Take the tarball from the Release area and unpack it in the desired location on the edge device
The systemctl service script assumes to find the application at /home/alarm/KROHNE/opcua2mqtt-bridge, so it is a good idea to put it there
Create a configuration directory /etc/opcua2mqtt-bridge and place the adjusted config.json into it
Enable the service using sudo systemctl enable /home/alarm/KROHNE/opcua2mqtt-bridge/opcua2mqtt-bridge.service
Start the service using sudo systemctl start opcua2mqtt-bridge
Check the log messages using journalctl -f

Configuration

{
    "mqtt": {
        "broker": "172.16.2.16",
        "port": 1883,
        "publishTopicPrefix": "opcua"
    },
    "stats": {
        "topic": "statistics",
        "period": 60
    },
    "opcua": [
        {
            "enabled": "true",
            "type": "flat",
            "url": "opc.tcp://172.16.3.60:4840",
            "name": "apl",
            "period": 1.0,
            "timeout": 1.0,
            "nodes": [
                { "ns": 0, "n": "i=345", "d": "pv" },
                { "ns": 0, "n": "i=348", "d": "sv" },
                { "ns": 0, "n": "i=351", "d": "tv" },
                { "ns": 0, "n": "i=354", "d": "qv" }
            ]
        }
    ]
}

The configuration object consists of three parts: mqtt, stats and opcua.

In mqtt the access to the broker is configuration and the prefix for the topics used by the statistics module and the actual bridge are defined. Besides the above shown attributes the login and password for authentication at the broker and ca, cert and key for TLS connections to the broker are available. ca, cert and key contain the filenames including complete path of the particular files.

In stats the topic suffix and the period of statistics messages are defined. The complete suffix will be ${mqtt.publicTopicPrefix}/${stats.topic}.

The section opcua contains a list of OPC-UA servers to be queried. Each entry can be enabled/disabled using the attribute enabled. The attribute url obviously has the URL to connect the server, period is the period to repeat queries and timeout is the timeout when talking to a server. name identifies the particular server, it becomes part of the topic of the published MQTT messages. The attribute type defines whether the individual variables of an OPC-UA server shall be communicated in individual MQTT messages (flat) or all variables of a server in a single message (structured).

The attribute nodes finally contains the list of variables to be queried. It contains the namespace index (ns), the node-id (n) and an optional descriptive name (d). Namespace index and node-id can be determined using for instance UAExpert when browsing the server and navigating to the relevant variables. The descriptive name - if given, otherwise the display name of the variable is used - becomes in flat mode part of the topic, in structured mode it becomes an attribute name within the message.

Example Output

Besides the value itself the output contains the status of the value and a couple of timestamps (from device t1, server t2 and bridge t3).

In flat mode the final topic will be ${mqtt.publicTopicPrefix}/${opcua.name}/${opcua.node.ns}/${opcua.node.d}

An example for the MQTT messages according to the above configuration in flat mode is:

opcua/apl/0/pv {
    "server": "apl", 
    "ns": 0, 
    "d": "pv", 
    "value": 19.833280563354492, 
    "status": "Good", 
    "t1": "2022-02-22 17:03:41.189000", 
    "t2": "2022-02-22 17:03:41.189000", 
    "t3": "2022-02-22 17:03:41.575504"
}
opcua/apl/0/sv {
    "server": "apl", 
    "ns": 0, 
    "d": "sv", 
    "value": 1706.15771484375, 
    "status": "Good", 
    "t1": "2022-02-22 17:03:41.189000", 
    "t2": "2022-02-22 17:03:41.189000", 
    "t3": "2022-02-22 17:03:41.625721"
}
opcua/apl/0/tv {
    "server": "apl", 
    "ns": 0, 
    "d": "tv", 
    "value": 23.29559326171875, 
    "status": "Good", 
    "t1": "2022-02-22 17:03:41.189000", 
    "t2": "2022-02-22 17:03:41.189000", 
    "t3": "2022-02-22 17:03:41.675352"
}
opcua/apl/0/qv {
    "server": "apl", 
    "ns": 0, 
    "d": "qv", 
    "value": NaN, 
    "status": "Good", 
    "t1": "2022-02-22 17:03:41.189000", 
    "t2": "2022-02-22 17:03:41.189000", 
    "t3": "2022-02-22 17:03:41.725487"
}

In structured mode the final topic will be ${mqtt.publicTopicPrefix}/${opcua.name}

An example for the MQTT messages according to the above configuration in flat mode is:

opcua/apl {
    "pv": {
        "value": 19.835201263427734, 
        "status": "Good", 
        "t1": "2022-02-22 16:58:21.188000", 
        "t2": "2022-02-22 16:58:21.188000", 
        "t3": "2022-02-22 16:58:22.071619"
    }, 
    "sv": {
        "value": 1704.4019775390625, 
        "status": "Good", 
        "t1": "2022-02-22 16:58:21.188000", 
        "t2": "2022-02-22 16:58:21.188000", 
        "t3": "2022-02-22 16:58:22.121559"
    }, 
    "tv": {
        "value": 23.08197021484375, 
        "status": "Good", 
        "t1": "2022-02-22 16:58:21.188000", 
        "t2": "2022-02-22 16:58:21.188000", 
        "t3": "2022-02-22 16:58:22.171498"
    }, 
    "qv": {
        "value": NaN, 
        "status": "Good", 
        "t1": "2022-02-22 16:58:21.188000", 
        "t2": "2022-02-22 16:58:21.188000", 
        "t3": "2022-02-22 16:58:22.221639"
    }
}