← Alle Beiträge English

MQTT-Availability-Topics: Erst die Bedeutung eines Offline-Status prüfen

Eine MQTT-Entität in Home Assistant kann genau dann unavailable anzeigen, wenn es auf eine Automation ankommt. Das ist ein hilfreicher Hinweis, verrät dir aber nicht, was schiefgelaufen ist. Ein Sensor könnte keinen Strom mehr haben, ein Publisher die Verbindung verloren haben, der Broker könnte eine Verbindung abgelehnt haben oder ein Topic könnte falsch konfiguriert sein.

Diese Anleitung beschreibt einen kleinen Test auf einem Broker und einer Home-Assistant-Installation, die du selbst verwaltest. Das Ziel ist klar begrenzt: Prüfe, wie ein bekannter Publisher eine Testentität zwischen verfügbar und nicht verfügbar umschaltet. Lass anschließend eine harmlose Automation die Änderung beobachten. Der Test bestätigt weder die Identität eines Geräts noch seine künftige Verfügbarkeit. Er belegt auch nicht, dass eine Aktion in der realen Welt tatsächlich stattgefunden hat.

Die Bedeutung eines Availability-Topics

Für MQTT Discovery und MQTT-Entitäten lassen sich Angaben zur Verfügbarkeit konfigurieren. In einem typischen Setup sendet ein Publisher eine Payload wie online oder offline an ein Availability-Topic. Die Entität ordnet diese Werte ihrem Verfügbarkeitsstatus zu. Home Assistant dokumentiert die MQTT-Optionen zur Verfügbarkeit, darunter ein optionales Availability-Topic und die Payload-Werte. Home Assistant: MQTT-Integration

Entscheidend ist das Wort konfiguriert. Wenn eine Entität als nicht verfügbar angezeigt wird, hat Home Assistant in dieser Installation eine Bedingung erkannt, die laut Konfiguration dazu führt. Die Ursache erklärt das nicht. Eine mit Retain gespeicherte offline-Nachricht kann nach einer früheren Trennung noch vorhanden sein. Eine gerade gesendete offline-Nachricht kann dagegen bewusst eine Wartung ankündigen. Eine fehlende Nachricht kann auf ein falsches Topic oder einen tatsächlichen Ausfall hindeuten.

Das sind getrennte Fragen: Hat Home Assistant die gewünschte Entität angelegt? Hat ein bekannter Publisher exakt die konfigurierte Availability-Payload gesendet? Hat sich die Entität geändert? Hat eine Automation die Änderung erkannt? Für jede Antwort brauchst du einen eigenen Beleg. MQTT-Topics sind Zeichenketten, die Clients nach den Topic- und Filterregeln des Protokolls abgleichen. Ein Name, der richtig aussieht, reicht nicht aus. OASIS MQTT Version 5.0

Eine abgegrenzte Testumgebung

Fang nicht mit dem Availability-Topic eines NAS, Routers, Backup-Dienstes oder einer Stromsteuerung an. Nutze einen Broker und einen Namensraum unter deiner Kontrolle, mit einem eindeutig vorläufigen Namen wie lab/availability-check-2026-10-26/status. Schreibe keine Zugangsdaten oder privaten Adressen in Test-Payloads oder geteilte Aufzeichnungen und sende keine Befehls-Payloads.

Lege eine einfache MQTT-Testentität oder eine Discovery-Konfiguration mit einer eindeutigen Objekt-ID an. Halte vor dem ersten Senden Folgendes fest:

  1. Das genaue Availability-Topic und die Payloads, die verfügbar und nicht verfügbar zugeordnet sind.
  2. Ob die Availability-Nachricht mit Retain gespeichert wird.
  3. Die Entitäts-ID, die Home Assistant tatsächlich vergeben hat.
  4. Die Uhrzeit und den verwendeten Client für jede Testnachricht.

Achte auf Retain. Der Broker liefert gespeicherte Retain-Nachrichten auch an Clients aus, die das Topic erst später abonnieren. Für ein Status-Topic kann das hilfreich sein. Wenn du einen Publisher stoppst, verschwindet dadurch aber nicht sein zuletzt mit Retain gespeicherter Status. Kläre vor dem Ändern einer Retain-Testnachricht, wie du hinterher aufräumst. Lösche nach dem Test den gespeicherten Testwert, sofern das für den von dir verwalteten Broker sinnvoll ist.

Tests in beide Richtungen

Sende vom bekannten Test-Publisher die konfigurierte Payload für verfügbar. Suche die Entität in Home Assistant und notiere ihren Zustand und die Uhrzeit. Sende danach die konfigurierte Payload für nicht verfügbar. Verwende nur dann einen anderen, ausdrücklich für den Test vorgesehenen Wert, wenn die Entitätskonfiguration ihn zuordnet. Sonst prüfst du womöglich einen Fehler beim Auswerten der Payload statt der Verfügbarkeit.

Prüfe, ob sich der Zustand in der vorgesehenen Reihenfolge ändert. Falls nicht, gleiche zuerst Topic, Schreibweise der Payload, Groß- und Kleinschreibung sowie die Retain-Einstellung ab, bevor du Verbindungseinstellungen änderst oder Dienste neu startest. Ändere immer nur eine Variable, damit der Test aussagekräftig bleibt. Wenn du zum Beispiel erst online, dann offline und anschließend wieder online sendest, erkennst du leichter, ob die Entität aktuelle Nachrichten abbildet oder noch einen früheren Retain-Wert anzeigt.

