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

[Michi240281]

@Rapster: Kann ich bedenkenlos ein update machen oder ändern sich dann die readings? Nutze sie bereits für PRESENCE!

[manfzimm]

Erst habe ich das hier durchgeführt:

Code Auswählen Erweitern

cpanm -i IO::Socket::SSL --force
Ergebnis: Version 2.019

Mein FHEM stürtzt jetzt an dieser Stelle ab (Kein Web-Interface mehr):

Code Auswählen Erweitern

2015.09.01 21:00:06 5: UnifiHome (Unifi_Login_Send) - executed.
SSL_verify_mode must be a number and not a string at /usr/local/share/perl/5.14.2/IO/Socket/SSL.pm line 2130.

Daraufhin habe ich wieder deinstalliert und damit meine alte Installation zurückerhalten:

Code Auswählen Erweitern

cpanm --uninstall IO::Socket::SSL

Auch das hier brachte keinen Erfolg:

Code Auswählen Erweitern

attr global sslVersion SSLv23

Oh je....

[rapster]

@Michi:
Die Client-Readings werden wie weiter oben beschrieben automatisch generiert: devAlias, controllerAlias, hostname, ID
Auf was prüfst du i.M.? Wenn du devAlias konfiguriert hattest bleibt alles gleich, wenn du ID verwendet hast, wirst du das ändern müssen in hostname z.B.

@Manfred:
Es könnte auch sein, dass das ganze nichtmal an deiner fhem-Maschine liegt, da in der Standardversion SSLv2 bei allen deaktiviert war (habe ich erst gestern aktiviert).

Probier mal bitte noch Zeile 98 in der 74_Unifi.pm durch folgendes zu ersetzen:

Code Auswählen Erweitern

sslargs         => { SSL_version => 'TLSv1', SSL_verify_mode => 'SSL_VERIFY_NONE' },
Das könnte klappen...
So wie ich das verstehe verwendet deine SSL Version i.M. NUR SSLv2 & SSLv3, die neueren SSL Versionen SSLv2, SSLv3 & TLSv1 bei der Einstellung SSLv23

Gruß
  Claudiu

[manfzimm]

Hallo Claudiu,

einfach spitze !!! Das ist es !!!

Vielen Dank

Lässt sich das vielleicht allgemeingültig einbauen ?

Liebe Grüße

Manfred

[rapster]

Super dass es geklappt hat, freut mich! 

Ich werde mal die Tage probierne ob der v3.x Controller auch damit zurecht kommt und auch sonst keine Nebenwirkungen auftreten, falls das alles gutgeht würde ich TLSv1 hardcodieren.
Die Frage ist nur was benötigt dann in Zukunft mal ein v4.7 oder v5 controller?

Bis dahin:
- Ich habe die forcierung auf eine TLS-Version aus dem Modul entfernt (in der Version die Morgen ab ~8 Uhr im Update ist)
- Du kannst dann ab Morgen erstmal mit "attr global sslVersion TLSv1" das FHEM-default überschreiben, damit deine Änderung in der 74_Unifi.pm nicht bei jedem Update rückgängig gemacht wird.

Evtl. baue ich aber auch ein eigenes Attribut hierfür ins Unifi-Modul, ich überlege morgen mal

Gruß
  Claudiu

[Michi240281]

Hi,

habe folgendes seltsames Verhalten festgestellt:

Code Auswählen Erweitern

Marina_iPhone_5S disconnected 2015-09-02 21:29:34
Marina_iPhone_5S_accesspoint EG 2015-09-02 21:29:34
Marina_iPhone_5S_hostname 192.168.188.179 2015-09-02 21:29:34
Marina_iPhone_5S_last_seen 2015-09-02 21:29:24 2015-09-02 21:29:34
Marina_iPhone_5S_snr 41 2015-09-02 21:29:34
Marina_iPhone_5S_uptime 14718 2015-09-02 21:29:34


Das iPhone ist definitiv online, sieht man ja auch am "...last_seen", aber warum steht es dann auf "disconnected"?

Ich nutze Controller v3.2.10.

[rapster]

Hallo Michi,

danke für die Info,
ja das Verhalten ist tatsächlich sehr seltsam, und du hast recht, das Gerät muss connected sein, sonst würden auch die restlichen readings nicht aktualisiert werden (Der 'disconnected' state hat immer ein <interval> unterschied zu den anderen Readings).

Allerdings schließt sich das auch gegenseitig aus, das Unifi-Modul kann den Status nicht auf "disconnected" setzen während es die anderen Readings aktualisiert.
Kann es sein dass dein eigenes DOIF das Reading auf disconnected setzt?

