--- title: FabLab projets tags: atelier, mqtt robots: noindex, nofollow author: Damien Truffaut, Julien Noyer --- # Protocole MQTT _Communication entre objets_ ![](https://i.imgur.com/mq02Waq.jpg) <!-- Temps souhaitable: 1h30 mini pour toute la séquence --> ### Objectif de la séquence - Comprendre le protocole MQTT - Savoir interragir avec les messsages (souscription, publication) - Comprendre la logique de requêtes # Activité 1 _Présentation du protocole MQTT_ ![Schéma de fonctionnement du protocole MQTT](https://i.imgur.com/Pq7aO5D.jpg) ### Message Queuing Telemetry Transport [MQTT (Message Queuing Telemetry Transport)](https://fr.wikipedia.org/wiki/MQTT) est un protocole de messagerie publish-subscribe basé sur le protocole TCP/IP, il a été initialement développé par Andy Stanford-Clark et Arlen Nipper. Un __Broker MQTT__ fonctionne à la manière d'un serveur et permet d'ouvrir des canaux de communication entre appareil sur le principe __Publication/Submition (PubSub)__. Les appareils qui y sont connectés peuvent s'envoyer des information à travaers le _Broker_ qui agit comme un fournisseur d'accès aux information entre les appareils. Le principe de base des communication sur le Broker MQTT est le suivant : - Lorsque q'un appareil veut agir sur un autre il publie un _topic_ - L'appareil qui doit effectuer l'action s'abonne au _topic_ - Les deux appareils peuvent s'abonner et publier sur le même _topic_ ### Les topics : concept de Routing d'un Broker MQTT Chaque [topic](https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices) est une adresse à laquelle les appareils peuvent s'abonner et publier des informations. Lorsqu'il partagent un ou plusieurs __topics__ il est possible de les faire interagir les uns avec les autres via le Broker MQTT sur des canaux ouvert uniquement pour des actions spécifiques. Les appareils connectés au __Broker MQTT__ sont considérer comme des clients autonomes qui doivent contenir les fonctions leur permettant d'agir sur le Broker. A la manière de la partie Front d'un site Web, les appareils dans un réseau MQTT sont des clients qui à travers un serveur - le __Broker MQTT__ - sont capable de traiter et d'envoyer des informations. # Activité 2 _Mise en place d'un Broker MQTT_ ![](https://i.imgur.com/PK8ynrP.jpg) Les logiciels suivant seront installé: - NodeJS : <https://nodejs.org/en/> - Un Broker MQTT : <http://www.mosca.io> - Un logger JSON : <http://getpino.io/#/> - Un client MQTT : <https://github.com/mqttjs/MQTT.js#readme> ## Etape 1 - Installation et premiers essais Trois terminaux doivent être ouverts simultanéments. - Un terminal (désigné __Broker__) pour visualiser le fonctionnement du Broker - Un terminal (désigné __Souscripteur__) pour souscrire à un sujet (_topic_) - Un terminal (désigné __Emetteur__) pour envoyer des messages ### Terminal Broker Installer et lancer le serveur en utilisant __npm__: ```bash npm install mosca pino-pretty mqtt -g && mosca -v | pino ``` ### Terminal Souscripteur Souscrire à un sujet: ```bash $ mqtt sub -t 'hello' -h 'localhost' -v ``` <!-- - Qu'observe-t-on sur le terminal `Broker` - Sur quels protocoles s'appuie le `MQTT` pour communiquer ? --> ### Terminal Emetteur Envoyer un message: ```bash $ mqtt pub -t 'hello' -h 'localhost' -m 'Hello Tizot' ``` <!-- - Qu'observe-t-on sur les terminaux `Broker` et `Souscripteur` ? - Les terminaux peuvent-il correspondre à des machines différentes ? - Quel client mqtt reste connecté ? --> ## Etape 2 - Changement de sujet Envoyer un message: ```bash $ mqtt pub -t 'ciao' -h 'localhost' -m 'Ciao Tizot' ``` <!-- - Qu'observe-t-on sur les terminaux `Broker` et `Souscripteur` => le message est reçu par le broker mais pas par le subsciber --> ## Etape 3 - Déconnexion du broker ### Terminal Broker On arrête le broker ```bash ^C ``` <!-- - Qu'observe-t-on sur le terminal Souscripteur --> On redémarre le broker ```bash $ mosca -v | pino ``` <!-- - Qu'observe-t-on dans les logs - Que peut on en conclure ? => le souscripteur se reconnecte --> ## Etape 4 - Deconnexion du Souscripteur ### Terminal Souscripteur On arrête le client ```bash ^C ``` <!-- - Qu'observe-t-on sur le terminal `Broker` => le souscripteur est déconnecté --> On souscrit au nouveau sujet `ciao` ```bash $ mqtt sub -t 'ciao' -h 'localhost' ``` <!-- - Qu'observe-t-on sur les terminaux `Broker` et `Souscripteur` => le souscripteur se connecte et attend les messages --> ## Etape 5 - Renvoie de messages ### Terminal Emetteur On relance la commande précédente de publication de message: ```bash $ mqtt pub -t 'ciao' -h 'localhost' -m 'Ciao Tizot' $ mqtt pub -t 'ciao' -h 'localhost' -m 'Ciao Tizot' ``` <!-- - Qu'observe-t-on sur les terminaux ? - Que peut-on en conclure ? => le souscripteur ne reçoit les messages que lorsqu'ils simultanément avec l'emetteur, il recoit autant de messages que de messages envoyés --> ## Etape 6 - Envoie de messages sur broker éteint Réitérer l'expérience : - Arrêter le __Broker__ - Renvoyer le message __ciao__ sur l'__Emetteur__ - Redémarrer le __Broker__ <!-- - Observation sur les terminaux `Souscripteur` et `Emetteur` l'emetteur attend de pouvoir établir une connection - Observation sur les terminaux. - Que peut on en conclure ? => dès que la communication est possible le message part, la publication est un appel bloquant --> ## Etape 7 - Messages retenus - Arrêter le souscripteur - Envoyer le message __Benvenuti__ en spécifiant qu'il doit être retenu par le broker (option __-r__) ```bash $ mqtt pub -t 'ciao' -h 'localhost' -m 'Benvenuti' -r ``` - Redémarrer à présent le souscripteur sur le topic __ciao__ - Renvoyer le message __Dai Dai__ sur le sujet __ciao__ - Arrêter et redémarrer le __Souscripteur__ - Arrêter le souscripteur puis le broker - Redémarrer le broker puis le souscripteur <!-- Redémarrer à présent le souscripteur sur le topic `ciao` - Qu'observe-t-on ? - Que peut on en conclure ? - Comment ça fonctionne ? Le précédent message est immédiatement envoyé au souscripteur Arrêter et redémarrer le `Souscripteur` - Qu'observe-t-on ? - Que peut on en conclure ? le nouveau message a remplacé l'ancien Redémarrer le broker puis le souscripteur - Qu'observe-t-on ? - Que peut on en conclure ? les informations du broker sont sauvegardées en mémoire vive --> <!-- Quelles avantages / inconvénients d'une solution avec ou sans message retenu ? pro: le souscripteur a tout de suite une info sans attendre qu'une prochaine arrive, cons: l'info est peut être erronée, il faut l'effacer pour que le message disparaisse Question subsidiaire : comment effacer le message retenu ? payload(0) = envoyer une chaine vide --> # Etude de cas _Ampoule allumée ou éteinte_ ![](https://i.imgur.com/athIhZK.jpg) ### On considère un dispositif suivant : - Un interrupteur commandé (relai) pour allumer ou éteindre une ampoule électrique - Un capteur pour vérifier si il y a du courant dans le circuit de l'ampoule - Un circuit électronique avec un micro-contrôlleur ### Trouver le ou les éléments qui permettent de : - Assurer le pilotage de l'interrupteur - Vérifier les données du capteur - Communiquer à un broker MQTT (via Ethernet ou WiFi) pour envoyer l'état de la lampe - Communiquer à un broker MQTT (via Ethernet ou WiFi) pour recevoir les commandes d'allumage et d'extinction <!-- Questions/Réponses - Décrire les messages entre le circuit et le broker - A quel moment sont ils envoyés ? -->