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).
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 think that it works well how it is at the moment, and think that the previous comment mentioning a last_seen attribute would be the way forward with this (which is a feature request) last_updated to me implies that something was updated, and if nothing has changed then there hasn’t been any update.
well if last_seen is implemented, I don’t really care as long as it works.
However last_updated is still implemented wrong as it is.
You may be using it to refresh the map, since in your case the coordinates are changing. I want to use it to update my climate control strategy. I don’t really care what the temperature was an hour ago, I want to know what it is now and trigger automation/math/PID for every update I get, I can’t really trust the data that I have now. Different thing, same outcome.
Current implementation is broken and this field can now be used in only very limited corner cases, like yours.
It’s not implemented wrong. It’s working as intended, which is what you dislike. That’s it. That doesn’t mean it’s wrong. There’s a difference. Your single opinion isn’t going to change it or break the functionality for everyone else.
Yes, someone may have adapted their config to use this as it works now, and such change would break things for them. As many fixes do.
And it’s not a “single opinion”. An update is an update. If I write here I’m still waiting for this fix, it’s an update, even if I have not stopped waiting.
Anyway I have opened another issue to implement last_seen, since your friend rejected the bug report.
update: just for the sake of argument, I have just searched these forums for last_update and oh boy. Almost every hit involves misconception what this does and frustration, why it does not update as expected. It’s even mentioned a few times in the thread that you yourself have linked, petro.
Again, it’s a real issue.
Completely support this WTH. This is not a matter of opinion or dislike. Whether through a change or an added property, HA should be able to provide the datetime of last data received from the actual device.
The WTH is clear, the use cases are there, benefits have been outlined, this is probably easy to implement.
Yep, I agree. But I can guarantee you that it will not replace last_updated. I can also guarantee the behavior of last updated is not a bug.
Secondly, OPs way of attempting to circumvent the month of WTH by creating an issue against last_changed completely defies the rules of the month of WTH as well as GitHub. Personal opinions are not bugs. There’s no room for argument there.
