[Feature Request]: Admit Router Client was a mistake about firmware HOT 74 CLOSED

Seems like the devs keep talking past people and not addressing concerns with this "fix". We understand the feature is being misused, and we understand the need to remove it. Our issue is that our use cases are not being addressed or just being passed over as not important. This fix is being championed and rammed through by one particular developer who seems to be experiencing lots of issues with their mesh network while many other users aren't experiencing this.

from firmware.

These are all RAK solar nodes with an external Bluetooth antenna. We do have to go on site but we can reach the Bluetooth from the bottom of the tower instead of climbing.

Its pretty trivial to use the admin channel to switch the node to client mode, do your DFU update over BT, and switch the node back to router. At least that's what I do every time. Sometimes I do client_mute just so I can have less traffic going through it to do post upgrade validation messaging to other nodes.

And not every mountain top node has to be a router either. I have 4 mountain nodes going at the moment. Each one of those 4 has LOS to 3 of the others. 3 look over the same 100+ km swath of the horizon but each covers vastly different areas of flatland. Only 2 of those are routers due to locations above urban centers. The other 2 are set to client and just for coverage infill. One of those 2 client mode node's main purpose is just to link an isolated valley that gets partial coverage from the 2 router nodes. The other's job is to provide coverage infill within an urban area from the opposite direction as the router for that urban area.

Thank you to the devs for spearheading this necessary change. I only wish there were a way to compel the existing router_client users to upgrade. Based on the responses here they will hold on to this mode for dear life by running old firmware.

from firmware.

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.

from firmware.

2. The documentation isn't clear on how to achieve what is currently a ROUTER_CLIENT node in an advantageous position, but also has wifi used for it to send the packets it hears to MQTT and be polled for device stats over tcp.

Router and repeater are meant for LoRa infrastructure, the blended ROUTER_CLIENT that has been almost entirely misused is being removed intentionally without a direct replacement as it is bad for the mesh. The blended role is the issue, so a new blended role is not being added back.

from firmware.

I think this should have been held off for the 3.0 release when all the other breaking changes are made. No reason to update and lose this feature now.

from firmware.

They have legitimate concerns but have been dismissed and ridiculed by some devs who have become a little too big for their britches. They would be well served to tread lightly here.

Who has been ridiculed here? We have gone out of our way to give transitional direction for folks wanting to make their infrastructural nodes with API connections continue to behave as they do in Router Client with the Router proper role. If the guidance is followed, no one should experience any changes of behavior in those installations.

Sometimes we have to make difficult decisions based on the data we have. This one kept coming up. It became clear that users have not understand the role and have been misusing to the harm of public meshes. I genuinely believe it will be a positive change that isn't deserving of the drama this thread has generated.

from firmware.

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 ?

from firmware.

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

from firmware.

I'm sorry guys I didn't elaborate more on my use case, but it is pretty similar with Petr.

I do understand why is wrong having so many ROUTER_CLIENTS in mesh and there is no doubt many of them misconfigured, but that doesn't mean there are some good use cases to have this hybrid setup.

I have Heltec_V3 on tower behind Raspberry PI with PoE HAT. With ROUTER_CLIENT, I can see how I'm doeing without any other device needed (and I dont want another device for that). There are sometimes some issues with radio goeing blind for day or two, which is really odd and troubleshooting is one of these use cases. So it's great to have router and client as well and monitor this device. I need to know if everything is great.

Also when I had just ROUTER, it doesn't work at all for reason I don't know (reboot, firmware update or change of TX power didn't helped back then) . My node was not discovered and did not passed traffic. When I switched to ROUTER_CLIENT, it started all working well.

It's also fun to have opportunity to check radio statistics directly, otherwise I loose my interest.

All that said, I do understand your concerns and intentions, but I believe we have some good reasons too why ROUTER_CLIENT is nice thing to have.

Thank you for your work.

from firmware.

I think this should have been held off for the 3.0 release when all the other breaking changes are made. No reason to update and lose this feature now.

It is universally being selfishly misused and affecting other mesh users, this needs to happen now and is not a breaking change.

from firmware.

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.

from firmware.

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.

from firmware.

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.

from firmware.

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 ?

from firmware.

Do we have an issue open to update the documentation yet, or has someone already taken responsibility for that?

I've got a draft ready for when the next release with this update is put out. I'll get an issue put in for it now.

from firmware.

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."

from firmware.

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).

