adam/Remote-Terminal-for-MeshCore
1
0 Fork 0
mirror of https://github.com/jkingsman/Remote-Terminal-for-MeshCore.git synced 2026-11-01 07:15:46 +01:00
Code Issues 26 Packages Projects Releases Wiki Activity

Radio-parameter updates silently disable companion repeat mode (no way to see or set it) #263

New Issue
Open
opened 2026-10-05 02:06:18 +02:00 by adam · 0 comments
adam commented 2026-10-05 02:06:18 +02:00
Owner
Copy link
Copy source

📝 Problem Description

MeshCore companions have a "repeat" flag (the repeater-mode checkbox in the official app). RemoteTerm can't display or set it, and worse, any radio-parameter change made through RemoteTerm resets it to off on the node.

The firmware sets the flag from a trailing byte on CMD_SET_RADIO_PARAMS, and treats a missing byte as repeat = 0 and persists it:

// examples/companion_radio/MyMesh.cpp, CMD_SET_RADIO_PARAMS
uint8_t repeat = 0;  // default - false
if (len > i) {
  repeat = cmd_frame[i++];   // FIRMWARE_VER_CODE 9+
}
...
_prefs.client_repeat = repeat;
savePrefs();

app/services/radio_commands.py::apply_radio_config_update calls mc.commands.set_radio(freq, bw, sf, cr) without repeat, so meshcore omits the byte.

🚦 Current Behavior

Saving a frequency, bandwidth, SF or CR change in RemoteTerm turns repeat mode off on a node that had it enabled from the app. Nothing in the UI shows the flag, so the user doesn't find out until they notice the node stopped repeating.

🎯 Expected Behavior

Radio-parameter updates leave the repeat flag as it was. Ideally RemoteTerm also shows the flag and lets you toggle it, like the official app does.

📋 Steps to Reproduce

  1. Enable repeater mode on a companion from the MeshCore app (or otherwise set client_repeat = 1).
  2. In RemoteTerm, Settings → radio settings, change any radio parameter (e.g. SF) and save.
  3. Query the device: DEVICE_QUERY reply byte 80, or device_info["repeat"] via meshcore-py. It is now 0.

📡 Radio Node

  • Firmware version: v1.16.0, companion protocol 13 (also applies to anything at protocol ≥ 9, which is when the repeat byte was added)
  • Hardware / board type: Raspberry Pi 4 + RAK6421 / RAK13302 (SX1262), running the Linux build of MeshCore companion firmware (meshcore-linux)

🔌 Connection to the Radio

  • Direct or intermediary? Direct. The node is the MeshCore companion firmware itself compiled for Linux, speaking the companion protocol natively over TCP. No pyMC / OpenHop in between.
  • Transport: TCP

💻 Environment Information

  • OS: Unraid (Docker), RemoteTerm container from the Community Apps template
  • Browser / Version: Chrome / 153.0.8010.48
  • RemoteTerm Version: v3.17.1

📸 Screenshots / Debug Logs

Not really a log-shaped bug. The cause is visible in the two code paths above. Happy to attach a debug snapshot if useful.

Additional context

Everything underneath RemoteTerm already supports the flag: meshcore 2.3.7 (the pinned version) has set_radio(..., repeat=None), parses device_info["repeat"], and has get_allowed_repeat_freq().

