Yes, right.

As a less important note, clients that use only namespace index (and not namespace URI) for node identification are doing it wrong. A node with namespace 3 may have namespace 15 next time. The namespace URIs stay the same, and the client should persist namespace URIs, and look up the namespace indexes every time it opens a session. QuickOPC is doing it. The fact that most servers do NOT change the namespace indexes makes it appear like everything is OK, but it isn't, and all these clients are broken and will not work well with servers that change their namespace indexes.

Best regards

opcfoundation.org/forum/opc-ua-standard/opc-ua-update-namespaceindex/

This has nothing to do with the server. What gets transferred to/from the server in the OPC UA protocol are *not* these strings, just their individual parts. The formats discussed here are all assembled/disassembled on the client side, by OPC clients.

So, the answer to your question

How can I know what is the format of the NodeId that the OPC UA server expects?

is: You cannot know that, because there is no such thing. The server does not know anything about these formats. It only knows that, for your example, that:
- The namespace index is 2
- the identifier type is String
- the identifier value is "Tag1".

These three pieces above are sent in an encoded way to the server, but *not* as 'ns=2;s=Tag1', and neither as 'NS2|String|Tag1'. They are sent piece by piece, and according to the message mapping used in UA (binary, XML or JSON), they will look differently on the wire, but never as any of these formats.

So, you really need to know what your *client* is using, if the client uses a string representation for node Ids. If you post here several examples of how the correct node Ids for your client look like, it should be relatively straightforward to come with a piece of code that formats the node Id in that way.

Regards

Hello.

Can you point me to the documentation that explains how to convert the nodeId object to a string?

Here: opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...ace.UANodeId~ExpandedText.html .

But you already have this string, so I do not understand why you are asking the question. The issue might be, that it is not in the format you want.

The other software is an OPC client that we develop. We thought that the nodeId string format is a standard that should be the same for all OPC clients.

You are probably not developing an OPC UA client from scratch. That would be man-months to man-years of work. I think you must be using some library. Which library is it? If it represents the node Ids by strings, what is the expected format?

And No, the node ID format does not have to be the same for all UA clients. The node IDs, as such, are the same. But node IDs are not the same as the string representations of node IDs, I have already repeatedly stated that.

Let me know what is the cost associated with explaining how to convert the nodeId object to string.

QuickOPC has its format that is documented, and it is also documented how to obtain it (see above), and you are already obtaining it, so there is no cost at all.

Converting QuickOPC node IDs to some other format would most likely be easy too, but it is necessary to know WHAT the format is.

Regards

Upgrade assurance contract is for version upgrades. It has nothing to do with support. We support everybody the same way, with the intent to be that to the best of our capabilities, but there is no paid, guaranteed support for anybody.

I will provide help to extract the necessary information from our node ID object. That is, in fact, trivial, and documented.

As to how to put that together to work with other software, in principle that has nothing to do with us. Frankly, I think it is actually trivial as well, as long as you know what is the format the other software (which you have not even identified to me) expects. If you describe that, I will try to help you as well, but it is well outside the normal support scope.

Regards

No.