Partially scrambled half hour data- Got an EV

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.

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 👀

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. 

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

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!