Interested in hardware

Hello there,

I have a home datacenter and a dedicated server that I am going to set aside to run openhab from, but I am trying to find a list of compatible hardware to use with openhab. I can see there’s a list of ‘widgets’ or whatever they are called, but as far as specific hardware models and etc, I can’t seem to find a list, and i’m interested in setting up openhab. Here are some things I want to configure:

LCD thermostat, capable of being controlled through openhab.
Window and Door sensors
Overhead light controls (probably a wifi electrical switch), so I can turn on and off ceiling lights in my house when I want to.
I did find zmote to control tv and changing channels etc remotely, so I think that’s covered
Also looking for security cameras that I can hook up to openhab to keep an eye on my premises.
Lastly, but not leastly, looking for a media center system that will allow me to use radio, internet streaming,or playing from a shared files location, to wifi speakers that are in various rooms of my house, with the ability to control the volume independently for each set of speakers.

Is all this possible? I was looking at the zwave system, but looked like it was difficult, and flaky, when being used with openhab.

Sorry if I sound like a noob, just trying to get as much info as I can.

This is because the list is massive and ever growing. As a general rule the main thing to be concerned about in terms of compatibility is making sure you choose a supported technology (e.g. Zwave, Phillips Hue, etc) and have a supported controller (i.e. the USB dongle that plugs into your server and bridges between the device’s wireless network and your computer) and you should be good to go. You can find supported technologies by looking at the list of supported bindings. For openHAB 1.8 look at the list of bindings on the right hand side of the wiki. For openHAB 2 look at the docs but be aware that all the 1.8 bindings also will work in OH 2 with only a couple of exceptions.

Nest and Echobee seem to be popular. There are lots of other supported ones to.

The most common approaches seem to be battery powered zwave sensors or DIY.

I recommend zwave switches though smart bulbs from Wimo and Hue are also popular. If you want to control color a smart bulb is pretty much your only option.

Anything that supports mjpeg (and others?) streaming can be put on your sitemap. Though beyond that you will want something like Zoneminder if you want a fully realized CCTV setup. There is an inwork binding for ZM which will let you change the mode and receive motion detection events from ZM into OH.

Sonos or DIY seems to be the primary option for the speakers. For video there are Kodi and Plex plugins.


Based on what information?

In my experience the vast majority of time zwave devices are rock solid and can’t be beat when it comes to setting them up. Push a button on the controller, push another button on the device, wait for the blue lights to stop blinking and its paired. OH 2 will drop it into the inbox and at this point it is like working with any other technology.

Battery powered devices are a little trickier than mains powered but still not hard. You just have to wake them up, sometimes several times before the binding can learn enough about them to configure them. There are a few areas that are not supported yet (e.g. locks) and you have to be aware of distances and the density of your mesh network. It works best if all of your devices are no more than one hop over a mains powered device to the controller. The complete list of currently supported zwave devices is located here:

Adding a new device to the database is super easy too.

1 Like

It is a very interesting - to me - topic as i am in the same exact situation. I run centos7 server with asterisk/freepbx, plex, and just added openhab2. I paired it with Alexa but so far only got 2 controllable devices Openhab can see - TPLink HS-100 and HS-200, via exec binding.

I cannot decide what system to buy into as it is absolutely murky what exactly Openhab can control directly and what requires additional hardware. And in case of a hardware - it is not listed at all what hardware will actually link and work on Linux and how to set it up. Like, if I get Samsug smart-things hub - will it be enough to integrate with openhab directly via IP?
Or does it require an another ‘adapter’? Z-Wave is mentioned to be supported via ‘serial’ interface - what ‘serial’? Is it a USB stick solution? Or does it require real RS-232 cord? It would really help to find some integration scenarios to figure out how to limit costs and reduce hardware footprint here.

It is more or less clear to me now that any Z-Wave integration does require its own ‘hub’ hardware of some sort to ‘talk’ to z-wave devices, but googling and reading about z-wave i see a ton of negativity, like situation when one device stops acting to z-wave commands, or stops transmitting to other devices, it may be needed to ‘reset’ devices from time to tine, etc. Does not sound good.

