New binding: OPC UA client

It would be nice to implement OPC A Client in OpenHAB - e.g. ability to connect to OPC UA Server.
This quite well supported modern communication protocol, used in automation PLCs, which are getting more and more used in home automation. OPC UA supported by many leading PLC vendors like Beckhof, Wago, Siemens, Codesys-based etc.
Previously only Modbus TCP could be used to communicate with those, but this 20 years old protocol is quite obsolete for IoT use - e.g. it is not so easy to configure, requires polling, limited data types etc. OPC UA can replace Modbus TCP in such cases easily.

There is OPC UA open-source client implementation available -
https://www.npmjs.com/package/node-opcua

2 Likes

I am far (and I mean really far) from being an expert on Node.js, but I wonder if it is really appropriate to use this in the context of an openHAB binding?

The following link seems to be a really good place to start in terms of open-source and OPC UA:

open62541

This implementation, however, is in C. This could maybe be used through the means of JNI, but again; I am not sure if this is appropriate for a binding.

The following link gives various alternatives:

List of Open Source OPC UA Implementations

The one that “sticks out” is opc-ua-sdk with its ua-client-sdk implented in pure Java.

I am not sure about the license, though:

The digitalpetri OPC-UA Client SDK is licensed under the GNU Affero General Public License v3 (AGPL-3.0).
Commercial-friendly licensing may be purchased.

Anyone?

@Artyom_Syomushkin, I’m with you! :slight_smile:

OPC UA Client in OpenHAB would be very useful!

For PLC eventually this BACNet Binding can help for now:

Now I’m thinking about MQTT. Bechhof PLCs already support it, so other SoftPLCs should come soon

This would be wonderful … But I see that the post is very old and after years it is still not there … No news / novelty?

What PLC do you have/like to connect?

I do not understand, I thought that the protocol was indifferent to the PLC.

Greetings

I think it‘s not so actual, as PLCs got support for MQTT, which is quite easy to get working with HA systems.

It is quite relevant as MQTT does not get you even close to what you in theory could do with OPC UA. Not that I am a big fan of it, but lets face the truth, you can’t do much with MQTT without getting burred into fairly complex configuration management. You have to decide how to name topics, what structures you send and how you command other end. All this is granted for UA plus support for grouping and discovery of symbols held by PLC. Surely you can do it with conventions such homie and sparkplug but this requires the PLC program author to follow these specs. I can guarantee you that most of them will not bother about these unless there is ready to use library which makes integration for them easier. Even if such library would existed, quite often it could involve extra licensing fees. Auite a lot libraries bought from PLC manufacturers require to pay extra for IP based communications.
Personally, speaking about single PLC installation, if I’d have to choice to pay 50€ for OPC UA license or no fee for MQTT I’d pick earlier one and save on labor costs. If you’d ask me same question about 50 or more devices then I’d start considering MQTT only if these 50 devices would rely on the same program.

@davidtorres I have a plan to put a proof of concept binding within coming weeks. Stay tuned.

1 Like

Well, I found that MQTT event bus binding does this job quite well, so that you get already quite structurized naming conventions for topics and a list of all your things, which you can directly use in PLC. That’s why I was so upset, when this became a low priority topic for developers migrating to OH 2.X.

Anyway I agree that OPC UA might be an interesting topic, so pls go on with PoC.

I’ll be up to date :eyes:, thank you very much.

As long as OPC UA is not available as binding you can use Node-Red as gateway between openhab and OPC UA using the OPC UA and openhab contribution to connect OPC UA tag to openhab items and vice versa.