Better channel management #183

New Issue

2026-10-05T02:02:21+02:00

adam commented

2026-10-05 02:02:21 +02:00

I was really racking my brain because whenever I disconnected from my Remote Terminal node and used any other client, I noticed that the channel list from the node itself had been deleted. Now I understand why. Remote Terminal handles channels in a somewhat unusual way: it simply deletes them, and depending on which channel you want to send messages through, it adds them as needed and sends the message. In principle, I understand the procedure since Remote Terminal doesn’t rely on having any preconfigured channels to receive messages (it reads the RAW traffic and applies the decryption keys it has stored), but doing this interferes greatly with the node’s operation since it forces you to reconfigure the node every time you switch client applications.

In my opinion, this should be tweaked slightly so that, at the very least, the node’s list of configured channels isn’t deleted. It occurs to me that upon startup, the channel list could be retrieved; if there is a match with the channels configured in RemoteTerm, the existing configuration could be used, and if not, the highest available channel number could be used to configure the desired channel. This would at least reduce interference and allow the system to function correctly.

Here's a snippet showing how to retrieve the list of channels configured on the node and the maximum number of channels it supports (I assume you already have this under control, but it never hurts to double-check):

import asyncio
from meshcore import MeshCore, EventType
async def main():
    # Connect to the MeshCore node by TCP (IP: 192.168.1.10, Port: 5000)
    meshcore = await MeshCore.create_tcp("192.168.1.10", 5000)
    
    # Request detailed device information
    result = await meshcore.commands.send_device_query()
    if result.type != EventType.DEVICE_INFO:
        print("Failed to get device info:", result.payload)
        await meshcore.disconnect()
        return
    device_info = result.payload
    print("Device info fields returned:")
    for key, value in device_info.items():
        print(f"  {key}: {value}")
    # Attempt to find the max channels value from common fields
    max_channels = (
        device_info.get("max_channels")
        or device_info.get("channels_supported")
        or device_info.get("channels")
        or 10  # Fallback default if not found
    )
    print(f"Node reports support for {max_channels} channels\n")
    # Retrieve and display all channel configurations
    for idx in range(int(max_channels)):
        channel_result = await meshcore.commands.get_channel(idx)
        if channel_result.type == EventType.ERROR:
            print(f"Error retrieving channel {idx}: {channel_result.payload}")
        else:
            info = channel_result.payload
            print(f"Channel {idx}:")
            print(f"  Name: {info.get('name')}")
            print(f"  Secret: {info.get('secret')}")
            print(f"  Other data: {info}")
    await meshcore.disconnect()
asyncio.run(main())

I was really racking my brain because whenever I disconnected from my Remote Terminal node and used any other client, I noticed that the channel list from the node itself had been deleted. Now I understand why. Remote Terminal handles channels in a somewhat unusual way: it simply deletes them, and depending on which channel you want to send messages through, it adds them as needed and sends the message. In principle, I understand the procedure since Remote Terminal doesn’t rely on having any preconfigured channels to receive messages (it reads the RAW traffic and applies the decryption keys it has stored), but doing this interferes greatly with the node’s operation since it forces you to reconfigure the node every time you switch client applications. In my opinion, this should be tweaked slightly so that, at the very least, the node’s list of configured channels isn’t deleted. It occurs to me that upon startup, the channel list could be retrieved; if there is a match with the channels configured in RemoteTerm, the existing configuration could be used, and if not, the highest available channel number could be used to configure the desired channel. This would at least reduce interference and allow the system to function correctly. Here's a snippet showing how to retrieve the list of channels configured on the node and the maximum number of channels it supports (I assume you already have this under control, but it never hurts to double-check): ```python import asyncio from meshcore import MeshCore, EventType async def main(): # Connect to the MeshCore node by TCP (IP: 192.168.1.10, Port: 5000) meshcore = await MeshCore.create_tcp("192.168.1.10", 5000) # Request detailed device information result = await meshcore.commands.send_device_query() if result.type != EventType.DEVICE_INFO: print("Failed to get device info:", result.payload) await meshcore.disconnect() return device_info = result.payload print("Device info fields returned:") for key, value in device_info.items(): print(f" {key}: {value}") # Attempt to find the max channels value from common fields max_channels = ( device_info.get("max_channels") or device_info.get("channels_supported") or device_info.get("channels") or 10 # Fallback default if not found ) print(f"Node reports support for {max_channels} channels\n") # Retrieve and display all channel configurations for idx in range(int(max_channels)): channel_result = await meshcore.commands.get_channel(idx) if channel_result.type == EventType.ERROR: print(f"Error retrieving channel {idx}: {channel_result.payload}") else: info = channel_result.payload print(f"Channel {idx}:") print(f" Name: {info.get('name')}") print(f" Secret: {info.get('secret')}") print(f" Other data: {info}") await meshcore.disconnect() asyncio.run(main()) ```

adam closed this issue

2026-10-05 02:02:21 +02:00

adam commented

2026-10-05 02:02:22 +02:00

Generally speaking, I'm not super interested in trying to reduce radio impact due to how our architecture is set up -- letting RemoteTerm choose the best channels to keep on the radio reduces send latency so we don't have to round-trip a channel load before send. I agree that it would, in the abstract, be nicer to not delete channels, but this is a decently meaningful architectural change with how we maintain our channel state within the app. I'll keep this open to gauge interest, but this is not a top priority for me (RemoteTerm is most ideally a semi-permanent base station system).

Generally speaking, I'm not super interested in trying to reduce radio impact due to how our architecture is set up -- letting RemoteTerm choose the best channels to keep on the radio reduces send latency so we don't have to round-trip a channel load before send. I agree that it would, in the abstract, be nicer to not delete channels, but this is a decently meaningful architectural change with how we maintain our channel state within the app. I'll keep this open to gauge interest, but this is not a top priority for me (RemoteTerm is most ideally a semi-permanent base station system).

adam commented

2026-10-05 02:02:23 +02:00

I'm going to close this for now, but feel free to reopen if you'd like to continue the discussion.

I'm going to close this for now, but feel free to reopen if you'd like to continue the discussion.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

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