CCS/LAUNCHXL-CC26X2R1: Process for adding a third party device to Zigbee coordinator e.g. light example

You can refer to to use install code.

Thank you for the response.

That is a good example that shows how to link two TI units using install codes.

When trying this example we set up the light coordinator with install codes gathered from the QR code of a SmartThings Switch. Then we started the coordinator light example, and did commisioning. Then we activated the switch and we see in the sniffer it started to send out Data Requests and Association Request, but why it does not connect to the network we do not understand.

1st image showing sniffer,

2nd image showing serial monitor in third commission attempt.

Raw data from smartthings button is:

Z:286D9700010873BF$I:33CACCEDEDD543348239B6018A0D9A31196E%SN:690SEA4M6E0418

Code for installation code in coordinator:

* LOCAL VARIABLES
 */
static uint8_t installCode[INSTALL_CODE_LEN + INSTALL_CODE_CRC_LEN] =
    {0x33,0xCA,0xCC,0xED,0xED,0xD5,0x43,0x34,0x82,0x39,0xB6,0x01,0x8A,0x0D,0x9A,0x31,0x19,0x6E};

static uint8_t installCodeAddr[Z_EXTADDR_LEN] =
    {0x28, 0x6D, 0x97, 0x00, 0x01, 0x08, 0x73, 0xBF};

BDB_DEFAULT_JOIN_USES_INSTALL_CODE_KEY is set to TRUE

Any thoughts? 

Can you provide your sniffer log which contains device association and key exchange process?

Yes, see attached from Ubiqua.1033.Smartthings_button_test.txtSmartthings_button_test.csv

1. Debug from CCS

2. Activate pairing on smartthings button

3. Commission from serial Putty to Coordinator.

All packets from above logged in attached file.

Thank you!

Can you attach your Ubuqua .cubx file? You can ZIP it before you attach it.

Hi,

Yes, see attached.

Thank you!

-FredSmartthings_button_test.zip

There is no key exchange process in your sniffer log. Can you factory reset everything to test again and use sniffer to log everything?

Hi,

There are two devices involved:

1. zc_light project from TI SDK

2. Smartthings button

To start everything we rebuild the project,

Start sniffer, then debug it on CC1352 (Rev E) launchpad and in the serial menu in Putty we select "COMMISSION".

Then we insert battery in the Smartthings unit.

Tried two times in the attached capture file.

Also attached project for zc_light

Smartthings_button_test_2.zipzc_light_CC1352R1_LAUNCHXL_tirtos_ccs.zip

Hi Fred,

If the Samsung SmartThings button is based on the Zigbee HA profile then it most likely does not use Install Codes as this is specifically a Zigbee 3.0 feature.  You will also need to make sure that your CC2652R ZC (Zigbee 3.0 profile from SIMPLELINK-CC13X2-26X2-SDK) light project has BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANGE set to FALSE (default) for backwards compatibility.  I believe zigbee2mqtt supports SmartThing devices, and internally we have verified that TI end devices are able to join and operate with a SmartThings hub.  I suppose you will first need to verify the the ZC forms a network on the same channel that the ZED supports.  There is a similar E2E post in this regard and you may find use from checking operation with a sniffer device.

Edit: Some of this information was already covered before this post was published.

Regards,
Ryan

Thanks Ryan.

• According to Samsung FAQ, the Smartthings Button supports Zigbee 3.0 and it features install code on the back QR as you can see from above correspondance.
• Regarding checking whether they are on the same channel, if you see the screenshot above in post #3, does it not confirm they communicate on same channel 11?
  • If not, how would we confirm it?

• Verified that BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANGE was already set to FALSE.

Thank you!

Hi Fredrik,

To root out issue kindly try following scenario.

Try to set  BDB_DEFAULT_JOIN_USES_INSTALL_CODE_KEY to FALSE and see if device able to join and remain connected in network

without install code and BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANGE as FALSE with disabling key exchange as well.

Dhaval

Did another try with BDB_DEFAULT_JOIN_USES_INSTALL_CODE_KEY set to FALSE again. What happens differently now is that the Smartthings button stops sscanning after some time. But it is unclear to me what actually happens.

