MeshMonitor 4 : Multi Node Support

[Yeraze]

The eagle eyed among you may have noticed recent commits to a new feature/4.0 branch. That's right, MeshMonitor 4.0 is currently in development. And the major new feature coming in 4.0: The long-awaited often-requested implementation of Multiple Node support.

In 4.0, you will be able to add "sources" directly inside the app via UI (no more docker-compose editing for this!), and enlist an unlimited number of nodes. At first we will just support MeshTastic nodes via IP, but shortly afterwards will come MeshCore nodes, MQTT support, and even other MeshMonitor4 installs.

It's going to take a bit to pull it all together, but I will start publishing MeshMonitor 4 alphas soon for those who want to try it out. As part of this, MeshMonitor3 development will slow significantly to avoid code divergence, but I'll be working to resolve urgent bugs as they are raised.

So if you have any questions or requests, get them in now! 4.0 is going to be a big one, and unfortunately there's a strong possibility that any existing saved data will not survive a migration. I'm going to try to get it to work, but I can't make any promises at this early time.

[denlenin]

Hi!
I'd like to see more convenient/expanded data analytics from the info page. For example, it's still difficult to understand which devices are used online and which are more popular. It would probably be nice to show the device model in the packet monitor, as well as the received data (for telemetry and other packets) in the content column.

On the info page, the "Packet Distribution" section has an "all data" button. It's unclear for what period this is. It would be great to be able to manually select the period. It would also be great to be able to expand the "Other: 51.7% (1,137)" line item. But that seems cumbersome. Perhaps you could export the full information for the selected period to a CSV file?

[bfsampson]

I am running the DMG/macOS app and not Docker.  Trying to connect to a Meshcore Companion.  Serial port path /dev/cu.usbmodem8856A69634981. The port is confirmed accessible (crw-rw-rw-).

tail -50 ~/Library/Application\ Support/MeshMonitor/logs/server-stderr.log
[ERROR] [MeshCore] Connection failed: undefined
[ERROR] [MeshCore] Connection failed: undefined
[ERROR] [MeshCore] Connection failed: undefined
[ERROR] [MeshCore] Connection failed: undefined
[ERROR] [MeshCore] Connection failed: undefined

Meshcore device does not connect.

[Yeraze]

@bfsampson Two things will help narrow this down:

1. macOS app permissions. The DMG bundle needs Full Disk Access + Input Monitoring granted to MeshMonitor itself in System Settings → Privacy & Security, and on Apple Silicon the binary must not be quarantined. Run xattr -p com.apple.quarantine /Applications/MeshMonitor.app — if that prints anything, run xattr -dr com.apple.quarantine /Applications/MeshMonitor.app and relaunch.
2. Confirm the device responds outside MeshMonitor. With the device idle, try screen /dev/cu.usbmodem8856A69634981 115200 from a terminal — you should see MeshCore framing or be able to send q for the CLI. If screen also can't open the port, something else is already holding it (meshcore-cli, a BLE bridge, etc.). If screen works but MeshMonitor still doesn't, please attach ~/Library/Application Support/MeshMonitor/logs/server.log — note server.log, not server-stderr.log; the stderr file only catches uncaught throws so it will always look like undefined.

The Connection failed: undefined line is a known lossy log — the underlying meshcore.js library rejects some promises without an Error object and the handler doesn't fall back gracefully. I'll fix that separately so the next report includes the actual cause.

[bfsampson]

