Getting a Web Interface to Talk to Industrial Hardware

A working note from one of the projects I’ve been spending time on. The goal: control real industrial equipment — in this case, a multi-zone lighting system — from a normal web browser, with no operator software to install.

The starting point

The hardware already exists. The PLC already runs. The lights already work. The problem is the human side: the existing control surface is locked to a specific panel, on a specific network, with a specific piece of software.

I wanted to know: can a browser do the same job, from anywhere, with the same latency and reliability?

What worked

• Treating the browser as a first-class operator surface. Once you stop apologising for the web and start designing for it (latency, state sync, error recovery), the same UI patterns that work in any modern app work just as well for “press this button to turn on the boom lights”.
• Messaging as the seam. A thin messaging layer between the browser and the controller keeps both sides independent. The browser doesn’t know it’s talking to a PLC. The PLC doesn’t know it’s being driven by a browser. That separation made it possible to add a second front-end (a different control surface) without touching the controller.
• Status streams over the same channel. Pushing live state from hardware back to the browser, in addition to commands going the other way, makes the UI feel alive and trustworthy.

What didn’t

• Underestimating the variety of failure modes. WebSockets drop, brokers restart, networks partition. The first version was optimistic; the second version treats every state transition as a thing that can fail and needs a recovery path.
• Trying to do too much in the browser. Some logic belongs on the controller, not the UI. The rule I now follow: if a decision affects the physical world, it lives as close to the physical world as practical.

What I’d do differently

Start with the failure path. Build the recovery flow first, then build the happy path on top of it. The happy path is easy and tempting to design first; the failure path is what makes the system usable in production.