Please clarify that are you trying to make a new Event type as in a new ObjectType node or are you trying to “trigger” a BaseEventType (type’d) Event?

Note that the literal “BaseEventType” is an abstract type (IsAbstract Attribute is true). Though, techically I do not think we actually prevent making an instance of it, but maybe we should..

Is your Event a subtype of ConditionType or anything else?

If a ConditionType subtype, you will NodeManagerUaNode.createInstance a node for it and then you can node.triggerEvent(…) for it. The node will remain in the address space and typically it has Methods etc. to change the state of it or it might have Properties to show some limit values etc.

If it is anything else, it is a “one-shot” event, for which there is no node. For those you must use NodeManagerUaNode.createEvent(…). Technically the way it currently works is that “virtual nodes” are constructed and then deleted when triggerEvent is called for the node that createEvent returned. These events can be observed by monitoring the Server node.

Just to doublecheck, you do monitor the Objects/Server node (the one Browser has there by default when you open the Event View)? Since that is the only node from where these “one-shot” events can be observed (and I hope I’m right here; I’ll have to check later, currently at the OPCF remote interop week, so answers are short for now from my side).

I meant the literal node of path Root.Objects.Server and that alone. The one that has NodeId i=2253. See https://reference.opcfoundation.org/v104/Core/docs/Part3/4.6.1/.

Basically Alarm events would come from the actual alarm node (or well the object that it is sort of linked to in an abstract way), and it typically would have an “event trigger path” that would eventually lead to the the server node and it would be triggered for each object in the path. But for these “one-shot” events there is no node, so there is no such “path” in the first place and thus the only place you can observer them should be the server node, since that is the endpoint of all paths like this.

Like, I do use the syntax “X/Y” sometimes also to mean X or Y OR X and Y, so that happening is … normal. But yes, this time it meant a path syntax instead.

Technically how it works is that we’ll invoke the event for the SourceNode property of the Event node that was instantiated (by the creatEvent, or for alarm nodes the actual node in the address space). Then we’ll look for inverse paths (recursively) for HasEventSource, HasNotifier, HasCondition referencecs and invoke it to them (recursively then continuing from those nodes). Lastly if the Server node is not part of that, it is also invoked for that node, since all events must come always via the Server node. The default value of that Property after instantiation for most event types in just the Server node. The MyAlarm node set’s that to MyLevel in the samples (and then there is the chain back to the Server node). But most of the “one-shot” events are sort of system or audit events etc. so they might not have a node i.e. the context is the “whole server”.

Hmm… the https://reference.opcfoundation.org/v104/Core/docs/Part5/B.4.16/ for the TransitionEventType does state: “The inherited Property SourceNode shall be filled with the NodeId of the StateMachine instance where the Transition occurs. If the Transition occurs in a SubStateMachine, then the NodeId of the SubStateMachine has to be used. If the Transition occurs between a StateMachine and a SubStateMachine, then the NodeId of the StateMachine has to be used, independent of the direction of the Transition.”

So at least those events could be observed also from those source nodes and not just the server node. So what I said earlier might have been not correct or a simplified version of the situation.