[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.

In my case...

R01 is accumulated based on the "current active tariff" which is the standard rate timing

R02 is accumulated 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

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