[Feature Request]: Wired Device Clusters - Multi-Node Cable Connection with Radio Integration

[vgpastor]

Platform

ESP32, NRF52, RP2040

Description

Problem Statement

Currently, Meshtastic devices communicate exclusively via radio (LoRa/WiFi/BLE) or via serial/USB for phone/client connectivity. There is no native support for device-to-device wired communication where multiple Meshtastic nodes can be interconnected via cable (RS-485, CAN, Ethernet) and act as a coordinated cluster while interfacing with the broader mesh network via radio.

Proposed Feature

Implement a Wired Cluster system that allows N Meshtastic devices to be physically connected via cable and function as a coordinated unit with the following capabilities:

Core Concept

Radio Mesh Network
    ↓
  Radio Link
    ↓
┌─────────────────────────────────┐
│   Wired Cluster (Building A)   │
│  ┌──────┐  ┌──────┐  ┌──────┐  │
│  │Node 1│──│Node 2│──│Node 3│  │
│  │Floor1│  │Floor2│  │Floor3│  │
│  └──────┘  └──────┘  └──────┘  │
│    (Connected via RS-485/CAN)   │
└─────────────────────────────────┘
    ↓
  Radio Link
    ↓
┌─────────────────────────────────┐
│   Wired Cluster (Building B)   │
│  ┌──────┐  ┌──────┐             │
│  │Node 4│──│Node 5│             │
│  └──────┘  └──────┘             │
└─────────────────────────────────┘

Key Features

1. Guaranteed Distribution: When any node receives a packet (via radio or locally), it's distributed to ALL cluster members via cable
2. Distributed Retransmission: ALL nodes in the cluster retransmit received packets via radio with staggered timing
3. Maximum Coverage: Multiple simultaneous transmissions from different physical locations provide omnidirectional coverage
4. Spatial Diversity: Different propagation paths increase probability of successful delivery to remote nodes
5. Cable as Backbone: Wired connection ensures no cluster member misses a packet, even if radio reception fails
6. Redundancy: If one node fails or has poor radio conditions, others compensate automatically
7. Transparent Operation: External mesh nodes see the cluster as a single node (optional distributed mode available)

Use Cases

1. Multi-Story Building Coverage

Building with 3 floors:
- Floor 1: Node A (entrance, cable connected)
- Floor 2: Node B (living area, cable connected)
- Floor 3: Node C (roof, cable connected)

When a remote node transmits:
- Only Node C receives via radio (RSSI: -85 dBm) - Floors 1-2 blocked
- Node C distributes packet to A and B via cable (guaranteed)
- ALL nodes retransmit via radio with staggered timing:
  * Node C (0ms delay): Covers North side
  * Node B (2ms delay): Covers Center/East side
  * Node A (4ms delay): Covers South/entrance side
- Result: Omnidirectional coverage from building, maximum reach

2. Rural Installation

Farm with multiple buildings:
- Main Building: 3 nodes via RS-485 (tower, office, workshop)
- Barn (500m away): 2 nodes via RS-485
- Radio link connects the two clusters

When Main Building receives a message:
1. Any node that receives it distributes via cable to others
2. All 3 nodes retransmit from different positions
3. Barn has 3 different propagation paths to receive from
4. Probability of successful delivery: ~99% vs ~70% single node

3. Mobile Applications

Vehicle with multiple antennas:
- Front roof antenna
- Rear roof antenna    ← Connected via CAN bus
- Side-mounted antenna

Provides spatial diversity as vehicle moves

Technical Architecture (High-Level)

Proposed Components

1. WiredInterface (extends RadioInterface)

• Acts as a "virtual radio" over cable
• Handles packet transmission/reception via physical cable
• No airtime restrictions (cable has higher bandwidth than LoRa)

2. WiredCluster (new class)

• Manages cluster membership and discovery
• Distributes packets to all cluster members via cable
• Coordinates staggered retransmission timing to minimize collisions
• Handles deduplication to prevent infinite loops
• Synchronizes configuration (NodeDB, Channels, etc.)

3. WiredBusInterface (abstraction layer)

• Supports multiple physical transports:
  • RS-485 (low cost, up to 1200m, 32+ devices)
  • CAN Bus (robust, automotive-grade)
  • Ethernet (high speed, requires switch)

4. Wire Protocol

Message Types:
- PACKET_DISTRIBUTION: "I have packet X, everyone should retransmit it"
  * Contains full MeshPacket payload
  * Sender's member_id for tracking
  * Packet_id for deduplication
