MQTT and JSON topic

Where I can find a script or solution for generating a plain-text JSON topic on our private MQTT server?

Any suggestion on how to use this? As I understand it’s a python module?

the instructions on the mqtt docs page should get you started. Its a standalone script that runs on its own, you just need to change some of the hardcoded parameters (that docs page says how).

Sure, but it’s hardcoded to use tracckr app. It’s a nice example of how to export nodes positions to tracckar server. But not clear how to use it like it’s used on the “official” MQTT server - decode position and message protobufs and send it to JSON topic.

This is a different script to the one on the official mqtt server. I couldnt find that one anywhere so wrote my own. Can you give me an example of the json you want out of it? Text message support is on my list to add, it’d be easy as to make it spit out position data as json too.

You can disable the traccar stuff by setting traccarHost = ""

It’s decoding only lat/lon, not text messages =(

I’ll add text message support hopefully in the next few days. A few people have been asking for it


I don’t really understand why this is not built in in Meshtastic. The MQTT integration feature is pretty much useless without this.

1 Like

To date most people working on MQTT have been focused on sensors, if you have a messaging use case pull requests are welcome!

my meshtastic-mqtt script supports text messages now, so you can get the plain text data out of your mesh that way

1 Like

@joshpirihi I know, but having an external tool postprocess MQTT messages to just decode the protobufs seems to be overshooting for me. Also, running this with AppDaemon on Home Assistant is somehow not stable for me. Looks like it just stops working after some reconnects.

1 Like

First attempt, don’t kill me :slight_smile:

1 Like

Followup PR that adds full JSON encoding/decoding support for uplink and downlink. It works, but I need some review if I did the radio sending correctly and did not miss some memory leaks. Any help/review appreciated.


We’ve had two reasons, the first is that by sticking with the protobufs, we don’t have to maintain the translation layer between protobufs and json as things change. In your draft PR, you only selected a small handful of the data available which I suppose is ok. We’ll need to figure out volunteers for when requests for changes in the area come up.

Second reason was size required by the inclusion of a json parser. You’ve picked a very lean library and that’s appreciated.

Over all, you’ve done great! Thanks for your contribution!

1 Like

Here you can see my modified version from the original.
Many parameters of the portnum: POSITION_APP, TEXT_MESSAGE_APP and NODEINFO_APP are decoded and republished.