NetGuard Master: WT32-ETH01, Ethernet i inteligentne wykrywanie awarii

NetGuard Power z poprzedniej części potrafi już fizycznie zrestartować zasilanie wybranego urządzenia. Teraz buduję drugą, ważniejszą połowę systemu: NetGuard Master. Zaczynam od gołej płytki WT32-ETH01, podłączam ją do USB–UART, wprowadzam ESP32 w tryb programowania, wgrywam własny firmware, uruchamiam Ethernet, łączę Mastera przez ADuM1201 z SONOFF 4CHR3 i dopiero wtedy konfiguruję monitoring, reguły oraz automatyczne recovery.

Ten etap jest już wykonany i sprawdzony. Master działa na rzeczywistym WT32-ETH01, pracuje po przewodowym LAN, komunikuje się z NetGuard Power, wykonuje testy sieciowe, ocenia reguły i przeprowadza pełny cykl: wykrycie problemu → potwierdzenie awarii → RESET → stabilizacja → ponowny test.

Zaczynam od prawdziwego WT32-ETH01

Masterem NetGuarda jest WT32-ETH01. To niewielka płytka z ESP32 oraz fizycznym interfejsem Ethernet zakończonym gniazdem RJ45.

W tym projekcie wybór nie był przypadkowy. Chciałem kontrolera, który może obserwować domową sieć, ale nie musi korzystać z Wi-Fi.

Fizycznie WT32-ETH01 wygląda zupełnie inaczej niż typowa płytka ESP32 DevKit. Jest wąski, ma RJ45 przy jednym z krótszych boków, moduł WT32-S1 z metalowym ekranem oraz wyprowadzenia wzdłuż obu boków.

Dlaczego nie używam Wi-Fi, skoro ESP32 je ma

Sam ESP32 potrafi pracować po Wi-Fi, ale w NetGuardzie celowo z tego nie korzystam jako podstawowej ścieżki sieciowej.

Załóżmy, że watchdog pracowałby po Wi-Fi i jego zadaniem byłoby wykrywanie awarii punktu dostępowego.

AP się zawiesza.

Master traci połączenie.

I urządzenie, które miało naprawić Wi-Fi, przestaje być częścią sieci dokładnie w tej samej chwili.

Dlatego NetGuard Master pracuje po Ethernet.

To nie sprawia, że staje się odporny na każdą możliwą awarię sieci, ale usuwa jedną bardzo istotną zależność.

Co przygotowałem do pierwszego uruchomienia

Do zaprogramowania Mastera potrzebowałem:

• WT32-ETH01,
• adapter USB–UART pracujący z logiką 3,3 V,
• kilku przewodów Dupont,
• stabilnego zasilania dla WT32-ETH01,
• przewodu Ethernet,
• aktualnego obrazu firmware NetGuard Master z repozytorium.

WT32-ETH01 może być zasilany przez wejście 5 V albo 3,3 V. To są dwie alternatywne metody, a nie dwa zasilania używane jednocześnie.

Na moim stanowisku wykorzystuję stabilne zasilanie płytki, a interfejs UART pozostaje w logice 3,3 V.

Najpierw poznajemy piny programujące

WT32-ETH01 nie ma typowego gniazda USB do programowania, dlatego firmware wgrywam przez UART.

Na płytce interesują mnie przede wszystkim:

TXD i RXD to port programujący ESP32.

IO0 służy do wyboru trybu bootloadera podczas startu.

EN pozwala zresetować układ.

To wystarczy, żeby przejść od fabrycznego firmware do własnego NetGuard Master.

Dokładne połączenie USB–UART z WT32-ETH01

Linie UART, podobnie jak przy SONOFF-ie, krzyżuję:

Do tego dochodzi zasilanie WT32-ETH01.

Jeśli zasilam płytkę przez pin 5 V:

Alternatywnie można korzystać z właściwego zasilania 3,3 V przez wejście 3V3, ale nie łączę obu wejść jednocześnie.

