BACnet vs Modbus vs OPC UA (plus LonWorks and KNX): a building integrator's guide

Photo by Troy Bridges on Unsplash.

Pick the wrong protocol on day one of a BMS integration and you're still paying for it five years later, usually in the form of a gateway box nobody remembers configuring. Get it right and the same integration barely gets a mention in the handover notes. The stakes are that lopsided, and yet the decision itself is rarely made on purpose. Most buildings just inherit whatever protocol the last controls contractor shipped.

That's not necessarily wrong. BACnet, Modbus and OPC UA all still have a job to do, and most estates run more than one of them side by side. LonWorks still shows up on older BAS retrofits; KNX often owns the room lighting and shading stack in European buildings. What matters for anyone trying to get sensor and meter data into an analytics layer is knowing which protocol is doing what, where each one runs out of road, and what that means for the gateway or agent sitting on top of it. This guide covers the six you'll meet most often, including when a BACnet Modbus gateway (or a LonWorks/KNX bridge) is the honest answer rather than a redesign.

BACnet: the default, with two flavors

BACnet (Building Automation and Control Network) is the protocol most modern BMS speak natively, and for good reason. It's an ANSI/ASHRAE and ISO standard purpose-built for this job, and it defines what a piece of data means, not just how the bytes move: a "value" arriving over BACnet already carries an object type, a temperature, a setpoint, an alarm state. That semantic layer is exactly what a generic industrial protocol doesn't give you, and it's why BACnet became the lingua franca of building automation rather than a general-purpose fieldbus adapted to the task.

BACnet MS/TP vs BACnet/IP

Where it gets messy is the split between BACnet/IP and BACnet MS/TP. IP is the modern, Ethernet-native version; MS/TP is the older serial variant still running on a lot of field-level controller networks, particularly anything installed before a site's last major refresh. The two don't talk to each other directly. An MS/TP segment needs a router or gateway to reach an IP network, and on older sites you'll find several such bridges stacked in a cabinet, each one a point of failure nobody's audited in years. Object naming is technically standardized, but vendors interpret the specification with enough local variation that a controls engineer moving between a Siemens Desigo estate and a Schneider EcoStruxure one will still hit friction mapping points cleanly.

For anyone building on top of a BMS, the practical takeaway is that BACnet coverage alone doesn't guarantee an easy read. Confirm whether the network you're integrating with runs IP or MS/TP, and budget for the gateway if it's the latter. Full details on the protocol, including how the object model works, are on our BACnet glossary page.

Modbus: old, simple, and still on every meter

Modbus predates BACnet by more than a decade. Modicon introduced it in 1979, and it survives today for the same reason a lot of old, boring technology survives: it's simple, it's royalty-free, and every vendor of every energy meter, sub-meter and legacy plant controller already knows how to implement it. There are two flavors in active use. Modbus RTU is the original serial form, running over RS-485 or RS-232 with compact binary frames. Modbus TCP wraps the same data model in Ethernet, and is the easier one to integrate on a modern network. A serial RTU meter reaches an IP network through a gateway, the same pattern as BACnet MS/TP.

The catch with Modbus is that it carries values, not meaning. A client polls a device for the contents of a numbered register, and that's it: no self-description, no built-in units, no indication of whether register 40012 is a kWh reading or a valve position. You need the device's register map to know what you're reading, and that map lives in a PDF from the meter vendor, not in the protocol itself. Get the map wrong and you'll happily ingest garbage that looks like data. There's also no authentication or encryption built in, which is rarely a problem on an isolated meter network but worth knowing before you expose one to anything wider.

In practice, Modbus and BACnet coexist constantly: BACnet runs the BMS, Modbus feeds the meters that BMS doesn't natively read. That mix is exactly the raw material energy management software needs to turn readings into decisions, provided every register gets mapped to something physical first. More on the protocol itself is on our Modbus glossary page.

OPC UA: modern, secure and semantic

OPC UA (Unified Architecture) is the newest of the three mainstream protocols and the one built with the most deliberate engineering. It replaced the older OPC Classic standard and was designed from the outset to be platform-independent, service-oriented and secure: authentication, encryption and access control are part of the specification, not bolted on afterward the way they'd have to be for Modbus. It also defines a genuinely rich object model, closer to BACnet's approach than Modbus's, which makes integration considerably less brittle once it's set up.

OPC UA's home turf is manufacturing and process industries, where it's become close to a default for machine-to-machine data exchange. In buildings it shows up wherever the BMS has been modernized recently or where building and industrial data are converging, for instance a data center, a factory with an attached office block, or any site where OT and IT teams are being asked to share a data layer. That convergence is a big part of why OPC UA matters for building integration even though it didn't start there. Subscriptions to value-change events work natively, so you get pushed updates rather than constant polling, and the security profile in use on a given site determines exactly how authentication is handled at connection time. The full picture is on our OPC UA glossary page.

oBIX: the newer one, mostly on Niagara

oBIX (Open Building Information Exchange) is worth a section of its own, not because it's replacing anything but because it keeps showing up in specific corners of the building stack that the other three protocols don't cover as cleanly. It's an OASIS standard, first published in 2006, and it takes a different technical approach: XML over HTTP web services rather than a purpose-built building protocol or an industrial fieldbus. In practice, the place you meet oBIX is a Tridium Niagara station. Niagara exposes its points over oBIX (and often BACnet too), and any Honeywell WEBs deployment or third-party JACE running on the Niagara framework will typically offer the same option.

