Heating Boilerplate - A Universal Temperature Control Solution with Modes

Tags: #<Tag:0x00007faee5def328> #<Tag:0x00007faee5deef90> #<Tag:0x00007faee5deecc0>

The days are getting shorter and the temperatures are slowly dropping. Summer is almost over on the northern hemisphere and with that many have to once again think about keeping their feet warm.

A normal person would turn a thermostat or crank up the fireplace - not the Home Automation Enthusiast!

A fully automated heating schedule system is one of the key components of every home automation setup. In this tutorial I’m going to guide you through one possible implementation of a heating automation using openHAB.

TL;DR; - Skip down to “Final Result” to find the configuration files used by this tutorial.


FIRST DRAFT

Please keep in mind that the tutorial is not quite finished and a few details might be missing. I will be traveling next week and will have no time to continue. I decided to post it rather sooner than later. Comments are welcome!


Side Note: Recommended Temperatures

In general we can agree, that everyone has their own preference regarding the ideal temperature in a specific room. Vast recommendations and studies online suggest slightly different settings. The majority of them agree on a few ground rules:

  • Do not over-heat. You are burning money and the human body doesn’t need the extra warmth. Only increase to comfortable temperatures.
  • Only heat where needed. The hallway or closet don’t have to be cozy. A warm bedroom is not ideal during sleep. Plan your temperature schedules per room.
  • Do not let your home cool out. Heating up cold furniture and walls costs more energy than keeping the temperature at a certain level for a few hours.
  • Do not go below a certain point. Even when gone for a longer time the temperature needs to stay stay above a certain temperature. Otherwise pipes can freeze or mold can develop in moist corners.

Remember: Temperature and time settings and the benefits and risks as well as potential savings in energy costs depend on your home, your neighbors and your families behavior. It’s not easy to define a perfect schedule but some field testing will yield quick results :wink:

For the purpose of this tutorial we are going to work with the following temperatures:

  • 21°C - Comfortable temperature for rooms we spend time in
  • 19°C - Comfortable temperature for rooms we are in shorter periods
  • 17°C - Normal temperature to hold during the day when nobody is home
  • 15°C - Lowered temperature when nobody is home for a few days
  • 13°C - Lowered temperature when nobody is home for a longer period

openHAB Implementation

The following parts of the tutorial describe the implementation of the Heating Boilerplate in your home. As each home is unique and everyone has different heating preferences, you’ll need to adapt, expand and remove parts of the example as you go along.

Rationale: The solution presented here is held at a complexity that allows for easy comprehension and reproduction. Many aspects about the way temperatures are configured or temporarily manipulated could be improved, which in return would limit the ease of use. The tutorial was planned as a guide for new openHAB users. Feel free to extend on the ideas and post your results in the comments below.

Prerequisite: Heating Actuators

Your heater actuators, thermostat or heating controls need to be connected to openHAB via one of the countless Bindings or any other supported method. For this example, let’s assume the following Items are able to control your target temperature:

Number LR_Heating_TargetTemp "Livingroom Heating Target [%.1f °C]" { /*...some binding config */ }
Number BE_Heating_TargetTemp "Bedroom Heating Target [%.1f °C]" { /*...some binding config */ }
Number BA_Heating_TargetTemp "Bathroom Heating Target [%.1f °C]" { /*...some binding config */ }

Many available devices bringing your heating into openHAB will already perform a temperature control internally, leaving us with a “Target Temperature” channel to set the target of the control hysteresis. However not all solutions might provide that comfort, please see below to find a Temperature Control Hysteresis algorithm implemented in openHAB. (TODO)

For further automation ideas or nice UI presentations other properties of your heaters (like current temperature or the valve setting) might be needed as items. For the pure heating schedule presented below the target temperature items are all that matters.

Introducing Heating Modes

The main idea of the Heating Boilerplate is to have one setup-wide heating mode setting. The selected mode will control all individual room target temperatures. A virtual item will serve that purpose:

String Heating_Mode "Global Heating Mode [%s]"

Everyone of the selectable modes has its special use case and the Boilerplate is prepared in a way so it can easily be expanded by new modes or operated in combination with other solutions (like a calendar or location based interruption).

Main Mode: Normal Heating Schedule

The Boilerplate includes one Normal heating schedule that - under normal circumstances - will make sure that rooms are warm when they need to be. The idea is not new and can be found in most other automation solutions. The approach works for most households and is probably what you want to use during a normal week.

Don’t worry, exceptions for either certain times or a single rooms can still be mixed in during Normal mode and examples will be shown below.

If you believe to need more than one regular schedule, the idea of a “normal” mode is easily replicated for a second or third set of times and temperatures.

Preset Temperature Items
First we need to define virtual Items for the target temperature during the Normal heating mode. These will be updated by rules to reflect the desired target temperature throughout the day. The usage of additional Items decouples the schedule from the actual heating mode currently active on the individual heaters. This step gives us more flexibility.

Create one preset temperature item per heater/room:

