Meshtastic Modules and Plugins
- Telemetry Module: Device, Environment, and Power
- Store and Forward Module
- Range Test Module
- External Notification and Canned Messages
- Serial, MQTT, and Ambient Light Modules
Telemetry Module: Device, Environment, and Power
The Telemetry module broadcasts sensor data from your node across the mesh - battery voltage, temperature, humidity, barometric pressure, and more. Other nodes receive this data and display it in the app, and it can be forwarded to external systems via MQTT.
Enabling Telemetry
In the Meshtastic app: Radio Config → Modules → Telemetry
Via CLI:
meshtastic --set telemetry.device_update_interval 900
meshtastic --set telemetry.environment_update_interval 900
meshtastic --set telemetry.power_update_interval 900Intervals are in seconds. Setting to 0 disables that telemetry type. The default of 900 seconds (15 minutes) is appropriate for most deployments.
Device Telemetry
Device telemetry is always available - it reports internal state from the node itself, no external sensors required:
| Field | Source | Notes |
|---|---|---|
| Battery level (%) | Hardware ADC | Accuracy varies by board; some boards always report 100% if battery not detected |
| Voltage (V) | Hardware ADC | Useful for deriving SoC for LiFePO4 packs |
| Channel utilization (%) | Radio stats | Percentage of airtime used; over 25% indicates congestion |
| Air utilization TX (%) | Radio stats | Percentage of time this node was transmitting |
| Uptime (seconds) | System clock | Resets on power cycle |
Environment Telemetry
Requires an external I2C sensor. Supported sensors include:
| Sensor | Measures | I2C Address | Notes |
|---|---|---|---|
| BME280 | Temp, Humidity, Pressure | 0x76 or 0x77 | Most popular; inexpensive; not suitable for air quality |
| BME680 | Temp, Humidity, Pressure, VOC/IAQ | 0x76 or 0x77 | Adds air quality index; requires 5-minute warmup |
| SHT31 | Temp, Humidity | 0x44 or 0x45 | High accuracy; ±0.3°C, ±2% RH |
| MCP9808 | Temperature only | 0x18-0x1F | ±0.25°C accuracy; for precision temperature monitoring |
| SHTC3 | Temp, Humidity | 0x70 | Low power; used on some integrated boards |
meshtastic --set telemetry.environment_measurement_enabled true
meshtastic --set telemetry.environment_screen_enabled truePower Telemetry
Requires an INA219 or INA260 current sensor on the I2C bus. Reports voltage, current draw, and calculated power consumption - useful for monitoring solar systems and diagnosing battery drain.
meshtastic --set telemetry.power_measurement_enabled trueTelemetry Intervals and Airtime Impact
Every telemetry broadcast consumes airtime. At Long Fast preset, a telemetry packet takes approximately 0.3-0.5 seconds of airtime. At 15-minute intervals with one sensor type, this is negligible. But if you enable all three telemetry types at 5-minute intervals on a busy network, the combined airtime impact becomes meaningful. As a guideline:
- Fixed infrastructure nodes: 15-30 minute intervals are appropriate
- Portable/personal nodes: 30-60 minute intervals to reduce network load
- Emergency operations (where battery monitoring is critical): 5-minute intervals acceptable
Store and Forward Module
The Store and Forward module lets a designated node buffer messages for clients that were offline when a message was sent. When the offline client reconnects to the mesh, it can request the message history and receive messages it missed.
How Store and Forward Works
- A node configured as a Store and Forward server (typically a fixed repeater with reliable power) listens to all channel traffic and stores messages in flash memory.
- When a client node that was offline reconnects, it sends a heartbeat to indicate it is online.
- The client can then request history from the Store and Forward server.
- The server replays stored messages to the requesting client.
Enabling on a Server Node (Repeater)
Configure the node that will store messages:
meshtastic --set store_and_forward.enabled true
meshtastic --set store_and_forward.is_server true
meshtastic --set store_and_forward.records 100records sets the maximum number of messages to store (circular buffer; oldest messages are overwritten). Default 100; increase up to the flash capacity of your device (ESP32 has more flash than nRF52840 for this purpose).
Enabling on a Client Node
Client nodes that want to receive history need the module enabled:
meshtastic --set store_and_forward.enabled true
meshtastic --set store_and_forward.is_server falseThe client will automatically request history when it comes online and can see the server node.
Limitations and Considerations
- Only one Store and Forward server per channel is recommended. Multiple servers on the same channel will each replay messages independently, causing duplicate deliveries.
- Server node must be always-on. A server that goes offline defeats the purpose. Use a mains or solar-powered repeater with reliable uptime.
- Does not store all traffic by default. Only channel messages are stored, not position reports or telemetry (configurable).
- Flash wear. Frequent writes to flash for message storage will wear the flash memory over years of operation. This is generally acceptable for typical community mesh usage but worth noting for very high-traffic channels.
- Message delivery is best-effort. If the client is out of radio range of the server, history request packets cannot reach the server.
Best Deployment Practice
Deploy Store and Forward on your highest-uptime fixed node - typically the primary community repeater with mains or solar power. This is the node most likely to have been online and collecting messages during the period a user was offline.
Range Test Module
The Range Test module automates signal strength measurement for deployment validation - letting you map exactly where in your coverage area packets arrive successfully, and at what SNR and RSSI values.
What the Range Test Module Does
Range Test operates as a sender/receiver pair:
- Sender node - Broadcasts a test packet at a configurable interval, incrementing a sequence number each time.
- Receiver node (typically your phone) - Logs each received packet with GPS coordinates (from the receiver's location), SNR, RSSI, and sequence number.
- Output - A CSV file saved to the receiver's device containing all received packets with position data, signal quality, and sequence numbers. Missing sequence numbers identify packet loss.
Setting Up a Range Test
Configure the Sender Node
meshtastic --set range_test.enabled true
meshtastic --set range_test.sender 60sender is the interval in seconds between test packets. 60 seconds works well for driving tests; 30 seconds for walking tests where you move slower.
Configure the Receiver
meshtastic --set range_test.enabled true
meshtastic --set range_test.save trueWith save true, received packets are logged to a file called rangetest.csv in the root of the device's SD card (if equipped) or internal storage.
Conducting a Range Test Drive
- Place the sender node at your repeater location or test deployment point. Ensure it has GPS lock and is transmitting.
- Configure your phone/portable node as the receiver.
- Drive or walk through your intended coverage area.
- After the test, retrieve the CSV file. Each row contains: timestamp, GPS lat/lon, SNR, RSSI, sequence number.
- Import the CSV into Google Maps (My Maps), QGIS, or any mapping tool to visualize coverage.
Interpreting Results
| RSSI | SNR | Connection Quality |
|---|---|---|
| -80 to -100 dBm | >5 dB | Excellent - reliable delivery |
| -100 to -115 dBm | 0 to 5 dB | Good - occasional packet loss |
| -115 to -125 dBm | -5 to 0 dB | Marginal - 20-40% packet loss |
| Below -125 dBm | Below -10 dB | Edge of range - unreliable |
Note: LoRa can decode packets at negative SNR values (down to approximately -20 dB depending on Spreading Factor) - this is one of its most remarkable properties. RSSI alone is not the full picture; low RSSI with high SNR can still be a reliable link.
Using Range Test for Repeater Placement Decisions
Deploy a temporary repeater at a candidate site, run a range test drive across the intended coverage area, then compare the CSV output against a test from your next-best candidate site. This gives objective, data-driven evidence for repeater placement decisions rather than guessing based on map topology alone.
External Notification and Canned Messages
External Notification Module
The External Notification module triggers a visual or audio alert on the node hardware when a message is received - useful for heads-up awareness without constantly watching a screen.
Configuration
meshtastic --set external_notification.enabled true
meshtastic --set external_notification.output_ms 1000
meshtastic --set external_notification.active true
meshtastic --set external_notification.alert_message trueoutput_ms is how long to activate the output in milliseconds. active sets the logic level (true = active high output). alert_message triggers on incoming text messages; alert_bell triggers on all message types.
Hardware Outputs
The module drives a GPIO pin that can trigger:
- Buzzer - Active buzzer connected between the GPIO pin and GND (through a transistor for modules requiring more current)
- LED - External LED indicator, useful for daytime visibility or status display
- Relay - Via a relay module, can trigger any external device: alarm siren, strobe light, or notification device
Most T-Beam and Heltec boards have accessible GPIO pins; consult your board's pinout documentation for safe GPIO numbers (avoid pins used by LoRa, I2C, and UART).
Canned Messages Module
The Canned Messages module allows quick message sending from the device hardware without using the phone app - ideal for when you have a dedicated node with a small rotary encoder or button input.
Use Case
Deploy a node in a fixed location (workshop, vehicle, equipment room) with a rotary encoder. The user can navigate a pre-programmed list of messages and send them with a button press, without needing to open a phone app. Useful for sending routine status messages in situations where opening a phone is inconvenient.
Configuration
meshtastic --set canned_message.enabled true
meshtastic --set canned_message.messages "OK|On my way|Need help|ETA 10 min|Stand by"Messages are separated by pipe characters. Maximum total length is limited by protobuf message size; keep individual messages short.
Input Hardware
Requires a rotary encoder connected to GPIO pins, or can use UP/DOWN/SELECT button inputs. Configure the GPIO pin assignments:
meshtastic --set canned_message.inputbroker_pin_a 39
meshtastic --set canned_message.inputbroker_pin_b 40
meshtastic --set canned_message.inputbroker_event_cw MSG_INPUT_EVENT_NEXT
meshtastic --set canned_message.inputbroker_event_ccw MSG_INPUT_EVENT_PREVPin numbers are board-specific. The RAK WisBlock Input module provides a pre-built button/encoder input board compatible with the WisBlock system.
Serial, MQTT, and Ambient Light Modules
Serial Module
The Serial module lets external hardware send and receive Meshtastic messages over a UART serial connection - enabling integration with microcontrollers, GPS units, custom sensors, and computer software.
Modes of Operation
| Mode | Description | Use Case |
|---|---|---|
| DEFAULT | Raw bytes in/out, app-layer messages | Arduino/ESP32 integration |
| SIMPLE | Newline-delimited text in/out | Simple text message bridging |
| PROTO | Protobuf framing | Full programmatic access |
| NMEA | Outputs NMEA sentences from node GPS | Feeding position to chartplotters |
| CALTOPO | CalTopo-compatible position format | SAR map integration |
Configuration
meshtastic --set serial.enabled true
meshtastic --set serial.mode SIMPLE
meshtastic --set serial.rxd 16
meshtastic --set serial.txd 17
meshtastic --set serial.baud BAUD_9600RXD/TXD pin numbers are board-specific. In SIMPLE mode, text sent to the serial port (terminated with newline) is broadcast as a mesh message; received mesh messages are printed as text to the serial port.
MQTT Module
The MQTT module directly connects a Meshtastic node to an MQTT broker (internet required), enabling cloud integration without a separate gateway computer.
meshtastic --set mqtt.enabled true
meshtastic --set mqtt.address "mqtt.meshtastic.org"
meshtastic --set mqtt.username "meshdev"
meshtastic --set mqtt.password "large4cats"
meshtastic --set mqtt.root "msh"
meshtastic --set mqtt.uplink_enabled true
meshtastic --set mqtt.downlink_enabled falseuplink_enabled sends local mesh packets to the broker. downlink_enabled receives packets from the broker and re-broadcasts locally - useful for extending the mesh over the internet but can cause feedback loops if misconfigured. Start with downlink disabled until you understand the topology.
Topic Structure
Meshtastic publishes to: msh/{region}/{channel_name}/{packet_type}
Example: msh/US/LongFast/text for text messages on the LongFast channel in the US region. Subscribe with wildcards: msh/US/# to receive all traffic from US nodes.
Ambient Light Sensor Module
When a supported ambient light sensor (BH1750, VEML7700, or TSL2591) is connected via I2C, this module adjusts the screen backlight brightness automatically based on ambient light conditions - reducing battery drain in dark environments and ensuring readability in sunlight.
meshtastic --set ambient_lighting.led_state true
meshtastic --set ambient_lighting.current 10Also works with RGB LED hardware (NeoPixel/WS2812) to set a status color. current is the LED current in milliamps (for current-controlled LEDs). For the screen backlight use case, no explicit configuration is needed beyond enabling the module - brightness is automatically managed.