Device Configuration

The Device Configuration tab in MeshMonitor allows you to remotely configure your connected Meshtastic device. Changes are sent directly to the device and typically require a reboot to take effect.

WARNING

Configuration changes directly modify your Meshtastic device settings. Always ensure you understand the impact of changes before applying them, as incorrect settings may affect device functionality or network connectivity.

Node Identity

Long Name

Description: The full display name for your node, shown in node lists and messages.

Maximum Length: 39 characters. Firmware 2.8 and later clamp the name it stores and transmits to 24 bytes (MAX_LONG_NAME_BYTES, meshUtils.h), so a longer name is truncated on the device.

Effect: Changes how your node appears to other users on the mesh network.

Side Effects:

Broadcasts the new name to all mesh users
May take several minutes to propagate throughout the network
Requires device reboot to take effect

Best Practices:

Use descriptive names that help identify location or purpose
Avoid special characters that may not display correctly
Keep it concise for better display on small screens

Short Name

Description: A 4-character abbreviated name for your node.

Maximum Length: 4 characters

Effect: Used in compact displays and when bandwidth is limited.

Side Effects:

Broadcasts the new short name to all mesh users
Some interfaces use short name exclusively
Requires device reboot to take effect

Best Practices:

Use easily recognizable abbreviations
Typically derived from long name (e.g., "Base Station 1" → "BS01")
Avoid ambiguous abbreviations

Unmessagable Nodes

Description: Nodes that advertise the is_unmessagable flag (and unlicensed nodes, is_licensed = false, where applicable) cannot receive direct messages — sensors, repeaters, and similar devices set this so DMs sent to them would silently go nowhere.

Effect in MeshMonitor: For these nodes, MeshMonitor hides the direct-message UI entirely instead of offering a composer that can't deliver:

The 💬 DM button is hidden in the Nodes tab.
Selecting the node in the Messages tab shows its node detail and per-node telemetry in place of the conversation — the message log, send composer, and mesh-transmit actions are not shown.

Side Effects:

The node remains fully listed and selectable in the node/contact lists, with all of its indicators, detail, and telemetry intact.
No messaging entry point is offered, avoiding the misleading "delivered" acknowledgements that occur when a relay acks a packet the target never received.

Meshtastic Device Configuration

Device Configuration

Device Role

Defines how your node behaves on the mesh network and affects power consumption, relay behavior, and visibility.

CLIENT (Default)

Description: General-purpose mode for devices with app connections or standalone messaging.

Behavior:

Rebroadcasts packets when no other node has done so
Normal power consumption
Full mesh network participation

Use Cases:

Personal handheld devices
Desktop monitoring stations
General mesh participation

Side Effects: Standard airtime usage and power consumption

CLIENT_MUTE

Description: Device that participates but does not forward packets from other devices.

Behavior:

Receives and sends own messages
Does NOT relay packets for others
Reduced network load contribution

Use Cases:

Reducing network congestion
Low-power deployments
Personal use without helping the mesh

Side Effects: Reduces overall mesh connectivity; not recommended for community networks

ROUTER ⚠️

Description: Infrastructure node that always rebroadcasts packets to extend network coverage.

Behavior:

Always relays all packets (no intelligent delay)
Visible in network topology
Significantly increased power consumption

Use Cases:

Fixed infrastructure installations
Strategic coverage extension points
Powered installations only

Side Effects:

Very high airtime usage
Significant battery drain (not suitable for battery power)
May cause network congestion if overused

DANGER

MeshMonitor will warn you before setting ROUTER mode. Only use this for powered, fixed infrastructure nodes in strategic locations.

TRACKER

Description: Optimized for broadcasting GPS position with priority handling.

Behavior:

GPS packets are prioritized
Reduced relay activity
Optimized for frequent position updates

Use Cases:

Vehicle tracking
Asset tracking
Mobile position reporting

Side Effects: Position broadcasts consume airtime; best for moving assets

SENSOR

Description: Optimized for broadcasting telemetry data with priority handling.

Behavior:

Telemetry packets are prioritized
Reduced relay activity
Efficient power usage for sensors

Use Cases:

Environmental monitoring stations
Weather sensors
Remote sensor deployments

Side Effects: Telemetry broadcasts consume airtime

TAK

Description: Optimized for ATAK (Android Team Awareness Kit) system communication.

Behavior:

Reduces routine broadcasts
Optimized for tactical communications
Requires Meshtastic ATAK Plugin

Use Cases:

Integration with ATAK systems
Tactical operations
Coordinated activities

Side Effects: Requires ATAK plugin for full functionality

CLIENT_HIDDEN

Description: Minimalist broadcasting for stealth or extreme power savings.

Behavior:

Only broadcasts when absolutely necessary
Minimal network presence
Maximum power conservation

Use Cases:

Stealth deployments
Ultra-low-power requirements
Hidden installations

Side Effects: Reduced network visibility; may appear offline to other users

LOST_AND_FOUND

Description: Broadcasts location messages to assist with device recovery.

Behavior:

Regular location broadcasts to default channel
Optimized for device recovery
Increased GPS activity

Use Cases:

Lost or stolen device recovery
Temporary deployment tracking

Side Effects: Frequent position broadcasts; high power usage

TAK_TRACKER

Description: Standalone Position Location Information (PLI) for ATAK systems.

Behavior:

Automatic TAK PLI broadcasts
Reduced routine broadcasts
Optimized for tactical tracking

Use Cases:

Tactical position tracking with ATAK
Team location awareness
Coordinated operations

Side Effects: Requires ATAK integration

ROUTER_LATE

Description: Infrastructure node that rebroadcasts only after all other modes attempt relay.

Behavior:

Waits for other nodes to relay first
Provides backup coverage
Visible in network topology

Use Cases:

Covering dead spots in local clusters
Backup coverage for specific areas
Ensuring local reliability without overloading broader mesh

Side Effects: Increased airtime usage (but less than ROUTER); best for powered installations

CLIENT_BASE

Description: Personal base station that prioritizes favorited nodes.

Behavior:

Always rebroadcasts packets from/to favorited nodes
Handles other packets like CLIENT
Helps extend range for specific nodes

Use Cases:

Strong attic/roof installations
Distribution node for weaker indoor devices
Personal network enhancement

Side Effects: Increased relay activity for favorited nodes

Node Info Broadcast Interval

Description: How often the device broadcasts its node information to the mesh.

Range: up to 2147483647 seconds (~68 years). Firmware clamps anything larger.

Default: 10800 seconds (3 hours)

Minimum: 3600 seconds (1 hour) (min_node_info_broadcast_secs, Default.h). Firmware raises any lower value to 3600 when the Device section is saved (AdminModule::handleSetConfig), and MeshMonitor refuses a non-zero value below 3600 on both the Configuration and Admin Commands tabs.

A value of 0: a node shows 0 when the interval was never set, and then uses the 3 hour default. MeshMonitor sends that 0 back as 0, but the firmware minimum applies to 0 too: after any save of the Device section the node holds 3600. Enter 10800 to keep 3 hours.

Effect: Controls how frequently other nodes receive updated information about your device (name, position, battery status, etc.).

Side Effects:

Shorter intervals: More network traffic, more up-to-date information, higher power usage
Longer intervals: Less network traffic, potentially stale information, lower power usage
Affects how quickly name changes and position updates propagate

Best Practices:

Use default (3 hours) for most deployments
Increase for static installations (6-12 hours)
Decrease only for highly mobile nodes needing frequent updates

