Auto-lock when the door is closed

A deadbolt automation that fires on a timer will lock an open door, or it will call lock.lock once, miss a jam, and stay quiet. This one waits until the door contact has been closed for a delay you set, commands the lock, then reads the lock state. If it is not locked — still unlocked, or jammed — it tries again, up to two more times. Only then does it send a high-priority push. If the door opens at any point, the run stops and it does not lock.

binary_sensor.front_door_contact and lock.front_door in the snippet are stand-ins. The pack is a blueprint with !input selectors. Do not publish which opening a lock covers.

What problem it solves

You want the deadbolt to lock itself a short time after the door shuts, to notice a jam instead of assuming the command worked, and to refuse to throw the bolt while the door is open.

How it works

For a contact with device_class: door, off is closed and on is open.

1. Closed delay — the contact goes off and stays off for the delay (pack default one minute). A swing that reopens resets the timer. There is no lock call before that hold.
2. Guard — every attempt checks the contact is still off. unavailable and unknown are not off, so a missing sensor does not lock the door.
3. Lock and verify — lock.lock on lock.front_door, then wait (pack default 15 seconds) and require state locked. locking is not success. jammed and unlocked are not success.
4. Retries — up to two more attempts (three calls total) with the same verify. A success stops the automation so the alert does not run. mode: restart means a door-open trigger cancels a retry that is in flight.
5. Abort on open — contact to on stops the run immediately. No lock call, no alert. The next close starts a fresh delay.
6. Alert — only if the contact is still closed and the lock is still not locked after the third verify. One critical Companion push. It does not repeat until the door opens and closes again, because the trigger is the closed-for edge, not a timer.

Already locked at the start of an attempt stops the run without another command and without an alert.

Hardware notes

• Lock. Any Home Assistant lock entity. Zigbee, Z-Wave, and Matter deadbolts all expose locked, unlocked, and usually jammed. Test with the lock’s own app or keypad so you know the entity matches the door you think it does.
• Contact. Use a sensor on the door slab, not the lock’s “I think I threw the bolt” flag. The lock state answers “did the bolt move?” The contact answers “is the door in the frame?” You need both. Never lock on the lock entity alone.
• Notify. Companion critical push, or any notify service. The alert is the failure path only.

Snippet

Stand-in ids. One minute closed, 15 seconds to verify, two retries after the first attempt:

mode: restart
max_exceeded: silent

trigger:
  - platform: state
    entity_id: binary_sensor.front_door_contact
    to: "off"
    for:
      minutes: 1
    id: closed
  - platform: state
    entity_id: binary_sensor.front_door_contact
    to: "on"
    id: opened

action:
  - if:
      - condition: trigger
        id: opened
    then:
      - stop: "Door is open"
  - repeat:
      count: 3
      sequence:
        - condition: state
          entity_id: binary_sensor.front_door_contact
          state: "off"
        - if:
            - condition: state
              entity_id: lock.front_door
              state: "locked"
          then:
            - stop: "Already locked"
        - service: lock.lock
          target:
            entity_id: lock.front_door
        - delay:
            seconds: 15
        - if:
            - condition: state
              entity_id: lock.front_door
              state: "locked"
          then:
            - stop: "Locked"
  - condition: state
    entity_id: binary_sensor.front_door_contact
    state: "off"
  - condition: template
    value_template: "{{ states('lock.front_door') != 'locked' }}"
  - service: notify.mobile_app
    data:
      title: "Deadbolt did not lock"
      message: "The door stayed closed, but the lock is not locked after two retries."
      data:
        push:
          interruption-level: critical

The repeat runs only for the closed trigger. The open trigger restarts the automation and hits stop before lock.lock. A contact that is not off fails the condition inside the repeat, the repeat ends, and the final contact condition blocks the push as well.

Setup outline

1. Confirm binary_sensor.front_door_contact is off with the door shut and on with it open. Confirm lock.front_door reports locked and unlocked when you use the keypad.
2. Import the blueprint. Set the closed delay, the verify time, and the notify service. Leave retries at two.
3. Shut the door and wait out the delay. The lock should throw once and the automation trace should stop on “Locked” with no notification.
4. Hold the door so the bolt cannot seat (or use a lock you can force into jammed on the bench). You should see three attempts, then one critical push, and no attempt while you open the door halfway through.
5. Open the door during the one-minute delay and confirm lock.lock never runs.

Troubleshooting

• It locks while the door is open. The contact is inverted (off means open on that device) or the automation is watching the lock entity instead of the contact. Fix the device class before you leave the delay at one minute.
• One attempt, then silence, bolt still out. The verify treats locking or unlocked as done, or the notify is inside the repeat. Success is state locked only. The push sits after the repeat.
• Retries forever. count is missing or the open trigger does not restart the run. Keep mode: restart and a finite count of 3.
• Alert every minute. A time-pattern trigger is also calling lock.lock. This pack uses the closed-for edge so a failure notifies once per close.
• Nothing after a restart. The door was already closed, so the for trigger does not replay. Cycle the door once, or run the automation by hand. Do not add a boot hook that locks without the contact reading off.
• Contact unavailable, and the door locked anyway. The guard condition is not on the lock call. unavailable must fail the off check.

Credits

Based on the community blueprint Auto-Lock Door Monitor. This write-up is an original closed-door delay, a lock-state verify, two retries, and a single high-priority alert. It does not lock an open door.