Ein MQTT-Client hat nach einem Reconnect nicht unbedingt einen leeren Posteingang. Je nach Verbindungs- und Abonnementeinstellungen kann der Broker Session-Informationen behalten und Nachrichten zustellen, die während der Abwesenheit des Clients in der Warteschlange gelandet sind. Auch beim Abonnieren eines Topics kann eine Retained-Nachricht ankommen. Beides ist nützlich, aber keines von beidem belegt, dass ein Gerät gerade ein neues Ereignis erzeugt hat.
Das ist relevant, wenn eine Home-Assistant-Automation nach einem Neustart, einer Netzwerkunterbrechung oder Wartungsarbeiten am Broker auf eine Nachricht reagiert. Hinter der Benachrichtigung kann ein neuer Messwert stecken. Es kann aber auch eine Nachricht aus einer früheren Session oder ein gespeicherter Zustand beim Subscriber angekommen sein. Mit dem folgenden Labortest kannst du diese Fälle auseinanderhalten, statt anhand eines Zeitstempels im Dashboard zu raten. Ob ein echtes Gerät, NAS oder ein Dienst fehlerfrei läuft, lässt sich damit nicht feststellen.
Session-Zustand und Retained-Nachrichten
MQTT-Sessions und Retained-Nachrichten sind unterschiedliche Funktionen. Eine Session kann Informationen zu einer Client-Verbindung speichern, darunter Abonnements und, je nach Quality of Service und Session-Einstellungen, Nachrichten, die auf ihre Zustellung warten. Eine Retained-Nachricht speichert der Broker für ein Topic und kann sie später an einen neuen Subscriber senden. Die MQTT-Spezifikation Version 5.0 legt die Protokolldetails fest.
Dass eine Nachricht nach einem Reconnect ankommt, sagt noch nichts darüber aus, warum sie ankommt. Die Payload kann genau gleich aussehen, egal ob sie gerade erst veröffentlicht wurde oder aus einem gespeicherten Zustand des Brokers stammt. Auch Topic-Namen beweisen nichts. Ein Topic namens online, event oder current hat nur die Bedeutung, auf die sich Publisher und Empfänger geeinigt haben.
Notiere vor dem Test vier Angaben für eine einzelne Teststrecke: welcher Client getrennt wird, das genaue Topic, die QoS-Einstellungen von Publisher und Subscriber und ob der Publisher das Retain-Flag setzt. Halte auch das Session-Verhalten der Verbindung fest, wenn du es steuern kannst. Verzichte auf Wildcard-Abonnements. Verwende kein Befehls-Topic. Nimm keine Zugangsdaten, echten Gerätekennungen oder privaten Adressen in Test-Topic-Namen, Payloads oder geteilte Aufzeichnungen auf.
Ein eigenes Test-Topic
Verwende einen Broker und eine Home-Assistant-Instanz, die du selbst verwaltest. Lege ein klar als vorübergehend erkennbares Topic an, etwa lab/session-replay-2026-10-28/event, mit einem bekannten Test-Publisher und einem bekannten Subscriber. Als Subscriber kannst du einen MQTT-Trigger in Home Assistant oder einen separaten Diagnose-Client verwenden. Wähle einen Aufbau, bei dem du Topic, Payload, Empfangszeit und Retain-Kennzeichnung erfassen kannst. Lösche vor jedem unabhängigen Durchlauf eine eventuell vorhandene Retained-Testnachricht, indem du auf genau diesem Test-Topic eine Payload mit einer Länge von null Bytes und aktiviertem Retain-Flag veröffentlichst. Schließe dieses Zurücksetzen ab, bevor du Beobachtungen aufzeichnest. Verwende für jeden Durchlauf eigene, eindeutige Test-Payloads; verwende die folgenden Beispielwerte in späteren Durchläufen nicht erneut.
Lass den Publisher bei verbundenem Subscriber einen eindeutig erkennbaren Wert senden, zum Beispiel run-a. Notiere, was ankommt, und trenne dann den Subscriber. Veröffentliche während der Trennung einen zweiten eindeutigen Wert, run-b, mit deinen gewählten QoS- und Retain-Einstellungen. Ändere pro Durchlauf höchstens eine Einstellung. Wenn run-b nach dem Reconnect ankommt, ist das ein Anhaltspunkt. Du musst aber noch klären, wie es zu dieser Zustellung kam.
Behalte beim Durchlauf zur Fortsetzung der Session dieselbe Client-ID bei und notiere nach dem Reconnect das Session-Present-Flag in CONNACK. Wiederhole den Durchlauf mit einer bewusst neuen Session ohne übernommenen Zustand oder einer abgelaufenen Session, sofern deine Broker- und Client-Konfiguration das unterstützt. Abonniere nach dem Start einer neuen Session das Test-Topic erneut, da die bisherigen Abonnements nicht mehr vorhanden sind. Halte fest, ob der Client automatisch erneut abonniert, und bei MQTT 5 gegebenenfalls auch die Retain-Handling-Einstellung des Abonnements, da die Zustellung von Retained-Nachrichten vom Abonnieren und den Abonnementoptionen abhängt. Wiederhole ihn anschließend mit deaktiviertem und aktiviertem Retain und ändere dabei nur diese eine Einstellung. Solche kleinen Vergleiche sagen mehr aus, als mehrere Dienste gleichzeitig neu zu starten. Ein Neustart kann die Ereignisabfolge verwischen, die das Ergebnis erklären würde.
Beobachtungen am Broker und Ergebnisse beim Subscriber
Erfasse Verbindungsaufbauten, Verbindungstrennungen, Abonnements und Veröffentlichungen im Broker-Log oder über eine andere administrative Diagnosemöglichkeit deiner Testumgebung. Geh nicht davon aus, dass die Benutzeroberfläche jedes Detail auf Broker-Seite zeigt. Das MQTT-Protokoll legt fest, wie sich Pakete und Sessions verhalten. Wie diese Details in der Diagnose auftauchen, hängt von der Implementierung des Brokers ab.
Lege für jeden Durchlauf eine kleine Tabelle an: Verbindungszeitpunkt, Session-Einstellung, Veröffentlichungszeitpunkt, Retain-Flag, Empfangszeit beim Subscriber und empfangener Wert. Kennzeichne jede Zeile als Beobachtung, nicht als Schlussfolgerung. Die Aussage „Subscriber hat run-b nach dem Reconnect empfangen“ lässt sich zum Beispiel belegen. „Das Gerät hat nach dem Reconnect ein neues Ereignis gesendet“ dagegen nicht, sofern nicht eine neue Messung des Publishers samt Zeitstempel genau das belegt.
Wenn sich das Ergebnis ändert, sobald du nur Retain umschaltest, prüfe zuerst, ob eine Retained-Nachricht die Erklärung ist. Ändert es sich nur mit der Session-Einstellung, prüfe die Fortsetzung der Session und die Zustellung aus der Warteschlange. Wenn beides keinen Unterschied macht, kontrolliere Schreibweise, Groß- und Kleinschreibung, Authentifizierung, ACLs, QoS und den genauen Abonnementfilter, bevor du weitergehende Schlüsse ziehst.
Eine harmlose Home-Assistant-Automation
Home Assistant kann direkt auf eine MQTT-Nachricht reagieren. Seine MQTT-Integration hat außerdem ein eigenes Verbindungs- und Discovery-Verhalten. Die Dokumentation der MQTT-Integration und die Referenz zu Automation-Triggern unterscheiden zwischen der Einrichtung der Integration und der Trigger-Konfiguration einer Automation. Eine erfolgreiche Verbindung sagt noch nicht, ob eine bestimmte Regel die vorgesehene Nachricht erhalten hat.
Lege eine vorübergehende Automation für das Test-Topic an. Lass sie beim ersten Test eine dauerhafte Benachrichtigung erstellen, einen Logbucheintrag schreiben oder einen eigens dafür angelegten Helfer aktualisieren. Veröffentliche keinen Befehl, starte keinen Host neu, schalte keine Stromversorgung und ändere keine Netzwerkeinstellung. Sende die beiden Testwerte in der festgelegten Reihenfolge. Prüfe anschließend den Automation-Trace und das Ergebnis der harmlosen Aktion.
Der Trace beantwortet eine begrenzte Frage: Wurde der Trigger dieser Regel ausgelöst und der konfigurierte Ablauf vollständig durchlaufen? Er belegt nicht, wann ein echtes Geräteereignis stattgefunden hat oder woher es kam. Die Hinweise zur Fehlersuche bei Home-Assistant-Automationen helfen dir zu unterscheiden, ob ein Trigger gar nicht ausgelöst wurde oder eine Bedingung beziehungsweise Aktion das erwartete Ergebnis verhindert hat.
Wenn die Automation zweimal auslöst, baue nicht sofort eine Verzögerung oder eine Regel zur Unterdrückung ein. Vergleiche die Zeiten beider Traces mit den Beobachtungen am Broker und der Testtabelle. Die Ursache könnte ein wiederholtes Ereignis des Publishers, eine Retained-Nachricht, zwei Abonnements oder ein Effekt des Reconnects sein. Wenn du die zweite Benachrichtigung mit einem Workaround ausblendest, verschwinden womöglich auch die Hinweise, die du für die Fehlersuche brauchst.
Discovery, Verfügbarkeit und neue Ereignisse
MQTT Discovery kann eine Home-Assistant-Entität anlegen oder aktualisieren, nachdem eine Konfiguration veröffentlicht wurde. Das ist etwas anderes als eine Zustandsnachricht. Eine erneut zugestellte Nachricht ist wiederum ein eigener Fall. Die Discovery-Dokumentation von Home Assistant erklärt den Konfigurationsablauf. Bevor du eine Änderung an einer Entität als Beleg in einem Session-Test wertest, prüfe die eindeutige ID und das Zustands-Topic der Entität.
Auch ein Verfügbarkeits-Topic ist ein separates Signal. Es kann den Verbindungszustand wiedergeben, den der Publisher gemäß seiner Konfiguration meldet. Es prüft aber nicht jeden Dienst, für den dieser Publisher steht. Ein NAS kann zum Beispiel mit dem Broker verbunden sein, während eine Dateifreigabe nicht erreichbar ist. Halte Änderungen der Verfügbarkeit und empfangene Ereignisse in getrennten Spalten fest.
DeviceShelf Server kann Netzwerkbeobachtungen über MQTT Discovery an eine Home-Assistant-Installation liefern, die du selbst verwaltest. Du kannst eine Beobachtung mit Broker- und Dienstprotokollen vergleichen. Daraus lässt sich weder die Ursache einer erneuten Zustellung durch den Broker noch die Identität oder Verfügbarkeit eines Geräts ableiten. Auch der Erfolg einer Automation-Aktion ist damit nicht belegt.
Aufräumen und eine klar begrenzte Schlussfolgerung
Deaktiviere oder entferne nach dem Test die vorübergehende Automation. Lösche alle Retained-Testnachrichten, die du angelegt hast, und prüfe, dass kein Test-Topic eine Aktion im Produktivbetrieb beeinflussen kann. Bewahre die Aufzeichnung der Testeinstellungen, Nachrichtenreihenfolge, Broker-Beobachtungen und Trace-Ergebnisse ohne sensible Daten auf. So hast du bei einem späteren Vorfall eine Vergleichsgrundlage, ohne das Laborergebnis auf sämtliche Clients zu übertragen.
Beschränke deine Schlussfolgerung auf das Beobachtete: Mit den dokumentierten Session- und Retain-Einstellungen hat der Test-Subscriber nach dem Reconnect einen bestimmten Wert empfangen, und die vorübergehende Automation hat ihn ein- oder zweimal erfasst. Wenn die Herkunft weiter unklar ist, prüfe die zugehörigen Publisher- und Broker-Logs, bevor du eine Alarmierung im Produktivbetrieb änderst. Der Test soll dir einen konkreten nächsten Prüfschritt liefern. Eine einzelne MQTT-Zustellung garantiert keinen störungsfreien Betrieb.