Mit MQTT Discovery taucht eine Entität schnell in Home Assistant auf. Das ist praktisch, aber eine sichtbare Entitätskarte ist nur der erste Check. Sie allein belegt weder, dass der Publisher noch verbunden ist, noch, dass der Wert aktuell ist oder eine Automatisierung darauf reagieren sollte.
Diese Anleitung beschreibt einen gezielten Test auf einem MQTT-Broker und einer Home-Assistant-Installation, die du verwaltest. Das Ziel ist einfach: Du prüfst, ob eine bekannte Testnachricht die vorgesehene Entität anlegt oder aktualisiert und ob eine harmlose Automatisierung das Update erkennt. Der Test bestätigt weder die korrekte Funktion eines Geräts noch seine Verfügbarkeit und belegt auch nicht, dass eine tatsächliche Aktion ausgeführt wurde.
Discovery und aktueller Zustand
Mit MQTT Discovery in Home Assistant kann ein Publisher Entitäten über MQTT-Konfigurationstopics beschreiben. Home Assistant: MQTT Discovery Die Konfiguration kann ein Zustandstopic, ein Verfügbarkeitstopic und Kennungen enthalten, die Entitäten einem Gerät zuordnen. Diese Felder beschreiben Teile der Integration. Sie prüfen nicht, ob die Quelle ordnungsgemäß läuft.
Eine Entität kann existieren, weil Home Assistant früher eine als Retained gespeicherte Discovery-Konfiguration empfangen hat. Der angezeigte Wert kann ein alter, als Retained gespeicherter Zustand sein. Oder die Entität ist nicht verfügbar, weil ihr Publisher die Verbindung getrennt hat. Prüfe jeden Teil einzeln: Hat Discovery die erwartete Entität angelegt, hat eine Zustandsnachricht sie aktualisiert und hat eine Automatisierung den vorgesehenen Zustandswechsel empfangen?
Notiere das genaue Discovery-Topic, das Zustandstopic, die Entitäts-ID, den erwarteten Testwert und den Testzeitpunkt. Hier kommt es auf die exakten Namen an. Ein Broker interpretiert MQTT-Topics nicht danach, was du damit meinst. Das Protokoll legt fest, wie Zeichenfolgen und Filter übereinstimmen müssen. OASIS MQTT Version 5.0 Ein Discovery-Topic für ein Testgerät und ein Zustandstopic für ein anderes können beide richtig aussehen und trotzdem auf unterschiedliche Pfade verweisen.
Eine eigene Testentität
Ändere zum Einstieg keine entdeckte Entität, die Stromversorgung, Netzwerk, Backups oder Zugriff steuert. Lege auf einem Broker unter deiner Kontrolle eine klar benannte Testentität an oder wähle eine vorhandene aus. Gib ihrem Topic einen Zweck und ein Datum mit, zum Beispiel lab/discovery-check-2026-10-24/state. Zugangsdaten, Adressen und Befehle, die im echten Betrieb etwas auslösen könnten, gehören nicht in die Payload.
Wenn du die Discovery-Konfiguration selbst veröffentlichst, verwende eine unterstützte Komponente wie sensor und ein noch unbenutztes Discovery-Topic mit einer noch unbenutzten Objekt-ID, damit du keine echte Entität ersetzt. Wenn du in der Payload eine unique_id angibst, muss sie sich ebenfalls von denen bestehender Entitäten unterscheiden. Notiere, ob die Konfiguration als Retained gespeichert wird. Das kann für Discovery-Daten sinnvoll sein, ist aber auch der Grund, warum eine Entität nach dem Stoppen des Publishers sichtbar bleiben kann. Wenn du einen Testclient stoppst, wird eine als Retained gespeicherte Konfiguration dadurch nicht entfernt. Plane schon vor dem Test, wie du sie aufräumst.
Damit der Testsensor einem Gerät zugeordnet wird, gib eine eindeutige unique_id und gültige device-Informationen mit identifiers oder connections an. Du kannst dir die Geräte- und Entitätsansichten ansehen, aber die Oberfläche überprüft die beschreibenden Angaben des Publishers nicht. Home Assistant: MQTT Discovery Verwende sachliche Namen für den Test. „MQTT-Discovery-Testentität“ sagt mehr aus als ein Name, der nahelegt, ein bestimmtes NAS, ein Sensor oder ein Dienst sei bereits bestätigt.
Entitätsprüfung mit einem bekannten Zustandswechsel
Lass Home Assistant die Discovery-Konfiguration empfangen und suche die Entität anschließend in der MQTT-Integration oder in den Entwicklerwerkzeugen. Notiere ihre Entitäts-ID. Gehe nicht davon aus, dass der Anzeigename diese ID festlegt. Veröffentliche über das konfigurierte Zustandstopic einen einzelnen harmlosen, eindeutigen Zustandswert, etwa check-1, wenn die Entitätskonfiguration Text akzeptiert.
Beobachte den Zustand der Entität und notiere den Zeitpunkt. Wird er korrekt aktualisiert, hast du gezeigt, dass diese Nachricht in dieser Installation zum konfigurierten Pfad passt. Damit ist nicht belegt, dass die Zustellung auch nach einem späteren Broker-Neustart, bei Paketverlust oder in einer anderen Subscriber-Sitzung erfolgt. Wenn sich nichts ändert, vergleiche das konfigurierte Zustandstopic Zeichen für Zeichen mit dem Topic, auf dem du veröffentlicht hast, bevor du allgemeine Broker-Einstellungen änderst.
Wiederhole den Test mit einem bewusst anderen Wert, zum Beispiel check-2. Zwei unterschiedliche Werte sagen mehr aus als das wiederholte Senden desselben Werts. So kannst du ein aktuelles Update besser von einem bereits gespeicherten und angezeigten Retained-Wert unterscheiden. Wenn die Entität ein Value-Template für Zahlen oder JSON verwendet, sende eine dafür gültige Payload. Lockere die Konfiguration nicht nur, damit der Test durchläuft.
Eine Automatisierung zur Beobachtung
Sobald du den Zustandswechsel gesehen hast, lege eine vorübergehende Automatisierung an, die nur die Testentität beobachtet. Ein Zustands-Trigger in Home Assistant kann auf einen bestimmten Zustandswechsel reagieren. Die Dokumentation erklärt auch den Unterschied zwischen dem Zustand einer Entität und einem Attribut. Home Assistant: Zustands-Trigger Verwende den tatsächlichen Zustand der Entität und kein vermutetes Attribut.
Wähle als erste Aktion etwas, das du rückgängig machen kannst. Schreibe einen Logbucheintrag, erstelle eine dauerhafte Benachrichtigung oder setze einen eigens dafür angelegten Testhelfer. Starte bei diesem ersten Test keinen Dienst, boote keinen Host neu und veröffentliche nichts auf einem Befehlstopic. Sende den Testwert einmal und prüfe anschließend den Trace der Automatisierung und ihr harmloses Ergebnis. Wenn sich die Entität aktualisiert, aber kein Trace vorhanden ist, prüfe die Konfiguration der Automatisierung. Wenn ein Trace vorhanden ist, aber die erwartete Aktion fehlt, prüfe die Bedingungen oder die Aktionsfolge.
Ein kurzer Testablauf reicht:
- Notiere das Discovery-Topic, das Zustandstopic, die Entitäts-ID und den erwarteten Testwert.
- Veröffentliche oder überprüfe die Discovery-Konfiguration der Testentität und suche anschließend die daraus entstandene Entität.
- Sende
check-1auf dem exakten Zustandstopic und notiere den Zustand der Entität sowie den Zeitpunkt. - Sende
check-2und prüfe, ob sich der Zustand erneut geändert hat. - Erstelle und aktiviere eine vorübergehende Automatisierung mit einem Zustands-Trigger für den Wechsel der Testentität von
check-1zucheck-2und einer Benachrichtigung oder einem Logeintrag als einziger Aktion. Veröffentliche erneutcheck-1und anschließendcheck-2auf dem exakten Zustandstopic. Prüfe danach, ob der dadurch entstandene Trace der Automatisierung den erwarteten Zustands-Trigger ausweist und ob die Benachrichtigung oder der Logeintrag vorhanden ist. - Deaktiviere oder entferne die Automatisierung und räume die Discovery-Konfiguration der Testentität auf, sobald der Test abgeschlossen ist.
Eine separate Verfügbarkeitsprüfung
Ein Update einer Entität sagt etwas anderes aus als ihre Verfügbarkeit. MQTT Discovery unterstützt eine Verfügbarkeitskonfiguration, aber ein einmal empfangener Zustand belegt nicht, dass der Publisher noch online ist. Auch der Zustand „nicht verfügbar“ verrät dir nicht die Ursache. Das Problem kann an der Broker-Verbindung, einem Verfügbarkeitstopic, einer unpassenden Konfiguration oder am Publisher selbst liegen.
Wenn eine Automatisierung von der Verfügbarkeit abhängt, stelle sicher, dass sie sich auch ohne bestätigte Verfügbarkeit sicher verhält. Bei einem Ablauf mit tatsächlichen Auswirkungen beginnst du mit einer Benachrichtigung, die den beobachteten Entitätszustand und den Zeitpunkt enthält. Prüfe diese Aufzeichnung, bevor du eine echte Aktion hinzufügst. Unterscheide klar zwischen „Home Assistant hat einen Testzustand empfangen“ und „Das Gerät ist für einen Vorgang bereit“.
DeviceShelf Server kann Netzwerkbeobachtungen über MQTT Discovery an eine von dir verwaltete Home-Assistant-Installation exportieren. Dabei kann es Entitäten und Ereignisse bereitstellen, die du zusammen mit den Broker-Aufzeichnungen prüfen kannst. Das belegt aber weder, dass eine entdeckte Entität aktuell ist, noch, dass die Geräteidentität feststeht oder eine Automatisierung abgeschlossen wurde. Prüfe jeden dieser Punkte auf dem konkreten Pfad, den du nutzt.
Das Ergebnis ist bewusst begrenzt: Ein Publisher unter deiner Kontrolle hat zwei unterscheidbare Testzustände erzeugt, Home Assistant hat sie an der vorgesehenen Entität angezeigt und eine vorübergehende Automatisierung hat eine Beobachtung mit einer rückgängig machbaren Aktion festgehalten. Das reicht als Grundlage, um vorsichtig weiterzumachen. Es ist kein Grund, Abonnements auszuweiten oder einer ungetesteten Aktion zu vertrauen.