What the heck is with the 'latest state change' not being kept after restart?

That would make sense, maybe a “last saved” timestamp? The state is already saved so another attribute doesn’t like like a massive change

By monitoring the restart button/service?

You don’t, you never. I don’t care if its not having status after a crash.
But… it can be like e.g. every 5 minutes it also saves the states in case of…

There are two properties for every entity, last_updated (when the state was last written to the state machine) and last_changed (when the state last actually changed). It would be nice if last_changed could survive a reboot even if the last_updated doesn’t.

3 Likes

“Last status changed” - known by HA - would be sufficient.
My longest downtime of HA this year was 25 mins because of drive failure and getting it fixed.

If something would happened in those 25 mins, I could live with it anyway…

1 Like

That is an example of something that should be fixed so that you don’t need to restart.

In my opinion this is the worst ‘feature’ of HA. Every time I add a sensor/cover/switch/light or update then I lose valuable data.

For such a simple problem, it seems (from a non-programmer’s simple mind) like it should be a simple fix.

4 Likes

This has been rejected so many times, all i get is please read the documentation. Glad this is not just my problem.

4 Likes

As a workaround, you could use InfluxDB and retrieve the info from there instead of the entity itself?

It isn’t about workarounds which are possible to make (and influx isn’t very user-friendly either)
It’s more about how it’s perceived by many of us, but especially those who migrate from i.e. domoticz.

Looking at votes count I can see it’s not only few of us that have regular “WTH” moment regularrly :slight_smile:
I’m glad WTH happened.

3 Likes

It’s just as simple as having the wrong “last changed” time in the user interface:

If homeassistant “restarts” (and that is sometimes a lot: config changes, HACS updates, hass updates, state updates for some integrations (vera) not working anymore… the “secondaries” are all reset to:

xx seconds ago even while the light or motion might have been days ago for the last time. That is very confusing for a user.

User: Hey, WTH… we were away the weekend but the door and the lights were open this morning. OMG! Oh after investigating it was again a home assistant restart.

2 Likes

I fully agree with you and I think it could be great to just have the choice with an additional property “last_observed” or “last_saved” as proposed.

I reboot my HA instance too often (and indeed, it may be the real issue here) and I had cases in the past where my door was shown “open” after a reboot because the door was closed while HA was unavailable. There is no perfect solution.

The other part of the problem are the multiple restarts. Every two weeks if you update for all the minor releases of HA. And in my case, maybe 2 times per week because of the HACS custom_components that require a full restart. I think I would be happy in the end if it was possible to reload everything but HA itself without a restart.

Really interesting progress here:

I fully understand that making HA less need in terms of often restarts, but I’d really like not to see this issue/WTH connected together.
As I can imagine not restarting HA, there are still updates and still my example of people not being at my location for 3 months or sensors not updated since last winter are still valid. :slight_smile:

1 Like

That’s an important point. There are 3-4 updates per release every three weeks (including the main release), so you have to reboot in average once per week. If you are in beta channel you can at least double that.
Even with the many many new reload services coming soon (which I really love!) there are still a lot of reboots needed if you want to stay up to date.
In addition there will be still reboots needed for some config changes and adding/removing/updating custom_components.

1 Like

I’m curious what happened to this WTH? 198 votes, it seem clear a large number of users would like to see this implemented; however, the conversation seems to have gone cold.

Are there technical challenges in implementing this feature?

1 Like

No one said that WTH ideas will be implemented at all…

I clearly hope that maybe hacktoberfest or something soon will allow to add implementation for that.
Or at least add workaround for entities/domains that should track one more timestamp, keep it’s value during restart and be able to show it in UI (like ‘last-changed’ now).

2 Likes

Even if you acknowledge that it might be bad data because something could’ve happened while HA was off or rebooting, you also have to acknowledge that it’s almost always bad data to reset the last changed time on a reboot. If we’re not going to change it to preserve the data across reboots, it would still be an improvement to at least set it to a null value to be clear that the information is worthless.

For example, I have a view showing alarm and door lock status. There is an entity filter card that also shows any zones that are faulted. Because some faults are very intermittent while still triggering my alarm’s chime—like an outside gate opening and closing, or a glass break sensor momentarily triggering from a hammer’s noise when the system is disarmed—I also have it configured to show any zones that are now clear but that were faulted in the last two minutes. Whenever I restart, all my zones are shown on that card. If I’d wanted a longer interval like four hours or something, they would be shown there in error for an unacceptably long time.

5 Likes

I agree, this is a big issue. The previously mentioned vacation house a perfect example. I have a couple motion detectors in areas I rarely go in. I do not like seeing that someone tripped them 17 minutes ago when that is not true. I have smoke detectors hooked up to HA, and I don’t want to see last time triggered 32 minutes ago (the last reboot). I do not care about the issue of something being triggered while the system was off. There is nothing you can do in that case, so who cares.

The entities I want to see last activity on are exactly all my smoke detectors and motion detectors in areas I rarely go in. But that shouldn’t matter, this should be fixed for all entities, even a light switch I use dozens of times a day, perhaps it is important to some people to know when the last activity was for those too.

11 Likes

It seems like the cleanest solution here that would provide minimal disruption to those that disagree with persisting state through reboots would be to add a new last_known_changed attribute to entities and have it stored in the db on state change event. Then restore whatever value is there on start. This would leave the existing functionality intact but expose what everyone is asking for in a way that is clear and accessible. Seems like an easy win with minimal if any downside, so what is the resistance to such a solution?

9 Likes

This is also an important point for me.
That’s why I’ve created about 25 input_datetime to store real ‘latest state change’ value for 25 ‘important’ entities.
I also use custom lovelace card ‘custom:template-entity-row’ with custom secondary info line to display this input_datetime as a relative time.

2 Likes

Could you share the yaml?