MQTT Last Will im Industrial Unified Namespace (UNS)

Für die sichere Übertragung von Daten in einem Industrial Unified Namspace (UNS) ist eine stabile und zuverlässige Kommunikation entscheidend. Doch was geschieht, wenn ein Gerät unerwartet die Verbindung verliert? An dieser Stelle kommt MQTT Last Will ins Spiel. Der folgende Artikel beschreibt die Funktionsweise dieses digitalen „Abschiedsbriefs“ im Kontext des Unified Namespace (UNS).

Was ist MQTT Last Will?

Innerhalb des MQTT-Protokolls fungiert ein MQTT Last Will als eine Art Sicherheitsnetz für den Fall, dass ein Client die Verbindung zum Broker unbeabsichtigt verliert (Disconnect). Es handelt sich dabei um eine spezielle Nachricht, die der Client beim Verbindungsaufbau beim Broker hinterlegt. Mehr Informationen zu MQTT Connection Settings finden Sie hier. Sollte der Client die Verbindung unvorhergesehen verlieren, übernimmt der Broker die Verantwortung. Dieser veröffentlicht die Last Will Nachricht im Namen des Clients. In MQTT sind ungeplante Disconnets wie folgt spezifiziert:

1. I/O-Fehler oder Netzwerkfehler: Der Broker stell Probleme mit der Ein-/Ausgabe oder der Netzwerkverbindung fest.
2. Fehlgeschlagene Kommunikation innerhalb des Keep-Alive-Zeitraums: Der Client antwortet nicht innerhalb des festgelegten Keep-Alive-Zeitraums.
3. Client schließt die Verbindung ohne DISCONNECT: Der Client beendet die Netzwerkverbindung, ohne ein DISCONNECT-Paket zu senden.
4. Broker schließt die Verbindung aufgrund eines Protokollfehlers: Der Broker schließt die Netzwerkverbindung aufgrund eines Protokollfehlers.
5. DISCONNECT Message mit dem return code „disconnect-with-will-message“: Ein Client beendet die Verbindung mit spezieller Last Will Message, nur für MQTT v5.0.

Wie funktioniert MQTT Last Will?

Die Unterscheidung zwischen geplanten und ungeplanten Disconnects erfolgt durch das MQTT-Disconnect-Paket. Ein sauberer Disconnect durch den Client beinhaltet dieses Disconnect-Paket, während ein unerwarteter Verbindungsabbruch das Paket nicht enthält. Bei erkanntem unerwartetem Verbindungsabbruch sendet der Broker die Last Will Nachricht an alle Subscriber. Dabei speichert der Broker das MQTT Last Will des Clients, bis der Client geplant die Verbindung trennt.

Dieser Mechanismus ermöglicht eine klare Unterscheidung zwischen geplanten und ungeplanten Verbindungsabbrüchen. Während ein Client bei einem geplanten Disconnect eine Nachricht auf einem bestimmten Topic senden kann, um seinen Status zu kommunizieren, signalisiert die Veröffentlichung des MQTT Last Will durch den Broker einen unerwarteten Ausfall. Dabei ist ein MQTT Last Will eine reguläre Nachricht mit allen üblichen Attributen wie Message, Topic, QoS und Retained-Flag.

Verfügbarkeitsstatus konsistent abbilden

Um ein vollständiges Zustandsmodell abzubilden, sollte ein Client beim erfolgreichen Verbindungsaufbau aktiv eine „online“-Nachricht auf dasselbe Status-Topic senden – idealerweise mit retain=true. Dadurch ist sichergestellt, dass andere Systemkomponenten immer den aktuellen Verfügbarkeitsstatus des Clients erkennen können. Erst durch dieses Zusammenspiel von „online“– und „offline“-Nachrichten entsteht ein robustes und dauerhaft sichtbares Heartbeat-Modell im Unified Namespace.

Zeitpunkt der Last Will Veröffentlichung

Wann genau die Last Will Message vom Broker veröffentlicht wird, hängt maßgeblich von den Keep-Alive-Einstellungen des Clients ab. Der MQTT-Client teilt dem Broker beim Verbindungsaufbau mit, in welchem Intervall er ein Lebenszeichen (Ping) senden wird – typischerweise alle 30 bis 60 Sekunden. Bleibt dieses Lebenszeichen aus, wartet der Broker eine gewisse Toleranzzeit (in der Regel 1,5-fache Keep-Alive-Zeit) und stuft den Client anschließend als nicht mehr erreichbar ein. Erst dann wird die gespeicherte Last Will Message ausgelöst und an alle relevanten Subscriber gesendet. Durch die Wahl eines passenden Keep-Alive-Werts lässt sich somit steuern, wie schnell ein Verbindungsverlust im System sichtbar wird.

Struktur und Verhalten von Last Will

