@tim441 - unfortunately that's not how billing works via a Smart Meter. 😥 

When the Smart Meter system was designed in 2013, they realised that it must incorporate a feature to prevent massive surges on the grid when devices automatically switched-on at the start of cheaper periods.

A Smart Meter divides the day into forty-eight periods of 30-minutes, commonly referred to as HH (half-hour). This is called the Tariff Switching Table.

Its internal software also incorporates a random-number generator which gets activated on the first occasion when power is applied to the electricity meter (ESME). That creates numbers which are stored permanently as constants within that particular meter.

The numbers are passed through an algorithm which yields a Randomised-offset between 1 and 1799. That gets rounded to the nearest whole number (ie to the nearest second). This value is used to delay the Tariff Switching Table times.

The random number constants and the Randomised-offset are within a Security Perimeter to prevent access both physically and by communications.
There is no external record of the offset, nor any SMETS-command by which it can be requested.

I have created a histogram demonstrating the Tariff Period start delays which apply to a notional random set of 4000 electricity Smart Meters:

As you can see, about 560 ESME devices start their Tariff Periods within the first minute of Universal Time (UTC/GMT).

But as the 8th minute ends, half of the 4000 meters have still not started the next HH period.

Energy Suppliers obtain the data on which to base our bills by reading the Smart Meter registers.
They have no way of knowing the exact time at which the 2nd Tariff Period of the day actually started for you.
It will be some time between 00:30 and 01:00, but that's as much as they can tell.

If it was your Smart Meter which had issued the command to turn on a particular device in your home, then there wouldn't be a problem.
The ALCS-ON command would be triggered by the same Randomised-offset used for your billing.

ALCS is Auxilliary Load Control Switching. Each Smart Meter must have at least five ALCS channels available.
The ALCS commands can be sent along a piece of wire, or using the same Zigbee network that transmits data to the display your In-Home Device (IHD).

But... as yet you can't get a device which can be triggered by your Smart Meter because no one has bothered to produce one since the SMETS Standard was laid down a decade ago.

Let's demonstrate the billing error issue graphically, using a time-line.

Imagine you are signed up for a tariff similar to Economy-7 or Octopus Go in which a cheaper rate applies each night from half-past-midnight.
Standard charges are 37p/kWh, and the reduced rate just 12p/kWh.

And lets suppose you are going to switch on a load for just 30-minutes at 00:30 when you think the cheap-rate begins.

For the purposes of this illustration we are going to use a Randomised Tariff Offset of 7min 40secs.

The top half of the time-line, with a light-green background, shows a command being sent to your Smart Meter soon after midnight, telling it to issue an ALCS-ON command when the second HH-Period of the day starts. The ESME knows this will actually occur at 00:37:40.

The bill will be 'correct' because electricity was consumed only when you were being charged 12p/kWh.

The lower half of the time-line illustrates you switching on the same load manually, or by using a time-clock.
Either way, you will be using Universal Time (GMT) to undertake this.

You will actually be consuming electricity at 37p/KwH for the first 480-seconds (7m40s), and only then being billed at the 12p/kWh which you'd wanted.

I have used a number of technical terms in the above explanation.
These have been obtained from the official specifications and documents published by the Government Dept for Energy (until May 2015) and subsequently the Dept for Business, Energy and Industrial Services.

@transparent Thanks for the explanation.  In this case, what happens with the Demand Flexibility Service payments?  Will I be penalized for  reducing consumption at the "wrong" time or do they have a workaround for that?

If the evidence for you having complied with Demand Flexibility Service payments is taken solely from Smart Meter readings, then it's possible that you may not receive the refund which you are due.

This depends on how each Energy Supplier is applying these rules. If they're looking for a reduction of demand by (eg) 10% between the hours of 4-7pm, and you attempt to save just 10% and no more, then the Smart Meter's Randomised Offset will count against you.

To  be certain of obtaining the payment you're after, you'd need to either reduce your electricity consumption by a greater amount, or extend the time-frame by another half-hour, or both.

If you are penalised due to the effects of the Randomised Offset, then you would probably have a claim against your Supplier for unfair/obscure terms of the 'contract' (Consumer Rights Act 2015).

But the issue is far more serious than the matter of Demand Flexibility Service payments.

If we assume that the SMETS Meter manufacturers have indeed abided by the requirement for the Randomised Offset stated in the 2013/4 specifications, then a significant proportion of customers with a Smart Meter could claim against their Supplier on the basis of some level of incorrect billing.

[I am not at this time revealing the criteria by which a consumer might have reasonable suspicion that they have been subject to incorrect billing. To do so could place 3rd parties in legal jeopardy.]

Since the Random Number Generator, and the numbers used to create the Randomised Offset are inside the Security Perimeter, goodness knows how those claims could be settled. I do know how to deduce the amount of the Randomised Offset to within around 10secs, but it can only be done whilst on-site and it takes many hours to conduct the required tests.

Moreover, Ofgem might also have serious questions to answer.
They have issued fines (or agreed financial penalties) with a number of Energy Suppliers over the past decade due to technical breaches in their Licence T&Cs regarding incorrect billing.

