1. Suivre une mesure de l’ESP32 au récepteur

Télécharger le projet, les exercices et les corrections (ZIP, v0.2.2)

Leçon 1 Suivre une mesure de l’ESP32 au récepteur

Des cubes jaunes représentent les mesures transmises par un ESP32 vers un récepteur.
Vue conceptuelle du trajet des mesures. Dans ce laboratoire, le récepteur est un programme sur votre ordinateur.

Le terminal affiche MQTT connected. Quelques secondes plus tard, des valeurs commencent à défiler. Le premier échange fonctionne.

Gardons maintenant une trace de ce qui se passe. Si une valeur manque à l’arrivée, nous aurons besoin de savoir si la carte l’a produite, si le programme a tenté de l’envoyer et si le récepteur l’a enregistrée. Ces trois observations vont nous servir pendant tout le parcours.

Dans cette leçon, vous allez lancer le projet fourni, retrouver une même mesure dans deux captures et modifier sa fréquence de production. La coupure réseau viendra dans la leçon suivante. Pour l’instant, nous établissons un fonctionnement de référence.

Préparer le poste

Il vous faut une carte ESP32, un câble USB qui transporte les données, un ordinateur et un réseau Wi-Fi 2,4 GHz. Le programme fabrique ses valeurs lui-même : aucun capteur à brancher.

Le projet utilise ESP-IDF et un serveur MQTT local, Mosquitto. Suivez la fiche Installation du laboratoire pour installer les outils, renseigner le réseau et compiler le programme. La fiche détaille l’installation sur macOS, Windows et Ubuntu/Debian. Choisissez la cible de votre carte : esp32 pour l’ESP32 classique, esp32s3 pour la S3-DevKitC-1, branchée sur UART. Si ESP-IDF n’est pas encore installé, commencez par cette fiche avant de poursuivre la leçon.

Vous pouvez suivre l’exercice avec les notions des premiers cours C : variables, conditions, boucles et fonctions. Le projet contient aussi des tâches FreeRTOS. Nous les utiliserons sans vous demander d’en maîtriser toute l’architecture dès cette première étape.

Le trajet de la mesure

L’ESP32 fabrique une valeur, lui ajoute quelques informations et publie le tout dans le topic pvt/lab/board01/telemetry. Mosquitto reçoit le message et le transmet au programme abonné à ce topic. Ce programme tourne sur votre ordinateur et écrit les messages dans un fichier.

Un topic est un nom utilisé pour publier et sélectionner des messages. Celui-ci ne correspond à aucun dossier sur le disque. Pour recevoir les valeurs du projet, le récepteur doit s’abonner au même nom.

Voici un message d’exemple, construit pour expliquer le format :

{"device":"aabbccddeeff","boot":"0123456789abcdef","seq":17,"uptime_ms":22100,"value":207}

value contient la valeur de démonstration, sans unité physique. seq est son numéro : la première mesure porte le numéro 1, la suivante le numéro 2, et ainsi de suite.

uptime_ms donne le temps écoulé depuis le démarrage de la carte, en millisecondes. Ce n’est pas une date. device identifie la carte et boot distingue deux démarrages. Après un reset, le compteur seq repart à 1 ; le nouveau boot permet d’éviter de confondre deux mesures issues de deux exécutions différentes.

Pour reconnaître une mesure, nous utiliserons donc l’ensemble device, boot et seq.

Lancer la première capture

Dans la configuration du projet, laissez la période à 1000 ms, le nombre de mesures à 60 et le déclenchement de coupure à 0. Laissez aussi Keep unsent samples in a bounded RAM buffer (lesson 3) désactivé. La carte doit rester connectée pour cette première expérience.

Lancez Mosquitto, puis le récepteur avec l’adresse IP locale de votre ordinateur. Dans les commandes ci-dessous, 192.168.1.10 est un exemple à remplacer.

python tools/capture_mqtt.py --host 192.168.1.10 --out captures/received-01.jsonl

