Alarm triggering based on any lock unlocked

Configuration
1

Hi there,

I recently installed the manual alarm control system into my configuration.

I have the following automation to move it to the “triggered” state:

  - id: trigger_security_system
    alias: "[Security System] Trigger Security System"
    mode: single
    trigger:
      - platform: state
        entity_id: lock.all_locks
        to: "unlocked"
      - platform: state
        entity_id: cover.garage_door
        to: "open"
      - platform: state
        entity_id: binary_sensor.front_door_contact
        to: "on"
      - platform: state
        entity_id: group.all_gates
        to: "on"
    condition:
      condition: or
      conditions:
        - condition: state
          entity_id: alarm_control_panel.security_system
          state: armed_home
        - condition: state
          entity_id: alarm_control_panel.security_system
          state: armed_away
    action:
      service: alarm_control_panel.alarm_trigger
      entity_id: alarm_control_panel.security_system

Yesterday, while I was at work, my wife left home which moved the state to “armed_away”.

Shortly after, the alarm triggered.

Inspection upon my arrival home seemed to indicate that the group of locks changed to “unlocked” because one of the locks because “unavailable”.

Is there any way for me to specify that the state of one lock in the group must be “unlocked”? I read up on the groups behavior in the docs. It specifies if every lock becomes unavailable the group state becomes unavailable, which makes sense, and if any lock becomes “unlocked” the group state moves to unlocked, but it actually doesn’t specify the behavior if a strict subset of the locks in the group become unavailable. These logs indicate to me that if that happens, the group state changes to “unlocked” which seems a bit odd to me.

Here is the lock group:

- platform: group
  name: All Locks
  entities:
    - lock.exterior_locks
    - lock.interior_locks

- platform: group
  name: Exterior Locks
  entities:
    - lock.front_door_lock
    - lock.garage_outdoor_lock

- platform: group
  name: Interior Locks
  entities:
    - lock.garage_indoor_lock

IMG_6018
IMG_60181290×2796 386 KB

Any thoughts?

Thanks!
Matt

2

Like you said, the documentation indicates all group members must be unavailable for the group to report unavailable. If you’re experiencing something different (only takes one member to be unavailable) then report it as a new Issue in Home Assistant’s GitHub Core repository (where software bugs are reported).

1 Like
3
4

My guess is this was initially this door/lock that triggered the alarm, as you have only 1 in the group in Interior _Locks, Interior becomes “unavailable” … just a guess , and then the ALL_Locks also

5

@boheme61 it’s weird though because if you look at the screenshot, one of the 2 exterior locks is what triggered it. I had initially suspected what you said.

Although even if what you said was true, since all_locks contains 2 groups, if one becomes unavailable, it shouldn’t show as unlocked.

Matt

6

garage_indoor_lock become “unlocked” , interior_locks become unavailable, All_locks become “unlocked” Doo to garage_indoor_lock become “unlocked”

PS: Dont tell me your wife have a remote to open the garage_door, before she lock the front door :slight_smile:

EDIT: but yes it seems like maybe there is a “glitch” in “garage_outdoor_lock”. No idea why that becomes unavailable(for 2 seconds) 10min after the front_door was locked , maybe a “network issue” , i would give the Trigger(lock.all_locks) a “delay” for: 5-10 seconds if the “behavior” persists/occur again

PS: it’s doesn’t seems like the exterior_group becomes unavailable, but the garage_outdoor_lock

1 Like
7

@boheme61 thank you kindly for your reply it’s super appreciated! Great idea about the trigger. The only downside is that if someone unlocks the door, comes inside and re-locks it quickly enough, the alarm would never trigger. It’s an edge case maybe, but something to consider.

I’ll keep poking around to see if I can figure out the best answer.

8

Also, FWIW, that’s the reason I had the “to” in the trigger to “unlocked” rather than a “from” “locked”, since I know wireless entities (like locks) can become unavailable sometimes.

My goal was to explicitly know if they were unlocked.

9

Not necessarily an “edge” , but could be combined with either “person_presence” and or motion sensor inside “If alarm _armed and person_not, immediate_release_the guillotine” :slight_smile:

My Router is the first to know im coming(my phone), 20m from the House, in the driveway(im not using gps, or zones), But HA knows im coming, before i reach the frontdoor

10

@boheme61 the challenge is that it’s not just my wife and I. We have a babysitter that comes sometimes, and a cat sitter when we’re on vacation.

So rather than using standard presence (which I also use for her and I from our phones, companion app) I have this sensor:

    - name: someone_is_home
      state: >
        {% if states('group.family') == 'home' %}
          true
        {% elif states('input_boolean.babysitter') == 'on' %}
          true
        {% elif states('input_boolean.vacation') == 'on' %}
          true
        {% elif states('input_boolean.guest_mode') == 'on' %}
          true
        {% else %}
          false
        {% endif %}

So if the value of this is true, we don’t trigger any alarm.

The vacation and babysitter booleans are controlled by other automations, driven from the calendar integration, etc.

EDIT: and yes, looking at this (one of my first sensors I wrote) I do need to update it to use the recommend is_state :slight_smile:

11

Yeah ok, i didn’t think so far, as you might have noticed, anyway it wasn’t a proper workaround, if the Outdoor_garage_door or other devices tend to report “unavailable” for no obvious reasons

1 Like