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.
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/
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
i have not made it till now, but the way to make sensor from db is
- platform: sql
db_url: !secret db_url
queries:
- name: Hassio Last Stop Date Time
query: "SELECT DATE_ADD(time_fired, INTERVAL 1 HOUR) as time_fired FROM events WHERE event_type = 'homeassistant_stop' ORDER BY event_id DESC LIMIT 1;"
column: 'time_fired'
+1 on this issue. I’m sure it’ll be resolved eventually but I’ve found a pretty decent workaround for now for those few entities you want to save between reboots. For me, it’s the time since I last toggled the input boolean for replacing my cat’s litter box.
var.time_sift only updates when the boolean changes, which it doesn’t between HA reboots.
Then just make a template sensor that compares the two.
configuration.yaml
sensor:
-platform: template
sensors:
time_since_last_sift:
friendly_name: Time Since Last Sift
entity_id: sensor.time
value_template: >-
{% set time = ((as_timestamp(now()) - as_timestamp(states.var.time_sift.state))) | round(0) %}
{% set minutes = ((time % 3600) / 60) | int %}
{% set hours = ((time % 86400) / 3600) | int %}
{% set days = (time / 86400) | int %}
{%- if time < 60 -%}
Less than a minute
{%- else -%}
{%- if days > 0 -%}
{%- if days == 1 -%}
1 day
{%- else -%}
{{ days }} days
{%- endif -%}
{%- endif -%}
{%- if hours > 0 -%}
{%- if days > 0 -%}
{{ ', ' }}
{%- endif -%}
{%- if hours == 1 -%}
1 hour
{%- else -%}
{{ hours }} hours
{%- endif -%}
{%- endif -%}
{%- if minutes > 0 -%}
{%- if days > 0 or hours > 0 -%}
{{ ', ' }}
{%- endif -%}
{%- if minutes == 1 -%}
1 minute
{%- else -%}
{{ minutes }} minutes
{%- endif -%}
{%- endif -%}
{%- endif -%}
This seems to work for me and persists across HA reboots. I also have an automation that just turns the input boolean back off as soon as it gets turned on.
I still don’t get how this still could be an issue.
Facts:
HA needs to be rebooted weekly to keep up with latest updates
Yo need to reload the configuration (=restart) EVERY TIME you do anything which is not possible to do in the GUI, like basic stuff of adding a template sensor, a light group, etc. My average is around 30 restarts per day if I am actually working with HA.
Reasons for not making the last changed timestamp persistent mentioned:
You don’t need to restart, why do you keep restarting so often? Voided by facts above
Something could have happened while HA restarts!
So what!? Then you have a last_changed which is 99% accurate (in case something happened during the 30s downtime during restart). It is better to have something that is 99% accurate than having something that is guaranteed 100% wrong!. I mean, saying it changed because of reboot is always wrong; no doors are opening because HA restarts!
something might change during startup Same argument as previous point.
Might break some existing logic Simple solution: simply introduce a last_changed_persistent attribute on all entities. Nothing will break.
If devs/admins are so sure that current behaviour of last_change is expected and wanted, simply introduce a last_changed_persistent attribute for all entities, wait a year, and see which attribute is used the most. I’m sure 99% of the community would prefer the last_changed_persistent one.
I mean, come on! I see 30+ row code solutions per entity above in this thread. Per entity. And to code all of that, you would need to restart the HA once more to make it apply and each time you add anything or remove anything, causing even more restarts. Having a persistant last_changed attribute is what everyone expect! It should be the default one. Perhaps add a
reset_all_my_timestamps_all_the_time: true
in the config if you actually WANT the current confusing behaviour?
You can add template sensors and groups etc without restarting simply by using the reload buttons in the config GUI. You can’t add standard sensors, camera and a few other things. When I create new automations in YAML I simply hit the reload automations button, done.
I do however agree that HA should keep it’s last known state change info across restarts. Even if the data is partly inaccurate due to the state of some entity having changed while HA was offline, it would be better than nothing.
Which is also my point here. There are numerous of cases requiring you to do restarts all the time. And sometimes it is not super-clear what can be reloaded and what cannot; making me restart just to make sure… … and whoooops I had a water leak in the kitchen 2 min ago. Nahh, that was just HA restarting
I have more than thousand entities right now.
Creating few more just to handle this… Let’s say I’m not a fan of that solution and would drown with templates and inputs…
The question is : for how many entities do you really need this info ?
I have about 700 entities, and I’ve identified only about 20 of them for which I really need a reliable ‘last_changed’ info.
But I full agree this would be way better if it was built-in and if reboot did not loose this info.
I started to count really fast in my mind to answer and… 20 is only device trackers/persons I’d track. Not even starting with switches, entities or states of sensors that are seasonal (and only i.e. summer-related). It would take months for me to add every each of this and add sensors around it just to solve something that could be done by database extra column.
I know what you mean - I only need it on a few entities for automations to work properly, but I would much prefer it to work with every entity for informational purposes (especially lights, motion detection, etc).
Here for example I make extensive use of last-changed state for my lights - I restarted HA an hour ago but they certainly didn’t turn on/off at that time which is annoying. Whilst I don’t need it here for HA to function, I would very much prefer them to have correct values.
This has been my number one annoyance with HA since I started using it a couple of years ago. I restart now and again for HACS updates and it’s extremely annoying to see all my last-changed statuses reset on the dashboard. Especially for some of the security sensors which throw me off now and again.
I know I could create workarounds but it just adds a lot more complexity and convoluted code. It would be great to either set the current last-changed to not reset on startup in the settings (not sure if technically possible) or to have a new last-changed attribute that persists through restarts.
Every new release I hope something is done to combat this, hopefully one day it will as I’d imagine this is quite a common use case for a lot of consumers! I don’t believe in the “This isn’t too much of an issue if you don’t restart” argument as to the average consumer/user you’d look at an attribute called “last-changed” and would expect it to be the last time that sensor changed, not that it changed due to a restart. Finding a solution to that seems better than just hoping people don’t need to restart often imo.
