[参考译文] CC2650EMK：NLME_NetworkDiscoveryRequest 规格

您可以参考文件夹 C：\Texas Instruments\Z-Stack Home 1.2.2a.44539\Documents\API 下 Z-Stack API.pdf 中的第3.4.1.1节 NLME_NetworkDiscoveryRequest ()。

感谢您的答复。

我找不到 Z-Stack API.pdf。
您能否附上它？

此致、

您可以参阅 Z-Stack API.pdf

您好！  
我还有一个问题。
此函数的源代码是否公开可用？

此致、
村田裕也

尊敬的 Yuya：

NLME 层和函数是 Z-Stack 源代码的一部分、并未公开提供。

此致、
瑞安

感谢您的答复。

余亚市

您好！

我找到了以下文章。
https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/390470/in-what-condition-function-nlme_networkdiscoveryrequest-will-return-znwkinvalidrequest

请注意、在已连接函数的情况下调用函数时会出现错误代码0xC2。
您知道为您提供该错误代码的其他条件是什么吗？

此致、
余亚市

ZNwkInvalidRequest 应该足够清晰、当提供的参数与命令的预期不匹配时将返回。  您能否提供一个示例、说明与包含的参数一起使用的命令会返回此错误？  此处还有 更多 E2E 主题 供您参考。

此致、
瑞安

感谢您的答复。

出现其它错误代码的情况是什么？

此致、
村田裕也

例如、  如果本地设备已经是网络的一部分、则 NLME_NetworkDiscoveryRequest 会返回 ZNWkInvalidRequest。

ZStatus_t NLME_NetworkDiscoveryRequest( uint32 ScanChannels, uint8 ScanDuration )
{
  ZMacScanReq_t scanReq;

  // If device is already on a network, use ZDO_MGMT_NWK_Discovery.
  // Or else, leave the network first, then initiate the scan
  if ( ( _NIB.nwkState == NWK_ENDDEVICE ) || ( _NIB.nwkState == NWK_ROUTER ) )
    return (ZNwkInvalidRequest);

此致、
瑞安

您好！

当 ZED 不发送 Orphan 通知和信标请求时、我的 ZNwkInvalidRequest 会发生。
请查看已连接的日志文件。

e2e.ti.com/.../6305.log.zip

savedState 为 ZStack 状态(App 使用 zclport_getDeviceInfo()获取 ZStack 状态)
信标请求 RET 为 NLME_NetworkDiscoveryRequest 返回值。

是否需要重新启动 ZED 才能解决此问题？

此致、
村田裕也

感谢您提供监听器日志。  即使在成功重新加入和设备通知后 ZC 也不会响应任何 ZED 数据请求(尽管有许多多余的数据包)。  然后 ZED 在30秒后无声,从未显示更多的活动。  设备重置或其他情况下、您需要修复这些 Zigbee 节点之间的通信。

此致、
瑞安

您好！  

在 ZComdef.h 中定义的错误代码中、NLME_NetworkDiscoveryRequest 输出什么内容？
是否可能输出所有错误代码？

此致、
村田裕也

您好！  
感谢你的评分

请告诉我们以下关于 ZNwkInvalidRequest 错误的两件事。

1.变为_NIB.nwkState = NWK_ENDDEVICE 的源代码是什么？
  我找不到。
2.什么是回调函数的断开?
  例如、当由于无线电功率弱而没有来自 ZC 的响应时调用的函数。

此致、
村田裕也

您好！

您所描述的是如何在应用程序中了解断开(SampleSwitch 代码)？
我想知道的是、在 z-stack 检测到断开连接时的回调函数、而不是应用。
我假设在 z-stack 检测到断开连接时调用了一个函数、例如、将 ZDO_NetworkDiscoveryConfirmCB 函数设置为 NLME_NetworkDiscoveryRequest 函数的回调函数。
您对此有什么看法吗？

此致、
村田裕也

Switch_processZStackMsgs (以 SampleSwitch 为例)是断开连接和其他网络状态的回调。

您好！

我对之前的日志有疑问。
在前面的日志中、我得到了数据包 DEV_ANNCE、但 zclport_getDeviceInfo 获取的 z-stack 的 devState 不是 DEV_END_DEVICE。
是否有任何情况会导致这种日志记录？

收件人、YK

我正在等待使用以下新的日志记录方法重现此缺陷。
当它重现时、我会发布该日志。

In Sensor_process(Tempsensor.c)

System_printf("ICall_wait start\r\n\0");
/* Wait for response message */
ICallerrNo = ICall_wait(ICALL_TIMEOUT_FOREVER);
System_printf("In ICALL_WAIT\r\n\0");
System_printf("ICallErrNo = %d \r\n\0", ICallerrNo);
if(ICallerrNo == ICALL_ERRNO_SUCCESS)
{
    System_printf("In ICALL_WAIT\r\n\0");
    pzDevInfo = zclport_getDeviceInfo(ztsEntity);
    dDevState = pzDevInfo->devState;	
    outputDevState(dDevState);	
    if(ICall_fetchServiceMsg(&stackid, &dest, (void **)&pMsg)
         == ICALL_ERRNO_SUCCESS)
    {
		System_printf("In fetchServiceMsg\r\n\0");
        if( (stackid == ICALL_SERVICE_CLASS_ZSTACK) &&
           (dest == ztsEntity) )
        {
          if(pMsg)
          {
            TempSensor_processZStackMsgs(pMsg);
            
            // Free any separately allocated memory
            Zstackapi_freeIndMsg(pMsg);
          }
        }
    }
    ~~processing for TEMPSENSOR_DATA_SEND_EVENT)~~
}