Randall, Meshmonitor has full disk access and is not in quarantine.  Screen starts properly with a q exit.  I am unable to find a server.log. The following are two logs.  The first is after shutting Meshmonitor down, closing the localhost:8080 browser, unplugging the companion. ***@***.*** ~ % tail -10 ~/Library/Application\ Support/MeshMonitor/logs/server-stdout.log [INFO] Skipping auto-connect for MeshCore source ce0a8f09-36bd-46e8-91d3-d81c0bc5ebca (BS1-Sequim) — autoConnect disabled [INFO] [MeshCorePoller] Starting local-node telemetry poll every 300s [INFO] [MeshCoreRemoteTelem] Scheduler starting (tick=30s, min-interval=60s) [INFO] [WebSocket] Client connected: wVYZdryg1tbtB9MEAAAB (user: admin) [INFO] [MeshCore:04d263f2-5290-4886-955c-649f1661bbd6] Manager initialized [INFO] [MeshCoreRegistry] Registered manager for source 04d263f2-5290-4886-955c-649f1661bbd6 (K6MBY2 - Sequim) [INFO] [MeshCore] Connecting via serial... [INFO] [MeshCore:04d263f2-5290-4886-955c-649f1661bbd6] Starting native backend (meshcore.js) [INFO] [MeshCore] Disconnecting... [INFO] [MeshCore] Disconnected ***@***.*** ~ % The second, restarting Meshmonitor, starting browser, starting localhost:8080, plugging the companion back in, attempting to connect, failed. % tail -10 ~/Library/Application\ Support/MeshMonitor/logs/server-stdout.log [INFO] Skipping auto-connect for MeshCore source ce0a8f09-36bd-46e8-91d3-d81c0bc5ebca (BS1-Sequim) — autoConnect disabled [INFO] [MeshCorePoller] Starting local-node telemetry poll every 300s [INFO] [MeshCoreRemoteTelem] Scheduler starting (tick=30s, min-interval=60s) [INFO] [WebSocket] Client connected: BBXKMySWNGSMGCCdAAAB (user: admin) [INFO] [MeshCore:04d263f2-5290-4886-955c-649f1661bbd6] Manager initialized [INFO] [MeshCoreRegistry] Registered manager for source 04d263f2-5290-4886-955c-649f1661bbd6 (K6MBY2 - Sequim) [INFO] [MeshCore] Connecting via serial... [INFO] [MeshCore:04d263f2-5290-4886-955c-649f1661bbd6] Starting native backend (meshcore.js) [INFO] [MeshCore] Disconnecting... [INFO] [MeshCore] Disconnected Bob Sampson aka k6mby Sequim, WA ***@***.*** 360-582-9116 From: Randall Hand ***@***.***> Reply-To: Yeraze/meshmonitor ***@***.***> Date: Sunday, May 17, 2026 at 7:58 AM To: Yeraze/meshmonitor ***@***.***> Cc: Robert Sampson ***@***.***>, Mention ***@***.***> Subject: Re: [Yeraze/meshmonitor] MeshMonitor 4 : Multi Node Support (Discussion #2604) @bfsampson Two things will help narrow this down: macOS app permissions. The DMG bundle needs Full Disk Access + Input Monitoring granted to MeshMonitor itself in System Settings → Privacy & Security, and on Apple Silicon the binary must not be quarantined. Run xattr -p com.apple.quarantine /Applications/MeshMonitor.app — if that prints anything, run xattr -dr com.apple.quarantine /Applications/MeshMonitor.app and relaunch. Confirm the device responds outside MeshMonitor. With the device idle, try screen /dev/cu.usbmodem8856A69634981 115200 from a terminal — you should see MeshCore framing or be able to send q for the CLI. If screen also can't open the port, something else is already holding it (meshcore-cli, a BLE bridge, etc.). If screen works but MeshMonitor still doesn't, please attach ~/Library/Application Support/MeshMonitor/logs/server.log — note server.log, not server-stderr.log; the stderr file only catches uncaught throws so it will always look like undefined. The Connection failed: undefined line is a known lossy log — the underlying meshcore.js library rejects some promises without an Error object and the handler doesn't fall back gracefully. I'll fix that separately so the next report includes the actual cause. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: ***@***.***>

[Yeraze]

@bfsampson Thanks — full disk access, no quarantine, and screen opening the port cleanly all rule out the most common macOS gotchas, so the real failure is happening inside the meshcore.js library after MeshMonitor opens the serial connection. The stdout log you sent stops at Disconnecting... because the actual rejection is being written to server-stderr.log, not stdout, and the lossy Connection failed: undefined line you originally posted is the only thing my catch handler can produce when the library rejects without an Error object — I need the surrounding context to see what it actually rejected with.

The macOS desktop bundle writes three log files. To diagnose this I need all three (full files, not tails). They live in:

~/Library/Application\ Support/MeshMonitor/logs/

Easiest way to grab them — paste this in Terminal:

cd ~/Library/Application\ Support/MeshMonitor/logs/
ls -la
# expected files: desktop.log, server-stdout.log, server-stderr.log

Then either attach all three to this thread, or paste each one to https://dpaste.com/ and post the links. Specifically I'm looking for:

1. server-stderr.log — full file (cat server-stderr.log, not tail). The [ERROR] [MeshCore] Connection failed: … lines are here, and any lines immediately before them should reveal the underlying cause (failed to open port, baud mismatch, no AppStart response, etc.).
2. server-stdout.log — full file. The INFO sequence you sent (Connecting via serial... → Starting native backend (meshcore.js) → Disconnecting...) is interesting because the manager gets through Starting native backend and then immediately tears down, so something is throwing inside the native backend's connect() between those two log lines.
3. desktop.log — the Tauri Rust side log. Includes startup paths and any spawn-time errors that don't surface in the Node logs.

One quick consistency check before you do that: looking at your stdout, there are two MeshCore sources configured — ce0a8f09-… (BS1-Sequim, autoConnect disabled) and 04d263f2-… (K6MBY2-Sequim, the one actually trying to connect). Can you confirm that 04d263f2-… (K6MBY2-Sequim) is the one with the serial-port path /dev/cu.usbmodem8856A69634981 set, and that the other source isn't claiming the same port?

[bfsampson]

Three files attached. Yes, K6MBY2 - Sequim is /dev/cu.usbmodem8856A69634981.  The other companion, BS1-Sequim, is not connected but is listed as a device without autoconnect. Bob Sampson Sequim, WA ***@***.*** 360-582-9116 From: Randall Hand ***@***.***> Reply-To: Yeraze/meshmonitor ***@***.***> Date: Sunday, May 17, 2026 at 3:56 PM To: Yeraze/meshmonitor ***@***.***> Cc: Robert Sampson ***@***.***>, Mention ***@***.***> Subject: Re: [Yeraze/meshmonitor] MeshMonitor 4 : Multi Node Support (Discussion #2604) @bfsampson Thanks — full disk access, no quarantine, and screen opening the port cleanly all rule out the most common macOS gotchas, so the real failure is happening inside the meshcore.js library after MeshMonitor opens the serial connection. The stdout log you sent stops at Disconnecting... because the actual rejection is being written to server-stderr.log, not stdout, and the lossy Connection failed: undefined line you originally posted is the only thing my catch handler can produce when the library rejects without an Error object — I need the surrounding context to see what it actually rejected with. The macOS desktop bundle writes three log files. To diagnose this I need all three (full files, not tails). They live in: ~/Library/Application\ Support/MeshMonitor/logs/ Easiest way to grab them — paste this in Terminal: cd ~/Library/Application\ Support/MeshMonitor/logs/ ls -la # expected files: desktop.log, server-stdout.log, server-stderr.log Then either attach all three to this thread, or paste each one to https://dpaste.com/ and post the links. Specifically I'm looking for: server-stderr.log — full file (cat server-stderr.log, not tail). The [ERROR] [MeshCore] Connection failed: … lines are here, and any lines immediately before them should reveal the underlying cause (failed to open port, baud mismatch, no AppStart response, etc.). server-stdout.log — full file. The INFO sequence you sent (Connecting via serial... → Starting native backend (meshcore.js) → Disconnecting...) is interesting because the manager gets through Starting native backend and then immediately tears down, so something is throwing inside the native backend's connect() between those two log lines. desktop.log — the Tauri Rust side log. Includes startup paths and any spawn-time errors that don't surface in the Node logs. One quick consistency check before you do that: looking at your stdout, there are two MeshCore sources configured — ce0a8f09-… (BS1-Sequim, autoConnect disabled) and 04d263f2-… (K6MBY2-Sequim, the one actually trying to connect). Can you confirm that 04d263f2-… (K6MBY2-Sequim) is the one with the serial-port path /dev/cu.usbmodem8856A69634981 set, and that the other source isn't claiming the same port? — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: ***@***.***>

[Yeraze]

@bfsampson Got the logs — thanks. Two different things are going on, and the noisy one in server-stderr.log actually has nothing to do with MeshCore.

What server-stderr.log is telling us

The vast majority of those error lines look like this:

[ERROR] ❌ TCP socket error: connect ENETUNREACH 192.168.1.100:4403
[ERROR] ❌ TCP transport error: connect ENETUNREACH 192.168.1.100:4403
[ERROR] Reconnection failed: connect ENETUNREACH 192.168.1.100:4403

That's a Meshtastic TCP source trying to reach 192.168.1.100:4403 and getting "Network unreachable." Looking at desktop.log, every spawn the desktop bundle sets MESHTASTIC_NODE_IP: 192.168.1.100, and server-stdout.log line 22 confirms it (MESHTASTIC_NODE_IP: 192.168.1.100 (env)). That value is a hardcoded placeholder the macOS app ships with — it's not something you set. Since you don't actually have a Meshtastic node at that IP (you have MeshCore companions instead), the env-derived Meshtastic source flaps forever in the background, producing the wall of ENETUNREACH lines.

Immediate workaround: in the MeshMonitor UI, open the Sources page and delete the Meshtastic source pointing at 192.168.1.100. That should stop ~99% of the noise in server-stderr.log. Your two MeshCore sources (K6MBY2-Sequim and BS1-Sequim) are independent and will stay.

I'm opening a fix for the desktop app so future builds won't ship that placeholder source for users who only run MeshCore.

What's left — the actual MeshCore failure

After you remove the phantom Meshtastic source, only one line in server-stderr.log is relevant to your MeshCore problem:

[ERROR] [MeshCore] Connection failed: undefined

That undefined is the issue I called out before — the underlying meshcore.js library rejects without an Error object, and our catch handler doesn't fall back gracefully. So we still can't tell whether the actual failure is at port-open, AppStart timeout, baud mismatch, or something inside the library. I'm shipping a fix in the same PR that will make this log line emit a useful message instead of undefined.

Once that's merged and the next desktop build is out, please try a clean Connect on K6MBY2 again and grab server-stderr.log — the one MeshCore error line will then tell us exactly what's failing.

[bfsampson]

old meshmonitor.app moved to trash. added 4.6.1 to application folder. plugged in companion. checked port /dev/cu.usbmodem8856A69634981. screen /dev/cu.usbmodem8856A69634981 115200 works with a q exit. launched meshmonitor.app, open browser to localhost:8080. logged in and old k6mby2 - sequim still there along with bs1-sequim. deleted both and put in just k6mby2 - sequim. Hit connect. got logs.
server-stdout.log
server-stderr.log
desktop.log

[bfsampson]

Made a test repeater. it connected. Logs attached.
server-stdout.log
server-stderr.log
desktop.log

[bfsampson]

Even though the repeater appeared to be connected, the map did not populate. In settings, the entry of the repeater lat/long failed on saving.

[Yeraze]

@bfsampson moving this over to #3087 for better tracking