-
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
[TC-DT-1.1] Fix Wild card read if thread diagnostic attributes on wifi devices. #28739
[TC-DT-1.1] Fix Wild card read if thread diagnostic attributes on wifi devices. #28739
Conversation
…butes for non thread device that would have the cluster enabled
PR #28739: Size comparison from 30e4169 to 7a6768e Increases above 0.2%:
Increases (17 builds for cc32xx, cyw30739, efr32, esp32, linux, mbed, nrfconnect, psoc6, telink)
Decreases (9 builds for bl602, bl702, bl702l, efr32, telink)
Full report (60 builds for bl602, bl702, bl702l, cc32xx, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
To my understanding a wi-fi based device is not allowed to have the Thread network diag cluster in the server list, so ideally we should not need this work-around and instead we should fix the zap files to actually match the spec? |
The only way to do that would be for each different manufacturer, or at least each different network platform to create and use its own Based on the conversations, I believe this is currently the best option. |
I understand, but the issue is if we are actually violating the spec by having Thread Diag enabled on devices that does not support Thread, If this is the case, I would argue we would need to (and properly should) do different zap files depending on the network interfaces. |
…butes for non thread device that would have the cluster enabled (project-chip#28739)
Issue:
TC-DT-1.1 wild card read would fail on our wifi platform running the doorlock app using the common data model config (.zap and .matter files). Other WiFi platforms probably encounter the same failure if they use common data models of the examples.
Fix:
In the case of non-thread devices that would have the ThreadDiagnostic Cluster enabled, we encode null (for nullable attributes) or the default values of the attributes instead of erroring the read command with
CHIP_ERROR_UNSUPPORTED_CHIP_FEATURE