Wiki listing all compatible hardware

There are several threads about motion sensors compatible with openHAB. However, there’s not a single one listing all of them so that you can easily compare them. For openHAB newbies like me it’s therefore pretty hard to find compatible hardware to buy.

To make this procedure easier I would suggest to set up a wiki that can be filled by openHAB users and developers. A very good example for such a site is the German FHEM wiki:
It has a (quite) comprehensive list of hardware products compatible with FHEM. Each product is described in an article and is categorized by its manufacturer and product type (e.g. motion sensor) so that users can easily find all supported products of a manufacturer or of a certain type (see for instance for a list of motion sensors).

I think this is a must have feature for openHAB, too. The only question is how it should be implemented (via MediaWiki or something else?) and where it should be hosted (ideally on or any subdomain).

What do you think?


Good idea. At the moment devices working with openhab are mostly listed within the specific bindings (e.g. homematic). So why not start with a simple list and evolve it to a wiki. If the data is collected once it’s easier to put that into something more readable.
Just started one:
incomplete list of openHAB compatible hardware

The list should at least contain:

  • manufacturer
  • devicename/id
  • category (e.g motion sensor)
  • used by/attached by (binding)

Anything else?

1 Like

Good idea to start with a table. Can you make the table publicly editable? At the moment I cannot add anything but comments.

1 Like

Oops. Sorry. User problem :slight_smile: Should be editable now.

Just one caution, there are tens if not hundreds of thousands of devices compatible with OH. If this mammoth task were to be undertaken I do not think a wiki page is appropriate. I also think this is more appropriate as part of each individual binding’s documentation, not a single global list of tens of thousands of devices.

For example, there is a database of all of the currently supported zwave devices (link is on the zwave wiki page) and a simple process for adding Items to the database. Other bindings only support a few devices (e.g. Nest). And sill others are unbounded from a device perspective (e.g. MQTT, HTTP, TCP/UDP).

The current OH approach is to go from technology choice to that technology’s binding documentation (i.e. wiki page). Then that binding’s documentation should have all the documentation necessary to determine what hardware is compatible. It may be a simple sentence (e.g. A rooted Wink Hub) or a link to a database like zwave.

