From 2b7b1042d675d7fce830576f560b0a53dec4a157 Mon Sep 17 00:00:00 2001 From: pdxlocations Date: Mon, 14 Aug 2023 09:54:38 -0700 Subject: [PATCH] reword for flow and timelessness --- docs/software/mqtt/index.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/software/mqtt/index.mdx b/docs/software/mqtt/index.mdx index d7997568..4919b9df 100644 --- a/docs/software/mqtt/index.mdx +++ b/docs/software/mqtt/index.mdx @@ -78,7 +78,7 @@ 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, represented as a signed decimal number. +- "`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. - "`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. @@ -88,7 +88,7 @@ The meaning of these fields is as follows: - "`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`). - "`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 (like the "`id`" and "`to`" fields) in JSON this is a signed value, whereas in protobufs it is unsigned. In firmware >=2.2.0 the JSON values are properly using unsigned values. +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. If the message received contains valid JSON in the payload, the JSON is deserialized and added as a JSON object rather than a string containing the serialized JSON.