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.
2 „Gefällt mir“
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.
1 „Gefällt mir“
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.
1 „Gefällt mir“
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 "
2 „Gefällt mir“
BTW: SO machen es andere:
Erster %-Wert ist „wait“
zweiter %-Wert ist „RX“
und dritter %-Wert it „TX“
wo kommt das her, kannste sourcen oder bsp linken?
Das ist das WebUI des UBNT Unfi-Controllers.
Also „proprietäre“ Ware.
Warum machst du’s nicht selbst? Du möchtest doch den Sourcecode haben 
ich hab die geräte nicht, wüsste daher auch nicht wonach ich fragen soll (und das scheint der einzige Weg zu sein, selbst an die opensource pflichtteile zu kommen) - mich interessiert dann eh nur wie die das frontend füttern und woher die sich die Daten ziehen,
aber das alles luxus - und zeit daran zu werkeln hab ich kaum - @adorfer hat das reingebracht , vielleicht mag er sich das ja ansehen
Wenn man sich die sourcen von iw anschaut, sieht man, dass die die nl80211-API nutzen. Die Daten kommen also direkt aus dem Kernel. Im nl80211.h Headerfile finden sich dann auch viele interessante Erklärungen zu den einzelnen Parametern.
Das von @Jason in der ersten Antwort verwendete Paket (liegt mittlerweile hier), geht dann eben auch direkt den Weg über den syscall, anstatt über iw und bash script. Frage: Was spricht gegen die Verwendung davon, es scheint doch genau das zu sein, was du suchst?
@Jason Gibt es einen Grund, warum ihr NL80211_SURVEY_INFO_CHANNEL_TIME_RX und NL80211_SURVEY_INFO_CHANNEL_TIME_TX bzw. NL80211_SURVEY_INFO_TIME_RX und NL80211_SURVEY_INFO_TIME_TX nicht auslest?
1 „Gefällt mir“