Heating Boilerplate - A Universal Temperature Control Solution with Modes

@ThomDietrich,
Fantastic tutorial Thomas!
I’m totally implementing it in my house (that’s currently being built) :smiley:

I’ve added some enhancements though!

First of all - the “System started” rule will take into consideration the season :slight_smile:
So we’ll need a Astro binding and a new item:

String   SeasonName   "Season name"   (gAstro)   {channel="astro:sun:home:season#name"}

Then let’s modify the rule:

rule "Initialize uninitialized virtual Items"
when
    System started
then
    createTimer(now.plusSeconds(180)) [ |
        logInfo(filename, "Executing 'System started' rule for Heating")

        if (SeasonName.state == "SUMMER" || SeasonName.state == "SPRING") {
            Heating_Mode.postUpdate("OFF_SUMMER")
        }

        if (Heating_Mode.state == NULL) {
            Heating_Mode.postUpdate("NORMAL")
        }

        gHeating_Normal.members.filter[item | item.state == NULL].forEach[item | item.postUpdate(19.0)]
    ]
end

Last but not least - a rule that sets heating mode with regard to the season:

rule "Turn on heating on autumn or winter"
when
    Item SeasonName changed to "AUTUMN" or
    Item SeasonName changed to "WINTER"
then
    if ( Weather_FeelTemp.state < 10 ) { // Turn it on only if it is below 10 degrees
        Heating_Mode.postUpdate("NORMAL")
    }
end

Hope you’ll find it helpful! Of course this can be improved even more.

1 Like

Hello everybody,

totally new to openHAB I have been reading many threads in the Forum as well as the beginner tutorial and several others including third party sources about iot. So far there is a test Intel NUC environment running with a few z-Wave things to test.

Maybe it is of interest for you guys to get a few point of an absolute openHAB beginner.
It would be very nice if you could guide me as a newbe. I would be willing to write a tutorial out of the beginners few points by then.

Started off in home automatization with a larger collection of thermostatic radiator heads (Eurotronic Bluetooth) controlled with the EUROprog app. As we have only one water heating circle in the house serving many radiators and at the same time several zones with much different use times I achieved with this simple solution an impressive saving of oil in the last winter.
Nevertheless the limitations of these simple systems are obvious:
• Not all thermostatic radiator heads are reachable at the same time due to range limitations of Bluetooth
• Problems with balancing the right temperature because of temperatures are only measured in the head itself and at no other spot in the room. This does lead into overshoot situations etc with the result of incorrect temperatures at least in larger rooms or rooms with difficult positioning of radiators such as position behind a desk. Without a separate source to get temperature away from the radiator the internal PIT algorithms of the radiator heads will not be able to reach a real stable room temperature at low hysteresis and low battery consumption of the head.
• Limitations of control aps are making it very easy on one hand to understand them on the other side they are not sufficient to several use cases
This considered it is a fact that Andreas Imhof is absolutely right. Beginners like me are in need of a simple to understand solution for a boiler plate. This solution can be time based first of all to take out complexity. Ideally there would be a script which would lead into a situation offering a beginner a similar solution like the simple control aps are offering. In my opinion it does make sense to have even at a beginner level a solution with variable definitions like Tom Dietrich’s variables for preset temperatures.
So far the absolute beginner’s part.
In addition I would like to bring some input into the discussion from my few point which could maybe drive the expert thing forward:
Ideally the user would decide at what time he wants to see a certain temperature in a room and not the time to start heating the room. This would mean we would need metrics to predict the time the valve would need to open and start to heat up the radiator in order to reach the wish temperature in time.
• this would need a standard value for preheating time
• this standard temperature would need adjustments based on
– temperature difference between start of heating and target temperature
– outside – inside temperature difference
– room size and radiator power
– many others thinkable like predicted day temperature outside, predicted and real sun load, wind speed and many more
• Of course such a system could be extremely fine-tuned but probably there is no need to achieve the main point to set a temperature which has to be reached at a certain time instead of a start heating time. Simply build in some safety in the preheating time.
• Maybe at a later state some intelligence to it.