from firmware.

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?

from firmware.

These are all RAK solar nodes with an external Bluetooth antenna. We do have to go on site but we can reach the Bluetooth from the bottom of the tower instead of climbing.

only small detail... I am not sure if on bluetooth is legal to use external antennas.

from firmware.

@petrkr what hardware is running on your current infrastructure nodes?

Do not know, what other using, but I have ESP32 with LAN8720 ethernet powered by PoE on 670m hill on 43m height observatory, where if you want to go, you need climb environment... Really do not want switch this node to CLIENT just because of missing ROUTER_CLIENT mode. And in CLIENT mode this node is pointless to be there. So if there is NO solution to keep it ROUTER and keep it accessible from network. Then I have 2 solutions

1. stuck on latest FW where ROUTER_CLIENT still is
2. take that node down, because in ROUTER I can not monitor it and in CLIENT mode is useless there and it is not worth to pay for it there.

from firmware.

Totally agree, but I do still insist that this should be handled in greater version number to be more clear about bigger change that break things (surely will break for me :)).

from firmware.

Well, I can't wait to see the improvements then. Hopefully they will be noticable.

Maybe you should mention that change in the patch notes and put a link to the great deal of transition guidance.

from firmware.

I continue to see no valid use cases that this change has made impossible.

Except people who need to update firmware over Bluetooth for actual routers, that need to be Router, on top of towers, instead of climbing the tower. That has not been addressed at all and it is not an edge case by any stretch.

We have provided a great deal transition guidance

Where is the transition guidance for this? Were just SOL and gotta climb the tower for every firmware update?

Why not just let BLE still work on the device and disable messaging?

from firmware.

They have legitimate concerns but have been dismissed and ridiculed by some devs who have become a little too big for their britches. They would be well served to tread lightly here.

Pretty ironic statement given your comment. From what I've observed, no one has been dismissed or ridiculed. Mostly folks not happy that the response isn't aligned with what their personal desires are. If you look closely, you'll notice several responses providing alternatives and guidance on best practices moving forward after this change. I would say this demonstrates a commitment to addressing concerns and helping users adapt -- quite the opposite of what you claiming.

The admins and devs have a responsibility to consider what's best for the wider community, which sometimes means making decisions that may not cater to every specific edge case. While it's natural to disagree with plans that don't align with individual needs, dismissing the expertise of those working to improve the network for everyone can be counterproductive. Such dismissal risks alienating the very people dedicated to the community's growth and improvement. This could potentially be more detrimental than an update some users disagree with.

from firmware.

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.

from firmware.

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.

from firmware.

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

from firmware.

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.

from firmware.

We mostly wanted to ability to update firmware via bluetooth instead of climbing the tower. There was also the issue where the nodes became unresponsive after a period of time with the roles where bluetooth is disabled (perhaps this has been fixed now though)

from firmware.

I totally get the need for this change though. We have 20+ nodes here in router or router_client. Just hoping it's possible to accomplish this while retaining the ability to update firmware via Bluetooth :-)

from firmware.

We mostly wanted to ability to update firmware via bluetooth instead of climbing the tower. There was also the issue where the nodes became unresponsive after a period of time with the roles where bluetooth is disabled (perhaps this has been fixed now though)

This concern is legitimate on ESP32 based routers, but BLE remains on for NRF52 unless explicitly disabled in the config. So for your RAKs being upgraded, you should remain up and running. Having said that, I always recommend experimenting with separate devices while on the ground. 😅

from firmware.

