Im Kontext des Unified Namespace (UNS) spielt die Verfügbarkeit aktueller Zustandsinformationen eine zentrale Rolle. MQTT Retained Messages bieten eine einfache Möglichkeit, den jeweils letzten bekannten Wert eines Topics im Broker zu speichern und neu verbundenen Clients sofort bereitzustellen. Richtig eingesetzt verbessern sie Reaktionszeiten, erleichtern die Inbetriebnahme neuer Systeme und erhöhen die Transparenz im Shopfloor. Doch wie bei vielen leistungsfähigen Funktionen liegt der Schlüssel im gezielten Einsatz. Dieser Artikel erklärt, was Retained Messages sind, wie sie sich von regulären MQTT-Nachrichten unterscheiden, wann ihr Einsatz sinnvoll ist – und wann nicht.
Was sind MQTT Retained Messages?
Eine MQTT Retained Message ist eine reguläre Nachricht, die im Broker persistent gespeichert wird. Dabei hält der Broker stets die zuletzt gesendete Retained Message inklusive der zugehörigen Quality-of-Service (QoS) Stufe für das jeweilige Topic vor. Pro Topic wird immer nur eine Retained Message gespeichert, wobei ältere Retained Messages überschrieben werden. Retained Messages 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 Messages die Lösung. In diesem Fall erhält jeder neu abonnierte Client die zuletzt gespeicherte Retained Message, 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 und Löschen von MQTT Retained Messages
Für das Senden einer Retained Message 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 Messages.
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.
Sinnvolle Anwendungsfälle im Unified Namespace (UNS)
Retained Messages stellen sicher, dass wichtige Status- und Kontextdaten im UNS dauerhaft verfügbar sind. Insbesondere bei langsam aktualisierten oder zustandsorientierten Topics ermöglicht das Retain-Flag neuen Abonnenten den letzten Systemzustand zu erhalten. Typische Anwendungsfälle sind:
- Maschinenstatus und Verfügbarkeit: Betriebszustände von Anlagen (ein/aus, Betriebsart) können als Retained Message publiziert werden. So erhält z. B. ein neu verbundener Monitoring-Client direkt die Information, ob eine Anlage aktuell in Betrieb ist. Auch Verfügbarkeitsinformationen (Heartbeat oder Last-Will, die den Online-Status signalisieren) profitieren von Retain, damit alle Subscriber stets den aktuellen Status sehen.
- Letzte Messwerte: Ein klassisches SCADA-System benötigt beim Start sofort Zugriff auf den letzten bekannten Zustand aller relevanten Tags – z. B. Maschinenstatus, Alarme oder Produktionszähler. Wenn ein Werker sein HMI öffnet, erwartet er, unmittelbar den aktuellen Status zu sehen, ohne auf neue Daten warten zu müssen. Retained-Messages können in diesem Fall sicherstellen, dass das HMI sofort alle benötigten Zustände verfügbar hat.
- Stammdaten und Metadaten: Selten veränderte Konfigurationsparameter oder Metadaten (wie Gerätekonfigurationen, Kalibrierungswerte, Anlagenkennungen) werden häufig als Retained Messages abgelegt. Neue Clients im UNS können so jederzeit auf solche Informationen zugreifen, was eine schnelle Inbetriebnahme zusätzlicher Anwendungen erleichtert. Beispielsweise können Topics mit Gerätedaten (Seriennummer, Modell) oder Anlagenbeschreibungen als retained hinterlegt sein, damit sie im Unified Namespace präsent bleiben.
Typische Fehlanwendungen von Retain
Trotz der Vorteile können Retained Messages bei unsachgemäßer Anwendung im UNS Probleme verursachen. Häufige Fehlanwendungen sind unter anderem:
- Veraltete Daten und Fehlinformationen: Stellen wir uns folgendes Szenario vor. Um 7:00 Uhr publiziert ein Sensor einen Messwert von 187°C 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. Um 15:00 Uhr schaltet ein anderer Mitarbeiter ein neues Überwachungssystem online. Dieses System abonniert das Topic factory/process1/temperature. Das Überwachungssystem erhält nun die letzte gespeicherte Nachricht von 187°C. Da das Überwachungssystem auf veraltete Temperaturdaten zurückgreift, könnte es falsche Alarme auslösen.
- Performance Overhead: Ein häufiger Irrtum ist die Empfehlung, alle MQTT-Nachrichten mit dem Retain-Flag zu versehen. Dies widerspricht dem Designgedanken von MQTT und kann Broker überlasten, insbesondere bei hochfrequenten Topics (z. B. Sensordaten im Millisekundentakt). Man sollte den Retain Einsatz daher auf sinnvolle Daten beschränken und bei hochfrequenten Streams prüfen, ob Retain tatsächlich nötig ist.
Wie Arlen Nipper, einer der Erfinder von MQTT, betont: „If everything was published with RETAIN then it’s probably NOT an application that should be using MQTT.“
Best Practices bei der Nutzung von Retained Messages
Ein effizientes Lebenszyklus-Management für Retained Messages stellt sicher, dass der Unified Namespace (UNS) konsistent und aktuell bleibt. Wichtige Strategien dabei umfassen die folgenden Punkte.
Geplante Aktualisierung und „Birth“-Events
Beim (Wieder-)Start eines Systems oder Geräts sollte dieses seine wichtigsten Zustandsdaten erneut als Retained Messages publizieren, um den UNS zu initialisieren. Dies verhindert, dass veraltete Einträge aus einer früheren Sitzung bestehen bleiben. In Protokollerweiterungen wie Sparkplug B wird hierzu ein Birth-Message-Konzept genutzt, um bei Verbindungsaufbau alle aktuellen Werte zu verteilen. Ein ähnliches Vorgehen lässt sich in MQTT implementieren, indem Geräte beim Start definierte Topics (Status, letzte Werte, etc.) mit retain neu schicken.
Last-Will und Offline-Markierung
Für Status Topics empfiehlt sich die Kombination aus Retain und Last Will Testament (LWT). Dabei richtet der Client beim Connect eine LWT-Nachricht ein, die z. B. das Status-Topic …/state im Fehlerfall auf „offline“ setzt. Fällt der Client aus, publiziert der Broker automatisch die vordefinierte Nachricht an alle Subscriber. Auf diese Weise ist der Online/Offline Status immer aktuell im UNS sichtbar, ohne manuelles Eingreifen. Dabei ist wichtig, die LWT-Nachricht als Retained zu konfigurieren, damit der Offline-Status bestehen bleibt, bis sich das Gerät wieder online meldet.
Regelmäßige Bereinigung von Retained Messages
Retained Messages bleiben im Broker, bis sie aktiv gelöscht werden. Um veraltete oder überflüssige Topics zu vermeiden, sollte regelmäßig eine gezielte Bereinigung erfolgen – z. B. beim Entfernen von Sensoren oder nach Tests. Dazu wird eine Nachricht mit leerem Payload und gesetztem Retain-Flag auf das betreffende Topic gesendet. Diese Routine sollte automatisiert oder als fester Wartungsschritt etabliert sein, um den UNS konsistent und aktuell zu halten.
Fazit
Korrekte MQTT-Einstellungen, insbesondere der selektive Einsatz von Retained-Nachrichten, sind im Kontext des Industrial Unified Namespace (UNS) entscheidend für eine zuverlässige Datenverfügbarkeit. Retained-Messages ermöglichen neuen Abonnenten einen sofortigen Überblick über den letzten bekannten Zustand, sind aber kein Ersatz für echte Persistenz. Falscher Einsatz kann zu veralteten Daten und unerwünschten Reaktionen führen – insbesondere in SCADA-ähnlichen Szenarien. Nutzen Sie Retained-Messages gezielt und mit Bedacht.
