Middleware for IoT / M2M - Semestre 9

Annee academique : 2024-2025
Enseignant : T. Monteil (LAAS-CNRS)
ECTS : 2.5
Categorie : IoT, Protocoles de communication, Middleware

Cours connexes :


PART A - Presentation Generale

Vue d'ensemble

Le cours "Middleware for IoT / M2M" aborde les architectures logicielles intermediaires (middleware) et les protocoles de communication dedies a l'Internet des Objets (IoT) et aux communications Machine-to-Machine (M2M). Il couvre l'ensemble de la chaine, depuis les protocoles de messagerie leger comme MQTT jusqu'aux standards de gestion de ressources comme oneM2M, en passant par le prototypage rapide d'applications IoT avec Node-RED.

L'objectif est de former des ingenieurs capables de concevoir, deployer et integrer des systemes IoT complets, en maitrise des protocoles de communication adaptes aux contraintes des objets connectes (bande passante limitee, consommation energetique, fiabilite).

Objectifs pedagogiques :

  • Comprendre les principaux standards de l'Internet des Objets (MQTT, oneM2M, CoAP)
  • Deployer et configurer des architectures IoT avec broker MQTT et CSE oneM2M
  • Programmer des microcontroleurs (NodeMCU/ESP8266) pour communiquer via MQTT
  • Concevoir des applications IoT avec Node-RED (prototypage rapide)
  • Comparer et choisir les protocoles adaptes aux cas d'usage IoT (HTTP vs MQTT vs CoAP)
  • Integrer capteurs, actionneurs et dashboards dans une architecture IoT complete
  • Analyser les enjeux de securite, scalabilite et interoperabilite des systemes M2M

Position dans le cursus

Ce module s'appuie sur les bases acquises anterieurement :

  • Reseau (S5-S8) : modele OSI, TCP/IP, HTTP, sockets
  • Microcontroleurs (S5-S7) : programmation embarquee, Arduino
  • Systemes d'exploitation : Linux, scripts Python

Il prepare et se connecte a :

  • Cloud et Edge Computing (S9) : deploiement d'architectures distribuees
  • Security for Connected Objects (S9) : securisation des communications IoT
  • Wireless Sensors Networks (S9) : couches physiques et liaison des capteurs
  • Projet Innovant (S9) : integration des protocoles IoT dans un projet reel

PART B - Experience et Contexte

Organisation et ressources

Le module combinait cours theoriques et travaux pratiques progressifs :

Cours magistraux :

  • Architecture IoT et pile protocolaire
  • Protocole MQTT : principes, QoS, topics, retain, last will
  • Standard oneM2M : architecture, ressources, CSE, AE
  • MOOC oneM2M (formation en autonomie)
  • Comparaison des protocoles IoT (HTTP, MQTT, CoAP, AMQP)
  • Patrons de communication M2M (publish/subscribe, request/response)

Travaux pratiques (TP) :

  • TP1-2 : Installation et configuration du broker MQTT Mosquitto, communication publish/subscribe, programmation NodeMCU/ESP8266 avec ArduinoMqttClient
  • TP3 : Standard oneM2M avec ACME CSE, creation de ressources (AE, Container, ContentInstance) via API RESTful, script Python simple_om2m.py
  • TP4 : Prototypage rapide avec Node-RED, integration MQTT, dashboard, gestion de capteurs et actionneurs, notifications email

Bureau d'Etudes (BE) :

  • Projet BE M2M : mise en oeuvre d'une architecture complete M2M integrant MQTT, oneM2M et Node-RED

Outils utilises :

  • Mosquitto : broker MQTT open-source
  • Arduino IDE : programmation ESP8266/NodeMCU
  • Node-RED : outil de prototypage visuel
  • ACME oneM2M CSE : implementation open-source du standard oneM2M
  • Python : scripts d'interaction avec les API oneM2M
  • cURL / Postman : test d'API RESTful

Ressources :

  • MOOC oneM2M (planning et contenu en autonomie)
  • Sujets de TP detailles (MQTT, oneM2M, Node-RED)
  • Documentation Mosquitto, ACME CSE, Node-RED
  • Sujet et presentation du BE M2M

Methodologie d'apprentissage

Phase 1 : Comprendre les fondamentaux :
Etudier l'architecture IoT, les modeles de communication (publish/subscribe vs request/response) et les contraintes specifiques des objets connectes.

Phase 2 : Maitriser MQTT :
Installer un broker, tester la communication en ligne de commande, puis programmer un microcontroleur pour publier et s'abonner a des topics.

Phase 3 : Decouvrir oneM2M :
Comprendre l'arbre de ressources, deployer un CSE, creer des Application Entities et des conteneurs via API REST.

Phase 4 : Prototypage rapide :
Utiliser Node-RED pour integrer tous les elements (capteurs, MQTT, dashboard, notifications) en un systeme fonctionnel.

Phase 5 : Integration et projet :
Combiner toutes les briques dans le BE M2M pour realiser une architecture IoT complete.

Mon role et mes responsabilites

Au cours de ce module, j'ai ete amene a :

  • Installer et configurer le broker MQTT Mosquitto sur Linux
  • Programmer un NodeMCU/ESP8266 pour la publication de donnees de capteurs (luminosite, etat bouton) via MQTT
  • Deployer et interagir avec un CSE oneM2M (ACME) via des requetes HTTP RESTful en Python
  • Concevoir des flux Node-RED integrant reception MQTT, logique de controle, dashboard et notifications
  • Rediger des rapports techniques detaillant les architectures deployees et les resultats obtenus

Difficultes rencontrees

Configuration reseau du broker :
La mise en place de Mosquitto avec les bons parametres d'ecoute et d'authentification a necessite plusieurs iterations pour fonctionner correctement avec le NodeMCU.

Programmation ESP8266 :
L'integration de la bibliotheque ArduinoMqttClient avec la gestion WiFi sur le NodeMCU a demande une bonne comprehension du cycle de vie de la connexion.