Have the same use-case as @TheCommsChannel -- use bluetooth to perform firmware updates for nodes up a mast.

from firmware.

I totally get the need for this change though. We have 20+ nodes here in router or router_client. Just hoping it's possible to accomplish this while retaining the ability to update firmware via Bluetooth :-)

I'm in a similar position. Multiple RAK solar nodes deployed in strategic advantageous positions using router_client mode so that firmware updates can be done without donning climbing gear.

from firmware.

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).

The blended role which also is a client has been totally misused, the client being available is the issue being fixed here.

Well.

So what is right solution to gather metadata from Router mode node by using Python API over TCP then?

To get this list https://mesh.petrkr.net/info.html

I will NOT try now router mode, because I will be soon 9000km far away from roof and I really can not switch it back, if TCP API will stop work in router mode

from firmware.

This is a really bad idea, we do use ROUTER_CLIENT intentionaly to also have opportunity to read statistics with CLI on our router node :/ And almost half of 90 nodes that we see is also ROUTER_CLIENT:
https://mesh.tricker.cz/

from firmware.

This is a really bad idea, we do use ROUTER_CLIENT intentionaly to also have opportunity to read statistics with CLI on our router node :/ And almost half of 90 nodes that we see is also ROUTER_CLIENT: https://mesh.tricker.cz/

Having 45 Router Clients in your mesh is a really bad idea, and this is exactly why we're removing it.

Well, nice to know that..

Still no one from you provided solution how to make it ROUTER and still be able to GET data from API to make those list / maps available. And NO CLIENT is NOT right solution for that.

Also you still did not answer to others, HOW they will update their nodes on 40m height observatory by using BLE so they do not need to climb there with Serial port if they will be in ROUTER mode.

All of that is addressed above. The blended roles are the issue, a router should do Lora routing not 5 different functions while on a tower.

from firmware.

Well. I wanted try how it will be in ROUTER mode... So I switch one my personal node to test and now... WiFi connected, after 4 pings disconnected..

So I wanted try serial port connection and that also does not works... So HOW I will return it back to CLIENT ? Some other way than total erase and reflash ?

from firmware.

2. The documentation isn't clear on how to achieve what is currently a ROUTER_CLIENT node in an advantageous position, but also has wifi used for it to send the packets it hears to MQTT and be polled for device stats over tcp.

Router and repeater are meant for LoRa infrastructure, the blended ROUTER_CLIENT that has been almost entirely misused is being removed intentionally without a direct replacement as it is bad for the mesh. The blended role is the issue, so a new blended role is not being added back.

A bit difficult for me to parse your reply, but it seems that your position is that an infrastructure node should not send RX'd packets to MQTT then?

from firmware.

@GUVWAF addressed this nicely here, so for device which should indeed be ROUTER there should be a way how to not put API in sleep and be able to monitor it via CLI:
#4227 (comment)

from firmware.

Seems like the devs keep talking past people and not addressing concerns with this "fix". We understand the feature is being misused, and we understand the need to remove it. Our issue is that our use cases are not being addressed or just being passed over as not important. This fix is being championed and rammed through by one particular developer who seems to be experiencing lots of issues with their mesh network while many other users aren't experiencing this.

I have been pretty clear as to the why here this has absolute nothing to do with a personal network. Removing code is tricky this thread validates that there are only a few edge cases here with hundreds of thousands of users. The code is merged, it needs to go as it is impacting network performance substantially. I continue to see no valid use cases that this change has made impossible.

from firmware.

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

from firmware.

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

from firmware.

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

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

from firmware.

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

from firmware.

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

from firmware.

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.

from firmware.

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.

from firmware.

These are all RAK solar nodes with an external Bluetooth antenna. We do have to go on site but we can reach the Bluetooth from the bottom of the tower instead of climbing.

from firmware.

All of the RAKs have an IPEX connector and the included BLE antenna is what I'm referring to when I say external antenna. This is why we went with the RAKs vs other options.

from firmware.

