BACnet + Modbus in One Building: A Gateway Mapping Strategy
When the BMS speaks BACnet but the chiller, VFDs and energy meters on site only speak Modbus RTU or Modbus TCP, the fix isn't a second head-end -- it's a documented mapping through a BACnet/Modbus gateway.
How we plan the mapping
Audit every Modbus device
List each chiller, VFD, meter and controller on site, and pull its register map -- address, data type, scaling and function code -- straight from the vendor documentation, not assumptions.
Draft the BACnet object list
Decide, register by register, which becomes an AI (readings) and which becomes an AV or BV (commandable points), then agree the Object_Name convention before anyone touches the gateway.
Configure the gateway and assign ownership
Program the register-to-object translation on the gateway and record which single device -- BMS or local controller -- holds write access to each point, so nothing fights itself.
Commission and verify in the BMS
Confirm every mapped object reads Present_Value correctly, check Status_Flags on communication loss, and walk the point list against the original Modbus register map before sign-off.
What the mapping has to get right
Every Modbus register becomes a native BACnet object
A correctly configured gateway exposes each Modbus holding or input register as its own BACnet object -- typically Analog Input for readings, Analog Value or Binary Value for commandable points -- so the whole Modbus points list shows up in the BMS graphics like any other native BACnet device.
Register map, not guesswork
Modbus has no self-describing object model -- the source register address, data type and scaling factor have to be documented from the device manual before any object gets created on the gateway.
Match the object type to the point
Readings map to Analog Input; commandable setpoints and start/stop points map to Analog Value or Binary Value, following the same Present_Value and Status_Flags conventions as native BACnet devices.
One naming convention, no AI-1/BO-14
Gateway-generated objects inherit whatever name the integrator gives them -- apply the same floor-system-point convention used on native BACnet devices, or the BMS graphics become unreadable.
One device owns each write
Decide up front whether the BMS or a local controller has write access to a mapped point -- the Priority_Array resolves conflicts between BACnet clients, but it can't resolve a fight between BACnet and Modbus writing to the same register.
Check the gateway's PICS before wiring
The gateway's own PICS states exactly which BACnet object types and services it supports as a server -- confirm it covers what your Modbus device list needs before the mapping is designed, not after.
What's in the mapping package
Documentation an installer, integrator or facilities team can hand over and reuse.
- Modbus register map for every source device (address, data type, scaling, function code)
- Target BACnet object list with agreed Object_Name and Description convention
- Write-ownership table showing which device holds write access to each point
- Gateway configuration record and PICS cross-check
- Commissioning checklist for verifying Present_Value and Status_Flags after go-live
Frequently asked questions
Can a BACnet BMS talk to Modbus RTU devices directly?
No -- BACnet and Modbus are different protocols with different object models. A BACnet/Modbus gateway sits between them, polling the Modbus device and exposing each register as a BACnet object, so the BMS never talks Modbus itself.
What BACnet object type should a Modbus holding register become?
It depends on the point, not the register type. A read-only measurement typically becomes an Analog Input; a register the BMS needs to write becomes an Analog Value or Binary Value, matching how the point is actually used.
Which side should own write access to a mapped point?
Exactly one device should hold write access -- either the BMS through the gateway or a local controller directly on the Modbus device. Document this per point; letting both sides write to the same register causes intermittent, hard-to-diagnose conflicts.
Do we need a BBMD for this kind of gateway setup?
Only if the gateway and the BMS server sit on different IP subnets and need BACnet/IP broadcasts -- Who-Is/I-Am discovery -- to cross that boundary. A gateway on the same subnet as the BMS server usually doesn't need one.
How is this different from an OPC-UA bridge?
A BACnet/Modbus gateway is a direct, purpose-built translation between two field protocols. OPC-UA is typically added as a broader integration layer when a third system -- SCADA, an MES or an analytics platform -- also needs the same data; see our OPC-UA / BACnet / Modbus bridge page for that pattern.
Bringing Modbus devices into a BACnet BMS?
Send us the device list and we'll help you plan the register-to-object mapping before the gateway gets configured.