Every way to send less data
Fewer messages, smaller messages, or a smaller question: batching, reporting by exception, compact formats, summaries, edge filters and on-device models, and what each one costs.
Ask first which number you're trying to cut, because the levers are different.
- The message count (it sets most per-message bills and much of the radio's energy) → send several readings per message, or report only when a value changes enough, with a heartbeat so silence still means something.
- The bytes per message (they matter on LoRaWAN, NB-IoT and metered links) → CBOR or Protobuf instead of JSON, shorter topics.
- What gets stored → a retention policy with downsampled summaries.
- What leaves the device at all → filter, summarise or classify at the edge, and send the result instead of the raw stream. Reach for rules and features before a model.
Every lever has a cost: latency for batching, a breaking change for a new message shape, lost detail for summaries. Write down which one you paid.
Fewer messages
Section
Cost and scale
Halving the reporting interval costs as much as doubling the fleet.
Term
batching
Section
Time-series data
Reporting by exception, and why it needs a heartbeat.
Term
heartbeat
Smaller messages
Section
Payload formats and contracts
66 bytes of JSON, 55 of CBOR, 21 of Protobuf, for the same reading.
Term
CBOR
Example
Less stored
Section
Retention and downsampling
Less leaving the device
Section
Local processing vs raw data
Section
Features from sensor windows
A window of samples becomes a few numbers.
Section
When not to use AI
A threshold or a rule first; a model only when they fail.
Section
What TinyML is
Send the class, not the waveform.