OPC UA to MQTT

The data flow

The OPC UA Client source node is one server. The gateway opens a session to its endpoint, reads each tag's variable on the poll interval, and hands the values to the route like any other source: a Double arrives as a number, a Boolean as a boolean, a String as text. A variable the server answers with a bad status is a tag with bad quality, never a stale number. From there the flow is the same as for a Modbus device: any output, any transform, any logic node.

It is the mirror of Modbus to OPC UA Server: that chapter makes the gateway a server for OPC UA clients; this one makes it a client of somebody else's server.

In the editor

• Host, port and endpoint path together make the endpoint URL, opc.tcp://10.0.0.20:4840/PumpHouse. Most servers have no path.
• Security mode None, Sign or SignAndEncrypt with a policy such as Basic256Sha256. Sign and SignAndEncrypt need the server to trust the gateway's certificate, placed on the device under the data directory as pki/opcua-client-cert.pem and pki/opcua-client-key.pem.
• User name signs the session in; empty is anonymous. The password is never in the design: on the device, modbuslogic-edge secrets set <device-id> password.
• Tags are node ids, ns=2;s=Pump.Speed or ns=3;i=1001, with the data type you expect. The OPC UA Explorer exports every variable of a server with its node id, so a tag list is a copy from its CSV.

Test it without a PLC

Any OPC UA server on your network will do, and two are close at hand. The OPC UA Explorer ships a mock server for development (npm run mock-server in its repository) that answers anonymously on opc.tcp://<pc>:4840/PumpHouse with a few moving variables. Or point the source at another gateway's OPC UA Server out: the two chapters together make a chain, Modbus into one gateway, OPC UA between them, MQTT out of the other.

From design to device

1. Validate. On the design page, Run validation. The editor's rules, the tag document and the runtime binary itself check the design; every issue names its node. Details: Validating a design.
2. Install. From the Devices panel download the installer for the device's platform (Windows x64, Linux x64 or Linux ARM64). Windows: extract and run Edge-Gateway-Console.exe from an administrator terminal. Linux (Debian, Ubuntu, Raspberry Pi OS): sudo dpkg -i the .deb, then sudo edge-gateway-console. It shows the device code. Details: Installing on the device.
3. Device code. Enter it in the Devices panel, choose a trial or one of your purchased licences, and press Download activation bundle: one small zip with the design and a licence bound to that machine, sealed so only that machine can open it. Details: Downloading.
4. Bundle. Give the zip to the console (drag it onto the program, pass its path, or put it beside the program and run it again; a USB stick is fine for a device without internet). It opens the bundle with its own code, installs the runtime as a service and starts it. The device never contacts the site. Details: Activation and the licence.

The console then opens the gateway's web view in a browser (on a device without a desktop it prints the address instead) and stays attached with the live view: devices up or down, values as they change, what was published, and the log.

• The live view shows the OPC UA server as connected and its tags' values changing at the poll rate.
• A wrong node id is refused at validation; a variable the server does not have reads as BAD with the server's status code in the log.

Ctrl-C leaves the gateway running as a service. Run edge-gateway-console again at any time: it shows the service, the licence, every device and destination with what to check, the web view, and the live log. Running covers the data directory, secrets and the diagnostics.