I'd like to submit a PR for this. Proposed shape:

  • RadioConfigResponse.repeat_enabled: bool, read from device info (self_info doesn't carry the flag).
  • RadioConfigUpdate.repeat_enabled: bool | None.
  • apply_radio_config_update always passes repeat= to set_radio: the requested value, or the node's current value when the caller didn't ask to change it. That fixes the reset for existing users regardless of the UI.
  • Firmware rejects repeat=1 on frequencies outside its allowed list (stock builds: 433.000 / 869.495 / 918.000 MHz), so surface that through the existing RadioCommandRejectedError → 422 path with a clear message rather than pre-validating in RemoteTerm.
  • A checkbox in the radio settings section, mirroring the official app.

repeat_enabled matches the existing RepeaterRadioSettingsResponse.repeat_enabled naming.

## 📝 Problem Description MeshCore companions have a "repeat" flag (the repeater-mode checkbox in the official app). RemoteTerm can't display or set it, and worse, any radio-parameter change made through RemoteTerm resets it to off on the node. The firmware sets the flag from a trailing byte on `CMD_SET_RADIO_PARAMS`, and treats a missing byte as repeat = 0 and persists it: ```c++ // examples/companion_radio/MyMesh.cpp, CMD_SET_RADIO_PARAMS uint8_t repeat = 0; // default - false if (len > i) { repeat = cmd_frame[i++]; // FIRMWARE_VER_CODE 9+ } ... _prefs.client_repeat = repeat; savePrefs(); ``` `app/services/radio_commands.py::apply_radio_config_update` calls `mc.commands.set_radio(freq, bw, sf, cr)` without repeat, so meshcore omits the byte. ## 🚦 Current Behavior Saving a frequency, bandwidth, SF or CR change in RemoteTerm turns repeat mode off on a node that had it enabled from the app. Nothing in the UI shows the flag, so the user doesn't find out until they notice the node stopped repeating. ## 🎯 Expected Behavior Radio-parameter updates leave the repeat flag as it was. Ideally RemoteTerm also shows the flag and lets you toggle it, like the official app does. ## 📋 Steps to Reproduce 1. Enable repeater mode on a companion from the MeshCore app (or otherwise set client_repeat = 1). 2. In RemoteTerm, Settings → radio settings, change any radio parameter (e.g. SF) and save. 3. Query the device: DEVICE_QUERY reply byte 80, or device_info["repeat"] via meshcore-py. It is now 0. ## 📡 Radio Node - Firmware version: v1.16.0, companion protocol 13 (also applies to anything at protocol ≥ 9, which is when the repeat byte was added) - Hardware / board type: Raspberry Pi 4 + RAK6421 / RAK13302 (SX1262), running the Linux build of MeshCore companion firmware (meshcore-linux) ## 🔌 Connection to the Radio - Direct or intermediary? Direct. The node is the MeshCore companion firmware itself compiled for Linux, speaking the companion protocol natively over TCP. No pyMC / OpenHop in between. - Transport: TCP ## 💻 Environment Information - OS: Unraid (Docker), RemoteTerm container from the Community Apps template - Browser / Version: Chrome / 153.0.8010.48 - RemoteTerm Version: v3.17.1 ## 📸 Screenshots / Debug Logs Not really a log-shaped bug. The cause is visible in the two code paths above. Happy to attach a debug snapshot if useful. --- **Additional context** Everything underneath RemoteTerm already supports the flag: meshcore 2.3.7 (the pinned version) has `set_radio(..., repeat=None)`, parses `device_info["repeat"]`, and has `get_allowed_repeat_freq()`. I'd like to submit a PR for this. Proposed shape: - `RadioConfigResponse.repeat_enabled: bool`, read from device info (self_info doesn't carry the flag). - `RadioConfigUpdate.repeat_enabled: bool | None`. - `apply_radio_config_update` always passes `repeat=` to `set_radio:` the requested value, or the node's current value when the caller didn't ask to change it. That fixes the reset for existing users regardless of the UI. - Firmware rejects `repeat=1` on frequencies outside its allowed list (stock builds: 433.000 / 869.495 / 918.000 MHz), so surface that through the existing `RadioCommandRejectedError` → 422 path with a clear message rather than pre-validating in RemoteTerm. - A checkbox in the radio settings section, mirroring the official app. `repeat_enabled` matches the existing `RepeaterRadioSettingsResponse.repeat_enabled` naming. <!-- github-sync-id:5556743747 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/Remote-Terminal-for-MeshCore#263