Thanks for the kind words @Steve. I’m sorta cheating because I’ve set myself up for experimentation with this Emoncms app and the way “actions” can contribute to my control algorithm.
My system isn’t blending well with the algorithm because it has a “target flow temp” and the accumulator algorithm is expecting the flow to just keep rising so would trigger the “diff>10” rule.
Within the gentle bouncing behaviour, I’m seeing it behave pretty reasonably. As you’ll see in the graph below, I obviously intervened around 19:30.
Here’s the whole experiment:
So there’s a few interesting things going on.
The defrost at 15:00 was handled pretty reasonably.
The shutdown at 23:07 was because the flow was set to a low temp. It’s a common problem when it’s warm (say 10 Celsius outside) because the flow required to dump all the heat would make everyone too warm. The accumulator had a gentle pause and then resumed. My control algorithm would have shut it down (for about the next hour or more). Notably the efficiency dropped off during that lull. However, the CoP of 3.81 during that time is pretty nice. As before, the gold line on the efficiency graph is what the vendor puts in their manual.
This couple of hours in the graph below is interesting because it seems to be behaving really nicely. I think that’s how we all imagine it behaving.
I had a similar couple of hours yesterday (in the graph below) and now I’m torn. We can see the accumulator was more efficient in CoP terms, but it used 2kWh rather than the 1.2kWh I used yesterday. I’m always striving for better efficiency, but I’m finding the long cycles that give good CoPs are actually consuming more energy so I’m experimenting with turning it off a bit more.
I left it unattended this evening which is a bit unfair. As you say, the thresholds need tweaking to make it run more smoothly. We can see how the “target” flow temp kept falling as the outdoor temp got warmer (yes, in the dark!)
I thought I’d share this next picture as an example of where tweaking is required because we can see around midnight it starts to cycle because the max flow temp is down at 33 Celsius. In that scenario the “set point” I coded was 31 so there’s not much change per cycle and we can see it ran for over an hour and was fairly unhappy. In that last run the CoP was 2.6.
Eventually it got to 11 Celsius outside and I hadn’t coded flow temps / set points that far so it stumbled and stopped doing anything. The heat loss from our house at that point is (finally) very low so arguably it could just shut itself off there. Unfortunately I know the others were all sat under blankets at that point to keep warm
Here’s another example of it behaving really well. It would make a good pairing with a buffer thank like @FredM67 has:
Part of what I’m doing with the experiments is playing old data through new algorithms. I can pick any point since the heat pump was installed and ask a new algorithm to tell me what it would do at that point in time. Unfortunately, without being able to actually act back then, it can’t change the state to implement it’s behaviour to cause a long-run simulation. I haven’t figured out how to do that yet. Of course I could simulate the device which John and Trystan did, but that would be the theoretical behaviour, not what would happen in my real setup. So at the moment I’m not sure how to do robust evaluations of novel control algorithms. One way is to just let them run, but that only gives you a small data set on a limited set of scenarios as we saw with our accumulator run today.
The other thing that’s important to me (and not everyone of course) is that I’m looking for the system to be robust. When there’s a squally shower that drops the temp by 5 degrees I want it to handle that. When there’s a power cut I want it to jump back into action and do the right thing as soon as it can. This is hard to balance with squeezing the ultimate performance from the system. I can only imagine this is going to get worse when I try to integrate with solar, an agile tarif and a car / battery using the demand shaper.
Running the experiment has given me some interesting ideas to try out.
Firstly I think I should see if I can go for lower flow temperatures and potentially longer runs. That’s a similar outcome from when I experimented using Trystan’s algorithm.
Secondly, I’m pondering how the sporadic hot water demand will affect this. I’ve been “resetting” the flow by pushing the hot water round the radiators and I think that would work with the accumulator, you’d just need to pause it when heating hot water.
Is your system doing space heating and hot water @Steve?
I should also add a big “thank you” for sharing your algorithm so concisely. It made re-implementing it trivial.
It’s nice that Emoncms made it easy for me to add something like the accumulator value to the graphs. That would have been a chore in the vendor app / site - it would have inevitably ended up with spreadsheets and lots of copy-n-pasting which makes me sad.