Recognize & Stop Recording Stale (Unavailable) Values

Feature Requests
1

Several of my Z-Wave temperature and humidity sensors recently had their batteries die, but the last reported temperature continued to be shown in the interface long after the data was no longer accurate. To be clear, these particular devices update with such precision that the history chart never shows anything that resembles a straight line while they are working, but the history charts were showing straight lines for well over 24 hours before I realized the batteries were dead. I have (hopefully) addressed my dead battery oversight separately using an automation, but I’d prefer that my dashboards and historical charts better reflect reality whenever possible.

State histories show blank space when the entities are unavailable and some graph histories do as well, but I am under the impression from Log state 'unavailable' as -1 (found via search before posting this) that this behavior isn’t broadly consistent.

In the case of Z-Wave battery devices, Z-Wave JS reasonably assumes the devices are asleep and have no change to report, but information on when the last report was provided is available; this may be the case for some other systems as well. I also understand that HA retains values through power failures and reboots as well, which is convenient if not beneficial. However, I suspect most entities in HA could have adjustable timeouts with reasonably sane defaults after which the data could be marked as unavailable (or perhaps stale; it could even be shown in dashboards while stale, but with an indicator that it is stale and with a history record update to have it stop charting until it is refreshed). While I’m not too concerned with exactly how this is achieved, I do believe it should be done at the HA level in order to provide consistent behavior across the various integrations that we all use.

2

FYI you can get what you want with a simple automation that pings the sensor when it doesn’t update for a long period of time

trigger:
- platform: state
  entity_id: sensor.zwave_something_or_other
  to: ~
  for:
    hours: 3
action:
  service: zwave_js.ping
  target:
    entity_id: sensor.zwave_something_or_other
3

Z-Wave JS never reports battery devices as dead, so HomeAssistant never reports them as unavailable. I believe there has actually been some discussion on #Z-Wave in the HomeAssistant Discord about why it shouldn’t work this way for wired Z-Wave devices, either.

4

the ping will check to make sure the device is alive, no response it will mark it as dead and thus unavailable.

5

No, it won’t, battery devices are never marked as dead in Z-Wave JS. They are only marked as sleeping. They also don’t listen for or respond to pings unless they are explicitly woken up (by physical interaction specifically designed to wake them or a scheduled wakeup cycle). I’m double-checking my understanding in Discord, but I’m 95% certain I’m correct here based on recent experience and discussion with Z-Wave JS developers and users.

ETA: A developer confirmed that ping with no response = sleep (NOT dead) for battery devices. This doesn’t necessarily mean I am correct about pings not being responded to without a wakeup, but it does mean the suggested solution is invalid.