Using Condition Entities

Using Condition Entities

Condition entities allow you to control when a PIN is active based on the state of another entity in Home Assistant. When a condition entity is configured for a user, the PIN will only be active when:

1. The user is enabled
2. The condition entity state is on

Supported Entity Types

Lock Code Manager supports the following entity types as conditions:

Entity Type	Domain	Use Case
Calendar	calendar	Schedule-based access with events (e.g., rental check-in/check-out times)
Schedule	schedule	Simple recurring schedules (e.g., 9 AM - 5 PM weekdays)
Input Boolean	input_boolean	Manual on/off toggle for access control
Switch	switch	Control access via any switch entity
Binary Sensor	binary_sensor	Control access via any binary sensor (great for template sensors!)

Calendar Entities

Calendars are ideal for non-recurring or complex schedules. The integration checks if there's an ongoing event at the current time.

Guest:
  pin: "1234"
  condition: calendar.guest_access

Features:

• Shows current event name and end time in the UI
• Shows next upcoming event when no event is active
• Create calendars using integrations like local_calendar

Tip: You can use a single calendar across multiple users, or create separate calendars per user.

Schedule Entities

Schedule entities are perfect for simple recurring patterns like business hours.

Employee:
  pin: "1234"
  condition: schedule.business_hours

Features:

• Shows when the schedule will next turn on/off in the UI
• Great for "every weekday 9-5" type schedules

Input Boolean / Switch Entities

For manual control, use an input boolean or switch. Toggle it on to enable access, off to disable.

Guest:
  pin: "1234"
  condition: input_boolean.guest_mode

Binary Sensor Entities (Template Sensors)

Binary sensors unlock the most flexibility. Use a template binary sensor to create complex conditions:

# Example: Only allow access when home is in guest mode AND it's daytime
template:
  - binary_sensor:
      - name: "Guest Access Allowed"
        state: >
          {{ is_state('input_boolean.guest_mode', 'on')
             and is_state('sun.sun', 'above_horizon') }}

Then reference it in your user config:

Guest:
  pin: "1234"
  condition: binary_sensor.guest_access_allowed

Use cases:

• Combine multiple conditions (guest mode + time of day + presence)
• Integrate with alarm systems (only allow access when disarmed)
• Weather-based access (e.g., allow contractor access only on non-rainy days)

You don't need YAML for this. Create the sensor in the UI under Settings → Devices & services → Helpers → Create helper → Template → Template a binary sensor and paste the template as its state.

Presence, Groups, and Other Entity Types

Any entity whose state isn't on/off can still drive a condition through a template binary sensor. A template is also how you invert a condition, which LCM has no option for.

For example, with a group of people (group.everyone), whose state is home or not_home:

Condition	Template
Someone is home	{{ is_state('group.everyone', 'home') }}
Nobody is home	{{ is_state('group.everyone', 'not_home') }}

Give one user the "someone home" sensor and another the "nobody home" sensor to switch codes on and off with presence. If the group becomes unknown or unavailable, both sensors turn off, so the codes are blocked rather than left active.

You don't need a group: zone.home reports how many people are in the zone, so {{ states('zone.home') | int(0) > 0 }} means "someone is home". A single person works the same way with is_state('person.alex', 'home').

The same pattern covers other entity types. For example, use is_state('alarm_control_panel.home', 'disarmed') to allow a code only while the alarm is disarmed.

Useful Integrations for Creating Condition Entities

These integrations are particularly useful for creating condition entities:

Integration	Description
Template	Create binary sensors or switches with custom logic using Jinja2 templates. Great for combining multiple conditions.
MQTT	Create entities controlled by external systems. Useful when access logic is managed outside Home Assistant.
Group	Combine multiple binary sensors or switches into one (on when any or all members are on). Groups created in the UI keep their members' domain, so a binary sensor group or switch group can be used directly. Old-style group.* entities, such as groups of people, can't be; wrap them in a template (see Presence, Groups, and Other Entity Types).
Workday	Binary sensor that's on on workdays (configurable for your country/region).
Time of Day	Binary sensor based on time ranges, including sunrise/sunset offsets.

Know of another useful integration? Please edit this wiki page to add it!

Note: Some integrations create entities that appear compatible but have state semantics that don't work with LCM. See Unsupported Condition Entity Integrations for details.

Migration from older configuration keys

The condition entity key is condition as of 5.0.0. Earlier versions called it entity_id (v1.0.0–4.x) or calendar (v0.9.x and earlier). Stored configuration is migrated automatically on upgrade — only YAML you paste in by hand needs to use the current key. See Upgrading to 5.0.

Displaying Condition Helper Controls Inline

When using helper entities (such as input_datetime, input_number, or input_boolean) alongside condition entities, you can display those helper controls directly within the LCM user card using the condition_helpers configuration property. This lets you adjust condition parameters (for example, start/end dates for a date range condition) without navigating away from the LCM dashboard.

Configuration

The condition_helpers property accepts a list of helper entity IDs to display inline for a given user. It can be set at three levels. At the dashboard and view levels the map is keyed by the user's internal slot number (see Finding a slot number); at the card level it is a plain list, since the card already identifies the user:

Dashboard level — applies across all views and cards:

strategy:
  type: custom:lock-code-manager
  condition_helpers:
    config_entry_id_here:
      1:
        - input_datetime.guest_start
        - input_datetime.guest_end

View level — applies to all cards in the view:

strategy:
  type: custom:lock-code-manager
  config_entry_id: abc123
  condition_helpers:
    1:
      - input_datetime.guest_start
      - input_datetime.guest_end

Card level — applies to a single user card:

type: custom:lcm-user
config_entry_id: abc123
name: Guest
condition_helpers:
  - input_datetime.guest_start
  - input_datetime.guest_end

Example: Date Range with Inline Controls

1. Create input_datetime.guest_start and input_datetime.guest_end helpers.
2. Use the Date Range Condition blueprint to create a binary sensor from those helpers.
3. Assign the binary sensor as the condition entity for the user.
4. Add condition_helpers to your dashboard configuration so the start/end dates can be adjusted directly from the user card.

Limitations

• One condition entity per user: Each user can only have one condition entity. For complex logic, use a template binary sensor to combine multiple conditions.
• State must be on: Access is granted when the entity state is on (or has an active event for calendars). All other states block access. To use an entity with other states, wrap it in a template binary sensor (see Presence, Groups, and Other Entity Types).