-
-
Notifications
You must be signed in to change notification settings - Fork 57
Expand file tree
/
Copy pathchipTestsSummary.log
More file actions
203 lines (201 loc) · 22.2 KB
/
Copy pathchipTestsSummary.log
File metadata and controls
203 lines (201 loc) · 22.2 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
Chip tests run started at 2026-08-20T22:27:56.286Z
✅ Generic device basic composition (TC_DeviceBasicComposition.py)
✅ Generic device conformance (TC_DeviceConformance.py)
✅ Generic device default warnings (TC_DefaultWarnings.py)
✅ Generic TestEventTrigger command (TC_TestEventTrigger.py)
✅ BasicInformation attributes with server-as-subject on RootNode (TC_BINFO_2_1.py)
✅ BasicInformation attributes with node-as-subject on RootNode (TC_BINFO_2_2.py)
⏭️ BasicInformation ProductAppearance on RootNode (TC_BINFO_3_1.py)
↳ Gated by @run_if_endpoint_matches(has_attribute(ProductAppearance)); Matterbridge doesn't implement ProductAppearance (BINFO.S.A0014=0 in matterbridge.pics), so it always skips.
✅ BasicInformation reboot count via app-pipe on RootNode (TC_BINFO_3_2.py)
✅ PowerSource attributes on RootNode on RootNode (Test_TC_PS_2_1)
✅ PowerSource event reporting with server as DUT on RootNode (Test_TC_PS_2_2)
✅ PowerSource battery reporting frequency on RootNode (TC_PS_2_3.py)
⏭️ Descriptor cluster attributes on RootNode (Test_TC_DESC_2_1)
↳ Every step in this YAML is disabled:true (manual chip-tool verification procedure, no automated assertions) and no TC_DESC_*.py exists either — it always runs 0 steps regardless of PICS.
✅ AccessControl simple attributes on RootNode (Test_TC_ACL_2_1)
✅ AccessControl attributes with server as DUT (TC_ACL_2_2.py)
✅ AccessControl Extension attribute on RootNode (TC_ACL_2_3.py)
✅ AccessControl write/read of Acl attribute on RootNode (TC_ACL_2_4.py)
✅ AccessControl event reporting with server as DUT on RootNode (TC_ACL_2_5.py)
⏭️ AccessControl commissioning event on RootNode (TC_ACL_2_6.py)
↳ Expects to read back the AccessControlEntryChanged event generated when TH1's admin entry was added during PASE commissioning. This harness reuses chip-tool's baked-in pairing instead of live-commissioning the DUT per test, so that event was never generated in this session and the test fails with IndexError on an empty event list.
✅ AccessControl multi-fabric Extension attribute on RootNode (TC_ACL_2_7.py)
⏭️ AccessControl multi-fabric Acl attribute and events on RootNode (TC_ACL_2_8.py)
↳ Test commissions its own fresh TH1 (nodeId=1)/TH2 (nodeId=2) fabrics and validates AccessControlEntryChanged events against them; observed event data (nested fabricIndex inconsistent with the outer event's fabricIndex) doesn't match what the test expects, failing an assert_equal on valid-event count. Reproducible from a fresh --start, independent of test order — needs deeper investigation before enabling.
✅ AccessControl multi-fabric ACL/Extension write with node-as-subject on RootNode (TC_ACL_2_9.py)
✅ AccessControl multi-fabric ACL/Extension write with server-as-subject (TC_ACL_2_10.py)
⏭️ AccessControl Managed Device feature (ARL) on RootNode (TC_ACL_2_11.py)
↳ Requires the MNGD/AUX features (Managed Device / Auxiliary ACL) with manufacturer-populated ARL/CommissioningARL restrictions. Matterbridge's AccessControl cluster only implements the EXTS feature (FeatureMap=1), so ARL/CommissioningARL are never populated and the test fails an assert_true immediately.
⏭️ GeneralDiagnostics attributes on RootNode (Test_TC_DGGEN_2_1)
↳ Uses SDK-CI-only pseudo-clusters (SystemCommands.FactoryReset, CommissionerCommands.PairWithCode) this harness's yaml runner can't handle — the spawned chip-tool interactive server crashes before opening its websocket port ('WebSocket startup has not been detected'), independent of PICS or retries.
⏭️ GeneralDiagnostics events with server as DUT (Test_TC_DGGEN_2_2)
↳ Every step in this YAML is disabled:true (manual verification procedure, no automated assertions).
✅ GeneralDiagnostics PayloadTestRequest command on RootNode (Test_TC_DGGEN_2_3)
✅ GeneralDiagnostics attributes with node-as-subject on RootNode (TC_DGGEN_2_4.py)
✅ GeneralDiagnostics RebootCount across a second fabric on RootNode (TC_DGGEN_2_5.py)
✅ GeneralDiagnostics TestEventTrigger on RootNode (Test_TC_DGGEN_3_1)
✅ GeneralDiagnostics TestEventTrigger with server as DUT on RootNode (TC_DGGEN_3_2.py)
✅ GroupKeyManagement attributes on RootNode (Test_TC_GRPKEY_2_1)
✅ GroupKeyManagement KeySet commands on RootNode (Test_TC_GRPKEY_2_2)
⏭️ GroupKeyManagement max group keys manual verification (Test_TC_GRPKEY_5_4)
↳ Every step in this YAML is disabled:true (manual verification procedure, no automated assertions).
✅ OperationalCredentials basic node operational credentials on RootNode (TC_OPCREDS_3_1.py)
✅ OperationalCredentials AddNOC for a new fabric on RootNode (TC_OPCREDS_3_2.py)
⏭️ OperationalCredentials attestation and CSR on RootNode (Test_TC_OPCREDS_3_3)
↳ Every step in this YAML is disabled:true (manual verification procedure, no automated assertions).
⏭️ OperationalCredentials UpdateNOC error conditions on RootNode (TC_OPCREDS_3_4.py)
↳ Expects exactly 1 entry in TrustedRootCertificates, but finds 2 (the same root cert, one normal-sized and one padded to max size) even from a fully fresh unpair+repair cycle. Caused by the Python test framework's own maximize_cert_chains:true default during commission-only, not a Matterbridge behavior — needs a way to disable that default for this harness's commissioning flow before enabling.
✅ OperationalCredentials UpdateNOC on RootNode (TC_OPCREDS_3_5.py)
⏭️ OperationalCredentials RemoveFabric manual verification on RootNode (Test_TC_OPCREDS_3_6)
↳ Every step in this YAML is disabled:true (manual verification procedure, no automated assertions).
✅ OperationalCredentials UpdateFabricLabel on RootNode (Test_TC_OPCREDS_3_7)
⏭️ OperationalCredentials VID verification statement on RootNode (TC_OPCREDS_3_8.py)
↳ Fails at import time: ModuleNotFoundError: No module named 'nest_asyncio' — missing Python dependency in this image, unrelated to Matterbridge.
✅ GeneralCommissioning attributes on RootNode (TC_CGEN_2_1.py)
✅ GeneralCommissioning ArmFailSafe command on RootNode (TC_CGEN_2_2.py)
✅ GeneralCommissioning OpenCommissioningWindow error conditions on RootNode (TC_CGEN_2_4.py)
✅ GeneralCommissioning SetTCAcknowledgements on RootNode (TC_CGEN_2_5.py)
✅ GeneralCommissioning CommissioningComplete without required terms on RootNode (TC_CGEN_2_6.py)
✅ GeneralCommissioning CommissioningComplete with invalid terms on RootNode (TC_CGEN_2_7.py)
✅ GeneralCommissioning TCAcknowledgements reset after factory reset on RootNode (TC_CGEN_2_8.py)
✅ GeneralCommissioning TCAcknowledgements reset after all fabrics removed on RootNode (TC_CGEN_2_9.py)
✅ GeneralCommissioning required TCAcknowledgements can't be unset on RootNode (TC_CGEN_2_10.py)
✅ GeneralCommissioning TCAcknowledgements update after commissioning on RootNode (TC_CGEN_2_11.py)
✅ ElectricalPowerMeasurement attributes on ElectricalSensor (TC_EPM_2_1.py)
✅ ElectricalPowerMeasurement primary functionality on ElectricalSensor (TC_EPM_2_2.py)
✅ ElectricalEnergyMeasurement attributes on ElectricalSensor (TC_EEM_2_1.py)
✅ ElectricalEnergyMeasurement cumulative imported functionality on ElectricalSensor (TC_EEM_2_2.py)
✅ ElectricalEnergyMeasurement cumulative exported functionality on ElectricalSensor (TC_EEM_2_3.py)
⏭️ ElectricalEnergyMeasurement periodic imported functionality on ElectricalSensor (TC_EEM_2_4.py)
↳ Requires the PeriodicEnergy feature; endpoint 206 does not enable this optional feature.
⏭️ ElectricalEnergyMeasurement periodic exported functionality on ElectricalSensor (TC_EEM_2_5.py)
↳ Requires the PeriodicEnergy feature; endpoint 206 does not enable this optional feature.
✅ DeviceEnergyManagement attributes on DeviceEnergyManagement (TC_DEM_2_1.py)
✅ DeviceEnergyManagement PowerAdjustment functionality on DeviceEnergyManagement (TC_DEM_2_2.py)
⏭️ DeviceEnergyManagement StartTimeAdjustment functionality on DeviceEnergyManagement (TC_DEM_2_3.py)
↳ Requires the StartTimeAdjustment feature; endpoint 207 does not enable this optional feature.
⏭️ DeviceEnergyManagement Pausable functionality on DeviceEnergyManagement (TC_DEM_2_4.py)
↳ Requires the Pausable feature; endpoint 207 does not enable this optional feature.
⏭️ DeviceEnergyManagement ForecastAdjustment with power forecast on DeviceEnergyManagement (TC_DEM_2_5.py)
↳ Requires the ForecastAdjustment feature; endpoint 207 does not enable this optional feature.
⏭️ DeviceEnergyManagement ForecastAdjustment with state forecast on DeviceEnergyManagement (TC_DEM_2_6.py)
↳ Requires StateForecastReporting and ForecastAdjustment features; endpoint 207 does not enable these optional features.
⏭️ DeviceEnergyManagement ConstraintBasedAdjustment with power forecast on DeviceEnergyManagement (TC_DEM_2_7.py)
↳ Requires the ConstraintBasedAdjustment feature; endpoint 207 does not enable this optional feature.
⏭️ DeviceEnergyManagement ConstraintBasedAdjustment with state forecast on DeviceEnergyManagement (TC_DEM_2_8.py)
↳ Requires StateForecastReporting and ConstraintBasedAdjustment features; endpoint 207 does not enable these optional features.
✅ DeviceEnergyManagement PowerForecastRReporting functionality on DeviceEnergyManagement (TC_DEM_2_9.py)
✅ DeviceEnergyManagement quiet-reporting quality on DeviceEnergyManagement (TC_DEM_2_10.py)
✅ DeviceEnergyManagementMode attributes on DeviceEnergyManagement (TC_DEMM_1_2.py)
✅ DeviceEnergyManagementMode change mode on DeviceEnergyManagement (Test_TC_DEMM_2_1)
✅ PowerSource battery attributes on ContactSensor (Test_TC_PS_2_1)
✅ PowerSource battery event reporting with server as DUT on ContactSensor (Test_TC_PS_2_2)
✅ PowerSource battery reporting frequency on ContactSensor (TC_PS_2_3.py)
✅ BooleanState attributes on ContactSensor (Test_TC_BOOL_2_1)
✅ BooleanState primary functionality on ContactSensor (TC_BOOL_2_2.py)
✅ BooleanStateConfiguration attributes on ContactSensor (TC_BOOLCFG_2_1.py)
✅ BooleanStateConfiguration sensitivity level on ContactSensor (TC_BOOLCFG_3_1.py)
✅ BooleanStateConfiguration alarms supported on ContactSensor (TC_BOOLCFG_4_1.py)
✅ BooleanStateConfiguration alarms active on ContactSensor (TC_BOOLCFG_4_2.py)
✅ BooleanStateConfiguration alarms enabled inactive alarms on ContactSensor (TC_BOOLCFG_4_3.py)
✅ BooleanStateConfiguration alarms enabled active alarms on ContactSensor (TC_BOOLCFG_4_4.py)
✅ BooleanStateConfiguration suppress inactive alarms on ContactSensor (TC_BOOLCFG_5_1.py)
✅ BooleanStateConfiguration suppress active alarms on ContactSensor (TC_BOOLCFG_5_2.py)
✅ BooleanStateConfiguration sensor fault on ContactSensor (TC_BOOLCFG_6_1.py)
✅ Identify attributes on ContactSensor (Test_TC_I_2_1)
✅ Identify primary functionality on ContactSensor (Test_TC_I_2_2)
✅ Identify trigger effect on ContactSensor (Test_TC_I_2_3)
✅ Identify reporting on ContactSensor (TC_I_2_4.py)
✅ BridgedDeviceBasicInformation attributes on ContactSensor (TC_BRBINFO_2_1.py)
⏭️ BridgedDeviceBasicInformation events on ContactSensor (Test_TC_BRBINFO_2_2)
↳ Every step in this YAML is disabled:true (manual verification procedure, no automated assertions).
⏭️ BridgedDeviceBasicInformation ProductAppearance on ContactSensor (TC_BRBINFO_3_1.py)
↳ Gated by @run_if_endpoint_matches(has_attribute(ProductAppearance)); Matterbridge does not implement ProductAppearance on BridgedDeviceBasicInformation (BRBINFO.S.A0014=0 in matterbridge.pics), so it always skips.
✅ BridgedDeviceBasicInformation configuration version on ContactSensor (TC_BRBINFO_3_2.py)
⏭️ BridgedDeviceBasicInformation KeepActive on ContactSensor (TC_BRBINFO_4_1.py)
↳ Requires the Bridged ICD Support feature, KeepActive command, ActiveChanged event, and an external TH_ICD_SERVER/Fabric Sync app; Matterbridge does not implement BIS (BRBINFO.S.C80.Rsp=0 and BRBINFO.S.E80=0 in matterbridge.pics).
✅ IlluminanceMeasurement attributes on LightSensor (Test_TC_ILL_2_1)
✅ IlluminanceMeasurement primary functionality on LightSensor (Test_TC_ILL_2_2)
✅ OccupancySensing attributes on OccupancySensor (TC_OCC_2_1.py)
✅ OccupancySensing type interdependency on OccupancySensor (TC_OCC_2_2.py)
✅ OccupancySensing hold time compatibility on OccupancySensor (TC_OCC_2_3.py)
✅ OccupancySensing primary functionality on OccupancySensor (TC_OCC_3_1.py)
✅ OccupancySensing subscription reports on OccupancySensor (TC_OCC_3_2.py)
✅ TemperatureMeasurement attributes on TemperatureSensor (TC_TMP_2_1.py)
✅ TemperatureMeasurement primary functionality on TemperatureSensor (Test_TC_TMP_2_2)
✅ PressureMeasurement attributes on PressureSensor (Test_TC_PRS_2_1)
✅ PressureMeasurement primary functionality on PressureSensor (Test_TC_PRS_2_2)
✅ FlowMeasurement attributes on FlowSensor (Test_TC_FLW_2_1)
✅ FlowMeasurement primary functionality on FlowSensor (Test_TC_FLW_2_2)
✅ RelativeHumidityMeasurement attributes on HumiditySensor (Test_TC_RH_2_1)
✅ RelativeHumidityMeasurement primary functionality on HumiditySensor (Test_TC_RH_2_2)
⏭️ Binding node binding manual verification on OnOffSensor (Test_TC_BIND_2_1)
↳ Every step in this YAML is disabled:true. It is a DUT-Controller Binding client manual verification flow with external controlee nodes, not an automated server assertion on endpoint 708.
⏭️ Binding group binding manual verification on OnOffSensor (Test_TC_BIND_2_2)
↳ Every step in this YAML is disabled:true. It is a DUT-Controller Binding client and GroupKeyManagement manual verification flow with external controlee nodes, not an automated server assertion on endpoint 708.
⏭️ Binding group settings manual verification on OnOffSensor (Test_TC_BIND_2_3)
↳ Every step in this YAML is disabled:true. It is a DUT-Controller Binding client manual verification flow with external controlee nodes, not an automated server assertion on endpoint 708.
✅ SmokeCOAlarm attributes on SmokeCOAlarm (Test_TC_SMOKECO_2_1)
✅ SmokeCOAlarm smoke primary functionality on SmokeCOAlarm (Test_TC_SMOKECO_2_2)
✅ SmokeCOAlarm CO primary functionality on SmokeCOAlarm (Test_TC_SMOKECO_2_3)
✅ SmokeCOAlarm mandatory secondary functionality on SmokeCOAlarm (Test_TC_SMOKECO_2_4)
✅ SmokeCOAlarm optional secondary functionality on SmokeCOAlarm (Test_TC_SMOKECO_2_5)
✅ SmokeCOAlarm expressed state with multiple alarms on SmokeCOAlarm (Test_TC_SMOKECO_2_6)
✅ SmokeCOAlarm attributes on Smoke-only SmokeCOAlarm (Test_TC_SMOKECO_2_1)
✅ SmokeCOAlarm smoke primary functionality on Smoke-only SmokeCOAlarm (Test_TC_SMOKECO_2_2)
✅ SmokeCOAlarm mandatory secondary functionality on Smoke-only SmokeCOAlarm (Test_TC_SMOKECO_2_4)
✅ SmokeCOAlarm attributes on CO-only SmokeCOAlarm (Test_TC_SMOKECO_2_1)
✅ SmokeCOAlarm CO primary functionality on CO-only SmokeCOAlarm (Test_TC_SMOKECO_2_3)
✅ SmokeCOAlarm mandatory secondary functionality on CO-only SmokeCOAlarm (Test_TC_SMOKECO_2_4)
✅ AirQuality attributes on AirQualitySensor (Test_TC_AIRQUAL_2_1)
✅ TotalVolatileOrganicCompoundsConcentrationMeasurement attributes on AirQualitySensor (Test_TC_TVOCCONC_2_1)
✅ SoilMeasurement attributes on SoilSensor (TC_SOIL_2_1.py)
✅ SoilMeasurement primary functionality on SoilSensor (TC_SOIL_2_2.py)
✅ FanControl mandatory functionality on Fan Complete (TC_FAN_2_1.py)
✅ FanControl optional speed attributes on Fan Complete (Test_TC_FAN_2_2)
✅ FanControl optional rock attributes on Fan Complete (TC_FAN_2_3.py)
✅ FanControl optional wind attributes on Fan Complete (TC_FAN_2_4.py)
✅ FanControl optional direction attributes on Fan Complete (Test_TC_FAN_2_5)
❌ FanControl mandatory functionality with PercentSetting/FanMode ordering on Fan Complete (TC_FAN_3_1.py)
❌ FanControl optional speed functionality on Fan Complete (TC_FAN_3_2.py)
✅ FanControl optional rock functionality on Fan Complete (TC_FAN_3_3.py)
✅ FanControl optional wind functionality on Fan Complete (TC_FAN_3_4.py)
✅ FanControl Step command functionality on Fan Complete (TC_FAN_3_5.py)
✅ FanControl optional direction functionality on Fan Complete (Test_TC_FAN_3_6)
✅ FanControl interaction with On/Off cluster on Fan Complete (TC_FAN_4_1.py)
✅ HepaFilterMonitoring attributes on AirPurifier (Test_TC_HEPAFREMON_2_1)
✅ ActivatedCarbonFilterMonitoring attributes on AirPurifier (Test_TC_ACFREMON_2_1)
✅ OnOff attributes on OnOffLight (Test_TC_OO_2_1)
✅ OnOff primary functionality on OnOffLight (Test_TC_OO_2_2)
✅ OnOff secondary (Lighting) functionality on OnOffLight (Test_TC_OO_2_3)
⏭️ OnOff startup functionality on OnOffLight (Test_TC_OO_2_4)
↳ Requires 3 real DUT reboots (StartUpOnOff=0/1/2) with the OnOff value re-verified after each one actually restarts Matterbridge; this harness's single spawned test process with pre-piped stdin can't synchronize a real 'docker restart' with the test pausing at its UserPrompt step, so the assertion would be checked against a device that never actually rebooted.
✅ OnOff scenes management interaction on OnOffLight (TC_OO_2_7.py)
⏭️ OnOff OffOnly feature on OnOffLight (Test_TC_OO_2_6)
↳ Requires OO.S.F02 (OffOnly), mutually exclusive with the OO.S.F00 (Lighting) feature createDefaultOnOffClusterServer() actually enables on OnOffLight — permanently inapplicable given this device's feature set, not a PICS omission to fix.
⏭️ OnOff functionality with client as DUT on OnOffLight (Test_TC_OO_3_2_Simulated)
↳ Requires OO.C: the DUT itself must issue On/Off/Toggle/OffWithEffect/OnWithRecallGlobalScene/OnWithTimedOff commands to the TH. Matterbridge only ever exposes an OnOff cluster server for bridged devices, never acts as an OnOff client sending commands to a controller — permanently inapplicable.
✅ Groups attributes on OnOffLight (Test_TC_G_2_1)
✅ Groups AddGroup, ViewGroup, RemoveGroup, RemoveAllGroups commands on OnOffLight (TC_G_2_2.py)
⏭️ Groups GetGroupMembership, AddGroupIfIdentifying manual verification on OnOffLight (Test_TC_G_2_3)
↳ Every step in this YAML is disabled:true (manual verification procedure, no automated assertions).
❌ Groups AddGroup with same GroupID on multiple endpoints on OnOffLight and DimmableLight (Test_TC_G_2_4)
↳ Patched locally (docker/chip-test/patches/Test_TC_G_2_4.yaml, see chip-tests instructions §12) to fix its Step 6 GroupTable read (missing a '&& !G.S.F00' PICS guard, so it wrongly ran and failed alongside the F00-gated Step 7 duplicate whenever GroupNames is supported) and to pin PIXIT.G.ENDPOINT1/ENDPOINT2 to real Groups-server endpoints 401/402 in the YAML's own config defaults instead of via CLI overrides, since chiptool.py's generic PIXIT override path stores CLI values as raw strings with no int coercion and that broke the response's integer Endpoints array comparison.
⏭️ Groups cluster commands with client as DUT (Test_TC_G_3_2)
↳ Requires G.C: the DUT itself must issue AddGroup/ViewGroup/RemoveGroup/... commands to the TH as a Groups client, and every step in this YAML is disabled:true (manual verification flow). Matterbridge only ever exposes a Groups cluster server for bridged devices, never acts as a client — permanently inapplicable.
✅ LevelControl attributes on DimmableLight (Test_TC_LVL_2_1)
✅ LevelControl attributes are writable on DimmableLight (Test_TC_LVL_2_2)
⏭️ LevelControl RemainingTime functionality on DimmableLight (TC_LVL_2_3.py)
↳ Asserts exactly 3 RemainingTime subscription reports (one per MoveToLevel with a non-zero transitionTime) and that the reported values track the transition in progress. matter.js's LevelControlServer default implementation (@matter/node, not Matterbridge code) always sets CurrentLevel to the target immediately and ignores transitionTime unless the behavior opts into `managedTransitionTimeHandling` (see LevelControlServer.js State.managedTransitionTimeHandling, default false, doc: 'The default implementation always set the target level immediately and so ignores all transition times requested or configured') — createDefaultLevelControlClusterServer() doesn't enable it, so RemainingTime never changes and 0 reports are received. Verified directly against the container: CurrentLevel jumps to the target level immediately regardless of transitionTime.
⏭️ LevelControl MoveToLevel verification on DimmableLight (Test_TC_LVL_3_1)
↳ Deterministically fails at Step 5h (3/3 reproductions): after OnOff.Off then MoveToLevel with Options.ExecuteIfOff=0, CurrentLevel should stay unchanged (120 sent, expects level to remain at the prior 100) but reads back as 120 instead. LevelControlServer's own #optionsAllowExecution() check (@matter/node, not Matterbridge code) reads the live OnOffServer OnOff attribute and correctly blocks execution — verified manually replaying the exact same command sequence one chip-tool process at a time (fresh CASE session per command), where the block works every time. Only reproduces inside chiptool.py's single long-lived interactive-server session sending the Off and MoveToLevel commands back-to-back, suggesting a race between the Off command's state commit and the following MoveToLevel's OnOff read under low-latency/pipelined command delivery — needs deeper investigation in @matter/node before enabling.
✅ LevelControl Move verification on DimmableLight (Test_TC_LVL_4_1)
✅ LevelControl Step verification on DimmableLight (Test_TC_LVL_5_1)
⏭️ LevelControl Stop verification on DimmableLight (Test_TC_LVL_6_1)
↳ Starts a Move (5 units/s), waits 5s, sends Stop, then expects CurrentLevel to be captured mid-transition (constrained between 64 and 86). Same root cause as TC_LVL_2_3: matter.js's default LevelControlServer (@matter/node) jumps CurrentLevel to the target immediately rather than simulating the transition, so by the time Stop is sent the level has already reached the Move's implicit target (254) — Stop then has nothing in progress to halt. Not fixable via PICS; permanently inapplicable unless Matterbridge opts into managedTransitionTimeHandling.
✅ LevelControl MoveToClosestFrequency verification on DimmableLight (Test_TC_LVL_7_1)
⏭️ LevelControl commands with client as DUT (Test_TC_LVL_8_1)
↳ Every step in this YAML is disabled:true (manual verification procedure, no automated assertions). It is also gated on LVL.C: the DUT itself must issue LevelControl commands to the TH as a client — Matterbridge only ever exposes a LevelControl cluster server, never acts as a client — permanently inapplicable.
✅ LevelControl OnOff interaction on DimmableLight (TC_LVL_9_1.py)
Summary: 125/128 tests passed (35 skipped).