MQTT-SN est une variante de MQTT conçue pour les réseaux de capteurs où TCP est trop lourd, voire tout simplement indisponible. Dans cet article, vous verrez en quoi MQTT-SN diffère du MQTT classique, ce que sont les topic IDs, les passerelles et les clients en veille, et comment relayer les appareils MQTT-SN vers un broker standard pour que le reste de votre stack n'ait jamais à savoir qu'ils existent.
Qu'est-ce que MQTT-SN ?
MQTT-SN signifie MQTT for Sensor Networks (MQTT pour réseaux de capteurs). Il a été publié à l'origine par des chercheurs d'IBM à la fin des années 2000 (d'abord sous le nom MQTT-S) afin d'apporter le modèle publish/subscribe aux réseaux de capteurs sans fil comme Zigbee, dont les nœuds disposent de radios minuscules, de batteries minuscules et d'aucune pile TCP/IP. La version la plus largement implémentée est MQTT-SN 1.2 ; OASIS travaille depuis sur un successeur standardisé.
L'objectif de conception est simple : conserver le modèle de programmation MQTT (topics, publish, subscribe, QoS) tout en supprimant tout ce qui coûte cher sur une liaison contrainte. MQTT-SN n'exige pas de transport orienté connexion. Il fonctionne sur UDP, ainsi que sur des réseaux de datagrammes non IP comme Zigbee ou des couches maillées basées sur BLE, du moment que le réseau sait acheminer des datagrammes adressés.
Conséquence importante : un client MQTT-SN ne peut pas dialoguer directement avec un broker MQTT classique. Il lui faut une passerelle (gateway) qui parle MQTT-SN d'un côté et MQTT sur TCP de l'autre.
MQTT-SN vs MQTT en un coup d'œil
| Caractéristique | MQTT (3.1.1 / 5.0) | MQTT-SN 1.2 |
|---|---|---|
| Transport | TCP, TLS, WebSocket | UDP ou autres réseaux de datagrammes |
| Topic dans le PUBLISH | Chaîne UTF-8 complète | Topic ID sur 2 octets ou nom court de 2 caractères |
| Découverte de passerelle | Sans objet | ADVERTISE, SEARCHGW, GWINFO |
| Clients en veille | Non intégré | États ASLEEP et AWAKE avec mise en mémoire tampon |
| Niveaux de QoS | 0, 1, 2 | 0, 1, 2 et QoS -1 (publication sans connexion) |
| Configuration du Will message | Dans le CONNECT | Échanges WILLTOPIC et WILLMSG séparés |
| Sécurité | TLS et authentification | Laissée à la couche réseau ou à DTLS |
Topic IDs : économiser des octets à chaque publication
Un topic comme factory/izmir/hall2/line4/temperature coûte des dizaines d'octets dans chaque paquet PUBLISH. Sur une liaison où une trame entière transporte parfois une centaine d'octets, c'est inacceptable. MQTT-SN remplace donc la chaîne par un nombre sur deux octets.
Il existe trois façons d'en obtenir un :
- Topic IDs enregistrés. Le client envoie
REGISTERavec le nom complet du topic ; la passerelle répond par unREGACKcontenant un ID. Le client publie ensuite avec cet ID. Les correspondances durent le temps de la session. - Topic IDs prédéfinis. Le client et la passerelle s'accordent à l'avance sur les IDs via la configuration, si bien qu'aucun enregistrement n'est nécessaire. C'est l'option la plus efficace pour un firmware figé.
- Noms de topic courts. Exactement deux caractères, comme
t1, transportés directement dans le champ ID.
Lorsqu'un client s'abonne avec un nom de topic complet, la passerelle renvoie l'ID qu'elle utilisera pour transmettre les messages correspondants. Les abonnements avec wildcards sont pris en charge, mais la passerelle doit alors enregistrer chaque topic concret auprès du client avant de le lui livrer, ce qui ajoute des allers-retours.
Passerelles et forwarders
La passerelle est le cœur de tout déploiement MQTT-SN. La spécification décrit deux styles :
- Passerelle transparente. Pour chaque client MQTT-SN, la passerelle ouvre une connexion MQTT distincte vers le broker. Simple et fidèle à la sémantique par client, mais le broker voit autant de connexions que vous avez de capteurs.
- Passerelle d'agrégation. La passerelle maintient une seule connexion MQTT vers le broker et y multiplexe tout le trafic des capteurs. Moins de connexions côté broker, plus de logique dans la passerelle.
Un forwarder est un nœud encore plus simple qui se contente d'encapsuler les messages MQTT-SN et de les relayer entre les clients et une passerelle sans les interpréter ; il est utile lorsque les clients se trouvent à plusieurs sauts radio.
Les passerelles s'annoncent par des messages ADVERTISE périodiques. Un client qui n'en a pas reçu peut diffuser un SEARCHGW, et les passerelles (ou d'autres clients qui en connaissent une) répondent par un GWINFO.
Clients en veille
Les capteurs sur batterie passent l'essentiel de leur vie radio éteinte. MQTT-SN modélise explicitement ce comportement :
- Le client envoie
DISCONNECTavec une durée de sommeil et passe à l'état endormi. - Pendant son sommeil, la passerelle met en mémoire tampon les messages qui lui sont destinés.
- Le client se réveille, envoie
PINGREQavec son client ID, reçoit les messages en attente, puis obtient unPINGRESPune fois le tampon vidé. - Il se rendort.
Le MQTT classique n'a rien d'équivalent : un appareil qui perd sa connexion TCP est simplement hors ligne, et seules les sessions persistantes sur le broker peuvent conserver des messages pour lui.
QoS -1 : publier sans connexion
MQTT-SN ajoute un niveau parfois noté QoS -1 (ou QoS 3 dans des brouillons ultérieurs). Un client peut envoyer un PUBLISH à l'adresse d'une passerelle connue en utilisant un topic ID prédéfini ou un nom court, sans jamais se connecter. Il n'y a ni acquittement ni session. C'est idéal pour des balises très simples qui se contentent d'émettre une valeur toutes les quelques minutes.
Relayer MQTT-SN vers un broker MQTT standard
Comme la passerelle convertit MQTT-SN en MQTT classique, le côté cloud peut être n'importe quel broker conforme aux standards. Un choix open source courant est l'Eclipse Paho MQTT-SN Gateway (issue du projet paho.mqtt-sn.embedded-c), qui tourne sous Linux, écoute le MQTT-SN sur UDP et se connecte à un broker en amont.
Une configuration qui pointe la passerelle vers un broker MQTT managé comme ConnectMQ ressemble à peu près à ceci. Les noms de clés proviennent du fichier d'exemple gateway.conf de la passerelle ; vérifiez le README de la version que vous compilez, car les options changent d'une version à l'autre.
# gateway.conf (Paho MQTT-SN Gateway, extrait)
GatewayID=1
GatewayName=site1-mqttsn-gw
KeepAlive=60
# Broker MQTT en amont (ConnectMQ, TLS)
BrokerName=broker.connectmq.com
BrokerPortNo=1883
BrokerSecurePortNo=8883
LoginID=YOUR_USERNAME
Password=YOUR_PASSWORD
# Une seule connexion TLS pour tous les capteurs
AggregatingGateway=YES
TransparentGateway=NO
# Côté MQTT-SN : écoute UDP pour les capteurs
GatewayPortNo=10000
MulticastIP=225.1.1.1
MulticastPortNo=1883
Deux points à surveiller spécifiquement avec ConnectMQ :
- Les client IDs sont liés aux identifiants. Chaque jeu d'identifiants du broker est associé à son propre client ID ; une passerelle transparente qui ouvre une connexion amont par capteur a donc besoin d'un jeu d'identifiants par capteur. Une passerelle d'agrégation avec une identité amont unique est généralement plus adaptée.
- Quotas de connexions. Le plan Serverless gratuit autorise jusqu'à 25 connexions et le plan Serverless payant jusqu'à 1 000. L'agrégation vous maintient largement sous ces limites, même avec de grands parcs de capteurs.
Vérifier le côté cloud
Une fois la passerelle lancée, abonnez-vous depuis un ordinateur portable pour voir arriver les données des capteurs sous forme de MQTT ordinaire. Pendant une preuve de concept, vous pouvez plutôt pointer la passerelle vers le serveur MQTT public gratuit (anonyme, port 1883, préfixe de topic unique, réservé aux tests) :
mosquitto_sub -h broker.connectmq.com -p 1883 -i mqttsn-check-4d1e \
-t "connectmq/demo/4d1e/#" -v
Avec les identifiants de production, ajoutez -p 8883 --capath /etc/ssl/certs -u YOUR_USERNAME -P YOUR_PASSWORD ainsi que le client ID fourni par le portail. Tout ce qui se trouve en aval (tableaux de bord, flux Node-RED, historiens) consomme les données exactement comme si les capteurs parlaient MQTT nativement.
Quand choisir MQTT-SN (et quand l'éviter)
Passez cette checklist en revue avant de vous engager :
- L'appareil dispose-t-il d'une pile IP avec TCP ? Si l'appareil a du Wi-Fi ou du cellulaire avec TCP, le MQTT classique sur TLS est plus simple et mieux supporté. Le tutoriel MQTT ESP32 en est un bon exemple.
- La radio ne gère-t-elle que des datagrammes ? Zigbee, 6LoWPAN, les liaisons brutes de type LoRa ou les radios sub-GHz propriétaires sont le terrain naturel de MQTT-SN.
- L'autonomie de la batterie est-elle la contrainte principale ? Les clients en veille et les topic IDs sont rentables quand chaque octet transmis coûte de l'énergie.
- Pouvez-vous exploiter et sécuriser une passerelle ? La passerelle devient un composant critique. Prévoyez la supervision, les redémarrages et ses identifiants amont.
- Et la sécurité ? MQTT-SN n'intègre aucun chiffrement. Appuyez-vous sur la sécurité de la couche liaison ou sur DTLS côté capteurs, et sur TLS pour le tronçon passerelle-broker.
- Disponibilité des bibliothèques. Des bibliothèques clientes existent pour le C et les plateformes embarquées, mais l'écosystème est bien plus restreint que celui de MQTT.
Pour de nombreux projets, une approche hybride est la meilleure : les nœuds contraints parlent MQTT-SN à une passerelle locale, tandis que tout le reste, y compris la liaison amont de la passerelle, parle MQTT standard. Si vous découvrez encore le protocole de base, commencez par le tutoriel MQTT et l'explication sur l'utilisation de TCP ou d'UDP par MQTT.
Pièges courants avec MQTT-SN
- Dérive des topic IDs. Les IDs enregistrés sont propres à chaque session. Après un redémarrage de la passerelle, les clients doivent se réenregistrer, sans quoi ils publieront sur le mauvais topic. Les IDs prédéfinis évitent ce problème, mais doivent rester synchronisés entre le firmware et la configuration de la passerelle.
- Perte de paquets UDP. La QoS 0 sur UDP peut réellement perdre des données. Utilisez la QoS 1 pour tout ce qui compte et dimensionnez les temporisations de réémission selon votre radio.
- Fragmentation. Gardez des payloads réduits ; les messages MQTT-SN sont censés tenir dans une seule trame réseau.
- La passerelle comme point de défaillance unique. Si la passerelle tombe, les capteurs ne mettent rien en mémoire. Concevez pour un redémarrage rapide et des alertes.
Connectez votre réseau de capteurs à ConnectMQ
La passerelle vous appartient ; le broker, lui, n'a pas besoin d'être à votre charge. ConnectMQ offre à votre passerelle MQTT-SN un point d'accès TLS sur le port 8883, la prise en charge de MQTT 3.1.1 et 5.0, et un explorateur de topics en direct pour confirmer que les données circulent. Créez un broker Serverless gratuit sur app.connectmq.com sans carte bancaire, copiez les identifiants générés dans la configuration de votre passerelle, et vos capteurs sont dans le cloud.
Questions fréquentes
Un client MQTT-SN peut-il se connecter directement à un broker MQTT ?
Pas à un broker standard. MQTT-SN utilise un format de paquet et un transport différents ; une passerelle doit donc le traduire en MQTT sur TCP pour le broker.
MQTT-SN prend-il en charge la QoS 2 ?
Oui. MQTT-SN 1.2 prend en charge les QoS 0, 1 et 2, ainsi que le mode QoS -1 sans connexion pour les émetteurs simples.
MQTT-SN est-il sécurisé ?
Le protocole lui-même n'intègre aucun chiffrement. Utilisez la sécurité de la couche liaison ou DTLS entre les capteurs et la passerelle, et TLS entre la passerelle et le broker.
Quel port utilise MQTT-SN ?
Il n'existe pas de port enregistré unique ; cela dépend de la configuration de la passerelle. De nombreux exemples utilisent un port UDP comme 10000 ou réutilisent le 1883 en UDP.
