I don’t think that is the case. This is a project that understands that bridging the gaps between 360+ walled gardens is going to be complex. The only way to be successful at eliminating the complexity is to eliminate the options. This is why commercial offerings, which are much simpler compared to OH, only support half a dozen technologies and standards.
You can’t have it both ways. OH has chosen to support more technologies even if that does cost more complexity rather than limit the end user’s options. If that trade is not a good one for you then a commercial offering is going to be a better choice.
One thing that a lot of users new to home automation do not realize is that building a smart home (or whatever you want to call it) is development effort. You the user are and will be responsible for coding the behaviors of your home automation. You the user are and will be responsible for configuring the system to inter-operate with what ever technologies your bespoke home automation system uses. You the user are and will be responsible for constructing and creating the end user interfaces and experience.
OH is a platform whose goal is to make this easier. But it can only go so far. You WILL have to deal with the complexities of development.
OH 2 has and continues address these complexities in many ways (automatic discovery and creation of Things for instance) and it is by no means done addressing ways to make it simpler. But OH is NEVER going to provide the end user a Firefox like end user experience. It can’t, because OH isn’t the end product. The bespoke home automation system YOU build is the end product. And I can say with authority, almost all of our end user experiences DO approach something like the Firefox experience. But we, as our individual system builders had to put in the work to make it so. OH can and does help (I can’t imagine trying to build a system like I have without some sort of HUB) but it can’t do it all.
I cannot stress how important this will be in anyone’s use of any free and open source home automation hub.
My understanding this is the goal. It is taking an extended amount of time to get there though. And do not underestimate the fury of the old timers if you take away a feature like being able to define Things in a .things file.
But I believe we will get to a point where there will be one official recommended way to doing things. Though support for some of the old ways will persist. I don’t think we will be able to drop them until a 3.0 release where we can say 1.x bindings are no longer supported (for example).
There is a Chocolatey package for installing OH which I believe will also install Java if it isn’t installed already.
See my comments above. Home Automation IS a development effort. You can’t get away from that. Even working with the commercial options requires a bit of programming (more at the Scratch level perhaps). What is Home Automation but defining behaviors of your devices under certain circumstances? And what is defining behaviors but another way to say programming them?
Comments like this, IMHO, show a lack of understanding of the Home Automation problem space and OH’s role in address parts of that problem space,
A home automation system that doesn’t let you define your own behaviors is no home automation system at all. At best it’s home remote control.
Quite a lot actually, but OH does a decent and always getting better job of hiding that fact from you. Much of what you are doing when you create Items and link Items to Channels and create Groups and most especially create Rules are all exercises in programming, whether you realize it or not. The fact that you missed it points to how successful the OH developers have been so far in reducing that complexity.
Possible but I wouldn’t recommend them yet. They are still experimental.
There is no requirement to program in Java to run OH. The only requirement is to install Java as a prerequisite as OH runs on the Java Runtime Environment.
Just like installing Python is a requirement to running Home Assistant.
Java is needed. Programming in Java is not.
There IS programming required to develop automation Rules but those are written in other languages. The default is to use the Rules DSL which is a simplified programming environment a little friendlier to users of OH who are not already programmers. Those who are already programmers are usually happier with one of the other options like JSR223 scripting or using an external rules engine like NodeRed.
An administration UI for OH. See
Perhaps this is unreasonable on our part, but I do know that when I personally send someone to “read the Beginner’s Tutorial” I expect them to read through the tutorial, not try to perform all the steps (the first time) and then stop when they run into trouble, especially when your main goal is to figure out whether or not OH is something you want to pursue.
Building docs is hard. Building beginner level docs is REALLY hard for experienced users and developers to write because it has been far too long since we’ve been beginners. So we are stuck in a catch-22. Beginners are usually unwilling to contribute and experienced users are no longer qualified to write them.
I don’t think most of us think there is no problem. But is there a problem here we can actually solve? Maybe. Do we actually have any concrete solutions or recommendations of solutions to solve the problem? No, we do not.
You are most certainly right. It isn’t intended to control a few devices. It is intended to mix and match the behaviors of dozens+ devices from any number of different walled gardens of technologies and services in a unified way.
If you want a virtual remote with buttons to control a few lights, OH is way overkill for you. If you want the lights to just know when to turn on based on external stimuli from sensors from three or four different technologies which don’t normally work together then OH is a good place to start.
And now you know why there is no list of devices. OH literally supports tens of thousands of different devices and the number grows every day. The amount of effort required to build let alone maintain such a database is not feasible.
Instead, what one can and should do to determine if a device is compatible is determine what technology/API it uses (Zwave, TP-Link, Xiaomi, etc) and look for whether there is a binding for that technology. If there is only limited support for that technology the read me for that technology will list that. For example, there are only a few Zigbee coordinator chipsets the Zigbee binding will work with. They are listed in the binding readme which you can find under the Add-Ons link at the top of this page.
At the end of this long thread, I think that indeed, OH may not be the right system for you. Your problem may be smaller than OH was built to solve and so the complexity is really beyond what is worth it for you.