Cant help you with #1, but here’s what I’m using to track vacation status for your #2
- platform: template
sensors:
vacation_status:
friendly_name: "Vacation?"
value_template: >-
{% if states.alarm_control_panel.area001.attributes["armed_status"] == "armed_to_vacation" %}true
{% else %} false {% endif %}elkm1/elkm1_lib/const.py at main · gwww/elkm1 · GitHub are the states for alarm. For example BURGLAR_ALARM will show as burglar_alarm – i.e.: change name to all lower and substitute ‘_’ for ’ ’ (blank). Same pattern for all the other constants in that file.
Thank you exactly what i was looking for and could not find for some reason.
Anybody know why the following automation doesn’t trigger? I’m trying to get an alert for any alarms that trigger.
- alias: "alarm testing"
trigger:
- platform: template
value_template: "{% if not is_state('sensor.alarm_state', 'no_alarm_active') %}true{% endif %}"
action:
- service: notify.pushover
data_template:
title: "{{ trigger.to_state.attributes.friendly_name }} Changed"
message: >
{{ trigger.to_state.attributes.friendly_name }} has changed to {{ trigger.to_state.state }} or {{ sensor.alarm_state }}.
My alarm_state sensor looks like this:
- platform: template
sensors:
alarm_state:
value_template: '{{ states.alarm_control_panel.area001.attributes["alarm_state"] }}'
friendly_name: 'House Alarm State'
I’ve not used the template platform in a trigger before. I know that recently template sensors (for example) requires you to specify the entity ids that the templates use to cause the template to be re-evaluated when one of the specified entities change. Until recently, if you didn’t specify the entity id, it would always be re-evaluated which was time consuming, thus the change. (See https://www.home-assistant.io/blog/2018/10/26/release-81/ announcement.)
Perhaps something similar is at work here when using the template platform as a trigger?
Alternatively, you could use the state platform as the trigger, based on the template sensor you defined. (And you probably ought to add the entity_id to the template sensor you listed in any case.)
Template sensors will no longer auto update if we can’t find relevant entities in the template. You’ll want to review your template sensors and consider adding relevant
entity_identries or use the newhomeassistant.update_entityservice.
So what’s the ‘relevant entity’ in this template_sensor?
- platform: template
sensors:
alarm_state:
value_template: '{{ states.alarm_control_panel.area001.attributes["alarm_state"] }}'
friendly_name: 'House Alarm State'
Is it alarm_control_panel.area001? Wouldn’t that mean that any change to area001 would cause the template_sensor to update? I’m unclear as to how this works.
For example, I have this in my configuration (for a binary sensor, but same idea for a normal sensor):
binary_sensor:
- platform: template
sensors:
dark:
# states.sensor.time (which is always true) so that the template sensor is evaluated every minute
entity_id:
- sensor.time
- input_boolean.force_dark
- sun.sun
value_template: "{{ states.sensor.time and (is_state('input_boolean.force_dark', 'on') or states.sun.sun.attributes.elevation < 10.0) }}"
friendly_name: 'Dark'
This is sort of hacky, in that I cause the template to get re-evaluated each time sensor.time changes, even though it’s not really used in the template. At one time, changing attributes (the solar elevationz0 didn’t seem to trigger a state change on the sun.sun entity. But this illustrates how you have multiple entities associated with the evaluation of a template.
In your case, I believe that the “relevant entity” is alarm_control_panel.area001
I just recently finally got our “live” HASS environment updated to latest (it was still on an ancient 0.6x with old elk custom code)
While doing so I found some simplifications versus our old automations. The following sends a notification of who accessed the main area when either the front door or back door KAM is accessed (RFID keycards). Used to be separate automations for each KAM and also I had to make value template sensors to access the attributes but this works just fine. They trigger any time the KAM updates, which is only on access / disarm / etc.
- id: '1542678207721'
alias: Main Area Accessed
trigger:
- entity_id: sensor.front_door_kam, sensor.back_door_kam
platform: state
condition: []
action:
- data_template:
message: "[{{now().strftime('%H:%M')}}] {{ trigger.to_state.attributes.friendly_name}} accessed by {{ trigger.to_state.attributes.last_user_name }}"
service: notify.stride
As per my question above, if the relevant entity is alarm_control_panel.area001 doesn’t that mean Home Assistant is monitoring state-changes for all of the entity’s attributes? In other words, although this example matches on one attribute’s state-change, “alarm_state”, Home Assistant is actually evaluating all of alarm_control_panel.area001 attributes. Just want to confirm this is actually what’s happening under the hood.
Hm, interesting… I wasn’t aware of this - I assume you’re talking about this?
Template sensors will no longer auto update if we can’t find relevant entities in the template. You’ll want to review your template sensors and consider adding relevant entity_id entries or use the new homeassistant.update_entity service.
If so, it seems a little vague - in my case, hass must be able to find the ‘relevant entities’ because the template sensors update immediately…
Regardless, you bring up a good point, and it certainly may relate to this. Can you elaborate on this
Alternatively, you could use the state platform as the trigger ?
How would I do this with the not that I’m trying to achieve? I want to ignore the no_alarm_active state…
hrm… so I think it has to do with the fact that I failed to use the states.xxxx.state convention, but i still cant get it to work.
- alias: "alarm testing2"
trigger:
- platform: template
value_template: "{% if not is_state('states.sensor.arm_up_state.state', 'ready_to_arm') %}true{% endif %}"
action:
- service: notify.pushover
data_template:
title: "{{ trigger.to_state.attributes.friendly_name }} Changed"
message: >
{{ trigger.to_state.attributes.friendly_name }} has changed to {{ trigger.to_state.state }} or {{ sensor.alarm_state }}.
Inside the is_state template function, you should use the actual entity name. So sensor.arm_up_state to get the state of that entity. The other form references a data structure that exists within the template.
First Beta is missing your pull sadly 
Ill hold for the next drop
Finally got the automation working. This has only been tested w/ burglar alarm, but should technically inform me of any/all alarms. Thanks for the help!
- alias: "alarm testing"
trigger:
- platform: template
value_template: "{{ not is_state('sensor.alarm_state', 'no_alarm_active') }}"
action:
- service: notify.pushover
data_template:
title: "{{ trigger.to_state.attributes.friendly_name }} Changed"
message: "Changed to {{ trigger.to_state.state }}."
It could be I don’t understand, but the rc branch has my latest as far I can tell. The rc branch is where beta’s are cut from, again, as I understand.
Yep.
To clarify, any attribute inside a state object will spark a state change event. Doesn’t matter how buried the change is, as long as the overall state or an attribute changes.
Thanks!
I think I understand how all this works now but please correct me if I’m wrong:
Based on what you said here and the docs for State Objects, the listener monitoring alarm_control_panel.area001 detects changes to the entity’s State object, namely properties like state, last_updated, last_changed, etc and (if present) its attributes dictionary.
Whereas in the past, Home Assistant would determine a template-sensor’s entities (to be monitored) by inference, since 0.81 it requires they be explicitly defined. This spares it the overhead of sussing out the entities within the templates.
Your explanation also makes it clearer why something like now() can’t be used as a trigger in a template_sensor because (and you explained it elsewhere) it’s not an entity. Listeners are created for entities and not for functions.
I do not know if they are included in the ‘state change’. Those aren’t attributes, they are properties of the state object. To get a better idea of what causes state changes, you should monitor the traffic in the home assistant logs when you have it set to INFO. You’ll see the information that’s passed when a state object changes.
To clarify, it’s my understanding that state changes will only occur on when these two properties of the state object changes:
state.state
state.attributes
I believe all other properties will not cause a state change as they are properties.
So to clarify, this is a list of all state object properties:
state.state
state.entity_id
state.domain
state.object_id
state.name
state.last_updated
state.last_changed
state.attributes
and the only two properties that cause state changes are
state.state
state.attributes
EDIT to further clarify. People always incorrectly refer to properties as attributes. Attributes are only state.attributes and nothing else. Everything else inside the state object is a property.
Thanks! This further clarifies my understanding of how template_sensors (and other things) work in Home Assistant; state and attributes are the state object’s sole properties monitored for changes.
FWIW, the HA system I’ve used for many years (Premise) presents this information visually and so I found it to be easier to comprehend. Furthermore, I can (visually) create listeners for each one of an object’s properties (even alterations to its name or its group membership) or just one listener for all its properties.
For example, to monitor changes for a light object, here’s the dialog-box to select one of its properties (option to monitor all its properties is shown on the bottom).
Drawing parallels between what I know (Premise) and what I’m learning (Home Assistant) helps me get up to speed faster.