Hi,

“Yes”, but it must be enabled separately (and I think we only so far have “documented” it in the release notes). In https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_SDK_for_Java_4_Release_Notes.html#version-4-5-2 we added support for this, it must be enabled by calling SubscriptionManager.setMinSamplingInterval(0) for UaServer.getSubscriptionManager().

It does have a limitation (copied from the notes): “No filtering is performed when the interval is 0 (e.g. it is possible to receive values from the past if multiple clients are writing to the node at the same time). Clients that previously used 0 will now see different behavior if enabled, since previously the server would have revised the value.”

And as extra-info in the https://reference.opcfoundation.org/Core/Part4/5.12.1/ it does say

“The Server may support data that is collected based on a sampling model or generated based on an exception-based model. The fastest supported sampling interval may be equal to 0, which indicates that the data item is exception-based rather than being sampled at some period. An exception-based model means that the underlying system does not require sampling and reports data changes.”

This is to say, basically the sampling interval just defines how fast the server is looking for the values of the nodes (before the filter!), therefore 0 is the fastest option (and if servers do not support literal 0 they would revise it to the fastest sampling rate).

P.S.
However, I should note that our SDK does this a bit differently: we do not sample, we emulate sampling, because most of the time the data is pushed (by the SDK user) to the UaNodes, so SDK already knows when the values do change. IF you use instead the “MyBigNodeManager” style NodeManager i.e. no UaNodes, you must keep track of the items manually and push changes to the them directly (basically the SDK does that for the UaNodes automatically via an internal listener), then the MonitoredDataItem does the filtering. So basically we are “always” exception-based and just emulate the intervals internally. Though you can listen and keep track of the intervals/items, if you wish to use that as a base to how often look up the true data source (assuming you poll something and the source is also not “exception-based”).

My point was that while you could enable samplinginterval 0 it is not a “solution” to the problem “they don’t want continuous updates for that subscription but only when the value changes”. In short, is this an actual observed problem OR a theorized one? Because OPC UA Subscriptions do not work like that. You will only get a notification if something changed (depending on the filter): either the status, value or the sourcetimestamp must change on the server, otherwise receiving a notification would be an error in the server’s implementation.

The ‘MyBigNodeManager “style”‘ in the answer meant that you can look at the ‘sdk_distribution_unzipped_rootfolder/samples/sampleconsoleserver/src/main/java/com/prosysopc/ua/samples/MyBigNodeManager.java’ (i.e. it is a sample of using the SDK; not inside the SDK) to see how it would be done. Though, it is kinda a bit lower-level API sort of as you must do things by hand that the “UaNode”(s) would normally do for you, but sometimes that is not an option. So basically we have kinda 2 major ways to model the address space (per namespace/NodeManager): either UaNodes with an NodeManagerUaNode (e.g. MyNodeManager in the sampleconsoleserver example), or “non-UaNode” implementations build manually on top of the NodeManager (and the MyBigNodeManager is such example e.g. the backend could be a database etc.).

Normally I would recommend going with ‘UaNode’ based implementation unless there is a good reason not to. IMPORTANT (since you asked about Codegen in the other post https://forum.prosysopc.com/forum/opc-ua-java-sdk/issue-with-missing-idscodegenutils-class-in-generated-class): IF you want to use Codegen, then it is hard to use the MyBigNodeManager-style solution. The output of the generation is basically more specific UaNode implementations, which are then used in place of more generic ones. You must also load the model to the server, they do go as UaNodes. Assuming the model models types, you can (and this is recommened) to have a separate namespace for the instances. However do note that SDK can only do “NodeManagerUaNode.createInstance” i.e. the generated output is not very useful if you do not use UaNodes (any custom Structure could be used though). I would basically need to know more of what you are trying to do to give a better answer.