Most battery blueprints are a finished notifier. They scan every device that reports a battery, find those under a threshold, and push a notification on a configured schedule. That is the whole product. The notification is the end of the line, and nothing else can read the result.
Battery Sentinel is not that. It is a template sensor, not a notification automation. It reports but does not alert. It publishes a clean signal, the count and the list of what is running low, and you build whatever you want on top of it: a notification, a dashboard, an automation, a badge. One sensor to rule them all, one sensor to find them, one sensor to bring them all, and in the dashboard bind them. That is enough of that.
Battery Sentinel is the sister of Entity Sentinel. Battery Sentinel answers “what batteries are running low.” Entity Sentinel answers “what stopped reporting.” Build both for full coverage, or just the one you need.
You Build the Watch List, So You Watch Exactly What You Want
Other blueprints scan every battery-reporting entity in your house and hand you an exclude list a mile long to carve away what you do not want. Your phone shows up at 15 percent, your watch at 12, your laptop, your tablet, a stack of remotes, and you spend your time quieting things you never wanted in the first place.
Battery Sentinel works the other way. You build an include list of the batteries that actually matter, the door lock, the leak sensor under the water heater, the smoke detectors, and it watches those. Nothing else ever appears. Your phone is not in the list because you did not put it there.
The easiest way to build that list is a label: tag a device in the Home Assistant interface and it is watched, untag it and it is gone, no YAML to edit. Areas, devices, and specific entities work too, and there is an exclude that always wins. Getting the scope right is what makes the sensor yours, and the Battery Sentinel README shows how to set it up properly, labels included.
Import
Before you click: Battery Sentinel is a template blueprint, not an automation blueprint. After import, it will not appear in your automations list and there is no Create button. A template blueprint becomes a sensor through a short piece of YAML you add to your configuration once. The Battery Sentinel README has the full setup with a ready-to-paste
use_blueprint:snippet, added to yourconfiguration.yamlor a package file. Read it first.
Or paste this URL into Settings, Automations & Scenes, Blueprints, Import Blueprint:
https://raw.githubusercontent.com/TheThinkingHome/Automations/main/blueprints/template/battery_sentinel.yaml
One Sensor, Many Consumers
Why is this a template sensor and not an automation? Because an automation fires once and the results are gone. A sensor persists, so once it is configured, anything in your system can read it: your own automations, your own dashboard cards, scripts, other template sensors. Two consumers are already published:
- Sentinel Notify turns the sensor into a live shopping list and change-aware notifications: every low battery becomes an item on the list, by name, with its percentage, battery type, and area, and your phone hears only about what is new, never again about the ones you already know. Check an item off to acknowledge it; a replaced battery quietly disappears from the list. Read the Sentinel Notify README.
Those are two consumers of the same sensor, not two separate products. The devices list is plain structured data, so you can just as easily gate an automation on it (hold the robot vacuum if its own battery is low), drive a badge with the count, or show a conditional card only when something needs attention. The invitation is the point: build your own consumer and it works the same way.
What the Sensor Looks Like
Open Developer Tools, States, and here it is with a couple of low batteries flagged:
state: 2
ok: true
sentinel_type: battery
sentinel_version: 1.0.3-beta
total_monitored: 77
devices:
- name: Front Door Lock
entity_id: sensor.front_door_lock_battery
area: Entryway
level: 20
battery_type: AA
- name: Water Heater Leak Sensor
entity_id: sensor.water_heater_leak_battery
area: Utility
level: 19
battery_type: CR2032
unavailable_count: 0
unavailable_entities: []
The state is the count: two. The devices list is the detail, each low battery by name, area, level, and type. That list is the thing every consumer reads: a notification formats it, a dashboard renders it, an automation gates on it. Offline batteries are collected separately in unavailable_entities with their own count, so a device that dropped off the mesh is never mislabeled as low.
Where It Is
This is a beta. I run it on my own system, and it has been through a heavy adversarial testing, but homes vary, what is important to me is trivial to you. Treat this as the point where your use makes it better. If you build something on it, or you hit an edge I did not, I want to hear it.
Questions, bug reports, and use cases I didn’t think of are welcome here. Half the fun of this is seeing where other people aim it.
- 1.2.0 - One row per problem: a dead device appears once, under its own name; every entry carries
kind. - 1.1.1 - The
scan_intervalinput is now echoed as an attribute so dashboards can display the check cadence. No behavior change. - 1.1.0 - First STABLE release. Every entry gains
since,last_seen, andage; for a low battery. - 1.0.3-beta, July 2026. Initial public release.
