[Zigbee] Problem with Zcl callback handler in zigbee and thread 4.2.0

Hi guys,

So lately, I decided to update the sdk from 4.1.0 to 4.2.0 and there are some problem that I can not solve myself. So I use the macro ZB_ZCL_REGISTER_DEVICE_CB to register a device call back in 4.1.0 and now keeping it in 4.2.0.

But I have this problem when I tried to send an on off cmd from the coordinator to the device(router role) everything is fine. When I tried to send the report (multi state cluster since I have many state of the button) from the router to the coordinator, it is also OK too. But If i just turn the device on by hand and try to turn it off by sending cmd off of zigbee, although the packet is successfully  receive(I use the endpoint handler), It does not call the cb function that I register before.

This problem is not existed in the last SDK so I do not know if there are any config need to be set to use the ZB_ZCL_REGISTER_DEVICE_CB correctly and compare to the light bulb example seem to have that the only diffent is that I declare the context after I call this marcro but I does now seem to make any difference. So can you tell me how I can fix this or can you give me some hint on how to use the ZB_AF_SET_ENDPOINT_HANDLER to replace that.

Thank you very much,

Best regards,

Tu

Parents
  • Hello Tu,

    This is not something that I have seen reported before. Do you have some application that I can use to replicate this behavior? Or did you just use one of the already existing examples?

    Best regards,

    Edvin

  • Hi Edvin,

    Well I have just figured it out that I need to use this marco ZB_ZCL_SET_ATTRIBUTE to set the cluster on/off value correspondingly whenever I change the state with the button so that when the on/off command is receive it will call the zcl callback function. 

    In the last SDK version 4.1.0 I do not need to set the value in the cluster but looks like in 4.2.0 your developers have made some changes so now the on/off command is only callback when the value to change is different from the value in the command. Now everything works as normal.

    But I have one more problem, after reset does the value that I use ZB_ZCL_SET_ATTRIBUTE will persist since when I reset the device the issue happen again.

    I am look forward to hearing from you.

    Best regards,

    Tu

  • Hello Tu,

    It is not clear to me what you used to do and what you have to do now. Can you explain in detail how you used to change the value, which doesn't work anymore. What API did you use?

    Tu Hoang said:
    In the last SDK version 4.1.0 I do not need to set the value in the cluster but looks like in 4.2.0 your developers have made some changes so now the on/off command is only callback when the value to change is different from the value in the command

    How did you do it before?

    Tu Hoang said:
    But I have one more problem, after reset does the value that I use ZB_ZCL_SET_ATTRIBUTE will persist since when I reset the device the issue happen again.

    Can you explain what you mean by this? This is not clear to me.

    Best regards,

    Edvin

  • Hi Edvin,

    Sorry for the late response and making the last reply unclear

    I do not use binding and configure report but use API such as to create a report message and send.

    So in my system I have a set of buttons; each goes with one endpoint and have an on/off cluster. If I press a button I want it to send an on/off to the coordinator and the coordinator will work as a gateway to send out the data through Ethernet to the server. I also have an app to control the button through the internet by using the data in the server. Because I form my own package report without configure (using marcro like ZB_ZCL_START_PACKET, ZB_ZCL_CONSTRUCT_GENERAL_COMMAND_REQ_FRAME_CONTROL, ZB_ZCL_CONSTRUCT_COMMAND_HEADER, ZB_ZCL_PACKET_PUT_DATA8 and ZB_SEND_SHORT_CMD) I usually just send the message without making changes in cluster attribute. This will make the data on the server and the attribute value in devices go un-sync. So there will be cases when the attribute is off/on and the command send to the device is also off/on. The call back was declared with ZB_ZCL_REGISTER_DEVICE_CB as usual. In 4.1.0, the callback register by that macro is always called whenever there are a on/off command. But from what I see, in 4.2.0, The callback will only called when the value in on/off command change the attribute in device cluster. If the value in that endpoint is off and I send an off command to it , it will not change anything thus the callback is not triggered. The same case goes with on. So what I did is to add ZB_ZCL_SET_ATTRIBUTE to everytime I press the buttons.

    But the problem is that after a reset, the value on/off in the cluster attribute is return to 0. What I ask is that is there any way I can persist the value on every reset without initiate a new regions in Fds.  Also, Is there any way I can get the callback to call every time.

    Thank you and looking forward for your answer,

    Best regards,

    Tu

  • Is this seen in e.g. the light bulb examples in v4.1.0 and 4.2.0? It is still a bit vague to me. If not, can you zip and send some examples that I can use to replicate this on a few DKs? 

    Disclaimer:

    If the behavior did actually change, I guess there isn't much we can do, since the nRF5 SDK for Thread and Zigbee is in maintenance mode (meaning there will not be any updates unless there are crucial security bugs that need patching). All future development is on the nRF Connect SDK (NCS).

    Tu Hoang said:
    But the problem is that after a reset, the value on/off in the cluster attribute is return to 0.

    So this was not the case in 4.1.0? If it was not, then I assume that this must have been stored in flash by the zboss stack (but I don't think it is).

    Best regards,

    Edvin

  • Thank you for your answer and sorry for the late reply,

    So this behavior can be easily seen by using CLI dongle and a NRF_dev board running example from the two light bulb example. You can just add some log in the zcl handler and using the cli dongle to send on/off command. You can tried to send 2-3 off command to see that only the first off command will trigger the callback

    So if nothing you can do to change the SDK, is there any other way I can use to fix this behavior like changing to another command or something.

    Best regards,

    Tu

Reply
  • Thank you for your answer and sorry for the late reply,

    So this behavior can be easily seen by using CLI dongle and a NRF_dev board running example from the two light bulb example. You can just add some log in the zcl handler and using the cli dongle to send on/off command. You can tried to send 2-3 off command to see that only the first off command will trigger the callback

    So if nothing you can do to change the SDK, is there any other way I can use to fix this behavior like changing to another command or something.

    Best regards,

    Tu

Children
  • According to our Zigbee team, the zboss stack will not tell the application layer about these events if no changes is done in the end point. From an application point of view, I guess this is fine. 

    I don't really understand the issue here. Are you trying to set up some custom protocol on top of an on_off cluster? Is that why you need the "duplicate" events?

    BR,

    Edvin

  • Hi Edvin,

    It is a long story, I have a server to turn on and off the light bulb with an interface in web. Every time I click at the button, the GUI will toggle the button and tell the coordinator to send on/off according to the before-clicking state of the bulb. Sometimes, when the coordinator can not reach the end devices, the state of the button and the state of the end device will not sync (the interface will the coordinator to send on/off when the device is already on/off respectively so no callbacks) and it cause the devices can not be control remotely.  So because this problem do not exist in the old sdk(4.1.0), the communication mechanism of the server and the devices are fixed and changing them to much will take a lot of time and thus cause a huge amount of problem to our company. 

    That is the reason why I want your help to have some methods to cope with the changes in the SDK and the problem I have just explained. 

    I am looking forward to hearing from you.

    Best regards,

    HNT

  • Hi Edvin,

    So I have just realize that I can just always set the value of on/off cluster to some random value other than 0 and 1 so every time I send something to the endpoint, the signal is received.

    For that I think is a quick fix for this problem.

    If there is something better to do please inform me,

    Best regards,

    HNT

Related