search

FreeOpcUa / python-opcua

LGPL Pure Python OPC-UA Client and Server
http://freeopcua.github.io/
GNU Lesser General Public License v3.0
1.32k stars 661 forks source link

NodeID string is truncated #1474

Open WOLF33 opened 1 year ago

WOLF33 commented 1 year ago

My server uses the following identifier "ns=3;s=EquipSetParam(E=93;SP=204)" to identify object parameters. when I get a node, the identifier is truncated to something like this "ns=3;s=EquipSetParam(E=93", so I can't get the node and data. I looked at the source code of the package, there is a semicolon separation. What should I do to start get data by my IDs?

swamper123 commented 1 year ago

Hey ho,

  1. The library is deprecated. Please switch to : opcua-asyncio which also has a sync-wrapper, with very few changes in API**

  2. If I remember right, symbols have been a problem even in opcua-asyncio, but was partly solved. You may have to give it a try there.

SnoopAir commented 2 months ago

@swamper123 : was actually using opcua-asyncio right from the start because of the argument "the other is deprecated use the new one". At first I just put all the await async stuff there... but code looks simply cluttered all over the place. In addition some calls are not async and you without looking it up you or running several times into the same issue you don't know.

In addition adding a sync-wrapper on top of the async which has been replacing sync in the first place sounds weird. On top of that, the sync-wrapper does neither use the same names for functions nor provide the same functionality. And cheery on the cake: Documentation of opcua-asyncio is even worse then python-opcua. In both projects merge requests are pending since long. So even if people want to contribute, it seems impossible.

After just moving to sync-wrapper with opcua-asyncio and struggling I'm reconsidering to move back to python-opcua in the first place and/or clone that repo to add and fix what I need.

oroulet commented 2 months ago

What? Just in case someone reads the naive and stupid comment above:

If you have things to fix, then just make a MR. If it make sense it will be merged quickly All of the not merged MR are either draft or broken. Someone should go through them and close most of them.
Also the syn/async wrapper thing is a quite common technical solution to support both api

SnoopAir commented 2 months ago

@oroulet : I accept your judgement of "naive", that might be. But stupid is just disrespectful.

If I have things to fix? As mentioned on another issue there is the request to move forward to support at last UA 01.05.02 while there is even already 01.05.03. - This is no MR but a necessary feature request. And there is yet somebody who would like to help.

And MR, there are a lot. I don't know what state they are and I don't care. But 4 of them are even from you and they date as far back as 2016. So you are telling me that that your MR are no sense, right? Or they are broken? Or they are draft? What ever is the reason, MR are a sign that people would like to contribute. Not processing them ....

And for example what'ts wrong/broken with a merge request fixing a type? https://github.com/FreeOpcUa/python-opcua/pull/1487

And about the sync/async API might be both common solutions. But without doubt you can't say that they cover the same features nor do they have the same naming. If you believe they are equivalent.... I'll proof you wrong.

And for anybody looking at "async" code and not addmitting that it looks ugly with all the gluttering aysnc and await ... I would recommend to read stuff about "Clean Code".