Smart Home w wersji Open source – jak zbudowałam Inteligentny Dom

Smart Home i IoT. Dwa wyrażenia, które były dla mnie od zawsze buzzwordami. Nadużywane, otoczone tajemnicą, a w większości przypadków chodzi w nich po prostu o zwykłą komunikację pomiędzy urządzeniami. Wszystko sprowadza się do łatwiejszej lub trudniejszej konfiguracji (o koszcie sprzętu i wiedzy nie piszę ;)).

Ponieważ temat jest owiany tajemnicą i stanowi niszę, stwierdziłam, że spróbuję swoich sił. Chciałam zobaczyć, czy ja, jako tester, QA Architect ze znajomością programowania i DevOps, jestem w stanie przy pomocy narzędzi Open source’owych zbudować swój Inteligentny Dom 😉 Jak to wyszło? Czemu wybrałam X, a nie Y? Co bym tym razem zrobiła inaczej? Zapraszam do lektury.

Skąd pomysł na zabawę ze stworzeniem Smart Domu?

Zacznijmy od tego, że jestem leniwa. Produktywnie, ale wciąż leniwa. Wieczorem, wychodząc spod prysznica, nie wyłączam wiatraka w łazience. Później ten wiatrak jest uruchomiony do rana albo z dużym oporem wstaję zaspana z łóżka, by kliknąć wyłącznik. Bez sensu. Tak samo, przechodząc z salonu do sypialni, chciałabym jednym kliknięciem wyłączyć wszystkie światła w salonie i zapalić na chwilę światło w korytarzu (np. na 3 sekundy), żebym zdążyła przejść do łazienki/sypialni. Wiesz, ile to wysiłku obsłużyć wszystkie włączniki? 😉

I tu lenistwo się przydaje! Słyszałam o gotowych rozwiązaniach związanych ze sterowaniem światłem, gniazdkami etc. Jednak stwierdziłam „Meh! To nie dla mnie”. Nie dość, że kosztowne, to tak naprawdę wszystkie informacje zostaną udostępnione na zewnątrz (czyli ktoś może się łatwo dostać do mojej sieci). Chronię swoją prywatność, nie chcę, aby moje dane zostały niepotrzebnie udostępnione, dlatego wolę prywatną chmurę od publicznej.

Zatem jeśli nie chcę wydawać dużo pieniędzy, a chcę utrzymać bezpieczeństwo moich danych, to koszt musi być inny – mój czas. Przecież jestem techniczna, więc bez problemu dam sobie radę, bo czego się nie robi w imieniu rozwoju. I jeszcze zdobędę dodatkowe doświadczenie! Pewnie bolesne, frustrujące, ale pod koniec będę zadowolona 😉

Komunikacja między urządzeniami

Zanim przejdę do opisu moich przygód z konfiguracją i wyborem odpowiednich narzędzi, chciałabym wspomnieć o tym, jak w Smart Domu urządzenia się porozumiewają.

W komunikacji mamy nadawcę i odbiorcę. W moim przypadku nadawcą może być: aplikacja w telefonie z zaprogramowaną automatyzacją lub fizyczny przycisk. Odbiorcą jest odpowiednie zachowanie (np. zapal światło w kuchni). Ale skąd mają wiedzieć, że owe role są im przypisane?

Ano za pomocą bramki. Bramka to urządzenie, które jest centralką zarządzającą całą komunikacją. I tu bym mogła zakończyć artykuł, gdyby nie to, że chciałam mieć większą swobodę. Nie czułam potrzeby, by być ograniczaną przez jakąś firmę. Gotowe rozwiązania zazwyczaj powodują trudniejszą integrację między różnymi producentami, brak możliwości modyfikacji czy przesyłanie danych, których nie chcę pokazywać światu. Zazwyczaj też wiąże się to z wyższym jednorazowym kosztem lub abonamentem.

Dlatego postanowiłam, że skonfiguruję własną centralkę! Podstawę już miałam: Raspberry Pi4, na którym został zainstalowany jeden system – Octoprint. Brakowało mi jedynie urządzenia, które posłuży jako węzeł początkowy (czyli coś, do czego podłączysz pozostałe urządzenia zgodne z IEEE802).

