[参考译文] CC2530：协调器和终端设备交互

您是否有监听器日志来详细说明此类行为？

AFAIK、IEEE 地址是发送 ZDO 管理休假请求所必需的。

否、设备在离开网络后不会与以前的网络通信。

否

Mark、您好！

默认 的 END_DEV_TIMEOUT_VALUE 为8、这意味着在256分钟内未进行通信后、ZED 将过期。  如果父级错过了太多的 ZED 数据请求、则子级也可以搜索更好的父级。  您可以增加 TX 功率或减小节点之间的距离以改善链路。

2.可以使用  UTIL_ADDRMGR_NWK_ADDR_Lookup 来发现关联表中设备的扩展地址。

此致、
Ryan

大家好

>>>1. 默认的 END_DEV_TIMEOUT_VALUE 为8、这意味着在256分钟内未进行通信后、ZED 将被淘汰。 如果父级错过了太多的 ZED 数据请求、则子级也可以搜索更好的父级。

如果终端设备已离线数天、然后联机、我将获得 ZDO_END_DEVICE_ANNCE_IND (0x45C1)+ ZDO_TC_DEV_IND (0x45CA)。 通信继续。 256分钟的离线时间不会导致离开。
离开的速度要快得多。 当 LinkQuality 足够高时-终端设备工作数天没有问题。 但是、如果终端设备和协调器之间存在一些障碍、ZDO_LEASE_IND 可能会在数十秒内发生。 即使消除了障碍物、与终端设备的连接也会丢失。 恢复通信的唯一方法是手动干预：PermitJoin +按下配对按钮。 终端设备在任何情况下都不应离开网络。 离开的唯一方法也应该是人工干预。

>>您可以提高 TX 功率或减小节点之间的距离以改善链路。
我们将 LNA 和外部天线用于协调器和终端设备。 但是、人群、装载机或金属门可能会随机穿过协调器和终端设备之间的通道。 在早期或之后、障碍物将消失、通信应继续进行。

>>>您是否有监听器日志来详细说明此类行为？

我们监听了无线电。 在金属盒的帮助下降低了 LinkQuality。

--示例1：

协调器：0x0000
ZDO：0x3459
数据包#3492 -从协调器到终端设备。
数据包#3494 -从终端设备离开以进行广播。
发起方是协调方。

-- --示例2

协调器：0x0000
ZDO：0x7F07
数据包#203-219 -从协调器到终端设备的若干叶片。
数据包#220-223 -从终端设备到广播的大量数据包。
发起方也是协调方。

我们需要禁用意外离开。 源代码中是否可以有一些#defines 来实现协调器的这种行为？

感谢监听器日志截屏、如果可以、请随时提供实际的监听器日志文件。  似乎是由终端设备的重新加入请求引发的。  您是否能够在失败状态期间调试协调器、如果是、它如何处理 ZDSecMgrDeviceJoin、以及它何时发送 NLME_LeaveReq (可能来自 ZDSecMgr.c)？  在此期间是否允许加入并将 zgAllowRejoins 设置为 true (ZGlobals.c)？

// trustcenter allows rejoins using well known or default keys 
uint8 zgAllowRejoins = FALSE;   // FALSE by default

//if zgAllowRejoins is set to FALSE, the rejoining device will receive a rejoin rsp success and also a leave command.
//The leave command will have set the rejoin parameter = 'zgAllowRejoinsOptions' value.
uint8 zgAllowRejoinsOptions = FALSE;  //FALSE by default

另请查看 Z-Stack 3.0.2已知问题和修复 E2E 帖子。

此致、
Ryan

你(们)好，Rian

ZGlobals.c 中的两个参数默认为 false
uint8 zgAllowRejoins = false；
uint8 zgAllowRejoinsOptions = false；

1.我已按照您的建议将其更改为 true。 这种情况没有得到明显的证明。 这两个参数仅在库中使用。 他们的感觉是什么？

在低链路质量上、虽然没有任何保留、但协调器只是忘记了终端设备、并针对向 ZDO 发出的任何请求响应了 ZNWKNORoute (0xCD)。 Util_get_device_info 表明表中根本没有器件。

--日志示例1：

