Czołem!
Trochę czasu od ostatniego wpisu, jak zazwyczaj, minęło. Oczywiście nie oznacza to, że nic się nie dzieje. Paradoksalnie dzieje się jeszcze więcej niż dotąd, również w tematach technicznych.
Budowanie sieci Zigbee...
Cóż, jakiś czas temu porwałem się z motyką na słońce i wdepnąłem w kolejną przygodę, jaką jest utrzymywanie sieci Zigbee. Co to takiego?
ZigBee – specyfikacja protokołów transmisji danych w sieciach bezprzewodowych typu mesh, cluster tree. Sieci oparte na ZigBee charakteryzują się niewielkim poborem energii, niewielkimi przepływnościami (do 250 kbps) oraz zasięgiem między węzłami rzędu 100 m. (źródło: wikipedia.org)
Na pierwszy rzut oka nie widać zbyt wielu konkretów (niestety im dalej, tym coraz mniej tych konkretów). W każdym razie wiedząc, że sieć działa w oparciu o 2.4GHz (niektóre elementy też na 868 MHz) ruszyłem z tematem. Założenie jest takie, by sieć organizowała się w topologii siatki, co zapewni niezawodną komunikację, nawet w przypadku wielu kondygnacji w budynku.
W dużym uproszczeniu można powiedzieć, że to takie WiFi dostosowane do urządzeń automatyki domowej, sensorów itd. Warto jednak pamiętać, że to nadal w zasadzie tylko sposób wymiany danych, na bazie którego producenci urządzeń budują swoje ekosystemy Smart Home.
Budujemy koordynator!
Trochę się naczytałem o tej sieci, więc mając już działającego Home Assistanta i zrealizowanych kilka projektów, pomyślałem, że sam sobie zbuduję koordynator.
Koordynator to urządzenie działające jako nadzorca (zarządza siecią) a także okno na świat (wymienia dane ze światem zewnętrznym). To właśnie dzięki koordynatorowi zbudujemy sieć i umożliwimy sterowanie domem z dowolnego miejsca na świecie.
Z tym tematem trochę popłynąłem, bo założyłem, że koordynator powinien:
- obsługiwać komunikację między ZHA oraz modułem EZSP
- umożliwiać odtwarzanie muzyki MP3 / dźwięku
- umożliwić podłączenie USB (przewodowe połączenie w razie potrzeby)
- nie robić bałaganu w eterze
Paradoksalnie najprostszy element to implementacja dot. Zigbee, bo programowanie ogranicza się do:
- zbudowania firmware'u (gotowego) na docelowy chip (NCP - Network Co-Processor)
- zbudowaniu oprogramowania działającego jako pośrednik między UART a HomeAssistant
Trudniejsza okazała się implementacja odtwarzania dźwięku za pomocą I2S, w oparciu o układ MAX98357A. Jednak i to się udało. Muszę przyznać, że całkiem przyjemnie się słucha odtwarzanej przez urządzenie muzyki.
Najciekawsze jednak, jak zwykle, było projektowanie płytki drukowanej i obudowy :)
Urządzenie składa się z ESP32S3 (z USB), kilku układów zarządzających energią, termometru, modułu Zigbee opartego o EFR32MG1 i paru innych mniej istotnych elementów.
Oprogramowanie Zigbee to gotowce, które wystarczy zbudować lub znaleźć zbudowane na repozytoriach. Tutaj jednak jest trochę zachodu, choćby ze względu na różne wersje EZSP.
Czekaj... czym jest EZSP? Jest to protokół komunikacji UART do komunikacji procesora aplikacyjnego z procesorem sieciowym. Można powiedzieć, że przypomina to trochę kartę graficzną, gdzie CPU wysyła poszczególne żądania, które są bardziej abstrakcyjne, niż operacje na bitach odpowiadających za poszczególne piksele. To pozwala odciążyć procesor od wykonywania wyspecjalizowanych, wąskich zakresowo czynności. Tak jest i tutaj, gdzie układ otrzymuje przykładowo żądanie uformowania sieci a pod maską obsługuje funkcje związane z emisją fal radiowych w odpowiednim standardzie. Niestety wersji tego protokołu jest sporo, nie zawsze urządzenie może mieć najnowszą wersję a ponadto dochodzi drugi koniec (czyli Zigbee2MQTT lub ZHA).
A cóż to jest ZHA, Zigbee2MQTT? W skrócie, to klient, który rozmawia z NCP przez UART. Mój koordynator wystawia UART za pośrednictwem sieci lokalnej, dzięki czemu ZHA/Zigbee2MQTT może bezpośrednio z nim nawiązać połączenie. To właśnie dzięki tym integracjom możliwe jest obsługiwanie różnych urządzeń lokalnie, unikając konieczności korzystania ze sprzętu, bramki i chmury jednego producenta - niestety kosztem tego, że czasem coś nie działa.
Device has left the network, unparsed frame 0xc4...
Trudne do zrozumienia błędy, lakoniczne komunikaty, konsola zawalona czerwonymi errorami, to chyab coś, co najbardziej demotywuje programistę.
Niestety, ze stabilnością sieci walczyłem bardzo długo. Przeskakiwałem między ZHA a Z2MQTT, kombinowałem z kanałami sieci, ustawieniami koordynatora, różnymi wersjami firmware a światło w salonie nie chciało się zaświecić w najbardziej potrzebnym momencie. Podobnie, automatyczne oświetlenie w przedpokoju zwykło przestać działać akurat wtedy, gdy w nocy ktoś musiał skorzystać z toalety.
Jednym z problemów, które namierzyłem dość szybko było nieodpowiednie inicjowanie HardwareSerial, co po rozłączeniu urządzenia z sieci bezprzewodowej uniemożliwiało ponowne rozpoczęcie transmisji po uzyskaniu dostępu do sieci.
Kolejnym, z którym dość długo się męczyłem było wypadanie urządzeń z sieci - głównie dotyczyło to przełączników bez wymaganego przewodu neutralnego. Wygląda na to, że urządzenia te rzadziej komunikują się z siecią, czasem nie odpowiadają na ping i w konsekwencji wypadają z sieci. Tutaj pomocne okazało się wymuszenie raportowania stanu częściej (konkretnie 60 sekund).
Inny problem na który się natknąłem, to coś w rodzaju opóźnionej reakcji na kliknięcie przełącznika. Warto spróbować odpiąć dany klaster w sekcji Powiązanie.
Niektórzy użytkownicy sugerują też wykorzystać opcję disable_tuya_default_response, która dostępna jest w Zigbee2MQTT Edge. U mnie jednak powoduije opóźnienia!
Ciąg dalszy...
Na dzisiaj to tyle, postaram się niebawem napisać coś więcej o praktycznym działaniu systemu. Do następnego!
Komentarze
Prześlij komentarz