Off peak times inaccurate.

Netexporter

7 hours sounds very much like the time difference in China, where the meter was probably made.

Chris_b2z

Another MSE user noticed this problem after the installing engineer incorrectly set the time as AM instead of PM resulting in a 12 hour offset. In my case it was correct originally but just suddenly changed overnight.

These two cases show that it's possible to set a smart meter with incorrect time. That really shouldn't be a an issue if there's a reliable connection as you would expect RTC to synchronise from DCC on the first connection. But this doesn't work.

For the past 3 years, my smart meter has been sending data every 30 minutes with an incorrect timestamp on the electric meter reading and this has not been detected.

Note: I do also have a gas meter which appears to send 30 minute data with a correct timestamp. 

mmmmikey

Chris_b2z said:

Another MSE user noticed this problem after the installing engineer incorrectly set the time as AM instead of PM resulting in a 12 hour offset. In my case it was correct originally but just suddenly changed overnight.

These two cases show that it's possible to set a smart meter with incorrect time. That really shouldn't be a an issue if there's a reliable connection as you would expect RTC to synchronise from DCC on the first connection. But this doesn't work.

For the past 3 years, my smart meter has been sending data every 30 minutes with an incorrect timestamp on the electric meter reading and this has not been detected.

Note: I do also have a gas meter which appears to send 30 minute data with a correct timestamp. 

Hi @Chris_b2z it sounds like you're assuming the meter sends out a timestamped message every 30 minutes and the supplier could check that the timestamp is current, but it doesn't work like that. Meter data is sent out when requested, and it is only requested as and when required. Quite often it will take a few attempts to get it depending on how the communications network is performing. Although it's obviously important that meter data is recorded accurately, the supplier doesn't actually need to get the data with any regularity to be able to bill you correctly.

The supplier is probably unaware of the issue if you haven't reported it. Have you reported it?

By way of explanation, the supplier requests the data from the meter via the DCC - that request is routed via the comms hub and the meter returns whatever data has been asked for. This isn't done every 30 minutes but typically 2 or 3 times a day IIRC. If the meter returns valid data then the supplier will treat it as such. The supplier has no way of knowing that the data the meter says is for, say, 09:00 to 09:30 is really for 02:00 to 02:30 because of a fault in the meter - either physical, firmware or misconfiguration.

Note that the gas meter works differently. It sends data to the comms hub every 30 minutes so the comms hub has a record of the gas data. That way, when the request for gas data comes in from the supplier (via the DCC) the comms hub can answer the request on the gas meter's behalf. So the gas meter doesn't need to stay awake listening for an incoming request, which would drain it's battery (not a problem for the comms hub or the electricity meter because they take mains power from the suppliers side of the meter).

As far as the synchronisation is concerned, underneath the surface the RTC in the meter probably uses something like epoch time (Google it if you're interested) and then calculates the time of day from that using locally stored time zone information. If the clock is consistently wrong by the same amount, it sounds like the RTC and synchronisation is working but the meter is consistently calculating the time wrong. From your description it sounds like an overnight firmware update stuffed things up (to use the technical expression). This would only be a significant problem for customers on a time of use tariff and not everyone is as on the ball as you so may not notice.

The bottom line is that if this is important to you then you need to report it and/or keep on at your supplier until they fix it.

Hope this helps (p.s. answering this from a position of having a background in IT and specifically global infrastructure that needs to say in sync. No real experience of smart meters but have done a fair bit of reading of the tech specs and one thing I do know about from (at times painful) experience is clock synchronisation.)

Chris_b2z

mmmmikey said:

Hope this helps (p.s. answering this from a position of having a background in IT and specifically global infrastructure that needs to say in sync. No real experience of smart meters but have done a fair bit of reading of the tech specs and one thing I do know about from (at times painful) experience is clock synchronisation.)

Thank you @mmmmikey. That's a really clear explanation. My previous understanding of the SMETS2 data exchange protocol was very different.
I'm also from an IT background having worked with networked storage devices where NTP servers are used to guarantee time accuracy but had no idea how this is implemented in SMETS2. There have been numerous references in these energy forums suggesting that smart meters have remotely synchronised clocks making them more reliable and accurate for TOU tariffs. That's simply not true.
I did not report the fault as it was an advantage to have E7 off-peak rates during the day. The meter has since been remotely updated to single rate mode and I've changed suppliers but the 7hr time offset remains. Now I just have to remember that for me BG PeakSave starts on Sunday evening rather than 11am. I can live with that.
I've dug out the previous discussion where someone discovered the 12hr offset. They had a 5-terminal meter and found their storage heaters only started charging at midday which was far from ideal. Armed with details of the incorrect time setting on the EDMI smart meter the supplier eventually resolved it by sending out an engineer to perform a reboot. That fixed the problem for one household but I doubt anyone took a closer look at how widespread this could be or how it could be avoided in future.

BarelySentientAI

Chris_b2z said:

mmmmikey said:

Hope this helps (p.s. answering this from a position of having a background in IT and specifically global infrastructure that needs to say in sync. No real experience of smart meters but have done a fair bit of reading of the tech specs and one thing I do know about from (at times painful) experience is clock synchronisation.)

Thank you @mmmmikey. That's a really clear explanation. My previous understanding of the SMETS2 data exchange protocol was very different.
I'm also from an IT background having worked with networked storage devices where NTP servers are used to guarantee time accuracy but had no idea how this is implemented in SMETS2. There have been numerous references in these energy forums suggesting that smart meters have remotely synchronised clocks making them more reliable and accurate for TOU tariffs. That's simply not true.
I did not report the fault as it was an advantage to have E7 off-peak rates during the day. The meter has since been remotely updated to single rate mode and I've changed suppliers but the 7hr time offset remains. Now I just have to remember that for me BG PeakSave starts on Sunday evening rather than 11am. I can live with that.
I've dug out the previous discussion where someone discovered the 12hr offset. They had a 5-terminal meter and found their storage heaters only started charging at midday which was far from ideal. Armed with details of the incorrect time setting on the EDMI smart meter the supplier eventually resolved it by sending out an engineer to perform a reboot. That fixed the problem for one household but I doubt anyone took a closer look at how widespread this could be or how it could be avoided in future.

It is true - however relies on two things.

Firstly, the sync command must actually be triggered, which it seems isn't a standard procedure.

Secondly, what is being synced must be what you think it is.  In your case, it could well be that there is a fixed 7 hour 'correction' in the conversion (either linked to time zone or some other firmware setting, that isn't clear).  When your meter gets told to sync, it applies the same 7 hour correction to the check time provided from the remote system and, rather unsurprisingly, thinks it is accurate.

If I tell my computer that I am in Berlin (or it thinks that's what I've told it) and set the time accordingly, and then sync the clock, it isn't going to suddenly decide to correct to London and claim an error, it's going to sync with Berlin and assume that it is correct.  That doesn't mean that I don't have a remotely synchronised clock.

Chris_b2z

BarelySentientAI said:

it could well be that there is a fixed 7 hour 'correction' in the conversion (either linked to time zone or some other firmware setting, that isn't clear).  When your meter gets told to sync, it applies the same 7 hour correction to the check time provided from the remote system and, rather unsurprisingly, thinks it is accurate.

If I tell my computer that I am in Berlin (or it thinks that's what I've told it) and set the time accordingly, and then sync the clock, it isn't going to suddenly decide to correct to London and claim an error, it's going to sync with Berlin and assume that it is correct.  That doesn't mean that I don't have a remotely synchronised clock.

Aren't we over-complicating this? Does it really matter why or how a smart meter can fail to tell the correct time? The effect is the same. Consumers could easily be overcharged if the switch between peak / off-peak rates doesn't happen when expected.

Whereas, the Radio Teleswitching Service (RTS) has proved to be reliable and accurate.

mmmmikey

Chris_b2z said:

BarelySentientAI said:

it could well be that there is a fixed 7 hour 'correction' in the conversion (either linked to time zone or some other firmware setting, that isn't clear).  When your meter gets told to sync, it applies the same 7 hour correction to the check time provided from the remote system and, rather unsurprisingly, thinks it is accurate.

If I tell my computer that I am in Berlin (or it thinks that's what I've told it) and set the time accordingly, and then sync the clock, it isn't going to suddenly decide to correct to London and claim an error, it's going to sync with Berlin and assume that it is correct.  That doesn't mean that I don't have a remotely synchronised clock.

Aren't we over-complicating this? Does it really matter why or how a smart meter can fail to tell the correct time? The effect is the same. Consumers could easily be overcharged if the switch between peak / off-peak rates doesn't happen when expected.

Whereas, the Radio Teleswitching Service (RTS) has proved to be reliable and accurate.

Hi @Chris_b2z in the words of Wikipedia, "citation needed"  

Do you have any evidence at all that RTS meters are more accurate and reliable at keeping the time than smart meters? You seem to have jumped from "I have a problem with my smart meter" to "smart meters don't work" based on a misundertanding of how they are supposed to work and minimal or no evidence to support your very bold assertion....

From the above exchanges, it seems likely that the issue you have is a simple configuration error that has been introduced by a firmware update which could be very easily rectified once reported and/or if it becomes important to ensure accuracy of billing. Or, worst case, if the meter is faulty it could be swapped out for a working one.

I really don't think there is anything more to this than you have a fault (most likely a simple configuration error) that hasn't been fixed because you haven't reported it.

Chris_b2z

The point I'm making is that RTS should always be accurate as it's triggered by a simple signal transmitted via BBC Longwave radio.

There is no clock drift affecting switching accuracy. There are no concerns of meter timezone being set incorrectly to Germany or China. There are no worries of installer setting RTC incorrectly. There is no risk of human error during remote code updates. There is no need for clock auto-synchronisation.

It just works reliably ... while the modern replacement may have some limitations. That looks like a backward step to me if accuracy is an important requirement.

bob2302

If the meter is set to the wrong time zone it will be an exact multiple of 0.5 h out, most likely an exact multiple of 1 h. It was said to be over 7 hours out, which doesn't sound like a time zone error.. 

mmmmikey

bob2302 said:

If the meter is set to the wrong time zone it will be an exact multiple of 0.5 h out, most likely an exact multiple of 1 h. It was said to be over 7 hours out, which doesn't sound like a time zone error.. 

Makes sense, but regardless of what the issue is it should be easy enough to get fixed, either by correcting a configuration error, updating the firmware or swapping out the meter if it is faulty.

Given the number of folks here on TOU tariffs I think it is a fair bet that if this was a widespread issue with smart meters we'd see far more complaints in line with the fairly steady stream of confusion over E7 timings. For most people, smart meter data timings just seem to work as expected.

I think that all we can really say with any certainty here is that there are a small number of customers who's smart meters are sending in data with the wrong times, which may or may not be due to a clock synchronisation issue with a specific meter.