Notifications
Clear all

Octopus tariffs - API & choosing best tariff

43 Posts
9 Users
14 Reactions
5,084 Views
(@tim441)
Reputable Member Contributor
1426 kWhs
Joined: 2 years ago
Posts: 166
Topic starter  
I'm not sure if anyone has got the time or any interest in expanding on available Octopus API data & tariffs to aid personalised calculations for best tariff? For example:
  1. Octopus now have many different tariffs inc Standard/flexible, Tracker (Daily rates), Tesla (retiring soon), Flux, Cozy, Agile tracker (incoming, half hourly rates), Agile outgoing (Half hourly), Agile Outgoing (Fixed), SEG... and maybe others!
  2. Trying to choose the best one is becoming a very personalised issue depending on usage (days/times), PV solar, batteries, ASHP, EV 
  3. But the "right" tariff is likely to have very significant differences in cost
  4. I was wondering whether someone with right skills could take the Octopus API key + MPAN to extract historical data etc to try and see the best tariff based on historical data (perhaps with certain assumptions if necessary?)
For myself I have 16kw ASHP, 3 x 8.2 kw batteries, 8kw PV solar and am inclined to think my best combination is currently Tracker (daily) + Agile Outgoing (half hourly) but its possible that Flux will be better in the summer and Tracker (daily) + Agile Outgoing (half hourly) in winter!
 
Even though I've had the ASHP for 3 winters we have only recently got to grips with weather compensation to ensure most efficient usage. At a guess we use around 8000kwh per annum. We used a hot tub a lot last year but I suspect that will be in the shed except for a month in the summer this year! I need to check but guess our solar production is around 4000 kw/h. 
Batteries give us options to potentially fill them at cheap tariff rates (as well as solar) & export at peak rates
 
I'm not currently aware of any easy way of trying to work it out other than guesswork.
 
any thoughts?

Listed Grade 2 building with large modern extension.
LG Therma V 16kw ASHP
Underfloor heating + Rads
8kw pv solar
3 x 8.2kw GivEnergy batteries
1 x GivEnergy Gen1 hybrid 5.0kw inverter
Manual changeover EPS


   
Quote
(@tim441)
Reputable Member Contributor
1426 kWhs
Joined: 2 years ago
Posts: 166
Topic starter  
Octopus have an API. Givenergy have an API too & I guess Tesla do too? 
 
The Octopus API connector links both the incoming & outgoing MPANs with 30 minute data. So between it all there is a huge amount of information "in the system"
 
Unfortunately I have no idea how to use the APIs!! But in principle feel it should be practical to extract the data and then make comparisons of the costs using different tariffs?
This post was modified 1 year ago 2 times by Tim441

Listed Grade 2 building with large modern extension.
LG Therma V 16kw ASHP
Underfloor heating + Rads
8kw pv solar
3 x 8.2kw GivEnergy batteries
1 x GivEnergy Gen1 hybrid 5.0kw inverter
Manual changeover EPS


   
ReplyQuote
Transparent
(@transparent)
Famed Member Moderator
8463 kWhs
Veteran Expert
Joined: 2 years ago
Posts: 1405
 

@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:

TariffOffset 4k

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.

ToU UTC offset4

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.

This post was modified 1 year ago 6 times by Transparent

Save energy... recycle electrons!


   
Filipe, Jancold, ronin92 and 1 people reacted
ReplyQuote
(@ronin92)
Estimable Member Member
1333 kWhs
Joined: 2 years ago
Posts: 64
 

@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?


   
ReplyQuote
Transparent
(@transparent)
Famed Member Moderator
8463 kWhs
Veteran Expert
Joined: 2 years ago
Posts: 1405
 

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.

This post was modified 1 year ago by Transparent

Save energy... recycle electrons!


   
ronin92 reacted
ReplyQuote
(@ronin92)
Estimable Member Member
1333 kWhs
Joined: 2 years ago
Posts: 64
 

@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.

This post was modified 1 year ago 5 times by ronin92

   
ReplyQuote



(@tim441)
Reputable Member Contributor
1426 kWhs
Joined: 2 years ago
Posts: 166
Topic starter  

@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

 

 

Listed Grade 2 building with large modern extension.
LG Therma V 16kw ASHP
Underfloor heating + Rads
8kw pv solar
3 x 8.2kw GivEnergy batteries
1 x GivEnergy Gen1 hybrid 5.0kw inverter
Manual changeover EPS


   
ReplyQuote
Transparent
(@transparent)
Famed Member Moderator
8463 kWhs
Veteran Expert
Joined: 2 years ago
Posts: 1405
 

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.

Save energy... recycle electrons!


   
Tim441 reacted
ReplyQuote
(@dangermousie)
Eminent Member Member
133 kWhs
Joined: 1 year ago
Posts: 16
 

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

This post was modified 1 year ago by dangermousie

   
Transparent reacted
ReplyQuote
(@tim441)
Reputable Member Contributor
1426 kWhs
Joined: 2 years ago
Posts: 166
Topic starter  

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

Listed Grade 2 building with large modern extension.
LG Therma V 16kw ASHP
Underfloor heating + Rads
8kw pv solar
3 x 8.2kw GivEnergy batteries
1 x GivEnergy Gen1 hybrid 5.0kw inverter
Manual changeover EPS


   
ReplyQuote
(@william1066)
Reputable Member Member
1333 kWhs
Joined: 1 year ago
Posts: 206
 

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.


   
dangermousie reacted
ReplyQuote
(@tim441)
Reputable Member Contributor
1426 kWhs
Joined: 2 years ago
Posts: 166
Topic starter  

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

Listed Grade 2 building with large modern extension.
LG Therma V 16kw ASHP
Underfloor heating + Rads
8kw pv solar
3 x 8.2kw GivEnergy batteries
1 x GivEnergy Gen1 hybrid 5.0kw inverter
Manual changeover EPS


   
ReplyQuote



Page 1 / 4



Share:

Join Us!

Latest Posts

Heat Pump Humour

x  Powerful Protection for WordPress, from Shield Security
This Site Is Protected By
Shield Security