I keep coming back to the same basic idea: get a useful signal before designing the perfect system. A lot of machine monitoring conversations start too high up. Dashboards, analytics, AI, reports, alerts. But on the floor the first question is usually more boring. Can I tell when the machine is running? Can I count a part? Can I tell when it stopped? Can I do that without touching the PLC program or creating a maintenance problem?
That is where cheap sensors are interesting. A photo eye, prox, current switch, or simple hardwired input can be enough to create visibility. Not complete truth. Just enough truth to start learning. This matters especially on older machines where the controls are limited, undocumented, locked down, or just not worth disturbing yet.
The constraint is that cheap sensors are not magic. Mounting matters. Cable routing matters. False counts matter. Operators bump things. Oil, dust, vibration, heat, and bad lighting all show up eventually. The sensor might be cheap, but the signal is only useful if the install survives the environment.
What I would want to capture first is simple: machine running, cycle complete, blocked, starved, faulted if I can get it, and maybe manual override or changeover state. I do not need a full semantic model on day one. I need a signal that lets me compare what the machine did against what people think it did.
The surprise is usually how much value comes from one boring input. A single part count tied to time can show cycle drift. A run signal with gaps can show downtime patterns. A simple stopped state can start better conversations than a beautiful dashboard built on guesses.
The note for next time is to treat the first sensor like a test instrument, not a permanent architecture decision. Mount it. Log it. Watch it lie. Fix the mount. Adjust the debounce. Compare it to reality. Then decide if the signal deserves to become part of the system. Small tests before big rollouts.