It was scheduled for end of January, but has been delayed due to technical issues and user concerns. ETA is not known at the moment, just says “in 2026”.
Keep up the good work!
Version 1.0.41 Published
Afternoon all. After some extensive testing of the mechanisms around dispatching I am pleased to say that 1.0.41 is now available for your evaluation. PLEASE READ THE NOTES, BELOW, CAREFULLY as there are some changes that may break your flows.
Notes:
- The clarification of the roles of
EnergyAccountandProductTariffhas been implemented.EnergyAccountnow monitors energy consumption over Period, Day and Chunk. It also holds the account balance and estimates the upcoming invoice.ProductTariffis responsible for tracking the unit price and its changes in response to Tariff Slots and Dispatch Slots. SmartEnergyDevicetracks Planned Dispatches only. It uses these to understand when energy is actually being dispatched to the device.- Power capabilities have been added to
EnergyAccountthat track the power (in Watts) being consumed and exported. These update every minute. (This capability could be used on a Homey Dashboard to emulate an IHD). - Flow events related to Dispatches and Price Quartiles have been moved from
EnergyAccounttoProductTariffas a reflection of the improved focus of these devices. This may break flows that used the When flowcards based onEnergyAccount. Price Quartile information is no longer duplicated on the two devices. - I have noted that, even though capabilities have been deleted, insights are sometimes still being generated, with 0 values. This seems to be a fault in the way Capabilities work. It’s not harmful, but may be confusing.
I will update the diagram to reflect the changed location of Flow events.
Next Steps
- I continue to be dissatisfied with the implementation of the
PeriodStartDaycapability through the Capability User Interface as a slider. I have been experimenting with the use of Device settings and I believe these offer a better way of implementing this requirement. - I further believe that Athom will not approve of the current implementation using a capability making it more likely that the App will not be approved and published in its current state.
- I plan, therefore, to replace the capability with a setting.
- There is a need for at least two more settings. First to control the maximum dispatch minutes per day for Intelligent Go tariff users. Second to control the polling interval on the Kraken API (selfish motive here, so I can run a test installation alongside my main installation and not keep losing historical data as I test new versions).
The upshot is, there will be a little longer to wait for a published version. I hope to have settings implemented in a couple of days. Once that is live I shall submit for publication (honest, guv).
1 Like
Not seen anything yet David.
I am seeing similar behaviour as others have mentioned regarding the treatment of dispatches using the Pricing Quartile Changed card.
1.0.40 or 1.0.41?
1.0.40.
Right - Tariff device did not track Dispatches in 1.0.40 (only tariff slot price changes). That’s the key change in 1.0.41. Can I ask that you test again with the new version 1.0.41? Thanks
1 Like
Release Usage Analysis
| Version | Installs | Crashes | Crash Types | Comment |
|---|---|---|---|---|
| 1.0.41 | 30 | 0 | 0 | Published 2026-02-04 14:22 |
| 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 | 42 | 2247 | 4 |
91 Kraken Devices
@ 2026-02-05 20:30
1.0.40 has already been retired!
1 Like
Settings - Progress Update 1
Good progress, settings are in place on the Homey Devices. All Devices share the same settings; each setting can be modified from any Device and the value is propagated across all devices. The Period Start Day and Dispatch Minutes Limit are fully wired up to their different devices and capabilities.
Kraken Polling Interval exists as a setting and it’s value can be modified. I have not built the functionality to modify the polling interval so the setting is completely ignored for the time being.
Setting Specifications
Period Start Day takes values 1-31 (in practice I suspect Octopus only permits 1-28 to invoice consistently over February).
Dispatch Minutes Limit takes values from 0 to 1440 (that’s 24 hours) in 15 minute increments. If there is no Dispatch Minutes Limit in force the setting should be set to 1440 minutes to allow for 24 hours of dispatches in a 24 hour period.
Kraken Polling Inverval is an enumerated list permitting intervals of 1, 2, 3 and 5 minutes.
More details on how to access the settings when I publish the release.
Good News
The rubbish UI around setting the Period Start Day will be no more. 
Next Steps
Running the app overnight to ensure everything is operating correctly. All being well I shall publish the release on Sunday as a test release. I shall then push the App to Athom for publication.
1 Like
I have an issue with the incrementing of the dispatch minutes today. It increases even when the car is not charging.
For example: dispatch starts, but car charger delays start to charging for 10 mins - dispatch minutes today still counts up for those 10 mins.
Another example: car finishes charging during the dispatch period but the house continues to use grid electricity, the dispatch minutes today continues to count up.
I don’t know if this is expected behaviour or not?
I am on intelligent octopus go, so the 360 limit for car charging is on its way and I don’t want ‘non car charging grid usage’ counting towards this limit?
1 Like
Another peculiar situation: car is fully charged, but still plugged in. Octopus sees the car is plugged in and creates a dispatch period from 6:00am to 11:30am, tariff changes to 7p and stays at that for the entire period, unless I unplug the car.
1 Like
Hi @Daneroyd
Interesting real-life experience. What’s below summarised my understanding. If that’s wrong please let me know (and point me to any documentation).
The app can only operate according to the data provided by Kraken. It has no knowledge of when the device is plugged in or actually charging, but only about when Dispatches are planned. The assumptions of the app are summarised in the diagram I posted a few days ago. To be explicit:
- If there is a
PlannedDispatchthen the app assumes the device is receiving a dispatch during the whole of that planned period. - The device does not receive a dispatch outside of the
PlannedDispatchperiod (unless anotherPlannedDispatchis planned contiguously to that planned period). - If a
chunk(30 continuous minutes from :00 or :30) contains all or part of aPlannedDispatchthen domestic energy is received at the reduced price for the whole of thechunk. This is theExtendedDispatch. - The 360 minute limit means that dispatches don’t really count after a total dispatch duration of 360 minutes in a day - the price reverts to the full tariff price for all energy supplied.
- I am uncertain as to when, exactly, domestic energy reverts to the full tariff price in response to the 360 minute limit. I understand that UK energy supply rules mean that all energy supplied in a
chunkmust be supplied at the same price. If the 360 minutes expires partway through achunkis all energy in thechunksupplied at reduced price or full tariff price? I have not seen any information to resolve this question.
Kraken assigns the Device a status (the CurrentStatus capability), but this does not seem to accurately reflect whether the device is receiving a dispatch or not. It only reflects that (a) the device has been “on-boarded” by Kraken and is capable of smart control and (b) whether it is plugged in or not plugged in.
My understanding from the information provided by Octopus is that a PlannedDispatch always counts towards the daily limit (i.e. a dispatch-minute is consumed even if the device does not receive power during that minute). The metric that seems to be important to Octopus is the total energy dispatched to a device during a plan of PlannedDispatches (e.g. the EV will receive 45kWh across the whole of the plan). This is the “promise” that the dispatch plan makes.
For the weird “unnecessary” PlannedDispatch in your second post. If the system says there is a PlannedDispatch then the App will reflect that. If that dispatch takes you above the 360 minute limit then the price should revert to the bump rate after 360 minutes of dispatch (in a 24 hour period).
I am unable to comment on why Kraken would schedule a dispatch even when the device is fully charged. BUT, I am sure that, the fact that a dispatch is planned by Kraken means that it will count towards the dispatch limit and that domestic energy prices will be reduced during that period too. This problem feels like a question for Octopus rather than for the app.
I agree with you. It looks like it is a question for Octopus - especially the second scenario - this is the one that most concerns me as we have 2 EV’s. If the 360 limit was live I would have very little time left today to charge our second EV at the 7p rate.
I am wondering if it is because the amount of kWh requested by me over the period was greater than the spare capacity in the car battery. From digging around, my zappi charger is still in boost mode trying to deliver the amount of boost set by octopus? Which looks like it was greater than the spare capacity in the battery.
In most EVCP you should be able to disable the random delay start.
myenergi do not let you override the setting on their zappi chargers. Octopus used to be able to override it, but a recent firmware update on the charger has disabled this 
That’s annoying.
I have Hypervolt with Octopus control and can still override.
Version 1.0.42 Published
In this release, the slider interface for Period Start Day has been removed; you now change the Period Start Day by using the settings of a device. The settings are common across all the Homey Devices created from the App. You can modify the setting in any device and its new value will propagate across all of the Homey Devices.
In addition, two additional settings have been implemented. The first is to change the Maximum Dispatch Minutes per day. I have set the default for this setting to 360. If Octopus has not implemented the 6 hour limit, choosing a value of 1440 (=24 hours) means that the limit will have no effect. The range is from 0 to 1440 in steps of 15 minutes. This setting is fully implemented.
The second new setting is to modify the Kraken Polling Interval. This setting is not yet fully implemented - you can change the value in the Settings, but the change will have no impact. I plan to improve the way the polling works in the next release and will implement the polling interval setting fully at that point.
Accessing The Settings
Right-click on any of the Kraken Energy Homey Devices and choose settings.
The settings dialogue is displayed:
Scroll down to advanced settings:
Change the settings to the values you want and press Save. The changes will be propagated to any other Kraken devices you have set up.
Next Steps
- Submit the app to Athom for publication (wait…)
- Implement polling interval changes
1 Like
Release Usage Analysis
| Version | Installs | Crashes | Crash Types | Comment |
|---|---|---|---|---|
| 1.0.42 | 35 | 1138  |
1 | Researching cause and potential fix |
| 1.0.41 | 1 | 0 | 0 | Published 2026-02-04 14:22 |
| 1.0.39 | 3 | 0 | 0 | Published 2026-01-11 17:25 |
| 1.0.38 | 3 | 246 | 1 | Affected user has upgraded 2026-01-11 20:23 |
| Totals | 42 | 1374 | 2 | Older versions all retired with 0 users |
93 Kraken Devices
@ 2026-02-09 21:05
