Implementacja MQTT

[Marcin]

Jacku jakie są szanse i możliwości "zaimplementowania" MQTT do HAPCAN'a ? (nie jestem programistą, nie wiem czy dobrze ująłem zapytanie)

[Jacek]

Tibbo ma nawet bibliotekę MQTT https://docs.tibbo.com/taiko/mqtt_library, więc potencjalne szanse są.
Powiedz proszę z czym chciałbyś to zintegrować.

[Marcin]

Osiadłem na Home Assistant, w tej chwili łączę się z Hapcan'em poprzez Node Red za pomocą integracji Bartka, ale mam sporo modułów i ciężko zapanować nad tym. Gdyby była możliwość integracji Hapcan'a po MQTT można było by zintegrować go praktycznie ze wszystkim.

[Jacek]

Home Assistant ma wbudowany broker MQTT?
Jakbyś wyobrażał sobie konstrukcję topiku publikowanego i subskrybowanego przez interfejs HAPCAN? Zastanawiam się czy prosty topik w postaci nagłówka ramki hapcan np. "hapcan/frame/30/80/01/02/" byłby na początek użyteczny, a jako treść wiadomości pełna ramka hapcan "30801002itd".

[Marcin]

Home Assistant nie ma brokera wbudowanego, ale ma "integrację" z Mosquitoo Broker. Co do dalszych Twoich pytań to myślę że Bartek może się wypowiedzieć merytorycznie na ten temat.

[Jacek]

No tak, przydałby się wyjadacz z MQTT, który by podpowiedział jak szybko bezboleśnie i użytecznie to zaprojektować. Przebrnij Marcinie przez dokumentację MQTT

[Marcin]

Zagadałem do Bartka na jego Slack'u, on to ma "w jednym palcu", może coś podpowie:)

[Bartek]

Co do struktury tematów to MQTT nie narzuca tutaj żadnego standardu i każdy robi jak chce.
W moim systemie struktura tematów zawiera nieco więcej informacji niż tylko sam adres urządzenia. A w zasadzie to samego adresu urządzenia nie zawiera, bo lepiej abstrahować od takich rzeczy jak adres fizyczny. Podobnie jak nie podaje się numerów IP w przeglądarce tylko nazwy domen.

U mnie wszystkie urządzenia(Hapcan, Philips Hue, inne zigbee, iRobot itp) jak i usługi softwarowe (monitoring użytkowników, kalendarze szkolne, system przetwarzania języka naturalnego, obsługa komunikatorów itp) mam ustrukturyzowane w podobny sposób.

Tematy MQTT określają tak naprawdę urządzenie czy usługę, jej typ, położenie w przestrzeni bądź domenie, nazwę itp. Dzięki temu łatwiej mi się w tym poruszać a prostymi zapytaniami w javascripcie mogę sobie wyłuskać informację np ze wszystkich termometrów czy świateł w mieszkaniu, niezależnie od tego czy na końcu siedzi Hapcan czy jakieś urządzenie zigbee.

Korzystam również z zigbee2mqtt, który te statusy urządzeń zwraca w postaci jakichś prostych tematów zdefiniowanych jako nazwy urządzeń ale to i tak tłumaczę sobie dalej na mój format.

Dokładny opis używanego przeze mnie formatu tematów opisany jest tutaj: https://onixarts.pl/blog/2019/02/daria- ... a-tematow/
W skrócie, przykład takich tematów:

home/env/light/room1/walllight/status
home/env/light/room1/walllight/control
home/env/button/kitchen/leftwindow/status
home/env/blind/room2/window2/control
home/sys/service/eventgenerator/sun/status
home/sys/scene/room1/night/control
home/sys/service/notification/center/control

Nie twierdzę, że jest to najlepszy z możliwych sposobów zapisu ale się jego trzymam a dopóki wszystko u mnie trzyma się tego zapisu to jest git .

W przypadku Hapcana miałem w planie zrobić taki bloczek do node-red na zasadzie zigbee2mqtt ale z nieco bardziej rozbudowaną konfiguracją tematów, tak aby każdy (w tym ja) mógł odtworzyć sobie strukturę jaką chce.
Natomiast docelowo prawdopodobnie załatwię sprawę prościej i dam możliwość użycia jednego bloczka obsługującego wiadomość typu X do wielu modułów. Uprości to znacząco konfigurację w samym node-redzie, zwłaszcza dla rozbudowanych sieci Hapcana a jednocześnie pozwoli mieć wpływ na to jakie dane faktycznie trafiają do MQTT.
Z mojego doświadczenia i serii zmian wynikło, że lepiej konwertować dane z urządzeń różnego typu na jeden wspólny format niż wrzucać surowe ramki do MQTT. Potem przykładowo ramka temperatury z Hapcana ma format zupełnie inny niż z zigbee a to nie powinno zupełnie interesować reszte systemu, gdyż koniec końców istotna jest informacja jaka temperatura panuje w pomieszczeniu. Lepiej wtedy odwołać się w identyczny sposób do danych z MQTT niż obsługiwać kilka różnych formatów np w warstwie wyświetlającej dane gdzieś na dashboardzie.

