142 lines
5.7 KiB
Markdown
142 lines
5.7 KiB
Markdown
# 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"
|
|
}
|
|
}
|
|
|
|
|