This question is related to Behavior for a history sets on a parameter with the same value.
The DataMiner Development Library explains that:
"When performing history sets, keep in mind that history sets must be done in chronological order. This means it is not allowed to perform a data point set with a timestamp of e.g. 14:10:30 once a data point with a later timestamp (e.g. 14:10:40) has been set."
I tested it and it works as is explained if the values of the parameter are different.
According to this and my previous question if I perform a history sets in this order (not all at once):
- Parameter01 = 0; 17-12-2020 10:00
- Parameter01 = 0; 17-12-2020 10:02
- Parameter01 = 1; 17-12-2020 10:01
What I expect is that DataMiner process entry 1, entry 2 but discard entry 3 because the last set is at 10:02 and entry 3 has a previous timestamp. So I expect that the value of Parameter01 will be 1 with LastChange = 17-12-2020 10:00 and LastPoll = 17-12-2020 10:02 which is the last and current status of the device parameter.
Instead of this, what actually happens is that DataMiner process entry 1 (Parameter01=0, LastChange=17-12-2020 10:00, LastPull=17-12-2020 10:00), DataMiner process entry 2 (Parameter01=0, LastChange=17-12-2020 10:00, LastPull=17-12-2020 10:02) and instead discarding entry 3 it is processed (Parameter01=1, LastChange=17-12-2020 10:01, LastPull=17-12-2020 10:01). So what I have at the end is that Parameter01 has a value 1 witch is not the current/last value of the device parameter.
I believe that this behavior is not appropriate because when you are using a history set with digital/binary parameters that could arrive disorderly or messy, DataMiner will display incorrect/old values.
Is there any solution or workaround for this?
Thanks in advance!!
Hi Fernando, it is indeed a requirement that history-sets happen chronological. The main reason why this is needed is for the average trending. Every 5 minutes and and every hour the so-called trend window gets closed and that trend-data is then pushed to the database. If after the close of the window, which happens when receiving a trend-point outside that window, you would push another value from within your protocol, it would require a CPU intensive recalculation and update of existing trend records. Now, to answer why your specific use-case acts as you describe, is that for DataMiner, and more specifically for SLElement.exe that only receives changed values, the 2nd update never happened as there was no value update. If then, the 3rd update comes in on a later time than the first time we received value '0', we do see a change and accept the value of '1'. The only way to work around this one today would be buffer the timestamp in your driver for the parameters that use history-sets.