Hi @Rrrr thanks for the contribution. All the data we need is being picked up via the GraphQL interfaces into the Kraken system. Tomorrow’s prices for all tariffs are published in the late morning or early afternoon. In the Kraken data tomorrow’s prices are published for the whole day in one go.
In addition the app triggers events when the tariff rate changes so that users can automate their smarthome reactions to price changes via Flows.
Things are looking pretty good. I Have run the app with my Dispatch Test data in place with good results. I shall leave it running overnight to test the midnight turnover.
I have changed the “picker” user interface into “slider” for the period start day. It’s much easier to use and much more immediate in presentation and use than the old version. Downside it doesn’t show you which value is currently selected, sigh! I have moved the Period Start Date capability to the top of the Sensor view so that it’s easy to see what day is currently selected.
Feedback welcome!
Dispatch timing seems to be working well. The EnergyAccount device always uses Extended dispatch periods and I have modified the SmartEnergyDevice device to focus only on Planned dispatch periods.
To illustrate the difference, imagine there is a Planned dispatch from 16:45-17:25 (40 minutes of dispatch). This Planned dispatch period is the period when the device will be switched ON by Octopus to receive dispatched energy. This is why I have modified SmartEnergyDevice devices to focus only on Planned dispatches.
In contrast, the Extended dispatch period will run from 16:30-17:30 (60 minutes). This is the period during which the Meter will receive reduced price energy. Note the smart device is switched off by Octopus from 16:30-16:45 and from 17:25-17:30 so only other devices on the Meter will receive the reduced price energy during these times.
The difference between planned and extended dispatches is explained by the constraint in the UK metering system that divides the day into 30 minute chunks (starting at :00 and :30 minutes passed the hour). Within a chunk all energy must be supplied at a uniform price. Planned dispatches represent the times when Octopus will use their control to switch the device on. Extended dispatches represent whole chunks which must be supplied at the dispatch rate.
Energy consumption and cost per chunk is explicitly reported by capabilities on the EnergyAccount device.
There are several new When flow cards available from the App. To manage general device usage (e.g. charging an domestic battery that is NOT a SmartEnergyDevice) the events Dispatch Pricing Starts and Dispatch Pricing Ends can be used.
To manage a SmartEnergyDevice the events Dispatch Starts and Dispatch Ends can be used.
The event Pricing Quartile Changed includes both Tariff Rates and Dispatches in its signal. So if you want to control energy usage so that it always makes use of the cheap(est) rate energy your flow can look like this:
Overnight testing has been successful with the app signalling tariff slot changes and dispatch slots for Intelligent Tariffs too (based on test data). The Price Quartile capability in the EnergyAccount device is tracking tariff changes and timings of extended dispatches.
I shall make a release this afternoon.
I know I have said this before but… I plan on only one more change before submitting to Athom for publication. This will be to extend Dispatch timing to the Import Tariff device. Fingers crossed…
thank you for all the work you have put into this. David
Has just been published for testing. Please update your installation and let me have any feedback.
The EnergyAccount device is completely re-implemented - all of the capabilities on the device will be removed and an updated set of capabilities will be added for you.
If you notice that your installation is failing then please restart your Homey to give the app the chance to make the necessary changes.
The removal of all the capabilities means that the insight data for the capabilities will be erased too. Please be aware of this potential loss of data.
In the last release changes had been made to try to better manage Dispatches (Intelligent Tariffs) - these were just wrong. Unfortunately the errors affected everyone, not just Intelligent Tariff users. Sorry.
In addition a change to make the code more robust resulted in the app missing the change from one invoicing period to the next. The result was that energy and cost capabilities were not reset to zero at the end of the invoicing period. These problems have been corrected.
If your Octopus account does not feature an Export tariff, the export capabilities will be omitted from the device. Similarly if you are not on an Intelligent tariff, capabilities related to Dispatches will be omitted.
In addition I have taken the opportunity to make the EnergyAccount device more consistent in the way it handles different periods of time. It uses three different periods of time, measuring consumption and cost over:
“Chunks” are the basic timescale of the UK smart metering network. Each chunk starts at 00 or 30 minutes past the hour and lasts for 30 minutes.
The measure of Price Quartile fully takes into account both changes in Tariff Price and, for those on Intelligent Tariffs, the receipt of Dispatches. Dispatch pricing is based on extended dispatch timing - that is the planned dispatch time extended to cover complete chunks. It also takes into account the 360 minute per day limit on dispatches across all smart devices.
The Price Quartile capability on the EnergyAccount device can be used to accurately indicate whether or not you are receiving reduced price energy (values 0 and 1) or more expensive energy (values 2 and 3). There is a When flow card (When Pricing Quartile Changed) on the EnergyAccount device that will trigger flows. You can combine this with an And card from the Logic system app to test the value of the quartile currently being applied. Here’s an example:
The Pricing Quartile Changed flowcard is also defined for the ImportTariff device. This card will NOT function correctly for Intelligent Tariff users because it does not take account of dispatches yet. The ImportTariff device will be adjusted to take account of dispatches in the next release.
These also track Dispatches, but, in contrast to the EnergyAccount device, devices track Planned Dispatches. A Planned Dispatch is the period of time when Octopus (who control the delivery of energy to the device) will actually enable the device so that it can receive power.
For users with Intelligent Tariffs the When In Dispatch card on the SmartEnergyDevice can be used to control flows that rely on the device actually being enabled to receive energy.
The equivalent flowcard on the EnergyAccount device is When Dispatch Pricing - this indicates that energy is being delivered at a reduced price because an Extended Dispatch is in progress. This capability does NOT relate to tariff prices, it indicates purely that the price is discounted because of an extended dispatch. Intelligent Tariff users can use this flowcard to trigger behaviour that relies on reduced price electricity being received because of an extended dispatch.
| Version | Installs | Crashes | Crash Types | Comment |
|---|---|---|---|---|
| 1.0.40 | 28 | 0 | 0 | Published 2026-01-31 13:53 |
| 1.0.39 | 4 | 0 | 0 | Published 2026-01-11 17:25 |
| 1.0.38 | 3 | 246 | 1 | Affected user has upgraded 2026-01-11 20:23 |
| 1.0.30 | 2 | 0 | 0 | Robust for non-intelligent tariff customers |
| 1.0.29 | 1 | 2000 | 2 | Newly created device causing crashes |
| 1.0.28 | 1 | 1 | 1 | Query returning malformed response |
| Older | 1 | Lots | 6 | Stopped explicit monitoring, it’s too old  |
| Totals | 39 | 2247 | 4 |
83 Kraken Devices
@ 2026-02-04 11:20
The interaction between the Tariff, Dispatches, Devices and Events fired by the Homey devices is pretty complicated. I thought a picture might help - so here’s an attempt.
2026-02-04 16:11 Updated to reflect changes to where Pricing Events originate
Sorry to sound stupid, but how do we now see the current price, for a flow? As my flows have stopped working. So i have flows when the current price is below 9p it switched things on and then when over 10p it would switch off.
Same here, I think we now have to use the pricing quartile on the octopus account device.
Hi @Matthew_Collins, welcome.
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.
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…
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:
For the bottom 50% you would use Price Quartile Number is less than 2. And so on.
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:
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?
These guidelines come from long experience both as a software engineer and as a user of Homey creating advanced flows. Hope it’s helpful.
Price Is Changing rather than Price Has Crossed An Arbitrary Threshold.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.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.
Indeed, see my reply to @Matthew_Collins to understand my rationale for this.
Just an observation, the £/Kwh price on the import device does not change when the quartile changes
Well that’s weird. Here are the insights for my Import Tariff (I guess that’s the one you are referring to).
That’s from the Cosy Octopus tariff. Can you share the same insights and let me know which tariff you are on (you may already have put that in a message, but I couldn’t find it easily).
If you are using Intelligent Go and the Quartile change results from a dispatch rather than a tariff price change, then please note that is the one piece of engineering I still need to do - linking Dispatches into the Import Tariff device - I hope to have that done in the next few days for the next release. After that I shall submit the app to Athom for full publication.
I have reviewed the code and the Import Tariff is picking up the Quartile value from Tariff Price only for now. Dispatches will not update the £/kWh value.
Please let me know. Thanks.
I am on Intelligent Octopus Go. The £/kwh only changes at 11:30pm and 5:30am, not when I smart charge my car during the day.
OK, that confirms my analysis. The price is NOT tracking dispatches yet. The same is true of Price Quartile on the Import Tariff device (since it is derived from Price on that device). Price Quartile on Energy Account is all wired up.
I shall wire up the Import Tariff capabilities in the next couple of days and make a new release. Sorry for the annoyance.
As part of the work to integrate Dispatch Pricing in to the Tariff Devices, I have discovered a faux-pas (aka defect) that means that the Cost (or Value) of Energy is never updated and remains set to the null value, displaying “-”. Surprisingly hard to uncover, easy to fix.
The initial work on the integration is complete. Brief testing with no dispatches revealed no errors. Testing with Dispatch test data is now in progress. I shall let this run overnight to check the Tariff Slot changes and midnight-rollover all work.
Hopefully a release tomorrow.
The work underway to make the treatment of Dispatches consistent across all Homey device types has made it clear that the design of each Homey device can be made more focused. I am proposing the following:
SmartEnergyDevice focuses on Planned Dispatches only and signals when energy is being dispatched to the specific device using the Dispatching Now capability. If there are multiple SmartEnergyDevices on the account each only pays attention to its own Planned Dispatches it counts DispatchMinutes only for those dispatches. NextDispatchCountdown is the interval until the next Planned Dispatch starts on the specific SmartEnergyDevice.EnergyAccount focuses on Extended Dispatches only and tracks these across all SmartEnergyDevices; it tracks the consumption of the DispatchLimit in minutes across all devices.ImportTariff tracks Extended Dispatches and tracks these across all SmartEnergyDevices; it adjusts pricing via £/kWh when any Extended Dispatch is in progress. As the device with responsibility for monitoring prices it also signals the PricingQuartile.To complete this improved focus the main change is to remove the PriceQuartile and DispatchPricing capabilities from the EnergyAccount device.
Monitors the consumption of energy provided by the tariff and the prices charged for that consumption. Tracks when Dispatch Pricing is in force and adjusts prices and price quadrant values accordingly. Signals price and quadrant changes according to Tariff Slots and Dispatch Slots. Tracks the consumption of the Dispatch Limit across all smart devices.
Monitors the amount and cost of energy consumed across different periods of time. It uses pricing information, including dispatch pricing to correctly calculate cost of energy. Uses cost information to estimate upcoming account invoices.
Monitors the dispatch of energy to the smart device via planned dispatches.
After mulling this post overnight, I have made a small change. The responsibility for monitoring the consumption of the dispatch limit should move to the ImportTariff device. All dispatch monitoring and flow control now rests with ImportTariff. The role of EnergyAccount is only about tracking energy consumption, cost, projected invoices and account balance:
I have left the test version running overnight and have identified one defect that needs to be fixed before release. Overnight tests again tonight, so release tomorrow, all being well.
Morning all INTELLIGENT GO tariff users. Has Octopus introduced the 360 minute Dispatch limit yet? I am about to make the new release - if there is no limit yet I will set the hard-coded limit to 1440 minutes (= 24 hours) so it will have no effect. If there is a limit now, please confirm it’s set at 360 minutes (6 hours).
Thanks!
PS. The limit will become a setting soon - more on settings in a post later today SPOILER