Die MQTT Last Will Message besteht aus mehreren Komponenten, die das Verhalten im Unified Namespace maßgeblich beeinflussen. Im Folgenden werden die wichtigsten Attribute erklärt.

Last Will Message

Die Last Will Message (LWT) ist eine normale MQTT-Nachricht. Der Broker veröffentlicht diese Nachricht im Auftrag des Clients, wenn dessen Verbindung unerwartet abbricht. Sie enthält üblicherweise einen Status wie „offline“ oder „disconnected“ und wird genutzt, um andere Teilnehmer im Unified Namespace über den Ausfall eines Geräts zu informieren. Durch ihre einmalige und automatisch ausgelöste Veröffentlichung trägt sie entscheidend zur Robustheit des Gesamtsystems bei.

MQTT Last Will Topic

Das Topic der Last Will Message bestimmt, unter welcher Adresse der Broker die Nachricht veröffentlicht. In einem Industrial UNS ist es üblich, dafür ein dediziertes Status-Topic zu verwenden, etwa nach dem Muster uns/<device-id>/status. Eine konsistente Topic-Struktur erleichtert das Monitoring und ermöglicht es anderen Systemkomponenten, gezielt auf Statusänderungen zu reagieren.

Last Will Quality of Service (QoS)

Die Quality of Service (QoS) Stufe legt fest, mit welcher Zuverlässigkeit die Last Will Message zugestellt wird. Besonders in industriellen Anwendungen empfiehlt sich QoS 1 („at least once“), um sicherzustellen, dass der Ausfall eines Geräts zuverlässig bei den relevanten Abonnenten ankommt.

Last Will Retained-Flag

Wird die Last Will Message mit aktiviertem Retained-Flag gesendet, bleibt sie auf dem Broker gespeichert und wird an neu hinzukommende Subscriber sofort ausgeliefert. Dies ist insbesondere dann sinnvoll, wenn der Offline-Status eines Geräts auch für spätere Abonnenten sichtbar bleiben soll – beispielsweise für ein zentrales Monitoring-Tool oder zur Initialisierung von Dashboards.

MQTT Last Will im Unified Namespace (UNS)

Im Industrial UNS dient die Last Will Message dazu, den Zustand von angebundenen Systemen zuverlässig abzubilden – auch bei unerwarteten Ausfällen. Sie ermöglicht es, zwischen einem geplanten Disconnect und einem Verbindungsverlust klar zu unterscheiden. Damit die Kommunikation im UNS robust und auswertbar bleibt, müssen die Last Will Mechanik konsequent umgesetzt werden. Die folgenden Best Practices helfen dabei, Statusinformationen konsistent bereitzustellen:

Best Practices

Damit die Last Will Mechanik im Unified Namespace zuverlässig funktioniert, solltest du folgende Punkte beachten:

1. „Online“-Nachricht senden: Sende beim Verbindungsaufbau aktiv eine „online“-Nachricht auf dasselbe Status-Topic. Verwende dabei retain=true. Nur so sehen auch später verbundene Clients den aktuellen Status korrekt.
2. Retained-Flag setzen: Setze das Retained-Flag bei der Last Will Message auf true. So speichert der Broker die „offline“-Nachricht und sendet sie automatisch an neue Subscriber.
3. QoS sinnvoll wählen: Nutze mindestens QoS 1, damit die Nachricht zuverlässig ankommt. Mit QoS 0 kann sie bei Verbindungsproblemen verloren gehen.
4. Konsistente Topic-Struktur nutzen: Halte dich an ein einheitliches Topic-Schema, zum Beispiel: factory1/lin2/device-id123/status. Das erleichtert das Monitoring, die Filterung und die Integration in andere Systeme.
5. Keep-Alive richtig einstellen: Wähle den Keep-Alive-Wert so, dass Verbindungsverluste schnell erkannt werden – aber ohne das Netzwerk unnötig zu belasten. Werte zwischen 30 und 60 Sekunden sind ein guter Ausgangspunkt.

Beispiel Implementierung im UNS

Ein Gerät mit der ID device-42 wird beim Verbindungsverlust als „offline“ markiert. Diese Statusmeldung soll für alle sichtbar sein – auch für Clients, die sich später verbinden. Dabei wird die Last Will Message wird beim Verbindungsaufbau registriert. Wenn device-42 später ohne sauberem Disconnect ausfällt, wird automatisch „offline“ auf dem definierten Topic gesendet. Durch retain=True bleibt diese Nachricht auf dem Broker erhalten, sodass auch neue Abonnenten sofort den letzten bekannten Zustand sehen.

Fazit

Das MQTT Last Will ist ein leistungsstarkes Werkzeug, um die Zuverlässigkeit und Statusverfolgung in MQTT-basierten Systemen zu gewährleisten. Insbesondere im Kontext des Unified Namespace ermöglicht es eine klare Kommunikation über den Zustand von Geräten und Komponenten, selbst wenn diese unerwartet ausfallen.