I'm pretty sure that the only reliable way to do this is based on the "device x hasn't been heard from for y period of time" -- not any sort of battery check. Even this approach is device specific.
Several years ago, while I still used ST, another user asked my help in writing an app that did this for a very specific sensor he used, a door jamb embedded contact sensor. I don't remember the details, but the app wasn't hard to come up with, and he reported that it solved his problem completely. I'm pretty sure that he wasn't looking for anything more than some notice that the battery was probably dead, and certainly not quickly after the event. He had some specific means of being notified that he wanted. An app like this does not tax the device battery any more than whatever its reporting cycle does.
Having said that, I'm not a big fan of the concept that somehow the hub should be reporting battery life, or death, as some basic function, or any kind of device health. That only leads to false expectations. These are cheap consumer devices. If you want security and knowledge that a device is actually working, use wire powered devices, not battery devices. Don't try to turn a sow's ear (a battery powered consumer device) into a silk purse!
I've found that using any of the "device watchdog" type of apps helps fill in the gaps between hubitat reporting nothing for device health and some sophisticated battery analysis. Just because it can't be done "perfectly" doesn't mean that it can't be made "better" by doing something in between.
Yes, a device may be dead for up to 24 hours before I am alerted due to inactivity, but I'm OK with that. My important/security/high availability items are either on other systems that can be fully monitored, or have a backup/fallback if the sensor goes out.
Been using and installing proprietary wireless protocol devices from Visonic for years, before Tyco bought them and seemed to downplay the line. (Likely because it was a beautiful solution for DIYs who wanted to skip installers and Central Station Subscriptions, both aspects are big money maker for Tyco). The line eventually became the core of Xfinity's Zigbee installs.. as production seemed not to be located, nor controlled, the way it once was... quality seemed to slip a little.
Back on point...they were affordable wireless security systems, and devices. Never felt insecure about losing a sensor, for battery or otherwise, and not knowing about it. The panel managed this quite reliably. Stuff was rock solid once appropriately located, and they used adequate batteries that sipped power for YEARS depending on the sensor.
This can be done affordably for simple sensors. I'd gladly pay more for sensors to get the wireless package quality Visonic use to be known for. Truth is, some of the Xfinity Zigbee sensors I've bought that are Visonic ARE some of the best battery sippers I have in service. Now if we can only get a better heads up in HE when their batteries ARE on their last leg (or dead).
Today's catalog:
A key phrase from their product line description:
Powerful diagnostic tool indicates RF link quality, based on the previous 24 hours’ statistics and on-demand bi-directional measurements, displaying immediate problems and enabling verification of the installation during house setup.
As an aside: My mailbox door sensor, a Visonic MCT340E, just reported 135F. Takes a licking and keeps on ticking....in sub zero too.
I agree with @JasonJoel ..... in my (MQTT & Node-Red based) system I implemented a "lifeline" concept.
Then I make sure that all my drivers / integrations across all my hardware / technologies "ping" a device-specific lifeline MQTT topic when there's any activity from the device.
This makes it really easy to raise alerts or highlight devices that haven't been seen for a period of time. Plus, each lifeline can be configured with appropriate "not heard from" timings that are specific to the particular device / technology. You can also do funky stuff like look at graphs of activity over time to allow you to fine tune those timings.
Some devices just don't play ball though, for example some ZigBee button devices can be totally silent until somebody uses them. No activity at all, not even battery reporting and a non-listening device so no way to "refresh" it.
So if nobody touches it for a week you've got no idea if it's dead or alive until you go to use it. At the moment the best I can do for devices that display that type of behaviour is to have a "not heard from" time generated from its historic activity.
Of course I could also replace them with something with better behaviour at a higher cost, but there's always going to be something that won't conform so I'd rather just make the system handle these outlier cases as close to perfect as it can....
Or if all the Hubitat drivers scale V to % the same way (likely for zigbee, not sure for zwave drivers), if Hubitat told people what that standard conversion is they could just covert it back to V themselves and do whatever the heck they want to with it in a custom app/node-red/Grafana/whatever.
No coding required on Hubitat's part.
For me, I'll just stick with low battery notifications + activity monitor.
Interesting, my MCT340E absolutely sucks the life out of the battery. Inside my garage so limited extreme temperatures. A repeater within 10 feet.
I discovered the dead battery using the "Device Activity Check" app which initiated an SMS message stating the Garage Read Door has not reported in within the last 24 hours.
I personally prefer the voltage be presented and not the %age. The lithium discharge curve is so non linear the %age has little to no meaning. This is especially true with very low current draw devices.
I would prefer to see V too. But if hubitat doesn't want to go back and re-do every single driver, then the easy way out (other than do nothing) would be to just say how the drivers are converting V to % (as the devices report in V to begin with, not %) and then users can put it in any units/format they want in an external system.
I would bet that the vast majority of Devices never disclose the battery voltage. I have some experience with the Aeon MultiSensor 6 and this is what the manual has to say about Battery:
No voltage offered, just percentage.
I know that the SmartThings Presence Fob sends a battery value, tenths of volts, but it's rare in the list of devices for which I've read the manual.
Most but not all zigbee devices report voltage, some report volts and percentage, some percentage or volts only. In cases where a device reports both, we use percentage.
Are there hardware requirements for different devices that require different volt to %age conversion? Maybe Alkaline vs lithium.
If that is the case perhaps we could get those numbers
Not following, in any event reporting voltage isn't going to make battery reporting better, I've spent a lot of time trying to calibrate it, it's a crap shoot, some of these 3 volt devices will operate down to 1.5 volts given sufficient current.
