A state (timestamp) that is not affected by HA restarts?

Running a template here that uses stuff like:

{{ states.person.X.last_changed }}

This makes it possible to see when someone was last at home.

However, on HA restart this is reset to that startup time.

Any way to prevent it? Is there a persistent attribute?

In addition, device_tracker resets on startup too. How to prevent?

(Using input_text could be a workaround but also a lot of work.)

I have an issue with that last sentence!

There’s a python script lower down in the thread that should do what you want.

As you’ve discovered last_changed and last_updated aren’t persistent (survive a restart) but are re-initialized after every restart.

Given the manner in which most people want to use those two properties, re-initialization throws a wrench into their plans. The workaround is to ‘persist’ them elsewhere as per the link tom_I posted.

Thanks. Yeah, that guy often barely can relate to use cases except his own.
So at this moment the choice is either to switch to MySQL and use the script or use input_text’s and if possible (guess not) write those saved timestamps back after restart.

1 Like

I store these timestamps in an input_datetime for this purpose - and use them straight from there for automations, etc.

As you can see below, I have a binary_sensor for the door and an input_datetime with the same name + “_last_opened” - this allows me to use a relatively simple template for all sensors of the same kind.

- alias: Last Door Opened Date and Time
  trigger:
    platform: state
    entity_id: binary_sensor.front_door, binary_sensor.back_door, binary_sensor.balcony_door, binary_sensor.downstairs_door, binary_sensor.living_room_motion
    from: 'off'
    to: 'on'
  action:
    - service: input_datetime.set_datetime
      data_template:
        entity_id: input_datetime.{{ trigger.entity_id[14:] }}_last_opened
        time: '{{ (as_timestamp(now()) | timestamp_custom("%H:%M:%S", true)) }}'
        date: '{{ (as_timestamp(now()) | timestamp_custom("%Y-%m-%d", true)) }}'
7 Likes

https://github.com/home-assistant/architecture/issues/230

Hi, this looks like what I’m searching for but not sure how to use it.
I have replaced the enties to my own and the automation is triggered.
I have checked developer page and tried to find last_opened data but can’t see any data. How do I present the last_opened for the entity?
I tried {{ states.binary_sensor['maindoor'].last_opened }}
I’m also curious what [14:] stands for?
Thanks

lol… really? HA still must be restarted to apply most updates and configuration changes.
BTW which dev is responsible for such approach?

That quote was from none other than our glorious leader.

It makes it even more sad.

Here i was thinking i was the only one that restarts at MOST every couple of days, and sometimes 15 times in an hour :slight_smile:

1 Like

It is python’s notation for slicing a string. It means to take a slice of the string starting at index position 14 to the end.

Given the following string, [14:] will return front_door

binary_sensor.front_door
012345678911111111112222
          01234567890123

For future reference, an entity_id is composed of a domain and an object_id. Therefore binary_sensor is the domain and front_door is the object_id. We can use that information to modify the template so that it accesses the object_id directly instead of slicing it from the entity_id:

  action:
    - service: input_datetime.set_datetime
      data_template:
        entity_id: input_datetime.{{ trigger.to_state.object_id }}_last_opened
        time: '{{ (as_timestamp(now()) | timestamp_custom("%H:%M:%S", true)) }}'
        date: '{{ (as_timestamp(now()) | timestamp_custom("%Y-%m-%d", true)) }}'

In addition, there are other ways to display the current date and time:

We can use that information to streamline the rest of the template:

  action:
    - service: input_datetime.set_datetime
      data_template:
        entity_id: input_datetime.{{ trigger.to_state.object_id }}_last_opened
        datetime: '{{ now().timestamp() | timestamp_local }}'

The solution chairstacker has presented relies on the fact that for every binary_sensor you have, you must also manually define an associated input_datetime entity.

So if you have defined this entity:

binary_sensor.front_door

you must also define this entity:

input_datetime.front_door_last_opened
1 Like

And concerning tbh, but that was 3 years ago and allegedly he’s a bit more connected to reality now :man_shrugging:

2 Likes

Thank you very much.
I will spend some time in the weekend to test.
So if I add an include file input_datetime.yaml with below configuration?


 front_door_last_opened:
   name: Front door last opened
    has_date: true
    has_time: true

For those still battling this issue, please have a look at the feature request: Retain last state change data of a sensor after reboot

Until then this custom component GitHub - PiotrMachowski/Home-Assistant-custom-components-Saver: This custom component allows you to save current state of any entity and use its data later to restore it. did the job for me.

@fabs Any chance you could post or point me to a complete example of using the custom component saver to save the last_changed or last_updated attributes? I haven’t been able to get that working. Thanks.

I have my system using this component only. Can you show what is not working? Do you have an error message?

As an example, I’m trying to save the state of a binary_sensor from my alarm panel and restore both the state and the last_modified and last_updated times. After a restart, the sensor is “unknown” until it’s toggled and the times are the restart times. But there is no service call to change the state of the sensor so how does the restore action of the saver component work? I started writing this and got stuck with how to implement the restore portion. I also looked through the saver code and don’t see anywhere that it would actually be able to update the last_modified and last_updated times of a state in the state machine.

In my automations.yaml:

- id: saver_save
  - service: saver.save_state
    data:
      entity_id: binary_sensor.front_door

- id: saver_load
  - service: saver.restore_state
    data:
      entity_id: binary_sensor.front_door
      restore_script:
        - service:  ???

What I do is: everytime my entitiy changes, I save the state like your example. In my case with an automation. This can also be done with a template sensor.

service: saver.save_state
data:
entity_id: device_tracker.ford_focus

What I do to restore my entity data is running an automation on HA start with the trigger ‘Home Assistant start’ as part of a some other inititialization steps:

service: device_tracker.see
data:
dev_id: Ford_Focus
gps: >-
({{
state_attr(‘saver.saver’,‘entities’)[‘device_tracker.ford_focus’].attributes.latitude
}},
{{ state_attr(‘saver.saver’, ‘entities’)[‘device_tracker.ford_focus’].attributes.longitude }})