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

Apps
,
201

Request for Assistance from IOG Tariff Users

One user of the Kraken app is seeing planned dispatches listed (and acted on in terms of executing flows) even though their device is unplugged. The dispatches do not show up in the Octopus app, but are real in the data (been and queried the data at source).

Have any other IOG users seen this behaviour?

I am unsure if Octopus will honour the dispatches in terms of the tariff price. If they do honour the dispatch no harm done. If it is not honoured, then I need to work out how and when to exclude planned dispatches. In this case the device status was shown in the app as Device Unavailable (this is equivalent to the Kraken status SMART_CONTROL_NOT_AVAILABLE).

Any information that any IOG users can provide will be gratefully received so that I can improve the Kraken app.

MTIA.

202

It’s not something I’ve seen. Is it a recent development with a recent release or an ongoing problem?

203

Proposal For Improved Dispatch Processing

Based on my earlier post (quote above) it appears that the App needs to filter dispatches more strongly. Dispatches should only be used by the App then the device status is one of:

  • SMART_CONTROL_CAPABLE (device can receive dispatches but nothing is planned)
  • SMART_ CONTROL_IN_PROGRESS (device is plugged in, ready to receive or is currently receiving)
  • BOOSTING (device is plugged in, ready to receive or is currently receiving at BOOST price)

In addition, the App will switch to BOOST price when a BOOST dispatch is in progress

204

It’s in the current release, but the processing of dispatches has not changed significantly for many releases now. The app is executing correctly given its current design. BUT the underlying assumption of the design is that “a planned dispatch is always relevant; in particular a dispatch planned for NOW is actually HAPPENING”.

The problem reported today is the first evidence I have seen that this is not the case.

I stress, the planned dispatches are real in the sense that they are listed on the users Octopus account. The Kraken system itself seems to have planned dispatches even though the device is not currently capable of receiving them. The resolution, then, is for the Homey App to reject dispatches when the device status indicates they cannot be received.

205

Hey David, I’m really enjoying the Kraken application. I had a quick question—would it be possible to get a daily breakdown showing how much of my total energy usage occurs during off-peak periods versus on-peak periods?

The reason I’m asking is that I’m trying to determine how much storage capacity I would need to run my entire system using only off-peak energy and avoid peak charges. Having this data would allow me to make a more informed, data-driven decision rather than relying on rough estimates.

206

Hi Gareth

Yes, this is one of the planned features - if you search way back in this thread you will find me burbling about Tariff Efficiency - that’s the very concept you are talking about. I have not done any detailed design yet but the loose plan is a “Tariff Statistics” device, and Tariff Efficiency will be one of the measures. The foundations are already there in terms of the Price Quadrant [PQ] measure that is calculated for each Tariff Price Slot - so my concept is that Tariff Efficiency is a measure derived from the percentage of consumption that occurs in each PQ. An alternative definition would be to calculate the average price per kWh that you have paid as a percentage of the minimum price.

In Cosy the minimum price is about 12p right now (max about 48p, mid 24p). In Feb I paid an average price of 15.25p per kWh - so that’s 127% of the theoretical minimum (so efficiency is -27%?).

An alternative formulation is “saving efficiency”. Using my example prices, the max saving from the mid rate is 12p and in Feb I achieved 8.75p - 73% of the theoretical maximum saving. There’s a clear relationship between these two measures.

My quartile numbers were Q0=89.5%, Q1=0 [there is no price band in Cosy that falls into Q1], Q2=10.2 and Q3=0.3%. I’m not sure of the algorithm to turn those values into a “score”, but one idea is to weight the quartiles Q0=+3, Q1=+1, Q2=-1 and Q3=-3. Using this schema my score is 2.574 out of 3 (or 86%). One benefit of this approach is that low efficiency gives a negative score - if all energy were consumed at the maximum price your score would be -3 (or -100%).

BTW I think daily, monthly and annual (12 month moving average, perhaps) would be a great approach to monitoring this stuff over time.

So, yeah, lots of ideas. And its definitely on the list. Happy to explore these ideas further.