Standard oneM2M :
La richesse du standard oneM2M (nombreux types de ressources, droits d'acces ACP, structure hierarchique) est intimidante au debut. La documentation du MOOC a ete essentielle pour progresser.

Integration Node-RED :
La coordination entre les noeuds MQTT, les fonctions JavaScript et le dashboard a necessite du temps de mise au point pour obtenir un systeme reactif et fiable.


PART C - Aspects Techniques Detailles

1. Protocole MQTT - Architecture et principes

MQTT (Message Queuing Telemetry Transport) est un protocole de messagerie leger, concu pour les environnements contraints (bande passante limitee, ressources reduites). Il repose sur le modele publish/subscribe avec un intermediaire central appele broker.

Architecture MQTT :

ComposantRoleDescription
PublisherEmetteurPublie des messages sur des topics
SubscriberRecepteurS'abonne a des topics pour recevoir les messages
BrokerIntermediaireGere la distribution des messages entre publishers et subscribers
TopicCanalChaine hierarchique identifiant le sujet du message (ex: sensor/temperature)
MessageDonneeContenu publie sur un topic (payload)

Principes du publish/subscribe :

  • Les publishers et subscribers sont decouplees : ils ne se connaissent pas directement
  • Le broker se charge du routage des messages selon les abonnements
  • Un publisher peut publier sur plusieurs topics
  • Un subscriber peut s'abonner a plusieurs topics avec des wildcards (+ pour un niveau, # pour tous les sous-niveaux)

Fonctionnement detaille :

  1. Le subscriber s'abonne a un topic aupres du broker (ex: insa/luminosity)
  2. Le publisher publie un message sur ce topic
  3. Le broker transmet le message a tous les subscribers abonnes a ce topic
  4. Le decoupage hierarchique des topics permet une organisation flexible (ex: building1/floor2/room3/temperature)

Figure : Architecture MQTT - Modele publish/subscribe avec broker central

Niveaux de QoS (Quality of Service) :

MQTT propose trois niveaux de qualite de service pour la livraison des messages :

QoSNomGarantieUsage
0At most onceAucune garantie, "fire and forget"Donnees non critiques, telemetrie frequente
1At least onceMessage livre au moins une fois (doublons possibles)Donnees importantes, tolerance aux doublons
2Exactly onceMessage livre exactement une fois (handshake en 4 etapes)Donnees critiques (facturation, commandes)

Autres fonctionnalites MQTT :

  • Retain : le broker conserve le dernier message d'un topic et l'envoie a tout nouveau subscriber
  • Last Will and Testament (LWT) : message automatiquement publie par le broker si un client se deconnecte anormalement
  • Clean Session : le client peut demander au broker de conserver ou non ses abonnements entre connexions
  • Keep Alive : mecanisme de ping periodique pour detecter les deconnexions

Securite MQTT :

  • Authentification par nom d'utilisateur / mot de passe
  • Chiffrement TLS/SSL pour la confidentialite des echanges
  • Listes de controle d'acces (ACL) pour restreindre l'acces aux topics
  • Port standard : 1883 (non chiffre), 8883 (TLS)

Protocole de transport :
MQTT fonctionne au-dessus de TCP/IP, ce qui garantit une communication fiable avec un overhead minimal. La taille de l'en-tete MQTT est de seulement 2 octets minimum, ce qui le rend ideal pour les reseaux contraints.

2. Installation et test du broker MQTT Mosquitto

Mosquitto est l'implementation open-source de reference du protocole MQTT. J'ai installe et configure le broker sur un environnement Linux, puis teste la communication publish/subscribe en ligne de commande.

Installation et demarrage :

# Installation
sudo apt-get install mosquitto mosquitto-clients

# Demarrage du broker
mosquitto -v

# Abonnement a un topic
mosquitto_sub -h localhost -t "test/topic"

# Publication d'un message
mosquitto_pub -h localhost -t "test/topic" -m "Hello MQTT"

Figure : Demarrage du broker Mosquitto en mode verbose

Figure : Test publish/subscribe avec mosquitto_pub et mosquitto_sub

Configuration avancee du broker :

  • Fichier de configuration : /etc/mosquitto/mosquitto.conf
  • Definition des ports d'ecoute, des parametres d'authentification
  • Configuration des ACL pour controler l'acces aux topics
  • Activation du logging pour le debogage

Les tests ont permis de valider le bon fonctionnement de la chaine de communication : le subscriber recoit instantanement les messages publies par le publisher via le broker, confirmant le modele asynchrone du publish/subscribe.

3. Programmation NodeMCU/ESP8266 avec MQTT

Le NodeMCU est une carte de developpement basee sur le microcontroleur ESP8266, integrant un module WiFi. J'ai programme cette carte pour qu'elle communique via MQTT avec le broker Mosquitto, en utilisant l'Arduino IDE et la bibliotheque ArduinoMqttClient.

Caracteristiques du NodeMCU/ESP8266 :

  • Processeur 32 bits a 80 MHz
  • WiFi 802.11 b/g/n integre
  • GPIO, ADC, PWM, I2C, SPI
  • Programmable via Arduino IDE
  • Ideal pour le prototypage IoT

Fonctionnalites implementees :

  1. Connexion WiFi : le NodeMCU se connecte au reseau WiFi local
  2. Connexion MQTT : etablissement de la connexion avec le broker Mosquitto
  3. Publication de l'etat du bouton : a chaque pression sur le bouton physique, publication de l'etat sur le topic button/state
  4. Publication de la luminosite : lecture du capteur de luminosite (ADC) et publication sur le topic light/state a chaque pression du bouton
  5. Abonnement a des topics : reception de commandes depuis d'autres dispositifs

Extrait de la logique de programmation :

// Connexion WiFi
WiFi.begin(ssid, password);

// Connexion au broker MQTT
mqttClient.connect(broker, port);

// Publication sur topic
mqttClient.beginMessage("button/state");
mqttClient.print(buttonState);
mqttClient.endMessage();

// Lecture luminosite et publication
int luminosity = analogRead(A0);
mqttClient.beginMessage("light/state");
mqttClient.print(luminosity);
mqttClient.endMessage();

Figure : Schema de l'application NodeMCU - publication des etats bouton et luminosite via MQTT

Points techniques importants :

  • La gestion du debounce du bouton est essentielle pour eviter les publications multiples
  • La reconnexion automatique au broker en cas de perte de connexion WiFi ou MQTT garantit la robustesse du systeme
  • L'utilisation de QoS 1 pour les publications critiques assure la livraison des messages

4. Standard oneM2M - Architecture et ressources

oneM2M est un standard international pour les communications M2M et l'IoT. Il definit une architecture de middleware universelle permettant l'interoperabilite entre differents systemes IoT, independamment du reseau sous-jacent.

Architecture oneM2M :

ComposantSigleRole
Common Services EntityCSEFournit les services communs (enregistrement, decouverte, gestion des donnees, securite)
Application EntityAERepresente une application IoT qui interagit avec le CSE
Infrastructure NodeINNoeud serveur hebergeant le CSE principal
Middle NodeMNNoeud intermediaire (passerelle)
Application Service NodeASNNoeud capteur/actionneur

Arbre de ressources oneM2M :

L'architecture oneM2M organise les donnees sous forme d'un arbre de ressources hierarchique :

CSEBase (in-cse)
  |-- ACP (Access Control Policy)
  |-- AE (Application Entity - ex: Mon_AE)
  |     |-- Container (DATA)
  |     |     |-- ContentInstance (valeur capteur)
  |     |     |-- ContentInstance (valeur capteur)
  |     |-- Container (COMMAND)
  |           |-- ContentInstance (commande actionneur)
  |-- AE (Autre application)

Types de ressources principaux :

TypeCode (ty)Description
ACP1Politique de controle d'acces (droits CRUD + Notify + Discovery)
AE2Application Entity - represente une application
Container3Conteneur de donnees (structure hierarchique)
ContentInstance4Instance de contenu (donnee individuelle)
Subscription23Abonnement pour notification automatique

Operations CRUD via API REST :

L'interaction avec le CSE se fait par des requetes HTTP RESTful :

# Creation d'une Application Entity
POST /~/in-cse/in-name
Headers: X-M2M-Origin: '', Content-Type: application/json;ty=2
Body: {"m2m:ae": {"api": "app.iot", "rr": "true", "rn": "Mon_AE"}}

# Creation d'un Container
POST /~/in-cse/in-name/Mon_AE
Headers: X-M2M-Origin: admin:admin, Content-Type: application/json;ty=3
Body: {"m2m:cnt": {"rn": "DATA"}}

# Creation d'un ContentInstance
POST /~/in-cse/in-name/Mon_AE/DATA
Headers: X-M2M-Origin: admin:admin, Content-Type: application/json;ty=4
Body: {"m2m:cin": {"con": "42"}}

# Recuperation du dernier contenu
GET /~/in-cse/in-name/Mon_AE/DATA/la
Headers: X-M2M-Origin: admin:admin, Accept: application/json

Droits d'acces (ACP) :

Les ACP definissent les permissions sur les ressources :

ValeurPermission
1CREATE
2RETRIEVE
4UPDATE
8DELETE
16NOTIFY
32DISCOVERY
63Toutes les permissions

ACME CSE :

Pour les travaux pratiques, nous avons utilise ACME, une implementation open-source du standard oneM2M developpee pour la recherche et l'enseignement. ACME fournit un CSE complet avec interface web, support HTTP/MQTT/CoAP, et une base de donnees locale.

5. Prototypage rapide avec Node-RED

Node-RED est un outil de programmation visuelle base sur Node.js, concu pour le prototypage rapide d'applications IoT. Il permet de creer des flux de donnees en connectant des noeuds graphiques, simplifiant considerablement le developpement et l'integration de systemes IoT.

Principes de Node-RED :

  • Flux (flows) : enchainement de noeuds connectes representant le traitement des donnees
  • Noeuds (nodes) : blocs fonctionnels (entree, traitement, sortie)
  • Messages : objets JSON circulant entre les noeuds (msg.payload, msg.topic)
  • Interface web : editeur visuel accessible via navigateur
  • Extensible : milliers de noeuds communautaires installables via npm

Types de noeuds utilises :

CategorieNoeudsFonction
Entreemqtt in, injectReception de messages MQTT, injection de donnees
Traitementswitch, function, changeLogique conditionnelle, transformation de donnees
Sortiemqtt out, debug, emailPublication MQTT, affichage de debug, envoi email
Dashboardgauge, chart, button, textComposants d'interface utilisateur

Figure : Flux Node-RED integrant reception MQTT, logique de controle et actionneurs

a. Verification de la connectivite MQTT

La premiere etape a consiste a ajouter un noeud mqtt in dans Node-RED, configure pour se connecter au broker Mosquitto et s'abonner au topic insa/luminosity. Le noeud debug a permis de confirmer la bonne reception des valeurs envoyees par le NodeMCU.

b. Gestion des capteurs et actionneurs

Un flux a ete cree pour simuler la logique de controle d'un systeme d'eclairage automatique :

  • Un capteur de luminosite publie des valeurs sur MQTT
  • Un noeud switch evalue la valeur recue :
    • Luminosite > 50 : envoi de la commande LED ON
    • Luminosite <= 50 : envoi de la commande LED OFF
  • Le noeud mqtt out publie la commande sur le topic de l'actionneur

Cette logique illustre le patron de base d'un systeme IoT reactif : capteur → traitement → actionneur.

c. Dashboard de visualisation et controle

Grace au module node-red-dashboard, un tableau de bord interactif a ete cree pour :

  • Visualiser les donnees des capteurs en temps reel (graphiques, jauges)
  • Controler les actionneurs (boutons ON/OFF pour les LEDs)
  • Surveiller l'etat du systeme (indicateurs visuels)

Figure : Dashboard Node-RED - visualisation capteurs et controle LED

d. Notifications email

Le module node-red-node-email a ete integre pour envoyer des alertes automatiques par email lors de :

  • Changement d'etat du switch (ON/OFF)
  • Depassement de seuil de luminosite
  • Detection d'anomalies (valeurs aberrantes)

Ce mecanisme de notification proactive est essentiel dans les systemes IoT pour assurer une reaction rapide aux evenements critiques.

6. Comparaison des protocoles IoT : HTTP vs MQTT vs CoAP

Le choix du protocole de communication est une decision architecturale majeure dans tout projet IoT. Chaque protocole presente des avantages et contraintes specifiques.

CritereHTTPMQTTCoAP
ModeleRequest/ResponsePublish/SubscribeRequest/Response
TransportTCPTCPUDP
OverheadEleve (en-tetes texte)Faible (2 octets min)Tres faible (4 octets)
QoSNon natif3 niveaux (0, 1, 2)Confirmable/Non-confirmable
DecouverteNonNonOui (ressource .well-known/core)
ObserveNonOui (subscribe)Oui (option Observe)
SecuriteTLSTLSDTLS
Usage typiqueAPI web, RESTTelemetrie, notificationObjets tres contraints
ConsommationEleveeModereeFaible
LatenceModereeFaibleTres faible

Quand utiliser quel protocole :

  • HTTP : interactions ponctuelles, API REST, integration avec le web existant, oneM2M
  • MQTT : telemetrie continue, notifications temps reel, communication entre de nombreux devices
  • CoAP : objets a tres faibles ressources (capteurs sur batterie), reseaux 6LoWPAN, communication directe device-to-device

7. API RESTful pour l'IoT

L'architecture REST (Representational State Transfer) est au coeur de l'IoT moderne, notamment dans le standard oneM2M. Les principes REST appliques a l'IoT :

Principes REST :

  • Ressources identifiees par URI : chaque capteur, actionneur ou donnee est une ressource adressable
  • Operations CRUD via verbes HTTP :
    • GET : lire une ressource (ex: valeur capteur)
    • POST : creer une ressource (ex: nouvelle ContentInstance)
    • PUT : mettre a jour une ressource
    • DELETE : supprimer une ressource
  • Representations : JSON ou XML pour encoder les donnees
  • Sans etat (stateless) : chaque requete contient toute l'information necessaire

Application au standard oneM2M :
Dans oneM2M, l'arbre de ressources est accessible via des URL RESTful. Les en-tetes HTTP specifiques (X-M2M-Origin, Content-Type avec type de ressource) permettent au CSE d'identifier l'appelant et le type de creation demande.

8. Pile protocolaire IoT

L'IoT utilise une pile protocolaire adaptee aux contraintes des objets connectes :

CoucheProtocoles standardProtocoles IoT
ApplicationHTTP, FTPMQTT, CoAP, AMQP, oneM2M
TransportTCP, UDPTCP (MQTT), UDP (CoAP)
ReseauIPv4, IPv66LoWPAN, RPL
LiaisonEthernet, WiFiIEEE 802.15.4, BLE, LoRa, Sigfox
PhysiqueCables, ondesRF sub-GHz, 2.4 GHz

Specificites de la pile IoT :

  • 6LoWPAN : adaptation d'IPv6 pour reseaux de capteurs a faible puissance (compression d'en-tetes)
  • RPL : protocole de routage pour reseaux de capteurs (arbre DODAG)
  • IEEE 802.15.4 : couche liaison pour reseaux personnels sans fil a faible consommation
  • Les middlewares comme oneM2M se situent au niveau applicatif et sont independants du reseau sous-jacent

