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

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.

docs/software/integrations/mqtt/index.mdx

@@ -87,14 +87,14 @@ The meaning of these fields is as follows:
 
 - "`id`" is the unique ID for this message. 
 - "`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.
-- "`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. 
+- "`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 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.
 - "`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.
-- "`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.
-- "`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.
 
 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
-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
 {
-   "from": <node number of MQTT node>,
-   "to": <node number of recipient for a DM (optional)>,
+   "from": <decimal Node ID of MQTT node>,
+   "to": <decimal Node ID of recipient for a DM (optional)>,
    "channel": <channel index (optional)>,
    "type": "type",
    "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"`.
 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).