Best of them all seems to be Lutron and i do not mind the cost of Lutron devices but i am lost at what is actually working and what is not from all Lutron family with Openhab. There is RA2, there is Caseta, there is Maestro, etc., etc. Go to web site and look. What hardware is needed to make Caseta device to be seen by Openhab2? Or will it work directly? Is there a sample of working Lutron integration anywhere, with config files samples to look and use?
If hardware is required for openhab to talk to Lutron Caseta - what exact device? Nothing is clear.

A direct device like HS-100 would be the best solution but it is not clear how to update status of a device if it is flipped manually, so to ‘buy into’ that solution is also not quite obvious. I spent 3 days now trying to google all those combinations but still not clear on what to do. Same with Sensi thermostat - i like its form factor and the way it plugs in, but how to hook it up to openhab is beyong me. It says it works with Wink. New Wink hub will also work with Lutron Clear Connect. Is it same as Lutron Caseta? It is nightmare. :frowning:

It is really difficult to figure out what is a minimum required hardware for different brands. It would really help to have some kind of a mapping document explaining what is possible. Like right now, literally, i am trying to figure out what can new Wink smarthub control from Lutron devices family and how to make Wink hub ‘talk’ to openhab. Not clear on either topic yet.

1 Like


The controller is a USB dongle that the OH binding talks to using a serial protocol. No additional cabling or hardware is required.

The hub hardware is the afore mentioned USB dongle.

The “negativity” you read is going to be pretty much the same for all wireless protocols. And in my experience the need to do any of these resets and such is rare and primarily become a need when you are making some major change in the system like moving to a new controller or migrating from OH 1 to OH 2.

There is a reason zwave is probably THE most popular home automation technology. I just works and it works well.

All you need is the aforementioned USB controller. With the exception of door locks, I believe all zwave devices are supported. If it happens to be a new device, adding it to the db (link above) takes less tgan 24 hours to get it supported.

If you have a question about any specific device before buying, feel free to ask.

I know nothing about Caseta. If it is zwave it is supported. If it is ZigBee it will be supported soon. If it is something else, it is supported if there is a binding for it. I’m not in a place where I can look right now. If there is hardware needed, it will be explained in the succumbing for the binding.

Sadly almost all of your problems have more to do with the fragmented nature of hinge automation than OH itself. OH is a hub designed to help you integrate many (150 give it take) technologies but it won’t be able to tell you what to pick.

Once you pick a technology there is copious documentation and help available on this forum but, unfortunately we are limited in our ability to help you navigate the fragmented ha market.

I can provide some general errors of thumb.

Look for a binding of that name. If you find one than OH supports it and the documentation for that binding will tell you what you need to make it work.

Look for the zwave logo to see if a “wireless” device is zwave. If it isn’t a lock it is almost certainly already sorted or could be supported within 24 hours.

I’m looking at diy door switches. I’m wondering how to build them. I found
a bundle of 15 of them for 7$ online, but they aren’t wireless. Running
wires from them isn’t bad, just not sure what I’d connect them to so
openhab can use them for sensing if a door is open.

Also, I had read that openhab has support for an alarm system. Is this
correct? I was hoping for OH to fully control my entire house including
arming/disarming my alarm system and notifying me when a sensor is

I’m assuming these sensors are Reed switches. If so you can easily wire them to a Raspberry Pi, Arduino, or Esp8266. The wires do not have to be connected to the machine where OH runs. If they are, you can use the GPIO binding. If they are not, you can have what ever they are wired to report their status to OH using OH’s REST API, or by using MQTT messaging fur which there are easy to use libraries for pretty much all platforms and programming languages.

I myself use a Python script. Search for “sensorReporter”.

There are several. I don’t do them so I don’t know which ones but if you search the forum I’m sure you will find them. At least a couple of them have their own binding while others are integrated using serial connections or TCP sockets.

Yes, they are reed switches. I have a raspberry pi free, but not enough
gpio sockets free. I’ve got about 30 windows and four doors I’d need
covered. May have to look at a different solution.

They make an expansion hat for the pi which might give you enough GPIO pins, but realize you are not limited to wiring these all up to one device. If you abreast have them, and at 30 devices, buying one or two more Pis will be WAY cheaper than doing anything wireless or buying a different type of sensor.