Attendez la ligne READY. Elle indique que le serveur a accepté l’abonnement du récepteur.

Ouvrez ensuite le moniteur série depuis le terminal ESP-IDF :

idf.py -p PORT monitor

Remplacez PORT par le port de votre carte. Activez l’enregistrement avec Ctrl+T, puis Ctrl+L. Le moniteur affiche le nom du fichier créé. Appuyez ensuite sur le bouton EN ou RESET de la carte pour enregistrer une exécution complète dès le début.

Laissez le programme aller jusqu’à PRODUCTION_DONE, puis attendez encore dix secondes. Arrêtez le récepteur avec Ctrl+C et quittez le moniteur avec Ctrl+]. Gardez les deux fichiers de cette exécution.

Si une première exécution a démarré pendant vos manipulations, vous verrez plusieurs identifiants boot. Le comparateur les traite séparément. Retenez celle que vous avez enregistrée entièrement.

Retrouver une mesure des deux côtés

Dans le fichier série, cherchez une ligne contenant "event":"produced". Le programme l’écrit lorsqu’il crée une mesure. Relevez son boot et son seq, puis cherchez les mêmes valeurs dans le fichier du récepteur.

La ligne série publish_returned a un autre sens : l’appel de publication est revenu sans signaler d’échec. Avec le QoS 0 utilisé ici, elle ne prouve pas que le récepteur a reçu le message. La capture du récepteur apporte cette observation supplémentaire.

Comparez maintenant les captures avec l’outil fourni. Remplacez FICHIER_SERIE par le chemin affiché par le moniteur.

python tools/compare.py --serial FICHIER_SERIE --received captures/received-01.jsonl --first 10 --last 29

Nous regardons les numéros 10 à 29 inclus, soit vingt mesures. Cette fenêtre écarte le tout début et la fin de l’enregistrement. Pour une exécution entièrement capturée et sans perte dans cette fenêtre, le résultat doit contenir produced_unique: 20, matched_unique: 20 et une liste missing_at_receiver vide.

Si ce n’est pas le cas, gardez le résultat. Vérifiez d’abord que les fichiers correspondent à la même exécution et que le récepteur est resté connecté. Une absence dans sa capture ne suffit pas à localiser la perte. Le champ received_without_production_log, lui, signale des messages reçus dont la production n’apparaît pas dans le fichier série.

Modifier la fréquence

Ouvrez idf.py menuconfig, puis ParlezVousTech MQTT lab. Passez Sample period in milliseconds de 1000 à 500. Gardez soixante mesures et la coupure désactivée. Recompilez, flashez et recommencez avec un nouveau fichier de réception, par exemple captures/received-02.jsonl.

La séquence va toujours de 1 à 60, mais les valeurs doivent arriver plus vite. Pour mesurer ce changement, utilisez uptime_ms : l’écart entre deux mesures successives doit être proche de 500 ms. Le temps d’affichage dans le terminal inclut aussi le transport et l’ordonnancement de l’ordinateur.

Prenez les mesures 10 et 29. Il y a dix-neuf intervalles entre elles. Calculez :

période moyenne = (uptime_ms de la mesure 29 - uptime_ms de la mesure 10) / 19

Vous devriez obtenir une valeur proche de 500 ms, contre environ 1000 ms dans la première exécution. Ces valeurs sont des objectifs de cadence ; le programme ne constitue pas un instrument de mesure du temps réel.

Comprendre les valeurs du projet

La valeur de démonstration est calculée dans main/sample.c :

return 200 + (int32_t)(seq % 10U);

L’opérateur % donne le reste de la division entière. Pour seq = 1, la valeur vaut 201. Pour seq = 10, elle revient à 200. La série se répète et permet de vérifier facilement ce que l’on reçoit.

En exercice supplémentaire, remplacez 200 par 300, puis vérifiez les mesures 1 et 10 dans les deux captures. Vous devez retrouver respectivement 301 et 300. Remettez ensuite le code initial et la période à 1000 ms pour préparer la suite.

