NetGuard Power: przerabiam SONOFF 4CHR3 na czterokanałowy moduł zasilania

W pierwszej części pokazałem, dlaczego NetGuard nie może być tylko systemem diagnostycznym. Jeśli router, punkt dostępowy, switch albo serwer rzeczywiście się zawiesi, potrzebuję fizycznej warstwy wykonawczej zdolnej bezpiecznie odłączyć i ponownie podać zasilanie. Ten etap projektu mam już ukończony: SONOFF 4CHR3 działa jako czterokanałowy NetGuard Power, komunikuje się z Masterem przez UART, wykonuje kontrolowane resety i poprawnie raportuje swój stan.

Dlaczego wybrałem SONOFF 4CHR3

Warstwę wykonawczą można było zbudować od zera: ESP32, czterokanałowa płytka przekaźników, własne złącza i własna obudowa. Technicznie zadziałałoby.

W NetGuardzie ta część pracuje jednak z urządzeniami zasilanymi z 230 V. Nie chciałem więc budować toru sieciowego na płytce prototypowej i dopiero później zastanawiać się nad zaciskami, odstępami oraz mechanicznym zabezpieczeniem przewodów.

SONOFF 4CHR3 daje gotową bazę: cztery przekaźniki, zaciski oraz ESP8285. Jego fabryczna funkcja nie była mi jednak potrzebna.

Nie używam chmury producenta, nie używam fabrycznego sterowania i nie potrzebuję Wi-Fi.

Po zmianie firmware SONOFF stał się dokładnie tym, czego potrzebuje NetGuard: prostym, przewodowym, czterokanałowym modułem wykonawczym.

Co zmieniłem w SONOFF-ie

Najważniejszą zmianą nie był hardware, lecz firmware.

ESP8285 pozostał na swoim miejscu, ale przestał pełnić rolę mikrokontrolera urządzenia smart home. Po wgraniu mojego oprogramowania zajmuje się wyłącznie obsługą czterech przekaźników, UART-em, lokalnymi timerami, heartbeatami i watchdogiem.

Cztery fizyczne wyjścia są widoczne w systemie jako CH1–CH4.

Mapowanie czterech kanałów mam już potwierdzone

Firmware steruje przekaźnikami poprzez:

Mapowanie sprawdziłem na fizycznym egzemplarzu. Każdy kanał logiczny odpowiada właściwemu przekaźnikowi i właściwemu wyjściu SONOFF-a.

Sprawdziłem wszystkie cztery kanały osobno oraz ich powrót do ON po zakończeniu operacji czasowej.

CH4 wykorzystuje GPIO15, czyli pin mający znaczenie podczas startu ESP8285. To ważny szczegół, bo przez krótką fazę bootloadera nie można traktować go dokładnie tak samo jak zwykłego GPIO aplikacji.

W praktycznych testach zachowanie po uruchomieniu jest poprawne. Po przejęciu GPIO przez firmware wszystkie cztery kanały przechodzą do oczekiwanego stanu ON.

Flashowanie zrobiłem całkowicie bez 230 V

To podstawowa zasada przy pracy z odsłoniętą płytką SONOFF-a. Podczas programowania dotykamy przewodów, padów i adaptera, więc napięcie sieciowe nie może być obecne.

Adapter USB–UART pracuje z logiką 3,3 V. Nie używam 5 V.

\

Połączenie USB–UART

Do programowania połączyłem płytkę klasycznie, krzyżując TX i RX:

Na tym etapie ADuM1201 nie jest potrzebny. Programator jest połączony bezpośrednio z SONOFF-em, ale wyłącznie przy całkowicie odłączonej stronie sieciowej.

Tryb bootloadera i wgrywanie firmware

Aby ESP8285 przyjął nowe oprogramowanie, uruchomiłem go w trybie bootloadera UART.

Firmware można wgrywać na kilka sposobów. Dla osób, które nie chcą budować projektu w PlatformIO, najprostsza będzie gotowa paczka BIN.

ESP8285 pozwala zapisać pojedynczy obraz aplikacji od adresu 0x00000.

Przetestowałem również prostą ścieżkę wgrywania gotowego BIN-u przez ESPHome Web.

Kod NetGuard jest już na GitHubie

Od początku zależało mi na tym, żeby NetGuard nie został projektem, który można odtworzyć tylko z kilku fragmentów kodu rozsianych po artykułach.