Whilst the app is in such active development (and I often have to delete devices for test purposes, so building up a historical record is a challenge) I am maintaining my spreadsheet view of the world. Here’s the chart for the last 12 months of my Price Band efficiency (not quite Quartiles):

image
image2014×767 98.7 KB

The dotted line shows the month by month “saving efficiency”.

207

Me too. I find that 95% of the time my existing 5kWh battery runs the house for at least 1.5 hours (colder days less, obviously - more heating). The longest gap between cheap periods in Cosy is 5 hours (07:00 to 13:00) - so to cover the full 5 hours would require 15kWh (round numbers). But I also use the house as a heat battery, so out of the 5 hours, 3.5 is probably enough. I am budgeting for doubling the battery as a first step.

Running out of battery mostly triggers mid-rate consumption. The only days in the year we consume (more than a few watts of) high rate energy are the 2 or 3 coldest days of the year. The house cools down more quickly and the heat pump kicks in before the end of the high rate tariff slot.

Reviewing my data for the last year the house consumed 3046kWh at cheap rate, 328kWh at mid rate and 17kWh at high rate (really pleased with that last number). The house exported 2529kWh. If I eliminate all of the mid-rate consumption that’s a saving of about £82 per year or 67% of the cost of energy (ignoring daily standing charge).

208

Version 1.2.3 Published In Test

Evening all. Following the most recent data-driven clue as to how Dispatches and Smart Devices actually behave, I abandoned the idea of publishing 1.2.2 as a production release. Instead changes have been made to the way that Dispatches are detected. I have taken the opportunity to correctly handle BOOST dispatches in the Import Tariff device - a high price will now be indicated during a BOOST dispatch.

I have finally bitten the bullet and found a more “professional” way to handle my test data. It only got published once :flushed_face: - but that was enough! The new mechanism makes the chance of publishing test data vanishingly small (never say “never”).

It’s a test release so you will need to install it manually using the following link:

209

Version 1.2.3 Publish As Live

At the risk of repeating myself I have not seen any reference to problems with 1.2.3, so I plan to submit it for publication to Live status this evening. Please contact me if you encounter any problems today. Thanks!

210

Version 1.2.3 Usage Analysis

Version Status Installs Crashes Crash Types Comment
1.2.3 Live 70 0 0 Published live 2026-03-16 08:30
1.2.0 Superseded 3 0 0 Published 2026-03-04 11:00
1.1.0 Superseded 6 999 1 Defect upgrading from prior releases, resolved by deleting and re-adding any device
1.0.39 Superseded 3 0 0 Published 2026-01-11 17:25
1.0.38 Superseded 3 246 1 Affected user has upgraded 2026-01-11 20:23
Totals 85 1245 2 Older versions all retired with 0 users

165 Kraken Devices

@ 2026-03-19 21:40

Status

Version 1.2.3 addresses an issue found with Smart Energy Devices and the processing of dispatches. It appears that under some circumstances, Kraken will plan dispatches even though the device is not in a state to receive them. The app was processing those dispatches as usual. State handling for Smart Energy Devices now ignores planned dispatches unless the device is in a state to receive them.

Version 1.2.3 has been published as “Live”. It seems to be running smoothly with no crashes reported and no problems with data being updated correctly that have been shared with me so far.

Please Upgrade

I encourage all remaining users on versions older than 1.2.3 to upgrade. For those that have not upgraded, I suspect that Automatic Upgrade is probably turned off on your Homey. You can upgrade either by switching Automatic Upgrade on for the app or by installing the app from the App Store.

211

Progress Update

Been several weeks that have felt more or less like my head and a brick wall… Trying to solve the memory creep problem. Extensive changes to the architecture have delivered real benefits in terms of CPU and total memory consumption - so that’s good. Changes made in the last couple days are showing signs of slowing the memory creep significantly. It feels like some real progress. Things are really slow because I have to test each change for an extended period of time just to see if each change has an impact or not. I apologise for not delivering any “new stuff”.

Version 1.2.3 Update

I am really pleased with the uptake and performance of V1.2.3 - over 70 users and no crashes so far.

