Zigbee Router device sometimes joins to 0x0000000000000000 network after factory reset

[pjbuntinx]

I am using NRF Connect SDK v2.5.2. Sometimes, after I factory reset my Zigbee router device, it will immediately join a network with PAN ID 000000000000. I get this with my project but also with the light_bulb sample. How can I prevent my device from doing this? Below you can view the logs. Just before the logs, the button was held to factory reset the device. The device had not joined a network before resetting. 

Many thanks,

Pieter-Jan

Fullscreen

1

2

3

I: Network left (leave type: 0)

I: Joined network successfully (Extended PAN ID: 0000000000000000, PAN ID: 0xffff)

I: Network rejoin procedure stopped.

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

I: Network left (leave type: 0)
I: Joined network successfully (Extended PAN ID: 0000000000000000, PAN ID: 0xffff)
I: Network rejoin procedure stopped.

[AHaug]

Hi

Sometimes, after I factory reset my Zigbee router device, it will immediately join a network

Could you clarify the following when you say "a network":

Do you have multiple networks up, i.e is it a random network it joins? Is it establishing a new network that the router joins?

Do you have a sniffer trace for the device throughout the procedure you describe? 

The log also says I: Network rejoin procedure stopped. Indicating that the rejoin procedure stops

Kind regards,
Andreas

[pjbuntinx]

This happens with or without a coordinator in the proximity. When it is, It does not matter whether the coordinator is allowing new devices or not. The network the device joins is not one that should be existing.
This is not applicable to the light bulb example, but for my own device's code, I am using install_codes. So, it should normally not be possible to join another network without having the correct install code added to the coordinator. 

[pjbuntinx]

Hi AHaug 

Do you perhaps have any update on this?

Kind regards,
Pieter-Jan

[AHaug]

Hi Pieter-Jan,

The latest update I received from the Zigbee team is they are working with testing and recreating the behaviour reported. I will try to update you before the weekend with any results and/or follow up questions from the team.

Thank you for your patience and kind regards,
Andreas

[AHaug]

Hi again,

The team verifies that the issue is reproducible and they are working on testing a suggested fix and to integrate it. If the test passes it will be targeted for NCS 2.9.0, which should be estimated release some time in Q1 2025. 

Kind regards,
Andreas

[pjbuntinx]

Good to hear! Thank you for the update :)

[AHaug]

Hi again,

Another update here. The team verifies that the fix will target NCS 2.9.0. You should already be able to see it in v2.9.0-rc1, if I am not mistaken.

Kind regards,
Andreas

[pjbuntinx]

Hi,

Thanks for the update.
I have now tried the official release of 2.9.0 and I have not managed to reproduce the problem. So that is great news! 

The reason I am so late in responding is because reporting attributes does not work the same anymore as with v2.5.2. I am not able to let my device automatically report the attributes it has. Is there something changed in this regard compared to v2.5.2? In 2.7.0 I have the same problem. 

I have tried the code below to enable reporting in the new version, in 2.5.2 this worked by default and I could change the intervals using zb_zcl_put_reporting_info.

Fullscreen

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

zb_zcl_reporting_info_t rep_info = {0};

rep_info.direction = ZB_ZCL_CONFIGURE_REPORTING_SEND_REPORT;

rep_info.ep = endpoint;

rep_info.cluster_id = ZB_ZCL_CLUSTER_ID_WILMS_VENT_OPERATION;

rep_info.cluster_role = ZB_ZCL_CLUSTER_SERVER_ROLE;

rep_info.u.send_info.def_min_interval = DEFAULT_MIN_REPORTING;

rep_info.u.send_info.def_max_interval = DEFAULT_MAX_REPORTING;

rep_info.u.send_info.delta.u16 = 1;

rep_info.dst.short_addr = 0xFFFF;

rep_info.dst.endpoint = 0xFF;

rep_info.dst.profile_id = ZB_AF_HA_PROFILE_ID;

for (int i = 0; i <= ZB_ZCL_ATTR_WILMS_VENT_OPERATION_ACTUAL_STATUS_ID; i++) {

rep_info.attr_id = i;

int put = zb_zcl_put_reporting_info(&rep_info, ZB_TRUE);

int start = zb_zcl_start_attr_reporting(endpoint, ZB_ZCL_CLUSTER_ID_WILMS_VENT_OPERATION, ZB_ZCL_CLUSTER_SERVER_ROLE, i);

int check = zcl_is_attr_reported(endpoint, ZB_ZCL_CLUSTER_ID_WILMS_VENT_OPERATION, ZB_ZCL_CLUSTER_SERVER_ROLE, i);

printf("reporting attr %i: put %i, start %i, check %i\n", i, put, start, check);

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

 zb_zcl_reporting_info_t rep_info = {0};

    rep_info.direction                    = ZB_ZCL_CONFIGURE_REPORTING_SEND_REPORT;
    rep_info.ep                           = endpoint;
    rep_info.cluster_id                   = ZB_ZCL_CLUSTER_ID_WILMS_VENT_OPERATION;
    rep_info.cluster_role                 = ZB_ZCL_CLUSTER_SERVER_ROLE;
    rep_info.u.send_info.def_min_interval = DEFAULT_MIN_REPORTING;
    rep_info.u.send_info.def_max_interval = DEFAULT_MAX_REPORTING;
    rep_info.u.send_info.delta.u16        = 1;
    rep_info.dst.short_addr               = 0xFFFF;
    rep_info.dst.endpoint                 = 0xFF;
    rep_info.dst.profile_id               = ZB_AF_HA_PROFILE_ID;

    for (int i = 0; i <= ZB_ZCL_ATTR_WILMS_VENT_OPERATION_ACTUAL_STATUS_ID; i++) {
        rep_info.attr_id = i;
        int put          = zb_zcl_put_reporting_info(&rep_info, ZB_TRUE);

        int start = zb_zcl_start_attr_reporting(endpoint, ZB_ZCL_CLUSTER_ID_WILMS_VENT_OPERATION, ZB_ZCL_CLUSTER_SERVER_ROLE, i);

        int check = zcl_is_attr_reported(endpoint, ZB_ZCL_CLUSTER_ID_WILMS_VENT_OPERATION, ZB_ZCL_CLUSTER_SERVER_ROLE, i);
        printf("reporting attr %i: put %i, start %i, check %i\n", i, put, start, check);
    }

Kind regards,

Pieter-Jan Buntinx

[AHaug]

Great news indeed!

From what I can see there shouldn't be any changes to attribute reporting other than this from 2.6.0:

  

I'm not quite sure what this fix is about, but you're able to verify that it is present in 2.6.1 this might be the root cause. I will discuss it with the zigbee team in the meanwhile

Kind regards,
Andreas

[pjbuntinx]

In 2.6.1 this issue is also present. 

[AHaug]

Noted, thank you for verifying. I will open a discussion with the Zigbee team w.r.t this

Kind regards,
Andreas

[pjbuntinx]

Hi AHaug 

Do you have any updates on this issue?

I do have one more question, if I try to do a Zigbee FOTA on the light switch example, it is reasonably fast. It takes maybe 15 minutes. When I do the FOTA on my build, it takes about 3-4 times as long. On both instances I am transferring the same OTA image, so the same amount of data. What could be the cause of this? I have compared both prj.conf's and all settings concerning FOTA seems to be the same.

Thanks!

Kind regards,
Pieter-Jan