# OPC-UA to MQTT Bridge

## Installation

* 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"
        }
    }