I’d love to opt into making that assumption for some specific entities.
14 Likes
As the comment below yours mentions - I’d also like to be in control of that assumption too. The chances of state changing whilst HA is updating or restarting is so slim for me that I’d take that risk. Even if that’s just a different type of “last-changed” option, perhaps the “last-updated” attribute.
I think it would be fair to say “it keeps track of the last time the entity changed whilst HA was online”. For me on my window and door sensors at least.
1 Like
Sure, but then again, the state does change when connecting to the device.
I just want to know when my windows and devices actually changed states (I know they technically are but in reality they’re not) that weren’t a simple restart is all - in reality they only open and close. I’ve already made a load of manual sensors now but I’d imagine it being a bit misleading for a new user when viewed on a dashboard - as the many threads point out.
If it really can’t be done, even as a new attribute then fair enough.
3 Likes
I really dont care about the times hass is offline. I do care about the times it is online and not correct due to a restart.
6 Likes
So maybe payload-state and connection-state could/should be different attributes.
2 Likes
If the biggest issue is that state can be changed when HA is offline (which is rare as hell anyway), then opt-in should be avaailable for such option or just call it “last-known-changed”
Or just make two attributes, but please - let me know when it has happened and for sure it was not at last restart 
“Unknown” to “known” is not state changed in reality - it’s just for HA. My window does not have unknown states, it’s just zigbee addon
1 Like
I also believe that most HA users can live with this “assumption”.
8 Likes
Somewhat related, there’s a discussion I started about improving the UI around last updated and last changed at Move entity "Last updated" to the attributes section? · Discussion #13687 · home-assistant/frontend · GitHub.
zigbee2mqtt will assume the last state is correct on a restart, and that works pretty well. It’s on by default but can be disabled: MQTT | Zigbee2MQTT
While there’s lots of ways this could be approached, I think z2m’s has been proven out for just over 2 years without issues so its worth considering.
1 Like
I (and I assume many other users too) would be fine with a couple minutes of possible uncertainty, if the other option is certain uncertainty.
Sorry if I’m rude saying it this way: If the name of the attribute is last_changed, I don’t care what the underlying architecture says about it, I assume that is the last time that door has opened, or that person came home. I assume those facts don’t change after a HA restart .
Anyway, if last_changed has to stay this way, then I hope we can add another last_changed_irl or whatever attribute to actually reflect expected behaviour.
Oh also, isn’t there also a last_updated attribute? Why doesn’t HA use that one then for the behaviour of the current last_changed attribute?
4 Likes
Yes, you will be making the assumption that if the previous state equals current state, it hasn’t changed. I think this is a reasonable assumption, especially in the case of a restart. If you think this isn’t, then provide a way to opt out, either system wide or better yet on a per entity basis.
Another argument to be made is that in it’s current implementation, the value that defaults to last restarted is not only useless but more misleading since it didn’t necessarily change at the time of restart. Maybe the last changed should be null instead of the restart time.
2 Likes
while I, as a developer, agree with devs and Frenck reasoning, I have opposite experience as a user. In result have mixed feelings about final solution.
Life teaches that user experience is most important. The system should be designed under the hood to be reliable, while user should get what he expect.
It’s like designing user-friendly GUI over data model instead of creating edit forms being direct reflection if data structure.
For example when restarting HA at night (because this is the best time for such an action) I (as a user) don’t want to loose state of sleep mat my wife is sleeping on.
Also I hate reseting all sensors update time to the time of HA restart. It completely misses the user expectation. It’s against general user needs.
maybe instead of changing state to unknown, it would be better to leave the value but set some attribute saying ‘there is potential possibility the value changed during restart’
7 Likes
Glad to see this post is up high in the votes list! I think it definitely shows that it’s currently not working as users would expect across the HA community. Fingers crossed this is the year I can have easy meaningful last-changed states on my dashboard!
3 Likes
Last updated is already well defined. The difference between the two is basically attributes. Last updated is changed anytime the state of an entity changed including attributes. Whereas last changed is only updated if the actual state of the entity changed, it remains the same if only an attribute changes.
If last changed can’t be modified as this wth suggests then last updated can’t either, same problems. A new field would be required.
4 Likes
I’ve always wondered what the difference was between them, thanks!
I’d be equally as happy with a new field that persists across restarts if that’s the best option, best of both worlds then. Although I have no idea if that makes things much harder techncially.
I realize it is not a trivial task, perhaps especially with the (very long) sequenced boot-up that HA appears to do… but some commercial/enterprise systems implement a “soft” boot, where the processor assumes it does NOT have the correct state of the system, and instead of initializing from scratch, it initializes its state from the components that were not reset.
Obviously in this case, the last-changed info from the “other components” would have to come from somewhere else (presumably database?).
Maybe we just need a new attribute and need to agree on terminology. Is there a name for the set of all entity states excluding unavailable and unknown? Something like:
- Valid States
- Known states
- Real states
- Confirmed states
- Genuine states
- Established states
- Authentic states
- Validated states
- Official states
- added: Nominal states (post from Taras)
I don’t know what it should be, but for the sake of the rest of this argument I’ll go with “authentic states”.
Once we agree upon that, can we get a new attribute that is the last time the entity transitioned from one authentic state to another authentic state, ignoring all unavailable and unknown (non-authentic) states? And we can call that attribute “last_authentic_state_change”.
Edit: this would require keeping track of the most recent authentic state. So if the entity is currently unavailable you’d need to know that the most recent authentic state was open (for example). Maybe that would need to be another added attribute? That could even be useful in automations: looking at the most recent authentic state could be more useful in some scenarios than doing error handling on unavailable/unknown states.
But at the end - using MySQL and SQL statements it’s very easy to get those values.
P.S. I also didn’t like this initially - but at the end - there is a working solution and usually its more functional, as I have 10 windows in my living room - so I’m interested for last time when one of windows was opened rather than last time when specific windows was opened. Same like - to activate alarm - I’m interested to know if there is an open door or windows - due to this reason I have a “summary” sensors for all doors / windows and etc.
But how is that helpful?
How is what helpful? Stating the issues the HA team faces when considering this change? Or that devices can change while HA is down? Not sure what you’re asking here…