Modbus TCP Unit ID Explained: Gateway Routing, 255, and the Slave ID Confusion
Every Modbus TCP frame ends its header with a single byte called the unit ID. On a direct TCP device it is usually dead weight, and integrators learn to ignore it. Then the request goes through a serial gateway, and that same byte becomes the address of a slave on an RS-485 bus. Half of all "the gateway works but I get no data" tickets are this byte set wrong.
Where the unit ID lives in the frame
Modbus TCP wraps the same PDU as RTU in an MBAP header (Modbus Application Protocol): a 2-byte transaction identifier, a 2-byte protocol identifier (always 0x0000), a 2-byte length, and the 1-byte unit identifier. The function code and data follow. The transaction ID exists so a client can run several requests on one connection and match each response to its request. The unit ID exists because the protocol designers wanted one frame format to survive the trip from Ethernet to serial and back.
Direct TCP devices: the byte most firmware ignores
A device that speaks Modbus TCP natively has no serial bus behind it, so there is nothing for the unit ID to select. The specification suggests 0xFF (255) for this case, and some devices also accept 0x00. In the field, most firmware answers a request with any unit ID at all. A minority validates the field and silently drops mismatches, which produces a timeout that looks exactly like a dead device. If the IP and port are known good and requests still time out, cycle the unit ID through 1, then 255, then 0 before you blame the network.
Gateways: the unit ID becomes a serial slave address
A Modbus TCP to RTU gateway has one job: lift requests off TCP, put them on the wire, and carry the answers back. The unit ID is the routing key. Unit ID 5 means "forward this frame to serial slave 5 and wait for its response." The gateway tracks the transaction ID, maps it to the serial transaction, and wraps the slave's reply into a TCP response with the same transaction ID and unit ID it received.
Two consequences matter. First, the gateway adds the serial round trip to every request: at 9600 baud, a full scan of a slow slave can take hundreds of milliseconds, and the TCP client needs a timeout that accounts for it. Second, the gateway's own configuration is a second address space. Many gateways listen on TCP with a configured "TCP unit ID" for their own diagnostic registers, then route everything else to the bus. Read the gateway manual: the difference between "unit ID 255 means the gateway itself" and "unit ID 255 is forwarded as 255" is a whole afternoon.
What each unit ID range means
| Unit ID | Meaning |
|---|---|
| 0 | Serial broadcast: every slave executes, none replies. No TCP equivalent, because TCP clients expect a response per request. |
| 1 to 247 | Valid slave addresses. On a gateway these select serial slaves; on some direct TCP devices they are also accepted. |
| 248 to 254 | Reserved by the specification. Do not use. |
| 255 (0xFF) | The convention for a direct Modbus TCP endpoint. Behind a gateway, behavior depends on the gateway's routing table. |
Unit ID vs slave ID vs node address
Vendors use all three terms for the same byte. Schneider calls it slave ID, Allen-Bradley gateways often say node address, and the specification says unit identifier. When a device manual asks for a "Modbus address," check whether it means this byte or the register address, because the off-by-one register confusion is its own problem: see Modbus Addressing Explained.
Debugging checklist
- Timeout on every request, port confirmed open: try unit IDs 1, 255, and 0 before anything else.
- Works directly on the device, fails through the gateway: the gateway is routing your unit ID to a serial address nobody answers.
- Intermittent data from several slaves: two clients may be issuing overlapping serial transactions; serialize requests or give each client its own unit ID range.
- Exception code 0x0B (Gateway Target Device Failed to Respond): the gateway reached the bus but the serial slave never answered. Check wiring and the slave address.
Watch the Bytes, Not the Guesswork
MacTools Modbus Poll for macOS: TCP + RTU master and slave simulator with a traffic view that shows every request, response, and exception as it happens. $19 one-time.
Get Modbus Poll: $19Frequently Asked Questions
What is the unit ID in Modbus TCP?
The unit ID is the last field of the MBAP header in every Modbus TCP frame. On Modbus RTU the same byte carries the slave address. On a pure Modbus TCP device many firmware builds ignore it, but a gateway reads it as the address of the serial-side slave the request should be routed to.
What unit ID should I use for a Modbus TCP device?
The Modbus TCP specification suggests 255 (0xFF), or 0, for a server that is a direct TCP endpoint and not behind a gateway. In practice most devices answer on any unit ID, while a few validate the field strictly. If requests time out on a known-good IP and port, try unit ID 1, then 255.
How does a Modbus TCP to RTU gateway use the unit ID?
The gateway maps the unit ID in the TCP request to a serial slave address on the RS-485 bus, forwards the request, waits for the slave's response, and wraps it back into a TCP reply. Unit ID 5 means serial slave 5. Serial broadcast (unit ID 0) has no TCP equivalent because TCP is point-to-point.
What is the difference between unit ID 0, 1-247, and 255?
Unit IDs 1 to 247 are valid slave addresses. Unit ID 0 is the serial broadcast address: every slave executes the request but none replies, so it is only meaningful on RS-485. Unit IDs 248 to 255 are reserved in the serial spec, and 255 (0xFF) is the convention for a direct Modbus TCP endpoint.
Why do my Modbus TCP requests time out with the wrong unit ID?
A TCP connection still opens because the port is listening, but the gateway forwards the request to a serial slave address that does not exist or never answers. No response ever comes back, so the client sees a timeout rather than an exception. This is the classic symptom of a unit ID mismatch through a gateway.
When polling is the job, not the test:
Voltrus SCADA polls Modbus plus OPC-UA, S7, EtherNet/IP and BACnet around the clock with dashboards, alarms, and history. Lifetime license from $49.