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

Begonnen von rapster, 23 August 2015, 02:12:04

Vorheriges Thema - Nächstes Thema

popy

Zitat von: Wuehler am 21 Februar 2020, 22:26:40
Hi,

im Anhang eine Testversion. Mal schauen, ob es hilft.

VG,
Dirk

leider nicht, nach dem reload:


syntax error at ./FHEM/74_Unifi.pm line 1012, near "{ }"
Global symbol "$h" requires explicit package name at ./FHEM/74_Unifi.pm line 1012.
syntax error at ./FHEM/74_Unifi.pm line 1012, near "})"
Global symbol "$h" requires explicit package name at ./FHEM/74_Unifi.pm line 1013.
Global symbol "$hash" requires explicit package name at ./FHEM/74_Unifi.pm line 1013.
Global symbol "$h" requires explicit package name at ./FHEM/74_Unifi.pm line 1013.
Global symbol "$hash" requires explicit package name at ./FHEM/74_Unifi.pm line 1014.
Global symbol "$h" requires explicit package name at ./FHEM/74_Unifi.pm line 1014.
Global symbol "$hash" requires explicit package name at ./FHEM/74_Unifi.pm line 1016.
Global symbol "$h" requires explicit package name at ./FHEM/74_Unifi.pm line 1016.
Global symbol "$hash" requires explicit package name at ./FHEM/74_Unifi.pm line 1021.
Global symbol "$data" requires explicit package name at ./FHEM/74_Unifi.pm line 1021.
Global symbol "$hash" requires explicit package name at ./FHEM/74_Unifi.pm line 1023.
Global symbol "$param" requires explicit package name at ./FHEM/74_Unifi.pm line 1023.
Global symbol "$hash" requires explicit package name at ./FHEM/74_Unifi.pm line 1026.
Global symbol "$self" requires explicit package name at ./FHEM/74_Unifi.pm line 1026.
syntax error at ./FHEM/74_Unifi.pm line 1028, near "}"
./FHEM/74_Unifi.pm has too many errors.


Wollte extra fhem nicht neustarten, soll ich?

Wuehler

