Battery drain detection: find failing Zigbee devices before they go silent

Most people discover a Zigbee battery problem when the device has already stopped doing its job. A door sensor no longer triggers an automation, a temperature reading becomes stale, or a leak sensor fails to report when it matters.

A low-battery alert can help, but it is not always early enough. Battery percentage may be reported infrequently, in broad steps, or only after the device wakes up. A current value of 62% says little by itself. The useful question is how that value compares with the device’s recent history and normal reporting behaviour.

Battery telemetry history lets you look for that pattern. It does not predict failure with certainty, and it cannot correct an inaccurate battery estimate. It can, however, give you evidence that a device is declining faster than expected and deserves attention before it becomes silent.

Battery percentage is a signal, not a fuel gauge

Zigbee2MQTT exposes battery-related values when a device supports them. A typical device may publish a battery value as a percentage, while some devices also expose voltage or a low-battery state. The exact fields and reporting behaviour depend on the device definition and firmware.

That percentage should be treated as an estimate. Two devices showing 70% do not necessarily have the same remaining runtime. Battery chemistry, temperature, load, radio conditions, reporting frequency, and the device’s voltage-to-percentage mapping can all affect the result.

Some battery devices also report only when a value changes or when they periodically check in. Zigbee2MQTT describes attribute reporting in terms of minimum and maximum reporting intervals: a device can wait for a change, but it may also be configured to report after a maximum interval when supported.

This has two practical consequences:

• A flat line does not always mean the battery level is unchanged. It may mean the device has not sent a new battery value.
• A sudden step does not automatically mean the battery lost that amount of capacity at that moment. It may be the first updated estimate after a period without reporting.

History is therefore most useful when combined with timestamps, repeated observations, and the device’s known behaviour.

The pattern matters more than the threshold

A conventional alert such as “battery below 20%” is easy to understand. It is also a late warning for some devices. If a sensor falls from 85% to 35% over a short period, waiting until it reaches 20% may leave little margin for a replacement, especially for a device that is hard to access.

A trend-based review looks at the rate and consistency of change. For example:

• A sensor moves from 92% to 88% over several months.
• The same sensor then drops to 74% in two weeks.
• It reaches 61% after another week and begins missing expected reports.

That pattern deserves investigation even though the current value is not yet critically low.

Avoid presenting fixed rates as universal definitions of a healthy or failing battery. The following are illustrative patterns, not diagnostic thresholds:

Observed pattern	Possible interpretation	Sensible next step
Small changes over a long period	Normal use or coarse reporting	Continue observing
One isolated large step	Delayed report, temperature effect, or estimate change	Check later readings and voltage if available
Repeated decline over a short period	Battery, device, or reporting problem	Inspect the device and plan a replacement
Battery decline combined with missing messages	Possible low battery or broader device/network issue	Check last-seen history, physical placement, and battery

The strongest warning is not a particular percentage. It is a sustained change combined with symptoms such as missed reports, reduced responsiveness, or an unexpected last-seen gap.

Compare devices with similar roles

A single battery graph can be difficult to interpret. Comparisons make it more useful.

Suppose four identical contact sensors were installed on the same day with the same battery type. Three remain between 78% and 84% after several months, while one has fallen to 49%. The outlier deserves attention, but it is not automatically defective. It may be exposed to colder temperatures, have a weaker radio path, use a different battery, or report its estimate differently.

A comparison should therefore generate a troubleshooting path rather than a conclusion:

1. Check whether the devices use the same battery type and firmware generation.
2. Compare their installation environments, especially temperature and accessibility.
3. Review message timestamps and last-seen information.
4. Check whether the outlier has repeated communication failures or unusual event frequency.
5. Replace the battery and observe whether the trend returns to normal.

This is where history is more useful than a list of current values. It helps you identify outliers and gives you a time window for comparing a change with a battery replacement, bridge restart, relocation, or seasonal temperature shift.

Do not confuse quiet with offline

