I didn’t think that a template sensor stored its value across a reboot. It that the case that it does?
I set it up for all my sensors earlier and several HA reboots today still persist the values.
Trigger template sensors persist across restarts. Normal (non-trigger) template sensors do not. From here:
The state, including attributes, of trigger-based sensors and binary sensors is restored when Home Assistant is restarted. The state of other trigger-based template entities is not restored.
1 Like
There is a risk though when it triggers before the attributes are restored.
1 Like
Thanks! I missed that when reading the docs.
I believe this WTH will be easier to fix if this is fixed first:
I get the reasoning behind why this doesn’t already exist, but some things don’t always gotta follow logic IMO. Even if the devs don’t agree with persisting the “last_changed” value between restarts at least give us the user to make the decision for ourselves.
I regret restarting HA bc it resets all my sensors “last_changed” state and looks a bit backwards when my garages say they were last opened a few minutes ago or my smoke detectors say last tripped a few minters ago (I know that’s not what last_changed means but to the user it kinda is misleading).
Giving the user the option to allow the persistence of the last_changed value is a win win for both sides.
Also this should extend to sensor states as well since the reasoning behind not having sensor states persist through restarts is the same.
3 Likes
I’ll probably end up re-raising it next year for a 3rd year running I guess.
2 Likes
There needs to be some solution to this problem, hopefully the Dev team take this into serious reconsideration since each time its brought up there are hundreds of votes.
So then restore the last_changed from what it was before restart, and also set last_updated to when the actual data was received from the sensor, so we would know how old the state is.
Home assistant is awesome, it has so many advanced features that took a long time to implement. And I think it is ridiculous that this kind of issue is still there, and not being treated seriously.
4 Likes
It is a bit disheartening seeing this exact same topic raise hundreds of votes each WTH (showing regardless of an individuals view on it - it’s overall something people obviously want) and to then not see any solutions coming out of it but to be fair the devs do say a high vote count doesn’t mean something will be done so can’t complain too much on that front - the ones voted higher probably interest me more to be fair!
Whilst not ideal… for now the solution above from TheFes with the template seems to be doing the trick for me. Had it setup for a few weeks now and it’s very helpful being able to comfortably restart again! Not that user friendly but it works!
5 Likes
Haven’t tried that solution yet, but I have upwards of 40 sensors that I would want to retain the last_changed state it would take a while to set up. Maybe I will create a new thread so anyone can reference it in the future
I see this got more votes than some other things that made the newsletter. 
I’m sure it’s coming next month! What’s the point in asking for pain points otherwise eh!
Jokes aside I think the newsletter said things were to come so fingers crossed.
I mean, its all the public repo. I assume that if the change was submitted and accepted, someone would come by here and tell us about it. That’s my hope anyway. 
edit: And seems unlikely since @frenck seems fine with HA essentially providing incorrect device information.
1 Like
For every WTH task there are multiple things to consider:
- Number of votes
- Time it takes to make it
- Is it backwards compatible
- Is it a building block to something that was already desired by devs/community
- etc. (definitely others)
Votes are important but the things that are going to get done first are primarily going to be quick wins. These are backwards compatible things that either take very little time to make or we’re already partially complete.
This may have high votes but its not quick. It requires planning. And probably an adr since the only way to do it in a backwards compatible way is to add to the core state model.
I totally understand that it probably is a lot of work. I promise that I’m not (intentionally) bitching from the cheap seats. My point really was that if something was going to happen, it seems like us in the cheap seats probably would have heard about it by now. 
@frenck What are the potential drawbacks of making this assumption?
Isn’t HA already making assumptions all the time? If a sensor updates once a minute, isn’t HA technically assuming it’s state between updates? Even if a sensor is pushing state to HA, isn’t HA assuming state in between those pushes?
It seems more practical to approach it from a usability perspective. Being “technically corrent” here and setting the state to something at intervals and then immediately to unavailable/unknown wouldn’t be very usable. So we have these attributes (changed/updated_at) to let us know this information instead.
HA going down for a reboot and coming back up doesn’t seem any different to me than a gap in a sensor update that would happen naturally. To me it draws parallels with null. It’s not unknown, it’s not unavailable, it’s nothing (null), so nothing should change.
However, perhaps there is something I’m not considering in the reverse case. So to reiterate my original question - What are the potential usability drawbacks of having sensors not report as unavailable during downtime?
3 Likes
I mean posts from the original WTH section were still referenced in PRs occaisionally all the way up to when this one started. Just because nothing was started within the month of WTH does not mean it won’t be done.
There are 3000 contributors to HA, if one of them decides its super important to them and they have the time it could be done next week (very unlikely, I think this is harder then that but people can be surprising when they really put their mind to something). Or it may not be started for a year. Or it may never happen. There’s really no way to tell.
I can only say it won’t be ignored. People go back to the WTH posts a lot as support for PRs and changes and this is high up there in the votes.
1 Like
I’m pretty sure I recall reading about at least one PR to fix this issue being shot down. While its of course still possible, it seems unlikely. I’ll remain hopeful though!