9. Patrons de communication M2M

Les communications Machine-to-Machine suivent plusieurs patrons architecturaux :

1. Publish/Subscribe (MQTT) :

  • Communication asynchrone via broker
  • Decoupage spatial (publisher et subscriber ne se connaissent pas)
  • Decoupage temporel (pas besoin d'etre connecte simultanement grace au retain)
  • Ideal pour : telemetrie, notification d'evenements, distribution de donnees a N recepteurs

2. Request/Response (HTTP, CoAP) :

  • Communication synchrone client/serveur
  • Le client initie la requete, le serveur repond
  • Ideal pour : lecture ponctuelle, commande d'actionneur, API REST

3. Observer (CoAP Observe, oneM2M Subscription) :

  • Le client s'enregistre pour etre notifie des changements
  • Le serveur envoie des notifications a chaque modification
  • Ideal pour : surveillance continue, tableaux de bord temps reel

4. Pipeline / Data Flow (Node-RED) :

  • Les donnees traversent une chaine de traitements
  • Chaque noeud transforme ou filtre les donnees
  • Ideal pour : ETL IoT, traitement de flux, prototypage

10. Prototypage rapide avec Node-RED - Approfondissement

Node-RED se revele un outil extremement puissant pour le prototypage IoT grace a plusieurs caracteristiques avancees :

Flux JSON exportable :
Les flux Node-RED sont serialises en JSON, permettant le versionnement (Git), le partage et le deploiement automatise. Lors du TP, nous avons exporte notre configuration dans le fichier Boukouiss_Chanfreau_Node-Red.json.

Noeuds personnalises (function) :
Le noeud function permet d'ecrire du code JavaScript pour des traitements complexes :

// Exemple : transformation de donnees capteur
var luminosity = msg.payload;
if (luminosity > 50) {
    msg.payload = "ON";
    msg.topic = "led/command";
} else {
    msg.payload = "OFF";
    msg.topic = "led/command";
}
return msg;

Integration multi-protocole :
Node-RED supporte nativement MQTT, HTTP, WebSocket, TCP, UDP et peut etre etendu pour supporter CoAP, oneM2M, bases de donnees (InfluxDB, MongoDB), services cloud (AWS IoT, Azure IoT Hub).

Avantages pour le prototypage IoT :

  • Developpement visuel accelerant la mise en oeuvre
  • Test et debogage en temps reel (noeud debug)
  • Dashboard integre pour la visualisation
  • Modification a chaud sans redemarrage
  • Grande communaute et ecosysteme de noeuds

PART D - Analyse Reflexive et Perspectives

Competences acquises

Maitrise des protocoles IoT :
Comprehension approfondie de MQTT (publish/subscribe, QoS, broker), des API RESTful pour oneM2M, et des principes de CoAP. Capacite a choisir le protocole adapte selon les contraintes du projet.

Programmation embarquee IoT :
Competence pour programmer un ESP8266/NodeMCU et l'integrer dans une architecture MQTT : connexion WiFi, publication/abonnement, gestion des capteurs et actionneurs.

Architecture middleware M2M :
Comprehension du standard oneM2M, de l'arbre de ressources, des ACP, et de l'interaction avec un CSE via API REST. Capacite a deployer et configurer une infrastructure oneM2M.

Prototypage rapide :
Maitrise de Node-RED pour concevoir des flux IoT complets, integrant capture de donnees, logique de traitement, dashboard de visualisation et systemes de notification.

Integration systeme :
Capacite a combiner toutes les briques (capteurs, broker MQTT, CSE oneM2M, Node-RED, dashboard) dans une architecture IoT coherente et fonctionnelle.

Points cles a retenir

1. MQTT est le protocole de reference pour l'IoT :
Sa legerete, son modele publish/subscribe et ses niveaux de QoS en font le choix privilegie pour la telemetrie et la communication entre objets connectes.

2. oneM2M standardise l'interoperabilite M2M :
Ce standard international fournit une couche d'abstraction au-dessus des protocoles de transport, permettant l'interoperabilite entre systemes heterogenes.

3. Node-RED accelere considerablement le prototypage :
La programmation visuelle permet de passer rapidement de l'idee au prototype fonctionnel, ce qui est crucial dans les projets IoT ou l'iteration rapide est essentielle.

4. Le choix du protocole depend du cas d'usage :
HTTP pour les API web, MQTT pour la telemetrie temps reel, CoAP pour les objets tres contraints. Il n'existe pas de solution universelle.

5. La securite IoT est un enjeu majeur :
L'authentification, le chiffrement (TLS/DTLS) et le controle d'acces doivent etre integres des la conception de l'architecture.

Auto-evaluation

Ce cours a constitue ma premiere experience approfondie avec les protocoles IoT comme MQTT et le standard oneM2M. J'ai trouve ces technologies relativement accessibles grace aux nombreuses bibliotheques existantes et a la documentation disponible. La progression pedagogique des TP (de la ligne de commande Mosquitto a l'application Node-RED complete) a permis une montee en competence progressive et solide.

