ARCHITEKTURA SYSTEMU DARIA
#dariahomesystem #HAPCAN #MQTT #schemat ideowy #DARIA
Opis architektury systemu inteligentnego domu, nad którym pracuję.
Architektura
Przemyśleń okropnie dużo. Systemów wiele przetestowanych. Sporo czasu upłynęło zanim zdecydowałem się na jakieś konkretne rozwiązania. Wszystkie z nich będę opisywał w kolejnych artykułach, do których linki można znaleźć we wpisie głównym (patrz powiązane na dole).
Sprzęt
Od strony sprzętowej architektura systemu przedstawia się następująco:
System składa się z dwóch magistral. Niebieskim kolorem oznaczyłem magistralę HAPCANa, czerwonym ETHERNET. Kolory te mają pokrycie w kolorach skrętek, tak aby jednoznacznie móc je szybko odróżnić.
Urządzenia pracujące w sieci HAPCAN są w zasadzie niezależne od reszty systemu. Mają zaprogramowane podstawowe funkcje. Z siecią ETHERNET połączone są poprzez moduł Ethernet systemu HAPCAN, który wpięty jest do switcha/routera.
Switch jest podłączony do Internetu. W sieci ETHERNET wpięty jest także mały komputer, na którym zainstalowany jest system zarządzający całością w sposób bardziej inteligentny. Można powiedzieć, że DARIA właściwa znajduje się właśnie tam.
Na schemacie umieściłem również znak zapytania, pod którym kryją się inne systemy automatyki domowej, które z biegiem czasu będą podłączone do systemu.
Szczegółowy opis znajdziesz w dedykowanych artykułach.
Oprogramowanie
Długo poszukiwałem dobrego systemu zarządzającego. Przewinął się tutaj OpenHab2, HomeGenie, Domoticz, Node-Red, Open Source Automation, nawet w pewnym momencie zacząłem sam implementować program, gdyż żaden z tych systemów nie spełniał moich oczekiwań do końca. Jeśli jedna rzecz była dobrze zrobiona, tak druga dyskredytowała system.
Głównym problemem były pluginy, łatwość ich tworzenia. Wiele z tych systemów narzuca sposób realizacji, język co prowadzi do sporych ograniczeń, bo nie można wykorzystać innych gotowych rozwiązań.
Wtedy wpadłem na pomysł, aby nie korzystać z jednego programu z systemem pluginowym — jego wysypka kończyła by się położeniem całego systemu. W zamian za to, stwierdziłem, że dobrym środowiskiem do budowy systemu, będzie sam system operacyjny. Ja postawiłem na system Windows z kilku powodów. Znam to środowisko, umiem korzystać z narzędzi programistycznych jak Visual Studio, posługuję się językami C++, C#, poza tym nie umiem za bardzo w Linuksy ;]. Oczywiście można się nauczyć, ale kluczowy jest tutaj również czas.
Poniżej schemat organizacji systemu od strony oprogramowania:
Nie ma tutaj jednego słusznego programu zarządzającego. Każda funkcja systemu (każdy plugin) jest osobnym procesem w systemie Windows. Procesy komunikują się ze sobą za pomocą brokera MQTT a ewentualny interfejs graficzny (panel sterowania) jest wyświetlony w przeglądarce na ekranie dotykowym, telefonie, czy w przeglądarce komputera.
Czym jest broker MQTT? Jest to serwer obsługujący architekturę publikacji i subskrypcji. Każdy klient (tutaj usługa SVC) podłączony do brokera może nadawać wiadomości publikując je w tematach, np. home/svc/hapcan/switch1/status — tutaj usługa komunikująca się z magistralą HAPCAN informuje, że zmienił się stan przycisku. Popularnym brokerem MQTT jest Mosquitto. Takiego również używam.
W zasadzie, to przestałem używać, gdyż z jakiegoś powodu proces Mosquitto.exe pożera mi cały jeden rdzeń, 25% mocy CPU, nieustannie. Napisałem zatem osobną usługę pod Windows, która ma zaimplementowany broker MQTT oparty na bibliotece MQTTNet. Jednak powróciłem ostatecznie do Mosquitto. Problem z pożeraniem CPU występował w jednej wersji. Powrót był podyktowany obsługą websocketów, które były mi potrzebne. Biblioteka MQTTNet niestety nie obsługuje tego typu połączenia. (26.01.2019).
Z drugiej strony, klienci mogą subskrybować wybrane tematy, np. home/svc/hapcan/+/status, otrzymując od brokera informacje o zmianach statusu urządzeń na magistrali HAPCAN. Istnieje możliwość używania wildcardów zastępujących dowolny fragment tematu (znak +).
Najważniejszą zaletą takiego systemu jest brak przywiązania do jednej platformy. Platformą staje się sam system operacyjny. Usługi mogą być tworzone w dowolnym języku, więc znika problem konieczności używania tylko jedynego słusznego.
Startem oraz okresowym uruchamianiem usług może sterować harmonogram systemu Windows, do logowania działania usług można wykorzystać dzienniki systemowe. Dzięki wykorzystaniu tych rozwiązań mamy już gotowe okna systemowe umożliwiające podgląd, konfigurację, edycję. Nie ma również obaw, że po jakiejś aktualizacji przestanie to działać, bo któryś z deweloperów nie zaktualizował jeszcze swojego plugina.
Całą platformę przeniosłem zatem piętro wyżej, na poziom systemu operacyjnego.
2 years later…
Życie jednak zweryfikowało nieco moje plany. Główna architektura systemu pozostała jak wyżej, ale zrezygnowałem z modelu rozpraszania funkcji po różnych usługach. I tak głównym modułem, który realizuje większość zagadnień stał się Node-RED. Zamiast logów systemowych używam zwykłych konsol systemowych z uruchomionym procesem. Tak jest o wiele szybciej i łatwiej zarządzać całością.
TO MOŻE CIĘ ZAINTERESOWAĆ