Repozytorium projektu jest już publiczne:

Repozytorium jest miejscem, w którym utrzymuję aktualne źródła, dokumentację oraz materiały potrzebne do odtworzenia projektu.

W artykułach celowo nie przywiązuję instrukcji do numerów wydań firmware. Podczas fazy pre-release rozwój nadal jest szybki i konkretne oznaczenia wersji niepotrzebnie postarzałyby tekst.

Docelowo chcę utrzymać dwie ścieżki. Osoba techniczna będzie mogła pobrać kod i zbudować firmware samodzielnie. Osoba, która chce po prostu odtworzyć gotowy projekt, będzie mogła skorzystać z przygotowanych obrazów BIN.

Pierwszy test po flashowaniu: PING i PONG

Po uruchomieniu firmware pierwszym testem była komunikacja UART.

Terminal ustawiłem na:

Czyli klasyczne 9600 8N1.

Po wysłaniu:

Power Module odpowiada:

Test działa powtarzalnie. Parser prawidłowo rozpoznaje zakończenia CR, LF i CRLF oraz ignoruje niekompletne linie do momentu otrzymania końca komendy.

Najważniejszy test: kontrolowany RESET

Podstawową operacją Power Module nie jest zwykłe OFF ani ON, lecz czasowy RESET.

Master wysyła:

Przykładowo:

Power Module potwierdza:

Kanał CH2 przechodzi do OFF. Po dziesięciu sekundach lokalny timer przywraca go do ON i moduł wysyła:

Sprawdziłem ten mechanizm na fizycznym module. Wyłączenie i ponowne załączenie działają zgodnie z zadanym czasem.

Przetestowałem wszystkie cztery kanały.

Odłączyłem UART podczas RESET-u

To jeden z najważniejszych testów całego Power Module.

Chciałem sprawdzić, czy rozpoczęta operacja rzeczywiście należy do SONOFF-a, czy tylko pozornie działa tak długo, jak długo Master pozostaje połączony.

Uruchomiłem czasowy RESET, a następnie przerwałem komunikację UART.

Kanał pozostał wyłączony przez zadany czas, po czym Power Module sam przywrócił go do ON.

To zachowanie jest dokładnie takie, jakiego oczekiwałem.

Dzięki temu zerwanie komunikacji w najgorszym możliwym momencie nie zostawia routera, AP czy switcha bez zasilania na stałe.

Powtórzona transakcja również została sprawdzona

RESET ma identyfikator transakcji nie bez powodu.

Jeżeli Master wysłał polecenie, ale nie otrzymał potwierdzenia, musi mieć możliwość bezpiecznego ponowienia transmisji.

Sprawdziłem ten scenariusz.

Ponowne wysłanie identycznej transakcji z tym samym ID, kanałem i czasem nie uruchamia drugiego przełączenia.

Power Module ponawia odpowiedź, ale nie wykonuje operacji ponownie.

Z kolei ponowne użycie tego samego ID z innymi parametrami jest odrzucane jako błąd transakcji.

Ta mała rzecz ma duże znaczenie w urządzeniu, które steruje zasilaniem. Bez niej utrata jednej odpowiedzi UART mogłaby wywołać kolejny reset w czasie, kiedy urządzenie właśnie wraca do pracy.

Nieblokujące timery działają prawidłowo

Każdy kanał ma własny timer i podczas oczekiwania firmware nie zatrzymuje głównej pętli.

To oznacza, że w czasie trwania RESET-u Power Module nadal:

• obsługuje UART,
• wysyła heartbeat,
• pilnuje watchdog,
• kontroluje pozostałe kanały.

Sprawdziłem również równoległe operacje czasowe. Timery kanałów pracują niezależnie.

Nie ma więc sytuacji, w której dziesięciosekundowy reset jednego wyjścia „zamraża” cały mikrokontroler.

Parser błędnych poleceń też działa

Przetestowałem nie tylko poprawne komendy.

Wysłałem również:

• nieprawidłowy numer kanału,
• czas równy zero,
• nieznane polecenie,
• niepełną linię,
• zbyt długą linię,
• nieprawidłową transakcję.

Parser odrzuca błędne komendy i nie wykonuje przypadkowo części uszkodzonego polecenia.

W zależności od problemu zwracane są czytelne komunikaty błędów dotyczące między innymi składni, kanału, czasu, transakcji czy chwilowej zajętości.

