[Zigbee] Manufacturer Code clarification

RE: [Zigbee] Manufacturer Code clarification

Edvin — Wed, 17 Apr 2024 06:17:39 GMT

[quote user="pwpot"]That assert is in 2.6.0 in 2.4.1 it looks different[/quote]

Yes, but it will still only be checked if is_manuf_specific is true?

RE: [Zigbee] Manufacturer Code clarification

Pawel(embeddedsolutions.pl) — Fri, 12 Apr 2024 06:56:54 GMT

Hi Edvin,

Sorry for the late reply.

[quote userid="26071" url="~/f/nordic-q-a/108662/zigbee-manufacturer-code-clarification/474792"]

Whenever you call:

Fullscreen

1
void zb_zcl_send_report_attr_command(zb_zcl_reporting_info_t *rep_info, zb_uint8_t param)
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

void zb_zcl_send_report_attr_command(zb_zcl_reporting_info_t *rep_info, zb_uint8_t param)

wouldn't the *rep_info hold information so that:

Fullscreen

1
is_manuf_spec = !!ZB_ZCL_IS_ATTR_MANUF_SPEC(attr_desc);
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

is_manuf_spec = !!ZB_ZCL_IS_ATTR_MANUF_SPEC(attr_desc);

would return false if that attribute is not a manufacturer specific attribute?

[/quote]

Yes, is_manuf_spec will be false, and that information is determined based on the attribute descriptor, not based on reporting info.

[quote userid="26071" url="~/f/nordic-q-a/108662/zigbee-manufacturer-code-clarification/474792"]

And if is_manuf_spec is false, then the

Fullscreen

1
ZB_ASSERT(rep_info->manuf_code != ZB_ZCL_NON_MANUFACTURER_SPECIFIC);
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

ZB_ASSERT(rep_info->manuf_code != ZB_ZCL_NON_MANUFACTURER_SPECIFIC);

will not run, right?

[/quote]

That assert is in 2.6.0 in 2.4.1 it looks different.

ZB_ASSERT(ep_desc && cluster_desc && cluster_desc->manuf_code != ZB_ZCL_MANUF_CODE_INVALID);

RE: [Zigbee] Manufacturer Code clarification

Edvin — Wed, 20 Mar 2024 08:46:50 GMT

Hello Pawel,

I am not saying you are wrong, but I am trying to understand.

Whenever you call:

void zb_zcl_send_report_attr_command(zb_zcl_reporting_info_t *rep_info, zb_uint8_t param)

wouldn't the *rep_info hold information so that:

is_manuf_spec = !!ZB_ZCL_IS_ATTR_MANUF_SPEC(attr_desc);

would return false if that attribute is not a manufacturer specific attribute?

And if is_manuf_spec is false, then the

ZB_ASSERT(rep_info->manuf_code != ZB_ZCL_NON_MANUFACTURER_SPECIFIC);

will not run, right?

RE: [Zigbee] Manufacturer Code clarification

Pawel(embeddedsolutions.pl) — Tue, 19 Mar 2024 12:28:33 GMT

Hi,

is_manuf_spec = !!ZB_ZCL_IS_ATTR_MANUF_SPEC(attr_desc);

returns true indeed. That is because my attribute descriptor looks as follows:

#define ZB_SET_ATTR_DESCR_WITH_ZB_ZCL_ATTR_DIAGNOSTIC_FAULT_CODE_ID(data_ptr) \
    { \
        ZB_ZCL_ATTR_DIAGNOSTIC_FAULT_CODE_ID, ZB_ZCL_ATTR_TYPE_U16, \
            ZB_ZCL_ATTR_ACCESS_READ_ONLY | ZB_ZCL_ATTR_ACCESS_REPORTING | ZB_ZCL_ATTR_MANUF_SPEC, (void *)data_ptr \
    }

Then:

ZB_ASSERT(ep_desc && cluster_desc && cluster_desc->manuf_code != ZB_ZCL_MANUF_CODE_INVALID);

Manufacturer Code shall be different than 0x0000, otherwise the ASSERT occurs.

I see that the reporting mechanism is slightly different in 2.6.0. I am going to migrate to 2.6.0 but no matter the version my question will be the same :)

