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

[Motivierte linke Hände]

Wenn sich die MAC-Adresse ändert, mag der Radius-Server das Zertifikat nicht mehr akzeptieren.

[hoppel118]

Alles klar! Ich sehe, du sorgst für Sicherheit bei dir zu Hause... [emoji2]

[Wuehler]

Du kannst entweder im Unifi dem client  einen Alias geben oder im Modul das Attribut devAlias nutzen. Damit ist der im client gesetzte Name irrelevant. 
In der vor ein paar posts angehängten Version und im post selbst habe ich die Priorisierung wann welcher clientname genommen wird beschrieben.

Edit: da auf disconnected vermutlich einige ihre PRESENCE aufgebaut haben hätte ein blocked dort Umstellungen zur Folge. Reading kann ich aber einbauen.
Gegen Anpassung der MAC gibt  es im Unifi auch ein Mittel.  Die werden zB mur als Gast behandelt.

[Motivierte linke Hände]

Hi Wuehler - Auf Deinen Hinweis hin habe ich mir das nochmal angeschaut:

Im Anhang eine Testversion mit einem neuen Attribut "deprecatedClientName". Auszug aus der commandref dazu:

Code Auswählen Erweitern


attr deprecatedClientNames <0,1>
Client-names in reading-names, reading-values and drop-down-lists can be set in two ways. Both ways generate the client-name in follwing order: 1. Attribute devAlias; 2. client-alias in Unifi;3. hostname;4. internal unifi-id.
1: Deprecated. Valid characters for unifi-client-alias or hostname are [a-z][A-Z][0-9][-][.]
0: All invalid characters are replaced by using makeReadingName() in fhem.pl.
default: 1 (if module is defined and attribute is not set)


Ich habe hier in Unifi ein Device, das

• taucht in Unifi in der Liste "Clients" als "iPhone 6" auf,
• zeigt in den Details den Hostname "iPhonevonXXX",
• hat in Unifi das Alias "iPhone 6" konfiguriert,
• taucht in 74_Unifi als "iPhonevonXXX" auf.

Müsste das Client-Alias nicht eigentlich vorgehen, habe ich etwas falsch verstanden oder ist diese Priorisierung der Namen (unabhängig von Sonderzeiten, Attribut ist bei mir nicht gesetzt) noch nicht eingecheckt und nur in der dort angehängten Testversion enthalten?

[Wuehler]

Das im post angehängte Update ist noch nicht eingecheckt.
Aufgrund des Leerzeichens in ,,iPhone 6" wird der Unifi-Alias ignoriert. Es sei denn du nimmst die Testversion und setzt das neue Attribut auf 0, dann wird daraus ,,iPhone_6"

[Motivierte linke Hände]

Danke für die Klarstellung. Ich habe die Testversion hier mal eingespielt. Es scheint zu funktionieren - Geräte mit Leerzeichen wurden nach dem Setzen des Attributs umbenannt. Dabei wurden die alten Readings nicht gelöscht/konvertiert, aber das kann man dann ja auch manuell machen.

Ob es nun für das fragliche iPhone aus der letzten Nachricht auch funktioniert, kann ich erst testen, wenn es wieder im Haus ist. Das Modul scheint nur die Daten für verbundene Clients auszulesen, nicht für die, die "disconnected" sind. Aber warum soll es dafür nicht klappen 

[Wuehler]

Das Modul kann ein disconnected ja nur daran erkennen, dass der Client vom Unifi nicht mehr mitgesendet wird (nach 5 Minuten), daher können Clients nicht durch das Modul gelöscht werden. Daher hatte rapster schon das

Code Auswählen Erweitern

set <Unifi> clear [readings|all]
eingebaut.
Das braucht man in solchen Fällen einmalig. Bei clients hilft meistens erst das clear all, da die internen Daten zu den clients bei clear readings nicht gelöscht werden und dann im nächsten update der client auf Basis der internen Daten wieder "neu" in den Readings angelegt wird.

[Motivierte linke Hände]

Ok, ich wusste nicht, dass inaktive Clients nicht mitgesendet werden. Meine Skripte erhalten über die API auch Informationen zu Clients, die gerade nicht connected sind. Aber dann passt ja alles!

Die Readings werde ich hier erst anpassen, wenn die Änderung eingecheckt ist. Denn beim nächsten automatischen Update werde ich ja erstmal wieder die alten Readings haben.

[Wuehler]

Da es zu keinen Problemen geführt hat bei dir habe ich jetzt eingecheckt. War eine größere Änderung an bestehendem Code. Da ich perl weiterhin noch lerne war ich da noch etwas vorsichtiger, als wenn ich neue Funktionalitäten hinzufüge 

[fhemplayer]

Hallo zusammen!
Geht es nur mir so (FHEM heute abend frisch aktualisiert vor dem Einbinden von 74_Unifi) oder ist es vielleicht noch nie angefragt worden:

In der DEF-Zeile im DeviceOverview (also beim Herumstöbern im GUI jederzeit sichtbar) für den Unify Controller erscheint das Passwort des Benutzers im Klartext!
Das wertet dieses tolle Modul als Ganzes natürlich auch nicht ab! Dennoch finde ich es persönlich recht unschön...

Bin heute Abend durch alle 39 Seiten des Threads durchgegangen, habe aber bislang keinen Feature Request bzgl. eines verschlüsselten Passworts gefunden.
Ich meine mich zu erinnern, daß FHEM Passwörter für externe Devices in verschlüsselter Form in einer separaten Datei ablegen und nutzen kann.
Wenn also bislang noch keiner angefragt hat, schlage ich die Implementierung eines verschlüsselt abgespeicherten Passwortes vor.   

Danke und Grüße!

fhemplayer

[Wuehler]

Moin,
Das Verschlüsseln des PW ist auf meiner Liste (schon fast ganz oben )
Als nächstes kommt der Voucher-Cache in die offizielle Version.

Das Reading für client_blocked kann ich leider nicht einfach so hinzufügen.

Grüße,
Dirk

[Eisix]

Hallo,

gerade ein update all gemacht.
Folgendes im Logfile:

Code Auswählen Erweitern


2018.02.01 10:38:41.228 1: PERL WARNING: Argument "false" isn't numeric in numeric eq (==) at ./FHEM/74_Unifi.pm line 1122.


Modul läuft aber denke ich ohne Probleme.

Gruß
Eisix

[Wuehler]

Hast du das Attribut ,,deprecatedClientName" auf false gesetzt? Durch manuelles editieren in der fhem.cfg?

[Eisix]

Hallo,

momentan habe ich keine Attribute gesetzt. In der Konfig ist nur der define.
Manuell habe ich nichts editiert.

Gruß
Eisix

[Wuehler]

Hi Eisix,

das ist leider ein Folgefehler. Bitte enable und disable (vermutlich) dein Gast-WLAN einmal. Ich habe den Fehler behoben, dass auf der Oberfläche der Haken am WLAN nicht wieder gesetzt wurde (Unterschied zwischen "false" und false (ohne Anführungszeichen)).
Kam leider erst jetzt wieder an einen Rechner, der letzte Post war eine Mutmaßung aufgrund meiner Anpassungen.

VG,
Dirk