search

freifunk-ffm / map-server-config

debian etch based ffffmmap hopglass server config/ install files
1 stars 10 forks source link

Zusätzliche Informationen auf der Hopglas-Map #4

Closed oszilloskop closed 8 years ago

oszilloskop commented 8 years ago

Könnten wir sowas wie unter https://forum.freifunk.net/t/airtime-in-fluechtlingsunterkuenften/12333 dargestellt ist, auch auf unsere experimentellen Map anzeigen lassen?

Also Wifi-Kanal, Airtime und Gesamtanzahl der Clients im Mesh?

eberhab commented 8 years ago

Prinzipiell ja, das ist aber kein config setting sondern muss dann als PR/ feature request in das hopglass projekt: https://github.com/plumpudding/hopglass

eberhab commented 8 years ago

Nachtrag: Für die Airtime müssen drei Projekte angepasst werden: viewer (hopglass), backend (hopglass-server) sowie auch respondd im gluon, sprich das muss mit in die Firmware. Wie im verlinkten Forumsthread beschrieben hat danielkrah das dementsprechend auch nur für einige router aktivieren können.

Beim wifi-Kanal verhält es sich ähnlich. Hier bin ich mir nicht sicher ob das von respondd/ firmware schon mitgesendet wird. Ich glaube nicht. Auch das müsste dann zuerst ins gluon eingebaut werden.

Gesamtanzahl der Clients im Mesh ist ein reines viewer feature. In der neuesten Version des meshviewers ist das drin, jemand müsste das in den hopglass viewer einbauen, dann können wir es hier installieren.

Das Thema kann hier weiter diskutiert werden. Ich habe den Thread vorerst geschlossen weil ich denke dass das Thema besser an den betroffenen Projekten diskutiert wird.

oszilloskop commented 8 years ago

