Core parameters for MeshDash and Hardware Communication.
⬑ CONNECTED RADIOS
Radio management (add, remove, switch, view stats) has moved to the Connection page.
Primary Radio Connectionnode_0
PROTOCOL
SERIAL PORT
HOST IP
PORT
MAC ADDRESS
How it works:
Save this config and restart. The server will no longer try to open a serial port itself.
A WEB SERIAL button will appear in the topbar β click it to
open a guided wizard, pick your COM port, and the browser streams packets directly to the dashboard.
Requirements: Chrome or Edge 89+ Β· HTTPS or localhost Β· USB cable to radio
β ACTIVE SESSION
MQTT Bridge Mode
MeshDash connects to an MQTT broker and receives mesh packets published
by nodes or gateways. All channels, DMs, telemetry and node info are decoded
and stored exactly like a direct radio connection β source is tagged MQTT.
Note: MQTT_NODE_ID is optional. Without it the slot runs in observer mode (receive-only). Region: The public Meshtastic broker rejects fully-wildcard subscriptions (region="#"). Use a specific region like EU_868 or US.
Your node heartbeat is always active β MeshDash checks in automatically every minute.
Enable Community API below to appear on the public map.
Heartbeat & Health Check● ACTIVE
MeshDash sends a heartbeat to meshdash.co.uk every 60 seconds.
Always active β keeps your node registered and ready for remote access.
Heartbeat runs continuously β not configurable.
ADD RADIO SLOT
LABEL
PROTOCOL
HOST / IP
PORT
SERIAL PORT
MAC ADDRESS
Web Serial slots are browser-direct. After creating the slot, use the WEB SERIAL topbar button and specify the slot ID to connect.
BROKER PRESET
BROKER HOST
PORT
USERNAME
PASSWORD
REGION (e.g. EU_868)
CHANNEL (e.g. LongFast)
MY NODE ID (optional)
TLS/SSL
PUBLIC NETWORK FILTERS
Why use filters? Public MQTT brokers broadcast thousands of packets per minute. To prevent browser lockups and database bloating, we highly recommend filtering out background noise (like telemetry and encrypted packets you can't read).
FILTER PRESET
β MESHCORE SUPPORT β BETA
MeshCore is a separate mesh protocol from Meshtastic. MeshDash integrates it
via the meshcore Python library over Serial, TCP, or BLE.
This integration is in active development. Please read the
capability and limitation notes below before connecting.
β WHAT WORKS
βReceive channel messages β all channels (0β7), displayed in the Channels view βReceive direct messages β DMs to your node appear in the DMs view βSend channel broadcasts β BROADCAST button works on all configured channels βSend DMs β to any node that has been seen via advertisement or contacts list βNode discovery β advertisements populate the node list and map βGPS / map plotting β nodes with location data appear on the map βBattery & telemetry β battery level, voltage, uptime, noise floor displayed in overview βFirmware & radio info β firmware version, frequency, bandwidth, spreading factor displayed βPacket statistics β RX/TX counts (flood vs direct) shown in analytics panel βACK delivery tracking β tick marks update to delivered on DMs βAuto-advertisement β MeshDash announces your node on connect and every 10 min so others can reach you βSNR/RSSI per-hop data β RX_LOG events correlated to messages, attached to packet log entries βPath / traceroute data β PATH_UPDATE events translated to traceroute packets βMulti-slot β add multiple MeshCore nodes alongside Meshtastic and MQTT slots βAuto-reconnect β exponential backoff reconnection on disconnect βQueued message replay β messages stored on radio while disconnected are delivered on reconnect βScheduler & auto-reply β scheduled messages and auto-replies work correctly via MeshCore sendText
β KNOWN LIMITATIONS
βDMs to completely unknown nodes may fail β a node must have advertised at least once
while you were connected for its public key to be known. MeshDash mitigates this by broadcasting
your own advertisement on connect and every 10 minutes, so remote nodes automatically add
you to their contact list. Nodes that are offline and have never been seen cannot be reached. βChannel messages may not arrive on some firmware versions β a confirmed bug in
nRF52840 Companion USB firmware v1.11.x causes CHANNEL_MSG_RECV events to not fire
from external devices. MeshDash works around this with a periodic
get_msg() fallback poll, but reception may still be unreliable on affected hardware.
Upgrade to the latest MeshCore firmware to resolve this. βChannel sender names anonymous on pre-V3 firmware β older firmware embeds the
sender name as "Name: message body" in the text. MeshDash attempts to resolve
the sender via case-insensitive contact lookup; if no match is found, the sender appears
as a stable anonymous node per channel. V3 firmware sends the pubkey prefix directly and
resolves correctly. βNo node-to-node DM interception (by design) β unlike MQTT observer mode,
MeshCore companion radio connections only see messages addressed to or from your node.
Traffic between other nodes is not visible unless relayed through your radio. This is a
fundamental MeshCore protocol design decision, not a MeshDash limitation. βDevice contact list is finite β MeshCore radios store 50β350 contacts depending
on firmware version. Once full, new nodes cannot be added until old ones are pruned.
MeshDash cannot currently manage the device contact list (add/remove contacts). βNode IDs are 12 hex chars, not 8 β MeshCore identifies nodes by a 6-byte
public key prefix, displayed as !a1b2c3d4e5f6.
Meshtastic uses 8-char IDs. Cross-protocol DMs (Meshtastic β MeshCore) are not supported β
they use incompatible key systems. βBLE transport is experimental β BLE pairing behaviour varies by OS.
Linux requires prior device pairing via bluetoothctl before connecting.
macOS handles pairing via the system Bluetooth UI. BLE proxy connections do not support
PIN pairing. Range and stability depend on host Bluetooth hardware quality. βSerial on pseudo-ttys (socat) fails β the MeshCore library sets RTS/DTR signals
on connect. Socat pseudo-ttys do not support hardware flow control ioctls and will error.
Use a real USB serial adapter (/dev/ttyUSB0, /dev/ttyACM0,
COM3). All genuine MeshCore hardware (Heltec, LilyGO, RAK) works correctly. βAdmin commands not yet exposed in UI β the MeshCore protocol supports remote
admin (login, radio config, set name/coords, reboot) via the library. MeshDash does not yet
expose these in the interface. MeshMonitor has this feature; it is on the MeshDash roadmap.