Sorry, answers are very long..

1.
Based on the error and our code, the AlarmConditionTypeNodeBase.getActiveStateNode() did return TwoStateVariableTypeNodeBase whose getIdNode is non-null UaProperty, but the Value of the property itself is null. In general this scenario should not happen. SDK assumes there is always a non-null Value in the Id node, because AlarmConditionTypeNode.afterCreate() forces there to be false. So, probably the afterCreate() was never run by the SDK. Thus SDK fails when it tries to use 'null' as 'boolean' (and not 'Boolean'). We could maybe treat null as false, but similar things exists elsewhere thus it is more important to know why afterCreate never ran as it does other things as well.

Each generated XXXTypeNodeBase.afterCreate has logic that first does 'super.afterCreate();' Then it calls internal .callAfterCreateIfExists(UaNode) for all of the components (that are defined in this typedefinition i.e. all for which it has a generated getXXXNode()). Thus an .afterCreate() on a "top-lvl-node" propagates to all of the components. Generated XXXTypeNode.afterCreate() also contain call 'super.afterCreate();' (so it calls the XXXTypeNodeBase.afterCreate() of that type, which then calls the XXXTypeNode of the super type) , thus one possibility is that this call would have been removed if 'XXXTypeNode' was edited manually (no 'super.afterCreate();'). Another is that our heuristic for determining "top-lvl-node" failed during model loading.

Whenever NodeManagerUaNode.createInstance/NodeBuilder makes instances, it knows the top-lvl node as it creates it (it is the one returned and it just makes one top-lvl at a time). However, when loading an information model we use a heuristic: nodes that have 0 inverse Aggregate (or subtypes) references are considered as top-lvl nodes and .afterCreate is called for each of them. It is important that it is only called for the top-lvl ones, since the logic in XXXTypeNode(s) might rely on the order, with effectively the top-lvl instance having the last say in the XXXTypeNode.afterCreate that is designed to be edited (i.e. after 'super.afterCreate();' SDK has finalized initializing all components and custom logic can be added so that the SDK does not override it).

Maybe this heuristic fails for your model? For example, if the model attaches instances with HasComponent instead of Organizes to some folder structure then it would fail.

2.
There is potential confusion, as some of the methods are from Codegen and others are what we have added manually (or existed from the era before we had Codegen). Also, some of the Codegen methods are for doing an UA Method call (or partially simulating one in the server) or setting the data of a component.

For example, the ConditionTypeNodeBase.disable() is related to the interface, ConditionType.disable(), which is actually used to Call the 'Disable' Method of the ConditionType. It exist for both sides, client and server. It might not make that much sense here for the server side, but this is general logic for all generated types (and we do Codegen the core information model in the SDK). Note that this ConditionTypeNodeBase.disable() specifically calls the implementation of ConditionTypeNode.onDisable, it bypasses the EventManager logic as it is done directly in the nodes, i.e. no CallRequest is made).

The AlarmConditionTypeNode.setActive(boolean) on the other hand is a manually created helper (or probably this existed before we had Codegen), since doing interaction alarmNode.getActiveStateNode().setId(..). Plus in addition it has custom logic if the Optional ShelvingState exists for the instance.

And as an example AcknowledgeableConditionTypeNodeBase.setEnabledState(LocalizedText) is a Codegen setter for setting the Value of the EnabledState component (just as an example, in practice this should not be used directly, but instead ConditionTypeNode.setEnabled(boolean) as it properly sets the Id to the given value and then that interaction flows to overriden logic in TwoStateVariableTypeNode.setId(Boolean) (not TwoStateVariableTypeNodeBase) which sets the value of the EnabledState to the proper LocalizedText which are set by ConditionTypeNode.afterCreate())

In general I would say it is best to call methods named setXXX and then trigger manually (yes, the above kinda conflicts with this one, for the ones having LocalizedText, see if we have a related method with boolean and use that instead). This could probably use a lot of improvements ... some day.

