What is the difference between ZCL packet handler & Zigbee device callback

[saratk90]

Context: 

I am developing a Zigbee lock that implements the door lock cluster, and needs to be able to parse and handle incoming ZCL commands. According to this documentation, the SDK provides two handling mechanisms for this use-case.

1) ZCL packet handler - registered via ZB_AF_SET_ENDPOINT_HANDLER. The SDK provides this method to bypass the default handler for application-specific handling of a ZCL command. 

2) Zigbee device callback - this is an optional callback registered via ZB_ZCL_REGISTER_DEVICE_CB. It's called by the stack's default cluster handlers when an event such as in incoming ZCL command occurs.

Question: 

To my understanding, both these handlers serve the purpose of processing ZCL commands. My question is, what's the distinction between the two and what use-cases serve the purpose of each? For example, if I issue a lock command from a coordinator, should the locking operation be performed in the ZCL packer handler after it is parsed for ZB_ZCL_CMD_DOOR_LOCK_LOCK_DOOR, or should it be performed in the Zigbee device callback when its called with the ID ZB_ZCL_DOOR_LOCK_LOCK_DOOR_CB_ID. Is there a rule of thumb for which flow to follow for processing commands and is it standard for all types commands or is one better suited for certain types of commands.

Thank you.

[Susheel Nuguru]

I am not Zigbee exert, so I need to ask my colleagues about it. I will let you know when I hear their insights about your question regarding the difference in these handler/callback.

[saratk90]

Hi, is there any update for this?

Thank you.

[Susheel Nuguru]

ZCL packets are by default handled internally by the stack, but using ZCL packet handler allows the user to intercept this and override the processing/handling of the messages in order to execute their own application-specific handling. There is more information about this here: Configuring default ZCL command handler override.

Zigbee device callback does not override the default handling of ZCL messages, but allows the user to do additional handling, for example if they need to change an attribute (e.g. the on/off attribute upon receiving an on/off command), or if they need to execute some code related to hardware (e.g. actually turn the light on/off when receiving an on/off command). More information about device callback can be found here: Implementing Zigbee device callback.

As for the questions

For example, if I issue a lock command from a coordinator, should the locking operation be performed in the ZCL packer handler after it is parsed for ZB_ZCL_CMD_DOOR_LOCK_LOCK_DOOR, or should it be performed in the Zigbee device callback when its called with the ID ZB_ZCL_DOOR_LOCK_LOCK_DOOR_CB_ID

This should be done with the Zigbee device callback, as you want to change the value of the attribute (to be in the locked state), and lock the actual, physical lock.

Is there a rule of thumb for which flow to follow for processing commands and is it standard for all types commands or is one better suited for certain types of commands.

Most customers will only need the Zigbee device callback, and never the ZCL packet handler, as they will most likely not need to intercept the packets and change the internal handling, only add additional handling.