Mit MQTT einen Roboter steuern - [Teil 1] - AZ-Delivery

La plupart des articles de blog concernent des contrôles ou des réglementations plus simples dont un microcontrôleur s'occupe. Mais les dispositifs IoT, abréviation de Internet of Things, peuvent faire beaucoup plus. La base en est fournie par les protocoles qui assurent la communication avec les différents appareils, comme le MQTT utilisé ici. Ce premier billet de la série de blogs sur le MQTT en enseigne les bases. À la fin de la série de blogs, un petit robot est commandé à l'aide de MQTT, similaire à une télécommande.

Prérequis

Pour cet article de blog, vous n'avez besoin que de quelques éléments, voir le tableau 1.

Nombre Composant
1 Raspberry Pi
1 Unité d'alimentation électrique appropriée

Tableau 1 : Matériel nécessaire

Pour le Pi, n'oubliez pas que vous avez besoin d'une carte MicroSD en plus du matériel ci-dessus. Pour cela, vous devez installer Raspberry Pi OS (anciennement Raspbian) comme image sur la carte.

Note à ce stade

Ce tutoriel présente le MQTT et explique comment créer votre propre courtier en MQTT et vos clients. Par conséquent, pour cette partie seulement, vous avez besoin d'un Raspberry Pi pour suivre et copier toutes les étapes indiquées ici. Dans les prochaines parties de la série de blogs, d'autres clients seront intégrés, comme la carte microcontrôleur compatible avec l'Arduino Uno R3 et le NodeMCU.

Qu'est-ce que MQTT?

MQTT est l'abréviation de Message Queuing Telemetry Transport et est également connu sous l'ancien nom de WebSphere MQTT, WSMQTT en bref. Il s'agit d'un protocole de réseau ouvert pour la communication de machine à machine, par exemple pour transmettre des données de capteurs et/ou commander des actionneurs. Le contexte de ce protocole est qu'une transmission d'informations peut également être garantie dans des réseaux dits instables. L'expression "réseaux instables" remonte à l'époque où les réseaux étaient encore très sensibles aux interférences.

MQTT, s'il est installé par défaut, est accessible via le port réseau 1883. La deuxième porte 8883 est la porte du réseau sécurisé, mais elle doit être cryptée à l'aide du protocole TLS. Pour utiliser le MQTT, vous avez besoin d'un serveur MQTT, appelé courtier, ainsi que des appareils terminaux correspondants qui envoient ou reçoivent les données, également appelés clients. La plupart du temps, le courtier se trouve sur un système d'exploitation basé sur Linux. Cependant, les systèmes d'exploitation Windows sont également possibles. Le MQTT se trouve maintenant dans les technologies d'automatisation et les projets IdO, car il est relativement facile de mettre en place un réseau MQTT avec peu de moyens.

La version 3.1.1 du protocole utilisée ici, ainsi que la version 3.1 précédente, ont été publiées en 2010 sous une licence libre spécifiée par l'organisme de normalisation OASIS. Cette version du protocole a donc déjà plus de 10 ans au moment de la publication du blog. La dernière version du protocole 5.0 a été publiée en 2019 et a également été spécifiée par l'organisme de normalisation OASIS.

Comment marche le MQTT?

Le MQTT utilise l'architecture de publication/abonnement pilotée par les événements. Il n'y a pas de connexion de bout en bout, comme par exemple avec un site web, mais un serveur, le soi-disant courtier, auquel l'expéditeur et le destinataire, les soi-disant clients, se connectent. Afin de mieux comprendre ces liens, la figure 1 illustre cela sous une forme simplifiée.

Figure 1 : Illustration de l'architecture du MQTT

Un client, dans ce cas le capteur, l'appareil mobile ou le dispositif IdO, peut toujours envoyer et/ou recevoir des données ; le courtier sert simplement de tampon d'information qui transmet les données à d'autres clients. Pour que le client puisse recevoir un message correspondant de la part du courtier, il doit s'abonner aux sujets dits "thématiques" lors de l'établissement de la connexion ou pendant le fonctionnement chez le courtier.


Vous pouvez considérer un sujet comme une sorte d'URL (Uniform Resource Locator) qui reflète le contenu souhaité. Un sujet pour un capteur de température dans le salon pourrait publier les valeurs mesurées sur la maison/le rez-de-chaussée/le salon/la température. Pour être clair tout de suite, il ne s'agit pas d'un adresse au capteur, mais permet d'accéder aux données les plus récentes du capteur. Lorsque la lecture est mise à jour, le courtier vérifie quel client s'est abonné pour recevoir ces informations et les transmet.

Échange de données avec le courtier

Comme mentionné au début, le MQTT était destiné aux connexions instables, c'est pourquoi il existe trois qualités de service différentes, la qualité de service ou QoS. Avec le niveau 1 ou la QoS = 0, le message est envoyé exactement une fois. Un accusé de réception, comme c'est le cas pour l'autre QoS, est complètement ignoré. Seule l'édition, la soi-disant PUBLISH, est importante.

Avec la QoS = 1, on parle aussi de "livré au moins une fois", ce qui signifie que l'expéditeur attend un accusé de réception de la part du destinataire. Cet accusé de réception est appelé PUBACK et est obligatoire pour la station distante, sinon l'émetteur transmet jusqu'à ce qu'un accusé de réception soit reçu. Inversement, cela conduit à ce qu'un message soit transmis plusieurs fois au destinataire.

QoS = 2 est la combinaison de QoS = 0 et QoS = 1, ce qui représente également la transmission la plus lente. Ici, le message n'est envoyé qu'une seule fois. Pour ce faire, un accusé de réception en deux étapes est nécessaire.


Tout d'abord, l'expéditeur envoie (PUBLISER) son message au destinataire, qui l'accepte et envoie un message de confirmation (PUBREC), avec le contenu de l'expéditeur en pièce jointe. Si ce message de confirmation (PUBREC) est reçu par l'expéditeur, celui-ci stocke les informations et répond également par un message de confirmation (PUBREL).


Enfin, lorsque le destinataire a reçu le PUBREL, celui-ci envoie le dernier message de confirmation (PUBCOMP). À la fin d'une telle transmission de données, on s'assure que le message est bien arrivé. Pour faciliter la compréhension, la figure 2 montre à nouveau schématiquement comment le flux de messages se présente pour les trois variantes de QoS.

Figure 2 : Vue d'ensemble de la QoS du MQTT

S'abonner aux données du courtier

La question se pose maintenant de savoir comment un client peut désormais interroger les données des capteurs ? Il existe à nouveau plusieurs variantes qui peuvent mener à l'objectif. Dans la première variante, vous pouvez, comme déjà montré ci-dessus avec le simple transfert de données de capteur, spécifier le sujet complètement. Il suffit d'entrer dans le thème Maison/Rez-de-chaussée/Salon/Température. Cependant, vous ne recevrez alors que cette seule valeur à ce stade.

Lors de l'utilisation de la variante deux, l'opérateur + entre en jeu. Avec Home/+/+/Temperature, vous obtenez les données de température pour toutes les pièces de chaque étage. C'est utile si vous souhaitez prédéfinir une telle structure pour tous les capteurs de votre maison et les afficher par exemple groupés.

La troisième variante va un peu plus loin avec l'opérateur #. Par l'intermédiaire de Home/Floor/#, vous obtenez toutes les informations disponibles pour chaque chambre du rez-de-chaussée. Selon la quantité d'informations, il est déjà possible d'en recueillir pas mal à ce stade.

Le quatrième et dernier cas est celui de l'abonnement thématique le plus gourmand en données, si vous envoyez beaucoup de données. En utilisant /#, vous vous abonnez au répertoire racine et chaque modification vous est envoyée. Je ne recommande pas cette variante pour l'instant ! Vous devez réfléchir à l'avance à votre structure ou aux données de mesure que vous voulez inclure et déterminer au préalable.

Enfin, la question se pose probablement de savoir ce qui se passe si un émetteur cesse brusquement d'émettre ? À cette fin, il existe le message dit "retenu" dans le MQTT, qui contient les dernières volontés et le testament. Pour qu'il puisse être utilisé, l'expéditeur, dans notre cas un capteur, doit fournir ce message retenu lors de la connexion au courtier. Il stocke ce qui doit être envoyé si l'expéditeur n'est plus joignable. Un contenu individuel peut alors être rédigé par le courtier pour chaque sujet. Comme le MQTT assure déjà la surveillance, vous n'avez pas à vous inquiéter sur ce point. Comme il s'agit d'un sujet trop approfondi, je peux à ce stade, mais avec plaisir, donner le mot-clé LWT message avec lequel vous trouverez suffisamment de matériel de lecture sur Internet.

Le Raspberry Pi devient un courtier

Comme mentionné dans la section "Qu'est-ce que le MQTT ?", ce protocole jouit d'une grande popularité sur la scène de l'IdO. De nombreuses personnes hésitent à stocker leurs données personnelles ou des données permettant de contrôler leur domicile sur l'internet, par exemple sur mqtt-dashboard.com/C'est donc une bonne idée de créer un petit courtier local avec les Rspberry Pi. À cet effet, peu importe la version de Raspberry Pi que vous prenez et si elle prend déjà en charge des tâches.

Tout d'abord, ouvrez le terminal de votre Raspberry Pi (voir la figure 3) puis entrez les commandes du Code 1.

Figure 3: Terminal ouvert dans Pi

sudo apt upgrade

sudo apt dist-upgrade

Code 1: mettre à jour Raspbian

Cela permettra d'abord de mettre à jour le Raspberry Pi et tous les paquets installés. Ensuite, entrez la commande du code 2. Vous pourrez ainsi télécharger le populaire moustique courtier et l'application client sur votre Raspberry Pi. Confirmez l'installation dans le terminal au point approprié.

sudo apt install mosquitto mosquitto clients

Code 2: installer le serveur et le client Mosquitto

Pour garantir que le courtier démarre directement après un redémarrage, utilisez la commande du code 3.

sudo systemctl enable mosquitto.service

Code 3: Démarrez le service mosquitto lorsque le Pi est redémarré

Comme le serveur ne fonctionne peut-être pas encore sur Pi, lancez-le avec la commande du code 4.

sudo mosquitto -d

Code 4: démarrer Mosquitto

À partir de ce moment, vous avez mis en place un courtier MQTT local et non crypté dans votre réseau domestique. À moins que vous n'ayez mis en place une redirection de port vers le Raspberry Pi via votre routeur, celui-ci n'est pas accessible sur Internet. Toutefois, il devrait suffire pour l'instant à un emploi domestique. Pour garantir que le courtier reste accessible depuis le Pi après un redémarrage, vous devez attribuer au Raspberry Pi un adresse IP fixe via le routeur.

Envoyer et recevoir des données au courtier

Il est maintenant temps de mettre la théorie en pratique et d'envoyer des messages au courtier et aussi de recevoir des messages du courtier. Pour cela, les commandes du terminal "mosquitto_sub" pour la fonction subscribe et "mosquitto_pub" pour la fonction publish messages sont nécessaires.

Nous commencerons par la commande de terminal "mosquitto_sub", dont les principales commandes sont expliquées ci-dessous. Si vous souhaitez aller au-delà des commandes présentées ici, je vous recommande le manuel Linux fourni en interne, que vous pouvez appeler dans le terminal avec la commande "man mosquitto_sub", "man mosquitto_pub" ou "man mosquitto". L'homme de commande Linux signifie "manuel".

Pour voir en détail ce que l'abonné mosquitto traite en arrière-plan, et aussi pour recevoir tous les messages, utilisez la commande du code 5.

mosquitto_sub -d -q 2 -t / #

Code 5 : Abonné Mosquitto à l'écoute sur le nœud racine

Le code 5 présenté ici utilise les options du tableau 2.

Option Explication
-ré Active le mode de débogage et affiche toutes les informations utiles.
-q Spécifie la qualité de service que l'abonné doit communiquer avec le courtier. QoS 2 est utilisé dans le code 5.
-t Spécifie à quelle rubrique l'abonné doit s'abonner. Dans Code 5, l'abonné s'abonne à tous les sujets.

Tableau 2: Options de l'abonné mosquitto

Si vous avez entré la commande à partir du code 5, la sortie indiquera d'abord la connexion réussie au courtier, voir figure 4 marqueur 1.

Figure 4: Sortie du terminal de moquitto_sub

Dans le marqueur 1 de la figure 4, vous pouvez voir qu'une connexion est établie et que la station distante, le courtier, a accepté la connexion. Immédiatement après, l'abonné transmet le sujet auquel il doit s'abonner, ici "/#", et la QoS qui a été demandée, ici "QoS : 2". Enfin, la demande d'abonnement est acceptée au moyen de SUBACK, l'abonnement reconnu. La connexion avec le courtier est établie et le sujet souhaité est souscrit. 

Le marqueur 2 de la figure 4 apparaîtra dans votre terminal après un certain temps. Il s'agit, comme décrit dans "Comment fonctionne le MQTT", de demander si l'abonné est toujours en ligne. Le courtier demande si l'abonné est toujours en ligne, c'est ce que l'on appelle la demande ping. Normalement, le client envoie la réponse correspondante, appelée réponse ping, au courtier.

La prochaine étape, maintenant que nous avons un abonné, consiste à utiliser un éditeur pour envoyer des données au courtier. Le premier message devrait bien sûr être "Hello World". L'éditeur envoie cette petite phrase au sujet /test/testpub.

Pour ce faire, ouvrez une deuxième fenêtre de terminal et entrez la commande selon le code 6 . 

mosquitto_pub -d -q 2 -t / test / testpub -m "Hello world"

Code 6: mosquitto_pub "Hello World"

Les options utilisées pour le code 6 sont énumérées dans le tableau 3.

Option Explication
-ré Active le mode de débogage et affiche toutes les informations utiles.
-q Précise la qualité de service que l'éditeur doit communiquer au courtier. Dans le code 6, la QoS 2 est utilisée.
-t Spécifie le sujet auquel les données doivent être envoyées, ici / test / testpub
-m Envoyez le message suivant, ici "Hello world"

Tableau 3: Options de l'éditeur mosquitto

Voyons quelles données sont envoyées au courtier pendant la transmission, voir figure 5, marqueur 1. Comme auparavant, la QoS 2 a été sélectionnée dans les options, c'est pourquoi vous voyez également l'historique de communication correspondant.

Figure 5: Sortie du terminal de moquitto_pub et mosquitto_sub

Immédiatement après, le courtier envoie le nouveau message à l'abonné, voir figure 5, marqueur 2, puisque l'abonné s'est abonné à tous les sujets. Vous pouvez voir sur le bord supérieur du marqueur 2 de la figure 5 que de nouvelles données ont été reçues dans le sujet /test/testpub. La poignée de main QoS 2 s'affiche directement derrière, avec le message "Hello world" reçu.

Vous avez ainsi appris les bases du MQTT et le contexte technique du MQTT. N'hésitez pas à jouer avec les commandes et à envoyer des données au courtier et, si nécessaire, à ouvrir d'autres terminaux qui s'abonnent à d'autres sujets.

Dans la prochaine partie de la série de blogs, vous allez connecter un microcontrôleur Arduino ou ESP32 au MQTT et envoyer des données et le pair répondra en conséquence.

Ce projet et d'autres projets peuvent être consultés sur GitHub à l'adresse https://github.com/M3taKn1ght/Blog-Repo

Projekte für anfängerRaspberry pi

7 commentaires

Ruediger

Ruediger

@Jörn: Ein paar Informationen gibt es hier: https://www.facebook.com/flyingthewinglets

Jörn Weise

Jörn Weise

Hallo Herr Kress,
sofern Sie fertige Bibliotheken benutzen, müssen Sie sich um das Quittieren kann Sorgen machen. Bauen Sie aber eine eigene Bibliothel oder Funktion die MQTT übernehmen soll, müssen Sie natürlich daran denken. Ich empfehle hier ganz klar die fertigen Bibliotheken, da spart man sich die Zeit und den Streß.

Hallo Lothar, Egon,
Danke für das Feedback, freut mich als Autor und als Blogger, wenn Beiträge gut ankommen.

Hi jm1704,
thanks for the feedback. Funny part is, that I will show people MQTT.fx in part two of this blog serie. I’m also using this tool for my normal buissnes to test and check signals.

Hallo Ruediger,
das hört sich nach einem sehr spannenden Projekt an. Das interessiert mich wahnsinnig, gibt es dazu ggf. eine Website, wo man diesen Status sehen kann? Zu der Thematik mit den Controllern muss ich gestehen, hatte ich bisher noch keine Aussetzer. Egal welchen ich verwendet habe, hatte ich eine zuverlässige Verbindung zum Wifi. Sicher das an irgendeiner Stelle nicht der verbaute Watchdog vom ESP32 oder ESP8266 zuschlägt? Ich hatte das bei ein paar Tests mal, da hatte ich eine Endlosschleife und habe erst später bemerkt, dass hier der Watchdog immer meinen MicroController neu gestartet hatte.

Gruß / Greetings
Weise

jm1704

jm1704

Good MQTT article with MOSQUITTO
For peoples who want to control or simulate MQTT transaction and check the critical or not and when problem was.
I am also using 2 tools MQTT.fx and MQTT Explorer

Ruediger

Ruediger

Ich betreibe privat einen B737 Flugsimulator und habe vor 1 Jahr damit begonnen Teile der Steuerung auf WiFi und MQTT umzustellen. Das funktioniert soweit recht gut, verwende es aber derzeit noch nicht für kritische Signale. Meine Erfahrung ist, das die WiFi Verbindung immer mal wieder zusammenbricht. Diese wird von dem betroffenen Client zwar wieder aufgebaut, dauert aber 3-5 sek. Während dieser Zeit kann viel passieren. Deshalb mein Hinweis mit MQTT bei kritischen Verbindungen vorsichtig zu sein. Woran es liegt, dass die Wifi Verbindung hin und wieder zusammenbricht, kann ich so noch nicht sagen. Nur soweit, dass ich mit dem ESP8266 ESP-01S noch keine Probleme hatte. Wohl aber mit dem ESP WROOM 32. Eigentlich hätte ich es eher anders herum erwartet. Ingesamt betreibe ich derzeit 4 ESP8266 ESP-01S Clienets und 3 ESP WROOM 32 Clients.

Egon

Egon

Kurz und knapp, sehr verständlich erklärt. Macht weiter so. Warte schon auf den nächsten Beitrag.

Lothar

Lothar

Vielen Dank für das tolle Tutorial zum Thema MQTT. Bin schon sehr gespannt, wie weiter geht.

E. Kress

E. Kress

Es wäre gut zu wissen, ob man als Progeammierer bei QoS 2 selbst für die Quittung-Tätigkeiten sorgen muss oder ob das im MQTT-System automatisch geschieht.

Laisser un commentaire

Tous les commentaires sont modérés avant d'être publiés

Articles de blog recommandés

  1. ESP32 jetzt über den Boardverwalter installieren - AZ-Delivery
  2. Internet-Radio mit dem ESP32 - UPDATE - AZ-Delivery
  3. Arduino IDE - Programmieren für Einsteiger - Teil 1 - AZ-Delivery
  4. ESP32 - das Multitalent - AZ-Delivery