Been adding quite a few buttons in the Lovelace setup using the last_changed, I now notice I never worried about the fact the alls Switches last_changed are always reset at startup. Isn’t this peculiar? I’ve set switch in both recorder and logbook to be included, and would love to see it survive restarts?
Am I missing a setting in the switch domain setup, or is this simply not possible (yet)…
AFAIK, that info surviving reboots is not possible. For all my setups that needed this info, I have switched to storing the info in either an input_text or variable (custom integration available via HACS). I have a templates automation that watches all of the switches and sensors I want to keep track of and updates the appropriate input_text or variable. Can share if requested (currently typing from mobile.)
Property vrs state attribute. It’s not possible because it’s just not built into the system. They’d have to build it into the serialize/deserialize methods. I honestly don’t know if that even happens, because it’s a state property, not an attribute.
this is how it is, @brahmafear have already said how to overcome it.
I store some of my times in input_datetime:
# this one just saves current time based on object_id, can work for any entity
# provided there is a corresponding input_datetime declared
- alias: "store sensor's triggered time"
trigger:
platform: state
to: 'on'
entity_id:
- binary_sensor.pir_ground_floor_hall
- binary_sensor.pir_ground_floor_reception
- binary_sensor.pir_ground_floor_lounge
- binary_sensor.pir_ground_floor_kitchen
- binary_sensor.pir_1st_floor_landing
- binary_sensor.pir_1st_floor_master_bedroom
- binary_sensor.pir_1st_floor_vasy_bedroom
- binary_sensor.smoke_detector_ground_floor_hall
- binary_sensor.smoke_detector_1st_floor_landing
action:
service: input_datetime.set_datetime
data_template:
entity_id: input_datetime.{{trigger.to_state.object_id}}
datetime: '{{ now().strftime("%Y-%m-%d %H:%M:%S") }}'
Then I display the data as secondary in template-entity-card using some relative_time trickery
I do something very, very similar to @AhmadK but use a custom component “hass-variable” that allows me to also store arbitrary attribute data. In the case below, I have several motion sensors. The variable component keeps track of the time of the 4 most recent trigger times for each one as well as a single variable that tracks the last 4 places where motion occurred. This persists across HA restarts. The custom component is available at the web address below and can be installed via HACS.
## https://github.com/rogro82/hass-variables
variable:
last_motion_location:
value: 'None'
restore: true
last_motion_time:
value: 'None'
restore: true
last_alarm_location:
value: 'None'
restore: true
last_alarm_time:
value: 'None'
restore: true
last_living_room_51_20:
value: 'Never'
restore: true
last_kitchen_52_20:
value: 'Never'
restore: true
last_bedroom_53_20:
value: 'Never'
restore: true
last_office_56_20:
value: 'Never'
restore: true
last_garage_57_20:
value: 'Never'
restore: true
last_porch_54_20:
value: 'Never'
restore: true
last_guestroom_55_20:
value: 'Never'
restore: true
last_baby_58_20:
value: 'Never'
restore: true
last_living_room_occupancy:
value: 'Never'
restore: true
last_kitchen_occupancy:
value: 'Never'
restore: true
last_bedroom_occupancy:
value: 'Never'
restore: true
last_guest_room_occupancy:
value: 'Never'
restore: true
last_office_occupancy:
value: 'Never'
restore: true
last_dining_occupancy:
value: 'Never'
restore: true
automation:
- alias: "Motion Update"
trigger:
- platform: state
entity_id: binary_sensor.living_room_51_20
to: 'on'
- platform: state
entity_id: binary_sensor.kitchen_52_20
to: 'on'
- platform: state
entity_id: binary_sensor.bedroom_53_20
to: 'on'
- platform: state
entity_id: binary_sensor.porch_54_20
to: 'on'
- platform: state
entity_id: binary_sensor.guestroom_55_20
to: 'on'
- platform: state
entity_id: binary_sensor.office_56_20
to: 'on'
- platform: state
entity_id: binary_sensor.garage_57_20
to: 'on'
- platform: state
entity_id: binary_sensor.baby_58_20
to: 'on'
- platform: state
entity_id: binary_sensor.living_room_occupancy
to: 'on'
- platform: state
entity_id: binary_sensor.bedroom_occupancy
to: 'on'
- platform: state
entity_id: binary_sensor.kitchen_occupancy
to: 'on'
- platform: state
entity_id: binary_sensor.guest_room_occupancy
to: 'on'
- platform: state
entity_id: binary_sensor.office_occupancy
to: 'on'
- platform: state
entity_id: binary_sensor.dining_occupancy
to: 'on'
# - platform: state
# entity_id: binary_sensor.door_81_1
# to: 'on'
# - platform: state
# entity_id: binary_sensor.door_82_1
# to: 'on'
# - platform: state
# entity_id: binary_sensor.porch_54_44
# to: 'on'
action:
- service: variable.set_variable
data_template:
variable: '{{ "last_" + trigger.entity_id.split(".")[1] }}'
value: '{{ as_timestamp(now()) | timestamp_custom("%b %d %-I:%M %p") }}'
attributes_template: >
{
"history_1": "{{ states('variable.last_' + trigger.entity_id.split('.')[1]) }}",
"history_2": "{{ state_attr('variable.last_' + trigger.entity_id.split('.')[1],'history_1') }}",
"history_3": "{{ state_attr('variable.last_' + trigger.entity_id.split('.')[1],'history_2') }}"
}
- service: variable.set_variable
data_template:
variable: 'last_motion_location'
value: '{{ trigger.to_state.attributes.friendly_name }} @ {{ as_timestamp(now()) | timestamp_custom("%b %d %-I:%M %p") }}'
attributes_template: >
{
"entity_id": "{{ trigger.entity_id }}",
"friendly_name": "{{ trigger.to_state.attributes.friendly_name }}",
"time": "{{ as_timestamp(now()) | timestamp_custom('%b %d %-I:%M %p') }}",
"history_1": "{{ states('variable.last_motion_location') }}",
"history_2": "{{ state_attr('variable.last_motion_location','history_1') }}",
"history_3": "{{ state_attr('variable.last_motion_location','history_2') }}"
}
btw, it’s possible to combine entity_ids in a list if they’re all change to the same (on or whatever)
makes code shorter and easier.
not generally supported though
I noticed that about your config. I would be a little worried about that being suddenly marked as an error in an upcoming version - but nice to know it works now.
that looks mighty awesome, would have hoped this to be easier, in core…
yep, I use that too, but hadn’t thought to do so recording the last_changed of switches globally yet. this will burden the system probably, so id better be careful. thanks anyways!
Uses the hass-variables custom component to store the information. Keeps track of the last 4 times the binary sensors are activated. The entity_ids of the variables must be the same as the binary sensor with “last_” prefixed - this allows the template to work. So for sensor ‘binary_sensor.living_room_51_20’, the required variables is ‘variable.last_living_room_51_20’.
There’s also logic to track which of a group of sensors is the last to be activated - ie, the last door opened.