-
-
Notifications
You must be signed in to change notification settings - Fork 436
Description
Describe the problem
Hello, I am using the CLI daemon with JS, and after updating the baudrate of the monitor, the client does not receive the corresponding response:
arduino-cli/rpc/cc/arduino/cli/commands/v1/monitor.proto
Lines 60 to 63 in c41f5df
I had expected to see this response after changing the baudrate, but it never occurred. Is it a bug?
To reproduce
Inside the arduino-cli repo, generate the .proto files with buf:
buf export . -o ./tmp/out
Start the Arduino CLI in daemon mode:
./arduino-cli daemon
Daemon is now listening on 127.0.0.1:50051
{"IP":"127.0.0.1","Port":"50051"}Open another shell and change the directory to the local Git clone of the Arduino CLI repository.
Create an instance:
grpcurl \
-plaintext \
-import-path ./tmp/out \
-proto cc/arduino/cli/commands/v1/commands.proto \
127.0.0.1:50051 \
cc.arduino.cli.commands.v1.ArduinoCoreService.Create
{
"instance": {
"id": 1
}
}
Initialize the instance:
grpcurl \
-plaintext \
-import-path ./tmp/out \
-proto cc/arduino/cli/commands/v1/commands.proto \
-d '{"instance": {"id": 1}}' \
127.0.0.1:50051 \
cc.arduino.cli.commands.v1.ArduinoCoreService.InitStart the monitor:
grpcurl \ -plaintext \ -import-path ./tmp/out \ -proto cc/arduino/cli/commands/v1/commands.proto \ -d @ \ 127.0.0.1:50051 \ cc.arduino.cli.commands.v1.ArduinoCoreService.Monitor
Paste the open port request and press Enter:
{
"openRequest": {
"instance": { "id": 1 },
"fqbn": "esp32:esp32:esp32da",
"port": {
"address": "/dev/cu.usbserial-0001",
"protocol": "serial"
},
"portConfiguration": {
"settings": [
{ "settingId": "baudrate", "value": "115200" }
]
}
}
}The monitor pushes the responses to the terminal:
{
"success": true
}
{
"rxData": "AGV0cyBKdWwgMjkgMjAxOSAxMjoyMTo0Ng0KDSqSLKQSHMGohDgmIAMIoeAf+Q=="
}
{
"rxData": "AAA="
}
{
"rxData": "AAA="
}
{
"rxData": "AAAAAA=="
}
{
"rxData": "AAAA"
}
{
"rxData": "AAAA"
}
// filtered chunks...
{
"rxData": "AAAA"
}
{
"rxData": "AAA="
}
{
"rxData": "AAAA"
}
{
"rxData": "AAAA"
}
{
"rxData": "AAAA"
}Paste the baudrate change request to the terminal and press Enter:
{
"updatedConfiguration": {
"settings": [
{
"settingId": "baudrate",
"value": "9600"
}
]
}
}{
"rxData": "AAA="
}
{
"rxData": "AAAA"
}
{
"rxData": "AAAAAA=="
}
{
"rxData": "AAAA"
}
{
"rxData": "AAAA"
}
{
"rxData": "AAAA"
}
{
"rxData": "AAAAAA=="
}
{
"rxData": "AAA="
}
{
"rxData": "AAAA"
}
{
"rxData": "AAAA"
}
{
"rxData": "AAAA"
}
{
"rxData": "AAAA"
}
{
"rxData": "AAAAAA=="
}
{
"rxData": "AAA="
}
{
"rxData": "AAAA"
}
{
"rxData": "AAA="
}
{
"rxData": "AAAA"
}
{
"rxData": "AAAA"
}
{
"rxData": "AAAA"
}
{
"rxData": "Gw=="
}
{
"rxData": "Ww=="
}
{
"rxData": "Mw=="
}
{
"rxData": "MQ=="
}
{
"rxData": "bQ=="
}
{
"rxData": "SA=="
}
{
"rxData": "YQ=="
}
{
"rxData": "bA=="
}
{
"rxData": "bA=="
}
{
"rxData": "bw=="
}
{
"rxData": "Gw=="
}
{
"rxData": "Ww=="
}
// filtered chunks...
{
"rxData": "bA=="
}
{
"rxData": "bw=="
}
{
"rxData": "Gw=="
}
{
"rxData": "Ww=="
}
{
"rxData": "MA=="
}
{
"rxData": "bQ=="
}
{
"rxData": "IA=="
}
{
"rxData": "Mg=="
}The received data has changed after changing the baudrate, but there was no applied_settings response sent by the server.
This proves that the monitor starts to produce the expected output after switching to the correct 9600 baudrate:
"bA==" → l
"bG8bWzA=" → lo\x1b[0
"bQ==" → m
"IA==" → (space)
"MQ==" → 1
"DQ==" → \r (carriage return)
"Cg==" → \n (newline)
"Gw==" → \x1b (ESC)
"Ww==" → [
"Mw==" → 3
"Mw==" → 3
"bQ==" → m
"SA==" → H
"YQ==" → a
"bA==" → l
"bA==" → l
"bw==" → o
"Gw==" → \x1b (ESC)
"Ww==" → [
"MA==" → 0
"bQ==" → m
"IA==" → (space)
"Mg==" → 2
"DQ==" → \r
"Cg==" → \n
The generated struct is not called from the codebase:
arduino-cli/rpc/cc/arduino/cli/commands/v1/monitor.pb.go
Lines 326 to 331 in c41f5df
Expected behavior
The client receives the applied settings response after updating the monitor config.
Pipedream: the applied settings response contains the applied settingIds and the new values.
Arduino CLI version
Operating system
macOS
Operating system version
15.5
Additional context
The sketch that was used for the testing:
unsigned long previousMillis; unsigned int ansi = 1; unsigned int clearCounter = 0; const unsigned int CLEAR_COUNTER_MAX = 10; void setup() { Serial.begin(9600); } void loop() { if (Serial.available() > 0) { while (Serial.available() > 0) { Serial.write(Serial.read()); delay(10); } } else if (millis() - previousMillis >= 500) { if (clearCounter == CLEAR_COUNTER_MAX) { Serial.print("\x1b[2J\x1b[3J\x1b[;H"); clearCounter = 0; } previousMillis = millis(); Serial.print("\x1b[3"); Serial.print(ansi); Serial.print("mHallo\x1b[0m "); Serial.println(clearCounter); ansi++; clearCounter++; if (ansi > 6) { ansi = 1; } if (clearCounter == CLEAR_COUNTER_MAX) { Serial.println("Clearing terminal in next tick..."); } } }
Issue checklist
- I searched for previous reports in the issue tracker
- I verified the problem still occurs when using the nightly build
- My report contains all necessary details