Best way to handle arming / disarming security alarm with door lock?

Configuration
1

I created the automation below so that when our cat sitter (Neighbor) unlocks the front door, the security alarm will be disabled. When leaving and the door is locked, the security alarm will be enabled. Then I tested it. I found myself unlocking the door and stepping inside the house, then wanting to lock the door, which would enable the alarm with me in the house.

I was thinking a delay might be in order, or at least a time in the "For" section of the triggers. Any suggestions how best to handle this would be appreciated!

-Thanks

alias: Front Door Lock - Vacation Mode
description: ""
triggers:
  - trigger: state
    entity_id:
      - lock.touchpad_electronic_deadbolt
    from:
      - unlocked
    to:
      - locked
    id: locked
  - trigger: state
    entity_id:
      - lock.touchpad_electronic_deadbolt
    to:
      - unlocked
    from:
      - locked
    id: unlocked
conditions: []
actions:
  - choose:
      - conditions:
          - condition: trigger
            id:
              - locked
        sequence:
          - delay:
              hours: 0
              minutes: 10
              seconds: 0
              milliseconds: 0
            enabled: false
          - action: input_boolean.turn_on
            metadata: {}
            target:
              entity_id: input_boolean.security_alarm_switch
            data: {}
      - conditions:
          - condition: trigger
            id:
              - unlocked
        sequence:
          - action: input_boolean.turn_off
            metadata: {}
            target:
              entity_id: input_boolean.security_alarm_switch
            data: {}
mode: single
2

TL;DR: lock state alone can't tell "left" from "stayed inside," so a delay/for: won't fix it. Either arm only when the door is locked from the outside (keypad/RF, not the manual thumb-turn), or use an exit delay that cancels if there's inside motion or a re-unlock.

Good instinct to flag it, but a delay or a for: won't actually fix this. The real problem is that "locked" can't tell "the sitter locked up and left" apart from "I locked the door and stayed inside" — the door is locked either way, so it'd still arm on you, just later.

Two good ways to handle it:

1. Best: only arm when it's locked from the outside. Most keypad deadbolts report how they were locked: keypad/code or RF (someone at the door, leaving) vs the manual thumb-turn (someone inside). Arm only on a keypad/RF lock and ignore the manual one, and your exact case is solved: the sitter locking via the keypad on the way out arms it, but you flipping the thumb-turn from inside doesn't.

To find what your lock reports: Developer Tools → Events, listen to zwave_js_notification (or state_changed for ZHA), lock it once with the keypad and once with the thumb-turn, and compare. You'll see something like "Keypad lock operation" vs "Manual lock operation." Add that as a condition on the arm action.

2. Robust fallback (any lock): an exit delay that cancels if you're still inside. Arm after a short grace period, but bail if the door is unlocked again or inside motion is seen, basically a real alarm's exit delay:

mode: restart
# in the "locked" branch sequence:
- wait_for_trigger:
    - trigger: state
      entity_id: lock.touchpad_electronic_deadbolt
      to: unlocked
    - trigger: state
      entity_id: binary_sensor.your_inside_motion_sensor
      to: "on"
  timeout: "00:01:30"
  continue_on_timeout: true
- condition: template
  value_template: "{{ wait.trigger is none }}"   # nothing cancelled it = nobody inside
- action: input_boolean.turn_on
  target:
    entity_id: input_boolean.security_alarm_switch

Unlock again or trip inside motion within 90s and it won't arm; if you really left, it arms. mode: restart so a fresh lock/unlock restarts the timer.

Two notes on your current one:

  • Your delay step has enabled: false, so it does nothing right now, and even enabled a bare delay still arms while you're home, just later.
  • No inside motion sensor? Then option 1 (lock method) is the way to go, the motion cancel is what makes the delay approach safe.

(If you have reliable presence detection, an "everyone away" condition on the arm is a nice extra net, though flaky with a cat sitter who isn't tracked.)

3

Thank you! I was not aware you could look into this from a zwave_js notification perspective. Good to know! I generated a "Manual lock operation" and unlock, then using the keypad outside generated the "Keypad lock operation" shown in the screenshot.

What I don't see how to do is use the "Keypad lock operation" event as a trigger or condition in an automation.

image
image826×737 29 KB

4

That "Keypad lock operation" event is exactly what you want for the arm side. You use it as an Event trigger (not a state trigger). In YAML:

- trigger: event
  event_type: zwave_js_notification
  event_data:
    device_id: 1a5a389ef82301e61fb1ec77004b0369
    event_label: Keypad lock operation
  id: arm

The event_data keys just filter the event: device_id pins it to your lock, and event_label to the keypad-lock case. (In the visual editor: add a trigger, pick Event, set Event type to zwave_js_notification, then put the event_data block in.)

So the whole automation becomes "arm only on the outside keypad lock, disarm on any unlock so you can get in":

triggers:
  - trigger: event
    event_type: zwave_js_notification
    event_data:
      device_id: 1a5a389ef82301e61fb1ec77004b0369
      event_label: Keypad lock operation
    id: arm
  - trigger: state
    entity_id: lock.touchpad_electronic_deadbolt
    to: unlocked
    id: disarm
actions:
  - choose:
      - conditions:
          - condition: trigger
            id: arm
        sequence:
          - action: input_boolean.turn_on
            target:
              entity_id: input_boolean.security_alarm_switch
      - conditions:
          - condition: trigger
            id: disarm
        sequence:
          - action: input_boolean.turn_off
            target:
              entity_id: input_boolean.security_alarm_switch
mode: single

Now flipping the thumb-turn from inside fires "Manual lock operation" instead, which this ignores, so it won't arm with you in the house. The sitter locking via the keypad on the way out fires "Keypad lock operation" and arms it.

One tip: the event_label text works, but if you want it bulletproof against any wording/translation changes, match the numbers instead, same result:

    event_data:
      device_id: 1a5a389ef82301e61fb1ec77004b0369
      command_class: 113
      event: 5

(113 = Notification/Access Control, event 5 = Keypad lock operation.)

5

Thanks again for your help with this! From your instructions I think I know what I need to do with the event based trigger, I will give it a try...

1 Like
6

I have this event trigger defined. And I have an "If triggered by arm" condition where the action just sends me a text message. But it's not trapping it for some reason. Not sure what I'm missing here.

-Thanks

trigger: event
event_type: zwave_js_notification
event_data:
  device_id: 1a5a389ef82301e61fb1ec77004b0369
  event_label: Keypad lock operation
  command_class: 113
  event: 5
id: arm
7

Before touching the condition, confirm the trigger itself is actually firing, because that's usually where these break.

1. Watch the real event. Go to Developer Tools > Events, subscribe to zwave_js_notification, then arm the panel. Look at the exact payload it emits. The most common cause here is that "arm" does not actually send Keypad lock operation / event 5. A lot of alarm keypads report arming via a different Access Control code, or via the Home Security notification type entirely, so the trigger you copied never matches. Match your trigger to what you actually see fire.

8

I just copied all of these event parameters from the event in Developer Tools to the trigger, but it's still not being triggered. I'll keep poking around...

-Thanks



trigger: event
event_type: zwave_js_notification
event_data:
  domain: zwave_js
  node_id: 10
  home_id: 3435971144
  device_id: 1a5a389ef82301e61fb1ec77004b0369
  event_label: Keypad lock operation
  command_class: 113
  event: 5
  type: 6
id: arm
9

If an exact copy still doesn't fire, the fastest way to stop guessing is the automation trace. Go to Settings > Automations, open this one, and check "Last triggered" plus the Traces tab.

  • No trace at all means the trigger never matched, so it's a data-matching problem (below).
  • There is a trace means the trigger did fire and your condition or action is what's swallowing it. That changes everything, since "not triggering" and "triggered but condition failed" look identical from the outside.

Assuming there's no trace, two things to do:

1. Capture the arm event live and diff it. Subscribe to zwave_js_notification in Developer Tools > Events, then physically arm the panel and read the payload that appears. Compare event and type to your 5 and 6. This is the usual culprit: the event you copied may have been from a different action (a manual lock, or an earlier test), and the actual arm press emits a different event number. The trigger can only match what arming really sends.

2. Strip the match down to the minimum. An exact copy with every field is the most fragile version, not the safest, since each key is one more thing that has to match perfectly. Cut it to just what's unique:

trigger: event
event_type: zwave_js_notification
event_data:
  device_id: 1a5a389ef82301e61fb1ec77004b0369
  event: 5
id: arm

Drop node_id, home_id, domain, type, and event_label. If it fires now, one of those fields was the mismatch (event_label text and the large home_id int are the usual offenders).

Two more quick checks: reload automations (or restart) after editing the YAML so the change is live, and test by actually arming, never the Run button, since Run leaves trigger empty and makes a working automation look broken.

My bet is still that arming sends something other than event: 5. The live capture in step 1 will tell you in about ten seconds.

10

It's working now, I mistakenly had a condition from a previous version of the automation which was preventing the actions to run.

Thank you for all of your help with this, much appreciated!

11

Awesome, glad to hear!

1 Like