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.