Alkaline battery reporting has never been any good either, in my experience.
When you get a better understanding of how often various devices you own should be reporting an event or otherwise checking in with the hub, you can create device activity check instances with corresponding monitoring periods.
I second if using lithium batteries don't go to far down the rabbit hole. I still just use the notification app to notify me of low batteries but I have the threshold set extremely low for that exact reason. They most of the time will be between 90% and 100% one day and then when they fail they are between 0% and 10% the next. I have it set low and when they fail I replace them.
I have a lithium battery powering a temp sensor in my freezer. Due to the cold when I put it in there it went from 100% to 12% in less than 24 hrs. It has hung at 12% for months. I am intrigued just to see how long it does go before it stops reporting.
Yes, I noted the dates that I installed the device and will note the dates that I install new batteries. Unfortunately I just found out I have bigger problems. You can see in the screenshhot that 4 od 5 of the Aqara sensors are not reporting the battery levels at all.
I asked AI about the battery issue and here is what it suggested. I guess I'll take a look for the drivers.
*** How to Fix or Improve Battery Reporting ***
Open up each device's details page, click CONFIGURE for each of these devices, wait a few seconds, and then click REFRESH (if available). This might help to kickstart the reporting of Battery levels.
Also, make sure all of your identical model leak sensors are using the same Device Driver Type. If you decide to change the Driver Type, please be sure to then click SAVE and then click CONFIGURE after the save process completes.
Thanks, I tried the configure button and some other changes but that didn't work. I also tried the driver below which did not work either. I'm going to go grab one of these sensors and see if triggering a leak snaps it out of it. Even if it does I'm inclined to go with a different sensor. I started out with Zooz ZSE42 which are about $40 each. The Aqara are about 3 for $40. So much for saving money!
I understand that battery reporting by many of these sensor is flakey. But flakey is better than none at all!
Xiaomi Aqara Mijia Sensors and Switches
I disagree.
Dealing with bad data is worse than no data, IMO.
With no data, you can plan accordingly. For example, don’t bother using battery reports and instead use a solution like device activity check 
.
With bad data, e.g. #s that are usually wrong, and perhaps occasionally right, how can you ever know what to do with that information?
Totally agree.
Case in point - sometime in the last 24 hours, one of my leak sensors, paired to z2m, dropped off. The last reported battery level was 3016 mV.
So my first inclination was that the device had fallen off the mesh. When I couldn’t get it to re-connect, I checked the battery using my multimeter. It was 1.65V - clearly insufficient for it to function.
With lithium cells, the drop-off is rapid and precipitous.
Device activity check is a far superior measure of a device’s presence on the mesh. For my Hubitat devices, I use @bertabcd1234 ’s app. And something equivalent in node-red for my z2m devices.
I don't know what the "flakiness" of power reporting looks like. I want to get a sense of the batteries longevity with flakiness factored in. Much better than nothing IMO.
I do intend to use device activity check eventually. But right now I'm switching back to the Zooz ZSE42 sensors. I just don't trust the Aqara which uses a non-standard Zigbee implementation. Look at how the model number is reported below.
There's an example posted right above your post.
Probably just a font that isn’t displayed correctly. Maybe Chinese characters.
ETA: oh and don’t believe everything AI suggests, like using Markus’ drivers 
.
For one of the best values, check out the IKEA products.
Badring Leak Sensor US$11.99
Combined with @dandanache's excellent drivers.
His drivers also implement the HealthStatus check to determine when device communication is lost.
Figures, I just ordered a dozen Zooz ZSE42 sensors from thesmarthouse.com. They were $24.95 compared to $38.95 at Amazon. Now that I know there is no such thing as a health status in Hubitat, I would hope they implement one eventually. I know there is Device Activity Check (Which I haven't used yet) but having something integrated with Hubitat would be desirable.
-Thanks
You still seem to be under the impression this is some kind of platform-level shortcoming with Hubitat. It is not.
Hubitat supports health status for any device drivers and devices that are correspondinly capable. But not all are, and that's especially true for battery devices where maxing battery life is a top priority.
A primary way for battery-device manufacturers to maximize battery life is to restrict the device's comms to a minimum. Hubitat has no direct influence over that -- it can only ever work within the device's own capabilities.
@zbernie123 - what @hydro311 wrote is 100% accurate.
There are several misperceptions in this topic. Here are three:
That the hub is in constant communication with devices. If battery powered devices did that, they'd run batteries down very quickly. So battery powered devices only report when there's a change in their state, or once every 12-25 hours if there's no state change. Did you know that the zigbee protocol requires battery-powered devices to check-in with the coordinator (hub) only once in 25 hours?
That device health status is of value, or can be interpreted reliably on the basis of battery reports. Battery reports are worthless on any platform. I have an example from zigbee2mqtt listed above.
That apps/drivers contributed by the community are inferior (or less trustworthy) than those created by Hubitat engineers. As with any platform, it is good to be skeptical of code from random people. With that said, there are several members of this community whose code is being used by Hubitat staff. Some members of staff started out as members of the community whose contributions were so valuable that they were recruited to join Hubitat staff. @bertabcd1234 is a perfect example of someone in that category. I don't have a lot of 3rd party code on my Hubitat, but I've used his Device Activity Check for years - long before he joined Hubitat.
There should be some type of "platform-level" monitoring like SmartThings has. This includes devices such as water sensors. I don't know how well it works. Essentially AI says that Hubitat does not have health monitoring, but SmartThings does:
SmartThings Device Health Overview
SmartThings uses a device health service to track:
See my response to hydro311.
Do a search on their forums and see how unreliable it is. 
(That response also isn't entirely accurate or relevant -- many of the features mentioned are device features you should find on most platforms, including Hubitat.)
I'm going to ask again if you can please consolidate multiple successive replies into a single post, using quoting (if necessary) to make it clear what you are replying to:
This is in line with the community guidelines to keep the forum tidy. Thanks!
I understand AI's momentum is now all but unstoppable (and that's fine), but as it's still in its infancy, it is currently rife with both misinformation and incompleteness.
Please do yourself a favor and stop using it as a singular (or even primary) source of information.
Each of these points has been dealt with earlier in this thread, so I have zero idea why you've chosen to raise them yet again. Here is the bottom line on each of these:
Connectivity status - interpret this with caution. For instance, for a battery powered zigbee device, "online" only means that the device has checked in once during the last 25 hours. This is part of the zigbee spec. There's nothing any hub manufacturer can do to change that. @bertabcd1234's Device Activity Check app provides actionable information for those Hubitat users who need it.
Battery level - totally worthless on any platform. I had a device report a battery level of 3016 mV (or 3.0 V) about 14 hours before it died. The actual battery voltage was 1.65V.
Signal strength - this only reflects the signal at the time the last communication from the device was received. Zigbee devices change the route to the hub/coordinator pretty damn frequently. Z-Wave device much less so. In any event, by the time the information is displayed by the hub, it is already of out of date. Hubitat does provide graphical maps with some of this information, but IMO it is of very little value, while no doubt visually appealing.
Tamper alert - useful for those devices that support it. And like any other platform, Hubitat reports this for those devices that support it.
It would be doing the rest of us here a favor too. Less misinformation to squash .
Download the Hubitat app
