[Feature Request]: Role between CLIENT and CLIENT_MUTE

[afourney]

Platform

Cross-Platform

Description

Feature Request

I am requesting that a new device role be created to fill the gap between CLIENT and CLIENT_MUTE. Basically, a CLIENT_WAIT_AS_LONG_AS_POSSIBLE (naming isn't my strong suit!) Or alternatively, maybe there could be a way to introduce a custom penalty or delay when setting up CLIENT, to allow more fine-grained control over transmission precedence in a local area.

Reasoning

There are many situations where it would be nice for a device to participate in the network, but also be deprioritized. For example, I have a solar node (RAK) on my roof with a 5bi antenna, and Heltec v3 in my basement, connected to Wifi and set up for MQTT. This configuration is necessary due to solar power constraints, and the lack of Wifi on the RAK. The Heltec is currently required to be set to CLIENT mode in order to bidirectionally bridge packets to RF, but then it fights with my roof node to retransmit RF traffic when nodes are close to my house. The roof node is ALWAYS the better choice for pure RF retransmission in this case.

Likewise, I carry a T1000e tracker in my pocket. It's almost always the worst choice for RF retransmission -- so I set the device to CLIENT_MUTE. However, this precludes the node from ever participating in the Mesh -- even if it's the only node around (e.g., when traveling about). A role between CLIENT and CLIENT_MUTE will potentially resolve this.

TL;DR;

I'd like there to be a deprioritized role that fills the gap between CLIENT and CLIENT_MUTE. Effectively, the opposite of CLIENT_ROUTER

[b8b8]

The correct setup for this situation would be to set to client_mute at home, client_mute in the city, and client when in sparse areas like hiking etc. I dont think there is a need for a new role. A node generally in your pocket shouldnt really be set to anything but client_mute.

[apoger]

But why shouldn't we use the proposed design to kind of automate the switching? It could even reduce network load/bad repeatings when every node starts default as defacto client_mute aka CLIENT_WAIT_AS_LONG_AS_POSSIBLE.

Good placed nodes could switch to client. Best placed stay router.

I like your idea, afourney.

[afourney]

The correct setup for this situation would be to set to client_mute at home, client_mute in the city, and client when in sparse areas like hiking etc. I dont think there is a need for a new role. A node generally in your pocket shouldnt really be set to anything but client_mute.

This is perhaps the weaker argument, I agree. But I've still got the problem with my solar node being in a better position, with a better antenna, but not having MQTT or wifi access. There's no great way to bridge these two.. they fight over RF retransmission. Consequently, I've set my roof node to ROUTER, which is discouraged. But my local mesh has agreed with this experiment.

[b8b8]

To me the better solution is a home zone without creating a new role. If within say 2km of home, set to client mute, else set to client. This may be something that can be set using the phone's location and not the firmware at all, since it is probably safe to assume you have your phone with you when you go out and its bluetoothed to your node.

For MQTT most people in that situation have a second node sitting on their desk set to client_mute that acts as just an MQTT relay (though at the expense of another hop).

[afourney]

To me the better solution is a home zone without creating a new role. If within say 2km of home, set to client mute, else set to client. This may be something that can be set using the phone's location and not the firmware at all, since it is probably safe to assume you have your phone with you when you go out and its bluetoothed to your node.

For MQTT most people in that situation have a second node sitting on their desk set to client_mute that acts as just an MQTT relay (though at the expense of another hop).

I like the home zone idea...

The MQTT relay on the desk only works for Uplink, not Downlink. When set to CLIENT_MUTE, there is no routing participation. So no way to bridge the incoming MQTT back out to the local RF mesh. This was the first thing I tried, and I was disappointed when it did not work. An alternative would be to allow CLIENT_MUTE_EXCEPT_MQTT... but this feels even more esoteric.

[b8b8]

MQTT down-link is zero hopped to not flood the local RF mesh with internet traffic for all roles (unless you are running a custom setup). In general you cannot pass any MQTT traffic over the mesh, only receive and upload.

[afourney]

MQTT down-link is zero hopped to not flood the local RF mesh with internet traffic for all roles (unless you are running a custom setup). In general you cannot pass any MQTT traffic over the mesh, only receive and upload.

We are running non-Default set up, with a private MQTT server, on our local mesh group, with a channel PSK. It works fine when the node is set to CLIENT. We believe we are configuring things appropriately, and respectfully, within the current design parameters of Meshtastic. Everything works fine, as designed, except CLIENT_MUTE is too restrictive, and CLIENT is too permissive.

[GUVWAF]

We're working on a ROUTER_LATE role here (#5528), that would help for e.g. your roof node.

[afourney]

We're working on a ROUTER_LATE role here (#5528), that would help for e.g. your roof node.

This looks like it would fit the bill. I look forward to this role.

[caveman99]

follow up in #5528