It costs a couple of euros, the radio is on the die, the toolchain is free and there is example code for everything. Then somebody asks how long it runs on two AA cells, and the honest answer depends almost entirely on decisions nobody made deliberately.
A printed enclosure is the fastest way to get a prototype onto a real site, and the fastest way to discover that a part which was fine on a desk fails outdoors in three seasons. The material choice does most of the work, and it is not the one most people start with.
The part is accurate to a tenth of a degree and the device reads two degrees high. Nothing is broken. The sensor is faithfully reporting the temperature of a piece of copper that runs back to a regulator, and no calibration constant will fix that.
Mass was never measured. It was derived from flashes of scattered light by assuming things about density, shape and what the inlet captured. Knowing which of those assumptions your sensor makes for you, and which it leaves to you, is the whole of using the data honestly.
Two sensors, both reporting a number in parts per million, both labelled CO2 on the dashboard. One measured it. The other inferred it from unrelated chemistry and will report a crowded room the moment somebody opens a bottle of cleaning spray.
Two sensors, the same measurement, and completely different engineering. The bigger one is easier to trust and hard to run on a battery. The small one fits anywhere and will lie about the room temperature until you tell it how warm its own package is.
The datasheet promises humidity to within a couple of percent. Two years later the fleet reads consistently high, and the cause is almost never the sensor. It is an adhesive, a conformal coating or a filter cap that has been quietly poisoning it since the day it was assembled.
The sensor is the easy part. What decides whether a remote site reports for five years is the panel sized against December instead of the annual mean, a cell that holds capacity below freezing, and a gland that is still sealed after two winters.
Most buildings condition empty rooms on a timer set by somebody who left years ago. Occupancy data changes that, and the sensor that gives it to you reliably is not the motion detector everyone reaches for first.
A fifty litre an hour leak is invisible on a quarterly bill and obvious in an overnight baseline. The difference between finding it in two hours and finding it in ninety days is thirty-six thousand litres, and the meter that finds it does not need to be accurate.
One meter at the door tells you what the building used and nothing about who used it. Clamp-on sensors go around existing conductors in twenty minutes, and the load profile they produce usually changes a capacity decision before it changes a bill.
The data reaches your device platform in week three. Then somebody spends two quarters writing the glue that gets it into the cloud, and that glue becomes the thing every dashboard depends on. The native integrations remove the glue, and with it the service nobody wanted to maintain.
Fifty panels covering every available metric is not a dashboard, it is an inventory. The ones people open have six or eight panels and each answers a question somebody has at nine in the morning. The difference is editorial, not technical.
Somewhere in most IoT projects there is a small service nobody planned, joining readings from one database to device records in another. It exists because of a storage decision made in week two, it is where the bugs live, and it never gets deleted.
The meter installed in 1995 still measures accurately. The machine that cost six figures is not being replaced because somebody wants a dashboard. Almost all of this equipment already speaks: pulses, Modbus, a current loop, a relay contact. The work is listening without interfering.
The pilot is not a small production system. It is a demonstration built under conditions production will never have: one site, one enthusiast, no security review, and a spreadsheet doing the work of a data pipeline. Everything that made it succeed is what stops it scaling.
The hardware quote is the part everyone examines and the smallest number in the model. Installation labour usually exceeds it, and on a per-device subscription the connectivity line passes the whole hardware budget somewhere in year two and keeps going.
Nobody picks a radio because of its radio performance. They pick it because of the power budget, who owns the ground, and what the connectivity line costs in year five. Answer those three and the shortlist writes itself, usually down to one option.
A bad sensor choice is invisible with one unit on a desk and obvious with three hundred on a site. The failures are predictable and almost none of them are on the datasheet: cold-crushed batteries, firmware that never backs off, gaskets that fail their second winter. Here is what to test before the purchase order.
Almost everything is encrypted in transit now, which makes 'is it encrypted' the wrong question. The one that stops rollouts is who can decrypt the payload, and a deployment where the answer is a supplier is a deployment that has outsourced its security posture.