Moduł dopuszkowy IoT – czyli moje podejście do Inteligentnego Domu

Nieopatrznie parę dni temu pochwaliłem się na forum w jednym z komentarzy fotkami swoich modułów. Wywołało to małą lawinę wiadomości prywatnych o to co tam wymodziłem, jak to działa oraz czy mogę się tym podzielić z innymi… Aby nie odpowiadać na te wszystkie pytania po raz setny – piszę tutaj!

Motywacja

Zanim pochwalę się swoją konstrukcją i tym jak ona działa, chciałbym, tytułem wstępu, powiedzieć kilka zdań na temat motywacji jaka mną kierowała. Otóż jestem właśnie na etapie budowy domu i oczywiście od samego początku, jak tylko zapadła decyzja o budowie, wiedziałem, że mój dom musi posiadać pewne elementy automatyki budynkowej lub nawet pewne cechy domu inteligentnego.
Zacząłem więc przeglądać internety w poszukiwaniu inspiracji jak to robią inni. Przejrzałem systemy gotowe, takie jak np. fibaro czy zamel. Spojrzałem też na fora i grupy jak wygląda DIY w tej materii. Potestowałem różne rozwiązania kontrolerów open-source (m.in. domoticz, openhub, HA itp.). Systemy komercyjne, które oglądałem, nie spodobały mi się, pomijam już tutaj cenę, która jest zaporowa (po skalkulowaniu funkcjonalności jaka by mnie interesowała, same graty do instalacji zamknęłyby się kwotą pięciocyfrową), to ich funkcjonalność była dla mnie niewystarczająca, a czasami nawet nie do zaakceptowania. DIY z kolei mnie przeraziło. To co ludzie wyprawiają i w jaki sposób budują swoje „inteligentne domy” przyprawiło mnie o zawrót głowy. Już pomijając błędy w architekturze, czy tworzenie tzw. single point of failur, niejednokrotnie narażali siebie i swoją rodzinę na niebezpieczeństwo. Ale zostawmy to, nie mnie to oceniać i pouczać.
W każdym bądź razie te obserwacje zainspirowały mnie do stworzenia własnego rozwiązania, które wykorzystam u siebie, i którym podzielę się ze społecznością IoT DIY – czyniąc, mam nadzieję, ten ekosystem lepszym miejscem 😉

Pomysł

Pomysł był taki, aby stworzyć moduł wykonawczy/multisensor, który będzie możliwie uniwersalny, i możliwie tani – przy czym jednocześnie bezpieczny i dobrze zaprojektowany. Chciałem wyeliminować te wszystkie błędy, które większość osób popełnia (jak np. topologia gwiazdy – centralizacja sterowania) i dać gotowe, w miarę uniwersalne narzędzie do konfigurowania i budowy sensorów i modułów wykonawczych.
W sieci znalazłem projekt o nazwie MySensors, który jest protokołem komunikacyjnym przeznaczonym dla urządzeń IoT. Na stronie projektu można znaleźć biblioteki implementujące tenże protokół oraz przykłady kodu wykorzystujące go. Projekt spodobał mi się na tyle, że postanowiłem go zaadaptować u siebie jako warstwę komunikacji. W moim odczuciu jest to tam dość dobrze zrobione i zdejmie ze mnie sporo pracy związanej z obsługą komunikacji.
Kolejnym założeniem była zgodność z Arduino – dzięki temu, osoby które nie posiadają rozbudowanej wiedzy z zakresu programowania czy mikrokontrolerów, będą w stanie same bawić się i rozwijać, czy kustomizować swoje urządzenia.
Chciałem również by płytka którą zaprojektuję była możliwe uniwersalna i również konfigurowalna – w zależności od tego w jakie elementy zostanie wyposażona będzie mogła spełniać różne funkcje.

Budowa

Moduł dopuszkowy MySensors

