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

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

AHaug — Thu, 21 Jul 2022 10:21:00 GMT

Hi,

Try the following code snippet

zb_uint8_t ep_handler(zb_bufid_t bufid)
{
    zb_zcl_parsed_hdr_t *cmd_info = ZB_BUF_GET_PARAM(bufid, zb_zcl_parsed_hdr_t);
 
    if (cmd_info->cluster_id == ZB_ZCL_CLUSTER_ID_ON_OFF)
    {
        switch (cmd_info->cmd_id)
        {
            case ZB_ZCL_CMD_ON_OFF_OFF_ID:
                NRF_LOG_INFO("OFF cmd received");
                break;
            case ZB_ZCL_CMD_ON_OFF_ON_ID:
                NRF_LOG_INFO("ON cmd received");
                break;
            case ZB_ZCL_CMD_ON_OFF_TOGGLE_ID:
                NRF_LOG_INFO("TOGGLE cmd received");
                break;
            default:
                NRF_LOG_ERROR("UNKNOWN cmd received");
                break;
        }
    }
 
    return ZB_FALSE;
}
 
...
 
ZB_AF_SET_ENDPOINT_HANDLER(HA_DIMMABLE_LIGHT_ENDPOINT, ep_handler);

One note of warning: To make sure that the received command is correct you should also check:

profile ID
command direction
if the command is manufacturer specific

Let me know if this works or not!

Kind regards,
Andreas

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

Tu Hoang — Wed, 20 Jul 2022 02:45:10 GMT

So I did tried to use endpoint handler, I can get the on/off cmd but can not parse the message by zb_zcl_parsed_hdr_t * p_cmd_info = ZB_BUF_GET_PARAM(bufid, zb_zcl_parsed_hdr_t);

When I tried to log the cmd, it just an increase number every time. Do you have any idea how this happen.

Best regards,

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

Tu Hoang — Wed, 20 Jul 2022 02:36:20 GMT

Hi AHuag,

Thank you for your dedication, I will take a look at the components/zigbee/cli/zigbee_cli_cmd_attr_report.c and components/zigbee/cli/zigbee_cli_cmd_attr.c to see if I can change the zcl callback to endpoint handler. But as far as I know if I use more than 1 endpoint for my application, I will have to set up a 4 handlers for it. Is it correct?

Best regards,

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

AHaug — Tue, 19 Jul 2022 13:14:40 GMT

Hi again,

[quote user="Tu Hoang"]I just found out that I can change the way the zcl callback is call for by modifying the corresponding file in Zboss so now the callback will be call whenever the command is arrive.[/quote]

My colleague brought up a good point with regards to this. In case you are using the endpoint handler by changing the corresponding file Iwould like to point you towards the cli_agent_ep_handler_report() in the components/zigbee/cli/zigbee_cli_cmd_attr_report.c or cli_agent_ep_handler_attr() in components/zigbee/cli/zigbee_cli_cmd_attr.c for example of how to use endpoint handler (registered by ZB_AF_SET_ENDPOINT_HANDLER()). Changing "the corresponding file" is not great approach, to prevent unexpected behavior use endpoint handler.

Kind regards,
Andreas

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

Tu Hoang — Tue, 19 Jul 2022 04:10:46 GMT

Hi,

I just found out that I can change the way the zcl callback is call for by modifying the corresponding file in Zboss so now the callback will be call whenever the command is arrive.

Thank you very much for your help.

Best regards,

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

AHaug — Fri, 15 Jul 2022 14:17:27 GMT

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

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

Tu Hoang — Thu, 30 Jun 2022 04:27:55 GMT

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

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

Tu Hoang — Mon, 27 Jun 2022 03:32:58 GMT

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

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

Edvin — Thu, 23 Jun 2022 13:29:33 GMT

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

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

Tu Hoang — Mon, 13 Jun 2022 09:40:59 GMT

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,

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

Edvin — Tue, 07 Jun 2022 13:29:30 GMT

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).

[quote user="Tu Hoang"]But the problem is that after a reset, the value on/off in the cluster attribute is return to 0.[/quote]

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

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

Tu Hoang — Mon, 06 Jun 2022 02:37:38 GMT

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,

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

Edvin — Wed, 01 Jun 2022 06:28:12 GMT

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?

[quote user="Tu Hoang"]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[/quote]

How did you do it before?

[quote user="Tu Hoang"]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.[/quote]

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

Best regards,

Edvin

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

Tu Hoang — Wed, 01 Jun 2022 02:12:58 GMT

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,

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

Edvin — Tue, 31 May 2022 13:57:50 GMT

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