Modul Unifi: Sammlung für Wiki

[Wuehler]

Hallo zusammen,

So langsam wird das Unifi-Modul so umfangreich, dass eine Dokumentation nur in der commandref nicht mehr ausreicht. Ich habe mir daher Zugang zum Wiki beantragt und werde dort ein wenig mehr zu einzelnen Attributen dokumentieren.
Meine Bitte an die Nutzer des Moduls:
Postet in diesem Thread eure Anwendungsfälle, ich würde sie dann als Beispiele mit ins Wiki übernehmen.

Vielen Dank schon mal,
Dirk

PS: Seite ist angelegt im Wiki: https://wiki.fhem.de/wiki/Unifi

[Maui]

Moin. Interessant wäre evtl. Auch die Unstellung am Controller auf 5.10.x
Hat zwar nix direkt mit dem Modul zu tun aber die Umstellung bei Java ist ja schon was größeres.
Aber ich weiß nicht ob das wirklich ins Wiki gehört.

Ansonsten als use case habe ich aktuell 2.

Einmal das Erkennen von neuen ggf. unbekannten WLAN-Geräten über dein newClients mit DOIF.
Und vermutlich den "Klassiker" hier, die Presence Detection über einzelne Geräte, ebenfalls mit DOIF.

[Wuehler]

Die Umstellung auf 5.10 ist ja eine einmalige Aktion. Würde sie daher nicht im Wiki sehen. Aber man könnte im Forum einen Dokuthread eröffnen.

Das doif für neue Clients Hattest du im Unifi-Hauptthread schonmal gepostet, oder?

[gloob]

Erstellen/Bereitstellen von Wifi Vouchers wäre interessant.

[Maui]

Das doif für neue Clients Hattest du im Unifi-Hauptthread schonmal gepostet, oder?

Denke schon. 

[Wuehler]

Seite ist angelegt im Wiki: https://wiki.fhem.de/wiki/Unifi

[Maui]

Sehr gut. Danke.
Paar typos:
- 2. port groß also Port
- Standardmäßig würde ich klein schreiben
- setings
- interval groß und Intervall
- wolltest du ptimes schreiben?

OT: Wieso sollte es eigentlich besser sein ein neuen User anzulegen?

[Wuehler]

Danke für die QS. Korrigiere ich gleich mal.

Wenn man nur eine Anwesenheitserkennung macht braucht man zB auch nur einen read-only-User. Und readopt-Rechte sind auch nie nötig.
Ärgerlich wäre auch, wenn einem für den einzigen Admin das Passwort von einem Dritten geändert wird.

[Steinzeitmensch]

Hallo Wuehler,
ich habe heute das Unifi-Modul eingespielt. Die Readings werden jedoch nicht korrekt angezeigt. Last_seen Readings werden aktualisiert, obwohl die entsprechenden Smartphones disconnected bzw. nicht im Wlan sind.
Oder habe ich etwas übersehen?
VG

[Wuehler]

Moin,

Das ist eher ein Feature des Moduls. Das Modul aktualisiert mittlerweile auch disconnected clients mit den Daten aus dem UnifiController (dort Insights genannt).  Der Status im Modul sollte aber disconnected sein.

VG,
Dirk

[MadMax-FHEM]

Hallo,

so wie in einem der anderen Threads zu Unifi "angedroht"

Hier meine Anwendung (erster Wurf):

Ich habe 3 APs hier verteilt, 2 AC-Pro und einen Mesh.
Beim Verteilen hatte ich schon ungefähr im Kopf wer (Client) sich mit welchem AP (bevorzugt) verbinden sollte
Leider gibt es das Feature (gab es wohl mal) Clients bevorzugt APs zuzuweisen nicht mehr (habe ich so zumindest aus versch. Unifi-Foren-Threads)...
Schade.

Es gibt dann nat. noch die Möglichkeit zusätzliche SSIDs zu erzeugen und dann damit eine "quasi Client-Bindung" zu erreichen, wollte ich aber nicht...
Und dann noch das Feature mit RSSI (hatte noch keine Zeit mir das anzusehen)...