Zaletą takiego rozwiązania jest dowolność w konfiguracji i modyfikacji zachowania. Coś czego gotowe bramki mi nie zapewnią. Spoiler alert: teraz bym użyła dockerowych obrazów, aby skonfigurować urządzenia, jednak ja wybrałam inną ścieżkę. Jak się później okazało… dla zaawansowanych.

Jaki cel chciałam osiągnąć przy pomocy IoT?

Na pewno sterowanie oświetleniem! Tak – oczami wyobraźni już widziałam siebie leżącą na kanapie i z telefonu wyłączającą światła, bądź też sprawdzającą wilgotność w danym pomieszczeniu. Rozważałam też możliwość automatycznego włączenie wiatraka, gdy wilgotność przekracza 60%.

No więc zaczęłam, jak przystało na prawdziwego amatora-przyszłego eksperta, się dokształcać! Czytałam, co można zrobić i jak. I wtedy przyszło olśnienie. Frustracja też 😉 Co by zrobił architekt IT w sytuacji, gdy zaczyna nowy projekt? Oczywiście rozrysował diagramy z etapami. Co, gdzie i do czego. Z tego podejścia zrodził się schemat, który jest widoczny poniżej (już w docelowym narzędziu Node-Red, o którym napiszę później), czyli przeniesienie na papier moich pomysłów dotyczących tego, jak bym chciała ułatwić sobie życie. Dzięki temu wiedziałam już, ilu urządzeń potrzebuję i mniej więcej jakiego typu przełączników szukać.

Miałam już cel, miejsce, schemat działania. Brakowało tylko plany, jak wykonać projekt i jakich narzędzi użyć.

Wybór narzędzi – hardware

Po przejrzeniu Allegro, Aliexpress i przeczytaniu kilku artykułów wybór sprzętu okazał się łatwy. Patrząc na sukcesy i porażki innych osób, zdecydowałam się na urządzenia obsługujące bezprzewodowy protokół Zigbee.

Zalety tego protokołu:

• łatwość zwiększenia zasięgu przez instalacje przekaźników (rola:router),
• mało zawodny,
• transmisja danych jest uwierzytelniona,
• dwustronna komunikacja,
• natychmiastowy dostęp (protokół również stosowany w czujnikach ruchu),
• łatwość w tworzeniu i rozbudowywaniu systemów,
• niekorzystanie z Wi-Fi.

Dla wybranego protokołu alternatywą może być Z-WAVE, który jest certyfikowany. Po porównaniu obu stwierdziłam, że Zigbee będzie wystarczający, tańszy i posiada bardzo duże wsparcie społeczności (choć jest ono chaotyczne). Dodatkowo, nie ma limitu połączeń i przekazywania danych w sieci mesh (Z-Wave ma limit do 4 urządzeń, a w sumie sieć może liczyć 232 połączone urządzenia. Wątpię bym kiedykolwiek tylu potrzebowała, ale po co się ograniczać).

Minusem może być częstotliwość, na której operuje Zigbee. Jest podobna do Wi-Fi, co mogło być wadą, ale na razie tego nie zauważyłam.

W Zigbee mamy 3 role:

• koordynator,
• router,
• urządzenie docelowe (gniazdka, przełączniki).

W tym jest tylko jeden fizyczny koordynator, a urządzenie docelowe może być również routerem. Jako koordynatora wybrałam za drugim razem klucz sprzętowy marki Sonoff. Pierwszy wybór padł na CC2531 z Aliexpress.

To był dobry, jednorazowy wybór. Urządzenie okazało się mocno niestabilne, jednak dla sprawdzenia czy warto pójść w stronę automatyzacji, jak najbardziej warte swojej ceny (40 PLN). Po kilku miesiącach mogę napisać, że Sonoff jednak jest mniej zawodny. Praktycznie ani razu nie miałam problemu.

I tak urządzenia zostały starannie dobrane, by nie korzystać z Wi-Fi. Ponadto, z kilku powodów wybrałam włączniki i przekaźniki firmy Tuya i Sonoff:

