Meshtastic features

A practical guide to the modules and integrations that turn a basic text mesh into a useful community network.

A Meshtastic network can do considerably more than exchange short text messages. Nodes can report their own battery condition, carry readings from environmental sensors, describe which radios they hear directly, trace one observed path through the mesh, recover recent messages and exchange small packets with external systems. These functions are useful, but none is free. Every packet occupies shared LoRa airtime, every integration introduces another component to maintain, and some modules are deliberately limited by hardware or firmware.

This series explains the features most relevant after a community has built a stable core network. It is not a checklist of options that should all be enabled. A healthy public mesh normally starts with restrained traffic and adds a feature only when operators can state who needs it, which nodes will provide it, how often it will transmit and who will maintain the resulting data or hardware.

The feature layers

Feature	Main purpose	Main cost or limitation
Telemetry	Device health, power and sensor readings	Periodic airtime and sensor calibration
Neighbor Info	Reports direct neighbors and link SNR	Optional topology traffic; not routing control
Traceroute	Observes the path of one request and response	A snapshot, affected by encryption and packet duplication
Store and Forward	Replays missed text history	Requires suitable always-on hardware; bursts of traffic
Standalone messaging	Operates without a phone	Input and interface depend on the device
ATAK/TAK	Carries selected CoT data	Low bandwidth; Android and plugin dependencies
Serial and alarms	Interfaces with sensors and external devices	Electrical integration and safety responsibility
Remote administration	Reads and changes remote configuration	Cannot repair loss of power, radio or firmware

Start with a purpose, not a module

A mountaintop solar node may need device and power telemetry so its steward can detect a declining battery. It probably does not need frequent weather reports, Neighbor Info over LoRa, a Store and Forward heartbeat and experimental GPIO control at the same time. A field team may benefit from ATAK position exchange, while a public regional mesh may obtain more value from quiet, reliable text service.

For each proposed feature, define the producer, consumers, interval, channel, retention and failure mode. Decide whether its packets belong on the shared public channel, a coordinated private channel, MQTT only or a locally connected computer. Test the feature on a small isolated setup before enabling it on an infrastructure node.

Airtime is the common budget

LoRa offers exceptional range by trading data rate for sensitivity. The consequence is that small packets can occupy the channel for a meaningful time. Periodic telemetry from one node may seem harmless; the same interval multiplied by dozens of nodes, several metrics and multiple relays can become a network-wide load. History replay, traceroute, alarms and TAK position reports add event-driven traffic on top.

Use the longest interval that still supports the operational decision. A battery trend may be useful every thirty or sixty minutes; it rarely needs a report every minute over the public mesh. Prefer local collection or MQTT where continuous detail is required and internet connectivity is acceptable. The existing network capacity guide explains how periodic traffic multiplies through rebroadcasting.

Security and privacy are feature-specific

Channel encryption protects content from listeners who do not have the key, but participants with the key can read it. Position, neighbor relationships, alarm state and environmental data may reveal more than their short payload suggests. Remote administration uses a different trust decision: the remote node authorizes particular administrator public keys in current firmware.

Do not publish exact infrastructure locations, private-site sensor states or administration material merely because the radio can transport them. Separate public operational data from restricted maintenance records. Use a dedicated private channel for sensitive group traffic and keep private keys, channel URLs and recovery information outside public documentation.

What this series covers

Telemetry: device metrics and supported environmental, air-quality, power and health sensors.
Neighbor Info: direct-neighbor observations and topology graphs.
Traceroute: request paths, return paths, SNR and unknown hops.
Store and Forward: intermittent clients, replay limits and network impact.
Standalone messaging: screens, keyboards, rotary inputs and canned messages.
ATAK and TAK: the official Android plugin and standalone TAK trackers.
Serial devices and alarms: UART modes, detection inputs and cautious GPIO use.
Remote administration: public-key authorization, Managed Mode and recovery boundaries.

Operational principle

A feature is ready for public infrastructure only when it has an owner, a tested configuration, an airtime budget, a rollback procedure and a documented user benefit. Experimental use is welcome, but experimentation should be labeled and contained. The mesh remains a shared radio resource, not an unlimited data network.

Begin with the official Meshtastic module overview, then use the focused articles in this section to plan deployment and limits.