Wenn ein Türkontakt, ein Vibrationssensor oder ein Füllstandssensor minütlich „nach Hause telefoniert“, entsteht schnell ein Muster: viele kleine Requests, wenig Informationsgehalt, unnötige Funkzeit und unnötige Cloud-Kosten. Gleichzeitig werden echte Ereignisse (z.B. „Motor schwingt plötzlich stärker“) im schlimmsten Fall erst beim nächsten Polling-Intervall sichtbar. Eine Event-Driven Architecture dreht das Prinzip um: Nicht die Plattform fragt ab, sondern das Gerät oder ein Gateway sendet nur dann, wenn sich etwas Relevantes ändert.
Im Internet of Things ist das besonders wertvoll, weil viele Endpunkte energiebegrenzt sind, Funkverbindungen schwanken und Latenz oft geschäftskritisch ist (z.B. Alarmketten, Abschaltungen, Prozessüberwachung). Entscheidend ist dabei nicht nur das Protokoll, sondern die saubere Modellierung von Ereignissen, Zuständen und Kommandos.
Warum Polling im IoT häufig zum Problem wird
Funkzeit, Batterie und Skalierung hängen zusammen
Polling verursacht regelmäßig Übertragungen, auch wenn sich nichts geändert hat. Bei batteriebetriebenen Knoten bedeutet jede Funkaktivität Energieverbrauch: Aufwachen, Senden, ggf. erneutes Senden bei Kollisionen oder schlechtem Empfang. Dazu kommen Effekte in der Zentrale: Viele Geräte erzeugen gleichförmigen Traffic, der bei hoher Gerätezahl nicht linear „mitwächst“, sondern Lastspitzen erzeugt (z.B. zur vollen Minute).
Polling versteckt echte Ereignisse hinter Intervallen
Ein Intervall von 60 Sekunden wirkt harmlos, ist aber für viele Szenarien zu lang: Leckage-Erkennung, Tür-/Fensterzustände, Produktionsstillstände oder Sicherheitsalarme. Kürzere Intervalle verbessern Reaktionszeiten, erhöhen aber Traffic und Energieverbrauch. Events umgehen dieses Dilemma, weil sie „bei Bedarf“ gesendet werden.
Welche Bausteine eine ereignisgetriebene IoT-Architektur braucht
Event-Quelle, Transport, Verarbeitung, Aktion
Technisch lässt sich der Datenfluss in vier Ebenen aufteilen: (1) Sensor/Aktor als Event-Quelle, (2) Transport über ein Protokoll und Netz, (3) Verarbeitung (z.B. Regeln, Persistenz, Analytics) und (4) Aktion (z.B. Benachrichtigung, Aktor schalten, Ticket erstellen). Die Architektur bleibt robust, wenn jede Ebene klar abgegrenzt ist und nicht „alles in einem Script“ passiert.
Zustand vs. Ereignis vs. Kommando sauber trennen
Ein häufiges Missverständnis: Ein Ereignis ist kein Zustand. „Temperatur = 22,1°C“ ist zunächst eine Messung (Zustandsinformation), „Temperatur hat Schwellwert überschritten“ ist ein Ereignis. Ein Kommando ist wiederum etwas anderes: „Ventil schließen“. Werden diese drei Konzepte vermischt, entstehen schwer zu debuggende Loops (z.B. Plattform sendet Kommando, Gerät meldet „Event“, Plattform interpretiert das als neuen Auslöser).
Wo Edge sinnvoll ist: Gateway als Event-Filter
Viele Sensoren liefern Rohdaten mit Rauschen. Ein Gateway oder ein Edge-Knoten kann daraus stabile Ereignisse machen (z.B. Debouncing, Hysterese, Zeitfenster). Das reduziert Cloud-Last und vermeidet Fehlalarme. Für praxisnahe Strategien zur lokalen Verarbeitung lohnt ein Blick auf Edge Computing im IoT.
Wie IoT-Events modelliert werden: Topic-Design, Payload, Versionierung
Topics hierarchisch und lesbar gestalten
Bei pub/sub-Systemen sind Topics das Rückgrat. Bewährt hat sich eine Hierarchie nach Standort/Anlage, Gerät, Subsystem und Signal, z.B. „werk-1/linie-3/motor-7/vibration/event“. Wichtig: keine „Datenhalden-Topics“, in die alles geschrieben wird. Gute Topics erleichtern Rechtevergabe, Routing und Fehlersuche.
Payload: klein, eindeutig, maschinenlesbar
Payloads sollten Felder enthalten, die für Verarbeitung und Debugging nötig sind: Zeitstempel (falls vorhanden), Event-Typ, Messwert oder Ursache, ggf. Qualitätsindikator. Für Low-Power-Funk sind kompakte Formate sinnvoll; in IP-Netzen ist JSON verbreitet, solange es nicht unnötig aufgebläht wird. Zentral ist eine stabile Feldbedeutung über die Zeit, sonst brechen Regeln und Dashboards.
Schema-Versionen vermeiden „stille“ Breaking Changes
Ändert sich ein Feldname oder eine Einheit, muss das als Version oder neuer Event-Typ sichtbar werden. Sonst wirken Systeme zwar „online“, liefern aber semantisch falsche Daten. Ein pragmatischer Ansatz: Event-Typen versionieren (z.B. „vibration_alert_v2“) oder eine „schema_version“ im Payload führen und Consumer schrittweise migrieren.
Protokolle und Zustellgarantien: wann welches Muster passt
Publish/Subscribe für Events, Request/Response für Abfragen
Events profitieren von Publish/Subscribe, weil mehrere Consumer parallel reagieren können (Alarmierung, Logging, Wartungssystem). Abfragen wie „Gib aktuellen Konfigurationsstand“ oder „Liefere letzten Zustand“ passen besser zu Request/Response. In der Praxis existieren beide Muster nebeneinander: Events für Änderungen, zusätzliche Abfragen für „Cold Start“ nach Neustart.
MQTT: QoS bewusst wählen
MQTT bietet Quality-of-Service-Stufen, die zwischen „best effort“ und bestätigter Zustellung liegen. Für Telemetrie, die regelmäßig kommt, ist ein Verlust tolerierbar; für Alarme oder Zustandswechsel kann bestätigte Zustellung wichtig sein. Zu hohe QoS-Level für alles erhöhen jedoch Latenz, Speicherbedarf und Funkzeit. Entscheidend ist, je Event-Typ eine passende Zuverlässigkeit zu definieren.
Idempotenz: gleiche Events dürfen nicht „doppelt wirken“
In realen Netzen kommt es vor, dass Events erneut gesendet werden (z.B. Reconnect, Retries). Consumer sollten so gebaut sein, dass ein Event bei Wiederholung keinen Schaden anrichtet. Typische Mittel: Event-IDs, Sequenznummern oder das Ableiten eines „Zielzustands“ statt „tu X zweimal“.
Umsetzungsbeispiel: vom Sensor-Event zur Aktor-Aktion
Bewegungserkennung mit Entprellung und Hysterese
Ein PIR- oder Radarsensor kann kurze Impulse liefern. Statt jede Flanke als Event zu schicken, erzeugt die Firmware (oder ein Gateway) ein robustes Ereignis: „motion_started“ und „motion_ended“ mit Mindestdauer. Das reduziert Chatty-Traffic und verbessert die Logik in nachgelagerten Systemen.
Aktorik über Kommandokanäle getrennt führen
Für Aktoren (Relais, Ventile, Dimmer) ist eine Trennung sinnvoll: ein Topic für Kommandos und ein Topic für Status/Events. Das Gerät bestätigt den neuen Zustand als Event („state_changed“), nicht als Echo des Kommandos. So bleibt nachvollziehbar, ob die Aktion wirklich ausgeführt wurde (z.B. bei blockiertem Ventil).
Alarmketten nicht „hart verdrahten“
Ein Alarm-Event sollte mehrere Empfänger bedienen können, ohne dass das Gerät diese kennt. Ein Consumer kann Benachrichtigungen auslösen, ein anderer schreibt in ein Ticketsystem, ein dritter triggert ein Dashboard. Das hält die Gerätefirmware schlank und reduziert Updatebedarf auf der Device-Seite.
Schritte, die in der Praxis sofort Stabilität bringen
- Ereignisse definieren: Welche Zustandswechsel sind wirklich relevant (z.B. Grenzwert über/unter, Fehlercode, Ausfall, Manipulation)?
- Topic- und Namenskonzept festlegen, bevor viele Geräte live gehen; Schreibweisen (Bindestriche, IDs, Standortlogik) konsequent halten.
- Pro Event-Typ Zustellniveau, Retain-Strategie und Wiederholungslogik bestimmen (Retries, Backoff, Duplikate).
- Consumer idempotent bauen: Events müssen bei Wiederholung ohne Nebenwirkungen verarbeitet werden.
- Geräte- und Gateway-Logs so planen, dass Event-IDs, Reconnects und Pufferzustände sichtbar sind.
Fehlerbilder im Betrieb und wie sie vermieden werden
„Event-Stürme“ durch schlecht gesetzte Schwellwerte
Wenn ein Grenzwert ohne Hysterese verwendet wird, pendelt ein Messwert um die Schwelle und erzeugt viele Events. Lösung: Hysterese, Mindestzeit über/unter Schwellwert, oder Aggregation (z.B. nur ein Event pro 5 Minuten). Das ist besonders bei Temperatur, Feuchte und Vibration relevant.
Offline-Phasen: Puffern statt Verlieren
Geräte in Kellern, Schächten oder mobilen Anwendungen verlieren zeitweise die Verbindung. Dann entscheidet die Strategie: Events puffern (mit Speichergrenzen und Prioritäten) oder verwerfen (mit „offline“-Event und späterer Zustands-Synchronisation). Für robuste Muster bei Unterbrechungen hilft der Ansatz aus offline-tauglichen Sensor-Deployments.
Sicherheit: Event-Kanäle sind produktive Angriffsflächen
Wenn Events Aktionen auslösen, sind Manipulation und Spoofing besonders kritisch. Notwendig sind eindeutige Geräteidentitäten, saubere Rechte (wer darf publizieren/abonnieren), sowie Schutz der Transportverbindung. Für praktische Maßnahmen rund um Schlüssel, Boot-Kette und sichere Updates passt der Einstieg über IoT im Betrieb absichern.
Vergleich: Ereignisse vs. Polling in typischen IoT-Szenarien
| Aspekt | Ereignisgetrieben | Polling |
|---|---|---|
| Funk- und Datenvolumen | Niedrig bei seltenen Änderungen; skaliert gut | Stetig hoch, auch ohne Änderungen |
| Latenz bei echten Vorfällen | Typisch niedrig, da sofort gesendet | Abhängig vom Intervall |
| Komplexität in Consumer-Logik | Höher: Duplikate, Reihenfolge, Zustandsaufbau | Niedriger: „aktuellen Wert“ abfragen |
| Energieverbrauch am Gerät | Gut steuerbar durch seltene Sendungen | Abhängig vom Intervall; oft ungünstig |
| Debugging | Erfordert Event-IDs und gute Telemetrie | Einfacher Start, später oft unübersichtlich |
Wann Polling trotzdem sinnvoll bleibt
Kaltstart, Re-Sync und Zustandsaufbau
Nach Neustarts (Gerät, Broker, Consumer) fehlt oft Kontext. Dann helfen einmalige Abfragen oder „State Snapshots“, um einen definierten Ausgangspunkt zu haben. Ein bewährtes Muster: Events liefern Änderungen, zusätzlich gibt es einen aktuellen Zustand (z.B. als „reported state“), der beim Start gelesen wird.
Geräte, die keine Events liefern können
Bei einfachen Embedded-Systemen oder bestimmten Industriekomponenten lässt sich Eventing nicht immer realisieren. Dann kann ein Gateway polling-basiert lesen und daraus Events generieren. So bleibt die Architektur nach außen ereignisgetrieben, ohne die Altkomponente zu überfordern.
Regulatorische oder betriebliche Nachweispflichten
Manche Anwendungen benötigen regelmäßige Lebenszeichen oder periodische Messpunkte (z.B. zur Nachvollziehbarkeit). Auch hier lässt sich kombinieren: Heartbeats als seltenes, planbares Signal plus Events für Abweichungen.
Wer Events konsequent denkt, baut vernetzte Geräte nicht nur „reaktiver“, sondern auch betriebssicherer: weniger unnötige Übertragungen, klarere Datenflüsse und eine saubere Trennung von Messung, Ereignis und Aktion. Wichtig ist, die Semantik früh festzulegen und den Betrieb (Duplikate, Offline, Sicherheit) von Anfang an mitzudenken.
Quellen
- IETF: MQTT Version 5.0 Specification
- IETF: The Constrained Application Protocol (CoAP)
