[zb4osgi Dev] Towards a roadmap

Han Alink h_alink at hotmail.com
Wed May 30 22:36:45 CEST 2012


Hi,

 

Some points related to using the NetVox devices (as far as I understand
them):

 

I have 3 types of devices, supplied by SimpleHomeNet USA.

The devices make use of network security. This means that the “secure”
compilation flag has to be set when building the CC2531USB image. I’m using
the 2.5 stack and used the TI instructions and the Zigbee4Osgi CC2531
compilation document to build the image.

In addition, the devices also use the TC_Link key. This key is defined in
the latest Zigbee Home Automation specification. To make use of this key I
found out that the compilation flag SE 
. (don’t know the exact name) had to
be set. The key is used for transportation of the first network key.

 

Using the CC2531USB dongle, a network is formed using channel B. I’m
wondering why you have a problem with the channel setting? 

I can use the Zigbee4Osgi Tester software to read all kind of attributes,
set attributes issue cluster specific commands etc. 

The end devices (on battery power) go to sleep for periods of 5 seconds. 1.5
minutes after power up they go to sleep forever. The switch is only awaking
when a switch is pressed, the temperature sensor wakes up dependant on the
setting of the reporting parameters.

 

Francesco, if your NetVox devices don’t use security, make sure the “secure”
flag  is set to 0. The default setting in 2.5..  is 1 I think. 

 

Please let me know if you think I’m interpreting things wrong.

Regards,

Han Alink

 

Van: dev-bounces at zb4osgi.aaloa.org [mailto:dev-bounces at zb4osgi.aaloa.org]
Namens Francesco Furfari
Verzonden: woensdag 30 mei 2012 16:24
Aan: ZigBee for OSGi help and dev
Onderwerp: Re: [zb4osgi Dev] Towards a roadmap

 

Hello Arnaud, all

thank you for voting !! this is exactly what  we need, identify the
requirements of this community.

Let me first remember that this is the first time we are involved in a
project with both Hardware and Software challenges and issues.
There are a lot things we can improve at software level, but we first need a
stable hardware, that's why  I sent an email to identify reference hardware
platform and sensors we can use to ease the development.

We developed he core feature with another dongle the CC2480 ( it was bugged
but with freezed firmware) 
So we moved only recently to CC2530. Let me summarise the status of this new
driver.

-Interoperability: 
We received netvox devices 10 days ago. They were blocked at the custom
because without CE label. Furthermore they use battery the shipment service
didn't accept to transport ( even if removed from the device) So we are
waiting for them with a different order. We cannot still use all the
devices.
Our set of devices is free to select any radio channel, so they don't start
on channel 22 :-( nd this is the first problem we are facing and want to
solve.

-Security
We have ordered also a trust and IAS center  ... so we likely will able to
test all the features you were asking about. 

-Open/close the network:
I guess you refer to the permit join command.  We have intention to
implement it too. Note that it shouldn't have impact on the joining of
existing networks
In this moment I guess our problems are more related to the Smart Energy
flag that helped HAn to solve problems more than the permit join.

-radio channel:
The firmware was compiled by using the TI SDK 2.3.1  by TSB people.  It
works on their hardware.  We raised an issue on this they started to analyse
the problem.
We shared time ago the instructions for compiling the firmware  and Han
Alink, our first user, used it to compile the firmware (2.5.1 version).and
flash his dongle.
After using the Smart Energy Flag he was able to see netvox devices and
change the channel (you can get it from the log sent by Han). One of them
was buggy, he updated the netvox's device firmware and now all of them are
recognised.
I asked Han to send us his firmware, but he is on vacation. At CNR we have
your same problem. We recompiled the firmware with 2.5.1 but it doesn't work
:-(
I cannot say why so far. I suspect we are all using different hardware.

- Tutorial: errors with the tutorial to be assessed

Yes, this is a new track issue we want to address when everything is
highlighted.

and ok with point C and D,
Zaragoza team is using another vendor if I remember well.
------------

Let me add more on the dongle driver.
We are not interested in a specific dongle, we are interested in using  the
most accessible code in case we need to implement "special features" for
monitoring and  sniffing the network. We found TI was a viable solution and
TSB have a good know-how on it.  Zaragoza people used Ember, and I guess
there are a lot of dongle vendors out there. So if you have a proposal for a
different dongle and team who may support our development with an OSS
approach,  it is welcome.

stay tuned,
Francesco

ps:
I hope I summarised enough well the status of CC2530 driver, please correct
me if I forgot something.




On 29/05/2012 16.58, arnaud.rinquin at orange.com wrote: 

Hi Francesco, all,
 
 
 
This email is a tentative to answer the "Vote for your preferred features"
proposed on the web site.
 
 
 
Based on Christophe's tests of ZB4OSGi OSGi ZigBee Base Driver with TI
CC2530 and Manlio's answers, we (Christophe, 3 other persons and I in the
Orange Labs) are making this list of major issues:
 
- Interoperability: This driver has only been tested with CC2530EM modules.
Interoperability with Netvox devices (some are based on TI modules, some are
on Ember, there may be others) is not tested.
 
- Security: ZigBee security is not managed. The network is not secured.
(Hence most of Netvox devices are not usable).
 
- open/close the network: these network management features are not managed.
The ZB network is always open.
 
- Radio channel management: the only radio channel possible today is 22
(why??)
 
 
 
Other (slightly less important) issues to be validated:
 
- Tutorial: errors with the tutorial to be assessed
 
 
 
Interoperability, Security and Network management issues are of top priority
for our project. Don't you have the same issues? Unless those first issues
are solved, what could be efficiently demonstrated and appreciated by your
audience?
 
 
 
 
 
With less priority, here are the next features that are important:
 
*C) Run ZB4OSGi on a  (Linux ) embedded system * => What could be easy for
you and appreciated by all the "embedded" OSGi community is running the
software on a Sheeva Plug (vendors: ionics, ...). The sheeva plug is well
spread by the community.
 
*D) Improve tools  for network browsing and commissioning* => Tooling is
very important to make efficient projects.
 
 
 
 
 
Some comments on other propositions:
 
*A) Ember Integrations*: Ember is a reference and the interoperability with
a new dongle would be nice. It would demonstrate that your ZigBee Simple
Driver API is well written. However, Texas Instruments may be sufficient if
ZigBee4OSGi community manpower remains low.
 
*B) Increase the available profiles:*: As soon as the base driver is working
with commercial sensors and actuators, many OSGi developers will implement
clusters. We are planning to release a device generator.
 
*E) Integrate Zigbee Device Gateway (ZDG) Specification*: ZigBee Gateway
Device is not well spread so we would like to focus on the use of a simple
ZigBee chip (in a dongle or built-in).
 
 
 
Kind regards,
 
--
 
André, Christophe, Arnaud
 
[http://www.orange.com/sirius/logos_mail/orange_logo.gif]
<http://www.orange.com/> <http://www.orange.com/>
Arnaud Rinquin
FT/OLNC/RD/TECH/MATIS/COSY
tél. 04 76 76 45 59
arnaud.rinquin at orange.com <mailto:william.barrachina at orange.com>
<mailto:william.barrachina at orange.com>
 
 
____________________________________________________________________________
_____________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete
altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages
that have been modified, changed or falsified.
Thank you.
 
 

 

_______________________________________________
Dev mailing list
Dev at zb4osgi.aaloa.org
http://zb4osgi.aaloa.org/mailman/listinfo/dev

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zb4osgi.aaloa.org/pipermail/dev/attachments/20120530/9b3c105b/attachment-0001.html>


More information about the Dev mailing list