publish: Utiliser le WiFi du NodeMCU

2026-05-16 22:47:34 +02:00
parent 425106fe03
commit 76721b900a
4 changed files with 193 additions and 203 deletions
@@ -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"
 }
@@ -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 <ESP8266WiFi.h>
 #include <PubSubClient.h>
 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
 - ✅ É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 qui publie ses mesures sur un serveur distant.
+- Une station de qualité d'air avec plusieurs NodeMCU qui publient leurs mesures sur un broker commun.
- Un bouton physique qui déclenche une action sur un service web (lumière, notification…).
+- 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…).
-
+
 **Pistes d'approfondissement** :
-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**.
+
 - 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.
 - Explorer **Home Assistant** ou **Node-RED** pour visualiser et orchestrer toute votre installation IoT.
@@ -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": [
@@ -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 <ESP8266WiFi.h>
 #include <PubSubClient.h>
 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**.
+- Un thermomètre connecté qui affiche la météo extérieure sur un servo-moteur.
- Une station de qualité d'air avec plusieurs NodeMCU qui publient leurs mesures sur un broker commun.
+- Une station de qualité d'air qui publie ses mesures sur un serveur distant.
- 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 bouton physique qui déclenche une action sur un service web (lumière, notification…).
-**Pistes d'approfondissement** :
+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**.
 - 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.