Today I received a diagnostic log from a user who is not seeing any updates to their devices from the app. This seems to be related to a failure to detect an Octopus Home Mini on the account - but we shall see. Even if it turns out to be account related rather than a data or app problem, it points out the need to be more robust at pairing time in checking for the presence of an OHM.

Further update. Exchange of PM with the affected user has confirmed that the OHM is not linked with a live meter on the account. Once the meter goes live the app should pick up the user’s OHM automatically. Will wait and see. Better checking in the Pairing process can avoid this problem in future.

212

Version 1.2.4 Published To Test

I have published Version 1.2.4 as a test version. This version gives you the benefit of a smaller, more stable footprint and less CPU consumption. It also resolves the problem reported by a new user whose Octopus Home Mini is not yet live. If there is no OHM registered against the consumer’s current meter points then no devices will be offered in the Pairing dialogue. Once the OHM is available to the App then the pairing will proceed normally.

Here is the link to the test version.

213

A Word of Warning - Data Access Limits

The Kraken app relies on access to the Kraken API provided by Octopus/Kraken. There is a throttle applied by Kraken to the number of SmartMeterTelemetry requests that can be made by an account in each hour - the current limit is 125 t/hr. The kraken app consumes just under half of the limit - one request per minute.

If you operate another app (e.g. OctoAid for IPhones) this will consume requests against the same limit. If you view your live consumption in the Octopus App or webapp, this too consumes against the same limit. You need to be aware of the limit otherwise one or more of your apps may not be able to read the data it needs.

A forthcoming feature in the Kraken App will allow you to throttle the transactions that it makes (frequencies of 1, 2, 3 and 5 minutes). The work is underway as part of the extensive re-architecture that I have been executing, but is not yet complete. If, in the future, you use this throttle and are an IOG customer, be aware that the frequency of reading PlannedDispatches will also be impacted.

For your information there is a limit on PlannedDispatches queries too - of 5 t/min. But if you have 2 smart devices this requires 2 transactions to be executed to get the PlannedDispatches for both devices. Logically, the limit on the number of devices on an account without throttling the transaction rate is 5. But, again, the limit is per account - if you have other apps reading PlannedDispatches these will consume the same “puddle of transactions” as the Kraken app.

214

Progress Update

Code changes for the new architecture are complete. But there is a whole raft of testing required. This is how it may affect you:

  • Account Data and Device Definitions are read ONCE PER CHUNK (30 minute period).
  • Consumption Data, Planned Dispatches and Device Status Data are read ONCE PER MINUTE

Account Data and Device Definitions

This is data that changes infrequently. The most dynamic part of the data are the Tariff Prices for Tracker Tariffs - half hourly prices that are different every day. These prices are published sometime in the afternoon of the day before then do not change again once they have been published.

This is a big lump of data and accounts for a lot of network traffic created by the app. By reducing the frequency of access some updates will be slowed - the most relevant is probably the “Tomorrow’s Prices Published” capability (on the Tariff device). That seems to be a low impact change that saves a lot of resources on your Homey.

Consumption Data, Planned Dispatches and Device Status

This is all information that changes all the time, so needs to be accessed as frequently as possible to keep the data in the app current. The volume of data is relatively small.

Next Steps

  • Extensive testing - I have run the code for 24 hours and found one capability calculation error so far. The quality seems good. I also need to “switch on” my IOG test data and test with Smart Devices.
  • Publish as a test release, then live.
  • Fully implement the Variable Polling feature so that you can choose to read the volatile data every 1, 2, 3 or 5 minutes.
  • Test this feature with and without IOG test data
  • Publish as a test release, then live.

After that I shall be able to use my Homey Pro as a production device and Homey SHS as a test device and finally be able to get some long-term insights into my energy efficiency.

Next Features

