utilities/telegraf-plugins#14: Octopus Energy Pricing Plugin

The plugin (as currently written) requires two environment variables be set

• OCTOPUS_KEY: the account's API Key (can be found here)
• OCTOPUS_ACCOUNT: the Octopus account number

With those details it will

• Place an API call to fetch account information
• From that information, identify any meters associated with the account
• Extract the tariff code for each meter
• Use the tariff code to calculate the product identifier
• Use both of those to fetch pricing information

At the moment we just build a big JSON blob - there's no line protocol being generated yet.

As well as Octopus' API docs, I used the excellent post by Guy Lipman to figure out which API endpoints needed calling.

One of the things we need to decide is how we want to handle the pricing info.

What we get back from the API looks like this

[
{
  'value_exc_vat': 29.2574, 
  'value_inc_vat': 30.72027, 
  'valid_from': '2023-06-30T23:00:00Z', 
  'valid_to': None, 
  'payment_method': 'DIRECT_DEBIT'
}, 
{
  'value_exc_vat': 29.9142,
  'value_inc_vat': 31.40991,
  'valid_from': '2023-06-30T23:00:00Z',
  'valid_to': None, 'payment_method':
  'NON_DIRECT_DEBIT'
}, 
{
  'value_exc_vat': 48.9338, 
  'value_inc_vat': 51.38049, 
  'valid_from': '2023-03-31T23:00:00Z', 
  'valid_to': '2023-06-30T23:00:00Z', 
  'payment_method': 'DIRECT_DEBIT'
}
]

(dodgy formatting is because I've pasted the resulting python dict in rather than the raw json)

I've cut it short, but it goes back to whenever the tariff was created. For Agile there will obviously be many more entries because the pricing is every half hour.

The question is: how do we want to handle exposing this pricing information?

1. • Do we just extract the latest price and attach that to the meter info?
2. • Do we do a 1:1 conversion (so in the example above, generate 3 lines of line protocol)
3. • Do we calculate each hour (or even 30m) between valid_from and valid_to and generate a line of LP for that?

I don't think I like option 1) at all.

Option 2) is OK, but means that we'll likely - in effect - be doing Option 3) at query time instead (the majority of the time, pricing information is going to be JOINed to consumption so that costs can be calculated)

I think the answer probably is to generate the iterations. The API supports provision of a period_from= argument in the request, so that can be used to ensure we don't end up doing this work for months at a time.

Although the main aim had been to collect tariff details, given the work involved in pulling out MPANs anyway, it's probably worth going a step further and grabbing consumption data too.

I've added support for consumption.

Given we're also collecting consumption, it's probably worth renaming the plugin from octopus-tariffs to octopus-energy (easier to do now than later, and the old name's no longer representative).

I think I'm more or less at the stage where I should be ready to release

• README has been created (commits inbound)
• License headers have been added (BSD FTW)
• Test install is happily sending data

However, Guy Lipman's post notes that

One of the complications of the price end-points is that they vary a bit between tariffs. I will first describe the Agile tariff, and then move to other tariffs in turn.

I'm actually ready to move onto Agile - I was expecting it to take a couple of weeks but they emailed me earlier (only brief hold up is I can't sign the terms + conditions because their server throws an error)

I can't see what the difference that Guy alludes to is - I think it might just be in the params that you can include in the URL, the path format and the response bodies look to be the same.

I think the answer to that, though, is to go ahead and merge and then raise a followup ticket once we're on Agile (if there's an issue).

Merged: https://github.com/bentasker/telegraf-plugins/pull/3