…sounds like a stupid question but i still wonder what the difference is. Both, client und router are forwarding packets and one can write a direct message to both, right?!
So what is the difference? I think that there are some parameters with a different default value. But do they fundamentally behave different in the mesh? I’m running a few nodes now, some in router mode. But i never noticed a dramatic difference. Also i found no tutorial somewhere explaining the differences in detail.
Can someone point this out?
2 Likes
1 Like
OK.
“Router - Mesh packets will prefer to be routed over this node. This node will not be used by client apps. The WiFi/BLE radios and the OLED screen will be put to sleep.”
A concrete example: I’m using a RAK4631, which has no screen and no WiFi anyway. I manually set bluetooth.enabled = false in a .yaml file. And this node is the only one on a certain path. So in this case there is no difference between Router and Client (?).
You want to use the router role on fixed nodes with a placement advantage, they will rebroadcast faster than client nodes will so if you have a cluster of handset nodes at base camp and a solar router at the top of a mountain, the mesh will prefer to route messages over the node on the mountain rather than the cluster of nodes next to each other that could easily use up all the hops without traveling much distance.
3 Likes
There seem to be more differences with default parameter settings relative to clients:
I just (unintentionally) set a node as a ROUTER and then wondered why it is impossible to set power.lsSecs 300. It was fixed at 86400. I tried this with the CLI and with the Android app. The value insisted to stay on 86400. Then i noticed that the device role is ROUTER. As soon as i changed to CLIENT, power.lsSecs was set to 300 automatically.
This is confusing! When i change device.role from 0 to 2 then i expect that nothing else, except the device.role changes. But it isn’t like that!
Also, i noticed that in ROUTER mode, the power saving is enabled by default, even if the output of meshtastic --get power.is_power_saving is false. This is both shown also on CLI and in the app. And indeed the node fell into deep sleep mode, so the power saving must have been active! This is even more confusing! Actually when the node falls into deep sleep, it will wake up just after a year again. It seems to forward packets, sometimes, somehow. But when i reset my local node, the router does not appear in my node list.
This all is from V2.0.12
I have a 30W solar panel for the remote node, oriented to south, with no shadow from trees. So i don’t expect any power problems, even in longer dark periods in winter… No need for deep sleep stuff actually.
Here is the example:
t@est:~/Meshtastic/Firmware$ meshtastic --get device.role
Connected to radio
device.role: 0
Completed getting preferences
t@est:~/Meshtastic/Firmware$ meshtastic --get power.lsSecs
Connected to radio
power.ls_secs: 300
Completed getting preferences
t@est:~/Meshtastic/Firmware$ meshtastic --set device.role 2
Connected to radio
Set device.role to 2
Writing modified preferences to device
t@est:~/Meshtastic/Firmware$ meshtastic --get device.role
Connected to radio
device.role: 2
Completed getting preferences
t@est:~/Meshtastic/Firmware$ meshtastic --get power.lsSecs
Connected to radio
power.ls_secs: 86400
Completed getting preferences
t@est:~/Meshtastic/Firmware$ meshtastic --set power.lsSecs 300
Connected to radio
Set power.ls_secs to 300
Writing modified preferences to device
t@est:~/Meshtastic/Firmware$ meshtastic --get power.lsSecs
Connected to radio
power.ls_secs: 86400
Completed getting preferences
t@est~/Meshtastic/Firmware$ meshtastic --set device.role 0
Connected to radio
Set device.role to 0
Writing modified preferences to device
t@est~/Meshtastic/Firmware$ meshtastic --get power.lsSecs
Connected to radio
power.ls_secs: 300
Completed getting preferences
t@est~/Meshtastic/Firmware$
Conclusion: Obviously a router does not only rebroadcast faster, it also has a fixed power.ls_secs value of 86400 and power saving is forced to be enabled, which let’s the router disappear from the node list (after a NodeDB reset) as soon as it fell into deep sleep mode.
For me this is a reason to run all nodes in CLIENT mode, as long as that problem exists. Or did i misunderstand something?
3 Likes
Take a look at the source code:
Line 23 in PowerFSM.cpp seems to tell that the PowerSavingMode is always ON if the node is a Router.
The firmware writers assume that a solar power source has (always) low power. But if so, the operator could manually enable the power saving mode. If you have a 100 W module and a 50 Ah battery, then you don’t need this. But Router + PowerSavingMode=false seems to be impossible without modifying the firmware…
I’m going to open an issue on github, although i expect that it will be deleted after some minutes…
Issue submitted: [Bug]: Router without power saving mode · Issue #2203 · meshtastic/firmware · GitHub
1 Like
Why not use the router client role as intended?
In Device Configuration | Meshtastic there is no information about that difference. Or do i miss another tutorial?
How can people know and what sense does it make that power saving is on although:
t@est:~$ meshtastic --set device.role 2
Connected to radio
Set device.role to 2
Writing modified preferences to device
t@est:~$ meshtastic --get power.is_power_saving
Connected to radio
power.is_power_saving: False
Completed getting preferences
The fact is: It says that power.is_power_saving: False although it is true. If that’s not a bug…
If the result of meshtastic --get power.is_power_saving would have been correct, then i and other would have saved a lot of time…
So update the docs? The new version launched at the end of November and the whole project is volunteers. The roles are how these things are going to be managed going forward.
You can always compile your own version with your desired specifications 
I don’t know how you can expect the developers to cater to each individual users desired functionality. If you think it’s a bug, report it and wait until they either fix it because it was or close it if it’s not. I don’t see the need to get so confrontational in the forum because it’s not to your liking. Behavior like that is what causes developers to get frustrated and move on from projects, especially when dealing with open-sourced all volunteer projects.
I know i know.
That what i did here, i asked a question and took effort to describe a strange behaviour of the firmware, see all the details above. Isn’t that a constructive way to help improving things?
The thing is: If you take care and effort to describe a problem or a bug, and you get an answer of not even a single line, like
then this is frustrating.
Basic communication levels. An answer like that has another message in the sub-text, which tries to let you appear as a fool just because you didn’t find the solution (if this is the solution at all) on your own. Even more, if the information is not available, except you are one of the deep firmware writers or member of the project from the beginning.
And it is not the first time that i’m getting quick answers of half a line, which do not even solve the problem.
3 Likes
I’m sorry but is it possible that you might be reading into it more than you really need to? I think it’s less about making anyone feel like a fool and more about pointing out that you’re not using it as intended. Which, goes back to not being able to cater to each individual users desired functionality.
As someone that has been working to improve the documentation, of course there is more that can be done but time is limited and we all volunteer. If you have suggestions, feel free to open an issue in the documentation repo or if you want to volunteer you can submit a PR for review.
You’ve submitted your bug report, so at this time the best thing you can do is wait to see how they act on it. Either it is a bug and they’ll fix it, or it’s not and they’ll let you know it’s operating as planned.
Power saving mode turns off the BLE/Wifi radios and the screen. When using as a Router, the intent is that it’s just a standalone device that a person won’t be controlling directly, so the behavior and code are correct because there is no need for these to be on (and eating up power for no reason).
That’s fine.
This is not intuitive. And this is not described anywhere except in the source code.
“standalone device” does not necessarily mean lack of electricity.
Well, there are 2 parameters: device.role and power.is_power_saving
If you execute the command line:
meshtastic --set device.role 2 --set power.is_power_saving false
then you expect to have a router with disabled power saving, right?
And then, if you check
t@est:$ meshtastic --get device.role --get power.is_power_saving
Connected to radio
device.role: 2
power.is_power_saving: False
Completed getting preferences
then you expect even more to have a router with disabled power saving, right?
So then, you climb a mountain and place that router up there and after some time is becomes passive and you wonder what is wrong…
Just to avoid misunderstandings: You say that the code is correct with the above bahaviour, i.e. that power saving is true although the result from meshtastic --get power.is_power_saving is false?
Now, there are these two parameters. Let’s distinguish two examples:
1: Someone wants to place a router on a hill with a small solar module.
2: Someone wants to place a router on a high building with access to electricity.
Solution for 1: meshtastic --set device.role 2 --set power.is_power_saving true
Solution for 2: meshtastic --set device.role 2 --set power.is_power_saving false
That (could) be all. So why is it “intended” to force power.is_power_saving true if this is not necessary. It is simply not necessary to do this. And it is unintuitive, that’s the main trap!
PS: There are 3 concrete questions in my post (with the ‘?’ at the end). Please, if you you respond, please respond directly to these 3 questions. I just say it that clearly because unfortunately often (or even mostly) answers do not relate to the asked questions.
Question 3: yes, as you showed, from PowerFSM.cpp you can derive that setting power saving to false will not do anything for a Router. So, regarding question 1 and 2, I agree that it is not so intuitive that if you set power saving to false it is actually still in power saving mode, because it is a Router. You can propose to add this to the documentation.
As Garth mentioned, the combination of Router without power saving can be obtained using ROUTER_CLIENT. Power saving is by default false as you can see from the docs and will thus by default not used, except for a Router.
However, are you sure that “after some time it becomes passive” is really because of power saving? It might also be related to the duty cycle limit (see this and this).
I know what you mean, but in this case the duty cycle has not been the issue.
From what i heared, setting a node into router mode has an advantage regarding packet forwarding, and that’s expected from the name of course. But i would expect nothing more than a different handling of the packets.
My router is quite a new installation and i just like to see it in my node list, just like a client that tells every 900 seconds “Hello, i’m still here” 
But the router always disappeaed from the node list and i didn’t know if it is still up and just passive or if it crashed.
Once your mesh is running stable and any participant knows that communication between each other is no problem, it may be fine to use power saving stuff. But in the beginning you just want to exclude any eventualities, you want to be sure that that node IS on the air.
Of course you can do tricks like requesting the position and see if a feedback comes. But this is still not ideal for me. I have a 30W solar module and 18 Ah @ 12V lead-gel-accu. There is just no lack of electricity.
Router-Client, yes, that’s what i’m using now and so far it looks good. But it has been a long way to be there.
Still i vote for maximising intuitivity, i.e. i propose to remove the forced power saving mode in router mode because if someone want power saving, he can simply turn power saving on, in what ever device.role. Then, you don’t need to add this to the documentation. And no one needs to find that information in the documentation. That’s the advantage of a intuitive handling (which the i-phone is called to be so popular for): You don’t need to read manuals to become able to use a device.
2 Likes
This is again where if this is something you want then you should compile your own firmware. The roles are designed to work for what the majority of users will need/want. You cannot expect the developers to cater to every single users desired functionality.
There is not exactly a chorus of support for you not real intuitive suggestion, if you need a wall of confusing text as a response to every question your idea is probably not as intuitive as you think.
1 Like
I just have about 3 days experience with meshtastic, with that said.
Back in my LAN and WAN days my understanding of routers (in very simple terms) is that they connect two or more packet-switched networks or subnetworks. They serve two primary functions: managing traffic between these networks by forwarding and receiving data packets to and from their destination off the local network by providing a gateway to other destination networks. In addition routers may convert data between different protocols.
A client is simply a node or endpoint that runs an application that needs to communicate with another node or endpoint.
Therefore a router is simply a traffic cop telling data packets which way to go (routing) and managing the traffic flow efficiently. Consequently routers dedicate more cycles/processes to controlling and converting network traffic and less cycles to applications that actually use and process the data.
I am still confused to what it means in meshtastic terms, but i would guess clients run processes for application data (sensor telemetry, chat, etc.) more efficiently and routers dedicate more cycles to managing routing/mesh tables and the rules for forwarding and receiving packets to and from remote nodes/networks.
I am sorry to say i could be totally wrong but would love to hear from a meshtastic expert on how meshtastics definition applies to the classic definition.