@ThomDietrich @kubawolanin still fighting with heating. Think this is one of the key fields for home automation at least here in Germany. In my opinion beginners like me are in need of a simple solution similar to what is used in Fibaro HC 2. OpenHAB is just making it from an expert only solution to a widely usable program due to approaches like paper ui and habmin. As home automation is becoming somehow mainstream it would be very nice if an open tool like oH would make it to the leading solution. Would it not be possible to implement something preconfigured? Do not get me wrong it is understood that experts are in discussion and that it is not your job to fill my or other beginners needs. I just have the feling that smart people are producing thousands of lines code just used for themselves or sharing it on a limited basis. Immagine big parts of this stuff would make it into easy installable and configurable ad ons or however you would want to call it.

Hey Christof,

it is not easy to compare openHAB with what you call mainstream home automation. openHAB succeeded in combining hundreds of systems and devices but that comes with the cost, that every e.g. radiator valve is a bit different and hence needs to be controlled differently inside an openHAB rule or the openHAB UIs.

Back to your messages. (Next time please try to format them better using the options of the editor here :wink: )

I am not sure if you are saying this is or this is not the case. The boiler plate example above is a carefully built combination of items and rules to:

  • Make it easy to understand and extend
  • Include in ones own setup (due to the minimal set of dependencies regarding specific hardware, i.e. one nominal temperature item per radiator)
  • Have a basic set of options to live with
  • Offer the needed basic complexity to incorporate more sophisticated algorithms and event-triggers (e.g. presence based)

The goal of the boiler plate is to implement a basic heating automation in just a few minutes. You didn’t clearly state if you had issues with that! Please let me know and we can try to enhance the article!

Not sure what you are asking for. The files offered at the end of the article should make it easy for you to get your system up and running.

As you’ve realized yourself, this isn’t as straight forward and thereby not candidate for a boiler plate solution (Of course we could add a section about the idea to the article). On a side note: the option sounds cool but in the end I am not sure if reaching a desired temperature 10 minutes earlier or later does make any real difference in cost or comfort.

To be clear: This would very well be possible. The boiler plate as it is right now offers the time-based schedule. you would need a slightly different scheduling algorithm, then calculate the perfect preheat-start-time based on the factors as you described them. Most of them would actually just be numeric constants you’d need to collect empirically upfront.

That’s also my/our vision. Sadly it’s complicated to bring the complex options of openHAB rules, the user-specific items of users and a fitting UI under one roof. In the end someone would need to build and maintain all of this. People are working on such things but till then you most resort to copy&adapt. Something I found to often be much easier than one would think.

That’s exactly what the tutorials section is for and as you’ve probably already realized, there are dozens of great tutorials and examples here to get inspired by and to copy&adapt.

That’s where you might underestimate the complexity. Look at the heating rules from above. There are item, times and other details you need to adapt to your personal setup and preferences. How would a UI automating all of this look like and how would users provide and use solutions for/from it. I’m not saying that this is impossible, as I said before, there are capable people working on such things but this is a complicated matter.

Here’s my personal opinion: It will take quite some time till this “automation modules” functionality reaches a level of complexity to offer real benefits. Till then you will be much better of to have 100% control over every detail of your setup by the power of a file-based scripting solution (i.e. openHAB rules). This aspect is imho the most important advantage of openHAB over other systems whose automation capabilities are immensely restricted by UIs.

Back to the issue at hand:

Why?

Hey @ThomDietrich
Very nice to get in contact with the “mastermind” at OpenHAB. Maybe it is of interest for you to get some insight where beginners potentially would struggle. First of all you are very deep into the concept of oh. Beginners may already struggle here in parts. Latest when code discussions are stared most non IT peoble will be out. Suggest to discuss this somewhere else as this is not specific to this thread.

What I am strugling from in heating?
Just see the long thread with many code snippets - a lot of valuable info
Even somewhere in the middle links to your GitHub page keeping your code.

This is overwhelming for beginners. Ideally such discussions would result at least in a new topic in oh documentation. Best showing a step by step approach.

Tutorials in the forum are extensively discussed and this is what aforum is for on the other side it becomes fast confusing. Just see this thread it simply breaks in November without a result assuming all important arguments in the thread

