• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 57 subscribers
  • Views 232 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2652P: Can gpd_switch and zr_light_sink join ZNP coordinator to work each other?

YiKai Chen
Guru 735455 points
Part Number: CC2652P

We use CC2652P as ZNP with our own host to act as coordinator.Can gpd_switch and zr_light_sink join ZNP coordinator to work each other?   If yes, can you provide steps to test this? For example, using ZTOOL with ZNP as coordinator to work with gpd_switch and zr_light_sink?

  • 0
    TI__Guru**** 202136 points

    Hi YiKai,

    This should be possible with the ZNP acting as ZC and GP proxy for the GP source (gpd_switch) and GP sink (zr_light_sink) without any modifications.  Have you followed the CUI commissioning instructions from the gpd_switch and zr_light_sink READMEs?  Please also refer to the GP Application section of the Z-Stack User's Guide and provide a sniffer log if you continue to experience commissioning issues.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Guru 735455 points

    can turn ZNP coordinator into GP sink. If Yes, how to do it?

  • 0 in reply to Ryan Brown1
    Genius 6000 points

    Hi Ryan,

    My test is showing below(sniffer for your reference),

    1. ZNP create network as ZC

    2. zr_light_sink enable GPS commissioning and join ZC

    3. gpd_switch pair with zr_light_sink

    4. zr_light_sink disable GPS commissioning

    5. gpd_switch send on/off command

    We can see gpd_switch broadcasts on/off command and zr_light_sink receives those command. Since gpd_switch broadcasts on/off command, shouldn't nearby ZC (with GP proxy capability) re-broadcast those commands? Do we miss or misunderstanding anything ?

    20210928_GP.zip

  • +1 in reply to Kimi Hu
    TI__Guru**** 202136 points

    Hi Kimi,

    Thanks for the additional information.  I was able to reproduce the same from my end.  I found that the ZNP project defines DISABLE_GREENPOWER_BASIC_PROXY, hence GP notifications will not be forwarded from the ZC.  The GP proxy implementation lies on the application so it would be the host's responsibility to interpret MT GP APIs from the GP stub layer of the ZNP to command the re-broadcasting of ZCL GP notifications.

    Hello YiKai,

    GP Sink functionality is specific to the Zigbee application as well, thus this should be performed from the gateway.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Guru 735455 points

    can you provide steps on host side to implement GP functionality?

  • 0 in reply to YiKai Chen
    TI__Guru**** 202136 points

    I haven't tried this personally, but the ZIGBEE-LINUX-SENSOR-TO-CLOUD does offer MT_GREENPOWER command processing and you could compare sink vs non-sink light application examples and Adding Green Power Sink instructions from the Z-Stack User's Guide.  But this is no minor change/effort and TI does not have an out-of-box demo to provide for this functionality at the moment.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Guru 735455 points

    Can you elaborate which source file in ZIGBEE-LINUX-SENSOR-TO-CLOUD offers MT_GREENPOWER command processing?

  • 0 in reply to YiKai Chen
    TI__Guru**** 202136 points

    Inside znp_misc.c, handleAsyncMsgs has a MT_RPC_SYS_GP subsystem which handles MT_GP* cases.  Using incoming GP Data Indicators as an example, this creates a GP_INCOMING_DATA_IND_CMD event for processGpDataIndMsgInd in zstackpb.c followed by a ZSTACK_CMD_IDS__GP_DATA_IND_INCOMING_MSG which executes processGpDataIndMsgInd in gatewaysrvr.c.  This ultimately leads to GP_DataInd from gp_common.c to be processed by the application accordingly, including GP_ProccessNotification -> zclGp_SendGpNotificationCommand.

    Regards,
    Ryan