MQTT est un protocole de messagerie léger qui permet aux appareils d'envoyer de petits messages par l'intermédiaire d'un serveur central, appelé broker, plutôt que de communiquer directement entre eux. Un appareil publie un message sous une étiquette appelée topic, et chaque programme abonné à ce topic en reçoit une copie. Ce fonctionnement explique pourquoi MQTT se retrouve dans les capteurs, les passerelles industrielles, les hubs Zigbee et les systèmes de gestion des bâtiments.

Andy Stanford-Clark, d'IBM, et Arlen Nipper, alors chez Arcom Control Systems, l'ont conçu en 1999 pour surveiller des oléoducs au moyen de liaisons satellite lentes et coûteuses. Cette origine explique encore aujourd'hui une grande partie de sa conception, des paquets minuscules à la possibilité pour un appareil de faire signaler sa propre disparition.

L'essentiel

  • MQTT fonctionne en publication/abonnement : les appareils publient des messages sur les topics d'un broker, qui transmet chaque message à tous les abonnés concernés.
  • Émetteurs et abonnés n'ont pas besoin de se connaître. Un tableau de bord, une base de données ou un service d'alerte peut donc être ajouté plus tard sans toucher à l'appareil.
  • Trois niveaux de QoS permettent d'arbitrer entre bande passante et garanties de livraison. Le testament signale qu'un appareil a perdu sa connexion.
  • Sparkplug complète MQTT avec une organisation commune des topics, un format de données et un suivi des états en ligne/hors ligne pour les systèmes industriels.

À quoi sert MQTT ?

MQTT sert lorsque de nombreux appareils transmettent fréquemment de petites quantités de données auxquelles un système doit réagir. Il peut s'agir d'une sonde de chambre froide qui relève la température chaque minute, d'un contrôleur de pompe qui indique si elle fonctionne, ou d'un hub Zigbee qui relaie les événements de porte et de mouvement. La même connexion fonctionne dans l'autre sens : une application peut envoyer une commande à un appareil, par exemple pour commuter un relais ou modifier une consigne.

Trois caractéristiques expliquent son intérêt. D'abord, les données de contrôle prennent très peu de place : l'en-tête fixe d'un paquet MQTT peut ne faire que deux octets, alors qu'une requête HTTP comporte généralement plusieurs centaines d'octets d'en-têtes avant même la mesure. Pour un appareil qui envoie un nombre toutes les quelques secondes, l'écart finit par compter.

Ensuite, la connexion reste ouverte. Puisque l'appareil l'a établie vers l'extérieur, le broker peut lui renvoyer des messages même derrière un pare-feu ou sur un réseau mobile qui bloquerait les requêtes entrantes.

Enfin, l'émetteur et les destinataires sont indépendants. Un capteur qui publie sur un topic ne sait pas si un programme ou vingt l'écoutent. Ajouter un tableau de bord ou un service d'alerte un an plus tard ne nécessite donc aucune modification de son micrologiciel.

Beaucoup d'équipements utiles à surveiller ne parlent pas MQTT nativement. Les compteurs d'énergie et les variateurs utilisent souvent Modbus, les contrôleurs de bâtiment BACnet, les machines d'usine OPC UA, et de nombreux capteurs sans fil du bâtiment Zigbee. La solution habituelle est une passerelle installée sur site, qui lit le protocole d'origine et publie les valeurs sous forme de messages MQTT. Ce peut être un boîtier industriel Advantech ou Moxa, un petit ordinateur exécutant Node-RED, ou un hub Zigbee2MQTT qui publie les données de chaque appareil Zigbee en JSON. Le reste du système n'a alors plus qu'un seul protocole à comprendre.

MQTT ne convient pas à tous les besoins. HTTP est souvent plus simple pour des échanges ponctuels de requête et de réponse, comme un appareil qui envoie un rapport par jour ou une application qui récupère un fichier de configuration. Un capteur sur batterie conçu pour tenir plusieurs années ne peut généralement pas maintenir une connexion TCP ouverte. Il utilise donc plutôt une liaison radio basse consommation, comme LoRaWAN, et rejoint le reste du système par une passerelle. La vidéo en continu et les gros transferts de fichiers relèvent eux aussi d'autres protocoles.

Qu'est-ce qu'un serveur MQTT ?

Un serveur MQTT est le programme auquel se connectent tous les appareils et applications. On l'appelle généralement broker, car il ne distribue pas de pages comme un serveur web. Il reçoit chaque message, consulte son topic et en transmet une copie à chaque client dont l'abonnement correspond. Parmi les brokers connus figurent Eclipse Mosquitto, qui est open source, EMQX et HiveMQ, ainsi que des services cloud comme AWS IoT Core.

