ESP32 Deep Sleep and massive power drain

pdn · December 19, 2024, 8:48am

Hello, I recently purchased the board shown in the photo.

It is equipped with an ESP32 designed to use a 18650 battery. I want to use the board to monitor my mailbox with two cylindrical magnetic reed sensors (one for detecting the opening to insert mail and another for detecting the door opening to retrieve mail).

Before installing the board, I wanted to test its functionality, and after just 5 days of simulating an opening, the board failed to start, and I noticed that the battery was drained. I recharged the battery and observed that in just 3 days, the voltage dropped from 4.10V to 3.75V, indicating that it consumes a significant amount of power even in Deep Sleep mode.

The board is always in deep_sleep mode, and it wakes up only when one of the 2 sensors goes up.

Here my configuration:

substitutions:
  board_type: esp32dev
  api_reboot_timeout: 0s
  device_name: "mailbox-monitor"
  friendly_name: "Monitor Cassetta della Posta"
  board_type_name: "ESP32 Battery Powered"
  api_encryption_key: "****"
  ota_password: "****"
  ip_address: 0.0.0.0
  ip_subnet: 0.0.0.0
  ip_gateway: 0.0.0.0
  ip_dns1: 0.0.0.0
  ip_ota: ${ip_address}
  logger_level: DEBUG
  # GPIO to monitor
  wakeup_pin_insert: "25"
  wakeup_pin_withdraw: "26"
  
    
esphome:
  name: ${device_name}
  friendly_name: ${friendly_name}
  comment: "${board_type_name}"
  compile_process_limit: 1
  on_boot:
    # Execute before WiFi and API connection
    - priority: 300
      then:
        - script.execute: reset_sensors
        - script.execute: recover_wakeup_info
        - script.execute: validate_wakeup

esp32:
  board: ${board_type}

logger:
  level: ${logger_level}

globals:
  - id: wakeup_cause
    type: esp_sleep_wakeup_cause_t
    initial_value: ESP_SLEEP_WAKEUP_UNDEFINED

api:
  reboot_timeout: ${api_reboot_timeout}
  encryption:
    key: ${api_encryption_key}
  on_client_connected:
    then:
      - script.execute: report_data
  
ota:
  - platform: esphome
    password: ${ota_password}

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  fast_connect: true
  manual_ip: 
    static_ip: ${ip_address}
    subnet: ${ip_subnet}
    gateway: ${ip_gateway}
    dns1: ${ip_dns1}
  use_address: ${ip_ota}

sensor:
  - platform: wifi_signal
    name: "WiFi Signal"
    update_interval: 300s

deep_sleep:
  id: dp
  wakeup_pin_mode: KEEP_AWAKE
  esp32_ext1_wakeup: 
    mode: ANY_HIGH
    pins:
      - number: ${wakeup_pin_insert}
        mode: INPUT
      - number: ${wakeup_pin_withdraw}
        mode: INPUT
          
binary_sensor:
  - platform: template
    id: door_insert
    name: "Porta Inserimento"
    device_class: door
  - platform: template
    id: door_withdraw
    name: "Porta Ritiro"
    device_class: door

output:
  - platform: gpio
    id: notification
    pin: GPIO16

