A beginners nightmare

When I was learning I found the openHAB Wiki to be essential. It has basic information as well as specific information about how to configure and use specific bindings (e.g. the Phillips Hue Binding) and examples of advanced rule techniques. I highly recommend spending some time there, particularly in the Configuration sections.

I also recommend starting slow. Focus on getting one thing working and then build on that. I started with a pair of z-wave outlets that I put on a timer. Then I added an already existing Raspberry Pi based garage door opener controller I built using WebIOPi. Then I added in the weather information and adjusting the lights timers so it responds to sunrise/sunset as opposed to just clock time. And on and on. If I had attempted to try all of that at once it would have been completely overwhelming.

As a personal rant, I really dislike the demo configuration. Based on what I’ve seen and personally experienced, I think it leads newcomers down the wrong path expecting to have something usable once the demo config is working. I would instead create something very simple, maybe with just the weather binding and maybe a switch or two as the demo config and rename the demo config to “examples”. I’ve seen many newcomers get the demo working only to realize that it doesn’t do anything. And because the demo is so complicated it is difficult to use it as a simple bootstrap configuration to start building upon.


I’d like to thank all of you for your positive responses. I think that such a great set of responses bodes well for this forum and the positives about openhab are a good recommendation. I will persevere and I’m sure somewhere someone is working on a gui config tool or at least thinking about one.

I have a long history in software development and there are two serious issues with config files. The first is their lack of instant feedback that is invaluable to helping users know what is acceptable and what is plainly ludicrous. The second is the inability to link fields that have dependencies. I have looked at habmin and assuming that there was a connection when I ran it alongside the demo I really struggled to see any relationship between the two.

In my view there will be a number of ways that one could look at the ‘Site’ being built.

  1. A Tree model which describes the physical nature of the environment. House, floors, rooms.
  2. A List model that can list rooms, lights, relays, input devices, action devices and ‘acted upon’ equipment etc.
  3. A rules model that describes how input devices trigger actions on outputs
  4. A measurement model that allows confirmation of actions or tracks changes in inputs/outputs
  5. A relationship model that translates types of inputs/outputs into computer addresses (bindings?)

Doing too much analysis here but I would welcome someone giving the ‘openhab’ names to my models, functions and classes?

Finally, yes a simple, working example would be a great start and one that doesn’t require me to have any specific hardware, so weather and email and perhaps some good people would later add in some very simple popular hardware examples using ‘hue’, ‘zwave’ or whatever is popular so that at least a beginner could have something working which he can break and mend and learn?

I am awed that there appear to be interfaces for Denon amps and Asterisk both of which I have but I also know I have a very long way to go before I have any chance of making a connection! I do look forward to the challenge!

One thing that I think would be a good idea is if the wiki in organized ways would list example configurations specific for every single kind of device out there. We could all help build this repository of course.

Usually that is the way a new user would start out: “So I just bought this Fibaro Eye… (or Aeotech Home Energy Meter or Qubino Flush Dimmer or whatever)… now… how do I use it in OpenHAB?” A lot of this information can be found in various google discussion groups as separate questions by someone - and the answers will be in more or less complete form. Would be helpful to collect it for the wiki in an easily browsable and searchable way.

Even better would of course be OpenHAB saying: “Oh hey I see you have a FooDevice here. Awesome. I just took the liberty of adding some items and rules for you that will be visible in the ‘Examples’ section and now you can take it form there.” That would really help out a lot.

Another thing I would love to see going forward is some way to bootstrap the entire installation experience on the most common systems…
Like for instance you set up your Raspberry with the official Raspian image, and then you just run

apt-get install openhab

and then something like:

Boom - done. It sets up openhab to start automatically as a service, sets up a samba file share which you can access form another computer, etc etc.
So that - from when you have a running OS - you would not have to wait more than 5 minutes before you can start doing stuff.

Then again… if OpenHAB2 is apparently rethinking the entire experience, maybe it will - through other means - allow us to get started sooner. (Having to set up file sharing is crazy. It should all be doable through the web UI). As I understand it, Habmin will be a central (pre-installed) part of OpenHAB2. One less thing to worry about! Great!
Oh well, slightly off topic from this thread, so I’ll stop here. :smile:

1 Like

I would like documentation with examples to try that anyone can do regardless of hardware they have.

Some ideas:

  • display the weather in the interface.
  • Show the current time that was pulled from NTP.
  • Run script based on time/temperature
  • etc.

I have found some bits of information online, but haven’t gotten anything successfully working. Quite disappointing.

1 Like

I agree @LarsK, there is a time and place for GUI and sometimes text based configs are easier to troubleshoot. I too hope it stays in future versions.

