draft: Utiliser le Wifi du NodeMCU
This commit is contained in:
@@ -535,3 +535,13 @@
|
||||
{"ts":"2026-05-16 20:28:38","url":"/informatique/divers/fedora_ecrire_image_iso_sur_cle_usb","ref":"","ua":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36"}
|
||||
{"ts":"2026-05-16 20:28:40","url":"/tag/windows_systeme/index/index/index/index/index/index/index/index/index/index/index","ref":"","ua":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36"}
|
||||
{"ts":"2026-05-16 20:28:48","url":"/user/denise","ref":"","ua":"Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/116.0.1938.76 Safari/537.36"}
|
||||
{"ts":"2026-05-16 20:30:45","url":"/informatique/linux/applications/soundux","ref":"","ua":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36"}
|
||||
{"ts":"2026-05-16 20:31:42","url":"/informatique/technologie/3d/index","ref":"https://www.abonnel.fr/informatique/technologie/3d/index?idx=informatique%3Avirtualisation","ua":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36"}
|
||||
{"ts":"2026-05-16 20:32:08","url":"/sitemaps.xml","ref":"","ua":"Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/116.0.1938.76 Safari/537.36"}
|
||||
{"ts":"2026-05-16 20:32:27","url":"/discussion/informatique/linux/distributions/debian/download","ref":"","ua":"Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.7778.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"}
|
||||
{"ts":"2026-05-16 20:32:30","url":"/electronique/raspberry-pi/\"\"","ref":"","ua":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"}
|
||||
{"ts":"2026-05-16 20:33:26","url":"/informatique/divers/fedora_ecrire_image_iso_sur_cle_usb","ref":"","ua":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36"}
|
||||
{"ts":"2026-05-16 20:34:39","url":"/informatique/serveur/web-linux-apache/directives-apache2-serveur-configuration-repertoire","ref":"","ua":"Mozilla/5.0 (compatible; SemrushBot/7~bl; +http://www.semrush.com/bot.html)"}
|
||||
{"ts":"2026-05-16 20:35:07","url":"/informatique/langage/index","ref":"https://abonnel.fr/informatique/langage/index","ua":"Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"}
|
||||
{"ts":"2026-05-16 20:37:16","url":"/informatique/hack/la-quadrature-du-net","ref":"","ua":"Mozilla/5.0 (Macintosh; Intel Mac OS X 14.4; rv:135.0) Gecko/20100101 Firefox/135.0"}
|
||||
{"ts":"2026-05-16 20:41:31","url":"/informatique/linux/commandes/du","ref":"","ua":"Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.7778.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"}
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
{
|
||||
"title": "Utiliser le WiFi du NodeMCU",
|
||||
"_updated_at": "2026-05-16 20:43:14"
|
||||
}
|
||||
@@ -0,0 +1,419 @@
|
||||
# Utiliser le WiFi du NodeMCU
|
||||
|
||||
Le module ESP8266 (embarqué sur les cartes NodeMCU) intègre nativement le WiFi. Dans ce tutoriel, nous allons apprendre pas à pas à exploiter cette capacité : scanner les réseaux disponibles, se connecter à un point d'accès, dialoguer avec un serveur web, puis interpréter les données reçues au format JSON.
|
||||
|
||||
L'objectif final ? Transformer votre NodeMCU en objet connecté capable, par exemple, d'afficher la température extérieure récupérée en temps réel sur Internet.
|
||||
|
||||
---
|
||||
|
||||
## 1. Scanner les réseaux WiFi disponibles
|
||||
|
||||
Avant de se connecter à un réseau, encore faut-il savoir quels réseaux sont à portée. C'est exactement ce que fait l'exemple `WiFiScan`, fourni avec la bibliothèque ESP8266.
|
||||
|
||||
**Pour le charger** : *Fichier* → *Exemples* → *ESP8266WiFi* → *WiFiScan*
|
||||
|
||||
### Préparer le module dans `setup()`
|
||||
|
||||
```cpp
|
||||
WiFi.mode(WIFI_STA); // mode "Station" (client d'une box)
|
||||
WiFi.disconnect(); // au cas où une connexion serait déjà active
|
||||
```
|
||||
|
||||
Quelques précisions importantes :
|
||||
|
||||
- `WiFi.mode()` est une méthode **spécifique au module ESP**, vous ne la trouverez pas dans la documentation officielle Arduino. Le mode `WIFI_STA` (Station) signifie que le module se comportera comme un client classique, à l'image d'un smartphone qui se connecte à une box. Il existe aussi un mode `WIFI_AP` (Access Point) où le module devient lui-même un point d'accès.
|
||||
- `WiFi.disconnect()` garantit qu'aucune connexion antérieure ne va perturber notre scan.
|
||||
|
||||
### Lister les réseaux dans `loop()`
|
||||
|
||||
```cpp
|
||||
int n = WiFi.scanNetworks();
|
||||
|
||||
for (int i = 0; i < n; ++i) {
|
||||
Serial.print(i + 1);
|
||||
Serial.print(": ");
|
||||
Serial.print(WiFi.SSID(i)); // nom du réseau
|
||||
Serial.print(" (");
|
||||
Serial.print(WiFi.RSSI(i)); // puissance du signal
|
||||
Serial.print(")");
|
||||
Serial.println((WiFi.encryptionType(i) == ENC_TYPE_NONE) ? " " : "*");
|
||||
delay(10);
|
||||
}
|
||||
```
|
||||
|
||||
### Comprendre ce qui se passe
|
||||
|
||||
| Méthode | Rôle |
|
||||
|---|---|
|
||||
| `WiFi.scanNetworks()` | Balaie toutes les fréquences WiFi et retourne le nombre de réseaux détectés |
|
||||
| `WiFi.SSID(i)` | Renvoie le nom du i-ème réseau (**SSID** = *Service Set IDentifier*) |
|
||||
| `WiFi.RSSI(i)` | Renvoie la puissance du signal reçu (**RSSI** = *Received Signal Strength Indication*), exprimée en dBm — plus la valeur est proche de 0, meilleur est le signal |
|
||||
| `WiFi.encryptionType(i)` | Indique si le réseau est protégé par un mot de passe |
|
||||
|
||||
> **Comment ça marche en coulisses ?** Les box (et plus généralement tous les points d'accès WiFi) émettent environ **10 fois par seconde** un petit message appelé *beacon* qui annonce le nom du réseau. La méthode `scanNetworks()` ne fait qu'écouter passivement toutes les fréquences pour capter ces annonces.
|
||||
|
||||
---
|
||||
|
||||
## 2. Se connecter à un réseau et obtenir une adresse IP
|
||||
|
||||
Détecter un réseau, c'est bien. Pouvoir l'utiliser, c'est mieux. Pour communiquer avec d'autres équipements, notre module doit :
|
||||
|
||||
1. Se connecter à un point d'accès (avec son nom et son mot de passe),
|
||||
2. Obtenir une **adresse IP** auprès du serveur DHCP de la box.
|
||||
|
||||
L'exemple `WiFiClient_simple.ino` illustre cette procédure.
|
||||
|
||||
### Établir la connexion
|
||||
|
||||
```cpp
|
||||
WiFi.begin(ssid, password); // on lance la connexion
|
||||
|
||||
while (WiFi.status() != WL_CONNECTED) { // on attend qu'elle aboutisse
|
||||
delay(500);
|
||||
Serial.print(".");
|
||||
}
|
||||
```
|
||||
|
||||
La boucle `while` est essentielle : la connexion n'est pas instantanée. Le module doit s'authentifier auprès de la box, puis attendre que le **serveur DHCP** lui attribue une adresse IP ainsi que les paramètres réseau (masque, passerelle, DNS).
|
||||
|
||||
### Afficher les paramètres obtenus
|
||||
|
||||
```cpp
|
||||
Serial.println("");
|
||||
Serial.println("WiFi connecté");
|
||||
Serial.print("Adresse IP du module ESP : ");
|
||||
Serial.println(WiFi.localIP());
|
||||
Serial.print("Adresse IP de la box : ");
|
||||
Serial.println(WiFi.gatewayIP());
|
||||
```
|
||||
|
||||
La *gateway* (passerelle) correspond à la machine vers laquelle le module va envoyer ses données pour qu'elles sortent vers Internet — autrement dit, l'adresse IP de votre box.
|
||||
|
||||
---
|
||||
|
||||
## 3. Comprendre le Web avant de l'utiliser
|
||||
|
||||
Avant d'écrire du code qui interroge un serveur, il faut comprendre comment fonctionne le Web. Trois concepts sont indispensables : le **modèle client/serveur**, les **méta-données**, et les **URI**.
|
||||
|
||||
### 3.1. Le modèle client/serveur
|
||||
|
||||
Le Web est souvent confondu avec Internet, mais ce n'est qu'**un service parmi d'autres** qui circulent sur le réseau. Sa force ? Sa **scalabilité** : la capacité à répondre à un nombre énorme de requêtes sans s'effondrer.
|
||||
|
||||
Le principe est simple :
|
||||
|
||||
- Le **client** demande une information.
|
||||
- Le **serveur** la lui retourne, puis **oublie tout**.
|
||||
|
||||
C'est cette amnésie volontaire du serveur qui permet la montée en charge. S'il devait se souvenir de chaque client et de chaque requête, il serait rapidement débordé. À la place, c'est le **client** qui conserve l'état de la session.
|
||||
|
||||
Conséquence pratique : une requête peut être traitée par n'importe quel serveur d'une ferme de machines, ce qui permet de répartir la charge. Quand une page web est demandée, elle contient souvent des références (images, scripts, styles) que le client ira chercher ensuite — éventuellement sur d'autres serveurs.
|
||||
|
||||
### 3.2. Les ressources et les méta-données
|
||||
|
||||
Le serveur manipule des **ressources** : une information binaire de taille finie. Cela peut être du texte, une image, une vidéo, des données structurées… La définition est volontairement très large.
|
||||
|
||||
Aux données brutes, on ajoute des **méta-données** : ce sont des informations *sur* les données (leur date, leur taille, leur type…). Elles permettent au client de savoir comment traiter ce qu'il reçoit.
|
||||
|
||||
Voici un exemple de réponse complète d'un serveur :
|
||||
|
||||
```http
|
||||
HTTP/1.0 200 OK
|
||||
Date: Thu, 28 Apr 2016 17:51:07 GMT
|
||||
Server: WSGIServer/0.1 Python/2.7.9
|
||||
X-Frame-Options: SAMEORIGIN
|
||||
Content-Type: text/plain
|
||||
|
||||
```
|
||||
|
||||
Décortiquons l'en-tête :
|
||||
|
||||
- **`HTTP/1.0 200 OK`** : version du protocole + code de statut. `200` signifie succès.
|
||||
- **`Date:`** : moment où la réponse a été produite.
|
||||
- **`Content-Type: text/plain`** : la donnée renvoyée est du texte non formaté.
|
||||
|
||||
Puis une **ligne vide** sépare l'en-tête du corps de la réponse, qui contient ici la valeur `147`.
|
||||
|
||||
#### Les codes de statut HTTP
|
||||
|
||||
Le premier chiffre du code indique la nature de la réponse :
|
||||
|
||||
| Code | Signification |
|
||||
|---|---|
|
||||
| **1xx** | Traitement en cours |
|
||||
| **2xx** | Succès |
|
||||
| **3xx** | Redirection (il faut interroger un autre serveur) |
|
||||
| **4xx** | Erreur côté **client** (mauvaise requête) |
|
||||
| **5xx** | Erreur côté **serveur** |
|
||||
|
||||
La fameuse **erreur 404** ("page non trouvée") est donc bien une erreur du client, qui a demandé une ressource qui n'existe pas.
|
||||
|
||||
### 3.3. Les URI : une adresse universelle pour les ressources
|
||||
|
||||
Pour identifier les ressources, le Web utilise les **URI** (*Uniform Resource Identifier*). On parlait historiquement d'URL, mais URI est devenu le terme générique.
|
||||
|
||||
La structure d'une URI typique :
|
||||
|
||||
```
|
||||
schéma://serveur:port/chemin/vers/la/ressource
|
||||
```
|
||||
|
||||
| Partie | Rôle |
|
||||
|---|---|
|
||||
| **schéma** | Indique comment lire le reste de l'URI (`http`, `https`, `ftp`…) |
|
||||
| **serveur** | Nom de domaine ou adresse IP |
|
||||
| **port** | Optionnel — par défaut `80` pour HTTP, `443` pour HTTPS |
|
||||
| **chemin** | Localisation interne au serveur |
|
||||
|
||||
> ⚠️ Contrairement à une idée reçue, le **schéma** ne désigne pas directement un protocole réseau, mais la **manière dont l'URI est structurée**.
|
||||
|
||||
Exemple :
|
||||
|
||||
```
|
||||
https://www.fun-mooc.fr/courses/MinesTelecom/04011S02/session02/about
|
||||
```
|
||||
|
||||
- Schéma : `https`
|
||||
- Serveur : `www.fun-mooc.fr`
|
||||
- Chemin : `/courses/MinesTelecom/04011S02/session02/about`
|
||||
|
||||
---
|
||||
|
||||
## 4. Interroger un serveur web depuis le NodeMCU
|
||||
|
||||
Maintenant que la théorie est posée, passons à la pratique avec le programme `WiFiClient-compteur.ino`. Il ouvre une connexion vers le serveur `api.tom.tools` sur le port 80 et récupère la valeur d'un compteur.
|
||||
|
||||
### 4.1. Ouvrir une connexion TCP
|
||||
|
||||
```cpp
|
||||
const int httpPort = 80; // port standard du Web
|
||||
|
||||
if (!client.connect(host, httpPort)) {
|
||||
Serial.println("connection failed");
|
||||
return;
|
||||
}
|
||||
```
|
||||
|
||||
Les variables `host` et `httpPort` sont déclarées en début de programme :
|
||||
|
||||
- `host` vaut `"api.tom.tools"`
|
||||
- `httpPort` vaut `80`
|
||||
|
||||
`client.connect()` établit la connexion TCP. Si elle échoue, on affiche un message et on quitte la boucle.
|
||||
|
||||
### 4.2. Construire et envoyer la requête HTTP
|
||||
|
||||
```cpp
|
||||
String url = String("/hits/");
|
||||
|
||||
client.print(String("GET ") + url + " HTTP/1.1\r\n" +
|
||||
"Host: " + host + "\r\n" +
|
||||
"Connection: close\r\n\r\n");
|
||||
```
|
||||
|
||||
On vient de construire l'URI `http://api.tom.tools/hits/` et d'envoyer une requête HTTP composée de **3 lignes** (`\r\n` signale une fin de ligne) :
|
||||
|
||||
1. **`GET /hits/ HTTP/1.1`** — la requête elle-même :
|
||||
- `GET` est la méthode HTTP pour *récupérer* une ressource.
|
||||
- `/hits/` est le chemin vers la ressource.
|
||||
- `HTTP/1.1` est la version du protocole. Le serveur peut répondre dans une autre version si la nôtre ne lui convient pas (on a vu plus haut une réponse en `HTTP/1.0`).
|
||||
|
||||
2. **`Host: api.tom.tools`** — indispensable pour la **virtualisation**. Sur une même machine physique, plusieurs sites peuvent partager une même adresse IP (par exemple `api.tom.tools` et `www.justinbieber-fan.fr`). Au niveau TCP/IP, impossible de deviner lequel des deux on souhaite contacter. C'est le champ `Host` qui lève l'ambiguïté.
|
||||
|
||||
3. **`Connection: close`** — on signale au serveur qu'il peut fermer la connexion après avoir répondu.
|
||||
|
||||
La ligne vide finale (`\r\n\r\n`) marque la fin de l'en-tête de la requête.
|
||||
|
||||
### 4.3. Recevoir et afficher la réponse
|
||||
|
||||
```cpp
|
||||
delay(1000); // on laisse au serveur le temps de répondre
|
||||
|
||||
while (client.available()) {
|
||||
String line = client.readStringUntil('\r');
|
||||
Serial.print(line);
|
||||
}
|
||||
|
||||
Serial.println();
|
||||
Serial.println("connexion fermée");
|
||||
```
|
||||
|
||||
Tant que des données arrivent, on les lit ligne par ligne et on les affiche. Puis on attend (typiquement 30 secondes) avant de recommencer.
|
||||
|
||||
---
|
||||
|
||||
## 5. Cas pratique : récupérer la température extérieure
|
||||
|
||||
Le programme `WiFiTemperature.ino` reprend la structure précédente, mais interroge cette fois l'API publique **OpenWeatherMap** pour obtenir la météo d'une ville.
|
||||
|
||||
### 5.1. Configurer la requête
|
||||
|
||||
```cpp
|
||||
const char* host = "api.openweathermap.org";
|
||||
const char* apikey = "1a702a15a2f46e405e61804cf67c0d30"; // clé d'API
|
||||
const char* town = "Rennes,fr";
|
||||
```
|
||||
|
||||
Trois variables sont nécessaires :
|
||||
|
||||
- **`host`** : le serveur à contacter.
|
||||
- **`apikey`** : une clé d'identification fournie par OpenWeatherMap pour identifier l'utilisateur qui fait la requête.
|
||||
- **`town`** : la ville dont on veut la météo.
|
||||
|
||||
### 5.2. Construire l'URL avec des paramètres
|
||||
|
||||
```cpp
|
||||
String url = String("/data/2.5/weather?q=") + town + "&appid=" + apikey;
|
||||
```
|
||||
|
||||
Ce chemin est plus complexe que `/hits/`. Après le `?`, on trouve des **paramètres** au format `clé=valeur`, séparés par des `&` :
|
||||
|
||||
- `q=Rennes,fr` : la ville recherchée.
|
||||
- `appid=...` : la clé d'API.
|
||||
|
||||
Ces paramètres permettent à la ressource `/data/2.5/weather` d'adapter sa réponse à notre demande.
|
||||
|
||||
### 5.3. Sauter l'en-tête pour atteindre le corps
|
||||
|
||||
La réponse du serveur contient un en-tête (les méta-données) suivi d'une ligne vide, puis des données utiles. Pour atteindre ces données, on utilise un drapeau booléen :
|
||||
|
||||
```cpp
|
||||
bool inBody = false;
|
||||
|
||||
while (client.available()) {
|
||||
String line = client.readStringUntil('\r');
|
||||
|
||||
if (line.length() == 1) inBody = true; // ligne vide → début du corps
|
||||
|
||||
if (inBody) {
|
||||
// ici on traite les données utiles
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Tant que `inBody` reste `false`, on est dans l'en-tête. Dès qu'on rencontre une ligne vide (de longueur 1 si on compte le saut de ligne), on bascule dans le corps.
|
||||
|
||||
### 5.4. Extraire la température du JSON
|
||||
|
||||
OpenWeatherMap renvoie ses données au format **JSON** (voir section suivante). La température se trouve après le mot-clé `"temp":`.
|
||||
|
||||
```cpp
|
||||
String keyword = String("\"temp\":"); // les \ permettent d'inclure " dans la chaîne
|
||||
```
|
||||
|
||||
> 💡 Les **antislashs** servent à *échapper* les guillemets, sinon le compilateur penserait que la chaîne se termine prématurément.
|
||||
|
||||
Puis on cherche cette chaîne dans chaque ligne :
|
||||
|
||||
```cpp
|
||||
if (inBody) {
|
||||
int pos = line.indexOf(keyword);
|
||||
|
||||
if (pos > 0) { // mot-clé trouvé
|
||||
pos += keyword.length(); // on se place juste après "temp":
|
||||
temperature = atof(&line[pos]); // conversion en nombre flottant
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Petites explications :
|
||||
|
||||
- **`indexOf()`** renvoie la position de la chaîne recherchée, ou `-1` si elle n'est pas trouvée.
|
||||
- En ajoutant la longueur du mot-clé, on se positionne sur le premier caractère du **nombre**.
|
||||
- **`atof()`** (*ASCII to float*) convertit une chaîne de caractères en nombre à virgule.
|
||||
- L'opérateur **`&`** donne l'adresse mémoire du caractère, car `atof` attend un pointeur.
|
||||
|
||||
Et voilà ! La variable `temperature` contient maintenant la température en kelvins (OpenWeatherMap renvoie ses températures en kelvins par défaut — il suffira de soustraire 273,15 pour les convertir en degrés Celsius).
|
||||
|
||||
---
|
||||
|
||||
## 6. Le format JSON
|
||||
|
||||
Le programme précédent recherche une valeur dans un texte structuré au format **JSON** (*JavaScript Object Notation*). Comprendre ce format est indispensable pour l'Internet des objets.
|
||||
|
||||
### 6.1. Pourquoi structurer les données ?
|
||||
|
||||
Imaginez une phrase sans espaces :
|
||||
|
||||
> sionnestructurepasunephraseavecdesespacesilesttrèsdurdelalireetdyretrouverdesmots
|
||||
|
||||
Pour les données, c'est pareil. Si l'on transmet juste `25`, ça peut être une température, un âge, un pourcentage… On a besoin d'une **structure** qui dise *à quoi correspond chaque valeur*.
|
||||
|
||||
JSON a été conçu pour le Web, mais sa simplicité et sa compacité l'ont rendu très populaire pour les objets connectés.
|
||||
|
||||
### 6.2. Les types de données JSON
|
||||
|
||||
JSON définit deux **types simples** :
|
||||
|
||||
| Type | Forme | Exemple |
|
||||
|---|---|---|
|
||||
| Chaîne de caractères | entre guillemets `"` | `"Bonjour"`, `"123"` |
|
||||
| Nombre | sans guillemets | `42`, `-3.14`, `-.1e+3` (= -100) |
|
||||
|
||||
Et trois **types composés** :
|
||||
|
||||
#### Les objets (listes de paires clé/valeur)
|
||||
|
||||
Entre **accolades**, une suite de paires `"clé": valeur` séparées par des virgules :
|
||||
|
||||
```json
|
||||
{
|
||||
"resolution_verticale": 1200,
|
||||
"resolution_horizontale": 900,
|
||||
"couleurs": true
|
||||
}
|
||||
```
|
||||
|
||||
#### Les tableaux
|
||||
|
||||
Entre **crochets droits**, une suite de valeurs séparées par des virgules :
|
||||
|
||||
```json
|
||||
[1200, 900, true]
|
||||
```
|
||||
|
||||
C'est plus compact, mais la **position** devient déterminante : il faut savoir que le premier nombre est la résolution verticale, le second l'horizontale, etc.
|
||||
|
||||
#### L'imbrication
|
||||
|
||||
La force de JSON est qu'on peut combiner ces structures à l'infini : objets dans des tableaux, tableaux dans des objets, etc.
|
||||
|
||||
```json
|
||||
{
|
||||
"Image": {
|
||||
"Hauteur": 800,
|
||||
"Largeur": 600,
|
||||
"Titre": "Vue du 5ème étage",
|
||||
"Vignette": {
|
||||
"Url": "http://www.example.com/image/481989943",
|
||||
"Hauteur": 125,
|
||||
"Largeur": 100
|
||||
},
|
||||
"Animee": false,
|
||||
"IDs": [116, 943, 234, 38793]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Ici, l'objet `Image` contient un sous-objet `Vignette` et un tableau `IDs`. Cette flexibilité explique pourquoi JSON s'est imposé comme standard d'échange de données.
|
||||
|
||||
> 💡 **Anecdote** : JSON se prononce *jisone* en français ou *jay-zon* à l'anglaise. Rien à voir avec le tueur des films d'horreur — celui-là s'écrit Jason !
|
||||
|
||||
---
|
||||
|
||||
## Pour aller plus loin
|
||||
|
||||
Vous disposez maintenant de toutes les briques pour construire un objet connecté :
|
||||
|
||||
- ✅ Scanner les réseaux WiFi disponibles
|
||||
- ✅ Se connecter à un point d'accès
|
||||
- ✅ Émettre une requête HTTP vers un serveur
|
||||
- ✅ Lire et interpréter une réponse JSON
|
||||
|
||||
**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…).
|
||||
|
||||
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**.
|
||||
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