Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.
Rollup Value Calculations and No Values for 15m intervals
-
Hi @phildunlap, thanks for the info, however I think this way of calculating deltas is flawed for anyone doing metered readings. These happen at regular intervals like above and currently the delta value for an hour does not show the user their usage for one hour and this is the critical issue.
The way the delta is being calculated effectively drops one reading per rollup period and gives a misleading result. The normal approach for metered data at regular intervals is to only allow rollups that are a multiple of the reading interval and to calculate the delta based on the difference between the first reading of each rollup period i.e. for 15 minute readings, an hourly rollup would take the first reading of hour 2 and subtract the first reading of hour 1.
Ofsetting by 1 ms does not cure the problem as it forces the last reading in the period into the next period so it still gets missed.
One solution might be to add a "consumption" delta option to use this method? We're trying to push Mango to our customers right now for energy monitoring and this is the behaviour they need and expect. Similarly, would you consider adding a
last_value-first valueto the mango statistics object? Again, for energy monitoring, this delta is the key piece of information as it's their usage in the time period. -
@cbyrne
I am just wondering what the polling intervals you have got for your points? I can imaging if the polling interval is the same as history interval, you may run
into such issues. -
@cwangv Yeah our polling interval is every 15 minutes.
-
@cbyrne
that may well be the cause of your issue. Due to polling delay, the data will not come in at exact 15 minutes intervals.
you need to have shorter poll interval period (which is different to your history log interval), eg, 5 minutes, then over 15 minutes period you will have 3 samples in the poll, when history log kicks in, there will always be data there to collect even it is maybe from 5 minutes ago.
Give it a try. -
@cwangv
We import our data from CSV files that are timestamp,value_1...value_n in fomat.
Maybe I'm misunderstanding but I don't see polling times affecting it.Software Developer for GLAS Energy Technology, Ireland
-
cwangv
that may well be the cause of your issue. Due to polling delay, the data will not come in at exact 15 minutes intervals.
Not so! Mango is somewhat deceptive in terms or recorded timestamps in polls, which is why we discourage collecting highly time-precise data directly via Mango.
Mango will schedule a poll for a data source at a certain time, and all data will report that timestamp for the poll, even if the poll took quite some time to run. That's not true for every type of data source, since some transmit the timestamps with the data, but for protocols like BACnet and Modbus all points sampled in the poll will have the poll as the timestamp of the value.
The problem is somewhat more readily evident even with those sources now, since "Quantize" became an option on all data sources, which will align the period along the millisecond boundary of the polling period, so it is easy to collect data with these timestamps.
cbyrne
Hi @phildunlap, thanks for the info, however I think this way of calculating deltas is flawed for anyone doing metered readings. These happen at regular intervals like above and currently the delta value for an hour does not show the user their usage for one hour and this is the critical issue.
I can see your argument. I will raise it with others and see their perspective. The reason the ending timestamp is exclusive is that otherwise values on the period boundary could be counted twice in separate periods, causing the sum, average, and integral to have issues when comparing to the whole period. But, as you are noting, the delta has that behavior.
Ofsetting by 1 ms does not cure the problem as it forces the last reading in the period into the next period so it still gets missed.
Offsetting the values by 1 ms backward would solve the display issue of those rollups, I would expect. Or one could offset the period 1 ms forward if not using the datebar and truncate is false.
Similarly, would you consider adding a last_value-first value to the mango statistics object?
There already are the values Start, First, and Last in terms of values. They are formally defined here: https://help.infiniteautomation.com/mango-rollups-and-statistics
-
@cbyrne
I didn't know that your data was imported. That all make sense now together with how Mango handles the data that falls on the boundary time.
This is definitely a scenario I need to watch out for.
thanks. -
@phildunlap Thanks Phil, much appreciated!
Similarly, would you consider adding a last_value-first value to the mango statistics object?
There already are the values Start, First, and Last in terms of values. They are formally defined here: https://help.infiniteautomation.com/mango-rollups-and-statistics
I should have been more specific on what I meant, I mean could the statistics object include a value which is equal to the last value minus the start value for the time period, essentially, the consumption or delta in my terms. For example, on the point details page in the point statistics card, it would be great to have one more value, the delta/consumption. But this is minor to the original issue.
-
The last value is the the value at the period end time, since that is exclusive.
I think what will probably happen is that the delta will be computed with an inclusive period end time, while all the other statistics will remain computed with an exclusive period end time, but I haven't collected that consensus yet.
-
@phildunlap Cool cool cool, sounds like a nice solution. Thanks for keeping us in the loop!
-
We had a discussion and this is the git issue: https://github.com/infiniteautomation/ma-core-public/issues/1480
We decided that it was a better solution to include the value prior to the period start time for computing the delta, since the same at the period start would be the instant of change, not the period where the prior value was held.
