zap
zap copied to clipboard
project-chip
Extra clusters incorrectly added to a Matter device configuration
Reproduction steps
- Starting a new ZAP configuration from
template.zap - Change the device on Endpoint 1 to the Matter Robotic Vacuum Cleaner device.
- Filter the enabled clusters on this endpoint and notice that the Groups and Scenes clusters are enabled.
The expectation here in that the Groups and Scenes clusters should not be enabled as these are not part of the Matter Robotic Vacuum Cleaner device as described in the spec.
@hicklin this is by design. ZAP generally stores all the configurations made by the user into the .zap file in order to retrieve user settings back easily if they want to go back to all the edits made. For eg. user edits a cluster for attributes, commands, etc then by mistake disables the cluster then the user can enable the cluster back and retrieve the changes made. In this case updating the device type on an endpoint does not disable the existing clusters which have been enabled previously since the user may want all those changes. I believe that before you updated the device type to Matter Robotic Vacuum Cleaner, the previous device type had Groups and scenes enabled. I recommend that you delete the endpoint to loose all the configuration on that endpoint and recreate the endpoint with Matter Robotic Vacuum Cleaner device type.
@brdandu But should the invalid config not at least be flagged as a warning?
@brdandu But should the invalid config not at least be flagged as a warning?
I do not see this to be an invalid config for every use case. I always thought a user can select a device type as a baseline and then add on to the list of clusters coming from the device type for their specific purpose but I see how one could be warned with having a cluster that does not come from your selected device types on that endpoint.
I always thought a user can select a device type as a baseline and then add on to the list of clusters coming from the device type for their specific purpose
Matter is moving away from that, because that's not very interoperable. So in general, anything that's not allowed by the device type should be flagged (though perhaps not prevented for now).
Matter is moving away from that, because that's not very interoperable. So in general, anything that's not allowed by the device type should be flagged (though perhaps not prevented for now).
Just noticed this thread. This is related to the Feature Request I posted here: https://github.com/project-chip/zap/issues/1150 though I have a stronger view that there should be an enforced conformance to the specs.
My view is that there should be no cluster that are not either Mandatory or Optional for the device type. If this isn't the case, then "Optional" in the standard has no meaning as everything becomes Optional and, as prior post pointed out, its an interoperability nightmare that is best avoided. Until Matter controllers have the basics 100% right, less choice can be a benefit.
