[zb4osgi Dev] Towards a roadmap

Han Alink h.alink1 at chello.nl
Thu May 31 11:54:36 CEST 2012

Hello Christophe,
I'm not sure!
Maybe Ztool offers the possibility.
I did set both at compile time.

Verzonden vanaf Samsung Mobile

-------- Original message --------
Subject: Re: [zb4osgi Dev] Towards a roadmap 
From: christophe.demottie at orange.com 
To: dev at zb4osgi.aaloa.org 


I have just some simple questions:

to use network security, the "secure" compilation flag has to be set when building CC2531 image.
So, the firmware is tagged secure or unsecure ? We can't change it when we start our application with this dongle ?

The same question for the TC Link key, if we can change it. But not really important.


Le 30/05/2012 22:36, Han Alink a écrit :
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.
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.

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.

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,

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
Arnaud Rinquin
tél. 04 76 76 45 59
arnaud.rinquin 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

Dev mailing list
Dev at zb4osgi.aaloa.org

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

More information about the Dev mailing list