Blueprints

Blueprints

The Condition Linker takes a name in 6.0. It used to take a slot number, and it called an action that 6.0 removed. An automation already created from it has to be reconfigured with the person's Name — or simply recreated, since it is a one-shot. See Upgrading to 6.0.

Entity IDs changed in 5.0. Blueprints take entity IDs as inputs, and every Lock Code Manager entity was renamed from its slot number onto its user's name when you upgraded — ..._code_slot_1_pin became ..._raman_pin. Home Assistant does not rewrite IDs stored inside an automation, so automations built from these blueprints before 5.0 need their inputs repointed. The upgrade leaves a notification listing every rename. See Upgrading to 5.0.

Lock Code Manager provides Home Assistant blueprints for advanced automation use cases. These blueprints let you build custom workflows on top of LCM without modifying the integration itself.

Import them using the buttons below, or copy the YAML files from the blueprints/ directory in the repository.

Slot Usage Limiter

Type: Automation

Decrements an input_number helper each time a user's credential is used. When the counter reaches 0, the user is automatically disabled. Optionally resets the counter when the user is enabled again.

Setup

1. Create an input_number helper (Settings → Devices & Services → Helpers) with min=0, max=your desired limit, and step=1.
2. Import this blueprint using the button above.
3. Create a new automation from the blueprint and pick the user's credential used event entity, their enabled switch, and the helper you created.

Inputs

Input	Description	Default
Credential used event entity	The user's credential_used event entity.	(required)
Slot enabled switch	The user's enabled switch, turned off when the counter hits 0.	(required)
Uses counter	An input_number helper that tracks remaining uses.	(required)
Operations that spend a use	Which uses decrement the counter, by what the device did — unlock, lock, unknown.	unlock, unknown
Locks (optional)	Restrict to a specific lock or set of locks. Empty counts every use.	(all)
Initial uses on re-enable	When > 0, the counter resets to this value each time the user is enabled again. Set to 0 to disable auto-reset.	0
Notification service (optional)	A notify entity messaged when uses are exhausted and the user is disabled.	(none)

Why lock is off by default. Since 5.3.0 a credential that locks a door is recorded too. A guest who unlocks with their PIN and locks up behind them with the same PIN would otherwise spend two uses — locking themselves out of a one-use code for being polite. Uses reported through lock_code_manager.use_credential are always unknown, since nothing told Lock Code Manager what happened next.

Note: This blueprint replaces the built-in Number of Uses feature (removed in 2.0) with an input_number-based approach. It provides external visibility into the remaining count and allows programmatic reset via automations or the UI.

---

Calendar Condition

Type: Template (binary sensor)

Creates a binary sensor that turns ON when a calendar event is active and an optional condition template is truthy. Assign the resulting binary sensor as the condition entity for a Lock Code Manager user.

Setup

1. Import this blueprint using the button above.
2. Configure it with your LCM config entry, slot number, calendar entity, and optionally a condition template.
3. The blueprint creates a binary sensor — assign it as that user's condition entity.

Inputs

Input	Description	Default
Lock Code Manager config entry	The LCM config entry that manages your lock(s).	(required)
Slot number	The code slot number. Can be a static number or a Jinja2 template using calendar event attributes.	(required)
Calendar entity	The calendar entity whose events control this condition.	(required)
Condition template	A Jinja2 template that must evaluate to truthy for the sensor to turn ON (in addition to the calendar being active).	{{ true }}

Available Template Variables

Your condition template can use these variables:

Variable	Description
message	Calendar event summary/title
description	Calendar event description
location	Calendar event location
start_time	Event start time
end_time	Event end time
all_day	Whether the event is an all-day event
slot_number	The resolved slot number
config_entry_title	The LCM config entry title
name_state	The current name of the code slot

Example Condition Templates

• Allow when event title contains "Guest": {{ 'Guest' in message }}
• Allow only during business hours: {{ 8 <= now().hour < 18 }}

