Jak zostać deweloperem HomeKit cz. VIII, baterie i wredne przekaźniki

Dziś będzie o problemach. Ostatnio obiecałem Wam, drodzy adepci programowania mikrokontrolerów oraz początkujący deweloperzy akcesoriów HomeKit, że napiszę o oszczędzaniu energii. Jednak tym razem nie tej, za którą płacimy rachunki, ale tej pobieranej przez akcesoria.

Jednak zanim do tego przejdę, muszę poskarżyć się na tanie przekaźniki stosowane w równie tanich przełącznikach „Wi-Fi” opartych na ESP8266. Mowa tu oczywiście o często opisywanych i bardzo popularnych Sonoffach i Electrodragonach. Tych drugich dotyczy to w mniejszym stopniu.

Jak już mogliście się zorientować, kilka z urządzeń, nad którymi pracuję, to akcesoria łączące się z HomeKit za pomocą mostka. Jest on oparty na ESP32. Jednak dla akcesoriów w zupełności wystarczą ESP8266 tej samej firmy. Komunikować się będą za pomocą protokołu ESPNOW. Z kilku powodów zrezygnowałem z komunikacji Wi-Fi. Najważniejszym to, jak uważni czytelnicy tego cyklu mogli się zorientować, zakaz mostkowania akcesoriów IP, czyli właśnie Wi-Fi lub Ethernet. Kolejne to niezależność od Wi-Fi, znacznie większa szybkość reakcji i prostsza obsługa.

Oczywiście z tego powodu całe oprogramowanie muszę w zasadzie pisać od podstaw. Pierwsze próby na deweloperskim zestawie ESP8266 z diodkami podpiętymi zamiast przekaźników przebiegały idealnie. Gdy już oprogramowanie uzyskało wymaganą funkcjonalność, postanowiłem testować je na działających urządzeniach w warunkach „bojowych”. Wgrałem soft w kilka Sonoffów i Electrodragonów i byłem bardzo zadowolony ze swojego dzieła. Krótko.

Okazało się, że czasem, gdy przełączam włącznik za pomocą komend z aplikacji HomeKit lub nawet przełącznikiem czy przyciskiem w urządzeniu, przekaźnik potrafi „odskoczyć”. Ja włączam, a on się włącza i wyłącza, ja wyłączam, a on raz reaguje dobrze, a czasem wraca do stanu wyjściowego. Ki czort?!

Dość szybko zdiagnozowałem przyczynę. To nie były błędy w oprogramowaniu. To był efekt zakłóceń generowanych przez przekaźniki sterujące zasilaniem urządzeń 230 V. Jak być może wiecie, przekaźnik składa się z elektromagnesu, który zasilony generuje pole magnetyczne przyciągające styki przełącznika. Przy okazji zmiany pola magnetycznego, za sprawą prawa indukcji elektromagnetycznej Faradaya, generują w okolicznych obwodach prąd, a raczej w tym przypadku napięcia zwane „stanami”.