script:
  - id: reset_sensors
    then:
      - lambda: |-
          // Reset all sensor template to OFF
          id(door_insert).publish_state(false);
          id(door_withdraw).publish_state(false);

  - id: recover_wakeup_info
    then:
      - lambda: |-
          id(wakeup_cause) = esp_sleep_get_wakeup_cause();
          uint64_t GPIO_reason = 0;

          switch(id(wakeup_cause)) {
            case ESP_SLEEP_WAKEUP_EXT0: ESP_LOGW("wakeup", "Wakeup caused by external signal using RTC_IO"); break;
            case ESP_SLEEP_WAKEUP_EXT1: ESP_LOGI("wakeup", "Wakeup caused by external signal using RTC_CNTL"); break;
            case ESP_SLEEP_WAKEUP_TIMER: ESP_LOGW("wakeup", "Wakeup caused by timer"); break;
            case ESP_SLEEP_WAKEUP_TOUCHPAD: ESP_LOGW("wakeup", "Wakeup caused by touchpad"); break;
            case ESP_SLEEP_WAKEUP_ULP: ESP_LOGW("wakeup", "Wakeup caused by ULP program"); break;
            default: ESP_LOGW("wakeup", "Wakeup was not caused by deep sleep: %d", id(wakeup_cause)); break;
          }

  - id: validate_wakeup
    then:
      - lambda: |-
          // If the wakeup was not triggered by a monitored pin this was a first boot/reset
          // we can go in deep sleep mode
          if (id(wakeup_cause) != ESP_SLEEP_WAKEUP_EXT1) {
              id(dp).begin_sleep(true);
          }
          
  - id: report_data
    then:
      - logger.log:
          level: DEBUG
          format: "Reporting data to HA . . ."
      - lambda: |-
          uint64_t GPIO_reason = 0;

          // If we are here, this condition should be always TRUE
          if (id(wakeup_cause) == ESP_SLEEP_WAKEUP_EXT1) {
              GPIO_reason = esp_sleep_get_ext1_wakeup_status();

              if (GPIO_reason & (1ULL << ${wakeup_pin_insert})) {
                  ESP_LOGI("wakeup", "Wakeup INSERT (GPIO%d)", ${wakeup_pin_insert});
                  id(door_insert).publish_state(true);
              }
              else if (GPIO_reason & (1ULL << ${wakeup_pin_withdraw})) {
                  ESP_LOGI("wakeup", "Wakeup WITHDRAW (GPIO%d)", ${wakeup_pin_withdraw});
                  id(door_withdraw).publish_state(true);
              }
              else {
                  ESP_LOGE("wakeup", "Wakeup caused by unknown pin");
                  ESP_LOGE("wakeup", "Wakeup Bitmask: %lld", GPIO_reason);
                  // In this case we can interrupt the script and go into deep spleep mode again
                  id(dp).begin_sleep(true);
                  return;
              }
          }
          else {
              // We should never arrive here
              ESP_LOGE("wakeup", "Reporting data requested but wakeup cause is wrong: %d", id(wakeup_cause));
              id(dp).begin_sleep(true);
              return;
          }
      - output.turn_on: notification
      - delay: 1s
      - output.turn_off: notification
      - logger.log:
          level: INFO
          format: "Data reported, waiting 5sec . . ."
      - delay: 5s
      - script.execute: reset_sensors
      - logger.log:
          level: INFO
          format: "Reverted all to OFF, waiting 60sec . . ."
      # Add a long delay permetting multiple insertions/long withdraw without continous deep sleep and wakeup
      - delay: 60s    
      - logger.log:
          level: INFO
          format: "Entering Deep Sleep. Bye!"
      - deep_sleep.enter

Any suggestion? It’s and HW problem (as I suspect) or something wrong in my configuration?

RonnieLast · December 19, 2024, 11:21am

Hi, two things to do - one is to attach directly to the serial and ensure that the ESP is sleeping as per how you coded it - you never know, maybe noise is causing wake-ups or something similar. Second you should either install a multimeter in series with the battery or supply 4.0v DC and a multimeter in series into the battery connector (with the battery detached); then measure the current draw during sleep.
What I suspect you find is that the DC-DC converter is running constantly at a high current and isn’t able to sleep and is just very inefficient when operating at low power. You should be able to identify the DC converter by looking at the board too, this would allow you to obtain the datasheet and understand whether it’s really suitable to be run off battery permanently or whether the battery should just be used as a backup to a 5v supply.

pdn · December 19, 2024, 11:39am

I’m pretty sure the board did not wake up because a blue LED go on once it happen and I had never seen it.

I’ll try with the multimeter in series with the battery in order to understand the power usage during deep sleep.

Thank you.

Does anyone have some suggestions on a similar board that works well in deep sleep mode?

pdn · December 19, 2024, 1:49pm

My multimeter do not allow to monitor a so low current, so I have checked for the DC-DC step-down IC and should be this:

AMS1117-3.3
https://www.digikey.com/en/products/detail/umw/ams1117-3-3/22482148

Looking into the datasheet I have found this value:

Quiescent Current (Iq): 10mA

I have limited electronics knowledge but I think that the problem is this. With a constant power drain of at least 10mA (I have to sum ESP in deep sleep and other components) and a battery of about 3000mAh, I have a lifetime of about 10 days.

Unuseful board!

Karosm · December 19, 2024, 2:26pm

There are high changes you find also a boost converter onboard.
Do you have 5V on that pin when powered from battery.
Also be aware that 1117 has 1V dropout voltage and that battery management chip turns off at X voltage, so your battery might have still plenty of juice when board turns off. And 3000mAh battery from AE might be 2000mAh…

pdn · December 19, 2024, 3:14pm

Checked, no pin at 5V

Ok, so this board has a lot of problems

I have just ordered a different model, seems more robust, I hope

Haldi · February 16, 2025, 10:09am

i got pretty much the same board from DIY-more and have similar issues.

The main problem is that is has coilwhine… a high whistle when entering certain power states. Kinda annoying.

Also the DeepSleep is software bugged in ESPhome.

Uses 1.8mA when entered wrongly.

and 60MicroAmps when entered correctly.

Sadly until now i haven’t found out when it happens.

github.com/esphome/issues

ESP32 high power usage in deep sleep.

opened 10:02AM - 30 Aug 19 UTC

closed 10:26PM - 05 Dec 20 UTC

craggyh

Type: ESP32 integration: deep_sleep stale

