Node Write_Value from client.

[Alfy102]

Hello good people, I have been lurking here quite a while studying this library and trying to implement my own Asyncio OPC UA server. The server purpose is to constantly while loop read from a machine address registers and write the value to the OPC server nodes.

However I am also trying to implement a write from the OPC server to the machine address registers by changing write_value to the OPC nodes which would send the data to the machine address registers.

I have been wondering if there is a way for the server to differentiate a write_value to a node coming from a client or the server itself? Something like a flag.

Thank you very much :)

[oroulet]

No.
You are not the first one to ask for such a feature. But so far i have only heard very bad reasons...

[Alfy102]

Understandable. Anyway I have thought up of a different communication method.

[dkeppler]

Apologies for digging up an old thread, but I find myself in the position as @Alfy102. What is the recommended pattern for this case?

[AndreasHeine]

probably server.read_attribute_value​(​ ​nodeid​, ​attr​=​ua​.​AttributeIds​.​Value​) rather then node.read()

same with write!

[dkeppler]

Ah, I think I see now. Thanks for that hint.

For anyone else that stumbles on this in the future, I was trying to implement a server backed by a hardware PLC and basing it on the server-callback.py and server-ua-python-mirror.py examples. The latter's use of Node.write_value() is what led me astray.

I was using a PreWrite callback to intercept client writes to the OPC server to simultaneously do a write back to the PLC. That part worked fine. The problem was when doing polling reads of the PLC for its data and then trying to update the OPC server with those values. Following the python-mirror example and using Node.write_value(), that goes down a code path that eventually triggers the same PreWrite callback which would set my code off in an endless recursive loop. Server.write_attribute_value() uses a slightly different path that does not trigger that particular set of callbacks (but still triggers data change subscription notifications). That's the differentiator.