scruplelesswizard
commented
4 days ago Hi @kallisti5!
Thanks for your feature request. I think there may be a few changes that are impacting you regarding MQTT, depending on your version.
Allow receiving and forwarding messages (and telematics) to MQTT via ethernet / wifi.
MQTT is supported in all roles, including router. Nodes that want their packets forwarded to MQTT will need to enable Ok to MQTT in LoRa Config, and the gateway node will need to have Uplink and/or Downlink enabled on the channels you want to use with MQTT in addition to the MQTT configuration for your MQTT server
Allow bluetooth management of nodes in a router role (optional.. I know of the "admin network", just don't know how to use it)
There are significant changes in 2.5 to remote adminstration that make it more secure and easier to use. Once this feature and the documentation are updated I highly recommend leveraging it for nodes without a Bluetooth connection.
That said, nodes using the router role are still available via BLE when they aren't sleeping, and for the first 30 seconds after a reboot 1. See https://meshtastic.org/docs/configuration/radio/power/#power-saving for more details
Block sending local messages from router nodes.
Can you say more about why one might want to ignore packets from other routers?
Platform
Cross-Platform
Description
So, I have a node in one of those "ideal locations" (height is pretty close to highest point for 30+ miles, tips of mountains are competing.) The area doesn't have cell coverage, but I do have Starlink to forward local chatter to MQTT.
As a user, with the removal of router_client, I lost the following key features I used a lot:
Proposal:
If I understand the reasons for router_client getting removed, wouldn't the proposal above address the concerns most folks have in threads like #4185 (people running router_client, and getting rapid network priority over client nodes), while enabling use of critical features important to people with "nodes in ideal locations"