Interpreting Alarm.com Sensor State

User story: We live in central Florida and have a nice pond in our backyard. Wifey loves to spend her mornings drinking coffee looking out over the pond while watching the ducks, egrets and baby alligator who call it home. This usually results in me – an hour later with the air conditioner running full blast – to “lovingly” remind her to turn off the air conditioner next time. Automatically turning off the air conditioner when we open the back door was her “killer feature” that sold her on letting me tinker around with HA.

So, the problem was how to read that the back door was open. Sure, a ZWave sensor would do it, but we also already have an Alarm.com alarm system with a sensor on the back door. So why have two things when just one will do it.

The Alarm.com integration is great at arming/disarming – and I was already using it in several other integrations. In the Developer States page, I could see that opening the backdoor resulted in a state change with “sensor_status: Z6 SLIDERS is open.”

How to get this piece of data into something that could turn off the air conditioner so Wifey could enjoy both the pond and her coffee?

[NOTE: May 12, 2019 update. See the end of this post for a more elegant solution using the template sensor platform.

Ingredients:

  • Alarm.com alarm system
  • Ecobee thermostat
  • Input_select custom field
  • Input_text custom field

I ended up writing my own automation that triggers on any state change to the alarm_control_panel.alarm_com object. Then, using a Jinga regex filter, I parsed the sensor_state for the important events to be kept in “input_select.backdoor”.

- id: '12345'
  alias: Alarm - State Change Decoder
  trigger:
  - entity_id: alarm_control_panel.alarm_com
    platform: state
  condition: []
  action:
  - service: input_select.select_option
    data_template:
      entity_id: input_select.backdoor
      option: "{% if state_attr('alarm_control_panel.alarm_com', 'sensor_status')|regex_search('Z6\
        \ SLIDERS is Open', ignorecase=TRUE) %}\n  open\n{% else %}\n  closed\n{%\
        \ endif %}\n"

For readability, the Jinga part is written out below with some whitespace:

   {% if state_attr('alarm_control_panel.alarm_com', 'sensor_status')|regex_search('Z6 SLIDERS is Open', ignorecase=TRUE) %}
      open
   {% else %}
      closed
   {% endif %}

Then, a second automation watches “input_select.backdoor” for a state change. After 5 minutes of being open, it will save the state of the Ecobee thermostat – in “input_text.ecobee_mode” and turn it off. A third automation watches for the door to close again and restores the original state of the thermostat.

You know what they say – happy wife, happy life. She’s out there enjoying her coffee right now as I write this out. She’s named the baby alligator “Arlo” – he just showed up a few weeks ago and is, I imagine, a terror to frogs and small fish everywhere.

2 Likes

This is a pretty cool project. I have a similar need that i sent to the larger group after I found this thread.

I would like to install HA to manage my Arlo cameras when I ARM and Disarm Alam.com (ADC).

Example: At night, if I arm ADC - ARM (Stay), I would like HA to trigger the Arlo system to “Armed” mode. In the morning when i disarm ADC, I would like HA to trigger Arlo system to “Disarmed” so the motion sensors in the cameras turn off.

Is this doable with HA? Just asking before I spend time building an HA environment.

My environment uses:
Alarm.com
SmartThings
Arlo
Zwave devices the control lighting and switches. These can both be seen by ST and ADC.

If this is possible i could use some help getting things going. I am not a Coder.

I haven’t played around with Arlo cameras myself, but by looking at the Arlo Components page (https://www.home-assistant.io/components/arlo/), it seems like that should be doable. The Arlo component looks like it already supports activating/deactivating the motion sensor without any further effort.

Then, it should be pretty straight-forward to make a rule, triggered on a state change for ADC that would de/activate motion sensing on the cameras. No “coding” should be needed as you should be able to use the user interface to set up that rule.

The example under “Camera” does exactly that – just replace the “trigger” with a state change on ADC instead of the “on HA start” that they show.

Thanks. I’ll give that a try. I hope you don’t mind if I ping you if I run into a problem?

@FlyGuy62N - In your overview you mentioned a 2nd and 3rd automation that watches the “input_select.backdoor” and enables your thermostat. Would you mind sharing those scripts? This would help me get an understanding of how all the flows are working.

Thanks.

Sorry for the delay John. Here’s all the parts together in one place.

I’m going to try to rewrite it today to use the Template Sensor component for interpreting the backdoor state from Alarm.com as that will be, I think, a cleaner/simpler implementation. If that works out, I’ll repost the updates.

configuration.yaml includes two input items:

  1. backdoor tracks open/closed
  2. ecobee_mode tracks the previous state of the Ecobee thermostat and is updated each time the automation turns off the HVAC system.
input_select:
  backdoor:
    name: Backdoor
    options:
      - "open"
      - "closed"
input_text:
  ecobee_mode:
    name: "Previous Ecobee Mode"

automations.yaml

- id: '1551552445847'
  alias: Otto - Alarm State Change Decoder
  trigger:
  - entity_id: alarm_control_panel.alarm_com
    platform: state
  condition: []
  action:
  - data_template:
      entity_id: input_select.backdoor
      option: "{% if state_attr('alarm_control_panel.alarm_com', 'sensor_status')|regex_search('Z6\
        \ SLIDERS is Open', ignorecase=TRUE) %}\n  open\n{% else %}\n  closed\n{%\
        \ endif %}\n"
    service: input_select.select_option
- id: '1551557141866'
  alias: Home - Ecobee Off When Backdoor Open
  trigger:
  - entity_id: input_select.backdoor
    for: 00:05:00
    platform: state
    to: open
  condition: []
  action:
  - service: input_text.set_value
    data_template:
      entity_id: input_text.ecobee_mode
      value: '{{ states(''climate.home'') }}'
  - service: climate.set_operation_mode
    data_template:
      operation_mode: 'off'
      entity_id: climate.home
- id: '1551559523000'
  alias: Home - Ecobee On When Backdoor Closed
  trigger:
  - entity_id: input_select.backdoor
    for: 00:00:30
    platform: state
    to: closed
  condition: []
  action:
  - data_template:
      operation_mode: '{{ states(''input_text.ecobee_mode'') }}'
    service: climate.set_operation_mode

Thanks FlyGuy62N for the info, this helps a lot. I’m also trying the template route but I’m a newb so I doubt I’m going to get far. Good luck!

@JohnB The template sensor was actually really easy and it eliminates the automation whose only job was to stuff values into input_text fields. Here’s the new layout…

configuration.yaml - My backdoor is on Zone 6, so Alarm.com shows “Z6 SLIDERS is Open” whenever the backdoor is open. The value_template searches AdC’s sensor_status field for the text. The icon_template changes the icon based on state.

sensor:
  - platform: template
    sensors:      alarm_backdoor:
        friendly_name: "Backdoor"
        value_template: >-
          {% if state_attr('alarm_control_panel.alarm_com', 'sensor_status')|regex_search('Z6 SLIDERS is Open', ignorecase=TRUE) %}
            open
          {% else %}
            closed
          {% endif %} 
        icon_template: >-
          {% if is_state('sensor.alarm_backdoor', 'open') %}
            mdi:door-open
          {% else %}
            mdi:door-closed
          {% endif %}

automations.yaml - the only change was to reference the correct object in the trigger – sensor.alarm_backdoor

- id: '1551557141866'
  alias: Home - Ecobee Off When Backdoor Open
  trigger:
  - entity_id: sensor.alarm_backdoor
    for: 00:05:00
    platform: state
    to: open
  condition: []
  action:
  - service: input_text.set_value
    data_template:
      entity_id: input_text.ecobee_mode
      value: '{{ states(''climate.home'') }}'
  - service: climate.set_operation_mode
    data_template:
      operation_mode: 'off'
      entity_id: climate.home
- id: '1551559523000'
  alias: Home - Ecobee On When Backdoor Closed
  trigger:
  - entity_id: sensor.alarm_backdoor
    for: 00:00:30
    platform: state
    to: closed
  condition: []
  action:
  - data_template:
      operation_mode: '{{ states(''input_text.ecobee_mode'') }}'
      entity_id: climate.home
    service: climate.set_operation_mode

I extended beyond just the backdoor by also capturing AdC’s state for each of the zones – all the other doors, windows and motion sensors. I now have one page on my HA dashboard to show the current state of all AdC zones. Adding them to automations will be a snap now.

image

Hopefully that’s enough to go on for your project. If you use the States Developers Tool, you can get the text you need for the search strings. Then it’s just a matter of getting the triggers and actions correct.

1 Like

@FlyGuy62N great job! This is just what I’m looking for. Unfortunately I’m having a hard time getting my configuration.yaml working. I took your example and tried modifying it for my environment. Here’s what I have so far.

Since I already had a “sensor:” section in my file, I added your code under it.

sensor:
  # Weather prediction
  - platform: yr
  - platform: aarlo
    monitored_conditions:
    - last_capture
    - total_cameras
    - battery_level
    - captured_today
    - signal_strength
  - platform: template
    sensors: 
      alarm_window:
        friendly_name: "Window"
        value_template: {% if state_attr('alarm_control_panel.alarm_com', 'sensor_status')|regex_search('Z6 SLIDERS is Open', ignorecase=TRUE) %}
            open
          {% else %}
            closed
          {% endif %} 
        icon_template: >-
          {% if is_state('sensor.alarm_window', 'open') %}
            mdi:window-open
          {% else %}
            mdi:window-closed
          {% endif %}

I tried moving things around to fix it with no luck.Now I getting this error:

@JohnB Have you tried using a template binary sensor? Does the same thing, but you don’t have to declare an icon template, instead it is a device class that translates the boolean on/off to make it pretty for the front end.

binary_sensor:
  - platform: template
    sensors:
      alarm_window:
        friendly_name: "Window"
        device_class: window
        value_template: >-
          {{ is_state_attr('alarm_control_panel.alarm_com', 'sensor_status')|regex_search('Z6 SLIDERS is Open', ignorecase=TRUE) }}
1 Like

@JohnB The problem is in value_template syntax. To use a “multi-liine” input, you need to use the >- right after the value_template:. Like this…

value_template: >-
  rest of code here

Take a look at what you have in icon_template where it’s correct.

@walrus_parka I’m still pretty new to HA. By using binary_sensor, with device_class: door, it looks I could’ve gotten there too. Thanks for the pro-tip.

@FlyGuy62N and @walrus_parka

Thanks for the help and advice. I tested both options and they worked in my environment! I tested the my office window and got some interesting results.

I used the Lovelace UI to test the sensor status change when the window is opened and closed.

  1. It took ~2 minutes for the UI to recognized the window being opened from a close state

  2. It took 20 seconds for the UI to recognized the window being closed from an opened state

For my needs I wished these numbers were reversed.

@FlyGuy62N - Are you seeing similar numbers in your environment?

I’m not sure looking at the Lovelace UI is the best way to test sensor updates. The UI may have a delay and things are happening under the hood in real-time.

Is there a better test I should use to test status changes?
Is there a way to speed up the notification for item 1 (opened from a close state)?

Just a small correction to @walrus_parka’s code above. With the is_state_attr call, it requires three parameters – the last one being the value to check against. However, we want to use a regex expression, so instead of is_state_attr, use just state_attr instead.

Also, since the value_template is just one line, I dropped the >- syntax for enclosing it in quotes. It cleans it up a little more in configuration.yaml.

binary_sensor:
  - platform: template
    sensors:
      alarm_window:
        friendly_name: "Backdoor"
        device_class: door
        value_template: "{{ state_attr('alarm_control_panel.alarm_com', 'sensor_status')|regex_search('Z6 SLIDERS is Open', ignorecase=TRUE) }}"

@JohnB, @FlyGuy62N have you had any success on adding silent arming to the HA alarm.com alarm panel? I’ve had the sensors up and running for a while now, but haven’t figured out how to get a night of silent arming feature set up. Any attempts or thoughts on this?

Hi Scott,
I followed the basic instructions room the alarm.com doc. I get the ARM Home and ARM AWAY items on the main page. When I select ARM Home the system says something like System Armed to Stay. I too would love to figure out a way to silently arm the system at night.

I’m using “alarm_arm_home” in an automation every night. Not quite sure what you mean by “silently”, but the panel doesn’t beep and with “alarm_arm_home”, the motion sensor is ignored just like it would be on the panel. It will only activate the siren if the back door or any of the windows are opened.

The condition ensures that it won’t override an “alarm_arm_away” state in the event we’re gone for the weekend or whatever.

There’s a corresponding rule to “alarm_disarm” each morning, but only if one of us is home (again, for the weekend away or whatever).

Is that what you were looking for?

- id: '1548901316524'
  alias: Home - Alarm Auto-Arm Home at Bedtime
  trigger:
  - at: '22:30:00'
    platform: time
  condition:
  - condition: state
    entity_id: alarm_control_panel.alarm_com
    state: disarmed
  action:
  - data:
      entity_id: alarm_control_panel.alarm_com
    service: alarm_control_panel.alarm_arm_home
  initial_state: true
- id: '1548902404127'
  alias: Home - Alarm Disarm at Wakeup
  trigger:
  - at: '07:00:00'
    platform: time
  condition:
  - condition: state
    entity_id: group.people_ha
    state: home
  action:
  - data:
      entity_id: alarm_control_panel.alarm_com
    service: alarm_control_panel.alarm_disarm
  - data:
      entity_id: lock.garage_door_lock
    service: lock.unlock
  initial_state: true

Thank you very much FlyGuy62N, I was able to add the alarm.com sensors based on your information without the thermostat function for now.

I share JohnB’s issue of a delay between the Home Assistant UI and the sensor state from the alarm.com config. Do you experience delays between the sensor and UI?

Thank you all, much appreciated

I am very confused in regards to what I need to do.
For instance I am using the alarm.com named sensor Office Window (14).

I created the following two codes

  - platform: template
    sensors:      
      alarm_office_window:
        friendly_name: "Office Window"
        value_template: >-
          {% if state_attr('alarm_control_panel.alarm_com', 'sensor_status')|regex_search('Office Window (14) is Open', ignorecase=TRUE) %}
            open
          {% else %}
            closed
          {% endif %} 
        icon_template: >-
          {% if is_state('sensor.alarm_office_window', 'open') %}
            mdi:window-open
          {% else %}
            mdi:window-closed
          {% endif %}      

and the following

  - platform: template
    sensors:
      office_window:
        friendly_name: Office Window (14)
        entity_id: alarm_control_panel.alarm_com
        value_template: "{{ 'Office Window is Open' in state_attr('alarm_control_panel.alarm_com', 'sensor_status') }}"
        device_class: opening  

I get the following
sensor.alarm_office_window (CLOSED)
binary_sensor.office_window (OFF)

Playing around with them and neither one shows when the window is open.
I am making myself very confused.
Can someone help me sort out what I need to do.
Thanks
carltonb

Test your value template by pasting it into the template tool in developer tools. For me, I forgot to update alarm_control_panel.alarm_com to the name of my actual alarm_control_panel entity, and it too me a while to realize that was my problem.