ESP32C6 Unable to join existing Zigbee PRO network with HA_on_off_light example (IDFGH-10486)

[lordldx]

Answers checklist.

• [X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• [X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• [X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.2-dev-1128-g03d4fa2869

Operating System used.

Windows

How did you build your project?

VS Code IDE

If you are using Windows, please specify command line type.

PowerShell

Development Kit.

ESP32-C6-DevKitM-1

Power Supply used.

USB

What is the expected behavior?

I expected that the device would join the network.

What is the actual behavior?

The device fails during network steering

Steps to reproduce.

1. in VSCode: run ESP-IDF: Show Examples Projects
2. Create a new example project of HA_on_off_light
3. Set correct COM port
4. Set target device to esp32c6
5. Build
6. Flash
7. Monitor

Debug Logs.

ESP-ROM:esp32c6-20220919
Build:Sep 19 2022
rst:0x15 (USB_UART_HPSYS),boot:0xc (SPI_FAST_FLASH_BOOT)
Saved PC:0x40805aac
0x40805aac: rv_utils_wait_for_intr at C:/Users/dieryckxl/esp/esp-idf/components/riscv/include/riscv/rv_utils.h:33
 (inlined by) esp_cpu_wait_for_intr at C:/Users/dieryckxl/esp/esp-idf/components/esp_hw_support/cpu.c:119        

SPIWP:0xee
mode:DIO, clock div:2
load:0x40875720,len:0x181c
load:0x4086c410,len:0xd44
load:0x4086e610,len:0x2df8
entry 0x4086c41a
I (23) boot: ESP-IDF v5.2-dev-1128-g03d4fa2869-dirty 2nd stage bootloader
I (23) boot: compile time Jun 23 2023 23:40:19
I (24) boot: chip revision: v0.0
I (28) boot.esp32c6: SPI Speed      : 40MHz
I (33) boot.esp32c6: SPI Mode       : DIO
I (37) boot.esp32c6: SPI Flash Size : 2MB
I (42) boot: Enabling RNG early entropy source...
I (48) boot: Partition Table:
I (51) boot: ## Label            Usage          Type ST Offset   Length
I (58) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (66) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (73) boot:  2 factory          factory app      00 00 00010000 00089800
I (81) boot:  3 zb_storage       Unknown data     01 81 0009a000 00004000
I (88) boot:  4 zb_fct           Unknown data     01 81 0009e000 00000400
I (96) boot: End of partition table
I (100) esp_image: segment 0: paddr=00010020 vaddr=42058020 size=0e5f8h ( 58872) map
I (121) esp_image: segment 1: paddr=0001e620 vaddr=40800000 size=019f8h (  6648) load
I (123) esp_image: segment 2: paddr=00020020 vaddr=42000020 size=57ec4h (360132) map
I (199) esp_image: segment 3: paddr=00077eec vaddr=408019f8 size=0de20h ( 56864) load
I (216) boot: Loaded app from partition at offset 0x10000
I (217) boot: Disabling RNG early entropy source...
I (228) cpu_start: Unicore app
V (228) mmap: after coalescing, 1 regions are left
I (229) cpu_start: Pro cpu up.
D (238) clk: RTC_SLOW_CLK calibration value: 3588762
W (246) clk: esp_perip_clk_init() has not been implemented yet
V CACHE_ERR: access error intr clr & ena mask is: 0x10
I (252) cpu_start: Pro cpu start user code
I (253) cpu_start: cpu freq: 160000000 Hz
I (255) cpu_start: Application information:
I (260) cpu_start: Project name:     light_bulb
I (265) cpu_start: App version:      1
I (270) cpu_start: Compile time:     Jun 23 2023 23:39:51
I (276) cpu_start: ELF file SHA256:  5d2a853ac886acdf...
I (282) cpu_start: ESP-IDF:          v5.2-dev-1128-g03d4fa2869-dirty
I (289) cpu_start: Min chip rev:     v0.0
I (293) cpu_start: Max chip rev:     v0.99 
I (298) cpu_start: Chip rev:         v0.0
V (303) memory_layout: reserved range is 0x42065ec8 - 0x42065ee8
D (309) memory_layout: Checking 5 reserved memory ranges:
D (315) memory_layout: Reserved memory range 0x40800000 - 0x4080dd90
0x40800000: _vector_table at ??:?

D (321) memory_layout: Reserved memory range 0x4080dd90 - 0x40815b00
D (327) memory_layout: Reserved memory range 0x4087f564 - 0x40880000
D (334) memory_layout: Reserved memory range 0x50000000 - 0x50000000
D (340) memory_layout: Reserved memory range 0x50003fe8 - 0x50004000
D (347) memory_layout: Building list of available memory regions:
V (353) memory_layout: Examining memory region 0x40800000 - 0x40820000
0x40800000: _vector_table at ??:?

V (359) memory_layout: Start of region 0x40800000 - 0x40820000 overlaps reserved 0x40800000 - 0x4080dd90
0x40800000: _vector_table at ??:?

0x40800000: _vector_table at ??:?

V (369) memory_layout: Start of region 0x4080dd90 - 0x40820000 overlaps reserved 0x4080dd90 - 0x40815b00
D (379) memory_layout: Available memory region 0x40815b00 - 0x40820000
V (385) memory_layout: Examining memory region 0x40820000 - 0x40840000
D (392) memory_layout: Available memory region 0x40820000 - 0x40840000
V (398) memory_layout: Examining memory region 0x40840000 - 0x40860000
D (405) memory_layout: Available memory region 0x40840000 - 0x40860000
V (412) memory_layout: Examining memory region 0x40860000 - 0x4087c610
D (418) memory_layout: Available memory region 0x40860000 - 0x4087c610
V (425) memory_layout: Examining memory region 0x4087c610 - 0x40880000
V (431) memory_layout: End of region 0x4087c610 - 0x40880000 overlaps reserved 0x4087f564 - 0x40880000
D (441) memory_layout: Available memory region 0x4087c610 - 0x4087f564
V (447) memory_layout: Examining memory region 0x50000000 - 0x50004000
V (454) memory_layout: End of region 0x50000000 - 0x50004000 overlaps reserved 0x50003fe8 - 0x50004000
D (463) memory_layout: Available memory region 0x50000000 - 0x50003fe8
I (470) heap_init: Initializing. RAM available for dynamic allocation:
D (477) heap_init: New heap initialised at 0x40815b00
I (482) heap_init: At 40815B00 len 00066B10 (410 KiB): D/IRAM
I (489) heap_init: At 4087C610 len 00002F54 (11 KiB): STACK/DIRAM
D (495) heap_init: New heap initialised at 0x50000000
I (500) heap_init: At 50000000 len 00003FE8 (15 KiB): RTCRAM
V (507) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): checking args
V (513) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): Args okay. Resulting flags 0x40E
D (521) intr_alloc: Connected src 15 to int 2 (cpu 0)
V (527) memspi: raw_chip_id: 164020

V (530) memspi: chip_id: 204016

V (534) memspi: raw_chip_id: 164020

V (537) memspi: chip_id: 204016

D (541) spi_flash: trying chip: generic
I (545) spi_flash: detected chip: generic
I (549) spi_flash: flash io: dio
W (553) spi_flash: Detected size(4096k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
D (566) cpu_start: calling init function: 0x4204f7aa
0x4204f7aa: _GLOBAL__sub_I__ZN9__gnu_cxx9__freeresEv at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/riscv32-esp-elf/src/gcc/libstdc++-v3/libsupc++/eh_alloc.cc:342

D (572) cpu_start: calling init function: 0x4204f174
0x4204f174: _GLOBAL__sub_I__ZN17__eh_globals_init7_S_initE at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/riscv32-esp-elf/build/build-cc-gcc-final/riscv32-esp-elf/rv32imac_zicsr_zifencei/ilp32/no-rtti/libstdc++-v3/include/riscv32-esp-elf/bits/gthr-default.h:708
 (inlined by) __eh_globals_init::__eh_globals_init() at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/riscv32-esp-elf/src/gcc/libstdc++-v3/libsupc++/eh_globals.cc:116
 (inlined by) __static_initialization_and_destruction_0 at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/riscv32-esp-elf/src/gcc/libstdc++-v3/libsupc++/eh_globals.cc:132
 (inlined by) _GLOBAL__sub_I__ZN17__eh_globals_init7_S_initE at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/riscv32-esp-elf/src/gcc/libstdc++-v3/libsupc++/eh_globals.cc:168

D (577) cpu_start: calling init function: 0x42003454
0x42003454: esp_crypto_dpa_protection_startup at C:/Users/dieryckxl/esp/esp-idf/components/esp_hw_support/esp_dpa_protection.c:21

D (582) cpu_start: calling init function: 0x4200002a
0x4200002a: esp_app_format_init_elf_sha256 at C:/Users/dieryckxl/esp/esp-idf/components/esp_app_format/esp_app_desc.c:69

D (587) cpu_start: calling init function: 0x42004d86 on core: 0
0x42004d86: __esp_system_init_fn_esp_timer_startup_init at C:/Users/dieryckxl/esp/esp-idf/components/esp_timer/src/esp_timer.c:575

V (593) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): checking args
V (599) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): Args okay. Resulting flags 0xC02
D (607) intr_alloc: Connected src 59 to int 9 (cpu 0)
D (612) cpu_start: calling init function: 0x42003304 on core: 0
0x42003304: __esp_system_init_fn_esp_sleep_startup_init at C:/Users/dieryckxl/esp/esp-idf/components/esp_hw_support/sleep_gpio.c:188

