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

[bogi999]

--> Modul aus Beitrag #639 von Maui: Hier sehe ich im FHEM Log: (Unifi_Login_Receive) - Login Failed! Invalid username or password! - state:'error' - msg:'api.err.Invalid'    | im Unifi Logging seh ich nichts.

So, ich glaube.... ich hab da was. Nee, es läuft nicht, aber ich denk ich weiss wo es klemmt.

Beim Aufruf zum Login wird bei der UDM https://ip/proxy/network/api/auth aufgerufen.

Geb ich genau den Pfad ohne Login in den Browser ein, bekomm ich das zuück. --> {"meta":{"rc":"error","msg":"api.err.LoginRequired"},"data":[]}
Mit dem aktuellen Controller sollte das aber https://ip/network/api/auth lauten, ohne Proxy.
Authentifiziert wird sich an der UDM selber, dann bekommt man die Erlaubnis den Pfad "/proxy/network....." aufzurufen.

Vielleicht etwas kompliziert erklärt.

[acw81]

Servus zusammen,

seit Kurzem (vermutlich einem Firmwareupdate) meldet mein Unifi AP nun sofort einen disconnect vom AP. Bisher kam die Notifizeriung erst, wenn das gerät ca. 5 Minuten disconnected war. Ist das bei euch auch so? Wenn ja, lässt sich das direkt im AP konfigurieren oder muss ich nun in FHEM selbst was basteln? Wenn sich das wirklich nur in FHEM lösen lässt wäre wahrscheinlich ein Modulerweiterung am sinnvollsten, oder?

Viele Grüße
Chris

[MadMax-FHEM]

Servus zusammen,

seit Kurzem (vermutlich einem Firmwareupdate) meldet mein Unifi AP nun sofort einen disconnect vom AP. Bisher kam die Notifizeriung erst, wenn das gerät ca. 5 Minuten disconnected war. Ist das bei euch auch so? Wenn ja, lässt sich das direkt im AP konfigurieren oder muss ich nun in FHEM selbst was basteln? Wenn sich das wirklich nur in FHEM lösen lässt wäre wahrscheinlich ein Modulerweiterung am sinnvollsten, oder?

Viele Grüße
Chris

Ich hab's nun wirklich ein paar mal gelesen und ja es gibt "Interpretationen" die vielleicht Sinn ergeben...
...aber ich habe keine Ahnung von was (genau) du sprichst!?

Der Unifi AP meldet disconnect vom AP sofort!?

EDIT: welche FWs laufen denn auf welcher HW jeweils!?

EDIT: und wenn du Clients meinst, die sofort disconnected gemeldet werden -> warum rumbasteln!? Das ist doch genau was Sinn macht!? Je schneller (wenn zuverlässig) desto besser bzgl. An-/Abwesenheitserkennung War/ist für mich ein Grund eben Unifi nicht zu nehmen... UND: es macht verm. auch einen Unterschied ob sich ein Client (wie geschrieben falls du davon "sprichst") "sauber" abmeldet oder eben "einfach so verschwindet" (also beispielswesie du mit dem Handy weggehst)...

Gruß, Joachim

[acw81]

Also irgendwo muss sich etwas geändert haben. Ich habe folgendes Szenario:

Unsere Handys werden zur Anwesenheitserkennung verwendet und dementsprechend die Haustür geöffnet bzw. geschlossen. Zusätzlich erhalte ich eine Jabber Nachricht aufs Handy wenn die Haustür auf- bzw. abgeschlossen wurde. Bisher habe ich etwa 5-10 Minuten nachdem ich das Haus verlassen habe die Meldung erhalten das die Haustür abgeschlossen wurde. Aktuell passiert das aber teilweise, wenn ich ein Stockwerk höher oder in den letzten Winkel im Keller gehe und die WLAN Verbindung kurzzeitig unterbrochen wird.

Ich fand 5-10 Minuten bei einer Aktion wie das Abschließen der Tür bisher auch etwas lang, aber nur weil ich mal kurzzeitig mich im Haus bewege sollte nicht gleich die Tür auf- und abgeschlossen werden. Ich hoffe das war nun halbwegs verständlich formuliert 

Das mit den 5 Minuten steht übrigens auch hier https://wiki.fhem.de/wiki/PRESENCE#Beispiel_Anwesenheitserkennung_mittels_UniFi_Controller

Code Auswählen Erweitern


Beispiel Anwesenheitserkennung mittels UniFi Controller
Die Anwesenheitserkennung bei Geräten in Verbindung mit UniFi-Produkten funktioniert selbst dann, wenn sich die Geräte im PowerSave-Modus befinden.

Beachte: Die Geräte werden erst ungefähr nach 5 Minuten, nachdem das Gerät das WLAN verlassen hat als disconnected angezeigt.

define <NAME> PRESENCE function {ReadingsVal("<UniFi>","<NamedDevice>","") eq "connected" ? 1:0}


[MadMax-FHEM]

Dachte mir schon "sowas"

Ich habe bis vor kurzem die "hping3-Methode" verwendet.
Hat jahrelang gut funktioniert...
Allerdings schlafe ich nachts im Sommer öfter mit geöffnetem Fenster und wenn dann das Handy mal "verschwindet", dann bekomme ich eine Nachricht, dass noch ein Fenster auf ist...
Selten aber oft genug, trotz des hping3...

Bin dann vor einiger Zeit auf Unifi umgestiegen (ob nun das oder irgendein Handy Update zu der beschriebenen "Unzuverlässigkeit" geführt hat: keine Ahnung und ist auch egal)...
...habe dann parallel mal die Anwesenheit mittels Unifi loggen lassen und musste feststellen, dass diese deutlich langsamer (mir sind 5min zu lange ) ist als die "hping3-Methode" und aber auch ab und an mal "Falschalarme" produziert hätte.
Daher kann ich die Aussage "geht auch, wenn Handy in sleep geht" nicht bestätigen...

Bin nun letztendlich auf einen Gigaset BT-Dongle gegangen.
Ja es hängt zusätzlich was am Schlüsselbund aber den Schlüssel habe ich außer Haus immer dabei (ebenso wie das Handy   )...
...und das funktioniert EINWANDFREI!
Keine "Fehlalarme" und ausreichend "schnell" (also [deutlich] unter 5min)...


Seither habe ich keine "Untersuchung" mehr bzgl. Anwesenheitserkennung mit Unifi gemacht...
...evtl. (falls noch vorhanden) kann ich ja mal das Logging noch mal mitlaufen lassen und dann mit dem BT-Dongle vergleichen...

EDIT: allerdings verlasse ich aktuell das Haus nicht wirklich oft

Ansonsten, wenn du PRESENCE zusammen mit Unifi nutzt, kannst du ja auch die "Pingzeit" hochdrehen oder presenceThreshold setzen...

Mehr kann ICH leider nicht beitragen, sorry!

Gruß, Joachim

[flummy1978]

Hallo Joachim,

kurze OT Frage...

Bin nun letztendlich auf einen Gigaset BT-Dongle gegangen.
Ja es hängt zusätzlich was am Schlüsselbund aber den Schlüssel habe ich außer Haus immer dabei (ebenso wie das Handy   )...
...und das funktioniert EINWANDFREI!
Keine "Fehlalarme" und ausreichend "schnell" (also [deutlich] unter 5min)...

Ist es sehr schwer für einen (fast) DAU was den Raspi und Linux etc angeht die Dinger in Betrieb zu nehmen bzw in Verbindung mit Fhem zu bekommen? *grübel*
Eine (vielleicht vorhandene) Anleitung wäre natürlich das iTüpfelchen 

Vielen Dank und viele Grüße
Andreas

[MadMax-FHEM]

Hallo Andreas,

dann mal (kurz) OT: https://wiki.fhem.de/wiki/PRESENCE#.C3.9Cberwachen_mittels_Bluetooth

Du musst dich entscheiden, ob der fhem Server selbst per BT "überwachen" soll -> presenced

oder ob ein anderer PI das übernehmen soll und fhem dann diesen "abfragt" -> lepresenced

(bei mir war es lepresenced, da bei meinem fhem PI BT deaktiviert ist)

Beides sind Scripte in /opt/fhem/contrib/PRESENCE/ bzw. deb-Pakete in /opt/fhem/contrib/PRESENCE/deb

Auf dem fhem Server einfach, da ja schon "dort"...
...bei lepresenced muss das Script bzw. deb-Paket halt erst mal auf den "anderen PI"...

Ich habe also das deb-Paket dorthin kopiert und dann einfach:

Code Auswählen Erweitern

sudo dpkg -i lepresenced-0.9-1.deb
(oder welche Version halt gerade verfügbar ist)

EDIT: laut meinen Notizen kann es sein, dass du noch ein

Code Auswählen Erweitern

sudo apt-get --fix-broken install "hinterher schieben" musst...

Installiert auf einem Raspbian Buster Lite...

Dann in fhem ein entsprechendes PRESENCE definieren vorher halt die MAC ermitteln:

sudo hcitool lescan

Ausgabe z.B.:
LE Scan ...
7C:2F:80:A1:XA:XD (unknown)
7C:2F:80:A1:XA:XD Gigaset G-tag <- das ist er
7C:2F:80:A1:X4:X1 (unknown)

Und dann halt ein PRESENCE in fhem definieren, entweder halt "lokaler BT" oder eben lan-BT...

Eigentlich ganz einfach...
...verwirrend ist (bzw. war für mich) nur: presenced, lepresenced oder collectord

EDIT: und die vielen verschiedenen Varianten der Installation(smöglichkeiten)... Ich dachte mir dann: deb-Paket kopieren und installieren klingt einfach

