Modbus Unit Identifier Explained: Unit ID by Scenario

You just installed a Modbus TCP device. The manual says “set Unit ID to 1.” Your PLC configuration asks for a Unit ID. Another device manual says “Unit ID is ignored.” A third says “Unit ID must be 0xFF.” What is going on? Which one is right?

All of them are right. The Unit Identifier — usually called Unit ID — is one field with several different meanings depending on how your Modbus TCP device is deployed. In one setup, it identifies a slave on a serial bus behind a gateway. In another, it is ignored entirely. In a third, it must exactly match a configured value or the device refuses to answer.

This article organizes the confusion by scenario. Find the deployment pattern that matches your setup, and you will know exactly what Unit ID to use and why.

The Unit ID field in one paragraph

The Unit Identifier is a 1-byte field (byte 7 of the Modbus TCP MBAP header) that identifies the intended recipient of a Modbus TCP request. Values run from 0 to 255. Values 1 through 247 identify individual devices, value 0 is historically the broadcast address on serial buses, and values 248 through 255 are reserved by the Modbus specification. The Unit ID exists to preserve the “slave address” semantics that Modbus RTU has always had — critical when a Modbus TCP request needs to reach a specific device on a serial bus behind a gateway. In other deployment scenarios its meaning varies: some devices ignore it, some require a specific value, and some allow it to be configured. For the technical field position and encoding, see our Modbus TCP MBAP Header article.

Find your scenario

Four common deployment patterns cover most Modbus TCP installations. Find yours below.

Scenario A: Direct Modbus TCP device

A PLC or SCADA client connects to a Modbus TCP device by its IP address. There is no gateway involved. The device natively speaks Modbus TCP.

Client (192.168.1.100)
   ↓ TCP port 502
Modbus TCP device (192.168.1.50)

How Unit ID behaves in direct-TCP mode

Different vendors handle Unit ID differently for direct devices. Four common patterns:

Pattern 1: Ignore Unit ID entirely. The device processes the Modbus request regardless of the Unit ID value. Any value (0, 1, 255) works. This is the most common approach for direct-TCP devices.

Pattern 2: Require a specific value. The device only responds if Unit ID matches a specific value, often 0, 1, or 255 (0xFF). Requests with other Unit IDs are silently dropped or return an exception. Documentation usually specifies which value.

Pattern 3: Configurable Unit ID. The device has a configurable Unit ID value (often called Server ID or Node ID in the device UI). The client must send that value.

Pattern 4: Reject Unit ID 0. Some devices explicitly reject Unit ID 0 as a protocol violation (interpreting it as “broadcast, not for you”). Any non-zero value works.

What to do

Read the device manual. Look for “Unit ID,” “Unit Identifier,” “Slave ID,” “Server ID,” or “Node ID.” The value your client should use is documented there. If the manual is silent, try 1 first, then 255, then 0.

Common defaults you will encounter:

Note: these are common defaults, not universal rules. Always verify with the specific device.

Scenario B: Modbus TCP-to-RTU gateway (the main use case)

A client connects to a gateway that fronts a Modbus RTU network on RS-485. The Unit ID field is essential here.

Client (192.168.1.100)
   ↓ TCP port 502
Gateway (192.168.1.10)
   ↓ RS-485
Slaves: [1] [2] [3] [4] [5] ... [20]

How Unit ID behaves in gateway mode

The Unit ID field tells the gateway which slave on the RS-485 side should receive the request. The gateway performs a straightforward pass-through:

1. Client sends Modbus TCP request with Unit ID 5
2. Gateway receives the request
3. Gateway forwards to RS-485 with slave address 5
4. Slave 5 responds on RS-485
5. Gateway wraps the response back as Modbus TCP with Unit ID 5
6. Client receives the response

The Unit ID and the RTU slave address are the same value on both sides.

What Unit ID to use

Match the target slave’s RS-485 address. If you want to talk to slave 5 on the RS-485 bus, send Modbus TCP with Unit ID = 5. Simple 1:1 mapping.

