Blueprints

Blueprints

Lock Code Manager ships Home Assistant blueprints for common lock management patterns. The full reference for every blueprint — its inputs, template variables, examples, and one-click import button — is BLUEPRINTS.md in the repository, next to the blueprint files themselves. This page says what each blueprint is for and how to combine them.

Automations built from these blueprints on an older version may need their inputs changed. See Upgrading to 6.0 and Upgrading to 5.0.

Slot Usage Limiter

Limits how many times a user's PIN can be used: each use counts down an input_number helper, and the user is disabled when it reaches 0. Reference

Calendar Condition

Creates a binary sensor that is on while a calendar event is active, optionally filtered by a template over the event, to use as a user's condition entity. Reference

Date Range Condition

Creates a binary sensor that is on between the times in two input_datetime helpers, for a rental-style access window, to use as a user's condition entity. Reference

Calendar PIN Setter

Sets a user's PIN when a calendar event starts, taken from the event's title, description, or location by a template, and optionally clears it when the event ends. Reference

Auto Re-lock

Locks a lock again after it has been unlocked for a set time, with an optional separate delay at night. Reference

Lock on Door Close

Locks a lock when a door sensor reports that the door has closed while the lock is unlocked. Reference

Slot Usage Notifier

Runs your actions, such as sending a notification, whenever one of the users you pick uses their credential. Reference

Credential Used

Runs your actions on every credential use, across every user and configuration, narrowed by optional filters. It is the one to use for an external keypad that opens something Lock Code Manager does not manage; see External Keypads. Reference

Condition Linker

A one-shot automation that assigns a condition entity to a person by name, from the user interface instead of YAML. Reference

---

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 user 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 Initial uses on re-enable set to 5.

How it works:

• When a cleaning event starts, the calendar condition turns on and Lock Code Manager puts 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 and Lock Code Manager removes the code
• The counter resets to 5 when Cleaners is enabled again. The calendar condition does not turn the user's Enabled switch back on, so someone (or another automation) has to

Example: Dynamic guest codes from a booking calendar

Combine 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 (for example "Check-in code: 5678")
3. Slot Usage Limiter for Guest → at most 10 uses during the stay

Combining conditions with groups

A user's condition entity can be any binary_sensor. Use Home Assistant's Group integration to combine several conditions into one:

• Create a group of binary sensors (for example a calendar condition and a presence sensor)
• By default the group is on when any member is on; turn on its "All entities" option (all: true in YAML) to make it on only when all members are 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 with "All entities" on → binary_sensor.guest_access_conditions
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.