[zb4osgi Dev] Towards a roadmap

Francesco Furfari francesco.furfari at isti.cnr.it
Thu Feb 2 13:52:12 CET 2012


Dear All,

here some action points. It is not a roadmap because we didn't 
define neither priorities or deadlines. In fact, there are several 
options, mainly  linked to the European projects in which we are 
involved, that are not mature yet. However, consider that for the end of 
the year we want to create some pilot tests in which we use and test our 
software and different action points should be accomplished for that time.

*A) Ember Integrations*
we want to extend the number of dongles recognised by ZB4OSGi. We will 
work to the integration of the software developed by the HowLab team. We 
analysed that there are two ways to proceed. The simpler one is to have 
two different implementations of the stack that share only the  ZCL API, 
and the longer way is to re-factor the Zigbee.basedriver API in order to 
move the serialization functions used by the ZCL to the lower  layers.
In few months it should be possible to access to the Ember-based code 
and likely by the summer to have  a first integrated version.
I guess we will live  with  two parallel versions of the software for a 
while.

*B) Increase the available profiles:*
/Smart Energy, Health Care, Remote Control/, ???
    These are some of the profiles we would like to implement,  (they 
are not listed with any priority).
     Do you have any preference? please let us know your opinion
    An important point here is that we would like identify and select, 
with the help of this community, some reference devices possibly to be 
used for testing and debugging by the  majority of us. The abstraction 
of the device API should be "harmonised" with the ongoing work at OSGi 
Residential Expert Group.
*
**C) Run ZB4OSGi on a  (Linux ) embedded system *
   We would like run ZB4OSGi on a real gateway, not just PC.
   At the moment we didn't select any hardware gateway, we are 
investigating:
   1) Intel M2M gateway (Fish River Island)
http://us.kontron.com/simplify-and-speed-your-entry-into-the-m2m-marketplace/
http://m2m.telekom.com/developers/intel
   2) IBM shaspa
http://www.shaspa.com/portfolio/shaspa-bridge/technical-specifications/
  3) Other Open Hardware solutions
             ( any advise from Howlab people?)
*
**D) Improve tools  for network browsing and commissioning*
        Configure the ZigBee networks is still tedious and tricky, after 
the network browsing we would like  to add facilities for the network 
commissioning

*E) Integrate Zigbee Device Gateway (ZDG) Specification*
      This is another relevant task that impacts with the current 
architecture. We can integrate this specification in two ways.
      1) implementing  a ZDG by using the ZB4OSGi software, 2) using a 
remote ZGD as a service in addition to the low level drivers that 
control the different ZigBee USB dongles.
*
**F) Extend ZB4OSGi API with declarative approach.*
  The idea is to provide a simpler declarative way to create new 
customised devices by declaring the clusters used by the new device.
   In this way developers can focus only on the new functionalities 
added by the specific device.

*G) Miscellaneous *
     package a new release containing the new CC2531 driver and the RXTX 
64bit library
     consolidate the documentation and the Wiki pages
     update or remove some 3-party libraries we currently use
     move to Karaf container
     manage more dongles at the same time
     synchronize the Redmine roadmap with our future decisions

That's all,
please, let us know your opinion, your ideas
and remember that  any contribution is welcome.

Francesco


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zb4osgi.aaloa.org/pipermail/dev/attachments/20120202/47cbbea1/attachment.html>


More information about the Dev mailing list