Modbus RTU — Inline coordinator + TCP tap

The modbus-inline adapter cuts Omnibus into an existing Modbus RTU master/slave bus so it passes traffic transparently — as though the line were still directly connected — and then exposes a Modbus/TCP tap so a second master can read status and send commands without colliding with the original master.

  [ existing master ] ──A── [port: master-facing]   [port: slave-facing] ──B── [ slaves ]
                                            └─────────── coordinator ───────────┘
                                                              ▲
                                                Modbus/TCP tap (2nd master)

Why this is safe (and why it needs two ports)

A shared RS-485 pair can only have one master. Adding a second talker to a live wire means detecting line-idle and arbitrating against collisions, which isn't reliable in software.

The inline coordinator avoids that entirely by being a true two-port cut-through:

• On segment B (the slaves) Omnibus is the only master. Every request — relayed from the real master or injected from a TCP client — is serialized onto one wire. No two talkers, so no collisions.
• On segment A (the master) Omnibus is the only thing the master talks to. It relays each request to B, gets the reply, and relays it back. The master never sees the injected traffic.

This requires two independent RS-485 ports — one wired to the master, one to the slaves. Both ports run this adapter with the same coordinator id and opposite roles.

Setup

1. Add two ports, both protocol Modbus RTU (inline coordinator + TCP tap), with matching serial settings (baud / parity / stop bits — it's one logical bus).
2. Give both the same coordinator id (e.g. inline-1).
3. Set one port's role to Master-facing, the other to Slave-facing.
4. Enable the TCP output on the port you want the second master to reach (typically the slave-facing port). Point any Modbus/TCP client at that port's TCP port.
5. Enable both ports. The panel's Coordinator link shows two green dots once both segments are attached — traffic only flows when both are up.

Read modes

Mode	Behavior
Shadow cache (default)	TCP reads are answered from a register cache built by observing the master's polls — zero added bus load. A read for a register the master has never polled falls through to a one-off live read.
Live passthrough	Every TCP read is forwarded onto segment B. Always ground-truth, at the cost of extra bus traffic and latency.

Writes from the TCP side are always queued onto the bus (a shadow can't apply a command for you).

Coordination tuning (slave-facing side)

• Inject gap (ms) — minimum quiet time on the master segment before an injected TCP request is allowed onto the bus. Higher protects the master's poll timing; lower gives the TCP side more throughput. The original master is always priority 0; injected requests are priority 1 and never delay a master transaction by more than one in-flight injected request.
• Reply timeout / Inter-frame — same RTU framing knobs as the standard Modbus adapter.
• Write arbitration — pass-through + audit (the only implemented policy) serializes both masters on the wire and emits a conflict event when both sides write the same register within the conflict window. Register-lock and source-priority policies are planned.

Outputs

Output	Behavior
TCP	The port's TCP server is the Modbus/TCP tap — connect a second master.
MQTT/Webhook	Emits a conflict event when the two masters write the same register within the conflict window.
REST	POST /api/ports/:path/rest/status returns live coordinator status (segments attached, queue depth, shadow size, transaction counters).

Operational cautions

• Fail-to-wire. Inline means Omnibus is now in series with a bus that used to be a direct wire. If it loses power or reboots, the master↔slave link is broken until it comes back. For a critical control bus, use an RS-485 bypass relay that reconnects the two segments on power loss, or accept a brief outage on restart.
• Latency. Omnibus stores-and-forwards each frame, adding roughly one frame-time (a few ms at 9600 baud) to every master transaction — well inside a typical master timeout, but worth confirming against a tight one.
• Not yet hardware-validated. The coordinator is covered by a hardware-free test harness; validate against a real bus (and confirm your master's timeout tolerates the added latency) before relying on it in production.