La mise en oeuvre pratique m'a permis de comprendre l'utilite concrete de ces concepts. J'ai par la suite reutilise certains de ces outils dans notre projet innovant pour mettre en place une communication efficace entre dispositifs, ce qui confirme la pertinence de cet enseignement.

La richesse du standard oneM2M m'a impressionne : la structure hierarchique des ressources, le systeme de droits d'acces et les mecanismes de notification permettent de construire des architectures IoT robustes et interoperables. Cependant, cette richesse implique une courbe d'apprentissage non negligeable.

Mon avis

Ce cours a ete l'un de mes favoris du semestre car il combine parfaitement les aspects materiel et logiciel. En tant qu'aspirant ingenieur en systemes embarques, cette association entre programmation de microcontroleurs et architectures logicielles middleware correspond exactement a mon profil de competences vise.

Points forts :

  • Progression pedagogique exemplaire : MQTT en CLI, puis ESP8266, puis oneM2M, puis Node-RED
  • Equilibre theorie/pratique avec des TP concrets et motivants
  • Outils open-source accessibles pour continuer a pratiquer
  • Lien direct avec les besoins de l'industrie IoT

Points a ameliorer :

  • Plus de temps sur oneM2M (complexite du standard)
  • Introduction de CoAP en pratique (pas seulement en theorie)
  • Aspects securite plus approfondis (TLS, certificats)
  • Scalabilite des architectures (clusters de brokers, load balancing)

La demarche progressive des labs a rendu l'apprentissage a la fois agreable et tres formateur. Partir de la communication MQTT basique en ligne de commande, evoluer vers la programmation Arduino avec la bibliotheque MQTT, puis integrer le tout avec Node-RED offre une vision complete de la chaine IoT. C'est exactement le type de cours qui prepare a des projets professionnels concrets.

Applications professionnelles

Ingenieur IoT :

  • Concevoir des architectures de communication pour objets connectes
  • Deployer et administrer des brokers MQTT a l'echelle
  • Integrer des capteurs et actionneurs dans des plateformes IoT

Ingenieur systemes embarques :

  • Programmer des microcontroleurs communicants (ESP8266, ESP32, STM32)
  • Implementer des protocoles IoT sur des systemes contraints
  • Optimiser la consommation energetique des communications

Architecte solutions M2M :

  • Concevoir des plateformes interoperables basees sur oneM2M
  • Definir les architectures middleware pour systemes industriels
  • Assurer la scalabilite et la securite des infrastructures

Liens avec les autres cours :


Documents de Cours

Planning MOOC oneM2M oneM2M MOOC Planning

Planning et contenu du MOOC oneM2M suivi en autonomie : introduction au standard, architecture, types de ressources. Planning and content of the self-paced oneM2M MOOC: introduction to the standard, architecture, resource types.

Telecharger Download


Rapports et Projets

Rapport Middleware for IoT - BE Middleware for IoT Report - Design Project

Rapport complet du bureau d'etudes : architecture IoT deployee, integration MQTT, oneM2M et Node-RED, resultats experimentaux. Complete design project report: deployed IoT architecture, MQTT integration, oneM2M and Node-RED, experimental results.

Telecharger le rapport BE Download the design project report

Rapport TP1-2 : MQTT et NodeMCU Lab 1-2 Report: MQTT and NodeMCU

Rapport des travaux pratiques 1 et 2 : installation Mosquitto, communication publish/subscribe, programmation ESP8266. Lab sessions 1 and 2 report: Mosquitto installation, publish/subscribe communication, ESP8266 programming.

Telecharger le rapport TP1-2 Download the Lab 1-2 report

Ouvrir le sujet de TP Open the lab subject

Cours suivi en 2024-2025 a l'INSA Toulouse, Departement Genie Electrique et Informatique, specialite ISS (Innovative Smart Systems).

Middleware for IoT / M2M - Semester 9

Academic year: 2024-2025
Instructor: T. Monteil (LAAS-CNRS)
ECTS: 2.5
Category: IoT, Communication Protocols, Middleware

Related courses:


PART A - General Presentation

Overview

The "Middleware for IoT / M2M" course covers middleware software architectures and communication protocols dedicated to the Internet of Things (IoT) and Machine-to-Machine (M2M) communications. It covers the entire chain, from lightweight messaging protocols such as MQTT to resource management standards like oneM2M, including rapid prototyping of IoT applications with Node-RED.

The objective is to train engineers capable of designing, deploying and integrating complete IoT systems, with mastery of communication protocols adapted to connected object constraints (limited bandwidth, energy consumption, reliability).

Learning objectives:

  • Understand the main Internet of Things standards (MQTT, oneM2M, CoAP)
  • Deploy and configure IoT architectures with MQTT broker and oneM2M CSE
  • Program microcontrollers (NodeMCU/ESP8266) to communicate via MQTT
  • Design IoT applications with Node-RED (rapid prototyping)
  • Compare and choose protocols suited to IoT use cases (HTTP vs MQTT vs CoAP)
  • Integrate sensors, actuators and dashboards into a complete IoT architecture
  • Analyze the security, scalability and interoperability challenges of M2M systems

Position in the curriculum

This module builds on previously acquired foundations:

  • Networking (S5-S8): OSI model, TCP/IP, HTTP, sockets
  • Microcontrollers (S5-S7): embedded programming, Arduino
  • Operating Systems: Linux, Python scripts

It prepares for and connects to:

  • Cloud and Edge Computing (S9): deployment of distributed architectures
  • Security for Connected Objects (S9): securing IoT communications
  • Wireless Sensors Networks (S9): physical and link layers of sensors
  • Innovative Project (S9): integration of IoT protocols in a real project

PART B - Experience and Context

Organization and resources

The module combined theoretical lectures and progressive hands-on lab work:

Lectures:

  • IoT architecture and protocol stack
  • MQTT protocol: principles, QoS, topics, retain, last will
  • oneM2M standard: architecture, resources, CSE, AE
  • oneM2M MOOC (self-paced training)
  • Comparison of IoT protocols (HTTP, MQTT, CoAP, AMQP)
  • M2M communication patterns (publish/subscribe, request/response)

Lab sessions:

  • Lab 1-2: Installation and configuration of the Mosquitto MQTT broker, publish/subscribe communication, NodeMCU/ESP8266 programming with ArduinoMqttClient
  • Lab 3: oneM2M standard with ACME CSE, resource creation (AE, Container, ContentInstance) via RESTful API, Python script simple_om2m.py
  • Lab 4: Rapid prototyping with Node-RED, MQTT integration, dashboard, sensor and actuator management, email notifications

Design Project (BE):

  • BE M2M project: implementation of a complete M2M architecture integrating MQTT, oneM2M and Node-RED

Tools used:

  • Mosquitto: open-source MQTT broker
  • Arduino IDE: ESP8266/NodeMCU programming
  • Node-RED: visual prototyping tool
  • ACME oneM2M CSE: open-source implementation of the oneM2M standard
  • Python: scripts for interacting with oneM2M APIs
  • cURL / Postman: RESTful API testing

Resources:

  • oneM2M MOOC (self-paced planning and content)
  • Detailed lab subjects (MQTT, oneM2M, Node-RED)
  • Mosquitto, ACME CSE, Node-RED documentation
  • BE M2M subject and presentation

Learning methodology

Phase 1: Understanding the fundamentals:
Study the IoT architecture, communication models (publish/subscribe vs request/response) and the specific constraints of connected objects.

Phase 2: Mastering MQTT:
Install a broker, test communication via command line, then program a microcontroller to publish and subscribe to topics.

Phase 3: Discovering oneM2M:
Understand the resource tree, deploy a CSE, create Application Entities and containers via REST API.

Phase 4: Rapid prototyping:
Use Node-RED to integrate all elements (sensors, MQTT, dashboard, notifications) into a functional system.

Phase 5: Integration and project:
Combine all building blocks in the BE M2M to build a complete IoT architecture.

My role and responsibilities

