A single Beacon is easy to forget about once it is stuck to a wall. The problem starts at scale: a warehouse with 500 beacons, a hospital with 2000, a campus with 8000. When one dies you do not notice until a location goes dark. This article covers how to keep a Beacon fleet observable — telemetry, battery alerts, online/offline state, and pushing config to thousands of units without touching them.
What a Beacon should report
Every managed Beacon should emit a small health heartbeat alongside its advertising, either over a connection or through a gateway that listens and forwards:
- Battery voltage / percentage: the single best early-warning signal.
- Last RSSI and a reference Tx power: detects a failing radio or moved unit.
- Uptime and reset cause: a beacon that resets hourly has a power or firmware fault.
- Firmware version: so you know what is in the field.
- Packet/adv counters: a frozen counter means the stack hung.
Keep the heartbeat small — a few bytes every few hours is enough; you are watching trends, not streaming.
Battery alert thresholds
A Beacon on a CR2477 at 1 s interval starts around 3.0 V and the voltage falls slowly, then cliffs near 2.4 V. Set two thresholds:
| Level | Voltage | Action |
|---|---|---|
| Healthy | > 2.7 V | no action |
| Warning | 2.5-2.7 V | schedule replacement within 60 days |
| Critical | < 2.5 V | replace now, flag location |
Do not wait for 2.0 V — by then the beacon may already be dropping packets intermittently and giving wrong positions.
Online / offline detection
The fleet dashboard’s core job is knowing who is alive. A Beacon that a gateway has not heard from in N advertising intervals is “stale”; one not seen for M minutes is “offline”. Typical values: stale after 3 missed intervals (~3-15 s), offline after 10-30 min. Gate the alert on offline, not stale, to avoid false alarms from a momentary gateway gap.
Bulk configuration push
When you change the advertising interval or major/minor IDs across a Beacon fleet, you do not visit each one. Two patterns work:
- Gateway relay: the gateway receives a config blob over MQTT/HTTP and forwards it to nearby beacons over connection or broadcast command (see the downlink article). One command reaches hundreds.
- Scheduled self-fetch: each beacon wakes, connects, and pulls its config from a server on a staggered schedule, avoiding a thundering herd.
Authenticate every command — an unsigned config push is an attacker’s dream.
Remote reconfiguration lifecycle
A disciplined Beacon rollout treats config as versioned state:
1. Author config v2 in the console (interval, tx power, payload).
2. Canary: push to 1% of the fleet, watch for resets or offline spikes.
3. Roll out to the rest on a staggered schedule.
4. Keep v1 for instant rollback if metrics degrade.
This is the same progressive-delivery discipline used for cloud software, applied to dumb little radios.
Security of telemetry
Health data is still data. A Beacon reporting battery and location is a fine side channel for an attacker mapping your floor plan. Send telemetry over an encrypted, authenticated channel, and sign config so a rogue gateway cannot impersonate the fleet owner.
Building the dashboard
The dashboard needs only four views: a map of online/offline, a battery histogram, a firmware-version breakdown, and a recent-alerts feed. Most of the value is in the battery histogram — it tells you next month’s replacement workload today.
A well-instrumented Beacon fleet turns “something is wrong somewhere” into “unit 4821 in aisle 7 drops below 2.5 V next Tuesday” — that is the difference between a maintenance team and a fire drill.