Neues Modul - 74_Unifi - Für den Ubiquiti Networks (UBNT) - Unifi Controller

DeeSPe · 07 März 2019, 13:32:16

Zitat von: f-zappa am 07 März 2019, 12:34:40
Das selbst zu modifizieren ist natürlich unelegant, entweder nimmt man das Modul von Updates aus oder man editiert nach jedem Update.

Was spricht denn dagegen dem freundlichen Modulautor einen entsprechenden Patch zu liefern wenn es doch bei Dir schon eingebaut ist?

Gruß
Dan

f-zappa · 07 März 2019, 14:10:15

Zitat von: DeeSPe am 07 März 2019, 13:32:16
Was spricht denn dagegen dem freundlichen Modulautor einen entsprechenden Patch zu liefern wenn es doch bei Dir schon eingebaut ist?

Einfach mal weiterlesen. Ich hatte herausgehört, dass der Modulautor das in dieser Form nicht gut findet. Wenn doch, ist er ganz sicher nicht auf meinen banalen Patch angewiesen 🤪

marvin78 · 07 März 2019, 14:12:55

Das siehst du falsch. Wir nehmen sicher fast alle gerne Patches entgegen, egal, wie banal sie sind.

f-zappa · 07 März 2019, 15:56:27

Na denn. Sei nicht enttäuscht.

Code Auswählen

1166a1167
>             readingsBulkUpdate($hash,$clientName."_mac",$clientRef->{mac});

Wuehler · 07 März 2019, 17:39:46

Moin,

Danke für die Diskussion und den Patch. Ich habe mir schon länger immer wieder kurz Gedanken gemacht, wie man das Thema der Client-Readings in den Griff bekommen kann. Also gleichzeitig nicht zu viele Readings, aber trotzdem alle!?
Folgendes Problem bringen mehr Readings: wenn man ein offenes WLAN (mit Vouchercode gesichert) hat, werden auch die Handys vieler Paketzusteller im Modul angezeigt. Die wählen sich oft in jedes WLAN ein. Das reduziert die Übersicht im Modul enorm.
Folgendes Problem bringt eine Einschränkung: man kann nicht auf alles in fhem reagieren.

Das hier angesprochene Problem könnte man noch über ,,get clientData" lösen. Da man glaube ich keine notifies oä auf die MAC aufsetzen würde.

Aber egal. Meine Idee wäre sehr ähnlich der unten angedachten, ein neues Attribut ,,customClientReadings" einzuführen. Mit der Syntax:

Code Auswählen

attr customClientReadings <clientname1>:<reading1>,<reading2>,<...> <clientname2>:<reading1>,<reading...> <clientname...>:<...>

Beispiel:
attr customClientReadings iPhone_Karl:mac,essid,uptime iPhone_Doris:mac,essid *:state

Im Beispiel würde für alle clients der state angezeigt und bei den genannten iPhones zusätzlich mac und essid, vei Karl noch die uptime.
Bei clientnames kann man mit regExp arbeiten, die Readings müssen ausformuliert sein.
Default wäre dann wie heute.

Folgendes habe ich noch nicht recherchiert: Wenn ich mich richtig erinnere gibt es auch andere FHEM-Module, bei denen man soetwas customizen kann. Gibt es da schon einen Stndard, wie man den Attributwert aufbaut?

Wir hatten auch mal die Diskussion, für jeden Client per autocreate ein eigenes UnifiCliebt-Device anzulegen. Das war aber als nicht so praktikabel gesehen worden.

Soviel erstmal von mir. Freue mich auf weitere Diskussion und Unterstützung,
Dirk

Wuehler · 07 März 2019, 17:52:30

PS: das Attribut ,,customNames" gibt es schon. Heißt ,,devAlias".

f-zappa · 07 März 2019, 18:11:47

Zitat von: Wuehler am 07 März 2019, 17:52:30
PS: das Attribut ,,customNames" gibt es schon. Heißt ,,devAlias".

Hi, das hatte ich anders gemeint .. bei mir würde "customNames" nicht einen einzelnen Namen ändern, sondern das komplette Schema, nach dem Namen aufgebaut werden.
Verrückterweise hab ich es gerade schon so implementiert, wie ich es mir vorstelle

Ich schick dir gleich einen Patch via PN, aber fall bitte nicht vom Stuhl wegen meiner miesen Perlkenntnisse ...

f-zappa · 09 März 2019, 18:54:25

Ich hoffe, Dirk ist nicht tatsächlich vom Stuhl gefallen?