Number LR_Heating_PresetTempNormal "Livingroom Heating Preset (Normal Mode) [%.1f °C]"
Number BE_Heating_PresetTempNormal "Bedroom Heating Preset (Normal Mode) [%.1f °C]"
Number BA_Heating_PresetTempNormal "Bathroom Heating Preset (Normal Mode) [%.1f °C]"

Furthermore we are going to define one single switch Item that will trigger subsequent procedures and consequently effect the heating actuators or controllers:

Switch Heating_UpdateHeaters "Send Target Temperatures to Heaters"

Schedule Definition
The next step is to define the actual time-based normal heating schedule. We are going to use the easiest way openHAB allows us to so, via cron-triggered rules.

Three rules are enough to schedule a normal workday in this example:

▼ 1. Crank heating up after work (17:00)

rule "17:00"
when
    Time cron "0 0 17 ? * * *"
then
    LR_Heating_PresetTempNormal.postUpdate(21.0)
    BE_Heating_PresetTempNormal.postUpdate(17.0)
    BA_Heating_PresetTempNormal.postUpdate(20.0)
    Heating_UpdateHeaters.sendCommand(ON)
end
2. Increase temperatures in the evening (20:30)
rule "20:30"
when
    Time cron "0 30 20 ? * * *"
then
    LR_Heating_PresetTempNormal.postUpdate(22.0)
    BE_Heating_PresetTempNormal.postUpdate(19.0)
    BA_Heating_PresetTempNormal.postUpdate(20.0)
    Heating_UpdateHeaters.sendCommand(ON)
end
3. Lower heating temperatures at bedtime (23:30)
rule "23:30"
when
    Time cron "0 30 23 ? * * *"
then
    LR_Heating_PresetTempNormal.postUpdate(17.0)
    BE_Heating_PresetTempNormal.postUpdate(17.0)
    BA_Heating_PresetTempNormal.postUpdate(17.0)
    Heating_UpdateHeaters.sendCommand(ON)
end

The weekends are a bit special but can be easily covered by reuse and extension of the rules above. In the example below we will simply add a higher temperature during the day.

4. On Saturday and Sunday: Comfortable temperatures during the day
rule "9:00, weekend"
when
    Time cron "0 0 9 ? * SAT-SUN *"
then
    LR_Heating_PresetTempNormal.postUpdate(21.0)
    BE_Heating_PresetTempNormal.postUpdate(17.0)
    BA_Heating_PresetTempNormal.postUpdate(21.0)
    Heating_UpdateHeaters.sendCommand(ON)
end

Yet another example I personally enjoy quite a lot:

5. Weekday: Cozy bathroom in the morning
rule "8:00, weekday, bathroom"
when
    Time cron "0 0 8 ? * MON-FRI *"
then
    BA_Heating_PresetTempNormal.postUpdate(23.0)
    Heating_UpdateHeaters.sendCommand(ON)
end

rule "9:00, weekday, bathroom"
when
    Time cron "0 0 9 ? * MON-FRI *"
then
    BA_Heating_PresetTempNormal.postUpdate(17.0)
    Heating_UpdateHeaters.sendCommand(ON)
end

And that’s it. A complete everyday week accompanied by a heating schedule that “just works”.

You might be disappointed that the “heating schedule” tutorial for your smart home ended at such a stiff schedule. You are right and that is where the other heating modes and the exceptions come into play!

Special Heating Modes

The Normal heating mode is a good fit for a normal week. However life is not always normal. We should prepare for times in which we want the heating to stay off over the course of a weekend trip or to stay on when we are home sick.

The Boilerplate considers the following heating modes:

  • NORMAL - The normal heating mode presented above
  • PARTY - Hold temperatures for a longer time and in more rooms, reset to NORMAL during the night
  • SICKDAY - Heat to a higher temperature throughout the day, reset to NORMAL during the night
  • WEEKEND_TRIP - Hold a normal temperature during the weekend, reset to NORMAL after
  • AWAY - For vacations or longer trips the temperature is lowered to a safe temperature, no reset
  • OFF_SUMMER - All heating is turned off

The algorithm to switch between these modes and to send target temperature to the actual heating actuators is now pretty simple:

rule "React on heating mode switch, send target temperatures"
when
    Item Heating_Mode received update or
    Item Heating_UpdateHeater received command ON