lock_entity_ids was removed in 5.3.0 — check your logs after upgrading.

A condition template still referencing it fails quietly: Home Assistant treats an undefined variable as empty rather than an error, so the binary sensor stays available, reads off, and the PIN never activates. The only signal is a log line — Template variable warning: 'lock_entity_ids' is undefined when rendering .... Nothing else will tell you. Remove the reference to fix the sensor.

There is no replacement, and it was not worth keeping: the list was the same for every slot in the config entry, so {{ 'lock.front_door' in lock_entity_ids }} could only ever be constantly true or constantly false. A condition entity gates a user across every lock in the entry; it cannot gate one lock.

Note: The condition template and calendar attributes are evaluated when the sensor is first loaded and when Home Assistant reloads template entities. For the default {{ true }}, the sensor dynamically tracks the calendar on/off state. For conditions that reference event attributes, reload template entities after calendar event changes to re-evaluate.

---

Date Range Condition

Type: Template (binary sensor)

Creates a binary sensor that turns ON when the current time is between two input_datetime helper entities. Assign the resulting binary sensor as the condition entity for a Lock Code Manager user.

Setup

1. Create two input_datetime helpers (Settings → Devices & Services → Helpers) — one for the start date/time and one for the end date/time. Enable both "Date" and "Time" on each helper.
2. Import this blueprint using the button above.
3. Configure it with your start and end date/time helpers.
4. The blueprint creates a binary sensor — assign it as that user's condition entity.

Inputs

Input	Description	Default
Start date/time	An input_datetime helper that defines when the access window begins.	(required)
End date/time	An input_datetime helper that defines when the access window ends.	(required)

Example Usage

Give a guest temporary access for a specific date range:

1. Create input_datetime.guest_start and input_datetime.guest_end helpers.
2. Set the start to your guest's arrival date/time and end to their departure.
3. Import this blueprint and select both helpers.
4. Assign the resulting binary sensor as the guest's condition entity.

Tip: You can display the input_datetime helpers inline in the LCM dashboard using the condition_helpers configuration property. See Using Condition Entities for details.

---

Condition Linker

Type: Automation (one-shot)

Calls lock_code_manager.set_condition to wire a condition entity to one person. This provides a UI-friendly way to assign condition entities without editing YAML.

Setup

1. Import this blueprint using the button above.
2. Create a new automation from the blueprint and configure it with your LCM config entry, the person's name, and the condition entity you want to assign.
3. Manually run the automation once from the Automations page (three-dot menu → Run).
4. The condition entity is now assigned to that person. You can delete the automation afterward or keep it for reference.

Inputs

Input	Description	Default
Lock Code Manager config entry	The LCM config entry that manages your lock(s).	(required)
Name	The name of the person to assign the condition entity to, as it appears in Lock Code Manager. Matched ignoring case and surrounding spaces.	(required)
Condition entity	The entity to use as the condition. Supports binary_sensor, calendar, input_boolean, schedule, and switch domains.	(required)

Note: This automation uses a synthetic event trigger that never fires on its own. You must manually run it from the UI.

---

Calendar PIN Setter

Type: Automation

Extracts a PIN from calendar event attributes using a user-provided template and sets it on a Lock Code Manager code slot. Optionally clears the PIN when the calendar event ends.

Setup

1. Import this blueprint using the button above.
2. Create a new automation from the blueprint and configure it with your LCM config entry, calendar entity, slot number, and a PIN template.
3. When a calendar event starts, the PIN is extracted and set on the slot. When it ends (if enabled), the PIN is cleared.

Inputs

Input	Description	Default
Lock Code Manager config entry	The LCM config entry that manages your lock(s).	(required)
Slot number	The code slot number. Can be a static number or a Jinja2 template using calendar event attributes.	(required)
Calendar entity	The calendar entity whose events provide PIN codes.	(required)
PIN template	A Jinja2 template that extracts a PIN from calendar event attributes. Must evaluate to a non-empty string.	(required)
Clear PIN when event ends	When enabled, the PIN is cleared when the calendar event ends.	true
Notification service (optional)	A notify entity messaged when PINs are set or cleared.	(none)