And this approach is going to be continued into OH 2 (though the wiki approach is being replaced. When a developer submits a binding they also submit the documentation for that binding which must include information about compatible devices. A single global list of devices will be impossible to keep up to date, complete, and accurate based on the developer’s experience with OH 1.

I would agree that there will be thousands of devices that are currently compatible or in use with OH. That’s what the system is really famous for (beside lots of other things :slight_smile: ). And if you add those devices that are connected through MQTT, HTTP and TCP/UDP it maybe a hundred of thousands.

And maybe a database is the right place for that, yes. I don’t care about the technology or solution used.

That’s what I would call a typical technical/developer view. But e.g. OH2 is designed to have a much more broader audience than the more or less technical oriented user that is using OH now. And the first group mentioned would not go through every binding of that list of more than hundred to look if there’s a hardware he’s thinking of.
As an end-user I would rather look for a way to find a hardware for a specific use-case and then look what technology is used to connect it to OH.
So having a central-place where all hardware is listed and how it’s connected to OH would really be helpful. Of course this would never be complete. But hey, this is a non-profit community project.

So why not make the life of those guys easier? Those who put functionality and use-case before technology.

I think it will happen as it always does: if someone starts, more and more people will join and put their input in.

So. Any good ideas what technology would be appropriate?

This is somewhat out of necessity. Bindings are developed by third parties by an large and there are a handful of active developers on OH. One of the problems with OH1 is keeping the documentation up to date, complete, and of high quality. The lead developers have deemed this approach a failure. The binding developers simply do not always go back and update the wiki and the quality of documentation is of mixed quality and completeness.

So we are left with the following facts:

  • The binding developers are the most qualified to write and maintain the documentation which includes compatible devices
  • The core OH developers are too few and too busy working core OH 2 to keep the documentation up to date themselves
  • The core OH developers have been unable to enforce a review and validation of wiki documentation to be a requirement before updates/new bindings are accepted into the baseline

So given that the OH developers have been unable to keep the existing documentation up to date how do you suggest they be able to keep a central list/database (and ever growing) database of compatible devices up to date?

I do not disagree with your premise but there are realities which, in my opinion, makes creation of a central database untenable.

Also, I don’t think it is too much to ask of an end user to see “zwave” in the name of a device and look at the documentation for the zwave binding to know if their device is compatible. And I actually have a good reasons for this:

  • Lets say a user searches the uber database of compatible devices and picks out a compatible zwave motion sensor. They never look at the binding docs and it is only when they get it and try to configure it that they discover they also need to purchase a USB zwave controller. Many many of these technologies have these sorts of dependencies (e.g. Hue requires a hub, X10 only works with a couple of controllers, etc). I firmly believe that such a database which is devoid of that context will cause more problems than it will solve.
  • Even with OH2 and the many changes to make it more beginner friendly, you still cannot get away from the fact that to do HA successfully one must decide on a relatively small set of technologies upon which to build. If a newcomer is jumping in looking for compatible devices without first choosing the base technologies they are in for a very expensive failure at worse, or a very expensive complicated system at best.
  • Home automation is a complicated/technical activity. I’m the first to say, at its current state, if you are not willing to get into the technical aspects and approach it from a technical perspective OH is not yet for you and you would be better off with a commercial solution.

I’m not convinced it will make their lives easier (see above). The HA/IoT market is too diverse technology wise and there is too much overlap, and there are too many caveats and dependencies for each technology type to capture in database like that. And allowing the newcomers to ignore the technology aspects and only focusing on functionality is, IMHO, doing those users a disservice.

Hey all,

I’m a new guy around here. I do understand the arguments from both sides of the debate of building this db or not. I can give you a couple use cases here from my point of view:

  • I an new to openHAB, but not new to HA in general. I came to OH with a few old X10 devices (RF and powerline) but am mostly on Insteon now. So, I have some X10 motion detectors already - is there anyway to use them directly? I had no idea. Without going through every binding page and looking for one that supports an X10 RF receiver I have no way of finding out.

  • For this the above example, I ended up using heyu (Linux X10 software) to receive the X10 RF incoming data and put it onto the MQTT bus and use those sensors in openHAB that way. Is that the best practice? Is that my only option? I have no idea. Is there a binding that would allow me to pull in X10 RF with some receiver directly and eliminate heyu? I have no idea.

  • The X10 motion detectors work, however are pretty unreliable at detecting motion. I want something with higher reliability - where do I find other detectors I can use?
    Are there any other brands of motion sensor that work? I have no idea. Are there any bindings that support any technologies that have motion sensors, without going through every binding page, I have no idea. Reading through the big list of bindings, I don’t even have any idea what 90% of them even do, or what hardware they connect to.

I can go on, but I think you see my point. I do understand the idea of keeping the information on the binding pages but the info there it isn’t really very helpful unless you already know what you are looking for.

I’m a huge open source guy - have been for many many years, but I honestly see this issue on many different projects that are open source (Mythtv is another good example). Opensource projects tries to support everything. There are official ways and then there are 10 ways to hack everything under the sun so you can argue that EVERYTHING is supported in some way or another, but it is kind of up to the user to find the into and make it work. Similar to my X10 motion sensors, are they supported? Well, if you go and get heyu, configure it to export the signals to the MQTT bus and use the MQTT binding - yes they are supported. It is kind of a hack, but it works. So do you call them “supported”? Not sure.

The proprietary guys on the other hand, do things like “Works with Nest” and hardware manufactures proudly publish this and put it on the packaging / websites. Having a “Works with OpenHAB” kind of page would be great and help pull in new users. Maybe it is simply a link to the binding page/pages. Trying to limit the scope is probably useful for this kind of page. Maybe it makes sense to consider item that have their own bindings “officially supported” by openHAB. Each of those would get a listing, and things like my X10 motion sensors could be listed under a “other hardware” section with an entry describing how to “make them work”? Not sure - just an idea.


I don’t think that such a wiki has to be filled and updated by the developers. I mean it would be nice if they contribute to the wiki sometimes, but it’s not necessary. The FHEM wiki works also that way. Every end user can create an account and contribute. The same way wikipedia works.

As a developer and end user I would like to contribute to such a database or wiki. For instance, I’m currently collecting information about motion sensors. I looked through different binding descriptions which anyway can be only used as starting point for further searches on the web. I also searched for user experience in the openHAB forum. But my feeling after investing a lot of time in just searching is:

  • I’m still not feeling well informed, since I assume I found only a small portion of the supported motion sensors.
  • I think there must be thousands of users that do exactly the same. They search and gather valuable information in a time consuming process and I’m pretty sure they would also like to share this information with others, because they know it’s a big help for others.
  • Moreover, while searching for motion sensors I accidentally discovered two wiki pages that exposed to be one of the best sources for my task: the FHEM wiki and the Homegear wiki - wiki pages of two alternative open source home automation systems. When I saw this, I felt very disappointed regarding openHAB and I started to doubt that I made the right choice with openHAB just because it’s implemented in Java. But since I made already some adaptions to an openHAB binding, I will of course stick to it. Since I don’t like problems to be unsolved I decided to improve what I though is necessary to improve - the missing device database. That’s why I started this thread.

Yes and no. Yes, they will definitely know best which protocols, properties and functions will be supported by the binding. However, they will not exactly know if some devices are not working properly as long as they did not test them all in detail. That’s an information only an end user can contribute.

I anyway wanted to suggest to add some additional columns to the database. One of them is “Additional hardware required?” where hubs and so on could be mentioned. Anyway this database should be of course only a starting point to find appropriate devices. If you want to set the system up, of cause you have to look into the binding documentation. I would also suggest to just link this documentation from the device database instead of duplicating and storing it at two positions.

Exactly! This cannot be handled without a database anymore.

Thank you very much for your experience. You mentioned a good example of how different system can be connected and do not have to be directly supported by openHAB. This makes it even more complicated for users to identify (indirectly) supported devices.
I don’t think that setting up such a database and collecting those devices will be easy. But I think it would be a HUGE help. It just needs to be collaborative, people have to be encouraged to contribute to it and then it will automatically fill over time.

1 Like

This is a problem. And I hope I was clear in the above that I do not think the current documentation is adequate. And part of the problem in your particular case is that X10 support in OH is pretty anemic and I’m not really sure if it is officially supported at all anymore. OH was primarily developed by Europeans and X10 never really became popular over there and by the time OH became popular in the US other technologies have replaced X10 in terms of interest.

The current wiki page does not really have a good search capability and there are sooo many bindings in the table on the right and I’m not even certain that list is complete. As a case in point, the meager X10 support in OH is through the Mochad X10 Binding which I was able to find through just a quick Google search of “openhab X10”. It used to be listed in that table of bindings. I don’t know if it has been removed because it is no longer maintained or in error.

Anyway, this binding supports the X10 CM15A RF and PL controllers or CM19A RF controllers only.

I do know of some people who have enabled support for other controllers via Perl scripts and the Exec binding.

I can’t answer whether that is a best practice as I don’t know much about how heyu nor X10 work. MQTT is a pretty good approach for getting info to and from OH and it is the approach I use. Other approaches that are common in cases where there isn’t an OH binding or the necessary hardware that OH needs to communicate with is not local to the OH server:

  • shell/Perl/Python scripts called from OH using the Exec binding
  • Implementing an HTTP REST API that OH calls to send/receive data
  • Implementing scripts which send/receive data from OH through OH’s API
  • TCP/UDP Socket communication

I completely understand your frustration but let me ask you a question. Let’s say there was a database of all supported devices and let’s even assume it were complete and up to date and has the information listed above (manufacturer, devicename/id, category, binding). OK, you do your search and find several devices listed. Lets say the Monoprice Z-Wave Motion Detector was the cheapest.

Given all of that, would you have continued the research to discover that you would also need to purchase one of the supported z-wave controllers to use it? Would you have done the research to discover whether z-wave is even an appropriate technology for you (e.g. your server/controller is close enough to your sensor and/or you have enough devices to make sure the mesh networking provides reliable paths to all of your devices)?

These are the things that make me wary of just having a table of supported devices even were it up to date and accurate. There are sooo many other considerations that must be taken into account beyond “some guy somewhere got a Monoprice Z-Wave Motions Detector to work.” And without going to the binding documentation (and sometimes beyond) you can’t really tell whether that “compatible” device will work for you.

Lets look at it from a slightly different angle. What if you did find your X10 motion sensors in the list of supported devices? As far as I can tell they are perfectly compatible with OH using the Mochad binding, BUT only if you are using one of the three supported controllers. So if you had search for your motion sensors and found them on the list, would you have purchased them before reading on and discovering that while the device is compatible the controller is not?

In fact this is usually the limitation. It is the controller that needs to be compatible and if the controller is compatible ALL devices that are compatible with that controller are also compatible with OH. So just having the list of compatible devices would not actually answer whether it is compatible for YOU.

I agree but how can you pick something that will work for you unless you know the advantages and limitations of what you are looking at? I agree, it is a hard chicken and egg problem. But by solving this immediate problem I want to avoid generating a whole bunch of other problems that I foresee will become a problem given a list like this even if I ignore the problem of keeping it up to date.

Agreed and part of that comes from the fact that most of these projects are structured where there is a core team of developers who create the platform and then a huge collection of one and two developer teams building plugins/addons/bindings/whatever to solve their particular need. So you end up with a solid core and a bunch of plugins that end up doing everything under the sun because some developer somewhere wanted to make the platform do something it was never designed to do. This was true of EMACS (an operating system masquerading as a text editor), Linux, MythTV, Eclipse, and plenty of other projects.

We are not going to fix that problem here. It is the nature of how OS development works, particularly projects that create a platform upon which users add plugins.

In your particular case, no, I would not call your motion sensors as being supported if this is what it takes to make them work. And that raises another problem with the list of supported devices approach. Just because a device isn’t directly supported does not mean it cannot be made to work. But to address a later comment of yours, documenting every hacky way to get something maybe working is IMHO way beyond the scope of what the official OH documentation should cover. Forum postings, Instructables, blog posts, examples, etc. sure; but not official OH documentation.

In a sense that is what the list of bindings is. But like I said above the key “works with” is not the device but the controller in almost every case. So saying that X10 Motion Sensor 1234 “works with openHAB” is, in my opinion misleading at best because that is only true for certain controllers. And once you have a supported controller pretty much ALL X10 devices are supported.

And there is a list of bindings on the OH 1 wiki, a list of supported bindings for OH 2 so maybe it is just a matter of nomenclature.

Given that the main compatibility point is between OH and the technology’s controller that is essentially exactly what the binding pages do (or are at least supposed to do). They just don’t list each and every device with the same information over and over. For example, in the X10 case it would be a table of every X10 device ever created with a note that says “only works with X10 CM15A RF and PL controllers or CM19A RF controllers.” Given limited resources it seems to make much more sense to document which controllers are compatible which is what we already have.

The one problem you are facing is you just want to search for a device to buy and know it will work. My response is that really won’t solve your problem.

Hi rlkoshak.

I think you have some good concerns. The db - if built - would have to have the appropriate information. I think that xylo had some good ideas for what that info might be. Maybe some of the columns would be:

  • Device name
  • Device PN
  • Device technology
  • Binding Support Page
  • Additional Hardware Required
  • Additional Software Required

So, for my little X10 motion sensor you would have:

  • Device Name: X10 motion Sensor
  • Device PN: MS-14A
  • Device Technology: X10
  • Official Binding Support Page: link to Mochad Binding page
  • Additional Hardware Required: X10 CM-15A or X10 CM-19A
  • Additional Software Required: None
  • Unofficial Support: possible link to page describing using heyu & MQTT and/or other solutions

I’m sure we’ll come up with other columns needed, but I think this would help most of your concerns you mentioned. I also want to create more problems that we would solve, but I think if we take a smart approach and try to add as much info as possible this approach can go a long way to getting the info out on what works with openHAB.

And in the case of OH 1 this model has not worked well.

See my just posted reply to @tommycw10 about my concerns about the problems such a database would create. And one further problem I don’t think I mentioned is what about devices that work perfectly fine but just haven’t been tested by anyone? Do we scare users off of new devices just because someone hasn’t added it to the DB yet?

That is probably very true. And in almost every case it isn’t the motion sensor itself that dictates whether it is compatible with OH but the controller.

In my experience, most of the users who post to this forum actually do focus on which technology they want to use (e.g. zwave or zigbee or insteon or hue) and then once they decide on the technology they can easily tell whether a given device will work. Often the story goes “I have a Wink Hub and am not happy with it, can I use OH with my zwave devices” or “I’m trying to decide between echobee and nest, which is better in OH” and the like. Like I said in my other posting, if you have a compatible controller ALL X10 devices will work, but if not NONE will work. So the really useful info is support for the controller, not individual devices.

Homegear appears to support five technologies. I don’t speak German but FHEM appears to support fourteen technologies. OH supports well over 150 technologies. In terms of scope there is simply no comparison between them. The problem of creating and maintaining a device database is one to two orders of magnitude a bigger problem for OH than it is for either of those two projects. And given my previously stated objections I’m still not convinced that such a database solves more problems than it creates.

This statement is ambiguous. Are you disappointed in OH because it is missing a database or some other unstated technical reason or documentation reason? Are you questioning your choice because OH is written in Java or was the fact that it is written in Java the reason you decided to choose OH?

And please please please do not take my pushback as discouragement. I’m not king around here, not even for a day. Please feel free to ignore me and forge ahead. But realize that a lot of my objections come from being a very active member on this forum (even back when it was on Google) and I’ve primarily focused on helping newcomers and with coding problems. And based on that experience I am not sure you realize the scope of what you are proposing, the problems such a database will create for newcomers, and that even given such a database newcomers will only have part of the information they need to make a decision.

But what about those devices that don’t work because of a bug in the binding that end up working later when the binding is updated? Who is responsible for correcting the database? What about something like z-wave which actually has to maintain a database of supported devices as part of how the binding works? Who is responsible for keeping that DB in sync with the documentation? What if the problem is completely outside of OH and is actually a problem with a specific controller but the device works fine with other controllers? Does OH need to document all the problems with everyone else’s hardware combinations?

Given our failure to even keep the existing wiki up to date how do you propose keeping a device database consisting of devices from over 150 HA and internet technologies up to date? “The community will provide” has not worked for the wiki so how will this DB be any different?

(NOTE: I’ve somewhat over maligned the wiki in this discussion. It isn’t great but it is actually a wealth of information and is a wonderful reference. What is lacking is a User’s Guide which will help the new user navigate the reference)

It should be but in my experience it won’t be. New users will search the DB, see that a device is listed as compatible, then come to this forum and wonder why, for example, their zwave switch won’t work that is 400 ft from the controller with no other zwave devices in-between doesn’t work.

But the number of supported controllers is small. And the list of supported controllers is the key compatibility point. If you have a supported controller you are compatible with almost everything that controller supports. I’m still seeing this DB as solving one single problem (i.e. giving new users a list of devices that were known to work with OH at some point) without actually directing the user to what they should focus on which is choosing a technology and a controller and then identifying the specific devices.

And frankly, a lot of user just come out and ask “will maker/model device work with OH” and we are happy to answer. But I think most users just search for a device and when they find one make sure the technology and/or API is supported by looking to see if there is a binding for it.

I’m still not convinced it will be all that HUGE of a help. Certainly not enough of a help to justify the effort, which I still maintain you underestimate. And I’m still not convinced that it solves more problems than it creates.

So far this has not proven true.

Let me counter propose a solution. One thing that is sorely missing from OH 1 is a User’s Guide (at least in English, apparently there is a German User’s Guide). A User’s Guide is planned for OH 2 and writing one for OH 1 is OBE. Would a chapter in the User’s Guide that explains that the key for compatibility is the controller, provides information about how to choose a technology and a controller, and how to find compatible devices once a technology and controler has been selected solve this problem? Then direct users who still have questions to the forum. Then a database or table for devices (or classes of devices) that seem like they should work but don’t, or require some additional finagling to make work only.

Like they say, multiple ways to skin a cat :slight_smile:
… or two sides of a coin…

I am new to openHAB (OH) and home automation (HA), but not new to electronics or certain programming languages; my take from the perspective of a newbie (to OH and HA); my approach and view was/is as follows:
a) be able to understand what OH is capable off (basic architecture, bindings = supported technology)
b) what it runs on
c) proper succinct! installation guides (e.g. I should have found a manual install doc, without the note (here) to preferably use apt-get for a (let’s say) community-consistent perspective (supportability; without going into ‘proprietary’ installation preferences for whatever reason they might exist).
d) understand how it works (sitemap, items, rules); this I find to be the most important point. If I cannot make this work at a very basic level in a very short time, frustration levels increase to the point of giving OH a miss. (And I was close; thanks to Rich, sihui and others I have decided to make OH my chosen ‘integrator’).
e) only then would I look around and see what hardware goes with it (which is what I am doing at present; however I am not too much concerned with, because of the over 100+ bindings).