Najważniejsze jest również to, żeby adapter UART nie wysyłał na TX sygnałów logicznych 5 V.

Jak wprowadzam WT32-ETH01 w tryb flashowania

Samo podłączenie RX i TX nie wystarczy.

ESP32 musi wystartować w trybie bootloadera.

W WT32-ETH01 robię to przez IO0.

Po zakończeniu zapisu usuwam połączenie IO0–GND przed normalnym startem.

W WT32-ETH01 ma to dodatkowe znaczenie, ponieważ IO0 nie jest po uruchomieniu zwykłym wolnym GPIO. Jest związany również z pracą interfejsu Ethernet.

Skąd pobieram firmware Mastera

Firmware jest częścią tego samego publicznego projektu co NetGuard Power:

Przy każdym flashowaniu pobieram aktualny obraz przygotowany dla NetGuard Master / WT32-ETH01.

Celowo nie wpisuję tutaj nazwy pliku z numerem wydania. Projekt jest pre-release i taki szczegół bardzo szybko zamieniłby poprawny poradnik w instrukcję do starej wersji.

Zasada jest prosta: korzystam z aktualnego pliku wskazanego w dokumentacji repozytorium jako firmware dla WT32-ETH01.

Wgrywanie gotowego BIN-u – najprostsza ścieżka

Nie każdy, kto chce zbudować NetGuard, musi od razu instalować PlatformIO i kompilować źródła.

Dlatego przygotowuję również gotowy obraz firmware.

Po wejściu WT32-ETH01 w bootloader:

Jeśli zamiast gotowego obrazu korzystam ze źródeł, kompilację i upload można wykonać w środowisku projektu. Repozytorium pozostaje właściwym miejscem do sprawdzenia bieżącej procedury dla danego pre-release.

Pierwszy normalny start po flashowaniu

Po zakończeniu flashowania nie przechodzę jeszcze do reguł ani automatycznych restartów.

Najpierw sprawdzam podstawy.

Zdejmuję IO0 z GND i uruchamiam WT32-ETH01 w normalnym trybie.

Jeżeli korzystam z terminala szeregowego, obserwuję log startowy i sprawdzam, czy firmware rzeczywiście się uruchomił, a nie wrócił do bootloadera.

Następnie podłączam RJ45.

Pierwszy test Ethernetu

To moment, w którym WT32-ETH01 zaczyna robić dokładnie to, dla czego go wybrałem.

Podłączam przewód RJ45 do tej samej infrastruktury LAN, z której Master będzie później obserwował urządzenia.

Po zestawieniu fizycznego linku firmware uruchamia interfejs Ethernet.

W sprawdzonym zestawie połączenie wstaje prawidłowo i Master staje się osiągalny w sieci.

Master pracuje po przewodowym LAN. Wi-Fi nie jest potrzebne do wykonywania podstawowej funkcji watchdoga.

Master ma osobne zasilanie

W docelowej instalacji WT32-ETH01 dostaje własne zasilanie, niezależne od czterech kanałów NetGuard Power.

To bardzo ważne.

Jeżeli CH1 odcina router, CH2 restartuje AP, CH3 switch, a CH4 serwer, żadna z tych operacji nie może wyłączyć samego Mastera.

Pierwsze wejście do panelu WWW

Po uruchomieniu Ethernetu przechodzę do interfejsu Mastera.

Panel WWW jest ważny, bo nie chcę rekompilować firmware za każdym razem, kiedy zmienię adres IP urządzenia, czas RESET-u albo dodam kolejny cel diagnostyczny.

Cała bieżąca konfiguracja watchdoga należy do Mastera.

To tutaj definiuję urządzenia i usługi, które mają być sprawdzane, przypisuję reguły oraz określam, który kanał Power Module ma być użyty jako akcja recovery.

Na tym etapie jeszcze nie podłączam automatycznych restartów

Pierwszy start Mastera robię zachowawczo.

Najpierw chcę wiedzieć, że sam kontroler jest stabilny.

Sprawdzam Ethernet, dostęp do panelu i zachowanie po ponownym uruchomieniu.

Dopiero później dokładam Power Module.

To ułatwia diagnostykę: jeżeli coś nie działa, wiem, czy problem jest po stronie Mastera, UART-u, izolatora czy SONOFF-a.

Łączę Master z NetGuard Power przez ADuM1201

Docelowo WT32-ETH01 nie komunikuje się z SONOFF 4CHR3 przez Wi-Fi, MQTT ani HTTP.

Oba moduły mają własny, lokalny UART.

Pomiędzy nimi znajduje się ADuM1201.

Jedna droga przenosi komendy Master → Power, a druga odpowiedzi i telemetrykę Power → Master.

W finalnym zestawie komunikacja przez izolator działa prawidłowo.

Jak sprawdzam, czy Master naprawdę widzi Power Module

Nie zaczynam od RESET-u.

Najpierw uruchamiam Power Module, a następnie Mastera i obserwuję kartę modułu wykonawczego.

Połączenie uznaję za gotowe dopiero wtedy, gdy widzę serię poprawnych heartbeatów, a nie jeden przypadkowy komunikat.

W działającym systemie panel pokazuje między innymi:

• Power Module ONLINE,
• rosnący licznik heartbeatów,
• serię kolejnych poprawnych heartbeatów,
• CH1–CH4 w stanie ON,
• wiek ostatniej odpowiedzi,
• timeouty,
• błędne linie UART,
• ostatni STATUS,
• wykryte restarty Power Module.

Pierwszy ręczny RESET z Mastera

Dopiero po potwierdzeniu stabilnego UART-u wykonuję ręczny test.

Wybieram kanał i zlecam RESET.

Master nadaje operacji identyfikator i wysyła do Power Module polecenie:

Power Module potwierdza przyjęcie, przełącza wyjście, pilnuje własnego timera, a po zakończeniu zgłasza powrót kanału.

Test zrobiłem dla wszystkich czterech kanałów.

Na tym etapie wiem już, że mam działający tor:

Dopiero teraz zaczynamy właściwą diagnostykę sieci

Możliwość kliknięcia RESET-u z panelu to nadal nie watchdog.

Watchdog zaczyna się wtedy, kiedy Master sam potrafi odpowiedzieć na pytanie:

Czy urządzenie rzeczywiście się zepsuło i czy wolno je teraz zrestartować?

Najprostsza odpowiedź brzmiałaby: „nie odpowiada na PING”.

Dla mnie to za mało.

PING jest tylko jednym z narzędzi

PING świetnie nadaje się do prostego sprawdzenia, czy host odpowiada na ICMP.

Nie mówi jednak wszystkiego.

Serwer może odpowiadać na PING, ale jego usługa webowa może być martwa.

Router może odpowiadać lokalnie, podczas gdy DNS nie działa.

Pojedynczy pakiet może również zostać zgubiony bez żadnej realnej awarii.

Dlatego Master ma kilka typów celów diagnostycznych.

PING, TCP, HTTP, HTTPS i DNS

W działającym Masterze korzystam z tych testów zależnie od tego, co właściwie chcę sprawdzić.

Cel diagnostyczny i kanał Power to dwie różne rzeczy

To jedna z najważniejszych cech systemu.

Master może monitorować więcej urządzeń niż cztery.

NetGuard Power ma cztery fizyczne kanały, ale liczba celów diagnostycznych nie jest z nimi tożsama.

Przykład: kamera PoE.

Kamera jest celem diagnostycznym.

Ale nie ma własnego gniazda 230 V w NetGuard Power.

Jeżeli reguła uzna, że wymagane jest recovery, akcją może być RESET kanału zasilającego switch PoE.

Jedna utracona odpowiedź niczego jeszcze nie restartuje

Nie chcę, żeby jedna zgubiona odpowiedź powodowała odcięcie routera od zasilania.

Dlatego Master liczy kolejne błędne próby.

Dopiero po osiągnięciu skonfigurowanego progu warunek może zostać uznany za awarię.

