-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial version of the Descriptor cluster #5020
Initial version of the Descriptor cluster #5020
Conversation
38386a3
to
17b8482
Compare
fb0d5d2
to
34f6a7b
Compare
<code>0xF003</code> | ||
<define>DESCRIPTOR_CLUSTER</define> | ||
<description>The Descriptor Cluster is meant to replace the support from the Zigbee Device Object (ZDO) for describing a node, its endpoints and clusters.</description> | ||
<attribute side="server" code="0x0000" define="DEVICE" type="ARRAY" entryType="DeviceType" length="254" writable="false" optional="false">device</attribute> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any other way to represent list other than type "ARRAY" to not use fixed length? The spec says the list should have one or more elements, why we set the length to 254 not other number?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any other way to represent list other than type "ARRAY" to not use fixed length? The spec says the list should have one or more elements, why we set the length to 254 not other number?
I agree this is confusing, but the length
argument here does not represent the size of the list, but the length in bytes of the related attribute.
In ZAP this argument is used for 2 things.
The first one is to generate the GENERATED_DEFAULTS
macro and store potential defaults for the attribute. In this case, it is basically unused, but at some point we could likely generate it directly for simple accessories and it may save some spaces.
The second case where it is used is to set the EmberAfAttributeMetadata
size field. This field is then used to allocate some spaces in the generatedData
global array, that will be used to store the attribute value itself.
I end up using 254
since this is the maximum value authorised in EmberAfAttributeMedata
currently, as it is a uint8_t
. But the actual length of the list is stored in the first 2 bytes of the attribute value in this patch and is retrieved as an uint16_t
.
The good thing about the current mechanism, where the length in bytes of attributes is defined ahead of time, is that you know how much space you need to store the attributes. The bad thing, is that it makes it harder for things such as list where the number of elements may vary.
I guess at some point we would have to look more deeper into the code that deals with attributes in the current ZCL stack...
FTR, this PR needs project-chip/zap#114 to land in order to work properly. |
@vivien-apple - could you fix merge errors (likely regenerate stuff)? it would be nice to have this within this week - probably TE1 cannot directly use it, but it still seems a good thing to have very early to iterate upon. |
ping @vivien-apple |
// The Descriptor Cluster instance on Endpoint 0 (zero) SHALL have a Parts attribute that lists all endpoint instances on a | ||
// node instance. | ||
// All local endpoints required by the device type(s) in the Device attribute SHALL be included in the Parts list. | ||
if (endpoint == 0x00 || (emberAfDeviceIdFromIndex(endpoint) == emberAfDeviceIdFromIndex(endpointIndex))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not quite following that second condition. You can have multiple same-type devices on the node, and devices don't span endpoints...
This hierarchical endpoint relationship will need to be expressed in the app config (i.e. the .zap file) and get spit out by codegen somewhere; I don't think our current generated code representes it. Please file a followup issue to do that?
Sorry. I'm still waiting on project-chip/zap#114 to be reviewed and landed before rebasing. This PR can not land without it as it will break the tree otherwise :/ |
8e9ab5c
to
6af9d6e
Compare
static void On{{asCamelCased parent.name false}}{{asCamelCased name false}}ListAttributeResponse(void * context, uint16_t count, _{{type}} * entries) | ||
{{else}} | ||
static void On{{asCamelCased parent.name false}}{{asCamelCased name false}}ListAttributeResponse(void * context, uint16_t count, {{chipType}} * entries) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a followup: we should strongly consider making the arg a Span<whatever-type>
....
6af9d6e
to
98dddbe
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, with the remaining suggestions applied.
Co-authored-by: Boris Zbarsky <[email protected]>
f17ba9b
to
cfa1db0
Compare
Size increase report for "esp32-example-build" from 524bafa
Full report output
|
Size increase report for "nrfconnect-example-build" from 524bafa
Full report output
|
* Add List[T] attribute support to src/app * Update the templates for List[T] supports * Add Descriptor cluster source code * Activate NetworkProvisiong, Descriptor and Group Key Management clusters * Update ZAP repo * Update the templates to fit ZAP update * Update gen/ folder * Update src/app/clusters/descriptor/descriptor.cpp Co-authored-by: Boris Zbarsky <[email protected]> * Apply suggestions from code review * Update src/app/util/af.h * Add 'descriptor' to the list of built cluster for the all-clusters-app Co-authored-by: Boris Zbarsky <[email protected]>
Problem
The
Descriptor
cluster is not implemented inCHIP
. TheDescriptor
cluster is meant to replaceZDO
for the discovery of endpoints and clusters on a target node.This PR introduce a first version of the
Descriptor
cluster with basic support forList[T]
in the attributes store.This PR contains the
Descriptor
cluster source code intosrc/app/clusters/descriptor
. As a result the attributes are defined during the setup phase of the cluster.I first did an initial version where the values of the attributes were statically defined when
ZAP
generates the file. It brings some size optimisations to the amount of memory consumes by the global attribute array but it may be hard to fit this model for theBridge
cluster.I think we may still want to do that for devices with low capacity thought. So maybe a different PR could fix the ZAP tool, to optimise the data if the
Bridge
cluster is not activated.Also this PR contains some basic support for
List[T]
. The tricky part was to getT
to work with the current attribute code since this one expectsT
to be one of the defined basic ZCL types (e.gINT8U
).At the moment the current code support
List[BASIC_TYPE]
and List[Struct]. It does not yet support nested
List. I have started to dig into it with the
ACLcluster (into
src/app/zap-templates/zcl/acl-cluster.xml`) but it it not fully done yet.Finally, this PR needs to come up with a patch into the ZAP repo (PR # to come).
Summary of Changes
Descriptor
cluster intosrc/app/zap-templates/zcl/descriptor-cluster.xml
ACL
cluster intosrc/app/zap-templates/zcl/acl-cluster.xml
src/app/clusters/descriptor
server
side intoall-clusters-app.zap
server
side intocontroller-clusters.zap
client
side intochip-tool.zap
List[T]
attribute