Ein einzelnes Bluetooth Beacon zu verwalten ist trivial. 500 ueber 30 Filialen zu verwalten ist Engineering. Jedes Beacon laeuft auf einer Knopfzelle, hat keine Netzwerkschnittstelle und kann die meiste Zeit nur in eine Richtung kommunizieren. Wenn ein Beacon stirbt, verstummt oder frequenzmaessig abdriftet, merkt es niemand, bis eine kundenorientierte Funktion ausfaellt. Dieser Artikel behandelt das praktische Engineering des Beacon-Fleet-Managements: wie man Geraete ohne Rueckkanal remote konfiguriert, wie man Firmware-Updates an 500 Geraete pusht, ohne sie zu bricken, wie man die Batterielebensdauer allein aus Scan-Daten ueberwacht und wie man die Telemetrie-Pipeline aufbaut, die alles verbindet.
1. Das Fleet-Management-Problem
Eine Beacon-Flotte unterscheidet sich grundlegend von einer WiFi- oder Cellular-Geraeteflotte. Die wesentliche Einschraenkung: Beacons sind standardmaessig nur Senden. Sie senden Advertising-Pakete aus und gehen wieder in den Schlaf. Es gibt keine TCP-Verbindung, keinen MQTT-Broker, keinen Heartbeat. Die einzige Moeglichkeit zu wissen, dass ein Beacon lebt, ist, danach zu scannen.
1.1 Was im Massstab Schiefgehen Kann
| Fehlermodus | Erkennungszeit (Ohne Monitoring) | Zeit (Mit Monitoring) | Auswirkung |
|---|---|---|---|
| Batterieerschöpfung | Tage bis Wochen | < 1 Stunde | Beacon verstummt, Funktion bricht |
| Firmware-Hang | Nie (bis Batterie tot) | < 15 Min | Stiller Ausfall, kein Advertising |
| Frequenzdrift | Nie | Stunden (via RSSI/Scan-Analyse) | Verpasste Verbindungen, Reichweitenverlust |
| Physische Verschiebung | Tage | < 30 Min | Falsche Standortdaten, Sicherheitsrisiko |
| Konfigurationskorruption | Nie | < 1 Stunde | Falsches Advertising-Payload |
| RF-Stoerung | Tage | < 15 Min | Reduzierte Reichweite, verpasste Pakete |
Bei 500 Beacons mit 2 Jahren Batterielebensdauer verlieren Sie ca. 0,27 Beacons pro Tag allein durch Batterieerschöpfung. Ohne Monitoring haeufen sich stille Ausfaelle an, bis eine kritische Masse toter Beacons die Kundenerfahrung bricht.
1.2 Der Drei-Schichten-Monitoring-Stack
Schicht 3: Cloud-Dashboard (Flottenstatus, Alerts, Analytik)
|
Schicht 2: Gateway/Scanner-Netzwerk (BLE-Scan, Datenweiterleitung)
|
Schicht 1: Beacon-Flotte (Advertising, Telemetrie im Payload)
Schicht 1 sind die Beacons selbst. Schicht 2 ist ein Netzwerk von BLE-Scannern (typischerweise Raspberry Pi oder dedizierte Gateway-Hardware), die ueber den Bereitstellungsort verteilt sind. Schicht 3 ist die Cloud-Plattform, die Scan-Daten aggregiert, Analytik ausfuehrt und Alerts ausgeloest.
2. Remote-Konfigurationsarchitektur
2.1 Das Rueckkanal-Problem
Beacons koennen keine Befehle empfangen, waehrend sie im Advertising-Only-Modus sind. Um Konfigurationsaenderungen zu pushen, benoetigen Sie einen von drei Ansaetzen:
| Ansatz | Mechanismus | Latenz | Komplexitaet | Zuverlaessigkeit |
|---|---|---|---|---|
| GATT-Verbindung | Scanner verbindet sich mit Beacon, schreibt Config-Characteristic | Sekunden | Mittel | Hoch (bidirektional) |
| Verschluesselte Scan-Response | Config in Scan-Response eingebettet | Minuten | Niedrig | Mittel (unidirektional) |
| Hersteller-spezifische Daten | Config in Payload-Rotation codiert | Minuten | Mittel | Mittel (unidirektional) |
2.2 GATT-basierte Konfiguration (Empfohlen)
Die meisten modernen Beacons expose-en einen GATT-Konfigurations-Service. Ein nahegelegener Scanner verbindet sich, authentifiziert und schreibt neue Parameter:
| Characteristic | UUID (gemeinsam) | Zugriff | Zweck |
|---|---|---|---|
| Advertising-Intervall | 0x2A04 | Lesen/Schreiben | Broadcast-Frequenz setzen |
| TX-Leistung | 0x2A07 | Lesen/Schreiben | Sendeleistung setzen |
| Batteriestand | 0x2A19 | Lesen | Batteriezustand ueberwachen |
| Firmware-Version | 0x2A26 | Lesen | Firmware-Version verfolgen |
| Herstellerdaten | 0x2A3D | Lesen/Schreiben | Custom-Payload-Konfiguration |
| Verbindungsintervall | 0x2A04 | Lesen/Schreiben | Verbindungsgeschwindigkeit optimieren |
Typische Konfigurationssession:
1. Scanner entdeckt Beacon per MAC/UUID
2. Scanner initiiert Verbindung (30-100ms)
3. Beacon erfordert Authentifizierung (AES-128 Challenge-Response)
4. Scanner schreibt neue Konfigurationswerte
5. Beacon validiert und wendet an
6. Beacon sendet Bestaetigung
7. Scanner trennt
Gesamtzeit: 200-500ms pro Beacon
2.3 Konfigurations-Payload-Codierung
Für effiziente OTA-Konfiguration packen Sie Parameter in ein kompaktes Binaerformat:
Konfigurationspaket (24 Bytes):
[0] Konfigurationsversion (1 Byte)
[1] Flags: bit0=adv_intervall, bit1=tx_leistung, bit2=payload, bit3=channel_map
[2-3] Advertising-Intervall (2 Bytes, 100ms-Einheiten, 0=unveraendert)
[4] TX-Leistung (1 Byte, dBm, vorzeichenbehaftet, 0=unveraendert)
[5-20] Payload-Daten (16 Bytes, 0xFF=unveraendert)
[21] Channel-Map (1 Byte, Bitmaske ch37/ch38/ch39)
[22-23] CRC16 (2 Bytes)
Mit 24 Bytes pro Paket kann ein Scanner ca. 2 Beacons pro Sekunde konfigurieren (inkl. Verbindungs-Overhead). Fuer 500 Beacons: ~4 Minuten wenn alle in Reichweite.
2.4 Geplante Konfigurationsfenster
Zur Minimierung von Stoerungen planen Sie Aenderungen waehrend Schwachlastzeiten:
| Fenster | Zeit | Grund |
|---|---|---|
| Einzelhandel | 02:00-05:00 | Geschäft geschlossen, keine Kundenbeeintraechtigung |
| Museum | 02:00-06:00 | Geschlossene Stunden |
| Lager | 12:30-13:00 | Mittagspause, reduzierter Gabelstaplerverkehr |
| Krankenhaus | 03:00-04:00 | Geringste Patientenbewegung |
3. OTA-Firmware-Update-Strategien
3.1 Das Brick-Risiko
OTA-Firmware-Updates sind die riskanteste Operation im Fleet-Management. Ein fehlgeschlagenes Update kann ein Beacon permanent bricken und physischen Austausch erfordern. Bei 500 Beacons bedeutet eine 1% Brick-Rate 5 Austausche — kostspielig bei 4-Meter-Deckenmontage.
3.2 Dual-Bank-OTA (Sicher)
Der sicherste Ansatz verwendet Dual-Bank-Firmware-Speicherung:
Flash-Layout (nRF52832, 512KB):
0x00000-0x01000 Bootloader (4KB)
0x01000-0x26000 Bank A: Aktive Firmware (156KB)
0x26000-0x4B000 Bank B: Download-Buffer (156KB)
0x4B000-0x4D000 Konfig & Kalibrierung (8KB)
0x4D000-0x50000 Bootloader-Einstellungen (12KB)
Update-Prozess:
1. Scanner verbindet sich per GATT mit Beacon
2. Beacon meldet verfuegbaren Flash und aktuelle Firmware-Version
3. Scanner uebertraegt neue Firmware zu Bank B (gestueckt, 20 Bytes pro GATT-Write)
4. Beacon verifiziert CRC32 des heruntergeladenen Images
5. Beacon tauscht Bänke: Bank B aktiv, Bank A Rollback
6. Beacon startet mit neuer Firmware neu
7. Wenn neue Firmware nicht startet (Watchdog-Timeout), bootet Bootloader automatisch von Bank A zurueck
| Parameter | Wert |
|---|---|
| Firmware-Image-Groesse | ~140KB |
| GATT MTU | 23 Bytes (20 Payload) |
| Writes pro OTA | 7.168 |
| Zeit pro Write | ~15ms (Verbindungsintervall 15ms) |
| Gesamt-OTA-Zeit | ~107 Sekunden |
| Retry-Overhead (10%) | ~12 Sekunden |
| Gesamt-OTA-Zeit mit Retrys | ~120 Sekunden pro Beacon |
3.3 Gestaffelte Rollout-Strategie
Aktualisieren Sie niemals alle Beacons gleichzeitig. Verwenden Sie gestaffelten Rollout:
| Stufe | Prozentsatz | Anzahl (500 Beacons) | Wartezeit | Aktion bei Fehlschlag |
|---|---|---|---|---|
| 1 | 1% | 5 | 24 Stunden | Rollout stoppen, untersuchen |
| 2 | 5% | 25 | 48 Stunden | Stopp bei >1 Fehlschlag |
| 3 | 20% | 100 | 48 Stunden | Stopp bei >2% Fehlschlag |
| 4 | 50% | 250 | 72 Stunden | Stopp bei >2% Fehlschlag |
| 5 | 100% | 500 | — | 1 Woche ueberwachen |
3.4 OTA-Zeitbudget fuer 500 Beacons
Mit 10 gleichzeitigen Scanner-Verbindungen:
Stufe 1: 5 Beacons / 10 Scanner = 1 Batch x 2 Min = 2 Min
Stufe 2: 25 Beacons / 10 Scanner = 3 Batches x 2 Min = 6 Min
Stufe 3: 100 Beacons / 10 Scanner = 10 Batches x 2 Min = 20 Min
Stufe 4: 250 Beacons / 10 Scanner = 25 Batches x 2 Min = 50 Min
Stufe 5: 500 Beacons / 10 Scanner = 50 Batches x 2 Min = 100 Min
Gesamt aktive OTA-Zeit: ~178 Min (alle Stufen)
Gesamt Kalenderzeit (mit Wartezeiten): ~9 Tage
4. Batterielebensdauer-Ueberwachung und -Vorhersage
4.1 Batteriestand-Auslesen
Drei Methoden zur Ermittlung der Batteriespannung:
| Methode | Genauigkeit | Overhead | Verfuegbar |
|---|---|---|---|
| Battery Level Service (GATT 0x2A19) | ±5% | Benoetigt Verbindung | Waehrend Config/OTA-Sessions |
| ADC-Messung im Advertising-Payload | ±2% | 50uA pro Messung, 2 Bytes Payload | Jede Advertisement |
| Spannungs-Inferenz aus RSSI | ±20% | Keine (passiv) | Nur Scan-Daten |
4.2 Batteriespannungs-Codierung im Payload
Herstellerdaten (4 Bytes):
[0-1] Company ID (0x0059 = Nordic)
[2] Batteriespannung (1 Byte, 20mV-Einheiten, 1,6V-Offset)
Beispiel: 0x33 = 51 = 51*20mV + 1600mV = 2620mV = 2,62V
[3] Status-Flags: bit0=niedrige_batterie, bit1=ota_bereit, bit2=config_ausstehend
Eine frische CR2032 liest ~3,0V (0x4C = 76). Lebensdauerende ~2,0V (0x14 = 20). Dies ergibt 56 diskrete Stufen im Nuetzlichkeitsbereich — ausreichend fuer Monitoring.
4.3 Batterielebensdauer-Vorhersagemodell
Mit Scan-Daten eine Erschoepfungskurve pro Beacon erstellen:
Taeglicher Spannungsabfall = (V_heute - V_gestern) / verstrichene_Tage
Verbleibende Lebensdauer (Tage) = (V_aktuell - V_lebensdauerende) / taeglicher_Spannungsabfall
Beispiel fuer ein Beacon mit 1-Sekunden-Advertising-Intervall:
| Tag | Spannung (mV) | Taeglicher Abfall (mV) | Vorhersage (Tage) |
|---|---|---|---|
| 1 | 3020 | — | — |
| 30 | 2985 | 1,17 | 841 |
| 90 | 2920 | 1,18 | 783 |
| 180 | 2810 | 1,22 | 664 |
| 365 | 2540 | 1,30 | 415 |
| 500 | 2280 | 1,43 | 196 |
| 600 | 2010 | 2,70 | 4 |
Beachten Sie die beschleunigte Erschoepfung nahe dem Lebensdauerende aufgrund zunehmenden Innenwiderstands. Das Vorhersagemodell sollte einen 14-Tage-gleitenden Durchschnitt verwenden.
4.4 Flottenweites Batterie-Dashboard
| Metrik | Ziel | Alert-Schwelle |
|---|---|---|
| Flottendurchschnittsspannung | > 2,7V | < 2,5V |
| Beacons unter 2,4V | 0 | > 2% der Flotte |
| Vorhersagliche Austausche (30 Tage) | 0 | > 5 |
| Monatliche Batterieaustauschkosten | < $50 | > $200 |
5. Health-Check und Anomalieerkennung
5.1 Heartbeat-Erkennung
Ein Beacon gilt als lebendig, wenn mindestens ein Scanner es innerhalb des erwarteten Intervalls gesehen hat:
| Advertising-Intervall | Heartbeat-Timeout | Begruendung |
|---|---|---|
| 100ms | 30 Sekunden | 300 verpasste Pakete = Anomalie |
| 1 Sekunde | 5 Minuten | 300 verpasste Pakete = Anomalie |
| 10 Sekunden | 30 Minuten | 180 verpasste Pakete = Anomalie |
5.2 RSSI-basierte Anomalieerkennung
| Anomalie | RSSI-Muster | Wahrscheinliche Ursache |
|---|---|---|
| Beacon verschoben | RSSI faellt > 15dB ploetzlich bei allen Scannern | Physische Verschiebung |
| Scanner-Ausfall | RSSI faellt bei einem Scanner, stabil bei anderen | Scanner-Hardware-Problem |
| RF-Stoerung | RSSI-Varianz steigt > 6dB | Neue Stoerquelle |
| Batterie niedrig | RSSI faellt allmaehlich 3-5dB ueber Wochen | Reduzierte TX-Leistung bei niedriger Spannung |
| Hindernis | RSSI faellt bei einem Scanner, verzoegert bei anderen | Neue physische Barriere |
5.3 Statistische Schwellen
Gleitendes Fenster (1 Stunde, 3600 Samples bei 1s):
Mittelwert RSSI: mu = sum(RSSI_i) / N
Std-Abw: sigma = sqrt(sum((RSSI_i - mu)^2) / N)
Alert wenn: |RSSI_aktuell - mu| > 3 * sigma (99,7% Konfidenz)
5.4 Advertising-Intervall-Monitoring
Einige Beacons driften ihr Intervall aufgrund von Kristalltoleranz oder Firmware-Bugs:
Erwartet: 1000ms +/- 50ms (BLE-Spec erlaubt +/- 50ms Jitter)
Gemessen: Zeit zwischen aufeinanderfolgenden Scans desselben Beacons
>1100ms oder <900ms konsistent: Firmware-Problem
Hohe Varianz (>200ms stddev): Oszillatorinstabilitaet
6. Telemetrie-Daten-Pipeline
6.1 Datenvolumen-Schaetzung
500 Beacons bei 1Hz, gescannt von 20 Gateways:
Pakete pro Beacon pro Sekunde: 1
Pakete pro Gateway pro Sekunde: 500 / 3 = 167
Pakete pro Flotte pro Sekunde: 167 * 20 = 3.340
Pakete pro Tag: 3.340 * 86.400 = 288.576.000
Pro Paket (JSON): ~200 Bytes
Taegliches Datenvolumen: 57,7 GB raw
Mit Deduplikation:
Nach Dedup: 1.440.000
Dedup-Volumen: 288 MB/Tag
6.2 Empfohlene Pipeline-Architektur
Beacons
|
Gateways (BLE-Scan, Dedup, Buffer)
|
MQTT (TLS, QoS 1)
|
Message Broker (Mosquitto/EMQX)
|
Stream Processor (Kafka/Faust/Python)
|---> Time-Series DB (InfluxDB/ClickHouse)
|----> Alert Engine (Prometheus/Grafana)
|---> Object Storage (S3/MinIO)
6.3 Gateway-Software-Stack
| Komponente | Technologie | Zweck |
|---|---|---|
| BLE-Scanner | Python + bleak / C + BlueZ | Advertising-Pakete scannen |
| Dedup-Filter | Custom (30s-Fenster pro Beacon) | Duplikate entfernen |
| Lokaler Buffer | SQLite / Redis | Netzwerkausfaelle ueberbruecken |
| MQTT-Client | paho-mqtt / Eclipse Paho | An Cloud weiterleiten |
| Health-Agent | systemd-Watchdog | Auto-Restart bei Ausfall |
6.4 Daten-Schema
{
"beacon_id": "AA:BB:CC:DD:EE:01",
"timestamp": "2026-08-23T01:00:00.123Z",
"rssi": -67,
"gateway_id": "gw-lobby-01",
"battery_mv": 2780,
"temperature_c": 24.5,
"adv_interval_ms": 1000,
"firmware_ver": "2.3.1",
"payload_hash": "a1b2c3d4"
}
7. Geraetemanagement-Plattform-Vergleich
| Plattform | Beacon-Support | OTA | Flottengroessenlimit | Preismodell | Self-Hosted |
|---|---|---|---|---|---|
| Kontakt.io Panel | Voll (Kontakt-Beacons) | Ja | 100.000+ | Pro Beacon/Monat | Nein |
| Estimote Cloud | Voll (Estimote-Beacons) | Ja | 50.000+ | Pro Beacon/Monat | Nein |
| RadBeacon Dashboard | Voll (nur RadBeacon) | Ja | 10.000+ | Gratis (Hardware-Lock-in) | Nein |
| BeeCastle / BlueUp | Voll (proprietaer) | Ja | 5.000+ | Pro Beacon/Monat | Nein |
| Custom (Open Source) | Beliebiges GATT-Beacon | Custom | Unbegrenzt | Infra-Kosten | Ja |
7.1 Build-vs-Buy-Entscheidung
| Faktor | Buy (Managed) | Build (Custom) |
|---|---|---|
| Setup-Zeit | 1-2 Tage | 2-4 Wochen |
| Monatliche Kosten (500 Beacons) | $250-500/Monat | $50-100 (Cloud-Infra) |
| Flexibilitaet | Beschraenkt | Volle Kontrolle |
| Multi-Vendor-Support | Meist Single-Vendor | Beliebiges GATT-Beacon |
| OTA-Zuverlaessigkeit | Vendor-verwaltet | Eigenverantwortung |
8. Sicherheitsaspekte des Fleet-Managements
8.1 Konfigurations-Authentifizierung
Alle Konfigurations-Writes muessen authentifiziert werden. Empfohlen: AES-128 Challenge-Response:
1. Scanner sendet Challenge (16 zufaellige Bytes)
2. Beacon berechnet HMAC-SHA256(challenge, shared_key), kuerzt auf 16 Bytes
3. Beacon sendet Response
4. Scanner verifiziert
5. Verschluesselte Config-Session (AES-128-CCM)
8.2 Schluesselrotation
| Schluesseltyp | Scope | Rotationsperiode | Mechanismus |
|---|---|---|---|
| Config-Auth-Schluessel | Pro Beacon | 12 Monate | OTA-Rotationsbefehl |
| OTA-Signierschluessel | Pro Flotte | 6 Monate | Firmware-Update mit neuem Schluessel |
| Gateway-API-Schluessel | Pro Gateway | 3 Monate | Cloud-Dashboard-Rotation |
| MQTT-Broker-Zertifikat | Pro Gateway | 12 Monate | Auto-Erneuerung |
8.3 Rogue-Beacon-Erkennung
| Check | Methode | Alert-Bedingung |
|---|---|---|
| MAC-Allowlist | Gescannte MAC mit registrierter Liste vergleichen | Unbekannte MAC mit Flotten-UUID |
| Payload-Signatur | HMAC in Herstellerdaten | Ungueltige Signatur |
| RSSI-Geofence | RSSI mit erwartetem Bereich vergleichen | Inkonsistent mit Standort |
| Firmware-Version | Via GATT lesen | Unbekannte Version |
9. Bereitstellungsautomatisierung
9.1 Pre-Deployment-Konfiguration
Workflow:
1. Beacon via USB-Dock verbinden (10er-Batch)
2. MAC-Adresse lesen
3. Beacon-ID und Standort aus Bereitstellungsplan zuweisen
4. Konfiguration schreiben (UUID, Major, Minor, Intervall, TX-Leistung)
5. Authentifizierungsschluessel schreiben
6. Konfiguration per Scan verifizieren
7. In Inventar-Datenbank eintragen
8. Als "Bereitstellungsbereit" markieren
Zeit pro Beacon: 15-20 Sekunden
500 Beacons: ~2,5 Stunden
9.2 Installationsverifizierung
Nach physischer Installation Standort mit Scanner-App ablaufen:
Pro Beacon:
1. An erwartetem Standort scannen
2. RSSI im erwarteten Bereich (-40 bis -80 dBm)
3. Advertising-Payload korrekt
4. Batteriespannung > 2,8V
5. Als "installiert und verifiziert" markieren
Zeit: 500 Beacons / 30 Standorte: ~4-6 Stunden
9.3 Post-Deployment-Health-Check
Automatisierter 24-Stunden-Check:
| Check | Schwelle | Aktion bei Fehlschlag |
|---|---|---|
| Alle Beacons gesehen | 100% | Fehlende untersuchen |
| RSSI im Bereich | 95% innerhalb +/- 10dB | Platzierung pruefen |
| Batteriespannung > 2,8V | 100% | Niedrige Batterien ersetzen |
| Advertising-Intervall korrekt | 100% | Rekonfigurieren |
| Keine Rogue-Beacons | 0 unbekannte MACs | Untersuchen |
10. Fallstudie: 500-Beacon-Retail-Bereitstellung
10.1 Setup
- Beacons: 500 Einheiten, nRF52832, CR2032, 1s-Advertising
- Standorte: 30 Filialen (15-20 Beacons je)
- Gateways: 60 Einheiten (2 pro Filiale), Raspberry Pi 4 + BLE-Dongle
- Anwendungsfall: Proximity-Marketing + Indoor-Navigation
- Monitoring: Custom-Plattform (Python + MQTT + InfluxDB + Grafana)
10.2 Betriebsmetriken (Jahr 1)
| Metrik | Wert | Hinweise |
|---|---|---|
| Bereitgestellte Beacons | 500 | 30 Filialen |
| Ausgetauscht (Batterie) | 12 (2,4%) | Ø 380 Tage bis Austausch |
| Ausgetauscht (Defekt) | 3 (0,6%) | 2 Firmware-Hangs, 1 Hardware-Ausfall |
| OTA-Updates gepusht | 2 | Minor-Firmware-Patches |
| OTA-Fehlschlaege | 0 | Dual-Bank-Rollback einmalig funktioniert |
| Ø Uptime | 99,6% | 4,2 Beacons jederzeit offline |
| Mittlere Erkennungszeit | 8 Minuten | Via Heartbeat-Monitoring |
| Mittlere Reparaturzeit | 2,5 Tage | Techniker mit Ersatz |
| Monatliche Monitoring-Kosten | $85 | AWS (EC2 + RDS + S3) |
| Monatliche Gateway-Kosten | $60 | Cellular-Backhaul (60 x $1) |
10.3 Gelernte Lektionen
1. Gateway-Redundanz ist kritisch: Ein Gateway pro Filiale verursachte Blindspots waehrend Reboots. Zwei Gateways mit ueberlappender Abdeckung loeste dies.
2. Batterievorhersage funktioniert: Das 14-Tage-Gleitmittel-Modell sagte 10 von 12 Batterieausfaellen innerhalb 7 Tagen vorher.
3. Firmware-Hang ist der stille Killer: 2 Beacons hingen mit deaktiviertem Watchdog. Externer Watchdog (Hardware-Reset-IC) in v2-Hardware hinzugefuegt.
4. RSSI-Geofencing erkannte 1 Diebstahl: Ein Beacon wurde in eine andere Filiale verschoben. RSSI-Musteränderung loeste Alert in 30 Minuten aus.
11. Fleet-Management-Checkliste
- [ ] Bereitstellungsplan mit Beacon-ID, Standort und Konfiguration pro Geraet
- [ ] Pre-Deployment-Batch-Konfigurations-Workflow (USB-Dock + Skript)
- [ ] Gateway-Netzwerk mit ueberlappender Abdeckung (min. 2 pro Standort)
- [ ] MQTT-Broker mit TLS und QoS 1
- [ ] Time-Series-DB fuer Scan-Daten (InfluxDB oder ClickHouse)
- [ ] Heartbeat-Monitoring mit konfigurierbarem Timeout
- [ ] Batteriespannungs-Tracking mit 14-Tage-Gleitmittel-Vorhersage
- [ ] RSSI-Anomalieerkennung (3-Sigma-Gleitfenster)
- [ ] Alert-Pipeline (E-Mail/SMS/Slack) mit Eskalationsregeln
- [ ] GATT-basierte Remote-Konfiguration mit AES-128-Authentifizierung
- [ ] Dual-Bank-OTA mit gestaffeltem Rollout (1% / 5% / 20% / 50% / 100%)
- [ ] OTA-Signierschluessel und Schluesselrotationszeitplan
- [ ] Rogue-Beacon-Erkennung (MAC-Allowlist + Payload-Signatur)
- [ ] Installationsverifizierung mit Scanner-App
- [ ] Automatisierter 24h-Post-Deployment-Health-Check
- [ ] Fleet-Dashboard mit Status, Batterie und Anomalie-Alerts
- [ ] Ersatz-Beacon-Inventar (5% der Flottengroesse)
- [ ] Techniker-Dispatch-Verfahren mit SLA-Zielen
- [ ] Monatlicher Fleet-Health-Report (Uptime, Ausfaelle, Batterietrends)
- [ ] Jaehrliche Schluesselrotation und Sicherheitsaudit
12. Zusammenfassung
Beacon-Fleet-Management ist ein System-Engineering-Problem, kein Hardware-Problem. Die Beacons sind einfach; die Infrastruktur drumherum ist komplex. Wesentliche Punkte:
1. Scan-Daten sind Ihr einziger Rueckkanal. Designen Sie Ihre Pipeline um das, was Sie passiv beobachten koennen.
2. Dual-Bank-OTA ist nicht verhandelbar fuer Flotten > 50 Beacons. Das Rollback-Sicherheitsnetz zahlt sich beim ersten Firmware-Update-Ausfall aus.
3. Batterievorhersage aus Spannungstrends ist mit 14-Tage-Gleitmittel auf 7 Tage genau. Tauschen Sie Beacons proaktiv aus, bevor sie verstummen.
4. Heartbeat-Monitoring mit 5-Minuten-Timeout erfasst 95% der Ausfaelle innerhalb 15 Minuten.
5. Gestaffelter OTA-Rollout (1% bis 100% ueber 9 Tage) verhindert Flotten-weites Bricking.
6. Gateway-Redundanz (2 pro Standort mit ueberlappender Abdeckung) eliminiert Blindspots waehrend Wartung.
Fuer Organisationen, die Bluetooth Beacon-Infrastruktur im Massstab bereitstellen, ist die Fleet-Management-Plattform, wo das eigentliche Engineering stattfindet. Beacons sind Commodities; die Monitoring-, Konfigurations- und OTA-Pipeline ist der Unterscheidungsfaktor zwischen einer selbstverwalteten Bereitstellung und einer mit konstantem manuellem Eingriff.
