Monitoring Meshtastic channel via API?

Support
1

I’d like to monitor a Meshtastic channel via a terminal window on my Mac, or by streaming the channel to a log file.

Has anyone written this code, or have another means of doing this? MeshWatch would do it but is no longer supported, unfortunately.

Thanks
-David

1 Like
2

Have you considered using MQTT?
https://meshtastic.org/docs/software/mqtt/
I haven’t done it on a Mac, but the software is out there if you look for it, with moar than one option to get it working on a Mac.
You could also get an inexpensive single board computer and run the MQTT broker on it instead of your Mac.
There is also the option of running it via Docker, using the official Docker image from Eclipse.
Once you have the broker running somewhere, you’d just need to setup your Meshtastic device to publish to it and monitor the broker using client software of some sort on your Mac.

3

Greetings,

I am running a Mosquitto MQTT server on the Mac. I can publish messages to it from the Mac and from an IOS app running on the same network.

I configured a T-Beam running 2.1.21 to connect to the same network. I can ping the T-Beam on that network.

I configured the T-Beam’s MQTT server with the same information I used for the IOS application.

I enabled Upload/Download on the primary channel.

All three T-Beam’s can exchange messages, including the one set up for MQTT. No messages are published to the MQTT server.

I’ve tried this with json turned on and with it turned off in the module.

No joy.

-David

4

Are you pushing it to the MQTT broker via the server’s DNS hostname? Have you tried using the broker’s IP address? What role is it configured to use? Is it set to obtain a network address using DHCP?

5

I’m looking for similar functionality, but I’d like to better understand the mechanics of routing so I’m looking for low-level radio packets, as in all ALL packets received by or sent from a node. I’ve tried both mqtt and the python cli but neither gives me a full picture. Is there any tool or setting that will enable these low-level packet details to be obtained, or is scraping from serial debug logs the only option available atm?

6

Greetings,

I forgot to update this thread. The MQTT app I was using, Mosquitto, wasn’t displaying messages even though it was subscribed to the channel. I used MQTTAnalyzer on my iPhone and was able to debug the issue.

7

I suspect I will need similar functionality at some point. I’ve not found anything close yet.

8

It’s not the main purpose of MMRelay (Github repo link), but you can view the raw packets in a terminal with the debug plugin.

2023-09-23 08:32:36 -0500 DEBUG:Plugin:debug:Packet received: {'from': 862627113, 'to': 4294967295, 'decoded': {'portnum': 'TELEMETRY_APP', 'payload': b'\r\xf4\xe8\x0ee\x12\x0c\x08c\x15\x1dZ\x84@%:m\xb0>', 'telemetry': {'time': 1695475956, 'deviceMetrics': {'batteryLevel': 99, 'voltage': 4.136, 'airUtilTx': 0.34458333}}}, 'id': 1835699875, 'rxTime': 1695475956, 'hopLimit': 3, 'priority': 'MIN', 'fromId': '!336aa529', 'toId': '^all'}
2023-09-23 08:32:52 -0500 INFO:Meshtastic:Processing inbound radio message from !315501e4 on channel 3
2023-09-23 08:32:53 -0500 DEBUG:Plugin:debug:Packet received: {'from': 827654628, 'to': 4294967295, 'channel': 3, 'decoded': {'portnum': 'TEXT_MESSAGE_APP', 'payload': b'Testing debug plugin', 'text': 'Testing debug plugin'}, 'id': 954031765, 'rxTime': 1695475972, 'rxSnr': 8.75, 'hopLimit': 3, 'rxRssi': -96, 'fromId': '!315501e4', 'toId': '^all'}

While the app uses the meshtastic python API there are errors that are produced that can be ignored, but you’ll be able to see full packets and you can save the output to a file.

More about MMRelay in the Discourse post:

9

I’ve played with the Python API and haven’t yet found a way to get ALL packets including retransmissions and other packets that might not otherwise make it to applications. Is this the kind of low-level stream MMRelay is receiving, or is it the processed/filtered stream?

10

Ah, yeah. I see that in your post now. if you’ve explored the Python API already, you might not get much more out of this. It relies on the API for all communication with the device and it processes any packets that it sends us.

I don’t remember ever seeing re-transmissions either.

11

Internal packet handling like retransmissions and rebroadcasts are not exposed to any API, so you’d indeed have to manually scrape the serial logs to check what the device is doing.

If you’re only interested in the working of the protocol (not real-life data of your own mesh), you could have a look at the interactive simulator that displays how packets are propagated over the mesh. Benefit of this is that you can see it of all the nodes in a mesh, not just of one node you are connected to.

1 Like