See this comment by @bertabcd1234 , but I think Hubitat staff can give us the most accurate info.
3 Likes
From someone who's still trying to get their heads around everything Hubitat, could you please be more specific as to why the answer is no?
I would guess that it is because the switch capability defines a binary device with two states - the equivalent of how physical two-position switches work.
Of course this doesn’t preclude the use of a new attribute (like deviceHealthStatus) or capability to determine whether a device is available for use.
1 Like
Because device health is a chimera. For the types and quality of smart devices available, any attempt to provide device health is doomed to fail in so many cases, as to make the offering of any form of device health very misleading. There is no reliable means to tell if a device is healthy or not. Consequently, we don't believe that device health should be a part of this platform.
3 Likes
it would be reassuring to me if I knew that there would be a warning if a device is no longer connected to the hub for any reason. It's still technology and technology can falter
4 Likes
Yes I use this app, but it would be nice if Hubitat supports 1 concept all developers could use
I think the staff’s stance on the concept of device health was pretty clearly laid out above:
3 Likes
That's the beauty of Hubitat. Even though they feel that it's not beneficial for them to add and maintain something, they leave the door open for others in the community to take it up and do as they wish... I mean there are a lot of things I wish were built in but instead are taken care of by the community and are done well..
5 Likes
@bravenel specifically said he would not support converting binary states into a tristate. What a mess that would cause otherwise!
DAC supports a number of different rules to decide device liveliness; I use at least 5 different ones. Cramming that into the platform (especially via a tristate) would be just more mess.
I hope that a well-known DevicePresent capability can be added (rather than overloading Presence as is currently done by a number of drivers), as that's not adding the detection into the platform, but just the ability to talk about it. But if doesn't happen, we still have a patched together solution.
3 Likes
The original request from @ymerj that @bravenel responded to was for a tri-state switch: on, off, unavailable.
I’m guessing this is what @jlv referred to.
2 Likes
Oh, yes...
So as the healthStatus attribute has only two states ( 'online' or 'offline' ), that's not a problem.
1 Like
But for those of us with OCD-like tendencies in this space.... On and Off does not satisfy us.... 
3 Likes
BTW, the HE inbuilt device Status property (binary state !) matches almost 100% the healthStatus of all my Zigbee devices, if the criteria is "nothing received from this device for more than 24 hours"
2 Likes
Weirdly that feels more appropriate....
2 Likes
Sadly, the device Status is not exposed for use in RM5 or in the dashboards.
Feels like something for a developer to work on.... hmmm... who could step up and provide that data,,,, 
Someone who has provided other hub-related data....
2 Likes
Was thinking the kind of developer who can provide "hub-level information" could maybe provide device-level information
2 Likes
