Posted on 17 Comments

ESP32 – Ultra-Long Battery Life With ESP-NOW

ePulse & ESPGateway with ESPNow

In an earlier blog post, we presented tricks to increase the battery life of your typical ESP8266 or ESP32 application. In this blog post, we show you how to prolong your device’s battery life from 7 months to 44(!) months.

We got to love the ESP32 because of its communication skills and also because it is easy to program. When you read the ESP32′ datasheet you can see that it supports not only WiFi but also Bluetooth Low Energy. But the ESP32 also supports a proprietary communication protocol by Espressif called ESP-NOW. This protocol also uses the 2.4GHz band but is optimized for sending short messages to other ESP-NOW nodes with as little overhead as possible.

And here you have two very important pre-conditions. The devices on both sides need to support the ESP-NOW protocol and it’s made for applications with short messages. You have to decide if these two pre-conditions are acceptable for your use case but if they are you can get a lot more runtime out of your batteries.

So why ESP-NOW is so much more battery-friendly? By avoiding the overhead of a WiFi, DHCP and HTTP handshake the ESP-NOW node can transmit the message much faster. And faster means a shorter duty cycle and more time to sleep. And since the ESP32 consumes far less energy when it is asleep our node can run much longer with one battery charge.

ESP-NOW Gateway

As mentioned earlier both sender and receiver of a ESP-NOW message need to speak the ESP-NOW protocol. And this means to forward the ESP-NOW message over regular WiFi channels you need some kind of a gateway for translating one protocol to the other.

This is one of the use cases we had in mind when we designed the ESPGateway. We put two ESP32-Wrover modules into the gateway. Then connected them with two GPIO pins so that the could communicate with each other. You could do a ESP-NOW-to-WiFi gateway also with just one ESP32. But WiFi and ESP-NOW cannot run at the same time in this setup. Because of this you’d have to listen with ESP-NOW for new messages. Once you receive a message switch over to WiFi and forward the message to the final destination. During this time, which can take several seconds you would miss incoming ESP-NOW messages. This might be unlikely if your system has just one node but with an increasing number of nodes you would miss more and more messages.

Our ESP-NOW Test Setup

In our experimental setup we have ESP32 nodes sending messages over ESP-NOW to one of the to ESP32-Wrovers in the ESPGateway. The first WRover then takes the ESP-NOW message and sends it over a serial line to the other one. This second ESP32 is constantly connected over WiFi and MQTT to a Raspberry Pi running an MQTT broker and Node-Red to log the messages.

Our experimental ESP-NOW setup: ePulse nodes send sensor data over ESP-NOW to the ESPGateway. Inside the gateway one ESP32 receives the message and forwards it over serial line to the other ESP32 from where it is sent over WiFi and MQTT to Node-Red

This design has clearly the advantage that one ESP32 can constantly listen on the ESP-NOW channel while the other one can forward messages with no delay to the upstream server. In addition, the ESPGateway comes with two external antennas which clearly should increase the range of both ESP-NOW communication as well as MQTT over WiFi.

We optimized the ePulse dev board for use cases where the micro-controller sleeps most of the time, wakes up, sends the message and goes back to sleep. With only 25uA power consumption in deep sleep, the ePulse is in the top league of development boards.

The node will wake up by a time trigger, send a message and go back to sleep for 15 minutes. We will compare the consumption of sending a message over WiFi with the consumption of using ESP-NOW.

We measure the power consumption with the fantastic Otii Arc from Qoitech. The Otii is a power supply and power analyzer. You can measure the power consumption over a given time

The Test Results

Let’s start with sending the message directly over WiFi and MQTT. As expected, it takes several seconds for the ESP32 to wake up, connect to WiFi, get an IP address from the DHCP server and to connect and send the message over MQTT. 3.877 seconds, to be precise. Assuming a 2500mAh battery and ignoring self discharge such a node could run for 6.9 months.

  • Battery Life Estimation with WiFi & MQTT
  • Duty Cycle with WiFi & MQTT

