You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today, the Groups cluster implementation for Servers forces feature bit 0 (GN) to be 1/true. This is regardless of what the zap file configuration of the cluster indicates. The consequence of this is that a device maker who uses the provided groups-server.cpp won't actually know what their PICS should be. A device maker should be able to determine their PICS for their device using two inputs, the zap file or their own application code.
Since the Groups cluster ignores the zap file and doesn't allow the application code to make a choice about NameSupport via its Init function, then the device maker might reasonably set their PICS for G.S.F00 to 0/false. Then, when they try to test their device for certification, they will get failures in one or more Groups tests and not understand why.
Taking feature bit values from the zap file and allowing them to be overridden by Init API calls is a reasonable way to ask thousands of device makers to fill out their PICS. Asking thousands of device makers to read the implementation code for every cluster provided by the SDK in order to determine their PICS is not.
Problem
Today, the Groups cluster implementation for Servers forces feature bit 0 (GN) to be 1/true. This is regardless of what the zap file configuration of the cluster indicates. The consequence of this is that a device maker who uses the provided groups-server.cpp won't actually know what their PICS should be. A device maker should be able to determine their PICS for their device using two inputs, the zap file or their own application code.
Since the Groups cluster ignores the zap file and doesn't allow the application code to make a choice about NameSupport via its Init function, then the device maker might reasonably set their PICS for G.S.F00 to 0/false. Then, when they try to test their device for certification, they will get failures in one or more Groups tests and not understand why.
Taking feature bit values from the zap file and allowing them to be overridden by Init API calls is a reasonable way to ask thousands of device makers to fill out their PICS. Asking thousands of device makers to read the implementation code for every cluster provided by the SDK in order to determine their PICS is not.
See lines 155 and 163 here: https://github.com/project-chip/connectedhomeip/blob/5aa5e8e/src/app/clusters/groups-server/groups-server.cpp#L150
I do not believe this should block 1.0 certification.
Proposed Solution
Two choices:
The text was updated successfully, but these errors were encountered: