[Feature Request]: MQTT Location only mode about firmware HOT 9 CLOSED

Sure, with info we got I could create something in Node-Red that only grabs my location and NodeInfo from a private MQTT server and publish this to a new topic....

But I see a lot of questions asking how to get on map(s), so this would help a lot in starting communities. Especially the ones with lower knowledge of the internal working of MQTT.

from firmware.

Chiming in only because I find this interesting. I don't see this feature as being practical, BUT I do see it as something lots of people have been asking for, and I'd prolly end up turning it on too. It would be an easier way to let everyone know you're around, without sharing your entire mesh online.

Perhaps a solution would be a new module/portnum that sends out a combination of Long/Short name + Position information. This portnum would NEVER TX over LoRa, only MQTT.

from firmware.

This is implemented with #3365 and will be in the upcoming 2.3.0 release. Please ask the maintainer of the map you're using to incorporate the new MapReport packet on the /2/map/ topic which will contain all kinds of information about the node (also e.g. firmware version and number of active local nodes).

from firmware.

Just to be sure: you know you can already only enable uplink (and not downlink) in the channel settings to avoid transmitting packets from MQTT over LoRa while still publishing your position on the map?

I don't see why you need separate topics for position and telemetry to accomplish what you want.

from firmware.

Just to be sure: you know you can already only enable uplink (and not downlink) in the channel settings to avoid transmitting packets from MQTT over LoRa while still publishing your position on the map?

I don't see why you need separate topics for position and telemetry to accomplish what you want.

Sure I know, that is a full one way publish and means that everything from the mesh is published to the MQTT server too. Privacy wise you don't want this. You can't hide messages in your public primary channel. Sure you can create a "private" channel, but you want a public one too for people from outside your mesh.
Also when someone subscribes to that MQTT topic and uses up- and downlink, messages can't ever reach the nodes via the node that has only uplink enabled. With a location only mode, you protect the expectation of reaching nodes that can't be reached. And with a separate topic, you protect the mesh from flooding too.

from firmware.

You can't hide messages in your public primary channel. Sure you can create a "private" channel, but you want a public one too for people from outside your mesh.

You can create a private primary channel to publish your position and not use it for anything else and have the "public" channel as secondary.
If you want to talk in the clear over LoRa on the primary channel but not publish it to MQTT, while still publishing your location, it sounds like a solution would be to allow periodic position publishing to MQTT on a different channel than the primary.

If you have a separate topic for position only, maps will not be able to show a short and long name, because they need the NodeInfo packets for that. So what you’re asking for is to have switches to select which kind of traffic (by port number) to publish to a dedicated MQTT topic (always unencrypted then?), without nodes subscribing to these topics. This is different from selecting to publish/subscribe to all traffic per channel and would require issue #3116 to be implemented first.

from firmware.

If you have a separate topic for position only, maps will not be able to show a short and long name, because they need the NodeInfo packets for that.

Sure, if that is needed too then NodeInfo should also be published in the same topic.

This could go hand in hand with issue #3116, but needs an approach to make it easier for new users. So an out of the box approach or single click would help.

from firmware.

A self-contained “Map Report” packet that only gets published to MQTT makes sense, but like @nukemrules said, it should be simple to use. If you also want things like Device and/or Environment metrics as previously mentioned (or Traceroute, NeighborInfo, DetectionSensor, etc. for that matter), then in my opinion you should just use uplink on the primary channel for that.

It would be good to know what people want to see on the map apart from short/long name and position? meshmap.net also shows the role and hardware type (from NodeInfo). Region, frequency slot and modem preset is useful for knowing how to reach a node over LoRa. Maybe also a boolean for if it uses a channel with the default encryption key and name.
Furthermore, you probably also want to configure the new position precision and send it with the packet such that the map can display the precision.

from firmware.

We are already using a country topic for MQTT for South Africa as msh/ZA and that is working well to filter more for local users, and still uploads our location to the map. So anyone can already choose their own topic.

from firmware.