Na powyższej grafice zilustrowałem 3 wersję mojego modułu. Dwie poprzednie posiadały różnego rodzaju drobne błędy, a także zostały zmodyfikowane po praktycznym przetestowaniu ich w akcji – kilka takich modułów pracuje już parę miesięcy u mnie w biurze. Na płytce mamy procek Atmela (teraz to już Microchip) Atmega328p w obudowie tqfp32. Zasilany jest z przetwornicy impulsowej 5V. Dodatkowo mamy stabilizator 3v3 dla radiówki na NRF24. Oprócz tego mamy opcjonalny stabilizator 5V, który możemy wlutować wraz z dwoma zworami i zasilać układ napięciem stałym dostarczanym zewnętrznie.
Płytka posiada również dwa przekaźniki elektromechaniczne o obciążalności do ok. 5A oraz zestaw złącz (pinów), które są wstępnie w sofcie przygotowane do podłączenia zewnętrznych przycisków, czujników, termometrów i innych sensorów. Piny te są w taki sposób wyprowadzone, że odpowiadają kolejnością wyprowadzeń popularnym czujnikom takim jak DS18B20 czy HTU210. Dzięki temu podłączanie ich jest bardzo proste. Samo włączenie ich obsługi w sofcie to tylko wprowadzenie odpowiedniego configu. Płytka dodatkowo jest wyposażona w wyprowadzony port szeregowy, który może służyć do debugowania (PC) lub jako port rozszerzeń jeśli np. chcemy do jednego modułu podłączyć dodatkową płytkę z np. 40-toma przekaźnikami 😉
Na płytce również znajduje się miejsce na 3 mosfety w obudowach TO-220, które są sterowane z wyjść PWM procka i mogą zostać wykorzystane do sterowania taśmami LED RGB (w takiej konfiguracji działa to u mnie w sypialni i spisuje się świetnie).

PCB modułu dopuszkowego mysensors - inteligentny dom

Komunikacja

Moduł inteligentnego domu - komunikacja

Z założenia moduły mają być autonomiczne, tzn. pstryczek który włącza światło w salonie, jest podłączony do modułu w puszcze. Moduł ten po zwarciu styków przełącza przekaźnik, a poprzez stację bazową tylko informuje kontroler o zmianie swojego stanu. W ten sposób jeśli komunikacja zawiedzie, kontroler przestanie działać, serwer, na którym mamy domoticza (lub inny) kontroler padnie, to układ dalej działa i możemy włączyć światło w pokoju. Co więcej, mamy tutaj bogatą możliwość konfiguracji, ponieważ w powyższym przykładzie możemy wykorzystać przełączniki chwilowe i generować sygnał (stanu niskiego), który będzie przełączał – toggle – przekaźnik lub możemy zastosować zwykły przełącznik bistabilny i reagować na zmiany stanów. Także opcji jest tutaj wiele i nic nas nie ogranicza.
Moduły do komunikowania się mogą być wyposażone w moduł NRF24 lub w układ MAX485, także można podłączać je do magistrali kablowej RS485 lub radiowo. O ile do magistrali rs485 nie muszę chyba nikogo przekonywać, to wybór NRF-a jako radiówki był podyktowanym tym, że jest on bardzo fajnie obsługiwany przez MySensors. W tej konfiguracji ma sporą przewagę nad innymi rozwiązaniami. Sama topologia sieci bezprzewodowej opartej na tym rozwiązaniu jest pancerna. Mamy moduły które komunikują się między sobą direct oraz poprzez stację bazową korzystając z tras routingu (np. moduł A wysyłając info do bramki może je przesłać przez moduł C i D, które przekażą informację dalej). Mamy też możliwość ustawienia każdego z modułów jako repeatera sygnału co zwiększa zasięg sieci. Generalnie jeśli moduły zostaną prawidłowo wdrożone jest to rozwiązanie bardzo solidne.

Inteligentny dom - komunikacja modułów

