mudhorn/meshtastic
1
0
Fork 0
mirror of https://github.com/meshtastic/meshtastic.git synced 2024-12-28 06:59:45 -08:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Merge branch 'meshtastic:master' into add-nano-g2

Browse source
This commit is contained in:
rcarteraz 2023-08-27 10:01:32 -07:00 committed by GitHub
parent 51603190c1 566fc3816a
commit cb948f1b4c
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
12 changed files with 140 additions and 80 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
docs/about/overview/mesh-alg.mdx
View file

@ -36,7 +36,8 @@ This layer is conventional non-reliable LoRa packet transmission. A packet gener
| 0x08 | 4 bytes | Integer | Packet Header: The sending node's unique packet ID for this packet. |
| 0x0C | 1 byte | Bits | Packet Header: Flags. See the [header flags](#packet-header-flags) for usage. |
| 0x0D | 1 byte | Bits | Packet Header: Channel hash. Used as hint for decryption for the receiver. |
| 0x0E | Max. 237 bytes (excl. protobuf overhead) | Bytes | Actual packet data. Unused bytes are not transmitted. |
| 0x0E | 2 bytes | Bytes | Packet Header: Padding for memory alignment. |
| 0x10 | Max. 237 bytes (excl. protobuf overhead) | Bytes | Actual packet data. Unused bytes are not transmitted. |
#### Packet Header Flags

2
docs/configuration/device-config/index.mdx
View file

@ -17,5 +17,5 @@ There are several config sections in the Meshtastic firmware, these are broken o
| [LoRa](/docs/settings/config/lora) | The LoRa config options are: Region, Modem Preset, Max Hops, Transmit Power, Bandwidth, Spread Factor, Coding Rate, Frequency Offset, Transmit Disabled and Ignore Incoming Array. |
| [Network](/docs/settings/config/network) | Network config options are: WiFi Enabled, WiFi SSID, WiFi PSK, WiFi Mode and NTP Server. |
| [Position](/docs/settings/config/position) | Position config options are: GPS Enabled, GPS Update Interval, GPS Attempt Time, Fixed Position, Smart Broadcast, Broadcast Interval and Position Packet Flags. |
| [Power](/docs/settings/config/power) | Power config options are: Charge Current, Power Saving, Shutdown after losing power, ADC Multiplier Override Wait Bluetooth Interval, Mesh Super Deep Sleep Timeout, Super Deep Sleep Interval, Light Sleep Interval and Minimum Wake Interval. |
| [Power](/docs/settings/config/power) | Power config options are: Charge Current, Power Saving, Shutdown after losing power, ADC Multiplier Override Wait Bluetooth Interval, Light Sleep Interval and Minimum Wake Interval. |
| [User](/docs/settings/config/user) | The user config options are: Long Name, Short Name, and Is Licensed |

32
docs/configuration/device-config/power.mdx
View file

@ -13,10 +13,10 @@ import calculateADC from "/src/utils/calculateADC";
Power settings are advanced configuration, most users should choose a role under [Device Config](/docs/settings/config/device) to manage power for their device and shouldn't ever need to adjust these settings.
:::
The power config options are: Power Saving, Shutdown after losing power, ADC Multiplier Override, Wait Bluetooth Interval, Mesh Super Deep Sleep Timeout, Super Deep Sleep Interval, Light Sleep Interval, Minimum Wake Interval, and Device Battery INA2xx Address. Power config uses an admin message sending a `Config.Power` protobuf.
The power config options are: Power Saving, Shutdown after losing power, ADC Multiplier Override, Wait Bluetooth Interval, Light Sleep Interval, Minimum Wake Interval, and Device Battery INA2xx Address. Power config uses an admin message sending a `Config.Power` protobuf.
:::info
ADC Multiplier, Super Deep Sleep, and Light Sleep settings only apply to ESP32-based boards. These settings will have no effect on nRF52 modules.
ADC Multiplier, The Light Sleep setting only applies to ESP32-based boards. This settings will have no effect on nRF52 modules.
:::
## Power Config Values
@ -95,20 +95,6 @@ How long to wait before turning off BLE in no Bluetooth states
`0` for default of 1 minute
### Mesh Super Deep Sleep Timeout
While in Light Sleep if this value is exceeded we will lower into super deep sleep
or Super Deep Sleep Interval (default 1 year) or a button press
`0` for default of two hours, MAXUINT for disabled
### Super Deep Sleep Interval
While in Light Sleep if Mesh Super Deep Sleep Timeout Seconds is exceeded we will lower into super deep sleep or this value (default 1 year) or a button press
`0` for default of one year
### Light Sleep Interval
In light sleep the CPU is suspended, LoRa radio is on, BLE is off and GPS is on
@ -174,8 +160,6 @@ All Power config options are available in the python CLI.
| power.on_battery_shutdown_after_secs | `integer` (seconds) | Default of `0` is off |
| power.adc_multiplier_override | `2-4` (floating point value) | Default of `0` uses firmware values |
| power.wait_bluetooth_secs | `integer` (seconds) | Default of `0` is 1 minute |
| power.mesh_sds_timeout_secs | `integer` (seconds) | Default of `0` is 2 hours |
| power.sds_secs | `integer` (seconds) | Default of `0` is 1 year |
| power.ls_secs | `integer` (seconds) | Default of `0` is 5 minutes |
| power.min_wake_secs | `integer` (seconds) | Default of `0` is 10 seconds |
| power.device_battery_ina_address | `integer` (I2C address as decimal) | Default of `0` is no address set |
@ -205,18 +189,6 @@ meshtastic --set power.wait_bluetooth_secs 0
meshtastic --set power.wait_bluetooth_secs 120
```
```shell title="Set Mesh Super Deep Sleep Timeout (Default of 0 is 2 hours/7200 seconds)"
meshtastic --set power.mesh_sds_timeout_secs 0
meshtastic --set power.mesh_sds_timeout_secs 120
// Disable using MAXUINT
meshtastic --set power.mesh_sds_timeout_secs 4294967295
```
```shell title="Set Super Deep Sleep (Default of 0 is 1 year)"
meshtastic --set power.sds_secs 0
meshtastic --set power.sds_secs 120
```
```shell title="Set Light Sleep to default (Default of 0 is 5 minutes)"
meshtastic --set power.ls_secs 0
meshtastic --set power.ls_secs 120

1
docs/configuration/module-config/index.mdx
View file

@ -14,6 +14,7 @@ Modules are included in the firmware and allow users to extend the functionality
| [Canned Message](/docs/settings/moduleconfig/canned-message) | Set a number of predefined messages to send out directly from the device with the use of an input device like a rotary encoder. |
| [External Notification](/docs/settings/moduleconfig/external-notification) | Incoming messages are able to alert you using circuits you attach to the device (LEDs, Buzzers, etc). |
| [MQTT](/docs/settings/moduleconfig/mqtt) | Forward packets along to an MQTT server. This allows users on the local mesh to communicate with users on another mesh over the internet. |
| [Neighbor Info](/docs/settings/moduleconfig/neighbor-info) | Send info on 0-hop neighbors to the mesh. |
| [Range Test](/docs/settings/moduleconfig/range-test) | Send messages with GPS location at an interval to test the distance your devices can communicate. Requires (at least) one device set up as a sender and one as a receiver. The receiver(s) will log all incoming messages to a CSV. |
| [Serial Module](/docs/settings/moduleconfig/serial) | Send messages across the mesh by sending strings over a serial port. |
| [Store & Forward](/docs/settings/moduleconfig/store-and-forward-module) | Stores messages on a device for delivery after disconnected clients rejoin the mesh. |

83
docs/configuration/module-config/neighbor-info.mdx Normal file
View file

@ -0,0 +1,83 @@
---
id: neighbor-info
title: Neighbor Info Module Usage
slug: /settings/moduleconfig/neighbor-info
sidebar_label: Neighbor Info
---
import Tabs from "@theme/Tabs";
import TabItem from "@theme/TabItem";
The Neighbor Info Module is for sending information on each node's 0-hop neighbors to the mesh. Config options are: Enabled and Update Interval.
In order to use it, make sure your devices use firmware version 2.2.0 or higher.
## Neighbor Info Module Config Values
### Enabled
Enables the Neighbor Info Module.
### Update Interval
How often the neighbor info is sent to the mesh.
## Neighbor Info Module Client Availability
<Tabs
groupId="settings"
defaultValue="cli"
values={[
{label: 'Android', value: 'android'},
{label: 'Apple', value: 'apple'},
{label: 'CLI', value: 'cli'},
{label: 'Web', value: 'web'},
]}>
<TabItem value="android">
:::info
All Neighbor Info Module config options are available for Android in app version 2.2.0 and higher.
1. Open the Meshtastic App
2. Navigate to: **Vertical Ellipsis (3 dots top right) > Radio Configuration > Neighbor Info**
:::
</TabItem>
<TabItem value="apple">
Not yet implemented.
</TabItem>
<TabItem value="cli">
:::info
All Neighbor Info Module config options are available in the python CLI version 2.2.0 and higher.
:::
Example commands are below:
```shell title="Enable/Disable the Neighbor Info Module"
meshtastic --set neighbor_info.enabled true
meshtastic --set neighbor_info.enabled false
```
```shell title="Set the update interval to 10 minutes"
meshtastic --set neighbor_info.update_interval 600
```
```shell title="Get the Neighbor Info Module Configuration"
meshtastic --get neighbor_info
```
</TabItem>
<TabItem value="web">
Not yet implemented.
</TabItem>
</Tabs>

38
docs/development/device/client-api.mdx
View file

@ -18,14 +18,14 @@ This protocol is **almost** identical when it is deployed over BLE, Serial/USB,
- The stream going towards the radio is only a series of ToRadio packets (with the extra 4 byte headers)
- The stream going towards the PC is a stream of FromRadio packets (with the 4 byte headers), or if the receiver state machine does not see valid header bytes it can (optionally) print those bytes as the debug console from the radio. This allows the device to emit regular serial debugging messages (which can be understood by a terminal program) but also switch to a more structured set of protobufs once it sees that the PC client has sent a protobuf towards it.
The 4 byte header is constructed to both provide framing and to not look line 'normal' 7 bit ASCII.
The 4 byte header is constructed to both provide framing and to not look like 'normal' 7 bit ASCII.
- Byte 0: START1 (0x94)
- Byte 1: START2 (0xc3)
- Byte 2: MSB of protobuf length
- Byte 3: LSB of protobuf length
The receiver will validate length and if >512 it will assume the packet is corrupted and return to looking for START1. While looking for START1 any other characters are printed as "debug output". For small example implementation of this reader see the python implementation.
The receiver will validate length and if >512 it will assume the packet is corrupted and return to looking for START1. While looking for START1 any other characters are printed as "debug output". For a small example implementation of this reader see the python implementation.
## Bluetooth (MeshBluetoothService)
@ -35,8 +35,8 @@ For a reference implementation of a client that uses this service see [RadioInte
Typical flow when a phone connects to the device should be the following (if you want to watch this flow from the python app just run `meshtastic --debug --info` - the flow over BLE is identical):
- There are only three relevant endpoints (and they have built in BLE documentation - so use a BLE tool of your choice to watch them): FromRadio, FromNum (sends notifies when new data is available in FromRadio) and ToRadio
- SetMTU size to 512
- There are only three relevant endpoints (and they have built in BLE documentation - so use a BLE tool of your choice to watch them): FromRadio, FromNum (sends notifies when new data is available in FromRadio) and ToRadio.
- SetMTU size to 512.
- Write a ToRadio.startConfig protobuf to the "ToRadio" endpoint - this tells the radio you are a new connection and you need the entire NodeDB sent down.
- Read repeatedly from the "FromRadio" endpoint. Each time you read you will get back a FromRadio protobuf (see Meshtastic-protobuf). Keep reading from this endpoint until you get back and empty buffer.
- See below for the expected sequence for your initial download.
@ -45,13 +45,13 @@ Typical flow when a phone connects to the device should be the following (if you
Expected sequence for initial download:
- After your send startConfig, you will receive a series of FromRadio packets. The sequence of these packets will be as follows (but you are best not counting on this, instead just update your model for whatever packet you receive - based on looking at the type)
- Read a RadioConfig from "radio" - used to get the channel and radio settings
- Read a User from "user" - to get the username for this node
- Read a MyNodeInfo from "mynode" to get information about this local device
- Read a series of NodeInfo packets to build the phone's copy of the current NodeDB for the mesh
- Read a endConfig packet that indicates that the entire state you need has been sent
- Read a series of MeshPackets until it returns empty to get any messages that arrived for this node while the phone was away
- After your send startConfig, you will receive a series of FromRadio packets. The sequence of these packets will be as follows (but you are best not counting on this, instead just update your model for whatever packet you receive - based on looking at the type).
- Read a RadioConfig from "radio" - used to get the channel and radio settings.
- Read a User from "user" - to get the username for this node.
- Read a MyNodeInfo from "mynode" to get information about this local device.
- Read a series of NodeInfo packets to build the phone's copy of the current NodeDB for the mesh.
- Read an endConfig packet that indicates the entire state you need has been sent.
- Read a series of MeshPackets until it returns empty to get any messages that arrived for this node while the phone was away.
For definitions (and documentation) on FromRadio, ToRadio, MyNodeInfo, NodeInfo and User protocol buffers see [mesh.proto](https://github.com/meshtastic/protobufs/blob/master/meshtastic/mesh.proto)
@ -86,12 +86,12 @@ Note: that if the phone ever sees this number decrease, it means the ESP32 has r
Re: Queue management,
not all messages are kept in the fromradio queue (filtered based on SubPacket):
- only the most recent Position and User messages for a particular node are kept
- all Data SubPackets are kept
- No WantNodeNum / DenyNodeNum messages are kept
- A variable keepAllPackets, if set to true will suppress this behavior and instead keep everything for forwarding to the phone (for debugging)
- Only the most recent Position and User messages for a particular node are kept.
- All Data SubPackets are kept.
- No WantNodeNum / DenyNodeNum messages are kept.
- A variable keepAllPackets, if set to true will suppress this behavior and instead keep everything for forwarding to the phone (for debugging).
### A note on MTU sizes
### A Note on MTU Sizes
This device will work with any MTU size, but it is highly recommended that you call your phone's "setMTU function to increase MTU to 512 bytes" as soon as you connect to a service. This will dramatically improve performance when reading/writing packets.
@ -99,7 +99,7 @@ This device will work with any MTU size, but it is highly recommended that you c
On connect, you should send a want_config_id protobuf to the device. This will cause the device to send its node DB and radio config via the fromradio endpoint. After sending the full DB, the radio will send a want_config_id to indicate it is done sending the configuration.
### Other Bluetooth services
### Other Bluetooth Services
This document focuses on the core device protocol, but it is worth noting that the following other Bluetooth services are also
provided by the device.
@ -125,8 +125,8 @@ Characteristics
#### DeviceInformationService
Implements the standard BLE contract for this service (has software version, hardware model, serial number, etc...)
Implements the standard BLE contract for this service (has software version, hardware model, serial number, etc...).
#### BatteryLevelService
Implements the standard BLE contract service, provides battery level in a way that most client devices should automatically understand (i.e. it should show in the Bluetooth devices screen automatically)
Implements the standard BLE contract service, provides battery level in a way that most client devices should automatically understand (i.e. it should show in the Bluetooth devices screen automatically).

10
docs/development/device/http-api.mdx
View file

@ -42,7 +42,7 @@ A `PUT` request to this endpoint will be expected to contain a series of ToRadio
The protobufs will be sent in binary as the body for the request.
For the initial implementation, only one ToRadio message per request is supported, but future optimizations to improve throughput might add support for multiple ToRadios in a single request.
Only one ToRadio message per request is supported.
#### OPTIONS
@ -76,9 +76,7 @@ The protobufs will be sent in binary as the body for the request.
## Authentication
The initial release will not have **any** user authentication. We assume access to the HTTP server is enough to establish trust.
Since authentication is also eventually needed for our other transports (TCP and eventually open BLE), we will be adding authentication **in-band**. When added in the second release there will be a new payload supported inside ToRadio for `SignIn <userid> <usersecret>`. The server will respond with a FromRadio `SignInResponse okay|fail`. Also, in the case of the REST API, that SignIn status will then be associated with the current session key. Most (all?) ToRadio packets will be ignored if the client is not signed in. Most (all?) FromRadio packets will be sent to clients that are not signed in.
There isn't **any** user authentication. We assume access to the HTTP server is enough to establish trust.
## Client
@ -90,7 +88,7 @@ A reference client written in JavaScript will provide a JavaScript API for using
### Protoman
See: [https://github.com/spluxx/Protoman]
See: https://github.com/spluxx/Protoman
Protoman is able to interface with the Meshtastic REST API out of the box. This is useful for manual testing of the endpoints.
@ -100,4 +98,4 @@ HTTP and HTTPS are both supported on the ESP32 using self signed certificates on
## Related documents
- Interesting slide pack on the concept: [https://www.slideshare.net/mokeefe/javaone-2009-ts5276-restful-protocol-buffers]
- Interesting slide pack on the concept: https://www.slideshare.net/mokeefe/javaone-2009-ts5276-restful-protocol-buffers

4
docs/legal/trademark-grants.mdx
View file

@ -23,6 +23,4 @@ sidebar_label: Trademark Grants
- Grant: [Keith Monaghan](http://voltaicenclosures.com/)
- Details: Keith is a contributer of computer aided design (CAD)/3D designs primarily for device enclosures and accessories, and runs an online shop for Meshtastic powered devices which carry the "Meshtastic" and "M" logos. The use of the Meshtastic Logo and Trademarks does not imply Keith is sponsored or endorsed by Meshtastic. Keith also agrees to maintain compliance with the Meshtastic Legal requirements. This grant is revokable at any time for any reason.
- Grant: [Neil Hao](https://shop.uniteng.com/)
- Details: Neil is a contributer of hardware designs, and runs an online shop for Meshtastic powered devices which carry the "Meshtastic" and "M" logos. The use of the Meshtastic Logo and Trademarks does not imply Neil is sponsored or endorsed by Meshtastic. Neil also agrees to maintain compliance with the Meshtastic Legal requirements. This grant is revokable at any time for any reason.
- Grant: (https://github.com/niccellular/Meshtastic-Plugin)
- Details: The Meshtastic-Plugin is an Android Tactical Assault Kit (ATAK) plugin that interacts with the Meshtastic Android App's IMeshService for sending/receving Cursor on Target (CoT) messages. The use of the Meshtastic Logo and Trademarks does not imply Meshtastic-Plugin is sponsored or endorsed by Meshtastic. Meshtastic-Plugin also agrees to maintain compliance with the Meshtastic Legal requirements. This grant is revokable at any time for any reason.
- Details: Neil is a contributer of hardware designs, and runs an online shop for Meshtastic powered devices which carry the "Meshtastic" and "M" logos. The use of the Meshtastic Logo and Trademarks does not imply Neil is sponsored or endorsed by Meshtastic. Neil also agrees to maintain compliance with the Meshtastic Legal requirements. This grant is revokable at any time for any reason.

2
docs/software/android/usage.mdx
View file

@ -152,6 +152,8 @@ The Map tab will show a local map with an icon for each active mesh node that ha
- Clicking the layers icon in the top-right will allow you to select the map type.
### Offline maps
[![Download offline maps](/img/android/android-map-download-c.png)](/img/android/android-map-download.png)
- Some map types allow downloading for offline use. If offline maps are available for your selected map type, a download icon will appear in the bottom-right corner of the map. Tap this icon and choose the option to Download Region, then select the area you wish to download.

1
docs/software/community/index.mdx
View file

@ -11,5 +11,6 @@ Current community projects:
- [ATAK (Android Team Awareness Kit) Forwarder](/docs/software/community/community-atak) - An ATAK plugin for forwarding CoT messages via a hardware layer which supports Meshtastic devices.
- [Meshtasticator (Simulator)](/docs/software/community/community-meshtasticator) - Meshtasticator is a discrete-event and interactive simulator that mimics the radio section of the device software.
- [Meshtastic Web API](/docs/software/community/meshtastic-web-api) - Meshtastic Web API provides a RESTful interface to interact with a Meshtastic node via a serial connection.
Support for these projects should be sought from their respective authors.

33
docs/software/mqtt/index.mdx
View file

@ -9,28 +9,28 @@ sidebar_position: 6
Meshtastic networks in different locations beyond the reach of LoRa can be easily bridged together using MQTT. The simplest option is to connect your mesh to the official Meshtastic MQTT broker. This makes your devices appear on the world map, and provides a copy of your mesh traffic, translated into JSON. All you have to do to join the public MQTT server is to Enable MQTT and set Uplink and Downlink on the channels that you want to share over MQTT. The default device configuration using the public MQTT Server is encrypted.
You can also share channel settings with a remote network. If you use the default meshtastic MQTT server, packets are always encrypted. If you use a custom MQTT broker (ie set `mqtt.address`), the `mqtt.encryption_enabled` setting applies, which by default is false. You can also specify your own private MQTT broker and specify authentication for that broker to bridge several mesh networks together, via the internet (or just a local IP network).
You can also share channel settings with a remote network. If you use the default Meshtastic MQTT server, packets are always encrypted. If you use a custom MQTT broker (ie set `mqtt.address`), the `mqtt.encryption_enabled` setting applies, which by default is false. You can also specify your own private MQTT broker and specify authentication for that broker to bridge several mesh networks together, via the internet (or just a local IP network).
You can find the settings available for MQTT [here](/docs/settings/moduleconfig/mqtt).
:::important
When MQTT is turned on, you are potentially broadcasting your entire mesh's traffic onto the public internet. This includes messages and position information.
:::
## Software Integrations
Using or emitting packets directly in/from smart home control software such as Home Assistant or other consumers that can work with JSON messages.
When MQTT is enabled, the Meshtastic device simply uplinks and/or downlinks every raw protobuf MeshPacket that it sees to the MQTT broker, encapsulated in a [ServiceEnvelope protobuf](https://buf.build/meshtastic/protobufs/docs/main:meshtastic#meshtastic.ServiceEnvelope). In addition, some packet types are serialized or deserialized from/to JSON messages for easier use in consumers. All packets are sent to the broker, whether they originate from another device on the mesh, or the gateway node itself.
Packets may be encrypted. If you use the default meshtastic MQTT server, packets are always encrypted. If you use a custom MQTT broker (ie set `mqtt.address`), the `mqtt.encryption_enabled` setting applies, which by default is false.
IMPORTANT: When MQTT is turned on, you are potentially broadcasting your entire mesh traffic onto the public internet. This includes messages and position information.
### MQTT [Topics](https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices)
If no specific [root topic](/docs/settings/moduleconfig/mqtt#root-topic) is configured, the default root topic will be `msh/`.
Each device that is connected to MQTT will publish its MQTT state ("`online`"/"`offline`") to:
Each device that is connected to MQTT will publish its MQTT state (`online`/`offline`) to:
`msh/2/stat/USERID`, where `USERID` is the user ID of the gateway device (the one connected to MQTT).
`msh/2/stat/USERID`, where `USERID` is the node ID of the gateway device (the one connected to MQTT).
For each channel where uplink and/or downlink is enabled two other topics might be used.
For each channel where uplink and/or downlink is enabled, two other topics might be used:
#### Protobufs topic
A gateway node will uplink and/or downlink raw ([protobuf](https://developers.google.com/protocol-buffers)) MeshPackets to the topic:
@ -50,7 +50,7 @@ The payload is a raw protobuf, whose definitions for Meshtastic can be found [he
If [encryption_enabled](/docs/settings/moduleconfig/mqtt#encryption-enabled) is set to true, the payload of the MeshPacket will remain encrypted with the key for the specified channel.
#### JSON topic
If [JSON is enabled](/docs/settings/moduleconfig/mqtt/#json-enabled), packets from the following [port numbers](/docs/development/firmware/portnum) are serialized to JSON: `TEXT_MESSAGE_APP`, `ENVIRONMENTAL_MEASUREMENT_APP`, `NODEINFO_APP` and `POSITION_APP`. These are then forwarded to the topic:
If [JSON is enabled](/docs/settings/moduleconfig/mqtt/#json-enabled), packets from the following [port numbers](/docs/development/firmware/portnum) are serialized to JSON: `TEXT_MESSAGE_APP`, `TELEMETRY_APP`, `NODEINFO_APP`, `POSITION_APP` and `WAYPOINT_APP`. These are then forwarded to the topic:
`msh/2/json/CHANNELNAME/USERID`.
@ -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.
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.
@ -238,17 +238,12 @@ Below is a valid JSON envelope for information sent by MQTT to a device for broa
}
```
Node-RED is a free cross-platform programming tool for wiring together hardware, APIs, and online services developed originally by IBM for IOT. It is widely used for home automation by many non-professional programmers and runs well on Pi's. Node-red has many plug-in modules written by the community. I will use this platform as a practical example on how to interface with the MQTT features of Meshtastic. Everything can be done from GUI's without using command line.
Node-RED is a free cross-platform programming tool for wiring together hardware, APIs, and online services developed originally by IBM for IOT. It is widely used for home automation by many non-professional programmers and runs well on Pi's. Node-RED has many plug-in modules written by the community. I will use this platform as a practical example on how to interface with the MQTT features of Meshtastic. Everything can be done from GUI's without using command line.
Step one: use http://client.meshtastic.org/ one of the Apple apps or the CLI to connect to your device and adjust these settings.
Step one: use http://client.meshtastic.org/ , the python CLI, or an Apple or Android app to connect to your device and adjust these settings.
Enable and enter network SSID/PSK. Settings--> Device Config--> Network; Save.
Set MQTT server address. Settings--> Module Config--> MQTT config; Verify Encryption Enabled is OFF. Turn JSON Output Enabled ON. Save.
Go to Channel Editor and set Uplink and Downlink enabled to True. Save. There is currently a bug for setting Uplink and Downlink Saving for the default channel. If you encounter this use the CLI commands:
```shell
meshtastic --ch-index 0 --ch-set uplink_enabled true
meshtastic --ch-index 0 --ch-set downlink_enabled true
```
Go to Channel Editor and set Uplink and Downlink enabled to True. Save.
Step two: if you don't want to depend on JSON decoding on the device, you can decode the protobuf messages off-device. To do that you will need to get the .proto files from https://github.com/meshtastic/protobufs. They function as a schema and are required for decoding in Node-RED. Save the files where the node-RED application can access them and note the file path of the "mqtt.proto" file.

11
docs/software/python-cli/index.mdx
View file

@ -306,7 +306,16 @@ meshtastic --sendping
Traceroute from connected node to a destination. You need pass the destination ID as an argument. Only nodes that have the encryption key can be traced.
```shell title="Usage"
meshtastic --traceroute 'ba4bf9d0'
meshtastic --traceroute '!ba4bf9d0'
```
### --request-telemetry
Request telemetry from a node. You need to pass the destination ID as an argument with '--dest'. For repeaters, the nodeNum is required.
```shell title="Usage"
meshtastic --request-telemetry --dest '!ba4bf9d0'
meshtastic --request-telemetry --dest 1828779180
```
### --ack