Opóźnienia sieciowe wpływają na Home Assistant podczas awarii internetu tylko wtedy, gdy nieudane żądanie nadal zależy od ścieżki sieciowej. Lokalna automatyzacja Zigbee może działać szybko, podczas gdy integracja z chmurą czeka na przekroczenie limitu czasu DNS lub TCP; kamera w sieci LAN może działać wolno z powodu przeciążenia Wi-Fi, nawet jeśli awaria u dostawcy internetu nie ma z tym związku.
Kluczowe jest rozróżnienie między utratą połączenia WAN a opóźnieniem w sieci lokalnej. Awaria internetu uniemożliwia dostęp do zasobów zewnętrznych. Opóźnienie wydłuża oczekiwanie na ścieżce, która nadal działa. Niezawodna konfiguracja Home Assistant utrzymuje krytyczne sterowanie na krótkich ścieżkach lokalnych i nie pozwala, aby powolne zależności zdalne wydłużały te ścieżki.
Protokoły lokalne mogą omijać WAN, ale nadal zależą od sieci LAN
Ruch urządzeń Zigbee i Z-Wave nie wymaga publicznego internetu, ale Home Assistant może nadal komunikować się z koordynatorem, brokerem, mostem lub usługą Thread/Z-Wave przez Ethernet albo Wi-Fi. Ta sieć lokalna może generować własne opóźnienia.
Niedawny przewodnik po lokalnym podejściu do Home Assistant podkreśla, że sterowanie niezależne od internetu nadal zależy od tego, czy lokalna infrastruktura pozostaje zasilana i dostępna.
Przetestuj ścieżkę od czujnika do działania przy odłączonym WAN, ale działającej sieci LAN. Następnie osobno obciąż sieć LAN. Dzięki temu nie przypiszesz awarii problemowi z Wi-Fi, przełącznikiem, DNS-em lub mostem.
Przekroczenia czasu DNS mogą powodować opóźnienia bez dużego zużycia przepustowości
Nieudane zapytanie DNS jest niewielkie, ale aplikacja może czekać na ponowienia lub przekroczenie limitu czasu resolvera. Integracje z chmurą, sprawdzanie aktualizacji, powiadomienia lub wywołania zewnętrznych interfejsów API mogą więc czekać kilka sekund, nawet gdy sieć lokalna przesyła bardzo mało danych.
Użytkownicy Home Assistant powiązali awarie automatyzacji z błędami przekroczenia czasu DNS, które pojawiają się dokładnie wtedy, gdy zawodzą żądania zewnętrzne. Wniosek jest prosty: mierz czas rozwiązywania nazw i zachowanie podczas awarii, zamiast oceniać sytuację wyłącznie na podstawie wykorzystania interfejsu.
Podczas utraty WAN zapewnij możliwość rozwiązywania wewnętrznych nazw hostów, jeśli są one wymagane przez lokalne usługi. Nie uzależniaj lokalnego brokera MQTT ani bazy danych od zewnętrznego resolvera, jeśli właściwym źródłem jest lokalny adres lub lokalna strefa DNS.
Sieciowe bramki radiowe mają własny niewielki budżet opóźnień
Koordynator podłączony przez sieć LAN dodaje opóźnienie transportowe w porównaniu z urządzeniem USB podłączonym bezpośrednio, choć w zdrowej sieci może być ono niewielkie. Efekt staje się bardziej widoczny przy słabym Wi-Fi lub przeciążeniu sieci.
Testy Home Assistant dotyczące Z-Wave przez Wi-Fi/PoE wykazały, że transport sieciowy powodował mierzalne opóźnienie w porównaniu z bezpośrednim USB, a przez Wi-Fi opóźnienie było bardziej zmienne.
Nie oznacza to, że radia podłączone przez sieć są domyślnie zawodne. Oznacza to, że ich ścieżka LAN jest częścią budżetu czasowego i należy ją mierzyć niezależnie od dostępności WAN.
Przekroczenia czasu połączeń z chmurą powinny ograniczać funkcje opcjonalne, a nie sterowanie lokalne
Urządzenia działające wyłącznie w chmurze, dane pogodowe, zdalne sterowanie głosowe, dostęp zdalny i zewnętrzne powiadomienia mogą przestać działać podczas awarii. Lokalna automatyzacja staje się wrażliwa na tę awarię dopiero wtedy, gdy czeka na zdalny wynik przed wykonaniem fizycznego działania.
Architektura oparta przede wszystkim na rozwiązaniach lokalnych zaleca utrzymywanie DNS, automatyzacji i krytycznych usług lokalnie, podczas gdy opcjonalne funkcje chmurowe mogą działać niezależnie w trybie ograniczonym.
W przypadku krytycznej reguły wykonaj działanie lokalne jako pierwsze, jeśli zdalne potwierdzenie nie jest wymagane. Traktuj powiadomienie lub analitykę w chmurze jako odgałęzienie drugorzędne, którego awaria nie opóźni zmiany stanu fizycznego.
Mierz opóźnienie na etapie, na którym użytkownik czeka
| Ścieżka | Przydatna metryka | Interpretacja podczas awarii |
|---|---|---|
| Czujnik → Home Assistant | Opóźnienie nadejścia zdarzenia | Ścieżka radiowa/LAN |
| Automatyzacja → urządzenie lokalne | Opóźnienie od usługi do informacji zwrotnej | Transport lokalny |
| DNS → zewnętrzne API | Rozwiązywanie nazwy + przekroczenie czasu | Zależność zewnętrzna |
| Aplikacja zdalna → Home Assistant | Czas pełnego obiegu / ponowne połączenie | Ścieżka WAN lub tunelu |
Model ścieżki dostępu zdalnego firmy ZimaSpace jest przydatnym uzupełnieniem, ponieważ oddziela prywatną sieć LAN od etapów związanych z dostawcą internetu, NAT-em, VPN-em i tunelem, zamiast traktować „sieć” jako jeden element.
Podczas awarii najlepszym rezultatem jest selektywne ograniczenie działania: sterowanie lokalne pozostaje w swoim zwykłym zakresie opóźnień, a połączenia zewnętrzne szybko kończą się niepowodzeniem lub są ponawiane w tle. Jeśli wszystko zwalnia jednocześnie, sprawdź współdzielony DNS, routing, Wi-Fi, niestandardowe integracje i blokujące wywołania sieciowe.
Centrum Technologii i Sztucznej Inteligencji
Więcej do przeczytania

Dlaczego Home Assistant działa inaczej w sieci lokalnej i przy połączeniach zdalnych?
Sesje Home Assistant w sieci LAN i zdalne korzystają z różnych ścieżek sieciowych; opóźnienie zdalne obejmuje DNS, szyfrowanie, sieć WAN, serwer proxy lub VPN...

Czy Home Assistant działa niezawodnie za CGNAT-em lub podwójnym NAT-em?
CGNAT i podwójny NAT zazwyczaj nie wpływają na lokalne sterowanie Home Assistantem; zmieniają głównie sposób, w jaki zdalni klienci mogą utworzyć ścieżkę przychodzącą do...

Czym są role trwałych danych Home Assistant i dlaczego mają znaczenie?
Trwałość danych Home Assistant nie ogranicza się do jednego folderu ani jednej bazy danych: konfiguracja, rejestry, historia, sekrety, kopie zapasowe i definicje środowiska uruchomieniowego...

