Napisz do mnie

Wyślij prywatną wiadomość

MQTT - CO TO JEST?

opublikowano: 10 lut 2019 wyświetleń: 22 komentarzy: 0

#dariahomesystem #MQTT #IoT #automatyka domowa #home automation

Magistrala komunikacyjna w systemie DARIA, oparta jest na szybkim i lekkim protokole komunikacyjnym dla urządzeń.

Co to jest MQTT?

Nie chcę opisywać dokładnie całego protokołu MQTT, podam jedynie kilka informacji aby zainteresować Cię, być może, do bliższego zapoznania się z możliwościami jakie daje. W dalszej części przedstawię moją wizję zastosowania tego protokołu w inteligentnym domu.
Jeśli temat MQTT nie jest Ci obcy, możesz przejść od razu do części 2.

Przypomnę rysunek poglądowy:

MQTT

Wynika z niego, że serwer MQTT (zwany również brokerem) znajduje się w centralnym punkcie całego systemu. Jego działanie opiera się o przyjmowanie wiadomości od podłączonych do niego klientów oraz rozsyłanie tych wiadomości do klientów, którzy wyrazili chęć otrzymywania wiadomości danego typu (subskrybentów).

Wiadomością w protokole MQTT może być cokolwiek, może to być string, liczba, json, dane binarne. Każda wiadomość zaopatrzona jest w temat. Temat wiadomości przypomina strukturę folderów na dysku i powinien jasno określać jakiego typu wiadomość została wysłana od klienta. Inne klienty mogą zasubskrybować dany temat co pozwoli im otrzymywać tylko wybrane wiadomości.

Przykładowe tematy

  • dom/kuchnia/swiatloscienne/status
  • dom/kuchnia/temperatura
  • garaz/drzwi/status
  • uzytkownik/bartek/pozycjagps

Subskrybenci mogą określić jakie tematy są dla nich istotne, np. wyświetlacz podłączony do systemu MQTT może nasłuchiwać tematu dom/kuchnia/temperatura. Ilekroć pod takim tematem zostanie opublikowana wiadomość, wyświetlacz otrzyma taką informację.

Istnieje również możliwość subskrybowania poddrzew tematów, np. mapa prezentująca lokalizację użytkowników domu zapewne chciała by otrzymywać informacje o każdym z nich. Zamiast subskrybować pojedyncze kanały każdego domownika z osobna, może ona nasłuchiwać na kanale:

  • uzytkownik/+/pozycjagps

Znak + oznacza tutaj dowolny ciąg znaków — w tym wypadku można przyjąć, że będzie to imię użytkownika.

Standard MQTT nie narzuca żadnego specyficznego układu tematów, jest tutaj zatem pełna dowolność. Niby fajnie, jednak po chwili okazuje się, że ciężko wymyślić taką strukturę aby nie pogubić się w tym wszystkim przy rosnącej liczbie podłączonych urządzeń.

RETAIN MESSAGE

Warto również nadmienić o wiadomościach trwałych (retain message). Jeśli klient wyśle wiadomość trwałą zostanie ona zapamiętana przez serwer i będzie automatycznie wysłana do każdego kto zasubskrybuje dany temat.
Do czego to się może przydać? A no np. do zapamiętywania ostatniego stanu każdego urządzenia. Bez tego, jeśli np. ekran prezentujący temperaturę podłączy się później niż termometr nada informację o temperaturze, wyświetlacz musiałby czekać aż przyjdzie coś nowego, lub też w jakiś sposób zapytać się o temperaturę. A tak dostanie ostatni odczyt zaraz po zalogowaniu się.

Generalnie zamysł twórców MQTT w wersji 3.1.1 był taki, aby protokół nie służył do wysyłania żądań i oczekiwaniu na dane (jak w HTTP). Nic jednak nie stoi na przeszkodzie aby każde urządzenie miało również dedykowany kanał do odbierania zapytań o swój status. W reakcji na takie zapytanie wysłać może informacje o swoim stanie ponownie.

Muszę jednak powiedzieć, że takie podejście rodzi pewne komplikacje, no bo teraz każdy proces do swojego działania musiałby jeszcze zaimplementować odpytywanie innego urządzenia o status, oczekiwanie na odpowiedź, obsługa timeoutu, błędów transmisji itp. Zdecydowanie w takich sytuacjach wystarczające i o wiele prostsze w użyciu są wiadomości trwałe.

QoS

Druga, istotna kwestia, to fakt, że każda wiadomość ma określony parametr QoSQuality of Service. Parametr ten to nic innego jak liczba 0, 1 lub 2 określająca gwarancję dostarczenia wiadomości.

  • QoS 0 — najszybszy, najprostszy, klient publikuje i zapomina. Nie ma tutaj gwarancji, że wysłana wiadomość dotarła do serwera. Nie ma też gwarancji, że subskrybent odebrał wiadomość od brokera.
  • QoS 1 — nieco wolniejszy, gdyż zarówno serwer jak i klient muszą potwierdzić, że odebrały wiadomość. Mamy zatem pewność, że wiadomość nie zaginęła po drodze, ale w związku z implementacją wiadomość może dotrzeć kilka razy. Nie jest to problemem jeśli zapisujemy status, ale już sterowanie przełącznikiem (toggle) może nas tutaj nieprzyjemniej zaskoczyć ;)
  • QoS 2 — najwolniejszy, tutaj jest już pełna gwarancja dostarczenia wiadomości i to dokładnie jeden raz.

Należy również pamiętać, że QoS występuje po dwóch stronach brokera MQTT, każda wysyłana wiadomość ma określony poziom dostarczenia do brokera, jak i każdy subskrybent określa poziom usług, który go satysfakcjonuje.

Dobór odpowiedniego poziomu QoS bywa bardzo istotny, z mojego doświadczenia warto zacząć od poziomu 2. System domowy nie jest na tyle skomplikowany oraz rozproszony aby wystąpiły jakieś problemy z czasem dostarczania wiadomości.

Skąd wziąć MQTT?

Aktualnie używam brokera Mosquitto. Miałem z nim początkowo problemy, ale to była kwestia "krzywego builda".

Przy wyborze brokera warto zwrócić uwagę czy obsługuje on prócz połączeń tradycyjnych TCP również połączenia oparte o technologię websockets. Jest to istotne, jeśli zechcesz podłączyć się do brokera z przeglądarki internetowej. Najnowsza wersja Mosquitto obsługuje websockety (wersja 64bit).

 


CZYTAJ DALEJ POZOSTAŁE CZĘŚCI TEGO ARTYKUŁU


ZOBACZ RÓWNIEŻ POLECANE WPISY


Comments (0)


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


PODOBAŁO SIĘ?

PODOBAŁO SIĘ?


0 like voting
is closed
thanks
for your vote

PODZIEL SIĘ

PODZIEL SIĘ