Dear Kai,
this is a very good news.
We will be happy to contribute to the requirements,
as well as to work on the reference implementation when the
specification will be ready.
Concerning Z-Wave I tried time ago to get their specification but it
wasn't open.
Is there anybody in AALOA who have experience with such technology ?
Kind regards,
Francesco
Il 22/12/2010 11.07, Kai Hackbarth ha scritto:
Dear Francesco, all,
some of you may know that the OSGi Residential Expert Group started to
work on new requirements for REG specification release 5. We are also
planning to define standardized APIs for ZigBee and Z-Wave. The
general idea that Francesco introduced is inline with what are
planning to do at REG. We will start working on requirements documents
next year and you kindly invited to participate in this activities. I
keep you informed.
Regards,
Kai
Am 21.12.2010 um 20:00 schrieb Francesco Furfari:
Dear Bruno, all,
this mail answers to your comments from two different perspective:
1) *technological aspects*
I'm very happy you have experience with two different ZB development
kits. It will be very useful, we can discus about this off-line or
through the proper mailing lists of the project .
I don't agree with your recommendation. Let me explain better the
goal of our project.
I would like to achieve a separation of concerns as far as ontology
definition is concerned.
I attached a picture representing the three-layered model we had in
PERSONA.
I think you can easily read the picture representing SAIL (Sensor
Abstraction and Integration Layer) sub-project of PERSONA.
It was implemented on OSGi, and only the top most layer concerns
with the *integration *of a specific technology.
As example, there are two components depicted in the picture, one is
the the bundle that maps ZB to the UPnP Specification, the second
exports the interfaces according to PERSONA architecture, that' s by
using the PERSONA ontology.
Our project wont deal with the *Integration Layer*, but only with the
first two layer: Access and Abstraction Layer.
IMO there are at least two good reasons for such approach.
a)There are many ontology definitions out there, not only OSGi4AMI,
but PERSONA, OASIS and standards like ISO11073 ...
So we need to create consensus, and the ZB4OSGI project is not the
right place to do it.
b) We want to be free to provide a very good solution for ZigBee,
independently from the strategic objectives of AALOA.
In such way we can assure that other communities will test our
software and will contribute to the bug fixing.
AALOA in other projects will be able to reuse the ZB4OSGi results
according to a shared plan.
2)* Organisational aspects*
The federation of projects is an important aspect we introduced in
the AALOA Manifesto: the glue thanks to which this community is growing.
I quoted here the "Call for Project Proposal" of the Manifesto:
"The association will be organised as a federation of
projects, one representative of each project being a
member of the Governing Board.
Proposals for new projects can be submitted to the
Governing Board, whose main role will be their
evaluation with respect to the association’s mission,
*while still encouraging the emergence of diversity, and
avoiding monoculture*. *Projects will autonomously
organize their governance rules*. Over time common
rules suggested by practice may be formally adopted... "
It is to point out that we should mainly vote regarding the
usefulness of the project, but we cannot bind the vote to the
realization of specific goals of AALOA.
In theory committers of open source projects are volunteers.
The project leader can report the advises he receive during the board
meeting, but usually he has not the power to impose "external" decisions.
They must be discussed and accepted by the community working in the
project according to their internal organization.
The coordination and the mutual commitments we can reach in AALOA is
another matter.
We can create ad hoc projects for shared objectives after discussing
among interested members .
I see your request/recommendation in this way. For example, we can
start to discuss about AAL ontologies in a specific project promoted
by EU projects like OASIS, UniversAAL, MonAMI and incubated by
AALOA... Alternatively also single organizations (e.g the CNR and
Trialog) could decide to dedicate resources to a specific project of
mutual interest.
However the AALOA converging process to a common platform has not to
influence the project proposals submitted to AALOA.
The first level of aggregation in AALOA is to allow visibility of all
the AAL-related software.
In this way EU projects/ organizations /individuals may be interested
to enter in AALOA.
The sharing of common objectives and planning is a second step.
I think it is the real challenge we have as community.
We need to be able to take commitments as a single entity, but also
to be free to propose independent solutions.
Working both as an Industrial Alliance that addresses specific
targets, and as an Open Source Community that encourages the diversity.
We are a community of communities, the challenge is to find the right
alchemy to work all together in harmony (it sounds good at Christmas
;-) )
Said that, I took your message as excuse to talk about these issues.
I will happy (and curious) to discuss with you about the MonAMI
interfaces ;-)
BRs,
Francesco
Il 21/12/2010 9.48, Bruno Jean-Bart ha scritto:
Dear Francesco and all,
My vote will be provided in a separate email but I include here
remarks on the Zigbee driver project.
As already mentionned by Antonio (Trialog) and Roberto (Uni.
Zaragoza), we have developed in MonAMI two drivers for Zigbee
Wireless Sensors network, one by Unv Zaragoza, one by Trialog. The
two approaches use different Zigbee implementation (Ember for Uzaz)
and (TI for TRIALOG). The objectives of these two approaches were
twofold :
1. to proof that the OSGi4AMI interfaces (Application Interfaces
representing sensors and actuators independantly from the type of
the network) can be implemented easily by two different teams.
2. to validate that the OSGi4AMI interfaces are comprehensively
defined to enable the interoperability of applications.
The objective 1 was demonstrated.
The objective 2 shows in some cases that the key issues is there :
an application interface such as OSGI4AMI is a must for
interoperability of applications but this is not sufficient: for
interoperability, the behaviour of devices themselves are generally
not totally identical and therefore the driver shall take into
account these differences.
In your project, I see some proposals to take into the above issues
: The use of the Zigbee Cluster Library will help for
interoperability at the level of Application Interfaces. However for
AALOA, one of the primary objectives is the definition of the
Application interfaces of the drivers. This interface cannot be the
Zigbee-based on the ZCL, but something more generic and I do not see
that approach in your document.
Therefore I would recommend the AALOA board to vote for the Zigbee
Project but a first task of this project would be to define the
Device API. In that goal, I recommend to use as input the OSGi4AMI
proposal (note that this name is misleading : the OSGI4AMI
interfaces are not depending on OSGi, nor Java. This is mainly an
ontology of devices, then mapped into Java interfaces).
Bruno
_________________________________________________________________________
Bruno Jean-Bart
Connectivity Products& Services
TRIALOG, 25 rue du General Foy, F-75008 Paris - France
http://www.trialog.com
Tel Direct : (33 1) 44 70 61 08, Fax :(33 1) 44 70 05 91
_________________________________________________________________________
Le 16/12/2010 15:07, Francesco Furfari a écrit :
Dear Supporters,
today I submitted a first project proposal to the Governing Board
of AALOA.
Even if the project was already announced, it was a needed action
in order to define the process for submitting a project proposal.
The governig board will decide whether the project proposal is
alligned to the AALOA mission and consequently will allocate the
requested resources.
In particular this proposal is one of the outcomes of the PERSONA
project (http://www.aal-persona.org/) that finished with excellent
evaluation few days ago.
As described in the Manifesto the leader proposing the project will
be part of the AALOA Governing Board.
We don't have a formal proposal template so far.
I thought to the following sections:
1. Motivation for incubating the project
2. Description of the codebase or the input material for the project
3. Simple roadmap and invitation to contribute ( how the AALOA
community could help)
4. People involved (e.g. the list of initial committers in case of
software projects)
5. An optional expression of interest on the project incubation. (
list of people internal or external to AALOA )
I invite all of you to read the proposal for the ZigBee 4 OSGi
project,
help to advertise the project (when accepted) and help to
contribute to the further development and testing.
Please, if you have any doubt about project proposal submission,
don't hesitate to post your questions,
they will help to create a FAQ on the topic.
Kind regards,
Francesco
_______________________________________________
Supporters mailing list
Supporters@aaloa.org
http://aaloa.org/mailman/listinfo/supporters
<ZigBee.JPG>_______________________________________________
Supporters mailing list
Supporters@aaloa.org <mailto:Supporters@aaloa.org>
http://aaloa.org/mailman/listinfo/supporters
-------------------------------------------------------------------------------------------------
Kai Hackbarth · Evangelist & Chair OSGi Residential Expert Group
ProSyst Software GmbH
D-50858 Cologne, Germany . Dürener Strasse 405
Tel. +49 (0)221 6604 410 · Fax +49 (0)221 6604 660
Mobile +49 (0)163 6604 410 · US Mobile +1-317-6039-264
http://www.prosyst.com · k.hackba...@prosyst.com
<mailto:k.hackba...@prosyst.com>
-------------------------------------------------------------------------------------------------
stay in touch with your product.
-------------------------------------------------------------------------------------------------
_______________________________________________
Supporters mailing list
Supporters@aaloa.org
http://aaloa.org/mailman/listinfo/supporters
