ZBOSS Manufacturer Specific Extension to Standard cluster

RE: ZBOSS Manufacturer Specific Extension to Standard cluster

Amanda Hsieh — Mon, 23 Sep 2024 20:48:04 GMT

Hi,

The fixed binaries are put into NCS by https://github.com/nrfconnect/sdk-nrf/pull/14282

Please check the latest version, v2.7.0.

-Amanda H.

RE: ZBOSS Manufacturer Specific Extension to Standard cluster

Sigurd — Tue, 04 Jul 2023 15:10:09 GMT

Hi Jonas,

I will forward this to the team.

BR,

Sigurd

RE: ZBOSS Manufacturer Specific Extension to Standard cluster

Jonas K — Tue, 04 Jul 2023 12:39:42 GMT

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.

RE: ZBOSS Manufacturer Specific Extension to Standard cluster

Sigurd — Mon, 03 Jul 2023 08:28:43 GMT

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.

RE: ZBOSS Manufacturer Specific Extension to Standard cluster

Jonas K — Wed, 14 Jun 2023 11:03:51 GMT

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.

RE: ZBOSS Manufacturer Specific Extension to Standard cluster

Jonas K — Mon, 12 Jun 2023 19:52:59 GMT

v2.2.0

RE: ZBOSS Manufacturer Specific Extension to Standard cluster

Amanda Hsieh — Mon, 12 Jun 2023 16:23:16 GMT

Hi,

Which NCS version are you using?

Regards,
Amanda H.

RE: ZBOSS Manufacturer Specific Extension to Standard cluster

Jonas K — Mon, 12 Jun 2023 10:39:17 GMT

Forgot to add that I'm also setting a manufacturer code in ZB_ZCL_CLUSTER_DESC for the On/Off cluster in the ZB_DECLARE_*_CLUSTER_LIST macro.