**Operating environment/Installation (Hass.io/Docker/pip/etc.):** Docker *…*ESP (ESP32/ESP8266, Board/Sonoff):** ESP32 **Affected component:** Deep Sleep **Description of problem:** I have an issue that happens across several different ESP32 devices all consuming high power when in deep sleep mode. This makes them unusable for battery projects as typical 3000ma batteries will drain in a few weeks or even days sometimes. Similar to this issue - espressif/arduino-esp32#1113 I have for example a Lolin32 board which is capable of 150 μA in deep sleep but mine draws 1.7ma. I have other modules from different manufacturers all the same issue with 1.5ma to 2.5ma absolutely minimum when in deep sleep but far from the microamp draw these boards are capable of. To eliminate outside influence I have an ESP32 board with uart chip, LDO, LEDs and all unnecessary components removed leaving basically just the ESP32 chip and some jumper wires for power. It too draws 1.5ma in deep sleep. This setup should be capable of sub 100μA. So my conclusion is that ESPhome must be leaving the wifi/ble powered on as described in the link above. Is there any way to issue a wifi turn off command through esphome? The solutions in the link are all based on Arduine IDE native commands. **Problem-relevant YAML-configuration entries:** ```yaml PASTE YAML FILE HERE ``` **Logs (if applicable):** ``` PASTE DEBUG LOG HERE ``` **Additional information and things you've tried:**

Edit: Got it… WiFi!

github.com/espressif/arduino-esp32

Deep-Sleep needs WiFi switched OFF for low current consumption

opened 03:57PM - 14 Feb 18 UTC

closed 10:52PM - 14 Aug 19 UTC

rudi48

Status: Stale

### Hardware: Board: WEMOS LoLin32 Core Installation/update date: Jun 8… 2016 IDE name: Arduino 1.8.5 MacOS Flash Frequency: 80Mhz Upload Speed: 115200 ### Description: Unfortunately it is not explained that for **deep-sleep** with about 150 uA mentioned **current consumption** you **need to switch OFF WiFi befor**e, if it was in use. If you do not do that the **current consumption** is about **1600 uA - about 10 time what has been told.** All **documentation** I found to that topic **did not tell about current consumption**. **I propose to mention it on all documentation, where the 150 uA are mentioned.** You can **save** in the case of an **internal** GPIO pull-down input **another 50 uA**, with an **external 120 KOhm resistor.** Regards, Rudolf ### Sketch: ```cpp #include <esp_wifi.h> ... esp_wifi_stop(); esp_deep_sleep_start(); // 0.25 mA sleep current (battery) ``` ### References: esp32_technical_reference_manual_en.pdf version 2.9 - does not tell about wifi_stop esp32_datasheet_en.pdf version 2.1 - does not tell about wifi_stop Table 4: Power Consumption by Power Modes Deep-sleep The ULP co-processor is powered on. 150 μA esp32_eco_and_workarounds_for_bugs_in_esp32_en.pdf verion 1.4 - does not tell about wifi_stop esp32_hardware_design_guidelines_en.pdf version 2.1 - does not tell about wifi_stop esp-wroom-32d_esp32-wroom-32u_datasheet_en.pdf version 1.0 - does not tell about wifi_stop Table 7: Power Consumption by Power Modes Deep-sleep The ULP co-processor is powered on. 150 μA https://dl.espressif.com/doc/esp-idf/latest/ Search for "deep" shows 11 Search Results Search for "wifi-stop" shows 1 Search Result - does not tell about power saving https://github.com/espressif/esp-idf/blob/master/docs/api-reference/system/sleep_modes.rst n deep sleep mode, wireless peripherals are powered down. Before entering sleep mode, applications must disable WiFi and BT using appropriate calls ( esp_bluedroid_disable, esp_bt_controller_disable, esp_wifi_stop). Note: but it does not tell about "current consumption". https://github.com/espressif/esp-idf/blob/master/components/esp32/include/esp_sleep.h * esp_deep_sleep does not shut down WiFi, BT, and higher level protocol * connections gracefully. * Make sure relevant WiFi and BT stack functions are called to close any * connections and deinitialize the peripherals. These include: * - esp_bluedroid_disable * - esp_bt_controller_disable * - esp_wifi_stop Note: but it does not tell about "current consumption".

    on_state:
      then:
        if:
          condition:
            binary_sensor.is_off: door
          then:
            - delay: 2s
            - wifi.disable:
            - deep_sleep.enter:
                id: deep_sleep_1
                sleep_duration: 12h

by manually disabling WiFi before entering DeepSleep it works!

You can see the difference between first and second time DeepSleep?

donburch888 · March 8, 2025, 4:14am

Not the main issue for you; but I would suggest that your wifi: parameters are not helping.

Wi-fi is re-established every time your ESP32 wakes up, and you have specified fast_connect and a manual_ip address to save your ESP32 having to look up DNS etc
… but 0.0.0.0 isn’t a real address, and instead of reducing the amount of work, you have increased it to decide what actual physical IP address parameters to use.

Assuming you are only using this device on one network, I recommend putting in the actual static manual_ip parameters.

FWIW on my home network I am specifying manual_ip in my ESPHome devices; and also have the same devices with the same IP addresses manually assigned in my routers DHCP list - belt and braces, but also good for documentation.