Napisz do mnie

Wyślij prywatną wiadomość

MĄDRY DOM - JAK Z NIM ROZMAWIAĆ?

opublikowano: 11 lut 2016 wyświetleń: 1487 komentarzy: 4

#dom inteligentny #HAPCAN #Open Source Automation #OpenHAB #Domoticz #Arduino #Raspberry Pi #HomeGenie #Node-RED #automatyka domowa #home automation

Zagłębiając się w tematykę automatyki domowej, nawet tej rozproszonej, prędzej czy później dociera się do miejsca, w którym chcemy mieć jakiś element nadrzędny, dzięki któremu w łatwy sposób będzie można "rozmawiać" ze swoim domem.

Centralny komputer

Za systemem rozproszonym przemawia jeden, niepodważalny argument — odporność na awarie. Nawet jeśli coś „wybuchnie“ i nie jest to główny zasilacz :), system w teorii powinien nadal funkcjonować. W systemie rozproszonym brakuje jednak takiego miejsca centralnego, z którego przeciętny użytkownik może zarządzać całym systemem. Często takim punktem staje się wiszący gdzieś na ścianie tablet — bo takie rozwiązanie jest relatywnie najtańsze.

Czego potrzebuję?

Jeśli nie miałeś okazji zapoznać się z innymi artykułami nt. automatyki domowej na moim blogu to przypomnę, że moim domowym systemem jest HAPCAN. Dysponuje on prostym interfejsem graficznym umożliwiającym stworzenie widoków pięter, pomieszczeń itp. i dodania do niego interaktywnych kontrolek umożliwiających sterowanie modułami oraz odczyt ich stanu.

Zrzut ekranu aplikacji Hapcan visualizer

Co jeśli jednak potrzebujemy czegoś więcej, co umożliwi obsługę także innych systemów, czujników, co w końcu pozwoli pobierać z Internetu jakieś zasoby i informować nas w taki czy inny sposób o tym, że za 2 godziny będzie padał deszcz, albo, że jadąc do pracy utkniemy w korku i należy pojechać inną drogą? A może po prostu chcemy mieć namiastkę Jarvisa z Ironmana, z którym będzie można „pogadać“ w języku naturalnym.

Wracając jednak do sedna, po przydługawym wstępie, porzuciłem (przynajmniej w tej chwili) złudną wizję stworzenia takiego systemu samodzielnie, całkowicie od podstaw — oczywiście jak to u mnie bywa, fragment takiego systemu stworzyłem. Chyba tylko po to, aby upewnić się, że jest przy tym masa roboty, na którą nigdy nie mam czasu ;).

Hapcan aplikacja

Czego zatem oczekuję od systemu?

  • musi być open source — żeby nie był zamknięty, wiadomo ;)
  • rozwijany z dużą grupą użytkowników
  • możliwość integracji z systemem HAPCAN
  • budowa modularna umożliwiająca w każdej chwili łatwą rozbudowę bez konieczności kompilowania kodu
  • możliwość pisania skryptów
  • interfejs graficzny pozwalający na własną ingerencję
  • możliwość dopisania własnych pluginów w C#

Poszukiwania systemu idealnego

Wspomnę jedynie, że poniższe opinie na temat sprawdzonych przeze mnie systemów są bardzo subiektywne i oceniałem je pod kątem własnych upodobań i potrzeb. Są to jednak systemy, które moim zdaniem warto obejrzeć samemu i wybrać ten najbardziej pasujący.

OpenHAB

Chwila spędzona w googlach i jest kilka pierwszych typów. Dużą popularnością cieszy się projekt OpenHAB. Lista obsługiwanych przez niego protokołów jest imponująca. Nie jest to jednak istotna dla mnie cecha. Na jego niekorzyść (biorąc pod uwagi moje potrzeby) przemawia również fakt, że działa on w środowisku java, zatem potencjalne pluginy musiałbym tworzyć w języku, który ostatnio widziałem 12 lat temu ;). Nie wchodziłem zatem w głębszą analizę tego środowiska.

Open Source Automation (OSA)

Open Source Automation jest dosyć ciekawym systemem napisanym w C#. Jest on oparty na MySQLu i w całości jest obiektowy. Każda rzecz, osoba, miasto czy plugin są z punktu widzenia OSA obiektami, posiadającymi własne (różne) atrybuty, mające metody (funkcje), które można wywoływać na tych obiektach.
System jest jeszcze w dość wczesnej fazie rozwoju i jego dokumentacja nie ułatwia rozpoczęcia z nim współpracy. Pomimo dość skąpego w wodotryski interfejsu konfiguracyjnego, zauważyłem w nim jeszcze sporo błędów, więc obecnie nie bardzo nadaje się on jako „środowisko produkcyjne“ :).
Jako ciekawostkę dodam, że system wymaga instalacji serwera MySQL oraz instaluje dodatkowo serwer HTTP, co sprawia, że sama instalacja jest, powiedzmy sobie „duża“. Siadałem do tego systemu dwukrotnie w odstępach rocznych ale niestety z racji błędów musieliśmy się rozstać.
Umożliwia pisanie skryptów w okrojonym języku skryptowym udającym język naturalny oraz w powershellu.