12：45：31之前、就在-路由请求之后、有重新加入响应。 这是协调员忘记设备的关键时刻。 我怀疑这一时刻与 PermitJoin 终端共存。

--日志示例2：

类似情况。 12：53：49之前、有重新加入响应、之后-路由请求。 协调器再次忘记设备。 PermitJoin 也被终止。

完全登录附件(时移12：41：00)

e2e.ti.com/.../Log7_5F00_25_5F00_10_5F00_2022_5F00_Leave.zip

忘记设备的原因是什么？ 虽然终端设备诱使协调器忘记、但如何防止这种情况？ 是否可以强制协调器和终端设备无限恢复连接？

您好、Ryan

>>>从数据包108开始，ZC 中似乎有多个“格式错误的数据包”，ZCL 序列号永远不会递增。
这些是我的测试请求。 我通过 API AF_DATA_REQUEST (0x2401)生成它们并发送给协调器。 始终存在相同的 TransId 和 ZCL 序列号。 是否会导致问题？
如果有良好的连接性、则根本没有问题。 设备可以正常工作数天。

TransId 和 ZCL 序列号是否相互依赖？ 像 ZCL 序列号= TransId + 1？
是否应在任何消息中使 TransId 和 ZCL 序列号独立于响应递增？
如果溢出0xFF->0、对吧？
是否有关于这两个字段的详细信息？

>>>一旦收到数据包136，ZC 就会在试运行后相当早的时间内开始丢失 ACK。
我想这是手动造成的数据包丢失、以重现这种情况。 良好的连接性没有问题。 在实际对象上、断开连接需要几天时间。 在调试时、我们必须为通信设置较差的条件才能在数分钟内获得相同的故障。

>>使用与 Z-Tool 相连接的默认 CC2530 Z-Stack 3.0.2 ZNP 时、您是否观察到此行为
我还没有尝试过。 通过 Z-Tool 手动发送多个请求并不容易、但会尝试...

>>以及与 ZNP 器件关联的器件数量大约是多少？
唯一的终端设备。

>>>即使节点彼此靠近，类似的行为是否仍然存在？
一切都取决于 LinkQuality。 很好的水平-没问题。 但我们无法保证物体的质量达到100%。

>> Z-Stack 3.0.2已知问题和修复 E2E 帖子
大多数问题都得到了解决。 已尝试减少 NWK_MAX_DEVICE_LIST、MAX_ANEL_ENABLESTERS"条目并增加 NWK_MAX_DATABIFS。 连接似乎更稳定、但最终会中断。

这是屏幕截图：

我可以看到890是最后一个 ACK 成功完成的数据包。 之后、我对 Coorditator 的请求未导致任何对讲机活动。 然后协调器停止响应我的 API 请求。
重新引导协调器后未忘记设备、但终端设备已离开网络。
为什么？ 看起来终端设备也需要修复。

e2e.ti.com/.../Log8_5F00_26_5F00_10_5F00_2022_5F00_Leave.zip

(完全登录附件，轮班09：37：30)

>>如果可能、您应该考虑将 ZNP 迁移到 SimpleLink CC13X2/CC26X2器件。
迁移到 CC2652P 是否可以解决所有这些问题？

感谢您的澄清、我想确保这是预期效果。

每个 Zigbee 层(IEEE、NWK、APS、ZCL)都有自己的计数、用户可以配置 ZCL。  这也是一项检查、以确保行为是已知和预期的。

如果 ZC 无响应、ZED 将进入孤立状态、这样它就可以发送信标、从而可能重新加入另一台路由器设备。  这应在同一网络中发生、除非应用程序指示它应忘记上一个网络并从开始重新启动调试。  这就是为什么它 有助于了解应用于每个项目的具体更改。

如前所述、CC2530具有有限的 RAM、因此与 CC2538或 SimpleLink CC2652R 相比、它作为 ZC 信任中心的性能较差。   另一个考虑因素是、CC253X 的最后一个 Z-Stack 更新发生在四年前、而 SIMPLELINK-CC13XX-26XX-SDK 仍然每季度收到更新、其中包括错误解决和功能改进。

ZED 和 ZC 似乎正在尝试保持连接、但由于链路质量差而不断受到阻碍、导致断开连接。  您可以在器件之间添加路由器、以帮助提高稳定性、或增加器件的 TX 功率、使其能够传输更远的距离。  最终，在这种情况下，可以实现的目标将受到限制。