I (618) sleep: Configure to isolate all GPIO pins in sleep state
I (625) sleep: Enable automatic switching of GPIO sleep configuration
D (632) cpu_start: calling init function: 0x420014b8 on core: 0
0x420014b8: __esp_system_init_fn_init_components0 at C:/Users/dieryckxl/esp/esp-idf/components/esp_system/startup.c:486

I (638) coexist: coex firmware version: ebddf30
I (643) coexist: coexist rom version 5b8dcfa
V (648) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): checking args
V (654) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): Args okay. Resulting flags 0x40E
D (663) intr_alloc: Connected src 22 to int 10 (cpu 0)
I (668) app_start: Starting scheduler on CPU0
V (673) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): checking args
V (673) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): Args okay. Resulting flags 0x402
D (673) intr_alloc: Connected src 57 to int 11 (cpu 0)
I (673) main_task: Started on CPU0
D (673) heap_init: New heap initialised at 0x4087c610
V (673) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): checking args
V (683) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): Args okay. Resulting flags 0xE
D (693) intr_alloc: Connected src 53 to int 12 (cpu 0)
I (693) main_task: Calling app_main()
V (703) partition: Loading the partition table
V (703) mmap: actual_mapped_len is 0x8000
V (713) calculated md5: 0x40818a48   b2 8f 38 bf 97 1a 10 d7  c4 19 2e 85 a5 2b f8 86  |..8..........+..|
V (723) stored md5: 0x420680b0   b2 8f 38 bf 97 1a 10 d7  c4 19 2e 85 a5 2b f8 86  |..8..........+..|
V (733) partition: Partition table MD5 verified
D (743) rmt: new group(0) at 0x4087d5f0, occupy=fffffff0
D (743) rmt: group clock resolution:80000000
V (743) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): checking args
V (753) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): Args okay. Resulting flags 0x10E
D (753) intr_alloc: Connected src 49 to int 13 (cpu 0)
I (763) gpio: GPIO[8]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0 
D (773) rmt: new tx channel(0,0) at 0x4087d360, gpio=8, res=10000000Hz, hw_mem_base=0x60006400, dma_mem_base=0x0, ping_pong_size=48, queue_depth=4
D (783) rmt: new bytes encoder @0x4087d670
D (793) rmt: new copy encoder @0x4087d694
D (793) efuse: In EFUSE_BLK1__DATA1_REG is used 8 bits starting with 8 bit
D (803) efuse: In EFUSE_BLK1__DATA1_REG is used 8 bits starting with 0 bit
D (803) efuse: In EFUSE_BLK1__DATA0_REG is used 8 bits starting with 24 bit
D (813) efuse: In EFUSE_BLK1__DATA0_REG is used 8 bits starting with 16 bit
D (823) efuse: In EFUSE_BLK1__DATA0_REG is used 8 bits starting with 8 bit
D (833) efuse: In EFUSE_BLK1__DATA0_REG is used 8 bits starting with 0 bit
D (833) efuse: In EFUSE_BLK1__DATA1_REG is used 8 bits starting with 24 bit
D (843) efuse: In EFUSE_BLK1__DATA1_REG is used 8 bits starting with 16 bit
I (853) phy_init: phy_version 202,b4b3263,May 17 2023,20:14:14
D (853) phy_init: loading PHY init data from application binary
D (863) nvs: nvs_open_from_partition phy 0
D (863) nvs: nvs_get cal_version 4
V (873) phy_init: phy_get_rf_cal_version: 202
D (873) nvs: nvs_get_str_or_blob cal_mac
D (883) efuse: In EFUSE_BLK1__DATA1_REG is used 8 bits starting with 8 bit
D (883) efuse: In EFUSE_BLK1__DATA1_REG is used 8 bits starting with 0 bit
D (893) efuse: In EFUSE_BLK1__DATA0_REG is used 8 bits starting with 24 bit
D (903) efuse: In EFUSE_BLK1__DATA0_REG is used 8 bits starting with 16 bit
D (903) efuse: In EFUSE_BLK1__DATA0_REG is used 8 bits starting with 8 bit
D (913) efuse: In EFUSE_BLK1__DATA0_REG is used 8 bits starting with 0 bit
D (923) efuse: In EFUSE_BLK1__DATA1_REG is used 8 bits starting with 24 bit
D (923) efuse: In EFUSE_BLK1__DATA1_REG is used 8 bits starting with 16 bit
D (933) nvs: nvs_get_str_or_blob cal_data
D (943) nvs: nvs_close 1
D (943) efuse: In EFUSE_BLK1__DATA1_REG is used 8 bits starting with 8 bit
D (943) efuse: In EFUSE_BLK1__DATA1_REG is used 8 bits starting with 0 bit
D (953) efuse: In EFUSE_BLK1__DATA0_REG is used 8 bits starting with 24 bit
D (963) efuse: In EFUSE_BLK1__DATA0_REG is used 8 bits starting with 16 bit
D (973) efuse: In EFUSE_BLK1__DATA0_REG is used 8 bits starting with 8 bit
D (973) efuse: In EFUSE_BLK1__DATA0_REG is used 8 bits starting with 0 bit
D (983) efuse: In EFUSE_BLK1__DATA1_REG is used 8 bits starting with 24 bit
D (993) efuse: In EFUSE_BLK1__DATA1_REG is used 8 bits starting with 16 bit
D (1003) temperature_sensor: range changed, change to index 2
V (1033) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): checking args
V (1033) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): Args okay. Resulting flags 0xE
D (1033) intr_alloc: Connected src 12 to int 14 (cpu 0)
I (1043) main_task: Returned from app_main()
I (1053) ESP_ZB_ON_OFF_LIGHT: ZDO signal: 23, status: -1
I (1053) ESP_ZB_ON_OFF_LIGHT: Zigbee stack initialized
I (1053) ESP_ZB_ON_OFF_LIGHT: Start network steering
I (3713) ESP_ZB_ON_OFF_LIGHT: Network steering was not successful (status: -1)

