mudhorn/meshtastic
1
0
Fork 0
mirror of https://github.com/meshtastic/meshtastic.git synced 2025-02-02 08:42:11 -08:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge branch 'master' into mqtt-link

Browse source
This commit is contained in:
Ben Lipsey 2024-01-04 09:29:23 -08:00 committed by GitHub
parent 969d9d48fa 25a2535037
commit 7b1d64d161
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
22 changed files with 893 additions and 491 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
.github/workflows/ci.yml vendored
View file

@ -9,12 +9,12 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Checkout code & submodules
uses: actions/checkout@v3
uses: actions/checkout@v4
with:
submodules: true
- name: Setup pnpm
uses: pnpm/action-setup@v2.2.1
uses: pnpm/action-setup@v2
with:
version: latest

2
docs/about/contributing.mdx
View file

@ -29,7 +29,7 @@ Most communication and interactions happen with protocol buffers. The [Meshtasti
### Device Firmware
The [firmware repo](https://github.com/meshtastic/firmware) is where all of the device firmware development happens. This is where the code for the ESP32 and nRF52 based devices is developed. It is mainly C and C++ code. Think Arduino. It is where the first level of hardware interaction begins and ends.
The [firmware repo](https://github.com/meshtastic/firmware) is where all of the device firmware development happens. This is where the code for the ESP32, nRF52 and RP2040 based devices is developed. It is mainly C and C++ code. Think Arduino. It is where the first level of hardware interaction begins and ends.
### Firmware Modules

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

@ -17,6 +17,7 @@ Modules are included in the firmware and allow users to extend the functionality
| [External Notification](/docs/configuration/module/external-notification) | Incoming messages are able to alert you using circuits you attach to the device (LEDs, Buzzers, etc). |
| [MQTT](/docs/configuration/module/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/configuration/module/neighbor-info) | Send info on 0-hop neighbors to the mesh. |
| [Paxcounter](/docs/configuration/module/paxcounter) | Count the number of BLE and Wifi devices passing by a node. |
| [Range Test](/docs/configuration/module/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. |
| [Remote Hardware](/docs/configuration/module/remote-hardware) | Set and read a GPIO status remotely over the mesh. |
| [Serial Module](/docs/configuration/module/serial) | Send messages across the mesh by sending strings over a serial port. |

4
docs/configuration/module/mqtt.mdx
View file

@ -131,6 +131,10 @@ All MQTT module config options are available for the Web UI.
## Connect to the Default Public Server
:::important
The default channel (LongFast) on the public server usually has a lot of traffic. Your device may get overloaded and may no longer function properly anymore. It is recommended to use a different channel or to use your own MQTT server if you experience issues.
:::
<Tabs
defaultValue="apple"
values={[

80
docs/configuration/module/paxcounter.mdx Normal file
View file

@ -0,0 +1,80 @@
---
id: paxcounter
title: Paxcounter Module Usage
sidebar_label: Paxcounter
---
import Tabs from "@theme/Tabs";
import TabItem from "@theme/TabItem";
The Paxcounter module counts the number of people passing by a specific area. It is commonly used in retail stores, museums, and other public spaces to monitor foot traffic and gather valuable data for analysis.
In order to use this module, make sure your devices have firmware version 2.2.17 or higher.
## Paxcounter Module Config Values
### Enabled
Whether the Module is enabled.
### Update Interval
The interval in seconds of how often we can send a message to the mesh when a state change is detected.
## Paxcounter 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
No Paxcounter Module config options are available for Android.
:::
</TabItem>
<TabItem value="apple">
:::info
No Paxcounter Module config options are available on the iOS, iPadOS and macOS app.
:::
</TabItem>
<TabItem value="cli">
:::info
All Paxcounter Module config options are available in the python CLI version 2.2.16 and higher.
:::
Example commands are below:
```shell title="Enable/Disable the Paxcounter Module"
meshtastic --set paxcounter.enabled true
meshtastic --set paxcounter.enabled false
```
```shell title="Set the Minimum Broadcast Interval to 90 seconds"
meshtastic --set paxcounter.paxcounter_update_interval 900
```
```shell title="Get the Paxcounter Module Configuration"
meshtastic --get paxcounter
```
</TabItem>
<TabItem value="web">
:::info
No Paxcounter module config options are available in the Web UI.
:::
</TabItem>
</Tabs>

32
docs/configuration/radio/device.mdx
View file

@ -17,25 +17,29 @@ Sets the role of the node.
Acceptable values:
| Value | Description |
| :-------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |
| `CLIENT` | Client (default) - This role will follow the standard routing rules while also allowing the device to interact with client applications via BLE/Wi-Fi (Android/Apple/Web). |
| `CLIENT_MUTE` | Client Mute - Same as a client except packets will not hop over this node, does not contribute to routing packets for mesh. |
| `ROUTER` | Router - Mesh packets will prefer to be routed over this node. The assumption is that Router-type devices will be placed in locations with a height/range/antenna advantage, and therefore have better overall coverage. This node will not be used by client apps. The BLE/Wi-Fi radios and the OLED screen will be put to sleep. Please note: Due to the preferred routing, this role may cause higher power usage due to more frequent transmission. |
| `ROUTER_CLIENT` | Router Client - Hybrid of the Client and Router roles. Similar to Router, except the Router Client can be used as both a Router and an app connected Client. BLE/Wi-Fi and OLED screen will not be put to sleep. |
| `REPEATER` | Repeater - Mesh packets will prefer to be routed over this node. This role eliminates unnecessary overhead such as NodeInfo, DeviceTelemetry, and any other mesh packet, resulting in the device not appearing as part of the network. As such, direct messaging this node is not available, as it will not appear in your nodes list which results in a cleaner mesh network. Channel and modem settings of the mesh packets being repeated must be identical to the repeater's configuration. Please see Rebroadcast Mode for additional settings specific to this role. |
| `TRACKER` | Tracker - For use with devices intended as a GPS tracker. Position packets sent from this device will be higher priority. Smart Position Broadcast will default to the currently configured settings. When used in conjunction with power.is_power_saving = true, nodes will wake up, send position, and then sleep for position.position_broadcast_secs seconds. |
| `SENSOR` | Sensor - For use with devices intended to primarily collect sensor readings. Telemetry packets sent from this device will be higher priority, broadcasting every five minutes. When used in conjunction with power.is_power_saving = true, nodes will wake up, send environment telemetry, and then sleep for telemetry.environment_update_interval seconds. |
| Value | Description |
|:----------------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
| `CLIENT` | Client (default) - This role will follow the standard routing rules while also allowing the device to interact with client applications via BLE/Wi-Fi (Android/Apple/Web). |
| `CLIENT_MUTE` | Client Mute - Same as a client except packets will not hop over this node, does not contribute to routing packets for mesh. |
| `ROUTER` | Router - Mesh packets will prefer to be routed over this node. The assumption is that Router-type devices will be placed in locations with a height/range/antenna advantage, and therefore have better overall coverage. This node will not be used by client apps. The BLE/Wi-Fi radios and the OLED screen will be put to sleep. Please note: Due to the preferred routing, this role may cause higher power usage due to more frequent transmission. |
| `ROUTER_CLIENT` | Router Client - Hybrid of the Client and Router roles. Similar to Router, except the Router Client can be used as both a Router and an app connected Client. BLE/Wi-Fi and OLED screen will not be put to sleep. |
| `REPEATER` | Repeater - Mesh packets will prefer to be routed over this node. This role eliminates unnecessary overhead such as NodeInfo, DeviceTelemetry, and any other mesh packet, resulting in the device not appearing as part of the network. As such, direct messaging this node is not available, as it will not appear in your nodes list which results in a cleaner mesh network. Channel and modem settings of the mesh packets being repeated must be identical to the repeater's configuration. Please see Rebroadcast Mode for additional settings specific to this role. |
| `TRACKER` | Tracker - For use with devices intended as a GPS tracker. Position packets sent from this device will be higher priority. Smart Position Broadcast will default to the currently configured settings. When used in conjunction with power.is_power_saving = true, nodes will wake up, send position, and then sleep for position.position_broadcast_secs seconds. |
| `SENSOR` | Sensor - For use with devices intended to primarily collect sensor readings. Telemetry packets sent from this device will be higher priority, broadcasting every five minutes. When used in conjunction with power.is_power_saving = true, nodes will wake up, send environment telemetry, and then sleep for telemetry.environment_update_interval seconds. |
| `TAK` | TAK - Used for nodes dedicated for connection to an ATAK EUD. Turns off many of the routine broadcasts to favor CoT packet stream from the Meshtastic ATAK plugin -> IMeshService -> Node. |
| `CLIENT_HIDDEN` | Client Hidden - Used for nodes that "only speak when spoken to." Turns off all of the routine broadcasts but allows for ad-hoc communication. Still rebroadcasts, but with local only rebroadcast mode (known meshes only). Can be used for clandestine operation or to dramatically reduce airtime / power consumption |
| `LOST_AND_FOUND` | Lost and Found - Used to automatically send a text message to the mesh with the current position of the device on a frequent interval: "I'm lost! Position: lat / long" |
### Rebroadcast Mode
This setting defines the device's behavior for how messages are rebroadcasted.
| Value | Description |
| :-----------------: | :-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |
| `ALL` | ALL (Default) - This setting will rebroadcast ALL messages from its primary mesh as well as other meshes with the same modem settings, including when encryption settings differ. |
| `ALL_SKIP_DECODING` | ALL_SKIP_DECODING - Same as behavior as ALL, but skips packet decoding and simply rebroadcasts them. **Only available with Repeater role.** |
| `LOCAL_ONLY` | LOCAL_ONLY - Ignores observed messages from foreign meshes that are open or those which it cannot decrypt. Only rebroadcasts message on the nodes local primary / secondary channels. |
| Value | Description |
|:-------------------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
| `ALL` | ALL (Default) - This setting will rebroadcast ALL messages from its primary mesh as well as other meshes with the same modem settings, including when encryption settings differ. |
| `ALL_SKIP_DECODING` | ALL_SKIP_DECODING - Same as behavior as ALL, but skips packet decoding and simply rebroadcasts them. **Only available with Repeater role.** |
| `LOCAL_ONLY` | LOCAL_ONLY - Ignores observed messages from foreign meshes that are open or those which it cannot decrypt. Only rebroadcasts message on the nodes local primary / secondary channels. |
| `KNOWN_ONLY` | KNOWN_ONLY - Ignores observed messages from foreign meshes like LOCAL_ONLY, but takes it a step further by also ignoring messages from nodenums not in the node's known list (NodeDB). |
### Serial Console

2
docs/configuration/radio/power.mdx
View file

@ -15,7 +15,7 @@ Power settings are advanced configuration, most users should choose a role under
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, The Light Sleep setting only applies to ESP32-based boards. This 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/RP2040 modules.
:::
## Power Config Values

5
docs/configuration/tips.mdx
View file

@ -29,7 +29,7 @@ If you'd like to connect with other Meshtastic users but only share your locatio
1. Ensure you have not changed the LoRa [Modem Preset](/docs/configuration/radio/lora#modem-preset) from the default `unset` / `LONG_FAST`.
2. On your PRIMARY channel, set anything you'd like for the channel's name and choose a random PSK.
3. Enable a SECONDARY channel named "LongFast" with PSK "AQ==".
4. Since the radio's frequency is automatically changed based on your PRIMARY channel's name, you will have to manually set it back to your region's default (in LoRa settings) in order to interface with users on the default channel:
4. If your LoRa channel is set to the default (`0`), the radio's frequency will be automatically changed based on your PRIMARY channel's name. In this case, you will have to manually set it back to your region's default (in LoRa settings) in order to interface with users on the default channel:
### Default Primary Channels by Region
@ -65,4 +65,5 @@ This configures the frequency the radio is set to. Check out the [frequency cal
- If you are part of a large mesh and don't know what a setting does, don't change it (unless you're super curious).
- Leave your [MAX HOPS](/docs/configuration/radio/lora#max-hops) set to 3 unless you're sure you need more (or less) to reach your destination node.
- TEST your settings and hardware before you install in hard-to-reach locations.
- Connecting a node to the [public MQTT server](./module/mqtt#connect-to-the-default-public-server) may publish the locations of all nodes in your mesh to the internet. This will also add every globally connected node to your node database and potentially flood your mesh with all types of packets.
- Connecting a node to the [public MQTT server](./module/mqtt#connect-to-the-default-public-server) may publish the locations of all nodes in your mesh to the internet. This will also add every globally connected node to your node database and potentially flood your mesh with all types of packets.

2
docs/development/js/connecting.mdx
View file

@ -7,7 +7,7 @@ sidebar_label: Connecting
```tsx
import type React from "React";
import { IHTTPConnection } from "@meshtastic/meshtasticjs";
import { IHTTPConnection } from "@meshtastic/js";
export const Connection = (): JSX.Element => {
const connection = new IHTTPConnection();

2
docs/development/js/http-api.mdx
View file

@ -14,7 +14,7 @@ import {
Types,
Protobuf,
SettingsManager
} from "@meshtastic/meshtasticjs";
} from "@meshtastic/js";
/**
* Connection method

8
docs/getting-started/index.mdx
View file

@ -42,7 +42,7 @@ The nRF52 chip is much more power efficient than the ESP32 chip and easier to up
The RP2040 is a dual-core ARM chip developed by Raspberry Pi. Supported RP2040 devices include:
- Raspberry Pi Pico + Waveshare LoRa Module (Note: **Bluetooth and Wi-Fi on the Pico W is not yet supported by Meshtastic**)
- Raspberry Pi Pico + Waveshare LoRa Module (Note: **Bluetooth on the Pico W is not yet supported by Meshtastic**)
- RAK11310 Core module for RAK WisBlock modular boards
:::info
@ -67,7 +67,7 @@ Some cables only provide _charging_, verify that your cable is also capable of _
:::caution
nRF52 devices typically do not require serial drivers. They use the UF2 bootloader which makes the devices appear as flash drives. Do _NOT_ download the USB device drivers unless required to install UF2 support.
nRF52/RP2040 devices typically do not require serial drivers. They use the UF2 bootloader which makes the devices appear as flash drives. Do _NOT_ download the USB device drivers unless required to install UF2 support.
:::
@ -89,7 +89,7 @@ If you require serial drivers installed on your computer, please choose one of t
className={'button button--outline button--lg cta--button'}
to={'/docs/getting-started/serial-drivers/nrf52'}
>
Install NRF52 Drivers
Install nRF52/RP2040 Drivers
</Link>
</div>
</div>
@ -115,7 +115,7 @@ After completing the previous steps, you can now flash the Meshtastic firmware o
className={"button button--outline button--lg cta--button"}
to={"/docs/getting-started/flashing-firmware/nrf52/"}
>
Flash nRF52 Firmware
Flash nRF52/RP2040 Firmware
</Link>
</div>
</div>

10
docs/getting-started/serial-drivers/serial-drivers-nrf52.mdx
View file

@ -1,7 +1,7 @@
---
id: nrf52
title: nRF52 Serial Drivers
sidebar_label: nRF52 Drivers
title: nRF52/RP2040 Serial Drivers
sidebar_label: nRF52/RP2040 Drivers
sidebar_position: 2
---
@ -9,11 +9,11 @@ import Tabs from "@theme/Tabs";
import TabItem from "@theme/TabItem";
import Link from "@docusaurus/Link";
## Install nRF52 USB to Serial Drivers
## Install nRF52/RP2040 USB to Serial Drivers
:::caution
nRF52 devices typically do not require serial drivers. They use the UF2 bootloader which makes the devices appear as flash drives. Do _NOT_ download the USB device drivers unless required to install UF2 support.
nRF52/RP2040 devices typically do not require serial drivers. They use the UF2 bootloader which makes the devices appear as flash drives. Do _NOT_ download the USB device drivers unless required to install UF2 support.
:::
@ -86,6 +86,6 @@ After installing the serial drivers, you can now flash the Meshtastic firmware o
className={"button button--outline button--lg cta--button"}
to={"/docs/getting-started/flashing-firmware/nrf52/"}
>
Flash nRF52 Firmware
Flash nRF52/RP2040 Firmware
</Link>
</div>

2
docs/getting-started/serial-drivers/test-serial-driver-installation.mdx
View file

@ -94,7 +94,7 @@ After completing the previous steps, you can now flash the Meshtastic firmware o
className={"button button--outline button--lg cta--button"}
to={"/docs/getting-started/flashing-firmware/nrf52/"}
>
Flash nRF52 Firmware
Flash nRF52/RP2040 Firmware
</Link>
</div>
</div>

9
docs/hardware/devices/heltec/index.mdx
View file

@ -194,10 +194,15 @@ Image Source: [Heltec](https://heltec.org/project/wireless-tracker/)
</TabItem>
<TabItem value="paper">
:::info
This device may have issues charging a connected battery if utilizing a USB-C to USB-C cable. It's recommended to use a USB-A to USB-C cable.
:::caution
Please note, this device is only partially supported. The display is not currently implemented in the firmware.
Additionally, this device may have issues charging a connected battery if utilizing a USB-C to USB-C cable. It's recommended to use a USB-A to USB-C cable.
:::
- **MCU:**
- ESP32-S3FN8 (WiFi & Bluetooth)
- **LoRa Transceiver:**

144
docs/legal/code_of_conduct.mdx Normal file
View file

@ -0,0 +1,144 @@
---
id: conduct
title: Code of Conduct
sidebar_label: Conduct
---
# Contributor Covenant Code of Conduct
## Our Pledge
We as members, contributors, and leaders pledge to make participation in our
community a harassment-free experience for everyone, regardless of age, body
size, visible or invisible disability, ethnicity, sex characteristics, gender
identity and expression, level of experience, education, socio-economic status,
nationality, personal appearance, race, caste, color, religion, or sexual
identity and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming,
diverse, inclusive, and healthy community.
## Our Standards
Examples of behavior that contributes to a positive environment for our
community include:
* Demonstrating empathy and kindness toward other people
* Being respectful of differing opinions, viewpoints, and experiences
* Giving and gracefully accepting constructive feedback
* Accepting responsibility and apologizing to those affected by our mistakes,
and learning from the experience
* Focusing on what is best not just for us as individuals, but for the overall
community
Examples of unacceptable behavior include:
* The use of sexualized language or imagery, and sexual attention or advances of
any kind
* Trolling, insulting or derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or email address,
without their explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
## Enforcement Responsibilities
Community leaders are responsible for clarifying and enforcing our standards of
acceptable behavior and will take appropriate and fair corrective action in
response to any behavior that they deem inappropriate, threatening, offensive,
or harmful.
Community leaders have the right and responsibility to remove, edit, or reject
comments, commits, code, wiki edits, issues, and other contributions that are
not aligned to this Code of Conduct, and will communicate reasons for moderation
decisions when appropriate.
## Scope
This Code of Conduct applies within all community spaces, and also applies when
an individual is officially representing the community in public spaces.
Examples of representing our community include using an official email address,
posting via an official social media account, or acting as an appointed
representative at an online or offline event.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported to the community leaders responsible for enforcement using one or more of the methods:
* In Discord, send a private message to an Admin
* In Email, send a message to all of these:
* conduct@meshtastic.org
* jm@meshtastic.org
* sachaw@meshtastic.org
All complaints will be reviewed and investigated promptly and fairly.
All community leaders are obligated to respect the privacy and security of the
reporter of any incident.
## Enforcement Guidelines
Community leaders will follow these Community Impact Guidelines in determining
the consequences for any action they deem in violation of this Code of Conduct:
### 1. Correction
**Community Impact**: Use of inappropriate language or other behavior deemed
unprofessional or unwelcome in the community.
**Consequence**: A private, written warning from community leaders, providing
clarity around the nature of the violation and an explanation of why the
behavior was inappropriate. A public apology may be requested.
### 2. Warning
**Community Impact**: A violation through a single incident or series of
actions.
**Consequence**: A warning with consequences for continued behavior. No
interaction with the people involved, including unsolicited interaction with
those enforcing the Code of Conduct, for a specified period of time. This
includes avoiding interactions in community spaces as well as external channels
like social media. Violating these terms may lead to a temporary or permanent
ban.
### 3. Temporary Ban
**Community Impact**: A serious violation of community standards, including
sustained inappropriate behavior.
**Consequence**: A temporary ban from any sort of interaction or public
communication with the community for a specified period of time. No public or
private interaction with the people involved, including unsolicited interaction
with those enforcing the Code of Conduct, is allowed during this period.
Violating these terms may lead to a permanent ban.
### 4. Permanent Ban
**Community Impact**: Demonstrating a pattern of violation of community
standards, including sustained inappropriate behavior, harassment of an
individual, or aggression toward or disparagement of classes of individuals.
**Consequence**: A permanent ban from any sort of public interaction within the
community.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
version 2.1, available at
[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
Community Impact Guidelines were inspired by
[Mozilla's code of conduct enforcement ladder][Mozilla CoC].
For answers to common questions about this code of conduct, see the FAQ at
[https://www.contributor-covenant.org/faq][FAQ]. Translations are available at
[https://www.contributor-covenant.org/translations][translations].
[homepage]: https://www.contributor-covenant.org
[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
[Mozilla CoC]: https://github.com/mozilla/diversity
[FAQ]: https://www.contributor-covenant.org/faq
[translations]: https://www.contributor-covenant.org/translations

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

@ -17,6 +17,8 @@ You can find the settings available for MQTT [here](/docs/configuration/module/m
:::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.
The default channel (LongFast) on the public MQTT server usually has a lot of traffic. Your device may get overloaded and may no longer function properly anymore. It is recommended to use a different channel or to use your own MQTT server if you experience issues.
:::
## Software Integrations

71
docs/software/mqtt/nodered.mdx
View file

@ -5,7 +5,56 @@ sidebar_label: Node-RED
sidebar_position: 3
---
### Using MQTT with Node-RED
## Using MQTT with Node-RED
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.
### Enabling MQTT
Use http://client.meshtastic.org/ , the python CLI, or an Apple or Android app to connect to your device and adjust these settings.
1. Settings--> Radio Config--> Network
- On the node that will act as the gateway between the mesh and MQTT enable a network connection (i.e. Wifi, Ethernet).
- Save
2. Settings--> Module Config--> MQTT config
- Configure the MQTT gateway's network configuration.
- Verify Encryption Enabled is OFF.
- (optional) Turn JSON Output Enabled ON.
- Save
3. Channel Editor
- Go to Channel Editor and enable Uplink and Downlink on the channels you wish to publish to MQTT.
- Save
### Using Node-RED with Meshtastic
There are three common approaches:
1. Using JSON-encoded messages
2. Using protobuf-encoded messages with the Meshtastic decode node
3. Using protobuf-encoded messages with a protobuf decode node and the Meshtastic protobuf definitions
The JSON output only publishes the following subset of the messages on a Meshtastic network:
- Text Message
- Telemetry
- Device Metrics
- Environment Metrics
- Power Metrics
- Node Info
- Position
- Waypoint
- Neighbor Info
> JSON is intended to be a convenience for consuming data in other applications like Home Assistant.
> Protobufs are mesh native.
#### 1. Using JSON-encoded messages
Make sure that option *JSON Output Enabled* is set in MQTT module options.
Below is a valid JSON envelope for information sent by MQTT to a device for broadcast onto the mesh.
@ -16,21 +65,25 @@ Below is a valid JSON envelope for information sent by MQTT to a device for broa
"payload": text or a json object go here
}
```
#### 2. Using protobuf-encoded messages with the Meshtastic decode node
Install Node-Red plug-in:
https://flows.nodered.org/node/@meshtastic/node-red-contrib-meshtastic
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.
More info is in the plug-in source repository.
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--> Radio 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 an example flow using this mechanism available
https://github.com/scruplelesswizard/meshtastic-node-red
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.
Step three: install Node-RED plug-ins to your node-RED application for an embedded MQTT server and a protobuf decoder.
#### 3. Using protobuf-encoded messages with a protobuf decode node and the Meshtastic protobuf definitions
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.
Install Node-RED plug-ins to your Node-RED application for an embedded MQTT server and a protobuf decoder.
https://flows.nodered.org/node/node-red-contrib-aedes
https://flows.nodered.org/node/node-red-contrib-protobuf
Drag, drop, and wire the nodes like this. For this example, I ran node-RED on a Windows machine. Note that file paths might be specified differently on different platforms. MQTT server wild cards are usually the same. A "+" is a single level wildcard for a specific topic level. A "#" is a multiple level wildcard that can be used at the end of a topic filter. The debug messages shown are what happens when the inject button sends a JSON message with a topic designed to be picked up by the specified Meshtastic device and then having it rebroadcast the message.
Drag, drop, and wire the nodes like this. For this example, I ran Node-RED on a Windows machine. Note that file paths might be specified differently on different platforms. MQTT server wild cards are usually the same. A "+" is a single level wildcard for a specific topic level. A "#" is a multiple level wildcard that can be used at the end of a topic filter. The debug messages shown are what happens when the inject button sends a JSON message with a topic designed to be picked up by the specified Meshtastic device and then having it rebroadcast the message.
[<img src="/documents/mqtt/NodeRedTwo.jpg" style={{zoom:'50%'}} />](/documents/mqtt/NodeRedTwo.jpg)
[<img src="/documents/mqtt/NodeRedThree.jpg" style={{zoom:'50%'}} />](/documents/mqtt/NodeRedThree.jpg)

18
package.json
View file

@ -12,34 +12,34 @@
"clear": "docusaurus clear"
},
"dependencies": {
"@algolia/client-search": "^4.20.0",
"@algolia/client-search": "^4.22.0",
"@docusaurus/core": "3.0.1",
"@docusaurus/plugin-content-docs": "3.0.1",
"@docusaurus/preset-classic": "3.0.1",
"@docusaurus/theme-common": "3.0.1",
"@docusaurus/theme-mermaid": "3.0.1",
"@heroicons/react": "^2.0.18",
"@heroicons/react": "^2.1.1",
"@mdx-js/react": "^3.0.0",
"@meshtastic/meshtasticjs": "2.2.13-1",
"@meshtastic/js": "2.2.16-0",
"autoprefixer": "^10.4.16",
"base64-js": "^1.5.1",
"clsx": "^2.0.0",
"dotenv": "^16.3.1",
"postcss": "^8.4.31",
"postcss": "^8.4.32",
"react": "^18.2.0",
"react-dom": "^18.2.0",
"react-icons": "^4.12.0",
"swr": "^2.2.4",
"tailwindcss": "^3.3.5"
"tailwindcss": "^3.4.0"
},
"devDependencies": {
"@docusaurus/module-type-aliases": "3.0.1",
"@tailwindcss/typography": "^0.5.10",
"@tsconfig/docusaurus": "^2.0.2",
"@types/node": "^20.9.3",
"@types/react": "^18.2.38",
"@types/react-dom": "^18.2.16",
"@types/node": "^20.10.5",
"@types/react": "^18.2.45",
"@types/react-dom": "^18.2.18",
"biome": "^0.3.3",
"typescript": "^5.3.2"
"typescript": "^5.3.3"
}
}

913
pnpm-lock.yaml
View file

File diff suppressed because it is too large Load diff

2
src/components/tools/FrequencyCalculator.tsx
View file

@ -1,4 +1,4 @@
import { Protobuf, Types } from "@meshtastic/meshtasticjs";
import { Protobuf, Types } from "@meshtastic/js";
import React, { useEffect } from "react";
interface Region {

2
src/pages/tools/OEM.tsx
View file

@ -2,7 +2,7 @@ import React, { useEffect, useState } from "react";
import { fromByteArray, toByteArray } from "base64-js";
import { Protobuf } from "@meshtastic/meshtasticjs";
import { Protobuf } from "@meshtastic/js";
import Layout from "@theme/Layout";
const OEM = (): JSX.Element => {

69
src/utils/apiTypes.ts
View file

@ -1,65 +1,14 @@
export interface Showcase {
id: string;
title: string;
summary: string;
body: string;
createdAt: Date;
updatedAt: Date;
tags: ShowcaseTag[];
nodes?: Node[];
materials?: Material[];
author?: Author;
authorId?: string;
}
export interface ShowcaseTag {
id: string;
label: string;
description: string;
color: string;
showcases?: Showcase[];
}
export interface Node {
id: string;
latitude: string;
longitude: string;
showcase?: Showcase;
showcaseId?: string;
}
export interface Material {
id: string;
name: string;
details: string;
image: string;
url: string;
showcases?: Showcase[];
}
export interface Author {
id: string;
githubUsername: string;
bio: string;
showcase?: Showcase[];
}
export interface DeviceFirmwareResource {
id: string;
title: string;
page_url?: string;
zip_url?: string;
id: string;
title: string;
page_url?: string;
zip_url?: string;
}
export interface FirmwareReleases {
releases: {
stable: DeviceFirmwareResource[];
alpha: DeviceFirmwareResource[];
};
pullRequests: DeviceFirmwareResource[];
releases: {
stable: DeviceFirmwareResource[];
alpha: DeviceFirmwareResource[];
};
pullRequests: DeviceFirmwareResource[];
}