Now let’s use the setup described above where we send the message over ESP-NOW. Here the node is active 564ms! The total runtime increases from 6.9 months to 3.7 years!!! The node could send 6.4 times more messages over ESP-NOW than by using WiFi!

  • Battery Life Estimation with ESPNow
  • Duty Cycle with ESPNow

Summary

blank

We love the ESP32 because it is easy to program and because you can easily integrate it into your existing WiFi infrastructure. And you can build devices that run for a long time from batteries. But with a bit of additional hardware we can build sensor nodes which can run more than 6 times longer from the same battery! You don’t need to change your ESP32 based device, just adapt the code to use ESP-NOW.

If you plan to go that way the ThingPulse hardware can be your friend. The ESPGateway can collect data over ESP-NOW and forward it to your server. Our ePulse is great for prototyping such sensor nodes with its low deep sleep consumption.

17 thoughts on “ESP32 – Ultra-Long Battery Life With ESP-NOW

  1. You can further reduce the power consumption if you have some scope of improvement on the hardware, like:
    1. IQ/efficiency of your Buck/buck-boost converter used on board
    2. If the Battery charger is on board, what is battery leakage because of the battery charger circuit.

    I have spent the last 2 years building low-power embedded systems design and in the process learn a lot.

    I have shared my learnings in this detailed article (http://bit.ly/2RAafM1), hope you will enjoy it.

    1. Hi Mr.Aggarwal,

      İ just want to thank you for sharing your knowledge. İt will surely enlighten our ways.

      Best regards

    2. I’m working on a text msg project using two ESP32. No gate just using ESP-Now for RX/TX of small messages. Through my research for this project I was of the understanding that I could not deep sleep the ESP and still use WiFi ir ESP-Now. That incoming msgs would not be received because of no wifi to wake the ESP.
      So are you saying that incoming ESP-Now messages CAN be received and wake the ESP?

  2. Hi
    Just wanted to ask if you used a website to calculate and show the battery Lifetime or maybe a program from your Webpage?

    1. The screens where we calculate the battery runtime are part of the software we use to measure the consumption. Software and hardware are from Qoitech and the software is called Otii. The hardware is not that cheap but it is really worth the money if you are trying to optimize hardware for long battery runtime

    2. Hello!
      I’ve developed a tool that helps you to estimate the battery life.

      https://danilopinotti.com.br/tools/device-battery-life-estimator

      Hope it is useful for you

  3. I use esp-now in my house.
    I designed an esp8266 hat for a raspberry pi that acts as a gateway.

  4. It is possible to make an ESP Gateway with only one (1) esp8266 or esp32 and still have simultaneous communication.
    https://github.com/jonasbystrom/ESP-Now-Sensor-system-with-WiFi

    The only drawback is the WiFi channel must be fixed (to 1).

    1. Thank you!
      Wonderful work and structure
      I love it!

  5. Yes it is, WiFi channel does not need to be fixed to channel 1. It’s not a good idea to force your router to channel 1, let it choose the best channel on it’s own.

    What I did was when the esp32 was reset I would do a WiFi scan for my access point, I see what channel it was on and store that as a system variable. when the device comes out of sleep it knows what channel to use.

    I have had trouble with using a fixed channel and sending out the broadcast address, but it works if you send the packed directly to the receivers mac.

    Let me know if I can be of any more help.

    1. Hello,

      Can you, please, share details?
      Sensors should now upfront, which channel to use before sending a data to the gateway, so, if our router changes it’s channel, then gateway will use this channel, but our sensors won’t know it. Or do you scan for the router’s channel on the first sensor’s boot, then use this channel to send a data for the gateway? But in this case sensors can become out of sync with the gateway, when the router changes it’s channel – due reset/reboot/no power/or just a periodic freq scan for free channels.

  6. Where can I find the code for this device?

    1. The sample projects are linked on the product listing page.

  7. I purchased a gateway from you. Can I get a schematic, please?

    1. It is available as product images on the listing page at https://thingpulse.com/product/espgateway/.

      1. Thank you!

Leave a Reply

Your email address will not be published. Required fields are marked *