此致、
Ryan

您好、Ryan

我们已根据 CC2652P 建立了一个新的协调器、并复制了具有低链路质量的相同实验。 协调器(CC2652P)、ZED (CC2652RB)、请求0x2401 ->响应0x4481。
我们不时收到_ANNCE_IND、但最终 ZED 发送了休假消息。

现在协调器不会忘记 ZED、但 ZED 仍然离开网络。
完整日志： e2e.ti.com/.../Log8_5F00_16_5F00_11_5F00_2022_5F00_Leave.zip

我们需要了解离开的原因。 ZED 可能会考虑电池的工作、并让网络备用能源？
ZED 基于 examples\rtos\LP_CC2652RB\Zstack\zed_temperaturesensor 并具有外部电源
我们的修改：
1. CUI 仍处于活动状态
添加了自定义请求/响应(0z2401/0x4481)
修改了 ZD_CONFIG.c
空 ZDConfig_UpdatePowerDescriptor()
｛
ZDO_Config_Power_Descriptor.powermode = NODECURPWR_RCVR_AYST_ON；
ZDO_Config_Power_Descriptor.AvailablePowerSources = NODEAVAILPWR_MAINS；
ZDO_Config_Power_Descriptor.CurrentPowerSource = NODEAVAILPWR_MAINS；
ZDO_Config_Power_Descriptor.CurrentPowerSourceLevel = NODEPOWER_LEVEL_100；
｝

和 zcl_sampletemperaturesensor data.c
const uint8_t zclSampleTemperatureSensor_PowerSource = power_source_DC；

使用预处理器构建定义：
ZCL_READ
ZCL_discover
ZCL_WRITE
ZCL_BASIC
ZCL_Identify
ZCL_GROUP
ZCL_TEMP_measurement
ZCL_MS
BDB_报告
TIMAC_ROM_PATCH
xCUI_DISABLE
MAX_STATUS_LINES=10
ZStack_security
Board_display_use_UART
FREQ_2_4G
OSAL_PORT2TIRTOS
OSAL_PORT2TIRTOS_OSALMAP
STACK_LIBRARY
ZDO_API_BASIC
TC_LINKKEY_JOIN
NV_RESTORE
NV_INIT
图元非信标模式
ZCL_单机 版
MAX_DEVICE_TABLE 条目= 50
DEVICE_family=cc26x0
DeviceFamily_CC26X2
TIMAC_ROM_IMAGE_BUILD
NVOCMP_NVPAGES=2

我们错过了什么吗？ 由于低链路质量和休假后是否会升温？ 我们需要防止 ZED 偶尔离开。

ZED 发送离开命令不应与您的应用和预定义更改相关、但您可以使用默认 ZED 温度传感器项目进行测试以进行确认。  如果可能主动调试 ZED、或者由于您仍然启用了 CUI、则有助于确定导致 bdb_resetLocalAction 或 bdb_event_loop 上的 NLME_LeaveReq 的调用栈、因为这两个位置是激发中断的两个可行位置。  

bdb_event_loop 中的实例取决于 BDB_TC_LINK_KEY_EXCHANGE_FAIL、鉴于 ZED 应已将 TCLK 存储在 NV 存储器中、并且似乎不会通过无线方式发送任何 TCLK 更新请求、因此对于该上下文而言这种情况没有太大意义。  从安全角度来看、这种情况可能会发生、因为 器件最近在 Lave 命令之前加入了不到15秒、并且 ZC 无法 ACK 节点描述符和读取属性响应。

   导致 bdb_resetLocalAction 的 Zstackapi_BdbResetLocalActionReq 的两个实例都依赖于 CUI、可以通过 UART 选择或在复位期间按 BTN-2。  这甚至比上一个实例更不可能。  您提到 ZED 由外部供电、通常通过电池供电。  在此行为期间、ZED 的电压电平是多少？其 TX 功率电平是多少？  如果尚未执行此操作、则应设置 NVOCMP_MIN_VDD_FLASH_MV=200 (非易失性存储器低压检测)、以便在低功耗状态下不会损坏 NV。

此致、
Ryan

您好、Ryan

