Hallo Zusammen,
habe soeben das neue Modul 74_Unifi eingecheckt, welches die API des UBNT Unifi-Controller verwendet um verschiedene Aktionen an den Geräten (z.B. WLAN Accesspoints) durchzuführen und Information & Statistiken abzufragen.
Der Funktionsumfang ist i.M. noch relativ begrenzt,
- Man kann die PRESENCE Funktionalität nutzen (mein Hauptgrund für das Modul), welche einen sofort sobald sich ein Gerät mit dem WLAN verbindet, und etwa 5 Minuten nachdem es sich wieder disconnected benachrichtigt.
- Man kann sich detailierte Informationen der WLAN-Clients ausgeben lassen.
Die PRESENCE Funktionalität meldet erst ein disconnect wenn das Gerät wirklich disconnected ist!
Da der Unifi Controller selbst im PowerSave-Mode (üblich bei MobileDevices, in diesem Modus ist kein Ping möglich) eine Verbindung zum Gerät hat.
Weitere Infos sind in der Commandref zu finden.
Gruß
Claudiu
Hi!
Das hört sich toll an! Kannst du mir das Modul schicken oder hier anhängen?
Du schreibst, die Abwesenheitsmeldung würde bei dir etwa 5 Minuten dauern, nachdem das Gerät offline geht! Bei mir sinds ziemlich genau 10 Minuten!Kann man diese Zeit über das Modul beeinflussen? Das wäre nämlich genau das, was ich bräuchte!
Besten Dank!!
Hallo Michi,
das Modul wird ganz normal über FHEM-Update verteilt.
Also in die Fhem-Kommandozeile einfach "update" eingeben.
Anschließend findest du in der Commandref ein Beispiel und Hilfe wie man Unifi in fhem definiert.
Habe gerade allerdings eine neue Version eingecheckt, welche ab Morgen früh im Update ist, oder welche du jetzt im SVN herunterladen kannst.
In der neuen Version hat sich zwar ein bisschen was geändert, aber grundlegend funktionieren tut die momentane auch schon :-)
Die 5 Minuten kommen vom Controller selber, das ist der Zeitpunkt nachdem der Controller das Device (z.B. wenn man sein Handy komplett ausschaltet) als disconnected markiert. (Das sind dann evtl. bei dir auch 10 Minuten, falls du eine andere Controller Version verwendest als ich.)
Unifi selber bietet dir aber für jedes WLAN-Gerät ein Reading <deviceID>_last_seen wodurch du dir selber nach beliebiger Zeit eine disconnected Meldung generieren kannst.
Gruß
Claudiu
Zitat von: rapster am 23 August 2015, 19:03:34
Die 5 Minuten kommen vom Controller selber, das ist der Zeitpunkt nachdem der Controller das Device (z.B. wenn man sein Handy komplett ausschaltet) als disconnected markiert. (Das sind dann evtl. bei dir auch 10 Minuten, falls du eine andere Controller Version verwendest als ich.)
Unifi selber bietet dir aber für jedes WLAN-Gerät ein Reading <deviceID>_last_seen wodurch du dir selber nach beliebiger Zeit eine disconnected Meldung generieren kannst.
Wie meinst du das? Ja bei mir kommen die 10 Minutem vom Controller und das würde ich gerne runtersetzen, weil das viel zu lange dauert! Problem: Ich verlasse das Haus, iPhone wird aber erst 10 Minuten später als offline erkannt! Die Dauer will/muss ich unbedingt verkürzen!!
Wie gesagt, wenn du das Standardverhalten nicht möchtest, kannst du dazu das Reading <deviceID>_last_seen welches jedem WLAN-Device zur Verfügung steht verwenden.
Beispiel für 3 Minuten mithilfe von DOIF:
define di_unifi_presence DOIF (time()-time_str2num([myUnifiController:MyClient_last_seen]) > 180) (set dummy disconnected) DOELSE (set dummy connected)
oder 3 Minuten mit einem notify:
define ntfy_unifi_presence notify myUnifiController:MyClient_last_seen:.* {
if (time() - time_str2num($EVENT) > 180) {
fhem("set dummy disconnected");
} else {
fhem("set dummy connected");
}
}
Gruß
Claudiu
D.h., dass dieses Reading direkt anzeigt, wenn ein Device offline geht und nicht erst nach den 5 oder 10 Minuten?
Kannst du mal einen Link zum SVN reinsetzen, ich kann das Modul leider nicht finden und ich will gerade kein "update" machen, da ich seit längerem keins gemacht habe und nachher zickt FHEM irgendwo rum und ich habe heute Abend keine Lust mehr auf evtl. Mehrarbeit! ;-)
Genau, in diesem Reading steht der Zeitpunkt des letzten Kontakt zum Controller, also plus/minus wenigen Sekunden die Zeit in der es tatsächlich offline ging.
Hier kannst du die Dateien aus dem SVN downloaden: https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/ (https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/)
Falls deine HttpUtils.pm allerdings älter als 2 Tage ist (was ich denke wenn du länger kein Update gemacht hast) musst du dieses Modul auch zwingend aktualisieren damit Unifi funktioniert.
Zitat von: rapster am 23 August 2015, 19:39:03
Wie gesagt, wenn du das Standardverhalten nicht möchtest, kannst du dazu das Reading <deviceID>_last_seen welches jedem WLAN-Device zur Verfügung steht verwenden.
Beispiel für 3 Minuten mithilfe von DOIF:
define di_unifi_presence DOIF (time()-time_str2num([myUnifiController:54245784e4b0b49b2ded629f_last_seen]) > 180) (set dummy disconnected) DOELSE (set dummy connected)
oder 3 Minuten mit einem notify:
define ntfy_unifi_presence notify myUnifiController:54245784e4b0b49b2ded629f_last_seen:.* {
if (time() - time_str2num($EVENT) > 180) {
fhem("set dummy disconnected");
} else {
fhem("set dummy connected");
}
}
Gruß
Claudiu
Das sollte auch einfach mit:
define di_unifi_presence DOIF ([myUnifiController:54245784e4b0b49b2ded629f_last_seen:sec] > 180) (set dummy disconnected) DOELSE (set dummy connected)
gehen.
Gruß
Damian
Hallo Damian,
funzt 1A, tagtäglich entdeckt man an diesem DOIF Modul etwas neues tolles ;D
Gruß
Claudiu
Ups, doch zu schnell getestet, scheint leider doch nicht zu funktionieren.
Kann es sein das :sec auf 'TIME' geht und nicht auf 'VAL'?
In diesem Fall steht der benötigte Zeitstempel in 'VAL', hast du dafür evtl. auch noch ne kürzere Lösung?
Gruß
Claudiu
Hmmmmmmmmm........
habe beide pm Dateien neu einkopiert aber Fhem stürzt jedes Mal ab, wenn ich das define anlegen will.........Ne Idee?
Am besten mal ein normales Update machen.
Ich denke da werden jetzt irgendwelche Abhängigkeiten nicht mehr stimmen, oder in deinem Versionsstand sind verwendete Funktionen noch nicht enthalten.
Du kannst aber auch mal "attr global verbose 5" probieren um zu schauen bei was genau fhem abstürzt)
Ok dann nehme ich mir mal morgen Abend das "update" vor! Das läuft ganz bestimmt nicht sauber über die Bühne! Hab ca. 4-5 Monate nicht mehr upgedated!
Zitat von: rapster am 23 August 2015, 21:49:59
Ups, doch zu schnell getestet, scheint leider doch nicht zu funktionieren.
Kann es sein das :sec auf 'TIME' geht und nicht auf 'VAL'?
In diesem Fall steht der benötigte Zeitstempel in 'VAL', hast du dafür evtl. auch noch ne kürzere Lösung?
Gruß
Claudiu
ja sec-Option bezieht sich tatsächlich auf den TIME-Wert. Wenn es der Wert selbst ist, dann ist deine Lösung die korrekte und wahrscheinlich auch die kürzeste.
Gruß
Damian
Hallo Rapster
Besten Dank für deine Arbeiten in diesem Modul. Ich wollte dieses heute installieren, bin aber wohl an einem Überlegungsfehler gescheitert...
Ich wollte mit dem Modul auf einen meiner 3 Accesspoints zugreifen und habe dementsprechend auch die IP eines solchen genommen. Dazu den Port 8443. Das Modul konnte sich jedoch nie mit dem Accesspoint verbinden.
Bei mir läuft der Controller auf einem Windows PC der sehr selten läuft, von dort aus kann ich mich problemlos auf die einzelnen Accesspoints einloggen.
Beim genauen durchlesen deines CommandRef Eintrages bin ich darauf gestoßen, dass du geschrieben hast die IP des UniFi Controllers. Das wäre in meinem Fall jetzt aber mein Windows PC! @dernieläuft@
Heißt das ich kann das Modul nicht nutzen oder wie hast Du das gelöst???
Gesendet von iPad mit Tapatalk
Hallo Mumpitz,
richtig, das Modul verwaltet die AccessPoints über die API des Unifi-Controllers.
Ich bin mir nicht sicher ob es sinnvoll ist zu versuchen das über die Accesspoints selber zu machen, da spricht zu viel dagegen.
Das Modul setzt zumindest vorraus, dass in den Momenten wo etwas getan werden soll, oder du benachrichtigt werden willst, der Controller Verfügbar ist.
Allerdings steht der Unifi-Controller sowohl für Linux(Debian & Ubuntu), Raspbian, Windows (und glaube sogar Osx) zur Verfügung, und groß auftragen tut er ebenfalls nicht.
Also warum nicht einfach mit auf deiner FHEM-Hardware installieren?
Auf Raspbian soll er für einen Nicht-IT'ler etwas kompliziert zu installieren sein, sagt mein Nachbar ;D ...aber er hats auch geschafft ;)
Dazu kommen dann gleich noch paar schöne Features wie Zero-Handoff Roaming, Statistiken, usw. welche nur zur Verfügung stehen wenn auch der Controller 24/7 läuft.
P.S. Dein gewünschtes Feature aus dem anderen Thread (WLAN-deaktivieren/aktivieren), sollte denke ich ebenfalls klappen und werde ich in Kürze versuchen zu implementieren.
Gruß
Claudiu
Ok. Dann weiß ich ja was ich in den nächsten Abenden zu tun habe :-)
Super wenn man es abschaltbar machen kann! Wäre genau meine Anforderung.
Gibt es auch die Möglichkeit, den Gastzugang zu aktivieren/deaktivieren???
Gesendet von iPad mit Tapatalk
Ja, Gastzugang-Verwaltung (incl. Voucher, Macbasiert, usw.) steht schon auf der ToDo ;)
Hier mal paar Links:
UniFi Updates Blog (https://community.ubnt.com/t5/UniFi-Updates-Blog/bg-p/Blog_UniFi)
Momentan neuste Version für Debian/Ubuntu:
UniFi 4.6.6 is released (https://community.ubnt.com/t5/UniFi-Updates-Blog/UniFi-4-6-6-is-released/ba-p/1288816)
Laut meinem Nachbarn, die momentan neuste Version für Raspbian:
UniFi 3.2.10 is released (https://community.ubnt.com/t5/UniFi-Updates-Blog/UniFi-3-2-10-is-released/ba-p/1165532)
HowTo Raspbian:
UniFi - Installing the Controller software on Raspberry Pi (https://community.ubnt.com/t5/UniFi-Controller-Installation/UniFi-Installing-the-Controller-software-on-Raspberry-Pi/ta-p/1127992)
Gruß
Claudiu
Oh, das habe ich dann aber auch komplett anders verstanden! Habe jetzt die IP des AP da eingetragen, aber er empfängt nichts!
Also muss man den Controller zusätzlich auf dem RPI installieren? Welche deiner Links sind dafür erforderlich?
Dein toller Support geht weiter! Merci
Für Raspberry muss ich Raspian nehmen, oder?
Denise geht nicht? Da wäre eben die neuere Version verfügbar....
Gesendet von iPad mit Tapatalk
Hallo Rapster
Ich habe meinen Controller welcher auf einem anderen RPi installiert ist wie folgt eingebunden:
Internals:
DEF 192.168.2.22 8443 admin geheim 60 Luftschloss 3
NAME my_unifi_controller
NR 1253
NTFY_ORDER 50-my_unifi_controller
STATE disconnected
TYPE Unifi
interval 60
siteID Luftschloss
url https://192.168.2.22:8443/
version 3
Readings:
2015-08-24 18:58:15 state disconnected
Clients:
Httpparams:
header Content-Type: application/json;charset=UTF-8
ignoreredirects 1
loglevel 5
method POST
noshutdown 0
timeout 5
Hash:
Sslargs:
SSL_verify_mode SSL_VERIFY_NONE
Loginparams:
NAME
addr https://192.168.2.22:8443
buf HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
Content-Type: application/json;charset=ISO-8859-1
Content-Length: 78
Date: Mon, 24 Aug 2015 17:00:19 GMT
Connection: close
{ "data" : [ ] , "meta" : { "msg" : "api.err.LoginRequired" , "rc" : "error"}}
code 401
conn
cookies
data {'username':'admin', 'password':'geheim'}
displayurl https://192.168.2.22:8443/api/login
header Content-Type: application/json;charset=UTF-8
host 192.168.2.22
httpheader HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
Content-Type: application/json;charset=ISO-8859-1
Content-Length: 78
Date: Mon, 24 Aug 2015 17:00:19 GMT
Connection: close
hu_blocking 0
hu_filecount 3
ignoreredirects 1
loglevel 5
method POST
noshutdown 0
path /api/login
protocol https
redirects 0
timeout 5
url https://192.168.2.22:8443/api/login
Hash:
Sslargs:
SSL_verify_mode SSL_VERIFY_NONE
Attributes:
room 1_Favoriten
verbose 5
Jedoch vebindet er sich nicht und im Log steht:
2015.08.24 18:50:33 5: my_unifi_controller: Login_Receive - Connect/Login to Unifi-Controller failed! Will try again after interval...
2015.08.24 18:50:33 5: my_unifi_controller: Login_Receive - Failed with HTTP Code 401!
2015.08.24 18:50:33 5: my_unifi_controller: Login_Receive - executed.
2015.08.24 18:50:32 5: my_unifi_controller: Login_Send - executed.
Die URL kann ich aber aufrufen und kann mich verbinden. Ich habe die Controller Version 3.2.5
Hast du mir einen Tipp?
Danke und Gruss Dani
Zitat von: Mumpitz am 24 August 2015, 19:06:13
Für Raspberry muss ich Raspian nehmen, oder?
Raspian ist genau richtig, einfach zuerst aktualisieren! Ich habe meinen nach folgender Anleitung installiert:
http://erikvanpaassen.tweakblogs.net/blog/10024/turning-a-raspberry-pi-into-a-unifi-controller-appliance.html
Gruss Dani
Hallo Eppi,
evtl. verhält sich die 3.2.5 etwas anders als meine, bei dir wird schon unauthorized beim Login zurückgemeldet,
kannst du mal probieren die Zeile 259 in der /FHEM/74_Unifi.pm durch diese zu Ersetzen, und dann nochmal die Logausgabe mit verbose 5 zu posten:
if ($param->{code} == 200 || $param->{code} == 400 || $param->{code} == 401) {
Gruß
Claudiu
EDIT: falsche Zeilennummer
Hi Rapster
Danke. Leider hatte ich damit keinen Erfolg. Im Log steht:
2015.08.24 19:21:38 5: my_unifi_controller: Login_Receive - Connect/Login to Unifi-Controller failed! Will try again after interval...
2015.08.24 19:21:38 5: my_unifi_controller: Login_Receive - Login Failed! - state:'error' - msg:'api.err.LoginRequired'
2015.08.24 19:21:38 5: my_unifi_controller: Login_Receive - executed.
Hast noch einen Tipp ohne das ich upgraden muss?
Ansonsten bleibt mir nicht viel anderes überig als mich einzulesen, wie ein Upgrade des Controllers zu machen ist...
Danke und Gruss Dani
Ja, denke weiß woran es liegt,
der v3 Controller erwartet das json-login-object urlencoded, bei v4 gehts ohne...
Starte gerade meine alte unifi v3 VM zum testen aus dem Backup, und werde es dann entsprechend für v3 einbauen.
Gruß
Claudiu
Rapster
Mach dir nicht soviel Mühe, ich werde sonst upgraden. Jetzt habe ich einen Grund dazu ;D
Die grundfunktionen des Moduls sollen ja für v3 ebenfalls funktionieren, gerade wenns nur um so eine Kleinigkeit geht.
Nur die Verrenkungen die für v2 nötig wären wollte ich nicht machen :-)
Konnte das Problem auf jedenfall grad bei mir nachstellen.
Sooooo, habe gerade Fhem komplett upgedatet und dann den Controller auf meinem Raspbian installiert! Scheinbar läuft er auch!
Habe dann im DEF die IP Adresse des PIs angegeben, auf dem ja auch Fhem drauf ist! Leider sagt er bei "STATE" immer nur "???"! Es passiert nichts! Was kann ich tun?
EDIT: Fhem neugestartet, jetzt steht der state auf disconneted! Warum denn bloß?
Log:
2015.08.24 19:59:26.579 5: HttpUtils https://192.168.188.200:8443/api/login: Got data, length: 78
2015.08.24 19:59:27.976 5: Unifi_EG: Login_Receive - executed.
2015.08.24 19:59:27.977 5: Unifi_EG: Login_Receive - Login Failed! - state:'error' - msg:'api.err.InvalidObject'
2015.08.24 19:59:27.977 5: Unifi_EG: Login_Receive - Connect/Login to Unifi-Controller failed! Will try again after interval...
beim warten bis sich mein Raspi geupdatet hat bin ich auf folgende Seite gestossen:
http://draganbjelic.com/tutorial-how-to-install-unifi-4-6-0-controller-on-raspberry-pi/ (http://draganbjelic.com/tutorial-how-to-install-unifi-4-6-0-controller-on-raspberry-pi/)
was meint ihr? würdet ihr versuchen die neueste Controller Software zu installieren oder doch lieber bei der 3er Version bleiben?
@Eppi:
Bitte mal die Version hier aus dem Anhang probieren, läuft schonmal mit meiner 3.2.10, <version> in der definition auf 3 setzen!
Zitat von: Michi240281 am 24 August 2015, 19:46:51
Habe dann im DEF die IP Adresse des PIs angegeben, auf dem ja auch Fhem drauf ist! Leider sagt er bei "STATE" immer nur "???"! Es passiert nichts! Was kann ich tun?
@Michi:
Dein Problem "könnte" mit dieser Version auch behoben sein, schick aber am besten mal ein "list" oder logs mit "verbose 5".
Allerdings ist das Fehler abfangen bei v3 sehr blöd, da einfach KEINE Antwort bei erfolgreichem Login abgeliefert wird :-)
Werde die Verison noch etwas aufhübschen, und dann fürs morgige Update einchecken.
Gruß
Claudiu
Edit: Anhang gelöscht, aktuelle Version im FHEM-Update.
So, mit der neuen Version steht er jetzt auf "initialized", jedoch werden keine readings angelegt?!?
Mach mal bitte ein "attr <devicename> verbose 5" am angelegten device, und poste mal die entsprechenden Log-Einträge.
2015.08.24 21:18:54.009 5: Unifi_EG: DoUpdate - executed.
2015.08.24 21:18:54.009 5: Unifi_EG: Login_Send - executed.
mehr kommt da nicht!
Das hier noch:
2015.08.24 21:26:32.854 4: HTTP FHEMWEB:192.168.188.177:54484 GET /fhem?cmd={ReadingsVal(%22Unifi_EG%22,%22clear%22,%22%22)}&XHR=1
2015.08.24 21:26:32.855 5: Cmd: >{ReadingsVal("Unifi_EG","clear","")}<
2015.08.24 21:26:32.864 4: 323:FHEMWEB:192.168.188.177:54484: /fhem?cmd={ReadingsVal(%22Unifi_EG%22,%22clear%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
OK, an der Stelle ruft das Modul eine Funktion eines anderen Moduls auf (HttpUtils), und macht erst weiter wenn die Rückmeldung erhalten wurde.
Mach mal bitte noch "attr global verbose 5" (Achtung jetzt wird ganz viel geloggt).
Und schick mal noch die ausgabe von "list Unifi_EG" (dein user&password steht dort an 2 Stellen, bitte löschen vor dem posten)
EDIT:
Hast du beim 'define' auch <version> gesetzt?
Hallo Rapster
Funktioniert - Danke! ;D
Mein Log :
2015.08.24 21:27:50 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/74_Unifi.pm line 321.
2015.08.24 21:27:50 5: my_unifi_controller: GetClients_Send - executed.
2015.08.24 21:27:50 5: my_unifi_controller: DoUpdate - executed.
2015.08.24 21:27:50 5: my_unifi_controller: Login_Receive - Received-cookies:Cookie: unifises=8ff9e998eefb7ffbbbe4413c7041f4f3\r\n
2015.08.24 21:27:50 5: my_unifi_controller: Login_Receive - Login successfully! - state=ok||version=3
2015.08.24 21:27:50 5: my_unifi_controller: Login_Receive - executed.
State ist nun connected, aber readings habe ich keine der Clients, trotz manuellem set xxxx update..
Muss ich sonst noch was machen?
Gruss & Danke Dani
@eppi nochmal aktuelle Version im Anhang, falls dann immer noch nicht klappt, mach nochmal ein "list my_unifi_controller" nach paar sekunden nachdem das device auf "connected" gewechselt ist.
Edit: Anhang gelöscht, aktuelle Version im FHEM-Update.
Hallo Rapster
Leider im noch gleich...
Anbei der List:
Internals:
DEF 192.168.2.22 8443 admin geheim 60 Luftschloss 3
NAME my_unifi_controller
NR 1253
NTFY_ORDER 50-my_unifi_controller
STATE connected
TYPE Unifi
interval 60
siteID Luftschloss
url https://192.168.2.22:8443/
version 3
Readings:
2015-08-24 21:49:31 state connected
Clients:
Httpparams:
header
ignoreredirects 1
loglevel 5
method POST
noshutdown 0
timeout 5
Hash:
Sslargs:
SSL_verify_mode SSL_VERIFY_NONE
Loginparams:
NAME
addr https://192.168.2.22:8443
buf HTTP/1.1 302 Found
Server: Apache-Coyote/1.1
Set-Cookie: unifises=38699b4eb51b12c4907ab3d31aa6ef22; Path=/; Secure; HttpOnly
Location: https://192.168.2.22/manage/s/default
Content-Type: text/html;charset=UTF-8
Content-Length: 0
Date: Mon, 24 Aug 2015 19:49:30 GMT
Connection: close
code 302
conn
cookies Cookie: unifises=38699b4eb51b12c4907ab3d31aa6ef22
data login=login&username=admin&password=geheim
displayurl https://192.168.2.22:8443/login
header
host 192.168.2.22
httpheader HTTP/1.1 302 Found
Server: Apache-Coyote/1.1
Set-Cookie: unifises=38699b4eb51b12c4907ab3d31aa6ef22; Path=/; Secure; HttpOnly
Location: https://192.168.2.22/manage/s/default
Content-Type: text/html;charset=UTF-8
Content-Length: 0
Date: Mon, 24 Aug 2015 19:49:30 GMT
Connection: close
hu_blocking 0
hu_filecount 1
ignoreredirects 1
loglevel 5
method POST
noshutdown 0
path /login
protocol https
redirects 0
timeout 5
url https://192.168.2.22:8443/login
Hash:
Sslargs:
SSL_verify_mode SSL_VERIFY_NONE
Attributes:
room 1_Favoriten
verbose 5
Gruss und Danke Dani
Was kommt im Log nach:
my_unifi_controller: GetClients_Send - executed.
?
Gruß
Claudiu
2015.08.24 21:55:33 5: my_unifi_controller: GetClients_Receive - Failed! - state:'error' - msg:'api.err.InvalidObject'
2015.08.24 21:55:33 5: my_unifi_controller: GetClients_Receive - executed.
2015.08.24 21:55:31 5: my_unifi_controller: GetClients_Send - executed.
2015.08.24 21:55:31 5: my_unifi_controller: DoUpdate - executed.
Ahh da haben wir das Problem :-)
deine <siteID> 'Luftschloss' scheint nicht zu passen.
Hast du die so herausgefunden wie in der commandref beschrieben?
Normalerweise ist die <siteID> einfach nur: default
Ich änder mal das Loglevel dieser Meldung auf 1, und schreib etwas deutlicheres mit dazu :-)
Gruß
Claudiu
EDIT:
In deinem List stehts ja ;):
Location: https://192.168.2.22/manage/s/default
du musst also als <siteID> default verwenden.
Zitat von: rapster am 24 August 2015, 22:00:05
du musst also als <siteID> default verwenden.
Genau, das war es! Funktioniert nun einwandfrei!!!!
Danke Danke für deine Geduld, Arbeit und grosse Hilfè
Gruss Dani
Freut mich dass es nun klappt :)
Werde dann die Version einchecken damit sie morgen über das Fhem-Update verfügbar ist.
Gruß
Claudiu
Hier das list:
Internals:
DEF 192.168.188.200 8443 ******* ******* 30 default 3
NAME Unifi_EG
NR 1009
NTFY_ORDER 50-Unifi_EG
STATE initialized
TYPE Unifi
interval 30
siteID default
url https://192.168.188.200:8443/
version 3
Readings:
2015-08-24 21:18:53 state initialized
Clients:
Httpparams:
ignoreredirects 1
loglevel 5
method POST
noshutdown 0
timeout 5
Hash:
Sslargs:
SSL_verify_mode SSL_VERIFY_NONE
Loginparams:
NAME
addr https://192.168.188.200:8443
buf HTTP/1.1 302 Found
Server: Apache-Coyote/1.1
Location: https://192.168.188.200/wizard/s/default
Content-Length: 0
Date: Mon, 24 Aug 2015 19:18:55 GMT
Connection: close
code 302
conn
cookies
data login=login&username=*******&password=*******
displayurl https://192.168.188.200:8443/login
host 192.168.188.200
httpheader HTTP/1.1 302 Found
Server: Apache-Coyote/1.1
Location: https://192.168.188.200/wizard/s/default
Content-Length: 0
Date: Mon, 24 Aug 2015 19:18:55 GMT
Connection: close
hu_blocking 0
hu_filecount 1
ignoreredirects 1
loglevel 5
method POST
noshutdown 0
path /login
protocol https
redirects 0
timeout 5
url https://192.168.188.200:8443/login
Hash:
Sslargs:
SSL_verify_mode SSL_VERIFY_NONE
Attributes:
verbose 5
Im Log steht nichts weiteres als ich oben bereits gepostet habe....
Hallo Michi,
Welche Controller Version setzt du ein, da die zurückgemeldet URL mir fremd erscheint?
Nichtsdestotrotz versuche es bitte nochmal mit der Version die seit heute früh über das fhem-update verteilt wird, hier sollte der State bei fehlgeschlagenem Login nicht mehr auf "initialized" festsitzen.
Oder gleich der Version welche ich hier angehangen habe(erst morgen um Update drin), in welcher ein paar mehr Fehler geloggt werden.
----
Allerdings hat die heutige Fhem-Update-Version auch noch einen Fehler (wie die letzten ebenfalls), dieser ist mir erst gerade eben aufgefallen.
Wenn das unifi-device neu definiert wird, startet das polling nicht automatisch. Entweder man muss das device einmal mit "attr disable 1" und "attr disable 0" deaktivieren und wieder aktivieren, oder nach dem define einmal fhem neustarten. Der Fehler betrifft nicht den Fall das man die definition ändert.
Der Fehler ist ab der morgigen Version welche im Fhem-Update ist behoben (oder der hier angehängten).
Gruß
Claudiu
EDIT:
Kannst du dich manuell am Controller anmelden wenn du auf https://192.168.188.200:8443/login gehst?
Auf dem RPi habe ich gestern die 3.2.10 installiert!
Meinst du, weil da "wizard" drin vorkommt? Finde ich auch komisch, denn am Win-PC bekomme ich als URL "https:/localhost:8443/manage/s/default" angezeigt...
Ok, ich teste heute Abend mit der angehängten Version!
Mal eine Halb Off Toppic Frage :-)
Kann der AP für verschiedene SIDS auch verschiedene VLAN's?
ja.
gruss
andre
Zitat von: Michi240281 am 25 August 2015, 11:14:57
Meinst du, weil da "wizard" drin vorkommt? Finde ich auch komisch, denn am Win-PC bekomme ich als URL "https:/localhost:8443/manage/s/default" angezeigt...
Ja genau, kenne das eigentlich auch nur mit /manage/, muss nach der Installation evtl. noch eine Erstkonfiguration durchgeführt werden oder so?
Gruß
Claudiu
Das weiß ich garnicht! Vllt können die anderen was dazu sagen?
Ich habe lediglich nach der von dir geposteten Anleitung die Software installiert und am Ende dann den Controller gestartet! Da kam aber nix weiter......vllt muss man da dann auch erstmal die Logindaten eintragen, aber keine Ahnung wie/wo das geht?!?
Ja denke das muss noch gemacht werden (schon ewig her wo ich meinen Controller installiert hab ;) )
Geh mal heut Abend einfach mit deinem Browser auf https://192.168.188.200:8443/login und versuch dich einzuloggen resp. schau was passiert.
Falls es das wirklich war, gib kurz bescheid, dann würde ich hierfür eine Aussagekräftige Fehlermeldung einbauen :-)
P.S. Die vorne geposteten Anleitungen bzgl. der Installation des Unifi-Controllers habe ich selber nicht ausprobiert, waren nur so als erste Gehhilfe gedacht..
Gruß
Claudiu
@rapster
Ich habe gestern Abend nach der Anleitung von eppi auf meinem Raspi den Controller installiert. Nach dem zweiten Versuch hat es funktioniert!
Offenbar geht es sogar mit der neuesten Version.,4.6.6!
Ok Super, evtl. kann sich Michi die Anleitung ja nochmal anschauen ob evt. was bei der Installation vergessen wurde.
Da ich ein normales x86 Debian verwende kann ich leider nicht viel zu der Raspi und co. installation sagen, auf dem normalen Debian läuft das 4.6.6 zumindest einwandfrei zusammen mit dem Unifi-Modul.
Gruß
Claudiu
@Mumpitz: Musstest du denn noch irgendwas konfigurieren? Ich habe wie gesagt nur die Anleitung befolgt, ich denke auch nichts dabei vergessen und am Ende steht da ja dann der Befehl, wie man den Controller startet! Das habe ich dann getan und damit dann aufgehört?!?
Hab hier nochmal eine neue Version in der recht viel geändert wurde.
Evtl. kann die ja mal noch jemand testen bei dem es bereits funktioniert, bevor ich sie in fhem einchecke?
Gruß
Claudiu
EDIT: File entfernt
Soooo, habe den Controller gerade nochmal gestoppt und gestartet und jetzt komme ich mit der folgenden Adresse auf den Controller.
https://192.168.188.200:8443/login
Dann ändert sich die Adresse aber direkt in
https://192.168.188.200:8443/wizard/s/default
Dann bin ich im Anmeldebildschirm, jedoch gibts da direkt neue Probleme! Zum einen erkennt er überhaupt kein Device und selbst wenn, müsste ich dann dort wieder alles neu konfigurieren? Das geht ja garnicht, das hat ne ganze Weile gedauert und außerdem scheint mir diese Version total abgespeckt, man kann nur eine SSID eingeben und das wars! :(
Hallo Michi,
OK da haben wir dann das Problem auch schon.
Natürlich musst du den Unifi Controller erst Konfigurieren, oder die Einstellungen aus deiner alten Installation exportieren (backup) und in die neue einspielen (restore).
Auch mehrere SSIDs und verschiedene VLANs dafür funktionieren in der 3.x Version, ich habe dir zu beiden Themen 2 Snippings aus meinem Controller angehangen.
Gruß
Claudiu
Ok, hab verstanden! Gerade ein Backup gemacht, leider kann er das nicht auf dem RPI importieren, vermutlich weil es nicht kompatibel ist! Am Win-PC nutze ich Controller Version 4.6.6 und am RPi 3.2.10! Was nun? Und warum findet er am RPi die APs nicht? Sonst würde ich mir das evtl. doch antun und alles neu einrichten!??!
er findet sie vermutlich nicht weil sie schon von einem controller gemanaged werden.
auf den neuen Controller bekommst die sie über das backup oder durch erzwungenes übernehmen. dazu brauchst du aber glaube ich das password das der alte controller verwendet.
gruss
andre
Also in dem "alten" Controller beim AP auf "Forget this AP" klicken? Dadurch wird er für den neuen Controller wieder "sichtbar"? Leider klappt das mit dem Backup ob der unterschiedlichen Versionen wohl nicht!?!
@Michi, genau so wie Andre es beschrieben hat :-)
Du kannst auf dem Windows Controller auch auf "forget" beim AP klicken, dann findet sie der neue Controller, hierzu im Anhang ein Bild.
Alternativ geht das auch über ssh auf den AP z.B. hier: https://community.ubnt.com/t5/UniFi-Wireless/Controller-can-t-see-discover-any-AP/td-p/374392
Das er das Backup nicht mag kann sein, habe nie ausprobiert ein 4.x Backup in einen 3.x Controller einzuspielen.
Gruß
Claudiu
Sooooooooo, es geht!!!! :-)
Habe auch jede Menge Readings! Dazu die erste Frage: Kann man den Devices auch Alias geben? Ähnlich dem Geofancy-Modul?
Dem unifi device selber, kannst du natürlich einen alias verpassen.
Wüsste allerdings nicht dass dies irgendein Modul bei readings unterstützt?
P.S. Wenn du eh schon dabei bist, würdest du evtl. noch kurz die aktuelle Version aus diesem Beitrag testen: http://forum.fhem.de/index.php/topic,40287.msg326142.html#msg326142
Danke ;)
EDIT:
Allerdings ein Hinweis dazu, die Device-ID's sollten ein Controller-Leben lang gleich bleiben.
Im Geofancy-Modul kann man den Readings auch einen Alias geben, siehe hier:
GEOFANCY Modul individualisieren
Die im GEOFANCY Modul dargestellten Readings sind nun in etwa so, wenn ihr euch bewegt:
Readings:
2014-01-18 14:37:42 51F23894-AAAA-BBBB-CCCC-0123456789AB arrived home
2014-01-18 14:37:42 currLocLat_51F23894-AAAA-BBBB-CCCC-0123456789AB 48.9999
2014-01-18 14:37:42 currLocLong_51F23894-AAAA-BBBB-CCCC-0123456789AB 11.9999
2014-01-18 14:37:42 currLocTime_51F23894-AAAA-BBBB-CCCC-0123456789AB 2014-01-18 14:37:42
2014-01-18 14:37:42 currLoc_51F23894-AAAA-BBBB-CCCC-0123456789AB home
2014-01-17 19:18:23 lastArr 51F23894-AAAA-BBBB-CCCC-0123456789AB home
2014-01-17 18:41:46 lastDep 51F23894-AAAA-BBBB-CCCC-0123456789AB Office
2014-01-18 14:37:42 lastDevice 51F23894-AAAA-BBBB-CCCC-0123456789AB
2014-01-17 18:41:46 lastLocArr_51F23894-AAAA-BBBB-CCCC-0123456789AB 2014-01-17 08:58:37
2014-01-17 18:41:46 lastLocDep_51F23894-AAAA-BBBB-CCCC-0123456789AB 2014-01-17 18:41:46
2014-01-17 18:41:46 lastLocLat_51F23894-AAAA-BBBB-CCCC-0123456789AB 48.1111
2014-01-17 18:41:46 lastLocLong_51F23894-AAAA-BBBB-CCCC-0123456789AB 11.1111
2014-01-17 18:41:46 lastLoc_51F23894-AAAA-BBBB-CCCC-0123456789AB Office
2014-01-18 14:37:42 state dev:51F23894-AAAA-BBBB-CCCC-0123456789AB trig:test id:home lat:48.9999 long:11.9999
Wer genauer hinschaut sieht: Mein iPhone heißt wohl 51F23894-AAAA-BBBB-CCCC-0123456789AB. Das ist sehr unübersichtlich. Wir setzen deshalb einen Alias-Namen für das Gerät. Sinnvoll erscheint mir der Vorname des Besitzers:
attr geofancy devAlias 51F23894-AAAA-BBBB-CCCC-0123456789AB:Julian
Weitere Alias-Namen können mit Leerzeichen einfach angehängt werden. Die alten Readings löschen wir mit
set geofancy clear readings
Jetzt sehen die Readings schon viel freundlicher aus:
Readings:
2014-01-18 14:37:42 Julian arrived home
2014-01-18 14:37:42 currLocLat_Julian 48.9999
2014-01-18 14:37:42 currLocLong_Julian 11.9999
2014-01-18 14:37:42 currLocTime_Julian 2014-01-18 14:37:42
2014-01-18 14:37:42 currLoc_Julian home
2014-01-17 19:18:23 lastArr Julian home
2014-01-17 18:41:46 lastDep Julian Office
2014-01-18 14:37:42 lastDevice Julian
2014-01-17 18:41:46 lastLocArr_Julian 2014-01-17 08:58:37
2014-01-17 18:41:46 lastLocDep_Julian 2014-01-17 18:41:46
2014-01-17 18:41:46 lastLocLat_Julian 48.1111
2014-01-17 18:41:46 lastLocLong_Julian 11.1111
2014-01-17 18:41:46 lastLoc_Julian Office
2014-01-18 14:37:42 state dev:Julian trig:test id:home lat:48.9999 long:11.9999
Ist aus dem FhemWiki! Das Attribut nennt sich "devAlias" und macht das ganze deutlich übersichtlicher!
Ok, werde ich direkt testen! Bekommst gleich Rückmeldung!
Ah Ok, sieht einfach aus, baue ich ein :-)
Gruß
Claudiu
Neue Version ist online! Man musste Fhem neustarten, damit er connected, aber jetzt scheints zu laufen wie mit der "alten" Version!
Sooooooooo! PRESENCE Funktion eingebaut und funktioniert SEEEEEEEHR GUT!!!!!!!!!!
VIELEN DANK für das tolle Modul, das ist genau das, was ich gesucht habe!!!!!
Wann genau musstest du neustarten?
Hast du wohl die die neue .pm zu fhem kopiert, fhem neugestartet, die alte definition gelöscht, neu definiert, und anschließend hat er nicht connected?
Im Anhang eine Version mit devAlias, analog zum geofancy modul, d.H. mit Leerzeichen getrennt bei mehreren Geräten.
Nur ganz kurz getestet, muss noch ausprobieren obs beim disconnect auch klappt :-)
Testest du mal, und gibst mir bescheid?
Gruß
Clauidu
EDIT: File entfernt
Folgendes habe ich gemacht:
- Neue Version in Fhem Ordner kopiert
- In Fhem Kommandozeile "reload 74_unifi.pm" eingegeben
- dann stand er auf disconnected
- dann disable 1 und disable 0 gemacht
- hat aber nichts gebracht, immer noch auf disconnected
- shutdown restart und dann war er auf connected
Jepp, super, ich teste ich meld mich gleich!
Neue Version funzt einwandfrei! :)
Bin begeistert!!
Zum Test: OK super, dann passt es, da hatte sich einfach zuviel geändert dass es nur mit reload funktioniert.
Zu den Aliasen: Spitze dass es bei dir auch funktioniert, habs nochmal auf eine schönere Art eingebaut, das landet dann Morgen im Update :-)
Gruß
Claudiu
Tolle Arbeit!
Hab noch eine Frage: Kannst du was zum Ressourcenverbrauch des Moduls sagen? Habe jetzt das Interval auf 10 Sekunden gestellt! So wird dann hoffentlich sehr schnell erkannt, wenn man nach Hause kommt! Hauptsache das frisst dann nicht zu viel Performance!
Ressourcenverbrauch => Nicht Messbar :-)
Edit:
Habs doch mal mehr oder weniger "gemessen" i.M. liegt die Blocking-Time des Moduls auf meinem Dev-System bei jedem update bei ~ 0.002 Sekunden (bei 5 WLAN-Clients und 3 AP's), davon allerdings ~ 0.002 Sekunden allein zum setzen der Fhem-Readings, die eigene Modul-Zeit konnte ich bei dieser Messauflösung nicht messen.
Die Kommunikation selber zur Unifi-API erfolgt natürlich Nonblocking.
P.S. 10 Sekunden sind vollkommen i.O. ich habe diese Intervall min-Beschränkung ohne besonderen Grund gewählt, dachte mir nur dass dies ein "vernünftiger" Wert ist, weil z.B. auch das interne Timeout (falls die Unifi-API z.B. mal 'seltsam' reagieren sollte) auf 5 Sekunden steht.
Falls wirklich bedarf besteht, kann ich das auch gerne noch etwas heruntersetzen.
Sehhhhr schön! :)
Hallo Rapster
Nochmals vielen Dank für Dein Super Modul. Kleine Frage, zwar eher zum Controller als zu deinem Modul:
Weisst Du wo der Controller die ganzen Statistiken ablegt betreffend den eingeloggten Devices, wer wievielte gesogen hat, wie lange online und so?
Meine Frage zielt dahin, dass ich diese andauernden Schreibzugriffe wenn möglich auf den angeschlossenen USB Stick auslagern möchte, damit meine Speicherkarte nicht in wenigen Monaten ins Nirvana wandert...
Danke für Deine Hilfe
Hallo Mumpitz,
zumindest in meiner Installation, liegen die Daten alle unterhalb von /var/lib/unifi, denke das müsste alles im /var/lib/unif/db Ordner sein.
Du musst mal schauen, wo ich vor ü. 1 Jahr den Controller bei mir installiert habe, hatte ich glaube ich auch paar Probleme damit dass die MongoDB ziemlich groß wurde.
Das hatte allerdings soweit ich mich erinnern kann damit zutun dass die DB als eigener Dienst gestartet wurde.
Es finden sich auch recht viele Infos wie man die DB klein halten kann, z.B. hier: https://community.ubnt.com/t5/UniFi-Wireless/UNIFI-Eating-all-disk-space-Mongodb/m-p/395418#M32124
Kann allerdings gut sein dass das auf die aktuellen Versionen nicht mehr zutrifft, ich habe seitdem zumindest kein besonderes Anwachsen der DB bemerkt.
Gruß
Claudiu
Ich hätte da noch eine Frage zum Controller:
Kann vllt jmd eine Anleitung posten, wie er es umgesetzt hat, dass der Controller auch nach einem Neustart automatisch gestartet wird? In den Anleitungen waren verschiedene Ansätze enthalten, jedoch war mir nicht ganz klar, wie man es am elegantesten löst!
Besten Dank!!
Hallo Rapster
Der Unifi Controller bietet die Möglichkeit, einem Decive einen Alias zu geben. Diese Möglichkeit nutze ich, um Geräte ohne Namen (Anstelle des Namens wird die MAC Adresse angezeit) zu benennen. Siehst du eine Chance, diese Aliasnamen auch zu den Device-Reading in FHEM aufzunehmen?
Danke für deine Prüfung!
Viele Grüsse Dani
Hallo Michi
Zitat von: Michi240281 am 27 August 2015, 11:06:03
Kann vllt jmd eine Anleitung posten, wie er es umgesetzt hat, dass der Controller auch nach einem Neustart automatisch gestartet wird?
In meinem Beitrag #21 habe ich einen Link gepostet, der ein Start/Stop Script beinhaltet.
Du findest ihn nach dem Absatz:
So, create the file /etc/init.d/unifi with the following contents:
Gruss Dani
Hallo zusammen
ich habe wie geschrieben den Controller in Betrieb genommen und dieser spuckt auch wunderbar alle Readings aus. Allerdings funktioniert das gepostete DOIF bei mir nicht. Leider finde ich den Fehler nicht...
Internals:
CFGFN
DEF ([UniFi_Controller:Reto_last_seen:sec] > 180) (set Reto abwesend,set pushmsg msg 'fhem' 'Reto hat das Haus verlassen')
DOELSE (set Reto anwesend,set pushmsg msg 'fhem' 'Reto ist nun zu Hause')
NAME di_unifi_presence_reto
NR 1504
NTFY_ORDER 50-di_unifi_presence_reto
STATE initialized
TYPE DOIF
Readings:
2015-08-27 09:49:40 state initialized
Condition:
0 ReadingSecDoIf('UniFi_Controller','Reto_last_seen') > 180
Devices:
0 UniFi_Controller
all UniFi_Controller
Do:
0 set Reto abwesend,set pushmsg msg 'fhem' 'Reto hat das Haus verlassen'
1 set Reto anwesend,set pushmsg msg 'fhem' 'Reto ist nun zu Hause'
Helper:
last_timer 0
sleeptimer -1
Itimer:
Readings:
0 UniFi_Controller:Reto_last_seen
all UniFi_Controller:Reto_last_seen
State:
Timerfunc:
Attributes:
weiss jemand Rat???
@Mumpitz:
Bitte das richtige doif verwenden, nicht das von Damian gepostete, sondern das von mir: http://forum.fhem.de/index.php/topic,40287.msg325446.html#msg325446
@eppi, das seit gestern neue Attribute 'devAlias' kennst du bestimmt oder?
Du meinst den Wert welcher unter dem Reading <ID>_hostname zu sehen ist ?
Wenn du ein "get unifi clientData <ID>" machst, taucht dein gewünschter Wert in der Liste auf?
Gruß
Claudiu
@eppi:
Hab den Aliaswert gefunden, und werde Ihn fall vorhanden als automatischen 'devAlias' verwenden.
Werde denke ich das Standardverhalten ändern,
d.h. Die momentanen Readings '<ID>_reading' werden dann in dieser Reihenfolge (entsprechen welcher Wert zuerst vorhanden ist) gesetzt: <devAlias-Attribute>_reading, <controller-Alias>_reading, <hostname>_reading, <ID>_reading.
Oder besteht dein Bedarf wirklich den Controller-Alias als Reading abzufragen?
Gruß
Claudiu
Zitat von: rapster am 27 August 2015, 19:59:16
Werde denke ich das Standardverhalten ändern,
d.h. Die momentanen Readings '<ID>_reading' werden dann in dieser Reihenfolge (entsprechen welcher Wert zuerst vorhanden ist) gesetzt: <devAlias-Attribute>_reading, <controller-Alias>_reading, <hostname>_reading, <ID>_reading.
Hallo Rapster
Das ist super und genau das, was ich brauche!
Danke vielmals! Viele Grüsse Dani
@Rapster
Perfekt, läuft 1A!
Merci
Zitat von: eppi am 27 August 2015, 20:22:05
Zitat von: rapster am Heute um 19:59:16
Werde denke ich das Standardverhalten ändern,
d.h. Die momentanen Readings '<ID>_reading' werden dann in dieser Reihenfolge (entsprechen welcher Wert zuerst vorhanden ist) gesetzt: <devAlias-Attribute>_reading, <controller-Alias>_reading, <hostname>_reading, <ID>_reading.
Hallo Rapster
Das ist super und genau das, was ich brauche!
Danke vielmals! Viele Grüsse Dani
Hab ich eingecheckt, entweder heute im SVN, oder Morgen früh über das FHEM-Update.
Die Readings-Namen werden jetzt per default in folgender Reihenfolge erstellt (jeweils falls vorhanden und valide (folgende Zeichen sind ohne Leerzeichen erlaubt:[alphanumerisch - _ .]):
1. Attribute 'devAlias'
2. Controller-Alias
3. Hostname
4. user_id
Das "get clientData" Kommando kann nun ebenfalls (egal mit welchem Namen das Reading erstellt wurde) mit einem von den vier oben genannten Werten als Parameter angesprochen werden.
Das Attribute 'devAlias' kann nun nicht nur 'user_id' überschreiben, sondern kann auch genutzt werden um 'Controller-Alias' und 'hostname' zu überschreiben (es muss
nicht der Wert angegeben werden mit welchem das Reading aktuell erstellt wurde), die Validitätsprüfung wird hier ebenfalls wie oben angegeben durchgeführt.
Bitte testen und falls irgendwelche Probleme auftreten bescheid geben! (Habe es bisher nur mit Controller v3.2.7 getestet)
P.S. Habe das min update intervall auf 5 Sekunden reduziert. (Falls es jemand eilig hat ;) )
Gruß
Claudiu
Zitat von: rapster am 27 August 2015, 22:44:56
Hab ich eingecheckt, entweder heute im SVN, oder Morgen früh über das FHEM-Update.
Die Readings-Namen werden jetzt per default in folgender Reihenfolge erstellt (jeweils falls vorhanden und valide (folgende Zeichen sind ohne Leerzeichen erlaubt:[alphanumerisch - _ .]):
1. Attribute 'devAlias'
2. Controller-Alias
3. Hostname
4. user_id
Hi Rapster
Eben ein Update durchgeführt, getestet und kann dir bestätigen, dass nun die Alias in den Readings angezeigt werden, wie ich es mir vorgestellt habe :D
Ganz herzlichen Dank!
Viele Grüsse Dani
Hallo Dani,
super dass soweit schonmal alles funktioniert, dann kann es ja jetzt mit neues features weitergehen ;D
Langsam find ich mich auch bisschen zurecht in dem Java-Sourcecode des Unifi-Controllers, viele Möglichkeiten, überlege was denn alles Sinn macht in Fhem zu haben :-)
Gruß
Claudiu
Also ich erlaube mir mal zu antworten:
Ich hätte gerne folgende Möglichkeiten:
- Gastzugang Verwaltung
- deaktivieren und aktivieren der einzelnen AP's
- an/abschalten des LED Rings
- locate Funktion anwählbar machen (prima Möglichkeit optisch ein eingetretenes Ereignis zu signalisieren, z. B. Neues Mail, Waschmaschine fertig oder so)
Si, das Wären meine Wünsch gewesen :-)
Danke fürs zuhören und allfälliges Umsetzen
Gruß
Reto
-
Danke schonmal für die Tipps :-)
- locate: Das ist einfach, werde ich denke ich in der nächsten Version mit einbauen
- deaktivieren eines AP WLAN ist (theoretisch, noch nicht probiert) machbar, kommt auch bald.
- Gastzugang: Das ist generell einfach, aber...
Ich habe den Gastzugang über Unifi noch nie verwendet (Guest WLAN macht bei mir Firewall über ein VLAN am AP), wie verwendest du den üblicherweise?
Die API bietet mir zumindest Funktionen eine MAC Adresse (oder hostname falls das ein bekanntes Gerät ist) für X-Minuten als Guest zu erlauben, und wieder zu deaktivieren.
Wäre das sowas?
Hast du schon ungefähr einen Verwendungszeck dafür im Kopf? Damit ich mir was darunter vorstellen kann wie man mit Fhem den Gastzugang anschließend verwalten soll?
- an/abschalten der led: Ich bin mir nicht sicher ob das überhaupt über die API machbar ist, habe zumindest (noch) nichts dazu im Quellcode gefunden.
- Alarmverwaltung baue ich auch noch ein
Gruß
Claudiu
Moin, danke für das Super Modul, klappt auch bei mir 1A :-)
Ich würde ich noch über folgende Infos freuen:
- Anzahl der verbundenen Clients gesamt (Prod und Gast)
- Clients pro AP
- Status der AP (Verbunden, Disconencted, Bridged)
Ich laufe selber auf der aktuellen 4er, bisher keine Probleme mit dem Modul.
Zitat von: Christoph.Goth am 29 August 2015, 10:43:51
Moin, danke für das Super Modul, klappt auch bei mir 1A :-)
Ich würde ich noch über folgende Infos freuen:
- Anzahl der verbundenen Clients gesamt (Prod und Gast)
- Clients pro AP
- Status der AP (Verbunden, Disconencted, Bridged)
Ich laufe selber auf der aktuellen 4er, bisher keine Probleme mit dem Modul.
Freut mich dass es bei dir auch funktioniert, deine genannten Punkte sind denke ich im nächsten Feature-Release mit drin ;)
____
Bzgl. der Funktion "
deaktivieren eines AP WLAN" müsste mal jemand der einen 5Ghz AccessPoint hat, (
nach einem Update Morgen früh auf die aktuelle Version, oder der momentanen SVN-Version) folgenden Befehl in die Fhem-Kommandozeile eingeben:
{ use Data::Dumper;; Dumper($defs{MeinUnifiFhemDevice}) }
und mir die Ausgabe zukommen lassen (das Controller-Kennwort bitte zuvor aus der Ausgabe löschen).
Am liebsten auch jeweils einmal mit einem 3.x und einmal mit einem 4.x Controller.
Da ich die WLAN's jeweils getrennt im 2.4 und 5 Ghz Band deaktivieren muss, und selber nur 2G AP's habe.
MeinUnifiFhemDevice in dem Befehl zuvor durch den Fhem device-namen eurer definition ersetzen.
Danke!
Gruß
Claudiu
Ich hätte da einen Wunsch:
Wäre es irgendwie möglich, auf die Readings EInfluss zu nehmen? Ich bekomme da ja jedes Gerät angezeigt, ich brauche aber nur die beiden iPhones! Der Rest interessiert mich nicht! Jedoch "müllen" mir die Readings Fhem zu, damit meine ich der Prozessor wird belastet, was unnötig ist!
Ist das irgendwie denkbar?
Klar, einfach Attribut "event-on-change-reading" oder "event-on-update-reading" konfigurieren.
Nicht Readings belasten fhem, sondern Events.
Gruß
Claudiu
Hallo zusammen,
das neue Modul scheint genau das richtige für meine Zwecke zu sein. Anber ich bin vermutlich zu deppert, es (auch nach Umzug meines Conrollers 4.6.6 von Windows auf einen gesonderten Raspberry mit Wheezy) richtig einzubinden.
State lautet immer "disconnected"
fhem.cfg:
define UnifiHome Unifi 192.168.2.66 8443 account blablabla
attr UnifiHome disable 0
attr UnifiHome verbose 5
LOG:
2015.08.31 09:12:02 5: UnifiHome: Defined with url:https://192.168.2.66:8443/api/s/default/, interval:30, version:4
2015.08.31 09:12:02 5: UnifiHome (Unifi_Notify) - DEFINED|MODIFIED|INITIALIZED|REREADCFG - Remove all Timers & Call DoUpdate...
2015.08.31 09:12:02 5: UnifiHome (Unifi_DoUpdate) - executed.
2015.08.31 09:12:02 5: UnifiHome (Unifi_Login_Send) - executed.
Der Aufruf von https://192.168.2.66:8443/manage/s/default/dashboard gelingt (nach Abnicken des Zertifikathinweises)
Sollte der Status nicht auf einen anderen Wert als disconnected wechseln ?
Wäre Euch für einen Hinweis sehr dankbar.
Mein Lob an alle, die dieses tolle FHEM-Meisterwerk geschaffen haben !!!!
Liebe Grüße
Manfred
Hallo Manfred,
nach dieser Logmeldung
Zitat von: manfzimm am 31 August 2015, 09:31:52
2015.08.31 09:12:02 5: UnifiHome (Unifi_Login_Send) - executed.
sollte spätestens nach 5 Sekunden eine weitere Logmeldung erscheinen. Kommt da noch was bei dir?
Gruß
Claudiu
Hallo Claudiu,
vielen Dank für Deine Rückmeldung.
Nee, leider erscheinen im Log keine weiteren Meldungen. (Zwei Minuten später erfolgen Meldungen zu anderen Geräten....)
Ich bin ziemlich ratlos....
Liebe Grüße
Manfred
Das ist seltsam, der Login Versuch kehrt bei dir nie mit einer Rückmeldung zurück... (Ansonsten würde ein weiterer Logeintrag mit weiteren Infos generieert werden.)
Dein restliches Fhem ist wahrscheinlich auch aktuell oder?
Kannst du mal bitte "attr global verbose 5" setzen, und die Logs posten (als Anhang oder in <code> Tags)? (hier wird jetzt von allen Geräten/Modulen deutlich mehr geloggt, insbesondere vom HttpUtils-Modul welches Unifi verwendet.)
Und auch mal bitte ein "list UnifiHome" machen, dein Passwort aus der Ausgabe entfernen, und ebenfalls mal hier posten (als Anhang oder in <code> Tags).
Gruß
Claudiu
Schon mal 1000-Dank für die Unterstützung !!!
Jawöhler, FHEM ist vollständig aktualisiert.
{ use Data::Dumper;; Dumper($defs{UnifiHome}) } liefert:
$VAR1 = {
'DEF' => '192.168.2.66 8443 xxx 111',
'NAME' => 'UnifiHome',
'NOTIFYDEV' => 'global',
'NR' => 454,
'NTFY_ORDER' => '50-UnifiHome',
'READINGS' => {
'state' => {
'TIME' => '2015-08-31 15:01:07',
'VAL' => 'disconnected'
}
},
'STATE' => 'disconnected',
'TYPE' => 'Unifi',
'clients' => {},
'httpParams' => {
'hash' => $VAR1,
'ignoreredirects' => 1,
'loginData' => '{"username":"xxx", "password":"111"}',
'loginUrl' => 'https://192.168.2.66:8443/api/login',
'loglevel' => 5,
'method' => 'POST',
'noshutdown' => 0,
'sslargs' => {
'SSL_verify_mode' => 'SSL_VERIFY_NONE'
},
'timeout' => 4
},
'unifi' => {
'CONNECTED' => 'disconnected',
'interval' => 30,
'url' => 'https://192.168.2.66:8443/api/s/default/',
'version' => 4
},
'updateDispatch' => {}
};
list UnifiHome liefert:
Internals:
DEF 192.168.2.66 8443 xxx 111
NAME UnifiHome
NOTIFYDEV global
NR 454
NTFY_ORDER 50-UnifiHome
STATE disconnected
TYPE Unifi
Readings:
2015-08-31 15:01:07 state disconnected
Clients:
Httpparams:
ignoreredirects 1
loginData {"username":"xxx", "password":"111"}
loginUrl https://192.168.2.66:8443/api/login
loglevel 5
method POST
noshutdown 0
timeout 4
Hash:
Sslargs:
SSL_verify_mode SSL_VERIFY_NONE
Unifi:
CONNECTED disconnected
interval 30
url https://192.168.2.66:8443/api/s/default/
version 4
Updatedispatch:
Attributes:
disable 0
verbose 5
LOG mit Vervose 5:
2015.08.31 15:26:14 5: Notify loop for global ATTR global verbose 5
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60013 GET /fhem?detail=global
2015.08.31 15:26:15 4: 1906:FHEMWEB:192.168.2.119:60013: /fhem?detail=global / RL:3536 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2015.08.31 15:26:15 5: CUL/RAW: /T0A57002200EB
2015.08.31 15:26:15 4: CUL_Parse: COC T0A57002200EB -84.5
2015.08.31 15:26:15 5: COC dispatch 810c04xx0909a0010a5700002200
2015.08.31 15:26:15 4: FHT FHT_EG_WoZi actuator: 0%
2015.08.31 15:26:15 5: Triggering FHT_EG_WoZi (1 changes)
2015.08.31 15:26:15 5: Notify loop for FHT_EG_WoZi actuator: 0%
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60013 GET /fhem/pgm2/style.css
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60010 GET /fhem/pgm2/jquery-ui.min.css
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60012 GET /fhem/pgm2/jquery.min.js
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60011 GET /fhem/pgm2/jquery-ui.min.js
2015.08.31 15:26:15 4: Connection accepted from FHEMWEB:192.168.2.119:60014
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60010 GET /fhem/pgm2/fhemweb_fbcalllist.js
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60012 GET /fhem/pgm2/fhemweb_knob.js
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60011 GET /fhem/pgm2/fhemweb_readingsGroup.js
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60014 GET /fhem/pgm2/fhemweb.js
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60013 GET /fhem/pgm2/fhemweb_colorpicker.js
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60010 GET /fhem/pgm2/fhemweb_readingsHistory.js
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60012 GET /fhem/pgm2/fhemweb_sortable.js
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60011 GET /fhem/pgm2/fhemweb_uzsu.js
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60014 GET /fhem/pgm2/RSS.js
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60010 GET /fhem/js/webviewcontrol.js
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60012 GET /fhem/pgm2/defaultCommon.css
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60013 GET /fhem/pgm2/cordova-2.3.0.js
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60011 GET /fhem/pgm2/dashboard_style.css
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60013 GET /fhem/images/default/icoLicht.png
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60010 GET /fhem/images/default/fhemicon.png
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60014 GET /fhem/images/default/icoEverything.png
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60013 GET /fhem?cmd={AttrVal(%22global%22,%22room%22,%22%22)}&XHR=1
2015.08.31 15:26:15 5: Cmd: >{AttrVal("global","room","")}<
2015.08.31 15:26:15 4: 1906:FHEMWEB:192.168.2.119:60013: /fhem?cmd={AttrVal(%22global%22,%22room%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.08.31 15:26:15 4: HTTP FHEMWEB:192.168.2.119:60013 GET /fhem?XHR=1&inform=type=status;filter=global;since=1441027574;fmt=JSON×tamp=1441027578310
2015.08.31 15:26:17 4: BlockingCall created child (3352), uses telnetForBlockingFn to connect back
2015.08.31 15:26:17 5: PRESENCE_DoLocalPingScan: PresDreamFleck|192.168.2.44|0|4
2015.08.31 15:26:20 5: PRESENCE (PresDreamFleck) - ping command returned with output:
PING 192.168.2.44 (192.168.2.44) 56(84) bytes of data.
64 bytes from 192.168.2.44: icmp_req=1 ttl=64 time=0.820 ms
64 bytes from 192.168.2.44: icmp_req=2 ttl=64 time=0.741 ms
64 bytes from 192.168.2.44: icmp_req=3 ttl=64 time=0.781 ms
64 bytes from 192.168.2.44: icmp_req=4 ttl=64 time=0.791 ms
--- 192.168.2.44 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 0.741/0.783/0.820/0.034 ms
2015.08.31 15:26:20 4: Connection accepted from telnet:127.0.0.1:37562
2015.08.31 15:26:20 5: Cmd: >{PRESENCE_ProcessLocalScan('PresDreamFleck|0|present')}<
2015.08.31 15:26:20 5: PRESENCE_ProcessLocalScan: PresDreamFleck|0|present
2015.08.31 15:26:20 5: Triggering PresDreamFleck (1 changes)
2015.08.31 15:26:20 5: Notify loop for PresDreamFleck present
2015.08.31 15:26:20 5: HMLAN_Send: HMLAN1 I:K
2015.08.31 15:26:20 5: HMLAN/RAW: /HHM-LAN-IF,03C4,LEQ0101658,26EE58,123ABC,001882D2,0020,01
2015.08.31 15:26:20 5: HMLAN_Parse: HMLAN1 V:03C4 sNo:LEQ0101658 d:26EE58 O:123ABC t:001882D2 IDcnt:0020 L:1 %
2015.08.31 15:26:20 5: Triggering HMLAN1 (1 changes)
2015.08.31 15:26:20 5: Notify loop for HMLAN1 loadLvl: low
2015.08.31 15:26:29 5: HMLAN/RAW: /E2D4592,0000,0018A666,FF,FFA2,37845E2D4592000000800CB700008E002A0902FE
2015.08.31 15:26:29 5: HMLAN_Parse: HMLAN1 R:E2D4592 stat:0000 t:0018A666 d:FF r:FFA2 m:37 845E 2D4592 000000 800CB700008E002A0902FE
2015.08.31 15:26:29 5: HMLAN1 dispatch A1437845E2D4592000000800CB700008E002A0902FE::-94:HMLAN1
2015.08.31 15:26:29 5: Triggering STAP_PM_Waschmaschine_Pwr (9 changes)
2015.08.31 15:26:29 5: Notify loop for STAP_PM_Waschmaschine_Pwr boot: off
2015.08.31 15:26:29 5: Triggering STAP_PM_Waschmaschine_SenF (1 changes)
2015.08.31 15:26:29 5: Notify loop for STAP_PM_Waschmaschine_SenF 49.98
2015.08.31 15:26:30 5: Triggering STAP_PM_Waschmaschine_SenI (1 changes)
2015.08.31 15:26:30 5: Notify loop for STAP_PM_Waschmaschine_SenI 42
2015.08.31 15:26:30 5: Triggering STAP_PM_Waschmaschine_SenPwr (1 changes)
2015.08.31 15:26:30 5: Notify loop for STAP_PM_Waschmaschine_SenPwr 1.42
2015.08.31 15:26:30 5: Triggering STAP_PM_Waschmaschine_SenU (1 changes)
2015.08.31 15:26:30 5: Notify loop for STAP_PM_Waschmaschine_SenU 230.6
2015.08.31 15:26:30 4: Connection closed for FHEMWEB:192.168.2.119:60013: EOF
2015.08.31 15:26:30 4: HTTP FHEMWEB:192.168.2.119:60012 GET /fhem?detail=UnifiHome
2015.08.31 15:26:30 4: 1906:FHEMWEB:192.168.2.119:60012: /fhem?detail=UnifiHome / RL:2704 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60012 GET /fhem/pgm2/style.css
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60010 GET /fhem/pgm2/jquery.min.js
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60012 GET /fhem/pgm2/fhemweb_colorpicker.js
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60011 GET /fhem/pgm2/jquery-ui.min.css
2015.08.31 15:26:31 4: Connection accepted from FHEMWEB:192.168.2.119:60021
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60014 GET /fhem/pgm2/jquery-ui.min.js
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60010 GET /fhem/pgm2/fhemweb_fbcalllist.js
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60012 GET /fhem/pgm2/fhemweb_knob.js
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60011 GET /fhem/pgm2/fhemweb_readingsGroup.js
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60014 GET /fhem/pgm2/fhemweb_readingsHistory.js
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60021 GET /fhem/pgm2/fhemweb.js
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60010 GET /fhem/pgm2/fhemweb_sortable.js
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60012 GET /fhem/pgm2/fhemweb_uzsu.js
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60011 GET /fhem/pgm2/RSS.js
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60014 GET /fhem/pgm2/cordova-2.3.0.js
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60010 GET /fhem/pgm2/defaultCommon.css
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60021 GET /fhem/js/webviewcontrol.js
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60012 GET /fhem/pgm2/dashboard_style.css
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60012 GET /fhem/images/default/icoLicht.png
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60011 GET /fhem/images/default/icoEverything.png
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60014 GET /fhem/images/default/fhemicon.png
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60012 GET /fhem?cmd={ReadingsVal(%22UnifiHome%22,%22clear%22,%22%22)}&XHR=1
2015.08.31 15:26:31 5: Cmd: >{ReadingsVal("UnifiHome","clear","")}<
2015.08.31 15:26:31 4: 1906:FHEMWEB:192.168.2.119:60012: /fhem?cmd={ReadingsVal(%22UnifiHome%22,%22clear%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60010 GET /fhem?cmd={AttrVal(%22UnifiHome%22,%22room%22,%22%22)}&XHR=1
2015.08.31 15:26:31 5: Cmd: >{AttrVal("UnifiHome","room","")}<
2015.08.31 15:26:31 4: 1906:FHEMWEB:192.168.2.119:60010: /fhem?cmd={AttrVal(%22UnifiHome%22,%22room%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.08.31 15:26:31 4: HTTP FHEMWEB:192.168.2.119:60021 GET /fhem?XHR=1&inform=type=status;filter=UnifiHome;since=1441027589;fmt=JSON×tamp=1441027593909
2015.08.31 15:26:35 4: Connection closed for FHEMWEB:192.168.2.119:60021: EOF
2015.08.31 15:26:35 4: HTTP FHEMWEB:192.168.2.119:60012 GET /fhem?detail=UnifiHome&detail=UnifiHome&val.modifyUnifiHome=192.168.2.66+8443+yyy+111&cmd.modifyUnifiHome=modify+UnifiHome
2015.08.31 15:26:35 5: Cmd: >modify UnifiHome 192.168.2.66 8443 yyy 111<
2015.08.31 15:26:35 5: UnifiHome: Defined with url:https://192.168.2.66:8443/api/s/default/, interval:30, version:4
2015.08.31 15:26:35 5: Triggering global (1 changes)
2015.08.31 15:26:35 5: Notify loop for global MODIFIED UnifiHome
2015.08.31 15:26:36 5: UnifiHome (Unifi_Notify) - DEFINED|MODIFIED|INITIALIZED|REREADCFG - Remove all Timers & Call DoUpdate...
2015.08.31 15:26:36 5: Triggering UnifiHome (1 changes)
2015.08.31 15:26:36 5: Notify loop for UnifiHome initialized
2015.08.31 15:26:36 5: UnifiHome (Unifi_DoUpdate) - executed.
2015.08.31 15:26:36 5: Triggering UnifiHome (1 changes)
2015.08.31 15:26:36 5: Notify loop for UnifiHome disconnected
2015.08.31 15:26:36 5: UnifiHome (Unifi_Login_Send) - executed.
2015.08.31 15:26:36 5: HttpUtils url=https://192.168.2.66:8443/api/login
2015.08.31 15:26:36 4: HTTP FHEMWEB:192.168.2.119:60012 GET /fhem?detail=UnifiHome
2015.08.31 15:26:36 4: 1906:FHEMWEB:192.168.2.119:60012: /fhem?detail=UnifiHome / RL:2716 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2015.08.31 15:26:36 4: HTTP FHEMWEB:192.168.2.119:60012 GET /fhem/pgm2/style.css
2015.08.31 15:26:36 4: HTTP FHEMWEB:192.168.2.119:60010 GET /fhem/pgm2/jquery-ui.min.css
2015.08.31 15:26:36 4: HTTP FHEMWEB:192.168.2.119:60011 GET /fhem/pgm2/jquery.min.js
2015.08.31 15:26:36 4: Connection accepted from FHEMWEB:192.168.2.119:60022
2015.08.31 15:26:36 4: HTTP FHEMWEB:192.168.2.119:60014 GET /fhem/pgm2/jquery-ui.min.js
2015.08.31 15:26:36 4: HTTP FHEMWEB:192.168.2.119:60010 GET /fhem/pgm2/fhemweb_fbcalllist.js
2015.08.31 15:26:36 4: HTTP FHEMWEB:192.168.2.119:60012 GET /fhem/pgm2/fhemweb_colorpicker.js
2015.08.31 15:26:36 4: HTTP FHEMWEB:192.168.2.119:60011 GET /fhem/pgm2/fhemweb_knob.js
2015.08.31 15:26:36 4: HTTP FHEMWEB:192.168.2.119:60022 GET /fhem/pgm2/fhemweb.js
2015.08.31 15:26:36 4: HTTP FHEMWEB:192.168.2.119:60010 GET /fhem/pgm2/fhemweb_readingsHistory.js
2015.08.31 15:26:36 4: HTTP FHEMWEB:192.168.2.119:60012 GET /fhem/pgm2/fhemweb_sortable.js
2015.08.31 15:26:36 4: HTTP FHEMWEB:192.168.2.119:60011 GET /fhem/pgm2/fhemweb_uzsu.js
2015.08.31 15:26:36 4: HTTP FHEMWEB:192.168.2.119:60022 GET /fhem/pgm2/RSS.js
2015.08.31 15:26:36 4: HTTP FHEMWEB:192.168.2.119:60014 GET /fhem/pgm2/fhemweb_readingsGroup.js
2015.08.31 15:26:36 4: HTTP FHEMWEB:192.168.2.119:60010 GET /fhem/pgm2/cordova-2.3.0.js
2015.08.31 15:26:36 4: HTTP FHEMWEB:192.168.2.119:60012 GET /fhem/js/webviewcontrol.js
2015.08.31 15:26:36 4: HTTP FHEMWEB:192.168.2.119:60011 GET /fhem/pgm2/defaultCommon.css
2015.08.31 15:26:36 4: HTTP FHEMWEB:192.168.2.119:60012 GET /fhem/pgm2/dashboard_style.css
2015.08.31 15:26:36 4: HTTP FHEMWEB:192.168.2.119:60012 GET /fhem/images/default/icoLicht.png
2015.08.31 15:26:36 4: HTTP FHEMWEB:192.168.2.119:60010 GET /fhem/images/default/icoEverything.png
2015.08.31 15:26:36 4: HTTP FHEMWEB:192.168.2.119:60022 GET /fhem/images/default/fhemicon.png
2015.08.31 15:26:36 4: HTTP FHEMWEB:192.168.2.119:60012 GET /fhem?cmd={ReadingsVal(%22UnifiHome%22,%22clear%22,%22%22)}&XHR=1
Hinweis: 192.168.2.119 ist mein Arbeitsplatzrechner (MacBook)
Super Infos!, würdest du bitte noch kurz deinen Beitrag bearbeiten und die Ausgaben(logs usw.) in Code-Blöcke einpacken? (das ist das #-Icon über dem Textfeld).
Es sieht so aus als ob deine HttpUtils.pm nicht aktuell ist, dadurch kann ich zumindest dieses Verhalten nachstellen.
Schau mal bitte in die Datei /fhem/FHEM/HttpUtils.pm was da in der zweiten Zeile steht, es sollte sein:
# $Id: HttpUtils.pm 9116 2015-08-23 11:30:20Z rudolfkoenig $
Falls dies nicht so ist mach mal ein "update force", falls "update" alleine nichts tun will.
Falls die HttpUtils.pm aktuell ist,
ersetze mal bitte Zeile 52 in der /fhem/FHEM/74_Unifi.pm durch diese:
sslargs => { SSL_version => 'SSLv23', SSL_verify_mode => 'SSL_VERIFY_NONE' },
und probiere es nach einem Fhem-Neustart erneut.
Falls es dann immer noch nicht funktionieren sollte,
- prüfe mal was du erhälst wenn du per Browser auf die Seite https://192.168.2.66:8443/api/login gehst.
- und Prüfe mal mit diesem Linux-Shell Befehl welche IO::Socket::SSL version du auf deiner Fhem-Maschine verwendest: perl -M'IO::Socket::SSL' -e 'print "$IO::Socket::SSL::VERSION\n"'
Gruß
Claudiu
Habe eben eine neue Version eingecheckt, ist dann Morgen im Update.
- Locate an/abschaltbar pro Accesspoint oder alle auf einmal. (Leider habe ich bisher keine Möglichkeit gefunden anzuzeigen ob locate i.M. aktiviert ist)
- Alarmanzeige & Archivierung noch nicht archivierter Alarme.
- Neustarten eines oder aller Accesspoints.
- Disconnecten eines oder aller Clients. (z.B. nutzbar um bei einem schlechten SNR-Wert ein roaming zu erzwingen)
- Anzeigen der letzten Events in der konfigurierbaren 'eventPeriod'
- Eine Menge neuer Readings:
- Jeder Client hat nun 6 readings für connection-state, SNR, uptime, last_seen-time, verbundener-AP und hostname.
- Jeder AP hat nun 3 readings für state (kann i.M sein: 'ok' oder 'error'), essid's und connected-clients count.
@Christoph.Goth: Ich kenne i.M. nur den state 1 (ok) und 0 (error), kannst du mir mal Daten mithilfe des fhem-Befehls {use Data::Dumper;;Dumper($defs{MeinUnifiFhemDevice})} zukommen lassen wenn sich ein AP im 'Bridged' Modus befindet? - Der unifi-controller hat nun 6 readings für event-count in konfigurierbarer 'timePeriod', unarchived-alert count, accesspoint count, overall wlan-state (kann i.M. sein: 'ok', 'warning' (wenn z.B. 1 von 2 AP down ist), oder etwas anderes evtl. ;) ), connected user count and connected guest count.
- Zwei neue Attribute:
- attr eventPeriod: Um die Zeit der abzufragenden Events anzugeben. (default: 24h)
- attr httpLoglevel: Damit man bei Problemen wie von @manfzimm nicht mehr global verbose hochsetzen muss, um die Logmeldungen des HttpUtils Moduls zu erhalten.
Und evtl. noch ein paar Kleinigkeiten die ich jetzt hier vergessen habe :)
@manfzimm: Die beschriebene Änderung bzgl. sslargs habe ich ebenfalls in das Modul eingebaut, bitte probieren ob es nach einem Update dadurch bei dir funktioniert.
Habe das ganze allerdings erst mit Controller v4.x getestet, hoffe bei v3.x gibt es keine Probleme...Gruß
Claudiu
@rapster:
Okay, ich schaue heute Abend mal was er anzeigt/reportet wenn der AP im Bridge Modus ist.
Habe mir mal ein paar ReadingGroups gebaut, evtl kann es der eine oder andere auch gebrauchen:
(http://bilder.2-cpu.de/fhem/wlan_unifi.PNG)
define Wifi_Clients_Status readingsGroup <Gerätename>,<Status>\
unifi_controller:Sandra_P8\
unifi_controller:Chris_LG_G4\
unifi_controller:Chris_HTC_HD2\
unifi_controller:Chris_Samsung_Note_10.1
attr Wifi_Clients_Status alias Wifi Clients Status
attr Wifi_Clients_Status group Wifi
attr Wifi_Clients_Status mapping { 'Sandra_P8' => 'Sandra P8', 'Chris_LG_G4' => 'Chris LG G4', 'Chris_HTC_HD2' => 'Chris HTC HD2', 'Chris_Samsung_Note_10.1' => 'Chris Samsung Note 10.1' }
attr Wifi_Clients_Status nameStyle style="color:yellow;;font-weight:bold"
attr Wifi_Clients_Status notime 1
attr Wifi_Clients_Status room Z_Groups
attr Wifi_Clients_Status valueStyle { if($VALUE eq "disconnected"){ 'style="color:red;;font-weight:bold"' }elsif($VALUE eq "connected"){ 'style="color:green;;font-weight:bold"' }}
define Wifi_APs readingsGroup <Gerätename>,<Status>\
unifi_controller:#AP.*
attr Wifi_APs alias Wifi APs
attr Wifi_APs group Wifi
attr Wifi_APs mapping { '#AP_AP Keller Vorne_clients' => 'AP Keller Vorne: Clients', '#AP_AP Wohnzimmer Hinten_clients' => 'AP Wohnzimmer Hinten: Clients', '#AP_AP Keller Vorne_essid' => 'AP Keller Vorne: SSIDs', '#AP_AP Wohnzimmer Hinten_essid' => 'AP Wohnzimmer Hinten: SSIDs', '#AP_AP Keller Vorne_state' => 'AP Keller Vorne: Status', '#AP_AP Wohnzimmer Hinten_state' => 'AP Wohnzimmer Hinten: Status' }
attr Wifi_APs nameStyle style="color:yellow;;font-weight:bold"
attr Wifi_APs notime 1
attr Wifi_APs room Z_Groups
attr Wifi_APs valueStyle { if($VALUE eq "disconnected"){ 'style="color:red;;font-weight:bold"' }elsif($VALUE eq "ok"){ 'style="color:green;;font-weight:bold"' }elsif(($READING eq "#AP_AP Keller Vorne_clients" || $READING eq "#AP_AP Wohnzimmer Hinten_clients") && $VALUE < 7){ 'style="color:green;;font-weight:bold"' }elsif(($READING eq "#AP_AP Keller Vorne_clients" || $READING eq "#AP_AP Wohnzimmer Hinten_clients") && $VALUE >= 7){ 'style="color:red;;font-weight:bold"' }else{ 'style="color:grey;;font-weight:bold"' }}
define Wifi_Clients readingsGroup <Gerätename>,<Status>\
unifi_controller:#UC_wlan_state\
unifi_controller:#UC_wlan_accesspoints\
unifi_controller:#UC_wlan_users\
unifi_controller:#UC_wlan_guests
attr Wifi_Clients alias Wifi Clients
attr Wifi_Clients group Wifi
attr Wifi_Clients mapping { '#UC_wlan_state' => 'WLan Gesamtstatus', '#UC_wlan_accesspoints' => 'WLan Access Points', '#UC_wlan_users' => 'WLan Benutzer in Produktion', '#UC_wlan_guests' => 'WLan Gast Benutzer' }
attr Wifi_Clients nameStyle style="color:yellow;;font-weight:bold"
attr Wifi_Clients notime 1
attr Wifi_Clients room Z_Groups
attr Wifi_Clients valueStyle { if($READING eq "#UC_wlan_state" && $VALUE eq "error"){ 'style="color:red;;font-weight:bold"' }elsif($READING eq "#UC_wlan_state" && $VALUE eq "ok"){ 'style="color:green;;font-weight:bold"' }elsif(($READING eq "#UC_wlan_users" || $READING eq "#UC_wlan_guests") && $VALUE < 10){ 'style="color:green;;font-weight:bold"' }elsif(($READING eq "#UC_wlan_users" || $READING eq "#UC_wlan_guests") && $VALUE >= 10){ 'style="color:red;;font-weight:bold"' }else{ 'style="color:grey;;font-weight:bold"' }}
Ohne Garantie auf die sauberste Umsetzung, bin immer offen für Verbesserungsvorschläge ;)
Hallo Claudiu,
ein "update force" hatte ich zur Sicherheit einfach schon mal durchgeführt. Die HttpUtils.pm ist aktuell und zeigt genau die von Dir genannte Zeile.
Dannach habe ich die 74_Unifi.pm in Zeile 52 ersetzt. Nach reboot des beider Raspis (FHEM und Unifi) leider keine Änderung.
https://192.168.2.66:8443/api/login zeigt:
{ "data" : [ ] , "meta" : { "msg" : "api.err.Invalid" , "rc" : "error"}}
Meine IO::Socket::SSL-Version lautet 1.76
Zwischenzeitlich habe ich den Unifi-Controller (V. 4.6.6. auf dem Raspi 2) nochmals neu installiert.
Leider kein Erfolg - schnief....
Merci Merci !!!!
Manfred
Hallo Manfred,
denke das liegt an deiner IO::Socket::SSL Version, da diese schon relativ alt ist.
Mit der heutigen Version aus dem fhem-update funktioniert es warscheinlich auch nicht oder?
Ich schau mal was ich machen kann.
Gruß
Claudiu
@Manfred:
Mach mal bitte folgendes:
1. aktualisiere das Unifi-Modul (fhem) auf die aktuelle Version über das fhem-update
2. ersetze die /fhem/FHEM/HttpUtils.pm durch anhängende.
3. setze an deinem Unifi-device das Attribute "attr httpLoglevel 1"
4. starte fhem neu
Jetzt sollte im Log eine Zeile kommen die so ungefähr anfängt:
https://192.168.1.66:8443/api/login: Can't connect(2) to .......
Die Fehlermeldung wird dann hoffentlich mehr Infos liefern :-)
Gruß
Claudiu
Hallo nochmal ;-)
super Tip !!! Hier der Auszug aus dem LOG:
2015.09.01 20:21:29 5: UnifiHome: Defined with url:https://192.168.2.33:8443/api/s/default/, interval:30, version:4
2015.09.01 20:21:29 5: UnifiHome (Unifi_Notify) - executed. - Remove all Timers & Call DoUpdate...
2015.09.01 20:21:29 5: UnifiHome (Unifi_DoUpdate) - executed.
2015.09.01 20:21:29 5: UnifiHome (Unifi_Login_Send) - executed.
2015.09.01 20:21:29 1: HttpUtils url=https://192.168.2.33:8443/api/login
2015.09.01 20:21:29 1: https://192.168.2.33:8443/api/login: Can't connect(2) to https://192.168.2.33:8443: SSL Version SSLv2 not supported error:00000000:lib(0):func(0):reason(0)
Mein FHEM-Raspi meldet nach einem
apt-get update
apt-get install libio-socket-ssl-perl
libio-socket-ssl-perl ist schon die neueste Version.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 332 nicht aktualisiert.
Vermutlich die richtige Ecke - aber mein Hirn bietet zu wenig Linux-kapazitäten....
OK, dann haben wir schonmal an der richtigen Stelle gebuddelt.
Laut Dokumentation http://search.cpan.org/~sullr/IO-Socket-SSL-1.76/SSL.pm#METHODS sollte es allerdings mit deiner SSL-Version generell funktionieren.
Probier mal bitte: "attr global sslVersion SSLv23" zu setzen, obwohl der default-Wert normalerweise i.M. vom Unifi-Modul genau damit überschrieben werden "sollte".
Um SSL selber upzudaten wirst du warscheinlich deine /etc/apt/sources.list anpassen, oder apt.pinning verwenden müssen.
Gruß
Claudiu
@Rapster: Kann ich bedenkenlos ein update machen oder ändern sich dann die readings? Nutze sie bereits für PRESENCE!
Erst habe ich das hier durchgeführt:
cpanm -i IO::Socket::SSL --force
Ergebnis: Version 2.019
Mein FHEM stürtzt jetzt an dieser Stelle ab (Kein Web-Interface mehr):
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:
cpanm --uninstall IO::Socket::SSL
Auch das hier brachte keinen Erfolg:
attr global sslVersion SSLv23
Oh je....
@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:
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
Hallo Claudiu,
einfach spitze !!! Das ist es !!!
Vielen Dank
Lässt sich das vielleicht allgemeingültig einbauen ?
Liebe Grüße
Manfred
Super dass es geklappt hat, freut mich! ;D
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
Hi,
habe folgendes seltsames Verhalten festgestellt:
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.
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
Hi Rapster,
devAlias habe ich nicht mehr konfiguriert! Hier meine komplette Konfig:
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......
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.
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
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?!?
Zitat von: Michi240281 am 03 September 2015, 09:00:36
die Ausgabe poste ich heute Abend.
Ok super, bitte zwischen auftreten des Problems und posten der Ausgabe keinen Fhem-Neustart o.ä. machen.
Zitat von: Michi240281 am 03 September 2015, 09:00:36
- 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 :-)
Zitat von: Michi240281 am 03 September 2015, 09:00:36
- 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.
Zitat von: Michi240281 am 03 September 2015, 09:00:36
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
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
Zitat von: rapster am 03 September 2015, 09:31:54
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?
Zitat von: justme1968 am 03 September 2015, 14:20:12
- 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!
Zitat von: rapster am 03 September 2015, 09:31:54
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!
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.
Zitat von: justme1968 am 03 September 2015, 14:20:12
- 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.
Zitat von: justme1968 am 03 September 2015, 14:20:12
- 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)
Zitat von: justme1968 am 03 September 2015, 14:20:12
- anzeige mit welcher ssid ein client verbunden ist.
Das hatte ich auch schon überlegt, und ist ruckzuck eingebaut :-)
Zitat von: justme1968 am 03 September 2015, 14:20:12
- (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) ?
Zitat von: justme1968 am 03 September 2015, 14:20:12
- 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.
Zitat von: justme1968 am 03 September 2015, 14:20:12
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.
Zitat von: justme1968 am 03 September 2015, 14:20:12
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
@Michi:
Ja genau, der Wert ändert sich ja nichtmehr, nurnoch der Fhem-Zeitstempel.
Du könntest z.B. die Attribute so setzen, um relativ wenige Events zu haben (nur bei Readings die sich selten ändern):
attr event-on-change-reading (?!.*_uptime)(.*)
attr event-on-update-reading .*(_last_seen|_snr)
Damit löst _uptime nie ein Event aus, das ist ein Reading das ändert sich sehr oft, wird allerdings nur selten benötigt,
_last_seen und _snr lösen bei jedem update ein Event aus,
und die restlichen Readings welche sich nur selten ändern lösen nur bei Änderung ein Event aus.
Wurde Michael_iPhone_5S durch das Unfifi-Modul als 'disconnected' gekennzeichnet, oder durch dein DOIF? Hatte es evtl. zu der Zeit wirklich schlechten Empfang?
Gruß
Claudiu
ZitatZitat von: justme1968 am Heute um 14:20:12
Zitat- (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) ?
in jedem device wäre dann nur die readings die permanent diesem device zugeordnet sind.
also z.b. im ap device die anzahl der gerade verbundenen clients, im client device der name des ap, der online status,...
ZitatBloß ein "." wird das Problem nicht lößen, da "-" in der ascii table immer noch weiter vorne liegt.
arg... natürlich. da war ich zu flüchtig. die alternativen sind alle nicht wirklich gut. wenn wie oben vorgeschlagen alle device spezifischen readings jeweils in einem eigenen device stecken wäre das problem aber auch gelöst.
das würde auch das loggen und plotten einfacher machen.
was die übertragenen daten angeht steht in clientData bei rx_.* und tx_.* ja schon was drin. wenn man das in readings bekommt wäre das ja auch ein anfang.
welche daten brauchst du von einem 5ghz ap? ich habe beide modelle in betrieb.
gruss
andre
Also separate Accesspoint definitions mit den permanenten Readings sollte kein Problem sein,
Was ich mir allerdings bei den Clients problematisch vorstelle sind die Gäste-Benutzer,
da so jeder Gast den man in sein WLAN lässt ein zusätzliches Fhem-Device erzeugt.
Oder man beschränkt das auf wlan-user (ohne Gäste) ?
EDIT: Oder beschränkt es wie bei mir auf SSID's da meine Gäste über eine eigene SSID und der Firewall abgefertigt werden?
Generell würd es alles schon übersichtlicher machen, da hast du recht, vorallem bei ü40 Devices :)
Das was unter clientData unter rx_* und tx_* zu sehen ist, sind allerdings immer nur die Statistiken seit dem letzten connect,
über die Statistik-Schnittstelle könnte man das ganze auch zeitbasiert ausgeben lassen, z.B. client_rx_today
Denke werde erstmal das clientData rx & tx über das vorgeschlagene Attribut manuell als reading hinzufügbar machen, und evtl. mal nachdem ich das mit der Statistik-Schnittstelle hinbekommen habe über ein generelles Reading nachdenken :)
Gruß
Claudiu
EDIT:
Ganz vergessen, bzgl. der SSID-Ab/Anschaltung, am liebsten mal alle Daten die
{ use Data::Dumper;; Dumper($defs{MeinUnifiDevice}) }
so ausspuckt (abgesehen von deinem Passwort ;) ), insbesondere geht es mir allerdings um den 'accespoints' Hash. (Mist da fällt mir grad auf, da fehlt ein 's' ;) )
ob ein device für einen client erzeugt wird könnte man von der rssi und den white und black listen abhängig machen. dann wäre es glaube ich so flexibel das man es auf die gewünschten clients beschränken kann.
wenn du daten brauchst sag bescheid. wie gesagt: ich habe beide so typen im einsatz.
gruss
andre
Hab die benötigten Daten oben nochmal als Edit angehangen gehabt, hatte ich vor dem Abschicken ganz vergessen ;)
Ja das klingt nach einem Plan,
Würde das evtl. über ein eigenes Attribut "separateDevices:0,1" machen wodurch im ersten Schritt alle AP's als eigenes Fhem-devices eingerichtet werden und anschließend noch jedes ge'withe'listete device (device-ssid) ein eigenes Fhem-device wird.
Oder das direkt als default machen?
Oder hast du zur konkreten Umsetzung einen besseren Vorschlag?
Gruß
Claudiu
Oh das wurde wohl abgeschnitten! :(
Jetzt gerade stehen sogar beide iPhones auf "disconnected" obwohl das nicht stimmt:
NAME Unifi_Controller
NOTIFYDEV global
NR 1028
NTFY_ORDER 50-Unifi_Controller
STATE connected
TYPE Unifi
Readings:
2015-09-03 18:17:03 #AP_EG_clients 6
2015-09-03 18:17:03 #AP_EG_essid Michael_Ubiquiti
2015-09-03 18:17:03 #AP_EG_state ok
2015-09-03 18:17:03 #AP_OG_clients 1
2015-09-03 18:17:03 #AP_OG_essid Michael_Ubiquiti
2015-09-03 18:17:03 #AP_OG_state ok
2015-09-03 18:17:03 #UC_events 78 (last 24h)
2015-09-03 18:17:03 #UC_unarchived_alerts 0
2015-09-03 18:17:03 FireTV_Stick connected
2015-09-03 18:17:03 FireTV_Stick_accesspoint OG
2015-09-03 18:17:03 FireTV_Stick_hostname 192.168.188.248
2015-09-03 18:17:03 FireTV_Stick_last_seen 2015-09-03 18:16:57
2015-09-03 18:17:03 FireTV_Stick_snr 29
2015-09-03 18:17:03 FireTV_Stick_uptime 537832
2015-09-03 18:17:03 HarmonyHub connected
2015-09-03 18:17:03 HarmonyHub_accesspoint EG
2015-09-03 18:17:03 HarmonyHub_hostname HarmonyHub
2015-09-03 18:17:03 HarmonyHub_last_seen 2015-09-03 18:17:02
2015-09-03 18:17:03 HarmonyHub_snr 59
2015-09-03 18:17:03 HarmonyHub_uptime 776061
2015-09-03 18:17:03 Marina_iPhone_5S disconnected
2015-09-03 18:17:03 Marina_iPhone_5S_accesspoint EG
2015-09-03 18:17:03 Marina_iPhone_5S_hostname 192.168.188.179
2015-09-03 18:17:03 Marina_iPhone_5S_last_seen 2015-09-03 18:17:02
2015-09-03 18:17:03 Marina_iPhone_5S_snr 31
2015-09-03 18:17:03 Marina_iPhone_5S_uptime 1337
2015-09-03 18:17:03 Michael_iPhone_5S disconnected
2015-09-03 18:17:03 Michael_iPhone_5S_accesspoint EG
2015-09-03 18:17:03 Michael_iPhone_5S_hostname MichasiPhone5S
2015-09-03 18:17:03 Michael_iPhone_5S_last_seen 2015-09-03 18:17:02
2015-09-03 18:17:03 Michael_iPhone_5S_snr 42
2015-09-03 18:17:03 Michael_iPhone_5S_uptime 2178
2015-09-03 18:17:03 Wandtablet connected
2015-09-03 18:17:03 Wandtablet_accesspoint EG
2015-09-03 18:17:03 Wandtablet_hostname 192.168.188.250
2015-09-03 18:17:03 Wandtablet_last_seen 2015-09-03 18:17:02
2015-09-03 18:17:03 Wandtablet_snr 37
2015-09-03 18:17:03 Wandtablet_uptime 775294
2015-09-03 18:17:03 XPS disconnected
2015-09-03 18:17:03 XPS_accesspoint EG
2015-09-03 18:17:03 XPS_hostname 192.168.188.177
2015-09-03 18:17:03 XPS_last_seen 2015-09-03 18:17:02
2015-09-03 18:17:03 XPS_snr 48
2015-09-03 18:17:03 XPS_uptime 2026
2015-09-03 18:17:03 iPad connected
2015-09-03 18:17:03 iPad_accesspoint EG
2015-09-03 18:17:03 iPad_hostname 192.168.188.31
2015-09-03 18:17:03 iPad_last_seen 2015-09-03 18:17:02
2015-09-03 18:17:03 iPad_snr 34
2015-09-03 18:17:03 iPad_uptime 514826
2015-09-03 18:11:07 state connected
Das Notebook (XPS) steht auch auf disconnected obwohl ich damit gerade schreibe....
Ich hätte da noch einen Wunsch, aber keine Ahnung ob sowas umsetzbar ist:
Kannst du das Intervall im DEF als Attribut einbauen? Dann könnte man das Intervall zB in einem DOIF ändern.
Mein Anwendungsfall:
Bei der ABwesenheitserkennung würde mir ein Intervall von 60s locker reichen. Bei der ANwesenheitserkennung würde ich gerne so schnell wie möglich reagieren können.
ich habe dir mal nur den accesspoints teil angehängt. wenn ich versuche alles auszugeben bricht fhem die ausgabe nach etwa 250k ab :). vermutlich läuft irgendwo ein buffer voll. wenn du den rest auch noch brauchst kann ich auch direkt per perl in ein file schreiben.
der ap Besprechungsraum ist ein 2.4ghz modell, die beiden anderen 2.4ghz und 5ghz dual band.
dabei fällt mir auf das in den readings der ap die rssids z.t. doppelt auftauchen. vermutlich je ein mal für 2.4ghz und 5ghz. hier wäre die frage ob man die frequenz noch in klammern hinter den namen hängt.
für das anlegen der sub devices habe ich im z.b. im harmony modul ein set autocreate kommando. da kann man dann für ein bestimmtes gerät oder für alle das fhem device anlegen lassen.
ich glaube das passt hier aber nicht so gut. ich würde erst mal einen schalter vorsehen in dem man die rssid(s) angeben kann für die automatisch sub devices angelegt werden sollen. wenn nichts gesetzt ist bleibt alles wie ist. wenn hier etwas gesetzt ist und der client zu dieser rssid verbindung hat wird das sub device angelegt. wenn er danach in ein netz wechselt dessen rssid nicht in der liste steht würde ich es trotzdem weiter updaten. und dann noch mal über die while und black list gehen um zu schauen ob ein device ignoriert werden soll. d.h. vor allem anderen schauen ob es das sub device gibt und wenn es da ist verwenden. dann kann man zur not auch ein sub device von hand anlegen das aus der reihe tanzt. hmmm war das verständlich?
gruss
andre
@Andre:
super danke, accesspoints reicht mir erstmal :)
Ja da hast du recht, der controller unterscheided beim wlan so ziemlich bei allem zwischen 2.4 und 5ghz, deswegen wollte ich die commandos zum deaktivieren auch erst einbauen nachdem ich infos für 5ghz habe, da die ssids auch jeweils separat de/aktiviert werden müssen.
Jetzt hab ich auch die Infos um die SSID anzeige zu verbessern, damit's etwas übersichtlicher wird wenn man beide Frequenzen bedient :)
Danke für die Info, schau ich mir an, evtl. kann ich ja was hilfreiches abkupfern, und jup war verständlich, so in der Art hab ich mir das vorhin auch überlegt gehabt ;)
@Michi
Kannst du bitte deinen Post oben bearbeiten und dieses Text-Massaker entfernen? Das macht den Thread hier unnötig aufgebläht..
Die Infos die ich brauchte hab ich erstmal, meld mich deswegen nochmal, Danke :)
Gruß
Claudiu
@Michi:
Dein Problem mit den falschen disconnect Meldungen sollte behoben sein, Morgen im Update, oder jetzt im SVN.
Entweder verhält sich allerdings dein Controller sehr seltsam, oder alle mit Controller v3.x sollten dieses Problem i.M. haben.
Danke für die Info hierzu!
Gruß
Claudiu
Hab den Post gelöscht.
Kannst du was zu meinem Wunsch sagen?
Ja, dass interval kein Wert ist welcher Attribut Eigenschaften besitzt :)
Falls du das trotzdem wirklich durchziehen willst,
kannst du entweder ein "modify Unifi_Controller 192.168.1.1 8443 admin password <neuesInterval>" machen,
oder von außen die Modul-Interval-Variable überschreiben, da ich diese nur beim define setze. (Nur der vollständigkeit halber ;) )
---
Habe mir deine clientData nochmals angeschaut, und ja, ich glaube dein Controller macht wirklich Mist.
Das könnte zur Folge haben dass sich deine Datenbank undefiniert groß aufbläht, und auch erhöhte Last auf dem System produziert.
Aus irgend einem Grund legt dein Controller die Clients immer wieder neu an.
Ich müsste das zwar nochmals mit einem v3 Controller testen, allerdings bilde ich mir ein dass bei meinen v3.2.10 Tests der Controller dieses Verhalten nicht gezeigt hat.
Der Patch aus dem morgigen Update hilft zwar gegen die Auswirkungen auf Fhem-Seite, aber....
Gruß
Claudiu
Könnte hier Vllt jmd ne Anleitung oder Link zur Anleitung posten, wie man die Controller Version 4 auf Raspbian installiert? Und muss/sollte man dann vorher V3 deinstallieren und wenn ja, wie?
Zu Raspbian selber kann ich zwar nichts sagen,
meinen 3.2.10 Controller auf Debian habe ich allerdings problemlos wie hier (https://community.ubnt.com/t5/UniFi-Updates-Blog/UniFi-4-6-6-is-released/ba-p/1288816) beschrieben durch ein "apt-get install unifi" ohne vorheriges entfernen auf 4.6.6 aktualisiert.
Hat nicht weiter vorne jemand schon einen Link auf eine Raspbian Anleitung gepostet?
Gruß
Claudiu
Also nur
apt-get install Unifi
ausgeführt? Braucht man nicht vorher die Software runterladen?
Jo richtig, aber das war ne komplette Anleitung und ich würde am liebsten updaten, habe keine Lust nachher 2 Controller parallel laufen zu haben oder irgendwelche Leichen da im System zu haben.
Auf einem Debian System ja, auf einem Raspbian System hab ich mal gehört soll es nicht ganz so einfach funktionieren..
Jmd hier, der von Version 3 auf Version 4 auf Raspbian gewechselt hat?
Zitat von: Michi240281 am 04 September 2015, 09:18:02
Jmd hier, der von Version 3 auf Version 4 auf Raspbian gewechselt hat?
Ja! Ist ganz einfach:
- Zuerst einen Backup machen der Konfig im UniFi WebIf (habe ich zwar nicht gebraucht).
- UniFi stoppen
- Danach die neuste Version downloaden von https://community.ubnt.com/t5/UniFi-Updates-Blog/UniFi-4-6-6-is-released/ba-p/1288816
- Entpacken und wieder starten.
Hier die groben Schritte:
java -jar /opt/UniFi/lib/ace.jar stop
unzip UniFi.unix.zip
ln -fs /opt/mongodb/mongod mongod
java -jar /opt/UniFi/lib/ace.jar start
Details zur gesamten Installation eines Controllers findest du hier:
http://erikvanpaassen.tweakblogs.net/blog/10024/turning-a-raspberry-pi-into-a-unifi-controller-appliance.html
Gruss Dani
@Dani:
Besten Dank! Wo muss die Datei denn dann hinkopiert werden vor dem entpacken? /home/pi? Und wird dann die alte Controller-Version überschrieben? Oder löscht man die am besten vorher und wenn ja, wie?
@Rapster:
Letzte Nacht war das iPhone_Marina 2x offline obwohl es an ein und derselben Stelle lag die ganze Zeit! Bei der SNR gabs auch einige Einbrüche! Woher könnte das kommen? Evtl. wenn das Device den AP wechselt?
Hallo Michi,
Du könntest mal den AP mitloggen, und mal beobachten ob die disconnectes täglich zur ähnlichen Uhrzeiten auftreten.
Das einzige was mir auffällt ist, dass mein 5s mit iOS 9 zwar in der Nacht am Ladegerät auch öfter einbricht (siehe Anhang), allerdings fällt dabei der SNR Wert nie unter 10 dB.
Beim SNR Wert muss man allerdings beachten, das ist nicht die Brutto Signalsträke zum Controller, sondern das Verhältnis zwischen Signal und Umgebungsrauschen.
Evtl. liegt dort wo sich das iPhone nachts befindet soviel Fremdrauschen vor, dass der Controller das iPhone im DeepPowerSave nicht mehr richtig erkennt und als disconnected markiert.
Du könntest probieren mit einem WLAN-Sniffer deine Umgebung zur erkunden und deinen WLAN-Kanal am Accesspoint entpsrechend anzupassen dass es keine Überschneidungen mehr gibt.
Am besten nur Kanal 1, 6 und 11 Nutzen, anstatt sich mit einem anderen Kanal zu überschneiden, lieber auf den gleichen Kanal wie ein anderer frem-AP konfigurieren.
Gruß
Claudiu
Zitat von: eppi am 05 September 2015, 08:13:03
Ja! Ist ganz einfach:
- Zuerst einen Backup machen der Konfig im UniFi WebIf (habe ich zwar nicht gebraucht).
- UniFi stoppen
- Danach die neuste Version downloaden von https://community.ubnt.com/t5/UniFi-Updates-Blog/UniFi-4-6-6-is-released/ba-p/1288816
- Entpacken und wieder starten.
Hier die groben Schritte:
java -jar /opt/UniFi/lib/ace.jar stop
unzip UniFi.unix.zip
ln -fs /opt/mongodb/mongod mongod
java -jar /opt/UniFi/lib/ace.jar start
Details zur gesamten Installation eines Controllers findest du hier:
http://erikvanpaassen.tweakblogs.net/blog/10024/turning-a-raspberry-pi-into-a-unifi-controller-appliance.html
Gruss Dani
Das tuts leider nicht! Alles so gemacht, aber es ist immer noch die alte Version 3.2.10 aktiv! :(
Zitat von: Michi240281 am 05 September 2015, 19:38:11
Das tuts leider nicht! Alles so gemacht, aber es ist immer noch die alte Version 3.2.10 aktiv! :(
Mach einen Backup deines Contollers, stoppe ihn, dann das Verzeichnis UniFi mal löschen und danach frisch entzippen..
Zitat von: eppi am 06 September 2015, 09:58:47
Mach einen Backup deines Contollers, stoppe ihn, dann das Verzeichnis UniFi mal löschen und danach frisch entzippen..
Ok, versuche ich mal!
EDIT: Habs hinbekommen! Jetzt läuft Version 4.6.3.! :)
Übrigens noch ein Hinweis für alle, die ähnliches vorhaben:
Entweder vorher ein Backup machen oder den/die AP vorher aus dem Controller entfernen (freigeben), sonst wird er später im neuen Controller nicht erkannt und Ihr müsst ihn evtl. irgendwie auf Werkseinstellungen zurücksetzen!
@Rapster:
Mir ist heute morgen ein seltsames Phänomen aufgefalllen. Und zwar scheint es ein deutlicher Unterschied zu sein, ob man am Device das WLAN abschaltet oder ob man mit dem Device das Haus/die AP-Reichweite verlässt. Schaltet man das WLAN ab, wird beim nächsten aktualisieren des Unifi-Moduls die Trennung erkannt (...last_seen). Wenn man jedoch das Haus verlässt, passiert das erst 5 Minuten später! Hast du ne Idee, woran das liegen könnte?
mir ist gerade leider noch ein problem mit der zeichenwahl aufgefallen. du verwendest ein # für die ap spezifischen readings. wenn man die loggt gibt es ein problem weil man das reading zumindest bei dblog licht im plotfile angeben kann. das # wird als kommentar interpretiert.
gruss
andre
Tatsache, Ohwei...
# wird in der nächsten Version bei allen Readings mit - ersetzt, oder dann über die geplante auslagerungsfunktion ohne prefix im separaten AP-Device.
Oder hast du evtl. einen besseren Vorschlag als die Sortierung durch ein - Prefix zu realisieren, Andre?
BTW, in der nächsten Version gibt es noch paar weitere AP-Reading, z.B. -AP_locate <on|off> welches anzeigt ob die Locate-Funktion an einem AP aktiviert ist und noch ein paar Statistik readings.
Desweiteren hab ich einen leichteren Weg gefunden die benötigten Abfragen an den Controller zu bilden, ALLE Funktionen welche über das normale Controller-Interface möglich sind, lassen sich damit nun auf jedenfall auch in das Unifi-Modul integrieren.
Paar Sachen hab ich schon in die kommende Version eingebaut, falls jemand allerdings noch paar Wünsche hat, immer raus damit :-)
Gruß
Claudiu
die readings werden alphabetisch sortiert. - ist vermutlich das beste so lange alle readings in einem device sind.
nur das aufteilen in mehrere devices ist besser :)
gruss
andre
Mein Wunsch ist immernoch die Gastfunktion, oder eben das Gast WLAN welches man on oder off schalten könnte. Das wäre für mich ein rechter Mehrwert.
Danke!
Hi Mumpitz,
ich zitier mich mal selber mit meine Fragen dazu welche ich vor 2 Wochen an dich stelllte ;D
Evtl. kannst du mir ja was dazu sagen..
Zitat von: rapster am 28 August 2015, 23:27:35
...
- Gastzugang: Das ist generell einfach, aber...
Ich habe den Gastzugang über Unifi noch nie verwendet (Guest WLAN macht bei mir Firewall über ein VLAN am AP), wie verwendest du den üblicherweise?
Die API bietet mir zumindest Funktionen eine MAC Adresse (oder hostname falls das ein bekanntes Gerät ist) für X-Minuten als Guest zu erlauben, und wieder zu deaktivieren.
Wäre das sowas?
Hast du schon ungefähr einen Verwendungszeck dafür im Kopf? Damit ich mir was darunter vorstellen kann wie man mit Fhem den Gastzugang anschließend verwalten soll?
...
Gast WLAN on/off sollte mit der nächsten Version funktionieren, denke ich zumindest, es gibt dann zumindest die Möglichkeit das WLAN einer SSID zu deaktivieren, das Gast_WLAN sollte ja eine eigene SSID haben, oder?
Gruß
Claudiu
Sorry, mein Versehen.. Hab es nicht geschnallt das das eine Frage an mich ist....
Habe den Gastzugang bis jetzt noch nie benutzt, da ich den Controller bis jetzt auf dem PC hatte der sehr selten lief. Da war es für Gäste einfacher, schnell ins normal wlan einzuloggen.
Ich stelle mir folgendermaßen vor:
Mittels eines Dummy kann ich das gastwlan ein und ausschalten. Beim einschalten sollte eine zweite SSID erstellt werden mit einem definierten Namen und einem kurzen, definierten Passwort. Diese Angaben kann ich an die Gäste weitergeben.
Wenn die Gäste weg sind kann ich dieses wieder über den dummy ausschalten...
Das mein Wunsch. Reicht dir das?
Ah ok,
dann ist die Funktion im nächsten update schon eingebaut welche du brauchst, da das eigtl. keine wirklich Gastverwaltung ist sondern nur WLAN (ssid) ein/aus schalten ;)
Wobei du dann in dem Fall die SSID einmalig im Controller erstellen musst, allerdings über das Modul entsprechend de-/aktivieren kannst.
Im nächsten Update gibts dann noch eine Funktion über das Modul das WLAN-Passwort einer SSID zu ändern, dadurch kann man sich auch für sein GästeWLAN ein random Passwort-Of-The-Day basteln, was denke ich auch ganz gut zu gebrauchen ist.
Gruß
Claudiu
Dann wart ich gespannt auf das nächste Update!
Sali Rapster
kleine Frage: Sobald ich den Unifi Controlle gestartet habe füllt folgende Meldung im Minutentakt mein LogFile:
Exception in thread "inform_stat-9" java.util.ConcurrentModificationException
at java.lang.Thread.run(Thread.java:744)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at com.ubnt.service.A.K$_o.run(Unknown Source)
at com.ubnt.service.A.class.?00000(Unknown Source)
at com.ubnt.data.X.mergeFrom(Unknown Source)
at java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:734)
at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:711)
Exception in thread "inform_stat-3" java.util.ConcurrentModificationException
at java.lang.Thread.run(Thread.java:744)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at com.ubnt.service.A.K$_o.run(Unknown Source)
at com.ubnt.service.A.class.?00000(Unknown Source)
at com.ubnt.data.X.mergeFrom(Unknown Source)
at java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:734)
at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:711)
Weisst Du wie ich das verhindern kann?
gruess
mumpitz
Hi Mumpitz,
landet das in unifi/server.log?
Welche Controller Versions etzt du ein?
Gruß
Claudiu
nein, im Hauptlogfile vom fhem...
Version 4.6.0
gruss
Zitat von: Mumpitz am 25 September 2015, 13:31:55
nein, im Hauptlogfile vom fhem...
Version 4.6.0
gruss
Wenn du den Conroller über einen Dummy/notify startet, musst du sicherstellen, dass die stdout Meldungen umgeleitet werden... Stichwort /dev/null
Oha, tönt kompliziert!
Würde die Meldung nicht kommen wenn ich den Controller beim starten des Raspi automatisch starten würde?
Hallo Mumpitz,
normalerweiße startet man den Unifi Controller über init.d oder ein rc-script.
Wie startest du den Controller i.M.?
Kannst du mal ein "attr unifi verbose 5" setzen und mal die zeilen vor & nach der Fehlermeldung posten?
Gruß
Claudiu
Zitat von: Mumpitz am 25 September 2015, 22:30:07
Würde die Meldung nicht kommen wenn ich den Controller beim starten des Raspi automatisch starten würde?
Nein, wenn du wie Rapster geschrieben hat, den Controller über das init.d Script startet, bekommst du keine Meldungen im FileLog.
Habe ein Problem mit dem init.d Skript:
Habe alles so gemacht wie hier beschrieben:
http://draganbjelic.com/tutorial-how-to-install-unifi-4-6-0-controller-on-raspberry-pi/
oder hier
http://erikvanpaassen.tweakblogs.net/blog/10024/turning-a-raspberry-pi-into-a-unifi-controller-appliance
Leider bekomme ich beim Ausführen von
update-rc.d unifi defaults
folgende Fehlermeldung in der Konsole:
pi@raspberrypi ~ $ sudo su
root@raspberrypi:/home/pi# update-rc.d unifi defaults
update-rc.d: using dependency based boot sequencing
insserv: Script unifi is broken: incomplete LSB comment.
insserv: missing `Provides:' entry: please add.
insserv: missing `Required-Start:' entry: please add even if empty.
insserv: missing `Required-Stop:' entry: please add even if empty.
insserv: missing `Default-Start:' entry: please add even if empty.
insserv: missing `Default-Stop:' entry: please add even if empty.
insserv: Default-Start undefined, assuming empty start runlevel(s) for script `unifi'
insserv: Default-Stop undefined, assuming empty stop runlevel(s) for script `unifi'
Woran könnte das liegen?
Besten Dank und viele Grüße
Michael
Hi,
finde ich sehr interessant diese Idee mit diesem Modul, aber leider bekomme ich es nicht zum laufen. Im Log sehe ich nur
SSL_verify_mode must be a number and not a string at /usr/share/perl5/IO/Socket/SSL.pm line 2154.
Der Tipp von vor einigen Seiten hilft mir leider nicht.
Fhem läuft auf einem Debian testing und Unifi Controller ist v4.7.5.
Hi,
hmm, wird Zeit das ich die neue Version endlich einchecke...
Hast du es mit
attr global sslVersion TLSv1
probiert ?
Prüfe mal mit diesem FHEM-Befehl welche IO::Socket::SSL version du auf deiner Fhem-Maschine verwendest:
{`perl -M'IO::Socket::SSL' -e 'print "$IO::Socket::SSL::VERSION\n"'`}
Oder in der Linux-Shell:
perl -M'IO::Socket::SSL' -e 'print "$IO::Socket::SSL::VERSION\n"'
Hallo zusammen,
nach längerer Zeit ungetrübter Freude am Unifi-Modul in FHEM stürzt FHEM nun in Gänze ab (ist nicht mehr nach Eingabe des Befehls "top" gelistet).
Das FHEM-Logfile sagt:
Can't use an undefined value as an ARRAY reference at /usr/share/fhem/FHEM/74_Unifi.pm line 843.
Hat jemand noch eine Idee ?
Hab ich gefixt (jetzt im SVN oder morgen im update),
bitte nochmal probieren, da scheint eine Abfrage an den Controller bei dir nicht zu funktionieren.
Evtl. mal mit verbose 5 schauen was das Modul loggt.
Gruß
Claudiu
Hallo Rapster
Ich habe eine Frage an dich:
Und zwar schreibt der AP ja alle 5 Sekunden Daten in das server.log und alle 5 Minuten in mongo.log (oder so ähnlich) im log Ordner des UniFi.
Ich hatte die Installation zuerst ganz normal auf dem Raspi, und somit auf der SD Karte installiert. Diese verabschiedete sich jedoch vor ca. 3 Wochen. Seither habe ich das UniFi auf einem USBSTICK installiert. Möchte damit ein erneuten Defekt der Karte verhindern. (Nur eine Vermutung das darum die Karte kaputt ging)
Nun meine Frage. Ist es möglich das loggen abzustellen oder zumindest auf minütlich zu ändern?
Greift dein Modul genau auf diese logfiles zu?
Danke für deine Hilfe
Mumpitz
Hi Mumpitz,
du kannst das logging des Controllers und der MongoDB gerne komplett deaktivieren, evtl. findet sich über google "disable mongodb log" eine Anleitung?
Für das Modul ist das Controller oder MongoDB Log nicht notwendig, das kommuniziert direkt mit der Controller-API.
Allerdings ist ein logging im 5 Sekunden Takt schon ungewöhnlich, hier mal die letzten 10 Zeilen meines mongod.log und server.log mit Controller Version 4.7.5 und MongoDB Version 2.4.14.
Da schreibt zwar die MongoDB auch alle ~5 Min eine Zeile ins Log, diese ist allerdings mMn zu vernachlässigen :)
root@UniFi:/var/log/unifi>tail -n 10 mongod.log server.log
==> mongod.log <==
Thu Nov 5 20:18:04.085 [conn2] info DFM::findAll(): extent 0:38f000 was empty, skipping ahead. ns:ace.device
Thu Nov 5 20:21:38.990 [conn1] info DFM::findAll(): extent 0:38f000 was empty, skipping ahead. ns:ace.device
Thu Nov 5 20:25:08.410 [conn4] info DFM::findAll(): extent 0:38f000 was empty, skipping ahead. ns:ace.device
Thu Nov 5 20:29:08.494 [conn4] info DFM::findAll(): extent 0:38f000 was empty, skipping ahead. ns:ace.device
Thu Nov 5 20:33:34.008 [conn2] info DFM::findAll(): extent 0:38f000 was empty, skipping ahead. ns:ace.device
Thu Nov 5 20:38:03.791 [conn6] info DFM::findAll(): extent 0:38f000 was empty, skipping ahead. ns:ace.device
Thu Nov 5 20:42:38.495 [conn5] info DFM::findAll(): extent 0:38f000 was empty, skipping ahead. ns:ace.device
Thu Nov 5 20:47:08.698 [conn2] info DFM::findAll(): extent 0:38f000 was empty, skipping ahead. ns:ace.device
Thu Nov 5 20:51:48.164 [conn2] info DFM::findAll(): extent 0:38f000 was empty, skipping ahead. ns:ace.device
Thu Nov 5 20:56:18.707 [conn4] info DFM::findAll(): extent 0:38f000 was empty, skipping ahead. ns:ace.device
==> server.log <==
[2015-08-31 20:18:22,412] <inform_stat-8> ERROR uap - isolated AP[04:18:d6:24:24:59] reported, last seen=10s ago, scan_node.last_seen=42s ago
[2015-08-31 20:18:32,941] <inform_stat-17> ERROR uap - isolated AP[04:18:d6:24:24:59] reported, last seen=5s ago, scan_node.last_seen=57s ago
[2015-08-31 20:18:37,452] <inform_stat-14> ERROR uap - isolated AP[04:18:d6:24:24:59] reported, last seen=10s ago, scan_node.last_seen=57s ago
[2015-09-13 16:52:25,286] <autoupdate-check> WARN system - update site - cannot resolve the host
root@UniFi:/var/log/unifi>
Gruß
Claudiu
Danke für die schnelle Antwort. Betreffend der Google Suche muss ich leider kapitulieren. Konnte nichts entsprechendes finden...
hier mein server.log
[2015-11-05 21:56:54,806] <inform-10> INFO inform - from [dc:9f:db:f2:eb:77](AP-EG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.101, dev_ip=192.168.17.101, up=3926984
[2015-11-05 21:56:59,279] <inform-11> INFO inform - from [24:a4:3c:4c:04:7d](AP-OG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.119, dev_ip=192.168.17.119, up=987190
[2015-11-05 21:57:04,286] <inform-12> INFO inform - from [24:a4:3c:4c:05:8d](AP-UG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.106, dev_ip=192.168.17.106, up=3928330
[2015-11-05 21:57:09,863] <inform-13> INFO inform - from [dc:9f:db:f2:eb:77](AP-EG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.101, dev_ip=192.168.17.101, up=3926999
[2015-11-05 21:57:14,342] <inform-14> INFO inform - from [24:a4:3c:4c:04:7d](AP-OG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.119, dev_ip=192.168.17.119, up=987205
[2015-11-05 21:57:19,348] <inform-15> INFO inform - from [24:a4:3c:4c:05:8d](AP-UG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.106, dev_ip=192.168.17.106, up=3928345
[2015-11-05 21:57:24,917] <inform-16> INFO inform - from [dc:9f:db:f2:eb:77](AP-EG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.101, dev_ip=192.168.17.101, up=3927014
[2015-11-05 21:57:29,506] <inform-17> INFO inform - from [24:a4:3c:4c:04:7d](AP-OG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.119, dev_ip=192.168.17.119, up=987220
[2015-11-05 21:57:34,409] <inform-18> INFO inform - from [24:a4:3c:4c:05:8d](AP-UG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.106, dev_ip=192.168.17.106, up=3928360
[2015-11-05 21:57:40,096] <inform-19> INFO inform - from [dc:9f:db:f2:eb:77](AP-EG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.101, dev_ip=192.168.17.101, up=3927029
[2015-11-05 21:57:44,569] <inform-20> INFO inform - from [24:a4:3c:4c:04:7d](AP-OG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.119, dev_ip=192.168.17.119, up=987235
[2015-11-05 21:57:49,470] <inform-21> INFO inform - from [24:a4:3c:4c:05:8d](AP-UG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.106, dev_ip=192.168.17.106, up=3928375
[2015-11-05 21:57:54,250] <inform-22> INFO inform - from [dc:9f:db:f2:eb:77](AP-EG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.101, dev_ip=192.168.17.101, up=3927044
[2015-11-05 21:57:59,632] <inform-23> INFO inform - from [24:a4:3c:4c:04:7d](AP-OG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.119, dev_ip=192.168.17.119, up=987250
[2015-11-05 21:58:04,533] <inform-24> INFO inform - from [24:a4:3c:4c:05:8d](AP-UG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.106, dev_ip=192.168.17.106, up=3928390
[2015-11-05 21:58:09,409] <inform-25> INFO inform - from [dc:9f:db:f2:eb:77](AP-EG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.101, dev_ip=192.168.17.101, up=3927059
[2015-11-05 21:58:14,703] <inform-26> INFO inform - from [24:a4:3c:4c:04:7d](AP-OG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.119, dev_ip=192.168.17.119, up=987266
[2015-11-05 21:58:19,593] <inform-27> INFO inform - from [24:a4:3c:4c:05:8d](AP-UG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.106, dev_ip=192.168.17.106, up=3928405
[2015-11-05 21:58:24,466] <inform-28> INFO inform - from [dc:9f:db:f2:eb:77](AP-EG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.101, dev_ip=192.168.17.101, up=3927074
[2015-11-05 21:58:29,861] <inform-29> INFO inform - from [24:a4:3c:4c:04:7d](AP-OG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.119, dev_ip=192.168.17.119, up=987281
[2015-11-05 21:58:34,656] <inform-30> INFO inform - from [24:a4:3c:4c:05:8d](AP-UG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.106, dev_ip=192.168.17.106, up=3928420
[2015-11-05 21:58:39,524] <inform-31> INFO inform - from [dc:9f:db:f2:eb:77](AP-EG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.101, dev_ip=192.168.17.101, up=3927089
[2015-11-05 21:58:44,938] <inform-32> INFO inform - from [24:a4:3c:4c:04:7d](AP-OG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.119, dev_ip=192.168.17.119, up=987296
[2015-11-05 21:58:49,797] <inform-33> INFO inform - from [24:a4:3c:4c:05:8d](AP-UG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.106, dev_ip=192.168.17.106, up=3928435
[2015-11-05 21:58:54,583] <inform-34> INFO inform - from [dc:9f:db:f2:eb:77](AP-EG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.101, dev_ip=192.168.17.101, up=3927104
[2015-11-05 21:59:00,062] <inform-35> INFO inform - from [24:a4:3c:4c:04:7d](AP-OG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.119, dev_ip=192.168.17.119, up=987311
[2015-11-05 21:59:04,923] <inform-36> INFO inform - from [24:a4:3c:4c:05:8d](AP-UG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.106, dev_ip=192.168.17.106, up=3928451
[2015-11-05 21:59:09,641] <inform-37> INFO inform - from [dc:9f:db:f2:eb:77](AP-EG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.101, dev_ip=192.168.17.101, up=3927119
[2015-11-05 21:59:14,119] <inform-38> INFO inform - from [24:a4:3c:4c:04:7d](AP-OG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.119, dev_ip=192.168.17.119, up=987325
[2015-11-05 21:59:19,985] <inform-39> INFO inform - from [24:a4:3c:4c:05:8d](AP-UG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.106, dev_ip=192.168.17.106, up=3928466
[2015-11-05 21:59:24,699] <inform-40> INFO inform - from [dc:9f:db:f2:eb:77](AP-EG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.101, dev_ip=192.168.17.101, up=3927134
[2015-11-05 21:59:29,185] <inform-41> INFO inform - from [24:a4:3c:4c:04:7d](AP-OG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.119, dev_ip=192.168.17.119, up=987340
[2015-11-05 21:59:35,043] <inform-42> INFO inform - from [24:a4:3c:4c:05:8d](AP-UG, BZ2, 3.2.10.2886): state=CONNECTED, ext/stun_ip=192.168.17.106, dev_ip=192.168.17.106, up=3928481
bei den 3 IP's handelt es sich um meine 3 AP'S: xxx.xxx.xxx.106 / 101 / 119
hier meine mongod.log
Thu Nov 5 21:25:22 [clientcursormon] mem (MB) res:29 virt:145 mapped:64
Thu Nov 5 21:30:22 [clientcursormon] mem (MB) res:29 virt:145 mapped:64
Thu Nov 5 21:35:22 [clientcursormon] mem (MB) res:29 virt:145 mapped:64
Thu Nov 5 21:40:22 [clientcursormon] mem (MB) res:29 virt:145 mapped:64
Thu Nov 5 21:45:22 [clientcursormon] mem (MB) res:29 virt:145 mapped:64
Thu Nov 5 21:50:22 [clientcursormon] mem (MB) res:29 virt:145 mapped:64
Thu Nov 5 21:55:22 [clientcursormon] mem (MB) res:29 virt:145 mapped:64
Thu Nov 5 22:00:22 [clientcursormon] mem (MB) res:30 virt:145 mapped:64
Eine Idee woher die Einträge kommen?
O.K. ich erinnere mich daran dass ich vor längerer Zeit mal an paar Schrauben bei meinem Controller gedreht hatte, stimmt!
Irgendwo in deinem System findest du ein file namens "system.properties", bei mir /var/lib/unifi/system.properties
Ändere mal die Zeilen:
debug.device=info
debug.mgmt=info
debug.system=info
auf
debug.device=warn
debug.mgmt=warn
debug.system=warn
und starte anschließend den Controller einmal neu.
Dann sollten keine INFO-Level Events mehr geloggt werden.
BTW: in dem file lässt sich auch der Controller Port ändern, z.B. von 8443 auf standard 443 damit das im browser nicht immer explizit mit angegeben werden muss.
Gruß
Claudiu
Großes Kino! Ich Probier es morgen aus!
Merci!
Da fallen mir grad noch so paar Sachen ein um Ressourcen und ~6GB Speicher einzusparen ;D
1. Standardmäßig werden 2 MongoDB Instanzen gestartet, eine vom System und eine vom Unifi-Controller.
Die System DB wird natürlich nicht benötigt!
Am besten hierzu in der /etc/init.d/mongodb die Start-Runlevels entfernen, also aus:
# Default-Start: 2 3 4 5
das machen:
# Default-Start:
und anschließend mit diesem Befehl die rc-scripte entfernen (als root):
update-rc.d mongodb remove
Zum Schluss können dann noch die 3x 1GB files in /var/lib/mongodb/journal/ gelöscht werden. (Die kommen von der nicht benötigten System mongo-Instanz)
2. Die Unifi Mongo-DB Instanz legt ebenfalls fürs journaling 3x 1GB files unter /var/lib/unifi/db/journal/ an, dies kann man auf 3x 128MB reduzieren wenn man im vorhin genannte system.properties file folgenden Zeile hinzufügt:
unifi.db.extraargs=--smallfiles
3. Um die Schreibzugriffe auf eine SD-Karte zu reduzieren, könnte man um den journal-overhead zu vermeiden das journaling auch komplett deaktivieren (Bitte die dadurch entstehenden Risiken beachten).
Hierzu die Argumente aus der MongoDB Dokumentation setzen (https://docs.mongodb.org/v2.4/reference/configuration-options/#journal (https://docs.mongodb.org/v2.4/reference/configuration-options/#journal), https://docs.mongodb.org/v2.4/reference/configuration-options/#nojournal (https://docs.mongodb.org/v2.4/reference/configuration-options/#nojournal)), bzw. den dafür in der system.properties vorhandenen Parameter unifi.db.nojournal.
Gruß
Claudiu
Hallo Claudiu
Heute Morgen voller Vorfreude um 0530 Uhr meinen Computer gestartet um die Änderungen einzutragen. Nun jedoch folgendes Problem:
Ich habe keinen Ordner /var/lib/unifi/system.properties.
Ich nehme jedoch an, dass es sich dabei um den Standardordner handelt, in welchem der Controller installiert ist. Das wäre bei mir: /media/usbstick_neu/UniFi
dort gibt es direkt unter unifi die entsprechende Datei nicht. Es gibt jedoch eine unter /media/usbstick_neu/UniFi/data
Diese beinhaltet:
## system.properties
#
# each unifi instance requires a set of ports:
#
# unifi.http.port=8080 # device inform
# unifi.https.port=8443 # controller UI / API
# portal.http.port=8880 # portal redirect port for HTTP
# portal.https.port=8843 # portal redirect port for HTTPs
# unifi.db.port=27117 # local-bound port for DB server
# unifi.stun.port=3478 # UDP port used for STUN
#
# system_ip=a.b.c.d # the IP devices should be talking to for inform
# unifi.db.nojournal=false # disable mongodb journaling
# unifi.db.extraargs # extra mongod args
#
## HTTPS options
# unifi.https.ciphers=TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA
# unifi.https.sslEnabledProtocols=TLSv1
#
# Ports reserved for device redirector. There is no need to open
# firewall for these ports on controller, however do NOT set
# controller to use these ports.
#
# portal.redirector.port=8881
# portal.redirector.port.wired=8882
#
#Fri Nov 06 05:01:55 UTC 2015
is_default=false
uuid=158c65d5-d387-4dbe-b59c-0f57ec3b81e7
Nichts mit Debug.....
Leider geht es auch weiter, dass dein zweiter Post, wo das System Mongodb abgeschaltet werden könnte, ebenfalls unter deinem angegeben Ort /etc/init.d/mongodb dieser Datei nicht existiert :-[
ich kann also den Default-Start eintrag nicht abändern...
Any Tricks?
Morgen Mumpitz,
du has tdie richtige Datei entdeckt :)
Einfach direkt eintragen die entsprechenden Parameter z.B. so:
## system.properties
#
# each unifi instance requires a set of ports:
#
# unifi.http.port=8080 # device inform
# unifi.https.port=8443 # controller UI / API
# portal.http.port=8880 # portal redirect port for HTTP
# portal.https.port=8843 # portal redirect port for HTTPs
# unifi.db.port=27117 # local-bound port for DB server
# unifi.stun.port=3478 # UDP port used for STUN
#
# system_ip=a.b.c.d # the IP devices should be talking to for inform
# unifi.db.nojournal=false # disable mongodb journaling
# unifi.db.extraargs # extra mongod args
#
## HTTPS options
# unifi.https.ciphers=TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA
# unifi.https.sslEnabledProtocols=TLSv1
#
# Ports reserved for device redirector. There is no need to open
# firewall for these ports on controller, however do NOT set
# controller to use these ports.
#
# portal.redirector.port=8881
# portal.redirector.port.wired=8882
#
#Fri Nov 06 05:01:55 UTC 2015
debug.device=warn
debug.mgmt=warn
debug.system=warn
is_default=false
unifi.db.extraargs=--smallfiles
unifi.http.port=80
unifi.https.port=443
uuid=158c65d5-d387-4dbe-b59c-0f57ec3b81e7
Dann Speichern und den Controller restarten :)
Wenn du keine Datei /etc/init.d/mongodb haben solltest, dann sollte bei dir auch alles O.K. sein und nur eine Mongo-Instanz laufen.
Einfach mal mit dem Shell Befehl
ps aux | grep [m]ongo
prüfen.
Gruß
Claudiu
Zitat von: rapster am 01 November 2015, 21:08:40
Prüfe mal mit diesem FHEM-Befehl welche IO::Socket::SSL version du auf deiner Fhem-Maschine verwendest:
{`perl -M'IO::Socket::SSL' -e 'print "$IO::Socket::SSL::VERSION\n"'`}
Oder in der Linux-Shell:
perl -M'IO::Socket::SSL' -e 'print "$IO::Socket::SSL::VERSION\n"'
Hallo Rapster,
sorry dass ich erst jetzt antworte. Ja natürlich habe ich es mit sslv1 bereits probiert, erfolglos.
Die Ausgabe der ssl version ist folgende:
$ perl -M'IO::Socket::SSL' -e 'print "$IO::Socket::SSL::VERSION\n"'
2.020
Update auf aktuelle Version habe ich auch bereits ausgeführt, weiterhin keine Verbesserung. Es kommt die erwähnte Ausgabe im Log und fhem schmiert ab.
Ich habe mir jetzt mal deinen Code angeschaut. Warum benutzt du 'SSL_VERIFY_NONE'. Wie es die Fehlermeldung sagt, dies ist ein String. Aber solche Parameter sind meistens definierte Werte. Du musst es auch als solches benutzen, sprich ohne die ''.
Ausserdem muss es natürlich vorher erst irgendwoher kommen:
use IO::Socket::SSL qw( SSL_VERIFY_NONE );
Danach startet dein Code wenigstens :)
Hallo Tompkin,
Mach mal bitte ein
attr global verbose 5
und
list global
und Poste das list sowie die Zeilen vor und nach dem Fehler mit.
kann es sein dass dein Unifi Controller NICHT auf der FHEM-Maschine läuft?
Die Perl-SSL Version hast du auf der FHEM-Maschine geprüft?
Bei v2.020 sollte die Standardeinstellung von FHEM O.K. sein und muss nicht über das global Attribut geändert werden.
Desweiteren hoffe ich du hast nicht sslVersion auf sslv1 gesetzt sondern auf TLSv1 ?
Deine Vermutungen zu dem use Statement sowie zu dem SSL_verify_mode sind desweiteren natürlich falsch, bitte hierzu die Dokumentation von IO::Socket::SSL anschauen und sich etwas in die Arbeitsweise dieses und der verwendeten FHEM-Module einlesen wenn es interessiert.
Gruß
Claudiu
Hi,
list global:
Internals:
DEF <no definition>
NAME global
NR 1
STATE <no definition>
TYPE Global
currentlogfile ./log/fhem-2015-11.log
logfile ./log/fhem-%Y-%m.log
Attributes:
autoload_undefined_devices 1
configfile fhem.cfg
logfile ./log/fhem-%Y-%m.log
modpath .
sslVersion TLSv1
statefile ./log/fhem.save
updateInBackground 1
userattr cmdIcon devStateIcon devStateStyle icon sortby webCmd widgetOverride
verbose 5
version $Id: fhem.pl 9755 2015-11-02 19:34:14Z rudolfkoenig $
Verbose log:
2015.11.06 19:21:29 4: Connection closed for FHEMWEB:fe80::c8a1:c7ec:af5:c4e7:50105: EOF
2015.11.06 19:21:29 4: FHEMWEB:fe80::c8a1:c7ec:af5:c4e7:50106 POST /fhem&cmd=define+ext_unifi+Unifi+192.168.0.40+8443+aa+bb+30+xx; BUFLEN:0
2015.11.06 19:21:29 5: Cmd: >define ext_unifi Unifi 192.168.0.40 8443 aa bb 30 xx<
2015.11.06 19:21:29 5: Loading ./FHEM/74_Unifi.pm
2015.11.06 19:21:29 5: ext_unifi: Defined with url:https://192.168.0.40:8443/api/s/xx/, interval:30, version:4
2015.11.06 19:21:29 5: Triggering global (1 changes)
2015.11.06 19:21:29 5: Notify loop for global DEFINED ext_unifi
2015.11.06 19:21:29 5: ext_unifi (Unifi_Notify) - executed. - Remove all Timers & Call DoUpdate...
2015.11.06 19:21:29 5: Triggering ext_unifi (1 changes)
2015.11.06 19:21:29 5: Notify loop for ext_unifi initialized
2015.11.06 19:21:29 5: ext_unifi (Unifi_DoUpdate) - executed.
2015.11.06 19:21:29 5: Triggering ext_unifi (1 changes)
2015.11.06 19:21:29 5: Notify loop for ext_unifi disconnected
2015.11.06 19:21:29 5: ext_unifi (Unifi_Login_Send) - executed.
2015.11.06 19:21:29 5: HttpUtils url=https://192.168.0.40:8443/api/login
SSL_verify_mode must be a number and not a string at /usr/share/perl5/IO/Socket/SSL.pm line 2154.
Der Unifi Controller läuft tatsächlich auf einer anderen Maschine, das ist richtig. Die Abfrage per Perl lief auf der FHEM Maschine.
Dokumentation zu IO::Socket::SSL hatte ich mir natürlich angeschaut, deswegen bin ich ja darauf gekommen.
Siehe bitte auch https://rt.cpan.org/Public/Bug/Display.html?id=106645 (https://rt.cpan.org/Public/Bug/Display.html?id=106645)
ZitatIf you set it to a string (like SSL_verify_mode => 'SSL_VERIFY_PEER') then you are doing it wrong.
Oha, ja das schaut soweit gut aus.
Das scheint bei dir tatsächlich daran zu liegen dass die SSL-Version zu neu ist, hier haben sie wohl die evaluierung dieses Arguments geändert.
Danke für den Link, ich bin von dieser Doku hier ausgegangen, habe das allerdings anders interpretiert. http://search.cpan.org/~sullr/IO-Socket-SSL-2.020/lib/IO/Socket/SSL.pod (http://search.cpan.org/~sullr/IO-Socket-SSL-2.020/lib/IO/Socket/SSL.pod)
Habe eben eine neue Version eingecheckt, bitte mal ausprobieren ob es hiermit funktioniert. (jetzt im SVN oder morgigen Update)
Gruß
Claudiu
Hallo Claudiu.
Deine gewünschte Abfrage ergab:
root 2357 0.9 6.5 147784 61916 ? Sl 06:01 8:25 bin/mongod --dbpath /media/usbstick_neu/UniFi/data/db --port 27117 --logappend --logpath logs/mongod.log --nohttpinterface --bind_ip 127.0.0.1
Gesendet von iPad mit Tapatalk
Ahja kein Problem. Aber wegen solcher Sachen werden Perl und ich auch niemals Freunde. Lieber debugge ich memleaks in C/C++, als Perl Dokus zu lesen ;)
Dein commit läuft sicherlich, aber du solltest dabei bleiben und die Definition SSL_VERIFY_NONE benutzen. Sonst hast du wieder Probleme, wenn sich vielleicht die Werte mal ändern in zukünftigen Versionen, oder jemand lokal "spielt".
Die Lösung hatte ich ja bereits gepostet.
Danke nochmal für das Modul, echt super Idee. Jetzt muss ich mir nur noch überlegen, was ich alles wie steuern lasse mit meiner Präsenzerkennung. Jemand gute Anregungen? :)
@Tompkin:
Allerdings bedenken dass sich im nächsten feature-release einiges ändern wird wodurch wahrscheinlich ein paar Steuerungen welche dieses Modul verwenden angepasst werden müssen.
Zitat von: Tompkin am 06 November 2015, 20:22:56
du solltest dabei bleiben und die Definition SSL_VERIFY_NONE benutzen
Jetzt habe ich die Doku allerdings etwas aufmerksamer gelesen, 0 ist und bleibt VERIFY_NONE :), das einbinden von SSL überlasse ich HttpUtils.
@Mumpitz:
Schaut gut aus, nur eine Mongo-Instanz, denke das liegt daran dass du das auf dem raspi nicht per apt-get installiert hast.
Dein Server-Log ist nun sauber?
Gruß
Claudiu
Sali Rapster
Ja, sein den beiden Einträgen habe ich nur noch diese Meldungen im Log:
[2015-11-06 20:01:17,679] <db-server> INFO db - DbServer stopped
[2015-11-06 20:01:30,010] <unifi-monitor> INFO launcher - service_loop()
scheint zu gehen!
merci, wie immer perfekter Service
Schönes Wochenende
Hallo Rapster
ich habe nun die nächste Frage. Leider finden immernoch permanent Zugriffe auf den USB Stick statt. Um den Inhalt des Sticks zu sichern, habe ich mir mittels rsync ein Backup des Sticks eingerichtet. Versuchsweise habe ich nun innerhalb von zwei Minuten das rsync script laufen lassen. Nun sehe ich, dass die folgenden Dateien jedesmal gesynct werden, sprich durch UniFi aktualisiert worden sind...
UniFi/data/db/ace_stat.0
UniFi/data/devices/uap/24-a4-3c-4c-04-7d/last.inform
UniFi/data/devices/uap/24-a4-3c-4c-04-7d/last.inform_connected
UniFi/data/devices/uap/24-a4-3c-4c-05-8d/last.inform
UniFi/data/devices/uap/24-a4-3c-4c-05-8d/last.inform_connected
UniFi/data/devices/uap/dc-9f-db-f2-eb-77/last.inform
UniFi/data/devices/uap/dc-9f-db-f2-eb-77/last.inform_connected
sprich diese Infos, die wir in einigen Posts vorher abgestellt haben (damit sie nicht mehr ins server.log) geschrieben werden, werden zusätzlich immernoch in diese Dateien geschrieben. Der Inhalt einer solchen last.inform:
{
"_authkey" : "bla bla bla" ,
"_devextip" : "192.168.17.119" ,
"_devsiteid" : "547ea53b9bfab4de58818c55" ,
"_encrypted" : true ,
"_id" : "55ebcf001228ccb2171a6888" ,
"_mac" : "24-A4-3C-4C-04-7D" ,
"_protoheader" : "Class:_oo" ,
"bootrom_version" : "unifi-v1.5.2.206-g44e4c8bc" ,
"cfgversion" : "fcdadf3cd2b81084" ,
"connect_request_ip" : "192.168.17.119" ,
"connect_request_port" : "50183" ,
"country_code" : 0 ,
"default" : false ,
"guest_token" : "4072BB9ED932D73EC8931A4EE7783AF1" ,
"has_eth1" : false ,
"has_poe_passthrough" : false ,
"hostname" : "AP-OG" ,
"if_table" : [
{
"full_duplex" : true ,
"ip" : "0.0.0.0" ,
"mac" : "24:a4:3c:4c:04:7d" ,
"name" : "eth0" ,
"num_port" : 1 ,
"rx_bytes" : 327172340 ,
"rx_dropped" : 0 ,
"rx_errors" : 0 ,
"rx_multicast" : 2564373 ,
"rx_packets" : 5306263 ,
"speed" : 100 ,
"tx_bytes" : 996439524 ,
"tx_dropped" : 0 ,
"tx_errors" : 0 ,
"tx_packets" : 2540487 ,
"up" : true
}
] ,
"inform_url" : "http://192.168.17.5:8080/inform" ,
"ip" : "192.168.17.119" ,
"isolated" : false ,
"locating" : false ,
"mac" : "24:a4:3c:4c:04:7d" ,
"model" : "BZ2" ,
"model_display" : "UAP" ,
"radio_table" : [
{
"athstats" : {
"ast_ath_reset" : 0 ,
"ast_be_xmit" : 12961808 ,
"ast_cst" : 7401 ,
"ast_deadqueue_reset" : 0 ,
"ast_fullqueue_stop" : 0 ,
"ast_txto" : 5242 ,
"n_rx_aggr" : 7307153 ,
"n_rx_pkts" : 27614957 ,
"n_tx_bawadv" : 821784 ,
"n_tx_bawretries" : 70721 ,
"n_tx_pkts" : 2234423 ,
"n_tx_queue" : 1230272 ,
"n_tx_retries" : 70722 ,
"n_tx_xretries" : 516 ,
"n_txaggr_compgood" : 442307 ,
"n_txaggr_compretries" : 71247 ,
"n_txaggr_compxretry" : 0 ,
"n_txaggr_prepends" : 36467 ,
"name" : "wifi0"
} ,
"builtin_ant_gain" : 0 ,
"builtin_antenna" : true ,
"max_txpower" : 23 ,
"min_txpower" : 5 ,
"name" : "wifi0" ,
"radio" : "ng" ,
"scan_table" : [
{
"age" : 0 ,
"bssid" : "2a:a4:3c:4d:05:8d" ,
"channel" : 1 ,
"essid" : "ReSuTuq" ,
"freq" : 2412 ,
"is_adhoc" : false ,
"is_default" : false ,
"is_isolated" : false ,
"is_locating" : false ,
"is_ubnt" : true ,
"is_unifi" : true ,
"is_vport" : false ,
"is_vwire" : false ,
"model" : "BZ2" ,
"model_display" : "UAP" ,
"rssi" : 8 ,
"security" : "secured" ,
"serialno" : "24A43C4C058D"
}
]
}
] ,
"required_version" : "2.4.4" ,
"serial" : "24A43C4C047D" ,
"state" : 2 ,
"time" : 1447097172 ,
"uplink" : "eth0" ,
"uptime" : 1327340 ,
"vap_table" : [
{
"bssid" : "00:00:00:00:00:00" ,
"ccq" : 716432144 ,
"channel" : 1 ,
"essid" : "vport-24A43C4C047D" ,
"id" : "user" ,
"name" : "ath0" ,
"num_sta" : 0 ,
"radio" : "ng" ,
"rx_bytes" : 0 ,
"rx_crypts" : 0 ,
"rx_dropped" : 0 ,
"rx_errors" : 0 ,
"rx_frags" : 0 ,
"rx_nwids" : 0 ,
"rx_packets" : 0 ,
"sta_table" : [
] ,
"state" : "INIT" ,
"tx_bytes" : 0 ,
"tx_dropped" : 0 ,
"tx_errors" : 0 ,
"tx_packets" : 0 ,
"tx_power" : 20 ,
"tx_retries" : 0 ,
"up" : false ,
"usage" : "uplink"
} ,
{
"bssid" : "2a:a4:3c:4d:04:7d" ,
"ccq" : 949 ,
"channel" : 1 ,
"essid" : "ReSuTuq" ,
"id" : "547d8d3a42e4fa9b30a2b618" ,
"name" : "ath1" ,
"num_sta" : 4 ,
"radio" : "ng" ,
"rx_bytes" : 559565283 ,
"rx_crypts" : 4207 ,
"rx_dropped" : 0 ,
"rx_errors" : 0 ,
"rx_frags" : 0 ,
"rx_nwids" : 90441 ,
"rx_packets" : 1669628 ,
"sta_table" : [
{
"auth_time" : 4294967282 ,
"authorized" : true ,
"ccq" : 930 ,
"dhcpend_time" : 136 ,
"dhcpstart_time" : 134 ,
"idletime" : 0 ,
"ip" : "192.168.17.110" ,
"is_11n" : true ,
"mac" : "18:fe:34:fe:a1:ae" ,
"noise" : -100 ,
"rssi" : 14 ,
"rx_bytes" : 2496 ,
"rx_mcast" : 9 ,
"rx_packets" : 22 ,
"rx_rate" : 1000 ,
"rx_retries" : 134 ,
"signal" : -86 ,
"state" : 29 ,
"state_ht" : true ,
"state_pwrmgt" : true ,
"tx_bytes" : 1770 ,
"tx_packets" : 20 ,
"tx_power" : 40 ,
"tx_rate" : 26000 ,
"tx_retries" : 6 ,
"uptime" : 336
} ,
{
"auth_time" : 4294967282 ,
"authorized" : true ,
"ccq" : 946 ,
"dhcpend_time" : 127 ,
"dhcpstart_time" : 124 ,
"idletime" : 0 ,
"ip" : "192.168.17.112" ,
"is_11n" : true ,
"mac" : "18:fe:34:fd:f0:cd" ,
"noise" : -100 ,
"rssi" : 23 ,
"rx_bytes" : 341864 ,
"rx_mcast" : 7 ,
"rx_packets" : 4031 ,
"rx_rate" : 1000 ,
"rx_retries" : 27958 ,
"signal" : -77 ,
"state" : 29 ,
"state_ht" : true ,
"state_pwrmgt" : true ,
"tx_bytes" : 252557 ,
"tx_packets" : 5391 ,
"tx_power" : 40 ,
"tx_rate" : 52000 ,
"tx_retries" : 1566 ,
"uptime" : 117492
} ,
{
"auth_time" : 4294967269 ,
"authorized" : true ,
"ccq" : 991 ,
"dhcpend_time" : 0 ,
"dhcpstart_time" : 0 ,
"idletime" : 10 ,
"ip" : "192.168.17.65" ,
"is_11n" : true ,
"mac" : "64:00:2d:00:b4:1f" ,
"noise" : -100 ,
"rssi" : 26 ,
"rx_bytes" : 20418942 ,
"rx_mcast" : 35224 ,
"rx_packets" : 50293 ,
"rx_rate" : 43333 ,
"rx_retries" : 9919 ,
"signal" : -74 ,
"state" : 15 ,
"state_ht" : true ,
"state_pwrmgt" : false ,
"tx_bytes" : 786121 ,
"tx_packets" : 12451 ,
"tx_power" : 40 ,
"tx_rate" : 72222 ,
"tx_retries" : 164 ,
"uptime" : 125922
} ,
{
"auth_time" : 4294967150 ,
"authorized" : true ,
"ccq" : 991 ,
"dhcpend_time" : 242 ,
"dhcpstart_time" : 240 ,
"hostname" : "HF-LPB100-ZJ200" ,
"idletime" : 5 ,
"ip" : "192.168.17.113" ,
"is_11n" : true ,
"mac" : "ac:cf:23:5f:32:04" ,
"noise" : -100 ,
"rssi" : 44 ,
"rx_bytes" : 6742698 ,
"rx_mcast" : 1920 ,
"rx_packets" : 77892 ,
"rx_rate" : 1000 ,
"rx_retries" : 1252 ,
"signal" : -56 ,
"state" : 31 ,
"state_ht" : true ,
"state_pwrmgt" : true ,
"tx_bytes" : 2405131 ,
"tx_packets" : 52813 ,
"tx_power" : 40 ,
"tx_rate" : 72222 ,
"tx_retries" : 741 ,
"uptime" : 605667
}
] ,
"state" : "RUN" ,
"tx_bytes" : 2579055731 ,
"tx_dropped" : 477 ,
"tx_errors" : 0 ,
"tx_packets" : 3866949 ,
"tx_power" : 20 ,
"tx_retries" : 0 ,
"up" : true ,
"usage" : "user"
}
] ,
"version" : "3.2.10.2886"
}
kann man das auch noch irgendwie abstellen. Wie gesagt, alle 5 sekunden werden diese 6 dateien aktualisiert...
Danke
Hallo Rapster
Existieren bei Dir diese Files pro AP auch und werden in dieser Ebenfalls so fleißig aktualisiert?
Kann man das irgendwie abstellen?
Moin Mumpitz,
ja diese Files existieren bei jedem jeweils pro AccessPoint und werden denke ich vom Controller intern benötigt.
Man könnte zwar versuchen den Debug level auf den AccessPoints selber zu ändern, allerdings bezweifle ich dass dies helfen wird.
Falls hier tatsächlich soviel Schreibzugriffe passieren dass es unschön für die SD-Card wird, könntest du beim booten an diesem Pfad immer eine kleine RAM-Disk (https://wiki.ubuntuusers.de/RAM-Disk_erstellen) einhängen, da das lediglich temporäre Dateien sind und dazu nicht besonders groß.
Hallo zusammen
Bin zwar noch Anfänger was Programmierung angeht, aber ich habe folgendes vor:
Ich habe ein KNX System, Loxone für Visualisierung und Unifi AP's. Raspberry Pi ist bestellt;-)
Ich möchte gerne die Anwesenheit von mir und meiner Frau via AP' und MAC Adressen auslesen und den Status in meiner KNX Logiken weiterverwenden.
Loxone kann UDP und http abfragen machen.
Kann mir jemand sagen ob das mit diesem Script möglich ist oder nicht? Und falls ja, eine Anleitung dazu Posten? (Schritt für Schritt)
Gruss
Keve
Gesendet von iPhone mit Tapatalk
Hallo
Ich habe nun FHEM und den Controller auf dem RPI installiert und es ist connected.
Kann mir jemand weiterhelfen, in welchen files ich nun finde, wer wann online gekommen ist und wieder offline?
Steige bei dieser Presence funktion nicht ganz.. wie bringe ich diese zum laufen?
und übrigens:
Mein Logfile im Ordner /log macht pro sekunde ca. 20 Einträge.. wie kann ich das ändern??
die Angaben wer wann online gekommen ist, findest du i.M. bei den jeweiligen readings des Gerätes.
Um die Log Einträge des Controller selber zu begrenzen, findest du ein paar Seiten weiter vorne eine Lösung.
hallo zusammen,
ich hoffe es ist ok, wenn ich diesen Thread wiederbelebe.
Ich habe testweise bei mir auch einen unifi ap ac lite im Einsatz und den Controller auf einer Raspberry Pi B+ installiert. Die Controller-Version ist 5.0.7. Leider habe ich erst danach gesehen, dass dieses Modul nur bis V4 unterstützt.
Ist eine Unterstützung von v5 geplant, oder habe ich was übersehen und das funktioniert schon?
Gruß Michael
Hi,
funktioniert bei mir nach Update von v4 auf v5.
Allerdings plane ich schon länger ein feature Update, aufgrund eines größeren Projektes finde ich aber leider sogut wie keine freie Minute zurzeit :-(
Gruß Claudiu
ok, danke für die Info.
Dann scheint es einen anderen Grund zu haben, warum bei mir der Controller noch als disconnected angezeigt wird.
Im Webinterface kann ich mich einloggen, wenn ich allerdings den API-Aufruf aus dem Logfile https://192.168.1.106:8443/api/login
manuell über den Browser aufrufe, dann bekomme ich folgendes ergebnis
{ "data" : [ ] , "meta" : { "msg" : "api.err.Invalid" , "rc" : "error"}}
Leider kann ich das nicht ganz deuten. Hat da vllt. jemand ne Idee?
Gruß Michael
Die Rückmeldung ist O.K.
Du hast ja keine Zugangsdaten mitgesendet, also wird dir der login verweigert.
Kannst du ein list des devices posten?
Und verbose 5 am device einstellen und mal loggen.
hier schonmal das list:
Internals:
CFGFN
DEF 192.168.1.106 8443 admin 1234
NAME unifi_controller
NOTIFYDEV global
NR 8073
NTFY_ORDER 50-unifi
STATE disconnected
TYPE Unifi
Readings:
2016-07-14 18:59:09 state disconnected
Accespoints:
alerts_unarchived:
Clients:
events:
Httpparams:
ignoreredirects 1
loginData {"username":"admin", "password":"1234"}
loginUrl https://192.168.1.106:8443/api/login
loglevel 5
method POST
noshutdown 0
timeout 5
Hash:
Sslargs:
SSL_verify_mode 0
Unifi:
CONNECTED disconnected
eventPeriod 24
interval 30
url https://192.168.1.106:8443/api/s/default/
version 4
Updatedispatch:
Attributes:
room Anwesenheit
den rest reiche ich dann morgen nach
und hier ein Auszug aus dem Log:
2016.07.15 08:40:41 5: unifi_controller (Unifi_Login_Send) - executed.
2016.07.15 08:40:47 5: unifi_controller (Unifi_Login_Receive) - executed.
2016.07.15 08:40:47 5: unifi_controller (Unifi_Login_Receive) - Error while requesting https://192.168.1.106:8443/api/login - https://192.168.1.106:8443/api/login: Can't connect(2) to https://192.168.1.106:8443: SSL wants a read first
2016.07.15 08:40:47 5: unifi_controller (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2016.07.15 08:41:14 5: unifi_controller: set called with update
2016.07.15 08:41:14 4: unifi_controller: set update
2016.07.15 08:41:14 5: unifi_controller (Unifi_DoUpdate) - executed.
2016.07.15 08:41:14 5: unifi_controller (Unifi_Login_Send) - executed.
2016.07.15 08:41:19 5: unifi_controller (Unifi_Login_Receive) - executed.
2016.07.15 08:41:20 5: unifi_controller (Unifi_Login_Receive) - Error while requesting https://192.168.1.106:8443/api/login - https://192.168.1.106:8443/api/login: Can't connect(2) to https://192.168.1.106:8443: SSL wants a read first
2016.07.15 08:41:20 5: unifi_controller (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
ich hab die Controller-Software jetzt mal auf ne Windows-Maschine packt und konnte mich problemlos connecten.
Ich vermute dass es kein Problem von deinem Modul ist, sondern dass die Raspberry Pi zu spät antwortet und die Anfrage für den Login dann in einen Timeout läuft...
Genau das selbe Problem habe ich bei mir auch.
Webinterface läuft der Unifi 5.0.7 einwandfrei aber FHEM kann nicht connecten.
Kann das vielleicht auch an der Version liegen? Das Modul scheint ja nur v3 und v4 zu unterstützen?
Hmm, hat hier wirklich keiner eine Idee dazu? :(
Da bei mir keine Probleme bei Verwendung von 5.0.7 auftreten, kann ich es leider nicht nachstellen.
Werde in den nächsten Tagen einen anderen v4 Controller upgraden um zu sehen wie sich dessen fhem verhält.
Allerdings habe ich keinen Raspi und verwende nichts unter Debian Jessie auf dem ich es testen könnte.
Zitat von: McUles am 20 Juli 2016, 14:01:02
Hmm, hat hier wirklich keiner eine Idee dazu? :(
habe auch das Problem :-(
ich vermute Probleme mit den Zertifikaten ... bin auch schon am Testen
Gruß
der Ralf
Die Validierung der Zertifikate sollte doch eigentlich deaktiviert sein oder?
Bin gerade auf Arbeit und kann nicht nach schauen.
Gesendet von meinem iPhone mit Tapatalk
ich bin mit dem ganzen leider auch noch nicht weiter gekommen... :(
mal eine Frage an Rapter ...
ich habe im ubnt Forum gefunden, wie man den SSL für das Tomcat Framework abschaltet ...
Geht Dein Modul auch ohne https?
Dank und Gruß
Ralf
Zitat von: Wuppi68 am 26 Juli 2016, 17:42:18
Geht Dein Modul auch ohne https?
Noch nicht, dazu müsste mindestens in Zeile 89 "https://" nach "http://" geändert werden.
Würde falls das hilft kurzfristig eine Erkennung reinbauen ob für den Parameter <ip> eine volle URL incl. http angegeben wurde, oder nur IP / Hostname
Leider konnte ich das Problem noch nicht nachstellen,
evtl. liegt das daran dass ich die Unifi-Controller bei mir auf Port 443 geändert habe?
Werde es nochmal mit einem frisch aufgesetzten Controller probieren, mit 2 bereits vorhandenen 5.0.7 Controllern konnte ich das Problem bisher leider nicht reproduzieren.
was ist denn der host für deine Controller?
Bei meinem Raspberry Pi 1B kann ich mich nicht connecten. Bei nem Windows Rechner als Host hab ich keine Probleme.
Gruß Michael
Zitat von: l2r am 26 Juli 2016, 21:29:16
was ist denn der host für deine Controller?
Das funktioniert z.B.:
Unifi Host
Linux UniFi 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u1 x86_64
root@UniFi:~>cat /etc/debian_version
stretch/sid
Fhem host
Linux fhem 4.5.0-1-amd64 #1 SMP Debian 4.5.1-1 (2016-04-14) x86_64
root@fhem:~>cat /etc/debian_version
stretch/sid
root@fhem:~>perl -M'IO::Socket::SSL' -e 'print "$IO::Socket::SSL::VERSION\n"'
2.027
root@fhem:~>lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux testing-proposed-updates (sid)
Release: testing-proposed-updates
Codename: sid
sry, vllt habe ich mich missverständlich ausgedrückt.
Ich vermute, dass meine Raspberry Pi 1B einfach zu schwach ist um die Anfragen von FHEM in angemessener Zeit zu verarbeiten und ein Ergebnis zurück zu geben. Das Ergebnis ist dann der Timeout.
Was setzt du denn als Hardware ein auf der der Unifi-Controller läuft?
Gruß Michael
Ne denke nicht dass es daran liegen kann, denke ich werde mir mal ein altes Squeeze Debian wie du warscheinlich auf deinem Pi installiert hast installieren müssen und darauf mal testen.
Evtl. liegt es aber auch an einer zu alten fhem Grundlage? ssl Modul veraltet? ...
Sowohl fhem als auch die unifi VM liegen bei mir auf einem keuchenden ESXi-Host,
denke aber nicht dass es an einem Timeout liegt,
du kannst es aber mal testen im dem du die Zeile 94 des Moduls bearbeitest und fhem neustartest:
timeout => 5,
falls das klappt kann ich des default höher setzen oder per Attr editierbar machen.
hast recht, der Timeout wars nicht.
Mein Controller läuft auf ner Raspberry Pi B mit Jessie.
Gruß Michael
Hast dus mal mit meiner unifi Controller Konfig versucht?
Evtl. incl. den Portänderungen welche in dem einem Codeblock stehen auf Port 443 und 80
https://forum.fhem.de/index.php/topic,40287.msg355287.html#msg355287
https://forum.fhem.de/index.php/topic,40287.msg355312.html#msg355312
https://forum.fhem.de/index.php/topic,40287.msg355355.html#msg355355
leider kein erfolg...:-(
Hier scheint tatsächlich der RasPI der Flaschenhals zu sein. Habe jetzt den UniFi Controller mal auf meiner QNap installiert und siehe da, FHEM connected sofort darauf.
Hallo zusammen,
hat jemand schon das Modul mit dem "neuen" Unifi 5 Controller zum Laufen bekommen?
Habe es testweise mal probiert. Ergebnis: Modul wurde direkt disconnected.
Beim Schwenk zurück auf den 4er Controller war wieder alles OK.
Gruß
Jörg
Bei mir läuft es mit dem 5er Controller einwandfrei. Hab ihn jedoch auch auf meiner qnap installiert, über den raspberry lief es nicht
Gesendet von meinem iPhone mit Tapatalk
bei mir läuft Version 5.0.7 auf ner Windows-Kiste, nachdem der Controller auf ner Raspberry-Pi ebenfalls nicht lief
Hier gibts ja gar nicht so wenige die unifi nutzen.
Leider bekomme ich die 5er Version auf meiner Synology nicht zum aufen, bzw, das Webinterface streikt. sonst könnte ich sage ob das mit dem connect klappt.
Gruß
H-Man
Also funktioniert der UniFi 5 generell mit FHEM? hhhmmm... dann schaue ich noch mal. Vielleicht habe ich nicht lange genug gewartet?!?
@h-man-kl: je nachdem welche Syno du hast ein passendes Paket von http://synology.acmenet.ru/ installieren. Denn erst den alten Controller stoppen (nicht deinstallieren) und danach den neuen starten. (Vielleicht vorher noch ein Backup vom UniFi ziehen, damit du nicht alles wieder neu einrichten musst.)
So hat es auf jeden Fall bei mir ohne Probleme funktioniert.
Gruß
Jörg
ich hab die 5er auf meiner DS412+ nicht zum laufen bekommen...
Inzwischen läuft auf meiner RS815 die 5er Version und redet auch brav mit fhem.
Das einzige was ich nicht hinbekommen habe ist Wireless uplink mit der 3.7.125154er Firmware. sobald ich die betroffenen APs von 3.3.224024 uppgrade verbinden sie sich nicht mehr wireless. Aber damit kann ich leben.
Der Unifi in Version 5 luppt auch wenn er lokal auf dem RasPi mit installiert ist.
Hierfür muss nur eine andere Java Version installiert werden:
http://www.lowefamily.com.au/2016/06/02/installing-ubiquiti-unifi-controller-5-on-raspberry-pi/3/ --> Oracle Java 8 (Optional)
Danach bekomme ich reproduzierbar den Connect hin und alles läuft wie gewünscht, läuft er auf OpenJDK 7 (default) oder 8, dann nicht.
Hallo,
habe mir mal, nachdem ich zum 5er Controller auf dem Cubietruck (auf dem auch FHEM läuft) keinen Connect hinbekam den Unifi Cloud Key zugelegt.
Funktioniert mit FHEM auf Anhieb, und ist ne Ecke schneller als auf'm Cubietruck. Zudem bleibt der Cubietruck jetzt 2°C kühler ;)
Bin sehr zufrieden mit dem Teil.
Andreas
kurze Rückmeldung:
bei mir läuft nun auch die ganz aktuelle 5er Version auf der Syno und alle APs sind aktualisiert worden
Gruß
H-Man
Hallo,
danke für das Modul hat meine presence Erkennung wesentlich verbessert. Kann auch bestätigen das es mit V5.2.9 läuft.
Ich hätte noch zwei Vorschläge zur Erweiterung:
- Gast Netze ein/aus schalten (Die Freunde meiner Kinder wären dir ewig dankbar)
- AP einzeln abschalten (Meine Kinder wären dir vielleicht nicht so dankbar)
Ist eine Erweiterung geplant?
Auf den access points läuft ja BusyBox habe ich mit ssh gesehen, da könnte man glatt auch noch was mit machen ::)
Gruß
Eisix
Du könntest doch die Geräte deiner Kidds Abends einfach blocken und morgens wieder unblocken oder temporär über Nacht das Passwort des WLANs ändern lassen ;)
Hallo zusammen,
habe ne Frage:
Ich habe gerade mein Fhem vom RPi2 aufs QNAP umgezogen. Dort habe ich eine VM laufen mit Ubuntu 16.04 LTS. Nun möchte ich da den Unifi-Controller installieren. Nun ergeben sich folgende Fragen:
- Welche Version kann/sollte ich nehmen? AUf dem Pi2 hatte ich 4.x!
- Welche Version des MongoDB sollte/muss ich nehmen? Ich habe irgendwo gelesen, dass man MongoDB in Version 2 nehmen sollte, diese habe ich aber nicht für Ubuntu 16.04 gefunden
Vielen Dank für Eure Hilfe!
Hi Michi240281,
wenn du sowieso schon einen Hypervisor einsetzt, dann würde ich auch den UniFi-Controller in einer einzelnen VM laufen lassen.
Benötigt kaum Ressourcen und du bist viel flexibler. 8)
Warum?
Stell dir vor, du zerschießt dir deine FHEM-Installation (aus welchen Gründen auch immer) und musst die VM neu aufsetzen.
Dann ist auch automatisch dein WLAN offline.
Nicht wirklich prickelnd, wenn der Rest der Familie Sturm läuft weil die nicht mehr ins Internet kommen :o
Da gibt es auch schon fertige Images, die man direkt importieren kann - kurze Recherche bei Google hilft ziemlich schnell.
Gruß
Jörg
Zitat von: Ghostchaser am 31 Oktober 2016, 12:37:11Warum?
Stell dir vor, du zerschießt dir deine FHEM-Installation (aus welchen Gründen auch immer) und musst die VM neu aufsetzen.
Dann ist auch automatisch dein WLAN offline.
Nicht wirklich prickelnd, wenn der Rest der Familie Sturm läuft weil die nicht mehr ins Internet kommen :o
Die APs funken auch ohne laufende Controller SW, diese ermöglicht nur Statistikfunktionen und sonstige Annehmlichkeiten.
Hallo,
ich habe eben mal das Unifi Modul bei mir ausprobiert. Der Unifi Controller läuft bei mir auf einer Synology in der Version V5.29.
Leider connected sich das Modul nicht, obwohl der Login zum Controller übers Web funktioniert. Anbei die Fehlermeldung.
Hat jemand eine Idee warum die SSL Kommunikation scheitert? Kann man auch non-SSL erzwingen?
2016.11.02 10:45:05 5: UnifiWohnzimmer (Unifi_DoUpdate) - executed.
2016.11.02 10:45:05 5: UnifiWohnzimmer (Unifi_Login_Send) - executed.
2016.11.02 10:45:05 5: UnifiWohnzimmer (Unifi_Login_Receive) - executed.
2016.11.02 10:45:05 5: UnifiWohnzimmer (Unifi_Login_Receive) - Error while requesting https://192.168.0.71:8443/api/login - https://192.168.0.71:8443/api/login: Can't connect(2) to https://192.168.0.71:8443: SSL connect attempt failed error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure SSL connect attempt failed error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
2016.11.02 10:45:05 5: UnifiWohnzimmer (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
Vielen Dank!
Hallo Thargor,
leider kann ich dir nicht sagen warum es über ssl nicht geht. Auch wenn es dir jetztz wenig hilft, eigentlich müsste es gehen, denn deine Konstellation habe ich auc ud da lief es ohne irgendwelche Sonderanpassungen....
Mal noch eine Frage an die Allgemeinheit:
Weiß zufällig jemand ob man beim Unif-Switch (im Konkreten Fall den 48port PoE) einen Port via fhem abschalten kann? So könnte ich bei Abwesenheit die APs abschalten :-)
Dankefein.
Zitat von: Eisix am 24 Oktober 2016, 16:30:47
Ich hätte noch zwei Vorschläge zur Erweiterung:
- Gast Netze ein/aus schalten (Die Freunde meiner Kinder wären dir ewig dankbar)
- AP einzeln abschalten (Meine Kinder wären dir vielleicht nicht so dankbar)
Da ich das Ein/Ausschalten von SSID's/AP's eigtl. schon eingebaut habe, versuche ich zumindest die Version im laufe der Woche einzuchecken.
@Thargor, das Problem scheint die Linux-Büchse deiner Fhem Installation zu sein.
Du kannst versuchen ein dist-upgrade zu machen, um die ssl-libs auf der fhem-Maschine auf den aktuellen Stand zu bringen.
Evtl. Versionen Vergleichen mit Leuten bei denen Unify ebenfalls auf Sinology installiert ist.
Top!
Melde mich zum testen.
Gruß
Eisix
Hallo,
ich überlege mir 1-2 Unifi AC EDU AP zu kaufen.
Das sind die mit eingebautem Lautsprecher.
Ist es möglich diese zB. für Alarmanlagen oder Türklingel zu nutzen?
Hallo,
in der Theorie denke ich das du von Musik bis Türklingel alles abspielen kannst. Die Frage ist eher wie du das ganze überträgst. Diese Modul unterstützt es soweit ich das sehe bis jetzt nicht. Bleibt nur die Hersteller Software.
Vermute mal du hattest an eine volle integration in Fhem gedacht.
Gruß
Eisix
Wenn man Musik oder ein auf dem AP abgelegtes mp3 File über den Unifi-Controller abspielen kann, dann lässt sich das auch in dieses Modul integrieren.
Broadcast geht mit der Controller Software. Laut Anleitung werden dort Broadcastgruppen angelegt. Ich habe aber nichts gefunden was die Audio Quelle ist (Mikrofon, mp3file, ...).
Man muss wohl auch einen EDU AP haben um die Funktionalität zu sehen.
Gruß
Eisix
Erst mal danke für die Antworten.
Ja würde die AP dann gerne für das Alarmmodul nutzen.
Zu mindestens scheint es ja nicht ausgeschlossen zu sein.
Konnte bisher auch nur herausfinden das man wohl über die Android App entweder gespeicherte MP3 abspielen kann oder einfach was ins Mikrofon reden.
Denke die gleiche Funktion wird der Unifi-Controller anbieten.
Leider sind die Teile recht teuer um mal auf verdacht zu kaufen.
Kannst ja einfach mal eine Mail an die schreiben, denke das du eine Antwort bekommen solltest ;)
Gesendet von iPhone mit Tapatalk
Das mit den Lautsprechern im AP klingt echt sehr interessant!
Kann evtl. noch jemand was zu meiner Frage bzgl. der Ports am Unifi switch sagen? Das wäre für mich klasse!
Gruß
H-Man
Zitat von: rapster am 07 November 2016, 18:00:34
Da ich das Ein/Ausschalten von SSID's/AP's eigtl. schon eingebaut habe, versuche ich zumindest die Version im laufe der Woche einzuchecken.
Meine Kinder werden Dich hassen, meine Frau wird Dich ... (vergiß es ;))
-teddy
Im Anhang ist eine Version in der mit
set <unifi> disableSsid <ap_freq_ssid>
die einzelnen ssids ausgeschaltet werden können.
Um das ganze zurückzusetzen können i.M. die overrides des AP's wieder gelöscht werden:
set <unifi> clearOverrides <apName>
Achtung, nach absenden einer dieser Befehle macht der entsprechende Accesspoint ein Provisioning (reboot).
Werde noch das einzelne aktivieren einbauen und filtern ob Overrides überhaupt gesetzt sind.
Desweiteren in dieser Version:
- Attribut devAlias ist jetzt textField-long (Multiline)
- -AP_<Accesspoint>_essid reading unterscheidet nun zwischen 2G und 5G
Hallo,
habe mal getestet.
Ich habe eine Standard SSID, eine Gäste SSID und drei AP (2.4, 5 aktiv)
Gäste SSID war aus und wurde nach dem Neustart über Webinterface aktiviert. Wie lange dauert es bis die SSID in der Fhem Liste erscheint? Nach einem fhem Neustart waren beide SSIDs von allen Frequenzen und APs sichtbar. Hängt das mit dem reboot der APs zusammen !?
clearOverrides hat nicht zurückgesetzt. Ich mußte im Webinterface ein reset to defaults machen. Werde ich aber nochmal probieren.
Im Log habe ich nach dem fhem Restart noch zwei Meldungen
2016.11.15 11:46:27 1: PERL WARNING: Odd number of elements in anonymous hash at ./FHEM/74_Unifi.pm line 894.
2016.11.15 11:46:27 1: PERL WARNING: Odd number of elements in anonymous hash at ./FHEM/74_Unifi.pm line 1070.
Gruß
Eisix
Die SSID Liste in Fhem wird bei jedem Modul-Update aktualisiert (Beim Start und in dem konfigurierten Update-Intervall).
Damit in FHEMWEB allerdings die SSIDs, APs, usw. aus der select-Liste aktualisiert werden, muss der Browser mit F5 neu geladen werden.
Bzw. wenn ein reading kein Event auslöst ist ebenfalls F5 notwendig um es zu aktualisieren.
clearOverrides sollte funktionieren, habe ich gerade nochmal ausprobiert. (Es muss der richtige AP gewählt sein)
i.M. wird allerdings (noch) nicht geprüft ob der Befehl erfolgreich vom AP angenommen wurde, bzw. der AP überhaupt erreichbar ist (nur ob der controller den Befehl erfolgreich empfangen hat), deswegen muss gewartet werden bis der entsprechende AP wieder state=ok hat.
Im Anhang eine Version ohne die zwei Perl Meldungen.
Gruß
Log Einträge sind weg.
Denke ich habe jetzt rausgefunden was passiert.
Ich habe auf 1 AP die 2G-Gast-SSID abgeschaltet, provisioning läuft durch alles korrekt abgeschaltet. Nun wollte ich die 5G-Gast-SSID abschalten. Provisioning läuft durch, 5G-Gast abgeschaltet, 2G-Gast wieder an. Der override vom ersten Abschalten wird durch das zweite provisioning wieder zurückgesetzt. In der jetzigen Form kann man also nur einen Override pro AP setzen. Kannst du das reproduzieren?
Gruß
Eisix
Super dann klappt das soweit schonmal :-)
Ja, viel mitdenken tun die neuen Funktionen bisher leider noch nicht.
Im Anhang eine Version in der zumindest schonmal mehrere SSID's pro AP auf einmal deaktiviert werden können.
> Das funktioniert i.M. nur konsistent wenn am AP keine Overrides gesetzt sind (evtl. vor disableSsid ein clearOverrides schicken)
In der nächsten Version gibt es dann den neuen setter "enableSsid" mit welchem dann einzeln SSIDs zu und per disableSsid abgeschaltet werden können :)
Wäre es nicht sinnvoller 1 SSID auf allen Frequenzen pro AP abschalten zu können?
Oder generell SSID abschalten zu können wie bei "settings -> Wireless Networks -> edit -> Enable Wireless Network
Sinnvoll ist es :-)
Über die Funktion (enable this wireless network) welche der Controller in den Settings anbietet, ist es ziemlich schwierig zu implementieren, auch habe ich bedenken dass es hier nicht sehr update-stabil sein wird.
Vorteile sehe ich keine, werde das selber im Modul einbauen, das Verhalten & Ergebniss sollte das selbe sein, auch wenn es der Controller intern auf ein andres Stück Papier notiert :)
Denke da zusätzlich an das
disableSsid <AP>_ALL_<SSID>
disableSsid ALL_ALL_<SSID>
disableSsid ALL_2G|5G_<SSID>
disableSsid ALL_ALL_ALL
disableSsid ALL_2G|5G_ALL
Wie ist mir eigentlich egal. Gibt halt ne Riesen Liste mit mehreren APs und SSIDs. ;)
Wäre auch nicht schlecht wenn man ein Passwort setzen/ändern könnte. Entweder SSID oder simple Passwort bei gehst wlan.
Weitere halbgare Version für Testwillige ;)
disableSsid sollte schonmal komplett funktionieren. (ohne die Notwendigkeit von clearOverrides)
enableSsid zeigt zwar schon ausgeschaltete SSIDs an, ist aber noch ohne Funktion, wieder Einschalten i.M. über clearOverrides am AP.
Edit: PW ändern könnte einfach sein, kann ich mir mal anschauen.
Ergibt über 30 Kombinationen um SSIDs abzuschalten. Mein Bildschirm wird zu klein. Wenn ich eine SSID auf einem AP abschalten will werden alle SSIDs abgeschaltet. Da stimmt was nicht. Das gleiche als ich 1 SSID auf allen APs abschalten wollte, alle SSIDs aus.
Hallo Zusammen,
habe seit kurzem Unifi im Betrieb und bin mit der Funktion für mich zufrieden.
Ich habe im Log jedoch dieses Verhalten festgestellt: (Vers. 74_Unifi.pm 11990 2016-08-19 18:11:24Z)
2016.11.20 02:19:07 1: Perfmon: possible freeze starting at 02:19:06, delay is 1.491
2016.11.20 02:19:35 1: Perfmon: possible freeze starting at 02:19:34, delay is 1.194
2016.11.20 02:19:38 1: Perfmon: possible freeze starting at 02:19:37, delay is 1.194
2016.11.20 02:19:41 1: Perfmon: possible freeze starting at 02:19:40, delay is 1.183
2016.11.20 02:20:04 1: Perfmon: possible freeze starting at 02:20:03, delay is 1.437
2016.11.20 02:20:09 1: Perfmon: possible freeze starting at 02:20:08, delay is 1.045
2016.11.20 02:20:12 1: Perfmon: possible freeze starting at 02:20:11, delay is 1.038
2016.11.20 02:20:35 1: Perfmon: possible freeze starting at 02:20:34, delay is 1.139
2016.11.20 02:20:38 1: Perfmon: possible freeze starting at 02:20:37, delay is 1.144
2016.11.20 02:20:41 1: Perfmon: possible freeze starting at 02:20:40, delay is 1.124
2016.11.20 02:21:06 1: Perfmon: possible freeze starting at 02:21:05, delay is 1.018
2016.11.20 02:21:09 1: Perfmon: possible freeze starting at 02:21:08, delay is 1.103
2016.11.20 02:21:32 1: Perfmon: possible freeze starting at 02:21:31, delay is 1.437
2016.11.20 02:21:35 1: Perfmon: possible freeze starting at 02:21:34, delay is 1.4
2016.11.20 02:21:38 1: Perfmon: possible freeze starting at 02:21:37, delay is 1.434
Ist dieses bei Euch auch normal?
Gibt es eine Möglichkeit dieses abzustellen oder ist es ein Bug?
Sobald ich die Definition: "define myunifi Unifi 192.168.1.180 8443 xxx yyy 30 default 4" deaktiviere, verschwinden auch die freezes.
Viele Grüße,
Chris
Mach mal bitte ein "attr myunifi verbose 5" und schau mal ob in den Log etwas aussagekräftigeres zu sehen ist.
Hmm.. ich bekomme da natürlich viel mehr Meldungen. Auffällig sind für mich die ProcessUpdates, welche mehr als 10 Sekunden dauern wobei ich nicht weiß, ob es normale Werte sind oder nicht.
Erkennst Du an der Stelle etwas?
2016.11.20 12:20:31 1: Perfmon: possible freeze starting at 12:20:30, delay is 1.121
2016.11.20 12:20:31 5: myunifi (Unifi_GetClients_Receive) - executed.
2016.11.20 12:20:31 5: myunifi (Unifi_GetClients_Receive) - state:'ok'
2016.11.20 12:20:31 5: myunifi (Unifi_ProcessUpdate) - executed after 10.9215 seconds.
2016.11.20 12:20:31 5: myunifi (Unifi_SetHealthReadings) - executed.
2016.11.20 12:20:31 5: myunifi (Unifi_SetClientReadings) - executed.
2016.11.20 12:20:31 5: myunifi (Unifi_SetAccesspointReadings) - executed.
2016.11.20 12:20:31 5: myunifi (Unifi_ProcessUpdate) - finished after 10.9546 seconds.
2016.11.20 12:20:43 5: myunifi (Unifi_DoUpdate) - executed.
2016.11.20 12:20:43 5: myunifi (Unifi_GetEvents_Send) - executed.
2016.11.20 12:20:45 1: Perfmon: possible freeze starting at 12:20:44, delay is 1.058
2016.11.20 12:20:45 5: myunifi (Unifi_GetEvents_Receive) - executed.
2016.11.20 12:20:45 5: myunifi (Unifi_GetEvents_Receive) - state:'ok'
2016.11.20 12:20:45 5: myunifi (Unifi_GetWlans_Send) - executed.
2016.11.20 12:20:46 5: myunifi (Unifi_GetWlans_Receive) - executed.
2016.11.20 12:20:46 5: myunifi (Unifi_GetWlans_Receive) - state:'ok'
2016.11.20 12:20:46 5: myunifi (Unifi_GetAccesspoints_Send) - executed.
2016.11.20 12:20:48 1: Perfmon: possible freeze starting at 12:20:47, delay is 1.236
2016.11.20 12:20:48 5: myunifi (Unifi_GetAccesspoints_Receive) - executed.
2016.11.20 12:20:48 5: myunifi (Unifi_GetAccesspoints_Receive) - state:'ok'
2016.11.20 12:20:48 5: myunifi (Unifi_GetHealth_Send) - executed.
2016.11.20 12:20:49 5: myunifi (Unifi_GetHealth_Receive) - executed.
2016.11.20 12:20:49 5: myunifi (Unifi_GetHealth_Receive) - state:'ok'
2016.11.20 12:20:49 5: myunifi (Unifi_GetClients_Send) - executed.
2016.11.20 12:20:51 1: Perfmon: possible freeze starting at 12:20:50, delay is 1.244
2016.11.20 12:20:51 5: myunifi (Unifi_DoUpdate) - executed.
2016.11.20 12:20:51 5: myunifi (Unifi_GetAccesspoints_Send) - executed.
2016.11.20 12:20:52 5: myunifi (Unifi_GetClients_Receive) - executed.
2016.11.20 12:20:52 5: myunifi (Unifi_GetClients_Receive) - state:'ok'
2016.11.20 12:20:52 5: myunifi (Unifi_GetUnarchivedAlerts_Send) - executed.
2016.11.20 12:20:54 1: Perfmon: possible freeze starting at 12:20:53, delay is 1.166
2016.11.20 12:20:54 5: myunifi (Unifi_GetAccesspoints_Receive) - executed.
2016.11.20 12:20:54 5: myunifi (Unifi_GetAccesspoints_Receive) - state:'ok'
2016.11.20 12:20:54 5: myunifi (Unifi_GetHealth_Send) - executed.
2016.11.20 12:20:55 5: myunifi (Unifi_GetUnarchivedAlerts_Receive) - executed.
2016.11.20 12:20:55 5: myunifi (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2016.11.20 12:20:55 5: myunifi (Unifi_ProcessUpdate) - executed after 12.0988 seconds.
2016.11.20 12:20:55 5: myunifi (Unifi_SetHealthReadings) - executed.
2016.11.20 12:20:55 5: myunifi (Unifi_SetClientReadings) - executed.
2016.11.20 12:20:55 5: myunifi (Unifi_SetAccesspointReadings) - executed.
2016.11.20 12:20:55 5: myunifi (Unifi_ProcessUpdate) - finished after 12.1104 seconds.
2016.11.20 12:20:55 5: myunifi (Unifi_GetHealth_Receive) - executed.
2016.11.20 12:20:55 5: myunifi (Unifi_GetHealth_Receive) - state:'ok'
2016.11.20 12:20:55 5: myunifi (Unifi_GetUnarchivedAlerts_Send) - executed.
2016.11.20 12:20:57 1: Perfmon: possible freeze starting at 12:20:56, delay is 1.11
2016.11.20 12:20:57 5: myunifi (Unifi_GetUnarchivedAlerts_Receive) - executed.
2016.11.20 12:20:57 5: myunifi (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2016.11.20 12:20:57 5: myunifi (Unifi_GetClients_Send) - executed.
2016.11.20 12:20:58 5: myunifi (Unifi_GetClients_Receive) - executed.
2016.11.20 12:20:58 5: myunifi (Unifi_GetClients_Receive) - state:'ok'
2016.11.20 12:20:58 5: myunifi (Unifi_GetEvents_Send) - executed.
2016.11.20 12:21:00 1: Perfmon: possible freeze starting at 12:20:59, delay is 1.071
2016.11.20 12:21:00 5: myunifi (Unifi_GetEvents_Receive) - executed.
2016.11.20 12:21:00 5: myunifi (Unifi_GetEvents_Receive) - state:'ok'
2016.11.20 12:21:00 5: myunifi (Unifi_GetWlans_Send) - executed.
2016.11.20 12:21:01 5: myunifi (Unifi_GetWlans_Receive) - executed.
2016.11.20 12:21:01 5: myunifi (Unifi_GetWlans_Receive) - state:'ok'
2016.11.20 12:21:01 5: myunifi (Unifi_ProcessUpdate) - executed after 10.5583 seconds.
2016.11.20 12:21:01 5: myunifi (Unifi_SetHealthReadings) - executed.
2016.11.20 12:21:01 5: myunifi (Unifi_SetClientReadings) - executed.
2016.11.20 12:21:01 5: myunifi (Unifi_SetAccesspointReadings) - executed.
2016.11.20 12:21:01 5: myunifi (Unifi_ProcessUpdate) - finished after 10.5985 seconds.
2016.11.20 12:21:15 5: myunifi (Unifi_DoUpdate) - executed.
2016.11.20 12:21:15 5: myunifi (Unifi_GetClients_Send) - executed.
2016.11.20 12:21:17 1: Perfmon: possible freeze starting at 12:21:16, delay is 1.153
2016.11.20 12:21:17 5: myunifi (Unifi_GetClients_Receive) - executed.
2016.11.20 12:21:17 5: myunifi (Unifi_GetClients_Receive) - state:'ok'
2016.11.20 12:21:17 5: myunifi (Unifi_GetUnarchivedAlerts_Send) - executed.
2016.11.20 12:21:18 5: myunifi (Unifi_GetUnarchivedAlerts_Receive) - executed.
2016.11.20 12:21:18 5: myunifi (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2016.11.20 12:21:18 5: myunifi (Unifi_GetAccesspoints_Send) - executed.
2016.11.20 12:21:20 1: Perfmon: possible freeze starting at 12:21:19, delay is 1.104
2016.11.20 12:21:20 5: myunifi (Unifi_GetAccesspoints_Receive) - executed.
2016.11.20 12:21:20 5: myunifi (Unifi_GetAccesspoints_Receive) - state:'ok'
2016.11.20 12:21:20 5: myunifi (Unifi_GetHealth_Send) - executed.
Ich bin mir nicht sicher woran das liegt, auf was fuer einer HW ist fhem und der controller installiert?
Die Abfragen an den Controller dauern extrem lange, bei dir knappe 11 Sekunden, irgendwas stimmt da nicht.
Habe es nie auf langsamer HW getestet, auf meinem System aber immer zweistellige ms Zeiten gehabt.
Beides läuft auf dem gleichen Raspberry pi 2 Model B.
Auf welcher H/W läufts bei Dir?
normale pc, kein ARM :)
Probier mal ob es was bringt wenn du statt der externen IP 192.168.1.180 die Loopback 127.0.0.1 bei der Fhem-Definition verwendest.
Wie schauts mit der Auslastung des Pi aus?
Hast du die Unifi-Controller Optimierungen einige Seiten weiter vorne durchgeführt, damit der Controller nicht mehr das Log fluted?
Ja, das gleiche Verhalten auch bei der Loopback Adresse.
Ich habe eben mit top die Auslastung überprüft:
top - 19:32:08 up 7 min, 1 user, load average: 0.43, 0.35, 0.19
Tasks: 113 total, 2 running, 111 sleeping, 0 stopped, 0 zombie
%Cpu(s): 25.8 us, 0.8 sy, 0.0 ni, 73.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 947736 total, 437596 used, 510140 free, 21500 buffers
KiB Swap: 0 total, 0 used, 0 free. 191800 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
583 root 20 0 1269460 84940 13720 S 85.0 9.0 2:27.89 java
446 fhem 20 0 46412 41172 6072 S 18.2 4.3 0:33.07 perl
738 pi 20 0 5112 2496 2140 R 0.7 0.3 0:03.03 top
546 pi 20 0 141252 39004 17712 S 0.3 4.1 0:06.89 homebridge
561 snmp 20 0 12796 5280 3608 S 0.3 0.6 0:00.77 snmpd
610 pi 20 0 11480 3336 2728 S 0.3 0.4 0:00.15 sshd
643 root 20 0 250320 96932 65500 S 0.3 10.2 0:04.18 mongod
918 root 20 0 0 0 0 S 0.3 0.0 0:00.01 kworker/u8+
1 root 20 0 5424 3788 2728 S 0.0 0.4 0:05.75 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:00.03 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:+
6 root 20 0 0 0 0 S 0.0 0.0 0:00.07 kworker/u8+
7 root 20 0 0 0 0 R 0.0 0.0 0:00.31 rcu_sched
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
9 root rt 0 0 0 0 S 0.0 0.0 0:00.01 migration/0
10 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/1
Hier schwankt Java allerdings zwischen 1% und 88%...
Optimierungen am Unifi controller habe ich noch nicht vorgenommen. Ich werde mal ein paar Seiten zurückblättern und mal schauen was es zu optimieren gibt
Edit:
habe auf page 12 den vorgeschlagenen Eintrag:
debug.device=warn
debug.mgmt=warn
debug.system=warn
in der /var/lib/unifi/system.properties vorgenommen, leider ohne Änderung :-(
ichhabe das gleiche Problem ....
auch diese ständigen freezes.
Habe meinen unibi controller auf einem anderen Rechner
und die unifi in meine 2. FHEM Instansz ausgelagert
beides keinen Erfolg ...
Ich vermute, da Perl nur single threaded ist ist igendwann bei größeren Installationen auf 1GHz Kisten Ende
Wenn noch Informationen zum Performancetracking gebraucht werden... nen Profiler z.B nytprof kann ein Freund werden ...
Liebe Grüße
Ralf
Zunächst einmal Danke für das Klasse Modul. Hat mich gefreut, als ich gemerkt habe, dass fhem mal wieder etwas mehr zusammenführen kann. :)
Bei mir gibt es leider auch Performance-Probleme. Habe auf einem frischen raspi 3 sowohl fhem als auch unifi-controller
(nach http://www.lowefamily.com.au/2016/06/02/installing-ubiquiti-unifi-controller-5-on-raspberry-pi/3/)
installiert. Alles in aktuellster Version. Alle 30 Sekunden (=gesetztes refresh-Intervall im myunifi) geht der raspi in die Knie.
Wenn ich myunifi disable läuft alles wie es soll.
Ich schaue mir die nächsten Tage nochmal an, ob ich da irgendetwas finden kann und berichte dann, freue mich aber auch auf Vorschläge ;)
Endlich dazu gekommen. Logging von unifi in der system.properties auf debug gestellt und in fhem verbose=5 und HttpLoglevel=5 gesetzt. Wobei der HttpLoglevel keine Ausgaben der HttpUtils hervorgerufen hat :(
Fhem.log
2016.11.27 12:07:51 5: Unifi (Unifi_DoUpdate) - executed.
2016.11.27 12:07:51 5: Unifi (Unifi_GetHealth_Send) - executed.
2016.11.27 12:07:53 5: Unifi (Unifi_GetHealth_Receive) - executed.
2016.11.27 12:07:53 5: Unifi (Unifi_GetHealth_Receive) - state:'ok'
2016.11.27 12:07:53 5: Unifi (Unifi_GetClients_Send) - executed.
2016.11.27 12:07:55 5: Unifi (Unifi_GetClients_Receive) - executed.
2016.11.27 12:07:55 5: Unifi (Unifi_GetClients_Receive) - state:'ok'
2016.11.27 12:07:55 5: Unifi (Unifi_GetEvents_Send) - executed.
2016.11.27 12:07:56 5: Unifi (Unifi_GetEvents_Receive) - executed.
2016.11.27 12:07:56 5: Unifi (Unifi_GetEvents_Receive) - state:'ok'
2016.11.27 12:07:57 5: Unifi (Unifi_GetWlans_Send) - executed.
2016.11.27 12:07:58 5: Unifi (Unifi_GetWlans_Receive) - executed.
2016.11.27 12:07:58 5: Unifi (Unifi_GetWlans_Receive) - state:'ok'
2016.11.27 12:07:58 5: Unifi (Unifi_GetUnarchivedAlerts_Send) - executed.
2016.11.27 12:08:00 5: Unifi (Unifi_GetUnarchivedAlerts_Receive) - executed.
2016.11.27 12:08:00 5: Unifi (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2016.11.27 12:08:00 5: Unifi (Unifi_GetAccesspoints_Send) - executed.
2016.11.27 12:08:02 5: Unifi (Unifi_GetAccesspoints_Receive) - executed.
2016.11.27 12:08:02 5: Unifi (Unifi_GetAccesspoints_Receive) - state:'ok'
2016.11.27 12:08:02 5: Unifi (Unifi_ProcessUpdate) - executed after 10.8838 seconds.
2016.11.27 12:08:02 5: Unifi (Unifi_SetHealthReadings) - executed.
2016.11.27 12:08:02 5: Unifi (Unifi_SetClientReadings) - executed.
2016.11.27 12:08:02 5: Unifi (Unifi_SetAccesspointReadings) - executed.
2016.11.27 12:08:02 5: Unifi (Unifi_ProcessUpdate) - finished after 10.9122 seconds.
Server.log des unifi-controllers:
[2016-11-27 12:07:51,620] <check-network-interfaces> DEBUG system - Interfaces: [{ "ip" : "192.x.y.z" , "name" : "eth0"}]
[2016-11-27 12:07:52,522] <inform-8> DEBUG inform - Inform [44:dd:ee:bb:00:44] ip=192.x.y.a {
[2016-11-27 12:07:52,523] <inform-8> INFO inform - from [44:dd:ee:bb:00:44](UAP_WZ, BZ2, 3.7.21.5389): state=CONNECTED, ext/stun_ip=192.x.y.c, dev_ip=192.168.178.74, up=303276
[2016-11-27 12:07:52,540] <inform-8> DEBUG inform - } Inform finished (18 handling)
[2016-11-27 12:07:52,554] <inform_stat-2> DEBUG uap - uplink: eth0
[2016-11-27 12:07:52,572] <inform_stat-2> DEBUG uap - [sta seen] 33:dd:ee:bb:00:cc (ng-user , iPhone1, myWLAN) up=84658
[2016-11-27 12:07:52,575] <inform_stat-2> DEBUG uap - [sta seen] 33:dd:ee:bb:00:bb (ng-user , HHub, myWLAN) up=177359
[2016-11-27 12:07:52,577] <inform_stat-2> DEBUG uap - [sta seen] 33:dd:ee:bb:00:aa(ng-user , null, myWLAN) up=301163
[2016-11-27 12:07:53,426] <webapi-22> DEBUG api - /api/s/default/stat/health finished (15 handling, 2 rendering)
[2016-11-27 12:07:55,148] <webapi-23> DEBUG api - /api/s/default/stat/sta finished (2 handling, 5 rendering)
[2016-11-27 12:07:56,987] <webapi-24> DEBUG api - /api/s/default/stat/event finished (27 handling, 76 rendering)
[2016-11-27 12:07:58,842] <webapi-25> DEBUG api - /api/s/default/list/wlanconf finished (7 handling, 3 rendering)
[2016-11-27 12:07:59,628] <inform-9> DEBUG inform - Inform [44:dd:ee:bb:00:22] ip=192.x.y.z {
[2016-11-27 12:07:59,629] <inform-9> INFO inform - from [44:dd:ee:bb:00:22](UAP_SZ, BZ2, 3.7.21.5389): state=CONNECTED, ext/stun_ip=192.x.y.d, dev_ip=192.168.178.75, up=303779
[2016-11-27 12:07:59,659] <inform-9> DEBUG inform - } Inform finished (32 handling)
[2016-11-27 12:07:59,669] <inform_stat-3> DEBUG uap - uplink: eth0
[2016-11-27 12:08:00,573] <webapi-26> DEBUG api - /api/s/default/list/alarm finished (6 handling, 2 rendering)
[2016-11-27 12:08:01,623] <devmgr> DEBUG system - mac[44:dd:ee:bb:00:44], last_seen=1480244872, state=1(CONNECTED)
[2016-11-27 12:08:01,624] <devmgr> DEBUG system - mac[44:dd:ee:bb:00:55], last_seen=1480244867, state=1(CONNECTED)
[2016-11-27 12:08:01,624] <devmgr> DEBUG system - mac[44:dd:ee:bb:00:22], last_seen=1480244879, state=1(CONNECTED)
[2016-11-27 12:08:02,448] <webapi-27> DEBUG api - /api/s/default/stat/device finished (25 handling, 14 rendering)
Wenn ich mir die Logs ansehe, scheint die Zeit beim Abfragen der Unifi-API liegen zu bleiben. Wenn ich die API-Url direkt im Browser eingebe bekomme ich quasi sofort das entsprechende Antwort.json. In den Funktione GetXXXX_Send wird HttpUtils_NonblockingGet() aufgerufen. Diese Funktion habe ich noch nicht durchschaut. So viel erstmal zu meiner bisherigen Analyse.
Btw: Gibt es eigentlich ein FHEM-Modul , dass Events durch parsen eines Logfiles erzeugt. Aktuell interessiert mich von Unifi nur, welcher Client sich wann connected und das steht im server.log von unifi.
@Wuehler: CustomReadings erlaubt parsen eines Logfiles
@Rapster: Hattes du einen Weg gefunden das Passwort zu ändern?
Gruß
Eisix
Ich glaube Passwort ändern habe ich mir bereits mal angeschaut und sollte machbar sein, allerdings finde ich im Moment keine ruhigen Minuten um mir Gedanken darüber zu machen.
Evtl. ist es nach Weihnachten etwas ruhiger :)
Zitat von: Wuehler am 27 November 2016, 13:42:52
Btw: Gibt es eigentlich ein FHEM-Modul , dass Events durch parsen eines Logfiles erzeugt. Aktuell interessiert mich von Unifi nur, welcher Client sich wann connected und das steht im server.log von unifi.
Für die uptime eines Geräts gibt es doch bereits das _uptime reading?
Bei Bedarf kann ich noch ein reading mit dem Timestamp des connects anbieten (timestamp von uptime=0)
Was is der Anwendungsfall hierfür?
Danke für die Antworten. Das mit dem Log auslesen war im Grunde nur eine blöde Idee, die beim Schreiben gekommen ist.
Ich habe gestern eine für mich erstmal brauchbare Lösung gefunden indem ich im Unifi-Modul in doUpdate() den Aufruf aller Methoden ausser GetClients() auskommentiert habe. Die anderen Readings benötige ich aktuell noch nicht. Damit ist der RasPi nur sehr kurzzeitig recht ausgelastet.
Zwei mögliche Gründe für die Performance-Probleme:
1. Der Unifi-Controller und FHEM laufen auf demselben RasPi
2. Wenn ich es richtig sehe wird V5 des Unifi-Controllers noch nicht unterstützt. Diese habe ich aber installiert.
@Wuehler
zu 2. Wenn du dir die älteren messages dieses Thread durchlesen würdest, würdest du sehen das die V5 funktioniert ;)
Kann auch bestätigen das es mit V5.2.9 läuft.
Gruß
Eisix
@rapster: keinen Stress mit dem PW
Kann bestätigen das Controller v5.3.8.2 läuft.
Gruß
Eisix
Guten Morgen,
kann auch die Funktionalität mit 5.3.8 bestätigen. 8)
Gruß
Jörg
Hallo,
bin gerade durch Zufall auf dieses Modul gestoßen.
Vielen Dank dafür, funktioniert ja genial!
Eine Frage hätte ich aber: in den Readings für meinen AP und mein USG habe ich ein Minus, weswegen ich die nicht weiterverabeiten kann (z.B. stateformat).
siehe: -AP_OfficeAP_clients
WIe kann ich das denn ändern, bzw. ist das ein Fehler in meinem Controller, oder im Modul?
Hi,
nein das - ist i.M. Absicht wegen der Sortierung der Readings :-)
Was genau funktioniert wegen dem - nicht? Bisher sind mir da noch keine Probleme begenet..
Sorry, mein Fehler, alles gut :-[
Ah OK, du solltest auf alle Fälle die Perl Schreibweise verwenden können:
attr Unifi stateFormat {ReadingsVal($name,'-UC_events','')}
Danke, hatte eine Denkfehler
Hallo,
die Ursache meines oben beschriebenes Performance-Problems kommt sehr wahrscheinlich daher, dass sowohl fhem als auch der Unifi-Controller auf demselben RasPi laufen. Das ist dann wohl doch etwas zu viel für den Kleinen als Abfragen-HTTP-Requests direkt hintereinander abzuschicken, durch den Unifi-Controller beantworten und die Antworten zu dekodieren. Da mich momentan nur die Clients interessieren bin ich mit dem Auskommentieren der anderen Aufrufe glücklich.
Da die Kinder aber immer öfter Besuch mit Handy-WLAN-Wünschen bekommen habe ich mir ein Voucher-Gast-WLAN eingerichtet. Jetzt wäre es Klasse, die Voucher-IDs per TelegramBot abfragen zu können.
Dazu habe ich auch schonmal ein wenig programmiert (als PERL- und Modul-Newebie nicht ganz so einfach :-), stoße aber beim Verstehen des Codes an meine Grenzen :-(
Mein Code dazu sieht aktuell folgendermaßen aus (zum Ausprobieren habe ich das Modul bei mir in MyUnifi umbenannt):
Voucher erzeugen:
sub MyUnifi_CreateVoucher_Send($) {
my ($hash) = @_;
my ($name,$self) = ($hash->{NAME},MyUnifi_Whoami());
Log3 $name, 5, "$name ($self) - executed.";
HttpUtils_NonblockingGet( {
%{$hash->{httpParams}},
url => $hash->{unifi}->{url}."cmd/hotspot",
callback => \&MyUnifi_CreateVoucher_Cmd_Receive,
data => "{'cmd': 'create-voucher', 'expire': '120', 'n': '1', 'quota': '1', 'note': 'by FHEM'}",
} );
return undef;
}
sub MyUnifi_CreateVoucher_Cmd_Receive($) {
my ($param, $err, $data) = @_;
my ($name,$self,$hash) = ($param->{hash}->{NAME},MyUnifi_Whoami(),$param->{hash});
Log3 $name, 5, "$name ($self) - executed.";
if ($err ne "") {
MyUnifi_ReceiveFailure($hash,{rc => 'Error while requesting', msg => $param->{url}." - $err"});
}
elsif ($data ne "") {
if ($param->{code} == 200 || $param->{code} == 400 || $param->{code} == 401) {
eval { $data = decode_json($data); 1; } or do { $data = { meta => {rc => 'error.decode_json', msg => $@} }; };
if ($data->{meta}->{rc} eq "ok") {
Log3 $name, 5, "$name ($self) - voucher_create_time:'$data->{data}[0]->{create_time}'";
$hash->{CreatedVoucherTime}=$data->{data}[0]->{create_time};
}
else { MyUnifi_ReceiveFailure($hash,$data->{meta}); }
} else {
MyUnifi_ReceiveFailure($hash,{rc => $param->{code}, msg => "Failed with HTTP Code $param->{code}."});
}
}
MyUnifi_GetCreatedVoucher_Send($hash);
return undef;
}
Voucher auslesen:
sub MyUnifi_GetCreatedVoucher_Send($) {
my ($hash) = @_;
my ($name,$self) = ($hash->{NAME},MyUnifi_Whoami());
Log3 $name, 5, "$name ($self) - executed.";
HttpUtils_NonblockingGet( {
%{$hash->{httpParams}},
method => "GET",
url => $hash->{unifi}->{url}."stat/voucher",
callback => \&MyUnifi_GetCreatedVoucher_Receive,
} );
return undef;
}
sub MyUnifi_GetCreatedVoucher_Receive($) {
my ($param, $err, $data) = @_;
my ($name,$self,$hash) = ($param->{hash}->{NAME},MyUnifi_Whoami(),$param->{hash});
Log3 $name, 5, "$name ($self) - executed.";
if ($err ne "") {
MyUnifi_ReceiveFailure($hash,{rc => 'Error while requesting', msg => $param->{url}." - $err"});
}
elsif ($data ne "") {
if ($param->{code} == 200 || $param->{code} == 400 || $param->{code} == 401) {
eval { $data = decode_json($data); 1; } or do { $data = { meta => {rc => 'error.decode_json', msg => $@} }; };
if ($data->{meta}->{rc} eq "ok") {
Log3 $name, 5, "$name ($self) - state:'$data->{meta}->{rc}'";
for my $h (@{$data->{data}}) {
if (defined($h->{create_time})) {
#$hash->{wlan_health} = $h;
if ($h->{create_time} eq $hash->{CreatedVoucherTime}) {
Log3 $name, 5, "$name ($self) - Treffer -----:'$h->{code}'";
readingsBeginUpdate($hash);
readingsBulkUpdate($hash,"CreatedVoucherCode",$h->{code});
readingsEndUpdate($hash,1);
}
}
}
}
else { MyUnifi_ReceiveFailure($hash,$data->{meta}); }
} else {
MyUnifi_ReceiveFailure($hash,{rc => $param->{code}, msg => "Failed with HTTP Code $param->{code}."});
}
}
#MyUnifi_NextUpdateFn($hash,$self);
return undef;
}
(plus Erweiterung der set-Methode)
Dabei habe ich gelernt, dass es aus Gründen der Vermeidung von Blockierung sinnvoller wäre, die Voucher-IDs in FHEM vorzuhalten (als Cache) und wenn der Cache z.B. nur noch 5 Voucher enthält ein paar auf einmal zu generieren und den Cache zu füllen. Bei jeder Auslieferung eines Vouchers müsste die entsprechende ID dann aus dem Cache gelöscht werden und evtl. erstmal für einen Tag (?) in eine Blacklist, so dass diese ID nicht mehrmals ausgeliefert wird.
Beim Auruf der Unifi-Api geholfen hat mir https://github.com/malle-pietje/UniFi-API-browser/blob/master/phpapi/class.unifi.php (https://github.com/malle-pietje/UniFi-API-browser/blob/master/phpapi/class.unifi.php).
Wie wäre die Implementierung am sinnvollsten? Ggf. als Submodul? Es gibt jetzt schon recht viele Readings. Ausserdem ist der UseCase ggü. dem bisherigen "Überwachungs"-Case ein anderer und hat daher evtl. keine Update-Intervalle sondern steuert sich selbst nach Verbrauch.
Ein frohes neues Jahr wünscht der
Wühler
ich bin gerade dabei ein unifi usg in betrieb zu nehmen und es kommen demnächst vermutlich noch ein paar unifi switches dazu.
das usg führt aktuell zu einem komischen verhalten im modul:
- es taucht als accesspoint auf, ich weiss noch nicht ob das sinnvoll ist
- ich habe readings für einen zusätzlichen ap mit der ip 192.168.1.1. das ist die default ip des usg die es aber nicht mehr hat
- alle lan clients tauchen jetzt mit reading auf, sind aber mehr oder weniger zufällig einem der wlan ap zugeordnet.
nicht dem usg
ich glaube hier gibt es noch optimierungsbedarf bzw. anpassungen wenn nicht nur wlan aps am unifi controller hängen.
gruss
andre
Das stimmt allerdings Andre :-)
Würde mir gerne ein möglichst vollständiges (ohne PW...) Dumper($defs{unifi}) von dir anschauen,
allerdings vermute ich dass hier nicht alles der usg dabei sein wird und separat abgefragt werden muss.
Unschön die usg mit in das unifi-device aufzunehmen,
es sollte dann auch gleich das Aufteilen des Moduls in mehrere Geräte gemacht werden.
Bin allerdings die letzten Wochen schon kaum zum schlafen gekommen :-)
Hoffe (denke) dass es allerdings in Kürze? ruhiger wird und ich mal wieder mehr zu fhem komme!
Falls du allerdings an dem Modul Optimierungen durchführen willst, oder Patches damit es schneller geht, gerne :-)
Gruß Claudiu
Mit dem richtigen PRESENCE-Modul gibt es aber keine Lösung?
du kannst z.b. die unifi connected/disconnected mit einem PRESENCE function {ReadingsVal(...) eq 'connected'} in ein PRESENCE devicvice übernehmen.
aktuell noch mit einem kleinen BlockingCall overhead der eigentlich nicht nötig ist. das ist aber nicht kritisch.
gruss
andre
Zitat von: justme1968 am 09 Januar 2017, 14:17:03
du kannst z.b. die unifi connected/disconnected mit einem PRESENCE function {ReadingsVal(...) eq 'connected'} in ein PRESENCE devicvice übernehmen.
Danke dir. Habe es nur schnell testen können, aber erhalte eine Fehlermeldung:
define Unifi_test PRESENCE function {ReadingsVal("UniFi","NameDevice") eq "connected"}
ergibt einen Error und eine Fehlermeldung im Log...
Bitte versuch mal:
define Unifi_test PRESENCE function {ReadingsVal("UniFi","NameDevice","") eq "connected"}
Also zumindest bei mir funktioniert das so.
Danke Markus.
Zitat von: Markus Bloch am 09 Januar 2017, 15:49:52
Bitte versuch mal:
define Unifi_test PRESENCE function {ReadingsVal("UniFi","NameDevice","") eq "connected"}
Funktioniert nun auch bei mir. Vielen Dank. Wie setze ich bei Abwesenheit "absent"? Bisher liefert er lediglich "error", klar weil die Funktion nicht erfüllt ist, aber keine 0 zurückgibt.
z.B. so:
define Unifi_test PRESENCE function {ReadingsVal("UniFi","NameDevice","") eq "connected" ? 1 : 0}
Zitat von: Markus Bloch am 10 Januar 2017, 08:38:28
z.B. so:
define Unifi_test PRESENCE function {ReadingsVal("UniFi","NameDevice","") eq "connected" ? 1 : 0}
Funktioniert perfekt! Danke.
Ich werde in den nächsten Tagen eine Änderung machen, so dass man PRESENCE auf Events binden kann.
Damit soll PRESENCE um folgende Syntax erweitert werden:
define <NAME> PRESENCE event <absent-Regexp> <present-Regexp>
Sobald die jeweilige Regexp auf ein entsprechendes Event matcht, wird der Status entsprechend in PRESENCE geändert. Optional würde dann noch eine Funktion hinzukommen in der man ein Timeout definieren kann analog zu den Thresholds bei den herkömlichen Modis (absence-/presenceThreshold).
Viele Grüße
Markus
Welche Vorteile hat dies gegenüber function?
Ist intuitiver ohne in Perl abtauchen zu müssen. Funktional wäre es gleich
Hi,
vielleicht hilft es ja jemandem wenn es Verbindungsprobleme mit einen UniFi Controller auf einem Raspi gibt ;)
Ich probiere hier schon seit Stunden den UniFi Controller in meine FHEM Installation einzubinden. Trotz aller Ansätze
aus dem Thread hier hat es nicht geklappt. Abhilfe schaffte letztendlich dann doch ein Setzen des Timeouts in der
74_Unifi.pm.
Das war auch so im Thread hier erwähnt, allerdings braucht der Raspi anscheinen teilweise mehr als die dort
vorgeschlagenen 5 Sekunden. Eine Erhöhung des Werts auf 10 funktioniert hier einwandfrei.
(Hardware: Controller auf einen Raspi 3, FHEM auf einem zweiten Raspi)
Grüße, Chris
Hi und Danke für den Hinweis,
ein Timeout Attribut wär doch was :-)
Die neue PRESENCE-Version habe ich soeben eingecheckt, steht ab morgen via update zur Verfügung. Damit kann man Unifi folgendermaßen einbinden (sofern ich es richtig verstanden habe, wie Unifi funktioniert):
define <NAME> PRESENCE event UniFi:NamedDevice:.disconnected UniFi:NamedDevice:.connected
Dazu kann man dann mit den neuen Attributen absenceTimeout sowie presenceTimeout einstellen, wie lange nach dem Empfang eines entsprechenden Events gewartet werden soll, bevor der PRESENCE Status final auf "absent" oder "present" gesetzt werden soll. Die Angabe erfolgt in HH:MM:SS wobei Stunden und Minuten optional sind.:
attr <NAME> presenceTimeout 10 # 10 Sekunden
attr <NAME> absenceTimeout 15:00 # 15 Minuten
Das ganze erfolgt ohne den ganzen Blocking.pm-Overhead direkt und ist daher in "Echtzeit".
Viele Grüße
Markus
Habe es gerade eingebunden.
Ich bekomme als Status lediglich "initialized".
Mache ich iwas falsch?
Erst, sobald ein entsprechendes Event auftritt ändert sich auch der Status entsprechend.
Gruß
Markus
Schöne Erweiterung, funktioniert bei mir einwandfrei :)
Hallo Markus,
bei beiden
attr <NAME> presenceThreshold 10 # 10 Sekunden
attr <NAME> absenceThreshold 15:00 # 15 Minuten
bekomme ich ein:
presenceThreshold is not applicable for mode 'event'
bzw. ein
absenceThreshold is not applicable for mode 'event'
Gruß Thomas
ich meine natürlich "Timeout:
attr <NAME> presenceTimeout 10 # 10 Sekunden
attr <NAME> absenceTimeout 15:00 # 15 Minuten
Ich habe es soeben im oberen Beitrag geändert.
Sorry
Gruß
Markus
Zitatich meine natürlich "Timeout:
Ah, jetzt, ja :) :) :)
Danke
Kurze Frage stimmt es, dass beim Unifi Controller die Geräte erst ab 5 Minuten abwesenheit auf disconnected gesetzt werden?
bei mir sind es ziemlich genau 10 minuten.
Zitat von: Pippowicz am 12 Januar 2017, 17:38:10
Hi,
vielleicht hilft es ja jemandem wenn es Verbindungsprobleme mit einen UniFi Controller auf einem Raspi gibt ;)
Ich probiere hier schon seit Stunden den UniFi Controller in meine FHEM Installation einzubinden. Trotz aller Ansätze
aus dem Thread hier hat es nicht geklappt. Abhilfe schaffte letztendlich dann doch ein Setzen des Timeouts in der
74_Unifi.pm.
Das war auch so im Thread hier erwähnt, allerdings braucht der Raspi anscheinen teilweise mehr als die dort
vorgeschlagenen 5 Sekunden. Eine Erhöhung des Werts auf 10 funktioniert hier einwandfrei.
(Hardware: Controller auf einen Raspi 3, FHEM auf einem zweiten Raspi)
Grüße, Chris
Ich habe leider auch Verbindungsprobleme. Egal was ich bisher probiert habe bleib der Status bei "disconnected".
Bei mir ist es genau wie oben beschrieben, dass FHEM auf einem PI läuft und auf einem komplett neu aufgesetzten PI3 ist der Controller der neusten Firmware installiert. Über den Browser (https://192.168.XXX.XXX:8443) kann ich auch problemlos zu greifen, nur in FHEM bekomme ich einfach keine Verbindung.
Muss ich denn die Version noch irgendwie anpassen, da Version 5 im Modul nicht unterstützt wird.
define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID> [
<version>]]]
Wie kann ich denn ein Timeout in der 74_Unifi.pm setzen?
Internals:
CFGFN
DEF 192.168.178.49 8443 xxxxx xxxxx
NAME myUnifi
NOTIFYDEV global
NR 349
NTFY_ORDER 50-myUnifi
STATE disconnected
TYPE Unifi
Readings:
2017-01-18 13:45:26 state disconnected
Accespoints:
alerts_unarchived:
Clients:
events:
Httpparams:
ignoreredirects 1
loginData {"username":"xxxx", "password":"xxxxx"}
loginUrl https://192.xxx.xxx.xxx:8443/api/login
loglevel 5
method POST
noshutdown 0
timeout 5
Hash:
Sslargs:
SSL_verify_mode 0
Unifi:
CONNECTED disconnected
eventPeriod 24
interval 30
url https://192.xxx.xxx.xxx:8443/api/s/default/
version 4
Updatedispatch:
Attributes:
$hash->{httpParams} = {
hash => $hash,
timeout => 5,
method => "POST",
noshutdown => 0,
ignoreredirects => 1,
loglevel => AttrVal($name,"httpLoglevel",5),
sslargs => { SSL_verify_mode => 0 },
};
Hier den Parameter 5 hinter timeout einfach mal auf 10 ändern, dann hats bei mir geklappt.
Gruß, Chris
Hallo @all,
FYA
ich habe gerade den Unifi Controller auf 5.4.9 aktualisiert und dann ein update von fhem durchgeführt.
Danach startet fhem nicht mehr :-/
Letzte Logzeile ist:
Can't use an undefined value as an ARRAY reference at ./FHEM/74_Unifi.pm line 846.
Kommentiere ich das Unifi-Modul in meiner fhem.cfg aus, dann startet fhem auch wieder brav.
Gruß,
blofield
Kann das Problem jemand bestätigen? SIehst du, wenn du "attr global verbose 5" setzt und FHEM startest etwas im Log?
Ich hab auch ein Update auf die 5.4.9 gemacht. Bei mir läuft alles. Ich nutze den windows controller
ich verwende die 5.5.2 alpha und die funktioniert auch.
Okay, danke für die Rückmeldungen. Dann kann ich heute Abend ja Problemlos auf die Stable 5.4.9 updaten.
Ich hab gerade das Modul erst definiert. Läuft bisher ohne Problem Danke.
Gesendet von iPhone mit Tapatalk Pro
Nachdem ich es auskommentiert, fhem gestartet, dann einkommentiert und fhem restarted habe, geht es auch wieder.
Allerdings macht die 5.4.9 auf Linux bei mir Probleme. Meine UAPs sind danach stündlich rebooted, musste mit Support meine (bis dato gut funktionierende) Config ändern, damit es sich wieder stabil betreiben lässt ...
Viel Erfolg.
blofield
Zitat von: blofield am 25 Januar 2017, 17:39:03
Nachdem ich es auskommentiert, fhem gestartet, dann einkommentiert und fhem restarted habe, geht es auch wieder.
Allerdings macht die 5.4.9 auf Linux bei mir Probleme. Meine UAPs sind danach stündlich rebooted, musste mit Support meine (bis dato gut funktionierende) Config ändern, damit es sich wieder stabil betreiben lässt ...
Viel Erfolg.
blofield
Was hast du denn ändern müssen? Wäre interessant zu wissen bevor ich upgrade.
Gruß
Karl
Sent from my iPad using Tapatalk
Zitat von: schka17 am 25 Januar 2017, 18:29:52
Was hast du denn ändern müssen? Wäre interessant zu wissen bevor ich upgrade.
Gruß
Karl
Sent from my iPad using Tapatalk
Ich musste für meine "alten" UAPs 1st Gen die Funktion "Verbindungs-Monitor und Drahtlos-Uplink aktivieren" sowie "Automatische Ausfallsicherung für Uplink aktivieren" deaktivieren (das hatte vorher immer sauber und zuverlässig funktioniert) und habe seither grundsätzlich ein Problem damit Änderungen zu Provisionieren.
Nach jedem neuen Provisioning starten die UAPs zwar aber laufen dann nur mal einige Minuten bis einige Stunden, bis sie sich wieder rebooten. Das geht so lange, bis man alle vom Strom trennt und dann schön langsam nacheinander wieder ans Netz nimmt.
Dann läuft es stabil (bei mir jetzt eine Woche), bis man was ändern möchte, dann geht es wieder von vorne los. Ist bei mir zuverlässig reproduzierbar.
Angeblich betrifft das nur die originalen UAPs aus der ersten Generation. Ich kann es mangels anderer Geräte nicht testen.
blofield
Ich überlege gerade, ob man mit dem Modul auch eine "Schlafen" Erkennung umsetzen kann, z.B. um den entsprechenden Status im Residents Modul zu setzen.
Wie würde man sowas am Besten angehen? Aktivität (connects, bandwidth,...) der betroffenen Geräte über eine Zeitdauer x messen?
ich glaube damit wirst du nicht glücklich bei nur einem gerät.
was aber z.b. perfekt funktioniert ist eine kombination aus iphone und apple watch.
nachts schalte ich mein handy immer in den flug modus. dadurch bucht sich die uhr automatisch ins wlan ein.
kein gerät vorhanden -> ich bin weg
nur watch vorhanden -> ich schlafe
nur iphone da -> ich bin zuhause
beide da -> übergangszeit
@Claudiu: da mein unifi device inzwischen einige dutzend geräte anzeigt habe ich immer wieder das problem die readings die zu einem bestimmten device gehören zu identifizieren.
das modul zeigt für manche geräte den im controller vergeben alias, für manche geräte scheinbar einen namen der vom gerät selber kommt und für manche geräte nur eine kryptische id. obwohl ich für alle geräte einen alias vergeben habe.
ich habe noch kein schema erkannt. hat du einen hinweis für mich ?
ein weiters problem dabei ist das die reading namen nicht stabil bleiben. was hältst du von einem attribut mit dem man festlegen kann worauf die reading namen basieren sollen. z.b. auf der mac adresse. so ähnlich wie man im nmap modul einstellen kann ob die readings auf ip oder mac basieren sollen.
gruss
andre
Hi Andre,
ich habe das devAlias attr eigtl. auch mit mehreren devices getestet.
Wie sieht denn dein devAlias attr aus? Evtl. schlägt sich ja eine bestimmte Kombination mit einer der RegEx.
Die Umsetzung von devAlias sollte eigtl. komplett in dieser Funktion passieren:
sub Unifi_ClientNames($@) {
my ($hash,$ID,$W) = @_;
my $clientRef;
my $devAliases = AttrVal($hash->{NAME},"devAlias",0);
if(defined $ID && defined $W && $W eq 'makeAlias') { # Return Alias from ID
$clientRef = $hash->{clients}->{$ID};
if ( ($devAliases && $devAliases =~ /$ID:(.+?)(\s|$)/)
|| ($devAliases && defined $clientRef->{name} && $devAliases =~ /$clientRef->{name}:(.+?)(\s|$)/)
|| ($devAliases && defined $clientRef->{hostname} && $devAliases =~ /$clientRef->{hostname}:(.+?)(\s|$)/)
|| (defined $clientRef->{name} && $clientRef->{name} =~ /^([\w\.\-]+)$/)
|| (defined $clientRef->{hostname} && $clientRef->{hostname} =~ /^([\w\.\-]+)$/)
) {
$ID = $1;
}
return $ID;
}
elsif (defined $ID && defined $W && $W eq 'makeID') { # Return ID from Alias
for my $clientID (keys %{$hash->{clients}}) {
$clientRef = $hash->{clients}->{$clientID};
if ( ($devAliases && $devAliases =~ /$clientID:$ID/)
|| ($devAliases && defined $clientRef->{name} && $devAliases =~ /$clientRef->{name}:$ID/)
|| ($devAliases && defined $clientRef->{hostname} && $devAliases =~ /$clientRef->{hostname}:$ID/)
|| (defined $clientRef->{name} && $clientRef->{name} eq $ID)
|| (defined $clientRef->{hostname} && $clientRef->{hostname} eq $ID)
) {
$ID = $clientID;
last;
}
}
return $ID;
}
else { # Return all clients in a scalar
my $clients = '';
for my $clientID (keys %{$hash->{clients}}) {
$clients .= Unifi_ClientNames($hash,$clientID,'makeAlias').',';
}
$clients =~ s/.$//;
return $clients;
}
}
mMn wäre die id noch besser, oder sowas z.B. 542_29f (die ersten 3 und die letzten 3 ziffern der id), mac muss nicht zwingend statisch sein. EDIT: oder macht der controller bei ner neuen mac auch eine neue ID :)?
ich schaus mir dann im nmap mal an ;)
Du könntest mal probieren alle Geräte in devAlias auf die id als basis zu setzen, evtl. hilft das?
"id1:alias1 id2:alias2 id3:alias3..."
aktuell verwende ich das devAlias attribut nicht. ich habe im unifi controller für alle devices einen alias vergeben. dieser taucht aber in fhem so gut wie nicht auf.
ich möchte gerne vermeiden das ich die >40 geräte an mehr als einer stelle verwalten muss.
das problem mit der id statt der mac adresse ist das die idee glaube ich nirgendwo sonst sichtbar ist. d.h. wenn ein device erscheint für das kein vernünftiger name angezeigt wird ist es fast unmöglich zurück zu schliessen welches device es denn jetzt ist. es ist dann auch nicht hilfreich wenn als reading name und als hostname das gleiche angzeigt wird.
ich glaube es wäre gut zumindest optional die möglichkeit zu haben die mac als eindeutige id zu verwenden. und dann reading namen der form <mac>_... zu haben.
gruss
andre
Hi,
habe auch das Problem, dass sich das Modul nach dem Upgrade auf 4.5.9 nicht mehr connected:
017.02.09 23:33:08 5: myUnifi (Unifi_Login_Receive) - executed.
2017.02.09 23:33:08 5: myUnifi (Unifi_Login_Receive) - Error while requesting https://192.168.1.44:8443/api/login - 192.168.1.44: Connection refused
2017.02.09 23:33:08 5: myUnifi (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
Den Timeout habe ich stufenweise mittlerweile auf 100 gesetzt. Hat leider nichts gebracht. Mit Curl kann ich auf die Adresse von dem Raspi auf dem fhem läuft zugreifen.
Irgendeine Idee wo ich weitersuchen könnte?
VG Texel
Gerade das Update auf 5.4.11 gemacht.
Läuft bis jetzt ohne Probleme 8)
Gruß
Jörg
Hallo,
scheint ein Problem mit der Java-Version zu sein, wenn der unifi controller auf einem Raspberry läuft:
https://blog.2-cpu.de/2016/09/27/ubnt-unifi-mit-ssl-und-fhem-auf-dem-raspberrypi/ (https://blog.2-cpu.de/2016/09/27/ubnt-unifi-mit-ssl-und-fhem-auf-dem-raspberrypi/)
Danach ist wieder connected :)
VG Texel
Plötzlich Probleme mit Presence....
ich hoffe hier an der richtigen Stelle gelandet zu sein um eine Lösung für mein Problem zu finden.
Mein Unifi läuft in der Version 5.4.11.2 auf einer Synology und macht keine Problem. Alle Geräte werden korrekt angezeigt.
Auf meinem Tagesaktuellen Fhem habe ich aber seit einem update in den vergangenen Tagen das Problem, dass ich meine Anwesenheitserkennung nicht mehr hinbekomme (und das ohne, dass ich dort etwas geändert habe)
Ich frage alle 5 Minuten den Status des Controlers ab und nutze die Meldung "UniFi.iPhone-HZ..connected" um ein notify auszulösen (so mache ich das be allen Mobilgeräten und auch für das disconnect:
Internals:
DEF UniFi.iPhone-HZ..connected set rr_Michael home
NAME n_iPhone.Michael.Connect
NR 408
NTFY_ORDER 50-n_iPhone.Michael.Connect
REGEXP UniFi.iPhone-HZ..connected
STATE 2017-02-27 07:28:24
TYPE notify
Readings:
2017-02-23 17:17:22 state active
Attributes:
room _notify
und
Internals:
DEF UniFi.iPhone-HZ..disconnected set rr_Michael absent
NAME n_iPhone.Michael.Disconnect
NR 409
NTFY_ORDER 50-n_iPhone.Michael.Disonnect
REGEXP UniFi.iPhone-HZ..disconnected
STATE 2017-02-24 17:30:15
TYPE notify
Readings:
2017-02-23 17:17:22 state active
Attributes:
room _notify
mein notify behauptet aber, dass ich daheim bin:
Internals:
DEF UniFi.iPhone-HZ..connected set rr_Michael home
NAME n_iPhone.Michael.Connect
NR 408
NTFY_ORDER 50-n_iPhone.Michael.Connect
REGEXP UniFi.iPhone-HZ..connected
STATE 2017-02-27 07:28:24
TYPE notify
Readings:
2017-02-23 17:17:22 state active
Attributes:
room _notify
mein Roommates sagt:
2017-02-24 17:35:19 lastArrival 2017-02-24 17:35:19
2017-02-24 17:30:16 lastDeparture 2017-02-24 17:30:16
was bedeuten würde dass ich am 24. Heimgekommen bin und 5 Minuten später wieder gegangen sein soll.....
Ich weiß echt nicht was hier nicht stimmt. Wie gesagt ausser Updates habe ich an der Anwesenheitsüberwachung nichts geändert.
Gabe es im Modul eine Änderung, die ich verpasst habe?
Danke und Gruß
H-Man
Irgendwie ist Deine Fragestellung komisch.
Was genau steht denn aktuell im Reading
UniFi.iPhone-HZ..connected
Grüße
Hi,
das ist ja das Problem. Die ganzen readings stimmen nicht mehr. Aktuell wird mein iphone z.B. in den readings garnicht angezeigt meine AppleWacht steht aber auf connected - obwohl ich nicht daheim bin.
In der Controller Oberfläche ist alles bestens.
Danke und Grüße
H-Man
Gut dann hat das ganze mit Presence nichts zu tun. Hier geht es also rein um die Aktualisierung der Readings.
Mach mal bitte ein list vom Ubiquiti Device und poste es hier in Codetags.
Achte bitte auf eventuelle Passwörter oder so.
das ist aber extrem lang:
[code]
Internals:
DEF ip port user pas 300
NAME UniFi
NOTIFYDEV global
NR 89
NTFY_ORDER 50-UniFi
STATE connected
TYPE Unifi
Readings:
2017-02-27 14:52:24 -AP_AP Flur EG_clients 4
2017-02-27 14:52:24 -AP_AP Flur EG_essid ohne-Kabel,ohne-Kabel,uplink
2017-02-27 14:52:24 -AP_AP Flur EG_locate off
2017-02-27 14:52:24 -AP_AP Flur EG_state ok
2017-02-27 14:52:24 -AP_AP Flur OG_clients 5
2017-02-27 14:52:24 -AP_AP Flur OG_essid ohne-Kabel,ohne-Kabel,uplink
2017-02-27 14:52:24 -AP_AP Flur OG_locate off
2017-02-27 14:52:24 -AP_AP Flur OG_state ok
2017-02-27 14:52:24 -AP_AP Garten unten_clients 0
2017-02-27 14:52:24 -AP_AP Garten unten_essid ohne-Kabel,uplink
2017-02-27 14:52:24 -AP_AP Garten unten_locate off
2017-02-27 14:52:24 -AP_AP Garten unten_state error
2017-02-27 14:52:24 -AP_AP Wohnzimmer EG_clients 0
2017-02-27 14:52:24 -AP_AP Wohnzimmer EG_essid uplink
2017-02-27 14:52:24 -AP_AP Wohnzimmer EG_locate off
2017-02-27 14:52:24 -AP_AP Wohnzimmer EG_state ok
2017-02-27 14:52:24 -AP_AP Wohnzimmer KG_clients 4
2017-02-27 14:52:24 -AP_AP Wohnzimmer KG_essid ohne-Kabel,ohne-Kabel
2017-02-27 14:52:24 -AP_AP Wohnzimmer KG_locate off
2017-02-27 14:52:24 -AP_AP Wohnzimmer KG_state ok
2017-02-27 14:52:24 -AP_Router_clients 45
2017-02-27 14:52:24 -AP_Router_essid
2017-02-27 14:52:24 -AP_Router_locate off
2017-02-27 14:52:24 -AP_Router_state ok
2017-02-27 14:52:24 -AP_Switch Serverraum _clients 53
2017-02-27 14:52:24 -AP_Switch Serverraum _essid
2017-02-27 14:52:24 -AP_Switch Serverraum _locate off
2017-02-27 14:52:24 -AP_Switch Serverraum _state ok
2017-02-27 14:52:24 -UC_events 254 (last 24h)
2017-02-27 14:52:24 -UC_unarchived_alerts 82
2017-02-27 14:52:24 -UC_wlan_accesspoints 4
2017-02-27 14:52:24 -UC_wlan_guests 0
2017-02-27 14:52:24 -UC_wlan_state warning
2017-02-27 14:52:24 -UC_wlan_users 13
2017-02-27 14:52:24 57cbeef9c556103888a90ef7 connected
2017-02-27 14:52:24 57cbeef9c556103888a90ef7_accesspoint AP Wohnzimmer KG
2017-02-27 14:52:24 57cbeef9c556103888a90ef7_hostname 192.168.10.22
2017-02-27 14:52:24 57cbeef9c556103888a90ef7_last_seen 2017-02-27 14:52:23
2017-02-27 14:52:24 57cbeef9c556103888a90ef7_snr 39
2017-02-27 14:52:24 57cbeef9c556103888a90ef7_uptime 249890
2017-02-27 14:52:24 57cbeef9c556103888a90efb connected
2017-02-27 14:52:24 57cbeef9c556103888a90efb_accesspoint AP Flur OG
2017-02-27 14:52:24 57cbeef9c556103888a90efb_hostname 192.168.10.18
2017-02-27 14:52:24 57cbeef9c556103888a90efb_last_seen 2017-02-27 14:52:02
2017-02-27 14:52:24 57cbeef9c556103888a90efb_snr 31
2017-02-27 14:52:24 57cbeef9c556103888a90efb_uptime 249708
2017-02-27 14:52:24 57cbf81bc556103888a90f56 connected
2017-02-27 14:52:24 57cbf81bc556103888a90f56_accesspoint AP Wohnzimmer KG
2017-02-27 14:52:24 57cbf81bc556103888a90f56_hostname 192.168.10.19
2017-02-27 14:52:24 57cbf81bc556103888a90f56_last_seen 2017-02-27 14:52:23
2017-02-27 14:52:24 57cbf81bc556103888a90f56_snr 49
2017-02-27 14:52:24 57cbf81bc556103888a90f56_uptime 144438
2017-02-27 14:52:24 57d31c34c556aea3d1314f62 connected
2017-02-27 14:52:24 57d31c34c556aea3d1314f62_accesspoint AP Flur EG
2017-02-27 14:52:24 57d31c34c556aea3d1314f62_hostname 192.168.10.152
2017-02-27 14:52:24 57d31c34c556aea3d1314f62_last_seen 2017-02-27 14:51:51
2017-02-27 14:52:24 57d31c34c556aea3d1314f62_snr 15
2017-02-27 14:52:24 57d31c34c556aea3d1314f62_uptime 242627
2017-02-27 14:52:24 57dffd5dc556aea3d13159ca connected
2017-02-26 20:07:16 57dffd5dc556aea3d13159ca_accesspoint AP Flur EG
2017-02-27 14:52:24 57dffd5dc556aea3d13159ca_hostname 192.168.10.27
2017-02-27 14:52:24 57dffd5dc556aea3d13159ca_last_seen 2017-02-27 14:52:18
2017-02-27 14:52:24 57dffd5dc556aea3d13159ca_uptime 359058
2017-02-27 14:52:24 57dffd5dc556aea3d13159cc connected
2017-02-27 14:52:24 57dffd5dc556aea3d13159cc_accesspoint AP Flur EG
2017-02-27 14:52:24 57dffd5dc556aea3d13159cc_hostname 192.168.10.26
2017-02-27 14:52:24 57dffd5dc556aea3d13159cc_last_seen 2017-02-27 14:52:18
2017-02-27 14:52:24 57dffd5dc556aea3d13159cc_uptime 235177
2017-02-27 14:52:24 57dffd5dc556aea3d13159d0 connected
2017-02-27 14:52:24 57dffd5dc556aea3d13159d0_accesspoint AP Flur EG
2017-02-27 14:52:24 57dffd5dc556aea3d13159d0_hostname 192.168.10.16
2017-02-27 14:52:24 57dffd5dc556aea3d13159d0_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 57dffd5dc556aea3d13159d0_uptime 249896
2017-02-27 14:52:24 57dffd5dc556aea3d13159d2 connected
2017-02-27 14:52:24 57dffd5dc556aea3d13159d2_accesspoint AP Flur EG
2017-02-27 14:52:24 57dffd5dc556aea3d13159d2_hostname 192.168.10.5
2017-02-27 14:52:24 57dffd5dc556aea3d13159d2_last_seen 2017-02-27 14:52:18
2017-02-27 14:52:24 57dffd5dc556aea3d13159d2_uptime 235163
2017-02-27 14:52:24 57dffd5dc556aea3d13159d4 connected
2017-02-27 14:52:24 57dffd5dc556aea3d13159d4_accesspoint AP Flur EG
2017-02-27 14:52:24 57dffd5dc556aea3d13159d4_hostname 192.168.10.25
2017-02-27 14:52:24 57dffd5dc556aea3d13159d4_last_seen 2017-02-27 14:52:18
2017-02-27 14:52:24 57dffd5dc556aea3d13159d4_uptime 359104
2017-02-27 14:52:24 57dffd5dc556aea3d13159d6 connected
2017-02-27 14:52:24 57dffd5dc556aea3d13159d6_accesspoint AP Flur OG
2017-02-27 14:52:24 57dffd5dc556aea3d13159d6_hostname 192.168.10.41
2017-02-27 14:52:24 57dffd5dc556aea3d13159d6_last_seen 2017-02-27 14:52:18
2017-02-27 14:52:24 57dffd5dc556aea3d13159d6_uptime 249090
2017-02-27 14:52:24 57dffd85c556aea3d13159de connected
2017-02-27 14:52:24 57dffd85c556aea3d13159de_accesspoint AP Flur EG
2017-02-27 14:52:24 57dffd85c556aea3d13159de_hostname 192.168.10.252
2017-02-27 14:52:24 57dffd85c556aea3d13159de_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 57dffd85c556aea3d13159de_uptime 249893
2017-02-27 14:52:24 57dffd85c556aea3d13159e0 connected
2017-02-27 14:52:24 57dffd85c556aea3d13159e0_accesspoint AP Flur OG
2017-02-27 14:52:24 57dffd85c556aea3d13159e0_hostname 192.168.10.15
2017-02-27 14:52:24 57dffd85c556aea3d13159e0_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 57dffd85c556aea3d13159e0_uptime 249894
2017-02-27 14:52:24 57dffd86c556aea3d13159e4 connected
2017-02-26 20:07:16 57dffd86c556aea3d13159e4_accesspoint AP Flur EG
2017-02-27 14:52:24 57dffd86c556aea3d13159e4_hostname 192.168.10.12
2017-02-27 14:52:24 57dffd86c556aea3d13159e4_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 57dffd86c556aea3d13159e4_uptime 249883
2017-02-27 14:52:24 57dffd86c556aea3d13159ea connected
2017-02-26 20:07:16 57dffd86c556aea3d13159ea_accesspoint AP Flur EG
2017-02-27 14:52:24 57dffd86c556aea3d13159ea_hostname 192.168.10.13
2017-02-27 14:52:24 57dffd86c556aea3d13159ea_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 57dffd86c556aea3d13159ea_uptime 236167
2017-02-27 14:52:24 57dffdc8c556aea3d13159f3 connected
2017-02-27 14:52:24 57dffdc8c556aea3d13159f3_accesspoint AP Wohnzimmer KG
2017-02-27 14:52:24 57dffdc8c556aea3d13159f3_hostname 192.168.10.70
2017-02-27 14:52:24 57dffdc8c556aea3d13159f3_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 57dffdc8c556aea3d13159f3_uptime 359059
2017-02-27 14:52:24 57e0014ac556aea3d1315a2d connected
2017-02-27 14:52:24 57e0014ac556aea3d1315a2d_accesspoint AP Flur EG
2017-02-27 14:52:24 57e0014ac556aea3d1315a2d_hostname 192.168.10.47
2017-02-27 14:52:24 57e0014ac556aea3d1315a2d_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 57e0014ac556aea3d1315a2d_uptime 249896
2017-02-27 14:52:24 57e00399c556aea3d1315a45 connected
2017-02-27 14:52:24 57e00399c556aea3d1315a45_accesspoint AP Wohnzimmer KG
2017-02-27 14:52:24 57e00399c556aea3d1315a45_hostname 192.168.10.30
2017-02-27 14:52:24 57e00399c556aea3d1315a45_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 57e00399c556aea3d1315a45_uptime 249893
2017-02-27 06:35:50 57e01155c556aea3d1315ab0 disconnected
2017-02-27 06:30:47 57e01155c556aea3d1315ab0_accesspoint AP Flur OG
2017-02-27 06:30:47 57e01155c556aea3d1315ab0_hostname 192.168.10.170
2017-02-27 06:30:47 57e01155c556aea3d1315ab0_last_seen 2017-02-27 06:25:43
2017-02-27 06:30:47 57e01155c556aea3d1315ab0_uptime 4029
2017-02-27 14:52:24 57e1ce04c556aea3d1316632 connected
2017-02-27 14:52:24 57e1ce04c556aea3d1316632_accesspoint AP Flur OG
2017-02-27 14:52:24 57e1ce04c556aea3d1316632_hostname 192.168.10.200
2017-02-27 14:52:24 57e1ce04c556aea3d1316632_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 57e1ce04c556aea3d1316632_uptime 249685
2017-02-27 14:52:24 57e3ee18c556aea3d131761f connected
2017-02-27 14:52:24 57e3ee18c556aea3d131761f_accesspoint AP Wohnzimmer KG
2017-02-27 14:52:24 57e3ee18c556aea3d131761f_hostname 192.168.10.202
2017-02-27 14:52:24 57e3ee18c556aea3d131761f_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 57e3ee18c556aea3d131761f_uptime 249684
2017-02-27 14:52:24 57e3ee18c556aea3d1317621 connected
2017-02-27 14:52:24 57e3ee18c556aea3d1317621_accesspoint AP Wohnzimmer KG
2017-02-27 14:52:24 57e3ee18c556aea3d1317621_hostname 192.168.10.203
2017-02-27 14:52:24 57e3ee18c556aea3d1317621_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 57e3ee18c556aea3d1317621_uptime 249870
2017-02-27 14:52:24 57ee727dfbd8a4f764ec9445 connected
2017-02-27 14:52:24 57ee727dfbd8a4f764ec9445_accesspoint AP Wohnzimmer KG
2017-02-27 14:52:24 57ee727dfbd8a4f764ec9445_hostname Unknown
2017-02-27 14:52:24 57ee727dfbd8a4f764ec9445_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 57ee727dfbd8a4f764ec9445_uptime 249730
2017-02-27 14:52:24 57ee7304fbd8a4f764ec944c connected
2017-02-26 20:07:16 57ee7304fbd8a4f764ec944c_accesspoint AP Flur EG
2017-02-27 14:52:24 57ee7304fbd8a4f764ec944c_hostname Unknown
2017-02-27 14:52:24 57ee7304fbd8a4f764ec944c_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 57ee7304fbd8a4f764ec944c_uptime 249661
2017-02-27 14:52:24 57ee75d3fbd8a4f764ec945a connected
2017-02-27 14:52:24 57ee75d3fbd8a4f764ec945a_accesspoint AP Flur OG
2017-02-27 14:52:24 57ee75d3fbd8a4f764ec945a_hostname Unknown
2017-02-27 14:52:24 57ee75d3fbd8a4f764ec945a_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 57ee75d3fbd8a4f764ec945a_uptime 249726
2017-02-27 14:52:24 57ee7603fbd8a4f764ec945c connected
2017-02-27 14:52:24 57ee7603fbd8a4f764ec945c_accesspoint AP Flur OG
2017-02-27 14:52:24 57ee7603fbd8a4f764ec945c_hostname Unknown
2017-02-27 14:52:24 57ee7603fbd8a4f764ec945c_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 57ee7603fbd8a4f764ec945c_uptime 249725
2017-02-27 14:52:24 57ee7a1afbd8a4f764ec9472 connected
2017-02-27 14:52:24 57ee7a1afbd8a4f764ec9472_accesspoint AP Wohnzimmer KG
2017-02-27 14:52:24 57ee7a1afbd8a4f764ec9472_hostname Unknown
2017-02-27 14:52:24 57ee7a1afbd8a4f764ec9472_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 57ee7a1afbd8a4f764ec9472_uptime 249598
2017-02-27 14:52:24 57efc32dfbd8a4f764ec9da5 connected
2017-02-27 14:52:24 57efc32dfbd8a4f764ec9da5_accesspoint AP Flur OG
2017-02-27 14:52:24 57efc32dfbd8a4f764ec9da5_hostname 192.168.10.23
2017-02-27 14:52:24 57efc32dfbd8a4f764ec9da5_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 57efc32dfbd8a4f764ec9da5_uptime 249626
2017-02-27 14:52:24 57f2253efbd8a4f764ecb1c6 connected
2017-02-27 14:52:24 57f2253efbd8a4f764ecb1c6_accesspoint AP Flur OG
2017-02-27 14:52:24 57f2253efbd8a4f764ecb1c6_hostname Unknown
2017-02-27 14:52:24 57f2253efbd8a4f764ecb1c6_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 57f2253efbd8a4f764ecb1c6_uptime 249867
2017-02-27 14:52:24 57f22550fbd8a4f764ecb1cc connected
2017-02-27 14:52:24 57f22550fbd8a4f764ecb1cc_accesspoint AP Flur OG
2017-02-27 14:52:24 57f22550fbd8a4f764ecb1cc_hostname Unknown
2017-02-27 14:52:24 57f22550fbd8a4f764ecb1cc_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 57f22550fbd8a4f764ecb1cc_uptime 249686
2017-02-27 14:52:24 57f3c01dfbd8a4f764ecb5a1 connected
2017-02-27 14:52:24 57f3c01dfbd8a4f764ecb5a1_accesspoint AP Flur OG
2017-02-27 14:52:24 57f3c01dfbd8a4f764ecb5a1_hostname Unknown
2017-02-27 14:52:24 57f3c01dfbd8a4f764ecb5a1_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 57f3c01dfbd8a4f764ecb5a1_uptime 248008
2017-02-27 14:52:24 5818c655c55608c16bec7cf9 connected
2017-02-27 14:52:24 5818c655c55608c16bec7cf9_accesspoint AP Flur OG
2017-02-27 14:52:24 5818c655c55608c16bec7cf9_hostname Unknown
2017-02-27 14:52:24 5818c655c55608c16bec7cf9_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 5818c655c55608c16bec7cf9_uptime 235304
2017-02-27 14:52:24 58289b51f416f846d7722c6a connected
2017-02-27 14:52:24 58289b51f416f846d7722c6a_accesspoint AP Flur OG
2017-02-27 14:52:24 58289b51f416f846d7722c6a_hostname 192.168.10.156
2017-02-27 14:52:24 58289b51f416f846d7722c6a_last_seen 2017-02-27 14:52:02
2017-02-27 14:52:24 58289b51f416f846d7722c6a_snr 41
2017-02-27 14:52:24 58289b51f416f846d7722c6a_uptime 239720
2017-02-27 14:52:24 589c94f26312de12226240b7 connected
2017-02-27 14:52:24 589c94f26312de12226240b7_accesspoint AP Wohnzimmer KG
2017-02-27 14:52:24 589c94f26312de12226240b7_hostname 192.168.10.20
2017-02-27 14:52:24 589c94f26312de12226240b7_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 589c94f26312de12226240b7_uptime 249820
2017-02-27 14:52:24 AppleWanMichael connected
2017-02-27 14:52:24 AppleWanMichael_accesspoint AP Flur OG
2017-02-27 14:52:24 AppleWanMichael_hostname AppleWanMichael
2017-02-27 14:52:24 AppleWanMichael_last_seen 2017-02-27 14:52:11
2017-02-26 14:52:36 AppleWanMichael_snr 40
2017-02-27 14:52:24 AppleWanMichael_uptime 189636
2017-02-27 14:52:24 Bastelkeller connected
2017-02-27 14:52:24 Bastelkeller_accesspoint AP Wohnzimmer KG
2017-02-27 14:52:24 Bastelkeller_hostname Bastelkeller
2017-02-27 14:52:24 Bastelkeller_last_seen 2017-02-27 14:52:18
2017-02-27 14:52:24 Bastelkeller_uptime 249635
2017-02-27 14:52:24 Eee-Top1602 connected
2017-02-27 14:52:24 Eee-Top1602_accesspoint AP Flur EG
2017-02-27 14:52:24 Eee-Top1602_hostname Eee-Top1602
2017-02-27 14:52:24 Eee-Top1602_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 Eee-Top1602_uptime 249537
2017-02-27 14:52:24 FHEM-RasPi connected
2017-02-27 14:52:24 FHEM-RasPi_accesspoint AP Flur OG
2017-02-27 14:52:24 FHEM-RasPi_hostname FHEM-MPH
2017-02-27 14:52:24 FHEM-RasPi_last_seen 2017-02-27 14:52:18
2017-02-27 14:52:24 FHEM-RasPi_uptime 235177
2017-02-27 14:52:24 FS20-Cube-EG connected
2017-02-27 14:52:24 FS20-Cube-EG_accesspoint AP Flur OG
2017-02-27 14:52:24 FS20-Cube-EG_hostname 192.168.10.49
2017-02-27 14:52:24 FS20-Cube-EG_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 FS20-Cube-EG_uptime 358962
2017-02-27 14:52:24 FireTV connected
2017-02-27 14:52:24 FireTV_accesspoint AP Flur OG
2017-02-27 14:52:24 FireTV_hostname amazon-11860a2f0
2017-02-27 14:52:24 FireTV_last_seen 2017-02-27 14:52:18
2017-02-27 14:52:24 FireTV_uptime 235177
2017-02-27 14:52:24 HM-LAN-EG connected
2017-02-27 14:52:24 HM-LAN-EG_accesspoint AP Flur OG
2017-02-27 14:52:24 HM-LAN-EG_hostname 192.168.10.48
2017-02-27 14:52:24 HM-LAN-EG_last_seen 2017-02-27 14:52:18
2017-02-27 14:52:24 HM-LAN-EG_uptime 249901
2017-02-27 14:52:24 HM485-LAN-Gateway connected
2017-02-27 14:52:24 HM485-LAN-Gateway_accesspoint AP Flur OG
2017-02-27 14:52:24 HM485-LAN-Gateway_hostname NEQ0834003
2017-02-27 14:52:24 HM485-LAN-Gateway_last_seen 2017-02-27 14:52:18
2017-02-27 14:52:24 HM485-LAN-Gateway_uptime 249855
2017-02-27 14:52:24 HarmonyHub connected
2017-02-27 14:52:24 HarmonyHub_accesspoint AP Flur OG
2017-02-27 14:52:24 HarmonyHub_hostname HarmonyHub
2017-02-27 14:52:24 HarmonyHub_last_seen 2017-02-27 14:52:02
2017-02-27 14:52:24 HarmonyHub_snr 29
2017-02-27 14:52:24 HarmonyHub_uptime 248838
2017-02-27 14:52:24 MILightBridge-01 connected
2017-02-27 14:52:24 MILightBridge-01_accesspoint AP Flur EG
2017-02-27 14:52:24 MILightBridge-01_hostname 192.168.10.92
2017-02-27 14:52:24 MILightBridge-01_last_seen 2017-02-27 14:51:51
2017-02-27 14:52:24 MILightBridge-01_snr 71
2017-02-27 14:52:24 MILightBridge-01_uptime 249677
2017-02-26 15:10:11 MX-ExtIO disconnected
2017-02-26 15:05:09 MX-ExtIO_accesspoint AP Flur OG
2017-02-26 15:05:09 MX-ExtIO_hostname Unknown
2017-02-26 15:05:09 MX-ExtIO_last_seen 2017-02-26 15:00:18
2017-02-26 15:05:09 MX-ExtIO_uptime 136
2017-02-27 14:52:24 NB-Nadine connected
2017-02-27 14:52:24 NB-Nadine_accesspoint AP Flur EG
2017-02-27 14:52:24 NB-Nadine_hostname NB-Nadine
2017-02-27 14:52:24 NB-Nadine_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 NB-Nadine_uptime 249894
2017-02-27 14:52:24 Nadines-iPad connected
2017-02-27 14:52:24 Nadines-iPad_accesspoint AP Flur EG
2017-02-27 14:52:24 Nadines-iPad_hostname Nadines-iPad
2017-02-27 14:52:24 Nadines-iPad_last_seen 2017-02-27 14:51:51
2017-02-27 14:52:24 Nadines-iPad_snr 38
2017-02-27 14:52:24 Nadines-iPad_uptime 107023
2017-02-27 14:52:24 Nadines-iPhone6 connected
2017-02-27 14:52:24 Nadines-iPhone6_accesspoint AP Flur OG
2017-02-27 14:52:24 Nadines-iPhone6_hostname Nadines-iPhone6
2017-02-27 14:52:24 Nadines-iPhone6_last_seen 2017-02-27 14:52:11
2017-02-27 07:08:12 Nadines-iPhone6_snr 1
2017-02-27 14:52:24 Nadines-iPhone6_uptime 225674
2017-02-27 14:52:24 NadinesPodtouch connected
2017-02-27 14:52:24 NadinesPodtouch_accesspoint AP Flur OG
2017-02-27 14:52:24 NadinesPodtouch_hostname NadinesPodtouch
2017-02-27 14:52:24 NadinesPodtouch_last_seen 2017-02-27 14:52:02
2017-02-27 14:52:24 NadinesPodtouch_snr 31
2017-02-27 14:52:24 NadinesPodtouch_uptime 114348
2017-02-27 14:52:24 NadinesiPhone4s connected
2017-02-27 14:52:24 NadinesiPhone4s_accesspoint AP Flur OG
2017-02-27 14:52:24 NadinesiPhone4s_hostname NadinesiPhone4s
2017-02-27 14:52:24 NadinesiPhone4s_last_seen 2017-02-27 14:52:02
2017-02-27 14:52:24 NadinesiPhone4s_snr 32
2017-02-27 14:52:24 NadinesiPhone4s_uptime 67375
2017-02-27 14:52:24 PC-Download connected
2017-02-27 14:52:24 PC-Download_accesspoint AP Wohnzimmer KG
2017-02-27 14:52:24 PC-Download_hostname 192.168.10.243
2017-02-27 14:52:24 PC-Download_last_seen 2017-02-27 14:52:18
2017-02-27 14:52:24 PC-Download_uptime 249346
2017-02-26 22:18:22 PC-MPH disconnected
2017-02-26 22:13:19 PC-MPH_accesspoint AP Flur EG
2017-02-26 22:13:19 PC-MPH_hostname PC-MPH
2017-02-26 22:13:19 PC-MPH_last_seen 2017-02-26 22:09:26
2017-02-26 22:13:19 PC-MPH_uptime 18757
2017-02-27 14:52:24 RS815 connected
2017-02-27 14:52:24 RS815_accesspoint AP Flur EG
2017-02-27 14:52:24 RS815_hostname 192.168.10.3
2017-02-27 14:52:24 RS815_last_seen 2017-02-27 14:52:18
2017-02-27 14:52:24 RS815_uptime 248718
2017-02-27 14:52:24 SonosZP connected
2017-02-27 14:52:24 SonosZP_accesspoint AP Wohnzimmer KG
2017-02-27 14:52:24 SonosZP_hostname SonosZP
2017-02-27 14:52:24 SonosZP_last_seen 2017-02-27 14:52:18
2017-02-27 14:52:24 SonosZP_uptime 248748
2017-02-27 14:52:24 VM-Host connected
2017-02-27 14:52:24 VM-Host_accesspoint AP Flur EG
2017-02-27 14:52:24 VM-Host_hostname 192.168.10.240
2017-02-27 14:52:24 VM-Host_last_seen 2017-02-27 14:52:18
2017-02-27 14:52:24 VM-Host_uptime 235177
2017-02-27 14:52:24 android-5cb8d2fa415e57bc connected
2017-02-27 14:52:24 android-5cb8d2fa415e57bc_accesspoint AP Flur EG
2017-02-27 14:52:24 android-5cb8d2fa415e57bc_hostname android-5cb8d2fa415e57bc
2017-02-27 14:52:24 android-5cb8d2fa415e57bc_last_seen 2017-02-27 14:52:11
2017-02-27 14:52:24 android-5cb8d2fa415e57bc_uptime 239983
2017-02-27 14:52:24 hentzns-iPhone connected
2017-02-27 14:52:24 hentzns-iPhone_accesspoint AP Flur OG
2017-02-27 14:52:24 hentzns-iPhone_hostname hentzns-iPhone
2017-02-27 14:52:24 hentzns-iPhone_last_seen 2017-02-27 14:52:11
2017-02-26 17:44:17 hentzns-iPhone_snr 37
2017-02-27 14:52:24 hentzns-iPhone_uptime 75774
2017-02-27 14:52:24 iPadProvonMPH connected
2017-02-27 14:52:24 iPadProvonMPH_accesspoint AP Flur OG
2017-02-27 14:52:24 iPadProvonMPH_hostname iPadProvonMPH
2017-02-27 14:52:24 iPadProvonMPH_last_seen 2017-02-27 14:52:11
2017-02-27 05:35:10 iPadProvonMPH_snr 38
2017-02-27 14:52:24 iPadProvonMPH_uptime 249838
2017-02-27 14:52:24 iPadminivonMPH connected
2017-02-27 14:52:24 iPadminivonMPH_accesspoint AP Flur OG
2017-02-27 14:52:24 iPadminivonMPH_hostname iPadminivonMPH
2017-02-27 14:52:24 iPadminivonMPH_last_seen 2017-02-27 14:52:11
2017-02-26 11:07:49 iPadminivonMPH_snr 30
2017-02-27 14:52:24 iPadminivonMPH_uptime 249845
2017-02-27 14:52:24 iPhone-3G connected
2017-02-27 14:52:24 iPhone-3G_accesspoint AP Wohnzimmer KG
2017-02-27 14:52:24 iPhone-3G_hostname iPhone-3G
2017-02-27 14:52:24 iPhone-3G_last_seen 2017-02-27 14:52:11
2017-02-25 15:58:03 iPhone-3G_snr 31
2017-02-27 14:52:24 iPhone-3G_uptime 194810
2017-02-27 14:52:24 iPhone-HZ connected
2017-02-27 14:52:24 iPhone-HZ_accesspoint AP Wohnzimmer KG
2017-02-27 14:52:24 iPhone-HZ_hostname iPhone-HZ
2017-02-27 14:52:24 iPhone-HZ_last_seen 2017-02-27 14:52:11
2017-02-27 05:35:10 iPhone-HZ_snr 12
2017-02-27 14:52:24 iPhone-HZ_uptime 249583
2017-02-27 14:52:24 iPhone- connected
2017-02-27 14:52:24 iPhone-_accesspoint AP Flur EG
2017-02-27 14:52:24 iPhone-_hostname iPhone
2017-02-27 14:52:24 iPhone-last_seen 2017-02-27 14:52:11
2017-02-27 05:35:10 iPhon
2017-02-27 14:52:24 iPhoneme 249663
2017-02-27 07:03:07 state connected
Accespoints:
57cbeec8c556103888a90ee0:
_id 57cbeec8c556103888a90ee0
_uptime 249953
adopt_ip 192.168.10.224
adopt_url http://192.168.10.3:8080/inform
board_rev 16
bytes 0
bytes-d 0
bytes-r 0
cfgversion bc79263dd00cf0e8
connect_request_ip 192.168.10.224
connect_request_port 48899
considered_lost_at 1488203676
device_id 57cbeec8c556103888a90ee0
discovered_via l2
fw_caps 91
guest-num_sta 0
guest_token 15308307B9536F5640DDDC4034FBB998
hostname APWohnzimmerEG
inform_authkey fc5caecf7dc188961f7ec692ccb52d31
inform_ip 192.168.10.3
inform_url http://192.168.10.3:8080/inform
ip 192.168.10.224
known_cfgversion bc79263dd00cf0e8
last_seen 1488203517
led_override default
mac 44:d9:e7:be:4e:e6
model U2IW
na-guest-num_sta 0
na-num_sta 0
na-state INIT
na-user-num_sta 0
na_tx_packets 0
na_tx_retries 0
name AP Wohnzimmer EG
next_heartbeat_at 1488203570
ng-channel 6
ng-eirp 19
ng-extchannel 0
ng-gain 1
ng-guest-num_sta 0
ng-num_sta 0
ng-state RUN
ng-tx_power 18
ng-user-num_sta 0
ng_ast_be_xmit 764
ng_ast_cst
ng_ast_txto
ng_cu_self_rx 4
ng_cu_self_tx 4
ng_cu_total 9
ng_tx_packets 0
ng_tx_retries 0
num_sta 0
radio_na
rx_bytes 0
rx_bytes-d 0
serial 44D9E7BE4EE6
site_id 57cbeddec556103888a90ece
state 1
tx_bytes 0
tx_bytes-d 0
type uap
uptime 249953
user-num_sta 0
version 3.7.40.6115
wifi_caps 117
wlangroup_id_ng 57cbede5c556103888a90ed5
x_authkey fc5caecf7dc188961f7ec692ccb52d31
x_ssh_hostkey_fingerprint 56:fa:da:ce:4a:c5:2b:bf:0a:d3:1a:47:65:14:ca:8c
x_vwirekey c1817ec9b3d9b9687e91fa33af1fde98
Config_network:
dns1 192.168.10.3
dns2 8.8.8.8
gateway 192.168.10.254
ip 192.168.10.224
netmask 255.255.255.0
type static
downlink_table:
HASH(0x4c54240)
ethernet_table:
HASH(0x4e09020)
port_table:
HASH(0x4db2f30)
HASH(0x4f16380)
HASH(0x4512640)
Radio_ng:
antenna_gain 6
builtin_ant_gain 1
channel auto
ht 20
max_txpower 18
min_txpower 1
name wifi0
nss 1
radio ng
tx_power_mode high
radio_table:
HASH(0x447e918)
Stat:
bytes 0
mac 44:d9:e7:be:4e:e6
ng-tx_dropped 858543
port_2-rx_bytes 214452928
port_2-rx_packets 512649
port_2-tx_bytes 404158008
port_2-tx_packets 1857093
port_3-rx_bytes 414618872
port_3-rx_packets 1911230
port_3-tx_bytes 241315222
port_3-tx_packets 592037
tx_dropped 858543
uplink-rx_bytes 195193484
uplink-rx_dropped 705
uplink-rx_errors 705
uplink-rx_packets 1426451
uplink-tx_bytes 27456061
uplink-tx_packets 131115
uplink-tx_retries 33220
user-ng-tx_dropped 858543
user-tx_dropped 858543
Sys_stats:
loadavg_1 0.08
loadavg_15 0.01
loadavg_5 0.02
mem_buffer 0
mem_total 63971328
mem_used 40656896
Uplink:
ip 0.0.0.0
mac 44:d9:e7:be:4e:e6
max_speed 100
name eth0
netmask 0.0.0.0
num_port 3
rx_bytes 204217678
rx_bytes-r 587
rx_dropped 870
rx_errors 870
rx_multicast 522531
rx_packets 1513783
speed 100
tx_bytes 27773102
tx_bytes-r 103
tx_dropped 0
tx_errors 0
tx_packets 126493
type wire
uplink_mac 80:2a:a8:dd:9f:15
uplink_remote_port 3
uplink_table:
vap_table:
HASH(0x4d69ea8)
vwire_table:
HASH(0x4b35590)
wlan_overrides:
HASH(0x44a65d8)
57cbeec9c556103888a90ee2:
_id 57cbeec9c556103888a90ee2
_uptime 250012
adopt_ip 192.168.10.221
adopt_url http://192.168.10.3:8080/inform
board_rev 24
bytes 545560106
bytes-d 76131
bytes-r 2003
cfgversion b25db70c46bdefe2
connect_request_ip 192.168.10.221
connect_request_port 32769
considered_lost_at 1488203714
device_id 57cbeec9c556103888a90ee2
discovered_via l2
fw_caps 75
guest-num_sta 0
guest_token 6ADBFCA8A53F26FE5A63F8FAE6A7B7AA
hostname APWohnzimmerKG
inform_authkey d4e2d57af221008e27006749a8912334
inform_ip 192.168.10.3
inform_url http://192.168.10.3:8080/inform
ip 192.168.10.221
known_cfgversion b25db70c46bdefe2
last_seen 1488203543
led_override default
mac 04:18:d6:d0:20:44
model U7Ev2
na-channel 44
na-eirp 19
na-extchannel 1
na-gain 0
na-guest-num_sta 0
na-num_sta 0
na-state RUN
na-tx_power 19
na-user-num_sta 0
na_ast_be_xmit 371
na_ast_cst
na_ast_txto
na_tx_packets 0
na_tx_retries 0
name AP Wohnzimmer KG
next_heartbeat_at 1488203600
ng-channel 1
ng-eirp 17
ng-extchannel 0
ng-gain 0
ng-guest-num_sta 0
ng-num_sta 4
ng-state RUN
ng-tx_power 17
ng-user-num_sta 4
ng_ast_be_xmit 372
ng_ast_cst
ng_ast_txto 3
ng_tx_packets 160
ng_tx_retries 12
num_sta 4
rx_bytes 81120723
rx_bytes-d 16006
serial 0418D6D02044
site_id 57cbeddec556103888a90ece
state 1
tx_bytes 464439383
tx_bytes-d 60125
type uap
uptime 250012
user-num_sta 4
version 3.7.40.6115
wifi_caps 64
wlangroup_id_na 57cbede5c556103888a90ed5
wlangroup_id_ng 57cbede5c556103888a90ed5
x_authkey d4e2d57af221008e27006749a8912334
x_ssh_hostkey_fingerprint c2:2a:cc:0d:16:f3:36:f1:13:7f:b1:2c:97:7f:28:18
x_vwirekey 6a814344669d0784b48a23dc642cd497
Config_network:
dns1 192.168.10.3
dns2 8.8.8.8
gateway 192.168.10.254
ip 192.168.10.221
netmask 255.255.255.0
type static
downlink_table:
ethernet_table:
HASH(0x5075148)
port_stats:
port_table:
Radio_na:
builtin_ant_gain 0
max_txpower 24
min_txpower 12
name eth2
nss 3
radio na
tx_power_mode medium
Radio_ng:
builtin_ant_gain 0
max_txpower 22
min_txpower 12
name eth1
nss 3
radio ng
tx_power_mode medium
radio_table:
HASH(0x50cb1e8)
HASH(0x43e9080)
Stat:
bytes 545560106
mac 04:18:d6:d0:20:44
na-rx_bytes 325968
na-rx_frags 2269560
na-rx_packets 3675
na-tx_bytes 7357109
na-tx_errors 2
na-tx_packets 13930
na-tx_retries 739
ng-rx_bytes 80794755
ng-rx_frags 15218569
ng-rx_packets 841644
ng-tx_bytes 457082274
ng-tx_errors 3
ng-tx_packets 1567096
ng-tx_retries 79296
rx_bytes 81120723
rx_frags 17488129
rx_packets 845319
tx_bytes 464439383
tx_errors 5
tx_packets 1581026
tx_retries 80035
uplink-rx_bytes 513586794
uplink-rx_packets 2280842
uplink-tx_bytes 110365788
uplink-tx_packets 965747
user-na-rx_bytes 325968
user-na-rx_frags 2269560
user-na-rx_packets 3675
user-na-tx_bytes 7357109
user-na-tx_errors 2
user-na-tx_packets 13930
user-na-tx_retries 739
user-ng-rx_bytes 80794755
user-ng-rx_frags 15218569
user-ng-rx_packets 841644
user-ng-tx_bytes 457082274
user-ng-tx_errors 3
user-ng-tx_packets 1567096
user-ng-tx_retries 79296
user-rx_bytes 81120723
user-rx_frags 17488129
user-rx_packets 845319
user-tx_bytes 464439383
user-tx_errors 5
user-tx_packets 1581026
user-tx_retries 80035
Sys_stats:
loadavg_1 0.00
loadavg_15 0.00
loadavg_5 0.00
mem_buffer 4284416
mem_total 129048576
mem_used 44142592
Uplink:
ip 0.0.0.0
mac 04:18:d6:d0:20:44
max_speed 1000
name eth0
netmask 0.0.0.0
num_port 2
rx_bytes 854284692
rx_bytes-r 1827
rx_dropped 0
rx_errors 0
rx_multicast 0
rx_packets 2663591
speed 1000
tx_bytes 139756151
tx_bytes-r 559
tx_dropped 0
tx_errors 0
tx_packets 1158195
type wire
uplink_mac 80:2a:a8:dd:9f:15
uplink_remote_port 7
uplink_table:
vap_table:
HASH(0x4eea1e0)
HASH(0x4e8ff78)
vwire_table:
wlan_overrides:
HASH(0x4d0d018)
HASH(0x53341d0)
57cbeec9c556103888a90ee4:
_id 57cbeec9c556103888a90ee4
_uptime 249951
adopt_ip 192.168.10.222
adopt_url http://192.168.10.3:8080/inform
board_rev 24
bytes 1242851453
bytes-d 32887
bytes-r 865
cfgversion 09eb9f1b55e2a831
connect_request_ip 192.168.10.222
connect_request_port 32771
considered_lost_at 1488203664
device_id 57cbeec9c556103888a90ee4
discovered_via l2
fw_caps 75
guest-num_sta 0
guest_token 5813A75E1588CEE1423B9A08E5E4017D
hostname APFlurEG
inform_authkey 2316673433d861824ff16ba8969e0dba
inform_ip 192.168.10.3
inform_url http://192.168.10.3:8080/inform
ip 192.168.10.222
known_cfgversion 09eb9f1b55e2a831
last_seen 1488203511
led_override default
mac 04:18:d6:d0:23:20
model U7Ev2
na-channel 44
na-eirp 19
na-extchannel 1
na-gain 0
na-guest-num_sta 0
na-num_sta 0
na-state RUN
na-tx_power 19
na-user-num_sta 0
na_ast_be_xmit 741
na_ast_cst
na_ast_txto
na_tx_packets 0
na_tx_retries 0
name AP Flur EG
next_heartbeat_at 1488203562
ng-channel 1
ng-eirp 17
ng-extchannel 0
ng-gain 0
ng-guest-num_sta 0
ng-num_sta 4
ng-state RUN
ng-tx_power 17
ng-user-num_sta 4
ng_ast_be_xmit 372
ng_ast_cst
ng_ast_txto 4
ng_tx_packets 68
ng_tx_retries 23
num_sta 4
rx_bytes 206117760
rx_bytes-d 5875
serial 0418D6D02320
site_id 57cbeddec556103888a90ece
state 1
tx_bytes 1036733693
tx_bytes-d 27012
type uap
uptime 249951
user-num_sta 4
version 3.7.40.6115
wifi_caps 64
wlangroup_id_na 57cbede5c556103888a90ed5
wlangroup_id_ng 57cbede5c556103888a90ed5
x_authkey 2316673433d861824ff16ba8969e0dba
x_ssh_hostkey_fingerprint c6:fe:37:96:24:c9:13:72:26:a9:57:c0:b7:41:8f:da
x_vwirekey 6bc52d05c692cd914a0d90a30dd488fa
Config_network:
dns1 192.168.10.3
dns2 8.8.8.8
gateway 192.168.10.254
ip 192.168.10.222
netmask 255.255.255.0
type static
downlink_table:
ethernet_table:
HASH(0x50bb7c8)
port_stats:
port_table:
Radio_na:
builtin_ant_gain 0
max_txpower 24
min_txpower 12
name eth2
nss 3
radio na
tx_power_mode medium
Radio_ng:
builtin_ant_gain 0
max_txpower 22
min_txpower 12
name eth1
nss 3
radio ng
tx_power_mode medium
radio_table:
HASH(0x4cd0f28)
HASH(0x440dd18)
Stat:
bytes 1242851453
mac 04:18:d6:d0:23:20
na-rx_bytes 90532267
na-rx_frags 734534
na-rx_packets 399641
na-tx_bytes 745064669
na-tx_errors 326
na-tx_packets 1142599
na-tx_retries 7360
ng-rx_bytes 115585493
ng-rx_frags 10117646
ng-rx_packets 464296
ng-tx_bytes 291669024
ng-tx_errors 46
ng-tx_packets 1139136
ng-tx_retries 74539
rx_bytes 206117760
rx_frags 10852180
rx_packets 863937
tx_bytes 1036733693
tx_errors 372
tx_packets 2281735
tx_retries 81899
uplink-rx_bytes 959129937
uplink-rx_packets 2326429
uplink-tx_bytes 235556004
uplink-tx_packets 981828
user-na-rx_bytes 90532267
user-na-rx_frags 734534
user-na-rx_packets 399641
user-na-tx_bytes 745064669
user-na-tx_errors 326
user-na-tx_packets 1142599
user-na-tx_retries 7360
user-ng-rx_bytes 115585493
user-ng-rx_frags 10117646
user-ng-rx_packets 464296
user-ng-tx_bytes 291669024
user-ng-tx_errors 46
user-ng-tx_packets 1139136
user-ng-tx_retries 74539
user-rx_bytes 206117760
user-rx_frags 10852180
user-rx_packets 863937
user-tx_bytes 1036733693
user-tx_errors 372
user-tx_packets 2281735
user-tx_retries 81899
Sys_stats:
loadavg_1 0.00
loadavg_15 0.00
loadavg_5 0.00
mem_buffer 4284416
mem_total 129048576
mem_used 44498944
Uplink:
ip 0.0.0.0
mac 04:18:d6:d0:23:20
max_speed 1000
name eth0
netmask 0.0.0.0
num_port 2
rx_bytes 1049117209
rx_bytes-r 902
rx_dropped 0
rx_errors 0
rx_multicast 0
rx_packets 2732847
speed 1000
tx_bytes 809810100
tx_bytes-r 276
tx_dropped 0
tx_errors 0
tx_packets 1477507
type wire
uplink_mac 80:2a:a8:dd:9f:15
uplink_remote_port 2
uplink_table:
vap_table:
HASH(0x455aab0)
HASH(0x4559a28)
HASH(0x4b4b738)
vwire_table:
wlan_overrides:
HASH(0xe9aa18)
57cbeec9c556103888a90ee6:
_id 57cbeec9c556103888a90ee6
_uptime 249978
adopt_ip 192.168.10.223
adopt_url http://192.168.10.3:8080/inform
board_rev 24
bytes 4847986288
bytes-d 40144
bytes-r 1029
cfgversion e439efd6d7ebe8b4
connect_request_ip 192.168.10.223
connect_request_port 32771
considered_lost_at 1488203690
device_id 57cbeec9c556103888a90ee6
discovered_via l2
fw_caps 75
guest-num_sta 0
guest_token F966437E6F86D8EA8B4687D4CFFEE276
hostname APFlurOG
inform_authkey 99cc285f87a7a2fa8b524b29746bc73f
inform_ip 192.168.10.3
inform_url http://192.168.10.3:8080/inform
ip 192.168.10.223
known_cfgversion e439efd6d7ebe8b4
last_seen 1488203522
led_override default
mac 04:18:d6:d0:15:80
map_id 57cbede5c556103888a90edc
model U7Ev2
na-channel 36
na-eirp 19
na-extchannel 1
na-gain 0
na-guest-num_sta 0
na-num_sta 0
na-state RUN
na-tx_power 19
na-user-num_sta 0
na_ast_be_xmit 764
na_ast_cst
na_ast_txto
na_tx_packets 0
na_tx_retries 0
name AP Flur OG
next_heartbeat_at 1488203578
ng-channel 6
ng-eirp 16
ng-extchannel 0
ng-gain 0
ng-guest-num_sta 0
ng-num_sta 5
ng-state RUN
ng-tx_power 16
ng-user-num_sta 5
ng_ast_be_xmit 380
ng_ast_cst
ng_ast_txto 6
ng_tx_packets 74
ng_tx_retries 24
num_sta 5
rx_bytes 217612626
rx_bytes-d 7346
serial 0418D6D01580
site_id 57cbeddec556103888a90ece
state 1
tx_bytes 4630373662
tx_bytes-d 32798
type uap
uptime 249978
user-num_sta 5
&
Bitte wenn möglich noch mal anpassen. So kann man das schlecht lesen.
Hi, das hab ich schon befürchtet,
kannst du mir grob sagen was ich rausfiltern soll?
würde dir gerne das liefern was auch was zur analyse taugt...
Gruß
H-an
Na ich dachte da eher das Du da eventuell einen Fehler gemacht hast.
Kann aber auch sein das es in der Tat zu viel war. Ich schau mal durch ob man was findet.
Also laut Deinen Readings bist du heute um 14:50 Rum nach Hause gekommen. Stimmt das?
Hi,
erstmal vielen Dank für die Geduld, ist ja alles nicht selbstverständlich.
Ich bin zu besagter Uhrzeit leider nicht heimgekommen.
Die Zeiten werden scheinbar nur zufällig angepasst. Ich verstehe halt nicht wie last seen oder conncted werte etwas anzeigen was nicht stimmt....
entweder ist das Modul geändert worden oder unifi..... :-(
ich liefere gerne alles was zur fehlerbeseitigung hilft ...
Ich fürchte da werden wir auf den Modulauthor warten müssen.
Am Unifi Modul wurde (leider noch) nichts geändert.
laut deinen Angaben
2017-02-27 14:52:24 iPhone-HZ connected
2017-02-27 14:52:24 iPhone-HZ_accesspoint AP Wohnzimmer KG
2017-02-27 14:52:24 iPhone-HZ_hostname iPhone-HZ
2017-02-27 14:52:24 iPhone-HZ_last_seen 2017-02-27 14:52:11
2017-02-27 05:35:10 iPhone-HZ_snr 12
2017-02-27 14:52:24 iPhone-HZ_uptime 249583
war iPhone-HZ am 2017-02-27 14:52:24 mit deinem WLAN seit 249583 Sekunden verbunden, also seit 2017-02-24 17:32:41.
Am 2017-02-27 14:52:11 fand die letzte Kommunikation mit deinem WLAN statt.
Dein presence zeigt einen Wert wenige Minuten später bei lastArrival, um 17:35:19 Uhr (laut Unifi 17:32:41 wenn nicht verrechnet), 5 Minuten zuvor bist du das letzte mal weggegangen laut Presence
2017-02-24 17:35:19 lastArrival 2017-02-24 17:35:19
2017-02-24 17:30:16 lastDeparture 2017-02-24 17:30:16
Was genau stimmt respektive funktioniert jetzt nicht?
Gruß
Claudiu
auch jetzt wird wieder angezeigt (nur im fhem) dass mein iphone zuhaus sein soll. Ebenso werden geräte angezeigt, die angeblich an einem Accespoint angemeldet sein sollen, obwohl sie gar kein wlan haben sondern direkt am switch (auch unifi) hängen. z.B. 192.168.10.25
Also vermute ich immer noch, dass das Auslesen aus dem unifi controller nicht mehr klappt :-(
Danke und Gruß
H-Man
Es lief aber mal ne ganze Zeit lang, oder? Firmwareupdate gemacht?
ja es lief die ganze zeit und läuft auch auf einem anderen fhem.
Habe mal noch mit dem Support von ubiquitti geredet. die haben sich meine Logs angesehen => sie kamen zu dem Schluss, dass da wohl ein Fehler in der Controller Version ist.
Deswegen würde ich allen, die das hier lesen, raen nicht auf die Version 5.4.11 zu gehen!
Vielen Dank und Gruß
H-Man
Hi
@rapster
ich hab jetzt den Thread zweimal durchgeschaut, aber ich finde die Version nicht, welche du mal bereitgestellt hattest, zumindest laut deinen Posts, um das Wlan aus und ein schalten zu können. Ich möchte auch das Gast Wlan über FTUI einschalten.
Kannst du die Version nochmal bereitstellen, bzw. mir einen Hinweis geben, wo ich sie finden kann?
Mfg
Stiv
Guten Morgen,
ich bekomme bei jedem FHEM Neustart folgende Fehlermeldung des Unifi Moduls (funktioniert aber super)
PERL WARNING: Use of uninitialized value in string eq at ./FHEM/74_Unifi.pm line 813.
hat das noch jemand ?
Gruß
Carsten
Ja, habe dies auch jedes mal.
Habe aus diesem Grund das Modul vorerst deaktiviert.
Hallo,
ich habe den Controller erfolgreich hinzufügen können.... Wenn ich nun aber ein Gerät hinzufüge bekommt es schlichtweg den Status "initialized". Dies ändert sich auch nicht nach 10 oder 15 Minuten disconnect / connect.
Was muss ich tun damit es funktioniert?
Die ping Anwesenheitskontrolle ist nicht wirklich brauchbar...
Ich habe auch den ganze Log mit Use of uninitialized value in string eq at ./FHEM/74_Unifi.pm line 813. voll.
Etwas unschön
hi,
nach dem Update von heute bekomme ich folge Meldung:
Can't use an undefined value as an ARRAY reference at ./FHEM/74_Unifi.pm line 847.
und FHEM schmiert ab...
nach nem restore der 74_Unifi.pm war alles wieder gut
Gruß Michael
Seltsam wenn es mit der Änderung von gestern zusammen hängen sollte, aber probier mal bitte die Version aus morgigem Update.
hi,
sieht erstmal gut aus!
Gruß Michael
anbei ein patch:
- damit auch für wired clients der richtigen 'ap' (d.h. switch) namen gefunden und im reading gesetzt wird
- die beidem attribute ignoreWiredClients und ignoreWirelessClients einführt
intern wird mit dem patch auch noch die schleife die für jeden client wieder neu über alle accesspoints läuft durch einen einzigen schleifendurchlauf und hash lookup pro client ersetzt. das sollte den lookup bei vielen aps und vielen devices beschleunigen.
eine fehler der bei bei nicht gefundem ap denjenigen für das vorherige device gefunden genommen hat ist hiermit auch behoben. das sollte mit dem eigentlichen zweck des patches aber nicht mehr auftreten.
gruss
andre
Hab den Patch nur auf generelle Funktion getestet und eingecheckt.
Sry dass die Entwicklung hier zurzeit stagniert, bin allerdings die letzten Monate noch nicht einmal zu einem simplen Update gekommen.
Mitte Mai gehts bei mir geschäftlich wieder mit einem größeren Fhem Modul weiter, will dann auch gleich paar der angelaufen Anfragen in dieses Modul impementieren.
Patches sind allerdings immer Willkommen :)
Welche Unifi AP's setzt du i.M. ein, insbesondere für wired-clients?
Werde die kommenden Tage (denke kommende Woche) ebenfalls für meinen neuen Standort ein paar neue AP's bestellen müssen.
Meine Unifi's in Deutschland sehe ich die letzten Monate leider viel zu selten.
Gruß
Claudiu
die 'aps' für die wired clients sind aktuell ganz normale unifi switche. alle möglichen modelle. insgesamt hängen etwa 3-10 mal so viele clients per lan am system als per wlan. ich wollte aber erst mal nicht alles umstellen und von acesspoints auf z.b. uplinks umbenennen :).
als richtige ap habe ich inzwischen ap-ac-pro, ap-ac-m, ap-ac-m-pro und ap-ac-iw im einsatz. die pro und der iw haben zwar auch einen uplink für wired clients, die firmware hinkt aber hinterher und meldet diese noch nicht richtig. für den iw gibt es zwar eine erste beta version, die habe ich aber noch nicht probiert. es sollte aber zum obigen patch kompatibel sein.
gruss
andre
ps: was die wünsche angeht wäre schön noch ein clear order than zu haben um readings für alte devices los zu werden. im nmap modul gibt es das inzwischen auch :)
Hallo zusammen,
Danke für den Patch andre. Ich nutze auch viele wired Clients über die unifi Switches. Werde ich die Tage auch mal testen. Was mir aber auch schon mal aufgefallen ist, dass im unifi Controller manchmal einige WLAN Clients kurz nach dem connect oder disconnect als wired Client angezeigt werden. Ebenso werden die wired Clients manchmal am falschen Switch oder Port des Switch angezeigt. Ich denke da ist der Controller nicht 100% zuverlässig.
Ich schalte bei mir einen POE Switch und POE AP im Schlafzimmer abends manuell über die unifi AP aus und morgens wieder ein. Siehts du eine Chance, das wir diese config Änderung des Controllers in das Modul integriert bekommen? Wäre super wenn das über FHEM gehen würde.
Grüße
Christian
das ein wlan client bevor er ganz weg ist als lan client erscheint ist auch direkt im controller so. das ist bei ubiquiti bekannt aber ich weiss nicht ob sie das ändern werden.
das mit dem poe schalten habe ich mir gerade vorhin angeschaut :)
per api weiss ich noch nicht wie das geht. per ssh scheint es recht einfach zu sein. etwas in der art sollte gehen:ssh into your switch ubnt@<switch-ip>
US.v3.7.12# telnet localhost 2222
Warning!
The changes may break controller settings and only be effective until reboot.
(UBNT) >
(UBNT) >en
(UBNT)# conf
(UBNT) (Config)# interface 0/2
(UBNT) (Config)#poe opmode shutdown
(UBNT) (Config)#exit
gruss
andre
Gibt es dafür einen Button im Controller?
Dann einfach im Firefox F12 und guckn welcher JSON String geschickt wird wenn man da draufklickt.
Dann wie die anderen Send Funktionien entsprechend im Modul rein.
@Andre
Zum testen von neuen Funktionen habe ich mich immer per SSH auf meine Unifi Kiste aufgeschaltet,
dann hiermit an die API angemeldet
curl --tlsv1 --silent --cookie /tmp/cookie --cookie-jar /tmp/cookie --insecure --data "{'username':'admin', 'password':'secret'}" https://localhost/api/login
Dann an die richtige schnittstelle der API den Befehl
curl --tlsv1 --silent --cookie /tmp/cookie --cookie-jar /tmp/cookie --insecure --data "json={'mac': '04:18:d6:24:26:00', 'cmd': 'unset-locate'}" https://localhost/api/s/default/list/wlanconf
ja. es gibt einen button. ich schau es mir mal an sobald ich dazu komme.
gruss
andre
Cool, wenn du was neues für das Modul hast gerne direkt einchecken.
Denke die Qualität von dir sollte stimmen ;-)
Hier zwei Bilder wie der Beispiel CMD und URL im Firefox mit F12 -> Netzwerkanalyse nach Klick auf den Beispiel "Unset-Locate Button" herausgefunden werden kann.
also... bitte mit vorsicht verwenden: ich weiss nicht ob immer der richtige port erwischt wird oder ob unvorhergesehene andere dinge überschrieben werden...
anbei eine test version mit zwei neuen kommandos:
- get <unifi> poeState [name|mac|id]
listet den poe status aller ports eines/aller switche auf
- set <unifi> poeMode <name|mac|id> <port> <off|poe+|passive|passthrough|restart>
setzt den poe mode für den <port> des switches <name|mac|id> auf:
off -> aus
auto -> poe+
poe+ -> poe+
passive -> passive 24v
passthrough -> passthrough
restart -> schaltet den port aus und wieder an
der switch kann jeweils als name (regex! z.b. mit . für leerzeichen), mac adresse oder id angegeben werden.
ich habe noch nicht probiert was passiert wenn man einen mode setzen will der von einem port nicht unterstütz wird. ich vermute es gibt nur einen fehler im log.
aktuell werden nur switch ports berücksichtigt. nicht die ports von accespoints.
damit das ganze geht muss der user aus dem define schreibrechte haben. d.h. nicht nur ein read only admin sein ;)
im poe status wird direkt nach dem port namen noch eine spalte mit den poe capabilities des ports ausgegeben das scheint ein bitfeld zu sein:
1 -> nur 802.3af
7 -> 802.3af/at + 24v passive
8 -> passthrough
gruss
andre
@rapster: wenn es nicht nur bei mir geht und nichts zerschiesst kann ich es gerne einchecken.
edit 2017-04-03:
- switch port bei poeMode lässt sich auch als name angeben
- mehr hinweise bei falschem parameter. zum teil noch deaktiviert
- poePower readings für alle switche. summe aller poe ports. exclusive passive mode
Hallo Andre,
an ssh hatte ich auch schon gedacht aber bisher keine Zeit gefunden das mal umzusetzen.
Die neue Version mit den Befehlen klappt super, vielen Dank dafür.
Du bist ja super schnell :)
Ich werde das mal bei mir in die Automatisierung einbauen und dann ein wenig beobachten. Wenn es Probleme gibt melde ich mich.
Wenn du noch was anderes brauchst zum testen, dann immer her damit.
Ich habe:
1X USG = UniFi Security Gateway 3P
3X US-8 = UniFi Switch 8
1X US-16-150W = UniFi Switch 8 POE-150w
1x US-8-60W = UniFi Switch 8 POE-60W
3x UAP = UniFi AP
1x UAP-AC-PRO = UniFi AP-AC-Pro
Grüße
Christian
schön das es geht :)
ich würde noch zwei meldungen für nicht unterstützte parameter einbauen und dann wäre es von meiner seite erst mal fertig.
vielleicht kannst du noch mal die ausgabe von get poeState für den us-16 zeigen. alle anderen habe ich auch.
ich überlege schon ob ich nicht die verteilten us-8-60 durch us-8 ersetze. bis her ging das nicht weil die dann alle über die zentrale usv gelaufen wären. jetzt kann ich in diesem fall aber einfach alle switches auf der zweiten ebene per fhem abschalten :)
gruss
andre
ps: wäre es nützlich die ports auch nach namen auszuwählen? dann könnte man z.b. mit einem kommando. alle kameras schalten. oder alle nachgelagerten switche wenn die ports passend benannt sind.
pps: was mir noch einfällt... man könnte die poe power werte auch noch in einzelne readings der ap stecken. und dann mit den diversen power modulen den verbrauch protokollieren und plotten. wäre das für jemanden interessant?
ich habe die version oben noch mal um drei punkte ergänzt.
gruss
andre
Hallo Andre,
auch die neuste Version funktioniert bei mir super. Vielen dank dafür.
Hier das get poeState vom us-8-150W (den us-16-150w habe ich nicht, hatte mich vertan):
Switch Keller (mac:80:2a:a8:dc:17:6d, id:5809ccb8e4b078eb97aa2178)
id name on mode class
1 PALADIN 7 0 off Unknown 0.00W 0.00V 0.00mA
2 Wohnzimmer 7 0 off Unknown 0.00W 0.00V 0.00mA
3 Router 7 0 off Unknown 0.00W 0.00V 0.00mA
4 Port 4 7 0 off Unknown 0.00W 0.00V 0.00mA
5 HM Lan 7 1 auto good Class 3 1.64W 53.78V 30.51mA
6 Fritzbox 7 0 off Unknown 0.00W 0.00V 0.00mA
7 Schlafzimmer 7 1 auto good Class 4 9.66W 53.65V 180.05mA
8 AP Keller 7 1 auto good Class 0 4.05W 53.91V 75.07mA
9 SFP 1
10 SFP 2
Was aus meiner Sicht noch interessant wäre, eine Power Reading pro Port den es gibt, aber wenn man sich das genau überlegt muss man dann langsam zu eigenen unifi Sub Geräten gehen.
Je unifi Gerät ein eigenes FHEM Device ... aber das ist vermutlich viel arbeit und dauert zu lange und dafür nutzen es dann zu wenige.
Ich habe mir dann mit einem Dummy und 2 DOIF's etwas gebaut um die Ports in den jeweiligen Zimmern Schaltbar zu haben und den Status anzuzeigen.
Für alle die es interessiert hier meine Umsetzung, wenn es optimierungsbedarf gibt, immer her damit:
Dummy für Geräte im FHEMWEB:
define <name> dummy
attr <name> alias SwitchPort
attr <name> devStateIcon on:it_net@green off:it_net@red change:it_net@orange
attr <name> icon it_network
attr <name> room <Raum>
attr <name> setList on off
attr <name> stateFormat portState
erstes DOIF zum setzen des Status:
define doif.10.<name> DOIF ([<name>:"on"] and\
[<name>:portState] eq "off") \
(set <unifi Device> poeMode <name|mac|id> <port> poe+;;\
setreading <name> portState change;;) \
DOELSEIF \
([<name>:"off"] and\
[<name>:portState] eq "on") \
(set <unifi Device> poeMode <name|mac|id> <port> off;;\
setreading <name> portState change;;)
zweites DOIF um den wirklichen Status (naja es gibt ok oder error, ich interpretiere ok als on und error als off) in den Dummy zu schreiben:
define 20.doif.<name> DOIF ([<unifi Device>:<reading vom geschalteten Gerät>_state] eq "error") \
(setreading <name> portState off)\
DOELSEIF ([SYS.unifi:<reading vom geschalteten Gerät>_state] eq "ok") \
(setreading <name> portState on)\
Grüße Christian
zu den readings für einzelne ports: daran hatte ich auch schon gedacht. aber es wird vermutlich unübersichtlich das alles im controller device zu haben. dann wäre vermutlich ein device pro switch besser. ich weiss aber nicht wie viele anwender es dafür gibt. andererseits könnte man es auch in den controller stecken und dann jeweils einen readingsProxy zum schalten verwenden. statt dummy und notify/doif. readingsProxy würde ich sowieso verwenden :) dann geht auch gleich on-for-timer und ähnliches automatisch.
wenn man damit anfängt kommen vielleicht auch noch mehr readings dazu und am ende hat man den kompletten status des controllers nachgebaut :). mit ensprechdem wartungsaufwand wenn sich das nicht dokumentierte api ändert :(.
ich glaube man sollte eher umgekehrt ran gehen:
- was möchte ich erreichen: pressend erkennung, poe ports schalten, verbrauch aufzeichnen, ...
- und dann erst mal genau nur das das so einfach wie möglich einbauen
gruss
andre
ps: ich sehe das du den hmlan per poe betreibst. welchen poe splitter verwendest du da?
pps: gibt es noch andere anwender? von meiner seite spricht nichts gegen einchecken wenn keiner probleme hatte.
ja sehe ich auch so. Zu readingsProxy muss ich gestehen, damit habe ich noch nicht gearbeitet, wenn du da was für den unifi parat hast, gerne mal posten :)
Für HMLan den hier:
https://smile.amazon.de/gp/product/B01EH4M782
+
https://de.aliexpress.com/item/5A-DC-DC-Step-Down-Adjustable-Power-Supply-Module-DC-DC-Step-Down-Voltage-Regulator-Kit/32486868611.html
um auf 7,5 V zu kommen
+
https://de.aliexpress.com/item/5pcs-lot-injuection-molding-IP54-ABS-plastic-diy-project-case-for-device-62-37-25mm/32753650496.html
weil ich die eh rumfliegen hatte und alles relativ gut reingepasst hat.
ein Poe Splitter auf 7,5 V habe ich nur für über 30€ gefunden, das war mir zu teuer.
Grüße
Hi,
Zitat von: Christian Uhlmann am 03 Mai 2017, 21:55:01
Zu readingsProxy muss ich gestehen, damit habe ich noch nicht gearbeitet, wenn du da was für den unifi parat hast, gerne mal posten :)
geil, klappt super. hier mein beispiel:
define <name> readingsProxy <unifi device>:<reading vom geschalteten Gerät>_state
attr <name> devStateIcon on:it_net@green off:it_net@red
attr <name> icon it_network
attr <name> setFn {($CMD eq "on")?"poeMode <name|mac|id vom Gerät an dem der Port geschaltet wird> <port> poe+":"poeMode <name|mac|id vom Gerät an dem der Port geschaltet wird> <port> off"}
attr <name> setList on off
attr <name> valueFn {($VALUE eq "ok")?"on":"off"}
zu beachten, bei mir war <reading vom geschalteten Gerät> mit Leerzeichen, das mochte readingsProxy nicht (oder ich hab keine möglichkeit dazu gefunden).
Dabei fällt mir auf, es könnte sinn machen ein reading je poe port zu erzeugen, in dem der status angezeigt wird.
dann muss man beim ausschalten nicht drauf warten, bis das gerät an diesem port nicht mehr als online erkannt wird.
weil wenn der port aus ist, ist das gerät ja sowieso sofort aus.
ebenso wäre der verbrauch pro port interessant und nicht nur die summen.
also wünsche ich mir 2 neue readings je poe port. eins mit dem status und eins mit dem verbraucht :-[
Grüße
Christian
wäre es als zusätzliche Funktion möglich die WLAN Utilization als Reading zu bekommen? Der neueste Controller 5.4.15 aus dem Debian Repository unterstützt dieses :-)
Gruß und Dank
Ralf
die angehängte version hat pro accesspoint ein _utilizationNA und _utilizationNG reading und lässt für switche das essid reading weg.
gruss
andre
Zitat von: justme1968 am 12 Mai 2017, 22:47:23
die angehängte version hat pro accesspoint ein _utilizationNA und _utilizationNG reading und lässt für switche das essid reading weg.
gruss
andre
wow, danke für die schnelle Umsetzung :-)
Es geht
Hallo,
gibt's was neues bzgl. Ein/Aus Gast WLAN und password setzen?
Gruß
Eisix
Ich habe festgestellt das ich lt. Perfmon einige Freezes habe (jeweils jede Stunde).
Mit verbose 5 habe ich jetzt festgestellt das es am Unifi Modul liegt.
2017.05.23 11:35:38 1: Perfmon: possible freeze starting at 11:35:37, delay is 1.967
2017.05.23 11:35:38 5: my_unifi_controller (Unifi_DoUpdate) - executed.
2017.05.23 11:35:38 5: my_unifi_controller (Unifi_GetAccesspoints_Send) - executed.
2017.05.23 11:35:38 5: HttpUtils url=https://192.168.0.14:8443/api/s/default/stat/device
Kann mir jemand sagen was das bedeutet?
Danke!
hallo claudiu,
wie besprochen habe ich die version mit den poe erweiterungen jetzt eingecheckt.
wenn ich dazu komme schaue ich mir die anderen wünsche auch mal an und poste hier wieder eine test version. ich weiss aber nicht wann das sein wird.
gruss
andre
Hi Andre,
danke dir, bin die Woche in DE und probiere es aus.
Will auch so einen Switch :)
Hi, habe gerade das unifi-Modul aktiviert, funktioniert soweit super, vielen Dank für die Arbeit, die da von einigen hineingesteckt wurde!
Was mir aufgefallen ist: Der ziemlich am Anfang gepostete Perl-Code für die PRESENCE-Funktion funktioniert nicht:
Zitat von: rapster am 23 August 2015, 19:39:03
oder 3 Minuten mit einem notify:
define ntfy_unifi_presence notify myUnifiController:MyClient_last_seen:.* {
if (time() - time_str2num($EVENT) > 180) {
fhem("set dummy disconnected");
} else {
fhem("set dummy connected");
}
}
$EVENT enthält ja auch das Reading. Hier klappt es nur mit:
define ntfy_unifi_presence notify myUnifiController:MyClient_last_seen:.* {
if (time() - time_str2num($EVTPART1." ".$EVTPART2) > 180) {
fhem("set dummy disconnected");
} else {
fhem("set dummy connected");
}
}
Und dann noch eine Frage: Könnte man in das Modul das Blocken und Entblocken einzelner Geräte aufnehmen? Derzeit läuft das noch über ein Bash-Skript, aber ich denke, das würde in diesem Modul viel Sinn machen für alle die, die die elterliche Zugangskontrolle nicht über das Abschalten des WLANs, sondern das Blocken einzelner Geräte umsetzen. :)
Die Kommandos dazu für den stamgr sind block-sta und unblock-sta. D.h. es sollte sich wohl durch folgende Funktion einbauen lassen:
sub Unifi_BlockClient_Send($@) {
my ($hash,@clients) = @_;
my ($name,$self) = ($hash->{NAME},Unifi_Whoami());
Log3 $name, 5, "$name ($self) - executed with count:'".scalar(@clients)."', ID:'".$clients[0]."'";
my $id = shift @clients;
HttpUtils_NonblockingGet( {
%{$hash->{httpParams}},
url => $hash->{unifi}->{url}."cmd/stamgr",
callback => \&Unifi_BlockClient_Receive,
clients => [@clients],
data => "{'mac': '".$hash->{clients}->{$id}->{mac}."', 'cmd': 'block-sta'}",
} );
return undef;
}
###############################################################################
sub Unifi_BlockClient_Receive($) {
my ($param, $err, $data) = @_;
my ($name,$self,$hash) = ($param->{hash}->{NAME},Unifi_Whoami(),$param->{hash});
Log3 $name, 5, "$name ($self) - executed.";
if ($err ne "") {
Unifi_ReceiveFailure($hash,{rc => 'Error while requesting', msg => $param->{url}." - $err"});
}
elsif ($data ne "") {
if ($param->{code} == 200 || $param->{code} == 400 || $param->{code} == 401) {
eval { $data = decode_json($data); 1; } or do { $data = { meta => {rc => 'error.decode_json', msg => $@} }; };
if ($data->{meta}->{rc} eq "ok") {
Log3 $name, 5, "$name ($self) - state:'$data->{meta}->{rc}'";
}
else { Unifi_ReceiveFailure($hash,$data->{meta}); }
} else {
Unifi_ReceiveFailure($hash,{rc => $param->{code}, msg => "Failed with HTTP Code $param->{code}."});
}
}
if (scalar @{$param->{clients}}) {
Unifi_BlockClient_Send($hash,@{$param->{clients}});
}
return undef;
}
bzw.
sub Unifi_UnblockClient_Send($@) {
my ($hash,@clients) = @_;
my ($name,$self) = ($hash->{NAME},Unifi_Whoami());
Log3 $name, 5, "$name ($self) - executed with count:'".scalar(@clients)."', ID:'".$clients[0]."'";
my $id = shift @clients;
HttpUtils_NonblockingGet( {
%{$hash->{httpParams}},
url => $hash->{unifi}->{url}."cmd/stamgr",
callback => \&Unifi_UnblockClient_Receive,
clients => [@clients],
data => "{'mac': '".$hash->{clients}->{$id}->{mac}."', 'cmd': 'unblock-sta'}",
} );
return undef;
}
###############################################################################
sub Unifi_UnblockClient_Receive($) {
my ($param, $err, $data) = @_;
my ($name,$self,$hash) = ($param->{hash}->{NAME},Unifi_Whoami(),$param->{hash});
Log3 $name, 5, "$name ($self) - executed.";
if ($err ne "") {
Unifi_ReceiveFailure($hash,{rc => 'Error while requesting', msg => $param->{url}." - $err"});
}
elsif ($data ne "") {
if ($param->{code} == 200 || $param->{code} == 400 || $param->{code} == 401) {
eval { $data = decode_json($data); 1; } or do { $data = { meta => {rc => 'error.decode_json', msg => $@} }; };
if ($data->{meta}->{rc} eq "ok") {
Log3 $name, 5, "$name ($self) - state:'$data->{meta}->{rc}'";
}
else { Unifi_ReceiveFailure($hash,$data->{meta}); }
} else {
Unifi_ReceiveFailure($hash,{rc => $param->{code}, msg => "Failed with HTTP Code $param->{code}."});
}
}
if (scalar @{$param->{clients}}) {
Unifi_BlockClient_Send($hash,@{$param->{clients}});
}
return undef;
}
Danke, Christian
presence kannst du inzwischen auch mit einem 'echten' PRESENCE device machen:define <name> PRESENCE function {ReadingsVal('unifi','mein-iPhone','') eq "connected" ? 1 : 0} 60 60
das hast den vorteil das man z.b. auch die threshold attribute für die hysterese verwenden kann und auch die roommate integration einfacher ist.
Zitat von: justme1968 am 01 Juli 2017, 11:26:32
presence kannst du inzwischen auch mit einem 'echten' PRESENCE device machen:define <name> PRESENCE function {ReadingsVal('unifi','mein-iPhone','') eq "connected" ? 1 : 0} 60 60
das hast den vorteil das man z.b. auch die threshold attribute für die hysterese verwenden kann und auch die roommate integration einfacher ist.
Danke für den Tipp .... jetzt ist meine "alte" Funktion auch weg :-)
Zitat von: Eisix am 16 Mai 2017, 11:03:59
gibt's was neues bzgl. Ein/Aus Gast WLAN und password setzen?
Ich weiß nicht, ob sich das schonmal jemand angeschaut hat. Wenn man in Firebug so beobachtet, was passiert, wenn man ein WLAN (de-)aktiviert, dann ist das wohl ein komplizierteres Unterfangen. Man muss wohl erst für die richtige ID die Daten des WLANs auslesen, dann den richtigen Parameter ändern und anschließend wieder alles zurückschreiben.
Möglicherweise könnte man alternativ ein WLAN per AP abschalten, aber da zeigte Firebug bei mir interessanterweise gar nichts an...
Also: Ich hätte diese Funktion auch gerne, aber im Gegensatz zum (Ent-)Blocken von einzelnen Usern (Code siehe oben) habe ich hier keine umsetzbare Idee.
Gruß, Christian
Hallo zusammen,
das hat an sich nichts mit Fhem zu tun, aber vllt kann mir ja einer von Euch dennoch helfen:
Ich habe den Unifi-Controller 5.2.9 auf einer VM mit Ubuntu 16.04 LTS laufen (wo auch mein Fhem läuft). Erst ist mir das gar nicht aufgefallen, aber dann doch, weil ich mich gewundert hatte, warum ich am iPhone kein WLAN hatte, als ich die VM mal rebootet habe. Mein Problem: Wenn der Controller nicht läuft, schaltet sich das WLAN ab und meine beiden APs blinken grün. Jmd ne Idee dazu?
Besten Dank im vorraus
Michael
Vielleicht die APs nochmal provisionieren? Hier funktionieren sind grundsätzlich auch weiter, wenn der Controller nicht mehr läuft.
Oder hast Du irgendwelche Funktionen aktiviert, die zwingend den Controller benötigen?
hat sich erledigt :)
Falls der Autor demnächst nochmal das Modul überarbeitet, wäre es prima wenn auch noch die Systemdaten (Temperatur, Energieverbrauch, Lüfterstufe etc) der Switche als reading übernommen wird.
Schonmal einen ganz großen Dank ... auch rückwirkend für das tolle Modul!
Hallo Comunity,
ich habe ein problem beim connecten mit dem Unifi Modul.
Ich bin mit FHEM auf einem Cubietruck - auf dem läuft auch der Unifi Controller 5.5.20.
Der Controller ist per Browser erreichbar, das Unifi Device in FHEM lässt sich aber nicht verbinden, es meldet im state "disconnected"
Ich habe verbose auf 5 gestellt und im Log geschaut...
2017.08.27 09:22:16 5: UnifiController (Unifi_Login_Receive) - executed.
2017.08.27 09:22:11 5: UnifiController (Unifi_Login_Send) - executed.
2017.08.27 09:21:41 5: UnifiController (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2017.08.27 09:21:41 5: UnifiController (Unifi_Login_Receive) - Error while requesting https://192.168.1.3:8443/api/login - https://192.168.1.3:8443/api/login: Can't connect(2) to https://192.168.1.3:8443: SSL wants a read first
2017.08.27 09:21:41 5: UnifiController (Unifi_Login_Receive) - executed.
2017.08.27 09:21:36 5: UnifiController (Unifi_Login_Send) - executed.
2017.08.27 09:21:36 5: UnifiController (Unifi_DoUpdate) - executed.
2017.08.27 09:21:36 5: UnifiController (Unifi_Notify) - executed. - Remove all Timers & Call DoUpdate...
2017.08.27 09:21:35 5: UnifiController: Defined with url:https://192.168.1.3:8443/api/s/default/, interval:30, version:4
2017.08.27 08:47:50 1: PERL WARNING: Use of uninitialized value $poeState in concatenation (.) or string at ./FHEM/74_Unifi.pm line 351.
2017.08.27 08:39:49 0: Server started with 49 defined entities (fhem.pl:14945/2017-08-22 perl:5.020002 os:linux user:fhem pid:9379)
2017.08.27 08:39:49 0: Featurelevel: 5.8
2017.08.27 08:39:48 1: Including ./log/fhem.save
2017.08.27 08:39:46 1: Including fhem.cfg
2017.08.27 08:39:43 0: Server shutdown
Andre gab mir den Tip mal bei die Perl Versionen zu schauen, aber auch hier komme ich nicht weiter...
root@cubietruck:~# perl -v
This is perl 5, version 20, subversion 2 (v5.20.2) built for arm-linux-gnueabihf-thread-multi-64int
(with 97 registered patches, see perl -V for more detail)
Copyright 1987-2015, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl". If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.
root@cubietruck:~# apt-get install libio-socket-ssl-perl
Reading package lists... Done
Building dependency tree
Reading state information... Done
libio-socket-ssl-perl is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Hat jemand eine Idee woran es liegt?
Wäre toll wenn ich das Modul ans laufen bekomme...
Vorweg mir gefällt das Modul wirklich super und ein riesen Dank an alle die hier so fleißig mitarbeiten.
Zitat von: Motivierte linke Hände am 03 Juli 2017, 10:55:57
Ich weiß nicht, ob sich das schonmal jemand angeschaut hat. Wenn man in Firebug so beobachtet, was passiert, wenn man ein WLAN (de-)aktiviert...
...
Also: Ich hätte diese Funktion auch gerne, aber im Gegensatz zum (Ent-)Blocken von einzelnen Usern (Code siehe oben) habe ich hier keine umsetzbare Idee.
Gruß, Christian
Was war denn mit dem Ansatz "disableSsid"?
Zitat von: rapster am 15 November 2016, 18:17:44
....
disableSsid <AP>_ALL_<SSID>
disableSsid ALL_ALL_<SSID>
disableSsid ALL_2G|5G_<SSID>
disableSsid ALL_ALL_ALL
disableSsid ALL_2G|5G_ALL
Im KNX Forum gibt es ein Modul dazu, eventuell ist es möglich mit Hilfe diesem eine gangbare Möglichkeit zu finden.
Zitathttps://service.knx-user-forum.de/?comm=download&id=19000728
Ich habe mir auch mal angesehen was beim setzen bzw entfernen des Haken bei Drahtlose-Netzwerke im Controller passiert.
Wie hier beschrieben:
Zitat von: rapster am 29 April 2017, 19:29:12
....
Hier zwei Bilder wie der Beispiel CMD und URL im Firefox mit F12 -> Netzwerkanalyse nach Klick auf den Beispiel "Unset-Locate Button" herausgefunden werden kann.
Vorweg möchte ich noch sagen, dass meine Programmierkentnisse leider nicht wirklich gut sind :(
Sind denn alle Parameter die gesendet werden notwendig um das Drahtlose-Netzwerk ein bzw aus zu schalten? Im direkten Vergleich ändert sich nur eine Zeile
enabled: false
enabled: true
Anschließend folgen noch einige Werte die ich nicht direkt zuordnen konnte, aber auch Werte die in FHEM schon bekannt sind bzw die Erweiterten Einstellungen des Drahtlos-Netzwerk beschreiben.
Wäre dankbar wenn ihr sonst noch Tipps/Hilfestellungen für mich habt, würde gerne probieren ob es keine Möglichkeit gibt die Netzwerke einfach in FHEM zu starten/beenden.
Moin Leute,
ich habe das gleiche Problem mit dem Unifi Controller 5.5.20 wie der-Lolo. Habe auch schon etwas herumprobiert aber leider ohne Erfolg. Da das Modul in der Hilfe sagt, es sei für Version 3 und 4 geschrieben, wird Version 5 wahrscheinlich nicht mehr ganz kompatibel sein, oder es liegt ggf. an der SSL Verbindung, die im neueren Modul ggf. alte SSL Versionen (v2,v3, TLSv1) abgeschaltet hat.
Ich würde gern zu einer Lösung beitragen, bin mir aber nicht sicher, wer das Modul entwickelt hat und ob hier die Möglichkeit der gemeinsamen Lösungsfindung möglich ist?
Falls ja, bitte einfach kurz melden!
Vielen Dank und ein schönes WE!
Zitat von: der-Lolo am 27 August 2017, 10:06:29
Hallo Comunity,
ich habe ein problem beim connecten mit dem Unifi Modul.
Ich bin mit FHEM auf einem Cubietruck - auf dem läuft auch der Unifi Controller 5.5.20.
Der Controller ist per Browser erreichbar, das Unifi Device in FHEM lässt sich aber nicht verbinden, es meldet im state "disconnected"
Ich habe verbose auf 5 gestellt und im Log geschaut...
2017.08.27 09:22:16 5: UnifiController (Unifi_Login_Receive) - executed.
2017.08.27 09:22:11 5: UnifiController (Unifi_Login_Send) - executed.
2017.08.27 09:21:41 5: UnifiController (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2017.08.27 09:21:41 5: UnifiController (Unifi_Login_Receive) - Error while requesting https://192.168.1.3:8443/api/login - https://192.168.1.3:8443/api/login: Can't connect(2) to https://192.168.1.3:8443: SSL wants a read first
2017.08.27 09:21:41 5: UnifiController (Unifi_Login_Receive) - executed.
2017.08.27 09:21:36 5: UnifiController (Unifi_Login_Send) - executed.
2017.08.27 09:21:36 5: UnifiController (Unifi_DoUpdate) - executed.
2017.08.27 09:21:36 5: UnifiController (Unifi_Notify) - executed. - Remove all Timers & Call DoUpdate...
2017.08.27 09:21:35 5: UnifiController: Defined with url:https://192.168.1.3:8443/api/s/default/, interval:30, version:4
2017.08.27 08:47:50 1: PERL WARNING: Use of uninitialized value $poeState in concatenation (.) or string at ./FHEM/74_Unifi.pm line 351.
2017.08.27 08:39:49 0: Server started with 49 defined entities (fhem.pl:14945/2017-08-22 perl:5.020002 os:linux user:fhem pid:9379)
2017.08.27 08:39:49 0: Featurelevel: 5.8
2017.08.27 08:39:48 1: Including ./log/fhem.save
2017.08.27 08:39:46 1: Including fhem.cfg
2017.08.27 08:39:43 0: Server shutdown
Andre gab mir den Tip mal bei die Perl Versionen zu schauen, aber auch hier komme ich nicht weiter...
root@cubietruck:~# perl -v
This is perl 5, version 20, subversion 2 (v5.20.2) built for arm-linux-gnueabihf-thread-multi-64int
(with 97 registered patches, see perl -V for more detail)
Copyright 1987-2015, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl". If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.
root@cubietruck:~# apt-get install libio-socket-ssl-perl
Reading package lists... Done
Building dependency tree
Reading state information... Done
libio-socket-ssl-perl is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Hat jemand eine Idee woran es liegt?
Wäre toll wenn ich das Modul ans laufen bekomme...
Also hier funktioniert es mit der 5.5.20. An einer generellen Inkompatibilität mit der Version kann es nicht liegen.
Wie hast Du denn den Controller in fhem definiert?
bei mir funktioniert es problemlos mit 5.5.x und 5.6.x
es liegt definitiv nicht an der controller version.
ich tippe auf die umgebung auf dem controller rechner oder auf perl seite und würde versuchen beides mal auf einem normalen intel system probieren.
welches java ist auf dem controller rechner installiert?
Wenn der Controller nicht auf dem Cubitruck läuft funktioniert das Modul bei mir auch problemlos...
Ich glaube die Controller Software auf einen ARM Prozessor laufen zu lassen ist einfach schwierig, wenn der Controller läuft ist ein Kern ständig zwischen 80 und 100% Last - ich habe kurzen Prozess gemacht und mir einen Cloud-Key bestellt.
der cloudkey funktioniert bei mir sehr gut. wichtig ist aber eine usv. er mag es garnicht wenn der strom plötzlich weg ist.
Zitat von: justme1968 am 06 September 2017, 16:16:25
der cloudkey funktioniert bei mir sehr gut. wichtig ist aber eine usv. er mag es garnicht wenn der strom plötzlich weg ist.
kann ich den Cloudkey einfach in meinen POE Switch dengeln und gut ist - inclusive fhem Unterstützung?
Zitat von: Wuppi68 am 06 September 2017, 21:16:52
kann ich den Cloudkey einfach in meinen POE Switch dengeln und gut ist - inclusive fhem Unterstützung?
Der Cloud kann poe
Ich betreibe ihn ohne poe hab einfach kennen Switch. Da er einen Micro usb prot hat nehme ich diesen zur Strom Versorgung.
FHEM Unterstützung?
Gesendet von iPhone mit Tapatalk Pro
Zitat von: no_Legend am 07 September 2017, 09:11:03
FHEM Unterstützung?
damit meine ich die Unterstützung von diesem Modul :-) Geht das?
Kann ich dir nicht genau sagen.
Ich habe das Modul zur Zeit nicht in Betrieb.
Hab andere Sachen die eher brennen.
Eventuell kann dir jemand Anderst hier weiter helfen.
Gesendet von iPhone mit Tapatalk Pro
Zitat von: Wuppi68 am 07 September 2017, 09:14:49
damit meine ich die Unterstützung von diesem Modul :-) Geht das?
Der Cloudkey ist ja "nur" ein kleiner Rechner, auf dem die passende Software vorinstalliert läuft. Ich habe den Unifi-Controller hier einfach in einer VM laufen, aber ich wüsste nicht, warum das mit dem Cloudkey anders funktionieren sollte. Du musst halt nur den Cloudkey samt IP in FHEM konfigurieren, denke ich mal.
Zitat von: Motivierte linke Hände am 07 September 2017, 10:22:42
Der Cloudkey ist ja "nur" ein kleiner Rechner, auf dem die passende Software vorinstalliert läuft. Ich habe den Unifi-Controller hier einfach in einer VM laufen, aber ich wüsste nicht, warum das mit dem Cloudkey anders funktionieren sollte. Du musst halt nur den Cloudkey samt IP in FHEM konfigurieren, denke ich mal.
na denn ist ja alles gut :-)
Danke
Ich habe ein etwas seltsames verhalten bei der Einbindung vom UniFi Controller für Presence.
Das Problem ist, wenn ich mit dem Handy außer Haus gehe wird nach ca 5 Minuten korrekt erkannt dass das Handy weg ist.
Allerdings wandert der Eintrag dann auf einen meiner Switche und wird als "connected" angezeigt.
Wie kommt der Controller dadrauf, dass mein Handy an einem der Switche connected sein soll ?
PhonevonXXX connected 2017-09-11 08:39:28
iPhonevonXXX_accesspoint Switch Wohnzimmer 2017-09-11 08:39:28
iPhonevonXXX_hostname iPhonevonXXX 2017-09-11 08:39:28
iPhonevonXXX_last_seen 2017-09-11 08:38:09 2017-09-11 08:39:28
iPhonevonXXX_uptime 50754 2017-09-11 08:39:28
Der Access Point hängt auch nicht am besagten Switch sondern am Core Switch im Keller, dort taucht die MAC aber auch nicht mehr in der ARP Table oder ähnlichem auf.
Das Problem ist zumindest auch nicht IOS spezifisch, am Android Handy meiner Frau sieht es ähnlich aus.
Könnte man ggf. für presence noch auf eine Liste der gültigen Accesspoints filtern ?
Danke für eure Ideen.
das ist ein bekanntes problem/bug auf unifi seite. es hat nichts mit dem modul oder irgendwelchen endgeräten zu tun.
ich persönlich finde die längere zeit bis zum absent sehr praktisch. aber wenn du das nicht magst kannst du einfach den function code deines presence device so erweitern das auch noch das access point reading ausgewertet wird.
dem unify modul könnte man noch readings für den ap typ (wireless/switch) verpassen. das würde es einfacher machen.
dies generell und automatisch bei presence zu berücksichtigen geht aber nicht weil es anwender gibt die auch fest verkabelte geräte überwachen.
Die 5 Minuten stören mich auch nicht weiter. Mich stört lediglich, dass ein Wireless Device an einem Switch angezeigt wird wo es niemals sein kann.
ich habe keine ahnung ob ubiquiti es als bug oder feature oder was auch immer sieht und ob sie es irgendwann ändern. aber es gibt im unify forum einige diskussionen darüber ohne offizielle stellungnahme.
Ich probiere es mal wie von dir vorgeschlagen mit Erweiterung des Presence Checks auf die Access Points.
Alternativ mal schauen ob ich nur die Access Points einer anderen Instanz im Controller zuweisen kann, dann könnte ich auch nur auf diese abfragen.
Hallo zusammen,
habe das Problem, dass sich mein State von unifi alle paar Sekunden von connected auf disconnected und wieder zurück ändert.
Wo könnte ich ggf. ansetzen, um den Fehler zu finden?
Zitat von: blane am 15 September 2017, 08:26:19
Hallo zusammen,
habe das Problem, dass sich mein State von unifi alle paar Sekunden von connected auf disconnected und wieder zurück ändert.
Wo könnte ich ggf. ansetzen, um den Fehler zu finden?
Ohne genaue Angaben wird dir keiner Helfen können.
Was hast du genau für Hardware usw.?
Gruß Robert
Zitat von: blane am 15 September 2017, 08:26:19
Hallo zusammen,
habe das Problem, dass sich mein State von unifi alle paar Sekunden von connected auf disconnected und wieder zurück ändert.
Wo könnte ich ggf. ansetzen, um den Fehler zu finden?
Wo läuft der Controller? Läuft der Controller? Kannst du per Webinterface drauf zugreifen?
Zitat von: gloob am 15 September 2017, 13:27:52
Wo läuft der Controller? Läuft der Controller? Kannst du per Webinterface drauf zugreifen?
Ja der Controller läuft auf einem Cloud Key und ist erreichbar.
gibt es eine option das Gäste Wlan ein/aus zu schalten??
Hallo,
meines Wissens nach nicht im Modul. Es gab mal eine Version bei der man Netze pro AP und Frequenz abschalten konnte.
Ich hätte auch Interesse an der Gast WLAN Funktion. Bei mir rennen zu viele Freundinnen/Freunde meiner Kinder rum und ich befürchte mein WLAN Password könnte irgendwann mal verteilt werden.
Gruß
Eisix
Interesse an der Funktion hätte ich auch. Allerdings habe ich noch keine Möglichkeit gefunden, sowas einfach umzusetzen...
Zur Not einfach einen Managed Switch vorhängen und das Gäste Wlan per Vlan mappen. Dann kannst du, recht einfach, per Script den Port deaktivieren und das zugehörige Wlan ist aus ;)
Ja, wobei... :)
Hier führt das Gäste-WLAN ins selbe VLAN wie das normale WLAN. Kinder, Freunde, Interaktion, Broadcasts etc... Wenn man nicht das ständige Genöle haben will, dass "das Internet" nicht funktioniert, weil die mobilen Geräte der Gäste und der Bewohner sich gegenseitig nicht finden, ist das die (für mich) einfachste Art der Umsetzung (einfacher als multicast across subnets).
Workarounds gibt es sicher. Da die Unifi-APs die Funktionalität aber grundsätzlich anbieten, wäre es sehr schön, wenn man das auch in fhem einfach erreichen könnte. Dann kann die Frau, die sich inzwischen gnädigerweise an die Haussteuerung über's Tablet ein wenig gewöhnt hat, dort den Knopf drücken, wenn Internetzugang für junge Gäste stattfinden soll.
Über die Unifi App geht es natürlich auch, aber für jede Funktion eine andere App ist auch nicht gerade benutzerfreundlich. 8)
ja genau das wäre schön wenn es irgendwann mal eingebaut wird. Dann kann ich es auch im TebeltUI hinterlegen wie bei der Fritzbox :)
Zitat von: Motivierte linke Hände am 20 September 2017, 13:28:39
Ja, wobei... :)
Hier führt das Gäste-WLAN ins selbe VLAN wie das normale WLAN. Kinder, Freunde, Interaktion, Broadcasts etc... Wenn man nicht das ständige Genöle haben will, dass "das Internet" nicht funktioniert, weil die mobilen Geräte der Gäste und der Bewohner sich gegenseitig nicht finden, ist das die (für mich) einfachste Art der Umsetzung (einfacher als multicast across subnets).
Workarounds gibt es sicher. Da die Unifi-APs die Funktionalität aber grundsätzlich anbieten, wäre es sehr schön, wenn man das auch in fhem einfach erreichen könnte. Dann kann die Frau, die sich inzwischen gnädigerweise an die Haussteuerung über's Tablet ein wenig gewöhnt hat, dort den Knopf drücken, wenn Internetzugang für junge Gäste stattfinden soll.
Über die Unifi App geht es natürlich auch, aber für jede Funktion eine andere App ist auch nicht gerade benutzerfreundlich. 8)
wenn schon nicht ein eigenes wirkliches Gast LAN dann würde ich dir Gast Funktion vom UNIFI nehmen und Vouchers einfach wochenweise/monatsweise ausstellen - Du kannst ja einfach viele ausdrucken, oder in der APP zur Verfügung stellen. Funktioniert bei mir ganz gut :-) Und hast Du "Dauergäste" können die auch länger ausgestellt werden und Du kannst es jederzeit auch wieder rlöschen
Zitat von: Wuppi68 am 21 September 2017, 10:29:13
wenn schon nicht ein eigenes wirkliches Gast LAN dann würde ich dir Gast Funktion vom UNIFI nehmen und Vouchers einfach wochenweise/monatsweise ausstellen
Das mache ich ja so. Nur halt mit einer eigenen SSID, denn natürlich will ich die Gast Funktionen nicht in meiner Standard-SSID haben, und ich möchte meinen WPA-Key nicht Gästen geben.
Wenn ich das Gast-WLAN aber nicht brauche, schalte ich es komplett aus. Und wenn man diese Funktion benutzerfreundlich in fhem bekäme, das wäre m.E. optimal.
Ok, ich hab's geschafft, mir einen Gäste-WLAN-Schalter zu basteln. :)
Und zwar geht das über die API für Unifi (https://github.com/Art-of-WiFi/UniFi-API-client (https://github.com/Art-of-WiFi/UniFi-API-client)) und dann zwei php-Skripte dazu, die man dann bei Bedarf aus fhem heraus starten kann.
Mein Skript zum Deaktivieren (für's Aktivieren verwende ich dasselbe Skript mit "true" statt "false") findet Ihr hier: https://community.ubnt.com/t5/UniFi-Wireless/UniFi-API-browser-tool-updates-and-discussion/td-p/1392651/highlight/false/page/18 (https://community.ubnt.com/t5/UniFi-Wireless/UniFi-API-browser-tool-updates-and-discussion/td-p/1392651/highlight/false/page/18)
Falls jemand das brauchen kann/kopieren möchte: Viel Spaß!
Hallo Gast-WLAN Nutzer,
Auf Seite 18 dieses Threads habe ich meine Anfängerversion zum Auslesen und aerzeugen von Vouchers aus Unifi-AP gepostet. Die Voucher können die Kinder dann per Telegram-Chat anfordern. Funktioniert und ist akzeptiert. Vielleicht passt die Idee ja auch in eurem Umfeld ;-)
Zitat von: Wuehler am 24 September 2017, 22:46:37
Hallo Gast-WLAN Nutzer,
Auf Seite 18 dieses Threads habe ich meine Anfängerversion zum Auslesen und aerzeugen von Vouchers aus Unifi-AP gepostet. Die Voucher können die Kinder dann per Telegram-Chat anfordern. Funktioniert und ist akzeptiert. Vielleicht passt die Idee ja auch in eurem Umfeld ;-)
Interessanter Ansatz, neuer Thread und neues Modul?
Würde vom Inhalt aber auch sehr gut in dieses Modul passen, oder?
Hallo,
Habe seit einem update die Tage folgendes Problem
2017.09.27 10:59:09 5: myUnifi (Unifi_Login_Receive) - executed.
2017.09.27 10:59:09 5: myUnifi (Unifi_Login_Receive) - Login Failed! - state:'error.decode_json' - msg:'JSON text must be an object or array (but found number, string, true, false or null, use allow_nonr
ef to allow this) at ./FHEM/74_Unifi.pm line 526.
'
2017.09.27 10:59:09 5: myUnifi (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2017.09.27 10:59:10 3: Wetter: JSON text must be an object or array (but found number, string, true, false or null, use allow_nonref to allow this) at FHEM/YahooWeatherAPI.pm line 247.
Da scheint was mit dem decode_json schief zu gehen.
Interessanterweise habe ich das Problem auch mit anderen devices:
2017.09.27 10:59:13 2: ESPEasy espBridge_192.168.178.131_20309: WARNING: Invalid JSON received. Check your ESP configuration (192.168.178.131).
JSON text must be an object or array (but found number, string, true, false or null, use allow_nonref to allow this) at ./FHEM/34_ESPEasy.pm line 736.
Kann hier jemand helfen?
Gruß
Carlos
libjson-perl oder so aktualisiert, versehentlich deinstalliert, etc.?
Nur 'ne Vermutung.
such mal im forum es gibt diverse threads mit diesem problem.
bis jetzt war immer das HMCCU modul beteiligt.
Tatsächlich, das HMCCU modul ist das Problem.
Hab ich diese Woche installiert und seit dem existiert das Problem.
Habe jetzt mal die Threads durchgelesen und auf den internen rpc server umgestellt.
Und siehe da, der Fehler ist weg ,auch mein FHEM stürzt nicht mehr ab.
Mal sehen wie das weiter geht.
Danke für die Hilfe.
Gruß
Carlos
Hallo Carlos,
kannst du bitte mal genau beschreiben, was du gamcht hast. Ich versuche auch den UniFi Controller seit 2 Stunden einzubinden und bekomme die gleiche Fehlermeldung.
Besten Dank
Axel
update:06.10.2017 Controllersoftware auf dem Raspberry nocheinmal aufgespielt, seit dem läuft das Modul. :)
Hallo,
erstmal ein großes Lob an den/die Entwickler, ein wirklich großartiges Modul.
Eine kleine Feature Anfrage habe ich trotzdem: ist es vielleicht möglich anstatt den Hostnamen in den Readings die vergebenen Alias aus der Controllersoftware zu nutzen? Oder ist das nicht möglich wg. erlaubten Leerzeichen etc?
Gruß Mohrengemuse
Entschuldigt, ich hab mir meine Frage selbst beantwortet. Kaum entfernt man die Leerzeichen, werden die Alias verwendet. Top!
Hi,
ist es irgendwie in näherer Zukunft geplant das Modul mit GastWlan Steuerung und Voucher abfrage zu erweitern ? bzw. dies zu implementieren ?
Habe gerade auf Seite 19 nen Beitrag @Wuehler gefunden, wonach dies irgendwie schon möglich scheint.
Nur leider bin ich da noch nicht ganz durchgestiegen, was sich dafür installieren muss, bzw. welche Script wohin. (Werd ich mich später nochmal genauer ansehen)
Ebenso finde ich den Beitrag von @Motivierte linke Hände interessant. Verstehe nur noch nicht wie ich das Unifi Api installieren muss oder so ?
Dachte die Grundlage dieses Modul ist das UnifiApi ?
Ich hoffe ich habe nicht zu wirr geschrieben und ihr könnt mir weiterhelfen ?
Grüße & danke vorab
Totti
P.S.: Riesen Lob und Dank noch für das Modul. Ist einfach genial alle meine Unifi Produkte hiermit einzubinden. Top.
(Jetzt brachte ich nur noch was um meine zwei Nanaobeam AC einzubinden, um sie neu starten zu können ;) )
Hallo Totti,
für Modulentwicklung oder Erweiterung bin ich in fhem leider nicht fit genug bzw. habe zu wenig Zeit mich einzuarbeiten. Leider habe ich damals auch keinen Input für den besten Ansatz bekommen, wie man die Voucher-Thematik einbaut. D
Die von Motivierte Hände genutzte API ist (soweit ich auf die Schnelle sehe) "nur" ein php-Script. Dazu musst du php installieren (falls nicht schon vorhanden). Dann müsstest du von der console sein Script aufrufen können (wenn die Unifi-Php-API im selben Verzeichnis liegt).
Aus Tablet-UI kann man soetwas dann folgendermaßen aufrufen (hier ein perl-script). Der system-Befehl geht z.B. auch in einem notify:
<div data-type="link"
data-color="white"
data-width="120" data-height="30"
data-background-color="green"
data-device="dummy_Vertretungsplan"
data-set="doUpdate"
data-set-on="inProgress"
data-fhem-cmd="{system('/mount/DiskStation/runVertretungsplan.sh&');;return 0}"
class="round centered">
Gruß,
Wühler
Hi,
Danke für die Rückmeldung !
Wie hast Du denn deine Scripts umgesetzt ? Also das mit der Unifi Api ?
Hast Du auf dem FHEM gerät unter ssh:
git clone https://github.com/Art-of-WiFi/UniFi-API-client.git
gecloned ?
Und dann wo wie dein Script eingefügt.
Für mich als Anfänger wäre ich dankbar für eine "kleine" Hilfestellung ;)
Grüße & Danke
Totti
Genau, git clone der API, z.B. nach /usr/local/src/Unifi_API. Wobei Du eigentlich nur Client.php brauchst.
Dann lädst Du Dir aus dem Verzeichnis examples noch config_template.php herunter, passt dort drin Deine Daten an und benennst es in config.php um.
Und dann verwendest Du am einfachsten wohl folgendes Script:
<?php
/**
* PHP UniFi API by Art of Wifi
* usage example to disable SSID
*/
/**
* include the config file (place your credentials etc. there if not already present)
* see the config.template.php file for an example
*/
require_once('Client.php');
require_once('config.php');
$site_id = 'default';
function PrintArgsAndExit($error) {
echo "\n$error\n\n";
echo "Gültige Argumente:\n\n";
echo " status SSID -> Status des WLANs anzeigen\n";
echo " enable SSID -> SSID aktivieren\n";
echo " disable SSID -> SSID deaktivieren\n";
echo "\nAbbruch.\n";
exit(1);
}
if ($argc < 2) PrintArgsAndExit("Kommandozeilenargument fehlt.");
if ($argc < 3) PrintArgsAndExit("SSID nicht angegeben.");
$command = strtolower($argv[1]);
$SSID = $argv[2];
if ($command != "status" && $command != "enable" && $command != "disable") PrintArgsAndExit("Unbekanntes Kommandozeilenargument $command.");
/**
* initialize the UniFi API connection class and log in to the controller and do our thing
*/
$unifi_connection = new UniFi_API\Client($controlleruser, $controllerpassword, $controllerurl, $site_id, $controllerversion);
$set_debug_mode = $unifi_connection->set_debug($debug);
$loginresults = $unifi_connection->login();
/**
* read all configured SSIDs
*/
$data = $unifi_connection->list_wlanconf();
echo json_encode($data, JSON_PRETTY_PRINT);
/**
* Look for correct SSIDs and store id
*/
$names = array_column($data, 'name');
echo "\nNames:\n";
print_r($names);
$wlan = array_search($SSID, $names);
if ($wlan === false) {
echo "SSID $SSID nicht gefunden. Abbruch.\n";
exit(2);
} else {
echo "\narray_search Ergebnis: ";
echo $wlan;
echo "\n";
}
$id = $data[$wlan]->_id;
if ($command == "status") {
if ($data[$wlan]->enabled) {
echo "enabled";
} else {
echo "disabled";
}
} elseif ($command == "disable") {
/**
* Change "enabled" to "false" and write it back
*/
$data[$wlan]->enabled = false;
$results = $unifi_connection->set_wlansettings_base($id, $data[$wlan]);
if ($results == 1) {
echo "disabled";
} else {
echo "error";
}
} else {
/**
* Change "enabled" to "true" and write it back
*/
$data[$wlan]->enabled = true;
$results = $unifi_connection->set_wlansettings_base($id, $data[$wlan]);
if ($results == 1) {
echo "enabled";
} else {
echo "error";
}
}
Dieses Script kannst Du von der Kommandozeile laufen lassen und mal gucken, ob es bei Dir klappt (sind Debug-Ausgaben drin). Am besten versuchst Du einfach mal
php <scriptname> status <SSID_Deines_Gäste_WLANs>
und schaust, was passiert. Wenn keine Fehler kommen, müsstest Du das WLAN einschalten
php <scriptname> enable <SSID_Deines_Gäste_WLANs>
und ausschalten
php <scriptname> disable <SSID_Deines_Gäste_WLANs>
können.
Mohrengemuse hatte damit anfangs einige Probleme. Ob er sie lösen konnte, weiß ich nicht.
Grüße, Christian
@ Motivierte linke Hände
Danke !
Ich habe die Nacht noch erfolglos ein wenig rumprobiert.
Werde es mit deiner "Anleitung" später nochmal von vorne probieren.
Aber ich glaube ich stelle mich was dämlich an :-\
Daher mal noch ne ganz doofe Frage und um Missverständnisse auszuräumen ?
Auf welchem Gerät packe ich welches Script ? Auf dem NUC auf dem FHEM läuft oder auf den CloudKey wo der Unifi Controller läuft ?
Oder geht das ganze nur wenn z.B. beides auf einem Pi läuft ?
Grüße & Danke
Totti
P.S.: Ich hoffe ich spame den Thread jetzt nicht unnötig mit meinen Newbie Fragen voll :(
Das Skript kann erstmal "irgendwo" laufen; es ist zum Test, ob das Skript bei Dir überhaupt funktioniert.
Was Du später - wenn das Skript mal läuft - brauchst, ist eine Möglichkeit, dieses Skript aus FHEM heraus zu starten, wenn Du einen Knopf drückst. Von daher ist es sicherlich geschickt, wenn Du das Skript direkt auf dem NUC installierst.
Die Integration in FHEM kann über ein notify o.ä. laufen. Du musst hat nur schauen, dass Du das Skript mit den richtigen Parametern aufrufst, wenn das Gäste WLAN geschaltet werden soll.
Hier z.B.:
if ($Status eq 'disabled') {
system('/usr/local/bin/guest_ssid_disable &');
} else {
system('/usr/local/bin/guest_ssid_enable &');
}
(Bzw. statt /usr/local/bin/<skript> direkt den php Aufruf aus meiner letzten Nachricht - ich habe das bei mir in Bash-Skripte gepackt, weil ich da teilweise noch andere Dinge drin mache.)
Grüße, Christian
Hi,
habe es jetzt mit Unterstützung von @Wuehler die Scripts soweit alle eingefügt etc und es hinbekommen.
Leider bekomme ich beim ausführen eine Fehler Meldung :( :
benutzer@NUC: /usr/local/src# php WLAN.php status Gastnetzwerk
PHP Notice: The PHP curl extension is not loaded. Please correct this before proceeding! in /usr/local/src/Client.php on line 56
PHP Fatal error: Uncaught Error: Call to undefined function UniFi_API\curl_init() in /usr/local/src/Client.php:2030
Stack trace:
#0 /usr/local/src/Client.php(98): UniFi_API\Client->get_curl_obj()
#1 /usr/local/src/WLAN.php(37): UniFi_API\Client->login()
#2 {main}
thrown in /usr/local/src/Client.php on line 2030
Ich habe curl nochmals installiert und das System neugestartet. Jedoch trotzdem der Fehler ?
Grüße
Totti
Welches Betriebssystem und welche PHP Version hast Du?
Für Ubuntu sollte, abhängig von der PHP-Version, funktionieren:
PHP 7: apt-get install php-curl
PHP 5.6: apt-get install php5.6-curl
PHP 5.5: apt-get install php5.5-curl
Ich nutze nen NUC mit Debian 9 und darauf FHEM.
Habe das Problem mit Curl gelöst bekommen.
Jetzt hab ich leider ne andere Fehlermeldung :( ...
PHP Notice: curl_setopt(): CURLOPT_SSL_VERIFYHOST no longer accepts the value 1, value 2 will be used instead in /usr/local/src/Client.php on line 2033
PHP Notice: cURL error: SSL certificate problem: self signed certificate in /usr/local/src/Client.php on line 110
falsePHP Warning: array_column() expects parameter 1 to be array, boolean given in /usr/local/src/WLAN.php on line 48
Names:
PHP Warning: array_search() expects parameter 2 to be array, null given in /usr/local/src/WLAN.php on line 51
array_search Ergebnis:
PHP Notice: Trying to get property of non-object in /usr/local/src/WLAN.php on line 63
PHP Notice: Trying to get property of non-object in /usr/local/src/WLAN.php on line 67
Debain9 stellt php 7 zu Verfügung damit scheint es Problem zu geben.
Muss jetzt mal schauen wie ich PHP wieder deinstalliert bekomme um dann php 5.6 zu installieren.
Grüße
Totti
Hi, bevor du das deinstallierst. Mach mal nen
echo $loginresult
Nach dem login. Könnte auch ein falsches Passwort sein.
Wenn ich es auf die s
schnelle richtig sehe kommt der erste Hinweis auch unter php 5.4. das zweite ist auch nur ein Hinweis. Und vor dem ersten echten error ist der login. Du musst user und pw des unifi controllers eingeben.
PHP7 habe ich hier auch. Daran sollte es nicht liegen. Versuch mal Wuehlers Tipp.
ich habe den Befehl:
echo $loginresults;
Im Script WLAN.php (Script von Motivierte linke Hände) eingefügt. Jedoch bekomme ich keine ausgäbe ?!?
@Motivierte linke Hände
Das Du auch php7 nutzt beruhigt mich schon mal. Den auf php 5.6 zu gehen wäre mit Debian Stretch auch schwierig.
Username und Passwort habe ich die genutzt, welche ich zum Login überBrowser zum Controller benötige.
Habe aber auch die Benutzerdaten für SSL probiert. Keine Veränderung !
CURLOPT_SSL_VERIFYHOST habe ich auf 2 gestellt, somit ist der Hinweis weg.
Jedoch Weiterhin:
PHP Notice: cURL error: SSL: unable to obtain common name from peer certificate in /usr/local/src/Client.php on line 110
falsePHP Warning: array_column() expects parameter 1 to be array, boolean given in /usr/local/src/WLAN.php on line 49
Names:
PHP Warning: array_search() expects parameter 2 to be array, null given in /usr/local/src/WLAN.php on line 52
array_search Ergebnis:
PHP Notice: Trying to get property of non-object in /usr/local/src/WLAN.php on line 64
PHP Notice: Trying to get property of non-object in /usr/local/src/WLAN.php on line 68
Grüße
Totti
EDIT !!!!!
So denn, es läuft !!!!
Habe nochmals komplett von vorne Angefangen und jetzt läuft es. Irgendwie hatte sich wohl nen Fehler eingeschlichen !
Jetzt wird weiter probiert !
Schau mal wie ich nen Button oder ähnliches in FTUI umsetzte und wie ich die "Voucher Abfrage" mit Telegram von Wuehler hinbekomme ?!?
Kurze Info. Für das WLAN.php Script ist php 7 Pflicht, da die Funktion array_column() erst ab dann mit Object-Array zurechtkommt.
Riesen Dank euch !!!!
Habe jetzt erst einmal alles so umgesetzt das es funktioniert.
Werde wenn mal Zeit ist, schauen wie ich einen Voucher Abruf ins FTUI umgesetzt bekommen. Am besten mit einem "Auswahl Rädchen" bei dem ich angebe für welchen Zeitraum ein Voucher erstellt werden soll.
Mal nachlesen, wie ich Werte an das Script übergeben kann (Vielleicht dann doch eher noch wie Motivierte linke Hände komplett alles über ein Shell Script laufen lassen)
Ich hoffe hier geht es weiter mit Ideen, Umsetzungen etc.
(Die Unifi Sachen sind schon genial. Habe gerade ein Script eingebaut das mein USG eine WOL Befehl sendet, sobald von intern/extern darauf zugegriffen wird)
Grüße & Danke
Totti
Zitat von: TottiToad am 13 Oktober 2017, 17:40:48
Riesen Dank euch !!!!
Habe jetzt erst einmal alles so umgesetzt das es funktioniert.
Werde wenn mal Zeit ist, schauen wie ich einen Voucher Abruf ins FTUI umgesetzt bekommen. Am besten mit einem "Auswahl Rädchen" bei dem ich angebe für welchen Zeitraum ein Voucher erstellt werden soll.
Mal nachlesen, wie ich Werte an das Script übergeben kann (Vielleicht dann doch eher noch wie Motivierte linke Hände komplett alles über ein Shell Script laufen lassen)
Ich hoffe hier geht es weiter mit Ideen, Umsetzungen etc.
(Die Unifi Sachen sind schon genial. Habe gerade ein Script eingebaut das mein USG eine WOL Befehl sendet, sobald von intern/extern darauf zugegriffen wird)
Grüße & Danke
Totti
Wärst du allenfalls bereit, deine Lösung inkl dem FTUI hier schritt für schritt zu erklären oder gar eine Anleitung zu machen???
Hi,
klar Grundsätzlich gerne ;)
Jedoch muss ich zum einen noch ein Paar Kleinigkeiten fertigstellen (Widget für Voucher Erstellung etc)
Und zum anderen bräuchte ich das OK von @Wuehler und @Motivierte Linke Hände, da die Haupteile von ihnen gekommen sind.
Mache aber dann gerne ne "Anleitung" wie ich es umgesetzt habe fertig (Bin aber selbst Anfänger)
Ich hoffe das das hier im Thread auch so Ok ist, bin bei sowas immer unsicher. Evtl. nen extra Thread aufmachen für die Umsetzung ?
Über Rückmeldung wäre ich dankbar !
Grüße
Totti
Vielleicht im Wiki?
Hi nochmal,
ich bin mir nicht sicher, ob der Weg den du eingeschlagen hast sinnvoll ist. Bei dem Versuch ein neues Modul daraus zu programmieren ist mit aufgefallen, dass man sehr stark darauf achten muss, dass ein Befehl aufgrund des Wartens auf einen Rückgabewert nicht FHEM in Gänze blockiert. Insgesamt wird durch FHEM alles schön nacheinander abgearbeitet. Sprich wenn dein notify 2 Sekunden auf die Rückgabe wartet werden alle anderen notifies usw. nicht ausgeführt.
Bei der Unifi-API handelt es sich im Grunde um http-Requests und das php-Script wartet bis es einen Response bekommt. Im Unifi-Modul wurde daher mit NonBlockingHttp-Request gearbeitet.
Das hat zur Folge, dass man bei Absetzen mehrerer Requests nicht genau weiß, welcher Response dann zu welchem Request gehört. Beim bisherigen Unifi-Modul ist das aufgrund des Intervals in dem aktualisiert wird egal (jeder Request wird im Interval nur einmal aufgerufen).
Hoffentlich habe ich das richtig Verstanden und wiedergegeben ::)
Ich grübele jetzt schon länger drüber nach wie man das am besten löst. Ne Idee habe ich auch schon. Allerdings wird sie evtl. nicht auf allen FHEM-Installationen funktionieren. Muss daher wohl mal die Experten fragen, ob solche Installationen die mir da vorschweben überhaupt vorkommen können.
Gruß und Gute Nacht,
Der Wuehler
PS: Ich kann mittlerweile mit dem eigenen Modul Voucher erzeugen. Die WLAN Ein-/Ausschaltung müsste dann auch einfach einzubauen gehen.
Hi,
ob das der Richtig Weg ist weiß ich leider selbst nicht ;)
Bin halt auch noch absoluter Anfänger und "kämpfe" mich dadurch. So lernt man ja auch immer wieder ne Menge dazu.
Und jetzt habe ich auch den drang es irgendwie erstmal hinzubekommen. Klar geht es im endeffekt bestimmt eleganter, doch erstmal zählt für mich das Ergebnis ;)
Ich bin jedenfalls heute nochmals ein Stück weiter gekommen.
Der erstellte Voucher Code wird erstellt und taucht auch im log auf. Nur leider bekomme ich ihn noch nicht in eine Dummy oder irgendwohin übergeben :(
2017.10.14 19:15:30 4: dummy set Voucher_Dummy Voucher_anfordern
2017.10.14 19:15:30 5: Triggering Voucher_create
2017.10.14 19:15:30 4: Voucher_create exec {Code_Anfordern("$EVENT")}
Code: 8098743296
2017.10.14 19:15:33 4: dummy set Code_Dummy -1
Über Hinweise, Ideen etc wäre ich natürlich dankbar !
Grüße & Danke
Totti
P.S.: Dein Modul wäre mit Sicherheit für einige hier interessant, bin gespannt ! Und gerne für test bereit ;)
Zitat von: Markus Bloch am 16 Januar 2017, 22:41:57
Die neue PRESENCE-Version habe ich soeben eingecheckt, steht ab morgen via update zur Verfügung. Damit kann man Unifi folgendermaßen einbinden (sofern ich es richtig verstanden habe, wie Unifi funktioniert):
define <NAME> PRESENCE event UniFi:NamedDevice:.disconnected UniFi:NamedDevice:.connected
Dazu kann man dann mit den neuen Attributen absenceTimeout sowie presenceTimeout einstellen, wie lange nach dem Empfang eines entsprechenden Events gewartet werden soll, bevor der PRESENCE Status final auf "absent" oder "present" gesetzt werden soll. Die Angabe erfolgt in HH:MM:SS wobei Stunden und Minuten optional sind.:
attr <NAME> presenceTimeout 10 # 10 Sekunden
attr <NAME> absenceTimeout 15:00 # 15 Minuten
Das ganze erfolgt ohne den ganzen Blocking.pm-Overhead direkt und ist daher in "Echtzeit".
Viele Grüße
Markus
Hallo.
Bin grad dabei meinen Unifi COntroller einzubinden.
Daten werden korrekt vom Controller abgefragt.
Jetzt geht's natürlich an die Presence Erkennung 8)
Leider scheitere ich da (mit meinen noob Kentnissen) an der Angabe von "NamedDevice".
Mein Gerät heißt in Unifi "LG G4" und auch das Unifi Modul hat unter Name "LG G4".
Darin befindet sich ein Leerzeichen und ich weiß nicht wie es angeben muss.
Habe schon folgendes probier, ohne Erfolg:
define P_WIFI_Ich PRESENCE event UniFi:'LG G4':.disconnected UniFi:'LG G4':.connected
define P_WIFI_Ich PRESENCE event UniFi:/LG G4/:.disconnected UniFi:/LG G4/:.connected
define P_WIFI_Ich PRESENCE event UniFi:LG G4:.disconnected UniFi:LG G4:.connected
Eine weitere Frage zum Event Syntax "UniFi:LG G4:.disconnected" Muss "Unifi" wirklich "Unifi" sein (= modulname) oder muss es der definierte Name meines Controllers sein?
Wäre über jeden Tipp dankbar.
Danke
Hallo.
Wer suche kann ist klar im Vorteil :D jedenfalls wenn's die Richtigen Wörter sind.
Hatte nach NamedDevice gesucht und nichts gefunden.
Bei Leerzeichen und Alias wird man hier fündig: https://forum.fhem.de/index.php/topic,40287.msg692074.html#msg692074
Durch testen habe ich Frage zwei auch Beantwortet, es muss der Device Name sein.
Funktioniert super, danke für das Modul!
pOpY
Dank einiger Hilfe hier und allg. durchs Forum habe ich mir das Modul jetzt etwas erweitert.
Zum einen im FTUI (Bild s.h. Anhang)
- An und ausschalten des GästeWlans
- Erstellen eines neuen Voucher Codes (vorheriges einstellen der Gültigkeit 1Std. bis 1 Woche möglich)
- Anzeigen im Popup des neuen Voucher-Codes (für die bessere Lesbarkeit in 5er Blöcke aufgeteilt)
Gleiches habe ich im WEB Fronted umgesetzt
- Voucher Code Erstellen
- Popup mit erstelltem Code anzeigen
Danke nochmals für das geniale Modul und die Hilfe !!!
Grüße & Danke
Totti
P.S.: Vom gespannt auf die Weiterentwicklung des Moduls oder ggf. Zusatzmodule
Könnte man die Funktionen nicht auch ins Unifi Modul übernehmen und übers normale Update verteilen?
Ich glaube @Wuehler ist da an was dran und@Motivierte Linke Hände hats glaube ich nochmal ganz anders gelöst.
Vom Modul Entwickler hat jetzt schon seit Mai nichts mehr zur weiteren Entwicklung geschrieben.
Finde es aber so wie ich es umgesetzt hab jetzt erstmal ausreichend. Und ist auch relativ einfach umgesetzt
(Uni API php Dateien aufs System geschoben und 3 Dummys und ein Notify erstellt)
Ich denke das es bestimmt auch anstatt mit 3 Dummys mit einem gehen würde, in dem alle Werte sind (Readings Group oder so), doch das habe ich noch nicht hinbekommen.
Und mich stören 3 Dummys jetzt nicht ;)
Grüße
Totti
Hallo TottiToad,
kannst du den Code zur Verfügung stellen?
Gruß
Eisix
Hallo TottiToad,
kannst Du uns mal kurz erläutern was genau geschiet wenn du das Gäste WLan schaltest?
Wird Provisioniert? - werden bestehende verbindungen getrennt?
Zitat von: TottiToad am 19 Oktober 2017, 13:39:25
Dank einiger Hilfe hier und allg. durchs Forum habe ich mir das Modul jetzt etwas erweitert.
Zum einen im FTUI (Bild s.h. Anhang)
- An und ausschalten des GästeWlans
- Erstellen eines neuen Voucher Codes (vorheriges einstellen der Gültigkeit 1Std. bis 1 Woche möglich)
- Anzeigen im Popup des neuen Voucher-Codes (für die bessere Lesbarkeit in 5er Blöcke aufgeteilt)
Gleiches habe ich im WEB Fronted umgesetzt
- Voucher Code Erstellen
- Popup mit erstelltem Code anzeigen
Danke nochmals für das geniale Modul und die Hilfe !!!
Grüße & Danke
Totti
P.S.: Vom gespannt auf die Weiterentwicklung des Moduls oder ggf. Zusatzmodule
Hallo, welches Web Frontend nutzt du?
Danke
Gesendet von meinem LG-H815 mit Tapatalk
Hi,
Zitat
kannst Du uns mal kurz erläutern was genau geschiet wenn du das Gäste WLan schaltest?
Wird Provisioniert? - werden bestehende verbindungen getrennt?
Ja leider werden für einen kurzen Moment die WLAN Verbindungen getrennt, sobald ich das GästeWlan aus bzw. einschalte.
Dies ist wohl leider auch nicht anders möglich. Passiert ja auch wenn ich das Gäste Wlna über den Unifi Controller schalte.
Es muss nach dem zu/abschalten kurz neu provisionieren !
Der USG benötigt dann ca 15 sek und die beiden bei mir angeschlossenen AC-AP 35 sek bis sie wieder verbunden sind.
Zitat
Hallo, welches Web Frontend nutzt du?
Zum einen das "normale" FHEMWEB Frontend
und zum anderen FHEM Tablet UI
Kann über beide Voucher erstellen etc.
Zitat
kannst du den Code zur Verfügung stellen?
Welchen Code meinst Du ?
Mich würde dann nur das Voucher erstellen interessieren - ich lass die Gäste SSID einfach dauerhaft an...
Hallo,
den von FTUI und alles was noch nicht hier im Thread steht.
Gruß
Eisix
Zitat von: TottiToad am 19 Oktober 2017, 13:39:25
Dank einiger Hilfe hier und allg. durchs Forum habe ich mir das Modul jetzt etwas erweitert.
Zum einen im FTUI (Bild s.h. Anhang)
- An und ausschalten des GästeWlans
- Erstellen eines neuen Voucher Codes (vorheriges einstellen der Gültigkeit 1Std. bis 1 Woche möglich)
- Anzeigen im Popup des neuen Voucher-Codes (für die bessere Lesbarkeit in 5er Blöcke aufgeteilt)
Gleiches habe ich im WEB Fronted umgesetzt
- Voucher Code Erstellen
- Popup mit erstelltem Code anzeigen
Danke nochmals für das geniale Modul und die Hilfe !!!
Grüße & Danke
Totti
P.S.: Vom gespannt auf die Weiterentwicklung des Moduls oder ggf. Zusatzmodule
Mich würden ebenfalls deine Änderungen im Modul wie auch die Dummys und Notify inkl Ftui und WebFrontend interessieren. Sprich alles was du uns gelüstig gemacht hast :)
Noch eine (Anfänger)frage ;)
Habe mir mehrere event Presence angelegt (für jedes Handy eines). Das funktioniert soweit.
Diese habe ich mit structure zusammengefasst um einen gesamt Status zu haben, funktioniert auch soweit.
Mein Problem ist, wenn ich fhem/rpi neustarte dass die Clients die nicht WLAn Reichweite sind auf STATE "Initialized" stehen und state/presence auf "present".
Wie bekomme ich ein "Defaultvalue" absent rein?
Danke
Entweder ein Notify auf Initialized setzen und dann von ,,Hand" auf abgesenkt setzen ...
Oder das gleiche auf global:INITITIALIZE machen
Zitat von: Wuppi68 am 19 Oktober 2017, 23:25:34
Entweder ein Notify auf Initialized setzen und dann von ,,Hand" auf abgesenkt setzen ...
Oder das gleiche auf global:INITITIALIZE machen
Danke für den Tipp!
Habe jetzt dass getestet:
###################################
# Initialize needed states
###################################
define Initialize_states notify global:INITIALIZED trigger P_WIFI_.* absent
funktioniert leider nicht.
Auch nicht manuell: trigger P_WIFI_.* absent
was mache ich falsch?
Update:
Habe es jetzt mit folgendem Befehl geschafft:
###################################
# Initialize needed states
###################################
define Initialize_states notify global:INITIALIZED { $defs{P_WIFI_Device1}{STATE}= "absent" ;; $defs{P_WIFI_Device2}{STATE}= "absent" ;; $defs{P_WIFI_Device3}{STATE}= "absent" ;; }
Ist das so korrekt?
Wäre über eine regex wildcard (I.*) Möglichkeit Dankbar ;)
Das funktioniert nicht:
{ $defs{P_WIFI.*}{STATE}= "absent" }
Danke
pOpY
Update2:
Habe die Presence jetzt auf function umgebaut -> Vorteil ist ich kann auch mitprüfen ob das Device mit einem "AP " Aufgelistet wird (Bug Unifi Controller) und das Thema mit dem Initialisieren hat sich auch erledigt, da alle 30 Sekunden geprüft wird.
Hier der define:
define Unifi_test PRESENCE function { ((ReadingsVal("<UniFi>","<NameDevice>","") eq "connected") and (index(ReadingsVal("UniFi","<NameDevice>_accesspoint",""), "AP ")) != -1) ? 1 : 0}
pOpY
Hi,
Da ich drum gebeten wurde und nachgefragt wurde habe ich versucht eine Anleitung "meiner" Umsetzung zu schreiben.
Ich war etwas unsicher, wo ich meinen "Anleitung" jetzt poste und da ich nicht diesen Thread nicht "zu packen" wollte habe ich jetzt mal einen Neune Thread eröffnet.
https://forum.fhem.de/index.php?topic=78247.msg702030#msg702030 (https://forum.fhem.de/index.php?topic=78247.msg702030#msg702030)
Grüße
Totti
Hallo zusammen,
ich habe das Modul um ein set createVoucher und get voucherList erweitert. Zumindest bei mir scheint es zu funktionieren. Ein paar kleinere ToDos sind auch noch drin. Da komme ich mit meinen perl-Kenntnissen spontan nicht weiter.
Zum Erstellen von Vouchers:
Unifi set createVoucher 120 2 1 byFHEM
Dadurch werden zwei Vouchers erstellt, die jeweils ein Mal für 120 Minuten genutzt werden können. Die Notiz am Voucher lautet "byFHEM" (aktuell nur Notizen ohne Leerzeichen verwenden!).
unifi get voucherList byFHEM
Zeigt eine Liste der Voucher mit der Notiz "byFHEM" an.
Es fehlt denke ich noch mindestens ein Reading für die Voucher, so dass man die Voucher einfacher weitergeben kann. Ich bin mir aber nicht sicher, wie so ein Reading (oder mehrere/viele Readings) genau aussehen sollte. Vorschläge gerne Willkommen.
Ausserdem gibt es set enableWLAN <SSID> und set disableWlan <SSID>. Bin mir noch nnicht ganz sicher, ob es wirklich funktioniert. Aufgrund der Provisionierung geht beim Testem immer recht viel Zeit drauf :(
Grundsätzlich scheint es zu gehen, seltsamerweise wird das enable bei mir im Unifi-Controller aber nicht angezeigt, nur beim disable geht's.
Testversion im Anhang und die Bitte an den Modulautor schonmal draufzuschauen, ob ich grundlegende Fehler drin habe :D
Viele Grüße,
Der Wuehler
PS: Braucht man ein Reading um zu sehen, dass das Update im Gange ist?
Hallo Wuehler,
habe deine Version installiert und kurz angetestet.
Fhem läuft noch und ich konnte wie beschrieben die Vouchers erstellen.
An/Aus Wlan konnte ich nicht testen.
Gruß
Eisix
Zitat von: popy am 20 Oktober 2017, 10:24:40
Update2:
Habe die Presence jetzt auf function umgebaut -> Vorteil ist ich kann auch mitprüfen ob das Device mit einem "AP " Aufgelistet wird (Bug Unifi Controller) und das Thema mit dem Initialisieren hat sich auch erledigt, da alle 30 Sekunden geprüft wird.
Hier der define:
define Unifi_test PRESENCE function { ((ReadingsVal("<UniFi>","<NameDevice>","") eq "connected") and (index(ReadingsVal("UniFi","<NameDevice>_accesspoint",""), "AP ")) != -1) ? 1 : 0}
pOpY
Dank pOpY für den Code, funktioniert einwandfrei bei mir :D
Zitat von: DerBodo am 23 Oktober 2017, 15:28:15
Dank pOpY für den Code, funktioniert einwandfrei bei mir :D
Bitte Gerne, schön zu hören das er auch bei dir funktioniert. Bei mir läuft er auch seit dem Posten stabil ☺
Gesendet von meinem LG-H815 mit Tapatalk
Zitat von: Wuehler am 22 Oktober 2017, 22:47:24
Hallo zusammen,
ich habe das Modul um ein set createVoucher und get voucherList erweitert. Zumindest bei mir scheint es zu funktionieren. Ein paar kleinere ToDos sind auch noch drin. Da komme ich mit meinen perl-Kenntnissen spontan nicht weiter.
Zum Erstellen von Vouchers:
Unifi set createVoucher 120 2 1 byFHEM
Dadurch werden zwei Vouchers erstellt, die jeweils ein Mal für 120 Minuten genutzt werden können. Die Notiz am Voucher lautet "byFHEM" (aktuell nur Notizen ohne Leerzeichen verwenden!).
unifi get voucherList byFHEM
Zeigt eine Liste der Voucher mit der Notiz "byFHEM" an.
Es fehlt denke ich noch mindestens ein Reading für die Voucher, so dass man die Voucher einfacher weitergeben kann. Ich bin mir aber nicht sicher, wie so ein Reading (oder mehrere/viele Readings) genau aussehen sollte. Vorschläge gerne Willkommen.
Ausserdem gibt es set enableWLAN <SSID> und set disableWlan <SSID>. Bin mir noch nnicht ganz sicher, ob es wirklich funktioniert. Aufgrund der Provisionierung geht beim Testem immer recht viel Zeit drauf :(
Grundsätzlich scheint es zu gehen, seltsamerweise wird das enable bei mir im Unifi-Controller aber nicht angezeigt, nur beim disable geht's.
Testversion im Anhang und die Bitte an den Modulautor schonmal draufzuschauen, ob ich grundlegende Fehler drin habe :D
Viele Grüße,
Der Wuehler
PS: Braucht man ein Reading um zu sehen, dass das Update im Gange ist?
Hallo Wuehler
Ich habe heute dein Modul in meiner Installation eingefügt und probiert. Es funktioniert alles problemlos. Ich konnte die Vouchers kreieren und diese waren auch gültig. Zudem klappt auch das ein- und ausschalten der einzelnen WLAN einwandfrei!
Herzlichen Dank dafür.. Genau das was ich gesucht habe!
Mumpitz
Gesendet von iPad mit Tapatalk
Sehr schön. Ein paar ToDos sind aber noch drin. Kann noch optimiert werden.
Frage ist, was wird Reading oder weitere Funktion noch benötigt um drum herum die benötigte Infrastruktur flexibel aufbauen zu können?
- get voucherListJson <note> – um in einem dummy einen VoucherCache bauen zu können? Ein Cache gleich im Unifi–Modul halte ich nicht für sinnvoll.
- readings für alle Voucher?
- oder was anderes?
Zitat von: Wuehler am 23 Oktober 2017, 21:44:35
Sehr schön. Ein paar ToDos sind aber noch drin. Kann noch optimiert werden.
Frage ist, was wird Reading oder weitere Funktion noch benötigt um drum herum die benötigte Infrastruktur flexibel aufbauen zu können?
- get voucherListJson <note> – um in einem dummy einen VoucherCache bauen zu können? Ein Cache gleich im Unifi–Modul halte ich nicht für sinnvoll.
- readings für alle Voucher?
- oder was anderes?
Ich denke ein Reading für den Voucher Code ist sinnvoll. Ich kann Dich dabei jedoch nicht unterstützen, da ich in meinem privaten Umfeld keine Voucher brauche. Ich schalte ein zweites WLAN mit deiner Funktion ein, sobald meine Gäste WLAN brauchen. Sobald diese weg sind werde ich dieses zweite WLAN wieder abschalten.
Wenn du noch was für die Wunschliste brauchst ;D
- Abschalten einzelner AP's
Gruß
Eisix
Das sollte doch jetzt schon über das schalten von POE funktionieren, oder?
Wenn man einen PoE Switch hat sollte das gehen. Ich habe aber keinen und nutze die PoE Adapter.
Gruß
Eisix
Jemand eine Idee, wie man den neu generierten Voucher in FTUI anzeigen lassen kann:
Unifi set createVoucher 120 1 1 byFHEM
Über:
Unifi get voucherList all
bekomme ich ja eine große Liste:
==================================================================
code = 3196740206
duration = 60
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
code = 3749748304
duration = 120
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
code = 9436821017
duration = 120
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
code = 0665958773
duration = 1440
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
code = 4651263880
duration = 1440
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
code = 4286102706
duration = 1440
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
code = 5501154988
duration = 1440
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
code = 4879594706
duration = 1440
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
code = 3407274259
duration = 1440
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
code = 4830134382
duration = 1440
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
code = 4095465187
duration = 1440
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
code = 7828933768
duration = 1440
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
code = 8629918802
duration = 1440
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
code = 5071154934
duration = 1440
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
code = 9153687849
duration = 1440
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
code = 9203347554
duration = 1440
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
code = 4062066989
duration = 1440
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
code = 3249993855
duration = 1440
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
code = 5430153896
duration = 1440
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
code = 4401897439
duration = 1440
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
code = 3225753720
duration = 1440
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
code = 7622936249
duration = 1440
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
code = 1309249732
duration = 1440
note =
quota = 1
status = VALID_ONE
status_expires = 0
used = 0
==================================================================
Count: 23
Noch nicht auf einfachem Weg. Dazu fehlen wie geschrieben noch Readings. Da das Ganze über HTTP funktioniert und Non-Blocking (es wird nich auf die Antwort gewartet) umgesetzt ist, kann createVoucher nicht den Code zurückgeben. Außerdem kann man ja mehrere Voucher erzeugen.
Brauche da noch Input wie man die Readings am besten umsetzt.
Hi,
genial @Wuhler, werde die Tage mal dein Modul ausprobieren. Freue mich das es so schnell mit der Umsetzung geklappt hat !
Kann mir jemand sagen, wie ich es schaffe, dass mir das UnifiModul nicht den ganzen Log "zumüllt" ?
Habe schon Verbose auf 0 und event-on-change reading .* gesetzt.
Doch leider bekomme ich ca. alle 30 sek. ungefähr 80 neue Einträge.
Wie habt ihr es gelöst ?
Hoffe ihr könnt mir weiterhelfen
Grüße & Danke
Totti
Hallo Totti,
Welche Einträge stehen denn im Log? Bei mor ist das nicht so.
Hallo rapster,
Vielen Dank noch einmal für das Klasse Modul. Ich habe daran viel gelernt wie fhem funktioniert und warum man etwas so umsetzen muss wie im Modul geschehen.
Was hältst du von meinen Erweiterungen? Können sie ins Modul übernommen werden? (Nachdem die ganzen kleinen ToDos ausgebessert wurden)
Ich würde die Voucher gerne noch um Caching erweitern, so dass man immer einen sicheren Vorrat hat. Dazu würde ich dann ein Attribut zur Konfiguration ergänzen.
Ist das für divh ok?
Viele Grüße,
Der Wühler
Hi,
hier mal ein teil aus dem Log der alle 30 sek kommt:
2017-10-25 09:58:25 Unifi MyUnifi 591cd813xxxxxxxxb39cc520a_last_seen: 2017-10-25 09:58:12
2017-10-25 09:58:25 Unifi MyUnifi 591cd813xxxxxxxx39cc520a_uptime: 661046
2017-10-25 09:58:25 Unifi MyUnifi 591cd65cxxxxxxxx39cc51ff_last_seen: 2017-10-25 09:58:12
2017-10-25 09:58:25 Unifi MyUnifi 591cd65xxxxxxxxxb39cc51ff_uptime: 661045
2017-10-25 09:58:25 Unifi MyUnifi 591cd5bxxxxxxxxxxb39cc51fb_last_seen: 2017-10-25 09:58:19
2017-10-25 09:58:25 Unifi MyUnifi 591cd5bxxxxxxxxxx39cc51fb_uptime: 660636
2017-10-25 09:58:25 Unifi MyUnifi 591ce53xxxxxxxxxx9cc5232_last_seen: 2017-10-25 09:58:12
2017-10-25 09:58:25 Unifi MyUnifi 591ce53fxxxxxxxxxxx9cc5232_uptime: 4096
2017-10-25 09:58:25 Unifi MyUnifi Denon_last_seen: 2017-10-25 09:58:12
2017-10-25 09:58:25 Unifi MyUnifi Denon_uptime: 154231
2017-10-25 09:58:25 Unifi MyUnifi UPCGW_C042_last_seen: 2017-10-25 09:58:19
2017-10-25 09:58:25 Unifi MyUnifi UPCGW_C042_uptime: 68701
2017-10-25 09:58:25 Unifi MyUnifi Philips-hue_last_seen: 2017-10-25 09:58:19
2017-10-25 09:58:25 Unifi MyUnifi Philips-hue_uptime: 661052
2017-10-25 09:58:25 Unifi MyUnifi 593447e6exxxxxxxccbd34_last_seen: 2017-10-25 09:58:12
2017-10-25 09:58:25 Unifi MyUnifi 593447e6exxxxxxxxb39ccbd34_uptime: 19763
2017-10-25 09:58:25 Unifi MyUnifi HF-LPB100-ZJ200_last_seen: 2017-10-25 09:58:05
2017-10-25 09:58:25 Unifi MyUnifi HF-LPB100-ZJ200_uptime: 661035
2017-10-25 09:58:25 Unifi MyUnifi HarmonyHub_last_seen: 2017-10-25 09:58:05
2017-10-25 09:58:25 Unifi MyUnifi HarmonyHub_uptime: 661034
2017-10-25 09:58:25 Unifi MyUnifi HP90094A_last_seen: 2017-10-25 09:58:19
2017-10-25 09:58:25 Unifi MyUnifi HP90094A_uptime: 661048
2017-10-25 09:58:25 Unifi MyUnifi 5957f61fe4b0ce25a12a5ce2_last_seen: 2017-10-25 09:58:19
2017-10-25 09:58:25 Unifi MyUnifi 5957f61fe4b0ce25a12a5ce2_uptime: 660920
2017-10-25 09:58:25 Unifi MyUnifi SonosZB_last_seen: 2017-10-25 09:58:12
2017-10-25 09:58:25 Unifi MyUnifi SonosZB_uptime: 661047
2017-10-25 09:58:25 Unifi MyUnifi Alexa_last_seen: 2017-10-25 09:58:05
2017-10-25 09:58:25 Unifi MyUnifi Alexa_uptime: 661022
2017-10-25 09:58:25 Unifi MyUnifi iPad_last_seen: 2017-10-25 09:58:05
2017-10-25 09:58:25 Unifi MyUnifi iPad_uptime: 490857
2017-10-25 09:58:25 Unifi MyUnifi MacBuro_last_seen: 2017-10-25 09:58:19
2017-10-25 09:58:25 Unifi MyUnifi MacBuro_uptime: 2061
2017-10-25 09:58:25 Unifi MyUnifi amazon-33029b9ae_last_seen: 2017-10-25 09:58:05
2017-10-25 09:58:25 Unifi MyUnifi amazon-33029b9ae_uptime: 661001
2017-10-25 09:58:25 Unifi MyUnifi SonosZP_last_seen: 2017-10-25 09:58:19
2017-10-25 09:58:25 Unifi MyUnifi SonosZP_uptime: 430088
2017-10-25 09:58:25 Unifi MyUnifi NUC_last_seen: 2017-10-25 09:58:19
2017-10-25 09:58:25 Unifi MyUnifi NUC_uptime: 661053
2017-10-25 09:58:25 Unifi MyUnifi OEQ0329312_last_seen: 2017-10-25 09:58:12
2017-10-25 09:58:25 Unifi MyUnifi OEQ0329312_uptime: 661042
2017-10-25 09:58:25 Unifi MyUnifi amazon-e6517_last_seen: 2017-10-25 09:58:05
2017-10-25 09:58:25 Unifi MyUnifi amazon-e6517_uptime: 661026
2017-10-25 09:58:25 Unifi MyUnifi 591cd7xxxxxxxxb39cc5209_last_seen: 2017-10-25 09:58:12
2017-10-25 09:58:25 Unifi MyUnifi 591cd7xxxxxxxxa7b39cc5209_uptime: 72170
2017-10-25 09:58:25 Unifi MyUnifi raspberrypi_last_seen: 2017-10-25 09:58:19
2017-10-25 09:58:25 Unifi MyUnifi raspberrypi_uptime: 661053
2017-10-25 09:58:25 Unifi MyUnifi UPCGW_76C0_last_seen: 2017-10-25 09:58:19
2017-10-25 09:58:25 Unifi MyUnifi UPCGW_76C0_uptime: 68700
2017-10-25 09:58:25 Unifi MyUnifi 591cxxxxxxxxxxa7b39cc51f2_last_seen: 2017-10-25 09:58:19
2017-10-25 09:58:25 Unifi MyUnifi 591cxxxxxxxxxxa7b39cc51f2_uptime: 661054
2017-10-25 09:58:25 Unifi MyUnifi amazon-302a5f636_last_seen: 2017-10-25 09:57:59
2017-10-25 09:58:25 Unifi MyUnifi amazon-302a5f636_uptime: 490777
2017-10-25 09:58:25 Unifi MyUnifi SonosZP_uptime: 165841
2017-10-25 09:58:25 Unifi MyUnifi SonosZP_last_seen: 2017-10-25 09:58:12
2017-10-25 09:58:25 Unifi MyUnifi SonosZP_uptime: 430281
2017-10-25 09:58:25 Unifi MyUnifi SonosZP_last_seen: 2017-10-25 09:58:19
2017-10-25 09:58:25 Unifi MyUnifi SonosZP_uptime: 661055
2017-10-25 09:58:25 Unifi MyUnifi iPhone7_last_seen: 2017-10-25 09:58:05
2017-10-25 09:58:25 Unifi MyUnifi iPhone7_uptime: 34893
2017-10-25 09:58:25 Unifi MyUnifi iPhone7_snr: 25
2017-10-25 09:58:25 Unifi MyUnifi -AP_Access Point_utilizationNG: 8
2017-10-25 09:58:25 Unifi MyUnifi -AP_Access Point Anbau_utilizationNA: 1
2017-10-25 09:58:25 Unifi MyUnifi -AP_Access Point Anbau_utilizationNG: 10
2017-10-25 09:58:25 Unifi MyUnifi -AP_Unifi Switch_poePower: 10.12
Verbose steht auf 0
und event-on-change-reading: .*
Durch die Aktualisierung der uptime und last seen, ist der log sehr schnell voll.
Wie habt ihr es gelöst ?
Grüße & Danke
Totti
Also ich habe weder ein verbose noch ein event_on_change reading gesetzt und erhalte keine Log Nachrichten.
Zitat von: gloob am 25 Oktober 2017, 10:22:19
Also ich habe weder ein verbose noch ein event_on_change reading gesetzt und erhalte keine Log Nachrichten.
Das verstehe ich nicht !?!?
Habe gerade es gerade mal ohne beide Werte probiert. Dann bekomme ich aufgrund der Anzahl meiner angeschlossenen Geräte 180 !!! Logeinträge alle 30 Sekunden.
Halt jedes Reading alle 30 sek
Wie siehts denn bei den anderen aus ? Und warum könnte das bei mir so sein ?
Hätte ich beim anlegen noch irgendwas definieren müssen ?
So habe ich es angelegt (egal ob ich es mit Verbose oder event-on-change-reading anlege):
define MyUnifi Unifi 192.168.178.2 8443 NAME PASSWORT
attr MyUnifi event-on-change-reading .*
attr MyUnifi room Geräte
Grüße & danke
Totti
Tatsächlich im Log oder meinst Du den Event Monitor..?
Zitat von: der-Lolo am 25 Oktober 2017, 14:01:25
Tatsächlich im Log oder meinst Du den Event Monitor..?
Hi,
taucht alles bei mir im log auf. Weiß nicht ob es wichtig ist, nutze DbLog.
Meine aber das es vorher in der normalen Log auch so war, kann es aber mit Sicherheit nicht sagen.
Grüße & danke
Totti
Da gehörts nun wirklich nicht hin...
UniFi schreibt bei mir gar nix ins Log! noch nichtmal ein connected oder so...
Zitat von: der-Lolo am 25 Oktober 2017, 17:37:38
Da gehörts nun wirklich nicht hin...
UniFi schreibt bei mir gar nix ins Log! noch nichtmal ein connected oder so...
mmmmh das finde ich Wiederrum auch ungewöhnlich, hast du denn irgendwelche attr gesetzt ?
ich hab event-on-change-reading Handy1 Handy2 gesetzt - mehr events will ich nicht vom Controller ;-)
Hast du die neueste Unifi Version? Ich finde auf die Schnelle keine Zeile im Code, die einen solchen Logeintrag erzeugen würde. Bekomme denselben Eintrag mit verbose auf 5 auch nicht.
Zitat von: Wuehler am 25 Oktober 2017, 20:32:06
Hast du die neueste Unifi Version? Ich finde auf die Schnelle keine Zeile im Code, die einen solchen Logeintrag erzeugen würde. Bekomme denselben Eintrag mit verbose auf 5 auch nicht.
Ja hab die neuste Version ! (Jedoch noch nicht deine ;) )
Was hast Du denn für attr gesetzte ? Vor allem bei event-on-change-reading ?
Ich hab es jetzt eingeschränkt und nur meine Handys eingetragen, dann werden auch nur diese angezeigt.
(Wunder mich halt nur, da einige wohl weder Verbose noch event-on-change gesetzt haben ?
Grüße & Danke
Totti
Hallo,
im Anhang eine neue Test-Version inklusive Voucher-Cache und en-/disableWLAN.
Um die Dokumentation gleich mitzutesten will ich hier gar nicht so viel schreiben ??? Bitte im Unifi-Device unten rechts auf "Device specific help" klicken.
Ich denke die Version ist gut geeignet um sie in FTUI oder andere User-Interfaces einzubinden, da sowohl Readings für Voucher-Codes (wenn ein Cache definiert wurde) als auch ein getter für einen Voucher-Code vorhanden ist (falls man z.B. den Cache nicht verwendet).
Das enableWLAN funktioniert, hat aber leider weiterhin die Nebenwirkung, dass der Haken im Unifi-Controller nicht gesetzt wird. Ich habe das Verhalten jetzt auch über die php-Scripte von Totti nachstellen können. Vielleicht liegt es ja an der Unifi-Controller-Version.. Bei mir läuft 5.5.24.
Hallo Wuehler,
bastel gerade an meinem Interface mit deiner neuen Version. Readings für die aktiven SSID's währen denke ich noch sinnvoll. Läßt sich das noch einbauen?
Werde es erst mal über userreadings machen.
Gruß
Eisix
Zitat von: popy am 20 Oktober 2017, 10:24:40
Update2:
Habe die Presence jetzt auf function umgebaut -> Vorteil ist ich kann auch mitprüfen ob das Device mit einem "AP " Aufgelistet wird (Bug Unifi Controller) und das Thema mit dem Initialisieren hat sich auch erledigt, da alle 30 Sekunden geprüft wird.
Hier der define:
define Unifi_test PRESENCE function { ((ReadingsVal("<UniFi>","<NameDevice>","") eq "connected") and (index(ReadingsVal("UniFi","<NameDevice>_accesspoint",""), "AP ")) != -1) ? 1 : 0}
pOpY
Kannst du mir den Bug kurz erklären?
Hallo Hauswart,
das Problem tritt auf wenn man Access Points und Switche von Unifi hat. Wlan Clients wie z.b. dein Handy werden dann als Connected an einem Switch angezeigt nachdem Sie das WLAN verlassen haben.
Somit kann man nicht einfach nur auf "connected" matchen wenn man eine Anwesenheitserkennung machen möchte, sondern man muss außerdem noch prüfen ob das Device an dem das Handy connected ist ein AP ist.
Bei mir war es z.B. so dass mein iPhone immer am Switch im Keller angeschlossen war :-)
Wie es dahin kommt ist nicht ganz logisch, ARP Table etc. waren immer korrekt.....
Gruß
Bodo
Hallo Totti,
Kann es sein, dass dein Log–Problem von einem notify oder ähnlichem kommt? Wenn du event–on–chang–reading einschränkst (bei mir .*) wird das notify nicht mehr so oft getriggert.
Mit der "event" funktion von Presence kann man diesen Bug aber auch gut umgehen..
Bei mir ging es damit leider nicht, daher habe ich auf die "function" umgesattelt.
Hallo zusammen,
ich hoffe es kann mir jemand hier helfen, da ich es einfach nicht schaffe das Unifi-Modul zur Anwesenheitserkennung zu nutzen.
Das Unifi-Modul als solches funktioniert. Im UnifiController ist z.B. mein persönliches Mobilgerät mit dem Alias "myHandy" versehen.
Somit wird "myHandy" auch im Unifi-Modul (innerhalb fhem) korrekt erkannt, siehe:myHandy_accesspoint
Access Point Erdgeschoss
2017-11-02 19:34:58
myHandy_hostname
Samsung-Galaxy-S7
2017-11-02 19:34:58
myHandy_last_seen
2017-11-02 19:34:49
2017-11-02 19:34:58
myHandy_uptime
132
Wie müsste das korrekte define in fhem lauten, damit ein "Connect/Disconnect" auch zur Anwesenheitserkennung genutzt werden kann. Weder die function noch event Variante aus dem wiki war bei mir erfolgreich!
Vielen Dank an alle!
Moin zusammen,
ich steh auf dem Schlauch warum funktioniert dieses bei mir nicht
function { ((ReadingsVal("UniFi","Samsung-Galaxy-S7","") eq "connected") and (index(ReadingsVal("Unifi","Samsung-Galaxy-S7_accesspoint",""), "AP ")) != -1) ? 1 : 0}
wohingegen dieses funktioniert
function {ReadingsVal('UniFi','Samsung-Galaxy-S7','"') eq "connected" ? 1:0}
Danke Benny
Hallo,
DOIF
([Unifi:Handy] eq "connected") (set rr_bewohner home) DOELSE (set rr_bewohner absent)
Gruß
Eisix
@Benny: Typo, einmal Unifi mit kleinem f, sonst mit großem F.
@Pi_Newbie: welches define funktioniert denn konkret nicht richtig?
@Wuehler
Das hatte ich auch zuerst auch vermutet, aber das ändern hilft nichts. Es funktioniert weiterhin nicht.
function { ((ReadingsVal("UniFi","Samsung-Galaxy-S7","") eq "connected") and (index(ReadingsVal("UniFi","Samsung-Galaxy-S7_accesspoint",""), "AP ")) != -1) ? 1 : 0}
presence und state bleibt auf absent.
hierbei sind die readings presence und state auf present bzw. auf absent wenn wlan am handy ausgeschaltet wird
function {ReadingsVal('UniFi','Samsung-Galaxy-S7','') eq "connected" ? 1:0}
Gruß Benny
Wie sind denn deine AccessPoints benannt ?
Der Filter in "AP " muss natürlich passen, sonst bekommt er immer ein "false" zurück.
Hallo,
@Wuehler: Ich habe folgende zwei defines eingetragen.
define Anwesenheit_Mobil1 PRESENCE function {ReadingsVal("<UniFi>","MyHandy","") eq "connected" ? 1:0}
define Anwesenheit_Mobil2 PRESENCE event UniFi:MyHandy:.disconnected UniFi:MyHandy:.connected
- Das "event"-define zeigt ein permanentes "absent". Egal ob ich via WLAN verbunden bin oder nicht. Das "unifi-modul" jedoch registriert sofort wenn ich das WLAN deaktiviere.
- Das "function"-define zeigt ein "initialised" oder ???.
Ich gehe davon aus, dass ich einen Fehler im define habe, erkenne leider nur nicht wo.
Besten Dank für die Hilfe!
Heisst dein Unifi-device wirklich ,,<UniFi>" oder nur ,,UniFi"?
Habe PRESENCE bisher nicht genutzt, da nicht alle ein Handy haben bei uns. Aber mit function hat es bei mir sofort funktioniert.
@Wuehler: genau dort lag der Fehler! Die Klammern habe ich bestimmt 100x mal überlesen! Sorry, aber trotzdem danke!
@alle: Ich habe soeben verschiedene Automatiken mit der Anwesenheitserkennung und "unifi" verknüpft. Gibt es eine Möglichkeit die "Connected/Disconnected"-Erkennung zu beschleunigen? Aktuell benötigt das Modul ja ca. 10Minuten bis es ein z.B. Disconnect registriert.
Wenn ich jedoch mit dem Auto in die Garage fahre, das Handy sich ins WLAN einwählt soll im Flur das Licht eingeschaltet werden. Durch die extrem verzögerte Erkennung macht die Funktion momentan wenig Sinn.
Jemand eine Idee wie man das beschleunigen kann?
Vielen Dank für Eure Hilfe!!!
Hallo Pi,
manchmal übersieht man sowas :D kein Problem.
Wegen der disconnect-Zeit: das kommt von der Controller-Software. Manche Versionen machen das nach 5, andere nach 10 Minuten. Auf Seite 1 dieses Threads ist eine Umsetzung auf Basis des last_seen readings dargestellt.
Wegen der connect-Zeit: das Unifi-Modul fragt regelmäßig den Controller nach aktuellen Daten ab. Die Zeit hast du im Define des Moduls festgelegt. Vermutlich 30 Sekunden. D.h. Wenn du Pech hast erkennt fhem erst 30 Sekunden später, dass dein handy im wlan ist. Je nachdem wo dein Controller und dein fhem läuft kannst du versuchen die Zeit zu reduzieren. Wenn beide auf demselben RasPi sind dann lass es lieber.
Kannst du nicht das Öffnen des Garagentors in fhem erkennen?
Gruß,
Wuehler
@Pi
Mit presence kannst du einen Ping auf die IP des Handys machen zb alle 30 sec. IP im DHCP fest vergeben.
Gruß
Eisix
Hallo Ich habe ständig Probleme mit Freez Meldungen im Log. Hab schon einiges Probiert an Optimierungen (glaube von Seite 17 in diesem Thread mongo DB verkleinert) am Unifi Server. Oder auch auch das Update auf nur Client beschränkt damit mein Cubietruck nicht so viel Arbeit hat. Dazu habe ich in der 74_Unifi.pm folgendes auskommentiert. Leider alles ohne Erfolg.
if (Unifi_CONNECTED($hash)) {
$hash->{unifi}->{updateStartTime} = time();
$hash->{updateDispatch} = { # {updateDispatch}->{callFn}[callFnRef,'receiveFn',receiveFnRef]
Unifi_GetClients_Send => [\&Unifi_GetClients_Send,'Unifi_GetClients_Receive',\&Unifi_GetClients_Receive],
#Unifi_GetAccesspoints_Send => [\&Unifi_GetAccesspoints_Send,'Unifi_GetAccesspoints_Receive',\&Unifi_GetAccesspoints_Receive],
#Unifi_GetWlans_Send => [\&Unifi_GetWlans_Send,'Unifi_GetWlans_Receive',\&Unifi_GetWlans_Receive],
#Unifi_GetUnarchivedAlerts_Send => [\&Unifi_GetUnarchivedAlerts_Send,'Unifi_GetUnarchivedAlerts_Receive',\&Unifi_GetUnarchivedAlerts_Receive],
#Unifi_GetEvents_Send => [\&Unifi_GetEvents_Send,'Unifi_GetEvents_Receive',\&Unifi_GetEvents_Receive],
# Unifi_GetWlanGroups_Send => [\&Unifi_GetWlanGroups_Send,'Unifi_GetWlanGroups_Receive',\&Unifi_GetWlanGroups_Receive],
#Unifi_GetHealth_Send => [\&Unifi_GetHealth_Send,'Unifi_GetHealth_Receive',\&Unifi_GetHealth_Receive],
Unifi_ProcessUpdate => [\&Unifi_ProcessUpdate,''],
};
Unifi_NextUpdateFn($hash,$self);
}
Hier mal ein Auszug aus dem FHEM Log Die ersten Zeilen sind mit verbose0 danach mit Verbose5
2017.11.13 09:26:23 1: Perfmon: possible freeze starting at 09:26:22, delay is 1.418
2017.11.13 09:26:55 1: Perfmon: possible freeze starting at 09:26:54, delay is 1.075
2017.11.13 09:28:30 1: Perfmon: possible freeze starting at 09:28:29, delay is 1.188
2017.11.13 09:30:05 1: Perfmon: possible freeze starting at 09:30:04, delay is 1.373
2017.11.13 09:30:37 1: Perfmon: possible freeze starting at 09:30:36, delay is 1.055
2017.11.13 09:31:40 1: Perfmon: possible freeze starting at 09:31:39, delay is 1.392
2017.11.13 09:32:12 1: Perfmon: possible freeze starting at 09:32:11, delay is 1.026
2017.11.13 09:33:15 1: Perfmon: possible freeze starting at 09:33:14, delay is 1.276
2017.11.13 09:34:50 1: Perfmon: possible freeze starting at 09:34:49, delay is 1.333
2017.11.13 09:36:25 1: Perfmon: possible freeze starting at 09:36:24, delay is 1.246
2017.11.13 09:38:00 1: Perfmon: possible freeze starting at 09:37:59, delay is 1.23
2017.11.13 09:38:30 5: Ubiquiti (Unifi_DoUpdate) - executed.
2017.11.13 09:38:30 5: Ubiquiti (Unifi_GetClients_Send) - executed.
2017.11.13 09:38:32 5: Ubiquiti (Unifi_GetClients_Receive) - executed.
2017.11.13 09:38:32 5: Ubiquiti (Unifi_GetClients_Receive) - state:'ok'
2017.11.13 09:38:32 5: Ubiquiti (Unifi_ProcessUpdate) - executed after 1.7571 seconds.
2017.11.13 09:38:32 5: Ubiquiti (Unifi_SetHealthReadings) - executed.
2017.11.13 09:38:32 5: Ubiquiti (Unifi_SetClientReadings) - executed.
2017.11.13 09:38:32 5: Ubiquiti (Unifi_SetAccesspointReadings) - executed.
2017.11.13 09:38:32 5: Ubiquiti (Unifi_ProcessUpdate) - finished after 1.7983 seconds.
2017.11.13 09:38:39 5: Ubiquiti: set called with update
2017.11.13 09:38:39 4: Ubiquiti: set update
2017.11.13 09:38:39 5: Ubiquiti (Unifi_DoUpdate) - executed.
2017.11.13 09:38:39 5: Ubiquiti (Unifi_GetClients_Send) - executed.
2017.11.13 09:38:41 5: Ubiquiti (Unifi_GetClients_Receive) - executed.
2017.11.13 09:38:41 5: Ubiquiti (Unifi_GetClients_Receive) - state:'ok'
2017.11.13 09:38:41 5: Ubiquiti (Unifi_ProcessUpdate) - executed after 1.5352 seconds.
2017.11.13 09:38:41 5: Ubiquiti (Unifi_SetHealthReadings) - executed.
2017.11.13 09:38:41 5: Ubiquiti (Unifi_SetClientReadings) - executed.
2017.11.13 09:38:41 5: Ubiquiti (Unifi_SetAccesspointReadings) - executed.
2017.11.13 09:38:41 5: Ubiquiti (Unifi_ProcessUpdate) - finished after 1.5411 seconds.
2017.11.13 09:39:11 5: Ubiquiti (Unifi_DoUpdate) - executed.
2017.11.13 09:39:11 5: Ubiquiti (Unifi_GetClients_Send) - executed.
2017.11.13 09:39:12 5: Ubiquiti (Unifi_GetClients_Receive) - executed.
2017.11.13 09:39:12 5: Ubiquiti (Unifi_GetClients_Receive) - state:'ok'
2017.11.13 09:39:12 5: Ubiquiti (Unifi_ProcessUpdate) - executed after 1.4249 seconds.
2017.11.13 09:39:12 5: Ubiquiti (Unifi_SetHealthReadings) - executed.
2017.11.13 09:39:12 5: Ubiquiti (Unifi_SetClientReadings) - executed.
2017.11.13 09:39:12 5: Ubiquiti (Unifi_SetAccesspointReadings) - executed.
2017.11.13 09:39:12 5: Ubiquiti (Unifi_ProcessUpdate) - finished after 1.4576 seconds.
2017.11.13 09:39:42 5: Ubiquiti (Unifi_DoUpdate) - executed.
2017.11.13 09:39:42 5: Ubiquiti (Unifi_GetClients_Send) - executed.
2017.11.13 09:39:43 5: Ubiquiti (Unifi_GetClients_Receive) - executed.
2017.11.13 09:39:43 5: Ubiquiti (Unifi_GetClients_Receive) - state:'ok'
2017.11.13 09:39:43 5: Ubiquiti (Unifi_ProcessUpdate) - executed after 1.4553 seconds.
2017.11.13 09:39:43 5: Ubiquiti (Unifi_SetHealthReadings) - executed.
2017.11.13 09:39:43 5: Ubiquiti (Unifi_SetClientReadings) - executed.
2017.11.13 09:39:43 5: Ubiquiti (Unifi_SetAccesspointReadings) - executed.
2017.11.13 09:39:43 5: Ubiquiti (Unifi_ProcessUpdate) - finished after 1.4887 seconds.
2017.11.13 09:40:13 5: Ubiquiti (Unifi_DoUpdate) - executed.
2017.11.13 09:40:13 5: Ubiquiti (Unifi_GetClients_Send) - executed.
2017.11.13 09:40:15 1: Perfmon: possible freeze starting at 09:40:14, delay is 1.38
2017.11.13 09:40:15 5: Ubiquiti (Unifi_GetClients_Receive) - executed.
2017.11.13 09:40:15 5: Ubiquiti (Unifi_GetClients_Receive) - state:'ok'
2017.11.13 09:40:15 5: Ubiquiti (Unifi_ProcessUpdate) - executed after 1.4242 seconds.
2017.11.13 09:40:15 5: Ubiquiti (Unifi_SetHealthReadings) - executed.
2017.11.13 09:40:15 5: Ubiquiti (Unifi_SetClientReadings) - executed.
2017.11.13 09:40:15 5: Ubiquiti (Unifi_SetAccesspointReadings) - executed.
2017.11.13 09:40:15 5: Ubiquiti (Unifi_ProcessUpdate) - finished after 1.4500 seconds.
2017.11.13 09:40:45 5: Ubiquiti (Unifi_DoUpdate) - executed.
2017.11.13 09:40:45 5: Ubiquiti (Unifi_GetClients_Send) - executed.
2017.11.13 09:40:46 5: Ubiquiti (Unifi_GetClients_Receive) - executed.
2017.11.13 09:40:46 5: Ubiquiti (Unifi_GetClients_Receive) - state:'ok'
2017.11.13 09:40:46 5: Ubiquiti (Unifi_ProcessUpdate) - executed after 1.4365 seconds.
2017.11.13 09:40:46 5: Ubiquiti (Unifi_SetHealthReadings) - executed.
2017.11.13 09:40:46 5: Ubiquiti (Unifi_SetClientReadings) - executed.
2017.11.13 09:40:46 5: Ubiquiti (Unifi_SetAccesspointReadings) - executed.
2017.11.13 09:40:46 5: Ubiquiti (Unifi_ProcessUpdate) - finished after 1.4662 seconds.
2017.11.13 09:41:16 5: Ubiquiti (Unifi_DoUpdate) - executed.
2017.11.13 09:41:16 5: Ubiquiti (Unifi_GetClients_Send) - executed.
2017.11.13 09:41:18 1: Perfmon: possible freeze starting at 09:41:17, delay is 1.328
2017.11.13 09:41:18 5: Ubiquiti (Unifi_GetClients_Receive) - executed.
2017.11.13 09:41:18 5: Ubiquiti (Unifi_GetClients_Receive) - state:'ok'
2017.11.13 09:41:18 5: Ubiquiti (Unifi_ProcessUpdate) - executed after 1.5892 seconds.
2017.11.13 09:41:18 5: Ubiquiti (Unifi_SetHealthReadings) - executed.
2017.11.13 09:41:18 5: Ubiquiti (Unifi_SetClientReadings) - executed.
2017.11.13 09:41:18 5: Ubiquiti (Unifi_SetAccesspointReadings) - executed.
2017.11.13 09:41:18 5: Ubiquiti (Unifi_ProcessUpdate) - finished after 1.7443 seconds.
2017.11.13 09:41:48 5: Ubiquiti (Unifi_DoUpdate) - executed.
2017.11.13 09:41:48 5: Ubiquiti (Unifi_GetClients_Send) - executed.
2017.11.13 09:41:50 1: Perfmon: possible freeze starting at 09:41:49, delay is 1.071
2017.11.13 09:41:50 5: Ubiquiti (Unifi_GetClients_Receive) - executed.
2017.11.13 09:41:50 5: Ubiquiti (Unifi_GetClients_Receive) - state:'ok'
2017.11.13 09:41:50 5: Ubiquiti (Unifi_ProcessUpdate) - executed after 1.4513 seconds.
2017.11.13 09:41:50 5: Ubiquiti (Unifi_SetHealthReadings) - executed.
2017.11.13 09:41:50 5: Ubiquiti (Unifi_SetClientReadings) - executed.
2017.11.13 09:41:50 5: Ubiquiti (Unifi_SetAccesspointReadings) - executed.
2017.11.13 09:41:50 5: Ubiquiti (Unifi_ProcessUpdate) - finished after 1.6108 seconds.
2017.11.13 09:42:20 5: Ubiquiti (Unifi_DoUpdate) - executed.
2017.11.13 09:42:20 5: Ubiquiti (Unifi_GetClients_Send) - executed.
2017.11.13 09:42:21 5: Ubiquiti (Unifi_GetClients_Receive) - executed.
2017.11.13 09:42:21 5: Ubiquiti (Unifi_GetClients_Receive) - state:'ok'
2017.11.13 09:42:21 5: Ubiquiti (Unifi_ProcessUpdate) - executed after 1.4371 seconds.
2017.11.13 09:42:21 5: Ubiquiti (Unifi_SetHealthReadings) - executed.
2017.11.13 09:42:21 5: Ubiquiti (Unifi_SetClientReadings) - executed.
2017.11.13 09:42:21 5: Ubiquiti (Unifi_SetAccesspointReadings) - executed.
2017.11.13 09:42:21 5: Ubiquiti (Unifi_ProcessUpdate) - finished after 1.4655 seconds.
2017.11.13 09:42:51 5: Ubiquiti (Unifi_DoUpdate) - executed.
2017.11.13 09:42:51 5: Ubiquiti (Unifi_GetClients_Send) - executed.
2017.11.13 09:42:53 1: Perfmon: possible freeze starting at 09:42:52, delay is 1.134
2017.11.13 09:42:53 5: Ubiquiti (Unifi_GetClients_Receive) - executed.
2017.11.13 09:42:53 5: Ubiquiti (Unifi_GetClients_Receive) - state:'ok'
2017.11.13 09:42:53 5: Ubiquiti (Unifi_ProcessUpdate) - executed after 1.4570 seconds.
2017.11.13 09:42:53 5: Ubiquiti (Unifi_SetHealthReadings) - executed.
2017.11.13 09:42:53 5: Ubiquiti (Unifi_SetClientReadings) - executed.
2017.11.13 09:42:53 5: Ubiquiti (Unifi_SetAccesspointReadings) - executed.
2017.11.13 09:42:53 5: Ubiquiti (Unifi_ProcessUpdate) - finished after 1.6136 seconds.
2017.11.13 09:43:23 5: Ubiquiti (Unifi_DoUpdate) - executed.
2017.11.13 09:43:23 5: Ubiquiti (Unifi_GetClients_Send) - executed.
2017.11.13 09:43:24 5: Ubiquiti (Unifi_GetClients_Receive) - executed.
2017.11.13 09:43:24 5: Ubiquiti (Unifi_GetClients_Receive) - state:'ok'
2017.11.13 09:43:24 5: Ubiquiti (Unifi_ProcessUpdate) - executed after 1.5346 seconds.
2017.11.13 09:43:24 5: Ubiquiti (Unifi_SetHealthReadings) - executed.
2017.11.13 09:43:24 5: Ubiquiti (Unifi_SetClientReadings) - executed.
2017.11.13 09:43:24 5: Ubiquiti (Unifi_SetAccesspointReadings) - executed.
2017.11.13 09:43:24 5: Ubiquiti (Unifi_ProcessUpdate) - finished after 1.5618 seconds.
2017.11.13 09:43:54 5: Ubiquiti (Unifi_DoUpdate) - executed.
2017.11.13 09:43:54 5: Ubiquiti (Unifi_GetClients_Send) - executed.
2017.11.13 09:43:56 1: Perfmon: possible freeze starting at 09:43:55, delay is 1.358
2017.11.13 09:43:56 5: Ubiquiti (Unifi_GetClients_Receive) - executed.
2017.11.13 09:43:56 5: Ubiquiti (Unifi_GetClients_Receive) - state:'ok'
2017.11.13 09:43:56 5: Ubiquiti (Unifi_ProcessUpdate) - executed after 1.4252 seconds.
2017.11.13 09:43:56 5: Ubiquiti (Unifi_SetHealthReadings) - executed.
2017.11.13 09:43:56 5: Ubiquiti (Unifi_SetClientReadings) - executed.
2017.11.13 09:43:56 5: Ubiquiti (Unifi_SetAccesspointReadings) - executed.
2017.11.13 09:43:56 5: Ubiquiti (Unifi_ProcessUpdate) - finished after 1.4549 seconds.
2017.11.13 09:44:17 3: CUL_HM set Zwi_Steck_Flur statusRequest
2017.11.13 09:44:26 5: Ubiquiti (Unifi_DoUpdate) - executed.
Was mir auffällt ist das die Freezer immer nach diesem Eintrag kommen 2017.11.13 09:42:51 5: Ubiquiti (Unifi_GetClients_Send) - executed.
Hat noch jemand eine Idee was ich probieren kann?
Unifi und Fhem laufen parallel auf einem Cubietruck.
Hi,
Versuch mal das Aktualisierungsinterval in der def des Unifi-Devices zu verlängern (von 30 auf 60 Sekunden).
Wie sieht denn ein top auf dem cubietruck aus? Nutzt Java (und damit vermutlich der Unifi-Controller) viele Ressourcen?
Ja alle ca 30 sec. geht die auslastung auf ca. 60% bis 80%. Mir würde es ja reichen wenn mir in fhem nur die wlan Geräte gezeigt werden kann ich da vielleicht noch Leistung einsparen irgendwie? den intervall auf 60 sec zu stellen finde ich icht so optimal da ich die anwesenheitserkennung damit machen möchte. ist dann etwas lang.
Also ein ändern des abruf intervalls ändert die häufigkeit der Freezer im Log und auch die auslastung im htop.
Bei mir lief bis vor kurzem auch fhem und Unifi auf einem RasPi. Führte dazu, dass man bei Nutzung von automatisierten Funktionen ab und an (wenn er das Refresh-Interval getroffen hat) recht lange auf Feedback gewartet hat. Jetzt habe ich nen eigenen RasPi für Unifi und alles läuft flüssiger.
@Roli1606
Hatte ich weiter oben schon mal geschrieben. Mach es doch mit presence und ping. Glaub nicht das der Ping viel last verursacht.
Eigentlich bemerke ich keine Beeinträchtigungen und beide Systeme laufen ja ungestört nebeneinander. Lediglich die Abrufe vom fhem kosten reichlich Rechenleistung.
Kann man da nicht noch was abspecken
Gruß Roland
Hi,
ich habe das Modul experimentell im Anhang um ein set updateClient <mac> erweitert. Bitte versuche mal in der def des Unifi-Moduls das Update-Interval sehr lang zu setzen (z.B. 3600) und dann in einem at alle 30 Sekunden das set updateClient aufzurufen. Bin gespannt, was dein cubietruck dann performancemäßig macht.
Hast du die ping-Alternative mal ausprobiert?
Die ping Methode hatte ich vor Jahren schon mal und war nicht zufrieden. Wenn die Handys im Standby sind lassen die sich nicht immer anpingen. Mit Unifi ist das endlich mal vernünftig zu realisieren finde ich.
Hab jetzt das updateClient mal kurz laufen lassen. Die Last geht zwar immer noch periodisch hoch aber ich habe keine freezer mehr im Log. So würde mir das reichen. Kann ich da jetzt auch mehrere Mac Adressen durch Komma getrennt updaten? Das wäre ein Traum.
Gruß Roland
Mehrere Mac-Adressen per Komma trennen lässt die Unifi-Api nicht zu. Musst du dann jeweils ein eigenes at für machen. Wenn ein client connected ist könnte man das at auch aussetzen, dich interessiert ja nur das Heimkommen schnell hinzubekommen. Das zieht dann insgesamt natürlich wieder Performance. Wieviele clients hast du denn?
Es gibt auch noch das Attribut ignoreWiredClients. Vielleicht hilft das ja schon.
Die Version im Anhang oben ist echt experimentell. Habe das interne Datenmodell des Moduls sowie die Antworten der Unifi-Api noch nicht ganz durchschaut (z.B. Was passiert bei geblockten Clients?). Ich glaube das disconnect wird aktuell nicht richtig erkannt. Das Testen ist auch etwas zeitaufwändig, da man immer 5 Minuten warten muss bis die Api einen client nicht mehr mitsendet. Also bitte bald wieder das Original einspielen. Aber lass erst mal ein wenig laufen und schau, ob irgendwann doch wieder freezes kommen.
PS: Altuell scheint der Maintainer im Urlaub zu sein. Er sollte auch noch eine Meinung dazu abgeben.
PPS: Über eine Dokumentation für die commanref wäre ich glücklich. Kann ein echter Anwender eines Features meist besser ;-) (Falls es das Feature dann in das Modul schafft)
das attr ignoreWiredClients habe ich schon gesetzt bringt aber nichts habe auch nur WLAN Geräte am Unifi. Könnte man denn vielleicht ein attr machen in dem man nach Mac adresssen filtert? damit nur diese geräte upgedatet werden? Ich habe aktuell nur 2 Geräte die ich Aktualisieren möchte. Aber in Zukunft werden es wohl noch mehr werden.
Danke für die Hilfe Gruß Roland
Hi,
ich habe gerade die neueste Version des Unifi-Controllers installiert. Dort gibt es eine Beta-Notification. Man kann sich darüber Mails senden, wenn sich z.B. ein Client connected/disconnected. Diese mit Mailcheck abfragen und darüber Anwesenheitserkennung realisieren.
Das macht das Ganze unabhängig von einem Polling-Interval.
Funktioniert beim ersten Versuch gar nicht schlecht :) Die Infos kommen im Mailcheck ziemlich schnell an.
EDIT: Leider kommt in Mailcheck nur das Subject an. Und darin stehen leider keine client-Infos :-(
Habe gerade zufällig in der Unifi-Community einen Beitrag gefunden, der einige von euch interessieren könnte:
https://community.ubnt.com/t5/UniFi-Wireless/NOTICE-UniFi-Controller-Memory-Usage-5-6-20/td-p/2137209 (https://community.ubnt.com/t5/UniFi-Wireless/NOTICE-UniFi-Controller-Memory-Usage-5-6-20/td-p/2137209)
Der Controller ab V5.6.20 nimmt sich per Default 1 GB Arbeitsspeicher. Wie man das konfigurieren kann steht im Artikel.
Ich habe mir mailcheck um das Auslesen des Bodys erweitert (https://forum.fhem.de/index.php/topic,14092.msg716826.html#msg716826 (https://forum.fhem.de/index.php/topic,14092.msg716826.html#msg716826)).
Damit geht die Erkennung bei Ankunft echt schnell. Mit einem Notify kann man den entsprechenden Roommate dann auf home bzw. absent setzen.
Im Unifi-Controller habe ich unter user-preferences dazu den Versand von html-mails deaktiviert.
Hier ist ja nichts mehr los.
Ich habe meine Anwesenheitserkennung jetzt auch per E-Mail eingerichtet. Das funktioniert auch sehr zuverlässig. mein einziges Problem ist das die Mail ca 1:30min braucht bis sie bei fhem ankommt. Ich habe schon google, t-online und gmx als Server und Empfänger ausprobiert, aber leider ohne Erfolg. Würde mal gerne wissen wie lange das bei dir dauert. Und mit welchen Provider du das realisiert hast. Hatte schon mal gedacht ob ein lokaler Mailserver schneller ist. Ich habe nur keine Ahnung wie ich das aufbauen kann.
Gruß Roland
Hi Roli,
keine 6 Sekunden vom klick auf reconnect im Unifi-Controller bis zum Eingang der Mail in Mailcheck. Nutze gmx.
Sendest und empfängst du mit dem gleichen Konto? Ich habe immer 2 verschiedene Email Konten zum Senden und Empfangen eingerichtet. Vielleicht kommt daher die Verzögerung.
Gesendet von meinem F5321 mit Tapatalk
Ja, nutze dasselbe Konto. Vielleicht braucht der SPAM-Filter so lange???
Also ich habe mir jetzt auch ein Kostenloses GMX Konto angelegt. Habe den spamfilter und den Virenscanner deaktiviert. Trotzdem dauert es ca. 1 min bis der status in fhem erkannt wird. Habe aber das gefühl das die Mail einfach erst später raus geht vom Unifi-server. Wenn die Mail im Postfach ankommt wird sie auch umgehend in Fhem verarbeitet. Finde da aber leider nichts zu im Unifi Forum
Gruß Roland
Im UniFi Controller habe ich folgendes konfiguriert:
Hostname: mail.gmx.net
Port: 465
Enable SSL: ja
Enable authentication: Ja
User und Passwort
Absender wie user
Edit: worauf läuft dein fhem und der UniFi Controller? Vielleicht hat deune Controller ein Ressourcen-Problem. Fisable mal das fhem-Unifi-Device und teste. Das braucht man für diesen Anwendungensfall ja gar nicht.
das FHEM-Unifi-device habe ich auf disabel stehen. Die Daten habe ich auch genau so eingetragen im Unfi server.
Und auf welcher Hardware laufen unifi und fhem? Beide auf demselben RasPi?
Auf dem selben cubietruck
Gesendet von meinem F5321 mit Tapatalk
Und, hat der evtl. Performanceprobleme? Oder Speicherprobleme? Mal nen "top" gemacht? Früher war es bei dir ja so, dass in fhem ein freeze kam.
Die neueste Unifi-Version nimmt sich ja per default 1 GB Ram. (siehe https://forum.fhem.de/index.php/topic,40287.msg716418.html#msg716418 (https://forum.fhem.de/index.php/topic,40287.msg716418.html#msg716418))
Ich kann mir vorstellen, dass der Mailversand im Controller nicht die höchste Prio hat.
Also ich hatte anfangs direkt die Speicher-Reservierung für den Unifi Server runter geschraubt auf 512 MB. Ich hab das jetzt gerade mal wieder rückgängig gemacht. Bei htop ist der Speicher recht voll aber nicht es sind noch ca. 600 MB frei. Die CPU ist auf rund 50% in der Spitze. Denke mal nicht das es daran liegt.
MFG Roland
habe gerade mal das plugin aktiviert, würde mir gern von ein paar devices das ganze um ftui anzeigen lassen, aber irgendwie mag er das nicht so recht auslesen.
Ein wenig mehr Infos wären Klasse, falls du Hilfe bekommen möchtest. ;)
welche infos benötigst du den?
DEF 192.168.1.5 8443 user pass
NAME MyUnifi
NOTIFYDEV global
NR 225
NTFY_ORDER 50-MyUnifi
STATE connected
TYPE Unifi
READINGS:
2018-01-09 12:10:23 Blu-ray connected
2018-01-09 12:10:23 Blu-ray_accesspoint 192.168.1.16
2018-01-09 12:10:23 Blu-ray_hostname 192.168.1.35
2018-01-09 12:10:23 Blu-ray_last_seen 2018-01-09 12:10:01
2018-01-09 12:10:23 Blu-ray_snr 44
2018-01-09 12:10:23 Blu-ray_uptime 3969
2018-01-09 12:10:23 Drucker connected
2018-01-09 12:10:23 Drucker_accesspoint 192.168.1.16
2018-01-09 12:10:23 Drucker_hostname DRUCKER
2018-01-09 12:10:23 Drucker_last_seen 2018-01-09 12:10:01
2018-01-09 12:10:23 Drucker_snr 41
2018-01-09 12:10:23 Drucker_uptime 3973
Helper:
DBLOG:
Drucker:
DbLog_intern:
TIME 1515492334.93439
VALUE connected
beides auf der selben VM (ubuntu 17.10)
https://wiki.fhem.de/wiki/FHEM_Tablet_UI sollte evtl bekannt sein,
dort möchte ich z.b. den status sehen wie bei den lampen also Geräte name z.b. drucker und lampe grün wenn connectet und grau wenn nicht da, _last_seen und _snr , das wars es auch schon evtl noch welcher hotspot verwendet wird.
mit
<section>
<div data-template="template_wlan.html" data-parameter='{"var_device":"MyUnifi","var_unit_data":"Drucker","var_symbol":"fa-wifi","var_name":"Galaxy-Note-Ralph"}'></div>
</section>
template_wlan
<div data-type="symbol" data-device="var_device" data-states='["disconnected","connected"]' data-colors='["blue","green"]' data-icon="var_symbol" class="big compressed"></div>
<div class="cell-80 left-align">
<div class="big">var_name</div>
<div data-type="label" data-device="var_device" data-get="var_unit_data"></div>
</div>
funktioniert zwar die anzeige vom MyUnifi selbst aber eben nicht von die clients.
das 2. ist in den readings wird beim client nicht die essid angegeben kan man dies hinzufügen?
Ich glaube ich habe verstanden, was du möchtest. Sieht aber eher nach eine ftui-Problem aus. Bitte dort in einem passenden Thread nachfragen. Kenne auch deine template_wlan.html nicht.
Code bitte in code-Tags schreiben. Macht es einfacher zu lesen.
Mit folgendem Code kann ich mir den Status meines Harmony-Hub anzeigen lassen:
<li data-row="1" data-col="1" data-sizex="2" data-sizey="2" class="semitransparent">
<header>Client</header>
HarmonyHub:
<div data-type="label"
data-device="Unifi"
data-get="HarmonyHub">
</div>
</li>
Edit: Im Anhang eine Version mit essid.
Cannot load module Unifi
2018.01.10 08:54:36 5: Loading ./FHEM/74_Unifi.pm
2018.01.10 08:54:37 1: reload: Error:Modul 74_Unifi deactivated:
Can't use a hash as a reference at ./FHEM/74_Unifi.pm line 1593, <$fh> line 748.
2018.01.10 08:54:37 0: Can't use a hash as a reference at ./FHEM/74_Unifi.pm line 1593, <$fh> line 748.
Undefined subroutine &main::Unifi_SSIDs called at ./FHEM/74_Unifi.pm line 183.v
hab mir den teil mit der essid in die originale gespielt und es funktioniert erst einmal , danke
Hallo wuehler, ich möchte gern mein Unifi Wlan per Fhem deaktivieren. Leider bekomme ich eine Fehlermeldung beim Einbinden Deines Moduls
2018.01.10 19:26:55 1: reload: Error:Modul 74_Unifi deactivated:
Can't use a hash as a reference at ./FHEM/74_Unifi.pm line 1593, <$fh> line 582.
2018.01.10 19:26:55 0: Can't use a hash as a reference at ./FHEM/74_Unifi.pm line 1593, <$fh> line 582.
Leider bin ich nicht so fit in Perl-Programmierung um es selbst zu beheben :-(
Versuch mal die angehängte Version. Ich lerne perl ja auch gerade noch. Kommt wohl auf die perl-Version an. Welche nutzt du?
Wuehler ist nun als zusätzlicher Maintainer für dieses Modul in der MAINTAINER.txt eingetragen und kümmert sich um 74_Unifi in Zukunft.
Würde mich freuen wenn ich wieder zum fhemen komme und ein update mache paar tolle neue features zu finden, bzw. zumindest dass es bei allen ohne Probleme läuft :)
Gruß an alle
Vielen Dank für den schnellen Bugfix. Es funktioniert nun alles :) :)
Bei mir läuft übrigend Perl v5.24.1
Zitat von: Wuehler am 10 Januar 2018, 20:36:17
Versuch mal die angehängte Version. Ich lerne perl ja auch gerade noch. Kommt wohl auf die perl-Version an. Welche nutzt du?
Bekommt man das Update eigentlich auch über die FHEM internen Mechanismen. Bin mir grad nicht mehr sicher, wie es am Anfang war.
Aktuell solltest du das Modul aus dem Update herauslassen (attr global excludefromupdate ...)
Ich habe mich gestern in den Status eines Entwicklers aufnehmen lassen. Beschäftige mich dann am Wochenende damit, wie das Veröffentlichen neuer Versionen technisch am besten funktioniert und welche weiteren Rahmenbedingungen beachtet werden müssen.
Anschließend werde ich die Anpassungen Stück für Stück in die offizielle Version des Moduls übernehmen. Schreibe dann hier im Forum immer etwas dazu.
Mein erster commit als developer ist getätigt :) Im Update sind folgende Features enthalten:set <name> blockClient <clientname>
set <name> blockClient <clientname>
Block the <clientname>
set <name> unblockClient <clientname>
Unblocks the <clientname>
set <name> disableWLAN <ssid>
Disables WLAN with <ssid>
set <name> enableWLAN <ssid>
Enables WLAN with <ssid>
new client reading "essid"
Vielen Dank an rapster für die Unterstützung.
@Wuehler & @rapster
Ich habe einen Feature Request für das 74_Unifi Modul. Ich würde mir wünschen, dass man die LED der APs per Modul ein- und ausschalten kann. Entweder einzeln pro AP oder aber für die gesamte Site. Die LEDs der APs sind in der Nacht schon sehr hell und im Moment schalte ich die LED immer per UniFi-Webinterface vor dem Schlafen gehen aus. Es wäre super, wenn man das über das Modul per Fhem steuern könnte. Eine zeitbasierte Funktion diesbezüglich wurde schon bei Unifi von mehreren Usern gewünscht, wurde aber bisher nicht umgesetzt.
Ich stelle mir vor, dass ich z. B. "set Unifi enableStatusLED 0/1" setze und dann die Funktion "Site - Enable status LED" im Webinterface umgeschaltet wird. Ist es möglich ohne großen Aufwand diese Funktion zu implementieren?
Viele Grüße
Tobias
Hallo Tobias,
da es auf einen ersten schnellen Blick dafür eine API von Unifi gibt sollte das recht einfach gehen. Ich setze mich die Tage mal ran.
Viele Grüße,
Dirk
Vielen Dank, Dirk! Das wäre wirklich super. Das würde dass schon jetzt sehr umfangreich nutzbare Modul für mich noch abrunden.
Liebe Grüße
Tobias
Hallo Tobias,
versuch mal die angehängte Version. Seltsamerweise verschwindet bei mir im Unifi-Controller der Haken beim disablen, beim enablen wird er aber nicht wieder gesetzt, obwohl die LEDs an gehen. Wie ist es bei dir?
Viele Grüße,
Dirk
Danke Dir! Ist bei mir aber genau so. Die Funktion ein/aus ist gegeben, aber beim enablen wird der Haken nicht gesetzt.
Wenn es nur diese kosmetische Anzeige ist, könnte ich damit leben. ;)
Viele Grüße
Tobias
Habe den Fehler gefunden. Kleiner typo. Versuch mal die neue.
Funktioniert nun wunderbar! Vielen Dank für den schnellen Service! ;)
Viele Grüße
Tobias
Cool!
Könnte ich mir gut als "Benachrichtigungs-Led" vorstellen, bei mir is der LED-Ring sonst eh immer aus (Frau erlaubt es nicht) ;).
Grüße
Morgen dann im Update :)
Und wenn die Nachricht dringend ist, dann nutzt du locateAP, dann blickt der LED-Ring ;)
Hi,
habe jetzt längere Zeit den Thread nicht mehr verfolgt, "leider" haben andere Projekte Vorrang ;)
Finde es Super das es hier weiter vorran geht !!! Danke an Wuehler !
Da hätte ich gleich mal ne Frage ;)
Ist es wohl möglich zukünftig einiges vom UNIFi Controller in FTUI einzubinden.
Hatte im Unifi Forum mal gesehen, wie sie jemand mit dem API Modul etwas gebastelt hatte und ihm die Grafiken Datenverkehr etc angezeigt wurden.
Sowas in die Richtung fände ich schon genial
Werde allgemein jetzt wieder hier mehr sein und gerne testen etc.
Grüße
Torsten
Hallo Thorsten,
Das wäre dann ein größeres Thema. Ich finde das Modul hat jetzt schon zu viele Readings. Man müsste es dann erstmal zweistufig aufbauen. Ein IODev-Modul als physikalisches Device und viele weitere für sie diversen Themen als logische Devices.
Am Ende baut man die Unifi-Controller-Oberfläche komplett nach und supportet am besten auch noch alle Controller-Versionen.
Ich habe das Gefühl, dass das nicht sinnvoll ist. Anforderungen die einer Automatisierung dienlich sind (z.B. auch den Missbrauch der LEDs zur Anzeige von Nachrichten) finde ich gut, gegenüber Anforderungen die reinen Dashboard-Charakter haben bin ich wegen des dann entstehenden Gesamtumfangs des Moduls etwas skeptischer eingestellt.
Viele Grüße,
Dirk
Hi Dirk,
ich wollte gerade mal versuchen, meine Lösungen zum Aktivieren/Deaktivieren des Gäste-WLANs via externer Skripte auf die neuen Funktionen hier im Modul umzustellen. Zwei Dinge sind mir aufgefallen:
1. Interessanterweise erkennt das Modul aber nicht alle konfigurierten WLANs am Namen.
Zwar erkennt er lt. List alle WLANs:
wlans:
595218024f0c10ea8919608b:
[...]
name Main
[...]
59849c1b4f0c6624c30fccda:
[...]
name Gast
[...]
599074a84f0cc4b26eb1b641:
[...]
name Secure
[...]
5a0e81c04f0c64410e58509f:
[...]
name Deschding
[...]
Aber in der Dropdown-Box für die Befehle disableWLAN und enableWLAN stehen nur "Secure" und "Deschding" mit Namen. Die anderen beiden stehen mit ihrer id dort (obwohl im List ja der Name auch auftaucht).
Das manuelle Absetzen der Befehle mittels ssid scheint aber zu funktionieren.
2. Ich kann so zwar enableWLAN und disableWLAN ausführen. Aber ein Reading, aus dem ich sehen kann, ob WLAN X auf den APs enabled oder disabled ist, gibt es nicht, oder? D.h. man müsste alle -AP_.*_essid Readings auf (doppeltes) Vorhandensein der SSIDs testen?
Wenn es solche einfachen Readings gäbe, könnte man das Anzeigen und Schalten des Status' ohne zusätzlichen Dummy und viel Code in, z.B., einer Readingsgroup unterbringen. Planst Du, sowas aufzunehmen?
Falls nicht (aber nur dann! :-)), würde ich mal schauen, dafür ein userreading zu basteln und das hier zu posten.
Danke, Christian
Hi Dirk - Noch was anderes, was mir gerade auffiel, als ich das Blocken von Clients auf die entsprechende Funktion im Modul umstellen wollte:
Bei einem Block-Test (einfaches Absetzen des Block-Befehls via Webinterface über die vorgegebenen Dropdown-Boxen) ist fhem abgestürzt:
Undefined subroutine &main::Unifi_BlockClient_Send called at ./FHEM/74_Unifi.pm line 208.
Gruß, Christian
Hi,
das mit dem blockClient ist gefixt. Morgen im Update. Weiß auch nicht wie mir das passieren konnte. Bin mir sicher, dass ich das getestet hatte.
zu 1. Die IDs statt SSIDs in der DropDown muss ich mir mal in Ruhe ansehen. Eher am Wochenende.
zu 2. Da scheint es einen Bug (?) im list zu geben. Wenn der aus JSON in den Hash übernommene Wert ein JSON::true (und nicht "true") ist, wird er bei list nicht mit ausgegeben. Könnte also in Ruhe dann Readings für <ssid>_enabled hinzufügen. Oder JSON::true wird nicht mit in den hash kopiert?
Gruß,
Dirk
Hallo zusammen,
ich habe leider ein Problem mit Presence und der Erkennung meines Iphones. Unter Presence Device Overview stehen bei mir seit der Einrichtung des Unifi AP in FHEM ausschließlich drei
???
Unter Internals steht folgendes:
event UniFi:meiniphone:.disconnected UniFi:meiniphone:.connected
In den Readings des Unifi AP steht das Device mit der jeweils aktuellen Uhrzeit.
meiniphone
connected
2018-01-20 09:40:46
Habt ihr eine Idee was da schief läuft oder wo ich ansetzen könnte.
Grüße
und Danke
Steven128
Hallo Wuehler,
ich habe gerade ein FHEM update gemacht und anschliessend neu gestartet.
Da kommt nun eine Perl Warnung.
PERL WARNING: main::Unifi_SSIDs() called too early to check prototype at ./FHEM/74_Unifi.pm line 1476, <$fh> line 350.
wenn Du mal bereinigst wäre es toll wenn Du danach schaust.
Danke!
Jetzt bräuchte ich mal etwas RegExp-Unterstützung:
Warum findet
$wlanRef->{name} =~ /^([\w\.\-]+)$/) {
das WLAN "Secure", aber nicht das WLAN "Gast"?
siehe fünf Posts vorher von MotivierteLinkeHände.
Ein Reading für den Status (enabled/disabled) habe ich eingebaut, ebenso das Warning gefixt. Wenn jetzt noch jemand die RegExp erklären kann packe ich alles ins nächste Update.
@Steven128: Wie ist denn dein presence definiert? Ich vermute, dass hier der falsche Thread für dein Problem ist, eher bei PRESENCE. Das Unifi-Modul scheint ja alles richtig zu machen. Ich persönlich nutze PRESENCE nur experimentell für mich, da bei uns nicht alle Roommates technisch gut identifizierbar sind ;)
Hoi,
@Steven128
Presence hab ich so definiert, läuft bei mir 1a
defmod <NAME> PRESENCE function {ReadingsVal('<UNIFYDEVICE>','<HOSTNAME DES GERÄTES IM UNIFY>','') eq "connected" ? 1 : 0} 60 60
<HOSTNAME DES GERÄTES IM UNIFY> ist bei mir "android-xxxxxxx"
Hoffe es hilft etwas weiter ;)
Ronny
Mit einem Regexp "a aber nicht b" zu realisieren ist sehr muehselig, ich empfehle zwei Pruefengen, einmal mit =~ und einmal mit !~
Ich verstehe den regExp so, dass zwischen Anfang und Ende des Strings nur Zahlen, Buchstaben, der Punkt und das Minus zugelassen sind. Das trifft auf "Main", "Gast", "Secure" und "Deschding" zu.
@MotivierteLinkeHände: Ist da evtl. doch irgendwo ein Leerzeichen in deiner SSID? Bei mir funktioniert es mit einem WLAN namens "Main" auch.
Nein, kein Leerzeichen. Aber ja, SSIDs mit, z.B., Ausrufezeichen werden auch nicht gefunden.
Ich kann ja über die php API die WLAN Configs auslesen. Das sieht ganz harmlos aus:
"name": "Main"
Auch nicht gefunden wird die - zulässige - SSID "Secure!". Das passt zu Deinem Test per regexp.
Aus Neugierde: Warum hast Du den Test auf einen zulässigen Namen überhaupt drin? Ich habe mal ein Logging eingebaut, bei mir liest er aus der Config im Namensfeld keinen Müll aus. Er verwirft bei dem Test nur bestehende SSIDs. (Kann man z.B. schön mit einem ! im Namen testen.) Wie wäre es, wenn Du beim Test des SSID-Namens auf Unifi vertraust und $wlanref->{name} ohne weiteren Test übernimmst?
Ich habe mich da an die Implementierung von rapster gehalten. Da ist sicherlich eine gewisse Vorsicht dabei gewesen, keine Sonderzeichen zuzulassen, um nicht aufgrund seltsamer Fehlermeldungen überall Sonderbehandlungen einbauen zu müssen.
Ich übertreibe jetzt vielleicht ;) denke aber, dass das der Grund war.
Interessanter finde ich, warum Main und Gast bei dir nicht funktionieren, bei mir aber schon.
Neues Reading für WLAN-Status sowie Behebung der Warning ist eingecheckt. Bitte testen und krzes Feedback geben.
@MotivierteHände: konntest du das Problem mit Main und Gast eingrenzen oder soll ich mal eine Version mit mehr Logausgaben bauen?
Danke, Logausgaben habe ich mir selbst gebaut. Wenn ich den regexp-Check rausnehme, funktioniert hier alles, mit Check das meiste.
Wenn ich das nächste Mal mehr Zeit habe, kann ich nochmal mit den Namen testen. Bis dahin nehme ich den Check hier raus und nehme das Modul vom Update aus. Dann passt es auf jeden Fall auch. ;D
Danke nochmal,
Christian
Zitat von: Wuehler am 22 Januar 2018, 12:00:56
Neues Reading für WLAN-Status sowie Behebung der Warning ist eingecheckt. Bitte testen und krzes Feedback geben.
Guten Abend,
ich habe heute zufällig nach dem Update gesehen dass man jetzt auch WLANs aktivieren/deaktivieren kann. Direkt ausprobiert, funktioniert Top. Auch der Status meiner verschiedenen WLANs wird sauber ausgegeben.
In diesem Sinne, herzlichen Dank für dieses neue Feature, ich habe es mir schon lange gewünscht :D
Vielleicht könntest du noch ein Reading oder ein get einbauen welches alle im Guest WLAN angemeldeten Nutzer zurückgibt. Das würde mir das filtern ersparen. Aber so ists auch schon super!
Gruß, Mohrengemuse
Hallo Wühler,
Schön daß es hier wieder weiter geht :)
Baust du die Voucher Geschichte wieder in die Update Version ein?
Gruß
Eisix
Zitat von: Wuehler am 22 Januar 2018, 12:00:56
Neues Reading für WLAN-Status sowie Behebung der Warning ist eingecheckt. Bitte testen und krzes Feedback geben.
@MotivierteHände: konntest du das Problem mit Main und Gast eingrenzen oder soll ich mal eine Version mit mehr Logausgaben bauen?
So, habe mal gerade das Update mit der neuen Version eingespielt und dann auch in Unifi mit den SSIDs herumgespielt. Ich weiß nicht, was vorher schiefgelaufen war oder sich an komischen Zeichen eingeschlichen hatte. Aktuell scheint es so zu sein, dass die SSIDs mit nur "normalen" Zeichen alle von Deinem Modul erkannt werden. Wenn ich ein Ausrufezeichen in die SSID einbaue, erkennt das Schaltfeld zum An- und Ausschalten von WLANs die SSIDs nicht mehr, sondern arbeitet mit der ID von Unifi. Deine Readings für den Status der WLANs allerdings erkennen auch SSIDs mit Ausrufezeichen. :-) Und wenn ich die enable bzw. disable Kommandos händisch eingebe, kann ich auch dort die SSIDs mit Ausrufezeichen verwenden. Nur für die Dropdownbox scheint die regexp-Prüfung zuzuschlagen.
Danke für den Test. Ich denke da habe ich dann folgendes zu tun:
1. laut https://wiki.fhem.de/wiki/DevelopmentModuleAPI (https://wiki.fhem.de/wiki/DevelopmentModuleAPI), dort goodReadingName(), werde ich beim erstellen des Readings die Funktion makeReadingName() verwenden. Das heißt, dass Sonderzeichen durch einen Unterstrich ersetzt werden.
2. in der DropDown-Liste lasse ich dagegen alles außer Leerzeichen zu.
3. Hinweise dazu in die commandeef aufnehmen.
@Eisix: Der VoucherCache kommt auch wieder. Ich wollte die ganzen Anpassungen aber lieber Stück für Stück von der Einfachsten zur Umfangreichsten in die offizielle Version übernehmen. Das macht allen die Fehlersuche einfacher ;)
Vielen Dank, für mich macht das alles sehr viel Sinn!
So, ist eingecheckt. Überall wo die WLAN-SSIDs verwendet werden wird vor der Anzeige makeReadingName() verwendet. Damit könnten sogar Leerzeichen in der SSID enthalten sein.
Ich denke dasselbe könnte man bei den Clients einbauen. Da wird immer der im Unifi-Controller hinterlegte Alias verwendet, es sei denn der Alias enthält Leer- oder Sonderzeichen, dann wird der Hostname verwendet, wenn der nicht existiert oder ebenfalls Leer-/Sonderzeichen enthält wird die interne ID verwendet.
Würde aber bedeuten, dass die Nutzer, die Sonderzeichen in Alias oder Hostname verwenden ihre notifies usw. anpassen müssen.
Zitat von: Wuehler am 27 Januar 2018, 13:24:09
Ich denke dasselbe könnte man bei den Clients einbauen.
Ich wäre dafür. Das gibt dann "ordentliche" Readings mit einem erwarteten Inhalt.
Vielen Dank für Deine stete Weiterentwicklung des Moduls!
bin auch dafür. eventuell über ein attribut aktivierbar wegen der rückwärts kompatibilität.
Ich habe nach dem Einsatz des Moduls (Danke dafür) eine alternative Methode gefunen mit der die Presence Erkennung etwas schneller (Present 25-45 Sekunden, Absent ca. 4-5 Minuten) und ressourcen-schonender (falls man den Controller auf einem Raspberry o.ä. hostet) zu bewerkstelligen ist.
Hier der Post dazu: https://forum.fhem.de/index.php/topic,83434.0.html
Falls Presence noch ein Thema ist, könnte man vieleicht diese Methode zusätzlich in das Modul integrieren.
Oder was habt ihr für Zeiten in der ihr die Erkennung realisiert bekommt?
Hi,
In der neuesten Unifi-Controller-Version gibt es eine Notification-Funktion. Damit kann man sich per Mail benachrichtigen lassen, wenn sich ein client connected/disconnectet. Zusammen mit dem Modul mailcheck wurde beides nach ca. 5 Sekunden in fhem registriert. Komplett ohne das Unifi-Modul. Mailcheck musste ich um zwei Zeilen erweiern. Siehe dortiges Forum. Nur wenn alle gleichzeitig das Haus verlassen wird manchmal eine der Mails übersprungen. Dann ist das Unifi-Modul als Fallback da.
Nebenwirkung ist leider, dass jedes (dis-)connect in Unifi einen Alert erzeugt.
Danke, @Wuehler, Update sieht gut aus.
Nur eine Frage: Kann es sein, dass Du makeReadingName() nicht nur auf die Namen von Readings, sondern auch auf die Inhalte anwendest? In den Readings .*_essid sind die Sonderzeichen auch gegen '_' getauscht.
Schönen Sonntag!
Ja, in FHEM sollte alles konsistent sein, damit man Readings als Input für Aktionen nehmen kann.
Im Anhang eine Testversion mit einem neuen Attribut "deprecatedClientName". Auszug aus der commandref dazu:
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)
Wäre Klasse, wenn es jemand testet bevor ich es einchecke. Anderweitiges Feedback dazu auch immer willkommen.
wollte nochmal nachfragen ob es nun die möglichkeit gibt das Gäste Wlan An / Aus zu schalten über fhem ? Hab mich damit letztes Jahr mal beschäftigt aber die wirklich einfache lösung wie bei der Fritzbox gab es da noch nicht.
Danke
Ja, gibt es. fhem updaten, dann hast Du disableWLAN und enableWLAN.
Zitat von: Gimbel am 27 Januar 2018, 17:40:11
Ich habe nach dem Einsatz des Moduls (Danke dafür) eine alternative Methode gefunen mit der die Presence Erkennung etwas schneller (Present 25-45 Sekunden, Absent ca. 4-5 Minuten) und ressourcen-schonender (falls man den Controller auf einem Raspberry o.ä. hostet) zu bewerkstelligen ist.
Hier der Post dazu: https://forum.fhem.de/index.php/topic,83434.0.html
Falls Presence noch ein Thema ist, könnte man vieleicht diese Methode zusätzlich in das Modul integrieren.
Oder was habt ihr für Zeiten in der ihr die Erkennung realisiert bekommt?
Also ich hätte an der Methode Interesse. Die Anwesenheits-erkennung mit mailcheck dauert bei mir auch rund 2 min. Aus irgendeinem Grund werden die Emails sehr verzögert gesendet obwohl der Cubietruck beim versenden der Mails nicht ausgelastet ist.
MFG Roland
Bei mir laufen fhem und der Unifi-Controller auf jeweils einem eigenen Raspi3. Da gibt es keine Probleme. Als ich beides auf demselben Raspi installiert habe gab es häufiger Performanceprobleme. Finde die 35 Euro für einen zusätzlichen Raspi haben sich gelohnt. Und viel Zeit hat das Aufsetzen usw. auch nicht gekostet.
Hi, ich schon wieder... :)
Bei einem erneuten Anlauf, das Blocken von Geräten und An-/Abschalten von SSIDs von meinen Bash-Skripten auf dieses Modul umzustellen, sind mir noch zwei Dinge aufgefallen:
Es wäre schön, wenn es ein Reading gäbe, das den aktuellen Block-Status anzeigen würde. Aktuell gibt es <Client> als Reading, das "connected" oder "disconnected" anzeigt. Daran kann ich aber nicht zweifelsfrei erkennen, ob das Gerät geblockt oder aus irgendeinem anderen Grund nicht connected ist. Die Unifi API liefert für blockierte Geräte einen blocked-Wert als true oder false zurück. Das ist m.E. der den Kommandos "blockClient" und "unblockClient" entsprechende Status. Das könnte man als neues Reading implementieren. Oder alternativ, um die Reading-Flut ein wenig einzudämmen, könnte man das <Client>-Reading um den Wert "blocked" erweitern. "Unblocked" bräuchte man nicht zwingend, da das dann "connected" oder "disconnected" ergäbe.
Es wäre schön, wenn 74_Unifi für "blockClient" und "unblockClient" auch die MAC-Adresse statt des Client-Namens akzeptieren würde. Denn den Client-Namen kann der Nutzer des Gerätes durch Veränderungen am Gerät ändern. Dann laufen fest kodierte Block-Kommandos, die auf dem Gerätnamen basieren, ins Leere. Das macht es dem Nachwuchs zu einfach, die Nutzungsbeschränkungen zu umgehen. Die MAC-Adresse ist da effektiver :)
Grüße, Christian
Zitat von: Motivierte linke Hände am 30 Januar 2018, 16:11:05Es wäre schön, wenn 74_Unifi für "blockClient" und "unblockClient" auch die MAC-Adresse statt des Client-Namens akzeptieren würde. Denn den Client-Namen kann der Nutzer des Gerätes durch Veränderungen am Gerät ändern. Dann laufen fest kodierte Block-Kommandos, die auf dem Gerätnamen basieren, ins Leere. Das macht es dem Nachwuchs zu einfach, die Nutzungsbeschränkungen zu umgehen. Die MAC-Adresse ist da effektiver :)
Ob das wirklich Abhilfe schafft... Ich sag mal so, es hängt davon ab, wie IT-affin deine Kinder sind. [emoji6]
https://www.google.de/amp/s/de.m.wikihow.com/Die-MAC-Adresse-eines-Computers-unter-Windows-ändern%3famp=1 (https://www.google.de/amp/s/de.m.wikihow.com/Die-MAC-Adresse-eines-Computers-unter-Windows-%C3%A4ndern%3famp=1)
Unter Linux ist das, wenn ich mich recht entsinne, auch nur ein Befehl auf der Command Line.
Gruß Hoppel
Wenn sich die MAC-Adresse ändert, mag der Radius-Server das Zertifikat nicht mehr akzeptieren. :)
Alles klar! Ich sehe, du sorgst für Sicherheit bei dir zu Hause... [emoji2]
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.
Hi Wuehler - Auf Deinen Hinweis hin habe ich mir das nochmal angeschaut:
Zitat von: Wuehler am 28 Januar 2018, 23:25:12
Im Anhang eine Testversion mit einem neuen Attribut "deprecatedClientName". Auszug aus der commandref dazu:
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?
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"
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 :)
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
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.
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. :)
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 ;)
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
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
Hallo,
gerade ein update all gemacht.
Folgendes im Logfile:
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
Hast du das Attribut ,,deprecatedClientName" auf false gesetzt? Durch manuelles editieren in der fhem.cfg?
Hallo,
momentan habe ich keine Attribute gesetzt. In der Konfig ist nur der define.
Manuell habe ich nichts editiert.
Gruß
Eisix
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
Hi Eisix nochmal,
im Anhang eine neue Version mit VoucherCache. Kannst du die bitte bei dir mal reinschmeissen und testen. Sollte so wie die alte funktionieren, plus die Änderungen die zwischenzeitlich dazugekommen sind. Da ich nur eine einzige Unifi-Infrastruktur habe und daher nur eine bestimmte Anzahl an "Testdaten" wäre es Klasse, einen zweiten Tester zu haben, um etwas sicherer zu sein, dass ich nichts übersehen habe.
Danke und Gruß,
Dirk
Hallo Wuehler,
Im log waren die zwei Meldungen nach dem Neustart. Die eine hatte ich schon geschickt. Haben aber so wie ich das sehe keinen Einfluss auf die Funktion.
2018.02.05 10:39:52.915 1: PERL WARNING: Use of uninitialized value $getVal in concatenation (.) or string at ./FHEM/74_Unifi.pm line 452.
2018.02.05 10:40:15.140 1: PERL WARNING: Use of uninitialized value $minSize in numeric lt (<) at ./FHEM/74_Unifi.pm line 1514.
Vouchures werden angezeigt (Frage sollte da nicht ein "-" in die Mitte der Zahl, musste ich bei mir immer so eingeben?)
Auf den ersten Blick würde ich sagen alles funktioniert. Heute Abend kann ich einen detaillierten Test machen.
Gruß
Eisix
Hallo,
Scheint alles zu funktionieren.
Gruß
Eisix
Super. Danke. Die beiden Warnings habe ich behoben. Dann checke ich nachher ein. Das Minus muss ich bei mir nicht mit eingeben. Der Voucher-Code kommt auch ohne Minus über die API.
Als nächstes versuche ich dann mal das Passwort zu verschleiern.
Moin,
eine kurze Frage, ist es so gewollt dass man mittels blockClient nur Devices blocken kann die gerade verbunden sind? Oder ist es über die API nicht anders möglich?
Hintergrund: ich würde gerne Devices blocken welche sich im Moment nicht im Netzwerk befinden.
Gruß Mohrengemuse
Dieselbe Frage hatte ich etwas weiter oben auch schonmal gestellt. :) Das hängt wohl ein wenig von der verwendeten API ab, über das fhem-Modul hier scheint es nicht zu gehen.
Solange der Client noch in den Readings auftaucht solltest du ihn blocken können, auch wenn er disconnected ist.
Ausnahme: du hast irgendwann mal clear clientData aufgerufen, dann bleibt der Client in den readings, aber ist in den internen Moduldaten nicht mehr vorhanden.
Das Modul verwendet nicht die client-Liste aus den Insights des Unifi-Controller. Es werden nur die Clients unter CLIENTS abgefragt, allerdings werden sie intern nicht automatisch gelöscht, wenn sie einmal connected waren.
Wie genau äußert sich denn dein Problem?
Ich habe jetzt für den Unifi Server einen RPI3 eingerichtet der auch problemlos läuft. Wenn ich jetzt das Unifi Modul auf einen 10 sec Intervall stelle habe ich mal wieder freezer hin und wieder im FHEM Log.
Wenn ich die Anwesenheit per Mailcheck überprüfe dauert der Mailversand immer noch eine Minute was mir viel zu lange ist und bei Wuehler nur 5 sec dauert. Es stehen keine Fehler im Log und mit htop ist auch alles in Ordnung.
Hat noch jemand einen Ansatz wodurch die Verzögerung verursacht werden kann?
MFG Roland
Hi Roland,
Ich habe mir gerade nochmal die commandref von mailcheck durchgelesen. Da ist im Attribut Interval ein Hinweis auf die Minute, die es bei dir dauert. Ist in den Internals von mailcheck IDLE auf 1? Wenn auf 0 dann wird jede Minute abgefragt, wenn ich es richtig verstehe. Wenn IDLE auf 1 wird eine Verbindung offen gehalten und man bekommt sofort die mails.
Gruß,
Dirk
PS: mein Unifi hat ein Interval von 30. Das neue Modul freezmon zeigt mir auch regelmäßig freezes an. Habe aber noch nicht verstanden, wo die herkommen könnten (habe aber auch nur kurz geschaut).
Zitat von: Wuehler am 15 Februar 2018, 22:47:54
PS: mein Unifi hat ein Interval von 30. Das neue Modul freezmon zeigt mir auch regelmäßig freezes an. Habe aber noch nicht verstanden, wo die herkommen könnten (habe aber auch nur kurz geschaut).
#metoo
;D
Hallo zusammen,
ich finde das Modul Unfifi echt top. Es funktioniert super zuverlässig bei mir. Eine Frage hätte ich aber noch. Ich habe nicht den Eindruck das es ein Problem gibt mit der Anwesenheitserkennung meines IPhone (Sleep Modus) im WLAN. Hat das einen technischen Hintergrund ? Wo ist da der Unterschied der Überprüfung mittels eines LAN Ping ? Hier soll es ja desöfteren zu Problemen kommen.
Grüße
sxx128
Zitat von: Wuehler am 15 Februar 2018, 22:47:54
Hi Roland,
Ich habe mir gerade nochmal die commandref von mailcheck durchgelesen. Da ist im Attribut Interval ein Hinweis auf die Minute, die es bei dir dauert. Ist in den Internals von mailcheck IDLE auf 1? Wenn auf 0 dann wird jede Minute abgefragt, wenn ich es richtig verstehe. Wenn IDLE auf 1 wird eine Verbindung offen gehalten und man bekommt sofort die mails.
Gruß,
Dirk
PS: mein Unifi hat ein Interval von 30. Das neue Modul freezmon zeigt mir auch regelmäßig freezes an. Habe aber noch nicht verstanden, wo die herkommen könnten (habe aber auch nur kurz geschaut).
Sorry ich habe deinen Beitrag gerade erst gesehen.
In meinem mailcheck device gibt es ein internal Namens HAS_IDLE und das steht auf 1
Meinst du das? Ich vermute auch das Problem liegt eher am Unifi Server als an fhem.
Mfg Roland
Gesendet von meinem F5321 mit Tapatalk
@sxx: ganz kurz und daher wahrscheinlich nicht komplett richtig: die wlan-verbindung wird auch im standby offen gehalten, das iphone schaltet aber die eigene Erreichbarkeit aus. Da Unifi der wlan-Partner ist weiß dieser, dass das iphone noch da ist, ein Dritter kann das iphone aber nicht erreichen.
@Roland: denke dann auch, dass es am Controller liegt. Welches Java nutzt du denn mit dem Controller ? Openjdk oder von oracle? Und in welcher Version?
Hallo
ja habe das überprüft. Habe einen Ping (ICMP) auf das Iphone gemacht. Sobald das Iphone in den SleepModus geht ist der ICMP weg. Trotzdem ist das Iphone noch im WLAN. Man bekommt ja auch weiterhin Messenger Nachrichten usw.
Trotzdem Danke für die Antwort.
Grüße
sxx128
Zitat von: Wuehler am 18 Februar 2018, 18:12:33
@Roland: denke dann auch, dass es am Controller liegt. Welches Java nutzt du denn mit dem Controller ? Openjdk oder von oracle? Und in welcher Version?
Ein Java -version zeigt mir das an
openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-1~deb9u1-b12)
OpenJDK Client VM (build 25.151-b12, mixed mode)
Hab das nach dieser Anleitung aufgesetzt meine ich zumindest.
Gruß Roland
Hi,
bei mir ergibt Java -Version ebenfalls openjdk, allerdings hatte ich das jdk von Oracle ebenfalls installiert und starte unifi damit. Das sieht man, wenn man folgenden Befehl eingibt:
sudo service unifi status
Da kommt das bei raus
pi@UNIFI:~ $ sudo service unifi status
* unifi.service - unifi
Loaded: loaded (/lib/systemd/system/unifi.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2018-02-18 20:50:51 CET; 34min ago
Process: 561 ExecStart=/usr/lib/unifi/bin/unifi.init start (code=exited, status=0/SUCCESS)
Main PID: 601 (jsvc)
CGroup: /system.slice/unifi.service
|- 601 unifi -cwd /usr/lib/unifi -home /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt -cp /usr/share/java/commons-daemon.jar:/usr/lib/unifi/lib/ace.jar -pidfile /v
|- 602 unifi -cwd /usr/lib/unifi -home /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt -cp /usr/share/java/commons-daemon.jar:/usr/lib/unifi/lib/ace.jar -pidfile /v
|- 603 unifi -cwd /usr/lib/unifi -home /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt -cp /usr/share/java/commons-daemon.jar:/usr/lib/unifi/lib/ace.jar -pidfile /v
|- 670 /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt/jre/bin/java -Xmx1024M -XX:ErrorFile=/usr/lib/unifi/logs/hs_err_pid%p.log -Dapple.awt.UIElement=true -jar /us
`-1526 bin/mongod --dbpath /usr/lib/unifi/data/db --port 27117 --unixSocketPrefix /usr/lib/unifi/run --logappend --logpath /usr/lib/unifi/logs/mongod.log --n
Feb 18 20:50:50 UNIFI systemd[1]: Starting unifi...
Feb 18 20:50:51 UNIFI unifi.init[561]: Starting Ubiquiti UniFi Controller: unifi.
Feb 18 20:50:51 UNIFI systemd[1]: Started unifi.
Das sieht so aus wie bei mir. Findest du im server.log des UC etwas?
Ich hab die Ursache gefunden vermute ich. Im Unifi-server gibt es unter Konto-Bearbeiten ein Häckchen "Ähnliche Alarme in einer E-Mail senden". Wenn der gesetzt ist Wartet der Server eine Minute um E-mails zu sammlen.
Trotzdem Herzlichen dank für die super untersützung insbesondere an Wuehler.
Sehr schön. Das war zu einfach zu finden ;D
Läuft es denn jetzt wie gewünscht?
Ich muss mal noch genau testen wie die Performance ist. Gestern beim reconnect war die Email nach ca 10sec verarbeitet. Mal schauen wie das so im Alltag ist. Momentan haut mit der Performance Monitor viele Meldungen rein die meistens mit der Anwesenheitserkennung zu tun haben. Muss das jetzt mal etwas ausgiebiger testen.
Gesendet von meinem F5321 mit Tapatalk
Hi,
bei mir ist in den Readings ein Gerät "connected" das seit dem 5.3.18 nicht mehr angemeldet war als. Ist das normal? Soweit ich mich recht erinnere fällt mir das Problem erst seit einem Neustart von FHEM auf, da das Geräte zur Anwesenheitserkennung dient.
Grüße
Andreas
Hi Andreas,
Ich kann mir soetwas vorstellen, wenn der client gerade das Netz verlässt, wenn fhem runtergefahren ist. Muss ich mir morgen mal ansehen.
Mit clear clientData kann man solche Schiefstände bereinigen.
Edit: Korrigiere: Nur durch clear clientData können solche Schiefstände entstehen, wenn man anschließend kein clear readings aufruft. Sonst sind intern alle Daten über die clients gelöscht, aber verbleiben in den Readings.
Gruß,
Dirk
Hallo zusammen,
vor einiger Zeit hatte ich das Modul für mich weiterentwickelt und um einige Funktionen erweitert. Davon sind mittlerweile fast alle in der offiziellen Version enthalten, außer der Funktion updateClient <mac>. Damit kann man einzelne clients öfter updaten (aus einem at aufgerufen) und somit das update Interval recht lang setzen, sofern man nur für wenige clients eine PRESENCE-Überwachung haben möchte und FHEM mit Unifi auf einem RasPi laufen hat, der dann an seine Ressourcengrenzen stößt.
Habe diese Funktion jetzt aus meinen alten Sourcen kopiert, da ich in einem anderen Thread das Gefühl hatte, dass manche dies als Script selbst implementiert haben.
Bei Bedarf mal die Version im Anhang vertesten und mir Feedback geben, ob sie so in die offizielle Version übernommen werden soll.
Viele Grüße,
Dirk
Zitat von: Wuehler am 10 März 2018, 13:56:38
Hi Andreas,
Ich kann mir soetwas vorstellen, wenn der client gerade das Netz verlässt, wenn fhem runtergefahren ist. Muss ich mir morgen mal ansehen.
Mit clear clientData kann man solche Schiefstände bereinigen.
Edit: Korrigiere: Nur durch clear clientData können solche Schiefstände entstehen, wenn man anschließend kein clear readings aufruft. Sonst sind intern alle Daten über die clients gelöscht, aber verbleiben in den Readings.
Gruß,
Dirk
Hi Dirk,
also ich glaube das Problem ist zumindest bei mir nicht dadurch entstanden, dass der Client das Netz verlassen hat während FHEM nicht läuft. Wie gesagt verwende ich dein Modul zur Anwesenheitssteuerung und erst seit 1-2 Tagen ist mir aufgefallen das eine Person zuviel gemeldet wird ;-) Vielleicht täusche ich mich aber auch, da ich aktuell leider auch keine Jabber Meldungen mehr bekomme (noch so eine Baustelle), wenn keiner mehr zu Hause ist. Sonst könnte ich das besser im Jabber Protokoll nachvollziehen.
Grüße,
Andreas
Neue Version ab morgen im Update.
Neue Features:
1. Account wird encryptet (neuer getter showAccount)
2. neuer setter: updateClient <mac> zum aktualisieren eines einzelnen clients. Übergeben werden muss die MAC-Adresse des clients.
Hallo zusammen,
Ich brauche mal eure Unterstützung. In der Unifi-Community habe ich eine Idee gepostet. https://community.ubnt.com/t5/UniFi-Feature-Requests/Notifications-Call-URL-instead-of-sending-Mails/idi-p/2276503 (https://community.ubnt.com/t5/UniFi-Feature-Requests/Notifications-Call-URL-instead-of-sending-Mails/idi-p/2276503)
Wenn sie das umsetzen kann man das Unifi-Modul umbauen, so dass nicht nach einem Intervall die Informationen vom Controller abgefragt werden sondern fhem bei jedem event angetriggert wird. Man bekommt das Ereignis (zB einen Client-connect) also sofort in fhem mit.
Wäre gut, wenn es ein paar ,,Daumen hoch" an meinem Festure-Request gibt.
Danke schonmal,
Dirk
Schon 10 Daumen hoch beim FeatureRequest. :)
Bin gespannt ob mal einer von Unifi einen Kommentar hinterlässt. Wäre gut wenn noch ein paar Unterstützer einen Kudo hinterlassen.
Klasse Modul, danke Dir(Euch) dafür!
Hab dir bei ubnt den Daumen hoch für deinen Request gegeben @Wuehler (auch wenn ich selber noch auf NAT per klickibunti im USG abschalten warte (habs per console gemacht)).
Kleine (mglw. blöde) frage am rande...
Ich hatte vorgestern das Phänomen das mein Fritzbox-Modul plötzlich alle Readings (anscheinend als Text) aus dem USG bekommen hat.
Jedenfalls stand das, was das USG meldet im fhem-Log und in den Readings des FB-Moduls.
Konnte damit natürlich nix anfangen, das arme Modul....
Hast Du da irgendwas dran geschraubt oder sollte ich lieber im FritzBox-Thread nachfragen ?
Das USG(3) macht schon länger kein NAT mehr... lief lange problemlos, vorher auch mit doppeltem NAT.
Updates mache ich schon quasi nicht mehr selber, dafür hab ich Webmin (täglich, Jessie, stable), der Controller selber läuft auf der selben Hardware und ist performant auch wenn fhem hängt.
Das Problem liegt also mMn ganz klar an/in fhem (CPU geht auf 100% für den thread und... ja www... welt weites warten)
Hat meinen armen kleinen Pi3 dermaßen gestresst das ich Antwortzeiten bis 2 Minuten hatte... WAF voll im Eimer :D
Da ich einen schnellen workaround brauchte hab ich zuerst unify UND fritzbox "rausgeschmissen", nochmal geupdated und jetzt nur unifi am laufen... aus "angst" das es wieder hängt...
Der FB_Callmonitor hat und hatte keine Probleme...
Am load kanns doch nich liegen, oder? Ich hab nen 16er poe switch, nen 8er, 2 AP Pro das USG(3) und den Controller aufm Pi . Ist mMn nich das meisste... (28-61 Clients)
Ne Idee ?
lg
Björn
Moin Björn,
Am 12.03.war das letzte Update des Unifi-Moduls von mir. Zumindest an einem Update dieses Moduls sollte es nicht liegen. Leider kann ich mir nicht vorstellen, was da genau in welchen Logs und Readings stand.
Es ist aber schon so, dass FHEM und der Unifi-Controller auf demselben PI läuft es zu Performanceproblemen kommen kann. Eine Folge könnte das Chaos sein. Ich habe mir auch einen zweiten PI zugelegt um das zu beheben.
Vielen Dank für den Daumen hoch. Vielleicht kann der ein oder andere ja noch einen vergeben, der FeatureRequest rutscht langsam etwas tiefer auf der ,Hot'-Seite.
Viele Grüße,
Dirk
Zitat
2018.04.18 11:53:12 3: WARNING: unsupported character in reading -WLAN_$@_Guest_state (not A-Za-z/\d_\.-), notify the Unifi module maintainer.
2018.04.18 11:53:12 3: WARNING: unsupported character in reading -WLAN_$@_state (not A-Za-z/\d_\.-), notify the Unifi module maintainer.
:)
Hi,
Schaue ich mir am Wochenende mal an. Wie lautet die zugehörige WLAN-SSID?
Zitat von: Wuehler am 18 April 2018, 12:23:07
Hi,
Schaue ich mir am Wochenende mal an. Wie lautet die zugehörige WLAN-SSID?
$abc@ und $abc@_Guest :)
Wäre es OK, wenn die Readings dann WLAN__abc_ heissen? Ansonsten musst du dein WLAN umbenennen.
Zitat von: Wuehler am 18 April 2018, 13:43:15
Wäre es OK, wenn die Readings dann WLAN__abc_ heissen? Ansonsten musst du dein WLAN umbenennen.
Da ich mein WLAN eigentlich nicht unbedingt umbenennen möchte, gerne das Reading ohne Umlaute :)
Gruss und danke
Hallo Leute!
Ich bin seit ein paar Wochen zum FHEM Server gekommen und bin total begeistert.
Habe gestern auch die Verbindung zum Unifi Controller hergestellt.
Funktioniert super.
Eine Kleinigkeit ist mir aufgefallen, die lässt sich aber leicht ausbessern.
in der 74_Unifi.pm ist ein Tippfehler drinnen.
auf Zeile 367 steht:
} elsif( $setVal3 eq 'restsart' ) {
wenn ich restsart gegen restart ausbessere funktioniert der Befehl ganz normal.
blöderweise wird bei jedem Update die Datei wieder mit der fehlerhaften Zeile überschrieben.
wär super, wenn das ausgebessert werden könnte.
das Modul ist sonst echt cool.
ich verwende es um bei mir im Haus AccessPoints und andere PoE Geräte durch einen Taster am KNX BUS ein-/auszuschalten
lg
Andreas
Hi Andreas und willkommen im Forum.
Danke für die Fehleranalyse. Da ich unterwegs bin komme ich erst am Wochenende dazu, den Fix hochzuladen.
Viele Grüße,
Dirk
@Andreas: Morgen im Update der Fix des restart-typos.
@hauswart: Bitte vorher mal ein Update machen. Das fehlerhafte WLAN-Reading ist seit Januar gefixt.
Dirk
Zitat von: Wuehler am 20 April 2018, 21:20:02
@Andreas: Morgen im Update der Fix des restart-typos.
@hauswart: Bitte vorher mal ein Update machen. Das fehlerhafte WLAN-Reading ist seit Januar gefixt.
Dirk
Ich habe folgende Version aktiv:
74_Unifi.pm 16638 2018-04-20 19:15:38Z wuehler
Ich sehe gerade die Readings sind doppelt da, einmal mit den Umlauten (Datum vom Januar) und einmal ohne Umlaute (aktuelles Datum). Ich lösche die Readings mit Umlauten mal von Hand, dann wird der Fehler weg sein.
Gruss und danke
Hi,
du kannst auch einfach über den set Befehl alle Reading löschen, mit dem nächsten Update werden diese wieder erzeugt.
Grüße Christian
Das Modul ruft nach Hilfe:
2018.04.23 14:08:26 3: WARNING: unsupported character in reading -AP_f0:9f:c2:f3:e7:45_clients (not A-Za-z/\d_\.-), notify the Unifi module maintainer.
2018.04.23 14:08:26 3: WARNING: unsupported character in reading -AP_f0:9f:c2:f3:e7:45_essid (not A-Za-z/\d_\.-), notify the Unifi module maintainer.
2018.04.23 14:08:26 3: WARNING: unsupported character in reading -AP_f0:9f:c2:f3:e7:45_locate (not A-Za-z/\d_\.-), notify the Unifi module maintainer.
2018.04.23 14:08:26 3: WARNING: unsupported character in reading -AP_f0:9f:c2:f3:e7:45_state (not A-Za-z/\d_\.-), notify the Unifi module maintainer.
2018.04.23 14:08:26 3: WARNING: unsupported character in reading -AP_f0:9f:c2:f3:e7:45_utilizationNA (not A-Za-z/\d_\.-), notify the Unifi module maintainer.
2018.04.23 14:08:26 3: WARNING: unsupported character in reading -AP_f0:9f:c2:f3:e7:45_utilizationNG (not A-Za-z/\d_\.-), notify the Unifi module maintainer.
Jemand eine Idee, was es sein könnte?
Gib den AP im Unifi-Controller mal einen Namen. Und einmal ,,set Unifi clear readings" aufrufen.
4 weg, 2 neue:
2018.04.23 19:10:25 2: Unifi_APC_AC_LR: deprecated use of Attribute 'deprecatedClientNames' (see commandref for details).
2018.04.23 19:10:34 2: Unifi_APC_AC_LR: deprecated use of Attribute 'deprecatedClientNames' (see commandref for details).
siehe commandref ;)
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/or attribute is not set)
Ein freundlicher Hinweis im Log, dass sich die Readingnamen der clients evtl. (bald) ändern. Mit dem o.g. Attribut kann man das Verhalten steuern und den zukünftigen Standard schonmal herstellen.
ich habe gerade bemerkt das der neue beta controller 5.9.x die cookies anders formatiert möchte.
beim debugger habe ich folgendes bemerkt:
bisher sendet das modul die cookies in genau so vielen zeilen zurück wie es Set-Cookie zeilen in der login antwort gibt. das funktioniert mit dem neuesten beta controller nicht mehr. er möchte eine einzige cookie zeile im header in der alle cookies mit ; getrennt sind. ich meine das ist überhaupt die korrekte variante.
weiterhin ist mir aufgefallen das im modul aktuell die \r\n beim zusammen bauen des header strings in einfache anführungszeichen eingeschlossen sind. das bedeutet das sie nicht als sonderzeichen interpretiert werden sondern als vier einzelne zeichen geschickt werden. ich meine das ist falsch und eher zufall das dies überhaupt geht.
ich habe aktuell den code zum setzen des cookies (zeile 792 folgende) so umgebaut: Log3 $name, 5, "$name ($self) - state=ok || version=3";
#$hash->{httpParams}->{header} = '';
$hash->{httpParams}->{header} = 'Cookie:';
for (split("\r\n",$param->{httpheader})) {
if(/^Set-Cookie/) {
s/Set-Cookie:\s(.*?);.*/Cookie: $1/;
#$hash->{httpParams}->{header} .= $_.'\r\n';
$hash->{httpParams}->{header} .= ' '.$1.';';
}
}
damit scheint erst mal wieder alles zu gehen. ich weiss nicht ob das so auch mit älteren controller versionen funktioniert. die api version ist immer noch 4 und man kann darüber keine unterscheidung machen.
ps: wenn man das header element für den httputils call nicht als string sondern als hash übergibt kümmert sich httputils übrigens selber um das erzeugen der zeilenenden. das macht den eigenen code übersichtlicher.
Moin,
Danke schonmal für die Analyse und den patch.
Schaue ich mir zeitnah (bin am Wochenende unterwegs) an und passe das Modul dann im Repository an.
Bin nun auf 5.9.4 und selbst mit dem Patch von justme1968 bekomme ich keine Daten mehr?
Moin,
habe bei mir nicht die beta installiert. Der patch funktioniert nicht mit meiner alten Controllerversion. Im Anhang eine Mischung beider Versionen. Diese funktioniert mit dem Unifi-Controller 5.7.20.
Könnt ihr die mal mit der beta-Version checken?!
Sehr schön, geht wieder alles, vielen Dank!
FYI ich nutze die 5.9.4 Controller Version
Sehr schön. Wäre gut wenn es noch weitere Tester gibt. Ist eine zentrale Stelle des Moduls und wäre ärgerlich, wenn es dann bei einigen nach einem Update nicht mehr funktioniert.
Wenns bei euch geht reicht auch ein ,,gefällt mir" am Beitrag mit dem Anhang.
Edit: merke gerade, dass die beim Test genutzte Controller-Version doch interessant wäre.
Die angehängte Version läuft bei mir mit Unify 5.8.14 und nach dem Update nun auch mit 5.9.4-11019, bisher ohne Probleme ;)
Ronny
Eine Frage zum Reading _snr der einzelnen WLan-Geräte:
Soll das die Signalstärke sein? Falls ja, welche Einheit hat das?
Aktuell in FHEM angzeigt: xxx_snr 38
In der UniFi-Software: Signal 81% (-57 dBm)
Werde einfach nicht schlau draus.
Grüße
Jörg
So viel ich weiß ist bei unifi snr= dBm+95 (um das Problem zu lösen, dass -90 auf den ersten Blick besser aussieht als -60).
Mehr unter//https://community.ubnt.com/t5/UniFi-Wireless/Minimum-RSSI/td-p/1063633
Zitat von: Wuehler am 07 Mai 2018, 22:06:58
Moin,
habe bei mir nicht die beta installiert. Der patch funktioniert nicht mit meiner alten Controllerversion. Im Anhang eine Mischung beider Versionen. Diese funktioniert mit dem Unifi-Controller 5.7.20.
Könnt ihr die mal mit der beta-Version checken?!
Diese Version funktioniert bei mir mit der Beta 5.9.4
Vielen Dank!
Zitat von: Wuehler am 07 Mai 2018, 22:06:58
Könnt ihr die mal mit der beta-Version checken?!
Beta 5.9.4 läuft, danke dir
Die Version wir aber über Update noch nicht verteilt, oder?
Habe die Version jetzt eingechecked. Morgen dann im Update.
sorry. komme eben erst dazu noch mal zu schauen.
auch wenn die aktuelle version jetzt funktioniert: ich glaube da stimmt immer noch etwas nicht und es ist mehr oder weniger zufall.
wenn ich das richtig sehe wird aktuell eine zeile aufgebaut die so ausschaut:Cookie: <name1>=<wert1>;\r\nCookie: <name2>=<wert2>;\r\n
es müsste aber so ausschauen:Cookie: <name1>=<wert1>; <name2>=<wert2>;
d.h. alles auf einer zeile, die einzelnen werte mit ; getrennt, nur ein mal das Cookie schlüsselwort am anfang, ohne \r\n dazwischen.
das bei dieser version zufällig nur eine zeile raus kommt statt mehrere liegt daran das die \r\n in einfachen anführungszeichen stehen statt in doppelten und dadurch nicht zwei steuerzeichen geschrieben werden sondern vier einfache zeichen.
ich hoffe es ist klar was ich meine. noch mal sorry das ich gerade nicht selber genauer schauen kann.
Habe ich nur irgendwas übersehen oder ist es nicht möglich den PoE-Verbrauch eines einzelnen Switchports auszulesen? Habe nur den Gesamtverbrauch eines Switches gefunden.
Zitat von: roedert am 11 Mai 2018, 10:41:16
Habe ich nur irgendwas übersehen oder ist es nicht möglich den PoE-Verbrauch eines einzelnen Switchports auszulesen? Habe nur den Gesamtverbrauch eines Switches gefunden.
Ja, das ist bisher so
ok, danke.
Vielleicht ist das ja noch ein "Denkanstoß" für die Zukunft - die UniFi-Gui gibt diese Infos ja her.
Hintergrund:
Hab eine Aussenkamera die bei Dämmerung auf s/w und IR-Beleuchtung umschaltet wodurch der Stromverbrauch steigt. Darüber könnte ich in FHEM prima erkennen wenns draussen dunkel wird.
Ja, die Diskussion gab es hier schon mal. Aber da kam als Ergebnis raus, das es dann pro unifi Controller sub-devices geben muss, je Switch eins zum Beispiel. Das ist natürlich mehr Arbeit und bisher gab es da nicht so viel Interesse.
Schau mal Post #353
Moin,
@justme:
Zitatd.h. alles auf einer zeile, die einzelnen werte mit ; getrennt, nur ein mal das Cookie schlüsselwort am anfang, ohne \r\n dazwischen.
so wie ich die Unifi-Schnittstelle verstanden habe werden insgesamt zwei Cookies gesetzt:
1. unifise: (oder so ähnlich, kann gerade nicht nachsehen) - eine Session-ID
2. csrf: ein Token gegen cross-site-request-forgery
Beim ersten Cookie kommen glaube ich auch noch andere name-Wert-Paare mit, die allerdings ignoriert werden.
Der ganz richtige Output müsste also folgendermaßen lauten:
Cookie: unifise=<die Session-ID>;
Cookie: csrf=<das csrf-Token>;
In der alten Version fehlte das Wort Cookie sowie das Semikolon nach einem Wert.
VG,
Dirk
ich meine das Cookie: schlüsselwort sollte nur ein mal am anfang der zeile auftauchen und danach dir name/wert paare mit semikolon getrennt. das wäre dann die syntax wie sie auch für alle anderen header elemente gilt.
das kann man z.b. mit wget auch auf der kommandozeile testen.
schau mal im rfc oder hier: https://de.wikipedia.org/wiki/HTTP-Cookie unter aufbau.
ja. die beiden cookie werte sind zumindest aktuell die einzig relevanten. es gibt zwar scheinbar noch einen dritten, der scheint aber nicht weiter wichtig zu sein.
Moin roedert,
ZitatVielleicht ist das ja noch ein "Denkanstoß" für die Zukunft - die UniFi-Gui gibt diese Infos ja her.
Ich hatte eh mal vor mich mit dem Thema zweistufiges Modul auseinanderzusetzen, hatte persönlich zu Hause bisher allerdings keinen case. Mittlerweile habe ich einen Unifi-Switch, da ein altes Billigding nach 13 Jahren den Geist aufgegeben hat (endlich ein Grund ;) ). Mal schauen wir kompliziert das wird und ob die (auf den ersten Blick gute) Doku im Wiki für mich verständlich ist.
Idee für die erste Stufe wäre, nur die Daten des Switch anzuzeigen, aber nichts schalten zu können. Dann müsste eine Erweiterung um ein paar Kleinigkeiten sowie die dispatch()-Funktion ausreichen (plus neues Modul 74_UnifiSwitch.pm).
Mal sehen wann ich dazu komme. Brauche dann auf jedenfall Tester ;-)
VG,
Dirk
@justme: Es werden zwei Cookies gesetzt, nicht einer mit zwei Werten.
ja. beim setzen. beim zurück geben hat das bei meinen tests aber nicht funktioniert. die beiden gesetzten mussten in der antworte zu einer einzigen antwortet zeile zusammengefasst werden.
Zitat von: roedert am 11 Mai 2018, 10:41:16
Habe ich nur irgendwas übersehen oder ist es nicht möglich den PoE-Verbrauch eines einzelnen Switchports auszulesen? Habe nur den Gesamtverbrauch eines Switches gefunden.
Also ich kann das auslesen, sowohl im Controller als auch in FHEM:
TK.KG.USW (mac:78:8a:20:fa:91:29, id:5ae06bae5147cd3be019de77)
id name on mode class
1 Port 1 7 1 auto good Class 4 3.33W 53.27V 62.49mA
2 Port 2 7 0 auto Unknown 0.00W 0.00V 0.00mA
3 Port 3 7 0 auto Unknown 0.00W 0.00V 0.00mA
4 Port 4 7 1 auto good Class 4 9.06W 53.27V 170.16mA
5 Port 5 7 0 auto Unknown 0.00W 0.00V 0.00mA
6 Port 6 7 0 auto Unknown 0.00W 0.00V 0.00mA
7 Port 7 7 0 auto Unknown 0.00W 0.00V 0.00mA
8 Wohnzimmer 7 1 auto good Class 4 9.61W 53.14V 180.78mA
9 Port 9 7 0 auto Unknown 0.00W 0.00V 0.00mA
Oder was genau meinst Du?
Zitat von: sledge am 11 Mai 2018, 16:46:54
Also ich kann das auslesen, sowohl im Controller als auch in FHEM:
TK.KG.USW (mac:78:8a:20:fa:91:29, id:5ae06bae5147cd3be019de77)
id name on mode class
1 Port 1 7 1 auto good Class 4 3.33W 53.27V 62.49mA
2 Port 2 7 0 auto Unknown 0.00W 0.00V 0.00mA
3 Port 3 7 0 auto Unknown 0.00W 0.00V 0.00mA
4 Port 4 7 1 auto good Class 4 9.06W 53.27V 170.16mA
5 Port 5 7 0 auto Unknown 0.00W 0.00V 0.00mA
6 Port 6 7 0 auto Unknown 0.00W 0.00V 0.00mA
7 Port 7 7 0 auto Unknown 0.00W 0.00V 0.00mA
8 Wohnzimmer 7 1 auto good Class 4 9.61W 53.14V 180.78mA
9 Port 9 7 0 auto Unknown 0.00W 0.00V 0.00mA
Oder was genau meinst Du?
Klar, im Controller geht das. Das FHEM Modul liefert diese Info aber nur auf device Ebene, nicht auf Port Ebene.
Yep - wie im Controller eben auch nur auf Device-Ebene.
Und - mir reicht sogar die Gesamtzahl, da ich damit dann bzgl. der USV rechnen kann... Aber generell geht es - den Output müsste man jetzt noch parsen...
Der Output ist ja von FHEM, nicht vom Controller.
Nabend,
mich hat der Ehrgeiz dann doch gepackt. Näheres unter https://forum.fhem.de/index.php/topic,87728.0.html (https://forum.fhem.de/index.php/topic,87728.0.html).
VG,
Dirk
@Sledge und Christian: Habt ihr das Modul hinter dem Link ausprobiert? Funktioniert es bei euch?
Zitat von: Wuehler am 12 Mai 2018, 21:03:27
@Sledge und Christian: Habt ihr das Modul hinter dem Link ausprobiert? Funktioniert es bei euch?
yep, antwort ist gerade gekommen, zeit ist bei mir momentan leider etwas knapp, aber ich bleibe dran und bin froh über die entwicklungen
Ich muss nochmal auf das Blocken und Entblocken von Clients zurückkommen. Das funktioniert ja mit dem Modul mittlerweile gut. Was ich immer noch über ein externes Skript mache, das dann per API-Zugriff den Unifi Controller abfragt, ist zu ermitteln, ob ein Client aktuell geblockt ist oder nicht.
Denn ein Reading dafür kann ich in Unifi nicht finden. Das Reading mit dem Namen des Clients wird nur zu "disconnected", wenn der Client geblockt ist. Und interessanterweise gibt ein get unifi clientData <client>
auch bei einem geblockted Client blocked = 0
zurück.
Ist das so nach wie vor beabsichtigt?
Danke, Christian
Hi Christian,
das Problem ist (weiterhin?), dass die aktuell verwendete Unifi-API geblockte clients nicht mitsendet. Daher bekommt man nie blocked=true. Erst wenn sich der client wieder connected wird blocked=false mitgesendet.
Man könnte ein Reading einführen, dass ausschließlich beim "set Unifi blockClient <client>" auf true gesetzt wird. Sobald der client per update mitkommt wird es wieder auf false gesetzt.
Dies könnte zu inkonsitenten Zuständen führen, wenn man direkt über die Oberfläche des UnifiController den Client blockt. Daher sollte das Reading evtl. eher "maybe_blocked" heißen.
Gruß,
Dirk
Danke, Dirk. Das ist schade, aber das zusätzliche Reading würde ich dann tatsächlich nicht umsetzen. Denn mit "maybe" hat ja niemand was gewonnen.
Solange man die clients nur über fhem blockiert stimmt das reading.
Hallo,
Ich habe mein Netzwerk auf Unifi umgebaut, ich bin damit sehr zufrieden :)
Ich habe probiert mit FHEM meine POE Ports an und aus zu schalten mit set <name> poeMode.
Ich habe zwei Instanzen von FHEM, mein altes x64 NUC mit Ubuntu 16.04 wird bald abgeschaltet, und mein neues Ubuntu 18.04 System, auch x64.
Mit dem alten Ubuntu 16.04 klappt set poeMode einwandfrei :) aber mit dem neuen Ubuntu 18.04 stürzt FHEM ab, und das poeMode wird nicht geändert.
Muss ich etwas installieren, JSON habe ich natürlich schon installiert. Könnte es ein Problem mit Ubuntu 18.04 sein?
Danke sehr
Gibt es denn Einträge im Log?
ja, folgendes:
2018.05.23 10:19:33 2: unifi: deprecated use of Attribute 'deprecatedClientNames' (see commandref for details).
Undefined subroutine &main::encode_json called at ./FHEM/74_Unifi.pm line 1737.
ich habe die letzten updates installiert in FHEM installiert, und apt-get update && apt-get upgrade gemacht
Zitat von: okenny am 23 Mai 2018, 10:24:51
ja, folgendes:
2018.05.23 10:19:33 2: unifi: deprecated use of Attribute 'deprecatedClientNames' (see commandref for details).
Undefined subroutine &main::encode_json called at ./FHEM/74_Unifi.pm line 1737.
ich habe die letzten updates installiert in FHEM installiert, und apt-get update && apt-get upgrade gemacht
Gegen die DeprecatedClientNames gibt es etwas:
Zitat von: Wuehler am 23 April 2018, 21:19:03
siehe commandref ;)
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/or attribute is not set)
Ein freundlicher Hinweis im Log, dass sich die Readingnamen der clients evtl. (bald) ändern. Mit dem o.g. Attribut kann man das Verhalten steuern und den zukünftigen Standard schonmal herstellen.
ok, aber versteh ich aber nicht.
Ich habe attr deprecatedClientNames 0 und 1 probiert, beide mit dem selben Ergebnis (Abstürz)
Mit dem alten Ubuntu 16.04 FHEM System funktioniert das set poeMode fc:ec:da:47:fc:d1 6 off einwandfrei, auch mit dem Default attr deprecatedClientNames
Zitat von: okenny am 23 Mai 2018, 10:24:51
Undefined subroutine &main::encode_json called at ./FHEM/74_Unifi.pm line 1737.
Das scheint mir eher das Problem zu sein. Das andere ist nur ein Hinweis.
Der alte Rechner scheint libjson-perl Version 2.9-1 zu haben, der neue Rechner hat 2.97001-1.
könnte das der Grund sein?
Hi,
Bin gerade nicht am Rechner, daher nur unspezifische Hilfe. Aktuell baue ich das Modul ein wenig um. Und da du gerade poe schalten möchtest wäre es denke ich sinnvoll, dass du die neue Version nutzt.
Siehe: https://forum.fhem.de/index.php/topic,87728.0.html (https://forum.fhem.de/index.php/topic,87728.0.html)
Dort gab es dasselbe Problem bei einem Tester. In Post 7 steht, wie das Problem gelöst werden kann.
Wusste nicht, dass es auch bei dem aktuellen Unifi-Modul passiert. Liegt evtl. an einer neueren perl Version.
VG,
Dirk
sehr schön, das geht. Danke
use JSON qw(encode_json);
Damit kann ich meine POE Verbrauchen schön schalten.
Das neue Modul werde ich auch probieren.
Hallo,
Heute schon ein neues 74_Unifi.pm? Was ist damit neu?
update check
macht
List of new / modified files since last update:
UPD ./CHANGED
UPD FHEM/36_WMBUS.pm
UPD FHEM/74_Unifi.pm
UPD FHEM/lib/fhem_zwave_deviceconfig.xml.gz
UPD FHEM/lib/openzwave_manufacturer_specific.xml
Moin,
Die letzte Änderung ist vom 10.05. eine Anpassung an den Cookies wegen der neuesten Unifi-Controller-Beta-Version.
VG,
Dirk
Heute wollte ich das PRESENCE-Modul dazu verwenden, um via UNIFI-Status die Anwesenheit einzelner Personen zu validieren - habe ich bisher "anders" gemacht.
Dazu wie im Wiki für das entsprechende Device auf connected / disconnected geprüft. Der Test auf "connected" hat auch sofort funktioniert. Dann WLAN beim Handy ausgeschaltet - nach wenigen Minuten verschwindet es im Controller, auch die Readings in FHEM ändern sich - bis auf connected. Das bleibt stehen.
android-8807d9f0cff0f861
connected
2018-05-24 19:52:16
android-8807d9f0cff0f861_accesspoint
unknown
2018-05-24 19:52:16
android-8807d9f0cff0f861_essid
UNDEFINED
2018-05-24 19:52:16
android-8807d9f0cff0f861_hostname
android-8807d9f0cff0f861
2018-05-24 19:52:16
android-8807d9f0cff0f861_last_seen
2018-05-24 19:52:16
2018-05-24 19:52:16
android-8807d9f0cff0f861_snr
59
2018-05-24 19:43:24
android-8807d9f0cff0f861_uptime
7639
Man sieht, die ESSID geht auf UNDEFINED, der accespoint steht auf unknown - aber der Status immer noch auf "connected".
Auch ein get <device> clientData hat nicht geholfen.
Klemmt nur bei mir was oder ist liegt es ggfs am Controller?
Version des Controllers: 5.7.23
Hinweise jederzeit gerne...
Gruß,
Tom
Hi,
Ist das reproduzierbar? Kannst du mal verbose =3 setzen und das Log dazu anhängen.
Ich habe noch Controller 5.7.20. kann das Verhalten jemand mit 5.7.23 bestätigen?
Morgen im Update der fix für das fehlende encode_json. Bei neueren libs führte dies zu einem Absturz von fhem.
Ausserdem ist das neue Modul UnifiSwitch https://forum.fhem.de/index.php/topic,87728.0.html (https://forum.fhem.de/index.php/topic,87728.0.html) soweit fertig. Jetzt auch mit setzen des poeMode direkt am Switch. Bitte mal ausprobieren.
Zitat von: Wuehler am 24 Mai 2018, 21:05:49
Hi,
Ist das reproduzierbar? Kannst du mal verbose =3 setzen und das Log dazu anhängen.
Ich habe noch Controller 5.7.20. kann das Verhalten jemand mit 5.7.23 bestätigen?
Hmmm - habe ich gerade gemacht - das Logfile brauche ich aber nicht dranhängen, weil da nichts drinsteht. Hatte global verbose auf 3, unificontroller auf 4. Es steht nur eine infomessage bzgl. Voucher drin - aber keine Infos bzgl. state eines Clients.
Davon abgesehen habe ich mich dazu entschieden, auf den Inhalt der SSID zu prüfen - beim Zugriff via VPN ist mir nämlich letztens meine Anwesenheitskontrolle aus dem Takt geraten, da für Unifi die Devices dann zwar connected sind - aber SSID bleibt weiterhin auf "UNDEFINED". Und da ich gelegentlich mit dem Handy via VPN zugreife, halte ich die Lösung für SSID für mich für "besser".
Unabhängig davon werde ich kommende Tage nochmal auf die jeweils neueste Version gehen (unificontroller / unifiswitch) und dann einen neuen Versuch wagen.
Gruß, Tom
Hi,
Das Unifi-Modul redet im Log erst ab verbose 3.
Dann kann ich verfolgen, was in welcher Reihenfolge passiert.
Falls Unterstützung notwendig nochmal Log erzeugen bitte.
VG,
Dirk
Hi Dirk - zur Abwechselung mal ein anderes Problemchen beim Block von Clients über das Modul:
2018.05.30 09:33:11 3: set unifi blockClient ASUS_Zenbook : unifi: Unknown client 'ASUS_Zenbook' in command 'blockClient', choose one of: all,memopad,iPad_Pro,sonykdl-32w705c,CvB-MBPro-7,iPhone-X,raspberrypi,iPhone_SE,harmonyhub-wohn,harmonyhub-gast
Das ist schade. Ein list auf unifi (stark gekürzt):
Internals:
DEF 192.168.1.106 8443 crypt:2e045c0859 crypt:330b5803590150347c722c
NAME unifi
NOTIFYDEV global
NR 914
NTFY_ORDER 50-unifi
STATE connected
TYPE Unifi
READINGS:
[...]
2018-05-28 23:18:53 ASUS_Zenbook disconnected
2018-05-28 23:18:39 ASUS_Zenbook_accesspoint Wohnzimmer
2018-05-28 23:18:39 ASUS_Zenbook_essid TESTTEST
2018-05-28 23:18:39 ASUS_Zenbook_hostname DESKTOP-1FQI71D
2018-05-28 23:18:39 ASUS_Zenbook_last_seen 2018-05-28 23:13:25
2018-05-28 23:18:39 ASUS_Zenbook_snr 40
2018-05-28 23:18:39 ASUS_Zenbook_uptime 421
[...]
Ja, das Gerät dürfte sich nicht in der Liste der in den letzten 24 Stunden gesehenen Geräte befinden. Aber blocken kann man es grundsätzlich schon. Was muss ich denn machen, damit das mit dem Modul mit allen dem Controller bekannten Geräten funktioniert?
Danke, Christian
Hi,
Als schnellen Workaround kommentiere die Zeile im Modul aus, in der die Prüfung stattfindet. Könnte evtl. ausreichen.
VG,
Dirk
Als Quickfix half ein Einschalten des Geräts gefolgt von einem Neustart von fhem. Dann kannte unifi das Gerät wieder.
Ich habe das allerdings mal mit einem anderen Gerät getestet, das schon länger offline war.
2018.05.30 10:58:51 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/74_Unifi.pm line 1441.
Geblockt wird es nicht.
Mal eine andere Frage dazu: Wie ist eigentlich der Automatisierungs-UseCase? Einfach nur die Oberfläche von Unifi durch FHEM abzulösen wird immer wieder zu Problemen führen.
Ich habe kein Interesse an einer Ablösung der Oberfläche. Hier geht es eher darum, event- oder zeitbezogen den Zugang einzelner Geräte zu blockieren, so dass z.B. die Kinder nicht dauernd an irgendwelchen Geräten im Internet hängen.
Da wird z.B. für diverse (Eltern-)Geräte einfach der Netzzugang geblockt, wenn die Eltern aus dem Haus sind. Die Kleinen sind ja ansonsten recht findig, wenn es darum geht, Youtube & co. gucken zu können, das Zeitkontingent am eigenen Gerät aber aufgebraucht ist.
Außerdem wird zu bestimmten Zeiten (abhängig von Schultag/Wochenende/Feiertag/Ferien - kennt fhem ja alles) der Netzzugang für Kindergeräte zu unterschiedlichen Zeiten für die Nächte unterbrochen.
Hallo,
ich nehme mal an du sprichst vom ganzen Modul!
Denke es macht keinen Sinn die Unifi Oberfläche Abzulösen. Ich habe 4 Switches, 3 AP's im Einsatz und meine UseCases sind:
- Guest Network an/aus und vouchers verteilen
- Anwesenheit über Handy im Wlan
- AP's nachts in bestimmten Bereichen ausschalten
- Neustart von Poe devices
- Status von Wlan Geräten erfassen (z.B. Laptop an/aus)
- Zeitliches blockieren von Geräten
- updates der Unifi Geräte zu einer bestimmten Zeit und Reichenfolge
- Netzwerktraffic erfassen
Mehr fällt mir momentan nicht ein.
Gruß
Eisix
Danke euch. Kann ich mir jetzt besser vorstellen was ihr macht und dadurch besser schauen wie man ed umsetzt. ;)
Muss mal schauen wie man das umsetzen kann. Aber dsnn auf Basis des Moduls mit UnifiSwitch.
@Christian: Habe jetzt nochmal in den Code schauen können. Ist das Problem bei dir reproduzierbar? Das kann so eigentlich nur auftreten (wenn ich das auf die Schnelle richtig verstanden habe) wenn du zwischndurch mal clear clientData aufgerufen hast. Dann bleiben die Readings. Die eigentlichen Daten liegen aber intern. Taucht das zenbook nochmal uinter den internals auf?
Gruß,
Dirk
Hi Dirk, clear clientData habe ich schon lange nicht mehr aufgerufen. Ich habe aber mal nachgeforscht. Das Problem scheint zu sein, dass 2 der zu blockenden Geräte im Controller nicht unter "Clients", sondern (nur?) unter Insights als "Known Clients" aufgeführt sind. Das passiert wohl, wenn sie gerade nicht/schon länger (Stundenbereich) nicht mehr im WLAN angemeldet waren.
74_Unifi scheint auf die Liste der (verbundenen) Clients zuzugreifen, nicht die der known clients. Entsprechend taucht das Zenbook (wie auch ein anderes Gerät) auch aktuell zwar in den Readings auf, beim List aber nicht in dem "clients:" Abschnitt. Das ist insofern deckungsgleich mit dem Controller: Dort tauchen die beiden Geräte auch nicht unter "Clients" auf, aber unter "insights" als "known clients" (wo man sie ja auch block etc. kann).
Mein "list unifi" produziert übrigens 4114 Zeilen. Davon 2999 Hashes unter "events" (vermutlich wegen der vielen auch im Controller gespeicherten Events). Das macht ein Posten des kompletten Lists etwas unhandlich. Aber ich kopiere gerne raus, was Du brauchst.
Grüße, Christian
Hi Christian,
Falls sich kein anderer Weg findet kann ich einnen neuen setter einbauen:
set Unifi blockClientByMac <mac>
Gleiches zum Unblock natürlich auch.
Das müsste die Unifi-API hergeben und deine Automatisierungsidee ermöglichen.
VG,
Dirk
Ja, über die MACs funktioniert das auch mit der php-API, die ich für meine Skripte nutze, sowie mit der von Ubiquiti verfügbaren bash API.
Wenn ansonsten niemand damit ein Problem hat, brauchst Du das Modul aber für mich nicht umzubauen. Ich kann mir prima mit den Skripten helfen.
Moin,
Das kann ich schon recht einfach umbauen, so dass man set Unifi blockClient auch mit einer mac aufrufen kann. Über die Oberfläche hätte man weiterhin die Auswahl der aktuellen clients beim Namen, kann die Funktion aber auch mit mac aufrufen.
Muss mich aber erstmal um meinen raspi des UnifiControllers kümmern. Der zickt seit gestern. Vermutlich die SD-Karte.
Grüße,
Dirk
Zitat von: Wuehler am 01 Juni 2018, 07:46:55
Muss mich aber erstmal um meinen raspi des UnifiControllers kümmern. Der zickt seit gestern. Vermutlich die SD-Karte.
Grüße,
Dirk
Ich habe seit einigen Wochen alle meine Raspis auf SSD umgebaut, geht sehr leicht mit dem Raspi 3 und 3B+.
Es hat sich gelohnt, keine Probleme mehr. Lieber ein mal ein billiges SSD kaufen, als oft neue SD-Karten kaufen.
Die kleinsten SSDs sind jetzt nur ~35€. MicroSD kostet ~10€
@christian:
im Anhang eine neue Version auf Basis des Moduls inkl. UnifiSwitch-Modul, daher bitte beide Dateien nehmen. Darin ist blockClient und unblockClient so angepasst, dass man es auch mit einer mac aufrufen kann. Habe dabei die implizit vorhandene Möglichkeit alle clients zu blocken entfernt. Das schien mir keine sinnvolle Funktion und ein Kopierfehler von disconnectClient sein.
Bitte mal testen.
@keny: War jetzt die erste SD in 5 Jahren. Eine Chance gebe ich ihr noch ;)
VG,
Dirk
Hi Dirk - Ja, danke, das block und unblock per MAC funktioniert hier, auch mit Devices, die nicht als Clients in der Dropdown-Box gelistet sind. Sehr schön!
Die SDs in den Himbeeren halten hier auch schön lange. Wobei ich versuche, Schreibvorgänge auf ein Minimum zu begrenzen und auch ins RAM logge und das nur selten auf die SD synchronisiere.
Einen schönen Sonntag,
Christian
Auch auf die Gefahr hin das es schon gefragt wurde:
Gibt es die Möglichkeit ein Notify auszulösen wenn sich ein neuer Client verbindet, der bisher noch nicht im Netz war?
Besten Dank schonmal
Matze
Moin Matze,
in dem Fall würde ein neues Reading mit dem Namen des clients entstehen. Ich kenne aktuell keinen Weg, wie man so etwas in FHEM mitbekommen kann.
Habe dir im Anhang eine Version gebaut mit dem Reading UC_newClients. Daran kannst du neue Clients erkennen. Wenn es mehrere sind, werden sie durch Komma getrennt. Nach einem Interval wird das Reading wieder auf leer gesetzt. Falls du einen Unifi-Switch hast bitte auch das Unifi-Switch-Modul mit kopieren.
VG,
Dirk
Hallo zusammen,
Ich habe die Version jetzt eingecheckt. Ab morgen dann folgende neue Features im Update:
Unifi:
# V 3.0
# - feature: 74_Unifi: new child-Module UnifiSwitch
# V 3.0.1
# - feature: 74_Unifi: new reading UC_newClients for new clients
# - feature: 74_Unifi: block clients by mac-address
UnifiSwitch:
# V 0.11
# - feature: 74_UnifiSwitch: state des USW wird gesetzt
# Port-Nummern < 9 mit führender 0
# Model als Internal
# port-state als reading hinzugefügt
# V 0.90
# - feature: 74_UnififSwitch: setter for poe-Mode
# added commandref
Bitte passt die Nutzung der setter und getter zum poe-Mode auf das neue Modul UnifiSwitch an. Irgendwann werde ich das aus dem Unifi(-Controller)-Modul entfernen.
VG,
Dirk
Hallo zusammen,
Seit dem letzten Update des Unifi-Moduls Connected und Disconnected das Modul hin und wieder.
Und wenn es einmal damit angefangen hat hört es nicht mehr auf.
Die Software läuft auf einer Synology DS412+.
Wenn ich mich unter der Adresse xxx.xxx.xxx.xxx:8443 anmelde, kann ich alles bedienen.
Die Software auf der Synology ist die 5.7.25 und das 74_Unifi.pm 16784 vom 2018-05-27
Auf dem AP läuft die Version 3.9.27.8537
Hat irgendjemand ähnliche Schwierigkeiten und weiß wie die zu lösen sind?
Danke Benny
Moin,
In dem Update des Unifi-Moduls war eine kleine Umformatierung des Login-Cookies. Das dürfte aber nicht diese Auswirkungen haben. Ich vermute du hast ein Performance-Problem. Fhem und Unifi laufen auf der DS? Wie ist das Update-Intervall des Unifi-Moduls? Was steht im Log? (Ggf. Verbose=5 setzen)
VG,
Dirk
Nur die Unifi Software läuft auf der Synology, Fhem läuft auf einem raspberry 3. Mit verbose 5 werde ich noch schauen wenn das Problem wieder da ist.
Gruss Benny
Es hört sich für mich konsequent an, wenn der connect bei Performance-Problemen dann dauerhaft nicht funktioniert, da der Unifi-Controller dann im Intervall-Abstand neue Anfragen bekommt. Dagegen spricht, dass du über die Unifi-Oberfläche noch gut arbeiten kannst. Bin dann mal auf das Log gespannt. Schau dir zu der Zeit auch mal mit dem Befehl top auf der console des RasPi und der DS an, wie es um die Performance gerade bestellt ist.
Wie behebst du das Problem denn bisher?
@Matze: hilft das neu eingebaute Reading für neue Clients? Wenn nein würde ich es bald wieder ausbauen. Ohne Nutzer einer Funktion braucht die Funktion nicht die Performance verbrauchen.
Ich behebe es in dem ich einen "shutdown restart" mache.
Heute wieder gewesen und diesmal auch ein log. Konnte ich nur via VPN einschalten. Das Problem fing um 13:18 an bis zum shutdown restart um 13:22.
Ich habe mal beide Logs hinzugefügt. Ist allerdings ne Menge.
Das Problem kommt wenn meine Frau mit dem (Honor_6X) das Haus verlässt mein Samsung GalaxyS7 ist da schon weg und sich die Alarmanlage einschaltet.
Die Heizung runterfährt etc pp. Leider nicht reproduzierbar.
Leider habe ich auch keine CPU Auslastung (top) ausführen können da keiner zuhause war.
Man sieht eindeutig das sich das Modul connected und disconnected. z.B.
2018-06-14_13:21:37 UniFi initialized
2018-06-14_13:21:37 UniFi disconnected.
Gruß benny
2018.06.14 13:18:45 1: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:18:45 3: alarm6.arm.N return value: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:18:45 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:18:45 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:18:45 3: nanoCUL433 IT_set: Sirene on
2018.06.14 13:18:46 3: CUL_HM set WT_Diele_Climate controlMode night
2018.06.14 13:18:46 3: CUL_HM set ZirkPumpe off
2018.06.14 13:18:48 3: alarm6.disarm.N return value: [Alarm 6] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:18:49 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:18:49 3: nanoCUL433 IT_set: Sirene off
2018.06.14 13:18:49 3: CUL_HM set WT_Diele_Climate controlMode auto
2018.06.14 13:18:49 3: CUL_HM set ZirkPumpe on
2018.06.14 13:18:50 1: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:18:50 3: alarm6.arm.N return value: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:18:50 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:18:50 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:18:50 3: nanoCUL433 IT_set: Sirene on
2018.06.14 13:18:50 3: CUL_HM set WT_Diele_Climate controlMode night
2018.06.14 13:18:50 3: CUL_HM set ZirkPumpe off
2018.06.14 13:18:51 3: CUL_HM ZirkPumpe repeat, level C8 instead of 00
2018.06.14 13:18:54 3: alarm6.disarm.N return value: [Alarm 6] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:18:54 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:18:54 3: nanoCUL433 IT_set: Sirene off
2018.06.14 13:18:55 3: CUL_HM set WT_Diele_Climate controlMode auto
2018.06.14 13:18:55 3: CUL_HM set ZirkPumpe on
2018.06.14 13:18:55 1: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:18:55 3: alarm6.arm.N return value: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:18:55 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:18:55 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:18:55 3: nanoCUL433 IT_set: Sirene on
2018.06.14 13:18:55 3: CUL_HM set WT_Diele_Climate controlMode night
2018.06.14 13:18:55 3: CUL_HM set ZirkPumpe off
2018.06.14 13:18:56 3: CUL_HM ZirkPumpe repeat, level C8 instead of 00
2018.06.14 13:19:01 3: alarm6.disarm.N return value: [Alarm 6] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:19:01 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:19:01 3: nanoCUL433 IT_set: Sirene off
2018.06.14 13:19:01 3: CUL_HM set WT_Diele_Climate controlMode auto
2018.06.14 13:19:01 3: CUL_HM set ZirkPumpe on
2018.06.14 13:19:01 1: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:01 3: alarm6.arm.N return value: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:02 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:02 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:02 3: nanoCUL433 IT_set: Sirene on
2018.06.14 13:19:02 3: CUL_HM set WT_Diele_Climate controlMode night
2018.06.14 13:19:02 3: CUL_HM set ZirkPumpe off
2018.06.14 13:19:03 3: CUL_HM ZirkPumpe repeat, level C8 instead of 00
2018.06.14 13:19:08 3: alarm6.disarm.N return value: [Alarm 6] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:19:08 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:19:08 3: nanoCUL433 IT_set: Sirene off
2018.06.14 13:19:08 3: CUL_HM set WT_Diele_Climate controlMode auto
2018.06.14 13:19:08 3: CUL_HM set ZirkPumpe on
2018.06.14 13:19:09 1: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:09 3: alarm6.arm.N return value: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:09 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:09 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:09 3: nanoCUL433 IT_set: Sirene on
2018.06.14 13:19:09 3: CUL_HM set WT_Diele_Climate controlMode night
2018.06.14 13:19:09 3: CUL_HM set ZirkPumpe off
2018.06.14 13:19:10 3: CUL_HM ZirkPumpe repeat, level C8 instead of 00
2018.06.14 13:19:13 3: alarm6.disarm.N return value: [Alarm 6] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:19:13 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:19:13 3: nanoCUL433 IT_set: Sirene off
2018.06.14 13:19:14 3: CUL_HM set WT_Diele_Climate controlMode auto
2018.06.14 13:19:14 3: CUL_HM set ZirkPumpe on
2018.06.14 13:19:14 1: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:14 3: alarm6.arm.N return value: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:14 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:14 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:14 3: nanoCUL433 IT_set: Sirene on
2018.06.14 13:19:14 3: CUL_HM set WT_Diele_Climate controlMode night
2018.06.14 13:19:15 3: CUL_HM set ZirkPumpe off
2018.06.14 13:19:16 3: CUL_HM ZirkPumpe repeat, level C8 instead of 00
2018.06.14 13:19:20 3: alarm6.disarm.N return value: [Alarm 6] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:19:20 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:19:20 3: nanoCUL433 IT_set: Sirene off
2018.06.14 13:19:20 3: CUL_HM set WT_Diele_Climate controlMode auto
2018.06.14 13:19:20 3: CUL_HM set ZirkPumpe on
2018.06.14 13:19:21 1: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:21 3: alarm6.arm.N return value: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:21 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:21 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:21 3: nanoCUL433 IT_set: Sirene on
2018.06.14 13:19:21 3: CUL_HM set WT_Diele_Climate controlMode night
2018.06.14 13:19:21 3: CUL_HM set ZirkPumpe off
2018.06.14 13:19:22 3: CUL_HM ZirkPumpe repeat, level C8 instead of 00
2018.06.14 13:19:27 3: ESPEasy: set ESPEasy_Poolpumpe_PUMP gpio 12 off
2018.06.14 13:19:27 3: alarm6.disarm.N return value: [Alarm 6] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:19:27 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:19:27 3: nanoCUL433 IT_set: Sirene off
2018.06.14 13:19:28 3: CUL_HM set WT_Diele_Climate controlMode auto
2018.06.14 13:19:28 3: CUL_HM set ZirkPumpe on
2018.06.14 13:19:28 1: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:28 3: alarm6.arm.N return value: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:28 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:28 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:28 3: nanoCUL433 IT_set: Sirene on
2018.06.14 13:19:28 3: CUL_HM set WT_Diele_Climate controlMode night
2018.06.14 13:19:28 3: CUL_HM set ZirkPumpe off
2018.06.14 13:19:29 3: CUL_HM ZirkPumpe repeat, level C8 instead of 00
2018.06.14 13:19:29 2: ESPEasy espBridge: httpReq failed: 192.168.2.69 Poolpumpe_PUMP 'gpio 12,0'
2018.06.14 13:19:29 2: ESPEasy ESPEasy_Poolpumpe_PUMP: WARNING: http://192.168.2.69:80/control?cmd=gpio,12,0: empty answer received
2018.06.14 13:19:33 3: alarm6.disarm.N return value: [Alarm 6] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:19:33 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:19:33 3: nanoCUL433 IT_set: Sirene off
2018.06.14 13:19:33 3: CUL_HM set WT_Diele_Climate controlMode auto
2018.06.14 13:19:33 3: CUL_HM set ZirkPumpe on
2018.06.14 13:19:33 1: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:33 3: alarm6.arm.N return value: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:34 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:34 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:34 3: nanoCUL433 IT_set: Sirene on
2018.06.14 13:19:34 3: CUL_HM set WT_Diele_Climate controlMode night
2018.06.14 13:19:34 3: CUL_HM set ZirkPumpe off
2018.06.14 13:19:35 3: CUL_HM ZirkPumpe repeat, level C8 instead of 00
2018.06.14 13:19:38 3: alarm6.disarm.N return value: [Alarm 6] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:19:38 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:19:38 3: nanoCUL433 IT_set: Sirene off
2018.06.14 13:19:38 3: CUL_HM set WT_Diele_Climate controlMode auto
2018.06.14 13:19:38 3: CUL_HM set ZirkPumpe on
2018.06.14 13:19:39 1: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:39 3: alarm6.arm.N return value: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:39 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:39 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:39 3: nanoCUL433 IT_set: Sirene on
2018.06.14 13:19:39 3: CUL_HM set WT_Diele_Climate controlMode night
2018.06.14 13:19:39 3: CUL_HM set ZirkPumpe off
2018.06.14 13:19:40 3: CUL_HM ZirkPumpe repeat, level C8 instead of 00
2018.06.14 13:19:44 3: alarm6.disarm.N return value: [Alarm 6] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:19:44 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:19:44 3: nanoCUL433 IT_set: Sirene off
2018.06.14 13:19:44 3: CUL_HM set WT_Diele_Climate controlMode auto
2018.06.14 13:19:44 3: CUL_HM set ZirkPumpe on
2018.06.14 13:19:45 1: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:45 3: alarm6.arm.N return value: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:45 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:45 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:19:45 3: nanoCUL433 IT_set: Sirene on
2018.06.14 13:19:46 3: CUL_HM set WT_Diele_Climate controlMode night
2018.06.14 13:19:46 3: CUL_HM set ZirkPumpe off
2018.06.14 13:19:46 3: CUL_HM ZirkPumpe repeat, level C8 instead of 00
2018.06.14 13:19:47 3: TelegramBot_Callback teleBot: resulted in NonBlockingGet timed out on read from <hidden> after 30s from SendIt
2018.06.14 13:19:47 3: TelegramBot_Callback teleBot: Reached max retries (ret: NonBlockingGet timed out on read from <hidden> after 30s) for msg #fhemgruppe : Alarm ausgeschaltet
2018.06.14 13:19:52 3: alarm6.disarm.N return value: [Alarm 6] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:19:52 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:19:52 3: nanoCUL433 IT_set: Sirene off
2018.06.14 13:21:28 5: UniFi (Unifi_Login_Receive) - executed.
2018.06.14 13:21:28 5: UniFi (Unifi_Login_Receive) - state=ok || version=3
2018.06.14 13:21:28 5: UniFi (Unifi_Login_Receive) - Login successfully! Cookie: unifises=0GstSp3p0COwNhadFYpJpShJBwFOj3zU;\r\nCookie: csrf_token=08031fxZaM6IUmQ9Sl8pen7kMZ7sWkNA;
2018.06.14 13:21:28 5: UniFi (Unifi_DoUpdate) - executed.
2018.06.14 13:21:28 5: UniFi (Unifi_GetEvents_Send) - executed.
2018.06.14 13:21:28 5: UniFi (Unifi_Login_Receive) - executed.
2018.06.14 13:21:28 5: UniFi (Unifi_Login_Receive) - state=ok || version=3
2018.06.14 13:21:28 5: UniFi (Unifi_Login_Receive) - Login successfully! Cookie: unifises=GiMrWS0p1gjvIPWnm1tzyRfENEoNpFQB;\r\nCookie: csrf_token=wD6ycwQJ1WQQCdoBj79VYiVfq5UsLJDX;
2018.06.14 13:21:28 5: UniFi (Unifi_DoUpdate) - executed.
2018.06.14 13:21:28 5: UniFi (Unifi_GetClients_Send) - executed.
2018.06.14 13:21:28 5: UniFi (Unifi_Login_Receive) - executed.
2018.06.14 13:21:28 5: UniFi (Unifi_Login_Receive) - state=ok || version=3
2018.06.14 13:21:28 5: UniFi (Unifi_Login_Receive) - Login successfully! Cookie: unifises=UYj1fiCQlqktDjMuBjxsrhHrgM6Y8uZX;\r\nCookie: csrf_token=u3H7t7OztuEfgeV7WQ4oGWdonV4spC74;
2018.06.14 13:21:28 5: UniFi (Unifi_DoUpdate) - executed.
2018.06.14 13:21:28 5: UniFi (Unifi_GetAccesspoints_Send) - executed.
2018.06.14 13:21:28 5: UniFi (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.06.14 13:21:28 5: UniFi (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.06.14 13:21:28 5: UniFi (Unifi_GetAccesspoints_Send) - executed.
2018.06.14 13:21:28 5: UniFi (Unifi_Login_Receive) - executed.
2018.06.14 13:21:28 5: UniFi (Unifi_Login_Receive) - state=ok || version=3
2018.06.14 13:21:28 5: UniFi (Unifi_Login_Receive) - Login successfully! Cookie: unifises=Yt9z1kSyZ4KLD9nTwkF5rmRriQ6I6Ytj;\r\nCookie: csrf_token=pUc9zM0MIY7z6WXDzWMBlcEjen4sT7v3;
2018.06.14 13:21:28 5: UniFi (Unifi_DoUpdate) - executed.
2018.06.14 13:21:28 5: UniFi (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.06.14 13:21:28 5: UniFi (Unifi_GetClients_Receive) - executed.
2018.06.14 13:21:28 5: UniFi (Unifi_GetClients_Receive) - state:'ok'
2018.06.14 13:21:28 5: UniFi (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.06.14 13:21:28 5: UniFi (Unifi_GetAccesspoints_Receive) - executed.
2018.06.14 13:21:28 5: UniFi (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.06.14 13:21:28 5: UniFi (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.06.14 13:21:28 5: UniFi (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.06.14 13:21:28 5: UniFi (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.06.14 13:21:28 5: UniFi (Unifi_GetVoucherList_Send) - executed.
2018.06.14 13:21:28 5: UniFi (Unifi_GetAccesspoints_Receive) - executed.
2018.06.14 13:21:28 5: UniFi (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.06.14 13:21:28 5: UniFi (Unifi_GetVoucherList_Send) - executed.
2018.06.14 13:21:29 5: UniFi (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.06.14 13:21:29 5: UniFi (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.06.14 13:21:29 5: UniFi (Unifi_GetVoucherList_Send) - executed.
2018.06.14 13:21:29 5: UniFi (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.06.14 13:21:29 5: UniFi (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.06.14 13:21:29 5: UniFi (Unifi_GetVoucherList_Send) - executed.
2018.06.14 13:21:29 5: UniFi (Unifi_GetVoucherList_Receive) - executed.
2018.06.14 13:21:29 5: UniFi (Unifi_GetVoucherList_Receive) - state:'ok'
2018.06.14 13:21:29 5: UniFi (Unifi_GetEvents_Send) - executed.
2018.06.14 13:21:29 5: UniFi (Unifi_GetVoucherList_Receive) - executed.
2018.06.14 13:21:29 5: UniFi (Unifi_GetVoucherList_Receive) - state:'ok'
2018.06.14 13:21:29 5: UniFi (Unifi_GetEvents_Send) - executed.
2018.06.14 13:21:30 5: UniFi (Unifi_GetVoucherList_Receive) - executed.
2018.06.14 13:21:30 5: UniFi (Unifi_GetVoucherList_Receive) - state:'ok'
2018.06.14 13:21:30 5: UniFi (Unifi_GetEvents_Send) - executed.
2018.06.14 13:21:30 5: UniFi (Unifi_GetVoucherList_Receive) - executed.
2018.06.14 13:21:30 5: UniFi (Unifi_GetVoucherList_Receive) - state:'ok'
2018.06.14 13:21:30 5: UniFi (Unifi_GetEvents_Send) - executed.
2018.06.14 13:21:30 5: UniFi (Unifi_GetEvents_Receive) - executed.
2018.06.14 13:21:30 5: UniFi (Unifi_GetEvents_Receive) - state:'ok'
2018.06.14 13:21:30 5: UniFi (Unifi_GetWlans_Send) - executed.
2018.06.14 13:21:30 5: UniFi (Unifi_GetEvents_Receive) - executed.
2018.06.14 13:21:30 5: UniFi (Unifi_GetEvents_Receive) - state:'ok'
2018.06.14 13:21:30 5: UniFi (Unifi_GetWlans_Send) - executed.
2018.06.14 13:21:30 5: UniFi (Unifi_GetWlans_Receive) - executed.
2018.06.14 13:21:30 5: UniFi (Unifi_GetWlans_Receive) - state:'ok'
2018.06.14 13:21:30 5: UniFi (Unifi_GetHealth_Send) - executed.
2018.06.14 13:21:30 5: UniFi (Unifi_GetEvents_Receive) - executed.
2018.06.14 13:21:30 5: UniFi (Unifi_GetEvents_Receive) - state:'ok'
2018.06.14 13:21:30 5: UniFi (Unifi_GetHealth_Send) - executed.
2018.06.14 13:21:31 5: UniFi (Unifi_GetHealth_Receive) - executed.
2018.06.14 13:21:31 5: UniFi (Unifi_GetHealth_Receive) - state:'ok'
2018.06.14 13:21:31 5: UniFi (Unifi_ProcessUpdate) - executed after 2.7627 seconds.
2018.06.14 13:21:31 5: UniFi (Unifi_SetHealthReadings) - executed.
2018.06.14 13:21:31 5: UniFi (Unifi_SetClientReadings) - executed.
2018.06.14 13:21:31 5: UniFi (Unifi_SetClientReadings) - Client 'Honor_6X' previously connected is now disconnected.
2018.06.14 13:21:31 5: UniFi (Unifi_SetAccesspointReadings) - executed.
2018.06.14 13:21:31 5: UniFi (Unifi_SetWlanReadings) - executed.
2018.06.14 13:21:31 5: UniFi (Unifi_SetVoucherReadings) - executed.
2018.06.14 13:21:31 5: UniFi (Unifi_Notify) - executed. - Remove all Timers & Call DoUpdate...
2018.06.14 13:21:31 5: UniFi (Unifi_DoUpdate) - executed.
2018.06.14 13:21:31 5: UniFi (Unifi_Login_Send) - executed.
2018.06.14 13:21:31 3: alarm6.disarm.N return value: [Alarm 6] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:21:31 5: UniFi (Unifi_Notify) - executed. - Remove all Timers & Call DoUpdate...
2018.06.14 13:21:31 5: UniFi (Unifi_DoUpdate) - executed.
2018.06.14 13:21:31 5: UniFi (Unifi_Login_Send) - executed.
2018.06.14 13:21:31 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:21:31 3: nanoCUL433 IT_set: Sirene off
2018.06.14 13:21:32 3: CUL_HM set WT_Diele_Climate controlMode auto
2018.06.14 13:21:32 3: CUL_HM set ZirkPumpe on
2018.06.14 13:21:32 5: UniFi (Unifi_Notify) - executed. - Remove all Timers & Call DoUpdate...
2018.06.14 13:21:32 5: UniFi (Unifi_DoUpdate) - executed.
2018.06.14 13:21:32 5: UniFi (Unifi_Login_Send) - executed.
2018.06.14 13:21:32 1: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:21:32 3: alarm6.arm.N return value: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:21:32 5: UniFi (Unifi_Notify) - executed. - Remove all Timers & Call DoUpdate...
2018.06.14 13:21:32 5: UniFi (Unifi_DoUpdate) - executed.
2018.06.14 13:21:32 5: UniFi (Unifi_Login_Send) - executed.
2018.06.14 13:21:32 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:21:32 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:21:32 3: nanoCUL433 IT_set: Sirene on
2018.06.14 13:21:32 3: CUL_HM set WT_Diele_Climate controlMode night
2018.06.14 13:21:32 3: CUL_HM set ZirkPumpe off
2018.06.14 13:21:33 5: UniFi (Unifi_ProcessUpdate) - finished after 4.7021 seconds.
2018.06.14 13:21:33 5: UniFi (Unifi_GetHealth_Receive) - executed.
2018.06.14 13:21:33 5: UniFi (Unifi_GetHealth_Receive) - state:'ok'
2018.06.14 13:21:33 5: UniFi (Unifi_GetWlans_Receive) - executed.
2018.06.14 13:21:33 5: UniFi (Unifi_GetWlans_Receive) - state:'ok'
2018.06.14 13:21:33 3: CUL_HM ZirkPumpe repeat, level C8 instead of 00
2018.06.14 13:21:33 5: UniFi (Unifi_GetEvents_Receive) - executed.
2018.06.14 13:21:33 5: UniFi (Unifi_GetEvents_Receive) - state:'ok'
2018.06.14 13:21:33 5: UniFi (Unifi_GetEvents_Receive) - executed.
2018.06.14 13:21:33 5: UniFi (Unifi_GetEvents_Receive) - state:'ok'
2018.06.14 13:21:33 5: UniFi (Unifi_Login_Receive) - executed.
2018.06.14 13:21:33 5: UniFi (Unifi_Login_Receive) - state=ok || version=3
2018.06.14 13:21:33 5: UniFi (Unifi_Login_Receive) - Login successfully! Cookie: unifises=hnoLEwzvCL0ofzz23DfV7uZTEspPdvBN;\r\nCookie: csrf_token=xkeFLcqEk0ABaGS8Vvf99pOcb66s2ZtT;
2018.06.14 13:21:33 5: UniFi (Unifi_DoUpdate) - executed.
2018.06.14 13:21:33 5: UniFi (Unifi_GetAccesspoints_Send) - executed.
2018.06.14 13:21:34 5: UniFi (Unifi_Login_Receive) - executed.
2018.06.14 13:21:34 5: UniFi (Unifi_Login_Receive) - state=ok || version=3
2018.06.14 13:21:34 5: UniFi (Unifi_Login_Receive) - Login successfully! Cookie: unifises=IeQG99JRhBAyfDQcGclPSBYBrewUaVhb;\r\nCookie: csrf_token=xaC2mrRS7H2IYgQ6TDDHvIcHUnwbxhQm;
2018.06.14 13:21:34 5: UniFi (Unifi_DoUpdate) - executed.
2018.06.14 13:21:34 5: UniFi (Unifi_GetVoucherList_Send) - executed.
2018.06.14 13:21:34 5: UniFi (Unifi_Login_Receive) - executed.
2018.06.14 13:21:34 5: UniFi (Unifi_Login_Receive) - state=ok || version=3
2018.06.14 13:21:34 5: UniFi (Unifi_Login_Receive) - Login successfully! Cookie: unifises=OBG7AmXnn226930AOg8mat6RcwKjO5sl;\r\nCookie: csrf_token=JdbcePOVQ0UNvKQjfF6IZjyjFF0cFOKn;
2018.06.14 13:21:34 5: UniFi (Unifi_DoUpdate) - executed.
2018.06.14 13:21:34 5: UniFi (Unifi_GetClients_Send) - executed.
2018.06.14 13:21:34 5: UniFi (Unifi_Login_Receive) - executed.
2018.06.14 13:21:34 5: UniFi (Unifi_Login_Receive) - state=ok || version=3
2018.06.14 13:21:34 5: UniFi (Unifi_Login_Receive) - Login successfully! Cookie: unifises=k9jbbdjBGLeIY4OboPTWNtKsx2tGhz7Y;\r\nCookie: csrf_token=2qQHyZfxjV8n72puC8tX8qSFo6B1qRa0;
2018.06.14 13:21:34 5: UniFi (Unifi_DoUpdate) - executed.
2018.06.14 13:21:34 5: UniFi (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.06.14 13:21:34 5: UniFi (Unifi_GetVoucherList_Receive) - executed.
2018.06.14 13:21:34 5: UniFi (Unifi_GetVoucherList_Receive) - state:'ok'
2018.06.14 13:21:34 5: UniFi (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.06.14 13:21:34 5: UniFi (Unifi_GetAccesspoints_Receive) - executed.
2018.06.14 13:21:34 5: UniFi (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.06.14 13:21:34 5: UniFi (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.06.14 13:21:34 5: UniFi (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.06.14 13:21:34 5: UniFi (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.06.14 13:21:34 5: UniFi (Unifi_GetClients_Send) - executed.
2018.06.14 13:21:35 5: UniFi (Unifi_GetClients_Receive) - executed.
2018.06.14 13:21:35 5: UniFi (Unifi_GetClients_Receive) - state:'ok'
2018.06.14 13:21:35 5: UniFi (Unifi_GetEvents_Send) - executed.
2018.06.14 13:21:35 5: UniFi (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.06.14 13:21:35 5: UniFi (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.06.14 13:21:35 5: UniFi (Unifi_GetEvents_Send) - executed.
2018.06.14 13:21:35 5: UniFi (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.06.14 13:21:35 5: UniFi (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.06.14 13:21:35 5: UniFi (Unifi_GetEvents_Send) - executed.
2018.06.14 13:21:35 5: UniFi (Unifi_GetClients_Receive) - executed.
2018.06.14 13:21:35 5: UniFi (Unifi_GetClients_Receive) - state:'ok'
2018.06.14 13:21:35 5: UniFi (Unifi_GetEvents_Send) - executed.
2018.06.14 13:21:36 5: UniFi (Unifi_GetEvents_Receive) - executed.
2018.06.14 13:21:36 5: UniFi (Unifi_GetEvents_Receive) - state:'ok'
2018.06.14 13:21:36 5: UniFi (Unifi_GetWlans_Send) - executed.
2018.06.14 13:21:36 5: UniFi (Unifi_GetEvents_Receive) - executed.
2018.06.14 13:21:36 5: UniFi (Unifi_GetEvents_Receive) - state:'ok'
2018.06.14 13:21:36 5: UniFi (Unifi_GetWlans_Send) - executed.
2018.06.14 13:21:36 5: UniFi (Unifi_GetWlans_Receive) - executed.
2018.06.14 13:21:36 5: UniFi (Unifi_GetWlans_Receive) - state:'ok'
2018.06.14 13:21:36 5: UniFi (Unifi_GetHealth_Send) - executed.
2018.06.14 13:21:36 5: UniFi (Unifi_GetEvents_Receive) - executed.
2018.06.14 13:21:36 5: UniFi (Unifi_GetEvents_Receive) - state:'ok'
2018.06.14 13:21:36 5: UniFi (Unifi_GetHealth_Send) - executed.
2018.06.14 13:21:36 5: UniFi (Unifi_GetWlans_Receive) - executed.
2018.06.14 13:21:36 5: UniFi (Unifi_GetWlans_Receive) - state:'ok'
2018.06.14 13:21:36 5: UniFi (Unifi_GetHealth_Send) - executed.
2018.06.14 13:21:36 5: UniFi (Unifi_GetEvents_Receive) - executed.
2018.06.14 13:21:36 5: UniFi (Unifi_GetEvents_Receive) - state:'ok'
2018.06.14 13:21:36 5: UniFi (Unifi_GetHealth_Send) - executed.
2018.06.14 13:21:37 5: UniFi (Unifi_GetHealth_Receive) - executed.
2018.06.14 13:21:37 5: UniFi (Unifi_GetHealth_Receive) - state:'ok'
2018.06.14 13:21:37 5: UniFi (Unifi_ProcessUpdate) - executed after 2.7381 seconds.
2018.06.14 13:21:37 5: UniFi (Unifi_SetHealthReadings) - executed.
2018.06.14 13:21:37 5: UniFi (Unifi_SetClientReadings) - executed.
2018.06.14 13:21:37 5: UniFi (Unifi_SetClientReadings) - Client 'Honor_6X' previously connected is now disconnected.
2018.06.14 13:21:37 5: UniFi (Unifi_SetAccesspointReadings) - executed.
2018.06.14 13:21:37 5: UniFi (Unifi_SetWlanReadings) - executed.
2018.06.14 13:21:37 5: UniFi (Unifi_SetVoucherReadings) - executed.
2018.06.14 13:21:37 5: UniFi (Unifi_Notify) - executed. - Remove all Timers & Call DoUpdate...
2018.06.14 13:21:37 5: UniFi (Unifi_DoUpdate) - executed.
2018.06.14 13:21:37 5: UniFi (Unifi_Login_Send) - executed.
2018.06.14 13:21:37 3: alarm6.disarm.N return value: [Alarm 6] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:21:37 5: UniFi (Unifi_Notify) - executed. - Remove all Timers & Call DoUpdate...
2018.06.14 13:21:37 5: UniFi (Unifi_DoUpdate) - executed.
2018.06.14 13:21:37 5: UniFi (Unifi_Login_Send) - executed.
2018.06.14 13:21:37 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
2018.06.14 13:21:37 3: nanoCUL433 IT_set: Sirene off
2018.06.14 13:21:38 3: CUL_HM set WT_Diele_Climate controlMode auto
2018.06.14 13:21:38 3: CUL_HM set ZirkPumpe on
2018.06.14 13:21:38 5: UniFi (Unifi_Notify) - executed. - Remove all Timers & Call DoUpdate...
2018.06.14 13:21:38 5: UniFi (Unifi_DoUpdate) - executed.
2018.06.14 13:21:38 5: UniFi (Unifi_Login_Send) - executed.
2018.06.14 13:21:38 1: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:21:38 3: alarm6.arm.N return value: [Alarm 6] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:21:38 5: UniFi (Unifi_Notify) - executed. - Remove all Timers & Call DoUpdate...
2018.06.14 13:21:38 5: UniFi (Unifi_DoUpdate) - executed.
2018.06.14 13:21:38 5: UniFi (Unifi_Login_Send) - executed.
2018.06.14 13:21:38 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:21:38 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
2018.06.14 13:21:38 3: nanoCUL433 IT_set: Sirene on
2018.06.14 13:21:38 3: CUL_HM set WT_Diele_Climate controlMode night
2018.06.14 13:21:38 3: CUL_HM set ZirkPumpe off
2018.06.14 13:21:39 5: UniFi (Unifi_ProcessUpdate) - finished after 4.8173 seconds.
2018.06.14 13:21:39 5: UniFi (Unifi_GetHealth_Receive) - executed.
2018.06.14 13:21:39 5: UniFi (Unifi_GetHealth_Receive) - state:'ok'
2018.06.14 13:21:39 5: UniFi (Unifi_GetHealth_Receive) - executed.
2018.06.14 13:21:39 5: UniFi (Unifi_GetHealth_Receive) - state:'ok'
2018.06.14 13:21:39 5: UniFi (Unifi_GetHealth_Receive) - executed.
2018.06.14 13:21:39 5: UniFi (Unifi_GetHealth_Receive) - state:'ok'
2018.06.14 13:21:39 3: CUL_HM ZirkPumpe repeat, level C8 instead of 00
2018.06.14 13:21:40 5: UniFi (Unifi_Login_Receive) - executed.
2018.06.14 13:21:40 5: UniFi (Unifi_Login_Receive) - state=ok || version=3
2018.06.14 13:21:40 5: UniFi (Unifi_Login_Receive) - Login successfully! Cookie: unifises=9ki0F7Gr6qJdFEcSVYeHrDXusOYaEf0u;\r\nCookie: csrf_token=jSNJsPsqaBexSS1Dgld5TEbIY0uWcUuP;
2018.06.14 13:21:40 5: UniFi (Unifi_DoUpdate) - executed.
2018.06.14 13:21:40 5: UniFi (Unifi_GetHealth_Send) - executed.
2018.06.14 13:21:40 5: UniFi (Unifi_Login_Receive) - executed.
2018.06.14 13:21:40 5: UniFi (Unifi_Login_Receive) - state=ok || version=3
2018.06.14 13:21:40 5: UniFi (Unifi_Login_Receive) - Login successfully! Cookie: unifises=VHHUXRbPYDROyRYauaE2mnF8uASv0UwE;\r\nCookie: csrf_token=5Ie04BCHmbfwgWatWhn9daAc4X06LaWf;
2018.06.14 13:21:40 5: UniFi (Unifi_DoUpdate) - executed.
2018.06.14 13:21:40 5: UniFi (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.06.14 13:21:40 5: UniFi (Unifi_Login_Receive) - executed.
2018.06.14 13:21:40 5: UniFi (Unifi_Login_Receive) - state=ok || version=3
2018.06.14 13:21:40 5: UniFi (Unifi_Login_Receive) - Login successfully! Cookie: unifises=Nuj5066TsirzsnpMoyPXkbcC3c5AYggC;\r\nCookie: csrf_token=W9netTFjjOEJ7w4bS6xDdsrORnxMeEBH;
2018.06.14 13:21:40 5: UniFi (Unifi_DoUpdate) - executed.
2018.06.14 13:21:40 5: UniFi (Unifi_GetWlans_Send) - executed.
2018.06.14 13:21:40 5: UniFi (Unifi_Login_Receive) - executed.
2018.06.14 13:21:40 5: UniFi (Unifi_Login_Receive) - state=ok || version=3
2018.06.14 13:21:40 5: UniFi (Unifi_Login_Receive) - Login successfully! Cookie: unifises=dFnfpBeSmG1AGKmsJkgSboCEaRvR8jYg;\r\nCookie: csrf_token=vWaOMH1p1TVKv7XXT9lgnxO8Fxm2HIhP;
2018.06.14 13:21:40 5: UniFi (Unifi_DoUpdate) - executed.
2018.06.14 13:21:40 5: UniFi (Unifi_GetAccesspoints_Send) - executed.
2018.06.14 13:21:40 5: UniFi (Unifi_GetHealth_Receive) - executed.
2018.06.14 13:21:40 5: UniFi (Unifi_GetHealth_Receive) - state:'ok'
2018.06.14 13:21:40 5: UniFi (Unifi_GetAccesspoints_Send) - executed.
2018.06.14 13:21:40 5: UniFi (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.06.14 13:21:40 5: UniFi (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.06.14 13:21:40 5: UniFi (Unifi_GetAccesspoints_Send) - executed.
2018.06.14 13:21:40 5: UniFi (Unifi_GetWlans_Receive) - executed.
2018.06.14 13:21:40 5: UniFi (Unifi_GetWlans_Receive) - state:'ok'
2018.06.14 13:21:40 5: UniFi (Unifi_GetAccesspoints_Send) - executed.
2018.06.14 13:21:40 5: UniFi (Unifi_GetAccesspoints_Receive) - executed.
2018.06.14 13:21:40 5: UniFi (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.06.14 13:21:40 5: UniFi (Unifi_GetEvents_Send) - executed.
2018.06.14 13:21:41 5: UniFi (Unifi_GetAccesspoints_Receive) - executed.
2018.06.14 13:21:41 5: UniFi (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.06.14 13:21:41 5: UniFi (Unifi_GetEvents_Send) - executed.
2018.06.14 13:21:41 5: UniFi (Unifi_GetAccesspoints_Receive) - executed.
2018.06.14 13:21:41 5: UniFi (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.06.14 13:21:41 5: UniFi (Unifi_GetEvents_Send) - executed.
2018.06.14 13:21:41 5: UniFi (Unifi_GetAccesspoints_Receive) - executed.
2018.06.14 13:21:41 5: UniFi (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.06.14 13:21:41 5: UniFi (Unifi_GetEvents_Send) - executed.
2018.06.14 13:21:41 3: TelegramBot_Callback teleBot: resulted in NonBlockingGet timed out on read from <hidden> after 30s from SendIt
2018.06.14 13:21:41 3: TelegramBot_Callback teleBot: Reached max retries (ret: NonBlockingGet timed out on read from <hidden> after 30s) for msg #fhemgruppe : Alarm ausgeschaltet
2018.06.14 13:21:41 5: UniFi (Unifi_GetEvents_Receive) - executed.
2018.06.14 13:21:42 5: UniFi (Unifi_GetEvents_Receive) - state:'ok'
2018.06.14 13:21:42 5: UniFi (Unifi_GetClients_Send) - executed.
2018.06.14 13:21:42 5: UniFi (Unifi_GetEvents_Receive) - executed.
2018.06.14 13:21:42 5: UniFi (Unifi_GetEvents_Receive) - state:'ok'
2018.06.14 13:21:42 5: UniFi (Unifi_GetClients_Send) - executed.
2018.06.14 13:21:42 5: UniFi (Unifi_GetClients_Receive) - executed.
2018.06.14 13:21:42 5: UniFi (Unifi_GetClients_Receive) - state:'ok'
2018.06.14 13:21:42 5: UniFi (Unifi_GetVoucherList_Send) - executed.
2018.06.14 13:21:42 5: UniFi (Unifi_GetEvents_Receive) - executed.
2018.06.14 13:21:42 5: UniFi (Unifi_GetEvents_Receive) - state:'ok'
2018.06.14 13:21:42 5: UniFi (Unifi_GetVoucherList_Send) - executed.
2018.06.14 13:21:42 5: UniFi (Unifi_GetClients_Receive) - executed.
2018.06.14 13:21:42 5: UniFi (Unifi_GetClients_Receive) - state:'ok'
2018.06.14 13:21:42 5: UniFi (Unifi_GetVoucherList_Send) - executed.
2018.06.14 13:21:42 5: UniFi (Unifi_GetEvents_Receive) - executed.
2018.06.14 13:21:42 5: UniFi (Unifi_GetEvents_Receive) - state:'ok'
2018.06.14 13:21:42 5: UniFi (Unifi_GetVoucherList_Send) - executed.
2018.06.14 13:21:42 5: UniFi (Unifi_GetVoucherList_Receive) - executed.
2018.06.14 13:21:42 5: UniFi (Unifi_GetVoucherList_Receive) - state:'ok'
2018.06.14 13:21:42 5: UniFi (Unifi_ProcessUpdate) - executed after 2.6474 seconds.
2018.06.14 13:21:42 5: UniFi (Unifi_SetHealthReadings) - executed.
2018.06.14 13:21:42 5: UniFi (Unifi_SetClientReadings) - executed.
2018.06.14 13:21:42 5: UniFi (Unifi_SetAccesspointReadings) - executed.
2018.06.14 13:21:42 5: UniFi (Unifi_SetWlanReadings) - executed.
2018.06.14 13:21:42 5: UniFi (Unifi_SetVoucherReadings) - executed.
2018.06.14 13:21:43 5: UniFi (Unifi_ProcessUpdate) - finished after 2.8887 seconds.
2018.06.14 13:21:43 5: UniFi (Unifi_GetVoucherList_Receive) - executed.
2018.06.14 13:21:43 5: UniFi (Unifi_GetVoucherList_Receive) - state:'ok'
2018.06.14 13:21:43 5: UniFi (Unifi_GetVoucherList_Receive) - executed.
2018.06.14 13:21:43 5: UniFi (Unifi_GetVoucherList_Receive) - state:'ok'
2018.06.14 13:21:43 5: UniFi (Unifi_GetVoucherList_Receive) - executed.
2018.06.14 13:21:43 5: UniFi (Unifi_GetVoucherList_Receive) - state:'ok'
2018.06.14 13:22:08 3: [Alarm 6] armed from alarmSensor AlarmArm with event delay
2018.06.14 13:22:08 3: alarm6.arm.dly: [Alarm 6] armed from alarmSensor AlarmArm with event delay
2018.06.14 13:22:08 3: [Alarm 7] armed from alarmSensor AlarmArm with event delay
2018.06.14 13:22:08 3: alarm7.arm.dly: [Alarm 7] armed from alarmSensor AlarmArm with event delay
2018.06.14 13:22:13 5: UniFi (Unifi_DoUpdate) - executed.
2018.06.14 13:22:13 5: UniFi (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.06.14 13:22:13 5: UniFi (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.06.14 13:22:13 5: UniFi (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.06.14 13:22:13 5: UniFi (Unifi_GetEvents_Send) - executed.
2018.06.14 13:22:13 5: UniFi (Unifi_GetEvents_Receive) - executed.
2018.06.14 13:22:13 5: UniFi (Unifi_GetEvents_Receive) - state:'ok'
2018.06.14 13:22:13 5: UniFi (Unifi_GetClients_Send) - executed.
2018.06.14 13:22:13 5: UniFi (Unifi_GetClients_Receive) - executed.
2018.06.14 13:22:13 5: UniFi (Unifi_GetClients_Receive) - state:'ok'
2018.06.14 13:22:13 5: UniFi (Unifi_GetVoucherList_Send) - executed.
2018.06.14 13:22:14 5: UniFi (Unifi_GetVoucherList_Receive) - executed.
2018.06.14 13:22:14 5: UniFi (Unifi_GetVoucherList_Receive) - state:'ok'
2018.06.14 13:22:14 5: UniFi (Unifi_GetAccesspoints_Send) - executed.
2018.06.14 13:22:14 5: UniFi (Unifi_GetAccesspoints_Receive) - executed.
2018.06.14 13:22:14 5: UniFi (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.06.14 13:22:14 5: UniFi (Unifi_GetHealth_Send) - executed.
2018.06.14 13:22:14 5: UniFi (Unifi_GetHealth_Receive) - executed.
2018.06.14 13:22:14 5: UniFi (Unifi_GetHealth_Receive) - state:'ok'
2018.06.14 13:22:14 5: UniFi (Unifi_GetWlans_Send) - executed.
2018.06.14 13:22:14 5: UniFi (Unifi_GetWlans_Receive) - executed.
2018.06.14 13:22:14 5: UniFi (Unifi_GetWlans_Receive) - state:'ok'
2018.06.14 13:22:14 5: UniFi (Unifi_ProcessUpdate) - executed after 1.3233 seconds.
2018.06.14 13:22:14 5: UniFi (Unifi_SetHealthReadings) - executed.
2018.06.14 13:22:14 5: UniFi (Unifi_SetClientReadings) - executed.
2018.06.14 13:22:14 5: UniFi (Unifi_SetAccesspointReadings) - executed.
2018.06.14 13:22:14 5: UniFi (Unifi_SetWlanReadings) - executed.
2018.06.14 13:22:14 5: UniFi (Unifi_SetVoucherReadings) - executed.
2018.06.14 13:22:14 5: UniFi (Unifi_ProcessUpdate) - finished after 1.5832 seconds.
2018.06.14 13:22:31 0: Server shutdown
2018.06.14 13:22:32 1: Shutdown executed
Hier noch das Unifi Log
2018-06-14_13:18:45 UniFi UC_newClients:
2018-06-14_13:18:45 UniFi -AP_Unifi Wlan AP_state: ok
2018-06-14_13:18:45 UniFi -AP_Unifi Wlan AP_clients: 15
2018-06-14_13:18:45 UniFi -AP_Unifi Wlan AP_essid: ATHome,Gast-WLAN,ATHome,Gast-WLAN
2018-06-14_13:18:45 UniFi -AP_Unifi Wlan AP_locate: off
2018-06-14_13:18:45 UniFi -WLAN_Gast-WLAN_state: enabled
2018-06-14_13:18:45 UniFi -WLAN_ATHome_state: enabled
2018-06-14_13:18:45 UniFi initialized
2018-06-14_13:18:45 UniFi disconnected
2018-06-14_13:18:45 UniFi initialized
2018-06-14_13:18:45 UniFi disconnected
2018-06-14_13:18:46 UniFi connected
2018-06-14_13:18:48 UniFi -UC_wlan_state: ok
2018-06-14_13:18:48 UniFi -UC_wlan_users: 15
2018-06-14_13:18:48 UniFi -UC_wlan_accesspoints: 1
2018-06-14_13:18:48 UniFi -UC_wlan_guests: 0
2018-06-14_13:18:48 UniFi -UC_unarchived_alerts: 1
2018-06-14_13:18:48 UniFi -UC_events: 3000 (last 24h)
2018-06-14_13:18:48 UniFi Poolpumpe_hostname: Poolpumpe
2018-06-14_13:18:48 UniFi Poolpumpe_last_seen: 2018-06-14 13:18:39
2018-06-14_13:18:48 UniFi Poolpumpe_uptime: 307076
2018-06-14_13:18:48 UniFi Poolpumpe_snr: 22
2018-06-14_13:18:48 UniFi Poolpumpe_essid: ATHome
2018-06-14_13:18:48 UniFi Poolpumpe_accesspoint: Unifi Wlan AP
2018-06-14_13:18:48 UniFi Poolpumpe: connected
2018-06-14_13:18:48 UniFi CarportCam_hostname: 192.168.2.151
2018-06-14_13:18:48 UniFi CarportCam_last_seen: 2018-06-14 13:18:39
2018-06-14_13:18:48 UniFi CarportCam_uptime: 321827
2018-06-14_13:18:48 UniFi CarportCam_snr: 19
2018-06-14_13:18:48 UniFi CarportCam_essid: ATHome
2018-06-14_13:18:48 UniFi CarportCam_accesspoint: Unifi Wlan AP
2018-06-14_13:18:48 UniFi CarportCam: connected
2018-06-14_13:18:48 UniFi Fronius_hostname: 192.168.2.163
2018-06-14_13:18:48 UniFi Fronius_last_seen: 2018-06-14 13:18:39
2018-06-14_13:18:48 UniFi Fronius_uptime: 1044286
2018-06-14_13:18:48 UniFi Fronius_snr: 26
2018-06-14_13:18:48 UniFi Fronius_essid: ATHome
2018-06-14_13:18:48 UniFi Fronius_accesspoint: Unifi Wlan AP
2018-06-14_13:18:48 UniFi Fronius: connected
2018-06-14_13:18:48 UniFi deckenlampe-7353_hostname: deckenlampe-7353
2018-06-14_13:18:48 UniFi deckenlampe-7353_last_seen: 2018-06-14 13:18:39
2018-06-14_13:18:48 UniFi deckenlampe-7353_uptime: 374021
2018-06-14_13:18:48 UniFi deckenlampe-7353_snr: 35
2018-06-14_13:18:48 UniFi deckenlampe-7353_essid: ATHome
2018-06-14_13:18:48 UniFi deckenlampe-7353_accesspoint: Unifi Wlan AP
2018-06-14_13:18:48 UniFi deckenlampe-7353: connected
2018-06-14_13:18:48 UniFi esstischlampe-7415_hostname: esstischlampe-7415
2018-06-14_13:18:48 UniFi esstischlampe-7415_last_seen: 2018-06-14 13:18:39
2018-06-14_13:18:48 UniFi esstischlampe-7415_uptime: 326144
2018-06-14_13:18:48 UniFi esstischlampe-7415_snr: 44
2018-06-14_13:18:48 UniFi esstischlampe-7415_essid: ATHome
2018-06-14_13:18:48 UniFi esstischlampe-7415_accesspoint: Unifi Wlan AP
2018-06-14_13:18:48 UniFi esstischlampe-7415: connected
2018-06-14_13:18:48 UniFi Honor_6X_hostname: Honor_6X
2018-06-14_13:18:48 UniFi Honor_6X_last_seen: 2018-06-14 13:16:23
2018-06-14_13:18:48 UniFi Honor_6X_uptime: 10076
2018-06-14_13:18:48 UniFi Honor_6X_snr: 8
2018-06-14_13:18:48 UniFi Honor_6X_essid: ATHome
2018-06-14_13:18:48 UniFi Honor_6X_accesspoint: Unifi Wlan AP
2018-06-14_13:18:48 UniFi Honor_6X: connected
2018-06-14_13:18:48 UniFi octopi_hostname: octopi
2018-06-14_13:18:48 UniFi octopi_last_seen: 2018-06-14 13:18:39
2018-06-14_13:18:48 UniFi octopi_uptime: 321822
2018-06-14_13:18:48 UniFi octopi_snr: 43
2018-06-14_13:18:48 UniFi octopi_essid: ATHome
2018-06-14_13:18:48 UniFi octopi_accesspoint: Unifi Wlan AP
2018-06-14_13:18:48 UniFi octopi: connected
2018-06-14_13:18:48 UniFi TL-WA860RE_hostname: TL-WA860RE
2018-06-14_13:18:48 UniFi TL-WA860RE_last_seen: 2018-06-14 13:18:39
2018-06-14_13:18:48 UniFi TL-WA860RE_uptime: 1044273
2018-06-14_13:18:48 UniFi TL-WA860RE_snr: 23
2018-06-14_13:18:48 UniFi TL-WA860RE_essid: ATHome
2018-06-14_13:18:48 UniFi TL-WA860RE_accesspoint: Unifi Wlan AP
2018-06-14_13:18:48 UniFi TL-WA860RE: connected
2018-06-14_13:18:48 UniFi FireTV-Stick_hostname: amazon-7e6a597e9
2018-06-14_13:18:48 UniFi FireTV-Stick_last_seen: 2018-06-14 13:18:39
2018-06-14_13:18:48 UniFi FireTV-Stick_uptime: 652901
2018-06-14_13:18:48 UniFi FireTV-Stick_snr: 20
2018-06-14_13:18:48 UniFi FireTV-Stick_essid: ATHome
2018-06-14_13:18:48 UniFi FireTV-Stick_accesspoint: Unifi Wlan AP
2018-06-14_13:18:48 UniFi FireTV-Stick: connected
2018-06-14_13:18:48 UniFi Ralfs-iPad_hostname: Ralfs-iPad
2018-06-14_13:18:48 UniFi Ralfs-iPad_last_seen: 2018-06-14 13:18:39
2018-06-14_13:18:48 UniFi Ralfs-iPad_uptime: 968328
2018-06-14_13:18:48 UniFi Ralfs-iPad_snr: 46
2018-06-14_13:18:48 UniFi Ralfs-iPad_essid: ATHome
2018-06-14_13:18:48 UniFi Ralfs-iPad_accesspoint: Unifi Wlan AP
2018-06-14_13:18:48 UniFi Ralfs-iPad: connected
2018-06-14_13:18:48 UniFi Alexa-Wohnzimmer_hostname: 192.168.2.42
2018-06-14_13:18:48 UniFi Alexa-Wohnzimmer_last_seen: 2018-06-14 13:18:39
2018-06-14_13:18:48 UniFi Alexa-Wohnzimmer_uptime: 438041
2018-06-14_13:18:48 UniFi Alexa-Wohnzimmer_snr: 36
2018-06-14_13:18:48 UniFi Alexa-Wohnzimmer_essid: ATHome
2018-06-14_13:18:48 UniFi Alexa-Wohnzimmer_accesspoint: Unifi Wlan AP
2018-06-14_13:18:48 UniFi Alexa-Wohnzimmer: connected
2018-06-14_13:18:48 UniFi Alexa-Kueche_hostname: amazon-98a3a0c3a
2018-06-14_13:18:48 UniFi Alexa-Kueche_last_seen: 2018-06-14 13:18:39
2018-06-14_13:18:48 UniFi Alexa-Kueche_uptime: 406776
2018-06-14_13:18:48 UniFi Alexa-Kueche_snr: 51
2018-06-14_13:18:48 UniFi Alexa-Kueche_essid: ATHome
2018-06-14_13:18:48 UniFi Alexa-Kueche_accesspoint: Unifi Wlan AP
2018-06-14_13:18:48 UniFi Alexa-Kueche: connected
2018-06-14_13:18:48 UniFi drucker-3062_hostname: drucker-3062
2018-06-14_13:18:48 UniFi drucker-3062_last_seen: 2018-06-14 13:18:39
2018-06-14_13:18:48 UniFi drucker-3062_uptime: 300734
2018-06-14_13:18:48 UniFi drucker-3062_snr: 14
2018-06-14_13:18:48 UniFi drucker-3062_essid: ATHome
2018-06-14_13:18:48 UniFi drucker-3062_accesspoint: Unifi Wlan AP
2018-06-14_13:18:48 UniFi drucker-3062: connected
2018-06-14_13:18:48 UniFi Honor_6X: disconnected
2018-06-14_13:18:48 UniFi HarmonyHub_hostname: HarmonyHub
2018-06-14_13:18:48 UniFi HarmonyHub_last_seen: 2018-06-14 13:18:39
2018-06-14_13:18:48 UniFi HarmonyHub_uptime: 1044301
2018-06-14_13:18:48 UniFi HarmonyHub_snr: 53
2018-06-14_13:18:48 UniFi HarmonyHub_essid: ATHome
2018-06-14_13:18:48 UniFi HarmonyHub_accesspoint: Unifi Wlan AP
2018-06-14_13:18:48 UniFi HarmonyHub: connected
2018-06-14_13:18:48 UniFi Poollicht_hostname: Poollicht
2018-06-14_13:18:48 UniFi Poollicht_last_seen: 2018-06-14 13:18:39
2018-06-14_13:18:48 UniFi Poollicht_uptime: 279536
2018-06-14_13:18:48 UniFi Poollicht_snr: 22
2018-06-14_13:18:48 UniFi Poollicht_essid: ATHome
2018-06-14_13:18:48 UniFi Poollicht_accesspoint: Unifi Wlan AP
2018-06-14_13:18:48 UniFi Poollicht: connected
2018-06-14_13:18:48 UniFi UC_newClients:
2018-06-14_13:18:48 UniFi -AP_Unifi Wlan AP_state: ok
2018-06-14_13:18:48 UniFi -AP_Unifi Wlan AP_clients: 15
2018-06-14_13:18:48 UniFi -AP_Unifi Wlan AP_essid: ATHome,Gast-WLAN,ATHome,Gast-WLAN
2018-06-14_13:18:48 UniFi -AP_Unifi Wlan AP_locate: off
2018-06-14_13:18:48 UniFi -WLAN_Gast-WLAN_state: enabled
2018-06-14_13:18:48 UniFi -WLAN_ATHome_state: enabled
2018-06-14_13:18:48 UniFi initialized
2018-06-14_13:18:48 UniFi disconnected
2018-06-14_13:18:48 UniFi initialized
2018-06-14_13:18:48 UniFi disconnected
2018-06-14_13:18:48 UniFi initialized
2018-06-14_13:18:48 UniFi disconnected
2018-06-14_13:18:48 UniFi initialized
2018-06-14_13:18:48 UniFi disconnected
2018-06-14_13:18:51 UniFi connected
2018-06-14_13:18:54 UniFi -UC_wlan_state: ok
2018-06-14_13:18:54 UniFi -UC_wlan_users: 15
2018-06-14_13:18:54 UniFi -UC_wlan_accesspoints: 1
2018-06-14_13:18:54 UniFi -UC_wlan_guests: 0
2018-06-14_13:18:54 UniFi -UC_unarchived_alerts: 1
2018-06-14_13:18:54 UniFi -UC_events: 3000 (last 24h)
2018-06-14_13:18:54 UniFi Poolpumpe_hostname: Poolpumpe
2018-06-14_13:18:54 UniFi Poolpumpe_last_seen: 2018-06-14 13:18:52
2018-06-14_13:18:54 UniFi Poolpumpe_uptime: 307089
2018-06-14_13:18:54 UniFi Poolpumpe_snr: 22
2018-06-14_13:18:54 UniFi Poolpumpe_essid: ATHome
2018-06-14_13:18:54 UniFi Poolpumpe_accesspoint: Unifi Wlan AP
2018-06-14_13:18:54 UniFi Poolpumpe: connected
2018-06-14_13:18:54 UniFi CarportCam_hostname: 192.168.2.151
2018-06-14_13:18:54 UniFi CarportCam_last_seen: 2018-06-14 13:18:52
2018-06-14_13:18:54 UniFi CarportCam_uptime: 321840
2018-06-14_13:18:54 UniFi CarportCam_snr: 18
2018-06-14_13:18:54 UniFi CarportCam_essid: ATHome
2018-06-14_13:18:54 UniFi CarportCam_accesspoint: Unifi Wlan AP
2018-06-14_13:18:54 UniFi CarportCam: connected
2018-06-14_13:18:54 UniFi Fronius_hostname: 192.168.2.163
2018-06-14_13:18:54 UniFi Fronius_last_seen: 2018-06-14 13:18:52
2018-06-14_13:18:54 UniFi Fronius_uptime: 1044299
2018-06-14_13:18:54 UniFi Fronius_snr: 27
2018-06-14_13:18:54 UniFi Fronius_essid: ATHome
2018-06-14_13:18:54 UniFi Fronius_accesspoint: Unifi Wlan AP
2018-06-14_13:18:54 UniFi Fronius: connected
2018-06-14_13:18:54 UniFi deckenlampe-7353_hostname: deckenlampe-7353
2018-06-14_13:18:54 UniFi deckenlampe-7353_last_seen: 2018-06-14 13:18:52
2018-06-14_13:18:54 UniFi deckenlampe-7353_uptime: 374034
2018-06-14_13:18:54 UniFi deckenlampe-7353_snr: 35
2018-06-14_13:18:54 UniFi deckenlampe-7353_essid: ATHome
2018-06-14_13:18:54 UniFi deckenlampe-7353_accesspoint: Unifi Wlan AP
2018-06-14_13:18:54 UniFi deckenlampe-7353: connected
2018-06-14_13:18:54 UniFi esstischlampe-7415_hostname: esstischlampe-7415
2018-06-14_13:18:54 UniFi esstischlampe-7415_last_seen: 2018-06-14 13:18:52
2018-06-14_13:18:54 UniFi esstischlampe-7415_uptime: 326157
2018-06-14_13:18:54 UniFi esstischlampe-7415_snr: 45
2018-06-14_13:18:54 UniFi esstischlampe-7415_essid: ATHome
2018-06-14_13:18:54 UniFi esstischlampe-7415_accesspoint: Unifi Wlan AP
2018-06-14_13:18:54 UniFi esstischlampe-7415: connected
2018-06-14_13:18:54 UniFi Honor_6X_hostname: Honor_6X
2018-06-14_13:18:54 UniFi Honor_6X_last_seen: 2018-06-14 13:16:23
2018-06-14_13:18:54 UniFi Honor_6X_uptime: 10076
2018-06-14_13:18:54 UniFi Honor_6X_snr: 8
2018-06-14_13:18:54 UniFi Honor_6X_essid: ATHome
2018-06-14_13:18:54 UniFi Honor_6X_accesspoint: Unifi Wlan AP
2018-06-14_13:18:54 UniFi Honor_6X: connected
2018-06-14_13:18:54 UniFi octopi_hostname: octopi
2018-06-14_13:18:54 UniFi octopi_last_seen: 2018-06-14 13:18:52
2018-06-14_13:18:54 UniFi octopi_uptime: 321835
2018-06-14_13:18:54 UniFi octopi_snr: 38
2018-06-14_13:18:54 UniFi octopi_essid: ATHome
2018-06-14_13:18:54 UniFi octopi_accesspoint: Unifi Wlan AP
2018-06-14_13:18:54 UniFi octopi: connected
2018-06-14_13:18:54 UniFi TL-WA860RE_hostname: TL-WA860RE
2018-06-14_13:18:54 UniFi TL-WA860RE_last_seen: 2018-06-14 13:18:52
2018-06-14_13:18:54 UniFi TL-WA860RE_uptime: 1044286
2018-06-14_13:18:54 UniFi TL-WA860RE_snr: 23
2018-06-14_13:18:54 UniFi TL-WA860RE_essid: ATHome
2018-06-14_13:18:54 UniFi TL-WA860RE_accesspoint: Unifi Wlan AP
2018-06-14_13:18:54 UniFi TL-WA860RE: connected
2018-06-14_13:18:54 UniFi FireTV-Stick_hostname: amazon-7e6a597e9
2018-06-14_13:18:54 UniFi FireTV-Stick_last_seen: 2018-06-14 13:18:52
2018-06-14_13:18:54 UniFi FireTV-Stick_uptime: 652914
2018-06-14_13:18:54 UniFi FireTV-Stick_snr: 20
2018-06-14_13:18:54 UniFi FireTV-Stick_essid: ATHome
2018-06-14_13:18:54 UniFi FireTV-Stick_accesspoint: Unifi Wlan AP
2018-06-14_13:18:54 UniFi FireTV-Stick: connected
2018-06-14_13:18:54 UniFi Ralfs-iPad_hostname: Ralfs-iPad
2018-06-14_13:18:54 UniFi Ralfs-iPad_last_seen: 2018-06-14 13:18:52
2018-06-14_13:18:54 UniFi Ralfs-iPad_uptime: 968341
2018-06-14_13:18:54 UniFi Ralfs-iPad_snr: 46
2018-06-14_13:18:54 UniFi Ralfs-iPad_essid: ATHome
2018-06-14_13:18:54 UniFi Ralfs-iPad_accesspoint: Unifi Wlan AP
2018-06-14_13:18:54 UniFi Ralfs-iPad: connected
2018-06-14_13:18:54 UniFi Alexa-Wohnzimmer_hostname: 192.168.2.42
2018-06-14_13:18:54 UniFi Alexa-Wohnzimmer_last_seen: 2018-06-14 13:18:52
2018-06-14_13:18:54 UniFi Alexa-Wohnzimmer_uptime: 438054
2018-06-14_13:18:54 UniFi Alexa-Wohnzimmer_snr: 36
2018-06-14_13:18:54 UniFi Alexa-Wohnzimmer_essid: ATHome
2018-06-14_13:18:54 UniFi Alexa-Wohnzimmer_accesspoint: Unifi Wlan AP
2018-06-14_13:18:54 UniFi Alexa-Wohnzimmer: connected
2018-06-14_13:18:54 UniFi Alexa-Kueche_hostname: amazon-98a3a0c3a
2018-06-14_13:18:54 UniFi Alexa-Kueche_last_seen: 2018-06-14 13:18:52
2018-06-14_13:18:54 UniFi Alexa-Kueche_uptime: 406789
2018-06-14_13:18:54 UniFi Alexa-Kueche_snr: 51
2018-06-14_13:18:54 UniFi Alexa-Kueche_essid: ATHome
2018-06-14_13:18:54 UniFi Alexa-Kueche_accesspoint: Unifi Wlan AP
2018-06-14_13:18:54 UniFi Alexa-Kueche: connected
2018-06-14_13:18:54 UniFi drucker-3062_hostname: drucker-3062
2018-06-14_13:18:54 UniFi drucker-3062_last_seen: 2018-06-14 13:18:52
2018-06-14_13:18:54 UniFi drucker-3062_uptime: 300747
2018-06-14_13:18:54 UniFi drucker-3062_snr: 15
2018-06-14_13:18:54 UniFi drucker-3062_essid: ATHome
2018-06-14_13:18:54 UniFi drucker-3062_accesspoint: Unifi Wlan AP
2018-06-14_13:18:54 UniFi drucker-3062: connected
2018-06-14_13:18:54 UniFi Honor_6X: disconnected
2018-06-14_13:18:54 UniFi HarmonyHub_hostname: HarmonyHub
2018-06-14_13:18:54 UniFi HarmonyHub_last_seen: 2018-06-14 13:18:52
2018-06-14_13:18:54 UniFi HarmonyHub_uptime: 1044314
2018-06-14_13:18:54 UniFi HarmonyHub_snr: 53
2018-06-14_13:18:54 UniFi HarmonyHub_essid: ATHome
2018-06-14_13:18:54 UniFi HarmonyHub_accesspoint: Unifi Wlan AP
2018-06-14_13:18:54 UniFi HarmonyHub: connected
2018-06-14_13:18:54 UniFi Poollicht_hostname: Poollicht
2018-06-14_13:18:54 UniFi Poollicht_last_seen: 2018-06-14 13:18:52
2018-06-14_13:18:54 UniFi Poollicht_uptime: 279549
2018-06-14_13:18:54 UniFi Poollicht_snr: 22
2018-06-14_13:18:54 UniFi Poollicht_essid: ATHome
2018-06-14_13:18:54 UniFi Poollicht_accesspoint: Unifi Wlan AP
2018-06-14_13:18:54 UniFi Poollicht: connected
2018-06-14_13:18:54 UniFi UC_newClients:
2018-06-14_13:18:54 UniFi -AP_Unifi Wlan AP_state: ok
2018-06-14_13:18:54 UniFi -AP_Unifi Wlan AP_clients: 15
2018-06-14_13:18:54 UniFi -AP_Unifi Wlan AP_essid: ATHome,Gast-WLAN,ATHome,Gast-WLAN
2018-06-14_13:18:54 UniFi -AP_Unifi Wlan AP_locate: off
2018-06-14_13:18:54 UniFi -WLAN_Gast-WLAN_state: enabled
2018-06-14_13:18:54 UniFi -WLAN_ATHome_state: enabled
2018-06-14_13:18:54 UniFi initialized
2018-06-14_13:18:54 UniFi disconnected
2018-06-14_13:18:54 UniFi initialized
2018-06-14_13:18:54 UniFi disconnected
2018-06-14_13:18:54 UniFi initialized
2018-06-14_13:18:54 UniFi disconnected
2018-06-14_13:18:54 UniFi initialized
2018-06-14_13:18:54 UniFi disconnected
2018-06-14_13:18:57 UniFi connected
2018-06-14_13:19:00 UniFi -UC_wlan_state: ok
2018-06-14_13:19:00 UniFi -UC_wlan_users: 15
2018-06-14_13:19:00 UniFi -UC_wlan_accesspoints: 1
2018-06-14_13:19:00 UniFi -UC_wlan_guests: 0
2018-06-14_13:19:00 UniFi -UC_unarchived_alerts: 1
2018-06-14_13:19:00 UniFi -UC_events: 3000 (last 24h)
2018-06-14_13:19:00 UniFi Poolpumpe_hostname: Poolpumpe
2018-06-14_13:19:00 UniFi Poolpumpe_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:00 UniFi Poolpumpe_uptime: 307089
2018-06-14_13:19:00 UniFi Poolpumpe_snr: 22
2018-06-14_13:19:00 UniFi Poolpumpe_essid: ATHome
2018-06-14_13:19:00 UniFi Poolpumpe_accesspoint: Unifi Wlan AP
2018-06-14_13:19:00 UniFi Poolpumpe: connected
2018-06-14_13:19:00 UniFi CarportCam_hostname: 192.168.2.151
2018-06-14_13:19:00 UniFi CarportCam_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:00 UniFi CarportCam_uptime: 321840
2018-06-14_13:19:00 UniFi CarportCam_snr: 18
2018-06-14_13:19:00 UniFi CarportCam_essid: ATHome
2018-06-14_13:19:00 UniFi CarportCam_accesspoint: Unifi Wlan AP
2018-06-14_13:19:00 UniFi CarportCam: connected
2018-06-14_13:19:00 UniFi Fronius_hostname: 192.168.2.163
2018-06-14_13:19:00 UniFi Fronius_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:00 UniFi Fronius_uptime: 1044299
2018-06-14_13:19:00 UniFi Fronius_snr: 27
2018-06-14_13:19:00 UniFi Fronius_essid: ATHome
2018-06-14_13:19:00 UniFi Fronius_accesspoint: Unifi Wlan AP
2018-06-14_13:19:00 UniFi Fronius: connected
2018-06-14_13:19:00 UniFi deckenlampe-7353_hostname: deckenlampe-7353
2018-06-14_13:19:00 UniFi deckenlampe-7353_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:00 UniFi deckenlampe-7353_uptime: 374034
2018-06-14_13:19:00 UniFi deckenlampe-7353_snr: 35
2018-06-14_13:19:00 UniFi deckenlampe-7353_essid: ATHome
2018-06-14_13:19:00 UniFi deckenlampe-7353_accesspoint: Unifi Wlan AP
2018-06-14_13:19:00 UniFi deckenlampe-7353: connected
2018-06-14_13:19:00 UniFi esstischlampe-7415_hostname: esstischlampe-7415
2018-06-14_13:19:00 UniFi esstischlampe-7415_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:00 UniFi esstischlampe-7415_uptime: 326157
2018-06-14_13:19:00 UniFi esstischlampe-7415_snr: 45
2018-06-14_13:19:00 UniFi esstischlampe-7415_essid: ATHome
2018-06-14_13:19:00 UniFi esstischlampe-7415_accesspoint: Unifi Wlan AP
2018-06-14_13:19:00 UniFi esstischlampe-7415: connected
2018-06-14_13:19:00 UniFi Honor_6X_hostname: Honor_6X
2018-06-14_13:19:00 UniFi Honor_6X_last_seen: 2018-06-14 13:16:23
2018-06-14_13:19:00 UniFi Honor_6X_uptime: 10076
2018-06-14_13:19:00 UniFi Honor_6X_snr: 8
2018-06-14_13:19:00 UniFi Honor_6X_essid: ATHome
2018-06-14_13:19:00 UniFi Honor_6X_accesspoint: Unifi Wlan AP
2018-06-14_13:19:00 UniFi Honor_6X: connected
2018-06-14_13:19:00 UniFi octopi_hostname: octopi
2018-06-14_13:19:00 UniFi octopi_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:00 UniFi octopi_uptime: 321835
2018-06-14_13:19:00 UniFi octopi_snr: 38
2018-06-14_13:19:00 UniFi octopi_essid: ATHome
2018-06-14_13:19:00 UniFi octopi_accesspoint: Unifi Wlan AP
2018-06-14_13:19:00 UniFi octopi: connected
2018-06-14_13:19:00 UniFi TL-WA860RE_hostname: TL-WA860RE
2018-06-14_13:19:00 UniFi TL-WA860RE_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:00 UniFi TL-WA860RE_uptime: 1044286
2018-06-14_13:19:00 UniFi TL-WA860RE_snr: 23
2018-06-14_13:19:00 UniFi TL-WA860RE_essid: ATHome
2018-06-14_13:19:00 UniFi TL-WA860RE_accesspoint: Unifi Wlan AP
2018-06-14_13:19:00 UniFi TL-WA860RE: connected
2018-06-14_13:19:00 UniFi FireTV-Stick_hostname: amazon-7e6a597e9
2018-06-14_13:19:00 UniFi FireTV-Stick_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:00 UniFi FireTV-Stick_uptime: 652914
2018-06-14_13:19:00 UniFi FireTV-Stick_snr: 20
2018-06-14_13:19:00 UniFi FireTV-Stick_essid: ATHome
2018-06-14_13:19:00 UniFi FireTV-Stick_accesspoint: Unifi Wlan AP
2018-06-14_13:19:00 UniFi FireTV-Stick: connected
2018-06-14_13:19:00 UniFi Ralfs-iPad_hostname: Ralfs-iPad
2018-06-14_13:19:00 UniFi Ralfs-iPad_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:00 UniFi Ralfs-iPad_uptime: 968341
2018-06-14_13:19:00 UniFi Ralfs-iPad_snr: 46
2018-06-14_13:19:00 UniFi Ralfs-iPad_essid: ATHome
2018-06-14_13:19:00 UniFi Ralfs-iPad_accesspoint: Unifi Wlan AP
2018-06-14_13:19:00 UniFi Ralfs-iPad: connected
2018-06-14_13:19:00 UniFi Alexa-Wohnzimmer_hostname: 192.168.2.42
2018-06-14_13:19:00 UniFi Alexa-Wohnzimmer_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:00 UniFi Alexa-Wohnzimmer_uptime: 438054
2018-06-14_13:19:00 UniFi Alexa-Wohnzimmer_snr: 36
2018-06-14_13:19:00 UniFi Alexa-Wohnzimmer_essid: ATHome
2018-06-14_13:19:00 UniFi Alexa-Wohnzimmer_accesspoint: Unifi Wlan AP
2018-06-14_13:19:00 UniFi Alexa-Wohnzimmer: connected
2018-06-14_13:19:00 UniFi Alexa-Kueche_hostname: amazon-98a3a0c3a
2018-06-14_13:19:00 UniFi Alexa-Kueche_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:00 UniFi Alexa-Kueche_uptime: 406789
2018-06-14_13:19:00 UniFi Alexa-Kueche_snr: 51
2018-06-14_13:19:00 UniFi Alexa-Kueche_essid: ATHome
2018-06-14_13:19:00 UniFi Alexa-Kueche_accesspoint: Unifi Wlan AP
2018-06-14_13:19:00 UniFi Alexa-Kueche: connected
2018-06-14_13:19:00 UniFi drucker-3062_hostname: drucker-3062
2018-06-14_13:19:00 UniFi drucker-3062_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:00 UniFi drucker-3062_uptime: 300747
2018-06-14_13:19:00 UniFi drucker-3062_snr: 15
2018-06-14_13:19:00 UniFi drucker-3062_essid: ATHome
2018-06-14_13:19:00 UniFi drucker-3062_accesspoint: Unifi Wlan AP
2018-06-14_13:19:00 UniFi drucker-3062: connected
2018-06-14_13:19:00 UniFi Honor_6X: disconnected
2018-06-14_13:19:00 UniFi HarmonyHub_hostname: HarmonyHub
2018-06-14_13:19:00 UniFi HarmonyHub_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:00 UniFi HarmonyHub_uptime: 1044314
2018-06-14_13:19:00 UniFi HarmonyHub_snr: 53
2018-06-14_13:19:00 UniFi HarmonyHub_essid: ATHome
2018-06-14_13:19:00 UniFi HarmonyHub_accesspoint: Unifi Wlan AP
2018-06-14_13:19:00 UniFi HarmonyHub: connected
2018-06-14_13:19:00 UniFi Poollicht_hostname: Poollicht
2018-06-14_13:19:00 UniFi Poollicht_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:00 UniFi Poollicht_uptime: 279549
2018-06-14_13:19:00 UniFi Poollicht_snr: 22
2018-06-14_13:19:00 UniFi Poollicht_essid: ATHome
2018-06-14_13:19:00 UniFi Poollicht_accesspoint: Unifi Wlan AP
2018-06-14_13:19:00 UniFi Poollicht: connected
2018-06-14_13:19:00 UniFi UC_newClients:
2018-06-14_13:19:00 UniFi -AP_Unifi Wlan AP_state: ok
2018-06-14_13:19:00 UniFi -AP_Unifi Wlan AP_clients: 15
2018-06-14_13:19:00 UniFi -AP_Unifi Wlan AP_essid: ATHome,Gast-WLAN,ATHome,Gast-WLAN
2018-06-14_13:19:00 UniFi -AP_Unifi Wlan AP_locate: off
2018-06-14_13:19:00 UniFi -WLAN_Gast-WLAN_state: enabled
2018-06-14_13:19:00 UniFi -WLAN_ATHome_state: enabled
2018-06-14_13:19:00 UniFi initialized
2018-06-14_13:19:00 UniFi disconnected
2018-06-14_13:19:00 UniFi initialized
2018-06-14_13:19:00 UniFi disconnected
2018-06-14_13:19:00 UniFi initialized
2018-06-14_13:19:00 UniFi disconnected
2018-06-14_13:19:00 UniFi initialized
2018-06-14_13:19:00 UniFi disconnected
2018-06-14_13:19:03 UniFi connected
2018-06-14_13:19:08 UniFi -UC_wlan_state: ok
2018-06-14_13:19:08 UniFi -UC_wlan_users: 15
2018-06-14_13:19:08 UniFi -UC_wlan_accesspoints: 1
2018-06-14_13:19:08 UniFi -UC_wlan_guests: 0
2018-06-14_13:19:08 UniFi -UC_unarchived_alerts: 1
2018-06-14_13:19:08 UniFi -UC_events: 3000 (last 24h)
2018-06-14_13:19:08 UniFi Poolpumpe_hostname: Poolpumpe
2018-06-14_13:19:08 UniFi Poolpumpe_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:08 UniFi Poolpumpe_uptime: 307089
2018-06-14_13:19:08 UniFi Poolpumpe_snr: 22
2018-06-14_13:19:08 UniFi Poolpumpe_essid: ATHome
2018-06-14_13:19:08 UniFi Poolpumpe_accesspoint: Unifi Wlan AP
2018-06-14_13:19:08 UniFi Poolpumpe: connected
2018-06-14_13:19:08 UniFi CarportCam_hostname: 192.168.2.151
2018-06-14_13:19:08 UniFi CarportCam_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:08 UniFi CarportCam_uptime: 321840
2018-06-14_13:19:08 UniFi CarportCam_snr: 18
2018-06-14_13:19:08 UniFi CarportCam_essid: ATHome
2018-06-14_13:19:08 UniFi CarportCam_accesspoint: Unifi Wlan AP
2018-06-14_13:19:08 UniFi CarportCam: connected
2018-06-14_13:19:08 UniFi Fronius_hostname: 192.168.2.163
2018-06-14_13:19:08 UniFi Fronius_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:08 UniFi Fronius_uptime: 1044299
2018-06-14_13:19:08 UniFi Fronius_snr: 27
2018-06-14_13:19:08 UniFi Fronius_essid: ATHome
2018-06-14_13:19:08 UniFi Fronius_accesspoint: Unifi Wlan AP
2018-06-14_13:19:08 UniFi Fronius: connected
2018-06-14_13:19:08 UniFi deckenlampe-7353_hostname: deckenlampe-7353
2018-06-14_13:19:08 UniFi deckenlampe-7353_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:08 UniFi deckenlampe-7353_uptime: 374034
2018-06-14_13:19:08 UniFi deckenlampe-7353_snr: 35
2018-06-14_13:19:08 UniFi deckenlampe-7353_essid: ATHome
2018-06-14_13:19:08 UniFi deckenlampe-7353_accesspoint: Unifi Wlan AP
2018-06-14_13:19:08 UniFi deckenlampe-7353: connected
2018-06-14_13:19:08 UniFi esstischlampe-7415_hostname: esstischlampe-7415
2018-06-14_13:19:08 UniFi esstischlampe-7415_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:08 UniFi esstischlampe-7415_uptime: 326157
2018-06-14_13:19:08 UniFi esstischlampe-7415_snr: 45
2018-06-14_13:19:08 UniFi esstischlampe-7415_essid: ATHome
2018-06-14_13:19:08 UniFi esstischlampe-7415_accesspoint: Unifi Wlan AP
2018-06-14_13:19:08 UniFi esstischlampe-7415: connected
2018-06-14_13:19:08 UniFi Honor_6X_hostname: Honor_6X
2018-06-14_13:19:08 UniFi Honor_6X_last_seen: 2018-06-14 13:16:23
2018-06-14_13:19:08 UniFi Honor_6X_uptime: 10076
2018-06-14_13:19:08 UniFi Honor_6X_snr: 8
2018-06-14_13:19:08 UniFi Honor_6X_essid: ATHome
2018-06-14_13:19:08 UniFi Honor_6X_accesspoint: Unifi Wlan AP
2018-06-14_13:19:08 UniFi Honor_6X: connected
2018-06-14_13:19:08 UniFi octopi_hostname: octopi
2018-06-14_13:19:08 UniFi octopi_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:08 UniFi octopi_uptime: 321835
2018-06-14_13:19:08 UniFi octopi_snr: 38
2018-06-14_13:19:08 UniFi octopi_essid: ATHome
2018-06-14_13:19:08 UniFi octopi_accesspoint: Unifi Wlan AP
2018-06-14_13:19:08 UniFi octopi: connected
2018-06-14_13:19:08 UniFi TL-WA860RE_hostname: TL-WA860RE
2018-06-14_13:19:08 UniFi TL-WA860RE_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:08 UniFi TL-WA860RE_uptime: 1044286
2018-06-14_13:19:08 UniFi TL-WA860RE_snr: 23
2018-06-14_13:19:08 UniFi TL-WA860RE_essid: ATHome
2018-06-14_13:19:08 UniFi TL-WA860RE_accesspoint: Unifi Wlan AP
2018-06-14_13:19:08 UniFi TL-WA860RE: connected
2018-06-14_13:19:08 UniFi FireTV-Stick_hostname: amazon-7e6a597e9
2018-06-14_13:19:08 UniFi FireTV-Stick_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:08 UniFi FireTV-Stick_uptime: 652914
2018-06-14_13:19:08 UniFi FireTV-Stick_snr: 20
2018-06-14_13:19:08 UniFi FireTV-Stick_essid: ATHome
2018-06-14_13:19:08 UniFi FireTV-Stick_accesspoint: Unifi Wlan AP
2018-06-14_13:19:08 UniFi FireTV-Stick: connected
2018-06-14_13:19:08 UniFi Ralfs-iPad_hostname: Ralfs-iPad
2018-06-14_13:19:08 UniFi Ralfs-iPad_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:08 UniFi Ralfs-iPad_uptime: 968341
2018-06-14_13:19:08 UniFi Ralfs-iPad_snr: 46
2018-06-14_13:19:08 UniFi Ralfs-iPad_essid: ATHome
2018-06-14_13:19:08 UniFi Ralfs-iPad_accesspoint: Unifi Wlan AP
2018-06-14_13:19:08 UniFi Ralfs-iPad: connected
2018-06-14_13:19:08 UniFi Alexa-Wohnzimmer_hostname: 192.168.2.42
2018-06-14_13:19:08 UniFi Alexa-Wohnzimmer_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:08 UniFi Alexa-Wohnzimmer_uptime: 438054
2018-06-14_13:19:08 UniFi Alexa-Wohnzimmer_snr: 36
2018-06-14_13:19:08 UniFi Alexa-Wohnzimmer_essid: ATHome
2018-06-14_13:19:08 UniFi Alexa-Wohnzimmer_accesspoint: Unifi Wlan AP
2018-06-14_13:19:08 UniFi Alexa-Wohnzimmer: connected
2018-06-14_13:19:08 UniFi Alexa-Kueche_hostname: amazon-98a3a0c3a
2018-06-14_13:19:08 UniFi Alexa-Kueche_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:08 UniFi Alexa-Kueche_uptime: 406789
2018-06-14_13:19:08 UniFi Alexa-Kueche_snr: 51
2018-06-14_13:19:08 UniFi Alexa-Kueche_essid: ATHome
2018-06-14_13:19:08 UniFi Alexa-Kueche_accesspoint: Unifi Wlan AP
2018-06-14_13:19:08 UniFi Alexa-Kueche: connected
2018-06-14_13:19:08 UniFi drucker-3062_hostname: drucker-3062
2018-06-14_13:19:08 UniFi drucker-3062_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:08 UniFi drucker-3062_uptime: 300747
2018-06-14_13:19:08 UniFi drucker-3062_snr: 15
2018-06-14_13:19:08 UniFi drucker-3062_essid: ATHome
2018-06-14_13:19:08 UniFi drucker-3062_accesspoint: Unifi Wlan AP
2018-06-14_13:19:08 UniFi drucker-3062: connected
2018-06-14_13:19:08 UniFi Honor_6X: disconnected
2018-06-14_13:19:08 UniFi HarmonyHub_hostname: HarmonyHub
2018-06-14_13:19:08 UniFi HarmonyHub_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:08 UniFi HarmonyHub_uptime: 1044314
2018-06-14_13:19:08 UniFi HarmonyHub_snr: 53
2018-06-14_13:19:08 UniFi HarmonyHub_essid: ATHome
2018-06-14_13:19:08 UniFi HarmonyHub_accesspoint: Unifi Wlan AP
2018-06-14_13:19:08 UniFi HarmonyHub: connected
2018-06-14_13:19:08 UniFi Poollicht_hostname: Poollicht
2018-06-14_13:19:08 UniFi Poollicht_last_seen: 2018-06-14 13:18:52
2018-06-14_13:19:08 UniFi Poollicht_uptime: 279549
2018-06-14_13:19:08 UniFi Poollicht_snr: 22
2018-06-14_13:19:08 UniFi Poollicht_essid: ATHome
2018-06-14_13:19:08 UniFi Poollicht_accesspoint: Unifi Wlan AP
2018-06-14_13:19:08 UniFi Poollicht: connected
2018-06-14_13:19:08 UniFi UC_newClients:
2018-06-14_13:19:08 UniFi -AP_Unifi Wlan AP_state: ok
2018-06-14_13:19:08 UniFi -AP_Unifi Wlan AP_clients: 15
2018-06-14_13:19:08 UniFi -AP_Unifi Wlan AP_essid: ATHome,Gast-WLAN,ATHome,Gast-WLAN
2018-06-14_13:19:08 UniFi -AP_Unifi Wlan AP_locate: off
2018-06-14_13:19:08 UniFi -WLAN_Gast-WLAN_state: enabled
2018-06-14_13:19:08 UniFi -WLAN_ATHome_state: enabled
2018-06-14_13:19:08 UniFi initialized
2018-06-14_13:19:08 UniFi disconnected
2018-06-14_13:19:08 UniFi initialized
2018-06-14_13:19:08 UniFi disconnected
2018-06-14_13:19:08 UniFi initialized
2018-06-14_13:19:08 UniFi disconnected
2018-06-14_13:19:08 UniFi initialized
2018-06-14_13:19:08 UniFi disconnected
2018-06-14_13:19:10 UniFi connected
2018-06-14_13:19:13 UniFi -UC_wlan_state: ok
2018-06-14_13:19:13 UniFi -UC_wlan_users: 15
2018-06-14_13:19:13 UniFi -UC_wlan_accesspoints: 1
2018-06-14_13:19:13 UniFi -UC_wlan_guests: 0
2018-06-14_13:19:13 UniFi -UC_unarchived_alerts: 1
2018-06-14_13:19:13 UniFi -UC_events: 3000 (last 24h)
2018-06-14_13:19:13 UniFi Poolpumpe_hostname: Poolpumpe
2018-06-14_13:19:13 UniFi Poolpumpe_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:13 UniFi Poolpumpe_uptime: 307103
2018-06-14_13:19:13 UniFi Poolpumpe_snr: 22
2018-06-14_13:19:13 UniFi Poolpumpe_essid: ATHome
2018-06-14_13:19:13 UniFi Poolpumpe_accesspoint: Unifi Wlan AP
2018-06-14_13:19:13 UniFi Poolpumpe: connected
2018-06-14_13:19:13 UniFi CarportCam_hostname: 192.168.2.151
2018-06-14_13:19:13 UniFi CarportCam_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:13 UniFi CarportCam_uptime: 321854
2018-06-14_13:19:13 UniFi CarportCam_snr: 19
2018-06-14_13:19:13 UniFi CarportCam_essid: ATHome
2018-06-14_13:19:13 UniFi CarportCam_accesspoint: Unifi Wlan AP
2018-06-14_13:19:13 UniFi CarportCam: connected
2018-06-14_13:19:13 UniFi Fronius_hostname: 192.168.2.163
2018-06-14_13:19:13 UniFi Fronius_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:13 UniFi Fronius_uptime: 1044313
2018-06-14_13:19:13 UniFi Fronius_snr: 27
2018-06-14_13:19:13 UniFi Fronius_essid: ATHome
2018-06-14_13:19:13 UniFi Fronius_accesspoint: Unifi Wlan AP
2018-06-14_13:19:13 UniFi Fronius: connected
2018-06-14_13:19:13 UniFi deckenlampe-7353_hostname: deckenlampe-7353
2018-06-14_13:19:13 UniFi deckenlampe-7353_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:13 UniFi deckenlampe-7353_uptime: 374048
2018-06-14_13:19:13 UniFi deckenlampe-7353_snr: 35
2018-06-14_13:19:13 UniFi deckenlampe-7353_essid: ATHome
2018-06-14_13:19:13 UniFi deckenlampe-7353_accesspoint: Unifi Wlan AP
2018-06-14_13:19:13 UniFi deckenlampe-7353: connected
2018-06-14_13:19:13 UniFi esstischlampe-7415_hostname: esstischlampe-7415
2018-06-14_13:19:13 UniFi esstischlampe-7415_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:13 UniFi esstischlampe-7415_uptime: 326171
2018-06-14_13:19:13 UniFi esstischlampe-7415_snr: 44
2018-06-14_13:19:13 UniFi esstischlampe-7415_essid: ATHome
2018-06-14_13:19:13 UniFi esstischlampe-7415_accesspoint: Unifi Wlan AP
2018-06-14_13:19:13 UniFi esstischlampe-7415: connected
2018-06-14_13:19:13 UniFi Honor_6X_hostname: Honor_6X
2018-06-14_13:19:13 UniFi Honor_6X_last_seen: 2018-06-14 13:16:23
2018-06-14_13:19:13 UniFi Honor_6X_uptime: 10076
2018-06-14_13:19:13 UniFi Honor_6X_snr: 8
2018-06-14_13:19:13 UniFi Honor_6X_essid: ATHome
2018-06-14_13:19:13 UniFi Honor_6X_accesspoint: Unifi Wlan AP
2018-06-14_13:19:13 UniFi Honor_6X: connected
2018-06-14_13:19:13 UniFi octopi_hostname: octopi
2018-06-14_13:19:13 UniFi octopi_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:13 UniFi octopi_uptime: 321849
2018-06-14_13:19:13 UniFi octopi_snr: 39
2018-06-14_13:19:13 UniFi octopi_essid: ATHome
2018-06-14_13:19:13 UniFi octopi_accesspoint: Unifi Wlan AP
2018-06-14_13:19:13 UniFi octopi: connected
2018-06-14_13:19:13 UniFi TL-WA860RE_hostname: TL-WA860RE
2018-06-14_13:19:13 UniFi TL-WA860RE_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:13 UniFi TL-WA860RE_uptime: 1044300
2018-06-14_13:19:13 UniFi TL-WA860RE_snr: 23
2018-06-14_13:19:13 UniFi TL-WA860RE_essid: ATHome
2018-06-14_13:19:13 UniFi TL-WA860RE_accesspoint: Unifi Wlan AP
2018-06-14_13:19:13 UniFi TL-WA860RE: connected
2018-06-14_13:19:13 UniFi FireTV-Stick_hostname: amazon-7e6a597e9
2018-06-14_13:19:13 UniFi FireTV-Stick_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:13 UniFi FireTV-Stick_uptime: 652928
2018-06-14_13:19:13 UniFi FireTV-Stick_snr: 25
2018-06-14_13:19:13 UniFi FireTV-Stick_essid: ATHome
2018-06-14_13:19:13 UniFi FireTV-Stick_accesspoint: Unifi Wlan AP
2018-06-14_13:19:13 UniFi FireTV-Stick: connected
2018-06-14_13:19:13 UniFi Ralfs-iPad_hostname: Ralfs-iPad
2018-06-14_13:19:13 UniFi Ralfs-iPad_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:13 UniFi Ralfs-iPad_uptime: 968355
2018-06-14_13:19:13 UniFi Ralfs-iPad_snr: 46
2018-06-14_13:19:13 UniFi Ralfs-iPad_essid: ATHome
2018-06-14_13:19:13 UniFi Ralfs-iPad_accesspoint: Unifi Wlan AP
2018-06-14_13:19:13 UniFi Ralfs-iPad: connected
2018-06-14_13:19:13 UniFi Alexa-Wohnzimmer_hostname: 192.168.2.42
2018-06-14_13:19:13 UniFi Alexa-Wohnzimmer_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:13 UniFi Alexa-Wohnzimmer_uptime: 438068
2018-06-14_13:19:13 UniFi Alexa-Wohnzimmer_snr: 36
2018-06-14_13:19:13 UniFi Alexa-Wohnzimmer_essid: ATHome
2018-06-14_13:19:13 UniFi Alexa-Wohnzimmer_accesspoint: Unifi Wlan AP
2018-06-14_13:19:13 UniFi Alexa-Wohnzimmer: connected
2018-06-14_13:19:13 UniFi Alexa-Kueche_hostname: amazon-98a3a0c3a
2018-06-14_13:19:13 UniFi Alexa-Kueche_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:13 UniFi Alexa-Kueche_uptime: 406803
2018-06-14_13:19:13 UniFi Alexa-Kueche_snr: 50
2018-06-14_13:19:13 UniFi Alexa-Kueche_essid: ATHome
2018-06-14_13:19:13 UniFi Alexa-Kueche_accesspoint: Unifi Wlan AP
2018-06-14_13:19:13 UniFi Alexa-Kueche: connected
2018-06-14_13:19:13 UniFi drucker-3062_hostname: drucker-3062
2018-06-14_13:19:13 UniFi drucker-3062_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:13 UniFi drucker-3062_uptime: 300761
2018-06-14_13:19:13 UniFi drucker-3062_snr: 15
2018-06-14_13:19:13 UniFi drucker-3062_essid: ATHome
2018-06-14_13:19:13 UniFi drucker-3062_accesspoint: Unifi Wlan AP
2018-06-14_13:19:13 UniFi drucker-3062: connected
2018-06-14_13:19:13 UniFi Honor_6X: disconnected
2018-06-14_13:19:13 UniFi HarmonyHub_hostname: HarmonyHub
2018-06-14_13:19:13 UniFi HarmonyHub_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:13 UniFi HarmonyHub_uptime: 1044328
2018-06-14_13:19:13 UniFi HarmonyHub_snr: 53
2018-06-14_13:19:13 UniFi HarmonyHub_essid: ATHome
2018-06-14_13:19:13 UniFi HarmonyHub_accesspoint: Unifi Wlan AP
2018-06-14_13:19:13 UniFi HarmonyHub: connected
2018-06-14_13:19:13 UniFi Poollicht_hostname: Poollicht
2018-06-14_13:19:13 UniFi Poollicht_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:13 UniFi Poollicht_uptime: 279563
2018-06-14_13:19:13 UniFi Poollicht_snr: 22
2018-06-14_13:19:13 UniFi Poollicht_essid: ATHome
2018-06-14_13:19:13 UniFi Poollicht_accesspoint: Unifi Wlan AP
2018-06-14_13:19:13 UniFi Poollicht: connected
2018-06-14_13:19:13 UniFi UC_newClients:
2018-06-14_13:19:13 UniFi -AP_Unifi Wlan AP_state: ok
2018-06-14_13:19:13 UniFi -AP_Unifi Wlan AP_clients: 15
2018-06-14_13:19:13 UniFi -AP_Unifi Wlan AP_essid: ATHome,Gast-WLAN,ATHome,Gast-WLAN
2018-06-14_13:19:13 UniFi -AP_Unifi Wlan AP_locate: off
2018-06-14_13:19:13 UniFi -WLAN_Gast-WLAN_state: enabled
2018-06-14_13:19:13 UniFi -WLAN_ATHome_state: enabled
2018-06-14_13:19:13 UniFi initialized
2018-06-14_13:19:13 UniFi disconnected
2018-06-14_13:19:13 UniFi initialized
2018-06-14_13:19:13 UniFi disconnected
2018-06-14_13:19:13 UniFi initialized
2018-06-14_13:19:13 UniFi disconnected
2018-06-14_13:19:13 UniFi initialized
2018-06-14_13:19:13 UniFi disconnected
2018-06-14_13:19:16 UniFi connected
2018-06-14_13:19:19 UniFi -UC_wlan_state: ok
2018-06-14_13:19:19 UniFi -UC_wlan_users: 15
2018-06-14_13:19:19 UniFi -UC_wlan_accesspoints: 1
2018-06-14_13:19:19 UniFi -UC_wlan_guests: 0
2018-06-14_13:19:19 UniFi -UC_unarchived_alerts: 1
2018-06-14_13:19:19 UniFi -UC_events: 3000 (last 24h)
2018-06-14_13:19:19 UniFi Poolpumpe_hostname: Poolpumpe
2018-06-14_13:19:19 UniFi Poolpumpe_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:19 UniFi Poolpumpe_uptime: 307103
2018-06-14_13:19:19 UniFi Poolpumpe_snr: 22
2018-06-14_13:19:19 UniFi Poolpumpe_essid: ATHome
2018-06-14_13:19:19 UniFi Poolpumpe_accesspoint: Unifi Wlan AP
2018-06-14_13:19:19 UniFi Poolpumpe: connected
2018-06-14_13:19:19 UniFi CarportCam_hostname: 192.168.2.151
2018-06-14_13:19:19 UniFi CarportCam_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:19 UniFi CarportCam_uptime: 321854
2018-06-14_13:19:19 UniFi CarportCam_snr: 19
2018-06-14_13:19:19 UniFi CarportCam_essid: ATHome
2018-06-14_13:19:19 UniFi CarportCam_accesspoint: Unifi Wlan AP
2018-06-14_13:19:19 UniFi CarportCam: connected
2018-06-14_13:19:19 UniFi Fronius_hostname: 192.168.2.163
2018-06-14_13:19:19 UniFi Fronius_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:19 UniFi Fronius_uptime: 1044313
2018-06-14_13:19:19 UniFi Fronius_snr: 27
2018-06-14_13:19:19 UniFi Fronius_essid: ATHome
2018-06-14_13:19:19 UniFi Fronius_accesspoint: Unifi Wlan AP
2018-06-14_13:19:19 UniFi Fronius: connected
2018-06-14_13:19:19 UniFi deckenlampe-7353_hostname: deckenlampe-7353
2018-06-14_13:19:19 UniFi deckenlampe-7353_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:19 UniFi deckenlampe-7353_uptime: 374048
2018-06-14_13:19:19 UniFi deckenlampe-7353_snr: 35
2018-06-14_13:19:19 UniFi deckenlampe-7353_essid: ATHome
2018-06-14_13:19:19 UniFi deckenlampe-7353_accesspoint: Unifi Wlan AP
2018-06-14_13:19:19 UniFi deckenlampe-7353: connected
2018-06-14_13:19:19 UniFi esstischlampe-7415_hostname: esstischlampe-7415
2018-06-14_13:19:19 UniFi esstischlampe-7415_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:19 UniFi esstischlampe-7415_uptime: 326171
2018-06-14_13:19:19 UniFi esstischlampe-7415_snr: 44
2018-06-14_13:19:19 UniFi esstischlampe-7415_essid: ATHome
2018-06-14_13:19:19 UniFi esstischlampe-7415_accesspoint: Unifi Wlan AP
2018-06-14_13:19:19 UniFi esstischlampe-7415: connected
2018-06-14_13:19:19 UniFi Honor_6X_hostname: Honor_6X
2018-06-14_13:19:19 UniFi Honor_6X_last_seen: 2018-06-14 13:16:23
2018-06-14_13:19:19 UniFi Honor_6X_uptime: 10076
2018-06-14_13:19:19 UniFi Honor_6X_snr: 8
2018-06-14_13:19:19 UniFi Honor_6X_essid: ATHome
2018-06-14_13:19:19 UniFi Honor_6X_accesspoint: Unifi Wlan AP
2018-06-14_13:19:19 UniFi Honor_6X: connected
2018-06-14_13:19:19 UniFi octopi_hostname: octopi
2018-06-14_13:19:19 UniFi octopi_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:19 UniFi octopi_uptime: 321849
2018-06-14_13:19:19 UniFi octopi_snr: 39
2018-06-14_13:19:19 UniFi octopi_essid: ATHome
2018-06-14_13:19:19 UniFi octopi_accesspoint: Unifi Wlan AP
2018-06-14_13:19:19 UniFi octopi: connected
2018-06-14_13:19:19 UniFi TL-WA860RE_hostname: TL-WA860RE
2018-06-14_13:19:19 UniFi TL-WA860RE_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:19 UniFi TL-WA860RE_uptime: 1044300
2018-06-14_13:19:19 UniFi TL-WA860RE_snr: 23
2018-06-14_13:19:19 UniFi TL-WA860RE_essid: ATHome
2018-06-14_13:19:19 UniFi TL-WA860RE_accesspoint: Unifi Wlan AP
2018-06-14_13:19:19 UniFi TL-WA860RE: connected
2018-06-14_13:19:19 UniFi FireTV-Stick_hostname: amazon-7e6a597e9
2018-06-14_13:19:19 UniFi FireTV-Stick_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:19 UniFi FireTV-Stick_uptime: 652928
2018-06-14_13:19:19 UniFi FireTV-Stick_snr: 25
2018-06-14_13:19:19 UniFi FireTV-Stick_essid: ATHome
2018-06-14_13:19:19 UniFi FireTV-Stick_accesspoint: Unifi Wlan AP
2018-06-14_13:19:19 UniFi FireTV-Stick: connected
2018-06-14_13:19:19 UniFi Ralfs-iPad_hostname: Ralfs-iPad
2018-06-14_13:19:19 UniFi Ralfs-iPad_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:19 UniFi Ralfs-iPad_uptime: 968355
2018-06-14_13:19:19 UniFi Ralfs-iPad_snr: 46
2018-06-14_13:19:19 UniFi Ralfs-iPad_essid: ATHome
2018-06-14_13:19:19 UniFi Ralfs-iPad_accesspoint: Unifi Wlan AP
2018-06-14_13:19:19 UniFi Ralfs-iPad: connected
2018-06-14_13:19:19 UniFi Alexa-Wohnzimmer_hostname: 192.168.2.42
2018-06-14_13:19:19 UniFi Alexa-Wohnzimmer_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:19 UniFi Alexa-Wohnzimmer_uptime: 438068
2018-06-14_13:19:19 UniFi Alexa-Wohnzimmer_snr: 36
2018-06-14_13:19:19 UniFi Alexa-Wohnzimmer_essid: ATHome
2018-06-14_13:19:19 UniFi Alexa-Wohnzimmer_accesspoint: Unifi Wlan AP
2018-06-14_13:19:19 UniFi Alexa-Wohnzimmer: connected
2018-06-14_13:19:19 UniFi Alexa-Kueche_hostname: amazon-98a3a0c3a
2018-06-14_13:19:19 UniFi Alexa-Kueche_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:19 UniFi Alexa-Kueche_uptime: 406803
2018-06-14_13:19:19 UniFi Alexa-Kueche_snr: 50
2018-06-14_13:19:19 UniFi Alexa-Kueche_essid: ATHome
2018-06-14_13:19:19 UniFi Alexa-Kueche_accesspoint: Unifi Wlan AP
2018-06-14_13:19:19 UniFi Alexa-Kueche: connected
2018-06-14_13:19:19 UniFi drucker-3062_hostname: drucker-3062
2018-06-14_13:19:19 UniFi drucker-3062_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:19 UniFi drucker-3062_uptime: 300761
2018-06-14_13:19:19 UniFi drucker-3062_snr: 15
2018-06-14_13:19:19 UniFi drucker-3062_essid: ATHome
2018-06-14_13:19:19 UniFi drucker-3062_accesspoint: Unifi Wlan AP
2018-06-14_13:19:19 UniFi drucker-3062: connected
2018-06-14_13:19:19 UniFi Honor_6X: disconnected
2018-06-14_13:19:19 UniFi HarmonyHub_hostname: HarmonyHub
2018-06-14_13:19:19 UniFi HarmonyHub_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:19 UniFi HarmonyHub_uptime: 1044328
2018-06-14_13:19:19 UniFi HarmonyHub_snr: 53
2018-06-14_13:19:19 UniFi HarmonyHub_essid: ATHome
2018-06-14_13:19:19 UniFi HarmonyHub_accesspoint: Unifi Wlan AP
2018-06-14_13:19:19 UniFi HarmonyHub: connected
2018-06-14_13:19:19 UniFi Poollicht_hostname: Poollicht
2018-06-14_13:19:19 UniFi Poollicht_last_seen: 2018-06-14 13:19:06
2018-06-14_13:19:19 UniFi Poollicht_uptime: 279563
2018-06-14_13:19:19 UniFi Poollicht_snr: 22
2018-06-14_13:19:19 UniFi Poollicht_essid: ATHome
2018-06-14_13:19:19 UniFi Poollicht_accesspoint: Unifi Wlan AP
2018-06-14_13:19:19 UniFi Poollicht: connected
2018-06-14_13:19:19 UniFi UC_newClients:
2018-06-14_13:19:19 UniFi -AP_Unifi Wlan AP_state: ok
2018-06-14_13:19:19 UniFi -AP_Unifi Wlan AP_clients: 15
2018-06-14_13:19:19 UniFi -AP_Unifi Wlan AP_essid: ATHome,Gast-WLAN,ATHome,Gast-WLAN
2018-06-14_13:19:19 UniFi -AP_Unifi Wlan AP_locate: off
2018-06-14_13:19:19 UniFi -WLAN_Gast-WLAN_state: enabled
2018-06-14_13:19:19 UniFi -WLAN_ATHome_state: enabled
2018-06-14_13:19:19 UniFi initialized
2018-06-14_13:19:19 UniFi disconnected
2018-06-14_13:19:19 UniFi initialized
2018-06-14_13:19:19 UniFi disconnected
2018-06-14_13:19:19 UniFi initialized
2018-06-14_13:19:19 UniFi disconnected
2018-06-14_13:19:19 UniFi initialized
2018-06-14_13:19:19 UniFi disconnected
2018-06-14_13:19:23 UniFi connected
2018-06-14_13:19:27 UniFi -UC_wlan_state: ok
2018-06-14_13:19:27 UniFi -UC_wlan_users: 15
Für mich sieht es so aus, als ob die Alarmierung in einer Endlosschleife hängt. Habe mal nach "Alarm 7" gefiltert:
Line 003: 2018.06.14 13:18:45 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 004: 2018.06.14 13:18:45 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 009: 2018.06.14 13:18:49 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
Line 015: 2018.06.14 13:18:50 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 016: 2018.06.14 13:18:50 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 022: 2018.06.14 13:18:54 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
Line 028: 2018.06.14 13:18:55 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 029: 2018.06.14 13:18:55 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 035: 2018.06.14 13:19:01 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
Line 041: 2018.06.14 13:19:02 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 042: 2018.06.14 13:19:02 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 048: 2018.06.14 13:19:08 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
Line 054: 2018.06.14 13:19:09 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 055: 2018.06.14 13:19:09 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 061: 2018.06.14 13:19:13 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
Line 067: 2018.06.14 13:19:14 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 068: 2018.06.14 13:19:14 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 074: 2018.06.14 13:19:20 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
Line 080: 2018.06.14 13:19:21 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 081: 2018.06.14 13:19:21 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 088: 2018.06.14 13:19:27 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
Line 094: 2018.06.14 13:19:28 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 095: 2018.06.14 13:19:28 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 103: 2018.06.14 13:19:33 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
Line 109: 2018.06.14 13:19:34 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 110: 2018.06.14 13:19:34 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 116: 2018.06.14 13:19:38 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
Line 122: 2018.06.14 13:19:39 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 123: 2018.06.14 13:19:39 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 129: 2018.06.14 13:19:44 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
Line 135: 2018.06.14 13:19:45 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 136: 2018.06.14 13:19:45 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 144: 2018.06.14 13:19:52 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
Line 228: 2018.06.14 13:21:31 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
Line 240: 2018.06.14 13:21:32 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 241: 2018.06.14 13:21:32 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 330: 2018.06.14 13:21:37 3: alarm7.disarm.N return value: [Alarm 7] disarmed from alarmSensor AlarmDisArm with event on
Line 342: 2018.06.14 13:21:38 1: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 343: 2018.06.14 13:21:38 3: alarm7.arm.N return value: [Alarm 7] will be armed from alarmSensor AlarmArm with event on, delay 0:30
Line 433: 2018.06.14 13:22:08 3: [Alarm 7] armed from alarmSensor AlarmArm with event delay
Line 434: 2018.06.14 13:22:08 3: alarm7.arm.dly: [Alarm 7] armed from alarmSensor AlarmArm with event delay
Denke nicht dass das so richtig ist.
Erst die letzten beiden Zeilen sind irgendwie anders.
Hast du in der Mitte etwas weggelassen? Ab 13:19:52?
Der RasPi bekommt dadurch voraussichtlich zuviel Last und kann die Login-Antworten der Unifi-Controller-API nicht mehr früh genug verarbeiten. Das Modul denkt dann, der Controller ist nicht erreichbar und stellt sich auf initialized. Das kommt dann so oft, da mehrere API-Calls direkt hintereinander erfolgen. Und jeder bekommt keine Antwort. Die Meldungen initialized/disconnected innerhalb einer Sekunde gehören alle zu einem Update-Intervall.
Ja ich habe was weggelassen da ich nicht soviel posten konnte. Das Forum hatte immer abgeschnitten, des wegen habe ich die Mitte weggelassen da sich das immer wiederholt und das Ende hinzugefügt.
Ich weiss nur, dass ich das vor dem Update nicht hatte.
An dem AlarmModul kann ich auch nichts ändern.
Ah gerade ausprobiert wieder das Problem
i@raspberrypi:~ $ top
top - 21:20:04 up 1 day, 14:01, 1 user, load average: 0,56, 0,27, 0,18
Tasks: 158 total, 1 running, 157 sleeping, 0 stopped, 0 zombie
%Cpu(s): 14,8 us, 2,7 sy, 0,0 ni, 81,0 id, 1,3 wa, 0,0 hi, 0,2 si, 0,0 st
KiB Mem : 949572 total, 58304 free, 295700 used, 595568 buff/cache
KiB Swap: 102396 total, 102348 free, 48 used. 532428 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4414 fhem 20 0 90732 83828 7372 S 37,4 8,8 16:19.70 perl
727 pihole 20 0 74624 20440 2216 S 5,8 2,2 64:32.36 pihole-FTL
6725 www-data 20 0 66608 18892 15544 S 4,2 2,0 0:00.13 php
6748 www-data 20 0 66608 18404 15104 S 3,2 1,9 0:00.10 php
739 fhem 20 0 104640 41736 20904 S 1,0 4,4 3:18.69 homebridge
6610 pi 20 0 8644 3304 2792 R 1,0 0,3 0:00.69 top
6749 fhem 20 0 90732 79228 2772 S 1,0 8,3 0:00.03 perl
6590 pi 20 0 11520 4184 3436 S 0,6 0,4 0:00.07 sshd
93 root 20 0 0 0 0 S 0,3 0,0 0:10.37 jbd2/mmcblk0p2-
112 root 20 0 29272 6860 6412 S 0,3 0,7 2:55.90 systemd-journal
969 pi 20 0 131896 40648 20044 S 0,3 4,3 2:32.64 alexa
4309 root 20 0 0 0 0 S 0,3 0,0 0:00.18 kworker/u8:2
6399 root 20 0 0 0 0 S 0,3 0,0 0:00.01 kworker/3:1
6750 fhem 20 0 5328 708 604 S 0,3 0,1 0:00.01 ping
1 root 20 0 28252 6200 4840 S 0,0 0,7 3:28.75 systemd
2 root 20 0 0 0 0 S 0,0 0,0 0:00.16 kthreadd
3 root 20 0 0 0 0 S 0,0 0,0 0:11.73 ksoftirqd/0
5 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/0:0H
7 root 20 0 0 0 0 S 0,0 0,0 0:58.99 rcu_sched
8 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcu_bh
9 root rt 0 0 0 0 S 0,0 0,0 0:01.46 migration/0
10 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 lru-add-drain
11 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/0
12 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/1
13 root rt 0 0 0 0 S 0,0 0,0 0:01.44 migration/1
14 root 20 0 0 0 0 S 0,0 0,0 0:01.63 ksoftirqd/1
16 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/1:0H
17 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/2
18 root rt 0 0 0 0 S 0,0 0,0 0:02.21 migration/2
19 root 20 0 0 0 0 S 0,0 0,0 0:04.39 ksoftirqd/2
21 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/2:0H
22 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/3
23 root rt 0 0 0 0 S 0,0 0,0 0:01.37 migration/3
24 root 20 0 0 0 0 S 0,0 0,0 0:02.78 ksoftirqd/3
26 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/3:0H
27 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kdevtmpfs
28 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 netns
29 root 20 0 0 0 0 S 0,0 0,0 0:00.19 khungtaskd
30 root 20 0 0 0 0 S 0,0 0,0 0:00.00 oom_reaper
31 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 writeback
32 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kcompactd0
33 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 crypto
34 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 bioset
35 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kblockd
36 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 watchdogd
Wurde denn nur das Unifi-Modul upgedated?
Der Pi ist auf jeden Fall zu sehr unter Last.
Wie ist das Update-Interval des Unifi-Moduls? Ggf. mal verlängern.
Hi,
mir ist in den Logs des unifi-Controllers etwas merkwürdiges aufgefallen:
Admin Admin fhemadmin log in from 192.168.0.48 3:05 15.06.2018
Admin Admin fhemadmin log in from 192.168.0.48 3:05 15.06.2018
Admin Admin fhemadmin log in from 192.168.0.48 3:05 15.06.2018
Admin Admin fhemadmin log in from 192.168.0.48 3:05 15.06.2018
Admin Admin fhemadmin log in from 192.168.0.48 3:05 15.06.2018
Admin Admin fhemadmin log in from 192.168.0.48 3:05 15.06.2018
Admin Admin fhemadmin log in from 192.168.0.48 3:05 15.06.2018
Admin Admin fhemadmin log in from 192.168.0.48 3:05 15.06.2018
Admin Admin fhemadmin log in from 192.168.0.48 3:05 15.06.2018
Admin Admin fhemadmin log in from 192.168.0.48 3:05 15.06.2018
Admin Admin fhemadmin log in from 192.168.0.48 3:05 15.06.2018
Admin Admin fhemadmin log in from 192.168.0.48 3:05 15.06.2018
Admin Admin fhemadmin log in from 192.168.0.48 3:05 15.06.2018
Admin Admin fhemadmin log in from 192.168.0.48 3:05 15.06.2018
Um 03:05 finden "massive" logins seitens meines FHEM-Rechners zum Controller statt (rein zufällig der gleiche Rechner, aber das tut ja nichts zur Sache). Was mich wundert: Um diese Uhrzeit läuft auf meinem Rechner nichts. Außer: Die Rollladensteuerung (von Cluni) mit Komfortfunktionen erzeugt die Timer für die nächsten 24h, wann die Rollladen rauf / runter gefahren werden.
Any ideas? Drehe jetzt mal das Logging auf, aber vielleicht hat ja jemand eine Idee?
Hi,
Kannst du das reproduzieren, wenn du den Controller stoppst und nach Abwarten eines Intervals wieder startest. Müsste dasselbe Log erzeugen. Vermutlich ist zur der Zeit das Login-Cookie abgelaufen.
Zitat von: Wuehler am 15 Juni 2018, 11:24:17
Hi,
Kannst du das reproduzieren, wenn du den Controller stoppst und nach Abwarten eines Intervals wieder startest. Müsste dasselbe Log erzeugen. Vermutlich ist zur der Zeit das Login-Cookie abgelaufen.
Hi,
habe den Controller jetzt mal für 10 Minuten unterbrochen - mal sehen, ob die Meldung so morgen wieder genau um 3:05 auftaucht... ist jeden Tag um 3:05 im Controller-Log. Verbose drehe ich heute abend mal hoch, um entsprechend mitzuschneiden...
Sind die Meldungen auch jetzt direkt nach der Unterbrechung im Log?
Du könntest dir sonst mal ein at bauen, dass einmalig um 3:00 Uhr das verbose auf dem global-Device auf 5 setzt und um 03:10 wieder zurück. Vielleicht sieht man im fhem-log dann einen Hinweis auf den Grund.
Das es jeden Tag ist war mir nach dem ersten post nicht klar.
Kannst du die Timer durch die Cluni auch mal jetzt erzeugen lassen? Und wenn ja: kommen dann auch die Meldungen?
Im Unifi-Modul gibt es nichts, dass um 03:05 einen Messenlogin verursacht. Müssten andere ja dann auch haben.
Wie bei Benny33 tippe ich eher darauf, dass die Meldungen des Unifi-Moduls nur Symptom sind. Die eigentliche Störung liegt woanders.
Zitat von: Wuehler am 15 Juni 2018, 15:03:37
Sind die Meldungen auch jetzt direkt nach der Unterbrechung im Log?
Du könntest dir sonst mal ein at bauen, dass einmalig um 3:00 Uhr das verbose auf dem global-Device auf 5 setzt und um 03:10 wieder zurück. Vielleicht sieht man im fhem-log dann einen Hinweis auf den Grund.
Nope, die Meldungen waren nach der Unterbrechung nicht im Log - und auch nicht nach Reboots o.ä. - aber immer 3:05. Den Timer für heute Nacht habe ich schon angelegt ;-) Sollte helfen.
Und den anderen Timer führe ich jetzt gleich mal aus - und siehe da: In der Tat 12-14 Einträge im Log.
Strange.
Also rein in den Perl-Code.
Danke derweil ;-)
Leg mal ein device von freezmon an, wenn du den Timerlauf startest. Vielleicht hilft das der Ursache näherzukommen.
Hallo,
morgen im Update ein kleines Bugfix in der Notify-Funktion. Bisher wurde ein disconnect der Verbindung zum Unifi-Controller bei jedem define (egal welches device) durchgeführt. Dies erfolgt jetzt nur noch bei einem defmod des Unifi-devices.
Schönes Wochenende,
Dirk
Zitat von: Wuehler am 13 Juni 2018, 15:29:55
@Matze: hilft das neu eingebaute Reading für neue Clients? Wenn nein würde ich es bald wieder ausbauen. Ohne Nutzer einer Funktion braucht die Funktion nicht die Performance verbrauchen.
Hey, erstmal vielen Dank. Habe die Antwort leider erst jetzt gelesen.
Das scheint schonmal zu klappen, muss mir jetzt nur mal zurechtbauen wie er da ein notify an Telegram draus macht :)
Das ist mir noch nicht ganz klar.
Gruß
Matze
Versuchs über den Eventmonitor:
https://wiki.fhem.de/wiki/Event_monitor (https://wiki.fhem.de/wiki/Event_monitor)
Wenn es läuft poste mal das Notify (für andere zum kopieren)
VG,
Dirk
Hallo Zusammen
ich betreibe mit dem UNIFI eine Anwesenheitserkennung, wie viele anderen auch.
leider bleiben bei mir in den readings die Benützer als connected markiert obwohl diese schon lange, bis zu einigen Tagen gar nicht mehr anwesend sind.
nun hatte ich versucht die Zeit aus dem reading last_seen zur Berechnung zu verwenden, klappt auch sehr gut, nur leider wird dieses Zeit auch nicht richtig akutalisiert.
wie bekomme ich, deffinitiv nicht anwesende, Geräte aus den readings entfernt bzw wie kann ich die "connectet" und "last_seen" besser aktualisieren.
danke für Eure Tipps
Hallo Dirk,
wäre es eventuell möglich in den Readings zusätzlich zum Hostname auch noch die jeweilige MAC-Adresse der Clients anzuzeigen? Ich habe in meinem Gast-WLAN verschiedene berechtigte Nutzer, die leider alle in ihrem Handy die Standardhostnames belassen. Da ist es schwierig zwischen den einzelnen Clients zu unterscheiden.
Gruß
Wolle
Hallo,
Ich bin aktuell nicht im Lande, daher kann ich keinen richtigen Support geben. Nur kurz:
@australien: wenn ich mich richtig erinnere gab es so eine Fehlerbeschreibung in diesem Thread schonmal. Hoffentlich mit Lösung ;) kann mit dem Handy selbst nicht so gut suchen.
@Wolle: Im Thread zum UnifiSwitch wurde schon über ein Redesign zu den Unifi-Clients diskutiert. Wäre das nächste Thema dass ich mal angehen werde. Werde dazu bald einen eigenen Thread eröffnen da können wir über Umsetzungsalternativen erstmal diskutieren. Habe da aus der letzten Diskussion schon ein paar Ideen bekommen. Das Problem bei deiner Anforderung ist, dass es für viele schon jetzt zu viele Readings gibt Man kann die MAC zwar einfach hinzufügen, das würde aber viele andere User stören. Als Workaround sollte auch funktionieren, wenn du die Clients im Unifi-Controller selbst umbenennst (zB Mac als Name).
Viele Grüße aus Europa,
Dirk
EDIT: hab das DOIF mal auf die neueste Version angepasst
Moin Dirk,
Erst einmal vielen Dank für dein Modul. Super Sache.
Ich nutze das neue Reading intensiv. Funktioniert super.
Hier mal der DEF vom DOIF
([myunifi:-UC_newClients] ne "" ) (set telebot message unbekannter WLAN Zugriff:[myunifi:-UC_newClients])
Also bitte nach Möglichkeit nicht rausnehmen ;)
Vielleicht kann Matze damit auch was anfangen.
Was ich noch vermisse ist die Auslastung der einzelnen Kanäle eines APs in Prozent.
Ach und schönen Urlaub :)
Hi,
@maui: Danke für das DOIF. Habe ich mir auch mal definiert. Ich habe das Modul übrigens von rapster übernommen.
@australien: Evtl. musst du mal mit
set <myunifi> clear all
die Moduldaten zurücksetzen. Und dann beobachten, wann es das nächste Mal passiert und versuchen, es nachzustellen.
@all: Findet sich evtl. mal jemand, der einen WIKI-Artikel mit Beispielen der Nutzung aufsetzt? Oder wie man bei manchen Problemen diese wieder in den Griff bekommen kann.
VG,
Dirk
@wuehler: ansich denke ich fast, dass ein Wiki-Artikel überflüssig ist, da die commandref ja gepflegt ist und die Einrichtung ansich ja echt easy ist. Aber vielleicht habe ich bald mal die Muße, will aber nix versprechen. Eine Hilfe bei Standard Problemen finde ich immer schwierig, vor allem wenn man Sie nur von Dritten aus dem Thread liest.
@australien: bei mir klappt das mit connected super, muss bei dir irgendwas krud sein.
EDIT: @Wuehler: Ist zwar eine Winzigkeit, aber ich würde dem Reading mit dem "UC_newClients" ein - voranstellen, dann findet man es auch schneller neben dem Rest.
Hey @Wuehler: Ich nochmal ;)
Ich hab bzgl. der Auslastung mal im Modul geguckt, und es gab ja mal die Utilization.
Allerdings scheint die mittlerweile in der API von Unifi verschoben worden zu sein.
Ich hab dazu mal etwas im Modul gebastelt.
Habe mich dabei an die essid vom Stil her gehalten. Man könnte natürlich auch die Auslastung der einzelnen Kanäle als einzelne Readings anzeigen.
Alternativ könnte man auch drüber nachdenken, die Readings eines WLAN-Geräts in ein Reading zu packen, allerdings würde ich eine Semikolon einem Komma (als Trennzeichen) stark vorziehen.
Würde immerhin die Readings an der Stelle um Faktor 7 minimieren. Aber gleichzeitig einige User abhängen bzw. diese müssten dann wieder mit userReadings arbeiten, aber könnten sich gezielt den für sie wichtigen Part rauspicken.
Was mir noch im Modul aufgefallen ist, ist accespoint (statt accesspoint). Ist klein-Kram, aber wenn ein 3. was am Code ändert, tippt er es bestimmt falsch ein ;)
Wenn du magst, kannst du meinen Code gerne noch ein wenig anpassen und dann einchecken. Ich persönlich find die Auslastung ganz interessant, zumal man in der iOS App sich die Auslastung nicht als Graph anzeigen lassen kann (Browser schon) und so relativ einfach eine telegram-Nachricht bauen kann, wenn das Netz überlastet ist.
###############################################################################
sub Unifi_SetAccesspointReadings($) {
my ($hash) = @_;
my ($name,$self) = ($hash->{NAME},Unifi_Whoami());
Log3 $name, 5, "$name ($self) - executed.";
my ($apName,$apRef,$essid);
my $utiliz;
for my $apID (keys %{$hash->{accespoints}}) {
$essid = '';
$utiliz = '';
$apRef = $hash->{accespoints}->{$apID};
$apName = ($apRef->{name}) ? $apRef->{name} : $apRef->{ip};
if (defined $apRef->{vap_table} && scalar @{$apRef->{vap_table}}) {
for my $vap (@{$apRef->{vap_table}}) {
$essid .= makeReadingName($vap->{essid}).',';
}
$essid =~ s/.$//;
} else {
my $essid = 'none';
}
if (defined $apRef->{'radio_table_stats'} ) {
for my $rts (@{$apRef->{'radio_table_stats'}}) {
$utiliz .= makeReadingName($rts->{'cu_total'}).',';
}
$utiliz =~ s/.$//;
} else {
my $utiliz = 'none';
}
readingsBulkUpdate($hash,'-AP_'.$apName.'_state',($apRef->{state} == 1) ? 'ok' : 'error');
readingsBulkUpdate($hash,'-AP_'.$apName.'_clients',$apRef->{'num_sta'});
if( $apRef->{type} eq 'uap' ) {
readingsBulkUpdate($hash,'-AP_'.$apName.'_essid',$essid);
readingsBulkUpdate($hash,'-AP_'.$apName.'_utilization',$utiliz);
# readingsBulkUpdate($hash,'-AP_'.$apName.'_utilizationNA',$apRef->{'na_cu_total'}) if( defined($apRef->{'na_cu_total'}) );
# readingsBulkUpdate($hash,'-AP_'.$apName.'_utilizationNG',$apRef->{'ng_cu_total'}) if( defined($apRef->{'ng_cu_total'}) );
}
readingsBulkUpdate($hash,'-AP_'.$apName.'_locate',(!defined $apRef->{locating}) ? 'unknown' : ($apRef->{locating}) ? 'on' : 'off');
my $poe_power;
for my $port (@{$apRef->{port_table}}) {
next if( !$port->{port_poe} );
$poe_power += $port->{poe_power} if( defined($port->{poe_power}) );
}
readingsBulkUpdate($hash,'-AP_'.$apName.'_poePower', $poe_power) if( defined($poe_power) );
# readingsBulkUpdate($hash,'-AP_'.$apName.'_guests',$apRef->{'guest-num_sta'});
# readingsBulkUpdate($hash,'-AP_'.$apName.'_users',$apRef->{'user-num_sta'});
# readingsBulkUpdate($hash,'-AP_'.$apName.'_last_seen',$apRef->{'last_seen'});
}
return undef;
}
Zitat von: Wuehler am 19 Juli 2018, 13:48:46
@australien: Evtl. musst du mal mit
set <myunifi> clear all
die Moduldaten zurücksetzen. Und dann beobachten, wann es das nächste Mal passiert und versuchen, es nachzustellen.
hab das Ganze versucht und den PI upgedatet, die aktuelle Version den Unifi Controllers ist nun 5.8.24-11016
sieht zur Zeit nicht schlecht aus, wobei die Zeitstempeln und der Inhalt des last_seen readings noch nicht mit dem Status des connected zusammen stimmen.
Werde das ganze weiter verfolgen.
zB. bei einer Systemzeit um 21.07.2018 19:33
HUAWEI_P9_lite_2017-fd983 connected 2018-07-21 18:11:38
HUAWEI_P9_lite_2017-fd983_accesspoint Wohnzimmer 2018-07-21 18:11:38
HUAWEI_P9_lite_2017-fd983_essid home 2018-07-21 18:11:38
HUAWEI_P9_lite_2017-fd983_hostname HUAWEI_P9_lite_2017-fd983 2018-07-21 18:11:38
HUAWEI_P9_lite_2017-fd983_last_seen 2018-07-21 18:11:24 2018-07-21 18:11:38
HUAWEI_P9_lite_2017-fd983_snr 24 2018-07-21 18:11:38
HUAWEI_P9_lite_2017-fd983_uptime 266685 2018-07-21 18:11:38
danke für eure Hints
Hey australien,
Laufen fhem und der unificontroller auf demselben PI? Ist im Unificontroller evtl. Eine andere Zeitzone ausgewählt? Und wie groß ist dein Aktualisierungsintervall gesetzt?
EDIT: Das Reading last_seen erhält die Daten aus dem Unifi-Controller. Die angezeigte Zeit muss immer kleiner sein, als der Reading_Timestamp, da sich das Modul ja nur im festgelegten Intervall neue Daten zieht. Ausserdem braucht es für die Verarbeitung Zeit bis das Reading dann am Ende gesetzt wird.
Der connected-Status wird aus den gelieferten Daten interpretiert: Wenn Client-daten vom Unifi-Controller geliefert werden, dann = connected. Wenn dann irgendwann keine Daten mehr kommen wird der Client im Modul nicht gelöscht (wie im Unifi bei der Devices-Ansicht, man sieht den client dann nur noch in den Insights), sondern auf disconnected gesetzt.
VG,
Dirk
Hey Maui,
das fehlende - bei UC_newClients ist ein Bug. Werde ich mal fixen. So viele nutzen es ja noch nicht, daher ist bei euch der Anpassungsaufwand gering.
Deinen Code zur utilization habe ich mir angesehen. Die Readings kommen seit den ersten Versionen des Moduls mit NG und NA. Mich selbst haben sie bisher nicht interessiert. Warum entfernst du die alten Readings zu utilization? Was bedeutet das neue Reading (Doku für commandref) im Gegensatz zu den alten Readings?
Bei mir bleibt das neue Reading immer leer.
VG,
Dirk
Wenn Du schon im Code wühlst - Wuehler
ich hab da noch was...
2018.07.21 21:40:17 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/74_UnifiSwitch.pm line 135.
Hi Lolo,
probier mal die angehängte Version ...
Das würde ich lieber über den update Prozess machen...
Ich kann es bei mir nicht nachstellen und brauche daher nen Tester. Einfach ins FHEM-Verzeichnis kopieren und in FHEMWEB "reload 74_UnifiSwitch.pm" aufrufen.
Nachstellen kann ich es glaube ich auch nicht - ich vermute das es damit zusammenhängt das beim letztem FHEM neustart der switch nicht verbunden war.
Sorry FHEM läuft bei mir auf einer Synology DS ich tausche dort ungerne Dateien hin und her...
Hey Wuehler,
Ich hatte (fälschlicherweise) angenommen, dass das JSON im UNMS geändert wurde. Bei mir ist es nämlich genau anders herum, die alten readings mit NG und NA werden nicht geladen. Sonst hätte ich das ja gar nicht angefasst. Liegt aber vermutlich dann an meinen APs, habe die AP AC LR. Hat jemand anders die gleichen, und kann bestätigen, dass bei ihm die utilizationNA/NG nicht gefüllt wird?
Wenn es da wirklich Unterschiede gibt, könnte man ja auch über das Model gehen.
Hey Maui,
das mit der Änderung am json kann sein. Welche Controller-Version läuft bei dir? Ich bin noch auf 5.6.37.
Ich bin auf der neuesten. 5.8.24 dürfte das sein. Hab direkt am Controller per Browser den json angeschaut.
Jetzt brauche ich mal ne schnelle Unterstützung. Bei mir auf raspian wird kein update größer als 5.6.39 angeboten. Was musste man anpassen?
Hast du in deinen Sources
deb http://www.ubnt.com/downloads/unifi/debian stable ubiquiti
Habe das mit docker gemacht.
https://github.com/oznu/docker-unms/blob/master/README.md
Danke. Mein Eintrag in den sources war tatsächlich nicht korrekt um auf 5.7ff zu kommen. Bin jetzt unter 5.8.24 und habe dasselbe Verhalten wie du. Hat sich also wirklich was im JSON geändert. Ich überlege mal, wie man das am Besten umsetzt.
ACHTUNG: Ab morgen nach einem UPDATE müssen einige evtl. etwas anpassen!
- Readingname -UC_newClients korrigiert (es fehlte das führende -)
- Wenn ihr das AP-Reading utilizationNA oder utilizationNG nutzt und auf eine Unifi-Controller-Version ab 3.7.x upgraded wird sich der Readingname auf utilization ändern.
-> Diese Änderung ist aufgrund einer Änderung im Unifi-Controller notwendig
Ausserdem:
- Im 74_UnifiSwitch: Abfangen eines kleines Fehlers
Moin. Die 3.0.4 scheint es nicht ins Repo geschafft zu haben :o
Oder wann läuft der batch Job nachts durch?
Moin,
Im Repo ist sie: https://svn.fhem.de/fhem/trunk/fhem/FHEM/74_Unifi.pm (https://svn.fhem.de/fhem/trunk/fhem/FHEM/74_Unifi.pm)
Vielleicht gab es heute Nacht Probleme im Update-Job?
Ja gesehen hatte ich das auch schon gestern. Dachte erst es läge an mir und meiner geänderten Modul-Datei. Naja warten wir einfach mal morgen ab. :)
Ich glaube 8 Uhr wird es immer rübergeschoben.
Zitat von: Wuehler am 23 Juli 2018, 06:57:58
Vielleicht gab es heute Nacht Probleme im Update-Job?
Nein.
https://fhem.de/commandref.html#update
ZitatThe files are automatically transferred from the source repository (SVN) to the web site once a day, at 7:45 CET / CEST.
Danke euch, wieder was dazu gelernt.
Bei mir ist die Version im Update enthalten. Hast du sie vielleicht doch bekommen und es funktioniert nur etwas nicht (wie erwartet)?
Achso Sorry dachte war klar. Hat jetzt geklappt. Update kam ja erst 7:45
;D ah. Jetzt ists klar. Bin heute deutlich früher aufgestanden als normal und hatte die Uhrzeit nicht im Blick. Kam mir alles schon viel später vor ::)
Zitat von: Wuehler am 21 Juli 2018, 21:47:30
Hey australien,
Laufen fhem und der unificontroller auf demselben PI? Ist im Unificontroller evtl. Eine andere Zeitzone ausgewählt? Und wie groß ist dein Aktualisierungsintervall gesetzt?
EDIT: Das Reading last_seen erhält die Daten aus dem Unifi-Controller. Die angezeigte Zeit muss immer kleiner sein, als der Reading_Timestamp, da sich das Modul ja nur im festgelegten Intervall neue Daten zieht. Ausserdem braucht es für die Verarbeitung Zeit bis das Reading dann am Ende gesetzt wird.
Der connected-Status wird aus den gelieferten Daten interpretiert: Wenn Client-daten vom Unifi-Controller geliefert werden, dann = connected. Wenn dann irgendwann keine Daten mehr kommen wird der Client im Modul nicht gelöscht (wie im Unifi bei der Devices-Ansicht, man sieht den client dann nur noch in den Insights), sondern auf disconnected gesetzt.
VG,
Dirk
Es läuft alles auf dem PI und der UnifiController ist auf dem aktuellen Stand 5.8.24, das Aktivierungsintervall ist standart auf 30sec
dachte es funktioniert alles nur leider ist Sybille seit gut 7 Uhr nicht mehr anwesend. aktuelle Zeit 11:28
im WebIF des UnifiControllers ist dieser Eintrag nicht mehr vorhanden, nur die wirklich aktiven!
Sybille
connected
2018-07-23 11:25:59
Sybille_accesspoint
Wohnzimmer
2018-07-23 11:25:59
Sybille_essid
FR_home
2018-07-23 11:25:59
Sybille_hostname
Sybille
2018-07-23 11:25:59
Sybille_last_seen
2018-07-23 11:25:47
2018-07-23 11:25:59
Sybille_snr
23
2018-07-23 11:25:59
Sybille_uptime
415147
2018-07-23 11:25:59
Ich hab quasi das gleiche Setup und da läuft es problemlos. Ich würde einfach mal aktiv gucken bzgl. connected. Ist es denn bei allen Handys so?
Dann nimm doch einfach deins, WLAN aus, gucken (kannst auch nebenbei Eventmonitor aufmachen oder FileLog bauen) und dann wieder an. Und gucken ob er jedes Mal sauber schaltet.
Das Modul macht im Kern ja nix anderes, als json vom Controller zu ziehen und aufzutrennen.
wenn ich set my_unifi__controller clear all
mache ist alles ok, aber sobald einer das WLAN verlässt oder ausschaltet bleibt immer irgendwas hängen/vorhanden.
Ich kann das auch nicht auf ein spezielles Gerät eingrenzen. hm?
Aber du wirst schon ein wenig probieren müssen, damit man es eingrenzen kann.
Welche Version vom Modul hast du denn?
Zitat von: Maui am 23 Juli 2018, 13:38:31
Welche Version vom Modul hast du denn?
Unifi
VERSION
3.0.4
@australien: bitte mal versuchen das nachzustellen.
1. clear all
2. update
3. wenn dein Handy connected ist im Unifi-Modul das Handy auf Flugmodus stellen
4. Wenn das Handy im Unifi-Controller nocht mehr unter devices ist, im Unifi-Modul update aufrufen und warten, bis die readings aktualisiert werden.
Wenn du das Phänomen so nachstellen kannst, das Ganze nochmal, aber vorher das verbose-Attribut im Unifi-Modul auf 5 setzen.
Nach dem Durchlauf: hier das Log und ein ,,list myUnifi" (Namen anpassen) posten. (Vorher einmal ansehen, ob nichts persönliches/Passwörter drinstehen ;)
Dann müsste sich das Problem eingrenzen lassen.
VG,
Dirk
hab ich gemacht.
zur Info das Device Sybille ist seit ca 19:30 nicht mehr angemeldet.
den Test hab ich mit Robert-X durchgeführt
2018.07.23 20:48:17 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/74_Unifi.pm line 1998.
2018.07.23 20:50:26 5: my_unifi__controller (Unifi_Notify) - executed.
2018.07.23 20:50:27 5: my_unifi__controller: get called with ?.
2018.07.23 20:50:31 5: my_unifi__controller: set called with clear all
2018.07.23 20:50:31 4: my_unifi__controller: set clear
2018.07.23 20:50:31 2: my_unifi__controller: deprecated use of Attribute 'deprecatedClientNames' (see commandref for details).
2018.07.23 20:50:31 5: my_unifi__controller: get called with ?.
2018.07.23 20:50:35 5: my_unifi__controller (Unifi_DoUpdate) - executed.
2018.07.23 20:50:35 5: my_unifi__controller (Unifi_GetEvents_Send) - executed.
2018.07.23 20:50:35 5: my_unifi__controller (Unifi_GetEvents_Receive) - executed.
2018.07.23 20:50:35 5: my_unifi__controller (Unifi_GetEvents_Receive) - state:'ok'
2018.07.23 20:50:35 5: my_unifi__controller (Unifi_GetClients_Send) - executed.
2018.07.23 20:50:35 5: my_unifi__controller (Unifi_GetClients_Receive) - executed.
2018.07.23 20:50:35 5: my_unifi__controller (Unifi_GetClients_Receive) - state:'ok'
2018.07.23 20:50:35 5: my_unifi__controller (Unifi_GetAccesspoints_Send) - executed.
2018.07.23 20:50:36 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - executed.
2018.07.23 20:50:36 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.07.23 20:50:36 5: my_unifi__controller (Unifi_GetWlans_Send) - executed.
2018.07.23 20:50:36 5: my_unifi__controller (Unifi_GetWlans_Receive) - executed.
2018.07.23 20:50:36 5: my_unifi__controller (Unifi_GetWlans_Receive) - state:'ok'
2018.07.23 20:50:36 5: my_unifi__controller (Unifi_GetVoucherList_Send) - executed.
2018.07.23 20:50:36 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - executed.
2018.07.23 20:50:36 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - state:'ok'
2018.07.23 20:50:36 5: my_unifi__controller (Unifi_GetHealth_Send) - executed.
2018.07.23 20:50:37 5: my_unifi__controller (Unifi_GetHealth_Receive) - executed.
2018.07.23 20:50:37 5: my_unifi__controller (Unifi_GetHealth_Receive) - state:'ok'
2018.07.23 20:50:37 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.07.23 20:50:37 5: my_unifi__controller: set called with update
2018.07.23 20:50:37 4: my_unifi__controller: set update
2018.07.23 20:50:37 2: my_unifi__controller: deprecated use of Attribute 'deprecatedClientNames' (see commandref for details).
2018.07.23 20:50:37 5: my_unifi__controller (Unifi_DoUpdate) - executed.
2018.07.23 20:50:37 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.07.23 20:50:37 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.07.23 20:50:37 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.07.23 20:50:37 5: my_unifi__controller (Unifi_GetHealth_Send) - executed.
2018.07.23 20:50:37 5: my_unifi__controller: get called with ?.
2018.07.23 20:50:38 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.07.23 20:50:38 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.07.23 20:50:38 5: my_unifi__controller (Unifi_GetHealth_Send) - executed.
2018.07.23 20:50:38 5: my_unifi__controller (Unifi_GetHealth_Receive) - executed.
2018.07.23 20:50:38 5: my_unifi__controller (Unifi_GetHealth_Receive) - state:'ok'
2018.07.23 20:50:38 5: my_unifi__controller (Unifi_GetVoucherList_Send) - executed.
2018.07.23 20:50:38 5: my_unifi__controller (Unifi_GetHealth_Receive) - executed.
2018.07.23 20:50:38 5: my_unifi__controller (Unifi_GetHealth_Receive) - state:'ok'
2018.07.23 20:50:38 5: my_unifi__controller (Unifi_GetVoucherList_Send) - executed.
2018.07.23 20:50:39 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - executed.
2018.07.23 20:50:39 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - state:'ok'
2018.07.23 20:50:39 5: my_unifi__controller (Unifi_GetWlans_Send) - executed.
2018.07.23 20:50:39 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - executed.
2018.07.23 20:50:39 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - state:'ok'
2018.07.23 20:50:39 5: my_unifi__controller (Unifi_GetWlans_Send) - executed.
2018.07.23 20:50:39 5: my_unifi__controller (Unifi_GetWlans_Receive) - executed.
2018.07.23 20:50:39 5: my_unifi__controller (Unifi_GetWlans_Receive) - state:'ok'
2018.07.23 20:50:39 5: my_unifi__controller (Unifi_GetAccesspoints_Send) - executed.
2018.07.23 20:50:39 5: my_unifi__controller (Unifi_GetWlans_Receive) - executed.
2018.07.23 20:50:39 5: my_unifi__controller (Unifi_GetWlans_Receive) - state:'ok'
2018.07.23 20:50:39 5: my_unifi__controller (Unifi_GetAccesspoints_Send) - executed.
2018.07.23 20:50:40 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - executed.
2018.07.23 20:50:40 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.07.23 20:50:40 5: my_unifi__controller (Unifi_GetClients_Send) - executed.
2018.07.23 20:50:40 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - executed.
2018.07.23 20:50:40 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.07.23 20:50:40 5: my_unifi__controller (Unifi_GetClients_Send) - executed.
2018.07.23 20:50:40 5: my_unifi__controller (Unifi_GetClients_Receive) - executed.
2018.07.23 20:50:40 5: my_unifi__controller (Unifi_GetClients_Receive) - state:'ok'
2018.07.23 20:50:40 5: my_unifi__controller (Unifi_GetEvents_Send) - executed.
2018.07.23 20:50:40 5: my_unifi__controller (Unifi_GetClients_Receive) - executed.
2018.07.23 20:50:40 5: my_unifi__controller (Unifi_GetClients_Receive) - state:'ok'
2018.07.23 20:50:40 5: my_unifi__controller (Unifi_GetEvents_Send) - executed.
2018.07.23 20:50:41 5: my_unifi__controller (Unifi_GetEvents_Receive) - executed.
2018.07.23 20:50:41 5: my_unifi__controller (Unifi_GetEvents_Receive) - state:'ok'
2018.07.23 20:50:41 5: my_unifi__controller (Unifi_ProcessUpdate) - executed after 4.0000 seconds.
2018.07.23 20:50:41 5: my_unifi__controller (Unifi_SetHealthReadings) - executed.
2018.07.23 20:50:41 5: my_unifi__controller (Unifi_SetClientReadings) - executed.
2018.07.23 20:50:41 5: my_unifi__controller (Unifi_SetAccesspointReadings) - executed.
2018.07.23 20:50:41 5: my_unifi__controller (Unifi_SetWlanReadings) - executed.
2018.07.23 20:50:41 5: my_unifi__controller (Unifi_SetVoucherReadings) - executed.
2018.07.23 20:50:41 5: my_unifi__controller (Unifi_ProcessUpdate) - finished after 4.0000 seconds.
2018.07.23 20:50:41 5: my_unifi__controller (Unifi_GetEvents_Receive) - executed.
2018.07.23 20:50:41 5: my_unifi__controller (Unifi_GetEvents_Receive) - state:'ok'
2018.07.23 20:50:52 5: my_unifi__controller: get called with ?.
2018.07.23 20:51:11 5: my_unifi__controller (Unifi_DoUpdate) - executed.
2018.07.23 20:51:11 5: my_unifi__controller (Unifi_GetEvents_Send) - executed.
2018.07.23 20:51:11 5: my_unifi__controller (Unifi_GetEvents_Receive) - executed.
2018.07.23 20:51:11 5: my_unifi__controller (Unifi_GetEvents_Receive) - state:'ok'
2018.07.23 20:51:11 5: my_unifi__controller (Unifi_GetClients_Send) - executed.
2018.07.23 20:51:11 5: my_unifi__controller (Unifi_GetClients_Receive) - executed.
2018.07.23 20:51:11 5: my_unifi__controller (Unifi_GetClients_Receive) - state:'ok'
2018.07.23 20:51:11 5: my_unifi__controller (Unifi_GetWlans_Send) - executed.
2018.07.23 20:51:12 5: my_unifi__controller (Unifi_GetWlans_Receive) - executed.
2018.07.23 20:51:12 5: my_unifi__controller (Unifi_GetWlans_Receive) - state:'ok'
2018.07.23 20:51:12 5: my_unifi__controller (Unifi_GetAccesspoints_Send) - executed.
2018.07.23 20:51:12 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - executed.
2018.07.23 20:51:12 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.07.23 20:51:12 5: my_unifi__controller (Unifi_GetVoucherList_Send) - executed.
2018.07.23 20:51:12 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - executed.
2018.07.23 20:51:12 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - state:'ok'
2018.07.23 20:51:12 5: my_unifi__controller (Unifi_GetHealth_Send) - executed.
2018.07.23 20:51:13 5: my_unifi__controller (Unifi_GetHealth_Receive) - executed.
2018.07.23 20:51:13 5: my_unifi__controller (Unifi_GetHealth_Receive) - state:'ok'
2018.07.23 20:51:13 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.07.23 20:51:13 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.07.23 20:51:13 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.07.23 20:51:13 5: my_unifi__controller (Unifi_ProcessUpdate) - executed after 2.0000 seconds.
2018.07.23 20:51:13 5: my_unifi__controller (Unifi_SetHealthReadings) - executed.
2018.07.23 20:51:13 5: my_unifi__controller (Unifi_SetClientReadings) - executed.
2018.07.23 20:51:13 5: my_unifi__controller (Unifi_SetAccesspointReadings) - executed.
2018.07.23 20:51:13 5: my_unifi__controller (Unifi_SetWlanReadings) - executed.
2018.07.23 20:51:13 5: my_unifi__controller (Unifi_SetVoucherReadings) - executed.
2018.07.23 20:51:13 5: my_unifi__controller (Unifi_ProcessUpdate) - finished after 2.0000 seconds.
2018.07.23 20:51:43 5: my_unifi__controller (Unifi_DoUpdate) - executed.
2018.07.23 20:51:43 5: my_unifi__controller (Unifi_GetHealth_Send) - executed.
2018.07.23 20:51:43 5: my_unifi__controller (Unifi_GetHealth_Receive) - executed.
2018.07.23 20:51:43 5: my_unifi__controller (Unifi_GetHealth_Receive) - state:'ok'
2018.07.23 20:51:43 5: my_unifi__controller (Unifi_GetVoucherList_Send) - executed.
2018.07.23 20:51:43 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - executed.
2018.07.23 20:51:43 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - state:'ok'
2018.07.23 20:51:43 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.07.23 20:51:44 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.07.23 20:51:44 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.07.23 20:51:44 5: my_unifi__controller (Unifi_GetEvents_Send) - executed.
2018.07.23 20:51:44 5: my_unifi__controller (Unifi_GetEvents_Receive) - executed.
2018.07.23 20:51:44 5: my_unifi__controller (Unifi_GetEvents_Receive) - state:'ok'
2018.07.23 20:51:44 5: my_unifi__controller (Unifi_GetWlans_Send) - executed.
2018.07.23 20:51:44 5: my_unifi__controller (Unifi_GetWlans_Receive) - executed.
2018.07.23 20:51:44 5: my_unifi__controller (Unifi_GetWlans_Receive) - state:'ok'
2018.07.23 20:51:44 5: my_unifi__controller (Unifi_GetAccesspoints_Send) - executed.
2018.07.23 20:51:45 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - executed.
2018.07.23 20:51:45 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.07.23 20:51:45 5: my_unifi__controller (Unifi_GetClients_Send) - executed.
2018.07.23 20:51:45 5: my_unifi__controller (Unifi_GetClients_Receive) - executed.
2018.07.23 20:51:45 5: my_unifi__controller (Unifi_GetClients_Receive) - state:'ok'
2018.07.23 20:51:45 5: my_unifi__controller (Unifi_ProcessUpdate) - executed after 2.0000 seconds.
2018.07.23 20:51:45 5: my_unifi__controller (Unifi_SetHealthReadings) - executed.
2018.07.23 20:51:45 5: my_unifi__controller (Unifi_SetClientReadings) - executed.
2018.07.23 20:51:45 5: my_unifi__controller (Unifi_SetAccesspointReadings) - executed.
2018.07.23 20:51:45 5: my_unifi__controller (Unifi_SetWlanReadings) - executed.
2018.07.23 20:51:45 5: my_unifi__controller (Unifi_SetVoucherReadings) - executed.
2018.07.23 20:51:45 5: my_unifi__controller (Unifi_ProcessUpdate) - finished after 2.0000 seconds.
2018.07.23 20:52:15 5: my_unifi__controller (Unifi_DoUpdate) - executed.
2018.07.23 20:52:15 5: my_unifi__controller (Unifi_GetEvents_Send) - executed.
2018.07.23 20:52:15 5: my_unifi__controller (Unifi_GetEvents_Receive) - executed.
2018.07.23 20:52:15 5: my_unifi__controller (Unifi_GetEvents_Receive) - state:'ok'
2018.07.23 20:52:15 5: my_unifi__controller (Unifi_GetAccesspoints_Send) - executed.
2018.07.23 20:52:15 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - executed.
2018.07.23 20:52:15 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.07.23 20:52:15 5: my_unifi__controller (Unifi_GetWlans_Send) - executed.
2018.07.23 20:52:16 5: my_unifi__controller (Unifi_GetWlans_Receive) - executed.
2018.07.23 20:52:16 5: my_unifi__controller (Unifi_GetWlans_Receive) - state:'ok'
2018.07.23 20:52:16 5: my_unifi__controller (Unifi_GetClients_Send) - executed.
2018.07.23 20:52:16 5: my_unifi__controller (Unifi_GetClients_Receive) - executed.
2018.07.23 20:52:16 5: my_unifi__controller (Unifi_GetClients_Receive) - state:'ok'
2018.07.23 20:52:16 5: my_unifi__controller (Unifi_GetHealth_Send) - executed.
2018.07.23 20:52:16 5: my_unifi__controller (Unifi_GetHealth_Receive) - executed.
2018.07.23 20:52:16 5: my_unifi__controller (Unifi_GetHealth_Receive) - state:'ok'
2018.07.23 20:52:16 5: my_unifi__controller (Unifi_GetVoucherList_Send) - executed.
2018.07.23 20:52:16 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - executed.
2018.07.23 20:52:16 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - state:'ok'
2018.07.23 20:52:16 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.07.23 20:52:17 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.07.23 20:52:17 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.07.23 20:52:17 5: my_unifi__controller (Unifi_ProcessUpdate) - executed after 2.0000 seconds.
2018.07.23 20:52:17 5: my_unifi__controller (Unifi_SetHealthReadings) - executed.
2018.07.23 20:52:17 5: my_unifi__controller (Unifi_SetClientReadings) - executed.
2018.07.23 20:52:17 5: my_unifi__controller (Unifi_SetAccesspointReadings) - executed.
2018.07.23 20:52:17 5: my_unifi__controller (Unifi_SetWlanReadings) - executed.
2018.07.23 20:52:17 5: my_unifi__controller (Unifi_SetVoucherReadings) - executed.
2018.07.23 20:52:17 5: my_unifi__controller (Unifi_ProcessUpdate) - finished after 2.0000 seconds.
2018.07.23 20:52:47 5: my_unifi__controller (Unifi_DoUpdate) - executed.
2018.07.23 20:52:47 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.07.23 20:52:47 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.07.23 20:52:47 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.07.23 20:52:47 5: my_unifi__controller (Unifi_GetVoucherList_Send) - executed.
2018.07.23 20:52:47 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - executed.
2018.07.23 20:52:47 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - state:'ok'
2018.07.23 20:52:47 5: my_unifi__controller (Unifi_GetHealth_Send) - executed.
2018.07.23 20:52:47 5: my_unifi__controller (Unifi_GetHealth_Receive) - executed.
2018.07.23 20:52:47 5: my_unifi__controller (Unifi_GetHealth_Receive) - state:'ok'
2018.07.23 20:52:47 5: my_unifi__controller (Unifi_GetClients_Send) - executed.
2018.07.23 20:52:48 5: my_unifi__controller (Unifi_GetClients_Receive) - executed.
2018.07.23 20:52:48 5: my_unifi__controller (Unifi_GetClients_Receive) - state:'ok'
2018.07.23 20:52:48 5: my_unifi__controller (Unifi_GetAccesspoints_Send) - executed.
2018.07.23 20:52:48 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - executed.
2018.07.23 20:52:48 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.07.23 20:52:48 5: my_unifi__controller (Unifi_GetWlans_Send) - executed.
2018.07.23 20:52:48 5: my_unifi__controller (Unifi_GetWlans_Receive) - executed.
2018.07.23 20:52:48 5: my_unifi__controller (Unifi_GetWlans_Receive) - state:'ok'
2018.07.23 20:52:48 5: my_unifi__controller (Unifi_GetEvents_Send) - executed.
2018.07.23 20:52:49 5: my_unifi__controller (Unifi_GetEvents_Receive) - executed.
2018.07.23 20:52:49 5: my_unifi__controller (Unifi_GetEvents_Receive) - state:'ok'
2018.07.23 20:52:49 5: my_unifi__controller (Unifi_ProcessUpdate) - executed after 2.0000 seconds.
2018.07.23 20:52:49 5: my_unifi__controller (Unifi_SetHealthReadings) - executed.
2018.07.23 20:52:49 5: my_unifi__controller (Unifi_SetClientReadings) - executed.
2018.07.23 20:52:49 5: my_unifi__controller (Unifi_SetAccesspointReadings) - executed.
2018.07.23 20:52:49 5: my_unifi__controller (Unifi_SetWlanReadings) - executed.
2018.07.23 20:52:49 5: my_unifi__controller (Unifi_SetVoucherReadings) - executed.
2018.07.23 20:52:49 5: my_unifi__controller (Unifi_ProcessUpdate) - finished after 2.0000 seconds.
2018.07.23 20:53:19 5: my_unifi__controller (Unifi_DoUpdate) - executed.
2018.07.23 20:53:19 5: my_unifi__controller (Unifi_GetEvents_Send) - executed.
2018.07.23 20:53:19 5: my_unifi__controller (Unifi_GetEvents_Receive) - executed.
2018.07.23 20:53:19 5: my_unifi__controller (Unifi_GetEvents_Receive) - state:'ok'
2018.07.23 20:53:19 5: my_unifi__controller (Unifi_GetWlans_Send) - executed.
2018.07.23 20:53:19 5: my_unifi__controller (Unifi_GetWlans_Receive) - executed.
2018.07.23 20:53:19 5: my_unifi__controller (Unifi_GetWlans_Receive) - state:'ok'
2018.07.23 20:53:19 5: my_unifi__controller (Unifi_GetAccesspoints_Send) - executed.
2018.07.23 20:53:20 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - executed.
2018.07.23 20:53:20 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.07.23 20:53:20 5: my_unifi__controller (Unifi_GetClients_Send) - executed.
2018.07.23 20:53:20 5: my_unifi__controller (Unifi_GetClients_Receive) - executed.
2018.07.23 20:53:20 5: my_unifi__controller (Unifi_GetClients_Receive) - state:'ok'
2018.07.23 20:53:20 5: my_unifi__controller (Unifi_GetHealth_Send) - executed.
2018.07.23 20:53:20 5: my_unifi__controller (Unifi_GetHealth_Receive) - executed.
2018.07.23 20:53:20 5: my_unifi__controller (Unifi_GetHealth_Receive) - state:'ok'
2018.07.23 20:53:20 5: my_unifi__controller (Unifi_GetVoucherList_Send) - executed.
2018.07.23 20:53:21 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - executed.
2018.07.23 20:53:21 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - state:'ok'
2018.07.23 20:53:21 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.07.23 20:53:21 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.07.23 20:53:21 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.07.23 20:53:21 5: my_unifi__controller (Unifi_ProcessUpdate) - executed after 2.0000 seconds.
2018.07.23 20:53:21 5: my_unifi__controller (Unifi_SetHealthReadings) - executed.
2018.07.23 20:53:21 5: my_unifi__controller (Unifi_SetClientReadings) - executed.
2018.07.23 20:53:21 5: my_unifi__controller (Unifi_SetAccesspointReadings) - executed.
2018.07.23 20:53:21 5: my_unifi__controller (Unifi_SetWlanReadings) - executed.
2018.07.23 20:53:21 5: my_unifi__controller (Unifi_SetVoucherReadings) - executed.
2018.07.23 20:53:21 5: my_unifi__controller (Unifi_ProcessUpdate) - finished after 2.0000 seconds.
2018.07.23 20:53:51 5: my_unifi__controller (Unifi_DoUpdate) - executed.
2018.07.23 20:53:51 5: my_unifi__controller (Unifi_GetHealth_Send) - executed.
2018.07.23 20:53:51 5: my_unifi__controller (Unifi_GetHealth_Receive) - executed.
2018.07.23 20:53:51 5: my_unifi__controller (Unifi_GetHealth_Receive) - state:'ok'
2018.07.23 20:53:51 5: my_unifi__controller (Unifi_GetVoucherList_Send) - executed.
2018.07.23 20:53:51 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - executed.
2018.07.23 20:53:51 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - state:'ok'
2018.07.23 20:53:51 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.07.23 20:53:51 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.07.23 20:53:51 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.07.23 20:53:51 5: my_unifi__controller (Unifi_GetEvents_Send) - executed.
2018.07.23 20:53:52 5: my_unifi__controller (Unifi_GetEvents_Receive) - executed.
2018.07.23 20:53:52 5: my_unifi__controller (Unifi_GetEvents_Receive) - state:'ok'
2018.07.23 20:53:52 5: my_unifi__controller (Unifi_GetAccesspoints_Send) - executed.
2018.07.23 20:53:52 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - executed.
2018.07.23 20:53:52 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.07.23 20:53:52 5: my_unifi__controller (Unifi_GetWlans_Send) - executed.
2018.07.23 20:53:53 5: my_unifi__controller (Unifi_GetWlans_Receive) - executed.
2018.07.23 20:53:53 5: my_unifi__controller (Unifi_GetWlans_Receive) - state:'ok'
2018.07.23 20:53:53 5: my_unifi__controller (Unifi_GetClients_Send) - executed.
2018.07.23 20:53:53 5: my_unifi__controller (Unifi_GetClients_Receive) - executed.
2018.07.23 20:53:53 5: my_unifi__controller (Unifi_GetClients_Receive) - state:'ok'
2018.07.23 20:53:53 5: my_unifi__controller (Unifi_ProcessUpdate) - executed after 2.0000 seconds.
2018.07.23 20:53:53 5: my_unifi__controller (Unifi_SetHealthReadings) - executed.
2018.07.23 20:53:53 5: my_unifi__controller (Unifi_SetClientReadings) - executed.
2018.07.23 20:53:53 5: my_unifi__controller (Unifi_SetAccesspointReadings) - executed.
2018.07.23 20:53:53 5: my_unifi__controller (Unifi_SetWlanReadings) - executed.
2018.07.23 20:53:53 5: my_unifi__controller (Unifi_SetVoucherReadings) - executed.
2018.07.23 20:53:53 5: my_unifi__controller (Unifi_ProcessUpdate) - finished after 2.0000 seconds.
2018.07.23 20:54:23 5: my_unifi__controller (Unifi_DoUpdate) - executed.
2018.07.23 20:54:23 5: my_unifi__controller (Unifi_GetHealth_Send) - executed.
2018.07.23 20:54:23 5: my_unifi__controller (Unifi_GetHealth_Receive) - executed.
2018.07.23 20:54:23 5: my_unifi__controller (Unifi_GetHealth_Receive) - state:'ok'
2018.07.23 20:54:23 5: my_unifi__controller (Unifi_GetVoucherList_Send) - executed.
2018.07.23 20:54:23 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - executed.
2018.07.23 20:54:23 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - state:'ok'
2018.07.23 20:54:23 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.07.23 20:54:24 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.07.23 20:54:24 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.07.23 20:54:24 5: my_unifi__controller (Unifi_GetEvents_Send) - executed.
2018.07.23 20:54:24 5: my_unifi__controller (Unifi_GetEvents_Receive) - executed.
2018.07.23 20:54:24 5: my_unifi__controller (Unifi_GetEvents_Receive) - state:'ok'
2018.07.23 20:54:24 5: my_unifi__controller (Unifi_GetAccesspoints_Send) - executed.
2018.07.23 20:54:24 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - executed.
2018.07.23 20:54:24 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.07.23 20:54:24 5: my_unifi__controller (Unifi_GetWlans_Send) - executed.
2018.07.23 20:54:25 5: my_unifi__controller (Unifi_GetWlans_Receive) - executed.
2018.07.23 20:54:25 5: my_unifi__controller (Unifi_GetWlans_Receive) - state:'ok'
2018.07.23 20:54:25 5: my_unifi__controller (Unifi_GetClients_Send) - executed.
2018.07.23 20:54:25 5: my_unifi__controller (Unifi_GetClients_Receive) - executed.
2018.07.23 20:54:25 5: my_unifi__controller (Unifi_GetClients_Receive) - state:'ok'
2018.07.23 20:54:25 5: my_unifi__controller (Unifi_ProcessUpdate) - executed after 2.0000 seconds.
2018.07.23 20:54:25 5: my_unifi__controller (Unifi_SetHealthReadings) - executed.
2018.07.23 20:54:25 5: my_unifi__controller (Unifi_SetClientReadings) - executed.
2018.07.23 20:54:25 5: my_unifi__controller (Unifi_SetAccesspointReadings) - executed.
2018.07.23 20:54:25 5: my_unifi__controller (Unifi_SetWlanReadings) - executed.
2018.07.23 20:54:25 5: my_unifi__controller (Unifi_SetVoucherReadings) - executed.
2018.07.23 20:54:25 5: my_unifi__controller (Unifi_ProcessUpdate) - finished after 2.0000 seconds.
2018.07.23 20:54:55 5: my_unifi__controller (Unifi_DoUpdate) - executed.
2018.07.23 20:54:55 5: my_unifi__controller (Unifi_GetVoucherList_Send) - executed.
2018.07.23 20:54:55 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - executed.
2018.07.23 20:54:55 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - state:'ok'
2018.07.23 20:54:55 5: my_unifi__controller (Unifi_GetHealth_Send) - executed.
2018.07.23 20:54:55 5: my_unifi__controller (Unifi_GetHealth_Receive) - executed.
2018.07.23 20:54:55 5: my_unifi__controller (Unifi_GetHealth_Receive) - state:'ok'
2018.07.23 20:54:55 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.07.23 20:54:55 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.07.23 20:54:55 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.07.23 20:54:55 5: my_unifi__controller (Unifi_GetEvents_Send) - executed.
2018.07.23 20:54:56 5: my_unifi__controller (Unifi_GetEvents_Receive) - executed.
2018.07.23 20:54:56 5: my_unifi__controller (Unifi_GetEvents_Receive) - state:'ok'
2018.07.23 20:54:56 5: my_unifi__controller (Unifi_GetClients_Send) - executed.
2018.07.23 20:54:56 5: my_unifi__controller (Unifi_GetClients_Receive) - executed.
2018.07.23 20:54:56 5: my_unifi__controller (Unifi_GetClients_Receive) - state:'ok'
2018.07.23 20:54:56 5: my_unifi__controller (Unifi_GetWlans_Send) - executed.
2018.07.23 20:54:56 5: my_unifi__controller (Unifi_GetWlans_Receive) - executed.
2018.07.23 20:54:56 5: my_unifi__controller (Unifi_GetWlans_Receive) - state:'ok'
2018.07.23 20:54:56 5: my_unifi__controller (Unifi_GetAccesspoints_Send) - executed.
2018.07.23 20:54:57 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - executed.
2018.07.23 20:54:57 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.07.23 20:54:57 5: my_unifi__controller (Unifi_ProcessUpdate) - executed after 2.0000 seconds.
2018.07.23 20:54:57 5: my_unifi__controller (Unifi_SetHealthReadings) - executed.
2018.07.23 20:54:57 5: my_unifi__controller (Unifi_SetClientReadings) - executed.
2018.07.23 20:54:57 5: my_unifi__controller (Unifi_SetAccesspointReadings) - executed.
2018.07.23 20:54:57 5: my_unifi__controller (Unifi_SetWlanReadings) - executed.
2018.07.23 20:54:57 5: my_unifi__controller (Unifi_SetVoucherReadings) - executed.
2018.07.23 20:54:57 5: my_unifi__controller (Unifi_ProcessUpdate) - finished after 2.0000 seconds.
2018.07.23 20:55:27 5: my_unifi__controller (Unifi_DoUpdate) - executed.
2018.07.23 20:55:27 5: my_unifi__controller (Unifi_GetClients_Send) - executed.
2018.07.23 20:55:27 5: my_unifi__controller (Unifi_GetClients_Receive) - executed.
2018.07.23 20:55:27 5: my_unifi__controller (Unifi_GetClients_Receive) - state:'ok'
2018.07.23 20:55:27 5: my_unifi__controller (Unifi_GetWlans_Send) - executed.
2018.07.23 20:55:27 5: my_unifi__controller (Unifi_GetWlans_Receive) - executed.
2018.07.23 20:55:27 5: my_unifi__controller (Unifi_GetWlans_Receive) - state:'ok'
2018.07.23 20:55:27 5: my_unifi__controller (Unifi_GetAccesspoints_Send) - executed.
2018.07.23 20:55:27 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - executed.
2018.07.23 20:55:27 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.07.23 20:55:27 5: my_unifi__controller (Unifi_GetEvents_Send) - executed.
2018.07.23 20:55:28 5: my_unifi__controller (Unifi_GetEvents_Receive) - executed.
2018.07.23 20:55:28 5: my_unifi__controller (Unifi_GetEvents_Receive) - state:'ok'
2018.07.23 20:55:28 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.07.23 20:55:28 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.07.23 20:55:28 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.07.23 20:55:28 5: my_unifi__controller (Unifi_GetVoucherList_Send) - executed.
2018.07.23 20:55:29 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - executed.
2018.07.23 20:55:29 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - state:'ok'
2018.07.23 20:55:29 5: my_unifi__controller (Unifi_GetHealth_Send) - executed.
2018.07.23 20:55:29 5: my_unifi__controller (Unifi_GetHealth_Receive) - executed.
2018.07.23 20:55:29 5: my_unifi__controller (Unifi_GetHealth_Receive) - state:'ok'
2018.07.23 20:55:29 5: my_unifi__controller (Unifi_ProcessUpdate) - executed after 2.0000 seconds.
2018.07.23 20:55:29 5: my_unifi__controller (Unifi_SetHealthReadings) - executed.
2018.07.23 20:55:29 5: my_unifi__controller (Unifi_SetClientReadings) - executed.
2018.07.23 20:55:29 5: my_unifi__controller (Unifi_SetAccesspointReadings) - executed.
2018.07.23 20:55:29 5: my_unifi__controller (Unifi_SetWlanReadings) - executed.
2018.07.23 20:55:29 5: my_unifi__controller (Unifi_SetVoucherReadings) - executed.
2018.07.23 20:55:29 5: my_unifi__controller (Unifi_ProcessUpdate) - finished after 2.0000 seconds.
2018.07.23 20:55:59 5: my_unifi__controller (Unifi_DoUpdate) - executed.
2018.07.23 20:55:59 5: my_unifi__controller (Unifi_GetVoucherList_Send) - executed.
2018.07.23 20:55:59 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - executed.
2018.07.23 20:55:59 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - state:'ok'
2018.07.23 20:55:59 5: my_unifi__controller (Unifi_GetHealth_Send) - executed.
2018.07.23 20:55:59 5: my_unifi__controller (Unifi_GetHealth_Receive) - executed.
2018.07.23 20:55:59 5: my_unifi__controller (Unifi_GetHealth_Receive) - state:'ok'
2018.07.23 20:55:59 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.07.23 20:56:00 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.07.23 20:56:00 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.07.23 20:56:00 5: my_unifi__controller (Unifi_GetEvents_Send) - executed.
2018.07.23 20:56:00 5: my_unifi__controller (Unifi_GetEvents_Receive) - executed.
2018.07.23 20:56:00 5: my_unifi__controller (Unifi_GetEvents_Receive) - state:'ok'
2018.07.23 20:56:00 5: my_unifi__controller (Unifi_GetClients_Send) - executed.
2018.07.23 20:56:00 5: my_unifi__controller (Unifi_GetClients_Receive) - executed.
2018.07.23 20:56:00 5: my_unifi__controller (Unifi_GetClients_Receive) - state:'ok'
2018.07.23 20:56:00 5: my_unifi__controller (Unifi_GetAccesspoints_Send) - executed.
2018.07.23 20:56:01 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - executed.
2018.07.23 20:56:01 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.07.23 20:56:01 5: my_unifi__controller (Unifi_GetWlans_Send) - executed.
2018.07.23 20:56:01 5: my_unifi__controller (Unifi_GetWlans_Receive) - executed.
2018.07.23 20:56:01 5: my_unifi__controller (Unifi_GetWlans_Receive) - state:'ok'
2018.07.23 20:56:01 5: my_unifi__controller (Unifi_ProcessUpdate) - executed after 2.0000 seconds.
2018.07.23 20:56:01 5: my_unifi__controller (Unifi_SetHealthReadings) - executed.
2018.07.23 20:56:01 5: my_unifi__controller (Unifi_SetClientReadings) - executed.
2018.07.23 20:56:01 5: my_unifi__controller (Unifi_SetAccesspointReadings) - executed.
2018.07.23 20:56:01 5: my_unifi__controller (Unifi_SetWlanReadings) - executed.
2018.07.23 20:56:01 5: my_unifi__controller (Unifi_SetVoucherReadings) - executed.
2018.07.23 20:56:01 5: my_unifi__controller (Unifi_ProcessUpdate) - finished after 2.0000 seconds.
2018.07.23 20:56:31 5: my_unifi__controller (Unifi_DoUpdate) - executed.
2018.07.23 20:56:31 5: my_unifi__controller (Unifi_GetHealth_Send) - executed.
2018.07.23 20:56:31 5: my_unifi__controller (Unifi_GetHealth_Receive) - executed.
2018.07.23 20:56:31 5: my_unifi__controller (Unifi_GetHealth_Receive) - state:'ok'
2018.07.23 20:56:31 5: my_unifi__controller (Unifi_GetVoucherList_Send) - executed.
2018.07.23 20:56:31 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - executed.
2018.07.23 20:56:31 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - state:'ok'
2018.07.23 20:56:31 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.07.23 20:56:31 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.07.23 20:56:31 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.07.23 20:56:31 5: my_unifi__controller (Unifi_GetEvents_Send) - executed.
2018.07.23 20:56:32 5: my_unifi__controller (Unifi_GetEvents_Receive) - executed.
2018.07.23 20:56:32 5: my_unifi__controller (Unifi_GetEvents_Receive) - state:'ok'
2018.07.23 20:56:32 5: my_unifi__controller (Unifi_GetAccesspoints_Send) - executed.
2018.07.23 20:56:32 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - executed.
2018.07.23 20:56:32 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.07.23 20:56:32 5: my_unifi__controller (Unifi_GetWlans_Send) - executed.
2018.07.23 20:56:33 5: my_unifi__controller (Unifi_GetWlans_Receive) - executed.
2018.07.23 20:56:33 5: my_unifi__controller (Unifi_GetWlans_Receive) - state:'ok'
2018.07.23 20:56:33 5: my_unifi__controller (Unifi_GetClients_Send) - executed.
2018.07.23 20:56:33 5: my_unifi__controller (Unifi_GetClients_Receive) - executed.
2018.07.23 20:56:33 5: my_unifi__controller (Unifi_GetClients_Receive) - state:'ok'
2018.07.23 20:56:33 5: my_unifi__controller (Unifi_ProcessUpdate) - executed after 2.0000 seconds.
2018.07.23 20:56:33 5: my_unifi__controller (Unifi_SetHealthReadings) - executed.
2018.07.23 20:56:33 5: my_unifi__controller (Unifi_SetClientReadings) - executed.
2018.07.23 20:56:33 5: my_unifi__controller (Unifi_SetAccesspointReadings) - executed.
2018.07.23 20:56:33 5: my_unifi__controller (Unifi_SetWlanReadings) - executed.
2018.07.23 20:56:33 5: my_unifi__controller (Unifi_SetVoucherReadings) - executed.
2018.07.23 20:56:33 5: my_unifi__controller (Unifi_ProcessUpdate) - finished after 2.0000 seconds.
2018.07.23 20:57:03 5: my_unifi__controller (Unifi_DoUpdate) - executed.
2018.07.23 20:57:03 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.07.23 20:57:03 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.07.23 20:57:03 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.07.23 20:57:03 5: my_unifi__controller (Unifi_GetHealth_Send) - executed.
2018.07.23 20:57:03 5: my_unifi__controller (Unifi_GetHealth_Receive) - executed.
2018.07.23 20:57:03 5: my_unifi__controller (Unifi_GetHealth_Receive) - state:'ok'
2018.07.23 20:57:03 5: my_unifi__controller (Unifi_GetVoucherList_Send) - executed.
2018.07.23 20:57:04 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - executed.
2018.07.23 20:57:04 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - state:'ok'
2018.07.23 20:57:04 5: my_unifi__controller (Unifi_GetWlans_Send) - executed.
2018.07.23 20:57:04 5: my_unifi__controller (Unifi_GetWlans_Receive) - executed.
2018.07.23 20:57:04 5: my_unifi__controller (Unifi_GetWlans_Receive) - state:'ok'
2018.07.23 20:57:04 5: my_unifi__controller (Unifi_GetAccesspoints_Send) - executed.
2018.07.23 20:57:04 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - executed.
2018.07.23 20:57:04 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.07.23 20:57:04 5: my_unifi__controller (Unifi_GetClients_Send) - executed.
2018.07.23 20:57:05 5: my_unifi__controller (Unifi_GetClients_Receive) - executed.
2018.07.23 20:57:05 5: my_unifi__controller (Unifi_GetClients_Receive) - state:'ok'
2018.07.23 20:57:05 5: my_unifi__controller (Unifi_GetEvents_Send) - executed.
2018.07.23 20:57:05 5: my_unifi__controller (Unifi_GetEvents_Receive) - executed.
2018.07.23 20:57:05 5: my_unifi__controller (Unifi_GetEvents_Receive) - state:'ok'
2018.07.23 20:57:05 5: my_unifi__controller (Unifi_ProcessUpdate) - executed after 2.0000 seconds.
2018.07.23 20:57:05 5: my_unifi__controller (Unifi_SetHealthReadings) - executed.
2018.07.23 20:57:05 5: my_unifi__controller (Unifi_SetClientReadings) - executed.
2018.07.23 20:57:05 5: my_unifi__controller (Unifi_SetAccesspointReadings) - executed.
2018.07.23 20:57:05 5: my_unifi__controller (Unifi_SetWlanReadings) - executed.
2018.07.23 20:57:05 5: my_unifi__controller (Unifi_SetVoucherReadings) - executed.
2018.07.23 20:57:05 5: my_unifi__controller (Unifi_ProcessUpdate) - finished after 2.0000 seconds.
2018.07.23 20:57:35 5: my_unifi__controller (Unifi_DoUpdate) - executed.
2018.07.23 20:57:35 5: my_unifi__controller (Unifi_GetAccesspoints_Send) - executed.
2018.07.23 20:57:35 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - executed.
2018.07.23 20:57:35 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.07.23 20:57:35 5: my_unifi__controller (Unifi_GetWlans_Send) - executed.
2018.07.23 20:57:35 5: my_unifi__controller (Unifi_GetWlans_Receive) - executed.
2018.07.23 20:57:35 5: my_unifi__controller (Unifi_GetWlans_Receive) - state:'ok'
2018.07.23 20:57:35 5: my_unifi__controller (Unifi_GetClients_Send) - executed.
2018.07.23 20:57:35 5: my_unifi__controller (Unifi_GetClients_Receive) - executed.
2018.07.23 20:57:35 5: my_unifi__controller (Unifi_GetClients_Receive) - state:'ok'
2018.07.23 20:57:35 5: my_unifi__controller (Unifi_GetEvents_Send) - executed.
2018.07.23 20:57:36 5: my_unifi__controller (Unifi_GetEvents_Receive) - executed.
2018.07.23 20:57:36 5: my_unifi__controller (Unifi_GetEvents_Receive) - state:'ok'
2018.07.23 20:57:36 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.07.23 20:57:36 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.07.23 20:57:36 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.07.23 20:57:36 5: my_unifi__controller (Unifi_GetHealth_Send) - executed.
2018.07.23 20:57:37 5: my_unifi__controller (Unifi_GetHealth_Receive) - executed.
2018.07.23 20:57:37 5: my_unifi__controller (Unifi_GetHealth_Receive) - state:'ok'
2018.07.23 20:57:37 5: my_unifi__controller (Unifi_GetVoucherList_Send) - executed.
2018.07.23 20:57:37 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - executed.
2018.07.23 20:57:37 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - state:'ok'
2018.07.23 20:57:37 5: my_unifi__controller (Unifi_ProcessUpdate) - executed after 2.0000 seconds.
2018.07.23 20:57:37 5: my_unifi__controller (Unifi_SetHealthReadings) - executed.
2018.07.23 20:57:37 5: my_unifi__controller (Unifi_SetClientReadings) - executed.
2018.07.23 20:57:37 5: my_unifi__controller (Unifi_SetClientReadings) - Client 'Robert-X' previously connected is now disconnected.
2018.07.23 20:57:37 5: my_unifi__controller (Unifi_SetAccesspointReadings) - executed.
2018.07.23 20:57:37 5: my_unifi__controller (Unifi_SetWlanReadings) - executed.
2018.07.23 20:57:37 5: my_unifi__controller (Unifi_SetVoucherReadings) - executed.
2018.07.23 20:57:37 5: my_unifi__controller (Unifi_ProcessUpdate) - finished after 2.0000 seconds.
2018.07.23 20:58:07 5: my_unifi__controller (Unifi_DoUpdate) - executed.
2018.07.23 20:58:07 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.07.23 20:58:07 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.07.23 20:58:07 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.07.23 20:58:07 5: my_unifi__controller (Unifi_GetVoucherList_Send) - executed.
2018.07.23 20:58:07 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - executed.
2018.07.23 20:58:07 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - state:'ok'
2018.07.23 20:58:07 5: my_unifi__controller (Unifi_GetHealth_Send) - executed.
2018.07.23 20:58:07 5: my_unifi__controller (Unifi_GetHealth_Receive) - executed.
2018.07.23 20:58:07 5: my_unifi__controller (Unifi_GetHealth_Receive) - state:'ok'
2018.07.23 20:58:07 5: my_unifi__controller (Unifi_GetClients_Send) - executed.
2018.07.23 20:58:08 5: my_unifi__controller: get called with ?.
2018.07.23 20:58:08 5: my_unifi__controller (Unifi_GetClients_Receive) - executed.
2018.07.23 20:58:08 5: my_unifi__controller (Unifi_GetClients_Receive) - state:'ok'
2018.07.23 20:58:08 5: my_unifi__controller (Unifi_GetAccesspoints_Send) - executed.
2018.07.23 20:58:08 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - executed.
2018.07.23 20:58:08 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.07.23 20:58:08 5: my_unifi__controller (Unifi_GetWlans_Send) - executed.
2018.07.23 20:58:09 5: my_unifi__controller (Unifi_GetWlans_Receive) - executed.
2018.07.23 20:58:09 5: my_unifi__controller (Unifi_GetWlans_Receive) - state:'ok'
2018.07.23 20:58:09 5: my_unifi__controller (Unifi_GetEvents_Send) - executed.
2018.07.23 20:58:09 5: my_unifi__controller (Unifi_GetEvents_Receive) - executed.
2018.07.23 20:58:09 5: my_unifi__controller (Unifi_GetEvents_Receive) - state:'ok'
2018.07.23 20:58:09 5: my_unifi__controller (Unifi_ProcessUpdate) - executed after 2.0000 seconds.
2018.07.23 20:58:09 5: my_unifi__controller (Unifi_SetHealthReadings) - executed.
2018.07.23 20:58:09 5: my_unifi__controller (Unifi_SetClientReadings) - executed.
2018.07.23 20:58:09 5: my_unifi__controller (Unifi_SetAccesspointReadings) - executed.
2018.07.23 20:58:09 5: my_unifi__controller (Unifi_SetWlanReadings) - executed.
2018.07.23 20:58:09 5: my_unifi__controller (Unifi_SetVoucherReadings) - executed.
2018.07.23 20:58:09 5: my_unifi__controller (Unifi_ProcessUpdate) - finished after 2.0000 seconds.
2018.07.23 20:58:13 5: my_unifi__controller: set called with update
2018.07.23 20:58:13 4: my_unifi__controller: set update
2018.07.23 20:58:13 2: my_unifi__controller: deprecated use of Attribute 'deprecatedClientNames' (see commandref for details).
2018.07.23 20:58:13 5: my_unifi__controller (Unifi_DoUpdate) - executed.
2018.07.23 20:58:13 5: my_unifi__controller (Unifi_GetEvents_Send) - executed.
2018.07.23 20:58:14 5: my_unifi__controller: get called with ?.
2018.07.23 20:58:14 5: my_unifi__controller (Unifi_GetEvents_Receive) - executed.
2018.07.23 20:58:14 5: my_unifi__controller (Unifi_GetEvents_Receive) - state:'ok'
2018.07.23 20:58:14 5: my_unifi__controller (Unifi_GetWlans_Send) - executed.
2018.07.23 20:58:14 5: my_unifi__controller (Unifi_GetWlans_Receive) - executed.
2018.07.23 20:58:14 5: my_unifi__controller (Unifi_GetWlans_Receive) - state:'ok'
2018.07.23 20:58:14 5: my_unifi__controller (Unifi_GetAccesspoints_Send) - executed.
2018.07.23 20:58:14 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - executed.
2018.07.23 20:58:14 5: my_unifi__controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.07.23 20:58:14 5: my_unifi__controller (Unifi_GetClients_Send) - executed.
2018.07.23 20:58:15 5: my_unifi__controller (Unifi_GetClients_Receive) - executed.
2018.07.23 20:58:15 5: my_unifi__controller (Unifi_GetClients_Receive) - state:'ok'
2018.07.23 20:58:15 5: my_unifi__controller (Unifi_GetHealth_Send) - executed.
2018.07.23 20:58:15 5: my_unifi__controller (Unifi_GetHealth_Receive) - executed.
2018.07.23 20:58:15 5: my_unifi__controller (Unifi_GetHealth_Receive) - state:'ok'
2018.07.23 20:58:15 5: my_unifi__controller (Unifi_GetVoucherList_Send) - executed.
2018.07.23 20:58:15 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - executed.
2018.07.23 20:58:15 5: my_unifi__controller (Unifi_GetVoucherList_Receive) - state:'ok'
2018.07.23 20:58:15 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.07.23 20:58:15 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.07.23 20:58:15 5: my_unifi__controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.07.23 20:58:15 5: my_unifi__controller (Unifi_ProcessUpdate) - executed after 2.0000 seconds.
2018.07.23 20:58:15 5: my_unifi__controller (Unifi_SetHealthReadings) - executed.
2018.07.23 20:58:15 5: my_unifi__controller (Unifi_SetClientReadings) - executed.
2018.07.23 20:58:15 5: my_unifi__controller (Unifi_SetAccesspointReadings) - executed.
2018.07.23 20:58:15 5: my_unifi__controller (Unifi_SetWlanReadings) - executed.
2018.07.23 20:58:15 5: my_unifi__controller (Unifi_SetVoucherReadings) - executed.
2018.07.23 20:58:15 5: my_unifi__controller (Unifi_ProcessUpdate) - finished after 2.0000 seconds.
list
Internals:
DEF 10.68.0.21 8443 crypt:130b00034442 crypt:140a0b005f18000d47044c430652
NAME my_unifi__controller
NOTIFYDEV global
NR 434
NTFY_ORDER 50-my_unifi__controller
STATE connected
TYPE Unifi
VERSION 3.0.4
READINGS:
2018-07-23 21:11:38 -AP_OG_clients 2
2018-07-23 21:11:38 -AP_OG_essid FR_home,FR_home
2018-07-23 21:11:38 -AP_OG_locate off
2018-07-23 21:11:38 -AP_OG_state ok
2018-07-23 21:11:38 -AP_OG_utilization 9,0
2018-07-23 21:11:38 -AP_Wohnzimmer_clients 7
2018-07-23 21:11:38 -AP_Wohnzimmer_essid FR_home,FR_home
2018-07-23 21:11:38 -AP_Wohnzimmer_locate off
2018-07-23 21:11:38 -AP_Wohnzimmer_state ok
2018-07-23 21:11:38 -AP_Wohnzimmer_utilization 6,0
2018-07-23 21:11:38 -UC_events 323 (last 24h)
2018-07-23 21:11:38 -UC_newClients
2018-07-23 21:11:38 -UC_unarchived_alerts 0
2018-07-23 21:11:38 -UC_wlan_accesspoints 2
2018-07-23 21:11:38 -UC_wlan_guests 0
2018-07-23 21:11:38 -UC_wlan_state ok
2018-07-23 21:11:38 -UC_wlan_users 9
2018-07-23 21:11:38 -WLAN_FR_home_state enabled
2018-07-23 21:11:38 AppleWaonRobert connected
2018-07-23 21:11:38 AppleWaonRobert_accesspoint Wohnzimmer
2018-07-23 21:11:38 AppleWaonRobert_essid FR_home
2018-07-23 21:11:38 AppleWaonRobert_hostname AppleWaonRobert
2018-07-23 21:11:38 AppleWaonRobert_last_seen 2018-07-23 21:11:35
2018-07-23 21:11:38 AppleWaonRobert_snr 12
2018-07-23 21:11:38 AppleWaonRobert_uptime 82643
2018-07-23 21:11:38 Robert-X connected
2018-07-23 21:11:38 Robert-X_accesspoint Wohnzimmer
2018-07-23 21:11:38 Robert-X_essid FR_home
2018-07-23 21:11:38 Robert-X_hostname Robert-X
2018-07-23 21:11:38 Robert-X_last_seen 2018-07-23 21:11:35
2018-07-23 21:11:38 Robert-X_snr 32
2018-07-23 21:11:38 Robert-X_uptime 512
2018-07-23 21:11:38 Robin connected
2018-07-23 21:11:38 Robin_accesspoint Wohnzimmer
2018-07-23 21:11:38 Robin_essid FR_home
2018-07-23 21:11:38 Robin_hostname Robin
2018-07-23 21:11:38 Robin_last_seen 2018-07-23 21:11:35
2018-07-23 21:11:38 Robin_snr 43
2018-07-23 21:11:38 Robin_uptime 38508
2018-07-23 21:11:38 Surface_Robert connected
2018-07-23 21:11:38 Surface_Robert_accesspoint Wohnzimmer
2018-07-23 21:11:38 Surface_Robert_essid FR_home
2018-07-23 21:11:38 Surface_Robert_hostname DESKTOP-VF14LFK
2018-07-23 21:11:38 Surface_Robert_last_seen 2018-07-23 21:11:35
2018-07-23 21:11:38 Surface_Robert_snr 23
2018-07-23 21:11:38 Surface_Robert_uptime 7530
2018-07-23 21:11:38 Sybille connected
2018-07-23 21:11:38 Sybille_accesspoint Wohnzimmer
2018-07-23 21:11:38 Sybille_essid FR_home
2018-07-23 21:11:38 Sybille_hostname Sybille
2018-07-23 21:11:38 Sybille_last_seen 2018-07-23 21:11:35
2018-07-23 21:11:38 Sybille_snr 22
2018-07-23 21:11:38 Sybille_uptime 450295
2018-07-23 21:11:38 amazon-ea128f8f2 connected
2018-07-23 21:11:38 amazon-ea128f8f2_accesspoint Wohnzimmer
2018-07-23 21:11:38 amazon-ea128f8f2_essid FR_home
2018-07-23 21:11:38 amazon-ea128f8f2_hostname amazon-ea128f8f2
2018-07-23 21:11:38 amazon-ea128f8f2_last_seen 2018-07-23 21:11:35
2018-07-23 21:11:38 amazon-ea128f8f2_snr 46
2018-07-23 21:11:38 amazon-ea128f8f2_uptime 910962
2018-07-23 21:11:38 android-1eb0d347a5394c39 connected
2018-07-23 21:11:38 android-1eb0d347a5394c39_accesspoint OG
2018-07-23 21:11:38 android-1eb0d347a5394c39_essid FR_home
2018-07-23 21:11:38 android-1eb0d347a5394c39_hostname android-1eb0d347a5394c39
2018-07-23 21:11:38 android-1eb0d347a5394c39_last_seen 2018-07-23 21:11:28
2018-07-23 21:11:38 android-1eb0d347a5394c39_snr 36
2018-07-23 21:11:38 android-1eb0d347a5394c39_uptime 374036
2018-07-23 21:11:38 raspberrypi connected
2018-07-23 21:11:38 raspberrypi_accesspoint OG
2018-07-23 21:11:38 raspberrypi_essid FR_home
2018-07-23 21:11:38 raspberrypi_hostname raspberrypi
2018-07-23 21:11:38 raspberrypi_last_seen 2018-07-23 21:11:28
2018-07-23 21:11:38 raspberrypi_snr 19
2018-07-23 21:11:38 raspberrypi_uptime 179642
2018-07-23 19:29:15 state connected
accespoints:
5a5cc3xxxxxxxx36194a8:
_id 5a5cxxxxxxxbc736194a8
_uptime 28256
board_rev 33
bytes 28174397229
bytes-d 89137
Brauche das ganze list. Der interessante Teil fehlt ;-)
Aber im Log fällt mir folgendes auf:
2018.07.23 20:57:37 5: my_unifi__controller (Unifi_SetClientReadings) - Client 'Robert-X' previously connected is now disconnected.
Direkt in der Zeile nach dem Logeintrag wird das Reading Robert-X auf disconnected gesetzt.
Ausserdem könntest du mal das Attribut "deprecatedClientNames" auf 0 setzen. Vielleicht hängt das Problem damit zusammen.
2018.07.23 20:58:13 2: my_unifi__controller: deprecated use of Attribute 'deprecatedClientNames' (see commandref for details).
Anschließend wieder ein clear all.
Könnte dazu führen, dass manche Client-Readingnamen sich ändern. Aber den alten Kram teste ich nicht mehr so gut, wollte das eh bald ausbauen, dann hätten sich die Readings eh geändert.
Edit: die alten Readingnames kannst du wieder herstellen, wenn due den clients im UnifiController einen Alias gegen bst.
sorry, das war mein Fehler, hier ist das ganze list
habe jetzt auch noch das Attribute 'deprecatedClientNames' auf 0 gesetzt, nach dem list.
werde es morgen weiter verfolgen.
Danke jedenfalls!!!!
Internals:
DEF 10.68.0.21 8443 crypt:130b00034442 crypt:140a0b005f18000d47044c430652
NAME my_unifi__controller
NOTIFYDEV global
NR 434
NTFY_ORDER 50-my_unifi__controller
STATE connected
TYPE Unifi
VERSION 3.0.4
READINGS:
2018-07-23 22:53:08 -AP_OG_clients 2
2018-07-23 22:53:08 -AP_OG_essid FR_home,FR_home
2018-07-23 22:53:08 -AP_OG_locate off
2018-07-23 22:53:08 -AP_OG_state ok
2018-07-23 22:53:08 -AP_OG_utilization 10,0
2018-07-23 22:53:08 -AP_Wohnzimmer_clients 6
2018-07-23 22:53:08 -AP_Wohnzimmer_essid FR_home,FR_home
2018-07-23 22:53:08 -AP_Wohnzimmer_locate off
2018-07-23 22:53:08 -AP_Wohnzimmer_state ok
2018-07-23 22:53:08 -AP_Wohnzimmer_utilization 7,0
2018-07-23 22:53:08 -UC_events 300 (last 24h)
2018-07-23 22:53:08 -UC_newClients
2018-07-23 22:53:08 -UC_unarchived_alerts 0
2018-07-23 22:53:08 -UC_wlan_accesspoints 2
2018-07-23 22:53:08 -UC_wlan_guests 0
2018-07-23 22:53:08 -UC_wlan_state ok
2018-07-23 22:53:08 -UC_wlan_users 8
2018-07-23 22:53:08 -WLAN_FR_home_state enabled
2018-07-23 22:53:08 AppleWaonRobert connected
2018-07-23 22:53:08 AppleWaonRobert_accesspoint Wohnzimmer
2018-07-23 22:53:08 AppleWaonRobert_essid FR_home
2018-07-23 22:53:08 AppleWaonRobert_hostname AppleWaonRobert
2018-07-23 22:53:08 AppleWaonRobert_last_seen 2018-07-23 22:53:03
2018-07-23 22:53:08 AppleWaonRobert_snr 17
2018-07-23 22:53:08 AppleWaonRobert_uptime 88731
2018-07-23 22:38:39 I-PhoneJurgen disconnected
2018-07-23 22:38:07 I-PhoneJurgen_accesspoint Wohnzimmer
2018-07-23 22:38:07 I-PhoneJurgen_essid FR_home
2018-07-23 22:38:07 I-PhoneJurgen_hostname I-PhoneJurgen
2018-07-23 22:38:07 I-PhoneJurgen_last_seen 2018-07-23 22:33:10
2018-07-23 22:38:07 I-PhoneJurgen_snr 7
2018-07-23 22:38:07 I-PhoneJurgen_uptime 5155
2018-07-23 22:53:08 Robert-X connected
2018-07-23 22:53:08 Robert-X_accesspoint Wohnzimmer
2018-07-23 22:53:08 Robert-X_essid FR_home
2018-07-23 22:53:08 Robert-X_hostname Robert-X
2018-07-23 22:53:08 Robert-X_last_seen 2018-07-23 22:53:03
2018-07-23 22:53:08 Robert-X_snr 40
2018-07-23 22:53:08 Robert-X_uptime 6600
2018-07-23 22:53:08 Robin connected
2018-07-23 22:53:08 Robin_accesspoint Wohnzimmer
2018-07-23 22:53:08 Robin_essid FR_home
2018-07-23 22:53:08 Robin_hostname Robin
2018-07-23 22:53:08 Robin_last_seen 2018-07-23 22:53:03
2018-07-23 22:53:08 Robin_snr 31
2018-07-23 22:53:08 Robin_uptime 44596
2018-07-23 22:53:08 Surface_Robert connected
2018-07-23 22:53:08 Surface_Robert_accesspoint Wohnzimmer
2018-07-23 22:53:08 Surface_Robert_essid FR_home
2018-07-23 22:53:08 Surface_Robert_hostname DESKTOP-VF14LFK
2018-07-23 22:53:08 Surface_Robert_last_seen 2018-07-23 22:53:03
2018-07-23 22:53:08 Surface_Robert_snr 46
2018-07-23 22:53:08 Surface_Robert_uptime 13618
2018-07-23 22:53:08 Sybille connected
2018-07-23 22:53:08 Sybille_accesspoint Wohnzimmer
2018-07-23 22:53:08 Sybille_essid FR_home
2018-07-23 22:53:08 Sybille_hostname Sybille
2018-07-23 22:53:08 Sybille_last_seen 2018-07-23 22:53:03
2018-07-23 22:53:08 Sybille_snr 23
2018-07-23 22:53:08 Sybille_uptime 456383
2018-07-23 22:53:08 amazon-ea128f8f2 connected
2018-07-23 22:53:08 amazon-ea128f8f2_accesspoint Wohnzimmer
2018-07-23 22:53:08 amazon-ea128f8f2_essid FR_home
2018-07-23 22:53:08 amazon-ea128f8f2_hostname amazon-ea128f8f2
2018-07-23 22:53:08 amazon-ea128f8f2_last_seen 2018-07-23 22:53:03
2018-07-23 22:53:08 amazon-ea128f8f2_snr 46
2018-07-23 22:53:08 amazon-ea128f8f2_uptime 917050
2018-07-23 22:53:08 android-1eb0d347a5394c39 connected
2018-07-23 22:53:08 android-1eb0d347a5394c39_accesspoint OG
2018-07-23 22:53:08 android-1eb0d347a5394c39_essid FR_home
2018-07-23 22:53:08 android-1eb0d347a5394c39_hostname android-1eb0d347a5394c39
2018-07-23 22:53:08 android-1eb0d347a5394c39_last_seen 2018-07-23 22:52:57
2018-07-23 22:53:08 android-1eb0d347a5394c39_snr 36
2018-07-23 22:53:08 android-1eb0d347a5394c39_uptime 380125
2018-07-23 22:53:08 raspberrypi connected
2018-07-23 22:53:08 raspberrypi_accesspoint OG
2018-07-23 22:53:08 raspberrypi_essid FR_home
2018-07-23 22:53:08 raspberrypi_hostname raspberrypi
2018-07-23 22:53:08 raspberrypi_last_seen 2018-07-23 22:52:57
2018-07-23 22:53:08 raspberrypi_snr 19
2018-07-23 22:53:08 raspberrypi_uptime 185731
2018-07-23 19:29:15 state connected
accespoints:
5a5cc37144ae24bc736194a8:
_id 5a5cc37144ae24bc736194a8
_uptime 34344
board_rev 33
bytes 28446166794
bytes-d 19328
bytes-r 1610
cfgversion 03abc5cc1bada013
connect_request_ip 10.68.0.6
connect_request_port 60276
device_id 5a5cc37144ae24bc736194a8
fw_caps 196151
guest-num_sta 0
guest_token EF6FD320064FC5497958A00BDA061213
hw_caps 0
inform_ip 10.68.0.21
inform_url http://10.68.0.21:8080/inform
ip 10.68.0.6
known_cfgversion 03abc5cc1bada013
last_seen 1532379183
led_override off
led_override_color #0000ff
led_override_color_brightness 100
license_state registered
mac 78:8a:20:50:6b:ca
map_id
meshv3_peer_mac
model U7LT
name Wohnzimmer
num_sta 6
outdoor_mode_override on
rx_bytes 18252086763
rx_bytes-d 4629
serial 788A20506BCA
site_id 5a5cc26d44ae24bc73619491
state 1
tx_bytes 10194080031
tx_bytes-d 14699
type uap
uptime 34344
user-num_sta 6
version 3.9.27.8537
wifi_caps 16373
wlangroup_id_na 5a5cc27b44ae24bc7361949c
wlangroup_id_ng 5a5cc27b44ae24bc7361949c
x
x_authkey 2a535d338f0f505848719ca9fe5d16b6
x_fingerprint 81:9c:40:bc:c5:32:27:72:33:bf:94:cd:5c:dc:75:b9
x_inform_authkey 2a535d338f0f505848719ca9fe5d16b6
x_ssh_hostkey_fingerprint 81:9c:40:bc:c5:32:27:72:33:bf:94:cd:5c:dc:75:b9
x_vwirekey 2f21f46cb3264c0516b64c2c2f77c1dc
y
antenna_table:
HASH(0x4685e30)
config_network:
ip 10.68.0.139
type dhcp
countrycode_table:
downlink_table:
ethernet_table:
HASH(0x449fd38)
port_table:
radio_table:
HASH(0x4740c68)
HASH(0x3e2a8c0)
radio_table_stats:
HASH(0x45b5b88)
HASH(0x459dfb8)
scan_radio_table:
ssh_session_table:
stat:
ap 78:8a:20:50:6b:ca
bytes 28446166794
datetime 2018-07-21T17:15:00Z
duration 185691000
guest-rx_bytes 0
guest-rx_crypts 0
guest-rx_dropped 0
guest-rx_errors 0
guest-rx_frags 0
guest-rx_packets 0
guest-tx_bytes 0
guest-tx_dropped 0
guest-tx_errors 0
guest-tx_packets 0
guest-tx_retries 0
o ap
oid 78:8a:20:50:6b:ca
rx_bytes 18252086763
rx_crypts 8471
rx_dropped 8475
rx_errors 8475
rx_frags 0
rx_packets 14680466
site_id 5a5cc26d44ae24bc73619491
time 1532193300000
tx_bytes 10194080031
tx_dropped 4680
tx_errors 12532
tx_packets 13367373
tx_retries 324952
user-rx_bytes 18252086763
user-rx_crypts 8471
user-rx_dropped 8475
user-rx_errors 8475
user-rx_frags 0
user-rx_packets 14680466
user-tx_bytes 10194080031
user-tx_dropped 4680
user-tx_errors 12532
user-tx_packets 13367373
user-tx_retries 324952
user-wifi0-ath0-5a5cc37144ae24bc736194a6-rx_bytes 17145768879
user-wifi0-ath0-5a5cc37144ae24bc736194a6-rx_crypts 59
user-wifi0-ath0-5a5cc37144ae24bc736194a6-rx_dropped 63
user-wifi0-ath0-5a5cc37144ae24bc736194a6-rx_errors 63
user-wifi0-ath0-5a5cc37144ae24bc736194a6-rx_packets 12730925
user-wifi0-ath0-5a5cc37144ae24bc736194a6-tx_bytes 4452523297
user-wifi0-ath0-5a5cc37144ae24bc736194a6-tx_dropped 14
user-wifi0-ath0-5a5cc37144ae24bc736194a6-tx_packets 8870078
user-wifi0-ath0-5a5cc37144ae24bc736194a6-tx_retries 324952
user-wifi0-rx_bytes 17145768879
user-wifi0-rx_crypts 59
user-wifi0-rx_dropped 63
user-wifi0-rx_errors 63
user-wifi0-rx_frags 0
user-wifi0-rx_packets 12730925
user-wifi0-tx_bytes 4452523297
user-wifi0-tx_dropped 14
user-wifi0-tx_errors 0
user-wifi0-tx_packets 8870078
user-wifi0-tx_retries 324952
user-wifi1-ath2-5a5cc37144ae24bc736194a6-rx_bytes 1106317884
user-wifi1-ath2-5a5cc37144ae24bc736194a6-rx_crypts 8412
user-wifi1-ath2-5a5cc37144ae24bc736194a6-rx_dropped 8412
user-wifi1-ath2-5a5cc37144ae24bc736194a6-rx_errors 8412
user-wifi1-ath2-5a5cc37144ae24bc736194a6-rx_packets 1949541
user-wifi1-ath2-5a5cc37144ae24bc736194a6-tx_bytes 5741556734
user-wifi1-ath2-5a5cc37144ae24bc736194a6-tx_dropped 4666
user-wifi1-ath2-5a5cc37144ae24bc736194a6-tx_errors 12532
user-wifi1-ath2-5a5cc37144ae24bc736194a6-tx_packets 4497295
user-wifi1-rx_bytes 1106317884
user-wifi1-rx_crypts 8412
user-wifi1-rx_dropped 8412
user-wifi1-rx_errors 8412
user-wifi1-rx_frags 0
user-wifi1-rx_packets 1949541
user-wifi1-tx_bytes 5741556734
user-wifi1-tx_dropped 4666
user-wifi1-tx_errors 12532
user-wifi1-tx_packets 4497295
user-wifi1-tx_retries 0
wifi0-rx_bytes 17145768879
wifi0-rx_crypts 59
wifi0-rx_dropped 63
wifi0-rx_errors 63
wifi0-rx_frags 0
wifi0-rx_packets 12730925
wifi0-tx_bytes 4452523297
wifi0-tx_dropped 14
wifi0-tx_errors 0
wifi0-tx_packets 8870078
wifi0-tx_retries 324952
wifi1-rx_bytes 1106317884
wifi1-rx_crypts 8412
wifi1-rx_dropped 8412
wifi1-rx_errors 8412
wifi1-rx_frags 0
wifi1-rx_packets 1949541
wifi1-tx_bytes 5741556734
wifi1-tx_dropped 4666
wifi1-tx_errors 12532
wifi1-tx_packets 4497295
wifi1-tx_retries 0
sys_stats:
loadavg_1 0.00
loadavg_15 0.05
loadavg_5 0.01
mem_buffer 0
mem_total 129302528
mem_used 67190784
system-stats:
cpu 1.5
mem 52.0
uptime 34344
uplink:
ip 0.0.0.0
mac 78:8a:20:50:6b:ca
max_speed 1000
name eth0
netmask 0.0.0.0
num_port 1
rx_bytes 1125785895
rx_bytes-r 1179
rx_dropped 11
rx_errors 0
rx_multicast 0
rx_packets 949984
speed 1000
tx_bytes 68457860
tx_bytes-r 689
tx_dropped 0
tx_errors 0
tx_packets 407684
type wire
uplink_table:
vap_table:
HASH(0x43a0f40)
HASH(0x42a96c0)
vwire_table:
vwire_vap_table:
HASH(0x4481950)
HASH(0x434d368)
5a5cccb044ae24bc736194c2:
_id 5a5cccb044ae24bc736194c2
_uptime 34386
board_rev 33
bytes 2713894833
bytes-d 12184
bytes-r 870
cfgversion ad6e5105ee2a8f96
connect_request_ip 10.68.0.5
connect_request_port 52266
device_id 5a5cccb044ae24bc736194c2
fw_caps 196151
guest-num_sta 0
guest_token 5898B0687636FE464A167F47656465A0
hw_caps 0
inform_ip 10.68.0.21
inform_url http://10.68.0.21:8080/inform
ip 10.68.0.5
known_cfgversion ad6e5105ee2a8f96
last_seen 1532379177
led_override default
license_state registered
mac 78:8a:20:83:5d:ce
map_id
meshv3_peer_mac
model U7LT
name OG
num_sta 2
outdoor_mode_override default
rx_bytes 70754677
rx_bytes-d 2237
serial 788A20835DCE
site_id 5a5cc26d44ae24bc73619491
state 1
tx_bytes 2643140156
tx_bytes-d 9947
type uap
uptime 34386
user-num_sta 2
version 3.9.27.8537
wifi_caps 16373
wlangroup_id_na 5a5cc27b44ae24bc7361949c
wlangroup_id_ng 5a5cc27b44ae24bc7361949c
x
x_authkey 320a6c0e28e1b6adb27284daf8e07c47
x_fingerprint 06:42:84:c6:a0:cc:a2:2a:12:cd:f1:5c:37:f0:5c:d7
x_inform_authkey 320a6c0e28e1b6adb27284daf8e07c47
x_ssh_hostkey_fingerprint 06:42:84:c6:a0:cc:a2:2a:12:cd:f1:5c:37:f0:5c:d7
x_vwirekey 8a06cc9f907120fec44ac951d4a6cdf2
y
antenna_table:
HASH(0x43aadd0)
config_network:
ip 10.68.0.147
type dhcp
countrycode_table:
downlink_table:
ethernet_table:
HASH(0x43abb50)
port_table:
radio_table:
HASH(0x47317d0)
HASH(0x4401570)
radio_table_stats:
HASH(0x3e18748)
HASH(0x4694be0)
scan_radio_table:
ssh_session_table:
stat:
ap 78:8a:20:83:5d:ce
bytes 2713894833
datetime 2018-07-21T17:15:00Z
duration 185685000
guest-rx_bytes 0
guest-rx_crypts 0
guest-rx_dropped 0
guest-rx_errors 0
guest-rx_frags 0
guest-rx_packets 0
guest-tx_bytes 0
guest-tx_dropped 0
guest-tx_errors 0
guest-tx_packets 0
guest-tx_retries 0
o ap
oid 78:8a:20:83:5d:ce
rx_bytes 70754677
rx_crypts 34
rx_dropped 34
rx_errors 34
rx_frags 0
rx_packets 441989
site_id 5a5cc26d44ae24bc73619491
time 1532193300000
tx_bytes 2643140156
tx_dropped 242691
tx_errors 7970
tx_packets 2112235
tx_retries 119515
user-rx_bytes 70754677
user-rx_crypts 34
user-rx_dropped 34
user-rx_errors 34
user-rx_frags 0
user-rx_packets 441989
user-tx_bytes 2643140156
user-tx_dropped 242691
user-tx_errors 7970
user-tx_packets 2112235
user-tx_retries 119515
user-wifi0-ath0-5a5cc37144ae24bc736194a6-rx_bytes 68956819
user-wifi0-ath0-5a5cc37144ae24bc736194a6-rx_crypts 6
user-wifi0-ath0-5a5cc37144ae24bc736194a6-rx_dropped 6
user-wifi0-ath0-5a5cc37144ae24bc736194a6-rx_errors 6
user-wifi0-ath0-5a5cc37144ae24bc736194a6-rx_packets 428599
user-wifi0-ath0-5a5cc37144ae24bc736194a6-tx_bytes 2549113239
user-wifi0-ath0-5a5cc37144ae24bc736194a6-tx_dropped 62108
user-wifi0-ath0-5a5cc37144ae24bc736194a6-tx_packets 2041880
user-wifi0-ath0-5a5cc37144ae24bc736194a6-tx_retries 119515
user-wifi0-rx_bytes 68956819
user-wifi0-rx_crypts 6
user-wifi0-rx_dropped 6
user-wifi0-rx_errors 6
user-wifi0-rx_frags 0
user-wifi0-rx_packets 428599
user-wifi0-tx_bytes 2549113239
user-wifi0-tx_dropped 62108
user-wifi0-tx_errors 0
user-wifi0-tx_packets 2041880
user-wifi0-tx_retries 119515
user-wifi1-ath2-5a5cc37144ae24bc736194a6-rx_bytes 1797858
user-wifi1-ath2-5a5cc37144ae24bc736194a6-rx_crypts 28
user-wifi1-ath2-5a5cc37144ae24bc736194a6-rx_dropped 28
user-wifi1-ath2-5a5cc37144ae24bc736194a6-rx_errors 28
user-wifi1-ath2-5a5cc37144ae24bc736194a6-rx_packets 13390
user-wifi1-ath2-5a5cc37144ae24bc736194a6-tx_bytes 94026917
user-wifi1-ath2-5a5cc37144ae24bc736194a6-tx_dropped 180583
user-wifi1-ath2-5a5cc37144ae24bc736194a6-tx_errors 7970
user-wifi1-ath2-5a5cc37144ae24bc736194a6-tx_packets 70355
user-wifi1-rx_bytes 1797858
user-wifi1-rx_crypts 28
user-wifi1-rx_dropped 28
user-wifi1-rx_errors 28
user-wifi1-rx_frags 0
user-wifi1-rx_packets 13390
user-wifi1-tx_bytes 94026917
user-wifi1-tx_dropped 180583
user-wifi1-tx_errors 7970
user-wifi1-tx_packets 70355
user-wifi1-tx_retries 0
wifi0-rx_bytes 68956819
wifi0-rx_crypts 6
wifi0-rx_dropped 6
wifi0-rx_errors 6
wifi0-rx_frags 0
wifi0-rx_packets 428599
wifi0-tx_bytes 2549113239
wifi0-tx_dropped 62108
wifi0-tx_errors 0
wifi0-tx_packets 2041880
wifi0-tx_retries 119515
wifi1-rx_bytes 1797858
wifi1-rx_crypts 28
wifi1-rx_dropped 28
wifi1-rx_errors 28
wifi1-rx_frags 0
wifi1-rx_packets 13390
wifi1-tx_bytes 94026917
wifi1-tx_dropped 180583
wifi1-tx_errors 7970
wifi1-tx_packets 70355
wifi1-tx_retries 0
sys_stats:
loadavg_1 0.02
loadavg_15 0.05
loadavg_5 0.03
mem_buffer 0
mem_total 129302528
mem_used 67751936
system-stats:
cpu 2.2
mem 52.4
uptime 34386
uplink:
ip 0.0.0.0
mac 78:8a:20:83:5d:ce
max_speed 1000
name eth0
netmask 0.0.0.0
num_port 1
rx_bytes 284932100
rx_bytes-r 356
rx_dropped 11
rx_errors 0
rx_multicast 0
rx_packets 296273
speed 1000
tx_bytes 21378929
tx_bytes-r 70
tx_dropped 0
tx_errors 0
tx_packets 106473
type wire
uplink_table:
vap_table:
HASH(0x41d2348)
HASH(0x472f6e8)
vwire_table:
vwire_vap_table:
HASH(0x46949a0)
HASH(0x4571228)
alerts_unarchived:
clients:
5a5ce6a644ae01f893b1f67f:
_id 5a5ce6a644ae01f893b1f67f
_last_seen_by_uap 1532379183
_uptime_by_uap 25192
ap_mac 78:8a:20:50:6b:ca
assoc_time 1531462133
bssid 78:8a:20:51:6b:ca
bytes-r 2
ccq 991
channel 1
dhcpend_time 570
essid FR@home
first_seen 1516037797
fixed_ip 10.68.0.22
hostname amazon-ea128f8f2
idletime 5
ip 10.68.0.22
last_seen 1532379183
latest_assoc_time 1532353991
mac 44:65:0d:19:5d:c3
name Amazon Fire Tablet
network_id 5a5cc27b44ae24bc7361949a
noise -108
note
oui AmazonTe
radio ng
radio_name wifi0
radio_proto ng
roam_count 4
rssi 46
rx_bytes 60500496
rx_bytes-r 2
rx_packets 321758
rx_rate 1000
signal -62
site_id 5a5cc26d44ae24bc73619491
tx_bytes 229110923
tx_bytes-r 0
tx_packets 274540
tx_power 34
tx_rate 71426
uptime 917050
user_id 5a5ce6a644ae01f893b1f67f
usergroup_id
vlan 0
5a5ce98b44ae01f893b1f6da:
_id 5a5ce98b44ae01f893b1f6da
_last_seen_by_uap 1532379183
_uptime_by_uap 7611
ap_mac 78:8a:20:50:6b:ca
assoc_time 1532334587
bssid 78:8a:20:52:6b:ca
bytes-r 0
ccq 333
channel 52
dhcpend_time 339830
essid FR@home
first_seen 1516038539
hostname Robin
idletime 24
ip 10.68.0.113
last_seen 1532379183
latest_assoc_time 1532371572
mac f0:24:75:e5:3c:80
noise -105
oui Apple
radio na
radio_name wifi1
radio_proto ac
roam_count 20
rssi 31
rx_bytes 26201597
rx_bytes-r 0
rx_packets 184341
rx_rate 200000
signal -74
site_id 5a5cc26d44ae24bc73619491
tx_bytes 1117744744
tx_bytes-r 0
tx_packets 832747
tx_power 34
tx_rate 200000
uptime 44596
user_id 5a5ce98b44ae01f893b1f6da
vlan 0
5a5cf12644ae01f893b1f776:
_id 5a5cf12644ae01f893b1f776
_last_seen_by_uap 1532379183
_uptime_by_uap 34313
ap_mac 78:8a:20:50:6b:ca
assoc_time 1531922800
bssid 78:8a:20:51:6b:ca
bytes-r 139
ccq 991
channel 1
dhcpend_time 0
essid FR@home
first_seen 1516040486
hostname Sybille
idletime 0
ip 10.68.0.3
last_seen 1532379183
latest_assoc_time 1532344871
mac e8:de:27:c9:b5:cb
name PV Anlage
noise -108
oui Tp-LinkT
radio ng
radio_name wifi0
radio_proto ng
rssi 23
rx_bytes 94033707
rx_bytes-r 97
rx_packets 227779
rx_rate 58500
signal -85
site_id 5a5cc26d44ae24bc73619491
tx_bytes 24075258
tx_bytes-r 42
tx_packets 91517
tx_power 34
tx_rate 52000
uptime 456383
user_id 5a5cf12644ae01f893b1f776
usergroup_id
vlan 0
5a5d0aa544ae01f893b1f7e7:
_id 5a5d0aa544ae01f893b1f7e7
_last_seen_by_uap 1532379183
_uptime_by_uap 5288
ap_mac 78:8a:20:50:6b:ca
assoc_time 1532365565
bssid 78:8a:20:51:6b:ca
bytes-r 1422
ccq 488
channel 1
dhcpend_time 30
essid FR@home
first_seen 1516047013
fixed_ip 10.68.0.39
hostname DESKTOP-VF14LFK
idletime 0
ip 10.68.0.39
last_seen 1532379183
latest_assoc_time 1532373895
mac 98:5f:d3:f0:e5:1d
name Surface_Robert
network_id 5a5cc27b44ae24bc7361949a
noise -108
note
oui Microsof
radio ng
radio_name wifi0
radio_proto ng
rssi 46
rx_bytes 14014685
rx_bytes-r 389
rx_packets 77607
rx_rate 1000
signal -62
site_id 5a5cc26d44ae24bc73619491
tx_bytes 103445350
tx_bytes-r 1032
tx_packets 98798
tx_power 34
tx_rate 65000
uptime 13618
user_id 5a5d0aa544ae01f893b1f7e7
usergroup_id
vlan 0
5a5e33d944ae01f893b1fbe3:
_id 5a5e33d944ae01f893b1fbe3
_last_seen_by_uap 1532379183
_uptime_by_uap 237
ap_mac 78:8a:20:50:6b:ca
assoc_time 1532290452
bssid 78:8a:20:51:6b:ca
bytes-r 9
ccq 991
channel 1
dhcpend_time 0
essid FR@home
first_seen 1516123097
hostname AppleWaonRobert
idletime 1
ip 10.68.0.188
last_seen 1532379183
latest_assoc_time 1532378946
mac 68:ab:1e:07:c9:27
noise -108
oui Apple
radio ng
radio_name wifi0
radio_proto ng
roam_count 48
rssi 17
rx_bytes 3017962
rx_bytes-r 9
rx_packets 41688
rx_rate 11000
signal -91
site_id 5a5cc26d44ae24bc73619491
tx_bytes 2886942
tx_bytes-r 0
tx_packets 8575
tx_power 34
tx_rate 67482
uptime 88731
user_id 5a5e33d944ae01f893b1fbe3
vlan 0
5acb6305235a1103b5d097fa:
_id 5acb6305235a1103b5d097fa
_last_seen_by_uap 1532379177
_uptime_by_uap 23788
ap_mac 78:8a:20:83:5d:ce
assoc_time 1531999052
bssid 78:8a:20:84:5d:ce
bytes-r 2
ccq 991
channel 11
dhcpend_time 246590
essid FR@home
first_seen 1523278597
fixed_ip 10.68.0.153
hostname android-1eb0d347a5394c39
idletime 9
ip 10.68.0.26
last_seen 1532379177
latest_assoc_time 1532355389
mac 00:08:22:1c:7a:b4
name Tablet WZ
network_id 5a5cc27b44ae24bc7361949a
noise -109
note
oui InproCom
radio ng
radio_name wifi0
radio_proto ng
roam_count 7
rssi 36
rx_bytes 13497197
rx_bytes-r 2
rx_packets 130487
rx_rate 1000
signal -73
site_id 5a5cc26d44ae24bc73619491
tx_bytes 32229152
tx_bytes-r 0
tx_packets 60802
tx_power 34
tx_rate 72167
uptime 380125
user_id 5acb6305235a1103b5d097fa
usergroup_id
vlan 0
5b2c0bea235a1103b074a392:
_id 5b2c0bea235a1103b074a392
_last_seen_by_uap 1532379177
_uptime_by_uap 34352
ap_mac 78:8a:20:83:5d:ce
assoc_time 1532193446
bssid 78:8a:20:84:5d:ce
bytes-r 806
ccq 932
channel 11
dhcpend_time 310
essid FR@home
first_seen 1529613288
hostname raspberrypi
idletime 1
ip 10.68.0.21
last_seen 1532379177
latest_assoc_time 1532344826
mac b8:27:eb:84:60:44
noise -109
oui Raspberr
radio ng
radio_name wifi0
radio_proto ng
roam_count 1
rssi 19
rx_bytes 17319227832
rx_bytes-r 182
rx_packets 11671028
rx_rate 43265
signal -90
site_id 5a5cc26d44ae24bc73619491
tx_bytes 1147845661
tx_bytes-r 623
tx_packets 6338830
tx_power 34
tx_rate 72222
uptime 185731
user_id 5b2c0bea235a1103b074a392
vlan 0
5b3cba2e235a1103b959d90f:
_id 5b3cba2e235a1103b959d90f
_last_seen_by_uap 1532379183
_uptime_by_uap 836
ap_mac 78:8a:20:50:6b:ca
assoc_time 1532372583
bssid 78:8a:20:52:6b:ca
bytes-r 0
ccq 333
channel 52
dhcpend_time 0
essid FR@home
first_seen 1530706478
hostname Robert-X
idletime 26
ip 10.68.0.31
last_seen 1532379183
latest_assoc_time 1532378347
mac 64:5a:ed:4b:8b:34
noise -105
oui Apple
radio na
radio_name wifi1
radio_proto ac
rssi 40
rx_bytes 1000912
rx_bytes-r 0
rx_packets 8124
rx_rate 324000
signal -65
site_id 5a5cc26d44ae24bc73619491
tx_bytes 2156018
tx_bytes-r 0
tx_packets 3267
tx_power 34
tx_rate 360000
uptime 6600
user_id 5b3cba2e235a1103b959d90f
vlan 0
5b562770235a1103dfa136b0:
_id 5b562770235a1103dfa136b0
_last_seen_by_uap 1532377990
_uptime_by_uap 970
ap_mac 78:8a:20:50:6b:ca
assoc_time 1532372835
bssid 78:8a:20:52:6b:ca
bytes-r 0
ccq 991
channel 52
dhcpend_time 0
essid FR@home
first_seen 1532372848
hostname I-PhoneJurgen
idletime 296
ip 10.68.0.165
last_seen 1532377990
latest_assoc_time 1532377020
mac 64:a5:c3:44:3c:a4
noise -104
oui Apple
radio na
radio_name wifi1
radio_proto ac
rssi 7
rx_bytes 220188
rx_bytes-r 0
rx_packets 3663
rx_rate 6500
signal -97
site_id 5a5cc26d44ae24bc73619491
tx_bytes 279262
tx_bytes-r 0
tx_packets 525
tx_power 34
tx_rate 13000
uptime 5155
user_id 5b562770235a1103dfa136b0
vlan 0
events:
HASH(0x4552bb8)
HASH(0x4567ce0)
HASH(0x454f1c8)
HASH(0x4596960)
HASH(0x473cdc0)
HASH(0x45689b0)
HASH(0x4567320)
HASH(0x427f368)
HASH(0x4596888)
HASH(0x4692160)
HASH(0x472b158)
HASH(0x3c0b1d0)
HASH(0x472ef20)
HASH(0x3b9a360)
HASH(0x439cde8)
HASH(0x468a870)
HASH(0x4598e20)
HASH(0x45a5020)
HASH(0x473cbf8)
HASH(0x3c6c1a0)
HASH(0x4593fa0)
HASH(0x3e439b8)
HASH(0x4741a78)
HASH(0x4248c48)
HASH(0x4267580)
HASH(0x45b6470)
HASH(0x43be140)
HASH(0x425b020)
HASH(0x473d7b0)
HASH(0x43a1b58)
HASH(0x3c0c870)
HASH(0x4692340)
HASH(0x3e18a78)
HASH(0x4685e48)
HASH(0x43ae2c8)
HASH(0x4576b48)
HASH(0x4688018)
HASH(0x43b6988)
HASH(0x456a188)
HASH(0x439cc98)
HASH(0x473b548)
HASH(0x468c688)
HASH(0x43b4040)
HASH(0x43a4478)
HASH(0x4694130)
HASH(0x47418b0)
HASH(0x4697498)
HASH(0x40b4818)
HASH(0x4586a68)
HASH(0x43a5378)
HASH(0x4690cd8)
HASH(0x43a9b60)
HASH(0x473d2e8)
HASH(0x43a5f90)
HASH(0xfb3098)
HASH(0x45ade28)
HASH(0x424f060)
HASH(0x472f3e8)
HASH(0x4487368)
HASH(0x45b3418)
HASH(0x43a1b10)
HASH(0x473cf70)
HASH(0x457b458)
HASH(0x4688030)
HASH(0x43aa1d8)
HASH(0x43b6b98)
HASH(0x447e060)
HASH(0x43c0608)
HASH(0x4487080)
HASH(0x3e2cf98)
HASH(0x4166030)
HASH(0x41b04c8)
HASH(0x429f208)
HASH(0x3b9a198)
HASH(0x3b83918)
HASH(0x4571420)
HASH(0x43a1a50)
HASH(0x3e16110)
HASH(0x472cac8)
HASH(0x3db0b48)
HASH(0x473ee68)
HASH(0x45537d0)
HASH(0x459ee20)
HASH(0x4553500)
HASH(0x45a5200)
HASH(0x3e1aa38)
HASH(0x4691f98)
HASH(0x3e1ac78)
HASH(0x4285630)
HASH(0x42aaf80)
HASH(0x4735fa8)
HASH(0x4691dd0)
HASH(0x47392b0)
HASH(0x43ab550)
HASH(0x3f77e68)
HASH(0x43aa310)
HASH(0x43c2188)
HASH(0x4588c60)
HASH(0x473e790)
HASH(0xfb34a0)
HASH(0x4353420)
HASH(0x41879e0)
HASH(0x41dcbc8)
HASH(0x3db18d0)
HASH(0x47367e8)
HASH(0x473b9e0)
HASH(0x3e16158)
HASH(0x42a7ed8)
HASH(0x3db8910)
HASH(0x4598cd0)
HASH(0x45b0818)
HASH(0x41d2cf0)
HASH(0x4568c80)
HASH(0x4558e98)
HASH(0x45c0730)
HASH(0x43ab1f0)
HASH(0x43b6b68)
HASH(0x3b83ae0)
HASH(0x4475b38)
HASH(0x43c0b90)
HASH(0x42667d0)
HASH(0x439e750)
HASH(0x43c0f50)
HASH(0x427f350)
HASH(0x45b15c8)
HASH(0x3b9b088)
HASH(0x43a9f68)
HASH(0x468a4b0)
HASH(0x472f7a8)
HASH(0x473cb80)
HASH(0x4168b28)
HASH(0x3e30d00)
HASH(0x3c0c2d0)
HASH(0x40e2180)
HASH(0x456ab90)
HASH(0x456abc0)
HASH(0x456a938)
HASH(0x41b90a0)
HASH(0x4569f18)
HASH(0x3b9ab88)
HASH(0x3b9c020)
HASH(0x4569f78)
HASH(0x45a46a8)
HASH(0x3c80f40)
HASH(0x456aa40)
HASH(0x4576890)
HASH(0x439d190)
HASH(0x42a1648)
HASH(0x455df58)
HASH(0x4697858)
HASH(0x43b3a88)
HASH(0x472f358)
HASH(0x455dec8)
HASH(0x41b5f68)
HASH(0x4685e60)
HASH(0x3e1adc8)
HASH(0x3e1af00)
HASH(0x3bf4a10)
HASH(0x456a338)
HASH(0x3e1aff0)
HASH(0x3e1af78)
HASH(0x3e1b170)
HASH(0x3e1aa68)
HASH(0x3e1b3f8)
HASH(0x3e1b380)
HASH(0x3e1d160)
HASH(0x3e1acf0)
HASH(0x3e1d310)
HASH(0x3e1d448)
HASH(0x3e1daf0)
HASH(0x3e1b548)
HASH(0x3e1d7a8)
HASH(0x3e1d790)
HASH(0x3e1b620)
HASH(0x3e1d8f8)
HASH(0x3e1d6a0)
HASH(0x3e1d988)
HASH(0x3e1db68)
HASH(0x3e1d370)
HASH(0x3e1f5c0)
HASH(0x3e1f1b8)
HASH(0x3e1ef60)
HASH(0x3e1f278)
HASH(0x3e215d0)
HASH(0x3e1eba0)
HASH(0x3e1f038)
HASH(0x3e1ed68)
HASH(0x3e220c8)
HASH(0x3e1f638)
HASH(0x3e1f380)
HASH(0x3e21e70)
HASH(0x3e21960)
HASH(0x3e216d8)
HASH(0x3e1ef30)
HASH(0x3e23248)
HASH(0x3e21e10)
HASH(0x3e22380)
HASH(0x3e23698)
HASH(0x3e232d8)
HASH(0x3e21b28)
HASH(0x3e21ab0)
HASH(0x3e23380)
HASH(0x3e23638)
HASH(0x3e221d0)
HASH(0x3e22f00)
HASH(0x3e23a40)
HASH(0x3e24a08)
HASH(0x3e24ca8)
HASH(0x3e23488)
HASH(0x3e23740)
HASH(0x3e25368)
HASH(0x3e23ce0)
HASH(0x3e23938)
HASH(0x3e25200)
HASH(0x3e249d8)
HASH(0x3e24d38)
HASH(0x3e24af8)
HASH(0x3e253c8)
HASH(0x3e27600)
HASH(0x3e24e10)
HASH(0x4736470)
HASH(0x4182838)
HASH(0x43b0488)
HASH(0x43b0a70)
HASH(0x473b698)
HASH(0x41c3f10)
HASH(0x43c08f0)
HASH(0x41d17b8)
HASH(0x4692400)
HASH(0x43a6ad8)
HASH(0x4352f88)
HASH(0x3e2e850)
HASH(0x3e2ea30)
HASH(0x3e30bc8)
HASH(0x4400838)
helper:
password crypt:140a0xxxxxxxxx430652
username crypt:130bwwwwwwww2
hotspot:
voucherCache:
attr_value
vouchers:
httpParams:
header Cookie: unifises=Rbs62Wi9n9uX1Ey928urd30bwo4b89BK;\r\nCookie: csrf_token=729N2wdtiXI94bQbuSeF5DW3EpYLJWm3;
ignoreredirects 1
loglevel 5
method POST
noshutdown 0
timeout 5
hash:
sslargs:
SSL_verify_mode 0
unifi:
CONNECTED connected
deprecatedClientNames 1
eventPeriod 24
interval 30
updateStartTime 1532379186
url https://10.68.0.21:8443/api/s/default/
version 4
connectedClients:
5a5ce6a644ae01f893b1f67f 1
5a5ce98b44ae01f893b1f6da 1
5a5cf12644ae01f893b1f776 1
5a5d0aa544ae01f893b1f7e7 1
5a5e33d944ae01f893b1fbe3 1
5acb6305235a1103b5d097fa 1
5b2c0bea235a1103b074a392 1
5b3cba2e235a1103b959d90f 1
updateDispatch:
wlan_health:
num_adopted 2
Hi,
ich kann in den Daten kein Problem entdecken, I-PhoneJurgen ist ja zB auch disconnected. Und Robert-X war vielleicht wieder neu connected.
Ein List direkt nach dem Logeintrag
2018.07.23 20:57:37 5: my_unifi__controller (Unifi_SetClientReadings) - Client 'Robert-X' previously connected is now disconnected.
wäre gut. Das List ist ja deutlich später entstanden.
@Wuehler
Danke für deine Hilfe, seit ich das attr 'deprecatedClientNames' auf 0 gesetzt habe, funktioniert alles ohne Probleme!
Hallo,
ich bin in der Suche nicht fündig geworden, und würde das Thema gerne nocheinmal aufgreifen.
Mein Notifiy sieht so aus:
Internals:
CFGFN
DEF UAP_AC_PRO:WLAN_Handy_Pat_S8_last_seen:.* {
if((time() - time_str2num($EVENT)) > 60) {
fhem("set HANDY_PAT_DUMMY absent");
} else {
fhem("set HANDY_PAT_DUMMY present");
}
}
NAME ntfy_HANDY_PAT_presence
NOTIFYDEV UAP_AC_PRO
NR 203191
NTFY_ORDER 50-ntfy_unifi_presence
REGEXP UAP_AC_PRO:WLAN_Handy_Pat_S8_last_seen:.*
STATE 2018-07-26 15:49:33
TYPE notify
READINGS:
2018-07-26 15:47:20 state active
Attributes:
room Phone
Leider kommt er mit der Subtraction der Zeit nicht klar.
2018.07.26 15:47:28 1: PERL WARNING: Use of uninitialized value in subtraction (-) at (eval 698838) line 2.
2018.07.26 15:47:28 3: eval: my $SELF='ntfy_HANDY_PAT_presence';my $EVENT='WLAN_Handy_Pat_S8_last_seen: 2018-07-26 15:47:21';my $EVTPART0='WLAN_Handy_Pat_S8_last_seen:';my $TYPE='Unifi';my $NAME='UAP_AC_PRO';my $EVTPART1='2018-07-26';my $EVTPART2='15:47:21';{
if((time() - time_str2num($EVENT)) > 60) {
fhem("set HANDY_PAT_DUMMY absent");
} else {
fhem("set HANDY_PAT_DUMMY present");
}
}
Hat da jemand ne Idee?
Danke schon mal im Voraus.
Zitat von: Damian am 23 August 2015, 21:20:31
Das sollte auch einfach mit:
define di_unifi_presence DOIF ([myUnifiController:54245784e4b0b49b2ded629f_last_seen:sec] > 180) (set dummy disconnected) DOELSE (set dummy connected)
gehen.
Gruß
Damian
Warum benutzt Du nicht das absenceThreshold attribut?
Zitat von: patator am 26 Juli 2018, 15:51:03
Mein Notifiy sieht so aus:
Internals:
CFGFN
DEF UAP_AC_PRO:WLAN_Handy_Pat_S8_last_seen:.* {
if((time() - time_str2num($EVENT)) > 60) {
fhem("set HANDY_PAT_DUMMY absent");
} else {
fhem("set HANDY_PAT_DUMMY present");
}
}
Mein notify sieht so aus:
unifi:iPhone.SE_last_seen.* {
if (time() - time_str2num($EVTPART1." ".$EVTPART2) > 180) {
fhem('set anwesend.WLAN.iPhoneSE absent');
} else {
fhem('set anwesend.WLAN.iPhoneSE present');
}
}
Gruß, Christian
Gefühlt macht ihr das echt kompliziert. Warum nicht connected mit DOIF und dann mit wait Timer? ::)
Ich mach das per PRESENCE Modul
define Ronny PRESENCE function {ReadingsVal('Unify1','HANDYNAME','') eq "connected" ? 1 : 0} 60 60
HANDYNAME ist der der Hostname vom Handy
Unify1 (ja ich weiss falsch geschrieben) ist das Unifi Device
Funktioniert bei mir zuverlässig wie es soll und ich kann das als Basis von vielen Dingen nutzen.
Habe ich hier im Thread vor langer Zeit mal so gesehen ;)
Ronny
Zitat von: Maui am 26 Juli 2018, 16:47:52
Gefühlt macht ihr das echt kompliziert. Warum nicht connected mit DOIF und dann mit wait Timer? ::)
Es gibt halt viele Wege zum Ziel. Manche setzen auf Dingen auf, die "ab Werk" mitgeliefert werden, andere auf weitere Module wie DOIF, PRESENCE, ...
"Jedem Tierchen sein Plaisierchen", oder so...
War auch nicht als Vorwurf gemeint. Habe selbst teilweise eklige Konstrukte. Besonders Sachen, die ich zur Anfangszeit gebaut habe ;)
Moin zusammen,
Ich nutze denselben Einzeiler wie Ronny. Funktioniert super. Aber man wird halt recht spät disconnected. Der Vorteil der notify-Lösung ist, dass man den Mindestabwesenheitszeitraum selbst definieren kann.
Falls es jemand ganz eilig hat, seine Abwesenheit festzustellen funktioniert das übrigens mit mailalerts aus Unifi und mailcheck-Modul auch sehr gut (< 5 Sekunden bis disconnected). Dann braucht man das Unifi-Modul für presence im Übrigen überhaupt nicht.
VG,
Dirk
Hallo !
Schwierig, für mein Problem den richtigen Bereich zu finden, deshalb hier Ubiquiti Controller im Einsatz sind.
System: Raspberry Pi 3B mit aktuellem Raspbian
FHEM: Aktuelle Version Stand 10.07.18
Am 10.07.18 hab ich die Ubiquiti Controller Software auf dem Raspberry Pi installiert, parallel zu FHEM. Der Controller läuft und ist erreichbar. Am 10.07.18 konnte ich auch die Anwesenheit-Überwachung installieren - alles soweit gut. Nur komme ich seit heute nicht mehr auf das FHEM Webinterface (FHEM läuft aber im Hintergrund, die Automatisierung funktioniert).
Ubiquiti Contoller hat Port 8443
FHEM hat Port 8083
Was läuft falsch ? Wie komme ich wieder an die FHEM Weboberfläche ?
Edit:
Hmmm, nach zwei mal Reboot läuft es jetzt wieder. Sehr merkwürdig. - sorry...
Was sagt denn das FHEM-Log?
Hallo,
das Module Unifi connected nicht mehr.
Mein Unifi Controller 5.8.28, läuft auf eine Qnap Server in einem Container.
Seit ca. 2 Tagen bekomme ich einfach keine Verbindung mehr hin, vorher keine Probleme.
Ich kann so sporadisch keinen Fehler feststellen.
Hat einer einen Rat?
Internals:
DEF 192.168.0.2 8443 crypt:???? crypt:????? 30 default 4
NAME Unifi_1
NOTIFYDEV global
NR 329
NTFY_ORDER 50-Unifi_1
STATE disconnected
TYPE Unifi
VERSION 3.0.4
READINGS:
2018-08-18 21:48:44 state disconnected
accespoints:
alerts_unarchived:
clients:
events:
helper:
password crypt:????
username crypt:????
hotspot:
vouchers:
httpParams:
header
ignoreredirects 1
loglevel 5
method POST
noshutdown 0
timeout 5
hash:
sslargs:
SSL_verify_mode 0
unifi:
CONNECTED disconnected
deprecatedClientNames 0
eventPeriod 24
interval 30
url https://192.168.0.2:8443/api/s/default/
version 4
updateDispatch:
wlans:
Attributes:
DbLogExclude .*
deprecatedClientNames 0
disable 0
room 0.1 Unifi,Zuhause
verbose 5
Log:
2018.08.18 21:48:38 5: Unifi_1: get called with ?.
2018.08.18 21:48:44 5: Unifi_1 (Unifi_Login_Send) - executed.
2018.08.18 21:48:44 5: Unifi_1: Defined with url:https://192.168.0.2:8443/api/s/default/, interval:30, version:4
2018.08.18 21:48:44 5: Unifi_1 (Unifi_Notify) - executed.
2018.08.18 21:48:44 5: Unifi_1 (Unifi_Notify) - executed. - Remove all Timers & Call DoUpdate...
2018.08.18 21:48:44 5: Unifi_1 (Unifi_DoUpdate) - executed.
2018.08.18 21:48:44 5: Unifi_1 (Unifi_Login_Send) - executed.
2018.08.18 21:48:44 5: Unifi_1 (Unifi_Login_Receive) - executed.
2018.08.18 21:48:44 1: Unifi_1 (Unifi_Login_Receive) - Login Failed! Invalid username or password! - state:'error' - msg:'api.err.Invalid'
2018.08.18 21:48:44 5: Unifi_1 (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
Laut Log ist user oder Passwort falsch.
Gelöst (Unifi connected):
Warum auch immer, gibt es auf einmal ein Problem mit einem deutschen Sonderzeichen ,,ß" im Passwort!!!
Natürlich hatte ich im Log gesehen, das eventuell User oder Passwort falsch ist und hatte diese auch mehrfach neu eingegeben.
Da das Module Unifi schon lange bei mir läuft, mit demselben User und Passwort, bin ich erst mal nicht darauf gekommen,
eventuell das Passwort zu ändern und auf Sonderzeichen zu verzichten.
Es Läuft, das ist erstmal das Wichtigste.
Sehr schön. Hast du vor drei Tagen etwas anderes geupdated?
Nicht bewusst, deshalb finde ich es ja irgendwie komisch.
Vielleicht ein automatisches Update auf der Qnap. Na egal. Hauptsache es läuft wieder. ;)
Beim Update von Version 5.7.x auf 5.8.x wurden neue PW Richtlinien für den Adminaccount eingeführt.
Bei mir führte dies dazu, dass ich mich am Controller auch erstmal nicht anmelden konnte.
Lösung war hier nur PW in der DB ändern und dann wieder einloggen. Bei meiner 2ten Installation habe ich dann vorher das PW gegen eines getauscht welches den PW Richtlinien entsprochen hat.....
Kann mir jemand sagen wie ich folgendes löse?
Ich habe ein Presence für "Unifi:-UC_wlan_guests" eingerichtet.
Wenn der Wert ".0" lautet dann "absent" wenn der Wert ".1" lautet dann "present"
event Unifi:-UC_wlan_guests:.0 Unifi:-UC_wlan_guests:.1
Was aber wenn mehrere Gäste im Haus sind? Ich wüsste gerne wie ich das angeben muss das er jeden Wert außer ".0" als present setzt.
Ich denke es geht nur um die Schreibweise aber ich komm da nicht mehr weiter.
Grüße Dave
Zitat von: davedeluxe am 06 September 2018, 16:04:15
Kann mir jemand sagen wie ich folgendes löse?
Ich habe ein Presence für "Unifi:-UC_wlan_guests" eingerichtet.
Wenn der Wert ".0" lautet dann "absent" wenn der Wert ".1" lautet dann "present"
event Unifi:-UC_wlan_guests:.0 Unifi:-UC_wlan_guests:.1
Was aber wenn mehrere Gäste im Haus sind? Ich wüsste gerne wie ich das angeben muss das er jeden Wert außer ".0" als present setzt.
Ich denke es geht nur um die Schreibweise aber ich komm da nicht mehr weiter.
Grüße Dave
Hallo Dave,
dann zeig uns doch mal was Du schon hast?
meine Glaskugel sagt nur, Du willst nach Rom, aber nicht welchen der vielen Wege Du benutzen willst.
Danke
Wuppi
Hi, wie bereits geschrieben sieht das gabze so aus:
event Unifi:-UC_wlan_guests:.0 Unifi:-UC_wlan_guests:.1
Sobald sich der Wert auf 2 oder höher ändert klappt das ganze allerdings nicht mehr.
gebe ich das so an:
event Unifi:-UC_wlan_guests:.0 Unifi:-UC_wlan_guests:*
Wird bei 0 Gästen kein Absent eingestellt.
Also brauche ich:
event Unifi:-UC_wlan_guests:.0 Unifi:-UC_wlan_guests:*(außer. 0)
Zitat von: davedeluxe am 06 September 2018, 16:23:04
Hi, wie bereits geschrieben sieht das gabze so aus:
event Unifi:-UC_wlan_guests:.0 Unifi:-UC_wlan_guests:.1
Sobald sich der Wert auf 2 oder höher ändert klappt das ganze allerdings nicht mehr.
gebe ich das so an:
event Unifi:-UC_wlan_guests:.0 Unifi:-UC_wlan_guests:*
Wird bei 0 Gästen kein Absent eingestellt.
Also brauche ich:
event Unifi:-UC_wlan_guests:.0 Unifi:-UC_wlan_guests:*(außer. 0)
mach doch mal ein List von dem Presence Device
Internals:
DEF event Unifi:-UC_wlan_guests:.0 Unifi:-UC_wlan_guests:.1
EVENT_ABSENT Unifi:-UC_wlan_guests:.0
EVENT_PRESENT Unifi:-UC_wlan_guests:.1
MODE event
NAME Presence_Guest
NOTIFYDEV Unifi,global
NR 414
NTFY_ORDER 50-Presence_Guest
STATE absent
TYPE PRESENCE
Helper:
DBLOG:
state:
DbLog:
TIME 1536247875.47141
VALUE absent
READINGS:
2018-09-06 15:54:35 model event
2018-09-06 17:31:15 presence absent
2018-09-06 17:31:15 state absent
helper:
CURRENT_STATE absent
Attributes:
presence Presence_ALL
room Umgebung
userattr presence presence_map structexclude
verbose 0
Spontane Idee: mach dir ein userreading, dass du bei 0 auf 0 setzt und bei >0 auf 1.
Internals:
DEF event Unifi:-UC_wlan_guests:.0 Unifi:-UC_wlan_guests:.1
EVENT_ABSENT Unifi:-UC_wlan_guests:.0
EVENT_PRESENT Unifi:-UC_wlan_guests:.1
MODE event
NAME Presence_Guest
NOTIFYDEV Unifi,global
NR 414
NTFY_ORDER 50-Presence_Guest
STATE absent
TYPE PRESENCE
Helper:
DBLOG:
state:
DbLog:
TIME 1536247875.47141
VALUE absent
READINGS:
2018-09-06 15:54:35 model event
2018-09-06 17:31:15 presence absent
2018-09-06 17:31:15 state absent
helper:
CURRENT_STATE absent
Attributes:
presence Presence_ALL
room Umgebung
userattr presence presence_map structexclude
verbose 0
code tags das # Zeichen über den Smileys machen das ganze ein wenig besser lesbar ;-)
in der Commandref zu dem Presence Befehl steht, dass Du eine RegEx auf das Event setzen kannst ....
also sollte es mit
event Unifi:-UC_wlan_guests:.0 Unifi:-UC_wlan_guests:.[1-9]
für maximal 9 Gäste .... für mehr musst Du die RegEx dann entsprechend erweitern
Gibt es evtl. auch die Möglichkeit die externe IP aus dem Unifi Controller auszulesen?
Paul
Habe jetzt noch nicht groß drüber nachgedacht, was für Fälle es da geben kann. Wo steht die externe IP bei dir im Controller?
Ich habe ein Unifi Security Gateway. Mir geht es um die IP-Adresse von dessen WAN-Anschluss. Unter den Eigenschaften des Gerätes Details->WAN kann ich die IP-Adresse sehen.
Paul
Hi Paul,
Mal eben so wird das vermutlich nicht gehen. Möglich sollte das aber sein. Ich denke ein Submodul/eigenes Device für den USG wäre der richtige Ansatz, ähnlich dem UnifiSwitch.
Bin gerade nicht am Rechner und auch sonst viel unterwegs, kann daher nicht selbst nachsehen. Aber das vermutlich im ersten Satz meinte ich folgendermaßen:
Mach mal verbose auf 5 im Unifi-Device. Dann müssten alle JSON-Nachrichten im log auftauchen. Wenn du in einer der Nachrichten die externe IP findest ist der Aufwand wieder geringer.
Wenn nicht braucht es neue API-calls und ein neues Submodul.
VG, Dirk
Danke Dirk für dein Feedback.
Ich habe die IP-Adresse im Server.log des Unifi-Controllers gefunden und lese sie nun dort aus.
Paul
Zitat von: Wuehler am 12 September 2018, 21:36:50
Ich denke ein Submodul/eigenes Device für den USG wäre der richtige Ansatz, ähnlich dem UnifiSwitch.
Ein eigenes Submodul für die USG wäre toll. Sehr interessant wären dabei die
Ergebnisse des Speedtests. Da ich hier per Hybrid angebunden bin schwanken diese Werte bei mir ganz ordentlich und es wäre toll, wenn FHEM die Ergebnisse des letzten Tests auswerten könnte.
Leider finde ich den FHEM-Logs keine JSON-Meldungen zur USG ... nur zu meinen Switches.
Moin,
habe mir das mal kurz angesehen, war beinahe schon fast alles vorhanden. Im Anhang eine nur schnell durchgetestete Version. Müssen wir mal überlegen, ob es ein eigenes Modul für den USG wird.
@Paul.baumann: Dabei ist mir aufgefallen, dass auch die WAN-IP da mit drin steht. Ist jetzt auch in der Version als Reading vorhanden.
VG,
Dirk
Danke, die Speedtest-Ergebnisse funktionieren perfekt!
Die WAN-IP habe ich jetzt aber noch nicht gefunden ... war für mich persönlich jetzt aber auch nicht wichtig ;-)
Jetzt im Anhang zwei posts vorher auch die wan-ip. Hatte die falsche Datei hochgeladen.
WAN-IP klappt einwandfrei. Vielen Dank!
Aber könnte es sein, dass die Speedtest-Ergebnisse nur beim Modulstart einmalig ausgewertet werden und dann nie wieder?
Die Testergebnisse sind bei mir lt. Unifi Controller immer recht "schwankend" (ich lasse den Test alle 45min ausführen) und daher wäre es toll, wenn das Modul dies auch regelmäßig abfragen könnte.
EDIT: Sorry, klappt alles einwandfrei. War wohl nur Einbildung ;-)
WAN-IP klappt einwandfrei.
Bei mir auch ...
Vielen Dank!
Läuft wirklich prima. Danke für das tolle Modul!
Es wäre zauberhaft, wenn die aktuelle Version im Repository eingepflegt werden könnte 8)
Habe noch die Doku ergänzt und gerade hochgeladen. Morgen nach 8 Uhr dann im Update.
Das mit der WAN-IP klappt wunderbar,vielen Dank :)
Eine Frage dazu.Wie kann man sich dann eine Telegram Nachricht schicken lassen,wenn die WAN-IP sich geändert hat und diese auch gleich mit senden ??
Beste Grüße
Falkes
ungefähr so, ungetestet:
defmod unifi_new_wan_ip notify Unifi:-UC_wan_ip:.*{ \
fhem('set TelegramBotmessage @xxxxx neue Wan-IP: '.$EVENT);;\
}
Vielen dank... :) Das werde ich gleich mal ausprobieren.
Beste Grüße
Falkes
Hi zusammen,
mir ist ein (für mich) unerklärliches Verhalten aufgefallen:
Das state Reading in FHEM zeigt "connected" an. Wenn ich jetzt den UniFi Controller beende, wechselt der status nicht auf "disconnected". Erst wenn ich eine Änderung im DEF Bereich vornehme, ändert sich STATE (richtigerweise) auf "disconnected". Andersherum funktioniert es: wenn STATE "disconnected" ist und ich den UniFi Controller starte, wechselt der STATE Wert auf "connected"
Habt ihr Tipps, wonach ich suchen sollte?
Danke und Gruss
Hi kalleknx,
bin leider erst jetzt zum Nachsehen gekommen. In irgendeiner Controller-Version hat sich evtl. an den Fehlermeldungen etwas geändert. Im Anhang mal ein kleiner Fix dazu. Schau mal nach, ob es bei dir damit funktioniert.
VG,
Dirk
Hallo,
mein unifi Fhem Modul lief bisher ohne Probleme. Jetzt merkte ich jedoch, dass er nicht mehr connecten kann.
Mit Sicherheit nach dem Unifi Controller Update auf
5.9.29 passiert, welches bei mir auf dem Unifi Key läuft.
Ich habe das Backup nochmal drüber recovert. Ich kann mich mit meinem Admin und auch mit meinen dafür angelgeten readonly "fhem" user am Controller anmelden.
Jedoch wird in der Log immer behauptet:
UnifiController (Unifi_Login_Receive) - Login Failed! Invalid username or password! - state:'error' - msg:'api.err.Invalid'
Und das Modul ist disconected.
Angelegt ist es mit "defmod myunifi Unifi 192.168.90.250 8443 benutzer passwort 180 default 4"
Weder Benutzer noch Passwort haben Umlaute.
Hoffe mir kann jemand helfen.
Vielen Dank Gruß , Rene
Hi,
Bekommst du bei
get Unifi showAccount
Den korrekte User/Passwort angezeigt?
Hallo,
nein es kommt "Unknown argument showAccount, choose one of poeState voucherList:all, voucher:"
Dann hast du nicht die aktuelle Version des Moduls. Welche Version steht im internal version?
Wo sehe ich das?
Ich habe eine 74_Unifi.pm Moduldatei
16100 2018-02-05 22:35:27Z wuehler
V 2.1.4
ok, nun habe ich es mal mit "update unifi" probiert. Ein normales "update" mache ich eigentlich regelmäßig. Komisch.
Jetzt habe ich 74_Unifi.pm 17650 2018-10-31 10:53:51Z wuehler V 3.0.5 und bekomme auch mit "get myunifi showAccount" die Daten angezeigt.
Ach und siehe da, er ist connected. :-)
Vielen Dank für den support. Da freu ich mich.
THX Gruß Rene
Gerne.
Hast du das Unifi-Modul im global-Attribut exclide-from-update?
Zitat von: Wuehler am 19 November 2018, 21:23:49
Hi kalleknx,
bin leider erst jetzt zum Nachsehen gekommen. In irgendeiner Controller-Version hat sich evtl. an den Fehlermeldungen etwas geändert. Im Anhang mal ein kleiner Fix dazu. Schau mal nach, ob es bei dir damit funktioniert.
VG,
Dirk
Leider kein Unterschied bei mir. Welche Infos benötigst Du, um der Sache auf den Grund gehen zu können?
Danke und Gruss
kalle
Moin kalle,
Bitte mal im Unifi-Modul verbose auf 5 setzen, Test durchführen und das Log hier posten. Darin sollte sie Fehlermeldung enthalten sein, auf die das Modul noch nicht reagiert.
Grüße,
Dirk
Hallo wuehler,
jedesmal, wenn ich mein Gast-WLAN aktiviere oder deaktviere blockiert irgendetwas FHEM. Ich kann zwar das Verhalten reproduzieren, aber nicht erkennen woran das liegen könnte.
Ich habe das Modul mal auf verbose 5 gestellt und das Gast-WLAN aktiviert und deaktiviert.
Beim Aktivieren steht im Log folgendes:
2018.11.24 07:09:00 5: UniFi_Controller: set called with enableWLAN Kerberos_Gastzugang
2018.11.24 07:09:00 4: UniFi_Controller: set enableWLAN
2018.11.24 07:09:00 5: UniFi_Controller (Unifi_WlanconfRest_Send) - executed with {"schedule":[],"wlangroup_id":"5a19f5d6e4b0af2d86e93b22","enabled":true,"minrate_ng_advertising_rates":false,"mac_filter_policy":"allow","minrate_na_enabled":false,"group_rekey":3600,"wpa_enc":"ccmp","minrate_na_data_rate_kbps":6000,"minrate_ng_data_rate_kbps":1000,"is_guest":true,"mac_filter_enabled":false,"wep_idx":1,"_id":"5a1fd769e4b067e43aff3b98","bc_filter_list":[],"mac_filter_list":[],"site_id":"5a19f5d3e4b0af2d86e93b17","vlan":"40","x_iapp_key":"bdd6ebbfe499476e9fed44885d9a9490","dtim_ng":1,"vlan_enabled":true,"minrate_na_beacon_rate_kbps":6000,"minrate_ng_enabled":false,"minrate_ng_beacon_rate_kbps":1000,"security":"wpapsk","dtim_mode":"default","usergroup_id":"5a19f5d6e4b0af2d86e93b21","minrate_na_advertising_rates":false,"bc_filter_enabled":false,"wpa_mode":"wpa2","minrate_ng_mgmt_rate_kbps":1000,"name":"Kerberos_Gastzugang","minrate_na_mgmt_rate_kbps":6000,"dtim_na":1}.
2018.11.24 07:09:01 3: UniFi_Controller (Unifi_WlanconfRest_Receive) - executed.
2018.11.24 07:09:10 5: UniFi_Controller (Unifi_DoUpdate) - executed.
2018.11.24 07:09:10 5: UniFi_Controller (Unifi_GetAccesspoints_Send) - executed.
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_GetAccesspoints_Receive) - executed.
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_GetAccesspoints_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/stat/device - connect to https://192.168.178.4:8443 timed out'
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_GetVoucherList_Send) - executed.
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_GetVoucherList_Receive) - executed.
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_GetVoucherList_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/stat/voucher - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_GetHealth_Send) - executed.
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_GetHealth_Receive) - executed.
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_GetHealth_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/stat/health - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_GetWlans_Send) - executed.
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_GetWlans_Receive) - executed.
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_GetWlans_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/list/wlanconf - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_GetEvents_Send) - executed.
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_GetEvents_Receive) - executed.
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_GetEvents_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/stat/event - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_GetClients_Send) - executed.
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_GetClients_Receive) - executed.
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_GetClients_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/stat/sta - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/list/alarm - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_ProcessUpdate) - executed after 5.0252 seconds.
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_SetHealthReadings) - executed.
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_SetClientReadings) - executed.
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_SetAccesspointReadings) - executed.
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_SetWlanReadings) - executed.
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_SetVoucherReadings) - executed.
2018.11.24 07:09:15 5: UniFi_Controller (Unifi_ProcessUpdate) - finished after 5.0738 seconds.
2018.11.24 07:09:23 2: HUEBridge: http request failed: connect to http://192.168.178.166:80: Network is unreachable
2018.11.24 07:09:26 1: HMLAN_Parse: HMLAN1 new condition disconnected
2018.11.24 07:09:26 1: 192.168.178.23:1000 disconnected, waiting to reappear (HMLAN1)
2018.11.24 07:09:26 1: HMLAN_Parse: HMLAN1 new condition disconnected
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_DoUpdate) - executed.
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_GetClients_Send) - executed.
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_GetClients_Receive) - executed.
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_GetClients_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/stat/sta - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/list/alarm - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_GetWlans_Send) - executed.
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_GetWlans_Receive) - executed.
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_GetWlans_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/list/wlanconf - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_GetEvents_Send) - executed.
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_GetEvents_Receive) - executed.
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_GetEvents_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/stat/event - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_GetHealth_Send) - executed.
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_GetHealth_Receive) - executed.
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_GetHealth_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/stat/health - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_GetVoucherList_Send) - executed.
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_GetVoucherList_Receive) - executed.
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_GetVoucherList_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/stat/voucher - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_GetAccesspoints_Send) - executed.
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_GetAccesspoints_Receive) - executed.
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_GetAccesspoints_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/stat/device - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_ProcessUpdate) - executed after 0.0103 seconds.
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_SetHealthReadings) - executed.
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_SetClientReadings) - executed.
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_SetAccesspointReadings) - executed.
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_SetWlanReadings) - executed.
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_SetVoucherReadings) - executed.
2018.11.24 07:09:31 5: UniFi_Controller (Unifi_ProcessUpdate) - finished after 0.0188 seconds.
2018.11.24 07:09:46 5: UniFi_Controller (Unifi_DoUpdate) - executed.
2018.11.24 07:09:46 5: UniFi_Controller (Unifi_GetEvents_Send) - executed.
2018.11.24 07:09:47 5: UniFi_Controller (Unifi_GetEvents_Receive) - executed.
2018.11.24 07:09:47 5: UniFi_Controller (Unifi_GetEvents_Receive) - state:'ok'
2018.11.24 07:09:47 5: UniFi_Controller (Unifi_GetWlans_Send) - executed.
2018.11.24 07:09:48 5: UniFi_Controller (Unifi_GetWlans_Receive) - executed.
2018.11.24 07:09:48 5: UniFi_Controller (Unifi_GetWlans_Receive) - state:'ok'
2018.11.24 07:09:48 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.11.24 07:09:48 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.11.24 07:09:48 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.11.24 07:09:48 5: UniFi_Controller (Unifi_GetClients_Send) - executed.
2018.11.24 07:09:49 5: UniFi_Controller (Unifi_GetClients_Receive) - executed.
2018.11.24 07:09:49 5: UniFi_Controller (Unifi_GetClients_Receive) - state:'ok'
2018.11.24 07:09:49 5: UniFi_Controller (Unifi_GetAccesspoints_Send) - executed.
2018.11.24 07:09:50 5: UniFi_Controller (Unifi_GetAccesspoints_Receive) - executed.
2018.11.24 07:09:50 5: UniFi_Controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.11.24 07:09:50 5: UniFi_Controller (Unifi_GetVoucherList_Send) - executed.
2018.11.24 07:09:50 5: UniFi_Controller (Unifi_GetVoucherList_Receive) - executed.
2018.11.24 07:09:50 5: UniFi_Controller (Unifi_GetVoucherList_Receive) - state:'ok'
2018.11.24 07:09:50 5: UniFi_Controller (Unifi_GetHealth_Send) - executed.
2018.11.24 07:09:51 5: UniFi_Controller (Unifi_GetHealth_Receive) - executed.
2018.11.24 07:09:51 5: UniFi_Controller (Unifi_GetHealth_Receive) - state:'ok'
2018.11.24 07:09:51 5: UniFi_Controller (Unifi_ProcessUpdate) - executed after 4.7569 seconds.
2018.11.24 07:09:51 5: UniFi_Controller (Unifi_SetHealthReadings) - executed.
2018.11.24 07:09:51 5: UniFi_Controller (Unifi_SetClientReadings) - executed.
2018.11.24 07:09:51 5: UniFi_Controller (Unifi_SetAccesspointReadings) - executed.
2018.11.24 07:09:51 5: UniFi_Controller (Unifi_SetWlanReadings) - executed.
2018.11.24 07:09:51 5: UniFi_Controller (Unifi_SetVoucherReadings) - executed.
2018.11.24 07:09:51 5: UniFi_Controller (Unifi_ProcessUpdate) - finished after 4.9101 seconds.
2018.11.24 07:10:07 5: UniFi_Controller (Unifi_DoUpdate) - executed.
2018.11.24 07:10:07 5: UniFi_Controller (Unifi_GetHealth_Send) - executed.
2018.11.24 07:10:07 5: UniFi_Controller (Unifi_GetHealth_Receive) - executed.
2018.11.24 07:10:07 5: UniFi_Controller (Unifi_GetHealth_Receive) - state:'ok'
2018.11.24 07:10:07 5: UniFi_Controller (Unifi_GetVoucherList_Send) - executed.
2018.11.24 07:10:08 5: UniFi_Controller (Unifi_GetVoucherList_Receive) - executed.
2018.11.24 07:10:08 5: UniFi_Controller (Unifi_GetVoucherList_Receive) - state:'ok'
2018.11.24 07:10:08 5: UniFi_Controller (Unifi_GetAccesspoints_Send) - executed.
2018.11.24 07:10:09 5: UniFi_Controller (Unifi_GetAccesspoints_Receive) - executed.
2018.11.24 07:10:09 5: UniFi_Controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.11.24 07:10:09 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.11.24 07:10:10 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.11.24 07:10:10 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.11.24 07:10:10 5: UniFi_Controller (Unifi_GetClients_Send) - executed.
2018.11.24 07:10:10 5: UniFi_Controller (Unifi_GetClients_Receive) - executed.
2018.11.24 07:10:10 5: UniFi_Controller (Unifi_GetClients_Receive) - state:'ok'
2018.11.24 07:10:10 5: UniFi_Controller (Unifi_GetEvents_Send) - executed.
2018.11.24 07:10:11 5: UniFi_Controller (Unifi_GetEvents_Receive) - executed.
2018.11.24 07:10:11 5: UniFi_Controller (Unifi_GetEvents_Receive) - state:'ok'
2018.11.24 07:10:11 5: UniFi_Controller (Unifi_GetWlans_Send) - executed.
2018.11.24 07:10:12 5: UniFi_Controller (Unifi_GetWlans_Receive) - executed.
2018.11.24 07:10:12 5: UniFi_Controller (Unifi_GetWlans_Receive) - state:'ok'
2018.11.24 07:10:12 5: UniFi_Controller (Unifi_ProcessUpdate) - executed after 4.9062 seconds.
2018.11.24 07:10:12 5: UniFi_Controller (Unifi_SetHealthReadings) - executed.
2018.11.24 07:10:12 5: UniFi_Controller (Unifi_SetClientReadings) - executed.
2018.11.24 07:10:12 5: UniFi_Controller (Unifi_SetAccesspointReadings) - executed.
2018.11.24 07:10:12 5: UniFi_Controller (Unifi_SetWlanReadings) - executed.
2018.11.24 07:10:12 5: UniFi_Controller (Unifi_SetVoucherReadings) - executed.
2018.11.24 07:10:12 5: UniFi_Controller (Unifi_ProcessUpdate) - finished after 5.0260 seconds.
2018.11.24 07:10:26 1: HMLAN_Parse: HMLAN1 new condition init
2018.11.24 07:10:26 1: 192.168.178.23:1000 reappeared (HMLAN1)
2018.11.24 07:10:27 1: HMLAN_Parse: HMLAN1 new condition ok
Bei Deaktivieren steht folgendes im Log:
2018.11.24 07:25:39 5: UniFi_Controller: set called with disableWLAN Kerberos_Gastzugang
2018.11.24 07:25:39 4: UniFi_Controller: set disableWLAN
2018.11.24 07:25:39 5: UniFi_Controller (Unifi_WlanconfRest_Send) - executed with {"vlan":"40","x_iapp_key":"bdd6ebbfe499476e9fed44885d9a9490","dtim_ng":1,"vlan_enabled":true,"minrate_na_beacon_rate_kbps":6000,"site_id":"5a19f5d3e4b0af2d86e93b17","dtim_mode":"default","minrate_na_advertising_rates":false,"usergroup_id":"5a19f5d6e4b0af2d86e93b21","minrate_ng_mgmt_rate_kbps":1000,"wpa_mode":"wpa2","bc_filter_enabled":false,"name":"Kerberos_Gastzugang","minrate_na_mgmt_rate_kbps":6000,"dtim_na":1,"minrate_ng_enabled":false,"minrate_ng_beacon_rate_kbps":1000,"security":"wpapsk","group_rekey":3600,"wpa_enc":"ccmp","minrate_na_data_rate_kbps":6000,"minrate_ng_data_rate_kbps":1000,"schedule":[],"wlangroup_id":"5a19f5d6e4b0af2d86e93b22","minrate_ng_advertising_rates":false,"enabled":false,"minrate_na_enabled":false,"mac_filter_policy":"allow","mac_filter_enabled":false,"wep_idx":1,"_id":"5a1fd769e4b067e43aff3b98","bc_filter_list":[],"mac_filter_list":[],"is_guest":true}.
2018.11.24 07:25:40 3: UniFi_Controller (Unifi_WlanconfRest_Receive) - executed.
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_DoUpdate) - executed.
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/list/alarm - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_GetClients_Send) - executed.
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_GetClients_Receive) - executed.
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_GetClients_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/stat/sta - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_GetEvents_Send) - executed.
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_GetEvents_Receive) - executed.
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_GetEvents_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/stat/event - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_GetWlans_Send) - executed.
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_GetWlans_Receive) - executed.
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_GetWlans_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/list/wlanconf - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_GetVoucherList_Send) - executed.
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_GetVoucherList_Receive) - executed.
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_GetVoucherList_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/stat/voucher - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_GetHealth_Send) - executed.
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_GetHealth_Receive) - executed.
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_GetHealth_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/stat/health - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_GetAccesspoints_Send) - executed.
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_GetAccesspoints_Receive) - executed.
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_GetAccesspoints_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/stat/device - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_ProcessUpdate) - executed after 0.0105 seconds.
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_SetHealthReadings) - executed.
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_SetClientReadings) - executed.
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_SetAccesspointReadings) - executed.
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_SetWlanReadings) - executed.
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_SetVoucherReadings) - executed.
2018.11.24 07:25:53 5: UniFi_Controller (Unifi_ProcessUpdate) - finished after 0.0351 seconds.
2018.11.24 07:25:57 1: HMLAN_Parse: HMLAN1 new condition disconnected
2018.11.24 07:25:57 1: 192.168.178.23:1000 disconnected, waiting to reappear (HMLAN1)
2018.11.24 07:25:57 1: HMLAN_Parse: HMLAN1 new condition disconnected
2018.11.24 07:25:59 2: HUEBridge: http request failed: connect to http://192.168.178.166:80: Network is unreachable
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_DoUpdate) - executed.
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_GetAccesspoints_Send) - executed.
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_GetAccesspoints_Receive) - executed.
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_GetAccesspoints_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/stat/device - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_GetHealth_Send) - executed.
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_GetHealth_Receive) - executed.
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_GetHealth_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/stat/health - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_GetVoucherList_Send) - executed.
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_GetVoucherList_Receive) - executed.
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_GetVoucherList_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/stat/voucher - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_GetWlans_Send) - executed.
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_GetWlans_Receive) - executed.
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_GetWlans_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/list/wlanconf - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_GetEvents_Send) - executed.
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_GetEvents_Receive) - executed.
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_GetEvents_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/stat/event - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_GetClients_Send) - executed.
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_GetClients_Receive) - executed.
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_GetClients_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/stat/sta - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.178.4:8443/api/s/default/list/alarm - connect to https://192.168.178.4:8443: Network is unreachable'
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_ProcessUpdate) - executed after 0.0206 seconds.
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_SetHealthReadings) - executed.
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_SetClientReadings) - executed.
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_SetAccesspointReadings) - executed.
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_SetWlanReadings) - executed.
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_SetVoucherReadings) - executed.
2018.11.24 07:26:08 5: UniFi_Controller (Unifi_ProcessUpdate) - finished after 0.0390 seconds.
2018.11.24 07:26:23 5: UniFi_Controller (Unifi_DoUpdate) - executed.
2018.11.24 07:26:23 5: UniFi_Controller (Unifi_GetAccesspoints_Send) - executed.
2018.11.24 07:26:23 5: UniFi_Controller (Unifi_GetAccesspoints_Receive) - executed.
2018.11.24 07:26:23 5: UniFi_Controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.11.24 07:26:23 5: UniFi_Controller (Unifi_GetHealth_Send) - executed.
2018.11.24 07:26:25 5: UniFi_Controller (Unifi_GetHealth_Receive) - executed.
2018.11.24 07:26:25 5: UniFi_Controller (Unifi_GetHealth_Receive) - state:'ok'
2018.11.24 07:26:25 5: UniFi_Controller (Unifi_GetVoucherList_Send) - executed.
2018.11.24 07:26:26 5: UniFi_Controller (Unifi_GetVoucherList_Receive) - executed.
2018.11.24 07:26:26 5: UniFi_Controller (Unifi_GetVoucherList_Receive) - state:'ok'
2018.11.24 07:26:26 5: UniFi_Controller (Unifi_GetWlans_Send) - executed.
2018.11.24 07:26:26 5: UniFi_Controller (Unifi_GetWlans_Receive) - executed.
2018.11.24 07:26:26 5: UniFi_Controller (Unifi_GetWlans_Receive) - state:'ok'
2018.11.24 07:26:26 5: UniFi_Controller (Unifi_GetEvents_Send) - executed.
2018.11.24 07:26:27 5: UniFi_Controller (Unifi_GetEvents_Receive) - executed.
2018.11.24 07:26:27 5: UniFi_Controller (Unifi_GetEvents_Receive) - state:'ok'
2018.11.24 07:26:27 5: UniFi_Controller (Unifi_GetClients_Send) - executed.
2018.11.24 07:26:28 5: UniFi_Controller (Unifi_GetClients_Receive) - executed.
2018.11.24 07:26:28 5: UniFi_Controller (Unifi_GetClients_Receive) - state:'ok'
2018.11.24 07:26:28 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.11.24 07:26:29 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.11.24 07:26:29 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.11.24 07:26:29 5: UniFi_Controller (Unifi_ProcessUpdate) - executed after 6.1975 seconds.
2018.11.24 07:26:29 5: UniFi_Controller (Unifi_SetHealthReadings) - executed.
2018.11.24 07:26:29 5: UniFi_Controller (Unifi_SetClientReadings) - executed.
2018.11.24 07:26:29 5: UniFi_Controller (Unifi_SetAccesspointReadings) - executed.
2018.11.24 07:26:29 5: UniFi_Controller (Unifi_SetWlanReadings) - executed.
2018.11.24 07:26:29 5: UniFi_Controller (Unifi_SetVoucherReadings) - executed.
2018.11.24 07:26:29 5: UniFi_Controller (Unifi_ProcessUpdate) - finished after 6.2973 seconds.
2018.11.24 07:26:44 5: UniFi_Controller (Unifi_DoUpdate) - executed.
2018.11.24 07:26:44 5: UniFi_Controller (Unifi_GetHealth_Send) - executed.
2018.11.24 07:26:45 5: UniFi_Controller (Unifi_GetHealth_Receive) - executed.
2018.11.24 07:26:45 5: UniFi_Controller (Unifi_GetHealth_Receive) - state:'ok'
2018.11.24 07:26:45 5: UniFi_Controller (Unifi_GetVoucherList_Send) - executed.
2018.11.24 07:26:45 5: UniFi_Controller (Unifi_GetVoucherList_Receive) - executed.
2018.11.24 07:26:45 5: UniFi_Controller (Unifi_GetVoucherList_Receive) - state:'ok'
2018.11.24 07:26:45 5: UniFi_Controller (Unifi_GetAccesspoints_Send) - executed.
2018.11.24 07:26:46 5: UniFi_Controller (Unifi_GetAccesspoints_Receive) - executed.
2018.11.24 07:26:46 5: UniFi_Controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2018.11.24 07:26:46 5: UniFi_Controller (Unifi_GetClients_Send) - executed.
2018.11.24 07:26:47 5: UniFi_Controller (Unifi_GetClients_Receive) - executed.
2018.11.24 07:26:47 5: UniFi_Controller (Unifi_GetClients_Receive) - state:'ok'
2018.11.24 07:26:47 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.11.24 07:26:47 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.11.24 07:26:47 5: UniFi_Controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2018.11.24 07:26:47 5: UniFi_Controller (Unifi_GetWlans_Send) - executed.
2018.11.24 07:26:50 5: UniFi_Controller (Unifi_GetWlans_Receive) - executed.
2018.11.24 07:26:50 5: UniFi_Controller (Unifi_GetWlans_Receive) - state:'ok'
2018.11.24 07:26:50 5: UniFi_Controller (Unifi_GetEvents_Send) - executed.
2018.11.24 07:26:51 5: UniFi_Controller (Unifi_GetEvents_Receive) - executed.
2018.11.24 07:26:51 5: UniFi_Controller (Unifi_GetEvents_Receive) - state:'ok'
2018.11.24 07:26:51 5: UniFi_Controller (Unifi_ProcessUpdate) - executed after 7.1141 seconds.
2018.11.24 07:26:51 5: UniFi_Controller (Unifi_SetHealthReadings) - executed.
2018.11.24 07:26:51 5: UniFi_Controller (Unifi_SetClientReadings) - executed.
2018.11.24 07:26:51 5: UniFi_Controller (Unifi_SetAccesspointReadings) - executed.
2018.11.24 07:26:51 5: UniFi_Controller (Unifi_SetWlanReadings) - executed.
2018.11.24 07:26:51 5: UniFi_Controller (Unifi_SetVoucherReadings) - executed.
2018.11.24 07:26:51 5: UniFi_Controller (Unifi_ProcessUpdate) - finished after 7.2399 seconds.
2018.11.24 07:26:59 1: HMLAN_Parse: HMLAN1 new condition init
2018.11.24 07:26:59 1: 192.168.178.23:1000 reappeared (HMLAN1)
2018.11.24 07:27:01 1: HMLAN_Parse: HMLAN1 new condition ok
Scheinbar bin ich der einzige mit diesem Problem, da ich noch nirgends etwas vergleichbares gelesen habe?
gruß
Wolle
Zitat von: Wuehler am 24 November 2018, 01:23:20
Moin kalle,
Bitte mal im Unifi-Modul verbose auf 5 setzen, Test durchführen und das Log hier posten. Darin sollte sie Fehlermeldung enthalten sein, auf die das Modul noch nicht reagiert.
Grüße,
Dirk
2018.11.24 11:31:09 5: WLAN (Unifi_DoUpdate) - executed.
2018.11.24 11:31:09 5: WLAN (Unifi_GetUnarchivedAlerts_Send) - executed.
2018.11.24 11:31:10 5: WLAN (Unifi_GetUnarchivedAlerts_Receive) - executed.
2018.11.24 11:31:10 5: WLAN (Unifi_GetUnarchivedAlerts_Receive) - Failed! - state:'Error while requesting' - msg:'https://192.168.0.10:8443/api/s/default/list/alarm - https://192.168.0.10:8443/api/s/default/list/alarm: Can't connect(2) to https://192.168.0.10:8443: SSL connect attempt failed'
@Kalle:
im Anhang eine Version, die auch deine Fehlermeldung berücksichtigen sollte. Bitte mal testen.
@Wolle:
Wenn ich mich richtig erinnere provisioniert der Unifi-Controller beim en-/disable WLAN alle APs. Das führt meiner Meinung nach dazu, dass alle WLANs kurzfristig nicht erreichbar sind. Deine HueBridge und HMLAN verlieren auch ihre Connection. Die langen Zeiten, die am Unifi_ProcessUpdate ausgegeben werden zeigen nicht unbedingt ein Blockieren an. Es wird immer NonBlockingHTTPRequest genutzt. Das kann man auch daran sehen, dass due Zeitsprünge immer zwischen sendXXX und receiveXXX sind. Der Unifi-Controller antwortet demnach nicht so schnell wie normal.
Folgende Fragen:
1. Laufen FHEM und Unifi-Controller auf demselben Rechner? Wenn ja: Bitte mal mit top beobachten wie der Rechner ausgelastet ist.
2. Passiert das Blockieren auch, wenn du das Unifi-Modul deaktivierst und das WLAN über die Oberfläche des Unifi-Controllers toggelst?
Zitat von: Wuehler am 24 November 2018, 13:34:35
Wenn ich mich richtig erinnere provisioniert der Unifi-Controller beim en-/disable WLAN alle APs. Das führt meiner Meinung nach dazu, dass alle WLANs kurzfristig nicht erreichbar sind. Deine HueBridge und HMLAN verlieren auch ihre Connection.
Ja, daran hab ich es eigentlich überhaupt erst bemerkt. Plötzlich blinkt der HMLAN und in FHEM geht nichts mehr.
Aber deine folgenden zwei Fragen haben mich auf eine neue Spur gebracht.
Zitat1. Laufen FHEM und Unifi-Controller auf demselben Rechner?
Nein, das tun sie nicht. Der Unifi-Controller läuft auf einem seperaten Cloud-Key.
Zitat2. Passiert das Blockieren auch, wenn du das Unifi-Modul deaktivierst und das WLAN über die Oberfläche des Unifi-Controllers toggelst?
Ja das passiert tatsächlich. Scheinbar blockiert der Cloud-Key irgendwie das gesamte drahtgebundene Netzwerk für ein paar Sekunden. Nur warum tut er das? Dass das WLAN kurzzeitig weg ist, weiß ich, aber warum wird das LAN blockiert?
Hat hier sonst noch jemand einen Cloud-Key und das Problem auch oder nicht? Scheinbar bin ich echt der einzige mit dem Problem. Auch Google wirft mir dazu nichts aus. >:(
Leider kann ich das Problem nicht nachstellen. Vielleicht findet sich ja jemand anderes hier.
Die Suche bei google nach dem Problem ist auch nicht so einfach. Gibt viele Treffer zu WLAN ;-) Mach mal Speedtests während der Provisionierung. Damit könnte man im Unifi-Forum evtl. einen Thrad aufmachen.
Viel Erfolg,
Dirk
Zitat von: Wolle02 am 24 November 2018, 15:21:28
Ja, daran hab ich es eigentlich überhaupt erst bemerkt. Plötzlich blinkt der HMLAN und in FHEM geht nichts mehr.
Aber deine folgenden zwei Fragen haben mich auf eine neue Spur gebracht.
Nein, das tun sie nicht. Der Unifi-Controller läuft auf einem seperaten Cloud-Key.
Ja das passiert tatsächlich. Scheinbar blockiert der Cloud-Key irgendwie das gesamte drahtgebundene Netzwerk für ein paar Sekunden. Nur warum tut er das? Dass das WLAN kurzzeitig weg ist, weiß ich, aber warum wird das LAN blockiert?
Hat hier sonst noch jemand einen Cloud-Key und das Problem auch oder nicht? Scheinbar bin ich echt der einzige mit dem Problem. Auch Google wirft mir dazu nichts aus. >:(
Wenn das LAN kurzzeitig blockiert kann es es an der STP Root Bridge die sich ändert liegen ...
ich vermute einfach mal, Du hast mindestens 3 STP fähige Devices:
Fritte --> garantiert
AP --> garantiert
Cloudkey --> keine Ahnung
vielleicht ist das ein möglicher Ansatzpunkt
Zitat von: Wuehler am 24 November 2018, 13:34:35
@Kalle:
im Anhang eine Version, die auch deine Fehlermeldung berücksichtigen sollte. Bitte mal testen.
@Wolle:
Wenn ich mich richtig erinnere provisioniert der Unifi-Controller beim en-/disable WLAN alle APs. Das führt meiner Meinung nach dazu, dass alle WLANs kurzfristig nicht erreichbar sind. Deine HueBridge und HMLAN verlieren auch ihre Connection. Die langen Zeiten, die am Unifi_ProcessUpdate ausgegeben werden zeigen nicht unbedingt ein Blockieren an. Es wird immer NonBlockingHTTPRequest genutzt. Das kann man auch daran sehen, dass due Zeitsprünge immer zwischen sendXXX und receiveXXX sind. Der Unifi-Controller antwortet demnach nicht so schnell wie normal.
Folgende Fragen:
1. Laufen FHEM und Unifi-Controller auf demselben Rechner? Wenn ja: Bitte mal mit top beobachten wie der Rechner ausgelastet ist.
2. Passiert das Blockieren auch, wenn du das Unifi-Modul deaktivierst und das WLAN über die Oberfläche des Unifi-Controllers toggelst?
Klappt, vielen Dank
Zitat von: Wuppi68 am 25 November 2018, 15:52:55
Wenn das LAN kurzzeitig blockiert kann es es an der STP Root Bridge die sich ändert liegen ...
ich vermute einfach mal, Du hast mindestens 3 STP fähige Devices:
Fritte --> garantiert
AP --> garantiert
Cloudkey --> keine Ahnung
vielleicht ist das ein möglicher Ansatzpunkt
Huiii, heute lerne ich wieder was über Netzwerktechnik. Vielen Dank für den Hinweis. Ich musste jetzt erstmal googlen was STP überhaupt ist, aber es liest sich so, als wenn das tatsächlich die Ursache sein könnte. Ich habe mal etwas mit den Einstellungen meins Switches herumgespielt und versucht STP und Multicast zu konfigurieren. Leider ohne Erfolg was das Problem angeht.
Ich denke, ich muss mal in Ruhe meine Netzwerktoplogie überdenken und ggf. anpassen.
Vielen Dank nochmal für den Tip.
Mal schauen was der Ubiquiti-Support noch beisteuern kann ;)
wenn Du managed Switche hast, kannst Du auch auf den Ports wo Du KEIN Spanning Tree haben möchtest diesen sperren - quasi wie eine Firewall
SPT --> Spanning tree
default: die kleinste MAC Adresse gewinnt ... (Problem bei Sonos) ggfls. kannst Du auch die Root Bridge Prio von Hand rauf setzen
Hi,
könnte einmal bitte jemand bei sich nachsehen, ob eure device readings auf disconnect wechseln, wenn z.B. ein Handy abwesend ist.
Mir ist heute aufgefallen, dass anscheinend kein entsprechendes Event mehr erzeugt wird und meine presence devices permanente Anwesenheit suggerieren.
USG 4.4.34.5140612
AP's 4.0.8.9618
Controller 5.9.32-11402-1
Fhem Stand von heute morgen.
Das dumme ist, dass ich nicht genau weiß, seit wann es nicht mehr funktioniert und ich neben den Unifi Updates
in der letzten Woche ziemlich viel an dem USG herum gehext habe um Sonos Vlan übergreifend ans laufen zu bekommen.
Edit: gerade noch einmal im Controller Event log geschaut: dort wird ein Disconnect Event angezeigt.
Ich konnte allerdings auch heute Mittag beobachten, dass am Handy der last Seen Wert die aktuelle Uhrzeit anzeigte obwohl das Gerät seit 4h ausser Haus war.
Edit2: hat sich erledigt. Nach dem Update auf den stable candidate 4.0.9.9636 auf den AP's und dem Switch kommen die Events wieder durch :)
Schade, heute war das Problem wieder da - diesmal bei einem anderen Handy.
Nachdem ich mich einmal durch den ganzen Thread gewühlt habe, vermute ich, dass ich ein ähnliches Problem wie @australien habe
https://forum.fhem.de/index.php/topic,40287.msg820651.html#msg820651
Es scheint mit dem hier
https://forum.fhem.de/index.php/topic,40287.msg701878.html#msg701878
erwähnten Unifi Bug zusammen zu hängen und lässt sich auch mit der dort beschriebenen Umstellung auf die presence function lösen.
Der "Bug" im Controller:
verlässt ein Device das Wlan, so wird dieses ab dem Moment unter Clients als Verbunden mit dem Switchport des Accesspoints angezeigt.
Im Controller wird auch ein Disconnect Event protokolliert.
Im Unifi Modul werden die Readings weiterhin aktualisiert
setstate UniFi 2018-12-04 23:50:41 HUAWEI_RIO-L01-1d07a68502 connected
setstate UniFi 2018-12-04 23:50:41 HUAWEI_RIO-L01-1d07a68502_accesspoint SWI01
setstate UniFi 2018-12-04 23:50:41 HUAWEI_RIO-L01-1d07a68502_essid UNDEFINED
setstate UniFi 2018-12-04 23:50:41 HUAWEI_RIO-L01-1d07a68502_hostname HUAWEI_RIO-L01-1d07a68502
setstate UniFi 2018-12-04 23:50:41 HUAWEI_RIO-L01-1d07a68502_last_seen 2018-12-04 23:50:13
setstate UniFi 2018-12-04 22:57:25 HUAWEI_RIO-L01-1d07a68502_snr 49
setstate UniFi 2018-12-04 23:50:41 HUAWEI_RIO-L01-1d07a68502_uptime 19135
Da der Workaround mit function funktioniert lehne ich mich mal zurück und warte ab ob Ubiquiti das irgendwann mal repariert (scheint ja erst seit mind. 3 Jahren bekannt zu sein :) )
Hi Stefan,
Danke dir für die Zusammenfassung. Habe mich leider auch nicht mehr dran erinnert. Wäre wohl mal einen Wiki-Artikel wert.
Ich mache mir gerade (leider zu selten Zeit) ein paar Gedanken dazu, wie man die Events zeitnäher mitbekommt und nicht durch regelmäßiges Polling. Erste Möglichkeiten:
1. Log überwachen und im Modul auswerten
2. Mail-Notifikation des Unifi-Controllers nutzen.
3. die MongoDB des UnifiControllers mit Kafka überwachen und an das Modul weitergeben.
Die dritte Alternative ist die komplexeste, hätte ich aber gerade am meisten Interesse dran ;-)
Mal sehen wann/ob ich dazu komme.
VG,
Dirk
Ist es normal wenn ich Gästewlan aktiviere das das Haupt Wlan auch kurz weg ist?
Ja, weil die Access Points provisionieren und in der Zeit alle Clients disconnecten. Das ärgert mich in vielen Bereichen.
Daher lasse ich mein Gäste-WLAN immer an und habe das Gästeportal mit Voucher eingerichtet. Das Modul hat einen Vouchercache und passende Readings, so dass man einen Code z.B. über Telegram anfordern kann.
Ist spannend, wie viele Paketboten sich vertrauensvoll automatisch mit dem "freien" WLAN verbinden.
Zitat von: Wuehler am 11 Dezember 2018, 21:05:32
Daher lasse ich mein Gäste-WLAN immer an und habe das Gästeportal mit Voucher eingerichtet. Das Modul hat einen Vouchercache und passende Readings, so dass man einen Code z.B. über Telegram anfordern kann.
Ist spannend, wie viele Paketboten sich vertrauensvoll automatisch mit dem "freien" WLAN verbinden.
Könntest du das genauer beschreiben / erklären ?
Muss das möglichst einfach halten da die Gäste es gerade mal hinbekommen einmal ein Passwort einzutragen.
Kann ich da "Feste" Gäste anlegen die ohne weiteres Zugang haben ?
Zitat von: ChrisW am 13 Dezember 2018, 14:07:22
Könntest du das genauer beschreiben / erklären ?
Muss das möglichst einfach halten da die Gäste es gerade mal hinbekommen einmal ein Passwort einzutragen.
Kann ich da "Feste" Gäste anlegen die ohne weiteres Zugang haben ?
Wenn bei Dir der unifi-Controller 24/7 läuft, kannst Du Dir ja mal in den Einstellungen das Thema "Guest Control" anschauen. Wie Wuehler habe ich ein offenes WLAN (wie im Cafe oder im Hotel) - wenn die Leute jedoch von diesem WLAN aus ins Internet möchten, bekommen Sie von mir einen Voucher, auf dem ein 10stelliger Code steht. Den müssen Sie jetzt nur auf der angezeigten Webseite eintragen und gut ist - fertig.
Nach 24h sind die Gäste wieder draußen (so habe ich das bei mir eingestellt - man kann die Gültigkeitsdauer eines Vouchers aber auch selber einstellen).
Somit muss ich niemandem irgendein Password geben. Ist sogar sehr gut in der Unifi-Doku beschrieben.
So als Anregung: Ich habe es bei mir noch weiter entwickelt, indem im Flur ein Tablet mit ftui hängt, an dem sich die Gäste per self-service ihren Voucher selbst ziehen können. Sorgt beim ersten Mal immer wieder für staunende Gesichter. Und ab dem zweiten Besuch gehen alle da wie selbstverständlich dran.
Gesendet von meinem SM-G960F mit Tapatalk
Zitat von: markus_fhem am 20 Dezember 2018, 19:07:12
So als Anregung: Ich habe es bei mir noch weiter entwickelt, indem im Flur ein Tablet mit ftui hängt, an dem sich die Gäste per self-service ihren Voucher selbst ziehen können. Sorgt beim ersten Mal immer wieder für staunende Gesichter. Und ab dem zweiten Besuch gehen alle da wie selbstverständlich dran.
Gesendet von meinem SM-G960F mit Tapatalk
kannst du mal bitte zeigen wie des aussieht? und ein Beispiel?
okay coole idee :) Kann man den Voucher auch dauerhaft speichern ? Meine 2-3 Stammgäste sollen möglichst sofort rein kommen ohne etwas zu machen ;)
Zitat von: Black7king am 20 Dezember 2018, 19:48:33
kannst du mal bitte zeigen wie des aussieht? und ein Beispiel?
Klar doch, gerne.
Von außen:
Ein Tablet in einem einfachen IKEA-Bilderrahmen, der die nötige Tiefe hat. Und dahinter direkt die dauerhafte Stromversorgung.
Von innen:
In einem dummy werden für unterschiedliche Gültigkeiten (pro Dauer ein reading) einige Voucher als Komma-separierte Liste vorgehalten, die dann vom Tablet aus über Notify und diese Funktion abgerufen werden können. Dieser Weg, da das Echtzeitabrufen der Voucher zu langsam war.
Das Generieren der Voucher passiert in einem externen php-Script. Inzwischen müsste das auch über das Modul selbst möglich sein, ich habe es aber nie umgebaut.
## Unifi-Voucher für Gäste-WLAN anfordern
sub Code_Anfordern($){
my ($hash) = @_;
my $defaultzeit = ReadingsVal("VoucherZeit.dum","default",1); ## In Reading definierten default-Wert für Voucher-Dauer holen
my $zeit = ReadingsVal("VoucherZeit.dum","state",$defaultzeit); ## Gewählte Voucher-Dauer abfragen
my $voucherlist = ReadingsVal("VoucherCode.dum", $zeit, 0); ## passende Vouchers aus Reading auslesen und einenen Code in State schreiben
my @vouchers = split ( /\,/, $voucherlist );
my $voucherzahl = scalar @vouchers;
fhem "set test.dum $voucherzahl";
my $voucher = splice (@vouchers, 0, 1);
if ($voucherzahl == 1) {
$voucherlist = qx(php /usr/local/src/Voucher.php $zeit); ## neue Vouchers für gewählte Gültigkeit holen, wenn nur noch einer übrig ist
} else {
$voucherlist = join ',', @vouchers;
}
fhem "set VoucherCode.dum $voucher";
fhem "defmod at_VoucherZeitDefault at +00:03:00 set VoucherZeit.dum $defaultzeit"; ## gewählte Voucher-Dauer nach Zeit x auf default zurücksetzen
fhem "setreading VoucherCode.dum $zeit $voucherlist";
}
Zitat von: ChrisW am 21 Dezember 2018, 11:13:26
okay coole idee :) Kann man den Voucher auch dauerhaft speichern ? Meine 2-3 Stammgäste sollen möglichst sofort rein kommen ohne etwas zu machen ;)
Gib Ihnen Voucher, die eine entsprechend lange Gültigkeit haben. Z.B. läuft mein Firmenhandy auch im Gäste-WLAN mit einer Voucher-Dauer von einem Jahr. Und zudem können Voucher auch verlängert werden, bevor sie abgelaufen sind.
ZitatInzwischen müsste das auch über das Modul selbst möglich sein
Korrekt. Dazu gibt es das Attribut VoucherCache mit passendem Reading für den nächsten freien Voucher eines Caches. Außerdem passende get VoucherList-Abfragen.
Einfach mal ausprobieren. In der Commandref sollte es beschrieben sein. Und wenns missverständlich ist einfach melden.
Hallo Leute,
schön, dass es auch für das Unifi Equipment ein FHEM Modul gibt. Ich habe einige Komponenten, die ich nun gern einbinden möchte.
- 1x Unifi Security Gateway
- 2x Unifi Switch US 8 150W
- 3x Unifi UAP AC Pro
Gibt es einen Wiki-Beitrag, der beschreibt, was möglich ist und was zu tun ist, um alles sauber einzubinden?
Irgendwie finde ich den gerade nicht.
- Mein Unifi Controller läuft auf der letzten LTS Version: 5.6.40
- Ihr seid hier anscheinend häufig (alle?) schon auf Version: 5.9.x
Sind dadurch irgendwelche Probleme zu erwarten?
Mein Ziel ist erstmal nur die Nutzung von "Presence" für zwei Smartphones. Als erstes habe ich im Controller einen neuen User mit Lesezugriff eingerichtet. Dann habe ich den Controller wie folgt definiert:
define UnifiController Unifi localhost 8443 <user> <password>
Neben dem Controller wurden noch meine beiden Switche eingerichtet. Das Security Gateway und die drei Access Points fehlen. Ist das so korrekt?
EDIT: Anscheinend funktioniert das so nicht. Mein FHEM WebUI zeigt mir nun in regelmäßigen Abständen "Connection lost, trying a reconnect every 5 seconds." an. Im Logfile kann ich einen Disconnect nicht nachvollziehen. Es gibt keine Einträge, alles sieht gut aus. Kennt das Problem jemand? Kann das mit der LTS-Version 5.6.40 zusammenhängen?
Danke und viele Grüße Hoppel
Hallo und Willkommen im Unifi-Thread.
einen Wiki-Artikel zum Modul gibt es bisher nicht. Bisher hat sich noch niemand gefunden ihn zu beginnen.
Allerdings ist dieser Thread im Großen und Ganzen auch der einzige Thread zum Modul (plus den kurzen Thread zum Unifi-Switch-Modul), so dass man bei geschickter Forumssuche gute Beispiele finden kann.
Für dich als neuer User des Moduls zwei Hinweise:
1. setze das Attribut deprecatedClientNames auf 0, dann werden deine clients ggf. anders, aber icht mehr auf die alte teilweise verwirrende Art, benannt. Spart dir später ggf. ein Umbenennen in PRESENCE oder notifies, wenn ich das Standardverhalten ändere.
2. Bei dir laufen fhem und Unifi vermutlich auf demselben RasPi (oder ähnlich). Wenn es Verbindungsprobleme gibt schau dir mal die Auslastung mit dem Befehl top an. Bei deinem define fragt fhem alle 30 Sekunden alle möglichen Infos ab. Das verursacht auf dem einen Kern recht viel Last und kann dazu führen, dass die Kommunikation zu lange dauert. Dann ggf. im define das Interval hoch setzen oder besser auf zwei RasPi verteilen.
Deine LTS-Version sollte eigentlich keine Probleme bereiten.
Zu PRESENCE gab es vor kurzem in diesem Thread einen best practice. Musst da mal weiter vorne schauen.
Deine APs sind auch angelegt, allerdings nicht als eigene devices sondern als Readings (beginnen mit -AP_) im Controller-Device. Den Switches habe ich vor kurzem ein eigenes Modul gegönnt, da diese je Port einige Readings hatten und ausserdem einige Funktionen (die Switch-Funktionen auf Controller-Ebene werde ich irgendwann auch ausbauen). Für das USG gab es bisher keine speziellen Anforderungen. Ein paar Readings dazu gibt es auch im Controller-Device (beginnen mit -UC_).
Viel Erfolg bei der weiteren Einrichtung,
Dirk
Zitat von: Wuehler am 27 Dezember 2018, 01:32:59
1. setze das Attribut deprecatedClientNames auf 0, dann werden deine clients ggf. anders, aber icht mehr auf die alte teilweise verwirrende Art, benannt. Spart dir später ggf. ein Umbenennen in PRESENCE oder notifies, wenn ich das Standardverhalten ändere.
Guter Hinweis - war mir doch glatt durchgerutscht. Direkt mal gesetzt und sämtliche PRESENCE-Devices angepasst... Wie immer Danke!
Zitat von: Wuehler am 27 Dezember 2018, 01:32:59
Hallo und Willkommen im Unifi-Thread.
einen Wiki-Artikel zum Modul gibt es bisher nicht. Bisher hat sich noch niemand gefunden ihn zu beginnen.
Allerdings ist dieser Thread im Großen und Ganzen auch der einzige Thread zum Modul (plus den kurzen Thread zum Unifi-Switch-Modul), so dass man bei geschickter Forumssuche gute Beispiele finden kann.
Hallo Dirk, danke erstmal für die herzliche Begrüßung. OK, dann werde ich mich mal auf die Suche in diesen beiden Threads begeben.
Zitat von: Wuehler am 27 Dezember 2018, 01:32:59
Für dich als neuer User des Moduls zwei Hinweise:
1. setze das Attribut deprecatedClientNames auf 0, dann werden deine clients ggf. anders, aber icht mehr auf die alte teilweise verwirrende Art, benannt. Spart dir später ggf. ein Umbenennen in PRESENCE oder notifies, wenn ich das Standardverhalten ändere.
OK, das habe ich direkt mal gemacht. Danke für den Hinweis.
Zitat von: Wuehler am 27 Dezember 2018, 01:32:59
2. Bei dir laufen fhem und Unifi vermutlich auf demselben RasPi (oder ähnlich). Wenn es Verbindungsprobleme gibt schau dir mal die Auslastung mit dem Befehl top an.
Ich habe einen XEON-Server (E3-1240L-v5) mit Supermicro Mainboard (X11SSH-CTF) mit 64GB ECC RAM, SSDs für das OS, ein ZFS Raid-Z2 mit ordentlich Speicher und eine Digital Devices MaxS8 zum TV schauen. ;)
Als OS verwende ich Openmediavault4 (Debian Stretch). Neben FHEM und Homebridge (beides läuft direkt auf dem System) betreibe ich folgende Docker Container: Portainer, Netdata, Unifi, TVHeadend und Emby. Also nichts wildes. Das läuft auch soweit alles einwandfrei.
Meine CPU dümpelt gerade auf ca. 5% herum. Es läuft LiveTV auf einem meiner Kodi Clients. An einer Überlastung meines Servers kann es somit nicht liegen.
Zitat von: Wuehler am 27 Dezember 2018, 01:32:59
Bei deinem define fragt fhem alle 30 Sekunden alle möglichen Infos ab. Das verursacht auf dem einen Kern recht viel Last und kann dazu führen, dass die Kommunikation zu lange dauert. Dann ggf. im define das Interval hoch setzen oder besser auf zwei RasPi verteilen.
Mir ist gerade aufgefallen, dass bei meinem define der Interval und die SiteID fehlen. Ich habe mein define nun wie folgt angepasst:
define UnifiController Unifi localhost 8443 <user> <password> 30 default
Ist 30 Sekunden das Default-Interval?
Wie dem auch sei, das hat leider nichts gebracht. Es hängt aber tatsächlich mit dem Interval zusammen. Ich habe Interval 60 und 600 getestet. Die Meldung "Connection lost, trying a reconnect every 5 seconds." erscheint immer genau zum Interval. Das hat also leider auch nichts gebracht.
Während der "Connection lost..." Meldung erscheint "perl" immer sehr weit oben in "top". Es lastet die CPU aber auch nur ca. 3-6% aus. Daran kann es nicht liegen.
Zitat von: Wuehler am 27 Dezember 2018, 01:32:59
Deine LTS-Version sollte eigentlich keine Probleme bereiten.
OK, gut zu wissen. Dann belasse ich es erstmal bei der Version.
Zitat von: Wuehler am 27 Dezember 2018, 01:32:59
Deine APs sind auch angelegt, allerdings nicht als eigene devices sondern als Readings (beginnen mit -AP_) im Controller-Device. Den Switches habe ich vor kurzem ein eigenes Modul gegönnt, da diese je Port einige Readings hatten und ausserdem einige Funktionen (die Switch-Funktionen auf Controller-Ebene werde ich irgendwann auch ausbauen). Für das USG gab es bisher keine speziellen Anforderungen. Ein paar Readings dazu gibt es auch im Controller-Device (beginnen mit -UC_).
OK, habe mir die Readings im Controller-Device gerade mal etwas genauer angesehen. Stimmt, da sehe ich Readings für mein USG, meine USWs und meine UAPs. Alles klar.
Danke schonmal für die Unterstützung! Falls hier noch jemand eine Idee hat, mich auf die richtige Fährte zu bringen, immer her damit. ;)
Viele Grüße Hoppel
Moin Hoppel,
ZitatIst 30 Sekunden das Default-Interval?
Ja, 30 Sekunden ist default. Aber bei der Rechnerleistung sollte es da keine Probleme geben. Beides auf einem RasPi geht auch, führt aber manchmal zu hohen Prozessorlasten.
Ich habe noch nicht verstanden, wann es funktioniert und wann nicht mehr. Geht es dann dauerhaft nicht, oder es geht eigentlich, aber im Log gibt es die "reconnect"-Meldung?
Außerdem kommt die Meldung nicht aus dem Unifi-Modul direkt. Kannst du (mit Attribut verbose auf 5) mal einen Log-Auszug posten.
Viele Grüße,
Dirk
Hallo Dirk,
die "reconnect"-Meldung taucht nicht im Logfile auf. Es handelt sich dabei einfach um die Meldung im FHEM WebInterface, siehe unten im angehängten Screenshot. Bei mir ist grundsätzlich "attr global verbose 3" gesetzt. Nun habe ich mal "attr UnifiController verbose 5" am Controller-Device gesetzt. Meine Unifi-Config sieht somit nun wie folgt aus:
define UnifiController Unifi localhost 8443 xxxx xxxx 30 default
attr UnifiController deprecatedClientNames 0
attr UnifiController icon it_network
attr UnifiController room Netzwerk
attr UnifiController verbose 5
define switch_base UnifiSwitch switch_base
attr switch_base room Netzwerk
define FileLog_switch_base FileLog ./log/switch_base-%Y.log switch_base
attr FileLog_switch_base logtype text
attr FileLog_switch_base room Netzwerk
define switch_office UnifiSwitch switch_office
attr switch_office room Netzwerk
define FileLog_switch_office FileLog ./log/switch_office-%Y.log switch_office
attr FileLog_switch_office logtype text
attr FileLog_switch_office room Netzwerk
Hier wie gewünscht das Logfile dazu:
- um 22:26:34 habe ich den fhem service gestartet, im WebInterface habe ich mich zu diesem Zeitpunkt in meinem Raum "Beleuchtung" befunden, die "reconnect"-Meldung ist nicht erschienen
- um ca. 22:27:15 habe ich im WebInterface in den Raum "Netzwerk" gewechselt
- um 22:27:36, um 22:28:06 und 22:28:37 habe ich dann die "reconnect"-Meldung im WebInterface gesehen
https://pastebin.com/Pg9jusZL
Die "reconnect"-Meldung taucht also nur auf, wenn ich mich im FHEM WebInterface in dem von mir definierten Raum "Netzwerk" befinde. Wenn ich auf einen anderen Raum im FHEM WebInterface wechsle, taucht die Meldung plötzlich nicht mehr auf. Das habe ich eben gerade herausgefunden. In dem Raum "Netzwerk" befinden sich ausschließlich meine Unifi-Definitionen, siehe Konfiguration oben. Sobald ich den Raum "Netzwerk" im WebInterface anklicke, erscheint alle 30 Sekunden im Gleichtakt mit dem Interval die "reconnect"-Meldung.
Womit kann das denn Zusammenhängen?
Siehst du da irgendwelche Fehler?
Meiner Ansicht nach sieht das alles gut aus.
Danke für deine Unterstützung.
Viele Grüße Hoppel
Moin,
OK, jetzt verstehe ich das Problem :)
Dazu müsste FhemWeb zunächst analysiert werden, nicht das Unifi-Modul. Kannst du bitte unter Frontends/Fhemweb einen neuen Thread dazu eröffnen und ihn mir per pm senden. Dann klinke ich mich ein. Bei mir selbst kann ich das nicht nachvollziehen.
Ich habe als Vermutung, dass es daran liegt, dass das Unifi-Modul viele http-requests absetzt und daher FhemWeb keine Ressourcen für sein Polling hat.
Da auch das Modul freezemon Unifi als mögliche Quelle für freezes anzeigt wäre das ein weiterer Hinweis das Design des Unifi-Moduls zu überdenken.
Wäre schön, wenn wir das mit FhemWeb klären könnten.
Viele Grüße,
Dirk
Hallo Dirk,
gerne, hier ist der Thread: https://forum.fhem.de/index.php/topic,95053.0.html
Danke für deine Unterstützung!
Gruß Hoppel
Hallo Wuehler,
vielen Dank für das super Modul!
Ich habe allerdings seit heute Nachmittag das Problem, das dass Modul zwar auf den Unifi Server connectetd, aber dann nur Fehler bringt. Sprich es wird keine Anwesenheit vom Unifi ins Fhem übertragen. Ich habe versucht einen weiteren AP AC Pro zu installieren. Dabei "verabschiedete sich der schon angemeldete AP, der seit ca. 2 Jahren lief....
Ich habe hier das List zum UNIfi gezogen:
Internals:
CHANGED
DEF xxx.xxx.xxx.xxx 8443 crypt:59120201045f5c5e crypt:4030080038625a745c561502372d695706632202
NAME UNIFI_Accesspoint
NOTIFYDEV global
NR 1311
NTFY_ORDER 50-UNIFI_Accesspoint
STATE connected
TYPE Unifi
VERSION 3.0.4
.attraggr:
.attreocr:
state
.attreour:
state
.attrminint:
READINGS:
2019-01-14 21:32:48 -AP_xxx.xxx.xxx.80_clients 0
2019-01-14 21:32:48 -AP_xxx.xxx.xxx.80_essid
2019-01-14 21:32:48 -AP_xxx.xxx.xxx.80_locate unknown
2019-01-14 21:32:48 -AP_xxx.xxx.xxx.80_state error
2019-01-14 21:32:48 -AP_Unifi_gateway_clients 0
2019-01-14 21:32:48 -AP_Unifi_gateway_locate unknown
2019-01-14 21:32:48 -AP_Unifi_gateway_state error
2019-01-14 21:35:56 -UC_events 0 (last 24h)
2019-01-14 21:35:56 -UC_newClients
2019-01-14 21:35:56 -UC_unarchived_alerts 0
2019-01-14 21:35:56 -UC_wlan_accesspoints 0
2019-01-14 21:35:56 -UC_wlan_guests 0
2019-01-14 21:35:56 -UC_wlan_state error
2019-01-14 21:35:56 -UC_wlan_users 0
2019-01-14 21:35:56 -WLAN_FRITZ_Box_Gastzugang_state enabled
2019-01-14 21:35:56 -WLAN_Ramsau_state enabled
2019-01-14 21:35:56 -WLAN_ZUHAUSE_state enabled
2019-01-14 21:34:38 state connected
accespoints:
alerts_unarchived:
clients:
events:
helper:
password crypt:4030080038625a745c561502372d695706632202
username crypt:59120201045f5c5e
hotspot:
voucherCache:
vouchers:
httpParams:
header Cookie: unifises=fOy7ONcDTJOoTRmZytAbe1JnqcRIzn4k;\r\nCookie: csrf_token=NWid6KwgDBjj2z5sQXKixHtdKI5a1sUc;
ignoreredirects 1
loglevel 5
method POST
noshutdown 0
timeout 5
hash:
sslargs:
SSL_verify_mode 0
unifi:
CONNECTED connected
connectedClients
deprecatedClientNames 0
eventPeriod 24
interval 30
updateStartTime 1547498078
url https://xxx.xxx.xxx.xxx:8443/api/s/default/
version 4
updateDispatch:
wan_health:
gw_mac f0:9f:c2:c3:53:e9
gw_name Unifi_gateway
gw_system-stats
gw_version 4.3.33.4936086
num_adopted 1
num_disconnected 1
num_gw 0
num_pending 0
status error
subsystem wan
wlan_health:
num_adopted 1
num_ap 0
num_disabled 0
num_disconnected 1
num_guest 0
num_pending 0
num_user 0
rx_bytes-r 0
status error
subsystem wlan
tx_bytes-r 0
wlans:
5902f0f1bc58f24b0c43ca8c:
_id 5902f0f1bc58f24b0c43ca8c
dtim_mode default
dtim_na 1
dtim_ng 1
mac_filter_policy deny
name Ramsau
security wpapsk
site_id 59028075577ab8fab28dfaed
usergroup_id 59028077577ab8fab28dfaf4
wep_idx 1
wlangroup_id 59028077577ab8fab28dfaf5
wpa_enc ccmp
wpa_mode wpa2
x_iapp_key 18f62241f4bf7574e9ccd283af3ba01c
bc_filter_list:
mac_filter_list:
schedule:
5902f6e0bc58f24b0c43cb0b:
_id 5902f6e0bc58f24b0c43cb0b
dtim_mode default
dtim_na 1
dtim_ng 1
group_rekey 3600
mac_filter_policy deny
minrate_na_beacon_rate_kbps 6000
minrate_na_data_rate_kbps 6000
minrate_na_mgmt_rate_kbps 6000
minrate_ng_beacon_rate_kbps 1000
minrate_ng_data_rate_kbps 1000
minrate_ng_mgmt_rate_kbps 1000
name FRITZ!Box Gastzugang
security wpapsk
site_id 59028075577ab8fab28dfaed
usergroup_id 59028077577ab8fab28dfaf4
wep_idx 1
wlangroup_id 59028077577ab8fab28dfaf5
wpa_enc ccmp
wpa_mode wpa2
x_iapp_key 613bbd3e1337648bdddc44e3b40b51ce
bc_filter_list:
mac_filter_list:
schedule:
590c77d3577ae0e0303a6576:
_id 590c77d3577ae0e0303a6576
dtim_mode default
dtim_na 1
dtim_ng 1
mac_filter_policy deny
name ZUHAUSE
security wpapsk
site_id 59028075577ab8fab28dfaed
usergroup_id 59028077577ab8fab28dfaf4
wep_idx 1
wlangroup_id 59028077577ab8fab28dfaf5
wpa_enc ccmp
wpa_mode wpa2
x_iapp_key 5972f9da81c062f0aa11d2a55799e457
bc_filter_list:
mac_filter_list:
schedule:
www_health:
gw_mac f0:9f:c2:c3:53:e9
status error
subsystem www
Attributes:
deprecatedClientNames 0
event-on-change-reading state
event-on-update-reading state
room System
verbose 5
Gelegentlich taucht eine Fehlermeldung im LogFile auf
UNIFI_Accesspoint (Unifi_Login_Receive) - executed.
2019.01.14 20:52:21 5: UNIFI_Accesspoint (Unifi_Login_Receive) - Error while requesting https://xxx.xxx.xxx.xxx:8443/api/login - https://xxx.xxx.xxx.xxx:8443/api/login: Can't connect(2) to https://xxx.xxx.xxx.xxx:8443: SSL connect attempt failed error:140773F2:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert unexpected message
2019.01.14 20:52:21 5: UNIFI_Accesspoint (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2019.01.14 20:52:21 3: FHEM2FHEM device opened (Remote_TRX)
2019.01.14 20:52:23 5: UNIFI_Accesspoint (Unifi_Notify) - executed.
Der Unifi Controller läuft auf dem gleichen Raspi 3, wie auch das Fhem,
Interessanterweise wird der neue AP AC nicht im Modul aufgeführt. xxx.xxx.xxx.81
Das Gateway ist tatsächlich nicht vorhanden.
Beide APs haben die gleiche Softwareversion :3.9.19.8123
Update Fhem und Raspi, neustart etc. habe ich auch schon probiert....
Kannst du erkennen, warum das Modul nicht mehr funzt??
Besten Dank für deine Unterstützung
winterliche Grüße
Axel
Hallo Axel,
Auf die Schnelle erstmal ein paar Ideen (ohne groß drüber nachzudenken):
- backup im UnifiController runterladen
- service Unifi stoppen und starten
- in FHEM im Unifi-Modul clear all und anschließend update aufrufen
- top auf der linux-console aufrufen und Prozessorlast ansehen
- auffällig ist auch, dass dein wan_health auf error steht. Da muss im Unifi-Universum noch etwas anderes nicht stimmen
Ansonsten bräuchte ich noch folgende Infos:
- Version des UnifiControllers
- deine openssl-Version unter Linux
- gibt es passende Meldungen auch im Unifi-Log?
Viele Grüße,
Dirk
Moin Dirk,
danke für die schnelle Hilfe. An das Backup vom Controller hatte ich auch schon gedacht.
Nachdem ich dies eingespielt habe taucht jetzt wenigsten der zweite AP in den Reading auf.
Anbei die list:
Internals:
CHANGED
DEF xxx.xxx.xxx,xxx 8443 crypt:59120201045f5c5e crypt:4030080038625a745c561502372d695706632202
NAME UNIFI_Accesspoint
NOTIFYDEV global
NR 1311
NTFY_ORDER 50-UNIFI_Accesspoint
STATE connected
TYPE Unifi
VERSION 3.0.4
.attraggr:
.attreocr:
state
.attrminint:
READINGS:
2019-01-15 01:23:12 -AP_xxx.xxx.xxx.80_clients 0
2019-01-15 01:23:12 -AP_xxx.xxx.xxx.80_essid
2019-01-15 01:23:12 -AP_xxx.xxx.xxx.80_locate unknown
2019-01-15 01:23:12 -AP_xxx.xxx.xxx.80_state error
2019-01-15 01:23:12 -AP_xxx.xxx.xxx.81_essid
2019-01-15 01:23:12 -AP_xxx.xxx.xxx.81_locate on
2019-01-15 01:23:12 -AP_xxx.xxx.xxx.81_state error
2019-01-15 01:23:12 -AP_Unifi_gateway_clients 0
2019-01-15 01:23:12 -AP_Unifi_gateway_locate unknown
2019-01-15 01:23:12 -AP_Unifi_gateway_state error
2019-01-15 01:23:12 -UC_events 317 (last 24h)
2019-01-15 01:23:12 -UC_newClients
2019-01-15 01:23:12 -UC_unarchived_alerts 0
2019-01-15 01:23:12 -UC_wlan_accesspoints 0
2019-01-15 01:23:12 -UC_wlan_guests 0
2019-01-15 01:23:12 -UC_wlan_state error
2019-01-15 01:23:12 -UC_wlan_users 0
2019-01-15 01:23:12 -WLAN_FRITZ_Box_Gastzugang_state enabled
2019-01-15 01:23:12 -WLAN_Ramsau_state enabled
2019-01-15 01:23:12 -WLAN_ZUHAUSE_state enabled
2019-01-14 21:34:38 state connected
accespoints:
:
adopt_ip 192.168.178.81
adopt_status 0
adopt_url http://xxx.xxx.xxx.63:8080/inform
discovered_via l2
hostname WlanKeller
ip xxx.xxx.xxx.81
last_seen 1547511441
mac fc:ec:da:fc:ce:ab
model U7PG2
serial FCECDAFCCEAB
site_id 59028075577ab8fab28dfaec
state 2
type uap
upgrade_state 0
uptime 22195
version 3.9.19.8123
port_table:
5902d8e2577a6f9d162a0b11:
_id 5902d8e2577a6f9d162a0b11
board_rev 25
cfgversion a9266f9b11c09a4c
device_id 5902d8e2577a6f9d162a0b11
fw_caps 196407
guest-num_sta 0
inform_ip xxx.xxx.xxx.63
inform_url http://192.168.178.63:8080/inform
ip xxx.xxx.xxx.80
mac f0:9f:c2:26:d1:f9
map_id 59028077577ab8fab28dfafc
model U7PG2
num_sta 0
serial F09FC226D1F9
site_id 59028075577ab8fab28dfaed
state 0
type uap
upgrade_state 0
user-num_sta 0
version 3.9.19.8123
wifi_caps 16373
x 570.832618230077
x_authkey 561402baec8fdd822ffd762a0aa14602
x_fingerprint 76:86:07:01:73:49:3f:88:51:c7:e5:d6:16:4d:9d:24
x_ssh_hostkey_fingerprint 76:86:07:01:73:49:3f:88:51:c7:e5:d6:16:4d:9d:24
x_vwirekey c2bf4838ff22672536a51e888bf74d13
y 399.206112425883
antenna_table:
HASH(0x3c5a008)
config_network:
ip xxx.xxx.xxx.80
type dhcp
countrycode_table:
ethernet_table:
HASH(0x624f938)
port_table:
HASH(0x6228920)
HASH(0x54dd090)
radio_table:
HASH(0x5fb7ba8)
HASH(0x54d6990)
radio_table_stats:
scan_radio_table:
uplink_table:
vwire_table:
5a91d743ccf2cf9e705055b5:
_id 5a91d743ccf2cf9e705055b5
cfgversion 3b907c3224f528d0
device_id 5a91d743ccf2cf9e705055b5
guest-num_sta 0
ip 192.168.178.2
led_override on
license_state registered
mac f0:9f:c2:c3:53:e9
model UGW4
name Unifi_gateway
num_desktop 0
num_handheld 0
num_mobile 0
num_sta 0
outdoor_mode_override default
site_id 59028075577ab8fab28dfaed
state 0
type ugw
upgrade_state 0
user-num_sta 0
version 4.3.33.4936086
x_authkey 2513867014dc43fc1e3f79fc6069efc8
config_network:
ip 192.168.1.1
type dhcp
config_network_wan:
ip 192.168.1.1
type dhcp
network_table:
HASH(0x5c4d1c8)
port_table:
alerts_unarchived:
clients:
events:
HASH(0x621c9c0)
HASH(0x61d05a0)
HASH(0x57eee48)
HASH(0x624e018)
HASH(0x59c4d50)
HASH(0x54b6c88)
HASH(0x5eaa0e0)
HASH(0x621e0d8)
HASH(0x629f898)
HASH(0x61945a8)
HASH(0x54efe18)
HASH(0x5ec5d98)
HASH(0x5c6c0e0)
HASH(0x6102b20)
HASH(0x5a0db08)
HASH(0x5d341a8)
HASH(0x5edaa00)
HASH(0x6130038)
HASH(0x56fc5d0)
HASH(0x54e5a00)
HASH(0x580f1a8)
HASH(0x5f53490)
HASH(0x5f52c50)
HASH(0x56efc78)
HASH(0x59fb2b8)
HASH(0x570a840)
HASH(0x5f1bb78)
HASH(0x61b7f60)
HASH(0x5c4e840)
HASH(0x6289088)
HASH(0x56fc178)
HASH(0x570ae88)
HASH(0x571f7a0)
HASH(0x60ecb78)
HASH(0x6206950)
HASH(0x5010738)
HASH(0x5523fa8)
HASH(0x5edf898)
HASH(0x4f02c28)
HASH(0x5526178)
HASH(0x6128f18)
HASH(0x6138fd8)
HASH(0x5ee1920)
HASH(0x6010cd8)
HASH(0x5529d40)
HASH(0x5542a88)
HASH(0x61b9138)
HASH(0x5d45e30)
HASH(0x5cff8a0)
HASH(0x5e72270)
HASH(0x56dc9f8)
HASH(0x61c9d30)
HASH(0x55198b8)
HASH(0x61b3d78)
HASH(0x5e397c0)
HASH(0x5525890)
HASH(0x56f4bc0)
HASH(0x624d138)
HASH(0x5f369d0)
HASH(0x5eb5ea0)
HASH(0x6275fc0)
HASH(0x62809e8)
HASH(0x5c53878)
HASH(0x5505898)
HASH(0x6222760)
HASH(0x54f3da0)
HASH(0x5f18100)
HASH(0x618e250)
HASH(0x55133c8)
HASH(0x61d0b28)
HASH(0x61ea910)
HASH(0x5719a30)
HASH(0x5d19450)
HASH(0x5814da8)
HASH(0x57ff6e8)
HASH(0x5711368)
HASH(0x5509820)
HASH(0x62691c8)
HASH(0x5d002a8)
HASH(0x5f19db0)
HASH(0x5ce7f58)
HASH(0x610bad0)https://forum.fhem.de/index.php/topic,40287.0.html
HASH(0x5507218)
HASH(0x6137030)
HASH(0x54e1580)
HASH(0x61209b8)
HASH(0x6056948)
HASH(0x57d4cc8)
HASH(0x61acce0)
HASH(0x624e180)
HASH(0x5fc2930)
HASH(0x5e89020)
HASH(0x5f1a1d0)
HASH(0x5fb79e0)
HASH(0x61b83b0)
HASH(0x54d5848)
HASH(0x5a84e60)
HASH(0x5ea7f20)
HASH(0x600af20)
HASH(0x57c8ef0)
HASH(0x54bef68)
HASH(0x57cc4b8)
HASH(0x5ea9990)
HASH(0x625fae0)
HASH(0x5d36d28)
HASH(0x57152c8)
HASH(0x61efaf8)
HASH(0x61b2870)
HASH(0x5d35158)
HASH(0x61b2c30)
HASH(0x5c5eae8)
HASH(0x600b568)
HASH(0x5709d58)
HASH(0x5512c90)
HASH(0x54ee030)
HASH(0x6227440)
HASH(0x60fbcf0)
HASH(0x54e5e38)
HASH(0x5cc45a8)
HASH(0x5a09710)
HASH(0x6121558)
HASH(0x5e3bcb0)
HASH(0x54c5298)
HASH(0x5eb52b8)
HASH(0x57eacb8)
HASH(0x61b85d8)
HASH(0x6067830)
HASH(0x5519db0)
HASH(0x5fc2b58)
HASH(0x6176680)
HASH(0x61d7c08)
HASH(0x5d032d0)
HASH(0x55048d0)
HASH(0x62295e0)
HASH(0x5817550)
HASH(0x56d9878)
HASH(0x629fc70)
HASH(0x5f505a0)
HASH(0x6203c58)
HASH(0x629fa18)
HASH(0x61f05f8)
HASH(0x61eb450)
HASH(0x6220c48)
HASH(0x5ec73a0)
HASH(0x552dd88)
HASH(0x57cd840)
HASH(0x5d3fa80)
HASH(0x61cf358)
HASH(0x5522250)
HASH(0x5f6caa0)
HASH(0x55426b0)
HASH(0x54ec540)
HASH(0x616cea0)
HASH(0x55023f8)
HASH(0x56e67a8)
HASH(0x5ee3d50)
HASH(0x5cc3d20)
HASH(0x5d14cd8)
HASH(0x5ce6ed0)
HASH(0x54e80e8)
HASH(0x5ec96c8)
HASH(0x6225cc8)
HASH(0x6195b50)
HASH(0x5528520)
HASH(0x5d375b0)
HASH(0x6060810)
HASH(0x54d2858)
HASH(0x5ecfb88)
HASH(0x61eb420)
HASH(0x5c59998)
HASH(0x5794910)
HASH(0x6111310)
HASH(0x5ce5668)
HASH(0x56e6490)
HASH(0x6197058)
HASH(0x58135b0)
HASH(0x61fcb18)
HASH(0x61c98c8)
HASH(0x5527888)
HASH(0x56b8768)
HASH(0x6057de8)
HASH(0x5fde8a8)
HASH(0x5503bc8)
HASH(0x5d24be8)
HASH(0x5d1f228)
HASH(0x5535710)
HASH(0x622ae08)
HASH(0x60fa470)
HASH(0x5ea7638)
HASH(0x61d9690)
HASH(0x621ea80)
HASH(0x624f3e0)
HASH(0x56d3a28)
HASH(0x61c58c0)
HASH(0x5ee1fb0)
HASH(0x5e2eeb8)
HASH(0x5f70e10)
HASH(0x5f17018)
HASH(0x5c607b8)
HASH(0x618e0e8)
HASH(0x5e73c10)
HASH(0x61b4120)
HASH(0x54be248)
HASH(0x5f5d338)
HASH(0x612d648)
HASH(0x6280cb8)
HASH(0x5ef2678)
HASH(0x5eb5d80)
HASH(0x62092d0)
HASH(0x60fc388)
HASH(0x5d23088)
HASH(0x5e78ce8)
HASH(0x6280940)
HASH(0x5fc5cd0)
HASH(0x61da758)
HASH(0x57e2d90)
HASH(0x5808650)
HASH(0x61bc910)
HASH(0x62870e0)
HASH(0x5f35668)
HASH(0x571d298)
HASH(0x59c3ec0)
HASH(0x6118f88)
HASH(0x6226f18)
HASH(0x57e6e50)
HASH(0x627ff68)
HASH(0x624df40)
HASH(0x61d01f8)
HASH(0x62a0438)
HASH(0x6289628)
HASH(0x6139638)
HASH(0x5a3cbb0)
HASH(0x57025c0)
HASH(0x5a1cc70)
HASH(0x60ecc68)
HASH(0x6231958)
HASH(0x5fe5068)
HASH(0x5804080)
HASH(0x57006f8)
HASH(0x5ea2a88)
HASH(0x5ecdda0)
HASH(0x6136148)
HASH(0x5cc4128)
HASH(0x5795dd0)
HASH(0x5ee1b30)
HASH(0x57d9a38)
HASH(0x6158550)
HASH(0x57d8a70)
HASH(0x54b8080)
HASH(0x56d0ee8)
HASH(0x54e1188)
HASH(0x5fb4268)
HASH(0x6232f40)
HASH(0x6227248)
HASH(0x5ce4c10)
HASH(0x5f36d00)
HASH(0x5d38218)
HASH(0x5efc318)
HASH(0x58033a0)
HASH(0x613d350)
HASH(0x600e1d8)
HASH(0x6061ff0)
HASH(0x5d03708)
HASH(0x6194ba8)
HASH(0x552cc28)
HASH(0x5f1ac70)
HASH(0x59c4de0)
HASH(0x60d5070)
HASH(0x5f065b0)
HASH(0x503c308)
HASH(0x59eae08)
HASH(0x614d498)
HASH(0x56dac48)
HASH(0x6013de0)
HASH(0x5f36a78)
HASH(0x6280b68)
HASH(0x61cec08)
HASH(0x56e61a8)
HASH(0x5ea29b0)
HASH(0x59c3498)
HASH(0x39ceee0)
HASH(0x62812b8)
HASH(0x62811b0)
HASH(0x54d0ad8)
HASH(0x61881f8)
HASH(0x627f0c0)
HASH(0x56ef330)
HASH(0x5c4aba8)
HASH(0x57ddb88)
HASH(0x5d22d10)
HASH(0x5f6e770)
HASH(0x6175670)
HASH(0x6151d00)
HASH(0x627e808)
HASH(0x6206c20)
HASH(0x619de38)
HASH(0x5a9f8c0)
HASH(0x61580d0)
HASH(0x61d57e0)
HASH(0x5d88f30)
HASH(0x571c018)
HASH(0x5c4f218)
HASH(0x5541c78)
HASH(0x6232a00)
HASH(0x6139548)
HASH(0x5d31440)
HASH(0x5e71a28)
HASH(0x5510b00)
HASH(0x6130260)
HASH(0x57cc860)
HASH(0x54cdbd8)
HASH(0x54e8630)
HASH(0x55157c0)
HASH(0x6108520)
HASH(0x61edf40)
HASH(0x5d360a8)
HASH(0x6264d58)
helper:
password crypt:4030080038625a745c561502372d695706632202
username crypt:59120201045f5c5e
hotspot:
voucherCache:
attr_value
vouchers:
httpParams:
header Cookie: unifises=fOy7ONcDTJOoTRmZytAbe1JnqcRIzn4k;\r\nCookie: csrf_token=NWid6KwgDBjj2z5sQXKixHtdKI5a1sUc;
ignoreredirects 1
loglevel 5
method POST
noshutdown 0
timeout 5
hash:
sslargs:
SSL_verify_mode 0
unifi:
CONNECTED connected
connectedClients
deprecatedClientNames 0
eventPeriod 24
interval 30
updateStartTime 1547511779
url https://192.168.178.63:8443/api/s/default/
version 4
updateDispatch:
wan_health:
gw_mac f0:9f:c2:c3:53:e9
gw_name Unifi_gateway
gw_system-stats
gw_version 4.3.33.4936086
num_adopted 1
num_disconnected 1
num_gw 0
num_pending 0
status error
subsystem wan
wlan_health:
num_adopted 1
num_ap 0
num_disabled 0
num_disconnected 1
num_guest 0
num_pending 0
num_user 0
rx_bytes-r 0
status error
subsystem wlan
tx_bytes-r 0
wlangroups:
wlans:
5902f0f1bc58f24b0c43ca8c:
_id 5902f0f1bc58f24b0c43ca8c
dtim_mode default
dtim_na 1
dtim_ng 1
mac_filter_policy deny
name Ramsau
security wpapsk
site_id 59028075577ab8fab28dfaed
usergroup_id 59028077577ab8fab28dfaf4
wep_idx 1
wlangroup_id 59028077577ab8fab28dfaf5
wpa_enc ccmp
wpa_mode wpa2
x_iapp_key 18f62241f4bf7574e9ccd283af3ba01c
bc_filter_list:
mac_filter_list:
schedule:
5902f6e0bc58f24b0c43cb0b:
_id 5902f6e0bc58f24b0c43cb0b
dtim_mode default
dtim_na 1
dtim_ng 1
group_rekey 3600
mac_filter_policy deny
minrate_na_beacon_rate_kbps 6000
minrate_na_data_rate_kbps 6000
minrate_na_mgmt_rate_kbps 6000
minrate_ng_beacon_rate_kbps 1000
minrate_ng_data_rate_kbps 1000
minrate_ng_mgmt_rate_kbps 1000
name FRITZ!Box Gastzugang
security wpapsk
site_id 59028075577ab8fab28dfaed
usergroup_id 59028077577ab8fab28dfaf4
wep_idx 1
wlangroup_id 59028077577ab8fab28dfaf5
wpa_enc ccmp
wpa_mode wpa2
x_iapp_key 613bbd3e1337648bdddc44e3b40b51ce
bc_filter_list:
mac_filter_list:
schedule:
590c77d3577ae0e0303a6576:
_id 590c77d3577ae0e0303a6576
dtim_mode default
dtim_na 1
dtim_ng 1
mac_filter_policy deny
name ZUHAUSE
security wpapsk
site_id 59028075577ab8fab28dfaed
usergroup_id 59028077577ab8fab28dfaf4
wep_idx 1
wlangroup_id 59028077577ab8fab28dfaf5
wpa_enc ccmp
wpa_mode wpa2
x_iapp_key 5972f9da81c062f0aa11d2a55799e457
bc_filter_list:
mac_filter_list:
schedule:
www_health:
gw_mac f0:9f:c2:c3:53:e9
status error
subsystem www
Attributes:
deprecatedClientNames 0
event-on-change-reading state
room System
Ich habe hier auch nocheinmal die Readings aufgelistet:
Readings
-AP_xxx.xxx.xxx.80_clients
0
2019-01-15 01:29:51
-AP_xxx.xxx.xxx.80_essid
2019-01-15 01:29:51
-AP_xxx.xxx.xxx.80_locate
unknown
2019-01-15 01:29:51
-AP_xxx.xxx.xxx._state
error
2019-01-15 01:29:51
-AP_xxx.xxx.xxx._essid
2019-01-15 01:29:51
-AP_xxx.xxx.xxx._locate
on
2019-01-15 01:29:51
-AP_xxx.xxx.xxx._state
error
2019-01-15 01:29:51
-AP_Unifi_gateway_clients
0
2019-01-15 01:29:51
-AP_Unifi_gateway_locate
unknown
2019-01-15 01:29:51
-AP_Unifi_gateway_state
error
2019-01-15 01:29:51
-UC_events
316 (last 24h)
2019-01-15 01:29:51
-UC_newClients
2019-01-15 01:29:51
-UC_unarchived_alerts
0
2019-01-15 01:29:51
-UC_wlan_accesspoints
0
2019-01-15 01:29:51
-UC_wlan_guests
0
2019-01-15 01:29:51
-UC_wlan_state
error
2019-01-15 01:29:51
-UC_wlan_users
0
2019-01-15 01:29:51
-WLAN_FRITZ_Box_Gastzugang_state
enabled
2019-01-15 01:29:51
-WLAN_Ramsau_state
enabled
2019-01-15 01:29:51
-WLAN_ZUHAUSE_state
enabled
2019-01-15 01:29:51
state
connected
2019-01-14 21:34:38
wie wird der Service für den Unifi controler gestoppt und gestartet?
- clear all und update ist durchgeführt
top: ich hab mal die spitze vom Unifi rausgesucht..
top - 01:36:24 up 5:37, 2 users, load average: 0,63, 0,60, 0,60
Tasks: 169 total, 2 running, 167 sleeping, 0 stopped, 0 zombie
%Cpu(s): 26,8 us, 0,9 sy, 0,0 ni, 72,3 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 949580 total, 877996 used, 71584 free, 31408 buffers
KiB Swap: 102396 total, 40228 used, 62168 free. 270032 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1216 unifi 20 0 1504972 122716 6704 S 62,5 12,9 82:36.86 java
11466 fhem 20 0 89684 84184 6848 R 37,2 8,9 62:04.81 perl
671 root 20 0 161476 53668 21828 S 4,6 5,7 2:15.86 Xorg
23654 pi 20 0 47816 18136 15336 S 4,3 1,9 0:06.16 lxterminal
23668 pi 20 0 5292 2496 2104 R 1,0 0,3 0:10.30 top
653 nobody 20 0 2288 1356 1336 S 0,3 0,1 0:03.98 thd
831 pi 20 0 52748 10384 10200 S 0,3 1,1 0:00.90 lxsession
1090 pi 20 0 95676 19356 15212 S 0,3 2,0 1:08.98 lxpanel
1093 pi 20 0 88208 19956 15112 S 0,3 2,1 1:50.70 pcmanfm
2076 unifi 20 0 838132 41128 10572 S 0,3 4,3 2:28.77 mongod
2119 pi 20 0 570016 137556 93056 S 0,3 14,5 5:46.63 chromium-b+
11491 fhem 20 0 80720 72400 3968 S 0,3 7,6 0:11.00 perl
Version des Controlers: Controller Version
UI 5.6.30.0
Backend 5.6.30
Version atag_5.6.30_10266
wie bekomme ich die openssl-Version raus?
Alarme auf den Unifi controler
Nicht autorisierter Access Point (AP) FRITZ!Box Gastzugang [7e:ff:4d:18:96:28] wurde erkannt. 1:40 am 01/15/2019
Nicht autorisierter Access Point (AP) FRITZ!Box Gastzugang [36:81:c4:b3:70:85] wurde erkannt. 1:18 am 01/15/2019
Nicht autorisierter Access Point (AP) Ramsau [1e:ec:da:fe:ce:ab] wurde erkannt. 1:08 am 01/15/2019
Nicht autorisierter Access Point (AP) ZUHAUSE [fe:ec:da:fe:ce:ab] wurde erkannt. 1:08 am 01/15/2019
Nicht autorisierter Access Point (AP) FRITZ!Box Gastzugang [0e:ec:da:fe:ce:ab] wurde erkannt. 1:08 am 01/15/2019
Nicht autorisierter Access Point (AP) FRITZ!Box Gastzugang [fe:ec:da:fd:ce:ab] wurde erkannt. 1:08 am 01/15/2019
Nicht autorisierter Access Point (AP) ZUHAUSE [fc:ec:da:fd:ce:ab] wurde erkannt. 1:08 am 01/15/2019
Nicht autorisierter Access Point (AP) Ramsau [0e:ec:da:fd:ce:ab] wurde erkannt. 1:08 am 01/15/2019
Im Moment scheinen beide APs zu funktionieren..
f0:9f:c2:26:d1:f9 xxx.xxx.xxx.80
Verbunden
UniFi AP-AC-Pro 3.9.19.8123 19 73 MB 504 MB 11 (ng), 36 (ac)
fc:ec:da:fc:ce:ab xxx.xxx.xxx.81
Verbunden
UniFi AP-AC-Pro 3.9.19.8123 2 3.27 MB 177 KB 6 (ng), 44 (ac)
Besten Dank für Deine Unterstützung
Grüße
Axel
update: Auschnitt aus dem Logfile nach einem Rest:
2019.01.15 01:46:45 5: UNIFI_Accesspoint: set called with restartAP all
2019.01.15 01:46:45 4: UNIFI_Accesspoint: set restartAP
2019.01.15 01:46:45 5: UNIFI_Accesspoint (Unifi_ApCmd_Send) - executed with cmd:'restart', count:'3', ID:'5a91d743ccf2cf9e705055b5'
2019.01.15 01:46:47 5: UNIFI_Accesspoint (Unifi_DoUpdate) - executed.
2019.01.15 01:46:47 5: UNIFI_Accesspoint (Unifi_GetClients_Send) - executed.
2019.01.15 01:46:47 5: UNIFI_Accesspoint: get called with ?.
2019.01.15 01:46:50 5: UNIFI_Accesspoint (Unifi_ApCmd_Receive) - executed.
2019.01.15 01:46:50 5: UNIFI_Accesspoint (Unifi_ApCmd_Receive) - Failed! - state:'error' - msg:'api.err.InvalidTarget'
2019.01.15 01:46:50 5: UNIFI_Accesspoint (Unifi_ApCmd_Send) - executed with cmd:'restart', count:'2', ID:''
2019.01.15 01:46:51 5: UNIFI_Accesspoint (Unifi_GetClients_Receive) - executed.
2019.01.15 01:46:51 5: UNIFI_Accesspoint (Unifi_GetClients_Receive) - state:'ok'
2019.01.15 01:46:51 5: UNIFI_Accesspoint (Unifi_GetVoucherList_Send) - executed.
2019.01.15 01:46:52 5: UNIFI_Accesspoint (Unifi_Notify) - executed.
2019.01.15 01:46:52 5: UNIFI_Accesspoint (Unifi_ApCmd_Receive) - executed.
2019.01.15 01:46:52 5: UNIFI_Accesspoint (Unifi_ApCmd_Receive) - Failed! - state:'error' - msg:'api.err.UnknownDevice'
2019.01.15 01:46:52 5: UNIFI_Accesspoint (Unifi_ApCmd_Send) - executed with cmd:'restart', count:'1', ID:'5902d8e2577a6f9d162a0b11'
2019.01.15 01:46:56 5: UNIFI_Accesspoint (Unifi_GetVoucherList_Receive) - executed.
2019.01.15 01:46:56 5: UNIFI_Accesspoint (Unifi_GetVoucherList_Receive) - state:'ok'
2019.01.15 01:46:56 5: UNIFI_Accesspoint (Unifi_GetHealth_Send) - executed.
2019.01.15 01:46:56 5: UNIFI_Accesspoint (Unifi_ApCmd_Receive) - executed.
2019.01.15 01:46:56 5: UNIFI_Accesspoint (Unifi_ApCmd_Receive) - Failed! - state:'error' - msg:'api.err.InvalidTarget'
2019.01.15 01:46:59 5: UNIFI_Accesspoint (Unifi_GetHealth_Receive) - executed.
2019.01.15 01:46:59 5: UNIFI_Accesspoint (Unifi_GetHealth_Receive) - state:'ok'
2019.01.15 01:46:59 5: UNIFI_Accesspoint (Unifi_GetWlans_Send) - executed.
2019.01.15 01:47:01 5: UNIFI_Accesspoint (Unifi_GetWlans_Receive) - executed.
2019.01.15 01:47:01 5: UNIFI_Accesspoint (Unifi_GetWlans_Receive) - state:'ok'
2019.01.15 01:47:01 5: UNIFI_Accesspoint (Unifi_GetUnarchivedAlerts_Send) - executed.
2019.01.15 01:47:03 5: UNIFI_Accesspoint (Unifi_GetUnarchivedAlerts_Receive) - executed.
2019.01.15 01:47:03 5: UNIFI_Accesspoint (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2019.01.15 01:47:03 5: UNIFI_Accesspoint (Unifi_GetEvents_Send) - executed.
2019.01.15 01:47:05 5: UNIFI_Accesspoint (Unifi_GetEvents_Receive) - executed.
2019.01.15 01:47:05 5: UNIFI_Accesspoint (Unifi_GetEvents_Receive) - state:'ok'
2019.01.15 01:47:05 5: UNIFI_Accesspoint (Unifi_GetAccesspoints_Send) - executed.
2019.01.15 01:47:08 5: UNIFI_Accesspoint (Unifi_GetAccesspoints_Receive) - executed.
2019.01.15 01:47:08 5: UNIFI_Accesspoint (Unifi_GetAccesspoints_Receive) - state:'ok'
2019.01.15 01:47:08 5: UNIFI_Accesspoint (Unifi_ProcessUpdate) - executed after 21.0000 seconds.
2019.01.15 01:47:08 5: UNIFI_Accesspoint (Unifi_SetHealthReadings) - executed.
2019.01.15 01:47:08 5: UNIFI_Accesspoint (Unifi_SetClientReadings) - executed.
2019.01.15 01:47:08 5: UNIFI_Accesspoint (Unifi_SetAccesspointReadings) - executed.
2019.01.15 01:47:08 5: UNIFI_Accesspoint (Unifi_SetWlanReadings) - executed.
2019.01.15 01:47:08 5: UNIFI_Accesspoint (Unifi_SetVoucherReadings) - executed.
2019.01.15 01:47:08 5: UNIFI_Accesspoint (Unifi_ProcessUpdate) - finished after 21.0000 seconds.
2019.01.15 01:47:16 5: UNIFI_Accesspoint: set called with enableWLAN FRITZ_Box_Gastzugang
2019.01.15 01:47:16 4: UNIFI_Accesspoint: set enableWLAN
2019.01.15 01:47:16 5: UNIFI_Accesspoint (Unifi_WlanconfRest_Send) - executed with {"minrate_ng_cck_rates_enabled":true,"mac_filter_policy":"deny","minrate_ng_advertising_rates":false,"name":"FRITZ!Box Gastzugang","security":"wpapsk","bc_filter_enabled":false,"minrate_ng_beacon_rate_kbps":1000,"usergroup_id":"59028077577ab8fab28dfaf4","minrate_ng_data_rate_kbps":1000,"dtim_na":1,"minrate_ng_mgmt_rate_kbps":1000,"_id":"5902f6e0bc58f24b0c43cb0b","minrate_na_beacon_rate_kbps":6000,"minrate_na_data_rate_kbps":6000,"is_guest":false,"mac_filter_enabled":false,"site_id":"59028075577ab8fab28dfaed","wpa_mode":"wpa2","minrate_na_enabled":false,"mac_filter_list":[],"group_rekey":3600,"schedule":[],"wlangroup_id":"59028077577ab8fab28dfaf5","x_iapp_key":"613bbd3e1337648bdddc44e3b40b51ce","uapsd_enabled":true,"wep_idx":1,"bc_filter_list":[],"enabled":true,"dtim_ng":1,"dtim_mode":"default","wpa_enc":"ccmp","minrate_na_mgmt_rate_kbps":6000,"minrate_ng_enabled":false,"minrate_na_advertising_rates":false}.
ende
Guten Morgen,
Ich denke im top sieht man das Problem. Dein RasPi beschäftigt sich durchgehend mit dem Update des Unifi-Moduls. Ein load-Average von 0,6 idt zu hoch. Als schnelle Maßnahme kannst du das Update-Interval im define hochsetzen. Ansonsten hilft ein extra RadPi für den Controller.
VG,
Dirk
Würde sich das lösen lassen ? Man vergibt verschiedene Passwörter / Gutscheine pro Mitarbeiter ein Gutschein. Dieser ist 30 Minuten alle 24 Stunden gültig ?
Ich suche eine lösung Mitarbeitern einfach Zugang zum Wlan in der Pause zu geben. Jedoch muss das einfach sein und die Pausen sind verschieden :(
Daher pro Gerät Maximal 30 Minuten WLAN.
Vielleicht ist hier ja jemand der dafür eine idee hat?
Hallo Dirk,
besten Dank, seit heute morgen ca. 3:00 Uhr funktioniert dein Modul wieder, auch mit zwei APs. Ich habe den Update Interval noch nicht hochgesetzt. Aber jetzt hängt das Presence Modul, kann das evtl. auch mit der Last zusammen hängen?
Besten dank für deine /eure Unterstützung
Grüße
Axel
@Axel: Die Last kommt dafür als Ursache definitiv in Frage. Setze das Interval bitte mal hoch. Dann kann sich der RadPi zwischendurch mal erholen.
@ChrisW: Unifi bietet meines Wissens kein zeitbezogenes Quota. Dazu gibt es ein paar Frature-Requests, es bleibt abr bei Volumen-Quotas bisher.
Ausserdem kann man Voucher nur erzeugen, aber nicht nachträglich bearbeiten. Zwei Ideen hätte ich zu deiner Problemstellung:
1. Generiere über das Modul für jeden Mitarbeiter jeden Tag einen Voucher und versende diesen per Mail.
2. Generiere einmalig für jeden einen Multiuse-Voucher und a) vertraue darauf, dass sie sich nur einmal am Tag die Mühe machen, den Code einzugeben. Oder b) versuche auf der Login-Webseite dazwischen zu kommen und speichere die eingegebenen Codes und lösche täglich den Speicher.
Danke für die Ideen. Meien Idee war irgndwie abzufangen wenn sich ein Gast Einloggt. Per fhem einen timer laufen zu lasse der dann die MAC Blockt. Das müsste mann dann nur nachts wieder aufheben.
Pauschal jeder Gast bekommt dann nach 30 Minuten eine Sperre.
Mal sehen wie man das am besten umsetzt :D
Ich würde einfach die Zeiten loggen. Wer sich nicht dran hält oder immer deutlich drüber liegt fliegt zumindest aus dem WLAN raus.
Hallo Dirk,
Besten DAnk, hälst du ein Interval von 300 für angemessen?
Durch eine längere Intervallzeit erhöht sich ja wohl auch die Latenz bis es zu einer Änderung in der Anwesenheit. Mir waren schon die 10-12 Minuten zu lange...
Kannst du mir sagen, woher, diese höhere Auslastung kommt? Ich frage letztlich nur 7-8 Wlan Nutzer mit Presence ab. Oder liegt es an den ganzen Wlan Anmeldungen die im Unifi_Modul erfasst werden. Kann ich hier eine Abfrage auf nur die Relevanten machen?
Ich hatte heute Vormittag ein Backup vom Dezember am laufen, dies lief sofort ohne Probleme mit den 2 APs.
Viele Fragen ich weiß auch viele Antworten... Ich suche halt jetzt nach der bestmöglichsten Lösung...
Besten Dank für deine Unterstützung..
Grüße
Axel
@Axel: Welche Version hat eigentlich der UnifiController (nicht FHEM Unifi-Modul). Wenn ich mich richtig erinnere sind die 10 Minuten bis Absent bei recht alten Versionen gewesen. Bei neueren sind es glaube ich eher 3-5 Minuten.
Per Default ist das Interval bei 30 Sekunden. Versuch erstmal 60.
Das Unifi-Modul macht insgesamt 7 API-Calls am UnifiController. Und das bei dir alle 30 Sekunden. Dies erzeugt sowohl in FHEM (Anfragen und Antwort verarbeiten) als auch im UC (Antwort zusammenbauen) einiges an Last. Wenn die Calls nach 30 Sekunden nicht komplett verarbeitet sind, werden schon die nächsten Calls abgesetzt und das Problem verstärkt sich.
Die Aktualisierung einzuschränken ist im Modul aktuell nicht vorgesehen. Evtl. hilft es, im UC Daten von Clients usw. zu löschen. Könnte die Antwortzeiten verbessern.
Ich hatte in der Unifi-Community einen Feature-Request für eine ,,Push-API", wird aber denke ich nicht umgesetzt. Das Thema Presence kann man aber mit der Mail-Notification und einem etwas angepasstem mailcheck-Modul komplett ohne Unifi-Modul auch umsetzen. Bin damit manchmal bei unter 3 Sekunden bis zur Abwesenheitserkennung gewesen. Brauche das Thema personenbezogene Anwesenheitserkennung aber nicht wirklich für meine Automatisierung.
@ChrisW: auch eine Idee. Dann hast du erstmal ein offenes Gast-WLAN. Obwohl man das auch als normales WLAN mit key aufsetzen könnte.
Moin Dirk,
es läuft... !
Danke für deinen Support.!
Kannst du mir mal bitte deine Anwesenheit per mailcheck aufzeigen??
Ich wäre daran sehr interessiert.
Danke nochmals
Grüße
Axel
Moin,
Kurze Zusammenfassung:
Irgendwo eine neue Mailadresse besorgen (siehe mailcheck-Doku, glaube gmail, gmx oder t-online gehen zB)
Im UC unter Settings->Controller den Mailserver einrichten.
Im UC unter Settings->Notifications->Client Events bei user connected und disconnected den e-mail Haken setzen.
Erweiterung des Moduls mailcheck (danach aus dem update ausschließen). Siehe:
https://forum.fhem.de/index.php/topic,14092.msg716826.html#msg716826 (https://forum.fhem.de/index.php/topic,14092.msg716826.html#msg716826)
Modul Mailcheck einrichten.
Ein Notify:
defmod notify_Anwesenheit_MailTest notify mailcheck.* {\
my $body=ReadingsVal("mailcheck","Body","");;\
if (index($body,"User[f0:79:60:a6:c5:3f] disconnected") != -1){\
fhem("set rr_Dirk absent");;\
}elsif(index($body,"User[f0:12:40:12:c5:4f] has connected") != -1){\
fhem("set rr_Dirk home");; \
}\
}
Hatte das notify zum Glück nur disabled. Brauche es nicht mehr.
Gruß,
Dirk
Moin Dirk,
das ist tricky !! ;) ;)
Ich hab mich bei der Einrichtung nur ums notwendigste gekümmert..
Cool probiere ich mal am We aus.
Grüße
Axel
Einen Nachteil hat die Mailbenachrichtigung: Im UC wird dann bei jedem User connect ein Alert erzeugt. Je nach Umfeld kann das stören. Im privaten Umfeld denke ich aber eher weniger.
Hi,
kurze Frage an die Forumsallgemeinheit, in der Beschreibung für das Presence-Modul steht ja
define <NAME> PRESENCE event UniFi:NamedDevice:.disconnected UniFi:NamedDevice:.connected
Mit was muss ich denn UniFi:NamedDevice: ersetzen ?
Mein Telefon heisst "OLA". Ist das dann OLA.disconnected und OLA.connected ? irgendwo im Thread habe ich auch was mit zwei Punkten gesehen.
Bei dem Controller sehe ich die folgenden Einträge:
OLAconnected
2019-01-21 20:08:22
OLA_accesspoint
Wohnzimmer
2019-01-21 20:08:22
OLA_essid
Highlands
2019-01-21 20:08:22
OLA_hostname
OLA
2019-01-21 20:08:22
OLA_last_seen
2019-01-21 20:08:15
2019-01-21 20:08:22
OLA_snr
45
2019-01-21 20:08:22
OLA_uptime
7109
Hi,
kurze Frage an die Forumsallgemeinheit, in der Beschreibung für das Presence-Modul steht ja
define <NAME> PRESENCE event UniFi:NamedDevice:.disconnected UniFi:NamedDevice:.connected
Mit was muss ich denn UniFi:NamedDevice: ersetzen ?
Mein Telefon heisst "OLA". Ist das dann OLA.disconnected und OLA.connected ? irgendwo im Thread habe ich auch was mit zwei Punkten gesehen.
Bei dem Controller sehe ich die folgenden Einträge:
OLA connected 2019-01-21 20:08:22
OLA_accesspoint Wohnzimmer 2019-01-21 20:08:22
OLA_essid <SSID> 2019-01-21 20:08:22
OLA_hostname OLA 2019-01-21 20:08:22
OLA_last_seen 2019-01-21 20:08:15 2019-01-21 20:08:22
OLA_snr 45 2019-01-21 20:08:22
OLA_uptime 7109 2019-01-21 20:08:22
Gruss und Dank, Oli
Moin,
Bin mir recht sicher, dass der erste Doppelpunkt durch einen Punkt ersetzt werden muss.
NamedDevice ist OLA. Die Instanz deines UnifiModul heißt bei dir auch Unifi?
Gruß,
Dirk
Also ich sehe im PRESENCE Modul Commandref nichts , was auf Unifi direkt schliessen lässt , bin ich blind oder nutz ich das falsche :D
Ich habs derzeit so laufen bei mir:
define BLA PRESENCE function {ReadingsVal('UNIFIDEVICE','USERDEVICE','') eq "connected" ? 1 : 0} 60 60
Wobei
UNIFIDEVICE das Device vom Unifi ist
USERDEVICE der Name des Handy ist
Rest sollte selbsterklärend dann sein.
EDIT:
Habs auf das event basierte umgestellt, geht gefühlt besser ;)
Ist irgendwie an mir vorbeigegangen, das es so besser geht (weil non blocking ;) Danke !)
defmod NAME PRESENCE event Unifi1:Handy1:.disconnected Unifi1:Handy1:.connected
Ronny
Zitat von: Wuehler am 21 Januar 2019, 21:15:53
Moin,
Bin mir recht sicher, dass der erste Doppelpunkt durch einen Punkt ersetzt werden muss.
NamedDevice ist OLA. Die Instanz deines UnifiModul heißt bei dir auch Unifi?
Gruß,
Dirk
Muss nicht - aber vermutlich kann.
defmod tom.prs PRESENCE event unificontroller:Moto_Z2_Tom:.disconnected unificontroller:Moto_Z2_Tom:.connected
funktioniert hier einwandfrei.
Zitat von: rcmcronny am 21 Januar 2019, 22:25:46
Also ich sehe im PRESENCE Modul Commandref nichts , was auf Unifi direkt schliessen lässt , bin ich blind oder nutz ich das falsche :D
Nicht in der Commandref, aber im wiki.
Hi,
danke es hat funktioniert. Ich habe den führenden Doppelpunkt gelassen, also <unify>:<telefon>:.connected ... so klappt es super.
Danke für Eure Hilfe.
Sehr schön, dann funktioniert ist denke ich genau wie im Wiki beschrieben, oder?
Trotzdem die Frage: Was kann man an der Wiki-Beschreibung ändern, damit man sicherer bei der Umsetzung ist?
Hi, ja so wie es im Wiki beschrieben ist funktioniert es.
Ich finde die Schreibweise mit UniFi:NamedDevice:.disconnected etwas unglücklich.
Wenn man es so stehen lässt würde ich zumindest noch den folgenden Satz ergänzen:
Der Platzhalter UniFi ist mit dem Alias des Unify controllers zu ersetzen, der Platzhalter NamedDevice mit dem Namen des Telefons innerhalb des Controllers.
Damit dürfte klarer sein was ersetzt werden muss.
Oli
Zitat von: Oliver Lamm am 22 Januar 2019, 19:29:38
Hi, ja so wie es im Wiki beschrieben ist funktioniert es.
Ich finde die Schreibweise mit UniFi:NamedDevice:.disconnected etwas unglücklich.
Wenn man es so stehen lässt würde ich zumindest noch den folgenden Satz ergänzen:
Der Platzhalter UniFi ist mit dem Alias des Unify controllers zu ersetzen, der Platzhalter NamedDevice mit dem Namen des Telefons innerhalb des Controllers.
Damit dürfte klarer sein was ersetzt werden muss.
Oli
Dann ändere ich das mal.
Kurze Zwischenfrage an der Stelle, mittels Event werden Geräte im PowerSave-Modus als disconnected angezeigt oder ebenfalls wie bei function-Variante als connected?
Das Event kommt doch aus dem Reading, dass du auch über function abfragen würdest.
Zitat von: marvin78 am 23 Januar 2019, 07:20:33
Das Event kommt doch aus dem Reading, dass du auch über function abfragen würdest.
Es ist zu früh am Morgen. Habe nur die Wiki-Änderung via Feedly gesehen und dann kam bei mir die Frage auf, dass es bei function explizit dabei steht.
Vlt. sollte man diese Passage nochmal etwas verfeinern?
Das sind aus meiner Sicht Grundlagen von FHEM, die an anderer Stelle ausreichend erklärt werden. Wenn man es aber ganz eng ziehen möchte, kann man es sicher dabei schreiben.
Ich will mir im Unifi-Device mittels StateFormat den Inhalt der Readings -UC_wlan_state, -UC_wlan_users und -UC_wlan_guests anzeigen lassen. Leider scheint StateFormat mit dem vorangestellten Bindestrich nicht zurecht zu kommen. Es wird mit nur der Name des Readings angezeigt und nicht der Inhalt. Andere Readings ohne vorangestellten Bindestrich funktionieren problemlos.
Kann man die Readings mit vorangestelltem Bindestrich durch irgendwas ersetzen, das mit StateFormat zusammenarbeitet?
Gruß
Wolle
du könntest ein Userreading bauen, was den Inhalt von -UC_wlan_state, -UC_wlan_users und -UC_wlan_guests beinhaltet und das als State-Format nutzen.
attr fl_GalaxyTab3 userReadings Power {my $powerLevel=ReadingsVal($name, "battery_level", "0");; if( ReadingsVal($name,"power",0) eq 'unplugged') { "$powerLevel% - unplugged"} else { "$powerLevel% - plugged"}}
attr fl_GalaxyTab3 stateFormat Power
so mache ich das zb. um mir Infos über meine Tablets im State anzeigen zu lassen... Die If-Bedingung brauchst du natürlich nicht zu übernehmen ;-)
Gruß Michael
Moin,
Bei mir machen die vorangestellten Bindestriche kein Problem.
attr Unifi stateFormat {ReadingsVal("Unifi","-UC_wan_ip","");;}
Zeigt zB die Wan IP im state an.
Wie sieht dein Code denn aus?
Grüße,
Dirk
Na ich hab halt einfach die Readingsnamen eingegeben; funktioniert mit normalen Readings auch problemlos.
Auf die Idee es mit PerlCode oder Userreadings zu machen, bin ich zugegebener maßen gar nicht gekommen. Wenn man die CommandRef liest, ist die Primärfunktion ja auch diese:
Zitat[Es] werden alle Wörter im Wert des Attributes durch das entsprechende Reading des Gerätes ersetzt (soweit vorhanden).
Aber wie immer führen mehrere Wege zum Ziel. Wenn man denn die Idee dazu hat.
Gruß
Wolle
Hi Wolle,
:) Die Primärfunktion kannte ich wiederum nicht. Nutze das selten und wenn dann sind da immer noch Formeln oder Konditionen drin.
VG,
Dirk
Serfvus beisammen!
Mal eine Frage, deren Antwort mir auch über die Suchfunktion leider noch nicht zu Teil wurde:
Kann man die abgefragten Readings der jeweilig angemeldeten Endgeräte im Modul irgendwie erweitern (z.B. um die MAC-Adresse)?
Mein Problem ist, dass sich bei mir gelegentlich Geräte anmelden die dummerweise den gleichen Namen haben. Neulich hatte ich, nebem dem Gerät meiner Tochter noch 2 weitere "iPhone" in der Liste. Dadurch kann ich natürlich keine wirkliche Unterscheidung nach Gerät vornehmen und meine Presence-Erkennung wird dementsprechend "unscharf".
Hat jemand einen Tipp für mich?
hi du kannst mit dem Attribut devAlias dir für jedes Gerät einen Alias anlegen, welcher dann wieder die 7 Readings für pro Alias erzeugt. Den Alias machst du an der Geräte-ID fest. (kriegst du über get ClientData all raus.)
Läuft bei mir einwandfrei.
Gruß Michael
Darüberhinaus bietet es sich an, im UNIFI-Controller dem iphone Deiner Tochter einen Alias / Namen zu verpassen, das macht es deutlich einfacher. Die "fremden" Geräte brnötigst Du ja nicht zur Presence-Erkennung.
Danke für den Tipp, aber das muss ich dann für jedes Gerät manuell machen. Kommt dann aber das näxte "iPhone" daher, muss ich das wieder eintragen. Wenn es aber ein Reading der Device-ID oder MAC gäbe, wären diese "Nachhaltungen" der Alias-Liste nicht notwendig, oder?
--edit--ok, überredet. Nach nochmaligem Nachdenken hab ich Euch jetzt verstanden.
Zitat von: tomster am 28 Januar 2019, 17:44:40
Danke für den Tipp, aber das muss ich dann für jedes Gerät manuell machen. Kommt dann aber das näxte "iPhone" daher, muss ich das wieder eintragen. Wenn es aber ein Reading der Device-ID oder MAC gäbe, wären diese "Nachhaltungen" der Alias-Liste nicht notwendig, oder?
--edit--ok, überredet. Nach nochmaligem Nachdenken hab ich Euch jetzt verstanden.
Wobei das jetzt zwei unterschiedliche Vorschläge waren.
Der von l2r wird primär im FHEM umgesetzt, meiner besteht erstmal darin, den Devices im Unifi-Controller sprechende Namen zu geben. Gerade bei einigen Android-Devices ist das zwingend erforderlich ;-)
Hallo zusammen,
im nächsten Update habe ich die - schon lange mit Warnmeldungen versehenen - getter und setter zu den Switches ausgebaut. Falls das noch jemand nutzt bitte auf das Modul UnifiSwitch umstellen. Dort gibt es dieselben Funktionen.
Wenn es hier (und heute) keinen großen Einsprüche gibt lade ich die Änderungen morgen hoch, so dass sie am Montag im Update enthalten sind.
Ein erfolgreiches Wochenende,
Dirk
Morgen im Update eine neue Version des Unifi-Moduls. Folgende Funktionalitäten wurden entfernt:
- set <name> poeMode <port-Nr> <state>
- get <name> poeState
- reading poeMode je Port
Alle Funktionen sind schon länger im per autocreate angelegten UnifiSwitch vorhanden.
Kann es sein, dass die Funktion "switchSiteLeds" nicht funktioniert? Hatte ich vorhin mal ausprobiert, aber die Einstellung im Unifi Controller ändert sich nicht (und die LEDs an den Geräten gehen auch nicht aus/an - klar). Kann das vielleicht jemand mal bei sich testen?
Gerade getestet - funktioniert hier auch nicht (mehr).
Moin,
Habe mir das gerade mal kurz angesehen und eine Vermutung woran es liegen kann. Komme aber frühestens Mittwoch dazu meine Vermutung zu überprüfen.
Falls ihr etwas perl könnt und vorher schon wollt:
Im Set-Zweig ,,switchSiteLeds" müsste ,,true" (inkl. Der Anführungszeichen) durch JSON::true ersetzt werden und ,,false" durch JSON::false. Ausserdem in der Funktion Unifi_SwitchSiteLEDs(..) die Anführungszeichen um den state entfernen.
Ich glaube die Unifi-API ist da genauer geworden und akzeptiert boolean in Anführungszeichen nicht mehr.
Viele Grüße,
Dirk
Ich habe das mal kurz ausprobiert, konnte aber keinen Erfolg verzeichnen.
2019.03.04 09:57:32 5: unifi: set called with switchSiteLEDs off
2019.03.04 09:57:32 4: unifi: set switchSiteLEDs
2019.03.04 09:57:32 2: unifi: deprecated use of Attribute 'deprecatedClientNames' (see commandref for details).
2019.03.04 09:57:32 5: unifi (Unifi_SwitchSiteLEDs_Send) - executed with command: '0'
2019.03.04 09:57:32 5: unifi (Unifi_SwitchSiteLEDs_Send) - URL: https://xyz:8443/api/s/default/set/setting/mgmt
2019.03.04 09:57:32 5: unifi (Unifi_SwitchSiteLEDs_Receive) - executed.
2019.03.04 09:57:32 5: unifi (Unifi_SwitchSiteLEDs_Receive) - state:'ok'
Zwar bekomme ich offenbar ein "ok" zurück, aber die Einstellung selber ändert sich im Controller nicht.
Folgendes hatte ich geändert:
--- 74_Unifi.pm.orig 2019-03-04 09:40:35.306823627 +0100
+++ 74_Unifi.pm 2019-03-04 09:47:59.868463744 +0100
@@ -298,9 +298,9 @@
}
}
elsif ($setName eq 'switchSiteLEDs') {
- my $state="true";
+ my $state= JSON::true;
if ($setVal && $setVal eq 'off') {
- $state="false";
+ $state= JSON::false;
}
Unifi_SwitchSiteLEDs_Send($hash,$state);
}
@@ -1500,6 +1500,7 @@
my ($hash,$state) = @_;
my ($name,$self) = ($hash->{NAME},Unifi_Whoami());
Log3 $name, 5, "$name ($self) - executed with command: '".$state."'";
+ Log3 $name, 5, "$name ($self) - URL: ".$hash->{unifi}->{url}."set/setting/mgmt";
HttpUtils_NonblockingGet( {
%{$hash->{httpParams}},
Anführungszeichen um "state" waren in der Funktion Unifi_SwitchSiteLEDs nicht vorhanden, mussten also wohl auch nicht entfernt werden.
HttpUtils_NonblockingGet( {
%{$hash->{httpParams}},
url => $hash->{unifi}->{url}."set/setting/mgmt",
callback => \&Unifi_SwitchSiteLEDs_Receive,
data => "{'led_enabled': ".$state."}",
} );
Moin erst mal! Ich habe seit ein paar Tagen den ersten UniFi-AP in Betrieb genommen. Mein WLAN läuft jetzt erheblich stabiler, darum wird auch noch ein zweiter AP kommen. Danke für das Modul, mit dem ich UniFi direkt in FHEM einbinden konnte!
Zitat von: tomster am 28 Januar 2019, 17:04:09
Kann man die abgefragten Readings der jeweilig angemeldeten Endgeräte im Modul irgendwie erweitern (z.B. um die MAC-Adresse)?
Das habe ich auch vermisst. Klar kann man, da war nur eine Zeile zu kopieren und leicht anzupassen. Ich komm gerade nicht an mein System, kann das aber noch nachliefern. Das selbst zu modifizieren ist natürlich unelegant, entweder nimmt man das Modul von Updates aus oder man editiert nach jedem Update.
Was ich mich aber gefragt habe: Warum liefert das Modul das nicht gleich mit? Wir reden hier über physikalische Geräte, und die kann man nun einmal am besten anhand ihrer physikalischen Adresse identifizieren. Wie viel Schall und Rauch hingegen Namen sind, sieht man ja am UniFi-Controller. Das Ding macht bescheuerterweise keine DNS-Abfrage (damit könnte ich einigermaßen leben), würfelt sich aber selbst (teilweise Phantasie-) Namen zB aus mDNS-Abfragen und vermutlich noch weiteren Quellen zusammen. Ja, ich könnte manuell Namen in UniFi pflegen, aber das mache ich schon an anderer Stelle und will keine redundante Datenhaltung.
Ich habe den Thread ein wenig überflogen - offenbar argumentiert Dirk, dass er aufgrund der Menge nicht noch weitere Readings hinzufügen möchte. Das ist ein verständliches Argument. Auf der anderen Seite braucht aber vielleicht auch nicht jeder die jetzt vorhandenen Readings (ich würde zB nur die MAC und connected/disconnected benötigen). Warum also nicht den Nutzer entscheiden lassen, welche Readings er will? Man könnte doch in einem Attribut "customReadings" eine Liste hinterlegen, welche vom Controller gelieferten Werte man als Readings will (zB customReadings="mac satisfaction"). Und wenn das Reading nicht gesetzt ist, kann sich das Modul ja so verhalten wie bisher, dann wäre auch die Rückwärtskompatibilität da.
Wo ich gerade schon so schön träume .. als weiteres Attribut wäre "customNames" eine feine Sache. Dann könnte sich jeder aussuchen, ob die Basisnamen der Readings aus der MAC, der IP oder auch dem bisherigen von UniFi ausgedachten Namen abgeleitet werden ...
Gruß, Uli
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
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 🤪
Das siehst du falsch. Wir nehmen sicher fast alle gerne Patches entgegen, egal, wie banal sie sind.
Na denn. Sei nicht enttäuscht.
1166a1167
> readingsBulkUpdate($hash,$clientName."_mac",$clientRef->{mac});
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:
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
PS: das Attribut ,,customNames" gibt es schon. Heißt ,,devAlias".
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 ...
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:
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 ...
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 ;)
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.
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.
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:
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 ..
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
attr myunifi event-on-change-reading .*_last_seen,.*(connected|disconnected)
DEF ist
defmod myunifi Unifi 192.168.178.85 8443 crypt:xxx crypt:xxx
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
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
setings-> admins -> add new admin
5.x geht auch
Oha, das ist mir in der commandref durchgerutscht. War glaube ich kurz vor meiner Zeit, dass V5 unterstützt wurde.
Würde am liebsten V3 so langsam mal ausbauen ;)
Zitat von: Wuehler am 14 März 2019, 21:07:00
Würde am liebsten V3 so langsam mal ausbauen ;)
Go for it.
Moin,
morgen im Update ein Modul ohne v3-Support. Hoffe nicht, dass jemand von euch noch auf dieser 3 Jahre alten Version hängen geblieben ist. Aber ab und an muss auch mal aufgeräumt werden.
Als nächstes bereite ich dann mal eine Version mit "customClientReadings" vor. Darin wird dann auch das Attribut deprecatedClientNames entfallen.
Viele Grüße,
Dirk
Zitat von: Wuehler am 16 März 2019, 14:20:49
Als nächstes bereite ich dann mal eine Version mit "customClientReadings" vor. Darin wird dann auch das Attribut deprecatedClientNames entfallen.
Hi, schön! Mir sind (wie du ja weißt) die customClientNames wichtiger - wird es die auch geben?
Gruß, Uli
hi,
bin dabei wie vorhin geschrieben. Aber eins nach dem anderen. Das Thema customClientReadings muss etwas mehr durchdacht werden.
Hallo zusammen,
So, im Anhang mal ein Testmodul mit neuem Attribut customClientReadings.
Für jeden client wird der "state" (connected|disconnected) angezeigt.
Um zusätzlich nur die mac als client-Reading zu bekommen müsste man
attr customClientReadings .:^mac$
setzen.
Für einzelne Clients könnte man sich so auch mehr Readings anzeigen lassen. Je nachdem welche Namenskonventionen man bei den Clients hat wird es dann auch ein einfacheres RegEx um zB die Familie zu addressieren. Alle MAC-Adressen und die uptime für die Familie:
attr customClientReadings myFam.*:^mac$|^uptime$
Alle Readings zu allen Clients würde so aussehen:
attr customClientReadings .:.
Welche Readings ist zur Auswahl gibt kann man auch sehen mittels:
get clientDate all
Bitte einmal ausgiebig testen und Feedback geben!
- Z.B. auch, ob sich bei der Installation etwas an eurem bisherigen Readings geändert hat.
PS: das Attribut deprecatedClientNames ist aus der Version auch entfernt worden.
Viele Grüße,
Dirk
Hallo Dirk,
vielen Dank für das update.
Ich habe das angehängte Modul auf einem Testsystem (welches bald mein Hauptsystem sein wird) aufgespielt.
Offtopic: Ich dachte, dass ich mittlerweile soweit fit wäre, einen neuen Fhem-Server aufzusetzen und loszulegen - aber Fhem macht es einem nicht einfach, ich frage mich ernsthaft, wie Anfänger (ich meine Linux und Fhem) bei dem Thema Verschlüsselung durchblicken können. Offtopic Ende
Das Attribut customClientReadings funktioniert soweit.
Bei dem Ausdruck "myFam.*" nehme ich an, dass deine Clients dann wohl vorneweg alle so heißen, die in dieser Gruppe enthalten sind.
Bei dem lastseen bekommt eine 10-stelliges ganzahliges Ergebnis, was möglicherweise mit dem neu aufgesetzten Testsystem zu tun hat.
Auf meinem laufenden System mit dem unverändetem Unifi-Modul bekommt man verständliche Formate: z.B: 2019-03-16 20:40:23.
Das müsste überprüft werden.
Falls das Modul aus deiner Sicht lesbare lastseen readings liefern müsste, dann wäre ein Hinweis für den User wünschenswert, was er ggf. an anderer Stelle ändern müsste, damit ein lesebares Datumsformat herauskommt, im Moment wüsste ich nicht, wo ich suchen sollte.
Viele Grüße Gisbert
Hi Gisbert,
Danke für das schnelle Feedback.
Bei mir heißen die Clients leider (noch) nicht einheitlich, aber könnte man ja ändern. ;)
Das schien mir ein leicht verständliches Beispiel zu sein.
Mit dem Attribut customClientReadings leite ich die Werte des UC momentan einfach durch. Es gibt dadurch bei einigen Werten Abweichungen. Lastseen und hostname gehören dazu.
Nehme das Feedback aber so auf, dass lesbarere Werte gewünscht sind. Das wäre dann nicht mehr generisch und könnte abwärtskompatible Updates schwieriger machen. Mal schauen, ob mir zu der Problematik noch etwas schlaues einfällt.
Und ja, wenn man sich nur ab und zu um Verschlüsselung kümmern muss, ist das kein einfaches Thema.
Viele Grüße,
Dirk
Hallo Dirk,
bei dem Format des lastseen bin mir nicht sicher, was besser wäre. Derzeit wird ein lesbares Datum-Uhrzeit-Format ausgegeben.
In deiner neuen Variante dürfte es vermutlich eine Unix-Zeit sein. Damit ließe sich im Zweifelsfall einfacher rechnen und eine Überwachung von IoT-Devices realsieren, d.h. ob die Teile noch brav senden oder sich aufgehängt haben und nichts mehr senden. Dann müsste aber auch der state disconneted sein, den man ebenfalls einfach auswerten könnte.
Readings liest man jetzt ja nicht so oft, natürlich wenn man sich damit beschäftigt schon.
Mit einem lastseen in der jetzigen Form könnte man überwachen, ob ein Modul 5 Minuten, 1 Stunde, 1 Tag z.B. offline ist und je nach Dringlichkeit dann handeln.
Vielleicht kannst du beide Readings zur Verfügung stellen und dem Anwender überlassen, was er bevorzugt.
Nimm es aber nur als Anregung, letzenendes programmierst Du es und es ist deine Zeit, die du investierst.
Viele Grüße Gisbert
Hallo Dirk,
mir ist auf dem Testsystem noch folgendes im logfile aufgefallen:
2019.03.16 21:50:02 2: myUniFi (Unifi_ProcessUpdate) - finished after 0.0000 seconds.
2019.03.16 21:50:32 2: myUniFi (Unifi_ProcessUpdate) - finished after 0.0000 seconds.
2019.03.16 21:51:02 2: myUniFi (Unifi_ProcessUpdate) - finished after 1.0000 seconds.
2019.03.16 21:51:32 2: myUniFi (Unifi_ProcessUpdate) - finished after 0.0000 seconds.
2019.03.16 21:52:02 2: myUniFi (Unifi_ProcessUpdate) - finished after 1.0000 seconds.
Auch hier weiß ich leider nicht, ob es am Testsystem oder an dem neuen Unifi-Modul liegt.
Viele Grüße Gisbert
ich habe gerade ein verständnis problem: wenn man die mac adressen braucht weil die client namen zu variabel sind kommt es mit komisch vor die client namen zu verwenden um die mac adressen zu aktivieren. wo ist mein denkfehler?
zu den sich ändernden client namen: wenn man im controller einen alias vergibt bleibt der doch konstant.
Moin, das waren zwei verschiedene Anforderungen. Das Attribut customClientNames habe ich noch nicht umgesetzt. Mit dem Alias im UC war auch mein Vorschlag, passte aber anscheinend nicht zur Infrastruktur von zappa.
@gisbert: die zusätzliche Logausgabe war nur zur Testerleichterung. Kommt später wieder raus.
Moin Wuehler,
hab die Test-Version mal aufgespielt und bin bisher positiv angetan. Konnte keine Fehler fest stellen. Hab aber gleich ein clear Readings gemacht.
Jetzt mit mac und ip neben connect-state ist es echt übersichtlicher.
Danke.
Bzgl. log ausgabe mit processUpdate: Ist das blocking? Ich hab bei mir immer so 6-7 Sekunden.
Hi Maui,
Danke für den Test. Ich denke ich werde für einige Daten noch zusätzlich formatierte Daten bereitstellen und es dann ins offizielle Update übernehmen.
Zum ProcessUpdate: nein. Ist alles non-Blocking. Es wird die Dauer des Updatezyklus gemessen, nicht die Prozessorzeit.
Hallo zusammen,
morgen im Update:
- neues Attribut customClientReadings.
- Ausserdem werden bei get clientData zusätzlich einige Daten formatiert angezeigt (präfix _f_). Diese kann man über customClientReadings auch als Readings anlegen lassen.
- das Attribut deprecatedClientNames ist entfallen.
Spannender Usecase ist mir dabei aufgefallen:
- Die UAP-Uptime könnte man evtl. dazu verwenden, den Kindern die Handyzeit im WLAN einzuschränken ;)
Nächste ToDos:
1. switchSiteLEDs reparieren (ab UnifiController 5.10. defekt)
2. setLocateAP reparieren (ab UnifiController 5.10. defekt)
3. neues Attribut customClientNames einführen. Einziger möglicher Wert ist zunächst "mac".
Viele Grüße,
Dirk
Was hälst du denn von einer Art Aufräumfunktion für die Readings?
Aktuell wird ja über den Name (alias) definiert. Ändere ich nun im Controller den alias, erstellt er ja dafür neue Readings.
Eine Idee wäre über lastSeen zu gehen und Einträge älter als x zu löschen.
Alternativ könnte man die mac Adresse auf doppelte Einträge prüfen, und dann den alten (ebenfalls mit lastseen) löschen.
Moin,
Ich mache bei Änderungen meistens ein set clear all. Reicht das nicht?
Prinzipiell ja. Ich mache es ja nicht anders.
Ist ganz klar unter Luxus Problem und kommt nicht häufig vor einzuordnen ;D
Moin,
Ich will für das Modul im Wiki eine Seite anlegen, falls ihr Input habt, nutzt bitte folgenden Thread:
https://forum.fhem.de/index.php/topic,98820.0.html (https://forum.fhem.de/index.php/topic,98820.0.html)
Danke für eure Unterstützung,
Dirk
Wenn ich mir selbst etwas bauen möchte, um zb per lastSeen > 14 Tage die entsprechenden Readings zu löschen, werden diese dann bei erneutem Connect auch wieder sauber angelegt und löst newClients aus?
Für beides ein Ja.
Okay, hab es soweit hinbekommen.
Allerdings triggert direkt nach dem Löschen der newClient. Hast eine Idee warum?
Magst du deinen Code posten. Dann wird es für mich einfacher. ;)
Aber erwarte kein Meisterstück :o Kann kein perl.
Und ja ich weiß das falls iPhone gelöscht wird, auch iPhone8 gelöscht wird.
Aber ich würde den Timer auf 14 Tage stellen, damit ich eine Art "Klingel" habe.
Ich kriege meistens zuerst die Telegram Nachricht, bevor der Besuch klingelt.
PS: Etwas ähnliches (also besser) könnte man halt auch im Modul unter clear:OldReadings einbauen.
Zeitspanne über Attribut und triggern nur händisch (in meinem Fall per at/DOIF).
Aber ich will dich dazu auch nicht drängen ;)
sub OldReadings_Unifi()
{
my $hash = $defs{'myunifi'};
my $readings = $hash->{READINGS};
foreach my $a ( keys %{$readings} )
{
if ($a =~ "last_seen")
{
my $differenz = time() - ReadingsVal('myunifi',$a,"");
if ($differenz > 3600)
{
my $hack = substr($a,0,length($a)-10);
Log3( 'myunifi', 0,"Reading : $hack $differenz" );
fhem("deletereading myunifi $hack.*");
}
}
}
}
Mit dem Code vor Augen war das Problem dann doch einfach zu finden. Dein sofort dürfte kein richtiges sofort gewesen sein. Die Readings sind beim nächsten Update-Zyklus wieder angelegt worden, oder? Und damit auch newClients.
Alle Clients die vom UC gesendet werden, werden im Modul-Hash intern gespeichert, vor jedem Update aber gelöscht. Darin sind also niemals disconnectede Geräte. Um auch für diese Geräte Readings haben zu können werden alle Clients noch einmal im Modul-Hash gespeichert. Das Delta der beiden Listen sind die disconnecteden Clients. Alle anderen werden aktualisiert. Aus der zweiten Liste werden die Readings erstellt.
Du müsstest also zusätzlich den Client aus der zweiten Liste entfernen.
Ich bin erst morgen wieder am Rechner. Daher diese nur halb qualifizierte Antwort von unterwegs.
Ne die Readings sind immer noch weg. Was mir allerdings grad auffällt, in newClient steht das Device immer noch. Ich erinnere mich, dass sonst beim nächsten Update Zyklus gelöscht wird. Vielleicht hängt das jetzt zwischen Himmel und Hölle.
Aber lass dir Zeit. Läuft ja nicht weg. Ist Wochenende :)
Hi Maui,
im Anhang ein kleiner Fix, newClients muss natürlich nur bei connected clients gemacht werden. Muss gerade weg und komme nicht zum testen, daher auf diesem Weg. Bitte mal ausprobieren.
VG,
Dirk
Looks promising. Danke dir. Teste noch paar Tage
@Wuehler
Zunächst einmal vielen Dank für die nützliche Erweiterung des Unifi-Moduls.
Beim ersten Einsatz nach dem Update sind mir folgende Dinge aufgefallen:
- snr heisst jetzt wohl rssi; snr-Reading ist weiterhin sichtbar, wird aber nicht mehr aktualisiert; Default-Wert für customClientReadings enthält weiterhin snr und nicht rssi.
- Wäre es möglich, die textField-long-Unterstützung für das Feld customClientReadings standardmäßig zu aktivieren (Modul-Zeile #146)?
- Nützlich wäre noch ein Hinweis im Wiki, dass die Liste der möglichen Readings für customClientReadings via "get <unifi> clientData <device>" zur Verfügung steht.
- Fehlerteufel in Wiki-Beispiel zu customClientReadings ... einTelefon$:^mac$:^mac$ ...
Moin OldFhem,
vielen Dank für das konkrete Feedback und Verbesserungsvorschläge. Habe die textField-long-Unterstützung gerade commited, ist morgen nach 8h im Update.
@Maui: Darin ist auch der Fix für newClients.
Die beiden Anpassungen im Wiki sind auch erledigt.
Zum Default für snr: Ich habe im Code einen Kommentar hinzugefügt, dass dieser Default eigentlich nie genutzt wird. Musste mich irgendwie entscheiden.
Um das Reading zu snr bei dir wegzubekommen müsstest du einmal set <unifi> clear all durchführen.
Viele Grüße,
Dirk
@Maui: Im Anhang wird noch zusätzlich ein Reading ermöglicht _f_last_seen_duration. Damit müsste dann auch folgendes Notify möglich sein.
Unifi:.*_f_last_seen_duration:..[456789]d.* {
my $clientName=substr($EVTPART0,0,length($EVTPART0)-23);
fhem("deletereading $NAME $clientName");
fhem("deletereading $NAME ".$clientName."_.*");
Log 3, "notify_removeOldUnifiClients removed: ".$clientName;
}
Das sollte alle Readings löschen, wenn ein client 14 Tage nicht gesehen wurde. Falls Fhem mal nen Tag steht sicherheitshalber alle zweistelligen Tage, die mit 4-9 enden ;)
Ist jetzt noch nicht groß getestet, habe gerade keine alten clients. :(
Musst den Trigger mit deinem Unifi-Devicename ersetzen.
Edit: fehlerhaften Anhang entfernt
@f_zappa: Im Anhang für dich eine Version zum Testen mit neuem Attribut customClientNames.
Die Reihenfolge bei der Namensvergabe ist:
- devAlias
- customClientName: wenn es in den internen Client-Daten (Unifi get clientData <name>) ein Feld gibt, das dem Wert des Attributes customClientNamens entspricht. Also z.B. auch uptime, dann bekommt man sehr schnell sehr viele neue Readings ;).
- name: Der im Unifi-Controller vergebenen Alias.
- hostname: Der Hostname des Clients.
Viele Grüße,
Dirk
Zitat von: Wuehler am 24 März 2019, 12:16:18
@f_zappa: Im Anhang für dich eine Version zum Testen mit neuem Attribut customClientNames.
Great 8) ich installier es gerade mal. Danke!
Zitat von: Wuehler am 24 März 2019, 08:44:25
@Maui: Darin ist auch der Fix für newClients.
Bist du sicher, dass newClients jetzt noch geht?
Bei mir triggert das Reading nicht mehr, bleibt leer.
Auch nach einem clear Readings kommt nix.
PS: Der Rest mit duration und notify sieht gut aus. Danke dafür.
Hi Maui,
da habe ich wohl vergessen zu speichern vorm Upload. Sorry dafür. Kannst die Version für f_zappa nehmen, da ist _f_last_seen_duration auch drin und newClients funktioniert.
Wenn von euch das OK kommt, checke ich das alles morgen ein.
@zappa: Die Hinweise zur commandref habe ich übernommen.
VG,
Dirk
Moin Dirk,
jetzt sieht es besser aus. Wenn ich heut nix mehr gegenteiliges schreibe, passt es :P
Gruß
Maui
Zitat von: Maui am 25 März 2019, 07:38:50
jetzt sieht es besser aus. Wenn ich heut nix mehr gegenteiliges schreibe, passt es :P
Bei mir läuft auch nach wie vor alles prima.
@Wuehler
Heute das neueste Update gezogen und es funktioniert alles tadellos.
Vielen Dank
Hallo zusammen!
Zuerst einmal vielen Dank für das tolle Modul. Habe dies schon seit mehreren Monaten im Einsatz.
Seit einigen Wochen habe ich das Problem, dass viele Aktionen aktuell nicht mehr funktionieren. FHEM ist auf dem aktuellen Stand (gerade nochmals aktualisiert, nachdem hier in ein paar Posts Änderungen am Modul beschrieben waren) und mein UNIFI-Controller ist auf der Version 5.10.20.
Funktioniert:
set UNIFICONTROLLER disableWLAN <SSID>
Funktioniert nicht mehr:
set UNIFICONTROLLER blockClient <hostname>
set UNIFICONTROLLER unblockClient <hostname>
Gleiches gilt für <mac> statt <hostname>
Jemand eine Idee?
Manuelles setzen am UnifiController geht.
Vielen Dank schon einmal im Voraus
Andreas
Hallo zusammen,
morgen im Update die kleinen Verbesserungen der letzten Diskussionen:
- customClientNames
- neues mögliches Reading _f_last_seen_duration
Ich bin Sonntag auch endlich dazu gekommen, den Unifi-Controller auf Version 5.10.x zu heben. War recht viel unterwegs die letzten Wochen. Da gab es offensichtlich nicht nur an der Oberfläche einige Anpassungen sondern auch an der API. Dem werde ich mich als nächstes zuwenden und die Fehler (nach und nach) beheben.
Bekannte Fehler bisher:
- set SwitchSiteLED
- set locateAP
- set (un-)blockClient
Falls ihr noch mehr findet, bitte hier berichten!
Edit: Als erstes versuche ich die Version des Unifi-Controllers zusätzlich abzufragen, dann braucht ihr keine Version als Attribut zu pflegen.
Viele Grüße,
Dirk
Moin,
im Anhang mal ein erster Fix. Da ich jetzt los muss, konnte ich nur block und unblock testen. Wäre schön, wenn ich dazu Feedback bekomme, von jemandem, der noch eine Unifi-Controller-Version kleiner 5.10 einsetzt.
VG,
Dirk
Edit: Anhang entfernt. Ist jetzt im normalen Update
Guten Abend, Wuehler!
Das war ja ein megaschneller Fix. Block und Unblock funktionieren wieder auf einem Cloudkey mit der Controller Version 5.10.20 :-)
Eine ältere Version kann ich leider nicht testen.
Beste Grüße
Andreas
Moin zusammen,
Ich habe heute morgen nochmal kurz testen können. Unter Controller-Version 5.10 ist das Datenhandling genauer geworden. Konkret: es werden keine Hochkommata sondern nur noch Anführungszeichen akzeptiert. Bei vielen kurzen von Hand zusammengebauten JSONs im Modul werden Hochkomma schon seit der aller ersten Version genutzt. Dies passe ich durchgehend an.
Ich benötige dringend Feedback von jemandem, der noch einen UC kleiner 5.10 einsetzt, ob blockClient mit dem Anhang aus zwei Posts vorher auch funktioniert. Sonst muss ich überall eine Abrage der Version einbauen. Oder es müssen alle auf UC 5.10 schwenken. Beides würde ich gerne vermeiden.
VG,
Dirk
@Wuehler
Ich setze derzeit noch Controller-Version 5.8.28 ein. Mit der angehängten Modul-Version von Gestern um 08:05:07 funktioniert weder block noch unblock.
2019.03.27 18:10:46.723 5: UniFiController: get called with ?.
2019.03.27 18:10:54.048 5: UniFiController: set called with blockClient myPhone
2019.03.27 18:10:54.049 4: UniFiController: set blockClient
2019.03.27 18:10:54.050 5: UniFiController (Unifi_BlockClient_Send) - executed with mac: 'cc:22:44:44:99:88'
2019.03.27 18:10:54.436 5: UniFiController: get called with ?.
2019.03.27 18:10:54.467 5: UniFiController (Unifi_BlockClient_Receive) - executed.
2019.03.27 18:10:54.468 5: UniFiController (Unifi_BlockClient_Receive) - Failed! - state:'403' - msg:'Failed with HTTP Code 403.'
2019.03.27 18:12:35.562 5: UniFiController: set called with unblockClient myPhone
2019.03.27 18:12:35.563 4: UniFiController: set unblockClient
2019.03.27 18:12:35.564 5: UniFiController (Unifi_UnblockClient_Send) - executed with mac: 'cc:22:44:44:99:88'
2019.03.27 18:12:35.896 5: UniFiController: get called with ?.
2019.03.27 18:12:35.926 5: UniFiController (Unifi_UnblockClient_Receive) - executed.
2019.03.27 18:12:35.926 5: UniFiController (Unifi_UnblockClient_Receive) - Failed! - state:'403' - msg:'Failed with HTTP Code 403.'
Hi OldFhem,
Vielen Dank. Zur Sicherheit aber folgende Frage: Hast du im Unifi-Modul evtl. ein User hinterlegt, der nur read-only-Rechte hat? Fehler 403 besagt, dass der Zugriff verboten ist. Block und unblock sind ziemlich sicher schreibende Zugriffe.
@Wuehler
Man sollte doch nie Befehle ausprobieren, die man eigentlich nicht braucht und vorher auch noch nicht eingesetzt hat :-[
Tatsächlich war der User für den FHEM-Zugriff ein "Read Only User" - klar, dass das dann nicht funktionieren konnte.
Nachdem der User mehr Rechte erhalten hatte, klappte block und auch unblock auf Anhieb.
Tut mir leid für den Fehlalarm ...
@OldFhem: Danke auf jeden Fall. Deine Rückmeldung war so ausführlich, dass es mir schnell auffallen konnte.
Dann kann ich mir die Versionsabfragen fast immer sparen. Nur bei switchSiteLED hat sich anscheinend der API-Endpunkt geändert. Das wird dann etwas länger dauern bis switchSiteLED wieder funktioniert.
Morgen im Update schon mal ein fix für UC-V5.10 mit repariertem (un-)blockClient und voucherCache.
Der Rest folgt nach und nach. Ich erwarte noch Probleme aufgrund Hochkommata bei:
- locateAP
- switchSiteLED
- unarchivedAlerts
- events
- disconnectClient
- restartAP
Muss ich mir dann noch genauer ansehen.
@Wuehler
Ich habe heute das neueste Update gezogen und nochmals ein wenig mit block/unblock experimentiert.
Dabei sind mir folgende Dinge aufgefallen:
Das Wichtigste: es funktioniert ;)
allgemein enthält die Geräte-Liste der set und get-Befehle nur noch die aktiven Geräte; schöner wäre es vermutlich, wenn hier die erweiterte Liste der bekannten Geräte erscheinen würde. Ansonsten kann nicht auf alle (bzw. die länger nicht mehr angemeldeten) Geräte zugegriffen werden (kein clientData, kein block, ...).
bei einem geblockten Gerät enthält das über clientData angezeigte "Reading" blocked fälschlischerweise den Wert 0; ist es möglich, hier den richtigen Wert anzuzeigen und evtl. sogar das blocked in den Gesamtstatus des Gerätes einfliessen zu lassen (also connected,disconnected oder blocked). Das blocked-"Reading" existiert scheinbar auch nur bei einem Gerät, das schon mal geblockt wurde.
Zu meinem Fehlalarm von gestern: Wäre es sinnvoll, einen Hinweis im Wiki unterzubringen, dass bei manchen Aktionen bzw. vielleicht sogar bei welchen Aktionen mehr als ReadOnly-Rechte erforderlich sind?
@all: Habe gerade die restlichen Funktionen für UC Version 5.10 gefixt. Gibt es morgen im Update.
@OldFhem:
Zitatallgemein enthält die Geräte-Liste der set und get-Befehle nur noch die aktiven Geräte; schöner wäre es vermutlich, wenn hier die erweiterte Liste der bekannten Geräte erscheinen würde. Ansonsten kann nicht auf alle (bzw. die länger nicht mehr angemeldeten) Geräte zugegriffen werden (kein clientData, kein block, ...).
Vom UC werden auch nur die Geräte mitgesendet, die connected sind. An die, die mal connected waren kommt das Modul momentan nicht dran. Du kanns aber immer in die Commandozeile von FHEM den Befehl mit alten Clients eintippen. Brauchst dann aber die mac-Adresse:
set Unifi blockClient 04:d6:aa:3f:84:50
Zitatbei einem geblockten Gerät enthält das über clientData angezeigte "Reading" blocked fälschlischerweise den Wert 0; ist es möglich, hier den richtigen Wert anzuzeigen und evtl. sogar das blocked in den Gesamtstatus des Gerätes einfliessen zu lassen (also connected,disconnected oder blocked). Das blocked-"Reading" existiert scheinbar auch nur bei einem Gerät, das schon mal geblockt wurde.
Bei mir steht dort false, keine 0 ??? Der UC sendet anscheinend das Feld blocked nur bei Clients, die schonmal geblocked waren. Könnte man natürlich bei Fehlen des Wertes im Modul generieren.
Da das Modul keine disconnected clients mehr bekommt, kann es zwischen blocked und disconnected nicht unterscheiden. Du könntest ja auch einen client im Unifi-Controller unblocken. Die Daten sind also nicht zwingend konsistent.
ZitatZu meinem Fehlalarm von gestern: Wäre es sinnvoll, einen Hinweis im Wiki unterzubringen, dass bei manchen Aktionen bzw. vielleicht sogar bei welchen Aktionen mehr als ReadOnly-Rechte erforderlich sind?
gute Idee.
Moin @Wuehler: leider scheint lastSeenDuration doch nicht zu klappen.
Nach 5min absence scheint er aufhören hochzuzählen.
Moin Maui,
im Anhang ein Fix dazu. Alle Readings werden darin bei jedem Update-Zyklus neu gesetzt. Ich muss aber erst nochmal in Ruhe durchdenken, welche Nebenwirkungen es gibt.
- zB wenn man das Attribut event-on-change-reading nicht gesetzt hat, gibt es bei disconnect-Clients mehr events. Denke das ist aber nicht so dramatisch.
VG,
Dirk
Edit: Anhang entfernt
Sieht besser aus. Danke.
Moin Wuehler,
Ist der fix schon eingecheckt?
Gruß
Maui
Moin Maui,
Nein. Bin gerade auf Reise. Musst dich noch eine Woche gedulden ::)
Alles gut dann mach ich so lange einfach kein Update
Kann mir mal jemand einen Tipp für ein Problem geben, das (noch) nicht mit dem Modul zu tun hat? Ich versuche auf einem RPi3 den Controller zu installieren und bin damit nicht erfolgreich. Wenn ich die Standard-Java-Umgebung installiere, erhalte ich einen Fehler
<UniFi> ERROR system - [exec] error, rc=141, cmdline=[/usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt/jre/bin/java, -Dfile.encoding=UTF-8, -Djava.awt.headless=true, -Dapple.awt.UIElement=true, -Xmx1024M, -XX:+ExitOnOutOfMemoryError, -XX:+CrashOnOutOfMemoryError, -XX:ErrorFile=/usr/lib/unifi/logs/hs_err_pid%p.log, -jar, /usr/lib/unifi/lib/ace.jar, start]
wobei wenigstens der Prozess gestartet wird, aber nicht erfolgreich
root@FHEM:/var/lib/unifi# service unifi status
● unifi.service - unifi
Loaded: loaded (/etc/systemd/system/unifi.service; enabled)
Active: active (running) since Sa 2019-04-13 14:55:39 CEST; 13min ago
Process: 914 ExecStart=/usr/lib/unifi/bin/unifi.init start (code=exited, status=0/SUCCESS)
Main PID: 998 (jsvc)
CGroup: /system.slice/unifi.service
├─ 998 unifi -cwd /usr/lib/unifi -home /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt -cp /usr/share/java/commons-daemon.jar:/usr/lib/unifi/lib/ace.jar -pidfile /var/run/unifi.pid -procname unifi -outfile SYSLOG -errfile SYSLOG -umask 027 -user unifi -Dunifi.datadir=/var/lib/unifi -Dunifi.logdir=/var/log/unifi -Dunifi.rundir=/var/run/unifi -Xmx1024M -Djava.awt.headless=true -Dfile.encoding=UTF-8 com.ubnt.ace.Launcher start
├─ 999 unifi -cwd /usr/lib/unifi -home /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt -cp /usr/share/java/commons-daemon.jar:/usr/lib/unifi/lib/ace.jar -pidfile /var/run/unifi.pid -procname unifi -outfile SYSLOG -errfile SYSLOG -umask 027 -user unifi -Dunifi.datadir=/var/lib/unifi -Dunifi.logdir=/var/log/unifi -Dunifi.rundir=/var/run/unifi -Xmx1024M -Djava.awt.headless=true -Dfile.encoding=UTF-8 com.ubnt.ace.Launcher start
└─1001 unifi -cwd /usr/lib/unifi -home /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt -cp /usr/share/java/commons-daemon.jar:/usr/lib/unifi/lib/ace.jar -pidfile /var/run/unifi.pid -procname unifi -outfile SYSLOG -errfile SYSLOG -umask 027 -user unifi -Dunifi.datadir=/var/lib/unifi -Dunifi.logdir=/var/log/unifi -Dunifi.rundir=/var/run/unifi -Xmx1024M -Djava.awt.headless=true -Dfile.encoding=UTF-8 com.ubnt.ace.Launcher start
Apr 13 14:55:39 FHEM unifi.init[914]: Starting Ubiquiti UniFi Controller: unifi failed!
Apr 13 14:55:39 FHEM systemd[1]: Started unifi.
Nachdem ich mehrere Stunden im Netz gelesen habe, scheint die Java-Version das Problem zu sein. Also habe ich die neueste Version installiert
pi@FHEM:~ $ update-alternatives --query java
Name: java
Link: /usr/bin/java
Slaves:
java.1.gz /usr/share/man/man1/java.1.gz
Status: manual
Best: /usr/lib/jvm/java-8-oracle/jre/bin/java
Value: /usr/lib/jvm/java-8-oracle/jre/bin/java
Alternative: /usr/lib/jvm/java-8-oracle/jre/bin/java
Priority: 1081
Slaves:
java.1.gz /usr/lib/jvm/java-8-oracle/man/man1/java.1.gz
und auch dafür gesorgt, dass diese berüchtige Environment-Variable gesetzt ist
echo $JAVA_HOME
/usr/lib/jvm/java-8-oracle
Jetzt startet der Controller aber mal gar nicht
sudo service unifi status
● unifi.service - unifi
Loaded: loaded (/etc/systemd/system/unifi.service; enabled)
Active: activating (start) since Sa 2019-04-13 17:18:58 CEST; 943ms ago
Process: 3566 ExecStop=/usr/lib/unifi/bin/unifi.init stop (code=exited, status=0/SUCCESS)
Control: 3584 (unifi.init)
CGroup: /system.slice/unifi.service
├─3584 /bin/bash /usr/lib/unifi/bin/unifi.init start
└─3602 sleep 1
Apr 13 17:18:58 FHEM systemd[1]: Starting unifi...
Apr 13 17:18:58 FHEM unifi.init[3584]: Starting Ubiquiti UniFi Controller: unifiCannot locate Java Home
und der Hinweis ist deutlich: Finde die Java-Umgebung nicht. Die ist aber da?!
Die Seiten im Netz, die ich durchsucht habe, helfen nun nicht mehr weiter.
Moin. Versuche es mal damit.
https://raspberrypi.stackexchange.com/questions/45976/how-do-i-update-java-8-in-raspbian
(https://raspberrypi.stackexchange.com/questions/45976/how-do-i-update-java-8-in-raspbian)
Sollte klappen. Die oberste Antwort mit grünem Check.
Gruß
Maui
habe ich gemacht und bin bei
java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) Client VM (build 25.201-b09, mixed mode)
und es geht nicht.
Es ist zwar keine schöne Dauer Lösung aber als Test könntest du mal versuchen in der /etc/init.d/UniFi in Zeile 69 den openjdk Pfad gegen Oracle zu tauchen.
Wenn das klappt kann man ja gucken warum er nicht in den anderen Zweigen landet.
Gruß
Ja, die Stelle kenne ich; die ist berüchtigt. Vorher wird der Pfad ausgerechnet um dann direkt eingegeben zu werden (geniale Programmierung). Ich habe da alles, was möglich ist, probiert: Mit direkter Eingabe, ausrechnen, verschiedene Einträge...
Ohne Erfolg. Siehe Foto.
Aber hattest es auch mal einkommentiert?
Das jre/bin müsste am Ende noch weg
Zitat von: Maui am 14 April 2019, 10:55:59
Das jre/bin müsste am Ende noch weg
Ja, hatte ich auch schon. Siehe vorigen Post
Zitat von: andies am 13 April 2019, 17:38:18
und auch dafür gesorgt, dass diese berüchtige Environment-Variable gesetzt ist
echo $JAVA_HOME
/usr/lib/jvm/java-8-oracle
Aber auch im init. Skript? Da wird es überschrieben denke ich
im skript wird es komischerweise überschrieben. Ich habe dann mehrere Sachen probiert: Im Skript setzen, im Skript ausblenden und per terminal setzen - keine Änderung.
Gesendet von iPad mit Tapatalk Pro
Wie hast du es denn im Script überschrieben?
Zitat von: andies am 14 April 2019, 09:56:30
Vorher wird der Pfad ausgerechnet um dann direkt eingegeben zu werden (geniale Programmierung).
Der Pfad zur JVM wird nicht im Script am Ende überschrieben. In den Schleifen gibt es ein return beim ersten Treffer. Ganz am Ende ist ein Default, falls vorher nichts gefunden wurde.
Wenn du das im Script anpasst, dann zumindest die beiden returns auskommentieren (oder alles was vor der letzten Zeile kommt).
Ich hatte damit damals auch Probleme. Kann mich aber nicht mehr dran erinnern, wie genau ich sie gelöst habe. Das init-Script ist bei mir aber Original von Unifi. Ich habe aber anscheinend alle alten Java deinstalliert und die Oracle-Java-Installation war auch erst nach zwei oder drei Anläufen funktionsfähig mit Unifi. Kommt wohl sehr darauf an, wie dein System sonst so aussieht. War bei mir auch viel googlei.
Viel Erfolg,
Dirk
Ja, das hatte ich mir dann auch klar gemacht. Ärgerlich ist, dass die Dokumentationen im Netz alle sehr spärlich sind und man enorm viel Zeit versenkt. Da ich derzeit nur ein unifi habe, will ich jetzt nicht mehr so viel in das Modul investieren; der Zugang geht momentan auch so. Vielleicht probiere ich das später einmal aus.
Und dann würde ich auch im Wiki etwas aufschreiben. An sich ist das ja eine Katastrophe mit diesem controller auf dem RPi. Anscheinend is Java das Problem, aber so sicher war ich mir nicht.
ZitatAn sich ist das ja eine Katastrophe mit diesem controller auf dem RPi.
Ich hatte versuchsweise den Unifi-Controller auf einem RPi3B installiert, ohne ihn jedoch produktiv zu nutzen. Ich hatte dabei 2 Beobachtungen gemacht, bevor ich ihn deinstalliert hatte:
- signifikant höhere Temperatur im RPi3B
- Vollschreiben des Speichers durch Unifi
Jetzt laufen Fhem und Unifi auf einem HP ThinClient T610 zur vollsten Zufriedenheit.
Viele Grüße Gisbert
Also ich habe den Controller seit 1 Jahr problemlos auf einem Pi3.
Weder erhöhte Last noch RAM voll
Gruß
Maui
ZitatWeder erhöhte Last noch RAM voll
Hallo Maui,
kann sein, dass es auch an mir lag, dass es zu einem Problem kam. Es wurde aber nicht der RAM vollgeschrieben, sondern die SD-Karte, so dass letztendlich für Fhem kein Platz übrig blieb.
Viele Grüße Gisbert
Moin Gisbert, ist vielleicht auch eine Frage mit welcher Controller Version du getestet hast und wie groß deine SD war. Meine mit 64 GB wird mein UniFi (hoffentlich) nie vollschreiben.
@andies: Versuch doch mal UniFi im docker Container.
Moin Wuehler,
Hast du auch eine Idee, warum nach 9 Tagen und 12 Std. Kein Update mehr kommt bei disconnected devices?
Gruß
Maui
Moin,
Hast du ein fhem-Update gemacht? Der Fix ist noch nicht im Repository.
Ne bewusst nicht gemacht
Beim update Check wird mir dein Modul auch noch angezeigt.
Ich lösche die devices nochmal und starte nochmal neu mit 0 Tagen vielleicht hat es irgendwo anders geharkt
Jetzt weiß ich woran es lag. Hab ein Update vom Controller selbst gemacht.
Moin zusammen,
@Maui: Dann bin ich beruhigt ;)
@all: Habe den fix zum Update der Readings von disconnected-clients jetzt auch commited. Morgen Vormittag dann im Update.
Wenn ich die Abhängigkeiten richtig sehe hat der Fix nur Auswirkungen auf das Verhalten in FHEM, wenn das Attribut event-on-change-reading nicht genutzt wird. Dann gibt es bei disconnected-clients öfter mal ein Event zum Update des Readings. Denke, das darauf bei disconnected-clients keiner ein notify drauf hat. Und wenn dann auf den state, und der wurde auch bisher schon bei jedem Update-Intervall erneut auf disconnected gesetzt.
VG,
Dirk
Hallo zusammen,
aus den letzten Diskussionen hatte ich noch zwei ToDos mitgenommen. Da ich gerade Zeit und Lust hatte befindet sich im Anhang eine neue Version für interessierte Tester. (Läuft bei mir jetzt 2h stabil ;) )
Folgende Änderungen haben sich dabei ergeben:
- Aulesen der Insights: Jeder Client hat immer eine interne Information, ob er geblocked ist (siehe getClientData). Über customClientReadings kann ein Reading dazu erzeugt werden. Wenn ein Client 365 Tage disconnected war, wird die Information nicht weiter aktualisiert.
- neues Reading "-UC_blockedClients: Eine Liste der geblockten Clients. Der Client muss dem Modul aber mindestens ein mal bekannt (connected) gewesen sein.
- neuer setter removeClientReadings: Hiermit können die Readings von disconnected Clients entfernt werden.
- Anpassung Drop-Down-Listen für ...
- blockClient: nur nicht geblockte Clients
- unblockClient: nur geblockte Clients
- disconnectClient: nur connected Clients
- removeClientReadings: nur disconnected Clients
Falls jemand Zeit und Lust zum Testen hat: gerne Feedback.
Ein schönes Osterfest euch allen,
Dirk
Guten Morgen Wuehler,
sag mal gibt es eigentlich eine möglichkeit aus FHEM heraus ein Radius Profil zu deaktivieren?
Das wäre eine tolle Anwedung für mich...
Moin,
nein, das ist aktuell nicht möglich, wäre aber möglich. Für das Modul selbst finde ich den UseCase ein wenig speziell ;)
@Maui: Hattest du nicht auch mal ein script, mit Login im UnifiController und anschließendem Funktionsaufruf? Das könnte man hierfür bestimmt nutzen.
VG,
Dirk
Hallo zusammen,
bei der Beschäftigung mit den Informationen des Unif-Controllers ist mir aufgefallen, dass man soetwas wie Onlinezeit damit tracken kann. Das kann dann dazu verwendet werden wie bei der Fritzbox z.B. 2h Onlinezeit für ein Gerät am Tag zuzulassen. Mittel block-/unblockClient kann man das Geräte dann aus dem WLAN/LAN aussperren und am nächsten Tag wieder zulassen. Ich habe mir die Ansätze dazu aus notifies und dummys zusammengebaut. Scheint grundsätzlich zu funktionieren, ist aber noch deutlich optimierbar.
Wenn ausreichend Interesse besteht könnte ein Modul UnifiClient die nächste Erweiterung sein. Wie ist eure Meinung?
VG,
Dirk
Na da würde sich ja dann sicher auch ein Radius Switch drin abbilden lassen, oder? ;-)
Moin Dirk,
Zitat von: Wuehler am 20 April 2019, 18:42:04
Wenn ausreichend Interesse besteht könnte ein Modul UnifiClient die nächste Erweiterung sein. Wie ist eure Meinung?
ich bekunde auf jeden Fall Interesse. Mein Sohn wird dich zwar irgendwann mal hassen, aber ich verrate dich nicht. ;D 8)
Gruß
Wolle
Finde ich auch interessant. :)
Dann werde ich mal anfangen an einem Modul UnifiClient mit einer solchen Funktionalität zu basteln.
@Lolo: Wenn ich dich richtig verstehe meinst du unter Settings->Profiles->Radius->Edit->"Enable RADIUS assigned VLAN for wired network"
Oder etwas anderes? Das hätte meiner Meinung mit einem Modul UnifiClient nicht o viel zu tun. Aber Diskussion gerne.
Mit PHP-Mittel kann man sich auch recht einfach eine spezielle Funktionalität programmieren. siehe z.B.
https://forum.fhem.de/index.php/topic,78247.30.html (https://forum.fhem.de/index.php/topic,78247.30.html)
Vielleicht kann diese API auch die Radius-Profile bearbeiten.
PS: Wozu brauchst du das eigentlich genau?
Hallo,
vor 1 Woche habe ich meinen UniFi-Controller umgezogen auf eine neue VM (jetzt Debian 9.8, vorher 8.x).
Einzige Änderungen sind die IP-Adresse und das Passwort beim Controller. Die APs und mein Switch sind unverändert geblieben.
In FHEM habe ich den vorhandenen UniFi-Controller und –Switch gelöscht und dann wieder mit den geänderten Daten (IP / Passwort) angelegt. Ich bekomme jetzt aber keine Daten vom Controller zu dem Switch und den APs.
Ein List meiner Definition:
Internals:
CFGFN
CHANGED
DEF 192.168.0.223 8443 crypt:<xxxx> crypt:<yyyy>
FUUID 5cb70149-f33f-fba2-a756-8a9334ed298577c7
NAME my_unifi_controller
NOTIFYDEV global
NR 24348
NTFY_ORDER 50-my_unifi_controller
STATE connected
TYPE Unifi
UC_VERSION 5.10.20
VERSION 3.2.6
READINGS:
2019-04-22 10:21:07 -UC_events 0 (last 24h)
2019-04-22 10:21:07 -UC_newClients
2019-04-22 10:21:07 -UC_unarchived_alerts 0
2019-04-22 10:21:07 -UC_wlan_accesspoints 0
2019-04-22 10:21:07 -UC_wlan_state unknown
2019-04-17 12:34:49 state connected
accespoints:
alerts_unarchived:
clients:
events:
helper:
password crypt:<yyyy>
username crypt:<xxxx>
hotspot:
voucherCache:
vouchers:
httpParams:
header Cookie: unifises=vxzW3yWY5t1HPY8RlLw1y5A0X7DjRNMF;\r\nCookie: csrf_token=X13G5dKrHD5pa6oSZ5fbBzXyek2ZpM6c;
ignoreredirects 1
loglevel 5
method POST
noshutdown 0
timeout 5
hash:
sslargs:
SSL_verify_mode 0
unifi:
CONNECTED connected
connectedClients
eventPeriod 24
interval 30
updateStartTime 1555921266.35375
url https://192.168.0.223:8443/api/s/default/
customClientReadings:
attr_value .:^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime
parts:
0000000_part:
ReadingRegEx ^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime
nameRegEx .
updateDispatch:
wan_health:
num_adopted 0
num_disconnected 0
num_gw 0
num_pending 0
status unknown
subsystem wan
wlan_health:
num_adopted 0
num_ap 0
num_disabled 0
num_disconnected 0
num_pending 0
status unknown
subsystem wlan
wlans:
www_health:
status unknown
subsystem www
Attributes:
event-on-change-reading .*
room Server
Leider keine weiteren Daten seit dem 16.04. Freue mich über Hilfe.
Frohe Restostern
Holger
Moin,
Hast du mal ein manuelles Update gemacht?
set my_unifi_controller update
Evtl. ist das Update-Intervall nicht richtig gestartet worden.
Ansonsten sieht es ja so aus, als ob das Modul sich verbinden konnte.
update hat keine Änderung gebracht - außer das die Timestamps in den Readings aktualisiert wurden.
Nach dem update habe ich mich am Controller angemeldet, um dort auf evtl. Meldungen zu schauen.
Das führte in FHEM beim Reading UC_events zu einer Änderung. Die Verbindung als solche ist also definitiv da.
UC_events 1 (last 24h) 2019-04-22 12:03:41
Holt sich das Modul seine Daten ausschließlich vom Controller oder auch direkt von den APs und dem Switch? Die haben noch mein ursprüngliches Passwort.
Hast du das Attribut customClientReadings gesetzt?
Oder hast du einen sitenamen vergeben? (Nicht default)
Hat der user des Moduls evtl. nur eingeschränkte Rechte?
Das Modul fragt nur den Controller ab, nicht die APs usw.
Edit: Mach mal ein Log mit verbose=5. Mal sehen was da an Meldungen kommt.
customClientReadings gesetzt? --> nein
sitenamen vergeben? --> nein (default)
user des Moduls evtl. nur eingeschränkte Rechte? --> nein, verwende einen Admin
Log (verbose 5 und nach ca. 2 min. zusätzlich httpLoglevel auch auf 5)
2019.04.22 16:51:19 5: my_unifi_controller (Unifi_Notify) - executed.
2019.04.22 16:51:19 5: my_unifi_controller: get called with ?.
2019.04.22 16:51:25 5: my_unifi_controller (Unifi_DoUpdate) - executed.
2019.04.22 16:51:25 5: my_unifi_controller (Unifi_GetAccesspoints_Send) - executed.
2019.04.22 16:51:25 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - executed.
2019.04.22 16:51:25 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2019.04.22 16:51:25 5: my_unifi_controller (Unifi_GetClients_Send) - executed.
2019.04.22 16:51:25 5: my_unifi_controller (Unifi_GetClients_Receive) - executed.
2019.04.22 16:51:25 5: my_unifi_controller (Unifi_GetClients_Receive) - state:'ok'
2019.04.22 16:51:25 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2019.04.22 16:51:25 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2019.04.22 16:51:25 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2019.04.22 16:51:25 5: my_unifi_controller (Unifi_GetHealth_Send) - executed.
2019.04.22 16:51:25 5: my_unifi_controller (Unifi_GetHealth_Receive) - executed.
2019.04.22 16:51:25 5: my_unifi_controller (Unifi_GetHealth_Receive) - state:'ok'
2019.04.22 16:51:25 5: my_unifi_controller (Unifi_GetVoucherList_Send) - executed.
2019.04.22 16:51:25 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - executed.
2019.04.22 16:51:25 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - state:'ok'
2019.04.22 16:51:25 5: my_unifi_controller (Unifi_GetEvents_Send) - executed.
2019.04.22 16:51:25 5: my_unifi_controller (Unifi_GetEvents_Receive) - executed.
2019.04.22 16:51:25 5: my_unifi_controller (Unifi_GetEvents_Receive) - state:'ok'
2019.04.22 16:51:25 5: my_unifi_controller (Unifi_GetWlans_Send) - executed.
2019.04.22 16:51:26 5: my_unifi_controller (Unifi_GetWlans_Receive) - executed.
2019.04.22 16:51:26 5: my_unifi_controller (Unifi_GetWlans_Receive) - state:'ok'
2019.04.22 16:51:26 5: my_unifi_controller (Unifi_ProcessUpdate) - executed after 0.7506 seconds.
2019.04.22 16:51:26 5: my_unifi_controller (Unifi_SetHealthReadings) - executed.
2019.04.22 16:51:26 5: my_unifi_controller (Unifi_SetClientReadings) - executed.
2019.04.22 16:51:26 5: my_unifi_controller (Unifi_SetAccesspointReadings) - executed.
2019.04.22 16:51:26 5: my_unifi_controller (Unifi_SetWlanReadings) - executed.
2019.04.22 16:51:26 5: my_unifi_controller (Unifi_SetVoucherReadings) - executed.
2019.04.22 16:51:26 5: my_unifi_controller (Unifi_ProcessUpdate) - finished after 0.7512 seconds.
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_DoUpdate) - executed.
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_GetClients_Send) - executed.
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_GetClients_Receive) - executed.
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_GetClients_Receive) - state:'ok'
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_GetHealth_Send) - executed.
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_GetHealth_Receive) - executed.
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_GetHealth_Receive) - state:'ok'
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_GetAccesspoints_Send) - executed.
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - executed.
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_GetEvents_Send) - executed.
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_GetEvents_Receive) - executed.
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_GetEvents_Receive) - state:'ok'
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_GetWlans_Send) - executed.
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_GetWlans_Receive) - executed.
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_GetWlans_Receive) - state:'ok'
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_GetVoucherList_Send) - executed.
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - executed.
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - state:'ok'
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_ProcessUpdate) - executed after 0.5942 seconds.
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_SetHealthReadings) - executed.
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_SetClientReadings) - executed.
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_SetAccesspointReadings) - executed.
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_SetWlanReadings) - executed.
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_SetVoucherReadings) - executed.
2019.04.22 16:51:56 5: my_unifi_controller (Unifi_ProcessUpdate) - finished after 0.5945 seconds.
2019.04.22 16:52:26 5: my_unifi_controller (Unifi_DoUpdate) - executed.
2019.04.22 16:52:26 5: my_unifi_controller (Unifi_GetEvents_Send) - executed.
2019.04.22 16:52:26 5: my_unifi_controller (Unifi_GetEvents_Receive) - executed.
2019.04.22 16:52:26 5: my_unifi_controller (Unifi_GetEvents_Receive) - state:'ok'
2019.04.22 16:52:26 5: my_unifi_controller (Unifi_GetWlans_Send) - executed.
2019.04.22 16:52:26 5: my_unifi_controller (Unifi_GetWlans_Receive) - executed.
2019.04.22 16:52:26 5: my_unifi_controller (Unifi_GetWlans_Receive) - state:'ok'
2019.04.22 16:52:26 5: my_unifi_controller (Unifi_GetVoucherList_Send) - executed.
2019.04.22 16:52:26 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - executed.
2019.04.22 16:52:26 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - state:'ok'
2019.04.22 16:52:26 5: my_unifi_controller (Unifi_GetHealth_Send) - executed.
2019.04.22 16:52:26 5: my_unifi_controller (Unifi_GetHealth_Receive) - executed.
2019.04.22 16:52:26 5: my_unifi_controller (Unifi_GetHealth_Receive) - state:'ok'
2019.04.22 16:52:26 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2019.04.22 16:52:26 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2019.04.22 16:52:26 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2019.04.22 16:52:26 5: my_unifi_controller (Unifi_GetClients_Send) - executed.
2019.04.22 16:52:27 5: my_unifi_controller (Unifi_GetClients_Receive) - executed.
2019.04.22 16:52:27 5: my_unifi_controller (Unifi_GetClients_Receive) - state:'ok'
2019.04.22 16:52:27 5: my_unifi_controller (Unifi_GetAccesspoints_Send) - executed.
2019.04.22 16:52:27 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - executed.
2019.04.22 16:52:27 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2019.04.22 16:52:27 5: my_unifi_controller (Unifi_ProcessUpdate) - executed after 0.5853 seconds.
2019.04.22 16:52:27 5: my_unifi_controller (Unifi_SetHealthReadings) - executed.
2019.04.22 16:52:27 5: my_unifi_controller (Unifi_SetClientReadings) - executed.
2019.04.22 16:52:27 5: my_unifi_controller (Unifi_SetAccesspointReadings) - executed.
2019.04.22 16:52:27 5: my_unifi_controller (Unifi_SetWlanReadings) - executed.
2019.04.22 16:52:27 5: my_unifi_controller (Unifi_SetVoucherReadings) - executed.
2019.04.22 16:52:27 5: my_unifi_controller (Unifi_ProcessUpdate) - finished after 0.5857 seconds.
2019.04.22 16:52:43 5: my_unifi_controller (Unifi_Notify) - executed.
2019.04.22 16:52:43 5: my_unifi_controller: get called with ?.
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_DoUpdate) - executed.
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_GetAccesspoints_Send) - executed.
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - executed.
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_GetHealth_Send) - executed.
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_GetHealth_Receive) - executed.
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_GetHealth_Receive) - state:'ok'
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_GetClients_Send) - executed.
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_GetClients_Receive) - executed.
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_GetClients_Receive) - state:'ok'
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_GetVoucherList_Send) - executed.
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - executed.
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - state:'ok'
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_GetWlans_Send) - executed.
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_GetWlans_Receive) - executed.
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_GetWlans_Receive) - state:'ok'
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_GetEvents_Send) - executed.
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_GetEvents_Receive) - executed.
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_GetEvents_Receive) - state:'ok'
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_ProcessUpdate) - executed after 0.6904 seconds.
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_SetHealthReadings) - executed.
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_SetClientReadings) - executed.
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_SetAccesspointReadings) - executed.
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_SetWlanReadings) - executed.
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_SetVoucherReadings) - executed.
2019.04.22 16:52:57 5: my_unifi_controller (Unifi_ProcessUpdate) - finished after 0.6909 seconds.
2019.04.22 16:53:27 5: my_unifi_controller (Unifi_DoUpdate) - executed.
2019.04.22 16:53:27 5: my_unifi_controller (Unifi_GetVoucherList_Send) - executed.
2019.04.22 16:53:27 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - executed.
2019.04.22 16:53:27 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - state:'ok'
2019.04.22 16:53:27 5: my_unifi_controller (Unifi_GetEvents_Send) - executed.
2019.04.22 16:53:28 5: my_unifi_controller (Unifi_GetEvents_Receive) - executed.
2019.04.22 16:53:28 5: my_unifi_controller (Unifi_GetEvents_Receive) - state:'ok'
2019.04.22 16:53:28 5: my_unifi_controller (Unifi_GetWlans_Send) - executed.
2019.04.22 16:53:28 5: my_unifi_controller (Unifi_GetWlans_Receive) - executed.
2019.04.22 16:53:28 5: my_unifi_controller (Unifi_GetWlans_Receive) - state:'ok'
2019.04.22 16:53:28 5: my_unifi_controller (Unifi_GetAccesspoints_Send) - executed.
2019.04.22 16:53:28 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - executed.
2019.04.22 16:53:28 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2019.04.22 16:53:28 5: my_unifi_controller (Unifi_GetClients_Send) - executed.
2019.04.22 16:53:29 5: my_unifi_controller (Unifi_GetClients_Receive) - executed.
2019.04.22 16:53:29 5: my_unifi_controller (Unifi_GetClients_Receive) - state:'ok'
2019.04.22 16:53:29 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2019.04.22 16:53:29 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2019.04.22 16:53:29 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2019.04.22 16:53:29 5: my_unifi_controller (Unifi_GetHealth_Send) - executed.
2019.04.22 16:53:29 5: my_unifi_controller (Unifi_GetHealth_Receive) - executed.
2019.04.22 16:53:29 5: my_unifi_controller (Unifi_GetHealth_Receive) - state:'ok'
2019.04.22 16:53:29 5: my_unifi_controller (Unifi_ProcessUpdate) - executed after 1.2677 seconds.
2019.04.22 16:53:29 5: my_unifi_controller (Unifi_SetHealthReadings) - executed.
2019.04.22 16:53:29 5: my_unifi_controller (Unifi_SetClientReadings) - executed.
2019.04.22 16:53:29 5: my_unifi_controller (Unifi_SetAccesspointReadings) - executed.
2019.04.22 16:53:29 5: my_unifi_controller (Unifi_SetWlanReadings) - executed.
2019.04.22 16:53:29 5: my_unifi_controller (Unifi_SetVoucherReadings) - executed.
2019.04.22 16:53:29 5: my_unifi_controller (Unifi_ProcessUpdate) - finished after 1.2682 seconds.
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_DoUpdate) - executed.
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_GetAccesspoints_Send) - executed.
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - executed.
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_GetClients_Send) - executed.
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_GetClients_Receive) - executed.
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_GetClients_Receive) - state:'ok'
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_GetHealth_Send) - executed.
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_GetHealth_Receive) - executed.
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_GetHealth_Receive) - state:'ok'
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_GetVoucherList_Send) - executed.
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - executed.
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - state:'ok'
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_GetEvents_Send) - executed.
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_GetEvents_Receive) - executed.
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_GetEvents_Receive) - state:'ok'
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_GetWlans_Send) - executed.
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_GetWlans_Receive) - executed.
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_GetWlans_Receive) - state:'ok'
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_ProcessUpdate) - executed after 0.4478 seconds.
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_SetHealthReadings) - executed.
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_SetClientReadings) - executed.
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_SetAccesspointReadings) - executed.
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_SetWlanReadings) - executed.
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_SetVoucherReadings) - executed.
2019.04.22 16:53:59 5: my_unifi_controller (Unifi_ProcessUpdate) - finished after 0.4482 seconds.
2019.04.22 16:54:23 5: my_unifi_controller (Unifi_Notify) - executed.
2019.04.22 16:54:23 5: my_unifi_controller: get called with ?.
Ich hoffe, du kannst etwas erkennen.
Auf jeden Fall schon mal ein riesiges Dankeschön für deine Unterstützung.
Holger
Moin Holger,
mmmh, bin momentan noch ratlos. Sieht eigentlich gut aus. Editiere bitte das Modul und erweitere es um die Zeile
Log3 $name, 5, "$name ($self) - data: ".$data;
An folgender Position:
sub Unifi_GetClients_Receive($) {
my ($param, $err, $data) = @_;
my ($name,$self,$hash) = ($param->{hash}->{NAME},Unifi_Whoami(),$param->{hash});
Log3 $name, 5, "$name ($self) - executed.";
if ($err ne "") {
Unifi_ReceiveFailure($hash,{rc => 'Error while requesting', msg => $param->{url}." - $err"});
}
elsif ($data ne "") {
if ($param->{code} == 200 || $param->{code} == 400 || $param->{code} == 401) {
eval { $data = decode_json($data); 1; } or do { $data = { meta => {rc => 'error.decode_json', msg => $@} }; };
if ($data->{meta}->{rc} eq "ok") {
Log3 $name, 5, "$name ($self) - state:'$data->{meta}->{rc}'";
# hier muss die Zeile eingefügt werden:
Log3 $name, 5, "$name ($self) - data: ".$data;
$hash->{unifi}->{connectedClients} = undef;
for my $h (@{$data->{data}}) {
Das Ergebnis im Log (verbose=5) brauche ich dann wieder. Ggf. auch als pm.
VG,
Dirk
Hallo zusammen,
ich habe zum UnifiClient einen neuen Thread zur Diskussion der Features eröffnet:
https://forum.fhem.de/index.php/topic,99864.0.html (https://forum.fhem.de/index.php/topic,99864.0.html)
Wer Interesse hat kann sich dort eine Beta herunterladen und mir gerne Feedback geben.
VG,
Dirk
Moin Dirk,
habe die Zeile eingefügt und dann ein "reload 74_Unifi.pm" gemacht. Anschließend verbose 5.
Um 07:41 habe ich mich parallel am Controller angemeldet - vielleicht kannst du das ja erkennen.
2019.04.23 07:39:03 5: my_unifi_controller (Unifi_Notify) - executed.
2019.04.23 07:39:04 5: my_unifi_controller: get called with ?.
2019.04.23 07:39:33 5: my_unifi_controller (Unifi_DoUpdate) - executed.
2019.04.23 07:39:33 5: my_unifi_controller (Unifi_GetEvents_Send) - executed.
2019.04.23 07:39:34 5: my_unifi_controller (Unifi_GetEvents_Receive) - executed.
2019.04.23 07:39:34 5: my_unifi_controller (Unifi_GetEvents_Receive) - state:'ok'
2019.04.23 07:39:34 5: my_unifi_controller (Unifi_GetWlans_Send) - executed.
2019.04.23 07:39:34 5: my_unifi_controller (Unifi_GetWlans_Receive) - executed.
2019.04.23 07:39:34 5: my_unifi_controller (Unifi_GetWlans_Receive) - state:'ok'
2019.04.23 07:39:34 5: my_unifi_controller (Unifi_GetVoucherList_Send) - executed.
2019.04.23 07:39:34 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - executed.
2019.04.23 07:39:34 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - state:'ok'
2019.04.23 07:39:34 5: my_unifi_controller (Unifi_GetHealth_Send) - executed.
2019.04.23 07:39:34 5: my_unifi_controller (Unifi_GetHealth_Receive) - executed.
2019.04.23 07:39:34 5: my_unifi_controller (Unifi_GetHealth_Receive) - state:'ok'
2019.04.23 07:39:34 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2019.04.23 07:39:34 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2019.04.23 07:39:34 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2019.04.23 07:39:34 5: my_unifi_controller (Unifi_GetClients_Send) - executed.
2019.04.23 07:39:35 5: my_unifi_controller (Unifi_GetClients_Receive) - executed.
2019.04.23 07:39:35 5: my_unifi_controller (Unifi_GetClients_Receive) - state:'ok'
2019.04.23 07:39:35 5: my_unifi_controller (Unifi_GetClients_Receive) - data: HASH(0xaac65e8)
2019.04.23 07:39:35 5: my_unifi_controller (Unifi_GetAccesspoints_Send) - executed.
2019.04.23 07:39:35 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - executed.
2019.04.23 07:39:35 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2019.04.23 07:39:35 5: my_unifi_controller (Unifi_ProcessUpdate) - executed after 1.7337 seconds.
2019.04.23 07:39:35 5: my_unifi_controller (Unifi_SetHealthReadings) - executed.
2019.04.23 07:39:35 5: my_unifi_controller (Unifi_SetClientReadings) - executed.
2019.04.23 07:39:35 5: my_unifi_controller (Unifi_SetAccesspointReadings) - executed.
2019.04.23 07:39:35 5: my_unifi_controller (Unifi_SetWlanReadings) - executed.
2019.04.23 07:39:35 5: my_unifi_controller (Unifi_SetVoucherReadings) - executed.
2019.04.23 07:39:35 5: my_unifi_controller (Unifi_ProcessUpdate) - finished after 1.7368 seconds.
2019.04.23 07:40:05 5: my_unifi_controller (Unifi_DoUpdate) - executed.
2019.04.23 07:40:05 5: my_unifi_controller (Unifi_GetVoucherList_Send) - executed.
2019.04.23 07:40:05 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - executed.
2019.04.23 07:40:05 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - state:'ok'
2019.04.23 07:40:05 5: my_unifi_controller (Unifi_GetWlans_Send) - executed.
2019.04.23 07:40:05 5: my_unifi_controller (Unifi_GetWlans_Receive) - executed.
2019.04.23 07:40:05 5: my_unifi_controller (Unifi_GetWlans_Receive) - state:'ok'
2019.04.23 07:40:05 5: my_unifi_controller (Unifi_GetEvents_Send) - executed.
2019.04.23 07:40:05 5: my_unifi_controller (Unifi_GetEvents_Receive) - executed.
2019.04.23 07:40:05 5: my_unifi_controller (Unifi_GetEvents_Receive) - state:'ok'
2019.04.23 07:40:05 5: my_unifi_controller (Unifi_GetAccesspoints_Send) - executed.
2019.04.23 07:40:06 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - executed.
2019.04.23 07:40:06 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2019.04.23 07:40:06 5: my_unifi_controller (Unifi_GetClients_Send) - executed.
2019.04.23 07:40:06 5: my_unifi_controller (Unifi_GetClients_Receive) - executed.
2019.04.23 07:40:06 5: my_unifi_controller (Unifi_GetClients_Receive) - state:'ok'
2019.04.23 07:40:06 5: my_unifi_controller (Unifi_GetClients_Receive) - data: HASH(0xa70a860)
2019.04.23 07:40:06 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2019.04.23 07:40:06 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2019.04.23 07:40:06 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2019.04.23 07:40:06 5: my_unifi_controller (Unifi_GetHealth_Send) - executed.
2019.04.23 07:40:06 5: my_unifi_controller (Unifi_GetHealth_Receive) - executed.
2019.04.23 07:40:06 5: my_unifi_controller (Unifi_GetHealth_Receive) - state:'ok'
2019.04.23 07:40:06 5: my_unifi_controller (Unifi_ProcessUpdate) - executed after 0.7825 seconds.
2019.04.23 07:40:06 5: my_unifi_controller (Unifi_SetHealthReadings) - executed.
2019.04.23 07:40:06 5: my_unifi_controller (Unifi_SetClientReadings) - executed.
2019.04.23 07:40:06 5: my_unifi_controller (Unifi_SetAccesspointReadings) - executed.
2019.04.23 07:40:06 5: my_unifi_controller (Unifi_SetWlanReadings) - executed.
2019.04.23 07:40:06 5: my_unifi_controller (Unifi_SetVoucherReadings) - executed.
2019.04.23 07:40:06 5: my_unifi_controller (Unifi_ProcessUpdate) - finished after 0.7832 seconds.
2019.04.23 07:40:36 5: my_unifi_controller (Unifi_DoUpdate) - executed.
2019.04.23 07:40:36 5: my_unifi_controller (Unifi_GetAccesspoints_Send) - executed.
2019.04.23 07:40:36 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - executed.
2019.04.23 07:40:36 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2019.04.23 07:40:36 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2019.04.23 07:40:36 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2019.04.23 07:40:36 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2019.04.23 07:40:36 5: my_unifi_controller (Unifi_GetHealth_Send) - executed.
2019.04.23 07:40:36 5: my_unifi_controller (Unifi_GetHealth_Receive) - executed.
2019.04.23 07:40:36 5: my_unifi_controller (Unifi_GetHealth_Receive) - state:'ok'
2019.04.23 07:40:36 5: my_unifi_controller (Unifi_GetClients_Send) - executed.
2019.04.23 07:40:36 5: my_unifi_controller (Unifi_GetClients_Receive) - executed.
2019.04.23 07:40:36 5: my_unifi_controller (Unifi_GetClients_Receive) - state:'ok'
2019.04.23 07:40:36 5: my_unifi_controller (Unifi_GetClients_Receive) - data: HASH(0xa9199a8)
2019.04.23 07:40:36 5: my_unifi_controller (Unifi_GetVoucherList_Send) - executed.
2019.04.23 07:40:36 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - executed.
2019.04.23 07:40:36 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - state:'ok'
2019.04.23 07:40:36 5: my_unifi_controller (Unifi_GetWlans_Send) - executed.
2019.04.23 07:40:36 5: my_unifi_controller (Unifi_GetWlans_Receive) - executed.
2019.04.23 07:40:36 5: my_unifi_controller (Unifi_GetWlans_Receive) - state:'ok'
2019.04.23 07:40:36 5: my_unifi_controller (Unifi_GetEvents_Send) - executed.
2019.04.23 07:40:37 5: my_unifi_controller (Unifi_GetEvents_Receive) - executed.
2019.04.23 07:40:37 5: my_unifi_controller (Unifi_GetEvents_Receive) - state:'ok'
2019.04.23 07:40:37 5: my_unifi_controller (Unifi_ProcessUpdate) - executed after 0.6939 seconds.
2019.04.23 07:40:37 5: my_unifi_controller (Unifi_SetHealthReadings) - executed.
2019.04.23 07:40:37 5: my_unifi_controller (Unifi_SetClientReadings) - executed.
2019.04.23 07:40:37 5: my_unifi_controller (Unifi_SetAccesspointReadings) - executed.
2019.04.23 07:40:37 5: my_unifi_controller (Unifi_SetWlanReadings) - executed.
2019.04.23 07:40:37 5: my_unifi_controller (Unifi_SetVoucherReadings) - executed.
2019.04.23 07:40:37 5: my_unifi_controller (Unifi_ProcessUpdate) - finished after 0.6944 seconds.
2019.04.23 07:41:07 5: my_unifi_controller (Unifi_DoUpdate) - executed.
2019.04.23 07:41:07 5: my_unifi_controller (Unifi_GetWlans_Send) - executed.
2019.04.23 07:41:07 5: my_unifi_controller (Unifi_GetWlans_Receive) - executed.
2019.04.23 07:41:07 5: my_unifi_controller (Unifi_GetWlans_Receive) - state:'ok'
2019.04.23 07:41:07 5: my_unifi_controller (Unifi_GetEvents_Send) - executed.
2019.04.23 07:41:07 5: my_unifi_controller (Unifi_GetEvents_Receive) - executed.
2019.04.23 07:41:07 5: my_unifi_controller (Unifi_GetEvents_Receive) - state:'ok'
2019.04.23 07:41:07 5: my_unifi_controller (Unifi_GetVoucherList_Send) - executed.
2019.04.23 07:41:08 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - executed.
2019.04.23 07:41:08 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - state:'ok'
2019.04.23 07:41:08 5: my_unifi_controller (Unifi_GetClients_Send) - executed.
2019.04.23 07:41:08 5: my_unifi_controller (Unifi_GetClients_Receive) - executed.
2019.04.23 07:41:08 5: my_unifi_controller (Unifi_GetClients_Receive) - state:'ok'
2019.04.23 07:41:08 5: my_unifi_controller (Unifi_GetClients_Receive) - data: HASH(0xa894020)
2019.04.23 07:41:08 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2019.04.23 07:41:08 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2019.04.23 07:41:08 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2019.04.23 07:41:08 5: my_unifi_controller (Unifi_GetHealth_Send) - executed.
2019.04.23 07:41:08 5: my_unifi_controller (Unifi_GetHealth_Receive) - executed.
2019.04.23 07:41:08 5: my_unifi_controller (Unifi_GetHealth_Receive) - state:'ok'
2019.04.23 07:41:08 5: my_unifi_controller (Unifi_GetAccesspoints_Send) - executed.
2019.04.23 07:41:09 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - executed.
2019.04.23 07:41:09 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2019.04.23 07:41:09 5: my_unifi_controller (Unifi_ProcessUpdate) - executed after 1.6049 seconds.
2019.04.23 07:41:09 5: my_unifi_controller (Unifi_SetHealthReadings) - executed.
2019.04.23 07:41:09 5: my_unifi_controller (Unifi_SetClientReadings) - executed.
2019.04.23 07:41:09 5: my_unifi_controller (Unifi_SetAccesspointReadings) - executed.
2019.04.23 07:41:09 5: my_unifi_controller (Unifi_SetWlanReadings) - executed.
2019.04.23 07:41:09 5: my_unifi_controller (Unifi_SetVoucherReadings) - executed.
2019.04.23 07:41:09 5: my_unifi_controller (Unifi_ProcessUpdate) - finished after 1.6055 seconds.
2019.04.23 07:41:39 5: my_unifi_controller (Unifi_DoUpdate) - executed.
2019.04.23 07:41:39 5: my_unifi_controller (Unifi_GetWlans_Send) - executed.
2019.04.23 07:41:39 5: my_unifi_controller (Unifi_GetWlans_Receive) - executed.
2019.04.23 07:41:39 5: my_unifi_controller (Unifi_GetWlans_Receive) - state:'ok'
2019.04.23 07:41:39 5: my_unifi_controller (Unifi_GetEvents_Send) - executed.
2019.04.23 07:41:39 5: my_unifi_controller (Unifi_GetEvents_Receive) - executed.
2019.04.23 07:41:39 5: my_unifi_controller (Unifi_GetEvents_Receive) - state:'ok'
2019.04.23 07:41:39 5: my_unifi_controller (Unifi_GetVoucherList_Send) - executed.
2019.04.23 07:41:39 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - executed.
2019.04.23 07:41:39 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - state:'ok'
2019.04.23 07:41:39 5: my_unifi_controller (Unifi_GetClients_Send) - executed.
2019.04.23 07:41:39 5: my_unifi_controller (Unifi_GetClients_Receive) - executed.
2019.04.23 07:41:39 5: my_unifi_controller (Unifi_GetClients_Receive) - state:'ok'
2019.04.23 07:41:39 5: my_unifi_controller (Unifi_GetClients_Receive) - data: HASH(0xa07a430)
2019.04.23 07:41:39 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2019.04.23 07:41:39 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2019.04.23 07:41:39 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2019.04.23 07:41:39 5: my_unifi_controller (Unifi_GetHealth_Send) - executed.
2019.04.23 07:41:39 5: my_unifi_controller (Unifi_GetHealth_Receive) - executed.
2019.04.23 07:41:39 5: my_unifi_controller (Unifi_GetHealth_Receive) - state:'ok'
2019.04.23 07:41:39 5: my_unifi_controller (Unifi_GetAccesspoints_Send) - executed.
2019.04.23 07:41:40 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - executed.
2019.04.23 07:41:40 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2019.04.23 07:41:40 5: my_unifi_controller (Unifi_ProcessUpdate) - executed after 0.9865 seconds.
2019.04.23 07:41:40 5: my_unifi_controller (Unifi_SetHealthReadings) - executed.
2019.04.23 07:41:40 5: my_unifi_controller (Unifi_SetClientReadings) - executed.
2019.04.23 07:41:40 5: my_unifi_controller (Unifi_SetAccesspointReadings) - executed.
2019.04.23 07:41:40 5: my_unifi_controller (Unifi_SetWlanReadings) - executed.
2019.04.23 07:41:40 5: my_unifi_controller (Unifi_SetVoucherReadings) - executed.
2019.04.23 07:41:40 5: my_unifi_controller (Unifi_ProcessUpdate) - finished after 1.2373 seconds.
2019.04.23 07:42:10 5: my_unifi_controller (Unifi_DoUpdate) - executed.
2019.04.23 07:42:10 5: my_unifi_controller (Unifi_GetClients_Send) - executed.
2019.04.23 07:42:10 5: my_unifi_controller (Unifi_GetClients_Receive) - executed.
2019.04.23 07:42:10 5: my_unifi_controller (Unifi_GetClients_Receive) - state:'ok'
2019.04.23 07:42:10 5: my_unifi_controller (Unifi_GetClients_Receive) - data: HASH(0x9b39f38)
2019.04.23 07:42:10 5: my_unifi_controller (Unifi_GetHealth_Send) - executed.
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_GetHealth_Receive) - executed.
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_GetHealth_Receive) - state:'ok'
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_GetAccesspoints_Send) - executed.
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - executed.
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_GetWlans_Send) - executed.
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_GetWlans_Receive) - executed.
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_GetWlans_Receive) - state:'ok'
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_GetEvents_Send) - executed.
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_GetEvents_Receive) - executed.
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_GetEvents_Receive) - state:'ok'
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_GetVoucherList_Send) - executed.
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - executed.
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - state:'ok'
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_ProcessUpdate) - executed after 1.1889 seconds.
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_SetHealthReadings) - executed.
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_SetClientReadings) - executed.
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_SetAccesspointReadings) - executed.
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_SetWlanReadings) - executed.
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_SetVoucherReadings) - executed.
2019.04.23 07:42:11 5: my_unifi_controller (Unifi_ProcessUpdate) - finished after 1.1895 seconds.
2019.04.23 07:42:41 5: my_unifi_controller (Unifi_DoUpdate) - executed.
2019.04.23 07:42:41 5: my_unifi_controller (Unifi_GetAccesspoints_Send) - executed.
2019.04.23 07:42:41 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - executed.
2019.04.23 07:42:41 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2019.04.23 07:42:41 5: my_unifi_controller (Unifi_GetClients_Send) - executed.
2019.04.23 07:42:41 5: my_unifi_controller (Unifi_GetClients_Receive) - executed.
2019.04.23 07:42:41 5: my_unifi_controller (Unifi_GetClients_Receive) - state:'ok'
2019.04.23 07:42:41 5: my_unifi_controller (Unifi_GetClients_Receive) - data: HASH(0x9edf458)
2019.04.23 07:42:41 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2019.04.23 07:42:41 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2019.04.23 07:42:41 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2019.04.23 07:42:41 5: my_unifi_controller (Unifi_GetHealth_Send) - executed.
2019.04.23 07:42:42 5: my_unifi_controller (Unifi_GetHealth_Receive) - executed.
2019.04.23 07:42:42 5: my_unifi_controller (Unifi_GetHealth_Receive) - state:'ok'
2019.04.23 07:42:42 5: my_unifi_controller (Unifi_GetVoucherList_Send) - executed.
2019.04.23 07:42:42 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - executed.
2019.04.23 07:42:42 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - state:'ok'
2019.04.23 07:42:42 5: my_unifi_controller (Unifi_GetEvents_Send) - executed.
2019.04.23 07:42:42 5: my_unifi_controller (Unifi_GetEvents_Receive) - executed.
2019.04.23 07:42:42 5: my_unifi_controller (Unifi_GetEvents_Receive) - state:'ok'
2019.04.23 07:42:42 5: my_unifi_controller (Unifi_GetWlans_Send) - executed.
2019.04.23 07:42:42 5: my_unifi_controller (Unifi_GetWlans_Receive) - executed.
2019.04.23 07:42:42 5: my_unifi_controller (Unifi_GetWlans_Receive) - state:'ok'
2019.04.23 07:42:42 5: my_unifi_controller (Unifi_ProcessUpdate) - executed after 0.5765 seconds.
2019.04.23 07:42:42 5: my_unifi_controller (Unifi_SetHealthReadings) - executed.
2019.04.23 07:42:42 5: my_unifi_controller (Unifi_SetClientReadings) - executed.
2019.04.23 07:42:42 5: my_unifi_controller (Unifi_SetAccesspointReadings) - executed.
2019.04.23 07:42:42 5: my_unifi_controller (Unifi_SetWlanReadings) - executed.
2019.04.23 07:42:42 5: my_unifi_controller (Unifi_SetVoucherReadings) - executed.
2019.04.23 07:42:42 5: my_unifi_controller (Unifi_ProcessUpdate) - finished after 0.5769 seconds.
LG
Holger
Da war ich etwas zu schnell ::)
Die Zeile muss weiter nach oben. Direkt hinter die Logausgabe aus Zeile 3, vor if ($err ne "") {
macht nichts...
Die Zeit habe ich genutzt, um FHEM und den Unifi-Controller auf die aktuellsten Versionen zu aktualisieren (waren allerdings bereits zuvor "nur" ca. 2 - 3 Wochen alt).
2019.04.23 08:44:02 5: my_unifi_controller (Unifi_Notify) - executed.
2019.04.23 08:44:02 5: my_unifi_controller: get called with ?.
2019.04.23 08:44:31 5: my_unifi_controller (Unifi_DoUpdate) - executed.
2019.04.23 08:44:31 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2019.04.23 08:44:31 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2019.04.23 08:44:31 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2019.04.23 08:44:31 5: my_unifi_controller (Unifi_GetHealth_Send) - executed.
2019.04.23 08:44:31 5: my_unifi_controller (Unifi_GetHealth_Receive) - executed.
2019.04.23 08:44:31 5: my_unifi_controller (Unifi_GetHealth_Receive) - state:'ok'
2019.04.23 08:44:31 5: my_unifi_controller (Unifi_GetAccesspoints_Send) - executed.
2019.04.23 08:44:32 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - executed.
2019.04.23 08:44:32 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2019.04.23 08:44:32 5: my_unifi_controller (Unifi_GetClients_Send) - executed.
2019.04.23 08:44:32 5: my_unifi_controller (Unifi_GetClients_Receive) - executed.
2019.04.23 08:44:32 5: my_unifi_controller (Unifi_GetClients_Receive) - data: {"meta":{"rc":"ok"},"data":[]}
2019.04.23 08:44:32 5: my_unifi_controller (Unifi_GetClients_Receive) - state:'ok'
2019.04.23 08:44:32 5: my_unifi_controller (Unifi_GetWlans_Send) - executed.
2019.04.23 08:44:32 5: my_unifi_controller (Unifi_GetWlans_Receive) - executed.
2019.04.23 08:44:32 5: my_unifi_controller (Unifi_GetWlans_Receive) - state:'ok'
2019.04.23 08:44:32 5: my_unifi_controller (Unifi_GetVoucherList_Send) - executed.
2019.04.23 08:44:32 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - executed.
2019.04.23 08:44:32 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - state:'ok'
2019.04.23 08:44:32 5: my_unifi_controller (Unifi_GetEvents_Send) - executed.
2019.04.23 08:44:32 5: my_unifi_controller (Unifi_GetEvents_Receive) - executed.
2019.04.23 08:44:32 5: my_unifi_controller (Unifi_GetEvents_Receive) - state:'ok'
2019.04.23 08:44:32 5: my_unifi_controller (Unifi_ProcessUpdate) - executed after 0.7572 seconds.
2019.04.23 08:44:32 5: my_unifi_controller (Unifi_SetHealthReadings) - executed.
2019.04.23 08:44:32 5: my_unifi_controller (Unifi_SetClientReadings) - executed.
2019.04.23 08:44:32 5: my_unifi_controller (Unifi_SetAccesspointReadings) - executed.
2019.04.23 08:44:32 5: my_unifi_controller (Unifi_SetWlanReadings) - executed.
2019.04.23 08:44:32 5: my_unifi_controller (Unifi_SetVoucherReadings) - executed.
2019.04.23 08:44:32 5: my_unifi_controller (Unifi_ProcessUpdate) - finished after 0.7577 seconds.
2019.04.23 08:45:02 5: my_unifi_controller (Unifi_DoUpdate) - executed.
2019.04.23 08:45:02 5: my_unifi_controller (Unifi_GetWlans_Send) - executed.
2019.04.23 08:45:02 5: my_unifi_controller (Unifi_GetWlans_Receive) - executed.
2019.04.23 08:45:02 5: my_unifi_controller (Unifi_GetWlans_Receive) - state:'ok'
2019.04.23 08:45:02 5: my_unifi_controller (Unifi_GetClients_Send) - executed.
2019.04.23 08:45:02 5: my_unifi_controller (Unifi_GetClients_Receive) - executed.
2019.04.23 08:45:02 5: my_unifi_controller (Unifi_GetClients_Receive) - data: {"meta":{"rc":"ok"},"data":[]}
2019.04.23 08:45:02 5: my_unifi_controller (Unifi_GetClients_Receive) - state:'ok'
2019.04.23 08:45:02 5: my_unifi_controller (Unifi_GetAccesspoints_Send) - executed.
2019.04.23 08:45:02 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - executed.
2019.04.23 08:45:02 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2019.04.23 08:45:02 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2019.04.23 08:45:02 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2019.04.23 08:45:02 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2019.04.23 08:45:02 5: my_unifi_controller (Unifi_GetHealth_Send) - executed.
2019.04.23 08:45:02 5: my_unifi_controller (Unifi_GetHealth_Receive) - executed.
2019.04.23 08:45:02 5: my_unifi_controller (Unifi_GetHealth_Receive) - state:'ok'
2019.04.23 08:45:02 5: my_unifi_controller (Unifi_GetEvents_Send) - executed.
2019.04.23 08:45:03 5: my_unifi_controller (Unifi_GetEvents_Receive) - executed.
2019.04.23 08:45:03 5: my_unifi_controller (Unifi_GetEvents_Receive) - state:'ok'
2019.04.23 08:45:03 5: my_unifi_controller (Unifi_GetVoucherList_Send) - executed.
2019.04.23 08:45:03 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - executed.
2019.04.23 08:45:03 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - state:'ok'
2019.04.23 08:45:03 5: my_unifi_controller (Unifi_ProcessUpdate) - executed after 0.8401 seconds.
2019.04.23 08:45:03 5: my_unifi_controller (Unifi_SetHealthReadings) - executed.
2019.04.23 08:45:03 5: my_unifi_controller (Unifi_SetClientReadings) - executed.
2019.04.23 08:45:03 5: my_unifi_controller (Unifi_SetAccesspointReadings) - executed.
2019.04.23 08:45:03 5: my_unifi_controller (Unifi_SetWlanReadings) - executed.
2019.04.23 08:45:03 5: my_unifi_controller (Unifi_SetVoucherReadings) - executed.
2019.04.23 08:45:03 5: my_unifi_controller (Unifi_ProcessUpdate) - finished after 0.8405 seconds.
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_DoUpdate) - executed.
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_GetWlans_Send) - executed.
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_GetWlans_Receive) - executed.
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_GetWlans_Receive) - state:'ok'
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_GetAccesspoints_Send) - executed.
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - executed.
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_GetClients_Send) - executed.
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_GetClients_Receive) - executed.
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_GetClients_Receive) - data: {"meta":{"rc":"ok"},"data":[]}
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_GetClients_Receive) - state:'ok'
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_GetHealth_Send) - executed.
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_GetHealth_Receive) - executed.
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_GetHealth_Receive) - state:'ok'
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_GetEvents_Send) - executed.
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_GetEvents_Receive) - executed.
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_GetEvents_Receive) - state:'ok'
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_GetVoucherList_Send) - executed.
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - executed.
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - state:'ok'
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_ProcessUpdate) - executed after 0.4503 seconds.
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_SetHealthReadings) - executed.
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_SetClientReadings) - executed.
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_SetAccesspointReadings) - executed.
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_SetWlanReadings) - executed.
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_SetVoucherReadings) - executed.
2019.04.23 08:45:33 5: my_unifi_controller (Unifi_ProcessUpdate) - finished after 0.4506 seconds.
2019.04.23 08:46:03 5: my_unifi_controller (Unifi_DoUpdate) - executed.
2019.04.23 08:46:03 5: my_unifi_controller (Unifi_GetClients_Send) - executed.
2019.04.23 08:46:03 5: my_unifi_controller (Unifi_GetClients_Receive) - executed.
2019.04.23 08:46:03 5: my_unifi_controller (Unifi_GetClients_Receive) - data: {"meta":{"rc":"ok"},"data":[]}
2019.04.23 08:46:03 5: my_unifi_controller (Unifi_GetClients_Receive) - state:'ok'
2019.04.23 08:46:03 5: my_unifi_controller (Unifi_GetAccesspoints_Send) - executed.
2019.04.23 08:46:03 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - executed.
2019.04.23 08:46:03 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2019.04.23 08:46:03 5: my_unifi_controller (Unifi_GetWlans_Send) - executed.
2019.04.23 08:46:03 5: my_unifi_controller (Unifi_GetWlans_Receive) - executed.
2019.04.23 08:46:03 5: my_unifi_controller (Unifi_GetWlans_Receive) - state:'ok'
2019.04.23 08:46:03 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2019.04.23 08:46:04 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2019.04.23 08:46:04 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2019.04.23 08:46:04 5: my_unifi_controller (Unifi_GetHealth_Send) - executed.
2019.04.23 08:46:04 5: my_unifi_controller (Unifi_GetHealth_Receive) - executed.
2019.04.23 08:46:04 5: my_unifi_controller (Unifi_GetHealth_Receive) - state:'ok'
2019.04.23 08:46:04 5: my_unifi_controller (Unifi_GetEvents_Send) - executed.
2019.04.23 08:46:04 5: my_unifi_controller (Unifi_GetEvents_Receive) - executed.
2019.04.23 08:46:04 5: my_unifi_controller (Unifi_GetEvents_Receive) - state:'ok'
2019.04.23 08:46:04 5: my_unifi_controller (Unifi_GetVoucherList_Send) - executed.
2019.04.23 08:46:04 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - executed.
2019.04.23 08:46:04 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - state:'ok'
2019.04.23 08:46:04 5: my_unifi_controller (Unifi_ProcessUpdate) - executed after 0.7607 seconds.
2019.04.23 08:46:04 5: my_unifi_controller (Unifi_SetHealthReadings) - executed.
2019.04.23 08:46:04 5: my_unifi_controller (Unifi_SetClientReadings) - executed.
2019.04.23 08:46:04 5: my_unifi_controller (Unifi_SetAccesspointReadings) - executed.
2019.04.23 08:46:04 5: my_unifi_controller (Unifi_SetWlanReadings) - executed.
2019.04.23 08:46:04 5: my_unifi_controller (Unifi_SetVoucherReadings) - executed.
2019.04.23 08:46:04 5: my_unifi_controller (Unifi_ProcessUpdate) - finished after 0.7612 seconds.
2019.04.23 08:46:34 5: my_unifi_controller (Unifi_DoUpdate) - executed.
2019.04.23 08:46:34 5: my_unifi_controller (Unifi_GetVoucherList_Send) - executed.
2019.04.23 08:46:34 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - executed.
2019.04.23 08:46:34 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - state:'ok'
2019.04.23 08:46:34 5: my_unifi_controller (Unifi_GetEvents_Send) - executed.
2019.04.23 08:46:34 5: my_unifi_controller (Unifi_GetEvents_Receive) - executed.
2019.04.23 08:46:34 5: my_unifi_controller (Unifi_GetEvents_Receive) - state:'ok'
2019.04.23 08:46:34 5: my_unifi_controller (Unifi_GetHealth_Send) - executed.
2019.04.23 08:46:35 5: my_unifi_controller (Unifi_GetHealth_Receive) - executed.
2019.04.23 08:46:35 5: my_unifi_controller (Unifi_GetHealth_Receive) - state:'ok'
2019.04.23 08:46:35 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2019.04.23 08:46:35 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2019.04.23 08:46:35 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2019.04.23 08:46:35 5: my_unifi_controller (Unifi_GetWlans_Send) - executed.
2019.04.23 08:46:35 5: my_unifi_controller (Unifi_GetWlans_Receive) - executed.
2019.04.23 08:46:35 5: my_unifi_controller (Unifi_GetWlans_Receive) - state:'ok'
2019.04.23 08:46:35 5: my_unifi_controller (Unifi_GetClients_Send) - executed.
2019.04.23 08:46:35 5: my_unifi_controller (Unifi_GetClients_Receive) - executed.
2019.04.23 08:46:35 5: my_unifi_controller (Unifi_GetClients_Receive) - data: {"meta":{"rc":"ok"},"data":[]}
2019.04.23 08:46:35 5: my_unifi_controller (Unifi_GetClients_Receive) - state:'ok'
2019.04.23 08:46:35 5: my_unifi_controller (Unifi_GetAccesspoints_Send) - executed.
2019.04.23 08:46:35 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - executed.
2019.04.23 08:46:35 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2019.04.23 08:46:35 5: my_unifi_controller (Unifi_ProcessUpdate) - executed after 1.3969 seconds.
2019.04.23 08:46:35 5: my_unifi_controller (Unifi_SetHealthReadings) - executed.
2019.04.23 08:46:35 5: my_unifi_controller (Unifi_SetClientReadings) - executed.
2019.04.23 08:46:35 5: my_unifi_controller (Unifi_SetAccesspointReadings) - executed.
2019.04.23 08:46:35 5: my_unifi_controller (Unifi_SetWlanReadings) - executed.
2019.04.23 08:46:35 5: my_unifi_controller (Unifi_SetVoucherReadings) - executed.
2019.04.23 08:46:35 5: my_unifi_controller (Unifi_ProcessUpdate) - finished after 1.4298 seconds.
2019.04.23 08:47:05 5: my_unifi_controller (Unifi_DoUpdate) - executed.
2019.04.23 08:47:05 5: my_unifi_controller (Unifi_GetVoucherList_Send) - executed.
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - executed.
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - state:'ok'
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_GetEvents_Send) - executed.
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_GetEvents_Receive) - executed.
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_GetEvents_Receive) - state:'ok'
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_GetHealth_Send) - executed.
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_GetHealth_Receive) - executed.
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_GetHealth_Receive) - state:'ok'
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_GetWlans_Send) - executed.
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_GetWlans_Receive) - executed.
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_GetWlans_Receive) - state:'ok'
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_GetAccesspoints_Send) - executed.
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - executed.
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_GetClients_Send) - executed.
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_GetClients_Receive) - executed.
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_GetClients_Receive) - data: {"meta":{"rc":"ok"},"data":[]}
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_GetClients_Receive) - state:'ok'
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_ProcessUpdate) - executed after 1.0182 seconds.
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_SetHealthReadings) - executed.
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_SetClientReadings) - executed.
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_SetAccesspointReadings) - executed.
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_SetWlanReadings) - executed.
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_SetVoucherReadings) - executed.
2019.04.23 08:47:06 5: my_unifi_controller (Unifi_ProcessUpdate) - finished after 1.0186 seconds.
2019.04.23 08:47:36 5: my_unifi_controller (Unifi_DoUpdate) - executed.
2019.04.23 08:47:36 5: my_unifi_controller (Unifi_GetWlans_Send) - executed.
2019.04.23 08:47:36 5: my_unifi_controller (Unifi_GetWlans_Receive) - executed.
2019.04.23 08:47:36 5: my_unifi_controller (Unifi_GetWlans_Receive) - state:'ok'
2019.04.23 08:47:36 5: my_unifi_controller (Unifi_GetAccesspoints_Send) - executed.
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - executed.
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_GetAccesspoints_Receive) - state:'ok'
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_GetClients_Send) - executed.
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_GetClients_Receive) - executed.
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_GetClients_Receive) - data: {"meta":{"rc":"ok"},"data":[]}
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_GetClients_Receive) - state:'ok'
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_GetHealth_Send) - executed.
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_GetHealth_Receive) - executed.
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_GetHealth_Receive) - state:'ok'
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Send) - executed.
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - executed.
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_GetEvents_Send) - executed.
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_GetEvents_Receive) - executed.
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_GetEvents_Receive) - state:'ok'
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_GetVoucherList_Send) - executed.
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - executed.
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_GetVoucherList_Receive) - state:'ok'
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_ProcessUpdate) - executed after 0.7797 seconds.
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_SetHealthReadings) - executed.
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_SetClientReadings) - executed.
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_SetAccesspointReadings) - executed.
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_SetWlanReadings) - executed.
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_SetVoucherReadings) - executed.
2019.04.23 08:47:37 5: my_unifi_controller (Unifi_ProcessUpdate) - finished after 0.7803 seconds.
Das Ergebnis habe ich zwar geahnt aber eigentlich nicht erwartet. In data sollten alle Informationen zu deinen Clients enthalten sein. Aber dein UnifiController sendet keinen einzigen Client mit. Hast du wenn du dich direkt anmeldest (selber user wie im Unifi-Modul) irgendwelche Clients/Endgeräte?
Schau ansonsten mal ins server.log des Unifi-Controllers.
Mein Unifi Controller zeigt mir alle Daten an (gleicher User), so wie früher auch.
Mein Server-Log ist voll mit normalen Meldungen - keine Hinweise auf Probleme.
Aber:
Wenn ich eine 2. Verbindung zum Controller aufmache (weiterer Tab in Chrome oder parallel mit Firefox), kommt die Verbindung als solches zwar zustande - entsprechend dem "connected" in FHEM.
Ich bekomme in dieser Verbindung (Chrome / Firefox) aber keine Daten (Geräte / Clients / Maps) angezeigt.
Aktuell habe ich den Controller 5.10.21, davor den 5.10.20. Hat es evtl. mit der Version zu tun?
5.10.20 habe ich auch und funktioniert. Ist ein guter Test von dir gewesen. Schön, dass das Problem auch ohne fhem reproduziert werden kann. Damit könntest du auch mal direkt im Ubiquity-Forum suchen oder nachfragen.
Könnte irgendeine Sicherheitseinstellung im Controller sein. Habe auf die Schnelle aber dort nichts passendes gefunden.
Ist bereits erfolgt aber leider sind die dort nicht so schnell wie du.
@omega: hast du mal einen eigenen user für fhem angelegt? Vielleicht geht es mit unterschiedlichen Accounts.
Zitat von: Maui am 15 April 2019, 19:09:31
Jetzt weiß ich woran es lag. Hab ein Update vom Controller selbst gemacht.
Ich muss das doch nochmal hoch holen. Kann es sein, dass die disconnected-Devices ein Neustart von FHEM nicht "überleben", also danach nicht mehr aktualisiert werden was last-seen angeht?
Gruß
Maui
Das wird so sein. Habe ich bei der Entwicklung des Modul UnifiClient gerade gelernt. Nur Readings werden automatisch gespeichert und beim Neustart wieder hergestellt. Aber ich könnte mich in den Neustartprozess einklinken und versuchen Teile der Internals aus den vorhandenen Readings wiederherzustellen. Geht aber nur, wenn die ID als Reading vorhanden ist. Vielleicht gibt es aber auch noch andere Möglichkeiten, die mir bisher nicht bekannt sind.
Alternativ könnte man auch auf last_seen schauen oder?
Dann muss man noch rechnen, also jetzt-last_seen und dann die Max Sekunden definieren.
Könnte man das nicht auch intern im Modul machen, also beim Update das berechnen?
Dann müsste es doch einen Neustart überleben. Zumindest wenn man last_seen als Reading gesetzt hat.
Gruß
Maui
Denke das bekomme ich über versteckte Readings, (beginnen mit einem .) hin. Darin kann ich mir die ID speichern und bei einem Neustart die disconnected clients zumindest teilweise wiederherstellen. Mache ich, wenn ich die notify-Methode eines Moduls, die auch beim Neustart durchlaufen wird, noch ein wenig besser verstanden habe und eine erste Version des UnifiClient-Moduls eingecheckt habe.
Edit: Wäre gut, etwas mehr Feedback zum UnifiClient-Modul zu bekommen. Dann kann es damit schneller voran gehen
@Maui: habe dir ein Unifi-Modul im ersten Post des Threads zum UnifiClient (https://forum.fhem.de/index.php/topic,99864.msg932489.html#msg932489) angehängt, das beim Neustart von fhem versucht aus den Readings die clients wiederherzustellen. Beschreibung siehe commandref zum Attribut customClientReadings.
Bitte Feedback (auch zur commandref)
Hallo,
ich habe meinen Usernamen und Passwort geändert, wie kann ich das jetzt auch in fhem ändern ?
Danke
speed
schon mal versucht im Modul unter DEF nach der IP Benutzernamen und Password einzugeben?
Zitat von: Wuehler am 28 April 2019, 22:27:34
@Maui: habe dir ein Unifi-Modul im ersten Post des Threads zum UnifiClient (https://forum.fhem.de/index.php/topic,99864.msg932489.html#msg932489) angehängt, das beim Neustart von fhem versucht aus den Readings die clients wiederherzustellen. Beschreibung siehe commandref zum Attribut customClientReadings.
Bitte Feedback (auch zur commandref)
Moin bin jetzt erst dazu gekommen. Funktioniert Danke. Commandref liest sich auch gut.
Ich persönlich würde allerdings das last_seen als Zwang intern dann setzen, also möchte jemand ein formatiertes Reading, so kauft er das andere mit dazu (und sei es als verstecktes Reading)
Gruß
Maui
Moin Wuehler,
Ich sehe grad im Log, dass in der Version schon UniFi Client mit verheiratet ist.
Führt bei mir im Log zu dauerhaften Meldungen "Cannot autoload UnifiClient"
Ich werd jetzt mal eh den Client probieren aber wäre blöd wen das so in die reguläre Version kommt.
Hi Maui,
deshalb hatte ich es im UnifiClient-Thread hochgeladen. Die drei Dateien dort muss man alle einspielen (ausser du hast keinen UnifiSwitch). Wenn man einen UnifiClient einrichtet kann ich auch alle Readings wiederherstellen für disconnected Clients, ist aber aktuell noch nicht umgesetzt. Um dann allerdings einmalige Besucher aufzuräumen müsste ich für UnifiClients noch ein autocreate implementieren und ggf. ein Attribut im Unifi-Modul, dass die UnifiClients nach einer bestimmten Zeit (zB last_seen > 2 Wochen) wieder aufräumt.
VG,
Dirk
Hallo,
ist es möglich auf einem Switch ein Port zu disablen und wieder enablen?
Hintergrund ist mein Onkyo Receiver hat einen Netzwerk Bug der von Onkyo noch oder nie behoben wird. Er ist manchmal einfach nicht erreichbar bisher habe ich ihn ausgeschaltet angeschaltet. Aber es reicht auch den Port disablen enablen(ist natürlich einfacher und nicht für andere störend).
Desweiteren ist mir aufgefallen wenn man über das Modul ein restart einen Devices macht im Controller nicht restart steht sondern getrennt.
Moin,
Rein theoretisch sollte das disablen eines ports eines Switches möglich sein. Rein praktisch ist es im Modul nicht implementiert.
Reicht evtl. auch ein disconnect client?
Aus Sicht des Moduls ist das Gerät beim restart disconnected, da keine Daten mehr ankommen.Restart ist im Grunde nur eine genauere Beschreibung von disconnected
VG,
Dirk
Zitat von: Wuehler am 16 Mai 2019, 17:35:19
Moin,
Rein theoretisch sollte das disablen eines ports eines Switches möglich sein. Rein praktisch ist es im Modul nicht implementiert.
Reicht evtl. auch ein disconnect client?
VG,
Dirk
Hi Dirk,
der Port darf dann kein Link haben. Ich denke bei einem Disconnect wird nur einmal die Verbindung kurz getrennt. Ist disconnect Client bei LAN überhaupt möglich? habe die Möglichkeit bei LAN Clients im Controller nicht gefunden.
Stimmt. Hatte ich nicht dran gedacht. Dann vielleicht block/unblock? Das geht mit der Beta-Version aus dem Thread zum UnifiClient dann auch sicherer als mit der aktuell offiziell verteilten Version.
Zitat von: Wuehler am 16 Mai 2019, 18:07:33
Stimmt. Hatte ich nicht dran gedacht. Dann vielleicht block/unblock? Das geht mit der Beta-Version aus dem Thread zum UnifiClient dann auch sicherer als mit der aktuell offiziell verteilten Version.
Wenn der Fehler wieder auftritt ist ja nur sporadisch :( Teste ich das mal über den Controller und wenn es funktioniert baue ich die Beta version ein. Melde mich dann wieder
Danke für deine schnelle Reaktion
Hallo zusammen,
folgende Änderungen habe ich gerade commited, sie sollten morgen im Update enthalten sein:
- Das Modul erzeugt sich nach einem fhem-Neustart aus den bestehenden Readings die coient-Informationen. Damit werden dann auch für disconnected clients weiterhin readings geupdated.
- Ein neuer setter removeClientReadings, um clients dann auch endgültig entfernen zu können.
- Ein neuer setter refreshUserGroups: Dieser wird für UnifiClients benötigt.
- neues Modul UnifiClient in einer BETA-Version.
- Thread dazu: Anregungen/Anmerkungen/Feedback zum Modul UnifiClient (https://forum.fhem.de/index.php/topic,99864.0.html).
- Einen UnifiClient muss man sich von Hand anlegen: define <name> UnifiClient <clientName in Unifi-Modul>
- Es werden dort alle Informationen zum client als Readings angezeigt, die das UnifiModul vom Unifi-Controller aktuell bekommen kann.
- Zusätzliche erst in FHEM erzeugte Werte haben das prefix fhem_
- Es wird die tägliche Onlinezeit des Clients berechnet. Sinnvolle Werte gibt es allerdings nur, wenn man das Update-Interval des Unifi-Moduls nicht deutlich hoch gesetzt hat.
- Wichtig dabei kann das Attribut thresholdBytesPerMinute sein. Es gibt an, wieviel bytes pro Minute frei sind und damit nicht zur Onlinezeit hinzugerechnet werden.
- Wenn das Attribut maxOnlineMinutesPerDay gesetzt ist wird der client bei Überschreiten der Onlinezeit geblockt. Um Mitternacht wird der client wieder unblocked. Nachteil: Es findet eine Provisionierung statt.
- Wenn das Attibut blockingUsergroup gesetzt ist, wird der client nicht geblocked, sondern in die angegebene usergroup (sollte man mit sehr geringen max_up/down-Werten versehen) verschoben. Vorteil: Es findet keine Provisionierung statt.
Einen schönen Sonntag,
Dirk
Moin Dirk,
Brauche ich dann noch beide custom Readings für die offline seit Meldung?
Gruß
Maui
Wenn du dir einen UnifiClient anlegst brauchst du im UnifiModul ggf. keine customReadings mehr.
Edit: Bin mir aber nicht sicher, ob ich verstanden habe, was du genau meinst.
hat sich zufällig etwas verändert in sachen Online/Offline ? Hab eine anwesenheitserkennung und seit ein paar Tagen ist diese echt "lahm" geworden ;) Stehe manchmal 1 Minute vor der Türe bis meine Alarmanlage aus geht :P
Und hat der unifi Controler eine Option das er nur verbindungen von Localhost zulässt ? Habe ein 2. Docker mit ner MACVLAN und Probleme auf unifi zu kommen obwohl es pingbar ist
Nein, keine Änderung am online/offline. Schau mal, in wieweit deine Rechner ausgelastet sind. Und welches Update-Intervall hast du im Unifi-Modul gesetzt (im DEF)?
Die Frage zum localhost kann ich nicht beantworten, da ich dein Problem noch nicht verstehe.
oh hab ein Update gemacht nu ist mein og total voll mit ganz viel Zeugs von meinen ganzen Netzwerkgeräten die damit verbunden sind d.. Leider is das Log nu schon so voll und groß ich bekomm nichts mehr Kopiert :(
Achso Ausgelastet ist es nicht Zeit steht auf : 05 ...
Frisches Log hier ein Teil was da aktuell alels im Logfile vom FHEM landet :
019.05.20 13:34:21.728 3: myunifi_pro (UnifiClient_Parse) - return: UNDEFINED UnifiClient_sonoffpowheizungpumpen-0957 UnifiClient sonoffpowheizungpumpen-0957
2019.05.20 13:34:21.735 3: myunifi_pro: Unknown code UnifiClient_sonoffpowheizungpumpen-0957{"ip":"192.168.2.62","tx_power":28,"_f_last_seen":"2019-05-20 13:34:05","hostname":"sonoffpowheizungpumpen-0957","idletime":0,"rx_rate":6000,"qos_policy_applied":true,"_uptime_by_uap":129519,"signal":-75,"satisfaction":87,"site_id":"5a26de95e76a5bb2daf04648","fhem_clientName":"sonoffpowheizungpumpen-0957","_last_seen_by_uap":1558352045,"uptime":129519,"blocked":false,"_id":"5bdaf130cc7b4b14fc54fa14","tx_bytes-r":167,"oui":"Espressi","bssid":"f0:9f:c2:2a:1f:2e","_f_latest_assoc_time":"2019-05-19 01:35:37","powersave_enabled":false,"tx_rate":39000,"_f_uptime_by_uap":"1d 11h 58m.............
Zitat von: TNT0068 am 16 Mai 2019, 18:16:35
Wenn der Fehler wieder auftritt ist ja nur sporadisch :( Teste ich das mal über den Controller und wenn es funktioniert baue ich die Beta version ein. Melde mich dann wieder
Danke für deine schnelle Reaktion
Fehler ist wieder aufgetreten leider hilft das Blocking nicht :(
@ChrisW: ich vermute, du hast das Attribut verbose auf 3 in deinem myunifi_pro-Device. Dann kommen diese Meldungen im Log.
Nein habe ich nicht ddas ist jetzt nach dem Update gekommen hmm. Hab nun verbose auf 2 und es ist weg. Aber hab gedacht es wäre wichtig ;) Aber okay unterdrücke ich es.
Das Interval mit 05 ist auch richtig und funktioniert ? Ich will ja eine möglichst schnelle erkennung haben.
Das mit den Logausgaben schaue ich mir in Ruhe nochmal an.
Ein Intervall von 5 bedeutet, dass alle 5 Sekunden alle Daten vom Unifi-Controller abgeholt werden. Das scheint mir zu gering, kann sein, dass nach 5 Sekunden noch nicht alle Antworten verarbeitet wurden und schon wieder erneut alles abgefragt wird. Was sagen den die Prozessorauslastungen deiner fhem und deiner Unifi-Umgebung dazu?
Wenn du in so kurzer Zeit eine Anwesenheitserkennung möchtest, solltest du das zB mit einem Bewegungssensor kombinieren, der bei Bewegung set update im UnifiModul auruft. Oder auf die Mail-Notifikation des UnifiControllers zurückgreifen. Dann ohne UnifiModul sondern mit mailcheck-Modul.
hmm ich habe es mal auf 10 Sekunden gesetzt. Vielleicht ist es wirklich zu viel für 5 Sekunden. Sind auch 2-3 Wlan Geräte hinzu gekommen. Das mit dem Mailcheck wäre eine Idee aber ob dies "scheller" funktioniert ?
Ich muss eh mal schauen ob man da nicht auf DHCP Anwesenheits check geht... Da ich unifi Fritzbox und so ein Noname Repeater habe.
Über Ein neues gmx-Konto und Mailcheck wurde bei mir innerhalb von zwei Sekunden ein notify in fhem ausgelöst, dass dann presence getriggert hat.
Da ich aber keinen Bedarf an einer so schnellen Benachrichtigung habe, habe ich es wieder deaktiviert. Um das Device herauszufinden muss man mailcheck um die Anzeige des bodys erweitern. Der Zweizeiler müsste irgendwo hier im Thread oder Mailcheck-Thread stehen. Gab bei anderen Nutzern aber wohl auch schlechtere Zeiten bis zur Benachrichtigung. Bei mir waren es immer unter 2 Sekunden.
Mit dem DHCP-Check auf Fritzbox habe ich keine Erfahrungen.
Hallo zusammen,
ich habe die Loglevel etwas angepasst, so dass es besser zum golbal-default-verbose=3 passt. Kommt morgen im Update.
Außerdem hat der UnifiClient einen neuen setter "update".
-> Meiner Meinung nach kann man dann das Update-Intervall des Unifi-Moduls recht hoch setzen (zB 300 = 5 Minuten) und wenn man nur seine Familien-Handys enger tracken will, diese über ein at zB alle 5-10 Sekunden einzeln updaten lassen. Wenn man mehr Handys trackt macht das vielleicht wieder keinen Sinn. Sollte bei wenigen (kleiner 8 ) Handys aber insgesamt performanter sein.
siehe WIKI (https://wiki.fhem.de/wiki/UnifiClient#Anwesenheitserkennung).
VG,
Dirk
das klingt ja nach einer coolen funktion.
Habe nun im Log in Fhem folgendes gefunden ..
2019.05.21 08:07:40.379 1: PERL WARNING: Argument "2019-05-21 07:39:25" isn't numeric in localtime at ./FHEM/74_Unifi.pm line 1470.
2019.05.21 08:07:40.431 1: PERL WARNING: Argument "1970-01-01 01:32:50" isn't numeric in localtime at ./FHEM/74_Unifi.pm line 1470.
2019.05.21 08:07:40.436 1: PERL WARNING: Argument "2019-05-21 05:53:22" isn't numeric in localtime at ./FHEM/74_Unifi.pm line 1470.
2019.05.21 08:07:40.444 1: PERL WARNING: Argument "2019-05-20 21:53:11" isn't numeric in localtime at ./FHEM/74_Unifi.pm line 1470.
2019.05.21 08:07:40.484 1: PERL WARNING: Argument "2019-05-21 07:04:59" isn't numeric in localtime at ./FHEM/74_Unifi.pm line 1470.
2019.05.21 08:07:40.504 1: PERL WARNING: Argument "2019-05-21 07:10:11" isn't numeric in localtime at ./FHEM/74_Unifi.pm line 1470.
2019.05.21 08:07:40.552 1: PERL WARNING: Argument "2019-05-21 07:19:34" isn't numeric in localtime at ./FHEM/74_Unifi.pm line 1470.
2019.05.21 08:07:40.558 1: PERL WARNING: Argument "2019-05-21 07:31:06" isn't numeric in localtime at ./FHEM/74_Unifi.pm line 1470.
2019.05.21 08:07:40.564 1: PERL WARNING: Argument "2019-05-20 21:35:08" isn't numeric in localtime at ./FHEM/74_Unifi.pm line 1470.
2019.05.21 08:07:40.569 1: PERL WARNING: Argument "2019-05-21 05:36:22" isn't numeric in localtime at ./FHEM/74_Unifi.pm line 1470.
2019.05.21 08:07:40.574 1: PERL WARNING: Argument "2019-05-21 07:05:10" isn't numeric in localtime at ./FHEM/74_Unifi.pm line 1470.
Moin Chris,
Danke für das schnelle Feedback. Kommt die Ausgabe regelmäßig? Oder war das nur nach dem Neustart nach Update?
Wenn regelmäßig: Welche Version des UnifiControllers nutzt du?
VG,
Dirk
hi,
nur beim Neustart. Das Update war heute morgen noch nicht dabei.
Glaube ich habe : 5.10.23
Moin also ich hab die Logausgaben nicht. Update heute morgen.
also das mit dem extra client Update is SUPER :) Glaub das entlastet da sehr viel.
Kann mna im controler noch was Optimieren und Online / Offline schneller zu erkennen ? Gerät ist nun schon paar Minuten weg aber im controler noch immer aktiv
Zitat von: ChrisW am 21 Mai 2019, 11:12:17
Kann mna im controler noch was Optimieren und Online / Offline schneller zu erkennen ? Gerät ist nun schon paar Minuten weg aber im controler noch immer aktiv
Für die schnelle Online-Erkennung kombiniere ich das "connected" event aus UniFi mit dem Modul dash_dhcp (https://fhem.de/commandref.html#dash_dhcp). Das war ursprünglich für Dashbuttons gedacht, kann aber für jeden DHCP-Request in deinem Netz ein Event erzeugen. Und den Request gibt's zuverlässig jedes Mal, wenn sich ein Wifi-Gerät neu anmeldet (ok, jedenfalls wenn du keine statische IP konfiguriert hast). Das ist rattenschnell. Mein Haus hat mich in der Regel erkannt, bevor ich aus dem Auto ausgestiegen bin.
Bei mir sieht ein typisches Presence so aus:
defmod mein_handy PRESENCE event unifi:aa_bb_cc_dd_ee_ff:.disconnected (unifi:aa_bb_cc_dd_ee_ff:.connected|dash_dhcp:aa-bb-cc-dd-ee-ff:.short)
Um "Offline" bzw. "absent" schneller zu erkennen, hilft das natürlich nicht. Das halte ich aber auch nicht für sinnvoll, sondern möchte im Gegenteil lieber eine leichte Verzögerung. Andernfalls geschehen ungewollte Dinge (Haus schaltet alle Lichter und Geräte aus, verrammelt die Türen und macht das Minenfeld scharf) nur weil ein Handy mal für ein paar Sekunden die Verbindung verliert.
Gruß, Uli
@Chris: das offline-gehen dauert im UC immer 3 oder 5 Minuten (bin mir gerade nicht mehr sicher). Da kann das Modul auch nichts anderes raten. Du könntest evtl. aus den noise oder rssi-Readings etwas ableiten. Berücksichtige aber die Anmerkungen von Uli. Man baut sich da sonst schnell etwas, das nicht zur Realität passt.
@f-zappa: gute Idee mit dash_dhcp gür present. Überlege ich mit ins Wiki aufzunehmen.
Vielleicht sollte auch ein kleiner Exkurs über disconnected-Dauern ins Wiki. Und was man in der Realität berücksichtigen sollte. Mal schauen ob mir da was einfällt.
@maui: Danke fürs Feedback zu den Logs. Beruhigt mich. Hatte auch das Gefühl, dass es eher Installationsspezifisch ist. Könnte aber auch mit dem restore der clients aus den Readings beim Neustart zusammenhängen. Schaue ich noch mal drauf.
Ich meine es sind 3 Minuten beim disconnect
nochmal zum unifi also das spinnt nun total bei mir ..
Im controler webinterface Gerät ist da ONLINE
in fhem unifi Disconnected ... Manuall auf UPDATE auch ... und unifi client auch ... Irgendwas spinnt hier mit dem abfragen des unifi controlers nach fhem
Zitat von: f-zappa am 21 Mai 2019, 11:58:32
Für die schnelle Online-Erkennung kombiniere ich das "connected" event aus UniFi mit dem Modul dash_dhcp (https://fhem.de/commandref.html#dash_dhcp). Das war ursprünglich für Dashbuttons gedacht, kann aber für jeden DHCP-Request in deinem Netz ein Event erzeugen. Und den Request gibt's zuverlässig jedes Mal, wenn sich ein Wifi-Gerät neu anmeldet (ok, jedenfalls wenn du keine statische IP konfiguriert hast). Das ist rattenschnell. Mein Haus hat mich in der Regel erkannt, bevor ich aus dem Auto ausgestiegen bin.
Bei mir sieht ein typisches Presence so aus:
defmod mein_handy PRESENCE event unifi:aa_bb_cc_dd_ee_ff:.disconnected (unifi:aa_bb_cc_dd_ee_ff:.connected|dash_dhcp:aa-bb-cc-dd-ee-ff:.short)
Um "Offline" bzw. "absent" schneller zu erkennen, hilft das natürlich nicht. Das halte ich aber auch nicht für sinnvoll, sondern möchte im Gegenteil lieber eine leichte Verzögerung. Andernfalls geschehen ungewollte Dinge (Haus schaltet alle Lichter und Geräte aus, verrammelt die Türen und macht das Minenfeld scharf) nur weil ein Handy mal für ein paar Sekunden die Verbindung verliert.
Gruß, Uli
Danke aber das DHCP ( mit den Buttons damals ) lief schon nicht wiel fhem in einem Host Docker ist .. glaub das macht die Probleme
Wegen den unifi Problemen... vielleicht hab ich das neuste Update noch nicht mitbekommen ? Aktuell sagt er aber nichts zu tun ..
Hi Chris,
Mach mal im Unifi-Modul ein set clear all. Hefolgt von einem update.
Wenn es dann immer noch Probleme gibt brauche ich ein list und Screenshots. An besten in einem eigenen Thread.
VG,
Dirk
Okay ich beobachte es mal und mache sonst was neues auf. Hab gerade kein Handy im WLAN zum testen :)
Mit dem client update check aus dem Wiki. Kann man das verhindert das er alle X sekunden dann immer den selben Status setzt ? Es würde ja nur bei änderungen reichen. So sehe ich z.b nicht WANN Disconnect gesetzt wird ( Uhrzeit )
Edit: hab mal neuen Post gemacht mit meinem Problem
Hallo,
Habe gerade ein update gemacht und nun bekomme ich vom Unifi Modul leider folgende Fehlermeldungen im Log:
2019.05.22 13:46:59 3: Unifi: Unknown code UnifiClient_TomiPad{"is_11r":false,"authorized":true,"tx_rate":866700,"_f_last_seen_duration":"0d 0h 0m 5s","_is_guest_by_uap":false,"ap_mac":"fc:ec:da:89:c6:24","sw_mac":"fc:ec:da:7f:5e:c9","hostname":"TomiPad","_f_usergroup_name":"Default","anomalies":0,"_id":"5c01123f67cc280865f726d8","_f_first_seen":"2018-11-09 17:35:59","bssid":"fe:ec:da:8b:c6:24","radio_name":"wifi1","oui":"Apple","tx_power":34,"vlan":0,"_f_latest_assoc_time":"2019-05-22 13:38:48","_f_last_seen":"2019-05-22 13:46:54","noted":true,"radio":"na","sw_depth":-1,"first_seen":1541781359,"_last_seen_by_uap":1558525614,"essid":"TommyNet5G","network_id":"5c01123f67cc280865f72699","_f_uptime_by_usw":"0d 0h 8m 0s","_uptime_by_uap":266943,"radio_proto":"ac","qos_policy_applied":true,"signal":-68,"_uptime_by_usw":480,"channel":36,"is_guest":false,"ccq":333,"is_wired":false,"tx_bytes-r":0,"rx_bytes":720078731,"use_fixedip":false,"_f_last_seen_by_usw":"2019-05-22 13:46:47","_last_seen_by_usw":1558525607,"mac":"4c:56:9d:12:bf:5f","name":"TomiPad","site_id":"5c01123e67cc280865f71994","ip":"192.168.1.135","_f_essid":"TommyNet5G","tx_bytes":12075775033,"satisfaction":100,"rx_packets":5081723,"sw_port":6,"rx_bytes-r":0,"rx_rate":650000,"_f_dhcpend_time":"157d 22h 32m 10s","fixed_ip":"192.168.1.135","_is_guest_by_usw":false,"bytes-r":0,"noise":-106,"roam_count":6,"_f_assoc_time":"117d 13h 32m 9s","dhcpend_time":13645930,"_f_last_seen_by_uap":"2019-05-22 13:46:54","user_id":"5c01123f67cc280865f726d8","note":"","accesspoint":"Unifi-AP-WZ","powersave_enabled":false,"fhem_clientName":"TomiPad","assoc_time":1556458329,"blocked":false,"idletime":69,"tx_packets":6224909,"last_seen":1558525614,"uptime":2067285,"rssi":28,"fhem_state":"connected","_f_uptime":"23d 22h 14m 45s","_f_uptime_by_uap":"3d 2h 9m 3s","latest_assoc_time":1558525128,"usergroup_id":""}, help me!
Ich habe die aktuellste Unifi Controller Software 5.10.23 laufen ... Ideen jemand?
Danke.
Tom
Das ist nicht wichtig kannst dein Verbose abändern. Glaube morgen rüh gibt es ein update
Ok --ich setze das verbose runter ...
Danke.
Hallo zusammen,
Morgen im Update dann noch ein Fix des Loglevels sowie ein Fix beim disconnect von clients, wenn man set update des Moduls UnifiClient nutzen möchte. Da der Test immer so aufwändig/langwierig ist, noch als BETA-Version. Bin mir nicht sicher, an alles 100% gedacht zu haben.
VG,
Dirk
hmm kann es sein das nu das Webinterface vom controller ausgebremst wird ? Komme da kaum drauf per Browser
Was konkret machst du dennn mit fhem?
Intervall de Unifi-Moduls?
Client-Updates per at? Wieviele, wie oft?
Moin
Seit dem letzten Update habe ich nach einem "shutdown restart" folgende Meldungen im Log:
2019.05.24 08:27:05 1: PERL WARNING: Argument "2019-05-24 05:35:07" isn't numeric in localtime at /var/fhem/FHEM/74_Unifi.pm line 1472.
2019.05.24 08:27:05 1: PERL WARNING: Argument "2019-05-24 05:30:00" isn't numeric in localtime at /var/fhem/FHEM/74_Unifi.pm line 1472.
2019.05.24 08:27:05 1: PERL WARNING: Argument "2019-05-24 05:47:13" isn't numeric in localtime at /var/fhem/FHEM/74_Unifi.pm line 1472.
2019.05.24 08:27:05 1: PERL WARNING: Argument "2019-05-23 13:23:44" isn't numeric in localtime at /var/fhem/FHEM/74_Unifi.pm line 1472.
2019.05.24 08:27:05 1: PERL WARNING: Argument "2019-05-23 21:05:18" isn't numeric in localtime at /var/fhem/FHEM/74_Unifi.pm line 1472.
2019.05.24 08:27:05 1: PERL WARNING: Argument "2019-05-24 07:51:52" isn't numeric in localtime at /var/fhem/FHEM/74_Unifi.pm line 1472.
2019.05.24 08:27:05 1: PERL WARNING: Argument "2019-05-24 07:55:25" isn't numeric in localtime at /var/fhem/FHEM/74_Unifi.pm line 1472.
Es ist natürlich kein kritisches Problem aber Bescheid geben wollte ich trotzdem ;-)
Gruß
Daniel
also mein Problem mit dem lahmen Controller war mein fehler IP doppelt vergeben :D
Aktuell scheint es zu laufen.
Nach nem Shutdown restart noch folgendes im Log
2019.05.24 09:07:56.747 1: PERL WARNING: Use of uninitialized value $mac in concatenation (.) or string at ./FHEM/74_Unifi.pm line 1038.
2019.05.24 09:07:56.747 3: eval: {
fhem("set handytanja_unifi update");
fhem("set handychris_unifi update");
}
2019.05.24 09:07:56.748 1: PERL WARNING: Use of uninitialized value $mac in concatenation (.) or string at ./FHEM/74_Unifi.pm line 1043.
2019.05.24 09:07:56.748 3: eval: {
fhem("set handytanja_unifi update");
fhem("set handychris_unifi update");
}
@Maui: Für dich war das restore der clients nach einem Neustart wichtig. Ich habe das wegen der Warnmeldungen im Log angepasst. Leider gehen dabei einmalig die disconnected clients verloren. Für die Zukunft ist die Implementierung des restore allerdings deutlich besser als bisher, da die mac-Adressen der clients den Neustart überleben und ich ein updateClient mit der mac aufrufe.
Die Idee ist mir aufgrund der tieferen Beschäftigung mit udateClient gekommen. Dabei werden auch für disconnectedClients Werte zurückgegeben.
Passt das für dich?
Vg,
Dirk
Moin Dirk,
Ich schaue es mir an aber denke es passt.
Melde mich wenn ich es live getestet habe
Gruß
Maui
Ist noch nicht bereitgestellt. Wenn du es testest gehen deine disconnected clients auch einmalig verloren und Readings werden nicht mehr aktualisiert. Deshalb habe ich die Version auch nicht angehängt.
Frage ist, ob das OK ist, dass einmalig beim Wechsel der Modulversion die disconnected clients wverloren gehen. Danach funktioniert das Ganze wieder sauber.
Ah okay das erklärt warum nach einem Update die disc. Clients noch da sein ;)
Klar hau in die Tasten. Mein Ziel ist es ja eh alte disc. Clients zu entfernen.
Moin
OK, habs eben ins svn commited. Kommt dann morgen ab 8 Uhr per Update.
Änderungen:
- Logmeldungen auf Stufe 3 vermieden bei Neustart von fhem
- restore der clients verbessert durch Nutzung von updateClient
Ich empfehle den Aufruf von "<myUnifi> set clear" all nach Durchführung des Updates um evtl. Leichen in den Readings loszuwerden.
VG,
Dirk
Hi, die Module sind echt alle sehr hilfreich! Ich verwende nun auch UnifiClient was mir meine etwas kompliziertere WLAN Erkennung ersetzt. Wäre es möglich ein Presence reading kompatibel zum ROOMMATE Module einzubauen? Das wäre richtig top! :)
Grüße
Dirk
Das müsstest du ja sonst auch selbst machen können über userReadings der betroffenen Clients.
Du willst ja sicherlich statt connected--> present und bei disconnected --> absent.
Moin,
wäre es nicht vielleicht sogar sinnvoll ein Attribut einzuführen, in dem man das Roommate-Device angeben kann und der UnifiClient setzt das Roommate dann bei connected auf preswnt und bei disconnwcted auf absent?
VG,
Dirk
Ich nutze ROOMMATE nicht aber so wie ich es verstehe, wäre ein DOIF oder notify dann am einfachsten, welches einen dunmy triggert. Da würde ich nix im Unfi Modul machen
Hallo,
zunächst mal: danke für das Modul und das Hilfsmodul...
Habe es (bzw. sie) mal auf meinem Testsystem eingerichtet...
...erster Versuch lief nicht so gerade raus: Fehlermeldungen bzgl. Switch ;)
Nach einem Update (Testsystem war wohl schon ein paar Tage alt ;) ) und Neuanlegen alles gut!
Ich habe mehrere APs und manchmal verbindet sich ein Client mit dem "falschen" AP...
...wenn ich dann im Unifi-Controller beim Client auf "reconnect" klicke, ist meist (eigentlich immer) alles gut.
Leider konnte ich keinen "reconnect" im Modul finden (auch nicht beim UnifiClient).
Bin ich zu doof oder gibt es den "Befehl" nicht?
Könnte man den einbauen!? :)
(oder ist er bewusst bzw. weil nicht möglich nicht eingebaut?)
Damit könnte ich das dann automatisieren :)
Gruß, Joachim
Zitat von: Wuehler am 29 Mai 2019, 10:16:43
Moin,
wäre es nicht vielleicht sogar sinnvoll ein Attribut einzuführen, in dem man das Roommate-Device angeben kann und der UnifiClient setzt das Roommate dann bei connected auf preswnt und bei disconnwcted auf absent?
VG,
Dirk
Ich fände das Prima!
Allerdings gibt es solch ein Attribut bereits im ROOMMATE Modul:
Zitatrr_presenceDevices - übernehmen des presence Status von einem anderen FHEM Device. Bei mehreren Devices diese mit Komma trennen, um ein Update des ROOMMATE Devices auszulösen, sobald ALLE Devices entweder absent oder present sind. Optional kann auch durch : abgetrennt ein Reading Name angegeben werden, ansonsten werden die Readings presence und state berücksichtigt.
Daher wäre nur ein reading presence mit status "present" und "absent", äquivalent zum state "connected" und "disconnected", ausreichend.
Grüße
Dirk
Hallo Joachim,
Das Unifi-Modul hat einen setter disconnectClient. Der entspricht dem reconnect. Ist glaube ich schon in der ersten Version des Moduls drin gewesen. Wahrscheinlich hieß das im Unifi-Controller damals auch noch so.
Das Modul UnifiClient hat diese Funktion(noch) nicht, da es noch recht neu ist.
VG,
dirk
@Dersch: ich schau mir das mal an, sofern Zeit vorhanden ist dazu.
OK danke dafür :)
Hi Dersch,
am UnifiClient-Modul muss man nichts anpassen. FHEM bietet schon alle Mittel an, um den Status eines Roommates per rr_presenceDevice an den UnifiClient zu binden. Über userReadings kann ein neues Reading erzeugt werden:
attr myUnifiClient userReadings presence {((ReadingsVal("$name","fhem_state","?") eq "connected") ? "present":"absent");;}
Edit: Habs auch im WIKI (https://wiki.fhem.de/wiki/UnifiClient#Anwesenheitserkennung)aufgenommen.
VG, Dirk
Zitat von: Wuehler am 29 Mai 2019, 16:48:27
Hallo Joachim,
Das Unifi-Modul hat einen setter disconnectClient. Der entspricht dem reconnect. Ist glaube ich schon in der ersten Version des Moduls drin gewesen. Wahrscheinlich hieß das im Unifi-Controller damals auch noch so.
Das Modul UnifiClient hat diese Funktion(noch) nicht, da es noch recht neu ist.
VG,
dirk
Hallo Dirk,
ich habe es vermutet aber bevor ich da drücke und mir mein neues Netzwerk "durcheinanderbringe" dachte ich ich frag mal ;)
Danke!
Werde ich bei Gelegenheit dann entsprechend nutzen.
Mir reicht es im Unifi-Modul (denke ich).
Gruß, Joachim
Eine Kleinigkeit ist mir aufgefallen:
wenn der Alias im Unifi-Controller ein Leerzeichen enthält, dann wird der Name nicht ins Modul übernommen...
...absicht!?
EDIT: gilt nur für Clients. Bei APs ist es kein Problem (zumindest werden meine angezeigt und sie haben Leerzeichen im Namen/Alias)...
Nicht schlimm, habe einfach die 2 Namen die ich noch mit Leerzeichen hatte in was umbenamst mit ohne ;)
Gruß, Joachim
Zitat von: Wuehler am 30 Mai 2019, 11:20:29
Hi Dersch,
am UnifiClient-Modul muss man nichts anpassen. FHEM bietet schon alle Mittel an, um den Status eines Roommates per rr_presenceDevice an den UnifiClient zu binden. Über userReadings kann ein neues Reading erzeugt werden:
attr myUnifiClient userReadings presence {((ReadingsVal("$name","fhem_state","?") eq "connected") ? "present":"absent");;}
Edit: Habs auch im WIKI (https://wiki.fhem.de/wiki/UnifiClient#Anwesenheitserkennung)aufgenommen.
VG, Dirk
Und wieder was über FHEM gelernt! Vielen Dank!
Grüße
Dirk
Wusste ich auch nur noch rudimentär. Lange nicht gebraucht.
Ist so eine sehr elegante Verbindung zwischen Roommate und UnifiClient. Danke dir für die Anforderungsbeschreibung per pm.
@MadMax: Absicht ist es in dem Sinne, dass man keine Readingnamen mit Leerzeichen erzeugen kann. Mal schauen, wo ich das am besten dokumentieren kann.
Zitat von: Wuehler am 30 Mai 2019, 21:00:02
@MadMax: Absicht ist es in dem Sinne, dass man keine Readingnamen mit Leerzeichen erzeugen kann. Mal schauen, wo ich das am besten dokumentieren kann.
Komisch, weil für APs geht es bzw. schaffst du es (irgendwie), hier mal ein Auszug/Beispiel:
READINGS:
2019-05-30 21:35:21 -AP_8 POE-60W Eingang_locate off
2019-05-30 21:35:21 -AP_8 POE-60W Eingang_state ok
2019-05-30 21:35:21 -AP_AP-AC-Mesh Balkon_locate off
2019-05-30 21:35:21 -AP_AP-AC-Mesh Balkon_state ok
2019-05-30 21:35:21 -AP_AP-AC-Pro Eingang_locate off
2019-05-30 21:35:21 -AP_AP-AC-Pro Eingang_state ok
2019-05-30 21:35:21 -AP_AP-AC-Pro Flur_locate off
2019-05-30 21:35:21 -AP_AP-AC-Pro Flur_state ok
Aber wie geschrieben: kein Problem, ich habe mich angepasst ;) / wie "gesagt" komisch ist nur der Unterschied zwischen APs und Clients...
Gruß, Joachim
Moin,
Der Codeteil ist noch von meinem Vorgänger, der konnte besser perl als ich ;) Evtl. ist da auch nicht jede FHEM-Anpassung des Kerns nachgezogen worden (?)
Laut DevelopmentModulAPI (https://wiki.fhem.de/wiki/DevelopmentModuleAPI#goodReadingname) ist ein Leerzeichen kein gültiges Readingzeichen. Muss ich bei den AP-Namen dann mal anpassen und makeReadingname nutzen. Dann wird aus dem Leerzeichen ein Unterstrich.
VG,
Dirk
Hallo Dirk,
wie geschrieben kein Problem.
Ich kann mit jeder Variante leben ;)
Mir ist es nur aufgefallen ;)
Gruß und danke für die Antwort(en), Joachim
Mal eine andere frage vielleicht hat ja jemand eine Idee. Wie kann ich Geräte im Gast Wlan anpingen ? Als zusatz Schutz würde ich gerne die Geräte Pingen. Leider geht das bei Gästen nicht durch :)
Zitat von: ChrisW am 08 Juni 2019, 14:24:23
Mal eine andere frage vielleicht hat ja jemand eine Idee. Wie kann ich Geräte im Gast Wlan anpingen ? Als zusatz Schutz würde ich gerne die Geräte Pingen. Leider geht das bei Gästen nicht durch :)
Eigentlich trennt man die Netze ja, damit sie .. nun ja .. getrennt sind. Dann ist eben nur noch Traffic dazwischen möglich, wenn er entsprechend geroutet wird. Davon abgesehen habe ich nicht verstanden, was für eine Art "Schutz" du dir von einem Ping versprichst. Überdenk das erst mal, damit du den Aufwand begründen kannst.
Wenn du konkretere Hilfe brauchst, musst du etwas mehr über dein Netzwerk verraten. Das Gast-WLAN hat offenbar eine eigene IP-Range; hat es auch ein eigenes VLAN? Von wo aus möchtest du pingen und wie sieht deine Infrastruktur aus (VLAN-fähige Switche? Was für ein Router?)
Übrigens kann man im Unifi-Controller dem Gäste-WLAN nicht nur einen Adressbereich zuordnen, sondern such einstellen, dass man vom Gäste-WLAN nicht auf andere lokale IP-Bereiche zugreifen kann - und das bringt Sicherheit, auch wenn man Gästegeräte dann nicht mehr anpingen kann (wodrin ich spontan auch keinen Sicherheitsgewinn sehen kann, eher das Gegenteil).
Moin Dirk,
Ich wollte nur mal kurz Lorbeeren loswerden.
Die disconnected Clients werden mittlerweile schön sauber weiter aktualisiert auch über einen Neustart hinweg.
Danke und Gruß
Maui
ja aber meine Gäste sind bekannte das ist nicht so schlimm :) Dann kommen die halt in mein normales Wlan :)
Unsere Tochter weint bitterlich. Da sie es mit ihrer Amazon Alexa übertreibt, hat diese in der Nacht eine Auszeit. Geregelt habe ich das über fhem mit BlockClient und am Morgen wurde dies bisher mit unblockClient wieder aufgelöst. Scheinbar funktioniert dies nicht mehr.
Wie ich jetzt feststellen musste, scheint im Modul kein unblock_Client mehr vorhanden zu sein. Ist das im Modul bewusst nicht mehr vorhanden oder ein Bug (siehe Anhang)?
Hallo astro,
schnelle und daher nicht 100% sichere Antwort:
das Modul schaut auf die Insights des UnifiControllers (wenn du eine einigermaßen aktuelle Modulversion hast). Wenn dabei blocked=true zurückkommt word unblockClient angeboten, sonst blockClient.
Manchmal kann es aufgrund Parallelität von Abfragen und Commands zu eigentznur kurzzeitigen Inkonsistenzen kommen. Mach dann mal ein set update, dann sollte es wieder gehen.
Für diesen Fall würde ich dir empfehlen explizit ein Modu UnifiClient anzulegen. Und wenn du dann damit Alexa in eine andere usergroup mit minimalem up/downstream schiebst wäre dein Netzwerk durch die Provisionierung beim blocken auch nicht mehr unterbrochen.
VG,
Dirk
Hallo Dirk!
Vielen Dank für die schnelle Rückmeldung. Ich werde das heute Abend ´mal testen, wenn die Alexa der Tochter wieder "offline" geht.
Das Modul ist auf dem aktuellen Stand, habe gestern auch extra nochmal ein Update gefahren.
Die Alexa der Tochter mit dem Modul "UnifiClient" in FHEM zu integrieren ist eine sehr gute Idee. Darüber habe ich bisher noch nicht nachgedacht.
Sonnige Grüße
Andreas
Gerade ´mal ein wenig geteset. BlockClient und UnblockClient scheinen mit der aktuellsten Controller Version 5.10.24-11676-1 nicht mehr zu funktionieren. Im FHEM Log sehe ich, dass der Befehl ausgeführt wird. Mit der neuen Controller-Version wurde auch eingeführt, dass BlockClient auf dem WebGUI des Controllers nochmals bestätigt werden muss (kann allerdings auch mit "Nicht mehr fragen") dekaktiviert werden). Die Abschaltung der Abfrage hat keine Auswirkungen auf die blockClient aus FHEM heraus.
So sieht das bei mir in Fhem aus
define EchoDot_Lotta_aus at *21:30:00 set UnifiController blockClient cc:9e:a2:ed:bb:68
define EchoDot_Lotta_an at *05:30:00 set UnifiController unblockClient cc:9e:a2:ed:bb:68
Die Verbindnung von FHEM/Modul zum UnifiConroller steht, die Readings werden regelmäßig aktualisiert.
Funktioniert mit dem Modul eigentlich auch die Authorisierung/Nicht-Authorisierung von Clients im Gäste-WLAN?
Falls ich etwas testen kann, z.B. Betaversionen, sehr gerne.
Grüße
Andreas
Moin,
Habe den UC noch nicht upgedated und ging gestern Abend nicht so schnell, da ich am Netzwerk umbauen bin und DNS zur docker registry nicht mehr aufgelöst hat. Kann aber gut sein, dass die wieder eine Kleinigkeit geändert haben. Versuch es bis ich das fixen kann mit der Änderung der Usergroup (siehe hier (https://forum.fhem.de/index.php/topic,99864.msg933421.html#msg933421)).
VG,
Dirk
Moin,
Bin jetzt auch auf der .24er Version und kann bestätigen, dass block und unblock nicht mehr funktionieren. Müsste auch disconnectClient betreffen. Es gibt irgendeine Änderung m API-Endpunkt stamgr. Habe ber noch nicht gefunden welche.
VG,
Dirk
Bin ja schon immer auf der neuesten Unifi Version.
Begonnen hab ich mit: 5.10.23
Aktuell bin ich auch auf: 5.10.24_11676
disconnectClient geht aber wohl noch :)
EDIT: seit eben auf 5.10.25-11682-1 und disconnectClient geht noch :)
Gruß, Joachim
Hallo Dirk!
Habe nun, wie von Dir vorgeschlagen, die Geräte per Unifi Client eingebunden. Auf dem Unifi Controller gibt es nun mehrere Usergruppen mit unterschiedlichen Down-/Uploadraten. Funktioniert sehr gut :-) Sohnemann musste als Opfer herhalten.
Der Wechsel zwischen den Gruppen ist problemlos möglich. In einem der vorherigen Posts bzw. im Unifi Client - Faden, war von Problemen die Rede. Diese konnte ich bisher nicht feststellen.
Bei mir ist die aktuellste Controller-Version 5.10.24-11676-1 im Einsatz. Block/Unblock wie von Dir jetzt auch bestätigt, läuft bei mir auch nicht.
Vielen Dank nochmal für die schnelle Hilfe!
Grüße
Andreas
Andreas
Moin zusammen,
ich habe am (un)blockClient eine Kleinigkeit angepasst, jetzt funktioniert es bei mir wieder. Bin mir sehr sicher, das das auch bei den alten Unifi-Controller-Versionen funktioniert. Denke aber, dass die von astro beschriebene Variante die bessere ist, um solche Szenarien umzusetzen.
Morgen dann im Update.
VG,
Dirk
Hi Dirk,
wäre es eigentlich möglich bei Unifi Switch die Temperatur dessen als FHEM reading zu bekommen?
Grüße
Dirk
Moin,
Du könntest schonmal im Unifi-Modul ein verbose auf 5 stellen. Dann im UnifiModul ein update. Im Log stehen dann viele JSON-Daten. Die für den Switch raussuchen und Felder ansehen.
VG,
Dirk
Also einmal gibt es "sfp_temperature":"54.585" was natürlich nur das SFP Modul ist aber dennoch mal keine schlechte Info. Und dann gibt es noch "general_temperature":69 was die relevante ist.
Grüße
Dirk
Sehr schön, das sollte einfach gehen. Schaue ich mir beizeiten mal an. Würde die Namen aus dem Json übernehmen als Readingnamen.
VG,
Dirk
Vielen Dank für deine Mühe!
Grüße
Dirk
Moin,
Es gibt ja eine Vielzahl an weiteren Infos die man ggf. als Reading sehen möchte. Daher die weitere Diskussion im Thread zum UnifiSwitch (https://forum.fhem.de/index.php/topic,87728.0.html).
VG,
Dirk
Guten Morgen Wuehler,
ich habe meine Netzwerk Infra Struktur etwas erweitert und einen 16/150 angeschafft - die Integration lief Dank Deines Moduls wunderbar!
1000 Dank nochmal für Deine tolle arbeit an den UniFi Modulen.
Durch die umstrukturierung habe ich auch alle Netzwerkkomponenten auf den aktuellsten stand gebracht - nun gibt es im Controller das
"Intrution Pevention System" - hast Du mal geschaut ob man die Informationen hier in FHEM darstellen kann...? bei z.b. mehr als 10 Angriffen innerhalb 5 minuten eine Warnung senden könnte nicht schaden...
Moin lolo,
Gehen tut das bestimmt, aber noch ist das ganze bei Unifi noch beta, oder? Sprich: Da wird sich öfter mal was dran ändern. Ich weiß nicht, wie es bei dir ist, aber bei mir vab es bisher zwei Meldungen, davon einer ein false positive.
VG,
Dirk
Hallo zusammen,
ist es möglich das automatische Anlegen der Subdevices zu unterbinden?
Ich benötige eigentlich nur den Controller für PRESENCE, der Switch erzeugt nur unnötig große Logs.
Habe es mit autocreate / ignoreTypes versucht, leider erfolglos.
Moin,
das autocreate kann man nicht verhindern, kommt jetzt auf die Todo-List. Du kannst das Log denke ich aber auch mit event-on-change-reading kleiner bekommen.
VG,
Dirk
Zitat von: zimb0 am 03 Juli 2019, 07:39:52
Ich benötige eigentlich nur den Controller für PRESENCE, der Switch erzeugt nur unnötig große Logs.
Jo, das ist bei mir eigentlich auch so.
Hab mich gerade gefragt, wofür ich die Filelogs meiner beiden Switche überhaupt benötige. Sie waren jeweils für 2019 schon 1,5GB groß. Ich hab nun das Filelog-Device und das entsprechende Logfile gelöscht.
Was steht da drin, was Ihr unbedingt braucht? :)
Gruß Hoppel
Moin,
das Filelog benötigt man denke ich wirklich nicht. Kommt aber durch autocreate automatisch sofern dort das Attribut filelog gesetzt ist. Siehe Forum (https://forum.fhem.de/index.php?topic=93824.0).
Also einfach das Device Filelog löschen, dann wird die Logdatei sehr klein ;). Außerdem event-on-change-reading nur auf den state, dann wird das FHEM-Eventhandling nicht so belastet. (Schaue mal, ob ich das nach der Urlaubszeit als Default einbauen kann. )
Warum ignoreTypes nicht funktioniert schaue ich mir dann auch an.
VG,
Dirk
Hallo,
bin von OpenVPN über Linux Server zu USG VPN gewechselt. Bei dem alten Setup habe ich mir über Shell Script die Anzahl der VPN Verbindungen in Fhem geholt. Läßt sich das auch aus dem Controller auslesen? Über "Insights"/"Remote User VPN" wird es auf der Web-Oberfläche anzeigen.
Gruß
Eisix
Moin,
geht bestimmt, wenn es auf der Oberfläche sichtbar ist. Nehme gerne einen patch entgegen ;)
Aber erst in 3-4 Wochen. Bin erstmal im Urlaub.
VG,
Dirk
Moin Dirk,
danke für die Infos und die Zeit bzw. Energie die du in dieses Modul steckst.
Viele Grüße
Hallo,
Zitat
geht bestimmt, wenn es auf der Oberfläche sichtbar ist. Nehme gerne einen patch entgegen ;)
Aber erst in 3-4 Wochen. Bin erstmal im Urlaub.
Ich schaue mir das Modul mal an, aber hab nicht zu viel Hoffnung.
Schönen Urlaub!
Gruß
Eisix
Would it be possible to use makeDeviceName() when setting the AP readings?
I have following errors in Fhem log (due to AP name containing "+")
2019.07.05 14:09:05 3: bad reading name -AP_+0 (contains not A-Za-z/\d_\.- or is too long)
2019.07.05 14:09:05 3: bad reading name -AP_+0 (contains not A-Za-z/\d_\.- or is too long)
2019.07.05 14:09:05 3: bad reading name -AP_+0 (contains not A-Za-z/\d_\.- or is too long)
2019.07.05 14:09:05 3: bad reading name -AP_+0 (contains not A-Za-z/\d_\.- or is too long)
2019.07.05 14:09:05 3: bad reading name -AP_+0 (contains not A-Za-z/\d_\.- or is too long)
2019.07.05 14:09:05 3: bad reading name -AP_+0 (contains not A-Za-z/\d_\.- or is too long)
2019.07.05 14:09:05 3: bad reading name -AP_+2 (contains not A-Za-z/\d_\.- or is too long)
2019.07.05 14:09:05 3: bad reading name -AP_+2 (contains not A-Za-z/\d_\.- or is too long)
2019.07.05 14:09:05 3: bad reading name -AP_+2 (contains not A-Za-z/\d_\.- or is too long)
2019.07.05 14:09:05 3: bad reading name -AP_+2 (contains not A-Za-z/\d_\.- or is too long)
2019.07.05 14:09:05 3: bad reading name -AP_+2 (contains not A-Za-z/\d_\.- or is too long)
2019.07.05 14:09:05 3: bad reading name -AP_+2 (contains not A-Za-z/\d_\.- or is too long)
Hi,
Thats a good idea. I will fix it after my holidays.
Zitat von: Wuehler am 19 Juni 2019, 21:54:58
Moin,
Bin jetzt auch auf der .24er Version und kann bestätigen, dass block und unblock nicht mehr funktionieren. Müsste auch disconnectClient betreffen. Es gibt irgendeine Änderung m API-Endpunkt stamgr. Habe ber noch nicht gefunden welche.
VG,
Dirk
also mir fällt auch gerade auf das disconnect nicht mehr funktioniert, nach einer gewissen zeit wird zwar bei essid "unknown" angezeigt, aber der client bleibt auf connected ? 74_Unifi.pm ist version 3.3.3 und der controller läuft auf 5.10.25 . im controller selbst ist der client nicht mehr unter "verbunden" aufgelistst
Also ich bin auf neuester Version fhem (damit auch Unifi-Module), update vor ein paar Tagen...
Unifi-Controller auch neueste Version 5.10.25.
disconnectClient funktioniert bei mir wie gewünscht...
Also Client wird (kurzzeitig) disconnected...
Ich nutze das da ab und an bestimmte Clients am "falschen" AP "hängen"...
...durch disconnectClient wird der Client disconnected und verbindet sich (natürlich, wenn beim Client "autoconnect" eingestellt ist) wieder mit der SSID.
Meist dann mit dem "richtigen" AP :)
Das disconnectClient führt nicht dazu, dass ein WLAN-Client dauerhaft disconnected bleibt (außer er hat kein "automatisches Verbinden" eingestellt)...
Gruß, Joachim
@rocknob: ich vermute, dass du auch einen USG hast. ?
Dann wird ein client durch den Unifi-Controller an den USG gehängt. Er ist dann wired. Deine Presenceabfrage muss dann auch wired berücksichtigen.
VG,
Dirk
ja da hab ich mich wohl falsch ausgedrückt, es geht um presence per unifi ap, und ja ich habe ein USG, früher stand der client auf "disconnected" und zumindest 2018 ging das noch :D ich weiß gerade nicht wann ich den USG in betrieb genommen habe, kann aber gut 2019 sein
versteh ich das richtig das ich das USG abfragen muss ?
Nein, nicht das usg. Sondern das Attribut wired (oder wireless, bin mir gerade nicht sicher) des Clients. Wenn wired, dann ebenfalls absent.
Zitat von: Nestor am 10 Juli 2019, 14:48:10
Would it be possible to use makeDeviceName() when setting the AP readings?
I have following errors in Fhem log (due to AP name containing "+")
2019.07.05 14:09:05 3: bad reading name -AP_+0 (contains not A-Za-z/\d_\.- or is too long)
2019.07.05 14:09:05 3: bad reading name -AP_+0 (contains not A-Za-z/\d_\.- or is too long)
2019.07.05 14:09:05 3: bad reading name -AP_+0 (contains not A-Za-z/\d_\.- or is too long)
2019.07.05 14:09:05 3: bad reading name -AP_+0 (contains not A-Za-z/\d_\.- or is too long)
2019.07.05 14:09:05 3: bad reading name -AP_+0 (contains not A-Za-z/\d_\.- or is too long)
2019.07.05 14:09:05 3: bad reading name -AP_+0 (contains not A-Za-z/\d_\.- or is too long)
2019.07.05 14:09:05 3: bad reading name -AP_+2 (contains not A-Za-z/\d_\.- or is too long)
2019.07.05 14:09:05 3: bad reading name -AP_+2 (contains not A-Za-z/\d_\.- or is too long)
2019.07.05 14:09:05 3: bad reading name -AP_+2 (contains not A-Za-z/\d_\.- or is too long)
2019.07.05 14:09:05 3: bad reading name -AP_+2 (contains not A-Za-z/\d_\.- or is too long)
2019.07.05 14:09:05 3: bad reading name -AP_+2 (contains not A-Za-z/\d_\.- or is too long)
2019.07.05 14:09:05 3: bad reading name -AP_+2 (contains not A-Za-z/\d_\.- or is too long)
I suppose this patch fixes it:
--- 74_Unifi.pm 2019-07-07 10:26:18.000000000 +0200
+++ 74_Unifi.pm 2019-07-29 15:43:21.000000000 +0200
@@ -1650,7 +1650,7 @@
$essid = '';
$utiliz = '';
$apRef = $hash->{accespoints}->{$apID};
- $apName = ($apRef->{name}) ? $apRef->{name} : $apRef->{ip};
+ $apName = ($apRef->{name}) ? makeReadingName($apRef->{name}) : $apRef->{ip};
if (defined $apRef->{vap_table} && scalar @{$apRef->{vap_table}}) {
for my $vap (@{$apRef->{vap_table}}) {
Thanks for the reminder ;)
The fix is commoted and availiable with next update.
Kann Mann mit dem Modul einen Funkscan auslösen? Ich habe in der commandref nichts gesehen.
Moin,
geht momentan nicht. Und ich kann das leider auch nicht einbauen, da meine AP schon etwas älter sind und diese Funktion nicht unterstützen.
VG, Dirk
Hallo andies,
war dann wirklich eine Kleinigkeit, das einzubauen. Wie gesagt, ich kann es nicht testen. Bitte Feedback auch zur commandref und dem Namen "startRFScan". Sollte beides möglichst sprechend sein.
Dabei ist mir aufgefallen, dass in den Drop-Down-Listen bei Funktionen, die nur auf APs sinnvoll sind auch andere Devices auftauchen. Ist der Historie des Moduls geschuldet, werde ich dann irgendwann mal optimieren.
VG,
Dirk
Also, das scheint ausgelöst zu werden. Es gibt aber noch irgendwie Probleme. Zuerst habe ich mehrere APs und einen doppelt drin (siehe Screenshot), das dürfte aber an meinen Readings liegen, die ich hier anhänge:
READINGS:
2019-08-11 13:20:20 -AP_192.168.1.20_essid
2019-08-11 13:20:20 -AP_192.168.1.20_locate off
2019-08-11 13:20:20 -AP_192.168.1.20_state error
2019-08-11 13:20:20 -AP_Arbeitszimmer_clients 0
2019-08-11 13:20:20 -AP_Arbeitszimmer_essid
2019-08-11 13:20:20 -AP_Arbeitszimmer_locate unknown
2019-08-11 13:20:20 -AP_Arbeitszimmer_state error
2019-08-11 13:20:20 -AP_Arbeitszimmer_utilization 22,1
2019-08-11 13:20:20 -AP_Keller_clients 16
2019-08-11 13:20:20 -AP_Keller_essid WLAN-120954,Gast-120954,WLAN-120954,Gast-120954
2019-08-11 13:20:20 -AP_Keller_locate off
2019-08-11 13:20:20 -AP_Keller_state ok
2019-08-11 13:20:20 -AP_Keller_utilization 60,0
2019-08-11 13:20:20 -AP_Schlafzimmer_clients 11
2019-08-11 13:20:20 -AP_Schlafzimmer_essid WLAN-120954,Gast-120954,WLAN-120954,Gast-120954
2019-08-11 13:20:20 -AP_Schlafzimmer_locate off
2019-08-11 13:20:20 -AP_Schlafzimmer_state ok
2019-08-11 13:20:20 -AP_Schlafzimmer_utilization 7,0
2019-08-11 13:20:20 -AP_Switch_clients 6
2019-08-11 13:20:20 -AP_Switch_locate off
2019-08-11 13:20:20 -AP_Switch_state ok
2019-08-11 13:20:20 -UC_blockedClients
2019-08-11 13:20:20 -UC_events 192 (last 24h)
2019-08-11 13:20:20 -UC_newClients
2019-08-11 13:20:20 -UC_unarchived_alerts 1
2019-08-11 13:20:20 -UC_wlan_accesspoints 2
2019-08-11 13:20:20 -UC_wlan_guests 0
2019-08-11 13:20:20 -UC_wlan_state warning
2019-08-11 13:20:20 -UC_wlan_users 27
2019-08-11 13:20:20 -WLAN_Gast-120954_state enabled
2019-08-11 13:20:20 -WLAN_WLAN-120954_state enabled
Dann habe ich den Scan ausgelöst und das bei beiden APs gemacht, die mir angezeigt wurden:
2019.08.11 13:03:09 5: Unifi (Unifi_Notify) - executed.
2019.08.11 13:03:09 5: Unifi: get called with ?.
2019.08.11 13:03:10 5: Unifi (Unifi_Notify) - executed.
2019.08.11 13:03:16 5: Unifi: set called with startRFScan Arbeitszimmer
2019.08.11 13:03:16 4: Unifi: set startRFScan
2019.08.11 13:03:16 5: Unifi (Unifi_ApCmd_Send) - executed with cmd:'spectrum-scan', count:'1', ID:'5d3eebb9fa410d04ac46eded'
2019.08.11 13:03:18 5: Unifi: get called with ?.
2019.08.11 13:03:18 5: Unifi (Unifi_DeviceCmd_Receive) - executed.
2019.08.11 13:03:18 5: Unifi (Unifi_DeviceCmd_Receive) - state:'ok'
2019.08.11 13:03:31 5: Unifi: set called with startRFScan Arbeitszimmer
2019.08.11 13:03:31 4: Unifi: set startRFScan
2019.08.11 13:03:31 5: Unifi (Unifi_ApCmd_Send) - executed with cmd:'spectrum-scan', count:'1', ID:'5d3eebb9fa410d04ac46eded'
2019.08.11 13:03:34 5: Unifi (Unifi_DeviceCmd_Receive) - executed.
2019.08.11 13:03:34 5: Unifi (Unifi_DeviceCmd_Receive) - state:'ok'
2019.08.11 13:04:36 5: Unifi (Unifi_DoUpdate) - executed.
2019.08.11 13:04:36 5: Unifi (Unifi_GetClientInsights_Send) - executed.
2019.08.11 13:04:40 5: Unifi (Unifi_GetClientInsights_Receive) - executed.
2019.08.11 13:04:40 5: Unifi (Unifi_GetClientInsights_Receive) - state:'ok'
2019.08.11 13:04:40 5: Unifi (Unifi_GetAccesspoints_Send) - executed.
2019.08.11 13:04:41 5: Unifi (Unifi_GetAccesspoints_Receive) - executed.
2019.08.11 13:04:41 5: Unifi (Unifi_GetAccesspoints_Receive) - state:'ok'
Danach kommen sehr, sehr viele Logeinträge, von denen ich nicht weiß, wie wichtig die sind:
2019.08.11 13:04:42 5: Unifi: dispatch UnifiSwitch_Switch{"cfgversion":"780ce948494da9d2","x_ssh_hostkey_fingerprint":"71:7e:34:11:dd:9b:cc:be:af:f6:e3:89:11:93:68:81","x_has_ssh_hostkey":true,"total_max_power":50,"adopted":true,"device_id":"5d3eebc1fa410d04ac46edf1","_id":"5d3eebc1fa410d04ac46edf1","x_fingerprint":"71:7e:34:11:dd:9b:cc:be:af:f6:e3:89:11:93:68:81","uplink_depth":1,"dhcp_server_table":[],"hw_caps":0,"tx_bytes":2300487050,"user-num_sta":6,"type":"usw","rx_bytes":459659590,"rollupgrade":false,"has_fan":false,"switch_caps":{"max_aggregate_sessions":4,"max_mirror_sessions":1,"feature_caps":1022},"fw_caps":4906533,"name":"Switch","guest-num_sta":0,"dot1x_portctrl_enabled":false,"system-stats":{"cpu":"56.7","mem":"49.9","uptime":"142029"},"uplink":{"rx_bytes-r":1693,"rx_errors":0,"port_idx":1,"tx_packets":1954575,"tx_errors":0,"name":"eth0","full_duplex":true,"rx_multicast":0,"tx_bytes-r":1840,"up":true,"tx_dropped":0,"num_port":8,"speed":1000,"rx_bytes":2300487050,"type":"wire","media":"GE","netmask":"255.255.255.0","rx_packets":2801119,"rx_dropped":0,"max_speed":1000,"ip":"192.168.2.95","tx_bytes":459659590,"mac":"74:83:c2:13:15:52"},"port_table":[{"satisfaction":100,"poe_caps":0,"speed_caps":1048623,"dot1x_status":"disabled","rx_errors":0,"tx_broadcast":40411,"rx_bytes-r":1693,"up":true,"bytes-r":3533,"tx_bytes-r":1840,"portconf_id":"5d3e8c53fa410d0ec637f89b","lldp_table":[],"full_duplex":true,"rx_broadcast":298664,"name":"Port 1","stp_state":"forwarding","dot1x_mode":"unknown","flowctrl_rx":false,"tx_multicast":204429,"tx_errors":0,"op_mode":"switch","tx_packets":1954575,"port_idx":1,"port_poe":false,"stp_pathcost":20000,"is_uplink":true,"jumbo":false,"tx_dropped":0,"rx_multicast":34868,"aggregated_by":false,"media":"GE","rx_bytes":2300487050,"speed":1000,"masked":false,"enable":true,"tx_bytes":459659590,"flowctrl_tx":false,"rx_dropped":0,"rx_packets":2801119,"autoneg":true},{"satisfaction":100,"poe_caps":0,"speed_caps":1048623,"rx_errors":0,"dot1x_status":"disabled","tx_broadcast":338829,"rx_bytes-r":0,"up":true,"bytes-r":591,"tx_bytes-r":591,"portconf_id":"5d3e8c53fa410d0ec637f89b","lldp_table":[],"full_duplex":true,"name":"Port 2","rx_broadcast":219,"stp_state":"forwarding","dot1x_mode":"unknown","flowctrl_rx":false,"tx_multicast":239180,"tx_errors":0,"op_mode":"switch","port_idx":2,"tx_packets":756964,"port_poe":false,"stp_pathcost":200000,"is_uplink":false,"jumbo":false,"tx_dropped":0,"rx_multicast":4,"media":"GE","aggregated_by":false,"speed":100,"rx_bytes":17830532,"masked":false,"enable":true,"tx_bytes":85623739,"flowctrl_tx":false,"rx_dropped":0,"rx_packets":35585,"autoneg":true},{"tx_broadcast":308800,"rx_bytes-r":15,"rx_errors":0,"dot1x_status":"disabled","poe_caps":0,"speed_caps":1048623,"satisfaction":100,"name":"Port 3","rx_broadcast":29475,"full_duplex":true,"lldp_table":[],"portconf_id":"5d3e8c53fa410d0ec637f89b","tx_bytes-r":597,"bytes-r":612,"up":true,"stp_state":"forwarding","tx_multicast":164409,"flowctrl_rx":false,"dot1x_mode":"unknown","jumbo":false,"stp_pathcost":20000,"is_uplink":false,"port_poe":false,"port_idx":3,"tx_packets":8412540,"op_mode":"switch","tx_errors":0,"rx_multicast":73856,"tx_dropped":0,"rx_bytes":6373846485,"speed":1000,"media":"GE","aggregated_by":false,"rx_packets":7188963,"autoneg":true,"rx_dropped":0,"flowctrl_tx":false,"tx_bytes":7235421244,"enable":true,"masked":false},{"flowctrl_rx":false,"tx_multicast":234681,"dot1x_mode":"unknown","stp_state":"forwarding","full_duplex":true,"rx_broadcast":2706,"name":"Port 4","lldp_table":[],"tx_bytes-r":591,"bytes-r":591,"portconf_id":"5d3e8c53fa410d0ec637f89b","up":true,"dot1x_status":"disabled","rx_errors":0,"rx_bytes-r":0,"tx_broadcast":336357,"speed_caps":1048623,"poe_caps":0,"satisfaction":100,"rx_dropped":0,"autoneg":true,"rx_packets":6217355,"tx_bytes":6075426246,"flowctrl_tx":false,"enable":true,"masked":false,"speed":1000,"rx_bytes":5862692565,"media":"GE","aggregated_by":false,"rx_multicast":4558,"tx_dropped":0,"is_uplink":false,"stp_pathcost":20000,"jumbo":false,"port_poe":false,"port_idx":4,"tx_packets":6518572,"tx_errors":0,"op_mode":"switch"},{"poe_good":true,"rx_multicast":9154,"tx_dropped":0,"port_poe":true,"jumbo":false,"is_uplink":false,"stp_pathcost":20000,"op_mode":"switch","poe_voltage":"47.68","tx_errors":0,"port_idx":5,"tx_packets":1123144,"poe_current":"68.60","rx_packets":382851,"autoneg":true,"rx_dropped":0,"enable":true,"masked":false,"flowctrl_tx":false,"tx_bytes":250888661,"media":"GE","aggregated_by":false,"speed":1000,"rx_bytes":112263059,"lldp_table":[],"poe_class":"Class 0","rx_broadcast":86,"name":"Port 5","full_duplex":true,"up":true,"portconf_id":"5d3e8c53fa410d0ec637f89b","tx_bytes-r":1177,"bytes-r":1337,"rx_bytes-r":160,"tx_broadcast":338970,"poe_power":"3.27","poe_mode":"auto","rx_errors":0,"dot1x_status":"disabled","satisfaction":100,"poe_caps":1,"speed_caps":1048623,"tx_multicast":230037,"flowctrl_rx":false,"dot1x_mode":"unknown","poe_enable":true,"stp_state":"forwarding"},{"rx_dropped":0,"rx_packets":721685,"autoneg":true,"poe_current":"63.23","tx_bytes":1039881240,"flowctrl_tx":false,"masked":false,"enable":true,"speed":1000,"rx_bytes":139504793,"media":"GE","aggregated_by":false,"rx_multicast":29193,"poe_good":true,"tx_dropped":0,"stp_pathcost":20000,"is_uplink":false,"jumbo":false,"port_poe":true,"tx_packets":1670772,"port_idx":6,"poe_voltage":"47.62","tx_errors":0,"op_mode":"switch","flowctrl_rx":false,"tx_multicast":209309,"poe_enable":true,"dot1x_mode":"unknown","stp_state":"forwarding","full_duplex":true,"name":"Port 6","rx_broadcast":814,"lldp_table":[],"poe_class":"Class 4","bytes-r":3014,"tx_bytes-r":1434,"portconf_id":"5d3e8c53fa410d0ec637f89b","up":true,"rx_errors":0,"dot1x_status":"disabled","rx_bytes-r":1580,"tx_broadcast":337603,"poe_mode":"auto","poe_power":"3.01","poe_caps":1,"speed_caps":1048623,"satisfaction":100},{"tx_multicast":237591,"flowctrl_rx":false,"poe_enable":true,"dot1x_mode":"unknown","stp_state":"forwarding","rx_broadcast":14,"name":"Port 7","full_duplex":true,"lldp_table":[],"poe_class":"Class 0","portconf_id":"5d3e8c53fa410d0ec637f89b","tx_bytes-r":590,"bytes-r":598,"up":true,"rx_bytes-r":8,"poe_power":"4.99","tx_broadcast":339044,"poe_mode":"auto","dot1x_status":"disabled","rx_errors":0,"speed_caps":1048623,"poe_caps":1,"satisfaction":100,"rx_packets":2254,"autoneg":true,"rx_dropped":0,"poe_current":"104.49","flowctrl_tx":false,"tx_bytes":82938306,"enable":true,"masked":false,"speed":100,"rx_bytes":462880,"aggregated_by":false,"media":"GE","rx_multicast":1705,"poe_good":true,"tx_dropped":0,"jumbo":false,"stp_pathcost":200000,"is_uplink":false,"port_poe":true,"port_idx":7,"tx_packets":720661,"op_mode":"switch","tx_errors":0,"poe_voltage":"47.75"},{"flowctrl_rx":false,"tx_multicast":228265,"poe_enable":true,"dot1x_mode":"unknown","stp_state":"forwarding","full_duplex":true,"name":"Port 8","rx_broadcast":3462,"lldp_table":[],"poe_class":"Class 4","tx_bytes-r":1106,"bytes-r":1859,"portconf_id":"5d3e8c53fa410d0ec637f89b","up":true,"rx_errors":0,"dot1x_status":"disabled","tx_broadcast":335137,"rx_bytes-r":752,"poe_power":"3.04","poe_mode":"auto","poe_caps":1,"speed_caps":1048623,"satisfaction":100,"rx_dropped":0,"rx_packets":264076,"autoneg":true,"poe_current":"63.72","tx_bytes":168134148,"flowctrl_tx":false,"masked":false,"enable":true,"speed":1000,"rx_bytes":63575438,"aggregated_by":false,"media":"GE","rx_multicast":10546,"poe_good":true,"tx_dropped":0,"is_uplink":false,"stp_pathcost":20000,"jumbo":false,"port_poe":true,"port_idx":8,"tx_packets":944693,"poe_voltage":"47.75","tx_errors":0,"op_mode":"switch"}],"mac":"74:83:c2:13:15:52","site_id":"5d3e8c4efa410d0ec637f88b","license_state":"registered","unsupported_reason":0,"connect_request_ip":"192.168.2.95","connect_request_port":"56670","adoptable_when_upgraded":false,"stat":{"port_4-tx_packets":6592941,"o":"sw","port_7-rx_broadcast":6,"port_7-rx_bytes":731977,"port_6-tx_packets":2102726,"port_8-tx_packets":1014298,"port_1-rx_multicast":37071,"port_5-tx_bytes":829243970,"port_2-tx_multicast":256016,"port_4-rx_multicast":4645,"port_2-rx_broadcast":233,"rx_dropped":0,"port_3-tx_packets":8588353,"port_6-tx_multicast":222355,"time":1565369400000,"bytes":32639946389,"port_2-rx_bytes":23363958,"port_1-tx_multicast":218947,"tx_packets":23576603,"port_8-rx_broadcast":3833,"port_1-rx_broadcast":319031,"tx_retries":0,"rx_multicast":175405,"sw":"74:83:c2:13:15:52","port_4-rx_broadcast":2823,"port_4-tx_multicast":251373,"port_4-rx_packets":6236245,"tx_dropped":0,"port_7-tx_bytes":88738409,"port_4-tx_broadcast":360686,"port_3-rx_multicast":77786,"port_5-tx_packets":1611513,"port_8-rx_multicast":11376,"port_3-tx_multicast":176999,"port_2-tx_broadcast":363276,"port_3-rx_packets":7320475,"rx_crypts":0,"tx_multicast":1870422,"port_5-tx_broadcast":363420,"port_4-rx_bytes":5866271584,"port_8-rx_packets":291089,"port_6-rx_multicast":32966,"rx_frags":0,"port_1-tx_broadcast":44480,"port_2-tx_bytes":92197314,"port_5-rx_multicast":9790,"rx_errors":0,"port_5-rx_broadcast":89,"port_4-tx_bytes":6109658718,"port_5-rx_bytes":555926141,"port_6-rx_packets":1157897,"duration":151951000,"port_6-rx_bytes":707276200,"port_1-tx_bytes":491027942,"rx_bytes":16037809970,"port_1-rx_packets":2954295,"port_3-rx_bytes":6427300776,"port_7-rx_packets":2549,"port_8-tx_bytes":175531552,"rx_packets":18771440,"port_7-tx_packets":771922,"port_8-tx_broadcast":359161,"oid":"74:83:c2:13:15:52","tx_bytes":16602136419,"port_8-tx_multicast":244253,"port_6-tx_bytes":1505446534,"port_7-rx_multicast":1769,"tx_errors":0,"port_3-tx_bytes":7310291980,"port_3-rx_broadcast":32687,"port_6-rx_broadcast":939,"port_2-tx_packets":818446,"port_5-rx_packets":763101,"datetime":"2019-08-09T16:50:00Z","port_7-tx_broadcast":363508,"port_6-tx_broadcast":361863,"port_8-rx_bytes":70166506,"port_2-rx_multicast":2,"port_1-rx_bytes":2386772828,"port_2-rx_packets":45789,"site_id":"5d3e8c4efa410d0ec637f88b","port_1-tx_packets":2076404,"tx_broadcast":2545842,"port_7-tx_multicast":254250,"rx_broadcast":359641,"port_5-tx_multicast":246229,"port_3-tx_broadcast":329448},"x_inform_authkey":"56f043662ca464a48ab87052925af7a3","jumboframe_enabled":false,"unsupported":false,"bytes":2760146640,"num_sta":6,"has_temperature":false,"x_aes_gcm":true,"_uptime":142029,"upgradable":false,"locating":false,"x_authkey":"56f043662ca464a48ab87052925af7a3","ip":"192.168.2.95","downlink_table":[{"speed":1000,"full_duplex":true,"port_idx":3,"mac":"f0:9f:c2:a6:4d:00"},{"port_idx":6,"mac":"18:e8:29:50:c0:f3","full_duplex":true,"speed":1000},{"mac":"18:e8:29:a9:44:a0","port_idx":8,"full_duplex":true,"speed":1000}],"uptime":142029,"inform_url":"http://192.168.2.40:8080/inform","flowctrl_enabled":false,"inform_ip":"192.168.2.40","config_network":{"ip":"192.168.2.95","type":"dhcp"},"ethernet_table":[{"num_port":8,"name":"eth0","mac":"74:83:c2:13:15:52"},{"name":"srv0","mac":"74:83:c2:13:15:53"}],"serial":"7483C2131552","known_cfgversion":"780ce948494da9d2","ssh_session_table":[],"model":"US8P60","sys_error_caps":0,"two_phase_adopt":false,"stp_version":"rstp","last_seen":1565521469,"board_rev":8,"version":"4.0.54.10625","state":1,"overheating":false,"stp_priority":"32768","required_version":"3.7.16","sys_stats":{"mem_total":262397952,"loadavg_15":"1.87","mem_used":130969600,"mem_buffer":0,"loadavg_5":"2.09","loadavg_1":"2.04"}}
2019.08.11 13:04:42 5: Unifi (UnifiSwitch_Parse) - executed. UnifiSwitch: Adress: Switch
2019.08.11 13:04:42 5: Unifi (UnifiSwitch_Parse) - executed. UnifiSwitch: message_json: {"cfgversion":"780ce948494da9d2","x_ssh_hostkey_fingerprint":"71:7e:34:11:dd:9b:cc:be:af:f6:e3:89:11:93:68:81","x_has_ssh_hostkey":true,"total_max_power":50,"adopted":true,"device_id":"5d3eebc1fa410d04ac46edf1","_id":"5d3eebc1fa410d04ac46edf1","x_fingerprint":"71:7e:34:11:dd:9b:cc:be:af:f6:e3:89:11:93:68:81","uplink_depth":1,"dhcp_server_table":[],"hw_caps":0,"tx_bytes":2300487050,"user-num_sta":6,"type":"usw","rx_bytes":459659590,"rollupgrade":false,"has_fan":false,"switch_caps":{"max_aggregate_sessions":4,"max_mirror_sessions":1,"feature_caps":1022},"fw_caps":4906533,"name":"Switch","guest-num_sta":0,"dot1x_portctrl_enabled":false,"system-stats":{"cpu":"56.7","mem":"49.9","uptime":"142029"},"uplink":{"rx_bytes-r":1693,"rx_errors":0,"port_idx":1,"tx_packets":1954575,"tx_errors":0,"name":"eth0","full_duplex":true,"rx_multicast":0,"tx_bytes-r":1840,"up":true,"tx_dropped":0,"num_port":8,"speed":1000,"rx_bytes":2300487050,"type":"wire","media":"GE","netmask":"255.255.255.0","rx_packets":2801119,"rx_dropped":0,"max_speed":1000,"ip":"192.168.2.95","tx_bytes":459659590,"mac":"74:83:c2:13:15:52"},"port_table":[{"satisfaction":100,"poe_caps":0,"speed_caps":1048623,"dot1x_status":"disabled","rx_errors":0,"tx_broadcast":40411,"rx_bytes-r":1693,"up":true,"bytes-r":3533,"tx_bytes-r":1840,"portconf_id":"5d3e8c53fa410d0ec637f89b","lldp_table":[],"full_duplex":true,"rx_broadcast":298664,"name":"Port 1","stp_state":"forwarding","dot1x_mode":"unknown","flowctrl_rx":false,"tx_multicast":204429,"tx_errors":0,"op_mode":"switch","tx_packets":1954575,"port_idx":1,"port_poe":false,"stp_pathcost":20000,"is_uplink":true,"jumbo":false,"tx_dropped":0,"rx_multicast":34868,"aggregated_by":false,"media":"GE","rx_bytes":2300487050,"speed":1000,"masked":false,"enable":true,"tx_bytes":459659590,"flowctrl_tx":false,"rx_dropped":0,"rx_packets":2801119,"autoneg":true},{"satisfaction":100,"poe_caps":0,"speed_caps":1048623,"rx_errors":0,"dot1x_status":"disabled","tx_broadcast":338829,"rx_bytes-r":0,"up":true,"bytes-r":591,"tx_bytes-r":591,"portconf_id":"5d3e8c53fa410d0ec637f89b","lldp_table":[],"full_duplex":true,"name":"Port 2","rx_broadcast":219,"stp_state":"forwarding","dot1x_mode":"unknown","flowctrl_rx":false,"tx_multicast":239180,"tx_errors":0,"op_mode":"switch","port_idx":2,"tx_packets":756964,"port_poe":false,"stp_pathcost":200000,"is_uplink":false,"jumbo":false,"tx_dropped":0,"rx_multicast":4,"media":"GE","aggregated_by":false,"speed":100,"rx_bytes":17830532,"masked":false,"enable":true,"tx_bytes":85623739,"flowctrl_tx":false,"rx_dropped":0,"rx_packets":35585,"autoneg":true},{"tx_broadcast":308800,"rx_bytes-r":15,"rx_errors":0,"dot1x_status":"disabled","poe_caps":0,"speed_caps":1048623,"satisfaction":100,"name":"Port 3","rx_broadcast":29475,"full_duplex":true,"lldp_table":[],"portconf_id":"5d3e8c53fa410d0ec637f89b","tx_bytes-r":597,"bytes-r":612,"up":true,"stp_state":"forwarding","tx_multicast":164409,"flowctrl_rx":false,"dot1x_mode":"unknown","jumbo":false,"stp_pathcost":20000,"is_uplink":false,"port_poe":false,"port_idx":3,"tx_packets":8412540,"op_mode":"switch","tx_errors":0,"rx_multicast":73856,"tx_dropped":0,"rx_bytes":6373846485,"speed":1000,"media":"GE","aggregated_by":false,"rx_packets":7188963,"autoneg":true,"rx_dropped":0,"flowctrl_tx":false,"tx_bytes":7235421244,"enable":true,"masked":false},{"flowctrl_rx":false,"tx_multicast":234681,"dot1x_mode":"unknown","stp_state":"forwarding","full_duplex":true,"rx_broadcast":2706,"name":"Port 4","lldp_table":[],"tx_bytes-r":591,"bytes-r":591,"portconf_id":"5d3e8c53fa410d0ec637f89b","up":true,"dot1x_status":"disabled","rx_errors":0,"rx_bytes-r":0,"tx_broadcast":336357,"speed_caps":1048623,"poe_caps":0,"satisfaction":100,"rx_dropped":0,"autoneg":true,"rx_packets":6217355,"tx_bytes":6075426246,"flowctrl_tx":false,"enable":true,"masked":false,"speed":1000,"rx_bytes":5862692565,"media":"GE","aggregated_by":false,"rx_multicast":4558,"tx_dropped":0,"is_uplink":false,"stp_pathcost":20000,"jumbo":false,"port_poe":false,"port_idx":4,"tx_packets":6518572,"tx_errors":0,"op_mode":"switch"},{"poe_good":true,"rx_multicast":9154,"tx_dropped":0,"port_poe":true,"jumbo":false,"is_uplink":false,"stp_pathcost":20000,"op_mode":"switch","poe_voltage":"47.68","tx_errors":0,"port_idx":5,"tx_packets":1123144,"poe_current":"68.60","rx_packets":382851,"autoneg":true,"rx_dropped":0,"enable":true,"masked":false,"flowctrl_tx":false,"tx_bytes":250888661,"media":"GE","aggregated_by":false,"speed":1000,"rx_bytes":112263059,"lldp_table":[],"poe_class":"Class 0","rx_broadcast":86,"name":"Port 5","full_duplex":true,"up":true,"portconf_id":"5d3e8c53fa410d0ec637f89b","tx_bytes-r":1177,"bytes-r":1337,"rx_bytes-r":160,"tx_broadcast":338970,"poe_power":"3.27","poe_mode":"auto","rx_errors":0,"dot1x_status":"disabled","satisfaction":100,"poe_caps":1,"speed_caps":1048623,"tx_multicast":230037,"flowctrl_rx":false,"dot1x_mode":"unknown","poe_enable":true,"stp_state":"forwarding"},{"rx_dropped":0,"rx_packets":721685,"autoneg":true,"poe_current":"63.23","tx_bytes":1039881240,"flowctrl_tx":false,"masked":false,"enable":true,"speed":1000,"rx_bytes":139504793,"media":"GE","aggregated_by":false,"rx_multicast":29193,"poe_good":true,"tx_dropped":0,"stp_pathcost":20000,"is_uplink":false,"jumbo":false,"port_poe":true,"tx_packets":1670772,"port_idx":6,"poe_voltage":"47.62","tx_errors":0,"op_mode":"switch","flowctrl_rx":false,"tx_multicast":209309,"poe_enable":true,"dot1x_mode":"unknown","stp_state":"forwarding","full_duplex":true,"name":"Port 6","rx_broadcast":814,"lldp_table":[],"poe_class":"Class 4","bytes-r":3014,"tx_bytes-r":1434,"portconf_id":"5d3e8c53fa410d0ec637f89b","up":true,"rx_errors":0,"dot1x_status":"disabled","rx_bytes-r":1580,"tx_broadcast":337603,"poe_mode":"auto","poe_power":"3.01","poe_caps":1,"speed_caps":1048623,"satisfaction":100},{"tx_multicast":237591,"flowctrl_rx":false,"poe_enable":true,"dot1x_mode":"unknown","stp_state":"forwarding","rx_broadcast":14,"name":"Port 7","full_duplex":true,"lldp_table":[],"poe_class":"Class 0","portconf_id":"5d3e8c53fa410d0ec637f89b","tx_bytes-r":590,"bytes-r":598,"up":true,"rx_bytes-r":8,"poe_power":"4.99","tx_broadcast":339044,"poe_mode":"auto","dot1x_status":"disabled","rx_errors":0,"speed_caps":1048623,"poe_caps":1,"satisfaction":100,"rx_packets":2254,"autoneg":true,"rx_dropped":0,"poe_current":"104.49","flowctrl_tx":false,"tx_bytes":82938306,"enable":true,"masked":false,"speed":100,"rx_bytes":462880,"aggregated_by":false,"media":"GE","rx_multicast":1705,"poe_good":true,"tx_dropped":0,"jumbo":false,"stp_pathcost":200000,"is_uplink":false,"port_poe":true,"port_idx":7,"tx_packets":720661,"op_mode":"switch","tx_errors":0,"poe_voltage":"47.75"},{"flowctrl_rx":false,"tx_multicast":228265,"poe_enable":true,"dot1x_mode":"unknown","stp_state":"forwarding","full_duplex":true,"name":"Port 8","rx_broadcast":3462,"lldp_table":[],"poe_class":"Class 4","tx_bytes-r":1106,"bytes-r":1859,"portconf_id":"5d3e8c53fa410d0ec637f89b","up":true,"rx_errors":0,"dot1x_status":"disabled","tx_broadcast":335137,"rx_bytes-r":752,"poe_power":"3.04","poe_mode":"auto","poe_caps":1,"speed_caps":1048623,"satisfaction":100,"rx_dropped":0,"rx_packets":264076,"autoneg":true,"poe_current":"63.72","tx_bytes":168134148,"flowctrl_tx":false,"masked":false,"enable":true,"speed":1000,"rx_bytes":63575438,"aggregated_by":false,"media":"GE","rx_multicast":10546,"poe_good":true,"tx_dropped":0,"is_uplink":false,"stp_pathcost":20000,"jumbo":false,"port_poe":true,"port_idx":8,"tx_packets":944693,"poe_voltage":"47.75","tx_errors":0,"op_mode":"switch"}],"mac":"74:83:c2:13:15:52","site_id":"5d3e8c4efa410d0ec637f88b","license_state":"registered","unsupported_reason":0,"connect_request_ip":"192.168.2.95","connect_request_port":"56670","adoptable_when_upgraded":false,"stat":{"port_4-tx_packets":6592941,"o":"sw","port_7-rx_broadcast":6,"port_7-rx_bytes":731977,"port_6-tx_packets":2102726,"port_8-tx_packets":1014298,"port_1-rx_multicast":37071,"port_5-tx_bytes":829243970,"port_2-tx_multicast":256016,"port_4-rx_multicast":4645,"port_2-rx_broadcast":233,"rx_dropped":0,"port_3-tx_packets":8588353,"port_6-tx_multicast":222355,"time":1565369400000,"bytes":32639946389,"port_2-rx_bytes":23363958,"port_1-tx_multicast":218947,"tx_packets":23576603,"port_8-rx_broadcast":3833,"port_1-rx_broadcast":319031,"tx_retries":0,"rx_multicast":175405,"sw":"74:83:c2:13:15:52","port_4-rx_broadcast":2823,"port_4-tx_multicast":251373,"port_4-rx_packets":6236245,"tx_dropped":0,"port_7-tx_bytes":88738409,"port_4-tx_broadcast":360686,"port_3-rx_multicast":77786,"port_5-tx_packets":1611513,"port_8-rx_multicast":11376,"port_3-tx_multicast":176999,"port_2-tx_broadcast":363276,"port_3-rx_packets":7320475,"rx_crypts":0,"tx_multicast":1870422,"port_5-tx_broadcast":363420,"port_4-rx_bytes":5866271584,"port_8-rx_packets":291089,"port_6-rx_multicast":32966,"rx_frags":0,"port_1-tx_broadcast":44480,"port_2-tx_bytes":92197314,"port_5-rx_multicast":9790,"rx_errors":0,"port_5-rx_broadcast":89,"port_4-tx_bytes":6109658718,"port_5-rx_bytes":555926141,"port_6-rx_packets":1157897,"duration":151951000,"port_6-rx_bytes":707276200,"port_1-tx_bytes":491027942,"rx_bytes":16037809970,"port_1-rx_packets":2954295,"port_3-rx_bytes":6427300776,"port_7-rx_packets":2549,"port_8-tx_bytes":175531552,"rx_packets":18771440,"port_7-tx_packets":771922,"port_8-tx_broadcast":359161,"oid":"74:83:c2:13:15:52","tx_bytes":16602136419,"port_8-tx_multicast":244253,"port_6-tx_bytes":1505446534,"port_7-rx_multicast":1769,"tx_errors":0,"port_3-tx_bytes":7310291980,"port_3-rx_broadcast":32687,"port_6-rx_broadcast":939,"port_2-tx_packets":818446,"port_5-rx_packets":763101,"datetime":"2019-08-09T16:50:00Z","port_7-tx_broadcast":363508,"port_6-tx_broadcast":361863,"port_8-rx_bytes":70166506,"port_2-rx_multicast":2,"port_1-rx_bytes":2386772828,"port_2-rx_packets":45789,"site_id":"5d3e8c4efa410d0ec637f88b","port_1-tx_packets":2076404,"tx_broadcast":2545842,"port_7-tx_multicast":254250,"rx_broadcast":359641,"port_5-tx_multicast":246229,"port_3-tx_broadcast":329448},"x_inform_authkey":"56f043662ca464a48ab87052925af7a3","jumboframe_enabled":false,"unsupported":false,"bytes":2760146640,"num_sta":6,"has_temperature":false,"x_aes_gcm":true,"_uptime":142029,"upgradable":false,"locating":false,"x_authkey":"56f043662ca464a48ab87052925af7a3","ip":"192.168.2.95","downlink_table":[{"speed":1000,"full_duplex":true,"port_idx":3,"mac":"f0:9f:c2:a6:4d:00"},{"port_idx":6,"mac":"18:e8:29:50:c0:f3","full_duplex":true,"speed":1000},{"mac":"18:e8:29:a9:44:a0","port_idx":8,"full_duplex":true,"speed":1000}],"uptime":142029,"inform_url":"http://192.168.2.40:8080/inform","flowctrl_enabled":false,"inform_ip":"192.168.2.40","config_network":{"ip":"192.168.2.95","type":"dhcp"},"ethernet_table":[{"num_port":8,"name":"eth0","mac":"74:83:c2:13:15:52"},{"name":"srv0","mac":"74:83:c2:13:15:53"}],"serial":"7483C2131552","known_cfgversion":"780ce948494da9d2","ssh_session_table":[],"model":"US8P60","sys_error_caps":0,"two_phase_adopt":false,"stp_version":"rstp","last_seen":1565521469,"board_rev":8,"version":"4.0.54.10625","state":1,"overheating":false,"stp_priority":"32768","required_version":"3.7.16","sys_stats":{"mem_total":262397952,"loadavg_15":"1.87","mem_used":130969600,"mem_buffer":0,"loadavg_5":"2.09","loadavg_1":"2.04"}}
2019.08.11 13:04:42 5: Unifi (UnifiSwitch_Parse) - return: Switch
2019.08.11 13:04:42 5: Unifi (Unifi_GetWlans_Send) - executed.
2019.08.11 13:04:44 5: Unifi (Unifi_GetWlans_Receive) - executed.
2019.08.11 13:04:44 5: Unifi (Unifi_GetWlans_Receive) - state:'ok'
2019.08.11 13:04:44 5: Unifi (Unifi_GetHealth_Send) - executed.
2019.08.11 13:04:46 5: Unifi (Unifi_GetHealth_Receive) - executed.
2019.08.11 13:04:46 5: Unifi (Unifi_GetHealth_Receive) - state:'ok'
....
Der AP, bei dem ich dann den Scan ausgelöst habe, war dann getrennt und musste händisch neu provisioniert werden.
PS Könnte man da einen Check einbauen, so etwa wie folgt
-AP_Arbeitszimmer_essid WLAN-120954,Gast-120954,WLAN-120954,Gast-120954
-AP_Arbeitszimmer_state ok
Haben die APs einen state "ok" und "nichtleere" ssid?
Zitat von: andies am 11 August 2019, 13:25:55
Dann habe ich den Scan ausgelöst und das bei beiden APs gemacht, die mir angezeigt wurden
Offenbar zwei mal beim AP Arbeitszimmer. Du hast da evtl. Restdaten im Modul. Mach mal ein "set clear all" gefolgt von einem "set update". Ca. 10 Sekunden warten, dann müsste ein Arbeitszimmer verschwunden sein.
Zitat von: andies am 11 August 2019, 13:25:55
Danach kommen sehr, sehr viele Logeinträge, von denen ich nicht weiß, wie wichtig die sind:
Die vielen Logeinträge ab 13:04:36 kommen von einem Update-Zyklus. Da werden eine Menge Infos vom UC abgefragt.
Zitat von: andies am 11 August 2019, 13:25:55
Der AP, bei dem ich dann den Scan ausgelöst habe, war dann getrennt und musste händisch neu provisioniert werden.
Lag das evtl. daran, dass zweimal das Arbeitszimmer einen scan machen sollte.
Zitat von: andies am 11 August 2019, 14:04:21
PS Könnte man da einen Check einbauen
Habe ich in der angehängten Version eingebaut. Aber erstmal nur, wenn essid als Reading vorhanden und ungleich 'none' ist. Edit: Anhang entfernt, da nun offiziell.
Klappt, wunderbar. Danke!!
Sehr schön. Dann teste bitte noch ein wenig und gibt Feedback zum Namen "startRFScan" und commandref. Wenn dann alles rund ist übernehme ich es in die offizielle Version.
Gerne auch den Anwendungsfall Wiki-Reif beschreiben, so dass andere leicht reinkommen und etwas übernehmen können.
mache ich gern, wird aber mit dem wiki etwas dauern; ging doch schnell. Und danke nochmal!
Habs dann auch commited, ab morgen Vormittag im Update.
Hallo,
ich hab in meinem Fall ständig die Fehlermeldungen im FHEM Log, wodurch mir ständig die 60GB Partition übergeht:
fhem.pl: Use of uninitialized value $isPortprofileID in concatenation (.) or string at ./FHEM/74_UnifiSwitch.pm line 130.
hat jemand eine Ahnung was hier bei dem Modul falsch Konfiguriert ist bzw. was ich da noch ändern muss, damit dieser Fehler nicht mehr auftritt?
Die Fehlermeldung habe ich auch im Logfile neuerdings.Das kann nur vom letzten Update vom Modul sein.
Moin,
das Problem lässt sich beheben, wenn man in Zeile 129 das undef durch ,," ersetzt und dann das Modul neu läd. Alternativ das neu Attribut portProfileDisableID setzen. Komme dazu wahrscheinlich erst Montag.
VG,
Dirk
Ist gefixt.
oder 3 Minuten mit einem notify:
define ntfy_unifi_presence notify myUnifiController:MyClient_last_seen:.* {
if (time() - time_str2num($EVENT) > 180) {
fhem("set dummy disconnected");
} else {
fhem("set dummy connected");
}
}
[/quote]
Wenn ich das so einfüge bekomme ich immer nur Fehler zb.:
Unknown command }, try help. Unknown command }}, try help.
Ich habs in einer Zeile probiert, nachdem er meinte, dass in der zweiten Zeile der Befehl falsch ist und auch in einer Zeile klappt es nicht.
mein code:
define ntfy_alex_unifi_presence notify unifi:iPhone7Plus_last_seen:.* { if (time() - time_str2num($EVENT) > 180) { fhem("set rr_Alex abwesend"); } else { fhem("set rr_Alex zuhause"); }}
attr di_alex_unifi_presence room Personen
Nachtrag, ich habs nun mit present probiert und da bekomm ich auch immer nur folgende Fehlermeldung:
Please define di_alex_unifi_presence first Please define di_alex_unifi_presence first Please define di_alex_unifi_presence first Please define di_alex_unifi_presence first Please define di_alex_unifi_presence first Please define di_alex_unifi_presence first Please define di_alex_unifi_presence first Please define di_alex_unifi_presence first Please define di_alex_unifi_presence first
Irgendwie werd ich aus den Wiki Einträgen nicht schlau, dort steht nur
ZitatAnwesenheitserkennung
Üblicherweise: siehe PRESENCE
und unter dem Link steht nur lauter Zeug über Bluetooth, dass ja nichts mit dem Unifi Controller zu tun hat.
Ich habs mal so definiert:
attr unifi userReadings presence {((ReadingsVal("iPhone7Plus","fhem_state","?") eq "connected") ? "present":"absent");;}
das Unifi Device selbst kann ich im FHEM auch nicht aufmachen, da ich so viele devices dort drinnen hab, dass sich der Browser ständig aufhängt :(
Connected Clients: 129
Bekannte Clients: 145
Hallo Alex,
Irgendwie werde ich aus deinem Post nicht richtig schlau, versuche es aber mal mit einer Antwort.
1. Die Fehlermeldungen kommen vermutlich von nicht escapten Zeichen, je nachdem wo und wie du etwas einfügst. Ist eher ein Thema für den Forenbereich Anfängerfragen, da gibt es ähnliches glaube ich öfter und die Helfer kennen die richtigen Fragen.
2. ich komme im Wiki an die Stelle von PRESENCE, an der Unifi beschrieben wird, nichts mit bluetooth.
3. die Anzahl an Readings kannst du mit dem Attribut customClientReadings reduzieren. Für spezielle devices die mehr überwacht werden sollen kann ein Device UnifiClient angelegt werden oder über customClientReadings mehr Readings angezeigt werden.
Viele Grüße,
Dirk
Hallo
danke für deine Antwort, aber vielleicht kannst Du mir noch sagen, wie ich das richtig verknüpfe. Natürlich kann ich das unter Anfängerfragen posten, aber dann werde ich nur wieder aufs Modul verwiesen.
lg
Alex
Was willst du verknüpfen? Und wo editierst du? Ich kann deinen Monitor leider nicht sehen und tappe im dunkeln.
Zitat von: Wuehler am 25 August 2019, 22:21:37
Was willst du verknüpfen? Und wo editierst du? Ich kann deinen Monitor leider nicht sehen und tappe im dunkeln.
Ich hab ein unifi Objekt (das den unifi Controller ausliest) und ein Objekt rr_Alex als Person die eben anwesend oder abwesend gesetzt werden soll.
Wo ich das nun genau definiere ist mir nicht klar, hab auf der Vorseite eh meine Versuche rein geschrieben, aber nichts davon funktioniert. Ich hab hier definitiv die Verknüpfung der beiden Objekte nicht verstanden.
Das Reading dass ich dafür verwende ist iPhone7Plus (last_seen) oder eines der anderen, je nachdem was hier besser funktioniert.
Dann öffne den EventMonitor, warte auf das gewünschte Event und klicke auf modify/create und lass dir das Notify erzeugen.
Anpassen fertig...
https://wiki.fhem.de/wiki/Event_monitor
Hat aber (wie Wühler schon geschrieben hat) nichts mit dem Modul zu tun, sondern sind fhem Basics...
Wie ebenfalls geschrieben gibt es noch das UnifiClient Modul, dort gibt es dann connected/disconnected...
Ob das besser ist: keine Ahnung (mache Anwesenheit über das Presence Modul mit hping3 https://forum.fhem.de/index.php/topic,76342.0.html)
Gruß, Joachim
Zitat von: MadMax-FHEM am 26 August 2019, 10:04:39
Dann öffne den EventMonitor, warte auf das gewünschte Event und klicke auf modify/create und lass dir das Notify erzeugen.
Anpassen fertig...
...
Ob das besser ist: keine Ahnung (mache Anwesenheit über das Presence Modul mit hping3)
Gruß, Joachim
Den EventMonitor muss ich mir mal anschauen, allerdings bei den 600 Zeilen die das Unifi Modul für die Endgeräte erzeugt, finde ich einfach nichts mehr.
Beim hping ist meines wissens nach das Problem, dass die Geräte im Stromsparmodus nicht Pingbar sind, aber weiterhin im WLAN Verbunden. Somit fällt das mal flach.
Hab den Eventmointor offen und da rauschen immer nur 80 Zeilen von den Switches vorbei.
Wenn soviel im Eventmonitor kommt, ist dein fhem doch unnötig belastet: event-on-change-reading etc. mal anschauen...
Oder die von Wühler erwähnten Attribute...
Du kannst auch im Eventmonitor einen Filter setzen...
Gruß, Joachim
Der normale ping ja.
Daher ja dann hping3!
Also bei mir funktioniert es...
Wie in dem verlinkten Thread beschrieben halt 2-stufig...
(wegen Akku)
Das mit dem Unifi reagiert mir zu langsam... ;)
Allerdings wird es langsam echt off-topic und vielleicht Zeit für einen neuen, gezielt passenden Thread...
Oder vorher mal alles was bereits genannt wurde anschauen/lesen/umsetzen...
Gruß, Joachim
Hi Zusammen,
sitze auf einem durchgängigem Unifi System, USG Pro, Unifi Switches und AP.
Alles fein soweit, habe die Präsenzlösung wie folgt aktuell gelöst:
Das sind die Readings die ich aus dem Unifi Modul für Wifi device bekomme (die Zeiten und Datumsangaben habe ich rausgenommen):
iPhone-de-Eimy
disconnected
iPhone-de-Eimy_accesspoint
unknown
2019-09-17 15:26:55
iPhone-de-Eimy_essid
UNDEFINED
iPhone-de-Eimy_hostname
iPhone-de-Eimy
iPhone-de-Eimy_last_seen
iPhone-de-Eimy_snr
8
iPhone-de-Eimy_uptime
2663
Nachdem die option über das connected / disconnected zwar für den Verbindungsaufbau gut und schnell funktioniert hat ist es beim lösen der Verbindung sehr schwankend von 20min- zu Stunden wo es dann teilweise unter wired device auftaucht. Das ist ja immer noch ein ungelöster bug in der Controller Software wenn man das Unifi Forum liest.
Daher habe ich den essid Wert zum Auslesen der Anwesenheit genommen undas funktionert damit recht gut bisher.
Wie habt ihr es gelöst?
define Eimy_Handy PRESENCE event Heimnetzwerk:iPhone-de-Eimy:.disconnected Heimnetzwerk:iPhone-de-Eimy:.connected
attr Eimy_Handy devStateIcon absent:10px-kreis-rot present:10px-kreis-gruen
attr Eimy_Handy room Wohnzimmer
define Eimy_Handy2 PRESENCE event Heimnetzwerk:iPhone-de-Eimy_essid:.UNDEFINED Heimnetzwerk:iPhone-de-Eimy_essid:.INNO
attr Eimy_Handy2 devStateIcon absent:10px-kreis-rot present:10px-kreis-gruen
attr Eimy_Handy2 room Wohnzimmer
Hallo,
ich habe im fhem.log lauter Meldungen vom Unifi Modul, anbei ein paar Beispiele.
readingsUpdate(UnifiController,CCU2_essid,UNDEFINED) missed to call readingsBeginUpdate first.
2019.09.29 17:07:44 1: stacktrace:
2019.09.29 17:07:44 1: main::readingsBulkUpdate called by ./FHEM/74_Unifi.pm (1600)
2019.09.29 17:07:44 1: main::Unifi_SetClientReadings called by ./FHEM/74_Unifi.pm (1471)
2019.09.29 17:07:44 1: main::Unifi_ProcessUpdate called by ./FHEM/74_Unifi.pm (2493)
2019.09.29 17:07:44 1: main::Unifi_NextUpdateFn called by ./FHEM/74_Unifi.pm (2022)
2019.09.29 17:07:44 1: main::Unifi_GetVoucherList_Receive called by FHEM/HttpUtils.pm (610)
2019.09.29 17:07:44 1: main::__ANON__ called by fhem.pl (747)
2019.09.29 17:07:44 1: readingsUpdate(UnifiController,CCU2_accesspoint,KellerSW) missed to call readingsBeginUpdate first.
2019.09.29 17:07:44 1: stacktrace:
2019.09.29 17:07:44 1: main::readingsBulkUpdate called by ./FHEM/74_Unifi.pm (1601)
2019.09.29 17:07:44 1: main::Unifi_SetClientReadings called by ./FHEM/74_Unifi.pm (1471)
2019.09.29 17:07:44 1: main::Unifi_ProcessUpdate called by ./FHEM/74_Unifi.pm (2493)
2019.09.29 17:07:44 1: main::Unifi_NextUpdateFn called by ./FHEM/74_Unifi.pm (2022)
2019.09.29 17:07:44 1: main::Unifi_GetVoucherList_Receive called by FHEM/HttpUtils.pm (610)
2019.09.29 17:07:44 1: main::__ANON__ called by fhem.pl (747)
set UnifiController clear all habe ich bereits versucht.
Ich habe keine Idee wie die Zustande kommen bzw wie ich das Problem beheben kann.
Gruß Thorsten
Moin,
Ich habe mal in den Code geschaut und dort nichtsgesehen, wie das passieren könnte. Hast du die aktuelle Version vom Modul? Was zeigt das internal Version an? Bitte mal verbose auf 5 stellen und das Log posten (wird recht viel).
Viele Grüße,
Dirk
Moin Dirk,
das Log wird wirklich groß ;)
Version ist 3.4.0
Viele Grüße
Thorsten
Hallos Thorsten,
konnte mir das Log gerade runterladen, du kannst den Anhang wieder löschen. Leider hatte ich noch nicht so viel Zeit mir das anzusehen, und kann mir das Problem nach erstem schnellen Blick nicht erklären.
Könntest du dir die Moduldatei aus dem SVN (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/74_Unifi.pm) runterladen, ins FHEM-Verzeichnis kopieren (alte Datei ersetzen) und dann ein reload 74_Unifi.pm durchführen.
Vielleicht ist die Datei irgendwie verändert worden.
Viele Grüße,
Dirk
Hallo Dirk,
Version aus dem SVN ist drauf, leider ohne Änderung.
Viele Grüße
Thorsten
Hi Thorsten,
ich tappe da ein wenig im Dunklen, warum das bei dir einen Fehler gibt und bei mir nicht.
Im Anhang eine leicht modifizierte Version mit einer Fix-Idee plus mehr Logausgaben. Bitte mal einspielenund falls es nicht funktioniert mir wieder ein Log bereitstellen.
Viele Grüße,
Dirk
Hallo Dirk,
der Fehler ist leider immer noch da, anbei ein Log Auszug:
2019.10.05 16:15:40 5: UnifiController (Unifi_ProcessUpdate) - 2. updateTime: 1570284940.81691
2019.10.05 16:15:40 5: UnifiController (Unifi_SetHealthReadings) - executed.
2019.10.05 16:15:40 5: UnifiController (Unifi_SetClientReadings) - executed.
2019.10.05 16:15:40 5: UnifiController (Unifi_SetClientReadings) - 3. updateTime: 1570284940.81691
2019.10.05 16:15:40 5: UnifiController (Unifi_SetClientReadings) - 4. updateTime: 1570284940.81691
2019.10.05 16:15:40 5: UnifiController (Unifi_SetClientReadings) - 5. updateTime: 1570284940.81691
2019.10.05 16:15:40 5: UnifiController (Unifi_SetClientReadings) - Dispatch: amazon-d0eb2d936
2019.10.05 16:15:40 5: UnifiController: dispatch UnifiClient_amazon-d0eb2d936{"tx_retries":0,"network":"LAN","satisfaction":100,"first_seen":1566844555,"dev_id":373,"_f_uptime":"11d 1h 10m 57s","_f_usergroup_name":"Default","_f_first_seen":"2019-08-26 20:35:55","qos_policy_applied":true,"dev_family":3,"dev_vendor":97,"_id":"5d64268b4fa78c08fb74dad7","sw_mac":"fc:ec:da:40:2f:14","_f_last_seen_by_usw":"2019-10-05 16:15:32","sw_depth":2,"site_id":"5b198d74bbdd7b0fd453e5f7","hostname":"amazon-d0eb2d936","tx_packets":10489947,"os_name":57,"accesspoint":"Dachboden","rx_bytes-r":0,"dev_cat":20,"rx_bytes":475922091,"is_guest":false,"wifi_tx_attempts":0,"user_id":"5d64268b4fa78c08fb74dad7","_f_last_seen_by_ugw":"2019-10-05 16:15:04","_last_seen_by_ugw":1570284904,"fhem_clientName":"amazon-d0eb2d936","_f_last_seen_duration":"0d 0h 0m 8s","ip":"192.168.7.156","_f_latest_assoc_time":"2019-10-05 16:14:40","blocked":false,"_f_uptime_by_usw":"9d 7h 41m 20s","_f_essid":"UNDEFINED","fhem_state":"connected","_f_last_seen":"2019-10-05 16:15:32","oui":"Luxshare","tx_bytes":15286678794,"tx_bytes-r":0,"_f_uptime_by_ugw":"0d 0h 0m 24s","os_class":5,"assoc_time":1569330275,"_f_assoc_time":"266d 13h 4m 35s","_uptime_by_usw":805280,"rx_packets":4511500,"uptime":954657,"latest_assoc_time":1570284880,"gw_mac":"fc:ec:da:44:80:b6","mac":"60:6d:3c:16:5c:01","_last_seen_by_usw":1570284932,"sw_port":5,"_is_guest_by_ugw":false,"network_id":"5b198d76bbdd7b0fd453e601","_uptime_by_ugw":24,"bytes-r":0,"is_wired":true,"_is_guest_by_usw":false,"last_seen":1570284932}
2019.10.05 16:15:40 5: UnifiController (UnifiClient_Parse) - executed. UnifiClient: Adress: amazon-d0eb2d936
2019.10.05 16:15:40 5: UnifiController (UnifiClient_Parse) - executed. UnifiClient: message_json: {"tx_retries":0,"network":"LAN","satisfaction":100,"first_seen":1566844555,"dev_id":373,"_f_uptime":"11d 1h 10m 57s","_f_usergroup_name":"Default","_f_first_seen":"2019-08-26 20:35:55","qos_policy_applied":true,"dev_family":3,"dev_vendor":97,"_id":"5d64268b4fa78c08fb74dad7","sw_mac":"fc:ec:da:40:2f:14","_f_last_seen_by_usw":"2019-10-05 16:15:32","sw_depth":2,"site_id":"5b198d74bbdd7b0fd453e5f7","hostname":"amazon-d0eb2d936","tx_packets":10489947,"os_name":57,"accesspoint":"Dachboden","rx_bytes-r":0,"dev_cat":20,"rx_bytes":475922091,"is_guest":false,"wifi_tx_attempts":0,"user_id":"5d64268b4fa78c08fb74dad7","_f_last_seen_by_ugw":"2019-10-05 16:15:04","_last_seen_by_ugw":1570284904,"fhem_clientName":"amazon-d0eb2d936","_f_last_seen_duration":"0d 0h 0m 8s","ip":"192.168.7.156","_f_latest_assoc_time":"2019-10-05 16:14:40","blocked":false,"_f_uptime_by_usw":"9d 7h 41m 20s","_f_essid":"UNDEFINED","fhem_state":"connected","_f_last_seen":"2019-10-05 16:15:32","oui":"Luxshare","tx_bytes":15286678794,"tx_bytes-r":0,"_f_uptime_by_ugw":"0d 0h 0m 24s","os_class":5,"assoc_time":1569330275,"_f_assoc_time":"266d 13h 4m 35s","_uptime_by_usw":805280,"rx_packets":4511500,"uptime":954657,"latest_assoc_time":1570284880,"gw_mac":"fc:ec:da:44:80:b6","mac":"60:6d:3c:16:5c:01","_last_seen_by_usw":1570284932,"sw_port":5,"_is_guest_by_ugw":false,"network_id":"5b198d76bbdd7b0fd453e601","_uptime_by_ugw":24,"bytes-r":0,"is_wired":true,"_is_guest_by_usw":false,"last_seen":1570284932}
2019.10.05 16:15:40 4: UnifiController (UnifiClient_Parse) - return: UNDEFINED UnifiClient_amazon-d0eb2d936 UnifiClient amazon-d0eb2d936
2019.10.05 16:15:40 5: UnifiController (Unifi_SetClientReadings) - 6. updateTime:
2019.10.05 16:15:40 5: UnifiController (Unifi_SetClientReadings) - 4. updateTime:
2019.10.05 16:15:40 1: readingsUpdate(UnifiController,medianas,connected) missed to call readingsBeginUpdate first.
2019.10.05 16:15:40 1: stacktrace:
2019.10.05 16:15:40 1: main::readingsBulkUpdate called by ./FHEM/74_Unifi.pm (1582)
2019.10.05 16:15:40 1: main::Unifi_SetClientReadings called by ./FHEM/74_Unifi.pm (1473)
2019.10.05 16:15:40 1: main::Unifi_ProcessUpdate called by ./FHEM/74_Unifi.pm (2501)
2019.10.05 16:15:40 1: main::Unifi_NextUpdateFn called by ./FHEM/74_Unifi.pm (1026)
2019.10.05 16:15:40 1: main::Unifi_GetClients_Receive called by FHEM/HttpUtils.pm (610)
2019.10.05 16:15:40 1: main::__ANON__ called by fhem.pl (747)
2019.10.05 16:15:40 1: readingsUpdate(UnifiController,.medianas_mac,00:80:5a:52:f8:c0) missed to call readingsBeginUpdate first.
2019.10.05 16:15:40 1: stacktrace:
2019.10.05 16:15:40 1: main::readingsBulkUpdate called by ./FHEM/74_Unifi.pm (1586)
2019.10.05 16:15:40 1: main::Unifi_SetClientReadings called by ./FHEM/74_Unifi.pm (1473)
2019.10.05 16:15:40 1: main::Unifi_ProcessUpdate called by ./FHEM/74_Unifi.pm (2501)
2019.10.05 16:15:40 1: main::Unifi_NextUpdateFn called by ./FHEM/74_Unifi.pm (1026)
2019.10.05 16:15:40 1: main::Unifi_GetClients_Receive called by FHEM/HttpUtils.pm (610)
2019.10.05 16:15:40 1: main::__ANON__ called by fhem.pl (747)
2019.10.05 16:15:40 1: readingsUpdate(UnifiController,medianas_hostname,medianas) missed to call readingsBeginUpdate first.
2019.10.05 16:15:40 1: stacktrace:
2019.10.05 16:15:40 1: main::readingsBulkUpdate called by ./FHEM/74_Unifi.pm (1599)
2019.10.05 16:15:40 1: main::Unifi_SetClientReadings called by ./FHEM/74_Unifi.pm (1473)
2019.10.05 16:15:40 1: main::Unifi_ProcessUpdate called by ./FHEM/74_Unifi.pm (2501)
2019.10.05 16:15:40 1: main::Unifi_NextUpdateFn called by ./FHEM/74_Unifi.pm (1026)
2019.10.05 16:15:40 1: main::Unifi_GetClients_Receive called by FHEM/HttpUtils.pm (610)
2019.10.05 16:15:40 1: main::__ANON__ called by fhem.pl (747)
2019.10.05 16:15:40 1: readingsUpdate(UnifiController,medianas_last_seen,2019-10-05 16:15:13) missed to call readingsBeginUpdate first.
2019.10.05 16:15:40 1: stacktrace:
2019.10.05 16:15:40 1: main::readingsBulkUpdate called by ./FHEM/74_Unifi.pm (1600)
2019.10.05 16:15:40 1: main::Unifi_SetClientReadings called by ./FHEM/74_Unifi.pm (1473)
2019.10.05 16:15:40 1: main::Unifi_ProcessUpdate called by ./FHEM/74_Unifi.pm (2501)
2019.10.05 16:15:40 1: main::Unifi_NextUpdateFn called by ./FHEM/74_Unifi.pm (1026)
2019.10.05 16:15:40 1: main::Unifi_GetClients_Receive called by FHEM/HttpUtils.pm (610)
2019.10.05 16:15:40 1: main::__ANON__ called by fhem.pl (747)
2019.10.05 16:15:40 1: readingsUpdate(UnifiController,medianas_uptime,953106) missed to call readingsBeginUpdate first.
2019.10.05 16:15:40 1: stacktrace:
2019.10.05 16:15:40 1: main::readingsBulkUpdate called by ./FHEM/74_Unifi.pm (1601)
2019.10.05 16:15:40 1: main::Unifi_SetClientReadings called by ./FHEM/74_Unifi.pm (1473)
2019.10.05 16:15:40 1: main::Unifi_ProcessUpdate called by ./FHEM/74_Unifi.pm (2501)
2019.10.05 16:15:40 1: main::Unifi_NextUpdateFn called by ./FHEM/74_Unifi.pm (1026)
2019.10.05 16:15:40 1: main::Unifi_GetClients_Receive called by FHEM/HttpUtils.pm (610)
2019.10.05 16:15:40 1: main::__ANON__ called by fhem.pl (747)
2019.10.05 16:15:40 1: readingsUpdate(UnifiController,medianas_essid,UNDEFINED) missed to call readingsBeginUpdate first.
2019.10.05 16:15:40 1: stacktrace:
2019.10.05 16:15:40 1: main::readingsBulkUpdate called by ./FHEM/74_Unifi.pm (1604)
2019.10.05 16:15:40 1: main::Unifi_SetClientReadings called by ./FHEM/74_Unifi.pm (1473)
2019.10.05 16:15:40 1: main::Unifi_ProcessUpdate called by ./FHEM/74_Unifi.pm (2501)
2019.10.05 16:15:40 1: main::Unifi_NextUpdateFn called by ./FHEM/74_Unifi.pm (1026)
2019.10.05 16:15:40 1: main::Unifi_GetClients_Receive called by FHEM/HttpUtils.pm (610)
2019.10.05 16:15:40 1: main::__ANON__ called by fhem.pl (747)
2019.10.05 16:15:40 1: readingsUpdate(UnifiController,medianas_accesspoint,KellerSW) missed to call readingsBeginUpdate first.
2019.10.05 16:15:40 1: stacktrace:
2019.10.05 16:15:40 1: main::readingsBulkUpdate called by ./FHEM/74_Unifi.pm (1605)
2019.10.05 16:15:40 1: main::Unifi_SetClientReadings called by ./FHEM/74_Unifi.pm (1473)
2019.10.05 16:15:40 1: main::Unifi_ProcessUpdate called by ./FHEM/74_Unifi.pm (2501)
2019.10.05 16:15:40 1: main::Unifi_NextUpdateFn called by ./FHEM/74_Unifi.pm (1026)
2019.10.05 16:15:40 1: main::Unifi_GetClients_Receive called by FHEM/HttpUtils.pm (610)
2019.10.05 16:15:40 1: main::__ANON__ called by fhem.pl (747)
2019.10.05 16:15:40 5: UnifiController (Unifi_SetClientReadings) - 5. updateTime:
2019.10.05 16:15:40 5: UnifiController (Unifi_SetClientReadings) - Dispatch: medianas
2019.10.05 16:15:40 5: UnifiController: dispatch UnifiClient_medianas{"_f_essid":"UNDEFINED","_f_uptime_by_usw":"0d 11h 59m 24s","_f_latest_assoc_time":"2019-10-05 04:15:50","blocked":false,"ip":"192.168.7.33","_f_uptime_by_ugw":"1d 1h 1m 32s","assoc_time":1569331807,"tx_bytes-r":0,"tx_bytes":479451,"fhem_state":"connected","_f_last_seen":"2019-10-05 16:15:13","oui":"TulipCom","_uptime_by_usw":43164,"rx_packets":19355,"uptime":953106,"_f_assoc_time":"266d 13h 30m 7s","mac":"00:80:5a:52:f8:c0","gw_mac":"fc:ec:da:44:80:b6","latest_assoc_time":1570241750,"usergroup_id":"","wired-rx_bytes":6076864,"_is_guest_by_ugw":false,"sw_port":2,"_last_seen_by_usw":1570284913,"is_wired":true,"bytes-r":0,"_uptime_by_ugw":90092,"network_id":"5b198d76bbdd7b0fd453e601","_is_guest_by_usw":false,"noted":true,"last_seen":1570284913,"wired-rx_packets":27275,"first_seen":1528494236,"satisfaction":100,"tx_retries":0,"network":"LAN","_id":"5b1af89cbbdd7b0fd453e64c","qos_policy_applied":true,"_f_first_seen":"2018-06-08 23:43:56","_f_usergroup_name":"Default","_f_uptime":"11d 0h 45m 6s","wired-tx_bytes":426777499,"wired-tx_packets":2737863,"site_id":"5b198d74bbdd7b0fd453e5f7","_f_last_seen_by_usw":"2019-10-05 16:15:13","sw_mac":"fc:ec:da:4d:f9:91","sw_depth":1,"wired-rx_bytes-r":0,"tx_packets":466,"hostname":"medianas","rx_bytes-r":0,"accesspoint":"KellerSW","wifi_tx_attempts":0,"wired-tx_bytes-r":648,"user_id":"5b1af89cbbdd7b0fd453e64c","is_guest":false,"rx_bytes":2027280,"_f_last_seen_duration":"0d 0h 0m 27s","name":"medianas","_last_seen_by_ugw":1570284904,"fhem_clientName":"medianas","_f_last_seen_by_ugw":"2019-10-05 16:15:04"}
2019.10.05 16:15:40 5: UnifiController (UnifiClient_Parse) - executed. UnifiClient: Adress: medianas
2019.10.05 16:15:40 5: UnifiController (UnifiClient_Parse) - executed. UnifiClient: message_json: {"_f_essid":"UNDEFINED","_f_uptime_by_usw":"0d 11h 59m 24s","_f_latest_assoc_time":"2019-10-05 04:15:50","blocked":false,"ip":"192.168.7.33","_f_uptime_by_ugw":"1d 1h 1m 32s","assoc_time":1569331807,"tx_bytes-r":0,"tx_bytes":479451,"fhem_state":"connected","_f_last_seen":"2019-10-05 16:15:13","oui":"TulipCom","_uptime_by_usw":43164,"rx_packets":19355,"uptime":953106,"_f_assoc_time":"266d 13h 30m 7s","mac":"00:80:5a:52:f8:c0","gw_mac":"fc:ec:da:44:80:b6","latest_assoc_time":1570241750,"usergroup_id":"","wired-rx_bytes":6076864,"_is_guest_by_ugw":false,"sw_port":2,"_last_seen_by_usw":1570284913,"is_wired":true,"bytes-r":0,"_uptime_by_ugw":90092,"network_id":"5b198d76bbdd7b0fd453e601","_is_guest_by_usw":false,"noted":true,"last_seen":1570284913,"wired-rx_packets":27275,"first_seen":1528494236,"satisfaction":100,"tx_retries":0,"network":"LAN","_id":"5b1af89cbbdd7b0fd453e64c","qos_policy_applied":true,"_f_first_seen":"2018-06-08 23:43:56","_f_usergroup_name":"Default","_f_uptime":"11d 0h 45m 6s","wired-tx_bytes":426777499,"wired-tx_packets":2737863,"site_id":"5b198d74bbdd7b0fd453e5f7","_f_last_seen_by_usw":"2019-10-05 16:15:13","sw_mac":"fc:ec:da:4d:f9:91","sw_depth":1,"wired-rx_bytes-r":0,"tx_packets":466,"hostname":"medianas","rx_bytes-r":0,"accesspoint":"KellerSW","wifi_tx_attempts":0,"wired-tx_bytes-r":648,"user_id":"5b1af89cbbdd7b0fd453e64c","is_guest":false,"rx_bytes":2027280,"_f_last_seen_duration":"0d 0h 0m 27s","name":"medianas","_last_seen_by_ugw":1570284904,"fhem_clientName":"medianas","_f_last_seen_by_ugw":"2019-10-05 16:15:04"}
2019.10.05 16:15:40 4: UnifiController (UnifiClient_Parse) - return: UNDEFINED UnifiClient_medianas UnifiClient medianas
2019.10.05 16:15:40 5: UnifiController (Unifi_SetClientReadings) - 6. updateTime:
2019.10.05 16:15:40 5: UnifiController (Unifi_SetClientReadings) - 4. updateTime:
2019.10.05 16:15:40 1: readingsUpdate(UnifiController,BOSCH-WTWH7591-68A40E2D655E,connected) missed to call readingsBeginUpdate first.
2019.10.05 16:15:40 1: stacktrace:
2019.10.05 16:15:40 1: main::readingsBulkUpdate called by ./FHEM/74_Unifi.pm (1582)
2019.10.05 16:15:40 1: main::Unifi_SetClientReadings called by ./FHEM/74_Unifi.pm (1473)
2019.10.05 16:15:40 1: main::Unifi_ProcessUpdate called by ./FHEM/74_Unifi.pm (2501)
2019.10.05 16:15:40 1: main::Unifi_NextUpdateFn called by ./FHEM/74_Unifi.pm (1026)
2019.10.05 16:15:40 1: main::Unifi_GetClients_Receive called by FHEM/HttpUtils.pm (610)
2019.10.05 16:15:40 1: main::__ANON__ called by fhem.pl (747)
2019.10.05 16:15:40 1: readingsUpdate(UnifiController,.BOSCH-WTWH7591-68A40E2D655E_mac,68:a4:0e:2d:65:5e) missed to call readingsBeginUpdate first.
2019.10.05 16:15:40 1: stacktrace:
2019.10.05 16:15:40 1: main::readingsBulkUpdate called by ./FHEM/74_Unifi.pm (1586)
2019.10.05 16:15:40 1: main::Unifi_SetClientReadings called by ./FHEM/74_Unifi.pm (1473)
2019.10.05 16:15:40 1: main::Unifi_ProcessUpdate called by ./FHEM/74_Unifi.pm (2501)
2019.10.05 16:15:40 1: main::Unifi_NextUpdateFn called by ./FHEM/74_Unifi.pm (1026)
2019.10.05 16:15:40 1: main::Unifi_GetClients_Receive called by FHEM/HttpUtils.pm (610)
2019.10.05 16:15:40 1: main::__ANON__ called by fhem.pl (747)
2019.10.05 16:15:40 1: readingsUpdate(UnifiController,BOSCH-WTWH7591-68A40E2D655E_hostname,BOSCH-WTWH7591-68A40E2D655E) missed to call readingsBeginUpdate first.
2019.10.05 16:15:40 1: stacktrace:
2019.10.05 16:15:40 1: main::readingsBulkUpdate called by ./FHEM/74_Unifi.pm (1599)
2019.10.05 16:15:40 1: main::Unifi_SetClientReadings called by ./FHEM/74_Unifi.pm (1473)
2019.10.05 16:15:40 1: main::Unifi_ProcessUpdate called by ./FHEM/74_Unifi.pm (2501)
2019.10.05 16:15:40 1: main::Unifi_NextUpdateFn called by ./FHEM/74_Unifi.pm (1026)
2019.10.05 16:15:40 1: main::Unifi_GetClients_Receive called by FHEM/HttpUtils.pm (610)
2019.10.05 16:15:40 1: main::__ANON__ called by fhem.pl (747)
2019.10.05 16:15:40 1: readingsUpdate(UnifiController,BOSCH-WTWH7591-68A40E2D655E_last_seen,2019-10-05 16:15:39) missed to call readingsBeginUpdate first.
2019.10.05 16:15:40 1: stacktrace:
2019.10.05 16:15:40 1: main::readingsBulkUpdate called by ./FHEM/74_Unifi.pm (1600)
2019.10.05 16:15:40 1: main::Unifi_SetClientReadings called by ./FHEM/74_Unifi.pm (1473)
2019.10.05 16:15:40 1: main::Unifi_ProcessUpdate called by ./FHEM/74_Unifi.pm (2501)
2019.10.05 16:15:40 1: main::Unifi_NextUpdateFn called by ./FHEM/74_Unifi.pm (1026)
2019.10.05 16:15:40 1: main::Unifi_GetClients_Receive called by FHEM/HttpUtils.pm (610)
2019.10.05 16:15:40 1: main::__ANON__ called by fhem.pl (747)
2019.10.05 16:15:40 1: readingsUpdate(UnifiController,BOSCH-WTWH7591-68A40E2D655E_uptime,67605) missed to call readingsBeginUpdate first.
2019.10.05 16:15:40 1: stacktrace:
2019.10.05 16:15:40 1: main::readingsBulkUpdate called by ./FHEM/74_Unifi.pm (1601)
2019.10.05 16:15:40 1: main::Unifi_SetClientReadings called by ./FHEM/74_Unifi.pm (1473)
2019.10.05 16:15:40 1: main::Unifi_ProcessUpdate called by ./FHEM/74_Unifi.pm (2501)
2019.10.05 16:15:40 1: main::Unifi_NextUpdateFn called by ./FHEM/74_Unifi.pm (1026)
2019.10.05 16:15:40 1: main::Unifi_GetClients_Receive called by FHEM/HttpUtils.pm (610)
2019.10.05 16:15:40 1: main::__ANON__ called by fhem.pl (747)
2019.10.05 16:15:40 1: readingsUpdate(UnifiController,BOSCH-WTWH7591-68A40E2D655E_snr,23) missed to call readingsBeginUpdate first.
2019.10.05 16:15:40 1: stacktrace:
2019.10.05 16:15:40 1: main::readingsBulkUpdate called by ./FHEM/74_Unifi.pm (1602)
2019.10.05 16:15:40 1: main::Unifi_SetClientReadings called by ./FHEM/74_Unifi.pm (1473)
2019.10.05 16:15:40 1: main::Unifi_ProcessUpdate called by ./FHEM/74_Unifi.pm (2501)
2019.10.05 16:15:40 1: main::Unifi_NextUpdateFn called by ./FHEM/74_Unifi.pm (1026)
2019.10.05 16:15:40 1: main::Unifi_GetClients_Receive called by FHEM/HttpUtils.pm (610)
2019.10.05 16:15:40 1: main::__ANON__ called by fhem.pl (747)
2019.10.05 16:15:40 1: readingsUpdate(UnifiController,BOSCH-WTWH7591-68A40E2D655E_essid,undwiedernenwlan) missed to call readingsBeginUpdate first.
2019.10.05 16:15:40 1: stacktrace:
2019.10.05 16:15:40 1: main::readingsBulkUpdate called by ./FHEM/74_Unifi.pm (1604)
2019.10.05 16:15:40 1: main::Unifi_SetClientReadings called by ./FHEM/74_Unifi.pm (1473)
2019.10.05 16:15:40 1: main::Unifi_ProcessUpdate called by ./FHEM/74_Unifi.pm (2501)
2019.10.05 16:15:40 1: main::Unifi_NextUpdateFn called by ./FHEM/74_Unifi.pm (1026)
2019.10.05 16:15:40 1: main::Unifi_GetClients_Receive called by FHEM/HttpUtils.pm (610)
2019.10.05 16:15:40 1: main::__ANON__ called by fhem.pl (747)
2019.10.05 16:15:40 1: readingsUpdate(UnifiController,BOSCH-WTWH7591-68A40E2D655E_accesspoint,DachgeschossAP) missed to call readingsBeginUpdate first.
2019.10.05 16:15:40 1: stacktrace:
2019.10.05 16:15:40 1: main::readingsBulkUpdate called by ./FHEM/74_Unifi.pm (1605)
2019.10.05 16:15:40 1: main::Unifi_SetClientReadings called by ./FHEM/74_Unifi.pm (1473)
2019.10.05 16:15:40 1: main::Unifi_ProcessUpdate called by ./FHEM/74_Unifi.pm (2501)
2019.10.05 16:15:40 1: main::Unifi_NextUpdateFn called by ./FHEM/74_Unifi.pm (1026)
2019.10.05 16:15:40 1: main::Unifi_GetClients_Receive called by FHEM/HttpUtils.pm (610)
2019.10.05 16:15:40 1: main::__ANON__ called by fhem.pl (747)
2019.10.05 16:15:40 5: UnifiController (Unifi_SetClientReadings) - 5. updateTime:
2019.10.05 16:15:40 5: UnifiController (Unifi_SetClientReadings) - Dispatch: BOSCH-WTWH7591-68A40E2D655E
2019.10.05 16:15:40 5: UnifiController: dispatch UnifiClient_BOSCH-WTWH7591-68A40E2D655E{"_id":"5d658c3a4fa78c08fb7fb2a5","qos_policy_applied":true,"_f_first_seen":"2019-08-27 22:02:02","signal":-73,"rx_rate":52000,"is_11r":false,"essid":"undwiedernenwlan","first_seen":1566936122,"satisfaction":98,"channel":6,"network":"LAN","_f_dhcpend_time":"0d 0h 0m 0s","idletime":20,"accesspoint":"DachgeschossAP","_uptime_by_uap":19085,"rssi":23,"tx_packets":3407,"_f_last_seen_by_uap":"2019-10-05 16:15:39","hostname":"BOSCH-WTWH7591-68A40E2D655E","_f_last_seen_by_ugw":"2019-10-05 16:15:04","user_id":"5d658c3a4fa78c08fb7fb2a5","wifi_tx_attempts":7550,"rx_bytes":525515,"ap_mac":"fc:ec:da:16:f9:22","fhem_state":"connected","oui":"BshHausg","_f_last_seen":"2019-10-05 16:15:39","_f_essid":"undwiedernenwlan","_f_latest_assoc_time":"2019-10-05 10:57:34","gw_mac":"fc:ec:da:44:80:b6","latest_assoc_time":1570265854,"_f_assoc_time":"276d 19h 28m 54s","bytes-r":14,"_is_guest_by_ugw":false,"bssid":"fc:ec:da:17:f9:22","radio_proto":"ng","vlan":0,"_f_uptime":"0d 18h 46m 45s","_f_usergroup_name":"Default","tx_retries":4149,"site_id":"5b198d74bbdd7b0fd453e5f7","_is_guest_by_uap":false,"rx_bytes-r":10,"ccq":955,"tx_power":34,"tx_rate":65000,"_f_last_seen_duration":"0d 0h 0m 1s","fhem_clientName":"BOSCH-WTWH7591-68A40E2D655E","_last_seen_by_ugw":1570284904,"anomalies":0,"dhcpend_time":0,"_f_uptime_by_uap":"0d 5h 18m 5s","is_guest":false,"assoc_time":1570217334,"_f_uptime_by_ugw":"0d 6h 22m 40s","radio":"ng","tx_bytes-r":4,"tx_bytes":210159,"blocked":false,"_last_seen_by_uap":1570284939,"ip":"192.168.7.157","mac":"68:a4:0e:2d:65:5e","powersave_enabled":false,"rx_packets":4196,"uptime":67605,"radio_name":"wifi0","roam_count":2,"is_wired":false,"_uptime_by_ugw":22960,"network_id":"5b198d76bbdd7b0fd453e601","noise":-106,"last_seen":1570284939}
2019.10.05 16:15:40 5: UnifiController (UnifiClient_Parse) - executed. UnifiClient: Adress: BOSCH-WTWH7591-68A40E2D655E
2019.10.05 16:15:40 5: UnifiController (UnifiClient_Parse) - executed. UnifiClient: message_json: {"_id":"5d658c3a4fa78c08fb7fb2a5","qos_policy_applied":true,"_f_first_seen":"2019-08-27 22:02:02","signal":-73,"rx_rate":52000,"is_11r":false,"essid":"undwiedernenwlan","first_seen":1566936122,"satisfaction":98,"channel":6,"network":"LAN","_f_dhcpend_time":"0d 0h 0m 0s","idletime":20,"accesspoint":"DachgeschossAP","_uptime_by_uap":19085,"rssi":23,"tx_packets":3407,"_f_last_seen_by_uap":"2019-10-05 16:15:39","hostname":"BOSCH-WTWH7591-68A40E2D655E","_f_last_seen_by_ugw":"2019-10-05 16:15:04","user_id":"5d658c3a4fa78c08fb7fb2a5","wifi_tx_attempts":7550,"rx_bytes":525515,"ap_mac":"fc:ec:da:16:f9:22","fhem_state":"connected","oui":"BshHausg","_f_last_seen":"2019-10-05 16:15:39","_f_essid":"undwiedernenwlan","_f_latest_assoc_time":"2019-10-05 10:57:34","gw_mac":"fc:ec:da:44:80:b6","latest_assoc_time":1570265854,"_f_assoc_time":"276d 19h 28m 54s","bytes-r":14,"_is_guest_by_ugw":false,"bssid":"fc:ec:da:17:f9:22","radio_proto":"ng","vlan":0,"_f_uptime":"0d 18h 46m 45s","_f_usergroup_name":"Default","tx_retries":4149,"site_id":"5b198d74bbdd7b0fd453e5f7","_is_guest_by_uap":false,"rx_bytes-r":10,"ccq":955,"tx_power":34,"tx_rate":65000,"_f_last_seen_duration":"0d 0h 0m 1s","fhem_clientName":"BOSCH-WTWH7591-68A40E2D655E","_last_seen_by_ugw":1570284904,"anomalies":0,"dhcpend_time":0,"_f_uptime_by_uap":"0d 5h 18m 5s","is_guest":false,"assoc_time":1570217334,"_f_uptime_by_ugw":"0d 6h 22m 40s","radio":"ng","tx_bytes-r":4,"tx_bytes":210159,"blocked":false,"_last_seen_by_uap":1570284939,"ip":"192.168.7.157","mac":"68:a4:0e:2d:65:5e","powersave_enabled":false,"rx_packets":4196,"uptime":67605,"radio_name":"wifi0","roam_count":2,"is_wired":false,"_uptime_by_ugw":22960,"network_id":"5b198d76bbdd7b0fd453e601","noise":-106,"last_seen":1570284939}
2019.10.05 16:15:40 4: UnifiController (UnifiClient_Parse) - return: UNDEFINED UnifiClient_BOSCH-WTWH7591-68A40E2D655E UnifiClient BOSCH-WTWH7591-68A40E2D655E
2019.10.05 16:15:40 5: UnifiController (Unifi_SetClientReadings) - 6. updateTime:
2019.10.05 16:15:40 5: UnifiController (Unifi_SetClientReadings) - 4. updateTime:
2019.10.05 16:15:40 1: readingsUpdate(UnifiController,9884E348706A-mysimplelink,connected) missed to call readingsBeginUpdate first.
2019.10.05 16:15:40 1: stacktrace:
Grüße
Thorsten
Zitat von: Pino72 am 17 September 2019, 15:33:43
Nachdem die option über das connected / disconnected zwar für den Verbindungsaufbau gut und schnell funktioniert hat ist es beim lösen der Verbindung sehr schwankend von 20min- zu Stunden wo es dann teilweise unter wired device auftaucht. Das ist ja immer noch ein ungelöster bug in der Controller Software wenn man das Unifi Forum liest.
Daher habe ich den essid Wert zum Auslesen der Anwesenheit genommen undas funktionert damit recht gut bisher.
Wie habt ihr es gelöst?
hi,
habe auch seit einiger zeit gemerkt dass das presence nicht mehr richtig funktioniert. ist wohl derzeit ein problem von unifi selbst.
hier meine anpassung:
defmod presenceMartina PRESENCE function {
(
ReadingsVal('unifi', 'iPhonevnMartina', '') eq 'connected' and
ReadingsVal('unifi', 'iPhonevnMartina_essid', '') ne 'UNDEFINED'
) ? 1:0
}
Zitat von: kirk1h am 06 Oktober 2019, 11:20:49
habe auch seit einiger zeit gemerkt dass das presence nicht mehr richtig funktioniert. ist wohl derzeit ein problem von unifi selbst.
Ich mache das mit UnifiClient-Devices und einem presence-Userreading (wie im Wiki (https://wiki.fhem.de/wiki/UnifiClient) beschrieben):
attr <UnifiClientName> userReadings presence {((ReadingsVal("$name","is_wired","?") eq "true") ? "absent" : ((ReadingsVal("$name","fhem_state","?") eq "connected") ? "present":"absent"));;}
Das "absent" kommt dabei recht gleichbleibend nach ca. 5 Minuten.
mal ne "Blöde" Frage :-)
Es gab mal das Reading für die WiFi Auslastung getrennt für 2,4 und 5GHz ...
wurden die wieder rausgenommen?
Und die CPU Auslastung der Access Points hat noch nen "," als Dezimaltrenner - kann man das noch ändern?
Hallo,
nutze das Unifi Modul, wobei ich an der Stelle "nur" lesend zugreifen möchte (auf dem Cloud Key ist dafür extra ein Nutzer "device_presence" eingerichtet) um die Präsenz von Mobiltelfonen (für "kurze" An-/abwesenheit) und Tablets (wenn die auch weg sind, dann ist Urlaub angesagt/länger weg) zu bestimmen. Das funktioniert bis auf ein paar sporadische Fehler/Hänger auch ganz gut, wobei ich an der Stelle das Modul PRESENCE und RESIDENTS/ROOMMATE nutze.
Was mich an dem Unifi Modul aber extrem stört: es werden immer automatisch auch Devices und Einträge (inkl. Raum) für meine Unifi Switche erstellt. Habe extra schon
ignoreWiredClients = 1
gesetzt. Aber das scheint nur für die Clienst zu gelten, nicht für die LAN Infrastruktur. Wie bekomme ich das reduziert?
Hintergrund: die zugehörigen Logs für die Switche werden echt groß, der extra Raum nervt mich (ok, den könnte man umbiegen auf "hidden") und das die Infos der Switche da offen rumstehen ist auch nicht ok. Kurzum: wie kann ich "nur" das Unifi Modul (lesend) nutzen? Sobald ich Autocreate anmache, nagelt er mir auch immer wieder alles voll...
Gruß, Robert
Du kannst doch die Switche in jeden beliebigen Raum packen und die Filelogs dafür einfach entfernen. So habe ich das zumindest umgesetzt.
Gruß Hoppel
Im Modul autocreate gibt es das Attribut ignoreTypes. Bitte mal ausprobieren um keine Switch-Devices anlegen zu lassen.
Hallo,
es "freut" mich ja zu hören, dass ich damit nicht alleine bin und sich auch schon Leute vor mir darüber geärgert haben...
Habe nun zuerst die Logs gelöscht, dann im autocreate einen Filter draufgesetzt (kannte das gar nicht) und zum Schluss die Teile per Hand gelöscht. Ärgerlich an der Sache war nur, dass ich alle 7 Switche komplett mit Namen angeben musste (liegt aber auch an meiner Namensgebung) da kein RegExp passte, aber FHEM sind längere Zeilen ja egal ;-) Und ändern werde ich die Switche auch nicht alle paar Tage...
Evtl. schaue ich mir das Modul mal genauer an und reduziere es auf die für Presence nötigen Funktionen, also nur den Status bestimmter WLAN Geräte anzeigen (in der Art: gib den Namen an und Modul liefert connect Status). Denn per FHEM schreibend im WLAN rumfummeln kommt für mich nicht in Frage. So richtig glücklich bin ich damit eh noch nicht, denn die Unifi SW selbst klemmt ja auch manchmal und meldet den Satus nicht korrekt (bzw. besser: nagelt ein WLAN Gerät an einen Switch Port/als wired).
Danke und Gruß, Robert
Hallo Robert,
die Themen FileLog und autocreate sind nicht modulspezifisch sondern in FHEM hoffentlich immer gleich durch die Module umgesetzt. Bei Unifi ist dir das anscheinend nur zum ersten Mal über den Weg gelaufen.
Schau dir im UnifiModul mal das Attribut customClientReadings an. Damit kannst du zumindest für die clients die Readings reduzieren buw so spezifizieren wie du sie brauchst und u.a. Das Reading ,,wired" erzeugen lassen, um im Presence auch das zu prüfen.
VG,
Dirk
Hallo Dirk,
danke dir für deine Hilfestellung. Und ja, das ist mir erst jetzt so aufgefallen, danke für deine Geduld.
Habe jetzt ein
attr unifi_controller customClientReadings .:^accesspoint$
attr unifi_controller ignoreWiredClients 1
und dadurch schon mal eine deutliche Reduktion erreicht.
Und dann die eigenltiche Anwesenheitserkennung über
defmod presenceMartina PRESENCE function {
(
ReadingsVal('unifi', 'iPhonevnMartina', '') eq 'connected' and
ReadingsVal('unifi', 'iPhonevnMartina_essid', '') ne 'UNDEFINED'
) ? 1:0
}
Das wollte der Editor zwar alles in einer Zeile haben (hat sich sonst immer über fehlende Klammer beschwert), aber meinetwegen soll er auch das bekommen...
Gruß, Robert
Hi!
Ich hatte heute Morgen einen stattlichen Freeze - exakt 15 Minuten - durch UniFi:
Di 05.11.2019 12:31:09 freezemon s:12:17:34 e:12:31:09 f:815.863 d:fn-ReadFn(WWW_192.168.0.151_52615) tmr-Unifi_DoUpdate(UniFi)
dnsServer in global ist gesetzt.
Patrick
Zitat von: PatrickR am 05 November 2019, 14:37:22
Hi!
Ich hatte heute Morgen einen stattlichen Freeze - exakt 15 Minuten - durch UniFi:
Di 05.11.2019 12:31:09 freezemon s:12:17:34 e:12:31:09 f:815.863 d:fn-ReadFn(WWW_192.168.0.151_52615) tmr-Unifi_DoUpdate(UniFi)
dnsServer in global ist gesetzt.
Patrick
Hmmm, die Informationen sind jetzt ein bisschen spärlich, aber ich versuch es mal.
- Nur weil freezemon unifi als Schuldigen identifiziert hat, muss dem nicht so sein. Was sagt denn das zugehörige Logfile zu dem freeze? Das Thema könnte also auch gut in dem freezemon-Thread aufgehoben sein - dort findet man auch Tipps, wie man freezes identifiziert.
- Bezogen auf unifi: Wie groß ist denn die Installation? Reden wir über 10-15 Geräte oder einige hundert? Auf welcher Hardware läuft der Controller, auf welcher Hardware läuft FHEM? Wifi oder Ethernet?
- War es der erste Freeze dieser Art?
Gruß Tom
@Tratonis:
dein Thema war noch offen, ich verstehe nicht woher das kommt und hatte leider wenig Zeit.
Bitte spiel mal das Modul im Anhang noch mit ein und mach ein "reload 74_UnifiClient.pm".
Danach brauche ich wieder das Log. Ich hoffe dann kann ich den Fehler weiter eingrenzen.
Viele Grüße,
Dirk
Nabend zusammen,
Ich hab mal eine kurze Verständnisfrage zum RSSI-Wert.
Ich kenn die immer mit -Werten wie -60 aber im Modul sind es so grob 50-0.
So wie ich es gesehen habe ist ein hoher RSSI im Modul eine gute Verbindung. Und im 5Ghz Netz geht der RSSI viel tiefer als beim 2.4 bevor die Verbindung abbricht.
Hmmm...
Gruss Maui
Hallo Zusammen,
evtl kann mir jemand von euch helfen:
Habe folgendes Problem seit gestern (Umstellung auf configDB und DBlog. habe ich folgenden Fehler bei den definierten UnifiClients:
configfile: 0\
0\
\
Autosave deactivated
Wird mir auf der FHEM Oberfläche angezeigt.
2019.11.27 02:30:40 5: Cmd: >define Handy UnifiClient Phone-Name<
2019.11.27 02:30:40 5: Loading ./FHEM/74_UnifiClient.pm
2019.11.27 02:30:40 3: UnifiClient_Define - executed. 0
2019.11.27 02:30:40 5: UnifiClient_Define - Adress: Phone-Name
2019.11.27 02:30:40 5: Handy (UnifiClient_DailyReset) - executed.
2019.11.27 02:30:40 5: fhem.cfg line 1653 returned >0<
2019.11.27 02:30:40 5: Cmd: >setuuid ChrisHandy 5dd99bf9-f12f-63b5-d3b0-f034561753e8fcdc<
2019.11.27 02:30:40 5: Cmd: >attr Handy DbLogExclude .*<
2019.11.27 02:30:40 5: Cmd: >attr Handy devStateIcon connected:it_wifi@#00ffa2 disconnected:it_wifi@#9e0000<
2019.11.27 02:30:40 5: Cmd: >attr Handy event-on-change-reading .*<
2019.11.27 02:30:40 5: Cmd: >attr Handy group Netzwerk Clients<
2019.11.27 02:30:40 5: Cmd: >attr Handy icon it_smartphone<
2019.11.27 02:30:40 5: Cmd: >attr Handy room Haus<
Dies ein Auszug aus der Log mit verbose 5
Und jetzt die paar Zeilen aus der FHEM.cfg
attr FileLog_U16PoeSwitch room System->Log
define Handy UnifiClient Phone-Name
setuuid Handy 5dd99bf9-f12f-63b5-d3b0-f034561753e8fcdc
attr Handy DbLogExclude .*
attr Handy devStateIcon connected:it_wifi@#00ffa2 disconnected:it_wifi@#9e0000
attr Handy event-on-change-reading .*
attr Handy group Netzwerk Clients
attr Handy icon it_smartphone
attr Handy room Haus
Habt ihr eine Idee dazu?
LG Christian
Moin,
Habe leider keine Ahnung von configDB und DBLog. Ich denke es wäre das Beste du machst einen neuen Thread im Bereich configDB auf (siehe Maintainer.txt). Dann gerne pm mit dem Thread an mich, damit ich die Hinweise des Maintainers mitbekomme.
VG,
Diek
Ich habe mit dem Unifi-Modul Performance-Probleme. FHEM lässt sich nicht mehr bedienen. (Freeze?)
Hatte erst 2 neue DOIFs im Fokus. Die waren es nicht.
Habe nun Unifi-Controller auf disable 1 gesetzt und die beiden 48 POE-Switches rausgeworfen.
Jetzt fluppt es wieder.
Ist das ein bekanntes Problem? Falls ja, gibt es Möglichkeiten das Modul trotzdem zu nutzen? Würde gerne die IPhones abfragen und Presence damit aufbauen.
EDIT: Intel-Nuc Proxmox-Container mit i5 und 4 zugeordneten Kernen:
ohne Unifi: 2,4% Prozessorauslastung
mit Unifi: 25% Prozessorauslastung
Moin Gunther,
wie hast du das Unifi-Modul definiert? Konkreter: Wie groß ist das Update-Interval.
Bei großen Unifi-Installationen oder nicht performanten Systemen (vor allem wenn FHEM und Unifi auf dem selben Rechner laufen) kann es passieren, dass ein neues Update (Abfrage aller Informationen) noch nicht beendet ist, wenn das nächste startet. Das schaukelt sich unter Umständen bis zu einem freeze hoch.
VG,
Dirk
Kurz vom Handy:
Nutze CloudKey2 getrennt von einem Nuc I5
Habe Standard-Definition genommen
Standard bedeutet 30 Sekunden-Intervall. Bei 2 x 48 Port-Switches hat du anscheinend einiges im Netz und es dauert evtl. insgesamt mehr als 30 Sekunden. Kannst du mit einem verbose=5 herausbekommen.
Moin Wuehler,
bin leider erst jetzt dazu gekommen das zu testen.
edit: jetzt der richtige Logauszug ;)
2019.12.04 16:16:18 5: UnifiController (UnifiSwitch_Parse) - return: KellerSW
2019.12.04 16:16:18 5: UnifiController (Unifi_GetClientInsights_Send) - executed.
2019.12.04 16:16:18 5: UnifiController (Unifi_GetClientInsights_Receive) - executed.
2019.12.04 16:16:18 5: UnifiController (Unifi_GetClientInsights_Receive) - state:'ok'
2019.12.04 16:16:18 5: UnifiController (Unifi_ProcessUpdate) - executed after 0.2084 seconds.
2019.12.04 16:16:18 5: UnifiController (Unifi_ProcessUpdate) - 1. updateTime:
2019.12.04 16:16:18 5: UnifiController (Unifi_ProcessUpdate) - 2. updateTime: 1575472578.21298
2019.12.04 16:16:18 5: UnifiController (Unifi_SetHealthReadings) - executed.
2019.12.04 16:16:18 5: UnifiController (Unifi_SetClientReadings) - executed.
2019.12.04 16:16:18 5: UnifiController (Unifi_SetClientReadings) - 3. updateTime: 1575472578.21298
2019.12.04 16:16:18 5: UnifiController (Unifi_SetClientReadings) - 4. updateTime: 1575472578.21298
2019.12.04 16:16:18 5: UnifiController (Unifi_SetClientReadings) - 5. updateTime: 1575472578.21298
2019.12.04 16:16:18 5: UnifiController (Unifi_SetClientReadings) - Dispatch: OEQ0329341
2019.12.04 16:16:18 5: UnifiController: dispatch UnifiClient_OEQ0329341{"tx_bytes":426294,"_id":"5c1cd4e643a0dc0981c506e0","user_id":"5c1cd4e643a0dc0981c506e0","mac":"00:1a:22:0a:e0:63","_f_usergroup_name":"Default","uptime":9793329,"bytes-r":0,"wired-tx_packets":8471915,"wired-tx_bytes":1191463625,"network_id":"5b198d76bbdd7b0fd453e601","hostname":"OEQ0329341","accesspoint":"KellerSW","sw_depth":1,"tx_retries":0,"_uptime_by_ugw":3218204,"is_wired":true,"fhem_state":"connected","satisfaction":90,"wired-rx_bytes-r":135,"_last_seen_by_usw":1575472549,"wired-rx_bytes":201714660,"is_guest":false,"_f_last_seen_duration":"0d 0h 0m 7s","_is_guest_by_usw":false,"gw_mac":"fc:ec:da:44:80:b6","tx_packets":9907,"_uptime_by_usw":3458440,"site_id":"5b198d74bbdd7b0fd453e5f7","_f_first_seen":"2018-12-21 12:56:22","_f_last_seen":"2019-12-04 16:16:11","_f_last_seen_by_ugw":"2019-12-04 16:16:11","blocked":false,"ip":"192.168.7.131","assoc_time":1565679242,"rx_packets":63941,"_f_last_seen_by_usw":"2019-12-04 16:15:49","network":"LAN","_last_seen_by_ugw":1575472571,"_f_uptime":"113d 8h 22m 9s","noted":false,"latest_assoc_time":1572254367,"_is_guest_by_ugw":false,"wifi_tx_attempts":0,"rx_bytes-r":0,"sw_mac":"fc:ec:da:4d:f9:91","fhem_clientName":"OEQ0329341","tx_bytes-r":0,"wired-rx_packets":3123482,"oui":"Eq-3Entw","_f_latest_assoc_time":"2019-10-28 10:19:27","last_seen":1575472571,"use_fixedip":true,"_f_essid":"UNDEFINED","first_seen":1545393382,"qos_policy_applied":true,"wired-tx_bytes-r":886,"fixed_ip":"192.168.7.131","_f_uptime_by_usw":"40d 0h 40m 40s","_f_uptime_by_ugw":"37d 5h 56m 44s","sw_port":11,"_f_assoc_time":"224d 6h 54m 2s","rx_bytes":2950874}
2019.12.04 16:16:18 5: UnifiController (UnifiClient_Parse) - executed. UnifiClient: Adress: OEQ0329341
2019.12.04 16:16:18 5: UnifiController (UnifiClient_Parse) - executed. UnifiClient: message_json: {"tx_bytes":426294,"_id":"5c1cd4e643a0dc0981c506e0","user_id":"5c1cd4e643a0dc0981c506e0","mac":"00:1a:22:0a:e0:63","_f_usergroup_name":"Default","uptime":9793329,"bytes-r":0,"wired-tx_packets":8471915,"wired-tx_bytes":1191463625,"network_id":"5b198d76bbdd7b0fd453e601","hostname":"OEQ0329341","accesspoint":"KellerSW","sw_depth":1,"tx_retries":0,"_uptime_by_ugw":3218204,"is_wired":true,"fhem_state":"connected","satisfaction":90,"wired-rx_bytes-r":135,"_last_seen_by_usw":1575472549,"wired-rx_bytes":201714660,"is_guest":false,"_f_last_seen_duration":"0d 0h 0m 7s","_is_guest_by_usw":false,"gw_mac":"fc:ec:da:44:80:b6","tx_packets":9907,"_uptime_by_usw":3458440,"site_id":"5b198d74bbdd7b0fd453e5f7","_f_first_seen":"2018-12-21 12:56:22","_f_last_seen":"2019-12-04 16:16:11","_f_last_seen_by_ugw":"2019-12-04 16:16:11","blocked":false,"ip":"192.168.7.131","assoc_time":1565679242,"rx_packets":63941,"_f_last_seen_by_usw":"2019-12-04 16:15:49","network":"LAN","_last_seen_by_ugw":1575472571,"_f_uptime":"113d 8h 22m 9s","noted":false,"latest_assoc_time":1572254367,"_is_guest_by_ugw":false,"wifi_tx_attempts":0,"rx_bytes-r":0,"sw_mac":"fc:ec:da:4d:f9:91","fhem_clientName":"OEQ0329341","tx_bytes-r":0,"wired-rx_packets":3123482,"oui":"Eq-3Entw","_f_latest_assoc_time":"2019-10-28 10:19:27","last_seen":1575472571,"use_fixedip":true,"_f_essid":"UNDEFINED","first_seen":1545393382,"qos_policy_applied":true,"wired-tx_bytes-r":886,"fixed_ip":"192.168.7.131","_f_uptime_by_usw":"40d 0h 40m 40s","_f_uptime_by_ugw":"37d 5h 56m 44s","sw_port":11,"_f_assoc_time":"224d 6h 54m 2s","rx_bytes":2950874}
2019.12.04 16:16:18 5: UnifiController (Unifi_SetClientReadings) - 6. updateTime:
2019.12.04 16:16:18 5: UnifiController (Unifi_SetClientReadings) - 4. updateTime:
2019.12.04 16:16:18 5: UnifiController (Unifi_SetClientReadings) - Client 'Galaxy-Note10' previously connected is now disconnected.
2019.12.04 16:16:18 5: UnifiController (Unifi_SetClientReadings) - 5. updateTime:
2019.12.04 16:16:18 5: UnifiController (Unifi_SetClientReadings) - Dispatch: Galaxy-Note10
2019.12.04 16:16:18 5: UnifiController: dispatch UnifiClient_Galaxy-Note10{"rx_bytes":0,"_f_assoc_time":"337d 13h 33m 10s","dev_id_override":392,"_f_uptime_by_ugw":"0d 0h 0m 11s","last_seen":1575466459,"fingerprint_override":true,"_f_essid":"UNDEFINED","first_seen":1567093878,"qos_policy_applied":true,"rx_bytes-r":0,"wifi_tx_attempts":0,"_is_guest_by_ugw":false,"_f_latest_assoc_time":"2019-12-04 14:34:08","oui":"SamsungE","tx_bytes-r":0,"fhem_clientName":"Galaxy-Note10","network":"LAN","rx_packets":0,"assoc_time":1575466390,"latest_assoc_time":1575466448,"noted":false,"_f_uptime":"0d 0h 1m 9s","_last_seen_by_ugw":1575466459,"tx_packets":0,"gw_mac":"fc:ec:da:44:80:b6","_f_last_seen_by_ugw":"2019-12-04 14:34:19","ip":"192.168.7.158","_f_last_seen":"2019-12-04 14:34:19","blocked":false,"_f_first_seen":"2019-08-29 17:51:18","site_id":"5b198d74bbdd7b0fd453e5f7","fhem_state":"disconnected","_uptime_by_ugw":11,"is_wired":true,"_f_last_seen_duration":"0d 1h 41m 59s","is_guest":false,"network_id":"5b198d76bbdd7b0fd453e601","tx_retries":0,"usergroup_id":"5b198d76bbdd7b0fd453e602","hostname":"Galaxy-Note10","accesspoint":"unknown","user_id":"5d67f4764fa78c08fb92f827","mac":"a8:db:03:fd:fd:6f","_id":"5d67f4764fa78c08fb92f827","tx_bytes":0,"bytes-r":0,"_f_usergroup_name":"Default","uptime":69}
2019.12.04 16:16:18 5: UnifiController (UnifiClient_Parse) - executed. UnifiClient: Adress: Galaxy-Note10
2019.12.04 16:16:18 5: UnifiController (UnifiClient_Parse) - executed. UnifiClient: message_json: {"rx_bytes":0,"_f_assoc_time":"337d 13h 33m 10s","dev_id_override":392,"_f_uptime_by_ugw":"0d 0h 0m 11s","last_seen":1575466459,"fingerprint_override":true,"_f_essid":"UNDEFINED","first_seen":1567093878,"qos_policy_applied":true,"rx_bytes-r":0,"wifi_tx_attempts":0,"_is_guest_by_ugw":false,"_f_latest_assoc_time":"2019-12-04 14:34:08","oui":"SamsungE","tx_bytes-r":0,"fhem_clientName":"Galaxy-Note10","network":"LAN","rx_packets":0,"assoc_time":1575466390,"latest_assoc_time":1575466448,"noted":false,"_f_uptime":"0d 0h 1m 9s","_last_seen_by_ugw":1575466459,"tx_packets":0,"gw_mac":"fc:ec:da:44:80:b6","_f_last_seen_by_ugw":"2019-12-04 14:34:19","ip":"192.168.7.158","_f_last_seen":"2019-12-04 14:34:19","blocked":false,"_f_first_seen":"2019-08-29 17:51:18","site_id":"5b198d74bbdd7b0fd453e5f7","fhem_state":"disconnected","_uptime_by_ugw":11,"is_wired":true,"_f_last_seen_duration":"0d 1h 41m 59s","is_guest":false,"network_id":"5b198d76bbdd7b0fd453e601","tx_retries":0,"usergroup_id":"5b198d76bbdd7b0fd453e602","hostname":"Galaxy-Note10","accesspoint":"unknown","user_id":"5d67f4764fa78c08fb92f827","mac":"a8:db:03:fd:fd:6f","_id":"5d67f4764fa78c08fb92f827","tx_bytes":0,"bytes-r":0,"_f_usergroup_name":"Default","uptime":69}
2019.12.04 16:16:18 5: UnifiController (UnifiClient_Parse) - return: Thorsten_Telefon_UC
2019.12.04 16:16:18 5: UnifiController (Unifi_SetClientReadings) - 6. updateTime:
2019.12.04 16:16:18 5: UnifiController (Unifi_SetClientReadings) - 4. updateTime:
2019.12.04 16:16:18 5: UnifiController (Unifi_SetClientReadings) - 5. updateTime:
Ich hoffe der Auszug reicht.
VG
Thorsten
Hallo Thorsten,
dein erster Logauszug hatte auch LogInfos aus dem UnifiClient (5a/b. updateTime), die fehlen mir jetzt. Wenn ich mch richtig erinnere, war die updateTime datin auch leer. D.h. es passiert irgendwo im Dispatch() in der fhem.pl, dass das ReadingsBulkupdate beendet wird. Ich habe da reingeschaut, finde aber nicht, wo das passiert. Vermutlich müssen wir da Rudi mit einbinden.
VG,
Dirk
Zitat von: Wuehler am 28 November 2019, 19:04:17
Standard bedeutet 30 Sekunden-Intervall. Bei 2 x 48 Port-Switches hat du anscheinend einiges im Netz und es dauert evtl. insgesamt mehr als 30 Sekunden. Kannst du mit einem verbose=5 herausbekommen.
Hi Dirk,
danke für Deinen Tipp.
Ich hatte jetzt trotz 180 Sekunden Intervall wieder ein stehendes FHEM. Der WAF leidet ein wenig... :-|
Daher habe ich nun mal verbose 5 gesetzt.
Anbei der letzte Auszug aus dem Gesamtlog. Irgendwie sollten die unten stehenden Zeiten ja kein Problem darstellen, oder?
Hier nur die Zeit-Logs. Kann auch alles posten, aber das wird seeeeeeeeeeehr lang...
2019.12.09 13:48:29 5: unifi_controller (Unifi_ProcessUpdate) - executed after 0.9262 seconds.
2019.12.09 13:48:31 5: unifi_controller (Unifi_ProcessUpdate) - finished after 3.3070 seconds.
Wie kann ich weiter vorgehen? Kann ich irgendwwie alles ausklammern außer die beiden IPhones, die ich für die Anwesenheitserkennung nutzen möchte?
Moin,
das Unifi-Update dauert nur etwas mehr als drei Sekunden, scheint also nicht das Problem zu sein. Zumal die Abfragen ggü. dem Unifi-Controller NonBlocking sind, die fhem.pl also immer mal wieder Zeit bekommt.
Irgendwie vermute ich das eigentliche Problem woanders. Bei mir war es mal ein unterversorgter USB-Verbraucher.
Hast du zufällig auch ein Log zum Zeitpunkt des Freezes?
VG,
Dirk
ne, habe ich leider nicht. Kann im Gesamtlog den Freeze auch nicht genau eingrenzen.
Habe gerade noch in 2 Bereichen (Sonos und komische Fehlermeldungen nachgefragt):
https://forum.fhem.de/index.php/topic,106157.msg1000431.html#msg1000431 (https://forum.fhem.de/index.php/topic,106157.msg1000431.html#msg1000431)
https://forum.fhem.de/index.php/topic,84372.msg1000435.html#msg1000435 (https://forum.fhem.de/index.php/topic,84372.msg1000435.html#msg1000435)
Hallo zusammen,
ich habe ein Reading für jedes Gerät, welches im UniFi-Controller angemeldet ist, welches die Unix-Zeit angibt, wann es zuletzt "gesehen" wurde.
Die Readings lauten Geraetxyz_last_seen, das Reading hat dann z.B. den Wert 1579435394, es dürfte sich also um die Unix-Zeit handeln.
Man könnte jetzt bei allen Readings die Unix-Zeit in eine lesbare Zeit umwandeln, dann müsste man es aber auch ständig bei neuen Geräten machen.
Gibt es eine Möglichkeit alle Readings Geraetxyz_last_seen im Format YYYY-MM-DD hh:mm auszugeben, ohne das für jedes einzelne Reading quasi händisch zu erledigen?
Viele Grüße Gisbert
Hallo zusammen,
Hilfe durch Selbsthilfe.
Es gibt das Reading _f_last_seen, welches eine lesbare Zeit ausgibt.
Damit dürfte meine Frage beantwortet sein.
Viele Grüße Gisbert
Korrekt. Aber um das Reading zu bekommen musst du das pber das Attribut customClientReadings konfigurieren (siehe commandref). Das last_seen im Unixformat ist noch aus den ersten Modulversionen und so drin geblieben, damit es Abeärtskompatibel ist und nicht bestehende FHEM-Installationen stört. Über customClientReadings kannst du die normalerweise genau das anzeigen lassen was dir hilft. Bei Besarf kannst du auch ein Device UnifiClient anlegen.
VG,
Dirk
Moin Dirk,
ich bastele grad (mal wieder) am Entfernen von Readings von disconnected Devices.
Wenn ich sie per deletereading entferne, kommen die Readings im nächsten Update wieder rein.
Hast du da etwas angepasst?
Gruß
Maui
Hi Maui,
Nein, habe lange nichts geändert im Modul. Worum geht es genau? Hast du ein List deines Devices?
VG,
Dirk
Moin Dirk, was brauchst du denn genau? Will zb nicht crypt und auch nicht alle mac Adressen im Forum stehen haben.
Müsstest du aber denke ich relativ leicht nachbauen können, indem du einfach die Readings eines disconnected Devices löscht in fhem und auf das Update wartest
Internals:
DEF 192.168.1.198 8443 crypt:xxxx crypt:xxx 10
FUUID 5cde9019-f33f-f22a-b901-d10927df52aa2d9b
LASTInputDev myunifi
MSGCNT 416285
NAME myunifi
NOTIFYDEV global
NR 61
NTFY_ORDER 50-myunifi
STATE connected
TYPE Unifi
UC_VERSION 5.12.35
VERSION 3.4.0
myunifi_MSGCNT 416285
myunifi_TIME 2020-01-21 08:25:57
OLDREADINGS:
READINGS:
.....
2020-01-21 08:25:57 3D_Drucker disconnected
2020-01-21 08:25:57 3D_Drucker__f_last_seen_duration 0d 2h 19m 28s
2020-01-21 08:25:57 3D_Drucker_last_seen 1579583189
2020-01-21 08:25:57 3D_Drucker_mac dc:4f:22:ea:1a:4e
......
Attributes:
customClientReadings .:^mac$|^ip$|^_f_last_seen_duration$|^last_seen$|^rssi$|^essid$
event-on-change-reading .*
room 9_Tech
Ich habe im groben den Code genommen, den du selbst mal gepostet hast, um die Readings zu löschen. Beim nächsten update sind diese dann aber fröhlich wieder da.
sub OldReadings_Unifi()
{
my $hash = $defs{'myunifi'};
my $readings = $hash->{READINGS};
foreach my $a ( keys %{$readings} )
{
if ($a =~ m/_last_seen$/)
{
my $differenz = time() - ReadingsVal('myunifi',$a,"");
if ($differenz > 3600)
{
my $dev_name = substr($a,0,length($a)-10);
Log3( 'myunifi', 0,"Reading : $dev_name $differenz" );
fhem("deletereading myunifi $dev_name ");
fhem("deletereading myunifi ".$dev_name."_.*");
}
}
}
}
Moin,
Es werden die Readings angezeigt (sofern vorhanden), die du bei customClientReadings anforderst. Ein disconnectedClient ist immer noch ein Client und wird vom UnifiController mitgesendet.
VG, Dirk
Moin Dirk,
jetzt habe ich aber grad einen Knoten im Kopf. ::)
Vielleicht kannst du ihn ja lösen.
Wir hatten hier (damals) ab Post #920 über das Thema gesprochen und du in Post #931 ein Notify reingestellt.
So wie ich dich heute verstehe, kann das gar nicht funktionieren?!
Irgendwann müsste der Unifi Controller doch die Clients vergessen...
Gruß und Danke
Maui
Moin Dirk,
ich habe mir ein USG zugelegt, wobei das USG die Einwahl ins Internet übernimmt. In den Readings des Unifi-Moduls habe ich gesehen, dass auch drei neue Readings hinzugefügt wurden für Clients, Locate und State.
Wenn die Internetverbindung getrennt wird bleibt der State aber weiterhin auf ok, obwohl im Controller das WAN Interface des USG als disconnected angezeigt wird.
Gibt es eine Möglichkeit den WAN Status auch in das Modul zu integrieren oder teilt das der Controller gar nicht mit?
Gruß
Wolle
@Maui: vor einiger Zeit gab es mal ein Update, in dem auch die disconnected clients aus der Historie ausgelesen werden. Vermutlich geht dein Script seit dem nicht mehr.
@Wolle: Es gibt das Reading -UC_wan_ip. Vielleicht kannst du das nutzen.
Zitat von: Wuehler am 30 Januar 2020, 08:44:55
Es gibt das Reading -UC_wan_ip. Vielleicht kannst du das nutzen.
Leider bleibt das Reading trotz Verlust der Internetverbindung auf der alten IP Adresse stehen, bis eine neue WAN IP Adresse zugewiesen wird. Erst dann wird das Reading aktualisiert.
Eine zuverlässige Prüfung der Internetverfügbarkeit ist so mit dem Reading wohl leider nicht durchführbar.
Hallo,
ich habe hier eine Unifi Dream Machine. Auf der läuft ein Controller, ein Switch und ein AP.
In der neuesten Software läuft der Controller auf der IP/network also in etwa so.
http://10.10.10.1/network/ und dann site etc.
Kann man das Modul anpassen das es auch mit dem neuen Controller läuft auf der UDM läuft?
Bin auch gern bereit zu testen.
VG
Frank
Hallo,
ich habe das Problem, dass derzeit der Status für einen Client bei mir zwischen dem Unifi Modul und dem Controller auseinanderfällt.
Das Modul in fhem meldet:
iPhone-11-Pro connected 2020-02-03 10:42:57
während der Controller es als disconnected anzeigt.
Ich habe dann mal ein
set unifi updateClient iPhone-11-Pro
versucht. Das gab mit verbose 5 einiges an kB an Logfile, wobei das Interessante für mich ist, dass in dem Logfile zwar Daten von Tonnen an verbundenen Geräten kommen (seit ich einen Unifi Flex habe, werden auch immer alle kabelgebundenen Geräte gezeigt, und das sind eine Menge), aber dieses Gerät (Status derzeit: Disconnected) tauchte darin gar nicht auf.
Dann habe ich weitergeschaut und festgestellt, dass ich, nach Integration des Unifi Flex, das Attribut
attr unifi ignoreWiredClients 1
gesetzt hatte, um die Tonnen an Gerätereadings im unifi-Device wieder loszuwerden, die ich für nichts brauche. Ein
get unifi clientData iPhone-11-Pro
allerdings zeigt dann interessanterweise:
======================================
[...]
is_wired = 1
[...]
======================================
Erfolgt diese Zuordnung durch das FHEM Modul Unifi? Falls ja, gibt es da irgendwo noch was, was man verbessern könnte. Ich bin im Bedarfsfall gerne beim Debuggen behilflich.
Bis dahin hat ein Löschen des Attributes mein Problem gelöst, um für alle WLAN-Clients im Netz Daten zu bekommen.
@fs79: ich vermute, das könnte einfach gehen. Bin aber privat und beruflich gerade sehr eingespannt und komme eher nicht dazu.
@linke Hände: das alles erinnert mich an das übliche Verhalten des Controllers (ohne alles genau durchdacht zu haben). Der sendet einen wifi-Client nach dem disconnect noch 5 Minuten als wired Client mit. Warte also mal etwas länger.
@Wuehler: Um 14:10 Uhr, als ich meine Nachricht schrieb, zeigte das Reading, wie unten geschrieben "last seen 10:42 Uhr" und "connected". Nach dem Löschen des Attributs passte es sofort wieder.
Ich habe das Unifi-Modul schon seit Jahren hier laufen, ich kenne die Verzögerung. :)
Hatte heute auch ein komisches Thema dass der State zwischen fhem modul und controller nicht passte.
Er ging bei einem Client einfach nicht auf connected obwohl der controller connected anzeigte.
Habe jetzt ein "clear all" gemacht und nun ist alles korrekt.
Mal schauen ob es geholfen hat...
Hatte sonst auch noch nie Probleme mit dem Modul außer dieses eine Problem heute.
pOpY
So, habe das mal getest: "is_wired" geht auf 1, wenn das Telefon mit einem AP verbunden ist, der hinter einem Unifi Switch (hier Flex) steht.
Also:
[Controller] -----> [AP] -----> Telefon => is_wired = 0
[Controller] -----> [Switch] ------> [AP] ------> Telefon => is_wired = 1
Deswegen darf ich
attr unifi ignoreWiredClients 1
nicht setzen, auch wenn ich nur WLAN-Geräte abfragen will, weil WLAN-Geräte, wie oben beschrieben, in manchen Szenarien als "wired" erkannt werden.
@Wuehler: Ich nehme mal nicht an, dass Du daran was ändern kannst? Sollte man das vielleicht dokumentieren?
Zitat von: Fs79 am 02 Februar 2020, 18:43:49
Hallo,
ich habe hier eine Unifi Dream Machine. Auf der läuft ein Controller, ein Switch und ein AP.
In der neuesten Software läuft der Controller auf der IP/network also in etwa so.
http://10.10.10.1/network/ und dann site etc.
Kann man das Modul anpassen das es auch mit dem neuen Controller läuft auf der UDM läuft?
Bin auch gern bereit zu testen.
VG
Frank
Funktioniert das Module mit dem UDM wirklich nicht? oh oh....
Ich habe ein UDM Pro bestellt....aber das FHEM Modul muss für mich funktionieren. Sonst bleibe ich mit dem Cloudkey/USG
Hallo okenny,
ohne selbst eine DreamMachine zu haben kann ich nicht so viel unterstützen. Also musst du selbst ein wenig ran. Schau mal direkt in den Modulcode. Zeile 212 kautet:
url => "https://".$a[2].(($a[3] == 443) ? '' : ':'.$a[3]).'/api/s/'.(($a[7]) ? $a[7] : 'default').'/',
# $a[2] = ip
# $a[3] = port
# $a[7] = site-ID
Jetzt kommt es darauf an, wie das Ganze aus der Unifi-Controller-Software aufgerufen wird. Dazu solltest du die Entwicklertools des Browsers starten und schauen, wie die API-Aufrufe von dort aussehen. Danach kannst du vermutlich Zeile 212 entsprechend anpassen.
Viele Grüße,
Dirk
Hi Dirk,
hab die Dev Console vom neuen Edge offen. Bin da aber etwas überfordert.
Hab mal auf einem herkömmlichen Unifi Controller gefunden wo ich etwas mit api finde, dann hätte ich das gleiche mit einer Dev Console an der UDM gemacht.
Finde aber weder etwas auf dem herkömmlichen Controller als auf der Unifi Dream Machine.
Vielleicht kannst du mir da noch etwas mehr Hilfestellung geben.
edit:
Habe einen Artikel zur API gefunden:
https://ubntwiki.com/products/software/unifi-controller/api
Hab auf dem herkömmlichen Controller damit Erfolg gehabt:
https://wlan.123456.work:8443/api/s/xx11223344/stat/event
Auf der neuen UDM habe ich einiges an URL Möglichkeiten probiert, es klappt leider nichts.
Wenn du dich bei der neuen UDM anmeldest , landest du auf einer Art Dashboard und dann kommst du durch Klick auf ein Symbol zum Unifi Controller.
Der läuft dann auf:
https://1.2.3.4/network/site/default/dashboard
Hab parallel auch mal im Unifi Forum nachgefragt. Gemeinsam lösen wir diese Herausforderung! :)
VG
Hi,
wenn ich diese Seite (https://godoc.org/golift.io/unifi) richtig interpretiere hat sich nur der Pfad zur login-API geändert. Ist aber ein wenig geraten.
Was passiert, wenn du folgendes im Browser in die Adresszeile eingibst?
https://<deine ip>:8443/api/s/default/self
Auf Port 8443 läuft leider kein Dienst.
# netstat -ln | grep tcp
tcp 0 0 0.0.0.0:39080 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:11081 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:27117 0.0.0.0:* LISTEN
tcp 0 0 192.168.250.2:110 0.0.0.0:* LISTEN
tcp 0 0 192.168.250.2:2222 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:39443 0.0.0.0:* LISTEN
tcp 0 0 192.168.250.2:21 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
tcp 0 0 192.168.250.1:53 0.0.0.0:* LISTEN
tcp 0 0 10.0.0.1:53 0.0.0.0:* LISTEN
tcp 0 0 172.16.251.1:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 192.168.250.2:23 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp 0 0 192.168.250.2:25 0.0.0.0:* LISTEN
tcp 0 0 192.168.250.2:1433 0.0.0.0:* LISTEN
tcp 0 0 192.168.250.2:445 0.0.0.0:* LISTEN
tcp 0 0 192.168.250.2:8000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:29668 0.0.0.0:* LISTEN
tcp 0 0 :::8843 :::* LISTEN
tcp 0 0 :::8880 :::* LISTEN
tcp 0 0 :::8080 :::* LISTEN
tcp 0 0 :::80 :::* LISTEN
tcp 0 0 ::ffff:127.0.0.1:8081 :::* LISTEN
tcp 0 0 :::9812 :::* LISTEN
tcp 0 0 ::1:53 :::* LISTEN
tcp 0 0 fe80::e263:daff:fe20:572:53 :::* LISTEN
tcp 0 0 fe80::8001:c6ff:feef:3c4e:53 :::* LISTEN
tcp 0 0 fe80::7861:faff:feaa:1134:53 :::* LISTEN
tcp 0 0 :::22 :::* LISTEN
tcp 0 0 :::9080 :::* LISTEN
tcp 0 0 ::ffff:127.0.0.1:1080 :::* LISTEN
tcp 0 0 ::1:25 :::* LISTEN
tcp 0 0 :::443 :::* LISTEN
tcp 0 0 :::9444 :::* LISTEN
tcp 0 0 :::29668 :::* LISTEN
tcp 0 0 :::6789 :::* LISTEN
#
Es gibt den Controller noch Standalone und da hat sich an den Ports (https 8443) nichts geändert.
Bei der UDM aka. Unifi OS läuft es jetzt auf Port 443 und du kommst auf folgende Oberfläche, die dann weiterleitet.
Bild der Oberfläche mit Link zum Controller ist anbei.
Controller wird dann so addressiert:
https://x.x.x.1/network/site/default/dashboard
Hast du die URL dann mal mit 443 anstatt 8443 versucht?
Hi,
@Wuehler ich weiss nicht ob Du es kennst, aber der Unifi Bash Api Client ist immer recht up2date. Nutze ich auch für einige Dinge ausserhalb von FHEM ;)
https://github.com/Art-of-WiFi/UniFi-API-client
HTH ronny
@Wuehler:
Hatte jetzt schon das zweite mal das dass Unifi Modul mein Handy nicht gemeldet hat als connected.
Mir ist aufgefallen dass passiert nur wenn ich es mit meinem 5Ghz WLAN verbunden habe.
Nicht aber wenn es mit meinem 2,4Ghz verbunden ist.
In beiden Fällen zeigt Unifi unter Clients mein Handy aber an (also connected).
Das Modul aber nur wenn es mit 2,4Ghz verbunden ist.
Komisch ist auch das es vor ein paar Tagen funktionierte -> Siehe meinen Post oben.
Nachdem ich ein Clear im Modul machte funktionierte es kurze Zeit wieder.
Habe jetzt aber kein Clear gemacht sondern ein verbose 5 und hier das Log meines Geräts:
Verbunden mit 5Ghz, Unifi erkennt das Gerät das Modul nicht:
2020.02.17 10:56:17 5: WZ_unifi_controller (Unifi_SetClientReadings) - Dispatch: OnePlus6T
2020.02.17 10:56:17 5: WZ_unifi_controller: dispatch UnifiClient_OnePlus6T{"_f_last_seen":"2020-02-17 10:56:08","idletime":2,"ap_mac":"XX:XX:XX:XX:XX:XX","_is_guest_by_ugw":false,"rx_packets":181,"_id":"5e30a27980f01f1b343273ac","ccq":333,"hostname":"OnePlus6T","radio_name":"wifi1","signal":-49,"rx_rate":360000,"dev_cat":1,"accesspoint":"AP Wohnzimmer","vlan":0,"_f_first_seen":"2020-01-28 22:07:05","_f_last_seen_by_ugw":"2020-02-17 10:56:15","_last_seen_by_ugw":1581933375,"network_id":"57d96efc0b4acf5afd2de6c3","tx_packets":156,"_f_assoc_time":"47d 9h 55m 8s","tx_rate":360000,"tx_power":34,"_f_uptime_by_ugw":"0d 0h 0m 26s","os_class":3,"qos_policy_applied":true,"powersave_enabled":false,"rx_bytes":36531,"assoc_time":1581933308,"_f_uptime_by_uap":"0d 0h 1m 0s","ip":"192.168.0.141","rssi":47,"_f_usergroup_name":"Default","dhcpend_time":1600,"is_wired":false,"os_name":3,"_f_last_seen_by_uap":"2020-02-17 10:56:08","tx_bytes-r":712,"radio":"na","radio_proto":"ac","_f_latest_assoc_time":"2020-02-17 10:55:49","satisfaction":97,"_last_seen_by_uap":1581933368,"channel":36,"latest_assoc_time":1581933349,"bssid":"fc:ec:da:88:ab:8c","_f_last_seen_duration":"0d 0h 0m 9s","tx_bytes":35603,"dev_vendor":1,"uptime":60,"mac":"XX:XX:XX:XX:XX:XX","authorized":true,"noise":-108,"_uptime_by_uap":60,"fhem_clientName":"OnePlus6T","wifi_tx_attempts":139,"essid":"WLANMEDIA50","_is_guest_by_uap":false,"gw_mac":"XX:XX:XX:XX:XX:XX","is_11r":false,"dev_id":283,"tx_retries":42,"bytes-r":1442,"rx_bytes-r":730,"site_id":"57d96efa0b4acf5afd2de6be","dev_family":4,"first_seen":1580245625,"fhem_state":"connected","anomalies":0,"_uptime_by_ugw":26,"is_guest":false,"user_id":"5e30a27980f01f1b343273ac","_f_essid":"WLANMEDIA50","oui":"","last_seen":1581933368,"network":"LAN","blocked":false,"_f_dhcpend_time":"0d 0h 26m 40s","_f_uptime":"0d 0h 1m 0s"}
2020.02.17 10:56:17 5: WZ_unifi_controller (UnifiClient_Parse) - executed. UnifiClient: Adress: OnePlus6T
2020.02.17 10:56:17 5: WZ_unifi_controller (UnifiClient_Parse) - executed. UnifiClient: message_json: {"_f_last_seen":"2020-02-17 10:56:08","idletime":2,"ap_mac":"XX:XX:XX:XX:XX:XX","_is_guest_by_ugw":false,"rx_packets":181,"_id":"5e30a27980f01f1b343273ac","ccq":333,"hostname":"OnePlus6T","radio_name":"wifi1","signal":-49,"rx_rate":360000,"dev_cat":1,"accesspoint":"AP Wohnzimmer","vlan":0,"_f_first_seen":"2020-01-28 22:07:05","_f_last_seen_by_ugw":"2020-02-17 10:56:15","_last_seen_by_ugw":1581933375,"network_id":"57d96efc0b4acf5afd2de6c3","tx_packets":156,"_f_assoc_time":"47d 9h 55m 8s","tx_rate":360000,"tx_power":34,"_f_uptime_by_ugw":"0d 0h 0m 26s","os_class":3,"qos_policy_applied":true,"powersave_enabled":false,"rx_bytes":36531,"assoc_time":1581933308,"_f_uptime_by_uap":"0d 0h 1m 0s","ip":"192.168.0.141","rssi":47,"_f_usergroup_name":"Default","dhcpend_time":1600,"is_wired":false,"os_name":3,"_f_last_seen_by_uap":"2020-02-17 10:56:08","tx_bytes-r":712,"radio":"na","radio_proto":"ac","_f_latest_assoc_time":"2020-02-17 10:55:49","satisfaction":97,"_last_seen_by_uap":1581933368,"channel":36,"latest_assoc_time":1581933349,"bssid":"fc:ec:da:88:ab:8c","_f_last_seen_duration":"0d 0h 0m 9s","tx_bytes":35603,"dev_vendor":1,"uptime":60,"mac":"XX:XX:XX:XX:XX:XX","authorized":true,"noise":-108,"_uptime_by_uap":60,"fhem_clientName":"OnePlus6T","wifi_tx_attempts":139,"essid":"WLANMEDIA50","_is_guest_by_uap":false,"gw_mac":"XX:XX:XX:XX:XX:XX","is_11r":false,"dev_id":283,"tx_retries":42,"bytes-r":1442,"rx_bytes-r":730,"site_id":"57d96efa0b4acf5afd2de6be","dev_family":4,"first_seen":1580245625,"fhem_state":"connected","anomalies":0,"_uptime_by_ugw":26,"is_guest":false,"user_id":"5e30a27980f01f1b343273ac","_f_essid":"WLANMEDIA50","oui":"","last_seen":1581933368,"network":"LAN","blocked":false,"_f_dhcpend_time":"0d 0h 26m 40s","_f_uptime":"0d 0h 1m 0s"}
2020.02.17 10:56:17 4: WZ_unifi_controller (UnifiClient_Parse) - return: UNDEFINED UnifiClient_OnePlus6T UnifiClient OnePlus6T
Und hier connected am 2,4Ghz Unifi und das Modul erkennt es als coonected:
2020.02.17 10:57:49 5: WZ_unifi_controller (Unifi_SetClientReadings) - Dispatch: OnePlus6T
2020.02.17 10:57:49 5: WZ_unifi_controller: dispatch UnifiClient_OnePlus6T{"bytes-r":0,"rx_bytes-r":0,"fhem_state":"connected","first_seen":1573069027,"site_id":"57d96efa0b4acf5afd2de6be","dev_family":4,"user_id":"5dc320e380f01f1ba4c0575f","is_guest":false,"_uptime_by_ugw":212,"anomalies":0,"oui":"OneplusT","_f_essid":"WLANMEDIA","blocked":false,"last_seen":1581933447,"network":"LAN","_f_uptime":"0d 0h 0m 10s","_f_dhcpend_time":"0d 0h 26m 50s","tx_bytes":4444,"_f_last_seen_duration":"0d 0h 0m 22s","uptime":10,"dev_vendor":1,"_uptime_by_uap":10,"fhem_clientName":"OnePlus6T","wifi_tx_attempts":0,"noise":-111,"authorized":true,"mac":"XX:XX:XX:XX:XX:XX","is_11r":false,"dev_id":283,"gw_mac":"XX:XX:XX:XX:XX:XX","_is_guest_by_uap":false,"essid":"WLANMEDIA","tx_retries":0,"ip":"192.168.0.130","_f_uptime_by_uap":"0d 0h 0m 10s","assoc_time":1581933437,"rx_bytes":4498,"is_wired":false,"dhcpend_time":1610,"_f_usergroup_name":"Default","rssi":64,"os_name":3,"_f_last_seen_by_uap":"2020-02-17 10:57:27","radio_proto":"ng","radio":"ng","tx_bytes-r":0,"channel":11,"_last_seen_by_uap":1581933447,"satisfaction":100,"_f_latest_assoc_time":"2020-02-17 10:57:17","bssid":"fc:ec:da:87:ab:8c","latest_assoc_time":1581933437,"idletime":0,"_f_last_seen":"2020-02-17 10:57:27","ap_mac":"XX:XX:XX:XX:XX:XX","_is_guest_by_ugw":false,"radio_name":"wifi0","signal":-32,"hostname":"OnePlus6T","ccq":652,"_id":"5dc320e380f01f1ba4c0575f","rx_packets":15,"accesspoint":"AP Wohnzimmer","dev_cat":1,"rx_rate":1000,"vlan":0,"tx_packets":28,"network_id":"57d96efc0b4acf5afd2de6c3","_last_seen_by_ugw":1581933468,"_f_first_seen":"2019-11-06 20:37:07","_f_last_seen_by_ugw":"2020-02-17 10:57:48","_f_assoc_time":"47d 9h 57m 17s","qos_policy_applied":true,"_f_uptime_by_ugw":"0d 0h 3m 32s","tx_power":34,"powersave_enabled":false,"os_class":3,"tx_rate":65000}
2020.02.17 10:57:49 5: WZ_unifi_controller (UnifiClient_Parse) - executed. UnifiClient: Adress: OnePlus6T
2020.02.17 10:57:49 5: WZ_unifi_controller (UnifiClient_Parse) - executed. UnifiClient: message_json: {"bytes-r":0,"rx_bytes-r":0,"fhem_state":"connected","first_seen":1573069027,"site_id":"57d96efa0b4acf5afd2de6be","dev_family":4,"user_id":"5dc320e380f01f1ba4c0575f","is_guest":false,"_uptime_by_ugw":212,"anomalies":0,"oui":"OneplusT","_f_essid":"WLANMEDIA","blocked":false,"last_seen":1581933447,"network":"LAN","_f_uptime":"0d 0h 0m 10s","_f_dhcpend_time":"0d 0h 26m 50s","tx_bytes":4444,"_f_last_seen_duration":"0d 0h 0m 22s","uptime":10,"dev_vendor":1,"_uptime_by_uap":10,"fhem_clientName":"OnePlus6T","wifi_tx_attempts":0,"noise":-111,"authorized":true,"mac":"XX:XX:XX:XX:XX:XX","is_11r":false,"dev_id":283,"gw_mac":"XX:XX:XX:XX:XX:XX","_is_guest_by_uap":false,"essid":"WLANMEDIA","tx_retries":0,"ip":"192.168.0.130","_f_uptime_by_uap":"0d 0h 0m 10s","assoc_time":1581933437,"rx_bytes":4498,"is_wired":false,"dhcpend_time":1610,"_f_usergroup_name":"Default","rssi":64,"os_name":3,"_f_last_seen_by_uap":"2020-02-17 10:57:27","radio_proto":"ng","radio":"ng","tx_bytes-r":0,"channel":11,"_last_seen_by_uap":1581933447,"satisfaction":100,"_f_latest_assoc_time":"2020-02-17 10:57:17","bssid":"fc:ec:da:87:ab:8c","latest_assoc_time":1581933437,"idletime":0,"_f_last_seen":"2020-02-17 10:57:27","ap_mac":"XX:XX:XX:XX:XX:XX","_is_guest_by_ugw":false,"radio_name":"wifi0","signal":-32,"hostname":"OnePlus6T","ccq":652,"_id":"5dc320e380f01f1ba4c0575f","rx_packets":15,"accesspoint":"AP Wohnzimmer","dev_cat":1,"rx_rate":1000,"vlan":0,"tx_packets":28,"network_id":"57d96efc0b4acf5afd2de6c3","_last_seen_by_ugw":1581933468,"_f_first_seen":"2019-11-06 20:37:07","_f_last_seen_by_ugw":"2020-02-17 10:57:48","_f_assoc_time":"47d 9h 57m 17s","qos_policy_applied":true,"_f_uptime_by_ugw":"0d 0h 3m 32s","tx_power":34,"powersave_enabled":false,"os_class":3,"tx_rate":65000}
2020.02.17 10:57:49 4: WZ_unifi_controller (UnifiClient_Parse) - return: UNDEFINED UnifiClient_OnePlus6T UnifiClient OnePlus6T
Irgendwie nicht so toll wenn man Zuhause ist und sich die komplette Wohnung ausschaltet obowhl man Zuhause ist :-)
Das funktionierte bis vor kurzem Problemlos.
Keine Ahnung ob es ein FHEm Update oder Unifi Update auslöste.
Habe folgende Unifi Fersion:
COMPONENT VERSION
Controller Version 5.12.35
Current Build atag_5.12.35_12979
User Interface Build 1.0.0-beta.61
Wäre toll wenn du im Log was erkennen kannst.
PS.: Wenn du es benötigst habe die Komplette Log Abfrage noch mit den Macs. usw.
Danke
pOpY
@popy, nur aus Interesse: Ich hatte oben ja ein ähnliches Problem geschildert, bei dem ein Handy nicht erkannt wurde, solange ich das Attribut gesetzt hatte, das kabelgebundene Geräte aus Unifi draußen halten soll. Hast Du dieses Attribut zufällig auch gesetzt, und falls ja, löst es Dein Problem, wenn Du es löschst?
Danke, der Beitrag hier hat mich auf mein eigentliches Problem gebracht.
Nach einem kurzen Test habe ich, seit dem letzten fhem und Unificontrollerupdate letzte Woche, das selbe Problem, dass fhem meine Handys nicht mehr erkennt, sobald diese im 5ghz wlan sind. Sind sie im 2,4ghz werden sie erkannt.
Hab mich schon gewundert, als es 2x dunkel im Haus wurde...
Hatte erst Empfangsprobleme vermutet.
Mehr testen kann ich später.
Port 443 habe ich natürlich schon versucht. :)
Leider kein Glück.
Zitat von: Motivierte linke Hände am 17 Februar 2020, 16:11:29
@popy, nur aus Interesse: Ich hatte oben ja ein ähnliches Problem geschildert, bei dem ein Handy nicht erkannt wurde, solange ich das Attribut gesetzt hatte, das kabelgebundene Geräte aus Unifi draußen halten soll. Hast Du dieses Attribut zufällig auch gesetzt, und falls ja, löst es Dein Problem, wenn Du es löschst?
Habe
attr unifi ignoreWiredClients 1
nicht gesetzt.
Dürfte ein Bug sein entweder im Unifi Controller oder Modul, da @Ban auch das gleiche Thema hat wie ich.
@Wuehler: Können wir irgendwie beim debuggen helfen?
Danke
pOpY
Hi,
laut meinem Link, ist der Pfad bei UnifiOS anders (sieht man im Commitverlauf)
https://github.com/Art-of-WiFi/UniFi-API-client/commit/961d692125cb9a0889c6a536e0bd60b19047be6b
BaseURL ist https://ip:8443 bzw bei UnifiOS halt 443 oder ganz weglassen , da ehh https genutzt wird
Ich steck zwar hier nicht so drin, aber ich würde folgendes mal "vermuten":
Normal ist baseurl . $path;
UnifiOS ist: baseurl . '/proxy/network' . $path;
Probiert mal:
https://<deine ip>/proxy/network/api/s/default/self
Vielleicht gehts ja, ich hab auch keine da um das direkt zu prüfen.
Ronny
Zitat von: rcmcronny am 18 Februar 2020, 12:17:36
Hi,
laut meinem Link, ist der Pfad bei UnifiOS anders (sieht man im Commitverlauf)
https://github.com/Art-of-WiFi/UniFi-API-client/commit/961d692125cb9a0889c6a536e0bd60b19047be6b
BaseURL ist https://ip:8443 bzw bei UnifiOS halt 443 oder ganz weglassen , da ehh https genutzt wird
Ich steck zwar hier nicht so drin, aber ich würde folgendes mal "vermuten":
Normal ist baseurl . $path;
UnifiOS ist: baseurl . '/proxy/network' . $path;
Probiert mal:
https://<deine ip>/proxy/network/api/s/default/self
Vielleicht gehts ja, ich hab auch keine da um das direkt zu prüfen.
Ronny
Glaube nicht dass es an sowas liegt da ja grundsätzlich die Kommunikation funktioniert.
Es werden nur "manchmal" die 5Ghz Geräte als disconnected angenommen, obwohl diese online/connected sind.
Mein Beitrag war mehr for fs79 gedacht ;)
Zitat von: rcmcronny am 18 Februar 2020, 14:32:20
Mein Beitrag war mehr for fs79 gedacht ;)
Sorry ;)
Zu meinem Thema, leider heute wieder das gleiche, Gerät 100% Online (getestet am Gerät & über den Controller sichtbar über einen AP) aber das fhem Unifi Modul meldet disconnected & Lichter gehen aus :(
Sprich, da Problem ist nicht nur das 5Ghz Band, mein Handy ist mit 2,4 Ghz verbunden.
Da ich leider nicht so tief in dem Thema fhem+perl drinnen bin wäre es toll wenn mit jemand (@Wuehler ?) das verbose 5 log ansehen könnte?
Habe ein Log vom jetzigen Zustand (fhem sagt disconnected & Unifi Controller connected).
Kann es Gerne per PM versenden, möchte es hier nicht hochladen da es alle MACs meiner Geräte enthält.
Danke
pOpY
Hi,
im Anhang eine Testversion. Mal schauen, ob es hilft.
VG,
Dirk
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?
sorry, am Ende nicht gespeichert und ne Zwischenversion hochgeladen :-[. Neuer Anhang
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
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.
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...
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
Ok, dann habe ich Pech oder Du Glück :-)
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
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
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.
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.
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
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
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
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.
Hallo Dirk,
könntest Du Dir mal mein Feature Request https://forum.fhem.de/index.php/topic,87728.msg1041442.html#msg1041442 (https://forum.fhem.de/index.php/topic,87728.msg1041442.html#msg1041442) anschauen. Ich hatte das im Unifi Switch Thread gepostet und es gibt noch weitere Interessenten dafür.
Beste Grüße
Torsten
Hat jemand es geschafft, das FHEM Modul mit dem Unifi Controller im UDM (Pro) zum laufen zu bringen?
Ich würde mich freuen wenn das gehen würde...seit meinem Umzug auf dem UDM pro, muss ich auf meine FHEM Funktionen leider verzichten...
Danke sehr
Hallo,
Da das Modul den Server abfragt kann das nur mit Server funktionieren. Wenn du ohne laufenden Server was abfragen willst würde ich dir snmp empfehlen.
Gruß
Eisix
Zitat von: Eisix am 10 Mai 2020, 14:25:35
Hallo,
Da das Modul den Server abfragt kann das nur mit Server funktionieren. Wenn du ohne laufenden Server was abfragen willst würde ich dir snmp empfehlen.
Gruß
Eisix
Hallo
Versteh ich nicht...?
Ich habe gensuso wie vorher ein Server, aber kein Cloudkey mehr, sondern ein Controller im UDM Pro.
Danke
@okenny: So ganz habe ich nicht verstanden, was Du machen möchtest. Aber es gibt von Ubiquity eine API (https://dl.ui.com/unifi/5.12.35/unifi_sh_api (https://dl.ui.com/unifi/5.12.35/unifi_sh_api)) und davon abgeleitet auch für php (https://github.com/Art-of-WiFi/UniFi-API-client (https://github.com/Art-of-WiFi/UniFi-API-client)). Damit und mit Skripten kann man sich auch so einiges an Funktionalität basteln.
Zitat von: Motivierte linke Hände am 10 Mai 2020, 14:35:58
@okenny: So ganz habe ich nicht verstanden, was Du machen möchtest. Aber es gibt von Ubiquity eine API (https://dl.ui.com/unifi/5.12.35/unifi_sh_api (https://dl.ui.com/unifi/5.12.35/unifi_sh_api)) und davon abgeleitet auch für php (https://github.com/Art-of-WiFi/UniFi-API-client (https://github.com/Art-of-WiFi/UniFi-API-client)). Damit und mit Skripten kann man sich auch so einiges an Funktionalität basteln.
Hallo,
Danke für die Antwort. Ich versuch's nochmal.
Seit jahen habe ich FHEM mit dem 74_Unifi Modul und mein Unifi Netzwerk benutzt. Es hat wunderbar funktioniert (POE an uns schalten, Anwesenheitserkennung usw..).
Seitdem ich aber mein Cloudkey für ein UDM Pro getauscht habe, funktioniert das FHEM Modul nicht mehr. FHEM bleibt auf "disconnected", vermütlich weil das UDM anders funktioniert, und das FHEM 74_Unifi Modul nicht kompatible ist?
Ich wollte fragen ob es doch einen Weg gibt FHEM mit dem UDM-Pro zu nutzen?
Leider kann das UDM Pro nur mit dem eingebauten Unifi Controller benutzt werden, ein Raspi oder Cloudkey kann nicht in kombination mit dem UDM-Pro benutzt werden.
Ah, also Deine Frage ist, ob das 74_Unifi-Modul so angepasst werden kann, dass es nicht nur die normalen Controller, sondern auch die in einem UDM Pro abfragen kann.
Ich habe da leider keine Ahnung oder Erfahrung. Hier im Thread hatte sich wohl das letzte Mal Ende Februar @Fs79 damit beschäftigt und offenbar Teilerfolge erzielt. Aber das hast Du sicherlich gesehen.
Moin,
so viel ich weiß hat sich der Pfad zu den API-URLs leicht verändert. Das größere Problem für mich ist der Geänderte Login-Mechanismus. Ohne eine UDM zu haben ist das für mich aber kaum zu entwickeln. Das sind Frontend-Themen mit denen ich mich nicht ganz so gut auskenne.
Wenn man das angepasst hat sollte das Modul auch für UDM funktionieren.
Viele Grüße,
Dirk
ok, vielen Dank Motivierte linke Hände und Wuehler!
Ich wünsche euch eine gut Woche!
Hallo Zusammen,
ich habe das Unifi Modul lange Zeit mit meinem Cloudkey genutzt, bin nun aber auch auf eine Dream Machine Pro umgestiegen. Ich biete meine Unterstützung an, das Modul auf der UDM lauffähig zu machen, habe auch die letzen Beiträge verfolgt.
Folgendes habe ich auch schon nachstellen können:
Wenn ich im Browser auf meiner UDM eingelogt bin (Standard Startseite https://192.168.1.1/network/site/default/dashboard ) dann kann ich in einem neuen Browser Tab die API Urls aufrufen:
URL hierfür lautet: https://192.168.1.1/proxy/network/api/s/default/"API CALL"
Gemäß der Unifi Doku https://ubntwiki.com/products/software/unifi-controller/api kann ich also die in "Path" genannten calls hinter die obige URL hängen und bekomme im Browser die Ergebnisse:
Beispiele:
https://192.168.1.1/proxy/network/api/s/default/self
https://192.168.1.1/proxy/network/api/s/default/stat/current-channel
https://192.168.1.1/proxy/network/api/s/default/rest/user
https://192.168.1.1/proxy/network/api/s/default/stat/sta
Habe mir auch schon das FHEM Modul 74_Unifi angesehen (https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/74_Unifi.pm) und glaube das in Zeile 212 lediglich die URL angepasst werden muss (dann würde es aber NUR fürs UDM gehen)
Zeile 212 Aktuell: url => "https://".$a[2].(($a[3] == 443) ? '' : ':'.$a[3]).'/api/s/'.(($a[7]) ? $a[7] : 'default').'/',
Zeile 212 Geändert: url => "https://".$a[2].(($a[3] == 443) ? '' : ':'.$a[3]).'/proxy/network/api/s/'.(($a[7]) ? $a[7] : 'default').'/',
Mein Plan war, dass ich die URL auf meinem FHEM mal anpasse um das Thema zu testen. Dies habe ich aktuell noch nicht geschafft, bin definitiv kein FHEM Profi.
Vielleicht kann mir jemand einen Tipp geben, gerne auch per PM, wie ich die Zeile in meinem FHEM angepasst bekomme. Gerne auch andere Vorschläge schicken, ich versuche dann zeitnah zu testen.
Freue mich auf eine produktive Zusammenarbeit, allen einen guten Start in die Woche,
Andi
Moin andi,
Hängt ja auch von deiner Hardware ab, auf der fhem läuft.
Das ist ja nicht direkt ein fhem thema, das modul zu ändern. Ist am Ende nur eine Datei.
Habe mal die Datei mit deiner gewünschten Änderung angehangen.
Vielleicht mag ja auch noch jemand anderes mit UDM testen.
Eine Idee, um beides zu ermöglichen, wäre ein Steuern per attribute im Modul.
Eine Art device auswahl, welche auf udm geändert werden kan.
Gruss
Maui
danke, ich würde es testen.
Die Datei scheint aber leer zu sein - 0kB
"74_Unifi.pm (0 kB - downloaded 1 times.)"
Sorry ;D
Da ist was im forum schief gelaufen.
Leider "Disconnected" :(
Danke trotzdem
Wie sieht denn dein define aus?
Port auf 443?
Wie geschrieben hat sich etwas am Login geändert. Evtl. auch nur der Pfad? Da gibt es an anderer Stelle im Modul eine weitere Pfadangabe. Mal nach login suchen.
Das experimentelle Anpassen eines Moduls geht eigentlich recht einfach:
1. In den Modul-Pfad wechseln (zB /opt/fhem/FHEM)
2. Sicherungskopie der entsprechenden Moduldatei erstellen
3. Die Moduldatei mit einem Texteditor bearbeiten und speichern. ZB mit Notepad++
4. In der FHEM-Befehlseingabezeile reload <Moduldatei> eingeben. Hier: reload 74_Unifi.pm
Dann bekommt man entweder eine Fehlermeldung falls man syntaktische Fehler hat (Sicherungskopie?) oder die geänderte Version läuft und kann getestet werden.
Ich bräuchte nur eine Version, die mit UDM funktioniert, um den Rest (UDM-Attribut oder ähnliches) kann ich mich dann kümmern.
"Connected" !!!!!!!
Danke! Ich hatte nur Port 8443 probiert, mit 443 funktioniert es! :) :) :) :)
Moin okenny, hattest du dich auf dem fhem Rechner zufällig vorher mal direkt am Browser über die URL eingeloggt?
@Dirk: Ich schätze mal in Zeile 902 müsste der Aufruf ebenfalls angepasst werden für UDM
Zitat von: Maui am 12 Mai 2020, 06:18:35
Moin okenny, hattest du dich auf dem fhem Rechner zufällig vorher mal direkt am Browser über die URL eingeloggt?
@Dirk: Ich schätze mal in Zeile 902 müsste der Aufruf ebenfalls angepasst werden für UDM
Nein, mein FHEM Server läuft auf einem Ubuntu 20.4 Server VM - es hat kein Borowser und kein GUI.
Dann müsste deine Moduldatei auch bei einem anderen UDM-Besitzer funktionieren. Könnt ihr mal testen?
Ich habe das Unifi Modul nun schon sehr lange im Einsatz und verwende es auch für eine Anwesenheitskontrolle in Verbindung mit dem Residents Modul.
Internals:
CODE Dirks-Handy
DEF Dirks-Handy
FUUID 5d8d404d-f33f-c2c3-7191-0ed1e3618614d330
IODev UnifiController
LASTInputDev UnifiController
MODEL SamsungE
MSGCNT 92
NAME DirkHandy
NOTIFYDEV global
NR 314
STATE connected
TYPE UnifiClient
UnifiController_MSGCNT 92
UnifiController_TIME 2020-05-13 20:12:32
VERSION 0.0.3 BETA
READINGS:
2020-05-13 20:12:32 1x_identity dirk
2020-05-13 20:12:32 _f_assoc_time 133d 17h 45m 15s
2020-05-13 20:12:32 _f_dhcpend_time 0d 0h 0m 0s
2020-05-13 20:12:32 _f_diff_tx_bytes -1697213359
2020-05-13 20:12:32 _f_essid DSHOME
2020-05-13 20:12:32 _f_first_seen 2019-09-26 18:06:13
2020-05-13 20:12:32 _f_last_seen 2020-05-13 20:12:13
2020-05-13 20:12:32 _f_last_seen_by_uap 2020-05-13 20:12:13
2020-05-13 19:44:04 _f_last_seen_by_usw 2020-05-13 19:43:31
2020-05-13 20:12:32 _f_last_seen_duration 0d 0h 0m 19s
2020-05-13 20:12:32 _f_latest_assoc_time 2020-05-13 19:45:15
2020-05-13 20:12:32 _f_uptime 0d 0h 26m 58s
2020-05-13 20:12:32 _f_uptime_by_uap 0d 0h 26m 58s
2020-05-13 19:44:04 _f_uptime_by_usw 0d 0h 0m 37s
2020-05-13 20:12:32 _f_usergroup_name Default
2020-05-13 20:12:32 _id 5d8ce1f527864218b1a8c734
2020-05-13 20:12:32 _is_guest_by_uap 0
2020-05-13 19:44:04 _is_guest_by_usw 0
2020-05-13 20:12:32 _last_seen_by_uap 1589393533
2020-05-13 19:44:04 _last_seen_by_usw 1589391811
2020-05-13 20:12:32 _uptime_by_uap 1618
2020-05-13 19:44:04 _uptime_by_usw 37
2020-05-13 20:12:32 accesspoint Terrasse
2020-05-13 20:12:32 anomalies 0
2020-05-13 20:12:32 ap_mac 18:e8:29:b4:e9:00
2020-05-13 20:12:32 assoc_time 1589391915
2020-05-13 20:12:32 authorized 1
2020-05-13 20:12:32 bssid 1a:e8:29:94:e9:02
2020-05-13 20:12:32 bytes-r 2
2020-05-13 20:12:32 ccq 0
2020-05-13 20:12:32 channel 100
2020-05-13 20:12:32 dev_id_override 2803
2020-05-13 20:12:32 dhcpend_time 0
2020-05-13 20:12:32 duration 191514
2020-05-13 20:12:32 essid DSHOME
2020-05-13 20:12:32 fhem_clientName Dirks-Handy
2020-05-13 20:12:32 fhem_state connected
2020-05-13 20:12:32 fhem_usedOnlineTime 12 Minuten
2020-05-13 20:12:32 fingerprint_override 1
2020-05-13 20:12:32 first_seen 1569513973
2020-05-13 20:12:32 hostname Dirks-Handy
2020-05-13 20:12:32 idletime 13
2020-05-13 20:12:32 ip 192.168.10.244
2020-05-13 20:12:32 is_11r 0
2020-05-13 20:12:32 is_guest 0
2020-05-13 20:12:32 is_wired 0
2020-05-13 20:12:32 last_seen 1589393533
2020-05-13 20:12:32 latest_assoc_time 1589391915
2020-05-13 20:12:32 mac MAC
2020-05-13 20:12:32 name Dirks-Handy
2020-05-13 19:44:04 network Freifunk Client VLAN
2020-05-13 19:44:04 network_id 598a10dab64610dfc2d2267e
2020-05-13 20:12:32 noise -96
2020-05-13 20:12:32 noted 1
2020-05-13 20:12:32 oui SamsungE
2020-05-13 20:12:32 powersave_enabled 1
2020-05-13 20:12:32 presence present
2020-05-13 20:12:32 qos_policy_applied 1
2020-05-13 20:12:32 radio na
2020-05-13 20:12:32 radio_name rai0
2020-05-13 20:12:32 radio_proto ac
2020-05-12 17:07:13 roam_count 1
2020-05-13 20:12:32 rssi 27
2020-05-13 20:12:32 rx_bytes 1196632
2020-05-13 20:12:32 rx_bytes-r 2
2020-05-13 20:12:32 rx_packets 9328
2020-05-13 20:12:32 rx_rate 702000
2020-05-13 20:12:32 satisfaction 98
2020-05-13 20:12:32 signal -69
2020-05-13 20:12:32 site_id 544e86a10d5d28255a2ce20c
2020-05-13 19:44:04 sw_depth 9551
2020-05-13 19:44:04 sw_mac f0:9f:c2:3f:e6:46
2020-05-13 19:44:04 sw_port 9
2020-05-13 20:12:32 tx_bytes 42139658
2020-05-13 20:12:32 tx_bytes-r 0
2020-05-13 20:12:32 tx_packets 30419
2020-05-13 20:12:32 tx_power 0
2020-05-13 20:12:32 tx_rate 780000
2020-05-13 20:12:32 tx_retries 1837
2020-05-13 20:12:32 uptime 1618
2020-05-13 20:12:32 user_id 5d8ce1f527864218b1a8c734
2020-05-13 20:12:32 usergroup_id
2020-05-13 20:12:32 vlan 0
2020-05-13 20:12:32 wifi_tx_attempts 32256
timeControl:
clientblocked 0
maxOnlineMinutesPerDay 2000
thresholdBytesPerMinute 75000
usedOnlineTime 762.6
unifiClient:
1x_identity dirk
_f_assoc_time 133d 17h 45m 15s
_f_dhcpend_time 0d 0h 0m 0s
_f_diff_tx_bytes -1697213359
_f_essid DSHOME
_f_first_seen 2019-09-26 18:06:13
_f_last_seen 2020-05-13 20:12:13
_f_last_seen_by_uap 2020-05-13 20:12:13
_f_last_seen_duration 0d 0h 0m 19s
_f_latest_assoc_time 2020-05-13 19:45:15
_f_uptime 0d 0h 26m 58s
_f_uptime_by_uap 0d 0h 26m 58s
_f_usergroup_name Default
_id 5d8ce1f527864218b1a8c734
_last_seen_by_uap 1589393533
_uptime_by_uap 1618
accesspoint Terrasse
anomalies 0
ap_mac 18:e8:29:b4:e9:00
assoc_time 1589391915
bssid 1a:e8:29:94:e9:02
bytes-r 2
ccq 0
channel 100
dev_id_override 2803
dhcpend_time 0
essid DSHOME
fhem_clientName Dirks-Galaxy-S10
fhem_state connected
fhem_usedOnlineTime 12 Minuten
first_seen 1569513973
hostname Dirks-Galaxy-S10
idletime 13
ip 192.168.10.244
last_seen 1589393533
latest_assoc_time 1589391915
mac MAC
name Dirks-Handy
noise -96
oui SamsungE
radio na
radio_name rai0
radio_proto ac
rssi 27
rx_bytes 1196632
rx_bytes-r 2
rx_packets 9328
rx_rate 702000
satisfaction 98
signal -69
site_id 544e86a10d5d28255a2ce20c
tx_bytes 42139658
tx_bytes-r 0
tx_packets 30419
tx_power 0
tx_rate 780000
tx_retries 1837
uptime 1618
user_id 5d8ce1f527864218b1a8c734
usergroup_id
vlan 0
wifi_tx_attempts 32256
Attributes:
DbLogExclude .*
room Ubiquiti
userReadings presence {((ReadingsVal("$name","fhem_state","?") eq "connected") ? "present":"absent");;}
Nun ist es aber schon seit einiger Zeit zu einem Problem geworden da permanent die Handys vom Unifi_Client Modul als disconnected und dann wieder connected gemeldet werden. Beim Unifi Controller selbst sind diese aber stets und stabil verbunden, die WLAN Verbindung reißt auch nicht ab. Das passiert vor allem beim Roaming zwischen den AP's aber auch manchmal wenn das Endgerät gar nicht bewegt wird.
Ich habe einige Abhängigkeiten mit dem Zuhause Status und das hat dann unerwünschte Kettenreaktionen.
Versuche das über waitsame attribute in DOIF's abzufangen sind leider auch nicht fruchtend.
Woran kann das liegen? Gibt es irgendeine Möglichkeit das im Unifi_Client Modul abzufangen? Nach der Einrichtung vor lange Zeit hat das auch bestens funktioniert aber irgendwann haben dann die Probleme angefangen und es wird zusehend instabiler.
Ich habe auch noch ein offenes Wlan mit Freifunk über die Unifi's laufen. Wenn ich mit dieser SSID verbunden bin ist es richtig schlimm. Da hilft nur ein Wechsel auf das Heimnetz und FHEM neustarten damit der connected status einigermaßen stabil bleibt.
Hat jemand ein ähnliches Setup und auch entsprechendes Beobachtet?
Grüße
Dirk
Wird u.a. auch am Standby der Handys liegen...
...evtl. dort ein FW-Update!?
Ich nutze nicht das Unifi, ist mir zu langsam...
Ich hatte es mal eine Zeit parallel laufen (also nur loggen) um zu sehen, ob es besser ist als das was ich habe: nein.
Ich nutze das hier: https://forum.fhem.de/index.php/topic,76342.msg682218.html#msg682218
EDIT: genauer in der Art https://forum.fhem.de/index.php/topic,76342.msg683910.html#msg683910 bzw. https://forum.fhem.de/index.php/topic,76342.msg706320.html#msg706320
Und bin (noch) zufrieden...
Gruß, Joachim
Danke dafür, das schaue ich mir mal als Alternative an.
Ich habe mir eben nochmal alles genauer angeschaut. Aufgefallen ist mir, dass das Network Reading sich nicht aktualisiert:
essid DSHOME 2020-05-13 20:31:32
network Freifunk Client VLAN 2020-05-13 19:44:04
network_id 598a10dab64610dfc2d2267e 2020-05-13 19:44:04
Das Network müsste LAN sein bei dieser SSID. Am Zeitstempel sieht man auch das dort was nicht stimmt. Aber ob das für die generelle Problematik verantwortlich ist bezweifel ich.
Zitat von: Wuehler am 12 Mai 2020, 10:24:25
Dann müsste deine Moduldatei auch bei einem anderen UDM-Besitzer funktionieren. Könnt ihr mal testen?
Hab die Datei ausgetauscht, aber passt nicht.
Steht weiter auf Disconnected.
Auch das Define --> also nochmal neu anlegen --> bringt keine Verbindung.
Die Fehlermeldung kommt, wobei die Credentials definitiv passen.
Unifi (Unifi_Login_Receive) - Login Failed! Invalid username or password! - state:'error' - msg:'api.err.Invalid'
Zitat von: bogi999 am 15 Mai 2020, 00:06:18
Hab die Datei ausgetauscht, aber passt nicht.
Steht weiter auf Disconnected.
Auch das Define --> also nochmal neu anlegen --> bringt keine Verbindung.
Die Fehlermeldung kommt, wobei die Credentials definitiv passen.
Unifi (Unifi_Login_Receive) - Login Failed! Invalid username or password! - state:'error' - msg:'api.err.Invalid'
Seltsam.....bei mir gehts (siehe Bild).
ich habe UDM Pro, Cloud Access enabled, und Firmware 1.7.0 RC18
define UnifiController Unifi 192.168.1.1 443 user pw
Habs nu in allen möglichen Variationen versucht.
No Way....
Nabend,
Ich habe nochmal was am login gedreht.
Probiert es nochmal beide mit der Version.
Gruss
Moin,
Habe mal ein wenig versucht die PHP-API zu verstehen und das Modul angepasst. Bin mir aber sicher, dass das nicht funktioniert. In Zeilen 942 bis 951 sind ein paar Kommentare mit ToDos.
Leider ist perl auch nicht meine Heimat und in das Thema header auslesen und cookie-jars in perl müsste ich mich auch erst tiefer einlesen.
Falls sich jemand damit auskennt: Bitte helfen.
Konkret scheint es bei UDM folgende Änderungen zu geben. Auch da bitte Korrektur von UDM-Besitzern:
- Loginpfad hat sich geändert von /api/login ind /api/auth/login
- API-Pfad hat sich geändert von /api/s auf /proxy/network/api/s
- Man braucht einen CSRF-Token
- Irgendetwas am Cookie. Man muss evtl. ein Cookie-Jar nutzen
Wie gesagt: Hilfe ist gerne gesehen, da das für mich ein Learning by Doing Thema wäre. Mangels eigener UDM ist das Doing etwas schwierig. Zudem hat Corona bei mir eher zu weniger Zeit geführt.
Dirk
Zitat von: Maui am 17 Mai 2020, 21:34:51
Nabend,
Ich habe nochmal was am login gedreht.
Probiert es nochmal beide mit der Version.
Gruss
Gibt es doch nich....
(Unifi_Login_Receive) - Login Failed! Invalid username or password! - state:'error' - msg:'api.err.Invalid'
Hallo zusammen,
bin leider sehr erfreut, dass es nicht nur mir so geht ;D - und danke für die Mühe - wäre toll, wenn es wieder klappt.
Ich bekomme mit dem letzten Modul und dem UDM mit FW 1.7.0 stable (=RC19)
Login Failed! - state:'error.decode_json' - msg:'malformed JSON string, neither tag, array, object, number, string or atom, at character offset 1 (before "<!doctype html>\n<ht...") at ./FHEM/74_Unifi.pm line 923.
gruß
Torsten
Hallo Torsten,
mit UDM hat das Modul noch nie funktioniert. Da ich kein UDM habe ist es auch schwierig dagegen zu programmieren. Ich kann gerne dabei unterstützen. Es müsste sich aber jemand mit UDM finden, der sich traut ein wenig Perl zu programmieren. Die zu ändernden Stellen habe ich im Post und Anhang vor drei Posts markiert.
Viele Grüße,
Dirk
Für mich funktioniert es immer noch....ich habe ein UDM-Pro mit FW 1.70 mit Contoller 5.13.27.
Was kann das erklären? Warum funktioniert es nur für mich?
Mein Unifi GUI ist auf Englisch, ich habe "Enable WebSocket connection" angeschaltet, Cloud Zugriff angeschaltet... was wäre noch relevant?
Mein FHEM ist auf einem 64bit x86 Ubuntu 20.03 LTS VM (in einem QNAP NAS).
FHEM Server und UDM sind im selben VLAN.
FHEM und UDM reden über Port 443.
Ich schalte meine POE Ports (IP Cams, APs, und einige Switches) mit FHEM an und aus..ich habe einige POE Switches. Anwesenheit funktioniert auch.
Also ich habe die gleichen Einstellungen, auch UDM Pro, nur läuft mein FHEM auf 16.04 64bit.
Cloud access lässt sich auf dem UDM eigentlich ja gar nicht ändern, jedenfalls finde ich keine Einstellungsmöglichkeit dazu.
Da ich jedoch remote über ui.com auf das UDM zugreifen kann, muss es ja enabled sein.
Ich kann gerne vieles ausprobieren und testen - habe aber leider von Programmiersprachen (Perl) nicht wirklich gute Kenntnisse.
@okenny
welches Modul verwendest du ? "original" 3.4.0 oder das letzte hier aus dem Post ?
um sicher zu sein welche ich habe, habe ich mein 74_Unifi.pm mit WinSCP runtergeladen und hier im Anhang hochgeladen.
Die ist Inhalts-identisch zu der meinen.
Ich habe zwischenzeitlich auch alle Ports versucht, welche offen stehen - ohne Erfolg.
Dann bin ich jetzt erst einmal am Ende meiner Ideen, erst recht, weil es bei dir geht - was ich dir sehr gönne :) .
Fall weitere Ideen auftauchen bin ich gerne weiter zum Testen bereit.
Torsten
Hoi, hab zwar keine UDM,aber habt Ihr schon euere Defines vom Unifi Device verglichen ? Wenn das Modul passt, wäre das auch ne Idee :)
Ronny
aus der fhem.cfg:
define UDM Unifi 192.168.10.20 443 crypt:450e5a405205 crypt:7e45680e743d7e5c
(die crypt sind natürlich nicht meine echten :) )
Torsten
So, ich hab mich noch mal hingesetzt.
Das Modul von Wuehler lässt sich nicht laden.
Das letzte was Maui online gestellt hat bringt mir folgende Fehlermeldung
Zitat(Unifi_Login_Receive) - Login Failed! - state:'error.decode_json' - msg:'malformed JSON string, neither tag, array, object, number, string or atom, at character offset 1 (before "<!doctype html>\n<ht...") at ./FHEM/74_Unifi.pm line 923. '
In der Zeile 923 steht folgendes
Zitateval { $data = decode_json($data); 1; } or do { $data = { meta => {rc => 'error.decode_json', msg => $@} }; };
Benutze ich das Modul von okenny bekomme ich folgendes
Zitat(Unifi_Login_Receive) - Login Failed! Invalid username or password! - state:'error' - msg:'api.err.Invalid'
Ich steig da noch nich so wirklich durch... Was fehlt mir in Zeile 923?
Ciao, Lee
Hallo,
das das Modul von Wuehler nicht geht, ist klar, das ist ja noch nicht für UDM vorbereitet, das war ja ein Mod vom okenny, das solltest Du also für alle Tests natürlich nutzen, bis es im offiziellen drin ist.
Dir fehlt da auch nix, es heisst nur, das es kein JSON ist,was zurückkommt. Das ist auch zu erwarten ;)
Also beim okenny Modul scheint es wohl Daten zu bekommen, allerdings zeigen die,das ein Login gescheitert ist. Sicher, das Du auch korrekte Daten angegeben hast ?
Also Modul von okenny runterladen in den entsprechenden FHEM Ordner, dann ein "shutdown restart" und dann schauen.
Ggf auch mal einen 2. Unifi Device nochmal komplett neu anlegen, ob das dann direkt klappt. Und ein List kam von Dir auch nicht bisher ^^
Ronny
@rcmcronny.
User/Pass is korrekt.
Mit der Aussage dass das Modul von Wuehler nicht lädt heißt dass es garnicht startet.
Das löschen/anlegen hab ich probiert.
Es tut nicht. Auch hab ich das logging auf 5 gestellt dass ich alles logge im Modul, aber mehr als das was ich zitierte kam nicht!
Moin,
wie schon geschrieben gab es eine Änderung beim Login (andere URL sowie vermutlich csrf-Token und nur die cookies senden, die erwartet werden (cookie_jar). Warum das bei okenny funktioniert weiß ich nicht (vielleicht gab es die Änderungen erst ab einer bestimmten FW-Version?).
Vielleicht gehts aber auch einfacher:
msg:'api.err.Invalid' deutet auf eine weitere Anpassung hin:
ersetzt mal in okennys Version die Zeile
$logindata = '{"username":"'.$user.'", "password":"'.$password.'"}';
durch
$logindata = '{\"username\":\"'.$user.'\", \"password\":\"'.$password.'\"}';
Vielleicht passt es dann wieder. Könnte an unterschiedlichen Passwörtern liegen, dass es bei dem einen funktioniert und beim anderen nicht.
Hallo,
habe deinen Vorschlag umgesetzt - (weiterhin disconnected) nun kommt:
2020.05.24 13:40:22 5: UDM3 (Unifi_Notify) - executed.
2020.05.24 13:40:22 5: UDM3 (Unifi_Notify) - checking 1 state
2020.05.24 13:40:22 5: UDM3 (Unifi_Notify) - executed. - Remove all Timers & Call DoUpdate...
2020.05.24 13:40:22 5: UDM3 (Unifi_DoUpdate) - executed.
2020.05.24 13:40:22 5: UDM3 (Unifi_Login_Send) - executed.
2020.05.24 13:40:22 5: UDM3 (Unifi_initCustomClientReadings) - parsed part: . -> ^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime
2020.05.24 13:40:22 5: UDM3 (Unifi_initCustomClientReadings) - parsed Attribute customClientReadings: {"attr_value":".:^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime","parts":{"0000000_part":{"nameRegEx":".","ReadingRegEx":"^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime"}}}.
2020.05.24 13:40:22 5: UDM3 (Unifi_Login_Receive) - executed.
2020.05.24 13:40:22 5: UDM3 (Unifi_Login_Receive) - Failed with HTTP Code 500!
2020.05.24 13:40:22 5: UDM3 (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2020.05.24 13:40:23 5: UDM3 (Unifi_Notify) - executed.
Fehler 500 heißt ,,internal server error". Jetzt braucht man das server.log vom Unifi. Da könnte dein stehen, was falsch ist.
Hi - sorry wenn ich die Logs nicht wirklich interpretieren kann :-) ...
[2020-05-24T16:54:10,573] <webapi-489> ERROR [ApiServlet] - Servlet.service() for servlet [ApiServlet] in context with path [] threw exception java.lang.RuntimeException: Error parsing json: JsonParseException: line: 1 char: 2 at com.ubnt.data.X.parseJSON(Unknown Source) ~[ace.jar:?] at com.ubnt.data.X.parseJSON(Unknown Source) ~[ace.jar:?] at com.ubnt.ace.api.ApiServlet.o00000(Unknown Source) ~[ace.jar:?] at com.ubnt.ace.api.ApiServlet.service(Unknown Source) ~[ace.jar:?] at javax.servlet.http.HttpServlet.service(HttpServlet.java:741) ~[tomcat-embed-core-8.5.51.jar:8.5.51] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) ~[tomcat-embed-core-8.5.51.jar:8.5.51] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[tomcat-embed-core-8.5.51.jar:8.5.51] at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) ~[tomcat-embed-websocket-8.5.51.jar:8.5.51] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) ~[tomcat-embed-core-8.5.51.jar:8.5.51] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[tomcat-embed-core-8.5.51.jar:8.5.51] at com.ubnt.ace.view.AuthFilter.doFilter(Unknown Source) ~[ace.jar:?] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) ~[tomcat-embed-core-8.5.51.jar:8.5.51] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[tomcat-embed-core-8.5.51.jar:8.5.51] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199) [tomcat-embed-core-8.5.51.jar:8.5.51] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) [tomcat-embed-core-8.5.51.jar:8.5.51] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:543) [tomcat-embed-core-8.5.51.jar:8.5.51] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139) [tomcat-embed-core-8.5.51.jar:8.5.51] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81) [tomcat-embed-core-8.5.51.jar:8.5.51] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87) [tomcat-embed-core-8.5.51.jar:8.5.51] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) [tomcat-embed-core-8.5.51.jar:8.5.51] at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:609) [tomcat-embed-core-8.5.51.jar:8.5.51] at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) [tomcat-embed-core-8.5.51.jar:8.5.51] at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:818) [tomcat-embed-core-8.5.51.jar:8.5.51] at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1623) [tomcat-embed-core-8.5.51.jar:8.5.51] at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-embed-core-8.5.51.jar:8.5.51] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_252] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_252] at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-embed-core-8.5.51.jar:8.5.51] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252] Caused by: com.fasterxml.jackson.core.JsonParseException: Unexpected character ('\' (code 92)): was expecting double-quote to start field name at [Source: (String)"{\"username\":\"BENUTZER\", \"password\":\"PASSWORT\"}"; line: 1, column: 3] at com.fasterxml.jackson.core.JsonParser._constructError(JsonParser.java:1840) ~[jackson-core-2.10.0.jar:2.10.0] at com.fasterxml.jackson.core.base.ParserMinimalBase._reportError(ParserMinimalBase.java:712) ~[jackson-core-2.10.0.jar:2.10.0] at com.fasterxml.jackson.core.base.ParserMinimalBase._reportUnexpectedChar(ParserMinimalBase.java:637) ~[jackson-core-2.10.0.jar:2.10.0] at com.fasterxml.jackson.core.json.ReaderBasedJsonParser._handleOddName(ReaderBasedJsonParser.java:1781) ~[jackson-core-2.10.0.jar:2.10.0] at com.fasterxml.jackson.core.json.ReaderBasedJsonParser.nextFieldName(ReaderBasedJsonParser.java:932) ~[jackson-core-2.10.0.jar:2.10.0] at com.fasterxml.jackson.databind.deser.std.BaseNodeDeserializer.deserializeObject(JsonNodeDeserializer.java:249) ~[jackson-databind-2.10.0.jar:2.10.0] at com.fasterxml.jackson.databind.deser.std.JsonNodeDeserializer.deserialize(JsonNodeDeserializer.java:68) ~[jackson-databind-2.10.0.jar:2.10.0] at com.fasterxml.jackson.databind.deser.std.JsonNodeDeserializer.deserialize(JsonNodeDeserializer.java:15) ~[jackson-databind-2.10.0.jar:2.10.0] at com.fasterxml.jackson.databind.ObjectMapper._readTreeAndClose(ObjectMapper.java:4254) ~[jackson-databind-2.10.0.jar:2.10.0] at com.fasterxml.jackson.databind.ObjectMapper.readTree(ObjectMapper.java:2711) ~[jackson-databind-2.10.0.jar:2.10.0] ... 29 more
Ich habe die Benutzerdaten durch BENUTZER und PASSWORT geändert ...
Sorry, da habe ich daneben getippt. Er beschwert sich über Zeichen 2 (also den \ ). Durch die Nutzung der einfachen Anführungsstriche war es ja auch schon im Original so, dass die " mitgesendet wurden. Mein Fixvorschlag war also sinnfrei.
Jetzt hilft am Besten, wenn ihr mit den Entwicklungstools von Chrome (Strg + Umschalt + I, Dann Network -> XHR) mal in die Daten, die euer Browser an den unifi-Controller beim Anmelden sendet reinschaut. Wenn beim Login andere Daten als die folgenden gesendet werden (Username und Passwort natürlich anders) bitte melden:
{"username":"DER_USER", "password":"DAS_PASSWORT"}
Da könnte auch ein Leerzeichen wichtig sein.
Hello again ...,
also hier das was ich sehen kann:
Request URL: https://192.168.10.20/api/auth/login
Request Method: POST
Status Code: 200 OK
Remote Address: 192.168.10.20:443
Referrer Policy: no-referrer-when-downgrade
Accept-Ranges: bytes
Access-Control-Allow-Origin: https://192.168.10.20
Connection: keep-alive
Content-Length: 5584
Content-Type: application/json; charset=utf-8
Date: Mon, 25 May 2020 16:23:16 GMT
Set-Cookie: TOKEN=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJjc3JmVG7rZW4iOiJjMDU2NzE2NS1iZDk3LTQ5MDEtYWI1Zi03M2EzNzJmNDhhYTIiLCJ1c2VySWQiOiJhZGNlYjU0OC1hMTJjLTRkNDItODc1ZS1mOWUzMTM4YTYxNjIiLCJpYXQiOjE1OTA0MjM3OTYsImV4cCI1MTU5MDQyNzM5Nn0.VKZj3xcsLWrQbB9MMCDqG9sGFUKtHyAXjBOxF6AQrk8; path=/; secure; httponly
Strict-Transport-Security: max-age=15552000; includeSubDomains
Vary: Origin
X-Content-Type-Options: nosniff
X-DNS-Prefetch-Control: off
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Response-Time: 762ms
X-XSS-Protection: 1; mode=block
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: de,de-DE;q=0.9,en-US;q=0.8,en;q=0.7
Connection: keep-alive
Content-Length: 60
Content-Type: application/json; charset=utf-8
Cookie: TOKEN=eyJhbGciOiJIUzI1NiIsInR3cCI6IkpXVCJ9.eyJjc3JmVG9rZW4iOiJjMDU5NzE2NS1iZDk3LTQ5MDEtYWI1Zi07M2EzNzJmNDhhYTIiLCJ1c2VySWQiOm52bGwsImlhdCI6MTU5MDQyMzc1OSwiZXhwIjoxNTkwNDI3MzU5fQ.lDub22RxlSxnIaIm9aue2_wFOZuTOHt9XF00qMx_hDA
Host: 192.168.10.20
Origin: https://192.168.10.20
Referer: https://192.168.10.20/login?redirect=%2F
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.138 Safari/537.36
x-csrf-token: c0567165-bd97-4901-ab5f-73a372f48aa2
{username: "DER_USER", password: "DAS_PASSWORT"}
password: "DAS_PASSWORT"
username: "DER_USER"
weiterhin sehr gespannt ... auch wenn ich hier nix verstehe :-)
Spannend. In der dritten Zeile von unten fehlen die Anführungszeichen um username und passwort. Vielleicht darf man die bei deiner Version nicht mitsenden.
Hab die Anführungszeichen aus Zeile 903 rausgenommen und die Leerzeichen rein - kein Erfolg.
Log:
2020.05.25 18:44:12 5: UDM3 (Unifi_Login_Send) - executed.
2020.05.25 18:44:12 5: UDM3 (Unifi_Login_Receive) - executed.
2020.05.25 18:44:12 5: UDM3 (Unifi_Login_Receive) - Failed with HTTP Code 500!
2020.05.25 18:44:12 5: UDM3 (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
Alle Anführungszeichen oder nur die um die Worte vorm Doppelpunkt (wäre analog Originallogin)?
Hi,
ich habe nur die Anführungszeichen um die Worte vor den Doppelpunkt entfernt, und auch einmal die "fehlenden" Leerzeichen ergänzt.
Beide ohne Erfolg:
also erster Test mit:
$logindata = '{username:"'.$user.'", password:"'.$password.'"}';
zweiter Test mit:
$logindata = '{username: "'.$user.'", password: "'.$password.'"}';
Am Logeintrag in FEHM hat sich nicht geändert, im LOG des UDM steht jetzt:
... Unexpected character ('u' (code 117)): was expecting double-quote to start field name at [Source: (String)"{username:"DER_USER", password:"DAS_PASSWORT"}"; line: 1, column: 3] at com.faster ...
Gruß
Torsten
Demnach wird doch ein doppeltes Anführungszeichen um username erwartet. Seltsam.
Ich möchte mich nochmal melden. Würde das Modul gerne nutzen. Leider geht meine Prozessorlast nach 1-3 Tagen immer so hoch, dass ich FHEM nicht mehr nutzen kann.
Meine Umgebung ist dem Screenshot zu entnehmen.
Die Aktualisierung dauert immer 2-5 Sekunden.
Ist das Problem bekannt?
Hallo Gunther,
laufen FHEM und der Unifi-Controller zufällig auf dem selben RasPi? Setze zur Not im define ein höheres Interval. Wäre interessant, ob es dann immer noch zu den Problemen kommt.
Viele Grüße,
Dirk
Zitat von: topsecret99 am 25 Mai 2020, 22:35:46
Am Logeintrag in FEHM hat sich nicht geändert, im LOG des UDM steht jetzt:
Gruß
Torsten
Hey Torsten, kannst du mir bitte erklären wie du auf die LOG des UDMs zugreifst?
Ich habe mittlerweile FHEM auf einem dedizierten Raspi aufgesetzt und alle möglichen Dateien (z.b. die von okenny) durchprobiert als auch die ein oder andere Änderung am login getestet. Leider in allen Fällen nach wie vor "disconnected"
Teste mal weiter...
Grüße
Andi
Hi Andi,
im Controller-Einstellungen unter "Network Settings / Advanced / Remote Logging - die ersten 3 Schalter aktivieren.
Danach kannst du dann unter "Einblicke (Insights)" die Logs online verfolgen.
Gruß
Torsten
Hallo,
hier in dem Beitrag habe ich schon mehrere Varianten der ReadingsGroup gefunden. Ich möchte aber folgendes realisieren und komme hier nicht weiter.
Eine einfache Tabelle mit allen WiFi Geräten (sind ja als Reading vorhanden). Aber anscheinden ist es nicht möglich mit der ReadingsGroup mehrere Zeilen darzustellen. Jedes Gerät als eine Zeile. Natürlich möchte ich nicht händisch jeden Geräte/Readingsnamen manuell angeben müssen sondern per Regex.
<Gerätename>,<AP>,<SSID>,<RSSI>,<Letzte Verbindung>
SY_WiFi:.*_hostname,.*_accesspoint,.*_essid,.*_snr,.*_last_seen
Wäre es nicht generell sinnvoll mal ein paar Visualisierungen usw. in dem Wiki Eintrag des Unifi Modules hinzuzufügen?
Es ist ja schön, dass es so ein Modul gibt aber ohne vernünftige Anzeige in der Visu bringt es nichts :)
VG Sebastian
Da ich noch sowas wie "reconnect Client" (bzw. disconnect Client) machen wollte und auch wissen über welchen AP usw. habe ich für jedes Client-Device/Gerät (das mich interessiert) ein UnifiClient-Device angelegt und dann "darüber" eine readingsGroup...
Gruß, Joachim
Hallo Sebastian,
das kannst Du schon mit einer readings group erreichen. Die Definition sieht dann ungefähr so aus
controller:@1,(.*)_hostname,#1_accesspoint,...
Beste Grüße
Torsten
Zitat von: ToKa am 07 Juni 2020, 18:56:14
Hallo Sebastian,
das kannst Du schon mit einer readings group erreichen. Die Definition sieht dann ungefähr so aus
controller:@1,(.*)_hostname,#1_accesspoint,...
Beste Grüße
Torsten
Hi Torsten,
vielen Dank. Genau das habe ich benötigt.
Fhem ist einfach viel zu kompliziert, da muss man erst einmal druchblicken bei der Syntax der ReadingsGroup. Das mit "@1" konnte ich auch nicht in der Wiki oder Commandref finden.
Jetzt habe ich noch folgendes was du eventuell auch lösen kannst :)
Ich hätte derne den Gerätenamen des APs in der ersten Spalte
<Status>,<Gerätename>,<Clients>,<Last>,<SSIDs>
SY_WiFi:@1,-AP_(.*)_state,<#1>,-AP_#1_clients,-AP_#1_utilization,-AP_#1_essid
Als Workaround könnte ich mir ein neues UserReading im Controller Device generieren mit dem AP Name. Aber vieleicht geht das ja auch so :)
VG
Sebastian
Zitat von: okenny am 15 Mai 2020, 08:29:18
Seltsam.....bei mir gehts (siehe Bild).
ich habe UDM Pro, Cloud Access enabled, und Firmware 1.7.0 RC18
define UnifiController Unifi 192.168.1.1 443 user pw
Hey Okenny,
geht das Modul bei dir immernoch?
Ich bekomm es einfach nicht zum Laufen.... Denke ich habe die selben Probleme wie topsecret99.
--> 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.
Habe auch verschiedene $logindata Zeilen Versucht, alles erfolgos...
@Okenny: Nutzt du deinen Ubiquiti Account für den Login oder hast du auf der UDM einen lokalen User hierfür konfiguriert?
Zitat von: Andibar am 09 Juni 2020, 10:36:40
--> 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.
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
Zitat von: acw81 am 03 Juli 2020, 10:51:42
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
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 (https://wiki.fhem.de/wiki/PRESENCE#Beispiel_Anwesenheitserkennung_mittels_UniFi_Controller)
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}
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
Hallo Joachim,
kurze OT Frage...
Zitat von: MadMax-FHEM am 03 Juli 2020, 18:32:58
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
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:
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
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:
Zitat von: Wiki
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
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
Zitat von: Leo1973 am 12 August 2020, 09:30:09
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.
@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.
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)
curl -k --data '{"username":"DERUSER","password":"DASPW"}' --fail https://192.168.1.198:8443/api/auth/login
Zitat von: Maui am 12 August 2020, 15:20:08
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)
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:
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?
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? ;D
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...
Blind testen (ohne udm) ist halt immer blöd.
Kommst per ssh auf deine udm oder kommst sonst an die logs?
Hallo,
habe auch keine. Aber ich weiss, das bei der UDM das etwas anders gelöst wurde,da ja mehr als nur der Controller da rennt.
Probiere mal ein
curl -k --data '{"username":"DERUSER","password":"DASPW"}' --fail https://<IP>:8443/network/api/auth/login
Wenn das dann klappt muss man alles mit
https://<IP>:8443/proxy/network/api/...
aufrufen wohl.
EIn versuch ist es mal wert :)
Ronny
Denke nicht dass das was bringt.
Vielleicht liegt es einfach wirklich an den Keksen und dem csrf.
@Leo versuch mal folgendes:
curl -k -c /tmp/unifiCookie --cookie-jar /tmp/unifiCookie --data '{"username": "<mein Username>", "password": "<mein PW>"}' https://192.168.xxx.xxx:8443/api/auth/login
Jetzt hast du erst wirklich einen Keks im Glas. Damit wird es bestimmt auch nicht gehen.
Wenn du jetzt in einem editor (vi,nano) den cookie anguckst, kannst mal den csrf token kopieren.
In einem 2. aufruf dann ohne neuen Keks im glas (cookie-jar) aber mit Header.
curl -k -c /tmp/unifiCookie -H 'x-csrf-token: <Token>' --data '{"username": "<mein Username>", "password": "<mein PW>"}' https://192.168.xxx.xxx:8443/api/auth/login
Zitat von: rcmcronny am 12 August 2020, 19:49:18
Hallo,
habe auch keine. Aber ich weiss, das bei der UDM das etwas anders gelöst wurde,da ja mehr als nur der Controller da rennt.
Probiere mal ein
curl -k --data '{"username":"DERUSER","password":"DASPW"}' --fail https://<IP>:8443/network/api/auth/login
Wenn das dann klappt muss man alles mit
https://<IP>:8443/proxy/network/api/...
aufrufen wohl.
EIn versuch ist es mal wert :)
Ronny
Wenn ich Port 8443 nutze kommt direkt Connection refused. 8443 war der Port beim Cloud Key 2. Dort hat der Unifi Controller geantwortet (der Cloud Key 2 Plus hat ja auch das Unifi Protect mit drin wie jetzt die UDM auch).
Gerade lasse ich das interne Log der UDM mit"tailen". Seltsamerweise scheint lokal auf der UDM doch etwas zu "horchen":
Aug 12 20:55:47 ubnt user.info mcad: mcad[1697]: ace_reporter.reporter_save_config(): Saving stun_url as stun://localhost/
Aug 12 20:55:47 ubnt user.info mcad: mcad[1697]: ace_reporter.reporter_save_config(): Saving mgmt_url as https://localhost:8443/manage/site/default
Aug 12 20:55:47 ubnt user.info mcad: mcad[1697]: ace_reporter.reporter_handle_response(): [setparam] applying new system.cfg
Aug 12 20:55:48 ubnt user.notice syswrapper: [apply-config] using fast apply
Das mit dem Cookie bringt leider gar keine Änderung.
Vielleicht lasse ich das Thema einfach ein paar Tage liegen und betoniere im Garten ein paar Randsteine. 8)
Ach stimmt, das ist bei der UDM auch anders.
Probiere doch mal die beiden: (Theor sollte es reichen, das in den Browser zu hauen und die Rückmeldung anzuschauen, wenn was kommt kann man das Curl anpassen und es so nochmal probieren.
https://ip/proxy/network/api/auth
https://ip/network/api/auth
Intern hört der Controller auf localhost:8443 die UDM leitet das dann weiter.
Mehr Ideen habe ich aber auch nicht, ohne die Unifi Api anzuschauen :D
Ronny
Die UDM müsste direkt auf 443 lauschen. Sollte also ein https reichen und das :8443 kann weg.
@Wuehler: hier sollte mehr oder weniger ein Faden ersichtlich sein, was für die UDM umgebaut werden muss.
https://github.com/Art-of-WiFi/UniFi-API-browser/blob/994d9226b49f47c50a94d2d2e09eb8b4b9f99f66/vendor/art-of-wifi/unifi-api-client/src/Client.php (https://github.com/Art-of-WiFi/UniFi-API-browser/blob/994d9226b49f47c50a94d2d2e09eb8b4b9f99f66/vendor/art-of-wifi/unifi-api-client/src/Client.php)
Zitat von: Leo1973 am 12 August 2020, 13:15:47
@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.
Enable WebSocket hab ich nun gefunden:
Der Schalter hierfür findet sich in den Controller-Einstellungen unter Benutzer Interface/User Interface in der Sektion Daten. Dort gibt's nen Schalter für WebSocket-Verbindung erlauben.
Nur so als Info...
Da es heute regnet und ich nun keine Randsteine im Garten betonieren kann hab ich mich nochmal dran gemacht.
Auf Anregung von Maui (Danke Dir an der Stelle für die Anregung) hab ich mir den UniFi-Api-Browser runtergeladen und an meinem Apache-Server eingehängt, konfiguriert und siehe da:
Funktioniert auf Anhieb!
Also kann ich auf jeden Fall schon mal ausschließen dass hier ein genereller Fehler an der UDM bzw. deren Firmware oder Konfiguration vorliegt.
Die Frage ist nur: Wie adaptiere ich die Anmeldungsprozedur so wie diese vom Unifi-Api-Browser abgesetzt wird und baue dementsprechend meine Bashscripts um damit ich diese wieder verwenden kann.
Im Prinzip sind es zwei Scripts die ich von Loxone aus über den Loxberry aufrufe um zwei Unifi-WLan Access-Points nachts ab- bzw. wieder anzuschalten.
Weiterhin offen ist ja die Anmeldeprozedur für das 74_Unifi-Modul... hat mir jemand von euch eine Anregung?
Ich vermute, dass es schon fast geht. Evtl. Fehlt noch die base64 dekodierung.
Siehe php code
return json_decode(base64_decode($jwt_payload))->csrfToken;
Freut mich dass hier wieder Schwung in die Sache kommt. Ich habe es leider auch noch nicht zum Laufen gebracht mit meinem UDM Pro. Wenn es die Zeit zulässt werde ich die Tage nochmals eure letzten Hinweise durcharbeiten und testen.
Grüße
Andi
Zitat von: Leo1973 am 13 August 2020, 17:05:26
Weiterhin offen ist ja die Anmeldeprozedur für das 74_Unifi-Modul... hat mir jemand von euch eine Anregung?
Die Anmeldung muss wohl direkt an der UDM erfolgen.
Sprich "https://ip-der-udm:443" und im Anschluss kann man dann auf die Api zugreifen via "/proxy/network....."
So zumindest meine Vermutung.
Hallo zusammen,
auch ich habe eben das angepasste Modul für die UDM Pro getestet. Leider ebenfalls ohne Erfolg.
Invalid user or password. Es scheint in der Tat an der Authentifizierung zu liegen.
Es wäre schön wen die UDM auch mit dem Modul laufen würde. Das müsste doch eigentlich irgendwie gehen.
Bei Bedarf helfe ich gerne.
Ich konnte dem Angebot (196€) nicht widerstehen und habe meinen Controller (unter Windows) und den USG gegen eine UDM Pro getauscht.
Der Umzug funktionierte erstaunlicherweise problemlos, nur beim Umstellen des Unifi Modul kam dann die Überraschung.
Leider funktioniert jetzt auch meine Anwesenheitserkennung nicht mehr. :-\
Gib es schon Neuigkeiten ?
das hier https://ubntwiki.com/products/software/unifi-controller/api schon gelesen?
Leider kann ich mich per REST Client bzw. curl nicht anmelden:
curl -k -i 'https://192.168.x.x/api/auth/login' --data '{"username":"xxx","password":"yyy","rememberMe":false}'
HTTP/1.1 401 Unauthorized
Vary: Origin
X-DNS-Prefetch-Control: off
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=15552000; includeSubDomains
X-Download-Options: noopen
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Accept-Ranges: bytes
X-CSRF-Token: caxxx5f9-b50f-44xx-b5xx-cf01dxxfxxc4
Content-Type: application/json; charset=utf-8
Content-Length: 56
X-Response-Time: 54ms
Set-Cookie: TOKEN=zQiLCJpYXQiOjE1OCI6MTU5OTU3NDU0NH0.aBlihFuj8m-7rVXaw81thh5VEz8; path=/; secure; httponly
Date: Tue, 08 Sep 2020 13:15:44 GMT
Connection: keep-alive
{
"errors": [
"Invalid username or password"
]
In der Web-Konsole des Firefox sehe ich, daß die Anmeldeseite der UDM-Pro diese Daten per POST an genau diese URL schickt.
Den Status hingegen kann ich abfragen:
curl -k -i 'https://192.168.x.x/proxy/network/status'
HTTP/1.1 200 OK
Vary: Origin
X-DNS-Prefetch-Control: off
x-frame-options: DENY
Strict-Transport-Security: max-age=15552000; includeSubDomains
X-Download-Options: noopen
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Accept-Ranges: bytes
X-CSRF-Token: 3b4dxxxx-40xx-44xx-a0xx-2dxx4cxx7dxx
content-type: application/json;charset=UTF-8
content-length: 320
date: Tue, 08 Sep 2020 13:29:11 GMT
connection: close
Set-Cookie: TOKEN=TdkMzEiLCJpYXQiMTU5OTU3NTM1MX0.BOrTmY_OmP9kKhFL0EiROy7arnvY; path=/; secure; httponly
{"meta":{"rc":"ok","uuid":"46bxxxxx-9bxx-5xxf-86xx-xxb2xff2ccxa","server_version":"5.14.22","server_running":true,"db_running":true,"db_connected":true,"db_journaling":false,"db_repairing":false,"db_importing":false,"db_importing_at":-1,"db_importing_name":null,"ucore_installation":true,"udm_connected":true},"data":[]}
Hat jemand einen Weg gefunden sich erfolgreich an der UDM bzw. UDM Pro anzumelden ?
Ich kann gerne Anpassungen testen.
Also als POST request funktioniert es:
curl -k -X POST -H "Content-Type: application/json" -i 'https://192.168.x.x/api/auth/login' --data '{"username":"xxx","password":"yyy","rememberMe":false}'
Mit diesem Patch funktioniert das Modul für mich mit der UDM Pro:
From 5995e6db43863722e6bc4525ec0e048238994454 Mon Sep 17 00:00:00 2001
From: Michael Kunzmann <michael.kunzmann@gmail.com>
Date: Sat, 12 Sep 2020 14:21:47 +0200
Subject: [PATCH] allow unifi for UDM Pro - breaks normal controllers
---
fhem/FHEM/74_Unifi.pm | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/fhem/FHEM/74_Unifi.pm b/fhem/FHEM/74_Unifi.pm
index 172877050..f703eda6f 100644
--- a/fhem/FHEM/74_Unifi.pm
+++ b/fhem/FHEM/74_Unifi.pm
@@ -209,7 +209,7 @@ sub Unifi_Define($$) {
CONNECTED => 0,
eventPeriod => int(AttrVal($name,"eventPeriod",24)),
interval => $a[6] || 30,
- url => "https://".$a[2].(($a[3] == 443) ? '' : ':'.$a[3]).'/api/s/'.(($a[7]) ? $a[7] : 'default').'/',
+ url => "https://".$a[2].(($a[3] == 443) ? '' : ':'.$a[3]).'/proxy/network/api/s/'.(($a[7]) ? $a[7] : 'default').'/',
},
);
$hash->{httpParams} = {
@@ -899,13 +899,15 @@ sub Unifi_Login_Send($) {
my $password = $hash->{helper}{password};
$user = Unifi_decrypt( $user );
$password = Unifi_decrypt( $password );
- ( $loginurl = $hash->{unifi}->{url} ) =~ s/api\/s.+/api\/login/;
- $logindata = '{"username":"'.$user.'", "password":"'.$password.'"}';
+ ( $loginurl = $hash->{unifi}->{url} ) =~ s/proxy\/network\/api\/s.+/api\/auth\/login/;
+ $logindata = '{"username":"'.$user.'", "password":"'.$password.'", "rememberMe":true}';
HttpUtils_NonblockingGet( {
%{$hash->{httpParams}},
url => $loginurl,
data => $logindata,
+ method => "POST",
+ header => "Content-Type: application/json",
callback => \&Unifi_Login_Receive
} );
return undef;
@@ -922,7 +924,7 @@ sub Unifi_Login_Receive($) {
if ($param->{code} == 200 || $param->{code} == 400 || $param->{code} == 401 || $param->{code} == 200) {
eval { $data = decode_json($data); 1; } or do { $data = { meta => {rc => 'error.decode_json', msg => $@} }; };
- if ($data->{meta}->{rc} eq "ok") {
+ if ($data->{meta}->{rc} eq "ok" || $data->{username} ne '') {
Log3 $name, 5, "$name ($self) - state=ok";
$hash->{httpParams}->{header} = '';
for (split("\r\n",$param->{httpheader})) {
--
2.24.3 (Apple Git-128)
Falls jemand das "vernünftig" ins Modul einbauen kann würde ich mich freuen.
Leider reichen meine Perl/FHEM Kenntnisse dazu noch nicht aus.
Als diff code schnipsel ist zwar super, aber häng mal bitte die komplette Datei an also die geänderte.
Dann können das leichter andere "weniger versierte" testen ;)
Gerne auch noch die komplette Datei.
Wie muss denn das define dazu nun sein? Also welcher Port? Wollte das ganze gerade einmal testen, ohne Port jedoch nimmt er das ncht an...
habs mit 443 gemacht, läuft ... und die Anwesenheitskennung auch wieder !
Zitat von: knochenmuehle am 12 September 2020, 16:21:48
habs mit 443 gemacht, läuft ... und die Anwesenheitskennung auch wieder !
Heißt:
IP Port User Passwort
192.168.19.1 443 User Passwort
?
EDIT: Ich sollte auch die richtige IP der UDM angeben und nicht den vom alten Controller :-X Ja so wie oben angegebn läuft es nun, danke! ;D
Läuft, Danke!
Wobei ich von der UDM-Pro z.Z. noch nicht überzeugt bin. Der WAN-Durchsatz ist wohl mit aktiviertem IPS höher, aber dafür fehlt der interne SNTP-Server und der Controller ist langsamer als unter Windows.
Mal abwarten, was Ubiquiti mit den nächsten Updates noch nachliefert.
Liefert der Controller der UDM bei euch Readings zu den APs?
Vorher waren Readings beginnend mit -AP_ da, die kommen bei mir jetzt nicht mehr.
Und bei den WLAN-Clients steht jetzt der verwendete AP im Reading xxx_accesspoint immer auf unknown, die SSID wird im Reading xxx_essid geliefert.
Neue Version. Diesmal kommen auch die APs wieder.
Es scheint die UDM Pro akzeptiert für manche API aufrufe nur GET und nicht POST.
Musste das in
Unifi_GetUnarchivedAlerts_Send
Unifi_GetEvents_Send
Unifi_GetAccesspoints_Send
noch anpassen.
Klasse, jetzt funktioniert auch meine Anwesenheitserkennung wieder vollständig, inkl. Verbindungs-AP.
Jetzt muss nur noch jemand das per Attribut und if einschränken, sodass es getestet werden kann, ob die Anpassungen (ohne url) bei allen ohne udm pro auch gehen.
Moin,
Klasse, dass sich ein UDM-Besitzer gefunden hat, das Modul anzupassen. Das Einarbeiten werde ich versuchen zeitnah zu übernehmen.
Viele Grüße, Dirk
Ich nutze eine UDM (ohne Pro) in 1.8.1 rc3 und mit Controller Version 6.0.20.
Das Modul läuft bei mir.
Vielen Dank für die Anpassung des Moduls für die UDM.
Hallo zusammmen,
da mir an anderer Stelle geraten wurde meine Frage hier zu posten hoffe ich auf Tips zur Lösung....
Mein Fhem läuft auf einem Raspi und ist aktuell
Mein Unifi läuft auf einem Cloudkey Gen2 und ist ebenfalls aktuell
Seit einiger Zeit habe ich das Problem, dass mein Handy nicht mehr korrekt in Fhem erkannt wird und so meine Anwesenheitsautomatik nicht geht.
Im Unifi selbst wird der Status korrekt angezeigt. Im Unifi-Device in Fhem passieren willkürlich folgende Dinge:
- das Handy hat den State Unknowen
- das Handy wechselt minütlich von diconnected auf connected egal ob ich da bin oder nicht => ich bin für Fhem dauerhaft connected
- das Handy wechselt minütlich von connected auf disconnected egal ob ich da bin oder nicht => ich bin für Fhem dauerhaft disconnected
Starte ich Fhem oder das Unifi Modul oder UNifi selbst neu, kann es sein, dass es funktoiniert.
Kennt jemand das Problem, was braucht ihr noch für Angaben?
Danke und Gruß
H-man
Hallo H-man,
ich kann mich dunkel daran erinnern, dass irgendjemand schon mal so ein Problem hatte. Lösung war glaube ich, dass es die Mac oder client im Unifi-Controller zwei mal gab. Musst du mal unter Insights suchen und den falschen löschen.
Ggf. zusätzlich mal ein clear all im Modul.
VG,
Dirk
Zitat von: kunze am 13 September 2020, 18:06:07
Neue Version. Diesmal kommen auch die APs wieder.
Es scheint die UDM Pro akzeptiert für manche API aufrufe nur GET und nicht POST.
Musste das in
Unifi_GetUnarchivedAlerts_Send
Unifi_GetEvents_Send
Unifi_GetAccesspoints_Send
noch anpassen.
Moin,
ich habe ebenfalls eine UDMP. Diese Version von dir ist schon mal besser als die vorher hier gepostete Version (die hat die Switche nicht angelegt).
Die Switche wurden nun angelegt, allerdings sind bei dieser Version die Werte
-UC_speed_down, -UC_speed_ping, -UC_speed_up alle "0" (Das ging vorher noch).
Zitat von: ComputerZOO am 15 September 2020, 20:51:47
Moin,
ich habe ebenfalls eine UDMP. Diese Version von dir ist schon mal besser als die vorher hier gepostete Version (die hat die Switche nicht angelegt).
Die Switche wurden nun angelegt, allerdings sind bei dieser Version die Werte -UC_speed_down, -UC_speed_ping, -UC_speed_up alle "0" (Das ging vorher noch).
Bist Du dir sicher? Bei mir werden da Werte angezeigt, eben auch nochmal Manuell einen Geschwindigkeitstest ausgelöst, da werden die Werte auch ins Modul geschrieben
Bei mir sieht das auch gut aus.
ZitatMoin,
ich habe ebenfalls eine UDMP. Diese Version von dir ist schon mal besser als die vorher hier gepostete Version (die hat die Switche nicht angelegt).
Die Switche wurden nun angelegt, allerdings sind bei dieser Version die Werte -UC_speed_down, -UC_speed_ping, -UC_speed_up alle "0" (Das ging vorher noch).
Zitat von: Fillip am 15 September 2020, 21:03:49
Bist Du dir sicher? Bei mir werden da Werte angezeigt, eben auch nochmal Manuell einen Geschwindigkeitstest ausgelöst, da werden die Werte auch ins Modul geschrieben
Und schwupps, kaum macht man einen (manuell ausgelösten) Speedtest, schon kommen da Werte. 8)
Danke für den Tip.
Aber ich hätte da noch nen paar Fragen:
1: Kann man die Health-Werte (Temperatur, Lüfter etc.) auch auslesen?
2: In der UDM( P ) ist ja auch nen 8-Port Switch, kann der auch ausgelesen, oder als UniFi-Switch-Device angelegt werden?
Edit: habe gerade mal im UniFi-API-Browser geschaut, die Werte werden wohl nicht zur Verfügung gestellt...
Hallo,
habe gestern ein Update auf 6.0.20 gemacht und bin heute in einen Broadcast storm gelaufen. Kann nur jedem empfehlen das upgrade nicht zu machen.
https://community.ui.com/questions/Broadcast-storm-after-Unifi-controller-upgrade-to-6-0-20/0b924047-0632-4304-bada-4158a0a5349e
(https://community.ui.com/questions/Broadcast-storm-after-Unifi-controller-upgrade-to-6-0-20/0b924047-0632-4304-bada-4158a0a5349e)
Gruß
Eisix
Zitat von: ComputerZOO am 15 September 2020, 22:07:04
Aber ich hätte da noch nen paar Fragen:
1: Kann man die Health-Werte (Temperatur, Lüfter etc.) auch auslesen?
2: In der UDM( P ) ist ja auch nen 8-Port Switch, kann der auch ausgelesen, oder als UniFi-Switch-Device angelegt werden?
Denke eher nicht, da die Werte der UDM Hardware erst mal nichts mit dem Controller zu tun haben.
Zitat von: Eisix am 16 September 2020, 16:51:41
habe gestern ein Update auf 6.0.20 gemacht und bin heute in einen Broadcast storm gelaufen. Kann nur jedem empfehlen das upgrade nicht zu machen.
gibt mittlerweile eine 6.0.22.
Weis jemand ob der Broadcast storm bug gefixt ist?
bin noch auf der 5.14.23 und möchte vermeiden in das gleiche Problem zu laufen. :-)
Zitat von: Frank_Huber am 17 September 2020, 15:36:18
gibt mittlerweile eine 6.0.22.
Weis jemand ob der Broadcast storm bug gefixt ist?
bin noch auf der 5.14.23 und möchte vermeiden in das gleiche Problem zu laufen. :-)
Dann bleib halt (wie ich) (erst mal) "da" ;)
Gruß, Joachim
Zitat von: MadMax-FHEM am 17 September 2020, 16:21:53
Dann bleib halt (wie ich) (erst mal) "da" ;)
Das ist der Plan bis der Bug bestätigt behoben ist. ;-)
Ich würde noch ein/zwei Wochen warten, warum Tester spielen, wenn die 'alte' Version zuverlässig läuft.
Hat sich bei mir (auch bei Firmwareupdates) als nervenschonender gezeigt, gerade in den letzten Monaten erscheint mir die Qualitätssicherung bei Ubiquiti nicht ausreichend.
Hallo,
bin gestern auf der 6.0.20 geblieben, habe die Wlan Netze neu angelegt alle AP raus und wieder rein.
Ich vermute
Multicast and Broadcast Filtering
Block LAN to WLAN Multicast and Broadcast Data
hat es dann endlich gebracht. Der Aufwand sollte nicht nötig sein zumal noch weitere Bugs in der Version sind, ein offensichtlicher ist das die Netzwerktopologie nicht mehr angezeigt wird, ist aber nicht tragisch.
Bei den readings in Fhem könnte sich auch was geändert haben da im meine FTUI der status des WLAN nicht mehr korrekt angezeigt wird, hatte aber noch keine Zeit das zu checken.
Weiter Updates werde ich jetzt erstmal nicht machen und kann auch jedem anderen raten nicht auf 6.0.XX zu gehen wenn es keine zwingenden Grund dafür gibt.
Denke in 2-3 Wochen wird sich das ganze stabilisiert haben.
Gruß
Eisix
Gemäß UI Forum sollte es reichen die vom Update angelegten VLANs zu löschen.
also erstmal alles abklemmen, VLAN löschen, und dann die APs nacheinander wieder anstecken.
Für die 6.0.22 kann man in den Rel Notes nachlesen dass die VLANs nicht mehr angelegt werden.
Damit sollte es eigentlich safe sein.
sollte....
wer traut sich als erstes? ;-)
Haha,
erstmal noch Löschen können. Mir hat es den Netzwerkport komplett ausgeblasen. Reboot hat nichts gebracht, musste den Strom kappen, danach ging es wieder.
Gruß
Eisix
Zitat von: Eisix am 17 September 2020, 16:45:38
erstmal noch Löschen können. Mir hat es den Netzwerkport komplett ausgeblasen. Reboot hat nichts gebracht, musste den Strom kappen, danach ging es wieder.
dafür sollte es reichen die Geräte abzuziehen. die verursachen wohl einen broadcast sturm.
Langsam sollten "wir" den Thread "damit" verlassen...
...weil es ja (wenn überhaupt) nur ganz entferntest (evtl. Readings anders) noch mit dem Modul zu tun hat... ;)
Gruß, Joachim
Hi Wühler...
Danke für die Rückmeldung
Das Endgerät (iPhone) ist im Controller und in allem was ich prüfen konnte nicht doppelt. Zumal ich es auch neu mit alias und Hostnamen angelegt hatte.
Getreu dem Motto No Risk No Fun habe ich heute direkt mal iOS14 draufgebügelt.
Aktuell wird der Status korrekt angezeigt - ohne fhem oder CloudKey zu ändern.
Meine Frau hat das gleiche Modell und ,,leider" nicht die gleichen Probleme deswegen habe ich leider nicht wirklich herausgefunden woran es liegt.
Gerne liefere ich aber alle gewünschten Informationen zur weiteren Analyse
Gruß
H-Man
Zitat von: ComputerZOO am 15 September 2020, 22:07:04
1: Kann man die Health-Werte (Temperatur, Lüfter etc.) auch auslesen?
2: In der UDM( P ) ist ja auch nen 8-Port Switch, kann der auch ausgelesen, oder als UniFi-Switch-Device angelegt werden?
Edit: habe gerade mal im UniFi-API-Browser geschaut, die Werte werden wohl nicht zur Verfügung gestellt...
Kannst du bitte verbose auf 5 stellen und mir das Log per pm senden. Dann kann ich mal schauen, ob man zusätzlich ein FHEM-UnifiSwitch-Device anlegen lassen kann, wenn die UDM dazu dieselben Strukturen zurückliefert wie bei den anderen Switches. Dann wäre u.a. auch Temperatur usw. dabei.
Komme hoffentlich am Wochenende mal dazu den Patch einzubauen.
Zitat von: Wuehler am 17 September 2020, 22:37:55
Kannst du bitte verbose auf 5 stellen und mir das Log per pm senden. Dann kann ich mal schauen, ob man zusätzlich ein FHEM-UnifiSwitch-Device anlegen lassen kann, wenn die UDM dazu dieselben Strukturen zurückliefert wie bei den anderen Switches. Dann wäre u.a. auch Temperatur usw. dabei.
Komme hoffentlich am Wochenende mal dazu den Patch einzubauen.
Danke für das Hilfsangebot, aber ich glaube da brauchst du (z.Zt.) keine Mühen investieren, habe mir die JSONs die der Controller liefert mit dem UniFi API-Browser mal angesehen, da ist leider nix dabei.
OK. Kannst du mal nachsehen, was bei der UDM unter type steht? Bei Switches es es usw, bei Accesspoints uap. Brauche die Info um für eine UDM ggf. ein zusätzliches Switch-Device anlegen zu können.
Das war vielleicht etwas zu schnell geschrieben. In FHEM kannst du den type des Unifi-Devices nirgendwo erkennen. Daher bitte einmal am Unifi-Controller/UDM anmelden und auf devices gehen.
Dann:
1. STRG + SHIFT + I (Entwicklertools öffnen sich)
2. Dort unter Netzwerk auf XHR klicken
3. Reload im Browser klicken
4. In der Liste auf "device-basic" klicken
5. Im rechten Teil auf Response klicken
6. Die Daten kopieren und hier posten oder mir per pm senden oder selbst heraussuchen, was die UDM für einen type hat.
-- helfen tut hierbei die Webseite https://jsonformatter.org/json-pretty-print (https://jsonformatter.org/json-pretty-print)
Es gibt für jedes Device darin folgenden Abschnitt:
{
"mac": "22:33:44:55:66:77",
"state": 1,
"adopted": true,
"disabled": false,
"type": "usw",
"model": "US16P150",
"name": "switch-HWR"
},
Da ist hoffentlich auch eines dabei, das als Model irgendetwas mit UDM hat. Interessieren tut dann der Eintrag bei type.
Gerne:
{
"mac": "aa:bb:cc:dd:ee:ff",
"state": 1,
"adopted": true,
"disabled": false,
"type": "udm",
"model": "UDMPRO"
},
Moin und vielen Dank,
ich habe die UDM-Version von dir aus Post #1315 in Zeile 1446 um den type udm erweitert, so dass die Daten des Gerätes an das Modul UnifiSwitch weitergegeben werden.
if (defined $h->{type} && (($h->{type} eq "usw") || ($h->{type} eq "udm"))){
Da ich keine Ahnung habe, wie die Device-Daten aussehen kann das funktionieren, sofern dieselben Datenstrukturen verwendet werden. Meine Vermtung ist aber, dass sich die Informationen zum Switch in der UDM tiefer in den UDM-Datenstrukturen befinden, so dass man diese vermutlich noch herausextrahieren müsste. Wenn man Pech hat sind die Daten aber vollständig anders aufgebaut.
Vielleicht mag mal jemand testen. Ungefähr folgendermaßen müsste die Datenstruktur aussehen, die an das Modul UnifiSwitch übergeben wird (Ich habe hier im Post alle nicht verwendeten Daten entfernt):
{
"has_fan": false,
"has_temperature": false,
"model": "xxxxxx",
"type": "udm",
"name": "yyyyyyyy",
"port_table": [
{
"port_idx": "1",
"port_poe": true,
"poe_mode": "off",
"poe_current": "0.00",
"poe_power": "0.00",
"poe_voltage": "0.00",
"speed": 1000,
"name": "Port 8",
},
{
"port_idx": "2",
"port_poe": true,
"poe_mode": "off",
"poe_current": "0.00",
"poe_power": "0.00",
"poe_voltage": "0.00",
"speed": 0,
"name": "Port 8",
},
...
],
"type": "usw",
"system-stats": {
"cpu": "33.9",
"mem": "22.3",
},
"ssh_session_table": [],
"overheating": false
}
Viele Grüße,
Dirk
Hi Dirk,
deine erzeugt bei mir einen Switch mit der WAN IP als Name.
Verbose output liefert folgendes:
unifi (UnifiSwitch_Parse) - executed. UnifiSwitch: message_json:
{
"has_fan": false,
"has_temperature": false,
"model": "UDMPRO",
"type": "udm",
"port_table": [
{
"port_idx": 1,
"port_poe": false,
"speed": 1000,
"name": "Port 1",
},
],
"system-stats": {
"uptime": "801093",
"mem": "48.1",
"cpu": "8.1"
},
"overheating": false,
}
und sehr viel mehr...
Allerdings fehlen einige von dir erwähnten Daten.
Schöne Grüße
Michael
OK, dann müssen die Daten für die anderen 4 Ports woanders versteckt sein. Du könntest nochmal mit den Entwicklertools schauen und dann nicht auf den "devices-basic" gehen sondern auf "devices". Der Response dort zeigt die Daten aller Devices an. Eines davon sollte die UDM sein.
Ggf. kann man nach Zeile 1446 $h für udm neu aufbauen und an UnifiSwitch senden. Ohne eine UDM zu haben kann ich nur helfen und nicht so viel selbst machen.
Hi Dirk,
evtl. liegt hier ein Missverständnis vor,
die port_table enthält alle Switch ports.
Das UnifiSwitch modul legt für den Switch in der UDM (Pro) keine readings an.
Wie sehe ich woran das scheitert?
Im Log sieht das so aus:
2020.09.20 09:52:25 5: unifi: dispatch UnifiSwitch_SW_Abstellraum{"has_fan":false,...}
2020.09.20 09:52:25 5: unifi (UnifiSwitch_Parse) - executed. UnifiSwitch: Adress: SW_Abstellraum
2020.09.20 09:52:25 5: unifi (UnifiSwitch_Parse) - executed. UnifiSwitch: message_json: {"has_fan":false,...}
2020.09.20 09:52:25 5: unifi (UnifiSwitch_Parse) - executed. UnifiSwitch: message_json: {"has_fan":false,...}
2020.09.20 09:52:25 5: unifi (UnifiSwitch_Parse) - return: SW_Abstellraum
2020.09.20 09:52:25 5: unifi: dispatch UnifiSwitch_xxx.xxx.xxx.xxx{"bytes":1051123792,...,"internet":true,"has_fan":false}
2020.09.20 09:52:25 5: unifi (UnifiSwitch_Parse) - executed. UnifiSwitch: Adress: xxx.xxx.xxx.xxx
2020.09.20 09:52:25 5: unifi (UnifiSwitch_Parse) - executed. UnifiSwitch: message_json: {"bytes":1051123792,...,"internet":true,"has_fan":false}
2020.09.20 09:52:25 5: unifi (UnifiSwitch_Parse) - return: xxx.xxx.xxx.xxx
Also für den "normalen" Switch ein dispatch, dann kommt die Adress zurück. Danach noch zwei Parse Aufrufe.
Beim UDM Switch: dispatch, dann kommt die Adresss als IP zurück, dann noch ein Parse Aufruf.
Schöne Grüße
Michael
Ok, mit dieser kleinen Änderung in Zeile 295 in 74_UnifiSwitch.pm
if( $apRef->{type} eq 'usw' || $apRef->{type} eq 'udm' ){
tauchen die Readings auf.
Super. Dann würde ich das auch so übernehmen.
Prima, konnte bis jetzt keine Nachteile feststellen.
Hallo zusammen,
im Anhang ein Merge der UDM-Version mit der bisherigen Version.
Anpassungen:
- neues Attribut: isUDM
Bitte nach dem Define auf 1 setzen, wenn ihr eine UDM habt - UnifiSwitch: Die Switch-Komponente der UDM wird als zusätzliches UnifiSwitch-Device angelegt.
Ich konnte das für UDM natürlich nicht testen. Mit dem normalen Controller scheint alles weiterhin zu funktionieren.
Ggf. versuche ich später noch eine Art autodetection einzubauen.
Bitte Feedback.
Viele Grüße,
Dirk
EDIT: Anhänge entfernt
Hi Dirk,
zwei Probleme:
1. der Login teil muss den Header mit content-type enthalten:
Zeile 899ff:
HttpUtils_NonblockingGet( {
%{$hash->{httpParams}},
url => $loginurl,
data => $logindata,
header => "Content-Type: application/json",
callback => \&Unifi_Login_Receive
} );
2. Nach dem login kommt nur data zurück, also schlägt die Prüfung auf nur meta rc ok fehl.
Zeile 918:
if ($data->{meta}->{rc} eq "ok" || $data->{username} ne '') {
Hi Michael,
vielen Dank. Im Anhang neue Versionen (UnifiSwitch hat sich nicht geändert zum 2 Posts vorher).
VG,
Dirk
Hi, vorab ich bin totaler Unifi-Neuling, habe gerade die Version aus dem vorherigen Post bei mir in FHEM eingespielt. Ich bin damit leider nicht auf die UDM Progekommen, er bliebt immer auf disconnected stehen. Habe nun if ($data->{meta}->{rc} eq "ok" || $data->{username} ne '') {
auskommentiert und es ging sofort auf connected und die Readings sind auch sofort gekommen.
Wenn ich etwas zur Fehlerbeseitigung (Falls der Fehler nicht bei mir liegt :)) beisteuern kann, dann sagt Bescheid.
VG
Zitat von: Wuehler am 20 September 2020, 22:29:52
Hi Michael,
vielen Dank. Im Anhang neue Versionen (UnifiSwitch hat sich nicht geändert zum 2 Posts vorher).
VG,
Dirk
Kurze Rückmeldung.
Direkt nach setzen des Attributes "isUDM" auf 1 war ich verbunden. Die Switche wurden ausgelesen, auch der der UDM wurde angelegt. Die Abwesenheit läuft wieder.
Vielen Dank dafür!!
Wenn nun @justme1968 ähnliches beim Protectmodul einfügen könnte, wär die UDM auch komplett im FHEM,
@Wuehler: bei mir läuft seit zwei Tagen die Version aus deinem letzten Post.
Moin,
@Florie: Verstehe dein Problem noch nicht. Kannst du mal deine geänderte Moduldatei und ein list des FHEM-Devices posten.
@all_non_UDM_User: Hat von euch mal jemand getestet?
@kunze: Vielen Dank für deine Anpassungen und Mühen.
VG,
Dirk
Zitat von: Wuehler am 22 September 2020, 20:48:42
@all_non_UDM_User: Hat von euch mal jemand getestet?
Moin Dirk,
ich habe hier einen UniFi-CloudKey Gen1 laufen und habe mir jetzt deine Version 3.5.0 auf mein Testsystem gezogen.
Beim ersten Betrachten scheint alles zu laufen wie zuvor.
Gruß
Wolle
Haben es eben auch mal getestet. Bei mir kommt leider folgendes:
2020.09.23 20:24:50 5: UnifiController (Unifi_Notify) - executed.
2020.09.23 20:24:50 5: UnifiController: get called with ?.
2020.09.23 20:24:52 5: UnifiController (Unifi_Login_Send) - executed.
2020.09.23 20:24:53 5: UnifiController (Unifi_Login_Receive) - executed.
2020.09.23 20:24:53 5: UnifiController (Unifi_Login_Receive) - Login Failed! - state:'error.decode_json' - msg:'malformed JSON string, neither tag, array, object, number, string or atom, at character offset 1 (before "<!doctype html>\n<ht...") at ./FHEM/74_Unifi.pm line 917.
Status bleibt auf disconnected
@Wuehler hier mal das List, ohne readings
Internals:
DEF 192.168.1.1 443 crypt:XXXXXXXXXXXXXXXXXXXXXX crypt:XXXXXXXXXXXXXXXXXXXXXXX
DreamMachinePro_MSGCNT 127124
DreamMachinePro_TIME 2020-09-23 20:35:32
FUUID 5f69bc8a-f33f-7810-58ba-84ba8b234d5ae75b
FVERSION 74_Unifi.pm:0.199890/2019-08-12
LASTInputDev DreamMachinePro
MSGCNT 127124
NAME DreamMachinePro
NOTIFYDEV global
NR 272
NTFY_ORDER 50-DreamMachinePro
STATE connected
TYPE Unifi
UC_VERSION 5.14.22
VERSION 3.5.0
Attributes:
DbLogExclude .*
isUDM 1
room System->Unifi
An sich hatte ich eben die if Zeile auskommentiert mehr nicht.
@Micky79 & @Wuehler So war das eben bei mir auch mit dem if statement, wenn das auskommentiert ist, dann connectet FHEM einwandfrei. Ich habe eine DreamMachine Pro, FW 1.8.0
Ah, habe das device gelöscht und dann neu angelegt. Jetzt geht es.
Super und Danke!!!
@Florie: Kannst du bitte das if wieder einkommentieren, schauen ob es wieder nicht connected und dnn ein shitdown restart von FHEM durchführen. Mal schauen ob es dann geht.
Dann springt er nach Neustart von FHEM direkt wieder auf disconnected :(
Internals:
DEF 192.168.178.1 443 crypt:XXXXXXX crypt:XXXXXXXXX
FUUID 5f69bc8a-f33f-7810-58ba-84ba8b234d5ae75b
FVERSION 74_Unifi.pm:0.199890/2019-08-12
NAME DreamMachinePro
NOTIFYDEV global
NR 272
NTFY_ORDER 50-DreamMachinePro
STATE disconnected
TYPE Unifi
UC_VERSION unknown
VERSION 3.5.0
Auch das Löschen des Devices und anschließendem define bringt nur disconnected.
Nachdem ichs wieder auskommentiert habe hat nach FHEM-Neustart das "neue" Device direkt wieder connected und sich die Readings geholt ... Username ist bei mir meine Mailadresse, sprich da ist ein @-Zeichen drinnen. Kann es daran liegen, dass das if-Statement "fehlschlägt"?
Mmmh, seltsam. Hast du schon mal ins Log geschaut mit einkommentiertem if.
Ggf. verbose auf 5 stellen. Ich hoffe das Modul loggt dann die empfangene Login-Antwort (habe gerade keinen Zugriff auf den Sourcecode).
@Florie
Kannst du mal ausprobieren das username durch zum Beispiel unique_id zu ersetzen ob es dann geht?
@Wuehler
ich würde die Funktion Unifi_Login_Receive für die UDM umbauen.
Wenn ich einen falschen Nutzer oder Passwort angebe bekomme ich immer ein
HTTP/1.1 401 Unauthorized
Wenn der Nutzer und das Passwort stimmen, immer ein
HTTP/1.1 200 OK
Das sollte doch beim CK hoffentlich auch so sein, oder kommt da auch ein OK zurück wenn der Login nicht erfolgreich war?
Also evtl. so wie im Anhang, ungetestet.
@Wuehler:
Das kommt alle 30 Sekunden im Log mit einkommentiertem if-Statement
2020.09.27 08:56:52 5: DreamMachinePro (Unifi_Login_Receive) - executed.
2020.09.27 08:56:52 5: DreamMachinePro (Unifi_Login_Receive) - Login Failed (without msg)! - state:''
2020.09.27 08:56:52 5: DreamMachinePro (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
@kunze: Mach ich gerne, wie bekomme ich die unique_id bzw. was soll ich genau tun ;) ?
@Florie
Ich meinte im if statement den 'username' durch 'unique_id' ersetzen, oder du versuchst mal die version aus dem Anhang hier: https://forum.fhem.de/index.php/topic,40287.msg1087822.html#msg1087822
Also mit der Version aus dem verlinkten Anhang gehts einwandfrei ;)
Hallo,
ich habe nochmal intensiv gesucht und finde keine Stellen wo etwas doppelt steht.
Meine Readings für mein(e) iphones springen einfach nach belieben von connected zu disconnected oder unknown :-(
Ich bin echt ratlos warum das plötzlich so ist
Gruß
H-Man
Moin,
hast du in dem WLAN-Netzwerk mit dem du dich mit deinem iPhone verbindest die Option ,,Private WLAN-Adresse" schon ausgeschaltet? Das hat bei mir das Problem behoben, weil der Controller nun das Gerät wieder eindeutig anhand seiner MAC-Adresse erkennen kann.
Moin ComputerZoo,
nein die Option hatte ich noch nicht getestet - zugegebenermaßen kannte ich die auch nicht.
Wenn ich daheim bin werde ich das mal testen!
Vielen Dank!
Also ich hab die Option aktiviert und bei mir springt der Status nicht. Klappt alles wie eh und je (auch mit iOS 14)
Gruß
Zitat von: h-man-kl am 27 September 2020, 16:44:25
Hallo,
ich habe nochmal intensiv gesucht und finde keine Stellen wo etwas doppelt steht.
Meine Readings für mein(e) iphones springen einfach nach belieben von connected zu disconnected oder unknown :-(
Ich bin echt ratlos warum das plötzlich so ist
Gruß
H-Man
Hallo H-Man,
habe seit 3 Tagen dasselbe Problem mit einem iPhone SE auf iOS 14 und der aktuellen UniFi Firmware.
3 andere iPhones ( anderes SE, 11 & 8 ) funktionieren problemlos.
Nur das eine IPhone springt alle 30 Sekunden in FHEM auf Connected und dann innerhalb von Max. 2 Sek. Disconnected, oder andersherum. Dann wieder 30 Sek Pause.
In UniFi Log sehe ich keine Disconnects, so dass ich davon ausgehe, dass das FHEM Modul irgendeinen (neuen) Status vom UniFi falsch interpretiert.
Ein Ausschalten des Home-Wifi hat keine Veränderung gebracht
Grüße
Obelix
Muss mich hier nochmal melden, ich hatte ja die geänderte Version genutzt, damit lief die UDM Pro wieder in FHEM. Nun seit dem 29.09. war wohl die letzte Verbindung mit der UDM Pro, ich habe nichts geändert oder sonst was. Die Version der UDM ist auf 5.14.22.
Hat noch jemand wieder "Probleme" mit der Verbindung?
Habe mal im Log geschaut, da steht folgendes:
2020.10.04 12:53:01 5: UniFi (Unifi_Login_Send) - executed.
2020.10.04 12:53:01 5: UniFi (Unifi_Login_Receive) - executed.
2020.10.04 12:53:01 5: UniFi (Unifi_Login_Receive) - Login Failed! - state:'error.decode_json' - msg:'malformed JSON string, neither tag, array, object, number, string or atom, at character offset 1 (before "<!doctype html>\n<ht...") at ./FHEM/74_Unifi.pm line 917.
'
2020.10.04 12:53:01 5: UniFi (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
Hast du zufällig ein Update in FHEM gemacht? Da würde er nämlich wieder die offizielle (in dem Fall ältere) Version drüberkopieren...
Eigentlich nicht, ich habe aber eben, wo mir das aufgefallen ist, die 74_Unifi.pm aus dem Beitrag:
https://forum.fhem.de/index.php/topic,40287.msg1087822.html#msg1087822
in den FHEM Ordner kopiert, FHEM Neugestartet, leider keine Änderung
EDIT: Komisch, habe eben nochmal den Benutzername und das Passwort neu eingegeben, nun läuft es wieder...
Muss da doch nochmal eine Frage stellen, zeigt er bei euch denn bei den Endgeräten den verbundenne Accespoint an? Bei mir steht bei jedem Device nur "unknown"... ???
Welche Version verwendest du?
https://forum.fhem.de/index.php/topic,40287.msg1087822.html#msg1087822
Die sollte funktionieren. Oder die hier:
https://forum.fhem.de/index.php/topic,40287.msg1086535.html#msg1086535
Habe eben mal die Version drüber kopiert und Modul neu gestartet,
Nun klappt es ;D Vielen dank ::)
https://forum.fhem.de/index.php/topic,40287.msg1087822.html#msg1087822
So langsam verzweifel ich echt an dem ganzen... :o
Zum Feierabend nach hause gekommen und gesehen das das Modul wieder auf "disconnected" steht, im Log dann wieder folgende Meldung:
2020.10.06 06:42:38 5: UniFi (Unifi_Login_Send) - executed.
2020.10.06 06:42:38 5: UniFi (Unifi_Login_Receive) - executed.
2020.10.06 06:42:38 5: UniFi (Unifi_Login_Receive) - Login Failed! - state:'error.decode_json' - msg:'malformed JSON string, neither tag, array, object, number, string or atom, at character offset 1 (before "<!doctype html>\n<ht...") at ./FHEM/74_Unifi.pm line 917.
'
2020.10.06 06:42:38 5: UniFi (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
Modul schon neu gestartet, FHEM komplett neu gestartet, Benutzername und Passwort erneut eingegeben, alles ohne erfolg...
Jemand eine Idee woran das liegen kann? Bin jetzt bei der 3.5.0 vom wuehler, auch andere Versionen, neuen Benutzer angelegt um zu testen ob es daran liegt, ohne Besserung...
Auch die UDM Pro habe ich schon mal neu geartet...
Nach eine define bekomme ich folgendes im Log:
2020.10.07 20:27:39 5: UniFi: Defined with url:https://192.168.19.1/api/s/default/, interval:30
2020.10.07 20:27:39 5: UniFi (Unifi_Notify) - executed.
2020.10.07 20:27:39 5: UniFi (Unifi_Notify) - checking 1 state
2020.10.07 20:27:39 5: UniFi (Unifi_Notify) - executed. - Remove all Timers & Call DoUpdate...
2020.10.07 20:27:39 5: UniFi (Unifi_DoUpdate) - executed.
2020.10.07 20:27:39 5: UniFi (Unifi_Login_Send) - executed.
2020.10.07 20:27:39 5: UniFi (Unifi_initCustomClientReadings) - parsed part: . -> ^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime
2020.10.07 20:27:39 5: UniFi (Unifi_initCustomClientReadings) - parsed Attribute customClientReadings: {"parts":{"0000000_part":{"nameRegEx":".","ReadingRegEx":"^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime"}},"attr_value":".:^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime"}.
2020.10.07 20:27:39 5: UniFi (Unifi_Login_Receive) - executed.
2020.10.07 20:27:39 5: UniFi (Unifi_Login_Receive) - Login Failed! - state:'error.decode_json' - msg:'malformed JSON string, neither tag, array, object, number, string or atom, at character offset 1 (before "<!doctype html>\n<ht...") at ./FHEM/74_Unifi.pm line 917.
'
2020.10.07 20:27:39 5: UniFi (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2020.10.07 20:27:42 5: UniFi (Unifi_Notify) - executed.
[/s]
Edit: Es läuft nun wieder, fragt nicht wie und warum, ich werde mal sehen wie lange...
Hallo Zusammen,
bei mir klappt der Login leider nicht.
Ich habe einen lokalen Benutzer auf der UDM-Pro angelegt (siehe Bild im Anhang).
Und folgendes define abgesetzt:
define Unifi Unifi <IP> 443 fhem <PASSWORT>
Im Logfile werden folgende Meldungen protokolliert:
2020.10.11 16:53:07 5: Unifi (Unifi_Login_Send) - executed.
2020.10.11 16:53:07 5: Unifi (Unifi_Login_Receive) - executed.
2020.10.11 16:53:07 5: Unifi (Unifi_Login_Receive) - Login Failed! - state:'error.decode_json' - msg:'malformed JSON string, neither tag, array, object, number, string or atom, at character offset 1 (before "<!doctype html>\n<ht...") at ./FHEM/74_Unifi.pm line 917.
2020.10.11 16:53:07 5: Unifi (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
Die Internals sehen wie folgt aus:
Internals:
DEF <IP> 443 crypt:<Cyrpt Username> crypt:<Crypt PW>
FUUID 5f8319c2-f33f-56f1-5ae6-8154b3d1029204c5
NAME Unifi
NOTIFYDEV global
NR 2513
NTFY_ORDER 50-Unifi
STATE disconnected
TYPE Unifi
UC_VERSION unknown
VERSION 3.5.0
READINGS:
2020-10-11 16:47:27 state disconnected
accespoints:
alerts_unarchived:
clients:
events:
helper:
password crypt:<Crypt PW>
username crypt:<Crypt Username>
hotspot:
vouchers:
httpParams:
header
ignoreredirects 1
loglevel 5
method POST
noshutdown 0
timeout 5
hash:
sslargs:
SSL_verify_mode 0
unifi:
CONNECTED disconnected
eventPeriod 24
interval 30
ucurl https://<IP>/api/s/default/
udmurl https://<IP>/proxy/network/api/s/default/
url https://<IP>/api/s/default/
customClientReadings:
attr_value .:^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime
parts:
0000000_part:
ReadingRegEx ^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime
nameRegEx .
updateDispatch:
wlans:
Attributes:
verbose 5
Ich habe die Version aus dem folgenden Link installiert und anschliessend das FHEM neu gestartet:
https://forum.fhem.de/index.php/topic,40287.msg1087822.html#msg1087822
Habe ich noch etwas vergessen oder falsch gemacht?
Gruß
Andreas
eventuell fehlt
attr Unifi isUDM 1
Zitat von: Fuchshausen am 11 Oktober 2020, 17:12:15
eventuell fehlt
attr Unifi isUDM 1
Vielen Dank, das hat noch gefehlt, jetzt klappt der Login :D
Moin :)
Wird das neue Modul irgenwann ins SVN fliessen, so dass man diese nicht jedes Mal nach nem Update die Datei wieder händisch per SSH zurückkopieren muss?
Das wäre echt hübsch :)
VG
Martin
einfach solang
attr global exclude_from_update 74_Unifi.pm
benutzen.
Hallo - Warnung für alle
Ich hatte bis heute mein UDM Pro mit FHEM verbunden - seit dem Update haute zu 1.8.2-5 steh ich auf "disconnected". Keine Annhung was das Problem ist, ich habe Reboots (FHEM und UDM) probiert, FHEM aktualisiert usw... funktioniert nicht.
Bin ich alleine, oder habt ihr auch das Problem?
Guten Morgen,
habe eben die UDM unterstützende Version commited. Morgen dann im Update.
@okenny: Was steht denn im Log?
VG,
Dirk
Kurze Info, ich habe bei mir festgestellt, wenn ich im DEF noch einen Intervall angebe (in meinem bsp mit 30 versucht) ändert sich der Intervall zwar auf 30, aber alle geräte gehen auf disconnected, die anderen Informationen zu den Geräten werden aber noch aktualisiert...
Um das wieder umzustellen reicht es nicht, den Intervall zu entfernen, sonder das ganze Gerät muss neu angelegt werden
Zitat von: okenny am 12 Oktober 2020, 23:06:49
Hallo - Warnung für alle
Ich hatte bis heute mein UDM Pro mit FHEM verbunden - seit dem Update haute zu 1.8.2-5 steh ich auf "disconnected". Keine Annhung was das Problem ist, ich habe Reboots (FHEM und UDM) probiert, FHEM aktualisiert usw... funktioniert nicht.
Bin ich alleine, oder habt ihr auch das Problem?
Gleiches Problem hier.
Moinsen,
ich habe auch mal eine Frage. Ich nutze das Unifi Modul mittlerweile schon mehrere Jahre. Bisher gab es noch nie Probleme damit! Super!
Mittlerweile bin ich auf Controller Version 6.0.23, habe aber sehr lange die LTS Version genutzt.
Ich weiß nicht genau seit wann es so ist, aber wenn ich in meine Logfiles schaue, sehe ich ständige Statusänderungen an meinen Residents. Die beiden Residents sind mit unseren Smartphones verknüpft.
2020.10.14 14:17:55 2: ROOMMATE set rr_Frau absent
2020.10.14 14:18:26 2: ROOMMATE set rr_Frau home
2020.10.14 14:19:58 2: ROOMMATE set rr_Frau absent
2020.10.14 14:20:59 2: ROOMMATE set rr_Frau home
2020.10.14 14:26:36 2: ROOMMATE set rr_Frau absent
2020.10.14 14:30:42 2: ROOMMATE set rr_Frau home
2020.10.14 14:35:17 2: ROOMMATE set rr_Mann absent
2020.10.14 14:36:19 2: ROOMMATE set rr_Frau absent
2020.10.14 14:37:51 2: ROOMMATE set rr_Mann home
2020.10.14 17:15:07 2: ROOMMATE set rr_Mann absent
2020.10.14 17:15:38 2: ROOMMATE set rr_Mann home
2020.10.14 17:17:10 2: ROOMMATE set rr_Mann absent
2020.10.14 17:18:41 2: ROOMMATE set rr_Mann home
2020.10.14 17:20:13 2: ROOMMATE set rr_Mann absent
2020.10.14 17:20:44 2: ROOMMATE set rr_Mann home
2020.10.14 17:26:21 2: ROOMMATE set rr_Mann absent
2020.10.14 17:27:22 2: ROOMMATE set rr_Mann home
2020.10.14 17:31:27 2: ROOMMATE set rr_Mann absent
2020.10.14 17:31:58 2: ROOMMATE set rr_Mann home
2020.10.14 18:29:40 2: ROOMMATE set rr_Mann absent
2020.10.14 18:30:10 2: ROOMMATE set rr_Mann home
2020.10.14 18:37:19 2: ROOMMATE set rr_Mann absent
2020.10.14 18:37:50 2: ROOMMATE set rr_Mann home
2020.10.14 18:38:21 2: ROOMMATE set rr_Mann absent
2020.10.14 18:38:51 2: ROOMMATE set rr_Mann home
2020.10.14 18:40:54 2: ROOMMATE set rr_Mann absent
2020.10.14 18:41:25 2: ROOMMATE set rr_Mann home
2020.10.14 18:48:34 2: ROOMMATE set rr_Mann absent
2020.10.14 18:49:36 2: ROOMMATE set rr_Mann home
2020.10.14 18:51:38 2: ROOMMATE set rr_Mann absent
2020.10.14 18:52:40 2: ROOMMATE set rr_Mann home
2020.10.14 18:53:10 2: ROOMMATE set rr_Mann absent
2020.10.14 18:53:41 2: ROOMMATE set rr_Mann home
2020.10.14 19:00:19 2: ROOMMATE set rr_Mann absent
2020.10.14 19:00:50 2: ROOMMATE set rr_Frau home
2020.10.14 19:01:21 2: ROOMMATE set rr_Mann home
2020.10.14 19:01:51 2: ROOMMATE set rr_Mann absent
2020.10.14 19:02:22 2: ROOMMATE set rr_Mann home
2020.10.14 19:04:55 2: ROOMMATE set rr_Mann absent
2020.10.14 19:05:26 2: ROOMMATE set rr_Mann home
2020.10.14 19:25:22 2: ROOMMATE set rr_Mann absent
2020.10.14 19:25:53 2: ROOMMATE set rr_Mann home
2020.10.14 20:07:48 2: ROOMMATE set rr_Frau absent
2020.10.14 20:08:19 2: ROOMMATE set rr_Frau home
2020.10.14 20:12:24 2: ROOMMATE set rr_Mann absent
2020.10.14 20:13:56 2: ROOMMATE set rr_Mann home
2020.10.14 20:43:35 2: ROOMMATE set rr_Mann absent
2020.10.14 20:44:06 2: ROOMMATE set rr_Mann home
2020.10.14 20:59:56 2: ROOMMATE set rr_Mann absent
2020.10.14 21:00:27 2: ROOMMATE set rr_Mann home
2020.10.14 21:06:35 2: ROOMMATE set rr_Mann absent
2020.10.14 21:07:06 2: ROOMMATE set rr_Mann home
2020.10.14 21:16:18 2: ROOMMATE set rr_Mann absent
2020.10.14 21:16:48 2: ROOMMATE set rr_Mann home
2020.10.14 22:01:16 2: ROOMMATE set rr_Mann absent
2020.10.14 22:01:47 2: ROOMMATE set rr_Mann home
2020.10.14 22:09:57 2: ROOMMATE set rr_Mann absent
2020.10.14 22:10:28 2: ROOMMATE set rr_Mann home
2020.10.14 22:15:04 2: ROOMMATE set rr_Frau absent
2020.10.14 22:15:35 2: ROOMMATE set rr_Frau home
2020.10.14 22:17:07 2: ROOMMATE set rr_Frau absent
2020.10.14 22:17:37 2: ROOMMATE set rr_Frau home
2020.10.14 22:25:17 2: ROOMMATE set rr_Mann absent
2020.10.14 22:25:48 2: ROOMMATE set rr_Mann home
2020.10.14 22:27:20 2: ROOMMATE set rr_Frau absent
2020.10.14 22:37:02 2: ROOMMATE set rr_Frau home
2020.10.14 22:43:41 2: ROOMMATE set rr_Frau absent
2020.10.14 22:46:45 2: ROOMMATE set rr_Mann absent
2020.10.14 22:47:15 2: ROOMMATE set rr_Mann home
2020.10.14 22:53:54 2: ROOMMATE set rr_Mann absent
2020.10.14 22:54:25 2: ROOMMATE set rr_Mann home
Woran kann das liegen?
Ich habe die Vermutung, dass jeder Wechsel zw. 2.4GHz und 5GHz zu einem kurzzeitigen "absent" führt.
Die Definition meines Controllers sieht wie folgt aus:
define UnifiController Unifi localhost 8443 username password 30 default
Die Definition für eins meiner Smartphones sieht wie folgt aus:
define Mann_iPhone_XR_WLAN PRESENCE event UnifiController:Mann-iPhone-XR:.disconnected UnifiController:Mann-iPhone-XR:.connected
Die Definition eines Residents sieht wie folgt aus:
define rr_Mann ROOMMATE Bewohner
attr rr_Mann rr_presenceDevices Mann_iPhone_XR_WLAN
Früher wurden Geräte erst 5 Minuten nachdem Sie das WLAN verlassen haben auf disconnected bzw. Residents auf absent gesetzt.
Kann ich irgendwo angeben, nach wieviel Sekunden/Minuten eine Statusänderung übernommen werden soll? Hat hier noch jemand das Problem? Wie kann man das lösen?
Danke und Gruß Hoppel
Hallo Hoppel,
Habe genau das gleiche Problem.
Hier sind meine Beobachtungen: https://forum.fhem.de/index.php/topic,40287.msg1088492.html#msg1088492 (https://forum.fhem.de/index.php/topic,40287.msg1088492.html#msg1088492)
Bist Du auch ausschließlich mit iPhones unterwegs, oder auch mit Androids?
VG
Obelix
Ich schlage vor, daraus einen eigenen Thread zu machen. Bitte postet dort folgende Infos um zu schauen, wo es eine Gemeinsamkeit gibt:
- fehlerhaftes Endgerät (iPhone SE, ...)
- Versionen UnifiModul, UnifiController (UC)
- wo läuft der UC? RasPi, CloudKey, UDM, ...
- Schilderung des fehlerhaften Verhaltens
- was euch sonst noch auffällt/einfällt
Zitat von: Wuehler am 16 Oktober 2020, 20:09:24
Ich schlage vor, daraus einen eigenen Thread zu machen. Bitte postet dort folgende Infos um zu schauen, wo es eine Gemeinsamkeit gibt:
Moin, ich habe dazu gerade einen eigenen Thread erstellt und meine Inhalte dort nochmal gepostet und vervollständigt:
https://forum.fhem.de/index.php/topic,115160.0.html
Zitat von: h-man-kl am 15 September 2020, 08:51:46
da mir an anderer Stelle geraten wurde meine Frage hier zu posten hoffe ich auf Tips zur Lösung....
Mein Fhem läuft auf einem Raspi und ist aktuell
Mein Unifi läuft auf einem Cloudkey Gen2 und ist ebenfalls aktuell
Seit einiger Zeit habe ich das Problem, dass mein Handy nicht mehr korrekt in Fhem erkannt wird und so meine Anwesenheitsautomatik nicht geht.
Im Unifi selbst wird der Status korrekt angezeigt. Im Unifi-Device in Fhem passieren willkürlich folgende Dinge:
- das Handy hat den State Unknowen
- das Handy wechselt minütlich von diconnected auf connected egal ob ich da bin oder nicht => ich bin für Fhem dauerhaft connected
- das Handy wechselt minütlich von connected auf disconnected egal ob ich da bin oder nicht => ich bin für Fhem dauerhaft disconnected
Starte ich Fhem oder das Unifi Modul oder UNifi selbst neu, kann es sein, dass es funktoiniert.
Kennt jemand das Problem, was braucht ihr noch für Angaben?
Zitat von: obelix221 am 29 September 2020, 06:57:38
habe seit 3 Tagen dasselbe Problem mit einem iPhone SE auf iOS 14 und der aktuellen UniFi Firmware.
3 andere iPhones ( anderes SE, 11 & 8 ) funktionieren problemlos.
Nur das eine IPhone springt alle 30 Sekunden in FHEM auf Connected und dann innerhalb von Max. 2 Sek. Disconnected, oder andersherum. Dann wieder 30 Sek Pause.
In UniFi Log sehe ich keine Disconnects, so dass ich davon ausgehe, dass das FHEM Modul irgendeinen (neuen) Status vom UniFi falsch interpretiert.
Ein Ausschalten des Home-Wifi hat keine Veränderung gebracht
Wäre schön, wenn wir Ihr beide und alle anderen betroffenen euch auch dort einbringen könntet.
Danke und Gruß Hoppel
Für Iphone IOS 14 gibt es seit heute die 14.1 diese soll Verbinungen mit Unifi wieder stabil machen.
Vielleicht war auch das das Problem!
Verbesserung der Kompatibilität mit Wireless-Zugriffspunkten von Ubiquiti
Nein, das war nicht das Problem. Nach dem Update gab es das Verhalten weiterhin.
@UDM-User: bitte mal auf diese Diskussion schauen und Feedback geben: https://forum.fhem.de/index.php/topic,87728.msg1097390.html#msg1097390 (https://forum.fhem.de/index.php/topic,87728.msg1097390.html#msg1097390)
Hi Dirk,
bei der Analyse der connected/disconnected-Problematik beim AP-Wechsel (siehe anderer Thread) ist mir folgendes aufgefallen:
--- 74_Unifi.pm.bak 2020-11-09 21:02:29.129834672 +0100
+++ 74_Unifi.pm 2020-11-10 09:27:09.636996990 +0100
@@ -1578,7 +1578,7 @@
# mac-Adresse in den Readings versteckt (statet mit .) speichern, um nach einem Neustart den client restoren zu knnen
readingsBulkUpdate($hash,".".$clientName."_mac",$clientRef->{mac}) if defined $clientRef->{mac};
}
- elsif ((!defined($hash->{READINGS}->{$clientName})) || (defined($hash->{READINGS}->{$clientName}) && $hash->{READINGS}->{$clientName} ne "disconnected")) {
+ elsif ((!defined($hash->{READINGS}->{$clientName})) || (defined($hash->{READINGS}->{$clientName}) && $hash->{READINGS}->{$clientName}->{VAL} ne "disconnected")) {
Log3 $name, 5, "$name ($self) - Client '$clientName' previously connected is now disconnected.";
if(defined $clientRef->{blocked} && $clientRef->{blocked} eq JSON::true){
$blockedClients.=$clientName.',';
Ohne das {VAL} werden alle disconnected devices immer wieder auf disconnected gesetzt. Das behebt jedoch nicht das connected/disconnected Problem.
LG
Christian
Da der Connect zur UDM ja nun klappt ein kurzer Hinweis von mir zu kommenden Firmwares für die Gen2 Cloud-Keys.
Ubiquiti wird auch hier auf Unifi-OS Umstellen, die erste Beta ist im Release Channel aufgetaucht.
Auch im Hinblick auf zentrales User-Management.
Ich denk, es sieht da dann ebenso aus.
Ich schau es mir am WE mal an.
Ich hab heute mal mein FEHM geupdatet.
Und das Unif Modul wurde auf V 3.5.0 gezogen.
Im Log hab ich folgenden Error:
2020.11.12 19:06:28 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/74_Unifi.pm line 919.
2020.11.12 19:06:28 1: stacktrace:
2020.11.12 19:06:28 1: main::__ANON__ called by ./FHEM/74_Unifi.pm (919)
2020.11.12 19:06:28 1: main::Unifi_Login_Receive called by FHEM/HttpUtils.pm (639)
2020.11.12 19:06:28 1: main::__ANON__ called by fhem.pl (752)
Verbindung mit UDM-Pro klappt aber
Hi ho!
Im Wiki gibt es ja das Beispiel für eine Benachrichtigung bei einem neuen Clienten.
Ich habe mir das noch etwas modifiziert damit ich auch mitbekomme in welcher SSID und an welchem AP der neue Client sich angemeldet hat.
Vielleicht kann es ja jemand brauchen oder mag es ins Wiki mit einpflegen.
defmod UniFi_new_Client DOIF ([UniFi:-UC_newClients] ne "" )\
{my $host = ReadingsVal("UniFi","-UC_newClients","--");; ## einlesen Hostname neuer WLAN Client\
my $readingSSID = ReadingsVal("UniFi",$host."_essid","--");; ## bauen Reading SSID\
my $readingAP = ReadingsVal("UniFi",$host."_accesspoint","--");; ## bauen Reading AP\
my $text = "Neuer WLAN Zugriff von ".$host." über ".$readingAP." an ".$readingSSID;; ## vorbereiten Text\
fhem("set TelegramBot msg $text")} ## Telegram senden
Warum legst du nicht für Clients ein UnifiClient Device an?
Da steht das dann drin...
Ich hab für jeden Client (der mich interessiert) ein UnifiClient Device angelegt und für die dann eine readungsGroup...
Oder hab ich was falsch verstanden...
Gruß, Joachim
Zitat von: MadMax-FHEM am 17 November 2020, 15:29:18
Oder hab ich was falsch verstanden...
Ja hast Du. ;-)
Es bezieht sich hier drauf: https://wiki.fhem.de/wiki/Unifi#Erkennung_neuer_clients
Die Benachrichtigung kommt wenn ein Gerät neu ins WLAN kommt. ins Gastnetz z.B. oder wenn jmd dein WLAN "hackt"
für bekannte Geräte und die Presence nutze ich natürlich die Client Instanz es Unifi Moduls. :-)
Ok, dann hab ich nix "gesagt"... ;)
Gruß, Joachim
Zitat von: Frank_Huber am 17 November 2020, 14:12:56
Hi ho!
Im Wiki gibt es ja das Beispiel für eine Benachrichtigung bei einem neuen Clienten.
Ich habe mir das noch etwas modifiziert damit ich auch mitbekomme in welcher SSID und an welchem AP der neue Client sich angemeldet hat.
Vielleicht kann es ja jemand brauchen oder mag es ins Wiki mit einpflegen.
defmod UniFi_new_Client DOIF ([UniFi:-UC_newClients] ne "" )\
{my $host = ReadingsVal("UniFi","-UC_newClients","--");; ## einlesen Hostname neuer WLAN Client\
my $readingSSID = ReadingsVal("UniFi",$host."_essid","--");; ## bauen Reading SSID\
my $readingAP = ReadingsVal("UniFi",$host."_accesspoint","--");; ## bauen Reading AP\
my $text = "Neuer WLAN Zugriff von ".$host." über ".$readingAP." an ".$readingSSID;; ## vorbereiten Text\
fhem("set TelegramBot msg $text")} ## Telegram senden
Hallo ich habe den folgenden Fehler :
UniFi_new_Client DOIF: expected DOELSEIF or DOELSE: \ {my $host = ReadingsVal("UniFi","-UC_newClients","--");
Kannst mir bitte helfen?
Zitat von: Kelwich am 29 November 2020, 00:18:06
Hallo ich habe den folgenden Fehler :
UniFi_new_Client DOIF: expected DOELSEIF or DOELSE: \ {my $host = ReadingsVal("UniFi","-UC_newClients","--");
Kannst mir bitte helfen?
Ja, hör auf in der cfg zu editieren. 😉
Pack den Code in der GUI in die RAW config.
Zitat von: Frank_Huber am 29 November 2020, 00:43:56
Ja, hör auf in der cfg zu editieren. 😉
Pack den Code in der GUI in die RAW config.
Danke hat funktioniert 😊
Hallo Wuehler,
erstmal herzlichen Dank für das coole Modul, das dDu der FHEM Community geschenkt hast.
Darf man eigentlich CRs bei Dir anmelden?
Ich würde ganz dringend die Funktion benötigen, um auf den einzelnen APs das WLAN ein- bzw. auszuschalten.
Hast Du so eine Funktion bereits schon auf der Roadmap?
VG
Obelix
Hallo Obelix,
sorry für die späte Antwort, aber ich mache die Betreuung des Moduls nur als Hobby. Eine Roadmap gibt es nicht.
Ich habe mir dein Problem eben angesehen und keine schnelle/einfache Umsetzungsmöglichkeit gefunden. Für APs gibt es aktuell keine eigenen Devices. Das wäre für diese Anforderung sinnvoll, da an den setter 3 Parameter (AP, WLAN und dis-/enable) übergeben werden müssten. Soweit ich weiß kann man aber nur keinen oder einen Parameter mitgeben. Müsste dann also eine Drop-Down-Liste mit allen Kombinationen von APs und WLANs erstellen. (Das hört sich nicht richtig an :()
Falls jemand ein Modul kennt, bei dem man mehr als einen Parameter übergeben kann bitte gerne melden.
Reicht es nicht, ein WLAN komplett zu disablen? Das funktioniert ja heute schon mit dem Modul.
VG,
Dirk
Hallo Dirk,
Danke für deine ausführliche Antwort.
Leider hilft mir das generelle Ausschalten des WLANs nicht.
Ich habe einen Beamer von BenQ, der das HDMI Signal über ein proprietäres Protokoll per Funk überträgt.
Dieses Protokoll scheint eine starke Frequenzüberlagerung zu dem WLAN Band zu haben.
Sobald mein AP im Wohnzimmer an ist, ist das Signal zum Beamer so stark gestört, dass ich das Schauen über den Beamer vergessen kann.
Falls ich das ganze WLAN ausschalten würde, hätte ich einen großen Aufstand meiner minderjährigen Mitbewohner zu befürchten.
Nachdem ich aber verstanden habe, dass die SW-seitige Umsetzung in dem Modul nicht in absehbarer Zeit machbar ist, werde ich eine HW-Lösung einsetzen, und den AP wohl mit einer Schaltsteckdose bei Beamer-Betrieb stromlos schalten.
Vielen Dank und schönen Abend
Obelix
Falls du den AP per PoE versorgst kannst ja mal schauen ob du nicht PoE für den Port abschalten kannst.
Hallo zusammen,
seit geraumer Zeit sind die Readingsnamen im Fhem-Device kryptische Monster, Beispiel: 5fd3d8cc0ed04a038c6996b2_name Google Pixel 4a 5G
Vorher waren die Readingsnamen meistens identisch oder ähnlich, z.B. mit kurzer angehängter Nummer, zu denen im Unifi-Controller.
Woran kann es liegen, vielleicht daran, ich Leerzeichen bei den Unifi Clients benutze? Früher hatte ich auf Leerzeichen verzichtet. Wäre es möglich in Fhem Readingsnamen ohne Leerzeichen aus den Unifi Clientnamen zu generieren?
Viele Grüße Gisbert
Moin Gisbert,
ja, das liegt an den Leerzeichen. Das Modul muß zur einfacheren Bedienbarkeit aus dem Namen wieder die ID des clients (die wird bei dir als Reading-Fallback genutzt) bekommen können. Das geht nicht, wenn man den Namen des Clients verändert (Leerzeichen entfernt) bzw. wäre ein recht großer und umfangreich zu testender Umbau.
Ich nutze als Ersatz für Leerzeichen immer Unterstriche.
VG und guten Rutsch,
Dirk
Zitat von: Wuehler am 31 Dezember 2020, 12:44:44
Moin Gisbert,
ja, das liegt an den Leerzeichen. Das Modul muß zur einfacheren Bedienbarkeit aus dem Namen wieder die ID des clients (die wird bei dir als Reading-Fallback genutzt) bekommen können. Das geht nicht, wenn man den Namen des Clients verändert (Leerzeichen entfernt) bzw. wäre ein recht großer und umfangreich zu testender Umbau.
Ich nutze als Ersatz für Leerzeichen immer Unterstriche.
VG und guten Rutsch,
Dirk
Hallo Dirk,
danke für die Erklärung, ich dachte mir schon während des Schreibens, dass es an den Leerzeichen liegt.
Vielen Dank, viele Grüße und einen Guten Rutsch
Gisbert
Hallo, es gibt ja mittlerweile die Version 6.0.43...
Zumindest "mault" mein UnifiController ;)
ABER: https://forum.fhem.de/index.php/topic,117421.msg1118086.html#msg1118086
Evtl. gibt es Probleme ab/mit der Version.
Wurde zwar im verlinkten Thread mit Cloudkey "gemeldet"/"festgestellt" aber ich denke das gilt dann (u.U.) auch für andere Plattformen...
Ich werde erst mal nicht updaten...
Gruß, Joachim
Zu spät. Es ist nicht ganz klar, was sich da alles geändert hat. Insbesondere ist die Weboberfläche eine andere und bei mir ging nach einem FHEM Neustart dann doch wieder alles, allerdings war der Neustart eher ein Absturz. Am besten erstmal warten.
Zitat von: andies am 05 Januar 2021, 10:39:41
Zu spät. Es ist nicht ganz klar, was sich da alles geändert hat.
Ohje...
Zitat von: andies am 05 Januar 2021, 10:39:41
Insbesondere ist die Weboberfläche eine andere...
Schon wieder eine andere oder jetzt "zwangsweise" der "neue Look"?
(konnte man ja "früher" schon aktivieren / allerdings fehlten dann doch noch einige Dinge und ich hab dann "oben" auf "did not find what you are looking for" geklickt ;) )
Zitat von: andies am 05 Januar 2021, 10:39:41
...bei mir ging nach einem FHEM Neustart dann doch wieder alles, allerdings war der Neustart eher ein Absturz. Am besten erstmal warten.
D.h. es geht jetzt (trotz V 6.0.43) wieder!?
Gruß, Joachim
Ich fahre schon seit ein paar Wochen unter der 6.0.43, allerdings mit einer UDM. Ich hab bislang keine Probleme festgestellt, weder im UDM Betrieb selber noch in FHEM.
Auch der Look in der Controlleroberfläche ist bei mir der alte.
Zitat von: MadMax-FHEM am 05 Januar 2021, 10:59:37
D.h. es geht jetzt (trotz V 6.0.43) wieder!?
Ja, nach einem Absturz läuft es. Ich starte nur gerade nicht neu.
Hmm, der "Kollege" im anderen Thread musste das Attribut isUDM setzen, dann hat es auch dort wieder funktioniert...
https://forum.fhem.de/index.php/topic,117421.msg1118131.html#msg1118131
Evtl./scheinbar führt Ubiquiti die "Linien zusammen"!?
Ich werde noch ein wenig warten ;)
Gruß, Joachim
Zitat von: MadMax-FHEM am 05 Januar 2021, 11:37:30
dann hat es auch dort wieder funktioniert...
Nut zur Bestätigung, das schalten von Switch POE Zustände (Auto, off usw..) funktioniert mit dem UDM Controller nicht mehr, oder?
Für mich zumindest nicht...
ohne das Attribut ging es gar nicht. Switch POE hatte ich noch nie ausprobiert.
in der Vergangenheit haben ich meine APs über POE in FHEM an und aus geschaltet, aber seit dem UDM-Pro FW ~1.83 (ich denke es war 1.83) geht das nicht mehr.
Ich kann alles auslesen, aber nichts schalten. (auch mt dem UDM Attribut)
Das connecten mit UC Version 6.0.43 funktioniert bei mir so
defmod Controller_Unifi Unifi 192.168.2.2 443 crypt:xx crypt:xx
attr Controller_Unifi isUDM 1
und dann FHEM neustarten, dann hat es ca 5min gedauert
Zitat von: SirMarco am 05 Januar 2021, 19:17:57
Das connecten mit UC Version 6.0.43 funktioniert bei mir
Kannst du auch POE an und aus schalten?
Leider nicht
Moin,
gestern habe ich mir den Controller 6.0.43 installiert. Das hat etwas länger gedauert, da ich ein paar Anpassungen in meinem Docker-Umfeld machen wollte um einfacher mal zwischen Versionen schwenken zu können.
Zitat von: MadMax-FHEMEvtl./scheinbar führt Ubiquiti die "Linien zusammen"!?
Es wäre zu schön ;)
Meine ersten Ergebnisse mit 6.0.43 (habe noch nicht alles durchgetestet):
- Nutzung: Docker-Image von jacobalberty (https://hub.docker.com/r/jacobalberty/unifi/)
- Das Modul hatte anschließend keinen Login mehr
- Also isUDM auf 1 gesetzt und shutdown restart
- => trotzdem kein login
- :o
- nach Analyse der Controller-Webseite: isUDM wieder auf 0 gesetzt
- => alles scheint zu funktionieren, das vorige Loginproblem war evtl. ein Cookie-Thema (?) und kann ich nicht nachstellen
- ==> auch poeMode ändern funktioniert
- :D :o :(
Es scheint mit 6.0.43 also je nach Laufzeitumgebung Unterschiede bei den URLs zu geben >:(
Auf UDM und CloudKey (ab 6.0.43, Gen??) muss isUDM offenbar auf 1 gesetzt werden, ansonsten auf 0.
Viele Grüße,
Dirk
Hallo zusammen,
ich betreibe in meinem Netzwerk den Unifi Controller 6.0.43 mit einer USG-Pro-4.
Ist es möglich die Temperaturen der USG als Readings anzeigen zu lassen, wie beim UnifiSwitch Modul?
Danke und Grüße
Moin,
Kannst du bitte mal verbose auf 5 stellen und im Log nachsehen, ob die Daten schon vorhanden sind.
Viele Grüße,
Dirk
Zitat von: Wuehler am 08 Januar 2021, 08:30:20
Moin,
Kannst du bitte mal verbose auf 5 stellen und im Log nachsehen, ob die Daten schon vorhanden sind.
Viele Grüße,
Dirk
Hallo Dirk,
Danke für deine Antwort. Ich habe Verbose 5 ausgeführt, konnte aber im Log keine Einträge finden, die ich dem USG direkt zuordnen konnte. Habe z.B. nach der MAC gesucht, Alias, Modell oder Version.
In den Readings wird die USG bisher mit folgeneden Readings angezeigt:
-AP_Keller_USG-Pro-4_clients
-AP_Keller_USG-Pro-4_locate
-AP_Keller_USG-Pro-4_state
Zudem habe ich eine Fehlermeldung im Log gefunden
2021.01.08 09:17:12 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/74_Unifi.pm line 2418
sowie Fehlermeldungen beim UnifiSwitch-Modul. Hier wurden die Readings das letzte Mal am 27.11.20 aktualisiert, obwohl der STATE=connected anzeigt
2021.01.08 08:16:56 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/74_UnifiSwitch.pm line 259.
2021.01.08 08:16:56 1: PERL WARNING: Exiting subroutine via next at ./FHEM/74_UnifiSwitch.pm line 259.
Hast du mir vielleicht weitere Hilfestellungen?
Gruß Ingo
Zitat von: karpate am 08 Januar 2021, 08:04:29
Hallo zusammen,
ich betreibe in meinem Netzwerk den Unifi Controller 6.0.43 mit einer USG-Pro-4.
Ist es möglich die Temperaturen der USG als Readings anzeigen zu lassen, wie beim UnifiSwitch Modul?
Danke und Grüße
mit SNMP kann man UDM und Switch Temperaturen auslesen (mit dem SYSLOG Modul). Du könntest SNMP probieren. Dafür müsste man nur die richtigen OIDs finden.
Moin,
da es öfters Anfragen gibt, ob noch ein weiterer Wert als Reading hinzugefügt werden kann habe ich das Modul um get deviceData erweitert. Man bekommt damit ein (einfach) formatiertes Json zurück. Aus diesem könnte man mit decode_json() in einer myUtils.pm den Wert extrahieren, den man als Reading möchte. Dann noch ein userreading anlegen mit dem Trigger -AP-lastUpdate.* und Aufruf der myUtils-Funktion und schon hat man ein eigenes neues Reading.
Morgen dann im Update.
Die Warnings von karpate sollten dann auch raus sein.
Viele Grüße,
Dirk
Guten Morgen Dirk,
kurze Rückmeldung zur aktualisierten Version: mit der neuen Version sehe ich aktuell keine Warnungen und mit "get devicedata" finde ich die die Werte im Json:
{
"CPU":"71 C",
"Board (PHY)":"50 C",
"PHY":"74 C",
"Board (CPU)":"50 C"
}
Mal schauen ob ich mit decode_json() weiterkomme...
Vielen Dank für deine schnelle Rückmeldung.
Gruß Ingo
Moin Ingo,
viel Erfolg. Falls du noch Infos oder Perl-Hilfe brauchst melde dich gerne. Im Kopf habe ich den notwendig Code grob durchdacht.
Und wenn es funktioniert bitte auch gerne hier posten, dann nehme ich das als Beispiel ins Wiki auf.
Viele Grüße,
Dirk
Hallo zusammen,
habt ihr den Code eventuell schon fertig?
Möchte auch gern noch einige eigene Readings definieren.
VG
edit:
Ich habe mal ein bischen rumprobiert.
Mir fehlt hier komplett der Einblick, wie ich das Ziel erreichen kann.
Kannst du mir hier eine Anschubidee geben?
Hab versucht "deviceData" in ein userreading zu schreiben. Wollte dann mit dem decodeJson aus dem Reading lesen.
Ist wohl etwas viel Input in einem userreading und FHEM mag nicht mehr.
Ich hätte mal einen Feature Request ;D
Kann man noch die Funktion "Reconnect" für WiFi Devices implementieren?
Vielen Dank
Zitat von: Mitch am 15 Januar 2021, 10:37:56
Ich hätte mal einen Feature Request ;D
Kann man noch die Funktion "Reconnect" für WiFi Devices implementieren?
Vielen Dank
Wenn du für das Gerät ein UnifiClient-Device anlegst hast du das ;)
Ich habe für meine "wichtigen" Geräte ein solches Device und zeige die in einer readingsGroup an und auch auf welchem AP sie hängen und ob das der "gewünschte" ist...
...mit Klick auf "reconnect"...
EDIT: https://forum.fhem.de/index.php/topic,117548.msg1120216.html#msg1120216
Gruß, Joachim
Danke, kannte ich nicht.
ABER 8) Reconnect gibt es da auch nicht.
Zitat von: Mitch am 15 Januar 2021, 11:44:53
Danke, kannte ich nicht.
ABER 8) Reconnect gibt es da auch nicht.
Heißt nicht mehr "reconnect" sondern "disconnect" (wurde irgendwann mal geändert, sollte sich im UnifiClient-Thread finden lassen: wann [und warum]), macht aber ein "reconnect" bzw. ist es eher in der Unifi-Oberfläche "falsch", weil: dort passiert auch nur ein "disconnect", "reconnect" macht der Client dann selbst ;)
Gruß, Joachim
Und falls Du die UnifiClients noch als "Presence" Nutzen willst kannst das hier mal im UnifiClient testen:
attr Presence_UniFi stateFormat {ReadingsVal($name,"presence","absent") eq "absent" ? "absent since ".ReadingsVal($name,"_f_last_seen","") : "present since ".ReadingsVal($name,"_f_uptime","")}
attr Presence_UniFi userReadings presence:fhem_state.* {(ReadingsVal($name,'fhem_state','disconnected') eq 'disconnected' ? 'absent' : 'present') }
Zitat von: MadMax-FHEM am 15 Januar 2021, 11:46:56
Heißt nicht mehr "reconnect" sondern "disconnect" (wurde irgendwann mal geändert, sollte sich im UnifiClient-Thread finden lassen: wann [und warum]), macht aber ein "reconnect" bzw. ist es eher in der Unifi-Oberfläche "falsch", weil: dort passiert auch nur ein "disconnect", "reconnect" macht der Client dann selbst ;)
Gruß, Joachim
Macht Sinn, Danke.
Aber auch Disconnect gibt es nicht?
Set
set <name> clear <readings|usedOnlineTime>
Clears the readings or set the usedOnlimeTime=0.
set <name> blockClient <
Blocks the client.
set <name> unblockClient <
Unblocks the client.
set <name> usergroup <
Set the usergroup for the client.
set <name> update <
Updates the client data.
Noch zum Hintergrund: ich brauch nicht viel (RedingGroup, etc.) ich habe einen Raspberry als ebusd laufen. Machmal verabschiedet er sich manchmal insofern, dass er zwar verbunden zeigt, aber keine IP bekommt. Ein einfaches Reconnect im Controller löst das "Problem".
Genau den Fall will ich automatisieren.
Äh, ja habe gerade im Code nachgeschaut (ist schon ne Weile her und "nur" auf meinem Testsystem)...
Das disconnect Client ist doch beim UnifiController-Device! SORRY!!
Du musst nur den Namen angeben:
set UnifiController disconnectClient ClientName
EDIT:
Der Name ist aber dann:
my $Name = ReadingsVal($Device,"fhem_clientName","n.a.");
Wobei $Device dann doch wieder das UnifiClient-Device ist... ;)
EDIT: oder beim Klicken über die Oberfläche per "DropDown" auswählen...
Gruß, Joachim
Zitat von: MadMax-FHEM am 15 Januar 2021, 11:58:42
Äh, ja habe gerade im Code nachgeschaut (ist schon ne Weile her und "nur" auf meinem Testsystem)...
Das disconnect Client ist doch beim UnifiController-Device! SORRY!!
Du musst nur den Namen angeben:
set UnifiController disconnectClient ClientName
EDIT:
Der Name ist aber dann:
my $Name = ReadingsVal($Device,"fhem_clientName","n.a.");
Wobei $Device dann doch wieder das UnifiClient-Device ist... ;)
Gruß, Joachim
Perfekt, Danke. Genau das habe ich gesucht.
Den set disconnect hatte ich schon geshen, habe aber immer nach reconnect gesucht 8)
Habe mich jetzt noch ins Wiki über UnifiClient eingelesen, ist irgendwie an mir vorbei gegangen.
Da gehen ja noch ein paar tolle Dinge.
Hat schonmal jemand eine "Kindersicherung" in folgender Form umgesetzt:
z.B. sperre einen WiFi Client von 20 bis 08 Uhr?
So etwas geht ja leider (noch) nicht im Controller selber.
Zitat von: Mitch am 15 Januar 2021, 12:13:56
Habe mich jetzt noch ins Wiki über UnifiClient eingelesen, ist irgendwie an mir vorbei gegangen.
Da gehen ja noch ein paar tolle Dinge.
Hat schonmal jemand eine "Kindersicherung" in folgender Form umgesetzt:
z.B. sperre einen WiFi Client von 20 bis 08 Uhr?
So etwas geht ja leider (noch) nicht im Controller selber.
Es gibt beim UnifiClient-Device ein:
set ClientDeviceName blockClient
D.h. das von 20:00 bis 08:00 müsste dann fhem machen und halt wieder unblock (oder wie das dann heißt) machen... ;)
Ist ja mit at oder DOIF kein Thema...
Gruß, Joachim
Ja, habe ich mir gerade angeschaut, Danke.
Leider scheint aber Unifi hier aber einen Bug zu haben. Ich habe mein Handy geblockt und kam trotzdem ohne Probleme ins Web.
EDIT: es geht wohl zu blocken, dauert aber einige Minuten, bis der Client rausgeschmissen wird. Wäre aber okay für mich.
Leider geht aber kein unblock aus fhem.
Im UnifiClient ist er ja disconnected und somit kann man auch nichts mehr damit machen.
Im Unifi Controller kann ich zwar unblock senden, wird aber nicht im Controller ausgeführt.
Eventuell das mal im UnifiClient-Thread ansprechen, vielleicht fehlt da noch was...
...evtl. hat noch niemand geblockt...
Und das blockClient war "offensichtlich" aber evtl. fraglich "was mache ich mit geblockten Clients" ;)
Gruß, Joachim
Das "Problem" mit dem Blocken ist, dass hierbei der AP oder Switch (je nachdem ob WLAN oder LAN) jedesmal neu provisioniert. Das dauert immer eine gewisse Zeit. Irgendwo hier in dem Thread gab es mal einen Tip den ich bei mir auch umgesetzt habe.
Einfach eine neue Benutzergruppe im Controller erstellen, die nur einen berenzten Datendurchsatz von z.B. 2 kb/s hat. Der zu blockende Client wird dann einfach in die neue Gruppe geschoben und diese Einstallung ist dann sofort aktiv.
Das ist zwar keine Blockierung im eigentlichen Sinne, aber aufgrund des äußerst geringen Datendurchsatzes ist das eine "quasi-Blockierung". So wird keiner Surfen wollen ;)
Beim "Blocken" wird nicht provisioniert, das macht der Controller
Zitat von: Wolle02 am 15 Januar 2021, 15:25:09
Das "Problem" mit dem Blocken ist, dass hierbei der AP oder Switch (je nachdem ob WLAN oder LAN) jedesmal neu provisioniert. Das dauert immer eine gewisse Zeit. Irgendwo hier in dem Thread gab es mal einen Tip den ich bei mir auch umgesetzt habe.
Einfach eine neue Benutzergruppe im Controller erstellen, die nur einen berenzten Datendurchsatz von z.B. 2 kb/s hat. Der zu blockende Client wird dann einfach in die neue Gruppe geschoben und diese Einstallung ist dann sofort aktiv.
Das ist zwar keine Blockierung im eigentlichen Sinne, aber aufgrund des äußerst geringen Datendurchsatzes ist das eine "quasi-Blockierung". So wird keiner Surfen wollen ;)
Gerade getestet: bei mir hier nichts provisioniert wenn ich einen Clinet blocke, zumindest nicht wenn ich die UnifiController-Oberfläche nutze...
Ich teste dann noch mal mit dem Unifi-Modul...
Gruß, Joachim
Ja, aber das mit der Benutzergruppe ist dennoch die elegantere Lösung, denn da gibt es auch einen Weg zurück. ;-)
Stimmt, es wird nicht neu provisioniert. Aber beim Entblocken über den Controller gab es bei mir Probleme beim Reconnecten. Das geht mit der Benutzergruppe fluffiger. :D
Aber ich habe grade festgestellt, das weder das Blocken noch das Ändern der benutzergruppe bei mir über FHEM funktioniert. Liegt wahrscheinlich daran, dass ich mittlerweile eine UDM habe und das Modul in manchen Bereichen damit noch nicht so richtig zusammenarbeitet. Als ich noch eine USG hatte ging das noch.
Moin,
ein paar Infos:
- set UnifiClient unblock gibt es auch, geht aber nur bei geblockten Clients (reading blocked=true). Und andersrum für blockCloent
- block/unblock sollte Provisioniern und stört daher das gesamte Netzwerk. Die Änderungen der Usergroup wird nicht provisioniert und hat daher einen höheren Akzeptanzfaktor (WAF, KAF, MAF, DAF) (Edit: Scheint mittlerweile nicht mehr so zu sein)
- falls ihr einen User habt, der im UnifiController nur lesen darf funktioniert beides nicht
- kann sein, dass es auf UDM nicht geht. Habe dazu kein Testsystem oder positives Feedback.
Viele Grüße,
Dirk
Nein, blocken/unblocken bedeutet keine Provisionierung!
Wäre aber auch nicht schlimm, es stört eigentlich nicht das System.
Ich habe festgestellt, das nur ein SuperAdmin blocken und unblocken kann, das war bei mir das Problem.
Finde ich blöd, aber gut, ist so.
Stimmt. Konnte es jetzt auch ausprobieren und es wird beim Block/Unblock nicht mehr provisioniert. War früher mal anders. Da hat sich Unifi positiv weiter entwickelt ;)
Habe es im Beitrag vorher editiert und muß dann mal schauen, was im WIKI und comandref ggf. anzupassen wäre.
Danke dir!
Hallo,
Ich nutzte das Unifi Modul schon einige Zeit.
Nun habe ich das Problem, dass es meine Fhem Instanz zu regelmäßigen Neustart bringt.
Habe es auch schon mal Neu installiert um es von den ganzen Notifys zu befreien aber ich erkenne den Grund für das Verhalten leider nicht.
Es werden auch keine Readings mehr erzeugt. Der Status ist jedoch Connectet
Nach einen set myunifi update ist unter verbose5 folgendes im Logfile zu sehen:
2021.01.23 11:36:43 5: myunifi: set called with update
2021.01.23 11:36:43 4: myunifi: set update
2021.01.23 11:36:43 5: myunifi (Unifi_DoUpdate) - executed.
2021.01.23 11:36:43 5: myunifi (Unifi_GetClientInsights_Send) - executed.
2021.01.23 11:36:44 5: myunifi: get called with ?.
2021.01.23 11:36:44 5: myunifi (Unifi_GetClientInsights_Receive) - executed.
2021.01.23 11:36:44 5: myunifi (Unifi_GetClientInsights_Receive) - state:'ok'
2021.01.23 11:36:44 5: myunifi (Unifi_GetVoucherList_Send) - executed.
2021.01.23 11:36:45 5: myunifi (Unifi_GetVoucherList_Receive) - executed.
2021.01.23 11:36:45 5: myunifi (Unifi_GetVoucherList_Receive) - state:'ok'
2021.01.23 11:36:45 5: myunifi (Unifi_GetClients_Send) - executed.
2021.01.23 11:36:45 5: myunifi (Unifi_GetClients_Receive) - executed.
2021.01.23 11:36:45 5: myunifi (Unifi_GetClients_Receive) - state:'ok'
2021.01.23 11:36:45 5: myunifi (Unifi_GetHealth_Send) - executed.
2021.01.23 11:36:46 5: myunifi (Unifi_GetHealth_Receive) - executed.
2021.01.23 11:36:46 5: myunifi (Unifi_GetHealth_Receive) - state:'ok'
2021.01.23 11:36:46 5: myunifi (Unifi_GetEvents_Send) - executed.
2021.01.23 11:36:47 5: myunifi (Unifi_GetEvents_Receive) - executed.
2021.01.23 11:36:47 5: myunifi (Unifi_GetEvents_Receive) - state:'ok'
2021.01.23 11:36:47 5: myunifi (Unifi_GetUnarchivedAlerts_Send) - executed.
2021.01.23 11:36:48 5: myunifi (Unifi_GetUnarchivedAlerts_Receive) - executed.
2021.01.23 11:36:48 5: myunifi (Unifi_GetUnarchivedAlerts_Receive) - state:'ok'
2021.01.23 11:36:48 5: myunifi (Unifi_GetAccesspoints_Send) - executed.
2021.01.23 11:36:49 5: myunifi (Unifi_GetAccesspoints_Receive) - executed.
2021.01.23 11:36:49 5: myunifi (Unifi_GetAccesspoints_Receive) - state:'ok'
encountered object '1', but neither allow_blessed, convert_blessed nor allow_tags settings are enabled (or TO_JSON/FREEZE method missing) at ./FHEM/74_Unifi.pm line 1466.
2021.01.23 11:36:49 1: PERL WARNING: Perl exited with active threads:
1 running and unjoined
0 finished and unjoined
0 running and detached
Fhem in aktueller Version.
Das Modul:
UC_VERSION
6.0.43
VERSION
3.5.2
Würde mich freuen, wenn hier vielleicht jemand behilflich sein könnte.
Vielen Dank
Moin,
das scheint ein Problem mit der Perl- und/oder Json-Modul-Version zu sein. Evtl. kann/sollte ich da etwas im Modul anpassen. Bitte schau mal, ob du da noch etwas updaten kannst. Wenn nicht, dann bitte mal Perl-Version posten. Dankk kann ich einen neuen Thread bei den devolpern aufmachen. Der Perl-Experte bin ich leider auch nicht :-[
VG,
Dirk
Hallo, vielen Dank.
Habe von Ubuntu 18.04.3 LTS auf Ubuntu 18.04.5 LTS geupdatet. Ergebnis ist das gleiche wie eben beschrieben.
Leider
Gruß Rene
und wie sieht es mit den perl-Modulen bzw perl selbst aus? Gibt da auch Module, die einem helfen: fhemInstaller, fhemServerApt, fhemServerNpm (falls man Nod.js braucht)
Hallo,
Die Debianversionen sind aktuell.
Ich habe die betreffende Ausstiegszeile mal auskommentiert.
Er hängt dann weiter bei der Zeile 1651 wo wiederum .encode_json aufgerufen wird.
Dispatch($hash,"UnifiClient_".$clientName.encode_json($clientRef),undef);
Dann habe ich das json Modul über CPAN installiert, welche etwas neuer war, jedoch mit gleichen Ergebnis, dass er Fehm in einen Neustart zwingt.
encountered object '1', but neither allow_blessed, convert_blessed nor allow_tags settings are enabled (or TO_JSON/FREEZE method missing) at ./FHEM/74_Unifi.pm line 1651.
Seltsam
Gruß
Rene
Seit dem letzten Update des Cloudkey2 (Firmware 2.0.27, Network-Modul 6.0.45) werden die einzelnen Reading für jeden Client nicht mehr aktualisiert?
Ich habe es bemerkt, da das PRESENCE-Modul bei mir darüber läuft.
Ein set clear hat alle Reading gelöscht, außer den Reading -UC_* und state wurde nichts wieder neu angelegt?
Was hat sich da geändert?
versuch mal das Attribut isUDM auf 1 zu setzen.
Ändert nichts, jetzt steht das Teil auf "disconnected". Ein Verbode 5 bringt im Log
UniFi (Unifi_Login_Receive) - Error while requesting https://172.16.1.1:8443/api/login - 172.16.1.1: Verbindungsaufbau abgelehnt (111)
Unter der Adresse ist auch nichts mehr erreichbar, Port 8443 ist lt. Portscan auch nicht mehr offen
Mit der neuen Software scheint sich auch der Zugang komplett geändert zu haben - im Browser ist die Netzwerk-App jetzt über https://<ip>/network zu erreichen
@Wuehler: schau dir mal die neueste version vom unifi protect modul hier: https://forum.fhem.de/index.php/topic,108715.msg1026934.html#msg1026934 an. da habe ich eine automatische erkennung ob es ein unifi os system ist oder nicht eingebaut. so oder sehr ähnlich müsste man das auch für den netzwerk controller einbauen können um dann ohne das attribut auszukommen. die urls für den weitern zugriff müssten dann ähnlich wie bei protect aufgebaut sein. das kann ich aber nicht selber testen da ich mein cloud key 2 noch nicht auf unifi os umstellen werde.
Moin zusammen,
bei mir funktioniert ein disconnectClient nicht mehr. Benutze ich normalerweise, um ein "verlorengegangenen" ESP32 wieder ins Netz zu holen. Das Modul ist verbunden mit einer UDM (state ist connected), aber irgendwie lassen sich keine set-Befehle mehr absetzen, block/unblock geht auch nicht mehr, sehe ich gerade.
Ist das ein bekanntes Problem? Gibt es eine Lösung?
Gruß Arne
Zitat von: wg25 am 01 März 2021, 14:35:36
bei mir funktioniert ein disconnectClient nicht mehr. Benutze ich normalerweise, um ein "verlorengegangenen" ESP32 wieder ins Netz zu holen. Das Modul ist verbunden mit einer UDM (state ist connected), aber irgendwie lassen sich keine set-Befehle mehr absetzen, block/unblock geht auch nicht mehr, sehe ich gerade.
Ist das ein bekanntes Problem? Gibt es eine Lösung?
Attribut isUDM auf 1 gesetzt?
Zitat von: Frank_Huber am 01 März 2021, 15:23:04
Attribut isUDM auf 1 gesetzt?
Ja. Wie gesagt, es lief bis gestern. Die Readings kommen auch alle...
Zitat von: wg25 am 01 März 2021, 15:32:23
Ja. Wie gesagt, es lief bis gestern. Die Readings kommen auch alle...
"Wie gesagt"??? ;-) das ist neue Info hier...
Was hast denn geändert seit es das letzte mal ging?
Zitat von: Frank_Huber am 01 März 2021, 15:40:00
"Wie gesagt"??? ;-) das ist neue Info hier...
Was hast denn geändert seit es das letzte mal ging?
Die Info war doch nicht neu?!? Wenn ich es bisher genutzt habe (disconnectClient), hat es wohl funktioniert ;-)
Geändert habe ich nichts, außer dass der NetworkController in der DreamBox jetzt auf 6.1.61 ist, vorher 6.1.56. Der fhem Server ist unverändert.
Gibts eigentlich schon Neuigkeiten zu der Kompatibilität mit der neuen Cloudkey-Firmware?
Bei mir werden die Readings nicht aktualisiert und ich habe diese Meldungen im Log, weiß da jemand weiter
2021.03.05 13:30:39 5: Unifi (Unifi_Notify) - executed.
2021.03.05 13:30:40 5: Unifi: get called with ?.
2021.03.05 13:30:42 5: Unifi (Unifi_Notify) - executed.
2021.03.05 13:30:45 5: Unifi: set called with update
2021.03.05 13:30:45 4: Unifi: set update
2021.03.05 13:30:45 5: Unifi (Unifi_DoUpdate) - executed.
2021.03.05 13:30:45 5: Unifi (Unifi_GetEvents_Send) - executed.
2021.03.05 13:30:45 5: Unifi: get called with ?.
2021.03.05 13:30:45 5: Unifi (Unifi_GetEvents_Receive) - executed.
2021.03.05 13:30:45 5: Unifi (Unifi_GetEvents_Receive) - Failed! - state:'error.decode_json' - msg:'malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "Unauthorized") at ./FHEM/74_Unifi.pm line 1408.
'
2021.03.05 13:30:45 5: Unifi (Unifi_GetUnarchivedAlerts_Send) - executed.
2021.03.05 13:30:45 5: Unifi (Unifi_GetUnarchivedAlerts_Receive) - executed.
2021.03.05 13:30:45 5: Unifi (Unifi_GetUnarchivedAlerts_Receive) - Failed! - state:'error.decode_json' - msg:'malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "Unauthorized") at ./FHEM/74_Unifi.pm line 1367.
'
2021.03.05 13:30:45 5: Unifi (Unifi_GetClients_Send) - executed.
2021.03.05 13:30:45 5: Unifi (Unifi_GetClients_Receive) - executed.
2021.03.05 13:30:45 5: Unifi (Unifi_GetClients_Receive) - Failed! - state:'error.decode_json' - msg:'malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "Unauthorized") at ./FHEM/74_Unifi.pm line 1015.
'
2021.03.05 13:30:45 5: Unifi (Unifi_GetClientInsights_Send) - executed.
2021.03.05 13:30:45 5: Unifi (Unifi_GetClientInsights_Receive) - executed.
2021.03.05 13:30:45 5: Unifi (Unifi_GetClientInsights_Receive) - Failed! - state:'error.decode_json' - msg:'malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "Unauthorized") at ./FHEM/74_Unifi.pm line 1070.
'
2021.03.05 13:30:45 5: Unifi (Unifi_GetVoucherList_Send) - executed.
2021.03.05 13:30:46 5: Unifi (Unifi_GetVoucherList_Receive) - executed.
2021.03.05 13:30:46 5: Unifi (Unifi_GetVoucherList_Receive) - Failed! - state:'error.decode_json' - msg:'malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "Unauthorized") at ./FHEM/74_Unifi.pm line 2004.
'
Das ging komischerweise vor einer Woche; ich kann mich nicht erinnern etwas an FHEM geändert zu haben (Unifi hatte ein update).
Sieht so aus als könnte sich das FHEM-Modul nicht mehr mit dem Controller verbinden (Unauthorized). Die zurückgelieferten Daten sind dann kein valides JSON und das Modul schreibt einen Fehler.
Stimmt die Adresse noch?
ja, die stimmt noch -aber ich kann mich tatsächlich nicht einloggen. Das Prozedere scheint sich da geändert zu haben. Danke für den Tipp, ich forsche da mal weiter.
Kann es sein, dass sich der port geändert hat? Die weboberfläche ist auch eine ganz andere.
root@CloudKey:~# netstat -nlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:7445 0.0.0.0:* LISTEN 12800/evostreamms
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 1219/systemd-resolv
tcp 0 0 0.0.0.0:7446 0.0.0.0:* LISTEN 12800/evostreamms
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1262/sshd
tcp 0 0 0.0.0.0:7447 0.0.0.0:* LISTEN 12800/evostreamms
tcp 0 0 127.0.0.1:9080 0.0.0.0:* LISTEN 29590/ulp-go-app
tcp 0 0 127.0.0.1:7448 0.0.0.0:* LISTEN 12800/evostreamms
tcp 0 0 127.0.0.1:1112 0.0.0.0:* LISTEN 12800/evostreamms
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 1274/postgres
tcp 0 0 127.0.0.1:7449 0.0.0.0:* LISTEN 12333/node
tcp 0 0 127.0.0.1:5433 0.0.0.0:* LISTEN 12059/postgres
tcp 0 0 127.0.0.1:7450 0.0.0.0:* LISTEN 12333/node
tcp 0 0 0.0.0.0:7550 0.0.0.0:* LISTEN 12800/evostreamms
tcp 0 0 127.0.0.1:9090 0.0.0.0:* LISTEN 1054/ubnt-systemhub
tcp 0 0 0.0.0.0:5355 0.0.0.0:* LISTEN 1219/systemd-resolv
tcp 0 0 127.0.0.1:27117 0.0.0.0:* LISTEN 5583/bin/mongod
tcp 0 0 127.0.0.1:7440 0.0.0.0:* LISTEN 12800/evostreamms
tcp 0 0 0.0.0.0:7441 0.0.0.0:* LISTEN 12800/evostreamms
tcp 0 0 127.0.0.1:7634 0.0.0.0:* LISTEN 1038/hddtemp
tcp6 0 0 :::7443 :::* LISTEN 12333/node
tcp6 0 0 :::7444 :::* LISTEN 12333/node
tcp6 0 0 :::22 :::* LISTEN 1262/sshd
tcp6 0 0 :::8888 :::* LISTEN 12333/node
tcp6 0 0 ::1:5432 :::* LISTEN 1274/postgres
tcp6 0 0 ::1:5433 :::* LISTEN 12059/postgres
tcp6 0 0 :::7877 :::* LISTEN 12333/node
tcp6 0 0 :::6789 :::* LISTEN 4711/java
tcp6 0 0 :::7080 :::* LISTEN 12333/node
tcp6 0 0 :::8843 :::* LISTEN 4711/java
tcp6 0 0 :::5355 :::* LISTEN 1219/systemd-resolv
tcp6 0 0 :::8880 :::* LISTEN 4711/java
tcp6 0 0 :::8080 :::* LISTEN 4711/java
tcp6 0 0 127.0.0.1:8081 :::* LISTEN 4711/java
tcp6 0 0 :::7442 :::* LISTEN 12333/node
udp 0 0 0.0.0.0:10001 0.0.0.0:* 12333/node
udp 0 0 192.168.2.15:42938 0.0.0.0:* 12333/node
udp 0 0 127.0.0.53:53 0.0.0.0:* 1219/systemd-resolv
udp 0 0 192.168.2.15:68 0.0.0.0:* 542/systemd-network
udp 0 0 192.168.2.15:123 0.0.0.0:* 1264/ntpd
udp 0 0 127.0.0.1:123 0.0.0.0:* 1264/ntpd
udp 0 0 0.0.0.0:123 0.0.0.0:* 1264/ntpd
udp 0 0 0.0.0.0:56058 0.0.0.0:* 1023/avahi-daemon:
udp 0 0 0.0.0.0:5353 0.0.0.0:* 1023/avahi-daemon:
udp 0 0 0.0.0.0:5355 0.0.0.0:* 1219/systemd-resolv
udp6 0 0 :::10001 :::* 4711/java
udp6 0 0 :::1900 :::* 4711/java
udp6 0 0 fe80::7683:c2ff:fe1:123 :::* 1264/ntpd
udp6 0 0 2003:cf:5706:c900:7:123 :::* 1264/ntpd
udp6 0 0 ::1:123 :::* 1264/ntpd
udp6 0 0 :::123 :::* 1264/ntpd
udp6 0 0 :::55654 :::* 1023/avahi-daemon:
udp6 0 0 fe80::7683:c2ff:fe1:546 :::* 542/systemd-network
udp6 0 0 192.168.2.15:51947 :::* 4711/java
udp6 0 0 :::5353 :::* 4711/java
udp6 0 0 :::5353 :::* 1023/avahi-daemon:
udp6 0 0 :::5355 :::* 1219/systemd-resolv
udp6 0 0 :::3478 :::* 4711/java
raw6 0 0 :::58 :::* 7 542/systemd-network
Active UNIX domain sockets (only servers)
Proto RefCnt Flags Type State I-Node PID/Program name Path
unix 2 [ ACC ] STREAM LISTENING 93981 12059/postgres /var/run/postgresql/.s.PGSQL.5433
unix 2 [ ACC ] STREAM LISTENING 39196 1/init /var/run/avahi-daemon/socket
unix 2 [ ACC ] STREAM LISTENING 55257 5583/bin/mongod /usr/lib/unifi/run/mongodb-27117.sock
unix 2 [ ACC ] STREAM LISTENING 39207 1/init /var/run/dbus/system_bus_socket
unix 2 [ ACC ] STREAM LISTENING 96855 12759/ubnt_avcodec_ /var/run/unifi-protect/transcoder
unix 2 [ ACC ] STREAM LISTENING 157831 29590/ulp-go-app /run/ulp-go/jsonrpc.sock
unix 2 [ ACC ] STREAM LISTENING 44685 1274/postgres /var/run/postgresql/.s.PGSQL.5432
unix 2 [ ACC ] STREAM LISTENING 16282 1/init /run/systemd/private
unix 2 [ ACC ] STREAM LISTENING 16296 1/init /run/systemd/fsck.progress
unix 2 [ ACC ] STREAM LISTENING 16307 1/init /run/systemd/journal/stdout
unix 2 [ ACC ] SEQPACKET LISTENING 462 1/init /run/udev/control
Das device
Internals:
DEF cloudkey.fritz.box 443 crypt:*********** crypt:*********** 300
FUUID 5e244be7-f33f-1115-db34-394dc6a8906d8bfd
FVERSION 74_Unifi.pm:0.235000/2021-01-09
LASTInputDev Unifi
MSGCNT 670825
NAME Unifi
NOTIFYDEV global
NR 255
NTFY_ORDER 50-Unifi
STATE disconnected
TYPE Unifi
UC_VERSION unknown
Unifi_MSGCNT 670825
Unifi_TIME 2021-03-05 13:23:37
VERSION 3.5.2
Port 443 stimmt schon, aber ich glaube, der Endpunkt hat sich geändert. Ich habe auf jeden Fall das gleiche Problem wie du.
Ich habe eine neue Firmware aufgespielt und komme nun nicht mehr an die Weboberfläche. Oh mann, manchmal nervt unifi...
Hallo,
ich hab die aktuelle Beta-Version 6.1.64 installiert und keine Probleme feststellen können.
viele Grüße
Jens
P.S.: attr Unifi isUDM 1 gesetzt?
ja, das Attribut ist gesetzt.
Tja, jetzt hat es mich mit meiner UDM scheinbar auch erwischt. state steht auf disconnected und im Logfile finde ich mit Verbose 5 folgendes:
2021.03.10 14:05:40 5: UniFi_UDM (Unifi_Login_Send) - executed.
2021.03.10 14:05:40 5: UniFi_UDM (Unifi_Login_Receive) - executed.
2021.03.10 14:05:40 5: UniFi_UDM (Unifi_Login_Receive) - Login Failed! - state:'error.decode_json' - msg:'malformed JSON string, neither tag, array, object, number, string or atom, at character offset 1 (before "<!doctype html>\n<ht...") at ./FHEM/74_Unifi.pm line 937.
'
2021.03.10 14:05:40 5: UniFi_UDM (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2021.03.10 14:06:10 5: UniFi_UDM (Unifi_Login_Send) - executed.
2021.03.10 14:06:10 5: UniFi_UDM (Unifi_Login_Receive) - executed.
2021.03.10 14:06:10 5: UniFi_UDM (Unifi_Login_Receive) - Login Failed! - state:'error.decode_json' - msg:'malformed JSON string, neither tag, array, object, number, string or atom, at character offset 1 (before "<!doctype html>\n<ht...") at ./FHEM/74_Unifi.pm line 937.
'
2021.03.10 14:06:10 5: UniFi_UDM (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2021.03.10 14:06:40 5: UniFi_UDM (Unifi_Login_Send) - executed.
2021.03.10 14:06:41 5: UniFi_UDM (Unifi_Login_Receive) - executed.
2021.03.10 14:06:41 5: UniFi_UDM (Unifi_Login_Receive) - Login Failed! - state:'error.decode_json' - msg:'malformed JSON string, neither tag, array, object, number, string or atom, at character offset 1 (before "<!doctype html>\n<ht...") at ./FHEM/74_Unifi.pm line 937.
'
2021.03.10 14:06:41 5: UniFi_UDM (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2021.03.10 14:07:11 5: UniFi_UDM (Unifi_Login_Send) - executed.
2021.03.10 14:07:11 5: UniFi_UDM (Unifi_Login_Receive) - executed.
2021.03.10 14:07:11 5: UniFi_UDM (Unifi_Login_Receive) - Login Failed! - state:'error.decode_json' - msg:'malformed JSON string, neither tag, array, object, number, string or atom, at character offset 1 (before "<!doctype html>\n<ht...") at ./FHEM/74_Unifi.pm line 937.
'
2021.03.10 14:07:11 5: UniFi_UDM (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2021.03.10 14:07:41 5: UniFi_UDM (Unifi_Login_Send) - executed.
2021.03.10 14:07:41 5: UniFi_UDM (Unifi_Login_Receive) - executed.
2021.03.10 14:07:41 5: UniFi_UDM (Unifi_Login_Receive) - Login Failed! - state:'error.decode_json' - msg:'malformed JSON string, neither tag, array, object, number, string or atom, at character offset 1 (before "<!doctype html>\n<ht...") at ./FHEM/74_Unifi.pm line 937.
Ist das mal wieder nur bei den UDMs so und mit den USGs geht es immer noch?
Kann man denn den Autocreate der Switche irgendwie ausschalten?
Hallo,
ich bin neuer Benutzer des Moduls und habe kriege leider keine Clients gelistet.
2021.03.13 22:39:28 1: UNIFI (Unifi_GetSysinfo_Receive) - Failed! - state:'error' - msg:'api.err.NoSiteContext' - This error indicates that the <siteID> in your definition is wrong. Try to modify your definition with <sideID> = default.
2021.03.13 22:39:28 5: UNIFI (Unifi_UsergroupRestJson_Receive) - executed.
2021.03.13 22:39:28 1: UNIFI (Unifi_UsergroupRestJson_Receive) - Failed! - state:'error' - msg:'api.err.NoSiteContext' - This error indicates that the <siteID> in your definition is wrong. Try to modify your definition with <sideID> = default.
Meine Site-ID hat einen eigenen Namen.
Ich habe in der Definition schon alles versucht:
Ohne Angabe von Site-ID, mit dem Namen default, mit meinem eigenen Sitenamen. Ich kriege aber immer den gleichen Fehler.
Der grundsätzliche Connect geht.
Wer kann helfen?
Danke!
Zitat von: wg25 am 01 März 2021, 14:35:36
bei mir funktioniert ein disconnectClient nicht mehr. Benutze ich normalerweise, um ein "verlorengegangenen" ESP32 wieder ins Netz zu holen. Das Modul ist verbunden mit einer UDM (state ist connected), aber irgendwie lassen sich keine set-Befehle mehr absetzen, block/unblock geht auch nicht mehr, sehe ich gerade.
Ist das ein bekanntes Problem? Gibt es eine Lösung?
Bin ich tatsächlich alleine mit dem Problem?
Nein, ich kann nichtmal connecten. Anscheinend ein update und dann war Schluss mit dem Zugriff.
Zitat von: Wolle02 am 10 März 2021, 14:10:52
Tja, jetzt hat es mich mit meiner UDM scheinbar auch erwischt. state steht auf disconnected und im Logfile finde ich mit Verbose 5 folgendes:
Ist das mal wieder nur bei den UDMs so und mit den USGs geht es immer noch?
Ich habe gestern ein FHEM Upate gefahren. Kurioserweise kann ich jetzt wieder connecten. Dabei wurde aber laut Changelog am Modul gar nicht geändert?
Hallo zusammen,
in letzter Zeit gibt es immer wieder neue "official releases" des Unifi-Controllers, diesmal die Version 6.1.71.
Wenn ich versuche auf meinem Debian 10 mit sudo apt update oder sudo apt-get update neue Pakete zu laden bzw. installieren, ist jedesmal kein Update von Unifi dabei.
Ich könnte diesen Controller händisch installieren, aber da hab ich schon einige Male üble Probleme gehabt, bis hin zum Einspielen eines Backup meines Servers.
Im Moment habe ich die Version 6.0.45.
Da ich oft versucht bin die neueste Version zu installieren, juckt es mich immer wieder in den Fingern, diesem Drang nachzugeben, allerdings halten mich bei Unifi die o.g. schlechten Erfahrungen zurück.
Viele Grüße Gisbert
Hallo,
bei mir kam ein repo update
Get:13 https://dl.ubnt.com/unifi/debian stable InRelease [3.023 B]
E: Repository 'https://dl.ubnt.com/unifi/debian stable InRelease' changed its 'Codename' value from 'unifi-6.0' to 'unifi-6.1'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this repository? [y/N] y
Bin jetzt auf 6.1.71
Gruß
Eisix
Hallo Gisbert,
also ich hab bisher noch keine Probleme beim Update gehabt. Für die 6.1.71 das folgende ins Putty-Terminal kopieren und gut ist.
rm /tmp/unifi_sysvinit_all.deb &> /dev/null; curl -o "/tmp/unifi_sysvinit_all.deb" https://dl.ui.com/unifi/6.1.71-de70ef60fe/unifi_sysvinit_all.deb && dpkg -i /tmp/unifi_sysvinit_all.deb && rm /tmp/unifi_sysvinit_all.de
mfG Jens
@Jens: das gilt ja nur, wenn du das .deb immer manuell selbst installierst. Und dass es was Neues gibt musst du "wissen"...
Außerdem würde ich auf einem/meinem "Produktiv-System" (und eigentlich auch sonstiges System) NIE so viele Befehle "verknüpfen", (Fehler)Ausgaben nach dev/null "pipen" und alle Befehle mit "y-Bestätigung" laufen lassen...
Wenn da was schief geht hat man keine Ahnung was oder wobei...
Und ich denke mindestens bei dpkg brauchst du doch sudo...
...ausser du machst dich vorher zu root oder (noch schlimmer) bist "immer" root...
Aber wie immer: jedem sein System....
Aktuell bekomme ich von apt auch nichts angezeigt (wie bei Gisbert).
Normalerweise gab es aber einen Hinweis auf ein Repo-Update (wie bei Eisix)...
Aber ich hab die source-list von Unifi auch nicht immer aktiv.
Weil diese Updates (im Gegensatz zu OS-Updates) spiele ich bewusst nicht so häufig ein...
Ich schaue mal, ob die Quelle aktuell überhaupt "aktiv" ist...
EDIT: aktuell nicht "aktiv" (dachte ich mir fast ;) ). Schalte sie meist nur aktiv, wenn die Controlleroberfläche "mosert" und ich denke: ok, kann man (nach einer [Komplett]Sicherung) ja mal machen...
Wobei norm. ja auch der Unifi Controller selber "mosert", wenn es was Neueres gibt... ;)
Gruß, Joachim
zumindest bis gestern war die 6.1.7 keine release version. auch wenn 'official' dran steht. es ist nur ein release candidate. das ist da gerade ein ziemliches durcheinander. ich glaube auch das sie die repositories noch mal eine woche nach dem release pushen weil sie lieber noch mal etwas wartezeit haben möchten.
Für meine Installation hatte ich so eben die neue Version im Update. Keine Fehler bislang und sieht chic aus...
VG
Torsten
Hallo Joachim,
Zitat...ausser du machst dich vorher zu root oder (noch schlimmer) bist "immer" root...
nicht immer, aber immer öfter ;)
P.S.: Beta ist aktuell 6.2.12
Zitat von: Newbie am 26 März 2021, 09:16:24
nicht immer, aber immer öfter ;)
Naja zu viel root ist auf Linux-Systemen halt nicht immer eine gute Idee... 8)
Viel Spaß, Joachim
die neue beta gibt es seit gestern oder heute. das bedeutet aber nicht das die 6.1.71 dann release ist. wie gesagt, es ist ziemlich chaotisch dort.
Ich bin noch bei 6.0.45. Lese auch die ganze Zeit mit was dort bei den Software Releases gepostet wird. Wahnsinn, Ubiquiti kommt da in den Kommentaren echt nicht gut weg. Irgendwie sind sie ja selbst Schuld. Statt Bugs nachhaltig zu beheben, gibt es nun dieses halbfertige UI, was irgendwie niemand braucht. Wobei ich es persönlich ziemlich schick finde. ;)
Das Ding ist nur, es handelt sich um Netzwerk-Equipment. Wenn man das einmal eingerichtet hat, dann sind Veränderungen nur noch selten und meist marginal.
Und wenn ich ehrlich bin, kann ich die Probleme auch nicht nachvollziehen. Bei mir läuft mittlerweile einiges an Unifi Equipment und das wurde auch alles schon mehrfach in den letzten Jahren durch größere/aktuellere Hardware ersetzt/ergänzt/umgebaut/whatever. Wirkliche Probleme hatte ich aber noch nie.
Bin mal gespannt wie Unifi diesen Imageschaden, der da gerade entsteht, wieder in den Griff kriegen will. Mit ständigen Release Candidates, die neue Bugs verursachen/enthalten, wird das wohl eher nichts.
Ich bin auch bei Reddit registriert. Da wird Ubiquiti gefühlt auch in jedem zweiten/dritten Post auseinandergenommen. In letzter Zeit gibt's dort Posts von Usern, die aufgrund des Shitstorms ganz bewusst positive Erfahrungen teilen. :)
Mal sehen, wie das alles so weiter geht.
Gruß Hoppel
So, ich habe gerade mal das Update auf die neue Stable v6.1.71 (official release) durchgeführt. Es handelt sich diesmal nicht um einen release candidate. Bei mir läuft der Controller in einem linuxserver.io Docker Container. Soweit sieht erstmal alles gut aus.
Aber wtf... Das WebUI sieht ja schon wieder anders aus als v6.045!!! CRAZY... :D
Gruß Hoppel
ZitatAber wtf... Das WebUI sieht ja schon wieder anders aus als v6.045!!! CRAZY... :D
Hallo Hoppel,
vorgestern abend (Freitag) hatte ich die anscheinend nun offizielle Version 6.1.71 installiert. Die Oberfläche ist zwar schön, aber viele meiner Einstellungen waren nicht mehr auffindbar.
In den Tiefen der Menus (nicht in der Kopfzeile) konnte man auswählen, ob man diese oder doch lieber die alte Oberfläche gerne hätte. Ich hab mich für die alte entschieden, und schon war sie wieder verfügbar.
Viele Grüße Gisbert
Hallo Giesbert,
wie gesagt, da man da nicht ständig etwas an der Konfiguration ändert, ist mir das eigentlich relativ egal, wie das in der Weboberfläche gelöst ist bzw. aussieht.
Solange man über die klassische Oberfläche noch an die benötigten Einstellungen kommt, ist für mich alles in Ordnung. ;)
Gruß Hoppel
Zitat von: andies am 05 März 2021, 16:22:41
Kann es sein, dass sich der port geändert hat?
Ich habe hier mal weiter gesucht und Logeinträge eingefügt, um zu sehen, was im Detail vor sich geht. In der Funktion Unifi_Login_Send($) (Zeile 920) wird folgendes übermittelt
2021.04.03 18:33:32 5: Unifi (Unifi_Login_Send) - executed.
2021.04.03 18:33:32 5: loginurl https://cloudkey.fritz.box/api/s/default/
2021.04.03 18:33:32 5: logindata {"username":<passt>, "password":<passt>, "rememberMe":true}
und dann lese ich in Unifi_Login_Receive, etwa Zeile 937
2021.04.03 18:33:32 5: Unifi (Unifi_Login_Receive) - executed.
2021.04.03 18:33:32 5: param-code 200
2021.04.03 18:33:32 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/74_Unifi.pm line 944
und die Fehlermeldung ist merkwürdig. Der Code lautet dort (durch meine Ergänzungen) wie folgt
940 Log3 $name, 5, "param-code $param->{code}";
if ($param->{code} == 200 || $param->{code} == 400 || $param->{code} == 401 || $param->{code} == 200) {
eval { $data = decode_json($data); 1; } or do { $data = { meta => {rc => 'error.decode_json', msg => $@} }; };
944 if ($data->{meta}->{rc} eq "ok" || $data->{username} ne '') {
Log3 $name, 5, "$name ($self) - state=ok";
$hash->{httpParams}->{header} = '';
for (split("\r\n",$param->{httpheader})) {
if(/^Set-Cookie/) {
s/Set-Cookie:\s(.*?);.*/Cookie: $1/;
$hash->{httpParams}->{header} .= 'Cookie: '.$1.';\r\n';
}
}
Data sieht so aus (ohne Dekodierung):
2021.04.03 18:42:36 5: data
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1"><link href="/2.css" rel="stylesheet"></head>
<body>
<div id="root"></div>
<script type="text/javascript" src="/vendor.0306759b.chunk.js"></script><script type="text/javascript" src="/main.d8e6c715.js"></script></body>
</html>
Ich glaube, ich kann den Fehler einkreisen. Es heißt im Code
if(int(AttrVal($name,"isUDM",0) == 1)){
( $loginurl = $hash->{unifi}->{url} ) =~ s/proxy\/network\/api\/s.+/api\/auth\/login/;
}else{
( $loginurl = $hash->{unifi}->{url} ) =~ s/api\/s.+/api\/login/;
}
und bei mir sind die Variablen wie folgt belegt
2021.04.03 18:57:36 5: $hash->{unifi}->{url} https://cloudkey.fritz.box/api/s/default/
2021.04.03 18:57:36 5: $loginurl https://cloudkey.fritz.box/api/s/default/
Es ist klar, dass isUDM=1 hier keine Wirkung hat, oder?
Hi,
if(int(AttrVal($name,"isUDM",0) == 1)){
eieiei :)
Da haben sich die Klammern wohl auf die Wanderung begeben ;)
LG
Christian
Hmm, komisch. Ich habe jetzt eine völlig triviale andere Lösung, die funktioniert trotz des offensichtlichen Klammerfehlers. Ich habe gesehen, dass beim list alles mögliche auftauchte und einfach das Gerät gelöscht und neu angelegt, also so wie im screenshot. Jetzt geht es.
Zitat von: andies am 03 April 2021, 19:34:37
Hmm, komisch. Ich habe jetzt eine völlig triviale andere Lösung, die funktioniert trotz des offensichtlichen Klammerfehlers. Ich habe gesehen, dass beim list alles mögliche auftauchte und einfach das Gerät gelöscht und neu angelegt, also so wie im screenshot. Jetzt geht es.
Sauber, hat bei mir auch geklappt... mit UDM-B 1.10.0-9 und Network 6.2.23.
Danke und Gruß
Arne
Hab nach einem Löschen und Neuanlagen nun den Unifiziert-Controller auch wieder connected (läuft auf einem Cloudkey 2).
Daten zu dem Clients sind auch alle wieder da.
Jedoch klappt das Schalten eines Ports mit poeMode über ein entsprechendes UnifiSwitch-Device nicht mehr. Es kommt kein Fehler - geschaltet wird aber auch nicht :-(
Ich habe keinen Cloudkey sondern PI-Installation.
(fast) neueste Version des Unifi-Controllers (also seit ein paar Tagen wird mir was Neueres angezeigt, die is noch nicht drauf) und damit geht das noch bzw. ging "letztens" noch...
EDIT: eben probiert und ging...
Poe-Switch: 8/60W
Gruß, Joachim
ein set Switch_Arbeitszimmer_1 poeMode 1 off liefert im Log mit verbose 5 auf switch und unifiziert-device
2021.05.26 12:41:37 4: UniFi (Unifi_Write) - executed with Unifi_DeviceRestJson_Send
2021.05.26 12:41:37 5: UniFi (Unifi_DeviceRestJson_Send) - executed with {"port_overrides":[{"portconf_id":"5e8c36093340d004d5088d31","port_security_mac_address":[],"poe_mode":"off","name":"Telefon Arbeitszimmer","port_idx":"1"},{"port_idx":"2","portconf_id":"5e8c36093340d004d5088d31","poe_mode":"auto","name":"Telefon Test"},{"name":"Switch Arbeitszimmer 2","poe_mode":"auto","port_security_mac_address":[],"portconf_id":"5e17d2ca3340d00ebacdce81","port_idx":"15"},{"port_idx":"16","portconf_id":"5e8c36093340d004d5088d31","name":"LNB","poe_mode":"auto"},{"portconf_id":"5e17d2ca3340d00ebacdce81","port_security_mac_address":[],"aggregate_num_ports":2,"port_idx":"17","op_mode":"aggregate"}]}.
2021.05.26 12:41:37 5: UniFi (Unifi_DeviceCmd_Receive) - executed.
2021.05.26 12:41:37 5: UniFi (Unifi_DeviceCmd_Receive) - Failed! - state:'404' - msg:'Failed with HTTP Code 404.'
Telefon Arbeitszimmer ist der korrekt erkannte Portname.
Nachtrag:
Die aufgerufene URL ist https://x.x.x.x/proxy/network/api/s/default/rest/device/5e17d7023340d01d8b3ed114. - und die Antwort die er bekommt
{"meta":{"rc":"error","msg":"api.err.NotFound"},"data":[]}
Network-Modul auf dem CloudKey ist 6.2.25
Hallo zusammen,
habe jetzt eine UDM Pro mit aktueller Firmware 1.9.3. Ich möchte über FHEM vor allem das Gäste-WLAN ein- und ausschalten. Ich habe erfolgreich ein Device in FHEM für den Controller definiert, die Readings werden brav aktualisiert.
Wenn ich jedoch ein "set UnifiController disableWLAN Gast" ausführe, passiert nichts. Ein Verbose 5 fördert eine 404-Antwort zutage:
2021.06.22 15:30:47.233 5: UnifiController (Unifi_Notify) - executed.
2021.06.22 15:30:47.275 5: UnifiController: get called with ?.
2021.06.22 15:30:54.359 5: UnifiController: set called with disableWLAN Gast
2021.06.22 15:30:54.360 4: UnifiController: set disableWLAN
2021.06.22 15:30:54.360 5: UnifiController (Unifi_WlanconfRest_Send) - executed with {"hotspot2conf_enabled":false,"fast_roaming_enabled":false,"dtim_ng":3,"minrate_na_beacon_rate_kbps":6000,"minrate_ng_data_rate_kbps":6000,"bc_filter_enabled":false,"uapsd_enabled":false,"wpa_mode":"wpa2","wep_idx":1,"enabled":false,"pmf_mode":"disabled","networkconf_id":"xy","wpa3_fast_roaming":false,"radius_mac_auth_enabled":false,"proxy_arp":false,"iapp_enabled":true,"minrate_na_advertising_rates":false,"minrate_na_data_rate_kbps":6000,"hide_ssid":false,"group_rekey":0,"name":"Gast","usergroup_id":"xy","wpa_enc":"ccmp","pmf_cipher":"auto","ap_group_ids":["xy"],"wpa3_support":false,"x_iapp_key":"xy","bss_transition":true,"mac_filter_enabled":false,"_id":"xy","site_id":"xy","wpa3_transition":false,"radius_macacl_format":"none_lower","mcastenhance_enabled":false,"minrate_ng_advertising_rates":false,"minrate_ng_cck_rates_enabled":true,"bc_filter_list":[],"dtim_mode":"default","wpa3_enhanced_192":false,"radius_das_enabled":false,"no2ghz_oui":false,"wlan_band":"both","minrate_ng_beacon_rate_kbps":6000,"mac_filter_list":[],"l2_isolation":false,"dtim_na":3,"auth_cache":true,"minrate_ng_enabled":true,"minrate_ng_mgmt_rate_kbps":6000,"is_guest":true,"security":"wpapsk","schedule_enabled":false,"mac_filter_policy":"allow","minrate_na_mgmt_rate_kbps":6000,"minrate_na_enabled":false,"b_supported":false}.
2021.06.22 15:30:54.421 5: UnifiController: get called with ?.
2021.06.22 15:30:54.440 5: UnifiController (Unifi_WlanconfRest_Receive) - executed.
2021.06.22 15:30:54.440 5: UnifiController (Unifi_WlanconfRest_Receive) - Failed! - state:'404' - msg:'Failed with HTTP Code 404.'
Wie kann das Problem gelöst werden?
Edit:
Oberfläche 6.2.26.0
Backend 6.2.26
Buildatag_6.2.26_15319
Kleiner Einwurf:
Das Modul sollte die Reading-Namen irgendwie transliterieren
2021.06.27 15:14:29.523 3: general.network.devices.controller: bad reading name 'Gartenhauptfl�che' (allowed chars: A-Za-z/\d_\.-)
2021.06.27 15:14:29.523 3: general.network.devices.controller: bad reading name 'Gartenhauptfl�che_accesspoint' (allowed chars: A-Za-z/\d_\.-)
2021.06.27 15:14:29.523 3: general.network.devices.controller: bad reading name 'Gartenhauptfl�che_essid' (allowed chars: A-Za-z/\d_\.-)
2021.06.27 15:14:29.523 3: general.network.devices.controller: bad reading name 'Gartenhauptfl�che_hostname' (allowed chars: A-Za-z/\d_\.-)
2021.06.27 15:14:29.523 3: general.network.devices.controller: bad reading name 'Gartenhauptfl�che_last_seen' (allowed chars: A-Za-z/\d_\.-)
2021.06.27 15:14:29.524 3: general.network.devices.controller: bad reading name 'Gartenhauptfl�che_uptime' (allowed chars: A-Za-z/\d_\.-)
2021.06.27 15:14:29.528 3: general.network.devices.controller: bad reading name 'T�rklingel' (allowed chars: A-Za-z/\d_\.-)
2021.06.27 15:14:29.528 3: general.network.devices.controller: bad reading name 'T�rklingel_accesspoint' (allowed chars: A-Za-z/\d_\.-)
2021.06.27 15:14:29.529 3: general.network.devices.controller: bad reading name 'T�rklingel_essid' (allowed chars: A-Za-z/\d_\.-)
2021.06.27 15:14:29.529 3: general.network.devices.controller: bad reading name 'T�rklingel_hostname' (allowed chars: A-Za-z/\d_\.-)
2021.06.27 15:14:29.529 3: general.network.devices.controller: bad reading name 'T�rklingel_last_seen' (allowed chars: A-Za-z/\d_\.-)
2021.06.27 15:14:29.529 3: general.network.devices.controller: bad reading name 'T�rklingel_snr' (allowed chars: A-Za-z/\d_\.-)
2021.06.27 15:14:29.529 3: general.network.devices.controller: bad reading name 'T�rklingel_uptime' (allowed chars: A-Za-z/\d_\.-)
Hallo zusammen,
ich habe seit einiger Zeit (weiß leider nicht genau seit wann, weil ich länger keine Zeit mehr hatte, das so genau zu beobachten) das sich meine Handys die auch für die Answesenheit zusätzlich fungieren, immerwieder für einen Bruchteil einer Sekunde disconnecten um sofort wieder zu verbinden. Im Log sieht das dann so aus:
2021-07-21 20:30:03.609 Unifi SYS_unify_controller ZTE-Blade-A7-2019: disconnected
2021-07-21 20:30:03.627 Unifi SYS_unify_controller ZTE-Blade-A7-2019: connected
2021-07-21 20:31:04.509 Unifi SYS_unify_controller ZTE-Blade-A7-2019: disconnected
2021-07-21 20:31:04.527 Unifi SYS_unify_controller ZTE-Blade-A7-2019: connected
2021-07-21 20:32:05.283 Unifi SYS_unify_controller ZTE-Blade-A7-2019: disconnected
2021-07-21 20:32:05.301 Unifi SYS_unify_controller ZTE-Blade-A7-2019: connected
2021-07-21 20:33:06.264 Unifi SYS_unify_controller YvonneZTE: disconnected
2021-07-21 20:33:06.324 Unifi SYS_unify_controller YvonneZTE: connected
2021-07-21 20:34:07.109 Unifi SYS_unify_controller YvonneZTE: disconnected
2021-07-21 20:34:07.170 Unifi SYS_unify_controller YvonneZTE: connected
2021-07-21 20:35:07.708 Unifi SYS_unify_controller ZTE-Blade-A7-2019: disconnected
2021-07-21 20:35:07.726 Unifi SYS_unify_controller ZTE-Blade-A7-2019: connected
2021-07-21 21:00:29.249 Unifi SYS_unify_controller YvonneZTE: disconnected
2021-07-21 21:00:29.416 Unifi SYS_unify_controller YvonneZTE: connected
Wie man sieht sind da teilweise ~20 ms dabei, so dass es eigentlich kein richtiges Reconnect sein kann, sondern irgendwie n Fehler.... Ist dahingehend etwas bekannt ?
Wenn nicht, hat jemand von Euch übergangsweise als Würgarround eine Idee, wie ich das Event (das ja dann ausgelöst wird) vielleicht verzögern könnte ? 100ms würden ja z.B locker reichen
Vielen Dank und viele Grüße
Andreas
Moin @flummy1978
hast du dich mit folgendem Thread schon auseinandergesetzt?
https://forum.fhem.de/index.php/topic,115160.0.html
Gruß Hoppel
Zitat von: Ralli am 22 Juni 2021, 15:37:10
Wenn ich jedoch ein "set UnifiController disableWLAN Gast" ausführe, passiert nichts. Ein Verbose 5 fördert eine 404-Antwort zutage:
Kann mir hier jemand helfen?
404 heisst nicht gefunden. FHEM ruft irgendeine Webseite auf, die das Gastlan ausschalten soll. Diese Seite aber gibt es nicht. Entweder ist ein Passwort nicht korrekt oder eas schlimmeres ist faul.
Hilft Dir das erstmal beim suchen?
Gleiches Problem mit 404 habe ich in #1505 beim An- und Ausschalten von PoE-Power geschrieben - vermutlich wurde durch eine neue Firmware die API bzw. URL-Struktur geändert. Da kann wohl nur de rModulentwickler weiterhelfen.....
@hoppel118,
Zitat von: hoppel118 am 22 Juli 2021, 22:51:11
hast du dich mit folgendem Thread schon auseinandergesetzt?
vielen herzlichen Dank für den Hinweis und sorry für die späte Rückmeldung. Hier geht aktuell gefühlt irgendwie alles drunter und drüber und ich komm zu nix. Aber das was ich gelesen hab, sollte ich damit auch klarkommen, danke Dir :)
VG
Andreas
Zitat von: andies am 01 August 2021, 23:22:16
Entweder ist ein Passwort nicht korrekt oder eas schlimmeres ist faul.
Hilft Dir das erstmal beim suchen?
Nein, das hilft leider nicht. Der grundsätzliche Zugriff auf die auszulesenden Funktionen klappt ja, also gibt's auch keinen User/Passwort-Konflikt. Mit dem verwendeten User kann ich über die GUI des Controllers auch die entsprechenden WLANs aktivieren/deaktivieren, also liegt auch kein Rechte-Problem vor.
Ich fürchte, dass die Struktur der Seiten bei einer UDM-Pro und dem darunter liegenden UnifiOS zwischenzeitlich sich in einigen Bereichen zu den "alten" unterscheiden. Ich habe allerdings nicht ersehen können, welche URL tatsächlich aufgerufen wird, wenn ich im Controller ein WLAN aktiviere oder deaktiviere. Wenn mir jemand sagt, wie ich das herausfinden kann, liefere ich gern eine entsprechende Information.
Gefunden habe ich allerdings diese Hinweise, die vielleicht hilfreich sein könnten:
https://gist.github.com/jcconnell/0ee6c9d5b25c572863e8ffa0a144e54b
https://ubntwiki.com/products/software/unifi-controller/api
Auch bei mir geht das disableWLAN nicht.
Hi,
ich bin noch recht kurz bei dem Unifi Thema dabei, die UDM-Pro läuft erst seit gestern :).
Ich vermute, dass die 404er mit fehlenden X-CSRF-Token zu tun haben, die irgendeine Version ab 6.irgendwas voraussetzt.
Ich habe gestern da mit experimentiert, weil bei mir das createVoucher auch nicht funktioniert, leider kam ich nicht zum Ziel.
Dafür habe ich den X-CSRF-Token aus dem login-reply ausgelesen (der, aus dem auch der Cookie kommt), und mit in die http-headers gepackt. Leider ohne Erfolg (beim createVoucher).
Interessant finde ich, dass der Cookie ein JWT ist und den X-CSRF-Token auch enthält. Hier könnte man auch unterscheiden, ob es ein unifi-os ist (isUDM), oder nicht. Dann könnte man sich das Attribut sparen.
LG
Christian
Ok,
hab's geschafft.
Wenn ich den X-CSRF-Token (und Content-Type) hinzufüge, funktioniert sowohl createVoucher() als auch enable/disable WIFI :D
Ich werde sehen, dass ich morgen einen patch fertig mache. Vielleicht ersetze ich dann auch noch isUDM mit dem automatischen code ;)
LG
Christian
Wow. Top! Vielen Dank sowohl für die Infos als auch den ggf. kommenden Patch 8) .
Habe auch seit ein paar Monaten eine UDMP. Auch wenn ich beides momentan nicht brauche, freue ich mich. Cool! ;)
Gruß Hoppel
Sodele,
im Anhang sind die Patches, die es bei mir fixen. Zusätzlich habe ich noch eine Version angehäng, die die Patches enthält. Ich weiss nicht, ob das so auch noch in der nicht-unifi-os-version funktioniert. Wäre schön, wenn das mal jemand testen kann, der keine DreamMachine hat.
EDIT: Nach dem reload 74_Unifi muss man sich einmal neu einloggen (Klick auf `DEF`, dann `modify <UNIFI_DEVICE>`).
LG
Christian
Vielen Dank!
74_Unifi.pm heruntergeladen und bei mir eingebaut, Reload durchgeführt, enableWLAN klappt leider nicht:
[code
2021.08.10 10:04:17.528 5: UnifiController (Unifi_WlanconfRest_Receive) - Failed! - state:'404' - msg:'Failed with HTTP Code 404.'
Hi,
Zitat von: Ralli am 10 August 2021, 10:05:45
74_Unifi.pm heruntergeladen und bei mir eingebaut, Reload durchgeführt, enableWLAN klappt leider nicht:
Danke für das Feedback.
Ist das 'ne DreamMachine? Besteht das Problem eigentlich nur bei DreamMachines? Hab' ich mir bisher gar keine Gedanken drüber gemacht.
Kannst Du mal verbose auf 5 stellen und gucken, was beim "Login successful" (oder so ähnlich) für Header ausgegeben werden?
EDIT: Du musst einmal neu einloggen (d.h. einmal auf `DEF` klicken und dann auf `modify <UNIFI_DEVICE>`)
LG
Christian
Ja, eine UDMP.
Es klappt doch!!!
Ein Reload 74_Unifi hat nicht gereicht, es musste ein "shutdown restart" durchgeführt werden. Vermutlich damit ein neuer Login und damit die Möglichkeit gegeben wird, das X-CSRF-Token mitzubekommen.
Vielen, vielen Dank!
Auch von mir ein großes Danke! Set poeMode funktioniert wird auf einem Cloudkey2 (keine DreamMachine)
Danke für die Patches!
Ich nutze mittlerweile den Umweg über Nodered. Da gibts auch ein Unifi Plugin, bei dem sofort alles funktioniert. FHEM triggert dann die Befehle über Nodered Webhooks.
Hallo zusammen,
ich nutze dieses Modul derzeit ausschließlich zur Präsenzerkennung über die eingeloggten Smartphones. Ich hätte jetzt aber für mehr Bedarf für folgendes Problem.
Einer von 2 AP macht Ärger. Die ausschließlich daran eingeloggten Geräte sind nicht erreichbar und senden folglich keine Daten zu Fhem. Das Eigenartige daran ist, dass der AP anpingbar und per ssh erreichbar ist, d.h. es sieht scheinbar gut aus, aber es gibt keine Verbindung zu den entsprechenden Geräten.
Startet man den AP per ssh oder im Controller neu, dann läuft wieder alles wie gewohnt.
Der 1. Schritt wäre natürlich die Ursachenbehebung, nur weiß ich überhaupt nicht, wo ich ansetzen kann. Die Firmware ist aktuell, es handelt sich um einen UAP-AC-LR mit 5.43.38.
Im Modul gibt es einen set-Befehl zum Neustart von AP:
set restartAP <Name>
Damit hätte ich einen work-around, bis ich die Ursache beseitigt habe. Mir stellt sich nur die Frage, ob ich diesen Befehl genauso in einem notify oder DOIF verwenden kann. Für meinen Geschmack fehlt der Devicename.
Viele Grüße Gisbert
Edit:
Wenn ich den AP im Fhem-Modul neu starte, dann bekomme ich folgenden log-Eintrag Eintrag im Eventmonitor:
2021-08-11 06:24:07.920 Unifi myUniFi restartAP UAP-AC-LR-EG
Hi Gisbert,
genau sowas hatte ich bei meinen U6-Pro auch mal, er lief, alles sah gut aus. Nur waren die Geräte nicht so erreichbar wie man es erwartet, presence zickte rum. Ein Restart und schupps lief wieder alles, wie gewohnt.
Ich habe da aber auch idR die Beta Releases an Firmware drauf. Es gibt beim 5.43er die .39 (ich glaube noch als Beta oder RC) vielleicht hilft die ja. Wenn sowas ist, kann man wirklich nur vorher einloggen per SSH und per "logread" / dmesg mal schauen, ob was sinnvolles rauskommt und damit ggf im Forum was rausfinden, was hängt (ist selten offensichtlich befürchte ich).
Ich habe keine UAP-AC-LR nur die MESH-M / AC-Pro und den U6-Pro.
Wie oft kommt denn das bei Dir vor ? Wenn es selten ist, würde ich auf das Release der .39 warten, ansonsten vielleicht auch mal die testen (gibts im Forum) zurück geht ja auch noch.
Die Entscheidung kann Dir keiner Abnehmen leider :)
Ronny
Hallo Ronny,
ich hatte früher schon Betas genutzt. Da das aber mit Aufwand und nicht garantiertem Erfolg verknüpft war, bin ich wieder auf die stable-Versionen zurück.
Der Fehler schwankt von wochenlang gar nicht bis zu 3mal täglich.
Ich wollte mir das noch ne Weile anschauen, aber in der Zwischenzeit in Fhem einen automatisierten Restart machen, basierend auf der Nichterreichbarkeit von einigen, ansonsten sehr zuverlässigen Geräten.
Ich habe nur noch keine Idee, wie ich den set-Befehl in ein notify oder DOIF hineinbekomme.
Viele Grüße Gisbert
Zitat von: Gisbert am 11 August 2021, 07:44:56
Ich habe nur noch keine Idee, wie ich den set-Befehl in ein notify oder DOIF hineinbekomme.
Moin,
na so, oder?
set myUniFi restartAP UAP-AC-LR-EG
Hallo Frank,
im Prinzip ja, d.h. so sollte der Fhem-Befehl funktionieren:
set myUniFi restartAP UAP-AC-LR-EG
Leider startet der AP nur nicht neu.
Leider geht aus dem Modul der Befehl
set restartAP UAP-AC-LR-EG
ebenfalls nicht, d.h. der AP wird nicht neu gestartet.
Ich zögere ein list des Devices hier reinzustellen, aber es sieht für mich so aus, dass es eigentlich ohne Probleme funktioniert.
Es sei denn, dass das Fhem-Device nur Leserechte hat, ich schaue nach.
Ergebnis: Es lag am Unifi-Controller-User, dem ich nur Leserechte eingräumt hatte. Nachdem ich im Fhem-Device auf den User mit allen Rechten im Controller gewechselt hatte, funktioniert der set-Befehl.
Manchmal sieht man das Brett vor lauter Wald (oder so ähnlich in bester Loddar-Manier) nicht.
Viele Grüße Gisbert
Zitat von: choenig am 10 August 2021, 07:59:50
EDIT: Nach dem reload 74_Unifi muss man sich einmal neu einloggen (Klick auf `DEF`, dann `modify <UNIFI_DEVICE>`).
LG
Christian
Hallo Christian,
ich habe 74_Unifi heruntergeladen und ausgetauscht. Dann FHEM neu gestartet. POE läßt sich mit Deiner Version jetzt wieder ohne Probleme schalten. Vielen Dank!
Gruß
Klaus
Ich nutze eine UDM Base.
Hab den Controller 6.4.47.
Hab dein Modul mit der neuen Version ausgetauscht, leider bekomme ich es nicht hin das PoE geschaltet wird.
021.08.14 17:05:14 5: SW01: set called with poeMode 01 off
2021.08.14 17:05:14 4: SW01: set poeMode
2021.08.14 17:05:14 4: UDM01 (Unifi_Write) - executed with Unifi_DeviceRestJson_Send
2021.08.14 17:05:14 5: UDM01 (Unifi_DeviceRestJson_Send) - executed with {"port_overrides":[{"portconf_id":"5e8df07dd66b1c0512fa75b1","port_security_mac_address":[],"poe_mode":"auto","port_idx":"1","name":"AP01"},{"port_idx":"1"},{"port_idx":"1","poe_mode":"pasv24"},{"port_idx":"1"},{"port_idx":"1"},{"port_idx":"1"},{"portconf_id":"5e8df07dd66b1c0512fa75b1","port_idx":"2","name":"AP02"},{"portconf_id":"5e8df07dd66b1c0512fa75b1","port_idx":"3","name":"AP03"},{"name":"SW02-1","port_idx":"4","poe_mode":"auto","portconf_id":"5e8df07dd66b1c0512fa75b1","port_security_mac_address":[]},{"name":"HOMEM01","portconf_id":"5e8df4a8d66b1c059d185252","port_security_mac_address":[],"poe_mode":"auto","port_idx":"5"},{"name":"Yealink T48S","port_idx":"6","poe_mode":"auto","stp_port_mode":true,"portconf_id":"5e91d845d66b1c059d1efee6","autoneg":true,"port_security_mac_address":[]},{"name":"SW03 Steckdose AZ links","port_security_mac_address":[],"portconf_id":"5e8df07dd66b1c0512fa75b1","port_idx":"7"},{"port_security_mac_address":[],"portconf_id":"5f2c78405b766b04556b3747","port_idx":"8","name":"Steckdose AZ rechts"},{"port_idx":"9","name":"Loxberry","stp_port_mode":true,"poe_mode":"auto","portconf_id":"5e8df4a8d66b1c059d185252","autoneg":true,"port_security_mac_address":[]},{"stp_port_mode":true,"poe_mode":"off","port_security_mac_address":[],"autoneg":true,"portconf_id":"60d45ef427e6582d84768cec","name":"AP04 Tiefgarage","port_idx":"10"},{"port_security_mac_address":[],"autoneg":true,"portconf_id":"5e8df4a8d66b1c059d185252","stp_port_mode":true,"poe_mode":"auto","port_idx":"11","name":"Pi StromzÃÂÃÂÃÂÃÂÃÂÃÂÃÂähler"},{"name":"PS4 Hugo","portconf_id":"5e8df07dd66b1c0512fa75b1","port_idx":"16"},{"port_idx":"17","portconf_id":"5e8df07dd66b1c0512fa75b1","name":"XBox360 Hugo"},{"name":"iMAC Hugo","port_idx":"18","portconf_id":"5e8df07dd66b1c0512fa75b1","port_security_mac_address":[]},{"port_security_mac_address":[],"autoneg":true,"portconf_id":"5e8df4a8d66b1c059d185252","stp_port_mode":true,"port_idx":"19","name":"SonyTV WZ"},{"name":"KabelRCVR Hugo","port_idx":"20","portconf_id":"5e8df07dd66b1c0512fa75b1","port_security_mac_address":[]},{"port_idx":"21","port_security_mac_address":[],"portconf_id":"5e8df4a8d66b1c059d185252","name":"Vu+ Uno 4K SZ"},{"name":"Samsung TV SZ","port_idx":"22","portconf_id":"5e8df07dd66b1c0512fa75b3","port_security_mac_address":[]},{"name":"FritzBox","portconf_id":"5e8df4a8d66b1c059d185252","port_security_mac_address":[],"port_idx":"23"},{"portconf_id":"5e8df07dd66b1c0512fa75b1","port_security_mac_address":[],"port_idx":"24","name":"Uplink UDM01"},{"port_idx":1},{"poe_mode":"off"}]}.
2021.08.14 17:05:14 5: SW01: get called with ?.
2021.08.14 17:05:14 5: UDM01 (Unifi_DeviceCmd_Receive) - executed.
2021.08.14 17:05:14 5: UDM01 (Unifi_DeviceCmd_Receive) - Failed! - state:'404' - msg:'Failed with HTTP Code 404.'
Ich habe versucht den 1. Port zu schalten, auf off.
In dem Set steht kein off, seltsam bzw. ich habe davon keine wirkliche Ahnung. ;-)
Und dann noch der API error.
Hat einer eine Idee oder einen Tip?
Lass mal die 0 vor der 1 weg.
Also "set nameSwitch poeMode 1 off".
Mit führender Null schaltet er bei mir nicht. Ohne die Null geht es bei mir.
Gruß
Klaus
Dank dir für den Tipp. Nun sieht der Befehl auch besser aus, es bleibt aber leider beim 404 im Log und das PoE für den Port nicht ausgeschaltet wird.
2021.08.15 09:28:25 5: SW01: set called with poeMode 1 off
2021.08.15 09:28:25 4: SW01: set poeMode
2021.08.15 09:28:25 4: UDM01 (Unifi_Write) - executed with Unifi_DeviceRestJson_Send
2021.08.15 09:28:25 5: UDM01 (Unifi_DeviceRestJson_Send) - executed with {"port_overrides":[{"port_idx":"1","autoneg":true,"stp_port_mode":true,"poe_mode":"off","name":"AP01","portconf_id":"5e8df07dd66b1c0512fa75b1","port_security_mac_address":[]},{"port_security_mac_address":[],"portconf_id":"5e8df07dd66b1c0512fa75b1","name":"AP02","poe_mode":"auto","autoneg":true,"port_idx":"2","stp_port_mode":true},{"poe_mode":"auto","stp_port_mode":true,"autoneg":true,"port_idx":"3","name":"AP03","portconf_id":"5e8df07dd66b1c0512fa75b1","port_security_mac_address":[]},{"autoneg":true,"port_idx":"4","stp_port_mode":true,"poe_mode":"auto","portconf_id":"5e8df07dd66b1c0512fa75b1","name":"SW02-1","port_security_mac_address":[]},{"poe_mode":"auto","name":"HOMEM01","portconf_id":"5e8df4a8d66b1c059d185252","port_idx":"5","port_security_mac_address":[]},{"port_security_mac_address":[],"name":"Yealink T48S","portconf_id":"5e91d845d66b1c059d1efee6","stp_port_mode":true,"port_idx":"6","autoneg":true,"poe_mode":"auto"},{"port_security_mac_address":[],"port_idx":"7","portconf_id":"5e8df07dd66b1c0512fa75b1","name":"SW03 Steckdose AZ links"},{"name":"Steckdose AZ rechts","portconf_id":"5f2c78405b766b04556b3747","port_security_mac_address":[],"port_idx":"8"},{"port_security_mac_address":[],"name":"Loxberry","portconf_id":"5e8df4a8d66b1c059d185252","poe_mode":"auto","stp_port_mode":true,"port_idx":"9","autoneg":true},{"stp_port_mode":true,"autoneg":true,"port_idx":"10","poe_mode":"off","portconf_id":"60d45ef427e6582d84768cec","name":"AP04 Tiefgarage","port_security_mac_address":[]},{"port_security_mac_address":[],"name":"Pi Stromzähler","portconf_id":"5e8df4a8d66b1c059d185252","port_idx":"11","autoneg":true,"stp_port_mode":true,"poe_mode":"auto"},{"port_idx":"16","portconf_id":"5e8df07dd66b1c0512fa75b1","name":"PS4 Hugo"},{"name":"XBox360 Hugo","portconf_id":"5e8df07dd66b1c0512fa75b1","port_idx":"17"},{"port_idx":"18","port_security_mac_address":[],"name":"iMAC Hugo","portconf_id":"5e8df07dd66b1c0512fa75b1"},{"port_security_mac_address":[],"portconf_id":"5e8df4a8d66b1c059d185252","name":"SonyTV WZ","port_idx":"19","autoneg":true,"stp_port_mode":true},{"port_idx":"20","port_security_mac_address":[],"portconf_id":"5e8df07dd66b1c0512fa75b1","name":"KabelRCVR Hugo"},{"portconf_id":"5e8df4a8d66b1c059d185252","name":"Vu+ Uno 4K SZ","port_security_mac_address":[],"port_idx":"21"},{"name":"Samsung TV SZ","portconf_id":"5e8df07dd66b1c0512fa75b3","port_security_mac_address":[],"port_idx":"22"},{"portconf_id":"5e8df4a8d66b1c059d185252","name":"FritzBox","port_idx":"23","port_security_mac_address":[]},{"port_idx":"24","port_security_mac_address":[],"name":"Uplink UDM01","portconf_id":"5e8df07dd66b1c0512fa75b1"}]}.
2021.08.15 09:28:25 5: UDM01 (Unifi_DeviceCmd_Receive) - executed.
2021.08.15 09:28:25 5: UDM01 (Unifi_DeviceCmd_Receive) - Failed! - state:'404' - msg:'Failed with HTTP Code 404.'
Zitat von: Fs79 am 15 August 2021, 09:30:10
Nun sieht der Befehl auch besser aus, es bleibt aber leider beim 404 im Log und das PoE für den Port nicht ausgeschaltet wird.
Den aktuellen Patch hast du aber manuell eingespielt und FHEM neu gestartet?
Apropos Patch ... wird dieser eigentlich in die normal hier verteilten Versionen übernommen?
Gerade den Patch , also die gesamte 74_unifi.pm heruntergeladen und jetzt möchte er sich nicht mehr mit meiner UDMP verbinden ...
2021.08.18 17:01:51 5: Unifi_BA10: Defined with url:https://192.168.110.6/proxy/network/api/s/default/, interval:30
2021.08.18 17:01:51 5: Unifi_BA10 (Unifi_Notify) - executed.
2021.08.18 17:01:51 5: Unifi_BA10 (Unifi_Notify) - checking 1 state
2021.08.18 17:01:51 5: Unifi_BA10 (Unifi_Notify) - executed. - Remove all Timers & Call DoUpdate...
2021.08.18 17:01:51 5: Unifi_BA10 (Unifi_DoUpdate) - executed.
2021.08.18 17:01:51 5: Unifi_BA10 (Unifi_Login_Send) - executed.
2021.08.18 17:01:51 5: Unifi_BA10 (Unifi_initCustomClientReadings) - parsed part: . -> ^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime
2021.08.18 17:01:51 5: Unifi_BA10 (Unifi_initCustomClientReadings) - parsed Attribute customClientReadings: {"parts":{"0000000_part":{"nameRegEx":".","ReadingRegEx":"^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime"}},"attr_value":".:^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime"}.
2021.08.18 17:01:52 5: Unifi_BA10 (Unifi_Login_Receive) - executed.
2021.08.18 17:01:52 5: Unifi_BA10 (Unifi_Login_Receive) - Login Failed (without msg)! - state:''
2021.08.18 17:01:52 5: Unifi_BA10 (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2021.08.18 17:02:00 5: Unifi_BA10 (Unifi_Notify) - executed.
2021.08.18 17:02:01 5: Unifi_BA10: get called with ?.
Ich habe das ganze Modul hier aus diesem Thread von einer Seite vorher installiert.
Habt Ihr sonst noch einer eine Idee?
Hi,
Zitat von: roedert am 18 August 2021, 10:35:34
Apropos Patch ... wird dieser eigentlich in die normal hier verteilten Versionen übernommen?
halte ich für ziemlich unwahrscheinlich, da die zwei Maintainer 'rapster' (seit 04.06.21 inaktiv) und 'Wuehler' (seit 08.04.21 inaktiv) schon seit Monaten nicht mehr im Forum aktiv waren.
LG
Christian
Hab jetzt für Unifi Steuerung auf Node Red umgesattelt.
Dank Docker war die Basis schnell erledigt.
Mein Hauptsystem ist eh Loxone und FHEM die Schnittstelle Richtung Zigbee und einigen anderen Dingen, nicht Richtung Unifi. ;-)
Mit NodeRed geht es gut, ein Modul kümmert sich um die Authentifizierung und man kann die JSON für die Port Konfig selber zusammenbauen.
Hab es leider nicht geschafft, dass in FHEM zu tun.
Thema ist für mich damit erledigt, dank euch für die Tipps.
Hi,
da das Wiki dazu nichts sagt, frag ich mal hier (vielleicht stehts ja auch in dem 100 Seiten Thread ;D):
Läuft das Modul auch mit der UDM Pro?
Ich habs probiert (Version: # $Id: 74_Unifi.pm 23500 2021-01-09 15:14:50Z wuehler $) und es bleibt bei Disconnected, keine Fehlermeldung.
Wenn ja, welcher User?
(Für die, die es nicht wissen: Der Controller läuft bei der UDM direkt auf der UDM. Es gibt keinen externen Controller.)
Homatrix
Hab auch eine UDMP.
• Port 443 im Define gesetzt?
• attr ... isUDM 1 gesetzt?
Danach ging es bei mir.
Gruß Hoppel
Das wars auch schon. Das attr hatte ich nicht gesehen bzw. in Erwähnung gefunden.
Danke Hoppel
Ist das nicht in der CRef niedergeschrieben?
Doch, ist es. Und es hätte geholfen, zumindest die letzten Seiten dieses Fadens mal anzuschauen.
Guten Abend.
Wenn ich mich mal mit einem Anliegen einreihen dürfte...
Ich nutze set UNIFI switchSiteLEDs on und
set UNIFI switchSiteLEDs off mit jeweils einem at, um meine FlexHD
als ,,Nachtlicht" benutzen zu wollen.
Leider funktioniert das nicht.
Ein manuelles ON oder OFF funktioniert nur manchmal.
Nämlich dann, wenn ich die LEDs zuvor im Controller manuell deaktiviert und wieder aktiviert habe.
Die at an sich schalten grundsätzlich- getestet mit einem normalen Schalter.
Dennoch, aktiviere ich die LEDs am Abend manuell über den Controller, sind diese am nächsten Morgen auch aus. Korrekt soweit. Aber sie schalten am Abend nicht wieder ein. Das muss ich dann wieder über den Controller erledigen...
Ist dazu etwas bekannt?
Ich wünsche einen schönen Abend.
Hallo,
habe das Problem nur, wenn ich mehrere Befehle an den Unifi Controller versende ( Schalte Nachts einige AP per POE an Switch aus), dann kommt Murks dabei heraus, wenn ich zwischen den Befehlen 90 Sekunden Wait habe ( DOIF), dann läuft es.
Ist im Controller ja auch so, wenn ein Gerät beim Provisioning ist, kann man ja auch nichts ändern.
Hi. Ok.
Eigentlich finden zu diesen Zeiten keine Befehle Richtung Controller statt..
So. Heute lief eigenartigerweise alles nach Plan.
Beobachten.
Ich wieder.
switchSiteLEDs off mittels at funktioniert super und zuverlässig.
on hat von 10x nur 1x funktioniert.
Eigenartig.
Ist dazu ein Bug bekannt?
Ich habe letztes Wochenende meine UDM Pro auf Firmware Version 1.10.0 upgedatet und im Anschluss die Network Application auf Version 6.4.54 gebracht. Jetzt ist mir aufgefallen, dass in Fhem die UDM Pro als "disconnected" angezeigt wird. Sowohl mit der Originalversion von 74_Unifi als auch mit dem Patch aus #1520 (https://forum.fhem.de/index.php/topic,40287.msg1169883.html#msg1169883 (https://forum.fhem.de/index.php/topic,40287.msg1169883.html#msg1169883)) bekomme ich beim Einloggen mit verbose 5 im Logfile ein "Failed with HTTP Code 404!" angezeigt.
Ein Reload 74_Unifi und ein erneutes Einloggen (modify-Button)habe ich durchgeführt.
Hier mal ein Logfileauszug:
2021.10.15 11:04:12 5: UniFi_UDM (Unifi_Login_Send) - executed.
2021.10.15 11:04:12 5: UniFi_UDM (Unifi_Login_Receive) - executed.
2021.10.15 11:04:12 5: UniFi_UDM (Unifi_Login_Receive) - Failed with HTTP Code 404!
2021.10.15 11:04:12 5: UniFi_UDM (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2021.10.15 11:04:17 5: UniFi_UDM: get called with ?.
2021.10.15 11:04:24 5: UniFi_UDM: Defined with url:https://192.168.1.1/proxy/network/api/s/default/, interval:30
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_Notify) - executed.
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_Notify) - checking 1 0_newClients
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_Notify) - checking 1 0_WLAN_Clients
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_Notify) - checking 1 0_WLAN_Status
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_Notify) - checking 1 0_WAN_IP
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_Notify) - checking 1 0_Gast_WLAN_Clients
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_Notify) - checking 1 state
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_Notify) - executed. - Remove all Timers & Call DoUpdate...
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_DoUpdate) - executed.
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_Login_Send) - executed.
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_initCustomClientReadings) - parsed part: . -> ^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_initCustomClientReadings) - parsed Attribute customClientReadings: {"attr_value":".:^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime","parts":{"0000000_part":{"ReadingRegEx":"^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime","nameRegEx":"."}}}.
2021.10.15 11:04:25 5: UniFi_UDM (Unifi_Login_Receive) - executed.
2021.10.15 11:04:25 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/74_Unifi.pm line 949.
2021.10.15 11:04:25 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/74_Unifi.pm line 988.
2021.10.15 11:04:25 5: UniFi_UDM (Unifi_Login_Receive) - Login Failed (without msg)! - state:''
2021.10.15 11:04:25 5: UniFi_UDM (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2021.10.15 11:04:55 5: UniFi_UDM (Unifi_Login_Send) - executed.
2021.10.15 11:04:56 5: UniFi_UDM (Unifi_Login_Receive) - executed.
2021.10.15 11:04:56 5: UniFi_UDM (Unifi_Login_Receive) - Login Failed (without msg)! - state:''
2021.10.15 11:04:56 5: UniFi_UDM (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2021.10.15 11:05:26 5: UniFi_UDM (Unifi_Login_Send) - executed.
2021.10.15 11:05:28 5: UniFi_UDM (Unifi_Login_Receive) - executed.
2021.10.15 11:05:28 5: UniFi_UDM (Unifi_Login_Receive) - Login Failed (without msg)! - state:''
2021.10.15 11:05:28 5: UniFi_UDM (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2021.10.15 11:05:58 5: UniFi_UDM (Unifi_Login_Send) - executed.
Scheinbar wurde seitens Ubiquiti wieder etwas am Einlogprozedere geändert? Oder habe ich hier irgendwas versäumt?
Ich habe gerade festgestellt das bei mir das Modul keine Unifi Devices (Switche, AP etc.)mehr aktualisiert bzw. neu einloiest. Daher geht auch Unifi Switch nicht mehr.
Hab eine UDM-Pro aktuelle EA.
Hat sonst noch wer das Problem?
Zitat von: Wolle02 am 15 Oktober 2021, 11:14:43
Ich habe letztes Wochenende meine UDM Pro auf Firmware Version 1.10.0 upgedatet und im Anschluss die Network Application auf Version 6.4.54 gebracht. Jetzt ist mir aufgefallen, dass in Fhem die UDM Pro als "disconnected" angezeigt wird. Sowohl mit der Originalversion von 74_Unifi als auch mit dem Patch aus #1520 (https://forum.fhem.de/index.php/topic,40287.msg1169883.html#msg1169883 (https://forum.fhem.de/index.php/topic,40287.msg1169883.html#msg1169883)) bekomme ich beim Einloggen mit verbose 5 im Logfile ein "Failed with HTTP Code 404!" angezeigt.
Ein Reload 74_Unifi und ein erneutes Einloggen (modify-Button)habe ich durchgeführt.
Hier mal ein Logfileauszug:
2021.10.15 11:04:12 5: UniFi_UDM (Unifi_Login_Send) - executed.
2021.10.15 11:04:12 5: UniFi_UDM (Unifi_Login_Receive) - executed.
2021.10.15 11:04:12 5: UniFi_UDM (Unifi_Login_Receive) - Failed with HTTP Code 404!
2021.10.15 11:04:12 5: UniFi_UDM (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2021.10.15 11:04:17 5: UniFi_UDM: get called with ?.
2021.10.15 11:04:24 5: UniFi_UDM: Defined with url:https://192.168.1.1/proxy/network/api/s/default/, interval:30
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_Notify) - executed.
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_Notify) - checking 1 0_newClients
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_Notify) - checking 1 0_WLAN_Clients
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_Notify) - checking 1 0_WLAN_Status
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_Notify) - checking 1 0_WAN_IP
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_Notify) - checking 1 0_Gast_WLAN_Clients
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_Notify) - checking 1 state
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_Notify) - executed. - Remove all Timers & Call DoUpdate...
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_DoUpdate) - executed.
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_Login_Send) - executed.
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_initCustomClientReadings) - parsed part: . -> ^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime
2021.10.15 11:04:24 5: UniFi_UDM (Unifi_initCustomClientReadings) - parsed Attribute customClientReadings: {"attr_value":".:^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime","parts":{"0000000_part":{"ReadingRegEx":"^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime","nameRegEx":"."}}}.
2021.10.15 11:04:25 5: UniFi_UDM (Unifi_Login_Receive) - executed.
2021.10.15 11:04:25 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/74_Unifi.pm line 949.
2021.10.15 11:04:25 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/74_Unifi.pm line 988.
2021.10.15 11:04:25 5: UniFi_UDM (Unifi_Login_Receive) - Login Failed (without msg)! - state:''
2021.10.15 11:04:25 5: UniFi_UDM (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2021.10.15 11:04:55 5: UniFi_UDM (Unifi_Login_Send) - executed.
2021.10.15 11:04:56 5: UniFi_UDM (Unifi_Login_Receive) - executed.
2021.10.15 11:04:56 5: UniFi_UDM (Unifi_Login_Receive) - Login Failed (without msg)! - state:''
2021.10.15 11:04:56 5: UniFi_UDM (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2021.10.15 11:05:26 5: UniFi_UDM (Unifi_Login_Send) - executed.
2021.10.15 11:05:28 5: UniFi_UDM (Unifi_Login_Receive) - executed.
2021.10.15 11:05:28 5: UniFi_UDM (Unifi_Login_Receive) - Login Failed (without msg)! - state:''
2021.10.15 11:05:28 5: UniFi_UDM (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2021.10.15 11:05:58 5: UniFi_UDM (Unifi_Login_Send) - executed.
Scheinbar wurde seitens Ubiquiti wieder etwas am Einlogprozedere geändert? Oder habe ich hier irgendwas versäumt?
Habe die gleiche UDM-Pro und Network Application installiert. Bei mir läuft noch alles.
Gruß Hoppel
Zitat von: Masterfunk am 18 Oktober 2021, 11:41:33
Ich habe gerade festgestellt das bei mir das Modul keine Unifi Devices (Switche, AP etc.)mehr aktualisiert bzw. neu einloiest. Daher geht auch Unifi Switch nicht mehr.
Hab eine UDM-Pro aktuelle EA.
Hat sonst noch wer das Problem?
Ja, was problem habe ich auch so etwa einmal im Monat, ich definiere das Gerät dann einmal neu, bzw gebe unter DEF die IP, Benutzername und Passwort nochmal neu ein und setzte das Attribut isUDM kurz auf 0 und wieder auf 1, danach läuft es dann wieder
Zitat von: Fillip am 25 Oktober 2021, 08:06:50
Ja, was problem habe ich auch so etwa einmal im Monat, ich definiere das Gerät dann einmal neu, bzw gebe unter DEF die IP, Benutzername und Passwort nochmal neu ein und setzte das Attribut isUDM kurz auf 0 und wieder auf 1, danach läuft es dann wieder
Hilft bei mir leider nicht.
Hallo Wuehler,
ich nutze nun schon seit Ewigkeiten das Unifiziert Modul und schiebe schon länger das Problem vor mir her, dass beim Ein- und Ausschalten meiner Gäste WLAN SSID auch immer das normale WLAN Ein- bzw. ausgeschaltet wird.
Schalte ich also über z.B.: FHEM Web im Controller mittels set disableWLAN NameSSID_guest
aus, wird auch mein normales WLAN mit NameSSID kurzzeitig deaktiviert.
Gibt es dafür eine Lösung oder habe ich ggf. nur etwas falsch konfiguriert?
Welche Infos zur Analyse des Problems werden hierfür benötigt?
Ich nutze im Unifi Controller selbst nur ein zweite Wireless Network und keinen Voucher oder Guest Portal etc.
Gruß
sTaN
Das ist auch so, wenn du es über den UnifiController direkt machst (zumindest bei mir)...
Hat also mMn nichts mit dem Modul zu tun sondern wie eben der UnifiController die AP "provisioniert"...
...wobei ich nicht weiß, ob die anderen SSDIs wirklich weg sind oder es nur so "aussieht"...
Gruß, Joachim
Na das ist ja blöd. Also die Clients disconnecten dann auch kurzzeitig und die Verbindung ist weg bzw. wird unterbrochen, daher fällt es ja so auf.
Ansonsten wäre mir das egal. Aber ist mir noch gar nicht aufgefallen, dass es sich im UnifiController selbst auch so verhält.
Gruß
sTaN
Zitat von: sTaN am 07 November 2021, 16:01:26
Ansonsten wäre mir das egal. Aber ist mir noch gar nicht aufgefallen, dass es sich im UnifiController selbst auch so verhält.
Einfach mal ausprobieren... ;)
Gruß, Joachim
Habe auch mit meiner UDM Pro das Problem, dass ich keine Daten mehr erhalte, habt ihr es gelöst bekommen?
Zitat von: Hauswart am 21 Dezember 2021, 14:04:09
Habe auch mit meiner UDM Pro das Problem, dass ich keine Daten mehr erhalte, habt ihr es gelöst bekommen?
Nein, leider nicht, da sich der Maintainer nicht meldet. Offensichtlich ist das Modul verwaist.
Siehe auch diesen Post: https://forum.fhem.de/index.php/topic,40287.msg1171206.html#msg1171206 (https://forum.fhem.de/index.php/topic,40287.msg1171206.html#msg1171206)
Heute ist mir aufgefallen, dass mein Logfile extrem viele Meldungen vom Unifi-Modul abbekommt, bspw.:
2022.01.19 08:16:18 3: Unifi: Unknown code UnifiClient_5dbf66b9b865796e0bd18c48{"fhem_state":"disconnected","is_wired":false,"first_seen":1572824761,"_f_last_seen_duration":"0d 20h 42m 3s","_f_essid":"UNDEFINED","tx_bytes":1151715732,"disconnect_timestamp":1642502406,"rx_packets":8141181,"accesspoint":"unknown","site_id":"5becb0d9e2969918885dd5f2","wifi_tx_attempts":51683,"tx_packets":4826356,"is_guest":false,"duration":14885448,"fhem_clientName":"5dbf66b9b865796e0bd18c48","mac":"e8:ab:fa:49:7c:75","_f_first_seen":"2019-11-04 00:46:01","_id":"5dbf66b9b865796e0bd18c48","last_seen":1642502055,"_f_usergroup_name":"Default","_f_last_seen":"2022-01-18 11:34:15","blocked":false,"tx_retries":0,"rx_bytes":2256951903,"oui":"Shenzhen"}, help me!
Ich setze Unifi Network 7.0.18 ein. Hat das hemand auch?
Ja, habe die Meldungen auch, soweit es aussieht ist dies hier die erste Meldung diesbezüglich in meinem Log:
2022.01.18 11:44:23 3: unifiwlan: Unknown code UnifiClient_5d70fead71d2250316df16ec{"_f_first_seen":"2019-09-05 14:25:17","mac":"00:11:32:3c:14:82","site_id":"5d01020123b661151f97d045","_f_last_seen_duration":"5d 1h 23m 14s","rx_bytes":0,"first_seen":1567686317,"tx_bytes":0,"duration":5074671,"fhem_state":"disconnected","last_seen":1642065669,"fhem_clientName":"5d70fead71d2250316df16ec","is_wired":true,"is_guest":false,"oui":"Synology","_f_last_seen":"2022-01-13 10:21:09","accesspoint":"unknown","_id":"5d70fead71d2250316df16ec","tx_retries":0,"disconnect_timestamp":1642065988,"_f_usergroup_name":"Default","rx_packets":0,"_f_essid":"UNDEFINED","tx_packets":0,"wifi_tx_attempts":0}, help me!
Seitdem wird mein Log zugemüllt.
Moin, ja, hier das gleich Problem. Seit dem Update heute kommen die Fehlermeldungen. Das Unifi-Modul an sich wurde nicht geändert, wenn ich das richtig sehe...
2022.01.19 11:13:43 3: Unifi: Unknown code UnifiClient_61cae1bb58994509c1627237{"_f_last_seen_by_usw":"2022-01-19 11:13:09","usergroup_id":"","_f_latest_assoc_time":"2022-01-18 13:23:57","mac":"7c:a6:b0:e8:f6:80","radio_proto":"ng","latest_assoc_time":1642508637,"_f_last_seen_by_uap":"2022-01-19 11:13:10","assoc_time":1642255085,"uptime":332105,"_f_usergroup_name":"Default","first_seen":1640686011,"_f_last_seen_duration":"0d 0h 0m 33s","_uptime_by_uap":78553,"essid":"OBIWLANKENOBI","channel":12,"wired_rate_mbps":1000,"oui":"","sw_mac":"74:ac:b9:47:de:2a","ccq":0,"site_id":"60a0f33621211105e6e6cf02","rx_bytes-r":4,"dev_cat":53,"wlanconf_id":"60a0f42421211105e6e6cf43","hostname_source":"ubios","fingerprint_source":0,"satisfaction_now":73,"user_group_id_computed":"60a0f33d21211105e6e6cf15","_f_uptime":"3d 20h 15m 5s","ip":"192.168.1.223","powersave_enabled":true,"network_id":"60a0f33d21211105e6e6cf14","_is_guest_by_uap":false,"_last_seen_by_uap":1642587190,"network":"Default","tx_bytes-r":3,"ap_mac":"78:45:58:6b:59:18","bssid":"78:45:58:6b:59:19","qos_policy_applied":true,"satisfaction":85,"_f_uptime_by_uap":"0d 21h 49m 13s","anomalies":0,"radio":"ng","_f_last_seen_by_ugw":"2022-01-19 11:13:09","_last_seen_by_usw":1642587189,"_uptime_by_ugw":332105,"dhcpend_time":120,"rx_bytes":118105,"_id":"61cae1bb58994509c1627237","tx_rate":65000,"_f_first_seen":"2021-12-28 11:06:51","_f_last_seen":"2022-01-19 11:13:10","disconnect_timestamp":1642508636,"vlan":0,"sw_port":4,"bytes-r":7,"user_id":"61cae1bb58994509c1627237","last_seen":1642587190,"signal":-41,"hostname":"","os_name":1,"is_11r":false,"_is_guest_by_ugw":false,"wifi_tx_attempts":1485,"satisfaction_reason":8,"satisfaction_real":85,"tx_retries":0,"dev_vendor":405,"rx_packets":1938,"fhem_state":"connected","fingerprint_engine_version":"0.0.0","confidence":36,"is_guest":false,"_f_uptime_by_ugw":"3d 20h 15m 5s","tx_power":0,"blocked":false,"anon_client_id":"58ce3b65f3f182948abfcce1fb18aa","authorized":true,"dev_id":3584,"fhem_clientName":"61cae1bb58994509c1627237","_uptime_by_usw":332105,"_last_seen_by_ugw":1642587189,"rx_rate":65000,"tx_bytes":95617,"is_wired":false,"rssi":55,"noise":-96,"tx_packets":1450,"_f_uptime_by_usw":"3d 20h 15m 5s","sw_depth":1,"eagerly_discovered":null,"radio_name":"ra0","idletime":25,"_is_guest_by_usw":false,"_f_essid":"OBIWLANKENOBI","dev_family":7,"_f_dhcpend_time":"0d 0h 2m 0s","tx_mcs":7,"gw_mac":"e0:63:da:21:aa:0d","accesspoint":"unknown","_f_assoc_time":"14d 13h 58m 5s"}, help me!
Ist bei mir auch so, allerdings mit den Stable-Versionen 1.11.0 der UDM Pro und 6.5.55 der Network-App.
Das ist interessant, ich vermutete eben eine neue Controller-Version. Ich habe mir mit verbose im Unifi-Modul übergangsweise geholfen.
Wuehler war zuletzt vor ein paar Tagen online ???
Hallo zusammen
Ich habe das gleiche Problem. Das Unifi Modul wurde nicht geändert. Ich habe geguckt welches geändert Modul da verantwortlich sein kann es scheint die fhem.pl zu sein die am 17.1.22 geändert wurde.
Ich habe die vorherige Version wieder eingespielt und die Meldungen sind ertmal verschwunden im Log.
Jetzt müsste man den Zusammenhang kennen zwischen der fhem.pl und dem Unifi Modul.
VG Alex
Sehr guter Hinweis!
Am 17.01. wurde durch Rudolf eine Änderung durchgeführt, die ein Splitting durchführt - das könnte hier das Problem sein.
https://svn.fhem.de/trac/changeset?reponame=&old=25489%40%2F&new=25489%40%2F
Hallo in die Runde,
ich war mal so frei mir eine UDM-Pro-SE zu kaufen. Diese habe ich gerade eingerichtet, im Netzwerk läuft so weit wieder alles. Im FHEM Unifi Device kommt allerdings statt valider clientData größtenteils nur noch Kauderwelsch an. Meine UDM-Pro-SE und meine zusätzlichen 4 Switches werden leider auch nicht mehr vom Modul in FHEM angelegt. Ich habe alles, was in Verbindung mit dem Unifi Device angelegt wurde einmal gelöscht und FHEM neugestartet. Anschließend die Definition neu erstellt. Bringt aber nichts.
Mein FHEM ist nicht ganz up-to-date, aber sehr alt ist es auch nicht. Sollte meiner Ansicht nach keine Rolle spielen. Im Gegenteil, wenn es gerade Probleme im Code gibt, wäre es ja sogar Kontraproduktiv. ;)
Im Logfile sehe ich folgende Meldung:
2022.01.20 22:35:33 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/74_Unifi.pm line 939.
Ist @Wuehler hier denn überhaupt noch aktiv? Welche Informationen werden benötigt, um das irgendwann wieder zum Fliegen zu bekommen? Ich kann gern ein list vom Device bereitstellen, aber nicht hier "öffentlich". Da sind für meinen Geschmack zu viele sensible Daten enthalten.
Viele Grüße Hoppel
Zitat von: choenig am 10 August 2021, 07:59:50
Sodele,
im Anhang sind die Patches, die es bei mir fixen. Zusätzlich habe ich noch eine Version angehäng, die die Patches enthält. Ich weiss nicht, ob das so auch noch in der nicht-unifi-os-version funktioniert. Wäre schön, wenn das mal jemand testen kann, der keine DreamMachine hat.
EDIT: Nach dem reload 74_Unifi muss man sich einmal neu einloggen (Klick auf `DEF`, dann `modify <UNIFI_DEVICE>`).
LG
Christian
Hi, ich habe gerade mal versucht meine neue UDM-Pro-SE mit der von @choenig angepassten Modul Version in FHEM einzurichten. Das klappt leider auch nicht. Das Define habe ich wie folgt ausgeführt:
define UnifiNetwork Unifi <IP.der.UDM.SE> 443 <user> <password> 90 default
Der User ist auf der UDM eingerichtet.
Hier mal ein verbose 5 Start mit deiner Unifi Modul Version:
- UnifiNetwork (Unifi_Login_Receive) - Login successfully! X-CSRF-Token: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
- UnifiNetwork (Unifi_GetUnarchivedAlerts_Receive) - Failed! - state:'Error while requesting' - msg:'https://x.x.x.x/proxy/network/api/s/default/list/alarm - read from https://x.x.x.x:443 timed out'
- UnifiNetwork (Unifi_GetEvents_Receive) - Failed! - state:'Error while requesting' - msg:'https://x.x.x.x/proxy/network/api/s/default/stat/event - read from https://x.x.x.x:443 timed out'
- UnifiNetwork (Unifi_GetAccesspoints_Receive) - Failed! - state:'Error while requesting' - msg:'https://x.x.x.x/proxy/network/api/s/default/stat/device - read from https://x.x.x.x:443 timed out'
2022.01.22 19:23:44 5: UnifiNetwork (Unifi_Notify) - executed.
2022.01.22 19:23:44 5: UnifiNetwork: get called with ?.
2022.01.22 19:24:03 5: UnifiNetwork: set called with clear all
2022.01.22 19:24:03 4: UnifiNetwork: set clear
2022.01.22 19:24:03 5: UnifiNetwork: get called with ?.
2022.01.22 19:24:08 5: UnifiNetwork (Unifi_Notify) - executed.
2022.01.22 19:24:18 5: UnifiNetwork (Unifi_Notify) - executed.
2022.01.22 19:24:18 5: UnifiNetwork: get called with ?.
2022.01.22 19:24:41 5: UnifiNetwork (Unifi_Notify) - executed.
2022.01.22 19:24:41 5: UnifiNetwork: get called with ?.
2022.01.22 19:24:49 5: UnifiNetwork (Unifi_DoUpdate) - executed.
2022.01.22 19:24:49 5: UnifiNetwork (Unifi_Login_Send) - executed.
2022.01.22 19:24:49 5: UnifiNetwork (Unifi_Notify) - executed.
2022.01.22 19:24:49 5: UnifiNetwork: get called with ?.
2022.01.22 19:24:49 5: UnifiNetwork (Unifi_Login_Receive) - executed.
2022.01.22 19:24:49 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/74_Unifi.pm line 949.
2022.01.22 19:24:49 5: UnifiNetwork (Unifi_Login_Receive) - state=ok
2022.01.22 19:24:49 5: UnifiNetwork (Unifi_Login_Receive) - Login successfully! X-CSRF-Token: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Cookie: TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx;
Content-Type: application/json
2022.01.22 19:24:49 5: UnifiNetwork (Unifi_GetSysinfo_Send) - executed.
2022.01.22 19:24:49 5: UnifiNetwork (Unifi_UsergroupRestJson_Send) - executed.
2022.01.22 19:24:49 5: UnifiNetwork (Unifi_UsergroupRestJson_Receive) - executed.
2022.01.22 19:24:49 5: UnifiNetwork (Unifi_UsergroupRestJson_Receive) - state:'ok'
2022.01.22 19:24:49 5: UnifiNetwork (Unifi_GetSysinfo_Receive) - executed.
2022.01.22 19:24:49 5: UnifiNetwork (Unifi_GetSysinfo_Receive) - state:'ok'
2022.01.22 19:24:49 5: UnifiNetwork (Unifi_GetSysinfo_Receive) - uc_version: 6.5.55
2022.01.22 19:25:10 5: UnifiNetwork (Unifi_Notify) - executed.
2022.01.22 19:26:19 5: UnifiNetwork (Unifi_DoUpdate) - executed.
2022.01.22 19:26:19 5: UnifiNetwork (Unifi_GetUnarchivedAlerts_Send) - executed.
2022.01.22 19:26:21 5: UnifiNetwork: get called with ?.
2022.01.22 19:26:24 5: UnifiNetwork (Unifi_GetUnarchivedAlerts_Receive) - executed.
2022.01.22 19:26:24 5: UnifiNetwork (Unifi_GetUnarchivedAlerts_Receive) - Failed! - state:'Error while requesting' - msg:'https://x.x.x.x/proxy/network/api/s/default/list/alarm - read from https://x.x.x.x:443 timed out'
2022.01.22 19:26:24 5: UnifiNetwork (Unifi_GetHealth_Send) - executed.
2022.01.22 19:26:24 5: UnifiNetwork (Unifi_GetHealth_Receive) - executed.
2022.01.22 19:26:24 5: UnifiNetwork (Unifi_GetHealth_Receive) - state:'ok'
2022.01.22 19:26:24 5: UnifiNetwork (Unifi_GetWlans_Send) - executed.
2022.01.22 19:26:24 5: UnifiNetwork (Unifi_GetWlans_Receive) - executed.
2022.01.22 19:26:24 5: UnifiNetwork (Unifi_GetWlans_Receive) - state:'ok'
2022.01.22 19:26:24 5: UnifiNetwork (Unifi_GetEvents_Send) - executed.
2022.01.22 19:26:29 5: UnifiNetwork (Unifi_GetEvents_Receive) - executed.
2022.01.22 19:26:29 5: UnifiNetwork (Unifi_GetEvents_Receive) - Failed! - state:'Error while requesting' - msg:'https://x.x.x.x/proxy/network/api/s/default/stat/event - read from https://x.x.x.x:443 timed out'
2022.01.22 19:26:29 5: UnifiNetwork (Unifi_GetAccesspoints_Send) - executed.
2022.01.22 19:26:34 5: UnifiNetwork (Unifi_GetAccesspoints_Receive) - executed.
2022.01.22 19:26:34 5: UnifiNetwork (Unifi_GetAccesspoints_Receive) - Failed! - state:'Error while requesting' - msg:'https://x.x.x.x/proxy/network/api/s/default/stat/device - read from https://x.x.x.x:443 timed out'
2022.01.22 19:26:34 5: UnifiNetwork (Unifi_GetClientInsights_Send) - executed.
2022.01.22 19:26:34 5: UnifiNetwork (Unifi_GetClientInsights_Receive) - executed.
2022.01.22 19:26:34 5: UnifiNetwork (Unifi_GetClientInsights_Receive) - state:'ok'
2022.01.22 19:26:34 5: UnifiNetwork (Unifi_GetVoucherList_Send) - executed.
2022.01.22 19:26:34 5: UnifiNetwork (Unifi_GetVoucherList_Receive) - executed.
2022.01.22 19:26:34 5: UnifiNetwork (Unifi_GetVoucherList_Receive) - state:'ok'
2022.01.22 19:26:34 5: UnifiNetwork (Unifi_GetClients_Send) - executed.
2022.01.22 19:26:34 5: UnifiNetwork (Unifi_GetClients_Receive) - executed.
2022.01.22 19:26:34 5: UnifiNetwork (Unifi_GetClients_Receive) - state:'ok'
2022.01.22 19:26:34 5: UnifiNetwork (Unifi_ProcessUpdate) - executed after 15.3659 seconds.
2022.01.22 19:26:34 5: UnifiNetwork (Unifi_SetHealthReadings) - executed.
2022.01.22 19:26:34 5: UnifiNetwork (Unifi_SetClientReadings) - executed.
2022.01.22 19:26:34 5: UnifiNetwork (Unifi_SetClientReadings) - Dispatch: LGwebOSTV
Anschließend werden die Clients eingelesen. Ich habe allerdings diverse Clients, die mir statt einem Namen nur Nummern anzeigen, hier ein paar Beispiele:
2022-01-22 19:26:34 Unifi UnifiNetwork 5ddd365d0c0ab41a9dfb98a3: connected
2022-01-22 19:26:34 Unifi UnifiNetwork 5ddd365d0c0ab41a9dfb98a3_hostname:
2022-01-22 19:26:34 Unifi UnifiNetwork 5ddd365d0c0ab41a9dfb98a3_last_seen: 2022-01-22 19:25:51
2022-01-22 19:26:34 Unifi UnifiNetwork 5ddd365d0c0ab41a9dfb98a3_uptime: 156512
2022-01-22 19:26:34 Unifi UnifiNetwork 5ddd365d0c0ab41a9dfb98a3_snr: 41
2022-01-22 19:26:34 Unifi UnifiNetwork 5ddd365d0c0ab41a9dfb98a3_essid: xxx
2022-01-22 19:26:34 Unifi UnifiNetwork 5ddd365d0c0ab41a9dfb98a3_accesspoint: unknown
2022-01-22 19:26:34 Unifi UnifiNetwork 5ed2c5e70c0abe9ea12faeb2: connected
2022-01-22 19:26:34 Unifi UnifiNetwork 5ed2c5e70c0abe9ea12faeb2_hostname:
2022-01-22 19:26:34 Unifi UnifiNetwork 5ed2c5e70c0abe9ea12faeb2_last_seen: 2022-01-22 19:26:09
2022-01-22 19:26:34 Unifi UnifiNetwork 5ed2c5e70c0abe9ea12faeb2_uptime: 158863
2022-01-22 19:26:34 Unifi UnifiNetwork 5ed2c5e70c0abe9ea12faeb2_essid: UNDEFINED
2022-01-22 19:26:34 Unifi UnifiNetwork 5ed2c5e70c0abe9ea12faeb2_accesspoint: unknown
2022-01-22 19:26:34 Unifi UnifiNetwork iPhone: connected
2022-01-22 19:26:34 Unifi UnifiNetwork iPhone_hostname: iPhone
2022-01-22 19:26:34 Unifi UnifiNetwork iPhone_last_seen: 2022-01-22 19:25:52
2022-01-22 19:26:34 Unifi UnifiNetwork iPhone_uptime: 84086
2022-01-22 19:26:34 Unifi UnifiNetwork iPhone_snr: 30
2022-01-22 19:26:34 Unifi UnifiNetwork iPhone_essid: xxx
2022-01-22 19:26:34 Unifi UnifiNetwork iPhone_accesspoint: unknown
2022-01-22 19:26:34 Unifi UnifiNetwork 61ccdcee917044047810e189: connected
2022-01-22 19:26:34 Unifi UnifiNetwork 61ccdcee917044047810e189_hostname:
2022-01-22 19:26:34 Unifi UnifiNetwork 61ccdcee917044047810e189_last_seen: 2022-01-22 19:25:53
2022-01-22 19:26:34 Unifi UnifiNetwork 61ccdcee917044047810e189_uptime: 158899
2022-01-22 19:26:34 Unifi UnifiNetwork 61ccdcee917044047810e189_snr: 27
2022-01-22 19:26:34 Unifi UnifiNetwork 61ccdcee917044047810e189_essid: xxx
2022-01-22 19:26:34 Unifi UnifiNetwork 61ccdcee917044047810e189_accesspoint: unknown
2022-01-22 19:26:34 Unifi UnifiNetwork 5ddbf8540c0ab41a9dfab5fb: connected
2022-01-22 19:26:34 Unifi UnifiNetwork 5ddbf8540c0ab41a9dfab5fb_hostname:
2022-01-22 19:26:34 Unifi UnifiNetwork 5ddbf8540c0ab41a9dfab5fb_last_seen: 2022-01-22 19:25:52
2022-01-22 19:26:34 Unifi UnifiNetwork 5ddbf8540c0ab41a9dfab5fb_uptime: 156612
2022-01-22 19:26:34 Unifi UnifiNetwork 5ddbf8540c0ab41a9dfab5fb_snr: 27
2022-01-22 19:26:34 Unifi UnifiNetwork 5ddbf8540c0ab41a9dfab5fb_essid: xxx
2022-01-22 19:26:34 Unifi UnifiNetwork 5ddbf8540c0ab41a9dfab5fb_accesspoint: unknown
Wie bereits erwähnt, es wird kein einziges Gerät angelegt, weder die UDM noch meine Switche.
Wer kann mich unterstützen das zu lösen oder mich in die richtige Richtung zu schubsen?
Anscheinend haben sich die API Pfade geändert. Wie finde ich die richtigen Pfade heraus?
Viele Grüße Hoppel
sub Unifi_GetAccesspoints_Send($) { # TODO Umbenennen in Unifi_GetDevices_Send. Dann muss man auch an Get_ApNames() ran, da dort nicht nur APs sondern auch usg und switch drin sind.
# Waren wohl früher in Version 1 des Moduls nur APs unter devices
my ($hash) = @_;
my ($name,$self) = ($hash->{NAME},Unifi_Whoami());
Log3 $name, 5, "$name ($self) - executed.";
HttpUtils_NonblockingGet( {
%{$hash->{httpParams}},
url => $hash->{unifi}->{url}."stat/device",
callback => $hash->{updateDispatch}->{$self}[2],
method => "GET",
#data => "{\"_depth\":2, \"test\":0}",
} );
return undef;
}
Zeile 1450 (bei mir) auskommentieren (wie oben) hat bei mir den gewünschten Erfolg gebracht. Es könnte aber sein, dass das auf schwachbrüstigen Systemen Auswirkungen auf die Gesamtperformance hat.
@marvin78 Soll ich Deinen Post als Antwort auf meine UDM-Pro-SE-Thematik verstehen oder war das auf die anderen Probleme bezogen die gerade bestehen?
Hast du auch eine UDM-Pro-SE?
Ich schau mir deinen Post später nochmal genauer an. Bin gerade unterwegs.
Gruß Hoppel
Zitat von: hoppel118 am 22 Januar 2022, 20:23:28
@marvin78 Soll ich Deinen Post als Antwort auf meine UDM-Pro-SE-Thematik verstehen oder war das auf die anderen Probleme bezogen die gerade bestehen?
Hast du auch eine UDM-Pro-SE?
Ich schau mir deinen Post später nochmal genauer an. Bin gerade unterwegs.
Gruß Hoppel
Direkte Antwort ohne Zitat. Muss sich also auf den Beitrag über meinem beziehen, wie in Foren üblich.;) Ich glaube nicht, dass sich hier UDMPro und SE sehr unterscheiden.
Alles klar. ;) Dann schau ich mir das nachher an.
Ich melde mich dann nochmal.
Danke dir und Gruß Hoppel
By the way... Am OS der UDM-Pro-SE hat sich wohl einiges geändert im Vergleich zur UDM-Pro-SE.
• UDM-Pro: v1.11.0
• UDM-Pro-SE: v2.3.11
Keine Ahnung, wie die API zur Firmwareversion in Beziehung steht. Aber der Versionssprung ist ja schon etwas größer. Wo wird die API denn bereitgestellt, von der ,,UDM Basis" oder von der Network Application?
Anscheinend ist das Root filesystem der UDM-Pro-SE nun persistent:
https://github.com/boostchicken-dev/udm-utilities/issues/214
Gruß Hoppel
Zitat von: hoppel118 am 22 Januar 2022, 20:44:50
By the way... Am OS der UDM-Pro-Se hat sich wohl einiges geändert im Vergleich zur UDM-Pro-SE.
• UDM-Pro: v1.11.0
• UDM-Pro-SE: v2.3.11
Keine Ahnung, wie die API zur Firmwareversion in Beziehung steht. Aber Versionssprung ist ja schon etwas größer.
Anscheinend ist das Root filesystem nur persistent:
https://github.com/boostchicken-dev/udm-utilities/issues/214
Gruß Hoppel
Ich rede nur von der API.
Ich steck da nicht so drin. Also sorry, wenn ich hier Sachen durcheinander werfe.
Ich probiere deinen Vorschlag nachher aus und dann schauen wir weiter. ;)
Ich melde mich. Bis dann
@marvin78
Perfekt, meine Geräte sind alle wieder da. Die API Fehler sind weg.
Jetzt habe ich noch das Problem mit den komischen Namen. Ich habe gerade mal versucht herauszufinden, was da los ist.
Dabei ist mir relativ schnell aufgefallen, dass jedes Client Device, dass in der FHEM Unifi Definition keinen "hostname" hat, eine Nummer erhält. Das ist erstmal irgendwie logisch. Hier ein paar Beispiele:
2022-01-22 22:53:03 Unifi UnifiNetwork 5f0b658b0c0abe9ea13fdea7: connected
2022-01-22 22:53:03 Unifi UnifiNetwork 5f0b658b0c0abe9ea13fdea7_hostname:
2022-01-22 22:53:03 Unifi UnifiNetwork 5f0b658b0c0abe9ea13fdea7_last_seen: 2022-01-22 22:53:02
2022-01-22 22:53:03 Unifi UnifiNetwork 5f0b658b0c0abe9ea13fdea7_uptime: 168933
2022-01-22 22:53:03 Unifi UnifiNetwork 5f0b658b0c0abe9ea13fdea7_snr: 67
2022-01-22 22:53:03 Unifi UnifiNetwork 5f0b658b0c0abe9ea13fdea7_essid: xxx
2022-01-22 22:53:03 Unifi UnifiNetwork 5f0b658b0c0abe9ea13fdea7_accesspoint: u6-pro-living
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za5_mibtC903: connected
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za5_mibtC903_hostname: zhimi-fan-za5_mibtC903
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za5_mibtC903_last_seen: 2022-01-22 22:53:02
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za5_mibtC903_uptime: 171268
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za5_mibtC903_snr: 44
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za5_mibtC903_essid: xxx
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za5_mibtC903_accesspoint: u6-pro-living
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za4_mibt3ABE: connected
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za4_mibt3ABE_hostname: zhimi-fan-za4_mibt3ABE
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za4_mibt3ABE_last_seen: 2022-01-22 22:53:02
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za4_mibt3ABE_uptime: 171275
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za4_mibt3ABE_snr: 52
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za4_mibt3ABE_essid: xxx
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za4_mibt3ABE_accesspoint: u6-pro-gallery
2022-01-22 22:53:03 Unifi UnifiNetwork AppleTV: connected
2022-01-22 22:53:03 Unifi UnifiNetwork AppleTV_hostname: AppleTV
2022-01-22 22:53:03 Unifi UnifiNetwork AppleTV_last_seen: 2022-01-22 22:53:02
2022-01-22 22:53:03 Unifi UnifiNetwork AppleTV_uptime: 171264
2022-01-22 22:53:03 Unifi UnifiNetwork AppleTV_essid: UNDEFINED
2022-01-22 22:53:03 Unifi UnifiNetwork AppleTV_accesspoint: usw-lite-living
2022-01-22 22:53:03 Unifi UnifiNetwork 5ddd365d0c0ab41a9dfb98a3: connected
2022-01-22 22:53:03 Unifi UnifiNetwork 5ddd365d0c0ab41a9dfb98a3_hostname:
2022-01-22 22:53:03 Unifi UnifiNetwork 5ddd365d0c0ab41a9dfb98a3_last_seen: 2022-01-22 22:53:02
2022-01-22 22:53:03 Unifi UnifiNetwork 5ddd365d0c0ab41a9dfb98a3_uptime: 168943
2022-01-22 22:53:03 Unifi UnifiNetwork 5ddd365d0c0ab41a9dfb98a3_snr: 40
2022-01-22 22:53:03 Unifi UnifiNetwork 5ddd365d0c0ab41a9dfb98a3_essid: xxx
2022-01-22 22:53:03 Unifi UnifiNetwork 5ddd365d0c0ab41a9dfb98a3_accesspoint: u6-pro-gallery
2022-01-22 22:53:03 Unifi UnifiNetwork Galaxy-A40: connected
2022-01-22 22:53:03 Unifi UnifiNetwork Galaxy-A40_hostname: Galaxy-A40
2022-01-22 22:53:03 Unifi UnifiNetwork Galaxy-A40_last_seen: 2022-01-22 22:53:02
2022-01-22 22:53:03 Unifi UnifiNetwork Galaxy-A40_uptime: 33687
2022-01-22 22:53:03 Unifi UnifiNetwork Galaxy-A40_snr: 29
2022-01-22 22:53:03 Unifi UnifiNetwork Galaxy-A40_essid: xxx
2022-01-22 22:53:03 Unifi UnifiNetwork Galaxy-A40_accesspoint: u6-pro-basement
War das schon immer so?
Bei manchen Devices (insbesondere bei diesem IoT Zeugs) kann man ja gar keinen Hostname definieren.
Wenn ich mir jetzt so das verbose 5 bspw. für das Device 5ddd365d0c0ab41a9dfb98a3 (ohne Hostname) anschaue, dann gibt es da durchaus verwertbare Informationen. Ich habe bspw. für alle meine Geräte manuell einen name im WebInterface der Unifi Network Application angelegt.
"name":"Sonos Galerie"
FHEM macht dann das daraus: "fhem_clientName":"5ddd365d0c0ab41a9dfb98a3"
Das "name" Feld zu nehmen, würde sicherlich zu den gleichen Herausforderungen führen, da nicht jeder an jedem Gerät in der Unifi Network Application einen eigenen Namen vergibt.
Jetzt bleibt bei mir einfach die Frage, ob das bei euch auch so ist?
Wie dem auch sei, hauptsächlich benötige ich diese Client Informationen, um den Presence Status zu ermitteln. Für die beiden relevanten iPhones ist das erstmal kein Problem.
Super, vielen Dank und einen schönen Abend noch!
Gruß Hoppel
OK, habe den Fehler gefunden. Neulich dachte ich irgendwann, dass es in der App schöner aussieht, wenn ich im Namen auf Bindestriche verzichte. Also habe ich bspw. aus
Hoppels-iPhone-13-Pro-Max
folgendes gemacht
Hoppels iPhone 13 Pro Max
Dies habe ich gerade testweise bei zwei Clients rückgängig gemacht und schon werden im FHEM Unifi Device neue Client Devices angelegt, die den "name" verwenden.
Anscheinend prüft das Modul den "name" auf Leerzeichen oder ähnliches. Sobald da Leerzeichen im "name" enthalten sind, wird der Hostname genommen. Schade. Schöner wäre es, wenn das Unifi FHEM Modul die Leerzeichen einfach durch bspw. Bindestriche ersetzen würde (und außerdem Umlaute wie folgt übersetzt ä=ae, ü=ue, ö=oe, ß=ss).
Oder gibt es da irgendeinen Trick, den ich nicht kenne?
Ich habe das Modul also jetzt erstmal wieder so mit meiner UDM-Pro-SE laufen, wie vorher mit der UDM-Pro. Habe gerade nochmal in allen Namen den Bindestrich ergänzt und anschließend am FHEM Unifi Device ein clear all ausgeführt. ;)
Das ist wirklich sehr, sehr schön! :D
Danke euch und Gruß Hoppel
Zitat von: marvin78 am 22 Januar 2022, 20:06:05
Zeile 1450 (bei mir) auskommentieren (wie oben) hat bei mir den gewünschten Erfolg gebracht. Es könnte aber sein, dass das auf schwachbrüstigen Systemen Auswirkungen auf die Gesamtperformance hat.
Super, herzlichen Dank - und schon sind meine Switche mit ihren Werten auch wieder da und grafisch auswertbar :)
Zitat von: marvin78 am 22 Januar 2022, 20:06:05
sub Unifi_GetAccesspoints_Send($) { # TODO Umbenennen in Unifi_GetDevices_Send. Dann muss man auch an Get_ApNames() ran, da dort nicht nur APs sondern auch usg und switch drin sind.
# Waren wohl früher in Version 1 des Moduls nur APs unter devices
my ($hash) = @_;
my ($name,$self) = ($hash->{NAME},Unifi_Whoami());
Log3 $name, 5, "$name ($self) - executed.";
HttpUtils_NonblockingGet( {
%{$hash->{httpParams}},
url => $hash->{unifi}->{url}."stat/device",
callback => $hash->{updateDispatch}->{$self}[2],
method => "GET",
#data => "{\"_depth\":2, \"test\":0}",
} );
return undef;
}
Zeile 1450 (bei mir) auskommentieren (wie oben) hat bei mir den gewünschten Erfolg gebracht. Es könnte aber sein, dass das auf schwachbrüstigen Systemen Auswirkungen auf die Gesamtperformance hat.
Guten Morgen Marvin,
betrifft diese Änderung nur den UDM-Pro oder auch den USG-3 Router, und evtl. Access Points?
Viele Grüße Gisbert
Zitat von: Gisbert am 23 Januar 2022, 07:06:22
Guten Morgen Marvin,
betrifft diese Änderung nur den UDM-Pro oder auch den USG-3 Router, und evtl. Access Points?
Viele Grüße Gisbert
Das weiß ich leider nicht. Nur mit UDMPro getestet.
Hallo Marvin. Ich habe einen CloudKey-Gen2-Plus. Nach dem Patch werden die Switches wieder sauber erkannt und ich kann auch wieder die POE-Ports ein-/ausschalten. Vielen Dank für die schnelle Hilfe.
Gruß Klaus
Guten Abend,
seit einigen Tagen wird bei mir Accesspoint nicht mehr übertragen mit welchen sich mein Handy verbunden hat.
Hat noch jemand so ein verhalten beobachten können oder gar eine Lösung?
Im post #1569 von hoppel118 stand auch als accesspoint = unknown.
Edit:
Beim Schreiben merke ich gerade das die Mac des AP´s mit welchen ich verbunden bin erkannt wird (blauer Kreiß).
Jemand eine Idee ?
LG
Dennis
Hi @MrStonedfire
folgenden Beitrag hast du gesehen?
https://forum.fhem.de/index.php/topic,40287.msg1202774.html#msg1202774
Seit ich diese Änderung umgesetzt habe, läuft das Modul bei mir.
Gruß Hoppel
Zitat von: hoppel118 am 04 Februar 2022, 01:53:39
Hi @MrStonedfire
folgenden Beitrag hast du gesehen?
https://forum.fhem.de/index.php/topic,40287.msg1202774.html#msg1202774
Seit ich diese Änderung umgesetzt habe, läuft das Modul bei mir.
Gruß Hoppel
Danke für die schnelle antwort.
Ich hatte die falsche Zeile auskommentiert....
Jetzt sollte meine Heizung auch wieder das tuen was sie soll.
Vielen Dank.
Hallöchen,
bin ich eigentlich der einzige der eine Dream Machine einsetzt und keine Voucher über FHEM erzeugen kann?
Das Log schreibt mir folgendes dazu:
2022.02.04 11:47:31 4: UDMPro Info: vouchers without note or containing comma(,) in note or with empty note are ignored in drop-downs.
2022.02.04 11:47:31 5: UDMPro (Unifi_CreateVoucher_Receive) - executed.
2022.02.04 11:47:31 5: UDMPro (Unifi_CreateVoucher_Receive) - Failed! - state:'403' - msg:'Failed with HTTP Code 403.'
Der Aufruf erfolgte mit:
set UDMPro createVoucher 6600 1 1 fhem
Attribut isUDM ist korrekt auf 1 gesetzt.
Danke & Gruß
Martin
Hi,
Zitat von: M@d am 04 Februar 2022, 11:52:40
bin ich eigentlich der einzige der eine Dream Machine einsetzt und keine Voucher über FHEM erzeugen kann?
Ich verfolge das hier nicht im Detail. Benutzt du die originale Version oder meine gepatchte aus diesem Thread? Ich denke, dass es mit der gepatchten (noch) funktioniert.
LG
Christian
Danke für den Hinweis, das kann ich mal ausprobieren, bisher verwende ich die originale Version.
hallo zusammen,
da ich mich gerade mit der erweiterung des unifi protect moduls beschäftige (siehe: https://forum.fhem.de/index.php/topic,126024.msg1206184.html#msg1206184) sind mir ein paar dinge aufgefallen die im netzwerk vorhandene unifi komponenten und deren zusammenspiel betreffen.
mit der umstellung auf unifi os ist es möglich aus jeder unifi console (d.h. udm, cloud key, unvr, ...) auszulesen welche controller (network/protect/...) jeweils installiert sind, welche unifi os systeme es noch im netz gibt, welche controller eventuell dort installiert sind und welche netzwerk und protect endgeräte es im netz gibt.
ausserdem unterstütz scheinbar jeder console und jeder controller push events für alle möglichen dinge.
mit diesen informationen könnte man die unifi module deutlich erweitern, besser zusammen arbeiten lassen und durch das auswerten der events das regelmäßige pollen und damit die fhem systemlast reduzieren.
gibt es interesse an einer solchen globalen umstellung?
das ganze könnte in etwa so aussehen: statt jeweils zweistufigen modulen für unifi und unifi protect gibt es ein drei- oder vierstufiges vorgehen:
- unifi als oberste ebene, für jede console gibt es ein solches fhem device.
hier landet information über cpu, health, platten, eventuell firmware updates, ...
- das unifi modul müsste ein mal für irgend eine console (d.h. mit deren ip) in fhem angelegt werden
- wenn es im netz weitere unifi consolen gibt werden deren fhem devices automatisch angelegt
- für alle installierten und unterstützten controller (network, protect, ...?) wird jeweils automatisch
ein fhem device angelegt
- dieses kümmert sich um die jeweiligen events und daten für die es zuständig ist und erzeugt jeweils
die fhem devices für die endgeräte (kameras, switche, wlan router, ...)
- diese kümmern sich um die jeweils verbunden endgeräte und plan nutzer. diese vierte ebene vermutlich
optional und nicht mehr automatisch sondern von hand angelegt.
Hi Andre,
ich habe die ,,Befürchtung", dass es dann darauf hinausläuft, dass du das Modul übernimmst. :)
@Wuehler hat hier in den letzten Jahren sehr gute Arbeit geleistet, aber sich hier auch schon länger nicht mehr gemeldet.
Das Modul wurde bei mir und anderen schon manuell angepasst und auch vom FHEM Update ausgeschlossen, weil die manuellen Änderungen sonst übergebügelt werden.
Grundsätzlich wäre es richtig cool, wenn es so abläuft, wie du es beschreibst. Grundsätzlich kommen da ja auch noch weitere Module neben Protect dazu, bspw. Access, Talk, UID, whatever.
Der UnifiClient müsste sich dann da für Presence auch irgendwie einreihen. Oder ist das die 4. Ebene?
Als Tester für das neue Gesamtkonstrukt hast du mich bereits gewonnen (falls es denn so kommt). :D
Gruß Hoppel
Zitat von: justme1968 am 07 Februar 2022, 17:34:05
gibt es interesse an einer solchen globalen umstellung?
Definitiv!
Ich fände es super wenn das alles Hand in Hand gehen würde.
Diese Woche werde ich auch auf "Unifi Protect" umstellen. Der alte CloudKey fliegt raus und ein "Gen2 Plus" kommt stattdessen. Hab mal eine G3-Instant und eine G4-Dome Kamera als Ergänzung zu meinen G3-Bullets mit bestellt. Bin gespannt wie Qualität der G4 ist.
Gruß
Dan
Kann es sein, das der Disconnect nicht richtig funktioniert?
Hab ein Gerät, dass öfter mal im WLAN strauchelt. Wenn ich es direkt über den Unifi-Controller neu verbinden (reconnect) lasse, dann ist es nach wenigen Sekunden wieder einwandfrei erreichbar. Probiere ich das aber über das Unifi-Device, so ist das nicht der Fall. Auch die Uptime ändert sich nicht, während die über den Controller wieder auf 0 gesetzt wird.
Auf dem Controller läuft "Network Version 6.5.55".
Guten Abend zusammen.
Ich habe nach wie vor ab und zu Probleme.
SwitchSiteLEDs funktioniert ganz gut, bis ich das Gast-WLAN aktiviere/deaktiviere.
Danach funktioniert SwitchSiteLEDs in 100% der Fälle nicht mehr.
Das UniFi-Web bekommt das zwar mit (Haken rein/raus) wenn ich den Befehl über FHEM absetze,
aber die LEDs schalten nicht.
Es hilft meist nur ein Reboot von FHEM + Controller.
Sehr unpraktisch...
Vielleicht hat da noch jemand einen Hinweis für mich?!
Ist das aktuelle Modul inzwischen automatisch über FHEM-Update verfügbar?
Bis jetzt habe ich das Modul excluded.
Einen schönen Abend.
Guten Abend,
neue Erkenntnisse.
ZitatDas UniFi-Web bekommt das zwar mit (Haken rein/raus) wenn ich den Befehl über FHEM absetze,
aber die LEDs schalten nicht.
Nach einem manuellen "PROVISION" auf die APs über das Controller-Web schalten die LEDs wie gewünscht ein/aus.
Zuverlässig reproduzierbar.
Jetzt ist die Frage: wie kann man einem
SwitchSiteLEDs ein PROVISION anhängen?
Ähnlich wie
SetLocaleAP all ...
zB
enableWLAN löst automatisch ein PROVISION aus.
Gruß
Hallo,
mir ist aufgefallen, dass mein Unifi-Device in FHEM als Status nurmehr "disconnect" anzeigt.
mein define lautet
define UniFiReisStr Unifi pm-unifi.fritz.box 8443 crypt:XXX crypt:XXX
bei verbose5 erhalte ich folgende events:
UniFiReisStr (Unifi_Login_Send) - executed.
IP: pm-unifi.fritz.box -> 192.168.178.199
UniFiReisStr (Unifi_Login_Receive) - executed.
UniFiReisStr (Unifi_Login_Receive) - Failed with HTTP Code 500!
UniFiReisStr (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
Ich komme über https://pm-unifi.fritz.box:8443 auf meinen Unifi controller (Network 7.0.25)
Hallo zusammen,
ich bin gerade dabei mein Fhem neu auszusetzen und bin dabei auf folgendes Problen gestossen,
Den Unifi Controller kann ich problemlos einbinden und alle Readings werden korrekt übergeben.
Die angeschlossenen Switches werden angelegt jedoch kommen aus irgendwelchen Gründen keine Daten gleiches Problem auch auf meinem Bestandssystem.
Das hat aber vor 2-3 Monaten noch funktioniert da ich den POE Stromverbauch in Grafana per Dashboard visualisiert habe.
Meinen letzten Logeintrag von Switch hatte ich am 18.2.2022.
Was zum abbruch geführt hat kann ich nicht sagen da sich die Unifi Geäte automatisch updaten bzw ich habe auch dieses Jahr schon einen Update gemacht nur weis ich nicht mehr wann. :(
Controller hat die Version 7.0.25.
Switch hat die Version 6.2.11.13822.
Zitat
Switch24 ? ? ?
CODE Switch24
DEF Switch24
FUUID 6xxxxxxf-fxxf-fxx7-cff1-fxxxxxxxxxxxxxf7af
IODev my_unifi_controller
NAME Switch24
NR 81
STATE ? ? ?
TYPE UnifiSwitch
VERSION 1.0.01
Gruß
Thomas
Hi @ThomasS
folgenden Beitrag hast du gesehen?
https://forum.fhem.de/index.php/topic,40287.msg1202774.html#msg1202774
Gruß Hoppel
Hallo Hoppel118,
ich hatte zwar den Beitrag nicht gesehen jedoch wenn ich es richtig verstehe wurde der Switch nicht in Deinem Controller angezeigt jedoch ist dies bei mir nicht der Fall.
Zitat
-AP_AC_Pro_EG_clients 4 2022-05-01 00:03:11
-AP_AC_Pro_EG_essid XXXXX,XXXXX 2022-05-01 00:03:11
-AP_AC_Pro_EG_locate off 2022-05-01 00:03:11
-AP_AC_Pro_EG_state ok 2022-05-01 00:03:11
-AP_AC_Pro_EG_utilization 45,1 2022-05-01 00:03:11
-AP_AC_Pro_OG_clients 6 2022-05-01 00:03:11
-AP_AC_Pro_OG_essid XXXXX,XXXXX 2022-05-01 00:03:11
-AP_AC_Pro_OG_locate off 2022-05-01 00:03:11
-AP_AC_Pro_OG_state ok 2022-05-01 00:03:11
-AP_AC_Pro_OG_utilization 5,1 2022-05-01 00:03:11
-AP_Switch24_clients 9 2022-05-01 00:03:11
-AP_Switch24_locate off 2022-05-01 00:03:11
-AP_Switch24_state ok 2022-05-01 00:03:11
Der Switch und die AC Pro's werden korrekt angezeigt.
Wenn den Switch lösche und einen Restart mache wird deerm Switch wieder definiert.
Jedoch ist der state immer "? ? ?".
Wie ist der Switch bei Dir in der fhem.cfg definiert?
Zitatdefine Switch24 UnifiSwitch Switch24
Fehlt hier eventuell noch die IP und der Port wie beim Controller?
Ich habe auch versucht die Zeile im 74_Unifi Module auszukommentieren jedoch sehe ich keinen Unterschied.
Gruß und Danke schon mal
Thomas
Hallo,
ich muss mich nochmal melden, da FHEM immer noch einen "disconnect" zu meinem UnifiController anzeigt.
Woran kann dies liegen?
PS: controller version: atag_7.1.65_17871
Zitat von: speedAmaster am 20 Mai 2022, 18:33:18
Hallo,
ich muss mich nochmal melden, da FHEM immer noch einen "disconnect" zu meinem UnifiController anzeigt.
Woran kann dies liegen?
PS: controller version: atag_7.1.65_17871
Hast du ein list?
Zitat von: rapster am 23 August 2015, 20:48:21
Genau, in diesem Reading steht der Zeitpunkt des letzten Kontakt zum Controller, also plus/minus wenigen Sekunden die Zeit in der es tatsächlich offline ging.
Hier kannst du die Dateien aus dem SVN downloaden: https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/ (https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/)promocodius.de (https://promocodius.de/)
Falls deine HttpUtils.pm allerdings älter als 2 Tage ist (was ich denke wenn du länger kein Update gemacht hast) musst du dieses Modul auch zwingend aktualisieren damit Unifi funktioniert.
Danke für die Klarstellung
Bei mir funktioniert blockClient nicht - in der App von UniFi dagegen wird das Gerät sofort gesperrt. Geht das jemandem auch so? Es gab da eine Diskussion auf den Seiten 97, aber das hat mir nicht geholfen.
Zitat von: kl@us am 23 Januar 2022, 18:17:14
Hallo Marvin. Ich habe einen CloudKey-Gen2-Plus. Nach dem Patch werden die Switches wieder sauber erkannt und ich kann auch wieder die POE-Ports ein-/ausschalten. Vielen Dank für die schnelle Hilfe.
Gruß Klaus
Hallo Klaus,
ich bin auch auf einen CloudKey-Gen2 Plus und habe den Patch auch gemacht, jedoch lassen sich POE bei mir nicht mehr schalten. Hast du sonst noch was geändert ?
Gruss Peer
Hallo,
der Status ist aktuell uneinheitlich. Ich habe 2 USW-16 bei denen das Schalten der POE ohne Probleme funktioniert. An einem 3ten USW-16 geht es nicht?! Alle USW sind auf der aktuellen Firmware. Keine Ahnung warum es manchmal funktioniert und manchmal nicht.
Sorry.
Gruß
Klaus
Hallo zusammen,
laut UniFi lassen sich die LEDs eines AccessPoints nur noch einzeln ein/ausschalten.
SwitchSiteLEDs ist über die neue Controller UI nicht mehr verfügbar -
über die Legacy UI ist das Feature zwar noch vorhanden, aber laut UniFi wird es in absehbarer Zeit verschwinden.
Also wird die Steuerung der AP-LEDs kein Site-Setting mehr sein.
Das wirft die Frage nach dem Support / der Weiterentwicklung des 74_Unifi-Moduls auf.
Die Funktion RestartAP all ist ja bereits voll funktionsfähig implementiert.
Wie aufwendig wäre eurer Meinung nach die Implementierung einer SwitchAPLED all - Funktion?
Ich habe mir das Modul mal genauer angesehen, scheitere aber an meinen Programmierkenntnissen.
Welche Ideen habt ihr dazu?
Liebe Grüße
Ich habe eine Lösung für mich finden können.
Da diese aber nichts mit dem UniFi-Modul zu tun hat, habe ich einen neuen Beitrag erstellt:
https://forum.fhem.de/index.php?topic=128995.msg1233508#msg1233508
Ich habe ein Problem mit dem unblock/block Client, kann mir da jemand helfen:
2022.09.11 19:11:05 5: Unifi (Unifi_Notify) - executed.
2022.09.11 19:11:05 5: Unifi: get called with ?.
2022.09.11 19:11:11 5: Unifi: set called with unblockClient iPadAirneration
2022.09.11 19:11:11 4: Unifi: set unblockClient
2022.09.11 19:11:11 5: Unifi (Unifi_UnblockClient_Send) - executed with mac: '7c:ab:XX:XX:XX:XX'
2022.09.11 19:11:11 5: Unifi: get called with ?.
2022.09.11 19:11:12 5: Unifi (Unifi_UnblockClient_Receive) - executed.
2022.09.11 19:11:12 5: Unifi (Unifi_UnblockClient_Receive) - Failed! - state:'403' - msg:'Failed with HTTP Code 403.'
Ich habe das Gerät außerhalb von FHEM geblockt, das ging einfach. Via App. Leider eben nicht via FHEM.
PS
defmod Unifi Unifi cloudkey.fritz.box 443 crypt:01234567890 crypt:ABCDEFGHIJKLMANOPQRST 300
attr Unifi isUDM 1
iPadAirneration disconnected 2022-09-11 19:10:36
iPadAirneration_accesspoint unknown 2022-09-11 19:10:36
iPadAirneration_essid WLAN-XXXXX 2022-09-11 19:10:36
iPadAirneration_hostname iPadAirneration 2022-09-11 19:10:36
iPadAirneration_last_seen 2022-09-11 18:59:31 2022-09-11 19:10:36
iPadAirneration_snr 31 2022-09-11 19:10:36
iPadAirneration_uptime 6643 2022-09-11 19:10:36
Also das soll einer verstehen. CloudKey neu gestartet, dann mehrere Stunden keinen Zugriff auf einen real existierenden Nutzer, alles erneut neu gestartet, isUDM mal rausgeworfen und wieder eingesetzt und auf einmal geht es. Der Bösewicht ist nicht wuehler, das ist Unifi 8)
Ich werde noch verrückt. Also das Modul liefert mir Daten, alle fünf Minuten:
Internals:
DEF cloudkey.fritz.box 443 crypt:jajajaja crypt:wasauchimmer 300
FVERSION 74_Unifi.pm:0.235000/2021-01-09
LASTInputDev Unifi
MSGCNT 73463
NAME Unifi
NOTIFYDEV global
NR 464
NTFY_ORDER 50-Unifi
STATE connected
TYPE Unifi
UC_VERSION 7.2.92
Unifi_MSGCNT 73463
Unifi_TIME 2022-09-12 07:27:12
VERSION 3.5.2
eventCount 74921
Helper:
DBLOG:...
Attributes:
isUDM 1
ich kann auch die geblockten Clients korrekt erfassen. Wenn ich sie aber entblocken will, geht das nicht:
2022.09.12 06:24:30 5: Unifi (Unifi_Notify) - executed.
2022.09.12 06:24:30 5: Unifi: get called with ?.
2022.09.12 06:24:38 5: Unifi: set called with unblockClient iPadAirneration
2022.09.12 06:24:38 4: Unifi: set unblockClient
2022.09.12 06:24:38 5: Unifi (Unifi_UnblockClient_Send) - executed with mac: '50:XX:XX:XX:XX:XX'
2022.09.12 06:24:38 5: Unifi: get called with ?.
2022.09.12 06:24:38 5: Unifi (Unifi_UnblockClient_Receive) - executed.
2022.09.12 06:24:38 5: Unifi (Unifi_UnblockClient_Receive) - Failed! - state:'403' - msg:'Failed with HTTP Code 403.'
Nun ist der Code im Modul glücklicherweise sehr gut lesbar, also es sind diese Zeilen
###############################################################################
sub Unifi_UnblockClient_Send($$) {
my ($hash,$mac) = @_;
my ($name,$self) = ($hash->{NAME},Unifi_Whoami());
Log3 $name, 5, "$name ($self) - executed with mac: '".$mac."'";
HttpUtils_NonblockingGet( {
%{$hash->{httpParams}},
url => $hash->{unifi}->{url}."cmd/stamgr",
callback => \&Unifi_UnblockClient_Receive,
data => "{\"cmd\":\"unblock-sta\", \"mac\":\"".$mac."\"}",
} );
return undef;
}
Da kann nicht so viel schief laufen. Es muss daran liegen, dass mit dem Aufruf des Http kein Login erfolgt, was aber merkwürdig ist, weil bei der Abfrage der geblockten Clients erfolgt nichts anderes? Hat jemand einen Tipp?
Ich habe mal ein wenig weiter gesucht. Also, ich habe einmal eine Fehlermeldung und einmal keine, zum Beispiel
Unifi (Unifi_GetClientInsights_Send) - executed.
Unifi (Unifi_GetClientInsights_Receive) - executed.
Unifi (Unifi_GetClientInsights_Receive) - state:'ok'
******************************************
Unifi (Unifi_GetAccesspoints_Send) - executed.
Unifi (Unifi_GetAccesspoints_Receive) - executed.
Unifi (Unifi_GetAccesspoints_Receive) - Failed! - state:'Error while requesting' - msg:'https://cloudkey.fritz.box/proxy/network/api/s/default/stat/device - read from https://cloudkey.fritz.box:443 timed out'
Dann bietet es sich ja an, beide Male den Code anzuschauen und Differenzen zu suchen. Pustekuchen:
sub Unifi_GetClientInsights_Send($) {
my ($hash) = @_;
my ($name,$self) = ($hash->{NAME},Unifi_Whoami());
Log3 $name, 5, "$name ($self) - executed.";
HttpUtils_NonblockingGet( {
%{$hash->{httpParams}},
url => $hash->{unifi}->{url}."stat/alluser?within=".(365*24),
callback => \&Unifi_GetClientInsights_Receive,
method => "GET",
} );
return undef;
}
******************************************
sub Unifi_GetAccesspoints_Send($) {
my ($hash) = @_;
my ($name,$self) = ($hash->{NAME},Unifi_Whoami());
Log3 $name, 5, "$name ($self) - executed.";
HttpUtils_NonblockingGet( {
%{$hash->{httpParams}},
url => $hash->{unifi}->{url}."stat/device",
callback => $hash->{updateDispatch}->{$self}[2],
method => "GET",
data => "{\"_depth\":2, \"test\":0}",
} );
return undef;
}
Da sind keine Unterschiede, bis eben auf die jeweilige URL (callback wird es nicht sein, das bemerkt dann nur den Fehler - aber ich muss dazu sagen, ich bin Perl-Laie). Meine Vermutung: Die URL hat sich geändert und das wird in der API eventuell nicht ordentlich kommentiert. Also muss ich da mal weiterschauen.
Hallo zusammen,
wegen regelmäßiger Fhem-Crashes habe ich begonnen, mit DOIFtools Events auszuwerten, da der Verdacht besteht, dass zuviele Events dafür verantwortlich sind.
Ich habe deshalb bei dem Unifi-Device das Attribut event-on-change-reading .* gesetzt, um die Anzahl der Events zu reduzieren. Leider bekomme ich immer noch über 4000 Events pro Stunde.
Da ich über die eingeloggten Handys diverse Schaltungen beeinflusse, benötige ich zumindest von diesen sehr regelmäßige Updates.
Meine Definition lautet (anonymisiert):
defmod myUniFi Unifi 192.168.xx.yy 8443 crypt:****** crypt:******* 60
attr myUniFi customClientReadings .:^last_seen$|^_f_last_seen$|^ip$|^name$|^mac$
attr myUniFi event-min-interval Handy1:60,Handy2:60,Handy3:60
attr myUniFi event-on-change-reading .*
attr myUniFi eventMap connected:1 disconnected:0
Wie und wo kann ich ansetzen, um die Anzahl der Events zu reduzieren?
Viele Grüße Gisbert
Nur die Events von Handy(123) erstmal zulassen (mit event-on-change-reading) und die dann auch noch beschränken mit timestamp-on-change-reading, alles weitere, falls erforderlich ergänzen, ist/wäre mein Ansatz ?
Hallo TomLee,
ich habe das event-on-change-reading gesetzt - damit geht die Anzahl der Events von 4000 auf ca. 10-20 pro Stunde zurück. Zusätzlich habe ich event-min-interval auf 900 (Sekunden) gesetzt, um Abrisse in Diagrammen zu vermeiden.
Für timestamp-on-change-reading sehe ich keine Notwendigkeit, habe aber auch nicht verstanden, wie dieses Attribut die Anzahl der Events beeinflusst.
Viele Grüße Gisbert
ZitatFür timestamp-on-change-reading sehe ich keine Notwendigkeit, habe aber auch nicht verstanden, wie dieses Attribut die Anzahl der Events beeinflusst.
Ganz einfach, mit nur event-on-change-reading gibts auch immer einen neuen timestamp, ergänzt man time-stamp-on-change-reading ändert sich der timestamp nur bei Änderung, du siehst dann praktisch an der Zeit wann die letzte Änderung war.Ich muss mich offensichtlich auch wieder mal genauer mit beschäftigen, um es korrekt erklären zu können 8)
Ok, das Attribut beinflusst keine Events, das war von mir falsch dargestellt, es verhindert das der Zeitstempel eines Readings, bei einem mit event-on-change-Reading eingeschränkten Event, nicht mehr aktualisiert wird.
Mit dem gesetzten Attribut wird dann praktisch festgehalten wann du das letzte mal an dem AP angemeldet warst.
Zitat von: andies am 13 September 2022, 20:00:55
Da sind keine Unterschiede, bis eben auf die jeweilige URL
Falsch: Einmal werden nur Daten gelesen, einmal werden sie geschrieben. Das war vor zwei Jahren schon mal Thema. Nur passt die damalige Lösung nicht, denn ich habe definitiv Schreibzugriff.
Noch etwas ist mir aufgefallen. Es gibt ja zwei mögliche Zugänge zum Netzwerk, einmal über die Cloud (Unifi.ui.com) und einmal lokal (bei mir 192.168.2.usw). In den GitHub-Lösungen, die das letzte Mal vor zwei Jahren aktualisiert wurden, ist davon die Rede, dass man den lokalen Zugang nehmen und eine so genannte Site-id herauslesen solle. Mein lokaler Zugang hat keine Site-it, aber der Cloud-basierte hat eine. Vielleicht können wir über die Cloud blockieren?
Die Doku von Unifi ist echt nervig. Die geben sich einfach keine Mühe.
Wenn keine Site-ID in der URL steht, ist es "default".
Hallo zusammen,
bis vor ein paar Wochen hatte ich ein USG mit Switchen und AP´s am laufen. Das Modul hat die Switche automatisch angelegt. Dann habe ich auf eine UDM umgestellt, in Fhem hatte ich dabei noch keine
Änderung vorgenommen und den wechsel auf die UDM wurde natürlich auch nicht erkannt.
Nun habe ich die alten Devices gelöscht un die UDM neu angelegt. Auch das attribut isUDM=1 ist gesetzt. Die Readings purzeln dann nach einer Weile auch rein.
Die Switche werden allerdings nicht per Autocreate angelegt. Wenn ich diese dann manuell anlege kommen keine readings rein.
Habe uch da was übersehen oder falsch verstanden ?
define UnifiController Unifi 192.xxx.x.1 443 crypt:xxx crypt:xxx 60 default
attr UnifiController DbLogExclude .*
attr UnifiController isUDM 1
attr UnifiController room UnifiSwitch
attr UnifiController verbose 2
Danke, Jens
Zitat von: Jewe am 28 September 2022, 18:48:39
Die Switche werden allerdings nicht per Autocreate angelegt. Wenn ich diese dann manuell anlege kommen keine readings rein.
Habe uch da was übersehen oder falsch verstanden ?
Einfach mal die letzten 2 Seiten dieses Threads lesen hilft in diesem Fall zumindest...
Das war bei mir die Lösung:
https://forum.fhem.de/index.php/topic,40287.msg1202774.html#msg1202774
Gruß Hoppel
Hallo Hoppel,
ja da habe ich wohl zuwenig gelesen...
Danke jetzt klappts wieder.
Jens
Hallo zusammen,
mit dem Dream Router ist das Modul aber nicht kompatibel, oder? Bei mir steht das Modul immer auf disconnected und im Log findet sich Error 404, vermute bei dem Modell sind die Pfade ggf. anders?
VG freddeh
Auf dem Dream Router läuft das neue OS 2.x, welches auch auf der UDM-SE läuft. Das Modul läuft bei mir mit der UDM-SE.
Es sollte also auch bei dir laufen, zumindest gehe ich davon aus. Aber sicher sagen kann ich es dir auch nicht. ;)
Gruß Hoppel
Hallo in die Runde. Ich hab das Modul 74_Unifi seit einiger Zeit laufen. Ich weis nicht ob das schon immer so war, aber ich habe im Fhem unter meinem Unifi-Controller hunderte Devices die ich nicht kenne. Wenn ich diese mit einem deletereading + Wildcard lösche, sind sie kurz darauf wieder da. Ich hatte vor einiger Zeit schon mal nach einer Lösung gesucht, aber auch da nichts gefunden. Die Modulversion ist aktuell und auf den Unifi Geräten ist auch alles aktuell. Hat noch jemand das Problem und/oder kann mir sagen was ich dagegen tun kann?
Falls das wichtig ist:
-UnifiController läuft auf einer Diskstation (gerade frisch geupdatet)
-UniFi Hardware
--2x UAP-AC-LR
--1x UAP-AC-Lite
--1x USG-3P
--1x US-24-G1
--3x USW-Flex-Mini
mfg
Marcel
Hallo Marcel,
ich hab das ähnlich - und mich daran gewöhnt, dass es so ist.
Abhilfe bringt etwas, dass weniger subskribiert wird, und die Intervallrate nicht zu klein gewählt wird.
Viele Grüße Gisbert
Die Lösung steht eine Seite vorher:
https://forum.fhem.de/index.php/topic,40287.msg1202835.html#msg1202835
Namen dürfen in der Unifi Network App keine Leerzeichen enthalten. Also:
- In der Network App bei allen Geräte-Namen mit Leerzeichen bspw. einen Bindestrich setzen oder auf Leerzeichen verzichten. Am besten jedem Gerät einen Namen geben, da Geräte ohne Hostnamen auch so einen sonderbaren Namen erhalten
- Dann am Unifi Device den Befehl ,,set <UnifiNetwork> clear all" ausführen, kurz den Intervall abwarten und alles ist schick
Zumindest hat das bei mir so funktioniert.
Gruß Hoppel
Zitat von: hoppel118 am 11 Oktober 2022, 20:14:40
Die Lösung steht eine Seite vorher:
https://forum.fhem.de/index.php/topic,40287.msg1202835.html#msg1202835
Namen dürfen in der Unifi Network App keine Leerzeichen enthalten. Also:
- In der Network App bei allen Geräte-Namen mit Leerzeichen bspw. einen Bindestrich setzen oder auf Leerzeichen verzichten. Am besten jedem Gerät einen Namen geben, da Geräte ohne Hostnamen auch so einen sonderbaren Namen erhalten
- Dann am Unifi Device den Befehl ,,set <UnifiNetwork> clear all" ausführen, kurz den Intervall abwarten und alles ist schick
Zumindest hat das bei mir so funktioniert.
Gruß Hoppel
Vielen Dank Hoppel, das wars wirklich.. manchmal kann es so einfach sein.
Noch ein Hinweis für alle, die das gleiche Problem haben. Bei mir waren es nicht nur die Namen der "Endgeräte" sondern auch die Namen der Switche und APs.
mfg
Marcel
Super! Switche und APs hatten bei mir schon immer Namen mit Namenskonvention ohne Leerzeichen. Deswegen hatte ich das Problem wohl nicht.
Keine Ahnung, welche Art der Dokumentation im Wiki bei einem verwaisten Modul noch sinnvoll ist.
Gruß Hoppel
Hallo zusammen,
ich hab heute etwas Merkwürdiges beim Unifi-Modul bemerkt. Ich habe absichtlich den unifi.service gestoppt, um zu sehen, wie sich im Unifi-Device in Fhem das Reading state ändert. Es ändert sich nichts. Aber das war nicht alles. Die Readings, die ich mir angeschaut hatte, wurden weiter upgedated, d.h. erhalten einen neuen Timestamp mit unverändertem Reading, als wenn der unifi.service weiterlaufen würde.
Wie kann das sein? Hat jemand etwas ähnliches beobachtet oder kann das für mich befremdliche Verhalten erklären?
Viele Grüße Gisbert
Hallo zusammen,
in diesem Thread scheint wohl nichts mehr zu passieren.
Eine weitere beobachtete Merkwürdigkeit ist die folgende. Wenn ich im Controller für ein Wireless Network das WiFi Band z.B. von Both auf 2.4 GHz (oder umgekehrt) stelle, dann startet Fhem neu.
Warum ist das so?
Kann jemand das bei sich bitte nachstellen, um auszuschließen, dass es irgendeine Ursache gibt, die nur bei mir gilt?
Gibt es einen anderen Thread, bei dem häufiger neue Beiträge reinkommen?
Viele Grüße Gisbert
Hai,
auch wenn ich kaum Ahnung habe, versuche ich trotzdem mal zu helfen:
Zitat von: Gisbert am 27 Dezember 2022, 16:00:17
in diesem Thread scheint wohl nichts mehr zu passieren.
ich gehe davon aus, dass das am Modul Autor liegt, der länger nicht mehr da war..... scheint, als hätte bisher auch sonst niemand das Modul übernommen zu haben. Ob andere ein anderes Modul nutzen, kann ich nicht beantworten. Ich nutze das Unifi Moduk ausschließlich für die Anwesenheitserkennung der einzelnen Handys, somit fallen mir viele (nicht) Funktionen, wahrscheinlich gar nicht erst auf.
Zitat von: Gisbert am 27 Dezember 2022, 16:00:17
Wenn ich im Controller für ein Wireless Network das WiFi Band z.B. von Both auf 2.4 GHz (oder umgekehrt) stelle, dann startet Fhem neu.
Kann jemand das bei sich bitte nachstellen, um auszuschließen, dass es irgendeine Ursache gibt, die nur bei mir gilt?
Ich habe es nachgestellt und sowohl meine Live als auch meine TestFhem Umgebung ist nicht neu gestartet....
Warum das bei Dir so ist, kann ich Dir leider nicht beantworten (dafür reichen meine Kenntnisse dann doch nicht aus). Allerdings hätte ich die Vermutung: Ist Dein FHEM irgendwie direkt mit der Unifi Umgebung verbunden ? (Bsw per WLAN) Was ich mir vorstellen könnte, wo man zu suchen ansetzen könnte?
Fhem auf einem Raspi -> Raspi im Wlan -> Unifi Umstellung -> Raspi verliert WLAN -> (oder sonstige Verbindung) -> kein Standard Gateway eingerichtet -> irgendein Modul versucht zu verbinden und crasht FHEM -> Bis dahin ist Wlan wieder da und schwupp das Problem ist hinfällig.
Das wäre ein Folgefehler und hätte nichts mit dem Unifi Modul zu tun aber indirekt würde es durch die Umstellung im Unifi ausgelöst werden. Allerdings wird Dir sicher der Log etwas mehr verraten als die Glaskugel ::)
Vielleicht hilft es ja auf die richtige Fährte zu kommen.....
VG
Andreas
Hallo,
warum stehen in den Readings der bei "Accesspoint" überall "unknown"?
Ist das bei euch ebenso?
Gruß
ESP_C38D3D
connected
2023-02-22 17:32:26
ESP_C38D3D_accesspoint
[color=red]unknown[/color]
2023-02-22 17:32:26
ESP_C38D3D_essid
XXXXXX
2023-02-22 17:32:26
ESP_C38D3D_mac
10:52:1c:c3:8d:XX
2023-02-22 17:32:26
ESP_C38D3D_radio_proto
ng
2023-02-22 17:32:26
Zitat von: speedAmaster am 18 April 2022, 19:45:49
Hallo,
mir ist aufgefallen, dass mein Unifi-Device in FHEM als Status nurmehr "disconnect" anzeigt.
mein define lautet
define UniFiReisStr Unifi pm-unifi.fritz.box 8443 crypt:XXX crypt:XXX
bei verbose5 erhalte ich folgende events:
UniFiReisStr (Unifi_Login_Send) - executed.
IP: pm-unifi.fritz.box -> 192.168.178.199
UniFiReisStr (Unifi_Login_Receive) - executed.
UniFiReisStr (Unifi_Login_Receive) - Failed with HTTP Code 500!
UniFiReisStr (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
Ich komme über https://pm-unifi.fritz.box:8443 auf meinen Unifi controller (Network 7.0.25)
Bei mir nun leider das gleiche Problem, hattest du dafür eine Lösung finden können?
Hallo,
bei mir ist der Unifi einwandfrei connected aber ich erhalte keine Readings da ich bei der SiteID eine Bezeichnung mit Leerzeichen verwenden sollte.
Wie kann da das define lauten für eine SiteID mit der Bezeichnung "anfang ende"?
define U_test Unifi unifi.datenstrom.at 8443 crypt:xxx crypt:xxx 30 anfang ende
Danke für eine Idee
Ich würde es mal mit Anfang.ende probieren? 🤔
Vielleicht hilft es ja :)
Danke flummy1978 .
Leider hats nichts genutzt.
Im Logfile hab ich nach wie vor die Meldung
U_test (Unifi_GetSysinfo_Receive) - Failed! - state:'error' - msg:'api.err.NoSiteContext' - This error indicates that the <siteID> in your definition is wrong. Try to modify your definition with <sideID> = default.
Gibts noch weitere Ideen ?
Hallo,
probiere es doch mal mit Anfang%20ende
Alternativ vielleicht auch mit "Anfang ende"
Ronny
Eine andere Idee wäre, einen anderen Site Namen zu nehmen
Zitat von: flywhiskygolf am 10 März 2023, 20:53:03
da ich bei der SiteID eine Bezeichnung mit Leerzeichen verwenden sollte.
Warum SOLLTEST Du das Leerzeichen im Site Namen verwenden? Geht es nicht ohne?
VG
Andreas
Habe beide Varianten probiert - danke, aber leider erfolglos
Da ich nicht Admin der Unifi-Hardware bin, darf ich die Site leider nicht ändern.
Ich probier mal den Admin dazu zu bewegen ...
Hallo,
hat schon jemand eine Verbindung zu einem Dream Router hingekriegt?
Gruß
Eisix
Hallo,
gestern nochmal getestet.
UDR hat 3.0.17.
Kann somit bestätigen das es mit dieser OS Version und dem Dream Router funktioniert.
Gruß
Eisix
Zitat von: Eisix am 18 April 2023, 09:48:58Hallo,
gestern nochmal getestet.
UDR hat 3.0.17.
Kann somit bestätigen das es mit dieser OS Version und dem Dream Router funktioniert.
Gruß
Eisix
Mal ganz OT, wie zufrieden bist Du mit dem UDR ? Meiner steht kurz davor aus dem Fenster zu fliegen.. sowas von instabil.
Angeschlossen ist ein Unifi 24Port-Switch, daran ein UAP-LR. Quasi alles auf Default. Insges. ca. 50Clients.
UDR stürzt mind 1xpro Woche ab, wenn ich an den internen Switch meinen DNS-Server (Adguard) hänge, kackt der UDR fast täglich ab. Und nach kurzer Zeit sind keine WLAN-Clients per WLAN erreichbar, obwohl UniOS "Alles super" meldet. Dann hilft nur noch steckerziehen.
Gerne können wir das auch in einem separaten Thread weiterführen....
Hallo Bartimaus,
Ja ist OT. Nur soviel, ist der dritte UDR mit dem ich zu tun habe. 1 läuft seit ca. 9 Monaten durch. Nur bei Updates neu gestartet. Ungefähr 20 Clients. Ein anderer seit ca 2. Monaten ohne Probleme aber da sind nur 2-3 Clients drauf. Den dritten habe ich erst 1 Woche in Betrieb auch ca. 50 Clients bis jetzt ohne Probleme.
Entweder hast du ein Montagsgerät oder irgendwas an deiner Umgebung passt nicht.
Details vielleicht über direkte Mail.
Gruß
Eisix
Moin zusammen
Dank Corona habe ich etwas Zeit, und habe mal eine neue fhem-Instanz aufgesetzt.
Damit wollte ich nun meine Unifi Umgebung integrieren.
Leider kommt ums Verrecken immer nur ein "disconnected".
define myunifi Unifi 192.168.178.124 443 crypt:475709565503 crypt:73514b0f0b50440101003c40010b4213504258
attr myunifi httpLoglevel 5
attr myunifi isUDM 1
attr myunifi room Network
attr myunifi verbose 5
# CFGFN
# DEF 192.168.178.124 443 crypt:475709565503 crypt:73514b0f0b50440101003c40010b4213504258
# FUUID 644521c8-f33f-d847-8308-0f8621cebe47c05e
# NAME myunifi
# NOTIFYDEV global
# NR 51
# NTFY_ORDER 50-myunifi
# STATE disconnected
# TYPE Unifi
# UC_VERSION unknown
# VERSION 3.5.2
# eventCount 2
# READINGS:
# 2023-04-23 14:17:12 state disconnected
# accespoints:
# alerts_unarchived:
# clients:
# events:
# helper:
# password crypt:73514b0f0b50440101003c40010b4213504258
# username crypt:475709565503
# hotspot:
# vouchers:
# httpParams:
# header
# ignoreredirects 1
# loglevel 5
# method POST
# noshutdown 0
# timeout 5
# hash:
# sslargs:
# SSL_verify_mode 0
# unifi:
# CONNECTED disconnected
# eventPeriod 24
# interval 30
# ucurl https://192.168.178.124/api/s/default/
# udmurl https://192.168.178.124/proxy/network/api/s/default/
# url https://192.168.178.124/proxy/network/api/s/default/
# customClientReadings:
# attr_value .:^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime
# parts:
# 0000000_part:
# ReadingRegEx ^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime
# nameRegEx .
# isUDM:
# attr_value 1
# updateDispatch:
# wlans:
#
setstate myunifi disconnected
setstate myunifi 2023-04-23 14:17:12 state disconnected
Ich habe die "letzte" Version von Christian genommen, und auch die Aenderung in Zeile 1450 gemacht!
UniFi OS UCK G2 Plus 3.1.6
Network 7.4.150
2023.04.23 14:12:58 0: Server started with 7 defined entities (fhem.pl:27410/2023-04-07 perl:5.032001 os:linux user:fhem pid:520)
2023.04.23 14:12:59 5: myunifi (Unifi_Login_Receive) - executed.
2023.04.23 14:12:59 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/74_Unifi.pm line 949.
2023.04.23 14:12:59 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/74_Unifi.pm line 988.
2023.04.23 14:12:59 5: myunifi (Unifi_Login_Receive) - Login Failed (without msg)! - state:''
2023.04.23 14:12:59 5: myunifi (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2023.04.23 14:13:23 5: myunifi: get called with ?.
2023.04.23 14:13:27 5: myunifi: Defined with url:https://192.168.178.124/proxy/network/api/s/default/, interval:30
2023.04.23 14:13:27 5: myunifi (Unifi_Notify) - executed.
2023.04.23 14:13:27 5: myunifi (Unifi_Notify) - checking 1 state
2023.04.23 14:13:27 5: myunifi (Unifi_Notify) - executed. - Remove all Timers & Call DoUpdate...
2023.04.23 14:13:27 5: myunifi (Unifi_DoUpdate) - executed.
2023.04.23 14:13:27 5: myunifi (Unifi_Login_Send) - executed.
2023.04.23 14:13:27 5: myunifi (Unifi_initCustomClientReadings) - parsed part: . -> ^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime
2023.04.23 14:13:27 5: myunifi (Unifi_initCustomClientReadings) - parsed Attribute customClientReadings: {"attr_value":".:^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime","parts":{"0000000_part":{"nameRegEx":".","ReadingRegEx":"^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime"}}}.
2023.04.23 14:13:28 5: myunifi (Unifi_Login_Receive) - executed.
2023.04.23 14:13:28 5: myunifi (Unifi_Login_Receive) - Login Failed (without msg)! - state:''
2023.04.23 14:13:28 5: myunifi (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2023.04.23 14:13:58 5: myunifi (Unifi_Login_Send) - executed.
2023.04.23 14:13:59 5: myunifi (Unifi_Login_Receive) - executed.
2023.04.23 14:13:59 5: myunifi (Unifi_Login_Receive) - Login Failed (without msg)! - state:''
2023.04.23 14:13:59 5: myunifi (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
20
Any thoughts?
Gruss Christoph
Ich habe seit einiger Zeit - ich vermute seit dem Update auf UnifiOS 3.x das Problem, dass ich keine Steuerungsmöglichkeiten über das Modul mehr habe. Bsw. kann ich mein G-Wlan nicht mehr aktivieren oder deaktivieren. Readings kommen im Modul nach wie vor problemlos an. Ich habe meinem Unift-Account für das Modul volle Rechte (Full Management) verpasst.
Im Log bekomme ich folgendes.
Unifi (Unifi_WlanconfRest_Receive) - Failed! - state:'403' - msg:'Failed with HTTP Code 403.'
EDIT: Ach so, das Ganze läuft bei mir auf einer UDM Pro.
EDITEDIT: Mit dem Patch aus Beitrag #1520 scheint es wieder zu funktionieren. Dankeschön!
LG Oli
Hallo zusammen,
der Unifi Controller "müllt" mir meine Datenbank (DBLog - MariaDB) zu.
Nun wollte ich über DBLogExclude das Logging für diese Device mal ausschalten - ohne Erfolg!
Er schreibt weiter Alles ins Log...
Friedrich
Internals:
DEF 192.168.0.78 8443 crypt:xxx crypt:yyy
FUUID 5ebf0f82-f33f-04e6-84f6-ea4d4a09f269232e
LASTInputDev Unifi
MSGCNT 731840
NAME Unifi
NOTIFYDEV global
NR 138
NTFY_ORDER 50-Unifi
STATE connected
TYPE Unifi
UC_VERSION 7.4.156
Unifi_MSGCNT 731840
Unifi_TIME 2023-08-06 18:01:48
VERSION 3.5.2
eventCount 264372
...
Attributes:
DbLogExclude .*
DbLogInclude state
alias Unifi
devStateIcon connected:hm_lan@#0064ff .*:hm_lan@red .*:hm_lan
event-on-change-reading .*
group Geräte
icon it_wifi
room 1.Übersicht,Server
Zitat von: putzvarruckt am 06 August 2023, 18:06:21Hallo zusammen,
der Unifi Controller "müllt" mir meine Datenbank (DBLog - MariaDB) zu.
Nun wollte ich über DBLogExclude das Logging für diese Device mal ausschalten - ohne Erfolg!
Er schreibt weiter Alles ins Log...
Friedrich
Hab es selber gefunden. Es lag an einem FHEM2FHEM der zugeschlagen hat und die Events in die DB bugsiert hat...
Danke trotzdem falls sich jemand schon Gedanken gemacht hat.
Hallo,
ich bekomme bei meiner UDM nur Clients ausgelesen, weder AP noch Switches erscheinen in den Readings ?!
Diese Readings bekomme ich wenn Wired & wireless clients auf ignore sind:
-UC_blockedClients
2023-08-09 10:20:20
-UC_events
0 (last 24h)
2023-08-09 10:20:20
-UC_newClients
2023-08-09 10:20:20
-UC_speed_down
161.299
2023-08-09 10:20:20
-UC_speed_ping
10
2023-08-09 10:20:20
-UC_speed_up
58.255
2023-08-09 10:20:20
-UC_unarchived_alerts
0
2023-08-09 10:20:20
-UC_wan_ip
192.168.1.10
2023-08-09 10:20:20
-UC_wlan_accesspoints
39
2023-08-09 10:20:20
-UC_wlan_guests
313
2023-08-09 10:21:08
-UC_wlan_state
warning
2023-08-09 10:20:20
-UC_wlan_users
33
2023-08-09 10:21:08
-WLAN_ICF-IoT_state
enabled
2023-08-09 10:20:20
-WLAN_Starlink_state
enabled
2023-08-09 10:20:20
-WLAN_intern_inselcamp_state
enabled
2023-08-09 10:20:20
-WLAN_personal_inselcamp_state
enabled
2023-08-09 10:20:20
-WLAN_welcome_inselcamp_state
enabled
2023-08-09 10:20:20
state
connected
2023-08-09 10:19:31
Zitat von: Freibeuter am 09 August 2023, 10:24:18Hallo,
ich bekomme bei meiner UDM nur Clients ausgelesen, weder AP noch Switches erscheinen in den Readings ?!
Diese Readings bekomme ich wenn Wired & wireless clients auf ignore sind:
-UC_blockedClients
2023-08-09 10:20:20
-UC_events
0 (last 24h)
2023-08-09 10:20:20
-UC_newClients
2023-08-09 10:20:20
-UC_speed_down
161.299
2023-08-09 10:20:20
-UC_speed_ping
10
2023-08-09 10:20:20
-UC_speed_up
58.255
2023-08-09 10:20:20
-UC_unarchived_alerts
0
2023-08-09 10:20:20
-UC_wan_ip
192.168.1.10
2023-08-09 10:20:20
-UC_wlan_accesspoints
39
2023-08-09 10:20:20
-UC_wlan_guests
313
2023-08-09 10:21:08
-UC_wlan_state
warning
2023-08-09 10:20:20
-UC_wlan_users
33
2023-08-09 10:21:08
-WLAN_ICF-IoT_state
enabled
2023-08-09 10:20:20
-WLAN_Starlink_state
enabled
2023-08-09 10:20:20
-WLAN_intern_inselcamp_state
enabled
2023-08-09 10:20:20
-WLAN_personal_inselcamp_state
enabled
2023-08-09 10:20:20
-WLAN_welcome_inselcamp_state
enabled
2023-08-09 10:20:20
state
connected
2023-08-09 10:19:31
Schau dir das an:
https://forum.fhem.de/index.php?topic=40287.msg1237096#msg1237096
und das folgende solltest du dir auch anschauen, auch wenn das mit deinem Problem nichts zu tun hat:
https://forum.fhem.de/index.php?topic=40287.msg1239079#msg1239079
Gruß Hoppel
Vielen Dank !
Hey zusammen,
ich habe eine UDM SE. Das ganze mit der Zeile 1450 habe ich auch gemacht. ABER bis zum 16.05.23 lief alles noch bei mir in FHEM. Aktuell bekomme ich aber nur noch "disconnected".
Gibt es hier ggf. Neuigkeiten die helfen könnten?
2023.08.28 12:29:49 2: HttpUtils url=https://192.xxx.xxx.1/api/auth/login NonBlocking via https
2023.08.28 12:29:49 1: IP: 192.xxx.xxx.1 -> 192.xxx.xxx.1
2023.08.28 12:29:49 2: HttpUtils request header:
POST /api/auth/login HTTP/1.0
Host: 192.xxx.xxx.1
User-Agent: fhem
Accept-Encoding: gzip,deflate
Content-Type: application/json
Content-Length: 81
2023.08.28 12:29:50 1: https://192.xxx.xxx.1/api/auth/login: HTTP response code 200
2023.08.28 12:29:50 2: HttpUtils https://192.xxx.xxx.1/api/auth/login: Got data, length: 8222
2023.08.28 12:29:50 2: HttpUtils response header:
HTTP/1.1 200 OK
Vary: Origin
X-DNS-Prefetch-Control: off
Expect-CT: max-age=0
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=15552000; includeSubDomains
X-Download-Options: noopen
X-Content-Type-Options: nosniff
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: no-referrer
X-XSS-Protection: 0
Accept-Ranges: bytes
Content-Type: application/json; charset=utf-8
X-CSRF-Token: 635f32f1-db63-4e60-8ffc-49347b32419c
X-Response-Time: 1183ms
Set-Cookie: TOKEN=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpdfgdgdgdgdnRydWUsInVzZXJJZCI6ImE5Nzc5MzAzLWRiODMtNDk3Ny05NjFlLTA4MGFjMzQyODY5OSIsImNzcmZUb2tlbiI6IjYyNWQwMmYxLWRiNjMtNGQ2MC04ZmZjLTQ5MzQ3YTMyNDE5YyIsImlhdCI6MTY5MzIxODU5MCwiZXhwIjoxNjk1ODEwNTkwLCJqdGkiOiI5ZTRkZDRiOC04MWIxLTQzY2QtOTNhOC00Y2UwN2QwMDMxY2IifQ.gdzm38MK9ucYS-gNrTskoZKFnhONCl9k32-7MkqQf0U; path=/; samesite=none; secure; httponly
Content-Length: 8222
Date: Mon, 28 Aug 2023 10:29:50 GMT
Connection: close
Gibt es denn mittlerweile eine Lösung für das Problem, dass bei enableWlan/disableWlan von zum Beispiel dem Gäste WLAN, nicht auch immer das Haupt WLAN disabled wird und alle Geräte kurzzeitig die Verbindung verlieren?
Danke und Gruß
sTaN
Ist das nicht ein Problem von Unifi? Das passiert hier auch, wenn ich das direkt im Controller mache anstatt über fhem...
Ja stimmt, ich erinnere mich wieder. Ich hatte die Vermutung, dass man über die Unifi API, die ja für das FHEM Modul genutzt wird hierauf ggf. Einfluss nehmen kann, wie sich das im Unifi Controller/AP verhält.
Kann das jemand bestätigen, dass dieser Bug seitens Unifi noch besteht oder wurde ggf. das Modul noch nicht auf eventuell neue API Funktionen angepasst oder gibt es hier gar keine andere Möglichkeit dies zu verhindern?
In jedem Fall verstehe ich das Verhalten offen gesprochen nicht wirklich und falls es bei Unifi noch besteht, warum man dies noch nicht behoben hat.
Gruß
sTaN
Es ist nicht wirklich ein Bug. Es ist bloß so, dass in solchen Fällen neu provisioniert wird und so lange steht der AP für nichts zur Verfügung. Ich nehme an, das ist technisch bedingt.
Kann mir einer helfen was den Post #1649 angeht?
Irgendwie habt ihr das ja auch zum laufen gebracht..
Gruß,
87Insane
Hallo zusammen,
seit einiger Zeit funktioniert set UnifiController enableWLAN XXX / set UnifiController disableWLAN XXX nicht mehr. Liegt das an mir oder ist da irgendwo ein Bug?
Hallo zusammen,
der UniFi-Controller, MongoDB und Debian verstehen sich nicht so recht. Nach dem Update auf Debian 12 Bookworm gab es immer wieder mit der MongoDB-Version 3.6 Warnungen oder Fehlermeldungen beim Update des Linuxsystems.
Durch Googeln bin ich auf die folgenden Seiten gestoßen, bei denen u.a. durch ein Installationsscript ein Update auf MongoDB 4.4 vorgenommen wird.
https://forum.netcup.de/sonstiges/werbung-f%C3%BCr-die-eigene-webseite/17262-unifi-controller-auf-debian-bookworm/?pageNo=2 (https://forum.netcup.de/sonstiges/werbung-f%C3%BCr-die-eigene-webseite/17262-unifi-controller-auf-debian-bookworm/?pageNo=2)
https://community.ui.com/questions/UniFi-Installation-Scripts-or-UniFi-Easy-Update-Script-or-UniFi-Lets-Encrypt-or-UniFi-Easy-Encrypt-/ccbc7530-dd61-40a7-82ec-22b17f027776 (https://community.ui.com/questions/UniFi-Installation-Scripts-or-UniFi-Easy-Update-Script-or-UniFi-Lets-Encrypt-or-UniFi-Easy-Encrypt-/ccbc7530-dd61-40a7-82ec-22b17f027776)
Es lief alles wie am Schnürchen und ich bin die nervigen Meldungen im Zusammenhang mit MongDB los.
Viele Grüße Gisbert
Zitat von: ranon am 17 November 2023, 08:07:07Hallo zusammen,
seit einiger Zeit funktioniert set UnifiController enableWLAN XXX / set UnifiController disableWLAN XXX nicht mehr. Liegt das an mir oder ist da irgendwo ein Bug?
Das ist bei mir nun leider auch so. Controller-Version 8.0.24 - so weit ich mich erinnere ging es mit den 7er Versionen noch.
Ich habe noch einen 7.5er Controller, damit geht es hier (noch).
Mit der beigefügten von mir gepatchten Version sollte das Modul so weit wieder insbesondere für das Ein- und Ausschalten von WLANs und anderen Dingen funktionieren.
Die ursprüngliche Version konnte nicht mit CSRF-Tokens umgehen, nach dem Patch aus #1520 (https://forum.fhem.de/index.php?msg=1169883) wurde das grundsätzlich behoben, seit der Unifi Networkcontroller App ab Version 8.x funktionierte das aber offensichtlich nun nicht mehr.
Dementsprechend habe ich eine der enthaltenen Subroutinen abgeändert, sodass der übernommene CSRF-Token nun anders ausgewertet und zwischengespeichert wird.
Hey zusammen,
hat von Euch ggf. auch einer das Phänomen, dass Clints (WLAN) disconneten und direkt wieder connecten?
Ich nehme mal mein Handy als Beispiel.
Das Teil liegt vor mir, Display an und es ist durchgehenden verbunden. Allerdings meldet FHEM mir als EVENT bei jeder Abfrage gegen das Modul ein disconnected und direkt wieder connected. Ich habe nun alles mögliche probiert aber finde nicht den Aufhänger. Innerhalb der App/des WEB-IF meiner UDM SE (UNIFI Controler) sehe ich das nicht so.
Meine Hardware: UDM SE, 1 USW-PRO-24-POE, 3 U6 PRO.
Hallo
ich versuche das Gäste-WLAN über das cmd des deviceStateIcon ein- und auszuschalten.
Der Eintrag für das Ausschalten sieht so aus:
enabled:WLAN_on_gWLAN_on:disableWLAN
Da öffnet sich ein Fenster und ich könnte die SSID auswählen. Weiß jemand, wie man dort eine SSID bereits mit übergeben kann?
Lösung:
Ich habe gerade cmdalias gefunden und das damit lösen können.
Moin zusammen,
ich habe vor zwei Tagen das Unifi Modul + Switch installiert und schaffe es einfach nicht Port 8 (oder irgendeinen anderen) mit "set Switch_48_PoE disablePort 8" ausschalten. Da hängt ein U6-Mesh dran, dessen Port ich komplett ausschalten will, sobald das Gerät nicht mehr "online" ist. Hintergrund ist das leicht zugängliche Lan-Kabel (bitte keine Belehrungen über mehr Kameras, höhere Zäune, mehr Licht, etc.)
Aus dem WIKI/Commandref werde ich nicht schlau...
set <name> disablePort <port>
Only visible when Attr portProfileDisableID is set.
Set the PortProfile from Attr portProfileDisableID for <port>.
set <name> portProfile <port>
Set the PortProfile ID. The ID can be found with get portOverrides.
Muss ich ein Portprofile erstellen? wenn ja warum?
Vielleicht hat jemand eine Idee um das Trauerspiel zu beenden :)
UDM-Pro
usw-48-poe
u6-mesh
alles aktuelle FW. FHEM aktuell. debian etc. aktuell.
Der Unifi-Benutzer mit dem ich verbunden bin ist admin mit allen Rechten
Keine Hinweise im Log oder im Event Monitor
Grüße und Danke!
Zitat von: Neeein am 07 März 2024, 22:12:30ich habe vor zwei Tagen das Unifi Modul + Switch installiert und schaffe es einfach nicht Port 8 (oder irgendeinen anderen) mit "set Switch_48_PoE disablePort 8" ausschalten. Da hängt ein U6-Mesh dran, dessen Port ich komplett ausschalten will, sobald das Gerät nicht mehr "online" ist. Hintergrund ist das leicht zugängliche Lan-Kabel (bitte keine Belehrungen über mehr Kameras, höhere Zäune, mehr Licht, etc.)
den port via 802.1x abzusichern stand jetzt nicht in deiner aufzählung, daher belehr ich dich dahingehend ;D der usw-48-poe kann das und 802.1x sollte bei allen lan ports im aussenbereich genutzt werden. MBA ist zwar nicht robust, aber besser als nichts. funktioniert aber gut, wenn du 802.1x mit radius nutzt und als fallback vlan ein gäste vlan nutzt oder eins mit honeypots. so checkt ein angreifer das nicht sofort und du kannst drauf reagieren... dann (erst) port sperren, alarmanlage oder was auch immer. port abschalten bringt dir nichts wenn im wlan ein gerät hängen bleibt, zumal das roaming bei unifi nicht immer 100prozentiges ist, wenn du mehrere AP nutzt und sich funkbereiche überschneiden.
Danke @guybrush, das war mit etc. abgedeckt 😉 das habe ich im Unifi-Forum schon zur genüge besprochen. Ich möchte da auch garnicht weiter drauf eingehen, da dass nicht die Fragestellung war.
Mir stellt sich nach wie vor die Frage, was ich übersehe, was mir das Abschalten nicht gelingen lässt.
Das Problem ist wahrscheinlich der Umstand, dass irgendein Firmwareupdate deines Switches in der Vergangenheit Änderungen eingeführt hat mit denen das Modul hier nicht umgehen kann; und deswegen funktioniert es halt nicht.
Leider ist das Modul hier offensichtlich verwaist. Der Modulmaintainer war das letzte Mal am 05.11.2023 online.
Hallo,
ich habe eine Dream Maschine von Unifi gekauft. Vorher hatte ich den Unifi Controller als Docker Container laufen und Fhem konnte sich problemlos damit verbinden. Nun läuft der Controller auf der UDM und die Verbindung funktioniert nicht mehr.
List vom Modul:
Internals:
DEF 192.168.0.1 443 crypt:755b5455 crypt:5b5c4148031016085000010652
FUUID 650db580-f33f-8133-e92f-ac15372b6efb3d41
NAME Unifi
NOTIFYDEV global
NR 1126
NTFY_ORDER 50-Unifi
STATE disconnected
TYPE Unifi
UC_VERSION unknown
VERSION 3.5.3
eventCount 33
READINGS:
2024-03-10 13:00:47 state disconnected
accespoints:
alerts_unarchived:
clients:
events:
helper:
password crypt:5b5c4148031016085000010652
username crypt:755b5455
hotspot:
vouchers:
httpParams:
header
ignoreredirects 1
loglevel 5
method POST
noshutdown 0
timeout 5
hash:
sslargs:
SSL_verify_mode 0
unifi:
CONNECTED disconnected
eventPeriod 24
interval 30
ucurl https://192.168.0.1/api/s/default/
udmurl https://192.168.0.1/proxy/network/api/s/default/
url https://192.168.0.1/api/s/default/
customClientReadings:
attr_value .:^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime
parts:
0000000_part:
ReadingRegEx ^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime
nameRegEx .
updateDispatch:
wlans:
Attributes:
alias Unifi
group Present
icon it_wifi
isUDM 1
room 90_System
Die Version der UDM ist: UniFi OS 3.2.12 / Netzwerk 8.0.28
Weis jemand Rat ?
Viele Grüße
HW1
https://forum.fhem.de/index.php?msg=1297760
Zitat von: Ralli am 10 März 2024, 14:46:23https://forum.fhem.de/index.php?msg=1297760
Danke für die schnelle Antwort, die Version hab ich auch schon erfolglos ausprobiert.
Folgendes ist im Log:
2024.03.10 16:03:36 5: Unifi (Unifi_Login_Send) - executed.
2024.03.10 16:03:36 5: Unifi (Unifi_Login_Receive) - executed.
2024.03.10 16:03:36 5: Unifi (Unifi_Login_Receive) - Failed because no data was received!
2024.03.10 16:03:36 5: Unifi (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2024.03.10 16:04:04 5: Unifi: Defined with url:https://192.168.0.1/api/s/default/, interval:30
2024.03.10 16:04:05 5: Unifi (Unifi_Notify) - executed.
2024.03.10 16:04:05 5: Unifi (Unifi_Notify) - checking 1 state
2024.03.10 16:04:05 5: Unifi (Unifi_Notify) - executed. - Remove all Timers & Call DoUpdate...
2024.03.10 16:04:05 5: Unifi (Unifi_DoUpdate) - executed.
2024.03.10 16:04:05 5: Unifi (Unifi_Login_Send) - executed.
2024.03.10 16:04:05 5: Unifi (Unifi_initCustomClientReadings) - parsed part: . -> ^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime
2024.03.10 16:04:05 5: Unifi (Unifi_initCustomClientReadings) - parsed Attribute customClientReadings: {"parts":{"0000000_part":{"ReadingRegEx":"^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime","nameRegEx":"."}},"attr_value":".:^accesspoint|^essid|^hostname|^last_seen|^snr|^uptime"}.
2024.03.10 16:04:05 5: Unifi (Unifi_Login_Receive) - executed.
2024.03.10 16:04:05 5: Unifi (Unifi_Login_Receive) - Login Failed (without msg)! - state:''
2024.03.10 16:04:05 5: Unifi (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2024.03.10 16:04:09 5: Unifi: get called with ?.
2024.03.10 16:04:28 5: Unifi (Unifi_Notify) - executed.
2024.03.10 16:04:28 5: Unifi: get called with ?.
2024.03.10 16:04:30 5: Unifi: get called with ?.
2024.03.10 16:04:35 5: Unifi (Unifi_Login_Send) - executed.
2024.03.10 16:04:36 5: Unifi (Unifi_Login_Receive) - executed.
2024.03.10 16:04:36 5: Unifi (Unifi_Login_Receive) - Login Failed (without msg)! - state:''
2024.03.10 16:04:36 5: Unifi (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2024.03.10 16:04:39 5: Unifi: set called with update
2024.03.10 16:04:39 4: Unifi: set update
2024.03.10 16:04:39 5: Unifi (Unifi_DoUpdate) - executed.
2024.03.10 16:04:39 5: Unifi (Unifi_Login_Send) - executed.
2024.03.10 16:04:39 5: Unifi: get called with ?.
2024.03.10 16:04:41 5: Unifi (Unifi_Login_Receive) - executed.
2024.03.10 16:04:41 5: Unifi (Unifi_Login_Receive) - Login Failed (without msg)! - state:''
2024.03.10 16:04:41 5: Unifi (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2024.03.10 16:04:47 5: Unifi: get called with ?.
Es kommt erst gar nicht zu einem erfolgreichen Login. User/Passwort neu setzen.
Hab ich versucht, klappt nicht. Hab auch mal einen extra User in der Unifi Console für Fhem angelegt, wird aber auch nicht verbunden.
Hab dann mal mit den gleichen User/Password über ioBroker eine Unifi Instanz angelegt, da war die Verbindung direkt da.
Zitat von: Wolle02 am 08 März 2024, 14:21:12Das Problem ist wahrscheinlich der Umstand, dass irgendein Firmwareupdate deines Switches in der Vergangenheit Änderungen eingeführt hat mit denen das Modul hier nicht umgehen kann; und deswegen funktioniert es halt nicht.
Leider ist das Modul hier offensichtlich verwaist. Der Modulmaintainer war das letzte Mal am 05.11.2023 online.
Das muss es wohl sein...
Zitat von: Neeein am 10 März 2024, 20:42:05Zitat von: Wolle02 am 08 März 2024, 14:21:12Das Problem ist wahrscheinlich der Umstand, dass irgendein Firmwareupdate deines Switches in der Vergangenheit Änderungen eingeführt hat mit denen das Modul hier nicht umgehen kann; und deswegen funktioniert es halt nicht.
Leider ist das Modul hier offensichtlich verwaist. Der Modulmaintainer war das letzte Mal am 05.11.2023 online.
Das muss es wohl sein...
Die API hat sich an der Stelle schon vor einigen Jahren geändert.
Hi,
nur falls sich mal jemand 2 Wochen mit Fehlermeldungen wie dieser rumschlägt und die Ursache im Bereich "unsichere SSL Verbindungen akzeptieren" sucht:
2024.03.13 14:09:17 5: unifi_pi: get called with ?.
2024.03.13 14:09:32 5: unifi_pi (Unifi_Login_Send) - executed.
2024.03.13 14:09:33 5: unifi_pi (Unifi_Login_Receive) - executed.
2024.03.13 14:09:33 5: unifi_pi (Unifi_Login_Receive) - Failed with HTTP Code 500!
2024.03.13 14:09:33 5: unifi_pi (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
Merke: verwende NIEMALS Anführungszeichen "" in Passwörtern!
>:(
Zitat von: hanswerner1 am 10 März 2024, 19:27:47Hab ich versucht, klappt nicht. Hab auch mal einen extra User in der Unifi Console für Fhem angelegt, wird aber auch nicht verbunden.
Hab dann mal mit den gleichen User/Password über ioBroker eine Unifi Instanz angelegt, da war die Verbindung direkt da.
Da ich über das Unifi Modul die Anwesenheitsabfrage (Handys in Wlan eingebucht) mache muss ich erstmal mit einen Workaround leben. Ich habe nur zu diesem Zweck iobroker installiert und mach dort die Abfrage und leite das Ergebnis an Fhem weiter.
Seit kurzem bietet Unifi die 2 Faktor Authentifizierung an.
Schaltet man diese ein, so kann sich FHEM nicht mehr verbinden.
Unify (Unifi_Login_Receive) - Login Failed! - state:'error' - msg:'api.err.Ubic2faTokenRequired'
Zitat von: chazz am 16 April 2024, 20:04:17Seit kurzem bietet Unifi die 2 Faktor Authentifizierung an.
Schaltet man diese ein, so kann sich FHEM nicht mehr verbinden.
Unify (Unifi_Login_Receive) - Login Failed! - state:'error' - msg:'api.err.Ubic2faTokenRequired'
Kann das sein, dass Du irgendein Cloud-Geraffel für die Anmeldung am Controller aktiviert hast? Ich melde mich mit einem lokalen Account an und es funktioniert trotz der Aktivierung der 2FA im Ubnt-Account.
Patrick