Update README.md

README.md

@@ -52,7 +52,9 @@ On the master branch, I'm using [task notifications](https://www.freertos.org/RT
 <ins>The main thread is more efficient than the one in the V2 branch</ins> (which employs [busy wait](https://github.com/TIT8/shelly_esp32_button_espidf/tree/v2?tab=readme-ov-file#why-busy-wait-the-button-status-and-not-polling-it-or-be-notified-by-interrupts) for monitoring button status instead of being notified by interrupts).   
 In the main task, interrupts are enabled and disabled only on the GPIO pin used and [on the core](https://github.com/TIT8/shelly_esp32_button_espidf/blob/1ccbeb450f857612228f9be3fbcbf5ec52a6ecf3/src/main.c#L190) where the task is pinned, akin to a critical section, as outlined in the [official documentation](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/freertos_idf.html#disabling-interrupts). [^4]
 
-The code handles the scenario where the button is continuously pressed; after a while, the main thread will enter a blocked state. You can refer to [the relevant part of the firmware](https://github.com/TIT8/shelly_esp32_button_espidf/blob/88ec38896c9c9199dd878153d043701d34ed38f2/src/main.c#L265) for more details.
+The code handles the scenario where the button is continuously pressed; after a while, the main thread will enter a blocked state. You can refer to [the relevant part of the firmware](https://github.com/TIT8/shelly_esp32_button_espidf/blob/88ec38896c9c9199dd878153d043701d34ed38f2/src/main.c#L265) for more details.   
+
+Obviously, putting the ESP32 to sleep until it's awakened by the GPIO would be much more efficient. However, the latency from button press to waking the CPU, connecting to WiFi and MQTT, and sending commands will decrease the responsiveness of the application (on the ESP32, you cannot put the CPU into deep sleep without turning off the radio).
 
 [^4]: Also a useful [topic](https://esp32.com/viewtopic.php?t=35019).