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 
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.
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?
One for instance looks like this :
input_datetime:
mouvement_maison_last_changed:
has_date: true
has_time: true
sensor:
- platform: template
mouvement_maison_last_changed_template:
value_template: "{{states('sensor.time') and relative_time(strptime(states.input_datetime.mouvement_maison_last_changed.state[:19], '%Y-%m-%d %H:%M:%S'))|replace('hour', 'heure')|replace('day', 'jour')}}"
You can have a way simpler template if you don’t need translations.
The template could maybe also be simplified with the recent changes to template with time functions but I did not had time to check. It works like this for the moment.
And I also have a very small NodeRed flow to update the input_datetime with the current timestamp on each ‘group.mouvement_maison’ value change to ‘on’ or ‘off’.
It’s probably easy using HA Automotion instead of NodeRed but I don’t know anything about it.
3 Likes
Hi, Guys,
i also would like to vote for this problem! It is terrible and seems light to fix.
Where do i need to vote for fixing it?
Haha
Guys is there a way to use for exmaple some DB as mysql or some other. I have read about infulxbd, but is it really solutuion?
It seems that i have found i relative simple way to get that, what we all here need with stock db and with no need to create other entities. Is is also not direct way, but it looks nic to me/
Here is stock db:
If you look to column old_state_id you can see that sometimes it has NULL value an sometimes - old id value. So if i right - everything with NULL are restarts!
So у can make a simple SQL (with Node Red or with Automation or even create a new sensor with platform: sql) to get what you need!
Select will look like this for my case:
SELECT last_changed
FROM "states"
WHERE entity_id = 'input_boolean.vacuum_auto_mode'
AND old_state_id !='NULL'
ORDER BY state_id DESC LIMIT 1
What do you think about it?
what about mariadb users ?
also can you please share your node/automation/sensor config