Les topics sont des chaînes de texte découpées en niveaux par des barres obliques, un peu comme des chemins de fichiers. Une sonde de chambre froide peut publier sur plant1/coldroom3/temperature, et un contact de porte sur plant1/dock2/door. Personne ne crée les topics à l'avance : ils existent dès qu'un message y est publié. C'est pourquoi les équipes définissent tôt une convention de nommage. Le broker accepte toute orthographe, et une faute de frappe crée simplement un nouveau topic que personne n'écoute.

Les abonnés disposent de deux caractères génériques. Le signe plus correspond à un seul niveau : plant1/+/temperature reçoit donc les températures de toutes les pièces du site 1. Le dièse correspond à tout ce qui se trouve sous un niveau : plant1/# reçoit tous les messages du site 1. Ces caractères s'utilisent uniquement dans les abonnements ; un émetteur indique toujours un topic précis.

Le broker ne regarde jamais le contenu du message. La charge utile n'est qu'une suite d'octets : un simple nombre, un objet JSON comme {"temperature": 4.2, "battery": 87}, ou un format binaire. Chaque abonné doit savoir l'interpréter. C'est précisément le problème que Sparkplug résout pour les systèmes industriels.

Deux autres fonctions du broker influencent le comportement du système. Lorsqu'un message est publié avec l'indicateur retain, le broker le conserve comme message retenu du topic, à raison d'un seul par topic, et le remet immédiatement à chaque nouvel abonné. Un tableau de bord qui vient de s'ouvrir affiche ainsi la position actuelle d'une vanne sans attendre la prochaine mise à jour. Une session persistante permet au broker de conserver les abonnements d'un client déconnecté et de mettre en attente ses messages QoS 1 et QoS 2 jusqu'à sa reconnexion. La mise en attente éventuelle des messages QoS 0 dépend du broker.

Vous pouvez exploiter votre propre broker ou utiliser celui d'un prestataire : la connexion d'appareils MQTT à Kilo fonctionne dans les deux cas. Avec Cloud MQTT, Kilo provisionne un broker avec un point de connexion et des identifiants propres à chaque connecteur. Il accepte uniquement les connexions MQTTS chiffrées sur le port 1884. Avec External MQTT, Kilo se connecte à un broker que vous exploitez déjà, comme Mosquitto, HiveMQ ou AWS IoT Core. Dans les deux cas, vous choisissez comment chaque message est associé à son appareil : par un motif de topic ou par un identifiant d'appareil présent dans le JSON.

Qu'est-ce qu'un client MQTT ?

Un client MQTT est tout élément qui se connecte au broker : capteur, passerelle, application mobile, programme alimentant une base de données ou plateforme cloud. En dehors du broker lui-même, le protocole ne distingue pas d'autres rôles. Chaque client peut publier, s'abonner ou faire les deux.

À la connexion, le client transmet un identifiant qui doit être unique sur ce broker. Si une seconde connexion arrive avec le même identifiant, le broker ferme la première. C'est une cause fréquente de déconnexions alternées entre deux appareils. Le client peut aussi transmettre un nom d'utilisateur et un mot de passe ou présenter un certificat. Il indique également un intervalle de maintien de connexion, par exemple 60 secondes. S'il n'a rien à envoyer pendant ce délai, il émet un petit ping pour signaler sa présence.

Des bibliothèques clientes, notamment la famille Eclipse Paho, existent pour presque tous les langages de programmation et pour de petits microcontrôleurs. Un script Python et une carte ESP32 peuvent donc partager le même broker. Pour diagnostiquer un problème, un client MQTT de bureau abonné à # sur un broker de test affiche tous les messages à leur arrivée.

Quels sont les niveaux de QoS MQTT ?

La qualité de service, ou QoS, est un réglage propre à chaque message qui détermine les efforts de livraison de l'émetteur et du destinataire. MQTT propose trois niveaux.

  • QoS 0, au plus une fois. Le message est envoyé une fois, sans accusé de réception. Si le réseau le perd, il disparaît. Cela convient aux mesures fréquentes.
  • QoS 1, au moins une fois. Le destinataire accuse réception de chaque message. En l'absence d'accusé, l'émetteur le renvoie, généralement après une reconnexion. Rien n'est perdu, mais un message peut arriver deux fois : le destinataire doit donc supporter les doublons.
  • QoS 2, exactement une fois. Un échange en quatre étapes garantit une livraison unique. C'est le niveau qui nécessite le plus d'allers-retours. Il convient aux cas où un doublon serait dommageable, par exemple une facturation à l'événement.

La QoS s'applique séparément à chaque trajet : de l'émetteur au broker, puis du broker à chaque abonné. L'abonné reçoit le message au plus faible des deux niveaux.

Prenons un capteur de cuve qui publie son niveau de remplissage toutes les 30 secondes sur une connexion mobile. En QoS 0, perdre ponctuellement une mesure n'a guère de conséquence : la suivante arrive 30 secondes plus tard. Une commande de fermeture de vanne est différente. Sa perte compte ; elle part donc en QoS 1, et le contrôleur traite une seconde commande « fermer » sans effet indésirable.