During this module, I was responsible for:

  • Installing and configuring the Mosquitto MQTT broker on Linux
  • Programming a NodeMCU/ESP8266 for sensor data publishing (luminosity, button state) via MQTT
  • Deploying and interacting with a oneM2M CSE (ACME) via HTTP RESTful requests in Python
  • Designing Node-RED flows integrating MQTT reception, control logic, dashboard and notifications
  • Writing technical reports detailing the deployed architectures and results obtained

Challenges encountered

Broker network configuration:
Setting up Mosquitto with the correct listening and authentication parameters required several iterations to work properly with the NodeMCU.

ESP8266 programming:
Integrating the ArduinoMqttClient library with WiFi management on the NodeMCU required a solid understanding of the connection lifecycle.

oneM2M standard:
The richness of the oneM2M standard (numerous resource types, ACP access rights, hierarchical structure) is intimidating at first. The MOOC documentation was essential to make progress.

Node-RED integration:
Coordinating between MQTT nodes, JavaScript functions and the dashboard required fine-tuning time to achieve a responsive and reliable system.


PART C - Detailed Technical Aspects

1. MQTT Protocol - Architecture and principles

MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol designed for constrained environments (limited bandwidth, reduced resources). It relies on the publish/subscribe model with a central intermediary called a broker.

MQTT Architecture:

ComponentRoleDescription
PublisherSenderPublishes messages on topics
SubscriberReceiverSubscribes to topics to receive messages
BrokerIntermediaryManages message distribution between publishers and subscribers
TopicChannelHierarchical string identifying the message subject (e.g.: sensor/temperature)
MessageDataContent published on a topic (payload)

