Unless I’m missing something, it appears as if JAVA is the only language within which bindings can be created…
What is the chance that a binding can be created with some very specific endpoints to perhaps MQTT that will manage data interactions with bindings created in another (mostly interpreted/script) language?
Such a binding should also have the ability to start and stop 3rd party services so as to be a “one stop shop”. All existing 3rd party scripts used by the community can then be aligned to this bindings’ requirements and become managed as part of the solution. We could even standardise the packaging requirements so that it can simply be dropped into some folder and automatically detected, configured and started from within OH.
The main driver behind this is to make it easier for users and developers to port or create new bindings for OH.
I wouldn’t consider myself a full fledged programmer having only python, node and some limited c background, so I can’t really comment any further on this. If anyone likes the idea or would like to pursue it please lets open a dialog here.
Please look into the work being done with the JSR223 add-on and Experimental Rules Engine. This will go a long way towards achieving something like the above.
However, in order for an add-on to be a true OH binding it will have to be written such that it can be compiled, deployed, and run by the karaf console and natively interact with the ESH core APIs. This will at a minimum limit you to what can run on the JVM and probably imposes even more severe restrictions.
If you want to write something in another language and it is so closely integrated with 3rd party services then you may as well write it as part of that third party service and interact with OH through the REST API. If the third party services are truly third party (i.e. written by someone other than the binding author and closed source) then I for one have severe computer security heartburn in giving an OH binding that ability. To do this OH will either have to be run as root (bad idea) or given special permissions to only be able to shutdown that one service which I’m not certain is even possible without using something like SELinux (I don’t know if it is possible in AppArmor). SELinux is NOT something we can impose on average OH users.
It already works like that. That is what the addons folder is for. But even better is select the addon from a web page and have it installed (cough PaperUI and IoT Marketplace cough).
Having not programmed a binding myself yet I can’t comment too far, but frankly it appears that developing a new binding isn’t really all that difficult to start with. The hardest part seems to be to get the IDE and environment set up, for which there are lots of documentation and lots of people to help. If the biggest concern is the language restrictions, well Java isn’t that difficult to learn if you already know at least one other language.
Finally, there is nothing at all wrong with someone writing a service using a language they know and integrating it with OH over the REST API or MQTT to start. Once that is done the hard part has already been figured out. Then I’m certain they will be able to find someone to help port it to become a native binding.
This is just MHO. I don’t speak for the community.
Also, any changes necessary to support something like this will have to take place on the ESH project so starting the conversation over there is a must.
You’ve given me a lot to think about. I like the idea of of using the REST API; In effect it already has all the endpoints you need to interact with OH. Other than that yes MQTT is probably the defacto “middleware”, which I am actually current using with success to integrate with OH. Thanks again.
