Neuaufteilung von Knoten anhand der Koordinaten

Am 15.01.2026 haben wir bei den monatlichen Infrastrukturarbeiten 4830.org ein neues Feature unserer Firmware ab 1.4.0~200 / 1.9.0~36 / 2.0.0~34 / 2.1.0~9 getestet: Änderung der Meshzugehörigkeit aufgrund der Knotenkoordinaten mittels des zentralen Setupservers.

Wir hatten dazu 9 Knoten an verschiedenen Koordinaten und gezielt ins Testmesh 99 konfiguriert. Auf dem Setupserver wurde dann hinterlegt, daß Knoten im Testmesh 99 ab 20:05 in das Mesh wechseln, in welchem sie aufgrund ihrer Koordinaten im Bereich des 4830.org e. V. sein sollten.

Der Wechsel selbst hat, Stand 23:00, bei allen bis auf einem Knoten funktioniert, auch Knoten, die durch Wechsel ihres Wirelessuplinks in ein anderes Mesh temporär offline gingen, tauchten binnen 60 Minuten nach dem Startzeitpunkt im neuen Netz auf — Ausnahme ist ein D-Link COVR-X1860 A1 mit 2.0.0~34 / gluon-v2023.2.5+. Ein anderer COVR-X1860 mit ebenfalls 2.0.0~34 ist problemlos umgezogen, @Klaus.P wird dem noch nachgehen und hoffentlich herausfinden, warum jener Knoten nicht so wollte, wie er sollte …

Über dieses Feature wollen wir in Zukunft periodisch Bestandsmeshes ›aufräumen‹, nachdem es mehrfach Konsolidierungen und Netzübernahmen gegeben hat. Der Test am Donnerstag hat gezeigt, daß unsere Firmware funktioniert — nice!

Nachdem die Meshes in Gütersloh, Bielefeld, Mesh 66 sowie Lippes D1/Blomberg nun ›durch‹ sind, habe ich mal ein erstes Fazit geschrieben:

Ein paar der Dinge, die seit 1.4.0~200 / 1.9.0~36 / 2.0.0~34 / 2.1.0~9 eingeflossen sind (aktuell sind: 1.4.0~206 / 1.9.0~46 / 2.0.0~47 /2.1.0~24):

  • newmesh-Anfrage immer per Mesh (initial via WAN, wenn vorhanden: FW-Issues möglich)
  • Koordinatenangaben werden ›gesäubert‹; initial wurde UCI-Wert in URL eingesetzt, jetzt wird aus UCI-Wert eine Fließkommazahl gemacht und diese in die URL eingesetzt
  • newmesh-wget nun mit -6, da sonst häufig »operation not permitted« kam (known issue lt. Web, Hintergrund unklar, -6 behebt es einfach)