Qu’est-ce que MQTT ? Le protocole MQTT expliqué

MQTT est un protocole de messagerie léger fondé sur la publication et l’abonnement. Les appareils et les applications se connectent à un seul serveur, le broker, et publient des messages sur des sujets nommés comme site/dub01/mdb1/main-incomer. Tout client abonné à ce sujet reçoit le message par le broker. Les éditeurs et les abonnés ne s’adressent jamais directement : un compteur, un tableau de bord et une plateforme cloud peuvent partager des données sans se connaître. MQTT fonctionne sur TCP au port 1883, ou sur TLS au port 8883, et son en-tête fixe ne fait que deux octets. Comme chaque appareil se connecte en sortie au broker et que n’importe quel nombre de systèmes peut s’abonner aux mêmes données, il est devenu le protocole le plus courant pour envoyer des mesures de capteurs et de compteurs par Internet.

Le fonctionnement de MQTT

Un client ouvre une connexion TCP vers le broker et envoie CONNECT avec son identifiant de client, ses identifiants d’accès et un intervalle de keep-alive. Le broker répond CONNACK. Un éditeur envoie ensuite des paquets PUBLISH ; un abonné envoie SUBSCRIBE avec un ou plusieurs filtres de sujets, et le broker lui transmet dès lors chaque PUBLISH correspondant. Si aucun paquet ne passe pendant l’intervalle de keep-alive, le client envoie PINGREQ, et le broker ferme une connexion restée muette pendant une fois et demie l’intervalle.

Comme chaque client établit une connexion sortante vers le broker, la passerelle d’un site n’a besoin d’aucun port entrant ouvert. C’est la principale raison pratique pour laquelle MQTT a remplacé les protocoles interrogés pour sortir les données d’un site.

Sujets et jokers

Les sujets sont des chaînes sensibles à la casse. Un client ne crée pas un sujet ; il publie dessus, et le broker achemine le message vers chaque abonnement qui correspond. Un abonnement peut utiliser deux jokers :

+ remplace un niveau et # tout le reste de l’arborescence : il doit donc venir en dernier. Les sujets qui commencent par $ sont réservés au broker, comme $SYS/ pour ses statistiques, et un filtre qui commence par un joker ne les inclut pas.

Concevez l’arborescence des sujets avant que le premier appareil ne publie, car chaque abonné et chaque règle d’accès en dépendent. Une bonne arborescence va du périmètre le plus large au plus étroit (organisation, site, tableau, appareil, puis type de message), place chaque appareil à un seul endroit et exclut les valeurs changeantes comme une mesure, un horodatage ou un numéro de session. Séparez les sujets de télémétrie, d’état et de commande, pour n’accorder le droit d’écriture que là où il est nécessaire.

QoS, messages conservés et dernière volonté

MQTT a trois niveaux de livraison. Ils s’appliquent à un segment à la fois : de l’éditeur au broker, puis du broker à chaque abonné.

Un message conservé (retained) est gardé par le broker comme dernière valeur de son sujet et envoyé aussitôt à chaque nouvel abonné : utile pour un état d’appareil, mais il peut livrer une mesure périmée. La dernière volonté (last will) est un message que le broker publie pour un client dont la connexion tombe sans DISCONNECT propre : c’est ainsi qu’un abonné apprend qu’une passerelle est hors ligne. Le guide QoS et messages conservés MQTT détaille les deux, avec l’expiration des messages et les sessions persistantes.

Ports et sécurité MQTT

MQTT ne prévoit en lui-même qu’un champ identifiant et mot de passe. Le chiffrement, l’identité du serveur et les certificats clients viennent de TLS, et le contrôle d’accès vient des règles du broker sur les sujets que chaque client peut publier ou suivre. Le guide MQTTS explique les certificats, la vérification du nom du serveur et comment tester une connexion TLS en ligne de commande.

MQTT 3.1.1 ou MQTT 5

