publish: Utiliser le WiFi du NodeMCU
This commit is contained in:
Cédrix
@@ -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.
|
||||
- Un bouton physique qui déclenche une action sur un service web (lumière, notification…).
|
||||
|
||||
- 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…).
|
||||
|
||||
**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": [
|
||||
|
||||
+4
-181
@@ -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**.
|
||||
- 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.
|
||||
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**.
|
||||
Reference in New Issue
Block a user