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.

[参考译文] LP-CC2652RB:使用协调器和配对问题进行长期连接状态监控

Guru**** 2390730 points
Other Parts Discussed in Thread: LP-CC2652RB, Z-STACK
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1450309/lp-cc2652rb-long-term-connection-status-monitoring-using-the-coordinator-and-pairing-issues

器件型号:LP-CC2652RB
Thread 中讨论的其他器件: Z-stack

工具与软件:

我一直在抱怨我的终端设备一直与我的协调器断开连接、已经决定尝试使用 TI 提供的协调器、以可能降低不同销售商出现实施错误的风险。 但使用 LP-CC2652RB 开发板时、似乎无法配对任何器件。 我曾尝试使用另一个 LP 和定制硬件、但都不起作用。 在控制台使用 putty 时、我可以看到配对倒计时开始、但似乎没有设备可以连接。 我已经尝试了自定义固件和 TI 提供的示例项目。 我已经为终端器件尝试了定制硬件和其他 LP、但同样无法正常工作。 我的固件和 TI 提供的示例都适用于 Sonoff 和 UZG 协调器、因此我认为终端器件可能没有问题。 我无法监听流量以获取进一步的调试信息。 这会让我回答我的问题:

  1. 导致此问题的原因可能是什么?如何让器件与在 LP 上运行的协调器配对?
  2. 如果我成功地让他们配对、我如何能够长时间监控流量? 设备可能会在首次配对几天或几周后断开连接、因此我可能不得不使用其他的调试方法、而不是流量监听。

我使用 SDK 6.20版构建了定制传感器、从未如此稳定。 将我的代码移植到最新的 SDK 版本以及从基于 Eclipse 的 CCS 切换到 Theia 是否有好处? 假设断开连接不是由代码中的主要隐藏缺陷引起的、我是否应该期望在使用最新的 SDK 版本时获得更高的稳定性?

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

    您好!

    感谢您联系我们。 移植到最新的 SDK 确实带来了许多好处、例如错误修复、额外的功能和优化。 我们在用户指南中包含了迁移指南、可在移植过程中提供帮助。 我已将以下链接链接:

    https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_7_41_00_17/docs/zigbee/html/zigbee-guide/migration_guide.html

    https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_7_41_00_17/docs/ble5stack/ble_user_guide/html/ble-stack-5.x-guide/migration-cc13xx_cc26xx.html

    我们将查看您的其他问题、并尽快与您联系。

    此致、

    1月

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

    您好、A V:

    请尝试擦除所有器件存储器或将 ZC 器件恢复出厂设置、以排除任何非易失性存储器问题。  然后、确保遵循 Zigbee Project Zero SLA 开始使用 ZC 和 ZED。  确保在两个器件上使用相同的通道。  尽管您不希望使用监听器器件、但对调试非常有帮助。

    使用 Zigbee API  (如 Zstackapi_sysNWkInfoReadReq ()、 Zstackapi_Zdo gmtLqiReq ( )和 Zstackapi_Zdo mmetRtgReq ()或 assoc_list.h/ nwk_util.h API)来收集网络信息并"发现"活动设备。  您还可以受益于 Z-Tool 连接的 ZNP。  以下是 用于额外参考的 MT API。

    此致、
    Ryan

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

    Ryan、您好!

    我试图嗅探流量无数次,但现有的工具只是窗口,他们不能在我的电脑上工作。 大约一个月前、我在给您的一位同事的以下回复中对此进行了解释:

    Alex、您好!

    我已到达办公室、并尝试通过两种方式再次嗅探:

    1. 使用 TI 提供的本指南:不起作用。 我 用所示的固件刷写了 LP-CC2652板、但无法获取  SmartRF 数据包监听器2来检测电路板。 我已经确保安装了 Cebal 驱动程序、再次刷写了电路板、重新启动了数据包监听器几次、重新连接了电路板、但仍然没有任何反应。 Ubiqua 协议分析器在几个月前工作过(当我上次尝试时,软件包监听器不工作),但我的免费试用过期了,他们只允许你缓存1000个消息,这在几分钟内就填满了。 用处不大、不愿意每月支付65美元。
    2. 使用 Zigbee2Mqtt 提供的本指南:仍然无法正常工作。 我已经成功使用 CC 调试器刷写电路板、配置了 ZBOSS 监听器、但 Wireshark 不会解码任何消息。

    关于我的数据包监听器2的问题:该程序没有检测到任何电路板、尽管我在设备管理器中看到过它们。 如果我尝试手动配置串行设置、则端口下拉列表不可用、并且无法看到设备管理器中列出的端口来手动选择器件 COM。

    在  Mac 上似乎没有任何用于流量监听的工具、但我可能会在以后使用 Windows 机器重试。 请告诉我这些问题是否已知以及是否存在权变措施。

    在此之前、我将听从 Jan 的建议、开始将我的代码移植到最新的 SDK 版本。 我会更加小心、一旦开始工作、我就会回来提供更新。

    其他问题:

    我正在开发的器件是一个双端点温度传感器、其中两个端点都是温度测量集群:一个用于测量环境温度的 SHT40板载传感器、另一个端点用于安装在散热器管道上以进行自动化的 NTC。 为端点使用两个温度仪表组是否会带来任何稳定性风险?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    在  Mac 上似乎没有任何用于流量监听的工具、尽管我以后可能会用 windows 机器重试。 请告诉我这些问题是否已知以及是否存在解决方法。

    Packet Sniffer 2仅支持 Windows、Ubiqua 不免费、因此我理解您的担忧。

    [报价用户 id="509946" url="~/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1450309/lp-cc2652rb-long-term-connection-status-monitoring-using-the-coordinator-and-pairing-issues "]终端设备不断断开与我的协调员的连接
    我使用 SDK 6.20版构建了我的自定义传感器、这款产品从未有过稳定可言

    您的终端设备在重新启动之前是否崩溃和完全无响应、或者它们是否只是失去与 ZC 的连接并必须重新加入网络?

    为端点使用两个温度群集是否会带来任何稳定性风险?

    我目前并不了解任何稳定性风险。  您是否观察到您可以提出的任何问题?  即当您只使用一个端点时、您的项目不会出现类似问题?  我看到过 其他 E2E 实例 、在这些实例中、用户能够实现针对更多端点和集群的报告。

    此致、
    Ryan

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

    您好、Ryan

    您的终端设备在重新启动之前是否崩溃且完全没有响应、或者它们是否只是失去与 ZC 的连接并必须重新加入网络?

    似乎没有发生崩溃。 我有一个活动 LED、每次执行传感器读取时我都会切换、设备似乎工作正常。 我假设某种原因导致连接丢失而不会崩溃。 我放置了一个看门狗、因此如果器件卡在某个循环中、看门狗应该会恢复它。 此外、我认为器件不会重新启动、因为我尝试在每次上电时重新连接:

    zstack_bdbStartCommissioningReq_t zstack_bdbStartCommissioningReq;
    zstack_bdbStartCommissioningReq.commissioning_mode = 0;
    Zstackapi_bdbStartCommissioningReq(appServiceTaskId,
                                           &zstack_bdbStartCommissioningReq);

    如果我看到其中一个传感器断开连接、取出电池并放回就足以使用协调器进行维修。

    您是否观察到任何您会问的问题?  也就是说、当您仅使用一个端点时、您的项目不会出现类似问题?

    我当时很好奇。 我在使用 SDK 6.20中提供的未修改示例时看到了完全相同的行为。 TI 提供的样品温度传感器会按照我自己项目的方式随机断开与协调器的连接。 未注意到断开连接的频率差异。 Sonoff 和 UZG 协调员我已经完美地工作了现成的产品从阿夸拉或宜家。 此外,我有一个随机的阿夸拉温度传感器,已经死了几个月,并放入一个新的电池,它自己修复没有任何问题。 当我自己的传感器断开连接(但仍通电)超过一周时、我必须重新执行整个配对过程才能使其正常工作。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    当我自己的一个传感器断开连接(但仍通电)超过一周后、我必须重新执行整个配对过程才能使其正常工作。

    Zigbee 协调器有一个终端设备超时过程(Z-Stack 中的 END_DEV_TIMEOUT_VALUE/NWK_END_DEVICE_LEVE_TIMEOUT 定义)、对于该过程、在指定的时间内无响应后、会从网络中删除 ZED。   

    如果传感器断开连接、则在 ping ZCL 数据包时不会接收到协调器的响应。  您可以尝试以不频繁的间隔发送这样的数据包、如果 ZC 不响应、则可以进一步调试该行为以确定它是否与故障实例相同、或者只需调用 SysCtrlSystemReset 来通过复位和重新连接来缓解该问题。

    此致、
    Ryan