← All use cases

Modbus to MQTT

Convert Modbus registers into clean, reusable MQTT topics for analytics, applications and downstream operational systems.

Legacy register data, ready for modern event-driven systems.

OTDataMule polls only the registers you define, converts raw addresses into meaningful payloads and publishes them to an approved MQTT broker. Connection management, local buffering and controlled retries keep the data stream stable around real industrial constraints.

Modbus DevicesPLC · Meter · Drive
OTDataMulePoll · Decode · Buffer
MQTT BrokerTopics · Apps · Analytics
PROTOCOL PIPELINE

From Modbus registers to governed MQTT messages

OTDataMule polls approved register ranges, decodes device-specific values and publishes a stable topic and payload model. Persistent buffering protects the plant-facing collection cycle when the MQTT broker is unavailable.

1
PLC / RTU / MeterModbus TCP or Modbus RTU
40001Pressure40003–4Flow00017Run status
PollGrouped reads
2
Polling planUnit ID · function · address · interval · timeout
FC01 CoilsFC03 Holding RegistersFC04 Input RegistersRetry and stale limits
DecodeDevice profile
3
Scale and mapRaw registers become named engineering values
UINT16 / INT32 / FLOAT32ABCD · CDAB · BADC · DCBAScale × 0.1 · offset · unitsAsset and signal identity
QueuePersistent
4
Buffer and packageTimestamp · quality · sequence · JSON payload
{
  "asset": "pump-07",
  "pressure_bar": 6.4,
  "quality": "good"
}
PublishTLS · QoS
5
MQTT BrokerAuthenticated, encrypted client connection
Topicplant/area-a/pump-07/telemetry
QoS 0/1Retain policyClient certificate
Broker offlineModbus polling continues according to policy; approved messages remain in the disk-backed queue.
Broker restoredQueued messages publish in controlled order with source timestamps and quality intact.
Reference flow. Register maps, word order, polling rate, QoS and retained-message behaviour must be validated for each device and consuming application.
REGISTER MAPNever infer the device model

Confirm zero/one-based addressing, function codes, signedness, register width and vendor word order.

POLLINGRespect device capacity

Group adjacent registers, use realistic intervals and expose timeout or stale-state behaviour.

MQTT MODELDesign stable topics

Keep asset identity in the hierarchy and put measured values, source time and quality in a governed payload.

Poll successResponses, timeouts and exceptions
Stale valuesAge since last valid device update
Queue depthPending MQTT messages
Publish healthBroker session and delivery rate

A controlled path from register to topic.

01 — Select

Define register maps

Select function codes, addresses, data types and polling intervals for each device.

02 — Normalize

Decode and enrich

Convert raw registers, byte order and scaling into meaningful, contextual payloads.

03 — Protect

Buffer and retry

Queue records locally during interruptions and resume delivery without losing sequence.

04 — Store

Publish to MQTT

Publish to a deliberate topic hierarchy with the required QoS and retained-message policy.

Built for operational reality.

Meaningful payloads

Translate raw register values into named fields with units, timestamps and device context.

Protocol separation

Keep Modbus polling inside the industrial zone while exposing a controlled MQTT interface to consumers.

Disciplined polling

Tune scan rates, grouping and timeouts to respect device capacity and serial network limits.

Resilient delivery

Store-and-forward behavior reduces gaps when the IT destination is temporarily unreachable.

Reusable topic model

Give applications a stable topic and payload convention instead of device-specific register knowledge.

Observable flow

Monitor connection state, queue depth and publish outcomes to make data delivery measurable.

Typical deployment boundary

OT side

  • Explicit Modbus device and register allowlist
  • Polling intervals matched to process needs
  • Local queue sized for expected outages

IT / application side

  • Authenticated and encrypted MQTT where supported
  • Approved topic hierarchy, QoS and retention
  • Monitoring for latency and failed publishes

Validate the flow with your own devices.

Start with one device, one register map and one measurable outcome.

Discuss your Modbus to MQTT use case