[APP][DEV][PRO] Octopus Energy Integration

Apps
,
130

Hi @Matthew_Collins, welcome.

“The only stupid question is the one you don’t ask.”

This is not a stupid question at all - I spent a few days working this stuff out when I first got my Homey. There are (at least) two possible reasons for this question.

  1. You are seeking an event (When flowcard) to trigger the flow that looks directly at price
  2. You already have an event that you want to use and need to further qualify that event (And flowcard)

I Already Have An Event

The second is the more general case and is easy to resolve - so let’s look at that first. The Pricing Quartile Changed event on the EnergyAccount device will fire whenever the price changes by enough to cross the quartile boundary - in practice that will be every price change worth worrying about (for example on the Cosy Octopus tariff, the quartile bands are each about 7p wide). I then qualify that event by looking at the price itself (£/kWh) from the ImportTariff device. This is the flow that results…

image
image1345×234 52 KB

Note you should NOT have a gap between your low price threshold and high price threshold. Octopus rates are expressed in units of 1000th of a penny (5 decimal places on the pound). What would your logic do with a price £.09426? In the flow above, low price actions are taken for prices <£.09 and high price actions for prices >=£.09. If you want exactly £.09 to be a low price then replace the And flowcard with £/kWh is greater than 0.09 and reverse the high price and low price actions.

One problem I would point out is that you have hard-coded a price limit into your flow. What happens when prices change? Potentially you are creating a maintenance headache. This is precisely the reason the App provides the Price Quartile capability. A Price Quartile of 0 means “any price that is within the bottom 25% prices available today”. Quartile 1 refers to the bottom 50% of prices today and so on.

So if you always want to consume when prices are at the lowest 25% (irrespective of the actual prices), the flow becomes:

image
image1364×256 49.8 KB

For the bottom 50% you would use Price Quartile Number is less than 2. And so on.

I Need An Event

To do what you are asking with explicit events makes things rather more complicated. Remember, an event is instantaneous. The price changing from £.09001 to £.08999 is an event, it happens NOW and then stops. Hopefully this is clarified by the use of the word “becomes” in the event name.

The price changing from £.08999 to £.09001 is a different event. This means you need two flows, one to handle the getting cheaper event, the other to handle the getting dearer event. It looks like this:

image
image669×197 26.9 KB

But here the maintenance load is made worse because you have the price stated twice. Arguably there is the edge case where the price becomes exactly £0.09. What happens?

I have to confess I dislike this flow separation. My view (only a view) is that the event you are handling is the PRICE IS CHANGING in some way - now what needs to happen in response to that price change?

Guidance

These guidelines come from long experience both as a software engineer and as a user of Homey creating advanced flows. Hope it’s helpful.

  • Always try to identify the “root” event - in these examples, the root event is the Price Is Changing rather than Price Has Crossed An Arbitrary Threshold.
  • Ask “how can I avoid hardcoding values that may well change in ways or at times I cannot control” - Price is a good example of such an exogenous variable. The app defines Price Quartile precisely to give control back to the user. Irrespective of how actual prices change a Price Quartile of zero always means the cheapest 25% of the price range on the day.
  • Then work out how you are going to distinguish between different conditions (states) that the root event establishes (in the example Quartile = 0 or Quartile <> 0).
  • Work out the actions you need in each condition or state.
  • When creating conditions for essentially continuous variables (Price is continuous to 5DP) always ensure you cover the entire range of that variable - if you don’t then a Price may arise that has no path through your flow.

As a footnote to the first bullet, it frustrates me that Homey automatically generates Greater Than and Less Than events even for discretely valued capabilities, but does not generate Changed events - those the app developer has to code for themselves. Sigh.