Exception 0B (0x0B) — Gateway Target Device Failed To Respond

Returned by a gateway, not by the end device: the gateway is alive and understood the request, but the target behind it did not answer. Exception 0A is the sibling — the gateway could not find a path at all.

Start free Modbus → canonical

Diagnosis

When you hit this

A serial slave behind a TCP-to-RTU gateway is powered down, unplugged, or set to the wrong unit ID.
Baud rate, parity, or stop-bit mismatch between the gateway and the serial device.
Bus termination or wiring problems on a long RS-485 run, so responses are corrupted rather than absent.

Resolution

How to fix it

Confirm you are talking to a gateway
0A and 0B can only come from a gateway. Their presence tells you the topology has a hop you may not have accounted for.
Check serial settings on both sides
Baud, parity, data bits, and stop bits must match exactly. A parity mismatch yields intermittent 0B rather than a clean failure.
Verify the unit ID
The gateway maps unit ID to a serial address. An unmapped ID gives 0A; a mapped but silent device gives 0B.

Normalization

What Forge does about it

This is a transport failure, so there is nothing for Forge to normalize: the reading never arrives. What Forge does is refuse to let the gap look like good data. The read-time dropout check flags a field that fell to zero and recovered as a communication glitch rather than a real measurement, and the stuck-sensor check fires when a value repeats for 20 consecutive readings — which is what a cached or last-known value looks like after a link drops. Forge does not retry or reconnect for you; that is your client's or your gateway's job.