No big difference in energy saving in Light and Deep sleep?

I need you to check and correct my thoughts.

I’m learning energy saving in ESP32 and found a thing which looks strange for me.
Let’s consider a standard weather station sending its sensor data to the Blynk server every 5 min (300 sec). It consumes about 200 mA when active and a little energy when sleeps: 0.8 mA in Light Sleep, 0.15 mA in Deep Sleep (0.15 in ULP on, 0.01mA if ULP off, I do not turn off ULP now)

Looking to my Light Sleep sketch I see:
Starting v2.02
[61] Connecting to XXX
[1151] Connected to WiFi
[1151] IP:
___ __ __
/ _ )/ /_ _____ / /__
/ _ / / // / _ / ’ /
/ /_, / // / /_
__/ v0.6.1 on ESP32

[1224] Connecting to [](
[2663] Certificate OK
[3264] Ready (ping: 600ms).
[3656] Time sync: OK
[3793] 0 38.849396
11:30:25 25°С 39%
Brightness Slider VPIN_Bright value is: 2
[3861] Voltage: 3160.50
MQTT connecting …connected
[4121] Subscribe: 1
[5123] Go to sleep in 1 sec…
[126123] Bootcount: 1
[126128] Connecting to [](
[128358] Certificate OK
[128859] Ready (ping: 500ms).
[129250] Time sync: OK
Brightness Slider VPIN_Bright value is: 2
[129388] 1 38.681549
11:32:30 25°С 39%
[129454] Voltage: 4002.25
[129523] Go to sleep in 1 sec…
[250524] Bootcount: 2

That means that after restart it takes 5 sec [5123] to start, initialize WiFi, connect to Blynk, run the measurement cycle, send everything to Blynk and MQTT and go to Light Sleep.
It wakes up at [126123], repeat the cycle and goes to Light Sleep again at [129523]
129523-126123 = 3400 (3.5 sec)
Looking to other cycles we see the same picture:
[1487300] Bootcount: 12
Wakeup caused by touchpad
[1487304] Connecting to
[1489071] Certificate OK
[1489574] Ready (ping: 501ms).
[1489964] Time sync: OK
Brightness Slider VPIN_Bright value is: 0
[1490101] 0 38.704437
11:54:56 24°С 39%
[1490169] Voltage: 4004.00
[1490239] Go to sleep in 1 sec…
[1611239] Bootcount: 13

1490239-1487300 = 2939 (3 sec)

So I expect that restart after Deep Sleep takes longer than running a cycle after Light Sleep (extra initialization required, etc). But “active” time is a major energy consumption!

5 sec * 200 mA (Active) + 295 sec * 0.15 mA (Deep) = 1000 + 44.25 = 1044 mAsec
3 sec * 200 mA (Active) + 297 sec * 0.8 mA (Light) = 600 + 237.6 = 838 mA

2 sec saving (shorter Active period when using Light Sleep) makes total energy consumption per cycle less then in Deep Sleep. These 2 sec beets even Hibernation extra saving.

I guess ESP8266 looks similar. And as it requires external RTC memory to save variables, some hardware modifications to wake up (connect RST to another pin) Light Sleep may become a good alternative to the Deep Sleep.

What do you think?

I’ve not done any deep/light sleep experiments with the ESP32, but I did do some with the ESP8266.

One thing I found was that assigning a static IP address in your code saved a lot of time. Routers keep a table of connected devices and tend to purge this after a fairly short while when a device disconnects. When a “new” device (one that’s no longer in that table) attempts to connect via DHCP, the router and the device do a little dance where they negotiate an IP address and the router sends the other data (gateway, DNS Server etc) to the ESP. This all takes time, whereas with a static IP it’s more of an instantaneous thing that bypasses all the DHCP negotiation.
Even when the router does have an entry in its routing table (which will be the case in this example with just a few seconds of sleep time), part of the process is still required and it takes longer than with a static IP.

The other thing is that once you have the Wi-Fi connection, you are having to wait for both the Blynk and MQTT connections to be established.
Is your MQTT server a cloud service, or a local server?
If it’s a local server then there’s a simple solution, which is to install Node-Red and the Blynk plug-in for Node-Red and let that take care of sending the data to Blynk. That way you only have to establish the MQTT connection, which will be quicker.
This is the approach I take with my weather station, although I don’t use any form of sleep as I need to constantly receive wind speed, wind direction and rainfall data via interrupt routines (and I have power available for my ESP8266 anyway).

The other thing to think about (any you may already have done this) is what happens if you can’t establish a connection to either Wi-Fi, Blynk or MQTT.
If you’re using Blynk.begin the this will block all other code execution and keep trying to connect until either it does connect, or the battery is flat.
Blynk config and connect are the better solution, along with a process that limits the number of attempts to make the various connections.

Also, with sleep routines you have to break the Blynk rules of using timers and keeping the void loop clean. You actually want the void loop to run just once, then go back to sleep.

Have you seen this topic?..



Yes, Peter, I’ve seen this project. It is really full of interesting ideas.

Static IP
For the real project I’m pretty I’ll use it instead of the DHCP.
It looks I’ve seen a debug message during the WiFi re-connection like “IP is already known, connection will be faster”.

Node-Red - Blynk plugin
Do you mean []( Node-RED blynk Websockets version) ?
I see 4 packages with “blynk”: node-red-contrib-blynk-api, node-red-contrib-blynk-bridge, node-red-contrib-blynk-websockets, node-red-contrib-blynk-ws
Looks interesting and promising. I thought about switching to Blynk API instead of “Blynk.connect”. But MQTT looks very nice. Is it suitable in my case?
I actually use ioBroker with Node-Red inside it. I mean my Node-Red uses Sonoff’s driver installed in the ioBroker.

Will the following flow be OK?

  • ESP sends MQTT update with its sensors data to ioBroker/Sonoff
  • Node-Red forwards MQTT data to Blynk

What about backward connections? I like to use Blynk app to configure ESP.
Which approach is better:

  1. Node-Red reads parameters from Blynk, publishes to ioBroker/Sonoff, ESP receives them by MQTT
    I’m afraid there will be too much extra work (duplicate every parameter in Node-Red, MQTT)
  2. ESP sometimes (once per hour) connects to the Blynk server itself and receives new data.
    Looks not good for me.
  3. Blynk has an extra button which instructs Node-Red to set an MQTT parameter that ESP should connect to Blynk for the new configuration.

Maybe I can skip MQTT at all and use Node-Red to receive data from Blynk (rather then from ESP)


I’d forget any Blynk connection from your ESP device. Outgoing data is sent as you described.
Incoming data is always going to be a problem when the ESPis offline (sleeping). You can pick-up the values as MQTT messages when the ESP comes online if you set their retainer flag to True.

To be honest, it’s not difficult to use Node-Red to translate Blynk commands into into MQTT then have your ESP process them. You’ll have most of the code setup already, it’s just a case of reconfiguring the code a little.

There’s a bit more here…


Thanks a lot, Pete!