I might have misunderstood, but lots of batteries don't have recorded changes over 1 or 2 days.
What im saying is if the sensor doesnt report any information over the last 48 hours and the sensor reads say 20% then it can learn that 20% is actually 0
There is not a confident way of saying that sensor is dead if 20% was last read and then it has not reported. What it can do is say itās stale OR mark it as āattention neededā
Changing the app based on driver behavior is not the rabbit hole I want to go down. If a device reports 20% then stopped responding, the driver needs updating.
I will look at better ways for a device to be flagged when it reads a low end battery level and then stops responding.
My suggestion is to do this in your routine that automatically detects battery replacements. I assume that is triggered by seeing a battery level jump up by at least a certain amount. So I assume that routine knows the new high level and the previous low level. Store the low level as battery minimum.
Great feedback and worth exploring, but there's a fundamental problem that makes it unreliable.
Auto-detection fires when a battery jumps from 40% or below up to 90% or higher. The app sees the pre-replacement level but has no way of knowing whether the battery was actually dead at that level or replaced proactively. Both scenarios look identical.
The only way to make a learned dead level meaningful would be to have the user explicitly flag whether the battery was depleted or replaced early, which adds UI complexity and relies on consistent user input over replacement cycles that could span years.
On the "app should know it's dead if it stops reporting" point, Battery Monitor only knows it hasn't heard from the device. It can't tell the difference between a dead battery, a device that fell off the mesh, a driver that stopped reporting, or a device the user intentionally removed. That's exactly why the Stale flag exists, it's the honest answer. If a device consistently dies at an atypical level without reporting it, that's a driver issue. ( This is one of the reasons I reworked the ST motion Sensor Driver)
The 25% Poor threshold and Stale flag already surface devices that are low and going quiet. Worth revisiting if a clean solution presents itself but not worth adding complexity for a feature that may not deliver reliable data.
[RELEASE] Battery Monitor 2.0 ā v2.5.27
Small maintenance release.
Battery scans now log at info level ā scan start and completion will appear in your Hubitat logs without needing debug mode enabled. Previously these were only visible with debug on, which made it harder to confirm scans were running on schedule.
Debug mode still provides full per-device detail on top of the info logs.
No other changes. All existing settings, history, and data are fully preserved.
1 Like
Note: Edited shortly after posting to correct the threshold percentages.
@JdThomas24, as I understand it, you automatically record a battery change whenever the battery goes from 40% (or less) to 90%.
Any chance you would consider making the threshold configurable or change the 40% threshold to 60%? Here is why:
- The lifespan of rechargeable LION batteries is greatly extended by recharging them before they go below 50%.
- I do not think that raising the 40% threshold to 60% will result in some batteries being marked as replaced when they werenāt replaced. (ie, False positives.) Sometimes the battery percentage reading will go up for various reasons, but Iāve never seen one go up by more than a handful of points.
Thank you for considering this.
Marc
You can log a manual battery replacement for batteries that are replaced, and do not meet the āunderā threshold. I will look at a possible way for the user to adjust the threshold based on their set up.
Thank you for considering it!
I already use the manual replacement option, but the simplicity of the automated process is such a beautiful thing that I would love to be able to use it for all of my recharges / replacements.
Marc
1 Like
I use several types of devices that have different ways to set up logging. They let me pick the logging level from the INFO/WARN/ERROR/TRACE/DEBUG list.
Please add them to the app.
The drivers are:
- Graber Somfy Shade Driver
- Zooz ZAC38 Range Extender
- Zooz ZEN Plugs Advanced
- Zooz ZSE11 Q Sensor
- Zooz ZSE43 Tilt-Shock XS Sensor
These are all user created drivers. There are probably more Zooz drivers by Joe Page jtp10181 with this type of logging
Edit: oops, posted to the wrong app. Meant to post to John Landās Device Status Checker.
1 Like
Hey, great idea in theory but Battery Monitor's debug logging is scoped to the app itself and what the battery data is doing, not how the underlying devices behave.
Reaching into driver settings that aren't mine gets messy fast. Different drivers use different setting keys, update cycles are out of my control, and one rename breaks things silently. Not a rabbit hole I want to go down inside a battery monitoring app.
A standalone device log manager would be the right shape for this as it discovers all your devices, finds the ones with a log level setting, bulk sets them in one shot. Clean scope, no weird dependencies.
This app will give you some info on device logging status; it will not set/reset logging levels though.
Battery Monitor 2.0 ā v2.5.28
This release improves auto-detection reliability and cleans up the Device Battery Management page. All health scoring, drain calculations, notifications, and the web portal are unchanged.
What's new:
Smarter replacement detection - Auto-detection now requires a second confirming reading within 48 hours before logging a replacement. A single invalid high reading will no longer create a false entry in your replacement history. Three background gates also run silently on every detection: a minimum of 3 prior drain samples, a minimum device age of 3 days, and a 12-hour cooldown after any replacement is logged. None of these require any configuration and they run automatically. For normal replacements the behavior is identical to before; the confirming read typically arrives within minutes via the next battery event or scheduled scan.
Note: replacement entries may appear slightly later than before as the app now waits for a confirming read before logging and this is expected behavior, not a bug.
Configurable detection thresholds - The battery level thresholds that trigger detection are now adjustable under Device Battery Management ā Auto-Detection Settings. Default values match the previous hardcoded behavior (was at or below 40%, jumped to or above 90%) so nothing changes unless you choose to adjust them. A minimum jump of 25% is always enforced in the background regardless of threshold settings.
Device Battery Management redesign - The management page has been reorganized into two clear groups: Actions (Device Actions, Bulk Actions) and Configuration (Ignored Devices, Auto-Detection Settings, Battery Types). Battery Types and Auto-Detection Settings each now open as their own dedicated page rather than expanding inline, keeping the main page clean regardless of how many devices you have.
What's not affected: All existing device history, drain samples, health scores, replacement logs, battery types, notification settings, and web portal configuration are fully preserved. No re-learning required.
3 Likes
Thank you!
Marc
First time playing with this and Iām super pleased by the featureset.
Couple small suggestions:
-
I have some Strips Guard sensors that are āIntegratedā batteries and not able to be replaced. I currently set as Other with āIntegratedā as text, but making an integrated choice would be great.
-
When selecting Other, you donāt get the ability to add the text until after you click done and come back into the list.
-
If you were able to extend the UI to refer to devices and by āDevice Typeā, it would make setting values easy (sort by type, then I can easily identify and set all my ZSE42 devices to CR2450)
-
Battery Replacement History should give you āReplaceā link - itās not intuitive where replacement is handled (but I found it and did one as a manually replace)
-
Iāve been noting replacement dates in comments right now ā so I have history, but I canāt āretroactivelyā add a date when batteries were installed as a replacement used the current date/time. Ideally I should be able to edit a date/time.
Three other thoughts I had, but no clear idea on what Iām asking for the first twoā¦
-
There are devices that are powered with battery backup (as an earlier poster noted). Normally theyād show as mains but sometimes (probably when main power is gone) there will be jumps down. Perhaps a check box to indicate the device uses battery backup, and if checked, track the trend on ānot 100%ā which would provide some level of idea about the battery used by the backup. Again, not fully thought out, and maybe thereās a way to query a device using main power but also equipped with batteryā¦.
-
There are devices that are āOutdoorā that might need to be tracked differently due to cold weather and the impact that it has on draining. The rate of drain etc would differ by time of year in some climates. Might be of benefit to track trend by 2 āseasonalā settings like āwarm rateā or ācold rateā.
-
Devices āto be replacedā probably are really āIgnoredā devices. Suggest moving the āignoreā into the Device Actions as a checkbox. A failed integrated battery can then be marked when I order a new sensor. HOWEVER, this is also a good candidate for Bulk Actions ā move the Ignored Devices selection activity in and treat it identically to bulk actions as the selection ability is the same, and you could handle it just as a 3rd action. Cleans up the UI and its more intuitive to put in the device and in bulk.
Plan for 2.5.29 Release:
Integrated battery type: Added as a first-class option in the Standard section of the battery type dropdown. No more setting Other ā typing "Integrated" manually.
Other custom text field: When you select Other from the dropdown the custom text field now appears immediately on the same page without needing to tap Done and come back in. (This is buggy due to HE page refresh constraints so I am working on testing internally)
Battery Types page split into two sections: The long flat list is now split into "
Not Yet Assigned" (open by default, shows count in red) and "
Assigned" (collapsed by default). Work through the unassigned section, and assigned devices stay out of the way. Both sections remain alphabetical.
Possibly on the Roadmap
Replace link in Battery Replacement History Adding a direct link from each history entry to Device Actions with that device pre-selected. Makes it obvious where to go to log a new replacement.
Editable replacement date When logging a manual replacement, you'll be able to set the actual date rather than defaulting to now. Useful when you replaced batteries a few days ago and want the history to reflect that accurately.
Not on the roadmap
Sort/group Battery Types by device driver type: I evaluated this but driver names in Hubitat are inconsistent across manufacturers and custom drivers, making grouping unreliable. The two-section split (assigned vs. unassigned) solves the real problem of finding what still needs to be set, without the grouping complexity.
Seasonal drain tracking: The app already handles this naturally. Drain rates will increase in cold weather and self-correct in warmer months. Flagging this as abnormal would create more noise than signal and would also rely on outside sources to stay on track.
Battery backup device tracking: Too niche and the data isn't reliably exposed by Hubitat across device types.
2 Likes
Battery Monitor 2.0 ā v2.5.29
What's New
Simplified Auto-Detection
Battery replacement detection has been reworked. Instead of configuring two separate thresholds (old level and new level), there is now a single setting: minimum upward jump % (default 30%). Since batteries only drain and never naturally recharge, any significant upward jump in level means a new battery was installed. The app confirms this across two consecutive readings before logging.
All existing safeguards remain in place: 3+ prior samples required, 3+ day device age, 12-hour cooldown, and two-reading confirmation.
- New Integrated battery type added to the standard list
- Page now split into two sections: Not Yet Assigned (open by default) and Assigned (collapsed), making it much easier to work through unassigned devices
- Two-column layout puts two devices per row for faster setup
- Selecting Other now shows the custom text field immediately without needing to tap Done first
Battery Summary & Trends (merged)
- The Trends page has been merged into the Summary page, now called Battery Summary & Trends
- Health column now shows trend inline: clean when everything is fine, flags with
Moderate Drain or
- Battery column slimmed down to a colored dot and percentage
- Recently replaced devices show a ā Replaced badge for 24 hours
- Collapsible Legend at the bottom for quick reference
Ignored Devices (moved)
Ignored Devices no longer has its own standalone page. It is now integrated directly into the workflow:
- Device Actions: new ignore/restore toggle per device
- Bulk Actions: ignore and restore available as bulk actions
- Device Battery Management: shows a summary of currently ignored devices with count and names
Device Actions (reorganized)
- Cleaner layout: description, device selector, info card, actions, ignore, battery type, history
- Log Replacement and Reset Drain History now displayed side by side
- Replacement History collapsed by default
- Device info card refreshed with a cleaner style
- Device names are now clickable links (LAN only)
- Type column now shows pill badges: Auto, Manual, Restored instead of single letters
- Dates normalized to MM/DD/YYYY format for all entries
Web Portal
Updated to match the new Summary & Trends table: slim battery column, Health & Trend merged with divergence flagging, consistent with the in-app view.
General UI & Fixes
This release had a significant focus on UI consistency and usability across all pages.
Navigation and page structure:
- Blue pill badges added consistently across Device Actions and Bulk Actions section headers
- Page descriptions are now bold with muted hint text below, matching a consistent pattern across all action pages
- LAN-only warning on the Summary page changed to a small red pill badge instead of a large red warning block
- Links now open in a true new tab, eliminating the Bad Message 431 error some users encountered
Summary & Trends table:
- Health & Trend column now shows clean health-only text when everything is normal, and flags with a trend indicator only when something needs attention
- Moderate drain now labeled "Moderate Drain" for consistency with "Heavy Drain"
- Recently replaced badge styled as a blue pill for better visibility
- Info box above the table condensed to two lines with a collapsible Legend section below the table
Device Actions page:
- Sections reordered to put the most-used actions first: device info card, actions, ignore, battery type, history
- Device info card given a distinct style to stand out from the action sections below it
Auto-Detection Settings:
- Blue info box condensed to the core concept
- Yellow warning box updated with an example showing what will and will not trigger detection
- Warning threshold updated
Consistency fixes:
- Section title bold styling now consistent across all pages
- Status labels (On, Off, Enabled, selected) use consistent color styling throughout
- Date format changed to MM/DD/YYYY throughout the app and portal
- Replacement history capped at 100 entries to reduce app state size
This update took 45+ iterations to work out all of the bugs and clean up the UI. I think i caught everything BUT if anyone finds a bug, please report it ASAP.
1 Like
Battery Monitor 2.0 ā v2.5.30
Bug Fix Release
Recently Replaced Badge Not Displaying
After a battery replacement was detected or manually logged, the ā Replaced badge on the Summary page was not appearing in some cases.
The cause was an internal check that cleared the badge if the new battery reported below 95%. This was too aggressive for a new battery reporting at less than 95. Thsi can be normal for shelved batteries.
The check has been removed. The badge now only clears after 24 hours as intended, regardless of the reported level.
Who is affected: Anyone who logged a replacement (auto or manual) where the new battery reported below 95%. The replacement was logged correctly in Battery Replacement History but only the visual badge on the Summary page was affected.
No other changes in this release.
1 Like
Battery Monitor 2.0 ā v2.5.31
Bug Fix Release
Pending Sample Progress Missing from Battery Summary & Trends
When the Trends page was merged into the Summary page in v2.5.29, the sample progress indicator for Pending devices was lost. Devices in the learning phase were showing only a chart icon in the Health & Trend column with no indication of how far along they were.
The progress display has been restored. Pending devices now show inline progress in the Health & Trend column:
2/5 samples Ā· 3/5 days
This matches the behavior from the previous Trends page and lets you see exactly how close a device is to clearing Pending status. The web portal has been updated to match.
No other changes in this release.
1 Like