Setting wakeup_pin on ESP32 interrupts deep_sleep cycle

Hello,

I am trying to build a water leak sensor that will be batter powered. I’d like to use deep_sleep to keep the device in low power most of the time, but to have it wake when the sensor detects water. I am using a D32 Mini and this water sensor hooked to GPIO27.

Everything works great when I just use deep sleep. The device wakes on cycle and the probe works as well. However, when I set GPIO27 as a wakeup pin the sleep cycle goes haywire. It will wake at random short intervals even though the probe is perfectly dry. I’m not sure what could be going wrong given that unless the probe is in water it can’t complete the circuit. Can anyone please help me learn what I’m missing?

I recognizing that using the API with deep_sleep isn’t ideal. I plan to switch to MQTT after I get this POC working.

YAML:

esphome:
  name: water_sensor_1_esp32
  platform: ESP32
  board: wemos_d1_mini32

wifi:
  ssid: "*****"
  password: "*****"
  manual_ip:
    static_ip: XXX.XXX.XX.XX
    gateway: XXX.XXX.XX.XX
    subnet: XXX.XXX.XX.XX

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Water Sensor 1 Esp32"
    password: "*****"

captive_portal:

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:

esp32_touch:
#  setup_mode_true
  iir_filter: 10ms

binary_sensor:
  - platform: status
    name: "Hot Water Tank Leak Status"
  - platform: esp32_touch
    name: "Hot Water Tank Leak"
    id: water_tank
    pin: GPIO27
    threshold: 100


deep_sleep:
  id: deep_sleep1
  run_duration: 180s
  sleep_duration: 10min
  wakeup_pin: GPIO27

You need a pull-up resistor on the pin. Use the software activated internal one.

This is super helpful! Thank you. I think that I’m on the right track but am having trouble figuring out how to use the pull-up resistor with an esp32_touch sensor. I tried setting the mode: INPUT_PULLUP option in the deep_sleep: section of the config, but it seemed to make not difference.

When I try to set up the esp32_touch binary sensor with something like:

binary_sensor:
  - platform: esp32_touch
    name: "Hot Water Tank Leak"
    id: water_tank
    pin:
      number: GPIO27
      mode: INPUT_PULLUP
    threshold: 100

I get the error that the variable does not support full pin schemas. I’ve tried searching for examples of using the internal pull-up resistor with esp32_touch?

Ok, if that’s the case you are going to have to use a physical pull-up resistor on the wakeup pin. 100k is enough and won’t drain too much current while asleep.

This is an old thread but I also ran into the exact same issue and was able to stumble onto the solution so adding it here for future reference.
So the problem is that you should only specify wakeup_pin under deep_sleep if you choose to use this pin with a specific level based input (as opposed to touch). For wake up with touch delete this line and it is sufficient to specify the pin number as part of the esp32_touch sensor.
Also no pull up was needed for me to get this to work.

Hi I tried this but the touch is not waking up the device anymore. Anywhere to specify which binary sensor should wake up the device?

I don’t think the ESPHome touch wakeup will work after looking at the code. Kindly chime in to my Github question:

1 Like

Hey everyone! :star2:

So, I’ve got some good news to share about fixing that deep_sleep wake_up issue on the ESP32_S2 with ESPHome.

You know how the docs say to set up deep_sleep with touch_wakeup: true? Well, like many of you, I found out the hard way that it’s not as straightforward as it seems. :sweat_smile: After a bit of sleuthing, I finally cracked the code! Here’s the setup that did the trick for me:

deep_sleep:
  touch_wakeup: true
  wakeup_pin: ${pin_touch}

Now, don’t freak out if you spot a little warning in the logs like this one:

[2024-04-03 03:47:31.612] [D][esp-idf:000]: E (63191) sleep: Conflicting wake-up trigger: ext0

Everything’s still running smoothly with the touch wake_up feature, no extra headaches. :nerd_face:

Hope this fix helps out anyone else banging their heads against the same problem. Hang in there, folks! :rocket:

Cheers! :v: