might correlate with this WTH 
I don’t think that “last_changed” and “last_updated” are equivalent.
“last_changed” is the last time the data actually changed. if the sensor keeps sending the same exact data every 10 seconds for 2 hours then the last_changed should be 2 hours ago.
but the last_updated should be 10 seconds ago even if the exact same data was sent for 2 hours.
8 Likes
I think that probably depends on the integration. For example you have a esphome node that send a sensor value (for example 10°C) then (for whatever reason) looses connection with ha for a second or two it will send that (unchanged) 10°C sensor value again when successfully connected (again). In that case the last_changed is updated even the sensor value stayed the same 
Another related issue - “last_changed” is equal to boot time, if server was restarted and if sensor is actually dead. It just takes the same dead value it had before server was rebooted, but forgets previous timestamp.
For example: sensor is dead for 10 hours and I see “last changed” 10 hours ago. Then I restart the server… And suddenly I see “last changed” a few minutes ago. Which is meaningless and misleading.
3 Likes
All of his examples are either custom integrations or have tools to get past the issue, except for BLE proxies. All to “win the argument” instead of discussing the actual feature he wanted (which we need). Sorry, but that comes off as complaining to me.
As for your comments, I think the best course of action is covered in another wth which mentions adding a last_seen or last_active property to all state objects.
2 Likes
Yes, mayyybe, but such basic thing should not need any tools or hoops to work around, it should just work out of the box.
I really hope that basic things like this will be done before some new fancy and exciting half-working features, as usual.
Just out of curiosity, how is it saved in the database now? There should be a timestamp with every datapoint anyway, right? So it’s just a matter of using it?
By the way this below seems to be incorrect. It’s a zigbee device with frequent broadcast. No way to check when was the last data received, but definitely not one hour ago.
1 Like
Right but that has literally nothing to do with the original intent of the WTH.
Last_changed can be whatever it wants (at least related to this WTH even tho I think it needs re-worked as well and agree with your link) but last_updated should be exactly that - when was the last time that the sensor received updated data from the device/integration.
Both of those should work the way they are advertised (by the name they used) and are expected to work by users instead of the way they work now.
I have posted a bug report. Hopefully it will be fixed one day.
[BUG] last_updated is incorrect · Issue #81069 · home-assistant/core (github.com)
1 Like
That will go no where. Last updated already has a meaning and home assistant follows that meaning correctly.
1 Like
It does not.
In what scenario in current setup last_updated is not the same as last_changed?
Because all I see is them being always the same, and incorrect.
1 Like
Yes, it describes how it is working now. But it’s wrong.
change is when value changes.
update is when value is updated to up-to-date value, even if unchanged. So the timestamp should be updated each time it’s received from sensor.
4 Likes
Yeah no. It’s correct. That was how it was decided to work. Not some random user on the forums who thinks it’s wrong.
2 Likes
Mayybe let’s not go this route, ok?
Everything is being done because someone decided it to be like that. Every functionality, no matter good or bad.
In current implementation there are two issues:
- It does not do what the name implies
- There is no way to see the age of actual data.
If so knowledgeable, Please also respond to my question in what scenarios last_changed and last_updated may be different.
4 Likes
Regardless, it’s not a bug or an issue. What your asking for is a feature request. Don’t come crying here when your issue is closed because you arent following the rules of GitHub.
1 Like
Why not just read it from the docs.
You can also check out my most hearted comment on the forums from ~4 years ago.
2 Likes
I use device trackers which report home or not_home these have attributes for latitude and longitude, when leaving home the device tracker updates the last_changed (and last_updated) as the state changes from home to not_home, whilst I am out and about the last_updated changes every time a new latitude and longitude is reported, but the last_changed does not, (as I am still not_home and that has not changed).
charlyr, well in your case the last_updated changes every time data comes in, which is good.
In all other cases, when data is coming, but not changing, it does not update, chis is not what the name implies.
I check the docs and this looks BS.
As per description, both fields change only when state actually changes.
If my window sensor sends “I’m still closed”, that’s an update, and should be logged.
1 Like