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

[Wuehler]

Moin,

Bei mir machen die vorangestellten Bindestriche kein Problem.

Code Auswählen Erweitern


attr Unifi stateFormat {ReadingsVal("Unifi","-UC_wan_ip","");;}

Zeigt zB die Wan IP im state an.
Wie sieht dein Code denn aus?

Grüße,
Dirk

[Wolle02]

Na ich hab halt einfach die Readingsnamen eingegeben; funktioniert mit normalen Readings auch problemlos.
Auf die Idee es mit PerlCode oder Userreadings zu machen, bin ich zugegebener maßen gar nicht gekommen. Wenn man die CommandRef liest, ist die Primärfunktion ja auch diese:

[Es] werden alle Wörter im Wert des Attributes durch das entsprechende Reading des Gerätes ersetzt (soweit vorhanden).

Aber wie immer führen mehrere Wege zum Ziel. Wenn man denn die Idee dazu hat.

Gruß
Wolle

[Wuehler]

Hi Wolle,

Die Primärfunktion kannte ich wiederum nicht. Nutze das selten und wenn dann sind da immer noch Formeln oder Konditionen drin.

VG,
Dirk

[tomster]

Serfvus beisammen!

Mal eine Frage, deren Antwort mir auch über die Suchfunktion leider noch nicht zu Teil wurde:

Kann man die abgefragten Readings der jeweilig angemeldeten Endgeräte im Modul irgendwie erweitern (z.B. um die MAC-Adresse)?
Mein Problem ist, dass sich bei mir gelegentlich Geräte anmelden die dummerweise den gleichen Namen haben. Neulich hatte ich, nebem dem Gerät meiner Tochter noch 2 weitere "iPhone" in der Liste. Dadurch kann ich natürlich keine wirkliche Unterscheidung nach Gerät vornehmen und meine Presence-Erkennung wird dementsprechend "unscharf".
Hat jemand einen Tipp für mich?

[l2r]

hi du kannst mit dem Attribut devAlias dir für jedes Gerät einen Alias anlegen, welcher dann wieder die 7 Readings für pro Alias erzeugt. Den Alias machst du an der Geräte-ID fest. (kriegst du über get ClientData all raus.)

Läuft bei mir einwandfrei.

Gruß Michael

[sledge]

Darüberhinaus bietet es sich an, im UNIFI-Controller dem iphone Deiner Tochter einen Alias / Namen zu verpassen, das macht es deutlich einfacher. Die "fremden" Geräte brnötigst Du ja nicht zur Presence-Erkennung.

[tomster]

Danke für den Tipp, aber das muss ich dann für jedes Gerät manuell machen. Kommt dann aber das näxte "iPhone" daher, muss ich das wieder eintragen. Wenn es aber ein Reading der Device-ID oder MAC gäbe, wären diese "Nachhaltungen" der Alias-Liste nicht notwendig, oder?

--edit--ok, überredet. Nach nochmaligem Nachdenken hab ich Euch jetzt verstanden.

[sledge]

Danke für den Tipp, aber das muss ich dann für jedes Gerät manuell machen. Kommt dann aber das näxte "iPhone" daher, muss ich das wieder eintragen. Wenn es aber ein Reading der Device-ID oder MAC gäbe, wären diese "Nachhaltungen" der Alias-Liste nicht notwendig, oder?

--edit--ok, überredet. Nach nochmaligem Nachdenken hab ich Euch jetzt verstanden.

Wobei das jetzt zwei unterschiedliche Vorschläge waren.

Der von l2r wird primär im FHEM umgesetzt, meiner besteht erstmal darin, den Devices im Unifi-Controller sprechende Namen zu geben. Gerade bei einigen Android-Devices ist das zwingend erforderlich

[Wuehler]

Hallo zusammen,

im nächsten Update habe ich die - schon lange mit Warnmeldungen versehenen - getter und setter zu den Switches ausgebaut. Falls das noch jemand nutzt bitte auf das Modul UnifiSwitch umstellen. Dort gibt es dieselben Funktionen.
Wenn es hier (und heute) keinen großen Einsprüche gibt lade ich die Änderungen morgen hoch, so dass sie am Montag im Update enthalten sind.

Ein erfolgreiches Wochenende,
Dirk

[Wuehler]

Morgen im Update eine neue Version des Unifi-Moduls. Folgende Funktionalitäten wurden entfernt:

Code Auswählen Erweitern


- set <name> poeMode <port-Nr> <state>
- get <name> poeState
- reading poeMode je Port

Alle Funktionen sind schon länger im per autocreate angelegten UnifiSwitch vorhanden.

[Phiolin]

Kann es sein, dass die Funktion "switchSiteLeds" nicht funktioniert? Hatte ich vorhin mal ausprobiert, aber die Einstellung im Unifi Controller ändert sich nicht (und die LEDs an den Geräten gehen auch nicht aus/an - klar). Kann das vielleicht jemand mal bei sich testen?

[stefanpf]

Gerade getestet - funktioniert hier auch nicht (mehr).

[Wuehler]

Moin,

Habe mir das gerade mal kurz angesehen und eine Vermutung woran es liegen kann. Komme aber frühestens Mittwoch dazu meine Vermutung zu überprüfen.
Falls ihr etwas perl könnt und vorher schon wollt:
Im Set-Zweig ,,switchSiteLeds" müsste ,,true" (inkl. Der Anführungszeichen) durch JSON::true ersetzt werden und ,,false" durch JSON::false. Ausserdem in der Funktion Unifi_SwitchSiteLEDs(..) die Anführungszeichen um den state entfernen.
Ich glaube die Unifi-API ist da genauer geworden und akzeptiert boolean in Anführungszeichen nicht mehr.
Viele Grüße,
Dirk

