support wrote: Hello.

Sure, yes. Strictly speaking, strings like "[] Success; Refresh; RefreshComplete" are *not* the events. They are just formatted string representations of the actual event. The event is represented by an object with various properties, and the proper way to deal with the event from inside the program is to use those properties. And, there is a boolean RefreshComplete property, too.

Read this: opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...&C%20Notification%20Event.html

I hope it helps. Let me know if you need some more info.

Best regards

Hello.

Sure, yes. Strictly speaking, strings like "[] Success; Refresh; RefreshComplete" are *not* the events. They are just formatted string representations of the actual event. The event is represented by an object with various properties, and the proper way to deal with the event from inside the program is to use those properties.

Read this: opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...&C%20Notification%20Event.html

I hope it helps. Let me know if you need some more info.

Best regards

Hello.

I do not see doing that as any disadvantage, quite the opposite. You will end up having the data closer to where they are consumed, and your REST client will get them *much* faster compared to a ConditionRefresh from the server.

QuickOPC has certain design ideas baked into itself, and in some areas, it provides higher level API than just what is OPC UA specs.

If this design does not fit your usage, you'd be better off using a different library (but I do not think this is the case with what you have described). Trying to get around the design is highly discouraged and it is possible that it won't even work. For example, you could try to extract subscription Ids from SubscriptionDiagnosticsArray variable in the server, but you may run into problems like a) permissions, b) whether the server supports it or not, c) how to map the subscription Ids to the monitored items/event subscriptions in QuickOPC, d) whether the event from the manually invoked ConditionRefresh will actually be correctly delivered by QuickOPC to you - because QuickOPC does not know about this additional ConditionRefresh - and those are just the issues that came to my mind first.

Best regards

Hello.

The fact that you ConditionRefresh "hidden" from you in QuickOPC is by design and is not going to change.
In your case your code should keep the data from incoming event notifications in memory. If the REST client needs all data, you can provide them from what you have stored.

Best regards

Hello.

In QuickOPC, you cannot get the subscription ID. The ConditionRefresh is called and handled automatically, internally by QuickOPC. For all event subscriptions you make with UAMonitoredItemArguments.AutoConditionRefresh == true, which is the default, QuickOPC will call refresh upon connections and reconnections, and also when the server indicates that the refresh is necessary, using a RefreshRequiredEventType event. To my knowledge, there are no other cases in which ConditionRefresh needs to be called.

QuickOPC also distinguishes, in the event notifications, which notifications belong to the ConditionRefresh and which represent "normal" events.

Best regards