Here is a newb MQTT tutorial for 1.3

I just started with meshtastic and spend days trying to get MQTT JSON to work to get at sent messages because I have a lot of automations with node-red. It currently doesn’t work ( . I thought I would post my intermim solution using the parts of MQTT that do work for other newbs out there.

First, set up unencrypted mqtt. You can use while connected to, for instance, a t-beam with a usb cable if you like working by GUI. Settings->Device Config ->Network=> set the network ssid/psk. Settings-> Module Config-> MQTT config-> set mqtt server adress. Verify on this page that the Encryption Enabled option is off so unencrypted protobufs will be sent. If you wish, on Channel Editor you can set uplink and downlink enabled to true.

Second, get the .proto files to a directory where node-red can get at them. Get them from GitHub - meshtastic/Meshtastic-protobufs: Protobuf definitions for the Meshtastic project
you will need the file path to mqtt.proto to stick into the node-red protobuf decode node.

Third, you will need the node-red nodes installed for an embedded mqqt server and protobuf decoding: node-red-contrib-aedes (node) - Node-RED
node-red-contrib-protobuf (node) - Node-RED

Set it up like this:

Stick your own channel name and topic into the mqtt node. If you don’t know it, it will show up on the Broker Publish Events.

This is where the proto-file goes. My Proto File name path is on a Windows machine, BTW.

This function node extracts the text of the message from the packet and sends it as a payload to the debug node.

The sent message will come out as a string payload to the debug node. Hope this helps.


Meshtastic MQTT JSON now works on tbeam on the latest master !!! (probably not heltec)
That would mean v1.3.46 or later.

I tested both upload and download using nod-red native aedes broker setup as I described above. The test setup looks like this.

1 Like

@gparduino this is really good information! We’d love it if you could contribute some of this into our official docs if you’re up to.


I would be happy to. Give me a couple days to figure out how to do that.

1 Like

Draft one in pull request.


Currently, MQTT JSON output on the POSITION_APP portnum is not working yet. If anyone needs to decode latitude and longitude from MQQT protobuf output here is an example on how to do it. Took me awhile to figure out because base64 is the only way I could get the bytes from being corrupted in this process.


It appears that altitude is encoded differently from Lat Lon. Added code to extract that here fro those who need it for node-red.

As of firmware 1.3.48. The inject message node in the prior test image will not work properly without modification. There is a change in what a valid JSON envelope will be accepted by the device for broadcast on the mesh. It looks like:
“sender”: “whatever you need here”,
“type”: “sendtext”,
“payload”: “whatever you want sent onto the mesh”
The “type”:“sendtext” is new.

Bridging a network is easy for messages


As is mapping and geofencing.

Version 2.0 Position.
JSON for this is broken, so here is the best way I’ve found of off-device decoding of the cleartext mqtt for message and position in node-red. BTW hub-and spoke positional map plotting of multipel mesh devices is not going to work because MQTT re-envelopes the position packet with the gatewayID of the mqtt connected device only. This will be a problem with bridging message and position packets. Message can be fixed with altering the code by putting the sending device in the message.


Update flow which plots all the devices in range the mqtt gateway meshtastic device without relying on the json position messages which still are buggy.


1 Like

OK, I just wanted to ENCODE a Position and send it via MQTT envelope to some devices to broadcast using standard node-red nodes.

OMG, trying to do this almost drove me nuts and took some hours. There is some crazy stuff when it comes to trying to use node-red (which runs on node.js) and the deeply nested meshtastic protobufs which include “bytes” fields.

The key things I learned are commented in the code, but include: sending JSON intended for encoding to a protobuf bytes field is best done by sending a base64 string, ENUMS are decoded as corresponding strings but encoded as numbers by the node-red nodes, note the difference in the Position message names (latitude_i, longitude_i) in the protobuf and the names really required for encoding (latitudeI, longitudeI). I’m beginning to hate this cross language nesting protobuf stuff. is a useful online tool when nothing makes sense.



Oops, ,forgot someone might want to populate the timestamp in the Position file.
Meshtastic seems to use UNIX time which is the integer portion of javascript time divided by 1000.



JSON output of Position_APP portnum should work now on the device 12/1/2022 in Version > 2.0.7. I tested on T-beam with GPS enabled. This should make things simpler.

1 Like

Confirmed that TEXTP_MESSAGE_APP, TELEMETRY_APP, NODEINFO_APP, POSITION_APP all work with JSON encoding on device with latest update.

1 Like

Submitted some firmware code in pull request and new documentation that will allow JSON sending of Position data from MQTT broker to Device to LORA mesh. Test of my compiled code and node-red. There is a new MQTT envelope type: “sendposition”.


I use this flow now for testing the cleartext messages.


Thank you so much for this, this is really excellent and far beyond what I could have cooked up! This is perfect for my use case, I am setting up a cloud instance of node red a base station to link my remote meshtastic network in an area with very limited lte network connection to the outside world.
Would you be able to share the json file or text file for this latest node red flow?