A Modbus serial-to-TCP gateway lets a modern network reach old RS-485 devices, but it has to solve a routing problem: many serial devices sit behind a single IP address, and the gateway needs to know which one each incoming request is meant for. It does this through the unit identifier in the Modbus TCP request, mapping it to the correct serial slave address. This guide explains how that unit-ID remapping works, why two serial devices sharing the same slave ID create a collision the gateway cannot resolve, and how to configure unit-ID routing so a cloud poller reaches the intended RTU.
Gateway Unit ID Remap in one line: A Modbus serial-to-TCP gateway maps the unit identifier field in each Modbus TCP request to the slave address of a device on its RS-485 line, so that many serial devices behind one IP can each be addressed individually. The poller sends a request to the gateway's IP with the unit ID set to the target device, and the gateway forwards it to the matching serial slave and returns the reply. Where the serial slave IDs are unique, this is a direct one-to-one routing; where they collide, the gateway needs a remap or separate ports to tell them apart.
On an RS-485 multidrop line, every device has a slave address - a number that distinguishes it from the other devices sharing the same wires - and a serial master addresses a specific device by putting its slave address in the request. Modbus TCP keeps a field for the same purpose called the unit identifier. On a pure TCP device the unit ID is often ignored or set to a placeholder, because the IP address already identifies the device. But behind a gateway, the IP identifies the gateway, not the individual serial devices behind it, so the unit ID recovers its original meaning: it tells the gateway which serial slave the request is for.
The routing flow is straightforward once you see the unit ID as the selector. The poller opens a TCP connection to the gateway's IP and sends a Modbus TCP request with the unit ID set to, say, 3. The gateway reads that unit ID, converts the request into a serial Modbus frame addressed to slave 3, transmits it on the RS-485 line, waits for slave 3's reply, wraps that reply back into a Modbus TCP response, and returns it over the same connection. From the poller's perspective it looks like it is talking to many devices at one IP, distinguished only by the unit ID; from the serial devices' perspective, a normal serial master is polling them by slave address. The gateway is the translator sitting between the two worlds, and the unit ID is the piece of information that survives the translation to keep each request pointed at the right device.
The clean one-to-one case assumes every serial device behind the gateway has a distinct slave address. Reality often violates this. Devices frequently ship from the factory with the same default slave address, and in a plant assembled over years you can easily end up with two flow computers or two meters that both answer to slave ID 1. On separate serial lines this is fine, but if you try to put both behind one gateway on one RS-485 line, you have a collision: a request for slave 1 would be answered by both devices at once, garbling the response, and there is no unit ID value that can distinguish them because they share the same underlying address.
There are two standard ways out. The cleanest is to renumber one of the devices so the two have unique slave addresses on the shared line - then the gateway maps unit ID 1 to one and unit ID 2 to the other, and the collision disappears. When renumbering is not possible, the devices are placed on separate serial ports or separate gateways, so each colliding device lives on its own line where its address is unambiguous, and the gateway distinguishes them by which port the request maps to rather than by the shared slave ID. This is why gateways with multiple serial ports exist and why documentation warns against putting same-addressed devices on one bus: the unit ID can only route to a unique address, so uniqueness has to be established somewhere, whether by renumbering the device or by giving each its own port.
Configuring the routing means building the map inside the gateway and matching it in the poller. In the gateway you define which unit ID corresponds to which serial slave on which port - a table that says unit ID 3 goes to slave 3 on port 1, unit ID 7 goes to slave 5 on port 2, and so on. On a simple single-port gateway this is often a direct pass-through where the unit ID equals the serial slave address, but multi-port gateways and situations with duplicate addresses require an explicit remap so that a unit ID the poller uses lands on the intended physical device even if its native slave address is different. Getting this table right is the whole job: a wrong entry sends your poll to the wrong device and returns plausible-looking but incorrect data.
For a cloud SCADA platform such as Merobix polling remote sites, the practical picture is that each field gateway presents one IP, or one hostname, behind which several serial RTUs or meters sit, and the platform is configured with the correct unit ID for each device so its requests route to the right hardware. This lets a whole cluster of serial devices at a remote site be reached through a single network endpoint, which is efficient over the cellular and shared links typical of field connectivity. The essential configuration discipline is consistency between the two ends: the unit ID the poller sends for a device must match the entry in the gateway's remap that points to that device's serial address and port. When the two agree, one IP cleanly fans out to many field devices; when they disagree, requests silently reach the wrong RTU, which is exactly the kind of fault the remapping is meant to prevent when it is configured correctly.
It uses the unit identifier field in each Modbus TCP request to select which serial slave the request is for. The poller connects to the gateway's single IP and sets the unit ID to the target device; the gateway converts the request into a serial frame addressed to that slave, sends it on the RS-485 line, and returns the reply. This lets the IP identify the gateway while the unit ID distinguishes the individual devices behind it, so many serial devices are reachable through one address.
You get a collision the gateway cannot resolve, because a request for that address would be answered by both devices at once, garbling the response, and no unit ID can separate two devices that share the same underlying slave address. The fix is either to renumber one device so the two have unique addresses on the shared line, or to place each on a separate serial port or separate gateway so the gateway can distinguish them by port rather than by the duplicated slave ID.
Build a mapping table in the gateway that ties each unit ID to a specific serial slave address on a specific port, then set the poller to use the matching unit ID for each device. On a simple gateway the unit ID may pass straight through as the slave address, but with multiple ports or duplicate addresses you need an explicit remap. The key discipline is consistency: the unit ID the poller sends must match the gateway entry pointing to that device, or requests will silently reach the wrong hardware.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.