At this point, In my opinion in the case of manufacturer-specific attributes within the standard cluster, the cluster descriptor shall use a Manufacturer Code different than 0x0000 and that is valid for NCS 2.4.1.

Maybe, that exact scenario is solved in 2.6.0 because the ASSERT does not check cluster_desc->manuf_code but rep_info->manuf_code.

What do you think?

Regards,

Pawel

RE: [Zigbee] Manufacturer Code clarification

Edvin — Tue, 19 Mar 2024 11:40:15 GMT

In fact, this is what it looks like in NCS v2.6.0:

void zb_zcl_send_report_attr_command(zb_zcl_reporting_info_t *rep_info, zb_uint8_t param)
{
  zb_uint8_t *cmd_data;
  zb_zcl_reporting_info_t *cur_rep_info;
  zb_zcl_attr_t *attr_desc;
  zb_uint16_t bytes_avail;
  zb_uint8_t attr_size;
  zb_uint8_t send_mode;
  zb_uint8_t is_manuf_spec;

  TRACE_MSG(
      TRACE_ZCL1,
      ">> zb_zcl_send_report_attr_command rep_info %p, param %hd",
      (FMT__P_H, rep_info, param));

  attr_desc =
    zb_zcl_get_attr_desc_manuf_a(
      rep_info->ep,
      rep_info->cluster_id,
      rep_info->cluster_role,
      rep_info->attr_id,
      rep_info->manuf_code);

  is_manuf_spec = !!ZB_ZCL_IS_ATTR_MANUF_SPEC(attr_desc);

  /* ZCL spec, 2.4.11 Report Attributes Command */
  /* Read attribute command
     | ZCL header 3 b | Attr Report 1 XX b | Attr Report 1 XX b | ...

     Attr Report format
     | attr id 2 b |  Attr data type 1 b | attr value XX b |
  */
  /* Construct packet header */
  /* Use buffer specified by input param */
  cmd_data = ZB_ZCL_START_PACKET(param);

  /* NOTE: currently, manufacturer specific is not supported */
  ZB_ZCL_CONSTRUCT_GENERAL_COMMAND_REQ_FRAME_CONTROL_A(
    cmd_data, ZB_ZCL_FRAME_DIRECTION_TO_CLI,
    is_manuf_spec, ZB_ZCL_ENABLE_DEFAULT_RESPONSE);

  if (is_manuf_spec)
  {
    TRACE_MSG(TRACE_ERROR, "rep_info->manuf_code 0x%x", (FMT__D, rep_info->manuf_code));
    ZB_ASSERT(rep_info->manuf_code != ZB_ZCL_NON_MANUFACTURER_SPECIFIC);

    ZB_ZCL_CONSTRUCT_COMMAND_HEADER_EXT(cmd_data, ZB_ZCL_GET_SEQ_NUM(), ZB_TRUE, rep_info->manuf_code, ZB_ZCL_CMD_REPORT_ATTRIB);
  }

And it looks like ZB_ZCL_MANUF_CODE_INVALID = 0x0000 and ZB_ZCL_NON_MANUFACTURER_SPECIFIC = 0xFFFF. I guess the callstack up until this is a bit different as well. Perhaps the default (if nothing else is specified) manuf_spec code has changed from 0x0000 to 0xFFFF.

[quote user="pwpot"]AFAIU that single line forces us to give the standard cluster Manufacturer-specific code.

[/quote]

But only if

is_manuf_spec = !!ZB_ZCL_IS_ATTR_MANUF_SPEC(attr_desc);

is true, right?

Does this return true if you are using a standard cluster as well?

To me, it looks like if the command is for a manufacturer specific cluster, then it checks whether the manufacturer code is not 0x0000 (in v2.4.0) and not 0xFFFF (in 2.6.0). Are you seeing something else?

BR,

Edvin

RE: [Zigbee] Manufacturer Code clarification

Pawel(embeddedsolutions.pl) — Mon, 18 Mar 2024 14:12:41 GMT

Hi Edvin,

Thank you for the detailed description.

I am a little bit unsure about the manufacturer-specific attribute within the standard cluster scenario in terms of attribute reporting.

See zb_zcl_send_report_attr_command function:

void zb_zcl_send_report_attr_command(zb_zcl_reporting_info_t *rep_info, zb_uint8_t param)
{
  zb_uint8_t *cmd_data;
  zb_zcl_reporting_info_t *cur_rep_info;
  zb_zcl_attr_t *attr_desc;
  zb_uint16_t bytes_avail;
  zb_uint8_t attr_size;
  zb_uint8_t send_mode;
  zb_uint8_t is_manuf_spec;

  TRACE_MSG(
      TRACE_ZCL1,
      ">> zb_zcl_send_report_attr_command rep_info %p, param %hd",
      (FMT__P_H, rep_info, param));

  attr_desc =
    zb_zcl_get_attr_desc_a(rep_info->ep, rep_info->cluster_id, rep_info->cluster_role, rep_info->attr_id);

  is_manuf_spec = !!ZB_ZCL_IS_ATTR_MANUF_SPEC(attr_desc);

  /* ZCL spec, 2.4.11 Report Attributes Command */
  /* Read attribute command
     | ZCL header 3 b | Attr Report 1 XX b | Attr Report 1 XX b | ...

     Attr Report format
     | attr id 2 b |  Attr data type 1 b | attr value XX b |
  */
  /* Construct packet header */
  /* Use buffer specified by input param */
  cmd_data = ZB_ZCL_START_PACKET(param);

  /* NOTE: currently, manufacturer specific is not supported */
  ZB_ZCL_CONSTRUCT_GENERAL_COMMAND_REQ_FRAME_CONTROL_A(
    cmd_data, ZB_ZCL_FRAME_DIRECTION_TO_CLI,
    is_manuf_spec, ZB_ZCL_ENABLE_DEFAULT_RESPONSE);

  if (is_manuf_spec)
  {
    zb_af_endpoint_desc_t *ep_desc = zb_af_get_endpoint_desc(rep_info->ep);
    zb_zcl_cluster_desc_t *cluster_desc = get_cluster_desc(ep_desc, rep_info->cluster_id, rep_info->cluster_role);

    ZB_ASSERT(ep_desc && cluster_desc && cluster_desc->manuf_code != ZB_ZCL_MANUF_CODE_INVALID);

    ZB_ZCL_CONSTRUCT_COMMAND_HEADER_EXT(cmd_data, ZB_ZCL_GET_SEQ_NUM(), ZB_TRUE, cluster_desc->manuf_code, ZB_ZCL_CMD_REPORT_ATTRIB);
  }
  else
  {
    ZB_ZCL_CONSTRUCT_COMMAND_HEADER(cmd_data, ZB_ZCL_GET_SEQ_NUM(), ZB_ZCL_CMD_REPORT_ATTRIB);
  }

  cur_rep_info = rep_info;

  while (cur_rep_info)
  {
    attr_desc =
      zb_zcl_get_attr_desc_a(cur_rep_info->ep, cur_rep_info->cluster_id, cur_rep_info->cluster_role, cur_rep_info->attr_id);
    TRACE_MSG(TRACE_ZCL3, "attr_desc %p", (FMT__P, attr_desc));

    /* attribute description could not be absent, it is checked while accepting configure report
       command */
    ZB_ASSERT(attr_desc);

    bytes_avail = ZB_ZCL_GET_BYTES_AVAILABLE(param, cmd_data,
                                             cur_rep_info->dst.profile_id, cur_rep_info->cluster_id);
    TRACE_MSG(TRACE_ZCL3, "bytes_avail %hd", (FMT__H, bytes_avail));

    TRACE_MSG(
        TRACE_ZCL3,
        "attribute: id 0x%x, type 0x%hx",
        (FMT__D_H, attr_desc->id, attr_desc->type));
    attr_size = zb_zcl_get_attribute_size(attr_desc->type, attr_desc->data_p);
    TRACE_MSG(TRACE_ZCL3, "attr_size %hd", (FMT__H, attr_size));

    /* Decrement read attr response by sizeof(zb_uint8_t), because attr value size is
     * calculated separately by attr_size  */
    if (bytes_avail >= (sizeof(zb_zcl_report_attr_req_t) - sizeof(zb_uint8_t) + attr_size))
    {
      ZB_ZCL_PACKET_PUT_DATA16_VAL(cmd_data, attr_desc->id);
      ZB_ZCL_PACKET_PUT_DATA8(cmd_data, attr_desc->type);
      cmd_data = zb_zcl_put_attribute_value(cmd_data, attr_desc, attr_desc->data_p, attr_size);

      zb_zcl_save_reported_value(cur_rep_info, attr_desc);

      ZB_ZCL_CLR_REPORTING_FLAG(cur_rep_info, ZB_ZCL_REPORT_ATTR);
      ZB_ZCL_CLR_REPORTING_FLAG(cur_rep_info, ZB_ZCL_REPORT_IS_ALLOWED);
      ZB_ZCL_CLR_REPORTING_FLAG(cur_rep_info, ZB_ZCL_REPORT_TIMER_STARTED);
      ZB_ZCL_SET_REPORTING_FLAG(cur_rep_info, ZB_ZCL_REPORT_IS_SENT);
    }
    else
    {
      TRACE_MSG(TRACE_ZCL1, "ERROR, buffer is full", (FMT__0));
      break;
    }

    /* get next report info for sending report to the same remote device */
    cur_rep_info = zb_zcl_get_next_reporting_info(rep_info, is_manuf_spec);
    TRACE_MSG(TRACE_ZCL1, "cur_rep_info %p", (FMT__P, cur_rep_info));
  }

  /* We should always use bindings for reporting (ZCL8, 2.5.7.1.2; ZCL8, 2.5.11.2) */
  send_mode = ZB_APS_ADDR_MODE_DST_ADDR_ENDP_NOT_PRESENT;
  TRACE_MSG(TRACE_ZCL1, "ZCL_REPORT send mode ZB_APS_ADDR_MODE_DST_ADDR_ENDP_NOT_PRESENT:", (FMT__0));

  ZB_ZCL_FINISH_N_SEND_PACKET(param, cmd_data,
      rep_info->dst.short_addr,
      send_mode,
      rep_info->dst.endpoint,
      rep_info->ep /* src ep */,
      rep_info->dst.profile_id,
      rep_info->cluster_id,
      zb_zcl_reporting_cb);

  TRACE_MSG(TRACE_ZCL1, "<< zb_zcl_send_report_attr_command ", (FMT__0));
}

Especially that part :

 if (is_manuf_spec)
  {
    zb_af_endpoint_desc_t *ep_desc = zb_af_get_endpoint_desc(rep_info->ep);
    zb_zcl_cluster_desc_t *cluster_desc = get_cluster_desc(ep_desc, rep_info->cluster_id, rep_info->cluster_role);

    ZB_ASSERT(ep_desc && cluster_desc && cluster_desc->manuf_code != ZB_ZCL_MANUF_CODE_INVALID);

    ZB_ZCL_CONSTRUCT_COMMAND_HEADER_EXT(cmd_data, ZB_ZCL_GET_SEQ_NUM(), ZB_TRUE, cluster_desc->manuf_code, ZB_ZCL_CMD_REPORT_ATTRIB);
  }

is_manuf_spec is determined based on the attribute descriptor.

Assuming the manufacturer-specific attribute within the standard cluster has a REPORTING access set, then we have to pass the ASSERT condition which is:

ZB_ASSERT(ep_desc && cluster_desc && cluster_desc->manuf_code != ZB_ZCL_MANUF_CODE_INVALID)

AFAIU that single line forces us to give the standard cluster Manufacturer-specific code.

Let me know what you think.

Maybe things changed in NCS 2.6.0 and we are not aligned :)

I am looking forward to hearing from you

RE: [Zigbee] Manufacturer Code clarification

Edvin — Wed, 13 Mar 2024 13:56:35 GMT

Hello Pawel,

After consulting with our Zigbee team, this is what I got:

----------------------------

You need to use manufacturer code for any manufacturer specific extension.
As the spec (ZCL8 ch. 2.3.3) states, you can extend the standard in the following ways:

Add manufacturer specific clusters to a standard device endpoint.

Add manufacturer specific commands to a standard cluster.

Add manufacturer specific attributes to a standard cluster.

In all cases, you need to specify that the extension is manufacturer specific. So in the customer’s case, they will need to add ZB_ZCL_ATTR_MANUF_SPEC to the manufacturer specific attributes. The cluster itself does not need manufacturer code if it is a standard cluster.

When it comes to communication, all communication regarding the manufacturer specific extension must be transmitted with the manufacturer sub-field set to 1 and with the manufacturer code. That goes both for the device itself and for remote devices, e.g., a remote device sending a read attributes command to read the manufacturer specific attribute.

----------------------------

I hope this helps. Basically, all custom clusters, commands and attributes needs to set the manufacturer sub-field to 1, and use the manufacturer code that corresponds with this feature.

Best regards,

Edvin

RE: [Zigbee] Manufacturer Code clarification

