[Lora]

MeshCore gegen Meshtastic: Wie aus Frust ein besseres Funknetz wurde

/meshcore-gegen-meshtastic-wie-aus-frust-ein-besseres-funknetz-wurde

Es gibt Konflikte in der Technikszene, die von außen wirken wie ein Sturm im Wasserglas. Zwei Open-Source-Projekte, kein Geld im Spiel, niemand verkauft Lizenzen – wozu dieser Krach? Beim Streit zwischen **Meshtastic** und **MeshCore** liegt der Grund tiefer. Hier prallen zwei Vorstellungen aufeinander, wofür ein LoRa-Mesh gedacht ist: Spielplatz oder verlässliches Werkzeug. Wer das nüchtern betrachtet, erkennt schnell, warum sich Lager gebildet haben und warum viele den Weg Richtung MeshCore einschlagen.

Wie es dazu kam

Meshtastic hat die Idee „Chat und Telemetrie über LoRa“ groß gemacht. Günstige Hardware, mobile Apps, eine wachsende Community – das zog viele an. Mit der Zeit zeigten sich aber die Grenzen der Architektur.

Flood-Routing ist bequem, aber ineffizient:
Ein Knoten ruft „in den Wald“, alle rufen weiter, bis das Hop-Limit erreicht ist. Für Demos, Wandergruppen und kleine Netze reicht das. Sobald ein Netz wächst, bricht die Effizienz ein:

  • zu viel Airtime
  • zu viele Duplikate
  • zu viel Zufall

Genau dort steckt Meshtastic bis heute fest.

Aus diesem Frust entstand MeshCore. Statt zusätzliche Funktionen in ein überladenes Konzept zu pressen, setzte MeshCore auf das, was große Netze überhaupt erst tragfähig macht: gezieltes Routing, klare Rollen, saubere Konfiguration – und kein Funktionschaos.


Was MeshCore technisch anders macht

Der entscheidende Unterschied ist simpel: MeshCore routet direkt.
Nicht jeder leitet alles weiter, sondern nur der nächste sinnvolle Hop.

Das klingt trivial, ist aber die Stellschraube, an der sich alles entscheidet:

  • stabile Airtime
  • berechenbarere Latenzen
  • segmentierbare Netze
  • gezielte Verbindungen statt Zufall

Dazu kommt eine klare Trennung der Aufgaben:

  • Repeater
  • Room-Server
  • Companion-Geräte

Jedes Element hat eine eindeutige Verantwortung. Zugriffe lassen sich beschränken, Zonen definieren, Regionen über WLAN oder Ethernet koppeln. Das Ergebnis ist kein Bastelzoo, sondern ein System, mit dem man Netze plant, betreibt und langfristig skaliert.


Warum der Streit so hochkochte

Reibung war unvermeidlich. Meshtastic-Entwickler fühlten sich anfangs übergangen, kritisierten fehlende Attribution in frühen MeshCore-Dateien und die bewusste Inkompatibilität.

Auf der anderen Seite stand die praktische Frage:
Will man ein stabiles, skalierbares Netz – oder das nächste neue Feature, das in ein paar Wochen wieder komplett umgebaut wird?

Rechtlich ist heute alles entspannt:
Open Source bleibt Open Source. Lizenzen stimmen, die Herkunft ist dokumentiert.

Moralisch blieb allerdings ein Kratzer. Wer jahrelang Energie in ein Projekt steckt, sieht ungern, wie ein Fork in kurzer Zeit die professionelleren Anwendungsfälle abräumt und viele Nutzer mitnimmt.


Kultur prallt auf Kultur

Der eigentliche Unterschied liegt im Umgang.

Meshtastic:
- zentrale Führung
- viele Ideen
- häufige Umbauten

MeshCore:
- dezentral
- pragmatisch
- wenig Show

Kein Chef, der alles entscheidet, sondern Maintainer, die nach Nutzen und Stabilität urteilen. Setzt sich ein Ansatz im Feld durch, wird er genutzt – nicht aufgrund eines Beschlusses, sondern weil er funktioniert.

Wer Infrastruktur betreibt, merkt den Unterschied sofort:
weniger Zeit für Versionssprünge und Brüche, mehr Zeit für Planung und Betrieb. Trocken, aber zuverlässig.


Wechselt „die Szene“?

Technisch versierte Nutzer und manche Entwickler schwenken zunehmend um – weg vom nächsten Feature-Event, hin zu verlässlicher Stabilität.

  • Meshtastic bleibt riesig und einsteigerfreundlich
  • MeshCore wächst langsamer, aber mit klarer Richtung

Zusätzlich macht sich Meshtastic derzeit mit seiner Moderationspraxis unbeliebt. Es mehren sich Berichte, dass im Subreddit r/meshtastic Beiträge und Kommentare mit dem Wort „MeshCore“ automatisch gefiltert oder gelöscht werden und dass Nutzer dafür gesperrt wurden. Ähnliche Meldungen gibt es aus dem Discord-Bereich.

Solche Keyword-Filter wirken wie Zensur, kommen schlecht an und erzeugen den Eindruck, Abwanderung verhindern zu wollen.


Was sollte man tun?

Der Einstieg ist bei beiden Projekten leicht:

  1. Board flashen
  2. App koppeln
  3. los geht’s

Meshtastic passt, wenn man:
- gern bastelt
- MQTT nutzt
- Sensoren einbindet
- Integrationen wie Home Assistant schätzt

MeshCore passt, wenn man:
- schlichten, zuverlässigen Nachrichtenversand will
- möglichst wenig Nachjustieren möchte
- Netze länger betreibt statt ständig umbaut

Einschalten, konfigurieren, laufen lassen.


Fazit

Der Konflikt war unvermeidlich, weil zwei Ziele kollidieren:

  • maximale Flexibilität
  • minimale Störungen

Meshtastic hat die Idee populär gemacht – das verdient Anerkennung.
MeshCore hat sie technisch sauber und nachhaltig umgesetzt.

Deshalb greift man bei größeren Flächen, höheren Lasten und klaren Anforderungen eher zu MeshCore.

Für kleine Gruppen und spontane Einsätze bleibt Meshtastic ideal.
Für Netze, die man verantworten muss, führt früher oder später kaum ein Weg an MeshCore vorbei – nicht aus Prinzip, sondern wegen der technischen Konsequenz.

Es ist Open Source. Beide Wege dürfen existieren.
Am Ende wählt man den Weg, der schneller zum Ziel führt.

Genau das tun immer mehr – leise, ohne Drama.
Und die Funkstrecken bleiben ruhig.

Anzeige

/comments0 Einträge

Kommentare

> NO_COMMENTS_FOUND

> INITIATE_COMMENT_PROTOCOL

MARKDOWN_SUPPORT: ENABLED
CHARS: 0