Domoticz

Domoticz to z kolei propozycja systemu stworzona w języku C++, co daje możliwość uruchomienia go na platformach Windows oraz Linux (Raspberry Pi). Jako niewątpliwą zaletę można podać obsługę języka skryptowego LUA, który daje spore możliwości oprogramowania.
Samo wrażenie po instalacji systemu i kilkugodzinnej zabawie jest takie, że system wygląda jakby był mocno skrojony i zszyty na miarę czyichś potrzeb. W ustawieniach pojawia się mnóstwo opcji, które na pierwszy rzut oka nie mówią nic i nie wiadomo do czego służą. Sam interface mocno widgetowy, też nie do końca mnie przekonuje. Nie tego poszukuję.

HomeGenie

HomeGenie to drugi, z tu obecnych systemów napisanych w języku C#. Co ciekawe, za pośrednictwem platformy Mono można go uruchomić na Linuksie jak i na Mac OSX. System jest nieco bardziej dopracowany względem poprzednika, ma ładnie wykończony interfejs w HTML5/js.
To co się rzuca na dzień dobry w oczy to możliwość pisania skryptów (tzw programów) bezpośrednio przez stronę administracyjną w językach: C#, JS, Python, Ruby oraz nagrywania mark, które skryptują zachowanie użytkownika. Na platformie Linux (Raspbery Pi) można nawet programować bezpośrednio Arduino podpięte pod RPI.
Program taki jest kompilowany „ze strony HTML“ do .NETowego assembly (powiało magią) i uruchamiany w procesie serwera aplikacji. Innymi słowy piszemy/poprawiamy skrypt, ten się sam kompiluje i uruchamia.. i działa :).
Przyznam obecnie, że z tym systemem wiążę największą nadzieję na współpracę. Pomimo, że dokumentacja trochę kuleje to po solidnym zagłębieniu się można się dogadać z dżinem. System ma również możliwość pisania własnych pluginów w C# w zewnętrznym środowisku i wczytywanie ich w postaci gotowych pakietów do systemu. Tego jeszcze do końca nie rozgryzłem, ale autor zdaje się zauważył problem wysokiego progu wejścia dla świeżych programistów i pewne kroki ostatnio poczynił by ułatwić nam życie :).

Jeśli chodzi o integrację z HAPCANem, to można to zrobić dwojako. Najprościej stworzyć nowy program i skorzystać z pomocniczej klasy do obsługi połączeń TCP. Do domowej magistrali HAPCAN mam podpięty moduł Ethernet, który umożliwia transmitowanie ramek CAN poprzez protokół TCP. Sam kod obsługujący pojedyncze urządzenie jest jednak dosyć duży, ze względu na konieczność składania ramek ręcznie, stąd też moim celem jest stworzenie plugina, który umożliwi łatwiejszą komunikację z HAPCANem.

Jeszcze jedną ciekawostką, o której nie wspominałem jest fakt posiadania REST API. Dotyczy to również innych systemów, ale na przykładzie HomeGenie przykładową żarówkę w kuchni można wyłączyć wchodząc na przykładowy adres:
http://ip.ip.ip.ip/api/HomeAutomation.HAPCAN/Relay/1/Control.On.
Daje to wręcz nieograniczone możliwości integracji z systemem i nawet żona z tableta z Androidem może mieć dostęp do zdalnego włącznika ;).

Node-RED

Jako ciekawostkę podrzucę też system Node-RED. Główna idea tego rozwiązania jest taka, aby maksymalnie odciążyć użytkownika czy programistę od… programowania rzeczy, które nie są istotne z biznesowego punktu widzenia. O ile w przypadku poprzednich systemów użytkownik musi poświęcić nieco czasu na stworzenie otoczki komunikującej się ze światem o tyle w systemie Node-RED użytkownik definiuje tylko przepływ danych pomiędzy bloczkami.

Poniższy przykład jak za pomocą 3 bloczków włączyć światło w kuchni :)

Node-RED i HAPCAN

Po lewej bloczek pełniący funkcję przycisku. Po jego naciśnięciu wywołuje się bloczek funkcyjny, w którym wpisałem poniższy kod:


