As we all normally chase our ZB batteries every year I came to rely on Device Activity Check app for a good indication of what was dead; it works fine for battery levels ATM and I assume health status.
I find that my ZB devices in the last 6-12 months(?) don't change their health status to "offline" so the reports is never indicative of battery issues..
Consequently I have to always go to Settings | ZigBee Details | msgs column and see what device has not been sending msgs or Ping responses.
Has anyone noticed the device health status is fixed at "online" even when the events stop coming in?
1 Like
This would depend on what driver you're using, as "deviceHealth" is not a standard part of the platform (or used in any built-in driver, though it does have some community traction). You'll probably have better luck if you share more information about the devices and drivers you're using.
3 Likes
This is my go-to for all my Aqara/Xiaomi devices of which I have many.
I was under the impression that Health was the new standard for HE reporting of device existence.
Maybe @kkossev might have some insight here as the last modder of the code for this particular purpose.
v0.2.1 - healthStatus fixes and improvements (@kkossev) 2024-04-23
That's not the case. Only some community developers use it - it's not used in any native drivers.
ETA - since this is specific to just that community driver, have you reviewed that driver's community thread? Posting this issue there would get the most traction from its developer and/or active fellow users of it.
1 Like
The last person to mod the code was @kkossev in 2024-04.
He has advised that the code is not currently maintained so that thread is dormant.
I guess I'm searching for a supported alternative if heathstatus isn't a real HE thing yet so I can get a state that reflects the device not answering to the 3 hour ping set in the ZB settings.
I am testing an older 2023 variant from Markus Liljergren as this was the first to support healthstatus.
The driver is just not advertised as accepting many different Aqara/Xiaomi devices.
@dnickel, the (incomplete) list of community drivers that support the healthStatus attribute can be found here:
I should probably edit or rephrase the first sentence in the top post to clarify that the Hubitat platform only displays an offline icon on the dashboards and certain device list pages. Note that the built-in system drivers from Hubitat do not support the healthStatus attribute.
What Aqara or Xiaomi devices do you have? Most of them should have a dedicated community driver with health status. Please check the links in the second post of the thread linked above. Personally, I am using the modified Markus's drivers for my Aqara buttons and contact sensors :
Personally, I don't use the "Xiaomi Aqara Mijia Sensors and Switches (w/ healthStatus)" driver (the one you refer to), as I think that combining so many different device capabilities in a single driver is not a very good idea.
If this driver is not updating properly the healthStatus attribute when the device has stopped sending any Zigbee messages to the hub, the problem may be in the driver code, so we need to look at it. The first thing to look at is the deviceHealthCheck periodic job - it is responsible for changing the heatlhStatus to offline. Do you have this scheduled job running? (see the sample screenshot above)
3 Likes
Thanks for detailed reply. 
I use the moisture (water), humidity/temp combo, motion and buttons a lot as they have been good value and are fairly stable/reliable; 30 in total.
I could tryy to find individual drivers and test to see if any of them reliably report and 'offline' status of some sort.
I don't see any healthstatus schd anywhere, just the daily app notification for the Device Activity App so maybe the driver has never really functioned properly.
I had a look at the list and interesting enough I tried the alternative from oh-la and it fails on healthcheck:
11:02:07.767errororg.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_driver_oh_lalabs_com_Zigbee___Xiaomi_Aqara_Opple_Button_Switch_Remote__w__healthStatus__3268.configure() is applicable for argument types: () values: (method configure).
I have been running the other example which is the one that always says "online"-
Xiaomi Aqara Mijia Sensors and Switches (w/ healthStatus).
Off to try whatever I can find that matches in the list for individual devices
I tried this for all my humidity sensors and they all reported offline for a while and then went online. Device Activity Check show the changes.
One down hopefully...
Zigbee - Xiaomi/Aqara Temperature & Humidity Sensor (w/ healthStatus) 6 - Aqara WSDCGQ01LM & WSDCGQ11LM.
Everything is moved over to discrete drivers and looking good in the DAC app.
Hopefully I'll start getting offline events now in the reports.
1 Like
I know you didn't do the drivers and the OG dev is out of the pictures but just some insight maybe?
This appears to be harmless but I get it on my buttons.
I think just mainly on a reboot.
dev:1432025-10-02 09:40:55.607warnUnhandled Event PLEASE REPORT TO DEV - description:read attr - raw: 57270100000A00002001, dni: 5727, endpoint: 01, cluster: 0000, size: 0A, attrId: 0000, encoding: 20, command: 01, value: 01 | msgMap:[raw:57270100000A00002001, dni:5727, endpoint:01, cluster:0000, size:0A, attrId:0000, encoding:20, command:01, value:01, clusterInt:0, attrInt:0, valueParsed:1]
1 Like
Yes, this is a harmless message (should be shown only as Debug log, not as a Warning!). On a future update of Marcus's driver, I will also remove the 'PLEASE REPORT TO DEV' text, it is not actual and not needed anymore.
3 Likes
@dnickel I did something similar to what you are trying to accomplish, but with the built-in "notification" app.
I select all battery devices, and created a notification that sends to my phone once per day when their battery level hits 60%. I've found that the Smarthings sensors tend to just die around 50%, so that gives me a couple days should I forget to address it when the I get the notification. Allows me to be pre-emptive in catching them before they die. There is a device activity check app on HPM that also works well to notify you should one of the attributes stop reporting. I use that for the Lutron battery remotes.
Sadly I have a lot of legacy ST motions, v1, that work great still but don't report battery. 
Those are the annoying ones as I use rechargeable Li batteries that regulate to 1.55 VDC.
Unfortunately when the die they don't fade away, they just turn off.
PS I think I'll try the "Last Activity at" in Device Activity Check app to see if it will catch these.
@kkossev
Another harmless message from the Water Leak driver as well.
I guess this will be common in all of them when you change to Debug.
dev:12442025-10-08 16:20:31.448warnUnhandled Event PLEASE REPORT TO DEV - description:read attr - raw: 8ADA0100000A00002001, dni: 8ADA, endpoint: 01, cluster: 0000, size: 0A, attrId: 0000, encoding: 20, command: 01, value: 01 | msgMap:[raw:8ADA0100000A00002001, dni:8ADA, endpoint:01, cluster:0000, size:0A, attrId:0000, encoding:20, command:01, value:01, clusterInt:0, attrInt:0, valueParsed:1]