ABER, dachte ich mir: wozu habe ich fhem und wozu gibt es Module wie UnifiController und UnifiClient

Gut von meiner automatischen Verteilung durch fhem bin ich erst mal (wieder) weg, hatte (noch) keine Zeit mir etwas für "störrische Clients" zu überlegen (will ja nicht ständig automatisch reconnecten) aber vielleicht später (wieder).

Da es auch meistens stimmt (also die Zuordnung wie ich sie gerne hätte) gehe ich ab und an drüber und "korrigiere"...

Aktuell entweder indem ich mich in den UnifiController einlogge oder eben über fhem und das UnifiController-Modul...
...beides nicht sehr übersichtlich (für diesen Zweck).

Daher habe ich mir eine ReadingsGroup gebaut, die mir 1. eine einfache Übersicht über die Verteilung gibt und 2. durch einen einfachen Klick einen Reconnect des Clients durchführt

Hier die ReadingsGroup (define für WebCmd + Attribute für "später"   ):

Code Auswählen Erweitern


define rgOverviewUnifiClients readingsGroup <Name>,<AP>,<reconnect>,<RSSI>,<signal> TYPE=UnifiClient:accesspoint,<{my_DisconnectClient($DEVICE)}@accesspoint>,rssi,signal


Und ich habe (aktuell) ein Attribut gesetzt, damit ich schnell einen Überblick habe wer wo dran hängt:

Code Auswählen Erweitern

attr rgOverviewUnifiClients sortColumn 2

Welche weiteren Werte ich mir noch anzeigen lasse weiß ich noch nicht, aktuell eben RSSI und signal...
Wichtig ist mir aber nur der AP...
...und der Knopf zum Drücken

Hier noch die Sub in myUtils:

Code Auswählen Erweitern


sub my_DisconnectClient($)
{
  my ($Device) = @_;
  my $Name = ReadingsVal($Device,"fhem_clientName","n.a.");
  my $AP = ReadingsVal($Device,"accesspoint","n.a.");
  my @ClientListAPACProEingang=("Client1","Client2","Client3","Client4","Client5");
  my @ClientListAPACProFlur=("Client1","Client6","Client7","Client8","Client9");
  my @ClientListAPACMeshBalkon=("Client1","Client10","Client11","Client12","Client13","Client14");
  my $ActClientFromList = "";
  my $found = "false";
  my $Ret = "%audio_repeat";

# für debugging 
#  Log3(undef, 3, "my_DisconnectClient        Device: $Device    Name: $Name    AP: $AP");

  if($AP eq "AP-AC-Pro-Eingang")
  {
    foreach $ActClientFromList (@ClientListAPACProEingang)
{
  if($Name eq $ActClientFromList)
  {
    $found = "true";
  }
}
if($found ne "true")
{
          $Ret = "%audio_repeat\@red";
}
  }
  elsif ($AP eq "AP-AC-Pro-Flur")
  {
    foreach $ActClientFromList (@ClientListAPACProFlur)
    {
  if($Name eq $ActClientFromList)
  {
    $found = "true";
  }
}
if($found ne "true")
{
          $Ret = "%audio_repeat\@red";
}
  }
  elsif ($AP eq "AP-AC-Mesh-Balkon")
  {
    foreach $ActClientFromList (@ClientListAPACMeshBalkon)
{
  if($Name eq $ActClientFromList)
  {
    $found = "true";
  }
}
if($found ne "true")
{
          $Ret = "%audio_repeat\@red";
}
  }

  if($Name ne "n.a.")
  {
    # für tatsächliche Clients den "reconnect-Befehl" setzen
    # alternativ auch das hier dort anfügen, wo das Icon auf rot gesetzt wird, dann geht Klick und reconnect nur bei roten Icons...
    $Ret .= "%set UnifiController disconnectClient $Name";
  }
 
  return $Ret;
}


Da der Name in fhem und im UnfiController abweichen (können / z.B. kann der Name in fhem KEIN "Minus" enthalten, im UnifiController sehr wohl usw.) lese ich den Namen aus, den brauche ich ja für den disconnectClient-Befehl.

