Ein Router-Neustart unterbricht das Netzwerk kurz und kann dabei vieles gleichzeitig betreffen. WLAN-Clients können sich neu verbinden, Clients können die Gültigkeit ihrer DHCP-Leases erneut prüfen oder diese erneuern, und Integrationen können vorübergehend die Verbindung verlieren. Entitäten in Home Assistant können vorübergehend den Zustand unknown oder unavailable annehmen, bevor sie wieder einen stabilen Zustand melden. Wenn eine Automation jeden anschließenden Zustand als tatsächliches Ereignis wertet, kann das Wiederverbinden so aussehen, als hätte jemand das Haus verlassen, ein Türsensor seinen Zustand geändert oder ein Gerät sich wieder verbunden.
Dieser Leitfaden richtet sich an dich, wenn du die Home-Assistant-Instanz und das Netzwerk selbst verwaltest. Er zeigt dir, wie du unerwünschte Aktionen nach einer geplanten oder ungeplanten Netzwerkunterbrechung reduzieren kannst. Er macht eine Automation nicht bei jedem Ausfall ausfallsicher. Alarme, Schlösser, Heizgeräte und andere Aktionen mit weitreichenden Folgen musst du weiterhin unter deinen eigenen Bedingungen testen.
Die Trigger-Referenz von Home Assistant beschreibt das Verhalten der Zustände unknown und unavailable. Prüfe nach einer Netzwerkunterbrechung den Zustandswechsel selbst, nicht nur den Zustand, den die Entität am Ende wieder meldet. Die passende Referenz findest du unter Verhalten der Zustände unavailable und unknown bei Triggern.
Zustandswechsel beim Wiederverbinden und tatsächliche Ereignisse
Eine Automation besteht aus drei Teilen. Ein Trigger startet sie, Bedingungen entscheiden, ob sie fortgesetzt werden darf, und Aktionen führen die eigentlichen Aufgaben aus. Home Assistant dokumentiert diesen Ablauf ausdrücklich. Wenn nach einem Neustart eine Aktion ausgeführt wird, sind die Dokumentationen zu Automation-Triggern und Bedingungen deshalb ein guter Ausgangspunkt.
Angenommen, eine Anwesenheitsgruppe wechselt normalerweise von home zu not_home, wenn die letzte Person das Haus verlässt. Bei einem Router-Neustart könnte die Abfolge stattdessen so aussehen:
home → unavailable → not_home → homeDie Zustände dazwischen stehen für unvollständige Informationen. Sie bedeuten nicht unbedingt, dass jemand das Haus verlassen hat. Ein Trigger, der nur vorgibt „ausführen, sobald die Gruppe not_home meldet“, kann für eine Aktion wie das Scharfschalten einer Alarmanlage zu unspezifisch sein. Ohne weiteren Kontext kann er einen direkten Wechsel beim Verlassen des Hauses nicht von den Zustandswechseln beim Wiederverbinden unterscheiden.
Öffne vor Änderungen am YAML den Trace der Automation oder das Logbuch. Notiere den genauen alten und neuen Zustand, die Uhrzeit, den Trigger und die Aktion. Halte auch fest, ob der Router, der Home-Assistant-Host, der Access Point oder eine bestimmte Integration neu gestartet wurde. Eine einzelne Beobachtung reicht nicht aus, um die Ursache zu bestimmen. Sie verhindert aber, dass du die Konfiguration aufgrund einer bloß vermuteten Abfolge änderst.
Explizite Zustandswechsel
Bei einer zustandsbasierten Automation kann ein from-Wert als einfache Absicherung helfen. Wenn dich der direkte Wechsel einer Gruppe von home zu not_home interessiert, gib genau diesen Wechsel an, statt die Automation jedes Mal auszulösen, wenn die Gruppe not_home erreicht.
triggers:
- trigger: state
entity_id: group.household
from: "home"
to: "not_home"Der Entitätsname ist hier ein Platzhalter. Prüfe die Entität in deiner eigenen Instanz, bevor du ihn ersetzt. Das Beispiel enthält bewusst keine Aktion: Während des Tests ist eine Benachrichtigung sicherer als eine Aktion, die sich nicht rückgängig machen lässt.
Die Felder from und to legen genauer fest, wann der Trigger auslöst. Ohne diese Einschränkung kann ein Zustands-Trigger beim passenden neuen Zustand auch dann auslösen, wenn der vorherige Zustand unknown oder unavailable war. Die Trigger-Dokumentation von Home Assistant enthält Beispiele für Zustands-Trigger und erklärt, dass der Trigger die Automation startet, bevor die Bedingungen geprüft werden. Mehr dazu findest du in der Referenz zu Zustands-Triggern.
Dieses Muster passt nicht zu jeder Automation. Ein Licht, das sich immer einschalten soll, sobald ein Bewegungssensor on meldet, braucht möglicherweise keinen from-Zustand. Bei einer Anwesenheits- oder Sicherheitsautomation ist er dagegen oft sinnvoll: Ein Zustandswechsel beim Wiederverbinden hat eine andere Bedeutung als das normale Ereignis.
Kurze Stabilitätsprüfungen vor wichtigen Aktionen
Die Prüfung auf einen direkten Zustandswechsel hilft, aber ein Gerät kann auch nach der Wiederherstellung der Netzwerkverbindung noch einen vorübergehenden Wert melden. Bei einer wichtigen Aktion solltest du überlegen, ob der relevante Zustand für eine kurze, von dir festgelegte Zeit bestehen bleiben muss. Home Assistant unterstützt for bei Zustands-Triggern und Bedingungen. Bei einem Zustands-Trigger wartet for vor dem Auslösen; bei einer Zustandsbedingung prüft for sofort, wie lange der Zustand bereits besteht, und wartet nicht. Noch laufende Wartezeiten von Triggern werden bei einem Neustart von Home Assistant oder beim Neuladen der Automationen zurückgesetzt. Richte die Dauer nach dem normalen Verhalten der Entität aus, statt irgendeinen vermeintlich passenden Wert zu wählen. Die Dokumentation zum Halten eines Zustands oder Attributwerts erklärt die Abwägung.
Eine Anwesenheitsgruppe, die nach dem Wiederverbinden des Routers kurz not_home meldet, sollte beispielsweise nicht allein deshalb eine Alarmanlage scharfschalten, weil dieser Zustand einige Sekunden lang bestand. Eine Verzögerung von zehn Minuten kann für einen Haushalt passen und für einen anderen untragbar sein. Während dieser Verzögerung könnte tatsächlich jemand das Haus verlassen. Nach Ablauf der Verzögerung sollte die Automation vor der Aktion trotzdem noch einmal den aktuellen Zustand prüfen.
Ein vorsichtiger Testablauf:
- Ersetze die Aktion durch eine dauerhafte Benachrichtigung oder einen Logeintrag.
- Starte jeweils nur den Router oder den Access Point neu, und zwar zu einem Zeitpunkt, an dem eine Fehlauslösung keine Folgen hat.
- Prüfe im Trace die tatsächliche Zustandsfolge.
- Wiederhole den Test mit dem normalen Verlassen des Hauses.
- Stelle die eigentliche Aktion erst wieder her, wenn du beide Abläufe verstehst.
Teste nicht, indem du Schlösser, Alarmanlagen oder Heizgeräte wiederholt vom Strom trennst und wieder einschaltest. Der Test soll dir Aufschluss über die Automation geben, ohne ein neues Sicherheitsproblem zu schaffen.
Nicht verfügbare Zustände und fehlende Anhaltspunkte
Eine Bedingung, die unknown und unavailable einfach ausschließt, wirkt zunächst wie eine einfache Lösung. Das kann sinnvoll sein, sagt dir aber nur, welchen Zustand die Entität zum Zeitpunkt der Prüfung hat. Daraus geht nicht hervor, ob das Wiederverbinden, das tatsächliche Verlassen des Hauses oder das unabhängige Neuladen einer Integration die Automation ausgelöst hat.
Wenn du ein Template brauchst, halte es kurz und lesbar. Die Dokumentation zu Templates in Automationen von Home Assistant beschreibt die dort verfügbaren Template-Funktionen. Eine Bedingung kann beispielsweise einen fehlenden Zustand ausschließen:
conditions:
- condition: template
value_template: >-
{{ states('group.household') not in ['unknown', 'unavailable'] }}Diese Absicherung beweist nicht, dass alle das Haus verlassen haben. Kombiniere sie mit dem direkten from/to-Wechsel, wenn das deiner gewünschten Regel entspricht. Falls die Automation die Anwesenheit ausschließlich über WLAN ermittelt, überlege, ob eine Aktion mit weitreichenden Folgen eine zweite, unabhängige Quelle für die Anwesenheitserkennung oder eine manuelle Bestätigung braucht. Diese Entscheidung müsst ihr im Haushalt treffen. Dafür gibt es keinen allgemein passenden YAML-Schnipsel.
Gleichzeitige Ausführungen und Neustartverhalten
Nach einem Ausfall können mehrere Entitäten kurz nacheinander wieder verfügbar werden. Dieselbe Automation kann erneut auslösen, während sie noch wartet. Ihr Modus bestimmt dann, was als Nächstes passiert. Home Assistant dokumentiert die Modi single, restart, queued und parallel und beschreibt, wie jeder davon mit einem neuen Trigger umgeht. Sieh dir die Automationsmodi an, bevor du Verzögerungen oder Wiederholungsversuche einbaust.
Mehrere Benachrichtigungen in der Warteschlange sind vielleicht nur lästig. Wird eine Aktion wiederholt ausgeführt, die Sicherheit oder Komfort beeinflusst, kann das dagegen verwirrend sein. Wähle den Modus danach aus, was passieren soll, wenn ein zweites gültiges Ereignis eintritt, während der erste Durchlauf noch läuft. Eine Warnung loszuwerden reicht als Grund für die Wahl nicht aus.
Prüfe auch die Integration, von der die Entität stammt. Router- und Cloud-Integrationen können unterschiedlich lange brauchen, bis sie wieder verbunden sind. Eine statische Adresse, eine DHCP-Reservierung oder ein längeres Timeout der Integration kann ein Verbindungsproblem beheben. Nimm solche Änderungen aber nicht nur vor, damit kein Automation-Trace mehr auftaucht. Stelle vor Änderungen an der Adressierung sicher, dass die Adresse nicht mit DHCP-Zuweisungen kollidieren kann, und halte eine lokale Möglichkeit zur Wiederherstellung des Zugriffs bereit; falsche Einstellungen können das Gerät unerreichbar machen. Kläre zuerst, ob die Entität tatsächlich nicht erreichbar ist, sich ihre Adresse geändert hat oder sie einen vorübergehenden Zustand meldet, während sich die Integration neu verbindet.
Kurzes Protokoll der Wiederherstellung
Notiere das Datum, die neu gestartete Komponente, die Zustandsfolge und das Ergebnis der Automation. Wenn das Problem wieder auftritt, hilft dir dieses Protokoll mehr als ein Screenshot des abschließenden Dashboard-Zustands. Es hilft auch dabei, einen Router-Neustart von einem Home-Assistant-Neustart oder einem einzelnen unzuverlässigen Gerät zu unterscheiden.
Ein lokales Tool zur Netzwerkinventarisierung oder Überwachung wie DeviceShelf kann dir für ein von dir verwaltetes Netzwerk eine weitere Beobachtungsquelle liefern. Es kann dir helfen, den Zeitpunkt, zu dem ein Host wieder erreichbar war, mit dem Ablauf der Automation abzugleichen. Es kann weder erklären, warum Home Assistant einen bestimmten Zustand gesetzt hat, noch den Trace von Home Assistant ersetzen. Nutze es als zusätzlichen Anhaltspunkt, nicht als abschließenden Befund.
Du musst nicht jeden unavailable-Zustand verhindern. Die Automation sollte auf den Zustandswechsel reagieren, der das tatsächliche Ereignis abbildet, nur aus gutem Grund warten und beim Wiederherstellen der Netzwerkverbindung einen nachvollziehbaren Trace hinterlassen.