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.
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:
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…
The way I see it there are two possible results:
The way it is now. HA reboots and the last_updated is wrong 100% of the time. Yes, we all understand that it did change during boot, but that’s kind of a cop out. Nothing is gained and the result is clearly wrong unless we want to argue minutiae.
Have the data survive a reboot. Yes, the device could have changed since reboot, but maybe not. At least it isn’t wrong 100% of the time. And at least we can be 100% sure of the last (real) change HA saw.
So I just don’t see how the comment explaining the current design helps us build a better Home Assistant. If we change it, of course HA isn’t going to know what happened while it was offline. HA also won’t know the state of any device before I ever installed HA. These things should be blatantly obvious.
I mean basically what you’re asking for is every entity to restore state, no longer leave that choice up to the integration developer.
You can’t just persist last_changed without also persisting the state of the entity. Otherwise when HA starts up there’s no way to know if the state of the entity is the same as when it shut down. If the entity was off when HA shut down and on when HA started up then you would want it to reset last_changed. It won’t be accurate since the change occurred while HA was off but a best guess during startup is more accurate then not changing it at all.
The next question is how to handle last_updated. Note that these aren’t the same thing. I point that out because you’re talking about last_updated here when this WTH is about last_changed:
I would expect these two to work the same though, they do now. But to do that means you have to not only persist the actual state value of the entity, you have to persist the entire state object (attributes too). Otherwise you wouldn’t be able to know if something changed while HA was down and you’d have the same issues I described above with last_changed.
All this is possible for sure but the cost is performance and disk I/O. The way state restore works is the state is written out to disk in /config/.storage/core.restore_state. HA does this every 15 minutes and on shutdown (assuming it is given time to cleanly shutdown instead of a power loss or force kill event). Most entities don’t restore state today. Suddenly making all of them restore state will not only take a lot more time every 15 minutes and on shutdown, it will cause a lot more writes to SD cards which are already being stressed out by all the recorded history.
I get why people want this but its not as simple as it sounds. It sucks to have to make an actual helper to store this value but perhaps asking the user to designate the entities they want this for is the right idea. Something like turning this behavior on for the entities you need it for in the more-info/settings panel could work better then making it either on or off for everything.
I’d be happy for state saving to be enabled/disabled at either a global or entity level. Perhaps enabled by default as that’s what’s most user friendly but I do agree it be good to disable for some users. I personally only need it enabled on my dashboard facing entities.
I’m glad this has the largest vote - it is truly a WTH for the ages.
I’m all for having a last known state as opposed to resetting everything to an arbitrary time when last booted.
I mean, it did last time too:
I’m just glad after years gone by it’s not still just me thinking “WTH” on this!
I think regardless of opinions on how the current last-changed/updated attributes work, there’s an obvious need for a last-known-state-changed attribute in some form. Whether that’s a toggle per entity or just a brand new attribute alongside the others…
The current form simply isn’t what the user would expect to see when using it, and that should be enough reason to introduce something new - as HA moves towards a more user friendly UI.
Posts like this from the previous WTH on this 2 years ago make me sad 
Seems like the devs are happy with how it currently works but most users would prefer something else.
just wondering if Scenes - Home Assistant would be helpful.
Or doesnt a scene created on the fly survive a restart either…
how could scene solve that my doors get ‘changed’ status even when no one touched them? 
wait, you’re right… I was thinking of the actual state, not the last_changed… my bad, please ignore
I think there might be a solution that makes everyone happy, but I’m just spitballing here. What if we keep last_changed as it is, but add functionality where you can get the last time there was a specific state change as well? Wouldn’t this cover the request stated in the OP (and a few others as well) while keeping the ‘logic’ intact?
Obviously this would depend on the history integration and the the availability would depend on the duration of the log, but that shouldn’t be a big issue for restarts at least?
I post my door state’s and change’s into an MQTT topic and use that as a separate timestamp sensor’s. One for open and one for closed. I found that I don’t care about closed, but I keep it anyways.
That is an interesting approach. Can you share specifics on how to use MQTT as a persistant state.
thanks
You make an automation that builds MQTT discovery information. Then you make an automation that posts the information to the topic’s configured in the discovery information.
I believe has @123 has generic versions of this floating around the forum. You can find mine in my configuration attached to my username here. However, mine rely on entity_id’s having a specific format so it won’t translate well to your system.