then
    Heating_UpdateHeater.postUpdate(OFF)
    logInfo("heating_mode.rules", "Heating Mode: " + Heating_Mode.state)
    switch Heating_Mode.state {
        case "NORMAL": {
            LR_Heating_TargetTemp.sendCommand(LR_Heating_PresetTempNormal.state as Number)
            BE_Heating_TargetTemp.sendCommand(BE_Heating_PresetTempNormal.state as Number)
            BA_Heating_TargetTemp.sendCommand(BA_Heating_PresetTempNormal.state as Number)
        }
        case "PARTY": {
            LR_Heating_TargetTemp.sendCommand(21.0)
            BE_Heating_TargetTemp.sendCommand(15.0)
            BA_Heating_TargetTemp.sendCommand(19.0)
        }
        case "SICKDAY": {
            LR_Heating_TargetTemp.sendCommand(23.0)
            BE_Heating_TargetTemp.sendCommand(19.0)
            BA_Heating_TargetTemp.sendCommand(23.0)
        }
        case "WEEKEND_TRIP": {
            LR_Heating_TargetTemp.sendCommand(15.0)
            BE_Heating_TargetTemp.sendCommand(15.0)
            BA_Heating_TargetTemp.sendCommand(15.0)
        }
        case "AWAY": {
            LR_Heating_TargetTemp.sendCommand(13.0)
            BE_Heating_TargetTemp.sendCommand(13.0)
            BA_Heating_TargetTemp.sendCommand(13.0)
        }
        case "OFF_SUMMER": {
            LR_Heating_TargetTemp.sendCommand(0.0)
            BE_Heating_TargetTemp.sendCommand(0.0)
            BA_Heating_TargetTemp.sendCommand(0.0)
        }
        default : { logError("heating_mode.rules", "Heating Mode unknown: " + Heating_Mode.state) }
    }
end

The last detail missing now is the automatic switch from some of these modes back to Normal mode at a certain time.

This should be a no-brainer by now.
rule "End PARTY and SICKDAY mode at 2:00 in the night"
when
    Time cron "0 0 2 ? * * *"
then
    if (Heating_Mode.state == "PARTY" || Heating_Mode.state == "SICKDAY") {
        Heating_Mode.postUpdate("NORMAL")
    }
end

rule "End WEEKEND_TRIP mode at 13:00 on Monday"
when
    Time cron "0 0 13 ? * MON *"
then
    if (Heating_Mode.state == "WEEKEND_TRIP") {
        Heating_Mode.postUpdate("NORMAL")
    }
end

Initialization and Restore of virtual Items

Now that the heating schedule and the heating modes are implemented, we should take care of the case when openHAB is started or the openHAB configuration reloaded. That should be considered with all rules to avoid unexpected states and misbehavior.

After the start up, a restart or a reload of openHAB, all last Item states are lost. Items bound to a Binding will normally be reinitialized by the Binding within seconds but Items without a Binding channel will not be initialized (to be technically correct speaking, they are initialized as NULL).

We are going to apply two concepts to make sure the introduced virtual Items are in a meaningful state whenever possible. A restoreOnStartup persistence strategy (e.g. utilizing mapDB) is used to reset a previous state:

Strategies {
    default = everyUpdate
}
Items {
    Heating_Mode                : strategy = everyUpdate, restoreOnStartup
    Heating_PresetNormal_Group* : strategy = everyUpdate, restoreOnStartup
}

If no old state is know by the system (e.g. when first set up) a System started rule is used to initialize Items with safe values:

rule "Initialize uninitialized virtual Items"
when
    System started
then
    createTimer(now.plusSeconds(180)) [ |
        if (Heating_Mode.state == NULL) Heating_Mode.postUpdate("NORMAL")
        Heating_PresetNormal_Group.members.filter[item | item.state == NULL].forEach[item | item.postUpdate(19.0)]
    ]
end

Final Result

Here’s an example how a sitemap presenting all data and controls could look like. I might eventually post it as well. Ask me about it if you are interested.

To get the solution working in your setup, please create the following files with the provided content and apply the mentioned modifications:

Items Configuration File

heating_mode.items
Number LR_Heating_TargetTemp "Livingroom Heating Target [%.1f °C]" { /*...some binding config */ }
Number BE_Heating_TargetTemp "Bedroom Heating Target [%.1f °C]" { /*...some binding config */ }
Number BA_Heating_TargetTemp "Bathroom Heating Target [%.1f °C]" { /*...some binding config */ }

String Heating_Mode "Global Heating Mode [%s]"
Switch Heating_UpdateHeaters "Send Target Temperatures to Heaters"

Group Heating_PresetNormal_Group
Number LR_Heating_PresetTempNormal "Livingroom Heating Preset (Normal Mode) [%.1f °C]" (Heating_PresetNormal_Group)
Number BE_Heating_PresetTempNormal "Bedroom Heating Preset (Normal Mode) [%.1f °C]" (Heating_PresetNormal_Group)
Number BA_Heating_PresetTempNormal "Bathroom Heating Preset (Normal Mode) [%.1f °C]" (Heating_PresetNormal_Group)
  1. Search&Replace LR_Heating_* and so on by your own device/room names
  2. Duplicate LR_Heating_* lines for more devices/rooms in your home

Rules Configuration File

heating_mode.rules
val String filename = "heating_mode.rules"

rule "Initialize uninitialized virtual Items"
when
    System started
then
    createTimer(now.plusSeconds(180)) [ |
        logInfo(filename, "Executing 'System started' rule for Heating")
        if (Heating_Mode.state == NULL) Heating_Mode.postUpdate("NORMAL")
        Heating_PresetNormal_Group.members.filter[item | item.state == NULL].forEach[item | item.postUpdate(19.0)]
    ]
end

rule "React on heating mode switch, send target temperatures"
when
    Item Heating_Mode received update or
    Item Heating_UpdateHeater received command ON