Vous pouvez demander à une IA de vous expliquer cette ligne ou de proposer une modification. Avant de compiler, écrivez les deux valeurs que vous attendez. Les captures permettront de vérifier la proposition.

Vérifier que le résultat est compris

Expliquez avec vos mots ce qui distingue produced, publish_returned et un enregistrement received. Retrouvez ensuite une mesure précise dans les deux fichiers. Enfin, expliquez pourquoi le numéro seq ne suffit plus si la carte redémarre.

La réponse attendue tient en quelques phrases : produced atteste la création dans le programme ; publish_returned décrit le retour de l’appel MQTT ; received atteste l’observation par notre récepteur. Le même numéro peut réapparaître après un reset, d’où l’identifiant boot associé à la carte.

Le laboratoire est prêt pour la suite lorsque vous savez faire cette correspondance et vérifier le changement de cadence. Dans la prochaine leçon, la carte continuera à produire ses valeurs pendant que son Wi-Fi sera coupé. Nous regarderons ce que le récepteur retrouve après la reconnexion.

Références

Installer le laboratoire ESP32 et MQTT

Installation : macOS · Windows · Ubuntu/Debian

À la fin de cette fiche, vous aurez les outils de compilation, un port série identifié et un récepteur MQTT prêt à enregistrer les mesures. Suivez uniquement la branche correspondant à votre système, puis reprenez les étapes communes. Copiez les commandes une par une et attendez leur fin. Si une commande échoue, corrigez cette étape avant de poursuivre.

ESP-IDF est le logiciel de développement d’Espressif à installer sur l’ordinateur. La carte se branche en USB. Mosquitto reçoit ses messages MQTT ; un petit programme Python les enregistre. Aucun capteur externe n’est nécessaire : le firmware produit les valeurs de l’exercice.

1. Préparer la carte et le dossier du projet

Il faut une carte de développement ESP32, un câble USB de données, un ordinateur et un réseau Wi-Fi 2,4 GHz. L’ordinateur peut utiliser le Wi-Fi ou Ethernet, mais il doit pouvoir communiquer avec la carte sur le réseau local. Un réseau invité qui isole les appareils ne convient pas.

Utilisez une carte dédiée à l’exercice : le flashage remplacera son application et peut remplacer des données présentes dans ses partitions.

Carte Cible ESP-IDF à sélectionner plus loin Branchement retenu
ESP32 classique, module ESP32-WROOM-32/32E esp32 Port USB de programmation de la carte
ESP32-S3-DevKitC-1 esp32s3 Port UART / USB-to-UART

Sur la S3-DevKitC-1, le port UART passe par un convertisseur USB-série. L’autre port, marqué USB, est relié à l’USB natif du S3. Pour cette procédure, branchez un seul câble sur UART : il alimente la carte, permet de la flasher et de lire les logs. Les indications S3 préparent l’essai ; elles ne remplacent pas la validation physique du parcours sur cette carte. Les variantes C3 ne sont pas couvertes par cette fiche.

Téléchargez le ZIP proposé en haut de la leçon et extrayez-le. Placez le dossier contenant CMakeLists.txt, main, tools et requirements.txt ici :

  • macOS/Linux : ~/esp/pvt-esp32-mqtt-lab ; ~ désigne votre dossier personnel.
  • Windows : C:\esp\pvt-esp32-mqtt-lab.

Évitez les espaces et accents dans le chemin. Vérifiez qu’il n’y a pas un second dossier du même nom à l’intérieur. Ne travaillez pas directement dans le ZIP. Le dossier du cours et celui d’ESP-IDF sont deux dossiers distincts.

2. Installer ESP-IDF 5.5.5

Sur macOS

Ouvrez Terminal depuis Applications → Utilitaires. Vérifiez les outils Apple :

xcode-select -p

