Sort out how manufacturer-specific stuff is represented

project-chip / zap

ZAP stands for ZCL Advanced Platform. It is used to configure clusters, attributes and other entities for Matter and ZigbeePro applications.

Apache License 2.0

139 stars 83 forks source link

Sort out how manufacturer-specific stuff is represented #370

Open bzbarsky-apple opened 2 years ago

bzbarsky-apple commented 2 years ago

Matter doesn't have the "manufacturer code" concept in the same way as Zigbee. Identifiers (cluster, attribute, command, event, etc) can just be larger than 0xFFFF, which puts them in manufacturer-specific territory.

How does this get represented in the XML and in ZAP's model? How does this interact with the way structs are associated to clusters (by "code")?

It seems like we fundamentally need to allow "code" values greater than 0xFFFF, for the cluster-association bit to work, and stop using manufacturerCode in XML entirely?

@tecimovic @vivien-apple

bzbarsky-apple commented 2 years ago

Note that there's all sorts of int16ToHex in ZAP that would probably need to change if we allow non-uint16 codes. But I think we just need to change that.

vivien-apple commented 2 years ago

Per my understanding "manufacturer" code where replaced by MEI code.

For example, the standard "OnOff" cluster code, which used to be "0x0006" with previous ZCL version will be "0x00000006" while the "manufacturer" version of manufacturer with assigned code "0x1234" would be "0x12340006"

It seems like we fundamentally need to allow "code" values greater than 0xFFFF, for the cluster-association bit to work, and stop using manufacturerCode in XML entirely?

Agreed. That would require diving into the ZAP code to fix all the places where a 16 bits value is assumed.

brdandu commented 2 years ago

What do you think of:

For all clusters > 0xFFFF, extract the mfg code and non-mfg code from them and insert it into the existing backend model
Add loader constraints such that the user does not add any xml such that manufacturerCode and Code>0xFFFF contradict each other.

@bzbarsky-apple @vivien-apple does this satisfy the requirement or are we looking for something more specific?

bzbarsky-apple commented 2 years ago

For Matter, we just fixed the 16-bit assumptions on "code" so we can specify larger "code" values...

brdandu commented 2 years ago

For Matter, we just fixed the 16-bit assumptions on "code" so we can specify larger "code" values...

Is this not a high priority issue right now? I see that you made some changes for this in https://github.com/project-chip/zap/pull/371

bzbarsky-apple commented 2 years ago

I think that for Matter this is no longer high priority in that what we have right now works.