Heartbeat działa stabilnie

Power Module cyklicznie wysyła heartbeat zawierający identyfikator sesji, uptime oraz logiczne stany czterech kanałów.

Struktura wygląda tak:

Stany:

oznaczają cztery kanały zadane jako ON.

Podczas testów heartbeaty przychodzą regularnie, uptime rośnie, a zmiany stanów kanałów są poprawnie raportowane.

Restart Power Module jest wykrywany przez Mastera

Każdy start Power Module tworzy nowy identyfikator sesji.

Sprawdziłem również ten mechanizm.

Po restarcie modułu Master odbiera nową sesję i rozpoznaje, że Power Module został ponownie uruchomiony.

To ważne, bo komunikacja po restarcie nie wygląda dzięki temu jak nieprzerwana praca.

Master może odnotować zdarzenie i odpowiednio traktować bieżący stan systemu.

Watchdog samego SONOFF-a również został sprawdzony

Power Module ma własny watchdog programowy.

Jego zadaniem jest zresetowanie ESP8285, jeśli główna pętla programu przestałaby działać prawidłowo.

Sprawdziłem zachowanie po restarcie i powrót do normalnej pracy. Moduł ponownie inicjalizuje UART, kanały wracają do oczekiwanego stanu, a Master rozpoznaje nową sesję.

Dzięki temu NetGuard nie opiera swojej odporności na założeniu, że moduł wykonawczy nigdy sam się nie zawiesi.

Sprawdziłem także zachowanie przy ponownym uruchomieniu

Kolejnym testem były stany wyjść po power-on oraz po restartach programowych.

Po przejęciu GPIO przez aplikację wszystkie cztery kanały przechodzą do ON, czyli stanu oczekiwanego w NetGuardzie.

Router, AP, switch i serwer mają być normalnie zasilane cały czas. Power Module odcina je wyłącznie na czas konkretnej operacji RESET.

Sprawdziłem również zachowanie po zaniku i ponownym podaniu zasilania. Moduł poprawnie wraca do pracy i ponownie rozpoczyna komunikację UART.

ADuM1201: finalna komunikacja nie jest połączona „na krótko”

Podczas programowania USB–UART był podłączony bezpośrednio do SONOFF-a, ale docelowy system wygląda inaczej.

Między NetGuard Master a NetGuard Power zastosowałem moduł z ADuM1201.

Izolator obsługuje dwa kierunki UART:

Połączenie przez izolator zostało uruchomione i sprawdzone. Komunikacja działa stabilnie w obu kierunkach.

Power Module odpowiada na komendy, wysyła heartbeaty, a Master poprawnie odbiera jego stan.

Co zostało fizycznie potwierdzone

Ten etap projektu uznaję za zakończony, ponieważ sprawdziłem całą podstawową ścieżkę działania Power Module na fizycznym SONOFF 4CHR3.

Stan logiczny nadal nie oznacza pomiaru napięcia

Jedno ograniczenie sprzętu pozostaje bez zmian.

Jeśli Power Module raportuje CH2 jako ON, oznacza to, że firmware ustawił wyjście sterujące w stanie odpowiadającym ON.

Nie jest to niezależny pomiar napięcia na gnieździe ani elektryczne sprzężenie zwrotne ze styku przekaźnika.

W praktycznych testach stany logiczne i fizyczne przełączanie były zgodne, ale w interfejsie nie chcę przedstawiać stanu GPIO jako pomiaru napięcia.

Power Module działa razem z Masterem

Po zakończeniu testów samego SONOFF-a połączyłem Power Module z NetGuard Master przez ADuM1201.

Master poprawnie rozpoznaje moduł jako ONLINE i odbiera regularne heartbeaty.

Widzę także:

• czas ostatniej odpowiedzi,
• liczbę heartbeatów,
• kolejne poprawne komunikaty,
• stany CH1–CH4,
• operację RESET w toku,
• błędne linie UART,
• timeouty,
• restarty Power Module.

Ręczny RESET z poziomu Mastera również działa prawidłowo dla wszystkich kanałów.

Komendy diagnostyczne zostały

Normalna praca opiera się na transakcyjnym RESET, ale zostawiłem również prostsze komendy przydatne podczas serwisu i testów.

Najważniejsza w diagnostyce awaryjnej jest ALLON, która natychmiast ustawia wszystkie kanały jako ON i anuluje aktywne timery.

Nie jest potrzebna w normalnym cyklu NetGuarda, ale podczas uruchamiania i serwisu jest bardzo wygodna.

Co pokazuje terminal, gdy coś jest nie tak

Finalna forma: cztery wyjścia zasilania

Elektronicznie Power Module jest gotowy. Mechanicznie całość dostaje cztery kontrolowane tory zasilania przeznaczone dla urządzeń stojących przy mojej infrastrukturze.

Rozwiązanie może zostać wykonane jako cztery oddzielne gniazda albo odpowiednio przygotowana listwa zasilająca.

Niezależnie od wariantu całość musi być zamknięta w sposób uniemożliwiający przypadkowy dostęp do części pracujących z napięciem sieciowym.

Obudowa z druku 3D

Power Module dostaje własną obudowę przygotowaną do druku 3D.

Chcę, żeby finalnie był to normalny element infrastruktury, a nie otwarta płytka z przewodami.

Na zewnątrz będą czytelne oznaczenia kanałów CH1–CH4, tak żeby późniejsza zmiana podłączonych urządzeń nie wymagała otwierania obudowy i śledzenia przewodów.

Ukończony etap: co naprawdę udało się osiągnąć

Na początku tej części miałem SONOFF 4CHR3, który fabrycznie był po prostu wielokanałowym urządzeniem smart.

Po zakończeniu prac mam zupełnie inny element systemu.

To oznacza, że warstwa wykonawcza NetGuarda jest gotowa i działa zgodnie z założeniami.

Cały projekt nadal pozostaje jednak w fazie pre-release. To rozróżnienie jest ważne: funkcje opisane w tym artykule zostały fizycznie sprawdzone, ale kod i architektura całego systemu nadal mogą być rozwijane przed pierwszym stabilnym wydaniem.

Co dalej?

W części 3 opiszę gotowy NetGuard Master na WT32-ETH01.

Tam znajduje się właściwa inteligencja projektu: przewodowy Ethernet, PING, TCP, HTTP, HTTPS, DNS, reguły, warunki AND/OR, liczniki błędów, stabilizacja po restarcie i zabezpieczenia przed pętlą restartów.

Tak samo jak w tej części, następny artykuł opisze etap już zbudowany i sprawdzony na rzeczywistym sprzęcie, mimo że cały NetGuard nadal pozostaje projektem pre-release.

NetGuard Power – najczęstsze pytania

Czy SONOFF 4CHR3 korzysta jeszcze z Wi-Fi?

Nie. W NetGuardzie pracuje jako przewodowy moduł wykonawczy i komunikuje się z Masterem przez UART.

Czy wszystkie cztery kanały zostały sprawdzone?

Tak. CH1–CH4 zostały fizycznie przetestowane, ich mapowanie jest poprawne, a kontrolowane wyłączenie i automatyczny powrót do ON działają zgodnie z założeniami.

Co się stanie, jeśli UART zniknie podczas RESET-u?

Kanał nadal wróci do ON. Czas RESET-u jest pilnowany lokalnie przez Power Module i został fizycznie sprawdzony również przy przerwaniu komunikacji.

Czy Home Assistant steruje SONOFF-em bezpośrednio?

Nie. Power Module wykonuje polecenia NetGuard Mastera. Home Assistant nie jest wymagany do działania tej warstwy systemu.

Dlaczego zastosowałem ADuM1201?

Do izolacji komunikacji UART pomiędzy niskonapięciowym Masterem a modułem wykonawczym pracującym w urządzeniu związanym z napięciem sieciowym. Połączenie przez ADuM1201 zostało uruchomione i działa poprawnie.

Czy firmware można wgrać bez PlatformIO?

Tak. Gotowy BIN można zaprogramować przez odpowiedni flasher, na przykład ESPHome Web, przy całkowicie odłączonym 230 V i z użyciem USB–UART 3,3 V.

Gdzie znajdę kod NetGuard?

Kod źródłowy i dokumentacja są już publiczne w repozytorium

MarkLabs-NetGuard na GitHubie
.
Projekt ma obecnie status pre-release.

Czy ON oznacza zmierzone 230 V na wyjściu?

Nie. Jest to stan zadany przez firmware. Fizyczne działanie przekaźników zostało potwierdzone podczas testów, ale sam firmware nie posiada osobnego pomiaru napięcia na wyjściu.