Automation to arm/disarm alarm - looking for feedback

[evanw]

Hi folks,

I’m new to Home Assistant (via HAOS) and am moving over from SmartThings.

I’ve been working on setting up an automated alarm arm/disarm system using Home Assistant automations, persons/zones, and Alarmo, and since I’m new to this, I wanted to reach out for any feedback from the community on if I’ve missed anything or am making any ignorant mistakes (or alternatively, if I’m on the right track, perhaps others will find this useful). Through my testing thus far, it appears to be working as expected.

The main use cases I have are:

1. Automatically arm the system when everyone leaves
2. Automatically disarm the system when anyone arrives
3. Automatically arm the system into night mode around the time everyone goes to bed
4. Automatically disarm the system in the morning when people are present

I’m using “Person” and Zone entities to track presence for my wife and I, using both the companion app for GPS as well as our network presence via the router.

Automation 1: Arm when everybody leaves

alias: "Alarm: When nobody is present, arm"
description: ""
trigger:
  - platform: numeric_state
    entity_id:
      - zone.home
    below: 1
condition: []
action:
  - device_id: c6613f8e40fa8575cf6c89d0e95ecb0c
    domain: alarm_control_panel
    entity_id: 388b302d4237b9ed9852ebfc070b1842
    type: arm_away
mode: single

Automation 2: Disarm when anyone arrives
This one looks at the home zone’s state to see if anyone is present and disarm the system if so.

alias: "Alarm: When anyone is present, disarm"
description: ""
trigger:
  - platform: numeric_state
    entity_id: zone.home
    above: 0
condition: []
action:
  - device_id: c6613f8e40fa8575cf6c89d0e95ecb0c
    domain: alarm_control_panel
    entity_id: 388b302d4237b9ed9852ebfc070b1842
    type: disarm
mode: single

Automation 3: Disarm if someone unlocks the front door via the keypad door lock

This one is if a guest etc. visits the house and uses a code to unlock the door. I might have over-complicated it a bit by having the conditional check to see if the system is actually armed before doing the disarm – this could probably be removed to simply always disarm the system regardless of its current state.

alias: "Alarm: Disarm if front door is unlocked with code"
description: ""
trigger:
  - platform: device
    device_id: b118f62e8cae1179bbed81d96dae5e8e
    domain: lock
    entity_id: 7298ce4bf1e7605b8a06ab5d762f82a1
    type: unlocked
condition:
  - condition: or
    conditions:
      - condition: device
        device_id: c6613f8e40fa8575cf6c89d0e95ecb0c
        domain: alarm_control_panel
        entity_id: 388b302d4237b9ed9852ebfc070b1842
        type: is_armed_away
      - condition: device
        device_id: c6613f8e40fa8575cf6c89d0e95ecb0c
        domain: alarm_control_panel
        entity_id: 388b302d4237b9ed9852ebfc070b1842
        type: is_armed_night
action:
  - device_id: c6613f8e40fa8575cf6c89d0e95ecb0c
    domain: alarm_control_panel
    entity_id: 388b302d4237b9ed9852ebfc070b1842
    type: disarm
mode: single

Automation 4: Arm at night

This one uses an arbitrary time (11:45pm in this case) to arm the system. As noted in the description, it looks to see if the system was already disarmed before enabling armed night, because I don’t want this to happen if the system was already armed (i.e. we were away).

alias: "Alarm: Arm at night"
description: >-
  Enable Armed Night mode if the system was already disarmed (i.e. someone is
  home). If not in disarmed mode, then it won't enable night mode (which is
  good, because we want to stay in Armed Away in that case).
trigger:
  - platform: time
    at: "23:45:00"
condition:
  - condition: device
    device_id: c6613f8e40fa8575cf6c89d0e95ecb0c
    domain: alarm_control_panel
    entity_id: 388b302d4237b9ed9852ebfc070b1842
    type: is_disarmed
action:
  - device_id: c6613f8e40fa8575cf6c89d0e95ecb0c
    domain: alarm_control_panel
    entity_id: 388b302d4237b9ed9852ebfc070b1842
    type: arm_night
mode: single

Automation 5: Disarm in the morning

This is the complement to the “arm at night” rule, and similar to that rule, it first checks if the system was already in armed night mode because I don’t want the system disarming if we are away.

