IoT-Kommunikation für ein Gewächshaus planen

Wenn Messwerte ankommen, aber Warnungen zu spät sind

Die Hainbogen Jungpflanzen eG betreibt drei Gewächshäuser. In jedem Haus regelt eine lokale Steuerung Lüftung und Bewässerung. Temperatur- und Feuchtesensoren sind bereits elektrisch angeschlossen, kalibriert und in der Steuerung eingerichtet. Diese lokale Regelung funktioniert auch dann weiter, wenn das Datennetz ausfällt.

Nun soll ein zentraler Dienst die Klimadaten aller 24 Zonen darstellen. Die Betriebsleitung möchte außerdem gewarnt werden, wenn eine lokale Steuerung einen kritischen Zustand meldet. Ein Edge-Gateway sammelt die Daten der Steuerungen und verbindet die lokale Anlage mit dem zentralen Dienst.

Ein erster Prototyp sendet alle Daten mit einzelnen HTTP-Anfragen. Im Normalbetrieb wirkt das ausreichend. Bei einer unterbrochenen Verbindung stauen sich jedoch Anfragen. Nach dem Wiederanlauf treffen alte Warnungen zusammen mit neuen Messwerten ein. Einige Warnungen werden doppelt angezeigt, andere lassen sich keiner Zone sicher zuordnen.

Das Problem ist nicht einfach “MQTT oder HTTP?”. Zuerst brauchst du klare Anforderungen an den Informationsfluss. Erst danach kannst du Topologie, Nachrichtenmuster, Protokoll und Zustellverhalten passend auswählen.

Die Grundidee lautet: Eine Kommunikationsstrecke ist erst geplant, wenn jede wichtige Nachricht einen Zweck, einen Absender, einen Empfänger, eine Frist und ein definiertes Verhalten bei Fehlern hat.

Formuliere Anforderungen als prüfbare Aussagen

“Die Daten sollen schnell und sicher ankommen” klingt vernünftig, hilft bei einer technischen Entscheidung aber kaum. Weder “schnell” noch “sicher” ist damit messbar. Für Hainbogen werden deshalb fünf konkrete Nachrichtenarten und Betriebsfälle beschrieben.

Diese Zahlen sind Anforderungen des neu erstellten Übungsszenarios. Sie behaupten keine allgemeingültigen Grenzwerte für Gewächshäuser. In einem echten Auftrag würdest du sie mit Betrieb, Informationssicherheit und den Verantwortlichen für die Anlage abstimmen.

Aus den Anforderungen entstehen technische Fragen:

• Muss ein Sender den Empfänger direkt kennen?
• Wird eine Nachricht von genau einem oder von mehreren Diensten gebraucht?
• Reicht eine Bestätigung des Transports, oder braucht die Fachanwendung eine eigene Verarbeitungsbestätigung?
• Was darf verloren gehen, was darf doppelt eintreffen und was darf verspätet nicht mehr verarbeitet werden?
• Welche Funktion bleibt bei einem Ausfall lokal erhalten?

Zwei Nachrichtenmuster lösen unterschiedliche Probleme

Bei Request-Response sendet ein Client eine Anfrage an einen Server und erwartet eine dazugehörige Antwort. HTTP ist laut RFC 9110 eine Familie zustandsloser Request-Response-Protokolle. Eine Anfrage enthält unter anderem eine Methode und ein Ziel. Die Antwort enthält einen Statuscode. Dieses Muster passt gut, wenn das Gateway gezielt die aktuell freigegebene Konfiguration abruft und wissen muss, ob genau dieser Abruf erfolgreich war.

Bei Publish-Subscribe veröffentlicht ein Client eine Nachricht unter einem Thema. Andere Clients abonnieren passende Themen. Der veröffentlichende Client muss die einzelnen Empfänger nicht kennen. MQTT 5.0 beschreibt genau dieses Client-Server-Muster. Ein Broker nimmt Veröffentlichungen an und verteilt sie an passende Abonnements.

Für Hainbogen ist diese Entkopplung hilfreich. Das Gateway veröffentlicht ein Warnereignis einmal. Der Leitstand, das Archiv und ein später ergänzter Benachrichtigungsdienst können es unabhängig abonnieren. Das Gateway braucht dafür keine Liste dieser Anwendungen.

Die Grafik zeigt eine logische Topologie. Sie legt noch nicht fest, ob Broker und Konfigurationsdienst im eigenen Rechenzentrum oder bei einem externen Betreiber laufen. Diese Betriebsentscheidung braucht eine eigene Bewertung von Verfügbarkeit, Datenschutz, Wartbarkeit und Netzübergängen.

Entwirf Topics und Nutzdaten gemeinsam

