[参考译文] SIMPLELINK-CC13X2-26X2-SDK：通过 ZNP 调试绿色电源器件(6.30 SDK)

您好、Ryan、

感谢您的回复、我查看了资源。

我发现  、对于 ZNP_CC26X2R1_LAUNCHXL_tirtos7_ticlang (SimplelinkSDK 6.30)、定义了 DISABLE_GREENPOWER_basic_proxy。 顾名思义、这会禁用 GreenPower 代理代码。 我删除了此定义、但这会导致所有类型的编译错误。

ZNP 项目是否支持绿色电源代理？

>所有 Zigbee 3.0器件都必须支持 GPP 功能、其中包括 ZNP。

对于 ZNP 示例、似乎没有这种情况、默认 情况下为该工程定义了 DISABLE_GREENPOWER_BASIAL_PROXY、并且在删除该工程后无法再进行编译。 这很容易 重现：导入如 ZNP_CC26X2R1_LAUNCHXL_tirtos7_tronicang、从预定义符号中删除 DISABLE_GREENPOWER_BASICE_PROXY、生成->失败。 请注意 、我对 ZNP 的灌电流功能不感兴趣、而只对代理服务器感兴趣。

你是对的、我输入的响应速度太快了。  我们在之前的主题中已经介绍过这一点：

https://e2e.ti.com/f/1/t/856997 
https://e2e.ti.com/f/1/t/1039737 

它再次返回到主机应用程序

此致、
Ryan

我想我把我的术语弄乱了；我不想使用接收器、也不想使用它看起来的代理(如果代理=重新广播这些绿色电源消息)。 对于我的用例、我有2个器件：一个 CC265R ZNP 和一个 Greenpower 器件(Hue Tap)。 接下来、我在 Hue Tap 上触发一条绿色电源"佣金"消息。 现在、我希望 ZNP 收到此消息、并通过 MT_GP  GP_DATA_IND 将其转发到主机应用程序(这样、我的主机应用程序可以相应地对其执行操作)。 这种情况不会发生、串行端口上不发送任何内容。

感谢您的耐心、现在我可以观察您所参考的内容。   目前、gp_event_loop 已从 zstackstartup.c 中删除、因为在 ZNP 项目中定义了 DISABLE_GREENPOWER_BASIAL_PROXY。 这意味着 DGP_STUG.c 永远不会到达 MT_GPDataInd/MT_GPDataCnf、因此不会向 ZNP 通知 GP 消息。 删除 disable_GREENPOWER_basic_proxy 会导致 GP 层链接器问题。 目前、您将无法在主机应用程序上构建 GP 功能、因为主机永远不会收到 MT GP 消息。  我将与 Zigbee 软件开发团队协调以确定可以执行的操作。

此致、
Ryan

感谢您的耐心等待！ 如果可以添加此功能、那将会很好。

出于兴趣，这如何能够与 Zigbe_3_0_Linux_Gateway_1_0_1配合使用 ？ 我假设还使用了 ZNP 固件吗？

我不完全理解您的问题、请您澄清一下吗？  该解决  方案需要 ZNP 重新启用 Z-Stack 源库中的 MT_GP*消息，以便 MT GP 消息可以发送到 Zigbee Linux 网关，该网关集成了解释这些数据包以实现代理功能所需的层。

此致、
Ryan

> 该解决  方案需要 ZNP 重新启用 Z-Stack 源库中的 MT_GP*消息，以便 MT GP 消息可以发送到 Zigbee Linux 网关，该网关集成了解释这些数据包以获得代理功能所需的层。

那么、如果我理解正确、对于 Zigbee 3.0 Linux 网关、ZNP 接收到的当前 ZNP FW 绿色电源消息也不会转发到网关？ 因为这需要与您之前提到的相同的更改：

> 目前、gp_event_loop 已从 zstackstartup.c 中删除、因为在 ZNP 项目中定义了 DISABLE_GREENPOWER_basic_proxy。

SIMPLELINK-CC13XX-CC26XX-SDK v6.30中的 ZNP 不会将绿色电源消息转发到主机、包括 Zigbee Linux 网关。 我不确定需要哪个较旧的 SimpleLink SDK 版本来恢复这些更改。

此致、
Ryan