Supla - MQTT - Dashing

Masz pomysł na funkcjonalność lub koncepcję na rozwój projektu. Opisz wszystko tutaj.
Beku
Posts: 453
Joined: Tue Nov 06, 2018 1:49 pm

Post

Cześć!

Wstęp

Chciałbym podzielić się z Wami moim ostatnim projektem z wykorzystaniem ekosystemu SUPLA. Pracowałem nad tym kilka ostatnich miesięcy, i chociaż jeszcze mam sporo pomysłów to osiągnąłem już zadowalające wyniki, które mogę i chcę pokazać światu. Wiem, że moje rozwiązanie zdarzeń jest tymczasowe bo zapowiadana jest obsługa natywna ... ale świat społeczności nie lubi czekać 🙂
Od pierwszego momentu, w którym wybrałem SUPLE jako podstawowy system dla mojej domowej automatyki marzył mi się centralny Dashboard-panel w domu, którym będę mógł sterować i obsługiwać urządzenia.

Jak to zwykle bywa każde z istniejących rozwiązań miało coś czego potrzebowałem, ale i braki. Pewnie dla wielu z Was, i to które zaprezentuje takie będzie.

Architektura
1. Po pierwsze SUPLA! I to nie ważne czy instancja w Cloud czy własna.
2. Supla MQTT Client
3. Mosquitto MQTT Broker
4. Dashing

Nie będę pisał o punkcie pierwszym bo wszyscy go znają.

Punkt drugi go klient supli napisany przeze mnie na podstawie źródeł klienta dostępnych na GITHUB. Przesiadłem się jednak w nim w większości na c++, być może trochę wolniejszy niż w czystym c, ale wygodniejszy i zaoszczędził mi trochę czasu.

Ale do rzeczy...

Supla MQTT Client to klient Supli jak każdy smartfon czy tablet. Działa dokładnie na takiej samej zasadzie - w CLOUD widoczny jest jako kolejne urządzenie klienckie o nazwie SUPLA MQTT proxy.
Jak każde urządzenie klienckie również i mój klient reaguje na zmiany stanów kanałów i umożliwia sterowanie urządzeniami.

I tutaj pojawia się MQTT.
Po wskazaniu serwera/brokera MQTT klient publikuje tzw. topic (tematy, topiki) wraz z zawartością zwana payloadem (zawartość). Format poszczególnych stanów kanałów został przedstawiony poniżej (można go dostosować do swoich potrzeb - jest konfigurowalny).

Dla przykładu sensor DHT11 domyślnie publikuje pod taką postacią:

topic: supla/channels/status/dht11/{id}
payload: { „temperature”: 12.35, „humidity”: 60.00 }

Dlaczego wykorzystałem MQTT? Przecież mamy w CLOUD REST’owe API, linki bezpośrednie ... Otóż dlatego ze te rozwiązania wymagają cyklicznego odpytywania o stan. I oczywiście, możemy robić to co sekundę ale generalnie to bardzo duże obciążenie i marnotrastwo. W ciągu godziny wykonamy 3600 zapytań do serwera by za każdym razem dowiedzieć się że lampka nie swieci - słabe.
Klient działa nieco inaczej. Utrzymuje on połączenie z serwerem (i nawiązuje jeśli zostało zerwane) i to serwer SUPLI wysyła do niego dane wtedy kiedy jest to potrzebne - dla uproszczenia po zmianie stanu kanałów.
Klient natomiast wtedy publikuje temat do MQTT - mamy system oparty na zdarzeniach! Supcio 🙂.
Dlaczego klient a nie bezpośrednio serwer?
Tutaj dosyć długo się zastanawiałem i sam przekonałem się następującymi argumentami:

1. Nie psuje serwera i tym sposobem nie wymagam własnej implementacji serwera. Proces serwera jest krytyczny i nie może nic złego się z nim stać.
2. Implementacja mqtt w serwerze tez byłaby bardziej skomplikowana.
3. Klientem jak każdym innym urządzeniem można sterować tzn może mieć dostęp tylko do określonego identyfikatora dostępu.
4. Klient może zostać odłączony bez wpływu na harmonogramy i inne rozwiązania wymagające serwera.

