Wybierz Strona

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

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

  • 0
  • 27.02.2019
Jaromir Kopp

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?!

Sonoff i Electrodragon

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.

 

O autorze

Jaromir Kopp

Użytkownik komputerów Apple od 1991 roku. Dziennikarz technologiczny, programista i deweloper HomeKit. Propagator przyjaznej i dostępnej technologii, wyczulony na potrzeby osób niepełnosprawnych i starszych. Tworzy w języku Swift aplikacje na platformy macOS, iOS, tvOS oraz systemy bazodanowe FileMaker. Prowadzi zajęcia z programowania dla dzieci i młodzieży. Autor książki o serwerach NAS „Mój QNAP”. Projektuje, programuje oraz samodzielnie wykonuje prototypy urządzeń Smart Home. Jeździ rowerem.

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Mój Mac Magazyn

Zapisz się

i otrzymuj darmowy magazyn

Witaj w gronie czytelników. Dziękujemy!