[TC-FAN] Clarify FanControl and OnOff cluster integration behavior

[Elen777300]

Summary Title:

[TC-FAN] Clarify FanControl and OnOff cluster integration behavior (Contradiction between TC-FAN-4.1 and TC-FAN-3.5)

Description:

There is a contradiction in the test plan regarding how the FanControl cluster is expected to interact with the OnOff cluster. The spec states that a product may use the On/Off cluster as a "Master" switch, but it does not mandate this behavior. Currently, our test scripts have conflicting expectations:

1. TC-FAN-4.1 assumes the OnOff cluster acts as a strict master switch. In step 11, it sends an Off command to the On/Off cluster. In step 16, it writes PercentSetting to 1 and verifies that PercentCurrent remains 0 (meaning the fan does not spin because the master switch was turned off).
2. TC-FAN-3.5 assumes the opposite default behavior. It immediately writes a value to PercentSetting and expects PercentCurrent to change, even though the device's OnOff cluster should technically be Off by default upon initialization.

Current Workaround:
To allow both tests to pass in our implementation, we had to introduce a conditional workaround: If the device is in its initial default Off state, writing to the fan settings will successfully turn the fan on (satisfying TC-FAN-3.5). However, if an explicit Off command was sent by the user/test (as in TC-FAN-4.1), writing to the fan settings will not turn it on.

This is a hack to bypass the conflicting test requirements. We are opening this issue to get clarification on the intended spec behavior so we can standardise the implementation and remove this workaround.

Steps to reproduce:

1. Run TC-FAN-4.1 and observe that an explicit Off command prevents a PercentSetting update from changing PercentCurrent.
2. Run TC-FAN-3.5 and observe that writing to PercentSetting directly after initialization (where the default state is implicitly Off) successfully changes PercentCurrent.
3. Note the conflicting assumptions about the OnOff cluster's "master switch" status between the two tests.

Logs:

N/A - This issue is a request for clarification on spec behavior and conflicting test plan requirements.

Additional Info:

• Sergio's PR Note: "The test plan assumes if the on/off cluster integration exists, the behavior is to obey on/off as the 'Master' switch to spin the fan. I think the spec says the product 'May' use the on/off in this way but doesn't mandate... let's follow whatever the test plan verifies for now and open an issue to clarify this behavior."

[cecille]

Is the problem here just that the test assumes the fan on/off cluster is on when the test starts? If so, just add a step to turn it on.

[jtrejoespinoza-grid]

Reading the spec there are some considerations in this issue.

The On/Off cluster is optional as defined in the Fan Cluster. Fan Cluster has as mandatory the FanControl, so the test should not assume the OnOff cluster is present, it needs to be indicated and take proper actions if implemented. This is the case for TC_FAN_4.1. Also as described when the OnOff cluster is present, this works as main switch before the FanControl which makes the attributes of the FanControl not to change when the device is Off and also block the attributes to be changed while the device is Off from the OnOff cluster and restore them when the device is turned On again.

Using the On/Off cluster alongside the Fan Control cluster allows the FanMode, SpeedSetting and PercentSetting to remain unchanged when the device is turned off. In this case, the On/Off cluster would be set to Off, and the SpeedCurrent and PercentCurrent set to zero, without changing FanMode, SpeedSetting and PercentSetting

As described in the spec the if OnOff cluster is not present , the attributes from FanControl must follow the rules from the FanMode. In this case if is Off and the PercentSetting is updated to 50, the other attributes as FanMode and SpeedSetting must update accordingly.

Maybe one thing we can add to those test is to ensure the device is Off/On for FanMode and for OnOff cluster depending on the scenario is under test.