Topic RSS12:15, EET
March 16, 2017
OfflineHi,
I’m just trying to read the history of the ‘Counter’ simulation value from the Simulation Server and recognized that when I call historyReadRaw with e.g. startDate 03/19/26 14:00:00.0000000 GMT and endData 03/19/26 14:05:00.0000000 GMT and returnBounds=false that I’m getting values from 14:00:01 to 14:05:00.
But as returnBounds was false, I expected values from 14:00:01 to 14:04:59
——————————————————————————————
historyReadRaw(): startDate: 03/19/26 14:00:00.0000000 GMT
historyReadRaw(): endDate : 03/19/26 14:05:00.0000000 GMT
historyReadAll: nodeId: ns=3;i=1001, indexRange: null, timestampsToReturn: Both, historyReadDetails: ReadRawModifiedDetails [IsReadModified=”false”, StartTime=”03/19/26 14:00:00.0000000 GMT”, EndTime=”03/19/26 14:05:00.0000000 GMT”, NumValuesPerNode=”0″, ReturnBounds=”false”]
historyReadAll: Got StatusCode: GOOD (0x00000000) “The operation succeeded.”
historyReadAll: Read complete, returning 300 values
historyReadRaw(): dataValue: DataValue(value=22, statusCode=GOOD (0x00000000) “The operation succeeded.”, sourceTimestamp=03/19/26 14:00:01.0000000 GMT, sourcePicoseconds=0, serverTimestamp=03/19/26 14:00:01.0000000 GMT, serverPicoseconds=0)
…
historyReadRaw(): dataValue: DataValue(value=11, statusCode=GOOD (0x00000000) “The operation succeeded.”, sourceTimestamp=03/19/26 14:05:00.0000000 GMT, sourcePicoseconds=0, serverTimestamp=03/19/26 14:05:00.0000000 GMT, serverPicoseconds=0)
——————————————————————————————
I tried the same with returnBounds = true, then I get 302 values from 14:00:00 to 14:05:01 – but I expected the last at 14:05:00
Is this normal or is it one entry too much?
Thank you!
12:38, EET
December 21, 2011
OfflineYes, you seem to be on the right track. We are returning samples a bit off. The specification says, that when returnBounds=false, we should return the first sample, even if it falls on startTime, but not the last sample that falls on endTime.
I think the idea is anyways, that with returnBounds=false, you will only get all samples without any interpolation at the bounds. But, you can ask for consecutive time ranges and still get all samples – even the ones that fall on the bounds, but only once.
So now it seems that we are doing the “right thing”, but returning the sample at the endTime instead of startTime.
Whereas, for returnBounds=true, the last sample seems to be too much, indeed.
We will need to check this out and see where the flaw is… Thanks for reporting.
1 Guest(s)

Log In
Register