[meldrewreborn]

Originally Posted by geoffers

Yeah - but if Eon are using the ½hr TOU registers for the billing the Total Import is irrelevant

How do you think EOn get the data from the meter? Via the DCC

Have you got a smart meter?
Have you got the EV tariff?
Have you written an XL macro to calculate your costs based on your half hour readings?

I guess not: but I have and this is how it seems to work for me, so I'm speaking from experience 😎

I fully appreciate your experience, but how can Eon Next use 1/2 hour TOU registers if the meter doesn't have them?

I've not got a smart meter yet (another saga) and I don't have an EV or an EV tariff. But I think i understand that a system where the accumulated supposedly 1/2 hour TOU data being used to bill the customers approximately doubles the accumulated total import figure, I don't see the latter as irrelevant at all. That Eon Next don't apparently use the Total import figure to validate their billing seems to me to be a complete failure on their part.

But lets not argue.

[geoffers]

Originally Posted by meldrewreborn

I fully appreciate your experience, but how can Eon Next use 1/2 hour TOU registers if the meter doesn't have them?

I've not got a smart meter yet (another saga) and I don't have an EV or an EV tariff. But I think i understand that a system where the accumulated supposedly 1/2 hour TOU data being used to bill the customers approximately doubles the accumulated total import figure, I don't see the latter as irrelevant at all. That Eon Next don't apparently use the Total import figure to validate their billing seems to me to be a complete failure on their part.

But lets not argue.

This thread is about @CharlotteEV's problem, and she has posted showing the values being stored in her half-hourly TOU registers (both on the Bright app and downloaded CSV file), which are showing double the kWh value being stored on the meter ... hence her bills based on these half-hourly values are double what they should be.

You have to have a smart meter and agree for them to use your half hourly data (GDRP?) to be accepted on a TOU tariff

[rwh202]

Originally Posted by meldrewreborn

@retrotecchie

If the meter sends a reading on the half hour and hour a simple calculation will identify the half hourly increment from the previous reading. If Eon Next implement a Tariff that depend on half hourly readings, then they should make sure the customer's meter is capable of supplying the required data in the correct format. They specify apparently that a smart meter is required, but do not go further. I doubt very much that this is the only case, but thankfully EVs are not that common and it seems that an EV tariff working from a Smets1 meter is required for this situation to happen.

But I don't see that the meter is to blame if it was not designed or intended to supply the data now required.

The meter doesn't send readings on the half hour and hour though!
It sends a packaged up dataset of 1/2 hour consumption values. The units of those values are different between meters, so need fixing (apparently by DCC).
It can also send the register values (up to 48 configured as well as total), but typically only daily.

I agree, using 30 minute data seems needlessly complex for a simple 2 rate tariff when all smart meters can be configured with a TOU matrix and report back peak and off peak cumulatives.

[geoffers]

Originally Posted by rwh202

...using 30 minute data seems needlessly complex for a simple 2 rate tariff when all smart meters can be configured with a TOU matrix and report back peak and off peak cumulatives.

aaah, but the ultimate (maybe pipedream) goal is to provide dynamic TOU pricing based on real time load where there are no set time periods, so costs will be based on each ½ hour's consumption

[rwh202]

Originally Posted by geoffers

aaah, but the ultimate (maybe pipedream) goal is to provide dynamic TOU pricing based on real time load where there are no set time periods, so costs will be based on each ½ hour's consumption

Yep, like Octopus Agile, but maybe E.ON should try to walk before they run...

[retrotecchie]

@rwh202

Before anyone can even crawl, let alone walk or run, every meter should be fully compliant with SMETS2, have full connectivity (preferably using 4/5G rather than the obsolete 3G), and all provide a consistent dataset that doesn't require any translation, faffing or fiddling with. Pointless trying to dream up new ToU schemes or anything else until the whole smart metering system is working properly, consistently and reliably.

[WizzyWigg]

Originally Posted by retrotecchie

@rwh202

Before anyone can even crawl, let alone walk or run, every meter should be fully compliant with SMETS2, have full connectivity (preferably using 4/5G rather than the obsolete 3G), and all provide a consistent dataset that doesn't require any translation, faffing or fiddling with. Pointless trying to dream up new ToU schemes or anything else until the whole smart metering system is working properly, consistently and reliably.

Well said. 👍

[geoffers]

Originally Posted by retrotecchie

@rwh202

Before anyone can even crawl, let alone walk or run, every meter should be fully compliant with SMETS2, have full connectivity (preferably using 4/5G rather than the obsolete 3G), and all provide a consistent dataset that doesn't require any translation, faffing or fiddling with. Pointless trying to dream up new ToU schemes or anything else until the whole smart metering system is working properly, consistently and reliably.

You've actually gotta feel sorry for the energy suppliers, as they can't just sit back and let the world pass them by - they need to move forwards and provide new tariffs etc, but in a number of cases they're stuck with obsolete equipment which they (probably) had no control over when it was installed

But agreed: the suppliers need to be more reactive in cases like this when the meter is clearly not up to the job.

I guess the meter did actually meet the requirement that it was working in smart mode and stored half hourly readings - the fact that the meter had a known firmware problem with the ½hr TOU registers is the meter manufacturers fault not the suppliers (unless the firmware can be updated OTA)

[meldrewreborn]

@geoffers

I know what the pipedream is of people in authority, but I very much doubt that the UK population will take to TOU tariffs in great numbers anytime soon, if ever.

Its the difference between theory and practice. The whole smart meter project is years behind schedule, costing a lot more than originally predicted, and while you are clearly enthusiastic for TOU tariffs, I'm guessing that for the vast majority of the population their introduction matters not one iota.

[geoffers]

Originally Posted by retrotecchie

@meldrewreborn
All that is needed is for ... Next Drive is to take the readings at the point the rate changes. That is to say, at the end of the peak period, take a single total kWh reading. Take another reading at the end of the off-peak rate. It's as simple as that and does not need to be any more complicated than that!

Sounds simple, but how would that work then?

If there's only a single Total Active Import register on the meter, they'd have to poll the meter twice a day at the exact point the tariff switches - any error on the time of polling would give incorrect results.

Presumably currently people on single tariffs just get polled once around about midnight, and it doesn't matter if the timing is off since the rate is the same every day; every week; every month of the year so your monthly bill will allow for this overlap.

People on TOU tariffs similarly must get polled once a day, when they pull the contents of the TOU registers rather than the single total-import value