DevicePresent capability ('Health Check' capability and 'healthStatus' attribute)

As this thread was created by the OP (@tomas1 ) for the purpose of discussion and Feature Request for Hubitat Elevation system platform, I have created a new dedicated thread for the new application :

Let's continue the discussions and the proposals for the particular app there.

4 Likes

I hope that HE will officially add the On/Off check function later
and display it in a small circle at the top left of the dashboard.

I'm sure it will be well received by many users.

1 Like

Seems like something very close to what we need is already available on Hubitat platform - this is the device property 'status' with possible values 'ACTIVE', 'INACTIVE', 'UNKNOWN'. What is missing at the moment is this property to be available in RM, HE dashboards, etc...

1 Like

I believe this referred to the value of an automatically-calculated, since-removed column on the Devices page of the hub (similar to that of the "classic" SmartThings IDE), the "Status" column. This happened a long time ago, and I think it took a long time after that for anyone to even notice. :slight_smile: Here's an old screenshot from the old docs, no longer available, this being column "E":

It was removed, I believe, precisely because there was no good way for the hub to determine this value (I think it was just an hours-based calculation, the same for any device and thus rarely accurate for all). The corresponding property on the device object apparently still remains, but I'd be surprised if it wasn't read-only. In any case, I don't know of anywhere that it is used, and I further wouldn't be surprised to see it marked as deprecated some day. Likely just a leftover from initial efforts to make ST ports easier...

3 Likes

Health check capability has been added to all custom generic components in HADB

3 Likes

The first tests are successful - thank you @ymerj !

1 Like

What is the difference between "Device Status" and "Health Status" in your table?

1 Like

`Device Status' is the device object property automatically determined by HE.
'Health Status' is the custom attribute, candidate for substituting the misused Presence attr.

1 Like

What is it supposed to mean? And is there any documentation about how it is determined, or is it totally opaque?

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

Hi @jlv ,

Can you clarify what you mean by 'tristate' ?