In my experience my learning curve was more about eclipse (designer) it self rather than the concept that openhab does.I love the config about configuring files, because it forces me to know and read what I’ doing and I learn when I read all the files.Of course this takes time but it pays off.
When I discover openhab i also discover MQTT, that simply blows my mind with the possibilities it can give me.My mind start dreaming :smile: :innocent:

[quote=“bbrendon, post:12, topic:1061, full:true”][/quote]

github.com/openhab/openhab/wiki/Scripts and github.com/openhab/openhab/blob/master/distribution/openhabhome/configurations/rules/demo.rules

It’s easy, but it takes a little bit of time and effort, good luck :grinning:

I agree with many of the comments here about the usefulness and accessibility of the demo setup for novices. It’s incredibly complex for a novice to get their head around. A newbie coming in to OpenHAB might arrive there on a whim and possibly with little in the way of any HA hardware to monitor or control. While the demo setup is interesting to get a sense of the capabilities of OpenHAB, a simple demo setup with a few basic hardware-independent items (weather, time and maybe an example of presence detection? Owntracks?) could help newbies get off and running much faster than the current demo setup. I’m not suggesting ditching the existing demo setup, but maybe a heavily documented (in layman’s terms!) secondary newbies-start-here demo setup could be of value.

Additionally, a script to create an SMB share, as well as to start OpenHAB as a service as @martin has suggested would really grease the wheels too.

You don’t persevere because nice people on a forum behave positively towards you. The reason you persevere is because the thing itself is worth it. Not to mention struggle brings greatness, innovation, and it teaches you.

I’ve been using OpenHAB for over a year now, trying to do my own thing with it, and I still struggle. Even sometimes with basic concepts. But the more I have learnt the more amazed by the platform I am.

OpenHAB in its current form is industry-ready, has a large user base and diverse support for systems and protocols that you want to tie together. The documentation, whilst sometimes not immediately obvious, is complete.

It’s not a panacea. If you are looking for one, you won’t find one!

Actually, for me deciding where to expend time and effort are very important factors and the product support, especially during the development phase, is a key factor. Unless I am mistaken, this product has a long way to go and it will only get there with good strong user support until such time as the difficulties and hurdles are resolved.

I have a number of other interests that I can pursue and I never have enough time or brain capacity to keep them all active. Two of my recent interests have now progressed to a state where they are mature and offer me mostly what I need. I have a choice now of becoming involved in SAT>IP or home automation. One promises entertainment and the other a battle to be part of a revolution in change. The former is attractive to other pensioners, whilst the latter might keep my brain challenged.


Maybe one of the gurus could build either a Virtual Machine image - (which i personally think is the smart way to go) or a Raspberry Pi DD image that could be easily burnt to an SD card.

This image could do the basics such as show the weather and time etc (and give tips about how to change for your location)

A couple of easy instructions about how to download and install would probably then get a lot more traction. I personally have only just started trawling the forums wondering if i have enough free time to put into getting OOpenhab off the ground (and i work in IT for a living !!!)


To everybody suggesting an improvement to documentation and/or wiki, the best person to fix things is YOU. There are lots of people here that don’t have the ability/time etc to contribute code, but most people can improve the documentation. It can be simple spelling mistake to writing a complete new installation procedure.

  1. Don’t be afraid to contribute.
  2. Don’t take it personally when somebody else ‘improves’ on your work.

Go to the page below and read the installation procedure for your platform

That is the only way this will ever be fixed.


I think the hardest part is the XTend-Rule engine. Almost every time I struggle with it, because it doesn’t allow the simplest things like classes, functions, etc…
I have my whole XTend-knowledge from examples from the forums and the wiki.
Something more common with better documentation (jsr223-addon is a step in the right direction) is essential.

The configuration of the addons was almost pretty straightforward. This is imho the only part where some GUI or Interface would make sense. Please don’t torture us with clickable rule creation. For the inexperienced users there is HABmin which allows you to create simple rules through a GUI.

What really would help is when you could test your Rules in the openHAB Designer.
I think this could really be possible by reading the variables and data via the web-API

1 Like

I agree, the most time I spend on OpenHAB is shared between Zwave devices and creating working rules.
Items and sitemaps are not a problem.

It doesn’t help that I can’t get the designer to work, so I edit using notepad++.

But as a software developer I would like to unittest my rules, that would really be great.

I agree, the lack of classes (which XTend does support but openHAB’s DSL does not) is a pain but almost every place I’ve wanted to use a class I’ve found a more elegant and proper XTend way to do it. But you can get functions (mostly) through lambdas. They have their limitations but I’ve managed to use them quite effectively.

