I'm somewhat skeptical about your conclusion that the TCP handshake and other possible overheads are the problem.

1) In the worst case you're transmitting one packet for each connection, this requires you to send two handshake packets. The TX time alone cannot be more than a few milliseconds per packet. Once every 5-15 minutes is negligible

2) MQTT uses TCP by default, unless you use one of its variants

3) Leaving RX on is inevitable if you want real time connection, this is likely a far larger draw than the handshake

4) You could also configure the keep alive tcp connection value on the server and reuse the same connection

Well.. why is he using the ESP32? That thing is everything but not a low power microcontroller. The use of BLE/Wifi increases the power consumption like crazy.

I've build a solar station with an ESP32 using LoRa module. Even that wasn't much fun as I was forced to keep in light or even deep sleep as often as possible.

An option would be to use a Nordic NRF or STM32WB and use the BLE long range mode.

ESP32 is generally not a good choice for infrequently-charged battery powered devices IMO, unless they have massive batteries. Power consumption always goes up with the sophistication of the communication stack, both hardware and software, and the ESP is toward the upper end of that spectrum (unlike, say, something based on 802.15.4).

That said, were you using TLS? I'd be curious to know how that impacts power consumption during HTTP calls.

It takes notional 3 seconds to boot and get an IP address alone.

If you use ESP-NOW then you can wake up send msg and sleep again in 35ms.

It's a layer 2 protocol.

This reads as if you did multiple API calls per "ping", and opened a new http connection for each API call?

Did you try reusing the http connection (one per ping)? How about putting all data in a single API call and let the server handle that?

Did you try compression? Not sure if compression makes sense, but a simple+fast compression like gzip could also be worth a try to reduce the actual bytes to put on the air; especially if your data is very verbose or repetitive. (Do that before connecting to wifi, even if that means not using http's compression).

I suppose you're talking http, not https. The latter will of course use much more energy.

Using UDP and the ensuring TCP-like qualities seems like a last resort solution.

Sorry if I misread your article and the suggestion were tried or are not feasible for you.

I feel like this is a finding/experience worth sharing. We ran into battery problem when developing our MVP using esp32 c3 MCU. ESP32 have high current consumption during network calls and we resolved this problem by avoiding TCP protocol in our network calls (Moving away from REST API calls).For Details, I am linking full article here: https://khalsalabs.com/iot-101-minimizing-esp32-wifi-battery...

Hope you all enjoy!

This is blatant blogspam to promote a product from a company that seems to be a self-declared social media expert and a wannabe life coach whose youtube video content includes 'how to make money using AI to produce videos.' The social media guy appears to be using ChatGPT to spam links to his blog about dogs.

The whole thing smells like a scam.

I just made sewer temperature guard, which reports via Wifi when something undesirable happens. It lasts SIX MONTHS on AA-batteries. Attiny checks the temp every 10 minutes using micro amperes and only starts ESP-01 Wifi when needed.

Undesirable thing is that I have left faucet running and the sewer stays too hot/cold for half an hour.

Sounds like TCP is in dire need of an upgrade that makes the protocol more power-friendly.

Everybody implementing their own protocol over UDP seems highly undesirable.

Has anyone used the Nordic power kit? Or any other recommendations for measuring power consumption?

Thank you for the article, very interesting. In my low power project I also switched away from my usually preferred esp32 in favor of a more battery efficient MCU. I also am not using wifi nor ble but lora instead.