TP03 : Station météo connectée

Dans ce laboratoire, nous introduisons une nouvelle dimension à notre station météo avec un module de communication ESP32. Le module de communication ESP32-WROOM-32 d’ESPRESSIF.

Le module de communication est un processeur de communication à part entière et monté sur sur un module Mikroe Wi-fi BLe click. Il est interfacé par deux UARTs (ports séries).

Le module ESP32 dispose de multiples fonctions de communication sans fil:

Bluetooth® selon Core Specification Version 5.0 :
- Bluetooth® classique ;
- Bluetooth® Low Energy.
Wi-Fi :
Gestion de la connection Wi-Fi ;
Programmation des addresses IP et MAC au niveau Ethernet ;
Fonctions TCP-IP ;
Liaison client HTTP ;
Fonctions MQTT directes (dans les modes “Publish” et “Subscribe”).

Les communications peuvent évidement, et le doivent dans un contexte d’application métier, être sécurisées via les protocoles SSL/TSL.

Note de version

Ce laboratoire nécessite une mise à niveau du module ESP32 en version 2.2.0.0.

La version 1.3.3.0 installée de base permet de faire les deux premières parties du laboratoire (partie Bluetooth® Low Energy) sans problème. Par contre pour la troisième partie MQTT, il faut impérativement passer à la version 2.2.0.0.

Un banc de mise à jour sera à disposition durant la 2e session de laboratoire pour effectuer cette mise à jour.

L’interface avec le module ESP32 se fait au travers de commandes de type AT. Les commandes AT de l’ESP32 sont regroupées sous ce lien pour la version 2.2.0.0.

Le système sera composé de deux appareils (deux cibles de laboratoire) :

une cible se charge de prendre les mesures environnementales et de les transmettre avec le BLE à la deuxième cible ;
une deuxième cible reçoit les mesures transmises par BLE et les affiche sur l’écran. Elle les transmets également à un broker MQTT via le Wi-Fi.

Schéma bloc

Objectifs du TP

Ce TP a pour but de mettre en pratique une communication BLE, une liaison Wi-Fi et une communication MQTT et d’en étudier les variantes fonctionnelles.

À la fin de ce TP, les étudiants :

auront intégré les composants de communication ESP32 (BLE, Wi-Fi, MQTT) à leur solution ;
auront intégré la transmission en mode connecté des données environnementales par BLE ;
auront intégré le scanning et l’advertising des modules BLE pour permettre la détection et la connexion ainsi que la transmission de données environnementales afin d’afficher ces données reçues sur un écran LCD ;
auront connecté la cible 2 à une routeur Wi-Fi et à un broker MQTT pour transmettre les données environnementales dans le cloud ;
auront utilisé des outils d’analyse et de test des communications (LightBlue pour le BLE Mobile, MQTT avec Wireshark et MQTTBox sous Chrome) ;
auront réalisé des analyses statiques de code et corrigé les erreurs rapportées ;
auront réalisé des tests de connectivité BLE relatifs à la portée ;
auront rédigé un journal de travail et déposé le PDF dans le dépôt git.

Les livrables sont :

un projet git (tp03) dans votre groupe sur gitlab.forge.hefr.ch avec le code du TP ;
un journal de travail déposé sur gitlab.

Temps accordé : 12 périodes de 45 minutes en classe (3 sessions de laboratoire) + travail personnel à la maison.

Délai

Le TP doit être rendu au plus tard 6 jours après la troisième séance en classe à 23:59.

Fonctionnement du système

Le logiciel de la cible 1 reprend la solution du tp02.

Un thread lit périodiquement les valeurs environnementales du capteur BME 280 et, en option, continue à afficher ces données sur le display LCD local.

Le mode d’acquisition urgente est remplacé par l’envoi d’un message BLE contenant les valeurs environnementales urgentes vers la cible 2 via BLE.

La led 4 bleue de la cible 1 flashe 100ms à chaque envoi de message BLE.

La cible 2 récupère via BLE les information environnementales.

La cible 2 affiche localement ces nouvelles valeurs environnementales sur le display LCD local. Un éventuel incrément sur l’affichage atteste de la bonne réception de nouvelles données.