If the RS-485 bus has 20 slaves numbered 1-20, then your PLC or SCADA can address them all through one gateway IP by cycling through Unit IDs 1-20. This is the primary reason Unit ID exists in Modbus TCP.

Broadcast in gateway mode

If the gateway supports it, Unit ID 0 becomes a broadcast to all RS-485 slaves. The gateway forwards the request as an RTU broadcast (slave address 0), and no responses come back. Not all gateways implement this. For details, see our Modbus Broadcast Function Codes article.

Scenario C: Multi-port gateway (multiple RS-485 buses)

Some industrial gateways host multiple RS-485 ports, each fronting its own set of slaves. A single gateway IP address serves dozens or hundreds of slaves across multiple buses.

Client (192.168.1.100)
   ↓ TCP port 502
Multi-port Gateway (192.168.1.10)
   ├── RS-485 Bus 1: slaves [1] [2] [3] ... [30]
   ├── RS-485 Bus 2: slaves [1] [2] [3] ... [30]
   └── RS-485 Bus 3: slaves [1] [2] [3] ... [30]

The problem: if each bus has slave 1, how does the gateway know which slave 1 you mean?

Two common approaches

Approach 1: Unit ID range mapping. The gateway maps Unit ID ranges to physical ports:

Client sends Unit ID 5 → gateway forwards to Bus 1 slave 5. Client sends Unit ID 35 → gateway subtracts the offset and forwards to Bus 2 slave 5.

This approach limits how many slaves you can address per bus (Unit ID has 247 usable values), but it fits in the standard Modbus TCP protocol.

Approach 2: Multiple gateway IP addresses. The gateway exposes one IP address per physical port. Each IP has its own Unit ID space of 1-247. This scales better but requires managing multiple IPs.

Some gateways combine both approaches — each port has its own IP, and within each IP the Unit ID maps to the local slave address.

What to do

Read the gateway manual and understand its Unit ID mapping strategy. Document your mapping in the commissioning notes so the next engineer does not have to reverse-engineer it. Some gateways expose the mapping in their web UI; others require config files.

Scenario D: TCP-to-TCP gateway (rare but valid)

Some deployments use a gateway that fronts multiple downstream Modbus TCP devices, not RS-485 slaves.

Client (192.168.1.100)
   ↓ TCP port 502
Aggregation Gateway (192.168.1.10)
   ├── Unit ID 1 → forwards to Device A at 10.0.0.5
   ├── Unit ID 2 → forwards to Device B at 10.0.0.6
   └── Unit ID 3 → forwards to Device C at 10.0.0.7

Uses:

• Centralized authentication or logging at the gateway
• Firewall traversal — expose one IP outside, many devices inside
• Client simplification — one connection reaches many devices
• Protocol translation — different vendor protocols mapped to Modbus TCP

The Unit ID selects the downstream device. The gateway maintains a mapping table from Unit ID to destination IP.

This scenario is less common than TCP-to-RTU but exists in some SCADA architectures and industrial IoT platforms.

Unit ID value ranges

The full value space:

Some devices use 248-255 in vendor-specific extensions despite the reserved status. If you see documentation using these values, follow it — but expect potential compatibility issues with strict Modbus TCP clients.

The special case of 0xFF (255)

Value 0xFF (255) is technically reserved, but many direct Modbus TCP devices use it as a “wildcard” or “match anything” Unit ID. When a manual says “use Unit ID 255,” it usually means the device treats 255 as “accept any client.” This is convention rather than specification.

The special case of 0x00 (0)

Value 0 has different meanings depending on context:

• On a serial bus: broadcast to all slaves
• In direct Modbus TCP: varies — some devices reject, some ignore, some accept
• In a Modbus TCP-to-RTU gateway: typically broadcast to serial slaves if the gateway supports it
• In some Modbus TCP client libraries: treated as “no target” and rejected before sending

If you can, avoid Unit ID 0 in direct Modbus TCP unless the device documentation explicitly supports it.