Teraz wróćmy do kodu. Byłem bardzo dumny z przerobionej przeze mnie biblioteki Button dołączonej do natywnego środowiska NONOS, w którym programuje się zazwyczaj ESP8266. Program wykorzystywał przerwania generowane przez zmianę stanu (napięcia) na wejściach, do których podpięte są przyciski i włączniki. Przerwanie może reagować na zmianę stanu z wysokiego na niski czy odwrotnie lub na osiągnięcie stanu wysokiego lub niskiego. Dzieje się to sprzętowo i błyskawicznie. Potem wystarczy sprawdzić, czy stan się utrzymuje, aby wykluczyć tak zwane odbicie przycisku (debounce). Wszystko działało idealnie do momentu pojawienia się wspomnianych indukcji. Wywoływały one zmiany i osiąganie stanów, i to w taki sposób, że nawet bardzo mocne wydłużenie czasu „na odskok” nie eliminowało wszystkich pomyłkowych wzbudzeń. OK… wszystko jasne, ale przecież oprogramowanie oryginalne czy np. opisywane w cyklu publikowanym w serwisie [mojmac.pl](https://mojmac.pl/2017/02/23/inteligentny-dom-tanim-kosztem-homekit-zrob-to-sam/) Tasmota nie ma tych problemów.

Nie zawsze przerwania są dobre

Jeżeli układ wykryje przerwanie wywołane „wciśnięciem” przycisku, czyli zmianą stanu jednego z wejść, to wywołuje stosowną funkcję. Potem wystarczy kilka „timerów” i już obsługa przycisku jest zaimplementowana, w dodatku bez zbędnego obciążania mikrokontrolera. Jednak jak widać w moim przypadku, nie zdało to egzaminu. Gdy tylko się zorientowałem, zaraz zacząłem sprawdzać działający bez tych problemów kod Tasmota.

Jest on napisany w środowisku Arduino. Powstało ono na bardzo fajne, ale wręcz prymitywne układy AVR. Nie mają one w zasadzie systemu operacyjnego poza funkcjami sprzętowymi. Z tego powodu Arduino jest oparte na pętli. Zresztą podobna pętla działa w każdym z systemów, nawet iOS. Czasem są do niej odniesienia w dokumentacji deweloperskiej Apple. Właśnie w Arduino obsługę przycisków najczęściej implementuje się za pomocą cyklicznego sprawdzania stanu wejścia, a nie przerwania. Jak już mamy pętlę, to niech się ona kręci. Cykliczne sprawdzanie np. co 50 milisekund w zasadzie całkowicie uodparnia na fałszywe wzbudzenia. Są one po prostu krótsze, choć zdążą wywołać przerwanie, a potem jeszcze namieszać w procedurze „debounce”. Nie pozostało mi nic innego, jak zaimplementować rozwiązanie podobne do tego stosowanego w Tasmota i Arduino. Jednak ESP8266 jest 32-bitowym dość zaawansowanym układem, a Arduino powstało na 8-bitowce, choć jest, jak widać dostępne i na ESP. W NONOS nie ma „nieskończonej pętli”, a stworzenie jej spowoduje awaryjne restarty. Musiałem wymyślić coś innego. Wybór padł na timer. Zamiast sprawdzać w pętli, czy od jednego wywołania funkcji obsługującej przyciski do kolejnego minęło np. 50 tysięcznych sekundy, ustawiłem timer, który co 50 ms wywołuje stosowną funkcję.

Okazało się, że implementacja przycisków i włączników za pomocą timera działa idealnie. Nie ma już żadnych fałszywych wzbudzeń, nawet gdy załączam za pomocą HomeKit odkurzacz czy inne prądożerne świństwo.

Przerwania nadal dobrze sprawują się podczas komunikacji z sensorami np. temperatury. I właśnie – będąc przy sensorach temperatury, wracamy do tematu baterii.

Życie na bateriach

Czy termometr warto zasilać z sieci 230 V? A może czujnik otwarcia okien podpiąć do fazy? Termometr, gdy jest samodzielny i poza pomiarem temperatury potrafi coś więcej, niegłupio byłoby zasilać z sieci. Również jeżeli jest dodatkiem np. do i tak podłączonego do prądu przełącznika, gniazdka czy oświetlenia. Jednak często nie mamy możliwości doprowadzenia zasilania do akcesorium. Jesteśmy wtedy skazani na zasilanie bateryjne. Z doświadczenia wiem, że wymiana baterii w takim urządzeniu częściej niż raz na pół roku będzie zdecydowanie uciążliwa. Baterie nie mogą być również zbyt wielkie. W końcu to nie „ruski zegarek” z dawnych dowcipów, który ma niesamowite możliwości i byłby bardzo wygodny, gdyby nie te akumulatory w plecaku.

Dlatego wiele urządzeń SmartHome jest zasilanych bateryjnie. Królują maleńkie pastylki CR2032 oraz paluszki, małe AAA i normalne AA. Niestety, gdy się korzysta z takiego zasilania, nie ma możliwości utrzymać połączenia Wi-Fi. Dlatego akcesoria HomeKit, które muszą być zasilane bateryjnie, są skazane na bardzo energooszczędny Bluetooth LE lub inne metody komunikacji i mostek do Wi-Fi. Ponieważ nadal mam opory przed programowaniem nRF52xxx (dobry i popularny układ z Bluetooth LE) i dodatkowo jest on wyraźnie droższy od układów ESP, zdecydowałem się na wariant z mostkiem, który i tak już mam opracowany.

Od razu muszę się przyznać, że odniosłem sukces, choć walka z trybami uśpienia ESP8266 oraz dość zawiłym układem z wieloma diodami (nie LED, ale „prostowniczymi”), który musi być zastosowany w pilocie, była zaciekła. Najlepiej to widać na zdjęciach prototypów, które przypominają koszmar sapera z najgorszych filmów sensacyjnych klasy D, ale działają. Według moich obliczeń dwie baterie AAA w „pilocie” powinny wystarczyć na 100 000 „pstryknięć”, czyli na kilka lat. Sensor temperatury, wilgotności, ciśnienia i jasności powinien działać przynajmniej rok, dokonując pomiarów co minutę, a na bateriach AA znacznie dłużej.

A! Jeszcze jedno intymne wyznanie. Od kilku tygodni zacząłem używać Visual Studio Microsoftu. Oczywiście na macOS. Jest to związane z prężniejszym rozwojem Platformio właśnie dla VS. Platformio służy mi do programowania ESP8266. Jednak również w Visual Studio edytuję, piszę kod HomeKit dla ESP32, choć kompilacja odbywa się już tradycyjnie w Terminalu za pomocą oryginalnych narzędzi Espressif i Tensilica.

O tym, jak udało mi się to osiągnąć za pomocą jednak dość energożernych ESP8266, oraz o tym, że HomeKit to nie wszystko, przeczytacie już w przyszłym roku. I będzie warto, bo ESP8266 ma wyjątkowo zawiłe podejście do oszczędzania energii.