Yes. I was talking about the current states of a device like:
switch: unavailable instead of switch: on or switch: off
Yes. I was talking about the current states of a device like:
switch: unavailable instead of switch: on or switch: off
Yeah, that's not going to happen.
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.
https://developer.smartthings.com/docs/devices/capabilities/capabilities-reference#healthCheck
Great, I think we need look no further than what was already defined and used in the ST platform for years :
attribute "healthStatus", "enum", ["offline", "online"]
One day, when and if Hubitat decides to add a standard "healthCheck" capability, the "healthStatus" events will be already available in some custom drivers.
I think this is really necessary.
The foundation of IOT is trust, and I think this is a big start for real trust.
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)
A very simple driver to test other apps to send notifications using the healthStatus attribute can be downloaded from here
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:
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: : )
Using HubiThings Replica for a device that will not stay paired to HE (TS011F _TZ3000_okaz9tjs )
Now waiting for the healthStatus to become offline both in SmartThings mobile app and in HE, after the plug was disconnected from the mains socket
And 10 minutes later :
Works exactly as expected!
The "healthStatus test driver" was updated to version 1.0.1
https://raw.githubusercontent.com/kkossev/Hubitat/main/Drivers/Misc/healthStatus%20test%20driver.groovy
The changes are in only 2 lines of the code :
.......
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
........
Here it comes, my first-ever app for Hubitat Elevation!
https://raw.githubusercontent.com/kkossev/Hubitat/main/Apps/Device%20Health%20Status.groovy
Welp I guess none of my devices have a health status Though I only have the tuya water sensors and they don't have health.
It will take a lot of time until the healthStatus attribute can be widely used for most of the devices used in HE..
But even today, we can use the "Last Activity At" property of any device (as already used in Device Watchdog and Device Activity Check apps):
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).
Thanks for the app!
Unfortunately, I am not able to select any devices althought I have at least 4 devices with health status?
I have temporarily removed the devices selection filter, please update the app ( time stamp : 2023/02/03 3:08 PM)
I am curious to see the last column (drivers)... : )