Protocol integration
Modbus Integration
How Modbus RTU and TCP devices are addressed, scaled and tested when meters, inverters, sensors and room controllers join a building platform.
What Modbus is and where it appears
Modbus is a simple request-response protocol. A master asks a slave for registers or coils; the slave answers with values. RTU runs over serial lines, TCP over Ethernet. It is popular because it is easy to implement, which is also why implementations vary. In buildings it appears in energy meters, inverters, battery systems, chillers, sensors, PLCs, room controllers and generator controls. The protocol is not a building standard in the way BACnet is; it is a data pipe that happens to be everywhere. That simplicity is an advantage at the edge and a risk at integration: there is no object model to negotiate, so every point has to be defined by hand. Protocol reference: slave addresses run from 1 to 247, with 0 reserved for broadcast, and a serial segment is usually planned around 32 unit loads. Those numbers are electrical limits, not a promise that a device will answer in time.
- Energy meters and sub-meters
- Solar inverters and battery systems
- Sensors, PLCs and room controllers
- Chillers, pumps and generator controls
Register maps and data types
Every Modbus integration begins with the register map. It should list the address, function code, data type, word order, scale factor, unit, access and meaning for each value. Address conventions differ: some documents count from zero, some from one, and a map that is off by one is a silent fault. A 32-bit value may arrive high word first or low word first. A status word may pack several alarms into one register. The point schedule should translate the register into an engineering value, not leave the raw number on the operator screen. Where a register is writable, the map should state the safe range and the effect of an out-of-range write. The map should be versioned with the device firmware. Function codes matter: reading holding registers is not the same as reading input registers, and writing a coil is not the same as writing a register. Signed and unsigned values need explicit treatment; a negative temperature can appear as a large positive number.
- Address base and function code
- Data type, word order and byte order
- Scale factor, offset and unit
- Bit-level status and alarm unpacking
Polling, timing and network design
Modbus is polled, so design the traffic rather than letting it happen. Group registers into blocks that can be read in one request. Set a polling interval that matches the value: a meter's energy register does not need the same rate as a pressure sensor. Avoid serial line lengths and baud rates that leave no margin. On TCP, watch connection limits, timeouts and reconnect behaviour. Where one device is slow, isolate it so it does not delay the whole poll cycle. A good integration document states the expected cycle time and what happens when a device does not answer. Polling is not a neutral setting; it determines how quickly an alarm is seen and how much bandwidth is left for everything else. Stagger polls across devices instead of starting them together. Set a timeout that is longer than the device's worst response, and a retry count that does not multiply the delay.
- Register blocking and read size
- Polling interval by value type
- Serial baud rate, parity and termination
- TCP connection limits and retries
Gateway selection and topology
A gateway is often needed to bring Modbus RTU devices onto an IP network, or to connect a serial segment to a platform that has no serial port. Choose it by the number of ports, the supported modes, the register mapping it allows, the isolation it provides and the diagnostics it exposes. Transparent gateways pass requests through; mapped gateways hold a register table internally. Transparent is easier to debug; mapped can reduce traffic and protect the device. Either way, document the gateway configuration and keep a backup. Where several masters share a line, define which one owns the device and how conflicts are resolved. A gateway is not a substitute for a register map. Check whether it supports the baud rate, parity and stop bits the device actually uses, whether it can poll several slaves without serial collisions, and whether its firmware and configuration are under change control.
- RTU-to-TCP gateway or native serial port
- Transparent vs mapped register handling
- Port count, isolation and diagnostics
- Multi-master ownership and conflict rule
Testing and commissioning
Test one device at a time. Read a known value and compare it with the device display. Write a safe setpoint and confirm the device accepts it. Check scaling across the range, not only at one point. Disconnect the device and confirm the platform shows a communication fault rather than a frozen value. For meters, compare energy accumulation over a period against the meter's own register. For inverters, confirm that the status word and fault bits decode correctly. Record the register, the raw value, the scaled value and the result. A register that reads correctly once is not commissioned; it is only a candidate. The test should be repeatable by the next engineer. Test the boundary values: zero, full scale, and a value just outside the alarm limit. Test a write that the device should reject, and confirm that it is rejected. Test recovery after a power cycle on both the device and the gateway.
- Known-value read against local display
- Safe write and feedback
- Scaling across the range
- Communication loss and recovery
- Meter accumulation check
Documentation, responsibilities and safeguards
Modbus has no standard object model, no discovery and no built-in authentication. Two devices with the same register map may still behave differently. Some manufacturers document only the registers they want read, not the ones a platform needs. Serial segments are electrically fragile; a single miswired device can take down the bus. TCP devices may accept only a small number of connections. The safeguards are practical: isolate segments, document every register, limit write access, test failure modes, and keep a local copy of the register map in the handover pack. Responsibility should be split between the device supplier, the controls contractor and the network owner, and written down. Do not expose Modbus TCP directly to the internet; segmentation and access control are the security model. Record who may write each register and why. A register map that lives only in the installer's laptop is not documentation.
- No discovery: inventory before configuration
- No standard object model: document everything
- Serial isolation and termination
- Write access limited and logged
- Register map in the handover pack
Modbus register definition
14 rows| Field | What to record | Why it matters |
|---|---|---|
| Slave address | Unit or device ID | Prevents collisions on the bus |
| Function code | Read/write coils or registers | Defines the request type |
| Register address | Decimal or hex, base convention | Avoids off-by-one mapping |
| Data type | 16/32-bit, signed, float | Selects correct decoding |
| Word order | High word first or low word first | Prevents scrambled values |
| Scaling | Factor, offset, unit | Produces an engineering value |
| Bit fields | Alarm and status bit meaning | Decodes packed status words |
| Polling | Interval, block size, timeout | Sets traffic and responsiveness |
| Serial settings | Baud rate, parity, stop bits | Matches the device and the gateway |
| Termination and isolation | Bias, termination, segment length | Keeps the electrical bus stable |
| Write rights | Which registers may be written | Protects equipment and data |
| Gateway mode | Transparent or mapped, port count | Determines behaviour and diagnostics |
| Test record | Raw value, scaled value, result | Proves the point works |
| Handover register map | Versioned map and device firmware | Keeps future changes possible |
Project images
3 images
Frequently asked
01What is the difference between Modbus RTU and TCP?
RTU runs over a serial line with slave addresses; TCP runs over Ethernet with IP addresses and unit identifiers. The register model is similar, but wiring, timing and diagnostics are different.
02Can you integrate our energy meters?
Usually, if the meters expose a documented Modbus register map and the communication settings are known. The audit confirms the map, the interface and whether the values are readable at the required interval.
03Why is my Modbus value wrong by a factor?
Scaling or word order is the usual cause. A 32-bit value split across two registers may need swapping, and a meter may report in different units. The register map and a known-value test resolve it.
04Can Modbus and BACnet work together?
Yes. A platform can read Modbus meters and BACnet plant, then present both in one model. A gateway is needed only when the two networks cannot be connected directly.
05Does Modbus support alarms?
Not as a standard alarm model. Alarms are decoded from status bits or calculated by the platform. The point schedule should define which bits mean what.
06How many devices can one Modbus line support?
It depends on the electrical limits, the device load and the polling time. The design should confirm the segment length, baud rate, termination and expected response time, not only the address range.
07Can we write setpoints over Modbus?
Often yes, if the device exposes writable registers and the project grants control rights. Writes should be limited, logged and tested, with a defined fallback if communication fails.
08Is Modbus secure?
Modbus itself has no authentication or encryption. Security comes from network segmentation, access control and limiting writes. It should not be exposed directly to the internet.
Next step
Bring us the building.
Tell us the building type, systems in scope and the outcome you need. We will map the shortest path to a working system.