The Problem:
Currently, Alarm.com treats all lock events identically. If an automation rule is set to “When Lock is Locked → Arm System to Away,” it fires whether someone hits the outside keypad while leaving or turns the inside thumbturn before going to bed.
The Safety & False Alarm Risk:
This all-or-nothing approach creates a serious false alarm hazard. When a family locks their doors manually, the system arms, and anyone in the house, unaware could then trigger an alarm either by the system, armed stay and them opening a door or by the system, armed away and them triggering motion sensor either of which could trigger an accidental alarm and possible emergency dispatch. Because of this, dealers routinely tell customers to avoid using “Arm on Lock” entirely. I’ve had this happen myself when the dog sitter came in after using her pin at the front door, turn around and lock the door behind her when she came in and then went to let the dogs out the back door. I can’t use the arm on lock feature at all at my home like I used to be able to with Vivint.
The Technical Solution:
The Z-Wave Door Lock Command Class ( 0x06 ) already sends distinct payloads for Manual Lock (0x01) and Keypad Lock (0x05) . Alarm.com already distinguishes keypad unlocks from manual unlocks for disarming.
Please expose this existing payload distinction in the Rule Builder. Allowing users to trigger rules strictly on Keypad Lock eliminates bedtime false alarms and creates a reliable exit automation for households where geofencing is impractical.
Thank you for taking the time to provide such a detailed explanation and for outlining the potential false-alarm concern.
We understand the distinction you’re requesting between a lock being locked through the exterior keypad and being manually locked using the interior thumbturn. At this time, Alarm.com’s Locking-triggered Arm rule is based on the lock reaching the Locked status and does not provide an option in the Rule Builder to specify the method used to lock it.
Your suggestion to expose the different lock-event types as selectable triggers would provide additional flexibility for this type of automation. We appreciate you taking the time to document the situation and propose a solution. We will submit this case to Alarm.com. While we don’t have an ETA on if or when this request would be implemented, we do see many such requests get added.
This makes a lot of sense. I can see how treating both types of lock events the same could cause problems, especially in a household where someone might manually lock the door from inside without intending to arm the system.
Having a separate keypad-lock trigger would give people much more control over their automations and avoid having to disable the whole “arm on lock” feature. Hopefully Alarm.com considers adding this distinction to the Rule Builder.