Input_datetime not persisting after HA restart

After reading about the reasons why a sensor’s .last_changed attribute does not persist between HA restarts… I have attempted to start storing last changed information on a handful of sensors in input_datetimes instead.

I have some template sensors that check the last_changed time on motion/door sensors, and they get thrown off after a restart because the last_changed gets reset.

However, I am basically having the same issue with the input_datetimes.

This is my automation. The trigger should be on every state change in the list of IDs, with a condition to stop “unknown”.


  - alias: Store Last Changed
    mode: parallel
      platform: state
        - binary_sensor.door_front
        - binary_sensor.door_back
        - binary_sensor.door_garage
        - binary_sensor.door_studio
      condition: template
      value_template: '{{ trigger.to_state.state != "unknown" }}'
      - service: input_datetime.set_datetime
          entity_id: >-
            input_datetime.{{ trigger.entity_id.split('.')[1] }}_last_changed
          time: '{{ (as_timestamp(now()) | timestamp_custom("%H:%M:%S", true)) }}'
          date: '{{ (as_timestamp(now()) | timestamp_custom("%Y-%m-%d", true)) }}'

I have an input_datetime for each sensor with the same name + _last_changed:

    name: Last changed
    has_date: true
    has_time: true

Everything here works great. The proper input_datetime gets updated reliably each time it’s corresponding door opens.

However, if I reboot HA, I check the state of the input_datetime, and it’s back to “1970-01-01 00:00:00” until the sensor changes state again.

It is possible that this also only happening when HA is restarted “shortly” after the state change (within 10 minutes or so)

Some of the datetimes do survive the restart.

I also notice that on the binary_sensor, the “timestamp” attribute also reverts back to a previous timestamp.

Is there some kind of interval that HA backs up the states of the sensors for restoration after restart?

I would think that it would save the state during the restart command regardless of how long it’s been, but that seems to be the only thing I can think of that would cause what I am experiencing.

In the end, all I am seeking is a way to have persistent “last_changed” data for some of my sensors that survives a restart. I am baffled by how difficult it has been to accomplish such a seemingly simple task.

Anyone have any ideas here? I am open to experimentation, it’s just not going well so far and this method seems to be causing new issues. I don’t love how many extra sensors, templates, and automations I have to make, and how easily the data can drift.


Just guessing, but have you excluded the input_datetime(s) from the recorder?

Nope! Nothing is excluded:

  db_url: !secret mariadb_db_url
  purge_keep_days: 7

Since the first post, I triggered binary_sensor.door_studio, which successfully updated input_datetime.door_studio_last_changed to ‘2020-09-24 16:45:31’.

I waited 1 hour, and then restarted HA, and this time, it persisted.

Just now, I triggered binary_sensor.door_front, which successfully updated input_datetime.door_front_last_updated to ‘2020-09-24 18:18:10’.

This time, I restarted HA after 2 minutes.

When it came back up, input_datetime.door_front_last_updated was immediately set to ‘1970-01-01 00:00:00’, but input_datetime.door_studio_last_changed still remains set to ‘2020-09-24 16:45:31’.

So there definitely seems to be some kind of interval in which these state changes actually get “saved”.

On a normal day, I’m not restarting HA all the time. But regardless, it happens from time to time, and it seems that any state changes in the minutes leading up to the restart are not recorded or something.

Maybe I’m going about this the wrong way.

I know there are other threads regarding the last_changed attribute, but I haven’t found a definite solution to reliably referencing a last_changed time between restarts.

THere is an issue about that with other input_* entities also. It’s closed now but I don’t think it should be if you are on 115 and experiencing the same thing.

I think the storage gets updated about every 15 minutes. If you wait longer than that it should store the state then restore the state on restart. If less than that then the state is lost.

At least it sounds like the same thing.

1 Like

Somebody else talked about a similar issue, and it looks like they did open an issue. I’d suggest you add your details to that one, since the only reason the state shouldn’t restore is if you defined initial.

1 Like

Thanks for the replies. I’ll check in with the github issue!

Good to know it’s not just me. Seems like it might just be bad timing that I started doing this after the 115 update. I didn’t have any datetimes at all prior to this.