Ein MQTT-Topic ordnet eine Nachricht in eine hierarchische Struktur ein. Die Segmente werden durch / getrennt. Für Hainbogen wird folgende Struktur festgelegt:

hainbogen/haus-2/zone-07/telemetrie
hainbogen/haus-2/zone-07/warnung
hainbogen/haus-2/gateway/status

Die Struktur geht vom stabilen betrieblichen Kontext zur Nachrichtenart. Ein Leitstand kann hainbogen/+/+/warnung abonnieren und damit Warnungen verschiedener Häuser und Zonen empfangen. Ein Archiv kann sich gezielt auf Telemetrie beschränken.

Topics sind sichtbar für die beteiligte Infrastruktur und werden häufig für Berechtigungen verwendet. Zugangsdaten, Personennamen und andere Geheimnisse gehören deshalb nicht in den Topic-Namen. Auch freie, ständig wechselnde Texte erschweren Regeln und Auswertung.

Das Topic allein reicht nicht. Die Nutzdaten müssen eine Nachricht eindeutig und zeitlich einordnen lassen:

{
  "schemaVersion": 1,
  "eventId": "haus-2-zone-07-18442",
  "observedAt": "2026-07-10T09:14:30+02:00",
  "sequence": 18442,
  "temperatureC": 31.8,
  "state": "warning"
}

observedAt bezeichnet den Messzeitpunkt an der Anlage. Das ist nicht dasselbe wie die Ankunftszeit im Dienst. eventId ermöglicht dem Empfänger, eine erneut zugestellte Nachricht zu erkennen. schemaVersion macht sichtbar, nach welchem Datenvertrag die Nutzlast interpretiert werden soll. Für das Szenario sind Kennung und Werte neu erstellt.

Eine gute Topic-Struktur und eine gute Nutzlast teilen sich die Aufgaben. Das Topic erleichtert Routing und Berechtigungen. Die Nutzlast trägt die fachlichen Daten, die eindeutige Ereigniskennung und den ursprünglichen Zeitpunkt.

Wähle QoS nach der tolerierbaren Fehlerwirkung

MQTT definiert drei Stufen für die Quality of Service, kurz QoS. Sie beschreiben die Zustellung einer Anwendungsnachricht zwischen einem einzelnen Sender und einem einzelnen Empfänger auf MQTT-Ebene.

Für die laufende Telemetrie reicht im Szenario QoS 0. Eine einzelne Lücke ist akzeptiert und der folgende Wert ersetzt sie nicht fachlich, macht den aktuellen Zustand aber wieder sichtbar. Warnungen werden mit QoS 1 veröffentlicht. Bei einer unterbrochenen Verbindung kann dieselbe Warnung erneut eintreffen. Der Leitstand verarbeitet sie deshalb idempotent: Dieselbe eventId erzeugt nicht zweimal denselben fachlichen Alarm.

QoS 2 wird oft als Garantie für den gesamten Geschäftsprozess missverstanden. Die OASIS-Spezifikation begrenzt die QoS-Aussage auf die Zustellung einer Anwendungsnachricht zwischen Sender und Empfänger. Ob der Leitstand die Nachricht dauerhaft speichert, eine Person erreicht oder eine Aktion ausführt, braucht eigene Bestätigungen und Tests.

Plane Identität, Verschlüsselung und Berechtigung getrennt

MQTT und HTTP beantworten nicht allein, wer kommunizieren darf. Für Hainbogen erhält jedes Gateway eine eindeutige technische Identität und eigene Zugangsdaten. Der Broker kann dadurch das Gateway gw-haus-2 von anderen Clients unterscheiden. Gemeinsam genutzte Zugangsdaten würden eine Sperrung, Zuordnung und Erneuerung unnötig erschweren.

Die Verbindungen zum Broker und zum Konfigurationsdienst werden verschlüsselt und die Gegenstelle wird geprüft. In der Planung steht daher nicht nur MQTT, sondern MQTT über eine geschützte Transportverbindung mit geprüfter Serveridentität. Für den Konfigurationsabruf wird HTTPS verwendet. Ob zusätzlich Client-Zertifikate, kurzlebige Token oder ein anderes Verfahren eingesetzt werden, entscheidet das Sicherheitskonzept der konkreten Umgebung.

Identität und Verschlüsselung ersetzen keine Berechtigung. Das Gateway aus Haus 2 darf nur in seinem eigenen Bereich veröffentlichen und seine eigene Konfiguration abrufen. Der Archivdienst darf Telemetrie lesen, aber keine Warnungen oder Konfigurationen schreiben. NIST IR 8259A nennt Geräteidentifikation, Schutz gespeicherter und übertragener Daten sowie den begrenzten logischen Zugriff auf Schnittstellen als Kernfähigkeiten für IoT-Geräte. Die genaue Umsetzung wird aus dem Schutzbedarf abgeleitet.

