From 76721b900a34e05b2ed347af296fef13e2bf593c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?C=C3=A9drix?= Date: Sat, 16 May 2026 22:47:34 +0200 Subject: [PATCH] publish: Utiliser le WiFi du NodeMCU --- .../draft_overlay.json | 16 -- ae28cd3b-052c-43c0-bafd-69fd2fd96dd7/index.md | 185 +++++++++++++++++- .../meta.json | 10 +- .../{draft_overlay.md => revisions/0002.md} | 185 +----------------- 4 files changed, 193 insertions(+), 203 deletions(-) delete mode 100644 ae28cd3b-052c-43c0-bafd-69fd2fd96dd7/draft_overlay.json rename ae28cd3b-052c-43c0-bafd-69fd2fd96dd7/{draft_overlay.md => revisions/0002.md} (65%) diff --git a/ae28cd3b-052c-43c0-bafd-69fd2fd96dd7/draft_overlay.json b/ae28cd3b-052c-43c0-bafd-69fd2fd96dd7/draft_overlay.json deleted file mode 100644 index b6a2a56..0000000 --- a/ae28cd3b-052c-43c0-bafd-69fd2fd96dd7/draft_overlay.json +++ /dev/null @@ -1,16 +0,0 @@ -{ - "title": "Utiliser le WiFi du NodeMCU", - "_updated_at": "2026-05-16 20:47:32", - "slug": "utiliser-le-wifi-du-nodemcu", - "published": true, - "published_at": "2020-04-17 18:22", - "category": "Électronique", - "tags": { - "tags": [ - "NodeMCU" - ] - }, - "seo_title": "", - "seo_description": "", - "og_image": "https://www.abonnel.fr/file?uuid=ae28cd3b-052c-43c0-bafd-69fd2fd96dd7&name=cover.png" -} diff --git a/ae28cd3b-052c-43c0-bafd-69fd2fd96dd7/index.md b/ae28cd3b-052c-43c0-bafd-69fd2fd96dd7/index.md index e2439cc..0c46ea5 100644 --- a/ae28cd3b-052c-43c0-bafd-69fd2fd96dd7/index.md +++ b/ae28cd3b-052c-43c0-bafd-69fd2fd96dd7/index.md @@ -401,6 +401,177 @@ Ici, l'objet `Image` contient un sous-objet `Vignette` et un tableau `IDs`. Cett --- +## 7. Dialoguer en MQTT plutôt qu'en HTTP + +HTTP fonctionne très bien pour interroger ponctuellement un serveur, mais il devient vite inadapté dès qu'on veut faire de la **vraie communication d'objets connectés** : capteurs qui publient leurs mesures en continu, actionneurs qui doivent réagir en temps réel, plusieurs objets qui dialoguent entre eux… + +C'est là qu'intervient **MQTT** (*Message Queuing Telemetry Transport*), un protocole conçu spécifiquement pour l'IoT. + +### 7.1. HTTP vs MQTT : pourquoi changer ? + +| Critère | HTTP | MQTT | +|---|---|---| +| **Modèle** | Client/serveur (requête/réponse) | Publish/subscribe (publication/abonnement) | +| **Initiative** | Le client demande, le serveur répond | Tout le monde peut publier et écouter | +| **Connexion** | Ouverte puis fermée à chaque requête | Permanente | +| **Taille des messages** | En-têtes verbeux (souvent plusieurs centaines d'octets) | Très léger (2 octets d'en-tête minimum) | +| **Temps réel** | Difficile : il faut interroger en boucle (*polling*) | Natif : les messages arrivent dès qu'ils sont publiés | +| **Consommation** | Élevée (CPU, énergie, bande passante) | Faible — idéal pour les objets sur batterie | + +En résumé : si votre NodeMCU doit envoyer une température toutes les 10 secondes pendant des mois sur une batterie, **HTTP va vider la pile en quelques jours**, là où MQTT tiendra des mois. + +### 7.2. Le modèle publish/subscribe + +Oubliez le client/serveur. En MQTT, on parle de : + +- **Broker** : un serveur central qui reçoit tous les messages et les redistribue. C'est le seul élément "lourd" du système. +- **Publishers** : les objets (ou applications) qui *envoient* des messages. +- **Subscribers** : les objets (ou applications) qui *reçoivent* des messages. + +Un même objet peut être à la fois publisher et subscriber. + +Les messages ne sont pas envoyés directement d'un objet à un autre : ils sont publiés sur des **topics** (sujets), organisés comme une arborescence : + +``` +maison/salon/temperature +maison/salon/humidite +maison/cuisine/temperature +maison/jardin/luminosite +``` + +Le séparateur est le `/`. Un capteur publie sur un topic, et tous les objets abonnés à ce topic reçoivent automatiquement le message. + +> 💡 **Avantage clé** : le publisher ne sait pas qui va lire son message, et le subscriber ne sait pas qui l'a envoyé. Cette **découplage** rend le système très souple — on peut ajouter ou retirer des objets sans rien reconfigurer. + +### 7.3. Les jokers (*wildcards*) + +Pour s'abonner à plusieurs topics à la fois, MQTT propose deux caractères spéciaux : + +| Symbole | Rôle | Exemple | +|---|---|---| +| `+` | Joker pour **un seul niveau** | `maison/+/temperature` capte le salon, la cuisine, la chambre… mais pas `maison/exterieur/jardin/temperature` | +| `#` | Joker pour **tous les niveaux suivants** | `maison/#` capte absolument tout ce qui commence par `maison/` | + +### 7.4. La qualité de service (QoS) + +MQTT propose trois niveaux de garantie de livraison : + +- **QoS 0** — *Au plus une fois* : le message part, et tant pis s'il se perd. Le plus rapide, mais sans garantie. +- **QoS 1** — *Au moins une fois* : le message arrivera, mais peut être livré plusieurs fois en cas de problème réseau. +- **QoS 2** — *Exactement une fois* : garantie totale, mais beaucoup plus coûteux en échanges réseau. + +Pour de la télémétrie (une température parmi des centaines), **QoS 0** suffit largement. Pour un ordre critique (déverrouiller une porte), on passera en **QoS 1** ou **2**. + +### 7.5. Mise en pratique sur le NodeMCU + +La bibliothèque la plus utilisée s'appelle **PubSubClient**. On l'installe via le gestionnaire de bibliothèques d'Arduino IDE (*Croquis* → *Inclure une bibliothèque* → *Gérer les bibliothèques* → rechercher `PubSubClient`). + +#### Étape 1 — Inclusions et configuration + +```cpp +#include +#include + +const char* ssid = "votre_wifi"; +const char* password = "votre_mot_de_passe"; +const char* mqtt_server = "test.mosquitto.org"; // broker public de test + +WiFiClient espClient; +PubSubClient client(espClient); +``` + +> 💡 **`test.mosquitto.org`** est un broker public **gratuit** parfait pour apprendre. Pour de vrais projets, vous installerez votre propre broker (par exemple **Mosquitto** sur un Raspberry Pi) ou utiliserez un service en ligne (**HiveMQ**, **AWS IoT Core**, **Adafruit IO**…). + +#### Étape 2 — Définir la fonction de réception + +C'est ici que toute la magie opère : dès qu'un message arrive sur un topic auquel on est abonné, cette fonction est appelée automatiquement. + +```cpp +void callback(char* topic, byte* payload, unsigned int length) { + Serial.print("Message reçu sur ["); + Serial.print(topic); + Serial.print("] : "); + + for (unsigned int i = 0; i < length; i++) { + Serial.print((char)payload[i]); + } + Serial.println(); +} +``` + +`payload` est un tableau d'octets (pas une chaîne C terminée par `\0`), d'où la nécessité du paramètre `length` pour savoir où s'arrêter. + +#### Étape 3 — Se connecter au broker + +```cpp +void reconnect() { + while (!client.connected()) { + Serial.print("Connexion au broker MQTT... "); + + // Chaque client doit avoir un identifiant unique + String clientId = "NodeMCU-" + String(random(0xffff), HEX); + + if (client.connect(clientId.c_str())) { + Serial.println("connecté !"); + client.subscribe("maison/salon/commande"); // on s'abonne + } else { + Serial.print("échec, code="); + Serial.print(client.state()); + Serial.println(" — nouvelle tentative dans 5s"); + delay(5000); + } + } +} +``` + +#### Étape 4 — La boucle principale + +```cpp +void setup() { + Serial.begin(115200); + WiFi.begin(ssid, password); + while (WiFi.status() != WL_CONNECTED) { delay(500); Serial.print("."); } + + client.setServer(mqtt_server, 1883); // port MQTT standard + client.setCallback(callback); +} + +void loop() { + if (!client.connected()) reconnect(); + client.loop(); // INDISPENSABLE : traite les messages entrants + + // Toutes les 10 secondes, on publie une température fictive + static unsigned long lastMsg = 0; + if (millis() - lastMsg > 10000) { + lastMsg = millis(); + float temperature = 20.0 + random(0, 100) / 10.0; + + char payload[10]; + dtostrf(temperature, 4, 1, payload); // float → chaîne + + client.publish("maison/salon/temperature", payload); + Serial.print("Publié : "); + Serial.println(payload); + } +} +``` + +Quelques points clés : + +- **Le port `1883`** est le port MQTT standard (non chiffré). Pour MQTT sécurisé (MQTTS), c'est `8883`. +- **`client.loop()` doit être appelé en permanence** : sans lui, aucun message entrant ne sera traité. +- **`dtostrf()`** convertit un float en chaîne de caractères (équivalent inverse de `atof()`). + +### 7.6. Tester sans matériel supplémentaire + +Pour vérifier que votre NodeMCU publie bien, vous pouvez utiliser un **client MQTT de bureau** comme [MQTT Explorer](https://mqtt-explorer.com/), gratuit et multiplateforme. Connectez-le au même broker (`test.mosquitto.org`), abonnez-vous à `maison/#` et vous verrez vos messages apparaître en direct. + +Vous pouvez aussi **publier** depuis MQTT Explorer un message sur `maison/salon/commande` pour voir votre NodeMCU le recevoir dans le moniteur série. + +> ⚠️ **Attention sur les brokers publics** : tous les messages sont visibles par tout le monde. Ne publiez rien de sensible, et préférez un préfixe original (`projet-de-pierre-42/...`) pour ne pas polluer les topics communs. + +--- + ## Pour aller plus loin Vous disposez maintenant de toutes les briques pour construire un objet connecté : @@ -409,11 +580,17 @@ Vous disposez maintenant de toutes les briques pour construire un objet connect - ✅ Se connecter à un point d'accès - ✅ Émettre une requête HTTP vers un serveur - ✅ Lire et interpréter une réponse JSON +- ✅ Publier et recevoir des messages via MQTT **Idées de projets** pour mettre en pratique : -- Un thermomètre connecté qui affiche la météo extérieure sur un servo-moteur. -- Une station de qualité d'air qui publie ses mesures sur un serveur distant. -- Un bouton physique qui déclenche une action sur un service web (lumière, notification…). +- Un thermomètre connecté qui publie sa mesure en MQTT, affichée sur un dashboard **Node-RED** ou **Home Assistant**. +- Une station de qualité d'air avec plusieurs NodeMCU qui publient leurs mesures sur un broker commun. +- Une télécommande sans fil : un bouton sur un NodeMCU publie une commande que d'autres NodeMCU exécutent (allumer une LED, faire bouger un servo…). -Pour aller plus loin, vous pouvez explorer les **méthodes HTTP** autres que `GET` (`POST`, `PUT`, `DELETE`), apprendre à parser le JSON proprement avec une bibliothèque comme `ArduinoJson`, ou découvrir des protocoles dédiés à l'IoT comme **MQTT**. \ No newline at end of file +**Pistes d'approfondissement** : + +- Parser proprement le JSON reçu avec la bibliothèque **`ArduinoJson`** plutôt qu'avec `indexOf()`. +- Installer son propre broker **Mosquitto** sur un Raspberry Pi pour ne dépendre d'aucun service en ligne. +- Mettre en place **MQTT sécurisé (MQTTS)** avec certificats TLS pour les déploiements en production. +- Explorer **Home Assistant** ou **Node-RED** pour visualiser et orchestrer toute votre installation IoT. \ No newline at end of file diff --git a/ae28cd3b-052c-43c0-bafd-69fd2fd96dd7/meta.json b/ae28cd3b-052c-43c0-bafd-69fd2fd96dd7/meta.json index 6146627..7a07a47 100644 --- a/ae28cd3b-052c-43c0-bafd-69fd2fd96dd7/meta.json +++ b/ae28cd3b-052c-43c0-bafd-69fd2fd96dd7/meta.json @@ -7,13 +7,19 @@ "featured": false, "published_at": "2020-04-17 18:22", "created_at": "2020-04-17 18:22:49", - "updated_at": "2026-05-16 20:43:40", + "updated_at": "2026-05-16 20:47:34", "revisions": [ { "n": 1, "date": "2026-05-16 20:43:40", "comment": "Titre modifié, tags modifiés, contenu modifié", "title": "Utiliser le Wifi du NodeMCU" + }, + { + "n": 2, + "date": "2026-05-16 20:47:34", + "comment": "Contenu modifié, image de couverture modifiée", + "title": "Utiliser le WiFi du NodeMCU" } ], "cover": "cover.png", @@ -21,7 +27,7 @@ "external_links": [], "seo_title": "", "seo_description": "", - "og_image": "", + "og_image": "https://www.abonnel.fr/file?uuid=ae28cd3b-052c-43c0-bafd-69fd2fd96dd7&name=cover.png", "category": "Électronique", "tags": { "tags": [ diff --git a/ae28cd3b-052c-43c0-bafd-69fd2fd96dd7/draft_overlay.md b/ae28cd3b-052c-43c0-bafd-69fd2fd96dd7/revisions/0002.md similarity index 65% rename from ae28cd3b-052c-43c0-bafd-69fd2fd96dd7/draft_overlay.md rename to ae28cd3b-052c-43c0-bafd-69fd2fd96dd7/revisions/0002.md index 0c46ea5..e2439cc 100644 --- a/ae28cd3b-052c-43c0-bafd-69fd2fd96dd7/draft_overlay.md +++ b/ae28cd3b-052c-43c0-bafd-69fd2fd96dd7/revisions/0002.md @@ -401,177 +401,6 @@ Ici, l'objet `Image` contient un sous-objet `Vignette` et un tableau `IDs`. Cett --- -## 7. Dialoguer en MQTT plutôt qu'en HTTP - -HTTP fonctionne très bien pour interroger ponctuellement un serveur, mais il devient vite inadapté dès qu'on veut faire de la **vraie communication d'objets connectés** : capteurs qui publient leurs mesures en continu, actionneurs qui doivent réagir en temps réel, plusieurs objets qui dialoguent entre eux… - -C'est là qu'intervient **MQTT** (*Message Queuing Telemetry Transport*), un protocole conçu spécifiquement pour l'IoT. - -### 7.1. HTTP vs MQTT : pourquoi changer ? - -| Critère | HTTP | MQTT | -|---|---|---| -| **Modèle** | Client/serveur (requête/réponse) | Publish/subscribe (publication/abonnement) | -| **Initiative** | Le client demande, le serveur répond | Tout le monde peut publier et écouter | -| **Connexion** | Ouverte puis fermée à chaque requête | Permanente | -| **Taille des messages** | En-têtes verbeux (souvent plusieurs centaines d'octets) | Très léger (2 octets d'en-tête minimum) | -| **Temps réel** | Difficile : il faut interroger en boucle (*polling*) | Natif : les messages arrivent dès qu'ils sont publiés | -| **Consommation** | Élevée (CPU, énergie, bande passante) | Faible — idéal pour les objets sur batterie | - -En résumé : si votre NodeMCU doit envoyer une température toutes les 10 secondes pendant des mois sur une batterie, **HTTP va vider la pile en quelques jours**, là où MQTT tiendra des mois. - -### 7.2. Le modèle publish/subscribe - -Oubliez le client/serveur. En MQTT, on parle de : - -- **Broker** : un serveur central qui reçoit tous les messages et les redistribue. C'est le seul élément "lourd" du système. -- **Publishers** : les objets (ou applications) qui *envoient* des messages. -- **Subscribers** : les objets (ou applications) qui *reçoivent* des messages. - -Un même objet peut être à la fois publisher et subscriber. - -Les messages ne sont pas envoyés directement d'un objet à un autre : ils sont publiés sur des **topics** (sujets), organisés comme une arborescence : - -``` -maison/salon/temperature -maison/salon/humidite -maison/cuisine/temperature -maison/jardin/luminosite -``` - -Le séparateur est le `/`. Un capteur publie sur un topic, et tous les objets abonnés à ce topic reçoivent automatiquement le message. - -> 💡 **Avantage clé** : le publisher ne sait pas qui va lire son message, et le subscriber ne sait pas qui l'a envoyé. Cette **découplage** rend le système très souple — on peut ajouter ou retirer des objets sans rien reconfigurer. - -### 7.3. Les jokers (*wildcards*) - -Pour s'abonner à plusieurs topics à la fois, MQTT propose deux caractères spéciaux : - -| Symbole | Rôle | Exemple | -|---|---|---| -| `+` | Joker pour **un seul niveau** | `maison/+/temperature` capte le salon, la cuisine, la chambre… mais pas `maison/exterieur/jardin/temperature` | -| `#` | Joker pour **tous les niveaux suivants** | `maison/#` capte absolument tout ce qui commence par `maison/` | - -### 7.4. La qualité de service (QoS) - -MQTT propose trois niveaux de garantie de livraison : - -- **QoS 0** — *Au plus une fois* : le message part, et tant pis s'il se perd. Le plus rapide, mais sans garantie. -- **QoS 1** — *Au moins une fois* : le message arrivera, mais peut être livré plusieurs fois en cas de problème réseau. -- **QoS 2** — *Exactement une fois* : garantie totale, mais beaucoup plus coûteux en échanges réseau. - -Pour de la télémétrie (une température parmi des centaines), **QoS 0** suffit largement. Pour un ordre critique (déverrouiller une porte), on passera en **QoS 1** ou **2**. - -### 7.5. Mise en pratique sur le NodeMCU - -La bibliothèque la plus utilisée s'appelle **PubSubClient**. On l'installe via le gestionnaire de bibliothèques d'Arduino IDE (*Croquis* → *Inclure une bibliothèque* → *Gérer les bibliothèques* → rechercher `PubSubClient`). - -#### Étape 1 — Inclusions et configuration - -```cpp -#include -#include - -const char* ssid = "votre_wifi"; -const char* password = "votre_mot_de_passe"; -const char* mqtt_server = "test.mosquitto.org"; // broker public de test - -WiFiClient espClient; -PubSubClient client(espClient); -``` - -> 💡 **`test.mosquitto.org`** est un broker public **gratuit** parfait pour apprendre. Pour de vrais projets, vous installerez votre propre broker (par exemple **Mosquitto** sur un Raspberry Pi) ou utiliserez un service en ligne (**HiveMQ**, **AWS IoT Core**, **Adafruit IO**…). - -#### Étape 2 — Définir la fonction de réception - -C'est ici que toute la magie opère : dès qu'un message arrive sur un topic auquel on est abonné, cette fonction est appelée automatiquement. - -```cpp -void callback(char* topic, byte* payload, unsigned int length) { - Serial.print("Message reçu sur ["); - Serial.print(topic); - Serial.print("] : "); - - for (unsigned int i = 0; i < length; i++) { - Serial.print((char)payload[i]); - } - Serial.println(); -} -``` - -`payload` est un tableau d'octets (pas une chaîne C terminée par `\0`), d'où la nécessité du paramètre `length` pour savoir où s'arrêter. - -#### Étape 3 — Se connecter au broker - -```cpp -void reconnect() { - while (!client.connected()) { - Serial.print("Connexion au broker MQTT... "); - - // Chaque client doit avoir un identifiant unique - String clientId = "NodeMCU-" + String(random(0xffff), HEX); - - if (client.connect(clientId.c_str())) { - Serial.println("connecté !"); - client.subscribe("maison/salon/commande"); // on s'abonne - } else { - Serial.print("échec, code="); - Serial.print(client.state()); - Serial.println(" — nouvelle tentative dans 5s"); - delay(5000); - } - } -} -``` - -#### Étape 4 — La boucle principale - -```cpp -void setup() { - Serial.begin(115200); - WiFi.begin(ssid, password); - while (WiFi.status() != WL_CONNECTED) { delay(500); Serial.print("."); } - - client.setServer(mqtt_server, 1883); // port MQTT standard - client.setCallback(callback); -} - -void loop() { - if (!client.connected()) reconnect(); - client.loop(); // INDISPENSABLE : traite les messages entrants - - // Toutes les 10 secondes, on publie une température fictive - static unsigned long lastMsg = 0; - if (millis() - lastMsg > 10000) { - lastMsg = millis(); - float temperature = 20.0 + random(0, 100) / 10.0; - - char payload[10]; - dtostrf(temperature, 4, 1, payload); // float → chaîne - - client.publish("maison/salon/temperature", payload); - Serial.print("Publié : "); - Serial.println(payload); - } -} -``` - -Quelques points clés : - -- **Le port `1883`** est le port MQTT standard (non chiffré). Pour MQTT sécurisé (MQTTS), c'est `8883`. -- **`client.loop()` doit être appelé en permanence** : sans lui, aucun message entrant ne sera traité. -- **`dtostrf()`** convertit un float en chaîne de caractères (équivalent inverse de `atof()`). - -### 7.6. Tester sans matériel supplémentaire - -Pour vérifier que votre NodeMCU publie bien, vous pouvez utiliser un **client MQTT de bureau** comme [MQTT Explorer](https://mqtt-explorer.com/), gratuit et multiplateforme. Connectez-le au même broker (`test.mosquitto.org`), abonnez-vous à `maison/#` et vous verrez vos messages apparaître en direct. - -Vous pouvez aussi **publier** depuis MQTT Explorer un message sur `maison/salon/commande` pour voir votre NodeMCU le recevoir dans le moniteur série. - -> ⚠️ **Attention sur les brokers publics** : tous les messages sont visibles par tout le monde. Ne publiez rien de sensible, et préférez un préfixe original (`projet-de-pierre-42/...`) pour ne pas polluer les topics communs. - ---- - ## Pour aller plus loin Vous disposez maintenant de toutes les briques pour construire un objet connecté : @@ -580,17 +409,11 @@ Vous disposez maintenant de toutes les briques pour construire un objet connect - ✅ Se connecter à un point d'accès - ✅ Émettre une requête HTTP vers un serveur - ✅ Lire et interpréter une réponse JSON -- ✅ Publier et recevoir des messages via MQTT **Idées de projets** pour mettre en pratique : -- Un thermomètre connecté qui publie sa mesure en MQTT, affichée sur un dashboard **Node-RED** ou **Home Assistant**. -- Une station de qualité d'air avec plusieurs NodeMCU qui publient leurs mesures sur un broker commun. -- Une télécommande sans fil : un bouton sur un NodeMCU publie une commande que d'autres NodeMCU exécutent (allumer une LED, faire bouger un servo…). +- Un thermomètre connecté qui affiche la météo extérieure sur un servo-moteur. +- Une station de qualité d'air qui publie ses mesures sur un serveur distant. +- Un bouton physique qui déclenche une action sur un service web (lumière, notification…). -**Pistes d'approfondissement** : - -- Parser proprement le JSON reçu avec la bibliothèque **`ArduinoJson`** plutôt qu'avec `indexOf()`. -- Installer son propre broker **Mosquitto** sur un Raspberry Pi pour ne dépendre d'aucun service en ligne. -- Mettre en place **MQTT sécurisé (MQTTS)** avec certificats TLS pour les déploiements en production. -- Explorer **Home Assistant** ou **Node-RED** pour visualiser et orchestrer toute votre installation IoT. \ No newline at end of file +Pour aller plus loin, vous pouvez explorer les **méthodes HTTP** autres que `GET` (`POST`, `PUT`, `DELETE`), apprendre à parser le JSON proprement avec une bibliothèque comme `ArduinoJson`, ou découvrir des protocoles dédiés à l'IoT comme **MQTT**. \ No newline at end of file