Driver can most defiantly fix that. Are you using stock driver or a custom driver?
Check HPM and see if someone has already fixed the issue by applying a better curve. I had the similar issue with ST motion sensor- I built a driver with a better voltage curve.
I am using the stock driver. Haven't seen any other drivers for these. But I can take a look. Maybe the app just isn't for me for reporting purposes.
May have to take a look at what might be involved in making it work with a V4.
Refresh page and you will notice it doesn't really highlight any at all. When you select one, from the hand icon, it will select the correct device.
This is an HE UI quirk.
Thanks for at nice app, I really appreciate it 
In the screenshot from @jshimota and from my own setup, I can see that it looks like there is an issue in estmating the drain %/day and therefore the Est days gets estimated incorrectly:
A lot of 'Drain %/day' are 0.00 and therefore 'Est days' ends up at 365.
I haven't reviewed the code or data yet, so I haven't identified the technical root cause of this.
If the battery drain pr. day is so low that it can't be measued (even 0.01% is a very low so it should be), maybe a fallback method for the estimation could be done over a week or 10 days? Estimation over a week/10 days would also be a more 'stable' period of estimation, because daily variances are evened out.
1- Have your read through the tips page?
2- What are the devices that show HEAVY DRAIN and are the same type with driver?
The app reads the battery from the driver that device uses, and what displays in the device page.
Example: If the battery was at 100% 20 days ago, and today its at 43%... that would be a heavy drain and/or Poor Health of battery.
Thanks for your feedback
I used Gemini to examine the code and it sure looks like my issue is that the devices use very little power and therefore the 'short' sample period wont catch the low drain (which ends upin 0.00 drain %/day and off estimation of power):
I changed the sample window to be over 7 days to catch these lower power consuming devices. In 7 days I will have a good estimation
It also identified some other elements that can be optimized in the code for example the unneccessary reassigning of state variables:
and when futher asked about optimizations:
In 7 days I will see if everything is working or I messed it all up 
Thanks for your hard work with the app 
One thing worth separating out:
The samples array isn't a straight time-based average, it's a rolling window of the last 10 valid readings (FIFO, oldest drops off as new ones come in). So widening the window from 24h to 7 days makes it more likely a slow drainer logs a real drop instead of a 0, but if a device barely moves in 7 days either, or the driver just doesn't push battery events often, you can still see strings of 0s while it builds up real samples.
Also worth noting:
Gemini's read of the code itself was accurate, but it only had the app code to go on. It had no visibility into what device or driver is actually generating these readings, so it concluded "app flaw" without the one input that would confirm or rule that out. A 0.00 sample is a true reflection of what the driver reported, not necessarily a bug in how the app processes it.
Device(s)
What device/driver are you seeing this on? That's the missing piece from your post and from your post to Gemini.
Curious how your 7-day test looks once it's had time to run.
Device Type & Driver:
Once you give me the type of device/ driver and battery used. I will look at it further.
EDIT:
Actually, good timing, I just pulled up one of my own devices showing this exact pattern: a motion sensor at 85% with 0.00 drain and Excellent health. Confirms what we're talking about. It dropped from 100% to 85% at some point (a real sample), then sat flat long enough that those zeros pushed the older real sample out of the 10-sample window. Same mechanism, not app-specific to your device.
Good real-world case for why the 7-day window should help. Let me know how yours looks once it's run a while.
Okay, what is everyone doing for devices that do not report? I have several (mostly the old OSRAM/Lightify two button switches and some hue and tradfri button switches) that do not report any changes in battery level. They just work or do not. When they don't, I just switch the batteries and they work again.
I know it is a limitation of the devices I have (not hubitat or this app). But, they work well aside from battery reporting.
I know I get about 8-10 months out of using them from tracking the manual way. Any way that we can have the monitor create a "check battery" alert date for items that do not actively report? (i.e., when I change the battery, set an alert for that battery in XX Months/weeks/etc)
Do they ever report ANYTHING at all?
What driver is being used? is there not a custom one? or is this a hardware issue, for reporting?
For the OSRAM, using built in Sylvania driver. For the Hue, I think that is the built in as well. For the Tradfri remotes, using the custom Tradfri/Ikea drivers.
They work fine other than battery reporting. They just never report anything other than 100% until they die completely. I don't think the OSRAM's reported correctly on the original OSRAM hub or ST. So, I am pretty sure that one at least is 100% just bad hardware not actually reporting.
Li-Ion batteries can be the issue too: they’ll report as good right up until they’re not. Pretty common behavior.
There are a couple of community apps for device health that can alert you, but again, it’s dependent on the driver. Without getting myself too far down a rabbit hole, I’d check the custom drivers for your devices and see if they can be modified to report battery levels more frequently.
Also, I have smoke detectors that report fine, but once they hit 78%, they’re basically dead. I’ve separated those into their own rule so I can get an alert specifically for them.
At some point, when I have more time and more input from users, I may change the app to allow specific devices to have a manually configured battery threshold for alerts.
I will need a poll on this being a function and specifics to the need versus want.
Could a separate/additional handling be added to the code for devices that are defined to use rechargeables? Here is a sensor with a LIR battery that died in a manner that appears textbook to me - sharp, precipitous drop at EOL 12 hours from 100% to 1%. "they’ll report as good right up until they’re not" as you said. If would be awesome if Battery Monitor can pick up that sudden drop and notify us urgently.
Agreed. The crux of it is that every battery needs the type assigned correctly so the app can apply the right scaling and detection logic. This has to be a deliberate, user-owned step, since there's no reliable way for the app to infer chemistry on its own.
Accuracy matters here more than usual though. If a device gets mis-assigned (say, a normal alkaline tagged as Li-Ion), you could get a false urgent alert. Just as important, if an actual Li-Ion device gets tagged as something else, a real cliff drop could go undetected entirely. So if something looks off, the type assignment is the first thing to check and reassign.
We also need to land on whether this urgent alert should bypass Notification Snooze. Since the whole point is catching a battery that's about to die with little warning, I'm inclined to say it should bypass snooze by default, but curious what others think given that changes expected behavior for anyone currently relying on snooze to go quiet.
Edit Adder:
Separately, there's a related issue worth folding in here: some devices are functionally dead well above 0%. My smoke detectors run on 2 AA and start chirping around 78%, since the hardware has a conservative low-voltage cutoff for safety. Right now the app only treats sub-1% as Dead, so a device like this just shows as Fair/Good with weeks of estimated life left, when it's actually already telling you to replace it.
Two ways to handle that, depending on whether you control the driver:
If you can edit the driver yourself, the cleaner fix is rescaling the reported % at the source, so the device's real functional cutoff maps to 0%. That way Battery Monitor's health/drain logic is accurate automatically, no special-casing needed.
Not everyone has that option though, plenty of people are on stock or vendor drivers they can't touch. For that case, a per-device "dead threshold" override in the app makes sense, so devices like smoke detectors that are functionally dead well above 0% can still show accurate status without needing driver access.
I personally don't use snooze. Was on a 16 day vacation and just let those Pushover notifications come in. They've been configured to expire after a certain time anyway. Snooze probably would have been a better option, but 
In my case, if I was on vacation, "urgent" messages breaking through a snooze would be useless anyway - can't change a battery remotely, and I'm not going to ask a friend to pop over and change them. Again, in my case, I pre-emptively changed rechargeable batteries in the most crucial temperature sensors and doors in the house.
Maybe an option like some apps have - don't send at all / or send messages only if specified switches are on or off. Then snoozing would be moot if a master switch was turned on (or off).
I also like the per device option in addition to a more global "uses Li-ion". I have a few devices that could use that, but thankfully are not critical like a smoke alarm.
The issue here is they never report ANYTHING other than 100% (even when they are dead). Would be nice if I had a 78% to know that was dead. But, I replaced it today, the battery said 100% in the device tab and the app, and it was dead dead.... like no blinking light when I pressed the button dead.
Also, again, the Hue Switches and OSRAM are old tech.... very old tech. So, I don't expect miracles. My thought was now that I know they die in 8-10 months, have a way to just set a long term reminder based on when I manually update them as replaced with a manually determined timeframe. Just an ask.... that is all (otherwise, I will just keep using my spreadsheet that I have been using since I got them in 2016)
Understood- I'm still going to make an update for cliff detection. The issues your having is based on devices and drivers unfortunately. A device that never registers anything aside from 100% is a driver, or hardware, issue IMO. I would start small and try and figure out what is fixable for the device Drivers themselves. Its doable with a little patience with the driver and possibly your favorite AI buddy. LOL .
I am gonna go on a limb and suggest device...... again, these things were sold with a $40 hub (if I recall correctly) back in the day. The button controllers were reliable as all get out. The bulbs not so much, and I onlyl stayed on the Osram hub about a month before I went over to ST.
Not a major issue either way. Just was a thought for devices known to have battery reporting issues to have a "you haven't changed this battery in a while... maybe you should" prompt. I mean, the quick test is if they don't work... do they light up when I hit the button -> if no - change battery, if yes -> troubleshoot.