This is YOUR CHANCE to ask for what you want to see added next. On the list (in no particular order) are:

  • Octoplus - see your points and their value; automate the roulette wheel each month (is the roulette wheel still a thing?)
  • Energy Saving sessions - automate the sign-up for energy saving sessions; WHEN flowcards for sessions starting and stopping
  • Free Energy sessions - not sure what is required here yet (or how to get to the data)
  • Gas tariffs
  • Homey energy stuff
  • Tariff Use Efficiency - some deeper “insights” into how well you optimise consumption at different prices, some longer statistical data (e.g. 12 month moving average bill)
  • Less frequent but potentially important WHEN cards (e.g. WHEN import Tariff Product changes - signalled if you move from a standard tariff to IOG or tracker, for example)

Let me know - otherwise I shall just pick and go…

215

Thanks David.

216

Progress Update

It’s going well. I managed to divert my attention to some other challenges whilst the necessary duration of testing goes on. A couple more days should see it done!

Energy Tab

Not sure there are many users for this in the UK. The major block is the inability to get prices registered in the UK. Why on earth Athom have not done the logical thing which is “hey there’s a capability over there, that’s the price, plug that value into Energy calcuations”… I have no idea.

When looking at it at first (and indeed second), the whole mess of data and symbols was hopelessly confusing. Magic numbers seemed to be springing out of the woodwork all over the place. It’s not helped by the fact that the Energy Tab samples data relatively infrequently so peaks and troughs in the data are often missed. This makes it hard to relate the data displayed to the data in the capabilities of the devices.

In the end I went for the analytic approach. I excluded everything from Energy. A blank energy tab. That’s a start at least.

Which Kraken device makes the most sense to put in the Energy Tab - the Energy Account was the choice. It’s set up to be the “master of the grid energy universe” - essentially tracking ALL grid energy coming in (and going out, too). I understand that other devices that take load “deduct” this energy from that provided by the Grid Master.

Here’s my really simple Energy Tab since finishing the wiring up at about 8:30 this morning (when the graph starts moving). At that time there was a moment of import - after that everything has been export:

image
image2510×1412 298 KB

Notes:

  1. The number above the roof (-4.9kWh) is the amount of energy today (negative for export)
  2. The “pill” under the house is the Octopus Account device showing flow of power (-1.9kW)
  3. The green flash on the pill shows export (blue for import)
  4. The equation is Import Energy Today - Export Energy Today = Net Energy Today
  5. The graph shows rate of power flow over time (export below the X-axis)

Setting It Up

This functionality IS NOT IN Version 1.2.3 or Version 1.2.4 - you need to wait for the next release, hopefully in a few days.

When you install you will need to ensure that the energy settings for all your Kraken Devices are set correctly. They are probably pretty random right now (because so far it hasn’t mattered). On the webapp right click on a device and choose settings. Scroll down until you see Energy.

On mobile app long click on a device to view the capabilities, use the cog-wheel, top-right, to get to settings. Now choose Advanced Settings to see the Energy settings.

For IMPORT TARIFF, EXPORT TARIFF and SMART ENERGY DEVICE Homey devices the required Energy Settings are:

  • Tracks total home energy consumption: No
  • Exclude from Energy: Yes

All of the energy tab functionality is supported by the ENERGY ACCOUNT device, the required Energy Settings are:

  • Tracks total home energy consumption: Yes
  • Exclude from Energy: No

Trying any other combination of settings will likely upset the Energy tab and create a really confusing display.

Confusing Data

When I first looked at the Energy Tab it was horribly confusing. The ONLY way I could get to understand it was to go back to first principles and exclude everything before re-adding stuff in a very controlled fashion. You might want to do the same to convince yourself that you are seeing sensible data!

Please remember, I am not responsible for the mess that other devices from other apps make of the Energy tab. It seems to be a bit like the wild-west out there. But Kraken behaves :innocent:.

My Bottom Line

“Well, it’s a pretty picture, but I’m not sure at adds any value…”

217

Release Plan

I have tested the new architecture as well and as comprehensively as I am able.

There is one narrow window of possible failure for Intelligent Octopus Go customers that I am unable to close with any tools at my disposal. I have had to change the devices component of the live meter (high-frequency) api call. I have tested the query through the Kraken query test tools and the query works, but there is a small chance that something will be different in the live environment. I have tested the app with dummy data that the query should return. It all works separately, but there is still that small, nagging gap - I haven’t been able to test the query in the app and get real data back to process.