War mein Code furchtbar?

Naja, zu dem hier wollte ich noch was sagen ..

Zitat von: Wuehler am 07 März 2019, 17:39:46
Das hier angesprochene Problem könnte man noch über ,,get clientData" lösen. Da man glaube ich keine notifies oä auf die MAC aufsetzen würde.

.. und zwar, dass das tatsächlich das ist, was ich für die Anwesenheitserkennung nehmen will. Momentan läuft das bei mir über das Fritzbox-Modul, und das liefert auch schon derartige Readings:

Code Auswählen

mac_38_F7_3D_36_A4_6D echo-kueche (WLAN, 0 / 0 Mbit/s, 0)
Um schneller den "Anwesend"-Status zu bekommen, benutze ich als zusätzlich das Modul dash_dhcp, auch da sind die Readings standardmäßig erst mal MAC-Adressen.
Klar, man kann auch da Aliases reinpflegen. Aber ich will nicht jedes neue/geänderte Gerät an zig Stellen anpassen müssen ...

Wuehler · 09 März 2019, 18:59:34

Moin,

bin endlich dazu gekommen, mir den patch genauer anzusehen. Das mit dem customName=ip finde ich als fehleranfällig. Mit dhcp können die clients öfter neue IPs bekommen und dann würden im Modul viele neue Readings angelegt und die Readings mit der alten IP bleiben bestehen. Das heißt, die Readingnamen verändern sich mit der dhcp-Vergabe. Ist für eine Hausautomatisierung meiner Meinung nach nicht nutzbar, oder nur ohne dhcp.
customname=mac finde ich nicht fehleranfällig. Ist für clients ohne hostname default.

Sehe also den Nutzen des Attributes eher niedrig.

Wenn ich deinen Netzwerkaufbau richtig verstehe hast du noch einen DNS-Server am Laufen. Und Unifi nutzt den nicht korrekt? Sollte man das dann nicht eher im Unifi korrigieren? Funktioniert die manuelle Konfiguration unter Network->LAN->DHCP Name Server nicht?

Wie steht die Community denn zum Thema "customClientReadings"?

VG,
Dirk

PS: Hast gerade zeitgleich geschrieben, denke aber zum Großteil passt meine Antwort immer noch

Wuehler · 09 März 2019, 22:02:22

PPS: Bin übrigens nicht vom Stuhl gefallen. War vorhin das erste Mal an einem richtigen PC. auf dem Handy konnte ich den patch irgendwie schlecht lesen. Und da auch ich kein Perl-Experte bin ...

Also: das mit der mac als customClientName kann ich gerne übernehmen. Die IP sehe ich als nicht so sinnvoll, lasse mich aber auch gerne überzeugen. In dem Rahmen kann man auch gleich das Attribut deprecatedClientNames ausbauen. Hatten allle genug Zeit, das auf den Standard 0 zu setzen (1 ist default, um abwärtskompatibelzu sein)

Das mit den customClientReadings ist denke ich für viele hilfreich zur Automatisierung. Hier würden mich Meinungen interessieren.

Maui · 10 März 2019, 08:11:26

Moin. Also ich denke customClientReadings ist tatsächlich sinnvoll. Vor allem wegen der MAC-Adresse.
Die Benennung bzw. Generierung eines neuen Reading-Satzes würde ich wie jetzt über den alias lassen.
Man kann ja seine Geräte im Controller umbenennen.

f-zappa · 10 März 2019, 15:36:35

Moin,

Zitat von: Wuehler am 09 März 2019, 22:02:22
Also: das mit der mac als customClientName kann ich gerne übernehmen. Die IP sehe ich als nicht so sinnvoll, lasse mich aber auch gerne überzeugen. In dem Rahmen kann man auch gleich das Attribut deprecatedClientNames ausbauen. Hatten allle genug Zeit, das auf den Standard 0 zu setzen (1 ist default, um abwärtskompatibelzu sein)

Das wäre super! Ich habe gestern den zweiten UAP-AC-LR aufgestellt und migriere dementsprechend gerade meine Anwesenheitserkennung, dabei würden mir die "MacNamen" sehr helfen.
Das mit der IP finde ich jetzt nicht unbedingt wichtig. Ich wollte nur zeigen, dass man sehr einfach alle anderen vom Controller gelieferten Felder für den Namen verwenden kann.

