[FEAT] Add MeshMapper Bridge / Data Forwarding Integration

[maxhayim]

Is your feature request related to a problem? Please describe.

MeshMonitor can already receive, decode, store, and bridge mesh traffic from connected nodes, MQTT brokers, and other sources, but there is currently no native way to forward applicable mapping/coverage data from MeshMonitor to MeshMapper:

https://meshmapper.net/

https://github.com/MeshMapper

This means that users who already operate MeshMonitor as a central monitoring system may need to run an additional dedicated MeshMapper observer or separate software stack simply to contribute data to MeshMapper.

For installations where MeshMonitor is already continuously connected to nodes and receiving position, packet, RSSI, SNR, routing, and other RF information, this creates unnecessary duplication.

Describe the solution you'd like

Add a MeshMapper Bridge / Output Integration to MeshMonitor that can forward compatible data collected by MeshMonitor to MeshMapper.

Ideally, this could be configured similarly to the existing MQTT Bridge functionality:

Dashboard → Sources → Add Source → MeshMapper Bridge

Possible configuration options could include:

• Enable / Disable MeshMapper forwarding
• MeshMapper region
• MeshMapper endpoint or broker
• Authentication / device signing information if required
• Select which MeshMonitor source(s) are allowed to contribute data
• Select which channels are forwarded
• Geographic bounding box filtering
• Node allow/block lists
• Packet type filtering
• Optional rate limiting
• Connection status
• Last successful upload
• Number of records forwarded
• Error / authentication status

The bridge should translate MeshMonitor's internally decoded data into whatever format MeshMapper officially supports rather than simply forwarding arbitrary MQTT packets.

For example:

Meshtastic / MeshCore Nodes
          |
          v
     MeshMonitor
          |
          +----> MeshMonitor Database / Dashboard
          |
          +----> Existing MQTT Bridges
          |
          +----> MeshMapper Bridge
                     |
                     v
              meshmapper.net

Another useful architecture would be to allow individual MeshMonitor sources to select MeshMapper as an output destination:

Node / MQTT / TCP / Serial / BLE
              |
              v
        MeshMonitor Source
              |
              v
       MeshMapper Adapter
              |
              v
         MeshMapper API
              OR
      MeshMapper MQTT Broker

The implementation should use whichever ingestion mechanism MeshMapper officially supports and maintain compatibility with its requirements for packet metadata, observer identification, authentication, duplicate detection, and coverage calculations.

Why this would be useful

MeshMonitor is often deployed as an always-on server with several radios, MQTT connections, and geographically distributed nodes.

If MeshMonitor already has access to the RF data, it makes sense for it to act as a gateway into community mapping systems instead of requiring another computer, application, or dedicated observer for the same radio network.

This would be especially useful for:

• Community mesh networks
• Permanent rooftop nodes
• Solar nodes
• Remote nodes
• Regional MQTT networks
• Multiple MeshMonitor instances
• Nodes connected through TCP/Serial/BLE
• Networks where MeshMonitor is already the central MQTT gateway
• Coverage mapping projects
• Large regional deployments

It would also allow communities to contribute significantly more coverage information to MeshMapper without requiring every operator to understand or manually configure a separate MeshMapper observer.

Describe alternatives you've considered

Running a separate MeshMapper observer

A dedicated observer can be deployed specifically for MeshMapper.

However, this duplicates infrastructure when MeshMonitor is already connected to the same radios and receiving the same underlying RF traffic.

Connecting radios directly to multiple services

Individual radios could potentially be configured to communicate with multiple MQTT systems or applications.

This increases configuration complexity and makes deployments harder to maintain, particularly when many nodes are involved.

External bridge script

A separate script could read data from MeshMonitor or MQTT and convert it into a format accepted by MeshMapper.

While technically possible, a native MeshMonitor integration would be much easier to configure, maintain, troubleshoot, and deploy.

It would also allow MeshMonitor to handle filtering, authentication, deduplication, source selection, and status reporting in one interface.

Additional context

MeshMonitor already has substantial MQTT broker and bridge functionality, making a generalized external-output architecture a natural extension of the existing system.

