cancel
Showing results for 
Search instead for 
Did you mean: 

stm32wb55: Zigbee - Touchlink Initiator as Sleepy End Device

tommy15433
Associate

Hello

 

 I need to develop low power wireless device which is suitable of making target devices to join a network. After doing research I came to a conclusion Zigbee Touchlink(TL) Initiator Sleepy End Device(SED). But STM32CubeWB does not have any Touchlink examples so currently testing with existing coordinator and router examples with their .ioc configuration changed to Touchlink. I see no problem making connection between "RFD-TL-Initiator-ED" and "FFD-TL-Target-Router" but when ED is changed to SED the connection fails. 

 Only code difference between SED and ED is that SED does not set ZCL_TL_ZBINFO_RX_ON_IDLE flag on function APP_ZIGBEE_NwkForm().

 

So my question is

1. Is there another way to make SED-Initiator combination work? (maybe some example codes)

2. Is SED-Initiator combo not workable by Zigbee itself at the first place?

3. Maybe there's something else I am missing on?

 

Below is my current setup

  • P-NUCLEO-WB55 with RFD stack x 1 (Initiator SED or ED)
  • P-NUCLEO-WB55 with FFD stack x 1 (Target)
  • Wireless Stack V1.18
  • IDE - STM32CubeIDE

Target Project (TL router)

Imported Zigbee_OnOff_Server_Coord and Changed Zigbee Configuration as below

target.PNG

ED project (TL connections are OK)

Imported Zigbee_OnOff_Client_Router example and Changed Zigbee Configuration as below

ED_Config.PNG

SED Project (TL connection fails)

Imported Zigbee_OnOff_Client_Router example and Changed Zigbee Configuration as below (enabled CFG_FULL_LOW_POWER)

SED_Config.PNG

Results are Target - ED is OK, but Target - SED fails.

Code difference between ED and SED is the greeb line in below image does not exist in SED code generation.

diff.PNG

 

Really appreciate your time for reading and any idea will be really helpful.

Thank you.

1 REPLY 1
Ouadi
ST Employee

Hello @tommy15433,

Thanks for contacting ST Support and welcome to the community.

Regarding your case, it seems that the initiator configured as a Sleepy end device goes to sleep mode in the commissioning phase and leads to losing some response packet from the target. 

A ticket has been created internally to look at this specific case, we will reach you asap with the last status.

For now, I recommend to use the initiator configured as ED with no sleep mode enabled.

Best regards,

Ouadi

PS: Internal ticket number 175851