Until now I can override the set temperature in each room, however if state change from evening to night it will be overwritten. However unlike most of you I have a separate sitemap(admin) where I define such as set temperatures for each rooms. This way when my airbnb are over or my parents uses the flat they might go in there and alter set temperatures (or use alexa), so I have no need to alter text files if I want to override or change set temperatures, works superb for me 
A few screenshot made on the road from my android app and posted here for you guys referance:
Used for debugging and overiding states:
Changing setpoints:
What my sitemap looks like:
A DP almost by definition is nothing special. It is just a named way to solve a common problem. Given the number of likes, discussions, and PMs I’ve received on it I would say it is the most popular of all my DPs.
Actually,
I just wanted to mention it so when future readers come along they would think of that. I really don’t expect you to actually incorporate it into your tutorial, though if you did that would be great too. I do think it makes a great approach to ending the PARTY mode.
That is what I would use. Or perhaps some other power reading or how frequently a PIR triggers. I don’t know all of the information you have available to drive this. You could use a combination. But I suspect the lights alone would be sufficient.
You would think but you still had the question arise in one of the first responses…
In the U.S., everywhere I’ve ever lived and where I have family (so mainly Colorado, Texas, Virginia, and North Carolina) in suburban areas most houses in the 1200 sqft to 4000 sqft size are built using timber frame with fiberglass insulation and a brick, wooden composite, or stucco siding and often have inadequate insulation in the attic and the doors and windows are poorly insulated (unless the previous homeowner took it upon themselves to upgrade). Houses built between the 1970s and late 1990s (I’ve no direct experience with newer or older houses) in these areas almost all utilize forced air HVAC. Each room has one or more vents, one per room for smaller bedrooms, bathrooms, etc and two or more for larger bedrooms and living areas.This also applies to the apartments I’ve lived in as well. The vast majority of homeowners own a “used” house. Very few have the money and opportunty to build something new. And even few of those people have any realy choice in what sort of heating technology gets put in. The builder and architect designed the house for forced air and that is what you get.
In a forced air HVAC system there is usually only one zone for the entire house. Typically this means that there is also only one thermostat and only one temperature sensor driving the climate of the entire house. If it happens to be cold in the room with the Nest, the furnace will turn on regardless of what the rest of the house feels like. One can fine tune each room by adjusting the damper on each vent in a given room to be more or less opened to allow more or less of the cooled/heated air into the room. But these systems are designed to work with the movement of a certain volume of air. If one were to close or restrict too many vents the effeciency of their HVAC will drop significantly and they will end up spending more money for a less comfortable environment.
The way forced air works is there is a central fan that lives in the basement in houses that have a basement, or the attic in houses that do not. This fan sucks in air from one or more intakes in the house and pushes it through all the vents through ductwork. Before leaving the main unit it passes through something that changes the temperature of the air. For cooling, this is almost always the condenser from a heat pump (the compressor is almost always outside somewhere). For heating, this is either a grid of electric heating elements or the air passes over a plate of fire fed by natural gas which is piped into the house as a standard utility (think the burners of a propane barbeque grill).
In the warmer climates, it is going to cost 2-3x more to cool a house than it will the heat it and the restrictions on closing vents is more pronounced for cooling than heating. In colder climates (like where I live now) a house may not even come with air conditioning.
For those who have natural gas central heating and an air conditioner, the cost of cooling the house will be 2-3x more than the cost of heating it. Of course, this also means you probably live somewhere hot so the general climate dictates that. However, those with electric heating are screwed. When I live in Texas, people with electric heating would spend 2x more to heat their house than cool it is the summer, and it does not get that cold in Texas.
So the reason I only have one zone is because that is really the only approach that makes sense with a system like this. And this is the most common HVAC system for residential homes in suburbia, at least in the areas where I have experience. Adding a new zone to the house would cost upwards of $10k per zone to install a separate fan, heat pump, furnace and ductwork for the new zone. Some larger houses will have two or even three zones but those type of houses are well outside the affordability range of the majority of people in the world.
There have been kickstarters and such to create IoT vent covers (Keen comes to mind) that you can control how open and closed they are via home automation. But for my house, which is admittedly larger than average, I’d be looking at spending $110-$135 per vent * 25 vents = $2750 - $3375 (not counting the cost of the controller under the assumption I could make something work with OH). And even if I were to put a smart vent everywhere, there is a limit to how many I can close and by how much I can close them because of the airflow requirements of the system. When my heating bill is < $200 in the winter (I don’t have a heat pump so spend almost nothing in the summer) it would take a LONG time to justify the expense.
As for the how, I have a Nest located in the idiotic location the house builders ran the wires to put it, about 15’ from the front door. Typically one wants to put the thermostat near the core of the house and away from exterior doors to avoid drafts or poorly insulated doors from overheating the rest of the house.
As you can see from the above, I really had and continue to have no choice. Natural gas is too cheap to justify spending the amount of money necessary to add new zones for heating. And I live in a cool climate so will never run a central air conditioner, had I had one, enough to justify adding new zones for cooling.
Nest has a feature that would be fairly easy to do in OH where it will start heating the the house to your home temperature when you start heading home. If you commute is short it doesn’t buy you much. But if it is long enough you can come home to a comfortable home and avoid unnecessarily heating the house for hours on those days you go home closer to 12:00.
Oh to be young again…
Not seeing the rest of this conversation and based on my own PMs with @skatun, I would have to agree. I think the two approaches are very similar and only really differ in detail.
It is really shocking how popular that DP is. I would have expectd my Working with Groups in Rules or Assocaited Items DPs to be the most popular. But no, Time of Day gets the msot mentions, the most likes, the msot discussion, and the most use (guessing based on the rest).
I do this with my lighting. I discard the override at a safe point in time. In my case, when I enter the next Time of Day state. But you could easily choose any criteria to cancel the override. This is the reason I wrote my Deadman’s Switch DP as I needed a way to detect the override.
I can say from personal experience. We had an uncharacteristically cold day this last August (high < 60 degrees F) and the heater came on because the house was cold. My wife told me in no uncertain terms that the heater should never come on in August under any circumstances.
@ThomDietrich, this posting is looking as useful and popular as the InfluxDB+Grafan posting. Thanks for sharing.
1 Like
Hi all, this to be coming a very popular topic!
I have some cad files on my desk for similar, I am just waiting for the kickstarter 3D printer to arrive to test it out. In my case It is just 4 valves, and I do not use them for heating but for ventilation. I just want to make sure that every room has a low enough CO2 level. I will keep you posted on the progress in a separate thread if you would like to.
So you wife don’t mind freezing to save a few bucks, my GF would never accept that!
So some more info about my setup, I started renovating our flat completly in 2014, and the reason why I went for OH was mainly because of lighting. I had to start with the ceiling and that was were I needed to put my downlights, and since at that point I had no clear view of how it would be furnished, I figured out that the best way to get started was to decide that I should be able to control each light seperatly, so whenever I finished the flat i could make different scenes as I would. So to do this I went down the road with wiring every single light to the fusebox where it got attached to a dmx controller, this is why I ended up with 82 pipes for electrical stuff in my 70 sqm flat. So that was why I ended up with Openhab! But since I then had Openhab I could also wire all my heating cables to the fusebox as well, so all these are attached to relays connected to RPI. In the beginning(first year or so) these were not programmed and simply just attached to Normally Closed on the relay and they had their own off the shelf thermostat in each sone. Then in 2016 I started to switch them off at night with cron rules in the same way as @ThomDietrich , Then later that year I implemented my own actuator control:
import org.eclipse.smarthome.core.items.GenericItem
import org.eclipse.smarthome.core.items.NumberItem
import org.eclipse.smarthome.core.library.types.DecimalType
import org.eclipse.xtext.xbase.lib.Functions
val Functions.Function3 heatings = [ NumberItem setPoint,NumberItem temperature,GenericItem relay |
// Turn on the heater if the temp gets more than 2 degrees below the Heating_LivingRoom_Setpoint to prevent rapid cycling
if((temperature.state as Number)-1.0< (setPoint.state as Number) ) {
//Items connected to NC, i.e sendcommand off is ON!!
if(relay.state != OFF) relay.sendCommand(OFF)
}
else {
//Items connected to NC, i.e sendcommand off is ON!!
if(relay.state != ON) relay.sendCommand(ON)
}
]
And this year I switched over to @rlkoshak DP time of day, and I am pretty happy with this setup as stated previously. Below are pictures for your reference, if you guys want to I can make a youtube video next week showing my setup if it is of any interest.
2 Likes
Examples like this are important for the community. They show off what is possible and provide inspiration. I say you should do it.
@skatun Definitely! Example setups can be very inspiring and we’ve created a special forum category just for those: About the openHAB Stories category
1 Like
Thank you for this wonderful thread!!!
I read all comments and like the idea to split/upgrade this Problem/task for different levels of skills.
A beginner would thankfully set up an easy way of controlling his/her home. Maybe not as comfortable or as perfect as it could be, but on a level he/she could deal with and understand what is going on.
Maybe it needs more steps to improve the solution step by step with more functions to get a more comfortable way to control it:
- in the first step setup temperatures within rules and with hard coded times (= cron) will work
- add flexibility with preset temperatures
- add more flexibility with time-of-day DP
Maybe this will be very useful for beginners who are new to openHAB to get things work and to learn step-by-step to improve their own skill in programming rules and to understand the constraints within a smart home (=> time-of-day is not only useful for central heating).
I also learned a lot of heating systems around the world. Thank you @rlkoshak for your detailed description of an “average” house in the US. Here in Germany the most used heating system is central heating with oil/gas/wood and one (controlled) radiator per room. In appartment houses (most common) you have no direct access to the central heating and you can only control each radiator.
In my house (I bought in 2010, was build mid of the 1960s) there was a similar approach as @rlkoshak described: we had a tiled stove with oil burner and hot air funnels to the rooms (two floors). But there was no vents to the heating, just the hot air flow worked on this. The only control was a two point control in the living room which was working on the burner, but the rest of the house was on the resulting temperature.
We “updated” to a new gas central heating with radiators in every room (=standard in older houses) and have now the ability to control every room by temperature sensor and radiator valve and could even control the central burner (if all valves are off there is no heating reequired…).
Another task in relation to the heating system with controlled radiator valves is the limescale protection. Normally the valves are cycle once a week to prevent limescale deposition within the valve. So once a week (even in summer) the valve opens and closes to the min and max position to prevent this.
Thanks again for this wonderful thread of information…
Andreas
2 Likes
@ThomDietrich,
Fantastic tutorial Thomas!
I’m totally implementing it in my house (that’s currently being built) 
I’ve added some enhancements though!
First of all - the “System started” rule will take into consideration the season 
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 
)
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:
- Either discovered THINGS or manual .things files are the base-layer.
- Real ITEMS are defined in text files where the channel-mapping is a cut-past from the things/items discovered by a binding.
- I create proxy items for each “change-vector” for a real item, viz ALEXA, CRON, GOOGLE, a UI like Habpanel, etc.
- 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.
- 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.
- 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.
- 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.
- 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.”
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