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

[Wuehler]

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.

[OdfFhem]

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

[Wuehler]

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

[Wuehler]

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.

[OdfFhem]

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

[Wuehler]

@all: Habe gerade die restlichen Funktionen für UC Version 5.10 gefixt. Gibt es morgen im Update.

@OldFhem:

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, ...).

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:

Code Auswählen Erweitern

set Unifi blockClient 04:d6:aa:3f:84:50

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.

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.

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?

gute Idee.

[Maui]

Moin @Wuehler: leider scheint lastSeenDuration doch nicht zu klappen.
Nach 5min absence scheint er aufhören hochzuzählen.

[Wuehler]

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

[Maui]

Sieht besser aus. Danke.

[Maui]

Moin Wuehler,

Ist der fix schon eingecheckt?

Gruß
Maui

[Wuehler]

Moin Maui,

Nein. Bin gerade auf Reise. Musst dich noch eine Woche gedulden   

[Maui]

Alles gut dann mach ich so lange einfach kein Update

[andies]

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

Code Auswählen Erweitern

<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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

echo $JAVA_HOME
/usr/lib/jvm/java-8-oracle
Jetzt startet der Controller aber mal gar nicht

Code Auswählen Erweitern

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.

[Maui]

Moin. Versuche es mal damit.

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

[andies]

habe ich gemacht und bin bei

Code Auswählen Erweitern


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.