Device roles and profiles

Every LowMesh node has a primary role (what the device is) and a profile (how it behaves within that role).

text

Role    = what the device is
Profile = how the device behaves

A Client can use different profiles without becoming a different role.

Naming: Client is the user-facing role name. Some firmware or legacy code may still use Edge as an internal alias for Client (primaryRole == 2).

Profiles are behavior presets. They are not wire-incompatible protocol versions and not additional primary roles on the mesh.

Roles

Role	Meaning
Client	Normal user, handheld, sensor, app, GPS, or attached-device node. Not fixed infrastructure.
Repeater	Always-on relay that extends coverage. No internet/backhaul.
Gateway	Repeater plus internet/backhaul and gateway services.

Role summary (infrastructure)

Role	Relays by default	Internet	Bulletin host
Client	Only when profile allows temporary fallback	No	No
Repeater	Yes	No	Optional
Gateway	Yes	Yes	Optional/Yes

Profiles

Client profiles (user-selectable when role = Client):

Profile	Spec name	User-facing name
Standard Client Profile	Standard Client Profile	Standard
IoT Client Profile	IoT Client Profile	Sensor

Infrastructure behavior (fixed by role — not user-selectable):

Role	Internal behavior profile
Repeater	Infrastructure Relay Profile
Gateway	Gateway Profile

Profile defaults

Role / configuration	Default profile	Dynamic Repeater Mode
Client	Standard Client Profile	Enabled by default
Client configured as sensor	IoT Client Profile / Sensor Profile	Disabled by default unless explicitly enabled
Repeater	Infrastructure Relay Profile	N/A
Gateway	Gateway Profile	N/A

See Embedded storage for NVM fields such as clientProfile and dynamicRepeaterModeEnabled.

Recommended settings UI

Device role

Client
Repeater
Gateway

Client profile (when role = Client)

Standard — Messaging, GPS, apps, and normal mesh use.
Sensor — Sends data to a Gateway and listens for ACK/downlink windows.

Dynamic Repeater Mode

On by default for Standard
Off by default for Sensor

Short description for Dynamic Repeater Mode: Temporarily helps relay messages when no repeater or gateway is nearby.

Client

A Client is any non-infrastructure node: handheld, companion-connected radio, GPS unit, sensor, or app-attached device. The Client profile selects behavior; the role stays Client.

Standard Client Profile

The Standard Client Profile is the default behavior for handheld, mobile, companion-connected, GPS, messaging, and general-purpose Client devices.

A Standard Client:

Sends and receives messages, GPS, telemetry, files, app payloads, and companion traffic.
Prefers Repeaters or Gateways when available.
Does not act as fixed infrastructure.
Has Dynamic Repeater Mode enabled by default unless product/fleet policy disables it.
May temporarily relay traffic only when no Repeater or Gateway is heard.
Applies TTL limits, rate limits, randomized backoff, and duplicate suppression while temporarily relaying.
Exits temporary relay when stable infrastructure is heard again, using debounce/hysteresis rules.
Large third-party files (Tethered Payload Mode): Standard Clients typically do not maintain large local buffers for other nodes’ PAYLOAD_BODY_V2 traffic. With a USB/BLE companion, they stream via FRAME_CAPTURE and rely on the host for reassembly — see Fragmentation and USB & BLE hex API.

Dynamic Repeater Mode

Dynamic Repeater Mode is a Standard Client Profile behavior — not a separate role.

Dynamic Repeater Mode lets a Client temporarily help relay nearby traffic when no Repeater or Gateway is available. It is enabled by default for Standard Clients, but a Client still prefers fixed infrastructure when available and does not behave as an always-on Repeater.

Layer	Name
User setting	Dynamic Repeater Mode
Internal state	`TempRelay` / temporary relay state
Capability bit	`TEMP_RELAY` (or `DYNAMIC_RELAY` in vendor extensions)

When temporary relay applies

A Standard Client with Dynamic Repeater Mode enabled:

Does not relay third-party traffic while a stable Repeater or Gateway is heard.
May enter TempRelay only when no Repeater or Gateway has been heard for tNoInfra (e.g. 60–300 s) and a relay-needed heuristic is true.

While in TempRelay:

