Il est indéniable que le fait que Tasmota sache passer en deepsleep automatiquement après l'envoie des données est un avantage.
Il est probable qu'il soit possible de faire de même avec ESPHome avec le trigger on_value sur les sensors (https://esphome.io/components/sensor/#sensor-on-value) mais je n'ai pas testé.

J'ai profité du WE pour tester le deepsleep sur Tasmota qui offre un gros avantage pour un fonctionnement sur batterie, là ou ESPHome met 35s pour démarrer et se connecter au Wifi (surement améliorable cela dit), Tasmota met ~7s (si le wifi capte bien)
Avec 7s de run pour 293s de deepsleep et une batterie de 4000mAh on tombe a plus d'un mois d'autonomie

Si votre Wifi capte mal et que vous préférez le laisser un peu tourner pour avoir une chance d'accrocher le wifi avant de retomber en deepsleep il faut lire https://tasmota.github.io/docs/DeepSleep/#overcome-network-issues

A noter que dans mon cas ou le Wifi capte mal, avec Tasmota je n'avais quasi jamais le wifi qui fonctionnait alors qu'avec ESPHome ca fonctionnait 90% du temps.
La documentation ici: https://tasmota.github.io/docs/Commands/#wi-fi indique que par défaut WifiPower est à 17 et la documentation ici https://tasmota.github.io/docs/WifiPower/ indique de ne pas dépasser 17.
Croyant la doc à la ligne j'ai mis un peu de temps à comprendre mais finalement en envoyant la commande WifiPower, j'ai eu 16 comme retour et non 17 ! Depuis que j'ai envoyé la commande WifiPower 17 j'ai le même comportement wifi qu'avec ESPHome.

concernant le deepsleep de tasmota j'ai bossé pour de Winky avec un autoconf spécial qui réveil, lit les données les envois et repasse en sleep. C'est ici

Sinon tasmota le fait très bien par défaut, sur ESP32 il suffit de mettre l'envoi de la télémetrie à 10 secondes ou 300 secondes (5 minutes), c'est comme ça que tasmota sait qu'il doit activer le deep sleep et il se remet en sleep pour la durée définie dans le DeepSleepTime (par exemple 5 min)

Sur ESP32 aucun besoin des rules ou autre hardware juste les 2 paramètres ci dessus.

Issue de la documentation

Let's assume you have set DeepSleepTime 3600 (one hour) and TelePeriod 60 (one minute). The device will first wake at 8:00 am. The device will boot and connect Wi-Fi. Next, the correct time must be synchronized from one of the NTP servers and initial telemetry is sent.

DeepSleep is then triggered after the next TelePeriod event. In this example, it will occur after one minute. Telemetry will be collected and sent (e.g., via MQTT) and DeepSleep can happen. First, Offline is published to the LWT topic on MQTT. It then calculates the new sleeping time to wake-up at 9:00 am (3600 seconds after the last wake-up). At 9:00 am this same sequence of events happens again.

If you want to minimize the time that the device is in operation, two special values for TelePeriod exist: 10 seconds and 300 seconds. Using either of these two exact values will prevent waiting for the next telemetry. DeepSleep will be triggered within a few second of the time being synchronized rather than waiting for the TelePeriod.

Pour ceux qui voudrais alimenter leur Denky sur batterie et qui tomberait sur ces échanges, je vous propose ci dessous une config ESPHome qui permet de faire fonctionner le Denky avec HomeAssistant et qui fait des cycles 1 minute en activité / 4 minutes en veille/deepsleep.

Il est certainement possible de faire pareil avec le firmware tasmota qui vient avec le Denky mais si j'ai bien trouvé comment configurer le temps ou il reste en deepsleep (commande DeepSleepTime) je n'ai pas compris par quelle mécanique l'esp décide de passer en deepsleep (ne voulant pas utiliser MQTT, donc tasmota, je n'ai surtout ni cherché ni testé)

Quelques information avant de passer à la configuration.
En fonctionnement j'ai mesuré une consommation de 0.14 à 0.16Ah (140 à 160mAh). En deepsleep 0.00Ah, la valeur réel n'est forcement pas 0 mais mon appareil de mesure n'est pas assez précis pour mesurer le faible courant en deepsleep.

Avec une batterie externe de 4000mAh, sans deepsleep l'esp va donc tenir ~ 4000 / 150 = 26h
J'ai pu vérifié en pratique ce calcul théorique.
En extrapolant, avec une batterie de 20'000 mAh (courant de nos jours) on monte a 5 jours et demi. Si vous etes en deepsleep 4/5 du temps, ca donne 27 jours. A vous d'ajuster le curseur entre fréquence d'actualisation des données et fréquence de recharge de la batterie..
Attention tout de même entre la théorie et la pratique :

• La consommation en deepsleep n'est pas nul ce qui va rogner à la marge la durée de vie de la batterie.
• Dans la configuration ci dessous, le mode deep sleep ne s'active pas tant que l'ESP n'est pas connecté au Wifi. Si comme chez moi votre wifi capte mal, au lieu de rester actif 60s toutes les 4m, il va rester plus longtemps ce qui va diminuer la durée de vie pratique de la batterie. Si votre priorité est la durée de la batterie quitte à rater des mesure, il est possible d'enclencher le deepsleep même si le wifi n'as pas connecté. Pour cela reitrer priority: 250 dans on_boot: , voir https://esphome.io/components/esphome.html#on-boot