And XTend is itself pretty well documented here with a pretty good example program with explanation showing how to use a lot of XTend specific stuff. That coupled with the examples in the wiki and here I’ve not had any more trouble learning XTend than I have had learning any new programming language.

Hey rlkoshak,
I use lambdas quite often, almost in every rule. But they are really quite limited, yet better than nothing.
Beeing unable to access global rule variables is a pain. I always have to declare additional parameters to access variables. Since I have quite a few I work with hashmaps all the time (in which I create a class alike data structure).
The setup and creation of the hashmaps seem to take lots of calculation time (first time execution ~60sec). While this is only annoying (it’s only the first time) not beeing able to call another lambda or the lambda function itself recursively makes structuring the code really hard.
As a workaround I basicly put all data in hashmaps, call the first function from the rule with the hashmap as parameter, call the second function from the rule with the hashmap as parameter, etc… This makes the code unnecessary complex.

What I haven’t figured out yet, is how to use common code in multiple rules (-files). Do you know how?

I have worked with the XTend documentation but unfortunately half the stuff there doesn’t work with openhab since we don’t have classes, functions, etc… It’s basicly just expression and properties.
Maybe that was why I have/had so much problems with it because of the reduced possibilities which I am not used to from other programming languages.

I’ve been down that road of using the hashmaps and passing lambdas to lambdas. However, in every case I got to a point of saying to myself “This is ridiculous”, stepping back and in each case (so far) I’ve found a better way to do it that didn’t feel like abusing XTend/openHAB. For example, I was using the hashmap approach to help determine presence (iPhone doesn’t stay on the network reliably so I added in OwnTracks into the mix and I had this complicated code that ran to a few hundred lines. So I started over from scratch and now have something that works much better and is only about 30, there is one lambda and no hashmaps. I’ve found I can go a long way towards simplification by keeping some of the data in Items rather than in variables inside rules or global rules variables.

The key for me was to quit trying to force an OO Java/C++ type programming paradigm onto XTend and code it more like I would code in a functional language like Lisp.

I haven’t paid attention to the runtime of creating hashmaps. I’m running openHAB on an old but powerful laptop with a broken LCD rather than a resource constrained device like a Raspberry Pi so I’ve not seen any performance issues. I will probably pay closer attention eventually but it hasn’t become a problem for me yet.

You can call a lambda from another lambda if you pass it as an argument (or put it into your hashmap). A lambda is a variable like any other. I’ve done that in a number of places, though I’m slowly reworking my rules and eliminating the need for that in most places.

The only way I know you can call code in multiple files is to create a script. I’ve not used scripts yet as I’ve separated my rules based on function rather than location (e.g. I have an entry.rules and a lights.rules rather than a familyroom.rules and bedroom.rules). Doing this has made my files pretty much completely independently from each other with the only overlap being the need for some of the values in Items in my weather.items and presence.items files outside of weather.rules. Scripts have some limitations too but they are less constrained than lambdas. Another thing you can do if your function just causes a side effect or gathers some data is to write it in an external shell/python/etc script which you call either from an exec binding on your item or an executeCommandLine action (note that only the one that takes a timeout will return the output of the script).

I understand your struggles, I fought with them too. But things became easier for me once I just accepted that the XTend based DSL for openHAB rules is what it is and rather than trying to force it to do something it doesn’t want to and I spend time learning how the DSL would prefer I do it. I’m still learning but it has made my experience much happier and my rules code much cleaner.

It also might be worth your time to get the Jsr223 Script Engine working so you can work in a language you are used to, though there is no guarantee that it will continue to work in openHAB 2.

Good luck and semper gumby.


thank you for your hint that you can pass a lambda to another lambda. I was not aware of that, even if it inflates the call additionally. I am normally used to structure problems into small fractions and then create a corresponding function. Now I can’t use that approach and I am really struggling with it.
Unfortunately I want to create really complex and mighty rules for my home and without the possibility of the OO-aproach things tend to quickly get hard to maintain.

As I have described in another thread it would helpful if you could access items by their name and get their values, like it is possible to post an update to an item-name. With this and a strickt naming schemata it would be possible to structure items and access them dynamically.
I already use this approach for most of my lighting. Most of my LEDs are controlled via dmx which is quite powerful and cheap. Unfortunately with the dmx-binding I have to create an item for every fade and then send an ON-Command to it. I named the items fade_dawn, fade_morning, fade_night, etc. and create the corresponding name on the fly.
In my bedrooms I put all the possible fades/items in an hashmap because and access them because I have multiple fade-senders which have different timeouts and different reactions. The bookkeeping is done in a second hashmap so I only have to pass two parameters to the functions.
What do you think about the getting items by name idea? Maybe you can contribute in the other thread. Thank you.

I will definately look in the jsr223, but I have no experience with python so I have to try out some stuff there first.

I totally understand where you are coming from. I’ve been primarily a Java programmer for over 15 years and C++ before that. Breaking problems down in an OO manner is second nature with me. But like you I kept running into limitations with XTend, which are doubly frustrating because XTend is built on and has access to Java, it should be able to do it darn it!

Oh yes, hashmaps galore. I’ve been there. I even had cases where I had hashmaps of hashmaps. I’ve manage to eliminate almost every single one of them though by using other constructs in openHAB. Don’t forget that you have Groups which you can iterate over and filter in a single line of code. I’ve used this to eliminate my need/desire to try to access the value of an item by name because items that I treat the same are part of the same group so there is no need to look anything up.

For example, I have four categories of lights: those that come on 90 minutes before sundown, those that come on at sundown, those that come on when the weather says it’s cloudy (a hack until I build some light sensors) and those that turn off at 11 pm (light can belong to more than one group). The one major gotcha is that that if I manually turn on or off a light that can be controlled by the weather, that value overrides the weather setting.

I used to have 140 lines of code, three lambdas (one which was called from the others as well as from some rules) and about a dozen rules and any time I added a new light I had to manually update the rules files, changing the hashmaps, the lambdas and add at least one rule. I also didn’t use Groups at all. It was complicated and brittle and I was unhappy, as you seem to be. It also felt like the most straightforward pseudo OO approach but it was ugly and complex.

I’ve since updated it significantly, dropping the LOC by half and now I can add or remove a light from any group to change its behavior. In my rules I iterate over the Group’s members and send the appropriate commands, or trigger on the Group and figure out what to do from there. My rules files are now much shorter, easier to understand, and easier to maintain.

Here is my rule which gets called when I manually switch a light, which marks it as overridden so the weather rule doesn’t change it (one of the cases where I still use a hashmap).

rule "Any light in gLight triggered"
    Item gLights received update
    Thread::sleep(250) // give lastUpdate time to be populated
    val mostRecent = gLights?.members.sortBy[lastUpdate].last as SwitchItem
    if(whoCalled == MANUAL) {
        overridden.put(mostRecent, true)

The magic takes place on the val mostRecent line where it sorts all the members of mostRecent by its lastUpdate time and grabs the last one. Before I had to have a rule for each Item which called a lambda to record that the the light was overridden (assuming it was triggered manually). About 30 LOC collapsed to this one easy to understand rule.

Here is the rule to turn off the lights at 11:

rule "Lights Bedtime"
    Time cron "0 0 23 * * ? *"
    whoCalled = TIMER

    gOffTimerLights?.members.forEach[light |
        overridden.put(light as SwitchItem, false) // reset any overrides
        applySwitch.apply(false, false, TIMER, light) // a simple lambda that checks whether a light is overridden before thurning it on

I was able to even further simplify my entry sensor rules. I used to have a couple of hashmaps, a couple of lambdas, and a rule for every individual door sensor in order to do things like remind me that I left the garage door open for more than an hour. I had three lambdas and a rule for each door sensor. Now I’ve now put all the doors I want the reminder from into a group and I have the one rule:

rule "Reminder for doors that are open for over an hour that we want to know at any time"
    Time cron "0 0/15 * * * ?"
    gRemindDoorSensors?.members.filter(s|s.state == OPEN && !s.changedSince(now.minusHours(1))).forEach[ door |
        sendNotification("myID", door.name + " is still open"

I have other rules for those I want a reminder about if they are open at night or when noone is home. And once again, I don’t have to change the rules to change the behavior of the doors and I reduced this rule from a complicated lambda calling mess to three simple rules that almost all fit on one screen.

So I encourage you to take a step back and think about your rules. Based on my experience I bet there is a simpler way (you can PM me if you want to work through it together and don’t want to do so out in the open). Without knowing better how your rules are working I’m not sure I can offer any concrete examples beyond the above that might be directly applicable, but given what you have provided I wonder if you couldn’t use Groups and some Items to replace some or all of your hashmaps along with some rules which loop and filter on your groups and greatly simplify things.

Finally, I just realized in writing this you CAN get an item by name, provided it is in a known group with:

val byName = gGroup?.members.filter(s|s.name == "ItemName").head as SwitchItem // assumes only one item

So at least there is that.



I don’t want to hijack this topic. So if it is okay for you I’ll open another one! :smile: