Unifi zu respondd Exporter - Unifi auf der Karte anzeigen

Nachdem wir immer mehr Unifi bei uns einsetzen, habe ich mich hingesetzt und begonnen einen Unifi zu Respondd Exporter in Python zu schreiben.

Dank einigen fleißigen Mitwirkenden, ist das Ding schön gewachsen und hat einige vielleicht für viele Interessante Features bekommen:

Zur Darstellung der Koordinaten, setzt man entweder eine Adresse oder direkt die Koordinaten in der SNMP Location der Unifi APs im Controller.

Vorteil, die Software kann sowohl Unicast als auch Multicast Mode und damit direkt auf dem Yanic Server mitlaufen da es nicht selber lauschen muss.

Beispiele auf unserer Karte:

Das Ganze läuft auch sauber direkt auf Gluon ;).

opkg update
opkg install python3
opkg install python3-pip
opkg install git-http

git clone http://github.com/awlx/unifi_respondd.git
cd unifi_respondd
pip3 -r requirements.txt
6 Likes

ich überlege, wie man das am sinnvollsten baut, wenn die Unifi-Geräte sich auf mehr als ein Dutzend verschiedene L2-Domains verteilen. Die sind aber alle in einem Controller.

Es gibt da mehrere Möglichkeiten, die mir aber alle schmerzhaft erscheinen.

Wieso? Domain setzt du im Zweifel per Python dem ist das per Unicast völlig egal ob da eigentlich nur Domain xy reinkommen sollte und zz drin steht.

Anmerkung so eben wurde ein Pullrequest gemerged der aus der meshviewer.json an Hand des Offloaders automatisch das Segment raussucht.

//Edit der Teil kommt morgen, aber Gateway wird nun automatisch ermittelt.

1 Like

Fehlende Plausibilitätsprüfungen müssen sich ja auch mal auszahlen.

2 Likes

Domain support ist jetzt drin, wenn ein zugehöriger Offloader angegeben ist.

1 Like

Nochmal Frage zur Architektur, ich habe da Verständnisproblem, wie ich das SCript möglichst wenig Traffic erzeugen lasse (und vielleicht ohne eine VM auskomme, die in N domains hängt)
Welche Rolle hat der besagte Offloader in diesem reporter?
Wo wollte man das Script sinnvollerweise drauf installieren?

Mein Szenario:

  • Mapserver, die mehrere Dutzend Domains bedient (und zu unterschiedlichen Maps aggregiert)
  • Unifi-Controller, der NICHT im Freifunk-L2 hängt, und
  • Unifi-Geräte, in vielen FF-L2-Netzen.

Es ist völlig egal, wo der Unifi Controller hängt unserer ist auch nicht im L2 Netz, so lange der unifi_respondd irgendwie an den hinkommt, kann er ihn abfragen.

Du kannst den Mapserver einfach angeben, nachdem keiner der Mapserver wirklich überprüft ob die Daten die reinkommen plausibel sind, kannst du für alle Domains sprechen egal ob die Konfiguriert sind. Die Karte macht nachher vermutlich das richtige draus.

Der Weg vom Script zum Controller ist mir klar.
Aber wie kommen die Informationen in den Mapserver, ohne dass die Daten in allen Domains erscheinen?
Zumindest beim Hopglas kann man zwar nach Domains filtern, ich müsste dann aber das json mit (allen) Unifies in allen Domains laden und dann erst im Client filtern?
Alternativ wäre, das Script n mal für entsprechend viele Domains zu installieren und den Host in die jeweilige Domain zu hängen, damit er dem Mapserver die respond-pakte auch in die richtige hopglas-server-Instanzu liefert.

Du lässt den Unifi_respondd entweder in einem L2 mit dem Mapserver antworten oder sendest periodisch per Unicast per Layer3.

Aber ja, bei mehreren Yanics oder Hoppglas Servern muss er mehrmals laufen, wenn die keine gemeinsame meshviewer.json erzeugen.

O.k, danke für die Klarstellung. Ich hoffte, mich da herummogeln zu können.

1 Like

Man könnte theoretisch, auch eine Liste von Targets angeben die er bespaßen soll, das könnte dann aber zu doppelten Daten führen denke ich.

Zu dem Thema ist mir noch eingefallen, wenn du jeweils einen User erstellst der nur auf die jeweiligen Sites im Unifi Controller kann passend zur L2 Domain für die der unifi_responnd läuft. Dann solltest du ohne doppelte Daten auskommen.

1 Like

Aber auf welchem Gerät?!

root@avm4040-gluon# pip3 install -r requirements.txt
[…]
ERROR: Could not install packages due to an OSError: [Errno 28] No space left on device: '/usr/lib/python3.6/site-packages/geopy/geocoders/mapbox.py'
root@avm4040-gluon:~/unifi_respondd# df -h .
Filesystem                Size      Used Available Use% Mounted on
overlayfs:/overlay       22.7M     22.4M    296.0K  99% /

Getestet auf nanopi r2s

Hallo,

vielen Dank für die tolle Arbeit.
Wir haben bisher für das einbinden der Unifi-Geräte eine von uns angepasste Version des unifi-meshviewer-generator genutzt. Dieser ist aber leider nicht sehr robust bei Änderungen und zerschießt uns regelmäßig die Karte.
Daher habe ich mir mal euren unifi_respondd angeschaut.
Nach einigem probieren habe ich es nun auch zum laufen gebracht. Die Möglichkeit, die Knoten über yanic zu integrieren gefällt mir sehr, da sie so auch in der Statistik ohne umwege erfasst werden.

Nun ergeben sich für mich noch 3 Fragen:
Wie können die Knoten verortet werden? Im Controller sind die Knoten mit Hilfe der Map eigentlich verortet. Das hatte so auch mit unserer alten Variante funktioniert.

Ist es möglich bestimmte Unifi-Sites nicht mit auszugeben? Wir verwalten mit unserem Controller auch einige Installationen, die wir nicht auf der Karte haben möchten.

Wäre es möglich, die fallback-Domain „ffmuc_unifi_respondd_fallback“ über die config einstellbar zu machen? Dies in der unifi_client.py (richtige Stelle?) zu editieren ist sicherlich nicht update-sicher bzw. ich müsste das Git-Repository forken…

Gruß aus dem Harz

1 Like

1: Du kannst die Knoten verorten in dem du den APs im Unifi Controller unter SNMP Location entweder Koordinaten oder ein Adresse einträgst.

2: Im Moment ist diese Möglichkeit nicht implementiert wir freuen uns aber über Pullrequests :).

3: Auch hier sind Pullrequests willkommen, wir haben es auf einen default gesetzt um auch ein bisschen für uns zu werben ;).

Danke für die schnelle Antwort.

Leider gehört Python bisher nicht zu meinem Repertoire, so dass ich da nicht so viel dazu beitragen kann…

Du kannst aber issues dazu öffnen und vielleicht schaut es sich jemand von uns an, wenn gerade Zeit ist :).

Im Moment ist unser Fokus aber auf Flüchtlingsarbeit, kann also etwas dauern.

OK…

Flüchtlingsarbeit bindet bei uns aktuell auch viel Zeit.