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

[burg93 (Adam)]

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!

[petro]

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.

[burg93 (Adam)]

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

[mekaneck (Rick Auch)]

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.

[burg93 (Adam)]

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.

[ilovezigbee (Teun)]

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.

[petro]

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.

[scottg489 (Scott G.)]

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:

Logbook is reporting states that aren't changing. Upon page refresh these entries disappear from logbook history.

[Mincka]

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!

[petro]

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?

[Mincka]

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

How to create two sensors for last changed for a lock sensor which have two values

Just tried what you created and that’s what I see as well. I watched the timestamp continuously update itself. How about an automation, triggered by the lock’s state-changes, that writes the timestamp to an input-text? If you want the automation to write to a sensor, you’ll have to used a small python_script to do that. Alternately, if you’re already using MQTT, you can publish the timestamp to the topic of an MQTT Sensor. EDIT I just tested the MQTT suggestion and it works. Sensor - pla…

Post sensor values to MQTT

Correct. If you want to publish your RESTful sensor’s state to an MQTT topic, use an automation. - alias: 'Publish sensor value' trigger: platform: state entity_id: sensor.my_sensor action: service: mqtt.publish data_template: payload: "{{trigger.to_state.state}}" topic: whatever/topic/you/want If you want to publish the states of several sensors yet with only one automation, you could use something like this: - alias: 'Publish multiple sensor values' trigg…

[123 (Taras)]

Manually add MQTT Entities

1. Create an MQTT Light using a script Assuming you have an existing scripts.yaml file, paste this into it and save the file:

Click to reveal scripts

## MQTT Discovery Test example_create: alias: 'Example MQTT Light - Create' sequence: service: mqtt.publish data: topic: 'homeassistant/light/example/config' retain: true payload: > { "name": "Example", "unique_id": &quo…

Long setup time for MQTT integration

The following script (script.create_sensors) contains five service calls. Each service call is an mqtt.publish creating a sensor via MQTT Discovery. You can easily see all of the sensor information you provided is included in the payload of each mqtt.publish call. The payloads are published as retained messages which means they will be stored on the MQTT broker; their configuration information will be instantly available to Home Assistant on startup. You don’t have to run the script more than o…

[petro]

Thanks

[Mincka]

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

[burg93 (Adam)]

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?

[petro]

@burg93

I understand you can make a MQTT Discovery “device” which can mirror your sensor.

No, you make a sensor that stores the last_changed.

@burg93

Then you have an automation that updates the MQTT device when the real device changes to on/off?

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

[burg93 (Adam)]

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?

[petro]

@burg93

Ah okay, in that case what’s the benefit over just using a helper to store that…?

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.

@burg93

Wouldn’t you still need something like the “secondaryinfo-entity-row” custom UI component to show that under the entity on the dashboard too?

Yep

[burg93 (Adam)]

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.

[petro]

@burg93

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.

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.

@burg93

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

Yep

@burg93

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

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() }}