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.

[参考译文] CC2652R:协调员丢弃无法访问的设备

Guru**** 2589300 points
Other Parts Discussed in Thread: CC2530, CC2652R, Z-STACK

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1080757/cc2652r-coordinator-dropping-inaccessible-devices

部件号:CC2652R
“线程:CC2530Z 堆栈”中讨论的其它部件

大家好,

我需要了解 ZigBee 网络在 信号较弱的设备(大量失败消息)上的默认行为。

假设您有一台电池供电的困倦设备,每小时报告一次,每10秒自动轮询一次。

根据我的经验,当设备靠近协调器且没有通信故障时,一切都正常。

但当我将设备移到信号覆盖不良的位置 时,我会出现以下行为:

-终端设备能够向协调人报告。 可能会发生某些报告未送达的情况,例如,即使一小时后的报告未送达,协调员也会接受下一个2小时后的报告。

-设备每隔10秒轮询一次新消息。 协调员被设置为在30秒后使消息过期。 因此,当协调员试图将消息传送到终端设备,但传送失败时,可能 当这种情况多次发生时,协调员决定忽略此类终端设备。 发生这种情况时,即使终端设备被移动到更好的位置,协调员仍拒绝向终端设备发送任何内容。 另一方面,协调人可以毫无问题地接收来自设备的报告。 唯一有帮助的是重新启动终端设备,所有设备都开始工作(我不确定 为什么-重新加入?)

因此,我不知道在这种情况下会发生什么。  

-协调员是否会在发生一些故障后从邻居列表中删除此类有问题的设备?

-有什么办法可以防止这种行为?

-终端设备和/或协调员是否可以配置任何内容?

我使用 cc2652R 和 zigbee2mqtt 作为协调器,例如 CC2530作为一个安静的终端设备,带有 z-stack1.2,带轮询间隔10秒的 Nwk_auto_polling。 电源管理设置为电池和省电设置。

但我也注意到一些商业终端设备的这种行为。

在我看来,当协调人遇到一些通信故障时,它会从邻居列表中删除终端设备,然后再也不会尝试向其发送任何内容。 只有当终端设备重新连接网络(例如,取出的电池)时,它才会刷新表,并再次能够与设备通信。

我能做些什么来强制协调员不要放弃某些设备,即使存在临时通信问题?

谢谢你。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您能否提供嗅探器日志来详细说明您的问题/案例?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    感谢您的快速回复:)我会尝试嗅探并收集一些日志。 现在我甚至不确定是协调员拒绝来自终端设备的消息,还是终端设备停止轮询。 我正在努力更好地了解在这种情况下它应该如何工作。 默认情况下,当与协调器的连接较弱且周围没有路由器时,终端设备应该怎么做? 它应该停止投票还是永远尝试? 协调员应该怎么做? 它应该从邻居列表中删除此类设备,还是只是等待? 终端设备端的相关设置以及协调员端的相关设置。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    当终端设备轮询失败或 Mac 在发送消息时无法恢复时,它将变为孤立状态并开始重新加入网络。 对于 Zigbee HA 1.2或 Zigbee 3.0设备,如果无法重新加入网络,它将后退一段时间,并再次重新启动同一个循环,直到它重新加入。  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    谢谢。 我会期待这种行为。 在本论坛上的一个旧话题中,我发现了以下几点:  

    由于您使用 Z-Stack 3.0协调器,因此设备将会老化,因为该设备长时间不会轮询。 当过期设备尝试向协调员发送消息时,该设备将不在关联列表中,协调员将要求设备离开以重新加入。

     

    如果我的 ZStack 1.2终端设备由于连接质量差而无法“长时间”轮询,会发生什么情况。 然后,我的3.0岁协调员将其标记为“已过期”,然后要求其离开。 当我只有默认实现时,我的 Zed 会发生什么情况——没有任何网络状态的自定义处理。 设备在被要求离开时是否会自动重新加入,或者是否需要手动实施此类机制? 谢谢你。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    嗨 Peter,

    请参阅 《Z-Stack 用户指南》的“子管理”部分。  如果超过 end_dev_timeout_value,ZC 将从其关联表中删除设备,但不会从网络中删除其信息。  它还将尝试向终端设备发送启用重新加入的休假请求。  因此,一旦 Zed 重新建立了更好的连接,它就完全能够通过单独的 ZR 父级或 ZC 重新加入网络。  处于孤立状态时,它将尝试按照网络连接管理器所述的方式重新加入网络。

    此致,
    瑞安

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    大家好。 非常感谢您的回答。 如果它能像你所描述的那样工作,那将会很棒。但是,当我的终端设备进入孤立状态时,它似乎不会尝试重新加入。 只有当我通过取出电池重新启动时,它才会发送计时器触发的定期报告,但它无法接收任何内容(写入命令)。 我需要嗅探和调试...非常奇怪,因为我没有做任何不寻常的事情...

    非常感谢您的意见。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您还可以尝试调试 ZDApp.h,以确定设备是否进入 dev_fwk_nonus 状态,从而开始定期 的 ZDO_REACK_backoff 事件。

    此致,
    瑞安

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    大家好,经过一些调查,我发现问题是由信号质量太差导致的,终端设备无法脱离孤立状态。 也许,甚至无法成功完成重新加入协调员或寻找新的家长所需的沟通。 我已经解决了一些天线问题,似乎该设备已回到正轨,并按预期运行,即使  在信号暂时弱的情况下也是如此... 非常感谢您的支持。 至少这有助于我理解预期的内容并缩小问题范围。