Events for client read and write on node.

[pedro-ricardo]

Hello, I'm starting to use the lib and I have a question regarding the Events.
I've created the following structure in the server:

And I wish to track the client's intention to read in ReadOnly node and to write in the WriteOnly node.
Are there built-in events generated by requesting a read or a write in a node?

So far I noticed that data_change can be used in the WriteOnly node to make this happen. But I'm looking forward to keep this based on requests.

[zerox1212]

You want to know which client is executing a one-time read? Or you want to keep track of clients with subscriptions?

Some people have asked for stuff like this before and it isn't supported as far as I know. You would need to do a lot of custom stuff to keep track of the activity of individual clients. In my opinion this is a strange use case for UA.

[pedro-ricardo]

I want to keep track of the client with the subscriptions.

Those requests shouldn't sound weird. I think the idea behind such questions is to use OPC-UA as a bridge between other communication protocols.
Things like these are present in every OPC-DA server out there in industry. They read from PLCs using the manufacturer protocols and make all data available through OPC-DA. From this DA server one can plug a historian, supervisory and etc.
Maybe the common idea between these people is to replicate this behavior with OPC-UA.

[starturtle]

Okay. So at one point you're talking about reading and writing, at the other you're talking about subscriptions.
Where do you wish to track the client's requests? Inside the server? In a different client? Somewhere completely different? Unless you wish one client to police another, I don't get your approach at all. If that's what you're planning, though, I don't get why.
Configuring your server to emit events on read and write is very custom behavior. Also note that events get emitted to all who subscribe with the right event filter, so if their subscription setup is sufficiently indiscriminate, either any client can read your tracking by putting in extra low effort, or your server doesn't publish events for all event handlers to handle, which is at best gray area in the spec.
What you could do though, if you plan to do this client-wise, is to define extra Variables with very reduced visibility (or Value read rights) that contain the request metadata. And have a monitoring client subscribe to changes on their Values.
But I wonder if exposing such more statistical data to clients either way is really the way to go.

[pedro-ricardo]

It is read and write... that is the goal.
But how can I read and write on demand? Maybe this is what I failed to explain.

The code I'm trying to build is both a OPC-UA server and another protocol's client.
My OPC-UA client is not in python.

There are some ways to do this. One is to have a internal loop in the code, that execute reads in other protocol and writes it into OPC-UA variable. This works.
But I wanted to execute this read in the other protocol only when the OPC-UA client asks to read a variable. That's what I called "on demand".
I thought that this read request from the client would generate a event on the server, and that is why I asked about subscriptions ... but maybe that is not the case.

[zerox1212]

He wants to intercept a read request, trigger an update of the node from another protocol, then fulfill the read to the client. From my experience this is not really the design of UA.

The intended design would be that the other protocol should update the UA server when a value changes, then the UA server will notify all subscribed clients of the change and send them the new value. Subscriptions are the most versatile and fastest communication method of UA.

[starturtle]

@zerox1212 the intended design assumes that the other protocol is capable of using events, or that the server is polling on the other connection. While I agree that this is most likely what the foundation people had in mind, it is not a given in all environments.
There must be a canonical concept in the spec to defer request handling somehow, given the return code GoodCompletesAsynchronously in Table 177 of the return code section in part 4 of the spec. Not sure if that is implemented in the server, I'm more familiar with the client side.
@pedro-ricardo an Event has a different direction in OPC UA. It sounds more like you're looking for server-internal callbacks than events in an OPC UA kind of way. Plus, if you use events, you probably end up with something executed at lower urgency, which would make the timeout issue Andrew mentioned even more pressing.

[zerox1212]

Deferring the request handling to do some other operation is outside of what I know about UA. Certainly there is nothing built into this library to handle that.

In my opinion the next step is to find where in the spec this behavior is defined. Then we would have some clue about what UA objects/mechanism must be created to achieve this.