What Is IoT?

What the Internet of Things is

The Internet of Things (IoT) is the idea of connecting ordinary physical things — meters, thermostats, door locks, pumps, street lights, cattle collars — to a network, so that they can report what they measure and be controlled from a distance, and the services built on top of that data. There is no single official definition; the common core is a thing in the physical world, a small computer inside it, and a network connection.

An IoT device is the thing itself: a piece of hardware with one or more sensors or actuators, a small processor that runs its firmware, and a radio or wired network interface. A smart thermostat, a wireless door sensor and a dongle on an electricity meter are all IoT devices. A laptop or a phone is not usually called one, even though it is connected: it is a general-purpose computer that a person uses directly, while an IoT device does one job, mostly unattended.

The word "Internet" is a little misleading. Many IoT systems never touch the public internet: a smart home can run entirely on the home network, and a factory keeps its sensors on an isolated network. What matters is that the devices are networked and that software, somewhere, does something useful with what they report.

Cyber-physical systems

A cyber-physical system is a system in which software and the physical world are tightly coupled: computers measure a physical process, decide, and act on it again, in a loop. A thermostat that reads the room temperature and switches the heating is a small one; a power grid with its protection and control systems is a very large one. The term stresses what makes these systems different from ordinary IT: a bug or an attack does not just corrupt data, it can change something in the real world — open a valve, switch off a heater, drain a battery.

The building blocks

Almost every IoT system, from a single smart plug to a fleet of hundreds of thousands of meters, is built from the same five parts:

1. The device measures or acts. It contains a sensor or actuator, a microcontroller and a radio (see Microcontrollers and Single-Board Computers).
2. A gateway (optional) connects devices that cannot reach the network on their own — for example a Zigbee hub that turns radio messages from battery sensors into IP traffic (see Edge Computing and Gateways).
3. The network and a message broker carry the data. Many IoT systems use MQTT, a lightweight publish-subscribe protocol in which devices send messages to a broker that passes them on to whoever subscribed (see MQTT and IoT Messaging).
4. A platform stores the data, keeps a registry of devices, runs rules and pushes updates. It can be a cloud service or a server at home (see IoT Platforms and the Cloud).
5. Applications and people use the result: dashboards, alerts, apps, automations and invoices.

Machine-to-machine communication

Before "IoT" became the popular word, the industry spoke of machine-to-machine communication (M2M): devices exchanging data with other devices or servers automatically, without a person in between. Vending machines that report when they are empty, alarm panels that call a monitoring center and meters that are read over a mobile network are classic M2M. Mobile operators still sell "M2M" or "IoT" SIM cards and subscriptions for this traffic. The difference with IoT is mostly one of emphasis: M2M is about the link between two machines, IoT about the whole system of devices, platforms and services.

IoT, embedded systems and OT

Three terms overlap, and it helps to keep them apart:

• An embedded system is a computer built into a device to do one job: the controller in a washing machine, a car's engine management, a microwave's timer. Every IoT device is an embedded system, but most embedded systems are not connected to anything. IoT is what you get when you add a network and a service.
• Operational technology (OT) is the hardware and software that monitors and controls physical processes in industry and infrastructure: power grids, water treatment, factories. OT has existed for decades, mostly on closed networks with specialized protocols (see OT & Industrial Control Systems).
• The Industrial Internet of Things (IIoT) is where the two meet: cheap networked sensors in plants and on the grid that send their data to central platforms.

Consumer IoT (smart homes, wearables), commercial IoT (buildings, retail, logistics) and IIoT use the same building blocks. They differ in what is at stake when something fails, how long the devices must last, and who looks after them. A broken smart plug is an annoyance; a broken sensor in a substation can be a safety issue.

Constrained devices

Most IoT devices are a constrained device: a device with very little memory, processing power or energy compared with a PC or a phone, often combined with a slow or unreliable network link. The numbers are a different world from the laptops on the Hardware pages:

Constraints shape every design decision. A device with 2 kB of RAM cannot run a TLS library; a device on two AA batteries cannot keep its Wi-Fi radio on; a device behind a weak radio link must expect to lose messages. Much of this topic is about working within those limits: Power and Batteries, Wireless Basics and Firmware and Embedded Programming.

Typical uses

• Energy. Smart meters, home batteries, solar inverters, heat pumps and electric-vehicle chargers that react to energy prices. The Dutch smart meter is the worked example of this topic (see Smart Meters and the P1 Port).
• Homes and buildings. Thermostats, lighting, locks, occupancy sensors and building management systems (see Smart Home and Building Automation).
• Industry and utilities. Vibration sensors on pumps, level sensors in tanks, condition monitoring of transformers — the IIoT side covered in the OT topic.
• Logistics and cities. Trackers on containers and pallets, parking sensors, waste bins that report when they are full, street lights that dim when nobody is around.
• Agriculture and environment. Soil moisture, water levels, air quality, weather stations far from any power socket.
• Health and wearables. Fitness trackers, glucose monitors, alarm buttons for elderly people — where privacy rules are strictest.

Connected products

