Any plans to add month period metrics like the electric devices have?
Not sure if youre using their REST or GraphQL endpoints
Reference | API docs - looks like you can pass it dates to fetch. Theres probably a graphQL equivalent as that API is much bigger, but I could find it after a ‘quick’ search
Yes indeed. I have decided NOT to integrate Gas into the Energy Account device - so that really becomes an “Electricity Account” device. The decision driven by the difference between measured energy (and cost) for electricity vs. calculated energy (and cost) for gas.
My plan is to use the period-day logic in the Gas Device and add capabilities for Period Consumption, Period Cost, Period Standing Charge, Gas Bill [to date] and Estimated Gas Bill. I already have a version where I have added Chunk Consumption and Chunk Cost (as a part of the Account device “emulation”).
The down side is that the Total Energy cost (covering both Gas and Electricity) won’t be covered anywhere. Not sure that’s too important, though.
Just so you know, the accumulation to chunk, slot, day and period doesn’t use extended date ranges, it just picks up the minute-by-minute (chunk by chunk for gas) consumption and sums it in the app. If you are feeling incredibly bored and willing to go through a considerable amount of frustration and pain, you can learn all about the GQL api into Kraken, and practice using it too, here
Not integrating them together is probably a good idea as there are people that dont have gas tariffs for reasons
Your plan is a good one as long as the API allows you to get the data to be honest. I looked at the GraphQL API and just thought ‘nah, cant be dealing with that’’
Looks too complicated, why they went this way I dont know. I find REST far easier
Total energy cost can be calculated with a script if people really want it, but I agree, not really a problem especially as the bill for gas/electric/export are separate entities when it comes to the customer anyway
Complexity is true, but so is completeness. REST has annoying gaps like marrying PRODUCT and TARIFF - that requires that you make assumptions about how product codes are “embedded” in tariff codes. That’s true today, and for Octopus, but what about future products and (perhaps) other companies using Kraken? The killer - in REST there is NO live telemetry. So it just was not an option for Homey. Once you climb the mountain, GQL is very consistent and predictable so actually isn’t that much of a problem.
I note that the HA Octopus app uses a combination of REST and GQL.
So im reading this as, Kraken are behind the mini and also it comes with GQL API as standard.
Octopus already had an API, and that is REST
This is why there are both - makes sense
APIs are not new to me, but Homey and Jscript is - its a bit of a learning curve
Before I discovered Homey and HA (and I still use it tbf) I was using a python script that Ive modified over the years to get live and historic data, put it all into influx, and then out to grafana
Recently, I also had solar/battery installed and integrated that into my grafana dash
Grafana is nice and all, but looking for something native now, to get it all in one place. I also have little time these days to fiddle about with stuff like this (recently became a father)
Hence Homey
I have HA and Homey. I use Homey as my “main” environment - hence my drive to the get Energy tab working the app. All of the devices that represent my Home Battery do not fully integrate into the Energy Tab. Right now (well last time I looked) Advanced Virtual Devices don’t fully support the settings required by the ET. I wrote this low-code app just to fix the problem.
I got the PV into the energy tab using an AVD too. Finally the grid data comes straight from the Octopus Account device. Apart from the annoyance of NOT being able to point the ET at a capability and saying “hey, there’s the price data”, it all works really well.
My main use case for HA is better support for “weird” Zigbee devices (and normal Zigbee devices too). I use zigbee2mqtt, pick up the mqtt inside HA then map that into Homey using the Homey Community App. It’s uncomfortably long as a chain, but it works and is reasonably resilient.
I have also used the Homey → HA integration to map the Octopus devices into HA and set up the HA Energy tab using that (along with my “unreal battery” and solar PV). That works pretty well too.
I guess I’m using HA as a “server” [of some sort] and Homey as the client. MQTT, HA and Homey SHS all run on the same machine - an old Asus C302 Chromebook that I installed Zorin linux on once it stopped getting updates. It’s lightweight and works well. My Homey Pro is my Homey “production” environment. I have automated charging the laptop too - it uses a webhook to pass data into Homey then a Homey flow controls a smart-plug so that the battery level on the machine stays between 15% and 90%… That works really well and is protecting battery life too.
I have installed Kraken and managed to connect it to my Octopus (UK) account. The app shows correctly the monthly billing start/end dates but that it all. How do I get it to read the energy data. I have a smart meter installed from which I can get this information but I would like to integrate it into Homey Pro 2026 for greater benefit.
Hello David. You need the Octopus Home Mini (OHM) to get the live meter readings. Do you have an OHM? If not, it’s interesting you were able to set anything up because (in theory) the pairing code should detect the absence of an OHM and refuse to pair. Suggests my validation code still isn’t up to snuff. Please let me know so I can either help you further if you already have an OHM or to confirm that you don’t.
If you don’t have one yet, then order one on the Octopus website. They take a while to arrive but (generally) are not hard to set up.
Thanks, David. I didn’t see any reference to the OHM requirement previously. I have now ordered one from Homey and will let you know the outcome when it arrives.
It is mentioned on the app store page, but maybe I need to be more explicit there. Thanks for the heads up…
The Kraken Energy app provides access to electricity import and export data from energy providers who use Kraken Technology to manage their customer data. It requires the use of a physical device such as the Octopus Home Mini that provides access (via Kraken) to live meter readings. There is no access provided to live data from gas tariffs, consequently this app does not support gas consumption data.
I concede the error is mine. I had assumed a Home Mini was an alternative version to the meter I already have. I’ve ordered on and will let you know in due course if this solves my problem.
Hi David. No concession warranted - if the pre-requisite is not clear enough then I should do something about it. As I said before, “thanks for the heads-up”. Looking forward to news when the OHM gets to you.
Been all quiet here for a while - to be honest been taking a break from building this beast. First an alternative app you might want to take a look at:
I haven’t installed it - if you decide to, let me know how you get on. Be aware of the API polling limits - you may need to use the settings in the Kraken app to slow down the polling rate if you decide to run both.
Update on Dispatch Limits
I understand that Octopus is rolling out dispatch limits over a period of time. Here’s how I understand things and what will need to change to keep the app as accurate as possible.
Dispatch limits will run from midday to midday
All the rules around a single charge rate per 30 minute chunk still apply
If any part of a chunk is covered by a discounted dispatch then the discounted price applies to all energy supplied in that chunk.
conversely if any part of a chunk is covered by a higher-rate dispatch then the higher price applies to all energy supplied in that chunk.
Dispatches can be planned and changed at very short notice meaning that there is no way of knowing at the start of a chunk whether or not a dispatch will be made at some time during the chunk.
All of this means that there is NO WAY of knowing the price per kWh that will be applied at the start of the 30 minutes chunk. Consequently cost can only be calculated per chunk at the end of the chunk.
Planned App Changes
Adjust the minute counting cycle to work from midday to midday (not midnight to midnight)
Remove minute-by-minute calculation of cost from the app for all users. Instead, cost will be calculated at the end of each 30 minute chunk - energy_consumed * price_applied
The second item represents a downgrade of functionality for non-IOG users, but it seems to be the only way to calculate cost of energy accurately. All other functionality (especially minute-by-minute monitoring of energy consumption) will remain unchanged.
Other Planned Changes
Complete the implementation of the Gas Tariff device to include Billing Period information and bill calculation.
Feedback Is A Gift
Any comments on the app, requests for features, reaction to these plans gratefully received, as always.
