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. 
For sure. Also, the implementation is going to be device protocol dependent making it a little tricky to implement.
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,
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:
Almost a year has passed since the first post...
Can we simply choose a custom attribute name and start using it instead of the Presence capability ?
We can simply make a poll here and decide what name to choose.
It is of critical importance that the new custom attribute is supported in Device Watchdog @bptworld and Device Activity Check @bertabcd1234
Then, someday, from a widely used custom attribute, it may turn into a standard capability @ Hubitat ?
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!
Yes, I meant a custom attribute (edited my post).
It will be used from the device drivers (Z-Wave, Zigbee, LAN) to denote that the device is currently offline to HE hub.
So seems like a name deviceStatus with possible values 'online' or 'offline' will be OK for both Zigbee/ZWave and for the LAN devices...
HubiThings Replica uses 'healthStatus' custom attribute ["offline", "online"]
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.
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: : )
Download the Hubitat app