Many of these are sold as a connected product: a consumer or business product that collects data about its use or surroundings and exchanges it over a network, usually together with an app or online service from the manufacturer. A connected product is only as good as that service: when the manufacturer's cloud shuts down or support ends, the device can lose features or stop working altogether. The law now pays attention to this. In the EU, the Cyber Resilience Act (CRA) speaks of "products with digital elements" and requires a support period of at least five years, unless the product is expected to be used for a shorter time; UK law requires the update period to be published, without a minimum; US law sets no such duty (see IoT Security).

The running example: Lotte's home

This topic follows one household. Lotte Kortenhoeve (customer C-10003 of Kestrel Energy, the fictional energy supplier used across this site) lives in Utrecht. She has solar panels, and since 1 July 2026 a dynamic contract (CT-20004) whose price changes every hour. Her electricity meter is a Dutch smart meter with a P1 port: a connector for the customer that sends the meter's readings every second. Kestrel knows the meter as M-30004.

Lotte builds her own setup, step by step, on the pages that follow: an ESP32 development board on the P1 port, a Raspberry Pi 5 with Home Assistant and a Mosquitto MQTT broker, a dashboard, and a home battery that charges when the hourly price is low. All of it stays in her home; Kestrel receives nothing from it.

How Kestrel really gets readings

Elsewhere on this site Kestrel's smart meters "send a reading to meter-api every 15 minutes". That is a simplified teaching model. In the Netherlands a smart meter belongs to the grid operator and reports to it, at most once a day, over its own mobile connection; a supplier like Kestrel receives the readings from there, monthly by default and in quarter-hour detail only with the customer's consent. In the simplified model, meter-api stands for Kestrel's intake of those readings. The full path is on Smart Meters and the P1 Port.

The Kestrel Home pilot

Because the official path is slow, Kestrel started a small pilot in September 2026: about 250 households on a dynamic contract got a P1 dongle, an ESP32-C3-based device made by an outside manufacturer and sold under Kestrel's name. With the customer's explicit consent, the dongle sends live power use to Kestrel's MQTT broker over an encrypted connection, so the Kestrel app can show it and advise when to charge a battery. Lotte joined as home h0017, with an active P1 splitter (a powered P1 hub) on her meter so that her own reader keeps working. The pilot gives the topic its fleet questions: how to give each dongle an identity, how to update 250 devices safely, and what the law expects from a company that puts its own name on a connected device.

Why IoT is hard: fleets

Building one working device on a kitchen table takes an evening. Running a device fleet — all the devices of one type or one service that an organization deploys and must manage as a group — is a different job. A fleet is managed like servers are managed: inventory, monitoring, updates, certificates, incidents. But the "servers" are in other people's meter cupboards, run on a few hundred kilobytes, and cannot be reached when their Wi-Fi is down.

Even a small fleet produces a steady stream of messages. The calculation below is for the pilot's 250 dongles, each sending one small JSON message every 10 seconds:

# Kestrel Home pilot: how much does a small fleet send?
DONGLES = 250
INTERVAL_S = 10                      # one live-power message per dongle every 10 s
PAYLOAD = '{"time":"2026-10-07T19:30:15+02:00","watts":1234}'
SECONDS_PER_DAY = 24 * 60 * 60

per_second = DONGLES / INTERVAL_S
per_day = DONGLES * SECONDS_PER_DAY // INTERVAL_S
payload_mb = per_day * len(PAYLOAD) / 1_000_000

print(f"payload size:         {len(PAYLOAD)} bytes")
print(f"messages per second:  {per_second:g}")
print(f"messages per day:     {per_day:,}")
print(f"payload per day:      {payload_mb:.1f} MB")

# The same fleet if every dongle forwarded every telegram (one per second):
print(f"at one per second:    {DONGLES * SECONDS_PER_DAY:,} messages per day")

# For scale: about 400,000 meters with one reading per quarter hour.
print(f"400,000 meters x 96:  {400_000 * 96:,} readings per day")

payload size:         49 bytes
messages per second:  25
messages per day:     2,160,000
payload per day:      105.8 MB
at one per second:    21,600,000 messages per day
400,000 meters x 96:  38,400,000 readings per day

Two million messages a day from 250 small devices is easy for a broker, but it adds up: the real traffic is larger than the payload because every message carries protocol headers and encryption, and sending every one-second telegram instead of a 10-second average would multiply everything by ten. Choosing what to send, and how often, is one of the first design decisions (see Edge Computing and Gateways).

What else makes IoT hard

• Power. Battery devices must sleep almost all the time; a radio left on drains the battery in days instead of years.
• Radio. Walls, distance and interference make the network unreliable, so devices must buffer, retry and cope with gaps.
• Physical access. Devices sit in homes, fields and cupboards where anyone can open them, so secrets stored on the device must be protected.
• Long lifetimes. A meter or a thermostat stays on the wall for ten or fifteen years — longer than most software stacks, cloud services and mobile networks last (see Wireless Basics on 2G switch-offs).
• Updates. Firmware must be updated over the air, safely, on devices that may lose power halfway (see Provisioning and Over-the-Air Updates).
• Security and privacy. Cheap devices with default passwords were the raw material of the largest botnets, and a meter that reports every second reveals when people are home, asleep or cooking (see IoT Security and the Dutch rules for smart-meter data).