- CLUSTER_DISCOVERY: Auto-discover cluster members at startup
- CLUSTER_HEARTBEAT: Periodic keepalive from each member
- CLUSTER_SYNC: Synchronize state/configuration between members

Simplified protocol: No election needed since ALL nodes retransmit

Operation Modes

Mode 1: Transparent Cluster (Recommended Initial)

• All cluster members share the same Node ID
• External mesh sees cluster as a single device
• Internal coordination invisible to mesh
• Advantage: No changes to existing mesh protocol

Mode 2: Distributed Cluster (Advanced)

• Each member has individual Node ID
• Members share a Cluster ID
• More flexibility but requires routing modifications

TX Coordination Strategy

Philosophy: ALL cluster members retransmit for maximum coverage and reliability

Approach: Distributed Retransmission with Staggered Timing

Scenario 1: Single node receives via radio
─────────────────────────────────────────
1. Node C (roof) receives packet via radio
2. Node C immediately sends PACKET_DISTRIBUTION via cable
3. Nodes A and B receive packet via cable (guaranteed delivery)
4. ALL nodes schedule retransmission with staggered delays:
   - Node A (member_id=1): delay = 0ms → transmits first
   - Node B (member_id=2): delay = 2ms → transmits second
   - Node C (member_id=3): delay = 4ms → transmits third
5. Result: 3 transmissions from different physical locations
   → Maximum spatial diversity
   → ~99% delivery probability vs ~70% single node

Scenario 2: Multiple nodes receive same packet
───────────────────────────────────────────────
1. Nodes A and C both receive via radio simultaneously
2. Both send PACKET_DISTRIBUTION via cable
3. All nodes detect duplicate via packet_id matching
4. Deduplication: Already processed → ignore duplicate
5. ALL still retransmit once with their assigned delays
6. Result: Still only 3 transmissions (dedup prevents extras)

Scenario 3: Locally generated message
──────────────────────────────────────
1. User on Node B sends text message
2. Node B sends PACKET_DISTRIBUTION via cable
3. Nodes A and C receive via cable
4. ALL nodes retransmit via radio with staggered delays
5. Result: Message propagates from 3 locations simultaneously

Key Design Decisions:

• Staggered timing (2ms per node): Reduces direct collisions between cluster members
• Deduplication by packet_id: Each packet processed exactly once, even if received multiple times
• No election protocol: Simpler implementation, no coordination overhead
• Cable guarantees delivery: Even nodes with poor radio reception get the packet and can retransmit

Loop Prevention and Deduplication

Challenge: When Node A retransmits via radio, Node B (same cluster) might receive it again via radio, creating potential loop.

Multi-Layer Solution:

1. Primary Defense - Packet ID Cache (10-second window)

   • Each node maintains recently_processed_packets set
   • Contains packet_id of all packets seen in last 10 seconds
   • If packet_id already in cache → ignore completely
   • Works for packets received via radio OR cable

2. Secondary Defense - TTL in Cable Messages

   • Cable messages have TTL=1 (not forwarded again to cable)
   • Prevents cable-to-cable loops

3. Existing Mesh Protection

   • Leverage existing PacketHistory deduplication
   • Hop limit prevents infinite mesh propagation
   • Flood routing already handles duplicate detection

Example Loop Prevention:

1. Node A receives packet ID 12345 via radio
2. Adds 12345 to recently_processed_packets
3. Distributes via cable to B and C
4. All three retransmit via radio
5. Node B receives Node A's retransmission via radio
6. Checks cache: 12345 already processed → IGNORE
7. No loop occurs

Result: Each unique packet is retransmitted exactly once per cluster member, regardless of how many times it's heard.

Benefits

✅ Maximum Coverage: Multiple simultaneous transmissions provide omnidirectional reach
✅ Extreme Reliability: ~99% delivery probability vs ~70% with single node
✅ Spatial Diversity: Different propagation paths overcome obstacles and interference
✅ Guaranteed Distribution: Cable ensures all cluster members get every packet
✅ Graceful Degradation: System continues working even if some nodes fail
✅ Obstruction Resilient: Walls, buildings, terrain affect each path differently
✅ Extended Range: Cable can span hundreds of meters (1200m for RS-485)
✅ Cost Effective: RS-485 hardware ~$0.50 per node
✅ Backward Compatible: Transparent to existing mesh nodes
✅ No Protocol Changes: Uses existing MeshPacket format (in Transparent mode)