Available Template Variables

Your PIN and slot number templates can use these variables:

Variable	Description
message	Calendar event summary/title
description	Calendar event description
location	Calendar event location
start_time	Event start time
end_time	Event end time
all_day	Whether the event is an all-day event

Example PIN Templates

• Extract a 4-digit PIN from description: {{ description | regex_findall('\b\d{4}\b') | first | default('') }}
• Use the first 4 characters of the event title: {{ message[:4] if message | length >= 4 else '' }}

---

Finding a slot number

The Calendar Condition and Calendar PIN Setter blueprints ask for a slot number, and nothing in the user interface shows you one — Lock Code Manager assigns each user a slot and manages it for you, so the configuration dialogs and the dashboard cards deliberately never mention it. Those two still take one because the number can come from a template over the calendar event. Every action, and every other blueprint, addresses the person instead.

To find the number for a user, open any of that user's entities and look at its code_slot attribute. In a template:

{{ state_attr('text.all_locks_raman_pin', 'code_slot') }}

The number is stable: renaming a user does not change it, which is why renaming is free. It only changes if you remove the user and add them again.

---

Combining Blueprints and Condition Logic

These blueprints can be combined with each other and with Home Assistant's built-in features for more advanced workflows. Each blueprint controls a different aspect of the same slot independently.

Example: Calendar access with usage limit

Give a cleaning crew a code that's only active during scheduled times and expires after a set number of uses:

1. Calendar Condition — Create a binary sensor from your cleaning schedule calendar. Assign it as the condition entity of the Cleaners user (slot 3 in the blueprint). The code is only active during scheduled cleaning events.
2. Slot Usage Limiter — Set up a usage counter for Cleaners with a limit of 5 uses and auto-reset on re-enable.

How it works:

• When a cleaning event starts, the calendar condition turns ON → LCM activates the code on the lock
• Each time the code is used, the usage limiter decrements the counter
• If the crew uses the code 5 times, Cleaners is disabled (even during an active event)
• When the event ends, the calendar condition turns OFF → LCM clears the code
• Next event: Cleaners is enabled again → counter resets to 5

Example: Dynamic guest codes from a booking calendar

Combine all three blueprints for a fully automated guest access system:

1. Calendar Condition for the Guest user (slot 3) → code only active during the booking
2. Calendar PIN Setter for Guest (slot 3) → PIN extracted from the booking description (e.g. "Check-in code: 5678")
3. Slot Usage Limiter for Guest → max 10 uses during the stay

Combining conditions with groups

LCM's condition entity accepts any binary_sensor. Use Home Assistant's Group integration to combine multiple conditions into one:

• Create a group of binary sensors (e.g. calendar condition + presence sensor)
• The group turns ON when all members are ON (default) or any member is ON
• Assign the group entity as the user's condition entity

Example: Code active only during a calendar event AND when the home is in "away" mode:

1. Calendar Condition → binary_sensor.guest_calendar_active
2. Template sensor → binary_sensor.home_is_away (based on alarm state)
3. Group → binary_sensor.guest_access_conditions (all must be ON)
4. Assign the group as the user's condition entity

Using templates for custom logic

For logic that doesn't fit neatly into blueprints or groups, create a Template binary sensor and assign it as the condition entity:

template:
  - binary_sensor:
      - name: "Slot 3 Active"
        state: >
          {{ is_state('calendar.guest_bookings', 'on')
             and states('input_number.guest_uses') | int > 0
             and is_state('alarm_control_panel.home', 'armed_away') }}

This gives full Jinja2 flexibility for combining any Home Assistant states into a single condition.

---

Auto Re-lock

Type: Automation

Automatically re-locks a lock after it has been unlocked for a configurable amount of time. Supports separate day and night delays based on the sun entity's state (sunrise/sunset).

Setup

