Reverse finding and binding role, initiator and target.

RE: Reverse finding and binding role, initiator and target.

Angry_Oatmeal — Mon, 30 Mar 2020 10:38:19 GMT

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

RE: Reverse finding and binding role, initiator and target.

Edvin — Tue, 24 Mar 2020 10:52:07 GMT

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.

RE: Reverse finding and binding role, initiator and target.

Edvin — Fri, 13 Mar 2020 11:29:33 GMT

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

RE: Reverse finding and binding role, initiator and target.

Angry_Oatmeal — Mon, 09 Mar 2020 08:20:18 GMT

Hi Edvin,

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

Thanks,
Angry Oatmeal

RE: Reverse finding and binding role, initiator and target.

Angry_Oatmeal — Thu, 20 Feb 2020 14:58:19 GMT

Hi Edvin,

[quote userid="26071" url="~/f/nordic-q-a/57197/reverse-finding-and-binding-role-initiator-and-target/235346"]My point was that if this is not removed, then this will create the binding, regardless of the zb_bdb_finding_binding_target/initiator(). [/quote]

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.

[quote userid="26071" url="~/f/nordic-q-a/57197/reverse-finding-and-binding-role-initiator-and-target/235346"]Let me check with our Zigbee team. Perhaps they know why it doesn't work.[/quote]

I'd appreciate that very much, thanks 😄

Best Regards,
Angry Oatmeal.

RE: Reverse finding and binding role, initiator and target.

Edvin — Thu, 20 Feb 2020 08:35:05 GMT

Hello,

[quote user="Slim_Jim_Larry"][/quote]

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

RE: Reverse finding and binding role, initiator and target.

Angry_Oatmeal — Wed, 19 Feb 2020 10:24:56 GMT

Hello Edvin,

[quote userid="26071" url="~/f/nordic-q-a/57197/reverse-finding-and-binding-role-initiator-and-target/234847"]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?[/quote]

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.

[quote userid="26071" url="~/f/nordic-q-a/57197/reverse-finding-and-binding-role-initiator-and-target/234847"]However, it is the bulb that initiate this in your project in the ZB_BDB_SIGNAL_DEVICE_REBOOT event. [/quote]

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.

[quote userid="26071" url="~/f/nordic-q-a/57197/reverse-finding-and-binding-role-initiator-and-target/234847"]Do you want me to remove the find_light_bulb call[/quote]

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

RE: Reverse finding and binding role, initiator and target.

Edvin — Tue, 18 Feb 2020 10:22:49 GMT

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);?

RE: Reverse finding and binding role, initiator and target.

Angry_Oatmeal — Mon, 17 Feb 2020 08:00:56 GMT

Hello Edvin,

Any updates?

RE: Reverse finding and binding role, initiator and target.

Angry_Oatmeal — Tue, 11 Feb 2020 11:29:14 GMT

Hello Edvin,

Just as another side note, I found the the reason for the crash on multiple zb_bdb_finding_binding_initiator() calls.

It was occurring due to the second call returning an error 4 (RET_BUSY). For some strange reason, the ZB_ERROR_CHECK(zb_err_code) was not catching this, and causing the system to freeze. The solution is strange so maybe you could shed some light on it.

The fix was to delete the NRF_LOG_INFO("Bulb Initiator") on line 363. Once this is deleted, the error check fires normally, and I can catch the error and deal with it appropriately using the below code:

        zb_err_code = zb_bdb_finding_binding_initiator(HA_DIMMABLE_LIGHT_ENDPOINT, finding_binding_cb);
		if(zb_err_code == RET_BUSY)
		{
		    NRF_LOG_INFO("initiator is busy, cancel");
		    zb_bdb_finding_binding_initiator_cancel();
		}

Just thought you should know,
Angry Oatmeal.

RE: Reverse finding and binding role, initiator and target.

Angry_Oatmeal — Mon, 10 Feb 2020 08:58:39 GMT

Hello Edvin,

Find attached both main.c files. I've named them according to their function.

For main_bulb.c the primary changes made are on line 359 - 365.

devzone.nordicsemi.com/.../main_5F00_bulb.c

For main_switch.c the primary changes made are on line 447 - 456.

devzone.nordicsemi.com/.../main_5F00_switch.c

Hope this helps,
Angry Oatmeal.

RE: Reverse finding and binding role, initiator and target.