OK, after another reinstall and placing jar into addons and chnaging syntax for items exec binding works now fine.

How are you trying to install the bindings? On what platform are you running and from where did you download the zip files?

There are two approaches to install OH 1 bindings, depending on whether it is an “official” binding or not.

If it is an official OH 2 binding (NOTE: the majority of “official” bindings listed are 1.9 version bindings, not native 2.0 bindings) it should be listed. I’ve only ever installed bindings through PaperUI and I’m much less familiar with other methods.

If not you need to install the 1.x compatibility layer and install (i.e. drop the jar file into addons) and configure (i.e. edit openhab.cfg) it the same as you would for OH 1.8.

It might be helpful if you walk us through the steps you made from downloading to install to attempting to install the binding.

There are a lot of places in this process that could have gone wrong, though frankly this is the first report I’ve seen on this forum of someone unable to install a binding. Consequently I don’t have a lot of experience to rely on to help off the top of my head. It also means something really weird is going on.

So, the required maneuver to make this contraption work is this:

Nothing works if you just go to the PaperUI and install binding from there. You just get weird log messages and 0 reaction to scripts.

Pre-reqs are to make openhab user, opehnab group, service to start under proper user - usual things. Install dir is set to /opt/openhab2. ‘passwd’ record for ‘opehhab’ user is set to same dir. You test it by running 'sh - opendir’
Whole install is an un-zip from the latest available build, i have one from Oct 29 11:42.

Then you need to go into /opt/openhab2/runtime/karaf/system/org/openhab/binding/org.openhab.binding.exec/1.9.0-SNAPSHOT and copy that jar into /opt/openhab2/addons/
Then you need to open /opt/openhab2/conf/services/addons.cfg and set
package = standard
remote = true
legacy = true
experimental = true
binding =exec

After it comes to life after startup i installed REGET transformation, mysql persistence, network binding, and all items under ‘MISC’ - hue emulator, rest doc, homekit, etc.

So, after it was all done in that exact sequence, with pre-reqs as stated - it finally worked. With same pre-reqs done but with a default install setting only
package = standard
remote = true
and doing rest from the PaperUI - nothing worked. Even now this exec binding does not show nowhere, API at only shows ‘network and onkyo’ bindings i installed.
But karaf shows it, why it differs - who knows. I have lost any interest to dig any deeper.

openhab> bundle:list | grep Bind
100 | Active | 80 | | Eclipse SmartHome AutoUpdate Binding
101 | Active | 80 | | Eclipse SmartHome Core Binding XML
175 | Active | 80 | | openHAB Exec Binding
209 | Active | 80 | | Network Binding
211 | Active | 80 | | Onkyo Binding

Also, here is the format of items that woked for me, all 3 method listed below do work. I hope all that will help whoever will google this up as there is nothing at all online in one single spot to explain how this stuff is supposed to be configured and there are no working samples to copy from.

Switch PlugTwo “Plug 2” {exec=">[ON:/opt/openhab2/conf/scripts/] >[OFF:/opt/openhab2/conf/scripts/]"}
Switch PlugOne “Plug One” [ “Switchable” ] { exec="<[/opt/openhab2/conf/scripts/] >[ON:/opt/openhab2/conf/scripts/] >[OFF:/opt/openhab2/conf/scripts/]"}
Switch Kitchen “Kitchen Light” [ “Switchable” ] { exec=">[ON:/opt/openhab2/conf/scripts/] >[OFF:/opt/openhab2/conf/scripts/] <[/opt/openhab2/conf/scripts/
?))]" }

So you are clearly on a Linux. Does that Linux support apt-get (i.e. Debian based?) If so I strongly recommend using the apt-get install rather than the manual install. You can use the nightly builds repository so you always have the latest if that is your concern.

With a manual install you shouldn’t HAVE to create the openhab user, though it is strongly recommended and the instructions have you do so. You can run it as root or any other user so long as that user has the right permissions for needed resources (e.g. that user is a member of the dialout group if it need to read/write to a /dev/tty* device like the zwave controller).

The nice thing about the apt-get install is it creates this user and sets the permissions for you.

