Hi there,
So , I see the Git Hub case open, and the Known condition your facing,
Unfortunately On ESP32-class chips, deep sleep + external wake can involve pad hold in the RTC domain. If the firmware sets up EXT1 wake incorrectly (and doesn’t fully restore the pad config), the pin can come back from deep sleep latched in its last level. That’s exactly what the GitHub issue describes for C6 with WAKEUP_ALL_LOW. MicroPython Documentation+1
From that GitHub issue, the only configuration that behaves correctly on C6 is:
- Use
WAKEUP_ANY_HIGH, notWAKEUP_ALL_LOW. - Use a pulldown instead of pullup (invert the logic). GitHub
So the practical workaround for this :
- Invert the hardware wiring
- 10 kΩ pulldown from D2 to GND.
- Button from D2 to 3V3 (so “door open/pressed” = HIGH).
- Change the MicroPython setup to:
from esp32 import wake_on_ext1, WAKEUP_ANY_HIGH
from machine import Pin
WAKE_UP_PIN = const(2)
door_sw = Pin(WAKE_UP_PIN, Pin.IN, Pin.PULL_DOWN)
# Wake if the pin goes HIGH
wake_on_ext1(pins=[door_sw], level=WAKEUP_ANY_HIGH)
machine.deepsleep(29_000)
This avoids the broken WAKEUP_ALL_LOW path on ESP32-C6 and, per the issue report, does not leave the pin stuck after wake.
Optionally, right after boot you can also be extra-defensive and clear any pin hold:
import esp32
esp32.gpio_deep_sleep_hold(False)
…but the real fix is the wake mode workaround above, plus waiting for MicroPython to address the bug upstream.
HTH
GL 
PJ 