Connect OPC UA to Mosquitto / MQTT broker

Before you start

• Something that actually speaks OPC UA: a publisher, a collector or a gateway. The broker is a destination, not a client, and no broker configuration will make a PLC publish.
• A decision about payload format before the first topic exists. OPC UA PubSub over MQTT with JSON is the standards-based route; a collector's own JSON shape and Sparkplug B are the common alternatives, and they are not interchangeable.
• A topic naming convention agreed with whoever will consume it, because the topic tree is the contract and renaming it later breaks every subscriber at once.
• TLS with real certificates and authentication configured before anything production publishes. An open broker on a plant network is an open plant.

Setting it up

1. Configure the broker for TLS and authentication firstSet an explicit listener, disable anonymous access, configure credentials or client certificates, and add topic access control per client. Doing this before any publisher exists is much easier than retrofitting it across a fleet of publishers later.
2. Design the topic hierarchy from the plant, not from the address spaceA topic tree derived mechanically from OPC UA browse paths is convenient and produces topics nobody can subscribe to usefully. Derive it from site, area, line and machine, then place the signal name at the leaf. Where a publisher does offer automatic routing from browse names, know that MQTT reserved characters have to be escaped, and check what the publisher does with them.
3. Choose and pin the payload encodingIf you use OPC UA PubSub over MQTT, decide between UADP and JSON, and if JSON, between reversible and non-reversible forms. Non-reversible JSON loses type information and cannot be round-tripped, which is a surprise that arrives months later in a downstream consumer.
4. Decide retained messages and last will per topic classRetained messages give a new subscriber the current value immediately, which is right for state and identity and wrong for events, where a retained message replays something that already happened. Configure a last-will topic per publisher so a dropped collector is visible.
5. Set quality of service to match the data's meaningQuality of service 0 is fine for a high-rate analog you will resample anyway and unacceptable for a downtime event or a count increment, because a network blip simply loses it. Use at-least-once for anything a calculation depends on and make consumers idempotent.
6. Verify the payload with a client before building consumersSubscribe with MQTT Explorer or a command-line client and read the actual bytes on the wire. Note in particular that in the OPC UA JSON encoding a Good status is the zero value and is omitted, so a missing status field means good, not missing data.
7. Monitor the broker and the publishers separatelyWatch broker connection counts and dropped messages, and alert on publisher liveness through last-will topics or a heartbeat topic per machine. Silence on a topic is ambiguous and needs an independent signal to interpret.

What the address space looks like

MQTT has no model, only a topic string and a payload, so everything the OPC UA address space knew has to be re-expressed by whatever publishes. That is the central design decision of a unified namespace: the topic hierarchy plus the payload schema is the entire information model as far as every consumer is concerned. OPC UA PubSub carries dataset metadata alongside the data, which preserves types and field names and is why the standards-based path is worth the extra configuration; an ad hoc collector's JSON usually does not, and then the meaning of a field lives in a document somewhere. Whichever you choose, publish the OPC UA namespace URI and node identifier in the payload or in the topic metadata, so a value can be traced back to the node it came from.

The traps

• Treating the broker as the integration is the classic mistake. The broker moves bytes; the semantics come from the publisher's topic and payload design, and that design is where the project's real work is.
• Quality of service 0 on event-like data silently loses events during exactly the network conditions that produce the most interesting events. Downtime records and count increments need at-least-once delivery.
• Retained messages on event topics replay stale events to every new subscriber, which corrupts consumers that assume a message means now.
• Non-reversible JSON encoding loses type information and cannot be round-tripped. Choose deliberately and record the choice; discovering it downstream is expensive.
• In OPC UA JSON encoding a Good status is zero and is omitted, so a consumer that treats a missing status field as missing data will discard good values.
• Topic trees derived automatically from browse paths encode the PLC's internal structure into your plant-wide namespace, and they change when the PLC program changes.
• The broker becomes a plant-wide single point of failure and a plant-wide security boundary. Cluster or accept the risk explicitly, and never leave anonymous access enabled because it was convenient during commissioning.
• MQTT gives no ordering guarantee across different topics. A state change and the count that belongs with it can arrive out of order if they are published on separate topics, so put facts that must be consistent in one message.

Getting OEE data out of it

The broker contributes nothing to OEE by itself and can quietly damage it. What it does well is decouple collection from calculation, so an analytics platform can consume machine state, counts and reasons without holding sessions against every PLC. The requirements it imposes are concrete: publish state transitions as events with the machine's own timestamp in the payload rather than relying on arrival time, publish count increments or absolute counters with enough context to detect resets, use at-least-once delivery for both, and give every machine a heartbeat or last-will topic so that silence can be distinguished from a stopped machine. Planned production time, shift calendars, order context and standard cycle times are not machine data and should reach the calculation from MES or ERP, not by being hand-published onto a topic and forgotten.

Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.