We added oBIX support to the FrostLogic Edge Agent because we kept running into exactly this situation: a mixed estate where most buildings speak BACnet cleanly but one or two run a Niagara supervisor that's easier to read over oBIX. The Edge Agent now speaks four protocols, BACnet, Modbus, OPC UA and oBIX, and its first live oBIX connection ran against a Tridium Niagara BMS. That's not a case study, just how the integration matrix looks in a normal week of onboarding buildings. If you're running a Niagara estate specifically, our Honeywell Niagara integrations page covers the connection details, and the mechanics of oBIX itself are on our oBIX glossary page.

LonWorks: legacy BAS that still shows up

LonWorks (often branded LonWorks / LonTalk) was the distributed-control stack of the 1990s: SNVT-typed variables, a peer-to-peer fieldbus, and a large installed base across older Schneider TAC, Honeywell and Siemens estates. New specifications rarely pick it; when a site still has LonWorks, it's usually a retrofit leaving the field controllers in place. The practical path into a modern analytics layer is almost always a LonWorks-to-BACnet gateway that presents those points as BACnet objects, not a native LonWorks driver on every new tool.

KNX: room-level Europe, often beside BACnet HVAC

KNX is strong in Europe for room-level lighting, shading and user interfaces. The bus is decentralized: devices talk to each other without a central controller owning every switch. In commercial buildings that usually means KNX for the tenant-facing room stack and BACnet for the central HVAC / BMS backbone. They coexist through a BACnet-KNX gateway rather than one protocol absorbing the other. For German, Nordic and wider EU estates, expect that mix; for analytics, treat KNX like LonWorks: budget the gateway that surfaces the room points into BACnet (or another already-supported feed) instead of assuming every tool speaks KNX natively. See also our supported integrations for how Explore connects once those points are on a readable bus.

The comparison at a glance

Gateways and protocol conversion

Can BACnet communicate with Modbus? Yes, on the same estate, every week. They do not become the same protocol. A BACnet Modbus gateway (or router) translates points so each side keeps its own model: Modbus registers on the meter side, BACnet objects on the BMS side. The same pattern covers LonWorks → BACnet and KNX → BACnet when a room or legacy fieldbus has to feed a modern backbone.

The conversions you will commission most often:

• Modbus meters and plant → BACnet (or straight into an analytics agent that already speaks Modbus)
• LonWorks legacy controllers → BACnet during a BAS modernization
• KNX room stack → BACnet BMS for a single operator view
• Serial segments (BACnet MS/TP, Modbus RTU) → IP via physical gateways or routers

Gateways are a mapping and commissioning cost, and they are a failure point. Budget them. Do not pretend a mixed-protocol estate becomes "one protocol" because a box sits in the cabinet. For analytics specifically, the FrostLogic Edge Agent reads BACnet, Modbus, OPC UA and oBIX natively; LonWorks and KNX typically arrive after a site gateway presents them as BACnet (or another supported feed). That is the truthful path into FrostLogic Explore, not a claim that every fieldbus is spoken end-to-end.

What this means for getting data into an analytics layer

None of this changes what an analytics layer actually needs: read access to whatever's already running, without touching the control system. A building management system that runs BACnet for its AHUs, Modbus for its meters and possibly OPC UA, oBIX, LonWorks or KNX somewhere in the mix isn't an integration problem to be solved once. It's the normal shape of a real estate, and the ingest layer has to handle all of it at once, not force a site to standardize on one protocol before it can be read.

The FrostLogic Edge Agent is built around that reality. It sits on the BMS PC or server, reads BACnet, Modbus, OPC UA and oBIX read-only by default, and pushes the data to FrostLogic Explore, which turns it into a ranked decision queue instead of another dashboard. Write access to specific points is available once you grant it a scope. Vendor-specific setup, whether that's a Siemens Desigo BACnet network or a Schneider EcoStruxure estate with its own quirks, is documented on our integrations pages rather than buried in a generic protocol spec. Whatever your BMS speaks, we read it. See the supported integrations.

FAQ

Which protocol should I use for a new BMS integration? Use whatever the equipment already speaks. BACnet is the safe default for a modern BMS and the one to specify if you're writing a new controls contract. Don't force a protocol change purely for the sake of standardization; a working Modbus meter or an OPC UA feed from a process system doesn't need replacing.

Can BACnet and Modbus be used together / can BACnet communicate with Modbus? Yes. They coexist on most mixed estates, and a BACnet Modbus gateway is how they share points when each side needs the other's model. BACnet typically runs the BMS and its controllers; Modbus feeds energy meters, sub-meters and older plant that never moved up to BACnet. Neither protocol needs to disappear for the other to work.

Do I need a gateway for LonWorks or KNX to feed analytics? Usually yes. Explore's Edge Agent reads BACnet, Modbus, OPC UA and oBIX natively. LonWorks and KNX almost always arrive through a site gateway that presents those points as BACnet (or a similar supported feed). Budget the gateway and its point mapping; don't assume native LonWorks or KNX on the analytics side.

BACnet/IP vs MS/TP: which one do I need a gateway for? BACnet/IP and BACnet MS/TP do not talk directly. MS/TP needs a router or gateway to reach an IP network. If your field controllers are still on MS/TP, plan for that bridge before an IP-native analytics agent can read them.

Does FrostLogic Explore need a gateway for OPC UA? No. Explore reads OPC UA natively, including subscriptions to value-change events, with authentication and encryption handled per the security profile the site already uses. Gateways come into play for BACnet MS/TP and Modbus RTU, the two serial variants, not for OPC UA.

What is oBIX and do I need it? oBIX is a web-services standard for reading building data over HTTP, most often met on a Tridium Niagara station. You need it specifically if part of your estate runs Niagara or a Niagara-based product like Honeywell WEBs. If your buildings run a standard BACnet BMS with Modbus meters, oBIX simply won't come up.