Im Rahmen eines Industrial Unified Namespace (UNS) spielen korrekte MQTT Einstellungen und Parameter eine wesentliche Rolle. Dieser Guide beschreibt MQTT Retained-Nachricht (Messages), wann deren Einsatz sinnvoll ist und wann sie vermieden werden sollten. Weitere Informationen zum Industrial Unified Namespace (UNS) finden Sie in unseren Ressourcen.
Was ist eine „Retained Nachricht“?
Eine MQTT-Retained-Nachricht ist eine reguläre Nachricht, die im Broker persistent gespeichert wird. Dabei hält der Broker stets die zuletzt gesendete Retained-Nachricht inklusive der zugehörigen Quality-of-Service (QoS) Stufe für das jeweilige Topic vor. Pro Topic wird immer nur eine Retained-Nachricht gespeichert, wobei ältere Retained-Nachrichten überschrieben werden. Retained-Nachrichten ermöglichen es neu abonnierten Clients, unmittelbar nach der Subscription den aktuellen Status des Topics zu erhalten, ohne auf die nächste Aktualisierung durch den Publisher warten zu müssen.
Was ist der Unterschied zu regulären Nachrichten?
Reguläre MQTT-Nachrichten (ohne „Retained“ Flag) werden vom Broker nicht persistiert. Dies beeinflusst die Zustellung von Nachrichten, insbesondere bei längeren Intervallen zwischen neuen Veröffentlichungen. In der Praxis können diese von Sekunden bis hin zu mehreren Minuten oder Stunden variieren. Infolgedessen erhalten Subscriber erst dann eine Aktualisierung, wenn ein Client neue Nachricht publiziert. Wenn jedoch ein sofortiger Zugriff auf den aktuellen Status eines Topics erforderlich ist, bieten Retained-Nachrichten die Lösung. In diesem Fall erhält jeder neu abonnierte Client die zuletzt gespeicherte Retained-Nachricht, selbst wenn seit der letzten Veröffentlichung keine weiteren Updates erfolgt sind. Der Broker stellt somit eine Momentaufnahme des letzten bekannten Zustands des Topics bereit. Clients erhalten so stets die aktuellsten Informationen, unabhängig von der Häufigkeit der Nachrichtenveröffentlichung.
Senden von MQTT-Retained-Nachrichten
Für das Senden einer Retained-Nachricht setzt der Entwickler das „Retained Flag“ in der MQTT-Publish-Nachricht auf true. Folglich speichert der Broker die Nachricht und stellt sie neuen Abonnenten nach der Subscription zur Verfügung. Die meisten MQTT-Client-Bibliotheken und Tools, wie etwa MQTT Explorer, bieten eine benutzerfreundliche Option, um das „Retained Flag“ zu aktivieren. Auch die i-flow Software bietet eine intuitive Möglichkeit, diese Funktion zu nutzen und vereinfacht so den Umgang mit Retained-Nachrichten.
Wichtig: Der Einsatz von Retained-Nachrichten erhöht den Overhead der MQTT Nachricht, besonders in Umgebungen mit hoher Frequenz von Updates für Retained-Nachrichten. Dies sollte bei der Skalierung und Performance-Optimierung des Systems berücksichtigt werden.
Löschen von MQTT-Retained-Nachrichten
Eine neue Retained-Nachricht mit leerem Payload (Nachrichteninhalt) löscht die bestehende Retained-Nachricht für das entsprechende Topic. Dies signalisiert dem Broker, die aktuell gespeicherte Retained-Nachricht für dieses Topic zu entfernen. Sobald der Broker die Nachricht mit leerem Payload empfängt, wird die Retained-Nachricht für dieses Topic gelöscht. Keine weiteren Clients erhalten beim Abonnement eine alte Nachricht.
Beispiel Use-Case im Kontext Unified Namespace (UNS)
Um die Bedeutung im UNS Kontext zu verdeutlichen, betrachten wir das folgende Beispiel. Stellen wir uns ein Szenario vor, in dem ein Sensor kritische Prozessparameter wie z.B. die Prozesstemperatur überwacht. Der Sensor publiziert die Daten an spezifische MQTT-Topics, um Echtzeit-Monitoring und automatische Sicherheitsprüfungen in einem Überwachungssystem zu ermöglichen.
1. Falsche Verwendung des Retain-Flag
- Um 7:00 Uhr morgens publiziert ein Temperatursensor einen Messwert von 38°C (100°F) auf das Topic factory/process1/temperature. Dabei ist der Retain-Flag auf „true“ gesetzt, sodass der MQTT-Broker diese Nachricht als den letzten bekannten Zustand speichert.
- Anschließend findet eine Wartung statt, ein Mitarbeiter schaltet den Prozess ab.
2. Ein neuer Subscriber verbindet sich
- Um 15:00 Uhr schaltet ein Mitarbeiter ein neues Überwachungssystem online. Dieses System abonniert das Topic factory/process1/temperature.
- Das Überwachungssystem erhält nun die letzte gespeicherte Nachricht von 7:00 Uhr morgens, welche eine Temperatur von 100°F enthält.
3. Unbeabsichtigte Folge
- Da das Überwachungssystem auf veraltete Temperaturdaten zurückgreift, könnte es unnötige Alarme auslösen.
Fazit
Korrekte MQTT-Einstellungen, insbesondere der Einsatz von Retained-Nachrichten, sind im Kontext des Industrial Unified Namespace (UNS) entscheidend für eine zuverlässige Datenübertragung. Retained-Nachrichten ermöglichen es neuen Abonnenten, den aktuellen Status eines Topics sofort zu erhalten. Falscher Einsatz kann jedoch zu veralteten Informationen und unerwünschten Reaktionen führen. Daher ist eine sorgfältige Konfiguration unerlässlich, um optimale Ergebnisse zu gewährleisten.
