Tour d'horizon des protocoles : MQTT dans l'IoT

L’univers de l’Internet des objets (IoT) se développe à grande vitesse, et l’une des technologies clés qui rend possible une communication efficace et fiable entre les appareils IoT est MQTT, sigle de Message Queuing Telemetry Transport. Dans cet article, nous allons explorer MQTT, de son histoire et son évolution jusqu’à son architecture, ses niveaux de QoS, ses topics, ses payloads et son rôle dans les applications IoT.

Qu’est-ce que MQTT ?

MQTT est un protocole de messagerie léger et open source, conçu pour une communication efficace et en temps réel entre appareils, en particulier dans les environnements contraints. Il a été créé par le Dr Andy Stanford-Clark d’IBM et Arlen Nipper d’Arcom à la fin des années 1990. MQTT se caractérise par sa faible charge réseau et sa consommation minimale de bande passante et d’énergie, ce qui en fait un choix idéal pour de nombreuses applications IoT.

MQTT a parcouru un long chemin depuis sa création, sur le plan de l’histoire et de l’évolution. Il a d’abord été développé pour surveiller des oléoducs, mais il est depuis devenu l’un des standards de communication de l’IoT. Le protocole répondait au besoin d’une messagerie fiable, à faible bande passante et à faible latence, sur des réseaux distants et peu fiables.

Pourquoi MQTT compte à l’ère de l’IoT

MQTT joue un rôle décisif dans de nombreuses applications IoT où quelques appareils, voire des millions, sont interconnectés. Sa légèreté et sa fiabilité le rendent parfait pour plusieurs applications IoT où les appareils disposent souvent de ressources limitées et d’une connectivité intermittente. MQTT garantit que les données sont transmises de manière efficace et sécurisée entre les appareils IoT et les systèmes centraux.

De plus, le caractère indépendant des appareils propre à MQTT permet à des appareils de différents fabricants de communiquer sans accroc, ce qui favorise l’interopérabilité. Le langage commun fourni par les topics et les payloads MQTT instaure un cadre de communication standardisé, qui permet d’intégrer des appareils IoT variés dans un ensemble cohérent.

L’architecture MQTT

Le modèle client-serveur

MQTT repose sur un modèle client-serveur, où les clients sont les appareils ou applications qui communiquent via MQTT, tandis que le serveur est appelé broker. Le broker se charge de recevoir, d’acheminer et de distribuer les messages aux clients appropriés. Les brokers sont la colonne vertébrale de la communication MQTT : ils servent d’intermédiaires qui gèrent le flux des messages. Les clients peuvent être à la fois publishers et subscribers, en envoyant et en recevant des messages via le broker.

De nombreuses plateformes IoT proposent un broker MQTT intégré ; TagoIO en est un exemple, où vous pouvez intégrer vos appareils MQTT et créer des scripts pour manipuler les données, créer des notifications et visualiser ces données.

Le modèle de communication publish/subscribe

MQTT utilise un modèle de communication publish/subscribe, où les publishers envoient des messages sur des topics précis et les subscribers manifestent leur intérêt pour des topics précis. Cela découple l’émetteur et le récepteur, ce qui rend la communication plus évolutive et plus souple. Par exemple, une station météo pourrait publier des données de température sur « weather/temperature », tandis qu’une application mobile pourrait s’abonner à ce topic pour recevoir les mises à jour des changements de température.

Qu’est-ce que la qualité de service MQTT

MQTT propose trois niveaux de qualité de service (QoS), qui déterminent les garanties de livraison des messages :

1. QoS 0 - Au plus une fois : ce niveau ne garantit aucune livraison. Le message est envoyé une fois, et l’émetteur n’attend ni accusé de réception ni garantie de livraison. Ce niveau convient aux données non critiques où la perte de messages est acceptable.

2. QoS 1 - Au moins une fois : ce niveau garantit la livraison mais peut produire des doublons. Le message est envoyé au moins une fois, et l’émetteur attend un accusé de réception du destinataire. Si l’accusé de réception n’est pas reçu, l’émetteur renvoie le message. Ce niveau convient aux données critiques où la perte de messages est inacceptable.

3. QoS 2 - Exactement une fois : ce niveau garantit la livraison sans aucun doublon. Le message est envoyé exactement une fois, et l’émetteur attend un accusé de réception du destinataire. Si l’accusé de réception n’est pas reçu, l’émetteur renvoie le message. Ce niveau convient aux données critiques avec une tolérance zéro à la perte de messages.

Le choix du niveau de QoS dépend des exigences propres à l’application. Sélectionner le bon niveau de QoS influence la livraison des messages, en agissant sur la duplication des messages et sur la charge réseau.

Les topics et les payloads MQTT

Les topics et les payloads MQTT sont deux composants essentiels du protocole MQTT. Les topics sont comme des canaux sur lesquels les messages sont publiés et auxquels on s’abonne. Ils sont hiérarchiques et aident à organiser les messages.

Les payloads des messages contiennent les données effectives à transmettre. Selon les exigences de l’application, ils peuvent prendre divers formats, comme JSON, XML ou binaire. Le format du payload doit être choisi en fonction des besoins de l’application et des ressources disponibles.

Quelques cas d’usage concrets de MQTT

À mesure que nous explorons l’efficacité de MQTT dans la communication IoT, il est important d’examiner comment ce protocole s’intègre sans accroc avec des appareils de différents fabricants, tels que Dragino, RAK Wireless, Seeed Studio et Khomp. Penchons-nous sur des cas d’usage concrets qui montrent la polyvalence de MQTT à travers les appareils IoT.

1. Systèmes SCADA avec MQTT (Supervisory Control and Data Acquisition) : MQTT est souvent intégré aux systèmes SCADA pour faciliter l’échange de données en temps réel entre les appareils de terrain et le système de supervision central. Il aide à collecter et à gérer les données issues de divers capteurs et appareils répartis dans un environnement industriel.

2. Suivi médical avec des capteurs portables : les scénarios de santé font intervenir des capteurs portables de différents fournisseurs, chacun offrant des capacités de suivi propres. Quelle que soit la marque, les capteurs portables peuvent publier les données de signes vitaux sur un topic standardisé comme « health/patient1/vital-signs ». L’interopérabilité de MQTT assure une intégration sans accroc, ce qui permet aux professionnels de santé de suivre les patients avec des types de capteurs variés.

3. Suivi environnemental avec divers capteurs : le suivi environnemental combine des capteurs de plusieurs fabricants, qui mesurent des paramètres comme la qualité de l’air, les niveaux de bruit ou la détection des rayonnements. La communication par topics de MQTT permet aux capteurs environnementaux de publier leurs données sur des topics partagés comme « environment/air-quality » ou « environment/noise-levels ». Cette interopérabilité simplifie l’intégration de capteurs environnementaux variés dans un système de suivi complet.

Que réserve l’avenir à MQTT ?

MQTT se distingue comme un protocole de communication très avantageux pour les solutions IoT, et il attire l’attention comme une option de prédilection. Néanmoins, le vaste champ des protocoles IoT offre plusieurs alternatives, CoAP étant un concurrent notable. Une caractéristique distinctive de CoAP est sa capacité à fonctionner sur TCP/IP et UDP, ce qui le différencie de MQTT, surtout associé à TCP/IP. L’évolution continue de l’IoT laisse planer une incertitude sur le protocole de communication qui s’imposera le plus largement. À mesure que les avancées technologiques façonnent l’univers de l’IoT, le jeu dynamique entre MQTT, CoAP et d’autres concurrents déterminera en fin de compte le protocole qui correspond le mieux aux besoins divers et changeants des applications IoT.