MeshMapper currently supports community coverage mapping through data submitted by clients and connected MQTT observers.

Relevant links:

• MeshMapper: https://meshmapper.net/
• MeshMapper Wiki: https://wiki.meshmapper.net/
• MeshMapper MQTT Overview: https://wiki.meshmapper.net/mqtt-main/
• MeshMapper Data Upload Documentation: https://wiki.meshmapper.net/dataupload/
• MeshMapper Third-Party API Documentation: https://wiki.meshmapper.net/app_third_party_api/

The goal would ultimately be:

Any compatible data already reaching MeshMonitor
                    |
                    v
              MeshMonitor
                    |
                    v
          Native MeshMapper Bridge
                    |
                    v
              MeshMapper.net

This would make MeshMonitor more useful as a centralized bridge between physical mesh infrastructure and third-party visualization/mapping services while avoiding the need to maintain duplicate observer infrastructure.

[Yeraze]

Thanks for the detailed writeup, @maxhayim — no duplicate found (closest related issues are #1368, an unrelated "MeshMonitor-hosted central map" ask that was pointed at the separate MeshManager.org project, and #1463, a local coverage-map visualization request; neither covers forwarding to MeshMapper). Classifying this as a Feature Request.

Alignment

MeshMonitor already has precedent for exactly this shape of feature — the MQTT Bridge (per-source outbound relay with filtering/status reporting) and the Apprise notification integration are both "forward what we already collect to an external service" patterns. A MeshMapper output bridge fits that mold well, so the concept is aligned with where the project is headed.

Research findings that change the scope

I pulled MeshMapper's own docs (wiki.meshmapper.net) to check feasibility before planning, and found a few things worth confirming with you before we commit to a design:

1. MeshMapper appears to be MeshCore-only today. Every doc I could find (mqtt-main, app_third_party_api, dataupload) references MeshCore devices, repeater discovery/trace pings, and contact public keys — I found no mention of Meshtastic support anywhere. Your issue frames this as bridging "Meshtastic / MeshCore Nodes," but if MeshMapper genuinely has no Meshtastic ingestion path, we'd scope this to MeshCore sources only. Do you have a pointer to Meshtastic support in MeshMapper, or should we treat this as MeshCore-specific?
2. MeshMapper's data model is built around active wardriving pings, not passive observation. The custom HTTP API (POST with an X-API-Key, batches of TX/RX/DISC/TRACE ping objects tied to a live lat/lon) reads as "a moving device firing pings and recording what comes back," not "relay packets I happened to overhear." MeshMonitor is normally a stationary/passive monitor. This matters a lot for scope:
   • If the intent is to relay packets MeshMonitor already passively observes (from meshcore_packet_log — RX/DISC/TRACE events with GPS from device position) without originating new mesh traffic, that's the safer and more natural fit for MeshMonitor's architecture.
   • If the intent is for MeshMonitor to actively originate ping sweeps on a schedule to build coverage data (closer to what the MeshMapper app itself does), that's new RF-transmitting behavior and falls under our airtime/mesh-impact policy — it would need an explicit rate limit and interval that I'd bring to you (the project owner) to set, not something I'd pick myself.
   • Which of these — or both — did you have in mind?
3. The MQTT observer path (mqtt.meshmapper.net / LetsMesh brokers) requires "device signing" for auth, and the public docs don't spell out how that credential is generated/formatted. If you or anyone in the MeshMapper community can point to how device signing works, that'd unblock using MQTT instead of (or alongside) the custom HTTP endpoint.
4. Should this be a global, cross-source integration (like Apprise) or a per-source destination (like the two architecture diagrams in your issue both suggest, somewhat differently)? A global bridge that lets you pick which MeshCore source(s)/channels feed it is simplest to reuse from the existing MQTT Bridge pattern.

Once these are pinned down I'll put together an implementation plan (data flow, settings UI under Dashboard → Sources, status/error reporting) and post it here for review before any code gets written.

-- Authored by Roger 🤓

---

Generated by Claude Code

[Yeraze]

Implementation plan (supersedes the open questions above)

After a deeper research pass on MeshMapper's docs and the reference observer code, here is the confirmed picture and the plan we're building. Two corrections to my earlier comment first:

1. The "Third-Party API" doc describes the reverse direction. It is MeshMapper's app forwarding wardrive batches to a third-party endpoint — not an upload API into MeshMapper. The real ingestion path for a stationary observer is MQTT.
2. MeshMonitor already speaks MeshMapper's exact wire contract. The MeshCore Analyzer Observer (per-source, added for the map.w0z.is / FL Mesh analyzer ecosystem) publishes to meshcore/{IATA}/{PUBLIC_KEY}/packets + /status with the same packet JSON and the same Ed25519 JWT ("device signing") auth that MeshMapper's brokers verify. MeshMapper is, in effect, just another broker URL.

Confirmed facts

• MeshMapper is MeshCore-only — no Meshtastic ingestion path exists, so this feature is scoped to MeshCore sources.
• Brokers: wss://mqtt.meshmapper.net:443 and LetsMesh (mqtt-us-v1.letsmesh.net / mqtt-eu-v1.letsmesh.net), WebSockets + TLS. MeshMapper recommends publishing to both; it dedupes.
• "Device signing" = a JWT (alg: Ed25519) with public_key/iat/exp/aud claims, signed with the companion's own key — which MeshMonitor's observer already mints.
• The relay is fully passive: it forwards packets the node already heard. Zero added airtime.

Plan

Phase 1 — multi-broker observer backend. The observer config grows from one broker to a list, each with its own connection state, counters, and auth; existing single-broker configs keep working unchanged. A new status API exposes per-broker health (connected, publishes, dropped, last publish, last error).

Phase 2 — UI. The observer settings gain an "Add broker" list with one-click presets — MeshMapper, LetsMesh US, LetsMesh EU, custom — plus live status on the Dashboard source card and the MeshCore source page.

Out of scope for v1 (can follow later if wanted): packet-type / node / bounding-box filtering, rate limiting (the reference meshcore-packet-capture observer forwards everything it hears, and this path transmits nothing on the mesh), and ingesting wardrive data from MeshMapper apps via the third-party endpoint API.

Net result: any MeshCore source connected to MeshMonitor can contribute coverage data to MeshMapper and LetsMesh at the same time, with no extra observer hardware.

---

Generated by Claude Code

[Yeraze]

Shipped in two phases — MeshMonitor can now act as a MeshMapper observer with no extra hardware:

• feat(observer): multi-broker Analyzer Observer backend (#5014 Phase 1) #5022 (backend, merged): the per-source Analyzer Observer publishes to N brokers at once — per-broker connections, counters, credentials, and Ed25519 auth tokens (minted per audience). Existing single-broker configs keep working unchanged.
• feat(observer-ui): broker-list editor, MeshMapper/LetsMesh presets, status surfaces (#5014 Phase 2) #5027 (UI, merged): the observer settings gained an "Add broker" list with one-click presets — MeshMapper, LetsMesh US, LetsMesh EU — plus live status: a per-broker panel (connected, publishes, drops, last publish, errors, token expiry) on the MeshCore Configuration page and an OBS c/N badge on the Dashboard source card. Docs: a "Contribute to MeshMapper" guide in the Analyzer Observer feature page.

Validated end-to-end against the production brokers: a dev instance connected to both mqtt.meshmapper.net and LetsMesh US with device-signed tokens and published live packets (TEST region), while a dead broker isolated its own error without affecting the others.

Setup for anyone landing here: enable the Analyzer Observer on a MeshCore Companion source, set your region's IATA code, click the MeshMapper preset (add LetsMesh too for redundancy — MeshMapper dedupes), and import/generate the signing key from the source's Configuration page. The relay is fully passive — it forwards only packets your radio already heard and transmits nothing on the mesh.

Out of scope for v1 (open to follow-ups if wanted): packet/node/bbox filtering, and ingesting wardrive data from MeshMapper apps via their third-party endpoint API.

---

Generated by Claude Code