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.
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
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.
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.
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):
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).
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 - 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:
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!
- but that was enough! The new mechanism makes the chance of publishing test data vanishingly small (never say āneverā).