Unifi

An dieser Seite wird momentan noch gearbeitet.

Unifi
Zweck / Funktion
Steuerung des Unifi-Controllers über FHEM
Allgemein
Typ	Gerätemodul
Details
Dokumentation	EN / DE
Support (Forum)	Automatisierung
Modulname	74_Unifi.pm
Ersteller	Wuehler (Forum / Wiki)
Wichtig: sofern vorhanden, gilt im Zweifel immer die (englische) Beschreibung in der commandref!

Das Modul Unifi ermöglicht die Steuerung eines Unifi-Controllers durch FHEM. Wenn durch den Unifi-Controller auch ein UnifiSwitch verwaltet wird, so legt das Modul bei aktiviertem autocreate UnifiSwitch-Devices an.

Voraussetzungen

Unifi-Controller

Es wird eine dauerhaft laufende Unifi-Controller-Software benötigt. Diese kann z.B. auf dem Unifi-Cloud-Key oder selbst installiert z.B. auf einem RaspberryPi laufen.

Definition

Die Definition erfolgt mittels define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID>]] . Dabei ist folgendes zu beachten:

• ip: Der Unifi-Controller muss eine feste IP-Adresse haben
• port: port der Adminkonsole des Unifi-Controllers. In der Regel 8443 oder 443.
• username/passwort: Entweder der Standardmäßig angelegt Admin des Unifi-Controllers, oder besser ein im Unifi-Controller angelegter eigener User, unter setings-> admins -> add new admin
• interval: Gibt die Zeit in Sekunden an, nach der das Modul erneut die Daten beim Unifi-Controller abfragt. Default: 30 Sekunden. Es ist darauf zu achten, dass das Intervall groß genug ist, so dass auch unter Last nicht vor Ende eines Update-Zyklus ein neuer Update-Zyklus gestartet wird. Dies kann zum Beispiel passieren, wenn FHEM und der Unifi-Controller auf demselben RaspberryPi laufen (interval dann zB auf 90 setzen).
• siteID: Üblicherweise und als Default default

Damit ist die Installation abgeschlossen. Nach kurzer Zeit sollten die ersten Readings angezeigt werden.

Anwendung

Readings

Details siehe Siehe commandref/Unifi

Attribut customClientReadings

Mit dem Attribut customClientReadings können die Readings für Clients individualisiert werden:

• Der state eines clients kann nicht entfernt werden. D.h. für jeden client wird es ein Reading <clientName> geben, dass entweder den Wert connected oder disconnected hat.
• Es werden die Daten, die der Unifi-Controller zu den Clients vorhält 1:1 als Readings zur Verügung gestellt.
• Zusätzlich stehen mit dem Präfix _f_ versehen formatierte Werte als Reading zur Verfügung.
• Wenn der Unifi-Controller einen Wert nicht liefert, so wird auch kein Reading angelegt, selbst wenn dies im Attribut customClientReadings explizit angegeben wird.

Bei der Verwendung des Attributes gibt es teilweise Abweichungen vom Standardverhalten, die bei einer nachträglichen Verwendung des Attributes ggf. berücksichtigt werden müssen:

• Das Reading <clientName>_last_seen wird nicht als Datum formatiert dargestellt, sondern wie vom Unifi-Controller zurückgegeben als Unix-Timestamp.
• Das Reading <clientName>_hostname kann ggf. auch fehlen. Ohne das Attribut customClientReadings wird bei fehlendem hostname die ip oder "unknown" angezeigt.
• Das Readings <clientName>_snr entfällt und lautet <clientName>_rssi.

Beispiele:

• .:^mac$ : Stellt für alle Clients zusätzlich ein Reading mit der mac-Adresse zur Verfügung
• .:^mac$|^uptime$ : Stellt für alle Clients zusätzlich ein Reading mit der mac-Adresse und ein Reading mit der uptime (Unix-Timestamp) zur Verfügung
• ^meinTelefon$:^mac$ : Stellt nur für den Client mit dem Namen "meinTelefon" ein zusätzliches Reading mit der mac-Adresse zur Verfügung
• ^meinTelefon$:^mac$ ^seinTelefon$:^mac$ : Stellt nur für die Clients mit dem Namen "meinTelefon" oder "seinTelefon" ein zusätzliches Reading mit der mac-Adresse zur Verfügung
• einTelefon$:^mac$:^mac$ : Stellt für alle Clients, die auf "einTelefon" enden im Client-Namen haben die mac-Adresse zusätzlich zur Verfügung
• .:uptime : Stellt für alle Clients zusätzlich einige Readings zur Verfügung, die "uptime" im Namen enthalten. Darunter sind auch formatierte ptimes.