The ConditionTypeNode Disable Method implementation does send the event because https://reference.opcfoundatio.....00-9/5.5.2 "When the Condition instance enters the Disabled state, the Retain Property of this Condition shall be set to False by the Server to indicate to the Client that the Condition instance is currently not of interest to Clients."
in addition it says "In normal processing when a Client receives an Event with the Retain flag set to False, the Client should consider this as a ConditionBranch that is no longer of interest, in the case of a "current Alarm display" the ConditionBranch would be removed from the display." Thus when a Client calls Disable this information must be relayed to all subscribers of the event. Though this logic is ... very old.

P.S.
I am aware that best would be if the Codegen versions had some specific qualifier e.g. callXXX instead of just xXX as the method name so they would be easier to differentiate. Wont happen in SDK 5.x, but not sure can we make this in 6.0.0 either, but we will have to discuss internally (it would resolve some other issues as well with naming conflicts, but the API breakage might be too much).

The same clause-logic should work for both selecting and filtering, though separately.

Assuming you use the ContentFilterBuilder, e.g. following should work as an example

ContentFilterBuilder fb = new ContentFilterBuilder();
NodeId expectedConditionId = ...
fb.add(FilterOperator.Equals, new SimpleAttributeOperand(Identifiers.ConditionType, null, Attributes.NodeId, null), new LiteralOperand(expectedConditionId));
ContentFilter contentFilter = fb.getContentFilter()
EventFilter filter = ...
filter.setWhereClause(contentFilter);

That SimpleAttributeOperand is listed at the end of https://reference.opcfoundatio.....00-9/5.5.2. Per my interpretation, it shouldn't be ... anything special as it just follows the normal rules of the SimpleAttributeOperand. A null/empty browsePath selects the alarm node itself and then it is attribute selection for that node. Though, note that in general servers (including our SDK) only support Attributes.NodeId for a null/empty path and then only the Attributes.Value for all others. It is also possible some server specifically wants the Identifiers.ConditionType as the typeId. In my opinion e.g. Identifiers.BaseEventType should work as well since it is just an inheritance check (though, in general only ConditionType and subtypes are real nodes in the address space and all other Events are "one-shot" and not present; even though temporarily they do in our impl before triggering)

I created a couple of Alarms (subtype of AlarmConditionType) using UaModeler. I am only using objects/variables/properties with ModelingRule==Mandatory.
All alarm instances are created in UaModeler as part of custom object definitions as instance declarations, not directly in the instance tree underneath the objects folder. Only an instance of the custom root application objectType is added to the objects folder.

Code has been generated and the model has been registered and nodesets have been loaded. SDK version is 5.8.0

1. when calling alarm.setActive(true) in the server code, the SDK throws an exception

After setting the ActiveState/Id value directly once (or, in UaModeler, uncheck the "null" checkbox for the value), subsequent calls succeed. This indicates, that the ActiveState/Id property is created only after writing a value directly to it

2. upon calling alarm.disable(), the toolkit triggers an event on its own. This came unexpected, because, if unaware of this behaviour, other alarm properties need to be adjusted before calling disable(). It looks like method calls are routed through the event manager. A little note in the Server tutorial could help to make this behaviour more explicit.
Is the recommendation to use the methods enable(), disable(); setActive() etc or to set the properties manually and then trigger in code?

I'd appreciate your comments on these observations.

Thanks, HU

I'd like to subscribe to condition based events and create a monitoredItem and listener per event. Is there a possibility to create a WhereClause including the conditionTypeId (already included) and the conditionId? While the conditionId is part of the returned eventProperty array (last item), there is no explicit condition property that can be used for whereclause..

Thanks, HU

That version is over 4 years old. Could you please try again with the latest version, 5.8.0?

The .getNode does read the Attributes of the node. In 4.x that also did re-read the NodeId Attribute, with basically assuming it gets the same NodeId back. This was changed during 5.x (around 5.4.0) that the NodeId of an UaNode is final and wont be re-read anymore.