• jedyny poczwórny przełącznik, którego nie trzeba montować na puszce (czyli bez zmian w instalacji elektrycznej oraz z zachowaniem spójności wyglądu) – z firmy Tuya,
• zasilanie bateryjne,
• montaż w dowolnym miejscu,
• cena (pod koniec opiszę cały koszt).

Post factum: dopiero później, będąc w IKEI, zobaczyłam, że ta sieć również ma swoje przełączniki i centralę o nazwie IKEA Tradfri. Lidl również… Ale co to by była za zabawa, gdybym poszła na łatwiznę 😉

Ze względu na praktyczność (dane dostępne od razu) oraz wygląd, wybrałam czujniki wilgotności i temperatury marki Xiaomi. Wykorzystują one Bluetooth Low Energy.

Komputer, na którym wszystko zostało skonfigurowane, to Raspberry Pi4. W związku z tym, że w moim domu panuje czysto „nerdowski” klimat, znalazłam je obok lutownicy. Wcześniej służyło m.in.: do obsługi drukarki 3D oraz wystawieniu na świat moich aplikacji do szkoleń związanych z testami wydajnościowymi i API.

W związku z tym, że na malinie miałam już zainstalowany system (OctoPrint), nie chciałam używać obrazów dockerowych i modyfikować obecnego stanu. Uznałam, że przecież konfiguracja nowego software’u będzie banalna! Aj jak się myliłam…

Podsumowując: miałam schemat, jak mój Inteligentny Dom ma działać i wybrałam urządzenia. Nadszedł czas, by zająć się Softwarem!

Wybór narzędzi – software

Od razu podam: wybrałam HomeAssistant, Zigbee2MQTT, Mosquitto oraz Node-Red. Wyjaśnienie znajdziecie poniżej.

Na początku opiszę czego szukałam w oprogramowaniu:

• ładnego UI, który zapewni mi przyjazne korzystanie ze sterowania urządzeniami,
• łatwej automatyzacji zachowań (czyli algorytmu jak ma się zachować dane urządzenie po danej sekwencji),
• integracji między koordynatorem i urządzeniem docelowym,
• software’u do obsługi kolejek,
• urządzeń skonfigurowanych w sieci lokalnej,
• dostępu do urządzeń z każdego miejsca, w którym mam internet, łącząc się bezpośrednio do sieci domowej, a nie przez chmurę.

Tak jak już wspomniałam – chciałam działać w open source. Istniejące rozwiązania nie spełniały wszystkich powyższych warunków. Pozostało zatem zintegrowanie kilku oprogramowań.

Cel osiągnęłam m.in. za pomocą HomeAssistant przy użyciu którego, będąc poza domem, łączę się bezpośrednio do sieci domowej, a nie przez publiczną chmurę. Odpowiednia konfiguracja HomeAssistant, która pochłonęła kilka wieczorów i kaw, zapewniła mi pozorny spokój ducha, obsługę zachowań i bezpieczeństwo. Wspominałam, że nie wybrałam najłatwiejszej drogi, używając obrazów dockerowych? 😉

Dzisiaj już wiem, że dokonałabym zmian w konfiguracji Raspberry. Malina zostałaby przygotowana tak, aby uruchamiać kontenery dockerowe m.in.: z HomeAssistant, Node-Red, Octoprint. Wierzę, że ułatwiłoby to późniejsze modyfikacje, aktualizację oraz zapewniłoby separację aplikacji.

HomeAssistant

HomeAssistant to aplikacja, którą oficjalnie można traktować jako centralny system do kontroli wszystkiego w domu. W moim przypadku jest to kontrola wysokopoziomowa, ponieważ traktuję ten program raczej jako UI do spięcia wszystkiego, co jest pod spodem. W teorii w sieci można znaleźć bardzo wiele instrukcji i dokumentacji, ale jak to często bywa – nie udało mi się znaleźć akurat tego, czego potrzebowałam.

Przy okazji stworzyłam ładny panel, który na telefonie wygląda następująco:

Do automatyzacji zachowań mogłam użyć HomeAssistant, jednak w tym wypadku wygrał Node-Red. Wg mnie jest bardziej intuicyjny (schemat przedstawiony wyżej), łatwy w obsłudze i po problematycznej konfiguracji HomeAssistant stwierdziłam: basta! Co prawda problemy konfiguracyjne były na moje własne życzenie, ale ileż można!

