Can I switch my smart meters to half hourly readings?

Interesting point @pheo ... and @Nancy_OVO has given an answer which is derived from OVO's current position - which will change.

Firstly, let's note that SMETS2 gas and electricity meters are able to take readings at intervals of less than 1 minute. That's why your IHD gets an updated electricity reading every 20 seconds.

In order to prolong battery-life, a SMETS2 gas meter is normally programmed to send its data to your Communications Hub every half-hour. But, even so, it's still sending 30 readings each time.

The electricity meter has no such constraints and can send readings every 20secs to the Comms Hub whilst simultaneously keeping a record of the cumulative total per minute.

Bizarrely, each separate Energy Supplier
is permitted to download their own code variations to

• the Comms Hub
• the Electricity meter
• the Gas meter

There is no universal agreed code, provided that it still obeys all the SMETS commands.

So OVO's present position is that they send a meter-read request to your Comms Hub shortly after midnight. This request generates a response which gives the totals for each of the two meters at 30-minute intervals during the previous day (referenced against UTC/GMT).

OVO receive this customer data from the BOL - a software interface agreed between them and the Data Communications Company. Only DCC actually transfer commands and data to/fro your SMETS2 meters, and this uses a secure system with encryption and public-keys.

OVO use this half-hour data to display the previous day's readings on your My OVO page as a histogram.

That's an entirely different scenario from actually using half-hourly readings to offer a Time-Of-Use Tariff. There are many customers eagerly awaiting such a contract to be announced.


Does that help to explain the chunkiness of your gas readings?

If not, then can you provide a clearer explanation (with usage data) so that we can have a more-informed discussion?

There may indeed be a problem with displaying readings when usage is low. But unfortunately I can't comment on this first hand because I'm one of the customers currently experiencing software faults on both my SMETS2 electricity and gas meters!

Thanks @pheo - this is just what we needed.

I've already emailed a member of the SMETS2 Team to alert them of what you've posted. This is an issue which hasn't previously been raised on the Forum. So you get a Gold Star for being the first! ⭐️

I need to do a bit more research, and I'll then post here what I think is happening.

I'll leave this in your more than capable hands, @Transparent, thanks for emailing the team on @pheo's behalf, heartwarming to see such great peer to peer interaction! 😊

Woohoo I get a gold star!!

(oh, no, hold on I broke it!!)

Im a product manager by trade btw, so I feel for the SMETS2 team right now 😉

OK @pheo - let's put you more in the picture about what's happening here. And please remember that Ben from the SMETS2 Team is able to read this Topic. The feedback we are giving here may have an effect on how OVO develop a future Time-of-Use Tariff.

I think the issue we're seeing on your gas histograms is resulting from missing readings.

That's fine. Any monitoring system will experience occasional missing or corrupt data. It's how we handle that which becomes important.

We've been evaluating the same issue in the OpenLV Project for which I'm in one of the Community-based Teams monitoring 11kV substations.

In our case we are receiving "live" data covering 146 different parameters. A missing 30-minute reading can't just be written off as "zero" because that would affect daily averages and our comparisons of usage patterns. And in may cases, taking the average of the two adjacent readings may be equally unhelpful. It all depends what we're trying to analyse.

It's slightly easier with a Smart Meter because the readings are cumulative. Even if there's a missing set of 10 half-hour readings, it would still be almost acceptable to apportion the reading from hour-10 across the preceding 9 empty slots.

The crucial point is to ensure that the mathematical corrections are made at the very last stage in the process. So if the data is to be used to generate a usage histogram on a customer's web-page, then it is the graph-generating software which applies the algorithm to "restore" missing data packets.


If this was an electricity meter presenting missing data, then we'd have reason to be much more concerned. Unlike gas, there is a clear strategy unfolding in which we will have Time-of-Use (TOU) Tariffs with electricity pricing varying each 30-minutes.

The issue with missing gas readings is also slightly complicated by the fact that a SMETS2 Communications Hub has within it a proxy gas-meter referred to as the Gas Mirror.

The Mirror exists in order to reduce the amount of traffic across the HAN, and hence extend the life of the battery in the actual gas meter.

What we can't tell from the Usage graphs which you've supplied here, is whether the missing data really is from the gas meter itself, or whether there is a deficiency in the code which operates the Mirror. And that's where OVO's SMETS2 Team will have to check it out.


So - why is it important that we discuss this now?

As SMETS2 meters get added to the National Smart Meter Network and more Energy Suppliers start issuing data-requests at half-hourly intervals (instead of once per 24hrs, as at present), there will be 3rd-parties who need to extract some of this data to use for other network-management purposes.

For example the regional Gas Distribution Network Operator (GDN) will be able to amass data showing them when there are demand peaks. Patterns will start to emerge, showing how temperature affects gas demand for central heating.

Currently it is only your Energy Supplier who issues Data Read instructions to customer meters. So GDNs can only access data which is help (in trust) by DCC, and amalgamated into geographical bundles.

Missing data could create problems for such 3rd parties. They need to know that no Energy Suppliers have tried to fix the issue by interpolating missing-reads within the Comms Hub software (the Gas Mirror) or filling the fields with zeroes, because this could create significantly unreliable data.

I hope that makes sense.

@Transparent yep perfect sense. The other thing which could cause a problem, as you allude to, is aggregation happening in he middle, e.g if the electricity meter is summarising and providing a single read once every 24 hours, and that isn't at a sufficient level detail, or is rounded, it could be creating this effect because we have insufficient precision.

It would concern me a bit if the meter was repeatedly failing to send readings; they're not far from each other, and you would think it could reattempt a couple of times a day, or alternatively, hold all the readings and dump them once it makes contact successfully (I'm assuming here there is two way comms with confirmation of receipt and parity checking or similar.

I've also still not got the IHD, so I can't use that to try and get some additional data from the meters (I think I'm right in saying they communicate directly) to try and validate.

I'm presuming there is nothing further I can do to validate / debug / provide logs at this end given everything is secured but do let me know.

@Nancy_OVO is there a significant delay in IHDs going out for new SMETS2 installs? Otherwise, is it possible to check on the delivery of mine? This might help get the team a bit more info.