Kannst du dein verwendetes DOIF hier mal posten?

Falls du das Modul nicht durch das Fhem-Update aktualisiert hast, hast du anschließend einen Fhem-Neustart gemacht? (Die disconnected Erkennung wurde in der letzten Modul Version ziemlich verändert und würde mit einem reinen "reload modul" nicht funktionieren.)

Eine letzte Möglichkeit was mir noch einfällt wie sowas auftreten könnte, wäre das Attribut "devAlias", hast du dies konfiguriert?
Falls ja, kannst du bitte den Eintrag für devAlias posten?

Gruß
  Claudiu

[Michi240281]

Hi Rapster,

devAlias habe ich nicht mehr konfiguriert! Hier meine komplette Konfig:

Code Auswählen Erweitern

define Unifi_Controller Unifi 192.168.188.200 8443 User PW 10 default 3
attr Unifi_Controller event-on-change-reading Marina_iPhone_5S_last_seen,Michael_iPhone_5S_last_seen
attr Unifi_Controller room System
attr Unifi_Controller verbose 3

define Marina_Unifi dummy
attr Marina_Unifi group Anwesenheitssteuerung
attr Marina_Unifi room 0_MAIN,Haus

define Marina_Unifi_DI DOIF (time()-time_str2num([Unifi_Controller:Marina_iPhone_5S_last_seen]) > 30) (set Marina_Unifi absent) DOELSE (set Marina_Unifi present)
attr Marina_Unifi_DI room Haus

define Michael_Unifi dummy
attr Michael_Unifi group Anwesenheitssteuerung
attr Michael_Unifi room 0_MAIN,Haus

define Michael_Unifi_DI DOIF (time()-time_str2num([Unifi_Controller:Michael_iPhone_5S_last_seen]) > 30) (set Michael_Unifi absent) DOELSE (set Michael_Unifi present)
attr Michael_Unifi_DI room Haus

define Marina_Homestatus_DI DOIF ([Marina_Unifi:state] eq "present") (set Abwesenheit_Marina nein) DOELSE (set Abwesenheit_Marina ja)
attr Marina_Homestatus_DI group Anwesenheitssteuerung
attr Marina_Homestatus_DI room Haus
attr Marina_Homestatus_DI wait 0:60

define Michael_Homestatus_DI DOIF ([Michael_Unifi:state] eq "present") (set Abwesenheit_Michael nein) DOELSE (set Abwesenheit_Michael ja)
attr Michael_Homestatus_DI group Anwesenheitssteuerung
attr Michael_Homestatus_DI room Haus
attr Michael_Homestatus_DI wait 0:60

Ich verändere also keine Readings......

[rapster]

Ja da hast du recht, das schaut sauber aus.

Kannst du mal bitte ein "get Unifi_Controller clientData" machen und die Ausgabe posten?

Es könnte sein dass dieses Device aus irgend einem Grund doppelt geliefert wird, dann müsste der name "Marina_iPhone_5S" in der Ausgabe 2x vorhanden sein.

Gruß
  Claudiu

EDIT:
was ich gerade sehe,
wenn du "attr Unifi_Controller event-on-change-reading Marina_iPhone_5S_last_seen,Michael_iPhone_5S_last_seen" setzt, tut doch dein DOIF nicht das was es soll? Es soll doch gerade einen konstanten Zustand dieses Readings überwachen, es wird allerdings nur ein einziges mal aufgerufen.

[rapster]

P.S. noch ein Tipp.

mit dem neuen Reading 'client_snr' könnte sich zusätzlich zum Reading 'client_last_seen' eine Abwesenheitserkennung theoretisch noch etwas schneller/zuverlässiger realisieren lassen.

Bevor sich ein Client durch zu weit entfernen vom AP disconnected, bekommt er im Normalfall erst einen sehr geringen _snr Wert.
Wenn dieser Wert nach mehreren Aktualisierung konstant bleibt, könnte man davon ausgehen dass der Client sich nun zu Weit vom AP entfernt hat und in kürze vom Controller als disconnected markiert wird.
In dem Fall könnte man bei Bedarf die 'disconnected' Meldung sozusagen selber etwas schneller als der Controller umsetzen.

Bin in der Richtung allerdings selber noch am testen (_snr Werte loggen um zuverlässige Aussagen treffen zu können), kann hier aber mal falls die Theorie aufgeht ein Beispiel posten.

Gruß
  Claudiu

[Michi240281]

Hi Rapster,

die Ausgabe poste ich heute Abend. Ich habe jetzt mal ein Filelog für die ganze Funktionalität erstellt und dabei 2 komische Sachen festgestellt:

- Michael_iPhone_5S hat sich die ganze Nacht über ständig neu connected. Glaube zwar nicht, dass das am Unifi-Modul liegt, wollte es aber dennoch mal überlegen. Vllt wechselt das iPhone ständig zwischen 2 AP hin und her?!?

- Das DOIF, was ich oben gepostet hatte für "Michael_iPhone_5S" reagiert manchmal nicht, obwohl die Zeit seit "...last_seen" schon mehrere Minuten beträgt. Verstehe ich nicht! Irgendwie ist das noch nicht so zuverlässig....

Der Tipp mit der SNR ist evtl. gold wert! Was sagen denn deine geloggten Werte bislang so, bei welchem SNR-Wert das Device eher disconnected als connected ist?

Bzgl. der "event-on-change-reading"-Attribute: Das müsste doch gehen.......das Reading ändert sich ja alle 10 Sekunden?!?

[rapster]

die Ausgabe poste ich heute Abend.

Ok super, bitte zwischen auftreten des Problems und posten der Ausgabe keinen Fhem-Neustart o.ä. machen.

- Michael_iPhone_5S hat sich die ganze Nacht über ständig neu connected. Glaube zwar nicht, dass das am Unifi-Modul liegt, wollte es aber dennoch mal überlegen. Vllt wechselt das iPhone ständig zwischen 2 AP hin und her?!?

Roaming beeinflusst nicht den 'connected'-status, evtl. hat das ja was mit dem Problem dem wir auf der Spur sind zutun

- Das DOIF, was ich oben gepostet hatte für "Michael_iPhone_5S" reagiert manchmal nicht, obwohl die Zeit seit "...last_seen" schon mehrere Minuten beträgt. Verstehe ich nicht! Irgendwie ist das noch nicht so zuverlässig....
...
Bzgl. der "event-on-change-reading"-Attribute: Das müsste doch gehen.......das Reading ändert sich ja alle 10 Sekunden?!?

Das liegt an dem event-on-change-reading welches du bei _last_seen gesetzt hast, du überwachst ja mit dem DOIF den Konstanten Zustand über eine Zeit gesehen. Das funktioniert natürlich nur wenn das Reading auch auf on-update-reading steht.

Der Tipp mit der SNR ist evtl. gold wert! Was sagen denn deine geloggten Werte bislang so, bei welchem SNR-Wert das Device eher disconnected als connected ist?

Da muss ich noch etwas genauer beobachten, allerdings irgendwas zw. 10 .. 15

Gruß
  Claudiu

[justme1968]

ich habe gerade dein modul das erste mal problemlos in betrieb genommen. sehr schön. ich bin begeistert

natürlich habe ich auch gleich ein paar vorschläge. die meisten deshalb weil ich in meiner installation recht viele geräte habe (zur zeit. 40-50) und weil dynamisch manchmal kurzzeitig welche dazu kommen die dann aber nicht weiter interessieren.

vielleicht gibt es für manche der vorschläge ja noch andere nutznießer:
- black und white liste um festzulegen welche geräte überhaupt readings erzeugen sollen
- konfiguration welche ssids überwacht bzw ignoriert werden sollen
- anzeige mit welcher ssid ein client verbunden ist.
- black und white list ssid basiert
- (optional?) erzeugen eines fhem devices pro accesspoint, ssid und device auf das dann die betreffenden readings verteil werden. (ählich wie im harmony modul)
- reading für upload und download. aktuell und summe sowie activity.

vielleicht wäre es eine option die readings die pro device erzeugt werden aus der clientData liste konfigurierbar zu machen.

und noch etwas ganz anderes:
ich glaube es wäre besser einen . statt des _ in den reading namen zu verwenden. dann ist die alphabetische sortierung der readings besser. ich habe z.b. einige devices die namen wie xyz und xyz-abc haben. der _ führt dazu das erst das reading  xyz kommt, dann alle xyz-abc_... readings und dann alle xyz_... readings. d.h. die readings für xyz stehen nicht zusammen.

ich hoffe du bist jetzt nicht erschlagen.

gruss
  andre

[Michi240281]

Das liegt an dem event-on-change-reading welches du bei _last_seen gesetzt hast, du überwachst ja mit dem DOIF den Konstanten Zustand über eine Zeit gesehen. Das funktioniert natürlich nur wenn das Reading auch auf on-update-reading steht.

