11 IoT Glossary: Terms From W Through Z

You’re designing an industrial monitoring system with 50 sensors transmitting via MQTT. The numbers below are worksheet assumptions for comparing choices; replace them with measured radio current, broker logs, and failure costs in a real design.

System Overview:

Begin with the traffic classes: 30 temperature sensors report at 1-minute intervals, 15 vibration sensors report equipment-health data every 10 seconds, and 5 emergency-stop buttons send immediate alerts. Their different consequences and repetition rates are why one QoS setting cannot be assumed for the whole system.

Step 1: Temperature Telemetry

Each temperature sensor produces 1,440 readings per day, or 43,200 readings across 30 sensors. QoS level 0 provides at-most-once, fire-and-forget delivery. Losing one isolated reading from this high-frequency trend may be acceptable only when aggregation, alerting, and data-quality rules tolerate gaps. On those worksheet assumptions, choose QoS 0: one MQTT transmission per reading and no acknowledgement exchange, which reduces radio airtime relative to QoS 1 or QoS 2.

Step 2: Vibration Monitoring

Vibration monitoring is predictive-maintenance evidence, so a missed high-vibration event could delay intervention; quantify that consequence from the asset and workflow. QoS level 1 provides acknowledged at-least-once delivery, but duplicates remain possible. Tag each reading with a timestamp and sequence number, then use idempotency checks at the backend. The resulting decision is QoS 1 with deduplication: roughly twice the MQTT message legs of QoS 0 in this simplified comparison, justified only by the measured maintenance risk.

Step 3: Emergency Stop Buttons

Life-safety commands need controlled execution, explicit acknowledgement, and a safe final state. QoS level 2 narrows duplicate delivery through the MQTT exactly-once exchange, but duplicate and missed-stop handling still belong in the application safety design. Follow the protocol in order: PUBLISH travels from client to broker; PUBREC confirms receipt; PUBREL releases the exchange; and PUBCOMP marks it complete. Choose QoS 2 plus command idempotency and safety interlocks only where this extra handshake is justified and the full end-to-end stop path still meets its timing requirement.

Step 4: Gateway Heartbeats

Gateway heartbeats are telemetry for online or offline health, sent every 60 seconds. If the stale-state policy accepts that detection interval, a lost heartbeat is replaced by the next scheduled observation. The bounded decision is therefore QoS 0 for redundant, fire-and-forget pings, with the 60-second delay made visible to operators.

Resulting MQTT Configuration Table

Relative Airtime Impact

If we incorrectly used QoS 2 for temperature telemetry:

At QoS 0, the worksheet’s 43,200 daily temperature messages require 43,200 MQTT transmission legs. Treating the four-step QoS 2 exchange as four legs would produce 172,800 legs, four times the simplified count. That does not by itself prove four times the battery use: it predicts more airtime, broker work, battery drain, and congestion exposure, which must be converted into battery-life and maintenance cost using measured device current.

Key Lesson: Match QoS level to message criticality. The glossary’s “Common confusions” section for QoS emphasizes: “Higher QoS means more overhead and latency” - reserve QoS 2 only for irreplaceable commands.