Terminology cross-reference

Different documentation calls this field by different names:

All refer to the same 1-byte field. For more on the naming update, see our Modbus Client-Server vs Master-Slave Terminology article.

Common pitfalls

Real deployments hit these regularly:

Assuming the device ignores Unit ID. Some direct Modbus TCP devices strictly enforce a specific Unit ID and silently drop requests with any other value. Symptom: your client sends requests but gets no response. Fix: check the device manual for the required Unit ID.

Using Unit ID 0 for a direct device. Unit ID 0 has different behavior across implementations. Avoid it for direct TCP devices unless explicitly documented as valid.

Mismatched Unit ID and slave address. In a gateway scenario, the Unit ID must match the RS-485 slave address exactly. Off-by-one errors, hex/decimal confusion, or copy-paste mistakes create hard-to-diagnose failures.

Duplicate slave addresses on different bus segments. In a multi-port gateway, if two RS-485 buses both have slave 1, and the gateway does not map them to different Unit IDs, requests to Unit ID 1 become ambiguous. Fix by understanding your gateway’s mapping strategy.

Reserved Unit IDs (248-255) causing rejection. Some strict Modbus TCP libraries reject Unit IDs in the reserved range. If your device uses Unit ID 254 (per its manual) but your client library rejects it, look for a config option to override the strict validation.

Changing device Unit ID mid-connection. Some devices allow reconfiguring the Unit ID at runtime. Changing it mid-conversation can produce unpredictable behavior. Reconfigure only when the device is idle.

Gateway Unit ID passthrough vs translation. Some gateways pass Unit ID through unchanged; others translate between TCP and RTU addressing. If the TCP-side and RTU-side Unit IDs differ, document the mapping clearly.

Troubleshooting Unit ID issues

If your Modbus TCP request gets no response, Unit ID is one of the first things to check.

Checklist

1. Verify the Unit ID in the request. Use Wireshark or a Modbus TCP debug tool to see what Unit ID your client is actually sending.
2. Compare to the device’s expected Unit ID. Read the manual. Look at the device’s configuration UI. Compare with what your client is sending.
3. For gateways, verify the mapping. Confirm the Unit ID the client sends matches the target slave address on the serial side.
4. Try Unit ID 1, then 255. These are the most common defaults for direct TCP devices.
5. Check for reserved value rejection. If you are using Unit ID 248-255, some strict clients or servers may reject it.
6. Verify no duplicate slaves. In multi-port gateway setups, confirm no address conflicts.

Wireshark filters

Useful filters for Unit ID troubleshooting:

mbtcp.unit_id == 5           # Requests to Unit ID 5
mbtcp.unit_id == 0           # Broadcast requests
mbtcp.unit_id >= 248         # Reserved-range Unit IDs

For deeper Wireshark work, see our Wireshark for Modbus TCP guide.

Common questions

What is a Modbus Unit Identifier?

The Modbus Unit Identifier — commonly called Unit ID — is a 1-byte field in the Modbus TCP MBAP header that identifies the intended recipient of a request. Values run from 0 to 255. Values 1-247 identify individual devices, 0 is historically the broadcast address on serial buses, and 248-255 are reserved. The Unit ID exists to preserve the “slave address” semantics from Modbus RTU, which is critical when Modbus TCP requests need to reach specific devices behind a gateway.

What is the difference between Unit ID and Slave ID?

Unit ID and Slave ID refer to the same field with different names. Unit ID is the Modbus TCP terminology. Slave ID (or Slave address) is the traditional Modbus RTU/ASCII terminology. Server ID is the modern client-server terminology introduced in 2020. All three names refer to the same 1-byte field with the same value ranges.

What Unit ID should I use for a direct Modbus TCP device?

It depends on the device. Check the device manual for the required or default Unit ID. Common defaults include 1, 255 (0xFF), or “any value accepted.” Some direct Modbus TCP devices ignore the Unit ID entirely; others strictly enforce a specific value. If the manual is silent, try Unit ID 1 first, then 255, then check the device’s configuration UI for a settable value.