Pour terminer, la cible 2 se connecte à un broker MQTT (mode Publisher) pour renvoyer une copie de ces données sur un broker MQTT via une connection Wi-Fi.

La led 4 bleue de la cible 2 flashe 100ms à chaque réception de message BLE et la led 3 rouge flashe 100ms à chaque envoi de message MQTT sur le broker.

Nous utiliserons alternativement un broker MQTT Eclypse Mosquitto en local votre machine de développement et un broker MQTT Adafruit dans le cloud.

Matériel

Pour ce laboratoire, vous avez besoin du module Mikroe Wi-fi BLe click que je vous conseille de placer sur le port click 1 (à gauche) sur les deux cibles.

Il vous faut également placé l’interrupteur de la carte de base Arduino Uno sur UART pour disposer des liaisons séries sur les modules click.

Nous avons besoin de 4 pins pour interfacer le module série sur le le port click 1 (à gauche) :

  CS  = PA_15;    // chip select at 1 at usage and 0 at startup
  RST = PC_4;     // chip select at 1 for reset and 0 at usage
  RX  = PG_9;     // serial receive
  TX  = PG_14;    // serial transmit

Ceci devra être adapté dans la solution proposé dans la classe click_board non fournie.

Le baudrate du module série est de 115‘200.

Note sur l’intégration du module

Mbed OS met à disposition une librairie complète d’intégration BLE. Cette structure nécessite l’écriture d’un pont logiciel HCI qui permet de nous abstraire de la complexité de développement et de maintenance d’une interface native en C++. Cette intégration est décrite dans la documentation Mbed OS sous l’api BLE.

Malheureusement notre module ne dispose pas encore de cette intégration et de ce fait nous allons rester au niveau de l’interface série et créer une librairie d’interaction qui répond aux besoins de notre laboratoire. Heureusement Mbed OS met à disposition un parseur de commandes AT qui nous sera bien utile et qui est relié à l’interface série buffer série.

La réalisation d’une classe d’intégration avec un parseur nécessite passablement de travail. C’est pourquoi, je vous proposer une version préliminaire qui réalise l’intégration de la partie BLE Publisher que vous pouvez directement intégrer, tester, étudier et modifier lors de la première séance de laboratoire. Cette classe Esp32 n’est pas complète et contient probablement encore des erreurs.

La documentation des commandes AT de l’ESP32 se trouvent sous ce lien et est indispensable à la compréhension des fonctions à intégrer. Elle doit être mise en relation avec la théorie du cours sur le BLE, le Wi-Fi et le MQTT.

Librairie de code

La librairie esp32 de base est disponible sous le fichier zip esp32.zip. Pour créer le tp03, vous pouvez dupliquer votre tp02 et y ajouter la classe Esp32 dans les librairies de votre nouveau projet tp03. Cette classe contient deux fichiers, esp32.hpp et esp32.cpp que nous allons analyser et intégrer.

Application mobile pour la mise au point du BLE

Vous aurez aussi besoin d’un outil pour tester votre application BLE. Je vous propose d’installer sur votre mobile l’application lightblue de la société PunchThrough qui est disponible sur App Store et Google Play.

Je vous ferais une rapide démonstration de cette application en début de laboratoire pour bien comprendre ce qui nous pouvons faire avec. Ceci reste plus efficace qu’une longue documentation insipide !

Planning

Laboratoire 1 : cible 1, publisher BLE

compréhension de la classe Esp32 ;
réalisation et intégration de la classe BlePublisher ;
tests et analyser de l’application sur la cible 1 à l’aide de l’application LightBlue.

Laboratoire 2 : cible 2, subscriber BLE

extension de la la classe Esp32 avec la fonction de BleSubscriber. Mise ;
mise en place de la cible 2 avec l’application subscriber BLE ;
tests et intégration des deux cibles.

Laboratoire 3 : cible 2, Wi-Fi et publisher MQTT

contenu à suivre !

Etude de la classe Esp32 de base.

Node sur les termes utilisés :