No dobra mamy w MQTT stany kanałów które taki stan udostępniają... ale jak nimi sterować?
W chwili obecnej obsługuję w kliencie sterowanie przyciskami, roletami oraz panelami rgb. Sterowanie jest dosyć proste, wystarczy do serwera MQTT (nie bezpośrednio do klienta czy serwera supli) wysłać z zewnątrz topic, np: dla przycisku:

topic: supla/channels/command/switch/{id}
payload: {„On”: true|false }

Klient Supli nasłuchuje określonych tematów (domyślnie supla/channels/command/#)
i odpowiednio na nie reaguje zmieniając stan kanału.

Ot cała filozofia MQTT.

Do działania tego wszystkiego potrzebny będzie jednak broker MQTT. Ja wybrałem własna instancje do tego konteneryzowaną. Mosquitto to OpenSource broker MQTT bardzo prosty w instalacji i konfiguracji. Wszystko sprowadza się do pobrania obrazu z dockerhub i uruchomienie kontenera. No prawie wszystko bo warto jeszcze to jakoś zabezpieczyć. Opiszę taką konfiguracje niebawem.

Dashing - to jedno z wielu rozwiązań obok openhab, domoticz, i wielu innych. Ale w porównaniu do innych cechuje je prostota - chociaż nie koniecznie w sensie „wszystko sobie wyklikam”.

Efekt mojego Dashboardu widoczny jest poniżej: to jeszcze nie jest finały projekt, zapinam do niego poszczególne klocki mojego systemu ale mniej więcej widać o co chodzi. Interfejs dostępny jest przez stronę www i wyglada ładnie zarówno w przeglądarce jak i urządzeniach mobilnych. Ja wykorzystałem już tu gotowe rozwiązanie (tzn. bazę) dostępna na github, ale generalnie można tworzyć dashboardy jakie tylko sobie wymarzymy. Trzeba znać tylko trochę html’a i dla bardziej aktywnych ruby i coffescripta 😀

Link do wykorzystanego dashingu:

https://github.com/smar000/openhab-dashboard

Powyższy temat opisuje akurat spięcie dashinga z openhabem - gdyby ktoś chciał 🙂



W moim projekcie dopisałem w dashing obsługę mqtt... I jak każdy już sobie domyśla dashing otrzymuje z serwera mqtt stan kanałów supli i umożliwia sterowanie nimi przez zastosowanie publikacji i subskrypcji tematów.

Tyle....
w dalszej części będę wrzucał kod - muszę garnąć całość i posprawdzać. Póki co efekt jest taki jaki widać w załączniku.

PS - tak jak napisałem Dashing to tylko jedna z wielu możliwości:
MQTT działa np. w openhab, homeaasistant, domoticz (chociaż tutaj trochę trzeba się napracować) u pewnie wielu innych rozwiązaniach.

P.S 2 - post stworzyłem na telefonie w czasie pracy kiedy instalowała mi się aktualizacja windowsa .... także tego, sorki za błędy. Do poczytano wkrótce!
You do not have the required permissions to view the files attached to this post.
User avatar
pzygmunt
Posts: 19204
Joined: Tue Jan 19, 2016 9:26 am
Location: Paczków

Post

Brawo!! :)
User avatar
klew
Posts: 9630
Joined: Thu Jun 27, 2019 12:16 pm
Location: Wrocław

Post

Czy dobrze rozumiem, że właśnie zintegrowałeś Suplę ze wszystkimi systemami zarządzania domem, które pracują z MQTT? :)
Cała instancja klienta Supli jest wtedy widoczna jako urządzenie wykonawcze wspierające MQTT i jako takie może być dodane np. do Domoticza?
Kiedy będzie Supla Offline Party / SOP#2025 ?
Beku
Posts: 453
Joined: Tue Nov 06, 2018 1:49 pm

Post

Z założenia tak. Ale jeszcze nie testowałem tego z innymi oprócz Dashinga. Domoticz akurat jest trochę upierdliwy pod tym kątem bo ma stałą strukturę topiców i na wejściu i na wyjściu ale z założenia moje rozwiązanie daje możliwość tworzenia szablonów MQTT - definiowania struktury komunikatów MQTT w jedną i drugą stronę.
Np homeassistant ma silnik który umożliwia prasowanie mqtt podobnie jak openhab i to je można dostosować do obsługi tego co domyślnie wypluje mój klient. W innych przypadkach trzeba napisać szablon w moim kliencie żeby rozumiał to co przychodzi z MQTT a nie jest definiowalne. Ufff.