Node-Red

Narzędzie Node-Red pozwala w łatwy sposób wyklikać zachowanie i cały przepływ dla wydarzeń, które są niczym innym jak np. kliknięciem w przycisk. Fizyczne przyciski dają możliwość sterowania. Można na nich wykonać np.: dwuklik, jednoklik i długoklik. A to z kolei pozwala na stworzenie ciekawej konfiguracji. Na poniższym diagramie przedstawiłam jedno z zachowań dla przycisku w jadalni.

Dla podwójnego kliknięcia przypisałam następujące akcje:

• włącz światło w jadalni (o ile nie jest już włączone),
• po 3 sekundach wyłącz światła w kuchni (o ile nie są już wyłączone).

Na tym etapie wiedziałam, co chcę osiągnąć, zatem przyszedł czas na pokazanie narzędzia w akcji!

W aplikacji prezentuje się ono następująco. Po dodaniu przycisku do schematu określiłam, jakie rodzaje fizycznych kliknięć na urządzeniu docelowym mogą zostać wykonane i co je wywołuje (payload.action).

Następnie odpowiednio skonfigurowałam opóźnienia i ustawiłam wyłączenie świateł kuchennych.

Dodam, że z sypialni również mam możliwość wyłączenia wszystkich świateł w domu 😊

Jako minus możliwości konfiguracji tylu różnych zachowań i liczby fizycznych przełączników wpiętych w sieć muszę przyznać, że początkowo nie zawsze pamiętałam, co robi każde kliknięcie. Teraz jest już lepiej.

Zigbee2MQTT oraz Mosquitto

Mamy UI do inteligentnego domu, mamy zrobioną automatyzację dla przycisków, ale jakoś trzeba połączyć te dwa światy. I tu przychodzi z pomocą Zigbee2MQTT, czyli mostek lub oprogramowanie pozwalająca na integrację.

Mój klucz sprzętowy posiadał już firmware wgrany przez sprzedawcę, umożliwiający korzystanie z Zigbee2MQTT, dlatego wybór oprogramowania w tym przypadku był prosty. Połączenie sprzętu fizycznego z Zigbee2MQTT jest łatwe – po prostu wyszukujemy urządzenie w aplikacji i je parujemy. Coś co mi się spodobało – czytelne logi, w przyjaznej wizualnej formie.

Do obsługi kolejek użyłam Mosquitto. Niestety tutaj nie ma UI. Wybór był prozaiczny – pierwszy wynik z Google na temat implementacji MQTT. Oczywiście konfiguracja na Raspberry.

Podsumowanie

Czy było warto? TAK! Nauczyłam się wielu rzeczy jak np. Konfiguracja. Pogłębiłam swoją wiedzę o protokole Zigbee, Raspberry i wiem, że chcę więcej. Jestem również świadoma, że po początkowej frustracji na liczbę artykułów i mało przyjazną dokumentację przychodzi uspokojenie i powolne dążenie do celu. Dodatkowo, po dodaniu kilku linii kodu, wiatrak w łazience sam się włącza, gdy wilgotność będzie powyżej 60%, a wyłącza, gdy spadnie do 50%.

Koszt inwestycji: 700 PLN za urządzenia (bez Raspberry, ale kiedyś jego cena była równa 340 PLN). Biorąc pod uwagę czas i zdobyte doświadczenie, uważam, że koszt finansowy jest bardzo niski. Dzięki temu, czego się nauczyłam, niedługo przygotuję konfigurację Inteligentnego domu na większą skalę.

Jeśli chcesz przeczytać moje kolejne przygody z tego typu modyfikacjami – daj znać w komentarzu, ponieważ z tych poniższych urządzeń będę tworzyła cluster, a jego wykorzystanie już mam zaplanowane 😉

***

Jeśli interesuje Cię wykorzystanie mikrokomputerów Raspberry, polecamy artykuł naszego eksperta: .NET i Raspberry Pi – możliwości wykorzystania platformy na mikrokomputerach.