All of the RAKs have an IPEX connector and the included BLE antenna is what I'm referring to when I say external antenna. This is why we went with the RAKs vs other options.

when I hear "external antenna" Then I assume someone put there 24dBi yagi or something. Not stock 2dBi which is on all APs. But maybe better to "chat" somewhere else than here. Is there any channel, where we can discuss ?

from firmware.

I'm on discord

from firmware.

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?

I think for your infrastructural RAK nodes, a switch to ROUTER should be pretty seamless unless I'm missing something. Is there something specific to ROUTER_CLIENT that made you choose that role?

from firmware.

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).

The blended role which also is a client has been totally misused, the client being available is the issue being fixed here.

from firmware.

Thinking about this some....

There's not really anything stopping people from using a T-Echo or something indoors and putting a node on the roof of their house that they set to Router role as a way to get out.

I wonder if having something like a nodeID list of the nodes in the area that should actually be routers that your node will prefer to route to. This way we more control over things.

from firmware.

Ah, good to know. I remembered seeing that at some point but wasn't sure if that was changed.

No worries, all experimenting will be done on the ground. I'm scared of heights and can't wait to get down whenever I'm up there 😆

from firmware.

Ah, good to know. I remembered seeing that at some point but wasn't sure if that was changed.

No worries, all experimenting will be done on the ground. I'm scared of heights and can't wait to get down whenever I'm up there 😆

Hit me up on discord if anything acts strangely. I want to make sure Router is a solid transition choice for those nodes that really need it to be.

from firmware.

Also you could just use the admin channel to switch your router to client, perform the firmware update, then switch it back to router if this was ever an issue.

from firmware.

This is a really bad idea, we do use ROUTER_CLIENT intentionaly to also have opportunity to read statistics with CLI on our router node :/ And almost half of 90 nodes that we see is also ROUTER_CLIENT: https://mesh.tricker.cz/

Having 45 Router Clients in your mesh is a really bad idea, and this is exactly why we're removing it.

from firmware.

This is a really bad idea, we do use ROUTER_CLIENT intentionaly to also have opportunity to read statistics with CLI on our router node :/ And almost half of 90 nodes that we see is also ROUTER_CLIENT: https://mesh.tricker.cz/

This is a perfect example of why this is being removed, your mesh should never be half infrastructure.

from firmware.

This is a really bad idea, we do use ROUTER_CLIENT intentionaly to also have opportunity to read statistics with CLI on our router node :/ And almost half of 90 nodes that we see is also ROUTER_CLIENT: https://mesh.tricker.cz/

Having 45 Router Clients in your mesh is a really bad idea, and this is exactly why we're removing it.

Well, nice to know that..

Still no one from you provided solution how to make it ROUTER and still be able to GET data from API to make those list / maps available. And NO CLIENT is NOT right solution for that.

Also you still did not answer to others, HOW they will update their nodes on 40m height observatory by using BLE so they do not need to climb there with Serial port if they will be in ROUTER mode.

from firmware.

@petrkr what hardware is running on your current infrastructure nodes?

from firmware.

And NO CLIENT is NOT right solution for that.

How is that not a solution? Leave the router to do its job, and use a client device to do the stat work. I don't understand why you feel it needs to be a router doing this.

from firmware.

And NO CLIENT is NOT right solution for that.

How is that not a solution? Leave the router to do its job, and use a client device to do the stat work. I don't understand why you feel it needs to be a router doing this.

but it is NOT CLIENT !! When you will finally understand that ?

it is ROUTER and API is used just to read status from it and monitor it by systems like zabbix. How I can monitor ROUTER node if API is disabled ?! It is like you will say all ISP should switch their routers to CLIENT mode in order to be able to use SNMP for monitoring... Totally pointless.

So HOW we can monitor ROUTER nodes by zabbix and making MAP what THAT router hear (not client somewhere else, but THAT exact ROUTER).

Please give solution for this problem.

from firmware.

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.

1. Curious your thoughts on a balloon nodes optimal device modes?

