De naam MQTT zal niet bij veel mensen een belletje doen rinkelen, maar het internet-of-things-protocol vormt de basis van talloze systemen in domotica. We kijken naar de werking van dit protocol en de verschillende manieren waarop je het kunt inzetten.

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.

©PXimport

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.

Wikipedia heeft een deal gesloten met bedrijven als Microsoft, Amazon en Mistral AI. Zij gaan voortaan betalen voor toegang tot Wikipedia Enterprise. In ruil krijgen ze toegang tot grote hoeveelheden content uit de online encyclopedie.

De samenwerking werd gisteren aangekondigd – precies op de vijfentwintigste verjaardag van Wikipedia. De samenwerking tussen de encyclopedie en bedrijven als Microsoft, Meta, Amazon, Mistral AI en Perplexity zorgt ervoor dat zij allen gebruik kunnen maken van Wikipedia Enterprise. Het is niet bekend hoeveel deze bedrijven betalen voor hun lidmaatschap.

Wat is Wikipedia Enterprise?

Wikipedia Enterprise is de commerciële tak van Wikipedia waarbij aangesloten bedrijven op grote schaal data aangeleverd krijgen via een API-dienst. Zo kunnen AI-bedrijven, zoekmachines en spraakassistenten op grote schaal betrouwbare data van Wikipedia ontvangen die door machines gelezen kan worden.

Kortgezegd is dit een efficiënte en makkelijke manier voor bedrijven om de informatie uit Wikipedia-pagina's voor hun eigen producten te gebruiken. Daarbij gaat het ook om de meest recente versies van Wikipedia-pagina's, zodat informatie altijd zo nieuw mogelijk en dus relevant is.

Lees ook: Kennis delen? Zo werk je mee aan Wikipedia

Waarom sluiten bedrijven zich bij Wikipedia Enterprise aan?

Hoewel elk bedrijf zijn eigen reden heeft om zich bij Wikipedia Enterprise aan te sluiten, lijken de deze week aangekondigde samenwerkingen vooral te maken te hebben met het gebruik van Wikipedia-info voor AI. Op die manier kunnen AI-bots getraind worden met correcte info van Wikipedia die door mensen is geschreven, waardoor ze steeds slimmer worden en ook steeds meer informatie kunnen bieden.

De samenwerking voelt deels symbolisch: bedrijven laten hun AI-modellen al geruime tijd gebruikmaken van Wikipedia en alle andere bronnen op het internet, waardoor Wikipedia aanzienlijk minder bezoek krijgt vergeleken met enkele jaren geleden. Wikipedia riep AI-bedrijven afgelopen jaar dan ook op te betalen voor het gebruik van Wikipedia-pagina's voor AI-training. Daar hebben Microsoft, Meta, Amazon en consorten nu dus gehoor aan gegeven. Andere bedrijven, zoals Google, hadden zich al aangesloten bij Wikipedia Enterprise.

Het was al bekend dat Lego dit jaar met een nieuwe set gebaseerd op Nintendo's populaire gamereeks gaat komen, en nu zijn er zowel details als foto's van de 'The Legend of Zelda: Ocarina of Time'-set opgedoken.

De informatie en afbeeldingen zijn afkomstig van het Reddit-account Brick Tap. Het account plaatste deze op de Lego Leaks-subreddit, en onthulde daarmee dat de set een diorama van het laatste gevecht in The Legend of Zelda: Ocarina of Time is. 

Link neemt het hierin op tegen de kwaadaardige Ganondorf, en beide personages zijn dan ook inbegrepen. Ook Princess Zelda is van de partij, en de doos toont al dat we ook Ganon in zijn demonenvorm kunnen bouwen bij aankoop van de 'The Final Battle: Ocarina of Time'-set.

De set is dus nog niet officieel onthuld, maar volgens Brick Tap bevat de doos 1003 steentjes om het eindgevecht uit Ocarina of Time mee na te bouwen. Ook zegt hij dat de prijs 120 euro zal worden. Op 1 maart moet deze Lego-set in de winkels liggen, dus het valt te verwachten dat Lego deze binnenkort officieel uit de doeken doet. 

Vorig jaar werd al bekend dat Lego nog een Legend of Zelda-set uit ging brengen, nadat het bedrijf eerder al een set gebaseerd op de Great Deku Tree uit de Nintendo-franchise had uitgebracht. Die set kon je op twee manieren bouwen: als de Deku Tree uit The Legend of Zelda: Breath of the Wild, of als de versie van Ocarina of Time. 

Nintendo is zelf ook nog altijd bezig met The Legend of Zelda. Hoewel er nog weinig bekend is over het volgende deel in de reeks, bracht het bedrijf in 2024 The Legend of Zelda: Echoes of Wisdom uit, waarin de titulaire prinses voor het eerst de hoofdrol speelde. Ook heeft het Japanse bedrijf de handen ineen geslagen met Sony Pictures om een live-action Zelda-film te maken, waarvan in 2025 de eerste beelden zijn getoond. De film draait vanaf 7 mei 2027 in de bioscoop.