Sind diese Angaben nicht Durchschnittswerte eines gewissen Zeitraums, z.B. 10 Min.? Wenn 2 Clients in den ersten 5 Min. online sind und die nächsten 5 Min. sind es insgesamt 3, wären es in 10 Min. doch 2,5…
Sieht eher aus als wenn RRDTOOL auf AVERAGE statt LAST steht dann gibt es aber auch keine
realistischen Daten auf diesem Graph.
LG
muss im backend geändert werden.
http://www.vandenbogaerdt.nl/rrdtool/min-avg-max.php
sind nicht nur halbe, sondern Teilstriche/Zeitraum
scheint zu entstehen, wenn Client(s) mit Unterbrechungnen für Zeitraum X online
(Bus vor Fenster z.B.)
Allerdings würde MAXIMUM meiner Meinung nach mehr Sinn ergeben.
Müsste in der lib/NodeRRD.py angepasset werden (wenn die Backend-Version bei mir lokal noch aktuell ist).
Aber am besten dann per Pull-Request upstream in’s Projekt.
1 „Gefällt mir“
Mit LAST macht auch nur sinn wenn man oft genug abfragt, so siehts zb. mit --slope-mode und LAST bei uns aus.
Supergenial, die Filterfunktion. So findet man leicht, welche Knoten noch auf alter Firmware laufen, wenn man in der Statistik z.B. auf 0.6 klickt: https://map.luebeck.freifunk.net
Cool wär noch, wenn man die liste der Treffer unten hätte, so dass man die gefundenen Knoten links durchklicken kann. Im Moment muss man immer auf der Karte den Knoten anklicken um zu sehen welcher das ist, wenn da mehrere auf einer Stelle sind, wird das schwierig.
Der Filter wirkt global. Du kannst dann auf den Tab Knoten gehen und sieht nur die Liste der gefilterten Knoten.
1 „Gefällt mir“
Zum Filter hätte ich noch einen Vorschlag, der allerdings keine hohe Priorität hat:
Wenn der/die gewählte(n) Filter auf nur einen Knoten zutreffen, wäre es nett, wenn dieser direkt angezeigt würde oder man ihn zumindest verlinkt. Das wär nützlich, damit man den letzten Knoten mit Firmware XY findet und es sieht besser aus.
Edit: Verlinkt ist der Knoten natürlich schon über die Knoten-Liste, auf die der Filter auch wirkt. Trotzdem finde ich die Statistik wenig aussagekräftig, wenn nur ein Knoten enthalten ist.
Die Statistikseite soll nicht das primäre Interface zum Setzen der Filter bleiben, sodass man später dann auch die Knotenliste direkt filtern kann.
1 „Gefällt mir“
Gibt es irgendwo eine Anleitung, wie man solche graphischen Statistik Grafiken einbaut wie in München hier?
http://map.freifunk-muenchen.de/meshviewer/#!n:c46e1ffe9f14
Update:
vielleicht einfach den münchener fork benutzen? da sind so commits drin:
https://github.com/freifunkMUC/meshviewer/commit/cbe21ee3dff73d2ea8ba14a34d4fcc901f70ce50
was muss man ev. noch installieren, damit die sttistik so läuft?
Hier hat @Xylou Grafana mal umgesetzt:
Ich würd jetzt einfach versuchen Graphana so zu installieren und dann den münchener commit einbauen
Ich glaube das wir mittelfristig, bzw mit erscheinen von „distributed“ DHCP und BMX, uns eh Gedanken machen müssen, wie die Daten aufbereitet werden. Dann hat das splitten der Domänen ein Ende und imho wird der große Merge einsetzen.
Da ich der Meinung bin, dass jede Community eine eigene Map haben sollte/möchte/will, sollten wir uns vielleicht auch gedanken machen, wie das umzusetzen ist.
Deswegen habe ich schon erste Tests mit Elasticsearch und der geographischen Zuordnung von Nodes zu Städten gemacht. Ein Problem könnten vielleicht die RRDs werden, da ich glaube, dass bei einer großen Meta Community das nicht mehr ordentlich skaliert.
Aber vielleicht entwickelt sich das auch alles anders und ich habe mir die Gedanken umsonst gemacht. 
Die von der Freifunk-API wollen das auch, da wird bei den Domainsplits schon drauf geschaut, kannst du auch bei dem Krefeldern aktuell lesen
[quote=„netminion, post:213, topic:4123“]
Da ich der Meinung bin, dass jede Community eine eigene Map haben sollte/möchte/will, sollten wir uns vielleicht auch gedanken machen, wie das umzusetzen ist.[/quote]
Ich sehe das in einem etwas größeren Kontext, vielleicht gibt es ja in Zukunft nicht mehr so viele "Sub-"Communitys, bzw nicht jede Community hat eine eigene Firmware.
So gehört zum Beispiel Moers zu Rheinufer, die Nodes liefern aber den Sitecode von Rheinufer aus.
Mit dem Filter kannst du soviel filtern, wie du möchtest, basiert auf dem Namen der Nodes.
Aktuell erstelle ich damit die Daten für Krefeld, Viersen, Jüchen und Mönchengladbach.
Damit kann der Betreiber der Infrastruktur, egal ob Sub-Domäne, Domäne oder gar der Verein, aus den Backend-Daten beliebig fein filtern, sei es für Communities, Städte oder gar Straßenzüge oder Ortsteile. Man muss sich nur auf ein Namensschema einigen, auf das gefiltert werden kann.
Das spätere einfügen anderer Filterkriterien gestützt auf weitere JSON-keys ist auch kein Problem.
In der nächsten Version möchte ich zusätzlich zu den Map-Daten (Meshviewer und ffmap) noch das Api-File für die Community aus einem Template generieren.
1 „Gefällt mir“
schön wäre ja, basierend auf den Koordinaten, vielleicht mit Angabe eines Zentrums und Radius.
Da nicht jede Stadt rund ist, bräuchte man mehrere kreise und Radien, so dass man die Stadt ungefähr abdecken kann.
1 „Gefällt mir“
Könnte aber auch kompliziert werden. Nicht jede Stadt ist rund
Das kannst du mit Elasticsearch machen, ohne Probleme! Siehe [hier][1]
Damit hat auch das manuelle Nodes zählen von @Sirhcnailuj bei den Butzentreffen ein Ende.
[1]: Fertige Lösung: Nodes einer Stadt ermitteln / Tool für Domain-Split
1 „Gefällt mir“
Halte ich pers. für zu umständlich, außerdem wie behandelt man dann Knoten ohne Geodaten?
Ich denke das Filtern auf den Namen und das Vereinbaren von Benennungsrichtlinien ist aktuell der einfachste Weg.
Schön wäre vielleicht eine weitere Konfigurationsoption „Stadt“ oder „Community“ zu schaffen, die dann auch in den JSON-Daten auftaucht. Im Idealfall als Dropdown-Box gefüttert aus der site.conf, damit die möglichen Werte klar sind.
Das schließt sich ja nicht aus. Man könnte nach Namen filtern und optional auch nach Entfernung. Natürlich kann man mit den Koordinaten nur Knoten filtern, die welche haben, daher wäre die Hauptfunktion so eines Filters, Knoten, die zu weit entfernt vom Zentrum des Stadtradius sind, von der Karte auszuschließen.