I understand what you want. We have thought about possible designs of supporting this, but because none of them look "beautiful" enough, we ended up doing none, at least for now.

We could let the developer create/subscribe observables individually, and somehow "group them" behind the scenes, for the optimization purposes. This can have two further sub-cases:

a) The grouping would be automatic. We will monitor what is being done, and make the bulk subscriptions based on criteria such as when enough time has elapsed, or certain number of observable has been issued. The issue with this is we have something similar in OPC-DA request handling, and the developers are commonly unhappy with somewhat undeterministic and "unpredictable" behavior this approach has.

b) The grouping would be manual - some kind of API methods to indicate "start" and "stop" of making subscriptions. This is of course possible to do but does not fill well with the common Rx usage pattern, and indeed common developer expectation either.

Note that there is a similar, if not worse, issue with un-subscribing - as that is tied to Dispose(), and if the developer is not doing it explicitly, it would be the finalizer who does it, with even less control from the developer.

Note that having an API that would allow to create multiple observables at once is not a solution - not only the API would not look nice, but it is not the creation of the observables that causes the issue, it is the Subscription being called o n them later.

So, how is it working now, and what are your options?

The methods I have seen in your posts so far are creating one observable per monitored item, and the calls that set up the UA subscription will indeed be done one by done, which is not very effective. Note however that if they use the same monitoring/subscriptions parameters, they will be merged into a single OPC subscription, therefore once they are subscribed, the server will handle them together - the ineffectiveness is only during the set-up (and tear-down) time, not during the duration of the subscription.

If you determine that the ineffectiveness causes a real problem, and is not just something being afraid of, the workaround might be:

- Use an overload of the Create static method that takes IEnumerable<UAMonitoredItemArguments> as an argument, and thus subscribe to multiple monitored items at once (not quite what you asked for, but at least it will not result in one-by-one subscription calls to the OPC server).

- You will receive an observable that gets notifications for all the items included in its creation call. It should be relatively easy, though, to create a computational-only observable class or a subject that would split the incoming events into separate observables, based either on the node Ids and other identifying pieces of info that come with the notification, or bases on the State object which you can pass in when creating the subscription or observable.


If you have a proposal of how this can be done differently or better, we would be interested in hearing that.

Best regards