Silabs

[tecimovic]

• Fixes some UI issues
• Improves some TS stuff
• Deals with For Matter, reportability is entirely spec-defined, not user-controlled #368

[tecimovic]

For people mostly interested in hew "reportingPolicy" (@bzbarsky-apple , @mrjerryjohns ):

Attributes in the XML can now have following options:
reportingPolicy="prohibited"
reportingPolicy="optional"
reportingPolicy="suggested"
reportingPolicy="mandatory"

Prohibited and mandatory remove user option. (The UI is not yet following along, I'll add an issue to be fixed by the UI consultants).

For backwards compatibility:
reportable="true" is equivalent to reportingPolicy="suggested"
reportable="false" is equivalent to reportingPolicy="optional"

Where you had defaultReportable earlier, you can now specify defaultReportingPolicy and use one of the 4 options, so you don't have to type all of these into XML.

This is sorting out the data model and the schema. I did not touch the Matter XML, but I've added a simple example into Zap's unit test test1.xml file.

[bzbarsky-apple]

I only reviewed the reporting policy changes.

They are OK as far as they go, but:

1. They do not affect the value returned from endpointTypeAttribute queries in any way.
2. There is, as far as I can tell, no way to get to the attribute-defined policy from the endpointTypeAttribute query.

so none of this really solves things for Matter on its own. We can specify the reporting policy all we want, and it will just be ignored in the data we actually have to work with.

Could we expose the policy in the queries that use endpointTypeAttribute for mapping?

[tecimovic]

@bzbarsky-apple : i see... You have data that already circumvented this policy and you need to deal with this.
This is essentially a data upgrading problem, similar to what happens if spec version 2 declared some attributes as "mandatory reporting", where earlier they were "optional" and users turned them off in the ZAP file.

I can do this:

• when reading user configuration, if the configuration conflicts with the static attribute setting, UI will show a warning or something. We could also provide a "data upgrade" option with "spec force" which would cause the data in the ZAP file to be properly "fixed" by forcing it to comply with the spec.

Would that work?

It's also an entry towards this much larger process that we will have to do with at some point:
how to upgrate zap files made with older spec, to the latest spec....

[bzbarsky-apple]

Fundamentally, we don't want to be getting this information from the zap files at all, for Matter. We want to be getting it directly from the XML. But the queries we have to work with don't seem to expose it?

[tecimovic]

@bzbarsky-apple :
I have added the logic, which will peg the boolean in the zap file to the value from XML upon loading the file, if the policy is "mandatory" or "prohibited".

You are correct, that in case of these policies, we shouldn't even have a boolean in the ZAP file. We'll address this as part of the UI fix to properly make UI follow this.