openHAB 2.0 and Eclipse SmartHome

Posted by Kai Kreuzer on June 16, 2014
As I am regularly asked how the projects openHAB and Eclipse SmartHome relate to each other, so I would like to take a chance to provide background information on this topic.

Since its inception in 2010, openHAB's popularity is constantly growing and our community is spread all over the world. Besides being used by end users and developers, openHAB is more and more adopted in academia, research and industry projects. Seeing the project maturing this way, two decisions were taken in 2013:

openHAB UG (haftungsbeschränkt) as a legal entity for openHAB


We (that is myself, Thomas Eichstädt-Engelen and Victor Belov) founded the openHAB UG (haftungsbeschränkt), a small limited company with the sole purpose to run, back and support the openHAB project. The company has no commercial interest and we are fully committed to keep openHAB as a leading open-source smart home solution. Having this company as a legal entity behind openHAB now allows becoming a member of alliances and other activities. The company therefore has official developer accounts at Apple's Appstore and Google's PlayStore in order to be able to distribute the iOS and Android apps for openHAB. Furthermore, the openHAB UG is a member of
    1. the EnOcean Alliance - Since we provide a solution that works well with EnOcean hardware, this was a natural step.
    2. the AllSeen Alliance - Their AllJoyn open-source technology can be a nice complement to openHAB as it unifies higher-level IP-based communication between end devices and could open the door for openHAB to many new devices though a single new AllJoyn-binding.
    3. the Eclipse Foundation - openHAB has always been based on many Eclipse projects, such as Equinox, Jetty and Xtext. But the main reason to join the Eclipse Foundation was this:

Kicking off the Eclipse SmartHome project

To enable others to use code from openHAB in their own solutions and products, we wanted to put the code base on a solid and trustworthy foundation. Th legal aspects of many open-source projects are often pretty fuzzy, even if they have a permissive license. But for companies using such project in their own products, there is always the risk that the copyright of the code is not clear and that the code might be contaminated by patents. To reduce such risks, it is very beneficial to have a rigid intellectual property management and clear contribution processes - this is one of the things that a foundation such as Eclipse provides. We therefore decided to contribute the core framework of openHAB to the Eclipse Foundation, which became the new Eclipse SmartHome project.
So has openHAB now been replaced by Eclipse SmartHome? Not at all - it is important to note that Eclipse SmartHome is only a framework (comprised of a set of OSGi bundles) to build smart home solutions on top. Although there are binary runtime downloads available for Eclipse SmartHome, these should only be seen as a demonstration of what can be done with Eclipse SmartHome - they are not meant as an end customer solution. The main deliverable of the project is a repository of the different bits and pieces to build solutions on top. There are already industry players actively contributing to the project and it can therefore be expected that commercial customer solutions become available later this year, which are based on the Eclipse SmartHome framework. One solution that can be counted on is openHAB - the new development branch of version 2.x is now based on Eclipse SmartHome.

openHAB 1.x versus openHAB 2.x

This leads us to the next questions: Is openHAB 1.x now replaced by openHAB 2.x? When will this be available? And what are the differences and (in)compatibilities?

Well, openHAB 1.x is currently still the main development stream and very active - we have just released version 1.5 and hit a new record in the number of available add-ons; we are close to 100 now!

We will continue the openHAB 1.x branch - the focus being on the bindings and other add-ons. For the core runtime and the designer, only critical bugs will be fixed. So if you are a user rather than a developer, this is the version you should be after.

openHAB 2 has a different focus: User comfort. While in openHAB 1.x you need to configure everything in text files and figure out the right syntax and possibilities of a certain binding in the wiki, openHAB 2 allows bindings and other add-ons to self-describe their configuration, so that it is possible to offer user interfaces for system setup and configuration. Additionally, auto-discovery (e.g. through UPnP, AllJoyn, etc.) is offered, so that new devices can be added by a simple click of a button. Chris Jackson has already built a lot of convenient UIs for openHAB 1.x, which are available as HABmin - this even includes a graphical rule editor based on blockly. We are striving for refactoring and integrating these things as a core part of openHAB 2.x and thus not requiring the users to use configuration files at all (but of course leaving it as an option).

A second major design goal of openHAB 2.x is the optimization for embedded platforms. Although openHAB 1.x works on a Raspberry Pi, it sometimes feels a bit sluggish at startup or with huge installations - this is due to the fact that openHAB had never been specifically optimized for embedded systems and thus uses libraries such as Xtext, which are not meant to be used in constrained environments. In consequence, we will try to provide a minimal openHAB runtime that will work with alternatives or strategies such as pre-compilation etc.

What exactly does this mean for the architecture of openHAB 2.x?
  • The core runtime and its APIs will change fundamentally. We deliberately use the chance to do backward compatibility breaking changes to it in favor of the above mentioned goals.
  • In consequence, the source repository of openHAB 2 will start with no bindings at all and we encourage the developers in our community to migrate their existing 1.x bindings to the 2.x concepts, once these are fully in place.
  • For the time being, there is a "1.x compatibility bundle" that allows to use openHAB 1.x add-ons with the openHAB 2 runtime - this will not run for all of them out of the box, but for the majority of them. 
The good news is that we have now the first developer builds available of openHAB 2! If you try this out (note that it is still under development and not meant for users, but rather developers), you will immediately see a couple of major changes:
  • The central configuration file "openhab.cfg" is gone. Instead, you can now have a separate file for every add-on. This clearly improves the overview over your configuration parameters as your configuration file won't be cluttered with information about add-ons that you are not using.
  • The whole directory structure has been overhauled - there are now three main folders: "runtime" containing the binaries and other content that is needed to run the system. "conf", which holds all your personal configurations and customizations (such as e.g. custom icons). "userdata", which is the only directory that the system actively writes to (log files, databases, etc.). This new structure makes system upgrades much easier and also facilitates the installation on embedded systems where one does not want to use flash memory for continuously writing logfiles etc.
To summarize: openHAB 2 is still in an early phase, but having binary builds with a 1.x compatibility layer available is a significant step forward. You can expect very active development on it in the next weeks and in a few months from now, it should be a worthy replacement for the 1.x runtime.

Shaping the Smart Home market

Moving the core framework to the Eclipse SmartHome project might at first sight seem like adding unnecessary complexity to openHAB. But I sincerely believe that it was the right step for the smart home market in general: The Eclipse Foundation serves as a trustworthy institution that fosters industry collaboration. And collaboration is highly needed - now that Apple has entered the market with introducing HomeKit. Everybody expects Google to be working on something similar after having shown interest in smart homes already in 2011 through the now vanished Android@home and more recently through the acquisition of Nest. So will we see after the smartphone wars now the smart home wars? Will we have to choose all our home appliances in future depending on whether we run our house on iOS or Android? This sounds like the ultimate vendor lock-in, something that I am trying to fight since the beginning of openHAB. We can only escape this future, if the rest of the industry joins forces - the time for proprietary silo solution is up. In my opinion this collaboration can only work through open source - everything else would only end up in competing consortiums that would further drive the market fragmentation. This is why Eclipse SmartHome should be seen as an invitation to the industry to collaborate - it is not so much about using the code that is out there right now, but much more about talking to each other, publicly sharing ideas, and shaping the future together for the better.