Opaque OPC UA NodeIds: why you don't type them by hand
OPC UA documentation always gives the same NodeId example:
ns=2;s=Temperature. A namespace index, a readable text identifier. On
that basis, it's tempting to treat the NodeId as a simple string to type
once you know the variable's name on the PLC side.
That works, until the day the server returns something else:
ns=2;b=AQAAAAQAAABudW1iZXI=
Why some identifiers are unreadable
OPC UA allows several identifier types for the same node: a string
(s=), a numeric integer (i=), a GUID (g=), or an encoded byte
sequence (b=). The standard doesn't force any server to pick the
readable form.
In a real test against a CODESYS PLC (Control Win V3, local OPC UA server), a good share of the application variables exposed their NodeId in this last, opaque form. Nothing in the variable's name on the program side let you reconstruct the string: the identifier is generated by the server, not by the PLC's developer.
Faced with this format, typing a NodeId by hand isn't a slow option anymore. It's an impossible one: there's nothing to type, the identifier has no readable equivalent a human could work out.
The one method that works every time
An OPC UA client (UaExpert is the most common for this) never asks the
user to know a NodeId in advance. It connects to the server, then browses
its namespace starting from the root node (ObjectsFolder), folder by
folder, down to the variables. The actual NodeId, readable or opaque,
then shows up in the tool: there's nothing left to guess, only to read.
This method works for an s= NodeId the same as for a b= NodeId,
because it never depends on the identifier's format. It's the only
approach that works every single time, not just when the server happens
to pick the readable form.
What you find in practice: a lot of noise, little signal
An OPC UA namespace doesn't just hold application variables. It also carries the protocol's entire standard structure: information about the server, its capabilities, its declared namespaces.
In that same real test, a full browse of the server surfaced 51 nodes. 47
of them belonged to that standard structure
(Server/ServerCapabilities, Server/Namespaces, Server/ServerStatus)
and exist identically on any OPC UA server, whatever PLC sits behind it.
Only 3 nodes corresponded to actual application variables: a
temperature, a pressure, a fault code.
Finding those 3 variables in a flat table of 51 rows is tedious and error-prone. Filtering out the server's standard branch before showing the result makes a real difference in the time spent configuring a point.
How Nodal automates this browse
The principle stays the same as UaExpert's, built directly into the
screen for adding an OPC UA device: entering the server's IP and port is
enough. The gateway connects, browses the namespace, filters out the
standard structure nodes (the Server node, well-known NodeId
ns=0;i=2253, and its descendants), and shows the result as an
expandable tree. A folder can be checked entirely, or partially if only
part of its contents matters.
Two points are worth spelling out, since they aren't visible on screen:
- The scan runs from the gateway, not from the cloud. An OPC UA server lives on the client's private network, which the cloud can't reach directly: it's the gateway that runs the browse and forwards the result.
- Typing a NodeId manually is still possible alongside this. For a server that exposes readable, already-known identifiers, typing the string directly stays faster than browsing the tree.
The scan isn't a convenience alternative to manual entry, then. For an opaque NodeId, it's the only path that works.
Frequently asked questions
- What is an opaque NodeId in OPC UA?
- An OPC UA NodeId identifies a node in a server's address space. The most documented format is a readable string (ns=2;s=Temperature), but some servers, CODESYS in particular, also use an encoded binary identifier (ns=2;b=...), impossible to guess or type by hand.
- How do you browse the OPC UA namespace with UaExpert?
- UaExpert connects to the server and then displays a tree starting from the ObjectsFolder node. Each folder can be expanded to reveal its variables, with their actual NodeId and live value. The method stays the same regardless of the NodeId's format, readable or opaque.
Dayen Driss
CEO, Nodal
Founder of Nodal, where he builds the Edge gateway and the cloud platform.