NVM saving persistent data

[ISLTG]

Hello,

I copied the logic from the NVM Zigbee examples. 

I notice that the end devices almost periodically calls the persistent data callback to save when I am sending sequential data sequences.

However, this unfortunately causes the end device to sometimes miss the reception of Zigbee data, and in my case, does not call ZbZcl_custom_ls_ServerSendCommandRsp.

The devices end up LOSING connection shortly after saving to persistent data.

Is this intended, and are there any solutions?

Thanks,

[Ouadi]

Hello @ISLTG,

Thanks for contacting us.

To better understand your issue, I have some questions :

What is the configuration used for both devices ? End device and coordinator ( sleep mode, persistable attributes implemented..)

When you say the device is loosing connection, do you detect a Parent Link Failure ? If yes, this means that the end device does not receive a response to its end device timeout request from the parent, what is the end device timeout configuration ?

Have you calculated the amount of time during a persistant data notification ? 

Also a full logs and Wireshark capture would be appreciated. 

Thanks & best regards,

Ouadi

 

[ISLTG]

Hello @Ouadi ,

Thank you very much for your response!

The end device is not on sleep mode, and I am not explicitly saving anything more than that from the example NVM code. On the coordinator, I do send binding requests and recover this information on startup.

I just tested and it does sometimes detect a parent link failure, but the connection tends to stay as it still receives information after and acts normally. When all devices stop responding, this typically happens when they all save to persistent data around the same time. Coordinator callback enters with ZCL_STATUS_FAILURE. How can I find the end device timeout configuration?

Sometimes the coordinator and end device take a couple seconds to save to persistent data.This also sometimes causes the coordinator to enter the NMI handler, and I have to delete NVM data for the device to exit the handler on reboot.

Please let me know if anything else is needed.

[Ouadi]

Hello,

Thanks for these informations. 

Still need some clarifications on how the coordinator sends data ana manages the response. Are you using Unicast or broadcast mode ?

End device timeout is set using ZbStartupT struct => config.endDeviceTimeout

Please share the logs and Wireshark when the issue occurs.

Best regards,

Ouadi

[Ouadi]

Hello @ISLTG,

For this use case the broadcast mode is more suitable and it should work properly.

You say that you have troubles when using broadcast even with 1 device, Are you using a custom boards or Nucleo ? Otherwise it may be linked to your code.

I recommend also to wait for the callback custom_ls_client_cb before sending a new data, this allow to manage properly the responses with a retry mechanism by the stack.  

For sniffer part, please refer to the wiki page below that explain how to configure sniffer for 802.15.4 => https://wiki.st.com/stm32mcu/wiki/Connectivity:How_to_configure_sniffer_for_802.15.4 

Regards,

Ouadi

 

[ISLTG]

Hello @Ouadi,

I am using the USB Dongles (P-NUCLEO-WB55) as the end devices and Nucleo board (NUCLEO-WB55RG) as the coordinator. I will try to first transition to broadcast logic.

With broadcast mode, I have a couple questions and comments. 

1) How does the callback work in broadcast mode in regards to multiple devices responses, considering ZCL_STATUS_TIMEOUT and ZCL_STATUS_FAILURE.

2) Must I wait until all devices respond/timeout to send the next broadcast?

Thanks,

[Ouadi]

Hi @ISLTG,

Broadcast communication in Zigbee uses a passive acknowledgement, meaning that when the message is sent it will be repeated by the neighboring with router capability ( Coordinator/ routers), in your case, end devices receiving a broadcast message will not send an acknowledgement, only responses if configured at the app level. 

The callback will be triggered as many time as responses, no error will be detected as there will be no ack.

For broadcast mode, depending on your time contraints, you can send broadcast with a configured timer with no condition on the responses.

Here is an example of the implementation :

 struct ZbApsAddrT dst;

 memset(&dst, 0, sizeof(dst));
 dst.mode = ZB_APSDE_ADDRMODE_SHORT;
 dst.endpoint = SW1_ENDPOINT;
 dst.nwkAddr = 0xFF; /* For broadcast */
 
 if (ZbZclSet_custom_ls_ClientCommand(zigbee_app_info.custom_ls_client,
 &dst,message, custom_ls_client_cb, NULL) != ZCL_STATUS_SUCCESS)
 {
 APP_DBG("Error, ZbZclSet_custom_ls_ClientCommand failed (SW1_ENDPOINT)");
 } 

Best regards,

Ouadi

[Ouadi]

Hello @ISLTG,

I recommend to take a look on zigbee specification to be familiar with Broadcast communication mode, here are some hints :

• Broadcast Delivery Time:The broadcast delivery time is the required time for a broadcast transaction to be delivered to every device on the network, it can be configured using the ZbNwkSet API with the parameter ZB_NWK_NIB_ID_NetworkBroadcastDeliveryTime.
• Minimum Interval: The minimum value for this parameter is 3 seconds. This means that broadcast messages cannot be sent at intervals shorter than 3 seconds.

Group addressing using ZB_APSDE_ADDRMODE_GROUP allow to send a message to a group of devices, while the broadcast mode in my example allow sending message to all devices on the network.

Best regards,

Ouadi

 

[ISLTG]

Thanks for all the help @Ouadi. 

3 seconds is unusable for my application.

Group addressing at 300ms seems to work well enough though...

Hopefully this isn't against recommended practice?

Thanks,