Thank you for explanation. I understand the need, and in fact having something like this is on the wish-list already, but it has not made it into the product yet.

If you already have the value being read back on the subscription, why don't you use its "status" to enable/disable the commands in UI? You can monitor whether the incoming item change notification has null or non-null Exception property, and act accordingly.

Alternatively (this really is a workaround, I know), you can even subscribe to *any* (even unrelated) readable item from the OPC server, and do the same.

Just to be completely clear, you should not look at the Quality (inside the VTQ): This information comes from the server itself, and the quality might perfectly be Bad even when the connection with the server is OK. But a non-null value in the Exception property indicates that the Value/Timestamp/Quality could not be obtained at all, meaning a serious problem between the client and the server.

Best regards,

This is by design.

By calling Subscribe, you declare an intent to be subscribed, and receive the status and values. By calling Unsubscribe, you declare that you are no longer interested in these.

The server or the item may go down at any time. Or. they may not be available at the time of calling - it doesn't matter. The component will try - and keep trying to - to fulfill the "subscription intent" for the time of its duration (i.e. until you unsubscribe).

After you Subscribe, you receive a first notification. It will be either successful (.Exception == null), or unsuccessful (.Exception != null). This is how you get the result. If the server is not available at the time of initial subscription, the first update will be with some .Exception, but after a (configurable) period, the component will retry, and then you may get a success.

The end result is, that you do not have to write any re-connection code, or handle the server failure in a special way.

Let's consider this use case: You are writing an "HMI" kind of application, where the values form the server should be continuously updates on the screen. With this design, you just call Subscribe for each item, and then with each notification, display whatever status or value you receive. That's it. No extra to code handle "what happens if the server is not running at the moment I first try to subscribe", or "what to do if it succeeded initially but then crashed", etc.

Your usage case may be similar, or different. If it's different and you are not sure how to handle it, please explain what you are trying to achieve.

Best regards