then
    Heating_UpdateHeater.postUpdate(OFF)
    logInfo(filename, "Heating Mode: " + Heating_Mode.state)
    switch Heating_Mode.state {
        case "NORMAL": {
            LR_Heating_TargetTemp.sendCommand(LR_Heating_PresetTempNormal.state as Number)
            BE_Heating_TargetTemp.sendCommand(BE_Heating_PresetTempNormal.state as Number)
            BA_Heating_TargetTemp.sendCommand(BA_Heating_PresetTempNormal.state as Number)
        }
        case "PARTY": {
            LR_Heating_TargetTemp.sendCommand(21.0)
            BE_Heating_TargetTemp.sendCommand(15.0)
            BA_Heating_TargetTemp.sendCommand(19.0)
        }
        case "SICKDAY": {
            LR_Heating_TargetTemp.sendCommand(23.0)
            BE_Heating_TargetTemp.sendCommand(19.0)
            BA_Heating_TargetTemp.sendCommand(23.0)
        }
        case "WEEKEND_TRIP": {
            LR_Heating_TargetTemp.sendCommand(15.0)
            BE_Heating_TargetTemp.sendCommand(15.0)
            BA_Heating_TargetTemp.sendCommand(15.0)
        }
        case "AWAY": {
            LR_Heating_TargetTemp.sendCommand(13.0)
            BE_Heating_TargetTemp.sendCommand(13.0)
            BA_Heating_TargetTemp.sendCommand(13.0)
        }
        case "OFF_SUMMER": {
            LR_Heating_TargetTemp.sendCommand(0.0)
            BE_Heating_TargetTemp.sendCommand(0.0)
            BA_Heating_TargetTemp.sendCommand(0.0)
        }
        default : { logError(filename, "Heating Mode unknown: " + Heating_Mode.state) }
    }
end

// ========================
// mode resets

rule "End PARTY and SICKDAY mode at 2:00 in the night"
when
    Time cron "0 0 2 ? * * *"
then
    if (Heating_Mode.state == "PARTY" || Heating_Mode.state == "SICKDAY") {
        Heating_Mode.postUpdate("NORMAL")
    }
end

rule "End WEEKEND_TRIP mode at 13:00 on Monday"
when
    Time cron "0 0 13 ? * MON *"
then
    if (Heating_Mode.state == "WEEKEND_TRIP") {
        Heating_Mode.postUpdate("NORMAL")
    }
end

// ========================
// NORMAL schedule

rule "17:00"
when
    Time cron "0 0 17 ? * * *"
then
    LR_Heating_PresetTempNormal.postUpdate(21.0)
    BE_Heating_PresetTempNormal.postUpdate(17.0)
    BA_Heating_PresetTempNormal.postUpdate(20.0)
    Heating_UpdateHeaters.sendCommand(ON)
end

rule "20:30"
when
    Time cron "0 30 20 ? * * *"
then
    LR_Heating_PresetTempNormal.postUpdate(22.0)
    BE_Heating_PresetTempNormal.postUpdate(19.0)
    BA_Heating_PresetTempNormal.postUpdate(20.0)
    Heating_UpdateHeaters.sendCommand(ON)
end

rule "23:30"
when
    Time cron "0 30 23 ? * * *"
then
    LR_Heating_PresetTempNormal.postUpdate(17.0)
    BE_Heating_PresetTempNormal.postUpdate(17.0)
    BA_Heating_PresetTempNormal.postUpdate(17.0)
    Heating_UpdateHeaters.sendCommand(ON)
end

rule "9:00, weekend"
when
    Time cron "0 0 9 ? * SAT-SUN *"
then
    LR_Heating_PresetTempNormal.postUpdate(21.0)
    BE_Heating_PresetTempNormal.postUpdate(17.0)
    BA_Heating_PresetTempNormal.postUpdate(21.0)
    Heating_UpdateHeaters.sendCommand(ON)
end

rule "8:00, weekday, bathroom"
when
    Time cron "0 0 8 ? * MON-FRI *"
then
    BA_Heating_PresetTempNormal.postUpdate(23.0)
    Heating_UpdateHeaters.sendCommand(ON)
end

rule "9:00, weekday, bathroom"
when
    Time cron "0 0 9 ? * MON-FRI *"
then
    BA_Heating_PresetTempNormal.postUpdate(17.0)
    Heating_UpdateHeaters.sendCommand(ON)
end
  1. Search&Replace LR_Heating_* and so on by your own device/room names
  2. Duplicate LR_Heating_* lines for more devices/rooms in your home
  3. Adapt schedule times and temperatures to your needs

Persistence Configuration File

mapdb.persist
Strategies {
    default = everyUpdate
}
Items {
    Heating_Mode                : strategy = everyUpdate, restoreOnStartup
    Heating_PresetNormal_Group* : strategy = everyUpdate, restoreOnStartup
}

Sitemap Configuration File

Add the following to your existing sitemap file:

myhome.sitemap
Selection item=Heating_Mode label="Heating Mode []" mappings=[NORMAL="Normal",
    PARTY="Party",
    SICKDAY="Sick day at home",
    WEEKEND_TRIP="Gone for the weekend",
    AWAY="Adventure Time!",
    OFF_SUMMER="Off (Summer standby)"
]

I hope this tutorial was helpful for you. Enjoy your warm smart home and as always: Happy Hacking!

29 Likes

Hi @ThomDietrich,

this is a perfect solution and tutorial.
I have one remark: I like your idea to set a preset temperature for normal mode. In my config I have also some presets values for all kind of items. It is an easy way to change such a value without restarting openhab.

Therefor I would suggest to set preset values for your list of Temperatures:
21°C - ComfortableMainRooms
19°C - ComfortableSideRooms
17°C - Normal
15°C - LowShortAway
13°C - LowLongAway
0°C - Off

In the heating mode change rule you can map these preset values to the target temperature of every room.
So if you have to change a preset value, you don’t have to change it in the rule, but you can easily change this preset value even within the sitemap (maybe on a special page).

Andreas

1 Like

Hey Andreas, thank you!
I actually have done that in my personal setup :smiley: I went with discrete values for the examples to make everything a bit more transparent. If you think it’s valuable I could of course still put them back in.

One thing though: During my time using the schedule, I realized that I’d adjust the temperature for one room for a specific time rather than adjusting the value of the variable used in this entry. In the end I didn’t use the variables as much, as you can see. What do you think about that?

Any other ideas?

Hi @ThomDietrich

Thanks for your helpful post as always!

One comment I have is that most people (I would guess - maybe I’m wrong?) won’t be able to control their heating on a per room basis. Simply because their existing heating system is not multi-zoned or it’s not cost-effective to add remote control TRVs to their existing single zone system.

For example, I have a combi boiler controlled by a single Nest. My heating system is single zoned. My Nest controls the heating and as obviously not all rooms heat equally I manually turn down the TRVs for the rooms least used.

I already have Xiaomi Temp sensors (they were quite cheap) so I can monitor temperature in those rooms but I’m not currently prepared to pay the price to buy remote TRVs (such as ZWave as they are relatively expensive) so I cannot control the heating in those rooms.

Anyway those are my thoughts - maybe I’m in the stoneage and others can enlighten me! :grinning:

Hi Thomas,
I would be interested in seeing how you achieved this.

No, it’s not necessarily expensive. A ZWave radiator thermostat is ~60-80€, and you can get a MAX! for as little as 30€.
Speaking of motorized or thermoactive valves to control underfloor heating, I got them for 12€ per valve, and you need just one actuator per zone, not per loop.
Now since the valves are usually located as a cluster in just one or two rooms, you will be able to use multi-actuators such as a Pi with a multi-relais hat, or any other device to have enough connectors (I’m using a 6-socket ZWave plug for ~90€).
If you still think that is expensive, go ask your local HVAC dealer for a solution.
Any single device (to contain electronics) they offer will be 100+ € … that’s probably what most people still have in mind.

EDIT: Now that’s my German (or European) view on things. Housing installations can vary greatly throughout the world, though, see e.g. @rlkoshak’s post on U.S. housing below, and so does the effort of any attempt to change it.

1 Like

Fantastic tutorial!
Some observations, more for people who come along later than suggested changes to your posting:

  • The Time of Day DP could be used to drive this instead of cron triggers. I just helped @skatun implement something very similar to the PARTY mode parts of the logic.

  • I would like to see a sentence somewhere just to mention that this same approach could be applicable to those of us unlucky enough to have only one zone for the whole house. You really just have the one Item you need to update with the new target temp.

I do think it would be valuable. I like to try to illustrate little coding best practices in examples like this where possible. Though I do agree, it is a fine line between adding clarity to the example and applying concepts like DRY.

1 Like

I don’t follow, sorry! I have one zone one thermostat but each of my radiators has its own TRV. Where can you get motorized TRVs for 12€?

Motorized thermostats are 30€ (MAX!) to 70€ (ZWave).
For underfloor heating, there’s these. See there’s even one for just 10€ :slight_smile:
They’re not motorized but work based on a material to expand/shrink when you apply current.
That’s why they’re slow (takes 3-4 minutes to open/close), but that’s fine for this kind of application. And they’re way more robust than motorized units. As they can be mounted in any orientation, in theory, you could even use them on radiators.
You won’t have a display and input wheel handle in that case, but you wouldn’t need these in a truely smarthome-controlled heating system, would you ?

EDIT: As @skatun stated correctly, you’re paying this to raise comfort - it’s not about cost savings (although those MIGHT be possible, too, especially if your home isn’t insulated as good as are new homes).

1 Like

