Partially scrambled half hour data- Got an EV

Further information: It’s not daylight saving time. In a sample of 27 charging sessions that spanned midnight the data is:

Correct = 13

Missing = 2

Displaced -1 day = 10 (data is 24 hours before it was supposed be logged)

Displaced +1 day = 2 (data is 24 hours after it was supposed to be logged)

So it’s not even consistent. So overall the energy used has mostly been accounted for, but the data moved and only on two occasions was the data for 2 HH periods actually lost so it appears I’m better off by about £1.20. Make of this what you want for the accuracy of smart meters.

Hi @Peter E

Out of curiosity have you seen much/any  difference between the daily total extracted from the meter reading page vs a daily total from summing up the 30min usage on the usage page

https://account.ovoenergy.com/meter-readings/history/electricity

https://account.ovoenergy.com/usage?datePeriod=daily&unit=kwh&fuel=electricity

OVO doesn't use anything on the usage page for billing and the 30min slots are not added up to make a daily total. The 30min data isn't used for billing. You may already know all this. 

@Jeffus Thank you for the point about double checking that the HH and daily rates agree. I also checked whether the monthly billing value was right and they all agree to within a small margin. Apart from the graph which at times looks like a random collection of values (during a power cut) everything presented as values appears to be correct if not actually in the right place.

@Firedog Thank you for the insight into BST/UTC. I don’t think it works consistently but it seems Ovo collect meter readings which are accurate but they sometimes have problems knowing what to do with them but in the end they manage to slot them in somewhere so that the total bill is correct. It will be interesting to see what happens when we go back to GMT. Having done the check that @Jeffus suggested I’m happy the bill is correct but the presentation of the data is a bit haphazard from a user perspective. Thank you @Firedog  for the links to the other resources. Always interesting to explore these.

@Firedog You mentioned the possibility that I had incorrectly copied across the wrong information (which got me to double check what I had done).

On the 29th I charged the car in the early hours but not late at night going into the 30th.

For the 30th it supposedly shows an isolated 1 hour of charging starting from midnight. The car definitely wasn’t connected to the charge point.

Later on on the 30th I started a charge late afternoon going through to about 2am on the 1st Oct but there is supposedly a gap from midnight to 1am on the 1st Oct. This gap is not backed up by SMS messages to say the charging had stopped and started and the charge would have been about 5% short of what I was expecting from the SoC on the battery and it wasn’t. This is definitely data being moved to different slots possibly because of the UTC/BST issue but the data overall is correct.

OK, I see your point and agree that this isn’t right by any measure. It looks as if the figures labelled 12:00am and 12:30am are the ones that belong at the other end of the day. For most customers most of the time, this would make very little difference since usage tends to be both low and consistent at that time of day, and even within the rounding error from three to two decimal places, if your meter is capable of reporting to the nearest Wh. For what it’s worth, I can see the same phenomenon on my own account pages, so it looks as if this is a simple coding error. The histograms and tables are showing all the right data, but not necessarily in the right order as regards the interval around midnight.  

You could establish whether this is what’s happening by looking at other sources of what should be the same data. With a bit of legerdemain, it’s possible to see the data OVO are using to construct both the histograms and the tables on the Usage pages. Another possibility is to access the data your meter transmits to DCC via a third party; I use n3rgy, because as far as I can tell the data are not embellished in any way, and the timing of each half-hour slot is given precisely.  I’ll post the instructions for this method below once I’ve found a moment to work through them like a complete novice. Watch this space 👀

@Peter E

These sort of chats use to go on a lot over the years when @Transparent and @Simon1D were around, two very knowledgeable posters. 

This is just one example and including chats about gas and electricity albeit not what you are seeing. 

There may be some useful info on their posts over the years. 

I’ve now satisfied myself that what you spotted is indeed a silly website coding error. The two first entries in the table are those for 23:00 and 23:30 UTC on the day specified instead of the ones for the previous day, shifted by one hour for BST. This happens for every day. I don’t know whether this is new, or whether it’s always been like that and I just never noticed.

Here’s just one way of retrieving your raw smart meter data, ready for you to examine and manipulate in, say, Excel if you’re so inclined. You’ll need to know your MPAN (the unique identifier of your electricity supply) and the UID of your IHD (this isn’t published anywhere and so identifies you as the user whose meter data you’re accessing). The MPAN is shown near the top of page 2 of your bill, and the IHD UID is usually on a sticker on the back or bottom of the device, or if that’s dropped off, it will be given somewhere in the device’s settings. It consists of 16 hexadecimal characters often displayed in pairs.

Armed with these IDs, visit n3rgy.com and satisfy yourself about their integrity. Click the I’m a consumer button to get started; there’s a Consumer Sign up button at the foot of the next page. Follow the prompts to set up and verify your account.

Now visit Smart Meter Reports (guylipman.com) and follow the links to load data from n3rgy. While you can happily use Lipman’s own visualizations and figures on his Consumption pages, I prefer to download the raw half-hour data as CSV. In your case, you could take the three days shown in your screenshots; once you have the CSV, you should easily spot where those rogue bars came from by comparing the UTC and BST timings. 

I don’t think I’ve ever looked forward so much to the clocks changing as they will do on Sunday. What I need to do is put a ‘marker’ on one of the peripatetic HH periods so that it is something other than the background level, like put the oven on just past midnight for 15 minutes. However, if I do that my wife is bound to ask me what I’m doing and will probably have me certified and taken away.

‘Certified’? You’re showing your age!

I was convinced of this fault by happenstance. A couple of days ago, I had to call for an ambulance to take me to hospital. As instructed, I unlocked the front door and switched on the outside light. They duly turned up and took me away, and I didn’t get home again until the following day (luckily with no lasting health problems). I checked my IHD and saw higher-that-expected usage while the house was empty. Of course, in the panic surrounding my departure, I’d forgotten about the outside light, which I discovered had the only non-LED bulb in the house, a halogen monster. So that night showed a constant ~80W draw instead of the usual ~50W, but the OVO usage chart moved the last hour’s usage for that day to the previous midnight. 

I don’t think you need to undertake any sort of certifiable activity to establish the fault - your usage histograms illustrate it very well.

PS I cannot get used to this silly (American?) sequence. where 12am comes before 11am instead of following it. 12 o’clock is neither AM nor PM - it’s just M. I wish OVO would use the 24-hour clock and take the objections on the chin until everyone has got used to it, like we’ve had to do with train and plane times. I suspect that this fault wouldn’t have arisen if the table started at 00:00 - 00:29 and ended at 23:30 - 23:59, as it does in the underlying data.

Rather than waiting for Sunday I went and retrieved some data from earlier in the year and it is definitely a UTC/BST issue. You can see the anomaly appears after the 26th March. The blank lines are missing data. At least I can work out where the data is now.

Nice! 

The missing data for the end of the quarter was a long-term known issue, which has now been resolved, we’re told. It’s anyone’s guess why you’re missing data for 15 April, though. But your displaced pink cells appear to illustrate the problem very effectively. Thanks!