Ein Room Server ist ein schwarzes Brett mit Gedächtnis. Wer nicht dabei war, holt sich die Nachrichten nach – bei einem normalen Kanal wären sie weg.
| Wie es sich anfühlt | |
|---|---|
| Kanal | Radio. Wer gerade nicht zuhört, hat es verpasst. Endgültig. |
| Room Server | Anrufbeantworter. Du schaust später rein und liest nach, was aufgelaufen ist. |
Ein Kanal ist live und flüchtig: Ist dein Gerät aus, außer Reichweite oder im Rucksack, ist die Nachricht für dich nie passiert. Es gibt keine Zustellgarantie und keine Historie.
Beim Room Server meldest du dich mit deinem Companion an. Danach kennt der Server dich. Alles, was im Raum gepostet wird, liegt in seinem Speicher – beim nächsten Verbinden holst du ab, was seit deinem letzten Mal dazugekommen ist.
Die drei Rollen machen drei verschiedene Dinge:
| Rolle | Job | Speichert? |
|---|---|---|
| Repeater | Reichweite. Hört ein Paket und ruft es weiter | nein, kennt die Inhalte gar nicht |
| Companion | dein Gerät. Sendet und empfängt für dich | nur, was dein Handy behält |
| Room Server | Gruppenchat mit Verlauf | ja, das ist sein ganzer Zweck |
Ein Room Server leitet zusätzlich weiter, wie ein Repeater. Das ist in der Firmware so vorgesehen und ab Werk an – ein Standortknoten kann also beides gleichzeitig sein. Abschalten geht mit
set disable.fwd 1, wenn er ausschließlich Raum sein soll.Geprüft an
meshcore-dev/MeshCore,examples/simple_room_server/MyMesh.cpp:300–allowPacketForward()gibttruezurück, solangedisable_fwdaus ist und die Hop-Grenzen nicht erreicht sind.
Was ihm gegenüber dem Repeater fehlt: die Schleifenerkennung und die Regionsprüfung. Als tragende Infrastruktur an einem wichtigen Standort ist ein reiner Repeater deshalb die sauberere Wahl.
Für spontanes Geplauder ist der offene Kanal besser – ein Room Server verlangt, dass man sich verbindet und abholt.
Er braucht Dauerstrom. Ein Solarknoten, der nachts wegnickt, taugt nicht – der Sinn der Sache ist ja, dass er da ist, wenn du nicht da warst.
Zwei Passwörter, und beide Vorgaben sind heikel:
| Einstellung | Vorgabe | Wofür |
|---|---|---|
password <neu> |
password |
Admin: Rechte vergeben, Zugriffsliste, Konfiguration |
set guest.password <neu> |
leer, aus dem Build-Flag ROOM_PASSWORD |
normale Nutzer, die lesen und posten |
set allow.read.only <on\|off> |
off |
on erlaubt Anmeldung ohne Passwort — dann aber nur Lesen |
Das Admin-Passwort ist ab Werk password. Wer es kennt, landet in der Admin-Liste und darf alle CLI-Befehle. Als Erstes ändern.
Der Login prüft gegen beide Passwörter, Admin zuerst. Daraus folgt:
allow.read.only off → niemand kommt hineinallow.read.only on → alle kommen ohne Passwort hinein, können aber nichts posten. Der Beitritt sieht aus, als hätte er geklappt, bis jemand schreiben willOb euer Build ab Werk ein Gastpasswort mitbringt, prüfst du am Gerät mit
get guest.password. Die offizielle Doku führt den Wert als leer, mehrere Community-Anleitungen nennenhelloals eingebaute Vorgabe. Setz in jedem Fall ein eigenes.
Werkseinstellung, geprüft an meshcore-dev/MeshCore (examples/simple_room_server/MyMesh.h, Firmware v1.17.0):
| Wert | |
|---|---|
| Beiträge im Puffer | 32 |
| Zeichen pro Beitrag | 151 |
| Bekannte Clients | 20 |
Das sind zusammen keine 5 kB Text. Der Puffer läuft um: Ist der 33. Beitrag da, fällt der erste raus – auch wenn ihn noch niemand abgeholt hat.
Das ist ein Nachhol-Puffer, kein Archiv. Wer eine Woche im Urlaub war und in der Zwischenzeit sind 50 Beiträge aufgelaufen, bekommt die ersten 18 nie zu sehen.
Praktisch heißt das: Ein Room Server trägt eine ruhige Gruppe über Tage. Er trägt keine lebhafte Diskussion über eine Woche. Und bei 20 Client-Plätzen ist er ein Werkzeug für eine Ortsgruppe, nicht für ein Bundesland.
Die Grenzen lassen sich beim Bauen der Firmware hochsetzen (MAX_UNSYNCED_POSTS, MAX_CLIENTS), kosten dann aber RAM – und der ist auf einem ESP32 oder nRF52 die eigentliche Schranke.
Hier steckt der Haken, den man beim Aufstellen leicht übersieht.
Der Server schickt jeden Beitrag einzeln an jeden Client. Nicht einmal in die Runde – einzeln. Fünf Leute holen zehn Beiträge nach, das sind 50 Pakete, die der Server sendet. Jedes davon läuft über den Weg zum jeweiligen Client, und jeder Hop unterwegs ist eine weitere Sendung → Best Practises
Was das kostet, bei vollen Paketen mit CR8 (1132 ms):
| Server steht … | Sendungen je Beitrag | 10 Beiträge an 5 Leute |
|---|---|---|
| in Reichweite der Nutzer, 0 Hops | 1 | 57 Sekunden Netzsendezeit |
| 1 Repeater dazwischen | 2 | 113 Sekunden |
| 3 Repeater dazwischen | 4 | 226 Sekunden |
Zur Einordnung: Das Stundenbudget eines Geräts sind 360 Sekunden. Ein schlecht platzierter Room Server verbrennt bei einem einzigen Nachhol-Schub den halben Tagesbedarf des halben Netzes – und der Server selbst rennt als Erstes ins eigene Limit, weil alle 50 Pakete von ihm kommen.
Gut: Der Server steht dort, wo seine Leute sind. Wenige oder gar keine Hops zwischen ihm und den Nutzern. Lieber ein Room Server pro Ortsgruppe als einer für ganz Kärnten.
Schlecht: Der Server steht weit weg und ist nur über drei Repeater erreichbar. Dann zahlt jede einzelne nachgeholte Nachricht den vollen Aufschlag – und zwar auf Kosten aller anderen, die sich das Band teilen.
Nahe am Backbone ist nicht dasselbe wie oben auf dem Backbone. Ein Room Server am Standort eines vielbeschäftigten Repeaters teilt sich mit diesem die Luft – und weil er ab Werk selbst weiterleitet, kommt der fremde Durchgangsverkehr obendrauf. Wenn er dort stehen muss:
set disable.fwd 1, dann spart er sein Budget für das, wofür er da ist.
Faustregel: Erst schauen, wer den Raum nutzen soll. Dann einen Standort suchen, der diese Leute direkt erreicht. Reichweite über halb Kärnten ist beim Room Server kein Vorteil, sondern eine Rechnung.
Nein. Dafür braucht es ein zweites Gerät.
Ein Observer meldet jedes gehörte Paket an die Karte. Das Programm, das die Meldungen abholt, spricht das binäre Companion-Protokoll – und das gibt es nur in der Companion-Firmware, über Bluetooth, USB oder TCP auf Port 5000. Die Room-Server-Firmware bringt keine dieser Schnittstellen mit; sie hat nur die Textkonsole zum Konfigurieren.
Geprüft an
meshcore-dev/MeshCore:examples/companion_radio/main.cppbindetMultiSerialInterface, BLE, WLAN-TCP und USB ein.examples/simple_room_server/main.cppbindet keine davon ein.
Dasselbe gilt für Repeater und für meshinfra – beides braucht einen Companion als Anschlusspunkt.
Das ist kein großes Problem: Ein Heltec V3 für den Observer kostet rund 20 €. Beide Geräte am selben Standort stören sich nicht, sie hören einander nur.
Das ist ein echter Login, kein Chat-Öffnen. Dein Gerät schickt eine Anmeldung mit Passwort, der Server prüft sie gegen beide hinterlegten Passwörter — erst das Admin-, dann das Gastpasswort. Passt das Gastpasswort, bekommst du Gastrechte, und der Raum wird zum Gesprächsfaden in der App.
Die genauen Beschriftungen in der App stehen hier bewusst nicht. MeshCore dokumentiert die Bedienoberfläche nirgends —
docs.meshcore.iobehandelt CLI, Paketformate und Companion-Protokoll, aber keine App-Ansicht. Wer den Weg gegangen ist: bitte hier eintragen.
| Symptom | Ursache |
|---|---|
| Raum taucht nicht auf | Advert noch nicht gehört. Warten oder den Kontakt von Hand anlegen. Vorher die Funkparameter prüfen — ein abweichender Wert macht dich taub, ohne Fehlermeldung |
| Beitritt geht, Schreiben nicht | Der Server steht auf allow.read.only on. Die Anmeldung mit leerem Passwort wird angenommen, Posten nicht. Sieht bis zum ersten Schreibversuch nach Erfolg aus. Nur der Betreiber kann das ändern |
| Passwort abgelehnt | Das Gastpasswort gibt es beim Betreiber, nicht im Wiki |
| Alles zäh | Anmelden und Abholen sind Hin und Zurück, kein passives Mitlesen wie am Kanal. Über mehrere Hops kostet das entsprechend → Direktnachrichten |
Ein Beitrag darf 151 Zeichen haben. Der Server hält 32 unsynchronisierte Beiträge für bis zu 20 Clients, zyklisch — der älteste fällt heraus, auch wenn ihn noch niemand abgeholt hat.
allow.read.only| Name | Standort | Zuletzt gehört |
|---|---|---|
AT-SP-Spittal |
46,7989 / 13,4977 | aktiv (18.08.2026) |
AT-KL-WFR-RS |
Klagenfurt-Land | aktiv, meldet zugleich als Observer an letsmesh.net |
S-G-K Room |
Klagenfurt (46,675 / 14,281) | 07.08.2026, seither verschwunden |
Betreiber und Gastpasswort sind bei keinem dokumentiert. Wer hinein will, fragt auf #at-ktn — Passwörter gehören nicht in ein öffentliches Wiki.
S-G-K Room folgt nicht dem Namensschema AT-<Bezirk>-<Name> und war deshalb auf der Karte schwer zuzuordnen → Repeaterliste
Wenn du ihn betreibst oder einen weiteren aufstellst: hier eintragen.
Mehr zu den Rollen → Rollen
Start · Schnellstart · Rollen · Firmware flashen · Funkeinstellungen · Kanäle · Geräte · Repeater · Repeaterliste · Repeater Setup Guide · Observer · meshinfra · MeshBot · Karte · FAQ · Glossar · Mitmachen · Alle Themen