Hi all,
Let me quick introduce myself, so I have been discussing this topic over the last year or so with @rlkoshak and @ThomDietrich . And I want to share my point of view on this great tutorial. And guys bear in mind as @ThomDietrich said this is just the preliminary version! So I am an aerospace engineer (Thats why so bad at coding…)working with fuel cell for oil and gas as well as for space. Even though I hated thermodynamics in school lately I found myself doing more and more FEM and CFD of thermodynamics problems in the last few years.
So lets start with the basic, heat flows from hot to cold, so to minimize this heat loss we tend to insulate our houses as well as possible, which is the most . The formula is Q=kADeltaT , so by insulating we decreases the k which is a combination of conduction and convection(radiation is neglectable in most cases), but at some point we come to that it cost more to insulate than what ever you will save on heating cost. So the second part is the area, so a smaller house will always have lower heating cost, something many forget about when building their own Taj Mahal. So the last factor is the temperature difference, and its here OH can help you save cost.

So by using a heating pattern where you lower deltaT when not needed potential heat cost could be saved. So lets me do an example if this really is the main factor of implementing the heating pattern or not. I just got my electrical bill which where slightly more than 60 euro for a month, most of this is hotwater and and cooking so we might look at 15 euro per month for heating. Then if we apply the heating pattern we might be able to lower the temperature so that the heating will be reduced by 30% so then we look at 5 euro per month in the best case!! So no its not because of saving 50 euro per year, but to make it more comfortable! So this means if you want to make it simple, then increase heat when you sit still and watch tv(I do increase heat in the evening from 19C to 21C) lower the temperature while sleeping(14-16C) . So what you really need is just day and night mode!!! But if you wanna slightly more complex then add evening mode, holiday mode and do not heat rooms which you don’t use(Having a guest mode).

So here is my thoughts regarding setpoint temperatures:

  1. The temperature should never get lower than 6-7 degree in the living room/kitchen due to fridge freezer operation problems. So holiday mode , set it to this
  2. So how long does it take to reheat your house by 1 degree? Find this out, and this will determine what temperature to keep it while at work, so lets say you heat it with 10 degree per hour, and it takes you 30 min to get home from work, then put at work temperature to 5 degree lower than when at home and start heating when leaving work.
  3. So I do not see the point in sending off during the summer, but rather just keep normal heating schedule, you still want the same comfort in the summer, however most likely your heating cables will hardly kick in during the summer.
  4. Just keep in mind that you don’t want high speed thermal cycling, that this can cause fatigue
  5. Yes you can use heat to transfer away water, but this is a really inefficient way to get away moisture, the best way is ventilation, because forced flow can get rid of way more water than heat heat can. So don’t keep it warm because of moisture, let the ventilation rule handle that!
    So to the comment by Rich, I started of as Thomas with cron rules, but I have now changed to Rich way of using time of day sates instead. And I am so much more pleased with it. I think if you are german and always keep going to bed at 23 it works fine, however I might be out sailing and come back late and another day I need to leave to the airport early so I typically go to bed between 21 and 01. So instead of using 01 to cool down the bedrooms and living rooms so that I can sleep comfortable at night I now use the rule if its after 8 and when all lights are off then I trigger night mode for instance.

Unfortunately I am on holiday now, so I have not been able to implement @rlkoshak latest suggestion to this alternative approach yet, but when I get back I will finish up the latest touches of my alternative approach and then post it here as a more advanced alternative for those who might be interested. (Will be around 15 of October)

2 Likes

Well, I am German but even I feel a time-driven schedule ain’t flexible enough to meet many people’s unsteady presence patterns, and even more so for a family or other group of people with overlapping but differing needs to share a home.
In the early days, you could simply claim (and it was true) that the heating just works the way it does and that it basically cannot be changed. Now that I do can change everything and my wife knows I do, she wants me to.
Way too many options to choose from. Life in fact was easier without a smarthome. Well, less fun, too, of course.

I, too, suggest to use time-of-the-day as a basic pattern, but I’d dynamically adapt/extend it based on presence detection methods.

You could, just for example, set your ‘nighttime’ trigger go off at 21:00, so your house will stop heating at 21:00, but it’ll keep (re-raise) the target temperature up as long as say a motion detector in your room detects presence.
I also use a geofencing app to determine when I’m leaving work to let my house know it’s time to start heating.

You could also do all of this per-zone. A “zone” might be a single room, a floor or the whole house, depending on your building situation (in terms of thermodynamics and how many independent OH-controlled valves you’ve setup), so maybe just for the bedroom, or just for the living room, or both, whatever you prefer.

Hey guys! Thanks for all the comments. As you know the article is a first draft and I’ll try to improve it and address all your suggestions and concerns. I’ll also add more chapters eventually. What I immediately got from the comments is, that I have to address two topics:

  • Different heating technologies/philosophies in different parts of the world
  • The possibility to add dynamic conditions to the game
  • The effect of such a control system on your energy bill

Let me start off with my thoughts on device and heating costs and potential savings. I would love to hear your thought on that.
I agree that fine-tuning temperatures will not safe you a fortune but it might reduce the energy bill. On the contrary, I believe that an automated heating solution implemented with the main focus to bring more comfort in our lives might even increase the heating costs. Aspects like overheating or unnecessary comfort are hard to predict. The costs for per-room or per-zone heating actuators the investment into a home automation controlled heating solution might not pay out…
Saving energy and money should be in everyone’s interest but other aspects might be more important when planing an automated temperature control.

