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.

关于CC2652 GreenPower 没有触发GP Pairing

【问题描述】

使用3块LP2652(芯片版本E) ,使用3.10版本协议栈

三块开发板分别烧录: light sink 、generic(路由)、gpd sw工程 

首先,根据开发文档先将sink 和 generic 路由设备组网, 然后在sink端enable commissioning (sink设备界面显示的是GP Proxy commissioning与文档有些出入),sniffer中能够看到 协调器和路由广播了mgmt permit 消息;

然后,gpd端触发 gpdf的(onOff)命令,sniffer中没有观察到后续的GP Pairing过程。

问题可能出现在哪里?

另外,看到相关文档提到,ti的sdk不支持direct mode,如果想在GPP端检查是否 收到GPDF数据应该,是否有专门的消息通知位置?

  • 另外,ti开发文档给出的sniffer截图,根据规范描述应该是direct mode下的配对过程,开发文档要求网络中GPP的设备是否多余?还是文档未更新至目前SDK 3.10?
  • 你有按照文档操作吗?是可以进行GP Pairing的。

    关于 GPP是一个router 做中继的:

  • 此外你的第二个问题是说MAC CONFIRM?:
    MAC Data Confirm callback:dataCnfCB
  • 还是说Notification callback:
    /*********************************************************************
    * @fn zclGp_GpNotificationCommandCB
    *
    * @brief Callback from the ZCL GreenPower Cluster Library when
    * it received an Gp Notification Command for this application.
    *
    * @param pCmd - command payload
    *
    * @return none
    */
    void zclGp_GpNotificationCommandCB( zclGpNotification_t *pCmd )
  • GPD-> Green Powerframe transmitted to proxy node (GPP)->Green Power frametunnelled in ZigBee framethrough network to sink node->(GPS)
  • Hi, chen,

    1. 是按文档操作, 但操作过程中看到 sink 的UI显示 GP Proxy commissioning ,这个显示有些异常,sink工程里看,是将sink定义了Combo设备,后面会跟踪下是否执行了 sink GP相关过程。
    1.1 按道理官方工程编译完,应该不至于让进行调试,咱那边是否收到其他人反馈的类似问题?

    1.2 sink工程中的Combo编译选项是否该工程真的具备Combo(target + proxy)的功能?

    2. 问题二是指这个zclGp_GpNotificationCommandCB( zclGpNotification_t *pCmd )

    3Q。
  • 你是说ENABLE_GREENPOWER_COMBO_BASIC?
    这宏定义说了该设备具备了传统的ZigBee设备以及GP的功能。
  • 至于你的说的问题没有出现请看:

    首先你GPS(ZR)要先入网,或者你的GPS(ZC)已经和ZR组建了网络。

    然后再APP MENU里面打开GP commissioning。

    然后GPD发送命令即可。

    请看我下面的是测图:

  • 这个编译选项,在sink工程中,与其api调用是 sink + proxy, zc light sink工程默认情况下是gp中的什么角色(target? target+? combo?)

    如果是为了区分zigbee 和GP的混合或独立功能,有GPC 和 GPC m,使用GP combo太容易引起歧义。
  • 应该是操作问题了,一直是 在UI里打开的 GP Proxy commission ,没进入 App Menu - GP Sink commission进行操作。
  • 既然sink 支持 GP Proxy 和 Sink的功能,他应该属于GP combo设备(支持direct mode),一会测试确认下
  • 扮演的SINK和传统的basic的zigbee 设备,发过来的GPDF command 是被zclGp_GpNotificationCommandCB处理的,而basic的ZCL命令是被
    zclSampleLight_GPSink_Toggle处理的,这个宏的定义就说明这个不但具备GP功能也具备Basic。
    你对这个编译选项不理解可以看下面的文档:
    dev.ti.com/.../zstack3.1.0-to-zstack3.2.0.html
  • 我这边enable   GP  sink commissioning后,直接由Proxy(路由)设备来启动 而 非0x0000(sink设备)发出GP pairing。

    然后  按下GPD按键 可以对 Sink 上的指示灯进行控制(该种方式是direct mode, zc light snik工程默认情况下设备类是target+ 或  combo设备)。

    【问题1】看能否帮确认下,zc light snik工程默认情况下设备类是什么GP设备?

     【问题2】目前测试情况看,当新GPD设备存在  GP Proxy设备 和  Target+或Combo 设备时,多次测试都是这种direct 模式,还没建立成功通过Proxy路由设备进行消息翻译来完成对灯的控制链路,咱那边能够给出更详细的操作过程?

    3Q

  • 我这边测试的情况 是有0x0000(sink)设备发出的GP Pairing ,说反了
  • zc light snik 是SINK ,不具备GPP。

    第二个问题:

  • 问题1: 网络中仅存在zc light sink, gpd配对后能够直接对sink进行控制,如何查询设备的GP类型?

    问题2:

         我这边是 sink  在进入commissioning 界面 - 按键触发commissioning - 建网成功

    → generic 路由设备上电 -  按键启动路由设备进入commissioning ,入网成功

    →进入sink的【app menu】- 【PG Sink Commission】切换成enable状态

    →触发GPD设备发送GPDF, sink设备发送 GP Pairing 和 dev Annce

    →sink设备上disable commissioning状态

    →然后可以通过GPD设备的左右按键对Sink上的红灯进行量灭操作。

     咱那边能否提供更详细的具体的操作过程? 3Q

  • 不能贴这个文档, 详细的关于GP的文档实在zigbee alliance 下载的:
    https://www.zigbee.org/
  • 文档的话这边应该都有,方便的话看能否私信下名称,这边会让相关同事去下载。

    更详细的的操作指  3个2652设备操作组网、进行GP配对 及 控制过程 ;

    我这边一直无法组建咱们那边tunnel mode方式的通讯链路,想看下是哪个步骤有差异, 3Q。

    另外,ZStack中是否有查询GP设备类型的API?

  • 对于设备类型我们是做的不同的库在建立工程的时候就完成的。对于tunnel mode是这样的规则:
    tunnel mode:GPP 可以 tunnel GPDFs 但是不是最终的接收者。

    如果你想route GPDF 你可以加一个 zr_genericapp 作为 GPP 他将转发。你可以看见我上面的包我的ZC(gpp)0X0000设备是个basic的ZC他在转发GPDF。
    公开文档只有这个:file:///C:/ti/simplelink_cc13x2_26x2_sdk_3_10_00_53/docs/zigbee/html/zigbee/gpd_application_overview.html#send-green-power-data-frames
  • 我这边对3个设备做如下 操作(始终是direct mode):
    sink 在进入commissioning 界面 - 按键触发commissioning - 建网成功

    → generic 路由设备上电 - 按键启动路由设备进入commissioning ,入网成功

    →进入sink的【app menu】- 【PG Sink Commission】切换成enable状态

    →触发GPD设备发送GPDF, sink设备发送 GP Pairing 和 dev Annce

    →sink设备上disable commissioning状态

    →然后可以通过GPD设备的左右按键对Sink上的红灯进行量灭操作。

    能否帮看下,整个过程,哪个步骤跟咱那边的操作有差异? 3Q
  • 按照所说的操作过程,在zr_genericapp中增加调试打印信息 并 增加通过按键来切换 gp_SetProxyCommissioningMode状态功能;

    在GPD设备发送GPDF数据前,将proxy设备切换成gp_SetProxyCommissioningMode = true, 从打印信息上看,proxy设备能否发出gp commission notification(规范文档描述的流程:proxy在处于commissioning状态下,在发出gp commission notification消息前 ,会对proxyTable进行检查,如果proxyTable中无该设备条目信息,会创建一个条目,代码执行流程中仅看到对proxy进行查询并没有创建相关条目),整个操作过程最终仅能对sink协调器建立direct mode方式控制链路。

    目前这边使用的SDK版本为3.10 ,详细的操作步骤如最后描述,要建立tunnel mode的控制链路使用的SDK和上述操作过程是否有问题?

    另外,在评估过程中,引入一个芯科的 combo(具备proxy能力) 路由设备, 对sink (2652)、 proxy(芯科)、gpd(2652),重复上述操作过程,能够建立tunnel mode的控制链路。
  • 你的设备始终无法向我前面的回帖一样去route GP Data Frames?
  • gpd 和 sink配对完成后, proxy的路由设备里中的proxyTable应该没有gpd和sink的对应条目信息,设备都退出commissioning模式后,gpd发送on/off控制命令直接发给sink设备,尝试多次配对2652设备都没出现过,proxy 路由设备进行转发GPDF现象。

    我这边的整个操作过程和你那边是否有差异?

  • 请看我的设备是会router GPDF的。

    我目前看出来你的问题处在哪里,你的GPP好像也没有pairing 成功吧。

    pairing如果你的GPP 转发     zclGp_GpSuccessNotificationProcess 会更新一个新的proxy table。

  • zclGp_GpSuccessNotificationProcess() 是在gp_sink中实现的,zr_genericapp工程仅是proxy设备没有该函数的实现:
    zr_genericapp工程仅在gp_dataIndProxy()中对该comandId做了通用性的处理,没有添加条目至ProxyTable的操作(我这边手动添加?)

    感觉咱们两个用的不是同一个版本的sdk 或者 你对sdk做修改了?
  • 你好,我真的无法复现。。
    找了个同事帮你看看
    你提供一下抓包文件回复下面的帖子:
    e2e.ti.com/.../802582
  • 看能否提供下 你那边的 zr_genericapp    proxy 路由设备的固件? 3Q

  • 不方便上传这类文件,请把你的一些detail的操作回复到我发的那个帖子,我会和同事在那个帖子帮你跟进。
  • 已在那个帖子中做更新,3Q
  • 你好,还在关注吗?

    这个问题已经在新的SDK里面被修复。
    请使用3.20SDK.
    ZIGBEE-402 Green Power Proxy not tunneling GPDFs under certain conditions
  • 3Q

    目前用的其他方案,后续有机会再看了。