Publish/subscribe principles:

  • Publishers and subscribers are decoupled: they do not know each other directly
  • The broker handles message routing according to subscriptions
  • A publisher can publish on multiple topics
  • A subscriber can subscribe to multiple topics with wildcards (+ for one level, # for all sub-levels)

Detailed operation:

  1. The subscriber subscribes to a topic on the broker (e.g.: insa/luminosity)
  2. The publisher publishes a message on that topic
  3. The broker forwards the message to all subscribers subscribed to that topic
  4. The hierarchical topic structure allows flexible organization (e.g.: building1/floor2/room3/temperature)

Figure: MQTT Architecture - Publish/subscribe model with central broker

QoS Levels (Quality of Service):

MQTT offers three quality of service levels for message delivery:

QoSNameGuaranteeUsage
0At most onceNo guarantee, "fire and forget"Non-critical data, frequent telemetry
1At least onceMessage delivered at least once (duplicates possible)Important data, duplicate tolerance
2Exactly onceMessage delivered exactly once (4-step handshake)Critical data (billing, commands)

Other MQTT features:

  • Retain: the broker keeps the last message of a topic and sends it to any new subscriber
  • Last Will and Testament (LWT): message automatically published by the broker if a client disconnects abnormally
  • Clean Session: the client can ask the broker to retain or discard its subscriptions between connections
  • Keep Alive: periodic ping mechanism to detect disconnections

MQTT Security:

  • Username/password authentication
  • TLS/SSL encryption for exchange confidentiality
  • Access Control Lists (ACL) to restrict topic access
  • Standard port: 1883 (unencrypted), 8883 (TLS)

Transport protocol:
MQTT operates on top of TCP/IP, which ensures reliable communication with minimal overhead. The MQTT header size is only 2 bytes minimum, making it ideal for constrained networks.

2. Installing and testing the Mosquitto MQTT broker

Mosquitto is the reference open-source implementation of the MQTT protocol. I installed and configured the broker on a Linux environment, then tested publish/subscribe communication via the command line.

Installation and startup:

# Installation
sudo apt-get install mosquitto mosquitto-clients

# Demarrage du broker
mosquitto -v

# Abonnement a un topic
mosquitto_sub -h localhost -t "test/topic"

# Publication d'un message
mosquitto_pub -h localhost -t "test/topic" -m "Hello MQTT"

Figure: Starting the Mosquitto broker in verbose mode

Figure: Publish/subscribe test with mosquitto_pub and mosquitto_sub

Advanced broker configuration:

  • Configuration file: /etc/mosquitto/mosquitto.conf
  • Definition of listening ports and authentication parameters
  • ACL configuration to control topic access
  • Logging activation for debugging

The tests validated the proper functioning of the communication chain: the subscriber instantly receives messages published by the publisher via the broker, confirming the asynchronous publish/subscribe model.

3. NodeMCU/ESP8266 programming with MQTT

The NodeMCU is a development board based on the ESP8266 microcontroller, integrating a WiFi module. I programmed this board to communicate via MQTT with the Mosquitto broker, using the Arduino IDE and the ArduinoMqttClient library.

NodeMCU/ESP8266 characteristics:

  • 32-bit processor at 80 MHz
  • Built-in WiFi 802.11 b/g/n
  • GPIO, ADC, PWM, I2C, SPI
  • Programmable via Arduino IDE
  • Ideal for IoT prototyping

Implemented features:

  1. WiFi connection: the NodeMCU connects to the local WiFi network
  2. MQTT connection: establishing connection with the Mosquitto broker
  3. Button state publishing: on each physical button press, publishing the state on the button/state topic
  4. Luminosity publishing: reading the luminosity sensor (ADC) and publishing on the light/state topic on each button press
  5. Topic subscription: receiving commands from other devices

Programming logic excerpt:

// Connexion WiFi
WiFi.begin(ssid, password);

// Connexion au broker MQTT
mqttClient.connect(broker, port);

// Publication sur topic
mqttClient.beginMessage("button/state");
mqttClient.print(buttonState);
mqttClient.endMessage();

// Lecture luminosite et publication
int luminosity = analogRead(A0);
mqttClient.beginMessage("light/state");
mqttClient.print(luminosity);
mqttClient.endMessage();

Figure: NodeMCU application diagram - publishing button and luminosity states via MQTT

Important technical points:

  • Button debounce management is essential to avoid multiple publications
  • Automatic broker reconnection in case of WiFi or MQTT connection loss ensures system robustness
  • Using QoS 1 for critical publications ensures message delivery

4. oneM2M Standard - Architecture and resources

oneM2M is an international standard for M2M communications and IoT. It defines a universal middleware architecture enabling interoperability between different IoT systems, regardless of the underlying network.

oneM2M Architecture:

ComponentAcronymRole
Common Services EntityCSEProvides common services (registration, discovery, data management, security)
Application EntityAERepresents an IoT application that interacts with the CSE
Infrastructure NodeINServer node hosting the main CSE
Middle NodeMNIntermediate node (gateway)
Application Service NodeASNSensor/actuator node

oneM2M resource tree:

The oneM2M architecture organizes data as a hierarchical resource tree:

CSEBase (in-cse)
  |-- ACP (Access Control Policy)
  |-- AE (Application Entity - ex: Mon_AE)
  |     |-- Container (DATA)
  |     |     |-- ContentInstance (valeur capteur)
  |     |     |-- ContentInstance (valeur capteur)
  |     |-- Container (COMMAND)
  |           |-- ContentInstance (commande actionneur)
  |-- AE (Autre application)

Main resource types:

TypeCode (ty)Description
ACP1Access Control Policy (CRUD + Notify + Discovery rights)
AE2Application Entity - represents an application
Container3Data container (hierarchical structure)
ContentInstance4Content instance (individual data point)
Subscription23Subscription for automatic notification

CRUD operations via REST API:

Interaction with the CSE is done through HTTP RESTful requests:

# Creation d'une Application Entity
POST /~/in-cse/in-name
Headers: X-M2M-Origin: '', Content-Type: application/json;ty=2
Body: {"m2m:ae": {"api": "app.iot", "rr": "true", "rn": "Mon_AE"}}

# Creation d'un Container
POST /~/in-cse/in-name/Mon_AE
Headers: X-M2M-Origin: admin:admin, Content-Type: application/json;ty=3
Body: {"m2m:cnt": {"rn": "DATA"}}

# Creation d'un ContentInstance
POST /~/in-cse/in-name/Mon_AE/DATA
Headers: X-M2M-Origin: admin:admin, Content-Type: application/json;ty=4
Body: {"m2m:cin": {"con": "42"}}

# Recuperation du dernier contenu
GET /~/in-cse/in-name/Mon_AE/DATA/la
Headers: X-M2M-Origin: admin:admin, Accept: application/json

Access rights (ACP):

ACPs define permissions on resources:

ValuePermission
1CREATE
2RETRIEVE
4UPDATE
8DELETE
16NOTIFY
32DISCOVERY
63All permissions

ACME CSE:

For the lab sessions, we used ACME, an open-source implementation of the oneM2M standard developed for research and education. ACME provides a complete CSE with a web interface, HTTP/MQTT/CoAP support, and a local database.

5. Rapid prototyping with Node-RED

Node-RED is a visual programming tool based on Node.js, designed for rapid prototyping of IoT applications. It allows creating data flows by connecting graphical nodes, considerably simplifying the development and integration of IoT systems.

Node-RED principles:

  • Flows: sequence of connected nodes representing data processing
  • Nodes: functional blocks (input, processing, output)
  • Messages: JSON objects flowing between nodes (msg.payload, msg.topic)
  • Web interface: visual editor accessible via browser
  • Extensible: thousands of community nodes installable via npm

Types of nodes used:

CategoryNodesFunction
Inputmqtt in, injectMQTT message reception, data injection
Processingswitch, function, changeConditional logic, data transformation
Outputmqtt out, debug, emailMQTT publishing, debug display, email sending
Dashboardgauge, chart, button, textUser interface components

Figure: Node-RED flow integrating MQTT reception, control logic and actuators

a. Verifying MQTT connectivity

The first step consisted of adding an mqtt in node in Node-RED, configured to connect to the Mosquitto broker and subscribe to the insa/luminosity topic. The debug node confirmed the proper reception of values sent by the NodeMCU.

b. Sensor and actuator management

A flow was created to simulate the control logic of an automatic lighting system:

  • A luminosity sensor publishes values on MQTT
  • A switch node evaluates the received value:
    • Luminosity > 50: send LED ON command
    • Luminosity <= 50: send LED OFF command
  • The mqtt out node publishes the command on the actuator topic

This logic illustrates the basic pattern of a reactive IoT system: sensor → processing → actuator.

c. Visualization and control dashboard

Using the node-red-dashboard module, an interactive dashboard was created to:

  • Visualize sensor data in real time (charts, gauges)
  • Control actuators (ON/OFF buttons for LEDs)
  • Monitor system status (visual indicators)

Figure: Node-RED Dashboard - sensor visualization and LED control

d. Email notifications

The node-red-node-email module was integrated to send automatic email alerts upon:

  • Switch state change (ON/OFF)
  • Luminosity threshold exceeded
  • Anomaly detection (outlier values)

This proactive notification mechanism is essential in IoT systems to ensure rapid response to critical events.

6. Comparison of IoT protocols: HTTP vs MQTT vs CoAP

The choice of communication protocol is a major architectural decision in any IoT project. Each protocol has specific advantages and constraints.

CriterionHTTPMQTTCoAP
ModelRequest/ResponsePublish/SubscribeRequest/Response
TransportTCPTCPUDP
OverheadHigh (text headers)Low (2 bytes min)Very low (4 bytes)
QoSNot native3 levels (0, 1, 2)Confirmable/Non-confirmable
DiscoveryNoNoYes (.well-known/core resource)
ObserveNoYes (subscribe)Yes (Observe option)
SecurityTLSTLSDTLS
Typical useWeb API, RESTTelemetry, notificationHighly constrained objects
ConsumptionHighModerateLow
LatencyModerateLowVery low

When to use which protocol:

  • HTTP: one-time interactions, REST APIs, integration with the existing web, oneM2M
  • MQTT: continuous telemetry, real-time notifications, communication between many devices
  • CoAP: very low-resource objects (battery-powered sensors), 6LoWPAN networks, direct device-to-device communication

7. RESTful APIs for IoT

The REST (Representational State Transfer) architecture is at the heart of modern IoT, particularly in the oneM2M standard. REST principles applied to IoT:

REST principles:

  • Resources identified by URI: each sensor, actuator or data point is an addressable resource
  • CRUD operations via HTTP verbs:
    • GET: read a resource (e.g.: sensor value)
    • POST: create a resource (e.g.: new ContentInstance)
    • PUT: update a resource
    • DELETE: delete a resource
  • Representations: JSON or XML for encoding data
  • Stateless: each request contains all necessary information

Application to the oneM2M standard:
In oneM2M, the resource tree is accessible via RESTful URLs. Specific HTTP headers (X-M2M-Origin, Content-Type with resource type) allow the CSE to identify the caller and the type of creation requested.

8. IoT protocol stack

IoT uses a protocol stack adapted to the constraints of connected objects:

LayerStandard protocolsIoT protocols
ApplicationHTTP, FTPMQTT, CoAP, AMQP, oneM2M
TransportTCP, UDPTCP (MQTT), UDP (CoAP)
NetworkIPv4, IPv66LoWPAN, RPL
Data LinkEthernet, WiFiIEEE 802.15.4, BLE, LoRa, Sigfox
PhysicalCables, wavesRF sub-GHz, 2.4 GHz

IoT stack specifics:

  • 6LoWPAN: IPv6 adaptation for low-power sensor networks (header compression)
  • RPL: routing protocol for sensor networks (DODAG tree)
  • IEEE 802.15.4: data link layer for low-power wireless personal area networks
  • Middleware such as oneM2M operates at the application level and is independent of the underlying network

9. M2M communication patterns

Machine-to-Machine communications follow several architectural patterns:

1. Publish/Subscribe (MQTT):

  • Asynchronous communication via broker
  • Spatial decoupling (publisher and subscriber do not know each other)
  • Temporal decoupling (no need to be connected simultaneously thanks to retain)
  • Ideal for: telemetry, event notification, data distribution to N receivers

2. Request/Response (HTTP, CoAP):

  • Synchronous client/server communication
  • The client initiates the request, the server responds
  • Ideal for: one-time reading, actuator command, REST API

3. Observer (CoAP Observe, oneM2M Subscription):

  • The client registers to be notified of changes
  • The server sends notifications on each modification
  • Ideal for: continuous monitoring, real-time dashboards

4. Pipeline / Data Flow (Node-RED):

  • Data passes through a processing chain
  • Each node transforms or filters the data
  • Ideal for: IoT ETL, stream processing, prototyping

10. Rapid prototyping with Node-RED - In depth

Node-RED proves to be an extremely powerful tool for IoT prototyping thanks to several advanced features:

Exportable JSON flows:
Node-RED flows are serialized in JSON, enabling versioning (Git), sharing and automated deployment. During the lab, we exported our configuration to the file Boukouiss_Chanfreau_Node-Red.json.

Custom nodes (function):
The function node allows writing JavaScript code for complex processing:

// Exemple : transformation de donnees capteur
var luminosity = msg.payload;
if (luminosity > 50) {
    msg.payload = "ON";
    msg.topic = "led/command";
} else {
    msg.payload = "OFF";
    msg.topic = "led/command";
}
return msg;

Multi-protocol integration:
Node-RED natively supports MQTT, HTTP, WebSocket, TCP, UDP and can be extended to support CoAP, oneM2M, databases (InfluxDB, MongoDB), cloud services (AWS IoT, Azure IoT Hub).

Advantages for IoT prototyping:

  • Visual development accelerating implementation
  • Real-time testing and debugging (debug node)
  • Built-in dashboard for visualization
  • Hot modification without restart
  • Large community and node ecosystem

PART D - Reflective Analysis and Perspectives

Skills acquired

Mastery of IoT protocols:
In-depth understanding of MQTT (publish/subscribe, QoS, broker), RESTful APIs for oneM2M, and CoAP principles. Ability to choose the appropriate protocol based on project constraints.

Embedded IoT programming:
Competence to program an ESP8266/NodeMCU and integrate it into an MQTT architecture: WiFi connection, publish/subscribe, sensor and actuator management.

M2M middleware architecture:
Understanding of the oneM2M standard, resource tree, ACPs, and interaction with a CSE via REST API. Ability to deploy and configure a oneM2M infrastructure.

Rapid prototyping:
Mastery of Node-RED for designing complete IoT flows, integrating data capture, processing logic, visualization dashboard and notification systems.

System integration:
Ability to combine all building blocks (sensors, MQTT broker, oneM2M CSE, Node-RED, dashboard) into a coherent and functional IoT architecture.

Key takeaways

1. MQTT is the reference protocol for IoT:
Its lightness, publish/subscribe model and QoS levels make it the preferred choice for telemetry and communication between connected objects.

2. oneM2M standardizes M2M interoperability:
This international standard provides an abstraction layer above transport protocols, enabling interoperability between heterogeneous systems.

3. Node-RED considerably accelerates prototyping:
Visual programming allows quickly moving from idea to functional prototype, which is crucial in IoT projects where rapid iteration is essential.

4. Protocol choice depends on the use case:
HTTP for web APIs, MQTT for real-time telemetry, CoAP for highly constrained objects. There is no universal solution.

5. IoT security is a major challenge:
Authentication, encryption (TLS/DTLS) and access control must be integrated from the architecture design stage.

Self-assessment

This course was my first in-depth experience with IoT protocols such as MQTT and the oneM2M standard. I found these technologies relatively accessible thanks to the many existing libraries and available documentation. The pedagogical progression of the labs (from Mosquitto command line to the complete Node-RED application) enabled progressive and solid skill building.

The hands-on implementation allowed me to understand the practical usefulness of these concepts. I subsequently reused some of these tools in our innovative project to set up efficient communication between devices, confirming the relevance of this teaching.

The richness of the oneM2M standard impressed me: the hierarchical resource structure, access rights system and notification mechanisms allow building robust and interoperable IoT architectures. However, this richness implies a significant learning curve.

My opinion

This course was one of my favorites of the semester because it perfectly combines hardware and software aspects. As an aspiring embedded systems engineer, this combination of microcontroller programming and middleware software architectures corresponds exactly to my targeted skill profile.

Strengths:

  • Exemplary pedagogical progression: MQTT in CLI, then ESP8266, then oneM2M, then Node-RED
  • Theory/practice balance with concrete and motivating lab sessions
  • Accessible open-source tools to continue practicing
  • Direct connection to IoT industry needs

Areas for improvement:

  • More time on oneM2M (standard complexity)
  • Introduction of CoAP in practice (not only in theory)
  • More in-depth security aspects (TLS, certificates)
  • Architecture scalability (broker clusters, load balancing)

The progressive approach of the labs made learning both enjoyable and highly educational. Starting from basic MQTT communication via command line, evolving to Arduino programming with the MQTT library, then integrating everything with Node-RED provides a complete view of the IoT chain. This is exactly the type of course that prepares for concrete professional projects.

Professional applications

IoT Engineer:

  • Design communication architectures for connected objects
  • Deploy and administer MQTT brokers at scale
  • Integrate sensors and actuators into IoT platforms

Embedded Systems Engineer:

  • Program communicating microcontrollers (ESP8266, ESP32, STM32)
  • Implement IoT protocols on constrained systems
  • Optimize communication energy consumption

M2M Solutions Architect:

  • Design interoperable platforms based on oneM2M
  • Define middleware architectures for industrial systems
  • Ensure infrastructure scalability and security

Links with other courses:


Course Documents

Planning MOOC oneM2M oneM2M MOOC Planning

Planning et contenu du MOOC oneM2M suivi en autonomie : introduction au standard, architecture, types de ressources. Planning and content of the self-paced oneM2M MOOC: introduction to the standard, architecture, resource types.

Telecharger Download


Reports and Projects

Rapport Middleware for IoT - BE Middleware for IoT Report - Design Project

Rapport complet du bureau d'etudes : architecture IoT deployee, integration MQTT, oneM2M et Node-RED, resultats experimentaux. Complete design project report: deployed IoT architecture, MQTT integration, oneM2M and Node-RED, experimental results.

Telecharger le rapport BE Download the design project report

Rapport TP1-2 : MQTT et NodeMCU Lab 1-2 Report: MQTT and NodeMCU

Rapport des travaux pratiques 1 et 2 : installation Mosquitto, communication publish/subscribe, programmation ESP8266. Lab sessions 1 and 2 report: Mosquitto installation, publish/subscribe communication, ESP8266 programming.

Telecharger le rapport TP1-2 Download the Lab 1-2 report

Ouvrir le sujet de TP Open the lab subject

Course taken in 2024-2025 at INSA Toulouse, Department of Electrical and Computer Engineering, ISS (Innovative Smart Systems) specialization.