MQTT voor IoT: betrouwbaar protocol voor data-uitwisseling

Als sensoren, actuatoren en machines moeten communiceren, hebben ze een gemeenschappelijke taal nodig. MQTT is zowel geschikt voor industriële installaties als voor huisnetwerken en is robuust genoeg bij onbetrouwbare verbindingen.  Een introductie en toelichting op dit protocol.

Een protocol voor de communicatie tussen apparaten moet in elk geval kunnen omgaan met problemen. De communicatiepartners kunnen om verschillende redenen onbereikbaar zijn, berichten kunnen verloren gaan en verbindingen kunnen tijdens de transmissie afgebroken worden. MQTT (Message Queue Telemetry Transport) is gebaseerd op TCP/IP en probeert de problemen van onbetrouwbare verbindingen op te lossen met een centrale bemiddelaar: de MQTT-broker.

Dat is de interface voor alle verzonden berichten. De betrokken apparaten communiceren alleen met de broker en kennen elkaar onderling verder niet. Ze hoeven de ip-adressen en de technische details van de andere deelnemers dus niet te weten. Het is de taak van de broker om berichten te accepteren en aan de juiste ontvanger door te geven.

Als een sensor, bijvoorbeeld een microcontroller met een temperatuursensor, wil communiceren via MQTT, moet hij eerst verbinding maken met de broker. Bij het MQTT-protocol is poort 1883 gereserveerd voor onversleutelde en poort 8883 voor versleutelde communicatie. MQTT is, anders dan bijvoorbeeld HTTP, een statusbehoudend protocol. Een verbinding kan dus ook blijven bestaan als er geen gegevens worden verzonden.

Als de sensor een temperatuurwaarde wil doorgeven, verstuurt hij een bericht van het type PUBLISH. Elk bericht bevat een liefst beschrijvende topic en een inhoud, de payload. Het topic lijkt qua opbouw op een Unix-bestandspad. De secties worden gescheiden door een /. Bij de formulering heeft de beheerder van de MQTT-omgeving de vrije hand. In een thuisnetwerk kan de sensor het topic house/rooms/wc/sensors/temperature met de waarde 22.5 aan de broker doorgeven. Daarmee is zijn taak volbracht en hoeft hij zich verder geen zorgen te maken voor welke apparaten deze informatie belangrijk is.

Een apparaat dat berichten wil ontvangen, maakt verbinding met de broker en abonneert zich met de opdracht SUBSCRIBE op een of meer topics. Voor het opvragen van meer waarden zijn er twee jokertekens (die dus niet in de naam van een topic voor kunnen komen).

Met # worden alle berichten op de lagere niveaus aangevraagd. Dat teken kan dus alleen aan het einde staan: house/rooms/wc/# is een abonnement voor alle berichten die op de wc van toepassing zijn. + is het teken voor een niveau: house/rooms/+/sensors/temperature is een abonnement op alle temperaturen. Een MQTT-compatibele radiatorthermostaat kan zo bijvoorbeeld alle sensorwaarden van een huis opvragen en daar op reageren. De broker slaat de abonnementen op en geeft de binnenkomende berichten onmiddellijk door aan alle abonnees die op dat moment verbonden zijn. Als een abonnee zich later aanmeldt, krijgt hij die informatie niet meer.

De zender kan bij het publiceren dan ook de retain-vlag zetten. Die geeft aan dat het bericht direct moet worden doorgegeven na een SUBSCRIBE. In dat geval slaat de broker de laatste waarde voor het topic op en geeft die door (en dus niet alle eerdere berichten uit het verleden).

MQTT heeft een mechanisme voor Quality of Service. Daarbij gaat het er niet om dat bepaalde berichten voorrang krijgen, maar om een soort ontvangstbevestiging. Elk bericht dat verstuurd wordt, krijgt een QoS-niveau mee. Niveau 0 bepaalt dat een bericht zonder bevestiging eenmalig verstuurd wordt. Dat gaat snel en bespaart bronnen. Voor eenvoudige sensorwaarden is dat voldoende, maar het is niet aan te bevelen als het functioneren van een fabrieksinstallatie afhankelijk is van die informatie en de netwerkverbinding slecht is.

Een bericht met de QoS-waarde 1 komt minstens een keer aan bij de ontvanger. Als antwoord op een PUBLISH verstuurt de ontvanger PUBACK. Als deze reactie uitblijft, probeert de zender het opnieuw tot de ontvangst bevestigd wordt. Bij die procedure kan het voorkomen dat een bericht vaker aankomt als de bevestiging verloren gaat. De ontwikkelaar moet ervoor zorgen dat daar geen problemen door kunnen ontstaan. Als een robotarm per ongeluk meerdere keren de opdracht krijgt een bepaalde afstand naar voren te gaan, kan dat vervelende gevolgen hebben.

QoS-niveau 2 van het MQTT-protocol is ingewikkelder, maar ook betrouwbaarder. Daarbij dragen beide gesprekspartners zorg dat een bericht precies één keer bij de partner aankomt. Zender A verzendt een bericht via PUBLISH met een bericht-ID. Ontvanger B bevestigt dit met PUBREC en slaat het bericht zolang op. Als zender A deze bevestiging ontvangt, retourneert hij PUBREL, waarna hij het bericht gerust kan schrappen. Hij zal het onder geen voorwaarde meer opnieuw verzenden. Hij weet nu zeker dat B het bericht ontvangen heeft. Ten slotte stuurt ontvanger B een laatste bericht naar A: PUBCOMP. Pas dan begint B het bericht te verwerken

Als B een broker is, zal hij pas na het verzenden van PUBCOMP het bericht naar de abonnees verzenden . Als een van de twee partners een ontvangstbevestiging ontvangt buiten de gedefinieerde wachttijd, gaat hij een stap terug en verzendt hij zijn laatste bevestiging nog een keer, maar het oorspronkelijke bericht nooit nogmaals.

Een verbroken verbinding komt vaker voor dan je denkt. Als een apparaat offline gaat, kan het niet meer alle apparaten waarschuwen die misschien op een bericht wachten. De ontwikkelaars van MQTT hebben in het protocol met die situatie rekening gehouden.

Wanneer een client verbinding maakt met de broker, kan hij een laatste wil deponeren en daar dezelfde eigenschappen voor instellen die ook voor normale berichten van het protocol gelden: topic, payload, QoS en retain-vlag. De broker accepteert die laatste wil en geeft hem door aan de abonnees zodra de verbinding verloren gaat.

Als je thuis met MQTT wilt experimenteren of je huis wilt automatiseren met het protocol, kun je terugvallen op verschillende opensourcebrokers. De software Mosquitto is het populairst. Die is ontwikkeld door de Eclipse Foundation. Het gebruik op Linux is een aanrader: een Raspberry Pi met Raspbian Stretch of Jessie wordt met één regel een Mosquitto-server: sudo apt install mosquitto. De ontwikkelaars stellen ook een versie voor Windows ter beschikking, maar daarbij ontbreken enkele dll’s die je zelf moet kopiëren uit een speciale OpenSSL-installatie.

Als je de mogelijkheden van MQTT wilt uitproberen, is een grafische client handig zoals MQTT.fx. Die is gebaseerd op Java en werkt onder macOS, Linux en Windows. Je downloadt hem via de site. Na de eerste start schakel je met het blauwe paginasymbool over naar de vrije invoer van een serveradres. Maak verbinding met de Mosquitto-instantie via poort 1883. Op het tabblad ‘Broker’staat dan een statusoverzicht van de server. Ga daarvoor in het menu naar ‘Mosquitto’ en sluit een abonnement af voor de statusberichten van de server.

Op het tabblad ‘Subscribe’ abonneer je je op een willekeurig topic (of direct op alle topics met #). Op het tabblad ‘Publish’ verstuur je zelf berichten, die je als het goed is weer terugziet in het venster ‘Subscribe’. Als je een tweede computer bij de hand hebt, die pas later verbinding maakt, kun je de werking van de retain-vlag makkelijk testen.

De MQTT-broker is alleen verantwoordelijk voor het ontvangen en versturen van berichten. De broker heeft dus geen functies om regels te definiëren of acties uit te voeren. Smart-home-programma’s als openHAB en Home Assistant werken echter samen met een MQTT-broker. Zij abonneren zich op al het verkeer, nemen beslissingen op basis van die en andere gegevens en publiceren berichten met stuurinstructies.

Een MQTT-compatibele lichtschakelaar verstuurt bijvoorbeeld op het topic house/rooms/livingroom/switch het bericht ‘on‘. De home-automation die zich op dat onderwerp geabonneerd heeft voert dan een regel uit: ‘Doe het licht aan als de schakelaar is ingedrukt en het buiten donker is.’ Van een andere bron (van internet of via een berekening) wordt de informatie opgehaald of de zon al onder is en dan wordt het bericht house/rooms/ livingroom/lamp met de waarde ‘on‘ verstuurd. Het relais is op dit topic geabonneerd en schakelt in. Als je alle logica tussen sensor en actuator via een centrale laat lopen, maak je je aan de ene kant daarvan afhankelijk, maar kun je wel snel nieuwe functies inbouwen zonder iets te hoeven veranderen aan de eindapparaten.

Zonder verdere maatregelen is al het MQTT-verkeer net zo veilig of onveilig als het netwerk waarover het verzonden wordt. Elk apparaat kan zich op alle topics abonneren en daarover berichten versturen. De berichten zijn niet versleuteld. Via een IoT-zoekmachine als Shodan kun je van buitenaf toegankelijke MQTT-toepassingen vinden. Gelukkig hebben de ontwikkelaars van MQTT beveiligingsfuncties ingebouwd. Meer hierover lees je in het MQTT-artikel in c’t magazine 5/2018. Daar lees je onder andere ook meer over poortinstellingen en apps voor MQTT.

De toepassingsmogelijkheden van MQTT gaan in ieder geval veel verder dan home-automation en industriële installaties. Zo bleek uit een blogpost van een Facebook-ontwikkelaar dat ook Facebook Messenger voor een deel met MQTT werkt. Meer over MQTT en andere IoT-protocollen lees je op de website en in uitgaven van c’t magazine.

(Jan Mahn / Noud van Kruysbergen, c’t magazine 5/2018)