Skip to content

[GRPC] Monitor does not emit applied_settings response after changing the baudrate #2965

@dankeboy36

Description

@dankeboy36

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:

// Settings applied to the port, may be returned after a port is opened (to
// report the default settings) or after a new port_configuration is sent
// (to report the new settings applied).
MonitorPortConfiguration applied_settings = 3;

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.Init

Start 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:

type MonitorResponse_AppliedSettings struct {
// Settings applied to the port, may be returned after a port is opened (to
// report the default settings) or after a new port_configuration is sent
// (to report the new settings applied).
AppliedSettings *MonitorPortConfiguration `protobuf:"bytes,3,opt,name=applied_settings,json=appliedSettings,proto3,oneof"`
}

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

c41f5df

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

Metadata

Metadata

Assignees

Labels

type: imperfectionPerceived defect in any part of project

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions

    pFad - Phonifier reborn

    Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

    Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


    Alternative Proxies:

    Alternative Proxy

    pFad Proxy

    pFad v3 Proxy

    pFad v4 Proxy