Nach einem Neustart des Brokers oder von Home Assistant liegt es nahe, die erste MQTT-Nachricht als Zeichen zu nehmen, dass alles wieder läuft. Meist reicht das nicht. Ein Client kann sich neu verbinden, während eine Entität noch nicht verfügbar ist. Ein als Retained Message gespeicherter Zustand kann veraltet sein, und eine Automation kann aktiviert sein, ohne das benötigte Ereignis zu empfangen.
Eine Birth Message liefert dir einen klar definierten Anhaltspunkt: Ein Client hat sich verbunden und eine bekannte Payload veröffentlicht. Ob das ganze System funktioniert, sagt sie dir nicht. In dieser Anleitung prüfst du mit einem kleinen Test-Topic drei Dinge: ob Home Assistant sich neu verbunden hat, ob ein bekannter Publisher sich neu verbunden hat und ob eine unkritische Automation das Ereignis erfasst hat. Das Ergebnis gilt nur für den kontrollierten Ablauf, den du testest. Es belegt nicht, dass ein NAS, ein Sensor, ein Netzwerk oder eine produktiv genutzte Automation wieder funktioniert.
Der Client hinter der Meldung
MQTT ist ein Publish/Subscribe-Protokoll. Ein Publisher sendet eine Nachricht an ein Topic, und der Broker liefert sie an Clients mit passenden Abonnements aus. Das Protokoll legt fest, wie Nachrichten weitergeleitet werden. Es legt nicht fest, was eine Payload wie online, ready oder homeassistant bei einem bestimmten Produkt bedeutet. Topic-Namen und Payload-Werte gehören zur Konfiguration und sind keine allgemeingültigen Diagnosewerte. Die MQTT-5.0-Spezifikation ist die Referenz für Topics, Abonnements, Retained Messages, Sessions und Verbindungen.
Die MQTT-Integration von Home Assistant bietet Einstellungen für eine Birth Message und eine Last-Will-Nachricht. Diese Birth Message gehört zum MQTT-Client von Home Assistant. Ihre Veröffentlichung sagt etwas über die Verbindung dieses Clients und seine konfigurierte Nachricht aus. Sie sagt dir nicht, ob alle anderen MQTT-Clients die Nachricht empfangen, darauf reagiert oder gültige Daten haben. Die Dokumentation der MQTT-Integration von Home Assistant beschreibt diese Einstellungen und ihren Zusammenhang mit der Verbindung zum Broker.
Halte auseinander, auf welchen Client sich eine Beobachtung bezieht. Eine Nachricht auf homeassistant/status kann sich auf Home Assistant beziehen. Ein gerätespezifisches Availability-Topic kann dagegen je nach Gerätekonfiguration Auskunft über einen bestimmten Publisher geben. Im Broker-Log ist möglicherweise eine Verbindung zu sehen. Diese Beobachtungen können einander stützen, aber keine ersetzt die anderen.
Ein rückgängig zu machender Testablauf
Verwende einen Broker und eine Home-Assistant-Instanz, die du selbst administrierst. Wähle ein neues Test-Topic wie lab/reconnect-check-2026-10-27 statt eines Topics, das ein echtes Gerät steuert. Lass Zugangsdaten, private Adressen, Befehle und persönliche Kennungen aus dem Topic und seinen Nachrichten heraus.
Notiere vor dem ersten Neustart die genauen Eckdaten des Tests:
- Das Birth-Topic und die Payload von Home Assistant, wie sie in der MQTT-Integration konfiguriert sind.
- Das Test-Topic und die Payload, die ein bekannter Test-Publisher nach dem erneuten Verbinden verwenden soll.
- Ob die jeweilige Nachricht als Retained Message gespeichert wird.
- Die Entität oder den Helfer, der die Beobachtung festhalten soll.
- Die erwartete Reihenfolge der Ereignisse und die Uhr, deren Zeit du zum Vergleich verwendest.
Diese Notizen helfen dir, einen häufigen Fehler zu vermeiden: Du erkennst einen Wert wieder, ordnest ihn aber der falschen Quelle zu. Der Broker kann einem neuen Abonnenten eine Retained Message zustellen, weil er sie gespeichert hat. Für Zustandsdaten ist das nützlich. Es bedeutet aber nicht zwangsläufig, dass nach dem Neustart jemand eine neue Nachricht veröffentlicht hat. Ändere Retain-Einstellungen nur für den Testablauf und räume sie nach dem Test wieder auf.
Getrennte Beobachtungen von Home Assistant und Publisher
Prüfe zuerst, ob Home Assistant sich mit dem Broker verbindet und seine konfigurierte Birth Message veröffentlicht. Nutze dafür das Log des Brokers oder abonniere genau das konfigurierte Topic. Notiere Zeitpunkt, Topic, Payload und das Retain-Flag der empfangenen Nachricht und halte die Retain-Konfiguration des Publishers separat fest. Das Dashboard allein reicht als Nachweis nicht aus.
Verbinde als Nächstes einen bekannten Test-Publisher neu und lass ihn eine eindeutig erkennbare Test-Payload an das Test-Topic senden. Beobachte diese Nachricht unabhängig von der ersten. Falls der Publisher eine Konfiguration für MQTT Discovery sendet, prüfe, ob Home Assistant die vorgesehene Entität angelegt hat, bevor du deren Zustand als Signal für die erneute Verbindung verwendest. Home Assistant dokumentiert MQTT Discovery getrennt von der zugrunde liegenden Broker-Verbindung. Die Discovery-Dokumentation unterscheidet zwischen der Veröffentlichung einer Konfiguration und der Veröffentlichung eines Zustands: Das sind separate Ereignisse.
Falls eine der beiden Beobachtungen fehlt, prüfe Schreibweise, Groß- und Kleinschreibung, Topic-Hierarchie, Authentifizierung und Retain-Verhalten, bevor du weitere Dienste neu startest. Wenn du viele Dienste auf einmal neu startest, ist die Reihenfolge der Ereignisse hinterher womöglich nicht mehr nachvollziehbar. Gerade sie hätte das Problem erklären können. Ändere eine Variable. Wiederhole dann den kleinen Test.
Eine Automation zur Erfassung des Ereignisses
Sobald beide Testnachrichten in der erwarteten Reihenfolge erscheinen, richte eine vorübergehende Automation ein, die die erneute Verbindung des Test-Publishers erfasst. Ein Zustands-Trigger beobachtet den Zustandswechsel einer Entität; ein MQTT-Trigger beobachtet eine Nachricht auf einem konfigurierten Topic. Wähle den Trigger danach aus, was du beobachten willst, auch wenn du mit dem anderen vertrauter bist. Die Referenz zu Automation-Triggern von Home Assistant erklärt beide Trigger-Arten.
Verwende beim ersten Durchlauf als Aktion eine dauerhafte Benachrichtigung, einen Logbucheintrag oder das Setzen eines Helferwerts. Starte keine Dienste neu, schalte keine Stromversorgung, veröffentliche nichts auf einem Befehls-Topic und ändere keine Netzwerkkonfiguration. Verbinde den Test-Publisher einmal neu und prüfe danach den Automation-Trace. Die Anleitung zur Fehlersuche bei Automationen von Home Assistant unterscheidet zwischen einem Trigger, der nicht ausgelöst hat, und einer Bedingung oder Aktion, an der der Ablauf hängen geblieben ist.
Der Trace bestätigt nur den Ablauf der konfigurierten Regel. Er belegt nicht, dass ein echtes Gerät seinen Wiederanlauf abgeschlossen hat. Falls eine Benachrichtigung zweimal erscheint, suche nach der Ursache, bevor du eine Verzögerung oder einen Wiederholungsversuch einbaust. Mögliche Gründe sind zwei Verbindungen, eine Retained Message, doppelte Automationen oder eine wiederholte Nachricht des Publishers.
Verfügbarkeit und Verbindungsmarker
Eine MQTT-Entität kann anhand eines konfigurierten Availability-Topics einen Verfügbarkeitsstatus bereitstellen. Diesen Status mit einem Marker für die erneute Verbindung zu vergleichen, ist oft hilfreich. Beide beantworten aber unterschiedliche Fragen. Ein Client kann sich neu verbinden, während ein Gerät weiterhin meldet, dass es nicht verfügbar ist. Ein als Retained Message gespeicherter Offline-Zustand kann bestehen bleiben, bis ein Publisher ihn ersetzt. Die Dokumentation zum MQTT-Sensor beschreibt Zustand und Verfügbarkeit als getrennte Konfigurationsbereiche.
Halte die Beobachtungen in deinen Notizen in einer kurzen Tabelle fest, statt sie im Kopf zusammenzuführen: Birth Message von Home Assistant beobachtet, Nachricht des Test-Publishers beobachtet, Verfügbarkeit der Entität und Automation-Trace. Ergänze zu jedem Eintrag einen Zeitpunkt und eine Quelle. Notiere, was du beobachtet hast, ohne gleich eine Ursache zuzuschreiben. Ein Beispieleintrag wäre: „Erneute Verbindung des Publishers um 10:03 beobachtet“ – sofern deine Beobachtungen das belegen. „Das Gerät funktioniert einwandfrei“ möglicherweise nicht.
DeviceShelf Server kann Netzwerkbeobachtungen über MQTT Discovery für eine Home-Assistant-Installation bereitstellen, die du administrierst. Damit hast du eine zusätzliche Beobachtung, die du mit den Aufzeichnungen des Brokers und der Dienste vergleichen kannst. Sie erklärt nicht, warum ein Client sich neu verbunden hat, garantiert keine Geräteverfügbarkeit und bestätigt nicht, dass eine Automation-Aktion erfolgreich war. Halte diese Beobachtung getrennt vom Neustartmarker fest.
Aufräumen nach dem Test und die nächste Prüfung
Deaktiviere oder entferne nach dem Test die vorübergehende Automation und die Konfiguration des Test-Topics. Lösche alle gespeicherten Retained-Testdaten, die du angelegt hast, und prüfe, dass keine Testnachricht eine echte Aktion auslösen kann. Bewahre Topic-Namen, Payloads, Zeitstempel, die Beobachtung am Broker und das Trace-Ergebnis auf, aber keine Zugangsdaten oder anderen Geheimnisse.
Ein brauchbares Ergebnis ist eng begrenzt: Home Assistant hat seine konfigurierte Birth Message veröffentlicht, ein bekannter Test-Publisher hat sich neu verbunden und seine Testnachricht veröffentlicht, und eine unkritische Automation hat dieses Ereignis erfasst. Fehlt ein Teil, untersuche zuerst diesen Teil. Sorge dafür, dass der Testablauf wiederholbar funktioniert, bevor du entscheidest, ob eine produktiv genutzte Automation eine separate Prüfung ihres Wiederanlaufs braucht.