Anyone else see nonsense gas usage like this?
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.
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?
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.
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.
I’ll pass this onto the correct team, @Transparent, leave it with me for an update, I’ll be back with you ASAP!
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.
Thanks @Not_so_smart - so I’m not alone. Sounds like at least two of us see this behaviour.
Over to Ovo ...
Thanks @Not_so_smart - that’s very useful feedback. So the figure of 188250.98 must surely mean something to an OVO SMETS2 engineer.
I was also intrigued to see when your Smart Meters were installed:
“This has been the same since my new smart meters fitted Dec 2919”
I’m afraid mine were in situ 900 years before yours, so they’ve probably had enough time to sort out erroneous readings by now.
I also noticed that @Not_so_smart and I had our meters installed at similar times (16 Dec in my case). FWIW, my 188250.98 kWh readings are still occurring intermittently on most days, but not all. And they crop up at some times when I know our boiler is burning, and at other times when I know it isn’t (nothing else uses gas, so I do have zero gas flow for hours at a stretch). Sounds like data miscommunication to me, rather than an erroneous “zero”.
Since each day’s data appears all at once early the following day, rather than reading by reading during the day, and the errors usually occur in clusters, I do wonder if the error rate in data transmission from gas meter to electricity meter is just beyond what the error correction algorithm can handle.
I can see where you’re heading with that analysis @102530130.
However the Zigbee link to the gas meter doesn’t operate like that. There’s a “gas proxy” inside your Communications Hub which is always available for interrogation when a SMETS command is sent by DCC.
The Gas Meter itself therefore only sends data to the gas proxy. I don’t like that arrangement. It means that the LED indicator on your Comms Hub can remain flashing at the slow rate, suggesting all is OK, when in fact there has been an interruption in data being sent from the gas meter. Ie it gives a “false positive” indication.
I see no reason why the behaviour of that indicator couldn’t be changed by a software download from the Comms Hub manufacturer. It might help to isolate the sort of fault we’re now discussing.
What we really need is a medium flash sequence to indicate that it’s attempting to make the connection.
I’m tagging @BenS_OVO to make sure he sees this comment. But he and I have discussed this previously, so don’t expect him to respond here.
Thanks for the insight @Transparent - as is obvious, I have a very naive interpretation of what I see, and no knowledge of what might be going on behind the scenes :)
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!
Erm @Tim_OVO I think we’d like a more detailed discussion than this please!
Simply having programmers “fix” the issue in-house isn’t the answer. I think we ought to be discussing the wider subject of how to handle missed readings, erroneous readings and zero-readings.
We also ought to have an option for a customer to “reject” a wildly inaccurate reading from their online graphs. Otherwise it will screw up the stats for months to come!
Thanks @Tim_OVO . The only change I’ve noticed (since the weekend) is that the day usage charts now say
Sorry, there is no data available for this period right now. Please check back again soon
I already assumed that they’d been turned off pending the implementation of some fix.
I look forward to reporting behaviour when it changes (a prod to have a look when a fix has been put in place wouldn’t go amiss ;-)
We’ll do our best to keep you updated, @102530130
I’m not sure if I should be concerned that the result of the conversion to kWh doesn’t reflect actual calorific value on the day (it is always the same). Maybe only a nominal value is used, and _this_ is the reason for the “usage data may not match meter reading/billing data” warning that I recall seeing (but can’t find anymore).
BTW I see the day usage graphs are back, but large values haven’t been fixed.
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.
What about your online graphs @102530130 and @Not_so_smart ?
Have the erroneous readings been removed from there so that the trends, usage comparisons and monthly averages will be correct?
What has replaced those very high readings? A zero, or an apparently correct reading?
@Transparent - there’s been no change to the historic data (pre 10 Jan) shown on my usage graphs. It was only ever the half-hourly gas data that were sometimes garbage, and eg monthly usage graphs never had obviously bad data, so I doubt that comparisons will ever be wildly out.
There also used to be missing data (quite often on the gas day usage graph but only once on the electricity day usage graph). For example, all values from 00:30 on one particular day to 00:00 the next day show “no data available” - this seems to have caused that day’s values on the week and month usage graphs (gas and electricity) to be just copies of the previous day. In this case, the month usage graphs do have bad data, but it’s not “obviously” bad. (The lists of meter readings both have a gap for that day too.)
I note that the day usage values shown on the week and month graphs never exactly matched the sum of the half-hourly usage values on the corresponding day usage graph. Certainly not when the day included any values equal to 188250.98 kWh.
If we’re getting into requests of ovo’s programmers, @Tim_OVO, mine would be for there to be a second pass over the gas usage data - by all means use a nominal figure for the calorific value in showing the most recent gas usage (I suspect that’s what happens at the moment), but go back and update older usage data as soon as the actual calorific values are made available. I think that any inconsistency between statements/billing and usage graphs would then be only temporary.
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.