# \[APP\]\[DEV\]\[PRO\] Octopus Energy Integration **URL:** \ **Category:** Apps\ **Tags:** app, homey-pro\ **Created:** [May 18, 2025, 3:47pm UTC](https://community.homey.app/t/app-dev-pro-octopus-energy-integration/136685 "2025-05-18T15:47:16Z")\ **Posts on this page:** 1\ **Showing post:** 130
**Author:** ![David\_Piper](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/david_piper/32/120919_2.png) [@David\_Piper](https://community.homey.app/u/David_Piper)\ **Post date:** [February 1, 2026, 11:43am UTC](https://community.homey.app/t/app-dev-pro-octopus-energy-integration/136685/130 "2026-02-01T11:43:15Z")
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](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/7/a/7ab272eb942e11fac65f5b0cad6b5bcaf7816d19.png) 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](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/5/8/58a1dbaff97844334a34a3b26bb5626dc7685847.png) 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](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/c/1/c1816ca53dd5988fc16b32554818998f8b0e2d3d.png) 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. --- _[View the full topic](https://community.homey.app/t/app-dev-pro-octopus-energy-integration/136685)._