Dla przykładu:

domoticz subskrybuje temat domoticz/in
z payloadem np. { "idx" : 1, "nvalue" : 0, "svalue" : "25.0" }

mój klient publikuje np: temat supla/channels/status/ds18b20/2
z payloadem np. {"temperature": "25.0"}

Trzeba jakoś powiedzieć mojemu klientowi żeby publikował topic zgodny z tym w domoticz.
I to mam zrobione. Definiuję sobie listę topiców wraz z szablonem payloada i na takie topiki mój klient wysyła komunikaty MQTT.

czyli mogę zrobić szablon
topic: domoticz/in
payload: {"idx": $id$, "nvalue": 0, "svalue" : "$temperature"}

i będzie z domoticzem działać.

w drugą strone jest trudniej i wciąż to testuję ale zasada polega na tym że mój klient subskrybuje np.

domoticz/out i musi wyłuskać z payload'a odpowiednie wartości (wiedzieć co jest co). W obecnej wersji mam tylko słuchanie komend na moim topiku supla/channels/command/ds18b20/{id}
z payloadem o określonej strukturze.

Muszę zrobić parser żeby payload i topic mógłbyć dowolny.
Ale docelowo tak - wszystko ma działać.
User avatar
fracz
Posts: 2274
Joined: Fri Oct 28, 2016 10:56 pm
Location: Kraków

Post

To będzie można łatwo do skryptów dodać obsługę zdarzeń i automatycznie wykonywać sceny gdy warunek się zmieni :mrgreen: Super!
User avatar
michael
Posts: 1311
Joined: Wed Nov 09, 2016 8:00 am
Location: Wojkowice

Post

Taki panel z Dashingiem kiedyś chciałem zrobić. Teraz muszę wrócić do tego tematu :) Dzięki za rozwiązanie!
fracz wrote: Wed Oct 16, 2019 2:02 pm To będzie można łatwo do skryptów dodać obsługę zdarzeń i automatycznie wykonywać sceny gdy warunek się zmieni :mrgreen: Super!
Mamy to rozumieć, że zapowiadają się Supla-Scripts v3.2.0? :D
:mrgreen: :mrgreen: :mrgreen:
User avatar
pzygmunt
Posts: 19204
Joined: Tue Jan 19, 2016 9:26 am
Location: Paczków

Post

Supla-Scripts będzie podpięte pod eventy bezpośrednio przez webhooki.
Beku
Posts: 453
Joined: Tue Nov 06, 2018 1:49 pm

Post

ten projekt nie rozwiąże wszystkich problemów świata i jednak wymaga postawienia go w chwili obecnej na swojej maszynie. Ale myśle ze dzięki temu trochę prościej będzie zintegrować suple z innymi systemami obsługującymi MQTT. Dashing jako panel jest wypas. Nie chce wchodzić w szczegóły - jak udostępnię źródła to je opisze, jednak w Dashingu można w zasadzie zrobić wszystko co tylko dusza zapragnie. Ja już mam podpięte kamery, teraz walczę z klimatyzacja. Różne widgety pogodowe a z ciekawych widgetów gotowych jest np Google traffic ... jest tego dużo 🙂
User avatar
fracz
Posts: 2274
Joined: Fri Oct 28, 2016 10:56 pm
Location: Kraków

Post

I co z tymi źródłami? ;)

Dopiero teraz zdałem sobie sprawę z której strony się do tego dobrałeś. Genialne :D
Beku
Posts: 453
Joined: Tue Nov 06, 2018 1:49 pm

Post

poprosiłem pzygmunt o przejrzenie (w ramach wolnego czasu) kodu, jak odpisze, że wstydu nie ma, to wrzucę. Może będzie na github supli ale to zależy od Was 😎

Samego dashinga też dzisiaj postaram się udostępnić.

Return to “Pomysły i koncepcje”