Location from other nodes misattributed via MQTT?

Support
1

What I’m trying to do: get all nodes to report location, have one node post all node location to MQTT.

I currently have 1 node (TTGO T-BEAM, id abf849b0) connected to Wi-Fi, configured as a client. I have MQTT enabled, and all sorts of messages appear to show up successfully. I have set it to provide its location every 15 minutes. This appears to work exactly as expected.

I have a second node with no Wi-Fi configured as client 71aca98a. It is set to “Provide location to mesh”, broadcasting its position (with smart position disabled) every 60 seconds.

I have a 3rd node that’s just hanging out connected to the computer, no GPS enabled.

In MQTT I’m seeing messages that look like this every ~60 seconds (redacted GPS co-ordinates):

msh/2/json/LongFast/!abf849b0 {"channel":0,"from":1907141002,"id":2009570779,"payload":{"latitude_i":450000000,"longitude_i":-750000000,"time":1690154742},"sender":"!abf849b0","timestamp":1690154768,"to":-1,"type":"position"}
msh/2/json/LongFast/!abf849b0 {"channel":0,"from":1907141002,"id":2009570781,"payload":{"latitude_i":450000000,"longitude_i":-750000000,"time":1690154803},"sender":"!abf849b0","timestamp":1690154829,"to":-1,"type":"position"}
msh/2/json/LongFast/!abf849b0 {"channel":0,"from":1907141002,"id":2009570777,"payload":{"latitude_i":450000000,"longitude_i":-750000000,"time":1690154681},"sender":"!abf849b0","timestamp":1690154708,"to":-1,"type":"position"}
msh/2/json/LongFast/!abf849b0 {"channel":0,"from":1907141002,"id":2009570783,"payload":{"latitude_i":450000000,"longitude_i":-750000000,"time":1690154864},"sender":"!abf849b0","timestamp":1690154889,"to":-1,"type":"position"}

These are ostensibly what I’d expect to see from the other node (71aca98a), but nothing identifies them as such. Am I missing something obvious here either configuration or functionality wise? It looks like the position broadcasts are being forwarded appropriately, but not attributed correctly?

Everything is running 2.1.17.7ca2e81

2

Comparing the output of meshtastic --info, it seems like maybe I’ve missed that “from” is a value that identifies the originating node. It lines up with the “num” value of 71aca98a.

In the Meshtastic world, given an output that looks like:

  "!71aca98a": {
    "num": 1907141002,
    ...

Looking at the protobuf, it seems like 1907141002 is the “sending node number” and the "!71aca98a" is the “userid”?

In what contexts do these values change? Are they equivalent? If I’m looking to uniquely identify a node in a programmatic sense, should I prefer one over the other?

3

The last part of the MQTT topic is the user ID of the node connected to MQTT, but it forwards all the messages it gets from nodes on the mesh with the channel you configured with uplink enabled.

Indeed in your case 1907141002 is the sending node number and !71aca98a is the user ID. Right now the user ID is just a hexadecimal representation (0x71aca98a = 1907141002) of the node number, so they are essentially identical. If in the future multiple ‘users’ per node are possible, this might change. So currently it doesn’t matter which one you pick to uniquely identify a node, but the node number might be the best choice.

I see why this is confusing, I think this from field should be explained somewhere in the documentation. The id field you see is the unique ID of a message. Edit: I just submitted a PR to the documentation to explain these fields.

1 Like
4

Interesting. I guess that all makes sense. I’m also getting some messages that look like this:

msh/2/json/LongFast/!abf849b0 {"channel":0,"from":-1409791568,"id":1739261803,"payload":{"altitude":91,"latitude_i":450000000,"longitude_i":-750000000,"time":1690233450},"sender":"!abf849b0","timestamp":1690233470,"to":-1,"type":"position"}

i.e. the “from” is a negative number (-1409791568). Is that… expected? My mesh consists of 3 nodes with the following “num” values:

  • 546312913
  • 2885175728
  • 1907141002

I’m noticing that the first node is an order of magnitude smaller, but none of them are negative. Potentially this is a bug?

5

Yes, it’s kind of a bug indeed. In the firmware this is an unsigned integer, but it arrives as signed integer, so that negative number is actually 2885175728.

Will probably be fixed when there is a major firmware release, as fixing it would be a breaking change for people depending on it.

6

fixing it would be a breaking change for people depending on it

:scream:

In the firmware this is an unsigned integer, but it arrives as signed integer

From what I’m seeing locally, it looks like the bug only impacts the JSON? The protobuf declaration here declares it as a fixed32. That’s good news (for me at least).

7

Yes, it goes wrong in the conversion to JSON.