Hallo zusammen,
ich habe begonnen ein Modul UnifiClient zu schreiben, das einen client nach einer definierbaren Online-Zeit blocked und am nächsten Tag wieder unblocked.
Definieren muss man aktuell noch manuell:
define myClient UnifiClient <clientName im Unifi-Modul>Es werden nach dem nächsten Update des Unifi-Moduls im UnifiClient alle Informationen als Readings angezeigt.
Es gibt die Attribute:
- maxOnlineMinutesPerDay: Zeit in Minuten, die der Client an einem Tag online sein darf.
- thresholdBytesPerMinute: Bytes, die pro Minute verbraucht werden dürfen, ohne dass Onlinezeit angerechnet wird. Default: 75000
- blockingUsergroup: Wenn gesetzt wird der client nicht geblockt sondern in die angegebene Benutzergruppe geschoben. Diese sollte einen sehr geringen up- und down-stream haben.
Es gibt einen set-Befehl (set usergroup <name>) zum ändern der Benutzergruppe des clients.
Es gibt einen neuen set-Befehl im Unifi-Modul:
- refreshUsergroups: Usergroups werden nur einmalig beim define abgefragt, nicht in jedem Update-Zyklus. Hiermit können Usergroups aktualisiert werden.
ich bin gespannt auf euer Feedback:
- Bezeichnungen verständlich?
- passt der Threshold?
- welche Funktionen fehlen?
Ihr müsst alle drei Module des Anhangs installieren.
VG,
Dirk
Edit: Anhänge entfernt, da das Modul im normalen Update enthalten ist.
Hallo Wuehler,
endlich kann ich meine Kinder ohne viel Aufwand quälen ;D
Zwei Attribute fehlen noch:
maxOnlineMinutesPerWeek
maxOnlineMinutesPerMonth
Gruß
Eisix
Wie funktioniert das technisch? Am blocken stört in der Regel die ständige Provisionierung aller Access Points.
Ja, geht nur mit blocken. Alternativ für Besitzer eines USG könnte man eine Firewallregel erstellen, dann würden APs nicht provisioniert, nur das USG. Da nicht jeder ein USG hat würde ich das Blocken bevorzugen.
wie wäre es optional die betroffenen clients zeitweise in eine andere benutzergruppe mit sehr stark eingeschränkter bandbreite zu schieben? 5k up und down machen das gerät interaktiv eigentlich unbenutzbar.
Zitat von: Wuehler am 24 April 2019, 06:43:06
Ja, geht nur mit blocken. Alternativ für Besitzer eines USG könnte man eine Firewallregel erstellen, dann würden APs nicht provisioniert, nur das USG. Da nicht jeder ein USG hat würde ich das Blocken bevorzugen.
Könnte man das eventuell mit einem Attribut steuerbar machen, ob Firewallregel oder Blocken? Beim Blocken habe ich das Problem, dass bei einer Neuprovisionierung des AP aus mir nicht ganz verständlichen Gründen mein FHEM für diese Zeit blockiert.
Die Idee von justme finde ich interessant. Leider kann man Usergroups nicht in Firewallregeln verwenden oder bestimmten Netzwerken zuweisen (zumindest habe ich das eben nicht gefunden).
Wenn ich es von unterwegs eben richtig gesehen habe führt eine Änderung der Usergroup nicht zu einer Provisionierung. Wäre ja vorteilhaft.
So wie es aussieht wird es dann irgendwann ein Attribut zur Auswahl der Block-Methode (block, Firewall, Usergroup) geben.
ja. es wird bei ändern der usergroup nicht neu provisioniert.
hab gerade gesehen das man inzwischen sogar bis auf 2kbps runter kann.
Nabend,
Ich habe die Anregung mit den Benutzergruppen umgesetzt. Ist noch nicht ganz durchgetestet und der Code kann auch noch optimiert werden, aber sieht bisher vielversprechend aus. Wer also Zeit und Lust hat sich als Beta-Tester zu beschäftigen:
Im ersten Post ein Update der Module.
Änderungen:
UnifiClient:
- Attribut blockingUsergroup: Wenn gesetzt wird der client nicht geblockt sondern in die angegebene Benutzergruppe geschoben. Diese sollte einen sehr geringen up- und down-stream haben.
- set usergroup
Unifi:
- set refreshUsergroups: Aufrufen, wenn man im UC die Benutzergruppen geändert hat
UnifiSwitch:
- Kompatibilität sicherstellen. Keine inhaltlichen Änderungen
VG,
Dirk
Zitat von: justme1968 am 24 April 2019, 08:19:50
wie wäre es optional die betroffenen clients zeitweise in eine andere benutzergruppe mit sehr stark eingeschränkter bandbreite zu schieben? 5k up und down machen das gerät interaktiv eigentlich unbenutzbar.
Das ist aber dann nur für ein Netzwerk gültig, das als Gastnetzwerk definiert ist. Für andere Netzwerke ist die Usergruppe und deren Bandbreite unerheblich und wird nicht angewendet.
https://community.ubnt.com/t5/UniFi-Updates-Blog/UniFi-5-0-7-is-released/ba-p/1587040
Und das gilt noch immer. Ich habe es eben getestet.
das funktioniert bei mir im ganz normalen (nicht-gast) netz.
dein link zeigt auf einen post der fast drei jahre alt ist und ich kann dort nichts zu benutzerguppen oder bandbreite finden.
Zitat von: justme1968 am 25 April 2019, 15:06:16
dein link zeigt auf einen post der fast drei jahre alt ist und ich kann dort nichts zu benutzerguppen oder bandbreite finden.
ZitatSpeed limits for wireless clients only work on guest VAPs. Non-guest VAPs will not enforce speed limits. This is to help with overall throughput. Please see our original post HERE. If you need to have enforced speed limits on non-guest VAPs then you should use firmware 3.4.19 (do note that you will lose some features when changing to 3.4.19). We've been working on a fix for this and will include it as soon as possible.
Und ich kann bei mir keine Veränderung zum Status von vor 3 Jahren feststellen. Und ja, ich bin bei der Firmware und beim Controller aktuell.
stimmt steht da. hatte nicht nach speed gesucht. nur nach user und bandwidh :). aber als bug. nicht als feature.
die 'offizielle' beschreibung des features hier: https://help.ubnt.com/hc/en-us/articles/204911354-UniFi-How-to-Set-Traffic-Bandwidth-Limits (http://ttps://help.ubnt.com/hc/en-us/articles/204911354-UniFi-How-to-Set-Traffic-Bandwidth-Limits) sagt auch nichts zu einer einschränkung auf gast netze.
ich verwende das schon ziemlich lange und es hat immer funktioniert.
jetzt wäre die frage welche ap modelle du verwendest und welche firmware?
meine sind uap-ac-pro, uap-mesh-pro, ap-ac-inwall, uap-ac-mesh und noch einen alten uap-pro aktuell mit 4.0.32, in den letzen monaten und jahren fast immer die jeweils neueste.
Ich verwende verschiedene Modelle:
UniFi AP-nanoHD
UniFi AP-AC-Mesh
UniFi AP-HD
UniFi AP-AC-LR
Jeweils mehrere, außer beim HD
Firmware ist aktuell: 4.0.21.9965
Idee: Ggf. muss man erst alle ACs erst provisionieren, nachdem die neue Gruppe mit neuer Bandbreite angelegt wurde? Genau das wollte ich vermeiden.
Aktuell ist es hier so: Gebe ich meinen Smartphone eine Usergroup mit 2kpbs Bandbreite, kann ich weiter ohne Einschränkung das Netz verwenden. Auch ein Neu-Verbinden ändert nichts daran.
ich habe die gruppe 'useless' mit 5kb up und down schon ewig. wenn ich einen client dort rein schiebe greift es sofort. ohne irgendetwas zu provisionieren. ich sehe auf dem iPhone sogar direkt wie der laufende speedtest fast sofort langsamer wird.
auch beim youtube schauen läuft noch der cache leer und das war es dann.
vorhin habe ich die gruppe von 5kb auf 2kb runter gesetzt und auch da wurde nichts provisioniert. und sie greift immer noch sofort. ob aktuell 2 oder 5 verwendet werden kann ich aber nicht sagen. beides ist so langsam das spendetest beim direkten laufen lassen eine fehlende verbindung anmeckert.
Bei meiner Idee ging es eher darum, dass die Gruppe mit der Bandbreite erst an die APs provisioniert werden muss und das spontane Gruppenänderungen erst danach greifen können.
Aber auch das ist nach einem Test auszuschließen. Die Bandbreite der Usergroup greift nicht.
sehr komisch... ich habe keine idee warum das bei dir nicht geht. ich fürchte da kann nur ubiquiti weiterhelfen.
So ganz wichtig ist dass noch nicht. Die größte ist erst 3. Auch wenn sie viel Quatsch im Kopf hat, bekommt sie noch kein Gerät in die Finger. ;)
Aber du hast Recht, es ist komisch.
Die Gruppe legt man einmalig an. Danach kann man munter Clients zuweisen ohne Provisionierung.
Ich hatte anscheinend den Thread aus Versehen geschlossen :o
Beim rumprobieren hatte ich eben ein ähnliches Verhalten wie marvin78. Nach einem Wechsel in das Gast-WLAN hatte ich keine Beschränkungen mehr. Anschließend zurück ins normale WLAN, und weiterhin keine Beschränkungen. Beide Male war der Client weiterhin in meiner Usergroup "Blocked". Erst ein erneutes Ändern der Usergroup auf "Default" und dann wieder "Blocked" hat den gewünschten Effekt geringer Bandbreite gehabt. Nachstellen kann ich das jetzt leider nicht mehr. Auch beim Wechsel ins Gast-WLAN bleibt die Usergroup "Blocked" wirksam. So wie erwartet.
Ich denke, die Funktion ist schlicht verbugt. Es gibt sicher dann noch Faktoren, die beeinflussen, ob es in gewissen Umgebungen funktioniert oder nicht. Wie so vieles bei UniFi eben.
Habe das Modul heute in einem BETA-Stadium bereitgestellt. Kann ab morgen über den fhem-Update-Mechanismus genutzt werden.
Ich finde folgendes Stateformat nützlich, wenn man alle clients in einer group untereinander schnell sehen möchte:
{ ReadingsVal("$name","fhem_usedOnlineTime","? Minuten")." / ".ReadingsVal("$name","_f_usergroup_name","?")." / ".((ReadingsVal("$name","blocked","?") eq "true") ? "blocked":ReadingsVal("$name","fhem_state","?"))}
Hallo,
beim define eines neuen UnifiClient's kriege ich folgende Fehlermeldung.
define myUC_Allnet-Tablet UnifiClient Allnet-Tablet
Invalid characters in name (not A-Za-z0-9._): myUC-Allnet-Tablet
Vor ein paar Tagen konnte ich noch
Internals:
CODE Viera
DEF Viera
FUUID 5ce5132a-f33f-8e5f-0479-f3448dba9859a9e6
FVERSION 74_UnifiClient.pm:0.194480/2019-05-22
IODev Unifi
NAME myUC_Viera
NOTIFYDEV global
NR 527
STATE disconnected
TYPE UnifiClient
VERSION 0.0.2 BETA
READINGS:
definieren. Mache ich was falsch oder hat sich da ein Bug eingeschlichen?
Gruß
Eisix
Zitat von: Eisix am 29 Mai 2019, 10:25:25
Hallo,
beim define eines neuen UnifiClient's kriege ich folgende Fehlermeldung.
define myUC_Allnet-Tablet UnifiClient Allnet-Tablet
Invalid characters in name (not A-Za-z0-9._): myUC-Allnet-Tablet
Vor ein paar Tagen konnte ich noch
Internals:
CODE Viera
DEF Viera
FUUID 5ce5132a-f33f-8e5f-0479-f3448dba9859a9e6
FVERSION 74_UnifiClient.pm:0.194480/2019-05-22
IODev Unifi
NAME myUC_Viera
NOTIFYDEV global
NR 527
STATE disconnected
TYPE UnifiClient
VERSION 0.0.2 BETA
READINGS:
definieren. Mache ich was falsch oder hat sich da ein Bug eingeschlichen?
Gruß
Eisix
In deinem Positiv Beispiel enthielt der eigentliche Hostname aber kein Minus Zeichen!
Scheinbar ist das für Hostnamen (nicht FHEM Namen) "noch" nicht möglich.
Greetz
Eldrik
Zitat von: Eisix am 29 Mai 2019, 10:25:25
Hallo,
beim define eines neuen UnifiClient's kriege ich folgende Fehlermeldung.
define myUC_Allnet-Tablet UnifiClient Allnet-Tablet
Invalid characters in name (not A-Za-z0-9._): myUC-Allnet-Tablet
Vor ein paar Tagen konnte ich noch
Internals:
CODE Viera
DEF Viera
FUUID 5ce5132a-f33f-8e5f-0479-f3448dba9859a9e6
FVERSION 74_UnifiClient.pm:0.194480/2019-05-22
IODev Unifi
NAME myUC_Viera
NOTIFYDEV global
NR 527
STATE disconnected
TYPE UnifiClient
VERSION 0.0.2 BETA
READINGS:
definieren. Mache ich was falsch oder hat sich da ein Bug eingeschlichen?
Gruß
Eisix
FHEM lehnt Device-Namen mit "Minus" ab, Hostname ist kein Problem.
Eben folgendes positiv getestet:
geht nicht:
define XPeria-Xc UnifiClient Xperia-Xc
define Test-Dummy dummy
define XPeriaXc UnifiClient Xperia-Xc
Gruß, Joachim
Danke, hat funktioniert.
Verwirrt hat mich die Fehlermeldung (not A-Za-z0-9._), habe ich als nicht A bis Z, a bis z, 0 bis 9,... gedeutet was ja dann nicht mehr viel übrig läßt ::).
Gruß
Eisix
Hallo zusammen,
ich habe voller Begeisterung das Modul ausprobieren wollen und scheitere zur Zeit an der Definiton eines Clients.
fhem ist aktuell (5.9.19488), update, shutdown, restart durchgeführt.
Das eigentliche Unifi Modul funktioniert soweit und liefert fröhlich Daten im eingestellten Rhythmus.
Wenn ich jedoch einen Client über das UnifiClient Modul definieren möchte stürzt fhem reproduzierbar ab.
define uclientD UnifiClient HandyZ1CD
Moin,
da habe ich wohl noch irgendetwas nicht richtig berücksichtigt. Was steht denn im Log wenn du das Modul definierst?
VG,
Dirk
Danke für die fixe Reaktion.
Ich habe mal ins Log geschaut:
2019.06.02 11:22:42 3: UnifiClient_Define - executed. 0
Undefined subroutine &main::timelocal called at ./FHEM/74_UnifiClient.pm line 344.
Nun bin ich nicht unbedingt der Perl-Zauberer... Ich hoffe aber, dass dir das hilft.
Gruß
Daniel
Vermutlich würde das helfen:
sudo apt-get install libdatetime-perl
Oder falls du lieber CPan zur Perl-Verwaltung nimmst DateTime darüber installieren...
EDIT: wann hast du fhem wie installiert? Bei meiner älteren Installation musste ich das Paket nachinstallieten, bei meiner neuesten fhem-Installation wurde es offenbar bereits mitinstalliert. Bzw. hatte ich dort beim define eines UnifiClient kein Problem...
Gruß, Joachim
Moin,
werde versuchen auf timelocal zu verzichten, um diese Abhängigkeit loszuwerden. Wird aber vermutlich etwas dauern bis ich Zeit dazu habe und etwas passendes gefunden habe. Bin auch kein Perl-Experte.
Von daher am schnellsten wäre es aktuell für euch das Paket zu installieren.
VG,
Dirk
Es war dann doch einfacher als gedacht, habe mich im Modul AT bedient und einen guten und einfachen Ersatz gefunden. Fix ist hochgeladen und morgen ab 8 Uhr im Update verfügbar.
Super, funktioniert!
Nicht, dass das jetzt noch entscheidend wäre... Ich habe mal nachgeschaut, zu meinem Erstaunen ist die lib bei mir installiert.
pi@HDDpi:~ $ sudo apt-get install libdatetime-perl
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
libdatetime-perl ist schon die neueste Version (2:1.42-1).
libdatetime-perl wurde als manuell installiert festgelegt.
fhem habe ich aus dem Repository installiert.
Danke an euch für die Mühe.
Sehr schön. Lerne immer noch neues über perl ;)
Keine Ahnung, warum manche den Fehler bekommen und andere nicht. In einer reinen perl-Datei ohne fhem drumrum habe ich nämlich dieselbe Fehlermeldung gesehen. Hätte mit use Time::Local das Paket eigentlich einbinden müssen. Aber die jetztige Lösung ist noch besser, da das zusätzliche Paket vermieden wird.
@all: Hatte mir selbst mal das presence-Reading wie im WIKI bisher beschrieben angelegt und bemerkt, dass das Handy oft als wired-Gerät an den USG "übergeben" wird, wenn ich das Haus verlasse. Bin dann oft ganz kurz absent gewesen um kurze Zeit später wieder present zu sein (wired). Habe daher das WIKI (https://wiki.fhem.de/wiki/UnifiClient#Anwesenheitserkennung)auf eine zusätzliche Überprüfung des Attributes "is_wired" angepasst.
Moin Dirk,
ich habe ein neues Handy und dieses als Unifi-Client in FHEM eingebunden und mein altes gelöscht. Jetzt habe ich gerade im Logfile gesehen, dass ca. alle 30 Sekunden folgende Meldung ins Log geschrieben wird.
ERROR: >UC_Wolles_S7< returned by the UnifiClient ParseFn is invalid, notify the module maintainer
Das Device UC_Wolles_S7 gibt es gar nicht mehr.
Gruß
Wolle
Ich habe jetzt versucht das Device UC_Wolles_S7 wieder anzulegen. Dann erhalte ich allerdings folgende Fehlermeldung:
Client with name Wolles-S7 already defined in UC_Wolles_S7
Ein "list UC_Wolles_S7" ergibt aber folgendes Ergebnis:
No device named UC_Wolles_S7 found
Moin,
Vermutlich muss ich beim undefine noch etwas machen. Schaue ich mir nach meinem Urlaub an.
VG,
Dirk
Ohh, alles klar. Dann wünsche ich dir erstmal einen schönen Urlaub. ;) 8)
Hi Wolle,
der erste Fehler
ZitatERROR: >UC_Wolles_S7< returned by the UnifiClient ParseFn is invalid, notify the module maintainer
kommt, da dein Unifi-Modul auch alte Clients weiter beinhaltet. Bitte dort mal ein "set removeClientReadings UC_Wolles_S7" durchführen, oder wenn das nicht geht ein clear all.
Zum zweiten Fehler: Wie hast du den UnifiClient gelöscht? Edit in fhem-config? Oder per klick auf den Link "Delete this device (UC_Wolles_S7)" unten am device?
VG,
Dirk
Hallo Dirk,
ZitatBitte dort mal ein "set removeClientReadings UC_Wolles_S7" durchführen
Das hat funktioniert. Die Fehlermeldung kommt nicht mehr.
Wenn ich allerdings das alte Handy wieder einschalte und es sich erneut am WLAN anmeldet werden die Readings wieder angelegt und die Fehlermeldung kommt wieder.
ZitatWie hast du den UnifiClient gelöscht? Edit in fhem-config? Oder per klick auf den Link "Delete this device (UC_Wolles_S7)" unten am device?
Ich hatte auf den Link "Delete this device (UC_Wolles_S7)" geklickt.
Wenn ich nun versuche das alte Handy wieder als ClientDevice anzulegen kommt wieder die gleiche Fehlermeldung, dass es nicht angelegt werden kann, da es bereits existiert. Ein list zeigt aber weiterhin, dass es nicht existiert.
Hi,
kannst du bitte ein
list TYPE=UnifiClient
ausführen. Bin gespannt, ob dein Wolles-S7 dann dabei ist.
Wenn nicht nochmal ein
{ join("\n", grep { !defined($defs{$_}{TYPE}) } keys %defs) }
VG,
Dirk
Also ein
list TYPE=UnifiClient
ergibt nur mein neues Handy:
Internals:
CFGFN
CODE Wolles-S10
DEF Wolles-S10
IODev UniFi_Controller
LASTInputDev UniFi_Controller
MODEL
MSGCNT 28353
NAME UC_Wolles_S10
NOTIFYDEV global
NR 26146
STATE Onlinezeit im Netzwerk: 14 Minuten
TYPE UnifiClient
UniFi_Controller_MSGCNT 28353
UniFi_Controller_TIME 2019-07-27 05:51:01
VERSION 0.0.3 BETA
Die Eingabe von
{ join("\n", grep { !defined($defs{$_}{TYPE}) } keys %defs) }
hat nur eine lere Seite zur Folge.
da bin ich irgendwie auch ratlos. Bei mir funktioniert das Löschen eines UnifiClients auch problemlos.
Setze bitte beim Unifi Modul und bei deinem existierenden UnifiClient mal verbose auf 5 und schick/poste mir das Log.
Huiii, das hat aber innerhalb von ein paar Minuten gut das Logfile gefüllt 8)
Ich schick dir die Daten per PN.
Moin,
ich fasse die Kommunikation per pm mal für die Nachwelt zusammen:
Interessant sind folgende drei Zeilen aus dem Log:
2019.07.28 06:57:33 5: UniFi_Controller (UnifiClient_Parse) - executed. UnifiClient: Adress: Wolles-S7
2019.07.28 06:57:33 5: UniFi_Controller (UnifiClient_Parse) - return: UC_Wolles_S7
2019.07.28 06:57:33 1: ERROR: >UC_Wolles_S7< returned by the UnifiClient ParseFn is invalid, notify the module maintainer
Die erste sagt, dass ein UnifiClient mit dem Namen Wolles-S7 aktualisiert werden soll.
Die zweite zeigt, dass eine Definition UC_Wolles_S7 dazu gefunden wurde in dem globalen Hash $modules.
Die dritte sagt, dass es diese Definition in einem anderen globalen Hash $defs nicht existiert.
Im Undefine vom UnifiClient wird eigentlich folgendes aufgerufen:
{delete($modules{UnifiClient}{defptr}{UC_Wolles_S7})}
Das hat aus irgendwelchen Gründen in diesem Fall nicht funktioniert.
Die Zeile direkt in der fhem-Befehlszeile eingegeben hat wieder für Konsistenz gesorgt.
VG,
Dirk
Moin Dirk,
bin jetzt erst wieder Heim gekommen.
Leider bringt der Versuch das Device UC_Wolles_S7 wieder anzulegen immer noch die Fehlermeldung
Client with name Wolles-S7 already defined in UC_Wolles_S7
Wenn ich das S7 Handy wieder hochfahre und ans Netz bringe kommt im Log auch wieder die Fehlermeldung
ERROR: >UC_Wolles_S7< returned by the UnifiClient ParseFn is invalid, notify the module maintainer
Somit leider keine Veränderung.
Mir fällt gerade auf, dass ich beim delete einen kleinen Denkfehler hatte. Probier mal
{delete($modules{UnifiClient}{defptr}{Wolles-S7})}
Hmmmm.
Bareword "Wolles" not allowed while "strict subs" in use at (eval 14438991) line 1.
Bareword "S7" not allowed while "strict subs" in use at (eval 14438991) line 1.
OK, dann noch Anführungszeichen:
{delete($modules{UnifiClient}{defptr}{"Wolles-S7"})}
Hallo Dirk,
Zitat von: Wuehler am 31 Juli 2019, 07:57:17
OK, dann noch Anführungszeichen:
{delete($modules{UnifiClient}{defptr}{"Wolles-S7"})}
Jawohl, das wars. :D Ich tu' mich immer noch schwer mit der Syntax.
Das Device wurde jetzt wieder angelegt. Irgendwelche Auffälligkeiten im Log konnte ich nicht entdecken.
Erstmal vielen Dank.
Gruß
Wolle
Zitat von: Wolle02 am 31 Juli 2019, 08:16:57
Ich tu' mich immer noch schwer mit der Syntax
Geht mir genauso. Musste ich auch erstmal ausprobieren.
Sehr schön, dass wir das korrigieren konnten, hoffentlich passiert es nicht noch einmal. Die Ursache haben wir ja nicht gefunden.
Soll ich das Device nochmal löschen um das auszuprobieren oder willst du im Modul erst noch was ändern und ich teste das nochmal nach einem Update?
Ich denke nicht, dass das reproduzierbar ist. Wenn du magst kannst du es gerne versuchen. Änderungsbedarf sehe ich nicht.
Alles klar. Tatsächlich hatte das erneute Löschen des Devices keine nachteiligen Folgen. Erneute Fehlermeldungen kommen nicht mehr.
Vielen Dank für deine Hilfe.
Hi
Der letzte Post ist zwar schon eine Weile her, aber er entspricht exakt meinem aktuellen Problem.
Die Erstellung eines Clients wird verweigert mit der Meldung "Client with name XYZ already defined in XYZ".
Der Client existiert aber nicht im cfg und kann auch über ein list nicht ermittelt werden.
Ich habe alle Hinweise aus diesem Beitrag durchgespielt und auch die vermeintliche Lösung am Ende versucht. Leider aber immer noch ohne Erfolg...
Deshalb die Frage. Gibt es inzwischen ein Update des Moduls? Oder andere weitere Erkenntnisse zur Behebung dieses Problems?
Aktuelle Version 74_UnifiClient.pm: V 0.0.3 BETA
DANKE!