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

Month of "What the heck?!"
98

I’ve been using the solution posted @TheFes for a few days successfully (thank you!), however I’ve noticed the following error message in Studio Code Server:

image

I believe this has only started showing since updating to 2023.5.3 and Studio Code Server 5.6.0

99

Just ignore it.

101

Maybe we should raise an all new WTH for a solution.

What about adding two attributes to the sensors;

  • last_time_on
  • last_time_off

which could be used for doors, alarms and everything with an on/off behaviour.

102

Does this line needs to be below the template sensor?

{{ state_attr(‘sensor.nominal_change_history’, ‘changes’)[‘input_boolean.test’] | as_datetime }}

Or does it have an own template sensor? Hm I’m not sure how to implement it.
Thanks!

103

That line is how you get the data out of the template sensor again.
You can use it where you want, but if course that place needs to allow template sensors

104

What I meant; Do I need to put the line below the rest? like this

image
image883×402 17.8 KB

or do I need to create a seperate sensor, like this:

  - sensor:
      - name: "test"
        state: "{{ state_attr('sensor.nominal_change_history', 'changes')['input_boolean.test'] | as_datetime }}"

and when I have multiple entities, I need to put it here twice right?

image
image879×434 19.1 KB

105

It’s not part of the template to store the data, so you should not put it in that template sensor.

You should put it where you want to use the stored datetime, which can be anywhere where usage of templates is allowed

1 Like
106

Hm do you have an example? I’ve tried this one but the sensor is telling me unknown.

  - platform: template
    sensors:
      lastchangedsomfybadkamer:
        friendly_name: "Last changed SomfyBadkamer"
        value_template: >-
          state: "{{ state_attr('sensor.nominal_change_history', 'changes')['cover.somfybadkamer'] | as_datetime }}"

or is an input number (helper) a better way?

108

Not related and looks like a gpt answer?

109

I’ve seen a few spam bots on here recently, if it’s obviously not helpful it’s best just press report as spam on the post.

1 Like
112

Can I give this topic another nudge? I have a suggestion that maybe makes this more likely to be implemented:

Add two fields to the states table in the database:

  1. last_communicated_state:
    • This will normally just reflect the same value that is in state. However:
      • It can only be unknown upon sensor creation if the sensor has a state of unknown or unavailable.
      • Once the sensor has any state besides unknown or unavailable, this value will reflect that state.
      • If the sensor state ever reverts to unknown or unavailable this value will not reflect that. It will not be changed and therefore retain the previous value.
  2. last_communicated_state_change_ts
    • This will be a timestamp which changes any time the last_communicated_state has its value changed.

Having the last communicated state in the database prevents having to do lookups when a sensor gets a new state and needs to determine whether this is a “real” change or not. It is also useful in scenarios where users want to ignore unknown/unavailable and just use the last known “real” value. Also it makes it clear that there is no request to change the functionality of the existing last_changed_ts and last_updated_ts fields.

The downside is that I have no idea how much extra storage this would require adding to the database.

Also, in regards to naming of these two fields, I don’t think it matters what it is called. Here’s some other ideas for people to chew on:

  • last_known_state
  • last_monitored_state
  • last_confirmed_state
  • last_nominal_state
  • last_measured_state
  • last_state_that_is_neither_unavailable_nor_unknown
  • any_parameter_name_that_the_people_who_create_and_approve_the_PR_agree_on
  • ...
2 Likes
113

Is WTH running again this year?

It might be coming around that time to get this yearly widely requested feature raised again!

114

no

115

Ah that’s a shame, thanks for confirming though!

116

EDIT:

This has not been implemented. I posted in the wrong topic. Very sorry.

8 Likes
119

I can’t believe it, my prayers have been answered and I can finally get rid of my DIY solution! Great news!

Got my hopes up, I should have checked the link! I’m still hoping this is implemented at some point - I still have the same stance that it’s the expected behaviour from your standard HA users view.

5 Likes
121

Oops, wrong topic. Sorry about that. I meant this topic

FYI it’s 3 properties on the state object. last_changed, last_updated, and last_reported.

122

Saying that my motion sensors and door/window sensors last changed 1 minute ago because I just restarted Home Assistant is wrong 99.9% of the time.

Persisting the previous “last changed” time would be wrong 0.1% of the time.

This is not a good argument. The current behavior makes no sense, especially considering the extreme frequency of Home Assistant updates that all require restarts. This is a constant annoyance.

1 Like
123

Preaching to the choir. There’s no real argument for it.

124

I’m glad I’m not the only one realizing that. Makes it nearly impossible to accurately track the state of things like contact sensors.