How to Bridge OPC UA Data to an MQTT Broker

Back to Blog

Subscribe on the OPC UA Side With Deadbands

Start on the OPC UA side, because that is where you control how much data enters the bridge. Create a subscription with monitored items for the nodes you want to publish, and set deadbands so only meaningful changes come through. If you poll or subscribe with no deadband, the bridge will forward noise as MQTT traffic, and you have moved the inefficiency downstream rather than fixed it.

Set the sampling and publishing intervals deliberately here - the bridge publishes to MQTT at whatever rate the subscription delivers. The full method is in setting OPC UA sampling and publishing intervals. A clean, deadbanded OPC UA subscription is the foundation; everything the bridge sends is only as good as what this step lets through.

Map Each OPC UA Node to a Stable MQTT Topic

Decide the mapping from OPC UA nodes to MQTT topics deliberately, because these topics are what every downstream subscriber will use. Build the topic from stable identifiers in a broad-to-specific order so the fleet stays subscribable, rather than dumping the raw NodeId as a topic. A NodeId is meaningful to the OPC UA server but makes a poor, unstable MQTT topic.

Keep the mapping stable so a node that moves or is re-addressed on the OPC UA side does not silently change its MQTT topic and orphan subscribers. Design the topic tree with the same care as any fleet - see designing MQTT topics for an oilfield fleet. The mapping table between NodeId and topic is the heart of the bridge and deserves to be explicit and version-controlled.

Choose the Payload and QoS per Topic

Decide the MQTT payload format - a value with a timestamp and quality, at minimum, so downstream consumers know when the value was true and whether it is trustworthy. Carrying the OPC UA quality forward matters: a bridge that publishes a bad-quality value as if it were good corrupts the consumer. Preserve quality end to end - the OPC UA side of it is in the OPC quality code substatus.

Choose QoS per topic by consequence, exactly as for any telemetry: high-rate trend at QoS 0, values and alarms at QoS 1, non-idempotent commands crossing back the other way at QoS 2. The decision method is in choosing an MQTT QoS for telemetry. Do not default the whole bridge to one QoS; match each mapped topic to its data.

Publish Each Data Change and Handle Reconnects

Wire the bridge so each OPC UA data-change notification becomes an MQTT publish on the mapped topic. Because you deadbanded the subscription, these fire only on real change, and the broker sees efficient event-driven traffic. Set retain on the topics where a new subscriber should get the last value immediately, and leave it off where only live changes matter.

Handle both sides reconnecting independently. If the OPC UA session drops, the bridge should resubscribe and, ideally, republish current values so the MQTT side is not left stale. If the MQTT connection drops, the bridge needs a buffering strategy so OPC UA changes during the outage are not simply lost - covered in buffering MQTT telemetry through a cellular outage.

Verify the Bridge End to End

Change a value on the OPC UA server and confirm it appears on the correct MQTT topic with the right payload, timestamp, and quality, at the cadence your subscription set. Then hold the value still and confirm the topic goes quiet - if it keeps publishing, a deadband is missing and the bridge is forwarding noise. Both checks together prove the bridge is event-driven, not a polling firehose.

Test the failure paths: drop the OPC UA session and confirm the bridge recovers and republishes; drop the MQTT link and confirm buffered changes flush on recovery without loss. A bridge that only works when both sides are healthy is not field-ready. The one that survives both reconnections cleanly is the one to deploy.

Common Mistakes

The biggest mistake is bridging without deadbands, so the MQTT broker receives every sample as traffic and the OPC UA efficiency is thrown away. The second is using the raw NodeId as the MQTT topic, producing an unstable namespace that breaks the moment a node is re-addressed.

Another is dropping the OPC UA quality on the floor and publishing every value as good, which hides sensor faults from downstream. And do not ignore the reconnect paths: a bridge that loses OPC UA changes during an MQTT outage, or leaves MQTT stale during an OPC UA drop, silently corrupts the fleet view exactly when operators most need it.

Frequently Asked Questions