Device Low Battery Alarm

Who it’s for

Fleet and asset managers, facility teams, and anyone running battery-powered sensors, GPS trackers, or metering endpoints. Use it when each device’s own battery should raise its own alarm before it goes dark: “which sensors are about to die and need a battery swap?”, “did this tracker just drop to a critical charge?”, “is a LoRaWAN endpoint running low weeks before its route visit?”

What it does

Watches a single device’s batteryLevel telemetry and raises a Major alarm when the charge falls to or below the low threshold, escalating to Critical when it drops to or below the critical threshold. The alarm clears once the battery is back above the safe threshold, which happens after a replacement or a charge. It waits for the battery to read low across a few readings in a row before firing, so a single stray value does not raise a false alarm. This is a per-device alarm, so each endpoint reports and clears on its own, independent of any site-wide rollup.

The debounce counts readings, not minutes: a sensor that reports once every few hours never satisfies a time-window “stayed low for N minutes” condition in any useful way, so this rule waits for N consecutive low readings instead.

An optional early-warning tier raises a Warning when a device’s projected days-to-empty (from a days-to-empty calculated field) falls to or below a threshold, so a battery can be scheduled for replacement weeks before it reaches the low level. It stays dormant unless that projection key is present, so it costs nothing if you do not use it.

How to set up

The rule has default values for every threshold, so it works as soon as it is installed. Install on a device or asset profile so the alarm covers every battery-powered device of that type at once and automatically picks up any new device added later. Single-device installs are also supported.

How to customize

• To monitor a different battery key - change the Time series key on the metric argument to match your vendor’s key (e.g. batteryLevel → battery, or vbat for devices that report a voltage instead of a percentage). If you switch to voltage, set the thresholds to the cell’s range, for example a 3.6 V lithium cell with the low, critical, and clear levels around 3.4, 3.2, and 3.5 volts.
• To use different threshold attribute names - change the Attribute key on the threshold arguments to match what your devices already use (e.g. batteryWarningThreshold → battLow).
• To change the low, critical, and clear levels used when no per-entity attribute is set - change the Default value on the warningThreshold, criticalThreshold, and clearThreshold arguments. Keep the clear level a few points above the low level so a battery hovering near the edge does not flap.
• To tune thresholds at runtime without editing the rule - set the value on the entity as a regular server-side attribute. It can be edited directly from a dashboard using the Update Multiple Attributes input widget:
  • Per device - set the attribute (e.g. batteryWarningThreshold) on the device itself. The per-entity value overrides the Default value.
  • Per customer (in deployments that use customers) - change Entity type on the relevant argument to Current owner, then set the attribute on the customer. Every device that customer owns picks up that value.
  • Tenant-wide - change Entity type to Current tenant, then set the attribute on the tenant. The value applies across every device.
• To alarm on a single level only - remove the Critical create rule to keep just the low warning, or remove the Major create rule to alert only at critical.
• To debounce a glitchy reading - change the Default value on the repeatCount argument. The battery has to read low for that many readings in a row before the alarm fires, so one stray value is ignored. This counts readings rather than minutes, so it does not delay the alarm on devices that report only every hour or so.
• To enable the early-warning tier - have the device report a batteryDaysRemaining key - a days-to-empty calculated field produces one, and so does any source of your own that writes it - and set batteryDaysWarningThreshold (default 14 days). The Warning fires when the projection drops to or below it, and the alarm does not clear until the level recovers and the projection is healthy again. Without the projection key the tier stays dormant.
• To make the alarm manual-clear-only - remove the Clear condition. The alarm then stays active until an operator clears it.
• To control where the alarm shows up - toggle the propagation flags under Advanced settings.

See also

Fires before a device goes dark. This rule tells you which battery is about to cause that, weeks earlier. The rule that tells you a device has already stopped reporting is here:

IoT Device Offline Alarm verified Dmytro Shvaika

This rule is per-device. For the site-wide question - how much of a site’s fleet is running low at once - install the roll-up instead, and run both if you need the device and the site view:

battery_alert Too many devices with low battery level per site verified Mykhailo Kornieiev

To read battery and signal together on a dashboard rather than as an alarm:

Device health card verified Andrii Zaiko