Migrating from keymaster

Migrating from keymaster

A practical guide for switching from keymaster to Lock Code Manager. The two integrations cover the same problem space — keymaster's per-slot features all have an LCM equivalent — but the modelling differs in a few places, so this page walks through the swap step by step.

Before you start: PINs already on the lock

When you remove a slot from keymaster (or remove the keymaster integration entirely), keymaster stops managing the slot but does not clear the PIN from the physical lock. Codes you previously set through keymaster will remain active on the lock until something clears them.

You have two easy paths:

• Reuse the slots. Configure LCM with the same slot numbers and PINs. LCM will re-sync those slots and pick up where keymaster left off — no cleanup needed.
• Start fresh. Clear the codes from the lock first (via the lock_code_manager.clear_usercode service after LCM is installed, your lock integration's own clear-code service, or the lock's keypad), then configure LCM however you want.

Either way works — pick whichever fits how you want your slots laid out going forward.

Feature mapping

Keymaster	Lock Code Manager
Slot name	Slot name field
Slot pin	Slot pin field
Slot enabled toggle	Per-slot switch.*_enabled entity
Slot notifications flag	Slot Usage Notifier blueprint
accesslimit_count (uses-remaining)	Slot Usage Limiter blueprint
accesslimit_date_range_start / _end	Date Range Condition blueprint, attached as a condition entity
accesslimit_day_of_week (per-day + time window)	A schedule helper attached as a condition entity (Using Condition Entities)
starting_code_slot + number_of_code_slots	Any slot numbers you choose, configured in the LCM entry
autolock_enabled + day/night minimums	Auto Re-lock blueprint
Parent / child lock relationships (one primary, others bolted on)	One LCM entry listing multiple lock.* entities as peers — no primary/secondary hierarchy
Auto-generated keymaster Lovelace dashboard	LCM ships its own dashboard / view / section strategies — see UI Strategies
Akuvox, Schlage, Z-Wave providers	Same — plus Matter, ZHA, Zigbee2MQTT, and Virtual

Step-by-step migration

1. Inventory your keymaster setup

For each enabled slot, note:

• Slot number
• Name
• PIN
• Any access restrictions: date range, day-of-week + time window, use-count limit
• Whether notifications was on
• Which lock(s) the slot applied to

You'll re-create these in LCM. A screenshot of the keymaster dashboard per lock is usually enough.

2. (Optional) Clear stale PINs from your lock

Skip this if you plan to reuse the same slot numbers in LCM (the new entry will overwrite them on first sync). Otherwise, use your lock integration's clear-code service (e.g. zwave_js.clear_lock_usercode for Z-Wave) or the lock's keypad to wipe codes keymaster previously set.

3. Install Lock Code Manager

Follow the install section in the README — HACS, restart, then Settings → Devices & Services → Add Integration → Lock Code Manager.

4. Add an LCM entry

For each lock (or group of locks managed by the same parent/child setup in keymaster), add a config entry:

• Pick the lock entity (or entities — LCM accepts multiple)
• Set the slot range you want to manage. Slot numbers don't need to match keymaster's; LCM lets you start at any slot the lock supports.

If keymaster used parent/child locks to broadcast one PIN to several locks, configure those locks in a single LCM entry instead of separate entries — LCM will sync each slot across all listed locks automatically. There's no primary/secondary distinction in LCM: every lock in the entry is treated as a peer and sees the same slot definitions, so the order you list them doesn't matter.

5. Configure each slot

In the LCM entry's options, fill in name and pin for each slot you're bringing over and toggle enabled on. That handles the always-on slots.

6. Re-create access restrictions

For each slot that had keymaster restrictions, set up the matching LCM construct:

• Day-of-week + time window (e.g. weekdays 9 AM – 5 PM): create a schedule helper with the window, then attach schedule.<name> as the slot's condition entity. See Using Condition Entities.
• Date range (e.g. guest staying Mar 12 – Mar 18): import the Date Range Condition blueprint, configure it for the slot, and attach the resulting binary_sensor as the slot's condition entity.
• Calendar-driven access (e.g. an Airbnb iCal feed): use a calendar entity directly as the condition entity, or use the Calendar Condition blueprint for richer filtering.
• Use-count limit (e.g. PIN valid for 3 entries): import the Slot Usage Limiter blueprint. It disables the slot's enabled switch after the configured number of uses.
• Per-slot notifications: import the Slot Usage Notifier blueprint and target it at the slot's event entity.

For attaching condition entities through the UI rather than YAML, see the Condition Linker blueprint.

7. Re-create autolock (if you used it)

Keymaster's per-lock autolock with day/night minimums maps to the Auto Re-lock blueprint — one automation per lock, with optional separate delays for daytime vs. nighttime.

8. Set up the dashboard

Keymaster auto-generated a Lovelace dashboard per lock. LCM doesn't generate one automatically, but ships strategies that do the same job in a more composable way. See UI Strategies for the options (one-click dashboard, view strategy, or section strategy), and Custom Cards if you want to compose your own layout from LCM's building blocks.

9. Remove keymaster

Once the LCM slots are configured and you've verified the lock is responding to them (try toggling enabled and watching the PIN appear / disappear on the lock), remove the keymaster integration:

1. Settings → Devices & Services → Keymaster → ⋯ → Delete for each keymaster entry.
2. (Optional) Uninstall keymaster from HACS.

If you skipped step 2 and the LCM slot numbers don't fully overlap with keymaster's, any non-overlapping slots will still have their old PINs on the lock. Clear them now using the same approach as step 2, or just bring those slot numbers into LCM and toggle enabled off — LCM will clear them on the next sync.

10. Verify

For each slot:

• Toggle enabled off and on — confirm the PIN is removed and re-set on the lock (watch the slot card or the lock integration's logs).
• For slots with condition entities, force the condition off (e.g. end-time a schedule, expire a date range) and confirm the slot reports inactive and the PIN is cleared from the lock.

Provider notes

Provider	Keymaster	LCM
Z-Wave (zwave_js)	✅	✅ — Z-Wave integration
Schlage (schlage)	✅	✅ — Schlage integration
Akuvox (local_akuvox)	✅	✅ — Akuvox integration
Matter	❌	✅ — Matter integration
ZHA	❌	✅ — ZHA integration
Zigbee2MQTT (MQTT)	❌	✅ — Zigbee2MQTT integration
Virtual (testing)	❌	✅ — Virtual integration

If you're on a provider keymaster supports, the move is transparent at the lock level — the same lock.* entity that keymaster was talking to is what LCM will use.

Things that don't translate

• The auto-generated Lovelace dashboard — rebuild via UI Strategies (often a one-line YAML strategy reference covers the whole dashboard).
• Keymaster's autolock entity model — replaced by the Auto Re-lock automation blueprint. Behaviour is equivalent for the common day/night case; nuanced setups may need a custom automation.
• Keymaster's *.connected / *.code_slots entity naming — LCM exposes per-slot entities under its own naming scheme. Update any automations that referenced keymaster entity IDs.