Skip to main content

3.6 Komunikácia cez MQTT

MQTT

MQTT je veľmi efektívny protokol pre asynchrónnu IoT komunikáciu - realizuje sa cez protokol TCP, pričom minimálna fixná hlavička v MQTT zaberá len 2 bajty (1 bajt pre typ a príznaky, 1 bajt pre dĺžku správy), zvyšok sú už prenášané údaje.

Čo vlastne znamená skratka MQTT?

V súčasnosti to podľa autorov neznamená nič konkrétne a ide o samostatnú značku a nie skratku. Historicky to však bola skratka pre Message Queuing Telemetry Transport, čo odkazovalo na technológiu IBM MQ, pre ktorú bol protokol pôvodne už v roku 1999 vyvinutý.

Komunikačná architektúra

Komunikuje sa prostredníctvom makléra (broker - tým je MQTT server), ktorý len preberá a doručuje správy. Tieto správy však (štandardne) nearchivuje!

Vydavateľ (publisher - obvykle IoT zariadenie so senzorom) odosiela správy s definovanou témou (topic) maklérovi. Nerieši doručovanie a ani nevie, komu bude správa doručená a či vôbec bude niekomu doručená.

Odberateľ (subscriber - obvykle aplikácia) sa môže prihlásiť na odber ľubovoľnej témy u makléra. V podstate ani nevie, od koho príde nejaká správa (pokiaľ to nie je uvedené priamo v jej obsahu) a ani ho to nezaujíma. Zaujíma ho len obsah správy.

Z tejto komunikačnej architektúry vyplýva, že nie je potrebné priame spojenie medzi vydavateľom a odberateľom, čiže nie je potrebná ani verejná IP adresa, ani firewall povolenia na strane zariadení. Dostupný (viditeľný) musí byť pre obe strany len maklér (teda server).

MQTT správy

Správy nemajú predpísaný formát a môžeme v nich posielať, čo nám vyhovuje - prosté číselné hodnoty alebo texty (podporujú UTF-8), či komplexnejšie štruktúrované údaje vo formátoch ako JSON a XML. Správa môže mať veľkosť až 256 MiB.

Téma správy (topic)

Témy majú hierarchickú štruktúru, jednotlivé úrovne sa oddeľujú lomkou, napríklad „SSND/monitoring/UST-A2/teplota“ - pozor, rozlišujú sa malé a veľké písmená!

Je možné prihlásiť sa na odber všetkých vnorených tém nejakej témy, používa sa na to symbol „#“, napríklad:

  • „SSND/monitoring/UST-A2/#“ bude prijímať všetky údaje z miestnosti UST-A2;
  • „SSND/monitoring/#“ bude prijímať úplne všetko z monitoringu školy.

Okrem toho je možné symbolom „+“ odoberať ľubovoľnú tému presne na danej úrovni hierarchie, napríklad:

  • „SSND/monitoring/+/teplota“ bude odoberať teplotu zo všetkých miestností, ale už nie napríklad vlhkosť.

Spoľahlivosť doručenia správy (QoS)

Vydavateľ odosiela jednotlivé správy s nastavenou hodnotou spoľahlivosti QoS (Quality of Service):

  • QoS 0: správa sa má maklérovi odovzdať nanajvýš raz (teda nemusí sa doručiť vôbec - prebehne len jeden pokus o odoslanie a nie je spätná väzba);
  • QoS 1: správa sa má maklérovi odovzdať aspoň raz (môže sa doručiť aj viackrát - prebiehajú pokusy o doručenie, kým nie je prijaté potvrdenie);
  • QoS 2: správa sa má maklérovi odovzdať práve raz - tento spôsob zabezpečuje najvyššiu spoľahlivosť, no je najpomalší a nie vždy podporovaný na strane servera alebo i klienta.

Hodnotu QoS si nevolí len vydavateľ, ale aj odberateľ - tým dáva maklérovi najavo, akú maximálnu úroveň spoľahlivosti si pre daný odber želá. V konečnom dôsledku bude správa doručená odberateľovi s takou hodnotou QoS, ktorá je z týchto dvoch požiadaviek nižšia.

Načo sú nám viaceré úrovne QoS? Nie je QoS 0 zbytočná?

Niekedy je QoS 0 lepšia voľba. Napríklad v situácii, že sa prenáša informácia o stlačení tlačidla a reakciou na to je prepnutie stavu. Pokiaľ by sme nastavili QoS 1 a správa by sa garážovej bráne doručila dvakrát, tak brána sa začne otvárať a vzápätí by sa opäť zatvorila. Vždy je potrebné prihliadnuť na kontext situácie a zvoliť najvhodnejšiu hodnotu.

Uchovanie správy (retain)

Vydavateľ môže pre odosielanú správu nastaviť jej uchovanie (retain) na serveri. Znamená to len toľko, že posledná správa bude v danej téme uchovávaná na serveri (a okamžite odosielaná novým odberateľom hneď po pripojení) dovtedy, kým nepríde novšia správa v danej téme.

Prečo nenastaviť uchovanie správy vždy?

Uchovávanie miliónov správ by server zbytočne preťažilo. Navyše niekedy je nežiaduce zobraziť starý údaj. Ak teplomer odosiela aktuálnu teplotu každých 15 sekúnd a displej po výpadku dostane 2 hodiny starú hodnotu (cez uchovanie správy),  môže to byť mätúce. Je lepšie na chvíľu nezobraziť nič, než neaktuálnu teplotu.

Softvér pre MQTT

Pre odber správ z MQTT a na testovanie publikovania správ môžeme využiť bezplatný klientsky softvér, napríklad:

  • MQTT Explorer: jednoduchý klient bez potreby inštalácie, vie aj kresliť grafy, no podporuje len MQTT 3.1.1 a chýbajú niektoré pokročilé možnosti (napríklad Last Will a voľba Clean Session) a jeho vývoj už nepokračuje;
  • MQTTX: moderný klient, podporuje aj MQTT 5.0 a viac možností, no je nutné ho inštalovať a nekreslí grafy;
  • on-line MQTTX: odľahčená verzia dostupná priamo cez webový prehliadač.

Servery MQTT

Ako servery (maklérov) môžeme na tréning používať:

  • školský výučbový server: server.ust.ssnd.sk - prihlasovacie údaje sú uvedené v Classroom, treba nastaviť aj parameter keepalive, napríklad na 600 s;
  • verejný server HiveMQ: broker.hivemq.com - bez mena a hesla;
  • verejný server EMQX: broker.emqx.io - bez mena a hesla.

Štandardné TCP porty sú:

  • 1883 pre nešifrovaný MQTT protokol,
  • 8883 pre šifrovaný MQTT s SSL/TLS,
  • obvykle 8083 pre nešifrovaný WS (WebSocket, pre komunikáciu priamo z webového prehliadača).

Tému (Topic) v tomto kurze vytvárajme s predponou v tvare „IVI1/X/“, kde X je názov projektu, napríklad „bicykel“. Konkrétna téma môže vyzerať napríklad takto: „IVI1/bicykel/Fero/koleso“.

Back to top