---
# System prepended metadata

title: FabLab projets
tags: [' mqtt', atelier]

---

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