Modbus RTU

The modbus-rtu adapter bridges a Modbus RTU serial bus. It has two modes.

Master mode (default)

A full RTU ↔ TCP gateway. Incoming Modbus TCP (MBAP) requests have their MBAP header stripped, get a CRC appended, are sent on the RTU line, and the reply is validated and re-wrapped into MBAP for the client. Requests also arrive over MQTT and REST.

• One request in flight per port. Additional requests are queued and served in order — correct behavior for a shared RS-485 line.
• Internal poller — define modbus.polls[] and OmniBus polls an inverter/meter on its own schedule and emits the responses to MQTT/webhooks, with no external scheduler needed.
• Vendor templates — apply a starter config (register map / polls for a known device) with POST /api/ports/:path/apply-template {templateId}. List available templates with GET /api/templates/modbus.

Slave mode

OmniBus is the Modbus device: it exposes a configurable in-memory register map at a given slave id, addressable over RTU and Modbus TCP, and writable via REST/MQTT. Useful for emulating a device or exposing computed values to a SCADA master.

Outputs

Output	Behavior
TCP	The port's TCP server speaks Modbus TCP — connect any standard Modbus TCP master.
MQTT	See topics below.
REST	Synchronous request/response.
Webhooks	Fan out parsed responses.

MQTT

• publish <prefix>/response — JSON parsed response (registers / bits / exception).
• publish <prefix>/snoop — hex of every RTU frame seen on the wire.
• subscribe <prefix>/request — JSON request, e.g. {"unitId":1,"fc":3,"address":0,"quantity":10}.

REST

POST /api/ports/:path/rest/request
Authorization: Bearer <token>
Content-Type: application/json

{ "unitId": 1, "fc": 3, "address": 0, "quantity": 10 }

Returns the parsed response synchronously, or 504 if the bus times out.

Tips

• Match baud/parity to the bus exactly — Modbus RTU silence-based framing is sensitive to it.
• Use the internal poller for "set-and-forget" telemetry; use master-mode gateway for on-demand reads from an upstream master.