Reguły AND i OR dają Masterowi kontekst

Sam licznik błędów nadal może nie wystarczyć.

Access point nie odpowiada.

Czy naprawdę jest uszkodzony?

Jeżeli jednocześnie router i wszystkie inne cele również przestały odpowiadać, problem może leżeć gdzie indziej.

Dlatego wyniki testów mogę łączyć w reguły.

Taka decyzja ma znacznie więcej sensu niż:

Ochrona po starcie

Po całkowitym zaniku zasilania infrastruktura nie uruchamia się jednocześnie.

Router, switch, serwer i AP potrzebują różnych czasów.

Master również może wystartować wcześniej od części urządzeń.

Gdyby natychmiast zaczął wykonywać recovery, uznałby zwykły rozruch za serię awarii.

Dlatego po uruchomieniu działa okres ochronny.

Sprawdziłem to również przy pełnym restarcie zestawu. Normalna faza uruchamiania urządzeń nie powoduje lawiny automatycznych RESET-ów.

Stabilizacja po RESET

Podobna ochrona jest potrzebna po wykonanej operacji.

Jeśli odetnę router na 10 sekund, to po ponownym podaniu napięcia router nie będzie ONLINE w jedenastej sekundzie.

Musi przejść cały własny boot.

Dlatego Master po recovery nie wraca od razu do normalnej oceny.

Dzięki temu urządzenie nie zostaje zrestartowane ponownie tylko dlatego, że nadal się uruchamia.

Cooldown i limit restartów

Jeżeli urządzenie mimo poprawnie wykonanego recovery nie wraca, kolejne odcinanie go od zasilania co kilkanaście sekund nie ma sensu.

Master ma więc dwa kolejne zabezpieczenia.

To bardzo ważna różnica względem prostego automatycznego „power cyclera”.

NetGuard nie ma restartować urządzenia za wszelką cenę.

Pełny cykl recovery mam już uruchomiony

Najważniejszym testem nie było dla mnie osobne sprawdzenie PING albo osobne kliknięcie przekaźnika.

Chciałem zobaczyć cały łańcuch.

Ten pełny przebieg działa.

Przykład: restart Access Point

AP przestaje odpowiadać.

Router pozostaje ONLINE.

Inny punkt odniesienia również działa.

Kolejne testy AP nadal kończą się błędem.

Reguła zostaje spełniona.

Master wysyła transakcję RESET do kanału zasilającego AP.

Power Module odłącza zasilanie, sam przywraca je po określonym czasie, a Master rozpoczyna stabilizację.

Po uruchomieniu AP zaczyna ponownie odpowiadać.

To jest dokładnie taki scenariusz, dla którego NetGuard powstał.

Przykład: kamera PoE i switch

Kamera nie musi mieć własnego kanału Power Module.

Master może monitorować jej IP, a jako akcję wskazać restart switcha PoE.

Po potwierdzeniu awarii resetowany jest kanał switcha, zasilanie PoE znika i wraca razem ze switchem, a kamera rozpoczyna nowy boot.

Oczywiście takie działanie wpływa także na inne urządzenia podpięte do tego samego switcha, więc reguła musi być przemyślana.

Technicznie jednak pokazuje to, że NetGuard nie jest prostym mapowaniem:

Przykład: serwer Home Assistant

Ten scenariusz najlepiej pokazuje, dlaczego Master musi być autonomiczny.

Jeżeli serwer Home Assistant się zawiesi, sam Home Assistant nie może być podstawową logiką decydującą o swoim restarcie.

WT32-ETH01 nadal działa.

Ethernet nadal może działać.

Master nadal ma swoją konfigurację, reguły i UART do Power Module.

Może więc przeprowadzić recovery także wtedy, gdy cały HA jest niedostępny.

Co się dzieje, gdy Master sam straci Ethernet

Ethernet nie gwarantuje, że połączenie nigdy nie zniknie.

Jeżeli restartuję router albo switch znajdujący się pomiędzy Masterem a innymi urządzeniami, przez pewien czas część sieci będzie niedostępna.

