With DST ending, what will the Octopus Agile app & emoncms do when the period between 01:00 and 02:00 local gets repeated?
1 Like
I was working on the timer feature in the DemandShaper earlier and was wondering why it was scheduling something at 9am today but 8am tomorrow… Id forgot the clocks were changing… a perfect time to develop a feature that needs to get timezones right…
So here is a test of demandshaper - minimum period is 01:00 - 01:30 BST 
.
{
"value_exc_vat": -8.23,
"value_inc_vat": -8.6415,
"valid_from": "2020-10-25T00:00:00Z",
"valid_to": "2020-10-25T00:30:00Z"
}
1 Like
Just do everything in UTC! Let the UI do the conversions.
I note EnergyStats has an extra 2 period on his graphs - so 1 - 1:30, 1:30 - 2, 1 - 1:30, 1:30 - 2 (as all times are local).
2 Likes
@TrystanLea, when does the pricing data get updated on a local system? I know if pulls it in from emoncms.org.
Glyn just asked the same, I guess because the price is -9p/kWh tonight!! It is usually loaded at 6:30pm, that becomes available in the agile app immediately but takes upto an hour to update in the demandshaper… What time is the new pricing usually available? I will add a couple more calls to pull it in earlier
Hmmm, Are you taking the first date time string and extrapolating out on a half hourly basis from there? rather than handling each date time string provided by the Agile API independently?
I see what’s happening I think, the API response as a whole switches from BST to UTC… Looks a bit better now:
Fixed a related issue in the demandshaper affecting the DSR end and plunge pricing tonight, this unfortunately requires an Emoncms update: v2.1.1 (stable) @ian @glyn.hudson @stuart @Bill_Burgess @johnbanks:
No the data returned is in UTC!
What language do you use to pull in the data from Octopus? Note Python does not convert data with Z in the timestamp correctly - always assumes it is ‘local’. You need to replace the Z with +00:00 for it to be handled correctly.
No I just convert to UTC integer and store it from there. The Graph is just a 24Hr window - so in this case, less than a day!
But the times cannot be correct as there are actually 3 hours between 00:00 and 02:00!! (i.e. 00:00+01:00 and 02:00+00:00)
I think that is right in the screenshot above, most of the time axis divisions are 2h appart from 1am to 2am which is 1h
1 Like
Ah, I’d missed that. Yep it looks like you have solved it then 
Has that always been the case?
Yes but they use Z which is dangerous for some languages.
{
"value_exc_vat": 0.0,
"value_inc_vat": 0.0,
"valid_from": "2020-10-24T23:00:00Z",
"valid_to": "2020-10-24T23:30:00Z"
}
[edit]
I think they changed the consumption API from this format to a true ISO datetime and use +00:00 on that now.
1 Like
I suggest a pinned announcement to update!
Thanks @borpin, seems that I was setting the timezone in php where I should not have done so… still php converted most of the datetime strings correctly as UTC apart from the two half hours on the change tonight. I’ve just set it all to UTC now and it looks like its working fine.
1 Like
I think the trick is to do everything in UTC and let the UI handle the timezone to display (this goes back to the timezone discussion previously). Yes the PHP Converter is pretty forgiving where Z is used - Python isn’t.
3 Likes
I didn’t see this thread until this morning but noticed that my car didn’t charge for as long as it should have done overnight due to OpenEVSE timers remaining on BST and 01:00 to 01:45 really meaning 105 minutes elapsed.
Not a big deal and I look forward to the day when DST is officially abolished. Also agree that all time handling should be UTC with the UI converting it if necessary (the UNIX® way!).
My immersion heater override (my own implementation in Node-RED) did work as that just reads a local copy of the Agile json at the start of each half hour. By the way @TrystanLea it’s available from 16:00 if you didn’t get an answer elsewhere (I add a random delay and also try again in subsequent hours if it had downloaded old data due to a late update).
1 Like
Hello @dbrooke I had the same issue, I forgot that the OpenEVSE requires a manual time update. I will discuss with @glyn.hudson what we can do there.