Hi, After every update (and therefore a reboot) the state of my binary sensor “All windows and doors” has a state change. Even if the state did’nt change. That is unfortunate.
I get notified in my dashboards that someone changed the state.
when I go and check, I notice that the state was not changed, in fact it marks the same state again after reboot.
Is this something that I can alter in settings? If the state is off at boot start and off at boot end I dont want a state_change on my sensor.
The state did change. It went unavailable when home assistant was turned off. The state was then restored when home assistant started.
You can guard against this in automation triggers by supplying a from and to state. e.g from on to off or vice-versa.
Then why is the state “unavailable” not also there in the history overview? Sorry, let’s agree to disagree
Yes, phantom change entries in the state machine nearly guarantee that state machine is invalid. Without this logic error, state machine change tracking would only be invalid when there was a change while Home Assistant was offline or restarting, which is generally true anyway.
The current behavior generates state chaos which require workarounds such-as ‘from-to’ / ‘to-from’ state triggers and/or elaborate trigger templates and automations. Since the state change timestamp is reset at system startup, any logic dependent on state change timestamp are degraded.
There is a solution but it requires integration with the history database - the solution is allowing entity change to be determined at startup by comparing the entity state in the history database to the first loaded or restored value. This should also fire any state change triggers and each integration should be able to configure the desired behavior, legacy or improved …
There’s no disagreeing about it. It’s the way the backend works. Home assistant has no idea what happened to the sensor while it was offline.
Therefore my request of beeing able to not have a state change on reboot (of selected sensors)
Supplying one extra argument for a trigger is not “chaos”. Nice hyperbole.
Not agreeing to disagree because unavailable is an indeterminate state, and often not a valid basis for action, but rather it’s a basis for inaction. I’ve spent more than a decade thinking about this state, and it’s not in the same category as on/off, for instance
It’s simple. When home assistant is offline the state is unknown. So the state machine has to reflect that when it comes back online.
True, chaos might be an overstatement, but for some or most users this state change can lead to unwanted results in reaction of mind and even triggers.
Not requesting to have a major rewrite, just to allow that some sensors can be tagged as do not change at reboot…
Then make it so … My Shelly is having connectivity issues which is reflected in the history shown here. Unavailable is a true state. However, I restarted Home Asisstant this morning around 7am, where’s your unknown state change?
It only shows up if the state can’t be restored.
If you restore every state from the database, as per your suggestion you will get false states if the state changed while home assistant was offline.
This is intended behaviour for a reason.
And I never said an extra parameter to a trigger was chaos, I said it was a requirement, as in necessary… The to and from behavior is brilliant for many situations.
I’m fine with the current behavior if the “unknown” period is properly recorded into the history database, and the state change timestamp is consistent with and can be read from the state tracking database
Edit:
Let it be an option on the integration component to decide. It doesn’t make sense to update the changed timestamp and not store a state change in the entity history. The entity state doesn’t have a memory of the system restart.
From the entity perspective, the timestamp is behavior so unpredictable that it appears random, which is the physics def for choas as opposed to the emotional definition. Yes, I can write a script to lookup the system uptime and see if it is within 20 seconds of the last state change timestamp, but is a poor basis for deciding if the timestamp is updated due to system restart
This feature request is actually a duplicate of the top 6th (out of hundreds) most outstanding feature request on the platform with 341 votes
Coming from HomeSeer (does not behave in this manor), I’ve always wondered why Home Assistant did. It seems unnecessary to me also. That said way smarter people have, presumably with very good reasons, developed it this way.
Cool. Closing it as a duplicate then. If you feel the need to push the immovable object (there’s a reason it has remained un-acted upon for 3 years as I have been trying to tell you), then comment over there.
