Supla - MQTT - Dashing
: śr paź 16, 2019 8:06 am
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!
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!
Super!
