ZIGBEE3.0 beacon request问题

有木有大神回一下呀？难道我的问题太简单了？

3.0协议栈，入网的启动时由BDB来控制的，你可以看下关于按键的处理。

请问入网的问题解决了吗

zigbee 3.0的入网似乎是有些问题的，同样的设备和固件，多刷几次，不是每次都能成功组网，两边用的都是bdb提供的API

你是怎么写设备入网的呢

1、

bdb_RegisterCommissioningStatusCB注册回调函数，在函数里面处理BDB_COMMISSIONING_SUCCESS消息；

收到消息后：调用bdb_StartCommissioning(BDB_COMMISSIONING_MODE_NWK_STEERING | bdbCommissioningModeMsg->bdbRemainingCommissioningModes);

2、

程序初始化完毕，直接调用如下实现组网，同时会调用 NLME_PermitJoiningRequest(0xFF)，两边设备流程是一样的：

bdb_StartCommissioning(BDB_COMMISSIONING_MODE_NWK_FORMATION | BDB_COMMISSIONING_MODE_NWK_STEERING | BDB_COMMISSIONING_MODE_FINDING_BINDING | BDB_COMMISSIONING_MODE_INITIATOR_TL);

为什么你的bdb_StartCommissioning要把所有的commissioning mode或者 state都往里面填写了呢

Z-Stack给的所有参考设计里面都是如此给的，不过一定要注册回调函数bdb_RegisterCommissioningStatusCB( zclSampleLight_ProcessCommissioningStatus ); ，不然只有beacon request，没有Device announce的

static void zclSampleLight_ProcessCommissioningStatus(bdbCommissioningModeMsg_t *bdbCommissioningModeMsg)
{
  switch(bdbCommissioningModeMsg->bdbCommissioningMode)
  {
    case BDB_COMMISSIONING_FORMATION:
      if(bdbCommissioningModeMsg->bdbCommissioningStatus == BDB_COMMISSIONING_SUCCESS)
      {
        //After formation, perform nwk steering again plus the remaining commissioning modes that has not been process yet
        bdb_StartCommissioning(BDB_COMMISSIONING_MODE_NWK_STEERING | bdbCommissioningModeMsg->bdbRemainingCommissioningModes);
      }
      else
      {
        //Want to try other channels?
        //try with bdb_setChannelAttribute
      }
    break;
    case BDB_COMMISSIONING_NWK_STEERING:
      if(bdbCommissioningModeMsg->bdbCommissioningStatus == BDB_COMMISSIONING_SUCCESS)
      {
        //YOUR JOB:
        //We are on the nwk, what now?
      }
      else
      {
        //See the possible errors for nwk steering procedure
        //No suitable networks found
        //Want to try other channels?
        //try with bdb_setChannelAttribute
      }
    break;
    case BDB_COMMISSIONING_FINDING_BINDING:
      if(bdbCommissioningModeMsg->bdbCommissioningStatus == BDB_COMMISSIONING_SUCCESS)
      {
        //YOUR JOB:
      }
      else
      {
        //YOUR JOB:
        //retry?, wait for user interaction?
      }
    break;
    case BDB_COMMISSIONING_INITIALIZATION:
      //Initialization notification can only be successful. Failure on initialization 
      //only happens for ZED and is notified as BDB_COMMISSIONING_PARENT_LOST notification
      
      //YOUR JOB:
      //We are on a network, what now?
      
    break;
#if ZG_BUILD_ENDDEVICE_TYPE    
    case BDB_COMMISSIONING_PARENT_LOST:
      if(bdbCommissioningModeMsg->bdbCommissioningStatus == BDB_COMMISSIONING_NETWORK_RESTORED)
      {
        //We did recover from losing parent
      }
      else
      {
        //Parent not found, attempt to rejoin again after a fixed delay
        osal_start_timerEx(zclSampleLight_TaskID, SAMPLEAPP_END_DEVICE_REJOIN_EVT, SAMPLEAPP_END_DEVICE_REJOIN_DELAY);
      }
    break;
#endif 
  }
  
  UI_UpdateComissioningStatus(bdbCommissioningModeMsg);
}

请问  bdb 是不是 取代了之前 的ZDApp 的code？

应该是这样的，不过不是很清楚，Z-Stack 3.0提供的bdb接口，实现了早期协议栈的诸如建立网络，加入网络等等操作，@VV 是不是这样

你好， 你的问题解决了吗？ CC2530  Z-Stack 3.0.0， 我的问题是终端不能入网。

协调器组网成功了：

bdb_StartCommissioning(BDB_COMMISSIONING_MODE_NWK_FORMATION);
NLME_PermitJoiningRequest(0xFF);

终端不能入网：

bdb_StartCommissioning(BDB_COMMISSIONING_MODE_NWK_STEERING);
NLME_PermitJoiningRequest(0xFF);

请教一下是什么原因？  在ZDO_STATE_CHANGE中， 最后的状态是 DEV_HOLD。

请问您的问题解决了吗？我也遇到了同样的问题 

NLME_PermitJoiningRequest

這個API文件裡寫的是只給協調器和路由器使用的FUNCTION

好像不是給終端用的.

This function defines how the next higher layer of a coordinator or router device may permit devices to join its
network for a fixed period.

hold li 说：

zigbee 3.0的入网似乎是有些问题的，同样的设备和固件，多刷几次，不是每次都能�功组网，两边用的都是bdb提供的API

好像是, 目前實驗到一開機時協調器和終端(先沒有用路由器)

在調用了    giGenAppScreenMode = GENERIC_MAINMODE;
    bdb_StartCommissioning(BDB_COMMISSIONING_MODE_NWK_FORMATION | BDB_COMMISSIONING_MODE_NWK_STEERING | BDB_COMMISSIONING_MODE_FINDING_BINDING | BDB_COMMISSIONING_MODE_INITIATOR_TL);

以後協調器和終端才能順利的進入協調器模式和終端模式

不然一開機都在DEV_IDLE狀態.

然後終端用以下入網

bindAddEntry(GENERICAPP_ENDPOINT,               //添加綁定表
                     &desAddr,
                     GENERICAPP_ENDPOINT,
                     TestRoutine_MAX_CLUSTERS,         
                     (cId_t *)TestRoutine_ClusterList)

ZDP_DeviceAnnce( NLME_GetShortAddr(), NLME_GetExtAddr(),
                                                       ZDO_Config_Node_Descriptor.CapabilityFlags, 0 );      

但添加綁定表好像會FAIL

然後如果順利BIND的話, 確實可以看到協調器的名單中出現終端的短位址, 但也不是每次都成功

現在卡在終端要傳訊給協調器, 終端的AF_DataRequest執行後有回afStatus_SUCCESS,

但協調器端沒有觸發事件: AF_INCOMING_MSG_CMD 或 AF_DATA_CONFIRM_CMD.

我没有用到过绑定，不知道绑定是干什么用的，谁能给个解释？

你先用ubiqua抓包看一下有没有发出数据，有的话就是接收问题，这样好确定查找方向，多半是没发出来。

應該有,有在SNIFFER看到朝0000發消息.

綁定好像是從以前的STACK抄來的, 以為終端都要加綁定表.

有發的話應該會觸發協調器的AF_INCOMING_MSG_CMD事件吧?

這是我現在最疑惑的痛點

既然協調器的AssociatedDevList都有終端的編號出現了.

那兩者應該己經通了.packet SNIFFER也可以看到從終端的編號丟到0X0000的封包

只是沒想到終端無法觸發協調器的AF_INCOMING_MSG_CMD事件.

還是可以從那裡再觀察到協調器有收到終端發來的訊息??

謝謝.
用的是ZSTACK 3.0.1配CC2538

这里面有多重因素，一个错了都导致数据发不过去，或者发过去那边收不到，你的很可能是数据没发出来。

确认如下几步：

自己的endPoint必须先注册，接收者的endPoint那边也必须注册；目标短地址必须对，这边需要发过去的clusterID和cmd，那边必须得处理