From the app Battery 2.0 app "Help & Info" section. [Emphasis added] by me. @JdThomas24 can correct me if I'm wrong. 
Last Battery shows when the app last received a battery reading — from a scheduled scan [by the app] or device event [reporting initiated by device]. It is independent of Last Activity. A device can be recently active but show an old Last Battery timestamp if its battery level has not changed or reported. This is normal.
This is correct- if battery has not changed, nothing logs. It needs real world examples of battery drain.
So if its 100% and stays that way, there is not anything to log or set for a trend example.
I did however discover a trend bug just now that i will be patching shortly.
Battery Monitor 2.0 Release v2.4.3 - via HPM
Bug Fixes
- Battery Trends showing 0% devices as 100% — Fixed a Groovy truthy-check bug where devices reporting 0% battery were incorrectly displayed as 100% (Excellent) in the Battery Trends page. Battery Summary was not affected. Devices with dead or fully drained batteries will now correctly show 0% in both views.
- Heavy Drain false positives on locks, sensors, and smoke detectors — Fixed a long-standing issue where the 50% drain adjustment for high-reporter device types (locks, motion sensors, contact sensors, smoke detectors, CO detectors) was never actually applying. The root cause was
getData().deviceTypealways returning empty on Hubitat — meaning all devices were calculated at full drain rate. Now usesdevice.nameanddevice.typeNamewhich correctly reflects the driver name. Locks and sensors that were showing Heavy Drain at 3.00%/day will now calculate at the correct adjusted rate and should trend toward Moderate or Stable over time as fresh samples accumulate.
New Features
- Reset Drain History — A new action is now available at the bottom of the Battery Trends page. It allows you to clear drain history for one or more devices without logging a battery replacement. Health returns to
Pending while fresh samples are collected. When to use it:
- A lock, sensor, or smoke detector is showing Heavy Drain from stale early samples
- You want to clear inaccurate drain data after updating to this version
- A device was moved, repaired, or had its reporting frequency changedWhat it resets: drain samples, drain rate (back to 0.3%/day default), trend (back to Stable) What it does NOT change: battery replacement history, last battery level, last seen date, or any other device state
This action only runs when you explicitly submit it — it never fires automatically on app save or hub restart.
- Reset Drain History documentation — Added to the App Guide & Reference info page with full explanation of when to use it, what it changes, and what it leaves untouched.
Recommended Action After Updating
If you have locks, motion sensors, or smoke detectors showing Heavy Drain:
- Go to Battery Trends
- Scroll to the bottom and tap Reset Drain History
- Select your affected devices
- Confirm and submit
- Health will return to
Known Issue
- Page scroll — Summary, Trends, and History pages may open scrolled to the bottom on C7 and C8 hubs. The
rawHtml: truescript override is the current mitigation — root cause under investigation.
I installed a new instance 4 days ago when it was released to HPM. I installed a fresh instance and deleted the beta instance I'd been using.
Yes, I've read the "Help & Info" section multiple times.
Just now one device reported a battery change. Apparently my devices just aren't chatty.
That device — it's an Aeotec motion sensor — still shows 0/5 samples. So I guess my question is... what constitutes a sample?
@JdThomas24 I just updated via HPM and I do not have the Reset Drain History at the bottom of the Battery Trends page.
try again------- i made a mistake. 
Working on Pentair APP and SmartThings driver at same time. I changed the wrong manifest.
^%$#@#$%^%$#
How Battery Monitor Learns About Your Batteries
Think of it like a notebook. Every time a battery drops even a little, the app writes it down. After enough notes, it can tell you if a battery is healthy or draining too fast.
What gets written down (a sample):
- Battery level dropped since last check
- Battery level same for 24+ hours
( This is a point of contention ATM)
What gets ignored:
- Level unchanged and less than 24 hours passed
Brand new install: Everything starts at 0. That's normal. Give it 1–2 weeks and the notebook fills up on its own.
Already had the app and just updated: Your history is safe — nothing is deleted on update. BUT if your locks, sensors, or smoke detectors were showing Heavy Drain before updating, that was a bug. The bug is fixed in v2.4.3 but the old wrong notes are still in the notebook.
The fix: Go to Battery Trends → scroll to bottom → Reset Drain History → select the affected devices. Fresh accurate notes will start being collected immediately.
Why does it say
Smoke detectors and rarely active sensors get a pass after 14 days with just 2 samples since they barely move.
Want results faster? Set Scan Interval to Hourly on the main page.
This is weird and it may just be me. When I click on Update in HPM it searches and comes up a SmartThings Motion Sensor Driver (installed 2.4.2 current 2.4.3) and then when I choose that and hit next it brings up the log notes for this last update of Battery Monitor 2.0. Any suggestions?
Edit: I have not SmartThings Motion Sensor Driver installed.
yeah - that is the issue and its fixed..... or i thought it was.... let me look again.
Edit: its fixed. I think HPM takes a few to grab the fix....
Try again and if it doesn't work. Go to repair and repair it.
Seems like HPM picked up the update, but it says 2.4.2 instead of 2.4.3 (which is what I think you expected).
New reset is there in the code that got installed via the update: 
yes - i didn't add note because i messed up the manifest and the name got hung up for another user...... @#$%^&(&^%$#@
yes - that's new. i will push another clean update with notes as 2.4.5 so i can get it all lined up.
getData().deviceType always returning empty on Hubitat — meaning all devices were calculated at full drain rate. Now uses device.name and device.typeName which correctly reflects the driver name. Locks and sensors that were showing Heavy Drain at 3.00%/day will now calculate at the correct adjusted rate and should trend toward Moderate or Stable over time as fresh samples accumulate. Pending while fresh samples are collected. When to use it:
If you have locks, motion sensors, or smoke detectors showing Heavy Drain:
Pending — fresh accurate samples will build over the next several daysrawHtml: true script override is the current mitigation — root cause under investigation.Mistakes happen. They happen to everyone. The old saying goes if you don't make mistakes you aren't trying. I think I can speak or all of us in saying you have tried so hard there is bound to be a hiccup or two. We worked through it. All is good. You have a great product that all of us appreciate.
Battery Monitor 2.0 — v2.4.6
Bug Fixes
- Last Battery column not updating on scans or Force Scan — A previous fix caused the scan timestamp to stop updating on every scan, freezing the Last Battery display column. Fixed by splitting into two separate fields:
lastScanDatedrives the Last Battery display and updates every scan, whilelastDatedrives the drain calculation window and only updates when a sample is recorded. Both now work independently and correctly.- Reset Drain History could cause inflated drain spike on first sample after reset — When resetting a device with existing history, the sample window date was not being cleared. The first new sample after a reset could calculate drain against a very old date, producing a falsely high reading. Both date fields are now correctly reset when Reset Drain History is used.
Do I Need to Reset Drain History?
You do not need to reset anything unless one of the following applies:
- You used Reset Drain History on a previous version and a device jumped straight to Heavy Drain shortly after — the inflated first sample bug may have affected it. Reset those devices again to get a clean start.
- You still have locks, sensors, or smoke detectors showing Heavy Drain from before the v2.4.5 updates — use Reset Drain History on those devices to clear the stale samples. Fresh accurate readings will build within a few days.
Everyone else can update and carry on — existing history and replacement logs are not affected.
Known Issue
- Page scroll — Summary, Trends, and History pages may open scrolled to the bottom on C7 and C8 hubs. The
rawHtml: truescript override is the current mitigation — root cause under investigation.
ALERT ALERT ALERT ALERT ALERT
Battery Monitor 2.0 Announcement 4/10/26
The **Hubitat Package Manager ** has historically used "Match Up" to scan installed apps and drivers and link them to community packages. While this process was based on name matching - which "isn't an exact science" - HPM version 1.9.0 and higher is now relying on unique identifiers (IDs) in the package manifest. This will ensure that the updates are detected properly.
Why Package IDs are Critical
- Accurate Matching: Relying only on app/driver names often leads to mismatches. Mandatory IDs ensure HPM monitors the correct repository for updates.
- Version Control: HPM uses the ID in the JSON manifest to track versioning for apps, drivers, and bundles.
- Platform Compatibility: Recent Hubitat platform updates (v2.3.6+) changed how HPM interacts with the hub's internal lists, making structured IDs more vital for stability.
Although this app works, and updates correctly in its current form, this process will be needed for future proofing the link and updates. There will be more to come soon. Goal is to prevent the current app instance from being orphaned from HPM once an ID is assigned
What that really means?
- New update will install as stand alone if MATCH UP in HPM does not work. You will have the old app instance still on the hub but will not receive updates while the new instance, also on the hub, will be the new rookie on the floor.
MORE TO COME.... Comment if you have insight.
yeah, my comment is update on github and all we need to do to get latest is this.
Loving this app, many thanks..
That will work for updating but the HPM instance will still be orphaned because a match up issue with the repo manifest.
The unmatch and match SHOULD work and I will be internally testing this soon.
Battery Monitor 2.0 — v2.4.7
Improvements
Dead Battery Detection — The app now tracks consecutive 0% battery readings. After 3 or more scans at 0%, a device is confirmed dead and displayed as
Improved Door Lock Handling — Door locks are now treated separately from passive sensors. Because locks drive a motor to operate, they have a genuinely higher baseline drain. Locks now use a 60% drain reduction (up from 50%) and higher stable and moderate thresholds. A lock that was previously showing Moderate or Heavy Drain may now correctly show Stable. This is not a data reset — existing samples are reused with the new calculation immediately.
Sample Quality Column — The Battery Trends page now includes a Sample Quality² column showing how established the health rating is for each device. Low = just started collecting data, Full = fully established. More samples means a more reliable health rating.
UI Improvements — Health ratings in the Summary and Trends tables are now color coded — green for Excellent/Good, orange for Fair, red for Poor. Pending devices show a grey progress indicator. Dead devices show dashes in place of drain and health data.
Updated App Guide — The App Guide & Reference page has been updated to document dead battery detection, the lock vs sensor distinction, and the new sample quality system.
Do I Need to Reset Drain History? You do not need to reset anything unless one of the following applies:
- Your door locks were previously showing Moderate or Heavy Drain — the new lock-specific thresholds will correct this automatically on the next scan. No reset needed.
- You have a device stuck at 0% that has not been flagged as dead yet — run a Force Scan to allow the new dead battery detection to confirm the reading across consecutive scans.
Everyone else can update and carry on — existing history and replacement logs are not affected.
Known Issue
- Page scroll — Summary, Trends, and History pages may open scrolled to the bottom on C7 and C8 hubs. The
rawHtml: truescript override is the current mitigation — root cause under investigation. (No Timetable)Coming Soon
- HPM unique package ID — A unique package ID will be added to the Battery Monitor HPM manifest once internal testing is complete (eyes heavily rolling). No rush on this one — the app is updating correctly in HPM without it. Since this is a single app with no drivers, duplicate installs are not a concern. If HPM is not detecting updates correctly in the meantime, use Un-Match followed by Match Up to re-link the package. I do not foresee this needing to be done. (ID will be assigned only when needed)
Download the Hubitat app
Thank you very much for the additional fixes/updates!