AddRequestData

[swang4415]

Reproduction steps

I am using the Matter protocol to send the OnOff Cluster command. After building the command path, I try to call the AddRequestData function to add the command data (onCommand), but the command fails to send. Here is the error log:

I (11057) MatterController: 按钮按下，时间: 11057194 微秒
I (11247) MatterController: 按钮松开，时间: 189996 微秒
I (11247) MatterController: 切换灯具状态，当前状态: OFF
I (11257) app_driver: 按钮被按下，切换灯具状态
I (11257) app_driver: 当前的 Node ID: 0x5164
I (11267) app_driver: 开始查找或建立会话.........
I (11267) chip[DIS]: Lookup started for 1A2869E20AC7B3F0-0000000000005164
I (11277) app_driver: 查找或建立会话的请求已发送, 回调地址: 0x3fc98f78
I (11277) MatterController: 灯具状态切换完成!!!!!!!!!!
I (11467) chip[DIS]: Checking node lookup status for 1A2869E20AC7B3F0-0000000000005164 after 200 ms
I (12037) chip[DIS]: UDP:[FE80::1291:A8FF:FE1F:9D88%st1]:5540: new best score: 7 (for 1A2869E20AC7B3F0-0000000000005164)
I (12037) chip[DIS]: UDP:192.168.1.123%st1:5540: score has not improved: 2 (for 1A2869E20AC7B3F0-0000000000005164)
I (12047) chip[DIS]: Checking node lookup status for 1A2869E20AC7B3F0-0000000000005164 after 786 ms
I (12067) chip[SC]: Initiating session on local FabricIndex 1 from 0x0000000000007283 -> 0x0000000000005164
I (12127) chip[EM]: <<< [E:55130i S:0 M:65955700] (U) Msg TX to 0:0000000000000000 [0000] [UDP:[FE80::1291:A8FF:FE1F:9D88%st1]:5540] --- Type 0000:30 (SecureChannel:CASE_Sigma1) (B:234)
I (12147) chip[SC]: Sent Sigma1 msg to <0000000000005164, 1>
I (12707) chip[EM]: Retransmitting MessageCounter:65955700 on exchange 55130i Send Cnt 1
I (12717) chip[EM]: >>> [E:55130i S:0 M:211836383 (Ack:65955700)] (U) Msg RX from 0:0000000000000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck) (B:26)
I (12737) chip[EM]: >>> [E:55130i S:0 M:211836384 (Ack:65955700)] (U) Msg RX from 0:0000000000000000 [0000] --- Type 0000:33 (SecureChannel:CASE_Sigma2Resume) (B:100)
I (12747) chip[EM]: <<< [E:55130i S:0 M:65955701 (Ack:211836384)] (U) Msg TX to 0:0000000000000000 [0000] [UDP:[FE80::1291:A8FF:FE1F:9D88%st1]:5540] --- Type 0000:10 (SecureChannel:StandaloneAck) (B:26)
I (12787) chip[EM]: <<< [E:55130i S:0 M:65955702 (Ack:211836384)] (U) Msg TX to 0:0000000000000000 [0000] [UDP:[FE80::1291:A8FF:FE1F:9D88%st1]:5540] --- Type 0000:40 (SecureChannel:StatusReport) (B:34)
I (12807) chip[SC]: SecureSession[0x3fc9b7c8, LSID:33467]: State change 'kEstablishing' --> 'kActive'
I (12817) app_driver: 成功与设备建立会话: Node ID 0x5164
I (12817) app_driver: 准备发送命令: 打开 到 endpoint 2
I (12827) app_driver: 命令路径信息: endpointId: 2, ClusterId: 6, CommandId: 1
I (12837) app_driver: PrepareCommand 成功
I (12837) app_driver: 发送打开命令: endpointId: 2, ClusterId: 6, CommandId: 1
E (12847) app_driver: AddRequestData 失败: Error CHIP:0x00000003
E (12847) app_driver: 发送控制命令失败: Error CHIP:0x00000003
I (12857) chip[EM]: >>> [E:55130i S:0 M:211836385 (Ack:65955700)] (U) Msg RX from 0:0000000000000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck) (B:26)
I (12947) chip[EM]: >>> [E:55130i S:0 M:211836386 (Ack:65955702)] (U) Msg RX from 0:0000000000000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck) (B:26)

1. Create CommandSender and callback objects.
2. Call PrepareCommand to prepare the command path.
3. Call AddRequestData to add command data for On/Off Cluster.
4. Failed to send command.

Is there something I'm missing when using AddRequestData? Is there something else I'm not considering that may be causing the command to fail? Thanks for your help!

Bug prevalence

Once or twice a week

GitHub hash of the SDK that was being used

5.0.2

Platform

esp32

Platform Version(s)

No response

Type

Core SDK Crash

Anything else?

[wqx6]

AddRequestData() will call the PrepareCommand() to encode the command path to the command payload, so you don't need to call it before AddRequestData().

[swang4415]

AddRequestData() will call the PrepareCommand() to encode the command path to the command payload, so you don't need to call it before AddRequestData().AddRequestData()将调用PrepareCommand()将命令路径编码到命令负载，因此您无需在AddRequestData()之前调用它。

Yes, in my original code, I did call the PrepareCommand() function before using AddRequestData(), but after listening to your advice, I removed the PrepareCommand() function. Now it still has the same problem, and it cannot be sent successfully. The error code is still Error CHIP: 0x00000003. I don't know what to do about this. I hope to get your advice. Thank you.

[swang4415]

AddRequestData() will call the PrepareCommand() to encode the command path to the command payload, so you don't need to call it before AddRequestData().

Sorry, now my AddRequestData() function has no problem, but when I finished loading the control command, my FinishCommand() function had a problem again. The specific error code is as follows: E (16768) app_driver: FinishCommand failed: Error CHIP:0x00000003
E (16778) app_driver: Send control command failed: Error CHIP:0x00000003
Sorry to bother you. I really hope you can take the time to guide me in your busy schedule. Thank you very much!!!

[tehampson]

No need to call Finish either. AddRequestData calls both prepare and finish for you.

Prepare and Finish are offered for more complex reason, but is strongly discouraged to use as most use cases should be able to use AddRequestData directly

[swang4415]

Prepare and Finish are offered for more complex reason, but is strongly discouraged to use as most use cases should be able to use AddRequestData directly
Hello, after I removed the FinishCommand() function as you suggested, the program ran normally, but when I sent a command to the device, the following log record appeared on the device:

Is this because my control end does not have sufficient permissions to access the device? But what I don't understand is: if I use chip-tool to bind my controller to the device, I can achieve this operation, but now I want to control the devices of different nodes separately, how can I do it? I hope you can give some suggestions, thank you very much! !

[tehampson]

If you can add logs onto the device side you can look into why you don't have permissions. That is an ACL thing I don't know too much about that so I cannot help you sorry