Reverse finding and binding role, initiator and target.

[Angry_Oatmeal]

Hello,

Originally, the Zigbee light_control examples ships with a bulb that can call the zb_bdb_finding_binding_target() function, and a light switch that calls zb_bdb_finding_binding_initiator() function. This allows the light switch to add the bulb to its binding table. Here are the corresponding WireShark packets, which shows the Simple Descriptor Request being sent using the Zigbee ZDP protocol. The request is sent from the switch to the bulb.

I am now trying to implement the reverse. Have the light switch call zb_bdb_finding_binding_target(), then call zb_bdb_finding_binding_initiator() on the bulb, in order to have the bulb add the switch to its binding table. 

However, this does not work. I am using the CLI example in coordinator mode to query the bulb using the zdo mgmt_bind 0xXXXX command to see if there are any entries in the bulbs binding table, but it consistently shows the binding table to be empty.

There are no errors thrown inside the bulb or the switch, and the entire system (joining network, turning bulbs on and off, etc.) works just fine. One possible clue is when using WireShark, I can can see the bulb is never able to send the Simple Descriptor Request that is sent during a normal interaction. Instead, a default response is sent indicating an unsupported cluster. In addition to this, it is not being sent via the Zigbee ZDP protocol, but is instead using Zigbee HA.

I was wondering if you could help me with this dilemma, and hopefully point me in the correct direction.

Thank you,
Angry Oatmeal

[Edvin]

Hello Angry Oatmeal,

I thought I should look into this. What SDK version are you using? I couldn't find that the bulb nor switch called any of these functions. Is this something you have added?

 

There are no errors thrown inside the bulb or the switch, and the entire system (joining network, turning bulbs on and off, etc.) works just fine.

 Is ERASE_PERSISTENT_CONFIG set to ZB_TRUE or ZB_FALSE when this happens? Are you sure that this is not caused because of previous network settings in the devices? This information is stored in flash, and will not by default be erased when you reprogram the application. Only if you erase all the flash (nrfjprog -e) or set ERASE_PERSISTENT_CONFIG to ZB_TRUE.

Also, is it possible to send the sniffer trace as a pcapng file?

[Angry_Oatmeal]

Hello Edvin,

Sorry, I should have been more clear. I am using the Thread and Zigbee SDK v3.2.

The zb_bdb_finding_binding_target() does exist in the light bulb code in the SDK version I have. For me, it is located on line 350 (line 12 in the below snippet)

static void buttons_handler(bsp_event_t evt)
{
    zb_ret_t zb_err_code;

    switch(evt)
    {
        case IDENTIFY_MODE_BSP_EVT:
            /* Check if endpoint is in identifying mode, if not put desired endpoint in identifying mode. */
            if (m_dev_ctx.identify_attr.identify_time == ZB_ZCL_IDENTIFY_IDENTIFY_TIME_DEFAULT_VALUE)
            {
                NRF_LOG_INFO("Bulb put in identifying mode");
                zb_err_code = zb_bdb_finding_binding_target(HA_DIMMABLE_LIGHT_ENDPOINT);
                ZB_ERROR_CHECK(zb_err_code);
            }
            else
            {
                NRF_LOG_INFO("Cancel F&B target procedure");
                zb_bdb_finding_binding_target_cancel();
            }
            break;

        default:
            NRF_LOG_INFO("Unhandled BSP Event received: %d", evt);
            break;
    }
}

However, the zb_bdb_finding_binding_initiator() was added by myself in the light switch. Again, this setup works just fine. It is only when switching the functions around on both devices that abnormal behavior starts popping up.

ERASE_PERSISTENT_CONFIG is set to ZB_TRUE on both the light switch and the light bulb, as per the default settings in the shipped examples.

Find attached both pcapng files of the working and non-working wireshark frames. The start of both files is just the switch and bulb joining the newly formed network after the coordinator comes online. The final burst of frames in both files is the find_and_bind function call.

Wireshark_Working.pcapng

Wireshark_Not_Working.pcapng

[Angry_Oatmeal]

Hi Edvin,

Edvin said:

My point was that if this is not removed, then this will create the binding, regardless of the zb_bdb_finding_binding_target/initiator(). 

I don't think this is the case. If I leave the switch as normal and allow it to find the bulb by executing the zb_zdo_match_desc_req() function, it is able to find the address and endpoint of the bulb and adds it to its m_device_ctx.bulb_params.short_addr and m_device_ctx.bulb_params.endpoint variables respectively.

However, this only seems to be a case of storing the bulb's address and endpoint in a variable, and not "binding" it. The reason I say this is because If I run the zdo mgmt_bind command from the CLI coordinator and send it to the switch, the switch's binding table does not show the bulb it just found. This binding table will only be filled when we go through the zb_bdb_finding_binding_target/initiator() procedure, and won't be filled by the zb_zdo_match_desc_req() procedure. 

Nevertheless, I commented out parts of my code to prevent the switch from calling the zb_zdo_match_desc_req() function, and then tried to call the zb_bdb_finding_binding_target() on the switch, and the zb_bdb_finding_binding_initiator() on the bulb. As expected, everything stayed exactly the same, with the switch being unable to bind to the bulb.

Edvin said:

Let me check with our Zigbee team. Perhaps they know why it doesn't work.

I'd appreciate that very much, thanks  

Best Regards,
Angry Oatmeal.

[Angry_Oatmeal]

Hi Edvin,

Any news on this? Have you consulted the Zigbee team?

Thanks,
Angry Oatmeal

[Edvin]

Hello,

I am sorry. I haven't heard from my internal ticket yet. I will ping it, and hopefully get a reply soon (they are in another country, so I can't just walk over to their office).

[Edvin]

Reply from our Zigbee team:

The short answer:

• I was able to reproduce the issue both on SDKv3.1 and SDKv4.1.
• If you generate ZCL client commands, you should implement ZCL client cluster.
• If you add the Identify client cluster to you device's cluster list, the Finding&Binding procedure works perfectly well.
  For example, copy/modify the ZB_HA_DECLARE_DIMMABLE_LIGHT_CLUSTER_LIST macro by adding the following item at the end of the list:

    ZB_ZCL_CLUSTER_DESC(          \
      ZB_ZCL_CLUSTER_ID_IDENTIFY, \
      0,                          \
      NULL,                       \
      ZB_ZCL_CLUSTER_CLIENT_ROLE, \
      ZB_ZCL_MANUF_CODE_INVALID   \
    ) 

When it comes to topology questions:

• Zigbee network may be considered as star topology networks (ZR - center/star, ZED/SED leafs/planets), connected with a full mesh (between both ZRs and ZR-ZC).
• If you want to draw the topology, please take a look at the zdo mgmt_lqi CLI command - it prints out the neighbor table of a selected node.

If you are targeting not the network topology, but sort of "application" topology, meaning which device controls which, you should draw:

• Connections based on binding tables (the command to read it was already mentioned inside the ticket).
• Grouping, by reading APS groups from each endpoint on each device (this covers switches that turn off/on the whole room/floor/building).
• This still will not cover manufacturer-specific ways of making connections between devices (such as match descriptor request/response-based).

When it comes to finding and binding:

• The idea of it is to provide an easy way of binding client clusters to server clusters (for example On/Off client a.k.a. switch with On/Off server a.k.a. light bulb).
• The procedure on an initiator device (usually the one that controls, e.g. light switch) is triggered manually.
• The selection of the target devices (e.g. light bulb) is by putting it into identify mode (this is quite obvious in case of lightning - you look for a bulb to control by sending identify command and checking which one starts blinking. One you find the right one, you initiate the initiator to bind with it).
• The bulb does not know if the switch was bound. It only knows that it was identifying and that someone queried for the identify state. The binding status may be queried only by reading out the binding table from the switch.

The usage of Finding&Binding procedure is presented in Multiprotocol Light Switch with NUS example (F&B initiator, sending Identify commands).
Reading binding tables, as well as neighbor tables is implemented in Zigbee CLI example.

[Angry_Oatmeal]

Hi Edvin,

Thank you so much for this response, it is extremely detailed and provides the answers I need.

I will give these a try and and let you know how they go.

Thank you,
Angry Oatmeal