This is the problem we are talking several areas being relation to each other

things definitions
item definitions
rules

Hard to understand for non programmers and non oh pros. Do not get me wrong I get the concept of non profit IT projects. I want to contribute and this is why I write to you as this nice program should be the solution to go even for normal people. If you are deeply into something it is easy to get a bit “Betriebsblind”. Most people contributing here seem to be IT pros with coding skills. This should make you guys think as I assume you want to make oh a solution for home automation which can be used by everyone. Let’s assume most of them are not It specialists. Please let me know if I can help in any means.

Hello @ThomDietrich. maybe we can discuss the general question here. @rlkoshak @bob_dickenson @binderth have provided nice insights to me and may be interested in the discussion.
There was a quite negative comment made by another person we need to avoid in any means - oH is such a nice tool…

I’ll second (what I think was @rlkoshak 's succinct point) – OH is an event BUS that connects to many types of devices. To really make OH shine, you have to REALLY and DEEPLY ponder that point. How events get “onto the BUS” (basically THINGS and ITEMS) and how events interact with the state of other bus-participants and/or time etc. (generally via rules and scripts – DSL or JSR223), THAT orchestration is the “art-form”.

1 Like

Additionally, I will add that understanding (and coping with uncertainties of…) the startup order of various components (from either sudo systemctl openhab2 restart OR sudo shutdown -r now) are CRITICAL for reliable performance.

Without getting “too deep-in-the-weeds”, I recently spent many personal time-slices over many weeks trying to figure out MY logic error, when the real problem was compensation for indeterminate load-order of various components. Synopsis-wisdom: when you make a change to any part of your system (if it has ANY level of real complexity) – YOU MUST repeatedly and systematically verify that the desired behavior pattern survives a “cold-start” of your OH host. This means your test cycle will be longer…you cannot just edit an individual .items or .rules file, inspect the results and ASSUME that the same configuration will behave under a “cold-start”. ( I am not even SURE that warm-start behavior is a proper-subset of cold-start behavior — I certainly HOPE so, but I am not SURE).

1 Like

Hi @bob_dickenson,

This seems to be somehow the crux. oH is seen as an event bus by the pros while it is advertised as a full blown home automatization solution.
As I like the concept a lot I tried to dive deeply into oh and read a lot of threads. It is the same in many cases experienced peoples talking to each other about more or less very individual solutions for similar problems. This is fine but it would be nice if such discussions would lead into generally working solutions with a working set of parameters to individualize to a certain level.
It is necessary that the IT guys discuss the coding part intense and probably it is a must to maximize the individual solution. In my opinion it is a must to make oH a general success in homeautomatisation the general outcome should be ideally installable packages to offer standard best practice solution. Believe me I am much more into IT than most “normal” people so I get the concept to a certain level. Most normal people are simply walking away. If you want it to be the toy for pros fine if you want it the general solution for home automatization this needs to change. openHAB certainly can be the general solution to beat all the others.

Talking heating in particular:

Here in Germany and several other areas in Europe radiators with thermostatic heads are common. People are changing the mechanical solutions to electronic ones. Z-Wave devices from Danfoss and Eurotronic as well as Homematic (ip) things are common beside of a few others like the Max system and minor important for oh Bluetooth LE. All this devices are offering the needed channels to link to items needed for a heating system. (Current temperature, target temperature to speak about first of all) If I am not mistaken the devices are all equipped internally with some PID logic to keep a target temperature best possible. Here the logic of OH having physical things to be configured and logic items are helping a lot to generalize solutions.This would help to identify problems as well as tehre would be not a personal layer deep in the logic.

Maybe a simple “how to” in the documentation would do it? Idealy it would be an installable package to bring items, rules and a graphical front end into the system.
Collect the outcome of the thread in form of code somewhere and explain how to install and configure it step by step. I shall be happy to assist as a normal user to let you know where I find problems how to execute.

I have spent a LOT of time over the past 4 years “burning my fingers” on various vagaries OH. My best description of “the magic key” is discerning the proper division of responsibilities between THINGS, ITEMS, RULES/SCRIPTS, the “virtualization” of said (small-t) things into abstractions which have other utility — “proxy” or “virtual” items for example, a proper use of groups, AND using the right tool for the right job.

My current “architecture” generally works like this:

  1. Either discovered THINGS or manual .things files are the base-layer.
  2. Real ITEMS are defined in text files where the channel-mapping is a cut-past from the things/items discovered by a binding.
  3. I create proxy items for each “change-vector” for a real item, viz ALEXA, CRON, GOOGLE, a UI like Habpanel, etc.
  4. I write my rules so that events direct actions toward the appropriate change-vector proxy, where subsequent rule-logic captures any desired metrics and does any required interception so that effects are directed toward the proper real THING efficiently.
  5. The “efficiently” of point 4 requires Groups BUT Groups in their current incarnation do not surface which group member changed to trigger a group change.
  6. The “change in what Grouped items did this” requirement for point 5 MIGHT be addressed by future enhancements to the “itemTriggered” (sic) feature of OH 2.2. But “NOT YET AVAILABLE” is still true.
  7. JSR223 (via J/P-ython, at least) does allow you to detect the “exactly who triggered this” for Groups without re-writing your entire rule set into J/P-ython. (Full disclosure: I’ve been a Python-enthusiast since the late 1990’s, have integrated the interpreter into successful commercial products, etc. It is a GREAT “Swiss-Army-Knife” language, possibly even the best S-A-K.) BUT re-writing all your extant rules into J/P-ython seems a bit masochistic.
  8. Ergo (to me, anyway), the key is efficiently exploiting J/P-ython to detect which item in a group actually generated an event-trigger, passing that result to “group-oriented standard RULES”, and acting appropriately.

One of the primary reasons there is an Experimental Rules Engine under development is to create a way for us to share Rules and Rules Libraries through the IoT Marketplace. When that happens you will be able to download and install code like this just like you do with bindings. Until that matures though, the only way to share solutions like this is through postings like this.

And I will second pretty much everything Thom said. Home Automation is complex and hard. You can either have the flexibility to adapt the system to your specific needs, like you mention with the desire to schedule the time when the room will reach a given temp, or it can be simple and easy to use but then you get what is offered whether it meets your needs or not.

I’d say "a mastermind’. Kai is “The Mastermind.” :slight_smile:

This has been discussed on at least a dozen threads. Yes, we know OH is hard for beginners to use. Yes, we know that there is a challenging learning curve. Yes, we know the documentation is not up to where it is needed. And yes, all of these are being actively worked on to make the situation better.

However, at the risk of sounding defensive, I find that many of those making these complaints vastly underestimate exactly how hard home automation is, even with the commercial solutions. There is only so much any tool will be able to do to make this something my father (i.e. non-technical person) could do on his own. It will require changes across the entier industry.

I’ve found quite the contrary. Most of the active non-IT people end up using examples like these as a means to learn OH and there are so many who have been successful. But you need to realize, neither the tutorials and examples nor the documentation is expected to be used in isolation, particularly for beginners. You should be looking at the code and tutorials posted and when you encounter something not explained well or skipped over or that you don’t understand you should look that up in the Docs. If you don’t figure it out from there then ask a specific question and someone will be happy to help you understand.

Beginners should be starting with the Beginners Tutorial, the first few sections of the User’s Manual, and playing around with the Demo. I wouldn’t expect a coder to be able to just pull up this tutorial and figure out OH based solely on it. You have to learn to walk before you can run.

That is not true. It may appear like that because most of the people posting have spent a lot of time learning OH but many of the users who post examples here are not tutorials. If I’m not misremembering, @skatun isn’t an IT pro.

So where do we draw the line? It’s not a rhetorical question, seriously, how complete must each tutorial be? Should we provide step by step instructions covering everything from installation of OH and assocaited bindings, explain the concepts of Things, Items, etc, and basically duplicate the Beginner’s Tutorial and User’s Manual for each and every tutorial posted to the forum? Or should we be able to assume that the users will be familiar with all of those concepts or at least know to look in the existing docs and rather than duplicating a bunch of docs for each and every tutorial?

Personally, if you want to ensure that no one ever writes a tutorial ever again and posts it to this forum it would be to require them to rewrite whole sections of existing docs to make the tutorial beginner friendly.

I’m glad you found it. Those sorts of errors are soooo hard to find.

This is an apples-to-oranges comparison. The Event Bus is how OH implements its “full-blown home automation solution.”

This is one of the things that makes home automation hard. Everyone’s solution is unique. There is no one solution to rule them all. No two home automation systems are identical. Everyone has their own set of requirements and desires and combinations of technologies in use which makes a generic solution all but impossible in most cases.

With an open source project you take what you can get. If someone posts just a bunch of code with no explanation to go with it we are not going to reject that contribution.

And for the record, Thoms’ solution above IS a generally working solution with a working set of parameters to indivdualize. It just doesn’t do what you specifically want which is going to be a problem for ALL examples, that is part of the point. You also lack some of the experince with OH to be able to see and understand how to use the example (i.e. the configurable parameters are the preset heating Items and the values sent to the Items in the Rules. And that is fine and to be expected. This particular tutorial is more on the Intermediate level and requires an understanding of how OH works and how Rules and Items work together.

See my comments above re the Experimental Rules Engine. That is where OH is heading. It will be a long time before we get there though. In the mean time, the only way we have to share solutions like this is through tutorials.

One thing I will note though is that Kuba has added several of the Design Patterns and code snippets in the VSCode openHAB Extension which is a little bit better, but it is still copy and paste code.

1 Like

Hi @rlkoshak,

thank you for your kind and well thought explenation as allways. Please do not see my comments as an offence against any person contributing to oh or the system itself. In the beginning it is just so many places to work on and try to get an understanding of the concepts. I see oh hiding into a direction to make it workable for normal people. An example is openhabian. For me it was no problem to do the instalation on a Intel NUC based on a normal Linux distribution and then pulling the needed packages. For a lot of people solutions like Openhabian are the way to go. I just wanted to share a vison and now it is undertood that people are already working on it. What already works in Paper U and Habmin is so straight forward other areas ar ehard for beginners

Thank you again people like you are making sure that beginners can manage the burdon of the start.

1 Like

Hi everyone,
that is quite an interesting discussion and I plan to use it in my smart home.
One more question: I have the Homematic Ip “Fenstergriffsensor” window handles and I would like to switch the heating off when the windows are opened and on again when they are closed. Theyboilerplate system only sets the temperature at defined times, if I am right. How can how include an open/closed window rule?
Thank you in advance
Philipp

I guess you are using HmIP thermostats as well? If yes, you can set your devices to do so on your own. Use the “Direktverknüpfung” of your ccu2.

I suggest to put the basic function in the devices and just put a comfort layer with openHAB on top.

@reissp, @job,
Gentlemen, it seems that we are going off subject here.
I have some examples of window sensor driven heating control
In a new thread?

@job , @vzorglub
I was sceptical concerning mixing rules within the ccu2 and OH - what happens, when ccu2 sets the temperature to 15 °C because the window is open and OH to 24 °C, because it’s 6 am and I want to have a warm bathroom? I thought having all roules in one place, would be more logical. But in fact using the ccu2 programs is quite easy.
@vzorglub: Yes, if the topic driftes towards using the ccu2, we should start a new thread, but it also could be intersting to discus adding sensors to boilerplate. It would be nice if you could inform us about your windows driven heating controls in a new thread.

Hi Thom (@ThomDietrich)

first of all, thank you very much for the great tutorial. It is working very nice and I am currently trying to build my own sitemap with the summaries. Very helpful was the link to your config, thank you therefore!

I have a question regarding my current situation. In one room I do have two thermostats and a DHT22. What would you recommend to

  1. combine these two thermostats that I can control them together (use group items? - both are showing different values e.g for act. temp and valve etc.)
  2. how can I include my DHT22 which is showing as well different current values? Any hints?

Kindly,
Woogi

Hi @ThomDietrich, @vzorglub, hi everyone else :slight_smile:

based on this tutorial I was able to combine the two values with a group item. I am struggling with the “Schnellauswahl”. I have the following rule in place:

rule "WZ Schnellauswahl (Sitemap)"
when
    Item WZ_Temp_Preset received command
then {
    logInfo(filename, "Auswertung Schnellauswahl WZ (Sitemap)")
    switch (receivedCommand){
        case 0: {
            HM1_Manu_Mode.sendCommand(tempLower)
            HM2_Manu_Mode.sendCommand(tempLower)
        }
        case 1: {
            HM1_Manu_Mode.sendCommand(tempComfort)
            HM2_Manu_Mode.sendCommand(tempComfort)
        }
        case 2: {
            HM1_Manu_Mode.sendCommand(tempHigh)
            HM2_Manu_Mode.sendCommand(tempHigh)
        }
    }
    WZ_Temp_Preset.postUpdate(-1)
}
end

Corresponding items:

Number WZ_Temp_Preset               "Schnellauswahl Soll WZ"                      <heating>         (G_Heating)
Number HM1_Manu_Mode                "Manu-Mode [%.1f °C]"                       <heating-40>      (G_Heating_WZ)                        {channel="homematic:HM-CC-RT-DN:ccu:NUMBEROFHEATERDEVICE:4#MANU_MODE"}
Number HM2_Manu_Mode                "Manu-Mode [%.1f °C]"                       <heating-40>      (G_Heating_WZ)                        {channel="homematic:HM-CC-RT-DN:ccu:NUMBEROFHEATERDEVICE:4#MANU_MODE"}

So far so good, but the problem is, after the first time I used this rule, I can’t use it again and the whole heating is not controllable any longer. Not even the heating mode and the cronjob time rules are working any longer.

The log is not showing the logInfo, but the temp is set. why? I have the impression, that the rule is not triggered and have no idea why. My log file:

019-02-08 09:44:36.295 [ome.event.ItemCommandEvent] - Item 'WZ_Temp_Preset' received command 2
2019-02-08 09:44:36.305 [vent.ItemStateChangedEvent] - WZ_Temp_Preset changed from NULL to 2
2019-02-08 09:44:36.339 [ome.event.ItemCommandEvent] - Item 'HM1_Set_Temp' received command 23.0
2019-02-08 09:44:36.345 [nt.ItemStatePredictedEvent] - HM1_Set_Temp predicted to become 23.0
2019-02-08 09:44:36.353 [vent.ItemStateChangedEvent] - HM1_Set_Temp changed from 15.00 to 23.0
2019-02-08 09:44:36.358 [GroupItemStateChangedEvent] - G_Heating_TargetTemps changed from 15.50 to 17.50 through HM1_Set_Temp
2019-02-08 09:44:36.367 [ome.event.ItemCommandEvent] - Item 'HM2_Set_Temp' received command 23.0
2019-02-08 09:44:36.375 [nt.ItemStatePredictedEvent] - HM2_Set_Temp predicted to become 23.0
2019-02-08 09:44:36.400 [GroupItemStateChangedEvent] - G_Heating_TargetTemps changed from 17.50 to 19.50 through HM2_Set_Temp
2019-02-08 09:44:36.405 [vent.ItemStateChangedEvent] - HM2_Set_Temp changed from 15.00 to 23.0
2019-02-08 09:44:36.410 [vent.ItemStateChangedEvent] - WZ_Temp_Preset changed from 2 to -1
2019-02-08 09:44:36.465 [vent.ItemStateChangedEvent] - WZ_Heizung_Summary changed from ( • 15.0 °C ) 19.6 °C to ( • 23.0 °C ) 19.5 °C

the second time I am using the button, the log shows the following:

2019-02-08 18:15:21.989 [ome.event.ItemCommandEvent] - Item 'WZ_Temp_Preset' received command 2

Thats it, nothing else… I don’t get it :slight_smile: Hope someone has an Idea.

Thank you in advance. Kindly,

Woogi

True today, but hopefully in the future we will all have this luxury / essential energy saving option.

Hi Thanks for the tutorial and the time taken, I am a bit confused and very new to Openhab.
you state to create the following:
heating_mode.items
heating_mode.rules
mapdb.persist and myhome.sitemap

I know where and how to create then, however I have no idea whatbits of code to insert into what file cheers in advance