mudhorn/meshtastic
1
0
Fork 0
mirror of https://github.com/meshtastic/meshtastic.git synced 2024-12-25 21:54:20 -08:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Clarify the necessity and configuration of the "mqtt" Meshtastic channel

Browse source 
My MQTT wasn't working at all (nothing published to msh/US/2/# except msh/US/2/stat/!myradio = offline for a week) until on advice from Discord I added a new Meshtastic channel to my radio configuration called "mqtt". They claim that this paragraph makes that requirement clear, but

1. This paragraph is only about JSON downlink to send MQTT over LoRa, which is odd because MQTT uplink didn't work either, but anyway:
2. The word "channel" by itself isn't a full set of instructions for creating a new Meshtastic channel on the appropriate node. The rest of the paragraph talks about the /mqtt/ topic, which is ambiguous.
This commit is contained in:
zyphlar 2024-06-29 13:19:12 -07:00 committed by Will Bradley
parent a3a9992022
commit 3aea1283d5
No known key found for this signature in database
GPG key ID: 1159B930701263F3
1 changed files with 14 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

22
docs/software/integrations/mqtt/index.mdx
View file

@ -87,14 +87,14 @@ The meaning of these fields is as follows:
- "`id`" is the unique ID for this message. - "`id`" is the unique ID for this message.
- "`channel`" is the channel index this message was received on. - "`channel`" is the channel index this message was received on.
- "`from`" is the unique node number of the node on the mesh that sent this message. - "`from`" is the unique decimal-equivalent Node ID of the node on the mesh that sent this message. (The hexadecimal value `7efeee00` represented by an integer in decimal is `2130636288`).
- "`id`" inside the payload of a `NODEINFO_APP` message is the user ID of the node that sent it, which is currently just the hexadecimal representation of the node number. - "`id`" inside the payload of a `NODEINFO_APP` message is the hexadecimal Node ID (sometimes called User ID) of the node that sent it.
- "`hardware`" is the [hardware model](https://github.com/meshtastic/protobufs/blob/master/meshtastic/mesh.proto#L215) of the node sending the `NODEINFO_APP` message. - "`hardware`" is the [hardware model](https://github.com/meshtastic/protobufs/blob/master/meshtastic/mesh.proto#L215) of the node sending the `NODEINFO_APP` message.
- "`longname`" is the long name of the device that sent the `NODEINFO_APP` message. - "`longname`" is the long name of the device that sent the `NODEINFO_APP` message.
- "`shortname`" is the short name of the device that sent the `NODEINFO_APP` message. - "`shortname`" is the short name of the device that sent the `NODEINFO_APP` message.
- "`sender`" is the user ID of the gateway device, which is in this case the same node that sent the `NODEINFO_APP` message (the hexadecimal value `7efeee00` represented by an integer in decimal is `2130636288`). - "`sender`" is the hexadecimal Node ID of the gateway device, which is in this case the same node that sent the `NODEINFO_APP` message.
- "`timestamp`" is the Unix Epoch when the message was received, represented as an integer in decimal. - "`timestamp`" is the Unix Epoch when the message was received, represented as an integer in decimal.
- "`to`" is the node number of the destination of the message. In this case, "-1" means it was a broadcast message (this is the decimal integer representation of `0xFFFFFFFF`). - "`to`" is the decimal-equivalent Node ID of the destination of the message. In this case, "-1" means it was a broadcast message (this is the decimal integer representation of `0xFFFFFFFF`).
- "`type`" is the type of the message, in this case it was a `NODEINFO_APP` message. - "`type`" is the type of the message, in this case it was a `NODEINFO_APP` message.
The `from` field can thus be used as a stable identifier for a specific node. Note that in firmware prior to 2.2.0, this is a signed value in JSON, while in firmware 2.2.0 and higher, the JSON values are unsigned. The `from` field can thus be used as a stable identifier for a specific node. Note that in firmware prior to 2.2.0, this is a signed value in JSON, while in firmware 2.2.0 and higher, the JSON values are unsigned.
@ -103,12 +103,18 @@ If the message received contains valid JSON in the payload, the JSON is deserial
#### JSON downlink to instruct a node to send a message #### JSON downlink to instruct a node to send a message
You can also send a JSON message to the topic `msh/2/json/mqtt/` to instruct a gateway node to send a message to the mesh. Note that the channel you publish it on **must** be called "mqtt". The JSON message should contain the following fields: You can also send a JSON message to the topic `msh/2/json/mqtt/` to instruct a gateway node to send a message to the mesh.
To make this work, ensure that your node has a Meshtastic channel configured called "mqtt". Enable Downlink. The PSK can be random and doesn't matter. This channel allows the node to listen to messages on the `msh/2/json/mqtt/` topic.
Reboot your device after creating this channel.
The JSON message should contain the following fields:
```json ```json
{ {
"from": <node number of MQTT node>, "from": <decimal Node ID of MQTT node>,
"to": <node number of recipient for a DM (optional)>, "to": <decimal Node ID of recipient for a DM (optional)>,
"channel": <channel index (optional)>, "channel": <channel index (optional)>,
"type": "type", "type": "type",
"payload": { "payload": {
@ -118,7 +124,7 @@ You can also send a JSON message to the topic `msh/2/json/mqtt/` to instruct a g
} }
``` ```
`from` and `payload` fields are required for a valid envelope (note that in firmware &lt;2.2.20 a field `sender` was required, but this is no longer the case). The `from` field should be equal to the node number of the node that will transmit the message. Optionally, you can specify a different channel than the primary channel by setting the `channel` field to a channel index (0-7). Furthermore, you can send a direct message by setting the `to` field to the node number of the destination. If the `to` field is not set, the message will be broadcast to all nodes on the mesh. `from` and `payload` fields are required for a valid envelope (note that in firmware &lt;2.2.20 a field `sender` was required, but this is no longer the case). The `from` field should be equal to the decimal Node ID of the node that will transmit the message. If the Node ID (sometimes called User ID) is !7efeee00, then the decimal equivalent would be 2130636288. Optionally, you can specify a different channel than the primary channel by setting the `channel` field to a channel index (0-7). Furthermore, you can send a direct message by setting the `to` field to the decimal Node ID of the destination. If the `to` field is not set, the message will be broadcast to all nodes on the mesh.
Currently two types of messages are supported: `"sendtext"` and `"sendposition"`. Currently two types of messages are supported: `"sendtext"` and `"sendposition"`.
For the type `sendtext`, the `payload` should be a string containing the text to send. For the type `sendposition`, the payload should be an object with the fields `latitude_i`, `longitude_i`, `altitude` (optional) and `time` (optional). For the type `sendtext`, the `payload` should be a string containing the text to send. For the type `sendposition`, the payload should be an object with the fields `latitude_i`, `longitude_i`, `altitude` (optional) and `time` (optional).