Records and ownership from day one
Monitoring a handful of beacons is straightforward: walk past them with a scanning app and note the readings. Monitoring hundreds or thousands of beacons across multiple sites demands a different approach entirely. The challenge is not simply knowing a battery is low, but knowing it before the beacon stops advertising reliably, and doing so without manual checks becoming a full-time job.
Battery level data does not appear by magic. A beacon must include that information in its broadcast packet, something must receive that packet, and a system must aggregate, store and present the data. Most modern beacons support battery reporting through Eddystone Telemetry (TLM) frames or manufacturer-specific data fields within iBeacon packets. However, not all deployments use protocols that carry telemetry, and not all receiver setups are configured to capture and forward it.
The reporting chain typically runs: beacon broadcasts a packet containing a voltage or percentage reading; a receiver—either a dedicated gateway or a visitor’s smartphone with your app installed—picks up the broadcast; the receiver forwards the data to a backend platform; and that platform updates a dashboard or triggers an alert. A break at any point in that chain means a beacon can go flat without anyone noticing until a zone stops working.
At scale, two problems emerge quickly. First, coverage gaps: if beacons in low-traffic areas are only detected by visitors’ phones, and few visitors pass through, battery readings for those units may be days or weeks out of date. Second, data consistency: different beacon models report battery levels in different ways—some as a percentage, some as a voltage in millivolts, some with coarse granularity that jumps from 80% to 20% in a single reading. A monitoring system that does not account for these differences will produce misleading dashboards.
Routine work, records and exceptions
Gateway-based versus app-based collection
Dedicated gateways placed at fixed positions scan continuously and report beacon data at regular intervals regardless of visitor traffic. This gives near-real-time visibility and is well suited to retail floors, warehouses and venues where consistent monitoring matters. App-based collection depends on visitors walking past beacons with Bluetooth enabled and your app installed. It costs nothing in extra hardware but introduces unpredictable latency and blind spots in quiet zones.
Many large deployments use a combination: gateways cover critical or low-traffic areas, while app-based collection supplements coverage in busy zones. The monitoring platform needs to handle both data sources and flag beacons that have not been heard from within a defined window, rather than relying solely on the last reported battery figure.
Setting useful thresholds
A single "low battery" alert is rarely sufficient at scale. Operational teams benefit from tiered thresholds: a warning level that prompts scheduling a replacement during the next routine visit, and a critical level that triggers an urgent swap. The values depend on the beacon model, battery chemistry and operating conditions, so they should be set after reviewing actual discharge curves from your pilot rather than using default values from the platform.
It is also worth monitoring the rate of change. A beacon dropping from 70% to 40% in a week when its neighbours have barely changed may indicate a hardware fault, a firmware issue or an environmental problem such as extreme cold, rather than normal discharge.
Multi-site visibility
For organisations managing beacons across several locations—retail chains, museum networks, event companies working multiple venues—a central view is essential. This means the monitoring platform must support site-level grouping, role-based access so local staff see only their own estate, and a consolidated view for central operations. Without this, battery management devolves into spreadsheets emailed between sites, which quickly becomes unreliable.
Handling silent failures
Not every beacon reports low battery before it stops transmitting. Some models simply cease advertising when voltage drops below a threshold, with no intermediate warning. Others continue broadcasting but at a reduced transmit power, which effectively shrinks their detection range without triggering a battery alert. A robust monitoring approach tracks both the reported battery level and the time since a beacon was last detected. A beacon that has not been seen for an unusually long period, regardless of its last reported battery state, should generate an alert.
What changes trigger intervention
Trusting reported percentages without verification
Battery percentage reported by a beacon is an estimate calculated by the beacon’s firmware, not a direct measurement. Some models round aggressively or update the value only when it crosses a threshold. A reading of "100%" does not guarantee a fresh cell, and a reading of "50%" on one model may correspond to a different remaining capacity than "50%" on another. During your pilot, compare reported values against actual voltage measurements taken with a multimeter for a sample of units, and document any consistent offsets for each model in your asset register.
Ignoring temperature effects
Battery chemistry, particularly for coin cells commonly used in beacons, is sensitive to temperature. A beacon in a refrigerated retail display or a cold storage area will discharge faster than the same model at room temperature, and the firmware’s voltage-to-percentage calculation may become inaccurate at low temperatures. If your deployment includes environments outside normal office conditions, factor this into your threshold settings and expect to replace cells more frequently in those zones.
Setting thresholds too late
If your critical alert fires at 10% and the beacon typically takes two weeks to go from 10% to zero, but your replacement cycle operates on a monthly schedule, you will routinely have dead beacons between scheduled visits. Work backwards from your practical replacement cadence to set thresholds that give enough lead time. This is distinct from planning the replacement cycle itself—the question here is purely about when the monitoring system should notify you.
Not correlating battery data with detection performance
Battery level is one indicator; actual performance is another. A beacon reporting 60% battery but showing a sudden drop in detection rate or range may have an antenna issue, interference problem or firmware fault. Monitoring systems that overlay battery data with detection metrics—how often the beacon is seen, by how many receivers, and at what signal strength—give a far more useful picture than battery percentage alone.
Key questions for a monitoring platform or provider
- Which beacon protocols and manufacturer data formats does the platform parse for battery data?
- Can it handle mixed beacon models with different reporting methods in a single dashboard?
- Does it support both gateway and app-based data sources?
- Can you set per-model, per-site and per-zone alert thresholds?
- Does it alert on "last seen" timeout as well as reported battery level?
- Is there an API or export function so you can integrate battery data into your existing asset management system?
- How does the platform handle beacons that report voltage but not percentage, or vice versa?
Monitoring battery levels at scale is fundamentally a data-quality problem. The value of the system depends less on the dashboard design and more on the reliability of the reporting chain, the granularity of the incoming data, and the rigour with which you set thresholds against your actual operating conditions. Start with a clear picture of what "at scale" means in your estate, then ensure every link in the chain—from broadcast format to alert action—is documented and tested before rollout.
