Configuration Structure

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, everything lives on the entry's own page under Settings → Devices & Services → Lock Code Manager:

• Configure edits the entry's locks.
• Each user is listed separately on that page, with Add user above them and an edit and a delete on each. Their entities and their device are grouped under them.

The dashboard's add-user card has a Manage users in settings button that opens this page.

Users

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

Add user asks whether to add one user or several users. One user is a form; several users is a block of YAML keyed by name, the same block the YAML path takes when you first set an entry up:

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"

The block only adds. A name already on the entry is refused rather than merged, matched ignoring case and surrounding spaces, so Bob and bob cannot become one person. To change somebody who exists, use the edit button on their row.

Each user has these fields:

Key	Type	Description
pin	string	The PIN this person uses. Optional, but required before you can enable them. In YAML, always quote it, or leading zeros are eaten.
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 |.

The same fields are what the add_user action takes, for adding people in bulk or from an automation.

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 6.0.0

Users moved out of the Configure screen and into config subentries — one per person, each with its own edit and delete on the entry's page. Configure now edits only the locks.

Your stored configuration is converted automatically when you upgrade. Nothing is renamed and nobody is renumbered, so every entity keeps its ID, its settings and its history.

There is no longer one editor holding every user at once. Adding several people still takes one dialog — Add user → Several users — or the add_user action, which takes a list. Editing and removing are one person at a time. See Upgrading to 6.0.

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.