the “last_updated” attribute should really be the time that the entity was actually updated and shouldn’t be filtered/manipulated by HA at all. Otherwise it becomes useless since the data can’t be trusted.
Every integration should work the same. There shouldn’t need to be any work arounds/jumping thru hoops for this basic and seemingly self-explanatory functionality.
IMHO, it isn’t “complaining” if the OP sees a valid issue, reports it in a WTH (which is the entire point of WTH) and then tries repeatedly to give examples of the issue. But that’s just me…
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.
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.
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.
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.
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.
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.
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.
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.
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).
