IoT devices range from a sensor the size of a coin that runs for a decade on one battery to a rack-mounted gateway with the same processor as a laptop. They share the definition of an IoT device, a physical object with sensing or actuation and a network connection, but almost nothing else. The differences come from constraints: how much energy is available, how much the unit can cost, how far it has to communicate, and how exposed it is to attackers and weather.
Understanding those constraints explains why devices are built the way they are, and why choices that look odd from a software perspective (no operating system, firmware that cannot be updated) are often deliberate. It also helps you pick the right class of device for a problem.
This guide walks through the main device classes, then the constraints that separate them.
A spectrum of devices
Constrained sensor nodes
At the small end sit battery-powered sensors: temperature and humidity probes, door contacts, soil moisture stakes, parking space detectors, asset tags. They are built around a microcontroller with a few hundred kilobytes of flash memory and tens of kilobytes of RAM, a single radio, and a coin cell or a pair of AA batteries. They spend almost all their time in deep sleep and wake briefly to measure and transmit.
The firmware is a single program, sometimes built on a small RTOS to schedule tasks. Everything is measured in microamps and bytes.
Mains-powered smart devices
Smart plugs, light bulbs, thermostats, doorbells and appliances have a power source and so can afford a Wi-Fi radio, a more capable chip such as an ESP32, and always-on connectivity. They can be reached at any time, which simplifies commands and OTA updates. Their constraint is cost: in a consumer product every cent of the bill of materials matters, which pushes designers toward the cheapest chip that meets the spec and leaves little margin for security hardware.
Wearables and portable devices
A wearable combines the battery constraint of a sensor node with the richer sensing (an IMU, optical heart rate, GPS) and user interface of a consumer product. It relies on a phone as its gateway over Bluetooth Low Energy, which keeps the device itself simple.
Gateways and edge devices
A gateway collects data from many local devices and forwards it over IP. An edge device goes further and runs application logic locally: protocol conversion, filtering, local rules, sometimes machine learning inference. These are built around a microprocessor running Linux, often packaged as a system on module or a board like the Raspberry Pi in prototypes. They have mains or Power over Ethernet supply, storage, and the ability to run containers.
Industrial and rugged equipment
Industrial sensors, controllers and trackers face vibration, dust, moisture and temperature extremes. A rugged device is sealed, certified for its environment, and designed for a service life measured in many years. In factories, PLCs and drives are increasingly fitted with IoT connectivity so that their data reaches analytics systems. Here the constraint is not cost per unit but reliability and certification.
Vehicles and mobile assets
Telematics units in trucks, agricultural machinery and shared scooters have abundant power while the engine runs but must survive on a small backup battery when parked. They use cellular IoT because they move, and often add satellite for remote areas.
The constraints that drive design
Energy
Energy is the first question for any device without a mains connection. The budget determines which radio is viable, how often the device can report, and whether it can afford to run cryptography. A device on a coin cell cannot keep a Wi-Fi connection alive; it has to use a low-power radio such as BLE, Zigbee, Thread or LoRaWAN, and a tiny duty cycle.
Energy harvesting from light or vibration can extend life indefinitely for very low-consumption nodes, where the source is reliable.
Cost and volume
A sensor deployed in the thousands must be cheap, which rules out large memories, secure elements, and expensive radios. This is the main reason constrained devices lack features that security engineers consider basic. When cost allows, a secure element provides hardware key storage and a root of trust for secure boot.
A cheaper radio may require more gateways and a cheaper chip more engineering time, so total cost of ownership over the deployment’s life is the right measure.
Memory and compute
A microcontroller with tens of kilobytes of RAM cannot hold a full TCP/IP stack with TLS plus application logic without careful engineering. This is why protocols like CoAP and MQTT-SN exist, why payloads use CBOR rather than JSON, and why 6LoWPAN compresses IPv6 headers for small radios. On the other end, edge devices with gigabytes of RAM run the same software as servers.
Connectivity and reach
The physical environment dictates the radio. Indoors, Wi-Fi or a mesh works. Across a campus or farm, LPWAN technologies cover kilometers on milliwatts. On the move, cellular (NB-IoT, LTE-M) is the practical choice. Each radio imposes limits on message size and frequency, which feed back into the firmware design.
Physical environment
Temperature range, ingress protection, vibration and chemical exposure all shape the enclosure and components. An outdoor device needs an antenna that works inside a sealed case and a battery chemistry that tolerates cold.
Longevity and maintainability
Consumer electronics are replaced in a few years; a smart meter or a structural sensor in a bridge may need to work for fifteen. Long life raises the stakes on firmware update mechanisms, cryptographic agility, and spare parts. A device that cannot be updated remotely is a liability for its entire life, which is why the device lifecycle deserves as much design attention as the hardware.
Security exposure
A device in a public place can be opened, probed and reprogrammed. A device in a locked cabinet cannot. The expected threat decides whether debug ports must be disabled, whether keys must live in tamper-resistant hardware, and how much the firmware must defend against physical attack. The security fundamentals guide covers these defenses.
Matching the class to the job
A quick heuristic: start from power. If mains is available, the design space is wide and the main questions are cost and connectivity. If the device runs on a battery, decide how long it must last and how much data it must send, and let those two numbers eliminate radio options until one remains. If local decisions are needed when the network is down, or if raw data volume is too large to ship, add an edge device.
Mixing classes is normal: coin-cell soil probes on LoRaWAN, a cellular tracker on each tractor, and a Linux gateway in the barn tying them together.
Where to go next
- IoT connectivity overview compares the radios each device class relies on.
- How IoT works: from sensor to cloud and back shows how these devices fit into a full system.
- Device management and OTA updates covers keeping devices maintainable after deployment.
- TinyML explained looks at running machine learning on the smallest class of device.
Topics: devices, hardware, microcontrollers, fundamentals