Meshtastic/MeshCore mesh radio container: backup link, alert TX, mesh RX #13

New Issue

2026-09-27T23:41:36-04:00

logan commented

2026-09-27 23:41:36 -04:00

Owner request 2026-09-27: add a Meshtastic/MeshCore LoRa radio to edge nodes, for all three uses:
(a) backup link, (b) push incident alerts out to the mesh, (c) mesh traffic as a data source for incidents.

Server side: see the linked server-26 issue.

Design

New 4th compose service mesh, modelled on secondary-sdr-container/. USB-serial LoRa radio (Heltec/RAK/T-Beam), devices: passthrough instead of privileged.
Python service using the meshtastic lib, or meshcore for MeshCore firmware, behind one small adapter interface so firmware choice is a config setting (MESH_FIRMWARE=meshtastic|meshcore).
RX: forward packets to edge-node over localhost HTTP. mqtt_manager.py publishes them on the new nodes/{id}/mesh topic (next to _t_metadata, mqtt_manager.py:32).
TX: a new mesh_send command type on the existing nodes/{id}/commands topic.

Per use

(a) Backup link: when MQTT/WireGuard is down, send a compact heartbeat (node id, status, last-call ts) over a private mesh channel. LoRa is ~200 bytes/packet at duty-cycle limits, so this carries heartbeats only, never audio or call metadata. A second DRB node or a gateway radio at the server receives it (needs a design decision: gateway hardware at the server, or peer relay).
(b) Alerts out: transmit a server-supplied text over a private channel with its own PSK, never the public LongFast channel.
(c) Data source: forward received text/position packets upstream, tagged with the channel they arrived on.

Constraints

Person names suppressed on every surface until E&O is bound (BUSINESS_MODEL.md). The mesh is a surface. Alert text must go through the same suppression as Discord.
Mesh RX is untrusted public input: size-cap it and rate-limit it on the node.
No lockfile/pinning convention exists; pin the meshtastic lib anyway, because its protobuf API churns.

Owner request 2026-09-27: add a Meshtastic/MeshCore LoRa radio to edge nodes, for all three uses: (a) backup link, (b) push incident alerts out to the mesh, (c) mesh traffic as a data source for incidents. Server side: see the linked server-26 issue. ## Design - New 4th compose service `mesh`, modelled on `secondary-sdr-container/`. USB-serial LoRa radio (Heltec/RAK/T-Beam), `devices:` passthrough instead of `privileged`. - Python service using the `meshtastic` lib, or `meshcore` for MeshCore firmware, behind one small adapter interface so firmware choice is a config setting (`MESH_FIRMWARE=meshtastic|meshcore`). - RX: forward packets to edge-node over localhost HTTP. `mqtt_manager.py` publishes them on the new `nodes/{id}/mesh` topic (next to `_t_metadata`, mqtt_manager.py:32). - TX: a new `mesh_send` command type on the existing `nodes/{id}/commands` topic. ## Per use - **(a) Backup link:** when MQTT/WireGuard is down, send a compact heartbeat (node id, status, last-call ts) over a private mesh channel. LoRa is ~200 bytes/packet at duty-cycle limits, so this carries **heartbeats only, never audio or call metadata**. A second DRB node or a gateway radio at the server receives it (needs a design decision: gateway hardware at the server, or peer relay). - **(b) Alerts out:** transmit a server-supplied text over a **private channel with its own PSK**, never the public LongFast channel. - **(c) Data source:** forward received text/position packets upstream, tagged with the channel they arrived on. ## Constraints - Person names suppressed on every surface until E&O is bound (BUSINESS_MODEL.md). **The mesh is a surface.** Alert text must go through the same suppression as Discord. - Mesh RX is untrusted public input: size-cap it and rate-limit it on the node. - No lockfile/pinning convention exists; pin the meshtastic lib anyway, because its protobuf API churns.

logan commented

2026-09-27 23:41:37 -04:00