Battery-powered Zigbee devices are often designed to sleep to conserve energy. A contact sensor that has not changed state may legitimately produce fewer messages than a mains-powered router or smart plug.

Zigbee2MQTT’s availability feature reflects this difference. Its documented defaults expect active, non-battery-powered devices to check in more frequently, while passive battery-powered devices are given a longer check-in period; the exact timeout can be configured and should match the installation.

That means a missing battery update is not automatically evidence of a dead battery. Look at several signals together:

• The time since the last message.
• The device’s expected reporting interval.
• Whether normal state changes are still being delivered.
• The recent battery trend.
• Whether the device is exposed to unusual cold or heat.
• Whether nearby devices or the Zigbee bridge show related problems.

The same principle applies to a battery percentage that remains unchanged for weeks. If the device continues to report door events normally, the battery field may simply be updated less often than the event field.

Use battery history to support an investigation, not to replace device-specific expectations.

Building this yourself

A DIY implementation is entirely reasonable if you already operate an MQTT and time-series stack. A typical pipeline would:

1. Subscribe to the relevant Zigbee2MQTT topics.
2. Extract the battery value and timestamp from each message.
3. Store the observations in a time-series database.
4. Build a dashboard showing battery history and last-seen time.
5. Add queries for percentage change over a chosen period.
6. Configure retention and backups so the monitoring system remains useful.

You may also want to store voltage, availability events, device identifiers, and the original message time. That provides better evidence when a battery percentage looks suspicious, but it increases the number of fields and operational decisions.

The initial implementation may be a small project. The long-term responsibility includes maintaining the MQTT consumer, handling renamed devices, preserving timestamps correctly, updating dashboards, monitoring storage, and deciding what happens when the bridge or database is unavailable.

For an enthusiast who wants complete control, that trade-off can be worthwhile. A self-hosted stack also makes sense when battery monitoring is part of a broader observability system that already covers energy, network devices, servers, and applications.

How a managed history service fits

ZigStream is intended for the narrower problem of collecting and inspecting Zigbee2MQTT telemetry without requiring you to build a separate history pipeline. Zigbee2MQTT remains responsible for communicating with your local Zigbee network and publishing device data. Your local automations and device configuration remain under your control.

That makes a managed history workflow useful for reviewing questions such as:

• Has this sensor’s battery estimate declined faster than its peers?
• Did the battery change before the device began missing messages?
• What was the device’s battery trend over the last week or month?
• Which device should be checked during the next maintenance round?

The exact usefulness depends on the fields your device publishes and the history available for your account.

Make battery checks part of maintenance

Battery history is most valuable when it leads to a small, repeatable maintenance process. Once a month, review devices with a recent downward trend, compare outliers with similar sensors, and check whether a missing report is consistent with the device’s expected sleep behaviour.

For important sensors, keep a replacement battery nearby and record the replacement date. After changing it, confirm that the device reports normally and that its historical trend reflects the intervention. If the new battery also declines quickly, investigate temperature, device configuration, physical damage, and Zigbee communication rather than repeatedly replacing batteries.

A practical alerting policy can combine several conditions:

• Notify when the battery remains below a device-appropriate threshold.
• Review when the percentage falls unusually quickly over a defined window.
• Escalate when battery decline coincides with missed expected messages.
• Treat a device as stale only after applying a timeout appropriate to its power source and reporting pattern.

These rules are more reliable than treating every percentage change as a failure.

The bottom line

A current battery percentage is useful for a quick check, but it is weak evidence on its own. The combination of trend, timestamps, similar devices, and last-seen behaviour gives you a much better basis for deciding whether a sensor needs a new battery or a deeper investigation.

If you already operate Grafana and a time-series database, adding battery history may fit naturally into that system. If you want device-history queries without maintaining another telemetry pipeline, ZigStream provides a focused way to inspect the data published by Zigbee2MQTT.

Start with the sensors that matter most—entry points, leak detectors, heating controls, and other devices whose silence would be costly. Review their history before the next low-battery alert becomes a missed event.