Was ich nicht umgesetzt habe ist collectord (also verschiedene verteilte BT-PIs) -> größere "Abdeckung"...
Da ich das nicht gebraucht habe, weil mein Schlüssel mit Dongel wenn ich da bin eben in der Schlüsselschale liegt und wenn ich weg bin definitiv außer Reichweite ist...
...wenn du nat. (wie mit dem Handy) mit dem Dongle durch die Wohnung oder ein Haus laufen willst -> collectord...

Was ich auch nicht umgesetzt habe (vielleicht noch nicht): Batterie-Erkennung...

Aber wenn ich mal nicht mehr da sein sollte, obwohl ich da bin, werde ich einfach die Batterie checken

Wenn weitere Fragen, besser im passenden Unterforum einen Thread öffnen...

EDIT: nachgelagerte Logiken testen ist nat. nicht so einfach wie mit dem Handy -> WLAN an/aus... Hier dann wirklich entweder weit wegtragen oder (großzügig) in Alufolie wickeln...

Gruß, Joachim

[Leo1973]

Hallo Miteinander,
gibt's hier eigentlich was Neues zum Thema Connect zu einem UDM Pro? Ich habe meinen CloudKey 2 Plus und USG gegen eine Unifi Dream Machine ausgetauscht weil ich mit der USG meine Internet Bandbreite nicht voll ausnutzen konnte. Nun funktioniert logischerweise der Connect von FHEM auf den Unifi Controller nicht mehr.
oKenny schrieb ja, dass er es zum Laufen bekommen hatte. Das 74_Unifi Modul welches er verwendet hab ich bei mir ausprobiert. Wie bei einigen anderen funktioniert es bei mir trotzdem nicht. Hat in der Zwischenzeit vielleicht jemand das zum Laufen bekommen und kann Hilfestellung geben? Wäre für Unterstützung dankbar.

Viele Grüße

[bogi999]

Wie bei einigen anderen funktioniert es bei mir trotzdem nicht. Hat in der Zwischenzeit vielleicht jemand das zum Laufen bekommen und kann Hilfestellung geben? Wäre für Unterstützung dankbar.

Es lief bislang wohl NUR bei @oKenny, sonst bei keinem. Zumindest is mir niemand bekannt.

[Leo1973]

@oKenny:

Wo hast du im Controller die Einstellung für "Enable WebSocket connection" gefunden? Kannst du bitte mal die Scripte für das dis- enablen von AP's und Switches posten?

Vielen Dank im Voraus.

[Maui]

Moin. Versucht es doch erstmal ohne fhem.
Auf einem pi oä folgenden curl-Befehl ausführen (ggf. curl installieren und natürlich ip, ggf. port und user pw ändern)

Code Auswählen Erweitern


curl -k --data '{"username":"DERUSER","password":"DASPW"}' --fail https://192.168.1.198:8443/api/auth/login


[Leo1973]

Moin. Versucht es doch erstmal ohne fhem.
Auf einem pi oä folgenden curl-Befehl ausführen (ggf. curl installieren und natürlich ip, ggf. port und user pw ändern)

Code Auswählen Erweitern


curl -k --data '{"username":"DERUSER","password":"DASPW"}' --fail https://192.168.1.198:8443/api/auth/login


Ich habe aktuell noch einen CloudKey 2 Plus sowie den UDM Pro - beide in Betrieb und kann also ausprobieren.
Folgender Aufruf auf dem CloudKey 2 Plus funktioniert:

Code Auswählen Erweitern

curl -k -c /tmp/unifiCookie --data '{"username": "<mein Username>", "password": "<mein PW>"}' https://192.168.xxx.xxx:8443/api/login
Response ist: {"meta":{"rc":"ok"},"data":[]}

Der exakt selbe Aufruf auf die URL des UDM Pro: https://192.168.xxx.xxx/api/auth/login schlägt fehl und gibt folgendes zurück:
{
  "errors": [
    "Invalid username or password"
  ]
}

Username und Passwort durchgetauscht und verschiedene ausprobiert. Alle getesteten User haben maximale Berechtigungen. Leider ohne Erfolg.
Die Controllerversionen sind jeweils 5.13.30 auf dem UDM und 5.13.32 auf dem Cloud Key 2 Plus.

Kann das jemand von euch vielleicht ebenfalls ausprobieren? Zumindest auf nem UDM Pro?

[Maui]

Glaub zwar nicht dass es was ändert aber nimm mal das -k weg und auch mal die cookies.
User und passwort sind aber sichee richtig?

[Leo1973]

Das -k ist notwendig. Steht für --insecure. Sonst wird folgendes gemeldet:
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Cookie hab ich entfernt.
Username und PW sind definitiv richtig. Puh das scheint ne echt harte Nuss zu sein...

[Maui]

Blind testen (ohne udm) ist halt immer blöd.
Kommst per ssh auf deine udm oder kommst sonst an die logs?