Hello community!
We are developing an IO board for home automation based on the Raspberry Pi 2.
More information about can be found here http://www.conmeleon.org
The first hardware revision is already finished and operational and we are already working on the revision 2 with more IO.
To use this hardware now in a home automation we need the necessary software. Currently we have 2 software solutions. q4PLC and 4diac support the automation standard and are for the classic automation a good, simple as well as modular solution.
For the classic home automation application, we would like to offer an openHAB2 binding for our boards.
My question would be whether there is an existing solution for communication over the network between openHAB and a Raspberry Pi to transfer the IOs from CONMELEON to openHAB and visa versa?
It would also be helpful that openHAB2 automatically recognizes our Board and serving our binding.
You need to provide a lot more information about what you mean by this question. What is your expected use case (e.g. OH running on the CONMELEON or OH running on another server and communicating with CONMELEON over the network or a serial connection)? What API does CONMELEON support (e.g. does it have a REST API, MQTT, GPIO, etc.)?
Out of the box there is an HTTP Binding, a TCP/UDB Socket Binding, an MQTT Binding, a GPIO Binding, a Serial Binding, an Exec Binding (for calling command line scripts which may be able to do things OH can’t do natively) and more.
Our use case would be to run OH on another server and communicate with CONMELEON over the network.
We would like to offer our own Binding in OH. And this binding is then communicate over the network with the CONMELEON module and pass the data to OH.
It would be helpful to know on what protocol we establish the communication.
Perhaps there is prepared such a communication based on Java for OH and Raspi.
Would it, for example, conceivable to integrate a MQTT broker in the CONMELEON binding? This broker would then be automatically installed with the CONMELEON binding.
Of this, the user would not notice in the first step. What makes the integration of our module would be very easy.
Communication between CONMELEON binding and CONMELEON module would then be carried out by MQTT!
Or there would be more of OH philosophy correspond to integrate the CONMELEON module via an external MQTT broker and the OH MQTT Binding?
Although I am of the opinion that this solution would not be so konvortabel!
The closest existing example (the Mqttitude binding) is halfway between these two extremes. I know of no binding that comes with its own MQTT Broker and am not sure how well that fits with the OH architecture. They all depend upon an externally installed and configured broker (most people around here use Mosquitto though some have been successful with RabbitMQ).
Personally I’m of the opinion that one of the biggest problems that OH has right now is that there are too many bindings and too few maintainers and reviewers to keep up with them all. So I tend to be down on the creation of any new binding that duplicates the capabilities of an already existing binding. However, as with the Mqttitude Binding, even though the communications duplicates the capabilities of an existing binding (MQTT binding) what it does with the messages (e.g. geofencing) does warrant its own binding.
So, in my opinion, and I’m just an active user of OH, not even a maintainer right now so my opinion should carry too much weight, whether it makes sense to build a separate binding for CONMELEON or not depends on whether there is some additional calculation, a fixed API, or some auto-discovery of sensors/devices that would best be implemented in a binding (auto-discovery is an OH 2 feature). But if we are just talking about passing some numbers back and forth between OH and CONMELEON then I would would probably advise against a separate binding.
As to embedding the MQTT Broker, while that may seem initially to be more user friendly I think you will quickly discover that the amount of configuration options that you will have to expose in your CONMELEON config to support configuring both your embedded MQTT Broker and your CONMELEON stuff will quickly erase much of the simplicity you appear to gain by embedding the broker.
