@Stu_F and I have been chatting about the complexity of his flow for a little while.
I think Stu’s use of AI to help write a flow is brilliant and raises the level of what less experienced users can do with Homey. But…
My experience of using AI is that the outcome depends very greatly on the way you phrase the question you pose (“prompt engineering”). I’m not that experienced in the use of NodeJS especially in the realms of synchronous and event based programming. Gemini has been really good at helping to refine the architecture of the app. But it is a very iterative affair.
Quite often I will start refactoring, get stuck and go to Gemini to ask about suitable patterns and suggestions to resolve the problem. Gemini then suggests something that turns-on a light-bulb in my head, so the next prompt is “OK, but what about…?” After the second prompt I find I get a much more evolved response. And so on…
I suspect that Stu’s use of CoPilot is a bit the same - immediate “how” questions have been answered (how can I write a flow that does X using these Homey apps…). In the case of Stu’s flow I would then start asking “but why is there a need to use Homey variables that shadow the values of capabilities…” or some such.
As an example… In a recent “chat”, Gemini suggested a solution to a problem. The solution exposed the inner working mechanisms of one class to another class (“breaking encapsulation”). It solved the problem, but in a really messy way. When I re-prompted about the “tightly coupled” mess being suggested, a much better solution was presented.
This is my simple flow which hopefully when a dispatches event occurs outside the 23:30-05:30 just starts charging my battery and I have 1 other flow to stop a dispatch and reset the battery time of use
Always good to see more examples of this type of flow.
There are things you are doing that lead me to think more can be done in terms of flow cards to automate more stuff. There might be some things you haven’t thought about in the flow, too. If you would like to discuss, send me a PM and we will chat outside the forum.
I guess it had to happen. New defect in 1.1.0 - that’s the bad news. Good news is I already knew about the problem and have code in the development version of the app to resolve it. Bad news I am in the midst of significant re-engineer so the replacement will be a few more days. Sorry.
The problem seems to be focused on a single user who has migrated from using an earlier version. If you are having a problem with the app, deleting your IMPORT TARIFF device and then re-adding it should cure the problem. You will lose any historical insights you have gathered, but the app should work properly thereafter.
Alternatively wait for the new release where the underlying problem has been resolved.
David & Stu Many thanks for the advice I have redone my Octopus IOG charging flow v3 Post Kraken implementation it seems more robust and 100% what it was intended to do
That’s marvellous. If I provide the Tariff Price capability as well as the Price Being Paid capability on the Import Tariff device then you can remove your reliance on “And… The time is between 05:30 and 23:30”. It can be replaced with a logic card “And… Price Being Paid is less than Tariff Price”. This describes exactly the condition you want - “am I paying less than the tariff price?” - if you are, then you want to charge the battery.
That condition is met at the moment between 05:30 and 23:30, but only until Octopus changes the timing or other rules.
Suggestions for flow layout that I have found helpful… In your diagram, there are two major flows depending on the value of PQ. I have found it helpful to put the “True” flow above the “And” card and the “False” flow below. That avoids the cross over of the “blue” and “gold” flow lines. The "When” card will end up somewhere in the vertical middle of your flow - which you may not like. The “True” flow proceeds UP the page, the “False” proceeds DOWN the page.
I also try and arrange my flows in three distinct columns. Column 1 is WHEN (you already have this by-and-large). Column 2 is AND. Column 3 is THEN. You can choose whether to make your flow wide (THEN cards proceed horizontally) or long (THEN cards proceed vertically) - or some compromise between the two.
You can see these principles in action in this flow that I use to stop my Solax inverter going idle at night (demand is low) and I have plenty of battery. On Cosy Octopus 00:00-04:00 is standard rate; with the inverter going idle, I ended up importing a chunk of standard rate electricity unnecessarily. This flow stops that happening by detecting when demand has been low for a while and turning on a heated towel rail that pulls about 180W - but only for 30 seconds. That resets the boilers idle monitor for another 5 minutes or so.
The architectural re-factoring is proceeding well. I have started running extended tests this evening and its looking pretty good so far. I also need to run extended tests with Smart Devices in place, so there is a while to go before I make the release. There is code in place to resolve the defect that appeared recently in V1.1.0.
In addition, there has been discussion amongst users of Intelligent Octopus Go about the need for a new When flowcard. I shall add this before making the release too. Unless you are an IOG user the flowcard will not be visible to you.
The timing of the update events has been tied to 15 seconds past the minute. This seems to be the earliest second that the preceding minute’s data becomes available. I shall re-visit the calculation of energy value (£) - I have realised that the current implementation prices the last minute’s energy using the current minute’s price. Most of the time this doesn’t matter, but at the change of a tariff slot or dispatch slot one minute’s energy will be mal-priced. The errors are small but will accumulate - particularly if you manage your consumption based on changes in price.
Finally the Projected Bill calculation has been refined (again). My testing suggests that the modified algorithm is working well. The new algorithm can even work on day 1 of a period - though the results are likely to be wildly inaccurate and extremely variable on such a short duration sample. Consequently, I shall leave it that the projection is only made from day 2 of a period.
The benefits of all this work are mostly technical. The app uses significantly less memory and CPU. This is useful to you because the Homey Pro is quite constrained for memory. Memory footprint seems quite stable over time.
Undone
Implementation of variable polling frequency (1, 2, 3 and 5 minute intervals) - the setting is already present but is ignored.
Next Steps
After the Architectural Re-factor and the implementation of variable polling frequency, I can re-focus on the backlog and start building some new stuff.
The bug in 1.1.0 is related to the need for some users to have to upgrade at least one device. That seems to have happened since the number of crashes is no longer going up. Several new installs in the last few days - that’s great to see.
Architectural re-factoring completed (subject to testing with Smart Device data). Here’s the performance graph for the app. PSS Memory plateauing at less than 44MB. CPU peaking at 10% for 10s out of an average of about 275s per peak.
From everything I have read the limits stated on the graphs are not treated as absolutes. Anyway many of you have been running the app with substantially greater memory consumption for an extended period without a problem. I have observed quite a few apps on my Homey (including “official” apps) - some of those are consuming 80MB or more.
I guess it’s pretty clear that things have not quite gone to plan with the re-factoring. The memory consumption has proved harder to resolve than I expected. I am now doing final testing (with simulated Smart Devices and Dispatches) of a release that I hope to publish sometime tomorrow. With the Athom review process it probably won’t be available for use until sometime on Thursday.
So What’s Going On?
In addition to the architectural re-factoring, I have been making additional performance improvements. Most of this will not be visible to you as users. The most visible changes will be:
Further improvements to the Projected Bill calculation - the algorithm now does the best it can with data available. If you create a device mid-period, then, by definition, the device does not know what happened prior to its creation and cannot include this data in its calculations. If your consumption is more or less constant per day during the period, then the estimate will be pretty good quite quickly. Day 1 - no estimate; Day 2 - estimate will fluctuate widely and quickly; Day 3 on - estimate will fluctuate less and less and will become closer and closer to the value of the bill. In short the estimate will be accurate but imprecise; over time it will become more precise.
More accurate calculation of energy value - previously energy consumed in minute X is priced at the price for minute X+1 (consumption looks back; price looks forward). Most of the time this doesn’t matter but when a Tariff Slot ends and the price changes then there will be inaccurate valuation of consumption in the last minute of the slot. In general over-valuation and under-valuation should cancel each other out. If you are a smart consumer and focus your consumption in cheap periods, then there will be a consistent over-valuation. If most energy is used in cheap slots, the last minute of high-consumption will be valued at the higher price of the next Tariff Slot. In contrast, in an expensive slot, consumption is low - the last minute of low-consumption will be valued at the lower price of the next Tariff Slot.
Better calculation of energy value makes the Projected Bill calculation more accurate because Projected Bill uses energy value as the basis of its calculation.
What’s Next
More architectural re-factoring, I am afraid. This week’s release will be an intermediate version to share the benefits of what has already been done. Memory use is more stable, but still grows over time. The likely culprit has been identified, but the changes to the way that the app does its calculations and then makes updates to devices and capabilities will be quite radical.
Background benefits of the planned change include very substantially reduced network traffic and less resource consumption on your Homey.
As described in previous posts its a lot of internal change with only minor improvements from the user’s view point. It has been submitted for full publication, but you can download it as a test release if you wish:
I tested regressing the install so if you run into problems with the upgrade let me know.
Ouch. Sorry about that. I test with my dummy device data, but it is only dummy data (though based on one users real data) and I have little insight into the full richness of the Kraken dataset. Frankly I have no idea what might be going on. I will PM you to suggest how we can move forward from here.
Best laid plans - but I guess I shouldn’t be too surprised that some worms are creeping out of the woodwork given the extent of the architectural changes that have been made.
Any other IOG users experiencing the same problem?
This is a point release made into Test for your evaluation. It resolves the following problems (thanks to @Daneroyd for his support analysing and resolving these problems):
Smart Energy Devices can be added and repaired (1.2.1)
Tariff Devices show correct currency unit for the £/kWh paid capability (1.2.1)
Account Device correctly calculates cumulative period standing charge in £ rather than in pence (1.2.1)
On a new install, the event loop will start automatically after adding the first Homey device rather than having to restart the app to trigger the event loop (1.2.1)
Device settings can be modified (1.2.2)
Installation
As a test release you will need to install the new version manually using the link below:
New Feature
You can gain some insight into the performance of the app using new application level insights. In the webapp go to the insights tab. In the Filter box at the top of the list of devices and insights on the left hand side of the screen, type “kraken”. Three insights will be listed. I normally overlay the App Footprint and Peak Memory Footprint insights, showing External/Buffer Memory in a separate chart:
Finish the architectural re-factoring. Memory and CPU use are both significantly reduced from earlier releases, but there are opportunities to do even better and to better stabilise memory use over time.
I have not seen any reports of problems with Version 1.2.2, I plan to make a submission this evening for the version to be made live. Please let me know ASAP (and before this evening) if you are encountering any problems with Version 1.2.2 - thanks.
Several new installs in the last few days - that’s great to see.
