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]

Hello Edvin,

Any updates?

[Edvin]

Hello, 

With the main.c files that you sent me, the bulb and switch will join the network, and the switch can control the light bulb. However, Is that not what you see?

However, it is the bulb that initiate this in your project in the ZB_BDB_SIGNAL_DEVICE_REBOOT event. 

zb_err_code = ZB_SCHEDULE_ALARM(find_light_bulb, param, MATCH_DESC_REQ_START_DELAY); ->

zb_zdo_match_desc_req -> find_light_bulb_cb, and this will set the address and andpoint for the bulb. This address and endpoint is used directly in the button event handler buttons_handler(). Do you want me to remove the find_light_bulb call:

zb_err_code = ZB_SCHEDULE_ALARM(find_light_bulb, param, MATCH_DESC_REQ_START_DELAY);?

[Angry_Oatmeal]

Hello Edvin,

Edvin said:

With the main.c files that you sent me, the bulb and switch will join the network, and the switch can control the light bulb. However, Is that not what you see?

I agree the bulb and switch will join the network without a problem. I am seeing this myself and that part is working as expected.

Edvin said:

However, it is the bulb that initiate this in your project in the ZB_BDB_SIGNAL_DEVICE_REBOOT event. 

I'm a bit confused. I don't understand how the bulb initiates "this" from its ZB_BDB_SIGNAL_DEVICE_REBOOT event, could you please elaborate? From what I understand, the ZB_BDB_SIGNAL_DEVICE_REBOOT event on the bulb calls the bdb_start_top_level_commissioning(ZB_BDB_NETWORK_STEERING); function, which allows the bulb to join the network.

The ZB_BDB_SIGNAL_DEVICE_REBOOT event on the switch however, goes through the steps you mentioned as: 

zb_err_code = ZB_SCHEDULE_ALARM(find_light_bulb, param, MATCH_DESC_REQ_START_DELAY) -> zb_zdo_match_desc_req -> find_light_bulb_cb.

Edvin said:

Do you want me to remove the find_light_bulb call

I don't think there will be any need for that, unless it can help with my finding and binding issues.

Again, just to reiterate my issue. The normal operation of the light control examples works perfectly, there are no issues there. The issue comes from the added zb_bdb_finding_binding_target() and zb_bdb_finding_binding_initiator() functions. The rest of the code operates fine, it is simply this add-on feature which is not working as expected.

If I call zb_bdb_finding_binding_target() on the bulb, then call zb_bdb_finding_binding_initiator()  on the switch, everything works fine, and when I check the switch's binding table, I can see the bulb there. Perfect.

However, if I reverse this, and call zb_bdb_finding_binding_target() on the switch, then call zb_bdb_finding_binding_initiator() on the bulb, the switch is not able to bind to the bulb. In fact nothing actually happens. This is my primary issue.

Would it perhaps help if I opened up a private support ticket for this issue? It seems this might need some more looking into than a quick forum post.

Thank you,
Angry Oatmeal

[Edvin]

Hello,

 

Angry_Oatmeal said:

The ZB_BDB_SIGNAL_DEVICE_REBOOT event on the switch however, goes through the steps you mentioned as: 

zb_err_code = ZB_SCHEDULE_ALARM(find_light_bulb, param, MATCH_DESC_REQ_START_DELAY) -> zb_zdo_match_desc_req -> find_light_bulb_cb.

 I am sorry. I meant the switch, not the bulb. My point was that if this is not removed, then this will create the binding, regardless of the zb_bdb_finding_binding_target/initiator(). 

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

Best regards,

Edvin

[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.