更多实验
协调员 CC2652P SDK 6.30、基于 ZNP_CC1352P_2_LAUNCHXL
更改：
zgAllowRejoinsWithWellKnownKey = true；
zgChildAgingEnable = false；

EndDevice CC2652RB SDK 6.30、基于 zed_temperaturesenser_LP_CC2652RB
更改：
requestNewTrustCenterLinkKey = false；

在调试器下进行 ZED、每个 NLME_LEAVeREQ 函数调用都有断点。
在通信期间、我们通过天线发出光、极化变化、器件屏蔽将 LinkQuality 降低到大约零。 目的是重新连接 ZDO_TC_DEV_IND 和 ZDO_END_DEVICE_ANNCE_IND。

没有一个断点是应该的。 将继续探索。
似乎有两个问题：
1.ZC 向 ZED 发送休假

完整日志 e2e.ti.com/.../09_5F00_18_5F00_11_5F00_2022.zip 故障低于1072。

2.ZC 无需离开即可使用 ZED

完整日志 e2e.ti.com/.../11_5F00_18_5F00_11_5F00_2022.zip 故障低于1608。

完整日志 e2e.ti.com/.../12_5F00_18_5F00_11_5F00_2022.zip 故障低于2148。

是否有任何关于如何防止不安全离开的想法？

第1个日志：与 ZED 一样、您可以调试 ZC 以确定它为何进入 ZDSecMgrDeviceRemove 以执行 NLME_LeaveReq。  这可能是由于缺少 Device Announce 消息。  您可能已经注意到重新加入位为 true、几秒钟后 ZED 重新加入成功。

第二个日志：我不相信 ZC 收到 ZED 设备通告消息，因此我相信另一个路由设备是父设备。  它正在确认直接发送给它的数据请求，然后尝试找到正确的父设备来接收排队的消息。

第三个日志的症状相同。  您将需要减小节点之间的距离或增加每个节点的 TX 功率以改善行为。

此致、
Ryan

尊敬的朋友 Ryan

>>您可以对 ZC 进行调试、以确定它进入 ZDSecMgrDeviceRemove 执行 NLME_LeaveReq 的原因。

当然、但我们只有调试器、因此可以一次性调试 ZC 或 ZED。 这些日志是在调试中通过 ZED 收集的。 现在将调试 ZC。

>>>我不相信 ZC 收到 ZED 设备通告消息，因此我相信另一个路由设备是父设备。 它正在确认直接发送给它的数据请求，然后尝试找到正确的父设备来接收排队的消息。

如果长时间(小时、天、周)关闭设备、则不会出现问题、打开设备后、设备将照常继续工作。 如果 ZC 和 ZED 之间的良好联系没有问题、他们工作数天和数周(我相信他们也可以工作数月和数年)。 当 LinkQuality 约为零时、会发生问题。 正如我刚才所说、我们可以确保100%的良好 LinkQuality。 在我们的实验中降低 LinkQuality 的唯一原因是在真实物体上重现情况。

>>您需要减小节点之间的距离或提高每个节点的 TX 功率以改善行为

ZC 和 ZED 无功率限制、由交流/直流转换器供电。 基于 CC2652P 的 ZC、具有+20dB 的放大效果和外部 WIFI 天线。 ZED 基于 CC2652RB、具有+5dB 放大功能和外部 PCB 天线。 距离约为15-20m、但可能会发生障碍物。 我们无法预测障碍的时间、持续时间和数量。 我们承认、几分钟甚至几个小时的连接中断。 但是、当障碍物移出时、连接必须恢复。 我们实际上并不需要在连接意外丢失后手动重复设备配对。

我们所需要的只是在任何情况下强制设备恢复连接、而无需手动干预。
我们怀疑这种行为与某些计数器/缓冲器/表过载甚至与安全策略有关。 如果是最后一个、让我们谈谈安全简化、我们可以自行减少流量。
我们需要您的支持。

您好、Mark、

