Binding / Addon development

Hello community,

If you have been to https://www.openhab.org/docs/developer/ recently, you might have noticed that we are working on different IDE setup instructions to get you started on addon development.

Still, the setup instructions are rather lengthy and Java as a language is also a bit noisy.

I suggest that we as openHAB community are opening up for external non-java solutions:

  • Make them installable via the addons section in our future user interface.
  • Seamless integration like any other java addon

Especially for binding development this is in parts already possible via MQTT and the Homie or HomeAssistant convention. You can develop a C++ or javascript/nodejs (or other) device integration and publish device capabilities / properties via the mentioned MQTT standards. openHAB will pick them up and even offer auto discovery.

We should not only list java addons on our addons page but also all device integrations that make use of any of those MQTT conventions.

I like to take this a step further and think about openHAB in the free software home automation eco system.

Extend MQTT Homie and allow device configuration

Right now it is only possible to use already configured Homie MQTT device integrations. Imagine for example a Philips Hue to MQTT bridge which exposes Hue devices as Homie MQTT devices. This bridge software requires some configuration like where to find the Hue bridge, and user authentication. This is at the moment done by custom configuration files, non standardized.

I propose to extend the Homie convention to also allow to configure a Homie MQTT device via MQTT itself.

Use other discovery / device description standards: Web Thing API

I’d also say that we add a (generic) binding pretty much like MQTT2 that discovers and makes Mozilla Web Things (https://iot.mozilla.org/) available to openHAB.

The web thing specification (https://iot.mozilla.org/wot/) defines HTTP and Websockets for communication (both TCP based like MQTT) and describes a device (=OH Thing) and its properties (=OH Channels) and how to interact with it.

Mozilla provides Web Thing scaffold implementations in many languages like Javascript, C++, Rust, even Java and it is way easier to develop a binding like for example for your favorite weather service in Javascript as a Web Thing. There are also Web Thing demos for Arduino / ESP8266/ESP32 to make your Sonoff or any other DIY project automatically discoverable without an MQTT broker.

And in the future we might just use those Mozilla and community Web Things in openHAB and develop Web Things ourselves if we don’t want to deep dive into Java/OSGi openHAB development.

And the community developed quite a few Web Thing bridges (called Web Thing adapters) as well, which we can take advantage of (about a hundred, ranging from simple Wake-on-lan to Zigbee/Zwave to WebThing adapters).

Performance: You might ask yourself if a java addon is performing better on a resource restricted device like a Raspberry PI. Actually the Web Thing might perform better with less memory consumption and resource leakage, if written in C++/Rust.

Ease of development: The average weather binding that takes about 1000 lines of code and xml files in openHAB is done in 30 lines in javascript via the Web Thing API scaffold project.

Open up to other free projects

openHAB is a Java project. And java is more and more an enterprise only language. If you want to stay on the JVM (java virtual machine) nowadays I see Kotlin leading (because of Android development). But it’s hard to foresee.

I see the future of openHAB in opening up and allow more developer languages to be used to extend functionality and be a heterogeneous eco-system. For example you can use the MQTT broker that we offer in our addons section. It’s a java project therefore we could ship it with OH. But it’s so much less mature and more resource hungry than the C++ counterpart Mosquito.

Related

Related issue in core to make other that java addons available via the Addons tab in future user interfaces:

DIY devices based on ESP Home:

Cheers and a wonderful weekend,
David

2 Likes

@David_Graeff I couldn’t agree more. I had not seen the web thing specification, that could be interesting. I would also be open to working on an extension to Homie to support configuration.

Ease of development : The average weather binding that takes about 1000 lines of code and xml files in openHAB is done in 30 lines in javascript via the Web Thing API scaffold project.

openHAB is a Java project. And java is more and more an enterprise only language. If you want to stay on the JVM (java virtual machine) nowadays I see Kotlin leading (because of Android development). But it’s hard to foresee.

Java, the OpenHab binding API, the large binding repo, and build experience makes developing a binding feel like death by 1000 cuts. Sure, each one is manageable, but combined, it makes developing and maintaining a binding feel like a job rather than hobby. Honestly, in all the talk about “Is OpenHab Dying” there is a lot of discussion about that we need to attract users. That is important, but it is a lot less important than attracting developers. Lack of developers will kill openhab, not new users. To attract developers we need a better development experience.

To address some of this, after Homie integration into the MQTT binding I created a binding to use and manage docker containers along with OpenHab. The binding provide some scaffolding (MQTT server location etc) to all of the containers under its control. Docker is used for automatically fetching and updating (no longer tied to the Openhab release cycle - yah!) and lets you use whatever language you want - just needs to communicate over Homie/MQTT. The binding takes care of shutting down and starting the containers. You can also have containers that are executed on-demand as well.

Unfortunately yes. I would have liked it so much more with an interpress communication model and a defined binding API, language agnostic. That’s what the Web Thing Framework of Mozilla does. It is how it is though, might even be an advantage that the persistence layer etc is all in one process. But for new bindings at least it might make sense to have them implemented as MQTT Homie Devices and Web Things.

Personally I’d say that we start to distribute openHAB mainly as docker container. I have recently written a short script that builds an entire OH distro with addons and packs it into a docker and embeds it into a Belena OS (https://www.balena.io/os/) image, ready to be written to a Raspberry PI SD card.

It works for HomeAssistant, it will work for us.

And yes, I agree that specific services should be just installed via Docker. I have explored our possibilities and discovered that Karaf, our OSGi container, can actually handle docker containers in the same manner as karaf features (aka OH addons). That must just be exposed via the above linked ExtensionService for user interfaces to be able to list and install available dockers.