Edvin — Mon, 11 Mar 2024 13:57:51 GMT

Hello Pawel,

I am terribly sorry for the delayed reply.

[quote user="pwpot"]I couldn't find any information regarding this. I think Option 2 is incorrect, and we should consider Options 1 and 3.[/quote]

I agree. But I will forward this to out Zigbee team for sanity checking.

RE: [Zigbee] Manufacturer Code clarification

Pawel(embeddedsolutions.pl) — Thu, 29 Feb 2024 10:30:45 GMT

I have changed the

#define ZB_MANUFACTURER_CODE_DSR 0x1234U
to some dummy value but still Node Descriptor was showing 0x1234. It seems that ZBOSS uses 0x1234 as default internally anyway but I have got good news :) I found following API in zboss_api.h :

/**
 * Set Manufacturer code of Node Descriptor Request
 *
 * @param manuf_code - manufacturer code to set
 * @param cb         - callback that is called after manufacturer code setting
*/
void zb_set_node_descriptor_manufacturer_code_req(zb_uint16_t manuf_code, zb_set_manufacturer_code_cb_t cb);

I call it in zboss_signal_handler on signal ZB_ZDO_SIGNAL_SKIP_STARTUP indicating that the stack is ready.

Callback returns RET_OK and Node Descriptor contains my custom Manufacturer Code, so I think the problem is solved.