Anwesenheitserkennung

Üblicherweise: siehe PRESENCE

Todo: weitere Varianten?

Voucher

Das Modul kann automatisiert immer eine ausreichende Anzahl an Voucher-Nummern für den Zugang in ein per GuestPortal mit Voucherzugang konfiguriertes WLAN bereithalten. Dazu wird das Attribut voucherCache genutzt. Mit Komma separiert können mehrere Vouchercaches angegeben werden. Je Vouchercache werden vier Attribute mit Leerzeichen getrennt mitgegeben:

• expire: Ablaufzeit des Vouchers in Minuten
• quota: Anzahl der Voucher, die mindestens vorgehalten werden (sinnvoller Wert ist >=2)
• n: Gibt an, wie oft ein einzelner Voucher genutzt werden kann (sinnvoll ist in der Regel der Wert 1)
• note: der Name des Vouchers. Er darf keine Leerzeichen enthalten und kann z.B. bei einer Auswahl in ftui angezeigt werden.

Je Vouchercache wird ein Reading -VC_<note> mit dem nächsten noch nicht bzw. am längsten nicht angeforderten Voucher zur Verfügung gestellt. Wenn weniger als "quota"-Voucher zur Verfügung stehen werden "quota" neue Voucher erstellt. Die Maximalanzahl an vorgehaltenen Vouchern beträgt als 2*quota-1.

Voucherverwendung aufzeichnen

Dies geschieht außerhalb des Moduls mit einem dummy und wird in den weiteren Beispielen mit verwendet:

defmod voucherComment dummy
attr voucherComment event-on-change-reading comment
attr voucherComment readingList comment
attr voucherComment setList comment

Über eine ReadingsHistory kann dies festgehalten werden:

defmod voucherCacheRH readingsHistory voucherComment:comment
attr voucherCacheRH nolinks 1
attr voucherCacheRH rows 10
attr voucherCacheRH timestampFormat %Y.%m.%d_%H:%M:%S

Und/oder in einem Log speichern:

defmod voucherCommentLog FileLog ./log/voucher.log voucherComment:.*

Voucher bereitstellen

Die Beispiele gehen davon aus, dass auch die Verwendung aufgezeichnet werden soll

über Telegram

Voraussetzung in diesem Beispiel ist, dass das Modul msgDialog eingerichtet ist und ein VoucherCache mit der note "2h" konfiguriert wurde:

defmod voucher_Dialog msgDialog {\
  "Voucher": {\
    "commands": [\
      "{fhem('set voucherComment comment '.ReadingsVal('Unifi','-VC_2h','').' (2h): $recipient')}"\
    ],\
    "message": "{return('Code: '.fhem('get Unifi voucher 2h'))}"\
  }\
}

in FTUI

Im head der Seite wird folgender code benötigt:

    <script>
      var oldcode=0;
      function setComment(){
        var code =document.getElementById('voucherCode').children[0].value;
        if(oldcode!=code){
          oldcode=code;
          ftui.sendFhemCommand('get Unifi voucher ' + document.getElementById('voucherCacheNote').children[0].children[0].options.item(document.getElementById('voucherCacheNote').children[0].children[0].selectedIndex).text);     
          ftui.sendFhemCommand('set voucherComment comment ' + code +' ('+document.getElementById('voucherCacheNote').children[0].children[0].options.item(document.getElementById('voucherCacheNote').children[0].children[0].selectedIndex).text+'): '+document.getElementById('comment').children[0].value);
        }
      }
    </script>

Im body der Seite kann der folgende code verwendet werden. Es wird vorausgesetzt, dass es Vouchercaches mit der note 2h und 3h gibt.

FTUI-Darstellung

<li data-row="18" data-col="1" data-sizex="2" data-sizey="3" class="semitransparent">
  <header>Voucher</header>
  Typ:
  <div data-type="select" data-items='["-VC_2h","-VC_3h"]' data-alias='["2h","3h"]' id="voucherCacheNote" class="notransmit w3x"></div>
  Kommentar:
  <div data-type="input"
    id="comment"
    class="notransmit"></div>
  Code: 
  <div data-type="input"
    data-device="Unifi"  
    data-get="#voucherCacheNote"
    id="voucherCode"
    class="notransmit w3x"></div>
  <div data-type="link"
    class="round notransmit"
    onclick="setComment()">
   Save</div>
</li> 

Erkennung neuer clients

Kleines DOIF mit Telegram-Benachrichtigung:

defmod di_newClients DOIF ([Unifi:-UC_newClients] ne "" ) (set Telegram message unbekannter WLAN Zugriff:[Unifi:-UC_newClients])