1. Pourquoi le protocole HTTP est-il inadapté à l’IoT de masse ?

Le protocole HTTP traditionnel repose sur une architecture client-serveur synchrone requête/réponse avec des en-têtes textuels volumineux (plusieurs centaines d’octets). Pour un capteur distant fonctionnant sur batterie qui ne transmet que 4 octets de température une fois par minute, HTTP gaspille inutilement de la bande passante et vide prématurément la pile.

Le protocole MQTT (Message Queuing Telemetry Transport), inventé pour la surveillance d’oléoducs par satellite, est un protocole extrêmement léger (en-tête minimal de 2 octets seulement) fonctionnant au-dessus de TCP/IP selon le paradigme Publish / Subscribe (Publication / Souscription).

2. Architecture Publish / Subscribe et le Broker Mosquitto

Dans un système MQTT, les appareils ne communiquent jamais directement entre eux :

[ Capteur Température ESP32 ] ──── Publish: "usine/batA/zone1/temperature" (21.4°C) ───┐
                                                                                        │
                                                                                        ▼
                                                                           ┌───────────────────────┐
                                                                           │  Broker MQTT Central  │
                                                                           │  (Eclipse Mosquitto)  │
                                                                           └───────────────────────┘
                                                                                        │
[ Tableau de bord Grafana ] ◄──── Reçoit la mesure en temps réel ───────────────────────┼── Souscrit à: "usine/batA/+/temperature"
[ Serveur d'alerte SMS ]   ◄──── Reçoit la mesure si > seuil ───────────────────────────┘

3. Arborescence des Topics et caractères génériques (Wildcards)

Les topics MQTT adoptent une structure hiérarchique similaire aux dossiers d’un système de fichiers, séparés par des barres obliques (/) :

  • Caractère + (Wildcard mono-niveau) : suisse/geneve/+/temperature recevra les données des capteurs de tous les bâtiments de Genève au niveau immédiatement inférieur.
  • Caractère # (Wildcard multi-niveaux) : suisse/lausanne/# recevra absolument tous les messages émis sous la branche de Lausanne sans exception.

4. Niveaux de Qualité de Service (QoS)

  1. QoS 0 (At most once – Au mieux) : Le message est envoyé une seule fois sans accusé de réception (type « Fire and Forget »). Risque de perte en cas d’instabilité réseau. Adapté aux flux de données très réguliers et non critiques.
  2. QoS 1 (At least once – Au moins une fois) : Le broker confirme la bonne réception par un paquet PUBACK. En l’absence de retour, l’émetteur renvoie le message. Garantie de livraison mais risque de doublons.
  3. QoS 2 (Exactly once – Exactement une fois) : Poignée de main en quatre étapes (Publish -> Pubrec -> Pubrel -> Pubcomp) garantissant la livraison de manière unique sans doublon. Indispensable pour la facturation et les ordres critiques de téléconduite industrielle.

Fonctionnalité LWT (Last Will and Testament) : Un client enregistre lors de sa connexion un message testamentaire. Si le nœud perd subitement sa connexion Internet sans se déconnecter proprement, le broker publie automatiquement ce message d’alerte pour avertir les systèmes de supervision.

PreviousNext