Meshtastic Node Roles Explained

A Meshtastic node role is a preset that tells a radio what kind of job it should perform. The role affects how the node rebroadcasts packets, whether it prioritizes particular traffic, which interfaces and screen features are enabled, and how it approaches power saving. It does not select the radio frequency, modem preset, or channel encryption key. Those are separate settings. Meshtastic Device Configuration

For most people, CLIENT is the correct choice. It can send and receive messages, connect to an app, appear in the node list, and help forward traffic when another node has not already done so. ROUTER is not an upgraded client. It is a high-power infrastructure role that retransmits with priority and can make a mesh worse when used at an unsuitable location. Meshtastic: Choosing the Right Device Role

This guide reflects the roles documented for the current Meshtastic firmware series. At the time of writing, GitHub lists firmware 2.7.26 Beta as the latest release. Meshtastic firmware releases

What node roles are and why they matter

All Meshtastic nodes use the same basic radio network, but different installations have different priorities.

A handheld node needs a phone connection and reasonable battery life. A GPS tracker mainly needs to wake, report a position, and sleep again. A weather station prioritizes telemetry. A carefully placed mountain relay must remain available to forward traffic, even if that consumes much more power.

Roles package sensible defaults for those jobs. The official role table describes the resulting defaults, but it also warns that individual settings may be changed after a role is selected. Official role comparison

Think of a role as a job description, not a separate network:

The role determines how your device participates.
The LoRa settings determine which compatible radio mesh it can hear.
The channels and keys determine which payloads it can decrypt.
The rebroadcast mode determines which eligible packets it is willing to forward.

A role and a channel are therefore independent. Changing from CLIENT to TRACKER does not move the node to another channel, and changing a channel key does not turn a client into a router. Device Configuration and Channel Configuration

Role comparison

The following is the current official default matrix. “Prioritized routing” means the role can receive an earlier or otherwise special opportunity to rebroadcast; it does not mean that Meshtastic builds conventional internet-style routing tables. Official role comparison

Role	BLE/Wi-Fi/Serial	Screen	Power	Retransmit	Prioritized routing	Visible in node list
`CLIENT`	Yes	Yes	Regular	Yes	No	Yes
`CLIENT_MUTE`	Yes	Yes	Lowest	No	No	Yes
`CLIENT_HIDDEN`	Yes	Yes	Lowest	Local only	No	No
`CLIENT_BASE`	Yes	Yes	Regular	Yes	Favorites only	Yes
`TRACKER`	Yes	No	Regular / low	While awake	No	Yes
`LOST_AND_FOUND`	Yes	No	Regular	Yes	No	Yes
`SENSOR`	Yes	No	Regular / low	While awake	No	Yes
`TAK`	Yes	Optional	Regular	Yes	No	Yes
`TAK_TRACKER`	Yes	Optional	Regular	Yes	No	Yes
`ROUTER`	No by default	No	High	Yes	Yes	Yes
`ROUTER_LATE`	Yes	Yes	High	Yes	No	Yes
`REPEATER`	Yes	No	High	Yes	Yes	No

CLIENT_BASE receives prioritized routing only for packets sent from or to nodes marked as favorites. TRACKER and SENSOR rebroadcast only while awake. ROUTER disables Bluetooth, Wi-Fi, and serial by default, but serial can be explicitly enabled again. Meshtastic role comparison notes

Client roles

CLIENT

CLIENT is the general-purpose role for a personal, portable, vehicle, desktop, or ordinary home node. It supports app connections and standalone messaging, appears in the node list, and participates in managed rebroadcasting. It schedules an eligible packet for retransmission, but cancels that transmission if it hears another suitable node forward the packet first. Device roles and Mesh broadcast algorithm

This “listen before duplicating” behavior is why ordinary clients can help the mesh without every nearby device retransmitting every packet.

Use it for: a first node, phone-connected handheld, normal home node, car node, or general-purpose station.

CLIENT_MUTE

CLIENT_MUTE sends and receives its own traffic but does not forward packets for other nodes. It retains BLE, Wi-Fi, serial, and screen support and has the lowest power category in the role matrix. Device roles

It is useful when several personal devices are together and there is no benefit in having all of them relay, or when a battery-powered node should participate without adding retransmissions.

Trade-off: it reduces mesh load and power use, but it contributes nothing to extending other users’ coverage.

CLIENT_HIDDEN

CLIENT_HIDDEN transmits only when needed, uses local-only retransmission behavior, consumes comparatively little power, and does not appear in the nodes list. It still supports normal client interfaces and a screen. Device roles

“Hidden” does not mean anonymous, undetectable, or cryptographically invisible. Meshtastic packet headers are not encrypted, and radio transmissions can still be observed by a receiver. Meshtastic encryption

Use it for: deployments that should minimize routine announcements and public node-list visibility.

CLIENT_BASE

