Zigbee read attribute request not well managed ?

[Elyxoft]

Hi,

I have an issue when I want to read an attribute from a toll to my nrf52840 device.

For exemple attribut 0 of cluster basic, if I forge a general read request for this public attribute, nRF answer correctly, but is I do the same request on an attribut 0 of cluster basic with a manufacturer code, nRF answer with the value of the public attribute, it shall send an unsupported attribute in place.

Is it a bug of zboss 3.3 stack ? How to well managed manufacturer attribute field for read/write request ?

regards,

Elyxoft

[Marte Myrvold]

Hi Elyxoft,

Elyxoft said:

2.5.1.1.1 ZCL Header Fields

This part of the specification specifies what the read attributes command should look like when it is sent from a device, and not how the receiving device should handle a command depending on the ZCL header field.

The manufacturer specific sub-field SHALL be set to 0 if this command is being used to Read Attributes defined for any cluster in the ZCL or 1 if this command is being used to read manufacturer specific attributes.

According to this, the read attributes command you are sending from your device is incorrect and not according to the specification. Since the command is used to read attribute 0x0007 of the Basic cluster, both a cluster and an attribute that are defined in the ZCL, the manufacturer specific sub-field shall be set to 0. 

Elyxoft said:

An attribute set as manufacturer specific is not the same as a public attribute and the way to check it is done on the zcl header field.

Yes, the ZCL header field is used to check if the command refers to a manufacturer specific extension. However, these manufacturer specific extensions can be of the following:

• 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.

When adding a manufacturer specific attribute to a standard cluster, the attribute ID should not be an ID that is already used by a standard attribute in the cluster.

I agree that the ZCL specification is not clear enough regarding this, which opens the possibility for different ways to interpret what the specification is saying. According to 2.5.1.1.1 ZCL Header Fields, the manufacturer field shall be set depending on whether the command is used to read a manufacturer specific attribute, or an attribute defined for any cluster in ZCL. Reading the PowerSource attribute in the Basic Cluster will be to read an attribute defined for a cluster in ZCL. However, you can argue that setting the manufacturer specific sub-field will make the attribute manufacturer specific, but in this case you are still using an attribute identifier that is already defined for a cluster in ZCL. Additionally, according to 2.5.1.3 Effect on Receipt, the only check is whether the attribute identifier corresponds to an attribute that exists on the device, which it does, as attribute 0x0007 (PowerSource) in cluster 0x0000 does exist.

Best regards,

Marte

[Elyxoft]

Hi,

Not agree section 2.5.1.1 is apply for generate and receive, generate specific section is specified in 2.5.1.2 and receive in 2.5.1.3. so when you do a manufacturer specific request only attributes set has manufacturer are concerned in the same way when you do a public request only public attributes are concerned.

When adding a manufacturer specific attribute to a standard cluster, the attribute ID should not be an ID that is already used by a standard attribute in the cluster.

You right since HA1.2 we can not use an existing id to put a manufacturer id, but if you try to read a manufacturer attribut with a silly tool, you have no reason to receive the value of the public attribute, it is not what you are request and the message if conform to specification, it is a stupid request ? yes. But conform and the answer is not. I have the same trouble when I request a anttribute id set as manufacturer and forge my request for a public attribute.

I search the PICS document but it can take time before I found the test apply to readattribute request during certification.

regards,

Elyxoft