msg.payload = new Buffer("AA30300302FFFF074004FFFFFFABA5", "hex");
return msg;

Komunikaty pomiędzy bloczkami przesyłane są w postaci obiektu json, pod atrybutem payload znajduje się szesnastkowo zapisana ramka HAPCAN, udająca sygnał z pilota włączającego światło w tym wypadku. Oczywiście aby całość była bardziej czytelna dla użytkownika wypadałoby stworzył swoje własne bloczki, które same generują odpowiednią wiadomość.
Następnie wyjście bloczka funkcyjnego przesyłane jest dalej do bloczka TCP, który wysyła tą ramkę na adres modułu HAPCAN Ethernet, a ten dalej wrzuca to w magistralę wewnętrzną i bam!… żarówka świeci ;).

Jeśli chcemy aby światło zgasło po 30 sekundach, nic prostszego, Wystarczy dorzucić bloczek Delay.

Node-RED i HAPCAN

Node-RED umożliwia w podobny sposób np. pobranie danych z Internetu, przetworzenie ich i np wysłanie maila z wiadomością. Zapewne znajdzie zastosowanie w przypadku, gdy chcemy pewne rzeczy zautomatyzować, albo dostać powiadomienie, że kurs akcji właśnie podskoczył. W przypadku takiego połączenia z HAPCANem zauważyłem, że system potrafi się rozłączyć i chwilę mu zajmie nawiązanie nowego połączenia. Dodatkowo jak dla mnie jest tutaj trochę zbyt duży poziom abstrakcji i czuję się nieswojo gdy nie wiem co dany bloczek robi pod spodem :).
Oczywiście może on się świetnie nadawać jako uzupełnienie któregoś z poprzednich systemów i dzięki API komunikować się z naszym systemem właściwym. Z pewnością niektóre zadania łatwiej w nim zaimplementować. Polecam się pobawić.


Comments (4)

  1. Piotr:
    mar 30, 2017 at 10:06

    "Jeśli chcemy aby światło zgasło po 30 sekundach, nic prostszego, Wystarczy dorzucić bloczek Delay."

    ten Delay to opóźnia wysłanie komunikatu?
    czy poprzez podwójne wyjście z "hapcan msg 4" duplikuje ten komunikat i po 30sek wysyła go ponownie?
    jak widzę, komunikat HapCana w INSTR1 jest "02" czyli Toogle więc kliknięcie powodowało by zapalenie się światła na 30sek, dobrze rozumuję ? :)

  2. Bartek:
    mar 30, 2017 at 12:36

    Delay w opóźnia przekazanie danych z wejścia na wyjście. W tym wypadku jest tak jak piszesz, czyli jedna wiadomość leci od razu do tcp i ta sama wiadomość jest puszczana na wejście tcp przez bloczek Delay 30 sekund później. Akurat w tym testowym przypadku wysyłałem właśnie wiadomość typu Toggle, która naprzemiennie raz włącza raz wyłącza światło, więc światło się włącza i wyłącza po 30 sekundach - chociaż to akurat zależy od stanu światła w danym momencie.

  3. blynk.pl:
    wrz 19, 2017 at 10:19

    Od pewnego już czasu dostępny jest BLYNK - dla mnie rewelacja w domowej automatyce centralnie sterowanej z telefonu/tableta . I najważniejsze - całkowicie kompatybilny co do filozofii z Arduino. Szkoda że trochę mało popularny u nas. Z twojego punktu widzenia pewnie mniej atrakcyjny bo serwera praktycznie w nim nie widać a całość konfiguruje się z telefonu bądź z kodu mikroprocesorowego modułu. Ale dla elektronika - ideał

  4. Bartek:
    wrz 19, 2017 at 10:56

    A kimże jest ten elektronik? :) Ja akurat mam negatywne zdanie na temat systemów zarządzania domem opartych o chmurę. Tego typu system w mojej ocenie powinien być zamknięty. Z Arduino jest jeden problem - aby złożyć z tego coś więcej niż tylko mrugająca diodę zapalaną smartfonem trzeba nieco orientować się w instalacjach elektrycznych, trzeba to wszystko jakoś połączyć - tak aby było bezpieczne itp. Dlatego jeśli chodzi o urządzenia polecam Hapcana, którego używam od kilku lat. Napisałem do niego również bibliotekę umożliwiającą w prosty sposób podpięcie Arduino i rozszerzenie możliwości systemu. Natomiast jako układy wykonawcze wolę zastosować dedykowane urządzenia w obudowach na szynę niż wiszące na przewodach chińskie moduły przekaźników - które potrafią być wręcz niebezpieczne dla użytkownika.

  1. 1

Allowed tags: <b><i><br>


PODZIEL SIĘ

PODZIEL SIĘ