Postanowiłem się podzielić z Wami moimi doświadczeniami z bezprzewodowymi czujnikami temperatury dla inteligentnego domu. Inteligentny dom buduję, tak jak wiele osób, na ESP8266. Do tej pory były to sterowniki – bramy, garażu, ogrzewania, domofonu, alarmu. Wszystkie te układy mają dostęp do zasilania (230V lub 12V). Układy były zamykane w standardowych obudowach i nie były na eksponowanych, widocznych miejscach. Elektroniką zajmuję się czysto amatorsko i swoje układy buduję na płytkach uniwersalnych. W przypadku pojedynczej sztuki nie stanowi to problemu – jest to szybkie i wygodne. Opanowałem sztukę takiego rozmieszczania elementów i doginania wyprowadzeń, że „ścieżki” powstają niejako same, a ilość połączeń osobnymi przewodami jest minimalna. Stanąłem jednak przed problemem przygotowania czujników temperatury dla każdego pomieszczenia – 6 sztuk. Czujniki te z założenia miały mierzyć temperatury w sposób reprezentatywny – nie mogłem ich ukryć na szafie, czy za meblami. Do tego miały być zasilane bateryjnie/akumulatorowo i chciałem uzyskać czas działania min. 6 miesięcy lub nawet lepiej – 1 rok przy interwale wysyłanych danych co 5 minut. Klasyczne rozwiązania oparte o ESP nie podołają temu, a do tego wymagałyby zasilania z dwóch baterii AA lub akumulatorów LiFePo4. Akumulatory Li-Ion w pełnym naładowaniu mają za wysokie napięcie i wymagają stabilizatora, który będzie pochłaniał dodatkowe uA. Wymyśliłem więc układ oparty o ATTINY 2313 i ESP. ATTINY robi cały pomiar i staruje ESP poprzez CH_PD i UART. Mam już jeden termometr własnej konstrukcji oparty o ATTINY i nadajnik Telecontrolli. Na trzech bateriach AAA pracuje kilka lat. Układy ATTINY naprawdę są bardzo oszczędne jeśli się odpowiednio je oprogramuje, wyłączy zbędne moduły i nie pozostawi wejść bez podciągania. Dodatkowo układ ten może pełnić funkcję Watchdoga dla ESP, jeśli ten nie potwierdzi wysyłki w zadanym czasie. Oczywiście ESP musi pracować na stałym IP i przesyłać dane na lokalny serwer, także identyfikowany po IP. Jednak po przemyśleniu całości przyszło zniechęcenie – niezbyt mi się podobała koncepcja zastosowania dwóch procesorów aby zmierzyć temperaturę, podejrzewałem też kłopoty z estetyką tego rozwiązania i rozmiarami – sam akumulator nie jest przecież mały. Do tego technologia płytki uniwersalnej przy 6 sztukach też nie była optymalnym rozwiązaniem.
Zacząłem szukać innych rozwiązań – tu kuszącą propozycją są rozwiązania oparte o BlueTooth zwłaszcza BLE. Wiedziałem, że nie będzie problemu z długim działaniem na zasilaniu bateryjnym. Urządzenia takie są też zwykle małe. Jedyny problem to zasięg. Czytałem wiele o zasięgu i wiedziałem, że nie jest różowo. U mnie całość miała działać w domku o 2 kondygnacjach ze stropem żelbetowym i gipsowymi tynkami. Postanowiłem jednak zaryzykować. Jako odbiornik BT zakupiłem Raspberry pi 3 – ma on docelowo pełnić 2 funkcje – jako urządzenie komunikacyjne BT i jako router WiFi dla urządzeń IoT. Ta druga funkcja wynika z faktu, że nie chcę aby urządzenia IoT pracowały na standardowym, domowym WiFi, choćby z powodu problematycznego zmieniania hasła. Dodatkowo osobny router może mieć złożone hasło i kontrolować ruch w domowej sieci. Wróćmy jednak do czujników temperatury na BT. Wybór padł na Xiaomi Mijia bluetooth temperature & humidity sensor. Na tej stronie: Link znalazłem opis jak dostać się do wysyłanych danych bez oryginalnego odbiornika BT Xiaomi.
Bazując na tym przykładzie stworzyłem skrypt, który odczytywał dane z Xiaomi. Działa to bardzo dobrze, ale są problemy z zasięgiem, czego się niestety obawiałem. Ostatecznie odczyt działał na tym samym piętrze, gdzie było Pi 3 i do tego nie w każdym miejscu. Komunikacja z Xiaomi jest dwukierunkowa – oznacza to że oba urządzenia coś wysyłają i odbierają. Mały zasięg może być zatem winą Pi 3, a nie termometru, tym bardziej, że monitor BLE na komórce „łapał” sygnał przez żelbetowy strop. Dla mnie jednak rozwiązanie się nie sprawdziło. Były okresy, że brak odczytu trwał kilka godzin i później wracał. Nie lubię takich niepewnych urządzeń, zwłaszcza, że termometry miały sterować ogrzewaniem.
Postanowiłem dać BT jeszcze jedną szansę – zakupiłem czujnik temperatury iNode. Są one niezwykle małe, a do tego dystrybutor napisał, że pracują z mocą +8dBm. Stosują one także inną technologię – dane wysyłane są w pakiecie rozgłoszeniowym, zatem nie są istotne właściwości nadawcze Pi – musi on tylko odczytać ramkę rozgłoszeniową. Urządzenie przyszło i pierwsze próby niestety skończyły się rozczarowaniem. Przez strop nie dało się niczego odebrać. Napisałem jednak do dystrybutora, z jaką mocą standardowo pracują te nadajniki i dostałem odpowiedź, że -2dBm. Dostałem także informację, że przy pomocy aplikacji na komórkę mogę to zmienić – tu minus dla dystrybutora – z urządzeniem nie przychodzi żaden opis nawet w postaci linku do instrukcji czy programów do sterowania; nie ma też mowy o tym, że urządzenie pracuje z -2dBm. Po przestawieniu na +8dBm byłem zachwycony. Strop nie stanowił przeszkody. W najdalszym kącie domu tracona (nieodebrana) była tylko co druga ramka. iNode nadaje standardowo co ok 1s, a ja na odbiór czekam 2 minuty mam zatem aż 60 poprawnych ramek! Od razu zmieniłem parametry iNode – czas zwiększyłem do maksimum (ok. 10s) i wyłączyłem niepotrzebne diody LED. Muszę powiedzieć, że rezultaty są wspaniałe – dokupiłem te czujniki do pozostałych pomieszczeń. Działają bezbłędnie od ponad pół roku. iNode wysyła także przybliżoną wartość napięcia baterii. Ja ze względu na posiadane Xiaomi (teraz są one w pomieszczeniach najbliższych odbiornikowi) napięcie pokazuję w procentach, gdzie 3V i więcej to 100%, a 1.8V to 0%). Po pół roku działania mam 100%! Zachęcony rezultatami zakupiłem kolejny iNode z myślą jego wystawienia na zewnątrz. Tu także spisuje się wyśmienicie mimo ujemnych temperatur w zimie. Przy mroźnych dniach napięcie spadało do 80%, ale teraz znowu jest 100%.
Na stronach iNode znalazłem przykładowy skrypt do odczytu danych. Działał on jednak na zasadzie startu przy starcie Pi. Z doświadczenia wiem, że takie rozwiązanie zawsze kiedyś przestaje działać. Postanowiłem zatem oprzeć się o cron’a, który będzie powtarzał cały proces co 5 minut. Jeśli coś się nie powiedzie będzie kolejna szansa za 5 minut. Oto główny skrypt:
Code: bash
Log in, to see the code
Pierwsze dwie linie odpowiedzialne są za odczyt Xiaomi. „timeout” odpowiada za „zabicie” procesu jeśli będzie trwał ponad 60s.
Oto zawartość bt_temp_mi.sh:
Code: bash
Log in, to see the code
Skrypt powstał w oparciu o wcześniej przywołaną stronę. Ma dwa parametry – MAC oraz numer czujnika. Jego dostosowanie do własnych potrzeb polega na zmianie adresów i parametrów w „wget”. Oczywiście trzeba też przekazać właściwe adresy MAC. Jednak głównym celem był odczyt z iNode. Główny skrypt uruchamia skanowanie na 120 sekund (hcitool) a następnie czyta dane z pakietów rozgłoszeniowych poprzez hcidump. Odczytywane dane przesyłane są do skryptu „bt_inode.sh”. Oto jego zawartość:
Code: bash
Log in, to see the code
Dostosowanie skryptu do własnych potrzeb, to przede wszystkim zmiana adresu i parametrów w „wget”, zmiana adresów MAC (tutaj są bez dwukropka). Oczywiście należy też skonfigurować własne pomieszczenia.
Uwagi do skryptu
Skrypt bazuje na „hcidump” – jeśli ulegnie zmianie format danych w tym programie, to oczywiście skrypt przestanie działać. Drugim problemem jest format ramki rozgłoszeniowej. Jest tam spora liczba nagłówków, a adresacja poszczególnych bloków powinna być względna. Ja dla uproszczenia zastosowałem adresację bezwzględną – jeśli jednak producent iNode zmieni format, to skrypt także przestanie działać. Tu nie mam obaw – ewentualna zmiana ramki wymaga upgrade iNode, a ja nie mam zamiaru tego robić. Wszystkie programy użyte w skrypcie były na Pi lub można je zainstalować poprzez apt-get. Nie było potrzeby pobierania źródeł i kompilacji czegokolwiek.
Podsumowanie
Metoda zastosowana przez iNode – wysyłania danych w ramce rozgłoszeniowej jest bardzo dobra, a moc +8dBm wystarczająca na domek jednorodzinny.
Cool? Ranking DIY
