Modbus Gateway to MQTT: Getting Legacy Plant Into SCADA

Modbus Gateway to MQTT: Getting Legacy Plant Into SCADA

Last updated: 2 September 2026

In short: A Modbus gateway reads registers from legacy plant over RS485 and republishes them as MQTT, LoRaWAN or a cloud feed. The retrofit rarely fails on the concept. It fails on register limits, byte order, polling rates and a two-wire bus that was never terminated properly. Those five things are what this guide is about.

Modbus gateway data flow diagram, showing legacy RS485 plant polled by function codes 3 and 4 and republished as named MQTT topics.
The gateway takes the master role, reads named registers, and republishes them as something modern. SOURCE: Milesight UC300 datasheet

There is a generator, a chiller, a weighbridge or a variable speed drive somewhere on your site with a serial port and forty years of service left in it. It already knows everything you want to know. It simply has no way to tell anyone.

Bridging it is a well-trodden job, and the traps are consistent enough to list. Here is what actually goes wrong, in the order it usually goes wrong.

What does a Modbus gateway do?

A Modbus gateway polls. Modbus is a request and response protocol with one master and many slaves, so nothing is ever pushed to you. A Modbus gateway takes on the master role, asks each device for specific registers on a schedule, and forwards the answers somewhere useful.

The data model has four types. Coils and discrete inputs are single bits. Input registers and holding registers are 16 bits each, with holding registers readable and writable and input registers read only.

Function code 3 reads holding registers and function code 4 reads input registers. Those two cover the overwhelming majority of monitoring work, because almost everything you want to read from plant is a measured value sitting in one of them.

The critical thing to internalise is that a register is just sixteen bits. It carries no units, no scaling and no name. The device documentation is the only thing that tells you register 40007 is a temperature in tenths of a degree, and without that document a Modbus gateway is reading numbers with no meaning.

Thirty two registers is not one variable speed drive. Generous for a pump station, nowhere near enough for a modern drive exposing several hundred.
Generous for a pump station, nowhere near enough for a modern drive exposing several hundred. SOURCE: Milesight UC300 datasheet

Trap one: the register limit nobody checks

This is the constraint that kills more retrofits than any other, and it is almost never in the quote. A Modbus gateway does not have unlimited capacity.

The Milesight UC300 datasheet states support for reading 32 Modbus registers and connecting up to 32 Modbus devices, alongside 4 digital inputs, 2 relay outputs, analogue inputs and a PT100 RTD input.

Thirty two registers is generous for a pump station and nowhere near enough for one modern variable speed drive, which can expose several hundred. Count the registers you genuinely need before choosing hardware, not after.

The discipline this forces is healthy. Most people asking for “all the data” want six numbers and a fault word. Write down the actual list, and the register budget usually stops being a problem.

Trap two: byte order and data types

Modbus register data is big-endian, high byte first. That part is settled. The problem is everything larger than sixteen bits.

A 32-bit value, such as an energy total or a floating point reading, occupies two consecutive registers, and the standard does not dictate which register holds the high half. Manufacturers made different choices, and both are in the field.

The symptom is unmistakable once you have seen it. Your reading is wildly wrong, jumps erratically, or sits at a huge number that changes in the wrong direction. Swap the word order and it becomes sensible. Any competent Modbus gateway lets you configure this per register, and configuring it is not optional.

Signed against unsigned catches people the same way. An unsigned reading of a value that can legitimately go negative gives you 65,000-odd instead of minus one, which looks like a fault rather than a frost.

Trap three: polling too fast

A Modbus gateway is limited by a slow bus, because every request costs time on a shared bus. At 9600 baud a single read is measured in tens of milliseconds, and you have to wait for the reply before asking the next question.

Poll thirty registers across five devices every second and the bus saturates. Devices start timing out, your Modbus gateway logs errors, and the data you do get arrives late and irregularly.

Match the poll rate to the physics of what you are measuring. A tank level that moves over hours does not need reading every second. A flow rate might. Poll fast things fast and slow things slowly, rather than putting everything on one interval because it was easier to configure.

The UC300 supports baud rates from 1200 to 115200 bps. Higher is not automatically better on a long or noisy run, because signal integrity degrades with speed and distance.

More commissioning time is lost to wiring than to software. RS485 is a differential bus with rules, and legacy installations routinely break them.
RS485 is a differential bus with rules, and legacy installations routinely break them. SOURCE: Indiott commissioning guidance

Trap four: the RS485 bus itself

More Modbus gateway commissioning time is lost to two wires than to all the software combined. RS485 is a differential bus with rules, and legacy installations frequently break them.

  • Topology. It is a daisy chain, not a star. Spurs off a central point cause reflections and intermittent faults that look like device problems.
  • Termination. Both ends of the bus need terminating, typically 120 ohms. Not one end, not every device, both ends only.
  • Ground reference. A and B are not enough on a long run between separate panels. Without a common reference the bus can drift outside the receivers’ range and fail unpredictably.
  • Polarity. A and B swapped is silent failure, not an error. Labelling conventions genuinely differ between manufacturers, so try both before condemning a device.
  • Addressing. Two devices with the same slave address produce corrupted or contradictory replies that look like random data corruption.