le slave/advertiser est aussi appelé Publisher dans le code et server dans la documentation des commandes AT.
le master/scanner est aussi appelé Subscriber dans le code et client dans la documentation des commandes AT.

L’étude de la classe Esp32 se fait en à l’aides des sources suivantes :

les commandes AT de l’ESP32 ;
la théorie du cours sur le BLE ;
le livre de référence “Getting Started with Bluetooth Low Energy”, Kevin Townsend, Carles Cufí, Akiba, Robert Davidson, O’Reilly Media, Avril 2014. Ce livre est en accès en ligne via le système des bibliothèques de la HES-SO.

Les points à observer, étudier et comprendre sont :

Pourquoi cette classe doit être créée sur le tas (heap) sur système pour garantir son bon fonctionnement ?
Le constructeur et l’utilisation des classes Mbed OS ATCmdParser et BufferedSerial.
La méthode Esp32::setATDebug qui permet de tracer dans le terminal les commandes AT pour la mise au point de votre code.
Les méthodes parlantes Esp32::getBleName, Esp32::getBleVersion, Esp32::getBleAddress qui donnent une première idée de l’utilisation du parseur de commandes AT.
La méthode Esp32::startBlePublisher qui permet de démarrer l’advertising du slave (Publisher) en attente de connexion en :
- initialisant le module BLE en mode slave (2: server role dans la documentation) ;
- donnant un nom spécifique au module BLE ;
- activant le service GATT qui publie le profil des fonctions disponibles ;
- enregistrant des méthode de callback sur la détection des interactions avec le master (ATCmdParser::oob) ;
- démarrant un thread d’interception des données entrantes sur le port série (Esp32::parseSubscriberCallback) pour permettre les callback ;
- et enfin démarrant l’advertising (Esp32::startBleAdvertising).
Les actions du master (Subscriber) sont capturée dans les méthodes sp32::callbackSubscriberConnect, Esp32::callbackSubscriberDisconnect, Esp32::callbackSubscriberRead() et Esp32::callbackSubscriberWrite(). Les données des actions read et write sont traitées dans :
- Esp32::subscriberRead qui n’est pas complété ici car pas utilisé dans notre application ;
- Esp32::subscriberWrite qui traite trois cas distincts :
  - l’écriture sur un profile GATT (ceci est observable avec l’application LightBlue) ;
  - l’enregistrement sur un profile GATT de notification que nous utiliseront pour publier les données environnementales (Esp32::notifyPublisherData) ;
  - l’enregistrement sur un profile GATT d’indication (notification avec quittance de réception) qui est implémenté pour information et tests avec l’application LightBlue.
La méthode Esp32::notifyPublisherData permet d’envoyer des données au master qui s’est connecté et enregistré pour la réception de données, le format transmis est libre et donc à convenir par les deux applications (dans notre cas trois données de type uint16_t).

Vous noterez également qu’il est possible d’enregistrer des méthodes utilisateur qui peuvent être appelées en deuxième niveau de callback pour un traitement personnalisé des commandes read, write, connect et disconnect (Esp32::attachSubscriberRead, etc.).

Vous disposez maintenant des élément essentiels nécessaires à la réalisation de votre application et à l’utilisation de cette classe Esp32 de base.

Publisher BLE sur la cible 1 (laboratoire 1)

Nous partons de l’idée que le mode urgent place les données environnementales dans une mailbox (ou tout autre objet partagé fonctionnellement équivalent) qui sert de point d’entrée de synchronisation à la classe BlePublisher pour l’envoie des données via BLE. Ceci relève du tp02 et n’est pas documenté plus avant ici.

Une fois la classe Esp32 bien comprise, il vous faut ajouter un objet BlePublisher et l’activer avec une méthode BlePublisher::startBlePublisher.

BlePublisher::startBlePublisher est donc une méthode qui :

crée l’objet new Esp32() impérativement sur le tas (heap) ;
démarre la notification slave du BLE : Esp32::startBlePublisher ;
démarre les deux threads décrits ci-après ;
récupère le nom du service (Esp32::getBleGATTService) et l’adresse (Esp32::getBleAddress) BLE nécessaire plus tard pour la réalisation du master.

