Anyone else see nonsense gas usage like this?
I’ll pass this onto the correct team, @Transparent, leave it with me for an update, I’ll be back with you ASAP!
Hi ya’ll, hope everyone is coping well with storm Brendan or whatever this one’s called….
Update on this: @102530130 @Not_so_smart we’re aware of this issue, still at the diagnostic stage, but billing will be unaffected!
It seems as if when the issue occurs, instead of returning a null value or an N/A the fields populate the maximum available volume which (when used in the m3 to kWh calculation) generates this spike. Not ideal!
If you could update us on this when anything changes, I’ll liaise with the team working on this fix!
Just to say I have the same problem of occasional erroneous readings on my daily gas chart of 188250.98kw. These then obscure the actual trends as the kw scale is so large. This has been the same since my new smart meters fitted Dec 2919. The electric graphs are always fine.
We’ll do our best to keep you updated, @102530130
Hi @Tim_OVO, @Amy_OVO
A week has now passed since the last 188250.98 kWh value appeared in one of my day usage charts (gas, on 10 Jan 2020), so something somewhere is working better than it was.
If someone has fiddled with the protocol for transferring data to make it a little more patient, by increasing the timeout, or the max attempts made to make each transfer , or whatever they’ve tried, well done. Or maybe the error just happens randomly and I’ve had a lucky break.
I wonder if @Not_so_smart is still seeing errors?
Have a good weekend everyone.
Also looks like my data is now fixed. No erroneous gas readings since 10th Jan. Well done OVO for sorting this.
That gas consumption is equivalent to 9.5 m^3/sec or 270km/sec in 22mm pipe. Some 400x faster than Concorde!
FWIW here is my best guess at what is going on. The database is storing volume consumption figures in litres in a 24 bit unsigned integer. There is an uncaught divide by zero producing a maximum value in this field 1677215 convert to m^3 => 1677.215 apply standard volume correction figure of 1.02264 => 17157.0511476 divide by 3.6 (convert from MJ to kWh) => 4765.847541 Then apply a fixed?? calorific value of 39.5 => 188250.9778695 kWh Which rounds to the 188250.98 displayed figure. I did look up UK daily calorific values and 39.5 was a valid value for some of the highlands and islands, but not for the majority of the UK. So I wonder if the graph uses a fixed compromise value of 39.5 rather than actual daily figures for the region.
OK… so two bits of feedback:
Firstly for @whitehouse - when looking at payback times for EV chargers and other energy-saving technologies, please bear in mind that we’re moving towards a domestic energy strategy called Demand Side Response.
This means customers will increasingly be offered a Time Of Use tariff (ToU) with variable pricing based on half-hour time-blocks.
If you opt for such a tariff, you will be able to have more control over when you charge your EV and use other high-energy household appliances. This will affect your payback period.
There’s other Topics on this Forum where we’ve discussed Demand Side Response, and you should see more about ToU tariffs over the next few months.
Secondly, on the subject of the Calorific Value for @NoPoke’s calculations; I’ve just received an excellent response from my GDN, Wales & West Utilities.
I’ve been given a number of documents to read online, and introduced to the concept of Wobbe Numbers. So I’ll have to do some background research into all this.
However, WWU included the following graph showing Calorific Values in my Region (SouthWest) over the past two years.
This should enable us to make a better guess as to the range of CVs which OVO’s programming team may have allowed for.
CVs will be gradually falling in the future as new legislation allows to more bio-methane and hydrogen in the mix.
I’ll return to this again once I’ve done my homework!
DSR sounds interesting. As a simple soul I simply intend to charge while the sun is over the yardarm and my panels are producing magic pixies for the picking - for me this will be mid afternoon may - october.
When I first ran the numbers I factored in a charger with all the bells and whistles that could talk to solar, ev and my phone - as I said it soon became apparent that the registered installers required by DVLA in order to be eligible for the £500 subsidy saw that figure as their starting cost point. Also seeing that an EV has an initial purchase subsidy too, they’ve also decided that they should be entitled to a “fair” chunk of that too. When any cash-cow is crossed with a golden goose - the only certainty is the prices will inflate to quite silly numbers and £2000 isn’t rare for a very basic install. So that subsidy isn’t quite the boon it looks to be
The T&Cs say they will provide your external wall mounted charger with the shortest surface fixed cables they can.. I wanted mine INSIDE the garage which is where the car usually sleeps. It seems obvious that if the crimms are eager to cut down anything made of copper however high the voltage it carries - as EVs become more popular - so will the easy money option to “harvest” those domestic wall chargers, external cables and flex as the car sits conveniently (and visibly) on the driveway tethered to a big chunky length of copper over night!
The car has an inbuilt timer and there is a nissan app - so with a little thought its easy enough to set that to fire up at whatever time is required without getting wet.
It took a day to dig a trench and lay duct - I’ve upgraded the garage, added a wireless access point that covers the garage and garden too and it’s all under lock and key.
Not a fan of hydrogen. Has a very wide flammability range (much wider than methane) and requires very little energy to ignite (an order of magnitude lower than methane). Hydrogen is also four times smaller than methane so much more likely to leak from the system.
Very odd - has anyone else seen this?
It is a) still showing this for that specific day, and b) showing anything odd for other days @102530130 ?
ps you might want to change your username to something else
Yes, since smart2 meters were installed on 16 Dec 2019, every day has some half-hourly usage values that are 188,250.98 kWh except for 17 Dec, 1 Jan, 3 Jan, 4 Jan. 22 Dec only has data for 0:00 hrs and 0:30 hrs and has “No data available” for every time after that. 16 Dec just has “no data available, perhaps not surprisingly since that was the day of installation. There are other days that have “No data available” for some time(s) including 0.00 hrs. (this seems to confuse the web page navigation from one day to the next/previous, and one has to come out to the month chart and select the day from there, on order to see the rogue values).
meter readings are mostly ok, except there are no readings for 23 Dec and 17 Dec, but I think I said that already.
PS I’ll change my username when I find where to do that...
To clarify slightly, the navigation within a day usage chart to the previous day is greyed out if and only if there is “No data available” at 0.00hrs. This happens in the gas day usage chart more often than in the electricity day usage chart.
Hi Simon…. great Topic. Thanks for raising this!
I too am noticing some “interesting” half-hourly readings for gas:
These readings of zero don’t appear to be valid.
I have a Thermal Store, for which the only overnight input is currently a gas boiler. So I expect to see a steady use, undulating around 1kWH to 1.6kWh, like the graph on the left:
The figures in the table above actually produced the graph on the right.
As the Usage Pages we are viewing are newly released to the public, I would expect all sorts of errors and incorrect data-handling.
I suspect that the readings of 188,250.98 kWh being reported by Simon are where the usage appears to be lower than the previous reading. Since Smart Meters report cumulative totals, the programmers haven’t thought to allow for such an anomaly, so the negative number has “wrapped around”.
I’m not seeing negative numbers, but I am seeing some which clearly shouldn’t be zero in the middle of the night. (The other thermal store inputs are solar, and we don’t get much of that between midnight and 5am !)
There are some possible explanations, none of which is fully satisfactory:
A: The Gas Meter failed the 30-minute link-up to the Communications Hub, which therefore reported a zero.
B: I had a number of power-cuts, preventing the gas boiler from firing
C: There is “missing data” in the stream obtained by OVO from DCC.
In the case of A or C, I would expect the next valid reading to be correspondingly high, which does not appear to be the case.
I can rule out B because I just happen to be a member of a Community Group which is monitoring the local electricity Distribution Grid. If there was a power-cut, then I’d see it on the graphs!
There isn’t a single “correct way” to handle data which is either absent or apparently wildly incorrect.
It might appear helpful to some users if incorrect data were discarded and the gaps filled in by averaging the next valid reading across the previous one. But this then prevents the usage graphs from showing half-hour slots where the usage really was zero, of course!
@Tim_OVO , is there any chance of getting a member of the relevant software Design Team to join this discussion?
The MyOVO pages are asking us for feedback, but we can’t send graphs and tables via the text-only reporting form which they’ve provided online.
Hi Transparent and thanks for those insights.
A small negative increment in a cumulative value being mistaken for the largest positive number (essentially, a confusion over whether the number has a sign bit or not) has a ring of plausibility to it. I agree that some comment from the software side would help - I feel that the underlying error may be almost diagnosing itself (including how that largest possible value turns out to be 188,250.98 kWh).
Fundamentally, the meter is measuring a flow, i.e. volume. I would refuse to accept any meter that reports negative increments in volume, however small.
So my hunch is that the problem lies in the conversion from volume (m^3) to energy (kWh). The conversion factor is temperature (i.e. weather)-dependent and so varies with time (like everyone, ovo has to use calorific value data provided by the regulator). There _is_ a way to use this varying conversion factor consistently, even if ovo’s code doesn’t achieve this.
By the way, the warning from ovo that I’ve read, about possible inconsistency between usage data and meter readings only makes me more sure that this is where the problem lies. (There really is no need for any such inconsistency.)
But that’s enough speculation from me.
@NoPoke- whatever we think of Hydrogen is unlikely to affect the plans to increase its presence in the mix. Unlike Methane, it is a zero-carbon fuel.
Moreover, using spare renewable electricity, which would otherwise be discarded, to create hydrogen from water makes economic and environmental sense. It costs very little to send gas through the grid-pipeline hundreds of miles to where it can be used.
Contrarywise upgrading the electricity National Grid to accept that excess renewable generation would cost £billions, and about 15% more energy would be wasted in grid losses.
See The Engineer article about Scottish Hydrogen Storage Project, Oct 2019.
PS regarding @Transparent’s dropouts - depending on how the thermal store control system is set up, it strikes me as quite plausible that the boiler really could spend periods of 30 min or longer without firing up at all. (At 2-3 kW on average, I think the boiler would be burning gas at most 30% - 50% of the time (c.f. the peak at 9am). Maybe stay up late one night and observe it?
Our gas grid is constrained too. https://www.nationalgridgas.com/data-and-operations/constraint-management Adding Hydrogen to the methane reduces the calorific value and will thus increase the volume demand on the pipes. The exact opposite of what you would wish as this acts to decrease capacity.
Erm @NoPoke - the Scottish project I referred to is for Hydrogen Storage.
The team are to investigate the viability of storing hydrogen when renewable energy is in abundance, then use it when there is a deficit. Thus it evens out the fluctuations in renewable generation.
Most of these gas-generation strategies are intended for use within the Distribution Grid rather than sending through National Grid pipelines.
Thanks @102530130 . I designed the control systems for my thermal-store inputs myself, so I’m pretty sure it can’t have two consecutive half-hour periods with no gas boiler firing!
If we’re going to help OVO’s software engineers to better present our data, then I think we need the on-screen display to provide two additional bits of information, apart from just a raw figure. In order not to confuse the vast majority of other non-techie customers, I’d suggest this is done by subtle means.
That will help us track down what’s happening and provide useful feedback.
For the sake of comparisons: the pseudo-minimum Calorific Value of mains gas is 37MJ. That’s what would be used to calculate our bills if there was a problem with measuring the actual CV.
The equivalent CV of Hydrogen is 12MJ.
The amount of hydrogen permitted within the mix is fixed by legislation in the Thermal Energy Regulations.
Control systems are fun - and I won’t get sidetracked by that discussion ;)
They sound like good suggestions re diagnosing the data/display problem, let’s see if they’re interested.
I’m aware of what might be another level of awkwardness with the smart2 setup - don’t the readings get to ovo via some vendor neutral intermediary? Maybe some of the processing is out of ovo’s hands…
fwiw, my issues are cropping up in the old version of my ovo (but I’m a little familiar with the new version, and recognise it from your screenshot).
We can get side-tracked by energy control systems on a different Topic if you want!
Yes, there are other parties involved in the communication links with SMETS2 meters. I uploaded a simplified diagram here on another Topic a year ago.
I’m assuming that DCC pass on the raw data to Energy Suppliers. So I’m hopeful that there is still a flag set where data is absent rather than being zero.
This is vitally important to the forthcoming Time Of Use tariffs, so it needs to be adequately researched and categorised now, whilst it has no financial impact on customers.
To illustrate this I’m borrowing my Gas Usage graph from last Saturday, but we’re going to pretend it actually shows my Electricity (green line).
I’ve added a Yellow line to show the forecast solar radiation for my area (Southwest), as it might be used as an input to the Kaluza Platform.
The Brown line depicts the rise and fall in the cost per kWh which my Time-Of-Use tariff offers me, and I therefore choose to turn on my immersion heater automatically between noon and 13:30 to make use of the lower price.
However, if there are missing readings from my meter during this period, the usage is incorrectly being assigned to the slot 13:30-14:00 and I then get charged at the standard daytime rate.
@Tim_OVO - are you following this?
Do you now see why we’d like one of the software design team here?
The handling of “missing data” is of crucial importance.
Thanks @Not_so_smart - so I’m not alone. Sounds like at least two of us see this behaviour.
Over to Ovo ...
Ask your question, the answer will help you and others
Already have an account? Login
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.