# Device Roles — All 12

# Personal Device Roles

Personal roles are designed for individual users who want to send and receive messages. They vary in how aggressively the device relays messages for others.

**Important:** Your role choice affects everyone on the network. The Meshtastic project's guidance is clear: only assign Router or Repeater roles to nodes with genuinely excellent placement and reliable continuous power. Do not assign infrastructure roles to personal devices for convenience.

## Client (Default)

**Behavior:** Sends and receives messages via the app. Rebroadcasts a packet (managed flood routing) only when no other node has already rebroadcast it after the node has heard it once - it does not pick a single "best-positioned" relay.

**Use for:** Most personal handhelds and portable nodes. This is the correct default for the majority of users.

## Client Mute

**Behavior:** Fully participates in messaging but *never* relays packets for other nodes.

**Use for:** Dense environments (city centers, events, conferences) where the channel is congested and adding another relay would make things worse. Client Mute is underappreciated - in a high-density network, switching personal devices to Client Mute can dramatically reduce channel utilization without losing any personal messaging capability.

## Client Hidden

**Behavior:** Suppresses periodic NodeInfo broadcasts. The node participates in messaging but does not regularly announce its existence, so it is less likely to appear in other users' node lists. (This role is firmware-version dependent.)

**Use for:** Privacy-conscious users who prefer not to be listed in others' node lists. **This is not a covert or anti-detection mode** - the node still transmits identifiable plaintext packet headers whenever it sends, so anyone monitoring RF can see the node when it transmits. It reduces directory visibility, not radio detectability, and metadata can still reveal the node.

## Choosing the Right Personal Role

<table id="bkmrk-situationrecommended"> <thead><tr><th>Situation</th><th>Recommended Role</th></tr></thead> <tbody> <tr><td>Default personal use</td><td>Client</td></tr> <tr><td>Dense urban area or event with congestion</td><td>Client Mute</td></tr> <tr><td>Reduce node-list visibility</td><td>Client Hidden</td></tr> </tbody></table>

# Infrastructure Roles: Router and Repeater

Infrastructure roles are for **fixed, well-placed nodes** that genuinely improve mesh coverage for others. They should only be assigned to nodes that meet strict criteria. Misuse of these roles is a common cause of network congestion and poor performance.

## Prerequisites for Any Infrastructure Role

1. **Excellent placement** - hilltop, tower, rooftop, or other elevated location with line-of-sight coverage over a wide area
2. **Reliable continuous power** - mains power, solar with battery backup, or other reliable source. An infrastructure node that goes offline unpredictably is worse than no node at all.
3. **Genuine improvement** - the node must provide coverage that no other node provides, not just duplicate existing relay coverage

## Router

**Behavior:** Always rebroadcasts each packet once, using prioritized routing. Visible in the node list and broadcasts its own position. On ESP32 boards the ROUTER role force-enables power-saving sleep and defaults BLE/WiFi/Serial off, but the node still appears in the node list. (Older firmware used an "aggressive/early" rebroadcast timing; current firmware no longer gives ROUTER a privileged fast contention window, so it does not "win" the relay race by speed.)

**Use for:** Primary hilltop/tower relays with the best possible placement. There should be few Router nodes on a regional network - one or two per coverage area at most.

**Do not use for:** Personal devices, nodes at ground level, nodes with intermittent power.

## Router Late

**Behavior:** Always rebroadcasts each packet once, but only after all other nodes have had a chance to relay it. If another node has already relayed the packet, Router Late stays silent. If no other relay has forwarded the packet, Router Late steps in as backup coverage. (ROUTER\_LATE is only available on newer firmware; on older builds it will not appear in the role list.)

**Use for:** Secondary or backup relay nodes that should only fill gaps. Useful in areas where primary coverage exists but is occasionally blocked or offline.

## Repeater

**Behavior:** Silent relay. Does *not* appear in node lists and does *not* originate NodeInfo, position, or telemetry. Solely forwards packets, rebroadcasting each one once at the same elevated (prioritized) routing priority as Router. Maximally efficient - no overhead from presence or telemetry. **Note:** the REPEATER role is deprecated as of firmware 2.7.11; for most infrastructure nodes prefer ROUTER (or ROUTER\_LATE).

**Use for:** Infrastructure relays where you want maximum forwarding efficiency with zero network overhead. Ideal for rooftop nodes in a managed deployment where you know the node is working from external monitoring rather than node-list visibility.

**Caution:** Because a Repeater is invisible in node lists, it can be difficult to diagnose remotely. Use an admin channel for remote configuration if deploying Repeater-role nodes.

## Router vs. Repeater: Which to Choose?