Najważniejsze jest to, że WT32-ETH01 nadal jest zasilany i nadal wykonuje firmware.

Nie znika razem z Wi-Fi.

Timery i stan trwającej operacji nadal istnieją.

Po powrocie linku Master wraca do testowania.

Co zostało fizycznie sprawdzone

Na tym etapie NetGuard Master jest działającą częścią systemu, a nie planem kolejnych funkcji.

Dlaczego cały projekt nadal jest pre-release

Power działa. Master działa. Pełny cykl działa.

Mimo tego NetGuard pozostaje obecnie pre-release.

Powód jest prosty: nadal rozwijam projekt przed pierwszym wydaniem, którego interfejs i zachowanie chcę uznać za stabilne.

Mogą zmieniać się szczegóły panelu, nazwy opcji, firmware, konfiguracja i dokumentacja.

Nie oznacza to, że opisane testy są dopiero planowane.

Mamy autonomiczny NetGuard. Teraz możemy dołożyć Home Assistant

Po trzech częściach system ma już wszystko, czego potrzebuje do wykonania podstawowego zadania.

Master obserwuje sieć.

Power steruje zasilaniem.

UART łączy obie części.

Recovery działa bez Home Assistant.

I właśnie dlatego w części 4 mogę bezpiecznie dołożyć MQTT oraz Home Assistant jako warstwę dodatkową.

HA pokaże statusy, zdarzenia, urządzenia i historię, ale nie stanie się warunkiem działania watchdoga.

NetGuard Master – najczęstsze pytania

Jak wgrać firmware NetGuard Master do WT32-ETH01?

Firmware wgrywam przez UART. Adapter TX łączę z RXD WT32-ETH01, RX z TXD, a masę z GND. Następnie zwieram IO0 do GND i resetuję lub ponownie zasilam płytkę, aby ESP32 uruchomił bootloader. Po wgraniu firmware usuwam zwarcie IO0–GND i uruchamiam Master normalnie.

Czy WT32-ETH01 można zasilać z 5 V?

Tak. Płytka udostępnia wejście 5 V oraz 3,3 V. Wybiera się jeden sposób zasilania, a nie oba jednocześnie. Linie UART ESP32 nadal wymagają poziomów logicznych 3,3 V.

Dlaczego IO0 trzeba odłączyć po flashowaniu?

Stan IO0 podczas uruchamiania decyduje o wejściu ESP32 w bootloader. Jeśli pozostanie zwarty do GND, urządzenie ponownie uruchomi się w trybie programowania zamiast wystartować z firmware NetGuard.

Dlaczego Master używa Ethernetu zamiast Wi-Fi?

Ponieważ urządzenie odpowiedzialne za diagnostykę infrastruktury nie powinno zależeć od Wi-Fi, którego awarię samo może być zmuszone wykryć. WT32-ETH01 korzysta z przewodowego interfejsu Ethernet.

Czy NetGuard restartuje urządzenie po jednym nieudanym PING?

Nie. Master może wymagać kilku kolejnych nieudanych testów i dodatkowych warunków reguły.

Jakie rodzaje testów obsługuje Master?

W działającym projekcie wykorzystuję PING, TCP, HTTP, HTTPS oraz DNS.

Jak NetGuard zapobiega pętli restartów?

Wykorzystuje między innymi próg kolejnych błędów, ochronę po starcie, stabilizację po recovery, cooldown oraz ograniczenie liczby kolejnych prób.

Czy NetGuard Master wymaga Home Assistant?

Nie. Master wykonuje diagnostykę i podejmuje decyzje lokalnie. Home Assistant jest dodatkową integracją opisaną w części 4.

Gdzie pobrać firmware NetGuard Master?

Aktualne źródła, dokumentacja i pliki projektu znajdują się w publicznym repozytorium

MarkLabs-NetGuard
.
Ponieważ projekt nadal ma status pre-release, przy flashowaniu należy korzystać z aktualnej dokumentacji repozytorium.