Hello, I am a new arrival here and know very little about OpenHAB. In fact, I’m not really interested in learning about it until I determine that it is a viable and good solution for what I want to accomplish. So I’m asking the community to offer some guidance…
I have a C++ application I’ve written, running on a Linux ARM SBC, which is my home automation control system. It handles I/O, data logging, switch logic, DMX control, sensors, HVAC, and more. I want to integrate it with Apple’s HomeKit to leverage Apple’s UI capabilities for this domain. I could directly implement HAP into my application (there are various available implementations), but it seems prudent to instead use a bridging technology that can bind to multiple 3rd party technologies, just in case we get other UIs in the household (Amazon, Google, etc). OpenHAB seems to be a pretty robust solution here, with an active community. Yes? No? Other opinions?
My core question, however, is that from an initial survey of the OpenHAB website its not clear what the most straightforward way to interface my C++ application (which embodies the lighting, sensing and HVAC systems) to OpenHAB. It looks like devices usually have a “binding” written for them (in Java?), but I’m not keen on spinning up on enough Java to code and debug this and then maintain it as things are inevitably versioned and evolved. Is there a generic binding that is recommended to which I can present a complex device with many accessories and all their attributes?
Okay, sounds like a solid recommendation… however, since there appear to be direct bindings between MQTT and HomeKit/etc. what is my motivation to use OpenHAB?
Sure, might be relevant some day, but OpenHAB looks like a fairly non-trivial software stack with a fair amount of configuration required. In any case, MQTT looks like a sound direction to pursue, so thanks. If I decide to stand up an OpenHAB instance, I’ll be back with more questions, I’m sure.
Binding api is quite stable and changes which are coming into this part are mainly improvements coming from varios aspects of implemented bindings (ie support for units as integral part of measurements). If you will check OH 1.x its not that complicated.
OH 2.x is slightly more advanced because it introduces few abstract definitions.
If your home controller wrotten in C++
has external communication interface, and believe it must have such thing already, you can utilize existing addons such exec or http in order to interact with your software. It wont give you a great user experience but at least will let you to brodge things with no effort.
Starting a new binding will be a challange because your existing C++ api/sdk has to be bridged to Java. There are several ways. First - create a native binding skelton to simply pass as much and as early as possible from java to c. By this way you could stay in environment which is convinient for you. Definitive disadvantage is necessity to handle jvm types as input and output from native implementation.
Second option does not require (in theory) that much C++. It is JNA, and allows to call native code from Java. It rely on certain assumptions thus on some cases will allow to have 1:1 mapping between c and Java. Because of bigger overhead it might be slightly slower, but all benchmarks I saw showed minimal difference between both. In such case you stay more on Java side.
Thanks for the suggestion, but I’m really trying to minimize the number of languages I have custom code in. Adding Java is definitely low on my list (apologies to the Java fans, but I’m just not). The MQTT recommendation seems like a good way to go, and I believe I’ve found a path forward that is compatible with my program architecture (libuv-based).