Auch das State-Topic und das Availability-Topic eines MQTT-Sensors sind getrennte Wege. Die Dokumentation zu MQTT-Sensoren in Home Assistant beschreibt Zustand und Verfügbarkeit separat. Home Assistant: MQTT-Sensor Ein aktueller Zustandswert kann auch dann vorliegen, wenn die Entität als nicht verfügbar gilt. Geh nicht davon aus, dass ein alter Zustand aktuell ist, nur weil er noch angezeigt wird.

Beobachtung vor Aktion

Sobald sich die Testentität wie erwartet ändert, lege eine vorübergehende Automation an, die nur eine Beobachtung festhält. Ein MQTT-Trigger kann auf ein Topic und optional eine bestimmte Payload reagieren. Eine zustandsbasierte Automation kann den daraus entstehenden Zustand der Entität beobachten. Wähle die Variante, die zu dem passt, was du prüfen willst. Home Assistant: MQTT-Trigger

Nutze für diesen ersten Durchlauf als Aktion eine dauerhafte Benachrichtigung, einen Logbucheintrag oder einen eigens angelegten Helfer. Starte keinen Host neu, schalte keine Stromversorgung, ändere keinen Netzwerkzugriff und sende nichts an ein Befehls-Topic. Sende bei aktivierter Testautomation zuerst die konfigurierte Payload für verfügbar und prüfe, dass die Entität nicht mehr unavailable ist. Sende danach einmal die konfigurierte Payload für nicht verfügbar und prüfe anschließend den Automation-Trace und das harmlose Ergebnis. Die Anleitung zur Fehlersuche in Home Assistant erklärt, wie du mit Traces unterscheiden kannst, ob ein Trigger nicht ausgelöst hat oder eine Bedingung beziehungsweise Aktion anders als erwartet ablief. Home Assistant: Fehlersuche bei Automationen

Wenn sich die Entität ändert, aber kein Trace vorliegt, prüfe das Ziel der Automation und den Trigger-Typ. Wenn ein Trace vorliegt, aber die erwartete Benachrichtigung oder das Update des Helfers fehlt, prüfe die Bedingungen und den Ablauf der Aktionen. Keines dieser Ergebnisse belegt, ob ein Gerät im Produktivbetrieb verfügbar ist. Du grenzt damit ein Konfigurationsproblem in einem kontrollierten Test ein.

Ein Offline-Ereignis als Ausgangspunkt

Im Produktivbetrieb ist es meist ein sicherer erster Schritt, bei einem nicht verfügbaren Zustand die Entitäts-ID, den beobachteten Wert und die Uhrzeit zu protokollieren. Gleiche dann das Broker-Log, das Log des Publishers und den Status relevanter Dienste jeweils separat ab. Mach eine Availability-Nachricht nicht zur einzigen Bedingung für eine Aktion mit weitreichenden Folgen.

Das ist besonders nach Broker-Neustarts und Wartungsarbeiten wichtig. Home Assistant kann neu starten, bevor sich ein Publisher wieder verbindet und einen Wert für verfügbar sendet. Ein gespeicherter Retain-Wert kann ebenfalls eintreffen, bevor der Publisher seine eigenen Prüfungen abgeschlossen hat. Setze eine Verzögerung oder eine zweite unabhängige Beobachtung nur ein, wenn du erklären kannst, wogegen sie absichert. Ein längeres Timeout verrät dir nicht, was den Ausfall verursacht hat.

DeviceShelf Server kann Netzwerkbeobachtungen über MQTT Discovery an eine von dir verwaltete Home-Assistant-Installation exportieren. Damit hast du eine weitere Beobachtung, die du mit den Broker-Aufzeichnungen abgleichen kannst. Eine nicht verfügbare Entität beweist weiterhin weder, dass ein Gerät verschwunden ist, noch zeigt sie einen bestimmten Netzwerkfehler oder bestätigt eine Wiederherstellungsaktion. Behandle ihre Verfügbarkeitsangaben und das Ergebnis einer Automation als getrennte Beobachtungen.

Aufräumen nach dem Test

Deaktiviere oder entferne die vorübergehende Automation, die Entität und die mit Retain gespeicherte Testkonfiguration passend zu deinem Setup. Prüfe, dass das Test-Topic keine produktive Automation mehr beeinflussen kann. Halte Topic-Namen, Payloads, Entitäts-ID und Trace-Ergebnis kurz fest. Lass dabei Geheimnisse und Details zum echten Netzwerk weg.

Der Erfolg ist hier bewusst begrenzt: Ein bekannter Test-Publisher hat eine konfigurierte Entität zwischen zwei Verfügbarkeitszuständen umgeschaltet, und Home Assistant hat eine rückgängig zu machende Reaktion protokolliert. Das reicht als Beleg, um zu entscheiden, ob die Konfiguration noch Arbeit braucht, bevor du sie mit einer folgenreichen Aktion verknüpfst.

Geprüfte Quellen

Netzwerk-Tipps und Produkt-Updates

Gelegentlich ein Guide, neue Features und Release-News, direkt in dein Postfach. Kein Spam, jederzeit abbestellbar.