reword for flow and timelessness

This commit is contained in:
pdxlocations 2023-08-14 09:54:38 -07:00
parent aec8a986c1
commit 2b7b1042d6

View file

@ -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.