Meshtastic Modules and Plugins 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 900 Intervals 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 true Power 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 true Telemetry 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 100 records 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 false The 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 60 sender 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 true With 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 true output_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_PREV Pin 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_9600 RXD/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 false uplink_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 10 Also 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.