Magst Du da[1] mal drübergucken, ob das in etwa Deinem paste entspricht?
[1] ffgt_packages-v2015.1/gluon-airtime at master · ffgtso/ffgt_packages-v2015.1 · GitHub
4 „Gefällt mir“
schaue ich nachher mal drüber 
ich denke mal das sollte funktionieren zum ausprobieren hatte ich aber bisher noch keine Zeit
Es tut, allerdings haben Skript auf dem Knoten und Deine »meshviewer«-Patches unterschiedliche Ideen, wo die Daten liegen sollen 
Du schreibst sie (oder ich habe das falsch interpretiert) nach nodeinfo.wireless, willst aber die Daten aus nodeinfo.network.wireless holen. Daher gab’s bei mir keine Ausgabe, und da json-Output vom Knoten auf der Kommandozeile für mich nur Datenmüll ist, habe ich im gelöschten Posting gesagt »der schickt nix, any hints?« — um dann im nach-rechts-scrollen dann eben doch „wireless“-Daten zu finden
Ich schreibe und suche die Daten nun in nodeinfo.wireless, gehört IMHO auch nicht unter network, und schon tut’s auch im Meshflix … http://map.4830.org/ffgt/meshflix/#!v:m;n:24a43cb111d9
Next step ist Verifikation, daß 5-Ghz-Daten auch bei 5 GHz ausgewiesen werden und umgekehrt
Hätte jetzt gerne eine dritte Meinung, ob diese Berechnung wie vorgenommen auch sinnvoll ist, d. h. »ein belastbarer Indikator«; kenne mich da nicht aus und auch Deinen Background nicht
Ich finde die Informationen, die da ausgeworfen werden. sehr interessant, mich wundert allerdings, daß es für >1 Kanal ist, sprich auch für nicht-aktive Kanäle Daten vorliegen. Was ich vermeiden möchte ist, a) durch eine Messung den Funk an sich zu verschlechtern (SSID-Scan über alle Kanäle führt AFAIK zwangsweise zu kurzem Datenverlust auf dem Hauptkanal?) oder b) eine Metrik anzuzeigen, die Probleme zeigt, die es gar nicht gibt bzw. Probleme versteckt.
Kurz: es wundert mich gerade, daß die Funkauslastung so einfach ermittelbar sein soll, und es noch niemand vorher zur Anzeige brachte
2 „Gefällt mir“
Moin.
Sehr interessantes Thema und was draus geworden ist. 
Aber passt da noch die Überschrift und die Kategorie?
Gruß
Hmm, was an …
[quote=„wusel, post:14, topic:12333“]
Next step ist Verifikation, daß 5-Ghz-Daten auch bei 5 GHz ausgewiesen werden und umgekehrt 
[/quote]
… hast Du nicht verstanden?
FTR, der in Post #10 verlinkte Code ermittelt anhand der Frequenz nun, welches Frequenzband welches Interface bedient. Tut für v2015.1.x.
Nun, er wird einerseits auf das Thema »Airtime« an sich hingewiesen (daß diese »precious« ist, mag nicht jedem sooo klar sein), andererseits auf einen Weg, diese zu visualisieren. Ich würde das in »Technik« suchen, aber ist das jetzt nicht eine Diskussion um des Kaisers Bart? Anonyme Anfrage ergibt jedenfalls dies:
Comments?
1 „Gefällt mir“
Nö. 
Ich für meinen Teil im Moment nicht.
GuMo
1 „Gefällt mir“
Planst du auch wieder einen Pull Request für Hopglass und hopglass-server?
Freu mich schon drauf mal wieder eine neue dev-Instanz auf unserem Server aufzusetzen
Mit dem Feature wird es sicherlich einfacher Entscheidungsträger dazu zu bewegen ein paar Löcher zu bohren und Kabel zu legen.
Beim hopglass-server ist wohl ein rewrite geplant … / die portierung zu hopglass ist kein Problem da es optional aufgebaut ist
1 „Gefällt mir“
Hallo zusammen,
ich verfolge den Thread und wir haben das Feature in Frankfurt ebenfalls getestet. Die Implementierung steht ebenfalls schon als PR für hopglass. Ich warte hier noch auf eine Rückmeldung ob das Format final feststeht.
github.com → hopglass → pull/38 (darf hier iwi keine links hinzufügen .o0)
Grüße,
Benjamin
1 „Gefällt mir“
Das hat jetzt aber doch eher weniger mit dem Airtime-Problem in Unterkünften oder an sich zu tun.
Klingt mir eher nach Gluon-Entwicklung und dem Hopglas-Server.
(Will sagen: Überhaupt kein Community-Thema)
1 „Gefällt mir“
@moderatoren bitte alle HopGlass- und Meshflix-Posts (auch diesen!) dorthin verschieben:
@Moorviper der HopGlass soll ein rebase bekommen, HopGlass-Server bleibt erstmal so
1 „Gefällt mir“
ah ich dachte es wäre anders rum
Hey,
wir setzen im Bereich Nordwest mittlerweile auch Hopglss ein und haben hier grade etwas komisches.
Im Hopglass Frontend taucht der Router mit letzte Nachricht vor 9 Tagen auf, in der json ist er offline. Tatsächlich ist der Router pingbar per batctl. Wie kann das vorkommen?
Wir möchten, das alle Altdaten aus den Jsons entfernt werden - wo ist das einzustellen, denn unsere jsons wachsen immer mehr. Kann man die Datenbank einmal händisch löschen?
Könnte es sein, dass der noch eine Firmware hat, die nicht auf respondd lauscht, sondern nur Alfred unterstützt?
Nein, das schließe ich aus!
es kann sein das der relevante teil nicht in die nodes.json kam, aber schon in nodelist.json und graph.json vorhanden ist (im backend) …
Es geht hier konkret um das Beispiel „FF-OS-Jaeger-2“
http://gw-os01.sn.ffnw.de:4000/nodes.json
Der Router wird im Hopglass angezeigt als online - nur wo bekommt er die Daten her?
Kann man denn die Daten von ffmap-backend für hopglass konvertieren?
Es wäre sehr ärgerlich, wenn das „firstseen“ verloren gehen würde…
jetzt habe ich eine Weile gesucht im Forum und auf github, aber fand keinerlei Diskussion dazu - war das bisher wirklich jedem total egal oder ist es so einfach dass ich es übersehe?
Geht bisher nicht. Der HopGlass speichert einfach mehr Daten, dementsprechend ist das nicht ohne weiteres möglich.