BlePublisher::notifyPublisher est une méthode qui se synchronise sur, et vide continuellement (boucle sans fin), la mailbox, formate les données environnementales et les envoie avec la méthode Esp32::notifyPublisherData. Elle enregistre également un nouvel événement bleLedEventQueue_.call(callback(this, &BlePublisher::bleLedBlink)) pour faire flasher la led 4 bleu à chaque transmission BLE. Cette fonction est réalisée dans un thread spécifique.

BlePublisher::bleLedBlink est une méthode qui fait flasher la led 4 bleue à chaque envoi sur le BLE. Elle est réalisée par un thread qui traite en continue les événements d’une queue bleLedEventQueue_.

L’objet BlePublisher peut, en option, enregistrer des méthodes de callback appelée en cas d’actions read, write, connect, disconnect du master, exemple : Esp32::attachSubscriberRead(callback(this, &BlePublisher::bleSubscriberRead));, etc.

Test de la cible 1

Avant de réaliser la master (cible 2), nous pouvons tester le slave (cible 1) à l’aide de l’application Mobile LightBlue :

Filtrer la réception en -40dB et -50dB (4 bars) et placer votre téléphone tout près de votre module BLE afin de limité les détections parasites.

Sélectionnez votre device et connectez-vous. Observez bien l’affichage sur le terminal de la cible. vous pouvez également tester l’envoi et la lecture de messages ainsi que l’enregistrement et la réception des notifications.

Observer tout particulièrement le comportement de la notification en cas de connexion et de déconnexion du master (LightBlue) sur le slave (cible 1).

Ces fonctions et actions vous seront présentée en début de laboratoire.

A ce stade nous sommes prêts à attaquer la programmation de la cible 2 !

Subscriber BLE sur la cible 2 (laboratoire 2)

Le code de la cible 2 part du code de la cible 1 qui est modifié selon les indications de ce paragraphe.

Les fonctions à réaliser sont :

initialiser le module BLE en mode master/scanner (Subscriber) ;
connecter au slave/advertiser (Publisher - cible 1) ;
s’enregistrer pour obtenir les notifications du slave ;
récupérer les données environnementales à chaque notification du Publisher dans une nouvelle fonction de callback notify du slave;
afficher ces données environnementales sur le display du (Subscriber - cible 2).

Afin de détecter les notifications, à chaque réception d’une notification la led blue de la cible 2 flashe 100 ms.

Les commandes au module BLE du Subscriber sont calquées sur les commandes du module BLE du Publisher. Il vous faut vous référer à la documentation des commandes AT de l’ESP32 pour le détail.

L’initialisation du Subscriber consiste en :

initialiser le nodule en mode slave espParser_.send("AT+BLEINIT=1") && espParser_.recv("OK") et lui donner un nom espParser_.send("AT+BLENAME=\"%s\"", name) && espParser_.recv("OK") ;
ajouter une fonction de callback pour la notification espParser_.oob("+NOTIFY:", callback(this, &Esp32::callbackPublisherNotify)) ;
démarrer un thread d’interception des données entrantes sur le port série (parseClientCallBack_.start(callback(this, &Esp32::parsePublisherCallback))) pour permettre les callback. La méthode Esp32::parsePublisherCallback est calquée sur la méthode Esp32::parseSubscriberCallback du publisher.

La connexion BLE nécessite l’adresse BLE de la cible 1 et se fait par la commande espParser_.send("AT+BLECONN=0,\"%s\"", address) && espParser_.recv("OK").

Une fois connecté, vous pouvez rechercher les services et les caractéristiques disponibles sur le BLE de la cible 1. Pour cela vous devez utiliser les deux commandes AT suivantes que vous devez analyser et comprendre :

Esp32::discoverBleServices() : espParser_.send("AT+BLEGATTCPRIMSRV=0") && espParser_.recv("OK")
Esp32::discoverBleCharacteristics(uint16_t index) : espParser_.send("AT+BLEGATTCCHAR=0,%d", index) && espParser_.recv("OK"). L’index de service sera 3 dans notre cas pour découvrir la caractéristique 6 réalisant la notification.