Flood / on-wire paths only — no predictive nextHop RAM — see Routing.
Enforce tempRelayFloodTtlCap, tempRelayMaxForwardsPerMin, and duplicate suppression.
Do not host bulletin boards or claim full IoT ACK service tiers.

Hysteresis (anti-flap)

Entering TempRelay: tNoInfra + tEnterDebounce + Dynamic Repeater Mode ON + relay needed.

Leaving TempRelay (return to ClientQuiet): stable infrastructure heard for tExitDebounce, or tempRelayMinutes expires, or duty policy forces exit.

The TEMP_RELAY capability bit SHOULD reflect actual temporary relay after debounce.

mermaid

stateDiagram-v2
  [*] --> ClientQuiet: boot
  ClientQuiet --> InfraHeard: beacon from repeater/gateway
  InfraHeard --> ClientQuiet: timer lost / moved away
  ClientQuiet --> TempRelay: Dynamic Repeater ON AND tEnterDebounce AND relay needed
  TempRelay --> ClientQuiet: stable infra tExitDebounce OR duty limit

IoT Client Profile / Sensor Profile

The IoT Client Profile (user-facing: Sensor Profile) is optimized for low-power sensors and actuators. It targets Gateway-based uplink, ACK, and downlink behavior rather than normal chat-style mesh use.

Routing: Do not say IoT messages must be sent directly to a Gateway. Say they are addressed or targeted to a Gateway and may traverse Repeaters.

An IoT Client (Sensor Profile):

Sends uplink messages toward a selected or discovered Gateway.
May reach the Gateway directly or through Repeaters.
Treats the Gateway as the logical endpoint for ACK/downlink behavior.
Opens a receive window after uplink for Gateway ACK/downlink.
May receive queued configuration/control payloads inside the Gateway ACK/downlink window.
Sleeps outside scheduled TX/RX windows.
Does not participate in Dynamic Repeater Mode by default.
May enable Dynamic Repeater Mode only by explicit product/fleet policy.

See IoT: hop budget & ACK downlinks for timing, discovery, and design-target IOT_UPLINK / IOT_ACK layouts.

Base Profile: simple sensor Clients SHOULD use TELEMETRY_BASIC + ACK_BASIC until IOT_* payloads are promoted.

Repeater

A Repeater is fixed infrastructure. Its behavior matches the Infrastructure Relay Profile (not a separate user setting).

An Infrastructure Relay Profile device:

Forwards traffic per Routing (stateless dumb-pipe: flood, strict on-wire routes, duplicate suppression).
Participates in link metric exchange.
MAY host a bulletin board.
Does not provide internet/backhaul unless the role is upgraded to Gateway.

Gateway

A Gateway is a Repeater with internet/backhaul and gateway services. Behavior matches the Gateway Profile (fixed by role).

A Gateway Profile device:

Forwards like a Repeater.
Maintains upstream connectivity (Ethernet, Wi-Fi, LTE — implementation-defined).
MAY bridge to MQTT/API/cloud (out of core wire spec).
MAY act as the logical endpoint for IoT uplinks, source of Gateway ACK/downlink messages, and bulletin host.
SHOULD advertise gateway / IOT_ACK_SVC capabilities in beacons where applicable.

Gateway reachability is optional for the mesh as a whole.

Capability flags (example)

Encoded in beacons (implementation-defined; semantic model):

Bit	Meaning
`0`	`GATEWAY` — internet backhaul
`1`	`REPEATER` — forwards by default
`2`	`BULLETIN` — bulletin storage
`3`	`IOT_ACK_SVC` — hop-budget ACK / downlink service
`4`	`TEMP_RELAY` — in temporary relay state (Dynamic Repeater Mode active)

Remote maintenance boundary

Remote access uses 0-hop maintenance. It does not change role or profile.

Device roles and profiles ​

Roles ​

Role summary (infrastructure) ​

Profiles ​

Profile defaults ​

Recommended settings UI ​

Client ​

Standard Client Profile ​

Dynamic Repeater Mode ​

When temporary relay applies ​

Hysteresis (anti-flap) ​

IoT Client Profile / Sensor Profile ​

Repeater ​

Gateway ​

Capability flags (example) ​

Remote maintenance boundary ​