La configuration ESPHome ci dessous permet de désactiver le deepsleep depuis un "toogle" HomeAssistant.
Il y a plusieurs intérêts à pouvoir faire ca:

• Couper le deepleep pour avoir assez de temps pour faire une mise à jour OTA.
• Avoir temporairement une actualisation plus rapide des données

Il faut donc commencer par créer le toogle pour cela sur HomeAssistant allez dans Settings -> Devices & Services -> Helpers (en haut) -> Create Helper (en bas). Choisissez Toogle en bas de la liste, donner lui comme nom disable_sleep_on_teleinfo. Par défaut il sera sur off (donc deepsleep actif), si vous le passez à on le deepsleep se desactivera tant qu'il ne repasse pas a Off

Pourquoi un choix de run_duration a 1 minutes ? C'est assez conservateur, l'ESP met au moins 35s a se connecter au Wifi et avec la configuration ci dessous il ne passera de toute facon pas en deepsleep avant d'être connecté. Vous pouvez probablement baisser a 45s, il faudra pas contre changer update_interval: 20s par une frequence plus rapide, probablement 5s à 10s.

La configuration est adapté à un compteur en tarif BASE et en mode Historique.
Si vous etes en mode Standard il faut passer baud_rate: 1200 à 9600 et historical_mode: true a false.d
Si vous etes en HP/HC il faudra ajouter des sensors pour récupérer HCHC et HCHP.
Il y a deux sensors pour PAPP pour renvoyer la valeur en VA et en W. J'ai lu HomeAssistant ne traite pas pareil l'historisation des valeurs en VA et W.

La configuration permet une integration direct dans le dashboard Energy de HomeAssistant

Voici donc une configuration ESPHome

esphome:
  name: teleinfo
  friendly_name: Teleinfo
  project:
    name: my.teleinfo
    version: "1.0"
  on_boot:
    priority: 250  # Do not enter deep sleep before Wifi is on | https://esphome.io/components/esphome.html#on-boot
    then:
      - script.execute: should_deep_sleep

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

deep_sleep:
  run_duration: 1min
  sleep_duration: 4min
  id: deep_sleep_control

script:
  - id: should_deep_sleep
    mode: queued
    then:
      - delay: 10s # Safe guard
      - if:
          condition:
            binary_sensor.is_on: disable_deep_sleep
          then:
            - logger.log: 'Prevent deep_sleep'
            - deep_sleep.prevent: deep_sleep_control
          else:
            - logger.log: 'Deep_sleep enabled'
            - deep_sleep.enter: deep_sleep_control

binary_sensor:
  platform: homeassistant
  id: disable_deep_sleep
  entity_id: input_boolean.disable_sleep_on_teleinfo
  on_press:
    then:
     - logger.log: "Prevent deep sleep ON"
     - deep_sleep.prevent: deep_sleep_control
  on_release:
    then:
     - logger.log: "Prevent deep sleep OFF"
     - deep_sleep.enter: deep_sleep_control
 
web_server:
  port: 80
  include_internal: true

esp32:
  board: denky_d4

uart:
  rx_pin: GPIO8
  baud_rate: 1200 # 1200 for Historical Mode, 9600 for Standard Mode
  parity: EVEN
  data_bits: 7
  stop_bits: 1

teleinfo:
  update_interval: 20s
  historical_mode: true

sensor:
  - platform: teleinfo
    tag_name: "BASE"
    name: "BASE"
    unit_of_measurement: "Wh"
    icon: mdi:flash
    device_class: "energy"
    state_class: "total"
  - platform: teleinfo
    tag_name: "PAPP"
    name: "PAPP"
    unit_of_measurement: "VA"
    state_class: "measurement"
    device_class: "apparent_power"
    icon: mdi:flash
  - platform: teleinfo
    tag_name: "PAPP"
    name: "POWER"
    state_class: measurement
    unit_of_measurement: W
    device_class: power
    icon: mdi:flash
  - platform: teleinfo
    tag_name: "IINST"
    name: "IINST"
    unit_of_measurement: "A"
    icon: mdi:flash
    state_class: "measurement"
    device_class: "current"

text_sensor:
  - platform: teleinfo
    tag_name: "OPTARIF"
    name: "OPTARIF"


# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: !secret api_password

ota:
  password: !secret ota_password

Sinon on travaille sur la production de la version auto alimenté avec @Ferrader, plus de détail ici, c'est peut être ça dans ce cas qu'il te faut mais il faudra attendre encore quelque temps.

J'ai donc acheté ca:
https://www.diymore.cc/collections/hot-sale/products/18650-battery-shield-v8-mobile-power-bank-3v-5v-for-arduino-esp32-esp8266-wifi

Tout marche, mais en revanche, ca ne tient pas plus de 24h... Auriez-vous un autre module à me recommander ? Faut-il activer une option pour réduire la conso?

Merci !

faut-il obligatoirement alimenter le Denky-D4 en USB ? J'ai cru comprendre qu'il pouvait s'alimenter avec la connection à I1 et I2.

Il s'alimente en USB Seulement, la 3eme borne ne délivre pas assez de puissance pour du WiFi en Temps Réel comme Tasmota

doit-on brancher I1 et I2 dans un ordre particulier ? Peut-on permuter comme on veut ?

Pas tout tout, pas d'ordre et ils peuvent être inversés

confirmez-vous que le firmware Tasmota est bien flashé pour les module achetés sur Tindie ?

Tout à fait

Charles