I developed a new version of the optimizing algorithm which might be of interest or inspiration for the others so I thought to share this one as well.
In our household, the heating optimization is a multiobjective optimization problem with three partially contradicting objectives:
Cost optimization i.e. utilizing the cheapest hours available for heating
Comfort: It’s not nice if the indoor temperature drops too much because all the heating hours occurred in the night and then the no heating hours occur during the afternoon / evening
Our ground source heat pump is a traditional on/off pump and according to people on the heat pump forums, the compressor lifecycle is around 100 000 compressor starts. So from this point of view, it is uncool if the compressor goes on-off-on-off-on-off every other hour just because the spot prices were a fraction lower.
So I came up with the following concept, which seems to work very nicely in our house, see the picture below:
On this example day, 12 hours of heating were needed. The logic for determining this number of required heating hours is the same as explained in comment #13, no changes to that.
The fact that 12 hours of heating is needed means that 12 hours will need to be blocked.
This new algorithm starts from the most expensive hours and blocks, not from the cheapest hours. The number of expensive, to-be-blocked hours is fist divided into two, i.e. there will be a 2 x 6 hour periods when the heating will be blocked.
- The algorithm first searches the most expensive 6 hour consecutive period and blocks that.
- The previous and next hour just before this block period will be marked as allowed.
- Then, the algorithm finds the second most expensive 6 hour period from those hours that are not yet blocked nor allowed.
- The fact that the previous and next hour around the first block period were marked as “allowed” guarantees that these two block periods are not consecutive i.e. there will always be at least one heating hour between these two blocked periods. This helps to the comfort objective.
The algorithm is here (remove the .txt file extension so that the file name becomes peak-period-blocker.js)
peak-period-blocker.js.txt (6.8 KB)
Usage in your Rule action scripts, assuming you have an Item called HeatingHours which contains a number of needed heating hours (updated via another Rule or adjusted manually)
dh = require('kolapuuntie/date-helper.js');
influx = require('kolapuuntie/influx.js');
optimizer = require('kolapuuntie/peak-period-blocker.js');
// Read desired amount of heating hours
item = items.getItem("HeatingHours");
hours = Math.round(item.state);
// Read spot prices from InfluxDB
start = dh.getMidnight('start');
stop = dh.getMidnight('stop');
prices = influx.getPrices(start, stop);
// Optimize heating hours
points = optimizer.getControlValues(hours);
// Write control values to InfluxDB
The results are so far very promising, here’s a temperature graph from our living room. The green line is indoor temperature and yellow line is outdoor temperature. The pink area indicates when heating has been on.
You can see that previously the indoor temperature started to decline quite steeply if the heating was blocked for too long (red arrows). Now with this new algorithm there is always one shorter heating period in the middle of the day between the morning & evening price peak and the indoor temperature is much more stable. I can most probably even adjust the heating hour calculation so that we can survive with less heating hours, which will mean reduced total energy consumption.