• State Verified Answer
  • Replies 15 replies
  • Answers 1 answer
  • Subscribers 78 subscribers
  • Views 3051 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 289850
Options

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

Tu Hoang

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

  • 0 in reply to 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

  • 0 in reply to Tu Hoang

    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

  • 0 in reply to 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

  • 0 in reply to Edvin

    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

  • 0

    Hi,

    Edvin is currently on vacation so I will relay this information from the ZigBee team related to this ticket

    That could be a quick fix, but maybe the following answer could clarify the issue for you

    Implementation of Home Automation Profile Specification logic was removed. This logic added dependency between On/Off and Level clusters, so changes in Level cluster were affecting the On/Off one. Now there is no such dependency. In case you were referring to the callbacks that affects more more than single attribute - the "missing" callback could be a one for OnOff attribute, which value used to be changed after Level cluster commands were received.

    I can't directly link to changes in nRF5 SDK but similar changes are present in the NCS and can be seen here:
    https://github.com/nrfconnect/sdk-nrf/commit/92c56d08ab01d6fb0368a57902e2e79e7461095d#diff-92c759bdfd46575513ee897f7fd0f2541e61fedb39b5d2b4412ee09347f908a5

    Kind regards,
    Andreas

Related
Terms of service