[Feature Request]: meshtastic mqtt server discovery defined in protocol and useable by clients..

[oiaohm]

Multicast DNS(mdns) is first that comes to mind. Going this path we need service name defined for the meshtastic mqtt server. so the service can be advertised.

Another option would the custom dhcp option entries of course this need some from of standard naming.

Think be able to connect to a wifi access point use the mdns or dhcp get list local lan meshtastic mqtt servers. Yes these are local lan mqtt servers that may have a local lora device connected..

https://github.com/pdxlocations/MQTT-Connect-for-Meshtastic

Yes I saw the picture on this page and my first though was why can not the phone connect to the wifi access point and stay meshtatic lora connected as long as a meshtastic lora interface is connected to the access point. Followed by what is missing todo this simple for end users? What is missing to make this simple for end users is lack of means for the software todo discovery and provide information of what local mqtt are around. Also it appears the software you cannot set more than one mqtt..

This also comes out from me hearing issues with meshtastic lora having too many devices in a small area. A local meshtastic mqtt on a openwrt router keep track of what devices are connected to the wifi and allowing those devices to go broadcast silent on lora would free up lora bandwidth. Basically take the picture on the above page but have the phone connecting to the wifi router and basically switching the bluetooth connected to phone meshtastic lora node into silent running mode but still able to receive messages sent to its identity because it connected to the local MQTT.

Yes adding the mdns option and a meshtastic MQTT server to the phone applications would possible allow meshtastic application to be operating inside public wifi with one phone operating as the local MQTT.

[oiaohm]

I have looked more detailed into options todo this. I did incorrectly presume that I had not press commit on this discussion but since I did I very sorry causing a duplication.. When I opened it this was a issue of course so that where I went looking for it.

After more thought on the topic this most likely owns in protobufs as a define on how the protocol says it discoverability should be done. Because this is information need by more people than those just working on firmware. Anyone making a meshtastic compatible client application or setting up a masochistic discoverable

Following is from the
meshtastic/protobufs#639 that I created presuming this one did not exist because this one was meant to be a draft that I had not pressed commit on. That is a more detail write up on the options after more thought.

Mosquitto does not built in discovery there are different options.

Option 1) "bootp dhcp"
https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml
224-254 Reserved (Private Use) could be used right away with dhcp to broadcast where the local meshtastic MQTT is. Of course application to iana for a assigned number for meshstatic usage with dhcp/bootp would be the recommend long term route.

Option 2) mdns/avahi/zeroconf
arendst/Tasmota#11403
Yes this does note some problems.

Mosquitto MQTT server on %h _mqtt._tcp 1883 info=Publish, Publish! Read all about it! mqtt.org

Yes you can make up a generic make mosquitto MQTT visible on mdns. But I have no where in the meshtastic documentation how this should look on mdns if this MQTT server for meshtastic clients to use.

As the Tasmota issue notes some firmware have trouble doing mdns/avahi. But still project does not have a define way it should advertise meshtastic local servers by mdns/avahi/zeroconf

Option 3) Custom local DNS record/records.
this is a lot like the mdns record.

Lot of people are not aware we could create domain name meshtastic.local with TXT records only containing client configuration information just like option2/mdns txt-record line you are allowed more line of this.

Yes both option 2 and option 3 we do not have what before the = for the txt-record/TXT to use these effectively.

txt-record or TXT have the same format. "what this is"="the data"
Yes protocol could define like that
meshtastic-domainname= in TXT is the domainname of the meshtastic MQTT server.
meshtastic-ipv4=is the ipv4 of the meshtastic MQTT
meshtastic-port= the port the server is on.
There could be been radio configuration.

Yes there is no documentation on how to setup meshtatic MQTT on DNS so that you can find by DNS.

Part of making this meshtastic MQTT discoverable can be making meshtatic configuration for a event discoverable by connecting to a local wifi access point to reduce issues caused by devices not all being on the same page. This could make bootstrapping/configuring many new meshtatic devices simple as connect authorized local wifi network that provides the configuration.