Node-RED/MQTT

MQTT

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.

Centrale spil bij MQTT

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.

protocol MQTT IoT-protocol MQTT-protocol inleiding uitleg broker communicatie beveiliging OpenHAB thuisnetwerk netwerk schema

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).
Protocol met 3 QoS-klassen

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.
————–

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *