---
title: FabLab projets
tags: atelier, mqtt
robots: noindex, nofollow
author: Damien Truffaut, Julien Noyer
---
# Protocole MQTT _Communication entre objets_

<!-- 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_

### 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_

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_

### 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 ?
-->