FHEMWiki - Benutzerbeiträge [de]

Conbee/deCONZ im Proxmox LXC-Container (Tutorial)

2022-01-20T20:44:45Z

Benni:

Conbee/deCONZ im Proxmox LXC-Container (Tutorial)

In diesem Tutorial wird gezeigt, wie sich ein Conbee ZigBee-Gatewas an einen unprivilegierten LXC-Container in einer Proxmox-VE einrichten und vewenden lässt.

Optional wird im Rahmen des Tutorials die Sicherung und Wiederherstellung der deCONZ-Konfiguration am Beispiel eines Umzugs von einem Raspberry PI auf den LXC-Container gezeigt.

Weiterhin wird in diesem Tutorial der deCONZ-Dienst im LXC-Container im Kontext eines dediziert für diesen Dienst angelegten User ("deconz") ohne besondere Berechtigungen eingerichtet. Auch dieser Teil ist optional.

== Verwendete Hard-/Software ==
<span style="color:darkgrey;">(Stand: 18.01.2021)</span>

Conbee (1+2) an unprivilegiertem Proxmox LXC-Container

Proxmox-Version: 7.1.8

deCONZ-Vesion: 2.13.04

== Bezeichnungen und Darstellung ==
Im Tutorial werden zur Kennzeichnung der einzelnen Rechnersysteme, auf denen die jeweiligen Arbeiten durchgeführt werden folgende Rechnerbezeichnungen verwendet:

* "RasPi" - Der Rechner mit der ursprünglich aktiven deCONZ-Installation (war ein Raspberry Pi)
* "LXC" - Der LXC-Container auf den die Neuinstallation von deCONZ kommt
* "Node" - Der Proxmox Node (Hardware) auf dem der LXC-Container betrieben wird und an dem letztendlich der Conbee angesteckt wird.

Im folgenden wird immer angegeben auf welchem Rechner mit welchem User gearbeitet wird unter Angebe von <span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">user@host</span>. Wenn also bspw. auf dem neuen Container (LXC) mit dem User "myadmin" gearbeitet werden soll, dann steht zu beginn des entsprechenden Abschitts <span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">myadmin@LXC</span>. Das heißt, immer wenn im folgenden Text eine solche Angabe kommt ist der User und/oder der Host entsprechend zu wechseln.

Im wesentlichen werden alle Aktionen ausschließlich auf der Kommmandozeile der jeweiligen Systeme durchgeführt, es sei denn es ist explizit anders angegeben.

In der Regel wird für die Anmeldung an den einzelnen Rechnern ssh verwendet. Bei der Anmeldung als root am Proxmox-Node wird das Shell-Fenster, das über die Proxmox-Verwaltung geöffnet werden kann gearbeitet. Genauso wird für die root-Anmeldung am LXC das Console-Fenster des Containers in der Proxmox-Verwaltung verwendet. In beiden Fällen ist eine Remote-Anmeldung von root per ssh ohne weitere Konfiguration nämlich nicht möglich. Das ist gut und soll auch so bleiben!
Generell spricht natürlich nichts dagegen auch bei der Arbeit mit anderen Usern auf dem LXC das Console-Fenster der Proxmox-Verwaltung zu nutzen.

Der RasPi, also das "Altsystem" ist eine Quasi-Standard-Installation mit Raspian, von daher gibt es dort auch den Standard-User "pi" mit dem dort gearbeitet wird.

Alle im Folgenden dargestellten Ausgaben von Befehlen werden <span style="font-family=monospace;color:#c0c0c0;background-color:black;">weiß auf schwarz</span> dargestellt und sind grundsätzlich beispielhaft zu verstehen.
Eventuell darin enthaltene Bezeichnungen und IDs können auf einem anderen System anders lauten. Es ist jeweils erklärt, welche Information in der Ausgabe wichtig ist. Dort dann also bitte die individuellen Informationen der eigenen Systeme für die weitere Verarbeitung notieren.

== Anlegen des LXC-Container in der Proxmox PVE ==

Die Erstellung des Containers selbst in der Proxmox-VE ist nicht Teil dieses Tutorials.

Benötigt wird ein unprivilegierter LXC-Container mit kleiner Ausstattung (1024 RAM / 2GB Disk) und aktiviertem nesting.
Als Betriebssystem wird Debian 10 (Buster) aus dem entsprechenden Proxmox-Image vorgeschlagen.
Debian 10 deshalb, da die deconz-Unterstützung derzeit offiziell nur bis zu dieser Version angegeben wird. Grundsätzlich sollte das aber auch unter Debian 11 (Bullseye) so funktionieren.

== Einrichten des Systems auf dem LXC-Container ==

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">root@LXC </span>

Folgende Pakete, die nicht mit dem Proxmox-Debian-Image kommen werden im weiteren Verlauf benötigt und müssen installiert werden:

<syntaxhighlight lang="bash">
apt install sudo lsb-release gpg usbutils
</syntaxhighlight>

Auf dem Container werden 2 User eingerichtet, einen für die Administration (myadmin / uid=1000) und einen für den Betrieb von deconz (deconz / uid=1001).

<syntaxhighlight lang="bash">
adduser deconz
adduser myadmin
</syntaxhighlight>

Der myadmin-User bekommt per sudo allumfassende Berechtiung ohne Passwort auf alles. Dazu muss die sudoers-Datei mit folgendem Befehl zur Bearbeitung geöffnet:

<syntaxhighlight lang="bash">
visudo
</syntaxhighlight>

folgende Zeile muss in die Datei eintragen werden

<syntaxhighlight lang="bash">
myadmin ALL=(ALL:ALL) NOPASSWD: ALL
</syntaxhighlight>

Ab jetzt kann für die weitere Einrichtung auf dem LXC-Container der User myadmin verwendet werden.

== Installation von deCONZ im LXC-Container ==

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">myadmin@LXC </span>

