Devices

An IoT device is one of two things, and sometimes both:

• A sensor measures its surroundings, converts the measurement to data and sends it on.
• An actuator receives data and uses it to change something: a valve, a relay, a light, a setpoint.

Devices have become smaller, cheaper and more accurate every year, and that is quietly the most important thing happening in the industry. Measurements that were once too expensive to justify are now cheap enough to take everywhere, and questions that used to be answered by sending someone to look are answered continuously instead.

What the device actually does

More happens inside a battery-powered sensor than the word "sensor" suggests:

1. It wakes on a timer or on an event, such as a door opening.
2. It takes a measurement, often several, and may average them to reduce noise.
3. It encodes the result into as few bytes as possible, because transmission is what costs battery.
4. It transmits, and on most low-power technologies it then stops listening almost immediately.
5. It sleeps again, which is what it does more than 99 percent of the time.

Two consequences follow from that sequence, and they explain most surprises in the field.

The first is that reporting is not continuous. A device reporting every hour tells you nothing about the fifty-nine minutes in between, so an event shorter than the reporting interval can pass unseen. Sensors intended to catch events, such as door contacts or leak detectors, therefore report on the event as well as on the timer.

The second is that the device is asleep when you want to talk to it. Sending a command back, a downlink, means waiting for a window when the device is listening. On some technologies that window opens briefly after each uplink; on others the device can listen continuously, at a cost in battery. This is why configuring a device remotely can take until its next report, and why actuator devices are often mains-powered.

Choosing the right sensor

The measurement is the foundation of everything above it. If a sensor does not deliver correct data, or cannot get that data out, nothing higher in the stack can compensate. When selecting one, weigh:

• Accuracy, since the data drives the decisions. Check the specified tolerance across the range you actually care about, not the headline figure.
• Power consumption, which sets battery life together with the reporting interval. Reporting ten times more often does not cost ten times more battery, it usually costs more.
• Environment, meaning the heat, cold, damp and vibration where it will sit, plus the enclosure rating if it is outdoors or in a wet room.
• Lifetime, including whether the battery can be replaced at all, and how often the sensor needs recalibrating to stay within tolerance.
• Placement, which decides more than the datasheet does. A temperature sensor in direct sun or above a radiator reports the sun or the radiator.
• Compatibility with the network technology and the platform you have chosen.

Then confirm the whole chain works before ordering in volume: one device, installed where it will really live, reporting through the real network into the real platform.

Where the data goes next

Whatever the device measured leaves it as a compact, manufacturer-specific payload, often only a handful of bytes. Nothing downstream can read that without knowing the manufacturer's encoding, which is why the platform needs a decoder for each device model, and why a normalized data model matters so much. That story continues in Network technologies and is resolved in Data models.