Calling esp_default_wake_deep_sleep() from ESPHome

I’m making a battery-powered button box, using an ESP32 and three buttons. The idea is, it would sleep basically all the time, and pushing a button would wake it (using esp32_ext1_wakeup’s ANY_HIGH mode) and send an MQTT message announcing which button was pushed.

Using information from this useful topic I have it working on an ESP32-WROVER-B module. Now I’m trying to implement it on an ESP-WROOM-32 module (presumably older) and failing.

The problem is, my lambda calling esp_sleep_get_ext1_wakeup_status() always returns 0 on the WROOM module; on the WROVER module it returns the GPIO pin number. This esp32 discussion includes, “Yes rev0 silicon has a bug where you have to run the default wake stub when coming out of deepsleep. So if you set a custom stub you should call the default from it.” I’m guessing that’s my problem; that somehow I need to “run the default wake stub.”

So… (I’m over my head here): I need to call esp_default_wake_deep_sleep() somewhere (?). However, if I change my lambda from:

    priority: 900
      - lambda: |-
          id(wake_up_reason) = esp_sleep_get_ext1_wakeup_status();


      - lambda: |-
          id(wake_up_reason) = esp_sleep_get_ext1_wakeup_status();

I get a module panic, including a long dump of warnings, brownout detections, and on and on.



I’m not familiar with that bug. But working around a hardware bug when using 3rd party library/environment sounds pretty impossible. Maybe doable when writing completely own code. But now you don’t know what ESPHome does before running your lambda.
I hate to say, but I recommend you to find another board.

Thanks, @drogfld; after some more groping around I’m coming to the same conclusion.
It causes me some grief because the chip that doesn’t work is a two-rows of pins “mini” configuration which was nice to put into a box (and I’ve already designed the box, getting ahead of myself), and I’m not finding many WROVERs in that configuration without waiting 6 weeks for delivery from China.
However, I’ve just realized (and confirmed) that ESP32-CAM modules work and fit (throwing the camera away), so I have a way forward.