BACnet vs Modbus BACnet Modbus

These are the two protocols an integrator meets most, and they solve the same problem — move values between devices over a wire — from opposite directions. Modbus came out of the factory floor in 1979: small, dumb, and universal. BACnet was written for buildings in 1995 and is bigger, opinionated, and self-describing. You rarely choose between them — the equipment on the job already picked — but knowing exactly how they differ tells you what an integration will cost before you wire it. The single deepest difference: a Modbus register is anonymous, and a BACnet object describes itself.

Two philosophies: registers vs objects

Modbus exposes four flat tables of numbered slots — coils and discrete inputs (single bits), input and holding registers (16-bit words). That is the entire model. Holding register 40012 is sixteen bits and nothing more; the protocol carries no name, no units, no hint of scale. To turn 552 into "55.2 °F" you need the vendor's register map, off the wire, in a PDF. Read a Modbus device you have never seen and you get a grid of numbers with no legend.

BACnet exposes typed objects with named properties. A temperature is an Analog Input object whose Present_Value is a real number, whose Units property literally says degrees-fahrenheit, and whose Object_Name and Description spell out what it is. The description travels with the data. Browse a BACnet device cold and it tells you what each point is — because the self-description is part of the protocol, not a separate document. That one design choice cascades into almost every other difference on this page.

The comparison, dimension by dimension

Same job, different tool for it. The table is the field-relevant read; the sections after it unpack the rows that actually change how a day goes.

Discovery and change-of-value: the two you feel daily

Two rows above bite on every job. The first is discovery. Point a tool at a BACnet network and send a Who-Is; every device answers I-Am with its device instance, and you have an inventory in seconds. Modbus has no such thing — there is no "who is out there." You commission a Modbus device by being told its unit ID and its register map, and if the meter's DIP switches say slave 7 and the drawing says slave 3, nothing on the wire will correct you. The 5-digit register trap and byte-order guessing are downstream of the same fact: without self-description, every number is an act of faith in a document.

The second is polling vs. push. Modbus is strictly poll-and-answer: the client asks for register 40012, the server replies, and to see a change the client asks again — a hundred times a second across a graphic if it wants to look live. BACnet keeps polling too, but it also offers COV — change-of-value. Subscribe to a point — renewing the subscription before its lifetime runs out — and the device notifies you when an analog value moves past its COV_Increment; binary and multistate points notify on any change of state. On a busy trunk that is the difference between constant chatter and quiet-until-something-happens. It is also not guaranteed: a device only pushes COV if its BIBBs include the server half, so you check before you count on it.

Commanding a point, and knowing what a device can do

Writing exposes another split. In Modbus you write a value to a register and it sticks until someone writes again — last write wins, with no memory of who wrote or why. If two masters fight over a coil, the register just holds whatever landed last. BACnet wraps a commandable output in a 16-level priority array: life-safety near the top, automatic control in the middle, the operator override above that, and a Relinquish_Default at the bottom for when every level releases. Nothing is "just overwritten" — the winning command is the highest active priority, and releasing one lets the next-lower one take back over. It is more machinery, and it exists because a building has more than one thing that legitimately wants to command the same damper.

Finally, knowing what a box can do. With Modbus that knowledge is a vendor PDF: the register map is the interface contract, and there is no PICS-style capability statement or device profile to read — so two "Modbus" devices share only the framing. (The Modbus Organization does run a conformance-certification program, but it tests TCP server behavior, not a per-device capability declaration.) BACnet formalizes exactly that — a device publishes a PICS (Protocol Implementation Conformance Statement) listing its device profile, its exact BIBBs, and the object types it supports, so you can tell before wiring whether the integration is even possible. Neither approach frees you from reading the docs; BACnet just standardizes what the docs must say.

Which is better, and when you meet each

Neither is better; they are optimized for different jobs. Modbus wins on reach — it is small enough that almost anything with a processor can speak it, which is exactly why meters, drives, and one-off specialty gear ship with it. BACnet wins on buildings — discovery, typed points, priority commanding, alarms, schedules, and trends are in the protocol because a BMS needs all of them. Asking which is "better" is like asking whether a wrench beats a screwdriver.

In the field you meet Modbus at the edges — the power meter, the VFD, the BTU meter, the packaged unit with its own onboard controller — and BACnet in the middle, tying the HVAC controllers and the head end together. The seam between them is a gateway: it polls the Modbus device's registers on one side and re-presents them as BACnet objects on the other, so the register map is entered once, in the gateway's config, and the rest of the building sees clean self-describing points.

So the practical takeaway is not "pick one." It is: recognize which one is in front of you, know that a Modbus point needs a map and a BACnet point carries its own, and expect a gateway wherever the two meet. The Modbus and BACnet basics pages each go deep on one side; this page is the bridge between them.