Improvement #274

Adapt to modified ZNP API to ZStack 2.6

Added by Philipp Buluschek almost 4 years ago. Updated almost 4 years ago.

Status:In Progress Start date:11/11/2014
Priority:Normal Due date:
Assignee:Fabio Mavilia % Done:

0%

Category:zigbee.cc2480.datalink Spent time: -
Target version:org.aaloa.zb4osgi.zigbee.cc2480.datalink-1.X
Has a patch:No Has license agreement signed:No

Description

Since ZStack 2.6 (ZStack Home 1.2), the format of the ZDO_MGMT_PERMIT_JOIN_REQ has changed. The code needs to be updated if that stack is to be used to send the new "AddressMode" byte.

History

#1 Updated by Han Alink almost 4 years ago

FYI: End devices and Routers that use the Home 1.2 stack work fine with a 2.5.1a Coordinator.

#2 Updated by Stefano Lenzi almost 4 years ago

  • Tracker changed from Task to Improvement
  • Subject changed from Adapt to modified ZNP API to Adapt to modified ZNP API to ZStack 2.6
  • Category set to zigbee.cc2480.datalink
  • Status changed from New to In Progress
  • Assignee set to Fabio Mavilia
  • Priority changed from Low to Normal
  • Target version set to org.aaloa.zb4osgi.zigbee.cc2480.datalink-1.X
  • Has a patch set to No
  • Has license agreement signed set to No

@Fabio: Have you had a chance to install ZStack 2.6 on Open2530 or CC2531EMK platform ?

#3 Updated by Stefano Lenzi almost 4 years ago

Han Alink wrote:

FYI: End devices and Routers that use the Home 1.2 stack work fine with a 2.5.1a Coordinator.

@Han and @Philipp
If I understood correctly the issues is only with the zigbee.CC2530.driver when is trying to use a dongle with a firmware built on top of ZStack 2.6, am I right?

@All
  1. How to identifies the ZStack running on the dongle?
  2. How to provide different implementation of the ZStack, any idea? Should we deploy several version of the zigbee.cc2480.datalink bundle and rely on Import-Package feature of OSGi, which implies that we have to branch zigbee.cc2480.datalink on the SVN, any thoughts?

#4 Updated by Philipp Buluschek almost 4 years ago

Yes, the issues is only with ZStack 2.6 firmware on the dongle.

The ZStack version can be requested with a SYS_VERSION request - it has only the major and minor version numbers (ie lacks the micro), but this should be enough.

The actual message constructor should, if possible, not be affected, as the calling code should not need to know the underlying hardware/firmware to do ZigBee calls.

So, in my opinion, the main problem is how to get this version information to the message constructor without breaking separation. I currently use system properties (which is basically a fat global data structure), but am open to other ideas.

Also, I can provide my solution if you want...

#5 Updated by Philipp Buluschek almost 4 years ago

To add a bit of fun, TI's documentation is wrong...
see http://e2e.ti.com/support/wireless_connectivity/f/158/t/333948.aspx

-> use 0x0F as addressMode when broadcasting...

Also available in: Atom PDF