What about the reverse? When a MonitoredDataItemListener generates a onDataChange(MonitoredDataItem sender, DataValue prevValue, DataValue value) call, how can I get the BrowsePath of the changed item?

The node is easy to get:

sender.getNodeId()

The BrowseName is also fairly easy to get:

client.getAddressSpace().getNode(sender.getNodeId()).getBrowseName().toString();

or

client.getAddressSpace().getNode(sender.getNodeId()).getBrowseName().getName();

However this only displays the last portion of the BrowsePath (for example CurrentTime from the BrowsePath Objects.Server.ServerStatus.CurrentTime).

The following code uses the BrowseUp function to trace the BrowsePath to the root. Is this the correct way to perform this conversion or is there a more efficient way (which does not require a BrowseUp function call for each hop)?

public String getBrowsePathFromNodeId(NodeId refNode)
{
try
{
String browsePath = super.getAddressSpace().getNode(nodeId).getBrowseName().getName();;
List results = null;
while(!refNode.equals(Identifiers.RootFolder))
{
results = client.getAddressSpace().browseUp(refNode);
refNode = client.getNamespaceTable().toNodeId(results.get(0).getNodeId());
if(!refNode.equals(Identifiers.RootFolder))
{
browsePath = results.get(0).getBrowseName().getName()+”.”+browsePath;
}
}
return browsePath;
}
catch(Exception e)
{
System.out.println(“Error: “+e.getMessage());
return “”;
}
}

I understand that Nodes can have many paths back to root but I am still confused by the constant suggestion to use nodes as opposed to BrowsePaths. Especially if you are using a 3rd party Server where the NodeIds are set by the 3rd party server (i.e. you have no control over them).

I understand that “under the hood” OPC UA uses nodes but from a user point of view it is still, in many cases, more desirable to use BrowsePath because this is, typically, how data is entered into the OPC UA server. For example, if I use a Kepware OPC Server (which is a UA server) then I still add entries into the server using the familiar:

channel.device.signal

Where “channel” is typically the protocol, “device” is a specific instance of the protocol typically including a path (folders) structure and “signal” is the desired signal. As an example, one might configure:

Modbus.Station01.FareGate01.Opened
Modbus.Station01.FareGate02.Opened
Modbus.Station02.FareGate01.Opened
Modbus.Station02.FareGate02.Opened
Modbus.Station02.FareGate03.Opened

When an “Opened” signal changes, I want to be able to determine for which device the signal changed. Using BrowsePath this is easy to do. If, instead, I get a Node reference then I now would need some additional resources (memory map, lookup table) to relate the obscure NodeId to something useful to an operator.

Similarly, from the BrowsePath, I can very easily adjust alarm count settings. If I have a signal that just went into alarm state with a BrowsePath of:

Modbus.Station02.FareGate01.Opened

Then I can easily see that I need to increase the Alarm Count for Modbus, Station02 and Station02.FareGate01. If, instead, I got a NodeId then I would have to somehow determine what Alarm Counts that Node belongs to. As far as I can see, that means (at best) having the Alarm Count objects as children to the node and navigating to each of the node’s children to determine all the counts that need to be adjusted.

Now consider that one of the Fare Gates from Station 02 are moved to Station 01. With a BrowsePath solution, the signals are renamed and you are done because things like alarm counts are based on the BrowsePath (meaning they update automatically). Whereas with Nodes, I would need to re-link the Node’s children to ensure that the correct alarm counts are being updated which, in my opinion, is much more prone to error (if the NodeIds used by the server are more arbitrary IDs).

Just my 2 cents.