Update cluster features in storage/consider only current and not stored features

[jpadie]

Suggestion that conformance errors are not automatically fatal errors in all cases. As an example use case:

set an onoff lighting device with colour support and colour temperature support and provide defaults for the mandatory attributes.
then remove colour temperature support.

the deployment will fail for conformance because an attribute is in the device storage that is contrary to the conformance requirements. But this could be silently ignored instead of resulting in a fatal error.

[Apollon77]

The issue is more that the storage contains meta data about features/clusters that are removed in the meantime ... so we need to see how we might support this.
Formally adding and removing clusters and features and attributes and commands should be possible - especially in a bridge

[jpadie]

The issue is more that the storage contains meta data about features/clusters that are removed in the meantime ... so we need to see how we might support this. Formally adding and removing clusters and features and attributes and commands should be possible - especially in a bridge

agreed that filtering the stored values is possibly a more elegant solution but is there not also a use case where a user may pass in (say) a valid but non-conforming attribute during runtime? would that result in a fatal error (if so, same concern) or be ignored?

[Apollon77]

if you do a "set" with an unconformant value then you will get an exception. Catch them and you can filter themnm most likely by the Error instance (ValidationError).