[Test Script Issue][TC-SC-5.2] step 15 use OnOff cluster to test group command, if a DUT did not support OnOff cluster, then it would fail to PASS step 16

[Aimeezhang2022]

[TC-SC-5.2] step 15 use OnOff cluster to test group command, if a DUT did not support OnOff cluster, then it would fail to PASS step 16
           # Step 15: Send group command via GroupID 0x0103
            self.step("15")
            dev_ctrl.SendGroupCommand(0x0103, Clusters.OnOff.Commands.On())
            await asyncio.sleep(3)
            # Step 16: Validate group command received
            self.step("16")
            on_off = await self.read_single_attribute_check_success(endpoint=groups_endpoint,
                                                                    cluster=Clusters.OnOff, attribute=Clusters.OnOff.Attributes.OnOff)

            asserts.assert_true(on_off, "OnOff should be TRUE after group On command")
            await dev_ctrl.SendCommand(node_id, groups_endpoint, Clusters.OnOff.Commands.Off())

            # restore the GroupInfo for groupID 0x0103 to use Per-Group address policy
            dev_ctrl.SetGroupInfo(0x0103, "Group #3")

[KishokG]

@jmartinez-silabs Can you please take a look into it?

[cecille]

Suggestion from a discussion with me and Tennessee - this piece of the test is for groups, which are being deprecated post 1.6. Suggestion here is to use the identify cluster because it's possible to check the side effects and most (all?) device types that require a groups cluster require an identify cluster. If the identify cluster doesn't exist, just skip the step because it's probably fine and that's probably just some groups cluster randomly hanging out for no reason and it's not worthwhile to jump through hoops to verify something that's on the way to being dead and probably not a part of a real device type anyway.

[jmartinez-silabs]

@cecille Yes from what I saw all device type mandating groups have identify.

We will have similar probleme those with testing multicast message with groupcast.
#970

We can extend the list of clusters for the time being but it might become hard maintain.

[Sumith-grl]

@jmartinez-silabs , could you please confirm whether this issue will be fixed in the 1.6 release or deferred to 1.6.1 ?

[jmartinez-silabs]

@Sumith-grl this can be for 1.6 but Im out of office all week. If you are expecting me to chance this test it will have to wait at least another week

[KishokG]

@jmartinez-silabs Thanks for the update. Also please note that, if we're planning to fix this issue for 1.6 final release, the deadline is 15th of May...

[jmartinez-silabs]

@KishokG I am working on updating the test script and it will require a step update in the test plan too but all this is only needed for 1.6.1 and not 1.6.

The problematic steps (15 and 16) are only done in the Groupcast case which is now provisional for 1.6.
See step 12

If Groupcast cluster is NOT enabled on the RootNode endpoint of the DUT or its Listener feature is disabled, skip to step 17. Otherwise, TH sends the Groupcast cluster’s LeaveGroup command on the DUT on EP0 with GroupID 0 (leave all groups)