Hi,

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. If this is the expected behaviour, maybe a note in the ServerTutorial could be added.

3. depending on how exactly the alarm instance (instance declaration) is setup in the model, different event properties are published:

version 1: customAppRootObjectType/customObjectType1/customObjectType2/AlarmInstanceDeclaration => all properties are received in UaExpert; sourceName = Server
version 2: customAppRootObject/objectInstanceDeclaration(BaseObjectType)/customObjectType3/AlarmInstanceDeclaration => only base event properties plus activeState/Id and enabledState/Id.; no SourceName, no “IsActive” in UaExpert

For this observation it is not entirely transparent, what UaExpert is doing behind the event subscription logic.

I’d appreciate your comments on these observations.

Thanks, HU