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

Wuehler · 18 Februar 2018, 21:06:35

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:

Code Auswählen

sudo service unifi status

Roli1606 · 18 Februar 2018, 21:26:10

Da kommt das bei raus

Code Auswählen

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.

Wuehler · 19 Februar 2018, 08:22:12

Das sieht so aus wie bei mir. Findest du im server.log des UC etwas?

Roli1606 · 19 Februar 2018, 23:20:22

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.

Wuehler · 20 Februar 2018, 09:32:03

Sehr schön. Das war zu einfach zu finden

Läuft es denn jetzt wie gewünscht?

Roli1606 · 20 Februar 2018, 09:44:12

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

acw81 · 10 März 2018, 13:26:02

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

Wuehler · 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

Wuehler · 10 März 2018, 18:09:25

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

acw81 · 10 März 2018, 18:27:05

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

Wuehler · 11 März 2018, 15:49:16

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.

Wuehler · 13 März 2018, 09:01:46

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
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

Wuehler · 13 März 2018, 22:04:23

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.

hologramm · 07 April 2018, 21:44:39

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

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

Wuehler · 07 April 2018, 22:17:23

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