openHAB 1.6 and 2.0 alpha Release

We have reached another milestone – openHAB 1.6 has been released! As usual, it brings a couple of new bindings and other add-ons. Just to name a few: There is now support for Belkin WeMo switches, LG TVs, BenQ beamers and Samsung air conditioners. A very interesting new system-to-system integration is now possible with MiOS-bases systems, such as the MiCasaVerde (now Vera Control). But with this release it seems that the focus of development has shifted slightly: While we had huge numbers of new bindings with every release in the past, we “only” have 17 new add-ons this time. But this does not at all mean that there is any slow down in the project activity; the opposite is the case: The community is growing massively and as a result we see more and more people improving existing add-ons and introducing new features to them – the very lively Z-Wave binding that is led by Chris Jacksonis the best example for this.

The community growth is nicely visualized in the OpenHUB (formerly Ohloh) statistics:

The factoids state: “Over the past twelve months, 147 developers contributed new code to openHAB. This is one of the largest open-source teams in the world, and is in the top 2% of all project teams on Open Hub.” - we can be really proud of this community!

Despite the large number of code commits in 1.6, there has not been much evolution on the core runtime itself. There is a very simple reason for this: The work on openHAB 2!

As a recap: One year ago we contributed the core parts of openHAB to the Eclipse Foundation to start off the Eclipse SmartHome project. This project provides a framework for building smart home solutions – and openHAB 2 will be one of such solutions. Others, like e.g. Deutsche Telekom with its QIVICONplatform and Yetu also chose Eclipse SmartHome as a part of the software stack for their home gateways.

Being a general purpose framework for smart home gateways implies that Eclipse SmartHome has its emphasis on providing means to build user-friendly configuration interfaces as well as optimizing it for embedded systems – both topics were not in focus for openHAB 1.

To show where these developments are leading, we have released an alpha version of openHAB 2.0 today. Let me share some first results with you:

A prerequisite for providing user interfaces for configuration is that there is a formal way of describing functionality. For this, the new concept of a “Thing” has been introduced in Eclipse SmartHome. Things build the foundation for the new configuration UIs. They are formally described and provide a lot of meta-data about their functionalities. Things represent the physical devices that can be added to the system and also (web) services that offer certain functionality.

Paper UI showing auto-discovered things

As such, one major feature is the auto-discovery of things: The user does not need to know IP addresses or other ids, but devices can be automatically added. Together with their formally described functionality, this can indeed mean zero effort for first steps.

As a new user interface that also supports dealing with things and their configuration, there is a prototype currently being developed by Dennis Nobel, which is HTML5 based and follows Google's material design. Just as the latest Android 5.0 Lollipop, it uses paper elements and is thus called the “Paper UI”. Although it is still in a very early prototype stage, it is a nice mean to use the new configuration features. You can see it in action in this screencast.

Although many users use a Raspberry Pi for openHAB 1.x, it feels a bit sluggish, especially when many different bindings are used.

Used heap of standard openHAB 2 runtime

A significant part of the runtime deals with processing the textual configuration files (incl. rules), which are realized through domain specific languages (DSLs) – requiring them to be parsed by the runtime is not ideal. Once there are the new configuration UIs in place, the textual configuration files could be made optional – while they can be very convenient and powerful for some users, this would also allow minimal setups that do without it. I am currently experimenting with such a minimal runtime, which packages the Paper UI and all new bindings, but comes without DSL support (and thus without sitemaps, so the other UIs cannot be used for the moment).

Used heap of minimal openHAB 2 runtime

A first analysis shows that it very much reduces the required Java heap size and also comes with a much better start up time than the “full” runtime – the goal is that the minimal runtime is nicely usable on an embedded system comparable to the Raspberry Pi Model A(+) with only 256MB RAM.

Note that removing DSL support currently also means that there is no way of defining automation rules. A new rule engine is therefore another topics that is currently worked on. Its vision is to make rules (or parts of them) easily sharable and reusable by others. Again, this should empower average users to set up automation logic through simple UIs – think of something like IFTTT.

There are also other efforts for reducing the footprint of the runtime: The Eclipse Concierge project might be a lightweight alternative to Eclipse Equinox as an OSGi container. Jochen Hiller is doing excessive testing and bug fixing to move this option forward. Another possibility is to go for Java 8 compact profiles, which would allow reducing the size of the JVM itself significantly.

With so much efforts going into openHAB 2, you might wonder how the future looks for openHAB 1. Well, the openHAB 1.x core runtime has been very stable and thus did not see much evolution during the last two releases. We will keep it this way and will only concentrate on security fixes and critical patches from now on. Note that this is only the case for the core runtime – all 1.x add-ons, i.e. bindings, actions, persistence services, etc. are very actively maintained and we ask our community members to not slow down here.

For the latest cutting-edge features, we want to encourage the users to switch to the openHAB 2 runtime though, once a first production release is out. One important feature is the 1.x compatibility layer, which should help making openHAB 1 add-ons working on the openHAB 2 runtime. With the current alpha release, we want to engage the our community in testing this layer – the goal is to quickly reach a good compatibility with all existing add-ons, so that there should be no reason not to move to the new runtime and benefit from its new features.

That much about the users, but what about add-on developers? Should they start migrating their 1.x add-on to 2.x? Well, there is absolutely no rush to port them to the new 2.x APIs - especially as there are only new APIs for bindings so far, but nothing yet for actions, persistence services or other types of add-ons. Even for bindings you have to be aware that the new APIs are not yet stable and are likely to change over time. Nonetheless, if you start a completely new binding for openHAB, you are encouraged to go for openHAB 2 directly - especially, if your devices can be discovered and formally described. A positive side effect of implementing a binding against the new APIs is the fact that your code is potentially automatically compatible with other Eclipse-SmartHome-based systems. Besides developing and contributing it to openHAB 2, you could also consider to directly contribute it the the Eclipse SmartHome project - but please note that there are some stricter requirements.
To sum things up: The journey of openHAB continues to be very exciting - and as always, there are so many great ideas, that are waiting to be implemented for the next release!