Devices are battery-powered with intermittent low-bandwidth connectivity. What protocol properties matter, and what is usually chosen wrongly?

The properties that matter

• Session persistence. Establishing a connection is expensive in both time and power, so a protocol maintaining a long-lived session outperforms one paying setup per message — this is usually the dominant factor.
• Small header overhead, since messages are tiny and per-message overhead can exceed the payload.
• Quality-of-service options, so the device can choose per message between fire-and-forget and acknowledged delivery rather than paying for guarantees uniformly.
• Broker-mediated delivery, so a device need not know or reach its consumers, and messages can be buffered while it sleeps.
• Graceful handling of intermittent connectivity, including session resumption without a full handshake.
• Last-will notification, so the platform learns of an ungraceful disconnect rather than inferring it from a timeout.

What is usually chosen wrongly

HTTP per reading. It is familiar, every library supports it, and it pays a connection setup and a large header for a payload of a few bytes, repeatedly, on battery. It is the default that gets chosen because the team's experience is with web services, and it shows up later as battery life far below specification.

The second common error is uniform maximum quality of service. Acknowledged delivery for every routine reading multiplies traffic and power for data whose loss is immaterial — telemetry is usually more valuable fresh than complete.

The decisions that go with the protocol

Batch on the device, since radio wake-ups dominate power cost far more than bytes transmitted. Compress, because bandwidth is scarce. And discard stale readings rather than uploading a backlog after an outage, since old telemetry usually has no value and the flush is an expensive burst.