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

Month of "What the heck?!"
47

I really think only point 1 is needed. A comparison of the startup state object to the last shutdown state object. Anything that’s different (main state, & attributes) will cause the startup state to be honored over the shutdown state. Make this the default and couple that with an option to have this functionality disabled per entity.

4 Likes
48

There’s another issue I haven’t seen mentioned here with the last updated/changed: forced updates.

I was made aware of this when I reported an issue with the new live logbook (since fixed). Logbook entries were being created even when the state value was not actually difference.

It turns out that states can be force updated which ends up changing the last updated/changed time even when the value is not actually different. Perhaps a HA dev can clarify if I’m off with the technical details of this explanation.

Here is the issue for anyone curious:

49

I tried to find this generic solution on the forum but no luck. If by any chance you may know where this example is, it would be very helpful to share it, thanks!

50

I was hoping 123 would link it because I don’t have his posts memorized. @123, sorry for pinging you, but do you have an example post where you explained how to create MQTT discovery and a sensor with an automation?

51

Thanks. In the meantime, I found two related posts:

52
6 Likes
54

Thanks

55

Thanks a lot. The device creation is really the icing on the cake. I wished I knew this earlier. :heart_eyes:

1 Like
56

I’ve read the thread but I think I’m still missing something. I understand you can make a MQTT Discovery “device” which can mirror your sensor. Then you have an automation that updates the MQTT device when the real device changes to on/off? From that I could just use that new fake MQTT device on the dashboard instead and the last-changed attrib would always be only from on/off. The problem there is what happens when the device actually becomes unavailable? It wouldn’t show that on the dashboard then would it?

1 Like
57

No, you make a sensor that stores the last_changed.

No, you don’t store the state, you store the last_changed

58

Ah okay, in that case what’s the benefit over just using a helper to store that…? Wouldn’t you still need something like the “secondaryinfo-entity-row” custom UI component to show that under the entity on the dashboard too?

59

It can’t be modified. Your automation creates it for you instead of you manually creating it. So you setup the automations and you’re done. Instead of: Create helper, Create automation, hide helper from ui, etc.

Yep

60

Just to confirm…

A script that will create a mqtt discovery sensor for each device to track. That will contain the last_changed attribute. This only needs to be ran once to initially create them.

One automation with triggers for each sensor changing from on/off. That will publish the current time to the relevant mqtt sensor.

Display the sensor as normal in the UI but use secondaryinfo-entity-row to show the new “last_changed” from the mqtt sensor.

61

Yep, or you can just manually create the MQTT sensor in configuration.yaml. I prefer the automation because you can write an automation that loops multiple sensors for you with a repeat. Then you only have 1 configuration.

Yep

Yes. If you want to view it as ‘x minutes ago’, you need to make it a device_class: timestamp and the format of the time should be .isoformat(). e.g. {{ states.sensor.xyz.last_changed.isoformat() }} or from a trigger… {{ trigger.to_state.last_changed.isoformat() }}

1 Like
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