The JEMMA - OpenHAB local binding

This is the first of a series of post explaining the experience of the JEMMA and Energy@home community with the OpenHAB framework. Find below links to all posts of the series:

1. JEMMA and OpenHAB: a nice match (publication date: 18/4/2016)
2. OpenHAB in theory: a short overview (publication date: 22/4/2016)
3. OpenHAB in action: a quick example (publication date: 26/4/2016)
4. The JEMMA - OpenHAB remote binding (publication date: 29/4/2016)
5. The JEMMA - OpenHAB local binding (publication date: 3/5/2016)
6. Conclusions and future work (publication date: 9/5/2016)

The JEMMA - OpenHAB local binding

This post cover the second case anticipated in our previous post.

Some theory first. Since version 0.9, JEMMA register devices according to a standard fashion specified in  namely the Device Abstraction Layer (formerly RFC-196, in the OSGi core 6 residential specifications).

The OSGi architecture is service-oriented, so this is the most natural way to proceed also for devices. If any local application is exposing devices, as a natural choice it should register in the OSGi framework a set of Device and Function services, which can be "read" via OSGI standard mechanisms (e.g. the Service Tracker).

The purpose of the ismb/jemma-local-binding is just to read these descriptions by using the standard OSGi service tracker and to register OpenHAB things accordingly. In order to run-it, just run the instructions for the jemma-remote-binding component.

This can be quickly tested e.g. by installing in your local OSGi runtime also all the fake devices project that we normally use for testing JEMMA features without connecting actual hardware.

Despite a few known limitations (mostly due to the demonstrative/PoC nature of this development), this is probably the best way to go for any future activities targeted at providing full interoperability between JEMMA and OpenHAB. The main advantage, is that, being a standard OSGi specification, the binding will be likely usable also to provide interoperability to devices implementing other technologies (e.g. z-Wave, enOcean, ...).

Important Note: both developments are provided as proof-of-concept to evaluate the feasibility of the proposed approaches. They are not meant as "professional" bindings - as much more work would be needed to use them reliably an in all cases. If you are interested in turning them in full-fledged binding - get in contact with the JEMMA community on the public mailing list.

The code of the developed solution is available in the ismb/jemma-local-binding repository.

Authors

This series of posts has been prepared by Sandro Tassone, supported by Riccardo Tomasi(ISMB). Sandro holds a MSc in Computer Engineering from Politecnico di Torino. He is currently collaborating with ISMB and Energy@home on JEMMA and other OSGi-based projects. He is a Software and C++ enthusiast.&; This activity has been partially co-funded by Energy@home. Thanks to IOOOTA for providing initial ideas and support for the jemma remote binding component.