SummitMesh

Turn a MeshCore LoRa mesh into a mountain-range sensor network. Summit nodes broadcast their sensor readings out over the mesh on a schedule; a collector on the home network verifies, decodes, and stores them. Hikers anywhere in range of the mesh can read live conditions in the standard MeshCore app.

Why

MeshCore's built-in telemetry is request/response over a few hops — you log into a node and pull its readings. That doesn't scale to "see every sensor across a whole mountain range." SummitMesh flips it to a broadcast model: each node floods its readings onto public channels, relayed by the existing repeater chain, so data travels the full mesh and needs no live infrastructure to reach a human. The collector is an optional consumer for storage/graphing, not a dependency for hikers seeing data.

How it works

 summit nodes (RAK4631 / Heltec T114, SummitMesh firmware)
   read sensors on interval, flood TWO channel messages:
     #sensordata : base64(node_id|counter|CayenneLPP|MAC4)   <- authoritative, signed
     #summitwx   : "MtSunapee 18.4C bat 88%"                 <- hiker-readable text
        |
   existing MeshCore repeater chain relays both
        |
 gateway node (companion firmware, USB serial)  -- dumb radio<->host pipe
        |
 collector (Python, beside Home Assistant)
   verify MAC + replay counter -> decode CayenneLPP -> publish MQTT
   (optional) answer keyword queries on #summitwx
        |
 Mosquitto -> Home Assistant entities + your time-series store + Grafana

Two resilience tiers: the #summitwx text flood reaches hikers with zero infrastructure (no gateway, no collector, no HA needed). The signed #sensordata channel is the authoritative machine-readable stream for storage.

Reading, requesting, and viewing sensors

Sensors are read through MeshCore's own SensorManager, so SummitMesh supports whatever sensors MeshCore supports for your board — no custom read code. The scheduled broadcast and an on-demand telemetry request return identical data.

Because nodes build on the repeater base, on-demand telemetry requests work out of the box: anyone can query a node from the standard MeshCore app and view its readings (with MeshCore's normal permission gating). SummitMesh adds the scheduled public broadcast on top — push and pull, from one firmware.

Node roles — one firmware, two builds

A compile-time flag, SUMMITMESH_RELAY, selects how a node presents itself:

Build	Advertises as	Default repeat	Relays the mesh
SUMMITMESH_RELAY=1	repeater	ON	yes
SUMMITMESH_RELAY=0	sensor	OFF	no

Deploy summit/backbone locations as relay builds (they show up as repeater infrastructure on the mesh map); deploy non-critical spots as sensor-only. The flag sets the fresh-install default for relaying — set repeat on/off over the CLI still works and persists afterward.

Repo layout

collector/    Python service: verify, decode, MQTT publish, query responder
firmware/     SummitMesh node firmware (MeshCore example app, repeater-based)
docs/         Architecture, collector and firmware detail, security model

Security model (short version)

• #summitwx is intentionally open — a public channel key can't authenticate senders, so we don't pretend to. Authoritative data lives elsewhere.
• #sensordata integrity = a per-deployment shared secret + keyed SHA-256 MAC over each reading, plus a monotonic per-node counter for replay protection. Forged or replayed packets are dropped by the collector.

See docs/ARCHITECTURE.md for the full design and docs/SECURITY.md for the threat model.

Status

Collector: complete and tested end-to-end (no hardware needed — cd collector && python3 test_pipeline.py). Firmware: structurally complete against verified MeshCore APIs; not yet compiled on hardware (expect minor board-glue fixups). See firmware/summitmesh_node/FIRMWARE.md. Remaining: implement MeshCoreSerialSource (gateway bridge) and a first hardware build.

License

MIT. Built on MeshCore (also MIT).