Zitat von: Wuehler am 09 März 2019, 18:59:34
Wenn ich deinen Netzwerkaufbau richtig verstehe hast du noch einen DNS-Server am Laufen. Und Unifi nutzt den nicht korrekt? Sollte man das dann nicht eher im Unifi korrigieren? Funktioniert die manuelle Konfiguration unter Network->LAN->DHCP Name Server nicht?

Der DNS ist nur ein DNSmasq auf der Fritzbox. Ich möchte halt an einer zentralen Stelle eine fixe Zuordnung MAC->IP festlegen und gleich auch die DNS-Namen pflegen. Alternative wäre da vermutlich ein USG, aber ich hadere noch damit, ob ich den brauche/will.
Zu der Konfiguration, die du ansprichst: Ohne USG kann man nur "DHCP-Modus: ohne" einstellen, und dann gibt es die Einstellung "DHCP Name Server" gar nicht. Ist ja letztlich auch egal, meine Clients bekommen vom DHCP ja korrekte Angaben zu Gateway und DNS geliefert. Mir geht's eher darum, wie der Controller _selbst_ seine Clients benennt, und das ist gar nicht konfigurierbar. In der VM, auf der der Controller läuft, ist die Namensauflösung ja auch sowieso schon konfiguriert.
Aber der Controller benutzt das nicht. Nur für sehr rudimentären Clients (ESPeasy; ältere Versionen) bekomme ich MAC-Adressen als Namen. Anderes sieht z.B. so aus:

Code Auswählen

60:01:94:07:xx:xx	          192.168.1.xx <- ESPeasy (alte Version)
amazon-887a4xxxx	                  192.168.1.xx <- Echo
iPhonevxxxx	                          192.168.1.xx <- iOS-Gerät
Roomba-xxxx                               192.168.1.xx <- Staubsauger
yeelink-light-bslamp1_mibt7xxxx  192.168.1.xx <- "smarte" Glühlampe

Ich denke, damit ist vielleicht auch meine Motivation klar, warum ich diese saublöden Namen nicht verwenden möchte ..

Waldmensch · 11 März 2019, 10:27:24

Hi,

Ich habe mir eine Unfi Instanz angelegt. Im Prinzip interessieren mich nur connected/disconnected. Irgendwie funktioniert aber der Wechsel von connected auf disconnected nicht. Scheinbar kommen bei einem diconnectetem Gerät gar keine Daten mehr vom Controller für dieses Gerät. Mache ich da irgendwas falsch? Ich habe einen Cloudkey, 5AP's und ca 50 clients. Alle sind auf aktuellem Software Stand. Das Plugin habe ich auch auf den neuesten Stand via FHEM update gebracht. Das einzige Attribut, was ich gesetzt habe, ist

Code Auswählen

attr myunifi event-on-change-reading .*_last_seen,.*(connected|disconnected)

DEF ist

Code Auswählen

defmod myunifi Unifi 192.168.178.85 8443 crypt:xxx crypt:xxx

Wuehler · 11 März 2019, 13:14:30

Hallo Waldmensch,

Vorab: Vermutlich habe ich dein Problem / deine Erwartungen noch nicht richtig verstanden. Daher erstmal nur eine Erklärung:
Wenn der UnifiController (UC) einen Client meldwt wird dieser als connected im state angezeigt. Auch wenn der Client das Netz verlässt sendet der UC weitere 5 Minuten den Client mit. Es gibt aber ,,keine" aktualisierten Informationen (last_seen ist da glaube ich die Ausbahme). Nach 5 Minuten Abwesenheit wird ein Client vom UC nicht mehr mitgesendet. Das FHEM-Modul erkennt das und setzt den state des clients auf disconnected.

Viele Grüße,
Dirk

Gisbert · 14 März 2019, 18:37:05

Hallo,

ich hab es endlich geschafft, den UniFi-Controller auf einen Server umzuziehen, so dass ich die Voraussetzungen habe dieses Modul zu nutzen.
Ich habe einen Beitrag gefunden, in dem es heißt:

ZitatWer nur möchte, dass FHEM lesenden Zugriff auf die Daten erhält, muss vorher eben entsprechend einen Benutzer mit eingeschränkten Rechten im UniFi-Controller einrichten.

Dies würde ich gerne umsetzen, weiß aber nicht wie. Recherche bei Google oder hier im Forum hat kein für mich verwertbares Ergebnis gebracht.

Im commandref steht, dass das Modul nur mit 3er und 4er Versionen arbeitet. Was heißt das für die 5er Version, die ich nutze?

Viele Grüße Gisbert