Ein MQTT-Publisher kann mit einem Broker verbunden sein, ohne dass eine Home-Assistant-Automation reagiert. Oft liegt das Problem nicht am Netzwerk. Der Publisher hat an ein anderes Topic gesendet, als der Subscriber abonniert hat. Oder ein Payload-Filter hat eine Nachricht abgewiesen, die auf den ersten Blick richtig aussah.
Diese Anleitung setzt voraus, dass du den Broker, die Home-Assistant-Instanz und das Test-Topic verwaltest. Mit einem kleinen Test grenzt du eine Topic-Abweichung ein, bevor du einen echten Sensor, ein NAS oder eine Automation mit folgenreichen Aktionen änderst. Ein erfolgreicher Test zeigt dir, was auf diesem Übertragungsweg passiert ist. Er beweist weder, dass ein Gerät einwandfrei funktioniert, noch dass ein Netzwerk sicher ist oder eine andere Automation genauso reagiert.
Der genaue Übertragungsweg vor Änderungen
Notiere zuerst vier Werte exakt so, wie sie eingetragen sind: den Broker, das Topic, an das die Quelle sendet, das in Home Assistant konfigurierte Topic und die Payload, die die Automation erwartet. Kopiere die Topic-Zeichenfolgen. Verlass dich nicht auf dein Gedächtnis. MQTT-Topic-Namen unterscheiden zwischen Groß- und Kleinschreibung. Ein falsch gesetzter Schrägstrich, ein Leerzeichen oder eine abweichende Topic-Ebene führt zu einem anderen Ziel.
Gib jedem Topic eine klar begrenzte Bedeutung. lab/nas/availability und lab/nas/status klingen vielleicht austauschbar, sind aber unterschiedliche Topics. Ein Topic, das einen Dienststatus meldet, sollte auch nicht nebenbei zum Befehls-Topic werden. Wenn du Ereignisse, Zustände und Befehle trennst, kannst du jede Bedeutung einzeln testen.
Die MQTT-Spezifikation definiert Topics und Subscriptions als Konzepte des Protokolls. OASIS MQTT Version 5.0 Sie legt keine allgemeingültige Bedeutung für Topic-Namen fest. Diese ergibt sich aus der Konfiguration von Publisher und Subscriber in deiner Installation.
Die tatsächliche Subscription in Home Assistant
Mit der MQTT-Integration von Home Assistant kannst du während eines Tests ein Topic abonnieren und beobachten. Home Assistant: MQTT Fang mit dem exakten Topic an. Eine vorübergehende Wildcard kann dir in einem kontrollierten Labortest helfen, eine Nachricht zu finden. Nutze sie aber zur Diagnose. Sie ist kein Grund, eine Automation dauerhaft mit einer breit gefassten Subscription laufen zu lassen.
Notiere Topic, Payload und Zeitpunkt der empfangenen Nachricht. Wenn die erwartete Testnachricht nicht auftaucht, vergleiche das notierte Publisher-Topic Zeichen für Zeichen mit dem Topic, auf dem du mitliest. Prüfe danach Broker-Adresse und Port. Geänderte Verbindungseinstellungen beheben keinen Unterschied zwischen zwei Topic-Zeichenfolgen.
Wenn die Nachricht beim Mitlesen ankommt, die Automation aber nicht reagiert, prüfe als Nächstes die Trigger-Konfiguration. Home Assistant dokumentiert MQTT-Trigger getrennt von der Integration selbst. Home Assistant: MQTT-Trigger Das Topic kann passen, während eine Payload- oder Template-Bedingung die Nachricht ausschließt. Die Zustellung an den Listener ist bestätigt, aber damit steht noch nicht fest, warum die Automation kein Ergebnis geliefert hat. Prüfe, ob die Automation aktiviert ist, sowie ihren Trigger, ihre Bedingungen, ihren Ausführungsmodus und ihren Trace.
Ein eigenes Test-Topic und eine harmlose Payload
Teste nicht mit Nachrichten an ein Topic, das Geräte steuert. Lege ein Topic für den vorübergehenden Test an, dessen Name es eindeutig als Labortest kennzeichnet, etwa lab/mqtt-topic-check-2026-10-22. Verwende eine Payload wie test-arrived. Nutze dafür kein Passwort, keine Inventarliste, keine Adresse und keinen realistischen Befehl. Wenn mehrere Personen den Broker verwalten, dokumentiere das Topic, bevor du es verwendest.
Richte einen temporären MQTT-Trigger für genau dieses Test-Topic ein. Wähle als erste Aktion etwas, das du rückgängig machen kannst: eine persistente Benachrichtigung, einen Logbuch-Eintrag oder ein Update eines eigenen Test-Helfers. Bedingungen in Home Assistant steuern, ob eine Automation nach einem Trigger weiterläuft. Home Assistant: Automationsbedingungen Halte die Bedingung so einfach, dass du sie anhand der aufgezeichneten Payload erklären kannst.
Mit dieser Abfolge kannst du häufige Fehler auseinanderhalten:
- Lies in Home Assistant auf dem exakten Labor-Topic mit und notiere die Startzeit.
- Sende von einem Client, den du kontrollierst, eine eindeutig gekennzeichnete Test-Payload.
- Prüfe, ob beim Mitlesen dasselbe Topic und dieselbe Payload angekommen sind.
- Prüfe anhand des Traces und der harmlosen Aktion, ob die in Schritt 2 gesendete Nachricht die temporäre Automation ausgelöst hat.
- Sende eine bewusst abweichende Payload, die die Bedingung ablehnen sollte, und bestätige anschließend, dass keine Aktion ausgeführt wurde.
- Entferne oder deaktiviere die temporäre Automation und verwende das Labor-Topic nach Abschluss der Prüfung nicht mehr.
Damit prüfst du nicht alle Retained-Nachrichten, Broker-Neustarts oder Zustellgarantien. Dafür sind eigene Tests nötig. Der Test zeigt dir nur, ob das angegebene Topic und die Regel zu der Nachricht passen, die du gezielt gesendet hast.
Topic-Abweichungen und Payload-Abweichungen
Wenn beim Mitlesen nichts ankommt, prüfe zuerst das Topic, an das gesendet wird, die Broker-Verbindung und die Subscription. Wenn die erwartete Nachricht ankommt, die Automation aber inaktiv bleibt, liegen die Ursachen eher beim Trigger, der Payload-Bedingung, dem Modus oder einer deaktivierten Automation. Halte diesen Unterschied in deinen Notizen fest. Ändere nicht alle Einstellungen auf einmal.
Vergleiche Payloads genauso sorgfältig wie Topics. Ein Filter, der online erwartet, passt nicht zu Online. Die gesamte Payload als Text zu vergleichen ist etwas anderes, als ein Feld aus geparstem JSON auszulesen und zu vergleichen. Selbst ein unsichtbarer Zeilenumbruch kann bei einem einfachen Vergleich einen Unterschied machen. Lockere einen Filter nicht nur, damit der Test auslöst. Zeichne eine Test-Payload ohne sensible Daten auf, notiere das erwartete Format und passe nur den abweichenden Teil an.
Auch Retained-Nachrichten können das Bild verfälschen. Nach dem Verbindungsaufbau kann ein Subscriber den vom Broker gespeicherten Retained-Wert erhalten, obwohl die Quelle in diesem Moment kein neues Ereignis gesendet hat. Home Assistant dokumentiert das Verhalten der Verfügbarkeitseinstellungen separat. Home Assistant: MQTT-Verfügbarkeit Ein Retained-Zustand kann als letzter bekannter Stand nützlich sein. Er belegt aber nicht, dass ein NAS, Sensor oder Dienst gerade verfügbar ist.
Die vorsichtige Übertragung auf die echte Automation
Wenn du den Übertragungsweg im Labortest verstanden hast, vergleiche ihn Feld für Feld mit der echten Automation: Topic, erwartete Payload, Bedingung und Aktion. Übernimm keine Wildcard oder reine Test-Payload in eine produktive Regel. Wenn eine Aktion die Stromversorgung, Sicherheit, Backups oder Netzwerkkonfiguration verändert, beginne mit einer Benachrichtigung oder einem Log-Eintrag. Prüfe das Ergebnis, bevor du die Aktion mit tatsächlichen Auswirkungen ausführen lässt.
Halte die Testergebnisse kurz fest: Test-Topic, Payload-Format, Zeitpunkt, empfangene Nachricht und ausgeführte Aktion. Wer die Installation später verwaltet, kann damit eine tatsächliche Änderung des Nachrichtenformats von einem Broker-Ausfall oder einer deaktivierten Regel unterscheiden. Die Aufzeichnung hilft auch dabei, ein Gerät nicht allein wegen fehlender Nachweise als ausgefallen einzustufen.
DeviceShelf Server kann Beobachtungen aus einem Netzwerk, das du verwaltest, über MQTT veröffentlichen. Diese Beobachtungen kannst du mit den Aufzeichnungen des Brokers und der Automation abgleichen. Sie beweisen nicht, dass eine Nachricht auf einem Topic zugestellt wurde, dass ein Gerät zweifelsfrei identifiziert ist oder dass eine Automation vollständig durchgelaufen ist. Prüfe jede Beobachtung unabhängig.
Das Ergebnis ist begrenzt, aber überprüfbar: Eine gezielt gesendete Nachricht passte zu einem bewusst konfigurierten Topic und löste eine rückgängig zu machende Aktion aus. Damit hast du eine verlässliche Grundlage, um die nächste Abweichung zu untersuchen, bevor du ein echtes Gerät anfasst.