Modbus and BACnet gateways: types and how to choose one

Request quotes for a "Modbus gateway" or a "BACnet gateway" and the replies can describe quite different products. One passes serial bytes over a network. One routes Modbus requests to an RS-485 bus. One joins two BACnet networks. One translates registers into BACnet objects. One is a small computer that collects data from everything on site and sends it somewhere else. Each solves a different problem, and a product that does one of them well may not do the others at all.

This guide sorts the five, then gives a checklist and a sizing method for choosing one. The protocol gateway vs transparent bridge guide goes deeper into the difference between passing frames and translating data.

Five devices called a gateway

Modbus RTU to Modbus TCP gateways

A Modbus TCP client sends its request to the gateway's IP address on TCP port 502. The unit identifier in the request names the serial device. The gateway sends the request on the RS-485 bus, waits for the reply and returns it over TCP. The client sees each serial meter as a Modbus TCP device.

Check these points before you buy one:

• Serial ports. How many RS-485 lines, and whether they are isolated. Each line is one bus with its own baud rate.
• Unit identifier routing. Whether the gateway maps unit identifiers to serial addresses one to one, or lets you remap them. Two buses with a device at address 1 need a remap to share one IP address.
• Client connections. How many TCP clients can connect at once. All of them share the same bus, so their requests queue.
• Timeouts. The client's timeout must be longer than the gateway's serial timeout plus the time a request waits in the queue.
• RTU over TCP. Some products only pass RTU frames through TCP, with the CRC and without the MBAP header. That is a serial device server, not a Modbus TCP gateway, and the client must be set for it.

The Modbus TCP vs RTU guide shows both frame formats, and the RS-485 wiring guide covers the serial side.

BACnet routers and BACnet gateways

A BACnet router connects BACnet networks that use different data links, most often MS/TP buses and BACnet/IP. It does not change the data: a client on BACnet/IP reads the same objects and properties that the MS/TP controller holds. Every network behind the router needs a network number that is unique on the site. The router is often built into the BMS supervisory controller. The BACnet/IP vs MS/TP guide covers routing and bus capacity.

A BACnet gateway translates a different protocol into BACnet. A Modbus to BACnet gateway, for example, polls Modbus registers and presents each one as a BACnet object, usually an analog input or an analog value. Someone must configure each point: the register, the data type, the word order, the scaling, the units and the object it becomes. The BACnet vs Modbus guide explains what is lost or added in that mapping.

For a translator, ask:

• How many points it carries, and whether the licence is per point.
• Whether it supports writes in both directions, and how it handles the BACnet priority array.
• Whether it supports COV subscriptions, or only polling.
• What a BACnet client sees when a Modbus device stops answering: a stale value, a fault flag in Status_Flags or Reliability, or nothing.
• Whether it is listed by BACnet Testing Laboratories (BTL), and for which device profile.

IoT and edge gateways

An IoT or edge gateway is a small computer on site. It reads field devices over their own protocols and radios, stores each reading with its timestamp, and forwards the data to a platform over MQTT, HTTPS or files. Many also run calculations, dashboards and alarms locally, so the site keeps working when the internet link fails.

It differs from a protocol converter in three ways. It keeps a history on site, and it should replay stored data with the original timestamps after an outage. It usually talks to software, not to another controller. And it may read a protocol without serving it: a gateway that reads BACnet/IP devices does not necessarily present its own data as BACnet objects to a BMS. Check each direction you need.

How to choose a gateway

1. Name the function. Which of the five devices above does the project need? Write down the protocol and the role (client or server) on each side.
2. List the devices and points. Count devices, registers or objects, and the polling interval each needs.
3. Check the physical interfaces. RS-485 lines, isolation, Ethernet ports, radios and the cable route to each device.
4. Size the polling load. Add up every client's polls on each serial bus, as in the next section.
5. Check writes separately. List every write the project needs and test each one with the equipment owner.
6. Check what happens on failure. A device offline, the gateway restarted, the network down: the data must show a gap or a fault, never a frozen value that looks live.
7. Check security. User accounts, encrypted management access, TLS for data that leaves the site, and how firmware updates arrive. Plain Modbus and BACnet/IP have no authentication of their own.
8. Check management at scale. How you back up, restore and update the configuration of many gateways.
9. Check the environment. Power supply, mounting, temperature range and enclosure rating for the panel or plant room.
10. Test it. Run a pilot with the real devices, and compare every value with the device display.

Size the polling load

Every client behind a serial gateway shares one bus. Take 10 meters on a 9,600 baud bus with even parity, where each read returns 25 bytes and each meter takes 5 ms to answer:

That cycle is the time for one client to read each meter once. If a BMS, an energy platform and a commissioning laptop all poll the same meters through the gateway, the bus carries three cycles in every polling interval. Add them up before you set the intervals. One offline meter also adds a full timeout to every cycle of every client, so keep the timeout short and the number of retries low. The polling and retries guide shows the effect.

Where the ZGW-20 fits

The ZGW-20 Gateway is an edge gateway. It runs Edge, which reads:

• Modbus TCP devices on the site network, and Modbus RTU devices on a serial port (the I/O board's RS-485 input on the Industrial version, or a USB serial adapter), or through a ZMB Modbus interface over the Zigbee mesh.
• BACnet/IP devices as a client, including MS/TP controllers through a BACnet router on the site.
• EpiSensor Zigbee devices and supported third-party Zigbee and LoRaWAN devices.

Edge keeps the history on the Gateway, with dashboards, calculations and alerts. It sends data onwards over MQTTS or HTTPS, or as scheduled files, and it serves selected values to a BMS or SCADA system as Modbus TCP registers on port 10502.

It is not a like-for-like protocol converter. It does not route MS/TP to BACnet/IP, it does not connect to an MS/TP bus directly, and it does not present its data as BACnet objects. A project that only needs Modbus registers shown as BACnet objects in an existing BMS needs a protocol translator. A project that needs the data collected, stored and analysed on site, and sent to a BMS or a platform, is what the Gateway is for.

To try it with one device before you buy hardware, a Raspberry Pi set up with System Manager runs Edge with one Zigbee or Modbus device licensed free, such as a Modbus meter with up to 32 registers. It runs from a microSD card, so use it to evaluate, not for a business-critical site. See evaluate Edge on a Raspberry Pi.