The clearest way to understand an IoT system is to follow a single measurement from the moment a physical quantity changes to the moment someone acts on it. Every deployment, from a smart plug to a refinery, repeats the same journey.
Take a concrete example: a temperature sensor in a refrigerated storage room. The owner wants a text message if the room gets too warm, and wants to be able to switch a backup compressor on remotely. This guide traces that reading through each stage, names the components involved, and explains the decisions that are made at each hop.
The stages are: sense, process locally, transmit, aggregate at a gateway, deliver over a protocol, ingest into a platform, store and analyze, and act. The return path, from a command in the cloud to a relay on the device, runs the same stages in reverse.
Sensing: turning physics into numbers
A sensor is a transducer. A thermistor changes its electrical resistance with temperature; a digital temperature chip measures that internally and exposes a number on a serial bus. Either way the microcontroller on the device has to read it, through an analog-to-digital converter for an analog part or through a bus such as I2C or SPI for a digital one.
Two decisions are made here. The first is the sampling rate: how often to read. A fridge changes temperature slowly, so once a minute is plenty, and reading less often saves energy. The second is calibration and filtering: raw readings are noisy, so firmware typically averages several samples or discards outliers before reporting.
Local processing: deciding what to send
The device’s firmware now has a number. It can send every reading, or it can be selective. Sending only when the value changes by more than a threshold, or only when it crosses an alarm limit, cuts radio traffic dramatically. On a battery-powered device the radio is the largest consumer of energy, so this step is where battery life is won or lost.
Between readings, a well-designed device goes into deep sleep, waking on a timer. The ratio of awake time to sleep time is the duty cycle, and a small duty cycle is what lets a sensor run for years on a coin cell.
The reading is packaged into a payload. For a constrained link that might be a few bytes in a compact binary format; for a Wi-Fi device it is often a small JSON object:
{"t": 4.8, "ts": 1760690400, "bat": 92}Transmission: the first hop
The device radio now sends the payload. Which radio depends on range, power and bandwidth needs, a trade-off covered in the connectivity overview. For a cold room inside a building, options include Wi-Fi directly to the site router, Zigbee or Thread to a nearby hub, or LoRaWAN to a gateway that may be on the roof of a different building.
Wi-Fi is power hungry but needs no extra hardware. Zigbee and Thread sip power but require a hub. LoRaWAN reaches far on tiny energy but moves only a few bytes at a time.
The gateway: bridging networks
Unless the device speaks IP natively over Wi-Fi, Ethernet or cellular, something has to translate between the local radio network and the internet. That something is the gateway. A smart home hub, a LoRaWAN gateway and an industrial edge gateway all play the same role: receive frames from many devices on one side, forward them as IP packets on the other.
Gateways often do more than forward: they buffer data when the uplink is down, convert protocols such as Modbus into MQTT, and run local rules so that an alarm still fires if the internet fails. This is where edge computing begins.
Protocols: talking to the platform
Once there is an IP path, the device or gateway needs an application protocol to deliver the payload. The common choice for telemetry is MQTT. The device publishes its payload to a topic such as site/coldroom-1/temperature on a broker; anything interested subscribes to that topic. The publish-subscribe pattern means the device does not need to know who consumes its data, and the broker handles delivery guarantees through QoS levels.
For very constrained devices CoAP over UDP is lighter. Devices with plenty of resources sometimes just use HTTP. In every case the connection should be encrypted with TLS or DTLS, and the device should prove its identity with a certificate or token issued during provisioning.
Ingestion, storage and analysis
The IoT platform receives the message. Its first job is data ingestion: authenticate the sender, validate the payload, attach metadata such as which customer and location the device belongs to, and hand the record to the next stage.
Readings go into a time-series database, which is optimized for append-only data indexed by time. The platform may also keep a device shadow, a small document that records the last known state of each device so that applications can query it without waiting for the next report.
A rule engine or stream processing job evaluates each reading as it arrives. In our example the rule is simple: if temperature exceeds a limit for more than a few minutes, raise an alert. More complex rules combine several sensors, compare against historical baselines, or run a machine learning model for anomaly detection. The data pipeline guide covers these stages in depth.
Acting: closing the loop
The alert rule fires. The platform sends a notification through a webhook to an SMS service, and the owner receives a text. A dashboard shows the trend so they can judge whether the problem is a door left open or a failing compressor.
The owner taps “start backup compressor” in an app. The command travels in reverse: the app calls the platform API, the platform publishes a message to the device’s command topic, the broker delivers it, and the device firmware drives a relay through a GPIO pin. The device publishes an acknowledgment so the shadow and the app reflect the new state.
A device that sleeps most of the time cannot receive a command until it next wakes, so the command waits in the shadow until the device fetches it.
What this journey tells you about design
Each stage has a failure mode. Sensors drift. Radios lose packets and devices must retry without flooding the network. Gateways go offline and need buffering. Brokers need to scale. Rules need thresholds that avoid both missed alarms and alert fatigue.
Good IoT engineering is mostly about anticipating these failures. The questions worth asking for any new deployment are: what happens when this link is down for an hour, how does the device know its data was received, and how will the firmware be fixed once a thousand units are in the field. The last one is the subject of device management and OTA updates.
Where to go next
- IoT architecture: the layers formalizes the stages above into the standard layered model.
- MQTT explained covers the protocol most of this traffic runs on.
- The IoT data pipeline goes deeper into what happens after ingestion.
- Types of IoT devices and their constraints explains the hardware side of these trade-offs.
Topics: IoT basics, architecture, telemetry, fundamentals