deCONZ wird nach Anleitung bei dresden-elektronik mittels apt installiert (s.a.: https://phoscon.de/en/conbee/install#ubuntu)

Wichtig! Wenn deCONZ so installiert wird, ist anschließend der deconz-Dienst noch nicht aktiviert und läuft folglich auch noch nicht. Das wird im späteren Verlauf nachgeholt.

Der deconz-User soll laut der deCONZ-Installationsanleitung (s.w.u.) der Gruppe dialout hinzugefügt werden.
Für den Betrieb auf dem LXC-Container sollte das aber egal sein. Die Rechte auf das USB-Device werden im späteren Verlauf außerhalb der Containers auf dem Proxmox-Node zugewiesen.

Nichts desto trotz:

<syntaxhighlight lang="bash">
sudo gpasswd -a deconz dialout
</syntaxhighlight>

== Sicherung der bestehenden deCONZ-Konfiguration (Optional) ==

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">pi@RasPi </span>

Für die Übertragung der deCONZ-Konfiguration wird vom Altsystem die Datei "zll.db" gesichert. In diesem Datenbank-File sind alle relevanten Informationen für deCONZ enthalten, inkl. Geräte, Gruppen, etc.

Die Datei befindet sich in einem Ordner Home-Verzeichnis des Users, unter dem der deCONZ-Dienst auf dem RasPi läuft. Das ist im Normalfall ebenfalls der User "pi"

Prüfen kann man das wie folgt:

<syntaxhighlight lang="bash">
sudo ps aux|grep deCONZ
</syntaxhighlight>

Ausgabe ist dann sowas in der Art

<pre style="color:#c0c0c0;background-color:black;">
root 87 0.0 0.2 3872 2940 ? Ss 17:03 0:00 /bin/bash /usr/bin/deCONZ-update2.sh
pi 88 0.0 4.6 402472 48436 ? Ssl 17:03 0:13 /usr/bin/deCONZ -platform minimal --http-port=80
pi 2860 0.0 0.0 3088 880 pts/3 S+ 17:54 0:00 grep deCONZ
</pre>

Interessant ist hier die mittlere Zeile, das ist der deCONZ-Dienst und wie man ganz vorne in der Zeile sieht, läuft er unter dem User "pi".

Die Datei befindet sich also im Ordner

<syntaxhighlight lang="bash">
~/.local/share/dresden-elektronik/deCONZ
</syntaxhighlight>

Wie gesagt wird von dort eigentlich nur die Datei zll.db benötigt. Es kann aber nichts schaden, sich eine Sicherung des kompletten Ordners "dresden-elektronik" zu machen.

Das alte System wird im weiteren Verlauf nicht mehr benötigt, dort kann also der deconz-Dienst beendet werden:

<syntaxhighlight lang="bash">
sudo systemctl stop deconz
</syntaxhighlight>

Weiterhin kann man auch gleich noch die zugehörigen deCONZ-Update- und -WiFi-Dienste beenden:

<syntaxhighlight lang="bash">
sudo systemctl stop deconz-update
sudo systemctl stop deconz-wifi
</syntaxhighlight>

Am besten deaktiviert man im Anschluss die Dienste generell, damit sie bei einem Neustart RasPi nicht automatisch wieder aktiv werden.

<syntaxhighlight lang="bash">
sudo systemctl deacitvate deconz
sudo systemctl deacitvate deconz-update
sudo systemctl deacitvate deconz-wifi
</syntaxhighlight>

== Durchreichen des Conbee-Stick an den LXC-Container ==

Damit der LXC-Container den Conbee-Stick, der physikalisch am Proxmox-Nodet angeschlossen ist, überhaupt verwenden kann, muss zum einen der Container auf die zugehörigen Device-Dateien des Nodes zugreifen dürfen und zum anderen müssen sie auf dem Container auch erst verfügbar gemacht werden.
Das ist derzeit leider nicht mit der Pxoxmox-VE Verwaltung im Web-UI machbar, sondern muss durch manuelle Anpassung der Container-Konfigurationsdatei erfolgen.

=== Benötigte USB-Informationen ermitteln ===

Die im folgenden ermittelten Informationen werden benötigt, um das USB-Gerät an den LXC-Container durchreichen zu können und diesem Zugriff darauf zu gewähren.

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">root@Node </span>

Bevor nun der Conbee am Proxmox-Node angeschlossen wird, lässt man sich am besten einmal die aktuell vorhandenen USB-Geräte anzeigen, das erleichtert im nächsten Schritt die Identifikation der verwendeten USB-Systemgeräte.

<syntaxhighlight lang="bash">
lsusb
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
</pre>

<syntaxhighlight lang="bash">
ls /dev/ttyUSB*
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
crw-rw---- 1 root dialout 188, 1 Jan 17 13:49 /dev/ttyUSB1
</pre>

Jetzt wird der Conbee am Proxmox-Node eingesteckt und die beiden gerad ausgeführten Befehle nochmals wiederholt

<syntaxhighlight lang="bash">
lsusb
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 007: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
</pre>

Die letzte Zeile ist neu hinzugekommen, also muss das der Conbee sein!

Folgende Informationen aus dieser Zeile werden für die weitere Konfiguration benötigt:

* Die BUS-Geräte-Informationen, Sprich die USB-Bus-Nummer (im Beispiel die 001) und die Device-Nummer auf dem Bus (im Beispiel die 007)
* Vendor- und die Product-ID des Gerätes. Das steckt im Beispiel in dieser Zahlenkombination 0403:6015. Der Teil vor dem Doppelpunkt ist die Vendor-ID ist (0403) und der Teil nach dem Doppelpunkt ist die Product-ID (6015)

<syntaxhighlight lang="bash">
ls /dev/ttyUSB*
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
crw-rw---- 1 root dialout 188, 1 Jan 17 13:49 /dev/ttyUSB1
crw-rw---- 1 root dialout 188, 0 Jan 18 19:15 /dev/ttyUSB0
</pre>

ttyUSB0 ist gegenüber dem vorherigen Aufruf hinzugekommen, dann gehört das Device zum Conbee. Auch der Datei-Zeitstempel passt zum Zeitpunkt des Anschließens am Node

Die relevante Information ,die aus dieser Ausgabe benötigt wird ist die 188. Das ist die (Major-)Nummer des Treibers, der für das Gerät zuständig ist.

Nun werden die zuvor notierten Bus- und Device-Nummer benötigt. Damit listet man sich das entsprechende USB-Bus-Device auf:

<syntaxhighlight lang="bash">
ls -l /dev/bus/usb/001/007
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
crw-rw-r-- 1 root root 189, 6 Jan 18 17:11 /dev/bus/usb/001/007
</pre>

Die relevante Information dieser Ausgabe ist auch hier die Treibernummer (189).

=== Anpassung der Container-Konfiguration ===

Für die Anpassung der Container-Konfiguration muss direkt die Container-Konfigurationsatei editiert werden. Dazu wird die Container-ID des LXC benötigt, die man am einfachsten aus der Proxmox-Verwaltung liest.

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">root@Node </span>

Die Konfigurationsdatei des LXC-Containers befindet sich unter

<syntaxhighlight lang="bash">
/etc/pve/local/lxc/
</syntaxhighlight>

und ist nach folgendem Schema benannt: <CONTAINER-ID>.conf das <CONTAINER-ID> ist natürlich mit der zuvor ermittelten Container-ID zu ersetzen

Die Datei mit der entsprechenden Container-ID wird nun editiert

<syntaxhighlight lang="bash">
nano <CONTAINER-ID>.conf
</syntaxhighlight>

Am Ende der Datei werden entsprechend der zuvor gesammelten Informationen folgende Zeilen am Ende eingefügt:

<syntaxhighlight lang="bash">
lxc.cgroup.devices.allow: c 189:* rwm
lxc.mount.entry: /dev/bus/usb/001/007 dev/bus/usb/001/007 none bind,optional,create=file
lxc.cgroup.devices.allow: c 188:* rwm
lxc.mount.entry: /dev/ttyUSB0 dev/ttyUSB0 none bind,optional,create=file
</syntaxhighlight>

Zur Erinnerung: Die genannten Werte sind nur Beispielhaft und müssen durch die zuvor, individuell ermittelten Werte aus 5. ersetzt werden!

* In die 1. Zeile kommt die 189 (die aus der Ausgabe von ls -l /dev/bus/usb/001/007 kommt). Damit wird dem Container der Zugriff auf USB-Bus-Devices gestattet.
* In der 2. Zeile kommt 2 mal der Bus-Device-Pfad, genau so, wie er auch beim ls verwendet wurde. Damit wird das Bus-Device des Node im Container genau unter dem selben Pfad gemountet.
* In der 3. Zeile wird dem Container der Zugriff auf USB-Serial-Devices eingerichtet. (die 188 kommt aus dem ls -l /dev/ttyUSB*)
* In der 4. Zeile wird das USB-Serial-Device ttyUSB0 unter demselben Pfad im LXC-Container gemountet.

Bei den beiden Mount-Angaben ist der erste Teil immer die Quelle, also der Pfad auf dem Node und der zweite Teil das Ziel, also der Pfad im LXC-Container. Die Devices können bei Bedarf und Wunsch also auch unter anderen Bezeichnungen im LXC-Container verfügbar gemacht werden.

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">myadmin@LXC </span>

Nach dem Speichern der Änderungen muss der LXC-Container (!) einmal neu gestartet werden:

<syntaxhighlight lang="bash">
sudo reboot now
</syntaxhighlight>

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">myadmin@LXC </span>

Überprüfen, ob die Änderunge erfolgreich für im LXC-Container übernommen und angewendet wurden:

<syntaxhighlight lang="bash">
ls -l /dev/bus/usb/001/007
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
crw-rw-r-- 1 nobody nogroup 189, 6 Jan 18 16:11 /dev/bus/usb/001/007
</pre>

Das ist die erwartete Ausgabe!

<syntaxhighlight lang="bash">
ls -l /dev/ttyUSB*
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
crw-rw---- 1 nobody nogroup 188, 0 Jan 18 19:49 /dev/ttyUSB0
</pre>

Auch das ist die erwartete Ausgabe.

=== Anpassung der Berechtigungen auf dem Node ===

Die letzte Ausgabe ist von zusätzlichem Interesse, denn Dort kann man sehen, dass nur der Eigentümer und die Gruppe Zugriff auf das Gerät haben, alle anderen (other) aber nicht. Leider sind als Eigentümer der User "nobody" und die Gruppe "nogroup" angegeben. Das liegt daran, Die User/Gruppen und Berechtigungen vom Host-System nicht ohne Weiteres an einen (unprivilegierten) Container weitergegeben werden können. Es gibt zwar die Möglichkeit dies durch ein entsprechendes Mapping der uid und gid in der Konfigurationsdatei des Containers zu erreichen.
Einfacher ist es aber, auf dem Node auch "allen anderen" (other) den Zugriff auf das Device zu erlauben. Temporär erreicht man das durch ganz normale Rechteanpassung:

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">root@node </span>

<syntaxhighlight lang="bash">
chmod o+rw /dev/ttyUSB0
</syntaxhighlight>

Ob die Änderungen wirksam sind, sieht man mittels

<syntaxhighlight lang="bash">
ls -l /dev/ttyUSB0
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
crw-rw-rw- 1 root dialout 188, 0 Jan 18 19:15 /dev/ttyUSB0
</pre>

Genau so soll es sein! Das Device darf nun von jedem gelesen und beschrieben werden.

Die Rechte müssten auch direkt auf dem Container entsprechend erweitert worden sein. Auch das kann man überprüfen

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">myadmin@LXC </span>

<syntaxhighlight lang="bash">
ls -l /dev/ttyUSB0
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
crw-rw-rw- 1 nobody nogroup 188, 0 Jan 18 19:49 /dev/ttyUSB0
</pre>

Man sieht, auch im Container kann nun jeder lesend und schreibend auf das Gerät zugegriffen werden. Genau so wird das auch benötigt.

Wie schon erwähnt ist die gerade durchgeführte Rechteanpassung nur temporär. Sprich wird der Pxoxmox-Node neu gestartet, sind die Schreib-/Leserechte für other auf das Device wieder verloren. Damit diese Rechtezuweisung auf dem Proxmox-Node auch über einen Systemneustart erhalten bleibt, genauer gesagt dann wieder automatisch eingerichtet wird, wird nun eine entsprechende udev-Regel auf dem Proxmox-Node eingerichtet.

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">root@Node </span>

Es wird die Datei mit dem Editor angelegt

<syntaxhighlight lang="bash">
nano /etc/udev/rules.d/50-lxcusb.rules
</syntaxhighlight>

Folgende Zeile wird dort eingetragen:

<syntaxhighlight lang="bash">
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", GROUP="users", MODE="0666"
</syntaxhighlight>

Hier sind natürlich wieder die oben ermittelten individuellen Werte für Vendor- und Product-ID einzutragen.
Durch diese Regel werden die Rechte für das, durch Product- und Vendor-ID identifizierte Device beim Systemstart auf den in MODE eingestellten wert (0666 -> rw-rw-rw) festgelegt.

Damit ist die USB-Geräteeinrichtung abgeschlossen.

{{Hinweis|Wenn der Stick irgendwann umgesteckt wird, teilweise auch nur, wenn er aus und wieder neu eingesteckt wird, ändert sich u.U. die Device-Nummer (007) ggf. auch die Bus-Nummer (001). In diesem Fall muss die LXC-Container-Konfigurationsdatei entsprechend angepasst werden.}}

{{Hinweis|Wenn der LXC-Container auf einen anderen Proxmox-Node migriert wird, muss natürlich der Conbee am neuen angesteckt angesteckt werden und entsprechend durchgereicht werden.}}

== Einrichtung und Konfigurieren des deCONZ-Dienstes ==

Jetzt erst wird der Dienst im LXC-Container aktiviert

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">myadmin@LXC </span>

<syntaxhighlight lang="bash">
sudo systemctl enable deconz
</syntaxhighlight>

Bevor der Dienst nun gestartet wird, wird zunächst das Services-File an die gewünschten gegebenheiten angepasst (optional!)
Zum einen wird der User angepasst, unter dem der deconz-Service laufen soll und zum anderen wird dem deconz dienst beim Aufruf mitgeteilt, wo er den Conbee findet (/dev/ttyUSB0)

Bei der Aktivierung des Dienstes wurde der Dateipfad, bzw. der erzeugte Symlink auf die Service-Datei ausgegeben.

<pre style="color:#c0c0c0;background-color:black;">
/etc/systemd/system/multi-user.target.wants/deconz.service -> /lib/systemd/system/deconz.service
</pre>

Es ist jetzt egal, ob über den symlink oder die Datei direkt editiert wird. Editiert werden muss allerdings mit root-Rechten (sudo)

<syntaxhighlight lang="bash">
sudo nano /etc/systemd/system/multi-user.target.wants/deconz.service
</syntaxhighlight>

Nach der Änderung sollte die Datei so aussehen

Die Service-Datei sieht bei mir nach Änderung so aus:

<syntaxhighlight lang="bash">
[Unit]
Description=deCONZ: ZigBee gateway -- REST API
Wants=deconz-init.service deconz-update.service
StartLimitIntervalSec=0

[Service]
User=deconz
ExecStart=/usr/bin/deCONZ -platform minimal --http-port=80 --dev=/dev/ttyUSB0
Restart=on-failure
RestartSec=30
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_KILL CAP_SYS_BOOT CAP_SYS_TIME

[Install]
WantedBy=multi-user.target
</syntaxhighlight>

Die genannten Änderungen finden sich in den ersten beiden Zeilen im Abschnitt [Service] Beim User stand ursprünglich die uid des Users drin, es funktioniert allerdings auch mit dem Usernamen. Falls nicht, dann gegen die gewünschte uid austauschen.

Nach dem Speichern der Datei muss systemctl dazu aufgefordert werden, die Änderungen zu übernehmen:

<syntaxhighlight lang="bash">
sudo systemctl daemon-reload
</syntaxhighlight>

Dann kann der Dienst endlich gestartet werden

<syntaxhighlight lang="bash">
sudo systemctl start deconz
</syntaxhighlight>

Überprüfen kann man das am einfachsten indem man sich den entsprechenden Prozess aus der Prozessliste filtert:

<syntaxhighlight lang="bash">
sudo ps aux|grep deCONZ
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
root 87 0.0 0.2 3872 2940 ? Ss 17:03 0:01 /bin/bash /usr/bin/deCONZ-update2.sh
deconz 88 0.0 4.6 402472 48436 ? Ssl 17:03 0:55 /usr/bin/deCONZ -platform minimal --http-port=80 --dev=/dev/ttyUSB0
myadmin 10727 0.0 0.0 3088 816 pts/3 S+ 20:36 0:00 grep deCONZ
</pre>

Man sieht in der Ausgabe, der Dienst läuft unter dem gewünschten User "deconz" und auch das ttyUSB0 wurde beim Start korrekt übergeben.

Damit ist die grundsätzliche Einrichtung von deCONZ auf dem LXC-Container mit durchgereichtem Conbee abgeschlossen.

== Wiederherstellen der vorherigen deCONZ-Konfiguration (Optional) ==

Wenn die deCONZ-Konfiguration samt Conbee von einem bestehenden System in den Container "umziehen" soll muss nun noch lediglich die in Punkt 5. gesicherte Datei "zll.db" in das deCONZ-Verzeichnis unter dem User deCONZ kopiert werden:

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow"> myadmin@LXC </span>

Dazu muss der Dienst zunächst gestoppt werden

<syntaxhighlight lang="bash">
sudo systemctl stop deconz
</syntaxhighlight>

Dann kann die Datei aus der vorherigen Sicherung vom Altsystem übertragen werden
Ziel ist in diesem Beispiel dann im Home-Verzeichnis des Users deconz:

<syntaxhighlight lang="bash">
/home/deconz/.local/share/dresden-elektronik/deCONZ
</syntaxhighlight>

Jetzt muss der Dienst nur wieder gestartet werden.

<syntaxhighlight lang="bash">
sudo systemctl start deconz
</syntaxhighlight>

Jetzt kann man sich wie gewohnt, mit dem Browser an der Phoscon-App auf dem LXC-Container anmelden. Dort sollte dann das "alte" Gateway zur Auswahl stehen und nach Anmeldung am Gateway sollten auch alle Gruppen, Lichter, Schalter, .... vorhanden und bedienbar sein.

== Anpassungen in FHEM (Optional) ==

Wenn der Conbee bisher in FHEM als HUE-IO verwendet wurde muss im entsprechenden FHEM-Device (Bspw.: "deCONZ") im DEF die IP-Adresse des LXC-Containers eingetragen werden.

== Anmerkungen ==

* Die Einrichtung zum Durchreichen von USB-Serial-Devices an unprivilegierte LXC-Container ist grundsätzlich auch für andere USB-Devices anwendbar. Auf gleiche Art und Weise lässt sich bspw. ein Volkszähler USB-Lesekopf am Proxmox-Node anschließen und an einen LXC-Container durchreichen.

* Die Sicherung und Wiederherstellung der deCONZ-Konfiguration lässt sich so natürlich auch bei einem System-Upgrade oder einer geplanten System-Neuinstallation anwenden.

[[Kategorie:ZigBee]]

Hue

2022-01-20T19:27:36Z

Benni: Link auf neues Tutorial "Conbee/deCONZ im Proxmox LXC-Container (Tutorial)" und Unterscheidung Proxmox-VM und Proxmox LXC-Container

<div style="float:right">{{Infobox Modul
|Name=HUEBridge
|ModPurpose=Anbindung Bridge des Philips Hue Lighting System
|ModType=d

|ModCmdRef=HUEBridge
|ModForumArea=Zigbee
|ModTechName=30_HUEBridge.pm
|ModOwner=Andre ([http://forum.fhem.de/index.php?action=profile;u=430 Forum] / [[Benutzer Diskussion:justme|Wiki]])
}}
{{Infobox Modul
|Name=HUEDevice
|ModPurpose=Ansteuerung Geräte des Philips Hue Lighting System über HUEBridge
|ModType=d

|ModCmdRef=HUEDevice
|ModForumArea=Zigbee
|ModTechName=31_HUEDevice.pm
|ModOwner=Andre ([http://forum.fhem.de/index.php?action=profile;u=430 Forum] / [[Benutzer Diskussion:justme|Wiki]])
}}
</div>

== HUE-Bridge ==
=== Einrichtung in FHEM ===
Die Einrichtung ist wirklich einfach. Mit
:<code>define Wiesollesheißen HUEBridge 192.168.0.123</code>
wird die Bridge eingebunden. (Die IP-Adresse gegen die der HUE Bridge ersetzen oder den DNS Namen.) Dann einfach auf den runden Knopf in der Mitte der Bridge drücken und sie wird von FHEM erkannt. Die drei Lampen des Starterkits werden automatisch erkannt und sind ansteuerbar -> fertig!

WICHTIG: danach in FHEM einmal die Konfiguration speichern damit der Pairing-Key gesichert wird. Sonst muss beim nächsten FHEM-Neustart das Pairing erneut durchgeführt werden.

Falls die Hue Bridge resetet wurde bleibt der Status auf "paired" und geht nicht mehr auf connected. Um das pairing erneut durchzuführen, muss das Attribut "key" gelöscht werden.

=== Nonblocking ===
Wenn man möchte, dass die Versuche, die HUEBridge zu kontaktieren, FHEM nicht blockieren, sollte man
:<code>attr <HUEBridge_Name> httpUtils 1</code>
setzen.

== HUE-Device ==
Als Gerät können alle Hue und LightLink kompatiblen Modelle verwendet werden, die sich an der Bridge anlernen lassen. Dies sind unter anderem:
*HueBulbs (E27, GU10, Lux, White, ...)
*Hue Beyond und Phoenix
*Friends of Hue LightStrips und LivingColors Bloom
*LivingColors ab gen2
*LivingColors Bloom, Iris und Aura
*LivingWhites Energiesparlampen
*LivingWhites Leuchtenadapter
*LivingWhites Bulbs
*[[HUE_Dimmer_Switch|Hue Tap und Hue Dimmer]] (mit Einschränkungen)
*dresden elektronik Vorschaltgeräte
*OSRAM LIGHTIFY Lampen (an der Hue Bridge angelernt)
*Müller Licht tint
*...

Diese sind jeweils über eine Bridge (HueBridge) steuerbar. Die LivingColors und LivingWhites Geräte sind vorher mit Hilfe einer LivingColors oder LivingWhites Fernbedienung an der Bridge anzulernen.

Es werden auch alle HUE Sensoren (Taster, Bewegungsmelder) unterstützt. Diese werden aber nicht per [[autocreate]] angelegt, sondern müssen manuell definiert werden. Hier ist auf ein passendes Polling-Intervall zu achten (siehe: [[HUE_Dimmer_Switch|HUE Dimmer Switch]]).

Sensoren (und Aktoren) lassen sich Konfigurieren (parameter Einstellen) und eigene Set- und Get- Kommandos im definieren.

=== Mögliche andere Gateways ===
HUEDevice Client-Devices können (mit leicht unterschiedlichem Funktionsumfang) auch mit den folgenden Gateways anderer Hersteller und dem zugehörigen Bridge-Device verwendet werden:
*[[Hue#RaspBee_.26_ConBee|RaspBee & ConBee mit deCONZ]] von Dresden Elektronik
** inklusive Push-API Erweiterung und Szenen
*[[TRÅDFRI| TRÅDFRI bzw. IKEA Home smart]]
** inklusive Rollos
*[https://github.com/bwssytems/ha-bridge HA-Bridge]
** inklusive aller [https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Supported-Devices unterstützten Geräte] (Lampen, Sensoren, Thermostate, Rollos, ...)
** inklusive Update des HA-Bridge internen Gerätestatus per <code>habridgeupdate</code> Kommando
*[[ZigBee#Lightify_von_Osram|OSRAM LIGHTIFY Gateway]]

Das HUEBridge Modul erkennt, wenn ein Leuchtmittel zwischen einer Hue und einer deCONZ Bridge (oder umgekehrt) wechselt und verschiebt das zugehörige HUEDevice in FHEM jeweils zum richtigen Bridge-Device. D.h. wenn z.B. zum Firmwareupdate die Bridge gewechselt wird, ist auf FHEM Seite nichts weiter zu tun.

=== Grundlagen - Farbmodelle ===
Ein HueDevice kann per set-Befehl über unterschiedliche Farbmodelle gesteuert werden. In der folgenden Tabelle ist dargestellt, welche Werte-Kombinationen sinnvoll sind:
{| class="wikitable"
|-
! Farbmodell !! Bestandteile !! Beispiel
|-
| xyY || x- und y-Koordinate im Farbraum, Y ist die Helligkeit || <code> set bulb1 xy 0.4595,0.4105 : bri 220 </code>
|-
| hue,sat,bri || Farbwert, Sättigung und Helligkeit || <code> set bulb1 hue 14922 : sat 144 : bri 220 </code>
|-
| ct || Farbwert über Farbtemperatur || <code> set bulb1 color 2600 </code>
|-
| rgb || Farbbestandteile rot, grün und blau || <code> set bulb1 rgb FFC698 </code>
|}
'''Hinweis:''' Zur Regelung der Helligkeit sind die Befehle ''bri'' und ''pct'' gleichwertig. ''bri'' hat den Bereich 0..254, ''pct'' 0..100 .

Das Modul lässt die Mischung von Angaben aus unterschiedlichen Farbmodellen technisch zu, jedoch sind diese nicht immer sinnvoll.

'''HA-Bridge:''' In der HA-Bridge können virtuelle Devices definiert werden, welche in FHEM als ''Dimmable light'' eingebunden und verwendet werden können.

Zusätzlich zu den bereits beschriebenen set-Befehlen kann der Zustand der HA-Bridge-Devices mit Hilfe von ''habridgeupdate'' in Kombination mit ''on'', ''off'', ''pct'' und ''bri'' aktualisiert werden, ohne dass die HA-Bridge einen Schaltbefehl versendet. Beispiel: <code>set bulb1 habridgeupdate : on : pct 50</code> Details siehe: [https://github.com/bwssytems/ha-bridge#update-bridge-internal-light-state].

=== Darstellung im Webfrontend ===
Wenn man die SVG Icons verwendet, ist es sinnvoll, das Attribut color-icons zu setzen. Mit
:<code>attr HUEDevice1 color-icons 2</code>
werden z.B. die Farben und der Dimmzustand der Lampe als Icon dargestellt. Damit das ganze funktioniert, muss noch
:<code>attr WEB iconPath fhemSVG:openautomation:default</code>
gesetzt werden.

=== Spezielle Konfigurationsmöglichkeiten ===
Zur Syntax der nachfolgenden Attribute (für widgets) siehe {{Link2Forum|Topic=119298|LinkText=
Patchvorschlag im Forum}}
==== setList ====
Ermöglicht einen indirekten Zugriff auf den Befehl ''setsensor'' der HUEBridge.

Beispiele
* {{Link2Forum|Topic=118788|LinkText=
Eurotonics Spirit bzw. MOES Thermostat}}
* [https://forum.fhem.de/index.php/topic,11020.msg1192888.html#msg1192888 HueLabs Scene aus FHEM über die HUEBridge ein- und ausschalten]

==== configList ====
Ermöglicht einen indirekten Zugriff auf den Befehl ''configsensor'' der HUEBridge.

Beispiele
* {{Link2Forum|Topic=115102|Message=1093876|LinkText=Aqara motion sensor - duration}}
* {{Link2Forum|Topic=111887|Message=1064164|LinkText=Aqara vibration sensor - sensitivity}}

== RaspBee & ConBee ==
Das HUEBridge Modul unterstützt auch die ZigBee Gateway Module RaspBee und ConBee von Dresden Elektronik über die zugehörige deCONZ Software und die Wireless Light Control WebApp und die Phoscon WebApp (kommt zusammen mit deConz). Die hierzu erhältlichen Funk-Vorschaltgeräte sind noch nicht getestet, sollten aber auch funktionieren.

Im diesem {{Link2Forum|Topic=80985|LinkText=Forenbeitrag}} wird über Details der HUE Module diskutiert, die das deCONZ PushAPI über Websockets unterstützen (die entsprechenden Modulversionen sind mittlerweile regulär verfügbar). Sensoren müssen hier nicht mehr gepollt werden.

Mittlerweile funktioniert die Einbindung der RaspBee und ConBee Module auf einem sehr einfachen Weg. Dieser ist in diesem {{Link2Forum|Topic=95288|LinkText=Forenbeitrag}} zusammengefasst. Zusätzliche Plugins sind nicht mehr nötig.

=== Installation von deCONZ in einer Proxmox-VM ===
Folgende Schritte sind notwendig, um unter Proxmox zu installieren:

* Installation einer Ubuntu oder Debian VM:
:<syntaxhighlight lang="bash">
cd /var/lib/vz/template/iso/
wget http://releases.ubuntu.com/18.04/ubuntu-18.04.2-desktop-amd64.iso
</syntaxhighlight>
:oder
:<syntaxhighlight lang="bash">
cd /var/lib/vz/template/iso/
wget https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.8.0-amd64-xfce-CD-1.iso
</syntaxhighlight>

* Weiterreichen des USB Devices in die VM:
: Auflistung der verfügbaren USB Geräte:
:<syntaxhighlight lang="bash">
root@node1:~# lsusb
Bus 002 Device 004: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
</syntaxhighlight>
:Der Conbee meldet sich als "Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)", hier ist die ID wichtig (0403:6015).
:Anschließend kann das USB Gerät an die VM weitergeleitet werden. Der Wert 804 ist durch die ID der VM zu ersetzen.
:<syntaxhighlight lang="bash">
qm set 804 -usb0 host=0403:6015
</syntaxhighlight>

* Installation von deCONZ:
:<syntaxhighlight lang="bash">
apt-get update && apt-get upgrade -y
wget http://www.dresden-elektronik.de/deconz/ubuntu/beta/deconz-2.05.60-qt5.deb
sudo dpkg -i deconz-2.05.60-qt5.deb
sudo apt install -f
sudo systemctl enable deconz
reboot now
</syntaxhighlight>

=== Installation von deCONZ in einem Proxmox LXC-Container ===

[[Conbee/deCONZ im Proxmox LXC-Container (Tutorial)]]

=== Installation von deCONZ unter Docker ===
https://hub.docker.com/r/marthoc/deconz/

=== Installation von deCONZ auf einem RaspberryPI ===
Für den ConBee2 [https://phoscon.de/en/conbee2/install#raspbian kann der guten Installation von Phoscon gefolgt werden]. Entweder ihr installiert deCONZ direkt (wie hier beschrieben) oder über einen Docker Container. Der Docker Container hat ein paar Einschränkungen bzgl. Firmware Updates.

Der ausführende Benutzer muss dialout Rechte haben um auf /dev/tty* zugreifen zu dürfen:
:<syntaxhighlight lang="bash">
sudo gpasswd -a pi dialout
</syntaxhighlight>
Im Standard wird deCONZ mit dem pi-Benutzer (user id 1000) ausgeführt.

Das deCONZ Repository bei APT hinzufügen (Vorteil davon ist dass später ganz normal mit sudo apt update/upgrade deCONZ aktualisieren könnt):
:<syntaxhighlight lang="bash">
wget -O - http://phoscon.de/apt/deconz.pub.key | \
sudo apt-key add -;
sudo sh -c "echo 'deb http://phoscon.de/apt/deconz \
$(lsb_release -cs) main' > \
/etc/apt/sources.list.d/deconz.list";
sudo apt update
</syntaxhighlight>

Mit der Einführung des Raspberry Pi 3 sind noch weitere Einstellungen notwendig. Diese sind hier: [[Raspberry Pi 3: GPIO-Port Module und Bluetooth|Raspberry Pi 3: GPIO-Port Module und Bluetooth – FHEMWiki]] ausführlich beschrieben.

deCONZ installieren:
:<syntaxhighlight lang="bash">
sudo apt install deconz
</syntaxhighlight>
Wenn ihr euren RaspberryPI mit UI betreibt, kann deCONZ über ''Menu > Programming > deCONZ'' aufgerufen werden. Es gibt aber auch den Service-Modus, der ohne X11 funktionert. Hierfür die Datei ''/lib/systemd/system/deconz.service'' anpassen (ich habe z.B. den Port des Webservers geändert) und den Service wie folgt aktivieren:
:<syntaxhighlight lang="bash">
systemctl enable deconz.service
</syntaxhighlight>

== HUE auf der Fritzbox ==
Da auf der FB standardmäßig kein JSON installiert ist, muss dies nachinstalliert werden: Man lädt das JSON-Paket http://search.cpan.org/CPAN/authors/id/M/MA/MAKAMAKA/JSON-2.53.tar.gz, packt es aus und kopiert den Inhalt vom <b>lib-Verzeichnis</b> nach \fhem\lib\perl5\site_perl\5.12.2

== HUE auf der Synology Diskstation ==
Da auf der DS standardmäßig kein JSON installiert ist, muss dies nachinstalliert werden, die Anleitung dazu {{Link2Forum|Topic=19093|Message=224641|LinkText=in diesem Forenbeitrag}}.

[[Kategorie:ZigBee]]
[[Kategorie:Lichteffektgeräte]]
[[Kategorie:IP Components]]

Conbee/deCONZ im Proxmox LXC-Container (Tutorial)

2022-01-20T19:19:37Z

Benni: Die Seite wurde neu angelegt: „Conbee/deCONZ im Proxmox LXC-Container (Tutorial) In diesem Tutorial wird gezeigt, wie sich ein Conbee ZigBee-Gatewas an einen unprivilegierten LXC-Container…“

Conbee/deCONZ im Proxmox LXC-Container (Tutorial)

In diesem Tutorial wird gezeigt, wie sich ein Conbee ZigBee-Gatewas an einen unprivilegierten LXC-Container in einer Proxmox-VE einrichten und vewenden lässt.

Optional wird im Rahmen des Tutorials die Sicherung und Wiederherstellung der deCONZ-Konfiguration am Beispiel eines Umzugs von einem Raspberry PI auf den LXC-Container gezeigt.

Weiterhins wird in diesem Tutorial der deCONZ-Dienst im LXC-Container im Kontext eines dediziert für diesen Dienst angelegten User ("deconz") ohne besondere Berechtigungen eingerichtet. Auch dieser Teil ist optional.

== Verwendete Hard-/Software ==
<span style="color:darkgrey;">(Stand: 18.01.2021)</span>

Conbee (1+2) an unprivilegiertem Proxmox LXC-Container

Proxmox-Version: 7.1.8

deCONZ-Vesion: 2.13.04

== Bezeichnungen und Darstellung ==
Im Tutorial werden zur Kennzeichnung der einzelnen Rechnersysteme, auf denen die jeweiligen Arbeiten durchgeführt werden folgende Rechnerbezeichnungen verwendet:

* "RasPi" - Der Rechner mit der ursprünglich aktiven deCONZ-Installation (war ein Raspberry Pi)
* "LXC" - Der LXC-Container auf den die Neuinstallation von deCONZ kommt
* "Node" - Der Proxmox Node (Hardware) auf dem der LXC-Container betrieben wird und an dem letztendlich der Conbee angesteckt wird.

Im folgenden wird immer angegeben auf welchem Rechner mit welchem User gearbeitet wird unter Angebe von <span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">user@host</span>. Wenn also bspw. auf dem neuen Container (LXC) mit dem User "myadmin" gearbeitet werden soll, dann steht zu beginn des entsprechenden Abschitts <span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">myadmin@LXC</span>. Das heißt, immer wenn im folgenden Text eine solche Angabe kommt ist der User und/oder der Host entsprechend zu wechseln.

Im wesentlichen werden alle Aktionen ausschließlich auf der Kommmandozeile der jeweiligen Systeme durchgeführt, es sei denn es ist explizit anders angegeben.

In der Regel wird für die Anmeldung an den einzelnen Rechnern ssh verwendet. Bei der Anmeldung als root am Proxmox-Node wird das Shell-Fenster, das über die Proxmox-Verwaltung geöffnet werden kann gearbeitet. Genauso wird für die root-Anmeldung am LXC das Console-Fenster des Containers in der Proxmox-Verwaltung verwendet. In beiden Fällen ist eine Remote-Anmeldung von root per ssh ohne weitere Konfiguration nämlich nicht möglich. Das ist gut und soll auch so bleiben!
Generell spricht natürlich nichts dagegen auch bei der Arbeit mit anderen Usern auf dem LXC das Console-Fenster der Proxmox-Verwaltung zu nutzen.

Der RasPi, also das "Altsystem" ist eine Quasi-Standard-Installation mit Raspian, von daher gibt es dort auch den Standard-User "pi" mit dem dort gearbeitet wird.

Alle im Folgenden dargestellten Ausgaben von Befehlen werden <span style="font-family=monospace;color:#c0c0c0;background-color:black;">weiß auf schwarz</span> dargestellt und sind grundsätzlich beispielhaft zu verstehen.
Eventuell darin enthaltene Bezeichnungen und IDs können auf einem anderen System anders lauten. Es ist jeweils erklärt, welche Information in der Ausgabe wichtig ist. Dort dann also bitte die individuellen Informationen der eigenen Systeme für die weitere Verarbeitung notieren.

== Anlegen des LXC-Container in der Proxmox PVE ==

Die Erstellung des Containers selbst in der Proxmox-VE ist nicht Teil dieses Tutorials.

Benötigt wird ein unprivilegierter LXC-Container mit kleiner Ausstattung (1024 RAM / 2GB Disk) und aktiviertem nesting.
Als Betriebssystem wird Debian 10 (Buster) aus dem entsprechenden Proxmox-Image vorgeschlagen.
Debian 10 deshalb, da die deconz-Unterstützung derzeit offiziell nur bis zu dieser Version angegben wird. Grundsätzlich sollte das aber auch unter Debian 11 (Bullseye) so funktionieren.

== Einrichten des Systems auf dem LXC-Container ==

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">root@LXC </span>

Folgende Pakete, die nicht mit dem Proxmox-Debian-Image kommen werden im weiteren Verlauf benötigt und müssen installiert werden:

<syntaxhighlight lang="bash">
apt install sudo lsb-release gpg usbutils
</syntaxhighlight>

Auf dem Container werden 2 User eingerichtet, einen für die Administration (myadmin / uid=1000) und einen für den Betrieb von deconz (deconz / uid=1001).

<syntaxhighlight lang="bash">
adduser deconz
adduser myadmin
</syntaxhighlight>

Der myadmin-User bekommt per sudo allumfassende Berechtiung ohne Passwort auf alles. Dazu muss die sudoers-Datei mit folgendem Befehl zur Bearbeitung geöffnet:

<syntaxhighlight lang="bash">
visudo
</syntaxhighlight>

folgende Zeile muss in die Datei eintragen werden

<syntaxhighlight lang="bash">
myadmin ALL=(ALL:ALL) NOPASSWD: ALL
</syntaxhighlight>

Ab jetzt kann für die weitere Einrichtung auf dem LXC-Container der User myadmin verwendet werden.

== Installation von deCONZ im LXC-Container ==

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">myadmin@LXC </span>

deCONZ wird nach Anleitung bei dresden-elektronik mittels apt installiert (s.a.: https://phoscon.de/en/conbee/install#ubuntu)

Wichtig! Wenn deCONZ so installiert wird, ist anschließend der deconz-Dienst noch nicht aktiviert und läuft folglich auch noch nicht. Das wird im späteren Verlauf nachgeholt.

Der deconz-User soll laut der deCONZ-Installationsanleitung (s.w.u.) der Gruppe dialout hinzugefügt werden.
Für den Betrieb auf dem LXC-Container sollte das aber egal sein. Die Rechte auf das USB-Device werden im späteren Verlauf außerhalb der Containers auf dem Proxmox-Node zugewiesen.

Nichts desto trotz:

<syntaxhighlight lang="bash">
sudo gpasswd -a deconz dialout
</syntaxhighlight>

== Sicherung der bestehenden deCONZ-Kofiguration (Optional) ==

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">pi@RasPi </span>

Für die Übertragung der deCONZ-Konfiguration wird vom Altsystem die Datei "zll.db" gesichert. In diesem Datenbank-File sind alle relevanten Informationen für deCONZ enthalten, inkl. Geräte, Gruppen, etc.

Die Datei befindet sich in einem Ordner Home-Verzeichnis des Users, unter dem der deCONZ-Dienst auf dem RasPi läuft. Das ist im Normalfall ebenfalls der User "pi"

Prüfen kann man das wie folgt:

<syntaxhighlight lang="bash">
sudo ps aux|grep deCONZ
</syntaxhighlight>

Ausgabe ist dann sowas in der Art

<pre style="color:#c0c0c0;background-color:black;">
root 87 0.0 0.2 3872 2940 ? Ss 17:03 0:00 /bin/bash /usr/bin/deCONZ-update2.sh
pi 88 0.0 4.6 402472 48436 ? Ssl 17:03 0:13 /usr/bin/deCONZ -platform minimal --http-port=80
pi 2860 0.0 0.0 3088 880 pts/3 S+ 17:54 0:00 grep deCONZ
</pre>

Interessant ist hier die mittlere Zeile, das ist der deCONZ-Dienst und wie man ganz vorne in der Zeile sieht, läuft er unter dem User "pi".

Die Datei befindet sich also im Ordner

<syntaxhighlight lang="bash">
~/.local/share/dresden-elektronik/deCONZ
</syntaxhighlight>

Wie gesagt wird von dort eigentlich nur die Datei zll.db benötigt. Es kann aber nichts schaden, sich eine Sicherung des kompletten Ordners "dresden-elektronik" zu machen.

Das alte System wird im weiteren Verlauf nicht mehr benötigt, dort kann also der deconz-Dienst beendet werden:

<syntaxhighlight lang="bash">
sudo systemctl stop deconz
</syntaxhighlight>

Weiterhin kann man auch gleich noch die zugehörigen deCONZ-Update- und -WiFi-Dienste beenden:

<syntaxhighlight lang="bash">
sudo systemctl stop deconz-update
sudo systemctl stop deconz-wifi
</syntaxhighlight>

Am besten deaktiviert man im Anschluss die Dienste generell, damit sie bei einem Neustart RasPi nicht automatisch wieder aktiv werden.

<syntaxhighlight lang="bash">
sudo systemctl deacitvate deconz
sudo systemctl deacitvate deconz-update
sudo systemctl deacitvate deconz-wifi
</syntaxhighlight>

== Durchreichen des Conbee-Stick an den LXC-Container ==

Damit der LXC-Container den Conbee-Stick, der physikalisch am Proxmox-Nodet angeschlossen ist, überhaupt verwenden kann, muss zum einen der Container auf die zugehörigen Device-Dateien des Nodes zugreifen dürfen und zum anderen müssen sie auf dem Container auch erst verfügbar gemacht werden.
Das ist derzeit leider nicht mit der Pxoxmox-VE Verwaltung im Web-UI machbar, sondern muss durch manuelle Anpassung der Container-Konfigurationsdatei erfolgen.

=== Benötigte USB-Informationen zum ermitteln ===

Die im folgenden ermittelten Informationen werden benötigt, um das USB-Gerät an den LXC-Container durchreichen zu können und diesem Zugriff darauf zu gewähren.

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">root@Node </span>

Bevor nun der Conbee am Proxmox-Node angeschlossen wird, lässt man sich am besten einmal die aktuell vorhandenen USB-Geräte anzeigen, das erleichtert im nächsten Schritt die Identifikation der verwendeten USB-Systemgeräte.

<syntaxhighlight lang="bash">
lsusb
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
</pre>

<syntaxhighlight lang="bash">
ls /dev/ttyUSB*
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
crw-rw---- 1 root dialout 188, 1 Jan 17 13:49 /dev/ttyUSB1
</pre>

Jetzt wird der Conbee am Proxmox-Node eingesteckt und die beiden gerad ausgeführten Befehle nochmals wiederholt

<syntaxhighlight lang="bash">
lsusb
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 007: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
</pre>

Die letzte Zeile ist neu hinzugekommen, also muss das der Conbee sein!

Folgende Informationen aus dieser Zeile werden für die weitere Konfiguration benötigt:

* Die BUS-Geräte-Informationen, Sprich die USB-Bus-Nummer (im Beispiel die 001) und die Device-Nummer auf dem Bus (im Beispiel die 007)
* Vendor- und die Product-ID des Gerätes. Das steckt im Beispiel in dieser Zahlenkombination 0403:6015. Der Teil vor dem Doppelpunkt ist die Vendor-ID ist (0403) und der Teil nach dem Doppelpunkt ist die Product-ID (6015)

<syntaxhighlight lang="bash">
ls /dev/ttyUSB*
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
crw-rw---- 1 root dialout 188, 1 Jan 17 13:49 /dev/ttyUSB1
crw-rw---- 1 root dialout 188, 0 Jan 18 19:15 /dev/ttyUSB0
</pre>

ttyUSB0 ist gegenüber dem vorherigen Aufruf hinzugekommen, dann gehört das Device zum Conbee. Auch der Datei-Zeitstempel passt zum Zeitpunkt des Anschließens am Node

Die relevante Information ,die aus dieser Ausgabe benötigt wird ist die 188. Das ist die (Major-)Nummer des Treibers, der für das Gerät zuständig ist.

Nun werden die zuvor notierten Bus- und Device-Nummer benötigt. Damit listet man sich das entsprechende USB-Bus-Device auf:

<syntaxhighlight lang="bash">
ls -l /dev/bus/usb/001/007
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
crw-rw-r-- 1 root root 189, 6 Jan 18 17:11 /dev/bus/usb/001/007
</pre>

Die relevante Information dieser Ausgabe ist auch hier die Treibernummer (189).

=== Anpassung der Container-Konfiguration ===

Für die Anpassung der Container-Konfigurtion muss direkt die Container-Konfig-Datei editiert werden. Dazu wird die Container-ID des LXC benötigt, die man am einfachsten aus der Proxmox-Verwaltung liest.

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">root@Node </span>

Die Konfig-Datei des LXC-Containers befindet sich unter

<syntaxhighlight lang="bash">
/etc/pve/local/lxc/
</syntaxhighlight>

und ist nach folgendem Schema benannt: <CONTAINER-ID>.conf das <CONTAINER-ID> ist natürlich mit der zuvor ermittelten Container-ID zu ersetzen

Die Datei mit der entsprechenden Container-ID wird nun editiert

<syntaxhighlight lang="bash">
nano <CONTAINER-ID>.conf
</syntaxhighlight>

Am Ende der Datei werden entsprechend der zuvor gesammelten Informationen folgende Zeilen am Ende eingefügt:

<syntaxhighlight lang="bash">
lxc.cgroup.devices.allow: c 189:* rwm
lxc.mount.entry: /dev/bus/usb/001/007 dev/bus/usb/001/007 none bind,optional,create=file
lxc.cgroup.devices.allow: c 188:* rwm
lxc.mount.entry: /dev/ttyUSB0 dev/ttyUSB0 none bind,optional,create=file
</syntaxhighlight>

Zur Erinnerung: Die genannten Werte sind nur Beispielhaft und müssen durch die zuvor, individuell ermittelten Werte aus 5. ersetzt werden!

* In die 1. Zeile kommt die 189 (die aus der Ausgabe von ls -l /dev/bus/usb/001/007 kommt). Damit wird dem Container der Zugriff auf USB-Bus-Devices gestattet.
* In der 2. Zeile kommt 2 mal der Bus-Device-Pfad, genau so, wie er auch beim ls verwendet wurde. Damit wird das Bus-Device des Node im Container genau unter dem selben Pfad gemountet.
* In der 3. Zeile wird dem Container der Zugriff auf USB-Serial-Devices eingerichtet. (die 188 kommt aus dem ls -l /dev/ttyUSB*)
* In der 4. Zeile wird das USB-Serial-Device ttyUSB0 unter demselben Pfad im LXC-Container gemountet.

Bei den beiden Mount-Angaben ist der erste Teil immer die Quelle, also der Pfad auf dem Node und der zweite Teil das Ziel, also der Pfad im LXC-Container. Die Devices können bei Bedarf und Wunsch also auch unter anderen Bezeichnungen im LXC-Container verfügbar gemacht werden.

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">myadmin@LXC </span>

Nach dem Speichern der Änderungen muss der LXC-Container (!) einmal neu gestartet werden:

<syntaxhighlight lang="bash">
sudo reboot now
</syntaxhighlight>

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">myadmin@LXC </span>

Überprüfen, ob die Änderunge erfolgreich für im LXC-Container übernommen und angewendet wurden:

<syntaxhighlight lang="bash">
ls -l /dev/bus/usb/001/007
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
crw-rw-r-- 1 nobody nogroup 189, 6 Jan 18 16:11 /dev/bus/usb/001/007
</pre>

Das ist die erwartete Ausgabe!

<syntaxhighlight lang="bash">
ls -l /dev/ttyUSB*
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
crw-rw---- 1 nobody nogroup 188, 0 Jan 18 19:49 /dev/ttyUSB0
</pre>

Auch das ist die erwartete Ausgabe.

=== Anpassung der Berechtigungen auf dem Node ===

Die letzte Ausgabe ist von zusätzlichem Interesse, denn Dort kann man sehen, dass nur der Eigentümer und die Gruppe Zugriff auf das Gerät haben, alle anderen (other) aber nicht. Leider sind als Eigentümer der User "nobody" und die Gruppe "nogroup" angegeben. Das liegt daran, Die User/Gruppen und Berechtigungen vom Host-System nicht ohne Weiteres an einen (unprivilegierten) Container weitergegeben werden können. Es gibt zwar die Möglichkeit dies durch ein entsprechendes Mapping der uid und gid in der Konfig-Datei des Containers zu erreichen.
Einfacher ist es aber, auf dem Node auch "allen anderen" (other) den Zugriff auf das Device zu erlauben. Temporär erreicht man das durch ganz normale Rechteanpassung:

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">root@node </span>

<syntaxhighlight lang="bash">
chmod o+rw /dev/ttyUSB0
</syntaxhighlight>

Ob die Änderungen wirksam sind, sieht man mittels

<syntaxhighlight lang="bash">
ls -l /dev/ttyUSB0
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
crw-rw-rw- 1 root dialout 188, 0 Jan 18 19:15 /dev/ttyUSB0
</pre>

Genau so soll es sein! Das Device darf nun von jedem gelesen und beschrieben werden.

Die Rechte müssten auch direkt auf dem Container entsprechend erweitert worden sein. Auch das kann man überprüfuen

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">myadmin@LXC </span>

<syntaxhighlight lang="bash">
ls -l /dev/ttyUSB0
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
crw-rw-rw- 1 nobody nogroup 188, 0 Jan 18 19:49 /dev/ttyUSB0
</pre>

Man sieht, auch im Container kann nun jeder lesend und schreibend auf das Gerät zugegriffen werden. Genau so wird das auch benötigt.

Wie schon erwähnt ist die gerade durchgeführte Rechteanpassung nur temporär. Sprich wird der Pxoxmox-Node neu gestartet, sind die Schreib-/Leserechte für other auf das Device wieder verloren. Damit diese Rechtezuweisung auf dem Proxmox-Node auch über einen Systemneustart erhalten bleibt, genauer gesagt dann wieder automatisch eingerichtet wird, wird nun eine entsprechende udev-Regel auf dem Proxmox-Node eingerichtet.

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">root@Node </span>

Es wird die Datei mit dem Edior angelegt

<syntaxhighlight lang="bash">
nano /etc/udev/rules.d/50-lxcusb.rules
</syntaxhighlight>

Folgende Zeile wird dort eingetragen:

<syntaxhighlight lang="bash">
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", GROUP="users", MODE="0666"
</syntaxhighlight>

Hier sind natürlich wieder die oben ermittelten individuellen Werte für Vendor- und Product-ID einzutragen.
Durch diese Regel werden die Rechte für das, durch Product- und Vendor-ID identifizierte Device beim Systemstart auf den in MODE eingestellten wert (0666 -> rw-rw-rw) festgelegt.

Damit ist die USB-Geräteeinrichtung abgeschlossen.

{{Hinweis|Wenn der Stick irgendwann umgesteckt wird, teilweise auch nur, wenn er aus und wieder neu eingesteckt wird, ändert sich u.U. die Device-Nummer (007) ggf. auch die Bus-Nummer (001). In diesem Fall muss die LXC-Container-Konfigurationsdatei entsprechend angepasst werden.}}

{{Hinweis|Wenn der LXC-Container auf einen anderen Proxmox-Node migriert wird, muss natürlich der Conbee am neuen angesteckt angesteckt werden und entsprechend durchgereicht werden.}}

== Einrichtung und Konfigurieren des deCONZ-Dienstes ==

Jetzt erst wird der Dienst im LXC-Container aktiviert

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow">myadmin@LXC </span>

<syntaxhighlight lang="bash">
sudo systemctl enable deconz
</syntaxhighlight>

Bevor der Dienst nun gestartet wird, wird zunächst das Services-File an die gewünschten gegebenheiten angepasst (optional!)
Zum einen wird der User angepasst, unter dem der deconz-Service laufen soll und zum anderen wird dem deconz dienst beim Aufruf mitgeteilt, wo er den Conbee findet (/dev/ttyUSB0)

Bei der Aktivierung des Dienstes wurde der Dateipfad, bzw. der erzeugte Symlink auf die Service-Datei ausgegeben.

<pre style="color:#c0c0c0;background-color:black;">
/etc/systemd/system/multi-user.target.wants/deconz.service -> /lib/systemd/system/deconz.service
</pre>

Es ist jetzt egal, ob über den symlink oder die Datei direkt editiert wird. Editiert werden muss allerdings mit root-Rechten (sudo)

<syntaxhighlight lang="bash">
sudo nano /etc/systemd/system/multi-user.target.wants/deconz.service
</syntaxhighlight>

Nach der Änderung sollte die Datei so aussehen

Die Service-Datei sieht bei mir nach Änderung so aus:

<syntaxhighlight lang="bash">
[Unit]
Description=deCONZ: ZigBee gateway -- REST API
Wants=deconz-init.service deconz-update.service
StartLimitIntervalSec=0

[Service]
User=deconz
ExecStart=/usr/bin/deCONZ -platform minimal --http-port=80 --dev=/dev/ttyUSB0
Restart=on-failure
RestartSec=30
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_KILL CAP_SYS_BOOT CAP_SYS_TIME

[Install]
WantedBy=multi-user.target
</syntaxhighlight>

Die genannten Änderungen finden sich in den ersten beiden Zeilen in der Seciton [Service] Beim User stand ursprünglich die uid des Users drin, es sollte aber auch mit dem Usernamen funktionieren. Falls nicht, dann gegen die gewünschte uid austauschen.

Nach dem Speichern der Datei muss systemctl dazu aufgefordert werden, die Änderungen zu übernehmen:

<syntaxhighlight lang="bash">
sudo systemctl daemon-reload
</syntaxhighlight>

Dann kann der Dienst endlich gestartet werden

<syntaxhighlight lang="bash">
sudo systemctl start deconz
</syntaxhighlight>

Überprüfen kann man das am einfachsten indem man sich den entsprechenden Prozess aus der Prozessliste filtert:

<syntaxhighlight lang="bash">
sudo ps aux|grep deCONZ
</syntaxhighlight>

<pre style="color:#c0c0c0;background-color:black;">
root 87 0.0 0.2 3872 2940 ? Ss 17:03 0:01 /bin/bash /usr/bin/deCONZ-update2.sh
deconz 88 0.0 4.6 402472 48436 ? Ssl 17:03 0:55 /usr/bin/deCONZ -platform minimal --http-port=80 --dev=/dev/ttyUSB0
myadmin 10727 0.0 0.0 3088 816 pts/3 S+ 20:36 0:00 grep deCONZ
</pre>

Man sieht in der Ausgabe, der Dienst läuft unter dem gewünschten User "deconz" und auch das ttyUSB0 wurde beim Start korrekt übergeben.

Damit ist die grundsätzliche Einrichtung von deCONZ auf dem LXC-Container mit durchgereichtem Conbee abgeschlossen.

== Wiederherstellen der vorherigen deCONZ-Konfiguration (Optional) ==

Wenn die deCONZ-Konfiguration samt Conbee von einem bestehenden System in den Container "umziehen" soll muss nun noch lediglich die in Punkt 5. gesicherte Datei "zll.db" in das deCONZ-Verzeichnis unter dem User deCONZ kopiert werden:

<span style="font-family:monospace;font-weight:bold;color:black;background-color:yellow"> myadmin@LXC </span>

Dazu muss der Dienst zunächst gestoppt werden

<syntaxhighlight lang="bash">
sudo systemctl stop deconz
</syntaxhighlight>

Dann kann die Datei aus der vorherigen Sicherung vom Altsystem übertragen werden
Ziel ist in diesem Beispiel dann im Home-Verzeichnis des Users deconz:

<syntaxhighlight lang="bash">
/home/deconz/.local/share/dresden-elektronik/deCONZ
</syntaxhighlight>

Jetzt muss der Dienst nur wieder gestartet werden.

<syntaxhighlight lang="bash">
sudo systemctl start deconz
</syntaxhighlight>

Jetzt kann man sich wie gewohnt, mit dem Browser an der Phoscon-App auf dem LXC-Container anmelden. Dort sollte dann das "alte" Gatewas zur Auswahl stehen und nach Anmeldung am Gateway sollten auch alle Gruppen, Lichter, Schalter, .... vorhanden und bedienbar sein.

== Anpassungen in FHEM (Optional) ==

Wenn der Conbee bisher in FHEM als HUE-IO verwendet wurde muss im entsprechenden FHEM-Device (Bspw.: "deCONZ") im DEF die IP-Adresse des LXC-Containers eingetragen werden.

== Anmerkungen ==

* Die Einrichtung zum Durchreichen von USB-Serial-Devices an unprivilegierte LXC-Container ist grundsätzlich auch für andere USB-Devices anwendbar. Auf gleiche Art und Weise lässt sich bspw. ein Volkszähler USB-Lesekopf am Proxmox-Node anschließen und an einen LXC-Container durchreichen.

* Die Sicherung und Wiederherstellung der deCONZ-Konfiguration lässt sich so natürlich auch bei einem System-Upgrade oder einer geplanten System-Neuinstallation anwenden.

[[Kategorie:ZigBee]]

HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi

2021-11-08T09:04:11Z

Benni: /* Bekannte Probleme */ Problem aus https://forum.fhem.de/index.php/topic,123948.msg1185048.html#msg1185048

{{Infobox Hardware
|Bild=HM-MOD-RPI-PCB.jpg
|Bildbeschreibung=HomeMatic Funkmodul für Raspberry Pi
|HWProtocol=HomeMatic
|HWType=Gateway
|HWCategory=HomeMatic
|HWComm=868,3/869,525 MHz
|HWChannels=n/a
|HWVoltage=1,8–3,6 V DC
|HWPowerConsumption=50 mA max.
|HWPoweredBy=RasPi
|HWSize=19x41x14mm
|HWDeviceFHEM=[[HMUARTLGW]]
|HWManufacturer=ELV / eQ-3
}}

Das [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi]] ist eine Platine, die auf die GPIO-Schnittstelle des [[Raspberry Pi]] aufgesteckt werden und damit als [[Interface]] zu [[HomeMatic]] Geräten dienen kann.

== Aufbau, Einsatz und grundsätzliche Funktionsweise ==
Das Modul besteht aus zwei Teilplatinen, die von eQ-3 über den Internetshop von ELV (als Bausatz ab etwa 20€, fertig montiert ab etwa 30€) verkauft werden.

Das eigentliche Funkmodul wird mit HM-MOD-RPI-UART bezeichnet (und trägt den Aufdruck UART, im obigen Bild hinten teilweise verdeckt und mit der umrandeten 7 versehen), sie hat fünf einpolige Buchsen mit dem Rastermaß 2mm. Die Zusatzplatine zum Anschluss an die GPIO wird mit TRX1 bezeichnet (im obigen Bild vorn sichtbar mit dem Aufdruck HM-MOD-RPI-PCB), sie hat zwei sechspolige Buchsen mit dem Rastermaß 2,54mm. Die Zusatzplatine enthält im Wesentlichen Stützkondensatoren und erlaubt einen direkten Anschluss an die GPIO eines Raspberry Pi.
* Der vorgesehene Einsatz als Aufsteckmodul auf den GPIO Port des Raspberry erfordert eine Modell abhängige Konfiguration. Diese wird im Setupbereich des Wiki Artikel zum [[Raspberry_Pi]] beschrieben.

{{Randnotiz|RNText=Neben der hier beschriebenen Option das HM-MOD-RPI-PCB zu verwenden, besteht auch die Möglichkeit, damit auf demselben Raspberry eine virtuelle CCU zu betreiben, welche dann mit [[HMCCU]] eingebunden werden kann. Hierfür stehen mehrere Virtualisierungsvarianten zur Verfügung; eine kurze Darstellung, wie das mittels YAHM funktioniert, ist in diesem {{Link2Forum|Topic=79670|Message=718289|Forenbeitrag}} zu finden.}}Mit dieser Platine in Verbindung mit dem FHEM-Modul [[HMUARTLGW]] ist nur der Betrieb von BidCoS-Geräten möglich. Zur Einbindung von Geräten, die HM-IP verwenden, ist derzeit (Stand Juni 2018) noch zwingend eine (ggf. virtualisierte) CCU2 oder neuer erforderlich.

Das Funkmodul stellt auf dem 868MHz-Frequenzband eine Verbindung zu Homematic-Geräten her. Das Modul wird über die serielle Schnittstelle an ein Gerät gekoppelt, dass diese serielle Schnittstelle auswerten und die Information dann weiterverarbeiten kann. Hier kommen beispielsweise in Frage: Raspberry Pi, WeMos mini, ESP8266-Module, USB-serielle Adapter. Bereits das UART-Funkmodul erlaubt eine serielle Anbindung (die entsprechenden Schnittstellen Tx und Rx sind vorhanden, sie basieren auf 3,3V), es kann aber auch die zusätzliche TRX1-Platine seriell verbunden werden. Des weiteren gibt es im Forum einen {{Link2Forum|Topic=56606|Thread}}, in dem PeMue eine eigene Platinenversion (Schaltplan, Stückliste und vieles mehr) vorstellt.

=== Platine 1 -PCB-Modul ===
[[Datei:Hm-uart trx1.png|thumb|right|200px|Verkabelung beim HM-MOD-PCB]]
Am einfachsten ist es sicherlich, das kombinierte PCB-Modul (also beide Platinen UART und TRX1 durch eine Pfostenleiste miteinander verlötet) direkt auf die GPIO des Raspberry Pi aufzustecken. Das Bild rechts zeigt die entsprechende Verkabelung. Dabei ist zu beachten, dass sich nicht zwei Module die GPIO teilen können. Steckt schon ein Modul im Raspberry Pi, muss der Anschluss per USB, in einem zweiten Raspberry Pi oder per WLAN gewählt werden.
<br clear="all">
=== Platine 2 -UART-Modul ===
[[Datei:Verkabelung-HM-MOD-uart.png|thumb|right|200px|Verkabelung beim HM-MOD-UART]]
Will man das TRX1-Modul nicht verwenden, so kann man auch das UART-Modul direkt mit Rx/Tx des Raspberry Pi verbinden. Das Bild rechts zeigt die entsprechende Verkabelung. Hier sollten allerdings Stützkondensatoren an die Stromversorgung des UART angebracht werden, da Spannungsschwankungen sonst zu schwer interpretierbaren Fehlern führen können. Die Anschlüsse sind dem nachstehenden Bild zu entnehmen, allerdings ist hier nicht die UART-Platine, sondern das TRX1-Gegenstück zu sehen!

Sowohl serielle Schnittstelle des Raspberry Pi als auch das UART-Modul arbeiten mit 3,3V arbeitet, so dass man keine Spannungsteiler benötigt. Mehr Informationen zu den GPIOs findet man unter diesem [http://www.netzmafia.de/skripten/hardware/RasPi/RasPi_GPIO.html Link].

=== Zusammenbau und Verwendung ===
Man sollte die Antenne aus dem Gehäuse schauen lassen oder gar eine externe Antenne anbringen. Idealerweise sollte das Ende der Drahtantenne mit einem Klecks Heißkleber oder ähnlichem isoliert werden; eine Berührung vor allem mit dem Innenleben des Raspberry Pi muss vermieden werden!

Beide Platinen können zusammengebaut oder auch nur das UART Modul getrennt verwendet werden.
[[Datei:HM-MOD-UART-Unten.jpg|thumb|left|200px|Montage des Moduls HM-MOD-UART unten]]
[[Datei:HM-MOD-UART-Oben.jpg|thumb|right|200px|Montage des Moduls HM-MOD-UART oben]]
Die originale Montage in der Anleitung von eq3 sieht den Zusammenbau PCB Modul unten und UART Modul oben vor (Bild rechts). Damit schließen die kleineren Pi-Gehäuse nicht richtig: das Gesamtmodul klemmt am Deckel.

Man kann ohne weiteres das UART-Modul unter dem PCB-Modul montieren (Bild links), damit wird die Gesamthöhe geringer und es passt problemlos in jedes Gehäuse. Bitte vorher die genaue Situation prüfen: Es kann sein, dass damit Kühlkörper oder ähnliches seitens der Pi-Platine stören.

Man kann auch das PCB Modul kürzen und das UART Modul mit kurzen Drähten in einer Ebene verbinden (kein Bild).

Bitte auf die richtige Lage (Bilder) beim Zusammenbau und auf Lötzinnbrücken achten. Da die Anschlüsse durchkontaktiert sind, bewirkt eine falsche Positionierung des UART-Moduls im schlimmsten Fall einen Kurzschluss. Man erkennt auf beiden Bildern, dass beim UART-Modul die Pinleiste einmal auf der einen und ein andermal auf der anderen Seite des Moduls angelötet werden muss!

<br clear="all">

== Verwendung ==
Das Modul muss, um verwendet zu werden, mit einer Hardware verbunden werden. Hier kommen mehrere Möglichkeiten in Betracht, die jeweils vor und Nachteile aufweisen. Sie werden jetzt nacheinander präsentiert.

=== Anbindung an die GPIO im Raspberry ===
==== Installation ====
Man kann das HM-MOD-RPI-PCB Modul direkt in die GPIOs eines Raspberry stecken. Das hat den Vorteil, dass das Gerät (mehr oder weniger) sofort betriebsbereit ist, aber den Nachteil, dass am RPi vorher mehrere Installationen zu erfolgen haben.

Die '''<big>notwendige Konfiguration der Schnittstelle</big>''' ist hier beschrieben: [[Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule|Verwendung UART für Zusatzmodule]].
* Der Einsatz in FHEM für CUL_HM erfolgt mit dem Modul [[HMUARTLGW]]
* Die automatische Erkennung der USB Geräte muss deaktiviert werden:
::<code>attr initialUsbCheck disable 1</code>
: Nach dem Setzen des Attributes muss die Änderung gespeichert werden (siehe [[save]])!

=== Anbindung über das Netzwerk===
Wenn das HM-MOD-RPI-PCB Modul an einen RPi angeschlossen ist, kann man dieses Modul danach auch im Netzwerk verfügbar machen. Dieser Pi kann beliebige Aufgaben erledigen, nur das HM-MOD-RPI-PCB Modul selbst darf nicht lokal verwendet werden. Somit kann man bei einem Umzug des FHEM Servers das HM-MOD-RPI-PCB Modul einfach weiterhin nutzen oder einen vorhandene RaspberryPi zum "HMLAN" umbauen. Sollte man aber ausschließlich Zugriff auf das HM-MOD-RPI-PCB Modul im Netzwerk benötigen, empfiehlt sich auch aus Kostengründen (Stromverbrauch) eine andere Lösung.

Achtung! Auch über das Netzwerk darf immer '''nur eine Instanz auf das freigegebene Modul zugreifen'''!

Die Konfiguration der Schnittstelle ist in jedem Fall gleich: [[Raspberry Pi#Verwendung UART für Zusatzmodule|Verwendung UART für Zusatzmodule]].

Die [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi#Definition in FHEM 2|Definition in FHEM]] erfolgt dann mit dem Parameter <code>uart:// .</code>

===== Variante mit ser2net =====
Diese Installation auf dem Pi mit dem HM-MOD-RPI-PCB Modul bitte im Kontext <code>sudo su</code> ausführen.

<pre>apt-get install ser2net
echo "4000:raw:0:/dev/ttyAMA0:115200 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE" >> /etc/ser2net.conf
# Den Dienst neu starten
systemctl restart ser2net</pre>

===== Variante mit socat =====
Installation auf dem Pi wo das Modul steckt bitte so installieren.

sudo apt-get install socat

Zum Test kann man socat in der Kommandozeile starten

sudo socat TCP4-LISTEN:2000,fork,reuseaddr /dev/ttyAMA0,raw,echo=0,b115200

Für den dauerhaften Betrieb muss der Start von socat automatisch erfolgen.
Auf einen Debian Jessie mit systemd legt man z.B. einen Dienst durch folgende Datei an:
/etc/systemd/system/hmlangw.service

[Install]
WantedBy=multi-user.target
Type=forking

[Service]
ExecStart=/usr/bin/socat TCP4-LISTEN:2000,fork,reuseaddr /dev/ttyAMA0,raw,echo=0,b115200
User=root
Restart=always
RestartSec=10

Dann kann mit

sudo systemctl enable hmlangw

der Service zum Autostart konfiguriert werden.

=== Anbindung mit USB-Adapter ===
{{Randnotiz|RNTyp=r|RNText=Bitte beachten: Es sind immer wieder Exemplare mit [[CP2102]] im Umlauf, die mehr als 3.3V Spannung liefern! Vor dem Verbinden mit dem HM-Modul sollte daher geprüft werden, ob der interne Spannungswandler ordnungsgemäß funktioniert und wirklich nur 3.3V liefert. Bei den blauen Micro-Modulen kann man den Fehler nach dieser Anleitung beheben: [https://www.silabs.com/community/interface/forum.topic.html/cp2102_3_3v_outputi-EaVr Beitrag von PBudmark vom 08.07.2017].}}
[[Datei:PL2102 Modul.png|200px|thumb|right|Mod zur Herstellung der korrekten Spannung]]
Das UART-Modul kann ebenfalls mit einem USB-Adapter an ein USB-fähiges Gerät angeschlossen werden. Allerdings ist hier wieder auf den Spannnungspegel zu achten, unbedingt einen USB-Adapter mit 3,3 Volt Pegel nehmen! Der Vorteil ist hier, dass hohe Geschwindigkeiten möglich sind und nicht wie bei WLAN Latenzen auftreten, aber es muss eben ein USB-Anschluss verfügbar sein.

Grundsätzlich bewährt haben sich z.B. Modelle mit einem [[CP2102]], der auch ausreichend Stromreserven zum Betrieb des Moduls bietet. Dabei ist die serielle Schnittstelle wie üblich zu kreuzen, also

'''Verschaltung'''
3.3V <-> 3.3V
GND <-> GND
Rx <-> Tx
Tx <-> Rx

=== Anbindung mit ESP8266 ===
Hier ist der Vorteil, dass vor Ort nur WLAN verfügbar sein muss. Nachteilig kann sich auswirken, dass WLAN hohe Latenzen aufweisen kann und daher manchmal der Eindruck entsteht, das Modul sei gerade abwesend.

Zum Anschluss kann ein beliebiger ESP8266 verwendet werden. Mit einigen Versionen (Beispiele im Forum: {{Link2Forum|Topic=102141|Message=956606|LinkText=ESP07}} sowie {{Link2Forum|Topic=102141|LinkText=Wemos mini pro}}) ist eine Anbindung anscheinend nicht oder nur schwer möglich - wobei dies auch an nicht funktionsfähigen Clonen liegen kann oder beim Wemos daran, dass dort die USB-Schnittstelle mit Tx/Rx nicht kalkulierbare Störungen auslöst. Beim ESP8266 gibt es zwei verschiedene Firmware-Möglichkeiten: ESPLink oder ESPEasy.

[https://github.com/jeelabs/esp-link ESPLink] ist eine sehr stabile und nicht mehr aktiv weiterentwickelte Firmware, die die serielle Schnittstelle direkt mit WLAN verbindet und ohne größere Schwierigkeiten eingerichtet werden kann und funktioniert. Sie nutzt die serielle Schnittstelle des ESP. Allerdings erlaubt ESPLink nicht die Nutzung anderer GPIOs, so können beispielsweise keine anderen Sensoren mit angeschlossen bzw. ausgelesen werden. Verwendet man ESP-Link, so muss neben der WLAN Konfiguration nur das Pin Assignment konfiguriert werden. Alle Pins auf disabled stellen.

[https://www.letscontrolit.com/wiki/index.php/ESPEasy ESPEasy] (neue Version: ESPMega) wird beständig weiterentwickelt und gestattet es, weitere Sensoren anzuschließen und deren Werte auszulesen. Insbesondere kann man mit ESPEasy auch zwei weitere Pins nutzen, um eine serielle Schnittstelle zu simulieren (so genannter ''serieller Server''). Man spricht auch von einer ''swapped'' Schnittstelle. Die {{Link2Forum|Topic=62651|LinkText=Platine von amunra}} nutzt eine solche Schnittstelle.
Allerdings gibt es mit einigen ESP8266-Geräten Schwierigkeiten, diese serielle Schnittstelle zu nutzen. So ist etwa ein serieller Server mit neueren ESP-Versionen anscheinend nicht lauffähig (siehe dazu {{Link2Forum|Topic=75422|LinkText=diesen Thread}}). Es gibt eine ältere Firmware-Version von PeMue, die unmittelbar funktionsfähig scheint, siehe dazu {{Link2Forum|Topic=86592|LinkText=diesen Forenthread}}.

[[Datei:Esp-pin Konfiguration HMUART.png|200px|mini|esp-link Pin-Konfiguration beim swapped Server]]
Bei der seriellen Schnittstelle (da die ESP auf 3,3V laufen, sind keine Spannungsteiler erforderlich) findet man die Verschaltung unten. Bei der ''swapped'' Schnittstelle wird auf die digitalen Pins D7/D8 zurückgegriffen (siehe auch unten). Die letztere Verschaltung erfordert eine entsprechende Implementierung der Schnittstelle in der Firmware selbst, die beispielsweise bei ESPEasy unter Umständen nicht gegeben ist oder selbst kompiliert werden muss.

'''Verschaltung bei einem WeMos D1 mini'''
(UART) <-> (Wemos swapped) <-> (Wemos seriell)
3.3V <-> 3.3V <-> 3.3V
GND <-> GND <-> GND
Rx <-> D8 <-> Tx (D10 oder Tx)
Tx <-> D7 <-> Rx (D9 oder Rx)

Es gibt eine ausführliche Erläuterung für die Software unter [https://forum.fhem.de/index.php?action=dlattach;topic=56606.0;attach=68630], siehe auch [https://www.esp8266.com/viewtopic.php?f=32&t=18669 diese Grafik der Pins des Wemos]

Im Forum gibt es mehr Informationen zu diesen Adaptern, zum Beispiel {{Link2Forum|Topic=62651|LinkText="(amunra)-Platine für HM-MOD-UART-RPI..."}} oder {{Link2Forum|Topic=79559|LinkText="3. Sammelbestellung - Homematic WLAN Gateway"}}.

[[Datei:HM-CFG-WLAN-k.jpeg|thumb|left|200px|Anschluß an Wemos]]
Auf dem linken Foto ist der Anschluss des gesamten Moduls (Rastermaß 2,54mm statt 2mm!) an den Wemos zur Wifi-Einbindung abgebildet.

=== Betrieb mit einem LAN-TTL-Wandler ===
[[Datei:Hm-uart und usr-tcp232-T2.png|thumb|right|400px|Anschluß an die gängige Variante USR-TCP232-T2]]Auf gängigen Marktplätzen sind für etwas weniger als 10 Euro Module erhältlich, die einen seriellen Anschluss im LAN bereitstellen können. Näher Hinweise sind in den Artikeln [[Serial TTL to Ethernet Module]] sowie [[1W-IF-ETH]] zu finden.

Die Module melden sich per DHCP<ref>jedenfalls neuere firmware-Versionen</ref> im Netzwerk an, die Konfiguration erfolgt je nach Variante über ein Web-Interface, ein Windows-Tool oder eine Management-Software.

=== Betrieb mit MapleCUx ===
Auch die seriellen Schnittstellen, die ein MapleCUL oder [[MapleCUN]] bereitstellen, können zum Anschluß des Moduls verwendet werden. Der MapleCUN stellt beide seriellen Schnittstellen je unter einem eigenen Port ins Netz.

== Definition in FHEM ==
Die Funktion in FHEM hängt ab von der verwendeten Hardware. Die eigentliche Funktion wird mit dem Modul [[HMUARTLGW]] hergestellt. Alle dortigen Hinweise zur Konfiguration sind zu beachten! Man sollte sich auch mit den Grundlagen der [[HomeMatic|Homematic]] Kommunikation vertraut machen.

Je nach physischem Anschluss erfolgt eine Anbindung in FHEM in unterschiedlicher Weise. Folgende Beispiele sind '''abweichend''' von der '''<big>[[HMUARTLGW#Define|Standardkonfiguration]]!</big>'''

Wurde ein USB-Adapter auf dem FHEM-Gerät selbst verwendet, definiert man das Gerät in FHEM wie folgt.
define USB_HmUART HMUARTLGW /dev/ttyUSBx
Wurde dagegen das Gerät über WLAN oder LAN durch das UART-Modul angebunden, erfolgt die Einbindung in FHEM durch
define WLAN_HmUART HMUARTLGW uart://<IP-Adresse>:<Portnummer>
Portnummern:
*ser2net 4000 (bzw. entsprechend gewählter Einstellung)
*socat 2000 (bzw. entsprechend gewählter Einstellung)
*esp-link 23
*MapleCUN 2324 bzw. 2325
*USR-TCP232-T2 entspr. Konfiguration.

=== Logbeispiel ===
Typischerweise meldet sich das Modul beim Start so:
2016.10.06 17:11:16 3: Opening myHmUART device /dev/ttyAMA0
2016.10.06 17:11:16 3: Setting myHmUART serial parameters to 115200,8,N,1
2016.10.06 17:11:16 3: myHmUART device opened
2016.10.06 17:11:17 3: HMUARTLGW myHmUART currently running Co_CPU_BL
2016.10.06 17:11:17 3: HMUARTLGW myHmUART currently running Co_CPU_App

=== Verwendung AES in FHEM===
Das Modul beherrscht AES.
Für weitere Informationen gibt es einen separaten Wiki Eintrag [[AES Encryption]]

=== Firmware Update des UART-Moduls mit FHEM ===
Die Module werden mit einer Firmware 1.2.1 ausgeliefert. Dies Firmware ist nicht für einen stabilen Betrieb geeignet, die Firmware 1.4.1 ist die minimal lauffähige Version.

Bitte den Befehl zum download inklusive der Anführungszeichen in die FHEM Kommandozeile eingeben!

'''Firmware herunterladen'''
* Version 1.4.1
<syntaxhighlight lang="text">"wget -qO ./FHEM/firmware/coprocessor_update.eq3 https://raw.githubusercontent.com/eq-3/occu/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/HM-MOD-UART/coprocessor_update.eq3"</syntaxhighlight>
* Alternativ die aktuellste (für den Betrieb mit dem Modul HMUARTLGW '''NICHT''' empfohlen)
<syntaxhighlight lang="text">"wget -qO ./FHEM/firmware/coprocessor_update.eq3 https://raw.githubusercontent.com/eq-3/occu/HEAD/firmware/HM-MOD-UART/coprocessor_update.eq3"</syntaxhighlight>
(Firmware neuer als 1.4.1 dient nur bei CCU-Klonen mit Mischbetrieb BidCOs, klassisch HomeMatic und HomeMatic IP, siehe {{Link2Forum|Topic=70752|LinkText=diesen Forenthread}}).

'''Flashen der neuen Firmware'''

Erstmal überzeugen das die Firmware da ist: Z.B. mit dem Befehl in der FHEM Kommandozeile, die Ausgabe erfolgt in der Weboberfläche!
<syntaxhighlight lang="text">{qx(ls -lha ./FHEM/firmware)}</syntaxhighlight>
Wenn alles ok - Befehl zum flashen ausführen:
<syntaxhighlight lang="text">set myHmUART updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update.eq3</syntaxhighlight>

=== Firmware Update des UART-Moduls ohne FHEM ===
Sollte das Update über FHEM nicht funktionieren oder FHEM nicht verfügbar sein, kann die Firmware auch wie folgt eingespielt werden (Quelle: [http://heinz-otto.blogspot.com/2016/07/raspberry-pi-homematic-modul.html Ottos Technik Blog])

sudo su
apt-get update && apt-get -y install libusb-1.0-0-dev build-essential git
systemctl stop fhem
git clone git://git.zerfleddert.de/hmcfgusb
cd hmcfgusb/
make
# Firmware runterladen
wget https://raw.githubusercontent.com/eq-3/occu/ee68faf77e42ed5e3641790b43a710a3301cea7e/firmware/HM-MOD-UART/coprocessor_update.eq3
# eigentliches flashen:
./flash-hmmoduart -U /dev/ttyAMA0 coprocessor_update.eq3

=== Bekannte Probleme ===
* Sollten beim Flashen der Firmware hartnäckige Probleme auftreten (kein Erfolg aber auch gar keine Fehlermeldungen) ist das Modul vom Strom zu trennen, ein Neustart des Pi reicht nicht!
* Ein {{Link2Forum|Topic=41203|Message=340320|LinkText=Beitrag}} aus dem genannten Forenthread: ''Das Ding ist anscheinend wirklich einfach das Funkmodul aus der CCU2 (wird zumindest in der eQ-3 SW als CCU2 angesprochen) und spricht ein für FHEM vollkommen neues Protokoll.''
* Beim Raspberry 4 gibt es eine Einstellung zur Temperaturkontrolle, die muss deaktiviert werden. Siehe diesen {{Link2Forum|Topic=123223|Message=1178032|LinkText=Beitrag im Forum}}.
* Bei Verwendung mit einem USR TCP232-T2 Wandler kann es in der Default-Einstellung des Wandlers dazu kommen, dass obsolete Kommunikation gepuffert und nach einem Wiederverbinden unnötig an FHEM gesendet wird (s. [https://forum.fhem.de/index.php/topic,123948.msg1185048.html#msg1185048 Foren-Thread]) Im FHEM-Log gibt es in diesem Fall die Meldung "HMUART failed to enter App!" Abhilfe schafft das Aktivieren der Option "Buffer Data before connected" unter "Expand Function" im WebUI des TCP-232

== Links ==
* {{Link2Forum|Topic=41203|LinkText=Forenthread}} mit Nachfrage zur Unterstützung dieses Geräts in FHEM
* {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}
* [http://www.elv.de/homematic-funkmodul-fuer-raspberry-pi-bausatz.html Produktseite] bei ELV
* {{DocLink|elv|/Assets/Produkte/10/1040/104029/Downloads/104029_lan_gateway_um.pdf Bedienungsanleitung}}
* {{Link2Forum|Topic=56606|LinkText=Forenthread}} Hardware Thread mit vielen Varianten der Anbindung. In Post #26 gibt es die Detailbeschreibung in der angehängten PDF.
:<hr />
<references />

[[Kategorie:HomeMatic Components]]
[[Kategorie:Interfaces]]
[[Kategorie:Raspberry Pi]]
[[Kategorie:868MHz]]

FRITZBOX

2018-09-29T04:42:16Z

Benni: https://forum.fhem.de/index.php/topic,91548.msg840625.html#msg840625

{{Infobox Modul
|ModPurpose=Steuerung einer Fritz!Box über FHEM
|ModType=d
|ModForumArea=FRITZ!Box
|ModTechName=72_FRITZBOX.pm
|ModOwner=tupol/Topos ({{Link2FU|5432|Forum}} / [[Benutzer Diskussion:Topos|Wiki]])}}

Das Modul [[FRITZBOX]] ermöglicht die Steuerung einer [[AVM Fritz!Box]] und von AVM FRITZ!WLAN Repeatern durch FHEM . An Fritzboxen können sowohl Geräte abgefragt werden, auf denen FHEM selbst läuft (lokaler Modus), als auch entfernte (externe) Geräte.

== Voraussetzungen ==
=== Remote-Zugang ===
Für den Remote-Zugang müssen die Module JSON:XS, LWP und SOAP::Lite installiert sein; auf einem [[Raspberry Pi]] oder unter Ubuntu z. B. mit dem Befehl
:<code>sudo apt-get install libjson-perl libwww-perl libsoap-lite-perl libjson-xs-perl</code>

Teilweise ist derzeit zusätzlich die Installation der telnet Libraries erforderlich, auch wenn der Telnet-Zugang nicht genutzt werden soll. Siehe dazu den nachfolgenden Abschnitt.

=== Telnet ===
Das Modul basierte ursprünglich auf dem Zugriff auf die Fritzbox per Telnet. Ab FRITZ!OS 6.2x baut AVM den abgekündigten Telnet-Zugang sowie die webcm-Schnittstelle sukzessive zurück bzw. hat dies, je nach Firmware, schon ganz abgestellt (siehe {{Link2Forum|Topic=38586|LinkText=dieses Forenthema}}). Der zukunftssichere Zugriff auf die Fritzbox sollte also per TR-064 erfolgen. Der Vollständigkeit halber und für ältere Firmwareversionen:

# Wer den Zugang per Telnet (noch) nutzen (kann und) möchte, muss dies zuerst freischalten. Üblicherweise durch Eingabe von #96*7* an einem direkt an der entsprechenden FritzBox angeschlosssenen Telefon
# Auf dem System, auf dem FHEM läuft ([[Systemübersicht#Server|Server]]) muss Telnet installiert sein; auf einem [[Raspberry Pi]] und unter Ubuntu z. B. mit dem Befehl
::<code>sudo apt-get install libnet-telnet-perl</code>

== Installation ==
=== Erste Schritte ===
Zur Erstinstallation reicht ein einfaches <code>define FritzBox FRITZBOX</code>, dieses Modul funktioniert lokal (FHEM auf Fritzbox) sowie per Fernzugriff (FHEM auf einem anderen Server im Netz, siehe nächsten Schritt).

==== TR-064: Modul FRITZBOX für Zugriff auf einem externen Server einrichten ====
Für den Fernzugriff über TR-064 auf eine oder mehrere Fritzboxen und/oder einen FRITZ!WLAN Repeater sind die folgenden Schritte nötig (für jedes Gerät):

Fritzbox definieren:
:<code>define FritzBox FRITZBOX</code>

Wenn die Fritzbox nicht unter <nowiki>http://fritz.box</nowiki> erreichbar ist, IP im define setzen:
:<code>define FritzBox FRITZBOX 192.168.168.168</code>
192.168.168.168 dabei natürlich durch die passende IP ersetzen... Alternativ kann statt der IP auch der Hostname eingegeben werden.

Wenn ('''und nur wenn''') das Login auf der Benutzeroberfläche der FritzBox mit User und Passwort (und nicht nur per Passwort) geschieht, den User konfigurieren:
:<code>attr FritzBox boxUser ''Benutzername'' </code>
In der Fritzbox muss dann auch "Anmeldung mit FRITZ!Box-Benutzernamen und Kennwort" ausgewählt sein.

Passwort konfigurieren:
:<code>set FritzBox password ''Passwort''</code> - legt das zugehörige Passwort fest (nur einmal --> gehört nicht in die cfg-Datei)

Manuelle TR-064 Kommandos erlauben (Das Auslesen der Readings per TR-064 funktioniert auch ohne dieses Attribut.):
:<code>attr FritzBox allowTR064Command 1</code>

==== Telnet: Modul FRITZBOX für Zugriff auf einem externen Server einrichten ====
[[Datei:Screenshot_FritzBox_TelnetUser.png|mini|300px|rechts|Anlegen des Attributs telnetUser]]
Bei Fernzugriff über Telnet sind weitere Schritte nötig:
# Telnet auf der Fritzbox freischalten (Tastenkombination #96*7* am angeschlossenen Telefon (auch FritzFon)
# TelnetUser definieren (wie im Screenshot gezeigt)
# Passwort zum Benutzer auf der Fritzbox definieren

[[Datei:Screenshot_FritzBox_Passwort.png|mini|300px|rechts|Passwort definieren]]

(bitte die Buttons {{Taste|set}} und {{Taste|attr}} bei der Definition der jeweiligen Einträge nicht vergessen)

Wer stattdessen lieber das [[Konfiguration|Befehl-Eingabefeld]] verwendet:

:<code>define FritzBox FRITZBOX</code>
:<code>attr FritzBox telnetUser ''Benutzername'' </code> - legt den Benutzer fest
:<code>set FritzBox password ''Passwort'' </code> - legt das zugehörige Passwort fest

Wer keinen User konfiguriert hat, kann das Feld "telnetUser" leer lassen.

Wer sicher gehen möchte, dass auch tatsächlich Telnet und nicht andere Zugriffe benutzt werden, sollte außerdem noch setzen:

:<code>attr FritzBox forceTelnetConnection 1</code>

=== mögliche Fehlermeldungen ===
Sollte schon bei <code>define FritzBox FRITZBOX</code> die Fehlermeldung kommen, dass dieses Modul nicht existiert, dann bitte prüfen, ob FHEM auf dem aktuellen Stand ist und ggf. [[Update|aktualisieren]].

Kommt jetzt bei der erneuten Definition die Fehlermeldung <code>Error: Perl modul Net::Telnet is missing on this system</code> bitte wie oben schon erwähnt den Befehl
:<code>sudo apt-get install libnet-telnet-perl</code>
direkt per Telnet/SSH auf dem FHEM-Server ausführen und neu starten.
Sollte alles geklappt haben, seht ihr nun eure Fritzbox und könnt diverse Einstellungen manuell vornehmen und/oder automatisch vornehmen lassen.

== Anwendung ==
=== Define ===
Siehe {{Link2CmdRef|Lang=de|Anker=FRITZBOXdefine}}

=== Attribute ===
Siehe {{Link2CmdRef|Lang=de|Anker=FRITZBOXattr}}

=== TR-064 ===
Die offizielle Programmier-Schnittstelle der Fritz!Box läuft über das Protokoll TR-064.

mit dem Attribute<br/>
<code>attr <device> allowTR064Command 1</code><br/>
kann man den Befehl<br/>
<code>get <device> tr064Command <service> <control> <action> [[parameterName1 parameterValue1] ...]</code><br/>
freischalten und damit auf diese Schnittstelle zugreifen.

AVM hat die Schnittstellenbeschreibung unter [http://avm.de/service/schnittstellen/] veröffentlicht. Diese wird jedoch nur sehr sporadisch gepflegt.<br>
Ein besserer Einstiegspunkt befindet sich auf der Box unter http://fritz.box:49000/tr64desc.xml.<br>
Die möglichen TR-064-Aktionen kann man auch über den Befehl <code>get <device> tr064ServiceList</code> auslesen.

Folgende Service und Controls existieren (für den get-Befehl ''tr064Command'' werden nur die fett formatierten Wörter benötigt)

{| class="wikitable"
|-
!serviceType!!controlURL!!XML!!Dokument bei AVM
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''DeviceInfo:1'''||/upnp/control/'''deviceinfo'''||[http://fritz.box:49000/deviceinfoSCPD.xml deviceinfoSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/deviceinfoSCPD.pdf deviceinfoSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''DeviceConfig:1'''||/upnp/control/'''deviceconfig'''||[http://fritz.box:49000/deviceconfigSCPD.xml deviceconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/deviceconfigSCPD.pdf deviceconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''Layer3Forwarding:1'''||/upnp/control/'''layer3forwarding'''||[http://fritz.box:49000//layer3forwardingSCPD.xml layer3forwardingSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/layer3forwardingSCPD.pdf layer3forwardingSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''LANConfigSecurity:1'''||/upnp/control/'''lanconfigsecurity'''||[http://fritz.box:49000//lanconfigsecuritySCPD.xml lanconfigsecuritySCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/lanconfigsecuritySCPD.pdf lanconfigsecuritySCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''ManagementServer:1'''||/upnp/control/'''mgmsrv'''||[http://fritz.box:49000//mgmsrvSCPD.xml mgmsrvSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/mgmsrvSCPD.pdf mgmsrvSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''Time:1'''||/upnp/control/'''time'''||[http://fritz.box:49000//timeSCPD.xml timeSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/timeSCPD.pdf timeSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''UserInterface:1'''||/upnp/control/'''userif'''||[http://fritz.box:49000//userifSCPD.xml userifSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/userifSCPD.pdf userifSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_VoIP:1'''||/upnp/control/'''x_voip'''||[http://fritz.box:49000//x_voipSCPD.xml x_voipSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_voipSCPD.pdf x_voipSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_Storage:1'''||/upnp/control/'''x_storage'''||[http://fritz.box:49000//x_storageSCPD.xml x_storageSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_storageSCPD.pdf x_storageSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_OnTel:1'''||/upnp/control/'''x_contact'''||[http://fritz.box:49000//x_contactSCPD.xml x_contactSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_contactSCPD.pdf x_contactSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_WebDAVClient:1'''||/upnp/control/'''x_webdav'''||[http://fritz.box:49000//x_webdavSCPD.xml x_webdavSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_webdavSCPD.pdf x_webdavSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_UPnP:1'''||/upnp/control/'''x_upnp'''||[http://fritz.box:49000//x_upnpSCPD.xml x_upnpSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_upnp.pdf x_upnp.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_RemoteAccess:1'''||/upnp/control/'''x_remote'''||[http://fritz.box:49000/x_remoteSCPD.xml x_remoteSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_remoteSCPD.pdf x_remoteSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_MyFritz:1'''||/upnp/control/'''x_myfritz'''||[http://fritz.box:49000/x_myfritzSCPD.xml x_myfritzSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_myfritzSCPD.pdf x_myfritzSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_TAM:1'''||/upnp/control/'''x_tam'''||[http://fritz.box:49000/x_tamSCPD.xml x_tamSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_tam.pdf x_tam.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_AppSetup:1'''||/upnp/control/'''x_appsetup'''||[http://fritz.box:49000/x_homeautoSCPD.xml x_homeautoSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_appsetupSCPD.pdf x_appsetupSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_Homeauto:1'''||/upnp/control/'''x_homeauto'''||[http://fritz.box:49000/x_homeautoSCPD.xml x_homeautoSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_homeautoSCPD.pdf x_homeautoSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WLANConfiguration:1'''||/upnp/control/'''wlanconfig1'''||[http://fritz.box:49000/wlanconfigSCPD.xml wlanconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wlanconfigSCPD.pdf wlanconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WLANConfiguration:2'''||/upnp/control/'''wlanconfig2'''||[http://fritz.box:49000/wlanconfigSCPD.xml wlanconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wlanconfigSCPD.pdf wlanconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WLANConfiguration:3'''||/upnp/control/'''wlanconfig3'''||[http://fritz.box:49000/wlanconfigSCPD.xml wlanconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wlanconfigSCPD.pdf wlanconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''Hosts:1'''||/upnp/control/'''hosts'''||[http://fritz.box:49000/hostsSCPD.xml hostsSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/hostsSCPD.pdf hostsSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''LANEthernetInterfaceConfig:1'''||/upnp/control/'''lanethernetifcfg'''||[http://fritz.box:49000/lanifconfigSCPD.xml lanifconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/lanifconfigSCPD.pdf lanifconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''LANHostConfigManagement:1'''||/upnp/control/'''lanhostconfigmgm'''||[http://fritz.box:49000/lanhostconfigmgmSCPD.xml lanhostconfigmgmSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/lanhostconfigmgmSCPD.pdf lanhostconfigmgmSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANCommonInterfaceConfig:1'''||/upnp/control/'''wancommonifconfig1'''||[http://fritz.box:49000/wancommonifconfigSCPD.xml wancommonifconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wancommonifconfigSCPD.pdf wancommonifconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANDSLInterfaceConfig:1'''||/upnp/control/'''wandslifconfig1'''||[http://fritz.box:49000/wandslifconfigSCPD.xml wandslifconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wandslifconfigSCPD.pdf wandslifconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANDSLLinkConfig:1'''||/upnp/control/'''wandsllinkconfig1'''||[http://fritz.box:49000/wandsllinkconfigSCPD.xml wandsllinkconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wandsllinkconfigSCPD.pdf wandsllinkconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANEthernetLinkConfig:1'''||/upnp/control/'''wanethlinkconfig1'''||[http://fritz.box:49000/wanethlinkconfigSCPD.xml wanethlinkconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wanethlinkconfigSCPD.pdf wanethlinkconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANPPPConnection:1'''||/upnp/control/'''wanpppconn1'''||[http://fritz.box:49000/wanpppconnSCPD.xml wanpppconnSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wanpppconnSCPD.pdf wanpppconnSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANIPConnection:1'''||/upnp/control/'''wanipconnection1'''||[http://fritz.box:49000/wanipconnSCPD.xml wanipconnSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wanipconnSCPD.pdf wanipconnSCPD.pdf]
|-
|}

=== Status-Symbol ===
<code>attr <device> devStateIcon .*on.*off:WLAN_on_gWLAN_off .*on.*on.*:WLAN_on_gWLAN_on WLAN..off.*:WLAN_off</code>

Im Verzeichnis www/images/default müssen die passenden Dateien "WLAN_on_gWLAN_off.png", "WLAN_on_gWLAN_on.png" und "WLAN_off.png" liegen. Wenn die PNGs fehlen, können sie {{Link2Forum|Topic=29725|Message=318113|LinkText=hier}} heruntergeladen werden.

== Anwendungsbeispiele ==
[[Datei:Screenshot_FritzBox1.png|mini|300px|rechts|FRITZBOX Gerät auf der FHEM Oberfläche]]
Sollte alles geklappt haben, seht ihr nun unter "Unsortiert" den im nebenstehenden Screenshot gezeigten Eintrag für das "Gerät" (hier mit dem Icon "it_router").

=== TR-064 Beispiele ===
*Box Reboot: <code>get <device> tr064Command DeviceConfig:1 deviceconfig Reboot</code>
*Internet Reconnect: <code>get <device> tr064Command WANIPConnection:1 wanipconnection1 ForceTermination</code>
*Daten eines Smart-Home-Gerätes auslesen: <code>get <device> tr064Command X_AVM-DE_Homeauto:1 x_homeauto GetGenericDeviceInfos NewIndex 0</code>

=== Klingel- und Sprachausgabe per TR-064 ===
Das geht derzeit nicht, da entsprechende Kommandos per TR-064 nicht verfügbar sind. Da Telnet sukzessive abgestellt wird, sollten sich Interessenten per Feature-Request an AVM wenden, wie {{Link2Forum|Topic=38586|LinkText=hier}} beschrieben.

Eine Alternative um Telefone klingeln zu lassen, ist die Nutzung des [[SIP-Client]]s.

=== Anwesenheitserkennung per regelmäßiger Abfrage über das PRESENCE Modul ===
Fritzboxen und die FRITZ!WLAN Repeater speichern den Status angemeldeter Geräte. Dieser Status lässt sich mittels des FRITZBOX Moduls über Readings abfragen, die das Format mac_AA_AA_AA_AA_AA_AA haben und die MAC-Adressen der jeweils angemeldeten Geräte (AA:AA:AA:AA:AA:AA) enthalten. Das Reading existiert, wenn das Gerät angemeldet ist. Wenn das Gerät abgemeldet ist, existiert es nicht mehr. Es gibt auch noch den Zwischenstatus "inactive", der anscheinend gesetzt wird, bevor das Reading gelöscht wird.

Mit Hilfe des [[PRESENCE]] Moduls (vgl. [[Anwesenheitserkennung]]) kann man auf diese Weise den Anwesenheitsstatus abfragen. Anregungen dazu gibt es im zugehörigen {{Link2Forum|Topic=39433|LinkText=Forenthread}} zur Anwesenheitserkennung und in [http://heinz-otto.blogspot.de/2015/07/die-zeiten-andern-sich.html diesem Blogpost]. Auf dieser Basis könnte eine einfache Implementierung zum Beispiel so aussehen:

Funktion in [[99_myUtils anlegen|99_myUtils]]:

<syntaxhighlight lang='perl'>sub checkFritzMACpresent($$) {
# Benötigt: Name der zu testenden Fritzbox ($Device),
# zu suchende MAC ($MAC),
# Rückgabe: 1 = Gerät gefunden
# 0 = Gerät nicht gefunden
my ($Device, $MAC) = @_;
my $Status = 0;
$MAC =~ tr/:/_/;
$MAC = "mac_".uc($MAC);
my $StatusFritz = ReadingsVal($Device, $MAC, "weg");
if ($StatusFritz eq "weg") {
Log 1, ("checkFritzMACpresent ($Device): $MAC nicht gefunden, abwesend.");
$Status = 0;
} elsif ($StatusFritz eq "inactive") {
Log 1, ("checkFritzMACpresent ($Device): $MAC ist >inactive<, also abwesend.");
$Status = 0;
} else {
# Reading existiert, Rückgabewert ist nicht "inactive", also ist das Gerät per WLAN angemeldet.
Log 4, ("checkFritzMACpresent ($Device): $MAC gefunden, Gerät heißt >$StatusFritz<.");
$Status = 1;
}
return $Status
}
</syntaxhighlight>

Nutzung dieser Funktion mit dem PRESENCE Modul definieren:
:<code>define <Name> PRESENCE function {checkFritzMACpresent("Fritzbox","AA:BB:CC:DD:EE:FF")} 60 60</code>
wobei
*<Name> ein beliebig zu wählender Name für die PRESENCE-Funktion ist,
*Fritzbox der Name ist, mit dem ihr die abzufragende Fritzbox als FRITZBOX definiert habt,
*AA:BB:CC:DD:EE:FF die MAC-Adresse des gesuchten Geräts ist.
* "60 60" sagt, dass der Anwesenheitsstatus im 60-Sekunden-Takt abgefragt wird. Das macht natürlich nur Sinn, wenn ihr mit <code>attr Fritzbox INTERVAL 60</code> den Abfrageinterval bei der Fritzbox auch entsprechend hochgesetzt habt. Der Standard ist 300.
* "Log 1" führt immer zum Loggen. Das ist zum Einrichten praktisch, ohne dass man gleich für das ganze Modul oder ganz FHEM <code>attr <device> verbose 5</code> setzen muss. Wenn es läuft, können die "Log 1"-Zeilen gelöscht, auskommentiert (# an den Zeilenanfang) oder in "Log 5" geändert werden.

=== Anwesenheitserkennung über mehrere Fritzboxen oder AVM Repeater und Fritzbox ===
Existiert ein AVM Repeater im Netzwerk, kann der als eigenständiges Gerät mit FRITZBOX definiert werden. WLAN Geräte an der Fritzbox werden in der Instanz der Fritzbox gelistet und WLAN Geräte am Repeater in der Repeater Instanz. Um trotzdem die Anwesenheit im Netzwerk einfach zu erkennen, muss die Subroutine in 99_myUtils.pm abgewandelt werden.

Existiert eine zweite Fritzbox im Accesspointmodus, werden die WLAN Geräte im Netzwerk alle in der Hauptfritzbox an einem LAN Anschluss gelistet. D.h. man sieht an der Hauptfritzbox nicht, dass sie im WLAN sind. Eine zweite Instanz mit dem FRITZBOX Modul muss wegen der Anwesenheitserkennung nicht gemacht werden. Die folgende Routine kann aber universell eingesetzt werden, unabhängig von der Anzahl der FRITZBOX Instanzen. Wer mitloggen will, kann das analog zur obigen Routine einbauen

<syntaxhighlight lang='perl'>sub checkAllFritzMACpresent($) {
# Benötigt: nur die zu suchende MAC ($MAC),
# Es werden alle Instanzen vom Type FRITZBOX abgefragt
#
# Rückgabe: 1 = Gerät gefunden
# 0 = Gerät nicht gefunden
my ($MAC) = @_;
# Wird in keiner Instanz die MAC Adresse gefunden bleibt der Status 0
my $Status = 0;
$MAC =~ tr/:/_/;
$MAC = "mac_".uc($MAC);
my @FBS = devspec2array("TYPE=FRITZBOX");
foreach( @FBS ) {
my $StatusFritz = ReadingsVal($_, $MAC, "weg");
if ($StatusFritz eq "weg") {
} elsif ($StatusFritz eq "inactive") {
} else {
# Reading existiert, Rückgabewert ist nicht "inactive", also ist das Gerät am Netzwerk angemeldet.
$Status = 1;
}
}
return $Status
}
</syntaxhighlight>

Da hiermit nach allen Instanzen mit dem TYPE=FRITZBOX durchsucht wird, braucht der Name der Fritzbox nicht angegeben werden.

:<code>define <Name> PRESENCE function {checkAllFritzMACpresent("AA:BB:CC:DD:EE:FF")} 60 60</code>

Die Abfrage auf einen bestimmten Status kann einfach erweitert werden, ist aber immer vom Entwicklunsgstand der Fritzbox Firmware und des FRITZBOX Moduls abhängig. Eventuell erreicht man bessere Reaktionszeiten auf Abwesenheit durch diesen Zusatz:
<syntaxhighlight lang='perl'>my $StatusFritz = ReadingsVal($_, $MAC, "weg");
if ($StatusFritz eq "weg") {
} elsif ($StatusFritz eq "inactive") {
} elsif ($StatusFritz =~ /(.*)s, 0/) {
# Dieser Zweig testet auf "<geraetename> (WLAN, 0 / 0 Mbit/s, 0)"
} else {
$Status = 1;
}
</syntaxhighlight>

Weitere Hinweise zu komplexeren Abfragen mehrere Boxen auf einmal etc. findet ihr auch im diesem {{Link2Forum|Topic=39433|LinkText=Forenthread}}.

=== Anwesenheitserkennung per Notify ===
Der von Fritzboxen und Fritz!WLAN Repeatern gespeicherte Status zum Status angemeldeter Geräte lässt sich (statt per PRESENCE, s.o.) auch per [[notify]] anfragen:

<syntaxhighlight lang="perl">define <Name> notify Fritzbox:mac_AA_BB_CC_DD_EE_FF:.* {
if (ReadingsVal("Fritzbox", "mac_AA_BB_CC_DD_EE_FF", "inactive") eq "inactive")
{
fhem("set anwesend_smartphone absent");
}
else
{
fhem("set anwesend_smartphone present");
}
}</syntaxhighlight>

Hinweise:
* <code>fhem("set anwesend_smartphone absent");</code> ist nur ein Beispiel, das einen Dummy auf den Status "absent" bzw. "present" setzt. Man kann hier natürlich auch gleich entsprechende Aktionen durchführen. Wer das Beispiel übernehmen möchte, sollte den Dummy vorher definieren (<code>define anwesend_smartphone dummy</code>).
* mac_AA_BB_CC_DD_EE_FF ist die MAC-Adresse des gesuchten Geräts.
* "Fritzbox" ist der Name, unter dem die Fritzbox als FRITZBOX-Modul definiert wurde.
* Das Notify funktioniert, weil Geräte, wenn sie sich abgemeldet haben, erst den Status "inactive" erhalten. Ist das Gerät ganz abgemeldet, verschwindet das mac_.*-Reading. Dabei löst das Notify nicht mehr aus. Da das mac-.*-Reading aber vorher auf "inactive" stand, wurde die Abwesend-Aktion schon ausgeführt.
* Damit der Notify nicht andauernd losgeht, sollte man mittels <code>attr Fritzbox [[event-on-change-reading]] mac_AA_BB_CC_DD_EE_FF</code> Events nur auslösen, wenn sich der Status des Gerätes ändert. Will man mehrere Geräte abfragen, sollte man <code>attr Fritzbox event-on-change-reading mac_AA_BB_CC_DD_EE_FF,mac_GG_HH_II_JJ_KK_LL</code> setzen, damit bei der Änderung jedes Readings ein Event ausgelöst wird.

=== Vergleich Anwesenheitserkennung PRESENCE/Notify ===
Die Anwesenheitserkennung per regelmäßiger PRESENCE-Abfrage hat den Vorteil, dass sie im Turnus der regelmäßigen Abfragen immer einen aktuellen Status produziert. Sie hat dafür den Nachteil, dass die PRESENCE-Funktionen regelmäßig abgearbeitet werden müssen, auch wenn sich gar nichts ändert. Außerdem aktualisiert sich der Status nicht sofort, sondern erst bei der nächsten regelmäßigen Abfrage. Durch häufiges Abfragen kann dieser Nachteil verringert werden (bei entsprechend höherer Systemlast).

Die Anwesenheitserkennung per Notify hat den Vorteil, dass ein sich ändernder Status sofort abgebildet wird. Ändert sich kein Status, werden keine Routinen ausgeführt, was die Systemlast gering hält. Der Nachteil ist, dass - z.B. nach einem Systemstart - die entsprechende Aktion erst bei einer Änderung des Status ausgeführt wird. D.h. ist das zu testende Gerät anwesend, wird dann FHEM beendet, das Gerät entfernt und FHEM wieder gestartet, ist der Status in FHEM immer noch "anwesend". Da das Reading für das Gerät nicht existiert, wird darauf auch erst wieder ein Notify ausgeführt, wenn sich der Status des Geräts wieder ändert, d.h. es wieder ankommt. Bis dahin ist der Status im System falsch.
Der Nachteil des Notify kann verringert werden, wenn man statt <code>attr Fritzbox event-on-change-reading mac_AA_BB_CC_DD_EE_FF</code> ein <code>attr Fritzbox [[event-on-update-reading]] mac_AA_BB_CC_DD_EE_FF</code> setzt. Das erhöht allerdings die Systemlast und funktioniert auch nur für den Status "anwesend". Bei "abwesend" ist kein Reading vorhanden, so dass auch event-on-update-reading nicht ausgeführt wird.
Eine weitere Möglichkeit, den Nachteil der Notify-Methode auszugleichen, ist, die Statusabfrage beim Systemstart einmal manuell auszuführen, durch ein notify auf "GLOBAL:initialized":
<syntaxhighlight lang="perl">
global:INITIALIZED {
Reset_Variables;
if (ReadingsVal("Fritzbox", "mac_AA_BB_CC_DD_EE_FF", "inactive") eq "inactive") {
fhem("set anwesend_smartphone absent");
} else {
fhem("set anwesend_smartphone present");
}
}
</syntaxhighlight>
Das hilft allerdings nur beim Systemstart. Nicht, wenn FHEM aufgrund irgendwelcher Hänger eine Aktualisierung des Status verpasst hat.

=== userReadings per ''get tr064Command'' oder ''get luaQuery'' ===
Um dem Gerätewert <userReadingName> den Wert von <VariabelName> aus der Rückgabe des get-Befehls ''tr064Command'' oder ''luaQuery'' zuzuordnen
<pre>
attr <device> userReadings <userReadingName> {my $resp=fhem("get <device> tr064Command <service> <control> <action> [[<argName1> <argValue1>] ...]",1);;$resp =~/\'<VariabelName>\' => '(.*)'/;;return $1;;}
</pre>
Beispielsweise
<pre>attr Fritzbox userReadings urMobilteil_1 {my $resp=fhem("get Fritzbox tr064Command X_AVM-DE_OnTel:1 x_contact GetDECTHandsetInfo NewDectID 1",1);;$resp =~/'NewHandsetName' => '(.*)'/;;return $1;;},
urDownstreamDSLRate {my $resp=fhem("get Fritzbox tr064Command WANDSLInterfaceConfig:1 wandslifconfig1 GetInfo",1);;$resp =~/'NewDownstreamCurrRate' => '(.*)'/;;return $1;;},
urUpstreamDSLRate {my $resp=fhem("get Fritzbox tr064Command WANDSLInterfaceConfig:1 wandslifconfig1 GetInfo",1);;$resp =~/'NewUpstreamCurrRate' => '(.*)'/;;return $1;;}</pre>
oder bei einzelnen Werte über ''get luaQuery''<pre>attr Fritzbox userReadings sip1_connect {my $resp=fhem("get Fritzbox luaQuery sip:settings/sip1/connect",1);;$resp =~/([0-9])$/;;return $1;;}</pre>

=== Klingelton-Einstellung und Abspielen von Sprachnachrichten bei Fritz!OS-Versionen >6.24 ===
Wenn die Fritzbox weder die Telnet- noch die webcmd-Schnittstelle hat, kann der Klingelton der Fritz!Fons nicht mehr verstellt und auch keine Sprachnachricht über ein Fritz!Fon ausgegeben werden.

Es gibt eine Behelfslösung über das Attribut ''useGuiHack''. Dadurch wird eine Eingabe in die WebGUI der Fritzbox simuliert.

'''ACHTUNG''': Vor allem nach einem Update der FritzBox kann es durch dieses Attribut zu ungewolltem Verstellen von Werten in der Fritzbox kommen.

Bei Verwendung der ring-Parameter "play:" und "say:" wird die abzuspielende URL in die M3U-Datei, die unter dem Internal ''M3U_LOCAL'' steht, eingetragen.<br>
Standardmäßig wird versucht, diese Datei im image-Verzeichnis von FHEM abzulegen. Diese kann dann vom Fritz!Fon über [[FHEMWEB]] abgespielt werden (IP-Freigaben beachten). Direkt nach dem ersten Anlegen der m3u-Datei kennt [[FHEMWEB]] diese noch nicht, daher bitte entweder ''set <webdevice> rereadicons'' ausführen oder FHEM neu starten.<br>

Aufgrund der Beschränkungen von [[FHEMWEB]] oder auch bei Authentifizierungsanforderungen ist es empfehlenswert, die Datei über das Attribute ''m3uFileLocal'' selber vorzugeben. Am besten auf einem Webserver, der auf dem FHEM-Server läuft und dessen Seiten-Verzeichnis durch FHEM beschreibbar ist.<br>
Beispiel: <code>attr Fritzbox m3uFileLocal /var/www/mp3/Fritzbox.m3u</code>

In dem Radioeintrag ''FHEM'' muss dann '''auf der FritzBox''', die '''Web'''-Adresse der entsprechenden Datei eingetragen werden. Dieser Sender sollte zu Testzwecken dann auch einmal am Fritz!Fon von Hand gestartet werden.<br>
Das Modul versucht, beim Start die einzutragende Radio-URL im image-Verzeichnis selber zu ermitteln (IP-Freigabe beachten). Gelingt dies, so steht diese im Internal ''M3U_URL''.

=== Ring auf mehreren Telefonen gleichzeitig ===

Damit mehrere Telefone per ring gleichzeitig Klingel, muss in der Fritzbox eine Rufgruppe definiert werden.
Sollte eine Türsprechanlage schon in Benutzung sein, kann die eventuell hierfür bereits eingerichtete Gruppe verwendet werden.
Das anlegen der Gruppe erfolgt wie in folgender AVM Anleitung erledigt werden. [http://http://avm.de/service/fritzbox/fritzbox-7390/wissensdatenbank/publication/show/1148_Interne-Rufgruppe-in-FRITZ-Box-einrichten-Gruppenruf/ AVM Interne Rufgruppe anlegen]

Es muss eine Kurzwahl bei der Gruppe zwingend hinterlegt sein.
Danach kann mit folgendem Beispiel Code gearbeitet werden:

<code>set FritzBox ring 791 15 show:Türklingel</code>

Name des Devices, Rufgruppen Nummer, Länge und gezeigter Text auf das gewünschte anpassen.

== Bekannte Probleme / Fehlersuche ==
=== Fehler nach Firmware Update===
Nach einem Firmwareupdate der Fritzbox am besten auch FHEM neu starten.

=== Modul bleibt im Status "Check APIs" hängen===
Im Log steht die Meldung: "Error: Timeout when reading Fritz!Box data.".

Mögliche Ursache: Nutzung des FHEM-Befehls [[FHEM_Command_Beispiele#rereadcfg|rereadcfg]]. Dieser verträgt sich nicht mit dem Modul "blocking.pm", das für parallel laufende FHEM-Prozesse genutzt wird.

Abhilfe schafft ein Neustart <code>shutdown restart</code> oder das Einfügen eines zusätzlichen, lokalen Telnet-Ports z.B. durch <code>define tPortLocal telnet 7073</code>

=== Nachtschaltung Doppel-WLAN ===
Beim Abschalten des WLAN über das Modul wird (über TR064) zuerst das 2.4 GHz und dann das 5 GHz WLAN ausgeschaltet. Bei der gleichzeitigen Nutzung der WLAN-Nachtschaltung (Anschalten über das Fritz!OS) wird dann jedoch nur noch das 5 GHz WLAN wieder angeschaltet. Die Box interpretiert den TR064-Befehl anscheinend als ein komplettes Abwählen des 2.4 GHz WLAN.

Abhilfe schafft hier nur ein notify auf das 5 GHz WLAN mit einem nachträglichem Anschalten des 2.4 GHz WLAN.

Alternativ kann das Ausschalten des WLANs nicht direkt über TR064-Kommandos, sondern über einen indirekten Weg erfolgen: über TR064 ein set call abzusetzen und hier den Tastencode zum Ausschalten des WLANs einzugeben, bei einer FritzBox 7490 wäre dies z. B. #96*0*.
Schaltet man über diese Methode das WLAN aus, kann es über die Nachtschaltung wieder automatisch auf beiden Frequenzen angeschaltet werden.

=== Kabelboxen ===
Bei Fritz!Boxen für den Kabelanschluss (z.B. Kabel Deutschland) scheint neben Telnet auch die TR064-API nicht zu funktionieren. Vermutlich wurde die API von AVM auf Betreiberwunsch deaktiviert, da man sonst Dinge ändern kann, die das gesamte Kabelnetz stören können.

Zumindest für Unitymedia und einer FRITZ!Box 6490 Cable (lgi) mit FRITZ!OS:06.50 funktioniert TR064.

Eine Rufumleitung bei Abwesenheit (Modul PRESENCE) funktioniert mit einer vorher eingerichten Telefonnummer wie folgt:
<code>define Rufumleitung DOIF ([Anwesenheit.dum:state] eq "off") (set FritzBox6490 diversity 1 on) DOELSEIF ([Anwesenheit.dum:state] eq "on") (set FritzBox6490 diversity 1 off)</code>

=== Wenn's nicht klingelt ===
Das Klingeln erfolgt über die Wählhilfe. Eventuell muss über die Weboberfläche der Fritz!Box ein anderer Port eingestellt werden. Der aktuelle steht in "box_stdDialPort".

=== TR064-Transport-Error: 500 Can't connect to ...:49443 (certificate verify failed) ===
Eventuell hilft es, die Perl Module Net::HTTPS, Net::SSL und IO::Socket::SSL zu aktualisieren.

=== "Error: Old SID not valid anymore." nach Erlauben von IPv6 auf der Fritzbox ===
Ohne hier den genauen Grund zu kennen - es hilft die Angabe der IPv4-Adresse: also statt <code>define FritzBox FRITZBOX</code> dann <code>define FritzBox FRITZBOX <IP></code> (z.B. <code>define FritzBox FRITZBOX 192.168.10.1</code>), so dass das Modul nicht über IPv6 geht.

=== "Didn't get a session ID" ===
Bei gleichzeitiger Nutzung anderer Modul für die Fritzbox (z.B. {{Link2CmdRef|Anker=FBAHAHTTP|Lang=en|Label=FBAHAHTTP}}) muss der Zugang über Benutzername und Password erfolgen.<br>
:<code>attr <DEVICE> boxUser <USER></code>
Da das FRITZBOX-Modul eine inoffizielle Schnittstelle benutzt, muss dann auch der normale Zugang zur Box auf "Benutzername und Password" eingestellt sein.<bR>
In der Firmware 6.92 wird der Zugang über die Menüs "System"->"Fritz!Box-Benutzer"->"Anmeldung im Heimnetz" eingestellt.

Oft wird aber auch ein falsches oder gar kein Passwort gesetzt.

:<code>set <DEVICE> password <PASSWORD></code>

=== TR064-Error 401:invalid action ===
Eventuell ist auf der Fritzbox ein Benutzer gesetzt und im Modul nicht korrekt angegeben bzw. mit falschen Rechten versehen (attribut boxUser).

== Links ==
* {{Link2Forum|Topic=29725|LinkText=Forenthread}} zu diesem Modul

[[Kategorie:FritzBox]]

SolarEdge Wechselrichter

2018-09-03T14:21:57Z

Benni: /* SunSpec (SolarEdge) */

{{Infobox Hardware
|Bild=platzHalter.png
|Bildbeschreibung=SolarEdge SE10k
|HWProtocol=Modubus TCP
|HWType=Wechselrichter
|HWCategory=Energieverbrauchsmessung
|HWComm=Ethernet TCP
|HWChannels=1 (bidiektional)
|HWVoltage=750V DC; 230V 3xAC
|HWPowerConsumption=Eigenverbrauch 2% (geschätzt)
|HWPoweredBy=230V~ 3xAC
|HWSize=317x512x214 (mm)
|HWDeviceFHEM=[http://fhem.de/commandref.html#ModbusAttr ModbusAttr]
|HWManufacturer=[https://www.solaredge.com/de Solaredge]
}}

== SE10k von Solaredge in FHEM einbinden==

Dieser Artikel beschreibt die Einbindung eines Solaredgewechselrichters SE10k in ein FHEM System über eine Ethernetverbindung mit Hilfe des Moduls ModbusAttr.

=== Vorbedingungen ===

FHEM läuft und hat genügend Platz für Modifikationen und Logfiles (ca. 100 MByte / Jahr).

=== Am Wechselrichter ===

Im zugehörigen Menu ist bereits der Port 502 eingestellt. Trotzdem muss dieser noch einmal aktiviert werden, da sonst Modbus TCP nicht aktiv wird.
Hilfe da zu bietet die Installationsanleitung [1]. <br>
Es ist möglich, dass es auch nur 10 Minuten aktiv bleibt wenn er nicht angesprochen wird.

== ModbusAttr Device in FHEM ==

in FHEM wird ein ModbusAttr angelegt

<code> define SolarEdge ModbusAttr 1 30 192.168.178.36 TCP </code>

danach alle Attribute aus dem unten stehenden list nach dem Verfahren:
<code> attr SolarEdge dev-h-defPoll 1 </code>

Mehr Daten sind im Sunspec Protokoll [2] zu finden

=== List von Device Solaredge in FHEM ===
<pre>
Internals:
BUSY 0
DEF 1 30 192.168.178.36 TCP
DEST 192.168.178.36:502
DeviceName 192.168.178.36:502
FD 91
INTERVAL 600
IODev KeSolarEdge
LASTOPEN 1523044866.65275
MODBUSID 1
ModuleVersion 3.7.3 - 22.12.2017
NAME KeSolarEdge
NOTIFYDEV global
NR 354
NTFY_ORDER 50-KeSolarEdge
PARTIAL
PROTOCOL TCP
REQUESTHEX 00270000000601039c940001
STATE 0 W; 1718 kWh
TRIGGERTIME 1523048587.13296
TRIGGERTIME_FMT 2018-04-06 23:03:07
TYPE ModbusAttr
devioLoglevel 4
nextOpenDelay 60
QUEUE:
READINGS:
2018-04-06 22:53:07 AC-Energy 1717.665
2018-04-06 22:53:07 AC-Energy-Scale 0
2018-04-06 22:53:07 AC-Energy-Val 1717665
2018-04-06 22:58:10 AC-Power 0
2018-04-06 22:58:10 AC-Power-Scale 0
2018-04-06 22:58:10 AC-Power-Val 0
2018-04-06 22:53:07 DC-Current 0
2018-04-06 22:53:07 DC-Current-Scale -32768
2018-04-06 22:53:07 DC-Current-Val 65535
2018-04-06 22:53:07 DC-Power 0
2018-04-06 22:53:07 DC-Power-Scale 0
2018-04-06 22:53:07 DC-Power-Val 0
2018-04-06 22:53:07 DC-Voltage 0
2018-04-06 22:53:07 DC-Voltage-Scale -1
2018-04-06 22:53:07 DC-Voltage-Val 0
2018-04-06 22:53:07 HeatSinkTemp 0
2018-04-06 22:53:07 Status 2
2018-04-06 22:53:07 Zustand Nachtmodus
2018-04-06 22:01:06 state opened
defptr:
1:
gotReadings:
AC-Power-Scale 0
helper:
buffer
lid 1
lrecv 1523048290.49688
lsend 1523048290.48976
lastRead:
h40083 1523048290.48193
h40084 1523048290.50143
h40093 1523047987.08669
h40095 1523047987.09043
h40096 1523047987.09428
h40097 1523047987.09784
h40098 1523047987.10153
h40099 1523047987.10505
h40100 1523047987.10867
h40101 1523047987.11226
h40103 1523047987.1158
h40107 1523047987.11994
Attributes:
dev-h-combine 200
dev-h-defPoll 1
dev-h-defShowGet 1
enableControlSet 1
event-on-change-reading .*
event-on-update-reading AC-Energy,AC-Energy-Scale,AC-Power-Scale,DC-Voltage-Scale,DC-Current-Scale,DC-Power-Scale,Status
maxTimeoutsToReconnect 3
obj-h40083-reading AC-Power-Val
obj-h40084-reading AC-Power-Scale
obj-h40084-unpack s>
obj-h40093-len 2
obj-h40093-reading AC-Energy-Val
obj-h40093-unpack l>
obj-h40095-reading AC-Energy-Scale
obj-h40096-reading DC-Current-Val
obj-h40097-reading DC-Current-Scale
obj-h40097-unpack s>
obj-h40098-reading DC-Voltage-Val
obj-h40099-reading DC-Voltage-Scale
obj-h40099-unpack s>
obj-h40100-reading DC-Power-Val
obj-h40101-reading DC-Power-Scale
obj-h40101-unpack s>
obj-h40103-reading HeatSinkTemp
obj-h40103-unpack s>
obj-h40107-reading Status
room Solar,SolarPV,SolarReport
silentReconnect 1
sortUpdate 1
stateFormat {sprintf("%.0f W; %.0f kWh",ReadingsVal("KeSolarEdge","AC-Power",0),ReadingsVal("KeSolarEdge","AC-Energy",0))}
userReadings AC-Energy:(AC-Energy-Scale.*) {
my $scale = ReadingsVal ("KeSolarEdge","AC-Energy-Scale",0);
return (ReadingsVal ("KeSolarEdge","AC-Energy-Val",0) * ( 10 ** $scale) / 1000);;},

AC-Power:(AC-Power-Scale.*) {
my $scale = ReadingsVal ("KeSolarEdge","AC-Power-Scale",0);
return (ReadingsVal ("KeSolarEdge","AC-Power-Val",0) * ( 10 ** $scale));;},

DC-Power:(DC-Power-Scale.*) {
my $scale = ReadingsVal ("KeSolarEdge","DC-Power-Scale",0);
return (ReadingsVal ("KeSolarEdge","DC-Power-Val",0) * ( 10 ** $scale));;},

DC-Current:(DC-Current-Scale.*) {
my $scale = ReadingsVal ("KeSolarEdge","DC-Current-Scale",0);
return (ReadingsVal ("KeSolarEdge","DC-Current-Val",0) * ( 10 ** $scale));;},

DC-Voltage:(DC-Voltage-Scale.*) {
my $scale = ReadingsVal ("KeSolarEdge","DC-Voltage-Scale",0);
return (ReadingsVal ("KeSolarEdge","DC-Voltage-Val",0) * ( 10 ** $scale));;},

Zustand:(Status.*) {
my $Zus = ReadingsVal("KeSolarEdge","Status",0);
my $rueck = ReadingsVal("KeSolarEdge","Zustand",0);
if (($Zus == 2) and (InternalVal("KeSolarEdge","INTERVAL","") != 600)) {
fhem("set KeSolarEdge interval 600");
$rueck = "Nachtmodus";
}
elsif (InternalVal("KeSolarEdge","INTERVAL","") != 60) {
fhem("set KeSolarEdge interval 60");
$rueck = "Tagmodus";
}
return ($rueck);;
}
webCmdLabel {sprintf("AC-Energy %.3f",ReadingsVal("Solaredge","AC-Energy",0));;}
</pre>

=== Dummys anlegen ===

Zur Verwendung der "at"s werden Dummys benötigt

<pre>
define dum_pv_energyday_log dummy
define dum_pv_energyday_read dummy
define dum_pv_energymonth_log dummy
define dum_pv_energymonth_read dummy
define dum_pv_energytoday dummy
define dum_pv_energytomonth dummy
define dum_pv_energytoweek dummy
define dum_pv_energytoyear dummy
define dum_pv_energyweek_log dummy
define dum_pv_energyweek_read dummy
define dum_pv_energyyear_log dummy
define dum_pv_energyyear_read dummy
define dum_pvdcpower dummy
define dum_pvdcvolt dummy
define dum_pvenergy dummy
define dum_pvloss dummy
define dum_pvpower_log dummy
define dum_pvpower_read dummy
</pre>

=== notify device in FHEM ===

Auslesen der Daten, getriggert vom ModbusAttr:

prg_solaredge

<pre>
KeSolarEdge:DC-Power:.* {
# 16.2.2018 Markus Loeben
# liest Solaredge aus und füllt die Werte in dummys, damit sie weiter verwertet werden können
my $ACE = ReadingsVal("KeSolarEdge","AC-Energy",0);
Log 5, "at_solaredge: ACE " . $ACE;
my $day = Value("dum_pv_energyday_read");
Log 5, "at_solaredge: day " . $day;
my $week = Value("dum_pv_energyweek_read");
Log 5, "at_solaredge: day " . $day;
my $month = Value("dum_pv_energymonth_read");
Log 5, "at_solaredge: month " . $month;
my $year = Value("dum_pv_energyyear_read");
Log 5, "at_solaredge: year " . $year;
#.. die geleistete Energie größer 0 ist (was immer sein sollte, aber leider nicht immer ist) -> laufende Werte berechnen
if ($ACE > 0) {
fhem ("set dum_pv_energytoday " . sprintf ("%.2f",($ACE - $day)));
fhem ("set dum_pv_energytoweek " . sprintf ("%.2f",($ACE - $week)));
fhem ("set dum_pv_energytomonth " . sprintf ("%.2f",($ACE - $month)));
fhem ("set dum_pv_energytoyear " . sprintf ("%.2f",($ACE - $year)));
}
#Log 1, "at_Solaredge: PV-Energy " . $ACE . "\n";
#Leistung auslesen
my $ACP = ReadingsVal("KeSolarEdge","AC-Power",0);
my $DCP = ReadingsVal("KeSolarEdge","DC-Power",0);
if ($DCP > 0) {
# Verlustleistung berechnen
fhem ("set dum_pvloss " . sprintf("%.1f", ($DCP - $ACP)));
my $MP = Value("dum_pv_power_read");
#Falls die größer ist als alles bis: ablegen
if ($DCP > $MP) {
fhem ("set dum_pv_power_read " . $DCP);
}
}
}
</pre>

=== at device in FHEM ===

Tägliches Auswerten für spätere SVGs:

at_midnight
<pre>
*23:59 {
# Abspeichern der täglichen, wöchentlichen und monatlichen Werte 16.3.18 Loeben;
use Time::Local;
my ($Psec,$Pmin,$Phour,$Pmday,$Pmonth,$Pyear,$Pwday,$Pyday,$Pisdst) = localtime(time()+61);
#Werte einlesen
my $ace = ReadingsVal("KeSolarEdge","AC-Energy",-1);
Log 5, "at_midnight AC-Energy" . " " . $ace;
#Tag updaten
# PV
my $aceread = Value("dum_pv_energyday_read");
Log 5, "at_midnight dum_pv_energyday_read " . $aceread;
my $aceday = ($ace - $aceread);
fhem ("set dum_pv_energyday_log " . sprintf("%.1f",($aceday)));
fhem ("set dum_pv_energyday_read " . $ace);
Log 5, "at_midnight dum_pv_energyday_read" . " " . $ace;
my $MP = Value("dum_pv_power_read");
fhem("set dum_pv_power_log " . $MP);
fhem("set dum_pv_power_read 0");

#Wochenwerte speichern;
if ($Pwday == 1) {
$aceread = Value("dum_pv_energyweek_read");
$aceday = ($ace - $aceread);
fhem ("set dum_pv_energyweek_log " . sprintf("%.1f",($ace - $aceread)));
fhem ("set dum_pv_energyweek_read " . $ace);
}
#Monatswerte speichern;
if ($Pmday == 1) {
$aceread = Value("dum_pv_energymonth_read");
$aceday = ($ace - $aceread);
fhem ("set dum_pv_energymonth_log " . sprintf("%.1f",($aceday)));
fhem ("set dum_pv_energymonth_read " . $ace);
}
#Jahreswerte speichern;
if ($Pyday == 1) {
$aceread = Value("dum_pv_energyyear_read");
$aceday = ($ace - $aceread);
fhem ("set dum_pv_energyyear_log " . sprintf("%.1f",($aceday)));
fhem ("set dum_pv_energyyear_read " . $ace);
}
}
</pre>

== Log ==

Das ModbusDevice legt sich ein eigenes Log an. Um aber übersichtliche Grafiken zu bekommen werden die Daten des Dummy benötigt. Hier hilft ein Logfile

<code> define FileLog_KePv Filelog %L/pv-%Y.log dum_pv*.* </code>

== Grafiken ==

{{Todo | Beschreibungen zu SVG hinterlegen }}

== SunSpec (SolarEdge) ==

Hier nochmal eine andere Variante der Attribut-Definition für ModbusAttr.
Diese Variante ist wesentlich enger an die Sunspec-Implementierung aus der SolarEdge-Dokumentation angelehnt, als die Definitionen in o.g. Beispiel-List.

<pre>
attr <DEVICE-NAME> obj-h40000-len 4
attr <DEVICE-NAME> obj-h40000-reading C_SunSpec_ID
attr <DEVICE-NAME> obj-h40000-unpack (a4)
attr <DEVICE-NAME> obj-h40004-len 16
attr <DEVICE-NAME> obj-h40004-reading C_Manufacturer
attr <DEVICE-NAME> obj-h40004-unpack (a16)
attr <DEVICE-NAME> obj-h40020-len 16
attr <DEVICE-NAME> obj-h40020-reading C_Model
attr <DEVICE-NAME> obj-h40020-unpack (a16)
attr <DEVICE-NAME> obj-h40044-len 8
attr <DEVICE-NAME> obj-h40044-reading C_Version
attr <DEVICE-NAME> obj-h40044-unpack (a8)
attr <DEVICE-NAME> obj-h40052-len 16
attr <DEVICE-NAME> obj-h40052-reading C_SerialNumber
attr <DEVICE-NAME> obj-h40052-unpack (a16)
attr <DEVICE-NAME> obj-h40068-reading C_DeviceAddress
attr <DEVICE-NAME> obj-h40069-reading C_PhaseDesign
attr <DEVICE-NAME> obj-h40070-reading C_SunSpec_Length
attr <DEVICE-NAME> obj-h40071-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Current_SF',0))
attr <DEVICE-NAME> obj-h40071-reading I_AC_Current
attr <DEVICE-NAME> obj-h40072-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Current_SF',0))
attr <DEVICE-NAME> obj-h40072-reading I_AC_CurrentA
attr <DEVICE-NAME> obj-h40073-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Current_SF',0))
attr <DEVICE-NAME> obj-h40073-reading I_AC_CurrentB
attr <DEVICE-NAME> obj-h40074-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Current_SF',0))
attr <DEVICE-NAME> obj-h40074-reading I_AC_CurrentC
attr <DEVICE-NAME> obj-h40075-reading I_AC_Current_SF
attr <DEVICE-NAME> obj-h40075-unpack s>
attr <DEVICE-NAME> obj-h40076-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Voltage_SF',0))
attr <DEVICE-NAME> obj-h40076-reading I_AC_VoltageAB
attr <DEVICE-NAME> obj-h40077-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Voltage_SF',0))
attr <DEVICE-NAME> obj-h40077-reading I_AC_VoltageBC
attr <DEVICE-NAME> obj-h40078-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Voltage_SF',0))
attr <DEVICE-NAME> obj-h40078-reading I_AC_VoltageCA
attr <DEVICE-NAME> obj-h40079-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Voltage_SF',0))
attr <DEVICE-NAME> obj-h40079-reading I_AC_VoltageAN
attr <DEVICE-NAME> obj-h40080-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Voltage_SF',0))
attr <DEVICE-NAME> obj-h40080-reading I_AC_VoltageBN
attr <DEVICE-NAME> obj-h40081-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Voltage_SF',0))
attr <DEVICE-NAME> obj-h40081-reading I_AC_VoltageCN
attr <DEVICE-NAME> obj-h40082-reading I_AC_Voltage_SF
attr <DEVICE-NAME> obj-h40082-unpack s>
attr <DEVICE-NAME> obj-h40083-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Power_SF',0))
attr <DEVICE-NAME> obj-h40083-reading I_AC_Power
attr <DEVICE-NAME> obj-h40083-unpack s>
attr <DEVICE-NAME> obj-h40084-reading I_AC_Power_SF
attr <DEVICE-NAME> obj-h40084-unpack s>
attr <DEVICE-NAME> obj-h40085-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Frequency_SF',0))
attr <DEVICE-NAME> obj-h40085-reading I_AC_Frequency
attr <DEVICE-NAME> obj-h40086-reading I_AC_Frequency_SF
attr <DEVICE-NAME> obj-h40086-unpack s>
attr <DEVICE-NAME> obj-h40087-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_VA_SF',0))
attr <DEVICE-NAME> obj-h40087-reading I_AC_VA
attr <DEVICE-NAME> obj-h40087-unpack s>
attr <DEVICE-NAME> obj-h40088-reading I_AC_VA_SF
attr <DEVICE-NAME> obj-h40088-unpack s>
attr <DEVICE-NAME> obj-h40089-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_VAR_SF',0))
attr <DEVICE-NAME> obj-h40089-reading I_AC_VAR
attr <DEVICE-NAME> obj-h40089-unpack s>
attr <DEVICE-NAME> obj-h40090-reading I_AC_VAR_SF
attr <DEVICE-NAME> obj-h40090-unpack s>
attr <DEVICE-NAME> obj-h40091-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_PF_SF',0))
attr <DEVICE-NAME> obj-h40091-reading I_AC_PF
attr <DEVICE-NAME> obj-h40091-unpack s>
attr <DEVICE-NAME> obj-h40092-reading I_AC_PF_SF
attr <DEVICE-NAME> obj-h40092-unpack s>
attr <DEVICE-NAME> obj-h40093-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Energy_WH_SF',0))
attr <DEVICE-NAME> obj-h40093-len 2
attr <DEVICE-NAME> obj-h40093-reading I_AC_Energy_WH
attr <DEVICE-NAME> obj-h40093-unpack I>
attr <DEVICE-NAME> obj-h40095-reading I_AC_Energy_WH_SF
attr <DEVICE-NAME> obj-h40096-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_DC_Current_SF',0))
attr <DEVICE-NAME> obj-h40096-reading I_DC_Current
attr <DEVICE-NAME> obj-h40097-reading I_DC_Current_SF
attr <DEVICE-NAME> obj-h40097-unpack s>
attr <DEVICE-NAME> obj-h40098-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_DC_Voltage_SF',0))
attr <DEVICE-NAME> obj-h40098-reading I_DC_Voltage
attr <DEVICE-NAME> obj-h40099-reading I_DC_Voltage_SF
attr <DEVICE-NAME> obj-h40099-unpack s>
attr <DEVICE-NAME> obj-h40100-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_DC_Power_SF',0))
attr <DEVICE-NAME> obj-h40100-reading I_DC_Power
attr <DEVICE-NAME> obj-h40100-unpack s>
attr <DEVICE-NAME> obj-h40101-reading I_DC_Power_SF
attr <DEVICE-NAME> obj-h40101-unpack s>
attr <DEVICE-NAME> obj-h40103-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_Temp_SF',0))
attr <DEVICE-NAME> obj-h40103-reading I_Temp_Sink
attr <DEVICE-NAME> obj-h40103-unpack s>
attr <DEVICE-NAME> obj-h40106-reading I_Temp_SF
attr <DEVICE-NAME> obj-h40106-unpack s>
attr <DEVICE-NAME> obj-h40107-reading I_Status
attr <DEVICE-NAME> obj-h40108-reading I_Status_Vendor
attr <DEVICE-NAME> userReadings uI_Status:I_Status.* {my $om=ReadingsNum($name,'I_Status',-1);;($om==2?'night':($om==4?'day':'off'))},\
uC_PhaseDesign:C_PhaseDesign.* {my $pd=ReadingsVal($name,'C_PhaseDesign','000');;($pd eq '101'?'single':($pd eq '102'?'split':($pd eq '103'?'3-phase':'unknown')))}
</pre>

<DEVICE-NAME> ist dabei natürlich durch den realen Namen des eigenen ModbusAttr-Devices zu ersetzen.

Zusätzlich sind hier auch zwei weiter userReadings definiert, die eine textliche Umsetzung für die Parameter C_PhaseDesign und I_Status vornehmen.

Die Folgende Datei enthält die entsprechenden Anpassungen an die SolarEdge-Dokumentation, die diesen Attribut-Definitionen zugrunde liegen.

[[Datei:FHEM-Solaredge_SunSpec_ModbusAttr.pdf]]

[[Kategorie:Other Components]]
[[Kategorie:Energieerzeugungsmessung]]

== Links ==
# Solaredge: [https://www.solaredge.com/sites/default/files/se-inverter-installation-guide-de.pdf Installationsanleitung]
# Solaredge: [https://www.solaredge.com/sites/default/files/sunspec-implementation-technical-note-de.pdf Sunspec Protokoll]

Datei:FHEM-Solaredge SunSpec ModbusAttr.pdf

2018-09-03T14:17:40Z

Benni: Angepasste Registerbeschreibung zur SolarEdge SunSpec-Implementation.

Angepasste Registerbeschreibung zur SolarEdge SunSpec-Implementation.

SolarEdge Wechselrichter

2018-09-03T14:12:51Z

Benni:

{{Infobox Hardware
|Bild=platzHalter.png
|Bildbeschreibung=SolarEdge SE10k
|HWProtocol=Modubus TCP
|HWType=Wechselrichter
|HWCategory=Energieverbrauchsmessung
|HWComm=Ethernet TCP
|HWChannels=1 (bidiektional)
|HWVoltage=750V DC; 230V 3xAC
|HWPowerConsumption=Eigenverbrauch 2% (geschätzt)
|HWPoweredBy=230V~ 3xAC
|HWSize=317x512x214 (mm)
|HWDeviceFHEM=[http://fhem.de/commandref.html#ModbusAttr ModbusAttr]
|HWManufacturer=[https://www.solaredge.com/de Solaredge]
}}

== SE10k von Solaredge in FHEM einbinden==

Dieser Artikel beschreibt die Einbindung eines Solaredgewechselrichters SE10k in ein FHEM System über eine Ethernetverbindung mit Hilfe des Moduls ModbusAttr.

=== Vorbedingungen ===

FHEM läuft und hat genügend Platz für Modifikationen und Logfiles (ca. 100 MByte / Jahr).

=== Am Wechselrichter ===

Im zugehörigen Menu ist bereits der Port 502 eingestellt. Trotzdem muss dieser noch einmal aktiviert werden, da sonst Modbus TCP nicht aktiv wird.
Hilfe da zu bietet die Installationsanleitung [1]. <br>
Es ist möglich, dass es auch nur 10 Minuten aktiv bleibt wenn er nicht angesprochen wird.

== ModbusAttr Device in FHEM ==

in FHEM wird ein ModbusAttr angelegt

<code> define SolarEdge ModbusAttr 1 30 192.168.178.36 TCP </code>

danach alle Attribute aus dem unten stehenden list nach dem Verfahren:
<code> attr SolarEdge dev-h-defPoll 1 </code>

Mehr Daten sind im Sunspec Protokoll [2] zu finden

=== List von Device Solaredge in FHEM ===
<pre>
Internals:
BUSY 0
DEF 1 30 192.168.178.36 TCP
DEST 192.168.178.36:502
DeviceName 192.168.178.36:502
FD 91
INTERVAL 600
IODev KeSolarEdge
LASTOPEN 1523044866.65275
MODBUSID 1
ModuleVersion 3.7.3 - 22.12.2017
NAME KeSolarEdge
NOTIFYDEV global
NR 354
NTFY_ORDER 50-KeSolarEdge
PARTIAL
PROTOCOL TCP
REQUESTHEX 00270000000601039c940001
STATE 0 W; 1718 kWh
TRIGGERTIME 1523048587.13296
TRIGGERTIME_FMT 2018-04-06 23:03:07
TYPE ModbusAttr
devioLoglevel 4
nextOpenDelay 60
QUEUE:
READINGS:
2018-04-06 22:53:07 AC-Energy 1717.665
2018-04-06 22:53:07 AC-Energy-Scale 0
2018-04-06 22:53:07 AC-Energy-Val 1717665
2018-04-06 22:58:10 AC-Power 0
2018-04-06 22:58:10 AC-Power-Scale 0
2018-04-06 22:58:10 AC-Power-Val 0
2018-04-06 22:53:07 DC-Current 0
2018-04-06 22:53:07 DC-Current-Scale -32768
2018-04-06 22:53:07 DC-Current-Val 65535
2018-04-06 22:53:07 DC-Power 0
2018-04-06 22:53:07 DC-Power-Scale 0
2018-04-06 22:53:07 DC-Power-Val 0
2018-04-06 22:53:07 DC-Voltage 0
2018-04-06 22:53:07 DC-Voltage-Scale -1
2018-04-06 22:53:07 DC-Voltage-Val 0
2018-04-06 22:53:07 HeatSinkTemp 0
2018-04-06 22:53:07 Status 2
2018-04-06 22:53:07 Zustand Nachtmodus
2018-04-06 22:01:06 state opened
defptr:
1:
gotReadings:
AC-Power-Scale 0
helper:
buffer
lid 1
lrecv 1523048290.49688
lsend 1523048290.48976
lastRead:
h40083 1523048290.48193
h40084 1523048290.50143
h40093 1523047987.08669
h40095 1523047987.09043
h40096 1523047987.09428
h40097 1523047987.09784
h40098 1523047987.10153
h40099 1523047987.10505
h40100 1523047987.10867
h40101 1523047987.11226
h40103 1523047987.1158
h40107 1523047987.11994
Attributes:
dev-h-combine 200
dev-h-defPoll 1
dev-h-defShowGet 1
enableControlSet 1
event-on-change-reading .*
event-on-update-reading AC-Energy,AC-Energy-Scale,AC-Power-Scale,DC-Voltage-Scale,DC-Current-Scale,DC-Power-Scale,Status
maxTimeoutsToReconnect 3
obj-h40083-reading AC-Power-Val
obj-h40084-reading AC-Power-Scale
obj-h40084-unpack s>
obj-h40093-len 2
obj-h40093-reading AC-Energy-Val
obj-h40093-unpack l>
obj-h40095-reading AC-Energy-Scale
obj-h40096-reading DC-Current-Val
obj-h40097-reading DC-Current-Scale
obj-h40097-unpack s>
obj-h40098-reading DC-Voltage-Val
obj-h40099-reading DC-Voltage-Scale
obj-h40099-unpack s>
obj-h40100-reading DC-Power-Val
obj-h40101-reading DC-Power-Scale
obj-h40101-unpack s>
obj-h40103-reading HeatSinkTemp
obj-h40103-unpack s>
obj-h40107-reading Status
room Solar,SolarPV,SolarReport
silentReconnect 1
sortUpdate 1
stateFormat {sprintf("%.0f W; %.0f kWh",ReadingsVal("KeSolarEdge","AC-Power",0),ReadingsVal("KeSolarEdge","AC-Energy",0))}
userReadings AC-Energy:(AC-Energy-Scale.*) {
my $scale = ReadingsVal ("KeSolarEdge","AC-Energy-Scale",0);
return (ReadingsVal ("KeSolarEdge","AC-Energy-Val",0) * ( 10 ** $scale) / 1000);;},

AC-Power:(AC-Power-Scale.*) {
my $scale = ReadingsVal ("KeSolarEdge","AC-Power-Scale",0);
return (ReadingsVal ("KeSolarEdge","AC-Power-Val",0) * ( 10 ** $scale));;},

DC-Power:(DC-Power-Scale.*) {
my $scale = ReadingsVal ("KeSolarEdge","DC-Power-Scale",0);
return (ReadingsVal ("KeSolarEdge","DC-Power-Val",0) * ( 10 ** $scale));;},

DC-Current:(DC-Current-Scale.*) {
my $scale = ReadingsVal ("KeSolarEdge","DC-Current-Scale",0);
return (ReadingsVal ("KeSolarEdge","DC-Current-Val",0) * ( 10 ** $scale));;},

DC-Voltage:(DC-Voltage-Scale.*) {
my $scale = ReadingsVal ("KeSolarEdge","DC-Voltage-Scale",0);
return (ReadingsVal ("KeSolarEdge","DC-Voltage-Val",0) * ( 10 ** $scale));;},

Zustand:(Status.*) {
my $Zus = ReadingsVal("KeSolarEdge","Status",0);
my $rueck = ReadingsVal("KeSolarEdge","Zustand",0);
if (($Zus == 2) and (InternalVal("KeSolarEdge","INTERVAL","") != 600)) {
fhem("set KeSolarEdge interval 600");
$rueck = "Nachtmodus";
}
elsif (InternalVal("KeSolarEdge","INTERVAL","") != 60) {
fhem("set KeSolarEdge interval 60");
$rueck = "Tagmodus";
}
return ($rueck);;
}
webCmdLabel {sprintf("AC-Energy %.3f",ReadingsVal("Solaredge","AC-Energy",0));;}
</pre>

=== Dummys anlegen ===

Zur Verwendung der "at"s werden Dummys benötigt

<pre>
define dum_pv_energyday_log dummy
define dum_pv_energyday_read dummy
define dum_pv_energymonth_log dummy
define dum_pv_energymonth_read dummy
define dum_pv_energytoday dummy
define dum_pv_energytomonth dummy
define dum_pv_energytoweek dummy
define dum_pv_energytoyear dummy
define dum_pv_energyweek_log dummy
define dum_pv_energyweek_read dummy
define dum_pv_energyyear_log dummy
define dum_pv_energyyear_read dummy
define dum_pvdcpower dummy
define dum_pvdcvolt dummy
define dum_pvenergy dummy
define dum_pvloss dummy
define dum_pvpower_log dummy
define dum_pvpower_read dummy
</pre>

=== notify device in FHEM ===

Auslesen der Daten, getriggert vom ModbusAttr:

prg_solaredge

<pre>
KeSolarEdge:DC-Power:.* {
# 16.2.2018 Markus Loeben
# liest Solaredge aus und füllt die Werte in dummys, damit sie weiter verwertet werden können
my $ACE = ReadingsVal("KeSolarEdge","AC-Energy",0);
Log 5, "at_solaredge: ACE " . $ACE;
my $day = Value("dum_pv_energyday_read");
Log 5, "at_solaredge: day " . $day;
my $week = Value("dum_pv_energyweek_read");
Log 5, "at_solaredge: day " . $day;
my $month = Value("dum_pv_energymonth_read");
Log 5, "at_solaredge: month " . $month;
my $year = Value("dum_pv_energyyear_read");
Log 5, "at_solaredge: year " . $year;
#.. die geleistete Energie größer 0 ist (was immer sein sollte, aber leider nicht immer ist) -> laufende Werte berechnen
if ($ACE > 0) {
fhem ("set dum_pv_energytoday " . sprintf ("%.2f",($ACE - $day)));
fhem ("set dum_pv_energytoweek " . sprintf ("%.2f",($ACE - $week)));
fhem ("set dum_pv_energytomonth " . sprintf ("%.2f",($ACE - $month)));
fhem ("set dum_pv_energytoyear " . sprintf ("%.2f",($ACE - $year)));
}
#Log 1, "at_Solaredge: PV-Energy " . $ACE . "\n";
#Leistung auslesen
my $ACP = ReadingsVal("KeSolarEdge","AC-Power",0);
my $DCP = ReadingsVal("KeSolarEdge","DC-Power",0);
if ($DCP > 0) {
# Verlustleistung berechnen
fhem ("set dum_pvloss " . sprintf("%.1f", ($DCP - $ACP)));
my $MP = Value("dum_pv_power_read");
#Falls die größer ist als alles bis: ablegen
if ($DCP > $MP) {
fhem ("set dum_pv_power_read " . $DCP);
}
}
}
</pre>

=== at device in FHEM ===

Tägliches Auswerten für spätere SVGs:

at_midnight
<pre>
*23:59 {
# Abspeichern der täglichen, wöchentlichen und monatlichen Werte 16.3.18 Loeben;
use Time::Local;
my ($Psec,$Pmin,$Phour,$Pmday,$Pmonth,$Pyear,$Pwday,$Pyday,$Pisdst) = localtime(time()+61);
#Werte einlesen
my $ace = ReadingsVal("KeSolarEdge","AC-Energy",-1);
Log 5, "at_midnight AC-Energy" . " " . $ace;
#Tag updaten
# PV
my $aceread = Value("dum_pv_energyday_read");
Log 5, "at_midnight dum_pv_energyday_read " . $aceread;
my $aceday = ($ace - $aceread);
fhem ("set dum_pv_energyday_log " . sprintf("%.1f",($aceday)));
fhem ("set dum_pv_energyday_read " . $ace);
Log 5, "at_midnight dum_pv_energyday_read" . " " . $ace;
my $MP = Value("dum_pv_power_read");
fhem("set dum_pv_power_log " . $MP);
fhem("set dum_pv_power_read 0");

#Wochenwerte speichern;
if ($Pwday == 1) {
$aceread = Value("dum_pv_energyweek_read");
$aceday = ($ace - $aceread);
fhem ("set dum_pv_energyweek_log " . sprintf("%.1f",($ace - $aceread)));
fhem ("set dum_pv_energyweek_read " . $ace);
}
#Monatswerte speichern;
if ($Pmday == 1) {
$aceread = Value("dum_pv_energymonth_read");
$aceday = ($ace - $aceread);
fhem ("set dum_pv_energymonth_log " . sprintf("%.1f",($aceday)));
fhem ("set dum_pv_energymonth_read " . $ace);
}
#Jahreswerte speichern;
if ($Pyday == 1) {
$aceread = Value("dum_pv_energyyear_read");
$aceday = ($ace - $aceread);
fhem ("set dum_pv_energyyear_log " . sprintf("%.1f",($aceday)));
fhem ("set dum_pv_energyyear_read " . $ace);
}
}
</pre>

== Log ==

Das ModbusDevice legt sich ein eigenes Log an. Um aber übersichtliche Grafiken zu bekommen werden die Daten des Dummy benötigt. Hier hilft ein Logfile

<code> define FileLog_KePv Filelog %L/pv-%Y.log dum_pv*.* </code>

== Grafiken ==

{{Todo | Beschreibungen zu SVG hinterlegen }}

== SunSpec (SolarEdge) ==

Hier nochmal eine andere Variante der Attribut-Definition für ModbusAttr.
Diese Variante ist wesentlich enger an die Sunspec-Implementierung aus der SolarEdge-Dokumentation angelehnt, als die Definitionen in o.g. Beispiel-List.

<pre>
attr <DEVICE-NAME> obj-h40000-len 4
attr <DEVICE-NAME> obj-h40000-reading C_SunSpec_ID
attr <DEVICE-NAME> obj-h40000-unpack (a4)
attr <DEVICE-NAME> obj-h40004-len 16
attr <DEVICE-NAME> obj-h40004-reading C_Manufacturer
attr <DEVICE-NAME> obj-h40004-unpack (a16)
attr <DEVICE-NAME> obj-h40020-len 16
attr <DEVICE-NAME> obj-h40020-reading C_Model
attr <DEVICE-NAME> obj-h40020-unpack (a16)
attr <DEVICE-NAME> obj-h40044-len 8
attr <DEVICE-NAME> obj-h40044-reading C_Version
attr <DEVICE-NAME> obj-h40044-unpack (a8)
attr <DEVICE-NAME> obj-h40052-len 16
attr <DEVICE-NAME> obj-h40052-reading C_SerialNumber
attr <DEVICE-NAME> obj-h40052-unpack (a16)
attr <DEVICE-NAME> obj-h40068-reading C_DeviceAddress
attr <DEVICE-NAME> obj-h40069-reading C_PhaseDesign
attr <DEVICE-NAME> obj-h40070-reading C_SunSpec_Length
attr <DEVICE-NAME> obj-h40071-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Current_SF',0))
attr <DEVICE-NAME> obj-h40071-reading I_AC_Current
attr <DEVICE-NAME> obj-h40072-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Current_SF',0))
attr <DEVICE-NAME> obj-h40072-reading I_AC_CurrentA
attr <DEVICE-NAME> obj-h40073-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Current_SF',0))
attr <DEVICE-NAME> obj-h40073-reading I_AC_CurrentB
attr <DEVICE-NAME> obj-h40074-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Current_SF',0))
attr <DEVICE-NAME> obj-h40074-reading I_AC_CurrentC
attr <DEVICE-NAME> obj-h40075-reading I_AC_Current_SF
attr <DEVICE-NAME> obj-h40075-unpack s>
attr <DEVICE-NAME> obj-h40076-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Voltage_SF',0))
attr <DEVICE-NAME> obj-h40076-reading I_AC_VoltageAB
attr <DEVICE-NAME> obj-h40077-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Voltage_SF',0))
attr <DEVICE-NAME> obj-h40077-reading I_AC_VoltageBC
attr <DEVICE-NAME> obj-h40078-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Voltage_SF',0))
attr <DEVICE-NAME> obj-h40078-reading I_AC_VoltageCA
attr <DEVICE-NAME> obj-h40079-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Voltage_SF',0))
attr <DEVICE-NAME> obj-h40079-reading I_AC_VoltageAN
attr <DEVICE-NAME> obj-h40080-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Voltage_SF',0))
attr <DEVICE-NAME> obj-h40080-reading I_AC_VoltageBN
attr <DEVICE-NAME> obj-h40081-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Voltage_SF',0))
attr <DEVICE-NAME> obj-h40081-reading I_AC_VoltageCN
attr <DEVICE-NAME> obj-h40082-reading I_AC_Voltage_SF
attr <DEVICE-NAME> obj-h40082-unpack s>
attr <DEVICE-NAME> obj-h40083-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Power_SF',0))
attr <DEVICE-NAME> obj-h40083-reading I_AC_Power
attr <DEVICE-NAME> obj-h40083-unpack s>
attr <DEVICE-NAME> obj-h40084-reading I_AC_Power_SF
attr <DEVICE-NAME> obj-h40084-unpack s>
attr <DEVICE-NAME> obj-h40085-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Frequency_SF',0))
attr <DEVICE-NAME> obj-h40085-reading I_AC_Frequency
attr <DEVICE-NAME> obj-h40086-reading I_AC_Frequency_SF
attr <DEVICE-NAME> obj-h40086-unpack s>
attr <DEVICE-NAME> obj-h40087-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_VA_SF',0))
attr <DEVICE-NAME> obj-h40087-reading I_AC_VA
attr <DEVICE-NAME> obj-h40087-unpack s>
attr <DEVICE-NAME> obj-h40088-reading I_AC_VA_SF
attr <DEVICE-NAME> obj-h40088-unpack s>
attr <DEVICE-NAME> obj-h40089-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_VAR_SF',0))
attr <DEVICE-NAME> obj-h40089-reading I_AC_VAR
attr <DEVICE-NAME> obj-h40089-unpack s>
attr <DEVICE-NAME> obj-h40090-reading I_AC_VAR_SF
attr <DEVICE-NAME> obj-h40090-unpack s>
attr <DEVICE-NAME> obj-h40091-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_PF_SF',0))
attr <DEVICE-NAME> obj-h40091-reading I_AC_PF
attr <DEVICE-NAME> obj-h40091-unpack s>
attr <DEVICE-NAME> obj-h40092-reading I_AC_PF_SF
attr <DEVICE-NAME> obj-h40092-unpack s>
attr <DEVICE-NAME> obj-h40093-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_AC_Energy_WH_SF',0))
attr <DEVICE-NAME> obj-h40093-len 2
attr <DEVICE-NAME> obj-h40093-reading I_AC_Energy_WH
attr <DEVICE-NAME> obj-h40093-unpack I>
attr <DEVICE-NAME> obj-h40095-reading I_AC_Energy_WH_SF
attr <DEVICE-NAME> obj-h40096-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_DC_Current_SF',0))
attr <DEVICE-NAME> obj-h40096-reading I_DC_Current
attr <DEVICE-NAME> obj-h40097-reading I_DC_Current_SF
attr <DEVICE-NAME> obj-h40097-unpack s>
attr <DEVICE-NAME> obj-h40098-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_DC_Voltage_SF',0))
attr <DEVICE-NAME> obj-h40098-reading I_DC_Voltage
attr <DEVICE-NAME> obj-h40099-reading I_DC_Voltage_SF
attr <DEVICE-NAME> obj-h40099-unpack s>
attr <DEVICE-NAME> obj-h40100-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_DC_Power_SF',0))
attr <DEVICE-NAME> obj-h40100-reading I_DC_Power
attr <DEVICE-NAME> obj-h40100-unpack s>
attr <DEVICE-NAME> obj-h40101-reading I_DC_Power_SF
attr <DEVICE-NAME> obj-h40101-unpack s>
attr <DEVICE-NAME> obj-h40103-expr $val * (10 ** ReadingsNum ('<DEVICE-NAME>' ,'I_Temp_SF',0))
attr <DEVICE-NAME> obj-h40103-reading I_Temp_Sink
attr <DEVICE-NAME> obj-h40103-unpack s>
attr <DEVICE-NAME> obj-h40106-reading I_Temp_SF
attr <DEVICE-NAME> obj-h40106-unpack s>
attr <DEVICE-NAME> obj-h40107-reading I_Status
attr <DEVICE-NAME> obj-h40108-reading I_Status_Vendor
attr <DEVICE-NAME> userReadings uI_Status:I_Status.* {my $om=ReadingsNum($name,'I_Status',-1);;($om==2?'night':($om==4?'day':'off'))},\
uC_PhaseDesign:C_PhaseDesign.* {my $pd=ReadingsVal($name,'C_PhaseDesign','000');;($pd eq '101'?'single':($pd eq '102'?'split':($pd eq '103'?'3-phase':'unknown')))}
</pre>

<DEVICE-NAME> ist dabei natürlich durch den realen Namen des eigenen ModbusAttr-Devices zu ersetzen.

Zusätzlich sind hier auch zwei weiter userReadings definiert, die eine textliche Umsetzung für die Parameter C_PhaseDesign und I_Status vornehmen.

[[Kategorie:Other Components]]
[[Kategorie:Energieerzeugungsmessung]]

== Links ==
# Solaredge: [https://www.solaredge.com/sites/default/files/se-inverter-installation-guide-de.pdf Installationsanleitung]
# Solaredge: [https://www.solaredge.com/sites/default/files/sunspec-implementation-technical-note-de.pdf Sunspec Protokoll]

Dewpoint

2016-05-09T10:34:28Z

Benni: /* Alternativen zu diesem Modul */

{{SEITENTITEL:dewpoint}}
{{Infobox Modul
|ModPurpose=Berechnung des Taupunkts
|ModType=h

|ModCmdRef=dewpoint
|ModTechName=98_dewpoint.pm
|ModOwner=Willi Herzig}}

Das Modul [[dewpoint]] bietet Funktionen im Zusammenhang mit der Taupunktberechnung an. Die verfügbaren Funktionen, über einen Parameter bei der Definition gesteuert, sind
* dewpoint (Taupunkt)
* fan (erzeugt ein Event, das zur Lüftersteuerung verwendet werden kann)
* alarm (erzeugt einen "Schimmel-Alarm", wenn eine Referenztemperatur unter den Taupunkt fällt)
{{todo|Seite muss noch vervollständigt werden --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 13:49, 14. Mär. 2016 (CET)}}
== Voraussetzungen ==
Es muss ein Device geben, das die zur Berechnung erforderlichen Basisdaten ''Temperatur'' und ''Feuchte'' liefert. Die Namen der entsprechenden Readings können bei der Definition des ''dewpoint'' Device angegeben werden.

== Anwendung ==
=== Define ===
Ein ''dewpoint'' Device (siehe auch commandref) wird definiert mit:
:<code>define <name> dewpoint <type> ...</code>
Mögliche Werte und Bedeutung von
;type
*dewpoint - aus ''temp_name'' und ''hum_name'' wird der Taupunkt berechnet und als Reading mit dem Namen ''new_name'' an die durch ''devicename-regex'' spezifizierten Devices hinzugefügt
*fan -
*alarm -

Die vollständige Syntax für den Typ ''dewpoint'':
:<code>define <name> dewpoint '''dewpoint''' <devicename-regex> [<temp_name> <hum_name> <new_name>]</code>
wobei die Platzhalter folgende Bedeutung haben:
;name
:der Name des definierten ''dewpoint'' Device
;devicename-regex
:Spezifikation des Geräts / der Geräte, von denen ''temp_name'' und ''hum_name'' gelesen und ''new_name'' geschrieben werden soll
;temp_name
:Name des Readings, das den Temperaturwert enthält; wenn dieser Parameter nicht angegeben ist, wird ''temperature'' angenommen
;hum_name
:Name des Readings, das den Feuchtewert enthält; wenn dieser Parameter nicht angegeben ist, wird ''humidity'' angenommen
;new_name
:Name des Readings, das den berechneten Taupunkt aufnehmen soll; wenn dieser Parameter nicht angegeben ist, wird ''dewpoint'' angenommen

==== Statuszeile ====
Will man den Taupunkt nicht als einzelnes Reading ''dewpoint'', sondern in Kurzform zusammen mit den anderen Werten in der Statuszeile anzeigen lassen, so muss man für ''temp_name'' und ''hum_name'' die Spezialwerte ''T'' und ''H'' angeben:
:<code>define dew_state dewpoint dewpoint .* T H D</code>
Dies bewirkt, dass bei allen abgefragten Geräten die Werte ''T'' und ''H'' aus der Statuszeile ausgelesen werden und selbige dann wie folgt um den Taupunkt mit dem Buchstaben ''D'' erweitert wird:
<pre>T: 18.2 H: 55 D: 9.0</pre>

=== Attribute ===
;absFeuchte
:Beim Setzen dieses Attributs wird zusätzlich die absolute Luftfeuchtigkeit (in Gramm Wasser pro Kubikmeter Luft) berechnet und als Reading mit dem Namen ''absFeuchte'' ausgegeben. Hat man das Dewpoint-Device vorher so definiert, dass es den Taupunkt an den Status anhängt:

:<code>define dew_state dewpoint dewpoint .* T H D</code>

:dann braucht man nichts weiter zu tun, die absolute Feuchtigkeit wird ab sofort unter dem Buchstaben ''A'' an den Status angehängt:

:<pre>T: 18.2 H: 55 D: 9.0 A: 8.5</pre>

:Für den Taupunkt konnte man mit dem Parameter ''new_name'' einen eigenen Namen für das erzeugten Reading festlegen. Für die absolute Luftfeuchte ist dieser Parameter nicht vorhanden, das Reading hat immer den Standardnamen ''absFeuchte'' bzw. ''A'' in der Statuszeile.

== Anwendungsbeispiele ==

== Alternativen zu diesem Modul ==

=== Berechnung direkt im userReading ===

Um den Taupunkt einfach berechnen zu können, kann neben dem Modul ''dewpoint'' auch das Folgende userReading gesetzt werden (der Code dazu wurde direkt aus dem Modul entnommen und ist so über das Webinterface einzugeben).

Das Userreading hat den Vorteil, nicht mit anderen Modulen in Konflikt zu geraten.
<source lang="perl">attr <Device> userReadings dew:temperature.* {
my $dp;
my $temperature = ReadingsVal($name,"temperature",0);
my $humidity = ReadingsVal($name,"humidity",0);
my $A = 17.2694;
my $B = ($temperature > 0) ? 237.3 : 265.5;
my $es = 610.78 * exp( $A * $temperature / ($temperature + $B) );
my $e = $humidity/ 100 * $es;
if ($e == 0) { Log 1, "Error: dewpoint() e==0: temp=$temperature, hum=$humidity";
return 0;
}
my $e1 = $e / 610.78;
my $f = log( $e1 ) / $A;
my $f1 = 1 - $f;
if ($f1 == 0) {
Log 1, "Error: dewpoint() (1-f)==0: temp=$temperature, hum=$humidity";
return 0;
}
$dp = $B * $f / $f1 ;
sprintf "%.2f", $dp;
}</source>
(Das obige Beispiel wurde nach Umstellung auf "Source"-Formatierung noch nicht getestet. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 13:49, 14. Mär. 2016 (CET))

=== Variante über 99_myUtils ===

Noch besser ist es, die im vorigen Abschnitt durchgeführte Berechnung nicht für jedes Device per userReading wieder neu einzugeben, sondern diese einmalig als Funktion in der 99_myUtils zu hinterlegen und diese dann im jeweiligen Device im userReading nur noch aufzurufen.

Dazu ist in der 99_myUtils folgende sub anzulegen:

<source lang="perl">
sub urDewpoint
{
my ($dname,$tname,$hname) = @_;

#Prüfen, ob überhaupt ein Device(-name) als Parameter übergeben wurde
if(!defined($dname)) {
Log3 undef,1,"Error: urDewpoint - No device specified!";
return 0;
}

#Prüfen, ob das angegebene Device überhaupt existiert
if(!$defs{$dname}) {
Log3 undef,1,"Error: urDewpoint - Device $dname is not defined!";
return 0;
}

#Wenn keine Readingsnamen für die Temperatur oder Luftfeuchtigkeit
#übergebenwurde wird per default temperature oder humidity verwendet
$tname='temperature' if(!defined($tname));
$hname='humidity' if(!defined($hname));

my $dp;

#Auslesen der Readingswerte für Temperatur und Luftfeuchtigkeit aus den
#entsprechenden Readings des Devic
my $temperature = ReadingsVal($dname,$tname,0);
my $humidity = ReadingsVal($dname,$hname,0);

#Magische Berechnung :)
my $A = 17.2694;
my $B = ($temperature > 0) ? 237.3 : 265.5;
my $es = 610.78 * exp( $A * $temperature / ($temperature + $B) );
my $e = $humidity/ 100 * $es;
if ($e == 0) {
Log3 undef,1, "Error: urDewpoint: $dname - e==0: temp=$temperature, hum=$humidity";
return 'ERR';
}
my $e1 = $e / 610.78;
my $f = log( $e1 ) / $A;
my $f1 = 1 - $f;
if ($f1 == 0) {
Log3 undef,1, "Error: urDewpoint: $dname - (1-f)==0: temp=$temperature, hum=$humidity";
return 'ERR';
}
$dp = $B * $f / $f1 ;

#Rückgabe der Taupunkt-Temperatur
return sprintf "%.2f", $dp;
}
</source>

Anschließend kann dann im jeweiligen Device ganz einfach ein userReading definiert werden:

<source lang="perl">attr <Device> userReadings dew:temperature.* {urDewpoint($name)}</source>

Die Readings-Namen für Temperatur und Luftfeuchtigkeit bei Device können bei bedarf auch abweichend angegeben werden. Bei den Homematic-Wandthermostaten heßt das Reading für die tatsächlich gemessene Temperatur measured-temp und nicht temperature, dann würde die definition des userReading wie folgt aussehen:

<source lang="perl">attr <Device> userReadings dew:measured-temp.* {urDewpoint($name,'measured-temp')}</source>

== Links ==
* Forendiskussion um {{Link2Forum|Topic=8576|LinkText=Lüften oder nicht}}
* Forendiskussion um {{Link2Forum|Topic=23080|LinkText=Temperaturdifferenz}}

[[Kategorie:HOWTOS]]

Benutzer:Benni

2016-02-18T13:10:53Z

Benni: Die Seite wurde neu angelegt: „ [http://forum.fhem.de/index.php?action=profile;u=6166 Mein User-Profil im FHEM-Forum]“

[http://forum.fhem.de/index.php?action=profile;u=6166 Mein User-Profil im FHEM-Forum]

FHEM Tablet UI

2016-02-18T13:05:43Z

Benni: /* Icon-Konfiguration */ fa- ist ein Präfix, kein Suffix

{{Infobox Modul
|ModPurpose=Oberfläche für Fhem
|ModType=x
|ModFTopic=34233
|ModForumArea=Frontends
|ModTechName=n.a.
|ModOwner=setstate ({{Link2FU|7023|Forum}})
}}
[[Datei:tablet_ui.png|200px|thumb|right|Fhem Tablet UI]]
FHEM Tablet UI ist ein leichtgewichtiges aber funktionsreiches Framework zum Steuern und Überwachen von in Fhem integrierten Geräten. Zahlreiche Widgets können sehr flexibel und leicht per HTML Code konfiguriert werden.

In dieser Anleitung wird die Installation und Konfiguration des FHEM Tablet UI beschrieben.

{{Todo|alle Widgets hier übernehmen, Übersetzung, weitere Beispiele aus dem Forum einfügen (evtl. mit Link!?)}}

== Voraussetzungen ==
Dieses User Interface für Tablets benötigt <u>keine</u> zusätzliche Frameworks, wie PHP, MySQL oder SmartVisu.

Voraussetzungen ist nur ein Standard-Fhem mit HTTPSRV Modul und ein beliebiger Standard-Browser mit Javascript auf einem beliebigen Betriebssystem oder Webviewcontrol.

== Installation ==
* Im Befehls-Eingabefeld eingeben: <code><nowiki>update all https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt</nowiki></code>
* Im Befehls-Eingabefeld eingeben: <code>define TABLETUI HTTPSRV ftui/ ./www/tablet Tablet-UI</code>
* Im Verzeichnis ./fhem/www/tablet die Datei index-example.html in index.html umbenennen oder eine neue index.html erzeugen und diese index.html wie nachfolgend beschrieben editieren.

Das UI ist über den Link "Tablet-UI" auf der Fhem-Hauptseite oder durch Direktaufruf der URL "<nowiki>http://<Fhem-url>:8083/fhem/tablet/index.html</nowiki>" zu erreichen.

Hinweise zu einer manuellen Installation und weitere Infos sind auf der Projektseite https://github.com/knowthelist/fhem-tablet-ui zu finden.

== Update ==
* Prüfen der Änderungen seit dem letzten Download/Update durch Eingabe von: <code><nowiki>update check https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt</nowiki></code>
* Update des UI durch Eingabe von: <code><nowiki>update all https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt</nowiki></code>

Über
<code><nowiki>update add https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt</nowiki></code>
kann seit dem 24.12.2015 die URL zum normalen Updatebefehl von FHEM hinzugefügt werden. Mit einen "update check" sieht man dann gleich alle Updates aus beiden "Welten".

== Weitere Widgets ==

=== Widgets for Fhem-tablet-ui ===
Zusätzlich zu den bei der Installation des Tablet UI direkt zur Verfügung stehenden Widgets, gibt es eine weitere Widget-Quelle von nesges unter https://github.com/nesges/Widgets-for-fhem-tablet-ui. Die Widgets aus dieser Quelle müssen für eine Nutzung separat installiert werden.

Dazu folgenden Befehl in die Fhem-Befehlszeile eingeben: <code><nowiki>update all https://raw.githubusercontent.com/nesges/Widgets-for-fhem-tablet-ui/master/controls_widgets-for-fhem-tablet-ui.txt</nowiki></code>.

Näheres zur Installation unter [https://github.com/nesges/Widgets-for-fhem-tablet-ui/wiki/Installation Wiki: Installation].

Die Dokumentation der einzelnen Widgets befindet sich ebenfalls [https://github.com/nesges/Widgets-for-fhem-tablet-ui/wiki im Github-Wiki].

== Konfiguration ==
Die Konfiguration der angezeigten Widgets erfolgt in der Datei '''index.html''' im Hauptordner 'tablet'.

'''Metadaten-Konfiguration'''

Refresh sofort, alle 15 Minuten ein voller Refresh (shortpoll) statt alle 30 Sekunden ein voller Refresh
:<code><meta name="longpoll" content="1"></code>

Drag&Drop deaktivieren
:<code><meta name='gridster_disable' content='1'></code>

Toast messages deaktivieren
:<code><meta name='toast' content='1'></code>

Größe des Basis-Rasters (data-sizey=1/data-sizex=1)
:<code><meta name="widget_base_width" content="116"></code>
:<code><meta name="widget_base_height" content="131"></code>

Abstände der Gridsterelemente verkleinern:
:<code><meta name="widget_margin" content="3"></code>

Das Layout und das Aussehen des UI kann durch die Klassen-Attribute beeinflusst werden. Verfügbare Klassen sind:

container, left, right, cell, narrow, darker, big, bigger, small

== Farbe ==
Es besteht die Möglichkeit, die Farbwerte in hexadezimaler Form oder als RGB-Wert anzugeben. Zum Beispiel: Hex: #A3CFA3 RBG: rgb(163, 207, 163).

Knallige Farben wie #ff0000 für Rot oder #00ff00 für Grün sollten vermieden werden. Es ist besser unterhalb von #D0 (208) für die Grundfarben zu bleiben.

Hilfreich bei der Suche nach den Farbwerten ist der color picker: http://www.w3schools.com/tags/ref_colorpicker.asp

== CSS Class description ==

Not all widgets support all classes

* readonly : changing of state is not allowed
* wider : 25px extra space for the widget to the top
* narrow : shorter distant to the widget above
* w1x, w2x, w3x : set the widget to a fix width: 1x, 2x, 3x width
* small : font 80% size (label), small diameter for volume widget
* mini : lowest diameter for volume widget
* large : font 150% size
* big : font 200% size
* bigger : font 320% size
* thin : font thin
* darker : forecolor in gray
* hue-tick : draw ticks in color range
* hue-front : draw handle in color range
* hue-back : draw background in color range
* dim-tick : draw ticks in brightness range
* dim-front : draw handle in brightness range
* dim-back : draw background in brightness range
* red : foreground color red
* green : foreground color green
* blue : foreground color blue
* doublebox-v : container to place 2 small widgets (e.g. switch) one above the other
* doublebox-h : container to place 2 small widgets (e.g. switch) side by side
* timestamp : deliver the date time for the reading instead the value
* inline : positioning elements in a row, no line break
* top-space : 15px extra on top (top-space-2x -> 30px; top-space-3x -> 45px)
* left-space : 15px extra on left (left-space-2x -> 30px; left-space-3x -> 45px)
* right-space : 15px extra on right (right-space-2x -> 30px; right-space-3x -> 45px)
* blink : blink animatation for label or symbol widget

== Positioning ==

*container : new box or new row
*col-x-y : new column with x/y of width (col-1-3,col-2-3,col-1-2,col-1-4,col-1-8,col-1-5,col-2-5,col-3-5,col-4-5)
*inline : positioning elements in a row, no line break
*top-space : 15px extra on top (top-space-2x -> 30px; top-space-3x -> 45px)
*left-space : 15px extra on left (left-space-2x -> 30px; left-space-3x -> 45px)
*right-space : 15px extra on right (right-space-2x -> 30px; right-space-3x -> 45px)
*top-narrow : -15px closer on top (top-narrow-2x -> -30px; top-narrow-10 -> -10px)
*centered : horizontal centered
*left-align : align text left
*right-align : align text right
*wider : 15px extra space for the widget all around
*narrow : shorter distant to the widget above
*fullsize : 100% in width and height

== Widgets -- Konfiguration ==

Zurzeit stehen 33 Widgets zur Verfügung:
* [https://github.com/nesges/Widgets-for-fhem-tablet-ui/wiki/button button]: Variante der push und switch Widgets, die entweder einen URL ansteuern oder einen Fhem-Befehl absetzen kann.
* [[#chart|chart]]: chart with similar capabilities as the FHEM plots
* [[#circlemenu|circlemenu]]: Mehrere Widgets hinter einem Widget verborgen, trotz des 'circle' im Namen kann das Menue jetzt auch horizontal oder vertikal ausgeklappt werden
* [https://github.com/nesges/Widgets-for-fhem-tablet-ui/wiki/clicksound clicksound]: Mit dem Widget "clicksound" können Sounds an Click-Events von Elementen gebunden werden.
* [https://github.com/nesges/Widgets-for-fhem-tablet-ui/wiki/clock clock]: Das Widget "clock" stellt eine einfach Uhr zur verfügung.
* [[#dimmer|dimmer]]: toogle button with a setter for on value
* [[#homestatus|homestatus]]: selector for 4 states (1=home, 2=night, 3=away, 4=holiday)
* [https://github.com/nesges/Widgets-for-fhem-tablet-ui/wiki/iframe iframe]]: Widget zum Einbinden externer Inhalte in einem Iframe.
* [[#image|image]]: insert an image, the URL is given by a reading
* [https://github.com/nesges/Widgets-for-fhem-tablet-ui/wiki/itunes_artwork itunes_artwork]: itunes_artwork durchsucht die iTunes-Datenbank anhand eines Arrays von beliebigen Suchworten nach einem Cover-Artwork und zeigt dieses an.
* [https://github.com/nesges/Widgets-for-fhem-tablet-ui/wiki/javascript javascript]: Ermöglicht die Ausführung beliebigen Javascript-Codes aus einem Reading.
* [https://github.com/nesges/Widgets-for-fhem-tablet-ui/wiki/joinedlabel joinedlabel]: verbindet mehrere Readings zu einem Feld
* [https://github.com/nesges/Widgets-for-fhem-tablet-ui/wiki/klimatrend klimatrend]: wandelt Daten aus dem statistics-Modul in einen Pfeil um, der den aktuellen Trend anzeigt.
* [https://github.com/nesges/Widgets-for-fhem-tablet-ui/wiki/kodinowplaying kodinowplaying]: zeigt Informationen zu grade in KODI gespielten Medien in Form eines Labels an.
* [[#label|label]]: ein state als Text anzeigen (Farbe einstellbar)
* [[#level|level]]: vertical/horizontal bar to show values between min/max value
* [https://github.com/nesges/Widgets-for-fhem-tablet-ui/wiki/mpdnowplaying mpdnowplaying]: zeigt Titelinformationen eines per MPD-Modul angebundenen Music Player Daemon an.
* [https://github.com/nesges/Widgets-for-fhem-tablet-ui/wiki/multistatebutton multistatebutton]: Variante des push-Widgets das den set-Befehl abhängig vom gelesenen Status ändert.
* [[#pagetab|pagetab]]: Element to smoothly exchange the whole page with another page
* [[#playstream|playstream]]: Abspielen eines Webradio-Streams per Button
* [[#popup|popup]]: a popup dialog which open on click on another widget
* [[#progress|progress]]: round symbolic display for percent values
* [[#push|push]]: send any command to Fhem e.g. up / down
* [https://github.com/nesges/Widgets-for-fhem-tablet-ui/wiki/reload reload]: auslösen eine Pagereloads
* [[#rotor|rotor]]: Umschalten von zwei oder mehr Widgets an einer Position
* [[#select|select]]: Combobox to provide a list for selection
* [https://github.com/nesges/Widgets-for-fhem-tablet-ui/wiki/settimer settimer]: zum anzeigen und einstellen einer Uhrzeit.
* [[#simplechart|simplechart]]: simple XY line chart for one value (reads directly from Fhem log file)
* [[#slider|slider]]: vertical slider to select between min/max value
* [[#switch|switch]]: Toggle any command to Fhem (e.g. on / off)
* [[#symbol|symbol]]: State als Symbol darstellen (z.B. Fenster offen)
* [[#thermostat|thermostat]]: dial for heater thermostates to set desired value and show current value
* [[#volume|volume]]: dial to set a single value (e.g. 0-60)
* [[#weather|weather]]: insert an icon or image, represending a weather literal
* [https://github.com/nesges/Widgets-for-fhem-tablet-ui/wiki/wind_direction wind_direction]: Zeigt die Windrichtung auf einer Windrose an.

----------------------------------

Für alle Widgets gilt:
{| class="wikitable"
|+allgemeine Attribute
|-
!align="right" |data-type
|Widget-Typ
|-
!align="right" |data-device
|Fhem-Name des Gerätes (mit dem Befehl 'list' bekommt man im Fhem die kpl. Liste)
|-
!align="right" |class
|CSS-Klassen für Aussehen und Formatierung des Widgets
|-
|}

<div id="chart">'''CHART'''</div>

{| class="wikitable"
!HTML Attribut
!Beschreibung
!Default Wert
|-
!align="right" |data-logdevice
|name of the logdevice (e.g. FileLog_WohnzimmerHeizung) or array of names if more than one graph shall be displayed
|-
|-
!align="right" |data-logfile
|name of the logfile (e.g. WohnzimmerHeizung-2015.log) or or array of names if more than one graph shall be displayed
|'-' or omitting this data means current logfile
|-
!align="right" |data-columnspec
|definition for how to find the values (e.g. "4:meas.*:1:int") or or array of columnspecs if more than one graph shall be displayed
|-
|-
!align="right" |data-style
|name of the graph style to be used (e.g. 'SVGplot l0' or 'ftui l0dash') or or array of styles if more than one graph shall be displayed using different stlyes. The standard fhem plot styles can be used furthermore there are some more predefined styles existing (details see css file). Own styles can be specified e.g. in the fhem-table-ui-user.css file.
|-
|-
!align="right" |data-ptype
|name of the plot type (e.g. 'lines' or 'fa-cog') or or array of plottypes if more than one graph shall be displayed. All fhem plot styles are supported. Additionally it is possible to specify symbols (currently supported are font awesome ('fa-...'), open automation ('oa-...') and fhem symbols ('fs-...'))
|'lines'
|-
!align="right" |data-uaxis
|name of the axis to be used ('primary' or 'secondary') or or array of axis' to be used if more than one graph shall be displayed. The 'primary' axis is labelled on the left side, the 'secondary' axis is labelled on the right side
|'primary'
|-
!align="right" |data-legend
|caption of the graph (used in the legend and at the cursor) or an array of legend texts if more than one graph shall be displayed.
|-
|-
!align="right" |data-minvalue
|min Y value to Show or an array of values for dynamic minY for primary axis. A value of 'auto' means that the value is calculated from the data displayed dynamically
|10
|-
!align="right" |data-minvalue_sec
|min Y value to Show or an array of values for dynamic minY for secondary axis. A value of 'auto' means that the value is calculated from the data displayed dynamically
|'auto'
|-
!align="right" |data-maxvalue
|max Y value to Show or an array of values for dynamic maxY for primary axis. A value of 'auto' means that the value is calculated from the data displayed dynamically
|30
|-
!align="right" |data-maxvalue_sec
|max Y value to Show or an array of values for dynamic maxY for secondary axis. A value of 'auto' means that the value is calculated from the data displayed dynamically
|'auto'
|-
!align="right" |data-yticks
|value distance between Y tick lines (related to primary axis). A value of 'auto' means that the value is calculated from the data displayed dynamically.
|'auto'
|-
!align="right" |data-xticks
|time range between each X tick lines (in minutes). A value of 'auto' means that the value is calculated from the data displayed dynamically
|'auto'
|-
!align="right" |data-daysago_start
|number of days back from now for the start of the plot (0 means the plot starts from today 0:00). Additionally the x-axis start value can be set here unsing standard data formats like ('2013-10-23'), the time portion of the string is only used when <code>data-nofulldays</code> is 'true'.
|0
|-
!align="right" |data-daysago_end
|number of days back from now for the end of the plot (-1 means the plot ends today 24:00). Additionally the x-axis end value can be set here unsing standard data formats like ('2013-10-23'), the time portion of the string is only used when <code>data-nofulldays</code> is 'true'.
|-1
|-
!align="right" |data-nofulldays
|switch to activate/deactivate rounding of the xaxis start and end values to full days ('true' or 'false')
|'false'
|-
!align="right" |data-ytext
|text to be shown besides the primary y axis.
|-
|-
!align="right" |data-ytext_sec
|text to be shown besides the secondary y axis.
|-
|-
!align="right" |data-yunit
|unit of the value to show beside of each Y ticks for primary y axis.
|-
|-
!align="right" |data-crosshair
|switch to activate/deactivate the crosshair cursor ('true' or 'false')
|'false'
|-
!align="right" |data-cursorgroup
|number to define coupling of the crosshair cursor. The cursors of all charts having the same number are coupled and move together.
|-
|-
!align="right" |data-scrollgroup
|number to define coupling of the scrolling (shift and zoom). All charts having the same number are scrolled (shifted and zoomed) together.
|-
|-
!align="right" |data-showlegend
|switch to activate/deactivate the initial display of the legend window ('true' or 'false')
|'false'
|-
!align="right" |data-yunit_sec
|unit of the value to show beside of each Y ticks for secondary y axis.
|-
|-
!align="right" |data-width
|fixed size for width (in % or px)
|-
|-
!align="right" |data-height
|fixed size for height (in % or px)
|-
|-
!align="right" |class
|fullsize, noticks, nobuttons
|
|-
|}

<code>data-logfile</code> can be omitted in this case the default value "-" will be used. This means that the current logfile is going to be used.

There are several buttons that control the dynamic behaviour of the chart. The <-, ->, + and - buttons shift and zoom the displayed data. The "legend" and "cursor" buttons are switching on and off the display of the legend window and the crosshair cursor respectively.

When the legend window is displayed, a click on the legend text shows/hides the respective graph. The legend window can be dragged to other positions on desktop browsers (currently not yet working for iOS and Android).

The crosshair cursor currently only works dynamically on desktop browsers. On iOS and Android you have to tap on the screen to set the cursor to a new position.

There is a number of css styles that control the visible appearance of the chart. The following classes are supported:

{| class="wikitable"
!CSS class name
!Description
|-
!.chart-background
|Color etc. for the chart background
|-
!.text.axes
|Font and color for the chart axes
|-
!.buttons
|Size and color for the buttons (shift etc.)
|-
!.gridlines
|Size and color for gridlines generally
|-
!.xaxis
|Font, size and color for xaxis
|-
!.yaxis
|Font, size and color for yaxis
|-
!.xticks
|Font, size and color for xticks
|-
!.yticks
|Font, size and color for yticks
|-
!.crosshair
|Font, size and color (foreground/background) for the crosshair cursor
|-
!.caption
|Font, size and color for text buttons for legend and cursor switching
|-
!.legend
|Font, size and background color for legend window
|-
|-
|}

[[#Beispiel_chart|Link zu einem Beispiel]]

<div id="circlemenu">'''CIRCLEMENU'''</div>

{| class="wikitable"
!HTML Attribut
!Beschreibung
!Default Wert
|-
!align="right" |data-item-diameter
|diameter of the circle
|52
|-
!align="right" |data-circle-radius
|radius of each item, in pixel
|70
|-
!align="right" |data-direction
|position of the items in relation to the center
|'full'
|-
!align="right" |data-close-after
|closing time of the circle-menu
|(item-count + 1s) or a minimum of 4s
|-
!align="right" |class
|keepopen
|
|-
|}

Optionen für data-direction: top | right | bottom | left | top-right | top-left | bottom-right | bottom-left | top-half | right-half | bottom-half | left-half | full | vertical | horizontal

[[#Beispiel_circlemenu|Link zu einem Beispiel]]

<div id="dimmer">'''DIMMER'''</div>

{| class="wikitable"
!HTML Attribut
!Beschreibung
!Default Wert
|-
!align="right" |data-get
|name of the reading to get from Fhem
|'STATE'
|-
!align="right" |data-get-on
|value for ON status to get
|'on'
|-
!align="right" |data-get-off
|value for OFF status to get
|'off'
|-
!align="right" |data-set
|(<command> <device> <reading> <value>)
|
|-
!align="right" |data-set-on
|value for ON status to set
|value of data-get-on
|-
!align="right" |data-set-off
|value for OFF status to set
|value of data-get-off
|-
!align="right" |data-cmd
|name of the command (<command> <device> <value>) (e.g. setstate, set, setreading, trigger)
|'set'
|-
!align="right" |data-dim
|name of the reading responsible for dim (<command> <device> <reading> <value>)
|value of data-get-on
|-
!align="right" |data-icon
|name of the font-awesome icon
|fa-lightbulb-o
|-
|}

[[#Beispiel_dimmer|Link zu einem Beispiel]]

<div id="homestatus">'''HOMESTATUS'''</div>

{| class="wikitable"
!HTML Attribut
!Beschreibung
!Default Wert
|-
!align="right" |data-get
|name of the reading to get from Fhem
|'STATE'
|-
!align="right" |data-set
|command to send to Fhem (<code>set <device> <command> <value></code>)
|''
|-
!align="right" |data-alias
|array of fix names to show only in the UI as an alias to the real states
|''
|-
!align="right" |data-icons
|array of icons related to the data-get-on array
|''
|-
!align="right" |data-version
|name of the status model e.g. 'residents','roommate','guest'
|(default NULL)
|-
|}

The default version has 4 states: '1','2','3','4' The default aliases are 'Home','Night','Away','Holiday'; data-version='residents' or 'roommate' or 'guest' has 5 states ('home','asleep','absent','gone','gotosleep') They have these aliases 'Home','Night','Away','Holiday','Retire'

[[#Beispiel_homestatus|Link zu einem Beispiel]]

<div id="image">'''IMAGE'''</div>

{| class="wikitable"
!HTML Attribut
!Beschreibung
!Default Wert
|-
!align="right" |data-get
|name of the reading to get an URL from Fhem
|'STATE'
|-
!align="right" |data-size
|width of the image in px or %, the height scales proportionally
|50%
|-
!align="right" |data-url
|URL of the image to show (use data-url or data-device + data-get, not both)
|
|-
!align="right" |data-refresh
|Interval in seconds for image refresh for usage together with data-url
|900
|-
|}

[[#Beispiel_image|Link zu einem Beispiel]]

<div id="label">'''LABEL'''</div>

{| class="wikitable"
!HTML Attribut
!Beschreibung
!Default Wert
|-
!align="right" |data-get
|name of the reading to get from Fhem
|
|-
!align="right" |data-fix
|keeping a specified number of decimals.
|'-1' -> non-numeric
|-
!align="right" |data-part
|split position of the space separated value to show or an RegEx
|
|-
!align="right" |data-colors
|a array of color values to affect the colour of the label according to the limit value
|
|-
!align="right" |data-limits-get
|name of the DEVICE:Reading to colorize the label
|data-device:data-get
|-
!align="right" |data-limits
|an array of numeric values to affect the colour of the Label
|
|-
!align="right" |data-limits-part
|part number of the space separated value to show or a RegEx
|'-1' -> all
|-
!align="right" |data-unit
|add a unit after a numeric value. use encoded strings e.g. "%B0C%0A"
|
|-
!align="right" |data-substitution
|regex-substitution to apply on the value. Standard regex notation (s/regex/subst/modifier) is expected
|
|-
!align="right" |class
|small, large, big, bigger, thin, red, green, blue, darker, timestamp, w1x, w2x, w3x, fixedlabel
|
|}

mit der Class 'fixedlabel' kann man Label einbauen, die einen festen Text (direkt im HTML) haben, aber trotzdem die Farbe per Reading Value beeinflusst werden könnte.

[[#Beispiel_label|Link zu einem Beispiel]]

<div id="level">'''LEVEL'''</div>

{| class="wikitable"
!HTML Attribut
!Beschreibung
!Default Wert
|-
!align="right" |data-get
|name of the reading to get from Fhem
|'STATE'
|-
!align="right" |data-min
|minimal value to set
|'0'
|-
!align="right" |data-max
|maximal value to set
|'100'
|-
!align="right" |data-on
|value where the slider moves to max
|'on'
|-
!align="right" |data-off
|value where the slider moves to min
|'off'
|-
!align="right" |data-colors
|a array of color values to affect the colour of the label according to the limit value
|
|-
!align="right" |data-limits
|a array of numeric or RegEx values to affect the colour of the label
|
|-
!align="right" |class
|mini, horizontal
|
|-
|}

[[#Beispiel_level|Link zu einem Beispiel]] (fehlt noch)

<div id="pagetab">'''PAGETAB'''</div>

{| class="wikitable"
!HTML Attribut
!Beschreibung
!Default Wert
|-
!align="right" |data-url
|URL of the new page to show
|
|-
!align="right" |data-icon
|name of the font-awesome icon
|'fa-power-off'
|-
!align="right" |data-background-icon
|name of the font-awesome icon for background
|''
|-
!align="right" |data-on-background-color
|color of ON state
|'#aa6900'
|-
!align="right" |data-off-background-color
|color of OFF state
|'#505050'
|-
!align="right" |data-on-color
|color of ON state
|'#aa6900'
|-
!align="right" |data-off-color
|color of Off state
|'#505050'
|-
!align="right" |data-get-on
|array of status to assign a special icon-list from data-icons
|
|-
!align="right" |data-icons
|array of icons related to the a data-get-on array
|
|-
!align="right" |class
|warn, activate (as additionals for data-icons)
|
|-
|}

[[#Beispiel_pagetab|Link zu einem Beispiel]]

<div id="playstream">'''PLAYSTREAM'''</div>

{| class="wikitable"
!HTML Attribut
!Beschreibung
!Default Wert
|-
!align="right" |data-url
|URL des Radio-Streams
|-
!align="right" |data-get
|name of the reading to get the control state from FHEM
|'STATE'
|-
!align="right" |data-get-on
|value for PLAY status to get.
|'on'
|-
!align="right" |data-get-off
|value for STOP status to get.
|'off'
|-
!align="right" |data-volume
|name of the reading to get the volume value (0-100)
|volume
|-
|}

[[#Beispiel_playstream|Link zu einem Beispiel]]

<div id="popup">'''POPUP'''</div>

{| class="wikitable"
!HTML Attribut
!Beschreibung
!Default Wert
|-
!align="right" |data-get
|name of the reading where to get the alert value from
|'STATE'
|-
!align="right" |data-get-on
|value which trigger to open the dialog
|'on'
|-
!align="right" |data-off
|value which trigger to close the dialog
|'off'
|-
!align="right" |data-width
|fixe size for width (in % or px)
|
|-
!align="right" |data-height
|fixe size for height (in % or px)
|
|-
|}

[[#Beispiel_popup|Link zu einem Beispiel]]

<div id="progress">'''PROGRESS'''</div>

{| class="wikitable"
!HTML Attribut
!Beschreibung
!Default Wert
|-
!align="right" |data-get
|name of the reading to get from Fhem
|'STATE'
|-
!align="right" |data-max
|maximal value to set or name of the reading which helds the max value
|100
|-
!align="right" |class
|novalue, percent
|
|-
|}

[[#Beispiel_progress|Link zu einem Beispiel]] (fehlt noch)

<div id="push">'''PUSH'''</div>

{| class="wikitable"
!HTML Attribut
!Beschreibung
!Default-Wert
|-
!align="right" |data-set
| name of the reading to set on FHEM (<command> <device> <reading> <value>)
|
|-
!align="right" |data-set-on
|value to send when the the button get pressed oder ein Array zwischen dessen Werten umgeschaltet werden kann
|
|-

!align="right" |data-icon
|name of the font-awesome icon
|
|-
!align="right" |data-background-icon
|name of the font-awesome icon for background
|'fa-circle'
|-
!align="right" |data-cmd
|name of the command (<command> <device> <value>) (e.g. setstate, set, setreading, trigger)
|'set'
|-
!align="right" |data-doubleclick
|timeout to wait for a second click or touch. '0' disables the doubleclick feature.
|0
|-
!align="right" |data-countdown
|secondes for the countdown progress control
|autodetect from 'on-for-timer' command
|-
!align="right" |data-background-icon
|name of the font-awesome icon for background
|
|-
!align="right" |data-off-background-color
|fix color attribute for OFF state or DEVICE:READING for dynamic setting
|#505050
|-
!align="right" |data-off-color
|fix color attribute for Off state or DEVICE:READING for dynamic setting
|#505050
|-
|}

[[#Beispiel_push|Link zu einem Beispiel]]

<div id="rotor">'''ROTOR'''</div>

{| class="wikitable"
!HTML Attribut
!Beschreibung
!Default Wert
|-
!align="right" | data-delay
|time in millisecondes to wait until next list item get shown
|3500
|-
!align="right" |class
|fade, rotate
|''
|-
|}
Ohne Angabe von class erfolgt keine Animation.

[[#Beispiel_rotor|Link zu einem Beispiel]]

<div id="select">'''SELECT'''</div>

{| class="wikitable"
!HTML Attribut
!Beschreibung
!Default Wert
|-
!align="right" |data-get
|name of the reading that get the selected item of the list
|
|-
!align="right" |data-set
|name of the reading to set on Fhem (<command> <device> <reading> <value>)
|''
|-
!align="right" |data-list
|name of the reading to get a :-separated list from Fhem
|''
|-
!align="right" |data-items
|an array of fix items to show in the selection box (alternative if data-list is empty)
|
|-
!align="right" |data-alias
|an array of fix names to show only in the selection box as an alias to the real items
|
|-
!align="right" |data-cmd
|name of the command to send to Fhem (<command> <device> <reading> <value>) (e.g. setstate, set, setreading, trigger)
|'set'
|-
!align="right" |data-quote
|characters to enclose the send value
|
|-
!align="right" |class
|wider, w1x, w2x, w3x, large, big
|
|-
|}

[[#Beispiel_select|Link zu einem Beispiel]]

<div id="simplechart">'''SIMPLECHART'''</div>

{| class="wikitable"
!HTML Attribut
!Beschreibung
!Default Wert
|-
!align="right" |data-logdevice
|name of the logdevice (e.g. FileLog_WohnzimmerHeizung)
|
|-
!align="right" |data-logfile
|name of the logfile (e.g. WohnzimmerHeizung-2015.log)
|'-' means current logfile
|-
!align="right" |data-columnspec
|definition for how to find the values (e.g. "4:meas.*:1:int")
|''
|-
!align="right" |data-minvalue
|min Y value to Show or an array of values for dynamic minY
|10
|-
!align="right" |data-maxvalue
|max Y value to Show or an array of values for dynamic maxY
|30
|-
!align="right" |data-yticks
|value distance between Y tick lines
|5
|-
!align="right" |data-xticks
|time range between each X tick line (in Minuten)
|360 minutes
|-
!align="right" |data-daysago
|number of days back from now
|0
|-
!align="right" |data-caption
|name of the chart to show as text
|
|-
!align="right" |data-yunit
|unit of the value to show beside of each Y ticks
|
|-
!align="right" |data-width
|fixe size for width (in % or px)
|
|-
!align="right" |data-height
|fixe size for height (in % or px)
|
|-
!align="right" |class
|fullsize, noticks
|
|-
|}

[[#Beispiel_simplechart|Link zu einem Beispiel]] (fehlt noch)

<code>data-logfile</code> kann man auch weglassen, dann greift der Defaultwert "-". Damit wird das neuste Logfile gelesen.

<div id="slider">'''SLIDER'''</div>

{| class="wikitable"
!HTML Attribut
!Beschreibung
!Default Wert
|-
!align="right" |data-get
|name of the reading to get from Fhem
|'STATE'
|-
!align="right" |data-set
|command to send to Fhem (<code>set <device> <command> <value></code>)
|''
|-
!align="right" |data-cmd
|name of the command (<command> <device> <value>) (e.g. setstate, set, setreading, trigger)
|'set'
|-
!align="right" |data-min
|minimal value to set
|0
|-
!align="right" |data-max
|maximal value to set
|100
|-
!align="right" |data-on
|value where the slider moves to max
|'on'
|-
!align="right" |data-off
|value where the slider moves to min
|'off'
|-
!align="right" |data-value
|wenn true wird beim sliden der Wert angezeigt
|
|-
!align="right" |data-width
|width for horizontal sliders
|'120px', for mini '60px'
|-
!align="right" |data-height
|height for vertical sliders
|'120px', for mini '60px'
|-
!align="right" |class
|Aussehen/Ausrichtung
|
|-
|}

Für class steht mini, horizontal und negated (0 liegt oben) zur Verfügung.

[[#Beispiel_slider|Link zu einem Beispiel]]

<div id="switch">'''SWITCH'''</div>

{| class="wikitable"
!HTML-Attribut
!Beschreibung
!Default-Wert
|-
!align="right" |data-get
|Name des Reading, was gelesen werden soll
|'STATE'
|-
!align="right" |data-get-on
|Wert, bei dem zum Status ON geschaltet werden soll.
|'on'
|-
!align="right" |data-get-off
|Wert, bei dem zum Status OFF geschaltet werden soll.
|'off'
|-
!align="right" |data-set-on
|Wert, der zu Fhem gesendet werden soll, wenn das Widget auf ON geschaltet wurde
|Wert von data-get-on
|-
!align="right" |data-set-off
|Wert, der zu Fhem gesendet werden soll, wenn das Widget auf OFF geschaltet wurde
|Wert von data-get-off
|-
!align="right" |data-cmd
|Kommando Name (<command> <device> <value>) <br />(z.B setstate, set, setreading, trigger)
|'set'
|-
!align="right" |data-icon
|Name des Font-Awesome Icon.
|'fa-lightbulb-o'
|-
!align="right" |data-background-icon
|Name des Font-Awesome Hintergrund Icon.
|'fa-circle'
|-
!align="right" |data-on-color
|Widget Farbe beim Status ON
|'#aa6900'
|-
!align="right" |data-off-color
|Widget Farbe beim Status OFF
|'#505050'
|}

<code>data-get-on</code> and <code>data-get-off</code> accept also RegEx values. e.g. data-get-on="[0-9]{1,3}|on" means set switch on if STATE is a numeric value or 'on'. data-get-off="!on" means accept all but the data-get-on value (negation)

[[#Beispiel_switch|Link zu einem Beispiel]]

<div id="symbol">'''SYMBOL'''</div>

dual state notation

{| class="wikitable"
!HTML Attribut
!Beschreibung
!Default Wert
|-
!align="right" |data-get
|Name des Reading, was gelesen werden soll
|'STATE'
|-
!align="right" |data-get-on
|value for ON status to get.
|'open'
|-
!align="right" |data-get-off
|value for OFF status to get.
|'closed'
|-
!align="right" |data-icon
|Name des font-awesome-Symbols
|'ftui-window'
|-
!align="right" |data-background-icon
|Hintergrundsymbol
|''
|-
!align="right" |data-on-background-color
|Farbe für ON-Zustand.
|'#aa6900'
|-
!align="right" |data-off-background-color
|Farbe für OFF-Zustand.
|'#505050'
|-
!align="right" |data-on-color
|Farbe für ON-Zustand.
|'#aa6900'
|-
!align="right" |data-off-color
|Farbe für OFF-Zustand.
|'#505050'
|-
|}

multi state notation

{| class="wikitable"
!HTML Attribut
!Beschreibung
!Default Wert
|-
!align="right" |data-get
|Name des Reading, was gelesen werden soll
|'STATE'
|-
!align="right" |data-states
|array of states.
|
|-
!align="right" |data-icons
|Array mit Icons zu data-states Array
|
|-
!align="right" |data-background-icons
|Array mit Icons zu data-states Array
|
|-
!align="right" |data-colors
|array of colors related to the data-states array
|''
|-
!align="right" |data-background-colors
|array of background-colors related to the data-states array
|''
|-
|}

data-get-on,data-get-off and data-states accept also RegEx values. The value for one icon can also contain an additional animatation CSS name, e.g. "fa-exclamation-triangle fa-blink" for a blinking Symbol

[[#Beispiel_symbol|Link zu einem Beispiel]]

<div id="thermostat">'''THERMOSTAT'''</div>

{| class="wikitable"
!HTML Attribut
!Beschreibung
!Default Wert
|-
!align="right" |data-get
|name of the reading to get from Fhem
|'desired-temp'
|-
!align="right" |data-temp
|reading for measured temperature of thermostates
|'measured-temp'
|-
!align="right" |data-set
|command to send to Fhem (set <device> <command> <value>)
|'desired-temp'
|-
!align="right" |data-valve
|reading for valve position of thermostates
|
|-
!align="right" |data-min
|minimal value to set
| 10
|-
!align="right" |data-max
|maximal value to set
| 30
|-
!align="right" |data-minColor
|Farbe des Keises für Min
| #4477FF
|-
!align="right" |data-maxColor
|Farbe des Kreises für Max, zwischen Min und Max wird linear interpoliert
| #FF0000
|-
!align="right" |data-step
|step size for value adjustment e.g. 0.5
|1
|-
!align="right" |data-bgColor
|Die Farbe der Kreises zwischen den ticks
|'transparent'
|-
!align="right" |data-fgColor
|Die Farbe der zahl im Kreismittelpunkt
|#bbbbbb
|-
!align="right" |data-tkColor
|Die Farbe der ticks
|#696969
|-
|-
!align="right" |data-angleOffset
|Start der ticks im Kreis (in Winkelgraden, 0 = oben)
| -120
|-
!align="right" |data-angleArc
|Bereich der ticks im Kreis (in Winkelgraden)
|240
|-
!align="right" |class
|big, readonly
|
|-
|}

[[#Beispiel_thermostat|Link zu einem Beispiel]]

<div id="volume">'''VOLUME'''</div>

{| class="wikitable"
!HTML Attribut
!Beschreibung
!Default Wert
|-
!align="right" |data-get
|name of the reading to get from Fhem
|'STATE'
|-
!align="right" |data-set
|command to send to Fhem (set <device> <command> <value>)
|''
|-
!align="rigth" |data-cmd
|name of the command (<command> <device> <value>) (e.g. setstate, set, setreading, trigger)
|'set'
|-
!align="right" |data-min
|minimal value to set
|0
|-
!align="right" |data-max
|maximal value to set
|70
|-
!align="right" |class
|small, hue-tick, hue-front, hue-back, dim-tick ,dim-front, dim-back
|
|-
|}

[[#Beispiel_volume|Link zu einem Beispiel]] (fehlt noch)

<div id="weather">'''WEATHER'''</div>

{| class="wikitable"
!HTML Attribut
!Beschreibung
!Default Wert
|-
!align="right" |data-get
|name of the reading to get the weather literal from Fhem
|'STATE'
|-
!align="right" |data-imageset
|collection of images to display current weather situation. Possible values: 'meteocons', 'kleinklima'
|'meteocons'
|-
!align="right" |data-image-path
|path to the images of the selected imageset
|/images/weather/
|-
|}

[[#Beispiel_weather|Link zu einem Beispiel]]

== Widgets -- Beispiele ==

<div id="Beispiel_chart">'''Chart'''</div>

Display a chart with similar capabilities as the FHEM plots

<pre>
<div class="normal">
data-type="chart"
data-logdevice='["Log.Garden","Log.Garden","Log.Garden","Log.Predicted"]'
data-columnspec='["4:Garden.T:15:","10:Garden.T:0:delta-h","10:Garden.T:0:delta-d","4:predicted.*:15:"]'
data-style='["ftui l0fill","ftui l1fill","ftui l2","ftui l3dot"]'
data-ptype='["lines","histeps","histeps","cubic"]'
data-uaxis='["primary","secondary","secondary","primary"]'
data-legend='["Temperature","Rain/hour","Rain/day","Predicted Temp."]'
data-yunit="°C"
data-ytext="Temperature"
data-minvalue="auto"
data-maxvalue="auto"
data-yunit_sec="mm"
data-ytext_sec="Rain (mm)"
data-height="250"
data-yticks="auto"
data-minvalue_sec="auto"
data-maxvalue_sec="auto"
data-nofulldays="true"
data-daysago_start="2013-08-13T00:00:00"
data-daysago_end="2013-08-14T00:00:00"
data-cursorgroup="1"
data-scrollgroup="1"
data-xticks="auto">
</div>
</pre>

[[Datei:chart_tabletUI.png]]

<div id="Beispiel_circlemenu">'''Circlemenu'''</div>

Cover a lot of other button behind one single button

<pre>
<div class="left">
<div data-type="circlemenu" class="cell circlemenu">
<ul class="menu">
<li><div data-type="push" data-icon="fa-wrench"></div></li>
<li><div data-type="push" data-device="AvReceiver"
data-set="remoteControl subwoofer-temporary-level -6"
data-icon="">-6</div></li>
<li><div data-type="push" data-device="AvReceiver"
data-set="remoteControl subwoofer-temporary-level -2"
data-icon="">-2</div></li>
<li><div data-type="push" data-device="AvReceiver"
data-set="remoteControl subwoofer-temporary-level 0"
data-icon="">0</div></li>
<li><div data-type="push" data-device="AvReceiver"
data-set="remoteControl subwoofer-temporary-level +3"
data-icon="">2</div></li>
<li><div data-type="push" data-device="AvReceiver"
data-set="remoteControl subwoofer-temporary-level +9"
data-icon="">9</div></li>
<li><div data-type="push" data-device="AvReceiver"
data-set="remoteControl subwoofer-temporary-level +C"
data-icon="">12</div></li>
</ul>
</div>
<div data-type="label" class="cell">Woofer</div>
</div>
</pre>

[[Datei:circlemenu_tabletUI.png]]

<div id="Beispiel_dimmer">'''Dimmer'''</div>

Dimmer Widget Beispiel für Philips Hue

Minimalvariante
<pre>
<div data-type="dimmer" data-device="HUEDevice1"
data-get-on="!off" data-get-off="off"
data-set="pct"</div>
</pre>

Mit Anzeige der Dimstufe
<pre>
<div data-type="dimmer" data-device="HUEDevice1"
data-get="onoff"
data-get-on="1" data-get-off="0"
data-set=""
data-set-on="on" data-set-off="off"
data-dim="pct">
</div>
</pre>

Dimmer Widget für MilightDevice

<pre>
<div data-type="dimmer"
data-device="SonstWas"
data-get="brightness"
data-get-off="0"
data-get-on="[1-9][0-9]*"
data-set-on="on"
data-set-off="off"
data-dim="dim"
data-min="0"
data-max="100"
></div>
</pre>

<div id="Beispiel_homestatus">'''Homestatus'''</div>

Beispiel rechts im Bild:
<pre>
<div data-type="homestatus" data-device='dummy1'
data-get-on='["1","2","3","4"]'
data-alias='["Home","Night","Away","Holiday"]'
data-icons='["fa-home","fa-bed","fa-car","fa-suitcase"]'>
</div>
</pre>

Beispiel links im Bild:
<pre>
<div data-type="homestatus" data-device='dummy1'
data-get-on='["home","asleep","absent","gone","gotosleep"]'
data-alias='["Home","Night","Away","Holiday","Retire"]'
data-icons='["fa-fire","fa-film","fa-plus","fa-car","fa-tint"]'
data-version='residents'>
</div>
</pre>

[[Datei:homestatus_tabletUI.png]]

<div id="Beispiel_image">'''Image'''</div>

Erzeugt ein Widget mit einem Bild aus dem www, das alle 5 Sekunden aktualisiert wird (hier eine Wetterkarte vom DWD).

<pre>
<div data-type="image"
data-size="80%"
data-url="http://www.dwd.de/wundk/wetter/de/Deutschland.jpg"
</div>
</pre>

[[Datei:image_tabletUI.jpg]]

Example for how to add an image to the dashboard which its URL is delivered by a Fhem module like PROPLANTA:

<pre>
<div data-type="image" data-device="Wetter1"
data-get="fc0_weatherDayIcon"
data-size="40px"
class="cell">
</div>
</pre>

<div id="Beispiel_label">'''Label'''</div>

Example for HM-WDS40-TH-I Funk-Temperatur-/Feuchtesensor innen

<pre>
STATE T: 20.0 H: 61
</pre>
<pre>
<div data-type="label" data-device="THSensorWZ"
data-part="2" data-unit="%B0C%0A" class="cell big"></div>
<div data-type="label" class="cell">Temperatur</div>
<div data-type="label" data-device="THSensorWZ" data-part="4"
data-unit="%" class="cell big"></div>
<div data-type="label" class="cell">Luftfeuchte</div>
</pre>

But the same result can reached by getting single readings:
<pre>
humidity 58
temperature 20.1
</pre>

<pre>
<div data-type="label" data-device="THSensorWZ"
data-get="temperature" data-unit="%B0C%0A" class="cell big"></div>
<div data-type="label" class="cell">Temperatur</div>
<div data-type="label" data-device="THSensorWZ"
data-get="humidity" data-unit="%" class="cell big"></div>
<div data-type="label" class="cell">Luftfeuchte</div>
</pre>

Example for how to influence the color of the label according to value limits
<pre>
<div data-type="label"
data-device="OutTemp"
data-limits='[-73,10,23]'
data-colors='["#6699FF","#AA6900","#FF0000"]'
data-unit="%B0C%0A"
class="cell big">
</div>
</pre>

Example for how to create a widget for shutter via push: show state and set up/down
<pre>
<div data-type="switch"
data-device="wzRollo"
data-get-on="up"
data-get-off="down"
data-icon="fa-bars"
class="cell" >
</div>
<div data-type="label"
class="cell">Rollo</div>
</pre>

Example for how to create a label for a time value in short format with usage of RegEx.

<pre>
<div data-type="label"
data-device="dummy1"
data-part="(\d\d\.\d\d\.).*"
class="cell">
</div>
</pre>

Example for how to show two labels in one line.

<pre>
<div class="">
<div type="label" device="OnSunrise" class="inline"></div>bis
<div type="label" device="OnSunset" class="inline"></div>
</div>
</pre>

Beispiel für die Anzeige des UV-Indexes und der Abhängigkeit der anzuzeigenden Farbe.

<pre>
<div data-type="label" class="wider cell bigger" data-device="ProVorhersage"
data-get="fc0_uv"
data-limits="[-2, 2, 5, 7, 10]"
data-colors='["#66FF33","#FFFF00","#FF6600","#FF0000","#993399"]'></div>
<div data-type="label" class="cell" data-device="ProVorhersage" data-get="fc0_date"></div>
<div data-type="label" class="wider cell bigger" data-device="ProVorhersage"
data-get="fc1_uv"
data-limits="[-2, 2, 5, 7, 10]"
data-colors='["#66FF33","#FFFF00","#FF6600","#FF0000","#993399"]'></div>
<div data-type="label" class="cell" data-device="ProVorhersage" data-get="fc1_date"></div>
</pre>

[[Datei:label_tabletUI.jpg]]

<div id="Beispiel_pagetab">'''Pagetab'''</div>

Example for a tab menu to switch smoothly between multiple pages. Multiple pagetabs in a template file: menu.html

<pre>
<html>
<body>
<header>MENU</header>
<div class="cell">
<div data-type="pagetab" data-url="index.html" data-icon="fa-home" class="cell"></div>
<div data-type="pagetab" data-url="index_2.html" data-icon="fa-sliders" class="cell"></div>
<div data-type="pagetab" data-url="index_3.html" data-icon="fa-music" class="cell"></div>
<div data-type="pagetab" data-url="index_4.html" data-icon="fa-hotel" class="cell"></div>
<div data-type="pagetab" data-url="index_5.html" data-icon="fa-music" class="cell"></div>
<div data-type="pagetab" data-url="index_6.html" data-icon="fa-database" class="cell"></div>
<div data-type="pagetab" data-url="index_7.html" data-icon="fa-fax" class="cell"></div>
</div>
</body>
</html>
</pre>

<div id="Beispiel_playstream">'''Playstream'''</div>

Erzeugt einen Knopf zum direkten Abspielen eines Webradio-Streams.

<pre>
<div data-type="playstream" data-url="http://radioeins.de/stream"></div>
<div data-type="label" class="darker">Radio eins</div>
</pre>

<div id="Beispiel_push">'''Push'''</div>

Example for how to create a push button widget to trigger all devices on:

<pre>
<div data-type="push"
data-device="LightAll"
data-cmd="trigger"
data-set="on"
class="cell">
</div>
</pre>

Beispiel für zwei horizontale Buttons:

<pre>
<div class="cell">
<div class="doublebox-h">
<div data-type="push" data-device="Rollo"
data-icon="fa-angle-up" data-background-icon="fa-square-o"
data-set="up">
</div>
<div data-type="push" data-device="Rollo"
data-icon="fa-angle-down" data-background-icon="fa-square-o"
data-set="down">
</div>
</div>
</div>
</pre>

[[Datei:push1.png]]

Beispiel für zwei quadratische vertikale Buttons:

<pre>
<div class="cell">
<div class="doublebox-v">
<div data-type="push" data-device="Rollo"
data-icon="fa-chevron-up" data-background-icon="fa-square-o"
data-set="up">
</div>
<div data-type="push" data-device="Rollo"
data-icon="fa-chevron-down" data-background-icon="fa-square-o"
data-set="down">
</div>
</div>
</div>
</pre>

[[Datei:push2.png]]

<div id="Beispiel_rotor">'''Rotor'''</div>

Example for a rotor widget, which switches between to days of weather forecast

<pre>
<div data-type="rotor" class="fade">
<ul>
<li>
<div data-type="label" class="darker">Heute</div>
<div data-type="weather" data-device="AgroWeather" data-get="fc0_weatherDay" class="big"></div>
<div data-type="label" data-device="AgroWeather" data-get="fc0_weatherDay" class=""></div>
<div data-type="label" data-device="AgroWeather" data-get="fc0_tempMax" data-unit="%B0C%0A" class="large"></div>
</li>
<li>
<div data-type="label" class="darker">Morgen</div>
<div data-type="weather" data-device="AgroWeather" data-get="fc1_weatherDay" class="big"></div>
<div data-type="label" data-device="AgroWeather" data-get="fc1_weatherDay" class=""></div>
<div data-type="label" data-device="AgroWeather" data-get="fc1_tempMax" data-unit="%B0C%0A" class="large"></div>
</li>
</ul>
</div>
</pre>

<div id="Beispiel_select">'''Select'''</div>

Erzeugt zwei Comboboxen zur Auswahl des Eingang eines 2-Zonen-AV-Receivers. Die Liste für Zone2 ist fest, die Liste für Zone1 wird von Fhem übergeben.

<pre>
<div class="cell wider">
<div data-type="label" class="inline wider">Zone2</div>
<div data-type="select" data-device="AvReceiverZ2" data-items='["Airplay","Webradio","BD/DVD","PHONO"]' data-get="input" data-set="input" class="cell w2x" ></div>
<div></div>
<div data-type="label" class="inline">Zone1</div>
<div data-type="select" data-device="AvReceiver" data-list="inputs" data-get="input" data-set="input" class="cell w2x" ></div>
</div>
</pre>

[[Datei:select_tabeltUI.png]]

<div id="Beispiel_slider">'''Slider'''</div>

Slider mit einstellbaren Werten von 10 bis 90:

<pre>
<div data-type="slider"
data-device='Dummy1'
data-min="10"
data-max="90"
class="cell" >
</div>
<div data-type="label" class="cell">Light1</div>
</pre>

[[Datei:slider_tabletUI.png]]

Horizontal angeordneter Slider:

<pre>
<div data-type="slider"
data-device='Dummy1'
data-min="0"
data-max="100"
class="horizontal"
</div>
</pre>

[[Datei:slider_tabletUI2.jpg]]

<div id="Beispiel_switch">'''Switch'''</div>

Schalter. Usage of RegEx pattern for state request:

<pre>
<div data-type="switch" class="cell"
data-device="MILIGHT_Zone1_Wohnzimmer"
data-get-on="on.*"
data-get-off="off"></div>
</pre>

[[Datei:switch.png]]

Beispiel für eine Gruppe von Schaltern, um zwischen vier verschiedenen Werten eines device umzuschalten:

<pre>
<div class="cell left">
<div data-type="switch" data-device="dummy1"
data-get-off="((?!Wert1).)*"
data-get-on="Wert1" class="cell" ></div>
<div data-type="label" class="cell">Wert1</div>
<div data-type="switch" data-device="dummy1"
data-get-off="((?!Wert2).)*"
data-get-on="Wert2" class="cell" ></div>
<div data-type="label" class="cell">Wert2</div>
<div data-type="switch" data-device="dummy1"
data-get-off="((?!Wert3).)*"
data-get-on="Wert3" class="cell" ></div>
<div data-type="label" class="cell">Wert3</div>
<div data-type="switch" data-device="dummy1"
data-get-off="((?!Wert4).)*"
data-get-on="Wert4" class="cell" ></div>
<div data-type="label" class="cell">Wert4</div>
</div>
</pre>

[[Datei:switch4.png]]

<div id="Beispiel_symbol">'''Symbol'''</div>

Example for a tristate icon

<pre>
<div data-type="symbol" data-device="dummy1"
data-get-on='["wert1","wert2","wert3"]'
data-icons='["fa-arrow-up","fa-user","fa-arrow-down"]'
data-on-colors='["SeaGreen","SlateBlue","IndianRed"]'
class="cell big">
</div>
</pre>

Example for a tristate icon with blink and spin animation

<pre>
<div data-type="symbol" data-device="dummy1"
data-icons='["fa-exclamation-triangle fa-blink","fa-exclamation-circle","fa-cog fa-spin"]'
data-on-colors='["Crimson","GoldenRod","SeaGreen"]'
data-get-on='["Wert1","Wert2","Wert3"]' >
</div>
</pre>

Example for a battery level control with RegEx

<pre>
<div data-type="symbol" data-device="BadHeizung" data-get="batteryLevel"
data-icons='["oa-measure_battery_100","oa-measure_battery_75","oa-measure_battery_50","oa-measure_battery_25","oa-measure_battery_0"]'
data-get-on='["3\\.[0-9]","2\\.[789]","2\\.[456]","2\\.[123]","((2\\.0)|([01]\\.[0-9]))"]'
data-on-colors='["#505050","#505050","#505050","#ad3333","#ad3333"]'>
</div>
</pre>

Example for a battery level control with greater-equal compare and 90° rotated symbols

<pre>
<div data-type="symbol" data-device="BadHeizung" data-get="batteryLevel"
data-icons='["oa-measure_battery_0 fa-rotate-90","oa-measure_battery_25 fa-rotate-90","oa-measure_battery_50 fa-rotate-90","oa-measure_battery_75 fa-rotate-90","oa-measure_battery_0 fa-rotate-90"]'
data-get-on='["0","2","2.4","2.7","3.0"]'
data-on-colors='["#ad3333","#ad3333","#505050","#505050","#505050"]'>
</div>
</pre>

<div id="Beispiel_thermostat">'''Thermostat'''</div>

Configure as data-device='...' that item which delivers temp and desired-temp as reading.

Default parameters are:
<pre>
data-get="desired-temp" data-temp="measured-temp" data-set="desired-temp"
</pre>

Therefor for HomaMatic HM-CC-RT-DN this is sufficient.

<pre>
<div data-type="thermostat" data-device='KH_Clima' class="cell"></div>
</pre>

The long format looks like this:

<pre>
<div data-type="thermostat"
data-device="KH_Clima"
data-get="desired-temp"
data-temp="measured-temp"
class="cell">
</div>
</pre>

Example for MAX!:
<pre>
<div data-type="thermostat" data-device="HZ_Tuer"
data-valve="valveposition"
data-get="desiredTemperature"
data-temp="temperature"
data-set="desiredTemperature"
class="cell">
</div>
</pre>

The wigets will show the valve value only in case of a valid data-valve attribute. The default for data-valve ist null. That means, a empty data-valve attribute hides the valve label for the widget.

[[Datei:thermostat.png]]

<div id="Beispiel_weather">'''Weather'''</div>

Das Widget fügt ein dem Wetter entsprechendes Bild ein. Die Daten können durch Fhem-Module wie [[PROPLANTA]], [[OPENWEATHER]] und [[Weather]] bereitgestellt werden.
Add 'big' or 'bigger' to CSS class to get a bigger weather icon.

Beispiel:
<pre>
<div data-type="weather"
data-device="Weather"
data-get="fc0_weatherDay"
class="cell big">
</div>
</pre>

[[Datei:weather.png]]

== Icon-Konfiguration ==

* Eingebaute Icons: Diese haben das ftui-Präfix. Zurzeit sind folgende verfügbar: ftui-window, ftui-door

* Mehr als 500 Icons von "http://fortawesome.github.io/Font-Awesome/icons" verfügbar. Einfach den Icon-Namen angeben (Präfix "fa-" nicht vergessen, Z.B. <code>data-icon="fa-volume-up"</code>

* Es stehen auch Openautomation Font-Files zur Verfügung. Wer sie nutzen möchte, muss folgende Stylesheets in die index.html hinzufügen.
<pre>
<link rel="stylesheet" href="/fhem/tablet/lib/openautomation.css" />
<link rel="stylesheet" href="/fhem/tablet/lib/fhemSVG.css" />
</pre>

Diese font icons haben das Präfix 'fs-' bzw. 'oa-'.

Beispiel bei einem Schalter:
<pre><div data-type="switch" data-device='dummy1' data-icon="oa-secur_locked"></div></pre>

Und so als großes Symbol:
<pre>
<div data-type="symbol" data-device='dummy1'
data-icon="oa-status_frost"
data-on-color="#bb3232"
data-get-on="on"
data-get-off="!on"
class="bigger">
</div>
</pre>

Die Icons kann man auch etwas dicker darstellen mit den Zusatz bold: <code>data-icon="oa-secur_locked bold"</code>

Die Namen der verfügbaren Icons findet man auch in den CSS Files (openautomation.css / fhemSVG.css)

== Spezial ==
Folgender Befehl setzt einen direkten Befehl an Fhem ab (<code>set dummy1 off</code>):
<pre>
<div onclick="setFhemStatus('set dummy1 off')">All off!</div>
</pre>

== FAQ ==
Häufig gestellte Fragen zum FHEM Tablet UI sind in der [[FHEM_Tablet_UI/FAQ|FHEM Tablet UI FAQ]] zusammengestellt.

== Links ==
* [http://forum.fhem.de/index.php/topic,34233.0.html Forums-Beitrag]
* [https://github.com/knowthelist/fhem-tablet-ui Projekt auf Github]
* [http://forum.fhem.de/index.php/topic,37378.0.html User-Demos]
* [https://github.com/ovibox/fhem-ftui-user-demos Download der User-Demo-Dateien]

[[Kategorie:FHEM Frontends]]