Cluster Zigbee Failure Write Request

[Jorge Alves]

Dear St,

I'm developing a cluster with a client and server, where I have a client to write on the cluster of the server. I can write with the function ZbZclWriteReq() on the server, but I'm not always successful. When I do the first write, I have success, but in the next ones, I have some failures. Especially when I put a Hal_delay of 10 seconds because I just want to send a message every 10 seconds. When I don't have the delay, the communication works better, but I don't understand why.

I also have another case where when I'm writing to the server without delay, I always have been successful until I touch the switch SW1. The SW1 on the server has the function of making a local read of the attributes of the cluster.

In my project, I'm developing with the Nucleo Board WB55RG.

Do you know what can be my problems?

Best Regards
Jorge Alves

[Ouadi · Accepted solution]

Hi @Jorge Alves ,

Welcome to the community.

I understand from your post that you need to write attribute on the server continuously with a delay of 10 sec of interval, for this purpose, you have to use a non blocking method like the hardware timer server module instead of using Hal_Delay function.

Actually, Hal_Delay() is an active polling loop which blocks the process waiting the end of the delay, this method is not suitable for your application as the response callback after a ZbZclWriteReq is not handled within this delay.

To use the time server as a virtual timer for your application, please have a look to the code below for the initialization : 

#define PERIOD_WR (10 * 1000 * 1000 / CFG_TS_TICK_VAL)//10s
HW_TS_Create(CFG_TIM_TASK_WR, &TASK_WR, hw_ts_Repeated, APP_ZIGBEE_Write_Request);//creating repeated timer for write request
HW_TS_Start (TASK_SW1, PERIOD_WR);

When sending a ZbZclWriteReq you have also to check the response callback before performing another write, you can refers to the project example ..\Zigbee_PollControl_Client_Coord that implements a semaphore mechanism for this purpose.

BR,

Ouadi

[Jorge Alves]

Ok, I understand. Thank you for your answer.

I will take the opportunity to ask another question.

In my case, I have a client (router or end device) that makes a write request every 10 seconds to the server (coordinator), and the server sends the new data by USB to another device when the callback is called (callback of write request from the client) making a local read of the cluster. The clients are writing to the same cluster in the server.

If I have multiple clients in my network working as routers or end devices, send information every 10 seconds, can I take some conflicts?  I.e., a write request is sent by a client, and then the callback is called at the server to send the new data by USB. If, during this process, it was received a new write request from another client before the callback of the previously to be called and processed, what happens? The callback is always called and processed before receiving the new write request. Or the values of the cluster can be updated with the new request, and when the callback of the first write request is called to make the local read, it can be reading the values of the new write request.
I have some doubts about how the Zigbee network works when you receive different requests in instants very close. The Zigbee always processes one remote request, executes the callbacks, and then receives the next request, having a sequential process?  So, the next remote request is like waiting in the buffer for the M0 to receive the next remote request?

I'm also studying to do that with an attribute report, working with the coordinator as a client and every end device working as a server. The attribute reporting sends all the attributes in one message or frame? Does attribute reporting report the current value of the attribute in the server (end device)? Do you think that is a better approach?

Best Regards,
Jorge Alves

[Ouadi]

Hello @Jorge Alves,

Actually in a radio environment the interferences between protocols and signals may exist, especially when you have many devices which communicates at the same time. To avoid conflicts, ZigBee uses a collision avoidance mechanism called CSMA-CA (Carrier Sense Multiple Access with Collision Avoidance). This mechanism ensures that clients check the channel before transmitting data and wait for a clear channel before sending their data. This helps to reduce the chances of collisions and improve the reliability of the network.

Now, back to your question about the management of the callback when many requests are received simultaneously, in order to not loose the data, the callback is processed in priority with FIFO order, first attribute value received on the callback, and then a second callback is triggered for the second value etc.

For your use case, I recommend to use attribute reporting feature which is more suitable to report continuously some values as " Temperature value" during an interval of time, this is simple to implement, data process is more flexible that ensures to avoid packet conflicts.

You can refer to this post that describes how to implement attribute reporting for both Coordinator as a client and End device as a server.

Best regards,

Ouadi