Ein Temperaturfühler sendet jede Minute einen Messwert. Gleichzeitig meldet ein Gerät „Batterie schwach“ und der Betreiber möchte jederzeit den aktuellen Online-Status sehen. In vielen IoT-Projekten werden diese drei Dinge in einen Topf geworfen – und später wundert sich das Team über unklare Dashboards, widersprüchliche Auswertungen oder Integrationen, die bei Last zusammenbrechen.
Saubere IoT-Systeme trennen drei Datenarten konsequent: kontinuierliche Messreihen, seltene Ereignisse und den jeweils aktuellen Zustand. Das klingt theoretisch, ist aber eine der praktischsten Stellschrauben für Datenqualität, Kosten und Wartbarkeit.
Warum unterscheiden: Messwerte sind keine Alarme
Typische Symptome eines vermischten Datenmodells
Ein häufiges Muster: Das Gerät veröffentlicht „temperature=23.1“, „alarm=true“ und „online=true“ als gleichartige Nachrichten. In der Datenbank liegen dann gemischte Datensätze, und jede Abfrage muss per Filterlogik erraten, was eigentlich gemeint ist. Das führt in der Praxis zu drei Problemen:
- Auswertungen werden unzuverlässig: Ein Alarm taucht in Trenddiagrammen auf oder wird von Aggregationen verschluckt.
- Integrationen werden fragil: Ein ERP-System erwartet Ereignisse, bekommt aber Messreihen – oder umgekehrt.
- Betrieb wird teuer: Zustandsänderungen werden wie Telemetrie im Sekundentakt gespeichert, obwohl nur „letzter Stand“ benötigt wird.
Die Trennung ist weniger eine „Datenbank-Frage“ als eine Semantik-Frage: Was bedeutet diese Information, wie lange ist sie gültig, und wie soll sie verarbeitet werden?
Telemetrie, Ereignisse und Zustände: klare Definitionen
Telemetrie: Zeitreihe mit Messkontext
IoT-Telemetrie beschreibt Messwerte, die typischerweise in regelmäßigen Abständen oder bei relevanter Änderung gesendet werden. Telemetrie ist historisch interessant (Trend, Nachweis, Optimierung) und wird daher oft als Zeitreihe gespeichert. Wichtig sind immer: Zeitstempel, Einheit, Messort/Sensor-ID und optional Qualitätsmerkmale (z. B. „estimated“, „calibrated“, „outlier“).
Beispiele: Temperatur, Vibration, Durchfluss, Luftfeuchte, Energieverbrauch, Füllstand.
Ereignisse: selten, diskret, handlungsorientiert
Event-Driven Architecture passt hier inhaltlich perfekt: Ein Ereignis ist etwas, das „passiert“ und eine Reaktion auslösen kann. Ereignisse sind diskrete Datensätze mit eindeutiger Bedeutung, oft mit Schweregrad, Ursache, Kontext und Referenzen. Sie sind nicht dafür gedacht, als Kurve geplottet zu werden.
Beispiele: Tür geöffnet, Grenzwert überschritten, Sensorfehler erkannt, Wartung fällig, Firmware-Update abgeschlossen.
Praxis-Tipp: Ein Ereignis sollte ohne zusätzliche Datenbank-Abfragen verständlich sein. Kontext (z. B. welcher Grenzwert, welcher Sensor, welcher Betriebsmodus) gehört direkt in den Event-Payload.
Zustände: „aktueller Stand“ mit definierter Gültigkeit
Digital Twins und Gerätestatus-Funktionen drehen sich um Zustände: „Das Gerät ist online“, „Ventil steht auf 35%“, „Batterie ist bei 62%“, „letzter Kontakt vor 2 Minuten“. Zustände werden überschrieben und repräsentieren den letzten bekannten Stand. Historie ist optional und sollte bewusst geplant werden (z. B. nur Zustandswechsel oder stündliche Snapshots).
Beispiele: Online/Offline, Konfigurationsversion, letzter Fehlercode, aktueller Betriebsmodus, Sollwert, Setpoint, aktueller Standort (als letzter bekannter Punkt).
Entscheidungshilfe für die Modellwahl im Alltag
Drei Fragen, die fast immer reichen
- Soll eine Zeitreihe entstehen? Wenn Ja: Telemetrie. Wenn Nein: weiter prüfen.
- Soll eine Reaktion ausgelöst werden? Wenn Ja: Ereignis (auch wenn zusätzlich Telemetrie existiert).
- Ist nur der aktuelle Stand relevant? Wenn Ja: Zustand (ggf. mit Historie der Änderungen).
Wichtig: Ein und dieselbe „Sache“ kann in mehreren Formen vorkommen. Beispiel Temperatur: Telemetrie als Messreihe, zusätzlich Ereignis „Grenzwert überschritten“, zusätzlich Zustand „temperature_last=23.1“ als schnelle Abfrage für Dashboards.
Payload-Design: Feldnamen, Einheiten, Versionierung
Stabile Schemas schlagen „freie JSON-Felder“
Ein robustes Datenmodell setzt auf klar benannte Felder und konsequente Einheiten. Gerade im Betrieb zeigt sich: spontane Felder („temp“, „t“, „temperatureC“) erzeugen später Migrationskosten. Sinnvoll ist ein kleines, versioniertes Schema je Datentyp, z. B.:
- Telemetrie: sensor_id, ts, value, unit, quality
- Ereignis: event_id, ts, type, severity, message, context
- Zustand: device_id, ts, state (Objekt), source, ttl
Versionierung muss nicht kompliziert sein. Ein Feld wie „schema_version“ oder ein „type“-Namensraum (z. B. „device.battery.low.v1“) reicht häufig aus, um Änderungen kontrolliert einzuführen.
Einheiten und Normalisierung früh festlegen
In der Praxis entstehen Fehler weniger durch Protokolle als durch Einheitenmix: °C vs. K, kW vs. W, Prozent vs. 0..1. Telemetrie sollte Einheiten entweder immer mitsenden oder eindeutig pro Sensorprofil festlegen. Bei Integrationen ist eine Normalisierungsschicht hilfreich, damit nachgelagerte Systeme konsistent bleiben.
Wer Messwerte aus verschiedenen Quellen zusammenführt, profitiert von sauberer Normalisierung. Dazu passt der Artikel IoT-Messdaten normalisieren – saubere Werte statt Datenchaos.
Speicher- und API-Design: was wohin gehört
Zeitreihen anders behandeln als Zustände
Telemetrie wird häufig aggregiert (Min/Max/Avg) und über Zeitfenster abgefragt. Zustände werden eher als „Get current state“ benötigt. Wird beides gleich gespeichert, leidet entweder die Abfragegeschwindigkeit oder der Speicherverbrauch.
Ein pragmatisches Muster:
- Telemetrie in einer Zeitreihenablage (oder zumindest zeitbasiert partitioniert), mit Retention-Strategie.
- Zustände in einer Key-Value-/Dokumentstruktur (letzter Stand pro Gerät), optional mit Change-Log.
- Ereignisse in einer Event-Tabelle oder einem Event-Stream, filterbar nach Typ, Zeit, Gerät, Schweregrad.
Wird eine IoT-Plattform angebunden, sollten API-Endpunkte das ebenfalls spiegeln: /telemetry für Zeitreihen, /events für diskrete Ereignisse, /state für aktuellen Stand. Das reduziert Interpretationsspielräume und erleichtert Rechtekonzepte (z. B. Leserechte für Zustand, restriktivere Rechte für Events).
Offline, Pufferung und Nachlieferung richtig abbilden
Im Feld entstehen Lücken: Funk weg, Gateway rebootet, Sensor im Energiesparmodus. Telemetrie kann nachgeliefert werden, Ereignisse hingegen müssen klar kennzeichnen, ob sie verzögert eintreffen. Zustände sind besonders heikel: Ein nachgelieferter alter Zustand darf den aktuellen Stand nicht überschreiben.
Das lässt sich durch zwei einfache Regeln entschärfen:
- Zustand nur aktualisieren, wenn der neue Zeitstempel „frischer“ ist als der gespeicherte.
- Ereignisse immer append-only speichern und „ingestion_ts“ getrennt vom „event_ts“ führen.
Für Puffer-Strategien im Feld ist IoT-Daten puffern: Offline-taugliche Sensor-Deployments eine passende Ergänzung.
Kommunikation und Topics: Struktur statt Wildwuchs
Topics und Routen nach Datentyp trennen
Unabhängig davon, ob MQTT, HTTP oder ein proprietärer Kanal genutzt wird: Die Trennung sollte sich in der Routing-Logik widerspiegeln. Bei MQTT bietet es sich an, Topic-Strukturen pro Datentyp zu definieren, etwa:
- telemetry/{device_id}/{sensor}
- events/{device_id}/{event_type}
- state/{device_id}
Das bringt zwei Vorteile: Consumer können gezielt abonnieren, und Retention/Expiry-Regeln lassen sich passend anwenden (Zustand kann retained sein, Telemetrie eher nicht). Für robuste MQTT-Muster lohnt ein Blick auf IoT-Nachrichten robust machen – QoS, Retain, LWT verstehen.
Idempotenz und Deduplikation einplanen
Im IoT sind doppelte Nachrichten normal: Retries, QoS, Gateway-Reconnect. Ereignisse sollten daher eine eindeutige event_id tragen, Telemetrie idealerweise eine Kombination aus sensor_id und ts. Zustände sind ohnehin „last write wins“ – aber nur, wenn die Zeitlogik stimmt.
Mini-Praxisbeispiel: Pumpenüberwachung mit klarer Semantik
Welche Daten fallen an?
Eine Pumpe in einer Anlage wird nachgerüstet: Stromaufnahme, Vibration, Temperatur am Lager, plus ein Relaiskontakt „Störung“. Zusätzlich soll ein Leitstand wissen, ob das Gerät erreichbar ist.
- Telemetrie: Strom (A), Vibration (mm/s), Lagertemperatur (°C) in einem sinnvollen Intervall.
- Ereignisse: „Störung erkannt“, „Vibration über Grenzwert“, „Sensorfehler“.
- Zustände: online/offline, letzter Messzeitpunkt, aktuelle Firmware-Version, letzter Fehlercode.
Das Dashboard greift primär auf Zustände zu (schnell, aktuell). Für Analysen und Predictive-Maintenance-Ansätze wird Telemetrie historisch ausgewertet. Der Alarm-Workflow hängt an Ereignissen und eskaliert nur, wenn ein Event eintrifft – nicht, weil ein Messwert zufällig hoch ist.
Kurze Umsetzungsschritte für bestehende Systeme
- Inventar anlegen: Welche Payloads existieren aktuell, und welche enthalten gemischte Bedeutungen?
- Pro Payload entscheiden: Telemetrie, Ereignis oder Zustand (bei Mischformen aufteilen).
- Topic-/Endpoint-Struktur nach Datentyp einführen und Consumer schrittweise migrieren.
- Für Zustände Regeln definieren: Zeitstempel-Vergleich, TTL (Gültigkeitsdauer) und optional retained Verhalten.
- Für Ereignisse eindeutige IDs und Schweregrade festlegen, damit Deduplikation und Eskalation funktionieren.
- Schema-Versionierung ergänzen, bevor neue Felder ausgerollt werden.
Häufige Stolperfallen aus Integration und Betrieb
„Online“ als Telemetrie zu speichern
Online/Offline ist ein Zustand. Wird er als Telemetrie behandelt, entstehen unnötige Datenmengen und widersprüchliche Anzeigen („online“ in der Vergangenheit). Besser: Zustand mit Zeitstempel und klarer Ableitung, z. B. aus Heartbeat oder letztem Kontakt.
Grenzwertverletzung nur als Flag im Messwert
Ein Boolean „alarm=true“ im Telemetrie-Datensatz ist schwer zu betreiben: Er kann wieder verschwinden, wird aggregiert, und die Auslösezeit ist unklar. Sauberer ist ein Ereignis „threshold_exceeded“ mit Details (Grenzwert, Messwert, Dauer) plus optional ein Zustand „alarm_active“ für den aktuellen Stand.
Gerätekonfiguration ohne Zustandsmodell
Konfigurationsparameter (Samplingrate, Kalibrierfaktoren, Grenzwerte) sind Zustände. Ohne definierte „desired“ (gewünscht) und „reported“ (gemeldet) Werte entsteht Drift: Die Plattform glaubt, das Gerät sei umgestellt, das Gerät läuft aber mit alter Konfiguration. Ein Zustandsmodell, das beide Seiten abbildet, reduziert Tickets und Fehlersuche im Feld deutlich.
Zu späte Abgrenzung zwischen Gerät und Standort
Geräte werden umgebaut, Sensoren werden getauscht, Standorte wechseln. Telemetrie sollte an eine stabile Identität gebunden sein (device_id und sensor_id), während Standort und Asset-Zuordnung als Metadaten geführt werden. Das verhindert, dass Historie „wandert“ oder bei Tausch unbrauchbar wird.
Wie sich das sauber in eine Gesamtarchitektur einfügt
Von der Ingestion bis zur API denken
Die Trennung der Datenarten hilft nicht nur im Payload, sondern entlang der gesamten Kette: Ingestion-Routen, Storage, Indizes, Retention, API-Design und Rollenmodelle. Wer eine Plattform oder ein eigenes Backend plant, sollte diese Semantik früh verankern. Dazu passt IoT-Backend-Architektur – Ingestion, Storage, APIs sauber planen.
Edge als Vorfilter, nicht als Bedeutungs-Mixer
Edge Computing eignet sich hervorragend, um Telemetrie zu verdichten (z. B. Mittelwert, RMS, Peaks) und Ereignisse lokal zu erkennen (z. B. Schwellen, einfache Regeln). Entscheidend ist, dass die semantische Trennung erhalten bleibt: Verdichtete Telemetrie bleibt Telemetrie; ein erkannter Zustand bleibt Zustand; ein Alarm bleibt Ereignis. Damit werden Cloud-Kosten gesenkt, ohne die Nachvollziehbarkeit zu verlieren.