感谢您对环境和项目要求的详细描述。  关于宽松安全性、您需要查看 ZD_sec_mgr.c 中 的 AddrMgrEntryRelease 用于删除设备关联的部分。  这是 在 APSMG_TCLinkKeyLoad 期间(由于允许器  件重新加入网络、因此不可能维护 TCLK、但考虑到更改的 zgAllowRejoinsWithWellKnownKey 位、我不太确定)或 ZDSecMgrAddrClear。  您可以进一步调试以确定 是否在任何时候使用了 ZDSecMgrAddrClear、然后查看调用堆栈以进一步确定在应用程序的 ZD_sec_mgr.c 内采取的正确操作。

您是否有推荐的复制此行为的方法、以便我可以从我的终端进一步测试？

此致、
Ryan

尊敬的朋友 Ryan

我们继续对 Zigbee 器件进行实验。 最终我们发现了 Zed 正在发生的事情。
我们注意到 Zed 在没有 CUI 的情况下寿命更长。 因此、我们使用关键字 CUI 禁用了它。 遗憾的是、LED 和按钮也已消失。

添加了#define RESET_ASSERT

对文件 ZD_APP.c 第516行进行了注释
//zgWriteStartupOptions (ZG_STARTUP_SET、ZCD_STARTOPT_DEFAULT_NETWORK_STATE | ZCD_STARTOPT_DEFAULT_CONFIG_STATE)；
这条线强制 Zed 忘记连接。 如果没有它、我们将获得所需的结果。
尽管链路质量较低、但 ZED 不会忘记网络。

我们有一些问题没有得到答复：

我们不确定第516行是最好的决定。 虽然我们得到了结果、但我们可能会失去其他东西。 是否会有一些副作用？
ZBA_REST_NWKKEY 的用途是什么？ 它能帮助我们保持连接吗？
3.DEV_END_DEVICE_UNauth //已加入但尚未通过信任中心进行身份验证
我们希望每次加入时都能发生这种事件、但实际上不会。 它可能在什么条件下发生？ 是否有超时？

4.有 SysCtrlSystemReset()函数可重置微控制器。 ZED 是否在连接安全时进行复位？ 处于未配对状态？

如果是良好的 LinkQuality、则使用 ZC 向我发送 AF_DATA_CONFIRM、状态为0x00 = OK。 在低链路质量的情况下、我曾经获得0xF0 =无响应、但有时0xCD =无路由。 因此、ZC 有一些理由从表中删除 ZED。 如果 ZED 继续从 ZC 请求数据、ZC 继续与 ZED 通话。 在对 Zed 中的第516行进行注释之前、我们习惯了断开连接。 我们可能应该在 ZC 中进行类似的更改、以防止线路松动。

6.zgChildAgingEnable=true；如果 zgChildAgingEnable=false，会产生什么影响？ 扫描床过载？

7.我们需要一个示例，说明如何添加我们自己的群集和命令。 现在、我们使用 ZCL_CMD_READ 处理程序。 只是添加了行
if (pInMsg->msg->clusterid=0x8888)｛OurHandler (pInMsg)；返回 true；｝
到 zclProcessInReadCmd( zclInforing_t *pInMsg )函数。
它起作用、但我们怀疑必须有更正确的方法来添加我们自己的处理程序。
最好添加我们自己的命令并使用我们自己的数据类型。 请提供一些示例吗？

谢谢

ZDO_DEVICE_RESET  事件用于器件出于任何给定原因(由其他器件或用户交互请求)需要离开网络的情况、因此删除启动选项会破坏此功能。
2. 如果 设备身份验证失败，ZBA_FRESTE_NWKKEY 将使用现有的备用 NWK 密钥。  这可能是一个选项、因为 ZED 当前无法与 ZC 通信。
DEV_END_DEVICE_UNauth 是 DEV_NWK_INUSTONGIN 和最终 DEV_END_DEVICE 之间的状态、由于器件应已进行身份验证、因此每次重新加入时不会发生该状态。
4.如果 ZDUApp_RestoreNWKKey 返回 false，或者状态为 DEV_NWK_TC_RESUARE_CURR_CHANNEL 或 DEV_NWK_TC_RESUOND_ALL_CHANNEL，如果没有来自 TC 的正确身份验证，则设备将离开网络。  请参阅以下代码摘录：