Qu'est-ce que le testament MQTT ?

Le testament, ou Last Will and Testament, généralement abrégé LWT, est un message que le client confie au broker lors de sa connexion. Il comprend un topic, une charge utile et un niveau de QoS. Le broker le conserve et ne le publie que si le client disparaît sans prévenir : coupure réseau, panne de courant ou expiration du délai de maintien de connexion sans trafic. Si le client se déconnecte proprement, le broker supprime le testament.

Le schéma habituel est le suivant. Lorsqu'une passerelle se connecte, elle publie online comme message retenu sur plant1/gateway7/status et enregistre un testament qui publiera offline, également comme message retenu, sur ce même topic. Tous les abonnés connaissent ainsi son état actuel, même après une panne.

La spécification accorde au broker une fois et demie l'intervalle de maintien de connexion avant de considérer qu'un client silencieux a disparu. Avec un intervalle de 60 secondes, le message de déconnexion peut donc mettre environ 90 secondes à apparaître. MQTT 5, la version actuelle du protocole, permet aussi de retarder la publication du testament afin qu'une reconnexion rapide ne soit pas annoncée comme une panne.

Qu'est-ce que MQTT Sparkplug ?

MQTT Sparkplug est une spécification qui définit les règles laissées ouvertes par MQTT. MQTT ne précise ni le nommage des topics, ni l'encodage des charges utiles, ni la façon de savoir si une machine est en ligne. Deux fabricants peuvent donc utiliser MQTT sans comprendre leurs données respectives. Créé par Cirrus Link Solutions, Sparkplug a rejoint en 2019 la fondation Eclipse, qui le maintient aujourd'hui.

La structure des topics est fixe : spBv1.0/<group>/<message type>/<edge node>/<device>. Les charges utiles utilisent un encodage binaire compact fondé sur Protocol Buffers, avec des métriques nommées, des types de données et des horodatages. L'état est suivi au moyen de certificats de naissance et de décès. Lorsqu'un nœud de périphérie se connecte, il publie un message de naissance qui liste toutes les métriques qu'il transmettra, avec leur nom et leur type. Il n'envoie ensuite que les valeurs modifiées, ce qui réduit le trafic sur les grands sites. Son certificat de décès est enregistré comme testament MQTT : si le nœud disparaît, le broker en informe tous les abonnés sans qu'ils aient à l'interroger.

Le « B » de Sparkplug B désigne la version du format de charge utile utilisée aujourd'hui. On la rencontre surtout dans les usines et les systèmes SCADA, où des équipements de nombreux fabricants partagent un broker.

Questions fréquentes sur MQTT

Quel port utilise MQTT ?

MQTT sans chiffrement utilise le port TCP 1883, et MQTT sur TLS le port 8883. Tous deux sont enregistrés auprès de l'IANA pour MQTT. Un broker peut également être configuré pour écouter sur un autre port.

MQTT utilise-t-il TCP ou UDP ?

Le MQTT standard fonctionne sur TCP, car il repose sur une connexion bidirectionnelle fiable qui conserve l'ordre des données. Il peut aussi fonctionner sur WebSockets, ce qui permet à une page web de jouer le rôle de client MQTT. Une variante distincte, MQTT-SN, existe pour UDP et pour les réseaux de capteurs qui ne transportent pas TCP.

MQTT est-il sécurisé ?

MQTT ne chiffre rien à lui seul : la sécurité dépend de la configuration du broker. Les mesures habituelles consistent à chiffrer la connexion avec TLS, à attribuer des identifiants ou un certificat client à chaque appareil, et à limiter les topics sur lesquels chaque client peut publier ou s'abonner. Un broker qui accepte des connexions anonymes et non chiffrées depuis Internet permet à toute personne qui peut le joindre de lire tous les messages et de publier des commandes.

Quelle différence entre MQTT 3.1.1 et MQTT 5 ?

MQTT 3.1.1 est devenu une norme OASIS en 2014, puis a été publié sous la référence ISO/IEC 20922. MQTT 5 a suivi en 2019. Il ajoute des codes de raison dans les accusés de réception, l'expiration des messages et des sessions, les abonnements partagés qui répartissent les messages d'un topic entre plusieurs clients, les propriétés utilisateur et les alias de topics. De nombreux brokers prennent en charge les deux versions ; chaque client choisit la sienne à la connexion.

Créez un connecteur Cloud MQTT dans un compte Kilo gratuit, publiez une mesure JSON sur TLS depuis n'importe quel client MQTT vers le point de connexion fourni, puis enregistrez un appareil pour ce topic. L'onglet Mapping de l'appareil répertorie alors tous les champs reçus avec leur valeur actuelle. Les objets JSON imbriqués sont aplatis en clés telles que sensor.temperature, et vous choisissez les champs qui deviennent des métriques. Avec un appareil de test, le forfait gratuit laisse encore de la place pour quatre autres une fois la première transmission validée.