This is really thorough and insightful @Firedog! You theory about the cause of the discrepancy seems like a solid one to me. I’ll share your topic with one of our smart meter experts, see if they can shed any light. 

Just FYI for anyone interested in this subject.

Attached is someone's submission to the House of Commons Committee on Energy Security and Net Zero. Obviously I can't vouch for detail so do your own research.

it contains some thoughts on the random offset and it's implications 

https://committees.parliament.uk/writtenevidence/123426/pdf/

I received a very detailed response by one of our smart meter experts:

This bit isn’t quite right as Half Hourly profile data does not 'exactly' match to meter readings, due to 2 specific reasons, UTC vs GMT and Randomised Offset.

No customer on a Smart meter is billed against their Half Hourly Profile data readings, they’re billed on the readings taken from the configurable Billing Registers for the periods in question. This then has a randomised offset applied to them that can make the offset anything up to 10 minutes variation. So the 2 are out of line but are explicitly based on the energy recorded through the metering. All of which must meet the tolerances set out to record energy in the UK.

So the key issue here is attempting to align the Half Hourly data to the meter reading (Billing) data, as they will not explicitly align, but we're not using them for billing purposes. They're for display purposes, so what Firedog is doing won't provide him the answer he wants or the outputs.

Please note this is nothing to do with accuracy of the device and all to do with confusion as to how the device operates. The data is accurate, the way it is calculated is accurate, but taking 2 separate data points, with different variables applied, and expecting them to match explicitly is what is creating this confusion.

So adding up the Half Hourly profile data to establish a value, and then trying to match that to the meter reading, will only work if you know the offset and how to apply it. But being the Half Hourly profile is not being used for billing, it's not needing to be done, it just gives how much energy was recorded in that Half Hour.

I knew your filing system would turn up trumps! Thanks for (re-) posting this ‍♂️

Hey @Jeffus,

Our smart meter expert has shared some information regarding the ‘written evidence’ you’ve posted. They advise although it is well meaning, there are inaccuracies which can be misleading. 

I’ll private message you a full breakdown of what they’ve advised as it’s rather lengthily. 

I don't need it @Emmanuelle_OVO

I won't read it to be honest.

I haven’t even read everything in the paper. Too detailed for me.

It was an edited paper published by a Westminster select Committee 

OVO are better off sending the commentary to the select committee rather than me.

That would be much more useful

Can you ask them if they will do that?

Else can I send their comments to the select committee and say they are from ovo?

The paper is nothing to do with me 

I’ve already sent you it! Apologies @Jeffus, you can just ignore my (very long) message! 

We've reviewed the document posted and would like to highlight it has many inconsistencies and inaccuracies so we would not recommend taking it as being something that fully describes some of the issues or as being fully factual. 

It’s worth highlighting that the paper is a view from an individual who has misunderstood some elements of Smart and has called out items that have either been misinterpreted or, unfortunately, not correct.

We’re happy to answer any queries or elaborate 

Sorry to have gone dark on you, but my slide rule overheated and I’ve had to give it a rest. I’ll be back 

 Right, now we have all of January’s data in hand, I can try and debunk what the expert says 

We know that billing depends solely on the meter readings, regardless of what the usage data may show, especially when viewed with reduced precision at account.ovoenergy.com or in the app.  

However, the expert writes “… the key issue here is attempting to align the HH data to the meter reading (Billing) data... as they will not explicitly align...” Well, in my case, they do align as regards the total usage recorded by the meter. Here is a comparison for the past 92 days, conveniently 1 November 2023 - 31 January 2024:
  

Here we see that the reading after three months can be predicted exactly by aggregating the half-hourly figures for the period - the difference between 390.130 and 390.131 is of course insignificant. This is just what I would expect from a precision instrument like a modern smart meter, and I don’t understand why the expert says that usage data and register readings won’t align.

What I can’t find a rationale for is the variance in the peak/offpeak usage figures. The expert gave two reasons: the BST/GMT dichotomy, and the ‘random offset’ that varies the peak/offpeak switching time to protect the electricity network from intolerable surges. 

• BST/GMT - that’s why I’ve chosen a quarter starting on 1 November, because it’s wholly within the GMT period. So we can rule that out as a factor for now.
• Random offset. I rather thought that this was meter-specific, built-in from the factory, in which case it should be a constant number n of seconds for any individual meter. If this were skewing the peak usage/readings, I’d expect to see a constant difference, of n seconds’-worth of use at the 00:00-00:30 draw rate in my case. I don’t: the difference appears to be completely random, varying between 3Wh and 35Wh, but usually less than 15Wh and averaging 11Wh, always over-reporting peak usage. I can’t see any reason for it other than perhaps a minor variable delay in submitting the reading. 
   

Bottom line: it’s quite possible to construct a missing meter reading by summing the half-hourly usage figures since the last known reading and adding them on.
  

PS In case anyone wonders, there are 9 missing half-hourly usage figures, from one day in December where there were two power cuts. I was pleasantly surprised to see that the meter register and the Hh data still matched precisely that day. 48 Hh x 92 days = 4416 - 9 = 4407.

Hey @Firedog,

I’ve managed to get a response from our smart meter expert: 

Randomised offset is applied to all configurable registers. The registers used for Billing. It is a singular thing. A random number is generated by the meter at the point of it being energised and configured. That value (which is between 0 and 1) is then multiplied by the parameter set by the Installing Supplier, which cannot be less that 600 seconds and more than 1799 seconds... This function must be done as it's a National Grid requirement and set out as an explicit obligation upon us. Also, it cannot be changed once set. The same value will be applied to every configurable register.. it was decided it would not only apply to load switching but any instance where a tariff changes whether load is linked or not.

So to answer the query stated, the offset of 5 minutes would apply to the start and finish of the period... so a 7 hour off peak, would commence at 00:05 to 07:05.. but, as it's in seconds, it may not be exactly 5 minutes.. it may be 4 minutes 43 seconds.. or whatever the random value generated made it to be.. hence the fact that attempting to align the HH Profile data to the Billing data generated from the configurable registers is always 'out'. It's not incorrect or inaccurate though.

I really ought to have responded to this long ago - sorry!

We’re repeatedly told that the Hh data won’t ever align with the meter advance when a randomized offset is involved. You can’t expect the difference in readings timed at 00:05 on two consecutive days to equal the total of Hh usage from 00:00-00:00 on the first day, because the offset only applies to the registers and not to the Hh buckets.

This doesn’t tally with my own observations. These two figures - meter advance and Hh data total - match precisely (±1Wh) every day, remaining ±1Wh over a period of days, weeks or months.  The meter readings (peak and offpeak) are taken from the account website and their sum checked occasionally against the IHD, which helpfully shows total import to the nearest Wh. There hasn’t been any discrepancy in the life of this meter. Hh data are usually taken from DCC via n3rgy, again checked occasionally against OVO’s own API. Again, I’ve not noticed any discrepancy.

I can only assume that the first half-hour starts at exactly the same time as the meter register, contrary to what we’ve been led to believe. How else can this precise alignment be explained?

The part I have difficulty with is the recording of peak and offpeak usage by the meter on the one hand and by the Hh data on the other. Here, there is a discrepancy every day, which I’m happy to ascribe to the offset. Of course, if there were perfect alignment, there wouldn’t be any discrepancy at all. So I’m inclined to think that the offset is applied at the beginning of the day, but not at the end (in my E7 case) of the offpeak period. If the difference were random, I could accept it. But it’s not - the offpeak register advance is always a little bit less than the total of the corresponding 14 Hh figures. The peak register records the same amount more each day. In my case, it’s about 8Wh a day, so insignificant for me in money terms. I suspect the difference would be much more for a meter with a randomized offset closer to 30 minutes. Added together for all of OVO’s E7 customers, it could amount to a sizeable sum.

I wonder if your correspondent could show me the error of my ways, if I’ve got it all wrong again.

Hi @Firedog,

I’ve managed to get a response from our smart meter expert. They’ve said:

“The randomised offset can be zero. It’s a random figure that is generated by the meter between zero and 1, so if the meter generates a figure of zero (randomly) it will apply an offset of no seconds but it’s different for every meter. There will be some with none but that is purely random. In those instances, the alignment is there but can’t be relied upon as a rule as it all depends on the value the meter has generated.”

Hopefully this helps.