[Zigbee] Manufacturer Code clarification

[pwpot]

Setup: 

nrf52840DK (Zigbee Cordinator based on Zigbee Coordinator sample)

nrf52840DK (ZED)

nrf52840 dongle (Wireshark sniffer)

NCS v2.4.1

Hi,

In my application I am using Manufacturer specific ZCL commands and attributes. All of that seems working fine but I am little bit confused regarding the Manufacturer Code usage.

There are two magic values in NCS: 
0x1234 defined as:

#define ZB_MANUFACTURER_CODE_DSR            0x1234U
/* That is not a joke, our manufacturer code is really 1234! */
/*! @endcond */ /* internals_doc */

#define ZB_DEFAULT_MANUFACTURER_CODE ZB_MANUFACTURER_CODE_DSR

Manufacturer Code of DSR for all applications based on ZBOSS.

0x127F defined as: 

config ZIGBEE_FOTA_MANUFACTURER_ID
	hex "Manufacturer ID"
	default 0x127F
	range 0x0000 0xFFFF
	help
	  This is the ZigBee assigned identifier for each member company.
	  0x127F - Nordic Semiconductor
	  0xFFFF - wild card value has a 'match all' effect.

Manufacturer Code of Nordic Semiconductor used only for FOTA purposes to fill up OTA Header with it.

1. 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)?
2. Which Manufacturer Code should be used in Cluster descriptor ?
   

   /** @brief ZCL cluster description. */
   typedef ZB_PACKED_PRE struct zb_zcl_cluster_desc_s
   {
     zb_uint16_t cluster_id; /**< ZCL 16-bit cluster id. @see zcl_cluster_id */
     zb_uint16_t attr_count;  /**< Attributes number supported by the cluster */
     struct zb_zcl_attr_s *attr_desc_list; /**< List of cluster attributes,
            declared using ZB_ZCL_DECLARE_<CLUSTER_NAME>_ATTRIB_LIST() macro */
     zb_uint8_t role_mask;   /**< Cluster role, refer to zcl_cluster_role */
     zb_uint16_t manuf_code; /**< Manufacturer code for cluster and its attributes */
     zb_zcl_cluster_init_t cluster_init;
   } ZB_PACKED_STRUCT
   zb_zcl_cluster_desc_t;

3. Is it possible to overwrite #ZB_DEFAULT_MANUFACTURER_CODE ?
4. Why #ZB_DEFAULT_MANUFACTURER_CODE is not overwritten by Nordic Semiconductor Manufacturer Code (0x127F) ? 

I am looking forward to hearing from you,

Pawel

[Edvin]

Hello Pawel,

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

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

[pwpot]

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

[Edvin]

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

[pwpot]

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

[pwpot]

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