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

[remo]

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

[remo]

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

[andies]

Ich habe ein Problem mit dem unblock/block Client, kann mir da jemand helfen:

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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


[andies]

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 

[andies]

Ich werde noch verrückt. Also das Modul liefert mir Daten, alle fünf Minuten:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

[andies]

Ich  habe mal ein wenig weiter gesucht. Also, ich habe einmal eine Fehlermeldung und einmal keine, zum Beispiel

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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.

[Gisbert]

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

Code Auswählen Erweitern

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

[TomLee]

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 ?

[Gisbert]

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

[TomLee]

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



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.

[andies]

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.

[marvin78]

Wenn keine Site-ID in der URL steht, ist es "default".

[Jewe]

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 ?

Code Auswählen Erweitern


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

[hoppel118]

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

[Jewe]

Hallo Hoppel,

ja da habe ich wohl zuwenig gelesen...

Danke jetzt klappts wieder.

Jens