{"id":5553,"date":"2026-08-30T08:52:28","date_gmt":"2026-08-30T08:52:28","guid":{"rendered":"https:\/\/www.creatingsmarthome.com\/?p=5553"},"modified":"2026-08-30T08:52:30","modified_gmt":"2026-08-30T08:52:30","slug":"home-assistant-how-to-track-low-batteries-with-auto-entities-battery-notes","status":"publish","type":"post","link":"https:\/\/www.creatingsmarthome.com\/index.php\/2026\/08\/30\/home-assistant-how-to-track-low-batteries-with-auto-entities-battery-notes\/","title":{"rendered":"Home Assistant: How to Track Low Batteries (With Auto-Entities & Battery Notes)"},"content":{"rendered":"\n

I think everyone has bumped into this at some point \u2014 an automation stops working, or a sensor’s data hasn’t updated in days, and the reason turns out to be a dead battery\u2026 again. I finally got tired of chasing down dead batteries one device at a time and decided to do something about it properly.<\/p>\n\n\n\n

I have 51 battery-powered devices scattered around my house that I need to keep track of \u2014 door sensors, motion sensors, dimmer switches, leak detectors, smoke detectors, plant sensors, you name it. In this article I’ll walk through the setup I built to catch low batteries before<\/em> they die on me, instead of finding out the hard way when something stops reporting.<\/p>\n\n\n\n

I’m using a couple of Home Assistant custom components to pull this off: the\u00a0auto-entities<\/a><\/strong>\u00a0card and the\u00a0Battery Notes<\/a><\/strong> integration. Here’s how they fit together.<\/p>\n\n\n\n

Battery Notes integration<\/h2>\n\n\n\n

This is a brilliant integration. Battery notes integration<\/a> scans your battery-powered devices and “extends” them with extra data \u2014 most importantly, the battery\u00a0type<\/em>\u00a0\u2014 which turns out to be essential once you get to the end result (more on that later).<\/p>\n\n\n\n

Battery Notes tries to automatically figure out the battery type from a community-maintained device library, and to its credit, it got quite a few of mine right without any input from me. But it couldn’t identify everything \u2014 in my case, I had to manually add 31 of my devices to the integration myself after the initial autodiscovery pass.<\/p>\n\n\n\n

Each device you add gets a companion _plus<\/code> sensor entity \u2014 mine look like sensor.multi_sensor_utility_room_battery_plus<\/code>, for example. This entity mirrors the original battery percentage, but carries extra attributes alongside it, like battery_type<\/code> and battery_type_and_quantity<\/code>. That second one is the attribute that ends up doing the heavy lifting later in this article \u2014 it’s the difference between a dashboard that tells you “27%” and one that tells you “27% \u2014 go grab a CR2032.”<\/p>\n\n\n\n

\"\"
Discovered and\/or manually added devices on battery notes integration<\/figcaption><\/figure>\n\n\n\n

Auto-entities card<\/h2>\n\n\n\n

Auto-entities<\/a> is a card that dynamically builds a list of entities based on a filter, instead of you hand-typing every entity_id into your dashboard config. Rather than maintaining a fixed list of 50-odd sensors and manually appending every new device I buy, I let the card do the filtering for me at render time.<\/p>\n\n\n\n

The filter isn’t limited to matching entity_ids or domains \u2014 it can match on state, on attributes, and (crucially for this setup) on labels<\/strong>. You can also sort the resulting list by state, which means I can have my “worst battery first” ordering fall out for free, rather than me manually re-sorting a list every time a battery drains further.<\/p>\n\n\n\n

The other piece that makes this work well is that auto-entities lets you override how each matched entity renders, via an options<\/code> block. That’s what lets me point the filtered results at a specific custom row type (more on this in the “Needs attention” section below) instead of settling for the plain default row.<\/p>\n\n\n\n

The labelling approach<\/h2>\n\n\n\n

Here’s the part I think matters most: I’m not filtering by entity type or device_class<\/code>. I’m filtering by label<\/strong>.<\/p>\n\n\n\n

My first instinct was to just match on device_class: battery<\/code>, since every battery-percentage sensor in Home Assistant carries that class. But that net catches everything<\/em> with a battery \u2014 my phone, my smartwatch, my electric toothbrush, the Tesla, the Peugeot, even the robot mower. None of those are things I want cluttering up a “go buy a battery” list. A dead phone battery is my problem to charge, not a CR2032 I need to add to a shopping list.<\/p>\n\n\n\n

So instead, I created a label called house_battery<\/code> and applied it only to the actual battery-powered devices<\/em> around the house \u2014 the sensors, switches, and detectors that would otherwise silently stop working. Anything I don’t want tracked (vehicles, personal electronics, anything with its own charging routine) simply never gets the label.<\/p>\n\n\n\n

The nice side effect: adding a new battery device to the setup is now a two-second job. I don’t touch any dashboard YAML at all \u2014 I just find the entity in Settings \u2192 Devices & Services \u2192 Entities<\/strong>, add the house_battery<\/code> label, and it’s automatically picked up everywhere that filters on that label. No more remembering to update three different dashboard cards every time I add a sensor.<\/p>\n\n\n\n

\"\"
Setting the label on battery+ entity<\/figcaption><\/figure>\n\n\n\n

‘Needs attention’ section<\/h2>\n\n\n\n

This is the beef of the whole setup. The “Needs Attention” section is a card that lists every house_battery<\/code>-labelled device currently sitting below 25%, sorted so the most urgent one is always at the top. When nothing is low, the card simply doesn’t render any rows at all \u2014 no empty “0 results” clutter.<\/p>\n\n\n\n

yaml<\/p>\n\n\n\n

type: custom:auto-entities\ncard:\n  type: entities\n  title: Needs Attention\n  icon: mdi:battery-alert-variant-outline\n  state_color: true\n  show_header_toggle: false\nshow_empty: false\nfilter:\n  include:\n    - label: house_battery\n      state: \"< 25\"\n      options:\n        type: custom:multiple-entity-row\n        secondary_info:\n          attribute: battery_type_and_quantity\nsort:\n  method: state\n  numeric: true\n  reverse: false<\/code><\/pre>\n\n\n\n
A couple of things worth calling out here:<\/p>\n\n\n\n