ArtemiaandClaude Opus 5.5
379cd03bc5
M10 : consommation par mode, profil de courant en deep sleep. M11 : publish/subscribe, arborescence des topics. M12 : démarche de projet, structure multi-fichiers. Synthèse : carte du parcours. Figure du chenillard (M2) déplacée après son code. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
119 lines
5.5 KiB
Plaintext
119 lines
5.5 KiB
Plaintext
---
|
|
title: "Module 10 — Gestion de l'énergie"
|
|
---
|
|
|
|
## Objectifs du module
|
|
|
|
- Comprendre les enjeux de consommation d'un projet ESP32-S3 alimenté sur batterie.
|
|
- Distinguer les différents modes de veille (modem-sleep, light sleep, deep sleep).
|
|
- Mettre en œuvre un réveil programmé (timer) et un réveil sur évènement externe (GPIO).
|
|
- Concevoir un capteur autonome optimisé pour l'autonomie sur batterie.
|
|
|
|
## 1. Pourquoi se soucier de la consommation ?
|
|
|
|
Un ESP32-S3 alimenté en continu (Wi-Fi actif, calcul permanent) consomme couramment 100 à 250 mA. Sur batterie, cela vide une pile de 2000 mAh en moins d'une journée. Pour un capteur autonome destiné à fonctionner plusieurs mois sur pile, il faut exploiter les modes de veille pour ne consommer significativement que pendant les brefs instants où la carte est réellement active.
|
|
|
|
## 2. Les différents modes de veille
|
|
|
|
| Mode | Consommation typique | État conservé | Réveil possible via |
|
|
|--------------|------------------------|----------------------------------------|--------------------------------|
|
|
| Actif (normal) | 80-250 mA | Tout | — |
|
|
| Modem-sleep | \~20-30 mA | RAM, CPU actif par intermittence | Automatique (Wi-Fi/BT en veille) |
|
|
| Light sleep | \~0,8 mA | RAM et état conservés | Timer, GPIO, UART... |
|
|
| Deep sleep | \~10-150 µA | RTC RAM uniquement, redémarrage du programme | Timer, GPIO (EXT0/EXT1) |
|
|
|
|
{#fig-m10-consommation-modes}
|
|
|
|
::: {.callout-note title="Le deep sleep redémarre le programme"}
|
|
Contrairement au light sleep, sortir du deep sleep provoque un redémarrage complet du programme (comme après un reset) : `setup()` est ré-exécuté depuis le début. Seule la zone mémoire RTC (déclarée avec `RTC_DATA_ATTR`) est préservée entre deux cycles de deep sleep, ce qui permet de conserver un compteur ou un état minimal.
|
|
:::
|
|
|
|
## 3. Deep sleep avec réveil par timer
|
|
|
|
Cas d'usage typique : un capteur qui se réveille toutes les X minutes, effectue une mesure, l'envoie, puis se rendort.
|
|
|
|
{#fig-m10-cycle-deep-sleep}
|
|
|
|
```cpp
|
|
#define TEMPS_REVEIL_SECONDES 60
|
|
|
|
RTC_DATA_ATTR int compteurReveils = 0; // conserve sa valeur entre deux deep sleep
|
|
|
|
void setup() {
|
|
Serial.begin(115200);
|
|
delay(200);
|
|
|
|
compteurReveils++;
|
|
Serial.printf("Reveil numero %d\n", compteurReveils);
|
|
|
|
// ... effectuer ici la mesure, l'envoi de donnees, etc. ...
|
|
|
|
Serial.println("Retour en deep sleep.");
|
|
esp_sleep_enable_timer_wakeup(TEMPS_REVEIL_SECONDES * 1000000ULL); // en microsecondes
|
|
esp_deep_sleep_start();
|
|
}
|
|
|
|
void loop() {
|
|
// Jamais atteint : le deep sleep redemarre au setup()
|
|
}
|
|
```
|
|
|
|
## 4. Deep sleep avec réveil sur GPIO (bouton)
|
|
|
|
Autre cas d'usage : une carte qui reste endormie jusqu'à ce qu'un utilisateur appuie sur un bouton.
|
|
|
|
```cpp
|
|
#define BOUTON_REVEIL GPIO_NUM_4
|
|
|
|
void setup() {
|
|
Serial.begin(115200);
|
|
delay(200);
|
|
|
|
esp_sleep_wakeup_cause_t cause = esp_sleep_get_wakeup_cause();
|
|
if (cause == ESP_SLEEP_WAKEUP_EXT0) {
|
|
Serial.println("Reveil provoque par le bouton.");
|
|
} else {
|
|
Serial.println("Premier demarrage (pas un reveil).");
|
|
}
|
|
|
|
// ... traitement ...
|
|
|
|
esp_sleep_enable_ext0_wakeup(BOUTON_REVEIL, 0); // reveil sur niveau LOW
|
|
Serial.println("Deep sleep, en attente d'un appui bouton...");
|
|
esp_deep_sleep_start();
|
|
}
|
|
|
|
void loop() {
|
|
}
|
|
```
|
|
|
|
::: {.callout-note title="Broche compatible RTC obligatoire"}
|
|
Le réveil par GPIO (EXT0/EXT1) en deep sleep nécessite d'utiliser une broche appartenant au domaine RTC du microcontrôleur. Toutes les broches ne sont pas éligibles : vérifiez la documentation de votre référence de carte pour identifier les GPIO compatibles RTC.
|
|
:::
|
|
|
|
## 5. Bonnes pratiques pour un projet sur batterie
|
|
|
|
- Couper le Wi-Fi/BLE dès que la transmission de données est terminée (`WiFi.disconnect(true)`; `WiFi.mode(WIFI_OFF)`;).
|
|
- Réduire la fréquence CPU si le calcul n'est pas critique en performance (`setCpuFrequencyMhz()`).
|
|
- Limiter le temps d'éveil au strict nécessaire : mesurer, envoyer, dormir.
|
|
- Éviter les composants annexes qui consomment en continu (LED témoin, capteur non coupé) — prévoir une alimentation commutée si besoin (MOSFET de coupure).
|
|
- Pour la LED NeoPixel : elle consomme significativement plus qu'une LED simple (jusqu'à 60 mA à pleine luminosité blanche) — la couper explicitement (couleur noire) avant le deep sleep, et limiter sa luminosité (setBrightness) pour un usage sur batterie.
|
|
|
|
## 6. Exercice : capteur météo autonome
|
|
|
|
En combinant les modules précédents, réalisez un capteur qui :
|
|
|
|
- Se réveille toutes les 5 minutes via un timer deep sleep.
|
|
- Lit la température et l'humidité (BME280, Module 5).
|
|
- Affiche un court flash de couleur sur la LED NeoPixel selon la température (bleu/vert/rouge, comme au Module 5), puis l'éteint.
|
|
- Retourne en deep sleep.
|
|
- Affiche dans le moniteur série, à chaque réveil, le nombre total de réveils depuis la mise sous tension (compteur en `RTC_DATA_ATTR`).
|
|
|
|
## Checklist de fin de module
|
|
|
|
- [ ] Je sais différencier modem-sleep, light sleep et deep sleep.
|
|
- [ ] Je sais programmer un réveil par timer en deep sleep.
|
|
- [ ] Je sais programmer un réveil par GPIO en deep sleep, sur une broche compatible RTC.
|
|
- [ ] Je connais au moins trois bonnes pratiques pour réduire la consommation d'un projet sur batterie.
|
|
- [ ] J'ai réalisé le capteur météo autonome en deep sleep.
|