[geoffers]

Originally Posted by geoffers

@Beki_EONNext

...
<EDIT>
...probably answered the discrepancy, since the DCC time is actually supplied as Zulu time (ie GMT not BST) so hopefully the billing system will account for this...

2023-07-29T23:00:00.000Z,0.84
2023-07-29T23:30:00.000Z,0.985

</EDIT>

Further to all the above, I've found the specification Smets2 smart meters, which states that although the meters display the current local time i.e BST in the summertime all the timing data is corrected to UTC (i.e GMT) when it is stored, so the data being passed through the DCC to eon is always UTC timing.

[DebF_EONNext]

Morning @geoffers

There was a glitch in the system where we weren't receiving half hourly data over the last few weeks, this issue this has now been resolved. I don't know if this will make any difference to the data (or if it's even related to what you were experiencing) but might be something worth you looking at again to see if there's any change now the issue has been fixed?

[geoffers]

Originally Posted by geoffers

Further to all the above, I've found the specification Smets2 smart meters, which states that although the meters display the current local time i.e BST in the summertime all the timing data is corrected to UTC (i.e GMT) when it is stored, so the data being passed through the DCC to eon is always UTC timing.

Even further to the "Further to all the above"...

One of my friends has just received his personal quote for the Next Drive tariff, which now explicitly states the following

Charging your vehicle - In order for you to benefit from the reduction in cost for charging your electric vehicle, you must charge between midnight and 7am. These time are all year round, regardless of GMT and BST
In-Home Display - We don’t want to keep you waiting for Next Drive, one of our new and evolving products. Getting on board early means that now and then, things might look or behave a little differently. This could mean your Smart IHD may not display your updated prices straight away.

Whereas my original quote didn't mention the GMT/BST details - the last paragraph in mine just said...

Charging your vehicle - In order to benefit from the reduction in cost for charging your electric vehicle, you must charge between midnight and 7 am

So although they've brought GMT & BST into the description, it is still very ambiguous and will be interpreted as "in the summertime your charger is set to midnight-7am BST" ...

However when the data is stored on the meter it is adjusted for BST and timestamped as GMT... so the first hour of midnight to 1am BST is actually stored as 11pm to midnight GMT. And this is the data which will be polled from the meter and received by E.On (via the DCC)

So unless the billing system adjusts the 11:00pm GMT back to 00:00am BST, your first hour will actually be from 11pm to midnight and will get charged at the higher daytime rate - as per my earlier posts, I have downloaded the raw data from my meter which confirms this.

I still haven't had any definitive confirmation from customer services about this, so will have to wait for my first bill in a couple of months time to see what the actual charges are.

[Mailman]

@geoffers

Yes indeed that line is still open to interpretation ...I think.

By that paragraph I take it to mean 'local time' which is GMT in winter and BST in summer. Hope this clarification is forthcoming - presumably you will be able to tell from your assiduous data collection and how it correlates with your next statement.

[JoeSoap]

@geoffers @Mailman

If it's definitely the case that the timings are always midnight to 7am GMT then I have to agree that this is misleading and it reads to me like the times are what you see on any clock or watch regardless of whether we're in winter or summer.

[geoffers]

Originally Posted by JoeSoap

@geoffers @Mailman
If it's definitely the case that the timings are always midnight to 7am GMT then I have to agree that this is misleading and it reads to me like the times are what you see on any clock or watch regardless of whether we're in winter or summer.

Since the intent of the drive tariff is to move the EV charging load to lower demand hours, sensibly they would want people to be using their leccy before peak demand kicks in.

So if you had to set your charger to 01:00 - 08:00 BST (to adjust to 00:00 to 7am GMT - which is what I've been doing) the charging would coincide with peak load when folks are showering, making cuppas etc etc

The data displayed in the Bright app (being sourced from the meter's GMT timestamped data) has been adjusted for the summertime BST offset, so actually displays the timings correctly.

The usage data in the E.On Next app (although it only displays daily cumulative kWh data) now matches the daily data in Bright, so I believe the app has been updated to adjust for BST. When I started my observations in the earlier postings, it was clear that the 00:00 midnight (BST) data was being reported as 23:00 (GMT) so being totalled in the previous day's usage.

I haven't received a statement/bill for my electrical usage yet (although they have just produced the Gas statement) so when I receive this we will hopefully get the final answer to this conundrum.

I am beginning to hope that in the summertime the billing will adjust the raw data's GMT timestamp to BST (ie add 1 hour), so the computation will actually be based on what most customers would expect, with their chargers being set to 00:00 -> 07:00am irrespective of whether it's summer or winter.

[JoeSoap]

@geoffers

I look forward to hearing the definitive.

[BlackpoolCerberus]

Good news - finally got a definitive answer out of EON............perhaps not, I mean this totally clarifies the issue 🤣 Really E.ON, come on!

[JoeSoap]

@BlackpoolCerberus

That’s that settled then 😂

[BlackpoolCerberus]

Originally Posted by geoffers

@Beki_EONNext


Hi Beki - thanks for your comments 👍 ... I hope I'm not going to drive you to distraction with this 😂

I've not yet had a bill for the NextDrive as I only transferred on the 27 July, however I'm gathering some data out of interest so I can see how things stack up with the billing.

One thing that may be an issue (or may not be, depending on how the data is processed at your end) is the midnight roll over time when the lower EV charging rate kicks in.

Looking at the data for Sunday July 30 for instance...

From my charger display, the charging commenced at 5 minutes past midnight, which you can see in the left hand bar showing 1.766kwh from 00.00~01:00

Attachment 2350

And the display from the Bright app, which picks up the data from the DCC shows much the same, with the left hand bar and the text field below showing 1.83kwh at 00:00 on the 30/07 (the amount is obviously bigger, since it includes other household appliances)
Attachment 2351


However - I have downloaded the Excel CSV file from the Bright website, and there is the potential for misinterpretation of the start/end of the timing

Attachment 2352

The data on the left from my charger shows the amount used starting from midnight to 1am =1.766; 1 to 2 =1.906 and so on

However the Bright data shows the first hour's value of 1.825 as the period commencing 11pm on the 29/7 and ending at midnight; then the next 1.967 between midnight and 1am etc

So if that is how the bills are calculated, there is the potential for the first hour's charging being billed at the higher daytime rate 😧

Their raw data is actually in 1/2hourly chunks as per this which shows the 0.84+0.985=1.825 as the 2 * 1/2 hour periods before midnight on the 29th

<EDIT>

...probably answered the discrepancy, since the DCC time is actually supplied as Zulu time (ie GMT not BST) so hopefully the billing system will account for this...

2023-07-29T23:00:00.000Z,0.84
2023-07-29T23:30:00.000Z,0.985

</EDIT>

Have replicated your spreadsheet and rational...and getting the same results. As long as I take the daily data from Glowmarkt as of 23:00 then the daily usage concurs perfectly with the E.ON app

So is just a case of waiting for someone to get a detailed bill and make sure E.ON are also correcting the data for BST