Don't you think those same Suppliers might now be demanding that their fines/penalties are refunded on the grounds that other Suppliers have issued incorrect bills to a substantial proportion of customers with a Smart Meter?
So why should they have been singled out by Ofgem?!

This is the second occasion that I have published the above details on how Smart Meter billing worked.
The first time was over 2 years ago on the OVO Forum.

And yes, I have put the same points in writing through the correct official channels to the relevant authorities.

And yes, I have written directly to more than one Energy Supplier to forewarn them that their billing software for Smart Meter customers is inaccurate.
I still have those replies.

I will give credit here to 'S1D', who is a professional mathematical modeller, and has provided invaluable assistance in analysing and reporting this same issue over the past 2 years.
Without their support, I may not have taken the risk of going public on the subject of incorrect billing.

@transparent Thanks for an enlightening reply.  Quite a conundrum.  It's driven me to look into it further.

From the Honeywell spec, the Randomized Offset is the product of an Randomization offset number (internal random number between zero and one set at manufacture; not accessible or modifiable) and a Randomization Offset Limit (between 0 and 1799; remotely modifiable by DCC) rounded to an integer.  The case you seem to refer to above will be elicited by ROL=1799 (~30 min).  The DCUSA seems to have agreed ROL should not be less than 600 (~10 min).  I don't know what ROL is in force currently.

From your histogram, I'm somewhat surprised the histogram does not have a uniform distribution since that would result in minimum synchronization of switching.  Have you backcalculated the distribution from samples or obtained the Random Number Generator (RNG) used by the manufacturers?

If I had to infer my randomized offset, I'd have thought I could do it by switching everything off between the notional UTC start and end times of a notional period then run a suitably large constant power sink (fan heater?) for a further tariff period.  If C1 is reported consumption in the first period and C2 in the second, then the randomized offset = 1800*C1/[C1+C2] seconds.  I suppose I can pick up the tariff period consumption off Bright who presumably pick it off the central database.

Corrected formula.

@transparent thank you for the detailed response. Certainly seems less than ideal way that it works and i guess its unlikely there will be any further changes any time soon. With smart meter rollout so far behind schedule I struggle to imagine DCC or the energy suppliers will do anything that creates further work.

I'm not sure how they will solve the issues you raise - presumably the meters could store the data and report with intervals to avoid surges but i've no idea if that means meters need changing/updating!

However it still brings us back to trying to decide best tariff based on available information. And it seems to me the API is the best we can do at this time. But i'm not aware of any publicly available Apps or spreadsheets using the API that allow personalised comparisons that include lots of Tarriffs inc Tracker.

Perhaps apps from Octopus Compare, Hugo (others?) will incorporate the info & comparisons better in future

Posted by: @ronin92

↑

... a Randomization Offset Limit (between 0 and 1799; remotely modifiable by DCC)

The SMETS Specification from which I've drawn my explanation could not have mentioned the concept of DCC being able to modify a Randomisation Offset Limit because the Data Communications Company did not then exist! 🤔 

I'll have a closer look at the Elster (Honeywell) spec that you refer to. It raises the question of a possible later amendment to the specification, albeit undertaken by DCC, whose operations exist within the Security Perimeter of the National Smart Meter Network.

All this energy-related documentation has now been acquired from BEIS, Ofgem and others, by the Retail Energy Code Company. They have granted me password-controlled access to their digital library, for which I'm grateful.
Alas I cannot find any SMETS Specification within the corpus of material curated by RECC.

Posted by: @tim441

↑

... it still brings us back to trying to decide best tariff based on available information. And it seems to me the API is the best we can do at this time.

Yes, the API is the correct way for you to proceed.

However, in light of the explanations which I've just given, you may wish to adjust the way in which you use your chosen tariff to minimise your exposure to billing errors.

1: inset the times during which you import electricity. Thus for a tariff which offers cheap-rate 00:30 - 04:30, you could elect to import between 00:50 - 04:30, thereby removing an initial 20mins of uncertainty.

2: spread the required load over as wide a time-interval as possible. Instead of charging an EV at 30A for 90mins, do so for 3-hours at 15A.

The above pair of suggestions are also DNO-friendly, and put less strain on grid-supply.

I built a spreadsheet that takes exported Smart Data and returns % used during the day Vs night. I can clean it up and share if you like.

Edit: Day being between sunrise and sunset, rather than the Octopus night time period

@dangermousie many thanks! Yes, would be interested in having a go. Perhaps you could share here or via DM please?

Posted by: @tim441

↑

However it still brings us back to trying to decide best tariff based on available information. And it seems to me the API is the best we can do at this time. But i'm not aware of any publicly available Apps or spreadsheets using the API that allow personalised comparisons that include lots of Tarriffs inc Tracker.

Try this video.  There is a link to the spreadsheet, this looks pretty comprehensive, though I did not validate it.

@william1066 interesting! ... many thanks.... will be looking in more detail. Not sure if he has done anything about Tracker yet... will check