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.
2 Likes
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.
Yeah, its hard to visualize if you don’t know what you’re working with. At some point I could see there being a state object viewer like that.
You might play around a bit with the “Templates” developer tool to explore.
There is the state viewer in Developer Tools. And the states update in real time, as well. Looks like this:
(I’m still running an old version of Home Assistant and the Elk M1 support from before it was integrated into the baseline. So don’t take the specific attributes as anything special if they’re different from what you see.)
Yep, but this doesn’t show the properties. I don’t think there is a way to show all properties either. Also, just to add one more layer of confusion, in Jinja, properties are refered to as attributes. You should not confuse jinja attributes with the state objects attributes.
Odd, I just double checked the state of the tree for the 0.83.0b0 release on Github and it looks like the fix is in the tree? Weird if it’s not in the archive files on the release page …
I see the fix in the release versions. However i noticed that the state shows a single entity, and not an array, which then changes few seconds to cycle trough all the active states.
This make it pretty thought to be of value as for example keyfobs which are out of range for a day show as the fault; but in a cyclic fashion. When an alarm triggers the cause gets reported but I don’t get initially the real faulting zone.
Is it possibly to change the entity to list all the failing zones which will increase until such time the alarm is acknowledged.
Cheers
Damian
First off can I just say props to to @BioSehnsucht and @gwww for this great integration. 
Second, not sure if this is a bug report or a feature request, but the counter states never change from “unknown”.
(I’m new to HA I’m running hassio and when I click on the individual counters on the Overview page they just show a continuous state of unknown)
Yes, I believe that is a bug, in the ElkM1 library. I’ll take a look further when I get back to my system.
1 Like
I’m not following you. Are you talking about alarm_state?
Fixed counter not updating. Bug in base lib: https://github.com/gwww/elkm1/commit/5c496936d8f1c2e69eaa63da2bee42c49a34e08d
Add alarm memory handling. Actually added it a few weeks back and just discovered that I forgot to push it. Doh! It was also a base lib change. https://github.com/gwww/elkm1/commit/c729a28cab95c06a27909aed9f70744e9ebb1865
Submitted PR to hass to use newest lib (0.7.13).
1 Like
Anyone able to arm their Elk via Home assistant?
Calling service “alarm_control_panel.alarm_arm_home” with “entity_id”: “alarm_control_panel.elkm1_area_001” doesn’t seem to do anything.
Yes, I am able to. You must include the alarm code and that user code can’t be configured with Access user authorization. Check out my issue here.
1 Like
Yes, I can arm and disarm via Home Assistant if I include a user code.
None of my users have the “access” box checked. I can’t arm or disarm with HA, even if I include an access code.