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
I think it is not possible.
User apps need the devices to be manually authorized (by manually selecting them) to have access to their data.
And it is impossible for a user driver to access the device data for devices different than the single one that uses this driver.
This is a security access restriction and is done the right way.
1 Like
I think we'd all trust @thebearmay with our data....
But I get your point, not a simple implementation that would work out of the box...
2 Likes
Could create an app with a dashboard device with multiple attribute pairs - one for the device name/id and one for the device status. Wouldn’t have an event to subscribe to so you’d have to poll. On the plus side not having to worry about multiple events will decrease the overhead.
2 Likes
Yes, this will be possible, but is definitely not the best approach ...
The Zigbee devices online/offline status is already here, just sort by the "Msgs" column :
In my use case, all these 8 devices that have zero messages received since the last reboot are truly offline (I have either switched them off or moved to another hub ).
All we need is to receive an event when the HE internal device Status changes between ACTIVE and INACTIVE.
2 Likes
This is actually a very good idea!
There will always be devices that are not designed or not implemented to report their health status reliably. We can't control this, but we can choose which devices to use.
I will not trust a water leak sensor that does not report its battery status periodically.
I will not trust a gas detector that does not report its battery status periodically.
I will not trust a shut-off valve if it does not reliably report its online/offline status to my hub.
Such device health status could be user-selected as 'unavailable' or whatever more appropriate term is chosen.
So everyone knows which devices are online, which are offline, and which devices status is unavailable.
4 Likes
I agree 100% on this. I want to be all my sensors are still working. I use DAC for this notifying me if a sensor hasn't updated in the last 24 hours.
But I don't like this at all. This just confuses the current state. And it would end up being a different attribute per device type (switch:, contact:, motion:, etc).
3 Likes
As I mentioned above, this was removed from the interface years ago because the data was unreliable — I think just a time-based approach, with no specific knowledge of how any device works. Pretty much the same problem any discussion of this issue centers around. I don't think using this (undocumented — and I'd say "legacy") data will fix the problem or address it better than other solutions could (e.g., using a custom attribute as in the driver-based approach, you actually do get an event if that is what you want).
Regardless of whether it's a good idea, I'd say there's little chance of it happening. It would necessitate drastically modifying nearly every existing capability to report in this way, and many apps would break as a result unless updated to match. This is particularly relevant for current "binary" states, like switches (e.g., if you test "if on" and it's not, you can assume it's off without testing; there are only two possibilities).
If someone wants this, I still think a single, new attribute in the driver — as proposed elsewhere — would be better; then apps that know about it could use it if needed, whereas apps that don't will not be affected.
4 Likes
For this to be useful, the word reliably needs to be added to the battery device requirements.
How is the general user population supposed to know when these requirements are met or not? In a perfect world, this would be true for all devices. In the world we actually live in most devices sometimes fail these requirements. This leaves us in a hole that no software is going to rescue us from.
From my perspective this is a complete non-starter. There are all of the problems that @bertabcd1234 cites above about existing app expectations, backwards compatibility, etc. Pile on that the unreliability intrinsic in the "unavailable" state. There is no reliable way to know if a device has become unavailable in any of the main protocols supported by the hub. A switch may report off, but then immediately become unavailable without a peep (e.g., turn off the breaker or pull the air-gap). I'm convinced this entire pursuit is ill-advised.
4 Likes
Sorry, now I see where the misunderstanding comes from - when I said that the tri-state concept is a good idea, I had only the proposed new healthStatus (or the existing Status) attribute in mind. But I wrongly quoted a switch example, which was not what I was thinking of.
Definitely, adding a third state to the existing binary attributes like switch on/off, contact open/closed, motion active/inactive, etc.. is a no-go.
What I am trying to propose is to restore the three-state device Status property and make it available as an attribute, which change will fire an event accessible from HE apps. Very similar to the custom deviceHealth attribute as it is used in some custom drivers now, but generated for each device by the HE system itself :
I didn't notice that the previously exposed Status already had a third state - UNKNOWN (similar to my idea for adding a third state 'unavailable' for the custom healthStatus attribute).
This third state (I like more the UNAVAILABLE term) should be selected by the user (could be done by adding a small action button/icon for each device in the table above next to the Status column). Setting/marking a device status as UNAVAILABLE should be done by the user and the meaning is - "Yes, I understand and confirm that this device ACTIVE/INACTIVE (online/offline) status can not be determined automatically by HE because of device/driver specific limitations. "
Regarding the reliability of determining the devices online/offline status - this was greatly improved after the latest HE platform updates:
- Beta Release 2.3.5.127 - C8 only - added logic to proactively ping devices that had no messages in 3 hours or more.
- Beta Release 2.3.5.133 - All hub versions - added last Zigbee message timestamp and Zigbee message counter on Zigbee details page
- Beta Release 2.3.5.136 - Fixed Last Update Time to reflect the last time a message is received from a device (as opposed to the last time device attribute changed).
All these improvements greatly impacted the reliability of determining the online/offline status of the Zigbee device in my opinion.
I am pretty sure similar improvements can be made for the Z-wave devices as well.
2 Likes
Why I use a mains powered gas sensor
even then....
