Add sensor field to store expected time between readings/updates

[BenBarat]

Describe your idea

Each and every sensor in HomeAssistant should have an optional parameter that stores an expected maximum time between updates, that if exceeded should be flagged as an error condition that could be tested in code.To be in appropriate units such as seconds, hours, days, etc.

Think of all the scripts and yaml that could be saved if this was standardised across the board.

Why is this exciting?

Think of all the code written to test for sensor activity, or lack thereof, each with their own set of conditions and bugs, and all that could be standardised and automated.

Potential use cases

Look for dead or hung sensors would be easy in code or yaml and scripts.

Anything else?

No response

[mib1185]

In a perfect world a sensor should go into unknown state as soon as the data update fails. This is already the case for most data update coordinator based integrations. But not all integrations make use of an update coordinator under the hood, or some use one but don't raise the correct error in case of data update issues.
Further the "last updated" timestamp of an entity is only updated, when it's state is changed - so when a state is not changed after a data update (eq the sensor value didn't change) then the "last updated" is also not bumped.

[mmiller7]

In a perfect world a sensor should go into unknown state as soon as the data update fails.

That's a nice thought, but we don't live in a perfect world.

But not all integrations make use of an update coordinator under the hood, or some use one but don't raise the correct error in case of data update issues.

Even if it does, many integrations can't know what the expected reasonable interval would be. For example, many thermometers (especially smarter Bluetooth ones) only push out an update on value change. For a thermometer measuring a room temperature that could be a few times an hour. For a thermometer measuring a large aquarium, that might be a few times per day. The integration can't know how the sensor is being used and that one of them an expiration should be 10-15 minutes while the other an expiration should be 6+ hours. My observation of these is that the integrations only usually reset to "unknown" from when HA restarts until the next time the sensor checks in minutes or hours later (unless I go pull out the battery to make the sensor reboot and send "now"). I've had more than once a battery dies (or Duraleak ones corrode and fail before it dies) and HA keeps the last reported temp/humidity and battery % for days until I notice it.

This also gets sticker when you have things like MQTT where the sensor input data can be an endless number of things and each value needs to be considered for its individual purpose. Not everything can or does publish an "availability" separately, but even if it does something like a battery-powered sensor could die without being able to publish its death. There should be a way to tell the system if it hasn't updated in for X time it should be purged regardless of what the MQTT server thinks. This is especially true with 3rd party things where you can't control what they publish or if they set a retention policy.

The whole selling point of HA is that its so flexible you can pull in anything you want. This feature-request would go a long way to enhancing that flexibility.