Si un chemin s’affiche, continuez. Si les outils sont absents, lancez la commande suivante, terminez l’installation dans la fenêtre Apple, puis recommencez la vérification :

xcode-select --install

Vérifiez ensuite Homebrew :

brew --version

Si la commande est introuvable, ouvrez brew.sh, utilisez l’installation officielle, puis exécutez les commandes indiquées dans Next steps à la fin. Elles rendent brew accessible dans le terminal. Ouvrez un nouveau terminal et vérifiez de nouveau. Consultez les versions de macOS prises en charge sur cette page si votre système est ancien ; ne forcez pas une installation signalée comme non prise en charge.

Installez les outils. Python 3.12 est choisi explicitement pour garder un environnement cohérent :

brew install git cmake ninja dfu-util python@3.12 mosquitto
export PATH="$(brew --prefix python@3.12)/libexec/bin:$PATH"
python3 --version

La dernière commande doit afficher Python 3.12.x, où x est le numéro de correction. Cette modification de PATH ne concerne que le terminal ouvert. Continuez avec « Télécharger et activer ESP-IDF » ci-dessous.

Sur Ubuntu ou Debian

Ouvrez un terminal. Installez les dépendances et Mosquitto avec le gestionnaire de paquets de votre distribution :

sudo apt update
sudo apt install git wget flex bison gperf python3 python3-pip python3-venv cmake ninja-build ccache libffi-dev libssl-dev dfu-util libusb-1.0-0 build-essential mosquitto
python3 --version

Le récepteur du cours demande Python 3.10 ou supérieur. Si votre distribution fournit une version plus ancienne, utilisez une version de distribution prise en charge avec un Python adapté, sans remplacer son Python système à la main. La procédure de paquets ci-dessus concerne Ubuntu/Debian ; les autres distributions ont leurs propres noms de paquets.

Télécharger et activer ESP-IDF : macOS et Linux

Dans le même terminal, téléchargez la version fixée pour le cours :

mkdir -p ~/esp
cd ~/esp
git clone --branch v5.5.5 --recursive https://github.com/espressif/esp-idf.git esp-idf-v5.5.5
cd ~/esp/esp-idf-v5.5.5
./install.sh esp32,esp32s3

Le téléchargement inclut les sous-modules ; l’installation ajoute les compilateurs et les dépendances Python d’ESP-IDF. Attendez sa fin sans erreur. Si esp-idf-v5.5.5 existe déjà, ne le supprimez pas pour recommencer : vérifiez d’abord s’il contient votre installation 5.5.5.

Activez ensuite cet environnement :

. "$HOME/esp/esp-idf-v5.5.5/export.sh"
idf.py --version

Le résultat attendu est ESP-IDF v5.5.5. Le point initial, suivi d’un espace, charge les outils dans le terminal courant. À chaque nouveau terminal de compilation, relancez la ligne export.sh. Sur Mac, si elle ne trouve pas le bon Python, reprenez d’abord la ligne export PATH de la section macOS. Gardez ce terminal ouvert : ce sera le terminal A.

Sur Windows 10/11

  1. Ouvrez la page officielle des installateurs ESP-IDF 5.x. Choisissez ESP-IDF v5.5.5 – Offline Installer. Le numéro du framework doit être 5.5.5 ; le numéro d’un installateur universel est une autre chose.
  2. Lancez l’installateur. Utilisez des chemins courts sans espace ni accent, par exemple C:\Espressif. Conservez les outils proposés, dont Python, Git, CMake et Ninja. Si une sélection de cibles apparaît, incluez ESP32 et ESP32-S3.
  3. À la fin, ouvrez ESP-IDF PowerShell Environment. Vous pourrez le retrouver par le raccourci ESP-IDF du menu Démarrer. Un PowerShell ordinaire ne charge pas automatiquement les outils.
  4. Dans cette fenêtre, vérifiez :
idf.py --version
python --version

