Expected behaviour of Historical Access for constant data values

[sricharan-code]

Hi everyone,

When I try to perform write operation on a historical variable with same value multiple times, the value gets logged only in the first instance and doesn't log on subsequent attempts. Is this expected behaviour?

Usecase: In field, Temperature sensor logs data for every minute. If the temperature remains same for an hour, Is the server supposed to store 60 values or single value?

I tried testing the same with UAExpert. However, the interface doesn't allow me to log the same data.

Please let me know the expected behaviour of sever in such cases.

Thanks in advance.

[oroulet]

if you change the sourcetimestamp, then every data_value should be different, but maybe you are writting the same datavalue withtout changing timestamp?

[sricharan-code]

I'm using opcua-asyincio client. I used the below code to write the data to historized variable,
nodeID.write_value(value, ua.VariantType.Int32)
Correct me if I'm wrong, I guess server will implicitly assign a new timestamp while writing a value using below code in ua_utils.py file.

if isinstance(val, ua.DataValue):
        datavalue = val
    elif isinstance(val, ua.Variant):
        datavalue = ua.DataValue(val)
        datavalue.SourceTimestamp = datetime.utcnow()
    else:
        datavalue = ua.DataValue(ua.Variant(val, varianttype))
        datavalue.SourceTimestamp = datetime.utcnow()
    return datavalue

[oroulet]

yes the client wil create a new timestamp before sending to server.

[sricharan-code]

I felt the same and thought that it should work when I write the same data again after some time. Inorder to test this, I used the same write method on loop. However, only the first value has got logged.

[sricharan-code]

Hi @oroulet , below code logs the data only if the data change happens.

opcua-asyncio/asyncua/server/address_space.py

Line 716 in b482a23

if (old.Value != value.Value) or (old.StatusCode != value.StatusCode):

This contradicts to our earlier assumtion below.

if you change the sourcetimestamp, then every data_value should be different, but maybe you are writting the same datavalue withtout changing timestamp?

Please advise

[oroulet]

well from what we discussed earlier this looks like a bug. but it requires a bit of work to fix correctly. It will change the behavour of subscription and I am not sure what spec says. Should we send a new subscription when a timestamp has changed? If so we can change that. If not we have an issue because hisotry uses subscription and we need a more complicated solution. Can someone check specification for subscriptions?