In de vorige aflevering schreef ik over TCP , een klassiek protocol om IP-pakketten uit te wisselen tussen twee sockets (deelnemers in het netwerk met een IP-adres en een poortnummer). TCP zorgt ervoor, dat de pakketten ook aankomen. Omdat veel programmeertalen ingebouwde functies hebben voor het programmeren met sockets, kunnen we met een eenvoudig (zelfbedacht) toepassingsprotocol al een kleine, betrouwbare besturing programmeren. We hoeven alleen maar korte strings, zoals „ON“, „RED“ of „3“, te versturen als nuttige lading in TCP /IP-pakketten.

Maar bij typische IoT-taken zoals het meten van grootheden uit de omgeving of domotica hebben we te maken met veel deelnemers in het netwerk. Er zijn knooppunten die data produceren en knooppunten die data consumeren, bijvoorbeeld voor verdere verwerking en weergave. We moeten er ook rekening mee houden, dat knooppunten niet altijd online zijn. Gelukkig is er al een efficiënt protocol, dat bovenop TCP /IP werkt en speciaal voor dat soort taken bedoeld is: MQTT. In plaats van rechtstreekse verbindingen tussen dataproducenten en -consumenten maakt dit al rond de millenniumwisseling ontwikkelde protocol gebruik van een bericht-broker, die de berichten verder verdeelt. Dataproducenten (zoals bijvoorbeeld sensorknooppunten) en dataconsumenten (zoals bijvoorbeeld smartphone-apps) kunnen zich aanmelden bij deze broker. De bericht-broker beheert dan de lijst van IP-adressen; de ontwikkelaar/gebruiker hoeft zich over die onoverzichtelijke getallen geen zorgen meer te maken. Dataproducenten zoals sensorknooppunten vertellen de broker bij het aanmelden, dat ze meetwaarden over een bepaald „thema“ of topic publiceren (publish). Zulke topics zijn gemakkelijk te onthouden tekenreeksen zoals bijvoorbeeld:

Gebouw/kantoor/temperatuur
Gebouw/keuken/temperatuur

Om zulke data te ontvangen, bijvoorbeeld met een smartphone-app, kan de app zich op bepaalde topics abonneren (subscribe), waarbij ook wildcards toegestaan zijn, bijvoorbeeld:

Gebouw/+/temperatuur

Maar MQTT kan nog meer: Het kan desgewenst garanderen (bovenop de beveiliging door TCP ), dat de data ook aankomt. Daarbij worden drie serviceniveaus ondersteund (0 = geen garantie, 1 = komt minstens 1x aan, 2 = komt precies 1x aan). Heel nuttig is ook de „laatste wil“ (last will). Alle knooppunten (clients) kunnen bij de bericht-broker één bericht per topic deponeren, dat bij het wegvallen van de verbinding aan alle abonnees wordt verzonden. De broker kan ook per topic een „bewaard bericht“ (retained message) opslaan; dat gaat altijd naar alle nieuw aangemelde abonnees. Dat is bijvoorbeeld nuttig voor sensoren, die maar af en toe data genereren: zo is de laatste meetwaarde altijd beschikbaar voor iedereen.

Het is in elk geval nuttig om u in dit protocol te verdiepen, want het hele protocol is in handen van de open source-community en bovendien wordt het gebruikt door verschillende bekende spelers op de IoT-markt.
We gaan verder in de volgende aflevering!
 
Officiële MQTT-pagina’s:
http://mqtt.org/
 
Leestip (Duits):
www.heise.de/developer/artikel/MQTT-Protokoll-fuer-das-Internet-der-Dinge-2168152.html
 
Leestip (Engels):
www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt