Jak rolety mają przetrwać restart Home Assistant, Wi-Fi Shelly i Ethernet boneIO

Prawdziwy system trzeba oceniać w chwili awarii, nie tylko wtedy, gdy wszystko jest online. Lekcja blokuje wykonanie na niepewnych danych, rozróżnia HA, LAN, Wi-Fi i zasilanie sterownika oraz usuwa niebezpieczne nadrabianie starych decyzji po reconnect.

Wyobraź sobie prostą sytuację. O 14:00 R04 powinna zejść do 35%, ale Shelly R04 akurat traci Wi-Fi. O 14:20 słońce chowa się za budynkiem i decyzja termiczna wraca do neutralnej. O 14:30 Wi-Fi wraca. Najgorsze, co możemy zrobić, to potraktować sam powrót urządzenia jako powód do wykonania komendy, która była sensowna pół godziny wcześniej. Dlatego w tym LAB-ie odzyskanie łączności oznacza tylko jedno: urządzenie znowu może być brane pod uwagę. Nie oznacza: „wykonaj ostatnie polecenie”, „przywróć noc”, „otwórz rano” ani „zjedź do 35%”. Ruch nastąpi później po prawdziwej zmianie warunków albo po świadomym użyciu przycisku synchronizacji po awarii.

Ten fragment zastępuje wcześniejszy, szeroki trigger na sensor.r04_decyzja_termiczna_rolety. Gdy sensor przejdzie z neutralny do chron_przed_sloncem, automatyzacja nadal się uruchomi. Gdy natomiast po awarii wróci z unavailable do chron_przed_sloncem, trigger zostanie zignorowany.

R08 nie korzysta z decyzji termicznej L20. Jej automatyka dobowa potrzebuje przede wszystkim wiarygodnej pozycji cover oraz poprawnej informacji, czy trwa pora prywatności. Dlatego sensor R08 nie wymaga prognozy, PV ani temperatury łazienki. Nie dokładamy zależności tylko dlatego, że dane istnieją.

To osobny test. Przy włączonym boneIO wyjmij patchcord Ethernet po stronie switcha lub sterownika. Nie dotykasz przewodów 230 V ani zasilania 24 V. Home Assistant straci komunikację z całym kontrolerem, więc wszystkie osiem encji cover boneIO może stać się niedostępnych. Lokalne IN01-IN19 i logika zapisane w ESPHome nadal działają w samym sterowniku. Web panel z innego urządzenia sieciowego oczywiście przestanie być dostępny, bo właśnie odłączyliśmy interfejs sieciowy. To nie jest awaria logiki lokalnej, tylko utrata transportu sieciowego.

Dodaj ten trigger do każdej automatyzacji wykonawczej R01-R07. Naciśnięcie przycisku wybudzi wszystkie siedem automatyzacji, ale każda nadal przejdzie przez swoje warunki: globalną zgodę termiczną, ręczny timer, rolety_termika_dozwolona oraz nowy sensor Rxx wykonanie gotowe. Sam przycisk nie omija zabezpieczeń.

R01 pozostaje wyjątkiem. Sensor gotowości R01 wymaga, aby binary_sensor.r01_drzwi_otwarte miał jednoznaczny stan ON lub OFF. Jeżeli kontaktron jest unknown albo unavailable, R01 wykonanie gotowe pozostaje OFF. W takim stanie automatyka nie ma prawa uznać, że drzwi „pewnie są zamknięte”.

Na czas commissioning potrzebujemy jednego ekranu, na którym widać nie tylko pozycję rolety, ale również prawo automatyki do ruchu. Poniższy YAML używa wyłącznie standardowych kart. Dla ścieżki Shelly dodaj pod spodem włączone sensory RSSI, Uptime i Device temperature każdego urządzenia. Dla boneIO możesz dodać dostępne encje diagnostyczne ESPHome oraz link do lokalnego panelu urządzenia w swojej dokumentacji technicznej.

• not_from / not_to dla unknown i unavailable
• 60 sekund stabilizacji po reconnect
• RXX wykonanie gotowe osobno dla każdej rolety
• Synchronizuj po awarii zamiast nadrabiania starych komend
• Najważniejsza zasada: po awarii nie nadrabiamy przeszłości
• Rozdzielamy trzy rodzaje awarii
• Co ma działać, kiedy Home Assistant jest wyłączony
• unknown i unavailable nie znaczą tego samego
• Dlaczego float(0) bywa niebezpieczny w decyzjach wykonawczych
• Przed zmianami zapisujemy aktualny stan instalacji
• Najpierw poprawiamy triggery z L21
• Poprawka triggera sensora decyzji R04
• Tak samo poprawiamy stabilną ochronę
• Dlaczego nie dodajemy triggera „urządzenie znowu dostępne”
• Budujemy warstwę „wykonanie gotowe” dla R01-R08
• Pełny YAML sensorów gotowości

Nie przeskakujemy od teorii prosto do gotowego efektu. Zaczynamy od not_from / not_to dla unknown i unavailable, następnie porządkujemy 60 sekund stabilizacji po reconnect i dopiero później przechodzimy do RXX wykonanie gotowe osobno dla każdej rolety. W praktycznym systemie rolet kolejność ma znaczenie: błąd z początku konfiguracji może wyglądać jak problem Home Assistant dopiero kilka etapów później. Dlatego materiał pokazuje nie tylko co ustawić, ale również po czym rozpoznać poprawny rezultat i kiedy zatrzymać się przed następnym krokiem.

Pełna lekcja łączy wykonanie z diagnostyką. Po drodze wracamy do takich punktów jak Synchronizuj po awarii zamiast nadrabiania starych komend oraz Najważniejsza zasada: po awarii nie nadrabiamy przeszłości. Nie zakładamy, że identyczne ustawienie będzie poprawne w każdym domu. Tam, gdzie wynik zależy od napędu, instalacji, kierunku elewacji, czasu ruchu lub zachowania domowników, dostajesz procedurę pomiaru i strojenia zamiast jednej „magicznej” liczby do skopiowania.

Na końcu etap musi dać się zweryfikować. Jeśli wynik jest inny niż opisany, pełna wersja prowadzi przez sprawdzenie przyczyny przed dołożeniem kolejnej warstwy. Dzięki temu następne lekcje opierają się na sprawdzonym fundamencie, a nie na przypadkowo działającej konfiguracji, która psuje się przy pierwszym restarcie, zmianie pogody albo użyciu fizycznego przycisku.

Zbudujesz warstwę gotowości wykonawczej R01-R08, poprawisz triggery z L21 tak, aby powrót z unknown lub unavailable nie uruchamiał silnika, dodasz diagnostykę awarii trwającej dłużej niż dwie minuty, uruchomisz przycisk świadomej synchronizacji po awarii, wykonasz kontrolowane testy utraty HA, Wi-Fi i Ethernetu oraz sprawdzisz ustawienia Shelly i boneIO związane z zachowaniem po restarcie. Po tej lekcji utrata komunikacji nie jest już przypadkiem „zobaczymy, co się stanie”.

Ta lekcja jest częścią kursu Smart Home od Zera na platformie MarkLabs E-Learning. Pełna wersja prowadzi przez konfigurację, testy, diagnostykę i przypadki awaryjne bez zostawiania Cię z poleceniem „skonfiguruj to sam”.