For users of other tariffs, the detailed testing I have performed covers all aspects of the data being retrieved from Kraken and I am confident that the significantly modified code does the same job as the previous version but much more efficiently.

The Plan

To mitigate adverse effects on all users my plan is as follows:

  • Convert version 1.2.4 into a “live” release - this provides a fallback path for any user who encounters problems with the upgrade to the next version. Version 1.2.4 has been “in the wild” for some time and has not generated any errors or problem reports that have been brought to my notice. I believe it represents a “safe harbour” as a fall-back should things not work out for you.
  • Once Version 1.2.4 is live I will publish Version 1.2.5 as a “test” release. Can I ask that as many of you as possible try it out, please? It is a substantial change in architecture - in consequence it is not risk free. But the safe-harbour of 1.2.4 is good mitigation for you.
  • Most of all, if you encounter problems with what will be Version 1.2.5, please let me know as soon as possible so that I can alert other users and also resolve the problem

Thanks for your help!

Next Steps

After Version 1.2.5 there will be at least one more 1.2.x release. It will implement the variable polling frequency feature. This will make my development and testing life so much easier.

After that I think the priorities are:

  • Energy saving periods - will probably need to pick up Octoplus stuff at the same time

  • Gas Tariffs - I need a volunteer to act as the Gas Guinea Pig. I have no idea how the live-ish data stuff works for Gas, so stand no chance of doing anything without help from the community

  • Energy stats - this is my long term aim - to get meaningful data analysis and presentation out of Kraken (and maybe other Homey apps). To give you an example, here is a chart I produce by manually combining data from 3 sources (Kraken, Solax and Ecodan Heat Pump) - I call it the energy wave; it summarises sources and sinks of energy for my home. It’s never going to be reproducible just in Homey, but if data feeds can be automated into Sheets (Excel, Grafana, whatever) then…

    image
    image2029×559 67 KB

218

I’m on the tracker for gas. Gas updates are less frequent than electricity.

219

@stu_f Will be in contact about how we can work together to add Gas…

220

Version 1.2.5 Published To Test

This is the finalisation of the substantially re-architected version of the app with “heavy” and “light” transactions fully implemented. You should see a substantial reduction in memory footprint, less growth of memory use over time, and less CPU too.

Heavy and Light Transactions

Data has always been requested from Kraken in two separate lumps. But both requests were made at the same frequency - once per minute. The two transactions have now been completely separated and each works to its own heartbeat. As a reminder:

Light Transaction - Every Minute

Reads the dynamic data - consumption (obviously) and, for Intelligent Octopus Go customers, planned dispatches and device statuses. This data changes very frequently, so is read every minute.

Heavy Transaction - Every Chunk (30 Minutes)

Includes the light transaction and, in addition, refreshes the account data, including tariff prices. This data is refreshed every 30 minutes. Consequently you may experience a short delay before being notified of account related events - specifically tomorrow’s prices being published. This doesn’t seem a huge penalty to pay for a substantial performance benefit.

Note that additional heavy transactions occur at App startup (to get the stable data in the first place). An additional heavy transaction also occurs when a new Homey Device is created in the app - to ensure that its stable data is present for use.

Dynamic data is not delayed, in particular live meter readings and changes to dispatch plans are tracked every minute.

Other Changes

There are no other significant functional changes in this version.

As discussed in a previous post, minor changes have been made to the Octopus Account device to allow it to act as the overall Grid Controller in the energy tab. Please review this post for further instructions on how to set it up. As a reminder, I did not find the Energy Tab easy to use from first principles - the only way I found I could develop an understanding was to remove everything and start with a blank canvas. My experience is that many devices do not correctly implement the Energy Tab settings, this can lead to further confusion as data is “mis-interpreted” by the Energy Tab.

I have managed to gather some knowledge and will try to answer any questions if you have them. I may publish a separate post describing the hoops I had to jump through to get the thing working understandably. I only managed to solve the last weird-thing this morning. :face_exhaling: