@PetaByteBoy ja - so ziemlich alles korrekt, einziger Punkt - die statistics daten werden, soweit ich weis , bei (vermeintlich) offline nicht angezeigt, fliegen aus der nodes.json raus …
allerdings werden die nodeinfo daten viel weniger oft abgefragt.
würd mich riesig freuen wenn das Paket anderweitig viel weiter entwickelt wird, und zu einer schöneren Darstellung kommt.
Sollen die Daten doch rausfliegen wenn sie nicht aktuell sind…
nun, ich find die meisten daten da aber sehr interessant, zumindest rx/tx und 24h avg, sowie ttvn und uplinkIF.
aber darüber streiten is müssig - in vielem deiner Punkte haste recht, muss halt jemand machen, bzw. muss man sich einigen was man wie
Dafür gibt es Statistiken d.h. Prometheus und Grafana.
Das batgw gehört ja nicht wirklich zu wireless. Es könnte ja auch das LAN-/WAN-If sein.
so nen forum is denkbar ungeeignet um gemeinsam an code zu arbeiten, oder sich zu einigen …
kann das sein das du email antworten benutzt und den nacheditierten beitrag folglich nicht gelesen hast ?
Nein, ich habe einfach geantwortet bevor du deinen Post editiert hast. Dein Edit war laut Forum vor 3 Min, mein Post vor 6 Min. Bei Email-Antworten wäre ein entsprechendes Icon oben rechts zu sehen.
wie auch immer, mir ist nicht klar wie es weitergehen kann/soll ? für konkrete vorschläge offen …
wobei ich sagen muss, das ich wenig motivation hab da gerade „groß“ was zu ändern, da es für unsere Freiburger verhältnisse gerade passt - und ich finde auch ausreichend gut dokumentiert, bzw . für Pull requests auch ausreichend offen im Netz steht.
Das da viel möglich ist, und einiges Sinnvoller ist steht ausser frage.
(btw. grafana nutzt schlicht nicht jeder - daher würd ich das als dependency unschön finden, zumal die knoten die daten ohne probleme liefern können (avg, min und max wobei die relativ wenig gehalt haben))
die einfache airtime pro Frequenz reicht für alles andere gibt es prometheus / opennms + grafana
Dir vielleicht, mir nicht, da es ein Unterschied zwischen RX und TX Airtime (Nein, das ist nicht zwangsläufig im gleichen verhätlnis wie TX/RX-volume oder TX/RX-packets, da die Info zur jeweiligen MCS fehlt.) gibt.
Und damit die Ableitung, wo Optimierungspotential hinsichtlich des Antennenstandortes ist.
Ausserdem wäre es schön, wenn zukünftige Chipsätze, zwischen Airtime des eigenen APs und der von anderen (auf gleicher Frequenz) unterscheiden könnten.
Ich werde das Paket mal in die Eulenfunk-Packages portieren und dort meinen Wünschen anpassen.
schön wäre natürlich wenn die Verbesserungen am respondd im upstream gluon landen, das ist ja eigentlich schon best-practise, dass man seinen Code auch upstream einfließen lässt 
@rotanid : der wird so nicht angenommen werden , vermutlich auch weil man auf „bessere“ Wege derartige Dinge in den FW Buildprozess einbauen kann … in etwa wie hier von @tcatm beschrieben: Alfred und anounced - respondd basics - #4 von tcatm
das hab ich aber nicht wirklich verstanden, so war das direkte ändern des sources der einfachere Weg …
das upstream bringen macht nur sinn wenn man airtime upstream bringen will - nur die respondd änderungen bringt nichts.
das müsste @PetaByteBoy auch lösen - oder so hinnehmen.
ein packet (wie dsa airtime packet) das man installieren kann, sollte out of the box funktionieren (wenn bspw. später installiert) und nicht auf angepasstes respondd setzen müssen.
.
@adorfer : das tun sie schon, ausgelesen wird
Zeit_wo_das_interface_up_ist
Zeit_wo_das_interface_lauscht_rx (gleich andere, auch clients senden)
Zeit_wo_das_interface_sendet_tx
Das wollte ich damit bekräftigten.
Ein Wert allein reicht zumindest mir nicht.
Moderne Chipsätze liefern noch deutlich mehr Infos zu Noisefloor und Fremdmodulations-Störern wie HDMI-Bridges, Zigbee etc.
in gluon packages gibt es nun „nativ“ ein airtime paket von corny & jplitza:
um die Daten auch in hopglass sinnvoll anzeigen zu können, wäre aber noch eine Anpassung des hopglass-server nötig:
derzeit ist daher nur der respondd-collector von freifunk bremen voll für die airtime vorbereitet.
danke für die Info, wenn ich das übernehme müsst ich nur noch rausfinden wo ich das uplinkif und batman ttvn her bekomme (das hatte ich dazu gepackt) und wie ich mit den 24std avg umgehe - die gibt es dann erstmal nicht mehr.
Das was dir fehlt hättest du ja in den vielen Monaten die der Pull Request diskutiert wurde mit einbringen können
Die Averages hätte ich auch gerne direkt mit drin gehabt, die „Profis“ waren aber dagegen das direkt zu integrieren und möchten das extern implementiert haben - wie es in respondd-collector schon geschehen ist.
EDIT:
ist die ttvn nicht nur die TQ, nur in 0-255 Darstellung statt in Prozent? die hat man doch schon?
mhm, ja ich hab das beobachtet und mitbekommen und dacht das bringt dann auch nix. (respondd war mir lange ein rätsel)
Kern des Problems war doch wo man designmässig ein 24h average berechnet. und da war die klare präferenz das nicht auf der Node selber zu machen.
und die ttvn und uplinkif - haben nix direkt mit der airtime zu tun, das wäre dann auch da aufgeschlagen. ttvn ist ja was anderes wie die einzelne link quality, das ist der Grad wie gut die Node im backbone Netz ist. das erlaubt sehr gut zu sehen wie gut/schlecht man am ende wirklich dran ist mit meshenden knoten.
ah, ok. na kann man ja per separatem PR nachrüsten.
Die Aussage von @PetaByteBoy dazu war etwa diese:
"Airtimesupport kommt im Hoppglas für das, was offiziell in gluon aufgenommen wird, denn derzeit gibt es noch zu viele, unterschiedliche Formate in x communities "
