Smart Home: openHAB 3 brings a fresh structure for the control console

Every year the openHAB community publishes a fresh release shortly before Christmas, and this year there is a new main version in the advent calendar. The 3.0 release brings some changes to the architecture including a uniform user interface and thus ends the balancing act between the purely code-based control of openHAB 1.x and the UI of openHAB 2.x. The release finally cuts off the 1.x pigtail and dispenses with the compatibility layer integrated in version 2. This means that openHAB only has one uniform concept of bindings. In the course of the changeover, however, the community has implemented numerous new 1.x bindings in order to ensure the smoothest possible changeover. A Table on GitHub showswhich add-ons have been migrated accordingly.

Semantic models

openHAB brings with it a new user interface that is more contemporary on the one hand and can be adapted for different user groups and devices on the other. A basic concept is semantic modeling, in which the semantic tags introduced in version 2 but rarely used in the old release serve as the basis for describing the smart home.

At the technical level, so-called things represent devices with their sensors and actuators. As an abstraction, openHAB offers the concept of items as a comprehensible description of the unit. The semantic model tutorial lists as an example that the device zwave:1231242:node12:switch becomes a “living room lamp”. Each item has the four properties of location, equipment, point and property, which in turn are interconnected. The former describes the location like living room, and the equipment contains information about the associated equipment, including battery, remote control or motion detector. Point describes the type or function such as alarm or measuring device, and Property contains the associated information or the measured or controlled value, for example the temperature.

With version 3, semantic modeling is the recommended procedure for creating and managing smart home components with openHAB.

Pages and Blocks

The concept of individual pages for interaction with the smart home is also new. The respective pages can be designed as maps, floor plans or diagrams, for example, in order to tailor them to suit the respective application.

In the course of the alignment, there is only one uniform rule engine that integrates the rules written in openHAB’s own Domain Specific Language (DSL) into the user interface. In addition, rules can now also be created in JavaScript, Groovy and the Java implementation of Python Jython formerly known as JPython. If you prefer a visual approach, you can now also use scripts for home automation with the Blockly programming language developed by Google which, like the Scratch language developed by MIT, enables code to be built in a graphical environment with predefined blocks.

Involvement of outposts

The noteworthy innovations also include the fact that distributed architectures can now be implemented directly with the software via openHAB remote binding. A central instance controls several openHAB outposts. Until now, a distributed architecture required the use of the MQTT protocol, which is widespread in the IoT environment. In addition to an MQTT broker, the integration of the MQTT binding was required for each instance. It is also worth mentioning that the ecosystem has grown significantly since the release of openHAB 2.5 a year ago: The GitHub repository lists 86 new add-ons since last year.

Focus on Java 11 and openHAB 3

Under the hood, openHAB 3 relies on Java 11, while the predecessor used Java 8. The team has also updated numerous libraries and removed methods marked as outdated (deprecated) and implemented current OSGi features. The further timetable sees according to the openHAB blog Minor releases every six months, so that openHAB 3.1 is planned for the summer. For version 2.5.x there will only be updates to make critical bug fixes. Such will also be available as 3.xy releases for the current major version. (rme)