Direct answer

Poll Modbus locally at the edge, decode registers through a versioned device map, attach source time and quality, and publish normalized telemetry or events to MQTT. Keep raw register provenance available for diagnosis. Do not map every poll directly to one MQTT message, and do not route remote writes from a generic MQTT subscription into Modbus without command identity, authorization, interlocks, and outcome acknowledgement.

Scope and non-scope

This pattern integrates register-oriented field devices with an asynchronous messaging platform. It does not turn Modbus into an event protocol or make MQTT safe for physical control by itself. The gateway owns polling schedules, decoding, local buffering, quality classification, and the boundary between observation and control.

Build a device map

For each supported model and firmware range, version a map containing unit ID, function, address base, register count, data type, byte and word order, scale, engineering unit, valid range, polling class, and write policy. Address bases in documentation often differ from zero-based protocol addresses; encode the resolved protocol address rather than relying on operator memory.

Group contiguous registers when the device supports it, but do not cross undocumented boundaries or exceed its response limits. Give fast control-relevant values and slow diagnostics separate schedules. Add jitter across devices so gateways do not produce synchronized bursts.

Preserve quality and time

A successful TCP exchange does not guarantee a meaningful measurement. Distinguish good, stale, timeout, protocol exception, decode error, out-of-range, and substituted values. Carry the original sampling or polling time, gateway receive time, device and map version, and sequence. If the device lacks a clock, say that the gateway time is an observation time rather than device event time.

Publish changes, bounded batches, or periodic snapshots according to consumer needs. Avoid a message per unchanged register per poll. Retain current state only on branches whose semantics are explicitly current state; send alarms and transitions as durable events with identifiers.

Edge workflow

  1. Identify the device and select an exact compatible map.
  2. Schedule bounded requests with per-device timeout, retry, and circuit-breaker policy.
  3. Decode only complete responses and attach quality to every output.
  4. Apply range and cross-field validation without silently clamping source data.
  5. Normalize names and units into a versioned MQTT payload.
  6. Buffer durable events locally with byte and age limits.
  7. Publish through least-privilege topics and preserve sequence across reconnect.
  8. Expose poll latency, exceptions, stale age, decode failures, queue depth, and MQTT acknowledgements.

Control writes

Separate the read pipeline from commands. A command needs authenticated origin, target, requested value, validity window, idempotency ID, safety preconditions, and an allowed register/function policy. The gateway validates current state, performs the write, reads back where meaningful, and publishes an acknowledgement plus observed outcome. Never interpret repeated MQTT delivery as permission to repeat a physical action.

Failure modes

Wrong word order can produce a believable floating-point value. A retry after an uncertain write can duplicate an action. Rapid timeouts against one failing device can block polling for an entire serial bus. A gateway clock jump can reorder events. Publishing “zero” on timeout destroys the difference between a real zero and missing data. Map drift after firmware upgrade can corrupt every downstream calculation without a transport error.

Implementation checklist

  • Maps are versioned by model and compatible firmware.
  • Address base, type, word order, scale, units, and range are explicit.
  • Polling is grouped, jittered, bounded, and load-tested.
  • Payloads preserve device, source time, gateway time, quality, and map version.
  • Missing data is never silently converted to zero.
  • Local buffers have count, byte, and age limits.
  • Writes use a separate authorized, idempotent command workflow.
  • Metrics expose field, decode, buffer, and MQTT failures separately.

Validation evidence

Bench-test every map with known low, high, negative, and boundary values. Preserve raw request and response bytes beside normalized output so a future engineer can distinguish field behavior from decoding behavior. Simulate protocol exceptions, partial serial responses, CRC errors, TCP reconnect, device reboot, and a firmware version that no longer matches the map. Confirm that quality becomes bad or unknown instead of publishing a plausible default.

For write-capable gateways, test duplicate MQTT delivery, timeout after the device applied a write, lost read-back, expired command, and changed safety precondition. Keep a command audit linking authenticated requester, gateway decision, raw Modbus operation, response, observed result, and acknowledgement. Review poll load at the slowest supported controller and largest shared bus; a reliable laboratory device alone does not establish fleet-safe timing.

Primary sources

The Modbus specifications directory provides the Application Protocol Specification that defines functions, exceptions, and protocol data units. The OASIS MQTT 5.0 specification defines publish delivery, sessions, and expiry. Device register maps and electrical/serial constraints must come from the exact manufacturer’s official documentation.