Ich habe das Thema mal durchdiskutiert, ein Package zusammengeklaut (https://github.com/freifunk-ffm/packages/tree/master/ffffm/ffffm-airtime-v2015.1.x), eine Dev-Firmware v1.10.3.2-dev-154 auf der Basis von Gluon 2015.1.2 gebastelt (https://dl.ffm.freifunk.net/firmware/dev) und das ganze auf einige Knoten in Hattersheim geflasht (https://hopglass.ffm.freifunk.net/#!v:g;n:60e3275ffd5c).

Kurz gesagt: Es gibt jetzt einige Knoten im Frankfurter Netz, die den Wert der Air Time und der verwendeten WLAN-Kanäle per "nodeinfo" JSON verteilen.
"statistics" konnte ich irgendwie nicht testen.

Format:

"wireless": {
    "chan2": "1",
    "airtime2": 0.48922392682701,
    "chan5": "44",
    "airtime5": 0.22392682634567
  }

chanX -> String airtimeX -> Float zwischen 0 und 1 (Deutung: 0-100%)

eberhab commented 8 years ago

unter o.g. links ist das jetzt auf der hopglass map zu sehen. Ich würde mir zudem noch den batman nexthop im statistics json wünschen und die airtime werte sollten ggf auch von nodeinfo nach statistics umziehen. Des Weiteren kann man optional noch die txpower mit rein nehmen.

Vorschlag:

"nodeinfo": {
  "wireless": {
    "chan2": "1",
    "chan5": "44",
    "txpower2": "11",
    "txpower5": "11"
  }
}
"statistics": { 
  "wireless": {
    "airtime2": 0.48,
    "airtime5": 0.22
  },
  "nexthop": "02:ff:0f:10:7d:01"
}
eberhab commented 8 years ago

andere communities senden die wifi infos u.a. unter nodeinfo.network.wireless.* da sollte man sich noch auf etwas einigen.

Ggf kann man die Kanalbreite noch dazu nehmen. Die ist zwar wohl community-weit in der site.conf definiert, das weiss aber die map (glaube ich) nicht. Auf dem Router ist der Wert unter: wireless.radio?.htmode auszulesen.

eberhab commented 8 years ago

noch ein Gedanke: es gibt Geräte wie z.B. einige der tp-link RE's welche zwei 2.4 GHz interfaces haben. Evtl sollte man sich bei der Formatdiskussion noch überlegen ob die channel/ airtime/ etc variablen nicht besser Listen sein sollten ... Ich denke nach wie vor, dass diese Diskussion wesentlich besser in einem Gluon feature request aufgehoben wäre als in einem repo welches sich mit Frankfurter config files befasst. Wir können das so umsetzen, aber irgendwann wird jemand das Thema (hoffentlich) in einem größeren Zusammenhang diskutieren und dann werden sich diese Formate ggf ändern.

oszilloskop commented 8 years ago

Was ist mit "ob die channel/ airtime/ etc variablen nicht besser Listen sein sollten" gemeint?

eberhab commented 8 years ago

So wie ich es verstehe gehen wir bisher davon aus, dass ein Gerät immer nur je ein interface in einem Frequenzband hat. Es gibt aber geräte, ich kann mich irren, aber wie ich glaube z.B. den TP-Link TL-WA830RE, welcher zwei 2.4 GHz devices hat. Welcher channel und welche airtime würde in diesem Falle unter "nodeinfo": { "wireless": { "chan2": "1" }} reported? Der vom ersten oder vom zweiten device? Oder sollte "chan2", etc nicht besser eine Liste sein, so dass man beliebige Anzahlen von Devices abdecken kann.

oszilloskop commented 8 years ago

Die Problematik ist mir klar. Mir geht es darum, was mit "Liste" gemeint ist? Nehmen wir halt anstelle von xyz2 (für 2GHz) und xyz5 (für 5GHz) folgende Benamung: xyz_w0 (für WLAN Interface 0) und xyz_w1 (für WLAN Interface 1).

@t-8ch und ich (ein wenig) sind da an einem generischen Package dran. Wenn da mal Daten fliessen, können wir das hier gerne verschieben.

eberhab commented 8 years ago

ah, ok, also du redest glaube ich gerade von den keys und ich rede von den values. In deinem Beispiel wäre das sowas wie:

"nodeinfo": {
  "wireless": {
    "chan2_w0": "1",
    "chan2_w1": "6"
  }
}

Das ist mEn unnötiger Aufwand auf der Gegenseite sauber herauszufinden wo sich die Daten befinden. Man müsste über alle keys in wireless loopen und dann schauen wieviele es bzgl chan2 gibt und das iwi per regex matchen.

Ich denke es wäre einfacher wenn der value eine Liste wäre:

"nodeinfo": {
  "wireless": {
    "chan2": ["1", "6"]
  }
}

Dann kann man über den value von "chan2" (also die liste) loopen.

Wenn ihr jetzt erstmal wollt das schnell Daten fließen, dann würde ich allerdings vorschlagen, dass wir vorerst bei dem formatvorschlag aus meinem letzten post bleiben. Wenn der Thread dann umzieht und es in einer größeren Runde diskutiert wird werden evtl noch mehr Änderungsideen kommen.

eberhab commented 8 years ago

Eine Benennung der keys nur anhand der Interface Nummern alleine halte ich nicht für so sinnvoll. Dann wird es an der Gegenstelle sehr schwer zu identifizieren welche info zu welchem Frequenzband gehört. Beim wlan Kanal kann man anhand der Kanalnummer das Frequenzband nachschlagen, aber bei z.B. 

"statistics": { 
  "wireless": {
    "airtime_w0": 0.48,
    "airtime_w1": 0.22
  }}

wird es schwer zu identifizieren welche info zu welchem Band gehört (Ich gehe hier einfach mal davon aus, dass man die Angabe des Frequenzbandes ebenfalls gerne auf der Karte darstellen möchte)

t-8ch commented 8 years ago

Das aktuelle Schema ist jetzt:

{
  "statistics": {
    "ffffm": {
      "wifi_info": {
        "channel_24": 1
      },
      "nexthop": "02:ff:1f:73:7d:02",
      "airtime":0.17127903022823
    }
  }
}
t-8ch commented 8 years ago

@eberhab Da wir ja wissen welches device auf welchem Kanal läuft können wir auch die Airtime über diesen Kanal dem Band zuordnen

oszilloskop commented 8 years ago

So, jetzt wird es kompliziert. Nexthop ist jetzt im Gluon Master-Branch mit aufgenommen worden (siehe https://github.com/freifunk-gluon/gluon/commit/0a936e4de533d8fc2332a0292cad3a1cdff3e345 )

Den Master-Branch verwenden wir aber in Frankfurt aber noch nicht. Wir verwenden noch den Branch v2016.1.x

Das wird irgend wann ein heilloses Durcheinander geben.

eberhab commented 8 years ago

können wir das modul verwenden bis zu diesem zeitpunkt und ab dann lassen wir es weg? Wenn wir die keys ab heute schon so benennen wie sie in zukunft im gluon heissen werden wird der übergang zudem transparent für die systeme welche diese daten nutzen.

oszilloskop commented 8 years ago

Wir wissen aber nur durch Zufall wie jetzt Nexthop im Gluon-Master heisst. Weiss das auch der Hopglass-Entwickler? Ich sag's ja bloss ...

@t-8ch muss dass dann mal irgendwann im Frankfurter Package ändern. Jetzt bau ich erstmal eine DEV nach unserem Muster und verabschiede mich dann für drei Tage.

eberhab commented 8 years ago

Da sehe ich keinen Zufall. Thomas hat den PR an gluon gestellt und ich stelle den PR an hopglass und Thomas und ich koordinieren uns diesbezüglich.

Frankfurter Package und Hopglass harmonieren ja schon, wie man hier betrachten kann: https://hopglass.ffm.freifunk.net/#!v:m;n:30b5c2c6ab78

EDIT: Wenn wir jetzt sukzessive die verbleibenden quantities ins gluon master pushen und dabei wie du vorschlägst die dort aufkommenen Änderungsvorschläge zurückreflektieren in das FFM package, dann kann das package bei einem gluon upgrade wegfallen und das upgrade wird für e.g. die map transparent.

oszilloskop commented 8 years ago

Zufällig habe ich mal in die Gluon Master Commits geschaut.

Das Frankfurter Package und Frankfurter Hopglass harmonieren z.z. noch. Gluon-Master verwendet einen anderen Namen für Nexthop.

Lass uns mal einen Update von Hopglass abwarten und/oder ein Update auf Gluon 2016.2. Dann sehen wir wo es kracht.

oszilloskop commented 8 years ago

Es sieht so aus, als ob ein allgemeingültiges Airtime-JSON-Format frühestens ab Gluon 2016.2.x released wird (https://github.com/freifunk-gluon/gluon/pull/826)

Nexthop ist bereits im Gluon-Master drin ( https://github.com/freifunk-gluon/gluon/pull/795 und darin verlinkte) und wird damit auch erst mit Gluon 2016.2.1 released werden.

Wann Gluon 2016.2.1 kommen wird, steht in den Sternen. Bis dahin, und solange die Map noch mitspielt, nutzen wir halt unser Package von @t-8ch https://github.com/freifunk-ffm/packages/tree/master/ffffm/ffffm-additional-wifi-json-info

oszilloskop commented 8 years ago

Als Issue-Ersteller mach den hier mal vorläufig zu.