Ffmap-backend und meshviewer

Was sind denn „Clients per Mesh“?

Client in der jeweiligen Meshvolke (ohne VPN).

Ah. Wenn man das will, sollten wir wohl mal ein Konzept zur Ansicht einzelner Meshwolken einbauen.

Hie mal am Beispiel Max Bahr in Fulda

Klickt man einen Knoten werden die Clients zusammengezählt sodass man sich nicht immer durchklicken muss um die Gesamtanzahl zu bekommen.

Spannend. Ich werd’ da mal für Meshviewer v6 was bauen. Hab schon ein paar Ideen :slight_smile:

Auf einigen Karten hab ich gesehen, dass man über die Statistik Werte wie z.B. Hardware oder Firmware Version filtern kann und nur noch diese auf der Karte angezeigt werden. Ist auch ein durchaus praktisches Feature… :smile:

Joa, das habe ich im filter-Branch entwickelt. Ist allerdings noch nicht fertig und deshalb noch nicht im dev-Branch gelandet. Hauptsächlich sind die Datenstrukturen dahinter noch nicht effizient genug und die GUI braucht auch noch arbeit.

Ah ok, aber cool zu wissen das du da dran bist :smile: Danke für die Arbeit die du da rein steckst!

Mal eine Frage: eine Suche brachte mich nicht weiter (vielleicht habe ich auch nach den falschen Begriffen gesucht) - wie wird das Paket gluon-respondd im Zusammenhang mit dem Meshviewer verwendet?

Auf unseren Knoten laufen im Moment gluon-alfred und gluon-respondd parallel. Wie sage ich dem Backend, die Daten vom respondd zu verwenden und nicht mehr vom alfred?

Auf dem Gateway mit dem Backend läuft im Falle von Alfred der Alfred Server im Master Modus sowie alfred-json.

Damit lassen sich die für das Backend nötigen Daten erfassen und extrahieren.

Für einen Wechsel auf respondd benötigst du auf den Gws das ensprechende Gegenstück und kannst dich von Alfred und alfred-json trennen.

Wie das geht weiß ich auch noch nicht daher schließe ich mich der Frage an, denn diese Modernisierung wollen wir ebenfalls durchführen.

Nachtrag:
Ich habe eben mal in die gluongateway und in die Eulenfunk (toll gemacht!) Doku geschaut. Respond tauchen leider nicht auf, oder bin ich blind?

Der meshviewer läuft traditionell noch auf auf dem Alfred.
Wenn man respondd nutzen möchte, dann braucht es entweder den
Node-Informant. (Der ist nach meiner Erfahrung jedoch bisweilen sehr träge bei neuen/erstmalig meldenden Nodes)
alternativ ist der Hopglass-Server (Install-Anleitung dort mit drin)

Aus Kompatiblitätsgründen sollte man aber dann überlegen, ob man nicht eventuell gleich den Hopglass-Client dafür nutzt, was dann aber nicht hierhin passen würde, sondern nach.

1 Like

Der Hopglass Server läuft in diesem Fall nicht auf dem Gateway, sondern auf einem seperaten Mapserver.

1 Like

Irgendwie passiert hier nicht mehr besonders viel. Auch sind die letzten Änderungen am Meshviewer selber schon Ewigkeiten her.

Gibt es mittlerweile eigentlich eine Alternative zum Meshviewer, die auch respondd unterstützt? Bzw. hat jemand solch ein Setup am Laufen und das dokumentiert, damit man das nachbauen könnte?

@collimas

Fragen gerne per PN oder mention sodass ich eine Mail bekomme

Beispielinstallationen: https://map.ffdus.de https://bgl.map.ffgl.eu https://lln.map.ffgl.eu

Vielen Dank, das sieht gut aus. Daran werde ich mich versuchen. Eine Frage noch: kann HopGlass direkt Daten aus verschiedenen Domänen verarbeiten bzw. mergen? Wir setzen das FFMS-Setup ein und dort läuft ein Merge-Script, dass die Daten der einzelnen Domänen zu einer nodes.json zusammenfasst.

a) Dieses ist der Meshviewer-Thread
b) PBB hat doch oben den Thread verlinkt wo es Thema wäre. Du musst nur dem Link da oben folgen.
Da war die Frage nämlich jungst, samt Antwort.

der Vollständigkeit halber:
es gibt den sehr aktuell gepflegten meshviewer-Fork von Freifunk Regensburg in Kooperation mit Bremen.

3 Likes

Danke fürs Hinweisen. Da es schon einige Forks gibt usw. und hab ich außer auf Mehrsprachigkeit (seit heute neben de, en auch fr) nie groß darauf hingewiesen im Forum. Jeder wünscht andere Features und alles muss im Frontend geladen werden. Wer Interesse hat ist willkommen. Wir entwickeln schon länger dran (~150 Commits) und es gibt einige Verbesserungen/Unterschiede:

  • Kritischer Pfad verbessert
  • Update vieler Libarys oder ganz aussortiert
  • Rest in README und kleinere Sachen im commit log

Warum kein Hopglass von @PetaByteBoy ? Einfachste Antwort - wir nutzten kein hopglass-server. Wer Hopglass-server nutzt wird einige Features nur mit Hopglass profitieren/angezeigt bekommen.

Falls es fragen gibt, einfach melden.

@xaver was benutzt ihr als Backend? Vielleicht wäre es ja möglich, die Features von HopGlass-Server auch auf andere Backends zu portieren und umgekehrt den HopGlass auf eurem Meshviewer zu rebasen. HopGlass ist ja auch nur ein Meshviewer-Fork, der auf Anfrage vom Meshviewer-Autor umbenannt wurde.

Aktuell (noch) Alfred und Bremen ihr eigenes. An viele Features hab ich kein Interesse oder sind bewusst geflogen (iFrame stats, Webseiten anzeige). Also Rebase wird schwer das Codeformatierung anders ist und einiges geflogen ist. Build Struktur umgebaut (git +8k lines -8k lines + yarn.lock). Wenn dann Patch für Patch bzw. Änderung übernehmen.

(Forum ist für mich nicht der Platz und so etwas zu bereden/schreiben)