<table id="bkmrk-attributerouterroute"> <thead><tr><th>Attribute</th><th>Router</th><th>Router Late</th><th>Repeater</th></tr></thead> <tbody> <tr><td>Visible in node list</td><td>Yes</td><td>Yes</td><td>No</td></tr> <tr><td>Broadcasts position</td><td>Yes</td><td>Yes</td><td>No</td></tr> <tr><td>Relay timing</td><td>Standard (prioritized routing)</td><td>Late (backup)</td><td>Standard (prioritized routing)</td></tr> <tr><td>Network overhead</td><td>Moderate</td><td>Moderate</td><td>Minimal</td></tr> <tr><td>Best for</td><td>Primary hilltop relay</td><td>Backup coverage</td><td>High-efficiency fixed relay</td></tr> </tbody></table>

## Setting the Role via CLI

```
meshtastic --set device.role ROUTER
meshtastic --set device.role ROUTER_LATE
meshtastic --set device.role REPEATER
```

Role values are bare enum names (`CLIENT`, `CLIENT_MUTE`, `CLIENT_HIDDEN`, `ROUTER`, `ROUTER_LATE`, `REPEATER`, `TRACKER`, `SENSOR`, ...). There is no `_ROLE` suffix - `ROUTER_ROLE`, `REPEATER_ROLE`, etc. will fail with an invalid-value error. The old `ROUTER_CLIENT` role was retired in firmware 2.3.15.

# Specialized Roles

Specialized roles optimize node behavior for specific use cases: tracking, sensing, and tactical operations. Each role adjusts transmission priority and sleep/retransmit behavior to match its intended function; telemetry cadence is configured separately in the Telemetry module.

## Tracker

**Behavior:** Transmits high-priority location updates. Position packets from Tracker nodes are given higher relay priority, which improves but does not guarantee delivery under congestion.

**Use for:** Personnel or vehicle tracking where real-time position data is critical. Common in search-and-rescue, outdoor event management, and field team coordination.

## Lost and Found

**Behavior:** Broadcasts its location as a text message to the default channel at regular intervals, allowing a lost asset or person to be located when the broadcast is received.

**Use for:** Asset tags, pet trackers, equipment that is rarely moved but may need to be located. Lost and Found uses Regular power (it is not a low-power role).

## Sensor

**Behavior:** Sends sensor readings at defined intervals and deep-sleeps between reports to minimize power consumption. Optimized for battery-powered environmental monitors.

**Use for:** Temperature/humidity sensors, weather stations, soil moisture monitors, or any application where the node sends data periodically and does not need to be interactive between readings.

Configure the sensor reporting interval in the Telemetry module settings to match your battery budget.

## TAK (Android Team Awareness Kit)

**Behavior:** Optimized for integration with ATAK (Android Team Awareness Kit) tactical software. Formats and prioritizes packets for compatibility with TAK workflows.

**Use for:** Public safety, military, or emergency management teams using ATAK for situational awareness. Requires ATAK installed on the controlling device.

## TAK Tracker

**Behavior:** High-priority position tracking variant for ATAK. Combines the position prioritization of Tracker with TAK-specific packet formatting.

**Use for:** Individual team members in a TAK-based deployment where real-time position is critical to the tactical picture.

## Roles at a Glance

<table id="bkmrk-rolecategorykey-beha"> <thead><tr><th>Role</th><th>Category</th><th>Key Behavior</th></tr></thead> <tbody> <tr><td>Client</td><td>Personal</td><td>Default. Rebroadcasts via managed flooding; visible in the node list.</td></tr> <tr><td>Client Mute</td><td>Personal</td><td>Never relays. For dense/congested areas.</td></tr> <tr><td>Client Hidden</td><td>Personal</td><td>Broadcasts only as needed; not shown in the nodes list; for stealth/low-power deployments.</td></tr> <tr><td>Tracker</td><td>Specialized</td><td>High-priority location updates.</td></tr> <tr><td>Lost and Found</td><td>Specialized</td><td>Periodic location broadcast to the default channel (Regular power).</td></tr> <tr><td>Sensor</td><td>Specialized</td><td>Sensor readings + deep sleep between reports.</td></tr> <tr><td>TAK</td><td>Tactical</td><td>ATAK-optimized messaging.</td></tr> <tr><td>TAK Tracker</td><td>Tactical</td><td>Priority tactical position for ATAK.</td></tr> <tr><td>Router</td><td>Infrastructure</td><td>Always rebroadcasts once with prioritized routing; best on elevated/strategic sites; visible in the nodes list.</td></tr> <tr><td>Router Late</td><td>Infrastructure</td><td>Backup relay; waits for others first.</td></tr> <tr><td>Repeater</td><td>Infrastructure</td><td>Silent relay; no node list presence. Deprecated as of firmware 2.7.11 - use Router for new infrastructure.</td></tr> </tbody></table>