Notez que la fonctions Esp32::discoverBleServices() ci-dessus est requise avant tout accès au Publisher alors que la fonction Esp32::discoverBleCharacteristics(uint16_t index) reste optionnelle. Ces fonctions n’affichent les valeurs de retour que dans le mode Esp32::setATDebug(true); sur le terminal par raison de simplification mais restent “muettes” en mode Esp32::setATDebug(false); elles sont utilisées pour explorer les services et leurs caractéristiques.

Ceci nous permet maintenant de nous enregistrer sur le Publisher pour recevoir les notifications. La méthode doit ressembler à quelque chose comme :

bool Esp32::notifyBleCharacteristic()
{
    smutex_.lock();
    if (espParser_.send("AT+BLEGATTCWR=0,3,6,1,2") && espParser_.recv(">"))
    {
        espParser_.putc(1);  // activate notify !
        espParser_.putc(0);
        espParser_.flush();
        espParser_.recv("OK");
        smutex_.unlock();
        return true;
    } else {
        smutex_.unlock();
        return false;
    }
}

A chaque notification, une méthode de réception proche du code de Esp32::publisherNotify donnée en exemple ci-dessous est automatiquement exécutée grace au callback :

bool Esp32::publisherNotify(){

    uint8_t char_index;
    uint8_t len;

    smutex_.lock();
    espParser_.recv("%hhd,%hhd,%hhd,%hhd,", &ble_conn_index_, &ble_srv_index_, &char_index, &len);

    uint8_t *data = (uint8_t *)malloc(len * sizeof(uint8_t));
    for (int i = 0; i < len; i++) {
        data[i] = espParser_.getc();
    }

    temperature = (data[1] << 8) + data[0];
    temperature = temperature / 100;
    humidity = (data[3] << 8) + data[2];
    humidity = humidity / 100;
    pressure = (data[5] << 8) + data[4];

    smutex_.unlock();
    free(data);
    return true;
}

Noter que dans la méthode Esp32::publisherNotify ci-dessus :

ble_conn_index_ est un attribut de la classe qui reçoit l’index de connexion ;
ble_srv_index_ est un attribut de la classe qui reçoit l’index du service traité ;
char_index est une variable locale qui reçoit l’index de la caractéristique traitée.

En attachant un deuxième niveau de callback à la notification (fonction Esp::attachPublisherNotify(your_bleNotify_action); à implémenter), vous pouvez lancer les opérations d’affichage local une fois de nouvelles données environnementales reçues.

Noter que les données environnementales reçues ci-dessus dans Esp32::publisherNotify devraient en principe être personnalisées dans your_bleNotify_action au deuxième niveau de callback. Pour réaliser ceci de manière générique, vous pouvez utiliser l’API Span qui est partagé entre le premier callback Esp32::publisherNotify qui extrait les données reçues par la notification dans un nouvel objet Span générique et le deuxième callback your_bleNotify_action qui extrait les données de manière spécifique (données environnementales) et détruit l’objet Span. Le Span est partagé en paramètre entre les deux callback.

Vous disposez maintenant des données environnementales sur la cible 2 et il vous reste à mettre en forme le tout afin d’obtenir une application propre et fonctionnelle sur la cible 2 !

Vous trouverez encore ci-après une trace de l’initialisation de la cible 2. Vous noterez principalement les temps de pause nécessaires entre les actions afin de laisser les temps des traitements intermédiaires.

bleLedThread.start(callback(&bleLedEventQueue, &EventQueue::dispatch_forever));

// esp.setATDebug(true);
if (!esp.restore()) tr_debug("ESP restore error !");
ThisThread::sleep_for(2s);
if (!esp.initBleSubscriber("ESP_Client")) tr_debug("BLE init error !");
ThisThread::sleep_for(1s);
if (!esp.connectBlePublisher("ec:94:cb:7d:ed:ee")) tr_debug("BLE connect error !");
ThisThread::sleep_for(1s);
esp.setATDebug(true);
if (!esp.discoverBleServices()) tr_debug("BLE service discovery error !");
ThisThread::sleep_for(1s);
if (!esp.discoverBleCharacteristics(3)) tr_debug("BLE char discovery error !");
ThisThread::sleep_for(1s);
esp.setATDebug(false);
if (!esp.notifyBleCharacteristic()) tr_debug("BLE registre notify error !");
esp.attachPublisherNotify(bleNotify);
// esp.setATDebug(false);

