I believe you are taking it way too personally, since clearly you are deeply involved in this.
It’s WTH, because yes, it did not work as I expected to, and my quick survey shows that many others had a similar experience, back from 2017 even.
And others seem to agree.
You may say it’s not a bug because documentation almost clearly states how it works and you may be right, in theory.
Admitted as bug or not, still an issue without solution or at least sensible workaround at the moment.
I’m not taking it personally at all. I’m trying to get you to follow the rules. As you can see, your issue was closed in less than an hour. I’ve also stated multiple times at this point that I want this feature. But you can’t get that though your head and you continue to argue by moving the goalposts when you’re proven wrong.
It was edited before it was closed. But thank you, I guess.
You mentioned there were discussions about last_seen already, so there’s no point in opening a request.
Just wanted to add my 2c to this. Elektrinis is going in quite hard saying its “wrong”, but I do agree with him. Currently I don’t see what the difference is between last_updated and last_changed, even when looking at your most hearted post. The difference I could think of is one updates when attributes update, and the other one doesn’t? But the names don’t make that clear at all. I’m
His explenanation is exactly how I would assume these properties work. How it works in the background or why they were implemented this way: I don’t care. I see last_updated and last_changed, and I assume what they are based on the names.
If last_updated actually showed when the entity was last updated (and not only changed), you could look on the map at a person entity, and assume how far away they are based on the last_updated value. Currently it shows when they last entered the away zone, which is something, but not as usefull as showing when exactly their coordinates were updated.
The property is the last time the state object was updated. Not the entity. And it means the last time any data inside the object was updated to a new value, not the last time it received data. Sorry, but that’s the behavior.
The discussion got heated and I am sorry for that. However my harsh reaction was to categorical reply from petro.
Please let me change my request: please not “fix”, but “change” the behavior to be as suggested by the name and actually as expected by most users.
You are clearly widely invested in the “last_updated” and your reaction to critics is way too sensitive. So let’s not say it’s a bug, it just needs revisiting.
Petro, after your explanation I understand what the behavior is, and I think there are many issues with that.
I think everyone understands now that “that’s the way it is”. But what we’re asking for is for it to be changed. The way it is currently doesn’t make sense to many people.
Just because “that’s the way it is” doesn’t mean it can’t be changed right?
Is it up for discussion in this case? If not, then I’ll be quite disappointed. Can you explain why in that case? Like what internal mechanisms use last_changed and last_updated in a way that changing them would break these mechanisms?
last_updated is an internally relevant timestamp, while last_changed is also quite useful to the end user. Therefore:
I agree with @petro that a new property would be better suited. At the same time last_updated could become purely internal and should be hidden from the end user. We can all agree that it doesn’t serve any purpose to the average user of the HA frontend.
Those two properties already have a function. You want a new property to indicate when the last state was received. Let’s call it last_acquired, as in states.domain.object_id.last_acquired.
The system is sort of at that point right now with last_updated, however there’s times when the frontend can benefit from this information. Like entities on the map that contain GPS coordinates. The main state essentially doesn’t change if they are still in the same zone, however the GPS coordinates may be bouncing around.
It doesn’t really matter what the name is. In fact, I don’t think we should even discuss the name because it’ll just be another point of contention. We simply just need a new property that doesn’t impact recorder’s recording, that contains the last time a state_object was sent new data from the device.
I have a quick question - it may, or may not be related to this thread. If its not, please redirect me to the correct place. I may also just use the wrong words/terms.
I am looking to display or plot my weight for the last 5 times I weighed myself. This could be 5x times in the last hour, or 5x times in the last 30 days.
The Xiaomi scale is integrated with the BLE sensor. However it always reports my last weight, no matter when that was. So, right now, if I make a card showing the weight sensor, it reports 135lbs, even though I last weighed myself a week ago. The “current” weight should be 0 or not applicable or something.
Is there a way too zero this out after X time, or only report data when it is received, or something?
Home Assistant provides a lot of flexibility around automation triggers. Consequently, a potential solution which might work for some is to use the last_triggered attribute of an automation that’s only triggered when the state of the entity changes.
I totally agree that the last changed date/time should not be reset when HA restarts. That is not helpful information at the sensor level. There are other ways to determine when HA is restarted. We really want to know when an entity LAST changed which is most likely not when HA was restarted. Perhaps the last changed date/time could be persisted somewhere, if it’s not already, and restored when HA is restarted.
I must say that I had the same problem with the last updated. I thought my sensor is faulty because it sometimes shown 30min on a sensor that sends an update every 1min. This is confusing.
Also I am surprised but it seems there is no way of simply logging values reported by a sensor (just change in value). This leads to a point where it is impossible to know what the actual value was at the exact point in time without some problematic availability logging. Lets say I have 433MHz temperature sensor. It might have weak signal and report at unpredictable intervals. How to setup the availability timeout? It will probably flicker the availability state.
I’m working now on a weather station data logging and charting. The standard charts are limited in their functionality, and it doesn’t look good on those. I switched to plotly (I know it is not officially supported), but changing the line type to e.g. linear distorts the actual data representation, because there are only “change in value” points, not the actual data points. This isn’t such a big deal, it kind of works, but on the other hand simple data logging seems to be a basic functionality that I would expect to exist in such a system. I don’t understand why it isn’t there. Are there any plans of adding that?
I’m looking for a way to make sure my integration is communicating successfuly with it’s endpoint. I found the discussion here which seems to have have become a discussion of semantics.
One example of a specific need is to determine when my Ambient weather station integration is not updating the data we look at. There are two known falut conditions. One the API at Ambient is failing. The other is my station is not connected to Ambient. Trying to develop a framework for montioring all what I consider to be critical sensors and an alert process for them. Another would be the temprature reported by a HVAC thernostat.
I take no sides in that but have not had a case where I was steered wrong by Petro so I appeal to you help define in a language that would be clear the the HA developers understand that there is a need to be able to ensure that information supplied by HA to users is timely and that there is a way to ensure the time accuracy of that data.
