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 :
- Security for Connected Objects - S9 - Securisation IoT
- Cloud & Edge Computing - S9 - Architectures IoT
- Wireless Sensors Networks - S9 - Reseaux de capteurs
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 :
| Composant | Role | Description |
|---|---|---|
| Publisher | Emetteur | Publie des messages sur des topics |
| Subscriber | Recepteur | S'abonne a des topics pour recevoir les messages |
| Broker | Intermediaire | Gere la distribution des messages entre publishers et subscribers |
| Topic | Canal | Chaine hierarchique identifiant le sujet du message (ex: sensor/temperature) |
| Message | Donnee | Contenu 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 :
- Le subscriber s'abonne a un topic aupres du broker (ex:
insa/luminosity) - Le publisher publie un message sur ce topic
- Le broker transmet le message a tous les subscribers abonnes a ce topic
- 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 :
| QoS | Nom | Garantie | Usage |
|---|---|---|---|
| 0 | At most once | Aucune garantie, "fire and forget" | Donnees non critiques, telemetrie frequente |
| 1 | At least once | Message livre au moins une fois (doublons possibles) | Donnees importantes, tolerance aux doublons |
| 2 | Exactly once | Message 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 :
- Connexion WiFi : le NodeMCU se connecte au reseau WiFi local
- Connexion MQTT : etablissement de la connexion avec le broker Mosquitto
- Publication de l'etat du bouton : a chaque pression sur le bouton physique, publication de l'etat sur le topic
button/state - Publication de la luminosite : lecture du capteur de luminosite (ADC) et publication sur le topic
light/statea chaque pression du bouton - 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 :
| Composant | Sigle | Role |
|---|---|---|
| Common Services Entity | CSE | Fournit les services communs (enregistrement, decouverte, gestion des donnees, securite) |
| Application Entity | AE | Represente une application IoT qui interagit avec le CSE |
| Infrastructure Node | IN | Noeud serveur hebergeant le CSE principal |
| Middle Node | MN | Noeud intermediaire (passerelle) |
| Application Service Node | ASN | Noeud 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 :
| Type | Code (ty) | Description |
|---|---|---|
| ACP | 1 | Politique de controle d'acces (droits CRUD + Notify + Discovery) |
| AE | 2 | Application Entity - represente une application |
| Container | 3 | Conteneur de donnees (structure hierarchique) |
| ContentInstance | 4 | Instance de contenu (donnee individuelle) |
| Subscription | 23 | Abonnement 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 :
| Valeur | Permission |
|---|---|
| 1 | CREATE |
| 2 | RETRIEVE |
| 4 | UPDATE |
| 8 | DELETE |
| 16 | NOTIFY |
| 32 | DISCOVERY |
| 63 | Toutes 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 :
| Categorie | Noeuds | Fonction |
|---|---|---|
| Entree | mqtt in, inject | Reception de messages MQTT, injection de donnees |
| Traitement | switch, function, change | Logique conditionnelle, transformation de donnees |
| Sortie | mqtt out, debug, email | Publication MQTT, affichage de debug, envoi email |
| Dashboard | gauge, chart, button, text | Composants 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.
| Critere | HTTP | MQTT | CoAP |
|---|---|---|---|
| Modele | Request/Response | Publish/Subscribe | Request/Response |
| Transport | TCP | TCP | UDP |
| Overhead | Eleve (en-tetes texte) | Faible (2 octets min) | Tres faible (4 octets) |
| QoS | Non natif | 3 niveaux (0, 1, 2) | Confirmable/Non-confirmable |
| Decouverte | Non | Non | Oui (ressource .well-known/core) |
| Observe | Non | Oui (subscribe) | Oui (option Observe) |
| Securite | TLS | TLS | DTLS |
| Usage typique | API web, REST | Telemetrie, notification | Objets tres contraints |
| Consommation | Elevee | Moderee | Faible |
| Latence | Moderee | Faible | Tres 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 :
| Couche | Protocoles standard | Protocoles IoT |
|---|---|---|
| Application | HTTP, FTP | MQTT, CoAP, AMQP, oneM2M |
| Transport | TCP, UDP | TCP (MQTT), UDP (CoAP) |
| Reseau | IPv4, IPv6 | 6LoWPAN, RPL |
| Liaison | Ethernet, WiFi | IEEE 802.15.4, BLE, LoRa, Sigfox |
| Physique | Cables, ondes | RF 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 :
- Cloud et Edge Computing - S9 : deploiement des brokers et CSE
- Security for Connected Objects - S9 : securisation MQTT/TLS
- Wireless Sensors Networks - S9 : couches basses des capteurs
- Service Oriented Architecture - S9 : API REST, microservices
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.
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.
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:
- Security for Connected Objects - S9 - IoT security
- Cloud & Edge Computing - S9 - IoT architectures
- Wireless Sensors Networks - S9 - Sensor networks
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:
| Component | Role | Description |
|---|---|---|
| Publisher | Sender | Publishes messages on topics |
| Subscriber | Receiver | Subscribes to topics to receive messages |
| Broker | Intermediary | Manages message distribution between publishers and subscribers |
| Topic | Channel | Hierarchical string identifying the message subject (e.g.: sensor/temperature) |
| Message | Data | Content 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:
- The subscriber subscribes to a topic on the broker (e.g.:
insa/luminosity) - The publisher publishes a message on that topic
- The broker forwards the message to all subscribers subscribed to that topic
- 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:
| QoS | Name | Guarantee | Usage |
|---|---|---|---|
| 0 | At most once | No guarantee, "fire and forget" | Non-critical data, frequent telemetry |
| 1 | At least once | Message delivered at least once (duplicates possible) | Important data, duplicate tolerance |
| 2 | Exactly once | Message 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:
- WiFi connection: the NodeMCU connects to the local WiFi network
- MQTT connection: establishing connection with the Mosquitto broker
- Button state publishing: on each physical button press, publishing the state on the
button/statetopic - Luminosity publishing: reading the luminosity sensor (ADC) and publishing on the
light/statetopic on each button press - 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:
| Component | Acronym | Role |
|---|---|---|
| Common Services Entity | CSE | Provides common services (registration, discovery, data management, security) |
| Application Entity | AE | Represents an IoT application that interacts with the CSE |
| Infrastructure Node | IN | Server node hosting the main CSE |
| Middle Node | MN | Intermediate node (gateway) |
| Application Service Node | ASN | Sensor/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:
| Type | Code (ty) | Description |
|---|---|---|
| ACP | 1 | Access Control Policy (CRUD + Notify + Discovery rights) |
| AE | 2 | Application Entity - represents an application |
| Container | 3 | Data container (hierarchical structure) |
| ContentInstance | 4 | Content instance (individual data point) |
| Subscription | 23 | Subscription 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:
| Value | Permission |
|---|---|
| 1 | CREATE |
| 2 | RETRIEVE |
| 4 | UPDATE |
| 8 | DELETE |
| 16 | NOTIFY |
| 32 | DISCOVERY |
| 63 | All 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:
| Category | Nodes | Function |
|---|---|---|
| Input | mqtt in, inject | MQTT message reception, data injection |
| Processing | switch, function, change | Conditional logic, data transformation |
| Output | mqtt out, debug, email | MQTT publishing, debug display, email sending |
| Dashboard | gauge, chart, button, text | User 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.
| Criterion | HTTP | MQTT | CoAP |
|---|---|---|---|
| Model | Request/Response | Publish/Subscribe | Request/Response |
| Transport | TCP | TCP | UDP |
| Overhead | High (text headers) | Low (2 bytes min) | Very low (4 bytes) |
| QoS | Not native | 3 levels (0, 1, 2) | Confirmable/Non-confirmable |
| Discovery | No | No | Yes (.well-known/core resource) |
| Observe | No | Yes (subscribe) | Yes (Observe option) |
| Security | TLS | TLS | DTLS |
| Typical use | Web API, REST | Telemetry, notification | Highly constrained objects |
| Consumption | High | Moderate | Low |
| Latency | Moderate | Low | Very 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:
| Layer | Standard protocols | IoT protocols |
|---|---|---|
| Application | HTTP, FTP | MQTT, CoAP, AMQP, oneM2M |
| Transport | TCP, UDP | TCP (MQTT), UDP (CoAP) |
| Network | IPv4, IPv6 | 6LoWPAN, RPL |
| Data Link | Ethernet, WiFi | IEEE 802.15.4, BLE, LoRa, Sigfox |
| Physical | Cables, waves | RF 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:
- Cloud and Edge Computing - S9: broker and CSE deployment
- Security for Connected Objects - S9: MQTT/TLS security
- Wireless Sensors Networks - S9: sensor lower layers
- Service Oriented Architecture - S9: REST APIs, microservices
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.
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.
Course taken in 2024-2025 at INSA Toulouse, Department of Electrical and Computer Engineering, ISS (Innovative Smart Systems) specialization.