FreeOpcUa / opcua-asyncio

OPC UA library for python >= 3.7
GNU Lesser General Public License v3.0
1.04k stars 345 forks source link

Read History Raw is displaying wrong information #151

Open luisfmelo opened 4 years ago

luisfmelo commented 4 years ago

Read History method is returning the wrong values. In this example, I'm trying to get values that may not be stored (server only stores 20 minutes or so):

tools/uahistoryread -u "opc.tcp://opcuaserver.com:48010" -n "ns=2;s=Demo.History.ByteWithHistory" --starttime "2020-02-20 11:04:00" --endtime "2020-02-20 11:06:00" Returns:

Reading raw history of node Node(StringNodeId(ns=2;s=Demo.History.ByteWithHistory)) at opc.tcp://opcuaserver.com:48010; start at 2020-02-20 11:04:00, end at 2020-02-20 11:06:00

Source timestamp               Status     Value
2020-02-20 11:46:42.369854     Good       219

We can see that the result returned is not in the provided range.

If we go to the last year: tools/uahistoryread -u "opc.tcp://opcuaserver.com:48010" -n "ns=2;s=Demo.History.ByteWithHistory" --starttime "2019-02-20 11:04:00" --endtime "2019-02-20 11:06:00 The response:

Reading raw history of node Node(StringNodeId(ns=2;s=Demo.History.ByteWithHistory)) at opc.tcp://opcuaserver.com:48010; start at 2019-02-20 11:04:00, end at 2019-02-20 11:06:00

Source timestamp               Status     Value
2020-02-20 11:48:21.366575     Good       152

What I think is happening is that when no value is in the provided range, the return value is always the oldest data point.

Now, let's try to get 2 seconds of data: tools/uahistoryread -u "opc.tcp://opcuaserver.com:48010" -n "ns=2;s=Demo.History.ByteWithHistory" --starttime "2020-02-20 12:08:58" --endtime "2020-02-20 12:09:00"

Reading raw history of node Node(StringNodeId(ns=2;s=Demo.History.ByteWithHistory)) at opc.tcp://opcuaserver.com:48010; start at 2020-02-20 12:08:58, end at 2020-02-20 12:09:00

Source timestamp               Status     Value
2020-02-20 12:08:57.520751     Good       2
2020-02-20 12:08:58.020752     Good       34
2020-02-20 12:08:58.520732     Good       66
2020-02-20 12:08:59.037920     Good       99
2020-02-20 12:08:59.537918     Good       131
2020-02-20 12:09:00.037912     Good       163

The resolution is not correct, as we can see, the first and last value are not in the provided range.

oroulet commented 4 years ago

Great you are having a look! I am not using history myself

luisfmelo commented 4 years ago

I'm seeing a lot of inconsistencies. But how can I help?

oroulet commented 4 years ago

Look at code and try to understand? Then fix things and make a pull request. The history code is quite simple

luisfmelo commented 4 years ago

I know but the result that it is giving me it's strange

KoenR3 commented 2 years ago

Experiencing the same issue