Spot Price Optimizer: Advanced algorhitms to optimize heating, charging of electric vehicles, water boilers and more

[masipila (Markus Sipilä)]

@masipila

I’m planning to develop a new optional feature which includes a feedback loop from the indoor temperature.

Conceptually something like this: in the parameters, we add a new optional parameters for setting a target average indoor temperature (this would obviously be read from an Item).

Then, if the price optimization has been too aggressive for example during the day when prices are too high, we would detect that the indoor temperature has dropped too much and we would take this into account and add more heating need.

Do the other users have indoor temperature sensors so that you could share screenshot of days when this kind of drop has happened?

I just realized that this is already now possible and can be done without changes to the openHAB Spot Price Optimizer, all the needed logic can be written to Rule scripts.

If somebody is interested, you can achieve this like this:

Detecting if additional heating is needed

• Have an indoor temperature sensor and create an Item for example TemperatureBedroom
• Create a Rule, for example ExtraHeatingOptimization which is run when the state of TemperatureBedroom changes AND the temperature is below your comfort zone, for example 19.5 °C

If additional heating is needed, you can add more heating need for the period between now and for example the next 6 hours. This Rule action could look something like this:

// Load modules and create service factory.
var { HeatingPeriodOptimizer } = require('openhab-spot-price-optimizer/heating-period-optimizer.js');
var { ServiceFactory }         = require('openhab-spot-price-optimizer/service-factory.js');
var serviceFactory = new ServiceFactory();

var parameters = {};

// Required item name parameters
parameters.priceItem    = "SpotPrice";                        
parameters.forecastItem = "FMI_Weather_Forecast_Temperature";
parameters.controlItem  = "HeatPumpCompressorControl";

// Required optimization parameters, heat curve can have 2 or more points.
parameters.numberOfPeriods = 1;
parameters.heatCurve = [
  {temperature : -25, hours: 24},
  {temperature : 2, hours: 7}, 
  {temperature : 13, hours: 2}
];

// Optional parameters, remove if you don't want to use these advanced features on this Rule.
parameters.periodOverlap   = 0;
parameters.dropThreshold   = 2;
parameters.shortThreshold  = 0.5;
parameters.gapThreshold    = 1;
parameters.shiftPriceLimit = 2;

// Read previous heating need adjustment, divide by 4 and add 1 hour.
parameters.heatingNeedAdjustment = items.getItem('HeatingNeedAdjustment').numericState / 4 + 1;

// Define the optimization window here
var start = time.toZDT()
var end   = start.plusHours(6);

// Read prices from the database, optimize and save the control points.
var heatingPeriodOptimizer = new HeatingPeriodOptimizer(start, end, parameters, serviceFactory);
heatingPeriodOptimizer.optimize();
var timeseries = heatingPeriodOptimizer.getControlPoints();
var controlItem = items.getItem(parameters.controlItem);
controlItem.persistence.persist(timeseries);

It is worth mentioning that in the example above, the numberOfPeriods parameter is set to 1 (I normally have 4 (i.e. 4 x 6h periods) and optimization period is from now to the next 6 hours. The heatingNeedAdjustment is a value for the normal use case i.e. optimization of the entire day, so the item state is divided by 4 so that we get this extra period’s share of the additional heating need. And then we add one more hour to get the indoor temperature up to the comfort zone.

The result of this hypothetical example situation would look like this:

Heating control points before are illustrated in the figure below.

• I use periodOverlap to be 1 hour.
• All of the heating need of the 05:00 - 13:00 period takes place in the beginning of this period
• The non-flexible heating need for the period 11:00-19:00 is 1h 30 minutes. 30 minutes of this take place at 15:00 and the rest happen at the end of this period starting at 19:30 (the gap shifting feature postponed this heating slightly so that’s why it starts this late)

The ExtraHeatingOptimization Rule was optimizing just the period from 15:00 - 21:00. With the example parameters illustrated above, the result looks like this:

• There is 30 minutes more heating starting at 15:00
• And then the heating goes on at 18:00 instead of 19:30
  
  

Summa summarum
I would primarily recommend to find optimization parameters for the day-ahead optimization which are not too agressive.

• The first parameter to adjust is the periodOverlap and have it at zero. If you’re having 4 x 6h periods, this guarantees that every 6h period will always have at least some heating (the non-flexible heating need)
• The second parameter to adjust is the flexDefault. If you need to guarantee more heating need for each 6h period, use a low flexDefault. For example the value 0 would mean that none of that period’s heating need is moved to other (cheaper) times of the day.

If your house is well insulated and you can normally have more agressive optimization like I can, you could benefit of this kind of intraday optimization as illustrated with the example above.

Happy optimizations to everyone!

Cheers,
Markus