Request: Please revise the "battery level" calculation implementation of generic drivers, such as "Generic Zigbee Shade."
I operate multiple Third Reality Zigbee Smart Shades, and use the OOB Generic Zigbee Shade to great success. However, I suspect raw values related to power and battery voltage from hardware may be parsed by the driver assuming 1.5V Alkaline Batteries are used.
Being able to direct the driver, via exposed config preference on a device, to parse those same raw values using voltage characteristics specific to different chemistries such as Nimh (1.2V) and Ni-Zn (1.6V) would allow for more accurate battery level values and further enrich programmatic battery level alert notifications for more timely battery changes.
I've pretty much given up on 1.5V Li-Ion, since the integrated voltage converter maintains constant voltage until very shortly before the battery is drained. This is a hardware problem with Li-Ion Batteries. However, a reach goal may be to incorporate a Li-Ion Battery Selection amongst other chemistry profiles and a day counter becomes active to reflect when the battery was last changed, superseding the numeric battery level device driver value.
I suspect the battery level logic is a common implementation, so I could see a broad array of use cases greatly improving if generic drivers across the board received this enhancement.
The Generic Zigbee Shade driver just gets the battery (half-)percent remaining as reported over Zigbee, then divides it by two to get the percent. That is rounded to an integer, then passed as the value of the event by the driver. There is no real calculation going on.
This is standard behavior of Zigbee cluster 0x01 attribute 0x0021, battery percentage remaining.
Some Zigbee devices also report voltage using attribute 0x0020. This only gives you 0.1 V resolution, so it might not help as much as you want either. Some devices might do both, and some may do neither, as both attributes are optional per the spec. Voltage is used in some drivers that don't report percent directly, but most generic drivers use the device's own percentage calculation (and I can't imagine ones that support both would use radically different data for either), including the one you're asking about.
FWIW, I'd guess Matter does the same as Zigbee (I haven't looked but that's basically the inspiration for the application layer of the spec), Z-Wave normally does percent from the device, and other protocols may vary -- so you probably won't find much different elsewhere either.
This comes up from time to time, and it while it would be great to do, many who try end up concluding that obsessing over battery levels is not worth it. This is one of the reasons I wrote Device Activity Check, which you can use to look at hints that a device might actually have some problem, perhaps a dead battery that prevents it from talking to your hub (or battery reports if you really want to, though that's not what I'd start with). There are or were similar options, as well, though I'm not sure if any are still maintained. But in general, this approach is more likely to work better for most devices.
So Im gathering that what is reported drivers is pass-through, and the battery level is implemented at firmware level.
Your knowledge about attribute 0x0020 is interesting. How prevalent is its availability? 0.1V resolution would be workable for an implementation like Im suggesting. Maybe could add to the wishlist burndown as an alternative hub sw battery level implementation?
Personally my interest is more for 1.6V Ni-Zn. However, I've got more experience using 1.2V Nimh. I haven't had any Ni-Zn Batteries get drained yet.
That voltage attribute would work fine. The charge state to cell voltage could be a tabular lookup, like a dictionary, and an alternative battery level calculation implementation could make is so freshly charged Nimh result in a device reporting 100% instead of 65-80% with the pass-through.
There is a community driver, iirc a multi-device driver for zigbee soil sensors. I dont recall which it is, but when i tried it on some devices it exposed values to configure what voltage is nominal and which indicates low battery. It isnt quite what i have in mind, but would be a halfway example.