Diagnose a Modbus gateway fault from the bus outward. If one device is unreliable, suspect that device. If all of them are, suspect termination, grounding or a slave address collision.

Trap five: bridging OT to IT without thinking

Modbus has no authentication and no encryption. Anything that can reach the bus can read it, and on holding registers, write to it. That was an entirely reasonable design for an isolated serial link in 1979 and it is a genuine consideration the moment a Modbus gateway connects that link to anything else.

The NCSC notes that OT priorities are often safety, reliability and availability given the physical dangers associated with OT failure, and that increased connectivity to enterprise technologies and the internet can increase system vulnerabilities, while stressing that organisations should ensure connectivity between OT environments and wider enterprise networks or the internet is managed securely.

Two practical rules follow. Make the link read only wherever the use case allows, because a monitoring project has no reason to hold write capability on a control system. And place the Modbus gateway so it initiates outbound connections rather than accepting inbound ones.

If the plant is genuinely critical, a monitoring bridge is not the right control boundary at all. Our guides to data diodes and IT/OT segmentation and OT cybersecurity best practices cover where that line should sit.

Choosing the backhaul for a Modbus gateway

Once the registers are read, they have to leave the building. The choice is usually between a wireless long-range link and cellular, and it is decided by how much data you are moving rather than by how far.

Airtime, not distance, decides which backhaul fits. A handful of registers every fifteen minutes is a very different job from thirty a minute.
A handful of registers every fifteen minutes is a very different job from thirty a minute. SOURCE: Indiott deployment guidance

LoRaWAN suits a small, slow payload. A handful of registers every fifteen minutes fits comfortably, and the site inherits the range and battery advantages of the wider network. It does not suit thirty registers a minute, because the airtime is simply not there under duty cycle rules.

Cellular suits richer data and faster intervals, at the cost of a SIM per site and a continuous power draw. If the plant already has a router, a Modbus gateway with an Ethernet or serial hop into it is often the least intrusive option of all.

The decision that matters more than either is where the decoding happens. A Modbus gateway that publishes named, scaled, unit-tagged values is doing the useful work once, at source. One that publishes raw sixteen-bit words pushes that job onto every consumer downstream, and the register map then has to be maintained in several places at once.

Do the scaling and naming at the Modbus gateway. It is the only component in the chain that has the register map as a first-class concern, and it is the only place the mapping will reliably stay correct.

A commissioning sequence that works

Prove each layer before adding the next. Skipping a step here is how a Modbus gateway install turns into three site visits.

  • Read the device manual first. Get the register map, data types, word order and default slave address before ordering anything.
  • Prove the bus with a laptop. A serial adapter and a Modbus polling tool confirm wiring and addressing without any gateway in the picture.
  • Read one register. Confirm one known value against the device’s own display. That single comparison validates addressing, byte order and scaling at once.
  • Add the rest, then publish. Only once the values are right locally should you point anything at MQTT or the cloud.
  • Log errors from day one. Timeout counts per device are your early warning that a bus is marginal rather than broken.

Frequently asked questions

What is the difference between Modbus RTU and Modbus TCP?

RTU is the serial form over RS485 or RS232, with a slave address and a CRC. TCP carries the same data model over Ethernet. A Modbus gateway commonly bridges one to the other, or bridges either to MQTT.

How many devices can one Modbus gateway poll?

The UC300 supports up to 32 Modbus devices, which aligns with the classic RS485 driver limit. Cable length, baud rate and noise all reduce what is achievable in practice on a real site.

Why are my readings wrong by a factor of ten?

Almost always scaling rather than a fault. Devices frequently report tenths or hundredths to keep a value inside sixteen bits. The register map will state the multiplier.

Can a Modbus gateway write to plant as well as read it?

Technically yes, through holding registers and coils. Whether it should is a separate decision that belongs with whoever owns the control system, and for pure monitoring the answer is usually no.

Do I need a PLC as well?

Not for monitoring. If you only need to observe and alert, a gateway with digital and analogue inputs plus a serial port often replaces a small PLC entirely. Closed-loop control is a different question.

The short version

A Modbus gateway retrofit is a documentation exercise wearing overalls. Get the register map, count your registers against the hardware limit, fix word order early, poll at a rate the bus can sustain, wire RS485 by the rules, and keep the link read only unless there is a compelling reason not to.

For choosing between controller models, our IoT controller comparison covers the UC300 against the UC100 directly, and what LoRaWAN is explains the wireless side of the same link.

The Milesight UC300 IoT controller is priced and in stock. Add it to a quote and we will come back within one working day.

Next step

Get a priced kit list for your site

Answer three quick questions and tell us where to send it. An engineer replies within one working day with the parts, the prices and the lead time.

Rather talk it through? Call 023 9223 3611

How many sites is it for?
Roughly how many sensors or points to monitor?
When do you need it?

Answered within one working day

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *