How the Internet of Things actually works
A plain-language walk through how an IoT system fits together, following one sensor reading from the device across the network to a decision and an action.
The phrase “Internet of Things” (IoT) stretches to cover a startling range of kit: a cheap smart plug, a soil probe buried in a paddock, a lift that files its own maintenance tickets, a car park that counts empty bays. Underneath the variety, most of these systems are assembled from the same small set of parts, wired together in roughly the same order. Learn that order once and almost any connected device stops looking like magic and starts looking like plumbing.
This guide follows a single reading — say, the temperature and movement in one room — from the moment a sensor measures it to the moment something acts on it. Along the way we meet the hardware on the device, the radios that carry the data, the gateways that marshal it, the messaging that shuttles it about, and the cloud and edge services that decide what to do. It sits alongside our broader Internet of Things topic, which maps how these same pieces turn up across homes, buildings and cities.
The anatomy of a “thing”
A single connected device is usually three things bolted together: something to sense, something to act, and a small computer to run the show.
Sensors: the physical world as numbers
Every IoT system begins with measurement. A sensor is a component that converts a physical quantity — temperature, light level, humidity, movement, pressure, sound, the concentration of a gas — into an electrical signal. A thermistor’s resistance changes as it warms; a passive infrared (PIR) sensor notices the moving heat of a body crossing its field of view; a photodiode responds to light. None of these produce a tidy number on their own. They produce a wobbling voltage, which an analogue-to-digital converter (ADC) samples and turns into the integers a computer can store and compare.
The quality of everything downstream is set here. A sensor that drifts, or that is polled once a minute when the thing it watches changes every second, hands bad data to every stage that follows. Choosing what to measure, and how often, is a real design decision, not a detail.
Actuators: numbers back into the world
If a sensor reads the world, an actuator writes to it. An actuator is any component that turns an electrical signal into a physical change: a relay that switches a heater, a motor that drives a blind, a solenoid valve that opens a water line, a dimmer that fades a light, an electronic lock that releases a door. Plenty of IoT devices are sensor-only — they just report — but the ones that close the loop and change something in the room depend on an actuator to do it.
The computer on the board
Between the sensing and the acting sits a microcontroller: a whole small computer — processor, memory and input/output — on a single chip. Classes such as the ARM Cortex-M family, or integrated wireless parts like the ESP32, are typical. Its job is modest but constant: wake up, read the sensors, apply any simple local logic, drive the actuators, and hand data to the radio. The software it runs is called firmware, and it is often written to spend most of its life asleep, waking only to take a reading or send a packet. On a battery device that discipline is the difference between a fortnight and a decade of life.
Getting the reading off the device
Once a device has a reading, it has to move it. This is where most of the meaningful engineering choices live, because no single radio is good at everything. Connectivity is a balance of four things pulling against each other: how far the signal must travel, how much power the device can spare, how much data it needs to push, and what it all costs. Stretch the range and you usually pay in power; cut the power and you usually pay in data rate.
The common options fall into a rough map:
| Technology | Typical range | Power draw | Data rate |
|---|---|---|---|
| Wi-Fi | Medium (a building) | High | High |
| Bluetooth / BLE | Short | Low | Low–medium |
| Zigbee | Short–medium (via mesh) | Low | Low |
| Thread | Short–medium (via mesh) | Low | Low–medium |
| LoRaWAN | Long (kilometres) | Very low | Very low |
| Cellular (4G/5G) | Wide area | High | High |
| NB-IoT / LTE-M | Wide area | Low | Low |
A few notes on that map. Wi-Fi is everywhere and moves data quickly, but it is power-hungry, which rules it out for anything meant to run for years on a coin cell. Bluetooth Low Energy (BLE) sips power and suits wearables and nearby devices. Zigbee and Thread both use the same low-power radio standard and both form a mesh, where mains-powered devices relay for their battery-powered neighbours, so coverage grows as you add nodes; Thread carries internet-style addressing and underpins the newer Matter standard. LoRaWAN, a long-range low-power network, trades almost all of its data rate away to send tiny messages across kilometres on very little power — ideal for that soil probe. Cellular reaches almost anywhere there is phone coverage; its low-power cousins, NB-IoT (Narrowband IoT) and LTE-M, are cut-down 4G variants built for small, infrequent messages from battery devices. For the home-network radios in particular, our guide to home-automation protocols compares them in more practical detail.
Gateways and hubs
Many of those radios do not speak the internet’s language directly. A Zigbee bulb or a BLE tag emits packets in its own dialect, over a network that never touches your router. Something has to sit in the middle, translate, and pass the traffic on. That something is a gateway, usually sold to consumers as a “hub”.
A gateway does more than translate. It often buffers readings when the upstream link drops, applies a first pass of filtering so the wider network is not flooded with near-identical values, and holds the credentials that keep the local devices secure. In a smart home it might be a small box plugged into the router; in a building or on a farm it can be an industrial unit aggregating hundreds of sensors before anything reaches the outside world.
How devices actually talk
Moving bytes is not the same as agreeing on what they mean. Devices need a shared messaging protocol — a convention for how a reading is packaged, addressed and acknowledged.
The most widely used in IoT is MQTT (Message Queuing Telemetry Transport). Rather than each device calling every other directly, they connect to a broker and use a publish-and-subscribe model: a sensor publishes to a named topic such as office/room3/temperature, and anything interested subscribes to that topic. The publisher and the subscriber never need to know about each other, which makes systems easy to extend. MQTT messages are small, which matters on a metered or battery-limited link. There is a fuller definition of MQTT in the glossary.
CoAP (Constrained Application Protocol) takes a different route: it looks deliberately like the web, with requests resembling those of a browser, but runs over the lighter UDP (User Datagram Protocol) transport so it fits on very constrained devices. Plain HTTP (HyperText Transfer Protocol), the web’s own protocol, is still common too, especially where a device talks straight to a cloud service — universally understood and easy to secure, but heavier than the alternatives. Which one a system uses is mostly a question of how small and how chatty its devices are.
The cloud: platforms and dashboards
Readings that survive all of that usually land in a cloud IoT platform. This is the part people see, but it rests on everything before it. A platform typically ingests millions of messages, stores the time-series data, and runs a rules engine — “if this room reports empty for twenty minutes, turn the heating down”. It manages devices too: tracking which are online, and pushing firmware updates over the air so a whole fleet can be patched without a site visit. On top sits the dashboard: the charts, maps and alerts that turn a torrent of numbers into something a person can read at a glance.
Where the edge fits
Sending every reading to a distant data centre is not always sensible. If a machine must stop within milliseconds of a fault, waiting for a round trip to the cloud is too slow. If a camera watches a doorway, streaming its footage offsite raises both bandwidth bills and privacy questions. If the internet link drops, a system that can only think in the cloud goes dumb.
Doing the processing near where the data is produced — on the device, on the gateway, or on a nearby server — is edge computing. The edge handles what needs speed, privacy or resilience; the cloud handles what needs scale, long history and heavy computation. Most real systems split the work, and deciding where to draw that line is a genuine trade-off rather than a fashion. Our edge vs cloud guide walks through how to weigh it.
In short: an IoT system is a relay race. A sensor turns something physical into a number, a microcontroller packages it, a radio and a gateway carry it, a messaging protocol like MQTT moves it, and a mix of edge and cloud decides what to do — often ending with an actuator changing something back in the physical world.
One reading, from sensor to action
Put the parts in a line and the journey is short. In our room, a PIR sensor detects no movement for twenty minutes and a thermistor reports 21°C. The microcontroller wakes, reads both, and publishes a small message over Zigbee. The gateway receives it, translates it to MQTT, and forwards it on. A rules engine — running at the edge for speed, or up in the cloud — sees “empty and warm” and decides to lower the target temperature. It publishes a command back down the same chain. The gateway relays it, the microcontroller receives it, and an actuator — a relay wired to the heating valve — clicks over. The room begins to cool. Every stage did one job and handed off to the next.
What this lets you see
The real payoff of knowing the chain is diagnostic. When a connected device misbehaves, the fault is almost always in one identifiable link: a sensor reading nonsense, a radio out of range, a gateway that has silently dropped offline, a broker not receiving messages, a rule written the wrong way round. Rather than treating the whole thing as an inscrutable black box, you can ask which stage failed and check it. The same map helps when choosing kit: a device’s radio tells you its likely range and battery life, its protocol tells you how easily it will fit with the rest, and where it does its thinking tells you how it will behave when the network does not. None of it is magic. It is a set of well-understood parts, and once you can name them, the whole field reads more plainly.