alias: "Alarm: Disarm in morning"
description: >-
  If the system was previously in the armed_night mode, then disarm
  automatically in the morning. armed_night mode should only engage if someone
  is present, so therefore this disarm step will only happen if someone is
  present as well.
trigger:
  - platform: time
    at: "07:00:00"
condition:
  - condition: device
    device_id: c6613f8e40fa8575cf6c89d0e95ecb0c
    domain: alarm_control_panel
    entity_id: 388b302d4237b9ed9852ebfc070b1842
    type: is_armed_night
action:
  - device_id: c6613f8e40fa8575cf6c89d0e95ecb0c
    domain: alarm_control_panel
    entity_id: 388b302d4237b9ed9852ebfc070b1842
    type: disarm
mode: single

Thank you for any feedback or suggestions!

[armedad]

first, nuke all the device id’s

Why and how to avoid device_ids in automations and scripts

Background When you start writing automations, a device trigger seems the obvious choice. Everybody knows what a device is and it comes at the top of the UI dropdown list. [image] It works… but it is certainly not a “great way to start” because it is storing up problems for the future. Far better to use an entity, with state or numeric_state. Device_id problems The yaml will be longer and harder to follow, which may make maintenance difficult, especially a few months down the line when yo…

[parautenbach (Pieter Rautenbach)]

Very useful, but I’d recommend moving away from device triggers, conditions and actions: just use the entities directly.

Why and how to avoid device_ids in automations and scripts

Background When you start writing automations, a device trigger seems the obvious choice. Everybody knows what a device is and it comes at the top of the UI dropdown list. [image] It works… but it is certainly not a “great way to start” because it is storing up problems for the future. Far better to use an entity, with state or numeric_state. Device_id problems The yaml will be longer and harder to follow, which may make maintenance difficult, especially a few months down the line when yo…

I personally wanted take the path you did, but in the end felt more comfortable with sending actionable notifications to ask whether it can do something like automatic arming or disarming the alarm.

[evanw]

@armedad

first, nuke all the device id’s

Great advice - thank you for sharing this. It definitely smelled a bit seeing all the IDs in the YAML and makes it hard for others to follow. Ironically, I had set up all the Alarmo actions using their respective entities, but then I moved those all over to the Alarmo device instead thinking that was a better level of abstraction (oops).

[armedad]

besides the device id stuff that pieter and i raised, a few thoughts from my experience using our auto-alarm system.

• having it auto-alarm at a specific time might work for you but didn’t work for us. there are too many reasons/times when we end up opening a door/window at night. particularly w/ kids and pets. what ended up working better was that we had a “good night” command that triggered several other things… turned off all the lights, opened the drapes, and then also set the alarm.

• definitely found disarming when the door is unlocked to be a good thing.

• why do you have automation 2, 3 and 5 separate? i’d put all the triggers for disarming together. and why, in automation 3 do you check to only do this when it’s armed for some reasons, whereas automation 2 you disarm always? if you need to do it in 3, seems like you’d do it in 2 and vice versa.

• consider a vacation mode… because when you’re on vacation, i presume you don’t want your alarm disarming at 7am…

the thing that you didn’t do that i’ve most appreciate in my alarm automation is to detect when the alarm has been left on for > 24hrs. at which point it automatically goes into vacation mode. our hvac system goes into low power (60 degress to 85 degrees), vacation lights turn on, etc.

[evanw]

@armedad Thanks for the feedback!

@armedad

consider a vacation mode… because when you’re on vacation, i presume you don’t want your alarm disarming at 7am…

I think I have this scenario covered: The “disarm in the morning” automation has a conditional check that the system was already in armed_night mode, which can only occur if someone was home (because armed night had its own precondition of the system being disarmed before it could kick in). So if we were on vacation, the 7am timer would hit, but the system would be in armed_away instead of armed_night, so nothing would happen and the system would stay in armed_away.

[armedad]

ah, righto!

[parautenbach (Pieter Rautenbach)]

@armedad

definitely found disarming when the door is unlocked to be a good thing.

I actually went the reverse in this one: When I get home and disarm the alarm, then unlock some doors. My reasoning was that disarming the alarm is a clear signal that I consider my environment safe.

The arrival part makes it different from should you be at home already and e.g. are unlocking a door from the inside when the alarm is in a stay/home mode — it can definitely be useful to not have your alarm’s siren sound unnecessarily when accidentally opening a door or such.