Bei mir heißt der UnifiController eben UnifiController, wenn er anders heißt: anpassen...
Auch die Namen der einzelnen APs, klar...
Und nat. auch der Clients in der Liste...

Dann habe ich für jeden meiner APs eine Liste mit bevorzugt zugeordneten Clients...
Wenn ein Client auch bei mehreren APs sein "darf" (wie beispielsweise Client1), dann ist er einfach in mehreren Listen drin (z.B. mein Handy weil das wandert ja mit mir durch die Wohnung etc.).
(mein späterer Plan ist Umbau auf ein Attribut [userattr], in dem die bevorzugten APs beim Client hinterlegt sind, dann werde ich da suchen, statt die Listen zu durchsuchen)

Wird der Client in der Liste des aktuell verbundenen APs gefunden bleibt das "Reconnect-Icon" grün ansonsten wird es rot -> einfache Übersicht wer richtig bzw. "falsch" verbunden ist.

Ein Klick auf das (rote / gut auch beim grünen wird es nicht verhindert, wäre aber möglich, indem man nur das Icon OHNE den set-Befehl zurück gibt) Icon wird dann für diesen Client der "reconnectClient" durchgeführt...

So, soweit erst mal zu meiner ersten Anwendung der Module (neben Logs und SVGs, was man halt so macht   )...

Gruß, Joachim

[Wuehler]

Moin Joachim,

wieder mal was dazugelernt. Mit readingsgroup habe ich bisher noch nicht viel gemacht. Ist aber inhaltlich sehr speziell, oder? Dein Ansinnen ist, sofern ich es richtig verstanden habe, dass stationäre WLAN-Clients immer das beste WLAN für sie nutzen. Und daher sollen sie an den räumlich nahesten accesspoint gebunden werden.

VG,
Dirk

[MadMax-FHEM]

Moin Joachim,

wieder mal was dazugelernt. Mit readingsgroup habe ich bisher noch nicht viel gemacht.

Nabend Dirk,

oh, freut  mich!

Ist aber inhaltlich sehr speziell, oder?

Jep, mag sein...
Aber ich hatte das so geplant als ich mir die APs besorgt und "verteilt" hab...
Und so speziell scheint es nicht zu sein, die APs hatten das Feature mal, wurde aber wohl wieder "ausgebaut" und von einigen "beklagt" (Unifi-Foren)...

Dein Ansinnen ist, sofern ich es richtig verstanden habe, dass stationäre WLAN-Clients immer das beste WLAN für sie nutzen. Und daher sollen sie an den räumlich nahesten accesspoint gebunden werden.

Exakt!
Wie geschrieben gab es das Feature wohl mal...
Und meistens halten sich die Clients ja an den Plan...
...aber ab und an ist halt einer "verwirrt"...

Und jetzt sehe ich es sofort (rotes Icon) und kann es (wenn ich möchte) einfach "korrigieren": Klick auf's Icon...

Wie gesagt ich habe überlegt von Liste von Clients pro AP fix im Code auf Attribut beim Client zu wechseln, also ein Attribut preferredAPs "irgendwas separierte Liste" mit bevorzugtem/bevorzugten AP/APs...
(also per userattr)

Evtl. baue ich auch noch ohne readingsGroup, also "vollautomatisch"...
...war ja der eigentliche Plan...

Gruß und danke für die Module, Joachim

[onkel-tobi]

Also ich nutze das Modul um festzustellen, ob geschlafen wird /gotosleep oder aber eben man aufgestanden ist.
Abhängig davon verschicke ich Termine für den nächsten Tag per Telegram und stelle die Dachfenster in Schlafstellung.

Das ganze klappt ganz ok, da ich 2 APs habe (1 im EG, 1 im DG), sodass das für meinen usecase eben passt.

Bei Bedarf kann ich die codes am WE mal posten.

Gruß,
Tobi

[JHo]

@Tobi: bitte mach das! Gerne auch mit ein paar Sätzen zur Erläuterung...

Viele Grüße
Jan