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