Het internet der dingen (internet of things, IoT) is de laatste jaren een hype, maar de meest gebruikte technologie om al die apparaten met elkaar te laten praten bestaat al twintig jaar: MQTT (Message Queuing Telemetry Transport). De eerste versie van het MQTT-protocol werd namelijk al in 1999 geschreven door Andy Stanford-Clark van IBM en Arlen Nipper van Arcom (later Eurotech).

Hun bedoeling was om een licht protocol te ontwikkelen dat met een efficiënt gebruik van bandbreedte allerlei soorten gegevens kon doorsturen met verschillende vormen van quality of service (QoS). En laat dat nu net een combinatie van eigenschappen zijn die essentieel is in het internet of things. Het mag dan ook niet verbazen dat talloze IoT-projecten ervoor gekozen hebben om onder de motorkap MQTT te gebruiken. Overigens toonde MQTT-uitvinder Stanford-Clark in 2009 de mogelijkheden al door zijn domoticasysteem via MQTT met Twitter te verbinden.

Centrale tussenpartij

Een cruciale rol in MQTT is weggelegd de ‘broker’, een centrale tussenpartij die de communicatie tussen zenders en ontvangers in goede banen leidt. In traditioneler taalgebruik zouden we het de server noemen. De broker is niet de enige afwijkende term die het MQTT-protocol gebruikt: een zender heet er uitgever (‘publisher’) en een ontvanger abonnee (‘subscriber’). Beide zijn vormen van clients. Uiteraard kan een client ook zowel zenden als ontvangen.

De broker zorgt ervoor dat uitgevers en abonnees niet van elkaars bestaan hoeven te weten: alles verloopt via de broker. Dat gaat als volgt: de broker beheert onderwerpen (‘topics’) met inhoud (‘payloads’). Een abonnee die in een onderwerp geïnteresseerd is, abonneert zich daarop bij de broker. Een uitgever die een boodschap wil sturen, publiceert zijn inhoud op een specifiek onderwerp door dit naar de broker te sturen. Zodra de broker een boodschap voor een onderwerp ontvangt, stuurt hij die door naar alle clients die op dit onderwerp geabonneerd zijn.

Hiërarchische onderwerpen

Een onderwerp kunnen we dus beschouwen als een soort locatie waarvan de naam bij uitgever en abonnee bekend is. Maar om hier wat systematiek in te brengen, definieert MQTT de onderwerpen als hiërarchische namen, gescheiden door een slash (/), zoals in url’s. Elke toepassing is voor de rest volledig vrij in de keuze van de namen; in tegenstelling tot url’s zijn er dus geen vastgelegde topdomeinen.

Wil je wat orde in je MQTT-netwerk houden, dan is het aan te raden om een systeem voor je onderwerpen te gebruiken. Een domoticatoepassing als Home Assistant doet dat door de onderwerpen van de volgende vorm te maken:

Daarbij is discovery_prefix standaard gelijk aan homeassistant. Component het type component, zoals binary_sensor enzovoort. Een voorbeeld van een onderwerp is:

Dat bevat als inhoud de temperatuur van een temperatuursensor in de slaapkamer, bijvoorbeeld 18.7.

Wildcards

MQTT kent ook ‘wildcards’ voor onderwerpen. Een client die in alle onderwerpen onder homeassistant/sensor/slaapkamer_temperature geïnteresseerd is, abonneert zich dan op:

Hij krijgt dan ook boodschappen over de onderwerpen:

Enzovoort.En als een client in alle onderwerpen van Home Assistant geïnteresseerd is, abonneert hij zich op:

Soms ben je geïnteresseerd in alle onderwerpen met een specifieke naam van het onderste niveau, ongeacht het niveau erboven. Daarvoor gebruik je de wildcard +. Zo abonneer je je bijvoorbeeld eenvoudig op de boodschappen over de laatste veranderingen van alle sensoren in Home Assistant:

De hiërarchische opbouw van onderwerpen maakt dit heel eenvoudig.

Verbinding en beveiliging

MQTT is ontworpen om over tcp/ip te draaien, meestal op poort 1883. Recentelijk is ook MQTT over WebSocket populair, omdat dit het mogelijk maakt om rechtstreeks in een webbrowser via MQTT te communiceren. Een JavaScript-client pakt de pakketten dan uit de WebSocket-laag uit en behandelt de MQTT-pakketten die erin zitten. MQTT over WebSocket verloopt meestal via poort 9001. Zowel MQTT over tcp/ip als MQTT over WebSocket zijn ook te gebruiken over een versleutelde verbinding, via tls.

Tot nu toe lijkt het alsof iedereen zomaar alle onderwerpen op je MQTT-broker kan uitlezen, en zo gebeurt het in veel lokale MQTT-installaties ook, maar de meeste MQTT-brokers bieden een gebruikersbeheer met bijbehorende authenticatie en gebruikersrechten. Je stelt dan in de configuratie van de broker in dat elke MQTT-client zich moet aanmelden met een gebruikersnaam en wachtwoord en lees- en schrijfrechten voor specifieke onderwerpen heeft. Zo voorkom je dat een willekeurige sensornode in je netwerk waarin iemand is ingebroken je hele domoticasysteem via MQTT kan aansturen.

Zelf aan de slag met MQTT

MQTT is in heel wat software ondersteund, dus je kunt het protocol zelf eenvoudig in je eigen projecten inzetten. Een eenvoudige manier om een Raspberry Pi, Arduino of ESP8266 via MQTT over internet te laten werken, is via de clouddienst Adafruit IO. Werk je liever in het ecosysteem van Amazon of Microsoft, gebruik dan AWS IoT respectievelijk Azure IoT Hub.

Je hoeft MQTT trouwens niet in de cloud te gebruiken: met het opensourceproject Eclipse Mosquitto, dat MQTT-protocols 3.1 en 3.1.1 ondersteunt, draai je eenvoudig een MQTT-broker op je eigen netwerk. Mosquitto komt ook met eenvoudige MQTT-clients voor op de opdrachtregel: mosquitto_pub en mosquitto_sub.

Wil je op een grafische manier MQTT-boodschappen doorzoeken, bekijken en publiceren, dan is MQTT Explorer een handig programma.

Wil je MQTT in je eigen programma’s gebruiken, dan is het project Eclipse Paho met bibliotheken in C, C++, Java, JavaScript, Python en Lua onmisbaar.