Mesh.edwinmatos.rocks
Sites
← Architecture

Gateway & MQTT Architecture

One gateway, one bridge: why uplink can be redundant but downlink must be singular per RF neighbourhood, or the mesh loops.

Current design · 12 SEP 2026·updated September 12, 2026

Purpose

The mesh runs over RF (LoRa). MQTT is how the mesh optionally connects to the Internet — for the public map, for reaching distant nodes, and for bridging traffic that can’t make it over the air. The design goal here is to connect to the Internet in a controlled way: exactly one door between RF and the Internet, opened just wide enough, so the mesh gains reach without importing loops or flooding the local air with re-injected traffic.

Design: one gateway, one bridge

KYKB is the single MQTT gateway for the KYK fleet. It is the only node running an MQTT connection to the broker (mqtt.meshtastic.org, root msh/US/FL). Every other KYK node is RF-only; none of them talk to the Internet directly.

This makes KYKB the one bridge point between the two worlds:

   RF mesh  <--LoRa-->  KYKB  <--MQTT/Internet-->  broker / map / distant nodes

Concentrating the bridge in a single node is deliberate. It means there is exactly one place where RF traffic can enter the Internet and one place where Internet traffic can enter RF — which is what makes the loop behavior below controllable.

Uplink and downlink — and why only one downlink

MQTT on a Meshtastic gateway has two independent directions, set per channel:

  • Uplink — the gateway publishes RF traffic it hears out to the broker (RF → Internet).
  • Downlink — the gateway injects traffic from the broker into RF (Internet → RF).

Our configuration: uplink ON, downlink OFF on the bridged channel(s), with the single exception described below.

Uplink is what feeds the public map and lets the wider network see the KYK mesh. It is low-risk: publishing what we already transmitted on RF doesn’t create new RF traffic.

Downlink is the direction that creates problems. When a gateway pulls messages from the broker and re-transmits them on RF, those packets re-enter the mesh. If two gateways in RF range of each other both downlink the same channel, you get a loop: gateway A hears a packet on RF, uplinks it to the broker; gateway B downlinks it from the broker back onto RF; gateway A hears it again, uplinks it again — and the same message circulates, each pass consuming airtime, until hop limits and duplicate-detection barely contain it. In a dense area this is a genuine air-time flood.

The rule that prevents this: only ever have a single downlink path into a given RF neighborhood. With one gateway (KYKB) that is automatic — there is no second node to loop against. Downlink is kept off by default even on that one gateway, and turned on only for a specific channel if we actually need Internet→RF delivery, and only because we can guarantee KYKB is the only downlinker in range.

Can we run two gateways?

Yes — but carefully, and only for the uplink side.

  • Two uplink-only gateways are fine and even useful: redundancy for the map feed, better coverage of which RF traffic reaches the broker. Two nodes publishing what they hear can’t loop, because neither injects anything back onto RF.
  • Two downlinking gateways in RF range of each other is the loop condition above and must be avoided. If a second gateway is ever added for coverage, it must be downlink OFF, leaving KYKB (or whichever single node) as the sole Internet→RF injector for that area.
  • If two gateways are far enough apart that they are not in RF range of one another, they can each downlink their own separate neighborhood without looping — but in a compact area like Boca that separation usually doesn’t exist, so the safe default remains: many uplinks OK, one downlink.

Summary rule: uplink can be redundant; downlink must be singular per RF neighborhood.

Other gateway hygiene

  • TLS: kept off (port 1883). On the ThinkNode ESP32 hardware the TLS handshake exhausts RAM and the node silently stops publishing. A GUI save has been observed to flip TLS back on — re-check after any app/web-UI touch, and configure the gateway from the CLI, one field at a time.
  • Encryption on, JSON off to keep the payload small and the heap headroom safe on this hardware.
  • Map reporting / location: the gateway’s own position reporting to the public map is a separate setting from uplink; set it deliberately (approximate precision, or off) rather than leaving it at defaults.
  • One TCP client at a time: the gateway handles a single network/BLE admin client cleanly — disconnect the app before CLI work against it.

Note: KYKB is temporary

KYKB (ThinkNode M2) is the gateway for now. It is a bare board on a UPS USB jack, indoor-only, and shares the same ~250 KB heap ceiling that makes MQTT+TLS and Store-and-Forward tight on this hardware.

It will be replaced by the RAK WisMesh Station HP (RAK8623) when it arrives. The RAK unit is purpose-built for the gateway role — a Linux meshtasticd host with room for Mosquitto, Node-RED, and Store-and-Forward — and will provide better stability as the permanent single bridge. The architecture above does not change with that swap; only the hardware under the “gateway” box does. KYKB reverts to a plain client (or spare) once the RAK is in service.