WTH, how can I know when the last (unchanged) sensor value was received?

Month of "What the heck?!"
61

You can easily add an attribute on your entity that holds the last time you communicated with the API, which in turn will ensure last updated changes. Any integration can do this.

The semantics in this thread are required because OP wants to change a building block of the state machine because he’s unwilling to understand what the property means (not what last_updated implies). Changing this would break many time related things all across HA. Triggers, timers, conditions, durations, you name it. Not including breaking changes for existing templates that users have. It’s not worth the headache to change the current functionality. Adding a new property to the state object would be simple and break nothing.

2 Likes
62

Wow, it’s almost 2025 and I can’t believe there is still no solution to this “problem” (it works as documented, not a bug, no need to fix… yeah, sure).

1 Like
63

Because no one is interested in making the change. Anyone can step up to the plate and take this on, even you. This is open source after all. That’s how changes work in open source. If someone is interested in implementing something, they submit a PR and go through the software change process. Since this WTH started, 0 people have attempted to make this change. Maybe you could be the first.

64

You are right, but only in theory. In practice the vast majority of us cannot make the changes necessary, we do not have the skills required to even begin contemplating what needs to be done.

That is why we must rely on people, like yourself, to solve these issues in a meaningful way. You have previously suggested an alternative solution that is “simple and breaks nothing” while still solving the OPs issue. Why not pick up the gauntlet, even if that simply means raising the issue elsewhere?

65

Because I don’t want to. I have no need for this. Even if I wanted to, I don’t have the time to maintain it.
Hopefully now you see the downside of open source products. It’s the FIO (Figure it out) philosophy, if you really really really want a feature, you’ll have to figure it out yourself.

66

I agree. The FIO philosophy is a major downside of open source projects. I’m very surprised though, that this property, which allows to distinguish between a sensor that is not reporting and a sensor that reports the same value multiple times in a row, is not implemented. It’s an important distinction.
What would need to be done? Add one line to the definition of a state? And then add some functionality to every individual integration in HA so the property is actually being used? That effort could be spread over many users of all the integrations. Or is thissomething that should be handled by the core?

Trying to understand, since I don’t have a clue, obviously.

1 Like
67

For me these are the typical useless discussions in OSS (of course as a developer myself I understand that is not a good idea to change the behaviour of a field from one day to the other but discussions over a year seams to indicate some need). And even if someone implements that feature and provides a MR usually there will be someone who finds a reason why not to add it.

But to add some value to this: At least for zigbee2mqtt there seams to be an option to see that in HomeAssistant.
You first need to enable

advanced:
  last_seen: ISO_8601_local

for zigbee2mqtt in configuration.yaml of zigbee2mqtt (Dont ask me about ISO_8601 or epoch).

I’m not sure if the next step

is still necessary.

You will see it then in HomeAssistant as Attribute of the Entity.

Because there is no generic implementation in HomeAssistant it is not possible to find in the devices tab devices you have not seen for months.

1 Like
68

Just chiming in to make a note that I have hit this issue with the statistics integration and trying to use a change of humidity in the past 5 minutes as a trigger.

What happens is that the humidity sensor is very stable, and the value is not changing. Then someone takes a shower. The humidity spikes up hard, and I’d really need to capture that original bottom level humidity from which the situation got triggered.

But I don’t, because “it works as specified”. The database doesn’t seem to store the polled humidity values when the value remains the same, and when the statistics integration is working on its 5-minute change calculations, it has no value from the bottom of the humidity graph, even though if I look at the humidity graph in Home Assistant I can see that it draws it mostly correctly in a fashion where the line drawn continues along the not-stored values until the spike up.

But the statistics integration works with the database, not the graph, and when it looks for values in the past 5 minutes, all those times the humidity polled the same old value, went to bit heaven in an acute case of it works as specified.

Now I suppose I could fix all the integrations in home assistant, of course. Or I could fix the core, database, whatever. But alas, I don’t know all the integrations, and there are too many, and I don’t know the core either. So I’m left with the vote button.

I sincerely hope others will take the time, register, and vote. Maybe someday, someone picks this up. Us users, we don’t want to change your beautiful design, it can be as it is, but we want something new - without specifying the “how” in details - that works even a bit better than the initial, beautiful design.

1 Like
69

This has been implemented as last_reported on the state object.

Will be released in within one of the next few versions of HA. I will update this post when it is fully implemented.

5 Likes
70

Consider an integration which creates a sensor.
Assume that a corresponding physical object is not changing for some period.
So, the sensor has SAME state & attributes for this period.
Currently DB may contain consecutive records with SAME content (state & attrs) - but with different “last_updated”. Imho “last_updated” should not be changed if a state/attrs do not change - but it happens, and not only on HA reboots. I noticed this behaviour for several integrations.
Now a new property is added - “last_reported”. I wonder - will DB store all records with same content but with different “last_reported”?

71

read the linked discussion in that blog post, that’s already a concern

72

2024.4 contains last_reported on the state object.

If you have any questions, please create a new topic in Configuration

{{ states.sensor.temperature.last_reported }}
8 Likes