Kurz erklärt
Ein MQTT-Gateway benötigt eine ausdrückliche Entscheidung darüber, welche Daten bei einem Ausfall erhalten bleiben müssen. Messwertverlauf, aktueller Zustand und Steuerauftrag haben unterschiedliche Anforderungen. Eine erfolgreiche Wiederverbindung allein bestätigt nicht, dass die Anwendung danach korrekt weiterarbeitet.
Daten nach Bedeutung trennen
Entscheiden Sie je Nachrichtentyp, ob der neueste Zustand genügt oder ein Verlauf vollständig gebraucht wird. Legen Sie außerdem fest, wann eine Information veraltet ist. Ein alter Messwert kann für eine Historie nützlich und für eine aktuelle Anzeige ungeeignet sein.
Vergeben Sie eine Gerätekennung und eine nachvollziehbare Ereigniskennung. Dokumentieren Sie, ob der Zeitstempel die Messung oder die Übertragung bezeichnet. Falls die Uhr nach einem Neustart noch nicht verlässlich ist, sollte diese Unsicherheit erkennbar bleiben.
Protokollfunktionen nicht mit einem Anwendungspuffer verwechseln
MQTT 5 unterscheidet die Lebensdauer einer Sitzung von der einer Nachricht. Diese Protokolloptionen ersetzen keinen automatisch persistenten lokalen Anwendungsspeicher. OASIS — MQTT Version 5.0
Beschreiben Sie getrennt, was Gerät, Bibliothek, Broker und Empfänger speichern. Prüfen Sie die tatsächlich verwendete Bibliothek und deren Konfiguration. Ein nicht dokumentierter Standardwert ist keine belastbare Zusage für das Verhalten nach einem Geräte-Neustart.
Speicherbedarf und Überlastverhalten berechnen
Ein einfacher Planungsansatz ist Nachrichtenrate mal maximale Offlinezeit mal gespeicherte Bytes je Datensatz. Ergänzen Sie Verwaltungsdaten und Reserve. Beispielsweise ergeben zwei Datensätze pro Sekunde über eine Stunde 7.200 Einträge, noch ohne Aussage zur Größe eines Eintrags.
Legen Sie fest, was bei vollem Puffer geschieht: ältere Daten ersetzen, bestimmte Nachrichten verwerfen oder einen Fehler melden. Begrenzen Sie das Nachsenden, damit neue Messungen und Steuerfunktionen weiter bedient werden. Beachten Sie beim persistenten Speicher die vorgesehenen Schreibzyklen.
Ende-zu-Ende-Verhalten prüfen
Der Empfänger sollte anhand der Anwendungskennung erkennen können, ob ein Ereignis bereits verarbeitet wurde. Wiederholte Nachrichten dürfen nicht unbeabsichtigt denselben Auftrag mehrfach ausführen. Definieren Sie für Steueraufträge zusätzlich Gültigkeit und Rückmeldung.
Testen Sie Netzausfall, Broker-Neustart und Geräte-Neustart getrennt. Prüfen Sie nach der Rückkehr Anzahl, Reihenfolge, Datenalter und Doppelverarbeitung. Ein Test gilt erst dann als bestanden, wenn die erwartete Anwendungswirkung nachvollziehbar ist, nicht nur die Verbindung wieder angezeigt wird.
Entscheidungen für den Offlinebetrieb
- Historie, Zustand und Aufträge getrennt klassifizieren.
- Maximales Datenalter und Offlinezeit festlegen.
- Puffergröße und Verhalten bei Überlauf berechnen.
- Ereigniskennung und Duplikatbehandlung definieren.
- Netz-, Broker- und Geräteausfälle getrennt testen.
Häufige Fragen
Garantiert ein höherer QoS-Wert eine einmalige Geschäftswirkung?
Nicht allein. Die Anwendung muss zusätzlich klären, wie Empfang, Speicherung und Verarbeitung zusammenhängen und wie Wiederholungen erkannt werden.
Soll jeder Messwert dauerhaft gespeichert werden?
Nur wenn der Anwendungsfall das verlangt. Für manche Zustandsanzeigen reicht der neueste Wert; für einen Verlauf können Lücken hingegen relevant sein. Die Entscheidung gehört in die Anforderungen.
Technische Quellen
Passende Entwicklungsleistung