A small device for the checks that interrupt your day

You run a small fabrication workshop. You are halfway through a quote when someone mentions the air supply does not seem right. You leave the desk, cross the floor, look at the compressor. It seems fine. Later you try to remember when it was last serviced, and the answer is somewhere in a folder, or possibly in a message to the engineer from last spring.

None of this is a crisis. It is a steady drip of small interruptions that each cost five minutes and a train of thought, and it is a better starting point for an automation project than most of the ones we get asked about. Not a new compressor. Not a dashboard for every machine on the floor. One device, on one machine, that records what matters and turns it into the right next action.

What we would actually build

The hardware side is well understood. A retrofit monitor is sensors and a small industrial controller bolted onto equipment you already own. For a compressor that means a pressure transducer on the receiver, a temperature sensor on the motor, and a way to read the run signal. Arduino's application note (opens in a new tab) for exactly this use case shows how little exotic engineering is involved; the parts are off the shelf.

The value is in what happens after a reading exists. For this workshop we would do three things with the data:

1. Count operating hours from the run signal and raise a maintenance task in whatever system the workshop already uses when the agreed service interval is coming up. Not an email that gets lost. A task with an owner.
2. Keep a pressure history so that "it didn't seem right" can be checked against what the receiver was actually doing at 14:20 on Tuesday.
3. Notify the workshop lead when pressure stays outside the agreed range for longer than an agreed time. If nobody acknowledges it within, say, twenty minutes, it goes to a named backup. The owner is not the backup.

That is the whole product. The sensor is the least interesting part of it.

We would also draw a hard line in the first version: the device watches the compressor. It does not start it, stop it or override any existing control. Installation gets looked at by a qualified technician, and nothing about it replaces the safety systems, the statutory inspections or the manufacturer's maintenance schedule. Those are not caveats for the contract; they are what keeps the project small enough to finish.

Before anyone gets an alert

The person who works next to the machine knows things the data does not. There is a pressure dip every time the big saw starts. There is a blow-down routine at the end of the day that looks alarming on a chart and is completely normal. If those two facts are not in the design before the first notification goes out, the first week of alerts will be noise and the workshop lead will mute them by Wednesday.

So the pilot runs alongside the existing checks, not instead of them. For a few weeks the device records and nobody is notified. We sit down with the readings and the team's own observations and agree three lists: conditions that deserve attention, conditions that are normal, and conditions the available sensors cannot reliably tell apart.

That third list is the one that keeps the claims modest. A low-pressure reading tells you pressure is low. It does not tell you whether that is a leak, an unusually heavy shift, a failing sensor or a valve someone left open. The alert should report the observation and stop there:

Compressor receiver pressure has been below 6.5 bar for 12 minutes. Dan has been notified.

That gives someone a reason to go and look. It does not pretend the device has diagnosed a repair, and it does not invite the owner to call the engineer about a problem that turns out to be a hose.

Every alert needs an owner and a lifecycle. The lead acknowledges it, adds a line of notes, closes it once checked. A condition that persists stays as one open incident rather than a fresh notification every ten minutes. And the hours counter is for scheduling servicing, full stop. We would say that out loud in the kickoff, because a runtime figure sitting in a dashboard has a way of being read as productivity six months later, and a compressor idling while someone changes a setup is not evidence of anything about the person standing next to it.

It has to survive a normal week

The workshop's internet connection will go down, and when it does, it will not be the most important thing happening that day.

The device has to keep recording locally through an outage and upload the backlog when the connection returns. That sounds obvious and it is not free: it needs the device to stay powered, and it needs enough configured storage for however long you decide an outage might reasonably last. Microsoft's notes on offline operation for edge devices (opens in a new tab) are a good reference for what "designed and tested" means here, as opposed to "the product page said connected".

Remote alerts are a different matter. If there is no path out, they do not arrive, and the interface should not hide that. "Last reading received 10:14" is more useful than a green light that stays green after the device went silent. A dropped connection also has to look different from a machine fault, or the owner ends up calling the engineer about a router, or assuming the compressor is fine because the alerts stopped.

These are unglamorous requirements. They decide whether the device is still in use in a year.

Six months later

The first demo is not the finish line. Within six months the firmware will need an update, a sensor will drift and need checking, the person who was receiving the alerts will have left, and the workshop may be changing its maintenance software. The agreement signed at the start should already say who handles each of those.

Security belongs in the same agreement, and it is not an enterprise-only concern. The device should be individually identifiable, access should be restricted, data in transit and at rest should be protected, and there has to be a secure way to update the firmware. NIST's baseline recommendations for IoT devices (opens in a new tab) list exactly these, and they apply to one compressor in a shed as much as to a plant.

Price the whole installed system: hardware, fitting, connectivity, software, support and sensor upkeep. A cheap device that becomes someone's part-time job is not cheap. And separate custom engineering from custom manufacturing. This workshop almost certainly needs a tailored link into its maintenance process; it almost certainly does not need a circuit board designed from scratch. Buy the box, build the integration.

Whether the project earns its place is decided by the pilot, and the scorecard is short. Fewer manual logs. Maintenance tasks that were actually useful. Fewer interruptions. On the other side: time spent dismissing false alerts and rebooting the device. Breakdowns that did not happen during a six-week trial do not count as savings; nobody knows whether they would have happened.

There will still be reasons to walk over and look at the compressor. The point is to take the routine checking and remembering off the owner, so that the quote on the desk gets finished.