Hello.

I investigated further on the first question. Unfortunately, as far as I can tell, the standard alarm types defined in the UA spec do not carry the actual process value with them. This means that the way to get the process value is to include the InputNode property in the Select clauses, and then read that node as a consequence of the event notification - which, of course, is not precisely the same thing as getting the value already with the event.

A server is free to define a new event type (alarm), possibly derived from the ones in the UA spec, and add the property for the process value. It would then be possible to have that value delivered to the client as part of event notification, by including it in the Select clauses.

Best regards

Hello.

Re 1) I wanted to answer that the events are of different types, all derived from BaseEventType. And that, when you are interested let's say in LimitAlarmType (reference.opcfoundation.org/v104/Core/docs/Part9/5.8.11/ ), there would be a property in it for the process value, and you would then construct a Select clause with UAAttributeField referring to that property. To my surprise, there are various useful properties in LimitAlarmType , such as the values of the limits, but I cannot find the one for the current value.

Please allow some more time while I am looking for the answer (it's not OPC Data Client/QuickOPC question - it is a UA spec question). One possibility is that for getting the process value, the server would have to derive a more specialized event type and add the property for the process value, but I find it hard to believe that this would be the right answer.

Re 2) There is no generic way you can influence which events and when are internally generated by the server (what triggers them). The server defines that (of course, for the events/alarms defined in the UA specs, it has to follow their semantics). With the of use of Where clauses (not Select clauses), you instruct the server to only send you a subset of what internally "happens" in the server. This server-side filtering is necessary, because otherwise every event would have to be transferred over the wire to the client.

For example, the LevelAlarm (reference.opcfoundation.org/v104/Core/docs/Part9/5.8.14/ ), according to the UA spec, is defined "A level Alarm is commonly used to report when a limit is exceeded.". The server will internally generate it on every source node where it sees fit. And, if your Where clauses allow (do not filter it out), the notification will be sent to the client. And it will contain the information you specify in the Select clauses. The fields you have mentioned (NodeId, SourceNode, SourceName, Time, Message and Severity) will be always among those fields (because they belong to BaseEventType from which every event type derives). So, they are not something that "triggers" the event; instead, they are something that accompanies the event and provides details aboutit.

I hope this helps.