|
| 1 | +# Copyright (c) 2023 Project CHIP Authors |
| 2 | +# |
| 3 | +# Licensed under the Apache License, Version 2.0 (the "License"); |
| 4 | +# you may not use this file except in compliance with the License. |
| 5 | +# You may obtain a copy of the License at |
| 6 | +# |
| 7 | +# http://www.apache.org/licenses/LICENSE-2.0 |
| 8 | +# |
| 9 | +# Unless required by applicable law or agreed to in writing, software |
| 10 | +# distributed under the License is distributed on an "AS IS" BASIS, |
| 11 | +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| 12 | +# See the License for the specific language governing permissions and |
| 13 | +# limitations under the License. |
| 14 | +# Auto-generated scripts for harness use only, please review before automation. The endpoints and cluster names are currently set to default |
| 15 | + |
| 16 | +name: |
| 17 | + 3.1.3. [TC-IDM-1.3] Batched Commands Invoke Request Action from DUT to TH - |
| 18 | + [{DUT_Client}] |
| 19 | + |
| 20 | +PICS: |
| 21 | + - MCORE.IDM.C.InvokeRequest.BatchCommands |
| 22 | + |
| 23 | +config: |
| 24 | + nodeId: 0x12344321 |
| 25 | + cluster: "Basic Information" |
| 26 | + endpoint: 0 |
| 27 | + |
| 28 | +tests: |
| 29 | + - label: "Note" |
| 30 | + verification: | |
| 31 | + Chip-repl commands used below are an example to verify the DUT as client test cases. For certification test, we expect DUT should have a capability or way to run the equivalent command. |
| 32 | + disabled: true |
| 33 | + |
| 34 | + - label: "Step 1: DUT sends the Invoke Request Message to the TH. The |
| 35 | + Message should contain two valid and unique paths in the |
| 36 | + CommandDataIBs, which has the specific Endpoints, specific Clusters |
| 37 | + and specific Commands. |
| 38 | +
|
| 39 | + TH should be configured such that it responds to the batched commands |
| 40 | + in a single InvokeResponseMessage, the ordering of CommandDataIBs in |
| 41 | + the InvokeResponseMessage SHALL be in the same order as provided in |
| 42 | + the request." |
| 43 | + |
| 44 | + verification: | |
| 45 | + Product maker needs to provide instructions for how to trigger the command on the DUT that is capable of fitting into a single InvokeResponseMessage. For comparison, the DUT behavior for this |
| 46 | + test step can be simulated using chip-repl (when DUT is a commissioner/Client). |
| 47 | + The cluster used in the below command is an example, User can use any supported chip cluster/attribute/command. Note in this example the unique path is created by using 2 different endpoints. |
| 48 | +
|
| 49 | + `await devCtrl.SendBatchCommands(0x12344321, [Clusters.Command.InvokeRequestInfo(1, Clusters.OnOff.Commands.Toggle()), Clusters.Command.InvokeRequestInfo(2, Clusters.OnOff.Commands.Toggle())]` |
| 50 | +
|
| 51 | + On TH(all-clusters-app), Verify that the EndpointIDs, CommandIDs, ClusterIDs in the InvokeRequestMessage (as below) matching with the data sent in the above command |
| 52 | +
|
| 53 | + CHIP:DMG: InvokeRequestMessage = |
| 54 | + CHIP:DMG: { |
| 55 | + CHIP:DMG: suppressResponse = false, |
| 56 | + CHIP:DMG: timedRequest = true, |
| 57 | + CHIP:DMG: InvokeRequests = |
| 58 | + CHIP:DMG: [ |
| 59 | + CHIP:DMG: CommandDataIB = |
| 60 | + CHIP:DMG: { |
| 61 | + CHIP:DMG: CommandPathIB = <--------- Verifying everything in this struct matches what is provided by product maker |
| 62 | + CHIP:DMG: { |
| 63 | + CHIP:DMG: EndpointId = 0x1, |
| 64 | + CHIP:DMG: ClusterId = 0x6, |
| 65 | + CHIP:DMG: CommandId = 0x2, |
| 66 | + CHIP:DMG: }, |
| 67 | + CHIP:DMG: |
| 68 | + CHIP:DMG: CommandFields = |
| 69 | + CHIP:DMG: { |
| 70 | + CHIP:DMG: }, |
| 71 | + CHIP:DMG: Ref = 0x0, |
| 72 | + CHIP:DMG: }, |
| 73 | + CHIP:DMG: |
| 74 | + CHIP:DMG: CommandDataIB = |
| 75 | + CHIP:DMG: { |
| 76 | + CHIP:DMG: CommandPathIB = <--------- Verifying everything in this struct matches what is provided by product maker |
| 77 | + CHIP:DMG: { |
| 78 | + CHIP:DMG: EndpointId = 0x2, |
| 79 | + CHIP:DMG: ClusterId = 0x6, |
| 80 | + CHIP:DMG: CommandId = 0x2, |
| 81 | + CHIP:DMG: }, |
| 82 | + CHIP:DMG: |
| 83 | + CHIP:DMG: CommandFields = |
| 84 | + CHIP:DMG: { |
| 85 | + CHIP:DMG: }, |
| 86 | + CHIP:DMG: Ref = 0x1, |
| 87 | + CHIP:DMG: }, |
| 88 | + CHIP:DMG: |
| 89 | + CHIP:DMG: ], |
| 90 | + CHIP:DMG: |
| 91 | + CHIP:DMG: InteractionModelRevision = 11 |
| 92 | + CHIP:DMG: }, |
| 93 | + CHIP:DMG: AccessControl: checking f=1 a=c s=0x000000000001B669 t= c=0x0000_0006 e=1 p=o |
| 94 | + CHIP:DMG: AccessControl: allowed |
| 95 | + disabled: true |
| 96 | + |
| 97 | + - label: "Step 2: DUT sends the Invoke Request Message to the TH. The |
| 98 | + Message should contain two valid and unique paths in the |
| 99 | + CommandDataIBs, which has the specific Endpoints, specific Clusters |
| 100 | + and specific Commands. |
| 101 | +
|
| 102 | + TH should be configured such that it responds to the batched commands |
| 103 | + over two InvokeResponseMessages. The first InvokeResponseMessage SHALL |
| 104 | + contain a response to the first CommandDataIB in the |
| 105 | + InvokeRequestMessage. The second InvokeReponseMessage SHALL contains a |
| 106 | + response to the second CommandDataIB in the InvokeRequestMessage." |
| 107 | + |
| 108 | + verification: | |
| 109 | + Product maker needs to provide instructions for how to trigger the command this on the DUT that is capable of fitting into a single InvokeResponseMessage. For comparison, the DUT behavior for this |
| 110 | + test step can be simulated using chip-repl (when DUT is a commissioner/Client). |
| 111 | + The cluster used in the below command is an example, User can use any supported chip cluster/attribute/command. Note in this example the unique path is created by using 2 different endpoints. |
| 112 | +
|
| 113 | + `await devCtrl.SendBatchCommands(0x12344321, [Clusters.Command.InvokeRequestInfo(1, Clusters.OnOff.Commands.Toggle()), Clusters.Command.InvokeRequestInfo(2, Clusters.OnOff.Commands.Toggle())]` |
| 114 | +
|
| 115 | + Verify DUT doesn't crash by seeing next step execute. |
| 116 | + disabled: true |
| 117 | + |
| 118 | + - label: "Step 3: DUT sends the Invoke Request Message to the TH. The |
| 119 | + Message should contain two valid and unique paths in the |
| 120 | + CommandDataIBs, which has the specific Endpoints, specific Clusters |
| 121 | + and specific Commands. |
| 122 | +
|
| 123 | + TH should be configured such that it responds to the batched commands |
| 124 | + over two InvokeResponseMessages. The first InvokeResponseMessage SHALL |
| 125 | + contain a response to the second CommandDataIB in the |
| 126 | + InvokeRequestMessage. The second InvokeReponseMessage SHALL contains a |
| 127 | + response to the first CommandDataIB in the InvokeRequestMessage." |
| 128 | + |
| 129 | + verification: | |
| 130 | + Product maker needs to provide instructions for how to trigger the command this on the DUT that is capable of fitting into a single InvokeResponseMessage. For comparison, the DUT behavior for this |
| 131 | + test step can be simulated using chip-repl (when DUT is a commissioner/Client). |
| 132 | + The cluster used in the below command is an example, User can use any supported chip cluster/attribute/command. Note in this example the unique path is created by using 2 different endpoints. |
| 133 | +
|
| 134 | + `await devCtrl.SendBatchCommands(0x12344321, [Clusters.Command.InvokeRequestInfo(1, Clusters.OnOff.Commands.Toggle()), Clusters.Command.InvokeRequestInfo(2, Clusters.OnOff.Commands.Toggle())]` |
| 135 | +
|
| 136 | + Verify DUT doesn't crash by seeing next step execute. |
| 137 | + disabled: true |
| 138 | + |
| 139 | + - label: "Step 4: DUT sends the Invoke Request Message to the TH. The |
| 140 | + Message should contain two valid and unique paths in the |
| 141 | + CommandDataIBs, which has the specific Endpoints, specific Clusters |
| 142 | + and specific Commands. |
| 143 | +
|
| 144 | + TH should be configured such that it responds incorrectly to the |
| 145 | + batched commands in a single InvokeResponseMessages. The |
| 146 | + InvokeResponseMessage SHALL contain a response to the first |
| 147 | + CommandDataIB in the InvokeRequestMessage. The second response to |
| 148 | + second CommandDataIB will intentionally be left out." |
| 149 | + |
| 150 | + verification: | |
| 151 | + Product maker needs to provide instructions for how to trigger the command this on the DUT that is capable of fitting into a single InvokeResponseMessage. For comparison, the DUT behavior for this |
| 152 | + test step can be simulated using chip-repl (when DUT is a commissioner/Client). |
| 153 | + The cluster used in the below command is an example, User can use any supported chip cluster/attribute/command. Note in this example the unique path is created by using 2 different endpoints. |
| 154 | +
|
| 155 | + `await devCtrl.SendBatchCommands(0x12344321, [Clusters.Command.InvokeRequestInfo(1, Clusters.OnOff.Commands.Toggle()), Clusters.Command.InvokeRequestInfo(2, Clusters.OnOff.Commands.Toggle())]` |
| 156 | +
|
| 157 | + Verify DUT doesn't crash by seeing next step execute. |
| 158 | + disabled: true |
| 159 | + |
| 160 | + - label: "Step 5: DUT sends the Invoke Request Message to the TH. The |
| 161 | + Message should contain one valid CommandDataIB, which has the specific |
| 162 | + Endpoint, Specific Cluster and Specific Command. |
| 163 | +
|
| 164 | + TH should be configured such that it responds regularly to single |
| 165 | + invoke request." |
| 166 | + |
| 167 | + verification: | |
| 168 | + Product maker needs to provide instructions for how to trigger the command this on the DUT that is capable of fitting into a single InvokeResponseMessage. For comparison, the DUT behavior for this |
| 169 | + test step can be simulated using chip-repl (when DUT is a commissioner/Client). |
| 170 | + The cluster used in the below command is an example, User can use any supported chip cluster/attribute/command. Note in this example the unique path is created by using 2 different endpoints. |
| 171 | +
|
| 172 | + `await devCtrl.SendCommands(0x12344321, 1, Clusters.OnOff.Commands.Toggle())` |
| 173 | +
|
| 174 | + On TH(all-clusters-app), Verify that we recieves an InvokeRequestMessage that contains a single InvokeRequests |
| 175 | +
|
| 176 | + CHIP:DMG: InvokeRequestMessage = |
| 177 | + CHIP:DMG: { |
| 178 | + CHIP:DMG: suppressResponse = false, |
| 179 | + CHIP:DMG: timedRequest = true, |
| 180 | + CHIP:DMG: InvokeRequests = <--------- Verify only one CommandDataIB in this structure |
| 181 | + CHIP:DMG: [ |
| 182 | + CHIP:DMG: CommandDataIB = |
| 183 | + CHIP:DMG: { |
| 184 | + CHIP:DMG: CommandPathIB = |
| 185 | + CHIP:DMG: { |
| 186 | + CHIP:DMG: EndpointId = 0x1, |
| 187 | + CHIP:DMG: ClusterId = 0x6, |
| 188 | + CHIP:DMG: CommandId = 0x2, |
| 189 | + CHIP:DMG: }, |
| 190 | + CHIP:DMG: |
| 191 | + CHIP:DMG: CommandFields = |
| 192 | + CHIP:DMG: { |
| 193 | + CHIP:DMG: }, |
| 194 | + CHIP:DMG: Ref = 0x0, |
| 195 | + CHIP:DMG: }, |
| 196 | + CHIP:DMG: |
| 197 | + CHIP:DMG: ], |
| 198 | + CHIP:DMG: |
| 199 | + CHIP:DMG: InteractionModelRevision = 11 |
| 200 | + CHIP:DMG: }, |
| 201 | + CHIP:DMG: AccessControl: checking f=1 a=c s=0x000000000001B669 t= c=0x0000_0006 e=1 p=o |
| 202 | + CHIP:DMG: AccessControl: allowed |
| 203 | + disabled: true |
0 commit comments