Advanced Meshtastic Repeater Topics

Store and Forward, position reporting, and telemetry for infrastructure repeater nodes.

Store and Forward

What Is Store and Forward?

Store and Forward (S&F) is a Meshtastic server module that buffers text messages for nodes that are temporarily offline. When a client node comes back within range, the S&F server can replay text messages the client missed while it was away.

Important - the buffer is volatile and S&F is not a delivery guarantee. Stored messages live only in the server node's PSRAM. Any reboot, brownout, or power loss on the server node erases ALL stored messages with no recovery. Replay is best-effort, request-driven, and limited by count and time window; it covers text messages only (not telemetry, position, or other packet types). Never treat the buffer as durable storage, and never rely on it for life-safety message assurance - for incident use, assume the buffer can vanish at any moment.

How It Works

  1. A node with S&F enabled in server mode listens to text messages on its primary channel (channel 0) and stores them in a ring buffer in PSRAM. Note: history retrieval over LoRa is not available on the default public channel, so the server must be configured with a non-default primary channel for S&F history to work.
  2. When a client node requests history (see Client Configuration below), it sends a replay request.
  3. The server transmits buffered messages up to the configured History Return Max count and within the History Return Window time range.

Hardware Requirements

The S&F server requires an ESP32 device with PSRAM - nRF52-based boards cannot run the Store-and-Forward server module at all:

Server Configuration

  1. Navigate to Config → Module Config → Store and Forward.
  2. Set Enabled → true.
  3. Set Is Server → true.
  4. Set History Return Max - the maximum number of messages to replay per request (default: 25 messages, which is the value used when this is left at 0).
  5. Set History Return Window - the time window in minutes from which to replay messages (default 0 = 240 minutes / 4 hours).
  6. Save and reboot the node.

Client Configuration

A client node does not need the Store and Forward module enabled to request history. To retrieve missed messages:

  1. Set role to CLIENT (or CLIENT_MUTE, labelled "Client Mute" in the app menu, if the device should not rebroadcast).
  2. Request history manually: on Android, send a direct message containing SF to the server node; on Apple, use the Client History option.

History retrieval over LoRa is manually requested as above. Automatic retrieval happens only when an app connects directly to the server node (firmware 2.4+) - it does not happen automatically over the mesh just by coming into range.

Ideal Use Cases

Limitations

Position and Telemetry for Infrastructure Nodes

Why Position Accuracy Matters

An accurate position lets your repeater appear correctly on meshmap.net and in the Meshtastic app's node list. (Note that meshmap.net is a third-party map and only shows nodes reporting to the public MQTT server, so it is not an authoritative or complete view of the mesh.) Other operators use your node's reported position to plan coverage, model signal paths, and verify that packets are actually being relayed from the expected location.

Fixed Position vs. GPS

Most unattended infrastructure repeaters do not need GPS hardware. Instead, configure a fixed position using the known coordinates of the deployment site:

  1. Look up the coordinates of your site with any map application (Google Maps, OSMand, etc.) - right-click the location and copy the lat/lon.
  2. In the Meshtastic app: Config → Position → Fixed Position → Enable.
  3. Enter the latitude, longitude, and altitude (in metres).
  4. Save. The node will broadcast this position at the configured interval without needing a GPS fix.

If your device has GPS hardware and the repeater is mobile (e.g. a vehicle relay), leave GPS enabled and set the Smart Position Broadcast threshold appropriate for your speed.

Position Broadcast Interval

This setting controls how often the node announces its location on the mesh.

Smart Position Broadcast

Meshtastic's Smart Position feature broadcasts a new position only when the node has moved beyond a configurable distance threshold. For a static repeater, disable Smart Position and use a fixed timed interval instead - Smart Position is designed for moving nodes and may behave unexpectedly on hardware without GPS.

Device Telemetry

Meshtastic can broadcast device health metrics over the mesh. The device metrics are:

Enable and configure telemetry under Module Config → Telemetry, in the Device Metrics section (exact menu labels vary by client and version). Set the broadcast interval - the default of 1800 seconds (30 minutes) is appropriate for most infrastructure nodes; lengthen it to reduce airtime.

Remote Health Monitoring

Once device telemetry is enabled, any operator who can see your node on the mesh can view its reported battery voltage and channel utilisation in the Meshtastic app's node detail view. This provides passive, no-cost status visibility:

Passive telemetry shows health only while the node is alive and in range. It provides no active alert when the node actually fails - you simply stop seeing updates, which is easy to miss. For infrastructure you depend on, pair telemetry with an active offline-detection alert (something that notifies you when telemetry stops).

For critical infrastructure nodes, consider setting up a MQTT bridge to push telemetry to an external monitoring system - see the Meshtastic MQTT documentation for details. Note that Wi-Fi/MQTT-based monitoring depends on internet connectivity and will fail in exactly the grid-down or internet-out emergencies you may most need it.