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.

LAUNCHXL-CC1352R1: Zigbee

Part Number: LAUNCHXL-CC1352R1
Other Parts Discussed in Thread: CC1352R

Hello,

I am using CC1352R REV E boards with SDK 3.10.00.11.

1) I started with the basic examples of ZigBee. I uploaded one board with Zc_doorlock_Controller and another with Zc_doorlock. But I noticed a difference in the way they used to interact in SDK 2.3 and in SDK 3.10.
In the newer version, the doorlock controller is not able to control the doorlock from its terminal. Pressing ‘W’ and ‘S’ won’t show unlock or lock the doorlock terminal and neither on its terminal. It reflects a state on its own terminal but it is always the locked state.

May I know the reason why it is behaving in such a way?

2) I have a doubt regarding the 2nd DMM example provided in ZigBee (dmm_zr_light_remote_display_app). I went through the Readme file of that particular example but I couldn’t understand the Projects used. It has asked to use a ZigBee Light Coordinator (which, if I am not wrong is Zc_Light) in conjunction with dmm_zr_light_remote_display_app. And it has no mention of any other example to be used. So how are 2 Light examples supposed to communicate with each other?

Is it that, this example is an extension/continuation of the previous example (dmm_zed_switch_remote_display_app) or is it a standalone example?

If it is the later can you please suggest me where I am going wrong with the setup?

 

Also, found this line (in the screenshot below) which confused me even more, Do end devices have routing capabilities?  

Can anyone help me in knowing where I am going wrong with this?

Thanks and Regards,

Yash.

  • Hi,

    1.
    Do you mean zc_doorlock_controller and [zr/zed]_doorlock (or vice versa) instead of both as zc?
    To explain the difference in behavior:
    - The doorlock cluster is type 2 (meaning transactions are initiated from server to client).
    - This means that Finding and Binding will create the bind on the doorlock (server) to doorlock controller (client).
    - The doorlock controller must know the address and endpoint of the doorlock it wishes to lock/unlock. This may be done with accomplished with a bind.
    - 2.30 added additional code which created a bind on the doorlock controller to the doorlock.
    - 3.10 changes this so that the bind creation on doorlock controller to doorlock must be initiated in the GUI (this happens through a discoverable/discover feature).
    - Please see the respective READMEs of the examples for more information on this.


    2.
    You are correct, 2 out-of-box light examples can not send on/off/toggle commands to each other. However, regardless of application level implementations, a router can join the network formed by a coordinator (eg dmm_zr_light can join zc_light).
    You can use the dmm_zr with any zc_* example. In this case, we have dmm_zr_light, so for quick evaluation of controlling the dmm_zr_light, perhaps use the zc_sw example.
    Note that you can control the state of the LED on dmm_zr_light either through the app or from a switch in the same Zigbee network.

    Good catch on the typo in "Provisioned Zigbee Light"! You're right, a ZED does not route packets.
    I've notified the team to fix this in the next SDK release.




    Regards,
    Toby

  • Hello Toby,

    Appreciate your quick response.

    1) Yes, I meant [zr/zed]_doorlock with zc_doorlock_controller. I tried the (discoverable/discover feature) and it's behaving the same way now. Thank you for such a detailed explanation.

    2) Okay, I have already tried dmm_zr with the [zc/zed]_switch but, as the guide was a bit confusing in expressing the motive (of the examples used) I thought there was more to it than I was able to understand. Anyways, you made that clear now.

    Thanks and Regards,
    Yash.