Vous devez obtenir ESP-IDF v5.5.5 et un Python 3.10 ou supérieur pour utiliser aussi le récepteur du cours. Gardez cette fenêtre comme terminal A. Si vous avez déjà plusieurs versions d’ESP-IDF, utilisez le raccourci correspondant à 5.5.5.

Installez ensuite Mosquitto depuis sa page officielle avec l’installateur Windows adapté. Pour ce laboratoire, lancez-le dans un terminal ; n’ajoutez pas de service automatique si l’installateur propose ce choix. Avec le chemin d’installation habituel, vérifiez dans PowerShell :

& 'C:\Program Files\mosquitto\mosquitto.exe' -h

L’aide doit afficher une version 2.x. Adaptez le chemin si vous avez choisi un autre dossier. Dans les commandes du reste du cours, remplacez alors mosquitto par & 'C:\Program Files\mosquitto\mosquitto.exe'. Le signe & permet à PowerShell d’exécuter un programme dont le chemin est entre guillemets.

3. Identifier le port USB avant de compiler

Commencez carte débranchée. Dans le terminal A, lancez :

python -m serial.tools.list_ports

Branchez maintenant la carte avec le câble de données, sur UART pour la S3-DevKitC-1, puis relancez la même commande. Repérez le port ajouté :

Système Exemples de noms possibles
macOS /dev/cu.SLAB_USBtoUART, /dev/cu.usbserial-…
Linux /dev/ttyUSB0
Windows COM5 ; visible aussi dans Gestionnaire de périphériques → Ports (COM et LPT)

Ces noms sont des exemples. Notez votre port : il remplacera PORT dans les commandes. Ne choisissez pas un port Bluetooth. Si aucun port n’apparaît, essayez un câble de données connu, une connexion directe à l’ordinateur et le bon connecteur de la carte. Une LED allumée prouve seulement que la carte est alimentée.

Si le périphérique USB est détecté mais qu’aucun port série n’est créé, identifiez son convertisseur et consultez le guide des pilotes série Espressif. Installez uniquement le pilote correspondant, depuis son fabricant. Ne changez pas les protections du système pour contourner une erreur de pilote.

4. Préparer les trois terminaux

On garde trois fenêtres séparées pour voir ce qui se passe à chaque endroit :

Terminal Rôle Environnement
A – Carte Compiler, flasher, puis lire et enregistrer le port série ESP-IDF 5.5.5
B – Récepteur Enregistrer les messages MQTT dans un fichier Environnement Python .venv du projet
C – Broker Laisser tourner Mosquitto Mosquitto ; .venv seulement pour créer sa configuration

Placez chaque terminal à la racine du projet :

macOS/Linux :

cd ~/esp/pvt-esp32-mqtt-lab

Windows PowerShell :

cd C:\esp\pvt-esp32-mqtt-lab

Dans B, créez l’environnement du récepteur une seule fois, en choisissant la commande de votre système :

macOS, dans un nouveau Terminal où brew est disponible :

"$(brew --prefix python@3.12)/bin/python3.12" -m venv .venv
. .venv/bin/activate

Linux :

python3 -m venv .venv
. .venv/bin/activate

Windows : ouvrez un second ESP-IDF PowerShell, rejoignez le dossier du projet, puis lancez :

python -m venv .venv
.\.venv\Scripts\Activate.ps1

Si PowerShell refuse le script d’activation, gardez sa politique actuelle et utilisez directement .\.venv\Scripts\python.exe à la place de python pour les commandes du récepteur. La création de .venv doit néanmoins avoir réussi.

Dans B, installez puis vérifiez la dépendance :

python -m pip install -r requirements.txt
python -c "from importlib.metadata import version; print(version('paho-mqtt'))"

La dernière commande doit afficher 2.1.0. Un message No module named paho indique souvent que la commande utilise un autre Python que celui de .venv. N’activez pas .venv dans A : ce terminal doit garder l’environnement ESP-IDF.