1. Import this blueprint using the button above.
2. Select the lock entity to auto-relock.
3. Set the day delay (in minutes). Default: 5 minutes.
4. Optionally set a night delay. Set to 0 to use the day delay for both day and night.

Inputs

Input	Description	Default
Lock	The lock entity to auto-relock.	(required)
Day delay (minutes)	How long to wait before auto-relocking during the day.	5
Night delay (minutes)	How long to wait at night (between sunset and sunrise). Set to 0 to use the day delay for both.	0

Note: Uses mode: restart — if the lock is unlocked again while the timer is running, the timer resets. If the lock is locked before the timer expires, the lock command is skipped.

Note: Night detection uses the sun.sun entity (Home Assistant Sun integration). If the Sun integration is not enabled, the night delay will never apply.

---

Lock on Door Close

Type: Automation

Automatically locks a lock when a door sensor detects the door has closed while the lock is unlocked. Useful for ensuring the door is always locked when closed.

Setup

1. Import this blueprint using the button above.
2. Select the lock entity to control.
3. Select the door sensor (binary_sensor with door device class).
4. Optionally set a delay before locking. Default: 5 seconds.

Inputs

Input	Description	Default
Lock	The lock entity to control.	(required)
Door sensor	A binary sensor that detects open/closed state (on = open, off = closed).	(required)
Lock delay (seconds)	How long to wait after the door closes before locking. Set to 0 to lock immediately.	5

Note: Uses mode: single to prevent duplicate lock commands. Only locks if the lock is currently unlocked when the door closes.

---

Credential Used

Type: Automation

Runs one or more actions every time a credential is used — whether Lock Code Manager saw a lock report it, or was told through lock_code_manager.use_credential.

Which of the three should I use?

All three see the same uses. The difference is what they trigger on:

• Slot Usage Notifier and Slot Usage Limiter trigger on one user's credential_used entity, so each automation covers the users you point it at. Reach for these when you want the focused, per-user recipe.
• Credential Used triggers on the lock_code_manager_credential_used event, so one automation covers every user in every configuration, and its filters narrow from there. Reach for this when you want the whole picture.

Inputs

Input	Description	Default
Actions	HA actions to run when a credential is used.	(required)
Lock Code Manager config entry (optional)	Only act on uses from this configuration.	(all)
Users (optional)	Only act on these users, by name.	(all)
Sources (optional)	Only act on uses entered at these entities.	(all)
Targets (optional)	Only act on uses against these entities.	(all)

Available Template Variables

Variable	Description
name	The user whose credential was used
source	The entity ID where the credential was entered
target	The entity ID it was used against

This is the blueprint to use for an external keypad opening something Lock Code Manager doesn't manage — a cover, a relay, an alarm panel. See External Keypads.

---

Slot Usage Notifier

Type: Automation

Runs actions when a user's credential is used on a lock. Use it to send notifications, trigger scripts, or run any HA action. Uses the HA action selector for full flexibility.

Setup

1. Import this blueprint using the button above.
2. Select the credential used event entity of each user to watch (e.g., "Raman Credential used").
3. Configure the actions to run when the PIN is used (notifications, scripts, etc.).

Inputs

Input	Description	Default
Credential used event entities	One or more users' credential_used event entities.	(required)
Locks (optional)	Restrict to a specific lock or set of locks. Empty runs for any lock the event entity reports.	(all)
Actions	HA actions to run when a credential is used (notifications, scripts, etc.).	(required)

Available Template Variables

Your actions can reference these variables in templates:

Variable	Description
slot_name	The name of the user whose credential was used
slot_num	The user's slot number
lock_name	Friendly name of the lock where the credential was used
timestamp	Date and time the event occurred (YYYY-MM-DD HH:MM:SS)
operation	What the device did with the credential: unlock, lock, or unknown

Note: Requires a lock that reports credential use (produces *_credential_used events; *_code_slot_*_pin_used before 5.0). Uses mode: queued with max 10 to handle rapid successive uses.