A very good point was made here: the key point is support of controllers (bindings), once the controller is supported all devices that hang of that controller will work with OH as well.

As result of this, listing devices seems IMHO pretty pointless; the devices come and go, discontinued, new ones, changed ones, etc.

Why am I using OH? Because of its power and wide controller support, vendor agnosticism, and community support… not because it supports a certain device from a certain vendor.

Another note: (I have read so much on this forum and can’t remember where), but someone said long these lines: home automation is a complex topic, and therefore needs considerable time for understanding the topic, as well as needing time for the implementation of a solution.

Potential users with the idea of a ‘quick’ solution to a problem, or the arrogance / ignorance in not wanting to do some (even basic) form of programming should be nicely fobbed off and encouraged to buy a turn-key solution, or go with a commercial grade install instead (C-Bus, KNX, etc.).

My 5 Cents. :slight_smile:

In any case: I appreciate the contributions of the members of this forum – and wish you all the success!


Thanks for your 5 cents. However, I believe this topic is going into a wrong direction now.

I’m fully on your side when you say you have chosen openhab because of it’s architecture, platform independence, wide controller support, vendor agnosticism, and community support. I did too.

So we are far beyond a) to d) and should concentrate on e). Moreover this topic was never about “arrogance / ignorance in not wanting to do some (even basic) form of programming”. I think all of us are already familiar with openhab and have at least one working setup.

