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

That’s actually a pretty neat idea! If this WTH doesn’t manage to take off again this year I might just change my setup over, looks like it might cut down on a bit of code for me - but not as good as a inbuilt solution ofc!

Many veterans have been using this method for a very long time. I think I built this automation in 2016 with appdeamon, then switched it to HA automations sometime last year when I got rid of appdeamon.

1 Like

It’s certainly a good alternative and thanks for sharing although I don’t think it should detract from the main point of this WTH which is it shouldn’t be hard for even a brand new user to get this expected info onto their dashboard :smiley:

I just don’t think this topic is ever going to get anywhere until we start asking for something different. It’s clear that the last_changed and last_updated attributes will forever be driven by state changes inclusive of unknown and unavailable states.

What we need to start asking for is a new attribute that ignores unknown and unavailable state changes.

3 Likes

Hopefully that should be clear to the devs/anyone interested in developing this from the thread contents above. The title was more of a hook for people for people who think “yeah that is pretty annoying actually”.

Definitely agree about having a new attribute now though, seems like that’ll solve the devs concerns over the current unavailable states. I can’t see any disadvantages to a new attribute.

I can see why it would be a problem if there was no way to check when Home Assistant last started.

But overall, the current method has a much higher probability of being incorrect and constitutes a more risky assumption than letting last-changed survive a restart intact @frenck.

For many entities a last-changed value that survives a restart will still be correct. But assuming state changes upon a restart will almost be certainly incorrect for most entities.

Take this scanario: 13:00 window sensor switches to open, 13:15 Home assistant reboots, 13:30 user checks.

If the user is aware that Home Assistant restarted, the assumption that it would have missed any state changed during this time makes complete sense. A surviving last-changed state (13:00) is a correct assumption here, while 13:15 as last state change is counter intuitive and incorrect. It’s only intuitive to those who know how Home Assistant’s startup process works, which shouldn’t be a requirement for its correct usage.

I see three options for making this work better:

  1. If the state of a sensor is different after Home Assistant starts from when it shut down, make the assumption that the state changed upon start. If it is still the same, keep the last-changed time from before the start.
  2. In addition to 1: What could be considered is a time-limit. For example, if Home Assistant has been switched off for 2h, all last-changed values are reset.
  3. A function for templates that makes it easy to check whether the last state change was due to a restart.
  4. A function for templates that makes it easy when the last state change was, but lets the user decide whether to consider the “unavailable” state. For example: {{ last_changed('sensor.some_entity_id', 1) }} where the default is to consider all states, and 1 is “method 1”, which ignores unavailable.
2 Likes

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

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:

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!

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?

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

6 Likes

Thanks

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

1 Like

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

No, you make a sensor that stores the last_changed.

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

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?

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

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.

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