LoRa Radio Configuration

Use Preset

Description: Enable or disable using predefined modem configurations.

Recommendation: Keep enabled unless you have specific requirements for custom settings.

Effect: When enabled, modem parameters (bandwidth, spreading factor, coding rate) are set automatically based on the selected preset.

Side Effects: Disabling requires manual configuration of advanced LoRa parameters

Advanced Configuration

When "Use Preset" is disabled, you must manually configure bandwidth, spreading factor, and coding rate. Incorrect settings can prevent communication with other nodes or violate regulatory requirements. Only disable presets if you have specific technical requirements and understand LoRa modulation parameters.

TX Enabled

Description: Enables or disables radio transmission on this source's node.

Effect: When enabled (default), the node transmits normally — messages, traceroutes, requests, and its own NodeInfo/Position/Telemetry broadcasts all go out over LoRa. When disabled, the node becomes receive-only: it keeps decoding everything it hears, but every outbound LoRa packet is dropped at the radio.

Side Effects: Unchecking this shows a confirmation dialog, because disabling TX has broad consequences — see Receive-Only Mode for the full list of what still works and what doesn't.

Receive-Only Mode

Disabling TX makes the node invisible to the mesh — it stops announcing itself, so other nodes will eventually age it out. MeshMonitor's own transmit controls (send, traceroute, remote admin, etc.) are disabled with a tooltip while this is off, and a persistent banner reminds you TX is disabled. See Receive-Only Mode for details.

Manual LoRa Parameters

These parameters are only available when "Use Preset" is disabled. They provide fine-grained control over radio modulation for advanced users.

Bandwidth

Description: Channel bandwidth in kHz, which determines the frequency range used for transmission.

Range: 31-500 kHz

Common Values:

31 (31.25 kHz) - Narrowest, best interference resistance
62 (62.5 kHz) - Used by the NARROW presets
125 kHz - Good balance
250 kHz - Most common, used by LONG_FAST and the MEDIUM/SHORT presets
500 kHz - Widest, highest data rate

The field holds the firmware's bandwidth code, a whole number: enter 31 for 31.25 kHz and 62 for 62.5 kHz.

Effect: Wider bandwidth = faster data rate but more susceptible to interference. Narrower bandwidth = slower data rate but better sensitivity and interference resistance.

Side Effects:

All nodes must use the same bandwidth to communicate
Wider bandwidths may violate duty cycle regulations in some regions
Affects battery life (wider = more power)

Best Practices:

Use 250 kHz for most deployments (matches LONG_FAST)
Only change if you have specific range or speed requirements
Verify regulatory compliance for your region

Spreading Factor

Description: Number of chirps per symbol, which determines how the signal is spread across time.

Range: 7-12

Effect: Higher spreading factor = longer range but slower data rate. Each increment doubles range but halves speed.

Common Configurations:

SF7: Shortest range, fastest speed (5.47 kbps @ 125kHz)
SF9: Medium range (SHORT presets)
SF10: Good range (MEDIUM presets)
SF11: Long range (LONG presets)
SF12: Maximum range, slowest speed (293 bps @ 125kHz)

Side Effects:

Higher SF = longer airtime = more battery usage
Higher SF = more susceptible to frequency drift
All nodes must use the same SF to communicate
Different SFs are orthogonal (can coexist without interference)

Best Practices:

Start with SF11 (LONG_FAST default) for most deployments
Increase to SF12 only for extreme range requirements
Lower to SF7-9 for dense local networks

Coding Rate

Description: Denominator of the forward error correction (FEC) coding rate.

Range: 5-8

Format: Coding rate is 4/N where N is the value you set (5-8)

Common Values:

5 (4/5): Lightest error correction, fastest speed
6 (4/6): Light error correction
7 (4/7): Moderate error correction
8 (4/8): Heaviest error correction, most robust

Effect: Higher coding rate (larger denominator) = more error correction overhead but better resistance to interference.

Side Effects:

Higher coding rate = longer airtime = more battery usage
Higher coding rate = slower effective data rate
All nodes must use the same coding rate to communicate

Best Practices:

Use 8 (4/8) for long-range or noisy environments (LONG_SLOW, LONG_MODERATE, LONG_TURBO)
Use 5 (4/5) for most links; LONG_FAST and the MEDIUM/SHORT presets all use it

Frequency Offset

Description: Fine-tuning frequency offset in MHz for crystal calibration and drift compensation.

Range: Typically ±0.5 MHz

Default: 0

Effect: Adjusts the transmission frequency by a small amount to compensate for crystal oscillator inaccuracies.

Use Cases:

Compensating for temperature drift
Correcting known crystal frequency errors
Fine-tuning for optimal performance with specific hardware

Side Effects:

Incorrect offset can prevent communication
Should only be changed if you've measured a frequency error
Most devices do not require adjustment

Best Practices:

Leave at 0 unless you have a specific reason to change it
Only adjust if you've used test equipment to measure frequency error
Very rarely needed with modern hardware

Modem Preset

Predefined radio settings that balance range, speed, and reliability. All nodes on a mesh must use the same preset to communicate. The values below come from the firmware's modemPresetToParams() table.

Preset	Bandwidth	SF	CR	Firmware	Notes
LONG_FAST (default)	250 kHz	11	4/5	all	Most deployments
LONG_SLOW	125 kHz	12	4/8	all	Deprecated upstream
LONG_MODERATE	125 kHz	11	4/8	all	More range than LONG_FAST, slower
LONG_TURBO	500 kHz	11	4/8	all	LONG_FAST range class at 500 kHz
MEDIUM_SLOW	250 kHz	10	4/5	all
MEDIUM_FAST	250 kHz	9	4/5	all
MEDIUM_TURBO	500 kHz	9	4/5	2.8+
SHORT_SLOW	250 kHz	8	4/5	all
SHORT_FAST	250 kHz	7	4/5	all	Dense local meshes
SHORT_TURBO	500 kHz	7	4/5	all	Fastest
LITE_FAST	125 kHz	9	4/5	2.8+	EU_866 only
LITE_SLOW	125 kHz	10	4/5	2.8+	EU_866 only
NARROW_FAST	62.5 kHz	7	4/6	2.8+	EU_N_868 and amateur 70cm / 1.25m only
NARROW_SLOW	62.5 kHz	8	4/6	2.8+	EU_N_868 and amateur 70cm / 1.25m only
TINY_FAST	15.6 kHz	7	4/5	2.8+	Amateur 2m only
TINY_SLOW	15.6 kHz	8	4/6	2.8+	Amateur 2m only

Firmware 2.8 early preview

See What is MeshMonitor's "firmware 2.8 early preview" decode support?.

Which presets the picker shows

The preset list only offers presets the connected radio will accept, because firmware does not reject a bad preset: it quietly swaps in a different one.

Firmware 2.8 and newer (or a version MeshMonitor has not seen yet): each region has its own preset list, copied from the firmware. Standard regions (US, EU_433, ANZ, and so on) get the ten standard presets. EU_868 gets the seven presets up to 250 kHz. EU_866 gets only LITE_FAST / LITE_SLOW, EU_N_868 and the amateur 70cm and 1.25m bands get only NARROW_FAST / NARROW_SLOW, and the amateur 2m bands get only TINY_FAST / TINY_SLOW.
Firmware older than 2.8: the 2.8-only presets (LITE, NARROW, TINY and MEDIUM_TURBO) are hidden, since older firmware would run LONG_FAST settings in their place. A preset is also hidden when its bandwidth is wider than the region's band (EU_868 hides the 500 kHz presets).

Firmware 2.8 treats EU_868, EU_866 and EU_N_868 as one family: its own apps list all their presets, and picking a LITE or NARROW preset on EU_868 makes the radio change its region. MeshMonitor does not do this; pick the region first (EU_866 for LITE, EU_N_868 for NARROW) and its presets appear.

If the radio is already on a preset that the list would hide, MeshMonitor still shows it as selected, with a warning, rather than changing it for you. If the radio reports a preset MeshMonitor does not recognize, the LoRa section refuses to save until you pick one, so it never writes a guess back to the radio.

Side Effects:

All mesh participants must use compatible settings
Changing presets may disconnect you from the network
Slower presets = longer airtime = more power usage
Faster presets = shorter range

Custom Parameter Recipes

When Use Preset is off, a Load recipe menu above the bandwidth field fills bandwidth, spreading factor and coding rate from a named community profile. It does not change the region, frequency slot or override frequency, and nothing reaches the radio until you save.

Recipe	Bandwidth	SF	CR	Source
LongModTurbo	500 kHz	11	4/8	Proposed in meshtastic/firmware#8214 (not merged)

A recipe is disabled when the region cannot use its bandwidth: when the band is too narrow (EU_868 cannot fit 500 kHz), or on firmware 2.8 when it is wider than the region's widest official preset. Loading one asks you to confirm first, because:

Every node on your mesh must use exactly the same custom settings, or they will not hear each other.
A recipe is not an official preset. Nodes on any official preset, including LONG_TURBO, cannot talk to it.
Your frequency slot is left alone, so nodes meant to talk to each other must also share the same slot.

Region

Description: Sets the frequency band and regulatory settings for your location.

Important: Select the correct region for your location to comply with local regulations.

Options:

UNSET: Region not configured
US: United States (915MHz)
EU_433: European Union (433MHz)
EU_868: European Union (868MHz)
CN: China
JP: Japan
ANZ: Australia/New Zealand (915MHz)
KR: Korea
TW: Taiwan
RU: Russia
IN: India
NZ_865: New Zealand (865MHz)
TH: Thailand
LORA_24: WLAN Band (2.4GHz)
UA_433: Ukraine (433MHz)
UA_868: Ukraine (868MHz)
MY_433: Malaysia (433MHz)
MY_919: Malaysia (919MHz)
SG_923: Singapore
PH_433: Philippines (433MHz)
PH_868: Philippines (868MHz)
PH_915: Philippines (915MHz)
ANZ_433: Australia / New Zealand (433MHz)
KZ_433: Kazakhstan (433MHz)
KZ_863: Kazakhstan (863MHz)
NP_865: Nepal (865MHz)
BR_902: Brazil (902MHz)
EU_866, EU_874, EU_917: European Union SRD bands (866MHz, 874MHz, 917MHz)
EU_N_868: European Union 868MHz Narrow
ITU1_2M, ITU2_2M, ITU3_2M: Amateur 2m, ITU Regions 1 to 3
ITU1_70CM, ITU2_70CM, ITU3_70CM: Amateur 70cm, ITU Regions 1 to 3
ITU2_125CM: Amateur 1.25m, ITU Region 2

The EU SRD, EU narrow and amateur regions come with firmware 2.8. The amateur bands need a licence; check local law before you pick one.

Side Effects:

Incorrect region may violate local regulations
May prevent communication with local mesh networks
Affects maximum power output and duty cycle limits

Legal Compliance

Always select the correct region for your location. Using incorrect frequency bands may be illegal and could result in fines or equipment confiscation.

Hop Limit

Description: Maximum number of times a message can be relayed through the mesh.

Range: 1-7. A node that reports 0 (zero hops: no other node relays its packets) shows 0, but a save sends 1, not 0.

Default: 3

Effect: Limits how far messages can propagate through the network. Each relay counts as one hop.

Side Effects:

Lower values (1-2): Reduced network range, less congestion, lower power usage
Higher values (5-7): Extended range, increased network load, more battery drain across all nodes
Value of 7 allows messages to traverse large networks but may cause congestion

Best Practices:

Use default (3) for most deployments
Increase (4-5) only for very large geographic coverage
Decrease (1-2) for dense local networks to reduce congestion

Channel Number

Description: The frequency slot the radio transmits on within the region's band. The value is 1-based.

Range: 1 to the region's frequency-slot count. The ceiling depends on region and bandwidth, and firmware rejects any slot above it (numFreqSlots, RadioInterface.cpp), so there is no flat 0-255 limit.

Default: 0, which derives the slot from a hash of the channel name.

Effect: Determines the specific frequency offset within your region's frequency band. All nodes on the same mesh network must use the same channel number to communicate.

Side Effects:

Changing channel number will disconnect you from nodes using different channel numbers
Can be used to create isolated networks within the same physical area
Does not affect regulatory region compliance (region setting controls legal frequencies)

Best Practices:

Use default (0) unless you need network isolation
Change only if you need to avoid interference with another nearby mesh network
Ensure all nodes in your network use the same channel number

RX Boosted Gain (SX126x)

Description: Enable boosted receive gain mode for devices using SX126x radio chips (e.g., RAK4631, LilyGo T-Beam with SX1262).

Default: Disabled

Effect: Improves receiver sensitivity, allowing the radio to receive weaker signals and potentially extending range.

Side Effects:

Increased power consumption: Boosted gain mode uses more power, reducing battery life
May increase noise: Higher sensitivity can also pick up more background RF noise
Only works on SX126x radios: Has no effect on SX127x or other radio types

Best Practices:

Enable for fixed, powered installations where power consumption isn't a concern
Consider enabling for routers or infrastructure nodes to improve network coverage
Disable for battery-powered mobile nodes to maximize battery life
Test range improvement in your specific environment (results vary)

Hardware Compatibility:

✅ Works: Devices with SX1262, SX1268 radios (RAK4631, some T-Beam models, Heltec V3)
❌ No effect: Devices with SX1276, SX1278 radios (older T-Beam, some Heltec models)

Position Configuration

Position Broadcast Interval

Description: How often to broadcast GPS position updates.

Range: 32-4294967295 seconds, or 0 for the firmware default

Default: 900 seconds (15 minutes) on older firmware; 3600 seconds (1 hour) on current firmware, 43200 seconds (12 hours) for router roles

A value of 0: the node uses the firmware default above. MeshMonitor sends a stored 0 back as 0, so saving another field in this section leaves the default in place. Any other value below 32 seconds is refused.

Effect: Controls frequency of position broadcasts to the mesh network.

Side Effects:

Shorter intervals: More network traffic, more current position data, higher power/battery usage
Longer intervals: Less network traffic, potentially stale position data, lower power usage

Best Practices:

Mobile nodes: 300-900 seconds (5-15 minutes)
Fixed nodes: 3600+ seconds (1+ hours)
Disable entirely (very large value) for nodes that don't need position sharing

Smart Position

Description: Intelligently adjusts position broadcast frequency based on movement.

Effect: When enabled, broadcasts more frequently when moving, less frequently when stationary.

Side Effects:

Reduces unnecessary broadcasts for stationary nodes
May delay position updates slightly
Saves battery on mobile deployments

Best Practices: Enable for mobile nodes, optional for fixed installations

Fixed Position

Description: Override GPS with a manually specified location.

Effect: Device reports the configured coordinates instead of GPS data.

Use Cases:

Nodes without GPS hardware
Indoor installations where GPS doesn't work
Correcting inaccurate GPS readings
Privacy (hiding exact GPS location)

Configuration: When enabled, enter:

Latitude: Decimal degrees (-90 to 90)
Longitude: Decimal degrees (-180 to 180)
Altitude: Meters above sea level

Side Effects:

Position never updates even if device moves
GPS hardware is not used (saves power)

Meshtastic Position Configuration

Power Configuration

Configure power management and battery settings for your Meshtastic device. These settings control sleep behavior, shutdown thresholds, and power consumption optimization.

Power Saving Mode

Description: Enable power saving features to extend battery life.

Effect: When enabled, the device uses various power-saving techniques to reduce power consumption.

Side Effects:

Reduced responsiveness when waking from sleep
Longer wake-up time for messages
Extended battery life

Best Practices: Enable for battery-powered deployments

Shutdown After (Battery)

Description: Automatically shut down the device after the specified time on battery power.

Range: 0-4294967295 seconds (0 = disabled)

Effect: Prevents complete battery drain by shutting down before battery is depleted.

Use Cases:

Protecting LiPo batteries from over-discharge
Scheduled operation windows
Emergency beacon deployments

Side Effects: Device will power off and require manual restart

ADC Multiplier Override

Description: Calibration value for battery voltage reading accuracy.

Default: 0, meaning use the board default. The proto documents a practical range of 2-6 (config.proto); firmware accepts any value above 0 and does not clamp the upper bound.

Effect: Adjusts the analog-to-digital converter scaling for accurate battery percentage reporting.

Use Cases:

Correcting inaccurate battery readings
Custom battery configurations
Hardware with non-standard voltage dividers

Best Practices: Only change if battery percentage readings are consistently inaccurate

Wait Bluetooth Seconds

Description: How long to wait for Bluetooth connection before entering sleep mode.

Range: 0-4294967295 seconds

Effect: Controls the Bluetooth connection window before power-saving sleep.

Side Effects: Longer values delay sleep but give more time for Bluetooth connections

SDS (Deep Sleep) Seconds

Description: Duration of super deep sleep periods when no activity is detected.

Range: 0-4294967295 seconds

Effect: Controls how long the device stays in deepest sleep mode.

Best Practices: Use longer periods for solar/battery nodes to maximize power savings

LS (Light Sleep) Seconds

Description: Duration of light sleep periods between active wake cycles.

Range: 0-4294967295 seconds

Effect: Controls light sleep duration (faster wake-up than deep sleep).

Best Practices: Balance between power savings and responsiveness

Minimum Wake Seconds

Description: Minimum time the device stays awake after waking from sleep.

Range: 0-4294967295 seconds

Effect: Ensures device is active long enough to process messages before returning to sleep.

Side Effects: Higher values increase power consumption but improve message handling reliability

Battery INA Address

Description: I2C address for INA battery monitoring chip.

Default: Auto-detected

Effect: Specifies the I2C address when using external INA battery monitoring hardware.

Use Cases: Custom hardware with non-standard I2C addresses

Meshtastic Power Configuration

Display Configuration

Configure screen and display settings for Meshtastic devices with integrated screens or external displays.

Screen On Seconds

Description: How long the screen stays on after activity.

Range: 0-4294967295 seconds

Default: 60 seconds

Effect: Controls screen timeout to save power.

Best Practices: Lower values for battery-powered devices, higher for powered stations

Auto Screen Carousel Seconds

Description: Time between automatic screen rotations through different display pages.

Range: 0-4294967295 seconds (0 = disabled)

Effect: Automatically cycles through status screens (node info, telemetry, messages, etc.).

Use Cases:

Unattended display monitoring
Dashboard/kiosk mode
Showing all available information automatically

Flip Screen

Description: Rotate display 180 degrees.

Effect: Inverts the screen orientation for upside-down mounting.

Use Cases: Mounting device in enclosures with inverted display orientation

Measurement Units

Description: Unit system for measurements (metric/imperial).

Options:

METRIC: Distances in km/m, temperatures in Celsius
IMPERIAL: Distances in mi/ft, temperatures in Fahrenheit

Effect: Changes how distance, speed, altitude, and temperature are displayed.

OLED Type

Description: Type of OLED display connected to the device.

Options:

AUTO: Automatically detect display type
SSD1306: Standard 128x64 OLED (most common)
SH1106: 132x64 OLED (similar to SSD1306 with offset)
SH1107: Larger 128x128 OLED
SH1107_128_128: 128x128 variant

Effect: Configures driver for correct display rendering.

Best Practices: Use AUTO unless you have display issues, then select your specific model

Display Mode

Description: Color and rendering mode for the display.

Options:

DEFAULT: Standard single-color rendering
TWOCOLOR: Optimized for displays with two-color sections (e.g., yellow header, blue body)
INVERTED: Inverted colors (white background, dark text)
COLOR: Full color mode for color displays

Effect: Adjusts rendering for different display types and preferences.

Heading Bold

Description: Render heading/title text in bold.

Effect: Makes headers more prominent on the display.

Wake on Tap or Motion

Description: Wake the screen when device detects tap or motion.

Effect: Uses accelerometer (if present) to wake display.

Side Effects: May cause unwanted wake-ups from vibration; increases power consumption slightly

Compass Orientation

Description: Rotation offset for the compass heading display.

Options: 0, 90, 180, 270 degrees

Effect: Adjusts compass heading to match physical device orientation.

Use Cases: When device is mounted at an angle from its default orientation

Meshtastic Display Configuration

Telemetry Configuration

Configure telemetry data collection and broadcasting for environmental sensors, device metrics, and power monitoring.

Device Telemetry

Device Update Interval

Description: How often to broadcast device metrics (battery, voltage, uptime, etc.).

Range: 0-4294967295 seconds

Default: 1800 seconds (30 minutes)

Effect: Controls frequency of device health broadcasts.

Side Effects:

Shorter intervals: More current data, higher network traffic
Longer intervals: Less traffic, potentially stale readings

Environment Telemetry

Configure environmental sensor (temperature, humidity, pressure, etc.) reporting.

Environment Measurement Enabled

Description: Enable collection of environmental sensor data.

Effect: Activates any connected environmental sensors (BME280, BMP280, DHT22, etc.).

Side Effects: Increases power consumption when sensors are actively reading

Environment Update Interval

Description: How often to broadcast environmental sensor data.

Range: 0-4294967295 seconds

Default: 1800 seconds (30 minutes)

Effect: Controls frequency of environment data broadcasts.

Environment Screen Enabled

Description: Show environmental data on the device screen.

Effect: Adds a screen page displaying temperature, humidity, and pressure readings.

Display Fahrenheit

Description: Show temperature in Fahrenheit instead of Celsius.

Effect: Changes temperature display format on device screen.

Note: Does not affect the transmitted data (always sent in Celsius internally)

Air Quality Monitoring

Configure air quality sensor (particulate matter) reporting.

Air Quality Enabled

Description: Enable air quality sensor data collection.

Effect: Activates connected air quality sensors (PM2.5, PM10, etc.).

Air Quality Interval

Description: How often to broadcast air quality data.

Range: 0-4294967295 seconds

Effect: Controls frequency of air quality data broadcasts.

Power Metrics

Configure power monitoring for nodes with power metering hardware.

Power Measurement Enabled

Description: Enable power consumption/generation monitoring.

Effect: Activates power monitoring sensors (INA219, INA226, etc.).

Use Cases:

Solar power monitoring
Battery charge/discharge tracking
Power consumption analysis

Power Update Interval

Description: How often to broadcast power metrics.

Range: 0-4294967295 seconds

Effect: Controls frequency of power data broadcasts.

Power Screen Enabled

Description: Show power metrics on the device screen.

Effect: Adds a screen page displaying power consumption/generation data.

Meshtastic Telemetry Module

Network Configuration

Configure network settings including WiFi, NTP, and static IP addresses.

WiFi Configuration

WiFi Enabled

Description: Enable WiFi connectivity on the device.

Effect: Activates the WiFi radio for network connectivity.

Side Effects:

Increased power consumption
Enables web interface access
Required for MQTT over WiFi

WiFi SSID

Description: Network name to connect to.

Maximum Length: 32 characters

Effect: Specifies the wireless network for connection.

WiFi Password

Description: Password for the WiFi network.

Security: Stored on device; included in configuration backups

NTP Configuration

NTP Server

Description: Network Time Protocol server address for time synchronization.

Default: meshtastic.pool.ntp.org (NodeDB.cpp)

Maximum Length: 32 characters (the nanopb buffer is 33 bytes including the NUL terminator)

Effect: Configures where the device gets accurate time when connected to the internet.

Use Cases:

Accurate timestamps on messages
Synchronized logging
Time-sensitive applications

Static IP Configuration

Address Mode

Options:

DHCP: Obtain IP address automatically from the network
STATIC: Use manually configured IP address

Effect: Controls how the device obtains its network address.

IPv4 Address

Description: Static IP address for the device (when using STATIC mode).

Format: 192.168.1.100 (dotted decimal)

IPv4 Gateway

Description: Network gateway address (router IP).

Format: 192.168.1.1 (dotted decimal)

IPv4 Subnet

Description: Network subnet mask.

Format: 255.255.255.0 (dotted decimal)

Common Values: 255.255.255.0 for /24 networks

IPv4 DNS

Description: DNS server address for name resolution.

Format: 8.8.8.8 (dotted decimal)

Common Options: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare)

Meshtastic Network Configuration

MQTT Configuration

Enable MQTT

Description: Connect your Meshtastic device to an MQTT broker for internet connectivity.

Effect: Allows messages to bridge between your local mesh and other mesh networks via the internet.

Use Cases:

Connecting multiple mesh networks
Internet gateway functionality
Remote monitoring and control
Integration with home automation systems

Broker Preset

Description: A chooser above the address that fills in a known broker. It appears here, in Remote Admin's MQTT section, and in an MQTT bridge source's Settings.

Preset	Address	TLS	Username / Password
Meshtastic Official	`mqtt.meshtastic.org` (port 1883)	off	`meshdev` / `large4cats`
Meshtastic Official (TLS)	`mqtt.meshtastic.org` (port 8883)	on	`meshdev` / `large4cats`
Custom…	your own	your own	your own

Effect: Choosing a preset only edits the form. Nothing reaches the device until you press Save, and Save works as it always has (the device may reboot). A preset sets the address, TLS and login, and leaves root topic, encryption, JSON, client proxy, map reporting and channel uplink/downlink alone.

Login rule: A preset fills the username and password only when they are empty. If you already have a login, it stays, and a note under the chooser tells you the public login so you can type it in.

Which one is selected: The chooser shows the preset your saved settings already match. An empty address counts as the official broker, because that is what the firmware uses when no address is set. Anything else shows Custom….

Finding a regional broker: There is no list of community brokers. Local groups run and publish their own, so the chooser links to the Meshtastic Local Groups list and the MeshMonitor Site Gallery. MeshMonitor does not read or copy either list.

Public broker

Every channel with uplink on publishes its traffic to the broker. On the public broker, anyone on the internet can read it. See Meshtastic's public MQTT server rules.

MQTT Address

Description: Hostname or IP address of the MQTT broker. Leave it empty to use the default public server (mqtt.meshtastic.org).

Format: hostname:port or ip:port

Example: mqtt.example.com:1883

MQTT Username & Password

Description: Credentials for authenticating with the MQTT broker.

Effect: Required if your MQTT broker uses authentication.

Security: Credentials are stored on the device

MQTT Encryption

Description: Send packets to MQTT still encrypted with the channel key, instead of decrypted.

Effect: Only clients holding the channel key can read the packets on the broker. This is separate from TLS, which protects the connection itself.

MQTT JSON

Description: Enable JSON encoding for MQTT messages.

Effect: Messages are sent in JSON format instead of protobuf.

Use Cases:

Integration with systems that expect JSON
Easier debugging and monitoring
Home automation systems

Side Effects: Larger message size compared to protobuf

TLS Enabled

Description: Enable TLS/SSL encryption for the MQTT connection.

Recommendation: Always enable for public/internet MQTT brokers.

Effect: Encrypts all MQTT traffic between the device and broker.

Side Effects: Slightly higher power usage due to encryption overhead.

MQTT Root Topic

Description: Base topic for MQTT messages.

Default: msh/

Effect: Customizes the MQTT topic hierarchy.

Use Cases: Running multiple independent mesh networks on same MQTT broker

Proxy to Client (Client Proxy Mode)

Description: Route MQTT traffic through a connected client application instead of directly from the node's WiFi.

Effect: Instead of the node connecting directly to the MQTT broker, it sends MQTT packets to a connected client (mobile app, MeshMonitor, etc.) which then forwards them to the broker.

Use Cases:

Nodes with unreliable WiFi (T-Deck, portable devices)
Serial or BLE-connected nodes that don't have WiFi
Centralized MQTT management through your server
More reliable connectivity via Docker containers with health checks

MeshMonitor Integration

With this option on, the node opens no broker connection of its own, so something must carry MQTT for it. Pick one:

A linked MQTT source. Pick an embedded broker or MQTT bridge in Quick configure from a MeshMonitor MQTT source at the top of this section, then save: the save sends the node its MQTT settings and links the sources. MeshMonitor then carries the traffic itself.
The MQTT Client Proxy sidecar, a separate container by LN4CY attached to the source's Virtual Node.

With neither, the node gets no MQTT traffic. MeshMonitor warns you here and on the source's dashboard card.

Not seeing MQTT traffic?

See Why don't I see MQTT traffic?. The usual causes are Proxy to Client with no linked source, a channel without Downlink Enabled, or LoRa Ignore MQTT.

How It Works:

Node sends mqttClientProxyMessage to connected client
Client (MQTT Proxy) publishes message to MQTT broker
Client receives messages from broker and forwards to node
Same protocol used by official Meshtastic mobile apps

Map Reporting

Description: Enable periodic location reporting to the MQTT map service.

Effect: Your node's position will be published to the configured MQTT broker for map display.

Use Cases: Integration with meshmap.net or custom mapping solutions.

Map Publish Interval

Description: How often to publish location updates to the map.

Default: 0 (use system default)

Range: 0-4294967295 seconds

Map Position Precision

Description: Position precision for map reporting.

Range: 10-19 (higher = more precise)

Privacy Note: Lower precision values share less exact location data.

Neighbor Info

Enable Neighbor Info Module

Description: Automatically collect and broadcast information about neighboring nodes.

Effect: Shares data about directly connected nodes (0-hop neighbors) with the network.

Use Cases:

Network topology analysis
Understanding node connectivity
Optimizing node placement

Neighbor Info Interval

Description: How often to send neighbor information updates.

Range: 14400-86400 seconds (4 to 24 hours)

Default: 21600 seconds (6 hours) in firmware

Effect: Controls frequency of neighbor information broadcasts.

Side Effects:

Shorter intervals: More network traffic, more current data
Longer intervals: Less network traffic, potentially stale data

Meshtastic Neighbor Info Module

Canned Message Configuration

Configure pre-defined messages that can be quickly sent using hardware buttons or a rotary encoder on your Meshtastic device.

Enable Canned Messages

Description: Enable the canned message module.

Effect: Activates the canned message selection interface on devices with buttons or encoders.

Use Cases:

Quick responses without typing
Emergency messages
Status updates while mobile

Rotary Encoder

Description: Enable rotary encoder input for message selection.

Effect: Allows using a rotary dial to scroll through canned messages.

Hardware: Requires rotary encoder connected to GPIO pins

Up/Down Buttons

Description: Enable up/down button input for message selection.

Effect: Allows using physical buttons to navigate canned messages.

Send Bell

Description: Send bell character with messages.

Effect: Causes receiving devices to play an alert sound.

Use Cases: Emergency messages, urgent alerts

Allow Input Source

Description: Which input source is allowed to trigger canned messages.

Options: NONE, UP, DOWN, LEFT, RIGHT, SELECT, BACK, CANCEL

Effect: Restricts which hardware inputs can activate canned message sending.

Advanced GPIO Settings

These settings configure the physical GPIO pin connections for rotary encoders and buttons.

Pin A / Pin B

Description: GPIO pins for rotary encoder A and B signals.

Range: 0-255

Effect: Specifies which GPIO pins are connected to the rotary encoder.

Note: Consult your device's pinout diagram for available GPIO pins

Pin Press

Description: GPIO pin for the encoder press/select button.

Range: 0-255

Effect: Specifies which GPIO pin is connected to the button.

Event Mappings

Configure which navigation events are triggered by encoder rotation and button press:

Event CW: Action triggered by clockwise rotation
Event CCW: Action triggered by counter-clockwise rotation
Event Press: Action triggered by button press

Options: NONE, UP, DOWN, LEFT, RIGHT, SELECT, BACK, CANCEL

Meshtastic Canned Message Module

Store and Forward Configuration

Configure the store-and-forward module to cache and replay messages for nodes that were offline.

Enable Store and Forward

Description: Enable the store-and-forward module.

Effect: Device will cache messages and replay them to nodes that request missed messages.

Use Cases:

Ensuring message delivery to intermittently connected nodes
Mesh networks with mobile nodes
Areas with unreliable coverage

Is Server

Description: Configure this node as a store-and-forward server.

Effect: When enabled, this node actively stores messages and serves them to requesting clients.

Best Practices:

Enable on powered, always-on nodes with good mesh coverage
Only one or two servers needed per mesh network
Choose nodes with stable power and central location

Side Effects: Increases memory usage and power consumption

Heartbeat

Description: Send periodic heartbeat messages to indicate server availability.

Effect: Broadcasts server presence so clients know a store-and-forward server is available.

Side Effects: Adds periodic network traffic

Records

Description: Maximum number of messages to store.

Range: 0-65535

Effect: Limits how many messages are kept in the cache.

Best Practices:

Set based on available memory
Higher values for longer offline periods
Consider message size and available RAM

History Return Max

Description: Maximum number of messages to return in a single history request.

Range: 0-255

Effect: Limits how many messages are sent at once when a client requests history.

Best Practices: Balance between completeness and network congestion

History Return Window

Description: Maximum age of messages to return (in seconds).

Range: 0-86400 seconds (up to 24 hours)

Effect: Only returns messages newer than this time window.

Best Practices:

Set based on typical offline duration
Longer windows for nodes that go offline for extended periods
Shorter windows reduce stale message replay

Meshtastic Store and Forward Module

Status Message

The Status Message section, and the quick-status pill in the header, set the short status text your node sends to the mesh (firmware 2.7.20+, up to 79 bytes). The node applies it without a reboot and sends it about every 12 hours.

MeshMonitor confirms the node took the status: after each save it reads the status back from the node and shows an error if the node holds something else or does not answer. Other module settings are not read back.

That check covers the node's running config only. A status that vanishes after a reboot is a node-side save failure (seen on nRF52 nodes with Bluetooth up), which MeshMonitor cannot detect. Set the status again after the reboot, or turn on the option below.

Re-apply after a reboot (opt-in)

The root cause is in the node firmware: it can lose a Status Message on reboot without any error. Re-apply after a reboot works around it from MeshMonitor's side.

It is off by default, and you set it per source, under the Status Message section.
MeshMonitor remembers the last status the node confirmed. When the node connects (including after a MeshMonitor restart) with an empty status, MeshMonitor writes the remembered one once more and reads it back.
It acts only when the node's status is empty. If the node holds a different status, MeshMonitor leaves it alone and remembers that one instead.
It tries once per connection. If the node does not confirm, MeshMonitor logs a warning and does not retry until the next reconnect.
It uses local admin packets only. Nothing goes on air.
Caveat: a status you cleared from another app looks the same as a status lost in a reboot, so it would be restored too. Clear it in MeshMonitor, or turn the option off.

Quick-status pill

The pill sits in the header of a Meshtastic source. Click it to pick one of ten presets (Available, Away, Busy and so on) or type your own text, with a byte counter. Save sends it, and Clear removes it.

It shows only while the node is connected, to a signed-in user with configuration: write on the source. It hides on firmware older than 2.7.20, and on MQTT, MeshCore and Reticulum sources.
A save goes to the local node over its own link. Nothing is sent over LoRa at that moment: other nodes see the change at the node's next status broadcast, up to 12 hours later.
Clearing the status is not sent to the mesh. Other nodes keep the last status they heard.

TAK Configuration

The TAK section of Device Configuration sets the Team colour and Role the node reports to TAK clients. It needs firmware 2.8.0 or newer; on older firmware the section shows as unsupported, because that firmware drops the settings without saving them.

Team: Default (Cyan), White, Yellow, Orange, Magenta, Red, Maroon, Purple, Dark Blue, Blue, Cyan, Teal, Green, Dark Green or Brown.
Role: Default (Team Member), Team Member, Team Lead, HQ, Sniper, Medic, Forward Observer, RTO or K9.

The node sends its team and role only when its device role is TAK_TRACKER. With any other role the values are stored but not used. Saving reboots the node. The same section is on the Admin Commands tab for remote nodes. See ATAK / CoT Integration for how MeshMonitor shows TAK traffic.

Security Configuration

The Security section of Device Configuration shows the local node's public key and its private key (masked). The public key is what other nodes use to send you PKI-encrypted direct messages.

Set Private Key