Dans C, ouvrez un terminal à la racine du projet, activez le même .venv avec la commande de votre système, puis vérifiez Mosquitto :

mosquitto -h

Sous Windows, utilisez le chemin PowerShell donné plus haut. L’aide doit indiquer 2.x. Notez la version utilisée pour les essais ; le contrôle logiciel précédent a été exécuté avec 2.0.22. Ne démarrez pas encore une seconde instance si un broker utilise déjà le port 1883.

5. Démarrer le broker local

Relevez l’adresse IPv4 privée de l’ordinateur dans les paramètres réseau. Elle ressemble par exemple à 192.168.1.10. Ce doit être l’adresse du réseau utilisé par la carte. Ne renseignez pas localhost dans le firmware : sur l’ESP32, ce nom désignerait l’ESP32 lui-même.

Sur Mac, trouvez cette adresse dans Réglages Système → Réseau → votre connexion → Détails → TCP/IP. Sous Windows, lancez ipconfig et relevez l’IPv4 de votre connexion Wi-Fi ou Ethernet. Sous Linux, utilisez ip -4 addr et relevez celle de l’interface utilisée. Écartez les interfaces VPN et virtuelles.

Dans le terminal C, depuis la racine du projet, créez la configuration et lancez le broker. Remplacez l’adresse d’exemple dans les deux étapes de configuration du laboratoire.

python tools/configure_broker.py --ip 192.168.1.10
mosquitto -c broker/mosquitto.conf -v

Ce broker d’exercice écoute seulement sur l’adresse indiquée, avec accès anonyme et sans TLS. Il sert uniquement à transporter les données fictives de ce laboratoire sur un réseau de confiance isolé. N’ouvrez pas le port 1883 sur Internet et n’y envoyez aucune donnée privée. Le déploiement réel demandera notamment authentification, droits d’accès et TLS, traités dans le parcours gratuit.

Le pare-feu de l’ordinateur doit autoriser l’ESP32 à atteindre ce port sur le réseau privé. Si un autre Mosquitto utilise déjà le port, utilisez cette instance après en avoir vérifié la configuration ou arrêtez votre instance de test précédente. Le script refuse d’écraser broker/mosquitto.conf ; éditez ce fichier si l’adresse de l’ordinateur change.

6. Choisir la cible et compiler le firmware

Dans le terminal A, à la racine du projet, choisissez une seule de ces commandes :

Pour l’ESP32 classique :

idf.py set-target esp32

Pour l’ESP32-S3-DevKitC-1 :

idf.py set-target esp32s3

Puis ouvrez la configuration :

idf.py menuconfig

set-target réinitialise la configuration et le dossier de compilation : faites-le avant les réglages Wi-Fi. Ne lancez pas les deux commandes à la suite. Un simple changement de cadence demande seulement menuconfig, puis une recompilation. Utilisez les flèches et Entrée pour naviguer ; Espace coche ou décoche une option. Dans ParlezVousTech MQTT lab, renseignez :

Réglage Valeur de départ
Keep unsent samples in a bounded RAM buffer (lesson 3) Désactivé pour les leçons 1 et 2
RAM buffer capacity in samples 64, utilisé en leçon 3
Wi-Fi SSID et Wi-Fi password Le réseau 2,4 GHz de l’exercice
Local broker URI mqtt://192.168.1.10:1883, avec l’adresse réelle de l’ordinateur
Telemetry topic pvt/lab/board01/telemetry
Sample period in milliseconds 1000
Number of samples per run 60
Disconnect Wi-Fi this many seconds after sampling starts 0
Duration of the deliberate Wi-Fi disconnection in seconds 30

Pour le port UART retenu ici, gardez la console sur UART0 (CONFIG_ESP_CONSOLE_UART_DEFAULT). Enregistrez avec S, confirmez le fichier sdkconfig, puis quittez avec Q. Compilez :

idf.py build