In TempSensor_processZStackMsgs(Tempsensor.c)

case zstackmsg_CmdIDs_DEV_STATE_CHANGE_IND:
    {
      // The ZStack Thread is indicating a state change
	  System_printf("msg=DEV_STATE_CHANGE_IND\r\n\0");
      zstackmsg_devStateChangeInd_t *pInd
        = (zstackmsg_devStateChangeInd_t *)pMsg;
      
      // Only process the state change if it actually changed.
      if(savedState != pInd->req.state)
      {
        savedState = pInd->req.state;
      	outputDevState(savedState);  
        if((pInd->req.state == zstack_DevState_DEV_ZB_COORD)
           || (pInd->req.state == zstack_DevState_DEV_ROUTER)
             || (pInd->req.state == zstack_DevState_DEV_END_DEVICE))
        {
          // The device is part of a network, get the device's
          // network parameters.
          //pNwkInfo = zclport_getDeviceInfo(ztsEntity);
          
          
          if(pInd->req.state != zstack_DevState_DEV_END_DEVICE)
          {
            
            
          }
          else
          {
            // Change the default poll rate from 1 second to
            // the config setting in znwk_config.h
            TempSensor_setPollRate(1000);
          }
          
#if defined (ZCL_EZMODE)
          zcl_EZModeAction(EZMODE_ACTION_NETWORK_STARTED, NULL);
#endif
        }
      }
    }
    break;

此致、
余亚市

请提供  DEV_ANNCE 数据包和 zclport_getDeviceInfo 值的内容。  没有具体细节，很难提供进一步的见解。

此致、
瑞安

您好、Ryan、

请查看已连接文件。

e2e.ti.com/.../0211.log.zip

ED 发送设备通知包。(请参见第224033号包)
但是、已保存的状态未从 NWK_DISC 更改为 DEV_END_DEVICE (请参见日志文件第435 ~ 452行)
日志文件第442行、我认为它实际上是 savedState = DEV_NWK_SEC_REGUING_ALL_CHANNEL。
我的编码错误是在更新前显示应用程序的保存状态。

此致、
村田裕也

根据我的经验、当 Zed 重新加入网络以及快速/持续的数据请求时、您应该不会看到这么多的设备公告。 如果您在 Z-Stack 源代码中未进行修改的情况下运行默认示例、那么您仍然会看到这种行为吗？

您好、YK
感谢您的答复。

请参阅随附的日志和数据包监听器日志。
我使用了除 发射功率之外的示例代码。(我使用了 ZMacSetTransmitPower (TX_PWR_联 萨特派团22)；)
有时、设备公告 会在数据包监听器日志中快速/连续看到。
(数据包编号1627-1,639,1741740-1,792,4754751-4,760,5577-5588)

e2e.ti.com/.../log_5F00_1018.zip

我希望看到您的意见。
此致、
村田裕也

我的看法是,为什么你在做测试时设置 TX_PWR_联 萨特派团22? 如果使用正常的 TX 电源、仍然会看到相同的问题吗？

您好、YK
感谢您的答复。

请参阅附加的数据包监听器日志。
下面是传输功率未降低时的日志。
有时、设备公告 会在数据包监听器日志中快速/连续看到。
(数据包编号 443562-443,605,443805 - 443816)
e2e.ti.com/.../0526.zip

即使 ZED 和 ZC 之间的距离很远、也需要重新连接我正在开发的产品。
因此、我将在降低的发射功率下测试产品。

此致、
余亚市

监听器日志看起来要好得多。 我记得 Z-Stack 会检查信号强度是否足以重新加入。 您可以尝试将 Nwk_globals.c 中的"uint8 gMIN_LQI = MIN_LQI_COUNT_3； "修改为"uint8 gMIN_TREE_LQI = MIN_LQI_COUNT_7；"、以查看在信号较差时重新加入是否效果更好。

您好、YK
感谢您的答复。

您的帮助非常有帮助。
我将尝试您的答案。
但我现在要问的问题如下。

我对之前的日志有疑问。
在 前面的 日志中、我得到了数据包 DEV_ANNCE、但 zclport_getDeviceInfo 获取的 z-stack 的 devState 不是 DEV_END_DEVICE。
是否有任何情况会导致这种日志记录？

e2e.ti.com/.../8053.log.zip

我希望就这一问题有一个答案。

此致、
余亚市

设备加入或重新连入网络后、可能需要一点时间才能将其状态更改为 DEV_END_DEVICE。 如果设备连入或重新连入网络失败、您可能会看到 DEV_ANNCE、但设备实际上已离开网络。

设备加入或重新连入网络后、可能需要一点时间才能将其状态更改为 DEV_END_DEVICE。

我需要有关上述内容的更多信息。
在大多数情况下、可使用以下代码：devState 变为 DEV_END_DEVICE、ZDO_REGUING_BACKUP 事件计时器停止、且系统将发送器件 Announce 数据包。
但是、日志行为表示已发送器件通知数据包、但 devState 不会变为 DEV_END_DEVICE、ZDO_REJING_BACKOFF 事件计时器到期、而 devState 变为 DEV_NWK_BACKUP。
(请参阅匹配记录号224033和串行记录行记录行435 ~ 452)

In ZDApp_ProcessNetworkJoin(ZDApp.c, Line1594~1654)

else if ( devState == DEV_NWK_ORPHAN ||
            devState == DEV_NWK_SEC_REJOIN_CURR_CHANNEL ||
            devState == DEV_NWK_TC_REJOIN_CURR_CHANNEL ||
            devState == DEV_NWK_TC_REJOIN_ALL_CHANNEL ||
            devState == DEV_NWK_SEC_REJOIN_ALL_CHANNEL )
  {
    // results of an orphaning attempt by this device
    if (nwkStatus == ZSuccess)
    {
      //When the device has successfully rejoined then reset retryCnt
      retryCnt = 0;

      // Verify NWK key is available before sending Device_annce
      if ( ZG_SECURE_ENABLED && ( ZDApp_RestoreNwkKey( TRUE ) == false ) )
      {
        // wait for auth from trust center
        ZDApp_ChangeState( DEV_END_DEVICE_UNAUTH );

        // Start the reset timer for MAX UNAUTH time
        ZDApp_ResetTimerStart( MAX_DEVICE_UNAUTH_TIMEOUT );
      }
      else
      {
        ZDApp_ChangeState( DEV_END_DEVICE );

        osal_stop_timerEx( ZDAppTaskID, ZDO_REJOIN_BACKOFF );

        // setup Power Manager Device
#if defined ( POWER_SAVING )
        osal_pwrmgr_device( PWRMGR_BATTERY );
#endif

        // The receiver is on, turn network layer polling off.
        if ( ZDO_Config_Node_Descriptor.CapabilityFlags & CAPINFO_RCVR_ON_IDLE )
        {
          // if Child Table Management process is not enabled
          if ( zgChildAgingEnable == FALSE )
          {
            NLME_SetPollRate( 0 );
            NLME_SetQueuedPollRate( 0 );
            NLME_SetResponseRate( 0 );
          }
        }

        if ( ZSTACK_ROUTER_BUILD )
        {
          // NOTE: first two parameters are not used, see NLMEDE.h for details
          if ( ZDO_Config_Node_Descriptor.LogicalType != NODETYPE_DEVICE )
          {
            NLME_StartRouterRequest( 0, 0, false );
          }
        }

        ZDApp_AnnounceNewAddress(); // send device announce packet

        if ( ( (ZDO_Config_Node_Descriptor.CapabilityFlags & CAPINFO_RCVR_ON_IDLE) == 0 )
            || ( (ZDO_Config_Node_Descriptor.CapabilityFlags & CAPINFO_RCVR_ON_IDLE)
              && (zgChildAgingEnable == TRUE) ) )
        {
          NLME_SetPollRate( ZDApp_SavedPollRate );
        }
      }
    }

您所说的耗时条件是什么？

此致、
余亚市

您好、Ryan。
感谢您的答复。

我给您提供了错误的信息。
日志文件中的行数为1882~1908。

设备加入或重新连入网络后、可能需要一点时间才能将其状态更改为 DEV_END_DEVICE。
关于以上方面、我想提供以下信息。
1. 你知道流程需要时间的确切位置吗?
  黑盒处理(ZigBee 处理)-> ZDO_JoinConfirmCB -> ZDApp_EVENT_LOOP -> ZD App_Process OSALMSg
  -> App_Process Join -> ZDschiles(DEV_END_DEVICE) App_Change ->状态= DEV_END_DEVICE
  -> OSAL_SET_EVENT ( ZDAppTaskID, ZDO_STATE_CHANGE_EVT )-> ZDApp_EVENT_LOOP -> ZDO_UpdateNWKStatus ( status )
  -> zdoSendStateChangeMsg ()-> (osal_event_hdr_t *) osal_msg_allocation (sizeof (osal_event_hdr_t))-> (void) osal_send (taskId、(uint8 *) pMsg)；
2. 最大延迟是多少？

3. 当 iCall_Wait 被释放时,串行日志被输出,但是当 iCall_Wait 被释放时,请告诉我该事件。
   我正在考虑可能已将状态设置为 DEV_END_DEVICE、但 ICE_WAIT 未释放、无法获取。

此致、
村田裕也

该延迟尚未指定。  封装的时间通常少于几秒。  您可以 通过功能设置来测量器件将状态从 NWK_DISC 更改为 DEV_END_DEVICE 所需的时间、并使用此类示例作为指导。  您应重点关注这样一个事实：由于与其父设备的连接质量较差、设备离开网络的时间很短。

此致、
瑞安

您好、Ryan。

问题的数据包日志和串行日志在随附的文件中进行了总结。
我对以下几点有疑问
我想知道您的意见。

1. 从18号线至55号线、经过9秒时间。
  在此期间、日志中的状态不是 DEV_END_DEVICE。
  在这种情况下、状态经历超过8秒之后才会改变吗？
  是否从 DEV_Nwk_REJING_SEC_ALL_CHANNEL 更改为 DEV_END_DEVICE？

2. 如果您不知道从 DEV_Nwk_REJING_SEC_ALL_CHANNEL 到 DEV_END_DEVICE 需要多长时间，
  我会尝试通过执行软复位来抵消这个问题。
  您认为此对策可行吗？

e2e.ti.com/.../Issues-behavior.zip

此致、
余亚市

 DEV_Nwk_SEC_REJING_ALL_CHANNEL 和 DevState_Nwk_BACKOFF 之间的时间 可能会因之前提到的 Z-Stack 设置决定的网络重新加入尝试次数和定义而异、但您似乎已根据当前的堆栈编译定义了时间。  执行软复位不能解决这些设备之间通信不良的问题、如果您需要 在应用程序中执行其他操作、而不是 DevState_Nwk_BACKOFF、则可以在 ZD8p.c 中进行更改或减少 REGISON_BACKOFF。  

此致、
瑞安

您好！

我测量了 zclport_getDeviceInfo 的处理时间。
有时需要大约9秒的处理时间。
该函数的处理时间是否这么长？
我将提供我获取的日志和源代码。

System_printf("ICall_wait start\r\n\0");
/* Wait for response message */
ICallerrNo = ICall_wait(ICALL_TIMEOUT_FOREVER);
System_printf("In ICALL_WAIT\r\n\0");
System_printf("ICallErrNo = %d \r\n\0", ICallerrNo);
if(ICallerrNo == ICALL_ERRNO_SUCCESS)
{
  startTick = Clock_getTicks();
  pzDevInfo = zclport_getDeviceInfo(ztsEntity);
  endTick = Clock_getTicks();
  System_printf("Beacon Request ret = %d\r\n\0", pzDevInfo->nwkAddr);
  System_printf("Send DEV ANNOUNCE ROUTE = %d\r\n\0", pzDevInfo->panId);
  System_printf("DISCONNECT ROUTE = %d\r\n\0", pzDevInfo->parentNwkAddr);
  // zclport_getDeviceInfo tick print start
  System_printf("zclport_getDeviceInfo tick count\r\n\0");
  System_printf("%d\r\n\0", endTick - startTick);
  ------------ ------------------------------------
}
    

e2e.ti.com/.../logfile.txt

zclport_getDeviceInfo 最终由 processSysNwkInfoReadReq 提供服务。  此函数中没有应消耗过多时间的操作。  需要注意的一点是、 在两者之间使用 Zstackapi_sysNwkInfoReadReq 来建立一条 ICall 消息来在 zcl_port 和 zstacktask 层之间进行通信、因此如果 ICall 队列忙、这可能会导致进一步的延迟。  但是、您实际上不需要像登录一样请求器件信息。   如果需要了解设备状态何时更改并执行相应的进一步处理、请监视应用程序中的 zstackmsg_Cmdids_DEV_State_Change_IND。

此致、
瑞安

您好、Ryan。

感谢您的答复。
如果 ICall 正忙、处理 zclport_getDeviceInfo 将需要一些时间。

我找到了重现此错误的方法。
・设置 rejoinScanDuration 非常短。(我将其设置为1500ms)
此错误是由于在收到重新加入响应之前退让引起的。
请尝试一下。

我有几个问题需要解答。
・可以使用以下公式计算发送信标请求的周期吗？
Beacon_request_delay + beacon_REQ_delay_mask +(zgDefaultStartingScanDuration * runtimeChannel)

・Z-stack 通过 ICall 将 DEV_STATE_CHANGE_EVENT 消息发送给应用的代码是什么？
App_Change -> osal_set_event -> ZDO_UpdateNWkStatus -> zdoSendStateChangeMsg -> osal_msg_send
(zstacktask.c) ZStackTaskProcessEvent -> processDevStateChange

此致、
余亚市

TI 不再将 CC2650作为有效的 Zigbee 解决方案进行投资、因此我不会花时间来重现此行为。  主动扫描所有通道所需的时间是扫描持续时间乘以通道掩码中的通道数。   Beacon REQ_DELAY_MASK 是位屏蔽、而不是以时间为单位的值。   App_Change 会向应用程序通知器件状态更改、这是因为 您的应用程序中的 ZDO_STATE_CHANGE (我的原始引用意外来自 SimpleLink SDK)。

此致、
瑞安