[Andy65]

It will be interesting to see what action e.onnext take now. The minimum one would expect would be to stop any customers taking the EV tariff if they have a SMETS1 meter, checking every EV tariff customers billing to ensure that they have been/are being charged correctly.

The supplier also has to take some responsibility for this, don't offer something that you don't fully understand.

[rwh202]

Originally Posted by retrotecchie

@geoffers

So you are saying that the smart meter dataset does not contain a cumulative value (I.e. Current Active Register reading) for each half hour?

Therein lies the fundamental problem.

correct - that is my understanding of the spec and confirmed by all the datasets I have seen.

[rwh202]

Originally Posted by geoffers

Are you assuming that meters have two separate Active import registers - mine certainly doesn't.

What meter is that? specs are for 48 registers.

[geoffers]

Originally Posted by retrotecchie

@geoffers

So you are saying that the smart meter dataset does not contain a cumulative value (I.e. Current Active Register reading) for each half hour?

Therein lies the fundamental problem.

Why does it need to ? Not sure about SMETS1, but if you look at the SMETS2 spec (section5.6.4.28) they have in internal half hourly incremental register which I assume is used for the TOU calculations

5.6.4.28 Profile Data Log
A log for storing UTC date and time-stamped half hourly data (the amount of energy imported or Exported in a half hour period) arranged as a circular buffer such that when full, further writes shall cause the oldest entry to be overwritten. The log shall be capable of storing:
i. 13 months of Consumption;
ii. 3 months of Active Energy Exported;
iii. 3 months of Reactive Energy Imported; and
iv. 3 months of Reactive Energy Exported.

I guess if you add these together for a 24hr period they add up to the Total Active Import register for that day.

To store 13 months of half hourly readings for the total import value would take many more bytes of internal memory so I guess it was a memory size issue in design (cf y2k problem)


<edit> Having mentioned y2k - these smart systems probably won't last after 2038 anyway as there's a y2k38 problem looming - the CSV data downloads contain the UNIX timestamp so that is probably how it's stored on the meters😎

The year 2038 problem, also known as Y2K38, is a time computing issue that will occur on January 19, 2038 at 03:14:07 UTC: Explanation

• The problem occurs because many computer systems use a 32-bit signed integer to store Unix time, which is the number of seconds since January 1, 1970

</edit>

[geoffers]

Originally Posted by rwh202

What meter is that? specs are for 48 registers.

Agreed - my L&G E470 type 5424 should have these, but they don't seem to be being used/accessed by EOn as they are not populated.

They look like they are for 48 different rates, so I guess each 1/2 hourly period can have it's own rate assigned