Building a Home Meshtastic Gateway

At some point the hobby stopped being “flashing firmware on dev boards” and quietly became infrastructure.

A Heltec V3 and a LilyGO T-Beam were set up to experiment with Meshtastic. What emerged was a functioning home gateway that bridges local RF traffic to the global MQTT mesh.

Two small boards. A cleaner architecture. A lot learned.

The Hardware

Heltec V3

• Always powered
• Connected to home Wi-Fi
• Configured as a CLIENT gateway
• Running Long Range – Fast
• Hop limit set to 3
• MQTT + JSON enabled
• GPS disabled

LilyGO T-Beam

• Battery powered
• Connected via Bluetooth to a phone
• Configured as a CLIENT
• Hop limit set to 3

The Heltec is the powered gateway node.

The T-Beam is the portable interface device.

Important Hardware Reality

On the Heltec V3, stable Wi-Fi operation requires the device to run in CLIENT mode. While it can act as a router in pure RF scenarios, maintaining Wi-Fi and MQTT connectivity is more reliable when configured as a client.

So in this architecture:

• The Heltec is not acting as a full-time RF backbone router.
• It is acting as a powered Wi-Fi-connected MQTT gateway.
• A future dedicated solar router (likely a WisBlock build) will handle permanent RF infrastructure duties.

Clear roles reduce confusion.

The Architecture

The topology looks like this:

T-Beam (portable client)
↓ RF
Heltec (powered client gateway)
↓ Wi-Fi
MQTT global mesh

The T-Beam speaks RF.

The Heltec participates in the mesh and publishes mesh traffic to MQTT when Wi-Fi is active.

MQTT connects the local mesh to the internet mesh.

Messages can now:

• Travel locally over LoRa
• Be heard by the Heltec
• Be forwarded to the global MQTT broker
• Appear from nodes hundreds of miles away

Not magic. Just layered systems working together.

Roles Matter

Separating responsibilities clarified everything.

A powered gateway should be:

• Stable
• Always on
• Network-connected
• Infrastructure-focused

A portable client should be:

• Battery-efficient
• Mobile
• Simple
• RF-focused

Once those responsibilities were separated, the system stopped feeling experimental and started feeling intentional.

MQTT Belongs on a Powered Gateway

Only the Heltec has MQTT enabled.

That means:

• One Wi-Fi bridge
• No redundant internet gateways
• Cleaner mesh behavior
• Longer battery life on portable nodes

The T-Beam benefits from MQTT indirectly through the gateway.

Hops Are About Packet Lifespan

Both nodes use the same hop limit to avoid asymmetric packet lifespan behavior.

Increasing hops does not increase signal strength or range. It only allows a packet to live longer in the mesh before expiring.

That distinction matters.

Hop count controls packet lifespan - not physics.

The Most Interesting Part: Data Access

The Heltec exposes structured data over JSON.

• Node info
• Signal metrics
• Heard nodes
• Telemetry
• Position broadcasts
• MQTT flags

That changes everything.

Instead of just watching packets appear in an app, the system can now be observed programmatically.

The Heltec is no longer just a radio.

It is a data source.

What’s Next

This is where the experiment shifts direction.

1. Building a Coverage Map

The goal:

• Collect position broadcasts
• Track RSSI and SNR values
• Log hop counts
• Store node metadata

From there:

• Plot points on a map
• Visualize signal strength geographically
• Identify dead zones
• Compare presets

A living coverage map.

Not theoretical range.

Observed range.

2. Mining Node Metadata

Every broadcast includes metadata.

Questions worth exploring:

• What firmware versions are common?
• What device types dominate?
• What hop patterns emerge?
• How often do nodes rebroadcast?

The mesh is constantly emitting information.

It just needs to be parsed.

3. Displaying Live Mesh Data on stepweaver.dev

The Heltec JSON can be:

• Polled
• Parsed
• Stored
• Rendered

Potential features:

• Live “nodes heard” list
• Signal strength table
• Recent packet log
• Map overlay
• MQTT vs RF comparison metrics

This turns a hobby node into a public dashboard.

It becomes both infrastructure and portfolio.

4. Elevation and Infrastructure Experiments

Future work may include:

• Raising the antenna
• Testing different coax lengths
• Comparing presets in real-world propagation
• Logging performance differences
• Deploying a permanent solar router node

That router will likely be a RAK WisBlock build:

• Ultra low power
• Solar-ready
• External antenna support
• Dedicated RF backbone role

At that point, the Heltec remains the Wi-Fi gateway.

The WisBlock becomes the RF spine.

Layered architecture. Purpose-built hardware.

Why This Matters

What started as curiosity turned into:

• A home RF gateway
• A bridge to the global mesh
• A programmable telemetry source
• A foundation for mapping and analysis
• The beginning of layered mesh infrastructure

The hardware is simple.

The architecture is not.

The focus has shifted from:

“Can it send messages?”

To:

“What can the mesh reveal?”

And that is far more interesting.