Trade-off: Increased airtime usage (N transmissions per packet) in exchange for maximum reliability and coverage. Ideal for critical infrastructure, emergency communications, or areas where reliability matters more than bandwidth efficiency.

Configuration (Protobuf Extension)

message WiredClusterConfig {
    bool enabled = 1;

    enum ClusterMode {
        TRANSPARENT = 0;  // Shared Node ID
        DISTRIBUTED = 1;  // Individual Node IDs
    }
    ClusterMode mode = 2;

    uint32 cluster_id = 3;
    uint32 member_id = 4;

    enum BusType {
        RS485 = 0;
        CAN = 1;
        ETHERNET = 2;
    }
    BusType bus_type = 5;

    uint32 bus_baudrate = 6;
    uint32 bus_pins_tx = 7;
    uint32 bus_pins_rx = 8;
    uint32 bus_pins_de = 9;  // Driver Enable for RS-485

    bool bridge_to_mesh = 10;

    // Retransmission control
    uint32 tx_delay_per_member_ms = 11;  // Default: 2ms stagger between nodes
    bool retransmit_all = 12;  // Default: true (all nodes retransmit)

    // Optional: Selective retransmission (future enhancement)
    repeated uint32 retransmit_port_nums = 13;  // If set, only retransmit these port numbers
}

Implementation Phases

Phase 1: Basic P2P (Foundation)

• Two devices connected via cable
• Basic packet forwarding
• RS-485 implementation for ESP32

Phase 2: Multi-Device Discovery

• N devices on cable with auto-discovery
• Member table management
• Heartbeat and health checks

Phase 3: Distributed Retransmission (Critical)

• Implement staggered timing based on member_id
• Collision avoidance through time slots
• Deduplication by packet_id
• All nodes retransmit with coordinated delays

Phase 4: Transparent Cluster

• Shared Node ID
• NodeDB synchronization
• Configuration persistence

Phase 5: Loop Prevention & Optimization

• Robust deduplication
• Metrics and telemetry
• Performance tuning

Phase 6+: Advanced Features

• Distributed mode
• Additional bus types (CAN, Ethernet)
• QoS and intelligent routing

Airtime and Duty Cycle Considerations

Impact: Each packet results in N transmissions (where N = cluster size)

Airtime Analysis

Region	Duty Cycle	Max Airtime/hour	Single Node (packets/hr)	3-Node Cluster (packets/hr)
EU868	1% (36s/h)	36 seconds	~360	~120
US915	None	Unlimited	Thousands	Thousands

For EU868 (duty cycle restricted):

• A 3-node cluster uses 3x the airtime
• Reduces packet capacity to 1/3
• Mitigation strategies:
  1. Selective retransmission: Only retransmit critical messages (TEXT, POSITION, NODEINFO)
  2. Configurable per port number
  3. Time-based throttling during high traffic

For US915 (no duty cycle):

• No restrictions
• Ideal for this approach
• Full redundancy without regulatory concerns

Configuration Example

// For duty-cycle-limited regions
retransmit_all = false;
retransmit_port_nums = [
    PortNum_TEXT_MESSAGE_APP,
    PortNum_POSITION_APP,
    PortNum_NODEINFO_APP
];
// Telemetry not retransmitted to save airtime

Recommendation: Start with US915 testing, add selective retransmission for EU868 compliance.

Hardware Requirements

Minimal setup (RS-485):

• ESP32 with 2+ UARTs available
• MAX485 or SP485 transceiver (~$0.50)
• Two-wire cable (twisted pair recommended)
• 120Ω termination resistors

Supported platforms (initial target):

• ESP32 (3 UARTs available)
• nRF52 (1+ UART available after Serial0)
• STM32WL (multiple UARTs)

Questions for Community

1. Is anyone already working on something similar?
2. What are the preferred use cases? (building, rural, mobile, emergency comms, other)
3. Transport preference? RS-485, CAN, Ethernet, or all?
4. Typical cluster size? 2-3 nodes or 10+ nodes?
5. Power supply? PoE, shared DC, or independent batteries?
6. Should this be a separate module or core feature?
7. Airtime concerns: Is 3x airtime usage acceptable for use cases requiring maximum reliability?
8. Regional priority: Should we optimize for US915 (no duty cycle) first, or EU868 (duty cycle limited)?
9. Selective retransmission: Should we support per-port-number filtering from day one, or add later?