CLIENT_BASE is a personal fixed base station. It always rebroadcasts packets to or from favorited nodes using the early contention window, while handling other packets like a normal CLIENT. Device roles and Demystifying ROUTER_LATE

This is the role to consider for an attic, roof, or other well-positioned home node whose main job is helping your weaker handheld or indoor nodes reach the wider mesh. It is not a general guarantee that every nearby packet will be repeated.

Use it for: a personal rooftop or attic base serving selected favorite nodes.

Tracking, sensor, and TAK roles

TRACKER

TRACKER prioritizes GPS position packets, disables the screen by default, and can use a special low-power cycle. With power saving enabled, an ESP32 or nRF52 tracker sleeps for the configured position-broadcast interval, wakes, waits for a valid GPS position, transmits it, and repeats the cycle. Its LoRa receiver does not remain listening during this special sleep. Power saving and role behavior

Use it for: hikers, vehicles, equipment, or assets whose main purpose is periodic location reporting.

LOST_AND_FOUND

LOST_AND_FOUND regularly broadcasts its location as a message on the default channel to help recover a missing device. Unlike TRACKER, the official matrix gives it regular power consumption and normal retransmission behavior. Device roles

Use it for: a device specifically configured so that other users may help locate it if lost.

SENSOR

SENSOR prioritizes telemetry packets, such as environmental measurements, and disables the screen by default. With power saving enabled on ESP32 and nRF52, it sleeps for the configured environmental update interval, wakes, gathers telemetry, transmits, and sleeps again; it cannot receive and relay packets while in that special sleep state. Power saving and role behavior

Use it for: weather, temperature, air-quality, battery, or other remote telemetry nodes.

TAK and TAK_TRACKER

TAK refers to the Team Awareness Kit ecosystem. TAK is optimized for communication through the Meshtastic ATAK plugin and reduces routine Meshtastic broadcasts. TAK_TRACKER adds automatic TAK Position Location Information (PLI) broadcasts and is intended for standalone tracking integration. Device roles

Both retain client interfaces; their screens are optional. Choose them only when the node is actually part of a TAK workflow.

Infrastructure roles

ROUTER

ROUTER is for an exceptionally well-positioned, permanently powered infrastructure node—typically a mountaintop, major tower, or similarly wide-coverage site. It always rebroadcasts eligible packets once, uses the early contention window, receives routing priority, and remains visible in the node list. Its default interfaces and screen are disabled, and its power category is high. Device roles

Because a router transmits early, ordinary clients that hear its retransmission may cancel theirs. A badly positioned router can therefore consume a hop without moving the packet far enough and suppress a better relay path. Choosing the Right Device Role

Use it for: coordinated backbone infrastructure with broad line-of-sight coverage and reliable power.

ROUTER_LATE

ROUTER_LATE is a mandatory rebroadcaster designed for a cluster hidden from the primary infrastructure by a hill, canyon, ridge, or similar obstacle. It first behaves like a client; if another node forwards the packet, it defers rather than cancels and retransmits in the late contention window. Demystifying ROUTER_LATE

It is not the recommended role for an ordinary home rooftop node. The official guidance warns that its mandatory extra retransmissions can increase congestion, collisions, and packet loss; CLIENT_BASE was designed for the personal-base use case. ROUTER_LATE rooftop guidance

Use it for: a genuine coverage pocket that must connect to a larger, coordinated mesh but is not suitable as a wide-area backbone site.

REPEATER

REPEATER is a minimal-overhead infrastructure role. It always rebroadcasts eligible packets once, receives early routing priority, disables the screen, and does not appear in the node list. It otherwise has the same high power category as ROUTER. Device roles

As of firmware 2.7.26, REPEATER is not deprecated: it remains in the official role list and current comparison table. Its special ALL_SKIP_DECODING rebroadcast mode is available only in this role and forwards without decoding packets. The documentation notes that this pairing was designed to let private and public traffic share the same infrastructure, but is seldom needed in practice. Rebroadcast mode documentation and latest firmware release

Do not choose REPEATER merely because the name sounds familiar. Its hidden identity and early, mandatory retransmission make it specialized coordinated infrastructure—not a default coverage booster.

Rebroadcast behavior settings

The role answers “what kind of node is this?” Rebroadcast mode adds a filter answering “which otherwise eligible traffic will it forward?” Official rebroadcast mode table

Mode	What it forwards	Practical implication
`ALL`	All packets using compatible modem settings, including traffic the node cannot decrypt	Default; can help neighboring meshes using the same radio parameters
`ALL_SKIP_DECODING`	Like `ALL`, but repeats without decoding	Available only with `REPEATER`
`LOCAL_ONLY`	Packets on the node’s own primary and secondary channels	Excludes open or undecryptable foreign-mesh traffic
`KNOWN_ONLY`	Local traffic only, and only from node numbers already in NodeDB	Most restrictive identity-based forwarding mode
`NONE`	No rebroadcasting	Permitted for `SENSOR`, `TRACKER`, and `TAK_TRACKER`; similar relay effect to `CLIENT_MUTE`
`CORE_PORTNUMS_ONLY`	Standard NodeInfo, Text, Position, Telemetry, and Routing packets	Excludes non-standard port numbers such as TAK, RangeTest, and PaxCounter

