Ein BLE-Tag ist nicht nur ein Ortungsgerät — baue einen Sensor darauf und es wird ein Funk-Sensor-Knoten, der Temperatur, Feuchte, Bewegung oder Licht ohne Verkabelung meldet. Dieser Artikel beschreibt, wie man Sensorwerte eines Tags sampelt, speichert und meldet, ohne die Knopfzelle zu leeren.

Was man am Tag sensen kann

  • Temperatur / Feuchte (SHTxx-Klasse, ~1–5 µA beim Lesen, sonst Schlaf)
  • Druck (Barometer für Höhe)
  • 3-Achsen-Beschleunigung (Bewegung / Sturz / Schock)
  • Umgebungslicht, magnetisch, Gas

Jeder Sensor addiert eine *Leseenergie* plus die *Funkerenergie* zum Senden des Werts.

Abtastrate

Einen Sensor jede Sekunde zu lesen wirkt sicher, zehrt aber die Batterie. Richte die Rate am Zweck aus:

  • Cold-Chain-Temperatur: alle 5–15 min loggen, Alarm bei Schwellwert.
  • Bewegungs-/Tür-Ereignisse: ereignisgesteuert, sonst schlafen.
  • Umgebungstrend: 1–10 min reicht.

Lokale Speicherung

Ein Tag kann nicht ständig uplinken, also puffert lokal. Ein Ringpuffer (FIFO) der letzten N Samples übersteht eine verpasste Verbindung; beim nächsten Kontakt zieht der Gateway den Backlog. 32–256 Samples sind typisch.

Report-Strategien

  • Periodisch: sende alle T egal was. Einfach, vorhersehbar, verschwendet bei Stillstand.
  • Ereignisgesteuert: sende nur bei Schwellwertüberschreitung oder Bewegung. Beste Batterie.
  • Delta-Report: speichere Deltas; sende volle Sample nur gelegentlich zum Resync.

Datenkompression

float32 × N in einem 32-Sample-Puffer ist verschwenderisch. Nutze:

  • Delta-Kodierung: `d_i = sample_i − sample_{i-1}` (kleine Integers).
  • Skaliere auf int8/int16 mit bekanntem Offset & Gain.
  • Bit-packe mehrere Kanäle.

Ein 16-Sample-float32-Temp-Log (64 B) wird zu ~16–20 B.

Leistungsmathematik

Pro Report-Zyklus: Sensorlesen ~5 µA·2 ms + Funk-TX ~8 mA·20 ms + MCU ~3 mA·50 ms.

Für einen Tag, der Temp alle 10 min liest und stündlich per BLE meldet:

  • Lesen: 5 µA × 2 ms × 6 = 60 nAh/Zyklus
  • TX: 8 mA × 20 ms = 44 nAh
  • Summe ≈ 100 nAh/Zyklus × 24 = 2,4 µAh/Tag → eine CR2032 (225 mAh) hält >20 Jahre auf dem Papier (Realität: Selbstentladung und Deep-Sleep-Leckage dominieren, ~2–5 Jahre).

Report über BLE

Zwei Wege:

1. Verbundenes GATT-Notify: Tag verbindet, sendet Sensor Notify, trennt. Maximale Flexibilität, maximale Energie.

2. Periodic Advertising with Responses (PAwR): Tag sendet Sensordaten in periodischen Slots; Gateway antwortet. Minimale Energie für viele Tags.

Gateway-Ingest

Dasselbe Pipeline wie ein Beacon: Gateway hört Advertisement/Notify, dedupliziert + Zeitstempel + aggregiert, weiter per MQTT. Der Tag muss für die meisten Reports nur *gehört*, nicht verbunden werden.

Anwendungsfälle

  • Cold-Chain (Pharma/Lebensmittel): Temp + Tür-Offen-Ereignisse.
  • Anlagenzustand: Vibration vor Ausfall.
  • Umgebung: Feuchte in Lagern, Licht in Büros.

Checkliste

  • [ ] Rate am Anwendungsfall ausgerichtet, nicht „jede Sekunde“
  • [ ] Ringpuffer für verpasste Verbindungen
  • [ ] Wo möglich ereignisgesteuert
  • [ ] Delta- + int-Skalierungskompression
  • [ ] PAwR oder kurze verbundene Fenster
  • [ ] Dedupe + Zeitstempel im Gateway
  • [ ] Batteriemodell inkl. Selbstentladung

Dieses Gleichgewicht ist das ganze Spiel des BLE-Tag.