Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a way to resolve OPC-UA tags by name when the server only permits numeric identifiers #15001

Open
supergrover opened this issue Mar 15, 2024 · 6 comments
Labels
feature request Requests for new plugin and for new features to existing plugins

Comments

@supergrover
Copy link

supergrover commented Mar 15, 2024

Use Case

I would like to propose to implement a method to resolve and subscribe to OPC-UA nodes by BrowseName when the server only permits numeric identifiers.

Issues may arise when using numeric identifiers and the OPC-UA server configuration changes. The server-side identifiers may change and if the configuration on the client side is not changed accordingly, the wrong tags may be logged. Some OPC-UA servers will only respond to numeric identifiers so the setup may become fragile.

Expected behavior

The capacity to add a tag by browseable and have the server resolve it to a numeric identifier on establishing connection by using the BrowseName node attributes.

This may be done by adding a new identifier_type in the config, such as r (to be determined), which will make the server first resolve the tag symbolically using the BrowseName attributes of the server nodes after the connection is established.
Example:
{name="Some.Hierarchical.Tag", namespace="1", identifier_type="r", identifier="Interface:Some.Hierarchical.Identifier"},

Actual behavior

The OPC-UA client can only use the default OPC-UA identifier types (string, numeric, guid, opaque). The capacity to resolve a numeric identifier by using the BrowseName fields is non-existing.

Additional info

I'm currently experiencing this issue with a Siemens S7-1200 right now which has this issue.
I've started working on a proof of concept for this implementation myself because this problem repeatedly breaks my setup. Because I'm not very well versed in OPC-UA, Telegraf and have only a little experience Go, and this is pretty much my first open-source contribution, I could use some guidance in this.

@supergrover supergrover added the feature request Requests for new plugin and for new features to existing plugins label Mar 15, 2024
@srebhan
Copy link
Contributor

srebhan commented Mar 15, 2024

@supergrover thanks for bringing this up. Your argumentation totally makes sense and I appreciate your effort in implementing this feature. My suggestion is to try to get a working proof-of-concept that does what you need and then post this as a pull-request. We can then suggestion improvements etc and get the code to a mergeable state in some pull-request-update iterations... There is no reason to hold back rough code, we have all been there. :-)

What do you think?

@supergrover
Copy link
Author

supergrover commented Mar 19, 2024

@srebhan Great, I'll continue working on it and report back when I've got something working.
What do you think would be the preferred way to configure the tag in this way? My suggestion is to define a new identifier_type, r for resolve using the OPC browse functionality , but the current identifier_type values (s, i, g, b) map to OPC-UA identifier types which are directly passed on to the OPC server. Any opinions on this?

@srebhan
Copy link
Contributor

srebhan commented Mar 21, 2024

Maybe explicitly add a resolve flag? It's better than introducing some abbreviations that look like being part of the standard but are not...

@supergrover
Copy link
Author

supergrover commented Mar 24, 2024

I've got something working in https://github.com/supergrover/telegraf/tree/feature/opcua-browse

I've added the browse flag for identifiers which need to be browsed as suggested. The format for the identifier is now closer to OPC UA browse paths "3:Folder/4:Object.Member.Field" as defined by the OPC UA standard.

I'm now working on the tests. Because I can only fully set all NodeIDs with a connected server in order to browse the tags if necessary, a lot of tests fail because they depend on the NodeID to be valid for the test. Before this change the NodeID could just be computed from the identifier_type and identifier. Now I'm stuck, because this would pretty much mean all tests become integration tests.

I'll keep working on the tests and see what I need to change to get them to run again.

@srebhan
Copy link
Contributor

srebhan commented Mar 26, 2024

@supergrover please create a pull-request out of this so I can take a look and suggest changes!

@supergrover
Copy link
Author

@srebhan see #15064

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Requests for new plugin and for new features to existing plugins
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants