[meldrewreborn]

@RobJM

Good move!

Please keep us advised of developments. You can also rest assured that we can offer sensible advice, should you need it.

[geoffers]

Originally Posted by geoffers

Out of interest, I'm going to compare my day/night register readings to the ½ hourly ToU consumption to see if they indeed do match
Although I'm billed on my ½ hourly ToU usage based on "local time = midnight to 7am", a couple of months ago I discovered that my meter seems to have been reconfigured with 2 Active Import registers, plus the tariff switch timing set set to 00:30 - 07:30 UTC (which currently is switching tariff between 01:30 to 08:30 BST)...

Well folks - I can confirm the following after 4 days monitoring R01(day)/R02(night) total consumption registers, and the corresponding 48 ToU ½ hourly usage values.

As expected...

• Registers (R01 + R02) match the sum of (hh01 thru hh48)
• R02 is currently accumulating the 7 hrs usage between 01:30 and 08:30 (since the tariff hours set on the meter are 00:30 to 07:30 UTC) which would be billed at the cheap rate
• and R01 accumulates the 1½ hrs before and the 15½ hrs after this, which would be billed at the at the standard rate
  
  • (luckily my billing is on the ½ hourly ToU readings from midnight to 7 local time)
• For E7 users: if the ALCS calendar is not set to the same as the tariff timings, you will be billed on the incorrect values being accumulated in R01/R02
  
  • Now that people on E7 have smart meters (as long as they're working in "smart" mode), there doesn't seem to be any reason for basing the billing on the R01/R02 registers.
  • They could do exactly the same as they do for the Next Drive tariff, and bill based on the ½ hourly ToU
  • Or if they do insist on using the R01/R02 registers, they could ensure that on change of GMT/BST the meter's tariff timings and ALCS calendar are both updated to reflect "local time" ie BST in summer and GMT in winter (don't know if this would overload the DCC with too many meter update commands being sent, but modern computer systems should be able to handle a huge amount of online transactions)

[meldrewreborn]

@geoffers

given that the live supply from a 5 port meter is split between normal usage and switched off peak only usage, the normal usage would record to the correct registers and “only” the ALCS usage would potentially be incorrect - offset by however much the timings disagree.

when that happens correcting the billing will be a matter of negotiation rather than being provable.

[geoffers]

Originally Posted by meldrewreborn

@geoffers

given that the live supply from a 5 port meter is split between normal usage and switched off peak only usage, the normal usage would record to the correct registers and “only” the ALCS usage would potentially be incorrect - offset by however much the timings disagree.
.

Maybe, but my 4-port meter is configured as a 2 rate meter with ALCS, where the ALCS would switch an external relay energising the off peak circuits, rather than a 5 port meter where the switching relay and supply live terminal is internal to the meter.

In both cases only the normal household circuits are energised in the day, but all household+off-peak circuits are energised at night.

The registers being used are based on the tariff timing not the ALCS switching times. In my case...

R01 accumulates total household usage based on the "current active tariff" which is the standard rate timing

R02 accumulates total household usage based on the "current active tariff" which is the off-peak rate timing

Which is why my R01+R02 equals the sum of the day's total consumption

So if the ALCS doesn't match the tariff timings BOTH registers will have recorded incorrect consumption totals (but their sum is still correct for the whole day)

Maybe it's different in a "Smart" 5 port meter? The only way to confirm this would be to compare the register & ToU readings from one of these in the same way

[meldrewreborn]

@geoffers

I don’t doubt that the total recording is correct when adding the two registers together compared to the half hourly consumption figures. But if the ALCS is not in step with the tariff timings, so that the customers BILLiNG is incorrect, the correct position cannot be proven by mathematics but instead must be assessed by probability.

[geoffers]

Originally Posted by meldrewreborn

@geoffers

I don’t doubt that the total recording is correct when adding the two registers together compared to the half hourly consumption figures. But if the ALCS is not in step with the tariff timings, so that the customers BILLiNG is incorrect, the correct position cannot be proven by mathematics but instead must be assessed by probability.

....but since the customer has access to the ½ hourly ToU readings he can use this to show the "BILLiNG was incorrect... proven by mathematics"

• If the Bill is calculated multiplying the usage by the tariff rate at the quoted tariff timings (which EOn have done - the registers are tied to the tariff timing), the bill will be incorrect ... ie this is what they were billed
• If the Bill is calculated multiplying the usage by the tariff rate at the time the ALCS switch actually occurred (which the customer has assumed should match the tariff timings) the bill will be correct ... ie this is what they should have been billed

I have read that EOn won't accept data downloaded from third parties, but armed with this information surely the onus is on EOn to do these same calculations (they too have access to the ½ hourly ToU readings) to accept or disprove the customer's mathematics

[meldrewreborn]

@geoffers

so if the ALCS switch takes place at quarter past the hour there is only indicative data, not conclusive data, to help quantify any billing error, so resolution will depend upon assessment. That’s all I’m saying!!

[geoffers]

@meldrewreborn - yawn 🤣

[doverboy]

Originally Posted by geoffers

Well folks - I can confirm the following after 4 days monitoring R01(day)/R02(night) total consumption registers, and the corresponding 48 ToU ½ hourly usage values.

As expected...

• Registers (R01 + R02) match the sum of (hh01 thru hh48)
• R02 is currently accumulating the 7 hrs usage between 01:30 and 08:30 (since the tariff hours set on the meter are 00:30 to 07:30 UTC) which would be billed at the cheap rate
• and R01 accumulates the 1½ hrs before and the 15½ hrs after this, which would be billed at the at the standard rate
  
  • (luckily my billing is on the ½ hourly ToU readings from midnight to 7 local time)
• For E7 users: if the ALCS calendar is not set to the same as the tariff timings, you will be billed on the incorrect values being accumulated in R01/R02
  
  • Now that people on E7 have smart meters (as long as they're working in "smart" mode), there doesn't seem to be any reason for basing the billing on the R01/R02 registers.
  • They could do exactly the same as they do for the Next Drive tariff, and bill based on the ½ hourly ToU
  • Or if they do insist on using the R01/R02 registers, they could ensure that on change of GMT/BST the meter's tariff timings and ALCS calendar are both updated to reflect "local time" ie BST in summer and GMT in winter (don't know if this would overload the DCC with too many meter update commands being sent, but modern computer systems should be able to handle a huge amount of online transactions)

Now that people on E7 have smart meters (as long as they're working in "smart" mode), there doesn't seem to be any reason for basing the billing on the R01/R02 registers.

• Not all customers have smart meters
• Smart meter customers have to opt in for 1/2 hour data reads
• Register reading provides transparency for all customers
• Customer reads and submissions need to be of registers

Out of interest what happens for someone on a ToU tariff, like yourself, if they have telecommunication problems or need to submit a manual reading. What happens on switching tariff or supplier?

[geoffers]

@doverboy said...

• Not all customers have smart meters
  
  • True, so in this case everything would still operate as it has done historically
• Smart meter customers have to opt in for 1/2 hour data reads
  
  • This is actually a GPDR thing, where you authorise the supplier to access your 1/2 hour data reads - the meter still stores them irrespective of your acceptance or not
• Register reading provides transparency for all customers
  
  • True: so the user can view their R01/R02 readings, and the meter still records even if comms is lost
  • However it is essential that the ALCS calendar matches the tariff timings otherwise the recorded usage is incorrect
• Customer reads and submissions need to be of registers
  
  • True, but the Next Drive tariff/structure is essentially the same as an E7 tariff, so in the "Smart" world: for E7 they could ignore the registers and bill in the same way as the they do for Drive
  • If that were the case they would only have to ensure the ALCS calendar is set up correctly on the meter to match the expected tariff - the actual tariff timings sent to the meter could be ignored (as happens on Drive where you are billed from Midnight to 7 local time (irrespective of BST/GMT), but they have uploaded the meter's "active tariff" times to 0:30 - 7:30 in the winter which equates to 1:30 - 8:30 in the summer

Originally Posted by doverboy

Out of interest what happens for someone on a ToU tariff, like yourself, if they have telecommunication problems or need to submit a manual reading. What happens on switching tariff or supplier?

That's a worrying unknown, since Drive relies on the ½ hourly ToU readings for billing.

• There is no opportunity to submit a manual reading, since the app/website doesn't provide that facility on ½ hourly ToU tariffs.
• They could use the R01/R02 registers, but since they have set the timing to 00:30 > 07:30 the billing would be ½ hour out in the winter and 1½ hour out in the summer (but of course they couldn't anyway, since if comms were lost they couldn't read the meter remotely - Catch-22)
• I guess they would just revert you to nextFlex for billing
  
  • hopefully you could fight your case if comms were later resumed, as you could then download the historic ½ hourly ToU and re-calculate your bills