It senses or acts on the physical world, it is connected so that data leaves it, and it is one of billions of small, cheap, low-power units rather than one of millions of managed general-purpose machines.

The phrase is easy to use and hard to pin down, so it helps to hold three properties together:

1. A foot in the physical world. An IoT endpoint has sensors (temperature, humidity, pressure, light, motion, acceleration), actuators, or both. Its purpose is to turn physical state into data, or data into physical change. A laptop is on the internet; a soil-moisture probe is of things.
2. Connectivity as the point, not a feature. The data is only valuable once it has left the device and been combined with other data — so the device exists inside a pipeline that runs to a gateway and on to a cloud backend.
3. Constrained, numerous, unattended. Small form factor, low cost, low power, often battery- or harvesting-powered, frequently with no screen and no keyboard, deployed in places nobody visits.

Across the classic application domains the same three properties recur with different payloads:

Cutting across all of them are four concerns that every IoT design has to answer: user experience, connectivity and manageability, data analytics, and security and trust.

Tip: if you can remove the physical sensing or the constrained hardware and the system still makes sense, you are probably looking at ordinary distributed computing wearing an IoT label.

Go deeper:

• Wikipedia — Internet of things — the definition in full, plus the application domains and the privacy and security debates that follow from them.

"Smart, always-on, always-sensing, connected, secure, low-power-capable, small-form-factor devices at the edge of the cloud" — a list in which almost every item fights the others.

The description is worth unpacking because it is really a list of conflicting requirements:

• Smart — it does local processing rather than shipping every raw reading, which costs compute and memory.
• Always-on / always-sensing — it never gets the luxury of being switched off, so its idle draw dominates its battery life.
• Connected — it holds a radio link, and radio is typically the single most expensive thing it does in energy terms.
• Secure — it must do cryptography, which costs cycles and energy on a processor that has few of either.
• Low-power-capable — the budget that all of the above must fit inside.
• Small form factor — which caps the battery size, and therefore the budget itself.
• At the edge of the cloud — it is the outermost tier of a larger system, not a standalone product.

That is why IoT engineering reads as a permanent negotiation rather than a set of best practices: every desirable property is drawn from the same energy account. The recurring design move is balancing computation against communication — process locally and send less, or send more and process centrally — and picking whichever side is cheaper for the workload at hand.

Tip: when a requirement seems impossible on an IoT device, ask which of these adjectives it is competing with. The answer is nearly always "low-power".

Go deeper:

• Wikipedia — Wireless sensor network — states the constraint bluntly: energy is the scarcest resource of a sensor node, and it is what decides the network's lifetime.