[TUTO] DeepSleep - Optimisation consommation d'un IOT ESPx sous Tasmota

2025-11-24T23:00:00Z
Bonjour à tous.

Mon premier Tuto (c’est donc le meilleur !)

Les IOT 230v ESP32 sous tasmota consomment un petit peu tout le temps (10kWh par an) ce qui peut faire l’objet d’optimisations voir de réduction drastique (jusqu’à 1,5 kWh par an), ce donc sera l’objet de ce tuto.

Les bases :
Avec un installation sans optimisation de tasmota sur un ESP (type Sonoff basic V1 ou Dual) consomme de l’ordre de 0,9W à 1,2W (relais On). C’est peut-être un peu moins avec les plus récents.

Optimisation de consommation de base (rappel, doc tasmota) :
En mode console sur l’IP de votre ESP/Tasmota, les commandes Sleep et WifiPower permettent de réduire la consommation à 0,5 - 0,7W, soit près de la moitié moins.
Sleep 50 met le CPU en pause pendant 50ms, Sleep 200 pendant 200ms (évidement).
Sleep 200 génère un peu plus de latence en général imperceptible pour l’utilisateur mais qui peut gêner avec certains capteurs (I2c par exemple) si Sleep > 50ms. SetOption60 2 permet d’avoir le CPU en Sleep mode « dynamique » également utile pour ces capteurs (sinon SetOption60 1).
image

WifiPower XX ajuste la puissance du WIFI de 0dBm à 17dBm (valeur par défaut, ne pas dépasser 17 !) en fonction de votre besoin de portée.
Wifipower 10 permet de réduire la consommation de 50mW, c’est peu si vous êtes sur secteur (1W par jour) mais ça compte sur batterie.
WiFiConfig 5 réduit également la consommations du Wifi (mode “Sleep Light”), latence 20 à 30ms.

Optimisation très basse consommation DeepSleep :
En mode DeepSleep, la consommation de votre ESP/Tasmota est réduite d’un facteur 50 par rapport aux optimisations de base, elle sera de l’ordre de 0,01W à 0,02W (et même beaucoup moins sur batterie et en fonction du temps de cycle). Du coup, un ESP simple peut même être alimenté par batterie pour des fonctionnalité « outdoor » de lecture de capteurs typiquement ou éventuellement des actions courtes et peu fréquentes (sinon faut une grosse batterie !).

Forcément, c’est plus contraignant que les optimisations de base mais cela reste très intéressant.

Le principe : Les ESP (8285, 8266, 32…) sont équipés d’une horloge interne programmable type « RTC ». Cela permet donc de mettre en veille profonde l’IOT (arrêt complet) en ayant programmé auparavant l’heure ou le délai de réveil.

Etape 1 : Faut viser juste !
Le plus délicat est qu’il faut relier la pin 8 de l’ESP à la pin 32 (valable pour ESP8285, 8266, à vérifier pour les autres ESP)) et c’est pas bien gros un ESP, c’est même de plus en plus petit plus on vieilli (environ 5mn de coté pour 8 pins) !
Astuce : utiliser du fil vernis (pour les transfos) très fin.
La pin 8, c’est la GPIO16 (XPD_DCC) qui s’active quand l’horloge le demande, la pin 32 (EXT_RSTB), c’est la fonction Reset de l’ESP, celle qui va donc le réveiller.

Etape 2 : Tasmota
Il faut juste configurer la GPIO16 sur hibernation dans le menu (configuration puis configuration modèle).
image

Etape 3 : Gestion par Jeedom
Le DeepSleep permet en gros 2 types de fonctionnements, une utilisation type « indoor », qui vise à réduire la consommation réseau (230v) de l’IOT, et « outdoor » sur batterie.
Je vais détailler le cas indoor un peu plus compliqué à mettre en oeuvre avec la commande d’un équipement par Jeedom. Forcément, l’équipement doit accepter un fonctionnement « temps pas réel du tout » comme du chauffage, une VMC qui ne sont pas à la minute près.
Le cas outdoor sera facile à décliner du premier.

Le principe est de paramétrer Tasmota pour que l’ESP se réveil toutes les minutes (par exemple), reste éveillé quelques secondes pour recevoir les ordres et envoyer ses états puis repasse en veille pour un nouveau cycle (conso divisée par 50 environ).
Comme l’ESP est en veille la plupart du temps, il faut adapter le fonctionnement Mqtt de Jeedom pour répéter les requêtes mosquito jusqu’à ce que l’ESP les reçoives.

Le scénario correspondant à ce fonctionnement ci-dessous se déclenche par le lancement de la VMC, lance un autre scénario (besoin perso), puis envoie des requêtes mqtt « ON » vers un Sonoff/Tasmota (via virtuel VMC_ON) toutes les secondes, jusqu’à ce que Tasmota envoie l’état ON (virtuel également). Dans ce cas, il reprogramme le DeepSleep à zéro (faut qu’il reste éveillé pour piloter le relais !),remet Téléperiode à une valeur standard et stoppe le scénario (pour arrêter les requêtes inutiles le reste des 60s).

La fonction de remise en veille (pour des cycles de 1mn) est plus simple. Dès que les conditions OFF sont remplies, envoie de la requête Mqtt « Off » (L’ESP est réveillé donc prise en compte immédiate), et quand le relais est OFF (pour éviter qu’il bagotte à chaque réveil), réactivation du DeepSleep (1mn) et réglage de la Télépériode (doit être inférieur à Deepsleep).

Une autre possibilité serait d’utiliser l’option « retain » de Mqtt à condition de pouvoir l’annuler (requête vide, non testé) pour pourvoir repasser en mode DeepSleep.

Un exemple de commandes Tasmota en Mqtt pour DeepSleep et Télépériode :

Pour conclure, un Sonoff qui est actif 6 à 8h va consommer environ 10kWh par an.
Avec les 2 optimisations, sa consommation passera à 1,6kWh par an (en première approche, mesures précises à venir) essentiellement a cause de l’alim 230v. Avec un ESP sur batterie en 3.5V, il ne restera quelques Wh.
Pour le cas inverse (actif 16h par jour), pensez utiliser une version avec relais normalement fermé (ZBMiniR2).

J’espère ne rien avoir oublié, ça reste un premier jet.
Bon Jee a tous.

2 « J'aime »