← Build · guide
Pair your nodes
You've built a leaf (sampling and queuing, slow-blinking discovering) and a gateway (announcing itself on the network). Pairing is how they find each other so the queued readings reach a spreadsheet you own. It's one config value and a restart, and the moment it connects, the leaf's whole backlog drains.
Pair them
-
Grab the gateway's identity hash
On the gateway,
journalctl -u egress-gatewayprints its identity hash at startup. Copy it down. It's the gateway's cryptographic address, and the one thing the leaf needs in order to trust it. -
Tell the leaf to trust it
On the leaf, set
gateway_identity_hashin/etc/mycelium-network-leaf/config.tomlto that hash, then runsudo systemctl restart leaf-node. That is the whole pairing, one config value. -
Watch them find each other
The leaf hears the gateway's announce and opens an encrypted link. Its LED goes from the slow-blink discovering to a solid connected on the first delivery, and its queued backlog drains. In the journal you'll see something like
delivered 3 reading(s) (rows …), 0 still queued. -
See it land
A
temp_crow appears in the spreadsheet your gateway forwards to. That is the whole path running end to end, from sense → encrypt → relay → gateway → your sheet.
Now prove it's robust with the gateway-outage drill
Pull the gateway's power mid-batch. The leaf keeps
sampling and buffers to disk (its LED goes to the fast-blink fail).
Restore power and it reconnects, then drains everything in order, with
nothing lost and nothing out of sequence. There's a script in the repo
(drill-gateway-outage.sh) that runs exactly this and checks
the count, and it should report zero readings lost.
Why a hash, and why neither node has to trust the other
The leaf addresses the gateway by its cryptographic identity hash, and the gateway rate-limits and logs by the leaf's identity hash. Both are authenticated by Reticulum, so a leaf can't impersonate another, and neither operator has to trust, or even know, who runs the other node. That is what lets strangers' networks strengthen each other. They share radio waves and nothing else.
The leaf's LED, decoded
| solid off | the service isn't running |
| slow blink (1 Hz) | discovering, looking for a gateway to announce |
| solid on | connected, the last reading was delivered |
| fast blink | the last transmit failed (see troubleshooting) |
Troubleshooting
- Leaf stuck slow-blinking discovering: the
gateway_identity_hashis wrong or empty, the gateway isn't announcing (checkjournalctl -u egress-gateway), or the two are out of radio range. - LED fast-blinking (fail): the link reached the gateway but it rejected the forward. The destination isn't in the gateway's
allowed_hosts, the leaf hit its rate limit, or the request was too big. The gateway journal says which. - Delivers, but no row in the spreadsheet: that's the destination end, so check the Apps Script URL and the sheet's permissions on the gateway side.
What this proves, and what it doesn't
It proves the complete delivery path end to end, auto-discovery by announce, encrypted addressing with no mutual trust required, and the outage spool-and-drain. It's a real two-node network on your bench.
It doesn't prove multi-hop relay across several nodes, real-world radio range, or power. Those come with more nodes and the field build, once they have survived real weather.