This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Z-Stack 3.0.2终端无法入网问题

Other Parts Discussed in Thread: Z-STACK

Z-Stack 3.0.2,终端正常加入协调器后,工作正常,

需要升级终端估计是时候,直接把终端断电后刷新的固件,

此时终端再加入原来的协调器,发现加上了一会就被踢了,再加上又被踢了,无限循环,

之前有咨询,你们回复说把BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANGE关闭,但是关闭了测试还有会出现被踢的现象

请帮忙分析可能的原因以及解决办法?

#ifdef TP2_LEGACY_ZC
#define BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANGE                FALSE
#else
#define BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANGE                FALSE//默认TRUE
#endif

  • 需要升级终端估计是时候,直接把终端断电后刷新的固件, NV已经没有了 会被踢出。要是OTA可以正常。
  • 1.现在出现终端刷固件后一直被踢的现象后只能把协调器也执行bdb_resetLocalAction后终端才能加入?
    这样所有终端全部掉线了,需要全部执行bdb_resetLocalAction才能重新加入,很麻烦
    如果不用OTA升级,有没有什么解决方案?在协调器里把不在线的终端删除了是否可以?
    2.协调器和终端相互发私有的数据,双方发送都采用zcl_SendReportCmd函数
    请问接收方是在static zclGeneral_AppCallbacks_t zclSampleLight_CmdCallbacks 里处理数据?
    还是在下面函数里处理
    case ZCL_INCOMING_MSG:
    // Incoming ZCL Foundation command/response messages
    zclSampleLight_ProcessIncomingMsg( (zclIncomingMsg_t *)MSGpkt );
    break;
    我目前在case ZCL_INCOMING_MSG:里数据收到的数据,可以收到,请问在这里处理和在zclSampleLight_CmdCallbacks 里处理有啥区别?
  • 1. 重刷固件后NV已经被擦除,所以必須重新加入,如果只是重新上電,终端有使能NV_RESTORE的狀態應該要能加入原來網絡的
    2. zclSampleLight_CmdCallbacks 主要是處理一些標準的zcl command,私有的数据是在case ZCL_INCOMING_MSG:函数里处理
  • 重刷固件后NV已经被擦除,所以必須重新加入
    重新加入是肯定的,现在的问题是加入协调器后一会就被踢了,再加进入还是被踢,一直循环
    #define BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANGE FALSE//默认TRUE
  • 重新加入時协调器有使能permit join嗎?
  • 1.协调器和终端都使能了BDB_COMMISSIONING_MODE_NWK_STEERING,能加入,只是加入后大概十几秒就被踢了,现象和#define BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANGE TRUE时的现象类似,能加入,只是加入一会就被踢了
    2.用zcl_SendReportCmd发送私有数据的时候,我是在ZCL_CLUSTER_ID_GEN_ON_OFF cluster下定义了私有的attribute,这样是否可以?
    如果可以的话还需要初始化哪些?zclSampleXXX_InClusterList和zclSampleXXX_OutClusterList,zclSampleXXX_SimpleDesc,zclSampleXXX_ResetAttributesToDefaultValues,zclSampleXXX_Attrs这些都要初始化吗还是只要初始化其中的一部分?
  • 1. 有抓包檔可以附上來看看嗎?
    2. 可以在ZCL_CLUSTER_ID_GEN_ON_OFF cluster下定义了私有的attribute,基本上其他地方不需要初始化
  • 放私有数据的数组,是否要在zclSampleXXX_Attrs里面初始化一下?类似下面的?
    如果不做下面的初始化是有问题?
    // ***私有数据*** //
    {
    ZCL_CLUSTER_ID_GEN_ON_OFF,
    { // Attribute record
    ATTRID_ON_OFF_OFF_ELEC,//私有attribute
    ZCL_DATATYPE_CHAR_STR,
    ACCESS_CONTROL_READ | ACCESS_CONTROL_WRITE | ACCESS_REPORTABLE,
    (void *)zclSampleSw_SensorData//私有数据所在的数组
    }
    },
  • 在zclSampleXXX_Attrs里面需要加上那段初始化程序沒錯
  • 好的,因为协调器和终端是互发私有数据,是不是在协调器和终端上都需要做如下的初始化?
    我是基于ZCL_CLUSTER_ID_GEN_ON_OFF cluster定义的私有attribute
    请问是否要在InClusterList和OutClusterList里面都把ZCL_CLUSTER_ID_GEN_ON_OFF加进去?
    const cId_t zclSampleXXX_InClusterList[] =
    {
    ......
    ZCL_CLUSTER_ID_GEN_ON_OFF
    ......
    };
    const cId_t zclSampleXXX_OutClusterList[] =
    {
    ......
    ZCL_CLUSTER_ID_GEN_ON_OFF
    ......
    };
  • 协调器和终端是互发私有数据的話就都要加上去
  • 请教一个路由的问题:
    一个网络中有协调器,路由,终端,所有的命令都来自协调器,
    通过协调器直接或者间隔控制终端,测试时发现一个现象,终端和路由从来没有加入协调器,
    上电后终端直接加入路由了,此时通过协调器并不能控制终端?协调器上有允许加入的时间限制,
    默认是180秒,路由上是不是也有这样的限制?是先要把路由和终端都加入协调器,然后协调器才能通过路由去控制终端?
  • 基本上經不經過路由是Z-Stack依據Zigbee信號強度決定的,照理來說只要入網成功就能夠透過协调器去控制终端
  • 1.协调器是基于switch例程修改,终端是基于light例程修改,路由的话建议基于哪个例程修改比较好?
    2.终端和路由是不是都要先加入协调器,然后才能正常使用?
    3.路由有没有类似协调器的允许设备加入功能?如果一直允许,别人家的物联设备不是也加进来了吗?
  • 1. 這個沒有限制,都可以
    2.是
    3. 协调器的允许设备加入命令會廣播給路由,時間到了會自動關閉允许设备加入