Ein einzelner Beacon ist leicht vergessen, sobald er an der Wand klebt. Das Problem beginnt bei Skala: ein Lager mit 500 Beacons, ein Krankenhaus mit 2000, ein Campus mit 8000. Wenn einer stirbt, merkt man es nicht, bis eine Zone dunkel wird. Dieser Artikel behandelt, wie man eine Beacon-Flotte beobachtbar hält: Telemetrie, Batterie-Alarme, Online/Offline-Zustand und Config an Tausende Einheiten zu pushen, ohne sie anzufassen.
Was ein Beacon melden soll
Jeder verwaltete Beacon sollte einen kleinen Health-Heartbeat neben seinem Advertising senden, über Verbindung oder via Gateway, das mithört und weiterleitet:
- Batteriespannung / Prozent: das beste Frühwarnsignal.
- Letztes RSSI und Referenz-Tx-Power: erkennt defekte Radio oder verschobene Einheit.
- Uptime und Reset-Ursache: ein Beacon, das stündlich resettet, hat Strom- oder Firmware-Fehler.
- Firmware-Version: um zu wissen, was im Feld ist.
- Paket/Adv-Zähler: ein eingefrorener Zähler bedeutet hängenden Stack.
Halten Sie den Heartbeat klein: ein paar Byte alle paar Stunden reichen; man beobachtet Trends, streamt nicht.
Batterie-Alarmschwellen
Ein Beacon mit CR2477 bei 1-s-Intervall startet bei ~3.0 V und fällt langsam, dann Klippe nahe 2.4 V. Setzen Sie zwei Schwellen:
| Stufe | Spannung | Aktion |
|---|---|---|
| Gesund | > 2.7 V | keine |
| Warnung | 2.5-2.7 V | Tausch in 60 Tagen |
| Kritisch | < 2.5 V | sofort tauschen, Ort markieren |
Warten Sie nicht auf 2.0 V: dann wirft der Beacon schon intermittierend Pakete weg und liefert falsche Positionen.
Online / Offline-Erkennung
Die Kernaufgabe des Dashboards ist zu wissen, wer lebt. Ein Beacon, den ein Gateway in N Intervallen nicht hörte, ist „stale“; einer, der M Minuten nicht gesehen wurde, ist „offline“. Typisch: stale nach 3 verpassten Intervallen (~3-15 s), offline nach 10-30 min. Gaten Sie den Alarm auf offline, nicht stale, um False Positives durch eine momentane Gateway-Lücke zu vermeiden.
Bulk-Config-Push
Wenn Sie das Intervall oder Major/Minor über die Beacon-Flotte ändern, besuchen Sie nicht jede. Zwei Muster funktionieren:
- Gateway-Relay: das Gateway holt ein Config-Blob per MQTT/HTTP und leitet es an nahe Beacons per Verbindung oder Broadcast-Befehl weiter (siehe Downlink-Artikel). Ein Befehl erreicht Hunderte.
- Geplantes Self-Fetch: jeder Beacon wacht auf, verbindet und zieht Config vom Server in gestaffeltem Plan, um eine Stampede zu meiden.
Authentisieren Sie jeden Befehl: ein Push ohne Signatur ist der Traum eines Angreifers.
Lifecycle der Remote-Reconfig
Ein disziplinierter Beacon-Rollout behandelt Config als versionierten Zustand:
1. Config v2 in der Konsole authorn (Intervall, Tx-Power, Payload).
2. Canary: auf 1% der Flotte pushen, Resets oder Offline-Spikes beobachten.
3. Auf den Rest in gestaffeltem Plan ausrollen.
4. v1 für sofortigen Rollback behalten, falls Metriken fallen.
Das ist dieselbe Progressive-Delivery-Disziplin wie in Cloud-Software, auf kleine Radios angewandt.
Sicherheit der Telemetrie
Health-Daten sind Daten. Ein Beacon, der Batterie und Ort meldet, ist ein feines Side Channel für einen Angreifer, der Ihren Grundriss mappt. Senden Sie Telemetrie über verschlüsselten, authentisierten Kanal und signieren Sie Config, damit ein rogue Gateway den Flottenbesitzer nicht imitiert.
Dashboard bauen
Das Dashboard braucht nur vier Views: Karte Online/Offline, Batterie-Histogramm, Firmware-Versions-Breakdown und Recent-Alerts-Feed. Der meiste Wert steckt im Batterie-Histogramm: es sagt heute die Tauschlast des nächsten Monats.
Eine gut instrumentierte Beacon-Flotte verwandelt „irgendwo stimmt was nicht“ in „Einheit 4821 in Gang 7 fällt nächsten Dienstag unter 2.5 V“: das ist der Unterschied zwischen Wartungsteam und Brandbekämpfung.