Skip to content

Commit

Permalink
Implement updates to IDM test spec for batch commands (#31042)
Browse files Browse the repository at this point in the history 
* Implement updates to IDM test spec for batch commands

* Restyled by whitespace

Restyled by prettier-yaml

Restyled by autopep8

* Add another test

* Addres PR comments

* Restyled by autopep8

* Restyled by isort

* Address PR comments

* Restyled by clang-format

---------

Co-authored-by: Restyled.io <commits@restyled.io>
  • Loading branch information
@tehampson @restyled-commits @pull
2 people authored and pull[bot] committed Jan 20, 2024
1 parent 28c791d commit 4053630
Show file tree
Hide file tree
Showing 4 changed files with 398 additions and 10 deletions.
9 changes: 0 additions & 9 deletions src/app/tests/suites/certification/Test_TC_IDM_1_1.yaml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -79,15 +79,6 @@ tests:

- label:
"Step 3: DUT sends the Invoke Request Message to the TH. The Message
should contain multiple paths Path = [[ Endpoint = Endpoint1, Cluster
= ClusterID, Command = Command1 ], [ Endpoint = Endpoint1, Cluster =
ClusterID, Command = Command2 ] ]"
verification: |
Out of Scope
disabled: true

- label:
"Step 4: DUT sends the Invoke Request Message to the TH. The Message
should contain one valid CommandDataIB, which has the specific
Endpoint, Specific Cluster and Specific Command. Send 2 more Invoke
Request Messages to the TH."
Expand Down
203 changes: 203 additions & 0 deletions src/app/tests/suites/certification/Test_TC_IDM_1_3.yaml
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,203 @@
# Copyright (c) 2023 Project CHIP Authors
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
# Auto-generated scripts for harness use only, please review before automation. The endpoints and cluster names are currently set to default

name:
3.1.3. [TC-IDM-1.3] Batched Commands Invoke Request Action from DUT to TH -
[{DUT_Client}]

PICS:
- MCORE.IDM.C.InvokeRequest.BatchCommands

config:
nodeId: 0x12344321
cluster: "Basic Information"
endpoint: 0

tests:
- label: "Note"
verification: |
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.
disabled: true

- label: "Step 1: DUT sends the Invoke Request Message to the TH. The
Message should contain two valid and unique paths in the
CommandDataIBs, which has the specific Endpoints, specific Clusters
and specific Commands.
TH should be configured such that it responds to the batched commands
in a single InvokeResponseMessage, the ordering of CommandDataIBs in
the InvokeResponseMessage SHALL be in the same order as provided in
the request."

verification: |
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
test step can be simulated using chip-repl (when DUT is a commissioner/Client).
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.
`await devCtrl.SendBatchCommands(0x12344321, [Clusters.Command.InvokeRequestInfo(1, Clusters.OnOff.Commands.Toggle()), Clusters.Command.InvokeRequestInfo(2, Clusters.OnOff.Commands.Toggle())]`
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
CHIP:DMG: InvokeRequestMessage =
CHIP:DMG: {
CHIP:DMG: suppressResponse = false,
CHIP:DMG: timedRequest = true,
CHIP:DMG: InvokeRequests =
CHIP:DMG: [
CHIP:DMG: CommandDataIB =
CHIP:DMG: {
CHIP:DMG: CommandPathIB = <--------- Verifying everything in this struct matches what is provided by product maker
CHIP:DMG: {
CHIP:DMG: EndpointId = 0x1,
CHIP:DMG: ClusterId = 0x6,
CHIP:DMG: CommandId = 0x2,
CHIP:DMG: },
CHIP:DMG:
CHIP:DMG: CommandFields =
CHIP:DMG: {
CHIP:DMG: },
CHIP:DMG: Ref = 0x0,
CHIP:DMG: },
CHIP:DMG:
CHIP:DMG: CommandDataIB =
CHIP:DMG: {
CHIP:DMG: CommandPathIB = <--------- Verifying everything in this struct matches what is provided by product maker
CHIP:DMG: {
CHIP:DMG: EndpointId = 0x2,
CHIP:DMG: ClusterId = 0x6,
CHIP:DMG: CommandId = 0x2,
CHIP:DMG: },
CHIP:DMG:
CHIP:DMG: CommandFields =
CHIP:DMG: {
CHIP:DMG: },
CHIP:DMG: Ref = 0x1,
CHIP:DMG: },
CHIP:DMG:
CHIP:DMG: ],
CHIP:DMG:
CHIP:DMG: InteractionModelRevision = 11
CHIP:DMG: },
CHIP:DMG: AccessControl: checking f=1 a=c s=0x000000000001B669 t= c=0x0000_0006 e=1 p=o
CHIP:DMG: AccessControl: allowed
disabled: true

- label: "Step 2: DUT sends the Invoke Request Message to the TH. The
Message should contain two valid and unique paths in the
CommandDataIBs, which has the specific Endpoints, specific Clusters
and specific Commands.
TH should be configured such that it responds to the batched commands
over two InvokeResponseMessages. The first InvokeResponseMessage SHALL
contain a response to the first CommandDataIB in the
InvokeRequestMessage. The second InvokeReponseMessage SHALL contains a
response to the second CommandDataIB in the InvokeRequestMessage."

verification: |
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
test step can be simulated using chip-repl (when DUT is a commissioner/Client).
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.
`await devCtrl.SendBatchCommands(0x12344321, [Clusters.Command.InvokeRequestInfo(1, Clusters.OnOff.Commands.Toggle()), Clusters.Command.InvokeRequestInfo(2, Clusters.OnOff.Commands.Toggle())]`
Verify DUT doesn't crash by seeing next step execute.
disabled: true

- label: "Step 3: DUT sends the Invoke Request Message to the TH. The
Message should contain two valid and unique paths in the
CommandDataIBs, which has the specific Endpoints, specific Clusters
and specific Commands.
TH should be configured such that it responds to the batched commands
over two InvokeResponseMessages. The first InvokeResponseMessage SHALL
contain a response to the second CommandDataIB in the
InvokeRequestMessage. The second InvokeReponseMessage SHALL contains a
response to the first CommandDataIB in the InvokeRequestMessage."

verification: |
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
test step can be simulated using chip-repl (when DUT is a commissioner/Client).
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.
`await devCtrl.SendBatchCommands(0x12344321, [Clusters.Command.InvokeRequestInfo(1, Clusters.OnOff.Commands.Toggle()), Clusters.Command.InvokeRequestInfo(2, Clusters.OnOff.Commands.Toggle())]`
Verify DUT doesn't crash by seeing next step execute.
disabled: true

- label: "Step 4: DUT sends the Invoke Request Message to the TH. The
Message should contain two valid and unique paths in the
CommandDataIBs, which has the specific Endpoints, specific Clusters
and specific Commands.
TH should be configured such that it responds incorrectly to the
batched commands in a single InvokeResponseMessages. The
InvokeResponseMessage SHALL contain a response to the first
CommandDataIB in the InvokeRequestMessage. The second response to
second CommandDataIB will intentionally be left out."

verification: |
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
test step can be simulated using chip-repl (when DUT is a commissioner/Client).
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.
`await devCtrl.SendBatchCommands(0x12344321, [Clusters.Command.InvokeRequestInfo(1, Clusters.OnOff.Commands.Toggle()), Clusters.Command.InvokeRequestInfo(2, Clusters.OnOff.Commands.Toggle())]`
Verify DUT doesn't crash by seeing next step execute.
disabled: true

- label: "Step 5: DUT sends the Invoke Request Message to the TH. The
Message should contain one valid CommandDataIB, which has the specific
Endpoint, Specific Cluster and Specific Command.
TH should be configured such that it responds regularly to single
invoke request."

verification: |
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
test step can be simulated using chip-repl (when DUT is a commissioner/Client).
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.
`await devCtrl.SendCommands(0x12344321, 1, Clusters.OnOff.Commands.Toggle())`
On TH(all-clusters-app), Verify that we recieves an InvokeRequestMessage that contains a single InvokeRequests
CHIP:DMG: InvokeRequestMessage =
CHIP:DMG: {
CHIP:DMG: suppressResponse = false,
CHIP:DMG: timedRequest = true,
CHIP:DMG: InvokeRequests = <--------- Verify only one CommandDataIB in this structure
CHIP:DMG: [
CHIP:DMG: CommandDataIB =
CHIP:DMG: {
CHIP:DMG: CommandPathIB =
CHIP:DMG: {
CHIP:DMG: EndpointId = 0x1,
CHIP:DMG: ClusterId = 0x6,
CHIP:DMG: CommandId = 0x2,
CHIP:DMG: },
CHIP:DMG:
CHIP:DMG: CommandFields =
CHIP:DMG: {
CHIP:DMG: },
CHIP:DMG: Ref = 0x0,
CHIP:DMG: },
CHIP:DMG:
CHIP:DMG: ],
CHIP:DMG:
CHIP:DMG: InteractionModelRevision = 11
CHIP:DMG: },
CHIP:DMG: AccessControl: checking f=1 a=c s=0x000000000001B669 t= c=0x0000_0006 e=1 p=o
CHIP:DMG: AccessControl: allowed
disabled: true
10 changes: 9 additions & 1 deletion src/controller/python/chip/clusters/command.cpp
View file
Original file line number Diff line number Diff line change
Expand Up @@ -248,7 +248,15 @@ PyChipError pychip_CommandSender_SendBatchCommands(void * appContext, DeviceProx
VerifyOrReturnError(device->GetSecureSession().HasValue(), ToPyChipError(CHIP_ERROR_MISSING_SECURE_SESSION));
auto remoteSessionParameters = device->GetSecureSession().Value()->GetRemoteSessionParameters();
CommandSender::ConfigParameters config;
config.SetRemoteMaxPathsPerInvoke(remoteSessionParameters.GetMaxPathsPerInvoke());

// TODO(#30986): Need to create a separate pychip_CommandSender_TestOnlySendBatchCommands so that we perform
// operations that is very clear at callsite that violating certain aspects like setting this MaxPathsPerInvoke
// to a number other than what is reported by the remote node is allowed. Right now the only user of this
// function is cert test script. To implement pychip_CommandSender_TestOnlySendBatchCommands in a clean way
// we need to move away from the variadic arguments.
// config.SetRemoteMaxPathsPerInvoke(remoteSessionParameters.GetMaxPathsPerInvoke());
(void) remoteSessionParameters; // Still want to get remoteSessionParameters, just wont use it right now.
config.SetRemoteMaxPathsPerInvoke(std::numeric_limits<uint16_t>::max());

std::unique_ptr<CommandSenderCallback> callback =
std::make_unique<CommandSenderCallback>(appContext, /* isBatchedCommands =*/true);
Expand Down
Loading

0 comments on commit 4053630

Please sign in to comment.