Avec la fonction Esp32::restore() suivante qui permet de réinitialiser le module ESP32 :

bool Esp32::restore()
{
    smutex_.lock();
    espParser_.send("AT+RESTORE");
    if (espParser_.recv("OK")) {
        smutex_.unlock();
        return true;
    } else {
        smutex_.unlock();
        return false;
    }
}

Publisher MQTT sur la cible 2 (laboratoire 3)

Outils MQTT

Nous allons utiliser quelques outils dans ce laboratoire 3 pour visualiser les échanges et les messages MQTT entre notre Publisher de la cible 2, les différents Brokers et les clients de test et visualisation.

Broker local : mosquitto sur votre laptop (localhost) y compris des outils en ligne de commande tel que mosquitto_pub.
Note

Pour accéder à votre mosquitto local depuis l’extérieur (hors localhost) et sans mot de passe, il vous faut adapter le fichier mosquitto.conf (répertoire /usr/local/etc/mosquitto sous mac osx, /etc/mosquitto sur Linux, et _c:\mosquitto_ sur Windows) avec les deux lignes suivantes :
```
listener 1883 0.0.0.0
allow_anonymous true
```
Clients : MQTTBox sur Google Chrome ou MQTT Explorer.
Dashboard : Adafruit avec son Broker selon la configuration ci-dessous.
Analyseur de protocole : Wireshark.

Ces outils nous permettrons de tester et valider notre système pas-à-pas.

Le Dashboard Adafruit

Afin de simplifier la visualisation, nous utilisons le dashboard offert par Adafruit. Rendez-vous sur io.adafruit.com et cliquez sur “Get Started for Free”¹ en haut à droite.

Créez un nouveau dashboard en cliquant sur “+ New Dashboard”

Dans votre nouveau dashboard, ajoutez un bloc, par exemple une gauge, pour représenter l’humidité :

Configurez le bloc pour l’humidité :

Créez ensuite un nouveau feed pour l’humidité :

Et connectez ce feed à votre bloc

Vous pouvez obtenir les détails d’un feed en cliquant sur “feed info”

Le feed peut recevoir des données par une connextion Web ou MQTT. Cette page vous indique le topic MQTT correspondant à votre feed.

Obtenez encode une clé en cliquant sur “My Key”

Testez maintenant l’envoi d’une valeur sur le feed que vous avez créé à l’aide de MQTT Explorer ou en ligne de commande :

mosquitto_pub \
  -h io.adafruit.com \
  -p 1883 \
  -u <VOTRE USERNAME (par ex. myname)> \
  -P <VOTRE CLE> \
  -t <VOTRE FEED (par ex. myname/feeds/humidity)> \
  -m 42

La gauge de votre dashboard devrait maintenant indiquer 42 :

Complétez le dashboard avec un bloc pour la température et un bloc pour la pression atmosphérique.

Notez que vous pouvez très bien configurer deux blocs avec le même feed. Expérimentez avec une mesure donnée (par exemple la température sur une gauge et sur un graph).

Réalisation du Publisher MQTT

MQTT nécessite une connection Wi-Fi. Nous reprenons l’intégration Wi-Fi du TP04 comme base de connection à Internet.

Les commandes MQTT à intégrer à la classe ESP32 sont décrites sous MQTT_AT_Commands.

Le code d’intégration des deux commandes nécessaires au laboratoire vous est donné ci-après :

bool Esp32::mqttConnectBroker(const char* host, int port, const char* id,
                              const char* user, const char* pwd)
{
    smutex_.lock();
    setATDebug(true);
    esp_parser_.send("AT+MQTTUSERCFG=0,1,\"%s\",\"%s\",\"%s\",0,0,\"\"", id, user, pwd);
    esp_parser_.recv("OK");
    esp_parser_.send("AT+MQTTCONN=0,\"%s\",%d,1", host, port);
    if (esp_parser_.recv("OK")) {
        setATDebug(false);
        smutex_.unlock();
        return true;
    } else {
        setATDebug(false);
        smutex_.unlock();
        return false;
    }
}

