I think I have the answer to this but I found out about the ‘problem’ by accident so I just want to be sure I properly understand it.
I discovered I have an automation (or probably many) that seem to trigger twice.
This is my trigger
- trigger: state
entity_id: sensor.house_mode
id: house_mode
and looking at the traces of the two times it was triggered I can see that the second time appears to be because the last_reported and last_updated attributes get changed.
The question really is, am I right, and if so is this expected because it seems to me a lot of automations will run twice?
It’s clearly been no problem for me (so far), I’m just interested.
Finally, are the only two ways to stop this happening to set to to null, or perhaps a small time like 1 second, although there will be cases where this is unwanted.
Or by adding mode: single and hoping the automation runs for longer than the time it takes for the attributes to be updated.
If that were true then it would be a frequent complaint in the forum. However, that’s not the case.
It’s probably because users normally either specify the desired state value(s) or are using entities that don’t have attributes with changing values.
FWIW, it’s good practice to specify the desired triggering states for a State Trigger unless the requirement it to trigger for anything and everything, including changing state values to/from unavailable and all changes to attribute values.
In my case, I have one or two automations that takes advantage of the fact a State Trigger can, in its simplest form, trigger for any and every change to an entity’s state or attribute.
The one I didn’t realize or consider when first starting out is triggering on the state change to or from “unavailable”, and I’ll bet that’s pretty common. I remember wondering why things happened (again) in my house when I restarted HA…
Oddly, I got tripped up with this in ESPHome today when I used an on_state trigger which didn’t trigger from being unknown/unavailable. There’s a flag trigger_on_initial_state that changes that behavior.
Not necessarily.
As I said I discovered this by accident and the automation this is happening with was fine running twice. Because of what it does It didn’t make any actual difference. Hence why I didn’t notice for a long time.
I would also question this (although by no means aggressively as I have no idea ). Many of my automations trigger on a simple state change and I am fully expecting to find more that trigger twice in the future.
That really goes to my point. Who knew that those ‘system’ attributes could change about 100th of a second after the state changed and cause a second trigger? And intuitively why would that even be a consideration?
(Actually, it is not even clear to me what last_reported even is - although I confess to not having tried very hard to find out yet)
Personally I don’t agree with this. ‘Good practice’ is a very subjective term
Good point, that would be another way to stop this and possibly a lot clearer than the documented from: null.
Indeed, exactly as I quoted in the OP
All I was really trying do here was check my understanding because I still think this default behaviour is completely unintuitive and illogical. the state is the state, the attributes are attributes and the trigger is a state trigger.
But of course I realise that it will not, and do not expect it to, ever change for many obvious and pragmatic reasons even if everyone were to agree with me.
It’s clear from your replies that you may have read the documentation for State Trigger but didn’t fully grasp the implications of its behavior. Perhaps that’s the documentation’s fault.
I suggest you submit changes to the State Trigger documentation, containing what you believe would clarify its operation.
I think I’m being completely misunderstood here.
The docs are good and I followed them easily.
I was really just trying to confirm I had understood them because they described something that seemed, and still seems, counterintuitive and illogical given that attributes are not just those that we can see in the dev tools, they include ones that ‘just exist in the background’ so to speak.
As I already said
And i still don’t know and don’t recall seeing it documented.
I just wish that the state trigger triggered on a state change. If it triggers on a state or attribute change it is mis-named.
But that ship sailed far too long a go to hope for a change now.
(And I wouldn’t like one - imagine the Breaking Backward-incompatible change that would be…)
Yes, yes, yes.
I am not questioning the docs or their accuracy or indeed anything with any real intent.
I think I fully grasp and understand everything around this subject1. I was just a tripped up by the trigger occurring on system attributes outside of anyone’s control and it struck me that most many, especially new users would have no idea this was happening and that the trigger was badly named.
The OP was simply borne out of surprise.
1 Except maybe see below
@busman Thanks. I missed that from last March, but then I don’t re-read all the docs every month.
I now take it back and think that the the state trigger docs could be improved to clarify the depth to which attributes the state object is checked i.e. the term attributes does not just apply to those visible in the dev tools which is something I didn’t know for at least a couple of years after first starting with HA.
And yes, I could.
Maybe I will.
Sorry it got lost in my other answers.
But thank you…
Indeed the sensor in question in this example does change it’s icon based on state.
And yes it looks like this may have been the cause of the second trigger.
Which goes a long way towards explaining what and why things happen the way they did.
Notwithstanding my (purely intellectual) objection to the name of, or the default behaviour of the state trigger
This entire topic serves as a lesson for other users.
Familiarize yourselves with Home Assistant’s State Object model and especially its terminology. Otherwise you run the risk of conceiving a confused model of how Home Assistant works.
I can’t disagree with that at all.
But with respect, I think that could be a tall order for a lot of people especially as HA becomes more and more ‘entry level’.
Yeah, especially with all this focus lately on making the UI more user-friendly. It’s not unreasonable to think, for example, a light has only two states and thus only two state changes possible – on to off and off to on. I still have some automations that are just:
- trigger: state
entity_id: light.living_room
to: "on"
Using something like not_from: unavailable seems a bit more advanced and maybe unexpected. A binary that has more than two states? Maybe a state_only trigger or state_all trigger, or an attribute on the trigger like ESPHome has.
I got a bit lost in this thread. Is the premise here that automations are triggering on last_[updated|changed|reported]? Not something I’ve seen or would expect.
Not unreasonable, just unfamiliar with all possibilities.
If an entity has ceased to communicate with, or be controlled by, Home Assistant, then its state is reported as unavailable. It may be a momentary or protracted period of unavailability.
If you know it can be in failure state like unavailable, you can design your automations to gracefully mitigate it. Otherwise you’re left with the faulty assumption that it always works, even when it has failed.
The hallmark of a good automation isn’t merely that it achieves a goal in an ideal situation, but how it handles a bad situation. The unavailable state informs you it’s now a bad situation.
All true and all very good advice but I can see no real defence for a state trigger to trigger if, for example, last_reported changes.
Despite it being by design and (kind of) documented.
). Many of my automations trigger on a simple state change and I am fully expecting to find more that trigger twice in the future.