@danielwalters86 the way how the heating is implemented in the concept of a house or apartment very much depends on the country/area you live in. Different strategies and philosophies exist. You said that “most people won’t be able to control their heating on a per room basis” and I know that this is true in many areas.
Here in Germany/Europe not having per room control is very uncommon. In a classic household you’d have one radiator per room with a normal thermostat controlled by the user on a daily basis. One of the first things I did in my apartment was to upgrade those to the connected Homematic thermostat valves HM-CC-RT-DN.
Pay attention to the fact, that I do not have control over the centralized boiler and even if I had, I would still want to tweak temperatures per room over certain times.

In conclusion I think one has to clearly distinguish between the technology used and the preferences with regards to a heating schedule/mode.
In the tutorial I try to provide a close-to universal temperature control solution with modes to match different needs. What and how you apply this to your setup and preferences is up to you. As @rlkoshak already said: In the example I am showcasing three rooms, your current setup would just need one of those. The alternative would of course be to upgrade your valves to connected ones. Yes that will cost extra money but as we are talking home automation I think we can agree that this is part of the deal.

@mstormi thanks for your comment. That’s a great alternative and I should mention clustered underfloor heating as one option. Also I should mention “zones” as an alternative to “room” to make the relation wrt the heating concept clear.
May I ask how you do temperature control? Centralized or on a per room basis with dedicated temperature sensors? @skatun already proposed a openHAB implementation of a heating hysteresis to me, which I’ll add to the tutorial shortly.

@rlkoshak @skatun The Time of day DP is imho nothing special and I’m using similar concepts. Pay attention to the fact that modes can be added and tuned. The current Normal mode 100% depends on cron-triggered rules but I could just as well add any other kind of influencing event (Hint: it is not called TIME_SCHEDULE).
One nice example I might even mention in the OP: In my brothers setup I’ve defined a rule depending on his iPhone location. If he is more than 50km away from home the rule will automatically switch to WEEKEND_TRIP or AWAY mode. That rule came in handy a few times already.
Back to the Time of Day idea: I believe your main point in mentioning it was so I’d consider it for the tutorial? That is a great idea and ending the PARTY mode based on a measurable criteria would be a nice example. Might I ask which condition you’d consider for it? My simple approach would be to trigger on a lower bound for active lights.

Isn’t that kinda obvious? But yes sure, as I said, I’ll add some facts about different technologies and philosophies to the OP.

Related to that: @rlkoshak @danielwalters86 Could you please describe shortly why you have a single zone setup and how you control it? What was the main focus while construction and why did you decide against full automation during the smart home upgrade (if that was an extra step for you). Is per room temperature control unimportant to you or is this a simple cost-cost-benefit tradeoff decision?

@imhofa Yeah okay :smiley:

Hey Kim!

Keep in mind that I plan to add aspects of what we’ve already discussed soon. Everything we discussed in the private chat is not forgotten :wink: I wanted to post the tutorial in time for most users who are currently thinking about the room temperature control topic.
Thanks for the interesting backstory about yourself :wink: That’s a great insight into things.

We totally agree on that! See also my previous reply.

Exactly. If your goal is to just be comfortable all day, a pretty simple schedule is all that’s needed. A day and night mode plus evening heat-up is enough. Check my example NORMAL mode in the OP to find exactly this :wink:

And here lies the interesting part about this whole idea. The NORMAL mode (which everyone is referring to and btw is deliberately not called TIMED_SCHEDULE) is just one example for one mode. I chose the name “Boilerplate” to highlight the aspect, that it provides the means and flexibility an openHAB automated temperature and heating control should provide. This will probably get clearer after I’ve added dynamic elements and the hysteresis algorithm.

Let me answer on these…

  1. If you have direct neighbors (apartment) temperatures will never drop that low to begin with. That’s nice. However if they do, there is the real risk that with the center of the living room being at 6°C, the corner of the bathroom can drop below 4°C. You do not want pipes to freeze in the middle of the winter. Choose a safer temperature that will not trigger unneeded energy investment!
  2. Good idea. Without the optimization to measure and test I think that is what everyone does. I normally go home from the office between 18:30-12:00 - hence I’ll set the target temperature to 21°C starting at 18:00. Yes that could be optimized but I honestly don’t care about this marginal optimization.
  3. “I do not see the point in sending off during the summer” - well yup that is also just a suggestion. The obvious comeback is, that I simply don’t want the heating to operate in summer - there is just no need in a mid-Europe summer. Also as I do receive my heat from an external provider, I don’t want to get billed for “nothing”.
  4. I think I’ve considered that with my temperature selections.
  5. My argument was not about reducing moisture but to prevent moisture to settle in cold corners. I agree that air humidity is an important issue that should be handled by ones ventilation technology or manual efforts.

Regarding the Time of Day thingy: See my comment on it in the previous comment.

It’s funny how this came out :smile: No I don’t do that. Actually I am the wrong person to ask about this as I am the guy who is out often and unplanned and seldomly goes to bed before 2 :sweat_smile: The example shown above is only one rule away from being operated by a dynamic behavior like your lights example. As I said in the previous post: I’ll add an example here and to my own setup :wink:

In conclusion I actually think that your approach is pretty much the same as mine, just the details and rule conditions are slightly different.

Best! Thomas

Hey Markus,
everyone is talking “time-of-day” when you actually mean “use more dynamic rule triggers”. That’s easy and not in conflict with what I’ve written so far. You have probably read in the previous comments, that this is what I’m going to add to the tutorial as just another example. I’m surprised how everyone is triggered by that details but don’t worry, getting honest and constructive feedback for the Tutorial is exactly what I was asking for :wink:

This is indeed an interesting aspect I wanted to discuss. How are “overrides” handled? If the heating rules state that the living room should do 21° at 18:00 (or any other condition), what happens if I came home early (17:00), didn’t feel well and cranked it up to 23°. Should the temperature drop silently or is an override considered of higher priority and only discarded at a safe point in time?

On a per room basis with dedicated temperature sensors. To be precise, on a per-zone basis.
Temperature sensors are available in most rooms anyway as part of multisensors or other OH-controlled devices.
So all you have to do is insert a thermoactive valve into every underfloor loop or attach a motorized thermostat to every radiator, respectively. Not at all as expensive as one might think, see posting above.
Plus you need to enable the furnace and/or pump(s) (to supply all rooms) whenever any of the zones detect a need for heat.

Build a proper presence detection and just use it in heating control. Strictly speaking, it’s another, unrelated problem and should not be part of the heating control algorithm (and if you put it into a separate ruleset, you can use it for many more applications).
Effectively, that way you don’t need any separate party mode at all.
How to properly detect presence is yet another story, The number of active lights could be part of that, yet I think motion detectors are more reliable. Or use the AVR or Kodi binding … if they start to play Udo Jürgens, the party is to end and you can turn down the heating :wink:

FWIW, I’ll have a presentation on presence detection on Smart Home Day in a fortnight.

Now with dynamic triggers such as presence detection, the need to heat would be detected when you enter at 17:00 and your house would start heating immediately (maybe your GPS tracker even foresees it already at 16:30 when you leave work). Either way, you can, but you wouldn’t need to manually override it.
In rare cases (e.g. if you’re sick and want overall higher temps), just manually turn the whole house (or just the relevant zones, like your bedroom) into that ‘sickness’ mode you mentioned.
From my experience, you wouldn’t need this. But if you feel you do, it’s of highest priority (because while it can take a long time to make a relevant delta-T difference in practice, at least you know you’ve done the best you could, making you feel better). Psychology plays a big role w.r.t. perceived heating comfort.
And as we all agree it’s about raising comfort and not about saving on energy, any override is to be kept until the next change is to happen according to the regular schedule or any dynamic trigger.

[ Another ‘psychology’ example: I guess most will agree that it’s a waste of energy to crank up the temperature in all rooms in the morning for just those couple of minutes that it takes you to have your morning coffee before you leave for work (the bathroom being an exception to this, of course. It is to be handled as a separate zone).
My trick now is to turn on my underfloor heating zones during the ‘early’ time-of-day and shut them back off right after that. (‘early’ is just slightly before I get up until switchover to ‘away’ mode takes place or my presence (absence) detection says I’m gone). That’s just enough to warm the flooring but nowhere near what the room would need to reach a target temperature. But the effect is still that you feel comfortable enough because of your warm feet, just you know you’re not wasting energy, making you feel even better. ]

Hey Markus,
a purely presence/location oriented heating control is another good example. However as we all know reliable presence detection can be hard to get right. For the tutorial (beginners tutorial) definitely something I wanted to avoid.
After a user is past the basic heating control something like that will be interesting. I might add a list of noteworthy conditions for the user to further explore :+1:

Why not insert a basic ‘presence’ switch item. Advantage: it reduces the number of modes you need to implement.
Any beginner can manually switch that item via UI, and any pro can spend as many of his nights optimizing his algorithm as he likes to.

1 Like

That is argument I can’t dismiss :slight_smile: :+1: I’ll add it soon.

Hello Hans-Jörg,

sure thing. Without further delay, you can find the configuration here and here. There is some redundant code in the lower part of the rules file, doesn’t look ideal but does the job. The maybe more interesting parts of the implementation are the summary generation and the conditional visibilities on the sitemap.
As you might have guessed the rules dependent on my actuators and their special features and limitations (Homematic HM-CC-RT-DN).

The result looks like this:

I meant at least this temperature, I just wanted to warn user to not set away temperature to low…

Why do you not want to have 21C in the summer? If its warmer outside anyway the heating will never be switched on anyway even if you set tempertaure 21C, so why introduce an extra state?

My point was that the heating pattern should not be there to avoid moisture in corners, because there are better ways to handle this(If you have no other way, then at least get a humidity sensor and if that gets to high >65% then increase heat… and let this be a separate rule because its not dependent of indoor temperature, but outside weather condition)