MQTT, un protocole pour tous les rassembler - Partie 1 : le broker

Si vous ne connaissez pas encore le protocole MQTT, nous allons tenter d'y remédier avec cet article qui fera office de présentation générale et d'étude d'un cas concret de bascule de certains de mes périphériques vers celui-ci.

Le MQTT (ou Message Queuing Telemetry Transport ) a été créé en 1999 dans le but de surveiller un oléoduc dans le désert. Il a été conçu dans l'optique d'être léger en bande passante et économe en ressources énergétiques dans le temps. Le MQTT est maintenant un des protocoles les plus utilisés par les objets IOT (Internet Of Things - objets connectés).

Au cœur de tous les projets MQTT centrés sur des objets connectés se trouvent un serveur central, appelé Broker. Tous les objets et services s'y connectent en tant que clients. Le Broker transmet les messages entre les clients. Les clients peuvent envoyer des messages en tant que publicateurs et recevoir des messages en tant que souscripteur. Les messages contiennent un sujet qui décrit le contenu du message (par exemple: la météo à Paris). Les souscripteurs reçoivent chacun une copie du message s'ils ont souscrit au sujet du message publié.

L'intérêt que je porte au MQTT vient du fait qu'il s'agit d'un protocole universel et robuste, et qu'il est possible de communiquer avec un broker depuis un grand nombre de solutions domotiques, dont Home Assistant, Gladys, Domoticz, Jeedom, ... . Le broker étant un point central et fonctionnant par abonnement, il est possible de faire cohabiter plusieurs solutions en parallèle qui utiliseraient les mêmes informations ou commanderaient les mêmes modules.

Une notion importante du protocole MQTT est la QOS (qualité de service), qui peut être définie selon vos exigences et différente selon les IOT que vous connecterez. Trois niveaux de QOS existent :

• QOS 0 : Le niveau le plus simple est le service non confirmé, aussi appelé « At most once » (au plus une fois). Ce niveau utilise une séquence de paquets PUBLISH : l'expéditeur  envoie un message une seule fois au broker et ce dernier transmet ce message une seule fois aux abonnés. Aucun mécanisme ne garantit la réception du message et le broker ne l'enregistre pas non plus.
• QOS 1 : Ce niveau est le service confirmé, aussi appelé « At least once » (au moins une fois). Ce niveau utilise une séquence de paquets PUBLISH/PUBACK (Publish Acknowledge) entre l'expéditeur et son broker, ainsi qu'entre le broker et les abonnés. Un paquet de confirmation vérifie que le contenu a été reçu et un mécanisme de renvoi du contenu d'origine est déclenché si l'accusé de réception n'est pas reçu en temps voulu. Cela signifie que l'abonné peut recevoir plusieurs copies du même message.
• QOS 2 : Le dernier niveau est le service garanti, aussi appelé « Exactly once » (exactement une fois). Ce niveau délivre le message avec deux paires de paquets. La première est appelée PUBLISH/PUBREC et la seconde, PUBREL/PUBCOMP. Les deux paires s'assurent que quel que soit le nombre de tentatives, le message ne sera délivré qu'une seule fois.

Dans notre utilisation domestique, ce qui peut être fait est d'utiliser la QOS 1 pour s'assurer que l'action demandée soit exécutée ou l'information correctement remontée, comme les lampes ou prises, ou encore les équipements de sécurité, comme les détecteurs d'ouverture. Pour les modules remontant des informations moins sensibles, comme les capeurs de température ou d'humidité, il est tout à fait possible d'utiliser la QOS 0. Vous pourrez affiner la QOS en fonction des équipements et de votre expérience.

La mise en place d'un broker MQTT

Un des brokers les plus connus est Mosquitto (https://mosquitto.org/), open-source et soutenu par la fondation Eclipse.org (bien connu des développeurs).
Pour le faire tourner, nous allons choisir de nous appuyer sur la solution Docker et une stack Docker Compose, cette approche permettant d'être évolutif et de pouvoir y ajouter plus tard des nouveaux conteneurs, en fonction des besoins.

Comme d'habitude, via Portainer (voir cet article si vous ne connaissez pas), on crée une stack qu'on appelle mqtt et on y place le contenu suivant :

version: '2'
services:
    eclipse-mosquitto:
        container_name: mosquitto
        ports:
            - 1883:1883
            - 9001:9001
        volumes:
            - volume-mosquitto-config:/mosquitto/config
            - volume-mosquitto-data:/mosquitto/data
            - volume-mosquitto-log:/mosquitto/log
        image: eclipse-mosquitto
        restart: always

On indique le nom du conteneur à créer, les ports à ouvrir (1883 comme port standard du protocole mqtt et 9001 pour l'utilisation via websocket), et les volumes à monter, ce qui nous permettra d'accéder plus facilement aux fichiers de configuration ou de logs.

Maintenant, passons au test de notre broker. Pour cela, il nous faut un client qui sera capable de lire et publier dans les différents topics. J'utilise MQTT Explorer, un client simple à prendre en main et efficace, qui permet de visualiser les topics sous forme de hiérarchie. Voici une vidéo de prise en main complète par son auteur.

Pour le configurer, il vous suffit d'ajouter une connexion, de lui donner un nom, et enfin de renseigner l'adresse IP de votre Broker et de cliquer sur "Connect". Vous verrez ensuite les différents topics existants sur votre Broker.

Nous aborderons la sécurisation du broker MQTT dans un prochain article, avec la mise en place d'identifiants de connexion, de certificat SSL et la configuration de websockets pour permettre d'annoncer et souscrire depuis Internet, bien pratique pour centraliser les informations remontées depuis des sites distants (modules installés chez de la famille, dans votre maison de campagne, ...).

Pour le moment, c'est bien vide, et nous allons voir ensemble dans le prochain article comment configurer différents types d'objets connectés : les modules wifi Shelly, les capteurs Xiaomi ou encore de la téléinfo.