[FEAT] Meshcore Autopoll Neighbours

[HougeDK]

I would like to be able to autopoll Neighbours.
A feature like Telemetry Retrieval that just polls Neighbours and fill it in the Node Details.
Use same function as Telemetry Retrieval.

Use same 60-second minimum spacing, to avoid too much polling.

Be sure the 60-second minimum spacing is separate on Telemetry Retrieval and Neighbours Retrieval.
So they dont collide.

[Yeraze]

Thanks for the request! I checked for duplicates (searched for "neighbor poll", "autopoll", "telemetry retrieval" — nothing open matches; closed #1373/#1728 covered manual NeighborInfo pulls for Meshtastic, not MeshCore auto-polling) and don't see an existing issue covering this.

Classification: Feature Request. This aligns well with the tool's existing "opt-in per-node scheduled polling" pattern already used for MeshCore telemetry, so it's a reasonable fit.

What already exists

• Telemetry Retrieval, the feature you're asking to mirror, lives in MeshCoreRemoteTelemetryScheduler (src/server/services/meshcoreRemoteTelemetryScheduler.ts). It's per-node opt-in (telemetryEnabled / telemetryIntervalMinutes / lastTelemetryRequestAt columns on meshcore_nodes), with a MIN_INTERVAL_BETWEEN_REQUESTS_MS = 60_000 per-source throttle and fair-rotation tie-breaking across nodes.
• Neighbour retrieval already exists as an on-demand action — MeshCoreManager.requestNeighbors() / getNeighbours(), wired to a manual "Request Neighbors" button (POST /api/sources/:id/meshcore/neighbors/request). So the mesh-protocol piece is done; what's missing is the scheduler.
• There's also an existing auto-poll for neighbours today, but it's bundled inside "Auto-Pathfinding" (meshcoreManager.ts startAutoPathfinding(), gated by meshcoreAutoPathfindingNeighborsEnabled). It polls repeater contacts on a fixed interval tied to pathfinding config, not the per-node opt-in style Telemetry Retrieval uses — so it's not really replaceable for what you're asking, but worth knowing about in case it's already scratching part of this itch.

One design question before I plan this out

You asked for the 60-second minimum spacing to be separate and independent between Telemetry Retrieval and Neighbours Retrieval, "so they don't collide." Looking at the code, it's actually the opposite: the 60s gate in the telemetry scheduler reads a single shared per-source "last mesh TX" clock that's deliberately shared across every scheduled mesh operation on that source (telemetry, traceroute, etc.) specifically to prevent airtime collisions between them.

If Neighbours Retrieval got its own fully independent clock as literally described, a telemetry request and a neighbours request could fire back-to-back with 0 seconds between them on the same source — which is the collision the shared clock exists to prevent.

I think what you actually want is:

• Independent configuration — separate enable/interval settings per node for neighbours vs. telemetry (so you can turn one on without the other, or set different intervals) — but
• Still sharing the underlying anti-collision transmit gate, so a neighbours poll and a telemetry poll never key up within 60s of each other on the same source.

That's consistent with the existing architecture and I'd plan to implement it that way unless you specifically want fully independent radio-time clocks (which would remove the collision protection between the two features). Let me know which you meant and I'll finalize the plan.

Sketch of the plan (pending your answer above)

1. Migration: add neighborsEnabled / neighborsIntervalMinutes / lastNeighborsRequestAt to meshcore_nodes, mirroring the telemetry columns.
2. New MeshCoreNeighboursScheduler (sibling to MeshCoreRemoteTelemetryScheduler), reusing the same per-node eligibility/fair-rotation logic, sharing the per-source getLastMeshTxAt()/recordMeshTx() gate rather than introducing a second one.
3. Routes mirroring the telemetry-config endpoints: GET/PATCH .../neighbors-config, POST .../neighbors/poll, calling the existing manager.requestNeighbors().
4. Frontend: a MeshCoreNodeNeighboursConfig panel mirroring MeshCoreNodeTelemetryConfig.tsx, mounted in Node Details alongside the telemetry config.
5. Scheduler registered at startup alongside the existing remote telemetry scheduler.
6. Tests mirroring the existing telemetry scheduler/route test suites.

I won't start implementation until we've settled the clock question above and I hear back on the overall plan.

-- Authored by Roger 🤓

---

Generated by Claude Code

[HougeDK]

I agree with the plan