Feature Request: CLI Enhancements for Large Mesh Deployments

[Liberty-Chris]

Hi team, I’ve been using Meshtastic in a large-scale deployment involving dozens (126) of LoRa-connected nodes in a real-world environment. The system involves frequent scanning, battery-powered mobility, and a central hub that aggregates telemetry and coordinates activity across the mesh on a quiet channel, utilizing PSK.

During our development and field testing, we ran into several edge cases where more detailed CLI outputs would have made monitoring and debugging significantly easier at scale. Here are a few specific command suggestions that could improve CLI utility for large deployments:

1. --nodes-full or --nodes-raw
   Outputs the complete metadata for each known node, including things like SNR, voltage, airUtilTx, hop limit, and last seen.

2. --channel-status
   Provides a summary of each configured channel index, whether enabled or not, with metadata like PSK set, role (router/client), and frequency/channel number.

3. --path-to !NODEID
   Traces the multi-hop route (if available) to the target node. This is helpful for mesh validation and topology visualization.

4. --telemetry-once
   Outputs a one-time telemetry snapshot for all nodes with values like battery, signal strength, SNR, etc. Great for powering live dashboards or battery diagnostics.

5. --node-health
   Shows summarized health metrics per node (e.g., online status, last seen delta, power level, GPS status, hop count). Can be optionally JSON for parsing.

6. --ping-all
   Pings all reachable nodes and prints responses with RSSI/SNR, helping confirm node presence and link quality in one pass.

These are based on tools we had to build manually or work around during a production ready rollout. I’m happy to help scope or contribute to any of these if there’s interest.

Thanks again for your work. Meshtastic has been a game changer for an interesting project. I found Meshtastic while searching for solutions to a problem and as a Ham, I have a new addiction :)

Chris Hockaday KF4DBX

[Liberty-Chris]

Also wanted to add one more suggestion related to real-time mesh status:

Right now, the positionBroadcastSecs setting (heartbeat interval) has a hardcoded minimum of 1800 seconds. In our use case, this made it difficult to reliably monitor units or mobile nodes where having fairly live system health updates greatly improves the ability to react to problems quickly when/if they arise. Even reducing it to 60 or 300 seconds would offer a lot more flexibility for controlled deployments.

If relaxing that limit isn't feasible by default, perhaps a CLI flag like --force or a dev mode override could bypass it intentionally. Just wanted to surface this in case others also need more frequent heartbeat updates for visibility.

Thanks again!

Chris Hockaday KF4DBX

[pdxlocations]

During our development and field testing, we ran into several edge cases where more detailed CLI outputs would have made monitoring and debugging significantly easier at scale.

Hi Chris, not to distract from your request, but have you considered using python scripts to collect more detailed data about nodes in your mesh? I ask because in # 4 you say "great for powering live dashboards" but I'd argue the CLI is not the best tool for this.

Regards,

Ben Lipsey K1PDX

[Liberty-Chris]

During our development and field testing, we ran into several edge cases where more detailed CLI outputs would have made monitoring and debugging significantly easier at scale.

Hi Chris, not to distract from your request, but have you considered using python scripts to collect more detailed data about nodes in your mesh? I ask because in # 4 you say "great for powering live dashboards" but I'd argue the CLI is not the best tool for this.

Regards,

Ben Lipsey K1PDX

Hi Ben! I wrote some software that gives me the flexibility in my use case. I'm transmitting data from remote nodes every 60 seconds that a central node listens for and parses to a dashboard that I'm hosting for remote viewing. It will be open sourced ultimately, so others might make use of it.

Chris Hockaday KF4DBX

[iranzo]

Would be great to have some sort of configuration definition inventory, similar to ansible to perform initial configuration (after first admin key has been defined), so that the nodes can be remotely administered and make them comformat to the yaml definitions (new channels, new keys, etc)

[SEWilco]

During our development and field testing, we ran into several edge cases where more detailed CLI outputs would have made monitoring and debugging significantly easier at scale.

Hi Chris, not to distract from your request, but have you considered using python scripts to collect more detailed data about nodes in your mesh? I ask because in # 4 you say "great for powering live dashboards" but I'd argue the CLI is not the best tool for this. Regards, Ben Lipsey K1PDX

Hi Ben! I wrote some software that gives me the flexibility in my use case. I'm transmitting data from remote nodes every 60 seconds that a central node listens for and parses to a dashboard that I'm hosting for remote viewing. It will be open sourced ultimately, so others might make use of it.

Chris Hockaday KF4DBX

MSPmesh has noticed high channel utilization on its large mesh, which is reduced by having many hours between node broadcasts. That might be reduced in recent versions of firmware if your private mesh is sending info in DMs to specific nodes.

Also, are you aware of potato-mesh (Github) use of multiple data collection nodes? The concept of having multiple listeners might be useful.

[SEWilco]

I'd argue the CLI is not the best tool for this.

Maybe some of these are jobs for the Python library. But it appears that the library is interwoven with the CLI development.

[roberthadow]

The --nodes command makes a beautiful table, true. That's great for a human reader. I would love --nodes-raw or --nodes-csv.

Yes, I could write regex to extract the data, but why, when the data should be avaible not yet prettified?