Compatible radio parameters do not imply access to message content. A node using ALL may forward a packet whose encrypted payload it cannot read. Meshtastic encryption

Power saving and sleep behavior

Role power labels are relative, not battery-life promises. Actual runtime also depends on the board, battery, GPS, screen, sensors, radio traffic, transmit interval, and connection use. Meshtastic recommends selecting the appropriate role before adjusting advanced power options. Power Configuration

On ESP32, every role except TRACKER and SENSOR can use traditional power.is_power_saving sleep. The CPU and peripherals sleep, BLE/Wi-Fi/GPS/serial are generally shut down, and the LoRa radio remains in standby so a received packet can wake the device. ROUTER enables this behavior automatically and does not allow it to be disabled. ESP32 role sleep behavior

On ESP32 and nRF52, TRACKER and SENSOR use their specialized interval-based sleep when power saving is enabled. Their LoRa radio does not remain available to receive packets while asleep, so they relay only while awake. Tracker and sensor sleep behavior

Do not assume an ESP32 and an nRF52 board with the same role will have identical battery life. The documented sleep mechanisms differ by platform, and hardware designs also differ.

Deprecated roles

ROUTER_CLIENT was deprecated in firmware 2.3.15. The current documentation points users to that release notice and no longer includes it in the active comparison table. Current device roles and firmware 2.3.15 release

REPEATER has not been deprecated in the current 2.7.26 documentation. Older forum discussions or planned changes should not be treated as current firmware behavior when they conflict with the active official role matrix. Latest firmware release

Which role should I pick?

Real-world deployment	Recommended starting role	Why
First device or normal home/portable node	`CLIENT`	Full user features with cooperative managed rebroadcasting
Several co-located personal devices	One `CLIENT`, others potentially `CLIENT_MUTE`	Avoids redundant local relaying
Personal attic or roof station helping your handhelds	`CLIENT_BASE`	Prioritizes traffic to and from selected favorites
Hiking location beacon	`TRACKER`	Position priority and specialized sleep cycle
Remote environmental station	`SENSOR`	Telemetry priority and interval-based sleep
Lost-device recovery beacon	`LOST_AND_FOUND`	Regular location-as-message broadcasts
Excellent mountaintop or major tower backbone site	`ROUTER`, coordinated locally	Early mandatory relaying with broad useful coverage
Isolated cluster behind a major terrain obstruction	`ROUTER_LATE`, coordinated locally	Provides a late mandatory path without preempting the backbone
Specialized invisible backbone relay	`REPEATER`, coordinated locally	Early mandatory relay without node-list visibility

The safest rule is simple: start with CLIENT. Change roles only to solve an observed problem, not to make the role name sound more important.

How role choice affects the whole mesh

Meshtastic broadcast traffic shares limited radio airtime. Managed flooding uses random delays, signal-to-noise bias, duplicate suppression, and hop limits to reduce unnecessary retransmissions. Since firmware 2.6, direct messages and broadcasts use different routing approaches, but neither creates unlimited capacity. Mesh Broadcast Algorithm

Too few useful relay nodes can leave valleys, buildings, or distant communities disconnected. Too many mandatory infrastructure nodes can make several radios repeat the same traffic, fill transmit queues, cause collisions, and waste the hop budget. ROUTER_LATE congestion guidance

Location matters more than title. A normal CLIENT on an exposed ridge may provide more useful coverage than a ROUTER inside a ground-floor room. Infrastructure roles should be selected with the local community after testing coverage, line of sight, channel utilization, and the existing network topology. Choosing the Right Device Role

Worldwide frequency note

Node roles behave the same conceptually around the world, but the legal radio region does not. A US node normally uses a North American Meshtastic region such as US, while Serbia is listed with EU_868 and EU_433; other countries use their own supported regions. The firmware’s country table is a configuration guide, not a substitute for the rules of the regulator where the transmitter is physically located. Meshtastic region-by-country table

Do not copy an EU_868 configuration onto US hardware, or a US 902–928 MHz setup onto European hardware. Frequency range, output limits, duty-cycle or channel-occupancy requirements, and permitted hardware vary by jurisdiction. US operators should check the FCC rules applicable to unlicensed intentional radiators, including 47 CFR Part 15. Users elsewhere should consult their national regulator as well as the Meshtastic region-code table.

Role selection does not override regional compliance. A ROUTER or REPEATER still has to obey the same local spectrum rules as any other node.