Obecnie każdy bloczek obsługuje jedno urządzenie Hapcan, więc w konfiguracji mapuję każdy kanał na odpowiedni temat MQTT i odwrotnie, każdy temat sterujący w MQTT mapuję na konkretny kanał w urządzeniu:

W przypadku kilku (nastu) modułów to jeszcze ma sens, aczkolwiek jeśli występują takie same moduły to wymagają powielania przepływów w node-redzie.
Zredukowanie tych wszystkich mapowań do jednego bloczka wymagałoby zapisania w jakiś inny sposób tego mapowania. Ze np channel 1 w module przekaźnika (2,1) to jest u mnie home/env/switch/room1/rgbpower/status.
Można w jakiś sposób podać te mapowania w samym bloczku, ale stwierdziłem, że być może lepiej wykorzystać nazwy umieszczane w samych modułach przypisane do kanałów urządzenia oraz jego nazwę. Przykładowo temat mógłby być wtedy składany wg potrzeb z tych danych pobranych z urządzeń na etapie wykrywania urządzeń (funkcja discover). O ile w Node-red i tak lista urządzeń jest przechowywana w konfiguracji, o tyle moduł Tibbo/Ethernet musiałby również być świadomy istnienia wszystkich modułów i taką listę również przechowywać. A nie wiem jak tam z dostępną pamięcią na takie rzeczy.

Oczywiście najprościej zrobić na danych, które i tak mamy w ramce, czyli to co Jacku zaproponowałeś ale i tak na jakimś etapie będzie to musiało zostać skonwertowane na jakiś device w Home Assistant czy Node-Red. U mnie sam temat jest już jakby nazwą devica, więc optymalnie by było dostawać już gotowy temat skrojony do potrzeb.

[Jacek]

Dzięki Bartek, no własnie moduł Tibbo nie ma tyle pamięci, żeby na jego pokładzie analizować ramki i formować tematy MQTT w czytelniejszy sposób. Tę analizę trzeba by było wykonać po stronie klienta. Marcinie, czy Home Assistant mógłby to wykonać?

[Marcin]

Jacku, po konsultacji z kolegą który ogarnia te "tematy" doszedł do jednego wniosku, mianowicie nie ma sensu czytać po MQTT ramki Hapcana którą trzeba w Home Assistant znów tłumaczyć i w drugą stronę tak samo.
Zaproponował dwa wyjścia:

- moduł TIBBO sam formatuje wszystko w strukturach i wysyła po MQTT ( pisałeś że może nie starczyć pamięci)

- opcja druga, podłączyć się modułem RS232 do magistrali CAN, a z drugiej strony po RS podłączyć ESP i tam w języku LUA zaimplementować MQTT z pełnymi sformatowanymi danymi dla każdego urządzenia. ( mówi że miało by to wygląd jak zigbee2mqtt )
Wtedy była by możliwość stworzenia uniwersalnej GATE hapcan2mqtt.
Trzeba by połączyć siły z Bartkiem bo już zrobił 90% roboty. Bartek, miałbyś chęć coś podziałać w temacie ?

P.S. Tak mi się nasunęło teraz...może czas na nowszą bramkę ETHM np. na ESP32?
Jeszcze jeden P.S. Coś mi się kojarzy że protokół CAN jest trochę zmieniony względem oryginału ? Jacku możesz rzucić okiem na tę stronę i powiedzieć mi czy to będzie czytać Hapcan ?
https://esphome.io/components/canbus.html

Pozdrawiam.

[Bartek]

Ja bym skłaniał się bardziej do rozszerzenia moich bloczków do node-red w pierwszej kolejności, bo tam już jest niemal wszystko przygotowane.

[Jacek]

Bartek, masz rację. Rozwijaj proszę swoje moduły. Nowy moduł sprzętowy na bazie Raspberry PI wykonał właśnie Alexandre.
viewtopic.php?f=3&t=965&p=2711#p2711. Niedługo ma go udostępnić. Cóż za szybka odpowiedź na nasze potrzeby

[Bartek]

Może być ciekawe. Zobaczymy jakie będą możliwości konfiguracji.