SIMPLELINK-CC13X2-26X2-SDK: Commissioning a green power device through ZNP (6.30 SDK)

Hi Ryan,

Thanks for the reply, I checked the resources.

I found out that for the znp_CC26X2R1_LAUNCHXL_tirtos7_ticlang (SimplelinkSDK 6.30) DISABLE_GREENPOWER_BASIC_PROXY is defined. As the name suggests, this disables the GreenPower proxy code. I removed this define but this results in all kinds of compilations errors.

Is the green power proxy supported for the znp project?

All Zigbee 3.0 devices must support GPP functionality one difference is that the ZNP host application would accomplish this, not the ZNP firmware, and this includes the ZNP.  Sink functionality however must be added.

Regards,
Ryan

> All Zigbee 3.0 devices must support GPP functionality, and this includes the ZNP.

This does not seem to be the case for the znp example, by default DISABLE_GREENPOWER_BASIC_PROXY is defined for this project and after removing it compilation is not possible anymore. This is easily reproducible: import e.g. znp_CC26X2R1_LAUNCHXL_tirtos7_ticlang, remove DISABLE_GREENPOWER_BASIC_PROXY from Predefined Symbols, build -> fails. Note that  I'm not interested in sink functionality for the znp, only proxy.

You're right, I typed my response too quickly.  We have already covered this in prior threads:

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

It once again goes back to the host application

Regards,
Ryan

I think I messed up my terminology; I don't want the sink but also not the proxy it seems (if proxy = rebroadcasting of these green power messages). For my use cases I have 2 devices; a CC265R ZNP and a Greenpower device (Hue Tap). Next I trigger a green power "commission" message on the Hue Tap. I would expect now the the ZNP picks up this message and forwards it to the host application via a MT_GP GP_DATA_IND (such that my host application can act upon it accordingly). This is not happening, nothing is send over the serial port.

Thank you for your patience, I can now observe what you are referencing.  Currently, gp_event_loop is removed from zstackstartup.c since DISABLE_GREENPOWER_BASIC_PROXY is defined in ZNP projects. This means that dgp_stub.c will never reach MT_GPDataInd/MT_GPDataCnf so the ZNP will not be notified of GP messages. Removing DISABLE_GREENPOWER_BASIC_PROXY results in GP layer linker issues. Currently you will be unable to build GP functionality on top of your host application since the host will never receive MT GP messages.  I will coordinate with the Zigbee Software Development Team to determine what can be done.

Regards,
Ryan

Thank you for your patience too! It would be great if this functionality can be added.

Out of interest, how could this even work with the Zigbee_3_0_Linux_Gateway_1_0_1 ? I assume for this the ZNP firmware is also used?

I don't fully understand your question, could you please clarify?  The solution would require the ZNP to re-enable MT_GP* messages from the Z-Stack source library so that MT GP messages can be send to the Zigbee Linux Gateway, which has integrated the layer needed to interpret these packets for proxy functionality.

Regards,
Ryan

> The solution would require the ZNP to re-enable MT_GP* messages from the Z-Stack source library so that MT GP messages can be send to the Zigbee Linux Gateway, which has integrated the layer needed to interpret these packets for proxy functionality.

So if I understand correctly, with the Zigbee 3.0 Linux gateway and the current ZNP fw green power messages received by the ZNP are also not forwarded to the gateway? As this would require the same changes as you mentioned before:

> Currently, gp_event_loop is removed from zstackstartup.c since DISABLE_GREENPOWER_BASIC_PROXY is defined in ZNP projects.

The ZNP from SIMPLELINK-CC13XX-CC26XX-SDK v6.30 will not forward green power messages to a host, including the Zigbee Linux gateway. I am not sure which older SimpleLink SDK version would be required to revert these changes.

Regards,
Ryan