Sensor readings flowing from equipment into a system that triggers a decision

Industrial IoT articles tend to stop at the interesting bit: sensors on machines, temperature in transit, RFID at the door, real-time visibility of everything.

All of that works and most of it is cheap. Hardware and connectivity stopped being the hard part some years ago.

What decides whether the project pays for itself is everything downstream — where readings land, what they connect to, and who is expected to do something when one of them changes. That part is a systems problem, and it is where these projects tend to quietly fail.

The sensor is the cheapest thing you will buy

A vibration sensor costs less than an hour of engineering. Put a hundred of them on a production line and the hardware bill is still smaller than the integration.

Because now you have a stream of readings, and every one of the following needs answering.

Where do they go, and how long do you keep them? Full-resolution vibration data from a hundred machines is a storage decision within weeks.

What is normal? A threshold is easy. Knowing that this bearing runs warmer than that one and always has takes a baseline, which takes months of data before it means anything.

Who gets told? An alert with no owner is a dashboard nobody opens. This is an organisational question wearing a technical costume.

What happens then? If the answer is "someone raises a ticket manually", the sensor saved nothing. The value shows up when the reading reaches the system where work is already scheduled.

Where it genuinely pays in a warehouse

Predictive maintenance on things that stop the line. Conveyors, sorters, compressors. The value is not the sensor, it is knowing three days early so the part is ordered and the fix goes into planned downtime rather than a Tuesday morning. Which means the reading has to reach the maintenance schedule, not a screen.

Condition monitoring where a breach costs the goods. Cold chain is the clean case: temperature is objective, the consequence of a breach is expensive and specific, and the intervention is obvious. Any case with those three properties works.

Location and dwell time. Where is the pallet, how long has it been there, which zone is congested at 3pm on Thursdays. Straightforward data that changes how the floor is laid out, provided somebody looks at it periodically and has the authority to move things.

Automatic stock signals. A weight sensor on a bin, feeding the reorder point. This one is worth more than it looks, because it removes a manual count that everyone knows is slightly wrong.

Where it usually disappoints

Anything justified as "visibility". Visibility is not a benefit. The benefit is the decision the visibility enables, and if nobody has agreed which decision that is, you have bought a dashboard.

Anything that ends in an email. Alerts arriving somewhere without a workflow attached get filtered within a month.

Anything requiring a new screen. If people have to open a second system to see the data, they will not, and the project becomes a slide about lessons learned.

The integration is the project

The pattern in every IoT project that worked is the same: the readings ended up inside the system where the work already happens.

For a warehouse that is the WMS. Sensor says the bin is low, the WMS raises the replenishment task, the picker sees it in the same queue as everything else. Nobody learned a new tool and nobody had to remember to check anything.

That means the real questions at the start are integration questions.

Which existing system needs to receive this, and what does its API accept?

What happens to a reading that arrives while that system is down — queued, or lost?

Who owns the threshold, and how do they change it without a developer?

How do you tell a broken sensor from a genuine anomaly, given both look like an outlier?

Answer those and the hardware choice becomes almost incidental. Skip them and you get a pilot that works beautifully and never reaches the second building.

Edge, 5G, and the rest

Two trends are worth knowing about, mostly because they change where you put the logic.

Processing at the edge, near the device, cuts latency and the volume you ship to the cloud. For anything needing a fast local reaction, that is where the decision belongs.

Better connectivity makes denser deployments practical. It does not change the integration question at all — it just means more readings arriving at a system that still needs to know what to do with them.

We build warehouse management systems and the integration layer that connects them to everything else. If you have sensors producing data nobody acts on, that is the conversation to have.