Ein Internetausfall führt nicht automatisch dazu, dass lokale Automationen in Home Assistant ausfallen. Lokale Zigbee-, Z-Wave-, Matter-, ESPHome-, MQTT- und LAN-Integrationen können weiterarbeiten, während die WAN-Verbindung unterbrochen ist. Was sich ändert, ist die damit verbundene Arbeitslast: Cloud-Anfragen laufen in Timeouts, Integrationen wiederholen Anfragen, DNS-Auflösungen schlagen fehl, Remote-Verbindungen verschwinden, und sobald die Verbindung wiederhergestellt ist, kann die Verarbeitung schubweise einsetzen.
Die Ressourcenplanung ist während eines Ausfalls daher auch dann wichtig, wenn der lokale Steuerungspfad intakt bleibt. Die Frage lautet nicht: „Benötigt Home Assistant das Internet?“ Entscheidend ist, ob fehlgeschlagene Remote-Aufgaben isoliert bleiben oder Zeit im Event-Loop, Executor-Threads, DNS-Kapazität, I/O für Protokolle oder das Neuladen von Integrationen beanspruchen und dadurch mit der lokalen Steuerung in Konflikt geraten.
Fehlgeschlagene Cloud-Anfragen machen schnelle Erfolgswege zu Timeout-Wegen
Wenn das WAN fehlerfrei funktioniert, kann eine Cloud-Anfrage schnell abgeschlossen sein. Während eines Ausfalls kann derselbe Aufruf jedoch das gesamte Timeout-Fenster beanspruchen, wiederholt werden und vor der Rückgabe einen Fehler protokollieren. Einige wenige Aufrufe sind unproblematisch; wenn viele Integrationen dies gleichzeitig tun, entsteht ein anderes Planungsprofil als im Normalbetrieb.
Der Lebenszyklus von Konfigurationseinträgen in Home Assistant verfügt ausdrücklich über einen setup retry-Status für Abhängigkeiten, die noch nicht bereit sind; dabei verlängert sich das Intervall zwischen automatischen Versuchen im Laufe der Zeit. Der genaue Fehlerfall hängt weiterhin von der jeweiligen Integration ab, aber Wiederholungsversuche sind ein definierter Bestandteil des eingeschränkten Betriebs und kein außergewöhnlicher Sonderfall.
Verhindere, dass kritische Automationen auf eine Remote-API warten, bevor sie die lokale Aktion ausführen. Sende die Benachrichtigung, Cloud-Aktualisierung oder den externen Webhook erst nach der physischen Aktion, wenn das Remote-Ergebnis nicht erforderlich ist, um zu entscheiden, was im Haus geschehen soll.
Netzwerk-Timeouts können Ressourcen binden, auch ohne hohe CPU-Auslastung
Ein blockierter Netzwerkvorgang kann nur wenig CPU verbrauchen und dennoch eine Aufgabe, Verbindung, einen Thread oder ein Timeout-Budget belegen. Deshalb beweist eine CPU-Auslastung von lediglich 10 % nicht, dass ein Ausfall kostenlos ist.
Ein Fall aus Home Assistant aus dem Jahr 2026 führte wiederholte Integrations-Timeouts und kaskadierende Neuladungen auf einen fehlerhaften IPv6-Pfad zurück, durch den Verbindungen warten konnten, anstatt schnell fehlzuschlagen. Das Problem war eine Verzögerung bei der Planung rund um Netzwerkaufrufe und keine Erschöpfung der reinen Rechenleistung.
Beobachte ausstehende Netzwerkaufgaben, Integrationswarnungen, DNS-Fehler und die Zeit zwischen dem Auslöser und dem lokalen Serviceaufruf. Bleiben lokale Aktionen schnell, während Cloud-Entitäten nicht verfügbar werden, ist der Ausfall korrekt isoliert. Wenn die Latenz lokaler Aktionen mit fehlgeschlagenen Remote-Aufrufen zunimmt, ermittle, welche Integration oder welcher eigene Code die gemeinsam genutzte Laufzeit blockiert.
Blockierende Arbeit ist gefährlicher als asynchrones Warten
Der Kern von Home Assistant arbeitet asynchron. Gut implementierte Integrationen können während des Wartens auf I/O pausieren und anderen Aufgaben die Ausführung ermöglichen. Gefährlich sind blockierende Vorgänge, die den Event-Loop selbst belegen, oder eigener Code, der synchrone Netzwerkoperationen an der falschen Stelle ausführt.
Die Entwicklerdokumentation von Home Assistant erklärt, dass ein blockierender Vorgang im Event-Loop verhindert, dass andere Arbeiten ausgeführt werden, bis er abgeschlossen ist. Ein Internetausfall kann diese Schwäche sichtbar machen, weil ein Aufruf, der normalerweise sofort zurückkehrt, plötzlich auf ein langes Timeout warten kann.
Deshalb kann eine eigene Integration den Ausfall wie eine Verlangsamung der gesamten Plattform wirken lassen, obwohl native lokale Integrationen weiterhin gut entwickelt sind. Vergleiche das Verhalten mit deaktivierten eigenen Komponenten, bevor du die Hardware verantwortlich machst.
Plane auch für den eingeschränkten Betrieb, nicht nur für den Normalbetrieb
Während eines WAN-Ausfalls sollten lokale Bewegungs-zu-Licht-Abläufe ohne Remote-Voraussetzung weiterlaufen. Cloud-Abfragen können in begrenzte Wiederholungsversuche übergehen, Remote-Benachrichtigungen können fehlschlagen oder in eine Warteschlange gelangen, DNS-abhängige Dienste sollten vorhersehbar ausfallen, und die Rückkehr der Verbindung kann einen kurzen Aktualisierungsschub auslösen.
Das Ziel ist eine selektive Verschlechterung: Optionale Remote-Arbeiten werden langsamer oder fallen weg, während die lokale Steuerung innerhalb ihres normalen Zeitrahmens bleibt. Der aussagekräftigste Ausfalltest besteht darin, die WAN-Verbindung während einer normalen Haushaltsauslastung zu trennen, einige kritische lokale Automationen zu messen und anschließend nach der Wiederherstellung sowohl den Wiederherstellungsschub als auch die Zeit bis zur Rückkehr zum Ausgangsniveau zu messen.
FAQ
Macht ein Internetausfall lokale Automationen in Home Assistant langsamer?
Nicht grundsätzlich. Eine vollständig lokale Automation kann mit normaler Geschwindigkeit weiterlaufen. Sie wird langsamer, wenn fehlgeschlagene Cloud-, DNS-, Integrations- oder gemeinsam genutzte Netzwerkvorgänge Ressourcen auf demselben kritischen Pfad verbrauchen.
Sollte ich aggressive Wiederholungsversuche hinzufügen, damit sich Cloud-Integrationen schneller wieder verbinden?
Nein. Aggressive Wiederholungsversuche können einen Ausfall verstärken und unnötige Arbeit erzeugen. Bevorzuge begrenzte Wiederholungsversuche und halte die Wiederherstellung der Cloud-Verbindung außerhalb des zeitkritischen Pfads kritischer lokaler Automationen.
Tech- & KI-Zentrum
Mehr zum Lesen

Warum funktioniert Home Assistant über LAN- und Remote-Verbindungen unterschiedlich?
LAN- und Remote-Home-Assistant-Sitzungen nutzen unterschiedliche Netzwerkpfade; bei Remote-Verbindungen kommen DNS, Verschlüsselung, WAN, Proxy oder VPN sowie das Verhalten bei erneuten Verbindungen als zusätzliche Latenzquellen...

Funktioniert Home Assistant zuverlässig hinter CGNAT oder doppeltem NAT?
CGNAT und doppeltes NAT beeinträchtigen die lokale Steuerung von Home Assistant normalerweise nicht; sie verändern hauptsächlich, wie externe Clients eine eingehende Verbindung zum Heimnetzwerk...

Wie beeinflusst die Netzwerklatenz Home Assistant während Internetausfällen?
Internetausfall und Netzwerklatenz sind unterschiedliche Fehler: Lokale Gerätepfade können schnell bleiben, während DNS, Cloud-Integrationen, Gateways oder Remote-Clients warten.