More Information.

I sniffed the network traffic (TI CC2531 + ZBOSS sniffer + wireshark) and the join seems to start properly: -> First beacon request and a beacon from the ZC -> Next: Association request from the ZED (my esp32c6), and an association response from the ZC. The response indicates success and assigns a network address to the ZED. -> Next, the ZC transmits the transport key. ZED emits an ACK, but that's it. No more communication from the ZED from then on.

From then on, the whole process repeats every two seconds.

I observed the same behaviour on v5.1-rc2.

When looking at the network steering spec (from the Zigbee BDB spec 2.1, it seems that something goes wrong in Step 9. Looks to me as if the esp32c6 answers "no" to the "Was the network key received succesfully" question. Even though I see it being transmitted and ACKed in the traffic.

I'm honestly a bit disappointed in the amount of logging the zigbee api emits. I've configured Default log verbosity to "Verbose", but the only zigbee related output I'm seeing is the Information logging emited by the HA_on_off_light application code itself. Some lower-level zb or zboss logging would be really helpful here!

I can't seem to attach the pcap file directly in this issue, but here's a screenshot of it. Let me know if you need to see more details:

[xieqinan]

Hi @lordldx , The log message of the ESP Zigbee SDK will be provided in more detail in the upcoming release version. Joining network failure is a tricky issue, and it is difficult to determine the exact reasons solely based on the aforementioned message. Conducting additional tests may prove helpful in resolving this problem.

The entire Wireshark message associated with the issue serves as a vital resource for us to address the bug effectively.

Could you please attempt to use the Ha_on_off_switch example as the Zigbee coordinator to establish the network? Additionally, kindly provide us with the Wireshark message captured during the network formation process.

[xieqinan]

Hi @lordldx , Can you try use esp_zb_secur_TC_standard_preconfigure_key_set() to set the HA_on_off_light device and keep the same Trust Center standard key in your zigbee network?

The corresponding description for the transport key can be found in Chapter 4.4.2 of the Zigbee specification.

[lordldx]

Hi @xieqinan

Creating the network seems to work. See file "create_network-v5.2-dev-1128-g03d4fa2869.pcapng" in the attached zip. Not sure if you'll be able to derive much from it, since the data is encrypted and I'm not sure where I can find the security key for the network the esp32c6 creates. (If you can point me to this, I can also provide you with an unencrypted log)

I also added the wireshark logging of my initial report. See file "join_network_fail-v5.2-dev-1128-g03d4fa2869.pcapng" in the attached zip.

Please let me know how I can assist any further. I'd love to get this fixed!

wireshark_dumps.zip

[xieqinan]

Hi @lordldx ,

In a general Zigbee network, the security key can typically be obtained from the transport key section.

I am confused about the process of joining a network on your Zigbee network. Firstly, I noticed that the Zigbee coordinator/router sends a transport key packet with a source address of ff:ff:ff:ff:ff:ff:ff:ff to the Zigbee end device. If your Zigbee network is centralized, the specification requires the source address to be the local device address.

f your Zigbee network is distributed, please verify your network using the following guidelines.

So what is your network topology?

Based on the Wireshark log you provided, it seems that your network topology is centralized since only the Zigbee coordinator is distributing the short address (0x0000). However, I am unsure how to explain the presence of the long address (ff:ff:ff:ff:ff:ff:ff:ff). Therefore, we would need more information about your Zigbee network to clarify this.

Besides, it is helpful to tell us whether network security feature is supported in your network Pro? I do not have detect any secuity key section in the wireshark log.

[lordldx]

Hi @xieqinan

Thank you for your fast responses and thourough investigation. To answer your questions:

1. Can you try use esp_zb_secur_TC_standard_preconfigure_key_set()? I tried, but I think I'm doing something wrong, because I get even less traffic. Now the esp32c6 only emits a beacon request and that's it. I may have misused the function above though, I'm still very uncomfortable with the esp_zb api... I used it like this:

   static void esp_zb_task(void *pvParameters)
   {
   /* initialize Zigbee stack with Zigbee end-device config */
   esp_zb_cfg_t zb_nwk_cfg = ESP_ZB_ZED_CONFIG();
   esp_zb_init(&zb_nwk_cfg);
   
   uint8_t key[16] = {0xb6, 0x00, 0x08, 0x56, 0xbe, 0x74, 0x7a, 0xb9, 0xf1, 0x50, 0xed, 0x5f, 0x82, 0x8b, 0x2c, 0xc0};
   esp_zb_secur_TC_standard_preconfigure_key_set(&key);
   
   /* set the on-off light device config */
   esp_zb_on_off_light_cfg_t light_cfg = ESP_ZB_DEFAULT_ON_OFF_LIGHT_CONFIG();
   esp_zb_ep_list_t *esp_zb_on_off_light_ep = esp_zb_on_off_light_ep_create(HA_ESP_LIGHT_ENDPOINT, &light_cfg);
   esp_zb_device_register(esp_zb_on_off_light_ep);
   esp_zb_device_add_set_attr_value_cb(attr_cb);
   esp_zb_set_primary_network_channel_set(ESP_ZB_PRIMARY_CHANNEL_MASK);
   ESP_ERROR_CHECK(esp_zb_start(false));
   esp_zb_main_loop_iteration();
   }

2. What is your network topology? It's a centralized network. The simplest possible: I have just a ZC which is also an actuator, and then a ZED which is a battery operated button that turns the light on and off. So now I'm just trying to add the esp32c6 as a second ZED.

3. Is network security feature supported in your network Pro? I actually don't know. The vendor of the ZC I'm using is very scarce with information. I'm using a bticino 3571, which is really just a relay with a Zigbee interface. I bought it in 2019 and it has been discontinued by the manufacturer, so I guess the technology is at least five years old. I tried getting some additional information on how to interface with it from the manufacturer, but I don't get any response. Is there any way I can figure this out from the traffic? From the beacon, or perhaps during initial network creation? I have no problem with completely resetting and reconfiguring the device if this would be any help.

Oh, and I haven't mentioned this before, but it might be important. I'm referencing esp-zigbee-lib v0.6.2, which is higher than the v0.5.0 with which the HA_on_off_light examples is preconfigiured:

## IDF Component Manager Manifest File
dependencies:
  espressif/esp-zigbee-lib: "~0.6.2"
  espressif/esp-zboss-lib: "~0.4.0"
  espressif/led_strip: "~2.0.0"
  ## Required IDF version
  idf:
    version: ">=5.0.0"

[xieqinan]

Hi @lordldx , This problem is triggered when the end device receives an unsecured frame on the application support sublayer. According to the specifications 4.4.2.3 section, If the device is operating in the joined and authorized state it may accept a NWK broadcast transport key command with Key type field set to 0x01 (that is, network key) where the message has no APS encryption.

However, the Wireshark log from the Bticino 3571 indicates that the frame is not encrypted, unsafe, and not using the broadcast address.

Therefore, if the coordinator can enable the transport key security feature through programming, the issue can be resolved, and the device will be able to function properly.

[lordldx]

Hi @xieqinan

About Section 4.4.2.3 that you quote. It states: "If the device is operating in the joined and authorized state..." I think that is not the case here. I compared the messages in the wireshark log with the sequence diagram in section 4.6.3.1. When the network key is received, the ED (our esp32c6) is still in the "joined but unauthorized" state

This means that, when the transport key is received, the ED should simply move into the "joined and authorized" state, right? And the esp_zb_app_signal_handler should be called with signal type ESP_ZB_BDB_SIGNAL_STEERING

Please let me know if there's any flaw in my logic here.

Also: I did some additional research in hopes of finding out more about the bticino 3571. I couldn't find any specifics on their implementation. So, seeing as the source address is set to ff:ff:ff:ff:ff:ff:ff:ff, let's assume that it creates a distributed network for now.

[xieqinan]

Hi @lordldx , From Figure 4-21, we can deduce that the Zigbee end device will remain in the Joined but unauthorized state upon receiving the association response. Only when the ZED receives the Network Key, it will transition into the "Join and Authorized" state.

Additionally, the Zigbee R22 certification requires the joining ZED to have the APS security key, and it allows the ZED to join the network without APS security when it is in the Joined and Authorized state. In other words, if the device has already joined the network, there is no need to perform an exchange of network keys during the next joining process.

Based on this information, I suspect that the "bticino 3571" may not be compliant with the R22 certification, or this bticino 3571 has been pre-configured at the factory to be already eligible for joining its network.

[chshu]

@lordldx please re-open if any follow up comments.