How is data recorded on the online graphs and tables?

I’d also try to rule Hive out, or identify it as a possible culprit. Google tells me that Hive operates on Zigbee channel 20, around Wi-Fi’s 2.4GHz channel 8-9. My own Wi-Fi always defaults to channel 9 (2.442-2.462 GHz). 

It’s not just Zigbee or Wi-Fi signals that interfere with each other. Any electrical equipment will emit EMF radiation, usually within prescribed anti-interference limits, but even lower-energy signals can interfere with others on the same frequency. It could be something entirely different, apparently innocuous, that just happens to be emitting low-power radiation at an awkward frequency. I don’t know of any foolproof technique for checking what’s going on in your EMF space.

That actually clears up why my gas usage always seems to show up 30 minutes 'early' on the charts. It's a bit unintuitive at first, but knowing it's just a timestamping quirk rather than a meter error is a relief. On a side note, I’ve been trying to keep a manual log of my monthly statements and project docs to track these discrepancies over time. I found a handy tool recently, https://wordimageextractor.com/, which is great if you ever need to quickly pull graphs or charts out of those long Word-based energy reports or project summaries without messily screengrabbing everything.

Anyway, I’ll keep an eye on my next '30-minute window' and see if the offset matches up with what you've described.

Obviously I am late to this thread so don't have anything much to add.

I don't look at the detailed readings any more.

I do remember I regularly use to get drop outs of gas readings, but my gas and electricity meters are quite far apart with solid walls in between so it is understandable for me. 

My main reason for starting this thread was to highlight two of the problems that I had with the recording of my gas data and how they would impact on my ability to take advantage of the “A little help with your heating initiative” (now finished). This was a “time of use” initiative and, as you can see from their final answer to me the known issue of the “data shift” with gas “can indeed make precise real-time management of usage for specific initiatives challenging,” Precise two hour slots were offered for this. One of the offered two hour slots each week out of three was not one I dared to choose as it fell in the period that I most regularly had no data recorded. On 6 out of 15 days, so far, this month I have had no data recorded for my usage in the 10.30pm and 11pm time periods. In almost every month, these two time periods are the only ones that have no recorded data. I would expect a DCC problem to be more random. The main focus of my case was on these two issues. Given that missing data and “data shift” problems appear not to be unusual, I still question why this initiative was not better thought out. This is especially true as Electricity ONLY customers were able to choose a slot and, without any other changes to their energy usage, were able to receive the equivalent of the cost of 10 kWh of gas for their area as a reward each week. Despite trying to second-guess the “data shift” in the slots I chose, I was not successful in being able to claim that 10 kWh (restricted to 5 kWh per hour) reward in any of the ten weeks!

While catching up on various threads, I came across this and am rather confused .. although appreciating that ​@Bendog has accepted an explanation.

My confusion arises as each data chunk from the smart meter should have various details, including the timestamp relating to each half hour record. Yes, the transmission of the 30 min record might not reach the comms hub at the end of the 30 min point (mine is delayed by up to 15 min) but it should still contain the information required to be accurate. Drop outs are a different item and can indeed occur from time to time, particularly on gas - the meter is often a distance from the comms hub and subject to any transmission difficulties while sending its data.

The explanation from OVO therefore doesn’t make sense and although TOU considerations are rare for gas supply (in the UK), smart meters are built with this consideration. Of course, the time of the data arrival can/does differ from time of usage and so manual intervention is required (this is often the case for electricity data, when out of line with ‘meter’ time).

The full answer may well therefore relate to an earlier point made in that gas is seen as secondary to electricity by suppliers and therefore beyond general accuracy checks for daily/monthly usage, they are mostly uninterested … which begs your basic question that why would an incentive be offered if it could not be validated easily .

​@Bendog  I’m sorry I missed this. I try to look at every new post in the Recently active list, but sometimes - like now - I discover posts that I’m sure weren’t there when I looked earlier.
    

It’s a bit sad that, given the complexity of the electronic innards of gas meter itself and of the GPF at the other end of the connection, it’s not possible to assign an accurate timestamp to a metered quantity. If you’d like to delve into that complexity, you could waste a few hours ploughing through the specifications! This is just the bit for the GPF (Gas Proxy Function) in the comms hub: https://smartenergycodecompany.co.uk/documents/sec-subsidiary-documents/sec-schedule-10-communications-hub-technical-specifications-v1-7/

Did your little experiment with changing the Hive heating control timing reveal anything?

It changed nothing. From 1st - 16th January, no data was recorded for the 10.30pm and 11pm slots on seven days. I am just assuming that, if OVO decide to try something similar for gas users in the future, it might be better thought out. To use the same model for gas as they used for electricity, given that the data recording and data shift issues for gas users are not unique, was, in my view, a poor decision. However, I believe that it was, in fact, a failed experiment. one they are unlikely to repeat. 

Thanks so much your feedback on this ​@Bendog - very much appreciated.

OK - it’s always good to be able to rule things out when troubleshooting! 

I’m still inclined to believe that this strange error is nothing to do with OVO, and almost as confident that DCC isn’t at fault either. If I were determined to get to the bottom of it, I’d be asking Landis & Gyr’s tech support whether they could shed any light on it.