Blog · August 4, 2026
Why the protocol determines the battery life of your device
On a device with a power socket, choosing a protocol is an architecture question. On a battery device it is a lifetime question: the same measurements, sent over different protocols, can make the difference between months and years of runtime. We have taken a battery-powered cellular sensor device into series production — here is what mattered.
The basic rule: the radio is the consumer, not the processor
In a battery-powered wireless device, the largest share of the energy budget is not spent on computing but on the time the radio spends transmitting, receiving, or waiting for a response. Every byte that goes over the air and every second the connection stays open costs battery. A protocol is therefore better the fewer bytes it wraps around the payload and the sooner it lets the radio go back to sleep.
The three candidates
| Protocol | Character | For battery devices |
|---|---|---|
| HTTP | Request and response over TCP, text-based headers | The most expensive path: connection setup, TLS negotiation and verbose headers are paid on every single transfer. Acceptable when transfers are rare and large |
| MQTT | Lightweight message broker over TCP, connection stays up | Efficient when the connection can be kept alive — per-message headers are small. But keeping it alive has a price: keep-alive packets wake the radio. Strong when the device must also receive commands |
| CoAP | Designed for constrained devices, runs over UDP | The leanest path for short reports: no connection setup, binary headers of a few bytes, transmit and sleep. The price is your own diligence on delivery confirmation and security (DTLS) |
The honest answer to “which one is best” is: it depends on how your device communicates — how often it transmits, how much data per report, and whether it only reports or must also stay reachable. A device that reports three readings every twenty minutes and then sleeps does well with CoAP or a briefly established MQTT session. A device that must be reachable at all times needs the persistent connection — and pays for it.
The underrated lever: the payload itself
The protocol is only half of the equation. The other half is what you send. A measurement as JSON — with field names, quotation marks and brackets — is easily ten times the size of the same value encoded in binary. In series production we therefore used Protobuf: fields are binary and numbered instead of named, and a report of several hundred bytes of JSON shrinks to a few dozen bytes. Over tens of thousands of transfers in a device's life, that adds up to hours of saved radio time.
Then there is transport security: TLS or DTLS belongs in a battery device too — but the handshake is expensive, and whoever pays it on every transfer gives away runtime. Session resumption instead of a full handshake is the difference you can see in the current measurement.
What we took away from series production
- Settle the communication behaviour first, then choose the protocol. How often does the device transmit, how much per transfer, and does it also need to receive? The answer decides — not the popularity of the protocol.
- Keep the payload binary. The switch from text to Protobuf was the biggest single win, bigger than any protocol swap.
- Measure instead of estimating. The current draw per transfer belongs on the bench — with a battery simulator, not with a datasheet figure. The gap between calculation and measurement was instructive every single time.
What about you?
Which protocol does your battery device run — and do you know what a single transfer costs? Write to us — we are curious how often and how much your devices out there really transmit.
Transparency note: This article was written with the help of artificial intelligence and reviewed by the author before publication. The review applies to the German original; this English version is a translation.