That is something the server returns to us, i.e. that means the server did return 0 (check from Wireshark). That is not a valid id (0 is not, all other UInt32 values would be, OPC UA UInt32 does not have a null value, though us being in the java-world UnsignedInteger can be null within the JVM, but UA-binary-wise it is same as 0). Most likely in this case the individual operation (UA has 2 levels, entire service call vs an individual operations within the calls, i.e. they can partially succeed) of creating the monitored item failed and not the entire service call. Note that the error code is unfortunately not logged, but if you have the MonitoredDataItem, you can call .getErrorCode() for it to see the StatusCode which should then indicate what is the problem (if that is GOOD, then I would say it is a server bug). Alternatively if you were capturing with Wireshark check the CreateMonitoredItemsResponse (entire service call statuscode + individual operation’s own statuscode).

You can do the error checking in SubscriptionAliveListener.onAfterCreate for this investigation, but you might also do it just need to do an actual logic of removing the item from the Subscription and then it is up-to you what to do (depends on the error code). Also sorry, seems in this case SDK cannot yet handle re-doing the item (basically, if the entire call does not fail and instead the individual item failed, most likely they would just keep on failing on any future calls; thus should those be even attempted?; but this is a bit more complicated and is outside of the SDK’s current level of automation it can provider for you). Most typically the situation could be that e.g. the NodeId does not exist (which is in turn another gray area, as server is allowed to make such item, but it does not have to, but if the node is deleted while the item exist and then later added back it should work again by the specification).

At least this partially solves the issue at least in that sense that it is not (as I would define it) a SDK bug. Though I think eventually we should get to a point where this would not matter.

Anyway, for now this is a problematic situation. There is no automatic-out-of-the-box to re-attempt creation of the items (other than losing connection again and thus an another attempt via reconnecting logic). But depending on what you would consider as an acceptable solution there are ways to workaround this.

If you Subscription.removeItem(…) and add the item again with Subscription.addItem(…), it would behave the same way as you would be adding it the first time (this keeps the MonitoredDataItemListener). Though note that the add behaves differently depending are we connected or not. If we are not, it is just added and then when the client is connected it will be made (though it could fail on the individual level). If we are connected, errors would be thrown as ServiceException (service-level) or StatusException (individual-operation-level) and it could also return the MonitoredItemCreateResult (which is null instead if we are not connected).

For bulk, addItems can take multiple items, but it can only throw on service-level errors, and the individual operation results must be checked from the retuned MonitoredItemCreateResult[].

If you subtype the Subscription class, you could call “protected void createItems()”, which is what is internally called on (re)connect, though this is only useful if all items failed.

So in basically all cases, you will need to implement some kind of watchdog to retry the failed items, since you basically have out-of-band information that they would eventually success. I would recommend to remove the failed items in the SubscriptionAliveListener.onAfterCreate(…), put them in a queue and retry them periodically and on success removing them from the queue. This is sort of how a collection of UaClients would be handled to get the initial connection in some of our own applications (I’m aware that this also would need some improvements).

Note that if you think the nodes are something the server should know to be valid, in the current specification version it could do the items: https://reference.opcfoundation.org/v104/Core/docs/Part4/5.12.2/#5.12.2.1 “If a NodeId is known to be valid by a Server but the corresponding Node Attributes are currently not available, the Server may allow the creation of a MonitoredItem and return an appropriate Bad StatusCode in the Publish response.”, you could also try to contact the server’s manufacturer to see if they would implement that.

Hopefully some day we will have something that would work out-of-the-box for this kind of situation. Note that the situation not exactly the same as with reconnecting (but the same principles sort of apply). With reconnecting it sort of doesn’t matter how many times we try to connect, since there is no SDK-user-originated-requests that could be attempted (as no connection). But once we do have the connection (and have fetched some data from the address space), we have one channel to send requests, and this is the same used by the SDK user. Therefore we need to be at least mindful of how much stuff we can put there automatically not to delay user requests too much (matters if low connection speeds and/or a lot of failing items, e.g. 10000s of them). But probably we should have some logic in place to allow this in the future (just that if we have no knowledge that the operation would ever succeed, it would be a bit wasteful to do those calls).