What the topic is/was actually about is an easy way of finding supported devices that match certain criteria, e.g. finding all motion sensors with light control or finding a technology/protocol that supports RGBW LED strips, motion sensors, and … and list me all those devices. My main aim was to simplify the search for appropriate hardware and for choosing a certain technology or maybe technologies in case that one technology does not cover all your needs.

However, as I see in the responses of this topic there’s a lot of doubt that such a device database could be filled and managed by the community, similar to wikipedia. Well, I believe it COULD work if it’s prominently placed on one of the main pages about OH hardware and if people are encouraged to contribute to it. Unfortunately, at the moment I don’t have time to implement it. Maybe next year.

BTW, IMO home automation is not really a complex topic. It can be quite intuitive and OH2 is already going this path. At the moment it’s necessary to invest an whole evening to setup items, rules, and sitemaps, but in future this won’t be necessary anymore, I think. However, by far the most time consuming part is my opinion the hardware selection/optimization problem:

  • finding all possible useful devices for your home automation problem and comparing them
  • finding a minimal number of technologies that cover all necessary device types

This problem is in fact a really complex one because you have to invest days (depending on the complexity of your home automation system) to find an ideal solution that maximizes the functionality and minimizes the price, especially when you think of the time you sometimes have to invest in looking for a good technical description of a product. For instance, if you’re looking for a motion sensor you want to know if it’s IR based, if it has a light control or a pet detection, and in which angle it’s able to detect objects. That’s what a good device database could answer.

1 Like

Well, I am sorry if I pushed the discussion out of space :slight_smile:

I am new to OH, and simply wanted to add my newbie opinion to this topic, in essence saying: I do not care much about suitable hardware being in a db, and be it only for the reason it could be outdated due to the fast speed of change in that market.

The order of my points are reflecting the order of importance for my progress with and acceptance of OH.
I know OH2 is the new thing and OH(1) may fall on a way side, in particular when it comes to documentation.

As for the ignorance part; I read some posts where the OP outright refused to get an understanding of how OH works, yet 80 posts tried to help this guy… whatever the reasons; at present is for the technical-minded audience… and while I am technical, I am still struggling to get anywhere with OH (at present).

As for your last paragraph: exactly what I use Google for. (It is self-updating too.)

I think the community spirit is, if you want to contribute: simply contribute :slight_smile: If you want a db, why not build it. Would it be important for me? No.

That was probably me. Can’t remember where I posted that but I’ve done so more than once. :slight_smile:

As a data point let me just point out that the zwave database which is REQUIRED for the zwave binding to work with certain devices is incomplete. The zwave binding is one of the most used bindings and this community has a really strong incentive to make this database complete because if a device isn’t in the DB it doesn’t work. Yet this database is incomplete.

If we can’t keep this vitally important database kept up to date fast enough, what chance is there in keeping up with the other 149 technologies that OH supports?

Here is another example. Zoneminder set up a sort of database (really a wiki) that is supposed to list all the compatible IP cameras that work with it. Guess what, it is inaccurate, incomplete, and in my experience thus far not all that useful.

On-the-other-hand I’ve seen some other FOSS home automation environments that do have a DB of supported devices that are purported to be complete and accurate (obviously I can’t verify). Though they are usually just dealing with a single or handful of technologies.

Not sure if you are just super genius level on this stuff or naive. I suspect the latter because in my and almost everyone else on this forum experience, home automation is actually quite complex. There is complexity cause by the fragmented nature of the technologies and standards, complexity caused by the interaction of these disparate technologies, dealing with errors and problems that will inevitably arise, complexity caused by designing a home automation system that is actually useful (what should I do verses what can I do), don’t even get me started on security, complexity caused by the fact that no matter how simple you make it configuring the behavior of the automation is programming, and indeed complexity caused by the need to determine which technology(ies) will work best for your application.

And there will always be the need for setting up Items, Rules, and Sitemaps. Doing so will become easier but to eliminate the need to set them up necessitates removing options, capability, customization, and other features.

If that is what you are looking for may I recommend looking at some of the less capable but easier to set up environments like Apple’s HomeKit, Wink, or Vera.

Only if, as you admitted above, you have no requirements. When you have requirements (e.g. I want to be able to open and close my garage door and know its status) suddenly the hours and hours of research turns into a quick Google/Amazon search and choosing between perhaps a dozen devices (to include the DIY Arduino/Raspberry Pi route).

In my experience the hardware selection has been the least challenging part of this whole endeavor. But perhaps this difference has more to do with the fact that I have and continue to gradually build up my home automation as opposed to trying to come up with something fully formed like Athena from the forehead of Zeus.

I chose zwave because I knew OH supported it and it appeared to have lots of different devices from multiple vendors. Then I decide “I want to automate X.” I look to see what devices in zwave or wifi might do X and check to see if this is something I can do faster/cheaper as a DIY. Then I implement it. I spend far more time coding the rules than selecting the hardware and I spend far more time coming up with “X” then any of it because I am very strict about about I will and will not automate and how it must work.

I don’t think that I or anyone else is arguing that such a database would be a bad thing or wouldn’t be useful. Ultimately I think the argument comes down to whether the creation of such a database is really something that is:

  1. achievable
  2. maintainable
  3. appropriate for the OH community

Personally I have extreme reservations about whether it is achievable (see my zwave db example above) or maintainable. It is hard enough for the maintainers to get enough people to review pull requests on the bindings. Who is going to build a database of tens to hundreds of thousands of devices that OH can support with all the technical detail you are asking for, particularly with the knowledge that it will be obsolete and incomplete on day one? Given the failure of this community to even keep up with zwave I don’t see how a DB that covers all supported OH technologies is possible.