MQTT a été conçu en 1999 pour la télémétrie d’oléoducs par liaison satellite. OASIS a publié MQTT 3.1.1 comme norme en 2014, devenue ISO/IEC 20922 en 2016, puis MQTT 5.0 en 2019. La plupart des brokers prennent en charge les deux, et de nombreux appareils ne parlent encore que la 3.1.1.

Pour la télémétrie, les apports les plus utiles de MQTT 5 sont les codes de raison, car un client voit que le broker a refusé un message, et l’expiration des messages, car une commande retardée par une coupure est abandonnée au lieu d’être exécutée en retard.

Charge utile : JSON, Sparkplug B et le contrat de données

MQTT transporte des octets et ne dit rien de leur sens. La plupart des plateformes énergétiques attendent du JSON, par exemple :

{"ts":"2026-10-28T09:15:00Z","kW":184.2,"kWh":1532871.4,"V1":231.4,"PF":0.94,"q":"good"}

Le sujet indique de quel compteur il s’agit ; la charge utile porte l’heure de mesure, les valeurs et un indicateur de qualité. Les unités et le sens de chaque clé doivent être écrits et convenus avec chaque abonné : kW ou W, énergie soutirée ou nette, heure du compteur ou heure de réception par la passerelle. C’est cet accord, et non la prise en charge de MQTT, qui fait fonctionner deux systèmes ensemble. Le guide de l’interopérabilité énumère ce qu’un contrat de données doit fixer, et le guide heure de mesure et heure d’arrivée explique pourquoi l’heure de mesure doit figurer dans la charge utile.

Sparkplug B, spécification de l’Eclipse Foundation courante dans les systèmes industriels, fixe au contraire ce contrat. Les sujets suivent spBv1.0/<group>/<message type>/<edge node>/<device>, la charge utile est en Protocol Buffers binaires, et chaque nœud edge publie un certificat de naissance listant ses mesures et un certificat de mort (par la dernière volonté) quand il se déconnecte. Un abonné peut alors découvrir les appareils et marquer les données comme périmées sans accord spécifique, au prix d’un format binaire qu’il faut un client compatible Sparkplug pour lire.

Exemple chiffré : quel volume de données pour la télémétrie MQTT ?

Cinquante compteurs publient chacun le message JSON ci-dessus toutes les 10 secondes en QoS 1. La charge utile fait 88 octets et le sujet 28 octets : chaque paquet PUBLISH fait donc environ 122 octets. TLS ajoute environ 22 octets par enregistrement, TCP et IP environ 52 octets par segment : chaque message occupe environ 200 octets sur la ligne.

Le message par site porte les 50 mesures dans un tableau JSON d’environ 3 650 octets (environ 73 octets par compteur, avec un seul horodatage pour tout le message), plus le sujet et les en-têtes, que TCP répartit sur trois segments.

Les PUBACK qui reviennent ajoutent encore une trentaine de Mo par jour dans le premier cas. Sur une ligne fixe, cela ne compte pas ; sur une carte SIM cellulaire, cela décide du forfait. Regrouper les mesures d’un site dans un seul message, ou n’envoyer que les changements, réduit le surcoût. Le calculateur de puissance par intervalle aide à choisir un intervalle qui répond encore à la question à laquelle les données doivent servir.

MQTT comparé à d’autres protocoles

MQTT est en général le lien entre un site et une plateforme, tandis que Modbus, BACnet et OPC UA lisent les appareils du site. Le comparatif OPC UA, Modbus et MQTT les met en regard pour les projets industriels, et Qu’est-ce que Modbus ? explique le côté interrogé.

MQTT avec EpiSensor

Edge, sur la Gateway ZGW-20, lit les appareils Zigbee, Modbus, BACnet et LoRaWAN du site, enregistre chaque mesure avec son heure de mesure et publie vers le broker d’une plateforme en tant que client MQTT, normalement en MQTTS sur le port 8883 avec un certificat client. Il publie en QoS 1 et garde les livraisons en échec dans une file locale, qu’il rejoue avec leurs horodatages d’origine quand le broker revient. Les sujets et la charge utile suivent le contrat de la plateforme, et Connecter Edge à votre plateforme présente les façons dont Edge transmet les données.