CODESYS MQTT: IIoT Library Client, Not a Fieldbus Driver

Follow the packet. A CODESYS runtime that publishes to MQTT is acting as an ordinary TCP client: the application task calls a function block, the block hands a CONNECT packet to the controller's socket layer, that packet leaves on the Ethernet port and terminates at a broker process listening on a port somewhere else on the network. Nothing in the fieldbus configuration tree participates. If the library is not installed, the runtime has no MQTT capability at all, and no amount of IP configuration will produce a publish.

That distinction drives the whole commissioning order below: prove the transport, prove the broker, then add the PLC last.

Which hops carry an MQTT publish, and where does it stop?

Five hops, and the failure is almost always at the first three:

Default ports, so you know what to open and what to sniff:

Check: from an engineering PC on the same subnet as the controller, open a TCP connection to the broker port. A refused connection is a broker or firewall problem; a timeout is a routing or physical problem. Resolve that before touching CODESYS.

How do I prove the broker works without a PLC?

You do not need a controller to learn or to validate the protocol. Install Mosquitto on a laptop or a small Linux host and drive it with its own command-line clients. Two terminals give you a complete publish/subscribe path in under a minute.

# terminal 1 - subscriber, wildcard on everything
mosquitto_sub -h 127.0.0.1 -p 1883 -t '#' -v

# terminal 2 - publisher
mosquitto_pub -h 127.0.0.1 -p 1883 -t 'plant/line3/cell1/temp' -m '{"t":72.4}'

Two configuration facts trip up nearly every first install. Mosquitto 2.x binds its default listener to localhost only, and it rejects anonymous clients unless told otherwise. A PLC on the network will therefore get connection refused against an otherwise healthy broker. For bench commissioning, declare an explicit listener and re-test from a second machine:

listener 1883 0.0.0.0
allow_anonymous true

Move to a password file or TLS before the broker leaves the bench. Check: run mosquitto_sub from a different host than the broker and confirm messages arrive. Until a remote subscriber sees traffic, the PLC will not either.

What gives the CODESYS runtime an MQTT client?

Bare CODESYS has no MQTT stack. You add one of three things:

Install the package, then add the library in the Library Manager of the application, not the device. After a package install CODESYS must be restarted before the library appears in the repository.

Check: the library resolves in the Library Manager with no yellow warning triangle, and the project compiles clean with an instance of the client FB declared. An unresolved library compiles into a runtime that silently never connects.

How do I get the first CONNECT out of the controller?

Instantiate the client block, call it every cycle from a task, and watch its status outputs. Do not gate the call behind a rising edge — the client needs cyclic execution to service keepalive and to reconnect.

The client ID must be unique. Two clients sharing an ID cause the broker to disconnect the older session on every new CONNECT, producing a connect/disconnect loop that looks like a network fault. Copying a project to a second controller without editing the ID is the most common way to create it.

Check: with mosquitto_sub -t '#' -v running, force the client online and watch for the topic. In parallel, the broker log records the CONNECT with the client ID — that line is the proof that the session reached layer 5, not just layer 4.

How do I build JSON payloads without burning scan time?

MQTT carries an opaque byte payload, and in practice that payload is JSON — text. String assembly is the work a PLC is worst at, and the packaging overhead per message is real. Three rules keep it bounded:

1. Batch related tags into one payload with one timestamp. One topic per machine cell beats one topic per tag for both broker load and subscriber logic.
2. Keep keys short. {"t":72.4,"st":1} costs a fraction of a verbose schema, and the difference is multiplied by every message on the bus.

Where the controller is already loaded, or the payload schema changes often, put the MQTT client outside the PLC: expose the data over a protocol the PLC does well and let Node-RED or a Python service do the JSON assembly, retry logic, and TLS. That gateway is also far easier to redeploy than a PLC application.

Pick QoS deliberately — it changes packet count on the wire:

Check: subscribe and confirm the message rate matches your intended publish rate, not the task rate.

End-to-end verification

Work the path once more, in order, with the machine running:

1. Subscribe with mosquitto_sub -h <broker> -t '#' -v from a third host — not the broker, not the PLC.
2. Confirm every expected topic appears and the JSON parses. Pipe through a JSON parser; a truncated payload from an undersized string buffer parses as an error, not as a short value.
3. Set a Last Will and Testament on the client, then pull the controller's Ethernet cable. The LWT topic must appear at the subscriber within the keepalive timeout — that is the only proof your consumers can detect a dead PLC.
4. Reconnect the cable and confirm the client re-establishes on its own, with no PLC restart and no duplicate-ID churn in the broker log.
5. Publish retained values for slow-changing setpoints, then start a fresh subscriber and confirm it receives current state immediately instead of waiting for the next change.

Step 3 is the one that gets skipped and the one that matters at 03:00, when a SCADA screen is showing a stale value from a controller that dropped off the network an hour earlier.

FAQ