FHEMWiki - Benutzerbeiträge [de]

HTTPS-Absicherung & Authentifizierung via nginx Webserver

2023-04-08T04:33:46Z

LordVoodoo: Formatkorrekturen

Ähnlich wie im Artikel [[Apache Authentication Proxy]] kann FHEM auch mit dem schlankeren nginx Webserver abgesichert werden. Nach diesem Artikel ist die Kommunikation zum FHEM-Server via HTTPS verschlüsselt und eine Authentifizierung nur via Benutzername und Passwort möglich. Externer Zugriff aus dem eigenen Netzwerk/Internet soll damit unterbunden werden; die Kommunikation und Authentifizierung findet verschlüsselt statt.
== Voraussetzungen ==
Vorausgesetzt wird eine funktionierende FHEM Installation. Die dadurch erbrachten Linux Kenntnisse reichen für die Umsetzung dieses Artikels. Weiterführende Links zu Zertifikaten und dem nginx-Webserver befinden sich im Anhang des Artikels.

Ausgegangen wird von einer FHEM-Installation, die auf Port 8083 via HTTP hört. Dieser Port wird abgesichert, indem er nur noch lokal und nicht mehr über das Netzwerk erreichbar ist. Anfragen auf Port 80 (HTTP, nginx) werden weitergeleitet zum lokalen Port 443 (HTTPS, nginx), der wiederum einen Reverse Proxy auf den Port 8083 (HTTPS, fhem) einrichtet. Mit leichten Modifizierungen könnte nginx auch auf einem separaten Server betrieben werden. Die benötigten Zertifikate für die HTTPS Verschlüsselung können eigenhändig angelegt werden. Der/die autorisierten Benutzer werden in einer verschlüsselten Datei hinterlegt, die nginx für die Authentifizierung benutzt.

Getestet wurde das Setup auf einem Raspberry Pi (Raspbian - basierend auf Debian 8 und 9) und fhem 5.7 bzw. fhem 5.8. Die beschriebenen Befehle sollten sich ohne weiteres auf Ubuntu oder andere Debian-Derivate übertragen lassen. Das beschriebene Konzept lässt sich aber auf jedes Unix-Derivat anwenden.

==Unterscheidung von Browser auf PC und mobilen Endgeräten==

Zusätzlich kann man mit nginx sehr bequem zwischen PC und mobilen Endgeräten unterscheiden und damit verschiedene FHEMWEB - Instanzen aufrufen.

==Anpassungen: fhem-Config==
In der FHEM-Konfiguration muss sichergestellt werden, dass kein Client außerhalb des Servers zugreifen kann. Dazu muss das normalerweise gesetzte Flag global von jeglicher Konfiguration entfernt werden.

Beispielkonfiguration:
<nowiki>
...

# define telnetPort telnet 7072 global

define WEB FHEMWEB 8083
attr WEB stylesheetPrefix dark
# attr WEB HTTPS

define WEBphone FHEMWEB 8084
attr WEBphone stylesheetPrefix darksmallscreen

# define WEBtablet FHEMWEB 8085 global
# attr WEBtablet stylesheetPrefix touchpad
</nowiki>
fhem neustarten:
<syntaxhighlight lang="bash"> $ sudo service fhem stop && sudo service fhem start </syntaxhighlight>

== Installation: nginx als reverse Proxy ==
nginx installieren:
<syntaxhighlight lang="bash">$ sudo apt-get install nginx </syntaxhighlight>

Danach im Pfad '''/etc/nginx/sites-available''' eine neue Proxy Konfiguration anlegen:
<syntaxhighlight lang="bash">$ sudo touch /etc/nginx/sites-available/reverse-proxy</syntaxhighlight>
Inhalt der Datei '''reverse-proxy''':
<syntaxhighlight lang="go">
server {
listen 80;
return 301 https://$host$request_uri;
}

server {

listen 443;
server_name fhempi;

# check user agent
if ($http_user_agent ~* '(iPhone|iPod|Opera Mini|Android.*Mobile|NetFront|PSP|BlackBerry|Windows Phone)') {
set $ua_type "@mobile";
}

ssl_certificate /etc/nginx/cert.crt;
ssl_certificate_key /etc/nginx/cert.key;

ssl on;
ssl_session_cache builtin:1000 shared:SSL:10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
ssl_prefer_server_ciphers on;

access_log /var/log/nginx/fhem.access.log;

location / {

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_http_version 1.1;

# Gehe zu FHEMWEB wenn kein mobiler Browser
if ($ua_type != "@mobile"){
proxy_pass http://localhost:8083;
}
# Gehe zu FHEMWEB smallscreen wenn mobiler Browser
if ($ua_type = "@mobile"){
proxy_pass http://localhost:8084;
}
proxy_read_timeout 90;
#proxy_read_timeout 20736000;
#proxy_buffering off;

# User Sickboy's Erweiterung für verschlüsselte Websocket-Kommunikation (siehe Diskussionsseite)
# Für normale Benutzer derzeit kommentiert, vom Autor Andremotz noch bisher ungetestet
# ... daher derzeit auskommentiert
# Wird für 'longpoll' benötigt (z.B. bei FTUI)
#set $my_http_upgrade "";
#set $my_connection "Connection";

#if ($http_upgrade = "websocket") {
# set $my_http_upgrade $http_upgrade;
# set $my_connection "upgrade";
#}

#proxy_set_header Upgrade $my_http_upgrade;
#proxy_set_header Connection $my_connection;

auth_basic "Restricted Content";
auth_basic_user_file /etc/nginx/.htpasswd;

# proxy_redirect http://localhost:8083 https://localhost;
}
}
</syntaxhighlight>
Mit dieser Konfiguration werden zwei Server-Instanzen auf Port 80 und Port 443 angelegt. Surft ein Browser/eine App Port 80 an, wird er umgehend zum verschlüsselten Port 443 weitergeleitet. Die Zertifikate befinden sich im lokalen Verzeichnis unter /etc/nginx und verschlüsselt wird via TLS.

Nginx' Default-Konfiguration muss noch deaktiviert und die Reverse-Proxy-Einstellungen verlinkt werden
<syntaxhighlight lang="bash">
$ sudo unlink /etc/nginx/sites-enabled/default
$ sudo ln -s /etc/nginx/sites-available/reverse-proxy /etc/nginx/sites-enabled/reverse-proxy
</syntaxhighlight>

Hinweis: Ein User hatte für mich nicht nachvollziehbare Probleme und empfiehlt folgende Settings:
<syntaxhighlight lang="go">
proxy_read_timeout 2073600;
proxy_buffering off;
</syntaxhighlight>

== User anlegen für Authentifizierung ==
Der Username und das verschlüsselte Passwort werden mit den folgenden Kommandos in die Datei ’’ ’/etc/nginx/.htpasswd’’’ geschrieben, das nginx in der Konfiguration für die User-Authentifizierung benutzt.

Username '''maxmustermann''' anlegen (Doppelpunkt nach Username nicht übersehen!):
<syntaxhighlight lang="bash">$ sudo sh -c "echo -n 'maxmustermann:' >> /etc/nginx/.htpasswd" </syntaxhighlight>

Passwort-Prompt aufrufen:
<syntaxhighlight lang="bash">$ sudo sh -c "openssl passwd -apr1 >> /etc/nginx/.htpasswd" </syntaxhighlight>

== Zertifikatserstellung ==
Erst durch die Zertifikate ist eine verschlüsselte Kommunikation zwischen Browser und nginx möglich
Beide beschriebenen Optionen sind dabei gleichermaßen sicher. Damit allerdings nicht jedes ausgestelle Zertifikat vertraut wird, gibt es das Konzept der Certificate Authorities ('CA', näheres siehe Links). Jeder gängige Browser warnt den Benutzer vor einem Zertifikat, das von keiner Thrusted Authority ausgestellt wurde, bietet jedoch dem Benutzer die Möglichkeit, trotzdem fortzufahren. Durch die Tatsache, dass das Zertifikat selbst erstellt und signiert wird, kann diese Warnung im Browser später getrost umgangen werden.

Selbst signiertes Zertifikat erstellen:
<syntaxhighlight lang="bash">$ sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/cert.key -out /etc/nginx/cert.crt </syntaxhighlight>
Dabei werden für die Erstellung ein paar Angaben abgefragt. Wichtig ist dabei der Common Name, der identisch mit der später verwendeten Domain oder öffentliche IP-Adresse sein muss.
<nowiki>
Country Name (2 letter code) [AU]:AT
State or Province Name (full name) [Some-State]:Vienna
Locality Name (eg, city) []:Vienna
Organization Name (eg, company) []:privat
Organizational Unit Name (eg, section) []:privat
Common Name (e.g. server FQDN or YOUR name) []:meine_domain_oder_ip
Email Address []:admin@meinedomain
</nowiki>

nginx neustarten, um die Änderungen und das Zertifikat zu übernehmen:
<syntaxhighlight lang="bash">$ sudo service nginx reload </syntaxhighlight>

Der folgende Aufruf sollten bereits eingerichteten FHEM-Server via Passwort-Abfrage und HTTPS absichern:
<nowiki>http://<fhemserver></nowiki>

== Bekannte Fehlerquellen ==
=== Beim Aufruf http://<fhempi> wird nur eine "Wilkommen bei nginx"-Seite angezeigt, statt der erwartete Login-Screen ===
Nach einer Neuinstallation dem Autor selber passiert. Fehler war, dass die nginx-Default-Konfiuguration noch aktiv war. Der Link zur Default-Konfiguration muss entfernt werden, bzw. gleich komplett gelöscht werden

=== Wenn ich mich einlogge, bekomme ich nur einen 500 internal Server error. Ich habe garantiert alles richtig konfiguriert! ===
Ebenfalls dem Autor nach einer Neuinstallation passiert: Fehler war, dass das Passwort durch einen Copy & Paste-Fehler falsch eingetragen wurde. Der Fehlerfall kann umgangen werden, indem zuerst die .htpasswd-Datei gelöscht wird und der User und ein simples Passwort neu angelegt werden. Danach mit einer neuen Browser-Session Fhem ansurfen (am besten Firefox im Privat-Modus, damit sämtliche Cookies & sonstiges Buffering umgangen wird)

