MQTT: De standaard voor IoT Messaging

MQTT, een OASIS standaard berichtenprotocol voor IoT. In zijn blog vertelt Samet hoe je dit onderwerp kunt aanpakken, welke verwerkingsstijl nodig is en hoe je je datastromen met behulp van MQTT aan je verwerkingsengine kunt koppelen. Hij vertelt ook welke versie je moet gebruiken om MQTT te implementeren.

In deze blog

MQTT is een OASIS standaard messaging protocol voor Internet of Things (IoT). Maar wat kun je er nu precies mee doen? MQTT is ontworpen als een extreem lichtgewicht publish/subscribe messaging protocol. Ideaal  voor het verbinden van remote apparaten met minimale netwerk bandbreedte. Dit is een korte beschrijving van MQTT op hun website https://mqtt.org/.  De vraag is hoe je het toe kan passen en of MQTT al jouw IoT uitdagingen daadwerkelijk oplost.

In sommige sectoren zijn IoT apparaten al jaren gangbaar en alles behalve nieuw, maar de interactie met sensordata is in de loop der jaren behoorlijk veranderd.

Er zijn veel verschillende traditionele manieren om te communiceren met IoT gateways en bijna elke leverancier heeft zijn eigen meegeleverde software en maatwerk stappen om te doorlopen. De ruwe sensordata worden verzonden, opgeslagen en kunnen op elk moment worden opgevraagd. Hoewel er verschillende bronnen kunnen zijn, zoals apparatuur-, gebied of meterdata, hebben ze hoogstwaarschijnlijk dezelfde kenmerken:

  1. Zeer hoge volumes aan kleine data pakketten
  2. De meeste data bestaat uit herhalende tijdsreeksen

Waarom is dit relevant om te vermelden? Omdat alleen ruwe data geen waarde heeft. Om sensor data om te zetten in zinvolle en bruikbare informatie, moet het eerst bewerkt en verwerkt worden. Bij hoge volumes aan data kan het verwerken ervan een hele uitdaging zijn. MQTT is specifiek ontworpen om lichtgewicht messaging met apparaten mogelijk te maken en lost dus primair het probleem van transport op, niet het probleem van het verwerken of zinvol gebruiken van de data. MQTT is zo efficiënt omdat het de data ontkoppelt en niet afhankelijk is van synchrone poll/responses. Als je geïnteresseerd bent in de historie en het verhaal van de mede-uitvinder van MQTT zelf, is dit artikel een aanrader.

Manier van verwerken

Om data in bruikbare informatie om te zetten, is bewerking vereist. De wijze waarop de data wordt getransporteerd moet de bewerking later in het proces vereenvoudigen. Bewerking kan op een aantal manier gebeuren, een traditionele manier is batchverwerking. Hoewel batchverwerking nog op grote schaal wordt gedaan, kan het in veel gevallen omslachtig zijn omdat:

  1. 90% van de data niet is gewijzigd of niet significant genoeg. Bijvoorbeeld een temperatuur sensor die altijd dezelfde temperatuur verstuurd. Je wil alleen reageren als de temperatuur significant daalt of stijgt.
  2. 90% van de tijd ben je te laat, omdat er vertraging is tussen het verzamelen van de data en de verwerking ervan. Als bijvoorbeeld een spoorwegwissel zijn eigen defect signaleert, wil je niet wachten tot de volgende dag.

Dit betekent niet dat je jouw IoT-datastroom niet in batches kunt verwerken, want er zijn nog steeds gevallen waarin de hoeveelheid data beheersbaar is of je simpelweg niet zo veel data hebt. Als dat zo is, kun je de data ergens in een database opslaan en er analyses op uitvoeren. Het gebruiken van een MQTT client om toegang te krijgen tot je data kan het proces versnellen.

Als je wel grote hoeveelheden data hebt en je wilt niet te laat zijn om te reageren, dan is real-time  verwerking meer geschikt. Iedereen met enige ervaring in software architectuur weet: real-time betekent hard werken en vereist een capabele en robuuste infrastructuur, inclusief de juiste tools om te kunnen reageren op gebeurtenissen die plaats vinden en misschien nog wel belangrijker: weten op welke gebeurtenissen je niet moet reageren, omdat ze niet relevant zijn voor het nemen van een besluit in jouw proces. Alle data opslaan in ouderwetse databases en deze herhaaldelijk uitvragen zal niet werken in de tegenwoordige tijd met veel data en een zeer hoog tempo waarin alles veranderd. Hoewel Event Streaming een populair antwoord is en veel uitdagingen in real-time verwerking aanpakt, heb je nog steeds iets nodig om je ruwe datastromen te transporteren en verbinden met de unit die verantwoordelijk is voor verwerking. MQTT biedt voornamelijk een oplossing voor de transport uitdaging.

Connecteer jouw data stromen met de verwerkende unit met MQTT

Het verbinden van je IoT datastromen met jouw core, dat is precies wat MQTT kan doen. MQTT en Kafka worden vaak verward als alternatieven voor elkaar, maar ze verschillen in doel en oorsprong. Beide technieken kunnen complementair aan elkaar gebruikt worden. De verwarring rond MQTT en Kafka is begrijpelijk, omdat beide een asynchrone publish/subscribe patroon implementatie zijn.

Waar Kafka zich richt op het gedistribueerd bewaren van persistente gegevens op topics, richt MQTT zich op betrouwbare communicatie tussen client en broker. Nog een ander verschil: MQTT is een protocol en Kafka is een software oplossing die implementatie van de Kafka client in jouw software stack vereist. Wanneer data succesvol overgedragen wordt vanuit IoT  apparaten naar de broker, is de belangrijkste taak van zowel de MQTT-client als broker volbracht.

Voor de Kafka oplossing begint de belangrijkste functie hier: het bewaren van de data op Kafka topics met de geconfigureerde retentie, zodat de verwerkende unit het zware werk kan doen. Maar voordat enige verwerking kan beginnen, moet irrelevante  data eruit gefilterd worden. Zoals eerder vermeld: 90% van de data is niet veranderd of niet significant genoeg, dus waarschijnlijk kan dit worden verwijderd en is het niet relevant voor verwerking.

Welke versie moet je gebruiken?

eMagiz heeft een paar weken geleden ondersteuning voor een  MQTT broker toegevoegd. Verbinden met MQTT clients was technisch al mogelijk, maar nu is het ook mogelijk om jou message broker uit te rusten met een MQTT gateway.

Het fungeert als een bridge voor je core en kan worden gebruikt als een gateway die jouw IoT gegevens koppelt met jouw event streaming oplossing. Alle clients die versie 3.1.1. ondersteunen kunnen hun data publiceren naar deze MQTT broker. Deze versie is niet de laatste, dat is versie 5.0. Hoewel versie 5.0 verschilt van versie 3.1.1 met enkele verbeteringen, wordt het niet veel gebruikt en is het (nog niet) geaccepteerd als de facto standaard. Versie 5.0 maakt het protocol flexibeler en neemt nog minder bandbreedte in beslag. Veel leveranciers en dus ook software ondersteunen echter nog steeds alleen versie 3.1.1.

Bij het implementeren van MQTT is het gebruik en de keuze voor de meest geschikte QoS configuratie  belangrijk en wordt dit als een uitdaging gezien.

Volgende keer zal ik wat meer vertellen over zowel dit onderwerp als over andere relevante onderwerpen. Laat me weten wat je vindt of deel jouw ervaringen met mij via LinkedIn. Bedankt voor het lezen!

Door Samet Kaya, Software Delivery Manager @ eMagiz

Twitter
LinkedIn
WhatsApp
Email
nl_NL_formal