Finally got around to trying this… It’s probably obvious but what am I missing here? This creates the sensor fine, the automation publishes a timestamp to the mqtt sensor fine (I can see it under “state” in MQTT explorer) and I can see the state of the sensor in HA showing the timestamp. As soon as I add the timestamp device_class it breaks and changes to unknown in HA, if I remove it then it works but that means the ‘x minutes ago’ doesn’t work when I use it…
You’re right, that sets the sensor perfectly now thanks! Although I’m not sure if it’s a limitation of “secondaryinfo-entity-row” but using {{ states.sensor.xyz.last_changed.isoformat() }} to set the secondary info just ends up printing the actual timestamp. Using the new sensor just as an entity shows it as “X mins ago”.
What is this wizardry! I’d just got the MQTT method working above but this is undoubtedly cleaner and easier to use so thanks!
I’ve not noticed much of a performance issue when using the data in the UI for 15 or so entities so hopefully that doesn’t slow down as more are added vs just using an entity directly. Sadly using it with the secondary-info component breaks the “state-color” attribute but that’s not too a compromise.
Fingers crossed the main issue is solved in this years WTH as this is still not very user centric but glad it’s manually possible at least!
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.
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.
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.
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!
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