IoT-0/IoT ketens

Voorbeelden van IoT-(deel)ketens

In het voorgaande hebben we de afzonderlijke onderdelen van het Internet of Things beschreven. Hieronder behandelen we een aantal voorbeelden om deze onderdelen samen te stellen tot een (deel)keten. Dit is vooral bedoeld als een eerste globale overzicht. In de volgende hoofdstukken werken we deze voorbeelden verder uit, met praktische opdrachten.

Concepten en leerdoelen

• client-server, "pull" interactie; "polling" om veranderingen te detecteren
• publish-subscribe interactie; "push" vanuit de broker

IoT-knoop als webserver

Als een IoT-knoop een ingebouwde webserver heeft kun je deze knoop direct vanuit een browser bedienen. De toepassing (web-app) komt dan van de IoT-knoop zelf. Sommige netwerkapparaten, zoals netwerkprinters en routers, gebruiken deze aanpak. De huidige microcontrollers zijn krachtig genoeg voor een kleine webserver.

Alleen apparaten in het lokale netwerk hebben toegang tot zo'n lokale webserver. Zonder extra voorzieningen is een lokale webserver niet vanuit het publieke internet toegankelijk.

Een webserver gebruikt het HTTP-protocol, in een client-server interactie. De webclient (in dit voorbeeld de smartphone) haalt ("pull") de data van de webserver (hier: IoT-knoop C). Om na te gaan of een sensorwaarde veranderd is, moet de smartphone regelmatig de de IoT-knoop raadplegen ("polling").

IoT-knoop met publieke MQTT-broker

Het MQTT-protocol is beter geschikt voor het IoT dan het webprotocol HTTP. IoT-knopen met een IP-protocolstack kunnen rechtstreeks communiceren met een publieke MQTT-broker. Toepassingen (web-apps) kunnen dan via de MQTT-broker communiceren met de IoT-knoop.

De interactie tussen de IoT-knopen en de web-apps met de MQTT-broker gebruikt het publish/subscribe-principe: clients kunnen berichten publiceren ("push") naar de broker, onder een bepaald onderwerp (topic); clients kunnen zich ook abonneren op de berichten van een onderwerp. De broker stuuurt de berichten door ("push") naar de clients die op dit onderwerp geabooneerd zijn. Voor de broker is er geen wezenlijk verschil tussen de clients: IoT-knopen en web-apps hebben hier dezelfde client-broker relatie.

IoT-knoop met lokale broker als bridge

Vaak is het handig om een lokale MQTT-broker te plaatsen tussen de lokale IoT-knopen en de publieke MQTT-broker. De IoT-knopen communiceren via het lokale (WiFi) netwerk met de lokale broker. De lokale broker communiceert met lokale toepassingen. Daarnaast fungeert de lokale broker als bridge naar de publieke MQTT-broker. Deze bridge scheidt zo het lokale IoT/MQTT-verkeer en het publieke IoT/MQTT-verkeer.

IoT-knoop met lokale gateway

Veel IoT-knopen gebruiken eenvoudige niet-IP protocollen. Een lokale gateway zorgt dan voor de protocolconversie, in dit geval tussen het lokale formaat van de IoT-knopen en het MQTT-toepassingsformaat. Deze lokale gateway verzorgt de communicatie met de publieke MQTT-broker, of met de lokale MQTT broker die ook als bridge fungeert. Als voorbeeld gebruiken we een eenvoudige pakketradio (RFM69) met een bereik van enkele honderden meters.

Iot-knoop met publieke gateway

Voor IoT-knopen die mobiel zijn in een groot gebied is het gebruik van een publieke gateway handig. Dit kun je vergelijken met het gebruik van de publieke zendmasten voor mobiele telefonie. Een voorbeeld The Things Network (TTN, op basis van LoRaWAN). De publieke TTN-gateways communiceren met een TTN-eigen server/MQTT-broker. Toepassingen (web-apps) communiceren via MQTT met deze TTN-server/broker.

We zullen in de volgende hoofdstukken deze vormen van de IoT-keten verder uitwerken.