Jon (and all),
I have done the same comparison as you and I haven't had any "null" values during the period I have been testing. I hadn't been using the sql logger and so had to recreate the database so I only have data since I started looking into your report. I will keep checking, and will now output the new rate to the event log when it updates so I can also cross reference in the next version. My database knowledge is a little weak so possible I am missing something but I do see the rates changing at the correct time for each period. Have you seen any more occurrences ? I will also see if I can make sure an error is thrown to the log and to validate the rate more rigorously in case it relates to unexpected (and untapped by me) responses from the API as it looks like the period updates correctly and they are all pushed to indigo in the same dict at once so the update itself is happening.
On the max, min, average issue, on reflection my approach was lazy and inelegant (if you need to explain what a day is, then it is counter intuitive). I would welcome your (and others) feedback on the approaches I have in mind.
1) Keep the approach I have today but correct it to reflect the DST adjusted time and remove the 1 hour mismatch during BST. This would update at local time midnight, and again sometime after 16:00 Local when the remaining rates are published (22:30 until midnight). This does mean that the values will/may change at that point (my thought was as these values are indicative it may not be an issue for a use case on a control page for example, and if you wish to graph it take care to capture the values after the refresh time each day)
2) Remove the midnight update and only update once a day when the full 48 periods are available, Downside being until the refresh early evening it will actually be yesterdays figures
3) Some smart approach I have not thought of
Thanks,
Neil