Większość rozwiązań które oglądałem było skonstruowane w ten sposób, że moduły, bądź pstryczki, dawały sygnał do kontrolera, a ten podejmował decyzję i wysyłał zwrotnie sygnał do modułu wykonawczego który np. przełączał przekaźnik. W takim układzie jeśli kontroler, arduino czy komputer lub raspberry pi z domoticzem ulegnie uszkodzeniu lub po prostu z jakiegokolwiek powodu nie będzie dostępny, cały układ nie działa. W wykorzystaniu domowym, takie rozwiązanie jest nieakceptowalne.
Jak wspomniałem powyżej, moduły mogą się komunikować między sobą direct, czyli z pominięciem bramki czy kontrolera (np. domoticz). Zarówno korzystając z opcji radiowej NRF24 jaki i kablowej RS485, moduły mogą wymieniać się informacjami między sobą bezpośrednio. Np. nasze moduły znajdują się w puszkach elektroinstalacyjnych na dwóch końcach salonu (patrz: rysunek powyżej). Do modułu A mamy podłączony przełącznik, a do modułu B mamy podłączone oświetlenie salonu oraz również pstryczek. Po kliknięciu na przycisk podłączony do modułu A, wysyła on info bezpośrednio do modułu B, aby ten włączył światło. Następnie moduł B wysyła informację o swoim aktualnym stanie do kontrolera (domoticz). Przy czym po naciśnięciu pstryczka podłączonego bezpośrednio do modułu B również możemy światło włączyć lub je zgasić. W ten sposób tak długo jak działają te dwa moduły, będziemy w stanie sterować światłem w salonie, nawet jeśli cała reszta naszego systemu ulegnie awarii bądź zostanie wyłączona.
Dodatkowo sam protokół obsługuję ACK (czyli potwierdzanie otrzymania wiadomości), a ja dopisałem jeszcze dodatkowo mechanizm, który po otrzymaniu komunikatu z np. kontrolera (domoticz), odsyła otrzymaną wartość z powrotem w celu weryfikacji stanu urządzenia po wykonaniu komendy. Mamy mówiąc inaczej proste sprzężenie zwrotne. W efekcie tego kontroler np. domoticz, wie zawsze w jakim stanie faktycznie znajduje się moduł.

Co dalej?

W tej chwili składam właśnie wersję 4 modułu, która dodatkowo wyposażona jest w dwa układy ASC712, dzięki którym będzie można szacunkowo określać wykorzystanie energii elektrycznej przez podłączone do przekaźników urządzenia. Nowa wersja jest też o 4mm mniejsza, dzięki czemu łatwiej upycha się ją w puszce, w której znajdują się sztywne kable elektryczne.
Oprócz przedstawionego modułu, wykonałem jeszcze trzy rodzaje stacji bazowych. Są to stacje ethernet na W5100 radiowa i druga kablowa, które bazują na tym samym PCB, a różnią się tylko wlutowanymi komponentami. Mamy także nakładkę na Raspberry Pi, zmieniającą ją w stację bazową, która może być radiowa lub kablowa (rs485) w zależności co wlutujemy w płytkę. Wszystkie te elementy są już od kilku miesięcy przeze mnie testowane. W biurze mam dwie stacje: radiową i kablową ethernet, które komunikują się z kilkoma modułami zabudowanymi w budynku, a z drugiej strony z domoticzem, postawionym na wirtualce w dokerze na normalnym serwerze 19”. Jest tam też kontener z MyDomoAtHome. Natomiast w domu, mam RPi wraz z nakładką radiową i zainstalowanym domoticzem i MyDomoAtHome. Zarówno pierwszy, jak i drugi setup póki co działa bezproblemowo od dłuższego czasu.
Oprócz w/w stacji przygotowałem jeszcze moduł, który posiada tylko jeden przekaźnik, ale za to wysoko obciążalny, który również testuję w biurze od dłuższego czasu (przełącza bojler z wodą – kilka kW).

Dostępne moduły i stacje bazowe inteligentny dom

Podsumowanie

Póki co projekt się sprawdza. Było kilka przebojów technicznych przy pierwszych prototypach, jednak w tej chwili, wydaje mi się, że wszelkie mankamenty już usunąłem. To nad czym teraz pracuję to dostosowanie modułów do obowiązujących norm – jestem już po zleconej analizie przedwdrożeniowej i normy są już określone. Następnie poddam je certyfikacji. Pomysł jest taki, aby dać społeczności DIY rozwiązanie, które będzie bezpieczne, pewne, będzie dawało spore możliwości, a jednocześnie nie spowoduje, że zostaniemy ukarani przez ubezpieczyciela w przypadku jakiegoś nieszczęścia (np. pożar). Zapraszam do komentowania, wszelkie sugestie są mile widziane. Jeśli zainteresowanie tematem będzie odpowiednie może uda się razem stworzyć coś fajnego 😉

