Ein MQTT-Dashboard kann ein Gerät als online anzeigen, sobald Home Assistant, ein Broker oder eine Integration startet. Das ist praktisch, wenn du einen Wert im Dashboard sehen möchtest, ohne auf das nächste Update zu warten. Es kann aber auch täuschen. Der Wert stammt möglicherweise aus einer Retained-Message, die veröffentlicht wurde, bevor ein Laptop in den Ruhezustand ging, ein NAS neu startete oder ein WLAN-Client das Netzwerk verließ.
Der Fehler liegt hier nicht bei MQTT. Das Speichern von Retained-Messages hat einen klaren Zweck und folgt einer festen Zustellregel. Der Fehler besteht darin, eine gespeicherte Nachricht als Beleg dafür zu nehmen, dass ein Gerät gerade erreichbar ist. In dieser Anleitung erfährst du, wie du gespeicherte Statuswerte erkennst, einen kleinen Aufbau unter deiner Verwaltung testest und eine Automatisierung so auswählst, dass alte Informationen keinen dringenden Alarm auslösen.
Nachrichtenzustellung und aktuelle Erreichbarkeit
MQTT veröffentlicht Nachrichten in benannten Topics. Wenn ein Publisher eine Nachricht als retained markiert, speichert der Broker die letzte Retained-Message für dieses Topic. Abonniert später ein Client ein passendes Topic, sendet der Broker ihm diese Nachricht. Die MQTT-Spezifikation nennt sie Retained-Message. Daraus folgt keine Zusage, dass das Gerät, von dem der Wert ursprünglich stammt, noch verbunden ist oder fehlerfrei läuft. MQTT Version 5.0 beschreibt das Retain-Flag und den Umgang des Brokers mit Retained-Messages.
Nimm ein Status-Topic wie home/lab-nas/status, dessen letzte Payload online lautet. Wenn der Publisher diesen Wert gestern gesendet hat und danach der Strom ausfiel, bevor er offline veröffentlichen konnte, kann ein neuer Subscriber heute noch online erhalten. Das zeigt dir, dass der Broker den Wert gespeichert hat. Über die Stromversorgung des NAS, den Netzwerkpfad, den Dateidienst oder die aktuelle Laufzeit des Betriebssystems sagt das allein nichts aus.
Halte zuerst fest, was das Topic laut seiner Definition aussagen soll. Eine Statusnachricht kann bedeuten, dass ein Dienst einen Selbsttest bestanden hat. Sie kann bedeuten, dass eine Netzwerküberwachung eine Antwort empfangen hat, oder lediglich, dass sich ein Client mit einem Broker verbunden hat. Das sind unterschiedliche Beobachtungen. Eine Anzeige wie „verfügbar“ sollte keine Details suggerieren, die Payload und Publisher gar nicht liefern.
Erkennung von Retained-Messages
Untersuche ein Topic nur auf einem Broker und in einem Netzwerk, die dir gehören oder die du verwalten darfst. Die MQTT-Integration von Home Assistant bietet Tools, mit denen du während eines Tests Nachrichten in einem Topic mitlesen kannst. Ihre Dokumentation unterscheidet außerdem zwischen der Broker-Verbindung und den Entitäten und Automatisierungen, die Nachrichten verarbeiten. Unterstützte Konfigurationen und Testmöglichkeiten findest du unter Home Assistant MQTT.
Für eine kontrollierte Prüfung auf der Kommandozeile dokumentiert Mosquitto mosquitto_sub und die Nachrichtenfelder, die es anzeigen kann. Verwende %r im Ausgabeformat von Mosquittos -F-Option, um das RETAIN-Flag zu prüfen und eine Retained-Message zu erkennen. An der Payload allein siehst du das nicht: Die Zeichenfolge online sagt nichts darüber aus, wann sie veröffentlicht wurde. Das Mosquitto-Subscriber-Handbuch beschreibt die passenden Client-Optionen.
Wenn du den Publisher ändern kannst, ergänze die Payload um einen von ihm erzeugten Zeitstempel oder eine monoton steigende Sequenznummer. Dokumentiere, welche Uhr und Zeitzone er verwendet. Einen Zeitstempel musst du trotzdem einordnen. Eine falsch eingestellte Uhr, eine verzögerte Veröffentlichung oder ein alter gespeicherter Wert können ihn als Beleg unbrauchbar machen. Er ermöglicht dir aber, den empfangenen Status mit dem vorgesehenen Update-Intervall abzugleichen, statt dich nur nach der Farbe im Dashboard zu richten.
Ein kleiner, unkritischer Retention-Test
Verwende ein Test-Topic, das du danach wieder löschen kannst, kein Topic zur Gerätesteuerung und kein Wildcard-Abonnement. Veröffentliche einen eindeutig gekennzeichneten Testwert mit aktiviertem Retain-Flag. Richte ein neues Abonnement für das Test-Topic ein; setze bei MQTT 5 Retain Handling auf 0. Ein erneuter Verbindungsaufbau allein reicht nicht aus: Das Fortsetzen einer persistenten Sitzung löst für sich genommen keine erneute Zustellung von Retained-Messages aus. Prüfe, ob der Subscriber diesen Wert erhält, bevor eine neue Nachricht veröffentlicht wird. Lösche anschließend die Retained-Message, indem du gemäß MQTT-Spezifikation eine leere Payload mit gesetztem Retain-Flag im selben Test-Topic veröffentlichst. Halte bei jedem Schritt Topic, Payload, Retain-Kennzeichnung und lokale Uhrzeit fest.
Damit stellst du fest, wie der Broker Retained-Messages für dieses Topic behandelt. Dieser Test prüft kein NAS, belegt nicht die Zustellung an alle Subscriber und bestätigt auch nicht, dass eine Home-Assistant-Automatisierung eine Aktion ausgeführt hat. Dafür brauchst du separate Prüfungen. Wenn der Test anders als erwartet läuft, halte an, bevor du produktiv genutzte Topics änderst. Prüfe den genauen Broker, die Zugangsdaten, die Schreibweise des Topics und die Client-Dokumentation.
Passwörter, vollständige Inventarlisten, private Adressen und Gerätenamen mit Personenbezug gehören nicht in Test-Payloads. Eine Retained-Message kann länger bestehen als der Test-Client. Ein anderer berechtigter Subscriber könnte sie später empfangen. Den Wert nach dem Test zu löschen gehört zum Aufräumen. Trotzdem musst du prüfen, wer Topics abonnieren oder darin veröffentlichen darf.
Ein separates Modell für die aktuelle Verfügbarkeit
Eine Aussage über die aktuelle Verfügbarkeit braucht einen Mechanismus, der auf einer kürzlich erfolgten Beobachtung und einem festgelegten Timeout beruht. Die MQTT-Funktion Last Will and Testament kann eine Nachricht veröffentlichen, wenn eine Client-Verbindung unter bestimmten Umständen endet. Das ist allerdings weiterhin ein Signal zur Broker-Verbindung und keine vollständige Funktionsprüfung aller Dienste auf dem Client. Der MQTT-Standard legt Will-Nachrichten und das Sitzungsverhalten fest. Halte dich an die dokumentierte Konfiguration von Publisher und Broker und lies aus dem Ergebnis nicht mehr heraus, als es tatsächlich aussagt.
Home Assistant dokumentiert außerdem MQTT-Availability-Topics für Entitäten. Über ein Availability-Topic kann eine Entität als nicht verfügbar markiert werden, wenn sich der erwartete Verfügbarkeitsstatus ändert. Ihr Status-Topic liefert weiterhin einen separaten Wert. Lies die Hinweise zur Verfügbarkeit der Integration, bevor du dich für Retained-Messages, Ablaufzeiten oder einen Automatisierungs-Trigger entscheidest. Welche Wahl passt, hängt davon ab, was der Publisher tatsächlich beobachtet.
Die Statusseite eines NAS, eine Dateifreigabe und der MQTT-Client des NAS können zum Beispiel unterschiedliche Zustände melden. Eine funktionierende Broker-Sitzung beweist nicht, dass die Dateifreigabe Anfragen annimmt. Und ein vorübergehend nicht verfügbarer MQTT-Publisher belegt keinen Neustart des NAS. Weise jedem erfassten Signal einen klar benannten Zweck zu. Gleiche es dann mit dem Dienst oder Log ab, das die nächste Frage beantwortet.
Prüfungen auf alte Statuswerte in Automatisierungen
Ein MQTT-Automatisierungs-Trigger kann eine Nachricht erhalten, nachdem Home Assistant gestartet ist oder das Topic erneut abonniert hat. Bevor die Automatisierung eine Benachrichtigung sendet, einen Eintrag schreibt oder ein anderes System verändert, sollte ihre Bedingung Informationen prüfen, die für diese Aktion aussagekräftig sind. Wenn die Aktion einen aktuellen Status erfordert, muss ein vertrauenswürdiger Beobachtungszeitstempel innerhalb eines dokumentierten Aktualitätsfensters vorliegen oder eine neue Beobachtung eingeholt werden. Sequenznummern helfen, Duplikate und die Reihenfolge von Nachrichten zu prüfen; eine bisher unbekannte Sequenznummer kann trotzdem zu einer alten Nachricht gehören. Ein separater Verfügbarkeitsstatus desselben verwalteten Publishers kann eine zusätzliche Bedingung sein, belegt aber nicht die Aktualität der Statusnachricht.
Beginne mit einer risikoarmen Aktion, etwa einem Logbucheintrag oder einer dauerhaften Benachrichtigung, die durch ein Test-Topic ausgelöst wird. Richte ein neues Abonnement für das Test-Topic ein und setze bei MQTT 5 Retain Handling auf 0, um zu prüfen, ob die Retained-Message die Regel auslösen würde. Wiederhole den Test dann mit einem absichtlich alten Zeitstempel und prüfe, ob die Bedingung ihn zurückweist. Ein erfolgreicher Test zeigt, dass ein bestimmter Publisher, ein Topic, eine Bedingung und eine Aktion in diesem Szenario funktioniert haben. Er belegt keine umfassende Geräteüberwachung.
Deaktiviere Retention nicht für unbeteiligte Topics, um ein verwirrendes Ergebnis zu umgehen. Für Konfigurationen und den zuletzt bekannten Status sind Retained-Messages nützlich, wenn ihr Einsatz dokumentiert ist. Beschränke die Änderung auf das betroffene Topic und die Verarbeitung seiner Nachrichten. Führe ein kurzes Testprotokoll und prüfe die Wirkung nach einem normalen Verbindungsneuaufbau.
Ein Protokoll zur Fehlersuche
Wenn ein Gerät unerwartet als online erscheint, halte vier Dinge fest: das genaue Topic, die Payload samt Zeitangaben, ob die empfangene Nachricht retained war und welche unabhängige Prüfung du durchgeführt hast. Bei einem NAS unter deiner Verwaltung könntest du dessen Verwaltungsoberfläche prüfen, auf die du zugreifen darfst, oder einen dokumentierten Dienst, den es normalerweise bereitstellt. Bei einem Publisher zur Netzwerküberwachung könntest du Zeitpunkt und Methode seiner letzten Beobachtung prüfen.
DeviceShelf Server kann Netzwerkbeobachtungen als Publisher an eine Home-Assistant-Installation unter deiner Verwaltung liefern. Prüfe MQTT-Statuswerte oder -Ereignisse zusammen mit dem Zeitpunkt der Beobachtung und den eigenen Aufzeichnungen des Geräts. Sie garantieren weder Verfügbarkeit noch Identität oder Sicherheit. Die Server-Dokumentation beschreibt den unterstützten Integrationsweg.
Oft ist die nützliche Schlussfolgerung überschaubar: „Dieser Subscriber hat einen Retained-Wert empfangen, der zu diesem Zeitpunkt veröffentlicht wurde“, sofern ein vertrauenswürdiger Veröffentlichungszeitstempel vorliegt. Andernfalls halte den Empfangszeitpunkt fest und vermerke ausdrücklich, dass der Veröffentlichungszeitpunkt unbekannt ist. Das reicht, um zu entscheiden, ob du auf ein neues Update wartest, ein Verfügbarkeitssignal prüfst oder einen Dienst direkt kontrollierst. Es ist genauer und sicherer als die Behauptung, eine gespeicherte Statusnachricht beweise, dass das Gerät jetzt online ist.