Plan the battery round before a sensor goes quiet

Why battery devices need a schedule, not a reaction

Most faults announce themselves. An integration that loses its connection turns entities unavailable, an automation with a bad entity ID throws an error, a failing disk fills the log. A battery running out does none of that. The device reports for the last time and then stops, and every automation that depends on it starts silently taking the branch for “no motion” or “door closed”.

Zigbee and Z-Wave battery devices are especially prone to going unnoticed because they are designed to be quiet. The ZHA documentation describes them as hardware that is typically battery-powered, such as remotes or motion sensors, and notes that some sleepy sensors, such as door or temperature sensors, only report when triggered. A device that is supposed to be silent for days is not distinguishable from a dead one by silence alone.

Hence the schedule. If you know roughly how long a cell lasts in your house, you can replace them before they run out, in planned rounds, with the batteries already in a drawer. That is a fundamentally different operation from discovering at eleven at night that the only motion sensor on the stairs has been dead for a fortnight.

Measure service life; do not inherit it

Service life is the only input to the planner that cannot be looked up honestly. The figure on the packaging was measured under conditions that are not your hallway. Reporting interval, how often the device is actually triggered, radio retries when the mesh is weak, temperature, and the quality of the cells all move it, sometimes by a factor of two.

So measure. Write down the date every time you replace a battery, in whatever place you will actually look again: a note on the device, a helper in Home Assistant, a line in a maintenance file. After one cycle you have a real number for your house, and that number is worth more than any specification.

Until you have it, use a deliberately conservative estimate and treat the first cycle as the measurement. Being early on a battery round costs a few cells. Being late costs an automation that was quietly wrong for a fortnight and a household that no longer believes the system.

Build the yearly plan

Run the planner once per battery type you stock. Mixing coin cells and AAs into one calculation produces a stock figure that is right in aggregate and wrong in the drawer.

The service-round interval is the number that turns this into an actual routine. Rather than replacing devices one at a time as they fail, the plan tells you how often to do a batch, so battery maintenance becomes a recurring calendar entry with a known duration instead of an interruption.

Back the schedule with an alert that fails safe

The schedule is the plan and the alert is the safety net. Home Assistant defines the semantics precisely: for a binary sensor with the battery device class, on means low and off means normal. Devices that report a percentage instead expose a numeric sensor, and a numeric-state threshold works there.

The failure mode to design against is an alert that goes quiet for the wrong reason. If a device has already gone flat, its entity may be unavailable or unknown rather than reporting a low battery, and a naive numeric threshold treats a missing value as “not below the limit”, which is to say, as fine. Test for the uncertain states explicitly.

alias: "Battery attention — low or silent"
triggers:
  - trigger: state
    entity_id: binary_sensor.hall_motion_battery
    to: "on"
    id: low
  - trigger: state
    entity_id: binary_sensor.hall_motion_battery
    to:
      - "unknown"
      - "unavailable"
    for: "06:00:00"
    id: silent
actions:
  - action: notify.send_message
    target:
      entity_id: notify.household_admin
    data:
      message: >-
        {{ 'Hall motion battery is low.' if trigger.id == 'low'
           else 'Hall motion has not reported for six hours.' }}
mode: single

The six-hour delay on the silent branch matters. Devices go briefly unavailable during a Home Assistant restart, an integration reload or a radio hiccup, and an alert that fires on every one of those becomes noise that gets muted, which is worse than having no alert at all. Choose a duration comfortably longer than your longest normal gap.

The same template patterns that guard any sensor apply here. Home Assistant's templating documentation covers checking whether a state has a real value before comparing it, which is the difference between an alert that catches a dead device and one that reports it as healthy.

Stock, spares and the batch you actually do

The spare percentage in the planner is not padding for its own sake. It covers early failures, the device you forgot to count, the cell that was already half flat in the packet, and the one you drop behind the radiator. Twenty-five per cent is a reasonable starting point for a small fleet, and the right figure is whatever stops you making an unplanned trip.

Batch size is a genuine trade-off rather than an optimisation. Small rounds mean visiting the loft four times a year; large rounds mean replacing cells that had months left in them. Somewhere in between is a round you will actually do, and a round you actually do beats an optimal round you skip.

Buy cells from somewhere with turnover and check the date on the packet. Coin cells in particular sit on shelves, and a cell that has already spent two years in a warehouse does not owe you the service life your plan assumes. Keep them in one labelled place, because a battery round that starts with a search does not stay a habit.

One thing not to economise on: devices whose failure is consequential. Whatever the plan says, a sensor that a safety-adjacent routine depends on deserves replacing early and checking after. Software schedules do not replace purpose-built alarms, and no automation on this site is a certified safety system.

Make the round routine

Put the interval the planner produced into whatever calendar the household actually reads, with the battery type and the device list attached. Do the round, write down the date, and update the service-life figure once you have a full cycle of evidence. The plan gets more accurate every time you run it, which is the entire point of measuring rather than guessing.

Review the fleet count whenever you add devices, and re-run the planner rather than assuming the stock level still holds. Ten new contact sensors is not a rounding error on an annual cell budget.