Entwirf den Offline-Betrieb vor dem Wiederanlauf

Ein Netzausfall darf die lokale Klimaregelung nicht stoppen. Diese Entscheidung liegt bereits in der Systemarchitektur: Die Steuerungen arbeiten lokal weiter. Das Gateway puffert Messwerte mit eventId, Sequenznummer und ursprünglichem Messzeitpunkt. Warnungen bleiben ebenfalls erhalten, bis sie übertragen oder nach einer festgelegten fachlichen Regel verworfen wurden.

Für 24 Zonen entsteht alle 30 Sekunden ein Datensatz. Pro Stunde sind das je Zone 120 Datensätze. Für den geforderten Puffer von 12 Stunden ergibt sich:

24 Zonen × 120 Datensätze pro Stunde × 12 Stunden = 34 560 Datensätze

Diese Anzahl ist erst der Anfang einer Speicherplanung. Zusätzlich brauchst du die reale Datensatzgröße, Dateisystem- oder Datenbank-Overhead, Reserven und ein Verhalten bei vollem Speicher.

Beim Wiederanlauf sendet das Gateway nicht einfach “alles so schnell wie möglich”. Alte Daten könnten neue Warnungen verzögern. Der Entwurf legt deshalb eine Reihenfolge fest:

1. Verbindung und Identität prüfen.
2. Aktuellen Gerätestatus und offene Warnungen übertragen.
3. Laufende neue Messwerte weiterleiten.
4. Gepufferte Telemetrie mit begrenzter Rate nachliefern.
5. Erst nach bestätigter Übertragung erfolgreich übermittelte Puffereinträge löschen.

Der ursprüngliche Zeitstempel bleibt erhalten. Der Dienst kann dadurch einen nachgelieferten Messwert von einem aktuellen Wert unterscheiden. Für Warnungen braucht es zusätzlich eine fachliche Gültigkeitsregel. Eine zehn Stunden alte Warnung darf nicht still als aktueller Zustand erscheinen. Sie kann aber für Verlauf und Nachweis weiterhin relevant sein.

Mache aus Erwartungen einen Testplan

Ein Testfall verbindet Ausgangslage, Handlung, erwartbares Ergebnis und Messpunkt. “Kommunikation testen” ist dafür zu breit. Hainbogen plant mindestens diese Fälle:

Die Schwelle “mindestens 19 von 20” gilt nur für die QoS-0-Telemetrie dieses Übungsszenarios. Für die Warnung fordert das Szenario eine andere Wirkung. Genau deshalb reicht ein gemeinsamer Test “Nachrichten kommen an” nicht.

Ein Ende-zu-Ende-Test beobachtet nicht nur den Broker. Er beginnt bei einer definierten Nachricht am Gateway und endet bei der fachlichen Wirkung im Zielsystem. Bei der Warnung ist das der sichtbare, nur einmal angelegte Alarm. Eine MQTT-Bestätigung ist ein wichtiger Zwischenbefund, aber nicht das Ende des Tests.

Übertrage den Entwurf auf ein neues Szenario

Was du aus dem Kommunikationsentwurf mitnimmst

Du hast die Protokollwahl nicht mit einem Produktnamen begonnen, sondern mit der fachlichen Wirkung einer Nachricht.

• Request-Response passt zu einer gezielten Anfrage mit zugehöriger Antwort.
• Publish-Subscribe entkoppelt Sender und Empfänger und verteilt Ereignisse an mehrere Abonnenten.
• Topic, Nutzdaten und Berechtigung werden gemeinsam geplant.
• MQTT-QoS beschreibt eine Zustellzusage auf Protokollebene, nicht automatisch den Erfolg des gesamten Arbeitsablaufs.
• Eindeutige Ereigniskennungen machen mögliche Duplikate beherrschbar.
• Identität, verschlüsselte Übertragung und minimale Rechte lösen unterschiedliche Sicherheitsaufgaben.
• Offline-Puffer brauchen Kapazität, Reihenfolge, Zeitstempel und eine Grenze für alte Nachrichten.
• Ein Test endet an der fachlichen Wirkung, nicht an einer einzelnen Transportbestätigung.

Die Lektion grenzt sich bewusst von der direkten Sensor- und Aktor-Integration ab. Sie legt auch keine allgemeine Funktechnik fest. Reichweite, Energiebedarf, Störumgebung und verfügbare Infrastruktur würden in einem eigenen Auswahlprozess für das Übertragungssystem bewertet. Hier stand die Kommunikation zwischen bereits angebundener lokaler Steuerung, Gateway und Diensten im Mittelpunkt.

Belegmatrix