Now I am waiting for your answer regarding dealing with Manufacturer-specific ZCL clusters, commands, and attributes and we are done

Regards,

Pawel

RE: [Zigbee] Manufacturer Code clarification

Pawel(embeddedsolutions.pl) — Thu, 29 Feb 2024 09:27:26 GMT

I understand. I will experiment more with the manufacturer codes to come up with some conclusions. Then, I will try to prepare a sample app for you, as the entire project is quite extensive.

In the meantime, could you please answer the questions below?

I would like to ensure correctness in dealing with Manufacturer-specific ZCL clusters, commands, and attributes. I aim to be consistent with the ZCL Specification and NCS throughout the process.

For standardizing ZCL clusters (e.g., Basic, Metering, etc.) and custom attributes within, I am considering the following options:

Option 1: The custom attribute has ZB_ZCL_ATTR_MANUF_SPEC access set, implying that the Cluster Descriptor should contain the Manufacturer code. Other devices in the network should then use the ZCL Header with the Manufacturer Specific bit set, along with the Manufacturer Code placed in the header, to perform ZCL:AttrWrite, ZCL:AttrRead, ZCL:ConfigureReporting on that attribute. I assume standard attributes should be accessed without the Manufacturer Specific bit and without the Manufacturer Code.

Option 2: The custom attribute has ZB_ZCL_ATTR_MANUF_SPEC set, but the Cluster Descriptor does not need to use the Manufacturer Code and be Manufacturer-specific. Other devices in the network should use the ZCL Header with the Manufacturer Specific bit set, along with the Manufacturer Code in the header, to perform ZCL:AttrWrite, ZCL:AttrRead, ZCL:ConfigureReporting on that attribute. I assume standard attributes should be accessed without the Manufacturer Specific bit and without the Manufacturer Code.

Option 3: The custom attribute does not have ZB_ZCL_ATTR_MANUF_SPEC access set, and the Cluster Descriptor does not need to use the Manufacturer Code and be Manufacturer-specific. Other devices in the network should use a simple ZCL Header without the Manufacturer Specific bit and without the Manufacturer code.

I couldn't find any information regarding this. I think Option 2 is incorrect, and we should consider Options 1 and 3.

For a custom ZCL Cluster with custom attributes within:

All attributes have ZB_ZCL_ATTR_MANUF_SPEC access set, and the Cluster Descriptor contains the Manufacturer Code. Other devices in the network should then use the ZCL Header with the Manufacturer Specific bit set, along with the Manufacturer Code in the header, to perform ZCL:AttrWrite, ZCL:AttrRead, ZCL:ConfigureReporting on these attributes.

Does this approach sound correct?

I am looking forward to hearing from you.

Pawel

RE: [Zigbee] Manufacturer Code clarification

Edvin — Thu, 29 Feb 2024 08:42:56 GMT

I didn't try to capture a sniffer trace, but I tried building the paplication after commenting out the ZB_MANUFACTURER_CODE_DSR and ZB_DEFAULT_MANUFACTURER CODE from zb_config_common.h, but perhaps it defaults to 0x1234 if t is not present. I tried building the basic light bulb/switch/coordinator trio, but I guess the bulb doesn't provide a manufacturer code, since it is not a custom cluster.

Can you try to insert your own manufacturer code in zb_config_common.h (ncs\nrfxlib\zboss\development\include\zb_config_common.h or ncs\nrfxlib\zboss\production\include\zb_config_common.h. Whichever you are using), and see if you are able to change it at all?

I understand your wish to do so without forking out of NCS, but I just want to check whether this instance of ZB_MANUFACTURER_CODE_DSR is being used at all.

If it is used, would it be possible to upload your application (or a stripped down version of it), so that I can poke around with the manufacturer codes?

Best regards,

Edvin

RE: [Zigbee] Manufacturer Code clarification

Pawel(embeddedsolutions.pl) — Wed, 28 Feb 2024 15:51:43 GMT

Hi Edvin,

Thank you for fast response.

ZB_DEFAULT_MANUFACTURER_CODE is indeed used by the stack.
Manufacturer Code 0x1234 (DSR) is used in Node Descriptor Response as an answer for Nordic Descriptor Request sent from parent device. Have a look on the screenshot below:

My goal is to have my custom (ofc certified by Zigbee Aliance) manufacturer code everywhere.
I am able to set it in Cluster descriptors and for FOTA purposes in OTA Upgrade cluster as well but it seems that the Node Descriptor Response still uses the DSR Manufacturer Code.
I would like to change ZB_DEFAULT_MANUFACTURER_CODE to custom one without needing to do the fork of NCS.
Is it possible ?

Thanks in advance,

Pawel

RE: [Zigbee] Manufacturer Code clarification

Edvin — Tue, 27 Feb 2024 14:34:12 GMT

Hello Pawel,

[quote user=""]What happens if the manufacturer code placed in the OTA Header of the received image is different from the one set on the device (0x127F by default)?[/quote]

According to the Zigbee FOTA library documentation, the image should only be accepted if the Manufacturer ID of the FOTA header matches, as well as the image type, Hardware version and Firmware version.

Regarding question 3 and 4. I assume it is possible to overwrite it, but I am not sure whether this code is even used at all. Unless the Zboss library (not open source) fetches the ZB_DEFAULT_MANUFACTURER_CODE and uses it, it is not used at all in the nRF Connect SDK. Seeing as it builds just fine without the ZB_DEFAULT_MANUFACTURER_CODE_DSR definition, I believe that isn't used anywhere. Remember that this library is not used on Nordic devices only. So perhaps it is used by other chip vendors.

To answer your second question, and all of them, I guess. If you intend to create a custom cluster, you must include a manufacturer_code. Before you start selling it, you need to certify it with the Zigbee Alliance, and for this, you are assigned your own company manufacturer code. So I believe they will tell you to use your custom manufacturer code for your own clusters. And I guess you are free to use either Nordic's or your own for the FOTA cluster, and as long as you use the same when generating FOTA images, that should work just fine.

Best regards,

Edvin