How to Fix Duplicate Telemetry in an OPC UA to MQTT Bridge

Back to Blog

First Checks

Characterize the duplicates before chasing them. Do they cluster right after a reconnect on either side, or occur steadily during normal running? Reconnect-clustered duplicates and steady duplicates have different causes, so this one observation splits the problem in half. Add a payload sequence number or compare timestamps so you can tell a true duplicate from two legitimately close values.

Confirm whether the duplicated messages are byte-for-byte identical or merely close in value. Identical content pattern points at a redelivery or republish; slightly different values point at the same node being sampled by two paths. That distinction, cheap to make, decides which of the causes below applies.

Fix Reconnect Republish Duplicates

A common bridge design republishes current values after an OPC UA or MQTT reconnect to refresh downstream state. Helpful in principle, it produces a duplicate if the same value was also delivered normally just before or after. If your duplicates cluster around reconnects, this republish-on-recovery behavior is the likely cause. The test is to correlate duplicate timestamps against the bridge's reconnect events.

Fix it by making the republish idempotent from the consumer's view - carry the source timestamp so a consumer can recognize a republished value as the same value it already has, rather than a new event. A consumer that keys on source timestamp naturally de-duplicates a republish. The reconnection design that drives this is part of building the bridge well, in bridging OPC UA data to an MQTT broker.

Account for QoS 1 At-Least-Once Redelivery

If the bridge publishes to MQTT at QoS 1, the protocol itself can deliver the same message twice - that is the meaning of at-least-once. A publish whose acknowledgement is lost on a flaky link is retried, and the consumer sees it twice with identical content. This is not a bug; it is the guarantee working as designed, and the consumer is responsible for tolerating it.

The fix is de-duplication at the consumer, keyed on a message identifier or the source timestamp, not lowering the QoS if you need the delivery guarantee. The behavior in detail is in MQTT QoS 1 duplicate delivery. If duplicates are byte-identical and occur on a marginal link, this is very likely your cause, and the consumer must handle it.

Find a Node Monitored Twice

Steady duplicates during normal running, with slightly different content, often mean the same OPC UA node is being monitored by two subscriptions or two bridge instances, each publishing to the same MQTT topic. Two bridges pointed at one server, or one bridge with an accidentally duplicated monitored item, both do this. The test is to trace how many paths lead to the offending topic.

The fix is to ensure exactly one monitored item, in one bridge, maps to each MQTT topic. If you run redundant bridges for availability, they must coordinate so only one publishes at a time, or they will duplicate everything. Understanding the subscription objects helps you spot a double-subscribe - see OPC UA subscriptions and monitored items.

When to Escalate

If duplicates persist after ruling out republish, QoS 1 redelivery, and double-monitoring, look at the broker fabric. A bridged or clustered broker can duplicate messages across nodes independently of your bridge, and no bridge-side change will fix that. Escalate to the broker owner with evidence that a single bridge path produces single publishes yet the consumer still sees two.

Provide the duplicated payloads, their timestamps, the QoS in use, and whether the duplication correlates with reconnects. Precise evidence that the bridge side emits one message per change is what turns a broker investigation from a guess into a targeted fix.

Common Mistakes

The main mistake is treating every duplicate as a defect to eliminate at the source when QoS 1 duplicates are an accepted part of at-least-once delivery that the consumer must handle. The second is a consumer that stamps arrival time and so cannot recognize a republished value as the same one, turning a benign refresh into a phantom event.

Another is running two bridges against one server without coordination, duplicating the entire stream. And do not lower QoS to kill duplicates if you needed the delivery guarantee - you would trade duplicates for lost data. De-duplicate at the consumer on a stable key instead.

Frequently Asked Questions