FHEMWiki - Benutzerbeiträge [de]

Unifi

2020-11-22T21:01:59Z

Wuehler: /* Erkennung neuer clients: Beispiel um SSID und AP erweitert*/

{{Infobox Modul
|ModPurpose=Steuerung des Unifi-Controllers über FHEM
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=74_Unifi.pm
|ModOwner=Wuehler ({{Link2FU|Wuehler|Forum}} / [[Benutzer Diskussion:Wuehler|Wiki]])}}

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.
Ausserdem gibt es das Unterstützungsmodul [[UnifiClient]], welches alle vorhandenen Informationen zu Clients als Reading bereitstellt und clientspezifische Funktionen zur Verfügung stellt.

== 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 <code>define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID>]] </code>.
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/password: Username und Passwort eines Unifi-Controller-Users (siehe [[Unifi#Unifi-User|Unifi-User]])
* 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 <code>default</code>

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

=== Unifi-User ===
Bei der Definition des Moduls werden username und passwort mit angegeben. Entweder wird der standardmäßig angelegte Admin des Unifi-Controllers, oder besser ein im Unifi-Controller angelegter eigener User (unter <code>settings-> admins -> add new admin</code>) genutzt. Wenn ein neuer User angelegt wird kann dieser z.B. auch ausschließlich read-only-Berechtigungen bekommen. Dies reicht für die Grundfunktion des Unifi-Moduls )Informationen auslesen und in Readings darstellen) aus. Alle set-Funktionen (Ausnahmen: clear, update und updateClient) sowie das Attribut voucherCache benötigen schreibende Rechte im Unifi-Controller .

== Anwendung ==
=== Readings ===
Details siehe Siehe {{Link2CmdRef|Lang=en|Anker=Unifi}}

==== Attribut customClientReadings ====
Mit dem Attribut <code>customClientReadings</code> können die Readings für Clients individualisiert werden. Eine Liste der möglichen Readings erhält man mittels <code>get <unifi> clientData all</code>.
* Der state eines clients kann nicht entfernt werden. D.h. für jeden client wird es ein Reading <clientName> geben, das entweder den Wert <code>connected</code> oder <code>disconnected</code> hat.
* Es werden die Daten, die der Unifi-Controller zu den Clients vorhält 1:1 als Readings zur Verfü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 Reading <clientName>_snr entfällt und lautet <clientName>_rssi.

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

=== Anwesenheitserkennung ===
Üblicherweise: siehe [[PRESENCE#Beispiel_Anwesenheitserkennung_mittels_UniFi_Controller|PRESENCE]]

Oder falls man einen [[UnifiClient]] definiert hat:
<code>define <NAME> PRESENCE event <UnifiClientName>:fhem_state:.disconnected <UnifiClientName>:fhem_state:.connected</code>

=== 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 <code>voucherCache</code> 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:
<pre>defmod voucherComment dummy
attr voucherComment event-on-change-reading comment
attr voucherComment readingList comment
attr voucherComment setList comment</pre>

Über eine ReadingsHistory kann dies festgehalten werden:
<pre>defmod voucherCacheRH readingsHistory voucherComment:comment
attr voucherCacheRH nolinks 1
attr voucherCacheRH rows 10
attr voucherCacheRH timestampFormat %Y.%m.%d_%H:%M:%S</pre>

Und/oder in einem Log speichern:
<pre>defmod voucherCommentLog FileLog ./log/voucher.log voucherComment:.*</pre>

==== 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:
<pre>defmod voucher_Dialog msgDialog {\
"Voucher": {\
"commands": [\
"{fhem('set voucherComment comment '.ReadingsVal('Unifi','-VC_2h','').' (2h): $recipient')}"\
],\
"message": "{return('Code: '.fhem('get Unifi voucher 2h'))}"\
}\
}</pre>

===== in FTUI =====
Im head der Seite wird folgender code benötigt:
<source lang="html">
<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>
</source>

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

[[Datei:ftui_vouchercache.png|thumb|FTUI-Darstellung]]
<source lang="html">
<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>
</source>

=== Erkennung neuer clients ===
Kleines DOIF mit [[TelegramBot|Telegram]]-Benachrichtigung:
<pre>defmod di_newClients DOIF ([Unifi:-UC_newClients] ne "" ) (set Telegram message unbekannter WLAN Zugriff:[Unifi:-UC_newClients])</pre>Mit zusätzlichen Infos zu SSID und AP:<syntaxhighlight>
defmod UniFi_new_Client DOIF ([UniFi:-UC_newClients] ne "" )\
{my $host = ReadingsVal("UniFi","-UC_newClients","--");; ## einlesen Hostname neuer WLAN Client\
my $readingSSID = ReadingsVal("UniFi",$host."_essid","--");; ## bauen Reading SSID\
my $readingAP = ReadingsVal("UniFi",$host."_accesspoint","--");; ## bauen Reading AP\
my $text = "Neuer WLAN Zugriff von ".$host." über ".$readingAP." an ".$readingSSID;; ## vorbereiten Text\
fhem("set TelegramBot msg $text")} ## Telegram senden
</syntaxhighlight>

=== Funkscan mit startRFScan ===
Die Accesspoints von Unifi erlauben eine automatische Kanalwahl.

Besonders dann, wenn der Funkraum mit vielen verschiedenen WLAN-Geräten belegt ist, ist die Auswahl des richtigen Kanals für einen stabilen Funkempfang wichtig. Um den richtigen Kanal zu wählen, sollte aber der vorhandene Funkraum vorher analysiert werden. Unifi erlaubt dies durch den so genannten RFScan, der für jeden einzelnen Accesspoint aufgerufen werden kann (und der dann für die Zeit des Scan von ca 5 Minuten offline ist).

Im Modul wird der Funkscann durch den Befehl
<pre>set <UnifiModulname> setRFScan <APName></pre>
sofort ausgelöst. Wenn beispielsweise bei zwei Accesspoints mit den Namen Arbeitszimmer und Keller jeweils Montag Nacht ein Scan ausgelöst werden soll, kann dies mit folgendem DOIF geschehen:

<pre>defmod MeinScan DOIF ([02:55|Mo]) (set Unifi startRFScan Keller) DOELSEIF ([03:10|Mo]) (set Unifi startRFScan Arbeitszimmer) </pre>

== FAQ ==
=== Warum enthält die DropDown-Liste einiger set-/get-Funktionen nicht alle Clients? ===
Vom UnifiController werden nur die Geräte mitgesendet, die connected sind / die im UnifiController auf der Seite Clients angezeigt werden. Clients, die connected waren, es aber nicht mehr sind - im UnifiController auf der Seite Insights - werden vom Modul aktuell nicht ausgelesen.
Edit: Seid März 2019 wird versucht auch disconnected clients nach einem Neustart aus den Readings wiederherzustellen. Damit sollten die clients in den DropDowns vollständig sein.

[[Kategorie:Other Components]]
[[Kategorie:IP Components]]
[[Kategorie:Code Snippets]]

UnifiClient

2019-06-03T18:22:07Z

Wuehler: /* Anwesenheitserkennung */ Erweiterung des presence-Readings auf wired-Abfrage

{{Infobox Modul
|ModPurpose=Steuerung von Unifi-Clients über FHEM
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=74_UnifiClient.pm
|ModOwner=Wuehler ({{Link2FU|Wuehler|Forum}} / [[Benutzer Diskussion:Wuehler|Wiki]])}}

Das Modul [[UnifiClient]] 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.
Ausserdem gibt es das Unterstützungsmodul [[UnifiClient]], welches alle vorhandenen Informationen zu Clients als Reading bereitstellt und clientspezifische Funktionen zur Verfügung stellt.

== Voraussetzungen ==
=== UnifiModul-Device ===
Es wird ein [[Unifi]]-Device (als IODev) benötigt.

=== Definition ===
Die Definition erfolgt mittels <code>define <name> UnifiClient <clientname in Unifi-Modul> </code>.

== Anwendung ==
Aufgrund der großen Anzahl an Readings bietet es sich an, die Events mittels Attribut <code>event-on-change-reading</code> einzuschränken.
=== Online-Zeitsteuerung ===
Das Modul versucht die Onlinezeit eines Clients zu berechnen und stellt Attribute bereit, um den client nach dem Verbrauch der Online-Zeit (Attribut maxOnlineMinutesPerDay) entweder zu blocken (default; Achtung Provisionierung) oder in eine andere Usergroup zu verschieben (Attribut blockingUsergroup; ohne Provisionierung).
Mit dem Attribut treshholdBytesPerMinute kann die Menge an bytes angegeben werden, die ein Client ohne Anrechnung auf die Onlinezeit verbrauchen darf.
Es bietet sich folgendes stateFormat an:
<pre>
{ ReadingsVal("$name","fhem_usedOnlineTime","? Minuten")." / ".ReadingsVal("$name","_f_usergroup_name","? Minuten")." / ".((ReadingsVal("$name","blocked","?") eq "true") ? "blocked":ReadingsVal("$name","fhem_state","?"))}
</pre>

=== Anwesenheitserkennung ===
Mittels [[PRESENCE]]:
<code>define <NAME> PRESENCE event <UnifiClientName>:fhem_state:.disconnected <UnifiClientName>:fhem_state:.connected</code>

Oder bei Verwendung von ROOMMATE ohne eigenes PRESENCE-Device per userReadings. Da beim verlassen des WLANs das Handy oft als "wired" an den USG o.ä. "übergeben" wird, mit einer zusätzlichen Abfrage auf <code>is_wired</code>:
<pre>
attr <UnifiClientName> userReadings presence {((ReadingsVal("$name","is_wired","?") eq "true") ? "absent" : ((ReadingsVal("$name","fhem_state","?") eq "connected") ? "present":"absent"));;}

und im Roommate:
attr <myRoommate> rr_presenceDevice <UnifiClientName>
</pre>

Um die Ressourcennutzung des Unifi-Moduls zu reduzieren kann man im DEF des Unifi-Devices das Update-Intervall hoch setzen und nur einzelne Clients mittels at einzeln updaten:
<pre>defmod updateUnifiClients at +*00:00:10 {\
fhem("set clientName1 update");;\
fhem("set clientName2 update");;\
}</pre>

UnifiClient

2019-05-30T09:24:31Z

Wuehler: /* Anwesenheitserkennung */

{{Infobox Modul
|ModPurpose=Steuerung von Unifi-Clients über FHEM
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=74_UnifiClient.pm
|ModOwner=Wuehler ({{Link2FU|Wuehler|Forum}} / [[Benutzer Diskussion:Wuehler|Wiki]])}}

Das Modul [[UnifiClient]] 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.
Ausserdem gibt es das Unterstützungsmodul [[UnifiClient]], welches alle vorhandenen Informationen zu Clients als Reading bereitstellt und clientspezifische Funktionen zur Verfügung stellt.

== Voraussetzungen ==
=== UnifiModul-Device ===
Es wird ein [[Unifi]]-Device (als IODev) benötigt.

=== Definition ===
Die Definition erfolgt mittels <code>define <name> UnifiClient <clientname in Unifi-Modul> </code>.

== Anwendung ==
Aufgrund der großen Anzahl an Readings bietet es sich an, die Events mittels Attribut <code>event-on-change-reading</code> einzuschränken.
=== Online-Zeitsteuerung ===
Das Modul versucht die Onlinezeit eines Clients zu berechnen und stellt Attribute bereit, um den client nach dem Verbrauch der Online-Zeit (Attribut maxOnlineMinutesPerDay) entweder zu blocken (default; Achtung Provisionierung) oder in eine andere Usergroup zu verschieben (Attribut blockingUsergroup; ohne Provisionierung).
Mit dem Attribut treshholdBytesPerMinute kann die Menge an bytes angegeben werden, die ein Client ohne Anrechnung auf die Onlinezeit verbrauchen darf.
Es bietet sich folgendes stateFormat an:
<pre>
{ ReadingsVal("$name","fhem_usedOnlineTime","? Minuten")." / ".ReadingsVal("$name","_f_usergroup_name","? Minuten")." / ".((ReadingsVal("$name","blocked","?") eq "true") ? "blocked":ReadingsVal("$name","fhem_state","?"))}
</pre>

=== Anwesenheitserkennung ===
Mittels [[PRESENCE]]:
<code>define <NAME> PRESENCE event <UnifiClientName>:fhem_state:.disconnected <UnifiClientName>:fhem_state:.connected</code>

Oder bei Verwendung von ROOMMATE ohne eigenes PRESENCE-Device per userReadings:
<pre>
attr <UnifiClientName> userReadings presence {((ReadingsVal("$name","fhem_state","?") eq "connected") ? "present":"absent");;}

und im Roommate:
attr <myRoommate> rr_presenceDevice <UnifiClientName>
</pre>

Um die Ressourcennutzung des Unifi-Moduls zu reduzieren kann man im DEF des Unifi-Devices das Update-Intervall hoch setzen und nur einzelne Clients mittels at einzeln updaten:
<pre>defmod updateUnifiClients at +*00:00:10 {\
fhem("set clientName1 update");;\
fhem("set clientName2 update");;\
}</pre>

UnifiClient

2019-05-20T20:22:16Z

Wuehler: /* Anwendung */

{{Infobox Modul
|ModPurpose=Steuerung von Unifi-Clients über FHEM
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=74_UnifiClient.pm
|ModOwner=Wuehler ({{Link2FU|Wuehler|Forum}} / [[Benutzer Diskussion:Wuehler|Wiki]])}}

Das Modul [[UnifiClient]] 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.
Ausserdem gibt es das Unterstützungsmodul [[UnifiClient]], welches alle vorhandenen Informationen zu Clients als Reading bereitstellt und clientspezifische Funktionen zur Verfügung stellt.

== Voraussetzungen ==
=== UnifiModul-Device ===
Es wird ein [[Unifi]]-Device (als IODev) benötigt.

=== Definition ===
Die Definition erfolgt mittels <code>define <name> UnifiClient <clientname in Unifi-Modul> </code>.

== Anwendung ==
Aufgrund der großen Anzahl an Readings bietet es sich an, die Events mittels Attribut <code>event-on-change-reading</code> einzuschränken.
=== Online-Zeitsteuerung ===
Das Modul versucht die Onlinezeit eines Clients zu berechnen und stellt Attribute bereit, um den client nach dem Verbrauch der Online-Zeit (Attribut maxOnlineMinutesPerDay) entweder zu blocken (default; Achtung Provisionierung) oder in eine andere Usergroup zu verschieben (Attribut blockingUsergroup; ohne Provisionierung).
Mit dem Attribut treshholdBytesPerMinute kann die Menge an bytes angegeben werden, die ein Client ohne Anrechnung auf die Onlinezeit verbrauchen darf.
Es bietet sich folgendes stateFormat an:
<pre>
{ ReadingsVal("$name","fhem_usedOnlineTime","? Minuten")." / ".ReadingsVal("$name","_f_usergroup_name","? Minuten")." / ".((ReadingsVal("$name","blocked","?") eq "true") ? "blocked":ReadingsVal("$name","fhem_state","?"))}
</pre>

=== Anwesenheitserkennung ===
Mittels [[PRESENCE]]:
<code>define <NAME> PRESENCE event <UnifiClientName>:fhem_state:.disconnected <UnifiClientName>:fhem_state:.connected</code>

Um die Ressourcennutzung des Unifi-Moduls zu reduzieren kann man im DEF des Unifi-Devices das Update-Intervall hoch setzen und nur einzelne Clients mittels at einzeln updaten:
<pre>defmod updateUnifiClients at +*00:00:10 {\
fhem("set clientName1 update");;\
fhem("set clientName2 update");;\
}</pre>

UnifiClient

2019-05-20T20:17:05Z

Wuehler: /* Online-Zeitsteuerung */

{{Infobox Modul
|ModPurpose=Steuerung von Unifi-Clients über FHEM
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=74_UnifiClient.pm
|ModOwner=Wuehler ({{Link2FU|Wuehler|Forum}} / [[Benutzer Diskussion:Wuehler|Wiki]])}}

Das Modul [[UnifiClient]] 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.
Ausserdem gibt es das Unterstützungsmodul [[UnifiClient]], welches alle vorhandenen Informationen zu Clients als Reading bereitstellt und clientspezifische Funktionen zur Verfügung stellt.

== Voraussetzungen ==
=== UnifiModul-Device ===
Es wird ein [[Unifi]]-Device (als IODev) benötigt.

=== Definition ===
Die Definition erfolgt mittels <code>define <name> UnifiClient <clientname in Unifi-Modul> </code>.

== Anwendung ==
=== Online-Zeitsteuerung ===
Das Modul versucht die Onlinezeit eines Clients zu berechnen und stellt Attribute bereit, um den client nach dem Verbrauch der Online-Zeit (Attribut maxOnlineMinutesPerDay) entweder zu blocken (default; Achtung Provisionierung) oder in eine andere Usergroup zu verschieben (Attribut blockingUsergroup; ohne Provisionierung).
Mit dem Attribut treshholdBytesPerMinute kann die Menge an bytes angegeben werden, die ein Client ohne Anrechnung auf die Onlinezeit verbrauchen darf.
Es bietet sich folgendes stateFormat an:
<pre>
{ ReadingsVal("$name","fhem_usedOnlineTime","? Minuten")." / ".ReadingsVal("$name","_f_usergroup_name","? Minuten")." / ".((ReadingsVal("$name","blocked","?") eq "true") ? "blocked":ReadingsVal("$name","fhem_state","?"))}
</pre>

=== Anwesenheitserkennung ===
Mittels [[PRESENCE]]:
<code>define <NAME> PRESENCE event <UnifiClientName>:fhem_state:.disconnected <UnifiClientName>:fhem_state:.connected</code>

Um die Ressourcennutzung des Unifi-Moduls zu reduzieren kann man im DEF des Unifi-Devices das Update-Intervall hoch setzen und nur einzelne Clients mittels at einzeln updaten:
<pre>defmod updateUnifiClients at +*00:00:10 {\
fhem("set clientName1 update");;\
fhem("set clientName2 update");;\
}</pre>

UnifiClient

2019-05-20T19:57:34Z

Wuehler: /* Anwesenheitserkennung */

UnifiClient

2019-05-20T19:53:48Z

Wuehler: /* Anwesenheitserkennung */

UnifiClient

2019-05-20T19:38:25Z

Wuehler: Die Seite wurde neu angelegt: „{{Infobox Modul |ModPurpose=Steuerung von Unifi-Clients über FHEM |ModType=d |ModForumArea=Automatisierung |ModTechName=74_UnifiClient.pm |ModOwner=Wuehler (…“

Unifi

2019-05-20T19:29:46Z

Wuehler:

{{Infobox Modul
|ModPurpose=Steuerung des Unifi-Controllers über FHEM
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=74_Unifi.pm
|ModOwner=Wuehler ({{Link2FU|Wuehler|Forum}} / [[Benutzer Diskussion:Wuehler|Wiki]])}}

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.
Ausserdem gibt es das Unterstützungsmodul [[UnifiClient]], welches alle vorhandenen Informationen zu Clients als Reading bereitstellt und clientspezifische Funktionen zur Verfügung stellt.

== 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 <code>define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID>]] </code>.
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/password: Username und Passwort eines Unifi-Controller-Users (siehe [[Unifi#Unifi-User|Unifi-User]])
* 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 <code>default</code>

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

=== Unifi-User ===
Bei der Definition des Moduls werden username und passwort mit angegeben. Entweder wird der standardmäßig angelegte Admin des Unifi-Controllers, oder besser ein im Unifi-Controller angelegter eigener User (unter <code>settings-> admins -> add new admin</code>) genutzt. Wenn ein neuer User angelegt wird kann dieser z.B. auch ausschließlich read-only-Berechtigungen bekommen. Dies reicht für die Grundfunktion des Unifi-Moduls )Informationen auslesen und in Readings darstellen) aus. Alle set-Funktionen (Ausnahmen: clear, update und updateClient) sowie das Attribut voucherCache benötigen schreibende Rechte im Unifi-Controller .

== Anwendung ==
=== Readings ===
Details siehe Siehe {{Link2CmdRef|Lang=en|Anker=Unifi}}

==== Attribut customClientReadings ====
Mit dem Attribut <code>customClientReadings</code> können die Readings für Clients individualisiert werden. Eine Liste der möglichen Readings erhält man mittels <code>get <unifi> clientData all</code>.
* Der state eines clients kann nicht entfernt werden. D.h. für jeden client wird es ein Reading <clientName> geben, das entweder den Wert <code>connected</code> oder <code>disconnected</code> hat.
* Es werden die Daten, die der Unifi-Controller zu den Clients vorhält 1:1 als Readings zur Verfü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 Reading <clientName>_snr entfällt und lautet <clientName>_rssi.

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

=== Anwesenheitserkennung ===
Üblicherweise: siehe [[PRESENCE#Beispiel_Anwesenheitserkennung_mittels_UniFi_Controller|PRESENCE]]

Oder falls man einen [[UnifiClient]] definiert hat:
<code>define <NAME> PRESENCE event <UnifiClientName>:fhem_state:.disconnected <UnifiClientName>:fhem_state:.connected</code>

=== 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 <code>voucherCache</code> 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:
<pre>defmod voucherComment dummy
attr voucherComment event-on-change-reading comment
attr voucherComment readingList comment
attr voucherComment setList comment</pre>

Über eine ReadingsHistory kann dies festgehalten werden:
<pre>defmod voucherCacheRH readingsHistory voucherComment:comment
attr voucherCacheRH nolinks 1
attr voucherCacheRH rows 10
attr voucherCacheRH timestampFormat %Y.%m.%d_%H:%M:%S</pre>

Und/oder in einem Log speichern:
<pre>defmod voucherCommentLog FileLog ./log/voucher.log voucherComment:.*</pre>

==== 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:
<pre>defmod voucher_Dialog msgDialog {\
"Voucher": {\
"commands": [\
"{fhem('set voucherComment comment '.ReadingsVal('Unifi','-VC_2h','').' (2h): $recipient')}"\
],\
"message": "{return('Code: '.fhem('get Unifi voucher 2h'))}"\
}\
}</pre>

===== in FTUI =====
Im head der Seite wird folgender code benötigt:
<source lang="html">
<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>
</source>

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

[[Datei:ftui_vouchercache.png|thumb|FTUI-Darstellung]]
<source lang="html">
<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>
</source>

=== Erkennung neuer clients ===
Kleines DOIF mit Telegram-Benachrichtigung:
<pre>defmod di_newClients DOIF ([Unifi:-UC_newClients] ne "" ) (set Telegram message unbekannter WLAN Zugriff:[Unifi:-UC_newClients])</pre>

== FAQ ==
=== Warum enthält die DropDown-Liste einiger set-/get-Funktionen nicht alle Clients? ===
Vom UnifiController werden nur die Geräte mitgesendet, die connected sind / die im UnifiController auf der Seite Clients angezeigt werden. Clients, die connected waren, es aber nicht mehr sind - im UnifiController auf der Seite Insights - werden vom Modul aktuell nicht ausgelesen.
Edit: Seid März 2019 wird versucht auch disconnected clients nach einem Neustart aus den Readings wiederherzustellen. Damit sollten die clients in den DropDowns vollständig sein.

[[Kategorie:Other Components]]
[[Kategorie:IP Components]]
[[Kategorie:Code Snippets]]

Unifi

2019-05-20T19:27:52Z

Wuehler: /* Anwesenheitserkennung */

{{Infobox Modul
|ModPurpose=Steuerung des Unifi-Controllers über FHEM
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=74_Unifi.pm
|ModOwner=Wuehler ({{Link2FU|Wuehler|Forum}} / [[Benutzer Diskussion:Wuehler|Wiki]])}}

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 <code>define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID>]] </code>.
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/password: Username und Passwort eines Unifi-Controller-Users (siehe [[Unifi#Unifi-User|Unifi-User]])
* 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 <code>default</code>

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

=== Unifi-User ===
Bei der Definition des Moduls werden username und passwort mit angegeben. Entweder wird der standardmäßig angelegte Admin des Unifi-Controllers, oder besser ein im Unifi-Controller angelegter eigener User (unter <code>settings-> admins -> add new admin</code>) genutzt. Wenn ein neuer User angelegt wird kann dieser z.B. auch ausschließlich read-only-Berechtigungen bekommen. Dies reicht für die Grundfunktion des Unifi-Moduls )Informationen auslesen und in Readings darstellen) aus. Alle set-Funktionen (Ausnahmen: clear, update und updateClient) sowie das Attribut voucherCache benötigen schreibende Rechte im Unifi-Controller .

== Anwendung ==
=== Readings ===
Details siehe Siehe {{Link2CmdRef|Lang=en|Anker=Unifi}}

==== Attribut customClientReadings ====
Mit dem Attribut <code>customClientReadings</code> können die Readings für Clients individualisiert werden. Eine Liste der möglichen Readings erhält man mittels <code>get <unifi> clientData all</code>.
* Der state eines clients kann nicht entfernt werden. D.h. für jeden client wird es ein Reading <clientName> geben, das entweder den Wert <code>connected</code> oder <code>disconnected</code> hat.
* Es werden die Daten, die der Unifi-Controller zu den Clients vorhält 1:1 als Readings zur Verfü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 Reading <clientName>_snr entfällt und lautet <clientName>_rssi.

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

=== Anwesenheitserkennung ===
Üblicherweise: siehe [[PRESENCE#Beispiel_Anwesenheitserkennung_mittels_UniFi_Controller|PRESENCE]]

Oder falls man einen [[UnifiClient]] definiert hat:
<code>define <NAME> PRESENCE event <UnifiClientName>:fhem_state:.disconnected <UnifiClientName>:fhem_state:.connected</code>

=== 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 <code>voucherCache</code> 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:
<pre>defmod voucherComment dummy
attr voucherComment event-on-change-reading comment
attr voucherComment readingList comment
attr voucherComment setList comment</pre>

Über eine ReadingsHistory kann dies festgehalten werden:
<pre>defmod voucherCacheRH readingsHistory voucherComment:comment
attr voucherCacheRH nolinks 1
attr voucherCacheRH rows 10
attr voucherCacheRH timestampFormat %Y.%m.%d_%H:%M:%S</pre>

Und/oder in einem Log speichern:
<pre>defmod voucherCommentLog FileLog ./log/voucher.log voucherComment:.*</pre>

==== 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:
<pre>defmod voucher_Dialog msgDialog {\
"Voucher": {\
"commands": [\
"{fhem('set voucherComment comment '.ReadingsVal('Unifi','-VC_2h','').' (2h): $recipient')}"\
],\
"message": "{return('Code: '.fhem('get Unifi voucher 2h'))}"\
}\
}</pre>

===== in FTUI =====
Im head der Seite wird folgender code benötigt:
<source lang="html">
<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>
</source>

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

[[Datei:ftui_vouchercache.png|thumb|FTUI-Darstellung]]
<source lang="html">
<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>
</source>

=== Erkennung neuer clients ===
Kleines DOIF mit Telegram-Benachrichtigung:
<pre>defmod di_newClients DOIF ([Unifi:-UC_newClients] ne "" ) (set Telegram message unbekannter WLAN Zugriff:[Unifi:-UC_newClients])</pre>

== FAQ ==
=== Warum enthält die DropDown-Liste einiger set-/get-Funktionen nicht alle Clients? ===
Vom UnifiController werden nur die Geräte mitgesendet, die connected sind / die im UnifiController auf der Seite Clients angezeigt werden. Clients, die connected waren, es aber nicht mehr sind - im UnifiController auf der Seite Insights - werden vom Modul aktuell nicht ausgelesen.
Edit: Seid März 2019 wird versucht auch disconnected clients nach einem Neustart aus den Readings wiederherzustellen. Damit sollten die clients in den DropDowns vollständig sein.

[[Kategorie:Other Components]]
[[Kategorie:IP Components]]
[[Kategorie:Code Snippets]]

Unifi

2019-05-20T19:27:04Z

Wuehler: /* Anwesenheitserkennung */

{{Infobox Modul
|ModPurpose=Steuerung des Unifi-Controllers über FHEM
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=74_Unifi.pm
|ModOwner=Wuehler ({{Link2FU|Wuehler|Forum}} / [[Benutzer Diskussion:Wuehler|Wiki]])}}

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 <code>define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID>]] </code>.
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/password: Username und Passwort eines Unifi-Controller-Users (siehe [[Unifi#Unifi-User|Unifi-User]])
* 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 <code>default</code>

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

=== Unifi-User ===
Bei der Definition des Moduls werden username und passwort mit angegeben. Entweder wird der standardmäßig angelegte Admin des Unifi-Controllers, oder besser ein im Unifi-Controller angelegter eigener User (unter <code>settings-> admins -> add new admin</code>) genutzt. Wenn ein neuer User angelegt wird kann dieser z.B. auch ausschließlich read-only-Berechtigungen bekommen. Dies reicht für die Grundfunktion des Unifi-Moduls )Informationen auslesen und in Readings darstellen) aus. Alle set-Funktionen (Ausnahmen: clear, update und updateClient) sowie das Attribut voucherCache benötigen schreibende Rechte im Unifi-Controller .

== Anwendung ==
=== Readings ===
Details siehe Siehe {{Link2CmdRef|Lang=en|Anker=Unifi}}

==== Attribut customClientReadings ====
Mit dem Attribut <code>customClientReadings</code> können die Readings für Clients individualisiert werden. Eine Liste der möglichen Readings erhält man mittels <code>get <unifi> clientData all</code>.
* Der state eines clients kann nicht entfernt werden. D.h. für jeden client wird es ein Reading <clientName> geben, das entweder den Wert <code>connected</code> oder <code>disconnected</code> hat.
* Es werden die Daten, die der Unifi-Controller zu den Clients vorhält 1:1 als Readings zur Verfü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 Reading <clientName>_snr entfällt und lautet <clientName>_rssi.

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

=== Anwesenheitserkennung ===
Üblicherweise: siehe [[PRESENCE#Beispiel_Anwesenheitserkennung_mittels_UniFi_Controller|PRESENCE]]

Oder falls man UnifiClients definiert hat:
<code>define <NAME> PRESENCE event <UnifiClientName>:fhem_state:.disconnected <UnifiClientName>:fhem_state:.connected</code>

=== 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 <code>voucherCache</code> 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:
<pre>defmod voucherComment dummy
attr voucherComment event-on-change-reading comment
attr voucherComment readingList comment
attr voucherComment setList comment</pre>

Über eine ReadingsHistory kann dies festgehalten werden:
<pre>defmod voucherCacheRH readingsHistory voucherComment:comment
attr voucherCacheRH nolinks 1
attr voucherCacheRH rows 10
attr voucherCacheRH timestampFormat %Y.%m.%d_%H:%M:%S</pre>

Und/oder in einem Log speichern:
<pre>defmod voucherCommentLog FileLog ./log/voucher.log voucherComment:.*</pre>

==== 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:
<pre>defmod voucher_Dialog msgDialog {\
"Voucher": {\
"commands": [\
"{fhem('set voucherComment comment '.ReadingsVal('Unifi','-VC_2h','').' (2h): $recipient')}"\
],\
"message": "{return('Code: '.fhem('get Unifi voucher 2h'))}"\
}\
}</pre>

===== in FTUI =====
Im head der Seite wird folgender code benötigt:
<source lang="html">
<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>
</source>

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

[[Datei:ftui_vouchercache.png|thumb|FTUI-Darstellung]]
<source lang="html">
<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>
</source>

=== Erkennung neuer clients ===
Kleines DOIF mit Telegram-Benachrichtigung:
<pre>defmod di_newClients DOIF ([Unifi:-UC_newClients] ne "" ) (set Telegram message unbekannter WLAN Zugriff:[Unifi:-UC_newClients])</pre>

== FAQ ==
=== Warum enthält die DropDown-Liste einiger set-/get-Funktionen nicht alle Clients? ===
Vom UnifiController werden nur die Geräte mitgesendet, die connected sind / die im UnifiController auf der Seite Clients angezeigt werden. Clients, die connected waren, es aber nicht mehr sind - im UnifiController auf der Seite Insights - werden vom Modul aktuell nicht ausgelesen.
Edit: Seid März 2019 wird versucht auch disconnected clients nach einem Neustart aus den Readings wiederherzustellen. Damit sollten die clients in den DropDowns vollständig sein.

[[Kategorie:Other Components]]
[[Kategorie:IP Components]]
[[Kategorie:Code Snippets]]

Unifi

2019-05-20T19:23:34Z

Wuehler: /* FAQ */ Wiederherstellung von disconnected clients beschrieben

{{Infobox Modul
|ModPurpose=Steuerung des Unifi-Controllers über FHEM
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=74_Unifi.pm
|ModOwner=Wuehler ({{Link2FU|Wuehler|Forum}} / [[Benutzer Diskussion:Wuehler|Wiki]])}}

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 <code>define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID>]] </code>.
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/password: Username und Passwort eines Unifi-Controller-Users (siehe [[Unifi#Unifi-User|Unifi-User]])
* 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 <code>default</code>

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

=== Unifi-User ===
Bei der Definition des Moduls werden username und passwort mit angegeben. Entweder wird der standardmäßig angelegte Admin des Unifi-Controllers, oder besser ein im Unifi-Controller angelegter eigener User (unter <code>settings-> admins -> add new admin</code>) genutzt. Wenn ein neuer User angelegt wird kann dieser z.B. auch ausschließlich read-only-Berechtigungen bekommen. Dies reicht für die Grundfunktion des Unifi-Moduls )Informationen auslesen und in Readings darstellen) aus. Alle set-Funktionen (Ausnahmen: clear, update und updateClient) sowie das Attribut voucherCache benötigen schreibende Rechte im Unifi-Controller .

== Anwendung ==
=== Readings ===
Details siehe Siehe {{Link2CmdRef|Lang=en|Anker=Unifi}}

==== Attribut customClientReadings ====
Mit dem Attribut <code>customClientReadings</code> können die Readings für Clients individualisiert werden. Eine Liste der möglichen Readings erhält man mittels <code>get <unifi> clientData all</code>.
* Der state eines clients kann nicht entfernt werden. D.h. für jeden client wird es ein Reading <clientName> geben, das entweder den Wert <code>connected</code> oder <code>disconnected</code> hat.
* Es werden die Daten, die der Unifi-Controller zu den Clients vorhält 1:1 als Readings zur Verfü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 Reading <clientName>_snr entfällt und lautet <clientName>_rssi.

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

=== Anwesenheitserkennung ===
Üblicherweise: siehe [[PRESENCE#Beispiel_Anwesenheitserkennung_mittels_UniFi_Controller|PRESENCE]]

=== 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 <code>voucherCache</code> 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:
<pre>defmod voucherComment dummy
attr voucherComment event-on-change-reading comment
attr voucherComment readingList comment
attr voucherComment setList comment</pre>

Über eine ReadingsHistory kann dies festgehalten werden:
<pre>defmod voucherCacheRH readingsHistory voucherComment:comment
attr voucherCacheRH nolinks 1
attr voucherCacheRH rows 10
attr voucherCacheRH timestampFormat %Y.%m.%d_%H:%M:%S</pre>

Und/oder in einem Log speichern:
<pre>defmod voucherCommentLog FileLog ./log/voucher.log voucherComment:.*</pre>

==== 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:
<pre>defmod voucher_Dialog msgDialog {\
"Voucher": {\
"commands": [\
"{fhem('set voucherComment comment '.ReadingsVal('Unifi','-VC_2h','').' (2h): $recipient')}"\
],\
"message": "{return('Code: '.fhem('get Unifi voucher 2h'))}"\
}\
}</pre>

===== in FTUI =====
Im head der Seite wird folgender code benötigt:
<source lang="html">
<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>
</source>

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

[[Datei:ftui_vouchercache.png|thumb|FTUI-Darstellung]]
<source lang="html">
<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>
</source>

=== Erkennung neuer clients ===
Kleines DOIF mit Telegram-Benachrichtigung:
<pre>defmod di_newClients DOIF ([Unifi:-UC_newClients] ne "" ) (set Telegram message unbekannter WLAN Zugriff:[Unifi:-UC_newClients])</pre>

== FAQ ==
=== Warum enthält die DropDown-Liste einiger set-/get-Funktionen nicht alle Clients? ===
Vom UnifiController werden nur die Geräte mitgesendet, die connected sind / die im UnifiController auf der Seite Clients angezeigt werden. Clients, die connected waren, es aber nicht mehr sind - im UnifiController auf der Seite Insights - werden vom Modul aktuell nicht ausgelesen.
Edit: Seid März 2019 wird versucht auch disconnected clients nach einem Neustart aus den Readings wiederherzustellen. Damit sollten die clients in den DropDowns vollständig sein.

[[Kategorie:Other Components]]
[[Kategorie:IP Components]]
[[Kategorie:Code Snippets]]

Unifi

2019-04-14T15:56:44Z

Wuehler: Baustelle entfernt

{{Infobox Modul
|ModPurpose=Steuerung des Unifi-Controllers über FHEM
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=74_Unifi.pm
|ModOwner=Wuehler ({{Link2FU|Wuehler|Forum}} / [[Benutzer Diskussion:Wuehler|Wiki]])}}

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 <code>define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID>]] </code>.
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/password: Username und Passwort eines Unifi-Controller-Users (siehe [[Unifi#Unifi-User|Unifi-User]])
* 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 <code>default</code>

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

=== Unifi-User ===
Bei der Definition des Moduls werden username und passwort mit angegeben. Entweder wird der standardmäßig angelegte Admin des Unifi-Controllers, oder besser ein im Unifi-Controller angelegter eigener User (unter <code>settings-> admins -> add new admin</code>) genutzt. Wenn ein neuer User angelegt wird kann dieser z.B. auch ausschließlich read-only-Berechtigungen bekommen. Dies reicht für die Grundfunktion des Unifi-Moduls )Informationen auslesen und in Readings darstellen) aus. Alle set-Funktionen (Ausnahmen: clear, update und updateClient) sowie das Attribut voucherCache benötigen schreibende Rechte im Unifi-Controller .

== Anwendung ==
=== Readings ===
Details siehe Siehe {{Link2CmdRef|Lang=en|Anker=Unifi}}

==== Attribut customClientReadings ====
Mit dem Attribut <code>customClientReadings</code> können die Readings für Clients individualisiert werden. Eine Liste der möglichen Readings erhält man mittels <code>get <unifi> clientData all</code>.
* Der state eines clients kann nicht entfernt werden. D.h. für jeden client wird es ein Reading <clientName> geben, das entweder den Wert <code>connected</code> oder <code>disconnected</code> hat.
* Es werden die Daten, die der Unifi-Controller zu den Clients vorhält 1:1 als Readings zur Verfü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 Reading <clientName>_snr entfällt und lautet <clientName>_rssi.

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

=== Anwesenheitserkennung ===
Üblicherweise: siehe [[PRESENCE#Beispiel_Anwesenheitserkennung_mittels_UniFi_Controller|PRESENCE]]

=== 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 <code>voucherCache</code> 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:
<pre>defmod voucherComment dummy
attr voucherComment event-on-change-reading comment
attr voucherComment readingList comment
attr voucherComment setList comment</pre>

Über eine ReadingsHistory kann dies festgehalten werden:
<pre>defmod voucherCacheRH readingsHistory voucherComment:comment
attr voucherCacheRH nolinks 1
attr voucherCacheRH rows 10
attr voucherCacheRH timestampFormat %Y.%m.%d_%H:%M:%S</pre>

Und/oder in einem Log speichern:
<pre>defmod voucherCommentLog FileLog ./log/voucher.log voucherComment:.*</pre>

==== 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:
<pre>defmod voucher_Dialog msgDialog {\
"Voucher": {\
"commands": [\
"{fhem('set voucherComment comment '.ReadingsVal('Unifi','-VC_2h','').' (2h): $recipient')}"\
],\
"message": "{return('Code: '.fhem('get Unifi voucher 2h'))}"\
}\
}</pre>

===== in FTUI =====
Im head der Seite wird folgender code benötigt:
<source lang="html">
<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>
</source>

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

[[Datei:ftui_vouchercache.png|thumb|FTUI-Darstellung]]
<source lang="html">
<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>
</source>

=== Erkennung neuer clients ===
Kleines DOIF mit Telegram-Benachrichtigung:
<pre>defmod di_newClients DOIF ([Unifi:-UC_newClients] ne "" ) (set Telegram message unbekannter WLAN Zugriff:[Unifi:-UC_newClients])</pre>

== FAQ ==
=== Warum enthält die DropDown-Liste einiger set-/get-Funktionen nicht alle Clients? ===
Vom UnifiController werden nur die Geräte mitgesendet, die connected sind / die im UnifiController auf der Seite Clients angezeigt werden. Clients, die connected waren, es aber nicht mehr sind - im UnifiController auf der Seite Insights - werden vom Modul aktuell nicht ausgelesen.

[[Kategorie:Other Components]]
[[Kategorie:IP Components]]
[[Kategorie:Code Snippets]]

Unifi

2019-04-14T15:56:27Z

Wuehler: /* Anwesenheitserkennung */ Baustelle entfernt

{{Baustelle}}
{{Infobox Modul
|ModPurpose=Steuerung des Unifi-Controllers über FHEM
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=74_Unifi.pm
|ModOwner=Wuehler ({{Link2FU|Wuehler|Forum}} / [[Benutzer Diskussion:Wuehler|Wiki]])}}

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 <code>define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID>]] </code>.
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/password: Username und Passwort eines Unifi-Controller-Users (siehe [[Unifi#Unifi-User|Unifi-User]])
* 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 <code>default</code>

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

=== Unifi-User ===
Bei der Definition des Moduls werden username und passwort mit angegeben. Entweder wird der standardmäßig angelegte Admin des Unifi-Controllers, oder besser ein im Unifi-Controller angelegter eigener User (unter <code>settings-> admins -> add new admin</code>) genutzt. Wenn ein neuer User angelegt wird kann dieser z.B. auch ausschließlich read-only-Berechtigungen bekommen. Dies reicht für die Grundfunktion des Unifi-Moduls )Informationen auslesen und in Readings darstellen) aus. Alle set-Funktionen (Ausnahmen: clear, update und updateClient) sowie das Attribut voucherCache benötigen schreibende Rechte im Unifi-Controller .

== Anwendung ==
=== Readings ===
Details siehe Siehe {{Link2CmdRef|Lang=en|Anker=Unifi}}

==== Attribut customClientReadings ====
Mit dem Attribut <code>customClientReadings</code> können die Readings für Clients individualisiert werden. Eine Liste der möglichen Readings erhält man mittels <code>get <unifi> clientData all</code>.
* Der state eines clients kann nicht entfernt werden. D.h. für jeden client wird es ein Reading <clientName> geben, das entweder den Wert <code>connected</code> oder <code>disconnected</code> hat.
* Es werden die Daten, die der Unifi-Controller zu den Clients vorhält 1:1 als Readings zur Verfü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 Reading <clientName>_snr entfällt und lautet <clientName>_rssi.

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

=== Anwesenheitserkennung ===
Üblicherweise: siehe [[PRESENCE#Beispiel_Anwesenheitserkennung_mittels_UniFi_Controller|PRESENCE]]

=== 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 <code>voucherCache</code> 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:
<pre>defmod voucherComment dummy
attr voucherComment event-on-change-reading comment
attr voucherComment readingList comment
attr voucherComment setList comment</pre>

Über eine ReadingsHistory kann dies festgehalten werden:
<pre>defmod voucherCacheRH readingsHistory voucherComment:comment
attr voucherCacheRH nolinks 1
attr voucherCacheRH rows 10
attr voucherCacheRH timestampFormat %Y.%m.%d_%H:%M:%S</pre>

Und/oder in einem Log speichern:
<pre>defmod voucherCommentLog FileLog ./log/voucher.log voucherComment:.*</pre>

==== 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:
<pre>defmod voucher_Dialog msgDialog {\
"Voucher": {\
"commands": [\
"{fhem('set voucherComment comment '.ReadingsVal('Unifi','-VC_2h','').' (2h): $recipient')}"\
],\
"message": "{return('Code: '.fhem('get Unifi voucher 2h'))}"\
}\
}</pre>

===== in FTUI =====
Im head der Seite wird folgender code benötigt:
<source lang="html">
<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>
</source>

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

[[Datei:ftui_vouchercache.png|thumb|FTUI-Darstellung]]
<source lang="html">
<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>
</source>

=== Erkennung neuer clients ===
Kleines DOIF mit Telegram-Benachrichtigung:
<pre>defmod di_newClients DOIF ([Unifi:-UC_newClients] ne "" ) (set Telegram message unbekannter WLAN Zugriff:[Unifi:-UC_newClients])</pre>

== FAQ ==
=== Warum enthält die DropDown-Liste einiger set-/get-Funktionen nicht alle Clients? ===
Vom UnifiController werden nur die Geräte mitgesendet, die connected sind / die im UnifiController auf der Seite Clients angezeigt werden. Clients, die connected waren, es aber nicht mehr sind - im UnifiController auf der Seite Insights - werden vom Modul aktuell nicht ausgelesen.

[[Kategorie:Other Components]]
[[Kategorie:IP Components]]
[[Kategorie:Code Snippets]]

Unifi

2019-03-28T19:15:35Z

Wuehler: FAQ begonnen

{{Baustelle}}
{{Infobox Modul
|ModPurpose=Steuerung des Unifi-Controllers über FHEM
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=74_Unifi.pm
|ModOwner=Wuehler ({{Link2FU|Wuehler|Forum}} / [[Benutzer Diskussion:Wuehler|Wiki]])}}

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 <code>define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID>]] </code>.
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/password: Username und Passwort eines Unifi-Controller-Users (siehe [[Unifi#Unifi-User|Unifi-User]])
* 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 <code>default</code>

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

=== Unifi-User ===
Bei der Definition des Moduls werden username und passwort mit angegeben. Entweder wird der standardmäßig angelegte Admin des Unifi-Controllers, oder besser ein im Unifi-Controller angelegter eigener User (unter <code>settings-> admins -> add new admin</code>) genutzt. Wenn ein neuer User angelegt wird kann dieser z.B. auch ausschließlich read-only-Berechtigungen bekommen. Dies reicht für die Grundfunktion des Unifi-Moduls )Informationen auslesen und in Readings darstellen) aus. Alle set-Funktionen (Ausnahmen: clear, update und updateClient) sowie das Attribut voucherCache benötigen schreibende Rechte im Unifi-Controller .

== Anwendung ==
=== Readings ===
Details siehe Siehe {{Link2CmdRef|Lang=en|Anker=Unifi}}

==== Attribut customClientReadings ====
Mit dem Attribut <code>customClientReadings</code> können die Readings für Clients individualisiert werden. Eine Liste der möglichen Readings erhält man mittels <code>get <unifi> clientData all</code>.
* Der state eines clients kann nicht entfernt werden. D.h. für jeden client wird es ein Reading <clientName> geben, das entweder den Wert <code>connected</code> oder <code>disconnected</code> hat.
* Es werden die Daten, die der Unifi-Controller zu den Clients vorhält 1:1 als Readings zur Verfü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 Reading <clientName>_snr entfällt und lautet <clientName>_rssi.

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

=== Anwesenheitserkennung ===
Üblicherweise: siehe [[PRESENCE#Beispiel_Anwesenheitserkennung_mittels_UniFi_Controller|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 <code>voucherCache</code> 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:
<pre>defmod voucherComment dummy
attr voucherComment event-on-change-reading comment
attr voucherComment readingList comment
attr voucherComment setList comment</pre>

Über eine ReadingsHistory kann dies festgehalten werden:
<pre>defmod voucherCacheRH readingsHistory voucherComment:comment
attr voucherCacheRH nolinks 1
attr voucherCacheRH rows 10
attr voucherCacheRH timestampFormat %Y.%m.%d_%H:%M:%S</pre>

Und/oder in einem Log speichern:
<pre>defmod voucherCommentLog FileLog ./log/voucher.log voucherComment:.*</pre>

==== 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:
<pre>defmod voucher_Dialog msgDialog {\
"Voucher": {\
"commands": [\
"{fhem('set voucherComment comment '.ReadingsVal('Unifi','-VC_2h','').' (2h): $recipient')}"\
],\
"message": "{return('Code: '.fhem('get Unifi voucher 2h'))}"\
}\
}</pre>

===== in FTUI =====
Im head der Seite wird folgender code benötigt:
<source lang="html">
<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>
</source>

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

[[Datei:ftui_vouchercache.png|thumb|FTUI-Darstellung]]
<source lang="html">
<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>
</source>

=== Erkennung neuer clients ===
Kleines DOIF mit Telegram-Benachrichtigung:
<pre>defmod di_newClients DOIF ([Unifi:-UC_newClients] ne "" ) (set Telegram message unbekannter WLAN Zugriff:[Unifi:-UC_newClients])</pre>

== FAQ ==
=== Warum enthält die DropDown-Liste einiger set-/get-Funktionen nicht alle Clients? ===
Vom UnifiController werden nur die Geräte mitgesendet, die connected sind / die im UnifiController auf der Seite Clients angezeigt werden. Clients, die connected waren, es aber nicht mehr sind - im UnifiController auf der Seite Insights - werden vom Modul aktuell nicht ausgelesen.

[[Kategorie:Other Components]]
[[Kategorie:IP Components]]
[[Kategorie:Code Snippets]]

Unifi

2019-03-28T18:46:51Z

Wuehler: /* Voraussetzungen */ Unifi-User beschrieben

{{Baustelle}}
{{Infobox Modul
|ModPurpose=Steuerung des Unifi-Controllers über FHEM
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=74_Unifi.pm
|ModOwner=Wuehler ({{Link2FU|Wuehler|Forum}} / [[Benutzer Diskussion:Wuehler|Wiki]])}}

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 <code>define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID>]] </code>.
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/password: Username und Passwort eines Unifi-Controller-Users (siehe [[Unifi#Unifi-User|Unifi-User]])
* 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 <code>default</code>

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

=== Unifi-User ===
Bei der Definition des Moduls werden username und passwort mit angegeben. Entweder wird der standardmäßig angelegte Admin des Unifi-Controllers, oder besser ein im Unifi-Controller angelegter eigener User (unter <code>settings-> admins -> add new admin</code>) genutzt. Wenn ein neuer User angelegt wird kann dieser z.B. auch ausschließlich read-only-Berechtigungen bekommen. Dies reicht für die Grundfunktion des Unifi-Moduls )Informationen auslesen und in Readings darstellen) aus. Alle set-Funktionen (Ausnahmen: clear, update und updateClient) sowie das Attribut voucherCache benötigen schreibende Rechte im Unifi-Controller .

== Anwendung ==
=== Readings ===
Details siehe Siehe {{Link2CmdRef|Lang=en|Anker=Unifi}}

==== Attribut customClientReadings ====
Mit dem Attribut <code>customClientReadings</code> können die Readings für Clients individualisiert werden. Eine Liste der möglichen Readings erhält man mittels <code>get <unifi> clientData all</code>.
* Der state eines clients kann nicht entfernt werden. D.h. für jeden client wird es ein Reading <clientName> geben, das entweder den Wert <code>connected</code> oder <code>disconnected</code> hat.
* Es werden die Daten, die der Unifi-Controller zu den Clients vorhält 1:1 als Readings zur Verfü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 Reading <clientName>_snr entfällt und lautet <clientName>_rssi.

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

=== Anwesenheitserkennung ===
Üblicherweise: siehe [[PRESENCE#Beispiel_Anwesenheitserkennung_mittels_UniFi_Controller|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 <code>voucherCache</code> 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:
<pre>defmod voucherComment dummy
attr voucherComment event-on-change-reading comment
attr voucherComment readingList comment
attr voucherComment setList comment</pre>

Über eine ReadingsHistory kann dies festgehalten werden:
<pre>defmod voucherCacheRH readingsHistory voucherComment:comment
attr voucherCacheRH nolinks 1
attr voucherCacheRH rows 10
attr voucherCacheRH timestampFormat %Y.%m.%d_%H:%M:%S</pre>

Und/oder in einem Log speichern:
<pre>defmod voucherCommentLog FileLog ./log/voucher.log voucherComment:.*</pre>

==== 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:
<pre>defmod voucher_Dialog msgDialog {\
"Voucher": {\
"commands": [\
"{fhem('set voucherComment comment '.ReadingsVal('Unifi','-VC_2h','').' (2h): $recipient')}"\
],\
"message": "{return('Code: '.fhem('get Unifi voucher 2h'))}"\
}\
}</pre>

===== in FTUI =====
Im head der Seite wird folgender code benötigt:
<source lang="html">
<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>
</source>

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

[[Datei:ftui_vouchercache.png|thumb|FTUI-Darstellung]]
<source lang="html">
<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>
</source>

=== Erkennung neuer clients ===
Kleines DOIF mit Telegram-Benachrichtigung:
<pre>defmod di_newClients DOIF ([Unifi:-UC_newClients] ne "" ) (set Telegram message unbekannter WLAN Zugriff:[Unifi:-UC_newClients])</pre>

[[Kategorie:Other Components]]
[[Kategorie:IP Components]]
[[Kategorie:Code Snippets]]

Unifi

2019-03-24T07:24:39Z

Wuehler: /* Attribut customClientReadings */ Hinweis auf get clientData ergänzt

{{Baustelle}}
{{Infobox Modul
|ModPurpose=Steuerung des Unifi-Controllers über FHEM
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=74_Unifi.pm
|ModOwner=Wuehler ({{Link2FU|Wuehler|Forum}} / [[Benutzer Diskussion:Wuehler|Wiki]])}}

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 <code>define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID>]] </code>.
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/password: Entweder der standardmäßig angelegt Admin des Unifi-Controllers, oder besser ein im Unifi-Controller angelegter eigener User, unter <code>settings-> admins -> add new admin</code>
* 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 <code>default</code>

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

== Anwendung ==
=== Readings ===
Details siehe Siehe {{Link2CmdRef|Lang=en|Anker=Unifi}}

==== Attribut customClientReadings ====
Mit dem Attribut <code>customClientReadings</code> können die Readings für Clients individualisiert werden. Eine Liste der möglichen Readings erhält man mittels <code>get <unifi> clientData all</code>.
* Der state eines clients kann nicht entfernt werden. D.h. für jeden client wird es ein Reading <clientName> geben, das entweder den Wert <code>connected</code> oder <code>disconnected</code> hat.
* Es werden die Daten, die der Unifi-Controller zu den Clients vorhält 1:1 als Readings zur Verfü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 Reading <clientName>_snr entfällt und lautet <clientName>_rssi.

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

=== Anwesenheitserkennung ===
Üblicherweise: siehe [[PRESENCE#Beispiel_Anwesenheitserkennung_mittels_UniFi_Controller|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 <code>voucherCache</code> 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:
<pre>defmod voucherComment dummy
attr voucherComment event-on-change-reading comment
attr voucherComment readingList comment
attr voucherComment setList comment</pre>

Über eine ReadingsHistory kann dies festgehalten werden:
<pre>defmod voucherCacheRH readingsHistory voucherComment:comment
attr voucherCacheRH nolinks 1
attr voucherCacheRH rows 10
attr voucherCacheRH timestampFormat %Y.%m.%d_%H:%M:%S</pre>

Und/oder in einem Log speichern:
<pre>defmod voucherCommentLog FileLog ./log/voucher.log voucherComment:.*</pre>

==== 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:
<pre>defmod voucher_Dialog msgDialog {\
"Voucher": {\
"commands": [\
"{fhem('set voucherComment comment '.ReadingsVal('Unifi','-VC_2h','').' (2h): $recipient')}"\
],\
"message": "{return('Code: '.fhem('get Unifi voucher 2h'))}"\
}\
}</pre>

===== in FTUI =====
Im head der Seite wird folgender code benötigt:
<source lang="html">
<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>
</source>

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

[[Datei:ftui_vouchercache.png|thumb|FTUI-Darstellung]]
<source lang="html">
<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>
</source>

=== Erkennung neuer clients ===
Kleines DOIF mit Telegram-Benachrichtigung:
<pre>defmod di_newClients DOIF ([Unifi:-UC_newClients] ne "" ) (set Telegram message unbekannter WLAN Zugriff:[Unifi:-UC_newClients])</pre>

[[Kategorie:Other Components]]
[[Kategorie:IP Components]]
[[Kategorie:Code Snippets]]

Unifi

2019-03-24T06:37:14Z

Wuehler: /* Attribut customClientReadings */ Korrektur eines Beispiels

{{Baustelle}}
{{Infobox Modul
|ModPurpose=Steuerung des Unifi-Controllers über FHEM
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=74_Unifi.pm
|ModOwner=Wuehler ({{Link2FU|Wuehler|Forum}} / [[Benutzer Diskussion:Wuehler|Wiki]])}}

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 <code>define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID>]] </code>.
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/password: Entweder der standardmäßig angelegt Admin des Unifi-Controllers, oder besser ein im Unifi-Controller angelegter eigener User, unter <code>settings-> admins -> add new admin</code>
* 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 <code>default</code>

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

== Anwendung ==
=== Readings ===
Details siehe Siehe {{Link2CmdRef|Lang=en|Anker=Unifi}}

==== Attribut customClientReadings ====
Mit dem Attribut <code>customClientReadings</code> 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, das entweder den Wert <code>connected</code> oder <code>disconnected</code> hat.
* Es werden die Daten, die der Unifi-Controller zu den Clients vorhält 1:1 als Readings zur Verfü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 Reading <clientName>_snr entfällt und lautet <clientName>_rssi.

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

=== Anwesenheitserkennung ===
Üblicherweise: siehe [[PRESENCE#Beispiel_Anwesenheitserkennung_mittels_UniFi_Controller|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 <code>voucherCache</code> 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:
<pre>defmod voucherComment dummy
attr voucherComment event-on-change-reading comment
attr voucherComment readingList comment
attr voucherComment setList comment</pre>

Über eine ReadingsHistory kann dies festgehalten werden:
<pre>defmod voucherCacheRH readingsHistory voucherComment:comment
attr voucherCacheRH nolinks 1
attr voucherCacheRH rows 10
attr voucherCacheRH timestampFormat %Y.%m.%d_%H:%M:%S</pre>

Und/oder in einem Log speichern:
<pre>defmod voucherCommentLog FileLog ./log/voucher.log voucherComment:.*</pre>

==== 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:
<pre>defmod voucher_Dialog msgDialog {\
"Voucher": {\
"commands": [\
"{fhem('set voucherComment comment '.ReadingsVal('Unifi','-VC_2h','').' (2h): $recipient')}"\
],\
"message": "{return('Code: '.fhem('get Unifi voucher 2h'))}"\
}\
}</pre>

===== in FTUI =====
Im head der Seite wird folgender code benötigt:
<source lang="html">
<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>
</source>

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

[[Datei:ftui_vouchercache.png|thumb|FTUI-Darstellung]]
<source lang="html">
<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>
</source>

=== Erkennung neuer clients ===
Kleines DOIF mit Telegram-Benachrichtigung:
<pre>defmod di_newClients DOIF ([Unifi:-UC_newClients] ne "" ) (set Telegram message unbekannter WLAN Zugriff:[Unifi:-UC_newClients])</pre>

[[Kategorie:Other Components]]
[[Kategorie:IP Components]]
[[Kategorie:Code Snippets]]

Unifi

2019-03-21T22:16:23Z

Wuehler: typos

{{Baustelle}}
{{Infobox Modul
|ModPurpose=Steuerung des Unifi-Controllers über FHEM
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=74_Unifi.pm
|ModOwner=Wuehler ({{Link2FU|Wuehler|Forum}} / [[Benutzer Diskussion:Wuehler|Wiki]])}}

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 <code>define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID>]] </code>.
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 <code>settings-> admins -> add new admin</code>
* 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 <code>default</code>

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

== Anwendung ==
=== Readings ===
Details siehe Siehe {{Link2CmdRef|Lang=eb|Anker=Unifi}}
==== Attribut customClientReadings ====
Mit dem Attribut <code>customClientReadings</code> 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 <code>connected</code> oder <code>disconnected</code> 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:
* <code>.:^mac$</code> : Stellt für alle Clients zusätzlich ein Reading mit der mac-Adresse zur Verfügung
* <code>.:^mac$|^uptime$</code> : Stellt für alle Clients zusätzlich ein Reading mit der mac-Adresse und ein Reading mit der uptime (Unix-Timestamp) zur Verfügung
* <code>^meinTelefon$:^mac$</code> : Stellt nur für den Client mit dem Namen "meinTelefon" ein zusätzliches Reading mit der mac-Adresse zur Verfügung
* <code>^meinTelefon$:^mac$ ^seinTelefon$:^mac$</code> : Stellt nur für die Clients mit dem Namen "meinTelefon" oder "seinTelefon" ein zusätzliches Reading mit der mac-Adresse zur Verfügung
* <code>einTelefon$:^mac$:^mac$</code> : Stellt für alle Clients, die auf "einTelefon" enden im Client-Namen haben die mac-Adresse zusätzlich zur Verfügung
* <code>.:uptime</code> : Stellt für alle Clients zusätzlich einige Readings zur Verfügung, die "uptime" im Namen enthalten. Darunter sind auch formatierte uptimes.

=== Anwesenheitserkennung ===
Üblicherweise: siehe [[PRESENCE#Beispiel_Anwesenheitserkennung_mittels_UniFi_Controller|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 <code>voucherCache</code> 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:
<pre>defmod voucherComment dummy
attr voucherComment event-on-change-reading comment
attr voucherComment readingList comment
attr voucherComment setList comment</pre>

Über eine ReadingsHistory kann dies festgehalten werden:
<pre>defmod voucherCacheRH readingsHistory voucherComment:comment
attr voucherCacheRH nolinks 1
attr voucherCacheRH rows 10
attr voucherCacheRH timestampFormat %Y.%m.%d_%H:%M:%S</pre>

Und/oder in einem Log speichern:
<pre>defmod voucherCommentLog FileLog ./log/voucher.log voucherComment:.*</pre>

==== 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:
<pre>defmod voucher_Dialog msgDialog {\
"Voucher": {\
"commands": [\
"{fhem('set voucherComment comment '.ReadingsVal('Unifi','-VC_2h','').' (2h): $recipient')}"\
],\
"message": "{return('Code: '.fhem('get Unifi voucher 2h'))}"\
}\
}</pre>

===== in FTUI =====

Im head der Seite wird folgender code benötigt:
<pre> <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></pre>

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

[[Datei:ftui_vouchercache.png|thumb|FTUI-Darstellung]]
<pre><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> </pre>
=== Erkennung neuer clients ===
Kleines DOIF mit Telegram-Benachrichtigung:
<pre>defmod di_newClients DOIF ([Unifi:-UC_newClients] ne "" ) (set Telegram message unbekannter WLAN Zugriff:[Unifi:-UC_newClients])</pre>

[[Kategorie:Other Components]]
[[Kategorie:IP Components]]
[[Kategorie:Code Snippets]]

Unifi

2019-03-21T21:10:51Z

Wuehler: Kategorien hinzugefügt

{{Baustelle}}
{{Infobox Modul
|ModPurpose=Steuerung des Unifi-Controllers über FHEM
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=74_Unifi.pm
|ModOwner=Wuehler ({{Link2FU|Wuehler|Forum}} / [[Benutzer Diskussion:Wuehler|Wiki]])}}

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 <code>define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID>]] </code>.
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 <code>setings-> admins -> add new admin</code>
* 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 <code>default</code>

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

== Anwendung ==
=== Readings ===
Details siehe Siehe {{Link2CmdRef|Lang=eb|Anker=Unifi}}
==== Attribut customClientReadings ====
Mit dem Attribut <code>customClientReadings</code> 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 <code>connected</code> oder <code>disconnected</code> 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:
* <code>.:^mac$</code> : Stellt für alle Clients zusätzlich ein Reading mit der mac-Adresse zur Verfügung
* <code>.:^mac$|^uptime$</code> : Stellt für alle Clients zusätzlich ein Reading mit der mac-Adresse und ein Reading mit der uptime (Unix-Timestamp) zur Verfügung
* <code>^meinTelefon$:^mac$</code> : Stellt nur für den Client mit dem Namen "meinTelefon" ein zusätzliches Reading mit der mac-Adresse zur Verfügung
* <code>^meinTelefon$:^mac$ ^seinTelefon$:^mac$</code> : Stellt nur für die Clients mit dem Namen "meinTelefon" oder "seinTelefon" ein zusätzliches Reading mit der mac-Adresse zur Verfügung
* <code>einTelefon$:^mac$:^mac$</code> : Stellt für alle Clients, die auf "einTelefon" enden im Client-Namen haben die mac-Adresse zusätzlich zur Verfügung
* <code>.:uptime</code> : 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#Beispiel_Anwesenheitserkennung_mittels_UniFi_Controller|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 <code>voucherCache</code> 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:
<pre>defmod voucherComment dummy
attr voucherComment event-on-change-reading comment
attr voucherComment readingList comment
attr voucherComment setList comment</pre>

Über eine ReadingsHistory kann dies festgehalten werden:
<pre>defmod voucherCacheRH readingsHistory voucherComment:comment
attr voucherCacheRH nolinks 1
attr voucherCacheRH rows 10
attr voucherCacheRH timestampFormat %Y.%m.%d_%H:%M:%S</pre>

Und/oder in einem Log speichern:
<pre>defmod voucherCommentLog FileLog ./log/voucher.log voucherComment:.*</pre>

==== 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:
<pre>defmod voucher_Dialog msgDialog {\
"Voucher": {\
"commands": [\
"{fhem('set voucherComment comment '.ReadingsVal('Unifi','-VC_2h','').' (2h): $recipient')}"\
],\
"message": "{return('Code: '.fhem('get Unifi voucher 2h'))}"\
}\
}</pre>

===== in FTUI =====

Im head der Seite wird folgender code benötigt:
<pre> <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></pre>

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

[[Datei:ftui_vouchercache.png|thumb|FTUI-Darstellung]]
<pre><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> </pre>
=== Erkennung neuer clients ===
Kleines DOIF mit Telegram-Benachrichtigung:
<pre>defmod di_newClients DOIF ([Unifi:-UC_newClients] ne "" ) (set Telegram message unbekannter WLAN Zugriff:[Unifi:-UC_newClients])</pre>

[[Kategorie:Other Components]]
[[Kategorie:IP Components]]
[[Kategorie:Code Snippets]]

Unifi

2019-03-21T21:01:34Z

Wuehler:

{{Baustelle}}
{{Infobox Modul
|ModPurpose=Steuerung des Unifi-Controllers über FHEM
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=74_Unifi.pm
|ModOwner=Wuehler ({{Link2FU|Wuehler|Forum}} / [[Benutzer Diskussion:Wuehler|Wiki]])}}

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 <code>define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID>]] </code>.
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 <code>setings-> admins -> add new admin</code>
* 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 <code>default</code>

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

== Anwendung ==
=== Readings ===
Details siehe Siehe {{Link2CmdRef|Lang=eb|Anker=Unifi}}
==== Attribut customClientReadings ====
Mit dem Attribut <code>customClientReadings</code> 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 <code>connected</code> oder <code>disconnected</code> 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:
* <code>.:^mac$</code> : Stellt für alle Clients zusätzlich ein Reading mit der mac-Adresse zur Verfügung
* <code>.:^mac$|^uptime$</code> : Stellt für alle Clients zusätzlich ein Reading mit der mac-Adresse und ein Reading mit der uptime (Unix-Timestamp) zur Verfügung
* <code>^meinTelefon$:^mac$</code> : Stellt nur für den Client mit dem Namen "meinTelefon" ein zusätzliches Reading mit der mac-Adresse zur Verfügung
* <code>^meinTelefon$:^mac$ ^seinTelefon$:^mac$</code> : Stellt nur für die Clients mit dem Namen "meinTelefon" oder "seinTelefon" ein zusätzliches Reading mit der mac-Adresse zur Verfügung
* <code>einTelefon$:^mac$:^mac$</code> : Stellt für alle Clients, die auf "einTelefon" enden im Client-Namen haben die mac-Adresse zusätzlich zur Verfügung
* <code>.:uptime</code> : 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#Beispiel_Anwesenheitserkennung_mittels_UniFi_Controller|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 <code>voucherCache</code> 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:
<pre>defmod voucherComment dummy
attr voucherComment event-on-change-reading comment
attr voucherComment readingList comment
attr voucherComment setList comment</pre>

Über eine ReadingsHistory kann dies festgehalten werden:
<pre>defmod voucherCacheRH readingsHistory voucherComment:comment
attr voucherCacheRH nolinks 1
attr voucherCacheRH rows 10
attr voucherCacheRH timestampFormat %Y.%m.%d_%H:%M:%S</pre>

Und/oder in einem Log speichern:
<pre>defmod voucherCommentLog FileLog ./log/voucher.log voucherComment:.*</pre>

==== 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:
<pre>defmod voucher_Dialog msgDialog {\
"Voucher": {\
"commands": [\
"{fhem('set voucherComment comment '.ReadingsVal('Unifi','-VC_2h','').' (2h): $recipient')}"\
],\
"message": "{return('Code: '.fhem('get Unifi voucher 2h'))}"\
}\
}</pre>

===== in FTUI =====

Im head der Seite wird folgender code benötigt:
<pre> <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></pre>

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

[[Datei:ftui_vouchercache.png|thumb|FTUI-Darstellung]]
<pre><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> </pre>
=== Erkennung neuer clients ===
Kleines DOIF mit Telegram-Benachrichtigung:
<pre>defmod di_newClients DOIF ([Unifi:-UC_newClients] ne "" ) (set Telegram message unbekannter WLAN Zugriff:[Unifi:-UC_newClients])</pre>

Unifi

2019-03-21T21:00:10Z

Wuehler:

{{Baustelle}}
{{Infobox Modul
|ModPurpose=Steuerung des Unifi-Controllers über FHEM
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=74_Unifi.pm
|ModOwner=Wuehler ({{Link2FU|Wuehler|Forum}} / [[Benutzer Diskussion:Wuehler|Wiki]])}}

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 <code>define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID>]] </code>.
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 <code>setings-> admins -> add new admin</code>
* 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 <code>default</code>

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

== Anwendung ==
=== Readings ===
Details siehe Siehe {{Link2CmdRef|Lang=eb|Anker=Unifi}}
==== Attribut customClientReadings ====
Mit dem Attribut <code>customClientReadings</code> 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 <code>connected</code> oder <code>disconnected</code> 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:
* <code>.:^mac$</code> : Stellt für alle Clients zusätzlich ein Reading mit der mac-Adresse zur Verfügung
* <code>.:^mac$|^uptime$</code> : Stellt für alle Clients zusätzlich ein Reading mit der mac-Adresse und ein Reading mit der uptime (Unix-Timestamp) zur Verfügung
* <code>^meinTelefon$:^mac$</code> : Stellt nur für den Client mit dem Namen "meinTelefon" ein zusätzliches Reading mit der mac-Adresse zur Verfügung
* <code>^meinTelefon$:^mac$ ^seinTelefon$:^mac$</code> : Stellt nur für die Clients mit dem Namen "meinTelefon" oder "seinTelefon" ein zusätzliches Reading mit der mac-Adresse zur Verfügung
* <code>einTelefon$:^mac$:^mac$</code> : Stellt für alle Clients, die auf "einTelefon" enden im Client-Namen haben die mac-Adresse zusätzlich zur Verfügung
* <code>.:uptime</code> : 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#Beispiel_Anwesenheitserkennung_mittels_UniFi_Controller|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 <code>voucherCache</code> 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:
<pre>defmod voucherComment dummy
attr voucherComment event-on-change-reading comment
attr voucherComment readingList comment
attr voucherComment setList comment</pre>

Über eine ReadingsHistory kann dies festgehalten werden:
<pre>defmod voucherCacheRH readingsHistory voucherComment:comment
attr voucherCacheRH nolinks 1
attr voucherCacheRH rows 10
attr voucherCacheRH timestampFormat %Y.%m.%d_%H:%M:%S</pre>

Und/oder in einem Log speichern:
<pre>defmod voucherCommentLog FileLog ./log/voucher.log voucherComment:.*</pre>

==== 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:
<pre>defmod voucher_Dialog msgDialog {\
"Voucher": {\
"commands": [\
"{fhem('set voucherComment comment '.ReadingsVal('Unifi','-VC_2h','').' (2h): $recipient')}"\
],\
"message": "{return('Code: '.fhem('get Unifi voucher 2h'))}"\
}\
}</pre>

===== in FTUI =====

Im head der Seite wird folgender code benötigt:
<pre> <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></pre>

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

[[Datei:ftui_vouchercache.png|thumb|FTUI-Darstellung]]
<pre><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> </pre>
==== Erkennung neuer clients ====
Kleines DOIF mit Telegram-Benachrichtigung:
<pre>defmod di_newClients DOIF ([Unifi:-UC_newClients] ne "" ) (set Telegram message unbekannter WLAN Zugriff:[Unifi:-UC_newClients])</pre>

Unifi

2019-03-21T20:56:46Z

Wuehler: Anwendungsfall "Erkennung neuer clients" beschreiben

{{Baustelle}}
{{Infobox Modul
|ModPurpose=Steuerung des Unifi-Controllers über FHEM
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=74_Unifi.pm
|ModOwner=Wuehler ({{Link2FU|Wuehler|Forum}} / [[Benutzer Diskussion:Wuehler|Wiki]])}}

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 <code>define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID>]] </code>.
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 <code>setings-> admins -> add new admin</code>
* 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 <code>default</code>

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

== Anwendung ==
=== Readings ===
Details siehe Siehe {{Link2CmdRef|Lang=eb|Anker=Unifi}}
==== Attribut customClientReadings ====
Mit dem Attribut <code>customClientReadings</code> 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 <code>connected</code> oder <code>disconnected</code> 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:
* <code>.:^mac$</code> : Stellt für alle Clients zusätzlich ein Reading mit der mac-Adresse zur Verfügung
* <code>.:^mac$|^uptime$</code> : Stellt für alle Clients zusätzlich ein Reading mit der mac-Adresse und ein Reading mit der uptime (Unix-Timestamp) zur Verfügung
* <code>^meinTelefon$:^mac$</code> : Stellt nur für den Client mit dem Namen "meinTelefon" ein zusätzliches Reading mit der mac-Adresse zur Verfügung
* <code>^meinTelefon$:^mac$ ^seinTelefon$:^mac$</code> : Stellt nur für die Clients mit dem Namen "meinTelefon" oder "seinTelefon" ein zusätzliches Reading mit der mac-Adresse zur Verfügung
* <code>einTelefon$:^mac$:^mac$</code> : Stellt für alle Clients, die auf "einTelefon" enden im Client-Namen haben die mac-Adresse zusätzlich zur Verfügung
* <code>.:uptime</code> : 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#Beispiel_Anwesenheitserkennung_mittels_UniFi_Controller|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 <code>voucherCache</code> 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:
<pre>defmod voucherComment dummy
attr voucherComment event-on-change-reading comment
attr voucherComment readingList comment
attr voucherComment setList comment</pre>

Über eine ReadingsHistory kann dies festgehalten werden:
<pre>defmod voucherCacheRH readingsHistory voucherComment:comment
attr voucherCacheRH nolinks 1
attr voucherCacheRH rows 10
attr voucherCacheRH timestampFormat %Y.%m.%d_%H:%M:%S</pre>

Und/oder in einem Log speichern:
<pre>defmod voucherCommentLog FileLog ./log/voucher.log voucherComment:.*</pre>

==== 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:
<pre>defmod voucher_Dialog msgDialog {\
"Voucher": {\
"commands": [\
"{fhem('set voucherComment comment '.ReadingsVal('Unifi','-VC_2h','').' (2h): $recipient')}"\
],\
"message": "{return('Code: '.fhem('get Unifi voucher 2h'))}"\
}\
}</pre>

===== in FTUI =====

Im head der Seite wird folgender code benötigt:
<pre> <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></pre>

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

[[Datei:ftui_vouchercache.png|thumb|FTUI-Darstellung]]
<pre><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> </pre>
==== Erkennung neuer clients ====
Kleines DOIF mit Telegram-Benachrichtigung:
<pre>defmod di_newClients DOIF ([Unifi:-UC_newClients] ne "" ) (set Telegram message unbekannter WLAN Zugriff:[Unifi:-UC_newClients])</pre>

Unifi

2019-03-21T20:50:22Z

Wuehler:

{{Baustelle}}
{{Infobox Modul
|ModPurpose=Steuerung des Unifi-Controllers über FHEM
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=74_Unifi.pm
|ModOwner=Wuehler ({{Link2FU|Wuehler|Forum}} / [[Benutzer Diskussion:Wuehler|Wiki]])}}

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 <code>define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID>]] </code>.
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 <code>setings-> admins -> add new admin</code>
* 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 <code>default</code>

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

== Anwendung ==
=== Readings ===
Details siehe Siehe {{Link2CmdRef|Lang=eb|Anker=Unifi}}
==== Attribut customClientReadings ====
Mit dem Attribut <code>customClientReadings</code> 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 <code>connected</code> oder <code>disconnected</code> 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:
* <code>.:^mac$</code> : Stellt für alle Clients zusätzlich ein Reading mit der mac-Adresse zur Verfügung
* <code>.:^mac$|^uptime$</code> : Stellt für alle Clients zusätzlich ein Reading mit der mac-Adresse und ein Reading mit der uptime (Unix-Timestamp) zur Verfügung
* <code>^meinTelefon$:^mac$</code> : Stellt nur für den Client mit dem Namen "meinTelefon" ein zusätzliches Reading mit der mac-Adresse zur Verfügung
* <code>^meinTelefon$:^mac$ ^seinTelefon$:^mac$</code> : Stellt nur für die Clients mit dem Namen "meinTelefon" oder "seinTelefon" ein zusätzliches Reading mit der mac-Adresse zur Verfügung
* <code>einTelefon$:^mac$:^mac$</code> : Stellt für alle Clients, die auf "einTelefon" enden im Client-Namen haben die mac-Adresse zusätzlich zur Verfügung
* <code>.:uptime</code> : 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#Beispiel_Anwesenheitserkennung_mittels_UniFi_Controller|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 <code>voucherCache</code> 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:
<pre>defmod voucherComment dummy
attr voucherComment event-on-change-reading comment
attr voucherComment readingList comment
attr voucherComment setList comment</pre>

Über eine ReadingsHistory kann dies festgehalten werden:
<pre>defmod voucherCacheRH readingsHistory voucherComment:comment
attr voucherCacheRH nolinks 1
attr voucherCacheRH rows 10
attr voucherCacheRH timestampFormat %Y.%m.%d_%H:%M:%S</pre>

Und/oder in einem Log speichern:
<pre>defmod voucherCommentLog FileLog ./log/voucher.log voucherComment:.*</pre>

==== Voucher bereitstellen ====
Die Beispiele gehen davon aus, dass auch die Verwendung aufgezeichnet werden soll
===== über Telegram =====
Voraussetzung hier ist, dass das Modul msgDialog eingerichtet ist und ein VoucherCache mit der note "2h" konfiguriert wurde:
<pre>defmod voucher_Dialog msgDialog {\
"Voucher": {\
"commands": [\
"{fhem('set voucherComment comment '.ReadingsVal('Unifi','-VC_2h','').' (2h): $recipient')}"\
],\
"message": "{return('Code: '.fhem('get Unifi voucher 2h'))}"\
}\
}</pre>

===== in FTUI =====

Im head der Seite wird folgender code benötigt:
<pre> <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></pre>

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

[[Datei:ftui_vouchercache.png|thumb|FTUI-Darstellung]]
<pre><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> </pre>

Datei:Ftui vouchercache.png

2019-03-21T20:48:43Z

Wuehler:

Unifi

2019-03-21T20:48:16Z

Wuehler: erste Beschreibung zur Anwendung des Moduls aufgenommen

{{Baustelle}}
{{Infobox Modul
|ModPurpose=Steuerung des Unifi-Controllers über FHEM
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=74_Unifi.pm
|ModOwner=Wuehler ({{Link2FU|Wuehler|Forum}} / [[Benutzer Diskussion:Wuehler|Wiki]])}}

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 <code>define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID>]] </code>.
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 <code>setings-> admins -> add new admin</code>
* 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 <code>default</code>

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

== Anwendung ==
=== Readings ===
Details siehe Siehe {{Link2CmdRef|Lang=eb|Anker=Unifi}}
==== Attribut customClientReadings ====
Mit dem Attribut <code>customClientReadings</code> 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 <code>connected</code> oder <code>disconnected</code> 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:
* <code>.:^mac$</code> : Stellt für alle Clients zusätzlich ein Reading mit der mac-Adresse zur Verfügung
* <code>.:^mac$|^uptime$</code> : Stellt für alle Clients zusätzlich ein Reading mit der mac-Adresse und ein Reading mit der uptime (Unix-Timestamp) zur Verfügung
* <code>^meinTelefon$:^mac$</code> : Stellt nur für den Client mit dem Namen "meinTelefon" ein zusätzliches Reading mit der mac-Adresse zur Verfügung
* <code>^meinTelefon$:^mac$ ^seinTelefon$:^mac$</code> : Stellt nur für die Clients mit dem Namen "meinTelefon" oder "seinTelefon" ein zusätzliches Reading mit der mac-Adresse zur Verfügung
* <code>einTelefon$:^mac$:^mac$</code> : Stellt für alle Clients, die auf "einTelefon" enden im Client-Namen haben die mac-Adresse zusätzlich zur Verfügung
* <code>.:uptime</code> : 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#Beispiel_Anwesenheitserkennung_mittels_UniFi_Controller|PRESENCE]]

{{Todo|weitere Varianten?}}

=== Voucher ===
{{Todo|Beschreibung aufnehmen}}
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 <code>voucherCache</code> 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:
<pre>defmod voucherComment dummy
attr voucherComment event-on-change-reading comment
attr voucherComment readingList comment
attr voucherComment setList comment</pre>

Über eine ReadingsHistory kann dies festgehalten werden:
<pre>defmod voucherCacheRH readingsHistory voucherComment:comment
attr voucherCacheRH nolinks 1
attr voucherCacheRH rows 10
attr voucherCacheRH timestampFormat %Y.%m.%d_%H:%M:%S</pre>

Und/oder in einem Log speichern:
<pre>defmod voucherCommentLog FileLog ./log/voucher.log voucherComment:.*</pre>

==== Voucher bereitstellen ====
Die Beispiele gehen davon aus, dass auch die Verwendung aufgezeichnet werden soll
===== über Telegram =====
Voraussetzung hier ist, dass das Modul msgDialog eingerichtet ist und ein VoucherCache mit der note "2h" konfiguriert wurde:
<pre>defmod voucher_Dialog msgDialog {\
"Voucher": {\
"commands": [\
"{fhem('set voucherComment comment '.ReadingsVal('Unifi','-VC_2h','').' (2h): $recipient')}"\
],\
"message": "{return('Code: '.fhem('get Unifi voucher 2h'))}"\
}\
}</pre>

===== in FTUI =====

Im head der Seite wird folgender code benötigt:
<pre> <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></pre>

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

[[Datei:ftui_vouchercache.png|thumb|FTUI-Darstellung]]
<pre><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> </pre>

Unifi

2019-03-21T18:52:26Z

Wuehler: Neuanlage der Seite inklusive erster Beschreibung des Moduls