== Alternative: Nutzung des NGINX Proxy Managers ==
FHEM ist kompatibel mit dem [https://nginxproxymanager.com NGINX Proxy Manager], welcher sich insbesondere für Docker-Umgebungen eignet. Falls eine Trennung zwischen mobilen Endgeräten und größeren Bildschirmen notwendig ist, dann kann dies über separate Subdomains erfolgen.

'''Wichtig:''' Die FHEM-WEB-Instanz ist mit HTTPS und komplexen Passworten abzusichern.
{| class="wikitable"
|+Einstellungen
!Details
!
!SSL
!
|-
|Domain Names:
|fhem.mydomain.com
|SSL Certificate
|Request a new SSL certificate
|-
|Scheme:
|https
|
|
|-
|Forward Hostname / IP:
|fhem (hier kann der Docker-interne Service Name verwendet werden)
|
|
|-
|Port:
|8083
|
|
|-
|Zusatzeinstellungen:
|Block Common Exploits

Wegsocket Support
|Zusatzeinstellungen:
|Force SSL

HSTS

HTTP/2 Support

HSTS Subdomains
|}

== Quellen & weiterführende Links ==
* [https://www.digitalocean.com/community/tutorials/how-to-create-an-ssl-certificate-on-nginx-for-ubuntu-14-04 How To Create an SSL Certificate on Nginx for Ubuntu 14.04]
* [https://linuxconfig.org/setting-up-nginx-reverse-proxy-server-on-debian-linux Setting up Nginx Reverse Proxy server on Debian Linux]
* [https://www.digitalocean.com/community/tutorials/how-to-set-up-password-authentication-with-nginx-on-ubuntu-14-04 How To Set Up Password Authentication with Nginx on Ubuntu 14.04]
* [https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure Wikipedia: HTTPS]
* [https://de.wikipedia.org/wiki/Transport_Layer_Security Wikipedia: TLS]

[[Kategorie:HOWTOS]]

HTTPS-Absicherung & Authentifizierung via nginx Webserver

2023-04-08T04:32:34Z

LordVoodoo: Abschnitt NGINX Proxy Manager

Ähnlich wie im Artikel [[Apache Authentication Proxy]] kann FHEM auch mit dem schlankeren nginx Webserver abgesichert werden. Nach diesem Artikel ist die Kommunikation zum FHEM-Server via HTTPS verschlüsselt und eine Authentifizierung nur via Benutzername und Passwort möglich. Externer Zugriff aus dem eigenen Netzwerk/Internet soll damit unterbunden werden; die Kommunikation und Authentifizierung findet verschlüsselt statt.
== Voraussetzungen ==
Vorausgesetzt wird eine funktionierende FHEM Installation. Die dadurch erbrachten Linux Kenntnisse reichen für die Umsetzung dieses Artikels. Weiterführende Links zu Zertifikaten und dem nginx-Webserver befinden sich im Anhang des Artikels.

Ausgegangen wird von einer FHEM-Installation, die auf Port 8083 via HTTP hört. Dieser Port wird abgesichert, indem er nur noch lokal und nicht mehr über das Netzwerk erreichbar ist. Anfragen auf Port 80 (HTTP, nginx) werden weitergeleitet zum lokalen Port 443 (HTTPS, nginx), der wiederum einen Reverse Proxy auf den Port 8083 (HTTPS, fhem) einrichtet. Mit leichten Modifizierungen könnte nginx auch auf einem separaten Server betrieben werden. Die benötigten Zertifikate für die HTTPS Verschlüsselung können eigenhändig angelegt werden. Der/die autorisierten Benutzer werden in einer verschlüsselten Datei hinterlegt, die nginx für die Authentifizierung benutzt.

Getestet wurde das Setup auf einem Raspberry Pi (Raspbian - basierend auf Debian 8 und 9) und fhem 5.7 bzw. fhem 5.8. Die beschriebenen Befehle sollten sich ohne weiteres auf Ubuntu oder andere Debian-Derivate übertragen lassen. Das beschriebene Konzept lässt sich aber auf jedes Unix-Derivat anwenden.

==Unterscheidung von Browser auf PC und mobilen Endgeräten==

Zusätzlich kann man mit nginx sehr bequem zwischen PC und mobilen Endgeräten unterscheiden und damit verschiedene FHEMWEB - Instanzen aufrufen.

==Anpassungen: fhem-Config==
In der FHEM-Konfiguration muss sichergestellt werden, dass kein Client außerhalb des Servers zugreifen kann. Dazu muss das normalerweise gesetzte Flag global von jeglicher Konfiguration entfernt werden.

Beispielkonfiguration:
<nowiki>
...

# define telnetPort telnet 7072 global

define WEB FHEMWEB 8083
attr WEB stylesheetPrefix dark
# attr WEB HTTPS

define WEBphone FHEMWEB 8084
attr WEBphone stylesheetPrefix darksmallscreen

# define WEBtablet FHEMWEB 8085 global
# attr WEBtablet stylesheetPrefix touchpad
</nowiki>
fhem neustarten:
<syntaxhighlight lang="bash"> $ sudo service fhem stop && sudo service fhem start </syntaxhighlight>

== Installation: nginx als reverse Proxy ==
nginx installieren:
<syntaxhighlight lang="bash">$ sudo apt-get install nginx </syntaxhighlight>

Danach im Pfad '''/etc/nginx/sites-available''' eine neue Proxy Konfiguration anlegen:
<syntaxhighlight lang="bash">$ sudo touch /etc/nginx/sites-available/reverse-proxy</syntaxhighlight>
Inhalt der Datei '''reverse-proxy''':
<syntaxhighlight lang="go">
server {
listen 80;
return 301 https://$host$request_uri;
}

server {

listen 443;
server_name fhempi;

# check user agent
if ($http_user_agent ~* '(iPhone|iPod|Opera Mini|Android.*Mobile|NetFront|PSP|BlackBerry|Windows Phone)') {
set $ua_type "@mobile";
}

ssl_certificate /etc/nginx/cert.crt;
ssl_certificate_key /etc/nginx/cert.key;

ssl on;
ssl_session_cache builtin:1000 shared:SSL:10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
ssl_prefer_server_ciphers on;

access_log /var/log/nginx/fhem.access.log;

location / {

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_http_version 1.1;

# Gehe zu FHEMWEB wenn kein mobiler Browser
if ($ua_type != "@mobile"){
proxy_pass http://localhost:8083;
}
# Gehe zu FHEMWEB smallscreen wenn mobiler Browser
if ($ua_type = "@mobile"){
proxy_pass http://localhost:8084;
}
proxy_read_timeout 90;
#proxy_read_timeout 20736000;
#proxy_buffering off;

# User Sickboy's Erweiterung für verschlüsselte Websocket-Kommunikation (siehe Diskussionsseite)
# Für normale Benutzer derzeit kommentiert, vom Autor Andremotz noch bisher ungetestet
# ... daher derzeit auskommentiert
# Wird für 'longpoll' benötigt (z.B. bei FTUI)
#set $my_http_upgrade "";
#set $my_connection "Connection";

#if ($http_upgrade = "websocket") {
# set $my_http_upgrade $http_upgrade;
# set $my_connection "upgrade";
#}

#proxy_set_header Upgrade $my_http_upgrade;
#proxy_set_header Connection $my_connection;

auth_basic "Restricted Content";
auth_basic_user_file /etc/nginx/.htpasswd;

# proxy_redirect http://localhost:8083 https://localhost;
}
}
</syntaxhighlight>
Mit dieser Konfiguration werden zwei Server-Instanzen auf Port 80 und Port 443 angelegt. Surft ein Browser/eine App Port 80 an, wird er umgehend zum verschlüsselten Port 443 weitergeleitet. Die Zertifikate befinden sich im lokalen Verzeichnis unter /etc/nginx und verschlüsselt wird via TLS.

Nginx' Default-Konfiguration muss noch deaktiviert und die Reverse-Proxy-Einstellungen verlinkt werden
<syntaxhighlight lang="bash">
$ sudo unlink /etc/nginx/sites-enabled/default
$ sudo ln -s /etc/nginx/sites-available/reverse-proxy /etc/nginx/sites-enabled/reverse-proxy
</syntaxhighlight>

Hinweis: Ein User hatte für mich nicht nachvollziehbare Probleme und empfiehlt folgende Settings:
<syntaxhighlight lang="go">
proxy_read_timeout 2073600;
proxy_buffering off;
</syntaxhighlight>

== User anlegen für Authentifizierung ==
Der Username und das verschlüsselte Passwort werden mit den folgenden Kommandos in die Datei ’’ ’/etc/nginx/.htpasswd’’’ geschrieben, das nginx in der Konfiguration für die User-Authentifizierung benutzt.

Username '''maxmustermann''' anlegen (Doppelpunkt nach Username nicht übersehen!):
<syntaxhighlight lang="bash">$ sudo sh -c "echo -n 'maxmustermann:' >> /etc/nginx/.htpasswd" </syntaxhighlight>

Passwort-Prompt aufrufen:
<syntaxhighlight lang="bash">$ sudo sh -c "openssl passwd -apr1 >> /etc/nginx/.htpasswd" </syntaxhighlight>

== Zertifikatserstellung ==
Erst durch die Zertifikate ist eine verschlüsselte Kommunikation zwischen Browser und nginx möglich
Beide beschriebenen Optionen sind dabei gleichermaßen sicher. Damit allerdings nicht jedes ausgestelle Zertifikat vertraut wird, gibt es das Konzept der Certificate Authorities ('CA', näheres siehe Links). Jeder gängige Browser warnt den Benutzer vor einem Zertifikat, das von keiner Thrusted Authority ausgestellt wurde, bietet jedoch dem Benutzer die Möglichkeit, trotzdem fortzufahren. Durch die Tatsache, dass das Zertifikat selbst erstellt und signiert wird, kann diese Warnung im Browser später getrost umgangen werden.

Selbst signiertes Zertifikat erstellen:
<syntaxhighlight lang="bash">$ sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/cert.key -out /etc/nginx/cert.crt </syntaxhighlight>
Dabei werden für die Erstellung ein paar Angaben abgefragt. Wichtig ist dabei der Common Name, der identisch mit der später verwendeten Domain oder öffentliche IP-Adresse sein muss.
<nowiki>
Country Name (2 letter code) [AU]:AT
State or Province Name (full name) [Some-State]:Vienna
Locality Name (eg, city) []:Vienna
Organization Name (eg, company) []:privat
Organizational Unit Name (eg, section) []:privat
Common Name (e.g. server FQDN or YOUR name) []:meine_domain_oder_ip
Email Address []:admin@meinedomain
</nowiki>

nginx neustarten, um die Änderungen und das Zertifikat zu übernehmen:
<syntaxhighlight lang="bash">$ sudo service nginx reload </syntaxhighlight>

Der folgende Aufruf sollten bereits eingerichteten FHEM-Server via Passwort-Abfrage und HTTPS absichern:
<nowiki>http://<fhemserver></nowiki>

== Bekannte Fehlerquellen ==
=== Beim Aufruf http://<fhempi> wird nur eine "Wilkommen bei nginx"-Seite angezeigt, statt der erwartete Login-Screen ===
Nach einer Neuinstallation dem Autor selber passiert. Fehler war, dass die nginx-Default-Konfiuguration noch aktiv war. Der Link zur Default-Konfiguration muss entfernt werden, bzw. gleich komplett gelöscht werden

=== Wenn ich mich einlogge, bekomme ich nur einen 500 internal Server error. Ich habe garantiert alles richtig konfiguriert! ===
Ebenfalls dem Autor nach einer Neuinstallation passiert: Fehler war, dass das Passwort durch einen Copy & Paste-Fehler falsch eingetragen wurde. Der Fehlerfall kann umgangen werden, indem zuerst die .htpasswd-Datei gelöscht wird und der User und ein simples Passwort neu angelegt werden. Danach mit einer neuen Browser-Session Fhem ansurfen (am besten Firefox im Privat-Modus, damit sämtliche Cookies & sonstiges Buffering umgangen wird)

== Alternative: Nutzung des NGINX Proxy Managers ==
FHEM ist kompatibel mit dem [https://nginxproxymanager.com NGINX Proxy Manager], welcher sich insbesondere für Docker-Umgebungen eignet. Falls eine Trennung zwischen mobilen Endgeräten und größeren Bildschirmen notwendig ist, dann kann dies über separate Subdomains erfolgen.

'''Wichtig:''' Die FHEM-WEB-Instanz ist mit HTTPS und komplexen Passworten abzusichern.

Einstellungen:

Port: 8083

aktivieren

aktivieren

SSL:
{| class="wikitable"
|+
!Details
!
!SSL
!
|-
|Domain Names:
|fhem.mydomain.com
|SSL Certificate
|Request a new SSL certificate
|-
|Scheme:
|https
|
|
|-
|Forward Hostname / IP:
|fhem (hier kann der Docker-interne Service Name verwendet werden)
|
|
|-
|Port:
|8083
|
|
|-
|Zusatzeinstellungen:
|Block Common Exploits

Wegsocket Support
|Zusatzeinstellungen:
|Force SSL aktivieren

HSTS aktivieren

HTTP/2 Support aktivieren

HSTS Subdomains aktivieren
|}

== Quellen & weiterführende Links ==
* [https://www.digitalocean.com/community/tutorials/how-to-create-an-ssl-certificate-on-nginx-for-ubuntu-14-04 How To Create an SSL Certificate on Nginx for Ubuntu 14.04]
* [https://linuxconfig.org/setting-up-nginx-reverse-proxy-server-on-debian-linux Setting up Nginx Reverse Proxy server on Debian Linux]
* [https://www.digitalocean.com/community/tutorials/how-to-set-up-password-authentication-with-nginx-on-ubuntu-14-04 How To Set Up Password Authentication with Nginx on Ubuntu 14.04]
* [https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure Wikipedia: HTTPS]
* [https://de.wikipedia.org/wiki/Transport_Layer_Security Wikipedia: TLS]

[[Kategorie:HOWTOS]]

TV Programm

2022-11-20T09:02:51Z

LordVoodoo: /* Variante 4 (RSS Daten einlesen): */ Auslesen des rss-Feed mittels des Moduls rssFeed ohne Umweg über eine rss2json-Konvertierung. Der vorher genannte Dienst rss2json.com cached die Ergebnisse und so erhält man ohne dynamische URL-Anpassung, z.B. timestamp als Zusatzparameter in der URL, keine Zeitgenossen Ergebnisse. Weiterhin hat man eine dynamische Sortierreihenfolge, beim rssFeed scheint diese fix zu sein.

Sich das aktuelle Fernsehprogramm in FHEM anzeigen zu lassen, ist leider gar nicht so einfach. Die einzelnen Anbieter stellen keine entsprechenden Schnittstellen zur Verfügung, um auf einfache Art und Weise das aktuelle Fernsehprogramm für beliebige Sender einlesen und darstellen zu können. Mit ein paar Tricks funktioniert es aber trotzdem.

Hierfür gibt es gleich mehrere Ansätze:
* Im einfachsten Fall bindet man sich ein iframe in die FHEM Weboberfläche ein. Einige Anbieter bieten sogar einen personalisierten Zugriff, so das man sich eine Übersicht nur mit den gewünschten Sendern zusammen stellen kann.
* Es besteht die Möglichkeit EPG Daten in einem speziellen xmltv Format in die FHEM Installation zu laden (enthält das Programm für 6-7 Tage), diese XML Datei zu parsen und dann in FHEM z.B. über eine readingsGroup darzustellen.
* Für Linux und auch Windows sind Tools verfügbar, mit denen man die Seiten von verschiedenen TV Programmanbietern grabben und daraus eine XML Datei im xmltv Format erstellen kann (enthält das Programm von 1-14 Tagen je nach Anbieter). Einer der bekanntesten Vertreter ist WebGrab++. Diese XML Datei kann dann wieder in FHEM eingelesen und angezeigt werden z.B. über eine readingsGroup. Das Parsen der Daten ist mit einem sehr hohen Traffic verbunden, so das hier die vorher erwähnten Methoden vorzuziehen sind.
* Es gibt Webseiten, die das TV Programm als rss zur Verfügung stellen. Darüber hinaus gibt es Services die online rss zu json konvertieren. Kombiniert man nun beides, dann kann man mit httpmod das Ganze mit wenigen Zeilen einlesen.
* Über httpmod könnte man eine Webseite eines TV Programmanbieters zyklisch einlesen und die für FHEM notwendigen Daten extrahieren. Von dieser Methode ist dringend abzuraten, da diese einen enormen Traffic sowohl für einen selbst, als auch für den Anbieter bedeutet. Aus diesem Grund soll diese Methode hier auch nicht dargestellt werden.

== Variante 1 (iframe): ==
<pre>
define wl_TV weblink iframe <Webseite des TV Programmanbieters z.B. http://www.klack.de/fernsehprogramm/was-laeuft-gerade/0/0/all.html>
attr wl_TV htmlattr width="1024" height="768"
</pre>

Das Attribut legt die Größe des iframes fest und kann beliebig angepasst werden.

== Variante 2 (Download der EPG Daten): ==

Dieser Ansatz ist bereits etwas komplizierter, aber immer noch sehr einfach einzubinden.

=== Vorbereitungen: ===
==== Fehlende Perl Module installieren: ====

<pre>
sudo apt-get install libxml-bare-perl libdatetime-perl wget xz-utils
</pre>

Die ersten beiden Bibliotheken werden benötigt, um die XML Datei zu parsen. wget wird benötigt um die Datei zu downloaden und xz enthält den Unpacker für die runtergeladene Datei.

==== Pfad für den Download anlegen und mit den entsprechenden Rechten versehen: ====

<pre>
sudo mkdir /opt/fhem/tv
sudo chown fhem:dialout /opt/fhem/tv
</pre>

In diesem Verzeichnis soll später die mit wget runtergeladene XML Datei landen.

==== 99_myUtils.pm erweitern: ====

Dieser Code kann einfach in die Zwischenablage kopiert und in die Datei 99_myUtils.pm eingefügt werden.

<pre>
sub rgUnfold($$)
{
my ($device, $reading) = @_;
my $title = ReadingsVal($device, $reading.'title', 'na');
my $desc = ReadingsVal($device, $reading.'stitle', 'na')."\n\n".
ReadingsVal($device, $reading.'desc', 'na');

$title =~ s/(.{1,45}|\S{46,})(?:\s[^\S\r\n]*|\Z)/$1 /g;
$desc =~ s/ /\n/g;
$desc =~ s/(.{1,65}|\S{66,})(?:\s[^\S\r\n]*|\Z)/$1 /g;
$desc =~ s/[\r\'\"]/ /g;
$desc =~ s/[\n]|\\n/ /g;
return "<a href=\"#!\" onclick=\"FW_okDialog('".$desc."')\">".$title."</a>";
}
</pre>

==== Dummy Device anlegen: ====

Dieses Device dient zur Datenhaltung. Hier werden immer die nächsten 3 Sendungen und die 3 Primetime Sendungen des aktuellen Tages als Readings abgelegt.

<pre>
define dmy_TV dummy
</pre>

==== Perl Script einrichten: ====

Den folgenden Code in die Datei tv.pl kopieren und in den Ordner /opt/fhem/tv/tv.pl kopieren:

<pre>
#!/usr/bin/perl
use strict;
use warnings;
use utf8;
use Date::Parse;
use Encode qw(encode_utf8 decode_utf8);
use XML::Bare 0.53 qw(forcearray);
use Data::Dumper;

my $channelFilter = qr/^(?:ARD\.|ZDF\.|Sat1\.|RTL\.|RTL2\.|Pro7\.|DMax\.|Vox\.|Kabel\.|KabelEinsClassic\.|KabelEinsDoku\.|ntv\.|ProSiebenMaxx\.|Sixx\.|TLC\.|N24Doku\.|SonyEntertainmentTV\.|AandE\.|TNTSerie\.|AnimalPlanet\.|History\.|Kinowelt\.|NatGeoHD\.|PLANET\.|Silverline\.|13thStreet\.|AXN\.|SciFi\.|TNTFilm\.)/;
my $timeAdjust = 0;

#my $channelFilter = qr/^(?:ARD|ZDF$|SAT\.1|RTL$|RTL II|PRO 7|DMAX|VOX|KABEL 1|13TH STREET|ANIMAL PLANET|Silverline|TNT Film|N24|kabel eins classics|ProSieben MAXX|Syfy|AE|TLC|AXN|sixx|Kinowelt TV|History)/;
#my $timeAdjust = 86400;

# internal variable
my $timepiece = 0;

eval "use Time::Piece";
$timepiece = 1 if (!$@);

sub xmltv2epoch($)
{
my $t = shift;

if (1 == $timepiece)
{
return Time::Piece->strptime($t, '%Y%m%d%H%M%S %z')->epoch;
}
else
{
substr($t, 8, 0) = 'T';

return str2time($t);
}
}

sub FmtDateTime($)
{
my @t = localtime(shift);
return sprintf("%04d-%02d-%02d %02d:%02d:%02d", $t[5]+1900, $t[4]+1, $t[3], $t[2], $t[1], $t[0]);
}

sub filterText($)
{
my $text = shift;

$text =~ s/["`;'\r]//g;
$text =~ s/[\n]/ /g;

return $text;
}

sub tvParse($;$)
{
my ($device, $mode) = @_;
my $obj = XML::Bare->new(file => '/opt/fhem/tv/rytecDE_Basic');
my $xml = $obj->parse();
my $lastChannel = '';
my $reading = '';
my $i = 0;
my $n = 0;
my $k = 0;
my $primeTime = substr(FmtDateTime(time() + $timeAdjust), 0, 11).'20:14:00';
my $sendTelnet = '';

if (!$@)
{
my $old = time() + $timeAdjust;

foreach (@{forcearray($xml->{'tv'}{'programme'})})
{
if ($_->{'channel'}{'value'} =~ $channelFilter)
{
my $stop = xmltv2epoch($_->{'stop'}{'value'});

# filter old stuff
if ($stop > $old)
{
if ($lastChannel ne $_->{'channel'}{'value'})
{
$lastChannel = $_->{'channel'}{'value'};
$reading = $_->{'channel'}{'value'};
$reading =~ s/[\.\s]//g;
$reading =~ s/de$//;
$i = 0;
$n = 0;
}

if ($i < 3 && (!defined($mode) || 'next' eq $mode))
{
my $fi = sprintf("%03d", $i);
my $start = xmltv2epoch($_->{'start'}{'value'});
my $readingName;
my $readingValue;

$readingName = 'next_'.$reading.'_'.$fi.'_bdate';
$readingValue = substr(FmtDateTime($start), 0, 10);
$sendTelnet .= ";setreading $device $readingName $readingValue";

$readingName = 'next_'.$reading.'_'.$fi.'_btime';
$readingValue = substr(FmtDateTime($start), 11, 8);
$sendTelnet .= ";setreading $device $readingName $readingValue";

#$readingName = 'next_'.$reading.'_'.$fi.'_edate';
#$readingValue = substr(FmtDateTime($stop), 0, 10);
#$sendTelnet .= ";setreading $device $readingName $readingValue";

#$readingName = 'next_'.$reading.'_'.$fi.'_etime';
#$readingValue = substr(FmtDateTime($stop), 11, 8);
#$sendTelnet .= ";setreading $device $readingName $readingValue";

$readingName = 'next_'.$reading.'_'.$fi.'_title';
$readingValue = filterText(@{forcearray($_->{'title'})}[0]->{'value'});
$sendTelnet .= ";setreading $device $readingName $readingValue";

$readingName = 'next_'.$reading.'_'.$fi.'_stitle';
if (exists($_->{'sub-title'}{'value'}))
{
$readingValue = filterText($_->{'sub-title'}{'value'});
}
else
{
$readingValue = 'na';
}
$sendTelnet .= ";setreading $device $readingName $readingValue";

$readingName = 'next_'.$reading.'_'.$fi.'_desc';
if (exists($_->{'desc'}{'value'}))
{
$readingValue = filterText($_->{'desc'}{'value'});
}
else
{
$readingValue = 'na';
}
$sendTelnet .= ";setreading $device $readingName $readingValue";

$i++;
$k++;
}

if ($n < 3 && (!defined($mode) || 'prime' eq $mode))
{
my $start = xmltv2epoch($_->{'start'}{'value'});
my $fmtStart = FmtDateTime($start);
my $bdate = substr($fmtStart, 0, 10);
my $btime = substr($fmtStart, 11, 8);

if ($bdate.' '.$btime gt $primeTime)
{
my $fn = sprintf("%03d", $n);
my $readingName;
my $readingValue;

$readingName = 'prime_'.$reading.'_'.$fn.'_bdate';
$readingValue = substr(FmtDateTime($start), 0, 10);
$sendTelnet .= ";setreading $device $readingName $readingValue";

$readingName = 'prime_'.$reading.'_'.$fn.'_btime';
$readingValue = substr(FmtDateTime($start), 11, 8);
$sendTelnet .= ";setreading $device $readingName $readingValue";

#$readingName = 'prime_'.$reading.'_'.$fn.'_edate';
#$readingValue = substr(FmtDateTime($stop), 0, 10);
#$sendTelnet .= ";setreading $device $readingName $readingValue";

#$readingName = 'prime_'.$reading.'_'.$fn.'_etime';
#$readingValue = substr(FmtDateTime($stop), 11, 8);
#$sendTelnet .= ";setreading $device $readingName $readingValue";

$readingName = 'prime_'.$reading.'_'.$fn.'_title';
$readingValue = filterText(@{forcearray($_->{'title'})}[0]->{'value'});
$sendTelnet .= ";setreading $device $readingName $readingValue";

$readingName = 'prime_'.$reading.'_'.$fn.'_stitle';
if (exists($_->{'sub-title'}{'value'}))
{
$readingValue = filterText($_->{'sub-title'}{'value'});
}
else
{
$readingValue = 'na';
}
$sendTelnet .= ";setreading $device $readingName $readingValue";

$readingName = 'prime_'.$reading.'_'.$fn.'_desc';
if (exists($_->{'desc'}{'value'}))
{
$readingValue = filterText($_->{'desc'}{'value'});
}
else
{
$readingValue = 'na';
}
$sendTelnet .= ";setreading $device $readingName $readingValue";

$n++;
$k++;
}
}

if ($k >= 10)
{
#system('/opt/fhem/fhem.pl 7072 "'.$sendTelnet.'"');
my $result = `perl /opt/fhem/fhem.pl 7072 "$sendTelnet"`;

$k = 0;
$sendTelnet = '';
}
}
}
}

if ('' ne $sendTelnet)
{
#system('/opt/fhem/fhem.pl 7072 "'.$sendTelnet.'"');
my $result = `perl /opt/fhem/fhem.pl 7072 "$sendTelnet"`;
}
}
}

sub tvMerge($$)
{
my ($dstName, $srcName) = @_;
my $fh;
my $dst;
my $src;
my $start = '';
my $channels1 = '';
my $channels2 = '';
my $programms1 = '';
my $programms2 = '';
my $end = '';

open($fh, '<', $dstName) or die "Can't open file $!";
read($fh, $dst, -s $fh);
close($fh);

open($fh, '<', $srcName) or die "Can't open file $!";
read($fh, $src, -s $fh);
close($fh);

if ($dst =~ /^(.*?)<channel/s)
{
$start = $1;
}

if ($dst =~ /<\/programme>(?!.*<\/programme>)(.*)$/s)
{
$end = $1;
}

while ($dst =~ /(\s*<channel\s.*?<\/channel>)/sg)
{
$channels1 .= $1;
}

while ($dst =~ /(\s*<programme\s.*?<\/programme>)/sg)
{
$programms1 .= $1;
}

while ($src =~ /(\s*<channel\s.*?<\/channel>)/sg)
{
$channels2 .= $1;
}

while ($src =~ /(\s*<programme\s.*?<\/programme>)/sg)
{
$programms2 .= $1;
}

open($fh, '>', $dstName) or die "Can't open file $!";
print $fh $start.$channels1.$channels2.$programms1.$programms2.$end;
close($fh);
}

sub tvDownload()
{
# other server
# http://www.xmltvepg.nl/rytecDE_Basic.xz
# http://91.121.106.172/~rytecepg/epg_data/rytecDE_Basic.xz
# http://www.vuplus-community.net/rytec/rytecDE_Common.xz
# http://www.xmltvepg.nl/rytecDE_Common.xz
# http://91.121.106.172/~rytecepg/epg_data/rytecDE_Common.xz
# http://www.vuplus-community.net/rytec/rytecDE_SportMovies.xz
# http://www.xmltvepg.nl/rytecDE_SportMovies.xz
# http://91.121.106.172/~rytecepg/epg_data/rytecDE_SportMovies.xz
my $output = qx(wget http://www.vuplus-community.net/rytec/rytecDE_Basic.xz -O /opt/fhem/tv/rytecDE_Basic.xz 2>&1);
#my $output = qx(wget http://192.168.178.100:8083/fhem/www/images/guide.xml -O /opt/fhem/tv/rytecDE_Basic 2>&1);
#print $output;
$output = qx(xz -df /opt/fhem/tv/rytecDE_Basic.xz 2>&1);
#print $output;
}

sub tvDownloadMerge()
{
# other server
# http://www.xmltvepg.nl/rytecDE_Basic.xz
# http://91.121.106.172/~rytecepg/epg_data/rytecDE_Basic.xz
# http://www.vuplus-community.net/rytec/rytecDE_Common.xz
# http://www.xmltvepg.nl/rytecDE_Common.xz
# http://91.121.106.172/~rytecepg/epg_data/rytecDE_Common.xz
# http://www.vuplus-community.net/rytec/rytecDE_SportMovies.xz
# http://www.xmltvepg.nl/rytecDE_SportMovies.xz
# http://91.121.106.172/~rytecepg/epg_data/rytecDE_SportMovies.xz
my $output = qx(wget http://www.vuplus-community.net/rytec/rytecDE_Basic.xz -O /opt/fhem/tv/rytecDE_Basic.xz 2>&1);
#print $output;
$output = qx(xz -df /opt/fhem/tv/rytecDE_Basic.xz 2>&1);
#print $output;
$output = qx(wget http://www.vuplus-community.net/rytec/rytecDE_Common.xz -O /opt/fhem/tv/rytecDE_Common.xz 2>&1);
#print $output;
$output = qx(xz -df /opt/fhem/tv/rytecDE_Common.xz 2>&1);
#print $output;
tvMerge('/opt/fhem/tv/rytecDE_Basic', '/opt/fhem/tv/rytecDE_Common');
}

my $d = shift || die "Need a device!\n";
my $m = shift || die "Need a mode!\n";

# mode 'parse': update next and prime
# mode 'next' : update next only
# mode 'prime': update prime only
if ('download' eq $m)
{
tvDownload();
}
elsif ('downloadMerge' eq $m)
{
tvDownloadMerge();
}
elsif ('parse' eq $m)
{
tvParse($d);
}
else
{
tvParse($d, $m);
}

exit;

</pre>

Sowohl das Verzeichnis, als auch das Script selbst muss mit den entsprechenden Rechten versehen werden:

<pre>
sudo chmod 744 /opt/fhem/tv/tv.pl
sudo chown fhem:dialout /opt/fhem/tv/tv.pl
</pre>

Bei Bedarf kann nun innerhalb des Scriptes die Senderliste angepasst werden.

Jetzt muss der Download einmalig von der Konsole (nicht mit der FHEM Befehlszeile verwechseln!) gestartet werden, da man ansonsten mehrere Tage warten muss, bis alles funktioniert:

<pre>
perl /opt/fhem/tv/tv.pl dmy_TV downloadMerge
</pre>

Danach muss die entstandene Datei /opt/fhem/tv/rytecDE_Basic mit den richtigen Rechten ausgestattet werden:

<pre>
sudo chown fhem:dialout /opt/fhem/tv/rytecDE_Basic
</pre>

==== at Devices anlegen: ====

3 "at" Devices müssen angelegt werden. Eins für den Download (alle 3 Tage 1x), eins für das Parsen der aktuellen Daten ins Dummy Device (alle 15 Minuten) und eins für das Parsen der Primtime Sendungen (einmal am Tag). Die 3 "at" sind als raw Definitionen kopiert und können auch als solche wieder angelegt werden. Dazu irgend ein Device öffnen, ganz unten auf "Raw definition" klicken und alles entfernen. Den Code von hier einfügen und ausführen und die Devices sind angelegt. Jedes at Device muss separat angelegt werden!

<pre>
defmod at_TV_DOWNLOAD at *00:10:00 {if ((1 == $wday) || (4 == $wday)) {fhem("\"perl /opt/fhem/tv/tv.pl dmy_TV downloadMerge\"")}}
</pre>

<pre>
defmod at_TV_UPDATE at +*00:15:00 "perl /opt/fhem/tv/tv.pl dmy_TV next"
</pre>

<pre>
defmod at_TV_UPDATE_PRIME at *00:15:00 "perl /opt/fhem/tv/tv.pl dmy_TV prime"
</pre>

Damit sind die Vorbereitungen abgeschlossen!

=== Dummy Device mit Daten füllen: ===

Dieser Vorgang muss nur einmalig gemacht werden, damit sofort Ergebnisse sichtbar sind und man nicht erst 15 Minuten warten muss.

<pre>
set at_TV_UPDATE execNow
</pre>

=== readingsGroups anlegen: ===

Zuletzt müssen wir uns noch 2 readingsGroups anlegen, damit das aktuelle TV Programm in FHEM auch dargestellt werden kann. Die readingsGroups müssen, wie zuvor die at Devices, als Raw Import importiert werden!:

Aktuelle Sendungen:
<pre>
defmod rg_TV readingsGroup <Sender>,<ab>,<Aktuelle Sendung>,<|>,<ab>,<Sendung>,<|>,<ab>,<Sendung>\
dmy_TV:<%tv/ard>,next_ARD_000_btime,<{rgUnfold($DEVICE,'next_ARD_000_')}@next_ARD_000_title>,<|>,next_ARD_001_btime,<{rgUnfold($DEVICE,'next_ARD_001_')}@next_ARD_001_title>,<|>,next_ARD_002_btime,<{rgUnfold($DEVICE,'next_ARD_002_')}@next_ARD_002_title>\
dmy_TV:<%tv/zdf>,next_ZDF_000_btime,<{rgUnfold($DEVICE,'next_ZDF_000_')}@next_ZDF_000_title>,<|>,next_ZDF_001_btime,<{rgUnfold($DEVICE,'next_ZDF_001_')}@next_ZDF_001_title>,<|>,next_ZDF_002_btime,<{rgUnfold($DEVICE,'next_ZDF_002_')}@next_ZDF_002_title>\
dmy_TV:<%tv/sat1>,next_Sat1_000_btime,<{rgUnfold($DEVICE,'next_Sat1_000_')}@next_Sat1_000_title>,<|>,next_Sat1_001_btime,<{rgUnfold($DEVICE,'next_Sat1_001_')}@next_Sat1_001_title>,<|>,next_Sat1_002_btime,<{rgUnfold($DEVICE,'next_Sat1_002_')}@next_Sat1_002_title>\
dmy_TV:<%tv/rtl>,next_RTL_000_btime,<{rgUnfold($DEVICE,'next_RTL_000_')}@next_RTL_000_title>,<|>,next_RTL_001_btime,<{rgUnfold($DEVICE,'next_RTL_001_')}@next_RTL_001_title>,<|>,next_RTL_002_btime,<{rgUnfold($DEVICE,'next_RTL_002_')}@next_RTL_002_title>\
dmy_TV:<%tv/rtl2>,next_RTL2_000_btime,<{rgUnfold($DEVICE,'next_RTL2_000_')}@next_RTL2_000_title>,<|>,next_RTL2_001_btime,<{rgUnfold($DEVICE,'next_RTL2_001_')}@next_RTL2_001_title>,<|>,next_RTL2_002_btime,<{rgUnfold($DEVICE,'next_RTL2_002_')}@next_RTL2_002_title>\
dmy_TV:<%tv/pro7>,next_Pro7_000_btime,<{rgUnfold($DEVICE,'next_Pro7_000_')}@next_Pro7_000_title>,<|>,next_Pro7_001_btime,<{rgUnfold($DEVICE,'next_Pro7_001_')}@next_Pro7_001_title>,<|>,next_Pro7_002_btime,<{rgUnfold($DEVICE,'next_Pro7_002_')}@next_Pro7_002_title>\
dmy_TV:<%tv/dmax>,next_DMax_000_btime,<{rgUnfold($DEVICE,'next_DMax_000_')}@next_DMax_000_title>,<|>,next_DMax_001_btime,<{rgUnfold($DEVICE,'next_DMax_001_')}@next_DMax_001_title>,<|>,next_DMax_002_btime,<{rgUnfold($DEVICE,'next_DMax_002_')}@next_DMax_002_title>\
dmy_TV:<%tv/vox>,next_Vox_000_btime,<{rgUnfold($DEVICE,'next_Vox_000_')}@next_Vox_000_title>,<|>,next_Vox_001_btime,<{rgUnfold($DEVICE,'next_Vox_001_')}@next_Vox_001_title>,<|>,next_Vox_002_btime,<{rgUnfold($DEVICE,'next_Vox_002_')}@next_Vox_002_title>\
dmy_TV:<%tv/kabel1>,next_Kabel_000_btime,<{rgUnfold($DEVICE,'next_Kabel_000_')}@next_Kabel_000_title>,<|>,next_Kabel_001_btime,<{rgUnfold($DEVICE,'next_Kabel_001_')}@next_Kabel_001_title>,<|>,next_Kabel_002_btime,<{rgUnfold($DEVICE,'next_Kabel_002_')}@next_Kabel_002_title>\
dmy_TV:<%tv/kabel1classic>,next_KabelEinsClassic_000_btime,<{rgUnfold($DEVICE,'next_KabelEinsClassic_000_')}@next_KabelEinsClassic_000_title>,<|>,next_KabelEinsClassic_001_btime,<{rgUnfold($DEVICE,'next_KabelEinsClassic_001_')}@next_KabelEinsClassic_001_title>,<|>,next_KabelEinsClassic_002_btime,<{rgUnfold($DEVICE,'next_KabelEinsClassic_002_')}@next_KabelEinsClassic_002_title>\
dmy_TV:<%tv/13thstreet>,next_13thStreet_000_btime,<{rgUnfold($DEVICE,'next_13thStreet_000_')}@next_13thStreet_000_title>,<|>,next_13thStreet_001_btime,<{rgUnfold($DEVICE,'next_13thStreet_001_')}@next_13thStreet_001_title>,<|>,next_13thStreet_002_btime,<{rgUnfold($DEVICE,'next_13thStreet_002_')}@next_13thStreet_002_title>\
dmy_TV:<%tv/silverline>,next_Silverline_000_btime,<{rgUnfold($DEVICE,'next_Silverline_000_')}@next_Silverline_000_title>,<|>,next_Silverline_001_btime,<{rgUnfold($DEVICE,'next_Silverline_001_')}@next_Silverline_001_title>,<|>,next_Silverline_002_btime,<{rgUnfold($DEVICE,'next_Silverline_002_')}@next_Silverline_002_title>\
dmy_TV:<%tv/tntfilm>,next_TNTFilm_000_btime,<{rgUnfold($DEVICE,'next_TNTFilm_000_')}@next_TNTFilm_000_title>,<|>,next_TNTFilm_001_btime,<{rgUnfold($DEVICE,'next_TNTFilm_001_')}@next_TNTFilm_001_title>,<|>,next_TNTFilm_002_btime,<{rgUnfold($DEVICE,'next_TNTFilm_002_')}@next_TNTFilm_002_title>\
dmy_TV:<%tv/axn>,next_AXN_000_btime,<{rgUnfold($DEVICE,'next_AXN_000_')}@next_AXN_000_title>,<|>,next_AXN_001_btime,<{rgUnfold($DEVICE,'next_AXN_001_')}@next_AXN_001_title>,<|>,next_AXN_002_btime,<{rgUnfold($DEVICE,'next_AXN_002_')}@next_AXN_002_title>\
dmy_TV:<%tv/sonytv>,next_SonyEntertainmentTV_000_btime,<{rgUnfold($DEVICE,'next_SonyEntertainmentTV_000_')}@next_SonyEntertainmentTV_000_title>,<|>,next_SonyEntertainmentTV_001_btime,<{rgUnfold($DEVICE,'next_SonyEntertainmentTV_001_')}@next_SonyEntertainmentTV_001_title>,<|>,next_SonyEntertainmentTV_002_btime,<{rgUnfold($DEVICE,'next_SonyEntertainmentTV_002_')}@next_SonyEntertainmentTV_002_title>\
dmy_TV:<%tv/kinowelt>,next_Kinowelt_000_btime,<{rgUnfold($DEVICE,'next_Kinowelt_000_')}@next_Kinowelt_000_title>,<|>,next_Kinowelt_001_btime,<{rgUnfold($DEVICE,'next_Kinowelt_001_')}@next_Kinowelt_001_title>,<|>,next_Kinowelt_002_btime,<{rgUnfold($DEVICE,'next_Kinowelt_002_')}@next_Kinowelt_002_title>\
dmy_TV:<%tv/pro7maxx>,next_ProSiebenMaxx_000_btime,<{rgUnfold($DEVICE,'next_ProSiebenMaxx_000_')}@next_ProSiebenMaxx_000_title>,<|>,next_ProSiebenMaxx_001_btime,<{rgUnfold($DEVICE,'next_ProSiebenMaxx_001_')}@next_ProSiebenMaxx_001_title>,<|>,next_ProSiebenMaxx_002_btime,<{rgUnfold($DEVICE,'next_ProSiebenMaxx_002_')}@next_ProSiebenMaxx_002_title>\
dmy_TV:<%tv/sixx>,next_Sixx_000_btime,<{rgUnfold($DEVICE,'next_Sixx_000_')}@next_Sixx_000_title>,<|>,next_Sixx_001_btime,<{rgUnfold($DEVICE,'next_Sixx_001_')}@next_Sixx_001_title>,<|>,next_Sixx_002_btime,<{rgUnfold($DEVICE,'next_Sixx_002_')}@next_Sixx_002_title>\
dmy_TV:<%tv/tntserie>,next_TNTSerie_000_btime,<{rgUnfold($DEVICE,'next_TNTSerie_000_')}@next_TNTSerie_000_title>,<|>,next_TNTSerie_001_btime,<{rgUnfold($DEVICE,'next_TNTSerie_001_')}@next_TNTSerie_001_title>,<|>,next_TNTSerie_002_btime,<{rgUnfold($DEVICE,'next_TNTSerie_002_')}@next_TNTSerie_002_title>\
dmy_TV:<%tv/syfy>,next_SciFi_000_btime,<{rgUnfold($DEVICE,'next_SciFi_000_')}@next_SciFi_000_title>,<|>,next_SciFi_001_btime,<{rgUnfold($DEVICE,'next_SciFi_001_')}@next_SciFi_001_title>,<|>,next_SciFi_002_btime,<{rgUnfold($DEVICE,'next_SciFi_002_')}@next_SciFi_002_title>\
dmy_TV:<%tv/ntv>,next_ntv_000_btime,<{rgUnfold($DEVICE,'next_ntv_000_')}@next_ntv_000_title>,<|>,next_ntv_001_btime,<{rgUnfold($DEVICE,'next_ntv_001_')}@next_ntv_001_title>,<|>,next_ntv_002_btime,<{rgUnfold($DEVICE,'next_ntv_002_')}@next_ntv_002_title>\
dmy_TV:<%tv/n24>,next_N24Doku_000_btime,<{rgUnfold($DEVICE,'next_N24Doku_000_')}@next_N24Doku_000_title>,<|>,next_N24Doku_001_btime,<{rgUnfold($DEVICE,'next_N24Doku_001_')}@next_N24Doku_001_title>,<|>,next_N24Doku_002_btime,<{rgUnfold($DEVICE,'next_N24Doku_002_')}@next_N24Doku_002_title>\
dmy_TV:<%tv/history>,next_History_000_btime,<{rgUnfold($DEVICE,'next_History_000_')}@next_History_000_title>,<|>,next_History_001_btime,<{rgUnfold($DEVICE,'next_History_001_')}@next_History_001_title>,<|>,next_History_002_btime,<{rgUnfold($DEVICE,'next_History_002_')}@next_History_002_title>\
dmy_TV:<%tv/planet>,next_PLANET_000_btime,<{rgUnfold($DEVICE,'next_PLANET_000_')}@next_PLANET_000_title>,<|>,next_PLANET_001_btime,<{rgUnfold($DEVICE,'next_PLANET_001_')}@next_PLANET_001_title>,<|>,next_PLANET_002_btime,<{rgUnfold($DEVICE,'next_PLANET_002_')}@next_PLANET_002_title>\
dmy_TV:<%tv/kabel1doku>,next_KabelEinsDoku_000_btime,<{rgUnfold($DEVICE,'next_KabelEinsDoku_000_')}@next_KabelEinsDoku_000_title>,<|>,next_KabelEinsDoku_001_btime,<{rgUnfold($DEVICE,'next_KabelEinsDoku_001_')}@next_KabelEinsDoku_001_title>,<|>,next_KabelEinsDoku_002_btime,<{rgUnfold($DEVICE,'next_KabelEinsDoku_002_')}@next_KabelEinsDoku_002_title>\
dmy_TV:<%tv/animalplanet>,next_AnimalPlanet_000_btime,<{rgUnfold($DEVICE,'next_AnimalPlanet_000_')}@next_AnimalPlanet_000_title>,<|>,next_AnimalPlanet_001_btime,<{rgUnfold($DEVICE,'next_AnimalPlanet_001_')}@next_AnimalPlanet_001_title>,<|>,next_AnimalPlanet_002_btime,<{rgUnfold($DEVICE,'next_AnimalPlanet_002_')}@next_AnimalPlanet_002_title>\
dmy_TV:<%tv/natgeo>,next_NatGeoHD_000_btime,<{rgUnfold($DEVICE,'next_NatGeoHD_000_')}@next_NatGeoHD_000_title>,<|>,next_NatGeoHD_001_btime,<{rgUnfold($DEVICE,'next_NatGeoHD_001_')}@next_NatGeoHD_001_title>,<|>,next_NatGeoHD_002_btime,<{rgUnfold($DEVICE,'next_NatGeoHD_002_')}@next_NatGeoHD_002_title>\
dmy_TV:<%tv/tlc>,next_TLC_000_btime,<{rgUnfold($DEVICE,'next_TLC_000_')}@next_TLC_000_title>,<|>,next_TLC_001_btime,<{rgUnfold($DEVICE,'next_TLC_001_')}@next_TLC_001_title>,<|>,next_TLC_002_btime,<{rgUnfold($DEVICE,'next_TLC_002_')}@next_TLC_002_title>\
dmy_TV:<%tv/ae>,next_AandE_000_btime,<{rgUnfold($DEVICE,'next_AandE_000_')}@next_AandE_000_title>,<|>,next_AandE_001_btime,<{rgUnfold($DEVICE,'next_AandE_001_')}@next_AandE_001_title>,<|>,next_AandE_002_btime,<{rgUnfold($DEVICE,'next_AandE_002_')}@next_AandE_002_title>
attr rg_TV alias Aktuelles TV-Programm
attr rg_TV cellStyle { \
'r:1,c:1' => 'style="color:yellow;;text-align:center;;font-weight:bold;;"',\
'r:1,c:2' => 'style="color:yellow;;text-align:center;;font-weight:bold;;"',\
'r:1,c:3' => 'style="color:yellow;;text-align:center;;font-weight:bold;;"',\
'r:1,c:5' => 'style="color:yellow;;text-align:center;;font-weight:bold;;"',\
'r:1,c:6' => 'style="color:yellow;;text-align:center;;font-weight:bold;;"',\
'r:1,c:8' => 'style="color:yellow;;text-align:center;;font-weight:bold;;"',\
'r:1,c:9' => 'style="color:yellow;;text-align:center;;font-weight:bold;;"'\
}
attr rg_TV group TV Programm
attr rg_TV nonames 1
attr rg_TV style style="font-size:16px;;"
</pre>

Primetime Sendungen:
<pre>
defmod rg_TV_PRIME readingsGroup <Sender>,<ab>,<Sendung>,<|>,<ab>,<Sendung>,<|>,<ab>,<Sendung>\
dmy_TV:<%tv/ard>,prime_ARD_000_btime,<{rgUnfold($DEVICE,'prime_ARD_000_')}@prime_ARD_000_title>,<|>,prime_ARD_001_btime,<{rgUnfold($DEVICE,'prime_ARD_001_')}@prime_ARD_001_title>,<|>,prime_ARD_002_btime,<{rgUnfold($DEVICE,'prime_ARD_002_')}@prime_ARD_002_title>\
dmy_TV:<%tv/zdf>,prime_ZDF_000_btime,<{rgUnfold($DEVICE,'prime_ZDF_000_')}@prime_ZDF_000_title>,<|>,prime_ZDF_001_btime,<{rgUnfold($DEVICE,'prime_ZDF_001_')}@prime_ZDF_001_title>,<|>,prime_ZDF_002_btime,<{rgUnfold($DEVICE,'prime_ZDF_002_')}@prime_ZDF_002_title>\
dmy_TV:<%tv/sat1>,prime_Sat1_000_btime,<{rgUnfold($DEVICE,'prime_Sat1_000_')}@prime_Sat1_000_title>,<|>,prime_Sat1_001_btime,<{rgUnfold($DEVICE,'prime_Sat1_001_')}@prime_Sat1_001_title>,<|>,prime_Sat1_002_btime,<{rgUnfold($DEVICE,'prime_Sat1_002_')}@prime_Sat1_002_title>\
dmy_TV:<%tv/rtl>,prime_RTL_000_btime,<{rgUnfold($DEVICE,'prime_RTL_000_')}@prime_RTL_000_title>,<|>,prime_RTL_001_btime,<{rgUnfold($DEVICE,'prime_RTL_001_')}@prime_RTL_001_title>,<|>,prime_RTL_002_btime,<{rgUnfold($DEVICE,'prime_RTL_002_')}@prime_RTL_002_title>\
dmy_TV:<%tv/rtl2>,prime_RTL2_000_btime,<{rgUnfold($DEVICE,'prime_RTL2_000_')}@prime_RTL2_000_title>,<|>,prime_RTL2_001_btime,<{rgUnfold($DEVICE,'prime_RTL2_001_')}@prime_RTL2_001_title>,<|>,prime_RTL2_002_btime,<{rgUnfold($DEVICE,'prime_RTL2_002_')}@prime_RTL2_002_title>\
dmy_TV:<%tv/pro7>,prime_Pro7_000_btime,<{rgUnfold($DEVICE,'prime_Pro7_000_')}@prime_Pro7_000_title>,<|>,prime_Pro7_001_btime,<{rgUnfold($DEVICE,'prime_Pro7_001_')}@prime_Pro7_001_title>,<|>,prime_Pro7_002_btime,<{rgUnfold($DEVICE,'prime_Pro7_002_')}@prime_Pro7_002_title>\
dmy_TV:<%tv/dmax>,prime_DMax_000_btime,<{rgUnfold($DEVICE,'prime_DMax_000_')}@prime_DMax_000_title>,<|>,prime_DMax_001_btime,<{rgUnfold($DEVICE,'prime_DMax_001_')}@prime_DMax_001_title>,<|>,prime_DMax_002_btime,<{rgUnfold($DEVICE,'prime_DMax_002_')}@prime_DMax_002_title>\
dmy_TV:<%tv/vox>,prime_Vox_000_btime,<{rgUnfold($DEVICE,'prime_Vox_000_')}@prime_Vox_000_title>,<|>,prime_Vox_001_btime,<{rgUnfold($DEVICE,'prime_Vox_001_')}@prime_Vox_001_title>,<|>,prime_Vox_002_btime,<{rgUnfold($DEVICE,'prime_Vox_002_')}@prime_Vox_002_title>\
dmy_TV:<%tv/kabel1>,prime_Kabel_000_btime,<{rgUnfold($DEVICE,'prime_Kabel_000_')}@prime_Kabel_000_title>,<|>,prime_Kabel_001_btime,<{rgUnfold($DEVICE,'prime_Kabel_001_')}@prime_Kabel_001_title>,<|>,prime_Kabel_002_btime,<{rgUnfold($DEVICE,'prime_Kabel_002_')}@prime_Kabel_002_title>\
dmy_TV:<%tv/kabel1classic>,prime_KabelEinsClassic_000_btime,<{rgUnfold($DEVICE,'prime_KabelEinsClassic_000_')}@prime_KabelEinsClassic_000_title>,<|>,prime_KabelEinsClassic_001_btime,<{rgUnfold($DEVICE,'prime_KabelEinsClassic_001_')}@prime_KabelEinsClassic_001_title>,<|>,prime_KabelEinsClassic_002_btime,<{rgUnfold($DEVICE,'prime_KabelEinsClassic_002_')}@prime_KabelEinsClassic_002_title>\
dmy_TV:<%tv/13thstreet>,prime_13thStreet_000_btime,<{rgUnfold($DEVICE,'prime_13thStreet_000_')}@prime_13thStreet_000_title>,<|>,prime_13thStreet_001_btime,<{rgUnfold($DEVICE,'prime_13thStreet_001_')}@prime_13thStreet_001_title>,<|>,prime_13thStreet_002_btime,<{rgUnfold($DEVICE,'prime_13thStreet_002_')}@prime_13thStreet_002_title>\
dmy_TV:<%tv/silverline>,prime_Silverline_000_btime,<{rgUnfold($DEVICE,'prime_Silverline_000_')}@prime_Silverline_000_title>,<|>,prime_Silverline_001_btime,<{rgUnfold($DEVICE,'prime_Silverline_001_')}@prime_Silverline_001_title>,<|>,prime_Silverline_002_btime,<{rgUnfold($DEVICE,'prime_Silverline_002_')}@prime_Silverline_002_title>\
dmy_TV:<%tv/tntfilm>,prime_TNTFilm_000_btime,<{rgUnfold($DEVICE,'prime_TNTFilm_000_')}@prime_TNTFilm_000_title>,<|>,prime_TNTFilm_001_btime,<{rgUnfold($DEVICE,'prime_TNTFilm_001_')}@prime_TNTFilm_001_title>,<|>,prime_TNTFilm_002_btime,<{rgUnfold($DEVICE,'prime_TNTFilm_002_')}@prime_TNTFilm_002_title>\
dmy_TV:<%tv/axn>,prime_AXN_000_btime,<{rgUnfold($DEVICE,'prime_AXN_000_')}@prime_AXN_000_title>,<|>,prime_AXN_001_btime,<{rgUnfold($DEVICE,'prime_AXN_001_')}@prime_AXN_001_title>,<|>,prime_AXN_002_btime,<{rgUnfold($DEVICE,'prime_AXN_002_')}@prime_AXN_002_title>\
dmy_TV:<%tv/sonytv>,prime_SonyEntertainmentTV_000_btime,<{rgUnfold($DEVICE,'prime_SonyEntertainmentTV_000_')}@prime_SonyEntertainmentTV_000_title>,<|>,prime_SonyEntertainmentTV_001_btime,<{rgUnfold($DEVICE,'prime_SonyEntertainmentTV_001_')}@prime_SonyEntertainmentTV_001_title>,<|>,prime_SonyEntertainmentTV_002_btime,<{rgUnfold($DEVICE,'prime_SonyEntertainmentTV_002_')}@prime_SonyEntertainmentTV_002_title>\
dmy_TV:<%tv/kinowelt>,prime_Kinowelt_000_btime,<{rgUnfold($DEVICE,'prime_Kinowelt_000_')}@prime_Kinowelt_000_title>,<|>,prime_Kinowelt_001_btime,<{rgUnfold($DEVICE,'prime_Kinowelt_001_')}@prime_Kinowelt_001_title>,<|>,prime_Kinowelt_002_btime,<{rgUnfold($DEVICE,'prime_Kinowelt_002_')}@prime_Kinowelt_002_title>\
dmy_TV:<%tv/pro7maxx>,prime_ProSiebenMaxx_000_btime,<{rgUnfold($DEVICE,'prime_ProSiebenMaxx_000_')}@prime_ProSiebenMaxx_000_title>,<|>,prime_ProSiebenMaxx_001_btime,<{rgUnfold($DEVICE,'prime_ProSiebenMaxx_001_')}@prime_ProSiebenMaxx_001_title>,<|>,prime_ProSiebenMaxx_002_btime,<{rgUnfold($DEVICE,'prime_ProSiebenMaxx_002_')}@prime_ProSiebenMaxx_002_title>\
dmy_TV:<%tv/sixx>,prime_Sixx_000_btime,<{rgUnfold($DEVICE,'prime_Sixx_000_')}@prime_Sixx_000_title>,<|>,prime_Sixx_001_btime,<{rgUnfold($DEVICE,'prime_Sixx_001_')}@prime_Sixx_001_title>,<|>,prime_Sixx_002_btime,<{rgUnfold($DEVICE,'prime_Sixx_002_')}@prime_Sixx_002_title>\
dmy_TV:<%tv/tntserie>,prime_TNTSerie_000_btime,<{rgUnfold($DEVICE,'prime_TNTSerie_000_')}@prime_TNTSerie_000_title>,<|>,prime_TNTSerie_001_btime,<{rgUnfold($DEVICE,'prime_TNTSerie_001_')}@prime_TNTSerie_001_title>,<|>,prime_TNTSerie_002_btime,<{rgUnfold($DEVICE,'prime_TNTSerie_002_')}@prime_TNTSerie_002_title>\
dmy_TV:<%tv/syfy>,prime_SciFi_000_btime,<{rgUnfold($DEVICE,'prime_SciFi_000_')}@prime_SciFi_000_title>,<|>,prime_SciFi_001_btime,<{rgUnfold($DEVICE,'prime_SciFi_001_')}@prime_SciFi_001_title>,<|>,prime_SciFi_002_btime,<{rgUnfold($DEVICE,'prime_SciFi_002_')}@prime_SciFi_002_title>\
dmy_TV:<%tv/ntv>,prime_ntv_000_btime,<{rgUnfold($DEVICE,'prime_ntv_000_')}@prime_ntv_000_title>,<|>,prime_ntv_001_btime,<{rgUnfold($DEVICE,'prime_ntv_001_')}@prime_ntv_001_title>,<|>,prime_ntv_002_btime,<{rgUnfold($DEVICE,'prime_ntv_002_')}@prime_ntv_002_title>\
dmy_TV:<%tv/n24>,prime_N24Doku_000_btime,<{rgUnfold($DEVICE,'prime_N24Doku_000_')}@prime_N24Doku_000_title>,<|>,prime_N24Doku_001_btime,<{rgUnfold($DEVICE,'prime_N24Doku_001_')}@prime_N24Doku_001_title>,<|>,prime_N24Doku_002_btime,<{rgUnfold($DEVICE,'prime_N24Doku_002_')}@prime_N24Doku_002_title>\
dmy_TV:<%tv/history>,prime_History_000_btime,<{rgUnfold($DEVICE,'prime_History_000_')}@prime_History_000_title>,<|>,prime_History_001_btime,<{rgUnfold($DEVICE,'prime_History_001_')}@prime_History_001_title>,<|>,prime_History_002_btime,<{rgUnfold($DEVICE,'prime_History_002_')}@prime_History_002_title>\
dmy_TV:<%tv/planet>,prime_PLANET_000_btime,<{rgUnfold($DEVICE,'prime_PLANET_000_')}@prime_PLANET_000_title>,<|>,prime_PLANET_001_btime,<{rgUnfold($DEVICE,'prime_PLANET_001_')}@prime_PLANET_001_title>,<|>,prime_PLANET_002_btime,<{rgUnfold($DEVICE,'prime_PLANET_002_')}@prime_PLANET_002_title>\
dmy_TV:<%tv/kabel1doku>,prime_KabelEinsDoku_000_btime,<{rgUnfold($DEVICE,'prime_KabelEinsDoku_000_')}@prime_KabelEinsDoku_000_title>,<|>,prime_KabelEinsDoku_001_btime,<{rgUnfold($DEVICE,'prime_KabelEinsDoku_001_')}@prime_KabelEinsDoku_001_title>,<|>,prime_KabelEinsDoku_002_btime,<{rgUnfold($DEVICE,'prime_KabelEinsDoku_002_')}@prime_KabelEinsDoku_002_title>\
dmy_TV:<%tv/animalplanet>,prime_AnimalPlanet_000_btime,<{rgUnfold($DEVICE,'prime_AnimalPlanet_000_')}@prime_AnimalPlanet_000_title>,<|>,prime_AnimalPlanet_001_btime,<{rgUnfold($DEVICE,'prime_AnimalPlanet_001_')}@prime_AnimalPlanet_001_title>,<|>,prime_AnimalPlanet_002_btime,<{rgUnfold($DEVICE,'prime_AnimalPlanet_002_')}@prime_AnimalPlanet_002_title>\
dmy_TV:<%tv/natgeo>,prime_NatGeoHD_000_btime,<{rgUnfold($DEVICE,'prime_NatGeoHD_000_')}@prime_NatGeoHD_000_title>,<|>,prime_NatGeoHD_001_btime,<{rgUnfold($DEVICE,'prime_NatGeoHD_001_')}@prime_NatGeoHD_001_title>,<|>,prime_NatGeoHD_002_btime,<{rgUnfold($DEVICE,'prime_NatGeoHD_002_')}@prime_NatGeoHD_002_title>\
dmy_TV:<%tv/tlc>,prime_TLC_000_btime,<{rgUnfold($DEVICE,'prime_TLC_000_')}@prime_TLC_000_title>,<|>,prime_TLC_001_btime,<{rgUnfold($DEVICE,'prime_TLC_001_')}@prime_TLC_001_title>,<|>,prime_TLC_002_btime,<{rgUnfold($DEVICE,'prime_TLC_002_')}@prime_TLC_002_title>\
dmy_TV:<%tv/ae>,prime_AandE_000_btime,<{rgUnfold($DEVICE,'prime_AandE_000_')}@prime_AandE_000_title>,<|>,prime_AandE_001_btime,<{rgUnfold($DEVICE,'prime_AandE_001_')}@prime_AandE_001_title>,<|>,prime_AandE_002_btime,<{rgUnfold($DEVICE,'prime_AandE_002_')}@prime_AandE_002_title>
attr rg_TV_PRIME alias TV-Programm Primetime
attr rg_TV_PRIME cellStyle { \
'r:1,c:1' => 'style="color:yellow;;text-align:center;;font-weight:bold;;"',\
'r:1,c:2' => 'style="color:yellow;;text-align:center;;font-weight:bold;;"',\
'r:1,c:3' => 'style="color:yellow;;text-align:center;;font-weight:bold;;"',\
'r:1,c:5' => 'style="color:yellow;;text-align:center;;font-weight:bold;;"',\
'r:1,c:6' => 'style="color:yellow;;text-align:center;;font-weight:bold;;"',\
'r:1,c:8' => 'style="color:yellow;;text-align:center;;font-weight:bold;;"',\
'r:1,c:9' => 'style="color:yellow;;text-align:center;;font-weight:bold;;"'\
}
attr rg_TV_PRIME group TV Programm
attr rg_TV_PRIME nonames 1
attr rg_TV_PRIME style style="font-size:16px;;"
</pre>

Die Icons der readingsGroups müsst ihr natürlich anpassen! Ladet euch einfach irgendwo die Senderlogos runter und speichert diese unter /opt/fhem/www/images/default/tv. Vergesst bitte nicht die entsprechenden Rechte zu setzen:
<pre>
sudo mkdir /opt/fhem/www/images/default/tv
sudo chown fhem:dialout /opt/fhem/www/images/default/tv
</pre>
Jetzt die Icons in das Verzeichnis kopieren und die entsprechenden Rechte für diese Dateien vergeben.
<pre>
sudo chown fhem:dialout *.png
</pre>
Falls die Icons nicht dargestellt werden sollten, könnte eventuell der folgende Befehl helfen:
<pre>
set WEB rereadicons
</pre>

== Variante 3 (EPG Daten selbst erstellen): ==

=== Vorbereitungen: ===

Mono und screen installieren:
<pre>
cd ~
sudo apt-get install mono-runtime libmono-system-data4.0-cil libmono-system-web4.0-cil screen
</pre>

WebGrab++ downloaden:
<pre>
wget http://www.webgrabplus.com/sites/default/files/download/SW/V2.1.0/WebGrabPlus_V2.1_install.tar.gz
</pre>

WebGrab++ entpacken:
<pre>
tar -zxvf WebGrabPlus_V2.1_install.tar.gz
</pre>

WebGrab++ installieren:
<pre>
cd .wg++
./install.sh
</pre>

Nun müssen zuerst einmal die Konfigurationsdateien angepasst werden:
<pre>
sudo nano WebGrab++.config.xml
</pre>

Diese Settings können z.B. verwendet werden:
<pre>
<filename>guide.xml</filename>
<mode>n</mode>
<postprocess grab="y" run="y">rex</postprocess>
<user-agent>Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0</user-agent>
<logging>on</logging>
<retry time-out="15">5</retry>
<timespan>6</timespan>
<update>i</update>
</pre>

Dann müssen noch die Channels eingetragen werden. Diese Channels können von der Webseite von WebGrab++ kopiert werden. Hier einmal Beispielhaft eine Zeile:
<pre>
<channel update="i" site="tvmovie.de" site_id="ard" xmltv_id="ARD">ARD</channel>
</pre>

Jetzt die Datei speichern und schliessen.

Jetzt muss noch die Datei für die Nachbearbeitung angepasst werden:
<pre>
cd rex
sudo nano rex.config.xml
</pre>

Hier können diese Settings verwendet werden:
<pre>
<title lang="de">'title'</title>
<sub-title lang="de">{Episode: 'episode' }'subtitle'</sub-title>
<desc lang="de">'description'{\nProduced in: 'productiondate'. }{\nCategory: 'category(, )'. }{\nActors: 'actor(, )'}{\nDirector: 'director(, )'}{\nPresenter: 'presenter(, )'}</desc>
<credits></credits>
<episode-num></episode-num>
<date></date>
<category></category>
<review>{Ratings: 'rating(, )'.}</review>
<rating></rating>
</pre>

Datei wieder abspeichern und schliessen.

=== EPG Daten grabben und aufbereiten: ===

Bitte vorsichtig sein, das grabben und aufbereiten der Daten kann extrem lange dauern. Fangt am besten mit einem oder 2 Sendern an, um einen ersten Eindruck zu bekommen.

<pre>
cd ~/.wg++
./run.sh
</pre>

=== WebGrab++ in Crontab einbinden: ===

Einfach nur das Script aufzurufen hat bei mir nicht funktioniert. Ich habe deshalb screen verwenden müssen.

<pre>
30 0 * * 1,4 /usr/bin/screen -dmS webgrab /home/<user z.B. pi>/.wg++/run.sh
</pre>

Damit wird der Vorgang alle 3-4 Tage gestartet und generiert das Programm der nächsten Woche. Die entstandene Datei könnte dann über Variante 2 weiter verarbeitet werden.

== Variante 4 (RSS Daten einlesen): ==

Die Website texxas.de stellt das aktuelle TV-Programm in einem RSS-Feed bereit, dies erzeugt eine sehr geringe Downloadmenge. Die Website unterteilt das Programm in verschiedene Kategorien:
* Hauptsender (ARD, ZDF, RTL, ProSieben, Sat.1, Kabel1, VOX)
* Spartensender (Anixe HD, ARTE, Bibel TV, Comedy Central, DMAX, HGTV, Kabel Eins Classics, MTV, One)
* Regionalsender
* Dokumentation
* …

=== rssFeed Device anlegen: ===

Das Attribut rfAllReadingsEvents sorgt dafür, dass EPG-Aktualisierung auch zu Events führen in Verbindung mit event-on-change / event-on-update. Siehe dazu commandref zum Modul rssFeed.

<pre>
defmod Dev_Mutlimedia_EPG_Spartensender rssFeed http://www.texxas.de/tv/spartensenderJetzt.xml 300
attr Dev_Mutlimedia_EPG_Spartensender rfAllReadingsEvents 1
</pre>

Anschließend liegen je Sender zwei Readings vor:
{| class="wikitable"
|+
!Reading
!Wert
|-
|n01_title
|ARD Alpha: Panoramabilder
|-
|n01_description
|20.11.2022 08:20 - 09:45
|-
|n02_title
|ARTE: 27 - Das europäische Magazin
|-
|n02_description
|20.11.2022 09:30 - 10:15<nowiki> </nowiki>In Europa ist die Sterbehilfe in gerade einmal vier Ländern erlaubt: in den Niederlanden, Belgien, Luxemburg und seit neuestem auch in Spanien. Die Schweiz hat mit der aktiven Sterbehilfe einen alternativen Weg gewählt. In Frankreich hat die nationale Ethikkommission das Thema im September wieder auf den Tisch gebracht und sich für eine "streng geregelte" Form der Sterbehilfe ausgesprochen. Wie sollten kranke Menschen mit Sterbewillen begleitet werden? Unter welchen Umständen ist die akt ...
|}
[[Datei:screenshot-2018-04-28-16-28-03.png|200px|thumb|left|Beispiel]]

[[Kategorie:Code Snippets]]

HM-CC-RT-DN Funk-Heizkörperthermostat

2021-01-30T17:01:15Z

LordVoodoo: Anmerkung ergänzt, nach dem das Vorgehen bei einem Thermostat mit Firmware 1.4 ebenfalls ein Pairing erfolgreich machte. Zuvor immer unvollständig.

{{Infobox Hardware
|Bild=HM-CC-RT-DN.jpg
|Bildbeschreibung=HM-CC-RT-DN an Heizkörper montiert
|HWProtocol=[[HomeMatic]]
|HWType=[[HomeMatic Type Thermostat|thermostat]]
|HWCategory=[[:Kategorie:Heizungsventile|Heizungsventile]]
|HWComm=868 MHz
|HWChannels=6
|HWVoltage=3 V
|HWPowerConsumption=180 mA
|HWPoweredBy=2x LR6/Mignon/AA
|HWSize=54x65x93 mm (BxHxT)
|HWDeviceFHEM=[[CUL_HM]]

|HWManufacturer=ELV / eQ-3
}}

'''HM-CC-RT-DN''' (häufig einfach '''RT''' genannt) ist ein Funk-''Heizkörperthermostate'' mit integriertem ''Stellantrieb''. Das Thermostat ist seit September 2013 verfügbar und ist der Nachfolger des [[HM-CC-VD Funk-Stellantrieb]]s.

== Vorbemerkungen ==
: ''→ Einstellungen und Informationen, die alle [[HomeMatic]] Thermostate betreffen, sind unter [[HomeMatic Type Thermostat#Temperaturlisten|HomeMatic Type Thermostat]] zu finden.''

Der HM-CC-RT-DN kann die Temperatur selbst messen (im Gegensatz zum [[HM-CC-VD Funk-Stellantrieb|Vorgänger]]) und verfügt über eine Fenster-Offen-Erkennung sowie eine Boost-Funktion. Der HM-CC-RT-DN ''kann'' von einem [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]] gesteuert werden, das ist aber ''optional''.

Das Gerät wird seit Anfang Oktober 2013 von FHEM unterstützt (siehe Diskussion im {{Link2Forum|Topic=14738|LinkText=Forum}}).

Der HM-CC-RT-DN scheint das erste HomeMatic-Device zu sein, bei dem ein Update der Firmware auch vom Anwender durchgeführt werden kann. Ein Firmware-Update erfordert einen [[HM-CFG-USB_USB_Konfigurations-Adapter|USB Konfigurations-Adapter]] und eine auf der eQ-3 Webseite herunterladbare Firmwareupdate-Software. Weitere Details sind unter [[#Firmware Update|Firmware Update]] beschrieben.
{{Hinweis|Die Solltemperaturen eines HM-CC-RT-DN lassen sich ''nicht'' durch einen [[HM-CC-TC Funk-Wandthermostat]] ''steuern''. Dieser kann nur die Ist-Temperatur an den HM-CC-RT-DN weitergeben, damit nicht die am HM-CC-RT-DN direkt gemessene Raumtemperatur zur Regelung verwendet wird.}}
Mit einem HM-CC-RT-DN können maximal (neben der Zentrale/FHEM):
* 7 HomeMatic Heizkörperthermostate
* 8 HomeMatic Tür-Fensterkontakte / Fenster-Drehgriffkontakte
* 8 Tastenpaare von HomeMatic Fernbedienungen bzw. Display-Wandtaster
* 1 HomeMatic Innen-Temperatur-Sensor
[[Peering (HomeMatic)|gepeert]] werden.

{{Hinweis|Wird für Wartungs-/Umbaumaßnahmen das Wasser der Heizung abgelassen bzw. diese neubefüllt, sind alle Stellantriebe manuell dauerhaft auf '''on''' zu setzen: set <HM_Stellantrieb>_Clima controlManu on. Beim Einsatz eines Wandthermostaten ist der Wandthermostat entsprechend einzustellen.}}

== Technische Daten ==
* Betriebsspannung: 2 Stck. 1,5V LR6/Mignon/AA
* Stromaufnahme: 180 mA max.
* Abmessungen (B x H x T): 54 x 65 x 93 mm
* Gewicht: 180 g (ohne Batterien)
* Ventilanschluss: M30 x 1,5 mm

Aktuelle Firmware: 1.5 (2020)

== Betrieb mit FHEM ==
Der Funk-Heizkörperthermostat muss zuerst mit FHEM [[Pairing (HomeMatic)|gepairt]] werden. Stellen Sie sicher, dass FHEM aktuell ist ([[update]] durchführen)

Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden (mittlere Taste mindestens drei Sekunden drücken, um den Vorgang auszulösen). Vereinzelt muss mehrfach gepairt werden, es wurde auch berichtet, dass dabei die Batterie zwichendurch entfernt und neu eingelegt werden muss.

=== Channels (Kanäle) ===
==== Channel (Kanal) 01 _Weather ====

Dieser Kanal dient zur Einspeisung der (gemessenen) ''Ist-Temperatur''. Als Sensor können zum Beispiel das [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP|HM-TC-IT-WM-W-EU Funk-Wandthermostat]] oder ein [[HM-WDS40-TH-I Funk-Temperatur-/Feuchtesensor innen (IT)|HM-WDS40-TH-I Funk-Temperatur-/Feuchtesensor]] dienen.

Ein Temperatur-Sensor ''tempSensor'' kann mit dem ''_Weather''-Kanal wie folgt [[Peering (HomeMatic)|gepeert]] werden:

set <HM-TC-IT-WM-W-EU>_Weather peerChan 0 <HM-CC-RT-DN>_Weather single set

Beispiel:
set EG_Buero_WANDTHERMOSTAT_Weather peerChan 0 EG_Buero_THERMOSTAT_Weather single set

ACHTUNG: Das Wandthermostat sowie das Thermostat Ventil (Beispiel "EG_Buero_WANDTHERMOSTAT" und EG_Buero_THERMOSTAT) werden vorher in FHEM den Status "CMDs_done" anzeigen.
Beim peerChan wird dann bei beiden "CMDs_pending" stehen. Wobei das Wandthermostat sehr schnell wieder auf CMDs_done zurück springt.
Allerdings ist dringend darauf zu achten, dass das Thermostat Ventil auch wieder auf "CMDs_done" wechselt, bevor man den nächsten Befehl absendet.
Das Heizkörper Ventil kann unter Umständen 3 bis 5 min benötigen bis wieder "CMDs_done" steht. Evtl. kann man dies durch die BOOST Taste beschleunigen. Da das Ventil etwa alle 3 min aufwacht, prüft und Daten sendet / empfängt. Sollte man mit dem Befehlen weiter gemacht haben, so kann es zu dem Problem führen, dass einer nicht mehr mit dem Pending aufhört. In dem Fall empfiehlt es sich beide Devices von FHEM abzumelden und auf Werkseinstellung zu resetten.

Zum Test haucht man das Wandthermostat an oder hält es einige Zeit in der Hand bis die Temperatur steigt, nach etwa 3 Minuten sollte man auch am Thermostat Ventil einen Temperaturanstieg sehen.

==== Channel (Kanal) 02 _Climate ====
Dieser Kanal erlaubt es dem [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP|HM-TC-IT-WM-W-EU Funk-Wandthermostat]] den HM-CC-RT-DN zu steuern. Dazu müssen die beiden Geräte gepeert werden:

set <HM-TC-IT-WM-W-EU>_Climate peerChan 0 <HM-CC-RT-DN>_Climate single set

==== Channel (Kanal) 03 _WindowRec ====
Mit diesem Kanal können Fensterkontakte ([[HM-SEC-SC Tür-Fensterkontakt|HM-SEC-SC]] und [[HM-Sec-RHS Funk-Fenster-Drehgriffkontakt|HM-SEC-RHS]]) ihren Fensterstatus (geöffnet / gekippt) an ein oder mehrere Thermostate senden. Die Thermostate stellen anschließend die entsprechende (konfigurierbare) Temperatur ein. Der Temperaturwert kann je Fenster-Sensor unterschiedlich definiert werden. Sind mehrere Fenster gleichzeitig geöffnet, so wird der Thermostat auf die Temperatur des Sensors mit dem geringsten Temperaturwert eingestellt.
Ferner wird empfohlen, bei Einsatz von externen Sensoren, die interne „Fenster auf Erkennung“ zu deaktivieren (weitere Details sind im [[HM-CC-RT-DN Funk-Heizkörperthermostat#Channel .28Kanal.29 04 _Clima|Channel (Kanal) 04 _Clima]] beschrieben).

Der Befehl zum Peeren lautet, wobei <fensterSensor> die FHEM-Kanalbezeichnung für den Fensterkontakt ist und <rt_WindowRec> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates (siehe [https://forum.fhem.de/index.php/topic,41541.msg348044.html#msg348044 diesen Thread]):
set <fensterSensor> peerChan 0 <rt_WindowRec>_WindowRec single

Zum Löschen (=unpeeren) dieser Kopplung:
set <fensterSensor> peerChan 0 <rt_WindowRec>_WindowRec single unset

'''Achtung''': Der Peer-(Lösch-)Vorgang muss erst am Fensterkontakt durch Drücken der Anlerntaste ausgelöst werden, und zwar auch dann, wenn der Fensterkontakt schon vorher mit FHEM gepairt wurde. Dann kann der oben genannte Befehl in FHEM abgesetzt werden. Wichtig scheint auch, dass der Fensterkontakt geschlossen ist wenn man die Anlerntaste drückt.

Der Befehl zur Temperatureinstellung des Heizkörperthermostaten für den Zustand "Fenster offen" lautet, wobei <fensterSensor> die FHEM-Kanalbezeichnung für den Fensterkontakt ist und <rt_WindowRec> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates, sowie <Temp> die einzustellende Temperatur (ganzzahliger Wert):
set <rt_WindowRec>_WindowRec regSet winOpnTemp <Temp> <fensterSensor>

Weitere Hinweise im Forum, siehe {{Link2Forum|Topic=41541|Message=348044|LinkText=FHEM Forum-Beitrag}}

==== Channel (Kanal) 04 _Clima ====
Dieser Kanal dient zum Einstellen der Betriebsparameter, auch [[#Temperaturlisten|Temperaturlisten]] sind hierauf zu übertragen.
Mit dem Modul [[Weekprofile|Wochenplan / Weekprofile]] können die Wochenpläne komfortabel in FHEM erstellt und an die Thermostate übertragen werden.

{{Hinweis|In älteren Versionen von FHEM wurde dieser Kanal durch ''autocreate'' als <code>_ClimRT_tr</code> angelegt. Der Hersteller hat hier offenbar die internen Bezeichnungen geändert, denn beim Vorläufermodell HM-CC-TC mussten Temperaturlisten auf den Kanal ''Climate'' übertragen werden.}}

Die maximale Öffnung des Ventils kann mittels folgendem Befehl eingestellt werden (hier auf 80 %):
set <HM-CC-RT-DN>_Clima regSet valveMaxPos 80

Die interne "Fenster-auf"-Erkennung kann man wie folgt abschalten:
set <HM-CC-RT-DN>_Clima regSet winOpnMode off

==== Channel (Kanal) 05 _ClimaTeam ====
Dieser Kanal erlaubt es mehrere HM-CC-RT-DN zu einem "Team" zu gruppieren. Ein Mitglied des Teams meldet
* Änderungen der Temperatur am Handrad
* Einschalten des Boost-Modus am Taster
an seine "Teamkollegen" weiter. Folgende Änderungen werden '''nicht''' weitergegeben:
* Status der Fensterkontakte
* Temperaturlisten/Wochenplan und daraus folgende Änderungen
* Änderungen durch Fernbedienungen
* Änderungen durch eine HomeMatic-Zentrale

Befehl zum Peeren, wobei ''<HM-CC-RT-DN#1>_ClimaTeam'', ''<HM-CC-RT-DN#2>_ClimaTeam'', ..., ''<HM-CC-RT-DN#8>_ClimaTeam'' die Kanalbezeichnungen der jeweiligen ClimaTeam-Kanäle sind:
set <HM-CC-RT-DN#1>_ClimaTeam peerChan 0 <HM-CC-RT-DN#2>_ClimaTeam single
set <HM-CC-RT-DN#1>_ClimaTeam peerChan 0 <HM-CC-RT-DN#3>_ClimaTeam single
set <HM-CC-RT-DN#2>_ClimaTeam peerChan 0 <HM-CC-RT-DN#3>_ClimaTeam single
...

==== Channel (Kanal) 06 _remote ====
Dieser Kanal kann an eine Fernbedienung gekoppelt werden. Per Tastendruck kann man einen bestimmten Mode und/oder eine bestimmte Temperatur wählen. Dabei kann die Reaktion auf einen langen oder kurzen Tastendruck gesondert eingestellt werden.

Der Befehl zum Peeren lautet, wobei <button> die Kanalbezeichnung der Fernbedienung und <rt-remote> die Kanalbezeichnung des Heizkörperthermostates ist:
set <nowiki><button> peerChan 0 <HM-CC-RT-DN>_remote single</nowiki>

=== Betriebsmodus Auto, Manu, Party (Urlaub) ===

Der HM-CC-RT-DN verfügt über drei Betriebsmodus: Auto, Manu (Manuell) und Party (Urlaub).

==== Modus Auto ====
Das Gerät arbeitet gemäß des gespeicherten Wochenprogramms. Manuelle Änderungen sind möglich, werden aber beim nächsten Schaltpunkt überschrieben.

==== Modus Manu ====
Die Temperatur wird manuell eingestellt, das Wochenprogramm wird nicht abgearbeitet. "Manuell Einstellen" bedeutet entweder am Handrad oder durch Übermittlung eines "set desired temp"-Befehls von FHEM (oder equivalent von einer CCU).

==== Modus Party (Urlaub) ====
Die eingestellte Temperatur gilt bis zu einem gegebenen Endzeitpunkt, anschließend wechselt das Thermostat in den ''Auto''-Modus.

==== Welchen Modus nutzen? ====
Im Umfeld von FHEM sind alle drei Modi einsetzbar. Betrieb in "Auto" hat den Vorteil, dass bei Ausfall der FHEM-Instanz der Thermostat trotzdem noch die eingespeicherten Wochenprogramme abarbeitet. Nachteilig ist aber, dass die Steuerung komplexer wird, weil sowohl die Einstellungen am Thermostat als auch Schaltbefehle von FHEM das Verhalten beeinflussen. Vielfach wird daher im Umfeld von FHEM der Modus "Manu" benutzt, hier wird die Temperatur nur per einzelnem FHEM Schaltbefehl gesteuert, ausgelöst z.b. durch "at" Kommandos, Anwesenheitserkennung oder Bewegungsmelder. Sollte FHEM (oder die Funkverbindung) ausfallen, bleibt der Thermostat allerdings auf der letzten eingestellten Temperatur stehen.

Denkbar ist auch, den Modus "Auto" zu verwenden und dann die Steuerung per FHEM dadurch durchzuführen, dass durch FHEM die Wochenprogramme verändert werden. Dies verbindet zwar die Vorteil der vorgenannten Methoden, ist aber am Aufwendigsten in der Programmierung und erzeugt die höchste Funklast.

Auch der Urlaubsmodus ist einsetzbar, so kann beispielsweise bei Abwesenheit ein niedrigeres Temperaturprofil eingestellt werden, ohne dass eventuell vorhandene Temperaturlisten verändert werden müssen.

set <HM-CC-RT-DN>_Clima controlParty 16 06.12.13 16:30 09.12.13 05:00

Dadurch wird
* von 06.12.2013, 16:30 Uhr
* bis 09.12.2013, 05:00 Uhr
* die gewünschte Raumtemperatur auf 16 °C eingestellt.

{{Hinweis|
* Der Befehl muss auf dem Kanal 4 ''(_Clima)'' erfolgen.
* Es werden nur Uhrzeiten zu jeder vollen oder halben Stunde angenommen (Minuten also 00 oder 30).}}

Mit der folgenden Funktion <code>Urlaub()</code> kann man eine ganze Wohnung (also mehrere RTs) mit nur einem Befehl in den Party-Modus versetzen. Im Beispiel werden zwei Heizkörper ("Treppenhaus" und "Kammer") angesteuert.

Zu beachten sind folgende Dinge:
# Aktuelle Dateien (z.B. <code>10_CUL_HM</code>) verwenden!
# Bei dem ''controlParty''-Befehl ''kein'' Komma zwischen den Parametern.
# Bei der Funktion die Parameterübergabe definieren <code>($$$$$)</code>

'''Aufruf:'''
:<code>{Urlaub ("16", "06.12.13", "16:30", "09.12.13" ,"05:00")}</code>

'''Funktion:'''
<syntaxhighlight lang="perl">
my $Urlaub;
sub
Urlaub($$$$$)
{
my ($temp, $startDate, $startTime, $endDate, $endTime) = @_;

# HM-CC-RT-DN akzeptiert nur Zeiten, die auf Minute 00 oder 30 enden.
# Daher $startTime und $endTime abrunden
$startTime =~ s/\:[0-2].$/:00/;
$startTime =~ s/\:[3-5].$/:30/;
$endTime =~ s/\:[0-2].$/:00/;
$endTime =~ s/\:[3-5].$/:30/;

# controlParty bei jedem HM-CC-RT-DN setzen.
for my $rt (qw(Kammer Treppenhaus)) {
fhem ("set $rt controlParty $temp $startDate $startTime $endDate $endTime");
}
}
</syntaxhighlight>

=== Tastensperre ===

Um zu verhindern, dass der Modus oder die Temperatur per Tasten bzw. Drehrad am HM-CC-RT-DN verändert wird, kann eine Tastensperre gesetzt werden. Dies erfolgt mittels des Befehls:

set <HM-CC-RT-DN> regSet btnLock on

Rückgängig machen geht per:

set <HM-CC-RT-DN> regSet btnLock off

Diese Tastensperre kann man aber am HM-CC-RT-DN durch eine Tastenkombination wieder zurücksetzen. Um sie nur per FHEM rücksetzen zu können, muss

set <HM-CC-RT-DN> regSet globalBtnLock on

eingegeben werden. Rückgängig geht wieder per:

set <HM-CC-RT-DN> regSet globalBtnLock off

Es gibt auch eine Tastensperre die nur das Umschalten des Modus (Auto, Manuell, Urlaub) am Gerät verhindert. Diese wird mit

set <HM-CC-RT-DN> regSet modusBtnLock on

eingeschaltet. Abschalten geht mit:

set <HM-CC-RT-DN> regSet modusBtnLock off

=== Burst-Modus ===
Das ist ein '''Übertragungs'''modus für Nachrichten zwischen HM-Geräten und der Zentrale. Der RT erwacht alle 2,5 Minuten und dann überträgt die Zentrale die Kommandos. Wenn man einen Fensterkontakt oder eine Fernsteuerung nutzt, muss der RT sofort reagieren - dann muss man den Burst ''enablen''. Der RT kann in diesem Fall sofort aufgeweckt werden und bearbeitet die Anforderung (Request). Das kann man auch von der Zentrale aus nutzen (so man möchte). Das ist der '''Vorteil''' des eingeschalteten Burst-Modus.

'''Nachteil:''' Der Burst-Modus benötigt mehr Leistung, das heißt die Batterien müssen häufiger gewechselt werden: Der RT muss den Receiver ständig empfangsbereit halten. Außerdem wachen bei jedem Burst ''alle'' Burst-Empfänger auf – egal an wen die Kommunikation gerichtet war.

'''Burst – wie es funktioniert'''

Schickt ein Sender eine burst Sequenz, wachen alle burst-Empfänger auf und prüfen die Message.
Wenn sie betroffen sind bleiben sie eine Zeit lang wach, ansonsten schlafen sie wieder ein.
Man beachte also, dass Senden eines Burst Energie in ALLEN burst-Empfängern verbraucht, egal ob sie angesprochen sind.

'''HMLAN und burst'''

[[HMLAN]] hat ein Sendebudget das über eine Stunde berechnet wird. Burst belastet dieses Konto deutlich - so können nicht mehr als 100 bursts /h gesendet werden - dann geht HMLAN in overload. Wenn zusätzliche Nachrichten gesendet werden sind es entsprechend weniger.
Es ist nicht vorteilhaft, unnötig bursts zu senden.

'''Burst devices'''

Es gibt Devices, die immer auf burst reagieren und solche bei denen es abgeschaltet werden kann. So reagiert ein Rauchmelder immer auf Burst damit er seine Team-Kollegen hören kann.
Ein TC oder RT hingegen hat diese Funktion abschaltbar. 'Per default ist dies ausgeschaltet um Batterie zu sparen'. Wenn ein VD gesteuert wird ist der TC ja selbst wach. Wird er aber mit einem Fensterkontakt gekoppelt muss es eingeschaltet werden – sonst verpasst er die Nachricht.

'''ConditionalBurst devices'''

Devices mit abschaltbarem Burst wie z.B. der ''HM-CC-RT-DN'' haben ein Register, ''burstRx'', mit dem das burst-Erwachen eingestellt werden kann.
Sendern, die einen burst-Aktor erwecken sollen, muss man sagen, welcher Peer Burst benötigt. Hier kann ggf. das Register ''peerNeedsBurst'' nach dem Peeren gesetzt werden. FHEM versucht dies automatisch beim Peeren zu erledigen. Siehe [[HomeMatic HMInfo|HMinfo]] Befehl ''models'' um herauszufinden, welche Devices welchen Modus unterstützen.

'''Attribut burstAccess'''

Devices, die abschaltbaren burst haben kann man ein attribut burstAccess 1_auto setzen. Es wird beim Abschicken eines Kommandos versucht, das Device mit burst zu wecken. Sollte es nicht funktionieren wird gewartet, bis das Device aufwacht (meist reagieren solche Devices auch auf wakeup). Das Setzen des Attributs ist angenehm – es werden aber ggf. viele bursts gesendet.

'''Kommando burstXmit'''

Mit diesem Kommando, das bei Devices mit conditional-Burst zu Verfügung steht, wird der burst gezielt vom User angestoßen.

Der User schickt erst seine Kommandos an das device. Die Kommandos werden im Command-stack gesammelt.

Dann sendet der User ein set burstXmit.

Es passiert das gleiche wie bei burstAccess.

FHEM versucht mittels burst zu wecken und sendet bei Erfolg die Messages aus dem Kommandostack.

Im Gegensatz zu burstAccess ist burstXmit gezielt einsetzbar und kann sparsamer verwendet werden.

''' FHEM und burst devices'''

FHEM sendet eine burst automatisch mit Kommandos zu Devices, die nur burst unterstützen.

'''So aktiviert man den burst-Betrieb am HM-CC-RT-DN'''

''Burst Mode einschalten'' (der Kanal 4 des Device WZ1 heisst hier WZ1_4)
:<code>set WZ1_4 regSet burstRx on </code>
prüfen mit:
:<code>get WZ1_4 reg burstRx </code>
''Nun in FHEM den Burst mode einschalten (sofern nicht burstXmit verwendet wird)''
:<code>attr WZ1 burstAccess 1_auto</code>

Hinweis: Das Attribut im Device und nicht im Kanal setzen, ansonsten gibt es eine Fehlermeldung.

=== Temperaturlisten ===
Die Temperaturlisten des HM-CC-RT-DN werden identisch mit denen anderer HomeMatic Thermostate verwaltet (siehe [[HomeMatic Type Thermostat#Temperaturlisten|HomeMatic Type Thermostat]]). Beim HM-CC-RT-DN ist der Kanal 4 (_Clima) für die Temperaturlisten zuständig.

==FHEM-Log==
In den folgenden Logs heißt Kanal 4 noch "_ClimRT_tr". Inzwischen würde man dort "_Clima" sehen.

=== Device-Log ===
2013.10.10 20:03:24 3: CUL_HM Unknown device CUL_HM_HM_CC_RT_DN_2212BC, please define it
2013.10.10 20:03:24 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC CUL_HM 2212BC A1A0184002212BC0000001000954B4551303531303031375900FFFF
2013.10.10 20:03:24 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time
2013.10.10 20:03:24 3: CUL_HM pair: CUL_HM_HM_CC_RT_DN_2212BC thermostat, model HM-CC-RT-DN serialNr KEQ0510017
2013.10.10 20:03:24 3: LANCUL pairing (hmPairForSec) not enabled
2013.10.10 20:03:24 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC-%Y.log CUL_HM_HM_CC_RT_DN_2212BC
2013.10.10 20:03:24 3: Device Heizung_Wohnzimmer added to ActionDetector with 000:10 time
2013.10.10 20:03:24 3: CUL_HM pair: Heizung_Wohnzimmer thermostat, model HM-CC-TC serialNr JEQ0044286
2013.10.10 20:03:24 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time
2013.10.10 20:03:24 3: CUL_HM pair: CUL_HM_HM_CC_RT_DN_2212BC thermostat, model HM-CC-RT-DN serialNr KEQ0510017
2013.10.10 20:03:25 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_Weather CUL_HM 2212BC01
2013.10.10 20:03:25 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Weather FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Weather-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Weather
2013.10.10 20:03:25 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Weather FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Weather-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Weather
2013.10.10 20:03:26 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_Climate CUL_HM 2212BC02
2013.10.10 20:03:26 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Climate FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Climate-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Climate
2013.10.10 20:03:26 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Climate FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Climate-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Climate
2013.10.10 20:03:27 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_WindowRec CUL_HM 2212BC03
2013.10.10 20:03:27 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_WindowRec FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_WindowRec-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_WindowRec
2013.10.10 20:03:27 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_WindowRec FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_WindowRec-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_WindowRec
2013.10.10 20:03:28 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr CUL_HM 2212BC04
2013.10.10 20:03:28 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr
2013.10.10 20:03:28 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr
2013.10.10 20:03:29 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam CUL_HM 2212BC05
2013.10.10 20:03:29 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam
2013.10.10 20:03:29 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam
2013.10.10 20:03:30 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_remote CUL_HM 2212BC06
2013.10.10 20:03:30 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_remote FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_remote-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_remote
2013.10.10 20:03:30 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_remote FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_remote-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_remote
2013.10.10 20:03:35 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time
2013.10.10 20:03:40 2: CUL_HM set CUL_HM_HM_CC_RT_DN_2212BC getSerial
2013.10.10 20:03:40 2: CUL_HM set CUL_HM_HM_CC_RT_DN_2212BC getConfig
2013.10.10 20:03:54 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time

=== Event monitor ===
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr motorErr: ok
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr measured-temp: 18.4
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr desired-temp: 18
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr ValvePosition: 3 %
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr mode: manu
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr unknown0: 24
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr T: 18.4 desired: 18 valve: 3 %
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC battery: ok
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC batteryLevel: 3.1 V
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC measured-temp: 18.4
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC desired-temp: 18
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC actuator: 3 %

== Firmware Update ==
Seit 24.10.2014 gibt es für den HM-CC-RT-DN die neue Firmware Version 1.4. Diese kann von der eQ-3 Webseite heruntergeladen werden. Genauere Informationen gibt es unter [[HomeMatic Firmware Update]].

=== HM-CC-RT-DN spezifische Update Informationen ===
Durch gleichzeitiges Drücken der "Auto-/Manu"-Taste und der "Comfort-/Eco"-Taste am HM-CC-RT-DN während man die Batterien wieder einlegt wird der updatemodus gestartet. Während des Updates steht "FUP" im Display. Nach erfolgreichem Update erscheint "Ins" im Display und es muss eine erneute Adaptierfahrt durch Drücken der Boost-Taste ausgelöst werden. Anschließend sollte der HM-CC-RT-DN wieder normal funktionieren. Die eingestellten Parameter und das Pairing mit FHEM gehen beim Update nicht verloren. Sollte das Update fehlschlagen, erscheint "Err" bzw. "CrC" im Display.

Normalerweise sollte dann durch erneutes Starten der Prozedur am PC und HM-CC-RT-DN das ganze erneut durchführbar sein.

Es gibt einige Readings, die nicht durch ein einfaches ''getConfig'' aktualisiert werden, z.B. "battery"(nicht batteryLevel). Um diese Readings zu bekommen, ist ein
:<code>set Device_Channel04 controlMode auto </code>
notwendig. Daraufhin werden die Readings übertragen/aktualisiert.

== Simulation von Fensterkontakten und externen Temperatursensoren ==
{{Randnotiz|RNTyp=r|RNText=Für jeden separat zu steuernden HM-CC-RT-DN kann nur je ein Kanal eines virtuellen Devices als Temperatur- bzw. Fensterkontakt genutzt werden. Insbesondere die virtuellen Kanäle der VCCU eignen sich nicht dazu, mehrere HM-CC-RT-DN unabhängig voneinander anzusteuern! Hat man mehrere unabhängig arbeitende RT's, muß für jeden auch ein '''eigenes virtuelles Gerät''' angelegt werden!

Die folgenden Beispiele sind nicht für Anfänger und Unwissende geeignet! Es gibt zahlreiche Stolpersteine:
# Die HMId für virtuelle Geräte muss einmalig im System sein. Sie muss selbst gewählt werden und es darf '''keine''' vorhandene ID verwendet werden!
# Es kann vorkommen, das beim Anlegen eines virtual Gerätes kein attr IODev gesetzt wird. Das Attribute ist aber notwendig, sonst arbeitet das Gerät nicht! Bitte kontrollieren und gegebenenfalls per Hand setzen.
}}
Grober Ablauf:
* erstelle ein virtuelles Device
* erstelle dazu einen virtuellen Kanal (bzw. mehrere, wenn sowohl ein virtueller Fensterkontakt wie ein virtueller Temperaturkanal benötigt werden).
* peere den Kanal mit dem RT (als Fenster-Kontakt oder als remote, wenn du willst)
* sende ein postEvent / stelle die neue Temperatur im Kanal ein

=== Fensterkontakte ===
''Angelehnt an diese {{Link2Forum|Topic=31078|Message=236245|LinkText=Forenbeitrag}}''
define virtKitchenSensors CUL_HM 221133
Um das Device als virtuelles zu kennzeichnen benötigt man den folgenden Befehl (legt weitere Attribute an):
attr virtKitchenSensors modelForce VIRTUAL

Kanal bzw. Kanäle erstellen:
set virtKitchenSensors virtual 1
oder (für das Anlegen je eines Kanals für einen Fenster- und Temperatur-Kanal):
set virtKitchenSensors virtual 2
Als Zwischenergebnis sehen wir in der Detailansicht des ''virtKitchenSensors'' ein bzw. zwei weitere Devices mit Namen ''virtKitchenSensors_Btn1'' bzw. ''virtKitchenSensors_Btn2''.

Umbenennen des 1. Kanals:
rename virtKitchenSensors_Btn1 virtualKitchenDoor

Danach sollte man das webCmd-Attribut wie folgt vergeben:
attr virtualKitchenDoor webCmd postEvent open:postEvent closed

Anschließend peeren und (wer weniger wie den default-Wert von 12°C einstellen möchte) Temperatur festlegen mit:
set virtualKitchenDoor peerChan 0 <Thermostat_Window_Rec> single set
set <Thermostat_Window_Rec> regSet winOpnTemp 5 virtualKitchenDoor

Ggf noch interne "Fenster-auf" Erkennung abschalten
set <HM-CC-RT-DN>_Clima regSet winOpnMode off

Die virtuelle Tür wird dann entsprechend über ein Notify getriggert.
Einfache Form (nur ein Fensterkontakt im Raum):
define notify_virtualKitchenDoor notify Fensterkontakt_1:(open|closed) set virtualKitchenDoor postEvent $EVENT
Komplexere Form (zwei Fensterkontakte):
<nowiki>define notify_virtualKitchenDoor notify (Fensterkontakt_1|Fensterkontakt_2) {if($EVENT eq "open" and Value("virtualKitchenDoor") eq "set_postEvent closed"){fhem("set virtualKitchenDoor postEvent open")} elsif (Value("virtualKitchenDoor") eq "closed" && Value("Fensterkontakt_2") eq "closed") {fhem("set virtualKitchenDoor postEvent closed")}}</nowiki>
{{Hinweis|Die ''postEvent''-Anweisung wird unmittelbar an die Funkschnittstelle weitergegeben und löst einen ''burst'' aus.}}

=== Temperatursensoren ===
''Angelehnt an diesen {{Link2Forum|Topic=19686|Message=233788|LinkText=Forenbeitrag}}''

1. Virtuelles HomeMatic Device mit eigener HM Id definieren, (s.o.), es kann auch ein weiterer Kanal des oben erstellten Devices genutzt werden

2. Dem Device einen virtuellen Kanal (Default ist ein virtueller Button) hinzufügen, wieder mit <code>set virtKitchenSensors virtual 1</code> bzw. <code>set virtKitchenSensors virtual 2</code> (2 geht auch, wenn bereits ein erster Kanal vorhanden war).

3. Es ist kein virtueller Button sondern ein virtueller Temperatursensor - darum rename:
rename virtKitchenSensors_Btn1 Kitchen_vT_Sensor1
bzw. <code>rename virtKitchenSensors_Btn2 Kitchen_vT_Sensor1</code>

4. Virtuellen Peer Sensor mit dem Weather Channel des RT-DN peeren:
set Kitchen_vT_Sensor1 peerChan 0 <RT_DN>_Weather single

5. Peering kontrollieren (Voraussetzung: Device ''hm'' vom Typ [[HomeMatic HMInfo|HMinfo]] existiert):
:<code>set hm peerXref</code>
Beispiel-Ausgabe:
peerXref done:
x-ref list
wz_Thermostat_Weather => Kitchen_vT_Sensor1
Kitchen_vT_Sensor1 => wz_Thermostat_Weather

6. Gemessene Temperatur vom z.B. 1-Wire DS1820 dem virtuellen HM Sensor übergeben. Z.B. bei jeder Aktualisierung des Messwerts per notify:
define at_Kitchen_vT notify myRealKitchenTempSensor:temperature:.* set Kitchen_vT_Sensor1 virtTemp $EVTPART1

{{Hinweis|Die ''virtTemp''-Anweisung ändert zunächst nur den Wert im virtuellen Kanal. Diese wird zu bestimmten Zeiten als ''broadcast'' gesendet. Diese Zeiten kennt der RT und hält sich kurzfristig empfangsbereit.}}
Sollte es Probleme geben, dass der RT des Öfteren wieder auf seine eigenen Messwerte wechselt, weil die von FHEM errechnete Sendezeit und die vom RT errechnete Empfangszeit zu weit auseinanderliegen, sollte das Attr cyclicMsgOffset im Virtuellen Kanal beachtet werden. Näheres dazu ist ca. ab {{Link2Forum|Topic=45735|Message=572806|LinkText=hier}} im Forum zu finden.

7. Sicherstellen, dass nicht längerfristig veraltete Temperaturdaten berücksichtigt werden:
Aufgrund des oben beschriebenen Verfahrens wird der im virtuellen Kanal vorhandene Wert solange immer wieder gesendet, wie dieser dort steht. Fällt z.B. der echte Sensor oder das Interface nicht nur vorübergehend aus, muß der Wert gelöscht werden. Hier ein Vorschlag für ein ''at'', das alle 15 Minuten alle virtuellen Temperaturwerte löscht, die älter als eine Stunde sind, und damit den Rückfall des jeweiligen RT auf seinen internen Sensor bewirkt:
defmod a_delete_outdated_virtTemps at +*00:15 {\
my @vTemps = devspec2array("TYPE=CUL_HM:FILTER=model=VIRTUAL:FILTER=temperature~.+");;\
for my $vTemp (@vTemps) {\
CommandDeleteReading(undef,"$vTemp temperature" ) if ReadingsAge($vTemp,"temperature",0) > HOURSECONDS ;;\
}\
}
Erhält der RT eine gewisse Zeitlang (ca. 15 Minuten) keinen Wert von seinem (virtuellen) Peer, schaltet er auf den internen Temperatursensor zurück und signalisiert dies durch ein blinkendes Funksymbol im Display.

=== Exkurs: HMCCUDEV ===
{{Hinweis|Das Nachfolgende entspricht dem Stand Janaur 2020. Die HMCCU-Module sind jedoch derzeit in der Weiterentwicklung, so dass es sich ggf. empfiehlt, im Forum nachzufragen.}}
Das Nutzen externer Sensoren scheint mit HMCCU nicht möglich zu sein, siehe {{Link2Forum|Topic=107134|LinkText=Forenbeitrag: RaspberryMatic (HMCCU) und LaCrosse Temperature als "Wandthermostat"}}, die Weitergabe eines externen Türkontakts ist eventuell möglich, siehe {{Link2Forum|Topic=106807|LinkText=Forenbeitrag: HMCCU mit Thermostat HM-CC-RT-DN und ZWave Türsensor}}, an anderer Stelle hat der Modulentwickler ausgeführt, es könnten nur {{Link2Forum|Topic=107501|Message=1015944|LinkText=Homematic Geräte}} als Sensoren verwendet werden.

== Auflistung und Beschreibung der Readings ==

Einige der Readings können via "regSet" parametriert werden.
Wobei der Registername etwas anders geschrieben wird als der Reading Name (ohne R-).

set <name> regSet <register> <value>
Beispiel für Reading R-winOpnPeriod erhöhen auf 60 Minuten:
set EG_Buero_THERMOSTAT_Clima regSet winOpnPeriod 60

Eine vollständige Liste erhält man auch, wenn man einen Falschen Register Namen angibt.
supported register are backOnTime boostPeriod boostPos btnLock btnNoBckLight burstRx cyclicInfoMsg cyclicInfoMsgDis dayTemp daylightSaveTime decalcTime decalcWeekday globalBtnLock localResDis lowBatLimitRT modePrioManu modePrioParty modusBtnLock nightTemp noMinMax4Manu pairCentral regAdaptive reguExtI reguExtP reguExtPstart reguIntI reguIntP reguIntPstart showInfo showWeekday sign tempMax tempMin tempOffset valveErrPos valveMaxPos valveOffsetRt winOpnBoost winOpnDetFall winOpnMode winOpnPeriod winOpnTempI

<table cellspacing="0" border="0">
<tr>
<td style="border-top: 2px solid #ffffff; border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#A6A6A6">Reading</td>
<td style="border-top: 2px solid #ffffff" align="left" valign="middle" bgcolor="#A6A6A6">Beispielwert</td>
<td style="border-top: 2px solid #ffffff" align="left" valign="middle" bgcolor="#A6A6A6">Mögliche Werte</td>
<td style="border-top: 2px solid #ffffff; border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#A6A6A6">Beschreibung</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#111111">CommandAccepted</td>
<td align="left" valign="middle" bgcolor="#111111">yes</td>
<td align="left" valign="middle" bgcolor="#111111">yes; no</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">Letztes Kommando akzeptiert (yes/ No)</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">R-boostPeriod</td>
<td align="left" valign="middle" bgcolor="#333333">5 min</td>
<td align="left" valign="middle" bgcolor="#333333">1 min bis x min</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">Zeit wie lange das Ventil im Boost Modus sein soll.</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#111111">R-boostPos</td>
<td align="left" valign="middle" bgcolor="#111111" sdval="0.8" sdnum="1033;0;0%">80%</td>
<td align="left" valign="middle" bgcolor="#111111" sdnum="1033;0;0%">0 bis 100</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">Ventilposition die im Boost Modus gesetzt wird.</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">R-btnNoBckLight</td>
<td align="left" valign="middle" bgcolor="#333333">off</td>
<td align="left" valign="middle" bgcolor="#333333">on; off</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">???</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="35" align="left" valign="middle" bgcolor="#111111">R-dayTemp</td>
<td align="left" valign="middle" bgcolor="#111111">21 C</td>
<td align="left" valign="middle" bgcolor="#111111">Siehe R-tempMin bis R-tempMax</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">Solltemperatur die gesetzt werden soll, wenn das Sonnensymbol am Thermostat gedrückt wird. Ebenso wird bei dieser Solltemperatur das Sonnensymbol im Display angezeigt.</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">R-daylightSaveTime</td>
<td align="left" valign="middle" bgcolor="#333333">on</td>
<td align="left" valign="middle" bgcolor="#333333">on; off</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">???</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#111111">R-decalcTime</td>
<td align="left" valign="middle" bgcolor="#111111" sdval="0.458333333333333" sdnum="1033;1033;H:MM">11:00</td>
<td align="left" valign="middle" bgcolor="#111111" sdnum="1033;1033;H:MM">00:00 bis 23:59</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">Uhrzeit wann die Entkalkungsfahrt durchgeführt werden soll. </td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">R-decalcWeekday</td>
<td align="left" valign="middle" bgcolor="#333333">Sat</td>
<td align="left" valign="middle" bgcolor="#333333">Mon; Tue; Wed; Thu; Fri; Sat; Sun</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">Tag an dem die Entkalkungsfahrt durchgeführt werden soll.</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#111111">R-modePrioManu</td>
<td align="left" valign="middle" bgcolor="#111111">all</td>
<td align="left" valign="middle" bgcolor="#111111">all; ???</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">???</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">R-modePrioParty</td>
<td align="left" valign="middle" bgcolor="#333333">all</td>
<td align="left" valign="middle" bgcolor="#333333">all; ???</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">???</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="35" align="left" valign="middle" bgcolor="#111111">R-nightTemp</td>
<td align="left" valign="middle" bgcolor="#111111">17 C</td>
<td align="left" valign="middle" bgcolor="#111111">Siehe R-tempMin bis R-tempMax</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">Solltemperatur die gesetzt werden soll, wenn das Mondsymbol am Thermostat gedrückt wird. Ebenso wird bei dieser Solltemperatur das Mondsymbol im Display angezeigt.</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">R-noMinMax4Manu</td>
<td align="left" valign="middle" bgcolor="#333333">off</td>
<td align="left" valign="middle" bgcolor="#333333">on; off</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">???</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#111111">R-regAdaptive</td>
<td align="left" valign="middle" bgcolor="#111111">on</td>
<td align="left" valign="middle" bgcolor="#111111">on; off</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">???</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">R-reguExtI</td>
<td align="left" valign="middle" bgcolor="#333333" sdval="15" sdnum="1033;">15</td>
<td align="left" valign="middle" bgcolor="#333333">???</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">???</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#111111">R-reguExtP</td>
<td align="left" valign="middle" bgcolor="#111111" sdval="30" sdnum="1033;">30</td>
<td align="left" valign="middle" bgcolor="#111111">???</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">???</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">R-reguExtPstart</td>
<td align="left" valign="middle" bgcolor="#333333" sdval="30" sdnum="1033;">30</td>
<td align="left" valign="middle" bgcolor="#333333">???</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">???</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#111111">R-reguIntI</td>
<td align="left" valign="middle" bgcolor="#111111" sdval="18" sdnum="1033;">18</td>
<td align="left" valign="middle" bgcolor="#111111">???</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">???</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">R-reguIntP</td>
<td align="left" valign="middle" bgcolor="#333333" sdval="33" sdnum="1033;">33</td>
<td align="left" valign="middle" bgcolor="#333333">???</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">???</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#111111">R-reguIntPstart</td>
<td align="left" valign="middle" bgcolor="#111111" sdval="44" sdnum="1033;">44</td>
<td align="left" valign="middle" bgcolor="#111111">???</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">???</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">R-showInfo</td>
<td align="left" valign="middle" bgcolor="#333333">time</td>
<td align="left" valign="middle" bgcolor="#333333">date; time</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">Zeige Datum oder Uhrzeit im Display an</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#111111">R-showWeekday</td>
<td align="left" valign="middle" bgcolor="#111111">off</td>
<td align="left" valign="middle" bgcolor="#111111">on; off</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">Zeige den Wochentag im Display an</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">R-sign</td>
<td align="left" valign="middle" bgcolor="#333333">off</td>
<td align="left" valign="middle" bgcolor="#333333">on; off</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">???</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#111111">R-tempMax</td>
<td align="left" valign="middle" bgcolor="#111111">30.5 C</td>
<td align="left" valign="middle" bgcolor="#111111">???</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">Größte einstellbare Temperatur</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">R-tempMin</td>
<td align="left" valign="middle" bgcolor="#333333">4.5 C</td>
<td align="left" valign="middle" bgcolor="#333333">???</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">Kleinste einstellbare Temperatur</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#111111">R-tempOffset</td>
<td align="left" valign="middle" bgcolor="#111111">0.0K</td>
<td align="left" valign="middle" bgcolor="#111111">0.0 bis ???</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">Temperaturabweichung gemessene Temperatur vs. realer Temperatur in Grad Kelvin. Angabe in 0.5-Schritten ohne Einheitenzeichen, z.B. 0.5 oder -1.0</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">R-valveErrPos</td>
<td align="left" valign="middle" bgcolor="#333333" sdval="0.15" sdnum="1033;0;0%">15%</td>
<td align="left" valign="middle" bgcolor="#333333" sdnum="1033;0;0%">???</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">???</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#111111">R-valveMaxPos</td>
<td align="left" valign="middle" bgcolor="#111111" sdval="1" sdnum="1033;0;0%">100%</td>
<td align="left" valign="middle" bgcolor="#111111" sdnum="1033;0;0%">0 bis 100</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">Maximale Ventilstellung die das Thermostat fahren darf.</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">R-valveOffsetRt</td>
<td align="left" valign="middle" bgcolor="#333333" sdval="0" sdnum="1033;0;0%">0%</td>
<td align="left" valign="middle" bgcolor="#333333" sdnum="1033;0;0%">0 Bis 100</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">???</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="52" align="left" valign="middle" bgcolor="#111111">R-winOpnBoost</td>
<td align="left" valign="middle" bgcolor="#111111">off</td>
<td align="left" valign="middle" bgcolor="#111111">on; off</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">Startet nach dem Fensterschließen die Boostfunktion um unabhängig von der Raumtemperatur den Heizkörper eine Zeit x aufzuheizen. (Siehe R-boostPeriod & R-boostPos)</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">R-winOpnDetFall</td>
<td align="left" valign="middle" bgcolor="#333333">1.4 K</td>
<td align="left" valign="middle" bgcolor="#333333">0.5 bis 2.5</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">Temperatur Sturz zwischen zwei Messungen, die als Fenster offen erkannt werden.</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="35" align="left" valign="middle" bgcolor="#111111">R-winOpnMode</td>
<td align="left" valign="middle" bgcolor="#111111">off</td>
<td align="left" valign="middle" bgcolor="#111111">on; off</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">Thermostat soll anhand eines schnellen Temperaturabfalls erkennen, dass das Fenster geöffnet ist.</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">R-winOpnPeriod</td>
<td align="left" valign="middle" bgcolor="#333333">15 min</td>
<td align="left" valign="middle" bgcolor="#333333">1 bis 60 Minuten</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">Dauer bis das Signal Fenster offen wieder entfernt wird.</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#111111">R-winOpnTemp</td>
<td align="left" valign="middle" bgcolor="#111111">12 C</td>
<td align="left" valign="middle" bgcolor="#111111">Siehe R-tempMin bis R-tempMax</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">Temperatur die eingestellt werden soll, wenn das Fenster als offen erkannt wird.</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="104" align="left" valign="middle" bgcolor="#333333">R_0_tempListSat</td>
<td align="left" valign="middle" bgcolor="#333333">07:00 20.0 22:30 22.0 24:00 20.0</td>
<td align="left" valign="middle" bgcolor="#333333">incomplete = Daten werden mit Thermostat abgeglichen Zeit/Temperaturangaben siehe Beispiel</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">Tages Solltemperaturen abhängig von der Uhrzeit. - Der Beginn um 00:00 ist nicht einzutragen. - Es sind immer Paare einzutragen (Uhrzeit Temperatur). - Der letzte Eintrag muss an jedem Tag 24:00 sein. - Uhrzeiten sind auf halbe Stunden beschränkt. Einträge 08:00 und 08:30 sind gültig. 08:20 ist ungültig.</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#111111">R_1_tempListSun</td>
<td align="left" valign="middle" bgcolor="#111111">07:00 20.0 22:00 22.0 24:00 20.0</td>
<td align="left" valign="middle" bgcolor="#111111">Siehe R_0_tempListSat</td>
<td align="left" valign="middle" bgcolor="#111111">Siehe R_0_tempListSat</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">R_2_tempListMon</td>
<td align="left" valign="middle" bgcolor="#333333">04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">Siehe R_0_tempListSat</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">Siehe R_0_tempListSat</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#111111">R_3_tempListTue</td>
<td align="left" valign="middle" bgcolor="#111111">04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0</td>
<td align="left" valign="middle" bgcolor="#111111">Siehe R_0_tempListSat</td>
<td align="left" valign="middle" bgcolor="#111111">Siehe R_0_tempListSat</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">R_4_tempListWed</td>
<td align="left" valign="middle" bgcolor="#333333">04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">Siehe R_0_tempListSat</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">Siehe R_0_tempListSat</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#111111">R_5_tempListThu</td>
<td align="left" valign="middle" bgcolor="#111111">04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0</td>
<td align="left" valign="middle" bgcolor="#111111">Siehe R_0_tempListSat</td>
<td align="left" valign="middle" bgcolor="#111111">Siehe R_0_tempListSat</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">R_6_tempListFri</td>
<td align="left" valign="middle" bgcolor="#333333">04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">Siehe R_0_tempListSat</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">Siehe R_0_tempListSat</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="35" align="left" valign="middle" bgcolor="#111111">R_tempList_State</td>
<td align="left" valign="middle" bgcolor="#111111">verified</td>
<td align="left" valign="middle" bgcolor="#111111">incomplete = Daten werden mit Thermostat abgeglichen verified = Daten sind mit Thermostat abgeglichen</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">Aktualisierungsstatus der Wochen Temperatur Einstellungen</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">ValvePosition</td>
<td align="left" valign="middle" bgcolor="#333333" sdval="36" sdnum="1033;">36</td>
<td align="left" valign="middle" bgcolor="#333333">0 bis 100</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">aktuelle Ventilstellung</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="35" align="left" valign="middle" bgcolor="#111111">boostTime</td>
<td align="left" valign="middle" bgcolor="#111111">-</td>
<td align="left" valign="middle" bgcolor="#111111">- 1 min bis n min</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">Zeit wie lange der Boostmodus noch aktiv ist.</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="121" align="left" valign="middle" bgcolor="#333333">controlMode</td>
<td align="left" valign="middle" bgcolor="#333333">auto</td>
<td align="left" valign="middle" bgcolor="#333333">auto = Thermostat wird nach der TempListe gesteuert manual = Die eingestellte Temperatur am Thermostat wird nicht verändert, außer bei Verwendung von WinOpn; boost = Thermostat wird in den Boost Modus gesetzt. Siehe R-boostPeriod/Pos day = Thermostat wird auf die eingestellte Tag Temperatur gesetzt (R-dayTemp). night = Thermostat wird auf die eingestellte Nacht Temperatur gesetzt (R-nightTemp).</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">Setzt das Thermostat in einen bestimmten Modus</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#111111">desired-temp</td>
<td align="left" valign="middle" bgcolor="#111111" sdval="22" sdnum="1033;">22</td>
<td align="left" valign="middle" bgcolor="#111111">N/A</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">Solltemperatur</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">measured-temp</td>
<td align="left" valign="middle" bgcolor="#333333" sdval="23.2" sdnum="1033;">23.2</td>
<td align="left" valign="middle" bgcolor="#333333">N/A</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">Isttemperatur</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#111111">partyEnd</td>
<td align="left" valign="middle" bgcolor="#111111">-</td>
<td align="left" valign="middle" bgcolor="#111111">???</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">Ende Datum/Zeit in dem die Party Temperatur (partyTemp) gesetzt sein soll.</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">partyStart</td>
<td align="left" valign="middle" bgcolor="#333333">-</td>
<td align="left" valign="middle" bgcolor="#333333">???</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333">Start Datum/Zeit in dem die Party Temperatur (partyTemp) gesetzt sein soll.</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#111111">partyTemp</td>
<td align="left" valign="middle" bgcolor="#111111">-</td>
<td align="left" valign="middle" bgcolor="#111111">-; 20.0</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">Party Temperatur</td>
</tr>
<tr>
<td style="border-left: 2px solid #ffffff" height="21" align="left" valign="middle" bgcolor="#333333">recentStateType</td>
<td align="left" valign="middle" bgcolor="#333333">ack</td>
<td align="left" valign="middle" bgcolor="#333333">???</td>
<td style="border-right: 2px solid #ffffff" align="left" valign="middle" bgcolor="#333333" sdnum="1033;1033;M/D/YYYY H:MM">???</td>
</tr>
<tr>
<td style="border-bottom: 2px solid #ffffff; border-left: 2px solid #ffffff" height="23" align="left" valign="middle" bgcolor="#111111">state</td>
<td style="border-bottom: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">T: 23.2 desired: 22.0 valve: 36</td>
<td style="border-bottom: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111"> </td>
<td style="border-bottom: 2px solid #ffffff" align="left" valign="middle" bgcolor="#111111">Aktuelle Statusinformation</td>
</tr>
</table>

== Bekannte Probleme ==
=== TempList: Bad format ... ===
Wenn Sie beim Setzen einer Temperaturliste nach dem o.a. Schema ("SetTempList...") die Meldung

Bad format, use HH:MM TEMP ......

erhalten, sollten Sie zunächst ein [[update]] von FHEM durchführen.

=== Der Thermostat heizt über die Solltemperatur hinaus ===
In der Regel ist das ein ganz normales Verhalten, wenn der Thermostat nicht mit einem externen Temperaturfühler oder einem Wandthermostat gepeert ist. In dem Fall muss sich der Thermostat auf den eingebauten Temperatursensor verlassen, der sehr nahe an der Heizung selbst sitzt. Dadurch ist die gemessene Temperatur höher, als sie z.B. in der Raummitte wäre. Der Hersteller hat hier einen mehr oder weniger intelligenten Algorithmus eingebaut, um diesen Effekt zu kompensieren. Das sieht dann so aus, als ob der Thermostat nicht richtig regelt.
Dieses Verhalten kann man im Prinzip nur verhindern, indem man einen externen Temperatursensor oder einen Wandthermostat peert. Wie das geht ist hier beschrieben: [[#Channel (Kanal) 01 _Weather]]. Normalerweise regelt der Thermostat dann genau auf die Solltemperatur.
Ansonsten sollte man sich auch fragen, ob das gezeigte Verhalten vielleicht doch gut genug ist. Dazu platziert man irgendein Thermometer möglichst in der Mitte des Raums und beobachtet den Temperaturverlauf eine Weile. Wenn man dann noch eine Abweichung feststellt, kann es sinnvoll sein, diese mittels des Registers R-tempOffset zu beheben.

=== Pairen bei Firmware 1.5 ===
Das nachfolgende Vorgehen bietet sich ab Firmware 1.5 ab, da sonst das pairen nicht erfolgreich sein wird:
# Pairing wie angegeben
# '''''GetConfig''''' erst, nachdem die Zeit von '''''hmPairForSec''''' abgelaufen ist
# burstXmit
# set <gerät> reset
# set <gerät> unpair
# harten HW Reset nach Handbuch am Gerät
# erneut pairen
Der Tipp stammt aus [https://de.elv.com/forum/neue-firmware-1.5-an-fhem-uart-modul-hm-mod-rpi-pcb-mit-firmware-1.4.1-7481 diesem Beitrag] im ELV Forum. Dies Vorgang konnte teilweise auch für Geräte mit Firmware 1.4 bestätigt werden.

== Links ==
* [http://www.eq-3.de/produkt-detail-aktoren/items/homematic-funk-heizkoerperthermostat.html Produktinfo bei EQ-3]
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-CC-RT-DN_UM_GE_eQ-3_web.pdf Bedienungsanleitung bei EQ-3 (PDF)]
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/pdb/Funk-Heizkoerperthermostat_105155_Produktdatenblatt_V2.3.pdf Datenblatt bei EQ-3 (PDF)]
* [http://www.eq-3.de/Downloads/eq3/downloads/Ventilkompatibilitaeten.pdf Ventil-Kompatibilitätsliste bei EQ-3 (zur Zeit nicht verfügbar)]
* {{Link2Forum|Topic=14738|LinkText=Forenthema zum Thermostat}}
* {{Link2Forum|Topic=64446|LinkText=Reparatur einer durch mechanischen Stoß von außen abgerissenen Lichtschranke}}

[[Kategorie:HomeMatic Components]]
[[Kategorie:Heizungsventile]]
[[Kategorie:868MHz]]

Modul YAAHM

2018-08-29T19:30:54Z

LordVoodoo: /* Einstellung des Tages-Profils */

{{
Infobox Modul
|ModPurpose=Das Modul stellt eine komfortable Oberfläche bereit, um per Webinterface die zyklische Ausführung von Kommandos - mit Tages- und Wochenprofil - zu konfigurieren
|ModType=h

|ModCmdRef=YAAHM
|ModForumArea=Unterstuetzende Dienste
|ModTechName=95_YAAHM.pm
|ModOwner=Prof. Dr. Peter A. Henning
}}
Diese Seite beschreibt die Konfiguration und Verwendung des Moduls 95_YAAHM.pm.

=Allgemeines=
Das Modul ''95_YAAHM.pm'' stellt eine komfortable Oberfläche bereit, um per Webinterface die zyklische Ausführung von Kommandos - mit Tages- und Wochenprofil - zu konfigurieren. Der Titel '''YAAHM''' ist das Akronym für ''Yet Another Auto Home Module'', denn es gibt ja schon verschiedene Module, die den Zeitablauf in einem SmartHome vereinfachen sollen. Warum also noch Eines ?

Ganz einfach: Die Philosophie von YAAHM ist die einfache Bedienbarkeit im Frontend, mit Eingabefeldern und Visualisierungselementen - statt dabei Unmengen von Attributen zu setzen. Dafür gilt es zunächst, verschiedene Begriffe zu verstehen.

== Tages-Typ ==
Ohne weitere Angaben unterscheidet YAAHM die beiden Tagestypen Wochenende und Werktag.
Durch das Setzen der Attribute ''vacationDevices'' und ''holidayDevices'', die jeweils eine komma-separierte Liste aus holiday-Devices oder Calendar-Devices sein können, holt YAAHM sich jeden Morgen kurz nach Mitternacht noch weitere Informationen. Nämlich, ob es sich um einen Ferientag (vacation) oder einen Feiertag (holiday) handelt. Der letztendliche Tagestyp wird dann in einer Priorisierung festgelegt: Feiertag hat die höchste Priorität, gefolgt von Wochenende, Ferientag und Werktag.

Für jedes Wochen-Profil kann man angeben, ob es auch an einem Ferientag (=Fer) und an einem Feiertag (=Fei) gültig sein soll, siehe [[#Einstellung der Wochen-Profile | Wochen-Profile]].

== Tages-Profil ==
Das Tagesprofil besteht aus einer Kette von Ereignissen (Events), die an jedem Tag zeitgesteuert ablaufen. Welcher Event als letztes durchgeführt wurde, steht im Reading '''housetime''', der vorhergehende Event im Reading ''prev_housetime'' und der vom gegenwärtigen Zeitpunkt aus nächste Event im Reading ''next_housetime''. Für jedes Event kann eine Liste von FHEM-Kommandos angegeben werden, die dann ausgeführt werden.

Das Modul ermöglicht mit dem Attribut ''timeHelper'' die Angabe einer Perl-Hilfsfunktion, die zu jedem Event mit den entsprechenden Argumenten aufgerufen wird, siehe [[#Attribute | Attribute]]

Die vordefinierten Events sind nachfolgend aufgeführt:
*''Nach Mitternacht'' und ''Vor Mitternacht'' (aftermidnight, beforemidnight) sind Events, die mit einem Offset an jedem Tag nach bzw. vor Mitternacht ausgeführt werden.
*''Sonnenaufgang'', ''Vor Sonnenaufgang'' und ''Nach Sonnenaufgang'' (sunrise, beforesunrise, aftersunrise) sind Events, die an jedem Tag zu Sonnenaufgang bzw. mit einem Offset davor und danach ausgeführt werden. Der Zeitpunkt des Sonnenaufgangs wird aus dem Modul 95_Astro.pm berechnet.
*''Sonnenuntergang'', ''Vor Sonnenuntergang'' und ''Nach Sonnenuntergang'' (sunset, beforesunset, aftersunset) sind Events, die an jedem Tag zu Sonnenuntergang bzw. mit einem Offset davor und danach ausgeführt werden. Der Zeitpunkt des Sonnenuntergangs wird aus dem Modul 95_Astro.pm berechnet.
*''Morgen'', ''Mittag'', ''Nachmittag'', ''Abend'' und ''Nacht'' (morning, noon, afternoon, evening, night) sind Events, die zu einer einstellbaren Zeit an jedem Tag ausgeführt werden. Das Reading '''housephase''' nimmt zwischen ''Morgen'' und ''Nacht'' den Wert ''Tageszeit'' an, sonst den Wert ''Nachtzeit''.
*''Wecken'' und ''Schlafen'' (wakeup, sleep) sind Events, die durch die beiden Standard-Wochenprofile gleichen Namens ausgelöst werden. Die entsprechenden Zeiten können von Tag zu Tag beliebig variieren.

== Wochen-Profile ==
Jedes Wochenprofil besteht aus einem Ereignis (Event) je Wochentag. Für dieses Event kann eine Liste von FHEM-Kommandos angegeben werden, die dann ausgeführt werden. Zwei Standard-Wochenprofile ''Wecken'' und ''Schlafen'' sind vordefiniert und können nicht gelöscht werden. Eine beliebige Anzahl weiterer Wochenprofile kann angelegt und wieder gelöscht werden.

Das Modul ermöglicht mit dem Attribut ''timeHelper'' die Angabe einer Perl-Hilfsfunktion, die für die beiden ersten (Standard-)Wochenprofile bei Eintritt des Events mit den entsprechenden Argumenten aufgerufen wird, siehe [[#Attribute | Attribute]].

Für jedes Wochenprofil kann eine '''manuelle Auslösezeit''' eingegeben werden. Ist diese später als der gegenwärtige Zeitpunkt, wird sie für den aktuellen Tag verwendet. Ist diese früher als der gegenwärtige Zeitpunkt, wird sie erst am nächsten Tag als Ausnahmezeit verwendet. Lautet die manuelle Auslösezeit 'off', wird der heutige Auslösezeitpunkt abgeschaltet, wenn er noch nicht verstrichen ist - sonst der morgige Auslösezeitpunkt.

== (Nutzungs-)Modus ==
Der '''housemode''' (bzw. (Nutzungs-)Modus) besagt, dass sich das SmartHome in einem der vier Modi ''Normal'', ''Party'', ''Abwesenheit'' oder ''Nicht Stören'' befindet. Dabei bedeutet:
*''Normal'' (Readingswert normal) = normale Tages- und Wochen-Profile werden angewandt, keine speziellen Anordnungen.
*''Party'' (Readingswert party) = kann in Hilfsfunktionen verwendet werden, um spezielle Anordnungen betreffend die Sicherheit und den Übergang in den Nachtzustand zu realisieren. Das Modul selbst sorgt dafür, dass im Party-Modus das SmartHome nicht in einen gesicherten Zustand versetzt werden kann.
*''Abwesenheit'' (Readingswert absence) = kann in Hilfsfunktionen verwendet werden, um spezielle Anordnungen zu realisieren.
*''Nicht Stören'' (Readingswert donotdisturb) = kann in Hilfsfunktionen verwendet werden, um spezielle Anordnungen zu realisieren.
Die Festsetzung des Modus bleibt bestehen, bis eine erneute manuelle Änderung durchgeführt wird. Ausnahme: Wenn das Attribut ''modeAuto'' gesetzt wird, kann sich der Modus auch bei bestimmten Events ändern.
Für jedes Wochen-Profil kann man angeben, ob es auch im Party-Modus (=Par) und bei Abwesenheit (=Abw) gültig sein soll, siehe [[#Einstellung der Wochen-Profile | Wochen-Profile]].

Das Modul ermöglicht mit dem Attribut ''modeHelper'' die Angabe einer Perl-Hilfsfunktion, die zu jedem Wechsel des Modus mit den entsprechenden Argumenten aufgerufen wird, siehe [[#Attribute | Attribute]]

== (Sicherheits-)Zustand ==
Der '''housestate''' (bzw. (Sicherheits-)Zustand) besagt, dass sich das SmartHome in einem der vier Zustände ''Nicht gesichert'', ''Gesichert'', ''Geschützt'' oder ''Überwacht'' befindet. Die Festsetzung des Zustands bleibt bestehen, bis eine erneute manuelle Änderung durchgeführt wird. Ausnahme: Wenn das Attribut ''stateAuto'' gesetzt wird, kann sich der Zustand auch bei bestimmten Events ändern. Dabei bedeutet (beispielsweise !)
**''Nicht gesichert'' (Readingswert unsecured) = Türen sind unverschlossen, Fenster dürfen geöffnet sein
**''Gesichert'' (Readingswert secured) = Türen sind verschlossen, Fenster dürfen nur in Ausnahmefällen geöffnet sein
**''Geschützt'' (Readingswert protected) = Türen sind verschlossen, Fenster dürfen nur in Ausnahmefällen geöffnet sein, die Alarmanlage ist scharf geschaltet
**''Überwacht'' (Readingswert guarded) = Türen sind verschlossen, Fenster dürfen nur in Ausnahmefällen geöffnet sein, die Alarmanlage ist scharf geschaltet, in regelmäßigen Abständen wird der Zustand des Hauses überprüft und bei Veränderungen irgendwie gemeldet. Vielleicht läuft auch noch eine Anwesenheitssimulation

Das Modul ermöglicht mit dem Attribut ''stateHelper'' die Angabe einer Perl-Hilfsfunktion, die zu jedem Wechsel des Zustands mit den entsprechenden Argumenten aufgerufen wird, siehe [[#Attribute | Attribute]]. Welche FHEM-Devices dabei geschaltet werden, muss also in dieser externen Hilfsfunktion angegeben werden.

Allerdings lässt sich in YAAHM der Schaltzustand dieser Devices periodisch überwachen. Sie werden dazu in das Attribut 'stateDevices' eingetragen, siehe unten.

=YAAHM-Device=
==Installation==
YAAHM ist Bestandteil der FHEM-Distribution. Die Installation erfolgt über den Standard-Updatemechanisnmus. Zu YAAHM gehören das Modul 95_YAAHM.pm und die Datei yaahm.js in /fhem/www/pgm2
==Definition==
Das YAAHM-Device - hier mit dem Namen ''YYY'' versehen - selbst wird über
define YYY YAAHM
definiert. Diese Definition legt einen versteckten Raum "ProfileRoom" an, welcher über einen Weblink im oberen Menü des Webinterfaces erreichbar ist.
*Der Name dieses Raumes kann durch das Attribut ''hiddenRoom'' geändert werden.
*Dieses Modul verwendet das globale Attribut ''language'' zur Bestimmung der Anzeigedaten (Standard: EN=english). Für deutsche Ausgabedaten muss in FHEM das Attribut
attr global language DE
gesetzt werden. Für dieses Wiki werden die deutschen Ausgabedaten verwendet.

Beim Anklicken des Begriffes ''Profile'' (eben der genannte Weblink) im oberen Menü des Webinterfaces wird dieser versteckte Raum angezeigt. Er enthält an erster Stelle das YAAHM-Device. Für die Konfiguration dieses Devices siehe den nächsten Abschnitt, für die Bedienung siehe den Abschnitt [Bedienung].

==Set-Befehle ==
Das YAAHM-Device kennt die folgenden Set-Befehle (''YYY'' ist duch den tatsächlichen Device-Namen zu ersetzen):
set YYY time (after|before)midnight | [before|after]sunrise | [before|after]sunset | morning | noon | afternoon | evening | night | wakeup | sleep
Erzeugt manuell den entsprechenden Event.
set YYY manualnext <timernumber> <time>
set YYY manualnext <timername> <time>
Setzt die manuelle Auslösezeit für das Wochen-Profil (Timer genannt), das durch die Angabe einer fortlaufenden Nummerierung (beginnend bei 0) oder seinen Namen identifiziert wird. Das nicht löschbare Standard-Wochen-Profil ''Wecken'' hat die Timer-Nummer 0, das nicht löschbare Standard-Wochen-Profil ''Schlafen'' hat die Timer-Nummer 1.
set YYY mode normal | party | absence | donotdisturb
Setzt den (Nutzungs-)Modus des SmartHome
set YYY state unsecured | secured | protected | guarded
Setzt den (Sicherheits-)Zustand des SmartHome
set YYY checkstate (0|5|10)
Führe die Überprüfung, ob alle stateDevices (siehe Attribute) für diesen (Sicherheits-)Zustand den richtigen Wert haben, manuell sofort oder mit 5 bzw. 10 Sekunden Verzögerung aus.
set YYY correctstate
Führe für jedes stateDevice (siehe Attribute), das nicht den richtigen Wert hat, das FHEM-Kommando ''set <stateDevice> <sollzustand>'' aus.
set YYY createWeekly <string>
set YYY deleteWeekly <string>
Erzeuge oder entferne ein Wochen-Profil mit dem entsprechenden Namen. Die beiden Standard-Wochen-Profile ''Wecken'' und ''Schlafen'' können nicht gelöscht werden.
set YYY locked |unlocked
Sperre oder entsperre das Überschreiben der Timer, siehe [[#Sperrung | Sperrung]].
set YYY save | restore
Speichere die Daten persistent, oder hole sie aus der betreffenden Datei ''YAAHMFile'' (Achtung für Nutzer der configdb: Das File wird in der Datenbank abgelegt, nicht im Dateisystem).

==Get-Befehle==
Das YAAHM-Device kennt die folgenden Get-Befehle (''YYY'' ist duch den tatsächlichen Device-Namen zu ersetzen):
get YYY next <timernumber>
get YYY next <timername>
get YYY sayNext <timernumber>
get YYY sayNext <timername>
Holt die nächste Auslösezeit für das betreffende Wochen-Profil (Timer genannt). Mit dem Befehl ''next'' erfolgt das in einem Format, das für textuelle Ausgabegeräte geeignet ist, mit dem Befehl ''sayNext'' in einem Format, das für Sprach-Ausgabegeräte geeignet ist. Die Identifikation des Wochen-Profiles (Timer genannt) erfolgt durch die Angabe einer fortlaufenden Nummerierung (beginnend bei 0) oder seinen Namen. Das nicht löschbare Standard-Wochen-Profil ''Wecken'' hat die Timer-Nummer 0, das nicht löschbare Standard-Wochen-Profil ''Schlafen'' hat die Timer-Nummer 1.
get YYY version
Gibt die Versionsnummer des Moduls zurück
get YYY template
Gibt Vorschläge für Helferfunktionen zurück.

==Attribute==
*Wenn das Attribut '''timeHelper''' auf einen Perl-Funktionsnamen gesetzt wird, erfolgt automatisch der Eintrag des Perl-Funktionsnamens in das Aktionsfeld für das Tages-Profil und die Aktionsfelder der beiden ersten (=Standard-)Wochenprofile, verbunden mit dem Argument des entsprechenden Events. Einen entsprechenden Vorschlag für eine solche Helferfunktion kann man sich durch ''get YYY template'' anzeigen lassen.

*Wenn das Attribut '''modeHelper''' auf einen Perl-Funktionsnamen gesetzt wird, erfolgt automatisch die Ausführung dieser Funktion (verbunden mit dem Argument des entsprechenden Events) bei einem Wechsel des (Nutzungs-)Modus. Einen entsprechenden Vorschlag für eine solche Helferfunktion kann man sich durch ''get YYY template'' anzeigen lassen.
*Wenn das Attribut '''modeAuto''' auf 1 gesetzt wird, wechselt der (Nutzungs-)Modus automatisch zu bestimmten Events:
**Die Events ''sleep'' und ''morning'' bewirken, dass der Modus ''Party'' aufgehoben wird und wieder ''Normal'' ist.
**Der Event ''wakeup'' bewirkt, dass der Modus ''Abwesenheit'' aufgehoben wird und wieder ''Normal'' ist.
**Jeder Event bewirkt, dass der Modus ''Nicht Stören'' aufgehoben wird und wieder ''Normal'' ist.

*Wenn das Attribut '''stateHelper''' auf einen Perl-Funktionsnamen gesetzt wird, erfolgt automatisch die Ausführung dieser Funktion (verbunden mit dem Argument des entsprechenden Events) bei einem Wechsel des (Sicherheits-)Zustands. Einen entsprechenden Vorschlag für eine solche Helferfunktion kann man sich durch ''get YYY template'' anzeigen lassen.
*Wenn das Attribut '''stateAuto''' auf 1 gesetzt wird, wechselt der (Sicherheits-)Zustand automatisch zu bestimmten Events:
**Wenn der Modus ''Normal'' ist und der Zustand ''Nicht gesichert'' ist, wird bei Eintritt der Events ''sleep'' oder ''night'' der Zustand auf ''Gesichert'' gesetzt.
**Wenn der Modus ''Party'' durch den Event ''sleep'' verlassen wurde, und der Zustand ''Nicht gesichert'' ist, wird der Zustand auf ''Gesichert'' gesetzt.

*Das Attribut '''stateDevices''' enthält eine kommagetrennte Liste von FHEM-Devices, die jeweils gefolgt werden von den erwarteten ''state''-Readings (getrennt durch ein ":"-Zeichen) für die entsprechenden (Sicherheits-) Zustände, also z.B. für eine Haustür, die in den (Sicherheits-) Zuständen ''Gesichert'', ''Geschützt'' und ''Überwacht'' abgeschlossen sein soll:
HausTuer::locked:locked:locked:locked
**Ob die korrekte Stellung der jeweiligen Devices erreicht wurde, wird periodisch in jeweils '''stateInterval''' Minuten geprüft und in der [[#Zusammenfassung | Zusammenfassung]] angezeigt.
**Für jedes Device, dessen Zustand nicht der Vorgabe entspricht, wird die im Attribut '''stateWarning''' genannte Funktion mit den Argumenten ''Device'', ''Sollzustand'', ''Istzustand'' aufgerufen.

*'''linkname''' ist der Name für den Link im FHEM-Menü. Default: ''Profile''.
*'''hiddenroom''' ist der Name für den versteckten Raum, der das YAAHM-Device enthält. Default: ''ProfileRoom''
*'''lockstate''' ist der Sperrzustand für das Device, siehe [[#Sperrung | Sperrung]]
*Wenn das Attribut '''simulation''' auf 1 gesetzt wird, werden die Kommandos in den Aktionsfeldern nicht ausgeführt, sondern nur eine Log-Meldung geschrieben.

*'''holidayDevices''', '''vacationDevices''' und '''specialDevices''' sind attribute, die jeweils eine kommagetrennte Liste von FHEM-Devices enthalten. Diese dürfen vom Typ holiday oder vom Typ calendar sein.
**holidayDevices enthält die Liste der Feiertage (=höchste Tagespriorität)
**vacationDevices enthält die Liste der Schulferien (=dritthöchste Tagespriorität)
**specialDevices enthält eine Liste von Einzelterminen (z.B. der Müllabfuhr)
*Diese Kalenderdaten werden jeweils kurz nach Mitternacht eingelesen und in der [[#Zusammenfassung | Zusammenfassung]] angezeigt.

=Webinterface=
In diesem Abschnitt wird die Bedienung des Webinterfaces und damit die Konfiguration der Hausautomatik beschrieben. Um sie zu erreichen, klickt man auf den Begriff ''Profile'' im oberen Menü des Webinterfaces.

Das Webinterface teilt sich in zwei Abschnitte: Die Übersicht (oder toptable), bestehend aus den beiden Flächen '''Aktion''' und '''Zusammenfassung''', sowie die Profilbereiche. Die Übersicht lässt sich auch separat als Weblink '''<YAAHM_Device-Name>_shortlink''' in einen beliebigen FHEM-Raum einbinden.
===Aktion===
[[Datei:action_2.png|600px|]]

Im Aktionsfeld werden links der aktuelle Mode (=housemode) und der aktuelle (Sicherheits-) Zustand (housestate) angezeigt. Das rote Kreuz beim Zustand besagt, dass nicht alle in dem Attribut '''stateDevices''' definierten FHEM-Devices im korrekten Zustand für diesen (Sicherheits-) Zustand sind. Im Feld rechts daneben befinden sich Buttons zum Wechsel von Mode und Zustand.

Unten befindet sich für jeden Wochentimer ein Eingabefeld für die 'nächste manuelle Auslösezeit'. Trägt man dort einen Wert ein, der für den heutigen Tag in der Vergangenheit liegt, wird dies als die nächste Auslösezeit am morgigen Tag interpretiert. Liegt der Wert für den heutigen Tag in der Zukunft, wird es als die nächste Auslösezeit am heutigen Tag interpretiert. Die Werte werden im Device gespeichert, sobald man das Feld verlässt.

===Zusammenfassung===

[[Datei:summary_2.png|600px|]]

Hier werden in nicht-editierbarer Form die wichtigsten Daten für den gegenwärtigen und den darauffolgenden Tag angezeigt.
*Rechts oben die Liste der '''stateDevices'''. Wie man hier sieht, ist eine der Türen nicht geschlossen und somit der Zustand ''Gesichert'' nicht vollständig erfüllt. Es ist Aufgabe der externen Helferfunktionen, dies ggf. zu korrigieren.

==== Das YAAHM-Widget ====

[[Datei:YAAHM_widget_1.png|400px|]]

Dabei handelt es sich um eine dynamisch erzeugte SVG-Datei, die man auch in beliebige eigene Webseiten einbinden kann. Der Aufruf dafür lautet
<IP-Adresse:Port>/fhem/YAAHM_timewidget?name='<Device-Name>'&size='<breite>x<höhe>'
Selbstverständlich kann man das auch in einen eigenen Weblink einbauen.
Markiert sind auf diesem Kreis die ''housetime''-Events ''Sonnenaufgang'', ''Morgen'', ''Mittag'', ''Nachmittag'', ''Abend'', ''Sonnenuntergang'' und ''Nacht''. Die ''Tageszeit'' ist ferner durch einen türkisfarbenen Sektor gekennzeichnet, und Mitternacht ist immer "unten".

Die gegenwärtige Zeit (beim Aufruf !) wird in rot angezeigt.

Hinweis: Es ist angedacht, dieses Widget noch sehr viel interaktiver zu machen.

===Einstellung des Tages-Profils===

[[Datei:daily_2.png|600 px]]
*Der Startbutton erzeugt einen externen Timer (mit dem DOIF-Modul), der auf die Zeiten der definierten ''housetime''-Events zugreift.
*Wenn dieser Timer erzeugt wurde, zeigt das Webinterface den entsprechenden Link an. Ein grüner Haken bedeutet, dass der Timer aktiv (enabled) ist, wenn er deaktiviert wurde (disabled), wird ein rotes Kreuz angezeigt.
*Die Aktionsfelder enthalten jeweils eine semikolon-getrennte List von FHEM-Befehlen, die bei Eintreten des Timer-Events abgearbeitet wird.
*Wenn das Attribut ''timeHelper'' auf einen Perl-Funktionsnamen gesetzt wird, erfolgt automatisch der Eintrag des Perl-Funktionsnamens in das Aktionsfeld, verbunden mit dem Argument des entsprechenden Events.

==Einstellung der Wochen-Profile==
[[Datei:weekly_2.png|400 px]]
*Der Startbutton erzeugt externe Timer (mit dem DOIF-Modul), die auf das Reading ''ring_<timer-no>'' zugreifen. Dieses Reading wird jeweils kurs nach Mitternacht auf den korrekten Wert für den entsprechenden Tag gesetzt.
*Wenn diese Timer erzeugt wurden, zeigt das Webinterface den entsprechenden Link an. Ein grüner Haken bedeutet, dass der Timer aktiv (enabled) ist, wenn er deaktiviert wurde (disabled), wird ein rotes Kreuz angezeigt.
*Die Checkboxen Par und Abw geben an, ob das betreffende Wochen-Profil (und damit der Timer) auch in den Modi ''Party'' und ''Abwesenheit'' aktiv ist. Die Checkboxen Fer und Fei geben an, ob das betreffende Wochen-Profil (und damit der Timer) auch an den Tagestypen ''Ferientag'' und ''Feiertag'' aktiv ist.
*Die Aktionsfelder enthalten jeweils eine komma-getrennte List von FHEM-Befehlen, die bei Eintreten des Timer-Events abgearbeitet wird.
*Wenn das Attribut ''timeHelper'' auf einen Perl-Funktionsnamen gesetzt wird, erfolgt bei den beiden ersten (=Standard-) Timern automatisch der Eintrag des Perl-Funktionsnamens in das Aktionsfeld, verbunden mit dem Argument ''wakeup'' oder ''sleep''.

=Sonstiges=
==Sperrung==
Das Reading ''lockstate'' muss den Wert ''unlocked'' haben, damit durch Anklicken der Start-Buttons für die Timer diese auch gestartet werden. Das ist in der Regel beim ersten Laden des Moduls '''nicht''' der Fall, hierzu muss also das Reading von Hand auf den richtigen Wert gesetzt werden. Dazu muss der Befehl '''set ... unlocked''' ausgeführt werden.

Benutzer Diskussion:LordVoodoo

2017-02-20T21:43:41Z

LordVoodoo: Antwort

== Willkommen! ==
{| width="100%" cellspacing="0" cellpadding="6" style="line-height: 20px; background: #E0E0E0; border: 2px solid #1874CD;"
|-
| colspan="4" style="background:#1874CD;" |<big>'''Hallo LordVoodoo,''' willkommen im FHEM Wiki!</big>
|-
| colspan="4" | Danke für dein Interesse an unserem Projekt, ich freue mich schon auf deine weiteren Beiträge. Die folgenden Seiten sollten dir die ersten Schritte erleichtern, bitte nimm dir daher etwas Zeit, sie zu lesen.

----
'''FHEM-spezifische Informationen'''

|-
| width="8%" |  
| width="38%" | '''[[Systemübersicht]]''' ''FHEM Systemübersicht''
| width="8%" |  
| width="38%" | '''[[FHEMWiki:Über FHEMWiki]]''' ''Informationen über dieses Wiki''

|-
| colspan="4" |
----
'''Generelle Informationen über (Media)Wikis'''
|-
| width="8%" | [[Datei:Crystal Clear app kedit.svg|rechts|30px|link=Hilfe:Bearbeiten]]
| width="38%" | '''[[Hilfe:Bearbeiten]]''' ''Zugang zu allen wichtigen Informationen.''
| width="8%" | [[Datei:X-office-presentation.svg|rechts|30px|link=Wikipedia:Tutorial]]
| width="38%" | '''[http://de.wikipedia.org/wiki/Wikipedia:Tutorial Wikipedia:Tutorial]''' ''Schritt-für-Schritt-Anleitung für Einsteiger.''
|-
| [[Datei:Applications-system.svg|rechts|30px|link=Wikipedia:Grundprinzipien]]
| '''[http://de.wikipedia.org/wiki/Wikipedia:Grundprinzipien Wikipedia:Grundprinzipien]''' ''Die grundlegende Philosophie unseres Projekts.''
| [[Datei:MentorenProgrammLogo-7.svg|rechts|60px|link=Wikipedia:Mentorenprogramm]]
| '''[http://de.wikipedia.org/wiki/Wikipedia:Mentorenprogramm Wikipedia:Mentorenprogramm]''' ''Persönliche Einführung in die Beteiligung bei Wikipedia.''
|-
| colspan="4" |
----
Bitte beachte, [http://de.wikipedia.org/wiki/Wikipedia:Was_Wikipedia_nicht_ist was Wikipedia nicht ist], und "unterschreibe" deine Diskussionsbeiträge durch Eingabe von <code>--<nowiki>~~~~</nowiki></code> oder durch Drücken der Schaltfläche [[Datei:button_sig.png|Signaturknopf|20px|link=Hilfe:Signatur]] über dem Bearbeitungsfeld. Artikel werden jedoch nicht unterschrieben, und wofür die Zusammenfassungszeile da ist, erfährst du unter [http://de.wikipedia.org/wiki/Hilfe:Zusammenfassung_und_Quellen Zusammenfassung und Quellen]. 
[[Datei:Nuvola apps ksirc.png|25px|link=Benutzer Diskussion:Ph1959de]]    '''Hast du Fragen an mich?''' Schreib mir auf [[Benutzer Diskussion:Ph1959de|meiner Diskussionsseite]]! Viele Grüße, [[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 15:41, 22. Dez. 2016 (CET)
|}

== Auslagerung des Abschnitts Z-Wave#Cyrus_Zwischenstecker aus dem ZWave-Grundlagenartikel ==

Hallo!

Vielen Dank für Deinen Beitrag [[Z-Wave#Cyrus_Zwischenstecker]] im FHEM-Wiki. Ich würde das nur gerne aus dem ZWave-Artikel auslagern. Zum Hintergrund: Der Grundlagen-Artikel [[Z-Wave]] soll im Bereich Geräte-Besonderheiten '''kurze''' Angaben zu Auffälligkeiten von bestimmten ZWave-Geräten im FHEM-Umfeld und Lösungsansätzen dazu enthalten. Die allgemeine und wichtige Beschreibung der Zerlegung von Readings und Übertragung von Teilstrings per notify auf einen dummy ist dort meiner Meinung nach nicht gut plaziert und zu lang. Das ist keine Besonderheit des Cyrus-Steckers, sondern ein allgemeines FHEM-Thema, das in vielen Fällen interessant und wichtig ist. Aus meiner Sicht bieten sich mehrere Lösungsansätze. Bspw. könnte man das im Bereich Code_Snippets als Artikel aufnehmen oder eine separaten Cyrus-Zwischensteckerartiel erstellen oder man behandelt das Thema in einem Readings-Artikel oder ...

Würde mich freuen, wenn Du das übernehmen könntest. 

Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 12:14, 6. Jan. 2017 (CET)

<hr>
Hallo!

Da nach über einem Monat noch keine Reaktion auf meine Bitte/Hinweis erfolgte, habe ich heute den Abschnitt aus dem ZWave-Grundlagenartikel entfernt. Da mir persönlich die dummy - Version der Readingsanpassung zu umständlich ist bzw. ich den Grund nicht kenne, habe ich das auch nirgendwo anders im Wiki plaziert. Das kannst Du aber gerne noch machen.

Alternativen zur dummy-Variante hatte ich im gelöschten Artikeltext bereits ergänzt.

Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 12:02, 13. Feb. 2017 (CET)Christian

Hallo Christian,

danke für Deinen Hinweis. Verstehe ich, dass das nicht zwingend zum Z-Wave-Teil gehört. Ich hatte im Forum den Hinweis darauf bekommen, dass "current Power consumption" Reading so zubekommen und es daher bei dem Adapter so platziert.
Hoffe aber, dass ansonsten Form und Stil in Ordnung war.

Viele Grüße, Matthias.

Z-Wave

2017-01-04T08:45:16Z

LordVoodoo: /* Geräte-Besonderheiten */

<div style="float:right">{{Infobox Modul
|Name=ZWDongle
|ModPurpose=Einbindung Z-Wave-Gateways
|ModType=d
|ModCmdRef=ZWDongle
|ModForumArea=ZWave
|ModTechName=00_ZWDongle.pm
|ModOwner=Rudolf König ([http://forum.fhem.de/index.php?action=profile;u=8 Forum])
}}
{{Infobox Modul
|Name=ZWave
|ModPurpose=Ansteuerung Z-Wave-Geräte über ZWDongle
|ModType=d
|ModCmdRef=ZWave
|ModForumArea=ZWave
|ModTechName=10_ZWave.pm
|ModOwner=Rudolf König ([http://forum.fhem.de/index.php?action=profile;u=8 Forum])
}}
</div>

[[Z-Wave]] ist ein drahtloser Kommunikations-Standard im 868 Mhz-Band (Europa), der von der Firma Sigma Designs und der Z-Wave Alliance, einen Zusammenschluss von mehreren Hundert Herstellern, für die Heimautomatisierung entwickelt wurde. Es existieren mehr als [http://products.z-wavealliance.org 1000 zertifizierte Produkte] verschiedenster Hersteller, die innerhalb eines gemeinsamen Z-Wave-Netzes einsetzbar sind. (Quelle: [http://de.wikipedia.org/wiki/Z-Wave Wikipedia])

Auf dieser Seite werden Grundlagen eines '''Z-Wave''' Systems und dessen Einrichtung in FHEM beschrieben.
== Z-Wave ==
=== Nodes - Controller und Slaves ===
Ein Z-Wave-Netz besteht aus mindestens 2 Geräten, den sogenannten '''Nodes''' (Knoten). Es setzt sich zusammen aus dem steuernden '''Controller''' (Zentrale) und min. 1 bis max. 231 gesteuerten '''Slaves''' (Geräten).

=== Home-Id und Node-ID ===
Innerhalb eines Z-Wave-Netzes gibt es zu 2 Identifikationsnummern zur Kennzeichnung der Netzstruktur:
# '''Home-ID:''' Gemeinsame Identifikationsnummer aller Nodes in einem Netz zur Abgrenzung gegenüber anderen Netzen. Nur Nodes mit der gleichen Home-ID können miteinander kommunizieren.
# '''Node-ID:''' Identifikationsnummer zur eindeutigen Kennzeichnung von jedem Node im Netz.

Die Home-ID ist im Controller (fest) hinterlegt und seine Node-ID ist typischerweise 1. Die Slaves haben zunächst keine Home-ID und Node-ID. Bei der '''Inklusion''' (Aufnahme) der Slaves in das Z-Wave-Netz überträgt der Controller seine Home-ID auf die Slaves und weist den Slaves eine eindeutige Node-ID im Netz zu, mit der Sie direkt angesprochen werden.

Besondere Node-ID ist die 255. Eine Nachricht an die Node-ID 255 kann von allen Z-Wave-Nodes ausgewertet werden (Broadcast).

=== Primär- und Sekundärcontroller ===
Der Controller, der durch Zuteilung seiner Home-ID auf die Slaves, das Netz aufbaut, ist der '''Primärcontroller'''. Grundsätzlich können in einem Netz mehrere Controller existieren, aber immer nur ein Primärcontroller. Weitere in das Netz eingebundene Controller werden zum '''Sekundärcontroller'''. Ohne besondere Maßnahmen kann nur der Primärcontroller die Inklusion (Einbindung) der Nodes in das Netz durchführen. Hingegen können sowohl Primär- als auch Sekundärcontroller die '''Exklusion''' (Ausschluss) eines Nodes aus dem Netz vornehmen.

Der Controller speichert intern diverse Informationen (Home-ID, Node-IDs,..) über das ZWave-Netz. Hierdurch kann unter anderem die Haussteuerungssoftware bei einem PC-Controller relativ unkompliziert gewechselt werden, da die wesentlichen ZWave-Netzinformationen vom Controller selbst verwaltet und gespeichert werden. Andererseits muß bei einem Controllerdefekt das gesamte Netz grundsätzlich neu aufgebaut werden, wenn kein Backup der internen Controllerdaten vorhanden ist.

=== Acknowledge ===
Im Z-Wave-Netz werden Nachrichten vom Empänger-Node an den Sender-Node rückbestätigt (Acknowledge). Bei ausbleibendem Acknowledge wiederholt der Sender-Node die Nachricht automatisch auf Protokollebene bis zu 2 mal. Hierdurch wird eine höhere Betriebssicherheit des Z-Wave-Netzes erreicht. Bei Broadcast-Nachrichten an die Node-ID 255 findet keine Rückbestätigung statt.

=== Vermaschtes Netzwerk mit Routing ===
Z-Wave nutzt als Netzwerktopologie ein '''mesh network''' (vermaschtes Netzwerk), d. h. jeder Node ist mit einem oder mehreren anderen Nodes verbunden. Das hat den Vorteil, dass eine Nachricht zwischen zwei Nodes übermittelt werden kann, selbst wenn diese nicht direkt miteinander kommunizieren können, z. B. weil sie zu weit voneinander entfernt sind. In diesem Fall wird die Funk-Nachricht über einen oder mehrere „Zwischen-Nodes“ übertragen; dieser Vorgang wird '''Routing''' genannt. Nur netzgespeiste Z-Wave-Geräte sind Router. Batteriebetriebe Z-Wave-Geräte sind grundsätzlich keine Router und dienen somit auch nicht zur Reichweitenerhöhung. (Quelle: [http://de.wikipedia.org/wiki/Z-Wave Wikipedia]) Einzelne Geräte, die alternativ per Batterie oder USB-Anschluss betrieben werden können, werden bei USB-Anschluss automatisch ({{Link2Forum|Topic=40393|Message=328080}}) oder durch Konfigurationsänderungen ({{Link2Forum|Topic=40393|Message=327331}}) zu Routern.

Informationen über das optimale Routing werden bei der Inklusion der Nodes in einer Routing-Tabelle des Primärcontrollers gespeichert. Dies geschieht durch Abfrage des Nodes, welche weiteren Nodes er erreichen kann. Durch örtliche Änderung oder Defekte von Nodes können die in der Routing-Tabelle gespeicherten Informationen fehlerhaft bzw. suboptimal werden. Dies kann sich in Funkkommunikationsproblemen im Netzwerk äußern. Hier kann ein per Software manuell angeforderter Neuaufbau der Routing-Tabelle gegebenenfalls Abhilfe schaffen. Bei Geräten und Controllern mit aktuellen Firmware-Versionen (SDK 4.5x und SDK 6.xx oder größer, aber ''nicht'' SDK 5.x) und Unterstützung von Explorer Frames kann sich die Routing-Tabelle unter bestimmten Bedingungen auch automatisch aktualisieren ("Selbstheilung")[http://wiki.zwaveeurope.com/index.php?title=SDK_Versions_and_Explorer_Frames].

=== Command Classes ===
Die Steuerung und Kommunikation der Nodes erfolgt über Befehle die funktionsbezogen in verschiedene '''Command Classes''' (Kommandoklassen) zusammengefasst sind.

Alle Z-Wave-Geräte haben als gemeinsame kleinste Übereinstimmung die '''Class Basic'''.

Z-Wave-Geräte haben im Originalzustand eine bestimmte arbeitsfähige Grund-Konfiguration. Anpassbar an individuelle Bedürfnisse ist die Konfiguration über die '''Class Configuration'''.

Durch eine Assoziation wird definiert, welche Geräte miteinander direkt -ohne Umweg über den Controller- kommunizieren können. Auch bei Ausfall des Controllers können diese Geräte ihre gemeinsame Funkton ausüben. Zudem dienen Assoziationen der Geschwindigkeitssteigerung und Funklastreduzierung innerhalb des Netzes. Angelegt werden Assoziationen über die '''Class Association'''.

Dies sind nur die allerwichtigsten Command Classes. Weitere Command Classes sind den Handbüchern zu entnehmen. Zudem enthält die Wiki-Seite [[Z-Wave Command Classes]] weitergehende Informationen.

=== Hinweise zur Z-Wave-Geräteauswahl ===
Aufgrund der vielen Z-Wave-Gerätehersteller mit jeweils eigenem Z-Wave-Gerätesortiment existiert eine große Produktauswahl. Jedoch gibt es auch große Unterschiede hinsichtlich Produkteigenschaften, Pflege der Produkte, Häufigkeit der Aktualisierung der Produktpalette und so weiter. Schwierigkeiten bereitet insbesondere, dass neben den aktuellesten Chipsätzen und SDKs auch die älteren Chipsätze und SDKs weiterhin in Produkten im Handel verfügbar sind. Neuere Chipsätze und aktuelle SDKs bieten gerade bei der Netzwerkstabilität (Explorer Frames, Reichweite usw.) Vorteile zu älteren Chipsätzen und SDKs. Beispielsweise beherrschen nur Geräte mit SDK 4.5x und 6.x oder neuer die für automatische Routenkorrekturen wichtigen Explorer Frames. Das ältere SDK 5.0, das verwirrenderweise auch noch eine höhere Versionsnummer als das neuere SDK 4.5 besitzt, beherrscht unter anderem keine Explorer Frames. Details hierzu enthält das [http://wiki.zwaveeurope.com/index.php?title=SDK_Versions_and_Explorer_Frames wiki.zwaveeurope.com]. Aktuellstes SDK ist Stand 06/2016 das SDK 6.5x, das in ZWave Plus - zertifizierten Produkten zum Einsatz kommt.

Gerade Einsteiger beachten die Unterschiede bei den Chipsätze/SDKs aus Unkenntnis manchmal nicht und ärgern sich im Nachhinein über Probleme bei der Netzwerkstabilität und Reichweite. Darum nachfolgend allgemeine, aber sehr einfache Empfehlungen zur Geräteauswahl. Selbstverständlich wird hier nicht von anderen Produkten abgeraten, wenn man die Unterschiede kennt und Vorteile bei deren Produkteigenschaften sieht. Zudem kann man (leider) schlechtere Produkteigenschaften bei Geräten mit aktuelleren Chipsätzen/SDKs nie ausschließen.

Gateway
# [http://z-wavealliance.org/z-wave_plus_certification Z-Wave Plus-Zertifizierung]. Diese ist mittlerweile bei nahezu allen erhältlichen Gateways gegebenen.

Endgeräte
# Z-Wave Plus-Zertifizierung (aktuellste Technik, höhere theoretische Reichweite, SDK 6.5x) oder
# zumindest Explorer Frames-Unterstützung (SDK 4.5x und 6.0x) oder
# zuletzt -bei Kenntnis der Besonderheiten und Auswirkungen- Produkte ohne Explorer Frames (SDK 5.0x)

'''Kurz''': Produkte mit Z-Wave Plus-Zertifizierung einsetzen.

Bitte unbedingt beachten, dass Z-Wave Plus-Vorteile bei einem Mischbetrieb mit älteren (ohne Plus) Geräten teilweise verloren gehen. Zum negativen Effekt des Einsatzes eines älteren, aber weiterhin erhältlichen Z-Wave-Repeaters mit aktuellen Z-Wave Plus-Geräten siehe beispielsweise den Hinweis in diesem {{Link2Forum|Topic=42591|Message=350066}}.

Bei Fragen zu bestimmten Geräten bitte -nach Durchsicht der Hinweise hier im Wiki- im Forum suchen oder anschließend nachfragen.

== Z-Wave in Fhem ==
=== Allgemein ===
FHEM wird fortwährend weiterentwickelt und verbessert. Daher ist es zwingend notwendig, dass FHEM auf dem aktuellsten Stand ist. Dazu nach der FHEM-Installation den Befehl <code>update</code> ausführen und anschließend <code>shutdown restart</code> durchführen. Genauso auch vor [[#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F|Anfragen im Forum]] die Aktualität von FHEM überprüfen.

Die Einbindung von Z-Wave in FHEM ist (nicht nur für den Anfänger) ausschließlich mit der standardmäßig eingeschalteten [[autocreate|autocreate-Funktion]] einfach möglich. Die Kenntnis der FHEM-Grundlagen und Durcharbeitung der Anfänger-Lektüren wird im Folgenden vorausgesetzt. Insbesondere sind [[Erste_Schritte_in_fhem|Erste Schritte in FHEM]] und [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung mit FHEM] Pflicht, auch wenn sie nicht speziell Z-Wave behandeln, so werden doch wesentliche Punkte für ein Verständnis von FHEM vermittelt.

Nachfolgend und auf den [[:Kategorie:Z-Wave Components|Wiki-Seiten der Einzelgeräte]] werden immer wieder Auszüge aus der [[Konfiguration]] dargestellt. Diese dienen zur Erläuterung und Veranschaulichung. Die Bearbeitung der Konfiguration sollte -zur Verhinderung von Fehlern- nach Möglichkeit immer über das "[[Konfiguration#Befehl-Eingabefeld|Befehl-Eingabefeld]]" und die "[[Konfiguration#Objektdetails|Objektdetails]]" erfolgen.

=== Vorbereitung ===
Die Bedienungsanleitungen (Handbücher) sind zwingende Voraussetzung zur korrekten Einbindung und Konfiguration von Z-Wave-Geräten in FHEM. Sie müssen daher vorliegen. Die Handbücher und technischen Informationen vieler Z-Wave-Geräte sind -trotz verschiedener Hersteller- zentral unter http://www.zwave.de/handbuecher/ in Deutsch abrufbar. Der Aufbau aller dort veröffentlichten Handbücher ist gleichartig, so dass man einen schnellen Einstieg in die Produkte und deren technischen Eigenschaften von verschiedenen Herstellern findet. Manche Hersteller (z.B. Fibaro) bieten zusätzlich auf Ihren Internetseiten noch separate, eigene Handbücher an. Bei ZWave-Plus-zertifizierten Geräten sind detaillierte Handbücher zudem unter http://products.z-wavealliance.org auf der gerätespezifischen Seite zu finden. Diese enthalten teilweise mehr Informationen als die den Produkten beigelegten Handbücher (z.B. AEOTEC).

== Definition des Gateways / Controllers ==
{{Randnotiz|RNText='''Tester für ZWave@culfw gesucht!'''
ZWave-Controllerfunktionen werden derzeit in die Firmware [http://www.culfw.de culfw] für den [[CUL]] implementiert. Detailinformationen zur Entwicklung finden sich im {{Link2Forum|Topic=44905}}. Eine kurze Zusammenfassung zum Stand 04/2016: {{Link2Forum|Topic=52364|Message=441957}} }}
=== Autocreate des Gateways ===
FHEM kann mit einem Funkgateway Z-Wave-Funk empfangen und senden. Z-Wave-Gateways (Controller) existieren von verschiedenen Herstellern.

Folgende Gateways wurden unter anderem bereits erfolgreich mit FHEM eingesetzt:
* AEON Labs Z-Stick S2 (SDK 5.x; [https://aeotec.freshdesk.com/support/solutions/articles/6000091809-z-stick-s2-v3-08-firmware-update Firmwareupdate auf 3.08 aus 2016])
* Aeotec Z-Stick Gen5 (Z-Wave Plus; SDK 6.5; [https://aeotec.freshdesk.com/support/solutions/articles/6000108806-z-stick-gen5-backup-software Backup-Software)] ({{Link2Forum|Topic=47000}})
* Goodway WD6001 (SDK 5.03 {{Link2Forum|Topic=40594|Message=332235}})
* Vision Z-Wave USB Stick ZU 1401 EU (SDK 6.0x)
* Vision Z-Wave USB Stick ZU 1401-5 EU (Z-Wave Plus; SDK 6.5x)
* Z-Wave.Me Z-StickC ({{Link2Forum|Topic=29930|Message=226530}})
* Z-Wave.Me USB Stick ZME_UZB1 (SDK 6.5x; Z-Wave Plus; [http://razberry.z-wave.me/z-way-server/ Firmwareupdate und Backup über z-way])
* Z-Wave.Me Razberry in Verbindung mit Raspberry Pi (1. Generation: Z-Wave, 2. Generation: Gen5-Razberry mit Z-Wave Plus[http://forum.z-wave.me/viewtopic.php?f=3419&t=21327#p55404])
** Die seriellen Schnittstelle /dev/ttyAMA0 muss am Raspberry Pi freigeschaltet werden, damit das Razberry-Modul funktionsfähig ist: {{Link2Forum|Topic=11716|Message=190402}})
** Beim Raspberry Pi 3 muss der GPIO-Port auf den Hardware-UART0 umgestellt werden: [[Raspberry Pi 3: GPIO-Port Module und Bluetooth]]

Folgende Gateways sind '''nicht''' mit FHEM einsetzbar:
* Merten Funk-USB-Datenschnittstelle CONNECT

Sollte das eigene Gateway hier nicht aufgeführt sein, ist aufgrund der Standardisierung dennoch die Chance für eine erfolgreiche Einbindung des Gateways in FHEM vorhanden. Bitte dies hier oder im Forum entsprechend vermerken.

Das Z-Wave-Gateway wird unter Linux nach Anschluss an den FHEM-Rechner beim nächsten FHEM-Start oder ohne FHEM-Neustart durch Aufruf des Befehls <code>usb scan</code> zumeist automatisch erkannt und grundlegend durch entsprechende Einträge in der Konfiguration definiert. Ein manuelles Anlegen des ZWDongle-Moduls oder Eingriffe in die Konfiguration sind unter Linux normalerweise nicht notwendig und auch nicht ratsam. Unter Windows ist ein manuelles Anlegen der Definition des ZWave-Gateways wegen fehlender Unterstützung des Befehls <code>usb scan</code> erforderlich. Das FHEM-Gateway-Device ist nach der Definition in FHEM im Raum "Everything" zu finden.

Beispiele der automatisch erzeugten define-Zeile in der Konfiguration:

Aeon Labs Z-Stick an der Fritzbox:
define ZWDongle_1 ZWDongle /dev/ttyUSB0@115200

Vision Z-Wave USB Stick ZU 1401 EU am Raspberry Pi:
define ZWDongle_1 ZWDongle /dev/ttyACM0@115200

Insbesondere wenn am FHEM-Server unter Linux mehrere USB-Gateways eingesetzt, empfiehlt es sich zur Erhöhung der Betriebsstabilität das Z-Wave-Gateway über [[Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden|Serial-by-Id]] oder [[LinuxDeviceNaming|uDev-Regeln]] anzusprechen.

=== homeId und nodeList des Gateways ===
Zur manuellen Definition von Z-Wave Aktoren und Sensoren ist die <code>homeId</code> notwendig. Bei der hier bevorzugten Definition der Geräte durch autocreate ist die Kenntnis der <code>homeId</code> nicht zwingend. Jedoch sollte durch Abfrage der <code>homeId</code> direkt nach Einbindung des Zwave-Gateways dessen Funktionsfähigkeit getestet werden.

Die <code>homeId</code> und <code>CtrlNodeId</code> des Gateways wird mit folgendem Befehl ausgelesen (ZWDongle_1 ist im folgenden durch den eigenen Gatewaynamen zu ersetzen):
get ZWDongle_1 homeId
ergibt beispielsweise:
ZWDongle_1 homeId => HomeId:e345c456 CtrlNodeId:01

Die aktuelle Liste der Z-Wave Nodes, die bereits am Gateway registriert/inkludiert sind, wird mit dem folgendem Befehl ausgelesen:
get ZWDongle_1 nodeList
ergibt beispielsweise:
ZWDongle_1 nodeList => ZWDongle_1 UNKNOWN_2

== Definition von Geräten / Slaves ==
=== Hinzufügen eines neuen Z-Wave Geräts / Inklusion ===
Zur Verfolgung von Inklusionsablauf und Meldungen des Controllers während der Inklusion sollte der [[Event monitor]] in einem 2. Browserfenster vor Aktivierung des Inklusionsmodus geöffnet werden.

Das Z-Wave Gateway wird in den Standard-Modus zur Inklusion (zum Aufnehmen) neuer Geräte gesetzt:
set ZWDongle_1 addNode on
Bei der Standard-Inklusion muss direkter Funkkontakt zwischen Gateway und zu inkludierendem Z-Wave Gerät bestehen.

Sofern Z-Wave Gateway und Z-Wave Geräte Explorer Frames unterstützen, sollte statt des obigen Befehls besser der Network-Wide-Modus für die Inklusion genutzt werden:
set ZWDongle_1 addNode onNw
Bei der Network-Wide-Inklusion muss kein direkter Funkkontakt zwischen Gateway und zu inkludierendem Z-Wave Gerät bestehen. Es reicht, wenn das zu inkludierende Gerät über andere bereits inkludierte, netzgespeiste Geräte mit Explorer Frames-Unterstützung erreicht werden kann. Die Network-Wide-Inklusion ist zu bevorzugen, da die Z-Wave-Geräte regelmäßig an Ihren örtlichen Endpositionen inkludiert werden können. Dadurch werden bei der Inklusion direkt die korrekten Routen gespeichert.

Nachdem das Gateway in den Inklusionmodus geschaltet wurde, muss das Gerät in den Inklusionsmodus (Aufnahmemodus) versetzt werden. Wie dies zu erfolgen hat, ist im Handbuch des Geräte nachzulesen. Typisch sind ein- oder dreimaliges Drücken einer Taste am Gerät oder beim Anlegen der Versorgungsspannung. Durch die Inklusion werden Home-ID und Node-ID im Gerät gespeichert. Zudem teilt das Gerät über ein spezielle Funknachricht (NIF=Node Information Frame) dem Controller seinen Gerätetyp und seine Geräteeigenschaften mit. Hierbei werden dem Controller auch die vom Gerät unterstützten Command Classes mitgeteilt. Aus diesen Informationen erzeugt FHEM automatisch durch autocreate das FHEM-Geräte-Device nach dem Namensschema <code><nowiki>ZWave_<Geräteklasse laut NIF des Gerätes>_<NodeID></nowiki></code> (an eigene Wünsche anpassbar mit [http://fhem.de/commandref.html#rename rename]). Die vom Geräte unterstützen Command Classes, die die in FHEM verfügbaren Befehle bestimmen, werden automatisch im Attribut <code>classes</code> des FHEM-Geräte-Device gespeichert. Das Gerät ist damit grundlegend in FHEM definiert und im Raum "ZWave" zu finden.

Nach der Inklusion schaltet FHEM den Inklusionsmodus des Z-Wave Gateway automatisch durch Absetzen des Befehls <code>set ZWDongle_1 addNode off</code> aus und zeigt eine Dialogbox mit dem Ergebnis der Inklusion:
* <code><nowiki>created ZWave_<Geräteklasse laut NIF des Gerätes>_<NodeID></nowiki></code> = Inklusion war erfolgreich und es wurde das bezeichnete FHEM-Device durch autocreate angelegt.
* <code><nowiki>addNode failed</nowiki></code> = Inklusion ist fehlgeschlagen

Eine erfolgreiche Inklusion ist zudem am Event "ZW_ADD_NODE_TO_NETWORK protocolDone" im Event monitor und natürlich der Anlage des entsprechenden FHEM-Devices durch autocreate zu erkennen. Das Scheitern einer Inklusion führt typischerweise zur Ausgabe des Events "ZW_ADD_NODE_TO_NETWORK failed". Häufigste Ursache sind Controllerprobleme, die sich oftmals durch kurzes Ein- und Ausstecken des Controllers, Neustart des Systems oder Ein- und Ausschalten des FHEM-Server-Computers beheben lassen.

HINWEISE: 
* Die Network-Wide-Inklusion kann nach derzeitiger Kenntnis auch bei Gateways und Geräten ohne Explorer Frames Unterstützung genutzt werden, da bei diesen Geräten grundsätzlich automatisch auf die Standard-Inklusion umgestellt wird.
* Bei der Standard-Inklusion ist unter Umständen nur ein geringer Abstand zwischen Gateway und Gerät möglich. Sollte die Inklusion daher nicht durchführbar sein, wenn Gateway und Gerät an ihren örtlichen Endpositionen sind (bevorzugte Variante), dann ist der Abstand zwischen diesen versuchsweise zu verringern. Anschließend bei örtlicher Veränderung die Routen mit <code><nowiki>set <name> neigborUpdate</nowiki></code> bzw. <code><nowiki>set TYPE=ZWave:FILTER=ZWaveSubDevice=no neighborUpdate</nowiki></code> neu ermitteln lassen. Unter Umständen kann der Abstand nur schrittweise erhöht werden. Dann ist bei jeder Abstandsänderung eine Neuermittlung der Routen notwendig.
* Der NIF enthält bei manchen Geräten fälschlicherweise nicht alle unterstützten Command Classes. FHEM identifiziert während der Inklusion das Gerät und ergänzt die fehlenden Command Classes aufgrund manuell gepflegter, gerätespezifischer [[#Welche_Funktion_haben_die_XML-Config-Dateien_in_Fhem.3F|XML-Config-Dateien]]. Weiterhin fehlende Command Classes können im Attribut <code>classes</code> manuell entsprechend ergänzt werden. Informationen liefern die unter [[#Links|Links]] aufgeführten Datenbanken. Häufig fehlt die Pflicht-Class BASIC.
* Bei der hier beschriebenen Inklusion findet die Kommunikation zwischen Controller und Gerät anschließend dauerhaft unverschlüsselt statt. Manche Geräte bieten mit der Command Class SECURITY eine AES-verschlüsselte Kommunikation an. Da die Verschlüsselung zu einer höheren Funklast und Latenzen führt, sollte eine verschlüsselte Kommunikation nur mit Bedacht eingesetzt werden (bspw. bei Schlössern). Als Sonderfall ist das Vorgehen zur secure-Inklusion in der [[#Wie_kann_eine_verschl.C3.BCsselte_Kommunikation_unter_Nutzung_der_Command_Class_SECURITY_eingerichtet_werden.3F|FAQ]] beschrieben.

Nächster Schritt ist die [[#Assoziation|Assoziation]] des Gerätes mit dem Gateway.

=== Assoziation ===
{{Randnotiz|RNText=Bitte unbedingt die Besonderheiten bei [[#batteriebetriebene_Ger.C3.A4te|batteriebetriebenen Geräten]] beachten!}}
Z-Wave-Geräte können über Assoziationen direkt mit anderen Z-Wave-Geräten kommunizieren. Dies können zum einen Meldungen über den Status und Zustand der Geräte, als auch direkte Befehle sein. Zum Beispiel kann damit ein Bewegungsmelder eine entdeckte Bewegung an den Controller senden und/oder bei entdeckter Bewegung direkt eine Lampe ein- oder ausschalten.

Die Assoziation zwischen zwei Geräten wird durch Aufnahme des zu steuernden Gerätes in eine oder mehrere Assoziationsgruppe(n) des steuernden Gerätes angelegt. Durch die Wahl der Assoziationsgruppe wird festgelegt, bei welchen Ereignissen welche Nachricht an das assoziierte Gerät verschickt wird. Angaben zu den Ereignissen und versandten Nachrichten an die Geräte in einer bestimmten Assoziationsgruppe stehen in der Bedienungsanleitung des jeweiligen Gerätes.

Damit FHEM Statusmeldungen von Sensoren/Aktoren anzeigen und auch darauf reagieren kann, '''muss''' der Controller (ZWDongle_1, <code>CtrlNodeId</code> = typischerweise 1) immer in der/den passenden Assoziationsgruppe(n) des jeweiligen Gerätes <code><name></code> aufgenommen werden:

set <name> associationAdd <associationGroup> <CtrlNodeId>

Typischerweise ist die Assoziationsgruppe 1 der Geräte für die Statusmeldungen an den Controller vorgesehen (Ausnahme: [[#Fibaro|Fibaro-Geräte ohne ZWave Plus - Zertifizierung]]). Daher nimmt FHEM die Assoziation von Controller mit der Assoziationsgruppe 1 des Gerätes bei der Inklusion immer automatisch vor. Zudem identifiziert FHEM während der Inklusion das Gerät und setzt weitere Assoziationen mit dem Controller für von 1 abweichende Assoziationsgruppen aufgrund manuell gepflegter, gerätespezifischer [[#Welche_Funktion_haben_die_XML-Config-Dateien_in_Fhem.3F|XML-Config-Dateien]]. Ist keine XML-Config-Datei für das Gerät vorhanden, sind Assoziationen des Controllers mit von 1 abweichenden Assoziationsgruppen oder weiteren Assoziationsgruppen mit dem zuvor genannten Befehl grundsätzlich manuell anzulegen.

Die richtige Anlage der Assoziation(en) des Controllers mit dem Gerät immer prüfen, da dies eine Hauptfehlerquelle bei Funktionsproblemen mit FHEM ist.

Abruf der assoziierten Geräte in einer bestimmten Assoziationsgruppe <associationGroup>:
get <name> association <associationGroup>

Abruf der assozierten Geräte für alle Assoziationsgruppen eines Gerätes:
get <name> associationAll

Nahezu alle in Europa erhältlichen aktuellen Geräte unterstützen die Rückmeldung des Status via Association. Ausnahmen gibt es in Nordamerika, wo aufgrund von Patentansprüchen einige Hersteller auf die Statusrückmeldungen verzichten. Diese Geräte unterstützen in der Regel die Command Class ASSOCIATION nicht.

Nächster Schritt ist die [[#Konfiguration|Konfiguration]] des Gerätes.

=== Konfiguration ===
{{Randnotiz|RNText=Bitte unbedingt die Besonderheiten bei [[#batteriebetriebene_Ger.C3.A4te|batteriebetriebenen Geräten]] beachten!}}
Die Standard-Konfiguration eines Gerätes entspricht oftmals nicht den eigenen Wünschen und Anforderungen (Einheiten usw.). Mit den Befehlen der Class CONFIGURATION lässt sich die Konfiguration anpassen. Die zur Konfiguration eines Gerätes notwendigen Angaben zu den Parameternummern, -größen und -werten sind im jeweiligen Geräte-Handbuch bzw. entsprechenden Datenbanken (bspw. [http://www.pepper1.net/zwavedb/ pepper1-Zwave-Datenbank] oder [http://products.zwavealliance.com/ products.zwavealliance.com]) enthalten.

Die Konfiguration beispielsweise bei Parametergröße 1 lässt sich mit diesem Befehl anpassen:
set <name> configByte <Parameternummer> <Parameterwert>
Für weitere Parametergrößen gibt es die Befehle <code>configWord</code> und <code>configLong</code>

Die im Gerät hinterlegten Konfiguration kann pro Parameternummer mit folgendem Befehl abgerufen werden:
get <name> config <Parameternummer>

Zudem bietet FHEM basierend auf den manuell gepflegten XML-Config-Dateien die Möglichkeit, die speziellen Parameternummern des Gerätes mit ihren Parametergrößen und -werte als eigenständige config-Befehle mit Hilfsinformationen einzubinden. Ein manuelles Suchen im Geräte-Handbuch und Nutzung der configByte-, configWord- und configLong-Befehle ist dadurch in vielen Fällen unnötig. Für diese Funktion muss das Gerät von FHEM einmalig durch folgenden Befehl, der bei der Inklusion automatisch ausgeführt wird, identifiziert werden:
get <name> model
Die Readings <code>model</code>, <code>modelID</code> und <code>modelConfig</code> werden dadurch erzeugt. In <code>model</code> sollte der Klartextname des Gerätes stehen. Zudem sind dann -soweit eine XML-Config Datei für das Gerät existiert- die speziellen set/get-Kommandos configXYZ für das Geräte im Auswahldialog der Detailansicht mit Hilfsinformationen verfügbar:
[[Datei:Z-Wave_confighelp.PNG|900px|thumb|center|config-Befehl mit Hilfstext]]

Bei vorhandener XML-Config-Datei kann die komplette Konfiguration eines Gerätes abgerufen werden:
get <name> configAll

Außerdem wird durch den <code>get <name> model</code> -Befehl geprüft, ob das Gerät in der pepper1-Zwave-Datenbank enthalten ist. Im Erfolgsfall wird ein Link "Details in pepper1.net" unten in der Detailansicht des FHEM-Geräte-Devices zum entsprechenden Geräteeintrag angelegt und ein Bild des Gerätes in die Detailansicht eingebunden.

Der Aufruf von <code>get <name> model</code> ist auch für die Nutzung der Class MANUFACTURER_PROPRIETARY zwingende Einsatzvoraussetzung.

=== Entfernen eines Z-Wave-Geräts / Exklusion ===
Durch die Exklusion wird die Home-ID und Node-ID aus dem Gerät und das Gerät selbst aus der Node-List des Controllers gelöscht. Erst nach einer Exklusion kann das Gerät in ein anderes Z-Wave-Netz aufgenommen werden.

Zuerst wird der Z-Wave Gateway in den Standard-Modus zur Exklusion (Ausschluss) von Geräten gesetzt:
set ZWDongle_1 removeNode on

Sofern Z-Wave Gateway und Z-Wave Geräte Explorer Frames unterstützen, sollte statt dem obigen Befehl besser der Network-Wide-Modus für die Exklusion genutzt werden (siehe auch Erläuterungen zu Standard- versus Network-Wide-Inklusion unter [[#Hinzufügen eines neuen Z-Wave Geräts / Inklusion|Inklusion]]):
set ZWDongle_1 removeNode onNw

Danach muss das Gerät in den Exklusionsmodus (Ausschlussmodus) versetzt werden. Wie dies zu erfolgen hat, ist im Handbuch des Geräte nachzulesen.

Abschließend wird der Exklusionsmodus am Z-Wave Gateway wieder ausgeschaltet:
set ZWDongle_1 removeNode off

Das FHEM-Device muss nach der Exklusion manuell durch <code>delete <name></code> gelöscht werden.

Die durch die Exklusion frei gewordene NodeID wird nicht bei der nächsten Inklusion wiederverwendet, sondern es wird die höchste noch nicht verwendete NodeID genutzt.

=== Erneutes Hinzufügen eines bereits registrierten Z-Wave Geräts ===
Die an einem Z-Wave-Gateway bereits registrierten/inkludierten Geräte sind im Gateway selbst abgespeichert und können durch FHEM jederzeit wieder abgerufen werden. Dies kann man in folgenden Fällen sinnvoll nutzen:
* Inklusion mit einem batteriegespeisten ZWave-Gateway (bspw. Aeon Labs Z-Stick) ohne FHEM-Server-Anschluss während der Inklusion
* Umstieg eines ZWave-Netzwerkes von Fremdsoftware auf FHEM
* Vollständiger oder teilweiser Verlust der FHEM-Konfiguration

Eine Node-Liste aller inkludierten Geräte des Gateways wird abgerufen durch:
get ZWDongle_1 nodeList
Es wird eine Liste aller im Gateway inkludierten Gerät inklusive Gateway selbst zurückgeliefert. Sofern ein Gerät bereits als FHEM-Device angelegt wurde, wird der FHEM-Device-Name in der nodeList angezeigt. Dies ist für das Gateway selbst immer der Fall. Im obigen Beispiel ist der Eintrag "ZWDongle_1". Alle noch nicht in FHEM angelegten Geräte, werden als "UNKNOWN_x" ausgegeben, wobei x die ID des betreffenden Gerätes ist.

Mit dem folgenden Befehl wird beispielsweise das bereits im Gateway inkludierte Gerät mit der ID 2 (in der nodeList angezeigt als "UNKNOWN_2") in FHEM durch autocreate definiert:
set ZWDongle_1 createNode 2

Batteriebetriebene Geräte müssen bei Absetzen des <code>createNode</code>-Befehls wach sein, damit der Befehl verarbeitet werden kann. Dies erreicht man, indem man das Gerät auf "permanent wach" stellt. Falls das Gerät diese Funktion nicht anbietet, muss man es manuell aufwecken und max. 2 Sekunden später den <code>createNode</code>-Befehl absetzen. Alternativ kann das batteriebetriebene Gerät durch Versand des NIF vom Gerät aus automatisch in FHEM erzeugt werden: Hierzu am Gerät die Taste zum Versand des NIF drücken und <code>autocreate</code> legt das FHEM-Device an; der Aufruf von <code>createNode</code> entfällt dann.

== Geräte-Besonderheiten ==
=== batteriebetriebene Geräte ===
Batteriebetriebenen Geräten können hinsichtlich ihrer Empfangsbereitschaft unterschieden werden in

* Wakeup-Geräte
* FLIRS-Geräte

==== Wakeup-Geräte ====
Wakeup-Geräte sind momentan die häufigste Art von batteriebetriebenen Z-Wave Geräten. Sie sind erkennbar an der Unterstützung der Command Class WAKE_UP.
Zur Verlängerung der Batterielaufzeit legen sich batteriebetriebene Wakeup-Geräte „schlafen“ und wachen (Wakeup) nur in konfigurierbaren Intervallen auf, um Befehle zu verarbeiten. Das Aufwachen signalisieren die Geräte durch den Versand einer Nachricht "wakeup notification". Daraufhin senden FHEM und andere Geräte ihre bis dahin gesammelten Befehle, die dann verarbeitet bzw. beantwortet werden. Anschließend gehen die batteriebetriebenen Geräte wieder in den Schlafmodus.

FHEM teilt bei set/get-Befehlen an batteriebetriebene Geräte über einen Hinweis der Form
:<code>Scheduled for sending after WAKEUP</code>
mit, dass der Befehl im Send-Stack abgespeichert und bei der nächsten "wakeup notification" an das Gerät versendet wird. Ein Versand der Befehle im Send-Stack findet grundsätzlich ausschließlich nach Erhalt der "wakeup notification"-Nachricht statt, selbst wenn das Gerät zwischendurch andere Telegramme (bspw. Bewegungsmeldung, Temperatur) an den Controller verschickt. Nur nach Versand der "wakeup notification" ist das batteriebetriebene Gerät grundsätzlich in der Lage ("wach genug"), Telegramme korrekt zu empfangen und zu verarbeiten.

Das Wakeup-Interval und der Empfänger der "wakeup notification" wird wie folgt konfiguriert:
<nowiki>set <name> wakeupInterval <time> <NodeId></nowiki>
<nowiki><time></nowiki> ist die Zeit in Sekunden zwischen den Intervallen und <nodeID> der gewünschte Empfänger der "wakeup notification"; in der Regel ist dies '''immer''' der Controller <CtrlNodeId>. Viele Geräte kommen im Auslieferungszustand mit der NodeID 255. Die "wakeup notification" wird dann als Broadcast ohne Nutzung von Routing an alle erreichbaren Geräte gesendet. Hier sollte die Konfiguration auf die NodeID des Controllers geändert werden, da dadurch die "wakeup notification" geroutet wird und größere Entfernungen zwischen Gerät und Controller möglich sind. Zudem ist dies robuster und spart zusätzlich noch Batterielaufzeit. Darum setzt FHEM bei der Inklusion von WakeUp-Geräten '''automatisch''' den Befehl <code><nowiki>set <name> wakeupInterval 86400 <ControllerNodeId></nowiki></code> ab. Bei abweichenden eigenen Vorstellungen ist dies gegebenenfalls anzupassen. Bei Geräten mit V2 der Command Class WAKE_UP kann das vom Hersteller vorgesehene Standard-wakeupInterval mit <code><nowiki>get <name> wakeupIntervalCapabilities</nowiki></code> vom Gerät abgerufen werden. Die Einstellungen von wakeupInterval nach Inklusion und nach jeder Änderung immer mit der Abfrage <code><nowiki>get <name> wakeupInterval</nowiki></code> überprüfen.

Ein Aufwachen und Versand der "wakeup notification" von batteriebetriebenen Geräten kann für die [[#Assoziation|Assoziation]] und [[#Konfiguration|Konfiguration]] manuell erzwungen werden. Hierzu bringt man das Gerät normalerweise in den Inklusionsmodus oder findet in der Bedienungsanleitung gegebenenfalls andere Informationen. Bitte beachten, dass dann je nach Gerät nur eine geringe Entfernung von Gateway und Gerät vorhanden sein darf (direkte Erreichbarkeit). Alternativ kann für die Dauer der Assoziation und Konfiguration das Wakeup-Interval verkürzt werden (beispielsweise auf 60 Sekunden), wodurch das Routing genutzt werden kann und größere Entfernungen zwischen Gateway und Gerät überbrückt werden können. Anschließend das Wakeup-Interval wieder auf eine batterieschonenende Dauer einzustellen.

Einzelne batteriebetriebene Gerät lassen sich für längere Zeit auf "wach" bzw. permanent "wach" stellen. Dann aus dem Attribut <code>classes</code> <code>WAKE_UP</code> entfernen, damit Befehle in diesem Gerätemodus von FHEM direkt verschickt werden. Nach Ausschalten des "wach"-Modus <code>WAKE_UP</code> wieder im Attribut <code>classes</code> aufnehmen.

Bei Konfigurationsänderungen an batteriebetriebenen Geräten mit <code>set <name> config...</code> sollte die korrekte Verarbeitung der Befehle immer mit dem entsprechenden <code>get <name> config...</code> oder -falls vorhanden- mit <code>get <name> configAll</code> überprüft werden, um eventuelle Funk-Telegrammverluste sofort festzustellen.

==== FLIRS-Geräte ====
Ein batteriebetriebene FLIRS (frequently listening routing slave) Gerät wacht in sehr kurzen Zeitabständen (250ms oder 1000ms) auf und prüft, ob ein Funksignal vorliegt. Liegt kein Funksignal vor geht das Gerät wieder in Tiefschlaf. Zum Aufwecken eines FLIRS-Gerätes ist ein dauerhaftes Funksignal -der Wakeup-Beam-, notwendig, das etwas länger als die Aufweckzeitabstände sein muss. Näher beschrieben unter anderem [http://library.ademconet.com/MWT/fs2/VAM/Introductory-Guide-to-Z-Wave-Technology.PDF hier].

FLIRS-Geräte haben nicht die Command Class WAKE_UP und arbeiten deshalb nicht mit "wakeup notification". Aus Sicht des FHEM-Nutzers sind die bekannten FLIRS-Geräte (Sirenen von Vision und Popp) nicht anders zu bedienen/einzurichten als netzgespeiste Geräte. Wakeup-Beam und andere Besonderheiten werden unsichtbar für den Nutzer automatisch abgewickelt.

=== Aeon Labs / Aeotec ===
==== Multi Sensor 5 ====
* aktuellste Firmware installieren
* Attribut <code>classes</code> um <code>BASIC</code> ergänzen (ab [[version|Modulversion]] 8824/25.6.2015 wird das automatisch bei der Inklusion durchgeführt)
* bei USB-Anschluss aus Attribut <code>classes</code> <code>WAKE_UP</code> entfernen
* Parameter 101 auf 225 (oder 224 bei USB-Anschluss) setzen mit <code>set <name> configGroup1Reports 225</code> oder <code>set <name> configLong 101 225</code>, um Batteriezustand (nicht bei 224), Temperatur, Feuchte und Helligkeit regelmäßig zu erhalten. Das Sende-Intervall wird duch <code><nowiki>set <name> configGroup1Interval <time/s></nowiki></code> festgelegt (Standard 720 Sek).
* [http://www.pepper1.net/zwavedb/device/407 Paramterübersicht pepper-Datenbank]
siehe {{Link2Forum|Topic=34505|Message=268913}}

==== Multisensor 6 ====
siehe {{Link2Forum|Topic=40393}}
* arbeitet bei USB-Anschluß als Router
* bei USB-Anschluss aus Attribut <code>classes</code> <code>WAKE_UP</code> entfernen
* die <code>configGroupxInterval</code> und <code>configxxxReportingThreshold</code> Einstellungen wirken nur bei USB-Anschluss, im reinen Batteriebetrieb werden die Sensordaten nur bei einem <code>wakeup</code> übertragen

==== Aeotec LED Bulb ZW098-C55 ====
siehe {{Link2Forum|Topic=40504}}

=== Cyrus ===
==== Cyrus Zwischenstecker ====
Der Zwischenstecker speichert den aktuellen Stromverbrauch in einem Reading gemeinsam mit dem zuvor gemessenen Wert und dem zeitlichen Abstand zwischen beiden Messungen:

<pre>
12.61 W previous: 12.78 delta_time: 21 s
</pre>

Um den aktuellen Stromverbrauch einem [[Dummy]] zuzuweisen, kann man den String per [[Notify]] zerschneiden und den Wert übernehmen:

<pre>
# Dummy-Objekt zum Speichern des aktuellen Stromverbrauches:
define Licht_Watt dummy
</pre>

<pre>
# Auslesen des Readings "power" aus dem Cyrus-Zwischenstecker (hier nur "Zwischenstecker" genannt) und speichern im Dummy Licht_Watt
define Licht_Watt_Set notify Zwischenstecker:power:.* {
my $power = ReadingsVal("Zwischenstecker", "power", "");
my @values = split(' ', $power);
fhem("set Licht_Watt @values[0];");}
</pre>

=== Danfoss ===
==== DAN_LC-13 Heizungsthermostat LC-13 (014G0013) ====
Das Danfoss Heizungsthermostat LC-13 muss derzeit zur korrekten Funktion mit FHEM regelmäßig mit folgendem <code>at</code> abgefragt werden ({{Link2Forum|Topic=32145|Message=260795}}):
define Atdanfoss at +*00:30 get <name> battery
Auf dem Markt sind mehrere Varianten des Thermostates LC-13 erhältlich. Darum beim Kauf unbedingt auf die genaue Bezeichnung LC-13 (014G0013) achten ({{Link2Forum|Topic=38041|Message=303146}}).

=== devolo ===
==== MT02648 Tür-/Fenster Kontakt 3in1 ====
siehe {{Link2Forum|Topic=41337}}

=== DüWI ===
Geräte von DÜWI liefern bei örtlicher Betätigung kein automatisches Funk-Signal über die Statusänderung. Das liese sich nur durch eine regelmäßige Statusabfrage durch FHEM (beispielsweise <code>define Status_Abfrage at +*00:03:00 get <name> swmStatus</code>) beheben.
Einige Produkte von [http://zwave.me Z-Wave.Me] basieren auf DÜWI-Geräten. Diese Z-Wave.Me Produkte haben jedoch eine erweiterte Firmware, welche die genannte und weitere Firmware-Schwächen der Original-Produkte von DÜWI behebt.

=== Everspring ===
==== AN145 Sockelmodul E27 ====
Statusabfrage ohne permanente Abfrage: {{Link2Forum|Topic=48864|Message=405545|Beitrag}}

=== Fibaro ===
Association Group für Übermittlung von Statusinformationen an den Controller:
* ZWave-Geräte: häufig Association Group 3
: <code><nowiki>set <name> associationAdd 3 <CtrlNodeId></nowiki></code>
* ZWave Plus-Geräte: Association Group 1 ("lifeline")

==== FGS-222 Relais Unterputzeinsatz ====
Bei der Inklusion werden von FHEM 3 Devices angelegt:
* Hauptdevice (Steuerung und automatischer Status für Kanal 1 und kanalübergreifende Funktionen)
* Device für Endpoint 1 (Steuerung Kanal 1)
* Device für Endpoint 2 (Steuerung und automatischer Status von Kanal 2)
Die Firmware des FGS-222 übermittelt den Status für Kanal 1 automatisch immer ausschließlich an das Hauptdevice. Die Steuerung von Kanal 1 kann hingegen sowohl über das Hauptdevice als auch über das Device für Endpoint 1 erfolgen. Das Device für Endpoint 1 ist somit nicht zwingend erforderlich und kann grundsätzlich gelöscht werden.

Details: {{Link2Forum|Topic=50176}}

Hinweis zum Reset: {{Link2Forum|Topic=55190|Message=469393}}

==== FGK-101 Tür/Fensterkontakt ====
* Besonderheiten bei Anschluss eines Temperatursensors: {{Link2Forum|Topic=38012}}

=== GE ===
==== GE (Model t.b.d) ====
Dieser Schalter unterstützt keine Statusrückmeldungen.

=== Merten ===
Laut {{Link2Forum|Topic=38133}} müssen bei einigen Merten-Geräten, die mit Fremdsoftware inkludiert wurden, gegebenenfalls die Geräte wieder exkludiert und dann erneut mit FHEM inkludiert werden, damit Assoziationen mit FHEM gesetzt werden können.

=== Philio ===
==== PHI_PAN04 Relais Unterputzeinsatz 2 Schalter a 1.5kW mit Messfunktion ====
siehe {{Link2Forum|Topic=28046}}

=== Popp ===
==== POPE004001 Z-Wave Rauchmelder mit Innensirene ====
siehe {{Link2Forum|Topic=39856}}
==== POPE005107 Z-Wave Außensirene ====
siehe {{Link2Forum|Topic=42736}} 
Alte Firmwareversionen haben einen Bug bei der Übermittlung von negativen Temperaturen. Eine Lösungsvariante über ein <code>userReadings</code> findet sich auch im verlinkten Thema.
==== POPE009006 Z-Wave Wall Plug Switch ====
siehe {{Link2Forum|Topic=40771}}
==== POPE009402 10Year Smoke Detector ====
Die erste Firmwareversion hat eine fehlerhafte modelID. Der Rauchmelder wird dadurch fälschlich als [[Z-Wave#POPE005107_Z-Wave_Au.C3.9Fensirene|Popp Aussensirene]] in FHEM angezeigt. Laut Popp ist eine Firmwareupdate in Arbeit (Stand 07/16).

=== Z-Wave.Me ===
==== ZME_RC2 Fernbedienung ====
siehe {{Link2Forum|Topic=35513}} 
Das Forenthema enthält eine detaillierte Beschreibung der Nutzung der Class MULTI_CHANNEL_ASSOCIATION.

== Links ==
=== Allgemein ===
* Grundlageninformation "Z-Wave-Haupt-Anleitung": [http://manuals.zwaveeurope.com/Generic_Z_de.pdf Wie errichte und betreibe ich ein Z-Wave basiertes Funknetz]
* [http://www.zwave.de/buch-z-wave-grundlagen/ Buch] "Z-Wave: Die Funktechnologie für das Smart Home" von Dr. Christian Paetz (Paetz "is the primary European representative for the Z-Wave Alliance" [http://z-wavealliance.org/global-contacts/])
* herstellerübergreifende Datenbank mit Bedienungsanleitungen zu Z-Wave-Geräten: http://www.zwave.de/handbuecher/ oder http://manuals.zwaveeurope.com
* herstellerübergreifende Datenbank mit technischen Informationen zu Z-Wave-Geräten (Z-Wave Device Library): http://www.pepper1.net/zwavedb/
* Z-Wave-Produktdatenbank mit Angabe zur Zertifizierung (Z-Wave oder [http://z-wavealliance.org/z-wave_plus_certification Z-Wave Plus]): http://products.z-wavealliance.org
* informative Webseiten zu Z-Wave:
** [http://www.z-wavealliance.org/ http://www.z-wavealliance.org/], englisch
** [http://www.zwaveeurope.com/ http://www.zwaveeurope.com/], englisch
** [http://www.zwave.de/ http://www.zwave.de/], deutsch
** [http://library.ademconet.com/MWT/fs2/VAM/Introductory-Guide-to-Z-Wave-Technology.PDF Introductory Guide to Z-Wave-Technology von Honeywell], englisch
=== Informationsquellen zur Einbindung von Command Classes ===
Offizielle und ausführliche Informationen von Sigma Designs (veröffentlicht am 31.08.2016):
* [http://z-wave.sigmadesigns.com/design-z-wave/z-wave-public-specification/ Z-Wave Public Specification]

Weitere Informationen (seit Veröffentlichung der Z-Wave Spezifikationen am 31.08.2016 geringe Relevanz)
* [https://github.com/yepher/RaZBerry Infos zu Command Classes (ausführlich; insbesondere im Verzeichnis "docs"), RaZBerry und Z-Wave allgemein], englisch
* [http://220.135.186.178/zwave/example/ Übersicht von Command Classes und deren Rückgabewerten mit Unterscheidung der Class-Versionen], englisch
* Code von http://www.openzwave.org (https://github.com/OpenZWave/open-zwave) und http://www.openhab.org (Z-Wave binding: https://github.com/cdjackson/openhab)
* eine Java-API-Beschreibung mit Hinweisen zu Unterschieden von Class-Versionen: http://dz.prosyst.com/pdoc/mBS_SH_SDK_8.1/modules/zwave/api/driver/index.html

== FAQ ==
=== Welche Infos sollten Anfragen im ZWave-Forum enthalten? ===
* Anfragen bitte nur zur aktuellsten FHEM-Version: Befehl <code>update</code> ergibt Ausgabe "nothing to do..."
* detaillierte Beschreibung des Problems
* beteiligte Komponenten (genaue Bezeichnung und evtl. Link auf Hersteller-Dokumentation)
* list des jeweiligen FHEM-Devices (<code>list <device></code>)
::Bitte vor Aufruf des list-Befehls -wenn vorhanden/möglich- folgende Befehle ausführen:
::*<code>get <device> associationAll</code>
::*<code>get <device> configAll</code>
::*<code>get <device> versionClassAll</code>
::*<code>get <device> wakeupInterval</code> (nur bei batteriebetriebenen Geräten)
* passender Ausschnitt aus dem Logfile (siehe Link im FHEM-Menü links) generiert mit den gesetzten Attributen
::*<code>attr <ZWDongle> verbose 5</code> und
::*<code>attr global mseclog 1</code>

=== Welche Schritte sind für die Einbindung von ZWave-Geräten in Fhem mindestens durchzuführen? ===
Voraussetzung: ZWave-Gateway ist erfolgreich eingebunden!
# [[#Hinzufügen eines neuen Z-Wave Geräts / Inklusion|Inklusion]] des Gerätes
# [[#Assoziation|Assoziation]] der Assoziationsgruppe(n) des Gerätes mit dem Gateway
# [[#Konfiguration|Konfiguration]] des Gerätes

=== Warum bleibt der Status (STATE) des neu inkludierten Gerätes dauerhaft auf "associationAdd <associationGroup> <CtrlNodeId>" stehen? ===
FHEM setzt das Reading "state", das den STATE bestimmt, nicht bei allen ZWave-Devices mit vordefinierten Standardwerten. Daher bleibt der bei der Inklusion automatisch abgesetzte "associationAdd"-Befehl unter Umständen im STATE stehen, bis der Anwender den STATE über die Vergabe des Attributes <code>[http://fhem.de/commandref#stateFormat stateFormat]</code> manuell an seine Bedürfnisse angepasst hat.
(weitergehende Info zum state/STATE/stateFormat: [[DevelopmentState]])

=== Wie können bei mehrkanaligen Aktoren die zusätzlichen Kanäle (>1) angesprochen werden? ===
* Bei der [[#Hinzufügen eines neuen Z-Wave Geräts / Inklusion|Inklusion]] des Gerätes wird das Hauptdevice mit dem Namen <code><nowiki>ZWave_<Geräteklasse laut NIF des Gerätes>_<NodeID></nowiki></code> und die Devices für alle Kanäle (Endpoints) nach dem Namensschema <code><nowiki>ZWave_<Geräteklasse laut NIF des Gerätes>_<NodeID>.<EndpointNr></nowiki></code> automatisch angelegt. Jedes dieser FHEM-Devices spricht regelmäßig einen bestimmten Kanal des Gerätes an; einige Geräte sprechen mit dem Hauptdevice jedoch das gesamte Gerät mit allen Kanälen an (Bedienungsanleitung beachten).
* Manuell werden Devices für zusätzliche Kanäle mit Hilfe der Befehle <code>get <device> mcEndpoints</code> und <code>get <device> mcCapability <chid></code> aus der Class MULTI_CHANNEL ermittelt bzw. einzeln über autocreate angelegt (Details und Beispiel siehe [http://fhem.de/commandref.html#ZWaveget commandref]). Mit dem Befehl <code>set <device> mcCreateAll</code> werden automatisch alle Kanäle des Gerätes durch autocreate als eigene Devices in FHEM angelegt.

=== Wie kann man die SDK-Version eines Gerätes herausfinden? ===
Mit FHEM alleine kann eine [[#Grobermittlung|Grobermittlung]] der SDK-Version vorgenommen werden, die aber für einige Zwecke bereits ausreichend ist. Soll eine [[#Detailermittlung|Detailermittlung]] der genauen SDK-Version erfolgen, dann müssen die mit FHEM ermittelten Werte anhand externer Quellen übersetzt werden.
==== Grobermittlung ====
Der Befehl <code><nowiki>get <ZWDongle> nodeInfo <dezimale nodeId></nowiki></code> liefert das Reading <code><nowiki>nodeInfo_<dezimale nodeId></nowiki></code> zurück.
Die Angabe im Reading hinter <code>ProtocolVers:</code> lässt grobe Rückschlüsse zu. Mögliche (bekannte) Werte:
* <code>2</code> -> bspw. keine Explorer Frames, keine SUC-Unterstützung (veraltet, keine bekannten Geräte mehr im Handel)
* <code>SDK5.0x+4.2x</code> -> bspw. keine Explorer Frames, teilweise SUC-Unterstützung
* <code>SDK4.5x+6.0x</code> -> bspw. Explorer Frames- und SUC-Unterstützung (Reading-Wert wird auch bei SDK 6.5x = Z-Wave Plus angezeigt)
==== Detailermittlung ====
Durch den Befehl <code><nowiki>get <name> version</nowiki></code> kann man die ZWave-Protokoll-Version von Geräten und Controller abfragen. Mit Unterstützung von Übersetzungstabellen
* http://wiki.micasaverde.com/index.php/ZWave_Protocol_Version
* Suche nach sdkids.xml in einer Suchmaschine
kann aus der Protokoll-Version das genutzte SDK festgestellt werden.

Beispielsweis entspricht das Reading eines Gerätes "Lib 6 '''Prot 2.64''' App 1.6" dem SDK 5.02 Patch 2 oder eines Controller "Z-Wave '''3.41''' STATIC_CONTROLLER" dem SDK 6.02.00.

HINWEIS: Bei der Vergabe der Protokoll-Version und zugehörigem SDK gibt es keine erkennbare Logik: Eine höhere Protokoll-Version steht nicht notwendig für eine höheres SDK.

=== Wie kann eine verschlüsselte Kommunikation unter Nutzung der Command Class SECURITY eingerichtet werden? ===
Die verschlüsselte Kommunikation zwischen Controller und Endgerät setzt eine secure-Inklusion voraus. Bereits mit der Inklusion wird entschieden, ob die Kommunikation von Controller und Endgerät dauerhaft verschlüsselt oder unverschlüsselt erfolgt. Ist ein Gerät bereits normal inkludiert und entscheidet man sich nachträglich für eine verschlüsselte Kommunikation, so ist das nur möglich, indem das Gerät exkludiert und dann wieder secure inkludiert wird.

Ob die Verschlüsselung bei einem Gerät mit Unterstützung der Command Class SECURITY genutzt werden soll, sollte genau überlegt werden. Die Verschlüsselung führt zu einem deutlich größeren Funkverkehr zur Ausführung eines Befehls und teilweise auch zu spürbaren Latenzen.

Vorarbeiten:
* Das Perl-Modul Crypt-Rijndael muss installiert sein.
* Das Attribut <code>networkKey</code> muss mit einem 32-Zeichen langen Hexzahl beim ZWDongle angelegt werden. Dieser Schlüssel sollte nicht veröffentlicht werden und auch zusätzlich separat (bspw. auf Papier) festgehalten werden. Bei Verlust des Attributes und Schlüssels ist eine Kommunikation nur nach erneuter Inklusion möglich.

Ablauf der secure-Inklusion:
* Controller in den Modus zur secure-Inklusion schalten:
: <code>set <ZWDongle> addNode onSec</code> für die Standard-secure-Inklusion
: oder alternativ
: <code>set <ZWDongle> addNode onNwSec</code> für die Nework-Wide-secure-Inklusion
* Gerät gemäß Handbuch in den Modus zur secure-Inklusion bringen (teilweise ist jeweils für secure- und normale Inklusion ein anderes Vorgehen notwendig!)
* Das Gerät sollte jetzt automatisch erkannt und das FHEM-Device durch <code>autocreate</code> angelegt werden. Die secure-inkludierten Geräte haben ein zusätzliches Attribut <code>secure_classes</code> in dem die Command Classes deren Kommunikation verschlüsselt abläuft aufgelistet sind. Nicht in diesem Attribut, aber in <code>classes</code> aufgeführte Command Classes wickeln die Kommunikation weiterhin unverschlüsslt ab.
* Inklusionsmodus des Controllers ausschalten:
: <code>set <ZWdongle> addnode off</code>
* Das Vorgehen in FHEM unterscheidet sich von nun an nicht von normal (unverschlüsselt) inkludierten Geräten. Die Verschlüsselung läuft für den Anwender transparent ab. Darum anschließend [[#Assoziation|Assoziation]] und [[#Konfiguration|Konfiguration]] vornehmen.

=== Wie kann man ohne Exklusion Nodes des Controllers löschen? ===
HINWEIS: Geräte sollten grundsätzlich immer über eine Exklusion aus der Nodelist des Controllers gelöscht werden. Das nachfolgend geschilderte Vorgehen ist nur in Sonderfällen (bspw. Gerätedefekt, gebraucht gekauftes Gateway) anzuwenden.

Nicht mehr zu erreichende/reagierende Nodes (Geräte) können manuell mit dem Befehl <code>removeFailedNode</code> gelöscht werden. Dazu muss sich der betroffene Node auf der FailedNodeList des Controllers befinden. Auf die FailedNodeList kommen netzbetriebene Geräte automatisch, wenn sie vom Controller nicht mehr per Funk erreicht werden. Batteriebetriebene Geräte müssen manuell auf die FailedNodelist gesetzt werden, da der Controller nicht feststellen kann, ob sie nur langfristig "schlafen".

Der Befehl <code>removeFailedNode</code> löscht nur Nodes auf der FailedNodeList, die erst vor Kurzem nicht erreicht werden konnten. Darum muss sowohl das manuelle Verschieben von batteriebetriebenen als auch das Nicht-Erreichen der netzbetriebenen Geräte erst Kurz vor Aufruf des <code>removeFailedNode</code>-Befehls erfolgt sein.

Vorgehensweise für den Node <NodeId>:
# An den betroffenen Node eine Telegramm mit <code><nowiki>set <ZWDongle> sendNIF <NodeId></nowiki></code> verschicken, um ihn auf FailedNodeList zu verschieben bzw. Zeitstempel zu aktualisieren.
# Abfragen, ob der Node auf der FailedNodeList steht: <code><nowiki>get <ZWDongle> isFailedNode <NodeId></nowiki></code>. Wenn der Rückgabewert der Abfrage "yes" ist, steht der Node korrekt auf der FailedNodeList und kann mit <code>removeFailedNode</code> gelöscht werden.
# Befehl zum Löschen des Nodes absetzen: <code><nowiki>set <ZWDongle> removeFailedNode <NodeId></nowiki></code>. Der Befehl testet vor dem Löschen noch einmal, dass der Node nicht erreicht werden kann und entfernt erst dann den Node.
# Prüfen, der Ergebnisse des <code>removeFailedNode</code>-Befehls im Log oder [[Event monitor]]. Die verschiedenen Ergebnisse werden durch die in der commandref dokumentierten Events signalisiert. Tritt das Ergebnis "failedNodeRemoveProcessBusy" mehrfach hintereinander auf, muss das ZWDongle kurz stromlos gemacht werden.
# Prüfen, ob der Node nicht mehr auf der Nodelist des Controllers ist: <code><nowiki>get <ZWDongle> nodeList</nowiki></code>

siehe auch {{Link2Forum|Topic=32823|Message=292626}}

=== Wie ist der einfachste Weg ein (defektes) Gerät durch ein gleiches Ersatzgerät auszutauschen? ===
Tauscht man ein defektes Gerät durch ein gleiches Ersatzgerät und inkludiert das Ersatzgerät per <code>addNode</code>, so erhält das Ersatzgerät eine neue NodeId. Soll das Ersatzgerät die gleiche NodeId wie das alte Gerät erhalten, so muss statt <code>addNode</code> der Befehl <code>replaceFailedNode</code> zur Inklusion des Ersatzgerätes (=gleiches Modell) verwendet werden.

Vorgehensweise für den Node <NodeId>:
# sofern das alte Gerät noch ansprechbar ist, die Konfiguration und Assoziationen abfragen, damit man die Werte im Ersatzgerät einfach wieder setzen kann:
## <code><nowiki>get <device> configAll</nowiki></code>
## <code><nowiki>get <device> associationAll</nowiki></code>
# defektes Gerät aus- und neues einbauen
# Befehl <code><nowiki>set <ZWDongle> sendNIF <NodeId></nowiki></code> absetzen, damit das Dongle die NodeId auf die FailedNodeList setzt.
# Abfragen, ob der Node auf der FailedNodeList steht: <code><nowiki>get <ZWDongle> isFailedNode <NodeId></nowiki></code>. Wenn der Rückgabewert der Abfrage "yes" ist, steht der Node korrekt auf der FailedNodeList und das Ersatzgerät kann mit <code>replaceFailedNode</code> inkludiert werden.
# <code><nowiki>set <zwdongle> replaceFailedNode <NodeId></nowiki></code> für die NodeId des defekten Gerätes aufrufen und das Ersatzgerät in den Inklusionsmodus bringen
# Korrekte Inklusion prüfen und beim alten Aktor ausgelesene Werte beim neuen Aktor wieder setzen.

=== Bei einer Inklusion wird eine durch Exklusion/removeFailedNode frei gewordenen NodeId nicht mehr vergeben. Ist das korrekt? ===
Ja, das ist richtig.

Bei der Inklusion über addNode vergibt der Controller die höchste bisher noch nie verwendete NodeID. Durch Exklusion oder removeFailedNode frei gewordene NodeIDs werden hierbei nicht erneut vergeben. Nur bei einem Controller-Reset, der mit einem unwiederbringlichen Verlust sämtlicher Informationen des ZWave-Netzes und Neuvergabe der HomeID verbunden ist, beginnt die Zählung wieder von vorne.

=== Welche Funktion haben die XML-Config-Dateien in Fhem? ===
In den XML-Config-Dateien sind Informationen zu einzelnen ZWave-Geräten enthalten, die der Erleichterung der Gerätenutzung und -einbindung in FHEM dienen. Dies sind unter anderem Erläuterungen zu den Parameternummer/-werten, Assoziationsgruppen und Besonderheiten eines Gerätes. Ob eine zum Zwave-Gerät passende XML-Config Datei existiert, wird im Rahmen der Inklusion oder durch manuellen Aufruf des Befehls <code>get <name> model</code> ermittelt. Wird eine passende XML-Config-Datei gefunden, wird sie automatisch in FHEM eingebunden. Das Reading <code>modelConfig</code> enthält dann den zugehörigen XML-Config-Dateinamen. Stehen keine XML-Config-Informationen bereit, enthält das Reading <code>modelConfig</code> den Wert "unknown". Die Funktionsfähigkeit von FHEM mit ZWave-Geräten ist auch bei fehlender XML-Config-Datei gegeben. Es gibt dadurch keine funktionalen Einschränkungen in FHEM; es entfallen "nur" Erleichterungen und es sind unter Umständen mehr manuelle Schritte bei der Gerätenutzung/-einbindung notwendig.

Erleichterungen bei vorhandener XML-Config für ein ZWave-Gerät:
* Bei der Inklusion:
** Assoziationen mit dem Controller bei von Gruppe 1 abweichenender Assoziationsgruppe werden automatisch gesetzt
** vom NIF nicht gemeldete, aber vom Gerät unterstützte Classes, werden im Attribut <code>classes</code> ergänzt
* Bei der Konfiguration:
** die Parameternummern stehen als configXY-Befehle zur Verfügung und werden mit Hilfetexten -auch zu den Parmaeterwerten- in der Detailansicht des FHEM-Device erläutert.

HINWEIS: Bitte auch bei vorhandener XML-Config-Datei nach der Inklusion und bei der Konfiguration die Assoziationen und Parameter prüfen. Von den eigenen Vorstellungen abweichende Vorgaben oder gar Fehler in der Config-Datei können nie ausgeschlossen werden. Fehler bitte im Forum ({{Link2Forum|Area=ZWave}}) melden.

=== Wie können fehlende XML-Config-Informationen für mein ZWave-Gerät in Fhem eingebunden werden? ===
Die XML-Config-Informationen von FHEM sind in folgenden Dateien im Ordner fhem/FHEM/lib gespeichert:
* openzwave_manufacturer_specific.xml
* openzwave_deviceconfig.xml.gz
* fhem_zwave_deviceconfig.xml.gz
Die in den Dateien enthaltenen Informationen beruhen in großen Teilen auf Daten von openzwave und übernehmen daher das openzwave-Datenformat, das unter https://github.com/OpenZWave/open-zwave/wiki/Adding-Devices näher beschrieben wird.

Die Datei "openzwave_manufacturer_specific.xml" enthält die eindeutige Kennung des ZWave-Gerätes, die in FHEM nach Aufruf des Befehls <code>get <name> model</code> im Reading <code>modelId</code> des FHEM-ZWave-Devices steht. Weiterhin wird der Klartextname dieses Gerätes, der im Reading <code>model</code> angezeigt werden soll, festgelegt. Zudem wird der Dateiname der eigentlichen XML-Config-Datei für das ZWave-Gerät angegeben, der später informativ im Reading <code>modelConfig</code> steht.

Die Dateien "openzwave_deviceconfig.xml.gz" und "fhem_zwave_deviceconfig.xml.gz" enthalten in komprimierter Form die eigentlichen XML-Config-Dateien für die ZWave-Geräte. FHEM durchsucht beide Dateien nach der passenden XML-Config-Datei. Ist in beiden Dateien eine XML-Config für ein Gerät vorhanden, so werden die XML-Daten aus der "fhem_zwave_deviceconfig.xml.gz" bevorzugt. Aufbau und Struktur einer einzelnen XML-Config-Datei ist der oben verlinkten Seite bei openzwave zu entnehmen.

Prüfschritte und Vorgehensweise:
* Gerät ist auf https://github.com/OpenZWave/open-zwave/tree/master/config oder https://github.com/jeedom/plugin-openzwave/tree/master/ressources/openzwave/config in manufacturer_specific.xml und dem herstellerspezifischen Unterordner bereits vorhanden, aber steht in FHEM nicht zur Verfügung: Hinweis mit Link im Forum ({{Link2Forum|Area=ZWave}}), dass die XML-Config-Dateien in FHEM aktualisiert werden sollen.
* Andernfalls: Entsprechend https://github.com/OpenZWave/open-zwave/wiki/Adding-Devices die XML-Config-Datei für das Gerät erstellen und unkomprimiert zusammen mit der zu ergänzenden Info für die Datei "openzwave_manufacturer_specific.xml" im Forum ({{Link2Forum|Area=ZWave}}) zur Verfügung stellen.

=== Wie führt man eine Komplett-Sicherung der ZWave-Installation durch? ===
Zu einer Komplett-Sicherung der ZWave-Konfiguration gehören:

1. [[Backup]] der FHEM-Installation
::'''und'''
2. Backup des NVRAM des Controllers

Es genügt nicht nur die FHEM-Installation/Konfiguration zu sichern, da der Controller im NVRAM Daten über HomeID, NodeIDs usw. speichert, die in der FHEM-Installation nicht enthalten sind und auch nicht durch FHEM rekonstruierbar sind.

zu 2.) Backup des NVRAM des Controllers

Einige Controllerhersteller bieten eine eigenständige Software zum Backup/Restore an (siehe Hinweise zu den Controllern unter [[#Autocreate_des_Gateways]]).

FHEM kann mit den ZWDongle-Befehlen <code>backupCreate</code> das NVRAM der Controller sichern und mit <code>backupRestore</code> zurückschreiben. Da das Speicherlayout des NVRAM unter anderem von Controller-Hersteller, SDK und Firmwareversion abhängig sein kann, sollte man die Sicherung und Wiederherstellung des eigenen Controllers (auf eigenes Risiko) testen und sinnvollerweise einen gleichen Ersatzcontroller wie den Controller des Produktivsystem besitzen. Erfolgreiche Sicherung/Wiederherstellung wurde im Forum von den ZWavePlus-Controllern UZB1 (256k), Razberry (256k), Vision ZU 1401-5 EU (128k)und AEOTEC Z-Stick Gen5 (256k) berichtet.
(Weitergehende Infos -neben der commandref- im Forum: {{Link2Forum|Topic=52364}}, {{Link2Forum|Topic=52914}}, {{Link2Forum|Topic=53023}})

=== Wie kann ich zur Fortentwicklung der ZWave-Module beitragen? ===
* Erfolgreichen Einsatz von neuen/bisher nicht gemeldeten ZWave-Geräten im Forum mitteilen
* Codeschnipsel und Ideen im Forum posten
* Fehler und Probleme im Forum melden
* [[How_to_write_a_patch|Patches]] für 00_ZWDongle.pm und 10_ZWave.pm erstellen
* Wiki: Ergänzungen und Korrekturen vornehmen; neue Geräte ins Wiki aufnehmen; Codeschnipsel und Beispiele einpflegen

=== Wie wird ein fehlendes Kernelmodul (Fritzbox) eingebunden? ===
Auf der Fritzbox (und evtl. auch anderen Systemen) muss sichergestellt werden, dass das Kernelmodul für das Gateway geladen wird. Ansonsten scheitert die Einbindung des Gateways in FHEM.

Für den Aeon Labs Z-Stick muss beispielsweise auf der Fritzbox das Kernelmodul <code>cp2101.ko</code> geladen werden.
Diese Datei ist bei einer [[FHEM und FritzBox 7390]] Installation über das Image von [http://www.fhem.de fhem.de] bereits enthalten.
Um den Aeon Labs Z-Stick zu verwenden, muss dieses Kernelmodul vor oder beim Starten des FHEM-Servers geladen sein. Dies erreicht man durch einen Eintrag in der Datei <code>startfhem</code>.

Die entsprechende Zeile kann direkt unterhalb der modprobe Anweisungen eingefügt werden.
insmod $home/lib/cp2101.ko

Nach einem FHEM-Neustart sollte das Gateway (der USB Stick) nun erkannt werden.

[[Kategorie:HOWTOS]]
[[Kategorie:Z-Wave Components]]

Anwesenheitserkennung

2017-01-03T09:57:19Z

LordVoodoo: /* Beispiele für die Nutzung der Anwesenheitserkennung */

Viele Benutzer führen bereits eine eigene '''Anwesenheitserkennung''' durch. Diese basiert in den meisten Fällen auf Ping Checks oder bei [[AVM Fritz!Box|FritzBoxen]] auf dem Befehl ''ctlmgr_ctl''. Diese Lösungen können aber je nach Aufbau und Funktion FHEM massiv beeinträchtigen. Aufgrund des Aufbaus vom FHEM kann dieses dadurch für mehrere Sekunden zum völligen Stillstand gebracht werden.

In FHEM gibt es mittlerweile mehrere Module, die eine zuverlässige Anwesenheitserkennung bieten, ohne dabei FHEM bei der Ausführung zu beeinträchtigen.

Eine erweiterte Funktion der Anwesenheitserkennung ist die Standortverfolgung, die sich nicht nur auf ein oder sehr wenige mit (eigenem) WLAN versorgte Gebiete beschränkt.

== Vorüberlegungen ==
Generell gibt es mehrere Ansätze um Anwesenheitserkennung mit Handys/Smartphones durchzuführen.

* via PING Checks im gesamten WLAN
* Aktivitätsprüfung auf einer FritzBox
* Bluetooth Checks in der gesamten Wohnung
* eigene Perl-Funktion
* aktive Benachrichtigung des Smartphones, ausgelöst z.B. über Geo-Lokation/Geofence

Dabei gilt bei der Auswahl der Art darauf zu achten wie sich das jeweilige Device verhält. Aufgrund der Vielfältigkeit kann man hier keine allgemeine Vorgehensweise empfehlen. Als einfacher Start (zumindest für Nicht-Apfel Telefone) eignet sich die Ping-Überprüfung und die FritzBox-Abfrage sehr gut.

=== Randbedingungen ===
Es gibt Geräte, die ihr WLAN/Bluetooth auch im Standby ständig aktiv haben und auf Anfragen antworten können (fast alle Android-Geräte). Gerade bei Tests über WLAN kann sich das aber signifikant auf die Akku Leistung auswirken.

Andere Geräte wiederum schalten WLAN im Standby Betrieb aus, um Akkukapazität zu sparen. Bluetooth hingegen bleibt weiterhin aktiviert und kann auf Anfragen reagieren. (iPhone)

Wenn man bei einem iPhone die Funktion "über WLAN synchronisieren" aktiviert hat, so ist dies auch im Standby jederzeit pingbar, wenn der Recher auf dem iTunes zum synchroniseren läuft auch an ist. Ansonsten ist bei iPhone Geräten nur die Aktivitätsprüfung mit einer FritzBox oder das überwachen der DHCP Lease auf einer Airport Basestation wirklich zuverlässig.

Auch wenn Bluetooth aktiviert ist, so bleiben einige Mobiltelefone erst dann empfangsbereit, wenn sie bereits zu irgend einem Bluetoothgerät gekoppelt wurden. Sind diese Geräte noch nie gekoppelt worden, deaktivieren diese ihren Bluetooth Empfänger beim verlassen des Bluetooth-Menüs im Gerät (iPhone).

Hier gilt es vor allem auszuprobieren, wie stark der Akku durch eine Anwesenheitserkennung belastet wird. Entscheidend ist hier, in welchem Abstand man eine Anwesenheitserkennung durchführt. Viele Abfragen wirken sich stärker auf den Akku aus als wenige. Wenige Abfragen bieten aber keine zuverlässige und zeitnahe Erkennung.

Als Alternative, unabhängig vom WLAN und der Erkennung, ob ein Gerät dort eingebucht ist oder nicht, bzw. unabhängig von Bluetooth kann zumindest bei einem iPhone die seit iOS 7 nochmals stark verbesserte Geo-Lokation (Geofencing) genutzt werden. Die iPhone Apps [http://geofency.com/ Geofency] oder [http://geofancy.com/ Geofancy] werden über das FHEM-Modul GEOFANCY angebunden und übertragen ihren Status immer dann, wenn ein definierter Standort betreten oder verlassen wird. Gekoppelt mit entsprechenden Notify und/oder Watchdog Kommandos ist so ebenfalls eine sehr zuverlässige Anwesenheitserkennung möglich (und das nicht nur für das eigene Zuhause).

== Das PRESENCE Modul ==
Das [[PRESENCE]] Modul bietet für die Anwesenheitserkennung mehrere Varianten an. Diese sind aktuell folgende:

* '''lan-ping''' - Das Überwachen via PING Checks, die durch den FHEM Server versandt werden.
* '''fritzbox''' - Das Überwachen von Geräten auf einer FritzBox via ctlmgr_ctl (Nur auf einer FritzBox möglich)
* '''local-bluetooth''' - Das Überwachen via Bluetooth Checks, die vom FHEM Server direkt durchgeführt werden (angeschlossener Bluetooth-Stick und die Software bluez voraussgesetzt)
* '''lan-bluetooth''' - Das Überwachen von Bluetoothgeräte, über Netzwerk. Auf einer oder mehreren Maschinen im Netzwerk (z.B. [[:Kategorie:Raspberry Pi|Raspberry Pi]]) läuft ein Presence-Daemon, der nach Bluetooth-Geräten sucht. Um mehrere Presence-Daemon mit FHEM zu verbinden, gibt es den Collector-Daemon, der sich zu allen Presence-Damons im Netzwerk verbindet und das Ergebnis von allen zusammenfasst.
* '''function''' - Das Überwachen mithilfe einer selbst geschrieben Perl-Funktion, die den Anwesenheitsstatus zurückgibt (0 oder 1)
* '''shell-script''' - Das Überwachen mithilfe eines selbst geschriebenen Shell-Programms/Skript, das eine 0 oder 1 ausgibt, um den Anwesenheitsstatus mitzuteilen.

=== Ping-Überwachung von Geräten im WLAN/LAN ===
{{Randnotiz|RNText=Um diese Methode auf einer FritzBox nutzen zu können, muss FHEM mit root-Rechten laufen. Dies ist standardmäßig nicht der Fall. Bitte dazu den Wiki Artikel [[FritzBox: fhem unter root starten]] beachten.}}
Um ein Gerät via Ping zu überwachen, muss folgende Definition durchgeführt werden:
:<code>define Handy PRESENCE lan-ping 192.168.0.30</code>

Dadurch wird die IP-Addresse 192.168.0.30 alle 30 Sekunden geprüft, ob sie erreichbar ist. Wenn sie erreichbar ist, ist der Status "present" (anwesend), ansonsten "absent" (abwesend).

Der Timeout kann verändert werden, indem ein Wert (in Sekunden) an das Define anhängt wird:
:<code>define Handy PRESENCE lan-ping 192.168.0.30 '''60'''</code>

Nun würde das Handy alle 60 Sekunden geprüft werden.

Nur wenn bei einem iPhone/iPad die Funktion "über WLAN synchronisieren" aktiviert ist, ist es auch im Standby zuverlässig pingbar. Standardmäßig deaktivieren Apple-Geräte ihr WLAN im Standby-Betrieb um die Akkulaufzeit zu verlängern.

Sollte die Fehlermeldung
:<code> PRESENCE (Handy) - ping command returned with output: ping: icmp open socket: Operation not permitted </code>
im Log auftauchen und lan-ping dadurch nicht funktionieren, liegt ein Berechtigungsproblem vor. Kein Grund den User fhem zu root zu machen!
So sollten die Berechtigungen aussehen
:<code>sudo ls -la /bin/ping</code>
unter Jessie
:<code>-rwxr-xr-x 1 root root 38844 Feb 12 2014 /bin/ping</code>
unter Wheezy
:<code>-rwsr-xr-x 1 root root 33220 Mär 30 2012 /bin/ping</code>
Sollte es trotzdem unter Jessie nicht funktionieren kann man auch dort die Berechtigung analog wheezy setzen:
:<code>sudo chmod u+s /bin/ping</code>

=== FritzBox: direktes Abfragen der Aktivität via ctlmgr_ctl ===
{{Randnotiz|RNText=Um diese Methode auf einer FritzBox nutzen zu können, muss FHEM mit root-Rechten laufen. Dies ist standardmäßig nicht der Fall. Bitte dazu den Wiki Artikel [[FritzBox: fhem unter root starten]] beachten.}}
Eine sehr häufige und auch zuverlässige Methode ist auf einer FritzBox die Abfrage mittels ctlmgr_ctl Befehl. Über diesen lassen sich alle Geräte abfragen ob sie aktiv sind. Ist ein Gerät aktiv, so gilt es als anwesend.

Dieser Modus kann allerdings nur in FHEM Installationen direkt auf einer FritzBox verwendet werden. Des weiteren muss FHEM unter dem User root laufen. Um ein Gerät zu überwachen, wird lediglich der Gerätename benötigt, so wie er unter dem Menüpunkt "Heimnetz" auftaucht.

Die erforderliche Definition:
:<code>define Handy PRESENCE fritzbox iPhone-4S</code>

=== Bluetooth-Überwachung von Geräten durch den FHEM Server ===
[[Datei:Bluetooth-Adresse-iPhone.png|thumb|Bluetooth-Adresse eines iPhones]]
Jenach Aufstellungsort des FHEM Servers kann es sinnvoll sein, eine Bluetooth-Überwachung direkt durch den FHEM Server durchzuführen. Hierbei gilt allerdings zu beachten, dass Bluetooth nicht für große Reichweiten gedacht ist und in den meisten Fällen keine Wände überwinden kann. Das heisst, dass in den meisten Fällen damit nur ein Raum überwacht werden kann.

Je nach Einsatzzweck kann das auch so gewollt sein. Bluetooth USB Sticks, die bereits Bluetooth 4.0 unterstützen, können höhere Reichweiten über Zimmerwände hinaus erreichen. Vorausgesetzt, das Mobilgerät unterstützt Bluetooth 4.0.

Um eine Überwachung per Bluetooth durchführen zu können, benötigt man die Bluetooth-Adresse eines Gerätes. Diese ähnelt vom Aufbau einer MAC-Adresse. Generell wird die Adresse in den Telefon-Informationen bei Smartphones angezeigt.

Um eine Anwesenheitserkennung via Bluetooth durchzuführen, wird folgende Definition in der [[Konfiguration]] benötigt:
:<code>define Handy PRESENCE local-bluetooth XX:XX:XX:XX:XX:XX</code>

=== Bluetooth-Überwachung von Geräten durch verteilte Agenten in der Wohnung (presencd/collectord) ===
[[Datei:Raspberry-Pi-mit-WLAN-und-Bluetooth-Stick.jpg|thumb|left|Raspberry Pi mit Bluetooth- und WLAN-USB-Stick]]
Um eine zuverlässige und flächendeckende Bluetooth-Anwesenheitserkennung durchzuführen, ist es unerlässlich, mehrere Bluetooth-Empfänger zu verwenden, die auf mehrere oder alle Räume verteilt sind.

Hierfür bietet sich zum Beispiel ein [[Raspberry Pi]] mit einem Mini-Bluetooth-USB-Stick und evtl. einem WLAN-USB-Stick an. Jeder Raum wird mit solch einem Raspberry ausgestattet und ist im WLAN Netz verfügbar.

Dieses Netz aus Raspberrys wird mit dem presenced (Download-Link ist in der [http://fhem.de/commandref_DE.html#PRESENCE Commandref] zum Modul enthalten) ausgestattet. Es stehen bereits entsprechende Pakete für den Raspberry zur Verfügung.

Beide Programme (presenced/collectord) sind Perl-Skripte, die als Daemon im Hintergrund laufen und auf Anfragen via Netzwerk warten. Es wird lediglich eine vollständige Perl-Grundinstallation mit Standardmodulen benötigt. Nach Installation der *.deb Pakete sollten diese noch angewiesen werden, automatisch beim Rechner-Neustart gestartet zu werden:

<pre>
sudo update-rc.d presenced defaults
sudo update-rc.d collectord defaults
</pre>

Eine detaillierte Benutzung von presenced ist in der [http://fhem.de/commandref_DE.html#PRESENCE Commandref] Beschreibung zum PRESENCE Modul enthalten.

==== Jeden Raum einzeln ansprechen (presenced) ====
Nun kann zuallererst jeder Raum einzeln angesprochen werden. Dabei ist zu beachten, dass pro Definition in der Konfiguration nur ein Gerät in einem Raum spezifisch überwacht werden kann.

Eine Definition sieht dabei folgendermaßen aus:
:<code>define Handy_Wohnzimmer PRESENCE lan-bluetooth XX:XX:XX:XX:XX:XX 192.168.0.10:5111</code>

Damit wird nun das Gerät nur im Wohnzimmer (Raspberry mit IP 192.168.0.10) überwacht.

==== Alle Räume gemeinsam ansprechen (collectord) ====
Um jedoch alle Räume gemeinsam zu verwenden, gibt es den Collector-Daemon. Dieser kennt alle presenced-Installationen im Netzwerk und führt eine koordinierte Suche nach den gewünschten Geräten durch. Sobald ein Gerät in einem Raum erkannt wurde, meldet der collectord den Status einschließlich der Angabe des Raumes, in dem das Gerät erkannt wurde.

Um alle Räume zu kennen, müssen diese mit einem Config-File dem collectord mitgeteilt werden. Dieses sieht folgendermaßen aus:

<pre>
[Schlafzimmer] # Name des Raumes (wird in FHEM als Reading angezeigt)
address=192.168.179.31 # IP-Adresse oder Hostname des presenced
port=5111 # TCP Port, der verwendet werden soll (standardmäßig Port 5111)
presence_timeout=120 # Prüfinterval, das verwendet werden soll, wenn ein Gerät anwesend ist
absence_timeout=20 # Prüfinterval, das verwendet werden soll, wenn ein Gerät abwesend ist

[Wohnzimmer]
address=192.168.179.34
port=5111
presence_timeout=180
absence_timeout=20
</pre>

Standardmäßig ist dieses Config-File unter /etc/collectord.conf zu finden. Mit dieser Konfiguration kann der Collectord gestartet werden. Es empfiehlt sich diesen mit auf dem FHEM Server zu betreiben. Die erforderliche Definition in der Fhem-Konfiguration:
:<code>define Handy PRESENCE lan-bluetooth XX:XX:XX:XX:XX:XX 127.0.0.1:5222</code>

Sobald das Handy irgendwo in der Wohnung erkannt wurde, meldet der Collectord dies sofort an FHEM und teilt den Raum mit.

Eine detaillierte Benutzung von collectord findet man in der [http://fhem.de/commandref.html#PRESENCE Commandref zum PRESENCE Modul].

=== Überwachung von Geräten mit Perl-Code ===
Es ist möglich zum Überwachen von Geräten eine eigene Perl-Funktion zu verwenden die dann vom PRESENCE Modul im Hintergrund aufgerufen wird.

define <name> PRESENCE function {...} [ <check-interval> [ <present-check-interval> ] ]

Sobald die Funktion den Rückgabewert 1 hat, ist das Gerät anwesend, bei 0 abwesend.

==== Beispiel DHCP Überwachung auf Airport Basestation ====
Die hier vorgestellte Überwachung der DHCP Lease auf Airport Basestations per SNMP ist absolut robust gegenüber dem Ruhezustand von iOS und setzt keine weitere Konfiguration auf dem iPhone voraus. Das Abmelden beim Verlassen des Empfangsbereiches der Basestation geschieht mit etwa 5-10 Minuten Verzögerung und ist somit auch vor kurzzeitigen Empfangsproblemen sicher. Das nebenstehende Bild (???) verdeutlicht noch mal die Unterschiede zwischen einer IP-Basierten Ping-Überwachung und der Überwachung auf Ebene der Basestation oder FritzBox.

Bevor der folgende Code verwendet werden kann ist das Perl Modul Net:SNMP zu installieren (z. B. mit: <code>cpan install use Net::SNMP</code>).

Zuerst ist folgender Code in 99_myUtils.pl einzufügen:

<pre>
use Net::SNMP;
sub
snmpCheck($$)
{
my ($airport,$client)= @_;

my $community = "public";
my $host = $airport;
my $oid = ".1.3.6.1.2.1.3.1.1.2";
#my $oid = ".1.3.6.1.2.1.3.1.1.2.25.1.10.0.1";

my ( $session, $error ) = Net::SNMP->session(
-hostname => $host,
-community => $community,
-port => 161,
-version => 1
);

if( !defined($session) ) {
return 0;
return "Can't connect to host $host.";
}

my @snmpoids = ();

my $response = $session->get_next_request($oid);
my @nextid = keys %$response;
while ( @nextid && $nextid[0] && $nextid[0] =~ m/^$oid/ ) {
push( @snmpoids, $nextid[0] );

$response = $session->get_next_request( $nextid[0] );
@nextid = keys %$response;
}

if( !defined($response = $session->get_request( @snmpoids ) ) ) {
return 0;
}

foreach my $value (values %$response) {
return 1 if( $value eq $client )
}

return 0;
}
</pre>

Danach lässt sich das Mobilgerät so überwachen:
:<code>define iPhone PRESENCE function {snmpCheck("10.0.1.1","0x44d77429f35c")} 30 30</code>

wobei 10.0.1.1 durch die IP-Adresse der Basestation und 0x44d77429f35c durch die MAC Adresse des Geräts als HEX-Zahl ersetzt werden muss.

== Das GEOFANCY Modul ==
Das Modul ermöglicht über einen sogenannten Webhook Mechanismus (umgangssprachlich oft auch als "Push" benannt) das aktive Melden des aktuellen Standortes. Die iPhone Apps [http://geofency.com/ Geofency] und [http://geofancy.com/ Geofancy] können dann aktiv und quasi in dem Moment, wo man den Wohnbereich betritt oder verlässt, benachrichtigen. Android Nutzern können [https://play.google.com/store/apps/details?id=de.egi.geofence.geozone&hl=de EgiGeoZone Geofence] nutzen. Das geht nochmals um einiges schneller, als die Erkennung im WLAN, bei der die Anwesenheit nur in (engen) Zyklen aktiv geprüft werden muss. Gleichzeitig werden Ressourcen in FHEM geschont. Die aktuelle Implementierung im iPhone 5S mit dediziert für das Tracking zuständigem Chip ist so gut, dass der Akku ebenfalls sehr geschont wird.

=== Modul in FHEM einrichten ===
Das Modul ist mit einer einfachen Definition sofort betriebsbereit:
:<code>define geofancy GEOFANCY geo</code>

Damit nimmt FHEM unter <nowiki>http://192.168.178.1:8083/fhem/geo</nowiki> entsprechende Meldungen des iPhones entgegen. Damit das nicht nur über das lokale WLAN funktioniert, bedarf es allerdings noch einiger zusätzlicher Maßnahmen. FHEM muss vom Internet erreichbar gemacht werden, dabei sollte unbedingt an die Absicherung des Zugriffs gedacht werden.

Zunächst einmal habe ich bei mir eine eigene FHEMWEB Instanz dafür angelegt:
<pre>
define WEBhook FHEMWEB 8088 global
attr WEBhook column Alarms: Apartment: Living: Bedroom: Kitchen: Sonos: Residents: Weather: Bathroom: Logs: Statistics: DashboardRoom: System: hidden: all:
attr WEBhook hiddenroom input,detail,save,Unsorted,Everything,CUL_HM,FS20,Commandref,style,Edit files,Select style,Logfile,Floorplans,Remote doc,FileLogs,Apartment,Bathroom,Bedroom,Kitchen,Living,Residents,System,Weather,Event monitor,NEW
attr WEBhook room hidden
attr WEBhook webname webhook
</pre>

Damit ist unter der URL <nowiki>http://192.168.178.1:8088/webhook/geo</nowiki> das GEOFANCY Modul erreichbar. Ich verstecke in dieser Ansicht noch alle Räume, die ich so habe. Wer die Raumnamen allerdings kennt, kann sie trotzdem aufrufen. Die Anzeige in den Räumen kann man mit dem Attribut column und entsprechend leeren Definitionen verstecken. Nun muss man explizit den Devicenamen kennen, um noch etwas über die Konfiguration in Erfahrung bringen zu können.
Auch wenn das Security-by-Obscurity ist - ich fühle mich wohler damit.

=== Webhook weiter absichern ===
Mit Hilfe eines [http://fhem.de/commandref.html#allowed allowed]-Devices lässt sich die FHEMWEB Instanz noch weiter absichern indem nur die tatsächlich benötigten Kommandos erlaubt werden (in diesem Fall keine) und damit alle anderen nicht erlaubten (attr,define,get,set,...) automatisch nicht mehr zur Verfügung stehen:
<pre>
define allowedWEBhook allowed
attr allowedWEBhook allowedCommands ,
attr allowedWEBhook allowedDevices ,
attr allowedWEBhook validFor WEBhook
</pre>

Außerdem ist dringend zu empfehlen, den Zugriff über TLS/SSL und HTTP Basic-Authentication weiter abzusichern. Läuft FHEM auf einem Raspberry Pi, dann empfehle ich dazu die Konfiguration eines ReverseProxy (vorzugsweise HAproxy, Pound oder Varnish, notfalls auch Nginx oder Apache); damit ist man am flexibelsten und kann auch alle FHEMWEB Instanzen direkt über einen einzigen Port (meist 443, der HTTPS Standard Port) zusammenfassen. Ich möchte hier allerdings beschreiben, wie weit man mit FHEM Bordmitteln kommt und nehme das Beispiel einer Installation auf einer Fritzbox.

Wie TLS aktiviert wird, steht in der Commandref für [[FHEMWEB]]. Um die Kommandos auf der Fritzbox ausführen zu können, muss zuerst Telnet aktiviert werden (bitte Google benutzen). Anschließend wechselt man auf der Fritzbox ins Verzeichnis /var/media/ftp/fhem und kann dann den Hinweisen aus der [http://fhem.de/commandref.html#FHEMWEB Commandref] unter dem Punkt HTTPS folgen. Letztlich fehlt noch das entsprechende Attribut:

<pre>
attr WEBhook HTTPS
</pre>

Als nächstes aktivieren wir Benutzername+Passwort für den Zugriff. Die commandref für allowed gibt auch hier unter dem Punkt basicAuth entsprechende Hinweise. Wir fügen hier einfach mal einen Benutzer "webhook" mit dem Passwort "Geofancy" hinzu, das sieht dann so aus:

<pre>
attr allowedWEBhook basicAuth { "$user:$password" eq "webhook:Geofancy" }
</pre>

Weitere Infos zur Absicherung gibt auch [[FritzBox Webzugriff absichern]].

Um zu testen, ob unsere Absicherung erfolgreich war, kann man die URL <nowiki>https://192.168.178.1:8088/webhook/geo</nowiki> aufrufen (wichtig ist, dass man jetzt https und nicht mehr http eingibt; ansonsten bekommt man keine Antwort). Eine Zertifikatswarnung kann getrost ignoriert werden, verschlüsselt wird trotzdem. Es sollte auch eine Passwort Abfrage kommen und die Eingabe der entsprechenden Daten sollte dann zu einer entsprechenden Meldung vom GEOFANCY Modul führen:

<pre>
NOK No data received, see API information on http://wiki.geofancy.com
</pre>

Das ist ok, schließlich sind wir keine App, sondern der Mensch, der nur mal eben prüfen will :-)

=== Zugriff vom Internet ermöglichen ===
Das ist je nach Fritzbox und Software Version unterschiedlich. Grundsätzlich gilt: Eine Weiterleitung des ports 8088 vom Internet auf das laufende FHEM auf Port 8088 intern ist von AVM so nicht vorgesehen.
Bei mir führte folgendes zum Erfolg:

* Einloggen per Telnet auf der Fritzbox (ich habe FritzOS 6 installiert)
* Konfiguration editieren mittels "nvi /var/flash/ar7.cfg"
* Suchen nach richtiger Zeile durch Eingabe von "/internet_forwardrules" und Enter
* Hinzufügen einer weiteren Zeile (Vorsicht, die bestehende Zeile endet mit ; und das muss in , umgeändert werden, so dass das ; schließlich am Ende der Zeile steht.

So sieht es bei mir vorher aus:
:<code>internet_forwardrules = "tcp 0.0.0.0:488 0.0.0.0:488 0";</code>
Hinterher:
:<code>internet_forwardrules = "tcp 0.0.0.0:488 0.0.0.0:488 0", "tcp 0.0.0.0:8088 0.0.0.0:8088 0";</code>

Danach mittels ":x" abspeichern und sofort per "reboot" die Box neu starten, um diese Änderungen zu aktivieren. Das ist wichtig; ansonsten zeigt die Erfahrung, dass die Änderung nicht dauerhaft erhalten bleibt und die gerade gemachten Änderungen verloren gehen.

Wer die Einstellungen zu "internet_forwardrules" bei sich nicht finden kann, hat womöglich eine andere Version als ich oder ein leicht anderes Gerät und bemüht am besten Google, was er tun kann, um das Gleiche zu erreichen. Möglicherweise tauchen die Einträge auch erst auf, wenn man mal über das Webinterface ein Forwarding eingerichtet hatte.

Hat man einen DynDNS Dienst oder myFritz auf der Fritzbox aktiviert, so kann man jetzt auch von draußen auf den Webhook zugreifen. Das kann man prüfen, indem man das iPhone aus dem WLAN ausbucht und einmal die externe Adresse eingibt, also z.B. https://meindyndns.org:8088/webhook/geo.

=== Weitere Alternativen für den Zugriff aus dem Internet ===
Als Alternative zum Port Forwarding kann man sich auch per VPN in das lokale Netzwerk einwählen. iOS bietet dazu auch eine automatische Aktivierung des VPN (VPN on Demand), wie z.B. [http://forum.loxone.com/dede/netzwerk-firewall-and-security/8121-vpn-demand-ios-8-1-1-fritz-box-kleine-how.html hier] beschrieben wird.

Auch eine Alternative ist, das Portforwarding nicht direkt an FHEM einzurichten, sondern an einem im Netzwerk laufenden Reverse-Proxy, der dann seinerseits die Anfragen an FHEM weiterleitet. Dies kann z.B. Apache, Nginx oder am besten HAproxy sein.
Letzterer ist dabei sehr flexibel, allerdings nicht unbedingt einfach zu konfigurieren. Ein paar Inspirationen diesbezüglich gibt es z.B. [https://github.com/Hoanoho/HSE/tree/develop/lib/cfg/any/stat/etc/haproxy hier] und [https://github.com/Hoanoho/HSE/tree/develop/lib/cfg/any/dyn/etc/haproxy hier]. Wer pfSense nutzt, findet [http://loredo.me/post/116633549315/geeking-out-with-haproxy-on-pfsense-the-ultimate diesen Artikel] womöglich auch interessant. Er zeigt auch, dass mit HAproxy noch weit mehr möglich ist.
Der Reverse-Proxy sollte dabei auch unbedingt der TLS Termination Point sein (TLS Offloading). Nicht nur spart man sich dann die Aktivierung von TLS in FHEM, sondern man hat auch mehr Einfluss darauf, wie TLS arbeitet (z.B. Deaktivierung von SSLv3, forcieren von TLSv1.2, nur als sicher eingestufte Cipher Suite... siehe auch Infos auf der [https://wiki.mozilla.org/Security/Server_Side_TLS Mozilla Website]).

=== Einrichten in der Geof[e|a]ncy.app ===
Hat das alles soweit geklappt, können endlich in der Geofency.app bzw. Geofancy.app am iPhone die gewünschten Bereiche definiert werden. Am Besten zuvor in den Global Settings die folgenden Einstellungen hinterlegen:

* URL: https://meindyndns.org:8088/webhook/geo
* POST (oder GET, ist egal - das FHEM Modul kann beides)
* HTTP Basic Authentication: EIN (entsprechend Username und Password eintragen)

Anfänglich ist es empfehlenswert noch "Notification on success" und "Notification on Failure" einzuschalten. Ersteres kann man ausmachen wenn man weiß, dass es soweit funktioniert. Über "Send Test-Request" kann man einmal einen Test schicken und erhält das Ergebnis entsprechend dargestellt. Es sollte sowas kommen wie
:<code>POST Success: test OK</code>. In Geofancy.app gibt es keine Rückmeldung über den Erfolg des Testrequests. In FHEM sollten sich durch den Testrequest jedoch die Readings sofort aktualisieren (Ggf. ist ein Reload der FHEMWEB-Seite nötig da zusätzliche Tabellenzeilen nicht via Longpoll ergänzt werden).

Funktioniert das soweit, kann man eine neue Lokation als sein Zuhause anlegen. Es empfiehlt sich einen ID-Namen zu setzen; dieser ist dann in FHEM als Name für die Lokation sichtbar. Für die eigene Wohnung empfiehlt sich hier "home" (da dies auch direkt vom RESIDENTS Modul so verwendet werden kann). Man kann auch Trigger für andere Standorte anlegen. FHEM weiß dann sogar, wenn ihr im Büro seid und könnte sich dabei auch unterschiedlich verhalten, als wenn ihr "auf Achse" seid. Bei letzterem ist der Status im GEOFANCY Modul "underway", was so viel heißt wie "unbekannter Aufenthaltsort".

Hinweis: Zumindest für Geofancy.app liefert ein Testrequest wohl zufällige Locations zurück. Die eigenen Location-IDs werden also nicht übergeben, selbst wenn man sich in einem Geofence befindet. Um zu testen muss man sich wohl oder übel selbst bewegen ;-).

=== GEOFANCY Modul individualisieren ===
Die im GEOFANCY Modul dargestellten Readings sind nun in etwa so, wenn ihr euch bewegt:

<pre>
Readings:
2014-01-18 14:37:42 lastDevice -
2014-01-18 14:37:42 lastDeviceUUID 51F23894-AAAA-BBBB-CCCC-0123456789AB
2014-01-18 14:37:42 state dev:51F23894-AAAA-BBBB-CCCC-0123456789AB trig:test id:home lat:48.9999 long:11.9999
</pre>

Wer genauer hinschaut sieht: Mein iPhone heißt wohl 51F23894-AAAA-BBBB-CCCC-0123456789AB.
Damit nun die Readings für mein iPhone richtig angelegt werden, muss ein Device Alias gesetzt werden. Sinnvoll erscheint mir der Vorname des Besitzers:
:<code>attr geofancy devAlias 51F23894-AAAA-BBBB-CCCC-0123456789AB:Julian</code>

Weitere Alias-Namen können mit Leerzeichen einfach angehängt werden.
Jetzt werden weitere Readings angelegt, sobald GEOFANCY entsprechende Daten vom Mobilgerät empfängt:

<pre>
Readings:
2014-01-18 14:37:42 Julian arrived home
2014-01-18 14:37:42 currLocLat_Julian 48.9999
2014-01-18 14:37:42 currLocLong_Julian 11.9999
2014-01-18 14:37:42 currLocTime_Julian 2014-01-18 14:37:42
2014-01-18 14:37:42 currLoc_Julian home
2014-01-17 19:18:23 lastArr Julian home
2014-01-17 18:41:46 lastDep Julian Office
2014-01-18 14:37:42 lastDevice Julian
2014-01-18 14:37:42 lastDeviceUUID 51F23894-AAAA-BBBB-CCCC-0123456789AB
2014-01-17 18:41:46 lastLocArr_Julian 2014-01-17 08:58:37
2014-01-17 18:41:46 lastLocDep_Julian 2014-01-17 18:41:46
2014-01-17 18:41:46 lastLocLat_Julian 48.1111
2014-01-17 18:41:46 lastLocLong_Julian 11.1111
2014-01-17 18:41:46 lastLoc_Julian Office
2014-01-18 14:37:42 state dev:Julian trig:test id:home lat:48.9999 long:11.9999
</pre>

Möchte man nun etwas bestimmtes tun, wenn man nach Hause kommt oder das Heim verlässt, kann man am Besten ein entsprechendes Notify auf das Reading currLoc_Name setzen. Ich aktualisiere lediglich zwei Dummies, durch die dann alle weiteren Notifies ausgelöst werden:

<pre>
define n_Julian.Presence notify geofancy:currLoc_Julian:.home set Julian.homestatus:FILTER=STATE!=home home
attr n_Julian.Presence room Residents
define n_Julian.absence notify geofancy:currLoc_Julian:.underway {\
if (Value("Julian.homestatus") ne "gone") {\
fhem("set Julian.homestatus:FILTER=STATE!=absent absent");;\
}\
}
define n_Julian.whereabout notify geofancy:currLoc_Julian:.* set Julian.whereabout:FILTER=STATE!=$EVTPART1 $EVTPART1
</pre>

Wer es noch einfacher möchte (bzw. auch noch mehr Features) schaut sich einmal die neue Modulfamilie aus RESIDENTS[http://fhem.de/commandref_DE.html#RESIDENTS], ROOMMATE[http://fhem.de/commandref_DE.html#ROOMMATE] und GUEST[http://fhem.de/commandref_DE.html#GUEST] an. Diese sind direkt auf GEOFANCY abgestimmt. Dabei kann das devAlias Attribut entfallen und man hinterlegt die UUID stattdessen direkt im ROOMMATE oder GUEST Device (Attribut r*_geofenceUUIDs). Das erspart es für jeden Bewohner und jedes Device zig unterschiedliche Devices der Typen Notify, DOIF oder Watchdog anlegen und pflegen zu müssen.

Wer mehr Kontrolle möchte kann natürlich bei notify, DOIF und Co. bleiben: <code>define n_rr_Julian.location notify geofancy:currLoc_Julian:.* set rr_Julian:FILTER=location!=$EVTPART1 location $EVTPART1</code>. Wobei "Julian" dabei als devAlias in GEOFANCY eingtragen wurde, rr_Julian der Name des ROOMMATE aus RESIDENTS ist. Außerdem wurden die Location-IDs in der Geofency.app bzw. Geofancy.app so gewählt, dass diese direkt einem ROOMMATE-Status entsprechen (also z.B. home, wayhome...).

== Beispiele für die Nutzung der Anwesenheitserkennung ==
Hier sollen Beispiele für den Nutzen von Anwesenheitserkennung aufgezeigt werden.

=== Abschalten aller Verbraucher (Licht, Musikanlage) beim Verlassen der Wohnung ===
Typisches Szenario: Man geht ausser Haus, aber hat vergessen im Bad das Licht aus zu machen. Allerdings geht man heutzutage fast garnicht mehr ohne Handy aus dem Haus.

Nun soll FHEM in der gesamten Wohnung das Licht, sowie sonstige Verbraucher ausschalten, wenn ich länger als 15 Minuten ausser Haus bin. Dazu benötigt man zuerst eine structure, die alle Verbraucher und sonstigen Devices, die das betrifft, zusammenfasst.

<pre>
define Gesamte_Wohnung structure Gesamtes_Licht Licht_Wohnzimmer Licht_Kueche LED_Kueche Licht_Bad Licht_Schlafzimmer AV_Receiver TV_Steckdose
attr Gesamte_Wohnung room Wohnung
</pre>

Nun kann man mittels eines watchdogs eine Überwachung für sein Handy anlegen:

<pre>
# Überwachen der gesamten Wohnung mittels collectord sowie presenced in jedem Raum
define Handy PRESENCE lan-bluetooth XX:XX:XX:XX:XX:XX 127.0.0.1:5222
attr Handy event-on-change-reading state # Ein Event soll nur bei der Änderung des Anwesenheitsstatus (Reading: status) erfolgen. Wichtig für den watchdog!!!

# Nach 15 Minuten Abwesenheit (Handy im Status "absent") soll die gesamte Wohnung ausgeschaltet werden.
define watchdog_Anwesenheit watchdog Handy:absent 00:15 Handy:present set Gesamte_Wohnung off ; trigger watchdog_Anwesenheit .
attr watchdog_Anwesenheit regexp1WontReactivate 1
</pre>

=== Benachrichtigung bei Batteriewechsel ===
Mit Hilfe des PRESENCE-Moduls kann man auch bei batteriebetriebenen Geräten eine Meldung ausgeben, sobald ein Batteriewechsel ansteht. Hier im Beispiel wird der Eve-Room-Sensor von Elgato eingebunden und anschließend mit einer DOIF-Nachricht ausgestattet.
Die Bluetooth-Adresse des Sensors kann mittels eines BLE-Scanners ermittelt werden.

<pre>
# PRESENCE-Modul für Elgato Eve Room Sensor mit Aktualisierung aller 6 Minuten
define Eve_Room_BLE lan-bluetooth <Bluetooth-Adresse> 127.0.0.1:5333 360
</pre>

Anschließend wird eine DOIF-Regel definiert, die eine Nachricht an die installiere [[FHEM_APP|FHEM App]] absendet:
<pre>
define Eve_Room_BLE_Battery_Msg DOIF ([Eve_Room_BLE] eq "absent") (set Msg_iPhone message 'Batteriewechsel beim Eve Room Sensor im Wohnzimmer.')
attr Eve_Room_BLE_Battery_Msg wait 600
</pre>

Die Aktualisierung des PRESENCE-Eintrages sollte nicht größer sein als das WAIT-Attribut der DOIF-Regel. Ansonsten könnte eine kurze Systemstörung zum Fehlalarm führen.

== Anwesenheitserkennung Bluetooth PebbleBee mit PRESENCE Modul ==
Im Forum gibt es einen {{Link2Forum|Topic=28753|LinkText=langen Beitrag}} über die Einrichtung eines BT-Tag an einem RaspberryPI mit FHEM. Dabei werden Skripte wie blescan.pl und lepresenced genannt.
Da mittlerweile viele neue Informationen zusammen gekommen sind wurde der Wiki Eintrag erstellt.

Im Folgenden wird die Konfiguration für '''LE Deviced (z.B. Gtags,Pebbles etc.)''' und '''NICHT LE Device (z.B. IPhone)''' beschreiben.

'''Wo finde ich denn lepresenced?'''

lepresenced kann über Github heruntergeladen werden (Link weiter unten)

'''Was ist der Vorteil gegenüber blescan.pl?'''

{{Randnotiz|RNText=Beide hier beschriebenen Wege (presenced/lepresenced) können parallel auf dem selben BT-Dongle laufen, da sich die Ports unterscheiden!}}
blescan.pl hat u. a. das Problem, dass dank der wundervollen Bluetooth-Implementierung unter Linux ab und zu der Scan fehlschlägt und das Interface resettet werden muss. Das tut blescan.pl auch mit aller Gewalt. Dazu kommt, dass bei längeren Scanzeiten und vielen Tags sich die Prozesse anstauen, weil immer nur auf einen Tag "gewartet" wird. Außerdem wurden mit der Einführung von lepresenced sämtliche Supportverträge gekündigt lepresenced läuft dauerhaft und merkt sich bei allen sendenden Tags den Zeitstempel des letzten Empfangs.

=== Getestete Hardware/Software===
* '''Raspbian System''' - wheezy, Jessie
* '''BT-Dongle''' - CSL NET BT USB2.0 Stick, Bluetooth V4.0, Nano '''Achtung''': Es muss ein BT V4.0 oder höher verwendet werden. Nur dieser unterstützt ''LowEnergy''
* '''BT-TAG''' - Gtag von Gigaset, TrackR, UDOO Neo, PebbleBee, iTag von Unitec, X4-LIFE Multifunkti BL-Anhänger, iTag Wireless Anti, Trackr bravo

=== BT Dongel am PI installieren ===

Um den BT Dongle ''(hier: CSL NET BT USB2.0)'' am PI verwenden zu können, müssen die notwendigen Pakete über die Paketverwaltung von debain nachinstalliert werden.
Wer bereits ein BT-Dongle installiert hat, kann diesen Schritt überspringen.
<pre>
apt-get install bluetooth
</pre>
Nach erfolgreicher Installation der Pakete sollte der RaspberryPI neu gestartet werden.
<pre>
sudo reboot
</pre>

Nach dem erfolgten Reboot bitte das Log des Raspberry auf folgende Einträge prüfen:
<pre>
Feb 12 19:52:55 fhem kernel: [ 4.773600] Bluetooth: Core ver 2.20
Feb 12 19:52:55 fhem kernel: [ 4.773748] NET: Registered protocol family 31
Feb 12 19:52:55 fhem kernel: [ 4.773765] Bluetooth: HCI device and connection manager initialized
Feb 12 19:52:55 fhem kernel: [ 4.773797] Bluetooth: HCI socket layer initialized
Feb 12 19:52:55 fhem kernel: [ 4.773821] Bluetooth: L2CAP socket layer initialized
Feb 12 19:52:55 fhem kernel: [ 4.773890] Bluetooth: SCO socket layer initialized
Feb 12 19:52:55 fhem kernel: [ 4.797531] usbcore: registered new interface driver btusb
</pre>
Sobald der BT-Dongle erkannt wurde ''leuchtet'' (wenn vorhanden) auch die ''blaue/gelbe'' LED am Dongle auf.

=== BT-Tags aktivieren ===
Jetzt kann der BT-Tag aktiviert werden. Bei einigen Tags muss dafür die '''Batteriesicherung''' gezogen werden.

Einen Tag wird mit folgendem Befehl auf der Konsole gesucht:
<source lang="bash">
sudo hcitool lescan

Ausgabe z.B.:
LE Scan ...
7C:2F:80:A1:XA:XD (unknown)
7C:2F:80:A1:XA:XD Gigaset G-tag
7C:2F:80:A1:X4:X1 (unknown)</source>
Eine Übersicht über die möglichen Befehle von hcitool gibt es mit der Eingabe von:
<pre>
sudo hcitool

Ausgabe z.B.:
hcitool - HCI Tool ver 5.23
Usage:
hcitool [options] <command> [command parameters]
Options:
--help Display help
-i dev HCI device
Commands:
dev Display local devices
inq Inquire remote devices
scan Scan for remote devices
name Get name from remote device
info Get information from remote device
spinq Start periodic inquiry
epinq Exit periodic inquiry
cmd Submit arbitrary HCI commands
con Display active connections
cc Create connection to remote device
dc Disconnect from remote device
sr Switch master/slave role
cpt Change connection packet type
rssi Display connection RSSI
lq Display link quality
tpl Display transmit power level
afh Display AFH channel map
lp Set/display link policy settings
lst Set/display link supervision timeout
auth Request authentication
enc Set connection encryption
key Change connection link key
clkoff Read clock offset
clock Read local or remote clock
lescan Start LE scan
lewladd Add device to LE White List
lewlrm Remove device from LE White List
lewlsz Read size of LE White List
lewlclr Clear LE White list
lecc Create a LE Connection
ledc Disconnect a LE Connection
lecup LE Connection Update
</pre>

Falls beim SCAN kein Tag gefunden wird, sollte das BT Interface neu gestartet werden. Dazu ist kein Reboot des PI notwendig.
<source lang="bash">
sudo hciconfig hci0 down
sudo hciconfig hci0 up
sudo hcitool dev
</source>

=== Anleitung für ein LE Device (z.B. Gtags,Pebbles etc.) ===

Herunterladen des Skripts lepresenced.
<pre>
https://github.com/mhop/fhem-mirror/blob/master/fhem/contrib/PRESENCE/lepresenced
</pre>

Zur "Installation" des Skripts folgendermaßen vorgehen:
Unter /fhem manuell den Ordner „script“ anlegen:
<pre>
mkdir script
</pre>
Datei lepresenced reinkopieren und ausführbar machen:
<pre>
sudo chmod +x /opt/fhem/script/lepresenced
sudo chgrp -cR dialout lepresenced
</pre>
Skript erstmalig starten:
<pre>
sudo ./lepresenced --loglevel LOG_EMERG -d
</pre>
Kommt beim Starten des Skript eine Fehlermeldung, müssen die Abhängigkeiten aufgelöst werden.
<pre>
Can't locate Net/Server/Daemonize.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 / usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at /opt/fhem/lepresenced line 17.
BEGIN failed--compilation aborted at /opt/fhem/lepresenced line 17.
</pre>
Um die Abhängigkeiten aufzulösen muss folgendes nachinstalliert werden und anschließend ein Reboot durchgeführt werden.
<pre>
sudo apt-get install libnet-server-*
</pre>

Nach dem letzten Schritt sind alle Bedingungen für eine abschließende Konfiguration der BT-Tags in FHEM abgeschlossen worden.
Jetzt kann der Tag dem FHEM-Server bekannt gemacht werden.
<pre>
-- Name Modul Modus MAC vom Gtag IP vom PI Port Abfragezeit in Sekunden
define MeinGtAG PRESENCE lan-bluetooth xx:xx:xx:xx:xx:xx 127.0.0.1:5333 120
</pre>

Den absent und present Mode kann man einfach testen, in dem man den Gtag mit Alufolie einwickelt.

=== Anleitung für ein NICHT LE Device (z.B. IPhone) ===
Die Installation kann (wie in der commanref beschrieben) über Debian Pakete erfolgen.
<pre>
.deb package for Debian (noarch): presenced-1.3.deb http://svn.code.sf.net/p/fhem/code/trunk/fhem/contrib/PRESENCE/deb/presenced-1.3.deb

.deb package for Raspberry Pi (raspbian): presenced-rpi-1.3.deb http://svn.code.sf.net/p/fhem/code/trunk/fhem/contrib/PRESENCE/deb/presenced-rpi-1.3.deb
</pre>

<pre>
sudo dpkg -i presenced-rpi-1.3.de
</pre>

Installation perl script file (Auszug commanref)
<pre>
direct perl script file: presenced http://svn.code.sf.net/p/fhem/code/trunk/fhem/contrib/PRESENCE/presenced
</pre>

Nach dem letzten Schritt sind alle Bedingungen für eine abschließende Konfiguration der BT-Tags in FHEM abgeschlossen worden.
Jetzt kann der Tag dem FHEM-Server bekannt gemacht werden.
{{Randnotiz|RNText=Wenn man mit collectord arbeitet muß man die Erkennung bei allen Devices auf port 5222 setzen.
lan-bluetooth xx:xx:80:xx:xx:AC 127.0.0.1:5222 20 120}}
<pre>
-- Name Modul Modus MAC vom Gtag IP vom PI Port Abfragezeit in Sekunden
define MeinGtAG PRESENCE lan-bluetooth xx:xx:xx:xx:xx:xx 127.0.0.1:5333 120
</pre>

=== Automatischer Start ===

Damit das leprecend Skript beim Systemstart mitgestartet wird, sollte eine Crontab Eintrag gesetzt werden. Alternativ die rc.local anpassen.
Ersteres würde so aussehen:

Ein sh-Skript mit dem Inhalt:
<pre>
sudo start-stop-daemon -d /opt/fhem/script -S -x /opt/fhem/script/lepresenced
</pre>
unter dem Verzeichnis /home/pi ablegen, welches sich init_start.sh nennt.

Das Skript dann unter: sudo crontab -e einhängen mit folgender Folge:
<pre>
@reboot /home/pi/init_start.sh
</pre>

Zweiteres so:
<pre>
sudo nano /etc/rc.local
</pre>

Datei rc.local, freie Stelle suchen, vor "exit 0":

<pre>
# Start lepresenced
/opt/fhem/script/lepresenced --loglevel LOG_EMERG -d
exit 0
</pre>

=== Batterieüberwachung (aktuell nur G-Tags) ===

Leider überträgt der G-Tag nach der Einrichtung als Device in FHEM kein Reading mit seinem aktuellen Batteriestatus.
Dem wurde mit Hilfe des Forum Abhilfe geschaffen.
Im Folgenden wird erläutert wie die Batterieüberwachung eingerichtet werden kann.

'''Voraussetzung:'''

bc - Basiscalculator [https://packages.debian.org/de/sid/bc Bc-Paket]
<pre> sudo apt-get install bc </pre>

Anlegen eines Shellskript auf dem Raspberry System.
Die Parameter <<MAC-Adresse>> und <<TagName>> müssen durch die Werte des auszulesenden G-Tags ersetzt werden.
<pre>
#!/bin/bash
stringZ=$(sudo gatttool -b 5C:2B:80:C1:14:41 --char-read --handle=0x001b)
stringZ=${stringZ:33:2}
stringZ=$(echo "$stringZ" | tr a-f A-F)
decimal=$(echo "ibase=16; $stringZ" | bc)
perl /opt/fhem/fhem.pl 7072 "setreading MeinGtag Batterie $decimal"
</pre>

Dem Device in FHEM (hier MeinGtag) ein userReading mit dem Namen '''Batterie''' hinzufügen.
Das Shellskript mit folgendem Befehl starten:
<pre>
./GtagBatterie.sh
</pre>
'''Wichtig ist hierbei,''' dass Skript mit "./" und nicht mit "sh" aufzurufen. Beim Aufruf mit "sh GtagBatterie.sh" produziert es einen Fehler
<pre>GtagBatterie.sh: 3: GtagBatterie.sh: Bad substitution </pre>

Das Reading wird auf den ausgelesenen Wert der Batterie gesetzt.

Hinweis: Es sollte für jeden G-Tag ein eigenes Skript abgelegt werden. Das Skript kann per crontab oder fhem Kommando (system) regelmäßig aufgerufen werden.

=== Batterieüberwachung (alle Devices vom Typ "MODE=lan-bluetooth") ===

Es gibt eine weitere Möglichkeit um den Batteriestatus von LE Devices abzurufen und in FHEM als Reading darzustellen.
Dabei wird der Batteriezustand für alle LE Devices, die bereits in FHEM konfiguriert sind und per lepresenced überwacht werden, automatisch in einem shell-Script ermittelt.
Näheres dazu im Forumartikel [https://forum.fhem.de/index.php/topic,56960.0.html [Erweiterung]: Anwesenheitserkennung/Batterieüberwachung].

Vorteile:
* Automatische Ermittlung aller in FHEM konfigurierten LE Devices
* Möglichkeit, diese Devices alternativ manuell im Script einzutragen
* Es werden nur Devices abgefragt, die im Status "present" sind, also mit ziemlicher Sicherheit auch verfügbar sind
* Ein eventuell auf dem FHEM telnet-Port gesetztes Passwort kann im Script hinterlegt werden

'''Voraussetzung:'''

'''Funktionierendes lepresenced''' - siehe [[Anwesenheitserkennung#Anleitung_f.C3.BCr_ein_LE_Device_.28z.B._Gtags.2CPebbles_etc..29|Anleitung für ein LE Device (z.B. Gtags,Pebbles etc.)]]

'''socat''' - TCP port forwarder
<pre>
sudo apt-get update && sudo apt-get install socat
</pre>

'''gatttool''' - Bestandteil von bluez

gatttool ist auf den meisten Distributionen im bluez-Paket, allerdings nicht bei Opensuse. Dort muss man das Sourcepaket von bluez installieren und selbst kompilieren.
gatttool sollte dann nach /usr/bin oder /usr/local/bin kopiert werden,

Zusätzlich zu den notwendigen Erweiterungen werden für die Ausführung von gatttool '''Root-Rechte benötigt'''!

Das Script selbst gibt es hier: [https://raw.githubusercontent.com/micky0867/lebattery/master/lebattery lebattery]

Am Besten unter /opt/fhem/script/lebattery speichern und ausführbar machen:
<source lang="bash">
sudo su -
mkdir /opt/fhem/script
cd /opt/fhem/script
wget https://raw.githubusercontent.com/micky0867/lebattery/master/lebattery
chmod 755 lebattery
</source>

Je nach Bedarf können im Script noch die folgenden 3 Parameter angepasst werden:
<source lang="bash">
# If allowed_telnetPort is protected by a password, add the password here
TELNETPASSWORD=""
# Attribute for batterylevel in FHEM
ATTRIBUT="batterylevel"
# Use this, if you dont want the script to determine the tags on its own
LETAGS=""
</source>

Das Skript wird dann unter root folgendermaßen gestartet:
<pre>
/opt/fhem/script/lebattery -v
</pre>

Ausgabe des Skripts, wenn es mit dem Verbose Parameter -v gestartet wird.

Beide Devices sind vom Typ NUT mini, das Device mit dem FHEM-Namen '''nut_Micky''' ist im Status '''absent'''. Das zweite Device ist im Status '''present'''.
<pre>
Determining address for nut_Micky ...
nut_Micky is in state absent, no further action required

Determining address for nut_Test ...
Fetching batterylevel for nut_Test (F3:44:04:81:54:89) ...
Setting batterylevel for nut_Test to 100%
</pre>

Mein crontab-Eintrag (User root) sieht so aus:
<pre>
3 3 * * * /opt/fhem/script/lebattery -v >/opt/fhem/script/lebattery.log 2>&1
</pre>
Damit wird jeden Morgen um 3 Minuten nach 3 Uhr der Zustand der Batterien aller Devices ermittelt und in FHEM abgespeichert. 
Bevor man das mit crontab macht, sollte man allerdings zunächst sicher stellen, dass es auch ohne crontab funktioniert....

Bei Problemen kann man auch erstmal schauen, ob das mit dem gattool überhaupt funktioniert:
<pre>
gatttool -t random -b <MAC-Adresse> --char-read --uuid 0x2a19

handle: 0x0017 value: 64
</pre>
In diesem Fall hat die Batterie noch 100% (hex 64).

=== Problemlösungen ===
Falls es Probleme beim Starten des Skripts gibt bzw. man das Skript ohne Reboot des Systems neustarten möchte, kann man dies per kill Befehl erledigen.
<source lang="bash">
ps -ef | grep lepresenced
sudo kill <pid>
</source>

Debuglevel lepresenced setzen:
{{Randnotiz|RNText=Um Debug-Meldungen zu bekommen (Vorsicht bei SD-Karten-Systemen wie dem RPi) - Hierbei werden die Schreibzyklen auf die SD-Karte erhöht.}}
<pre>
lepresenced --loglevel LOG_DEBUG
</pre>
Nur das wichtigste Loggen:
<pre>
lepresenced --loglevel LOG_WARNING
</pre>
Keinerlei LOG-Einträge
<pre>
lepresenced --loglevel LOG_EMERG
</pre>

==== Ansprechpartner ====
# {{Link2FU|5068|PatrikR}} (Patrick) für lepresenced
# [[Benutzer Diskussion:Devender|Devender]] ({{Link2FU|20043|Dirk}}) für Wiki und Doku

[[Kategorie:Code Snippets]]
[[Kategorie:Glossary]]