I really have no idea what went wrong but whatever it was it majorly went wrong as no one has reported anything like these problems. The typical install goes:

  • Add the desired repo to apt
  • apt-get install openhab2
  • install bindings through PaperUI
  • set configuration, Things and Items as appropritate


  • create openhab user
  • download desire opnehab2 distro
  • unzip to /opt/openhab2
  • change ownership of /opt/openhab2 recursively to openhab:openhab
  • run it as the openhab user using
  • copy the .service file and enable OH to start as a service

(Details for all of these steps are defined at the link above)

In your instructions you kind of skip over a lot of little steps regarding the steps between downloading and running. Did you chown the files in /opt/openhab2?

From your description of the behavior and what you did this is really sounding like a permissions problem where the openhab user (or whatever user you are running OH as) does not have permission to add files to the userdata folder where the bindings and configurations get stored.

You haven’t mentioned the log file. Are you seeing any errors in the /opt/openhab2/userdata/logs/openhab.log file or by logging into the karaf console and tailing the log file?

Absence of evidence is not evidence of absence:

I’ll be the first to admit the docs are not up to where they need to be but they do exist and they cover both apt-get and manual installation pretty thoroughly.

For the exec binding, it is pretty thoroughly documented on the OH 1.x wiki (its a 1.9 binding so the 1.x docs apply), links are provided from the OH 2 docs on bindings.

And if you search this forum for “exec” you will literally see dozens of threads with working examples.

I am not making point to criticize anything - I am only stating a fact that it took me 3 days to google up all various threads and absorb a ton of information to make this seemingly simple feature to work.
As of Linux - i am on CentOs7 and it is not changeable. It is obvious that in time doc.s will get better.

Anyway, to be on the constructive side of things, it would help a lot for specifically content to add descriptions of what was ‘old’ way, what is ‘new’ way, explain meaning of < and > directives, and add troubleshooting tips of what specific logger shoud be altered and what should be checked when switch item gets pressed, default logging states successful item state change and nothing runs at all from the given scripts.

And, by the way, i do really appreciate your help and tips - it did help me quite a bit to turn my head around this morning and find a reason why it did not want to cooperate.

As of permissions problem - the fist command after un-zip was ‘chown openhab:openhab /opt/openhab2 -R’. There were no issues with permissions for service owner. Issue was with modules not loading properly and erroring out in the suppressed logs levels which i only saw after turning root logger into TRACE mode. Was that something CentOs7 specific or not, i do not know. It seems to work now, more or less, and that is the only part that matters, and it is good.

Not asking you to change, just trying to understand so we aren’t talking cross purposes. Were the Manual Instructions on the link I provided not adequate or did you not see them in time? The main reason I ask is you should not have had to do any of the stuff you did to make it work following those instructions. They are essentially the same instructions (minus the username creation) for MacOS, Windows, and FreeBSD. CentOS is not that different as to make the instructions invalid.

The article on the Exec binding probably needs updating. The “old way” it is referring to is from OH 1.5 or thereabouts. The old way is all but OBE and the discussion of it should probably be removed from the wiki.

Indeed the “>” and “<” are not discussed. As I’m sure you already figured out, “>” means outgoing and “<” means incoming. An Item configured with “>” will call the script when it receives a command. An Item configured with “<” will call the script periodically (the second to last number in the examples on the wiki page) is the polling period in milliseconds.

One thing to note is that for the most part each binding defines its own syntax for the stuff that goes inbetween the { }. Consequently there is a lot of inconsistencies from binding to binding. This is getting better over time, especially with the changes in OH 2. But for legacy stuff there are no generic docs to help explain the binding configs. You have to go to each binding’s docs, and in this case clearly the Exec binding docs is in need of an update.

For the most part the default logging config should be adequate to at least discover problems. The logging documentation is in need of expanding. I made a first attempt with this posting.

And there are plans to have a troubleshooting section in the docs that would cover other common gotchas (e.g. making openhab a member of the dialout group, exec permissions, etc.). Lots to do, too few people doing it (myself included).

Logging state changes for Items are recorded in the events.log by default. Logs from Rules and bindings go to openhab.log. All get included when tailing the log on the karaf console.

This is troubling and concerning because this is the first I’ve seen posted here of someone unable to run from the included scripts.

Glad I could help. I’ve been on this forum long enough that I try to never interpret anything negatively. I hope I’m not coming across as angry or anything like that. I frankly want to get to the bottom of the problems you had because:

  • they are unique, no one has reported such problems on this forum yet
  • you are clearly technically proficient so I can discount a lot of ID-10T type problems and you are in a position to help us get to the root of the problem without playing 20 questions for a week
  • if there is a problem on CentOS we need to get it fixed because your experience is wrong and it needs to be fixed.

That doesn’t seem right because if they were having errors, they should have logged at least something at the ERROR level rather than just failing silently.

What specifically were the errors and what did you do to finally get it to work?

Out of curiosity, did you attempt to follow the installation instructions in the docs I linked to above or did you “forge your own way”? I ask because if the instructions don’t work as written for CentOS we need to write new instructions that will work.

So, i can say one more thing - at leadst on CentOs it makes life easier to make openhab service run of ‘root’ and make all files owned by ‘root’.

Z-Wave binding gave a lot of struggle. The worst issue - /var/lock/ directory wants to be used for /dev/ttyACM0 lock and as it resides under /run - it never holds privs if you grant ‘openhab’ rights to access it. There was, may be, some way to get around it with more tinkering on privs but it was easier just to give ownership of all openhab2 stuff to ‘root’ and start it like that.
I do not have any issues after that.

As of what else could go wrong - you know, i deal with software solutions for 30 years now and I admit - i rarely RTFM. :slight_smile: should read more, And i am trying to, but, sometimes stuff just slips by.

Also, this new method you got here is not a usual ‘./configure; make, make install’ way. I do not criticize, but it is tricky. Make this thing work requires constant googling for threads and trying to get a single grain of wisdom from the pile stack of BS, sorry.

There is a ton of work done for this project, it is obvious, it is a great software with a lot of possibilities, but it is veru difficult to absorb it all with almost no proper user guides. Like, i found this link -

same issue i have, then somebody goes and posts some xml document with node5 description… Where is it supposed to go? grepping whole openhab2 set of files for any of that brings nothing. Where to go, what to do - go figure.

And it is like this for every single little thing.
You have to put all descriptions of various users and groups into text files, fine. There is a ‘demo’ setup - so it has to be
first found out it is a must to deploy it in demo, so it then cold be reversed engineered and then you can construct it similar to that. Fine, done.

Where can it be found out how to deal with persistences? There are 5 kinds of them. What is to be used? I had tried mysql one against mariadb on centos - it was making some tables. Replaced it with mariadb proper persistence with jdbc.cfg file that has, again, be crafted manually as system does nothing to make it - it connects to DB and pings is fine but does not create anything.
Why? Who knows, no errors in logs. Replaced it with mysql - works again. Eventually it just gets tiresome as initial curiosity evaporates and you just want this thing to do what you need from it - turn lights off and on.

HabMin i get it is still in development, so it is probably expected that perfectly fine working basic UI content is showing its tab in HabMin but with totally empty content and the only item with content is ‘Home’ that has a copy of ‘Control’ section that has nothing at all from the text files you configure?

it is obvious to me by now that there are 2 different items systems in openhab2 - one from config files and one that is hidden inside, somewhere. At least after i turned off ‘simple mode’ in Item Linking - i gained an ability to associate items from .items text file to the ‘thing’ openhab finds by itself. Any assignments to things in the .items file are simply ignored and it was totally confusing in the beginning. I wish there was some kind of an slideshow somewhere that could actually show step by step how to do devices, as normal people who not geeks and do not have desire to reverse engineer all this will not be able to use it, no way no how. Again, it is not a whining - just a my bystander view - user experience here for me was very bad in the beginning, after getting more into it it becomes more intuitive, but manual configuration and settings is an Achilles heel here.

Like this - why even to offer to ‘create new item’ in things link interface if all it responds back is ‘ERROR 405 - Method not allowed’? You then go to log files to see what the heck this ‘error 405’ was - there is nothing in logs. It is just plain confusing. I bet it will eventually get better but as is now - it is very confusing.

Still, it works for what i need from it now, after almost a week fighting with it. Alexa link works, it controls lights well, and that is all what was needed.

Now i need to do some scripting but have no stamina left to go start researching how to do scripts here and how to time them, as it refuses to bring online ntp:ntp:local for reasons not yet known to humanity and i am out of time at work to do more digging.

On Debian type machines such folders have a group with group rwx permissions so all one needs do is add openhab to that group to grant it rights. CentOS doesn’t work like this? That’s unfortunate. It is rather unfortunate because running OH (or any such service for that matter) as root is not a great answer from a security perspective.

This isn’t a new method. OH is a Java program. Java and make don’t usually play well together. OH’s packaging and delivery is pretty standard for Java type projects.

The OH community also suffers a little from Debian myopia. All the docs and scripts and packages are focused on apt. This makes sense because perhaps the most popular platform upon which OH is run is a Raspberry Pi, or a similar type of machine, which runs a Debian based Linux (i.e. Raspbian). With Ubuntu being the second most popular support for other types of Linux, OS X, and Windows is not as strong.

However, I would say that I’m sure the community would welcome someone to submit an RPM build to the build scripts.

That is a treach for OH 1.5. So much has changed that what is on that thread is unlikely to address your specific problem. Those node.xml files are automatically generated by the binding based on the data in the zwave database. Chris asked the submitter to append some to that file just to see if there was a problem with the database entry for that device. Essentially the XML tells the functional part of the binding what that node is capable of and configuration parameters. Manually editing that file is not a permanent solution.

And for the record, those files are located in userdata/zwave

So OH is a lot like Linux. There is a core which you can think of like the Kernel. Then there are addons which run on the core. Pretty much all of the addons are written by third parties. So there is going to be a lot of inconsistency in the amount of documentation written, quality of that documentation, and how much fiddling is required to get things to work. These addons are like all the programs that run on Linux.

So you admitted above you usually do not RTFM. So have you spent any time reading at ?

These are indeed incomplete but they do give a relatively high overview of all the pieces and concepts and how they fit together. Unfortunately, OH is not very self documenting nor is it intuitive how to set everything up. Skipping the docs is really not going to lead to a happy experience.

I can’t answer specifically to your specific problems with mariadb and mysql. I know some people have made it work but I have no experience with it. The first link above is how I set up my persistence and the second one is to the OH 1.x wiki which is a good source of info since the 2.0 persistence docs are unfinished. But for the most part, based on some things I’ve seen on this forum, MariaDB and MySQL are not compatible. You have to use the same binding as the DB.

There are several UIs in OH. I agree this is causing some confusion. PaperUI and Habmin are intended to be administration UIs. Sitemaps which get defined by .sitemap files are for configuing BasicUI and ClassicUI. HabPanel has its own browser based set and configuration. I don’t know much about CometVisu.

At this time, neither PaperUI nor Habmin are capable of creating sitemaps.

I completely agree. I’m firmly in the camp that PaperUI, in its current state, causes more problems than it solved. Until PaperUI or Habmin can do EVERYTHING and do it well I would make it optional, not the default thing that comes up. I’ve had to help a lot of people and have even run into problems myself because of the way PaperUI does things and hides things.

My recommendation is to use text files for everything (turning off simple mode in PaperUI) except auto-discovery of Things and installation of addons.

The inconsistency and bifurcated configuration is really causing problems.

That sounds like a bug. That shouldn’t happen. But again, I don’t recommend using PaperUI for this anyway so I’m not sure if this is a known bug or something new. It is worth a new thread to discuss and perhaps opening an issue.

Hi Justin,

The most reliable implementation of OH I have used was with KNX equipment for actuators and sensors (more than 400 producers worldwide). The downsides of KNX are the commissioning that requires a license (see relatively expensive equipment and a certain level of experience for commisioning. The upside is that you have the complete range of equipment and multiple infrastructure medias (IP, twisted pair, RF, even power line - not so much used these days).
Other things you can try are: Z-wave (quite easy to commission nowadays), EnOcean, GPIO on development boards such as rapsberry pi, or any other protocol you can think of with a proper interface and some tweaking in terms of communication. For IoT devices you can control and monitor everything.
OH has bindings for a lot of things, even if it does not have a specific binding you can always use exec binding or http binding for controlling and monitoring.

Best regards,

George Erhan