For what it's worth, HA marks the state of an unreachable device as "unavailable". Which makes sense. HE will even accept such a status, BUT since RM only allow to test for predefine states (ex: switch on or off) this is currently useless.
What about adding that possibility to RM and other app instead?
This isn't right. RM Custom Attribute can use any attribute defined for a device. The attribute can be defined to be an ENUM, with values of [availalble, unavailable] defined. So yeah, the possible states should be predefined.
Could also go to the light side of the force. From what I can tell - going forward they are only supporting the attribute 'healthStatus" of the "healthCheck" capability as enum: [online, offline].
It does keep a nice KISS principle and finally is a standard on that sometimes curious platform.
One day, when and if Hubitat decides to add a standard "healthCheck" capability, the "healthStatus" events will be already available in some custom drivers.
Here are the first successful tests using the Device Watchdog ( thanks @bptworld ) app to send healthStatus offline notifications from devices that use the "Tuya Scene Switch TS004F" driver (dev. branch version 2.6.0):
This is the Device Watchdog app configuration : (just use the existing 'Special Tracking' options)
To clarify, is the expectation that drivers will "know" their own status and update their healthStatus attribute accordingly? Then an app can read this attribute?
(I see online() and offline() commands in the simple test driver above, but I assume they are intended only for users to test different values of this attribute, not for apps to use to set this on a driver directly. I would look at DW to see if this indeed what it's doing but apparently cannot view the code directly on GitHub as I would prefer due to it only being available in a Bundle/ZIP, which I'd rather not deal with. )
Yes. It is the driver that 'knows' whether and when a particular device has fallen off the HE network:
battery-powered devices - when nothing is received from the device for X hours. These usually send battery percentage remaining reports periodically, different for each device model/manufacturer. Some allow the battery reporting period to be configured. some have hardcoded reporting periods.
mains-powered devices - a lot of devices are sending periodically some commands/reports to the hub as a heart-beat or check-in messages. Not receiving such messages for a predefined period (which may be different for each specific device) will trigger 'heatchStatus offline' event.
The offline state can be determined very quickly for some devices! As an example, a water shutoff valve is supposed to report back the open/closed state after the command is sent. If the device does not report 'closed' 10 seconds after sending the 'close' command - it seems like the valve is not operational right now, send an 'healtStatus offline' event immediately!
There are a lot of functionality exception scenarios that can be handled much better on a driver level.
The app that is subscribed to healthStatus events will further send notifications, generate reports, etc.
That's correct. You can create a virtual device, assign the '"healthStatus test driver" to it and use the UI buttons to test the Device Activity Check new Inactivity detection method: : )
.......
ver. 1.0.1 2023-02-02 kkossev - a dummy capability 'Health Check' already exists in Hubitat! (unfortunately, the attribute 'healthStatus' still has to be declared)
.......
capability "Health Check"
attribute "healthStatus", "enum", ["offline", "online"]
........
This helps a lot for filtering the devices lists in apps ... like the Device Activity Check ! : )
case sHEALTH: // healthCheck is an undocumented Hubitat capability! :)
capabilityFilter = "capability.healthCheck"
break
........
input name: "group${groupNum}.devices", type: capabilityFilter, multiple: true, title: "Select devices to monitor", submitOnChange: true
........
This will not help a lot for these devices that have issues reporting the remaining battery level periodically but in my opinion will be more precise than simply relying on the battery levels, which may have been reported as 100% a year ago, but the device to be dead since then...
So next version of the app will have the option to show all devices (without the 'Health Check' capability filter as it is at the moment).