What is Unit ID 0 in Modbus TCP?

Unit ID 0 has different meanings depending on context. On serial buses, 0 is the broadcast address that all slaves receive but none respond to. In direct Modbus TCP, behavior varies — some devices ignore Unit ID 0, some reject it, some accept it as a valid request. In Modbus TCP-to-RTU gateways that support broadcast forwarding, Unit ID 0 is typically forwarded as a broadcast to all RS-485 slaves. When in doubt, avoid Unit ID 0 for direct TCP devices unless the manual explicitly documents it.

What is Unit ID 255 (0xFF) in Modbus TCP?

Value 255 (0xFF) is technically in the Modbus specification’s reserved range (248-255). Despite the reserved status, many direct Modbus TCP devices use 0xFF as a “wildcard” or “match anything” Unit ID. If a device manual says “use Unit ID 255,” it usually means the device accepts any incoming request regardless of Unit ID. This is convention rather than a formal specification.

Do all Modbus TCP devices need a Unit ID?

The Unit ID field is required in every Modbus TCP MBAP header — you cannot omit it. However, how the receiving device uses it varies. A direct Modbus TCP device might ignore the value entirely. A gateway uses it to route the request to a specific slave. Every Modbus TCP request includes a Unit ID; whether it matters depends on the target device.

How does Unit ID work with a Modbus TCP-to-RTU gateway?

The gateway uses Unit ID to select which RS-485 slave should receive the request. If you send a Modbus TCP request with Unit ID 5, the gateway forwards it to slave 5 on the RS-485 side, then wraps the slave’s response back as Modbus TCP with Unit ID 5. This is the primary reason Unit ID exists — to preserve serial slave addressing across TCP transport.

Can I use Unit IDs in the reserved range (248-255)?

The Modbus specification reserves 248-255 for future use, so strict Modbus TCP implementations may reject these values. In practice, some vendor devices use them anyway — 255 (0xFF) is particularly common as a “wildcard” Unit ID. If your device documentation specifies a Unit ID in this range, use it, but be aware that some strict client libraries may need configuration overrides to allow reserved values.

How do I find my Modbus device’s Unit ID?

Check three places: (1) the device manual for the default or required Unit ID, (2) the device’s configuration UI (web interface, front panel, or configuration tool), and (3) any commissioning notes from previous engineers. If all three are silent, try Unit ID 1 first — it is the most common default across vendors.

What is the maximum number of Modbus devices I can address with Unit ID?

The Unit ID field has 8 bits, giving values 0-255. Values 1-247 are usable for individual devices, so a single Modbus TCP endpoint (gateway or direct device with configurable Unit ID) can address up to 247 devices. Values 0 and 248-255 are reserved. If you need to address more devices, use multiple gateway IP addresses or a multi-port gateway with Unit ID range mapping.

What happens if I send a request with the wrong Unit ID?

Depends on the target. A direct TCP device that ignores Unit ID processes the request normally regardless of value. A device that strictly enforces Unit ID silently drops the request (most common) or returns an exception. A gateway forwards to a nonexistent slave, resulting in a timeout on the serial side and a gateway path unavailable exception (0x0B) back to the client. Symptoms: no response, timeout, or exception 0x0B.

Is Unit ID the same as the IP address in Modbus TCP?

No. The IP address identifies the Modbus TCP endpoint (the direct device or the gateway) at the network level. The Unit ID identifies the target device within that endpoint — critical for gateways serving multiple slaves. A client connects to an IP address, then uses Unit ID to select which slave to address. In direct Modbus TCP scenarios where one IP equals one device, the Unit ID often becomes irrelevant.

Should I configure my Modbus TCP device’s Unit ID?

If the device offers a configurable Unit ID, set it deliberately and document your choice. Common practice: use Unit ID 1 unless you have a reason to use another value. Keep it consistent across similar devices in your plant to reduce commissioning errors. If the device does not offer a configurable Unit ID, work with whatever value it uses by default.