-
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
Add a way to run custom cluster logic for attribute reads #9667
Add a way to run custom cluster logic for attribute reads #9667
Conversation
We should probably clone the writer and convert failures hereconnectedhomeip/src/app/util/ember-compatibility-functions.cpp Lines 206 to 216 in a3951b5
This comment was generated by todo based on a
|
Add DataVersion supportconnectedhomeip/src/app/util/ember-compatibility-functions.cpp Lines 212 to 221 in a3951b5
This comment was generated by todo based on a
|
a3951b5
to
c2659d0
Compare
c2659d0
to
6216258
Compare
Well, I am not able to find a practical way to verify the correctness of those diagnostic attribute in CI, since we don't have the reference value of those physical info from platform in real-time. The test was done by reading those diagnostic Ethernet network attributes using chip-tool , such as ./chip-tool ethernetnetworkdiagnostics read packet-rx-count 0, then compare them with the output of ifconfig and netstat. |
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 next step I would be happy to hear your thoughts on how to connect this machinery to ZAP in order to not have to generate useless defaults in this case (thinking about the descriptor
cluster use case...).
Since interceptors are not granular at the AttributeId
level, it may make it hard to know which attributes needs generated defaults and which one does not.
src/app/clusters/ethernet_network_diagnostics_server/ethernet_network_diagnostics_server.cpp
Outdated
Show resolved
Hide resolved
src/app/clusters/ethernet_network_diagnostics_server/ethernet_network_diagnostics_server.cpp
Outdated
Show resolved
Hide resolved
src/app/clusters/ethernet_network_diagnostics_server/ethernet_network_diagnostics_server.cpp
Outdated
Show resolved
Hide resolved
src/app/clusters/ethernet_network_diagnostics_server/ethernet_network_diagnostics_server.cpp
Outdated
Show resolved
Hide resolved
src/app/clusters/ethernet_network_diagnostics_server/ethernet_network_diagnostics_server.cpp
Outdated
Show resolved
Hide resolved
src/app/clusters/ethernet_network_diagnostics_server/ethernet_network_diagnostics_server.cpp
Outdated
Show resolved
Hide resolved
Yes, we need to do that. The basic problem is that the source of truth for what the cluster is doing is the cluster code, but we need to get information like "don't generate storage for this" into the ZAP pipeline. I don't have any better ideas so far than @tecimovic's suggestion to have an SDK configuration thing where we basically have a list we provide to ZAP of attributes to not generate storage for.... |
0c05150
to
8bdbe09
Compare
@msandstedt @saurabhst @LuDuda @andy31415 @mspang @jepenven-silabs Please take a look? |
…e reads. This allows a cluster implementation to provide custom logic for an attribute read without requiring the attribute to be marked external and needing to trampoline through the app callback.
…tics cluster. This just adds the class and registration machinery for it. It does not produce any data yet. The build system changes are for various example apps that enabled the diagnostics clusters in their ZAP configuration but did not actually compile in the code for them. Those stop linking with this change, since they don't include the cluster init function.
Instead handle ethernet network diagnostics via an attribute override.
8bdbe09
to
7dbfb82
Compare
Looks ready for review. @msandstedt @andy31415 @mspang @Damian-Nordic @LuDuda ? |
Size increase report for "gn_qpg-example-build" from 4763c91
Full report output
|
Size increase report for "nrfconnect-example-build" from 4763c91
Full report output
|
Size increase report for "esp32-example-build" from 4763c91
Full report output
|
…ip#9667) * Add machinery to allow a cluster implementation to intercept attribute reads. This allows a cluster implementation to provide custom logic for an attribute read without requiring the attribute to be marked external and needing to trampoline through the app callback. * Add a no-op attribute access override to the Ethernet Network Diagnostics cluster. This just adds the class and registration machinery for it. It does not produce any data yet. The build system changes are for various example apps that enabled the diagnostics clusters in their ZAP configuration but did not actually compile in the code for them. Those stop linking with this change, since they don't include the cluster init function. * Stop using the external attribute callback in lighting-app. Instead handle ethernet network diagnostics via an attribute override. * Disallow registering conflicting attribute access overrides.
Problem
At the moment we can either have cluster attributes living in the "global" attribute store or get an application-level callback called by marking them "external".
Change overview
Add a way to have SDK-internal logic run to produce attribute values, in TLV form only.
This mechanism, when it's used, gets first crack at the value; if it doesn't want to provide one we fall back to asking the attribute store (which might call into the external attribute machinery).
For review purposes: It's probably best to review the three changesets one at a time.
Testing
This part I need to sort out. I don't know how #9587 was tested, but we should presumably do the same tests here to verify that this all works. @yufengwangca