Your Equipment Already Talks. Your Software Just Can't Understand It

I got a message a while back from someone who runs a small manufacturing site. Their machines already logged temperature, cycle counts and fault codes. The data existed. It had existed for years. But it lived on a small screen bolted to the machine, and nobody outside the factory floor ever saw it. Getting it into a spreadsheet meant someone walking round with a clipboard once a shift.

That's not a rare situation. A huge amount of business equipment, from HVAC controllers to weighing scales to card payment terminals to building sensors, already produces data that would be genuinely useful in an office, a dashboard, or an alert to someone's phone. The equipment isn't silent. It's just speaking a language your other software doesn't understand.

What "speaking a protocol" actually means

Most modern web apps talk to each other over HTTP, using something like JSON. It's a common language. Industrial and building equipment usually doesn't use that at all. It uses older, purpose-built protocols designed for reliability on a factory floor or in a plant room, not for talking to a browser.

• Modbus is one of the oldest and most common. It's simple, it's been around since the 1970s, and it's still on huge amounts of industrial kit today. It reads and writes numbered "registers" rather than named fields, so register 40012 might mean "boiler temperature" on one machine and something completely different on the next.
• BACnet turns up a lot in building management, heating, ventilation, access control.
• OPC-UA is a newer, more structured protocol that's slowly replacing older industrial standards on newer equipment.
• MQTT is common on IoT sensors, designed for lots of small, frequent messages over unreliable connections.

None of these are wrong or outdated as far as the equipment is concerned. They do their job well. The problem is only that nothing has ever translated what they say into something your website, your dashboard, or your existing software can use.

Why it gets left alone until it's a real bottleneck

This kind of gap tends to survive for years because nobody ever has to fix it in one go. Someone reads a meter by hand. Someone checks a screen once a day. Someone exports a CSV manually from a device that was installed a decade before the current staff joined. Each of these is a small, tolerable bit of admin on its own.

It becomes a problem when the business grows, when a site adds more equipment than one person can walk round and check, or when someone finally asks "why can't we just see this on a screen in the office". At that point, the manual workaround that's been fine for years suddenly looks like the thing holding everything else back.

What building the bridge actually involves

Getting data out of an industrial protocol and into something usable is genuinely a different job to normal web development, and it's worth knowing what's involved before you ask someone to quote for it.

• A gateway or polling service. Something needs to sit near the equipment, speak its protocol, and pull data at sensible intervals. This is usually a small dedicated piece of software, sometimes on a Raspberry Pi or small industrial PC on site, rather than something running in the cloud.
• Mapping raw values to something meaningful. Register 40012 needs to become "boiler flow temperature (°C)" somewhere in the system, documented properly so the next person doesn't have to reverse-engineer it again.
• Handling the quirks. Older equipment drops connections, sends malformed data occasionally, or needs a specific timing pattern to respond at all. Good integration code expects this and doesn't fall over the first time a device misbehaves.
• Security on the network side. A lot of this equipment was never designed with the internet in mind. Exposing it carelessly is a real risk. Getting the data out usually means a controlled, one-way flow rather than opening the device up directly.
• What happens with the data once it arrives. Raw numbers landing in a database aren't useful on their own. The value is in turning them into an alert, a dashboard, or a trigger for something else, which is where this connects back to normal software and automation work.

What to check before you commission this kind of project

If you're looking at this for your own business, a few things are worth knowing before you ask anyone to quote:

• What protocol does the equipment actually use? The manufacturer's manual or spec sheet usually says. If nobody has this documented, expect some time spent finding out.
• Is there existing documentation of what each register or data point means, or will that need working out from scratch?
• Does the equipment sit on a network already, or does something need installing on site to talk to it directly?
• How often do you actually need updates? Real time monitoring is a different, more demanding job than a dashboard that refreshes every few minutes.
• What should happen when the connection drops or a reading looks wrong? Deciding this up front saves a lot of confusion later.

This kind of work sits closer to systems integration than to typical app development, and it's often the unglamorous part of a project that makes everything built on top of it actually work. If your equipment is already producing data that never reaches anyone who could use it, that's usually a smaller and more contained problem to solve than it feels like from the outside. I'm happy to have a look at what you're working with and give you a straight answer on what it would take.