Conclusions and future work

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)

Conclusions and future work 

With this note we conclude our short series of posts describing our experiences evaluating feasibility of a binding to integrate JEMMA and OpenHAB.

It's very hard to not appreciate the flexibility and the open approach of the OpenHAB framework. The way actual devices/services can be abstracted makes it possible to have a unified representation of objects despite the high degree of possible heterogeneous configurations that we experience in devices across technologies.  Overall, this experience was quite interesting, and proved that developing a fully-fledged JEMMA openHAB binding is indeed possible.

Here some ideas that it would be definitely interested in exploring:

• Extend and test the binding to cover the full set of Energy@home devices, going beyond simple Smart plugs;
• Align the DAL definitions currently used in JEMMA to the correct classes adopted by the OSGi alliance;
• Update JEMMA dependencies to the same versions used in OpenHAB to prevent version conflicts that may (will) occur when trying to import the full JEMMA set of bundles in the same OSGi runtime as OpenHAB.
• Realize demonstrators to understand how OpenHAB GUIs and features (e.g. rule engine, etc) can play a part in Energy@home use cases.

Energy@home will definitely continue to look with interest at OpenHAB and its developments. If you are interested in turning the results of this small feasibility study them in full-fledged binding get in contact with the JEMMA community on the public mailing list.

If you are interested in discussing this in person with some Energy@home and OpenHAB contributors just drop us an e-mail on the JEMMA mailing list.

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.

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.