Add lora.hop_limit to Settings menu

[klikva]

The only parameter I regularly change via CLI on my T-Deck is the lora.hop_limit value. When I’m in the area near my home (and my Meshtastic <-> Matrix gateway), a value of 3 or 4 works perfectly. However, when I travel longer distances or try to reach a friend 100+ km away, I need to increase it to 7. Since I don’t want to flood the network, I have to adjust this value frequently. Having this option available directly in the settings would be very helpful.

[dzienisz]

Yes, please! There are not enough settings in T-Deck settings.

[mverch67]

There is usually no need to change this setting because MUI is handling it automatically based on the received nodeinfo. Setting hops to 7 is never a good idea. It will do more harm than good. Instead the network topology should be adapted accordingly.

[dzienisz]

@mverch67 soo what is your approach when you live in a big city? In Poland we told everybody to set hops to 7.

Check here: https://lorastats.pl/

[mverch67]

@mverch67 soo what is your approach when you live in a big city?

As I said: no need as MUI sets the right value automatically.

[aseiger]

what do you mean by it setting hops automatically? As far as I know the only way to set hops on a T-Deck or other MUI device is to put it into Bluetooth/BaseUI mode and change the setting there.

[klikva]

There is usually no need to change this setting because MUI is handling it automatically based on the received nodeinfo. Setting hops to 7 is never a good idea. It will do more harm than good. Instead the network topology should be adapted accordingly.

I agree that there is usually no need to change this setting, but there are situations where it can be useful. For example, if you need to chat on a group channel where the members are farther than 3 hops away. Also, when communicating on the edge, some messages may take a route with 3 hops, while others may require 4 hops, and so on.

From a practical point of view, I see a lot of people leaving the setting at 7 hops after experimenting with a higher number, simply because they are too lazy to set it back lower.

I could imagine a solution where this setting is not permanent and resets to the default of 3 after a reboot. Would this be acceptable to you?

[aseiger]

I actually don't use my T-Deck much anymore, simply because it's hard to set the hop count around - I often need to go to 7 to reach edge-to-edge of our local mesh.

Also, could someone elaborate on what "MUI sets the right value automatically" means? If MUI is changing hop count without the user explicitly saying so, that feels like an over-reach of what MUI is supposed to do

OK found it here:

device-ui/source/graphics/TFT/TFTView_320x240.cpp

Line 4343 in 3677476

void TFTView_320x240::handleAddMessage(char *msg)

It looks like that's just for DM's though?

[dzienisz]

Maybe we should have information on how many hops are set?

[klikva]

I understand the argument that MUI is supposed to handle hop limits automatically, but based on my practical experience, this isn’t always the case — especially in mixed or larger networks.

In many real-world setups, especially when using group channels or edge nodes, messages may require more than the default 3 hops to reach their destination reliably. In such cases, being able to temporarily override the hop limit directly from the device (e.g. T-Deck) is extremely useful.

Also, I don’t see why this should be restricted specifically in the MUI interface — users can already change the hop limit freely via CLI or Bluetooth, so this would only bring consistency across different interfaces. If this setting is considered “dangerous,” it should ideally be restricted (or warned about) everywhere, not just in MUI.

As a compromise, I would suggest either:

• making the setting temporary (e.g. automatically reverting to default after reboot), or
• adding a warning dialog/pop-up when setting a high hop limit (e.g. “You are setting a high hop limit — this may flood the network. Continue?”) which the user has to confirm at every startup of the device.

This would make the user experience much better, while keeping the network safe and avoiding accidental misuse.