Pride Goeth Before A Fall
Ahh, the hubris. App goes live. App crashes. Hey ho.
Good News
The Kraken Energy app is now live. Thanks Athom.
Bad News
Got a crash right afterwards.
1 Like
Bug #19
I have documented the new defect in github as Issue #19. I shall run the code overnight to ensure I have not broken anything else with the change I have made. Following that I shall release for wider testing before publishing again.
Request For Information
The crash was first reported today at around 10:30. As far as I can see, the publication of the app has not added any new users, so I speculate that a test user with an old release has upgraded (either manually or automatically) to the Published Release. It may be that the only resolution is to either remove and re-add devices, or a complete re-installation of the app.
The crash data shows that the app is crashing once per minute. I suspect that one user is experiencing this problem. The crash data shows that it occurs as part of the timed-loop to update the Homey devices - that loop runs every minute.
If you installed the app as a new user at or around 2026-02-09T10:30, or if it was upgraded for you automatically and if you are experiencing crashes (every minute or so) please contact me here or via PM so that I can more thoroughly understand what is going on. Thanks!
Next Steps
- Personal testing overnight
- Publish as testing release for a day or two
- Re-publish to live
1 Like
Another Worm Uncovered
Identified a problem calculating the Period Duration (to be fair to myself it will only appear in February 
). Fixed that. Doing more testing. New test release tomorrow.
1 Like
More Testing
I have taken the opportunity of the improvements to Period Handling to refine the calculation of the Projected Bill. Thatās not calculated for the first day that the device exists (or of the period), so it takes a while to test. Just refined the calculation further and need to do a bit more testing before releasing the update. Itās looking good now, so release tomorrow all being well.
1 Like
Iām very happy to say that thanks to the excellent work from @David_Piper here in developing this tool I managed my first automated control of my SolarEdge battery whilst charging one of our cars.
In short summary, I have faced an issue with the randomness of the Octopus Dispatches and preventing not only discharging of the battery in to the car but also in preventing peak charging of the battery when Octopus changes itās mind on what time slots they want to give me.
Itās early days and there are many more possibilities with this tool, but at this point I know that I can safely plug in a car at any time, and have the battery charge from the grid during the low rate dispatch Octopus issues to charge the car. Alongside that the automation will prevent the battery from being discharged in to the car, as well as ensuring that if at any time the off peak window changes the battery mode will also be changed accordingly.
A huge thanks to David for his help and support, because itās clear that creating these advanced flows is very far from my forte. 
2 Likes
Thanks for the kind words, @Stu_F. Great to see to some very real benefits coming from the automations the app supports.
1 Like
Problems Publishing
Hi Folks. Had some problems publishing the new version to the App Store this afternoon. It appears that published versions after 1.0.42 (the version released by Athom) are corrupted in the app store and ARE NOT INSTALLABLE. Please DO NOT ATTEMPT TO INSTALL ANY VERSION AFTER 1.0.42.
Apologies for the delay. I have a support request into Athom and will let you know when the problem is resolved.
Version 1.1.0 Published For Testing
Good news, the problems with publication to the Homey App Store appear to have been resolved overnight (by magic, I presume). Here is the link to the new TEST version:
I am hopeful that this version will resolve the problems encountered by a couple of users in the Published Version. If you are currently having problems with the App causing errors and stopping all the time, please do make a point of trying the new Version 1.1.0
Why 1.1.0?
Just because I was having problems with the Homey App Store, I wondered if publishing a more substantial increment in the version would trigger a new baseline. Apparently not.
Upgrading
As before, you will need to upgrade manually because automatic upgrades only work between fully published versions, not to test versions.
Rollback
You can move back to the recently approved published version by clicking the link āBack to the regular versionā:
2 Likes
Version 1.1.0
Has been running for more than 24 hours with 30 users and has not reported any crashes. The code in the area that was causing the error in 1.0.42 has been refactored and made more robust - though I still donāt understand the specific cause of the error.
I have submitted 1.1.0 for live publication. Users will be automatically upgraded once that has happened and we shall see what happens.
My estimated bill was looking about right before the upgrade at Ā£97, it is now saying Ā£483? Iām 19 days into the period.
Itās really hard to get right in the first month for everyone because of the different use cases that need to be dealt with. I thought of the use case where there is a new device created in the middle of a period (day 19, perhaps). In this case you only have a few days observations to include in the calculation and it will do a far better job than the old algorithm. This covers all future new users of the app.
For existing users, in the future, when you have data from the start of the period it will work pretty much as before.
The case I forgot about is the āitās an upgrade from the old algorithm, I should take into account the old estimate and assume the device was in existence from day 1 of this periodā.
Sorry about that.
The figure will remain an over-estimate this month because you have all the days of consumption data, but the algorithm is assuming you only have a few days of observations. Once you get past this month it should settle down and be a sensible projection of what the actual bill will be.
If it looks stupid at the start of the next period, let me know. (Iām monitoring mine, too).
Version 1.1.0 Usage Analysis
Itās been too depressing to publish this for 1.0.42 - two users experiencing a crash one a minute soon mounts up 
. 1.1.0 looks clean so far (famous last words). 42 users and no crashes.
| Version | Installs | Crashes | Crash Types | Comment |
|---|---|---|---|---|
| 1.1.0 | 55 | 999 | 1 | Published 2026-02-16 |
| 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 | 61 | 1245 | 1 | Older versions all retired with 0 users |
107 Kraken Devices
@ 2026-02-24 18:40
1 Like
Recent Progress
Now that the app has been published by Athom, I started paying some attention to the footprint of the app in your Homey. CPU has been fine from the start. Thatās not surprising it only does stuff once per minute and then itās ājustā read some data, do some calcs, update Homey devices. Despite this the app, as downloaded, was over 90 files and about 6MB in size.
I have been using 2 NodeJS modules - Luxon for date handling and JSONata to help with navigating and processing the deeply nested and extremely variable structures from Kraken. Reading around on the Homey Fora, I found Package Bundler by @robertklep - grateful thanks to Robert.
That helped a lot and got the install size down to 45 files and 2.5MB.
Then I started looking at App performance after install. CPU was fine, but memory consumption was way OTT and increasing over time (never a good thing). Did some quizzing using Gemini. It suggested that JSONata was notorious for hogging memory by leaving uncollected garbage around after processing. That made me bite the bullet and do the work required to get rid of JSONata.
Marginal gain in download size 44 files and 2.4MB. Significant benefits in terms of memory consumption during execution. Hereās a chart of HEAP memory - no more increasing over time. Hoorah.
I am in the midst of reviewing the architecture of the app. It is clear that itās hard for the NodeJS VM to garbage collect with the current architecture having multiply referenced global structures. I have already done some work that has further reduced memory size and improved garbage collection - as evidenced by the bumpy but flat line for heap memory.There is more to do and thatās going to be my priority for the next few days. I have a (more-or-less cunning) plan but it will take a little time to iron out all the wrinkles.
1 Like
OMG the happiness I am feeling when I found Kraken app for homey many many thanks @David_Piper ! 1 thing that I am unsure of, I am a Octopus Intelligent Go customer and a Zappi user, I noted the installation of Kracken found the Zappi to as a device .. is this going to allow the holy grail of identifying when Octopus charge my car using a slot outside the usual 23:30-05:30 so I have a 7p slot to use for my home and also prevent my battery from discharging (important)
1 Like
Good news I think Gareth, thanks to some great work from David I think the app will do what you want. I donāt have Zappi, I have Hypervolt, but in this case I donāt think it matters. The tariff, IOG, can control your Zappi and depending on the controls your battery offers the Homey can control your battery.
in my case I have an automation that takes a notification that takes a signal from the IOG control by Kraken and can control the charge state of my battery. So Iām always in the right setting for the 23.30 - 05.30 slot, and also if I get dispatches outside of that it also controls the battery status.
A good example here below where Octopus were messing about around 23.00
So it works with a zappi as you see I have 4 future dispatches !! Can we reveal the times of the dispatches or is that not possible ! PS I have edited my Charging and battery control to use your new card as well
Do you use IOG to control you Zappi? If so, ignore trying to control the Zappi.
Iām using Price Quartile equal to zero to indicate a dispatch, and Price Quartile greater than zero to indicate pricing above 7p.
Something like this Gareth.
My flow is still under construction and probably over complicated, but it is working. Iāve been experimenting with Copilot AI to write my flows, itās pretty smart.
1 Like
Thanks Gareth - appreciate the feedback. Itās great to see some really positive use come out of the app. Suggestions are welcome - though they will take some time to materialise and I may argue the toss - but only in favour of getting the best possible outcome for the app.
Hi Gareth. I have thought about this, but I cannot see away of getting Homey to present a ālistā of information in the app. What may be possible is to provide a flowcard that will contain a JSON structure representing an array of scheduled dispatches. But then I am not too sure what you would do with that in a flowā¦ I guess you could log some messages in the timeline - but Iām not sure how that would help either.
As you can see on your Zappi device, you get the number of planned dispatches and, if one is in progress, its start and end times. You also get the time of the next planned dispatch start. At best you know about āthe current oneā and the ānext oneā. I can add ānext dispatch durationā to give a little bit more info.
Other than āvisual informationā what utility do you see in being able to see a ālistā of all future planned dispatches?
