W ostatnim czasie obserwuję coraz większą popularność rozwiązań automatyki domowej, opartych na otwartym protokole MQTT. W świecie inteligentnych domów dzieje się tak zapewne w dużej mierze za sprawą rozwoju tanich rozwiązań proponowanych przez chińskich producentów. Nie bez znaczenia jest też rozwój otwarto-źródłowego oprogramowania, w tym świetnego projektu zigbee2mqtt, który stanowi bramę między bezprzewodowym systemem zigbee a dowolnym brokerem MQTT. Spróbujemy dzisiaj przyjrzeć się nieco bliżej temu protokołowi i zastanowić się, czemu właśnie on staje się królem świata IoT.
Protokół MQTT
Warto zacząć od podstaw, czyli historii, ograniczając się jednak do minimum, rozumiejąc awersję wielu osób do tego co było i skupienie na „tu i teraz”, szczególnie w świecie technologii. Protokół powstał ponad 20 lat temu, dzięki wysiłkowi dwóch pracowników firm IBM i Arcom. W założeniu miał on umożliwiać przesyłanie danych telemetrycznych w sposób oszczędny, przez wolne, niestabilne łącze. Panowie mieli zebrać dane z rurociągu biegnącego przez pustynię. Istotne więc była oszczędność danych, przesyłanych przez łącze satelitarne. Poza kosztami miało to dodatkowo przynieść zysk na oszczędności zużycia prądu z baterii. Nazwa protokołu rozwija się jako Message Queuing Telemetry Transport. Już z nazwy widać, że będziemy mieli do czynienia z kolejkami komunikatów, co dobrze wpisuje się w potrzeby automatyki.
Podstawy techniczne i architektura
MQTT oparte jest na protokole TCP. Klient otwiera stałe połączenie z serwerem, który w tym wypadku nazywa się brokerem MQTT. Serwer nazywa się brokerem, ponieważ jego jedyną funkcją jest zarządzanie kolejkami komunikatów (kanałami) i przesyłanie danych do klientów. Dane pochodzą od innych klientów.
Mamy więc klienta, który po utworzeniu połączenia może zasubskrybować wybrane kanały, czym informuje brokera, jakie informacje mają do niego trafiać. Może też, nawet bez subskrypcji wysłać zlecenie opublikowania komunikatów na wybranym kanale.
Mamy więc architekturę, gdzie kliencie mogą wymieniać dane między sobą, z udziałem brokera. Jasne jest, że zwykle w systemie automatyki domowej mamy też jakiś serwer (lub serwery) przetwarzające dane z czujników i wysyłające polecenia do elementów wykonawczych. W tym wypadku serwer jest klientem brokera MQTT, działającym na takich samych prawach jak każdy inny klient.
To co jest bardzo ważne w wybranych zastosowaniach, to wsparcie QoS. Dzięki niemu możemy sobie zagwarantować dostarczenie komunikatu pozostałym klientom, a nawet dostać gwarancję dokładnie jednokrotnej dostawy.
Warto wspomnieć, że protokół wspiera różne formy uwierzytelniania i warstwy transportowe. Można go używać na przykład w parze z SSLem i WebSocketami.
Zalety MQTT
Zwykle zwolennicy tego protokołu opisują kilka jego kluczowych zalet. Skupmy się na każdej z nich i zastanówmy się na ile jest to dla nas wada, na ile zaleta. Do całej listy dołożymy też cechy, które są istotne w przypadku automatyki domowej.
Lekki i efektywny
Tak, to prawda, protokół został zaprojektowany do raczenia sobie w trudnych warunkach, gdzie efektywność była bardzo istotna. Dlatego też świetnie nadaje się nawet do prostych mikrokontrolerów. Tak, ale… Tak zawsze są jakieś „ale”. Obecnie komunikaty bardzo często są rozbudowany, zwykle wysyłane w formacie JSON, a czasem nawet jako zakodowane zdjęcia lub filmy. Oczywiście nie ma w tym nic złego i świadczy tylko o świetnej elastyczności protokołu, jednak trzeba mieć świadomość, że nie wszystkie urządzenia poradzą sobie z dowolnym przekazem przez ten protokół. Dodatkowo niektóre proste implementacje nie wspierają QoS, nie mówiąc oczywiście o szyfrowaniu przez SSL.
Należy też mieć świadomość, że protokół wcale nie jest bardziej efektywny i łatwiejszy w implementacji niż szybkie zapytania http, czy tym bardziej pakiety UDP. Jest on lekki, gdy weźmiemy pod uwagę jego możliwości.
Wielostronna komunikacja
Tak, to bardzo duża zaleta – jeden komunikat może mieć bardzo wielu odbiorców, a nadawca nie musi się w żaden sposób przejmować wysyłaniem wielu kopii.
Niezawodne dostarczanie wiadomości
Tak, to też prawda, dzięki QoS, możemy określić jak bardzo zależy nam na dostarczeniu wiadomości i czy chcemy mieć gwarancję, że klienci nie dostaną duplikatów komunikatu. Oczywiście z zastrzeżeniem, że implementacja kliencka obsługuje „jakość serwisu”.
Działanie w niestabilnych warunkach
Tak, protokół został zaprojektowany, żeby radzić sobie w sytuacjach niepewnego połączenia sieciowego, stąd też implementacja QoS. Oczywiście w naszej sieci lokalnej ma to pewnie mniejsze znaczenie, jednak w świecie IoT, gdzie mamy czasem do czynienia z wąskim pasmem lub obiektami przemieszczającymi się i gubiącymi od czasu do czasu zasięg, ma to kolosalne znaczenie. Oczywiście przy okazji wychodzą na wierzch wady użycia protokołu TCP i zagadnienia wykrywania zerwania połączeń. Dlatego częścią protokołu są cykliczne pakiety wykrywające problemy (keepalive).
Wsparcie bezpieczeństwa
To kolejna zaleta nie do przecenienia. W zaufanej lokalnej sieci możemy pozwalać łączyć się klientom wyłącznie z podaniem unikalnego identyfikatora, ale nic nie stoi na przeszkodzie, żeby używać loginu i hasła. Ma to szczególne znaczenie w przypadku prostych klientów, gdzie nie jest łatwo zaimplementować bardziej złożone metody bezpieczeństwa. Poza zaufaną siecią możemy wymagać szyfrowania przez SSL, a tekże autoryzacji na podstawie klucza PSK lub certyfikatu klienckiego.
Skalowalność
Ze względu na prostą architekturę protokołu i ogólne założenia, nic nie stoi na przeszkodzie, żeby broker był też klientem innego brokera. Dzięki temu możemy budować struktury gwiaździste i łączyć klientów do różnych brokerów.
Prędkość działania
Ponieważ mamy do czynienia z cały czas otwartymi połączeniami TCP, nie ma potrzeby nawiązywania połączenia za każdym razem, gdy chcemy wysłać komunikat, więc wymiana prostych danych jest znacznie szybsza, niż np. przy zastosowaniu protokołu http, co jest szczególnie odczuwalne na przykład w połączeniach z serwerami chmurowymi.
Działanie za NAT
Przy różnych protokołach, dla zachowania obustronnej komunikacji, problematyczna bywa konfiguracja sieci, w szczególności zapory ogniowe i NAT. W przypadku MQTT komunikacja jest obustronna, ale połączenie zestawia zawsze klient, który z reguły nie ma problemu z komunikacją na zewnątrz. Dlatego, nawet wymiana danych z brokerami umieszczonymi w Internecie, nie stanowi zazwyczaj żadnej trudności.
Kolejki komunikatów
Szczególnie dla prostych klientów, dużym odciążeniem przetwarzania jest przeniesienie zarządzania dostarczaniem wiadomości na brokera. Dzięki temu jedynym zadaniem klienta jest wysłanie wiadomości, a już dystrybucją ma się w pełni zająć broker. Gdy zaimplementujemy rozsądne nazewnictwo kanałów, to czytelność konfiguracji i obsługa wiadomości staje się bardzo prosta.
Szerokie wsparcie
MQTT jest wykorzystywany przez bardzo wielu producentów. Gdy dodamy do tego projekt zigbee2mqtt, łączący świat bezprzewodowych elementów automatyki z brokerem MQTT, dostaniemy całkiem szeroki ekosystem z warstwą komunikacyjną, którą obsłużymy w bardzo prosty sposób. I to chyba powszechność tego protokołu jest jego największą zaletą.
Wady MQTT
Wad tak naprawdę nie jestem w stanie znaleźć wiele. Są one w większej mierze cechami rozwiązania niż rzeczywistym problemem. Poza tym, nikt nie powiedział, że możemy stosować już tylko MQTT. Gdy któraś z wad jest naprawdę istotna, to zawsze możemy zastosować inny protokół.
Dodatkowy komponent
Nie da się ukryć, że gdy zależy nam na bardzo prostej architekturze, to broker MQTT jest dodatkowym, potencjalnie zawodnym komponentem. Oczywiście nie zawsze jest to uzasadnione i gdy mamy tylko jednego klienta, albo klientów jednego typu i jeden specjalizowany serwer warto rozważyć inne alternatywy.
Użycie ciągłego połączenia TCP
Z jednej strony lekkość i efektywność była wymieniona jako zaleta, z drugiej jednak dla bardzo prostych zastosowań, gdzie pozostałe zalety protokołu są mniej istotne, warto rozważyć użycie pakietów UDP lub nawiązywanie połączeń http. Mogą być one lżejsze i prostsze w implementacji.
Narzędzia
Mimo, że narzędzia są dostępne na każdą platformę, to nic nie jest w stanie pobić protokołu http, przy powszechności występowania przeglądarek na niemal każdym urządzeniu klienckim.
Podsumowanie
Zainteresowałem się poważniej MQTT, zachęcony jest rosnącą popularnością. W tej chwili w nowych urządzeniach implementuję MQTT, a część starszych także będę przeprogramowywał. Dlaczego? Ze względu na dążenie do względnej standaryzacji. Mimo, że nadal stosuję własne rozwiązania, to uważam, że ich łatwe łączenie z rozwiązaniami obecnymi na rynku, a także możliwość łatwego zrozumienia działania przez inne osoby, jest bardzo ważna. Tym bardziej, że zawsze byłem zwolennikiem otwartych standardów.