[1.2] [TC-LVL-3.1] Logic of Step 5f - 5j
Closed this issue · 7 comments
Feature Area
Other
Test Case
TC-LVL-3.1
Reproduction steps
Test step 5a writes 0x00 to the options attribute which disables execution if the EP is off. Step 5f sends an off command and after that a MoveToLevel (level to 120) command without any options modification gets sent. Because the options attribute is 0x00 and the EP is off nothing happens. The next test step though expects the current level to be 120. Same goes for the next two step respectively.
Step 5k sends along the MoveToLevel command an option override which enables execution if off. Step 5l succeeds because the new level gets applied.
In my perspective either the test step sequence is wrong or the expected return values a wrong.
I suggest to modify the expected current level values of the test steps 5h and 5j to be 1 (off). This ensures that the behaviour with options = 0x00 is correct and also if a command overrides the options attribute.
Bug prevalence
every time
GitHub hash of the SDK that was being used
Platform
darwin
Anything else?
No response
In the same context: Test step 6j fails because it expects the previous MoveToLevel command not to be executed, but it is. Therefore the read value is considered wrong.
Should this be a test plan issue?
In my perspective this is a test plan issue because the current test procedure is not compliant to the matter spec.
Can you raise this issue on the test plan repo?
Looking at this, 5g does a MoveToLevel to Level=120 and states in the expected outcome is "that the device remains in the off state."
5h then reads currentLevel and states: "Verify that the DUT response indicates that the CurrentLevel attribute (still) has the value given in 5d." and from what I can see they YAML also expects 100? This is also the case for 5i and 5j?
Well, maybe I have misinterpreted the standard. If a device receives an off command, it does not mean that the current level set to minimum? So if a MoveToLevel command gets sent, the current level gets updated but the device still remains off? Except when the ExecuteIfOff option is set?
After rereading the spec more carefully I have a better understanding of the dependency between the OnOff and LevelControl cluster now. I initially derived the OnOff attribute from the current level. But these attributes should be treated separately.
Sorry for the confusion, the test plan is correct.