There’s a long thread about the issue at https://renewableheatinghub.co.uk/forums/electricity-providers/incorrect-billing-of-customers-with-a-smart-meter
Wow! thanks @djh that is a significant issue, has Octopus given any response / advice on this?
We should be able to measure this by comparing half hourly data recorded by Octopus and comparing with half hourly totals aligned to the clock recorded locally…
All I know is what’s in the thread, except that I’ve found the randomisation mentioned elsewhere so I know it is real.
I agree that comparing the half-hourly data from the meter against [allegedly] the same data recorded by emoncms should allow one to work out approximately how long the delay is for any particular meter. Particularly if one is willing to switch a large load on or off at a particular time and leave it on for at least half an hour. I don’t have a smart meter so it’s not something I can do.
Unfortunately, there seems to be some confusion about this randomisation. This is what I know having worked on the firmware for the L+G E470 SMETS2 ESME (albeit some years ago now).
- The ESME (electricity meter) does have a free running battery backed RTC. This can be set during commissioning via the WAN backhaul, and at any time if required, but once set it is usually left to run. This clock is used for timing the tariff changes, but there is no randomisation involved. Unfortunately, the RTC tends to drift over time as Utilities are very bad at checking the clock for accuracy, so this may give the impression of deliberate randomisation. The ESME has its’ own RTC since it must store profiles (log data) even if the WAN and/or HAN fail.
- There is a randomisation applied to ALCS/HCALCS switching (Auxiliary Load Control/HAN Connected Auxiliary Load Control). These are switches controlled via the ESME that can be scheduled to switch ON/OFF. This is to ensure that there is not a huge load spike on the distribution network when things like Economy 7 switch in the storage heaters/EV chargers/etc.
- I can’t think why tariff switching should have randomisation applied to it, unless this is something new developed since I left the industry (which is, of course, quite possible).
1 Like
Please see https://committees.parliament.uk/writtenevidence/123426/pdf/ for some discussion of the randomisation we are talking about. It has nothing to do with a free running clock.
“When switching between Time-of-use Bands and Tariff Registers as set-out in this section ESME shall be capable of applying the Randomised Offset(5.7.5.28).”
Yet another example of an ambiguous requirement in the SMETS/GBCS documents. use of “shall be capable” is deprecated in standards writing. If you want to say it must be used then write “shall apply the Randomised Offset”. “shall be capable” can be interpreted as “must have the ability to, but may or may not be used”. This is the way I interpret it, and the way most ESMEs work.
I have never come across the use of the Randomised offset on tariff switches in the real world. However, it is possible so he is technically correct.
I have been on both the Octopus Agile and Go tariffs.
- With Agile the ESME TOU registers are not used. The Half-hour consumption profile is uploaded to the Octopus servers and the billing calculation done in the back end, so the problem cannot arise.
- When I was on Go then 2 of the ESME TOU registers were populated with the rates. The rate switching happened on the correct time boundaries (within the accuracy of the ESMEs RTC), so randomisation was not used.
Have you read the discussion I originally linked to?
Yes, but the only thing I get from that is that EDF have not configured their ESMEs correctly.
If I look at “DCC User Interface Specification V4.0” section 3.8.98 Set Randomised Offset Limit then Service Request ECS38 can be used to set the offset between 0…1799, so the randomisation can be disabled. I can’t see anything that defines what the default value should be, so it may well be manufacturer dependent.
However, there does seem to be a problem. There is only one Randomised Offset Limit, so this applies to both tariff switching and ALCS/HCALCS switching. Generally you would want the randomisation to be off for tariff switching and on for ALCS/HCALCS switching (avoiding large load changes on the distribution network). But you can’t do that (unless there are disable randomisation booleans buried in some other Service Request, which, no doubt, is named something non-obvious).
The point is that there are examples in the real world where the use of randomisation is causing problems. You may not have encountered them yourself, but apparently others have.
AIUI, the supplier’s conditions of supply say that they are not allowed to disable the offset.
I’m not sure why you say this? I have an E7 tariff and if I replaced my present dumb meter with a smart meter and wanted to use the ALCS/HCALCS switching to switch my heating then I would want the heating to switch on when the cheap rate started and switch off when it ended. Not at some random time within the wrong tariff period. So I would want the tariff switching at the same time as the load switching.
PS The spec says the clock shall be accurate within 10 seconds of UTC.
Whilst I tend to agree with you about “shall be capable of”, the authors of the SMETS spec clearly didn’t get the memo. They use it everywhere!
Oh, if that is true then all that he says about randomisation is correct. It also means there are a lot of systems in the field that are non-compliant. Do you happen to know which of the byzantine set of SE documents specifies this restriction?
Yes, this occurred to me later, there are 2 circumstances
- Load switched by ALCS/HCALCS. You would want the tariff switching and load switching at the same time, as you say.
- Load switched by user programming some white goods. The user doesn’t know about any randomisation so you want the tariff switching to occur at the nominal times. But then you get into the problem of large load disturbances
Well, in the real world it isn’t, unless they have improved the clock monitoring at the head-end in the last few years.
Came across this while searching for the illusive restriction on disabling offset.
Apparently they haven’t. This document is dated November 2023
It is concerned with service level targets of alarms generated by the ESME. The ESME will time stamp an Alert and send it off to the head-end. When the message arrives at the head-end the difference between the time stamp in the Alert and time of arrival gives the transit time. If the ESME clock is wrong, then this computed transit time will be wrong. The interesting section is 3.2 Time Clock Drift
“28. Time clock drift occurs when the meter and the CH clock no longer align to the actual
current time and can impact the calculated performance of the CPM and Performance
Indicator. The greater the drift between the device clock and the actual time results in an
increasingly inaccurate calculation. Clock drift was not included in the original list of
exclusions since it was considered that the issue would soon be resolved, that has not
proven to be the case.”
So they know there is a problem, they thought it would be fixed, but it hasn’t
“30. Time clock drift impacted installations differ in volume over time as meters and CHs
become unaligned and where Supplier Parties take action to realign the two, often over a
short period where high numbers of installations are corrected. At the beginning of
October Time clock drift in Supplier portfolios ranged from less than 1% of installations up
to 23% of installations”
So worst case roughly a quarter of some suppliers installations were suffering from clock drift
“31. The difference in WAN solution across CSPs may also impact the prevalence of clock drift
since the CSPN solution allows for, and requires, the CH clock to be updated on a regular
basis where the CSPC&S does not. At the beginning of October round 14% of installations
were impacted by time clock drift in each CSP.”
So if you are in the North your clock is more likely to be accurate, but not in the Central and South.
Sorry, no.
Well the user knows [or can know] that the randomisation exists. It’s just that they have no means to determine what it is (except experimentation). Which is pretty much the situation that has always existed with ‘dumb’ meters. So no worse, but no better. Allowing the user to discover what his randomisation is would be an improvement. I can’t understand why it is kept secret.
Ouch. That’s quite worrying.
You’d think so, but the document states that there is apparently no difference for some reason? The mind boggles as to how one spec doesn’t require clocks to be synchronised, whilst the other does. What were they smoking?