[Phiolin]

Ich habe das mal kurz ausprobiert, konnte aber keinen Erfolg verzeichnen.

Code Auswählen Erweitern

2019.03.04 09:57:32 5: unifi: set called with switchSiteLEDs off
2019.03.04 09:57:32 4: unifi: set switchSiteLEDs
2019.03.04 09:57:32 2: unifi: deprecated use of Attribute 'deprecatedClientNames' (see commandref for details).
2019.03.04 09:57:32 5: unifi (Unifi_SwitchSiteLEDs_Send) - executed with command: '0'
2019.03.04 09:57:32 5: unifi (Unifi_SwitchSiteLEDs_Send) - URL: https://xyz:8443/api/s/default/set/setting/mgmt
2019.03.04 09:57:32 5: unifi (Unifi_SwitchSiteLEDs_Receive) - executed.
2019.03.04 09:57:32 5: unifi (Unifi_SwitchSiteLEDs_Receive) - state:'ok'

Zwar bekomme ich offenbar ein "ok" zurück, aber die Einstellung selber ändert sich im Controller nicht.


Folgendes hatte ich geändert:

Code Auswählen Erweitern

--- 74_Unifi.pm.orig    2019-03-04 09:40:35.306823627 +0100
+++ 74_Unifi.pm 2019-03-04 09:47:59.868463744 +0100
@@ -298,9 +298,9 @@
                 }
             }
             elsif ($setName eq 'switchSiteLEDs') {
-                my $state="true";
+                my $state= JSON::true;
                 if ($setVal && $setVal eq 'off') {
-                    $state="false";
+                    $state= JSON::false;
                 }
                 Unifi_SwitchSiteLEDs_Send($hash,$state);
             }
@@ -1500,6 +1500,7 @@
   my ($hash,$state) = @_;
   my ($name,$self) = ($hash->{NAME},Unifi_Whoami());
   Log3 $name, 5, "$name ($self) - executed with command: '".$state."'";
+  Log3 $name, 5, "$name ($self) - URL: ".$hash->{unifi}->{url}."set/setting/mgmt";

   HttpUtils_NonblockingGet( {
     %{$hash->{httpParams}},


Anführungszeichen um "state" waren in der Funktion Unifi_SwitchSiteLEDs nicht vorhanden, mussten also wohl auch nicht entfernt werden.

Code Auswählen Erweitern

  HttpUtils_NonblockingGet( {
    %{$hash->{httpParams}},
    url   => $hash->{unifi}->{url}."set/setting/mgmt",
    callback => \&Unifi_SwitchSiteLEDs_Receive,
    data => "{'led_enabled': ".$state."}",
  } ); 

[f-zappa]

Moin erst mal! Ich habe seit ein paar Tagen den ersten UniFi-AP in Betrieb genommen. Mein WLAN läuft jetzt erheblich stabiler, darum wird auch noch ein zweiter AP kommen. Danke für das Modul, mit dem ich UniFi direkt in FHEM einbinden konnte!

Kann man die abgefragten Readings der jeweilig angemeldeten Endgeräte im Modul irgendwie erweitern (z.B. um die MAC-Adresse)?

Das habe ich auch vermisst. Klar kann man, da war nur eine Zeile zu kopieren und leicht anzupassen. Ich komm gerade nicht an mein System, kann das aber noch nachliefern. Das selbst zu modifizieren ist natürlich unelegant, entweder nimmt man das Modul von Updates aus oder man editiert nach jedem Update.

Was ich mich aber gefragt habe: Warum liefert das Modul das nicht gleich mit? Wir reden hier über physikalische Geräte, und die kann man nun einmal am besten anhand ihrer physikalischen Adresse identifizieren. Wie viel Schall und Rauch hingegen Namen sind, sieht man ja am UniFi-Controller. Das Ding macht bescheuerterweise keine DNS-Abfrage (damit könnte ich einigermaßen leben), würfelt sich aber selbst (teilweise Phantasie-) Namen zB aus mDNS-Abfragen und vermutlich noch weiteren Quellen zusammen. Ja, ich könnte manuell Namen in UniFi pflegen, aber das mache ich schon an anderer Stelle und will keine redundante Datenhaltung.

Ich habe den Thread ein wenig überflogen - offenbar argumentiert Dirk, dass er aufgrund der Menge nicht noch weitere Readings hinzufügen möchte. Das ist ein verständliches Argument. Auf der anderen Seite braucht aber vielleicht auch nicht jeder die jetzt vorhandenen Readings (ich würde zB nur die MAC und connected/disconnected benötigen).  Warum also nicht den Nutzer entscheiden lassen, welche Readings er will? Man könnte doch in einem Attribut "customReadings" eine Liste hinterlegen, welche vom Controller gelieferten Werte man als Readings will (zB customReadings="mac satisfaction"). Und wenn das Reading nicht gesetzt ist, kann sich das Modul ja so verhalten wie bisher, dann wäre auch die Rückwärtskompatibilität da.

Wo ich gerade schon so schön träume .. als weiteres Attribut wäre "customNames" eine feine Sache. Dann könnte sich jeder aussuchen, ob die Basisnamen der Readings aus der MAC, der IP oder auch dem bisherigen von UniFi ausgedachten Namen abgeleitet werden ...

Gruß, Uli