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.

[参考译文] CC2530:默认响应不通过 ZR 从 ZC 传送到 ZED

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

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/898169/cc2530-default-response-is-not-delivered-from-zc-to-zed-through-zr

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

我正在从事一个家庭自动化项目、其中 TI CC2530与门触点、运动传感器、光开关等其他器件配合使用、充当 ZC。 射频模块与 Z-Stack 3.0.2搭配使用、并根据 http://www.ti.com/lit/wp/swra635/swra635.pdf 在 RAM 和闪存范围内进行了少量修改、同时应用在主机 MCU 上运行。

最初、我计划仅使用星型网络拓扑。 但是、在与一些光开关和调光器集成后、我意识到它们充当 ZR、而其他 ZC 器件正在建立与 ZR 而非 ZC 的链接。 如果未弹出以下案例、则不会出现问题。

  • 正常行为。 ZED 与 ZC 通信时的电池供电门触点。 它配置为向 ZC 报告群集 IAS 区域中的打开和关闭状态。 每当报告打开时、ZC 中的应用程序都会使用默认响应确认打开。 关闭不需要使用默认响应确认。

  • 异常行为。 当 ZC 关闭时、车门触点重新连接到用作 ZR 的其中一个照明开关。 当 ZC 重新联机时、车门触点通过光开关与其通信、有时甚至通过多跳进行通信(请参阅下面的屏幕截图)。 尽管数据被传送到 ZC、但应用程序发送为 AF_DATA_Request 的默认响应不会传送到网络中的器件、因此不会到达门触点。  

同时,通过另一台交换机作为 ZR 发送的交换机的事件将通过默认响应正确确认。

问题的根本原因是什么?如何解决?

我将用于 ZC 的编译标志如下:

SECURE=1
TC_LINKKEY_JOIN
NV_INIT
NV_RESTORE
ZTOOL_P1
MT_TASK
MT_APP_FUNC
MT_SYS_FUNC
MT_ZDO_FUNC
MT_ZDO_Mgmt
MT_APP_CNF_FUNC
MT_UTIL_FUNC
MT_AF_FUNC
MT_AF_CB_FUNC
MT_ZDO_CB_FUNC
xLEGACY_LCD_DEBUG
xLCD_supported=调试
组播启用=假
ZCL_READ
ZCL_WRITE
ZCL_BASIC
ZCL_Identify
xZCL_Scenes
xZCL_GROUP
HAL_LCD=false
HAL_ADC=false
xHAL_UART_DMA_RX_MAX=128
Max_neighber_entions=1
TP2_LEGACY_ZC

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

    是否可以附加监听器日志而不是屏幕截图?

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

    事实上、我在该主题中找到了解决方案:

    https://e2e.ti.com/support/wireless-connectivity/other-wireless/f/667/p/147752/534242?tisearch=e2e-sitesearch&keymatch=AF_DATA_REQUEST_SRC_RTG#534242

    所需的全部操作是将 AF_DATA_REQUEST 中的 Options 字段设置为 AF_DISCV_route (0x20)、此屏幕截图作为参考:

    然后、根据需要将默认响应路由到 ZED。 但是、由于 Z-Stack 监视器和测试 API (SWRA198)包含以下内容、因此文档中存在一些差异:

    而相应的 Z-Stack 3.0.2代码在 AF.h 中包含以下内容:

    #define AF_Wildcard_profileID 0x02 //将强制消息使用通配符 profileID
    #define AF_preprocess 0x04 //将强制 APS 回调到预处理,然后再调用 NWK 层
    #define AF_LIMIT_集中 器 0x08
    #define AF_ACK_REQUEST 0x10
    #define AF_SUpress_route_disd_network 0x20 //对中间路由选择按路由
    //(为启动器件准备的路由发现)
    #define AF_EN_SECURITY 0x40
    #define AF_SKIP_ENLOADCRAT 0x80
    
    #define AF_DISCV_route 0x00 //此选项不再可用,它包含用于向后兼容性
    
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    启用 AF_DISCV_route 后,问题是否得到解决?

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

    不过、以下是监听器日志供您参考:

    e2e.ti.com/.../20200419-_2D00_-Default-Response-routing-issue.zip

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

    是的。

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

    很酷、最好知道它可以解决问题。