[Bug]: remote admin partially not working

[jranma]

Category

Other

Hardware

Rak4631

Firmware Version

2.3.13

Description

Hello everyone,
it's partly a bug, and partly a feature request.
I tested the administration of nodes via the admin channel under real-life conditions. Alas, the implementation is good, but there are situations that don't work.

In a laboratory configuration, with a distance of a few meters between two nodes, no problems were observed.

In a real-world setting, with two nodes inline of sight, distance of 1km, I could change "simple" settings. But the management of channel-related parameters is very random, and only works very occasionally.
For example, I sent this command:
meshtastic --ch-set module_settings.position_precision 17 --ch-index 0 --dest !xxxxxx --no-time
and it only worked once out of 20 attempts.
This command requires the configuration of all the device's channels to be sent, so the risk of transmission errors is very high.
Does so much data have to be sent/received, just to change one simple parameter?

I consider this a bug as the situation between the two nodes was very favorable, and they were not far apart. The remote administration implementation can't be considered fully functional, although for most "simple" settings it works.

Thanks again to the devs for this great software.

Relevant log output

No response

[ianmcorvidae]

I'm not sure what the apps are doing differently here (@garthvh can perhaps clarify, since he moved this here -- though I think iOS doesn't support doing channel-related stuff on the admin channel at all, so maybe it's a question for the Android devs), but it might at least be possible to only send the update for the one channel being changed. I'll try to see if I can get something that way, at least.

[thebentern]

I know from personal experience, in addition to the theoretics, that longer packets are more vulnerable to interference in reaching their destination. Admin messages generally produce comparatively longer packets that normal traffic. So I can't say this is completely unexpected behavior because I've seen some of it as well. That said, I don't believe this is a problem solvable with firmware.

[jranma]

Maybe we could imagine a way to compress admin commands, so the payload is as small as possible.
Maybe it's already implemented, who knows ?
Channel admin management could probably be improved as big payload are used for quite "simple" operations.

[thebentern]

The fundamental architecture of admin commands would have to change. As it exists now, the entire config section objects are exchanged over the admin message payload, which leads to variably sized messages, in some cases very large if there are long strings like in the case of MQTT settings.

[garthvh]

iOS uses the admin channel for everything, including the local node. Channels can't be updated remotely right now but that is a different issue. Any packet that returns a response is less reliable than a packet that just wants an ack, but the way the python cli checks for all the channels is really inefficient @ianmcorvidae

[lysol]

Would love to see more efficient message handling for channel setting updates using the CLI. Or at least better behavior for retrying admin commands that generate timeouts -- a config option that attempts retries, temporarily retaining channel config information if one timeout is received so only the timeout'd channel setting fetches need to be retried, etc. I think adverse conditions are impossibly to eliminate entirely, but making it easier to keep at it until we see a success is doable. I may be able to put a PR together.