Edvin — Fri, 07 Feb 2020 12:53:07 GMT

Hello Mr/Ms Angry 🙂

Is it possible to send the projects that you have used so that I can try to replicate this? If you didn't change anything other than main.c, then you only need to send those (please name the two main.c files differently, because there is a bug in devzone that will only allow one file with a specific name per ticket).

If you have changed things outside the main.c file, please zip the project folder. If it is too big to upload, delete the build folders, and it should be just fine.

Best regards,

Edvin

RE: Reverse finding and binding role, initiator and target.

Angry_Oatmeal — Fri, 07 Feb 2020 09:11:23 GMT

Hello Edvin,

Just as an added note, I've tried to manually bind the switch the bulb using the Zigbee CLI in coordinator mode.

Using the zdo bind on command followed by the zdo mgmt_bind command, I was able to bind the bulb to the switch and check the switch's binding table to find the bulb (as usual) but I was also able to bind the switch to the bulb, and read the binding table on the bulb to find the switch listed there, as expected.

It seems then that there is nothing stopping the switch being bound to the bulb, and that the issue might be the the zb_bdb_finding_binding_initiator()/zb_bdb_finding_binding_target() functions.

The plot thickens,

Angry Oatmeal.

RE: Reverse finding and binding role, initiator and target.

Angry_Oatmeal — Thu, 06 Feb 2020 15:01:19 GMT

Hello Edvin,

I have a callback function ready for the initiator as below. Unfortunately, the bulb never enters this callback function. It simply acts as though nothing has occurred.

static zb_bool_t finding_binding_cb(zb_int16_t status, zb_ieee_addr_t addr, zb_uint8_t ep, zb_uint16_t cluster)
{
    NRF_LOG_INFO("Entering finding_binding_cb");
    NRF_LOG_INFO("status: %d", status);
    NRF_LOG_INFO("addr: %X", addr);
    NRF_LOG_INFO("ep: %d", ep);
    NRF_LOG_INFO("cluster: %d", cluster);
    return ZB_TRUE;
}

A point though about my previous comment concerning the lack of errors in the bulb. While the bulb and switch continue to operate normally after calling zb_bdb_finding_binding_initiator() on the bulb, if zb_bdb_finding_binding_initiator() is called twice in a row, the bulb freezes. The bulb will no longer respond if zb_bdb_finding_binding_initiator() is called a 3rd time, and will no longer receive any ON/OFF commands from the light switch. Once this freeze occurs, checking on WireShark reveals the bulb is truly frozen, as It no longer responds to the coordinator's Link Status request, and does not respond to a zdo match_desc() command from the coordinator CLI. A reset is the only option at this point.

This might be a good time to ask a higher-level question regarding this project. I am trying to implement a scenario where the coordinator can regularly check the topology of the network. By scanning the binding tables of all router devices, the coordinator will be able to form a table of what devices are connected to each other. The reason I am trying to have the binding table on the bulb/router as opposed to the switch/end device, is the because the light switch will be a low power energy harvesting device, hence powered down most of the time, until it is pressed. Other than what I am trying to do now, do you think there are better ways to implement this?

Thank you,
Angry Oatmeal

RE: Reverse finding and binding role, initiator and target.

Edvin — Wed, 05 Feb 2020 14:56:05 GMT

Ah, ok. I see it in SDK3.2.0, but couldn't find them in 4.0.0. I guess they are changed.

Ok, so when you switch them around, you can't operate the light bulb from the light switch. Did you check the callback function for zb_bdb_finding_binding_initator()?

zb_ret_t zb_bdb_finding_binding_initiator(zb_uint8_t endpoint, zb_bdb_comm_binding_callback_t user_binding_cb);

Can you try to provide a callback function to this call, and check the status in the callback (if the callback is called)?

Also, what is the addr, ep, cluster. and does it help if you return true in this callback?

BR,

Edvin

RE: Reverse finding and binding role, initiator and target.

Angry_Oatmeal — Mon, 03 Feb 2020 13:15:51 GMT

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.

devzone.nordicsemi.com/.../Wireshark_5F00_Working.pcapng

devzone.nordicsemi.com/.../Wireshark_5F00_Not_5F00_Working.pcapng

RE: Reverse finding and binding role, initiator and target.

Edvin — Fri, 31 Jan 2020 16:04:12 GMT

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?

[quote user=""]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. [/quote]

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?