Can you show what client.readAttribute(expandedNodeId, Attributes.NodeId) returns or throws?
The expandedNodeId being the same as what you used for addressSpace().getNode(expandedNodeId). If the result is anything, but the expandedNodeId (in NodeId format that is; depending on things the ExpandedNodeId format could have been with the namespaceuri as well), then that is probably the issue and the server must be fixed. In practice to in this case I would expect a null value with bad status be returned in the DataValue for the theory to be proven. IF this was the case, then 5.8.0 should avoid the issue (but let us know if not), though the server should still be fixed.

java.lang.NullPointerException: nodeId
at com.prosysopc.ua.client.AddressSpace.browse(SourceFile:1862)
at com.prosysopc.ua.client.AddressSpace.browse(SourceFile:367)
at com.prosysopc.ua.client.AddressSpace.readReferences(SourceFile:1404)
at com.prosysopc.ua.client.AddressSpace.getNode(SourceFile:977)
at com.prosysopc.ua.client.AddressSpace.getNode(SourceFile:854)
at
======
The simplified code:

List references = addressSpace().browse(nodeId, BrowseDirection.Forward, NodeId.NULL, true, NodeClass.Variable);
ExpandedNodeId expandedNodeId = references.get(0).getNodeId();
UaNode uaNode = addressSpace().getNode(expandedNodeId);

Well ... so far basically there has been no demand to do it differently. Do you have a use-case where it would be of use?

Currently the logic is shared with MQTT-UADP. In MQTT it is likely that each Writer has a different Topic. It is not possible to publish to multiple topics in a single MQTT network message. Thus, at the moment the WriterGroup simply does loop all Writers and each Writer will produce the NetworkMessages related to it. The only scenario where multiple DataSetMessages would exist in a single NetworkMessage at the moment are for Event-DataSets.

P.S.
It is not related to the sequence number issue.

As far as I remember the U(A)DP logic didn't yet properly support wildcards, though it mostly appears to do so via common logic. A proper wildcard-supporting version would need to keep track of the numbers for each PublisherId+WriterId combination it sees. Though in reality probably something like last 100 seen to avoid memory leaks.

Adding few extra notes, though mostly it is as said above.

The configuration can be changed via PubSubSystem.updateConfiguration(..). That method will take a function, which receives the current live configuration as input (PubSubSystemConf) and it must output the desired new configuration (PubSubSystemConf) or throw PubSubException to abort. Once the function outputs the desired state, PubSubSystem will internally create/modify/remove connections/groups/writers/readers to match the new configuration (or throws PubSubException, if that fails for some reason).

The design was to allow multiple concurrent update operations from multiple threads. Due to intentional synchronizations, only one of the update-functions runs at a time, but they would always see the result of the previous function output as their input. This would have been a need for making an address space -based configuration, since each Write/Call operation happens on the blocking-work threads. Though, nowadays it mostly enables SDK itself updating the configuration as that is used to store received metadatas.

Thus, in general one PubSubSystem should be enough. If for some reason the updating doesn't work, let us know.

P.S.
Since the PubSubSystem takes the UaApplication (UaClient/UaServer), if you have multiples in a single application, then you would need a PubSubSystem for each. Skipping some details regarding Subscriber side for now. Skipping also some details regarding MQTT.

In the meantime I'm using the workaround above.

I'll make an issue on this as a possible future improvement.

It actually sounds like you have picked the wrong installer. Look for the separate macOS installer for Apple Silicon on the download page 🙂

BR, Jouni

I am running Prosys OPC UA Browser 2026.1.2-38 on Apple Silicon macOS 26.5.1.

macOS reports that the application will not be supported in a future macOS version. Inspection shows that both the bundled Java runtime and launcher are Intel-only:

/Applications/Prosys OPC UA Browser.app/Contents/PlugIns/jre.bundle/Contents/Home/bin/java: Mach-O 64-bit executable x86_64
/Applications/Prosys OPC UA Browser.app/Contents/MacOS/JavaApplicationStub: Mach-O 64-bit executable x86_64

My system Java is already native arm64 OpenJDK 21.0.8, but the app uses its bundled Intel runtime.

Do you provide, or plan to provide, a macOS Apple Silicon / Universal build with an arm64 bundled JRE and native launcher?

Best,

Matthias

Is there any way to accept a .pem file which contains both using the SDK?