Agreed. The limitation is that not all devices support a check in to assess DeviceAvailability. For example, I know that zigbee devices do support it. I don't know about z-wave or LAN connected devices.
Edit: for z-wave and LAN devices, I suppose the hub could schedule a periodic ping. So your proposed capability is definitely doable.
Capability is more of a "macro", it functions rather the same as an Attribute and Command in one word.
Defining an Attribute then altering the sendEvent to use the new Attribute would be functionally the same as having a Capability.
I say all this NOT to disagree with the idea/need, but to show how to do it BEFORE the request actually is found in a Release. Adding it to a Release is going to take a while BUT then getting all the drivers converted is even more time... what I mention can be added to drivers today, getting them working "better" until the Capability hits the street.
Having a standard attribute for all to use is a great idea.
The only thing is that all of the drivers will need to be updated to implement this. But at least having a capability will allow them to implement it in a standard way that all can follow. This will be a bit of work.
I've implemented a system on all of my device drivers and also created an app to notify me once a device stops checking in. From a high level this is what I do,
a custom attribute on the device called checkInInterval that defines how often a device should check in. (every device reports differently).
a custom setting that allows you to set the above attribute but also allows you to define weather it should ping on this schedule to force the check in if need on devices that don't automatically check in on an interval.
in the driver code I have an extra line that will update a data value with the last check in time every time a device does something that I consider a sign of it "being alive". I use a data value mainly because I don't want to flood event logs with a bunch of updates to this key and its less overhead.
My device monitor app will just read this data value and ensure that it has checked in, in the time specified by the interval and if not send me a notification and it runs every hour.
Doing it this way I know within the hour when a device hasn't checked in within its period and I can address it. It works well. Later on if they add a custom attribute for "online/offline" then I would just make it set that based on the above calculation as well.
I'm not saying this is the best way, just dropping my method here in case the HE team are thinking of doing something like this and can use some input.
I'm looking to do this specifically for my Honeywell Home integration - it seems to get booted from the Honeywell API every so often and I don't notice for many days. I re-authenticate and all is well, but I'd love to setup something to notify me when a device hasn't had an event (temp/hum change) over a certain time like a few hours.
Any ideas how to set a condition where the value hasn't changed in x time? Figure this is the quick and easy method since i'm looking at one thing right now.
Actually I think I figured out an easy method - trigger based on temp changed, set local variable to current date/time and then make condition where if the local variable value (minus) current date/time > 2 hours should be sufficient, no?
lol scratch that, it's not going to be that simple. I need to:
Trigger based on any temp sensor changed
Trigger on periodic schedule like every 2 hours
Action to set current date/time only if trigger by temp sensor change
Action to set current date/time only if trigger by periodic schedule
Condition to subtract 2 variables and if >90 minutes, sent notification
Assuming you mean attribute and not capability (the only one between the two that we can define custom), a few built-in drivers use networkStatus for this, with online or offline as two possible values — though among the ones I'm aware of, only for LAN devices where this is easily discernible. Z-Wave and Zigbee are, as we all know, a bit trickier, but they are still networks, so it's not a totally inappropriate name ... just to provide one idea!
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.
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: : )