New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question : SourceTimestamp not working for external clients #727
Comments
+1 I have the same issue :-/ |
I would take a look at this. python-opcua/opcua/ua/ua_binary.py Line 36 in a8553ad
This library converts the incoming binary to python Datetime from what I remember. Whatever the client is sending must not be formatted how the code expects it.
|
I have the same issue with UaExpert - what is the solution? |
As far as I remember we donnot write this attributes. but if you write it explicitly for example in python: then you will see it updated from uaexpert or any other client if you are using an external client and do not see that value, then it measns that you client do not specify that attribute |
Thank you @oroulet for the fast reply. I'm just wondering, because the timestamps were correctly set in opcua-0.98.1 (tested with python 3.6 and the latest version of UaExpert). But it is not working with the latest opcua release (neither with python 3.6 nor with 3.7). So I assume that there was a change in the time stamp handling of the library. |
Yes before we updated automatically both timestamps, but it was a performance issues and we found out many servers were not doing it. So I removed that code |
The whole discussion seems to be related to #850. Maybe you can add the functionality again as "optional feature", so that we have the possibility to turn it on for the server. |
Whenever I update a certain value of a variable from an external client, the source Timestamp becomes 1/1/1601 (like the Server Timestamp, but this is less important...).
I tried with different clients (2 different from Node-Red and also with UAExpert). Maybe the timestamp I'm sending is wrong, but my feeling is telling me than it would not work like this and some kind of handler would need to be written to handle incoming values and write them in python as client to the server including its own timestamp?
I anted actually to replace an OPCUA Server on one side with this one, but it will be impossible if the timestamp is not adapting.
The text was updated successfully, but these errors were encountered: