WTH there is no new last_* attribute that retains restart

As suggested:

There should be new attribute, that can be shown in UI as last_reported_change (or whatever wording used) that will preseve it’s state and change only with real state change, not just by HA restart.

This would allow to see which devices were used when last time - not when HA was restarted last time.

Please, don’t let this WTH pass next edition… :wink:

Previous WTH-ks: 2020 and 2022

This is a serious bug from the users perspective. The data displayed to the user is totally wrong. Since years.

The biggest problem with Home Assistant developers is that they see bug reports from the programmers perspective not from the users view. In their POV this is not a software bug, because it is designed to work like this. But it is designed in a wrong way.

Most probably they have to restart this project to solve that and those which are connected to this. The last_* attributes are just the tip of the iceberg, as entity states are also wrong after a restart. These problems come form the base design of Home Assistant, that they didn’t wanted to store data at all. Then came the Recorder integration, then the long-term statistics. But there is more like this: access control limitations, problems with restarting, Long-term statistics.

In my opinion it’s time to think on a new Home Assistant.

Here is my closed WTH and even forgot to write about long-term stats: WTH Home Assistant 2.0

14 Likes

Well said! I read a couple of times “If we dont know if it has been on or off, it is unknown”. Which is totally right and actually in quite some Situations really helpful!
But yeah - my Door gets shown as “closed 3 Minutes ago”. It is not. It is three Minutes ago that i restarted Homeassistant :stuck_out_tongue: I like the Idea of additional “last_valid_change” or whatever for every Entity: Would solve a lot of Issues and Redundancies +1:

9 Likes

Surely third time lucky of getting the most votes will get something rolling!

I really don’t like updating or restarting as my smart home turns very dumb (no, my hot water system that has been on for 6 months has not been on for 5 minutes :slight_smile: )

It can be a new attribute, the most important thing is that it must survive restarts.
I know there is a chance it might now have a valid value, because the state could change during restart, but I can live with that.

1 Like

Information about the actual last reported state of a given entity is definitely needed. At least once a week I look at the attic window entity and wonder why it was open for the last few hours… only after a while I realize that I restarted HA.

2 Likes

My post back from 2022 had loads of votes for this issue and was near the top voted for a while but I think it’s been a well voted WTH for years now. Some say it’s a “feature” not not an “issue” which I clearly disagree with. Please, please can we have this optional new actually-last-changed attribute this year!

5 Likes

I think this problem shouldn’t be solved by introducing a new attribute. This is a much deeper problem. There are many other problems connected to this, specifically to the root cause which is that restarts are not handled correctly.

An example:

trigger:
  - platform: state
    entity_id: binary_sensor.a
    to: "on"
    for:
      minutes: 15
  - condition: state
    entity_id: binary_sensor.a
    state: "on"
    for:
      minutes: 15

Let’s assume the state of sensor is on before and also after the restart. And here comes the problem: the trigger doesn’t fire 15 minutes after the restart, which is okay as the state was on before and after the restart for hours, BUT the condition is false for 15 minutes after the restart as the 15 minutes is calculated from the restart not the real state change. Like the last_changes attributes in this WTH…

To debug and solve the problems in complex automations caused by the inadequate restart mechanism is a huge task, makes the automations even more complex and inefficient, for example putting timed triggers beside those required by the logic in every automation.

7 Likes

I absolutely love Home Assistant but man time and time again I take a look at my door sensors and panic for a split second when its last changed attribute says “2 hours ago” when I know it wasn’t opened since last month. Only to realize I had just restarted HA 2 hours ago…

A simple attribute will at least give us users the option to prevent this from happening. While I have yet to see a compelling argument from the HA devs, we should be allowed to have the option for persistent states/attributes.

I also could be mistaken but isn’t this a HA unique quirk? Other major smart home brands don’t seem have the similar take that HA does.

6 Likes

@terba Totally agree.
Most of the time, you know when you restart and what is the impact of that.
If HA restart due to an issue, then I got a notification. For me, unknow state is correct because it’s unknow after a restart… That’s simple as that and there are ways to take care of this state.

This is so huge. This would be singly the most important thing that’s missing from Home Assistant.

4 Likes

Thank you that helped explain what I was missing.
Time to vote, agreed.

andriej,

I didnt see this post, but posted another one that closed as duplicate. I had good historical links from the previous WTH requests. Feel free to add to your OP.

Totally agree with this. It takes years to convince HA/devs to see it from a general consumer perspective.

Albeit, steady progress is being made recently with community voices being heard, which I’m liking. I surely hope this gets implemented soon.

1 Like

I think there are two simple issues here.

  1. The label is wrong - it’s not last change, it’s last database update.
  2. The design is wrong - what the consumer of the data (the user) is interested in is not the internal state of the software, but the state of the physical world. The internal state is important, but not for the user.

The purpose for the user of the software is to manipulate and get information about external entities in their home. The internal state is a tool for that but not the goal. Since the information shown to the user is sometimes relfecting the physical world and sometimes not, it’s even more problematic.

This bug could be solved with chaning the label, with only showing the last reported state if it is known - otherwise “unkown”, it could be solved with a new attribute, but my preference would be to store the real world state and report it in the logbook and rest of the UI, rather than reporting the internal state.

1 Like