IoT Data Flow: Telemetry, Command, Alarm, Config

Every IoT deployment moves more than just "sensor readings to the cloud." A functioning system carries at least four distinct message categories, each with different direction, latency budget, reliability requirement, and payload shape. Conflating them — e.g., sending a firmware-config change over the same best-effort channel as routine telemetry — is a common design mistake that leads to missed commands, lost alarms, or configuration drift. Understanding the four flows and their QoS requirements is foundational to sizing a broker, choosing a protocol, and writing correct device firmware.

The Four Flow Types

These map cleanly onto MQTT topic conventions in most platforms:

devices/{id}/telemetry   (publish, QoS 0/1)
devices/{id}/cmd         (subscribe, QoS 1)
devices/{id}/alarm       (publish, QoS 1/2)
devices/{id}/config      (subscribe+publish, retained, QoS 1)

Telemetry: High Volume, Low Individual Value

Telemetry is the continuous stream of measured state — temperature, vibration, GPS position, battery voltage. Individually each sample is low-stakes; the value comes from aggregation and trend analysis over time.

Design implications:

• Sampling vs. reporting interval: a vibration sensor might sample at 1 kHz internally but report a computed RMS value once per minute — decoupling raw acquisition rate from network reporting rate is essential to fit LPWAN duty-cycle and airtime limits (e.g., LoRaWAN's 1% duty-cycle sub-band restrictions in EU868, or ~30 seconds/day of uplink airtime under some fair-use policies).
• QoS 0 (fire-and-forget) is often acceptable because losing one of thousands of periodic samples barely affects the trend line. This trades reliability for lower radio airtime and battery drain.
• Timestamping matters more than delivery guarantee. If the broker or gateway buffers and forwards in bursts, the device-side timestamp (not arrival time) must be preserved for correct time-series reconstruction.
• Delta/threshold reporting (report-by-exception) cuts payload volume 10–100× versus fixed-interval reporting in slowly-varying processes, at the cost of needing a periodic heartbeat to distinguish "no change" from "device offline."

Command: Low Volume, High Urgency

Commands flow the opposite direction — from application/operator down to the device — and must arrive and execute correctly, often exactly once (a duplicate "open valve" command is harmless; a duplicate "dispense 10 mg" command is not).

Design implications:

• Idempotency: design command handlers so that receiving the same command twice produces the same end state, not a repeated action. Include a monotonic command ID or sequence number so firmware can detect and drop duplicates.
• Acknowledgment loop: a command channel without an ack is just hope. Practical designs pair each command with a response message (cmd_ack with status: received / executing / done / failed) so the cloud side can retry or alert on timeout.
• QoS 1 minimum (MQTT "at least once") is standard; QoS 2 ("exactly once") is used where duplicate execution is unsafe and the broker/network overhead is acceptable.
• Timeout and fallback: for constrained devices sleeping most of the time on a duty cycle (independent of their RFC 7228 memory class — e.g., a Class 1 node with ~10 KiB RAM can still be duty-cycled or always-on), commands must queue at the broker/gateway until the device's next wake window — the application layer needs an expiry so a stale "unlock door" command issued 6 hours ago doesn't fire on wake-up.

Alarm: Low Volume, Critical Path

Alarms are exception events that must not be dropped, throttled, or delayed behind routine telemetry. An over-temperature alarm arriving 30 seconds late defeats its purpose.

Design implications:

• Separate channel/topic from telemetry so a busy telemetry queue never delays an alarm behind it — this is why alarms usually get their own MQTT topic and QoS 1/2, sometimes prioritized in the broker or even routed over a separate bearer (e.g., SMS fallback for a cellular gateway when the primary uplink is congested).
• Deduplication and hysteresis: a sensor oscillating around a threshold can flood the channel with repeated alarm/clear events. Firmware should apply hysteresis (e.g., alarm at 90 °C, clear at 85 °C) and rate-limit re-alerts.
• Latching vs. self-clearing: decide whether an alarm requires explicit operator acknowledgment (latching, for safety-critical faults) or clears automatically once the condition resolves (for transient conditions).
• End-to-end acknowledgment: the device (or gateway) should know the alarm was received by the application, not just handed to the broker — a broker crash between publish and subscriber delivery must not silently swallow a critical alarm.

Config: Rare, but Must Be Consistent

Configuration flow sets or reads operating parameters — report interval, threshold values, calibration offsets, firmware channel. It's infrequent but must never leave the device and cloud disagreeing about current state.

Design implications:

• Versioning: every config payload carries a version/sequence number. The device reports its current cfg_ver in telemetry or on connect; the cloud compares against the desired version and pushes an update only on mismatch — this is essentially the device shadow / digital twin pattern (desired state vs. reported state).
• Retained messages: MQTT's "retain" flag lets a newly-connecting device immediately receive the last-published config without the cloud needing to know it just came online — useful after a reboot or reconnect.
• Atomic apply: a config update should be validated and applied as a whole (or rolled back) rather than partially — a device that applies half a config set (new sample rate but old threshold) can behave unpredictably.
• Read-back confirmation: after applying, the device should publish its new effective config so the cloud-side shadow converges — closing the loop the same way commands do.

Worked Example: A Cold-Chain Temperature Tracker

A refrigerated shipping container node illustrates all four flows together:

1. Telemetry: publishes {temp, humidity, door_state} every 5 minutes over cellular IoT (QoS 0, unretained).
2. Alarm: if temp > -15°C for more than 2 consecutive readings, publishes an immediate alarm on a dedicated topic (QoS 1), independent of the 5-minute cycle — detected within one sample period, not delayed behind the telemetry schedule.
3. Command: a dispatcher sends {"cmd":"set_setpoint","val":-18} when rerouting to a different product; device acks with cmd_ack: done within its next connect window.
4. Config: fleet-wide update changes report_interval from 5 to 2 minutes ahead of a high-risk transit leg; device picks it up via retained config topic on next connection and echoes back cfg_ver to confirm.

Check: telemetry volume is 288 msgs/day at 5-minute intervals — fits easily within typical cellular data plans; alarms are rare (ideally zero) but reserved capacity guarantees they're never queued behind telemetry; commands and config are infrequent, human/system-triggered events needing acknowledgment, not periodic ones. Each flow's design (QoS, topic, payload size) matches its actual frequency and criticality — sizing a system as if all four had telemetry's volume-tolerant, best-effort profile would under-provision reliability for the two flows that need it most.

Key Takeaways

• Telemetry is high-volume, best-effort, device-to-cloud — optimize for airtime/battery, not per-message guarantees.
• Command is low-volume, cloud-to-device, and must be idempotent with an acknowledgment loop to handle retries and duplicates safely.
• Alarm is low-volume but latency- and loss-critical — give it its own channel/QoS so it never queues behind routine telemetry.
• Config is infrequent but must be versioned and convergent (device-shadow pattern) so cloud and device never silently disagree on current state.
• Matching each flow's protocol QoS, topic structure, and payload design to its actual criticality — not treating all IoT traffic the same — is the core architectural decision behind reliable device-to-cloud communication.