Hi there,
So bottom line is Both CAN’t be true,…
“Sleep” or “Listening for BLE packet” BLE is not magic. It’s just a radio.
For a device to “hear” a BLE packet, three things must be ON:
- RF front end (radio hardware)
- Clock system (timing is everything in BLE)
- BLE stack / controller
When you put an ESP32 (or most MCUs) into deep sleep, all of that is completely powered down.
No radio
No receiver
No packet detection
No chance of waking from BLE
Deep sleep exists for one reason:
Ultra-low power (µA range)
Keeping the radio on—even in a “listening” mode—costs orders of magnitude more power.
Typical comparison:
| Mode | Current Draw |
|---|---|
| Deep Sleep | ~5–20 µA |
| BLE idle/listen | ~1–10 mA |
That’s a 100x–1000x difference.
So if BLE wake were allowed in deep sleep, it wouldn’t really be “deep sleep” anymore.
Some chips (not ESP32) have special ultra-low-power radios or “wake-on-radio” features—but even those:
- don’t run full BLE stacks
- use simplified detection
- still consume more power than true deep sleep
I have this diagram I made for the (10) BLE sensor_Node project with 3 concurrent connections and 6 notifies. (demo & code is one here)
I useds the technique # 4 along with the #2 the timer.
https://forum.seeedstudio.com/t/multi-concurrent-ble-connections-with-seeed-round-display/293997
HTH
GL 
PJ 