Identify Offline Sensors With Expected Sensor Cadence?

[bretton.wade]

I have a number of sensors that will go offline and stop reporting, but I won’t notice because HA just continues to use the last reported value. This is predominantly a problem with Z-Wave sensors that are not expected to be always communicating due to power saving, but some wifi-based sensors will also exhibit this problem. The problem could be a dead battery, or a Z-wave network issue (constant).

I’m considering an automation to check a group of entities against an expected cadence. For instance, I expect a temperature sensor in my garage to give an update every hour. If I haven’t gotten one in say… 4 hours, I’d like a notification that the sensor is possibly offline.

Has anybody already done something like this?

[123 (Taras)]

I call a state value that has failed to change in a long time “stale”. The links below explain how to detect “stale” sensors. However, be advised that they rely on the sensor’s last_changed property. Some sensors have a value that never changes yet doesn’t mean it’s stale (like a smoke alarm’s state). Therefore you have to use the technique judiciously otherwise you’ll get false positives.

Monitor a single sensor:

Notification in case no values have been recorded since X

One way to detect if a sensor’s value is stale (i.e. has not changed for a long time) is to compare the entity’s last_changed to the current time. If it’s more than some threshold value, like 30 minutes, that means the entity’s value hasn’t changed in the past half-hour. You can create an automation with a Template Trigger that triggers when the monitored temperature sensor is stale. The action can be whatever you want. It can log the incident to a file, notify you, do both and more. In the exa…

Monitor several sensors:

Polling Devices to Avoid Silent Failure

Paste this template into the Template Editor. It will list all sensors whose states have not changed in the past hour (3600 seconds, change it to whatever duration you prefer). {{ states.sensor | selectattr('last_changed', 'lt', now()-timedelta(seconds=3600)) | map(attribute='entity_id') | join(', ') }} You can use that as a starting point to create a template that checks for ‘stale’ entities. If you want it to check sensors and binary_sensors, use expand(). {{ expand(states.sensor, …

BTW, when an entity’s received value is identical to its existing value, its last_changed remains unaltered (to be expected) but its last_updated will also remain unaltered. Long story short, received duplicates are ignored (so be careful if you decide to check for staleness based on last_updated).

Reference: State Object

[bretton.wade]

Thanks. I tried something like this already. I ran into two problems:

• these last-updated values are reset on reboot. I have to restart HA a lot because I am always updating integrations and automations, and
• I found a lot more false positives than I needed - a basement door that hasn’t been opened in some time, or your example of a smoke alarm…

I was looking for anything with an expected cadence - so a list of entities with an expected frequency, or maybe a “learning” approach that recognizes a regular pattern and reports when that pattern breaks.

BTW, when an entity’s received value is identical to its existing value, its last_changed remains unaltered (to be expected) but its last_updated will also remain unaltered.

I have long considered this is a substantial bug in the sampling strategy. Knowing that a sensor reported is an important piece of information, even if its state is identical.