Hi,

Alarms and Events (Alarms are a subtype of Events) are basically (only) a snapshot of a alarms/event node’s Properties state of a certain time. When a node fires an event (or a “virtual node” in case of “one-shot” events), it takes a snapshopt of all it’s Properties. This data is then compared vs. the WhereClause of the EventFilter of the Monitored event item. IF the event passes the clause, then the array of SelectClauses are evaluated vs. the data and the results are (in same order) what the MonitoredEventItemListener.onEvent(item, Variant[]) set on the item will give out on the client side. If the given event did not have that Property, it will get a null value (because the indexies are 1:1 for the SelectClauses of the filter). Please read UA Specification Part 9 for more info.

On the client side please see MyMonitoredEventItemListener and SampleConsoleClient.createEventFilter method. It is quite simplified; for more complex EventFilters at the moment you will need to read the Part 9 (and the server must support those filters as well).

On the server side, get the Properties of the node (UaNode.getProperty) and values of those Properties, or use codegen classes; see MyNodeManager.createAlarmNode.

On the server side, the SDK contains a base implementations of handling the state within the alarm nodes (e.g. AcknowledgeableConditionTypeNode). This follows the same logic as implementing methods on codegenerated types. Please see the server tutorial chapter “13.2.5. Implementing Methods in Generated Types”. You can e.g. override the complete current “Acknowledge” Method implementation by calling (static)

Alternatively you can react to the call the similar way as MyMethodManagerListener sample does.

P.S.
Unless you make your WhereClause to ignore certain events, you will get all events from the ‘Server’ node (assuming you subscribed there). Therefore it is possible that the original issue (assuming there was not a typo with the casing) was just another event type, which does not contain that Property.

Hi,

In general please do not resurrect old threads.

In short, it is not possible to “select all fields” in OPC UA. You can only get what you select, in that order (selecting nothing would get nothing).

The Variant array you get as data has the Variants in the same order the selectClauses of the event Filter. This is to say, like with the Read service call, the results have “no key” and it is the request that defines the order and kind of the data. With events it is the creation of the monitored item that fixes the fields and their order.

Technically you can loop all componets and properties of all event types and make the EventFilter like that, though you will get a lot of extra null values when that field doesn’t apply to the event.

IF the server also supports Event History, you could make a basic filter and then make a more specific history read for the event to get extra details(since you can make the event filter “again” when you make the history call, i.e. the server could store all fields for the event, though depends on the server implementation).

Alternatively if you control all information models and event types, you could make a generic “Data” Property to have a Structure that would contain all data of the event, though this would be a non-general solution.

If possible can you explain why exactly would you need this?

Anyway, either via UaNodes (UaClient.getAddressSpace().getNode) or UaClient.getAddressSpace().browseXXX:

Start from the BaseEventType and recursively Browse and get the referecens (you can do this form UaNode instances directly) and find all subtypes and keep track of their Components and Properties and then build the EventFilter with all paths.

That being said, I would not recommend doing this. Like, that is the only way as far as I’m aware, yes, but clearly the intention of OPC UA is not to do it like this (like I could be wrong as well).

There are limits on how much data can be sent back in a single message. The exact limits are negotiated by the client and the server. Most likely you cannot affect the server.

This “trick” might only work upto the point where all the data fits a single PublishResponse. Since it is a notification for single monitored item, it cannot be split. But if we take this “crazy way” even further beyond, maybe the EventFilter can be split into multiple items. You would want to be sure to include the EventId in all of them to sync up later. Then you could limit the subscription to only report a single change per notification. That would scale (upto allowed items per subscription, which probably is high enough of a limit).

But, the server will transmit quite a lot of unneeded data and will also put a burden on the server to always encode and send the data.There could be 100s or 1000s or 10000s of event fields, at least theoretically. And you will always get _all of them_ (as null values, that does take up space on the wire, at least a bit), even though the actual event might take like 10 of them. It will be the worse the more there are event types on the server.