Les identifiants Wi-Fi sont intégrés au firmware et présents dans sdkconfig. Gardez ce fichier et vos binaires privés. L’archive de départ n’en contient pas.

Attendez la fin sans erreur et le message Project build complete. Cette étape valide la compilation pour la cible choisie ; elle ne prouve pas encore que la carte communique. Le projet n’utilise aucun GPIO externe ni PSRAM.

7. Flasher et enregistrer une première exécution

Dans A, remplacez PORT par le port relevé à l’étape 3, sans chevrons, puis flashez :

idf.py -p PORT flash

Lancez le récepteur dans son terminal :

python tools/capture_mqtt.py --host 192.168.1.10 --out captures/received-01.jsonl

Après READY dans B, ouvrez le moniteur dans A :

idf.py -p PORT monitor

Le moniteur réinitialise généralement la carte à l’ouverture. Activez le fichier de log avec Ctrl+T puis Ctrl+L, relevez son chemin, puis appuyez sur EN ou RESET. Cette nouvelle exécution sera enregistrée dès le début. La production commence trois secondes après la première connexion MQTT et s’arrête après soixante mesures.

Pour quitter le moniteur, utilisez Ctrl+] ; si ce raccourci est difficile sur votre clavier, Ctrl+T puis Ctrl+X. Arrêtez le récepteur avec Ctrl+C lorsque l’essai est terminé.

Le récepteur refuse d’écraser un fichier existant. Choisissez un nom différent à chaque essai. Suivez ensuite la première leçon.

8. Si une étape bloque

Si aucun port n’apparaît, essayez un câble USB de données connu et vérifiez le pilote de l’interface USB de votre carte. Si la connexion Wi-Fi échoue, vérifiez le SSID, le mot de passe et la bande 2,4 GHz.

Si le Wi-Fi obtient une adresse mais que MQTT reste indisponible, vérifiez l’adresse du broker, son terminal, le pare-feu et l’isolation éventuelle entre appareils. Un READY côté récepteur confirme son abonnement ; il ne confirme pas la connexion de l’ESP32.

Si le fichier série contient la production mais que le fichier de réception reste vide, comparez le topic configuré sur la carte avec celui du récepteur. Conservez les logs pendant le diagnostic.

Symptôme Vérification utile
idf.py: command not found Rechargez export.sh dans A, ou ouvrez le raccourci ESP-IDF 5.5.5 sous Windows.
Mauvaise version avec idf.py --version Le terminal utilise une autre installation ; activez celle de ce cours.
CMakeLists.txt introuvable Vous n’êtes pas à la racine du projet extrait.
Puce détectée différente de la cible Comparez esp32 et esp32s3, corrigez la cible, puis refaites les réglages et la compilation.
Flash bloqué sur Connecting... Fermez tout autre moniteur série. Maintenez BOOT, appuyez puis relâchez EN/RESET, lancez le flash et relâchez BOOT quand le transfert démarre.
Port série refusé sous Linux Vérifiez son groupe avec ls -l /dev/ttyUSB0, en adaptant le port. Pour un port du groupe dialout sur Ubuntu/Debian, ajoutez votre compte avec sudo usermod -aG dialout "$USER", puis déconnectez et reconnectez votre session.
Address already in use Un programme occupe l’adresse et le port du broker. Identifiez votre instance existante avant d’en relancer une.
Port présent mais logs absents Vérifiez le port UART de la carte, la console UART0 et le redémarrage après flash.

Le poste est prêt lorsque la compilation et le flash se terminent, que B affiche READY, que A affiche MQTT connected et que des mesures apparaissent dans le fichier de réception. Vous pouvez alors reprendre « Le trajet de la mesure » dans la leçon 1.

Références des outils

Procédure mise à jour le 14 octobre 2026. Les sorties indiquées sont des critères à vérifier, pas des captures d’un essai effectué sur votre machine.

Fichiers de l’exercice
ESP32-MQTT-Lab-v0.2.2 (zip)
75,28 Ko