Added in 4.14.1 (#4632)

The private key is copy-only until you click Set private key, which clears the field for a paste.

Setting the private key lets you restore a node's identity from a backup or migrate it onto replacement hardware, matching the official Meshtastic apps. When you save a changed key, MeshMonitor derives the matching public key from it and writes both together, so the node can never be left advertising a public key that no longer matches its secret (which would silently break PKI DMs to it).

Local device only. The private key can only be set on the directly-connected node, never through remote admin.
Validated before it reaches the device. The key must be base64 of a 32-byte X25519 scalar; anything else is rejected on both the client and the server.
Confirmation required. Saving a changed key requires acknowledging a dialog that spells out the identity change and the impersonation / duplicate-key risk. Cancel restores the loaded key.

WARNING

Whoever holds a node's private key can impersonate it. Only paste a private key you own, on a trusted machine, and never share it.

Protection Level (packet authenticity)

Firmware 2.8.0 added a packet signature policy. The Protection Level picker in the Security section sets how the node treats packets it cannot prove came from their sender.

Level	What the node accepts
Compatible (firmware default)	Unsigned packets. A signature that can be checked and is wrong still drops the packet. Works with every firmware version.
Balanced	Unsigned packets, except an unsigned broadcast from a node that has sent a signed one before.
Strict	Only packets with a verified signature, and PKI-encrypted direct messages.

The picker is locked when the node runs firmware older than 2.8.0, when its firmware version is not known, or when its current level could not be read. Load the security config first.
Moving to Balanced or Strict asks you to confirm. Saving the security config reboots the node.
Firmware signs broadcasts only. A Strict node drops everything from nodes older than 2.8 except PKI direct messages, and from 2.8 nodes it drops packets sent to one node on a channel (traceroute replies, ACKs, legacy admin-channel messages) and broadcasts too large to carry a signature. A Strict router is likely to stop relaying that traffic for others too.
The same picker is on the Admin Commands tab. Strict on a remote node you reach through older peers can cut it off, and you may not be able to change it back from MeshMonitor.

A Security save that leaves the picker alone keeps the node's level. MeshMonitor reads the security config from the node before it writes, and sends nothing if the node does not answer.

Authenticated encryption (AEAD) channels

A channel with the firmware's AES-CCM authenticated encryption turned on shows an AEAD badge in the Channels tab and in the channel list under Device Configuration. Only nodes with the same setting can read such a channel. MeshMonitor shows the flag and keeps it when you edit, import or export the channel. It has no control to turn it on or off.

Applying Changes

All configuration changes require clicking the "Save" button in each section. Most changes also require a device reboot to take effect. MeshMonitor will notify you when a reboot is required.

You can clear a number field while you edit it. A blank or out-of-range field gets an outline and a message, and Save stays off until every number on the form is valid. A field that shows 0 where 0 has a special meaning says under it what 0 means and what a save sends.

Troubleshooting

Configuration Not Saving

Ensure you have a stable connection to the Meshtastic device
Check that the device is powered and responsive
Verify you have appropriate permissions

Device Disconnected After Changes

Some configuration changes (especially LoRa settings) may temporarily disconnect the device
Wait 30-60 seconds for the device to reboot and reconnect
If device doesn't reconnect, verify the configuration is compatible with your mesh network

Can't Communicate After Region Change

Ensure region matches other nodes in your mesh
Verify the frequency is legal in your location
Check that modem preset is compatible

Device Configuration Backup

MeshMonitor provides comprehensive backup functionality that exports your complete device configuration in a format fully compatible with the official Meshtastic CLI --export-config command.

What Gets Backed Up

The backup export includes your complete device configuration:

Device Settings: Node identity, role, timezone, broadcast intervals
LoRa Radio: Modem preset, region, bandwidth, spreading factor, coding rate, hop limit, TX power
Position: GPS settings, broadcast intervals, smart position, fixed position coordinates
Power: Battery management, sleep settings, shutdown behavior
Network: WiFi credentials, Bluetooth settings
Security: Device keys (encrypted)
MQTT: Broker settings, encryption, topics, credentials
Module Configuration: All enabled modules (telemetry, neighbor info, canned messages, detection sensor, etc.)
Channel Configuration: All channels with encryption keys (encoded in channel URL)

Backup Features

Automated Backups

MeshMonitor can automatically create backups on a daily schedule:

Open Device Configuration → Backup (the Device Backup Management section)
Check Enable Automatic Backups
Set the Daily Backup Time (server time zone)
Set Maximum Backups to Keep (1-365)
Click Save Backup Settings

Automated backups are stored in the /data/backups/ directory with filenames in the format:

{nodeId}-{timestamp}.yaml

Example: 43588558-2025-10-28-12-34-18.yaml

Manual Backups

To create an on-demand backup:

Open Device Configuration → Backup (the Device Backup Management section)
Click Create Backup Now
MeshMonitor saves the backup on the server and downloads a copy to your computer

Show Saved Backups lists the stored files, each with Download, Restore and Delete.

Backup File Format

Backups are saved in YAML format and are fully compatible with the official Meshtastic CLI. The format matches the output of:

bash

meshtastic --export-config output.yaml

This means you can use MeshMonitor backups interchangeably with backups created by the official Meshtastic tools.

Example backup structure:

yaml

# start of Meshtastic configure yaml
channel_url: https://meshtastic.org/e/#ChASAQE...
config:
  bluetooth:
    enabled: false
    fixedPin: 123456
  device:
    nodeInfoBroadcastSecs: 10800
    role: CLIENT_MUTE
    tzdef: EST5EDT,M3.2.0/2:00:00,M11.1.0/2:00:00
  lora:
    modemPreset: MEDIUM_FAST
    region: US
    hopLimit: 5
  position:
    fixedPosition: true
    positionBroadcastSecs: 1800
location:
  lat: 26.333431
  lon: -80.267695
  alt: 5.0
module_config:
  mqtt:
    enabled: true
    address: mqtt.example.com
owner: My Node Name
owner_short: MNN

Restoring Configuration from Device Backup Management

New in 4.15.2. Every backup listed under Device Configuration → Backup → Show Saved Backups carries a Restore button. Restore is a local, per-source, verbatim replay of the saved YAML back onto whichever device this source is currently connected to. MeshMonitor sends each config chunk in the same order it exported them (device, module, channels), then asks the device to reboot to apply the changes; a banner in the panel surfaces the reboot notice directly from the "did-reboot" flag on the response, so the UI never claims a reboot happened that the device didn't do.

Behavior:

Local device only — restore targets the device on the current source, not another node on the mesh. Cross-node config transfers still need the Meshtastic CLI recipe below.
Verbatim replay — every field in the backup is sent, including the encryption keys, WiFi passwords, and channel URLs. Restore does not merge or diff.
Bluetooth is handled separately — Bluetooth configuration has its own setter path, so the panel offers a Bluetooth restore too.
configuration:write on the source is required. The server refuses a restore without it.

Restoring Configuration with Meshtastic CLI

You can restore a MeshMonitor backup to any Meshtastic device using the official Meshtastic CLI tools.

Prerequisites

Install the Meshtastic Python CLI:
bash
```
pip install meshtastic
```
1
Connect your device:
- USB/Serial: Connect device via USB cable
- Network: Ensure device is on same network
- Bluetooth: Enable Bluetooth on your computer

Restore Process

Using USB/Serial Connection:

bash

meshtastic --configure backup.yaml

The CLI will automatically detect your connected device and apply the configuration.

Using Network Connection:

bash

meshtastic --host 192.168.1.100 --configure backup.yaml

Replace 192.168.1.100 with your device's IP address.

Using Bluetooth:

bash

meshtastic --ble "Device Name" --configure backup.yaml

What Happens During Restore

When you restore a configuration:

Device receives configuration: All settings are sent to the device
Channels are configured: The channel URL is decoded and all channels are set up with encryption keys
Device reboots: The device automatically reboots to apply changes
Settings take effect: After reboot, device operates with restored configuration

Backup Encryption Keys

The backup includes your device's encryption keys and WiFi passwords. Store backup files securely and never share them publicly. Anyone with access to your backup file can decrypt messages from your mesh network and connect to your WiFi.

Restore Behavior

What Gets Overwritten

When restoring a backup, these settings are completely replaced:

Device identity (names)
LoRa radio settings
All module configurations
Channel settings and encryption keys
WiFi and Bluetooth settings

What Doesn't Change

These items are not affected by restore:

Device hardware model
Firmware version
MAC address
Any locally stored messages or telemetry data

Partial Restore

You can manually edit the YAML backup file to restore only specific sections:

Open the backup file in a text editor
Delete the sections you don't want to restore
Save the modified file
Run the restore command

For example, to restore only LoRa settings, keep only the config.lora section.

Best Practices

Regular Backups

Enable automated backups to protect against configuration loss
Create manual backups before making significant configuration changes
Keep backups after firmware updates in case you need to rollback

Backup Storage

Store backups in multiple locations (local computer, cloud storage, USB drive)
Keep backups from different time periods (don't immediately delete old backups)
Consider encrypting backups if storing in cloud services

Before Restoring

Verify the backup file is for the correct device or a compatible model
Review the backup contents to ensure it has the settings you want
Make a backup of the current configuration before restoring
Ensure the device has adequate power (battery or connected to power)

After Restoring

Wait for the device to fully reboot (30-60 seconds)
Verify critical settings like region and channel configuration
Test connectivity with other mesh nodes
Check that module configurations are working as expected

Troubleshooting

Restore Fails or Hangs

Ensure device is powered and responding
Check USB cable connection quality
Try using --port /dev/ttyUSB0 (Linux/Mac) or --port COM3 (Windows) to specify port
Verify Python and meshtastic CLI are up to date:
bash
```
pip install --upgrade meshtastic
```
1

Device Won't Reconnect After Restore

Wait 60-90 seconds for full reboot cycle
If using WiFi, the restored WiFi settings may be different
Try connecting via USB/serial instead
Check if region settings are compatible with your local regulations

Configuration Partially Applied

Some settings may require multiple reboots to fully take effect
Channels in particular may need an extra reboot
Power cycle the device completely (disconnect power/battery) and reconnect

"Invalid Configuration" Error

Verify the backup YAML file is not corrupted
Check that the backup is from a compatible firmware version
Ensure the backup file follows proper YAML formatting
Try restoring individual sections instead of the complete file

Use Cases

Device Replacement

When replacing a failed device:

Restore your backup to the new device
The new device will have identical configuration
Channels and encryption keys will match your network
No manual reconfiguration needed

Multiple Identical Nodes

To deploy multiple nodes with the same configuration:

Configure one node as a template
Export its configuration
Edit the backup to change node name/ID for each device
Restore to each new device

Configuration Templates

Create backup templates for different use cases:

router-template.yaml - Settings for infrastructure nodes
mobile-template.yaml - Settings for handheld devices
sensor-template.yaml - Settings for sensor nodes

Testing and Development

Backup production configuration
Test experimental settings
Restore original config if tests fail
No need to manually track settings changes

Firmware Updates

Device Configuration → Firmware Updates is the last section, after Backup. It updates the node over Wi-Fi and is admin-only. It appears only when OTA is enabled, and not on MQTT sources. For hardware MeshMonitor cannot flash (a Linux meshtasticd node, a simulator, a node that reports no hardware model, or a board it has no firmware build for), a card explains why in place of the update controls. See Firmware OTA Updates and its list of hardware that cannot be updated here.

Settings - Learn about MeshMonitor settings and backup automation
Automatic Responses - Configure the standing automation behaviours
Meshtastic Official Documentation
Meshtastic CLI Documentation

Device Configuration ​

Node Identity ​

Long Name ​

Short Name ​

Unmessagable Nodes ​

Related Meshtastic Documentation ​

Device Configuration ​

Device Role ​

CLIENT (Default) ​

CLIENT_MUTE ​

ROUTER ⚠️ ​

TRACKER ​

SENSOR ​

TAK ​

CLIENT_HIDDEN ​

LOST_AND_FOUND ​

TAK_TRACKER ​

ROUTER_LATE ​

CLIENT_BASE ​

Node Info Broadcast Interval ​

Related Meshtastic Documentation ​

LoRa Radio Configuration ​

Use Preset ​

TX Enabled ​

Manual LoRa Parameters ​

Bandwidth ​

Spreading Factor ​

Coding Rate ​

Frequency Offset ​

Modem Preset ​

Which presets the picker shows ​

Custom Parameter Recipes ​

Region ​

Hop Limit ​

Channel Number ​

RX Boosted Gain (SX126x) ​

Related Meshtastic Documentation ​

Position Configuration ​

Position Broadcast Interval ​

Smart Position ​

Fixed Position ​

Related Meshtastic Documentation ​

Power Configuration ​

Power Saving Mode ​

Shutdown After (Battery) ​

ADC Multiplier Override ​

Wait Bluetooth Seconds ​

SDS (Deep Sleep) Seconds ​

LS (Light Sleep) Seconds ​

Minimum Wake Seconds ​

Battery INA Address ​

Related Meshtastic Documentation ​

Display Configuration ​

Screen On Seconds ​

Auto Screen Carousel Seconds ​

Flip Screen ​

Measurement Units ​

OLED Type ​

Display Mode ​

Heading Bold ​

Wake on Tap or Motion ​

Compass Orientation ​

Related Meshtastic Documentation ​

Telemetry Configuration ​

Device Telemetry ​

Device Update Interval ​

Environment Telemetry ​

Environment Measurement Enabled ​

Environment Update Interval ​

Environment Screen Enabled ​

Display Fahrenheit ​

Air Quality Monitoring ​

Air Quality Enabled ​

Air Quality Interval ​

Power Metrics ​

Power Measurement Enabled ​

Power Update Interval ​

Power Screen Enabled ​

Related Meshtastic Documentation ​

Network Configuration ​

Device Configuration

Node Identity

Long Name

Short Name

Unmessagable Nodes

Related Meshtastic Documentation

Device Configuration

Device Role

CLIENT (Default)

CLIENT_MUTE

ROUTER ⚠️

TRACKER

SENSOR

TAK

CLIENT_HIDDEN

LOST_AND_FOUND

TAK_TRACKER

ROUTER_LATE

CLIENT_BASE

Node Info Broadcast Interval

Related Meshtastic Documentation

LoRa Radio Configuration

Use Preset

TX Enabled

Manual LoRa Parameters

Bandwidth

Spreading Factor

Coding Rate

Frequency Offset

Modem Preset

Which presets the picker shows

Custom Parameter Recipes

Region

Hop Limit

Channel Number

RX Boosted Gain (SX126x)

Related Meshtastic Documentation

Position Configuration

Position Broadcast Interval

Smart Position

Fixed Position

Related Meshtastic Documentation

Power Configuration

Power Saving Mode

Shutdown After (Battery)

ADC Multiplier Override

Wait Bluetooth Seconds

SDS (Deep Sleep) Seconds

LS (Light Sleep) Seconds

Minimum Wake Seconds

Battery INA Address

Related Meshtastic Documentation

Display Configuration

Screen On Seconds

Auto Screen Carousel Seconds

Flip Screen

Measurement Units

OLED Type

Display Mode

Heading Bold

Wake on Tap or Motion

Compass Orientation

Related Meshtastic Documentation

Telemetry Configuration

Device Telemetry

Device Update Interval

Environment Telemetry

Environment Measurement Enabled

Environment Update Interval

Environment Screen Enabled

Display Fahrenheit

Air Quality Monitoring

Air Quality Enabled

Air Quality Interval

Power Metrics

Power Measurement Enabled

Power Update Interval

Power Screen Enabled

Related Meshtastic Documentation

Network Configuration