Ein einfacher Advertising-Beacon beantwortet nur eine Frage: “Wo ist dieses Tag?”. Fuegen Sie einen Sensor hinzu — Temperatur, Feuchtigkeit, Beschleunigung, Licht — wird dieselbe Hardware zu einem verteilten Messknoten, der “Wie ist der Zustand hier, und hat sich etwas geaendert?” beantwortet. Dieser Artikel behandelt die Engineering-Entscheidungen hinter Sensor-Beacons: wie man Sensoren anbindet, wie man Messwerte in die 31-Byte-Werbenutzlast packt, wie die Abtastrate die Batterielebensdauer treibt und wie die On-Device-Schwellenwertslogik einen dummen Sender in einen Edge-Detektor verwandelt.
1. Warum Sensor-Beacons anders sind
Ein reines Positions-Beacon sendet eine feste Nutzlast in festem Intervall. Sein Stromverbrauch ist deterministisch und seine Firmware trivial. Ein Sensor-Beacon muss:
1. Den Sensor aus dem Schlaf wecken (oder in einem Low-Power-Abtastmodus halten)
2. Einen Messwert erfassen ueber I2C/SPI, was Millisekunden dauert und Sensor-Ruhestrom verbraucht
3. Den Wert verarbeiten (Filterung, Kalibrierung, Schwellenwertpruefung)
4. Entscheiden, was gesendet wird — der Rohwert, ein Delta oder nichts
5. Kodieren und werben das Ergebnis
Jeder Schritt fuegt Latenz und Strom hinzu. Das Design-Problem ist die Balance zwischen Messgenauigkeit und Batterielebensdauer, denn das Sensorsubsystem — nicht das Funkmodul — dominiert das Budget, sobald man oefter als ein paar Mal pro Stunde abtastet.
2. Sensor-Schnittstellen und Stromverbrauch
Die meisten Beacon-Sensoren haengen an einem digitalen Bus. Die zwei gaengigen Optionen:
| Schnittstelle | Speed | Typ. Sensorstrom | Wake-Latenz | Hinweise |
|---|---|---|---|---|
| I2C | 100-400 kHz | 1-15 µA idle, 100-500 µA aktiv | 1-5 ms | 2 Leitungen, adressbegrenzt, leicht teilbar |
| SPI | 1-8 MHz | 2-20 µA idle, 200-800 µA aktiv | 0,1-1 ms | 4 Leitungen, schneller, niedrigere Latenz |
Fuer ein Knopfzellen-Beacon ist die dominierende Kosten nicht der Aktivstrom, sondern die Energie pro Probe = (Wake-Latenz + Konvertierungszeit) × Durchschnittsstrom. Ein Feuchtigkeitssensor, der 10 ms bei 300 µA braucht, kostet 3 µC pro Messung. Bei 1 Probe/Stunde sind das 3 µC/h ≈ 0,83 µA im Schnitt — vernachlaessigbar. Bei 1 Probe/Minute sind es 50 µA im Schnitt — jetzt konkurriert es mit dem Funkmodul.
2.1 Gaengige Sensoren und ihre Fussabdruecke
| Sensor | Typ. Bauteil | Bus | Aktivstrom | Konvertierungszeit | Ausgangsbereich |
|---|---|---|---|---|---|
| Temperatur | TMP117 | I2C | 3,5 µA | 15,5 ms (avg) | -0,1 bis 0,2 °C |
| Feuchtigkeit | HDC2080 | I2C | 300 µA | 1,2 ms | ±2 % rF |
| 3-Achsen-Beschl. | LIS2DH12 | I2C/SPI | 4 µA (Low-Power) | 1 ms | ±2/4/8/16 g |
| Umgebungslicht | OPT3001 | I2C | 1,8 µA | 100-800 ms | 0,01-83k lux |
| Druck | LPS22HB | I2C/SPI | 25 µA | 13 µs (ODR) | ±0,025 hPa |
| CO2 (NDIR) | SCD40 | I2C | 18 mA (Puls) | 0,5-5 s | 0-40000 ppm |
Der CO2-Sensor sticht heraus: bei 18 mA ist er 1000× der Schlafstrom des Funkmoduls und kann nicht kontinuierlich an einer Knopfzelle laufen. Er ist das kanonische Beispiel, warum die Sensorwahl die Stromarchitektur begrenzt — ein CO2-Beacon braucht eine groessere Zelle oder Kabelstrom.
3. Kodierung von Sensordaten in 31 Bytes
Ein BLE-Werbepaket traegt eine 31-Byte-Nutzlast (Legacy), aufgeteilt in AD-Strukturen: 1 Byte Laenge, 1 Byte Typ, dann Daten. iBeacon nutzt 25 Byte Herstellerdaten; Eddystone-URL nutzt ~20. Das laesst wenig Platz fuer Sensoren.
3.1 Die Regel “Anhaengen, nicht ersetzen”
Behalten Sie den Identitaetsrahmen (iBeacon / Eddystone-UID) intakt fuer Positionssysteme und fuegen Sie einen sekundaeren Werberahmen hinzu, der Sensordaten traegt. BLE erlaubt einem Beacon, zwischen mehreren Werberahmen zu wechseln (abwechselnd bei jedem Werbeevent). Ein Gateway, das alle 3 Kanaele ueber einige Sekunden scannt, erfasst beide.
3.2 Eddystone-TLM: der eingebaute Telemetriekanal
Eddystone-TLM ist der standardisierte Weg, Telemetrie zu tragen:
| Feld | Bytes | Inhalt |
|---|---|---|
| Version | 1 | 0x00 |
| Batteriespannung | 2 | 1 mV Einheiten, 0-65535 |
| Beacon-Temperatur | 2 | 8,8 Fixed-Point, °C |
| PDU-Zaehler | 4 | Lebenspaketzaehler |
| Betriebszeit | 4 | 0,1 s Einheiten |
TLM ist sauber, aber begrenzt: ein Temperaturwert, nur Batterie, keine Feuchte/Beschleunigung. Fuer reichere Daten brauchen Sie einen benutzerdefinierten Herstellerdatenrahmen (MSD).
3.3 Beispiel fuer benutzerdefinierte MSD-Kodierung
Ein kompaktes Layout fuer ein Multi-Sensor-Beacon (Little-Endian):
Byte 0: Company ID LSB (0x4C fuer Apple, oder Ihre CID)
Byte 1: Company ID MSB
Byte 2: Rahmentyp = 0x50 (Vendor-Sensorrahmen)
Byte 3: Sensor-Bitmap (bit0 temp, bit1 hum, bit2 accel, bit3 licht, bit4 batt)
Byte 4-5: Temperatur, 8,8 Fixed-Point, vorzeichenbehaftet (×256)
Byte 6-7: Feuchtigkeit, 8,8 Fixed-Point (×256)
Byte 8-9: Licht, 10-Bit-Logskala (0-1023 → 0,01-100k lux log)
Byte 10-11:Batterie mV (0-65535)
Byte 12-13:Beschleunigungsbetrag, 8,8 Fixed (g × 256)
Byte 14: Status / Flags (Bewegung erkannt, Schwelle ausgeloest)
Byte 15: Sequenznummer (wrappt 0-255)
Dieser 16-Byte-Rahmen existiert neben einem iBeacon-Identitaetsrahmen mit Platz zu ueber. Die Bitmap erlaubt einem Beacon, fehlende Sensoren wegzulassen und die Nutzlast zu verkleinern. Ein Nur-Temperatur-Beacon sendet Byte 0-7 (8 Byte); ein vollstaendiger Sensorknoten sendet alle 16.
3.4 Komprimierungstricks
- Delta-Kodierung: Werben Sie die Aenderung seit der letzten Messung, nicht den Absolutwert. Eine Temperatur, die 0,1 °C/Stunde driftet, passt in ein vorzeichenbehaftetes 8-Bit-Delta (±127 × 0,01 °C) statt eines 16-Bit-Absolutwerts.
- Fixed-Point statt Float: 8,8 Fixed-Point kostet 2 Byte fuer ±127,99 mit 0,004 °C Aufloesung — genug fuer Umweltmonitoring.
- Logskala Licht: `encoded = round(1023 × log10(lux/0,01) / log10(100000/0,01))` packt 5 Dekaden in 10 Bit.
- Run-Length-Skip: Wenn sich nichts ueber den Rauschboden hinaus geaendert hat, senden Sie einen Heartbeat-Rahmen alle N Zyklen statt jeden Zyklus.
4. Abtaststrategie und Strombudget
Der groesste Hebel auf die Batterielebensdauer ist wie oft Sie abtasten. Drei Strategien:
4.1 Festes periodisches Abtasten
Am einfachsten: alle T Sekunden abtasten, jede Messung werben.
Durchschnittsstrom ≈ I_radio_adv × duty_adv + I_sensor_avg × (t_sample / T)Fuer T = 60 s, t_sample = 5 ms, I_sensor_avg = 200 µA: Sensorbeitrag = 200 µA × 5ms/60s = 0,017 µA — vernachlaessigbar. Das Funkmodul (z.B. Schlaf 1 µA, 3 ms bei 15 mA alle 1 s) dominiert mit ~45 µA. Also bei 1/min Abtasten ist der Sensor gratis; pusht man auf 1/s, steigt der Sensorbeitrag auf ~1 µA — noch klein, aber nicht mehr vernachlaessigbar.
4.2 Adaptives / On-Demand-Abtasten
Langsam abtasten (z.B. alle 5 min) fuer den Identitaetsrahmen, aber den Interrupt des Beschleunigungssensors den MCU bei Bewegung wecken lassen. Der Beschleunigungssensor im Wake-on-Motion-Modus zieht ~1-4 µA kontinuierlich, eliminiert aber Funkaktivitaet, bis etwas passiert. Fuer Asset-Tracking, wo Bewegung selten ist, senkt das den Durchschnittsstrom um 10-100×.
4.3 Schwellenwert-Ausgeloeste Burst
Das Beacon bleibt stumm (Deep Sleep, <1 µA), bis ein Wert eine Grenze ueberschreitet — Gefrierer ueber 0 °C, Vibration ueber 2 g, Tuer geoeffnet. Beim Ausloesen:
1. Voll wecken
2. Einen Burst von N Proben bei hoher Rate erfassen (zur Ereignischarakterisierung)
3. Einen Alarmrahmen mit Spitzenwert + Zeitstempel werben
4. Zurueck in Deep Sleep
Das ist das Edge-Intelligence-Muster: Das Beacon entscheidet, *ob* es spricht, nicht nur, *was* es sagt. Der Durchschnittsstrom bricht auf den Schlafboden plus seltene Burstenergie zusammen.
4.4 Strombudget-Rechenbeispiel
Knopfzelle CR2032 = 225 mAh = 810 C. Ziellebensdauer 2 Jahre = 17,5 k Stunden.
| Komponente | Strom | Duty | Durchschnitt |
|---|---|---|---|
| nRF52 Schlaf | 0,6 µA | 99,9% | 0,6 µA |
| Radio adv (3 ms @ 15 mA, 1/2 s) | 15 mA | 0,6% | 90 µA* |
| Sensorabtastung (5 ms @ 200 µA, 1/min) | 200 µA | 0,0008% | 0,017 µA |
| Beschl. Wake-on-Motion | 2 µA | 100% | 2 µA |
| Gesamt (periodisch) | — | — | ~92,6 µA |
| Gesamt (Schwelle, 99% stumm) | — | — | ~2,6 µA |
*Das Funkmodul dominiert den periodischen Modus. Umschalten auf Schwellenwertausloesung senkt den Gesamtstrom 35× und verlaengert die Lebensdauer von ~2,5 Jahren auf Jahrzehnte (Zellselbstentladung wird zum Limit).
5. On-Device-Filterung und Trigger-Logik
Jeden Rohwert senden verschwendet Bandbreite und Batterie. Das Beacon sollte filtern:
- Toter Bereich (Deadband): Nur werben, wenn |Wert − zuletzt_gesendet| > Δ (z.B. 0,3 °C). Unterdrueckt Rausch-Chatter.
- Gleitender Durchschnitt: 4-8 Proben mitteln, um Einzel-Spikes vor dem Deadband-Vergleich zu toeten.
- Aenderungsrate: Ausloesen, wenn d(Wert)/dt eine Steigung ueberschreitet (z.B. Temp faellt 5 °C/min = Kompressor defekt).
- Hysterese: Separate Ein-/Aus-Schwellen (z.B. Alarm bei >0 °C, Freigabe bei <-0,5 °C), um Alarm-Flattern an der Grenze zu vermeiden.
Eine minimale Zustandsmaschine:
Zustand: IDLE
bei Timer-Tick:
v = sensor_lesen()
v_f = tiefpass(v)
if |v_f - zuletzt_gesendet| > deadband:
werben(v_f); zuletzt_gesendet = v_f
if v_f > schwelle_hoch and Zustand == IDLE:
Zustand = ALARM; alarm_werben(v_f, grund=HOCH)
if Zustand == ALARM and v_f < schwelle_niedrig:
Zustand = IDLE; freigabe_werben()
Diese Logik laeuft in <1 ms auf dem nRF52 und kostet vernachlaessigbaren Strom gegenueber dem Funkmodul.
6. Echte Bereitstellungsmuster
6.1 Kuehlkettenueberwachung
Ein Temp+Feuchte-Beacon im Impfstoffkuehler. Alle 5 min abtasten, werben bei Deadband (0,2 °C) oder Schwelle (>8 °C Alarm, <-0,5 °C Freigabe mit Hysterese). Das Gateway protokolliert die Zeitreihe; ein Verstoss loest Push-Benachrichtigung aus. Batterie: CR2477 (1000 mAh) haelt 3+ Jahre bei 5-min-Abtastung.
6.2 Predictive-Maintenance-Vibration
Ein Beschleunigungs-Beacon an einem Motor verschraubt. Im Wake-on-Motion erfasst es 1-kHz-Vibrationsbuerste nur, wenn der Motor laeuft. RMS-Beschleunigung ueber ein Fenster zeigt Lagerverschleiss. Wochenuebergreifender RMS-Trendvergleich (im Gateway berechnet) sagt Ausfall vor Bruch voraus. Strom: Die 2 µA Idle des Beschleunigungssensors dominieren; CR2032 haelt 1-2 Jahre.
6.3 Smart-Building-Belegung
Ein Licht+PIR- (oder mmWave-) Beacon in jedem Raum. Lichtpegel + passives IR geben Praesenz ohne Kameras. Das Beacon wirbt nur Belegungszustandsaenderungen (Eintritt/Austritt), nicht kontinuierliches lux. Durchschnittsstrom dominiert vom PIR-Ruhestrom ~5 µA — ein AA-Pack haelt Jahre.
7. Gateway-seitige Ueberlegungen
Das Gateway muss den benutzerdefinierten MSD-Rahmen verstehen. Praktische Punkte:
- Alle 3 Kanaele scannen: Sensorrahmen wechseln mit Identitaetsrahmen; beide zu erfassen braucht Multikanal-Verweildauer ≥2-3 Werbeintervalle.
- Bitmap parsen: Nur vorhandene Sensoren dekodieren; unbekannte Rahmentypen graceful ignorieren.
- Sequenznummern handhaben: Verpasste Rahmen (Luecke in seq) erkennen, um unzuverlaessige Links zu markieren.
- Zeitreihe speichern: In InfluxDB/TimescaleDB schreiben; das Beacon selbst haelt keinen Verlauf.
- Kalibrierungs-Offset: Gerätespezifische Kalibrierkonstanten serverseitig anwenden (jeder Sensor hat Bias).
8. Fallstricke
- I2C-Bus-Lockup: Ein Sensor, der einen Takt verpasst, kann SDA niedrig halten und den Bus einfrieren. Fuegen Sie bei jedem Wake eine Recovery-Sequenz hinzu (SCL 9× toggeln, STOP senden).
- Kaltstart-Offset: TMP117 braucht 15,5 ms Durchschnittskonvertierung; zu schnelles Abtasten liefert veraltete Daten. t_conv respektieren.
- Batteriespannung als Temperaturproxy: Viele Beacons melden V_batt, aber unter Last faellt die Spannung — Batterie nur nach Ruheperiode messen fuer Genauigkeit.
- RH-Kondensation: HDC2080 liest 100 % rF bei Kondensation; das Gateway sollte anhaltendes 100 % rF als Fehler markieren, nicht als gueltigen Wert.
- Werbekollision: Hinzufuegen eines Sensorrahmens verdoppelt die Airtime; bei hoher Beacon-Dichte steigt die Kollisionswahrscheinlichkeit (siehe Kollisionsartikel). Halten Sie den Sensorrahmen kurz und bei separatem Werbeintervall, wenn moeglich.
9. Design-Checkliste
- [ ] Sensoren waehlen, deren Strom in die Zelle passt (18-mA-CO2 an Knopfzelle vermeiden)
- [ ] Sekundaeren Werberahmen nutzen; Identitaetsrahmen fuer Position behalten
- [ ] Mit Fixed-Point + Bitmap packen; langsame Drift delta-kodieren
- [ ] Deadband + Hysterese setzen, um Chatter zu unterdruecken
- [ ] Schwelle/Wake-on-Motion vor festem schnellem Abtasten bevorzugen
- [ ] I2C-Bus-Recovery bei jedem Wake hinzufuegen
- [ ] MSD-Layout dokumentieren, damit Gateway es parsen kann
- [ ] Batteriemodell gegen gemessenen Schlafstrom pruefen, nicht Datenblatt-Typ
10. Fazit
Ein Sensor-Beacon ist ein Edge-Geraet, kein bloßer Sender. Der Engineering-Wert liegt in den on-device getroffenen Entscheidungen: wann abzutasten, wann zu schweigen und welche minimalen Bytes zu senden. Mit Fixed-Point-Packing, bitmap-getriebener Nutzlast, Deadband-Filterung und schwellenwertausgeloesten Buersten kann ein Knopfzellen-Beacon Jahre lang Umgebungszustand melden und spricht nur, wenn es wichtig ist.
Das Funkmodul war nie der Flaschenhals — Sensorsstrom und Abtastrate sind es. Gestalten Sie die Wake-Logik zuerst; der Werbekodierer ist der einfache Teil.