Aber wieso? Das Reading ÄNDERT sich doch auch alle 10 Sekunden, weil die Uhrzeit in dem last_seen reading sich ja immer ändert! Oder meinst du, wenn das Gerät disconnected? Hmmmm, stimmt, dann kommt ja kein change mehr und daher löst das DOIF nicht aus?!? Wie sehen denn die Attribute bei dir diesbezüglich aus?

- black und white liste um festzulegen welche geräte überhaupt readings erzeugen sollen

Das fänd ich auch prima, dann könnte ich damit die Readings festlegen, die ich benötige!

Roaming beeinflusst nicht den 'connected'-status, evtl. hat das ja was mit dem Problem dem wir auf der Spur sind zutun

Was meinst du damit? Dass das Device auf disconnected steht obwohl es online ist? Das war ja "Marina_iPhone_5S". Das war die Nacht über ganz brav, was "last_seen" angeht! Ich glaube ich spiele mal was mit den SNR Readings rum! Denke, man kann dann ja schon einstellen, "wenn kleiner als 20 für 3 Minuten" dann ist es offline!

[rapster]

Hi Andre,

ne keineswegs erschlagen, paar Punkte hatte ich mir sogar selber schon überlegt, wusste allerdings nicht ob es jemand braucht und dachte mir schon, "einfach mal warten bis es jemand braucht"

Freut mich auf jedenfall dass auch bei dir die Inbetriebnahme soweit problemlos funktionierte, und die meisten Vorschläge sind auch relativ leicht umsetzbar.

- black und white liste um festzulegen welche geräte überhaupt readings erzeugen sollen
- black und white list ssid basiert

Ist auf jedenfall eine gute Idee, baue ich ein.

- konfiguration welche ssids überwacht bzw ignoriert werden sollen

Auf Client-Seite kann ich das auf jedenfall schonmal einbauen, denke auch auf white- & blacklist Basis.
Bei den AP selber würde das denke ich gegen das geplante Feature widersprechen, bei AP über Fhem ssids ein oder auszuschalten. (Für das feature brauch ich noch paar Daten von jemanden der 5Ghz APs in Betrieb hat)

- anzeige mit welcher ssid ein client verbunden ist.

Das hatte ich auch schon überlegt, und ist ruckzuck eingebaut

- (optional?) erzeugen eines fhem devices pro accesspoint, ssid und device auf das dann die betreffenden readings verteil werden. (ählich wie im harmony modul)

Da ist die Frage ob das sinnvoll ist, da einerseits die Clients durch roaming immer wieder den AP wechseln und ssid's von einzelnen AP hinzugefügt und entfernt werden können (kommt noch) ?

- reading für upload und download. aktuell und summe sowie activity.

Das hatte ich schon mal länger Versucht über "den richtigen weg" hinzubekommen, die Controller api bietet eigentlich eine Schnittstelle für genau diese Daten, allerdings habe ich es bisher noch nicht geschafft die richtige JSON-Abfrage zusammen zu basteln damit ich hier eine Antwort vom Controller bekommen.
Leider zerhackt mein Java-Decompiler den Code an dieser Stelle auch etwas, was das Ganze nicht einfacher machte.
Habe dieses Projekt dann erstmal zurückgeschoben um Sachen die schon über die Api funktionieren in das Modul einzubauen.

vielleicht wäre es eine option die readings die pro device erzeugt werden aus der clientData liste konfigurierbar zu machen.

Ja auch das wäre einfach umsetzbar und könnte nützlich sein, werde ein Attribut machen wo Elemente aus clientData angegeben werden können um direkte Readings daraus zu generieren.

und noch etwas ganz anderes:
ich glaube es wäre besser einen . statt des _ in den reading namen zu verwenden. dann ist die alphabetische sortierung der readings besser. ich habe z.b. einige devices die namen wie xyz und xyz-abc haben. der _ führt dazu das erst das reading  xyz kommt, dann alle xyz-abc_... readings und dann alle xyz_... readings. d.h. die readings für xyz stehen nicht zusammen.

Daran hab ich nicht gedacht, und du hast recht, in diesem Fall ist die Sortierung ja echt katastrophal.
Bloß ein "." wird das Problem nicht lößen, da "-" in der ascii table immer noch weiter vorne liegt.

Als mögliche Trenner kommt nicht so viel in betracht, evtl !, #, $, %,  ', +,  ", gefällt mir allerdings alles nicht so richtig... Vorschlag?

Gruß
  Claudiu