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 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.
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.
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.
That’s actually a pretty neat idea! If this WTH doesn’t manage to take off again this year I might just change my setup over, looks like it might cut down on a bit of code for me - but not as good as a inbuilt solution ofc!
Many veterans have been using this method for a very long time. I think I built this automation in 2016 with appdeamon, then switched it to HA automations sometime last year when I got rid of appdeamon.
It’s certainly a good alternative and thanks for sharing although I don’t think it should detract from the main point of this WTH which is it shouldn’t be hard for even a brand new user to get this expected info onto their dashboard
I just don’t think this topic is ever going to get anywhere until we start asking for something different. It’s clear that the last_changed and last_updated attributes will forever be driven by state changes inclusive of unknown and unavailable states.
What we need to start asking for is a new attribute that ignores unknown and unavailable state changes.
Hopefully that should be clear to the devs/anyone interested in developing this from the thread contents above. The title was more of a hook for people for people who think “yeah that is pretty annoying actually”.
Definitely agree about having a new attribute now though, seems like that’ll solve the devs concerns over the current unavailable states. I can’t see any disadvantages to a new attribute.
I can see why it would be a problem if there was no way to check when Home Assistant last started.
But overall, the current method has a much higher probability of being incorrect and constitutes a more risky assumption than letting last-changed survive a restart intact @frenck.
For many entities a last-changed value that survives a restart will still be correct. But assuming state changes upon a restart will almost be certainly incorrect for most entities.
Take this scanario: 13:00 window sensor switches to open, 13:15 Home assistant reboots, 13:30 user checks.
If the user is aware that Home Assistant restarted, the assumption that it would have missed any state changed during this time makes complete sense. A surviving last-changed state (13:00) is a correct assumption here, while 13:15 as last state change is counter intuitive and incorrect. It’s only intuitive to those who know how Home Assistant’s startup process works, which shouldn’t be a requirement for its correct usage.
I see three options for making this work better:
If the state of a sensor is different after Home Assistant starts from when it shut down, make the assumption that the state changed upon start. If it is still the same, keep the last-changed time from before the start.
In addition to 1: What could be considered is a time-limit. For example, if Home Assistant has been switched off for 2h, all last-changed values are reset.
A function for templates that makes it easy to check whether the last state change was due to a restart.
A function for templates that makes it easy when the last state change was, but lets the user decide whether to consider the “unavailable” state. For example: {{ last_changed('sensor.some_entity_id', 1) }} where the default is to consider all states, and 1 is “method 1”, which ignores unavailable.
I really think only point 1 is needed. A comparison of the startup state object to the last shutdown state object. Anything that’s different (main state, & attributes) will cause the startup state to be honored over the shutdown state. Make this the default and couple that with an option to have this functionality disabled per entity.
Seems like the devs are happy with how it currently works but most users would prefer something else.
