[Feature Request]: Admit Router Client was a mistake

garthvh commented 3 days ago

Platform

NRF52, ESP32, RP2040, Linux Native

Description

Router client was a bad choice, make router client behave exactly as client does and disable BLE for router so that the role is only used for infrastructure nodes as intended.

rcarteraz commented 3 days ago

Platform

NRF52, ESP32, RP2040, Linux Native

Description

Router client was a bad choice, make router client behave exactly as client does and disable BLE for router so that the role is only used for infrastructure nodes as intended.

+1

daviesgeek commented 3 days ago

Can you explain the reason why it was a bad idea?

Am just trying to gain more understanding of the function behind each role.

Also if router is going to be the new role for nodes with good locations, then I'm not sure we can really use it on nodes for which we need BLE.

I have a roof node that is in a good position but I also connect to it a lot via BLE, which now wouldn't be possible without router client.

b8b8 commented 3 days ago

Is your roof node on top of a mountain or radio tower? If not the mesh would be better served setting it to client and letting the mesh algorithm determine the routing priority. Setting it to router or router_client automatically overrides this and transmits immediately, regardless of if the node is actually in an advantageous position. By removing bluetooth connection and only allowing remote management over the mesh, this biases the setting to be only really useful as an infrastructure node and not simply one on someone's roof that they are interfacing with directly. Your roof node would still fully contribute to the mesh network based on signal strength where appropriate but wouldnt step on the signal from nodes that are better positioned on an actual mountain.

madeofstown commented 2 days ago

One concern I have is that I will lose the ability to do Store and Forward. As far as I know, that feature is only available on Router-Client / Router. If I change my rooftop Router-Client to just Client I lose that.

Also, if a node is routing to MQTT it would also make sense for it to be a Router-Client/Router regardless of position.

garthvh commented 2 days ago

One concern I have is that I will lose the ability to do Store and Forward. As far as I know, that feature is only available on Router-Client / Router. If I change my rooftop Router-Client to just Client I lose that.

Also, if a node is routing to MQTT it would also make sense for it to be a Router-Client/Router regardless of position.

A mobile node should also not be a store and forward router, the router roles need advantageous position or they quickly become a negative for the mesh.

thebentern commented 2 days ago

Also, if a node is routing to MQTT it would also make sense for it to be a Router-Client/Router regardless of position.

I think this is where the semantics of Router really get problematic. Routers are only intended be preferred routes over the physical (LoRA) mesh. MQTT shouldn't bear relevance to the decision of role choice. If anything, in most cases client or client mute to link MQTT makes more sense in most contexts, unless you have PoE network connected node on a tower.

madeofstown commented 2 days ago

One concern I have is that I will lose the ability to do Store and Forward. As far as I know, that feature is only available on Router-Client / Router. If I change my rooftop Router-Client to just Client I lose that. Also, if a node is routing to MQTT it would also make sense for it to be a Router-Client/Router regardless of position.

A mobile node should also not be a store and forward router, the router roles need advantageous position or they quickly become a negative for the mesh.

I'm not referring to a mobile node. This is my home Router-Client. It sits on top of my house and I occasionally log in to check things. I have it set up to do Store and Forward so that I can receive messages on my mobile node when I get back in range.

You devs keep talking about aadvantageous positions for Routers yet you haven't clearly defined what that means. Is my home an advantageous position if it is elevated from the surrounding area and there aren't any other nodes around for couple miles? Let's get some metrics listed so people understand this.

thebentern commented 2 days ago

I'm not referring to a mobile node. This is my home Router-Client. It sits on top of my house and I occasionally log in to check things. I have it set up to do Store and Forward so that I can receive messages on my mobile node when I get back in range.

I think we should consider opening up Store and Forward to other roles, honesty. Some of the feature-set of Routers and S&F seem antithetical at points.

You devs keep talking about advantageous positions for Routers yet you haven't clearly defined what that means. Is my home an advantageous position if it is elevated from the surrounding area and there aren't any other nodes around for couple miles? Let's get some metrics listed so people understand this.

@b8b8 said it well: "Is your roof node on top of a mountain or radio tower? If not the mesh would be better served setting it to client and letting the mesh algorithm determine the routing priority."

thebentern commented 2 days ago

PS: Sorry I think I accidentally edited your comment while trying to quote reply to it 😓

b8b8 commented 2 days ago

One concern I have is that I will lose the ability to do Store and Forward. As far as I know, that feature is only available on Router-Client / Router. If I change my rooftop Router-Client to just Client I lose that. Also, if a node is routing to MQTT it would also make sense for it to be a Router-Client/Router regardless of position. A mobile node should also not be a store and forward router, the router roles need advantageous position or they quickly become a negative for the mesh.

I'm not referring to a mobile node. This is my home Router-Client. It sits on top of my house and I occasionally log in to check things. I have it set up to do Store and Forward so that I can receive messages on my mobile node when I get back in range.

You devs keep talking about aadvantageous positions for Routers yet you haven't clearly defined what that means. Is my home an advantageous position if it is elevated from the surrounding area and there aren't any other nodes around for couple miles? Let's get some metrics listed so people understand this.

Your roof node would still get used in the network when set to client, it would just wait for the 1 second or so listening to see if another router on top of a mountain should transmit first, and if not, it would transmit. The router mode is more like "trust me i know i am the best in the area" instead of lets determine who is the best in the area organically using the algorithm. The S&F note though makes sense certainly and to me makes even more sense than the current implementation. I would want a s&f node at home like you to see what messages my home missed when i was away and have little use for it located somewhere else physically. It may even be the case (havent checked) but i think S&F should be zero hopped so you dont flood the mesh and just download your own messages "locally" with littl impact to the rest of network.

new role: BaseStation - client + store and forward + assume always powered ?

madeofstown commented 2 days ago

OK, Router-Client gets renamed to Base Station and loses priority routing. Is that doable?

meshtastic-bot commented 1 day ago

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/meshtastic-scotland/11479/157

petrkr commented 11 hours ago

So it means. If I have router node on 40m height observatory with 100km+ view. It is PoE powered and it using CLIENT mode to be used with gather data or make something like BBS or whatever. Then this node must add another CLIENT radio node in order to achieve same working ?

Because if I will switch this ROUTER_CLIENT to just CLIENT, it will delay ALL routings in that 100km range area

And if I will switch to ROUTER that node will lost ability to act as CLIENT with connected Rpi/Server/MQTT/Whatever.

So solution to "help" network is add 2nd mesh device, which will ALL nodes keep in database and which will ALL nodes in range rebroadcast...

Brilliant idea... Or maybe I missing some other solution than add on every hill/good place 2nd CLIENT node

petrkr commented 11 hours ago

And one more question.. in ROUTER mode, will remote admin over LoRa works - for that hill instalations without network connections?

b8b8 commented 10 hours ago

The delay is like 1 second, its not noticeable. Routers can still be controlled with remote admin over LoRa.

petrkr commented 10 hours ago

The delay is like 1 second, its noticeable. Routers can still be controlled with remote admin over LoRa.

Thanks for reply

delay is not problem, priority is problem.

High level placed Router_Client node act better than just Client on same place, regarding to routing for example.

But if I will need on that place use also Client mode/API, then I have no reason to put there node at all, because degraded Client mode will degrade performance as clients will rather jump over Router nodes on lower places.

Adding 2nd Client node will decrees network stability as there will be one more node to relay.

I hope they will find solution for those node purposes.

I want have there router node with ability to post messages to MQTT (but not to LoRa, only that who it heard).

Maybe, if there will be some benefit from it, I will make it as BBS node as-well.

But still mainly it is best placed ROUTER (prio routing) node with CLIENT (API) abilities

So what is solution after this mode will be disabled ?

garthvh commented 10 hours ago

The delay is like 1 second, its noticeable. Routers can still be controlled with remote admin over LoRa.

Thanks for reply

delay is not problem, priority is problem.

High level placed Router_Client node act better than just Client on same place, regarding to routing for example.

But if I will need on that place use also Client mode/API, then I have no reason to put there node at all, because degraded Client mode will degrade performance as clients will rather jump over Router nodes on lower places.

Adding 2nd Client node will decrees network stability as there will be one more node to relay.

I hope they will find solution for those node purposes.

I want have there router node with ability to post messages to MQTT (but not to LoRa, only that who it heard).

Maybe, if there will be some benefit from it, I will make it as BBS node as-well.

But still mainly it is best placed ROUTER (prio routing) node with CLIENT (API) abilities

So what is solution after this mode will be disabled ?

Use router as intended, a mobile router is not a valid use case as a moving node by definition can't be in an advantageous position.

petrkr commented 10 hours ago

Use router as intended, a mobile router is not a valid use case as a moving node by definition can't be in an advantageous position.

At mobile node it is sure to use CLIENT.

I am asking for fixed ROUTER node on good propagation place which can work also as client for some services.

CLIENT - For mobile devices, in pocket ROUTER - For fixed stations without connection or any other services provided (But still I guess telemetry can be used as temperature for example)

But what about nodes, which are fixed, with good propagation, where you have UPS backed power with optic internet connection and you want provide some services?

That is NOT client, that is ROUTER with Client features.

Or again,, you can use ROUTER mode but also can connect there from python client over TCP for example?

Maybe there is just missunderstand what CLIENT feature actually is compared to ROUTER one.

From documentation I thought it is exactly that control node from python (or other language).

petrkr commented 10 hours ago

Actually for mobile node in pocket best mode is CLIENT_MUTE, because there is no reason such client will relay/routing function if it is moving.

TheCommsChannel commented 10 hours ago

One of our concerns here is we have a number of solar nodes on mountaintop towers that we would prefer to be able to perform firmware updates via bluetooth instead of having to climb up the tower to perform them.

Would a change to router_client that only allows the bluetooth for updates/admin and disable the ability to use it as a chat client be possible?

petrkr commented 9 hours ago

One of our concerns here is we have a number of solar nodes on mountaintop towers that we would prefer to be able to perform firmware updates via bluetooth instead of having to climb up the tower to perform them.

Would a change to router_client that only allows the bluetooth for updates/admin and disable the ability to use it as a chat client be possible?

That is another question.

For example, BLE does not have such range. So if I will have to update only by BLE, I need still climb 40m to observatory to get in range. Instead of Wifi/LAN I can do it remotely from 100km city.

But yes, Solar nodes mostly will NOT have WiFi as WiFi have onlly ESP32 and that has more power consumption than for exampe RAK. But RAK does not have wifi...

So there is question if such node is good choice for those nodes at all.