Skip to content

Configuration Structure

raman325 edited this page Aug 21, 2026 · 8 revisions

Lock Code Manager is configured per config entry. Each entry holds a set of locks and the people who may open them.

The UI steps you through this when you first set it up. Afterwards, Settings → Devices & Services → Lock Code Manager → Configure shows the whole entry at once: a lock picker, and a YAML editor holding your users.

Users

Each user is keyed by name. The name is how you refer to that person everywhere — in the dashboard, in the entity IDs, and in the events their PIN produces.

Raman:
  pin: "1234"          # quote it, or YAML eats the leading zeros
  enabled: true        # optional, defaults to true
  condition: calendar.my_local_calendar   # optional, see below
Housekeeper:
  enabled: false       # a user with no PIN yet must be disabled
Guest:
  pin: "5678"
Key Type Description
pin string The PIN this person uses. Optional, but required before you can enable them. Always quote it.
enabled boolean Whether the PIN is programmed onto the locks. Defaults to true.
condition entity ID An entity whose state decides when the PIN works. Optional. See [[Using Condition Entities

Names must be unique within an entry and cannot contain |.

You do not choose slot numbers. Lock Code Manager reads each lock, picks positions that are free, and keeps each person on the same position for as long as they exist. Adding or removing somebody never moves anybody else.

Locks

The lock picker takes any number of lock entities. Every user in the entry is programmed onto every lock in it. To give different people access to different doors, create a second config entry.

See Adding and Removing Locks.

Dashboard Configuration

The LCM dashboard strategy supports additional properties for customizing the UI. The condition_helpers property lets you display helper entity controls (such as input_datetime pickers) inline within a user's card. See Displaying Condition Helper Controls Inline for configuration examples at the dashboard, view, and card levels.

Key Type Description
condition_helpers map Maps config entry IDs (dashboard level) or slot numbers (view/card level) to lists of helper entity IDs to display inline in the card.

Changes in 5.0.0

Before 5.0.0, users were keyed by slot number and the condition entity key was called entity_id:

# the old shape -- no longer accepted
1:
  name: Raman
  pin: "1234"
  entity_id: calendar.my_local_calendar

Your stored configuration is converted automatically when you upgrade, and everyone keeps the slot number they already had. Only YAML you paste in by hand needs updating. Pasting the old shape is rejected with an explanation rather than silently creating users named 1 and 2.

The number_of_uses key was removed. Use the Slot Usage Limiter blueprint instead, which does the same thing with an input_number helper you can see and reset.

Clone this wiki locally