Ein Dashboard auf MQTT-Basis kann ein Gerät schon wenige Sekunden nach einem Verbindungsabbruch als offline anzeigen. Das ist praktisch, besonders wenn das Gerät normalerweise dauerhaft mit dem Broker verbunden ist. Allerdings lässt sich aus der Meldung schnell zu viel herauslesen. Eine MQTT-Offline-Meldung allein beweist nicht, dass ein NAS keinen Strom mehr hat, ein Dienst beendet wurde oder das gesamte Netzwerk ausgefallen ist.
Solche Meldungen stammen oft von der MQTT-Funktion Last Will and Testament, kurz LWT. Damit kann ein Client beim Broker eine Nachricht hinterlegen, die dieser bei einem unerwarteten Verbindungsabbruch veröffentlicht. In diesem Guide erfährst du, was diese Nachricht aussagt, wie du sie ohne Störungen im laufenden Betrieb testest und wie du dafür sorgst, dass eine Automation nur Schlüsse zieht, die ihre Eingangsdaten auch hergeben.
Das Verbindungsereignis aus Sicht des Brokers
Ein MQTT-Client kann eine Will-Nachricht mit Topic, Payload, Quality-of-Service-Einstellung und optionalem Retained-Flag hinterlegen. Erkennt der Broker, dass die Verbindung ohne regulären Disconnect beendet wurde, kann er diese Nachricht für den Client veröffentlichen. Der Broker meldet damit, was mit einer Client-Verbindung passiert ist. Er prüft nicht jeden Prozess oder jede Netzwerkschnittstelle auf dem Gerät.
Die Spezifikation MQTT Version 5.0 definiert Will-Nachrichten und die Bedingungen für ihre Veröffentlichung. Sie beschreibt auch Optionen für Sessions und Verzögerungen, die beeinflussen können, wann ein Subscriber eine Will-Nachricht erhält. Diese Einstellungen sind relevant, wenn die Meldung eine zeitkritische Reaktion auslösen soll.
Ein Publisher könnte zum Beispiel beim Verbindungsaufbau eine Birth-Nachricht mit online senden und eine Will-Nachricht mit offline hinterlegen. Fällt das WLAN aus, verliert das Gerät die Stromversorgung oder wird ein Netzwerkpfad unterbrochen, veröffentlicht der Broker möglicherweise nach einiger Zeit offline. Das ist ein guter Hinweis darauf, dass der Broker vom Client nicht den erwarteten regulären Disconnect erhalten hat. Welche Ursache dahintersteckt, verrät die Nachricht nicht. Sie sagt auch nichts über den Zustand einer Dateifreigabe, einer Weboberfläche oder eines Speichervolumes auf demselben Rechner aus.
Bevor du aus einem Topic einen Alarm machst, halte genau fest, was es dir sagt. „Die Verbindung zum MQTT-Client wurde unterbrochen“ ist eine klar begrenzte Aussage, die du testen kannst. „Das NAS ist kaputt“ fasst mehrere verschiedene Fragen zusammen und braucht weitere Belege.
Reguläres Beenden und unerwartete Verbindungsabbrüche
Eine Anwendung kann ihre Verbindung zum Broker normalerweise sauber beenden. Je nach Client-Konfiguration und Protokolleinstellungen verhindert das möglicherweise, dass der Broker eine Will-Nachricht veröffentlicht. Die Will-Nachricht soll einen unerwarteten Verbindungsabbruch melden. Sie ist kein allgemeines Shutdown-Protokoll. Du kannst daran nicht zuverlässig erkennen, ob jemand einen Dienst absichtlich beendet hat.
Auch Keepalive beeinflusst den Zeitpunkt. MQTT-Clients und Broker erkennen damit, wenn auf einer Verbindung keine Nachrichten mehr ankommen. Der Broker bemerkt den Abbruch nicht unbedingt genau in dem Moment, in dem jemand ein Kabel zieht. Die Verzögerung hängt vom eingestellten Intervall, den Zeitabläufen im Netzwerk und dem Verhalten des Brokers ab. Halte fest, wann der Subscriber die Nachricht empfangen hat; erfasse den Zeitpunkt, zu dem der Broker den Verbindungsabbruch erkannt hat, nur dann separat, wenn Broker-Logs ihn belegen. Durch Will Delay, Zustellungsverzögerungen und erneut zugestellte gespeicherte Nachrichten können diese Zeitpunkte voneinander abweichen.
Home Assistant dokumentiert eine MQTT-Integration mit Birth- und Last-Will-Nachrichten sowie Availability-Topics für MQTT-Entitäten. Die Dokumentation zur Verfügbarkeit erklärt den Unterschied zwischen dem aktuellen Wert einer Entität und dem Verbindungssignal, anhand dessen dieser Wert als verfügbar oder nicht verfügbar gilt.
Eine offline-Will-Nachricht kann mit gesetztem Retained-Flag gespeichert werden. Das kann sinnvoll sein, wenn ein neuer Subscriber den zuletzt bekannten Verfügbarkeitsstatus braucht. Es gibt allerdings einen Haken: Ein Subscriber kann beim Start einen gespeicherten Offline-Wert erhalten. Diese Nachricht gibt den zuletzt erfassten Zustand wieder. Das bedeutet nicht unbedingt, dass beim Verbindungsaufbau des Subscribers ein neuer Ausfall aufgetreten ist.
Ein eigenes Topic für kontrollierte Tests
Führe Tests nur auf einem Broker und in einem Netzwerk durch, die du selbst administrierst. Wähle ein separates, eindeutig gekennzeichnetes Test-Topic statt eines Topics zur Gerätesteuerung im laufenden Betrieb oder eines Wildcard-Abonnements. Verwende kein Topic, das ein Schloss, einen Schalter, eine Alarmeskalation oder eine andere physische Aktion auslöst.
Richte einen temporären Client mit einer online-Birth-Nachricht und einer offline-Will-Nachricht ein. Abonniere das Topic mit einem zweiten, dazu berechtigten Client und protokolliere Topic, Payload, Empfangszeitpunkt beim Subscriber, Retained-Kennzeichnung und eingestelltes Keepalive. Beende den Publisher zuerst regulär. Prüfe, ob der Broker die Will-Nachricht veröffentlicht. Unterbrich in einem separaten Test den Netzwerkpfad des Clients oder beende seinen Prozess abrupt, sodass er keinen DISCONNECT senden kann. Beobachte dann, ob und wann die Will-Nachricht beim Subscriber ankommt.
Das Subscriber-Handbuch von Mosquitto beschreibt einen Kommandozeilen-Client, mit dem du ein Test-Topic beobachten kannst. Seine Ausgabe zeigt, welche Nachrichten er empfangen hat. Das beweist nicht, dass alle anderen Subscriber reagiert haben oder dass das Gerät selbst über keinen anderen Weg erreichbar ist.
Verwende eindeutige Test-Payloads ohne sensible Informationen. Ein kurzer Wert wie test-online oder test-offline ist sicherer als ein echter Hostname, eine private Adresse, eine Inventarliste, ein Token oder Zugangsdaten. Wenn du beim Test eine Will-Nachricht mit Retained-Flag verwendest, lösche den gespeicherten Testwert, nachdem du das Ergebnis festgehalten hast. So räumst du hinter dir auf. Kopien, die ein Subscriber bereits verarbeitet hat, verschwinden dadurch aber nicht.
Unabhängige Prüfungen für die konkrete Frage
Wähle eine unabhängige Prüfung danach aus, was du mit dem Ergebnis tun würdest. Wenn du wissen willst, ob ein NAS-Dateidienst erreichbar ist, teste den dokumentierten Dienst über einen Zugriffsweg, für den du berechtigt bist. Wenn du prüfen willst, ob der Host neu gestartet wurde, ziehe eine Aufzeichnung der Laufzeit oder das Systemprotokoll zum Vergleich heran. Bei einer möglichen WLAN-Änderung prüfst du die aktuellen Zuordnungsdaten der WLAN-Clients auf den Netzwerkgeräten. Jede dieser Prüfungen beantwortet eine andere Frage als ein MQTT-Verbindungsereignis.
Du kannst eine Automation auch eine kurze, dokumentierte Wartezeit abwarten lassen, bevor sie eine Benachrichtigung sendet. Sende nach der Wartezeit nur dann eine Benachrichtigung, wenn die Offline-Bedingung weiterhin erfüllt ist. Das reduziert unnötige Meldungen durch kurze WLAN-Wechsel oder Broker-Neustarts. LWT wird dadurch aber nicht zu einer Prüfung des Gerätezustands. Eine sinnvolle Bedingung könnte sowohl eine Offline-Will-Nachricht als auch das Ausbleiben eines neuen Publisher-Zeitstempels nach dem erwarteten Intervall voraussetzen. Teste die Regel mit einer absichtlich kurzen Unterbrechung, einem regulären Beenden sowie einem Neustart des Brokers oder Subscribers.
Teste nicht, indem du unbekannte Geräte blockierst oder Router-Einstellungen im laufenden Heimnetz änderst. Ein kontrollierter Test-Client liefert dir ein klares Ergebnis mit geringerem Risiko, jemanden bei der berechtigten Nutzung zu stören. Wenn dich ein Ergebnis im laufenden Betrieb überrascht, sichere Topic, Zeitpunkt, Payload, gegebenenfalls die Client-ID und die Broker-Logs, bevor du mehrere Einstellungen auf einmal änderst.
Neustarts und gespeicherte Verfügbarkeitsmeldungen
Neustarts von Brokern und Subscribern sind normal. Sie können Verbindungen kurz unterbrechen oder dazu führen, dass gespeicherte Verfügbarkeitsmeldungen eintreffen. Bevor du eine Benachrichtigung an ein Topic knüpfst, starte den Subscriber in einem Testzeitfenster neu und prüfe, ob er einen zuvor gespeicherten Zustand erhält. Starte anschließend den Broker neu, wenn das sicher möglich ist und du dazu berechtigt bist. Beobachte dabei, wie sich die Publisher wieder verbinden.
Das ist für Automationen in Home Assistant relevant. Ein Trigger, der beim erneuten Verbindungsaufbau von Home Assistant auslöst, kann einen Wert verarbeiten, der schon vor dem Neustart vorhanden war. Eine eingehende Nachricht muss eingeordnet werden. Sie bedeutet nicht automatisch, dass eine neue Störung vorliegt. Wenn der Publisher es unterstützt, können ein Zeitstempel, ein monoton steigender Zähler oder ein separat abgebildeter Verfügbarkeitsstatus die Regel präziser machen.
DeviceShelf Server kann Netzwerkbeobachtungen an eine Home-Assistant-Installation senden, die du administrierst. Betrachte diese Daten als eine Informationsquelle unter mehreren. Gleiche ein MQTT-Ereignis mit dem Beobachtungszeitpunkt und dem zugehörigen Geräte- oder Diensteintrag ab. Es garantiert weder die Identität noch die Verfügbarkeit oder Sicherheit eines Geräts. Die Server-Dokumentation beschreibt den unterstützten Integrationsweg.
Schlussfolgerungen auf Basis der Belege
Eine belastbare Notiz zur Fehlersuche nach einer Meldung kann kurz sein: „Zu diesem Zeitpunkt hat der Subscriber eine Offline-Nachricht auf dem konfigurierten Availability-Topic empfangen.“ Halte die unabhängige Prüfung und ihr Ergebnis separat fest. MQTT 5 erlaubt einem Client auch, die Veröffentlichung seiner Will-Nachricht mit dem DISCONNECT-Reason-Code 0x04 absichtlich anzufordern. Zudem muss die Zustellung einer gespeicherten Nachricht nicht mit ihrer Veröffentlichung zusammenfallen. Diese Formulierung belegt daher weder einen unerwarteten Verbindungsabbruch noch den Veröffentlichungszeitpunkt.
Darin liegt der praktische Nutzen von LWT: Es bietet einem verwalteten System einen standardisierten Weg, einen unerwarteten MQTT-Verbindungsabbruch zu melden. Mit einem definierten Topic, einem klar begrenzten Test und einer unabhängigen anschließenden Beobachtung kann es dir helfen, die nächste Prüfung auszuwählen. Für sich genommen kann eine empfangene Offline-Nachricht auf ein Verbindungsproblem zum Broker hinweisen, aber auch auf eine absichtlich angeforderte Will-Veröffentlichung oder einen gespeicherten Zustand zurückgehen. Den Zustand des gesamten Geräts stellt sie nicht fest.