sorry, am Ende nicht gespeichert und ne Zwischenversion hochgeladen  :-[. Neuer Anhang

popy

Zitat von: Wuehler am 21 Februar 2020, 22:42:45
sorry, am Ende nicht gespeichert und ne Zwischenversion hochgeladen  :-[. Neuer Anhang

Habe mir ledier damit mein Unifi device zerschossen gehabt durch das reload. Egal, kann passieren  :o
nach fhem neustart war es weg -> gleiche Fehler beim starten von fhem.
Blöderweise habe ich eine art Autosave welches dann fhem.cfg ohne das unifi device gespeichert hat.
Nachdem ich die org 74_Unifi.pm wiederhergestellt habe und aus einer Sicherung das define war es wieder da....

...aber der Fehler ist weg. Sprich mein Gerät wird als connected angezeigt  :(

Habe jetzt wieder auf 5Ghz verbunden und da war der Fehler sofort wieder da mit dem original Modul.
Dann ein UnifiClient angelegt auf mein Handy und im Eventmonitor den fhem_state gefiltert mit: UnifiClient_OnePlus6T.*fhem_state.*

Hier die durchaus positiven Ergebnisse:

Alt - in der gleichen Sekunde connected & disconnected:
    2020-02-21 22:52:50 UnifiClient UnifiClient_OnePlus6T fhem_state: connected
    2020-02-21 22:52:50 UnifiClient UnifiClient_OnePlus6T fhem_state: disconnected

Neu - nur mehr connected  :D:
    2020-02-21 22:56:45 UnifiClient UnifiClient_OnePlus6T fhem_state: connected
    2020-02-21 22:57:16 UnifiClient UnifiClient_OnePlus6T fhem_state: connected

Auch der state toggelt nicht mehr sichtbar beim UnifiClient.
Schaut aus als ob das Problem durch die neue Version auf den ersten Blick weg ist.

Ich lasse das mal laufen und berichte.
Ev. kann auch @Motivierte linke Hände das mal testen?

Danke jedenfalls für die schnelle Hilfe.
Gute Nacht







popy

Hallo Zusammen.

Habe mein Problem nun endlich gelöst.
Die Lösung war einfacher als gedacht, aber dazu am Schluss mehr.

Hier mal das Problem:
Habe 3x Handys mittels PRESENCE und einer eigenen Funktion überwacht:


function { ((ReadingsVal("WZ_unifi_controller","OnePlus6T","") eq "connected") and (index(ReadingsVal("WZ_unifi_controller","OnePlus6T_accesspoint",""), "AP ")) != -1) ? 1 : 0}


Das funktionierte bei 2x Handys normal nur bei meinem nicht.
Es passierte immer wieder dass der state connected/disconnected toggelte, obwohl das Gerät 100% online war (Unifi zeigte Online & Wifi am Gerät funktionierte).
Dieses toggeln konnte man im Polling Intervall (30 Sekunden) beobachten (besser dann mit dem Event Viewer).
Somit löste dass PRESENCE aus und ich saß manchmal im Dunkeln.

Das Problem war sporadisch wegzubekommen indem man fhem, unifi neu startete.

Durch besseres analysieren mittels Eventmonitor sah ich dass Unifi immer den gleichen 2,4 Ghz Client als disconnected meldete.
Ich war aber mit 5 Ghz verbunden. Das 2,4 Ghz Wifi entfernte ich vom Handy.
Brachte aber keine Abhilfe.

Durch dieses "fehlerhafte" disconnected Event des 2,4 Ghz Wifi wurde das richtige "connected" des 5 Ghz Wifi immer überschrieben.
Je nachdem, wie es sich zeitlich ausging gewann manchmal das connected und manchmal das disconnected.

Lösung:

  • Im Unifi Controller -> Clients -> All configured Clients -> alle 3 Schalter auf All stellen -> da waren nun 2x Clients mit gleichem Namen sichtbar -> den gelöscht wo last seen länger her ist.
  • IgnoreWiredClients auf 1 gesetzt -> ich überwache nur Handys

Im Eventviewer sah ich dann das der Unifi Controller den 2,4 Ghz Client nicht mehr meldete, yipi.

Lass das jetzt mit dem originalen eingecheckten Modul mal paar Tage laufen und beobachte das weiter.
Schaut aber sehr verdächtig aus.
Auf gut deutsch, ich hatte das Gerät mal mit 2,4 Ghz verbunden und der Controller merkte sich das und meldete den Client immer als disconnected.
Alle anderen überwachten Handys, gab es nur einmal in der Liste, darum hatten die das Problem nicht.

@Wuehler Sorry das ich Deine Zeit beansprucht habe wegen dem Thema! Aber, ich glaube noch immer dass das Modul ein Problem hat mit 2,4 Ghz & 5 Ghz.
In meinem Fall verwende ich für meine Geräte zum Glück nur 5 Ghz, so komme ich mit dem Workaround gut aus.

Vielleicht hilft das mal jemanden.

Motivierte linke Hände

Zitat von: popy am 23 Februar 2020, 22:17:51

  • IgnoreWiredClients auf 1 gesetzt -> ich überwache nur Handys

Das bringt Probleme, WENN man nicht nur Unifi APs, sondern auch einen Unifi-Switch hat und ein AP hinter einem Switch hängt. Denn dann zählt ein mit diesem AP verbundenes Handy wohl als Wired und nicht als Wireless...
FHEM 6 in einer KVM VM mit Ubuntu
HM-CFG-USB2, 2xHM-CFG-HMLAN, HM-HMUARTLGW mit 100+ HomeMatic Devices, Geofencing, Fritzbox, Unifi, HUE, Harmony-Hub, Denon-Receiver-Modul, Calendar, GardenaSmartDevice, Shelly, MQTT (zigbee2mqtt, Tasmota und Shelly) und ein wenig 1Wire.

popy

Zitat von: Motivierte linke Hände am 23 Februar 2020, 22:37:25
Das bringt Probleme, WENN man nicht nur Unifi APs, sondern auch einen Unifi-Switch hat und ein AP hinter einem Switch hängt. Denn dann zählt ein mit diesem AP verbundenes Handy wohl als Wired und nicht als Wireless...

Hmm, bei mir werden die wireless clients als nicht wired gekennzeichnet. Habe aber einen AP hinter einem Switch!?

Aber du hattest ja das Thema oben, werde dann das IgnoreWiredClients weglassen und testen.

Das Problem bei mir war devinitiv der doppelte Client im Controller.

Danke pOpY

Motivierte linke Hände

FHEM 6 in einer KVM VM mit Ubuntu
HM-CFG-USB2, 2xHM-CFG-HMLAN, HM-HMUARTLGW mit 100+ HomeMatic Devices, Geofencing, Fritzbox, Unifi, HUE, Harmony-Hub, Denon-Receiver-Modul, Calendar, GardenaSmartDevice, Shelly, MQTT (zigbee2mqtt, Tasmota und Shelly) und ein wenig 1Wire.

Wuehler

Hi popy,
schön, dass du das Problem eingrenzen und erstmal für dich beheben konntest.
Aus Modulsicht dürfen die Readings dann nicht mehr wie die Geräte heißen sondern müssten die ID berücksichtigen. Der UnifiController hat ja zum selben Gerätenamen zwei Einträge gehabt und an das Modul gesendet. Beide haben dasselbe Reading verändert. Daher das Toggeln. Die Readings anders zu benennen ist denke ich aber auch keine Lösung, da dann alles sehr wenig intuitiv wird.
Ich werde mal drüber nachdenken wie man dem Anwender wenigstens bei der Fehlersuche unterstützen kann. ZB durch eine Logmeldung, wenn es Geräte mit demselben Namen gibt. Da es Geräte mit mehreren Netzwerkkarten gibt (Notebook) muss ich wahrscheinlich zusätzlich die MAC berücksichtigen.
Da der State für die meisten das wichtigste ist, ist es bei doppelten Geräten wahrscheinlich sinnvoll, sie als connected anzuzeigen, sobald eines connected ist. Wie das ohne Einfluss auf bestehende Automatisierungen möglich ist muss ich auch durchdenken.

VG,
Dirk

popy

Zitat von: Wuehler am 24 Februar 2020, 08:39:05
Hi popy,
schön, dass du das Problem eingrenzen und erstmal für dich beheben konntest.
Aus Modulsicht dürfen die Readings dann nicht mehr wie die Geräte heißen sondern müssten die ID berücksichtigen. Der UnifiController hat ja zum selben Gerätenamen zwei Einträge gehabt und an das Modul gesendet. Beide haben dasselbe Reading verändert. Daher das Toggeln. Die Readings anders zu benennen ist denke ich aber auch keine Lösung, da dann alles sehr wenig intuitiv wird.
Ich werde mal drüber nachdenken wie man dem Anwender wenigstens bei der Fehlersuche unterstützen kann. ZB durch eine Logmeldung, wenn es Geräte mit demselben Namen gibt. Da es Geräte mit mehreren Netzwerkkarten gibt (Notebook) muss ich wahrscheinlich zusätzlich die MAC berücksichtigen.
Da der State für die meisten das wichtigste ist, ist es bei doppelten Geräten wahrscheinlich sinnvoll, sie als connected anzuzeigen, sobald eines connected ist. Wie das ohne Einfluss auf bestehende Automatisierungen möglich ist muss ich auch durchdenken.

VG,
Dirk

Hi Dirk.

Da hast du natürlich recht dass der Geräte Namen intuitiver ist als die _id. Eine "einfache" Möglichkeit wäre "Name_id" also z.B.: OnePlus6T_xxxxxxxxx.
So ist nicht viel zu ändern im Modul und in meinem Fall wären dann zwei Geräte sichtbar gewesen wovon das eine mit dem 5 Ghz AP das richtige wäre.

Die Idee mit der MAC und Gerät als connected anzeigen wenn eines von mehreren auf connected ist, wäre wahrscheinlich die beste Lösung.
Glaube dass es damit einige Probleme weniger gibt  ;)

lg

Fs79

kurzes Update zur UDM ( Unifi Dream Machine), hab den Pfad probiert.
Es kommen jetzt Authentifizierungs Probleme.

Bei Updates sage ich Bescheid, vielleicht habe Ihr ja noch Ideen.
Wenn ich am UDM authentifiziert bin, funktioniert die API mit dem *proxy* Pfad erstmal.
Vielen Dank für die Info.

Bin derzeit im Umzug und kümmere mich so nebenbei drum daher entschuldigt meine sporadischen späten Feedbacks.

andies

Ich habe eine Frage zu diesem Modul und habe in der commandref dazu nichts gefunden. ich habe zwei Unifi-APs und einen ESP, der sich eigentlich immer mit einem AP verbinden soll. Bei einer Verbindung mit dem anderen AP ist der RSSI-Wert viel zu niedrig.

Ich erfasse jetzt die RSSI Werte mit einem DOIF
defmod UART2_RSSI_check DOIF ([Unifi:ESP-Easy-UART2_snr]<10)
und möchte dann aber, dass sich der Client ESP-Easy-UART2 erneut verbindet, reconnected. Im Controller geht das mit einem Mausklick. Kann man das mit dem Modul auch bewerkstelligen? "set Unifi reconnect" habe ich aber nicht gefunden.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

MadMax-FHEM

Beim Modul heißt es "disconnect" Client.

Also:

set UnifiControllerName disconnectClient ClientName

EDIT: statt RSSI kannst du auch ein UnifiClient-Device anlegen und dort ein Notify auf ClientName:accesspoint einrichten und dort dann beim "falschen" AP ein reconnect (bzw. disconnectClient) aufrufen... Aber wenn RSSI zuverlässig funktioniert ist es nat. auch gut ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

towag

Hallo

Ich wollte das UNIFI-Modul in meiner Automation einbinden (Controller mit 6 Switches). In der Systemüberwachung konnte ich dann einen stetigen Speicherverbrauch erkennen. Kommentiere ich die Definitionen aus läuft das System mit stabilen Memory (siehe Grafik)
Das war die einzige Änderung am System (rasp mit buster und aktuellem Patch-Stand).

In Perl bin ich nicht so fit. Ich unterstütze aber gerne bei der Suche, weil ich die gesamte FHEM-Lösung genial finde.


lg
Thomas

MadMax-FHEM

Diesen und ähnliche Threads kennst du: https://forum.fhem.de/index.php/topic,84372.msg766405.html#msg766405

EDIT: wenn man das verfolgt (und das habe ich, mein "Verdächtiger" war "damals" das echodevice-Modul) sieht man, dass da oft mehr zusammenkommt... Auch wenn es so aussieht, dass es EIN Modul sein MUSS ;)

Ich habe Unifi noch auf Stretch (Testsystem) laufen und sehe auch sehr, sehr, sehr leichten Anstieg...
(also über 30 Tage sehe ich was)

Werde es aber demnächst mal auf mein Buster Testsystem "überführen" und testen.
Sollte der Anstieg so leicht bleiben wie jetzt kommt es auf mein Hauptsystem (Buster)...
...wenn nicht, dann warte ich bzw. versuche mit zu analysieren (helfen)...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

bogi999

Zitat von: rcmcronny am 18 Februar 2020, 12:17:36

UnifiOS ist: baseurl . '/proxy/network' . $path;

Probiert mal:
https://<deine ip>/proxy/network/api/s/default/self

Hallo Zusammen,

Hab mir das auch mal angesehen. Ich hoffe ich geb das korrekt wieder.

Beim normalen Controller authentifizierst Du Dich auf der "https://IP:8443".
Beim Unifi-OS erfolgt beim Aufruf der URL https://ip:443/proxy/network/api/s/default erst einmal ein redirect auf https://ip/login?redirect=%2Fnetwork.

Ich bekam das mit dem FHEM Mopdul nicht ans laufen. Der Unifi API Browser macht es aber einwandfrei.