123 said:
OpenHAB's transition from version 1's architecture to version 2 has not been painless. It required modifying all drivers, excuse me bindings, to be compliant with the (improved) architecture of version 2. If you omit updating a binding it becomes a second-class citizen within the version 2 environment. This is the fate of OpenHAB's UPB Binding (plus it has a known bug when running on a Windows PC).
Agreed. When I jumped in, I had the choice of starting with a very stable OH1, or a very unstable OH2. I chose OH2. People coming from a stable OH1 environment definitely experience pain in the transition. I see that pain in their forum postings... There are some big differences that are pretty easy to handle. It's the subtle differences that often can inflict some real pain.
Some OH1 bindings fit better in OH2 than others. I still use some OH1 bindings (MyQ, Ecobee, Google Calendar Scheduler), which work well in the OH2 environment. OTOH, the reason I wrote an OH2 GlobalCache binding was because the OH1 GC100 binding had some real functional and technical issues and limitations in OH2.
123 said:
Premise's drivers can (automatically or semi-automatically) discover associated devices and make them available in Premise Builder. That was one of the major improvements in OpenHAB version 2. However, the problem (as I see it) is they did not create a unified environment. In version 1 you defined everything in a configuration file. In version 2 it finds things automatically and stores them ...
not in the configuration file. No, it stores them in a repository that you cannot edit (or at least that was the state of affairs the last time I looked at it several months ago). Automatic 'thing' discovery goes in one place (that you can't inspect and edit) and manual 'thing' configuration goes in a text file. <pffft>
The old unviewable and uneditable mapdb has been replaced with a JSON-based storage service, which you can view and edit. Edits need to be done with the system stopped.
123 said:
There's no binding for an ELK M1 (not even a beta). Nor for my trusty Omnistat/2. There are well-maintained bindings for HAI and DSC panels. However, it's a non-trivial undertaking to make an ELK M1 binding even if you use the HAI or DSC binding as a starting point.
Yeah, it would be a pretty big job to build these for openHAB, especially if it's your first binding.
123 said:
The other thing is that OpenHAB's heritage is European. So if you have some distinctly North American gadgetry, especially legacy North American gadgetry (hello UPB, ELK M1, Omnistat, etc), you'll be hard-pressed to find much of an audience. Check the OpenHAB community for UPB-related posts and it's a microscopic percentage of the whole. Talk about ELK M1 is even less.
Both OpenHAB and Home Assistant introduce many conveniences not found in Premise. However, when you dig a bit you discover they also lack things we take for granted in Premise. For example, I recently discovered that, for all of Home Assistant's power and sophistication, you have to restart it after adding a new device. It only registers devices at start-up time. Want to add a new thermostat driver or an additional light? Just modify its configuration file but then make sure you
restart Home Assistant otherwise its blind to your additions. <pfft> It also means a driver can't discover a new device while Home Assistant is running and automatically include it for general use ... it'll only become functional
after the software is restarted (What does all this rebooting remind of me of?!? Oh yeah, installing programs on MS-DOS.)
There are some things I miss in openHAB (such as Scenes and Logic Diagrams). But for me, the support for modern devices and modern user interfaces outweighed the shortcomings. The European heritage is becoming less of an issue, but you're absolutely right that this heritage has left some gaping holes w.r.t support of legacy North American devices.
I like the fact that it's multi-platform (and runs on a modern OS). Linux easily has the most deployments, as there are far fewer Windows and Mac deployments. I don't want to say that Windows users are second class citizens, but Windows-specific issues definitely take longer to get fixed. Mac issues (of which there are fewer due to the similarities to Linux) get fixed quickly because some of the developers are Mac users.
The rule language (xtend) is a PITA to learn. Really! Fortunately, there's a new rule engine in the works that will support Javascript and Jython.
123 said:
So, depending on what gear you have and what functionality you wish to gain, and what you can stand to lose, the transition might be fairly painless ... or hellish. If you have no legacy devices to automate, then OpenHAB is a viable option (or Home Assistant). Otherwise, making the move can be onerous. Either you commit to writing your own binding (the magnitude of the challenge depends upon the target device's complexity) or scrapping your legacy devices and buying late-model gear supported by OpenHAB/Home Assistant. The software may be free but buying new gear isn't nor is one's time and effort to write a new binding.
You sum it up really well here.
Some legacy devices might lend themselves to being integrated through a broker, such as the MQTT message broker (for which there is a binding in openHAB). Others (like the ELK M1) probably not.
All my Z-Wave devices made transition painlessly (I think there are over 500 Z-Wave devices in OH now). For the Z-Wave issues I did run into, the UK-based ZWave binding developer turned around some fixes very quickly (it also helps that Zensys has opened up some of the ZWave documentation). My X10 devices not so much. There is a cm11a binding now, but that's a pretty recent addition, and I haven't tried it out.
Writing my first binding was a struggle. My Java skills were rusty, and I was learning the openHAB architecture. The second binding was much smoother, and would've been easy were it not for the need to reverse engineer the BigAssFan protocol. :-(
OH 2.2 is scheduled to be released before year-end. I expect that release to be the most stable yet. But, there still are some shortcomings (as there are with many things that are under very active development). I run what's called the snapshot build -- basically the nightly build. My test system pretty much runs the latest nightly build. For my prod systems, I tend to stay on a "stable" nightly build until there's a new build that 1) has the features I want, and 2) has no serious regressions.
If you've made it this far, and if there's interest, I'd be happy to post some UI images from my installation.