//bdb.c

  // Transition state machine to correct rejoin state based on nwk key
  if ( (bdbSecureRejoinAttempts < zgBdbMaxSecureRejoinAttempts) && (ZDApp_RestoreNwkKey( FALSE ) == TRUE) )
  {
    ZDApp_ChangeState( DEV_NWK_SEC_REJOIN_CURR_CHANNEL );
  }
  else
  {
    ZDApp_ChangeState( DEV_NWK_TC_REJOIN_CURR_CHANNEL );
  }

//zd_app.c

      // Verify NWK key is available before sending Device_annce
      // Device performing TC rejoin shall wait until (new) NWK key received
      if ( ZDApp_RestoreNwkKey( TRUE ) == false ||
           devState == DEV_NWK_TC_REJOIN_CURR_CHANNEL ||
           devState == DEV_NWK_TC_REJOIN_ALL_CHANNEL )
      {
        if ( ZSTACK_END_DEVICE_BUILD )
        {
          nwk_SetCurrentPollRateType(POLL_RATE_TYPE_JOIN_REJOIN,TRUE);
        }
        // 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 );
      }

您可以选择器   件继续尝试 DEV_NWK_SEC_RESUON_CURR_CHANNEL、而不是使用 DEV_NWK_TC_RESUON_CURR_CHANNEL、或者在验证失败时不使用 ZDUP_ResetTimerStart。
5.如果 zgChildAgingEnable = true，则 在 END_DEV_TIMEOUT_VALUE 过期后，ZED 关联将从 ZC 中删除。
6. zgChildAgingEnable 允许 ZC 清除不再通信的 ZED 关联，因此如果忽略该表，则可以填充该表。
请参阅此相关 E2E 主题 ：https://e2e.ti.com/f/1/t/1124463 

此致、
Ryan

尊敬的朋友 Ryan

感谢您的回答。 我们获得了大量有用的信息、并取得了一定的结果。
但我们仍有一些问题。
请求到 ZED 和从 ZED 响应之间的延迟平均为2-4秒。
在浏览代码时、似乎有两种方法可以减少延迟：

将 POLL_RATE 从3000降低至500。 它将加快响应速度、对吧？ 但是、如果有许多 ZED、例如50。 所有这些器件每500毫秒从 ZC 请求一次数据。 这会是个问题吗？

2.切换到 RxAlwaysOn 模式。
ZC 是否会在 RxAlwaysOn 模式下立即向 ZED 发送请求而不排队？

我们在 ZED 中尝试了这两个定义：
RFD_RX_AUSE_ON_Capable=true
RFD_RX_ALOW_ON=true
但没有成功。 ZED 无法与 ZC 配对。 有 ZDO_TC_DEV_IND (0x45CA)、但没有 ZDO_END_DEVICE_ANNCE_IND (0x45C1)。
可能还有另一种方法可以将 ZED 转换为 RxAlwaysOn 模式。

从 ZC 的角度来看、有什么更好的选择：RxAlwaysOn 模式下为50个 ZED、休眠模式下为50个 ZED、POLL_RATE = 500？

我很高兴听到您正在取得进展。

1.降低 POLL_RATE 会降低数据延迟，同时还会增加网络流量。

2. 非休眠状态将在器件通告期间广播，因此父节点将知道它可以立即向非休眠 ZED 发送消息，而不会在数据请求上挂起。

请尝试在 f8wConfig.cfg 中设置 RFD_RCVC_ALWEY_ON=true、是否还有任何理由继续使用 ZED 节点而不是 ZRS？

此致、
Ryan

尊敬的朋友 Ryan

谢谢。

DUT、找不到 f8wConfig.cfg 文件。
我在 ZStack 1.2和 ZStack 3.0中找到它。

但我的 ZED 基于 SDK 6.30构建。 是否没有此类文件？

很抱歉、您提到了旧版 CC253X 更改。  对于 SIMPLELINK-CC13XX-CC26XX-SDK 器  件、您将参考 Z-Stack->Power Management 模块下的 SysConfig 文件、并将"电源模式"更改为"始终开启+休眠"(RFD_RX_AUSE_ON_Capable = true)、并将"电源运行模式"更改为"始终开启"(RFD_RX_AUST_ON = true)、从 z_stack_config.h 生成的文件生成。  我刚刚使用 SIMPLELINK-CC13XX-CC26XX-SDK v6.30中的 zc_light 和 zed_SW 项目确认了这种模式的成功运行

此致、
Ryan