21 odpowiedzi na “Moduł dopuszkowy IoT – czyli moje podejście do Inteligentnego Domu”

  1. Piotr pisze:

    Czy jest możliwość zaprogramowania ściemniania oświetlenia? Albo sterowania roletami?

  2. leniwiec pisze:

    @Piotr tak, można sterować taśmami led, wspomniałem już o tym:
    “Na płytce również znajduje się miejsce na 3 mosfety w obudowach TO-220, które są sterowane z wyjść PWM procka i mogą zostać wykorzystane do sterowania taśmami LED RGB (w takiej konfiguracji działa to u mnie w sypialni i spisuje
    się świetnie). ”
    Natomiast jeśli chodzi o sterowanie oświetleniem 230V np. żarówki, to na płytce już nie ma miejsca na to. Można natomiast zastosować rozszerzenie i sterować nim z modułu. Wówczas będzie to wykonalne 😉

  3. Marcin pisze:

    Bardzo Ciekawy projekt !!!
    Zycze powodzenia
    Powinienes pomyslec o wprowadzenie takiego produktu na sprzedarz
    Bylo by wielu chetnych

  4. nelumeh pisze:

    Profesjonalne podejście do tematu DIY. Podoba mi się pomysł uniwersalnego modułu, mam nadzieje że uda się dokończyć temat aby był zgodny z normami.

  5. Stormy pisze:

    Ciekawy wpis.
    Jestem w trakcie tworzenia podobnego systemu, widzę tylko, że odrobinę różnimy się podejściem.
    Również uważam, że moduły muszą być sterowane lokalnie i działać bez komunikacji z serwerem, ale jednak jestem zwolennikiem specjalizowanych modułów a nie uniwersalnych.
    Na razie zaprojektowałem moduł dopuszkowy z przekaźnikami: https://www.openhardware.io/view/670/MySensors-InCan-double-light-switch
    oraz schielda do NRF dla Gatewaya: https://www.openhardware.io/view/671/NRF24L01-shield-for-Arduino-Uno-for-MySensors-gateway
    W trakcie testów mam (jeszcze nie opublikowałem na openhardware.io) Gateway EthernetRS485 na szynę DIN (szerokość 2 modułów) oraz moduł wykonawczy z 4 przekaźnikami na RS485 również na szyną DIN (szerokość 4 modułów).
    W twoim wpisie zainteresował mnie szczególnie następujący fragment: “a ja dopisałem jeszcze dodatkowo mechanizm, który po otrzymaniu komunikatu z np. kontrolera (domoticz), odsyła otrzymaną wartość z powrotem w celu weryfikacji stanu urządzenia po wykonaniu komendy”.
    Czy mógłbyś udostępnić więcej szczegółów? A najlepiej podzielić się stosownym fragmentem kodu?
    Mam dokładnie taki sam pomysł na potwierdzanie stanu i miałem to pisać, ale skoro już ktoś to zrobił to po co wyważać otwarte drzwi?
    I jeszcze nie do końca zgodzę się, że komunikacja MySensors jest pancerna. Niestety nie jest. Czasami zdarza się że jakiś pakiet zaginie.

  6. feanor-anglin pisze:

    Czy zamierzasz opublikować gdzieś pliki źródłowe? Chętnie zapoznałbym się ze szczegółami projektu.

  7. leniwiec pisze:

    @feanor-anglin, tak, ale dopiero jak będę mieć finalną wersję 😉

  8. leniwiec pisze:

    @Stormy, tak, uniwersalne bo to ma być platforma 😉 No i koszta, tanie jest mi wyprodukować 200 takich samych płytek w panelu i tylko różnie je obsadzić elementami w zależności od potrzeby.
    Kod jest bardzo prosty, chodzi o odesłanie wartości po zmianie stanu. Czyli: urządzenie zmienia swój stan, autonomicznie, albo za sprawą otrzymanego z zewnątrz komunikatu, po czym po wykonaniu komendy np. zmianie stanu przekaźnika, sprawdzam czy faktycznie przekaźnik się przełączył, po czym wysyłam do bramki V_STATUS z prawdziwym stanem. W ten sposób domoticz zawsze pokazuje realny stan, a nie stan wynikający z sekwencji poleceń. Jak do tego dodamy odpowiednią konfigurację domoticza i włączymy ACK, to będzie pancernie. Nawet jak się pakiet zgubi, to domoticz będzie do skutku szturmował bramkę i moduły, aż otrzymany z powrotem stan będzie taki sam jak zadany. Można później się z tym bawić i robić limity, np. 5 prób, po czym oznaczamy moduł jako uszkodzony. itd. Dlatego właśnie w moim odczuciu ta komunikacja jest pancerna 😉

    • Stormy pisze:

      @Leniwiec
      OK, rozumiem.
      Ja myślałem raczej o czym takim jak tutaj:
      https://forum.mysensors.org/topic/1467/how-to-deal-with-a-request-for-information-from-controller/14
      czyli że to kontroler (np. Domoticz) może się w dowolnym momencie zapytać moduł o jego stan.
      Bo Twoja metoda ma jeden słaby punkt – jeżeli przełącznik zostanie przełączony w momencie jak kontroler nie chodzi (jakiś problem z siecią, lub chociażby po załączeniu zasilania – przyciski wstaną znacznie szybciej niż kontroler) to Domoticz nie ma szans znać prawdziwego stanu przycisku. Wtedy prosty skrypt który odpyta poszczególne moduły i ustawi prawdziwe stany rozwiązuje problem. Tak samo można się upewnić po zmianie stanu – przełączyć, a np. po 1 sek odpytać o stan.
      A tak w ogóle to docelowo będę to robił na OpenHab zamiast na Domoticzu chociaż Domoticza bardziej lubię. Ale OH ma 2 przewagi nad D: OpenHab Panel – gdzie możesz sobie porobić piękne panele sterujące np. wieszając w domu tableta i ustawionego na “kiosk mode” i ma znacznie więcej bindingów do różnych urządzeń. Z wad to konfiguracja jest mało sympatyczna i jest w Javie i Eclipse (czyli uruchamia się wielka kobyła).

      • leniwiec pisze:

        Ale u mnie kontroler może się zapytać o stan 😉 Tyle że stany dodatkowo są raportowane, inaczej to by sensu nie miało.

  9. pit_i_mat pisze:

    Hej,
    Muszę powiedzieć, że całość zrobiła na mnie ogromne wrażenie-pomysł i wykonanie po prostu super.
    Czy mógłbyś powiedzieć jak wyglądają ramki danych jakie przesyłasz między Domoticz, a przekaźnikami i włącznikami po RS485? Chodzi mi o sterowanie i status przekaźnika w Domoticz.
    Sam coś swojego zacząłem kombinować, ale za dużo tego wszystkiego na początek.

    • leniwiec pisze:

      pomiędzy RS485 a Domoticzem (lub innym kontrolerem) jest jeszcze po drodze bramka. Bramka może być albo ethernetowa, albo serial (usb, rs232) lub w postaci nakładki na RPi. Natomiast stacja bazowa komunikuje się z nodami (płytkami w puszkach itp.) już po rs485 lub radiowo (mesh). Po rs485 latają dane spakowane w protokół mysensors. Komunikacja jest dwukierunkowa, czyli moduł raportuje stan faktyczny jak i odbiera komendy.

      • pit_i_mat pisze:

        Dziękuję za odpowiedź. Jednak zbyt skrótowo napisałem 😉
        Oczywiście wiem o bramce, dokładnie miałoby to u mnie wyglądać tak:
        PC (Domoticz) -> USB -> Arduino NANO (bramka MySensors RS485) -> MAX485 <> klient MAX485 -> ATmega328
        Kod piszę w BASCOM i będę próbował się przystosować do tego co jest w oryginale tylko nie wiem jak wyglądają ramki danych w komunikacji.

        • leniwiec pisze:

          czemu taka decyzja? Protokół w mysensors jest dobrze przemyślany, jest ack, potweirdzenie odbioru ramki, kontrola kolizji itd. itp. Napisanie tego wszystkiego samemu i zdebugowanie do takiego poziomu zajmnie masę czasu. Nie wiem jak to w BASCOmie wygląda bo z niego nie korzystam, ale osobiście doradzał bym skorzystanie z biblioteki mysensors i tylko dopisanie samemu tego co potrzeba, naprawdę sporo problemów w ten sposób zostaje rozwiązanych 🙂

          • pit_i_mat pisze:

            Wiem, że BASCOM nie jest najlepszym językiem, ale w nim potrafię jeszcze coś tam zrobić, a Arduino to dla mnie taki trochę język eskimoski 🙂
            No to może inaczej… da się zrobić sterowanie na ATmega328 pod MySensors gdybym chciał osiem przycisków, osiem przekaźników i RS485-plytkę już mam zrobioną.

        • leniwiec pisze:

          Bezproblemowo 😉 Pokaż schemat swojej płytki to pomogę to ogarnąć 😉

          • pit_i_mat pisze:

            Wysłałem pliki na e-mail. Mam nadzieję, że używasz EAGLE.
            Nie przestrasz się bo to dzieło niedzielnego amatora elektroniki 😉
            Z góry dziękuję za pomoc. Widzę, że trzeba będzie się wziąć za tego “stwora” Arduino i się z nim zaprzyjaźnić.

Dodaj komentarz

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