ZBOSS Manufacturer Specific Extension to Standard cluster

[Jonas K]

Hi,

I'm trying to add a manufacturing specific attribute to the On/Off cluster.

To do this I have so far created a custom attribute list with ZB_ZCL_DECLARE_ON_OFF_ATTRIB_LIST_CUSTOM, inside that macro I've used ZB_ZCL_SET_MANUF_SPEC_ATTR_DESC to add my attribute and I've redefined ZB_ZCL_CLUSTER_ID_ON_OFF_SERVER_ROLE_INIT to point to my own function because I want to do a value range check of the manufacturer specific attribute.

For the most part I think I have a decent grasp of how things fit together, and when I do a WriteAttributes command over the Zigbee network I can see my range check is called, and then the zcl_device_cb triggeres and I can see that the attribute has a new value.

My problem is that the attribute is successfully written to when the manufacturer specific flag is set to false. According to the Zigbee spec:

"All communications regarding manufacturer specific extensions SHALL be transmitted with the manufac-
turer specific sub-field of the frame control field set to 1 and the manufacturer code included in the frame.
If the manufacturer code in a command frame is not recognized, the command is not carried out."

So I'm wondering if I'm missing something in the setup of the attribute, or if I'm supposed to validate the manufacturer code in the check value callback. If the latter I'm not sure where to get the manufacturer code in the incoming frame as what seems to be the norm is calling ZB_BUF_GET_PARAM on the param argument to get zb_zcl_parsed_hdr_t in most callbacks, but the check value callback doesn't have that argument, and I'm struggling to find a global way of accessing it.

Kind regards,

Jonas

[Amanda Hsieh]

Hi, 

Which NCS version are you using?

Regards,
Amanda H.

[Jonas K]

v2.2.0

[Jonas K]

Hi, any update on this? I've got some kind of workaround hooking into ZB_AF_SET_ENDPOINT_HANDLER and replying with ZB_ZCL_STATUS_UNSUP_ATTRIB if it's a ReadAttributes command for my manufacturer specific attribute, but the manufacturer specific flag is not set, and/or wrong manufacturer code.

But this seems like it will end up being a lot of work, especially when adding additional manufacturer specific attributes for something I kind of expected ZBOSS to do already.

[Sigurd]

Hi Jonas,

Amanda is out of office, so I'm replying instead.

It looks like the manufacturer specific is not handled fully by the stack, seems like it is ignored in general ZCL commands but the response should be sent with this bit set. We are looking into this.

Your attempt to send ZB_ZCL_STATUS_UNSUP_ATTRIB may be good step forward, however I am not yet sure if this is the correct status code to return.
I’d guess that to make it according to specification, ZCL general commands (Read/Write Attribute, et.c.) targeting manufacturer specific attribute should be handled in the endpoint handler (checking if such command has manufacturer specific bit set, checking manufacturer’s code) and return correct status code.
When command has correct flags set and contain correct manufacturer code, the command should be passed to the stack for further processing. Then, the zcl device cb will be called, informing application about attribute value change. In the mean time I would expect check value callback to be called and at this point there will be no need to check the manufacturer code again (it was already checked in the endpoint handler)

To get the manufacturer specific code, in the endpoint handler:

zb_zcl_parsed_hdr_t *cmd_info = ZB_BUF_GET_PARAM(param, zb_zcl_parsed_hdr_t);

then cmd_info->manuf_specific should have the manufacturer specific code.

[Jonas K]

Hi Sigurd, thanks for the follow up.

Just to reiterate the problem I'm trying to solve is that Read/Write attribute command to a mfg attribute added to f.ex the On/Off cluster with ZB_ZCL_SET_MANUF_SPEC_ATTR_DESC, is still processed and accepted when the command does not have the mfg flag set.

So if I have to fix it in the endpoint handler callback, I can't just look at the incoming messages with the mfg flag set and verify that the mfg code is correct.

I have to check if it's a read/write command, then check if it's related to my attribute, and then check the mfg flag is set and compare the manufacturer code, and if the mfg flag is not set I need to "reject" the command with whatever status code is appropriate. This is further complicated when read/write command can have multiple attributes in one message.

Certainly possible, but I would hope the stack could do this as it's part of the spec.

[Sigurd]

Hi Jonas,

I will forward this to the team.

BR,

Sigurd