But even if it were possible, is it an appropriate task for OH? I can only answer from my personal perspective which is No, it is not appropriate for the OH community to take this on. OH is not a “one stop shopping” experience. It was never built to be and never intended to be. I think it is perfectly reasonable to prioritize the work of building OH 2, beefing up the OH specific documentation, and managing the growth of the project. Just as I don’t think it should be expected that this forum should be able to provide debugging advice for your custom Arduino creation you hacked together by copy/pasting code from here and there, I don’t think it should be expected that OH would maintain a team whose sole purpose is to troll the Internet to find and consolidate every single device that OH could possible work with.

While that is true, don’t forget that Kai has been very careful to preserve OH 1 type functionality in OH 2 so theoretically you should be able to take your config and all you have learned and apply it to OH 2 too. But indeed, if I and Kai get our way, the OH 2 documentation will be better than the OH 1 documentation and updating the docs will be part of the review and acceptance of any pull request.

Was that one of mine too? I’ve done that twice. I tend to bail sooner or avoid engaging on those threads now.

Indeed. If you want it build it. There was another thread on this very same topic a few months ago. As far as I know none of those posters pushing for a hardware DB have started building something yet. Just because I don’t think it is a good idea doesn’t mean it shouldn’t be done if you do. Like @Max_G, I would not get much use out of it but clearly there are at least three or four people who have posted to this forum who would. I bet if you search for “hardware” it won’t be too hard to find. Perhaps you can reignite the conversation with those users and form a team.

But the current set of active contributors and maintainers I believe share my opinion so I don’t think you can expect them to step up and build it.

1 Like

Hello guys I will throw my few cents in here. This is a situation I am currently going through. I am new to OpenHab2 and from a new user stand point it is very difficult to sort out what will and wont work with OpenHab2

I ordered a WIFI Switch and it appears that this will not work with OpenHAB. I have also ordered a RGB wifi controller and I’m guessing this also might not work with openhab.

You have a huge user base why not pull from them to develop what is native (Plug & Play) and Modified (re-Programed / Requires additional hardware) And Heavy Modified (Hacked / Re-Flashed) I think that if you break the hardware down by Systems / Usability that would help to sort it down. You can also list the major Players and then refer to the bindings for additional info at the point like Nest, Zwave, Zigbee.

So here would be a example of the break downs:


   Music Players

Lighting Switches
Power Outlets
LED Controllers
RGB Lighting Controllers
DMX Controllers

HVAC Controlers

IP Security Cameras
Wireless Lock Systems
Motion Sensors
Contact Sensors

Video Control
TV Integration
Media Servers
Projectors Control
Screen Control

And so on! Then under these groups would list hardware that your users have gotten to work. Ideally a link to buy them would be great too. Share the knowledge of what others have struggled with to find hardware that works!.

Like I said above. There is nothing stopping anyone from doing this. But:

-any such list will be immediately and forever out of date resulting is dozens of devices that no longer work remaining in the DB and hundreds of new devices that do work but no one has added them

  • it will be huge, from the tens of thousands to millions of devices
  • the effort will be huge to build and maintain it
  • because of the effort involved the value for the effort will be limited
  • how to handle devices that have an open API but no official binding?

I think it would be a far better solution to write a “before you buy” tutorial to tell new users how to determine a specific device will work.

  1. Search the docs for a binding spring that technology (e.g ZWave, knx, etc)
  2. Search the docs for that company
  3. Search the web for that company plus the word “API”
  4. Ask on the forum
1 Like

Although I can see some utility in having such a database, I would have agree with Rich that the feasibility of such a task is largely in question. I would also agree that the efforts of those main contributors to the project would be better served by focusing on improving the code and documentation.

As an alternative I might suggest that if you have a successful experience with a product, particularly an obscure one, that you would document it. Either here on the forums or otherwise. I have posted a short tutorial here in the past on how I reflashed my wifi Ecoplugs with espeasy and tied them in to OH via mqtt.

My process for selecting a product is similar to what Rich suggested.

  1. Do a search for the product + openhab
  2. Do a search for the product + API
  3. Do a search for the product + hack/flash etc to see if it can be modified to support open protocols
  4. Do a search for the product + ESP8266. To be honest this is usually closer to the top of the list :joy:

Once you have information about the product, particularly whether has open protocols or can be modified to support such, it is pretty easy to guess whether you will be able to integrate it with OH.

1 Like