Related Work

• SerialModule: Currently handles UART for phone/PC connectivity
• StreamAPI: Already has 0x94C3 framing for serial communication
• PacketHistory: Deduplication infrastructure exists
• RadioInterface: Abstract interface allows adding new transport types

This feature would extend existing abstractions rather than replace them.

Willingness to Contribute

I am willing to implement this feature and submit PRs. Before starting development, I would like community feedback on:

• Architecture validation: Is distributed retransmission (all nodes TX) acceptable given airtime trade-offs?
• Transparent vs Distributed mode priority: Which should be implemented first?
• Transport layer priority: RS-485, CAN, or Ethernet first? (Leaning toward RS-485 for cost/simplicity)
• Duty cycle strategy: Implement selective retransmission from Phase 1, or add later?
• Integration points: Any conflicts with existing RadioInterface implementations?
• Testing methodology: Hardware setups and validation criteria

Initial Approach: Planning to start with:

1. RS-485 transport on ESP32
2. Transparent Cluster mode (shared Node ID)
3. All nodes retransmit (no selective filtering initially)
4. Target US915 region first (no duty cycle constraints)
5. Add EU868 optimizations in later phase

References

• Existing exploration in fork: vgpastor/meshtastic-firmware branch claude/plan-wired-protocol-QVOm7
• Similar concepts in other mesh systems (Zigbee coordinator clustering, Bluetooth mesh relay nodes)

Why This Approach?

Compared to traditional mesh repeaters:

• Traditional: Single device in optimal location
• Wired Cluster: Multiple devices in different locations acting as one unit
• Advantage: Overcomes line-of-sight limitations, walls, and local interference

Compared to just adding more independent nodes:

• Independent nodes: Each acts selfishly, may miss packets
• Wired Cluster: Cable guarantees every member receives every packet
• Advantage: No member left behind, even with poor radio conditions

Philosophy:

• Reliability over Efficiency: Use more airtime but guarantee delivery
• Infrastructure over Ad-hoc: Suitable for permanent installations (buildings, sites)
• Coordination over Competition: Nodes cooperate via cable rather than competing for airtime

Ideal For:

• Fixed installations (homes, buildings, farms)
• Emergency communication infrastructure
• Critical message delivery (safety, alerts)
• Areas with complex RF propagation (urban, multi-floor)

Not Ideal For:

• Mobile/portable deployments (cable impractical)
• Bandwidth-constrained networks (duty cycle limits)
• Networks with mostly non-critical traffic (telemetry)

---

Looking forward to feedback and discussion from the community!

[github-actions]

@vgpastor, Welcome to Meshtastic! 👋

Thanks for opening your first issue. If it's helpful, an easy way
to get logs is the "Open Serial Monitor" button on the Web Flasher.

If you have ideas for features, note that we often debate big ideas
in the discussions tab
first. This tracker tends to be for ideas that have community
consensus and a clear implementation.

We're very active on discord,
especially the #firmware and #alphanauts-testing channels. If you'll
be around for a while, we'd love to see you there!

Welcome to the community! ❤️

[vgpastor]

#9282

[Xaositek]

I feel like a simple network (ethernet or WiFi) you can use UDP to do this?

Technically you could even use a crossover cable between two nodes with static IPs and this would work.

[vgpastor]

I feel like a simple network (ethernet or WiFi) you can use UDP to do this?

Hi! Using a network cable would be a great solution, but so far we haven't been able to use a network cable to forward packets as if it were another radio, allowing us to maintain communication not just between two nodes, but between multiple nodes.

Have you been able to test it with UDP packet transmission? Could you give us feedback or tell me about your experience?

[vgpastor]

Additionally, my first idea it's not need additional boards to connectivity, use the ESP32 available connectors or cards that only requires minimum ports available

[Xaositek]

Look at https://store.rakwireless.com/products/wismesh-ethernet-gateway which allows Ethernet built in. This would likely work well for your application. Otherwise any ESP32 with something like a GLiNet router for WiFi would work fine

[github-actions]

This issue has not had any comment or update in the last month. If it is still relevant, please post update comments. If no comments are made, this issue will be closed automagically in 7 days.

[github-actions]

This issue has not had any comment since the last notice. It has been closed automatically. If this is incorrect, or the issue becomes relevant again, please request that it is reopened.