Binary Door Sensor: When State is on

I have several time stamp entities that record the time a particular sensor is updated. Here is the value template

value_template: "{{ as_timestamp(states.binary_sensor.aeotec_dsb29_doorwindow_sensor_2nd_edition_office.last_updated) | timestamp_custom('%a %b %d %H:%M:%S') }}"

This works except I want this date/time to survive a reboot. Currently the date and time is updated after each HA restart. Is this possible and how do I revise this template to capture an actual ON event rather than an update_event which occurs at each HA restart?

The issue is that the binary_sensor’s attribute is last_updated which, as you’ve discovered, isn’t the same as last_triggered.

Given that last_updated will refresh after Home Assistant restarts, I can’t see how a template can get around it. The template can only work with available data and a binary_sensor doesn’t have a last_triggered attribute.

I can’t think of an elegant way to do it, short of making an automation that triggers on any binary_sensor’s state-change and then stores the trigger-time … somewhere. :thinking:


Seems to me this might be a worthwhile Feature Request. last_triggered is a useful bit of information for binary_sensors used to detect opening/closing of doors, windows, etc.

you should be able to do so with the CC variable, and update the variable with each state change.

here’s what I do:

# Update Last Motion variable
  - alias: 'Update Last Motion'
    id: 'Update Last Motion'
    initial_state: 'on'
      platform: state
        - binary_sensor.laundry_motion_sensor
        - binary_sensor.dining_table_motion_sensor
        - binary_sensor.auditorium_motion_sensor
        - binary_sensor.frontdoor_motion_sensor
        - binary_sensor.corridor_motion_sensor
        - binary_sensor.corridor_terrace_motion_sensor
        - binary_sensor.master_bedroom_motion_sensor
        - binary_sensor.corridor_office_motion_sensor
        - binary_sensor.control_room_motion_sensor
        - binary_sensor.dorm_motion_sensor
        - binary_sensor.attic_motion_sensor
        - binary_sensor.poort_buiten_motion_sensor
      to: 'on'
      service: variable.set_variable
        variable: last_motion
        attributes_template: >
                "history_1": "{{ variable.state }}",
                "history_2": "{{ variable.attributes.history_1 }}",
                "history_3": "{{ variable.attributes.history_2 }}",
                "history_4": "{{ variable.attributes.history_3 }}",
                "history_5": "{{ variable.attributes.history_4 }}",
                "history_6": "{{ variable.attributes.history_5 }}",
                "history_7": "{{ variable.attributes.history_6 }}",
                "history_8": "{{ variable.attributes.history_7 }}",
                "history_9": "{{ variable.attributes.history_8 }}",
                "history_10": "{{ variable.attributes.history_9 }}"
        value: >
          {{ trigger.to_state.attributes.friendly_name|replace('motion sensor','') }}:
          {{as_timestamp(states.variable.last_motion.last_changed)| timestamp_custom('%X') }}


    value: 'Not set'
    restore: true
      icon: mdi:map-marker
      name: 'Last Motion'


1 Like

Yep, like I said, somewhere, meaning a whole pile of additional infrastructure (in this example, automation and a custom component) to save an attribute that, arguably, ought to be part of binary_sensor.

FWIW, in the home automation software I’ve used for over a decade, “LastTimeTriggered” is a standard property (attribute) of a DoorSensor (binary_sensor).


I’m already using a python script for this.

I thought I found a solution in this post by @pnbruckner

However, when I tried it (after restarting), both last_updated and last_changed were identical.

Try it and see what you get:

{{states.binary_sensor.aeotec_dsb29_doorwindow_sensor_2nd_edition_office.last_updated }}
{{states.binary_sensor.aeotec_dsb29_doorwindow_sensor_2nd_edition_office.last_changed }}


After reading VDRainer’s post (above), obviously my ‘discovery’ was something already well known, namely last_changed = last_updated after a restart. Clearly, you have to store the attribute somewhere (to survive the restart) and VDRainer’s solution is yet another way to do it (i.e. with a python script into a database).

Not sure it’s worthwhile to add a Feature Request because this is just one small part of the much larger issue of Home Assistant lacking a system-wide persistence feature. FWIW, I used openHAB for a few months and it has persistence that, in its most basic form, can store and restore entity states. My long-used home automation software (Premise) can do this as well. Without it, you’re obliged to improvise with a custom persistence solution (as demonstrated by the two examples above).


Though I agree we would need the persistence feature natively in HA, I am not sure I understand what you mean in your first reply indicating the difference between last_updated and last_triggered. I think in HA language triggered is only applicable for automations, and last_updated or _changed would be identical in the case of binary_sensors?

You’re right, in Home Assistant the word ‘trigger’ is associated with automations. So when I used the term last_triggered for a binary_sensor, that was an incorrect use of Home Assistant’s terminology. I should’ve used last_changed when referring to the time of a binary_sensor’s last state-change.

FWIW, I have years of experience with Premise and sometimes its terminology seeps into the words I use to describe Home Assistant’s operations. As you can see in the screenshot above, in Premise the term is LastTimeTriggered … and that stuck in my mind when I wrote about Home Assistant’s binary_sensor.