Learning rule in openHAB – Part 1

This is the first part of a series of articles about a small “research” I am doing for developing a simple learning rule in openHAB. The rule will cover an energy saving functionality which activates hot water circulation only when it really is required. To discover when hot water  is required should be something that openHAB learns by observing the behavior of the house residents. In the first part of the article, I will describe the application and the related simple learning algorithm. The next part will follow once I will have collected enough experience to tell you more.

The application

The idea behind hot water circulation is to make sure that a faucet will provide hot water instantly up on demand (see also Wikipedia article about circulator pumps). Even though there are energy saving circulator pumps already available on the market, it surely makes sense to think about additional energy saving options when you have an automation system in place anyway.

In my case I decided to connect my low energy circulator pump to an actor on my EIB based automation system so that I can control its function easily. The best place to measure when hot water is used of course is the heating system itself. It is something that I definitely love on openHAB, that there are so many bindings covering nearly every device you could have in your house. So the case for my Alpha Innotec air-to-water heat pump which is based on a Luxtronic controller having a binding in openHAB. Reading the documentation and observing some values, I found out that there is a parameter available in the Luxtronic binding which is directly related to hot water consumption. The parameter “temperature_servicewater” tracks the required current hot water temperature. Let’s have a look at the following chart to explain how this parameter can be used to detect hot water consumption:

Chart showing the hot water temperature over time and the temperature differential.

Chart showing the hot water temperature over time and the temperature differential.

The blue line on the chart shows the value of the hot water temperature over time, while the red line shows the temperature difference. The faster decreasing values are related to hot water consumption in general, the higher the decrease, the more hot water is consumed. The highest drops are related to residents showering and so consuming a lot of hot water. The value increases immediately as the heating pump immediately start its heating cycle and the water reaches its target temperature again. The slower temperature decrease is related to the normal temperature drop in the system. At 35°C the heating pump starts its heating cycle to bring the temperature back to the target temperature.

In order to get hot water as fast as possible, the circulator pump should be started 15-30 minutes right before hot water is required. A lot of consumption cases happens nearly at the same time, so that it would make sense to track and learn when water is required normally and to drive the circulator pump according to the individual use tracked by the system.

Only the following items are required: as previously explained, the service water temperature of the heating pump is required to track the hot water consumption, this is represented by the item “Heizung_Brauchwasser”. The item “Heizung_Zirkulationspumpe” switches the circulator pump. The item “Zirkulation_WorkingDayStorage” stores the tracked consumption values in order to make them persistent when openHAB is restarted. The item “Zirkulation_Threshold” stores the switching threshold for the circulator pump and will be explained later in more detail.

Learning openHAB rule

Hot water consumption is detected by tracking the temperature difference over time. This is way better than just comparing to an absolute temperature threshold as this could wrongly recognize smaller temperature losses of the system as hot water consumption. The first rule is the one which is taking care of tracking water consumption by observing a change in the hot water temperature:

To track changes over time, the day is divided in 15 minutes slices (quarters). The frequency of hot water usage per quarter (histogram) is counted in the “workingDays” array.  The first part of the rule initializes the value array. Of course this could also be done at system startup. When the hot water temperature difference exceeds the threshold (0.5°C / Minute), the rule adds 1 to the value of the current quarter. Regular and repeating uses of hot water at the same time of the day will increase the value for the related quarters of the day and so be a good indicator for when normally hot water is required in the house.

In order to make the whole quarter array persistent the array is stored into the string item “Zirkulation_WorkingDayStorage” whenever a change occurs. The array is restored at system startup according to the following rule. Please note, that restoring is started a minute after startup in order to leave enough time for the system to load its values from persistence:

The next rule calculates the adapting threshold item “Zirkulation_WorkingDayThreshold” for switching the circulator pump based on the current hot water consumption histogram. In order to avoid a too optimistic switching, only values above 0 are considered for calculation of the new threshold. An threshold based on the mean value above the complete histogram should adapt well to the intention of switching the circulator pump only when hot water is used regurarly. The assumption is that sporadic usage should drop below the threshold after a few days of tracking.

The final rule would be the predictive switching of the circulator pump. The rule should look two quarters (30 min) ahead and starts the circulator pump, when the value of the histogram exceeds the given threshold.

As I just wanted to start collecting data to gain some experience the following rule just tracks the current quarter value within the persisted item “Zirkulation_Tracker”. I will use this to show the results in the second part of this article.

Now that all required rules are prepared, it’s time to start collecting real life data and see, how they work. On the second part of this article in a few weeks, I will present the results and may be also some first improvements of this “learning” rule setup.