Meshtastic Node IDs, Addresses, and Naming

Understanding how Meshtastic nodes are identified helps you interpret the node list, configure direct messaging, and troubleshoot network issues.

Node ID Format

Every Meshtastic node has a unique 32-bit node ID derived from its hardware MAC address. The ID is displayed in several formats:

• Decimal: 2882343476 (rarely used in user interfaces)
• Hex with prefix: !abcd1234 (most common display format; the "!" prefix denotes a node ID)
• Short ID: The last 4 hex digits, e.g., "1234" — used as the default short name

The node ID is permanent and tied to the hardware. It cannot be changed without hardware modification (some boards expose a method to set a custom hardware ID in firmware).

Long Name and Short Name

In addition to the hardware node ID, each node has two user-configurable names:

• Long name — Up to 39 characters. Used in the full node list. Example: "Portland-Burnside-Bridge-Repeater" or "KG7XYZ Mobile"
• Short name — Up to 4 characters. Displayed on the map and in compact node list views. Example: "PDX1", "K7AB"

# Set long name:
meshtastic --set-owner "Your Long Name Here"

# Set short name:
meshtastic --set-owner-short "SHT1"

Channel Name and Hash

Meshtastic channels have both a name and a PSK (encryption key). The channel name is displayed to users; the PSK is what actually controls which nodes can communicate on the channel. Two nodes can have different channel names but the same PSK — they'll still communicate (though the name mismatch may confuse users).

The "channel hash" is a short numeric identifier derived from the channel name, used in packet headers to quickly identify which channel a packet belongs to without decrypting it.

How Nodes Discover Each Other

Meshtastic nodes don't have a directory or registration system. Discovery happens organically:

1. Nodes periodically broadcast "NodeInfo" packets containing their node ID, name, hardware model, and (optionally) GPS position
2. Any node that receives a NodeInfo packet adds the sender to its local node database
3. NodeInfo packets propagate through the mesh via the same flooding mechanism as messages
4. Nodes that haven't been heard from in a configurable time period are marked as "stale" in the node database

This means in a well-connected mesh, a new node will typically appear in all other nodes' lists within a few minutes of powering on, even if it's multiple hops away.