When controlling real-world devices, it is more than healthy to consider what can go wrong and what happens when (not if) that happens.

The failsafe considerations depend obviously what you are using the openHAB, but here are some considerations as food for thought.

I use the solution for three things:

• Optimizing the heating of our house
• Optimizing the heating of domestic hot water
• Optimizing the charging of an electric vehicle

Especially the heating of the house is a critical application. Winters in Southern Finland can be very cold and the temperature can drop below -20 °C. The last thing that we want is that the house freezes.

Hardware considerations

All my three devices are controlled with relays with Raspberry Pi. The relays controlling the ground source heat pump and boiler are connected so that when Raspberry is powering the relays (relay pulls), the heating is blocked. In other words, if Raspberry would be shut down and the relay does NOT pull, then heating is allowed normally.

An electrician installed bypass switches to our electrical cabinet. These switches either allow Raspberry to control the device or make the devices to behave as if Raspberry would not exist, see the picture below:

• The first switch on the left is for the water boiler. If the switch is down, Raspberry / openHAB can control the power supply. If the switch is up, then power supply is always ON and the boiler works with its own thermostat logic only as if Raspberry would not exist.
• The last switch on the right is for the compressor of the ground source heat pump. If the switch is up, Raspberry / openHAB can control the AUX input of the heat pump. If the switch is down, the heat pump works with its own internal logic only as if Raspberry would not exist.
• Other switches are for similar purposes for the other devices that I control with openHAB.

Our Raspberry Pi is connected to an UPS battery power supply so that it does not shut down in an uncontrolled way. You can use for example linux NUT tool to enable communication between the UPS and your Raspberry.

SD Cards will eventually wear out and get corrupted. If the power supply of the Raspberry Pi shuts down in an uncontrolled way and there happens to be a write operation in progress, the whole sector of the SD card will get corrupted (the probability for this is 100%, so it's not a theoretical risk). openHABian operating system image comes with very nice utilities pre-installed and one of them is SD card mirroring. My Raspberry has an USB-adapter with a secondary SD card inside it. If the primary SD card gets corrupted, I can simply swap the SD cards and life will continue. Read more on openHABian documentation page.

I have a NAS server with two hard drives so that the server will continue to operate even though one of the hard drives would fail. I installed the InfluxDB to this NAS server so that the database is located on a more reliable device than the SD card of the Raspberry Pi.

Software considerations

Control points is a fundamental concept of the openhab-spot-price-optimizer solution. The controller Rules run every 15 minutes, check the control point values for the next 15 minute period and change the state of the devices if needed. If the control point does not exist or cannot be read for whatever reason, the solution falls back to value "1" which means that the device will be turned ON. This way the worst thing that can happen with heating is that the house heats a bit too much but it does not freeze.

All optimizations assume that the spot prices for tomorrow are available and in addition to this, the heating period optimizer assumes that the weather forecast is available. If they are not, control points can't obviously be calculated.

The spot price data is read from external data source which can have planned or unplanned outages or your own internet connection might be unavailable when you try to fetch the prices. The Entso-E Binding has a retry mechanism but it is still possible that the outage is not resolved by midnight. For these kind of situations, there is a failsafe mechanism which can be used to clone today's control points for tomorrow. With this approach the devices will be turned ON and OFF at the same time as the day before.

Create a new Rule CloneControlPoints and schedule it to run for example at 23:00

Script for version 3.x

The following inline script action:

• First checks if there is a SpotPrice available for tomorrow at 12:00
• If not, it reads the control points for today for BoilerControl and HeatPumpCompressorControl
• And clones them for tomorrow and saves them to the database
• This way the devices will behave tomorrow like they did today and if the price profile is somewhat similar than today, the run times should be quite OK.

// Load modules. Database connection parameters must be defined in config.js.
var { Influx } = require('openhab-spot-price-optimizer/influx.js');
var { ControlPointCloner } = require('openhab-spot-price-optimizer/control-point-cloner.js')

// Create objects.
var influx = new Influx();
var cloner = new ControlPointCloner();

// Check if spot price is available for tomorrow 12:00
var start = time.toZDT('12:00').plusDays(1);
var stop = start.plusHours(1);
var prices = influx.getPoints('SpotPrice', start, stop);

// Clone the control points if spot prices are missing
if (prices.length < 1) {
  console.log("Spot prices missing for tomorrow!");
  start = time.toZDT('00:00');
  stop = start.plusDays(1);
  
  // BoilerControl: Read control points for today and clone for tomorrow.
  var pointsToday = influx.getPoints('BoilerControl', start, stop);
  var pointsTomorrow = cloner.getClonedControlPoints(pointsToday);
  influx.writePoints('BoilerControl', pointsTomorrow);
  
  // HeatPumpCompressorControl: Read control points for today and clone for tomorrow.
  pointsToday = influx.getPoints('HeatPumpCompressorControl', start, stop);
  pointsTomorrow = cloner.getClonedControlPoints(pointsToday);
  influx.writePoints('HeatPumpCompressorControl', pointsTomorrow);
}

Script for version 4.x

The script for version 4.x is conceptually slightly different.

• It checks if the first hour of tomorrow has control points
• If not, it clones today's control points for tomorrow
• This way the devices will behave tomorrow like they did today and if the price profile is somewhat similar than today, the run times should be quite OK.

// Load modules and create services.
var { ControlPointCloner } = require('openhab-spot-price-optimizer/control-point-cloner.js')
var cloner = new ControlPointCloner();

// Define times here.
var todayStart    = time.toZDT('00:00').plusDays(0);
var tomorrowStart = todayStart.plusDays(1);

// Define your control point item here.
var controlItem = items.getItem('BoilerControl');

// If control points are missing for tomorrow, clone and save them. 
if (cloner.missingTomorrow(controlItem, tomorrowStart)) {
  var timeseries = cloner.getClonedControlPoints(controlItem, todayStart);
  controlItem.persistence.persist(timeseries);
}