An IoT device looks simple from the outside: something small, often battery-powered, that somehow sends information to an app. Inside, it is a tightly constrained computer doing a repeating cycle of five steps — sense, process, transmit, act, sleep — where every step is shaped by how much power it can afford to spend.
This guide follows a single reading through a real device, from the physical world to a phone screen, and explains what the hardware is actually doing at each stage. By the end the design trade-offs behind every connected product should be clear.
What an IoT Device Is Made Of
Almost every connected device, from a parking sensor to a smart thermostat, contains the same five building blocks.
| Part | Job | Typical example |
|---|---|---|
| Sensor | Turn a physical condition into an electrical signal | Temperature, motion, pressure, current, camera |
| Microcontroller (MCU) | Read the sensor, decide what matters, control everything | ESP32, nRF52, STM32 |
| Radio | Move data off the device | BLE, Wi-Fi, LoRaWAN, NB-IoT, cellular |
| Power source | Run all of the above, often for years | Coin cell, Li-ion, mains, energy harvesting |
| Firmware | The program that coordinates the cycle | Bare-metal loop or a small RTOS |
On many devices the MCU and radio are one chip — an ESP32 includes Wi-Fi and Bluetooth, an nRF52 includes BLE. That integration is a large part of why connected products became cheap enough to be everywhere.
How an IoT Device Actually Works, Step by Step
Sensing: the physical world becomes a number
A sensor converts something physical into an electrical signal. A thermistor changes resistance with temperature; an accelerometer produces a voltage proportional to movement.
That analogue signal is then digitised by an analogue-to-digital converter, usually built into the MCU. Resolution matters here: a 12-bit ADC divides its input range into 4,096 steps, which sets the smallest change the device can detect at all.
This is also where accuracy is won or lost. Sensor placement, calibration, and electrical noise decide whether the number means anything — and nothing later in the chain can repair a bad measurement.
Processing: deciding what is worth sending
The MCU now applies logic to the raw reading. Even on simple products this usually involves:
- Filtering out noise and obviously invalid values
- Averaging several samples into one reliable figure
- Comparing against a threshold to see if anything notable happened
- Storing the result until it is time to transmit
More capable devices run small machine-learning models here instead of fixed thresholds, classifying a vibration pattern or a sound. That is the idea behind TinyML, and it exists for a very practical reason explained in the next step.
Transmitting: the expensive part
The device wakes its radio and sends data to a gateway, a phone, or directly to the internet. This is where most of the energy goes — transmitting costs far more power than sensing or computing, which is why a well-designed device sends conclusions rather than raw streams.
- BLE — very low power, short range, needs a phone or gateway nearby
- Wi-Fi — high bandwidth, mains power or frequent charging
- LoRaWAN — kilometres of range, tiny messages, years on a battery
- NB-IoT / LTE-M — no gateway needed, but a subscription per device
Data usually travels using a lightweight protocol such as MQTT, which is designed for unreliable networks and small payloads rather than for web pages.
The platform: storing, interpreting, alerting
On the other side, a server authenticates the device, validates the message, stores it, and applies rules or analytics. This is where a reading becomes a chart, an alert, or a work order, and where data from many devices can be compared.
The app on your phone almost never talks to the device directly. It talks to this platform, which is why you can check a sensor from another country.
Acting and sleeping
Some devices also receive commands — unlock a door, change a setpoint, run a pump. Then the device does the most important thing in its cycle: it goes back to sleep.
A battery-powered sensor may be awake for a few milliseconds every few minutes and asleep the rest of the time, drawing microamps. That sleep ratio, far more than the battery size, is what makes multi-year battery life possible.
An IoT device is mostly asleep. The engineering is in deciding what is worth waking up for.
Following One Reading End to End
Take a soil moisture sensor in a field, reporting every 30 minutes on LoRaWAN.
- 00:00:00.000 — a timer wakes the MCU from deep sleep
- 00:00:00.010 — power is applied to the sensor, which needs a moment to stabilise
- 00:00:00.110 — the ADC takes several samples and averages them
- 00:00:00.120 — firmware checks the value is plausible and packs it into a few bytes with a device ID and timestamp
- 00:00:00.130 — the radio transmits for roughly 100 ms
- 00:00:00.250 — the device returns to deep sleep
- +1 second — a gateway forwards the message to a network server, then to the platform
- +2 seconds — the reading is stored, compared with the irrigation threshold, and appears on a dashboard
Awake for about a quarter of a second, asleep for 1,799.75 seconds. Repeat for three years on two AA cells. That ratio is the whole design.
What Makes Real Devices Harder Than the Diagram
Frequently Asked Questions
Conclusion
IoT devices work by repeating a disciplined cycle: measure something real, decide locally whether it matters, spend a little energy sending the conclusion, and sleep. The components are standard and inexpensive; the skill is in the trade-offs between accuracy, power, range, and cost.
Understanding that cycle explains almost everything about connected products — why they report every few minutes instead of continuously, why radio choice shapes the whole design, and why the best devices do as much thinking as possible before they transmit.
To see these principles applied, our list of 30 IoT examples covers devices in homes, hospitals, factories, farms and cities.