Persistent version of "last-changed" for the UI?

Archive Month of "What the heck?!" 2022
62

Finally got around to trying this… It’s probably obvious but what am I missing here? This creates the sensor fine, the automation publishes a timestamp to the mqtt sensor fine (I can see it under “state” in MQTT explorer) and I can see the state of the sensor in HA showing the timestamp. As soon as I add the timestamp device_class it breaks and changes to unknown in HA, if I remove it then it works but that means the ‘x minutes ago’ doesn’t work when I use it…

service: mqtt.publish
data:
  topic: homeassistant/sensor/office_balcony_door/config
  retain: true
  payload: |
    {
      "name": "Office balcony door",
      "unique_id": "office_balcony_door_mqtt",
      "state_topic": "homeassistant/sensor/office_balcony_door/state",
      "device_class": "timestamp"
    }

Automation sends:

payload: "{{ now().timestamp() }}"
63

{{ now().isoformat() }}

64

Also you need value_template: “{{ value }}” I think, on mobile so can’t check atm. Inside the config payload

65

You’re right, that sets the sensor perfectly now thanks! Although I’m not sure if it’s a limitation of “secondaryinfo-entity-row” but using {{ states.sensor.xyz.last_changed.isoformat() }} to set the secondary info just ends up printing the actual timestamp. Using the new sensor just as an entity shows it as “X mins ago”.

entity: binary_sensor.office_balcony_door_contact
type: custom:secondaryinfo-entity-row
secondary_info: '{{ states.sensor.office_balcony_door.last_changed.isoformat() }}'
66

It’s probably a limitation of the secondary_info row. You can use…

secondary_info: "{{ states('sensor.office_balcony_door') | as_datetime | relative_time }}"
1 Like
67

Made a simple version using a trigger based template sensor which stores the last change of all entities you list in the trigger.

template:
  - trigger:
      - platform: state
        entity_id:
          - input_boolean.test
        not_to:
          - unavailable
          - unknown
        not_from:
          - unavailable
          - unknown
    sensor:
      unique_id: dbf841e2-ae6f-4fc1-9534-a1046204945f
      name: Nominal Change History
      state: "OK"
      attributes:
        changes: >
          {% set current = this.attributes.get('changes', {}) %}
          {% set new = {trigger.entity_id: trigger.to_state.last_changed.isoformat()} %}
          {{ dict(current, **new) }}

To get it out as datetime, you need:

{{ state_attr('sensor.nominal_change_history', 'changes')['input_boolean.test'] | as_datetime }}
28 Likes
68

What is this wizardry! I’d just got the MQTT method working above but this is undoubtedly cleaner and easier to use so thanks!

I’ve not noticed much of a performance issue when using the data in the UI for 15 or so entities so hopefully that doesn’t slow down as more are added vs just using an entity directly. Sadly using it with the secondary-info component breaks the “state-color” attribute but that’s not too a compromise.

Fingers crossed the main issue is solved in this years WTH as this is still not very user centric but glad it’s manually possible at least!

69

There is already a topic for this
https://community.home-assistant.io/t/scenes-created-with-scene-create-to-survive-a-restart/471215

70

I didn’t think that a template sensor stored its value across a reboot. It that the case that it does?

71

I set it up for all my sensors earlier and several HA reboots today still persist the values.

72

Trigger template sensors persist across restarts. Normal (non-trigger) template sensors do not. From here:

The state, including attributes, of trigger-based sensors and binary sensors is restored when Home Assistant is restarted. The state of other trigger-based template entities is not restored.

1 Like
73

There is a risk though when it triggers before the attributes are restored.

1 Like
74

Thanks! I missed that when reading the docs.

75

I believe this WTH will be easier to fix if this is fixed first:

WTH, how can I know when the last (unchanged) sensor value was received? - Month of “What the heck?!” - Home Assistant Community (home-assistant.io)

76

I get the reasoning behind why this doesn’t already exist, but some things don’t always gotta follow logic IMO. Even if the devs don’t agree with persisting the “last_changed” value between restarts at least give us the user to make the decision for ourselves.

I regret restarting HA bc it resets all my sensors “last_changed” state and looks a bit backwards when my garages say they were last opened a few minutes ago or my smoke detectors say last tripped a few minters ago (I know that’s not what last_changed means but to the user it kinda is misleading).

Giving the user the option to allow the persistence of the last_changed value is a win win for both sides.

Also this should extend to sensor states as well since the reasoning behind not having sensor states persist through restarts is the same.

3 Likes
77

I’ll probably end up re-raising it next year for a 3rd year running I guess.

3 Likes
78

There needs to be some solution to this problem, hopefully the Dev team take this into serious reconsideration since each time its brought up there are hundreds of votes.

79

So then restore the last_changed from what it was before restart, and also set last_updated to when the actual data was received from the sensor, so we would know how old the state is.

Home assistant is awesome, it has so many advanced features that took a long time to implement. And I think it is ridiculous that this kind of issue is still there, and not being treated seriously.

4 Likes
80

It is a bit disheartening seeing this exact same topic raise hundreds of votes each WTH (showing regardless of an individuals view on it - it’s overall something people obviously want) and to then not see any solutions coming out of it but to be fair the devs do say a high vote count doesn’t mean something will be done so can’t complain too much on that front - the ones voted higher probably interest me more to be fair!

Whilst not ideal… for now the solution above from TheFes with the template seems to be doing the trick for me. Had it setup for a few weeks now and it’s very helpful being able to comfortably restart again! Not that user friendly but it works!

6 Likes
81

Haven’t tried that solution yet, but I have upwards of 40 sensors that I would want to retain the last_changed state it would take a while to set up. Maybe I will create a new thread so anyone can reference it in the future