Upgrading to 6.0

Upgrading to 6.0

Lock Code Manager 6.0 finishes the move that 5.0 started: a person is the unit you work in, and the slot number is bookkeeping. Every surface that still addressed a slot is gone, and each person now has their own place on the config entry's page.

Upgrading migrates each config entry from version 4 to version 5. It cannot be undone from inside the integration. An older Lock Code Manager will not load an entry that 6.0 has migrated; the only way back is restoring a Home Assistant backup. Take one before you upgrade.

Coming from 4.x or earlier? The 5.0 migration runs first, in the same restart. Read Upgrading to 5.0 too — that is the one that renames entity IDs.

---

Before you upgrade

Search your automations, scripts and blueprints for these, because 6.0 removes them:

• lock_code_manager.set_usercode
• lock_code_manager.clear_usercode
• lock_code_manager.set_slot_condition
• lock_code_manager.clear_slot_condition
• lock_code_manager_lock_state_changed

Each has a replacement, listed below. Anything still calling a removed action fails with an unknown-action error, and anything still triggering on the removed event simply never fires.

---

What happens on the first restart

1. Each user becomes a config subentry of their entry, holding their name, PIN, enabled state, condition and slot number.
2. Each user's device moves under their subentry, so their entities and device are grouped under them on the entry's page.

Nothing is renamed and nobody is renumbered. Every entity keeps its ID, its settings, its area and its history, and there is no rename notification this time because there is nothing to repoint.

---

Where users live now

Open Settings → Devices & Services → Lock Code Manager and select the entry:

• Configure edits only the entry's locks.
• Each user is listed on the page with an edit and a delete.
• Add user asks whether to add one user (a form) or several users (a block of YAML keyed by name, the same block the setup flow's YAML path takes). A block only adds: a name already on the entry is refused rather than merged.

There is no longer one editor holding every user at once, so editing and removing are one person at a time. See Configuration Structure.

The dashboard's add-user card still adds a single user in place, and gains a Manage users in settings button that opens this page.

---

Removed actions

Removed	Use instead
lock_code_manager.set_usercode	set_credential
lock_code_manager.clear_usercode	clear_credential
lock_code_manager.set_slot_condition	set_condition
lock_code_manager.clear_slot_condition	clear_condition

The replacements take the config entry and the person's name where the old ones took a lock and a slot number:

# before
action: lock_code_manager.set_usercode
data:
  lock_entity_id: lock.front_door
  code_slot: 3
  usercode: "5678"

# after
action: lock_code_manager.set_credential
data:
  config_entry_title: All Locks
  name: Guest
  credential_type: pin
  value: "5678"

set_credential also behaves differently, and better: the PIN is stored in the configuration and synced to every lock in the entry. set_usercode wrote one lock behind the configuration's back, and the next sync could undo it.

---

Removed event

lock_code_manager_lock_state_changed is gone. Trigger on lock_code_manager_credential_used instead, or on the user's credential used event entity. It names the person rather than the slot they occupy.

Old field	Now
code_slot, code_slot_name	name
entity_id	target, and source for where it was entered
action_text, notification_source, state, from, to	operation, plus the target entity's own state
extra_data	dropped — read the source or target entity directly

See Tracking lock state change events.

---

Condition Linker blueprint

The Condition Linker blueprint now takes the person's Name instead of a slot number, and calls set_condition. An automation you already created from it must be reconfigured with the name — or simply recreated, since it is a one-shot.

The other blueprints are unchanged. The two calendar blueprints still take a slot number, because it can come from a template over the calendar event; see Finding a slot number.

---

New: a PIN in-sync sensor per lock

Each user has had an in sync sensor per lock. It is now the aggregate over every credential type Lock Code Manager manages for that person, and each type gets its own sensor beside it: {lock} PIN in sync.

The PIN sensor is disabled by default. With PINs as the only managed type it reads exactly what the aggregate reads, so there is nothing to gain from it yet. Enable it from the entity's settings if you want the split; generated dashboards show it next to the aggregate once it is enabled. Your existing in sync sensors keep their IDs and their meaning.

---

Other changes

• Setting up an entry shows progress while it reads which slots your locks already hold. A lock that answers one slot at a time can take a minute or more per lock, and the dialog now says so instead of appearing stuck.
• A write is confirmed by re-reading its own slot, not by reading the whole lock. On a large Z-Wave lock this was a walk of every slot after every write.
• Waiting for another operation on the same lock no longer counts as the lock not answering. A few users queued behind one slow operation could mark a working lock unreachable.
• Time limits scale with what an operation reads. A read that walks many slots gets time for each of them.
• Reloading or removing an entry no longer waits indefinitely on a lock that has stopped answering. A write in progress gets a short grace to finish, then is cancelled.
• Changes to an entry are applied one at a time, and a reload or removal waits for the change in progress rather than overlapping it.
• Entities of a removed lock are cleaned up on the next start, including disabled ones, which could previously be left behind.

---

If something goes wrong

• Check Settings → Repairs first.
• Debug logs and device diagnostics both show the migrated configuration.
• Recovery from a bad migration is a Home Assistant backup restore. There is no code-level downgrade.