Need some manufacturer-specific attributes/commands/clusters in test apps

[Survensa]

CHIP Spec section 7.19 needs to be developed to support from Chip-tool to verify the DUT.

Tracking purpose raising this ticket in SDK bucket

[cjandhyala]

Implement a few manufacturer-specific extensions in one of the reference app, so that when controllers are tested, we'd like to make sure controllers do not crash when talking to the controlee that has these extensions implemented.

[andy31415]

Since this is a MAY setting in the spec, it sounds like the SDK could be certifiable without any of these implemented.

I understand the goal is "do not crash if you see something optional" however in list of priorities, implementing anything optional should not be a priority.

[woody-apple]

Cert Blocker Review: May not be a cert blocker, but needs further discussion.

[woody-apple]

Cert Blocker Review: @cjandhyala @mrjerryjohns and @woody-apple to follow up.

[robszewczyk]

MEI is part of the spec; we need to ensure proper encoding & decoding in the SDK s.t. MEI adheres to the spec. Suggest: write a controller-oriented test that produces responses with MEI to verify correct controller behavior. Definitely cert blocker.

[woody-apple]

Cert Blocker Review: Per @cjandhyala there is an existing ticket on the test plan side here.

Per @tcarmelveilleux's suggestion, let's add a simple MEI command/example to the all clusters app, and tooling (if needed).

[woody-apple]

Cert Blocker Review: @andy31415 to find an assignee.

[andy31415]

Spec 10.3.10 for field IDs says "Support for encoding FieldIDs with an MC sources is provisional" which as I understand from @bzbarsky-apple seems to mean "1.0 support not really needed". Generally this seems like it would require more SDK changes so we should focus on some sample attributes/commands for now.

[andy31415]

Thins we likely need to track here:

• add an extension attribute (Mei data in all clusters #19274 does that)
• add an extension command (tried that, some compile errors so this needs tracking down)
• add an extension event
• add a manufacturer specific cluster.I would propose to move TestCluster from 0x50F to something like 0xFFF1050F - this will make it both used and an actual valid ID.

[andy31415]

TestCluster is now a manufacturer specific extension. Left todo:

• attributes (PR pending)
• commands - not possible in V1 timeframe - adding a MEI for a command requires it to be available within the entire SDK due to how our codegen and dependencies work
• events - to be investigated.

[andy31415]

MEI commands added for ModeSelect cluster in all-clusters-app.

[andy31415]

For events, extensions containing events do not seem supported by https://github.com/project-chip/zap/blob/master/zcl-builtin/shared/schema/zcl.xsd

At this time, the file describes:

  <xs:element name="clusterExtension">
    <xs:complexType>
      <xs:sequence>
        <xs:element minOccurs="0" maxOccurs="unbounded" ref="attribute"/>
        <xs:element minOccurs="0" maxOccurs="unbounded" ref="command"/>
      </xs:sequence>
      <xs:attribute name="code" use="required" type="xs:string"/>
      <xs:attribute name="introducedIn" type="zclSpecVersion"/>
    </xs:complexType>
  </xs:element

We are missing "structures" (this is known) and "events".
As a result, for 1.0 we will only have ability to test fully custom clusters (TestCluster is an example of such) and existence of extension attributes (ModeSelect in all clusters is such an example, with the note that it will be listed as available but will NOT be interactable on purpose)