Any input?Smartthings_button_test_3.zip

Hi Fredrik,

From what I can gather looking through the sniffer log, the SmartThings Button (ZED) completes the Association Request, broadcasts the Device Announce, sends End Device Timeout & Node Descriptor Requests to the ZC, and completes the TC Link Key update.  This confirms that the ZED supports Zigbee 3.0, the ZC is open for joining, install codes are not required, that both devices are on the same channel, and that the ZED successfully joins the ZC's network.  However the device ZED then sends Data Request every quarter second for around a minute, then at seven second intervals for about eight minutes more before ultimately Leaving the network of its own volition and restarting the process with a new short address assignment.  It seems to be waiting for some action from the ZC which never occurs, you may need to consult a SmartThings forum to find the expected hub behavior.

Regards,
Ryan

Hi Ryan,

Thank you for the help so far.

It seems actually the smartthings button connects successfully now, and the break after 8 minutes is when we restarted commissioning and reset the smartthings button.

Does the ZC example have serial commands to show information about the connected device to see and debug that it has a connection?

What we struggle with currently is that the SmartTHings button does not send anything when we click it, after it has successfully connected to our ZC.

Hi Ryan, 

Now, we able to join button with our ZC Light example code using install code.

I have enable Finding and Binding and when I click on commission from serial terminal menu to trigger binding

I can see it able to receive at case zstackmsg_CmdIDs_ZDO_IEEE_ADDR_RSP: as shown in figure in function zclSampleLight_processZStackMsgs().

Here for debug when I put breakpoint at line 1585- Zstackapi_sysNwkInforReadReq() it go into this function.

But, after that it exit from that.

It doesn't executing code below that line which fill and create bind request.

So, question is what could be problem for this issue? 

Is it could be memory issue?

Regards,

Dhaval  

Hi Dhaval,

You will need to provide more debug information (sniffer log, call stack, device behavior, etc) in order to receive any further assistance.  The code shown would only be used in the case that an endpoint with a matching cluster was found on a remote device (i.e. button) at which point the local bind would allow for BDB reporting.  I do not know enough about the SmartThings device to know whether the On/Off Cluster client is supported.  The device would not simply "exit" the middle of a case statement so you need to determine whether it was really executed in the first place or if the device enters a bricked/unknown state.

Regards,
Ryan

Hi Ryan,

I highly appreciate your response in this matter. I am trying to provide as much info as possible.   About device behaviour. What I have observed in code is that it goes into "case zstackmsg_CmdIDs_BDB_NOTIFICATION"  and "case zstackmsg_CmdIDs_BDB_IDENTIFY_TIME_CB" as well.  Sniffer logs attached: log1.cubx

Link listed below is smarthings repo and after reviewing it says it does support and working on off clustor.  

"github.com/SmartThingsCommunity/SmartThingsPublic/blob/bfa22fd629635a45f14b7f9b7266975306bc0e87/devicetypes/smartthings/zigbee-button.src/zigbee-button.groovy"

Optimization level of code is at highest does it could be because of that ? Or Because of interrupt triggered in middle of that case? May be I can call that bind request as separate function to make it sure it executes? 

log1.zip

-

Dhaval

I cannot decrypt the sniffer log since no NWK key is provided, the sniffer must not have captured the commissioning/joining process.  It is possible that the high level of code optimization is causing the erratic debug behavior, you may try turning it off in Properties -> Build -> ARM Compiler -> Optimization.  The sniffer log will also show whether the light application got as far as to send a Match Descriptor Request followed by the IEEE Addr Request to the button.

The purpose of the zstackmsg_CmdIDs_ZDO_IEEE_ADDR_RSP case statement code is to create a local bind so that the light can report its status to a compatible device, in this case the SmartThings button.  If the button does not automatically bind to the light during the F&B process (in order to control the light's status) then you must manually create a bind to be sent to the remote device as well.  This type of functionality is accomplished in the ZIGBEE-LINUX-SENSOR-TO-CLOUD gateway example.

Regards,
Ryan