Persistent version of "last-changed" for the UI?

Something that has always annoyed me is how the “last-changed” attribute is handled after a restart. I understand why it’s changing as it’s technically unavailable but it’s not very helpful when you’re using it in the UI. On my security dashboard I only really care about the time a window state changed from on/off, not the fact that HA restarted and changed all my windows to 1 minute ago…

What’s the likelihood of a new “last-changed” attribute that persists state between restarts so I don’t need to create a million different manual sensors to hold the state for me? It’s been raised a few times in the past so it can’t just be me!

That is a very populair and old topic:

1 Like

Yep, so thought it was worth bringing up again! I can hope, thanks for the link, hopefully shows it’s a well requested feature.

1 Like

As an author of previous WTH thread:

i upvoted this one, as not even a single thing has changed in this matter and everytime I want to check something I still ask myself ‘WTH’…

2 Likes

Yeah it seems like it’s been a very requested change over the years so hopefully this gets enough votes to really show that people want it. The logbook is able to show when my window only opened and closed so surely the data is quite easily accessible. Fingers crossed!

Yes, more user feedback in an older posts here:

https://reddit.com/r/homeassistant/comments/vmxkvf/can_last_changed_secondary_info_survive_restart/

The biggest problem is very simple:

Home Assistant is offline (during reboot or when shut down). It has no idea what happened during that time. Restoring the last changed would be an assumption, not reality. (Besides that, it actually changes at startup, when connecting).

1 Like

I’d love to opt into making that assumption for some specific entities.

11 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.

:relaxed:

5 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 :wink:
“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 :wink:

1 Like

I also believe that most HA users can live with this “assumption”.

7 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 :wink:.

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

6 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!

2 Likes