bool Esp32::mqttPublish(const char* topic, const char* data, uint8_t qos, uint8_t retain)
{
    smutex_.lock();
    esp_parser_.send("AT+MQTTPUB=0,\"%s\",\"%s\",%d,%d", topic, data, qos, retain);
    if (esp_parser_.recv("OK")) {
        smutex_.unlock();
        return true;
    } else {
        smutex_.unlock();
        return false;
    }
}

Vous pouvez maintenant intégrer la partie MQTT sur la cible 2 et la tester sur votre broker MQTT local mosquitto et un client local de visualisation.

Attention de réaliser une intégration propre et fonctionnelle.

Vous pouvez encore ajouter la fonction Last Will and Testament en implémentant la fonction AT Configuration of MQTT Connection dans votre ESP32.

Test de la cible 2

Les données reçues par BLE de la cible 1 sont affichées localement et retransmises via MQTT sur le broker local mosquitto ou affichées sur le Daskboard adafruit selon votre choix de broker.

Analyse du protocole MQTT et test des fonctions spéciales

Avec Wireshark et une connection sur le broker local mosquitto, vous pouvez analyser et tracer les différences du protocole MQTT dans les 3 configurations de qos.

Vous pouvez aussi tester avec un client local les options Last Will and Testament et retain sur le broker local mosquitto.

Tests et validations

Tester automatiquement un tel système est difficile avec l’infrastructure de l’école. Pour ce TP, vous ne testerez donc pas de code automatiquement sur la cible d’un runner gitlab.

Par contre, vous allez configurer l’analyse statique de code de manière plus stricte.

Dans le fichier .gitlab-ci.yml, configurez l’analyse statique pour alerter lors de problèmes de niveau low. Ajoutez pour cela l’option --fail-on-defect=low à la commande pio check:

check-job:
  stage: check
  script:
    - pio run -e DISCO_F
    - pio check -e DISCO_F --skip-packages --fail-on-defect=low
    - pio test --without-uploading --without-testing

À ne pas oublier

Gardez toujours en têtes les bonnes pratiques ainsi que les dix commandements du bon programmeur.

Choisissez de bons noms pour les classes, les méthodes et les variables.
Implémentez les bibliothèques avec un haut niveau d’abstraction pour pouvoir réutiliser les méthodes dans d’autres projets.
Faites des “git commit” régulièrement avec de bons commentaires.
Configurez le CI/CD de gitlab et testez automatiquement le plus de choses possibles.
Implémentez des tests unitaires.
Utilisez des assertions dans votre code pour le documenter et le rendre plus robuste.

Journal de travail

Rédigez un rapport (journal de travail) avec les indications suivantes :
Une page de titre avec au minimum :
- le nom et le logo officiel de l’école
- le nom du cours : Informatique Embarquée
- le titre de votre document : Travail Pratique 3 : Station météo connectée
- le numéro de votre groupe
- les noms des auteurs (vous) avec la classe dans laquelle vous êtes
- la date à laquelle vous avez terminé le rapport
- éventuellement la version du rapport
Une introduction pour poser le contexte
Un résumé des notions que vous avez apprises pendant ce TP en précisant si c’est
- non acquis
- acquis, mais encore à exercer
- parfaitement acquis
Un résumé des points qui vous semblent importants et que vous devez retenir
Les réponses aux questions.
Le code source bien formaté et avec du “syntax highlighting” de votre code source.
Une conclusion par laquelle vous donnez vos impressions sur le TP, ce que vous avez aimé, ce que vous avez moins aimé, et éventuellement des suggestions pour des changements. Indiquez également le nombre d’heures que vous avez passées, par personne, en dehors des heures de TP en classe.

Important

Déposez votre rapport dans un dossier /docs de votre dépôt git (tp03) avec le nom report03.pdf (le chemin complet vers votre rapport est donc /docs/report03.pdf)

Cliquez sur “Sign In” si vous avez déjà un compte. ↩