Battery sensors with ESPHome deep_sleep, and how to still get OTA updates onto them

Basic cycle

deep_sleep:
  id: deep_sleep_1
  run_duration: 20s
  sleep_duration: 10min

The device wakes, connects to Wi-Fi, reports for run_duration, then sleeps for sleep_duration. Every wake-up is a full reboot; the device doesn't resume where it left off.

Keep run_duration just long enough to connect and publish. Wi-Fi connection time dominates battery life. Static IP and fast_connect in the wifi: block can shorten it.

The OTA problem

A device that sleeps 10 minutes and wakes for 20 seconds almost never catches an OTA upload. Give yourself a way to keep it awake.

With Home Assistant: create a toggle helper (input_boolean.esphome_ota_mode) and mirror it on the device:

binary_sensor:
  - platform: homeassistant
    id: ota_mode
    entity_id: input_boolean.esphome_ota_mode
    on_press:
      then:
        - deep_sleep.prevent: deep_sleep_1
    on_release:
      then:
        - deep_sleep.enter: deep_sleep_1

Turn the helper on, wait for the next wake-up, upload, then turn it off.

With MQTT (as in ESPHome's docs): subscribe to an "ota mode" topic that triggers deep_sleep.prevent and a "sleep" topic that triggers deep_sleep.enter. Publish the ota-mode message retained, so the device sees it on its next wake-up.

Wake-up sources and wiring

• ESP8266: connect GPIO16 to RST, or the chip never wakes. The same connection can make flashing awkward on some boards; add a jumper.
• ESP32: wake by timer, or by a pin with wakeup_pin: (e.g. a door contact); several pins via esp32_ext1_wakeup.
• Use on_wake: for actions that should only run after a sleep-wake, not after a power-on reset.

Don't forget the hardware

Deep sleep only saves power if the board allows it. USB-serial chips, power LEDs and linear regulators on dev boards can draw far more than the sleeping ESP. Measure the real sleep current before trusting a battery estimate.