2. The documentation isn't clear on how to achieve what is currently a ROUTER_CLIENT node in an advantageous position, but also has wifi used for it to send the packets it hears to MQTT and be polled for device stats over tcp.

from firmware.

For preventing premature sleeping in Router mode in ESP32 devices, have you tried maxing out power.wait_bluetooth_secs and display.screen_on_secs?

from firmware.

Do we have an issue open to update the documentation yet, or has someone already taken responsibility for that?

from firmware.

Definitively yes, this is a big breaking change for somebody who needs working API, which is not available when in router mode, to address issues I mentioned few hours ago.

from firmware.

@garthvh I'm really sorry, but removing device role which is widely used is a huge breaking change. Yes, this is exactly why are you doeing this, I get it, but it totally breaks not only my monitoring use case. And as I mentioned few posts back when I elaborated on why this sucks, ROUTER was acting weidly.

Is there option to have ROUTER with API? Becasuse in ROUTER mode, serial only working few seconds after reboot.

from firmware.

@garthvh I'm really sorry, but removing device role which is widely used is a huge breaking change. Yes, this is exactly why are you doeing this, I get it, but it totally breaks not only my monitoring use case. And as I mentioned few posts back when I elaborated on why this sucks, ROUTER was acting weidly.

Is there option to have ROUTER with API? Becasuse in ROUTER mode, serial only working few seconds after reboot.

Your mesh is half routers, clearly this can't be managed by users. If there are bugs we need to address those, the blended router client will role is a mistake we made that needs to be corrected. Meshtastic has grown 10x in a year we can't just leave feature like this that are only negative for the mesh in place.

from firmware.

Seems like the devs keep talking past people and not addressing concerns with this "fix". We understand the feature is being misused, and we understand the need to remove it. Our issue is that our use cases are not being addressed or just being passed over as not important.

We have provided a great deal transition guidance (also see intervals in #4227 because this same configuration will work for your use case) and additionally have personally worked with users on the discord to ensure that for the ROUTER role, things continue to work as billed for their use cases.

This fix is being championed and rammed through by one particular developer who seems to be experiencing lots of issues with their mesh network while many other users aren't experiencing this.

You might not even be aware of the impact this could be having on your own mesh, as it can result in completely dropped packets you would be unaware of, if the density of routers grows large enough. And by the way, they don't have to be on the same mesh even, just the same frequency slot and preset.

from firmware.

I continue to see no valid use cases that this change has made impossible.

Except people who need to update firmware over Bluetooth for actual routers, that need to be Router, on top of towers, instead of climbing the tower. That has not been addressed at all and it is not an edge case by any stretch.

We have provided a great deal transition guidance

Where is the transition guidance for this? Were just SOL and gotta climb the tower for every firmware update?

Why not just let BLE still work on the device and disable messaging?

Always coming in hot... The answers to all your questions are both in this issue and on #4227

from firmware.

I continue to see no valid use cases that this change has made impossible.

Except people who need to update firmware over Bluetooth for actual routers, that need to be Router, on top of towers, instead of climbing the tower. That has not been addressed at all and it is not an edge case by any stretch.

We have provided a great deal transition guidance

Where is the transition guidance for this? Were just SOL and gotta climb the tower for every firmware update?

Why not just let BLE still work on the device and disable messaging?

Please read the thread, it has all the information.

from firmware.

Would it make sense to eventually have a separate firmware for the Router/Repeater roles? Maybe removing the possibility of selecting those roles out of curiosity and ease of access would be for the better.

from firmware.

What will happen here and make more sense, is those who have a legitimate reason to keep the router/client role will keep it and not update the firmware. Many router/clients are not updated for years and this will be a legitimate course of action for those to keep the router/client role as it works better for them in their specific area with their specific terrain. This one size fits all shotgun approach is a bad idea as expressed by several in these comments. They have legitimate concerns but have been dismissed and ridiculed by some devs who have become a little too big for their britches. They would be well served to tread lightly here.

from firmware.