FHEMWiki - Benutzerbeiträge [de]

PRESENCE

2018-09-10T20:56:49Z

Mikka: /* Getestete Hardware/Software */

{{Infobox Modul
|ModPurpose=Anwesenheitserkennung
|ModType=h

|ModTechName=73_PRESENCE.pm
|ModOwner=markusbloch
}}

Das [[PRESENCE]] Modul bietet für die Anwesenheitserkennung mehrere Varianten an:

* '''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)
* ''' Bluetooth'''
:- '''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äten, ü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.

= Überwachen mittels Ping 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!
Prüfe zu erst als User root ob die Capabilities gesetzt sind.
:<code>getcap /bin/ping</code>
Sollte folgendes Ergeben zu Tage fördern.
:<code>/bin/ping = cap_net_raw+ep</code>
Ist dem nicht so, setzen wir die benötigten Capabilities
:<code>setcap cap_net_raw+ep /bin/ping</code>
Mehr Informationen zum Thema Capabilities [https://manpages.debian.org/jessie/manpages-de/capabilities.7.de.html].

= 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>

= Überwachung mittels 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.pm einzufügen, sollte diese noch nicht vorhanden sein muss diese aus dem Template welches unter Edit Files zu finden ist erzeugt werden.
'''Achtung, das ist nicht der komplette Inhalt der 99_myUtils!''' Das ist nur die einzelne Routine

<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.

== Beispiel Anwesenheitserkennung mittels UniFi Controller ==

Die Anwesenheitserkennung bei Geräten in Verbindung mit UniFi-Produkten funktioniert selbst dann, wenn sich die Geräte im PowerSave-Modus befinden.

Beachte: Die Geräte werden erst ungefähr nach 5 Minuten, nachdem das Gerät das WLAN verlassen hat als disconnected angezeigt.

<code>define <NAME> PRESENCE function {ReadingsVal("<UniFi>","<NamedDevice>","") eq "connected" ? 1:0}</code>

= Überwachen mittels Events =
Der Vorteil gegenüber der Function-Variante ist, dass diese Variante ohne Blocking.pm-Overhead direkt ausgeführt werden kann und in "Echtzeit" abläuft (siehe {{Link2Forum|Topic=40287|Message=562823}}).

<code>define <NAME> PRESENCE event UniFi:NamedDevice:.disconnected UniFi:NamedDevice:.connected</code>

= Überwachen mittels Bluetooth =
== Vorbereitung und Informationen ==
=== Getestete Hardware/Software ===
* '''Raspbian System''' - wheezy, Jessie (interner BT-Controller)
* '''BT-Dongle''' - CSL NET BT USB2.0 Stick, Bluetooth V4.0, Nano <br />'''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, GhostyuBeacon iBc41

=== BT-Dongle am RaspberryPI installieren ===
Um den BT-Dongle ''(hier: CSL NET BT USB2.0)'' am RaspberryPI verwenden zu können, müssen die notwendigen Pakete über die Paketverwaltung von debian 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 RaspberryPI 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 BT-Tags muss dafür die '''Batteriesicherung''' gezogen werden.

Ein BT-Tag wird mit folgendem Befehl auf der Konsole gesucht:
<syntaxhighlight 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)</syntaxhighlight>
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 BT-Tag gefunden wird, sollte das BT Interface neu gestartet werden. Dazu ist kein Reboot des RaspBerryPI notwendig.
<syntaxhighlight lang="bash">
sudo hciconfig hci0 down
sudo hciconfig hci0 up
sudo hcitool dev
</syntaxhighlight>

== Überwachung durch den FHEM Server direkt ==
[[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>

== Überwachung durch verteilte Agenten in der Wohnung (presenced/lepresenced/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 / lepresenced Programm ausgestattet. Beide Programme 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.

=== Unterschied presenced / lepresenced / collectord ===
presenced und lepresenced sind Programme, welche in regelmäßigen Abständen nach Bluetooth-Geräten suchen. Sobald ein Gerät, welches vorab definiert wurde, gefunden wird, wechselt der Status des Geräts in FHEM auf Anwesend. Der Unterschied zwischen presenced und lepresenced ist, dass lepresenced insbesondere für [https://de.wikipedia.org/wiki/Bluetooth_Low_Energy Bluetooth-LE-Devices] ist und presenced für "normale" Bluetooth-Geräte.

collectord wiederum ist ein Programm, welches mehrere Pis verbindet und auf allen den aktuellen Status von presenced/lepresenced abfragt. Ist das gesuchte Bluetooth-Gerät auf einem der Pi anwesend, so wird es auch in der definierten Hauptinstanz auf anwesend gesetzt. Zusätzlich wird der Pi auf dem das Gerät gefunden wurde als Reading angegeben. Sofern alle Räume einen Empfangspegel (RSSI) ermitteln können, wird bei mehreren anwesenden Räumen der Raum mit dem besten Empfangspegel selektiert (siehe {{Link2Forum|Topic=54482}}).

=== Installation von (le)presenced ===
Diese Anleitung ist sowohl für presenced, als auch für lepresenced gültig. Einfachheitshalber wird nur lepresenced erwähnt, sämtliche Schritte gehen jedoch auch mit presenced, wobei einfach die genannten Daten durch presenced ersetzt werden müssen.

Die Software lepresenced kann aktuell über drei Varianten installiert werden. Dabei ist die bevorzugte Variante (Variante 1) die Installation über das bereitgestellte .deb-Paket.
Die Variante 2 setzt voraus, dass im FHEM contrib Verzeichnis (/opt/fhem/contrib) die aktuelle Version des .deb-Pakets liegt. Die Variante 3 ist dafür gedacht, wenn man keine .deb-Pakete installieren kann/will oder es aus anderen Gründen nicht funktioniert. Es wird davon abgeraten die Variante 3 zu verwenden. Vollständigkeitshalber wird sie aber aufgeführt.

===== Installation per .deb-Paket =====

Die bevorzugte Variante ist die Installation von lepresenced durch die passenden .deb Pakete.
{{Randnotiz|RNText=Bei einem Upgrade einer älteren Version reicht es, das neue .deb Paket mit
:<code>sudo dpkg -i lepresenced-X.XX-X.deb</code>
zu aktualisieren}}

'''1.Variante:'''
Herunterladen der aktuellen lepresenced-0.83-3.deb (Stand August 2017) Datei über den Webbrowser
[https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/PRESENCE/deb/ SVN-Repository]. Im SVN die passende Datei auswählen und in der folgende Webseite den Link unter:
<pre>
Download in other formats:
Original Format
</pre>
anklicken und die Datei herunterladen.
Die Datei kann jetzt auf den RPi kopiert und mit folgenden Befehlen ausgeführt werden (ggf. Berechtigungen anpassen).

Alternativ per wget Befehl direkt auf den RPi (aktuelle Versionsnummer beachten)
https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/PRESENCE/deb/lepresenced-0.83-3.deb

'''2.Variante:''' (zu Verwenden, wenn es Probleme bei Variante 1 gibt)
Herunterladen aus dem fhem contrib Verzeichnis:
Hierzu muss das contrib auf dem aktuellen Stand sein. Dazu wird die Installation von subversion (normal bereits vorhanden) benötigt.

sudo apt-get install subversion

Danach kann per
sudo svn checkout https://svn.fhem.de/fhem/trunk/fhem/contrib svnrepo

Das aktuelle Repository auf den Pi heruntergeladen werden. Danach sollte im gewählten Verzeichnis die eingecheckten Dateien verfügbar sein.
/opt/fhem/svnrepo/PRESENCE/deb

''' Installation der Variante 1 oder 2 '''

Egal welche Variante gewählt wurde, nun kann mit folgenden Befehlen das Paket installiert werden. Bitte Pfade ggf. anpassen.

'''Wichtig''': Das '''Paket''' hat eine ca. Größe von '''6,5Kb'''. Ab und an gibt es wohl Probleme mit der Installation, wodurch die Datei 11,5kb groß wird.
Diese Datei lässt sich nicht Installieren. In diesem Fall das Paket bitte mit der Variante 1 und dem Bereich "Download in other formats" herunterladen.

sudo dpkg -i lepresenced-0.83-3.deb

sudo apt-get -f install

Die Ausgabe der Installation sollte am Ende ein [ ok ] Starting lepresenced (via systemctl): lepresenced.service. ausgeben.

<pre>
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Abhängigkeiten werden korrigiert ... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
bluez-hcidump
Die folgenden NEUEN Pakete werden installiert:
bluez-hcidump
0 aktualisiert, 1 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
1 nicht vollständig installiert oder entfernt.
Es müssen 157 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 490 kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n]
Holen: 1 http://archive.raspberrypi.org/debian/ jessie/main bluez-hcidump armhf 5.23-2+rpi2 [157 kB]
Es wurden 157 kB in 0 s geholt (921 kB/s).
Vormals nicht ausgewähltes Paket bluez-hcidump wird gewählt.
(Lese Datenbank ... 42033 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../bluez-hcidump_5.23-2+rpi2_armhf.deb ...
Entpacken von bluez-hcidump (5.23-2+rpi2) ...
Trigger für man-db (2.7.0.2-5) werden verarbeitet ...
bluez-hcidump (5.23-2+rpi2) wird eingerichtet ...
lepresenced (0.82-1) wird eingerichtet ...
[ ok ] Starting lepresenced (via systemctl): lepresenced.service.
</pre>

'''3.Variante:'''

Bei dieser Variante wird das aktuellste lepresenced Skript aus github heruntergeladen. Das bedeutet, dass jegliche Konfiguration wie automatischer Start, Berechtigungen etc.
manuell konfiguriert werden muss. Diese Variante eignet sich nur für diejenigen, die keine .deb-Pakete installieren wollen/können oder die genau Wissen, was sie tun!
<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>

===== Einrichtung eines Bluetooth-Geräts über FHEM =====

Nach dem letzten Schritt sind alle Bedingungen für eine abschließende Konfiguration eines BT-Geräts in FHEM abgeschlossen worden.
Jetzt kann der zum Beispiel ein G-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>

'''Wichtig ist den angegeben Port zu unterscheiden. Für presenced muss der Port 5111 genommen werden, für lepresenced der Port 5333.'''
Den absent und present Mode kann man einfach testen, in dem man den Gtag mit Alufolie einwickelt.

Diese Variante sollte eingesetzt werden, wenn nur ein Pi nach Bluetooth-Geräten sucht. Möchte man mehr als ein Gerät nutzen um zum Beispiel eine größere Fläche abzudecken so muss mit collectored gearbeitet werden.

=== Alle Räume gemeinsam ansprechen mittels collectord ===
Um zwei presenced- oder lepresenced Installationen zu verbinden wird der collectord Daemon von Markus Bloch benötigt. 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.

[[Datei:Presence_Collectord_Uebersicht.jpg|200px|thumb|left|Schematische Darstellung Presence und Collectord, Danke an dtavb]]
Auf Basis folgender Skizze wird die Einrichtung und der Betrieb der Anwesenheitserkennung und Überwachung <p></p>
mit dem PRESENCE-Modul sowie dem Skript (.deb-Paket) lepresenced beschrieben. Zusätzlich wird für die Verbindung <p></p>
mehrere lepresenced Instanzen der collectord verwendet.<p></p>
Diese Skizze dient als Basis für alle genannten Konfigurationen innerhalb dieses Artikels.
{{NeuerTextBlock}}

==== Aufbau ====
; RPi1 (Hauptinstanz):
: FHEM Installation
: presence/lepresenced Installation
: collectord installation
: Sämtliche Bluetooth-Geräte in FHEM definiert
; RPi2 (Zweitsystem):
: FHEM installation
: presence/lepresenced Installation
: Sämtliche Bluetooth-Geräte in FHEM definiert

==== Installation per .deb-Paket ====
collectord wird heruntergeladen und installiert:
https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/PRESENCE/deb/collectord-1.8.deb (Stand Januar 2018)
<pre>
sudo dpkg -i collectord-1.8.deb
</pre>

Nach der Installation befindet sich im Verzeichnis: /etc/collectord.conf die Konfigurationsdatei für das collectord. Weitere Einstellungen können unter /etc/default/collectord vorgenommen werden.

==== Konfiguration auf Shellebene ====
<pre>
sudo vi /etc/collectord.conf
</pre>

Diese Datei muss jetzt nach folgender Vorlage angepasst werden.
<pre>
# room definition
#[room-name] # name of the room
#address=192.168.0.10 # ip-address or hostname
#port=5111 # tcp port which should be used (5111 is default)
#presence_timeout=120 # timeout in seconds for each check when devices are present
#absence_timeout=20 # timeout in secondsfor each check when devices are absent

[RPi1] # Name (wird als Reading room bei den BT-Tags angezeigt) der presence Instanze
address=127.0.0.1 # Lokale Adresse RPi1 , da hier das Collectord später laufen soll!
port=5333 # Port der Presence Installation
presence_timeout=60 # Selbstgewaelte Pruefintervalle
absence_timeout=60 # Selbstgewaelte Pruefintervalle

[RPi2] # Name (wird als Reading room bei den BT-Tags angezeigt) der presence Instanze
address=192.168.178.127 # IP-Adresse der Instanz, wo nur das Presence laueft, also RPi2
port=5333 # Port der Presence Installation
presence_timeout=60 # Selbstgewaelte Pruefintervalle
absence_timeout=60 # Selbstgewaelte Pruefintervalle
</pre>

Hinweis:
* Es dürfen keine [Namen] mit Leerzeichen verwendet werden
* Der angegebene Port richtet sich danach, ob auf dem Pi presenced (Port 5111) oder lepresenced (Port 5333) nach dem Bluetooth-Gerät sucht

==== Konfiguration in FHEM ====
;RPi1
define Gtag PRESENCE lan-bluetooth XX:XX:XX:XX:XX:XX 127.0.0.1:5222 60 ''Hinweis: (Der Port ist der, des collectord!! Standard 5222)''
;RPi2
define Gtag PRESENCE lan-bluetooth XX:XX:XX:XX:XX:XX 192.168.178.127:5222 60 ''Hinweis: (Der Port ist der, des collectord!! Standard 5222 - die IP-Adresse von die von RPi1)''

Nach der Konfiguration kann der Daemon gestartet werden.
Sobald das Bluetoothgerät irgendwo in der Wohnung erkannt wurde, meldet der Collectord dies sofort
an FHEM und teilt den Raum mit in dem es erkannt worden ist. Diese Information wird im Reading "rooms" des jeweiligen BT-Gerätes dargestellt.

Zum testen sollte collectord einmalig manuell gestartet werden. Dies hat den Vorteil, dass man nochmal den Port des collectord prüfen kann, dieser steht in der Zeile <pre>created socket on 0.0.0.0 with port 5222</pre> und man sehen kann, ob der collectord richtig startet, oder Fehler auswirft. Gestartet wird mit folgendem Kommando:
<pre>
sudo collectord -vv -c /etc/collectord.conf
</pre>
Die Ausgabe sieht wie folgt aus:
<pre>
2017-04-02 17:52:55 - =================================================
2017-04-02 17:52:55 - started with PID 15554
2017-04-02 17:52:55 - reading configuration file
2017-04-02 17:52:55 - no config errors found
2017-04-02 17:52:56 - created socket on 0.0.0.0 with port 5222
2017-04-02 17:53:20 - new connection from 127.0.0.1:48656
2017-04-02 17:53:20 - created thread 1 for processing device 7C:2F:80:E1:14:31 in room RPi2 for peer 127.0.0.1 (UUID: d0beb79dd4771532eb5e207c7bf31788)
2017-04-02 17:53:20 - created thread 2 for processing device 7C:2F:80:E1:14:31 in room RPi1 for peer 127.0.0.1 (UUID: d0beb79dd4771532eb5e207c7bf31788)
2017-04-02 17:53:20 - new connection from 127.0.0.1:48662
2017-04-02 17:53:20 - new connection from 127.0.0.1:48664
2017-04-02 17:53:20 - created thread 3 for processing device 7C:2F:80:ED:BC:F7 in room RPi2 for peer 127.0.0.1 (UUID: 7495a112063d5db45e6335d3fe305e36)
2017-04-02 17:53:20 - created thread 4 for processing device 7C:2F:80:ED:BC:F7 in room RPi1 for peer 127.0.0.1 (UUID: 7495a112063d5db45e6335d3fe305e36)
2017-04-02 17:53:20 - created thread 5 for processing device 7C:2F:80:E1:2A:4D in room RPi2 for peer 127.0.0.1 (UUID: c228f8d4d33b06787f995c7903c02760)
2017-04-02 17:53:20 - created thread 6 for processing device 7C:2F:80:E1:2A:4D in room RPi1 for peer 127.0.0.1 (UUID: c228f8d4d33b06787f995c7903c02760)
2017-04-02 17:53:22 - new connection from 192.168.xxx.xxx:51638
2017-04-02 17:53:22 - created thread 7 for processing device 7C:2F:80:E1:14:31 in room RPi2 for peer 192.168.xxx.xxx (UUID: 5db7012e709d6dc2fcd8159fc0344e40)
2017-04-02 17:53:22 - created thread 8 for processing device 7C:2F:80:E1:14:31 in room RPi1 for peer 192.168.xxx.xxx (UUID: 5db7012e709d6dc2fcd8159fc0344e40)
2017-04-02 17:53:22 - new connection from 192.168.xxx.xxx:51640
2017-04-02 17:53:22 - created thread 9 for processing device 7C:2F:80:ED:BC:F7 in room RPi2 for peer 192.168.xxx.xxx (UUID: c4b4d7c654132cf88e8c1fec3a956d3d)
2017-04-02 17:53:23 - created thread 10 for processing device 7C:2F:80:ED:BC:F7 in room RPi1 for peer 192.168.xxx.xxx (UUID: c4b4d7c654132cf88e8c1fec3a956d3d)
2017-04-02 17:53:29 - new connection from 192.168.xxx.xxx:51642
2017-04-02 17:53:29 - created thread 11 for processing device 7C:2F:80:E1:2A:4D in room RPi2 for peer 192.168.xxx.xxx (UUID: ecd7081e5ae3a0d8e735c8750cb116a1)
2017-04-02 17:53:29 - created thread 12 for processing device 7C:2F:80:E1:2A:4D in room RPi1 for peer 192.168.xxx.xxx (UUID: ecd7081e5ae3a0d8e735c8750cb116a1)
</pre>

Wenn das Log wie oben abgebildet aussieht wurde alles richtig gemacht und unter dem Device in FHEM erscheint ein neues Reading "rooms" mit dem Wert der erkannten PRESENCE-Installation.

'''Verhalten presence timeout im zusammenhang mit dem Attribut "absenceThreshold" der PRESENCE Konfiguration in FHEM'''
<br>
In der collectord.conf sind <code>presence_timeout</code> und <code>absence_timeout</code> für den jeweiligen Raum konfiguriert.
Das bedeutet, sobald irgendein Gerät in diesem jeweiligen Raum anwesend/abwesend ist, wird das jeweilige Timeout an den verbundenen presenced/lepresenced geschickt um damit das Check-Interval entsprechend zu ändern.

In der PRESENCE-Definition kann man ebenfalls ein <code>absence_timeout</code>/<code>presence_timeout</code> setzen. Sobald sich der Zustand ändert, wird auch das jeweilige Timeout an den collectord gesandt. Dies hat aber auf die Checks in den jeweiligen Räumen und damit der collectord.conf keinen Einfluss. Der collectord schickt ein Statusupdate an PRESENCE nur, wenn das vorgegebene Timeout (von PRESENCE) erreicht ist und keine Statusänderung stattfand. Sobald eine Änderung des Status erfolgt wird natürlich sofort der Status an PRESENCE geschickt.

Das Attribut absenceThreshold/presenceThreshold funktioniert nachwievor. Hier ist nur wichtig wie man die Timeouts sowohl in PRESENCE als auch collectord.conf setzt.

'''Das Reading "room" bei einer PRESENCE Definition und der Zusammenhang zu collectord'''
<br>
Wenn ein BT LE Empfänger in mehr als einem Raum detektiert wird, führt der collectord (ab Version 1.8) eine RSSI-Erkennung durch. Sofern alle Räume den Empfangspegel (RSSI) ermitteln können, wird der Raum mit dem besten Empfangspegel als Raum für das "room"-Reading ausgewählt. Der lepresenced in aktueller Version von PatrickR gibt immer den Empfangspegel aus.

==== Automatischer Start ====
Wenn der collectord per .deb Paket installiert wurde, startet er automatisch bei einem Reboot mit (via systemd/init-Skript).
<br>

Der Collectord wird standardmäßig mit dem Port 5222 gestartet. Um diese anzupassen sind zwei Schritte notwendig:<br>
'''1.)''' Anpassen der /usr/bin/collectord
Hier bitte den Parameter my $opt_p von 5222 auf 5XXX abändern.

Da der collectord mittlerweile per systemd beim reboot des RPi gestarte wird muss auch diese Konfiguration auf den neuen Port angepasst werden.<br>
'''2.)''' Anpassen der /etc/default/collectord
<pre>
# collectord startup defaults:
# The TCP port collectord will listen for incoming connections (default: 5222)
PORT=5111
# The location of the configuration file (default: /etc/collectord.conf
CFGFILE=/etc/collectord.conf
</pre>

Manuell starten als Daemon (Parameter <code>-d</code>) mit:
<pre>
sudo collectord -c /etc/collectord.conf -d -v -l /var/log/collectord.log
</pre>

== Batterieüberwachung ==

=== Batterieüberwachung mit dem Modul BleTagBattery ===
{{Infobox Modul
|ModPurpose=Anwesenheitserkennung
|ModType=h

|ModTechName=74_BleTagBattery
|ModOwner=mumpitzstuff
}}
Mit dem Modul BleTagBattery - können die Batteriestati aller BT-LE Devices gelesen werden.
Es wird das batteryLevel und battery angelegt welches als BT-LE Tags an einer PRESENCE-Installation registriert wurden.

Vorraussetzung und Installation:

Bluez und Gattool
sudo apt-get install bluez

Das Gattool ist in den Installationen von Bluez inbegriffen.

Hinzufügen des githup für das Modul
update add http://raw.githubusercontent.com/mumpitzstuff/fhem-BleTagBattery/master/controls_bletagbattery.txt
update all
restart fhem: shutdown restart
BT-LE tags muss an einer PRESENCE-Installation des type "lan-bluetooth" registriert sein.

Nach dem Neustart von FHEM kann das Modul definiert werden:
define a new device: define <name of device> BleTagBattery

Das Modul versucht in der Standardkonfiguration alle 6 Stunden die BT-LE Devices zu erreichen und das Reading batteryLevel und battery zu aktualisieren.
Das Update kann auch manuell mit dem folgenden Befehl erzwungen werden

set <name of device> statusRequest.

Weiter Informationen und Disskussionen können dem eigentlichen [https://forum.fhem.de/index.php?topic=68104.0 Forumsbeitrag] entnommen werden,

=== 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 {{Link2Forum|Topic=56960|LinkText=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>

'''gawk''' - Zum extrahieren der Daten
<pre>
sudo apt-get update && sudo apt-get install gawk
</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:
<syntaxhighlight lang="bash">
sudo su -
mkdir /opt/fhem/script
cd /opt/fhem/script
wget https://raw.githubusercontent.com/micky0867/lebattery/master/lebattery
chmod 755 lebattery
</syntaxhighlight>

Je nach Bedarf können im Script noch die folgenden 3 Parameter angepasst werden:
<syntaxhighlight 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=""
</syntaxhighlight>

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.<br>
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 <Typ> -b <MAC-Adresse> --char-read --uuid 0x2a19

handle: 0x0017 value: 64
</pre>
In diesem Fall hat die Batterie noch 100% (hex 64).<br>
Der Typ ist abhängig vom Hersteller und kann public (G-Tags) bzw. random (Nut) sein. Im Zweifelsfall beides ausprobieren.

= Beispiele =
== Anwesenheitserkennung / Anwesenheitsbenachrichtigung mit G-Tags ==
Ein Skript zur Nutzung der Gigaset G-TAGs zur Alarmierung bei öffnen und schließen von Türen und zur Anwesenheitserkennung, um die Alarmierung zu aktivieren bzw. deaktivieren.
Es kann verwendet werden um die Anwesenheit von mehrern Personen im Haushalt zu erkennen. Dabei wird eingeschränkt, dass nur bestimmte Personen die Alarmierung aktivieren können ( Eltern/Kind -Beziehung ).
Des Weiteren werden im Beispiel die Eltern benachrichtigt wenn eins der Kinder das Haus verlässt und die Eltern nicht anwesend sind.

{{Randnotiz|RNText=Namen der G-Tags in den Skripten bitte anpassen!}}

Für die ''Notify'' und die ''RESIDENTS-Erweiterung'' wird ein Dummy benötigt.
<pre>
define Alarm dummy
attr Alarm devStateIcon aktiv:secur_locked@red inaktiv:secur_open@lightgreen
attr Alarm eventMap on:aktiv off:inaktiv
attr Alarm setList on off
attr Alarm webCmd aktiv:inaktiv
attr Alarm room Alarm
</pre>

=== Mit Notify ===
<pre>
gtag.*.presence:.* {Anwesenheit_check("$EVTPART1", "$NAME")}
</pre>

Code für die 99_myUtils.pm
<pre>
### GTAG ANWESENHEITS CHECK
sub Anwesenheit_check($$) {
my ($EVENT, $NAME) = @_;

# gtag_rot - Alias Marco
# gtag_schwarz - Alias Ulli
# gtag_gruen - Alias Frida
# gtag_orange - Alias Hannah

my $RESIDENT = "rr_"; # Alle GTAGs sind Standardmäßig Residents Roommate
# $RESIDENT = "rg_" if (($NAME eq "gtag_orange") xor ($NAME eq "gtag_weis")); # Hier nur Gäste (Roomguest) Auskommentiert, da ich es so nicht brauche
my $ROOMMATE = ("$RESIDENT" . "$NAME"); # Residentsname zusammenbauen
my $ALIASNAME = AttrVal($ROOMMATE,'alias',$ROOMMATE); # ALIAS des Roommates auslesen

my $GTAG1 = Value('gtag_rot'); # ELTERN
my $GTAG2 = Value('gtag_schwarz'); # ELTERN

my $STATUS = "wahrscheinlich gerade los";
$STATUS = "anwesend" if ($EVENT eq "present"); # Status: anwesend
$STATUS = "unterwegs" if ($EVENT eq "absent"); # Status: unterwegs

Log 1, "$ALIASNAME ist $STATUS."; # LOG Eintrag erzeugen

if (($EVENT eq "present" && Value("Alarm") eq "aktiv") && ($NAME eq "gtag_gruen" xor $NAME eq "gtag_orange")) {
fhem("set teleBot send ALARMIERUNG BLEIBT AKTIV: $ALIASNAME ist da..."); # Telegram
# fhem("set Infopush msg 'ALARMIERUNG BLEIBT AKTIV' '$ALIASNAME ist da...'"); # Pushover
}
elsif (($EVENT eq "present" && Value("Alarm") eq "aktiv") && ($NAME eq "gtag_rot" xor $NAME eq "gtag_schwarz")) {
fhem("set teleBot send ALARMIERUNG INAKTIV: $ALIASNAME ist da...; set Alarm inaktiv"); # Telegram
# fhem("set Infopush msg 'ALARMIERUNG INAKTIV' '$ALIASNAME ist da...'; set Alarm inaktiv"); # Pushover
}
elsif (($EVENT eq "absent" && Value("Alarm") eq "aktiv") && ($NAME eq "gtag_gruen" xor $NAME eq "gtag_orange")) {
fhem("set teleBot send ALARMIERUNG BLEIBT AKTIV: $ALIASNAME hat das Haus verlassen."); # Telegram
# fhem("set Infopush msg 'ALARMIERUNG BLEIBT AKTIV' '$ALIASNAME hat das Haus verlassen.'"); # Pushover
}
elsif (($EVENT eq "absent" && Value("Alarm") eq "inaktiv") && ($GTAG1 eq "absent" && $GTAG2 eq "absent")) {
fhem("set Alarm aktiv; set teleBot send ALARMIERUNG AKTIV: $ALIASNAME hat das Haus verlassen."); # Telegram
# fhem("set Alarm aktiv; set Infopush msg 'ALARMIERUNG AKTIV' '$ALIASNAME hat das Haus verlassen.' '' 0 ''"); # Pushover
}
}
</pre>

<br>

=== Mit Notify und Integration des RESIDENTS-MODUL ===

Der hier beschriebene Code erweitert die Funktionen unter dem Punkt 5.93.
Das Notify muss daher mit der folgenden Zeile erweitert werden.

<pre>
define Alarm_AnwesenheitCheck notify gtag.*.presence:.* { Anwesenheit_check("$EVTPART1", "$NAME"), Anwesenheit_check_resi("$NAME") }
</pre>

Zusätzlicher Code für die 99_myUtils.pm um die RESIDENTS Funktion nutzen zu können:
<pre>
### RESIDENTS
sub Anwesenheit_check_resi($) {
my ($NAME) = @_;
my $ALIASNAME = AttrVal($NAME,'alias',$NAME); # ALIASNAME des GTAGs auslesen

my $RESIDENT = "rr_"; # Als Standard sind alle GTAGs Roommates
$RESIDENT = "rg_" if (($NAME eq "gtag_orange") xor ($NAME eq "gtag_weis")); # Hier nur GTAG Namen der Gäste (Roomguest)
my $ROOMMATE = ("$RESIDENT" . "$ALIASNAME"); # Residentsname zusammenbauen

if (ReadingsVal($NAME,'presence',$NAME) eq "absent") {
fhem("set $ROOMMATE absent"); # Resisents Status von Roommates setzen
}
elsif(ReadingsVal($NAME,'presence',$NAME) eq "present") {
fhem("set $ROOMMATE home"); # Resisents Status von Roommates setzen
}
}
</pre>
<br>

=== Mit Notify und Fenster/Tür. -Kontakt Überwachung ===

Erweiterung für die Überwachung von Fenster/Tür. -Kontakten. Dazu sind zwei weitere Notifys notwendig die auf die Trigger der Kontakte regagieren
und so eine weitere Funktion in der 99_myUtils.pm ansprechen. Die Notifys triggern auf Kontakte die mit dem Namen Kontakt* beginnen.
Sollten die eigenen Fenster/Tür. -Kontakt anderen Namen besitzen, müssen die Skripte dementsprechend angepasst werden.
<pre>
define Alarm_Kontaktmeldung notify Kontakt.*:contact:.* {Kontakt_Meldung("$EVTPART1", "$NAME")}
</pre>
<pre>
define Alarm_Sabotagealarm notify Kontakt.*.sabotageError:.on {Kontakt_Sabotage("$EVTPART1", "$NAME")}
</pre>

Zusätzlicher Code für die 99_myUtils.pm um die TÜRKONTAKTE-Meldung nutzen zu können:
<pre>
### TÜRKONTAKTE-Meldung/Zustand
sub Kontakt_Meldung($$) {
my ($EVENT, $NAME) = @_;
my $ALIASNAME = AttrVal($NAME,'alias',$NAME);
Log 1, "$ALIASNAME wurde $EVENT";
if (ReadingsVal("Alarm", "state", "on") eq "on") {
fhem("set teleBot send $ALIASNAME wurde $EVENT"); # Nachricht über Telegram
# fhem("set Infopush msg '$ALIASNAME' '$ALIASNAME wurde $EVENT'"); # Nachricht über Pushover
}
}

### TÜRKONTAKTE-Sabotagealarm

sub Kontakt_Sabotage($$) {
my ($EVENT, $NAME) = @_;
my $ALIASNAME = AttrVal($NAME,'alias',$NAME);
Log 1, "$ALIASNAME meldet Sabotagealarm";
fhem("set teleBot send Alarm: $ALIASNAME meldet Sabotagealarm"); # Nachricht über Telegram
# fhem("set Infopush msg 'Alarmanlage' '$ALIASNAME meldet Sabotagealarm' '' 2 ' ' 60 600 "); # Nachricht über Pushover
}
</pre>
<br>

=== Hinweis zur Benutzung / Fehlerhandling ===

Der Alarm dummy hat den Zustand on:off. Die Bezeichnungen und Namen müssen 1:1 übernommen werden damit das Script funktioniert.
Andernfalls müssen die Bezeichnungen für z.B. absent:unterwegs und present:anwesend - angepasst werden.
Die Benachrichtigung kann aktuell per ''Telegram'' sowie ''Pushover'' ('''Achtung mit zweiterem sind Abokosten verbunden!''') realisiert werden.
Diskussion zum Thema im Forum unter: {{Link2Forum|Topic=64080}}
<br>

= 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.
<syntaxhighlight lang="bash">
ps -ef | grep lepresenced
sudo kill <pid>
</syntaxhighlight>

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.}}

Der Log Level muss im lepresenced-Skript selbst verändert werden. Um den Log-Level auf INFO/WARNING/DEBUG zu setzen, dass Skript lepresenced mit einem Editor öffnen und die Stellen, wo LOG_WARNING zu finden sind durch den nötigen LOG-Eintrag ersetzen.

<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>

Bei '''Problemen mit der Batterieüberwachung''' der Tags kann die Pi Firmeware mit folgenden Befehl auf eine ältere Version zurückgesetzt werden.
Fehlermeldung beim Aufruf des lebattery oder anderen Batterietestskripten:
<pre>connect: Connection refused (111)</pre>

Lösung (vorübergehend)
<pre>
sudo rpi-update 8521fd34c8f66b6d109acce943f6e25ec93ec005
</pre>

Mehr dazu unter: {{Link2Forum|Topic=56960|Message=589165}}

'''Das BT-Device ist ständig "absent"'''<br>
Eine Mögliche Lösung kann sein, dass Paket bluez-hcidump zu installieren. Das Werkzeug hcidump erlaubt die Beobachtung von Bluetooth-Aktivität.
Dies ist nicht notwendig, wenn bereits bluez installiert ist, da dies Teil des bluez Paketes ist
<pre>
sudo apt-get install bluez-hcidump
</pre>

'''Fehler in Logdateien /var/log/syslog und /var/log/kernel'''
Jul 29 15:08:11 raspberrypi kernel: [ 4905.634211] bt_err_ratelimited: 1 callbacks suppressed
Jul 29 15:08:11 raspberrypi kernel: [ 4905.634231] Bluetooth: hci0 advertising data length corrected
Jul 29 15:08:12 raspberrypi kernel: [ 4906.647350] Bluetooth: hci0 advertising data length corrected
Jul 29 15:08:13 raspberrypi kernel: [ 4907.532081] Bluetooth: hci0 advertising data length corrected
Jul 29 15:08:13 raspberrypi kernel: [ 4907.655564] Bluetooth: hci0 advertising data length corrected

Die Ursache des Problems ist noch nicht ergründet, allerdings betrifft dies aktuell nur den RPi3. Die Fehlermeldungen werden in verschiedene log's geschrieben. Darunter maßgeblich "syslog" und "kern.log".

Lösung (vorübergehend)
Unterbinden der Einträge durch Anlage eines blocklist Eintrag:

1. Unter "/etc/rsyslog.d" eine Datei erzeugen mit dem Namen "01-blocklist.conf"
2. Inhalt: (Die Ausdrücke in den "" sind diejenigen, die aus dem log verschwinden sollen. - bei mir waren es die unten stehenden")
:msg,contains,"Bluetooth: hci0 advertising data length corrected" stop
:msg,contains,"bt_err_ratelimited:" stop
3. Dienst neu starten "sudo service rsyslog restart"

Weiter Infos werden im offiziellen Thema {{Link2Forum|Topic=28753|Message=499184|LinkText=hier}} diskutiert.

Seit Version 0.82 kann es beim Start zu folgenden Meldungen im Log kommen.
Sep 06 16:13:45 raspberrypi systemd[1]: Started lepresenced.
Sep 06 16:13:45 raspberrypi lepresenced[16010]: [tid:1] main::bluetooth_scan_thread: Received 'Set scan parameters failed: Input/output error', ...tting...
Sep 06 16:13:46 raspberrypi lepresenced[16010]: [tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...

Diese Meldungen können ignoriert werden. Abhilfe schafft sich lepresenced selbst indem es sich resettet.

'''Moderne iPhones und Android Geräte wechseln zum "deep standby" Modus''', und werden dann als "abwesend" gemeldet.
Mittels einer Funktion, die via hping3 Packete an den Geräte senden, um die "wach" zu halten, und dann die MacAdresse ausliest, kann man dieses Problem umgehen. Mehr im Forum [https://forum.fhem.de/index.php/topic,76342.0.html]

= Versionsänderungen lepresenced =
<pre>
--Version 0.81 (BasisVersion)
--Version 0.82 (stable 08/2017)
-Neue Kommandozeilenoption "--debug": Startet lepresenced im Vordergrund und gibt ausführliche Debug-Informationen auf STDOUT aus.
-Sanity Check: lepresenced prüft beim Starten die Verfügbarkeit von hciconfig, hcitool und hcidump.
-Model: lepresenced übermittelt das Reading model nun als lan-lepresenced. Das erlaubt die Erkennung von lepresenced in der FHEM-Statistik (sofern aktiviert).
--Version 0.83 (stable 09/2017)
- Behebung von Systemstart Fehlern
- Weitere Debug-Möglichkeiten. U. a. wird nun mitgezählt, ob hcitool lescan ("legacy") und hcidump eine identische Zahl an Beacons empfangen
</pre>

= Ansprechpartner =
# {{Link2FU|117|markusbloch }} (Markus) für das PRESENCE-Modul und collectord
# {{Link2FU|5068|PatrikR}} (Patrick) für lepresenced
# [[Benutzer Diskussion:Devender|Devender]] ({{Link2FU|20043|Dirk}}) für Wiki und Doku

Twilight Anwendungsbeispiel

2018-04-05T19:43:52Z

Mikka: Es gibt keine if-Schleifen ;-)

Das Modul Twilight errechnet verschiedene Dämmerungsphasen und kalkuliert daraus einen wetter- und dämmerungsabhängigen Lichtwert, der den Grad der Außenhelligkeit angibt. Hier soll an einem Beispiel der Einsatz dieses Moduls zur Steuerung eines Ambient-Lichtes und einer Vitrinenbeleuchtung gezeigt werden.

Ziel: Eine indirekte Beleuchtung, z. B. im Wohnzimmer, soll sich, sobald es zu dämmern anfängt bzw. wetterabhängig schon früh "gefühlt" dunkler wird, eingeschaltet werden. In diesem Beispiel wird eine dimmbare indirekte Beleuchtung (ein LED-Lichtschlauch) verwendet. Die Helligkeit des Lichtschlauchs soll bei nur leichter Dämmerung maximal sein und soll sich dann bei Dunkelheit bis auf 20% reduzieren. Die Vitrinenbeleuchtung (ebenfalls LED) soll ebenfalls nur dann eingeschaltet sein, wenn es nicht taghell ist, da man die da sowieso nicht sieht. Nachts soll die Beleuchtung natürlich nicht an sein, dazu wird hier auf eine Variable "Anwesend" zurückgegriffen, die beim Autor als Indikator für Nacht und Abwesenheitsbetrieb verwendet wird. Dies kann individuell angepasst werden. Anwesend=2 bedeutet "Die Bewohner sind im Bett" und Anwesend=4 bedeutet "Die Bewohner sind abwesend".

Neben der automatischen Beleuchtung soll auch ein manuelles Eingreifen möglich sein. So kann über einen Wandtaster sowohl das AmbientLight als auch die Vitrinenbeleuchtung ein- oder ausgeschaltet werden, wobei die Automatik nach einer bestimmten Zeit automatisch wieder greifen soll. Hier werden ein Homematic-Schaltaktor und ein Homematic-Dimmer verwendet, das Beispiel lässt sich leicht auf andere Komponenten übertragen.

Zur Realisierung wurden einige Perl-Schnipsel in ein externes Modul ausgelagert, weil dies wesentlich übersichtlicher ist als die Inline-Definition in der fhem.cfg. Als Basis kann das Modul 99_Utils.pm genommen werden. Der Autor hat diese Datei kopiert, das Modul umbenannt, und den zusätzlichen Code eingetragen.

== Definition des Twilight-Devices ==

Um überhaupt die Lichtwerte zur Verfügung zu haben, muss zunächst in der fhem.cfg ein Twilight-Device erzeugt werden. Hierzu wird folgender Aufruf verwendet:

Syntax: <code>define <name> Twilight <Längengrad> <Breitengrad> <Indoor_Horizont> <Yahoo-Wetter-ID></code>

Beispiel für Helgoland:
<pre>
define T twilight 54.18258 7.885938 1 709403
</pre>

Hier beispielhaft eine Eingabe direkt per telnet in FHEM auf Port 7072

=== Code ===
<pre>
define T twilight 54.18258 7.885938 1 709403

list T
Internals:
CFGFN
DEF 54.18258 7.885938 1 709403
INDOOR_HORIZON 1
LATITUDE 54.18258
LONGITUDE 7.885938
NAME THelgo
NR 751
STATE 6
TYPE Twilight
WEATHER 709403
WEATHER_HORIZON 6
Readings:
2012-03-30 08:40:34 light 6
2012-03-30 08:40:34 nextEvent ss_weather
2012-03-30 08:40:34 nextEventTime 19:13:23
2012-03-30 08:40:34 nextUpdate 08:55:34
2012-03-30 08:40:34 sr 07:10:41
2012-03-30 08:40:34 sr_astro 04:57:56
2012-03-30 08:40:34 sr_civil 06:28:52
2012-03-30 08:40:34 sr_indoor 07:17:33
2012-03-30 08:40:34 sr_naut 05:45:13
2012-03-30 08:40:34 sr_weather 07:51:46
2012-03-30 08:40:34 ss 19:54:28
2012-03-30 08:40:34 ss_astro 22:07:13
2012-03-30 08:40:34 ss_civil 20:36:17
2012-03-30 08:40:34 ss_indoor 19:47:36
2012-03-30 08:40:34 ss_naut 21:19:56
2012-03-30 08:40:34 ss_weather 19:13:23
</pre>

Zu sehen ist hier die Übersicht der entsprechenden Dämmerungszeiten des aktuellen Tages (Details siehe FHEM {{Link2CmdRef|Anker=Twilight}}).

== Berechnung des Automatik-Wertes ==

In folgender Routine wird zunächst abhängig vom Lichtwert und der aktuellen Anwesenheit der Automatikwert für den Lichtschlauch und die Schrankbeleuchtung errechnet. Der Lichtschlauch ist ein Dimmer, erhält also Werte zwischen 0% und 100% und die Vitrine ist ein Schaltaktor, ist also entweder an oder aus.
<pre>
sub calc_a_schlauch{
my $licht=ReadingsVal("T","light","6");
my $anwesend=ReadingsVal("anwesend","state","4");
if($licht eq 6 || $anwesend eq 2 || $anwesend eq 4){
fhem "set a_schlauch 0" ;
fhem "set a_schrank off";
}elsif($licht<6 && $licht>3){
fhem "set a_schlauch 100";
fhem "set a_schrank on";
}elsif($licht>2 && $licht<5){
fhem "set a_schlauch 40";
fhem "set a_schrank on";
}elsif($licht<3){
fhem "set a_schlauch 20";
fhem "set a_schrank on";
}
}
</pre>

Die Ausgangsbedingungen "light" und "anwesend" werden zu Beginn abgefragt. In der darauffolgenden IF-Anweisung wird dann je nach Lichtstärke ein Wert für die beiden Automatikwerte gesetzt. Zu beachten ist, dass die Devices a_schlauch und a_schrank Dummy-Devices sind (siehe fhem.cfg unten). Hier wird noch nicht direkt geschaltet sondern nur ein Wert berechnet und zwischengespeichert.

== Manuelle Schaltung Vitrine ==

Zur manuellen Schaltung wird durch das Drücken eines Tasters folgender Schnipsel ausgeführt, der dann den neuen Manuell-Wert berechnet:
<pre>
sub calc_m_schrank{
my $aktuell = ReadingsVal("m_schrank","state","auto");
my $auto = ReadingsVal("a_schrank","state","off");
if($aktuell eq "off" || ($aktuell eq "auto") && $auto eq "off"){
fhem "set m_schrank on";
}else{
fhem "set m_schrank off";
}
}
</pre>
Die aktuellen Werte für Manuell und Automatik werden zunächst aus den Dummy-Devices abgefragt. Jetzt gibt es zwei Möglichkeiten. Wenn die Vitrine gerade in dem Zustand ist, dass sie schon manuell ausgeschaltet wurde (also $aktuell eq "off"), dann muss sie jetzt eingeschaltet werden. Dies muss auch dann passieren, wenn man gerade im Automatikmodus ist, und eben dieser gerade auf "off" steht. Dies ist wichtig, damit für den Anwender, dem nicht klar ist, in welcher Betriebsart die Beleuchtung gerade ist, bei jedem Tasterdruck auch ein sichtbarer Schaltvorgang ausgelöst wird.

== Manuelle Schaltung LED-Schlauch ==

Die manuelle Schaltung des LED-Schlauchs ist noch etwas aufwendiger, da mehrere Dimmerstufen angefahren werden sollen:
<pre>
sub calc_m_schlauch{
my $aktuell = ReadingsVal("m_schlauch","state",0);
my $auto = ReadingsVal("a_schlauch","state",0);
if($aktuell==0 || ($aktuell==-1 && $auto==0)){
fhem "set m_schlauch 100";
}elsif($aktuell==100){
fhem "set m_schlauch 30";
}elsif($aktuell==30 || ($aktuell==-1 && $auto>0)){
fhem "set m_schlauch 0";
}else{
fhem "set m_schlauch 0";
}
}
</pre>

Das Prinzip ist wie bei der Vitrine. Da hier mit numerischen Werten gearbeitet wird, ist die Bedeutung "Automatik" nicht als "auto" definiert sondern als Zahlenwert "-1". D.h. der Wert für "m_schlauch" kann zwischen -1 und 100 schwanken, wobei im Bereich 0-100 ein manueller Wert gesetzt wird und bei "-1" die Automatik greifen soll.

In der IF-Abfrage wird zunächst der Fall behandelt, dass das Licht komplett aus ist. Dies ist entweder der Fall, wenn es manuell aus ist oder die Automatik greift und diese aber auch auf "0" ist. Der zweite Zweig schaltet den manuellen Wert auf 30 runter, wenn dieser gerade auf 100 ist. In allen anderen Fällen wird das Licht im nächsten Schritt manuell ausgeschaltet.

== Schalten der Aktoren ==

Letztlich müssen natürlich die Aktoren tatsächlich geschaltet werden. Dazu wird folgende "Treiber"-Routine genutzt, die die manuellen und automatischen Werte logisch kombiniert:
<pre>
sub drive_schrank_schlauch{
my $dimmer=dimvalue(ReadingsVal("dim_schlauch","state",0));
my $man=ReadingsVal("m_schlauch","state",0);
my $auto=ReadingsVal("a_schlauch","state",0);
my $newvalue;
my $zeit=60;

if($man==-1){
$newvalue=$auto;
}else{
$newvalue=$man;
$zeit=5;
}
if($dimmer ne $newvalue){
fhem "set dim_schlauch ".$newvalue." 84000 ".$zeit;
}
my $schrank=ReadingsVal("akt_schrank","state","off");
$man=ReadingsVal("m_schrank","state","auto");
$auto=ReadingsVal("a_schrank","state","off");
if($man eq "auto"){
$newvalue=$auto;
}else{
$newvalue=$man;
}
if($schrank ne $newvalue){
fhem "set akt_schrank ".$newvalue;
}

}
</pre>

Hier wird nun zuerst der LED-Schlauch und dann der Schrank behandelt. Zunächst wird sowohl der aktuelle Wert des tatsächlichen Aktors (hier: dim_schlauch) als auch die Manuell- und Automatik-Werte abgefragt. Die Variable $newvalue soll den neuen Schaltwert erhalten. Dies wird deswegen eingesetzt, um einen Schaltbefehl nur dann über Funk zu senden, wenn sich der Zustand geändert hat. Die Variable $zeit wird hier genutzt, um beim automatischen Schalten den Dimmer sehr langsam fahren zu lassen, so dass es zu keiner abrupten merklichen Helligkeitsänderung kommt. Dies geht nur mit Homematic-Dimmern.

In der folgenden IF-Abfrage wird geklärt, ob der Dimmer im manuellen oder automatischen Modus betrieben wird. Dementsprechend wird $newvalue gesetzt. Bei manuellem Betrieb wird die Zeit auf 5 Sekunden runtergesetzt, denn hier soll eine merkliche Helligkeitsänderung in kurzer Zeit nach dem Betätigen des Tasters erfolgen. Stellt sich dann in der kommenden Abfrage heraus, dass der aktuelle Wert des Aktors noch nicht dem von $newvalue entspricht, wird ein tatsächlicher Schaltvorgang ausgelöst. Die Zahl 84000 ist die Einschaltzeit des Dimmers (unwichtig hier, muss nur hoch genug sein, ist aus Sicherheitsgründen nicht auf 0=unendlich - so geht der Dimmer auch bei einem FHEM-Ausfall nach knapp 24 Stunden aus).
Im weiteren Verlauf wird die Vitrine nach dem gleichen Prinzip geschaltet, wobei hier keine Zeit sinnvoll ist.

=== fhem.cfg ===
In der fhem.cfg müssen, damit die Schnipsel funktionieren, neben dem Twilight-Device auch die Dummy-Devices, die beiden Aktoren, und entsprechende At-/Notify-Defines eingetragen werden, die dafür sorgen, dass die Code-Schnipsel ausgeführt werden. Die Definition der beiden Aktoren ist hier nicht aufgeführt und muss individuell eingetragen werden.

<pre>
define a_schlauch dummy
define m_schlauch dummy
define a_schrank dummy
define m_schrank dummy
define T twilight 54.18258 7.885938 1 709403
set m_schlauch -1
set m_schrank auto

define m_a_schlauch notify m_a_schlauch {calc_a_schlauch();;}
define n_abwesend_ambient notify anwesend {fhem "trigger m_a_schlauch";;}
define n_lightchange_ambient notify T:light.* {fhem "trigger m_a_schlauch";;}
define n_d_schlauch notify a_schlauch {drive_schrank_schlauch();;}
define n_d_schlauch2 notify m_schlauch {drive_schrank_schlauch();;}
define n_d_schrank notify a_schrank {drive_schrank_schlauch();;}
define n_d_schrank2 notify m_schrank {drive_schrank_schlauch();;}
define n_m_schlauch_reset notify m_schlauch {fhem "delete temp_at_m_schlauch_reset";;fhem "define temp_at_m_schlauch_reset at +01:00:00 set m_schlauch -1";;}
define n_m_schrank_reset notify m_schrank {fhem "delete temp_at_m_schrank_reset";;fhem "define temp_at_m_schrank_reset at +01:00:00 set m_schrank auto";;}
define n_m_schlauch notify taster_wohn:Btn1.off[^L]* {calc_m_schlauch();;}
define n_m_schrank notify taster_wohn:Btn2.on[^L]* {calc_m_schrank();;}
</pre>

<code>m_a_schlauch</code> ist ein Makro, was hier überflüssig erscheint, aber sinnvoll ist, wenn man einen Perl-Aufruf von verschiedenen Stellen aus antriggern will, so ist man unabängig vom tatsächlichen Inhalt.

Die Berechnung wird also immer dann angetriggert, wenn entweder der Anwesenheitsstatus oder der Lichtwert sich verändert haben. Die folgenden Notifys reagieren auf Werteänderungen der Automatik- und Manuell-Dummys. Die nächsten beiden Notifys (<code>n_m_schlauch_reset</code> und <code>n_m_schrank_reset</code>) sorgen dafür, dass bei einer Änderung der Manuell-Werte durch das Drücken von Tastern, etc. der Wert nach einer Stunde wieder auf Automatik zurückfällt. Die letzten beiden Notifys reagieren auf genau diese Taster, wobei hier ein Homematic-Wandtaster eingesetzt wird, bei dem nur auf einen kurzen Tastendruck reagiert werden soll.

Der bisherige Code sieht nicht vor, mit den Tastern auch frühzeitig wieder auf Automatik zurückzuschalten. Das kann z. B. mit einem zusätzlichen Taster gemacht werden:

<pre>
define n_tEingang_lichtReset notify taster_eingang:Btn1.offLong.* {lichtReset();;}
</pre>

Hier wird auf den langen Tastendruck eines anderen Tasters reagiert, wobei dieser Notify zündet, sobald man den Taster länger als 0,4 Sekunden festhält, also noch bevor dieser losgelassen wird. Der Code von lichtReset kann dann mehr tun, als nur die beiden hier beschriebenen Beleuchtungen auf Automatik zu setzen. Beispiel:
<pre>
sub lichtReset{
fhem "set m_schlauch -1";
fhem "set m_schrank auto";
fhem "set akt_treppe off";
fhem "set akt_eingang off";
fhem "set akt_esszimmer off";
}
</pre>

== yahoo - Condition Codes ==
<pre>
Condition code Beschreibung Internes Mapping in: sub Twilight_getWeatherHorizon
0 tornado 25
1 tropical storm 25
2 hurricane 25
3 severe thunderstorms 25
4 thunderstorms 20
5 mixed rain and snow 10
6 mixed rain and sleet 10
7 mixed snow and sleet 10
8 freezing drizzle 10
9 drizzle 10
10 freezing rain 10
11 showers 7
12 showers 7
13 snow flurries 7
14 light snow showers 5
15 blowing snow 10
16 snow 10
17 hail 6
18 sleet 6
19 dust 6
20 foggy 10
21 haze 6
22 smoky 6
23 blustery 6
24 windy 6
25 cold 6
26 cloudy 6
27 mostly cloudy (night) 5
28 mostly cloudy (day) 5
29 partly cloudy (night) 3
30 partly cloudy (day) 3
31 clear (night) 0
32 sunny 0
33 fair (night) 0
34 fair (day) 0
35 mixed rain and hail 7
36 hot 0
37 isolated thunderstorms 15
38 scattered thunderstorms 15
39 scattered thunderstorms 15
40 scattered showers 9
41 heavy snow 15
42 scattered snow showers 8
43 heavy snow 5
44 partly cloudy 12
45 thundershowers 6
46 snow showers 8
47 isolated thundershowers 8
not available 1
</pre>

== Zusammenhang STATE und light ==

STATE wird beim Twilight-Modul von 0 - 11 durchgezählt.

0 -> vor astronomischen Aufgang, 1 -> vor nautischem Aufgang, 2 -> vor zivilem Aufgang, 3 -> vor Sonnenaufgang, 4 -> vor Indoor-Aufgang, 5 -> vor "Wetter-Aufgang", 6 -> vor "Wetter-Untergang" (also den meisten Tag lang)

Bis hierher ist light = STATE. Von nun an wird light wieder weniger (es wird ja dunkler) aber STATE schreitet vor, um Sonnenuntergänge von -aufgängen unterscheidbar zu machen.

7 -> vor Indoor-Untergang, 8 -> vor Sonnenuntergang, 9 -> vor zivilem Untergang, 10 -> vor nautischem Untergang, 11 -> vor astronomischem Untergang

Bitte auch bedenken, dass in der Nordhälfte Deutschlands die Sonne astronomisch im Sommer ca. 6 Wochen lang nicht untergeht, State wird also nicht alle Werte durchlaufen und light wird nie 0 sein.

[[Kategorie:Examples]]

EnOcean-FSB61-Aktor-Beschattungselemente-Rollladen

2018-02-08T14:54:52Z

Mikka: Links aktualisiert

{{Infobox Hardware
|Bild=Fsb61np.jpg
|Bildbeschreibung=FSB61NP Fertigungswoche XX/12
|HWProtocol=EnOcean
|HWType=Aktor, Empfänger, ab Fertigungswoche 41/11 auch Sender, Sensor
|HWCategory=EnOcean
|HWComm=EnOcean Funk, 868Mhz
|HWChannels=1 (unidirektional, ab Fertigungswoche 41/11 bidirektional)
|HWVoltage=230V~
|HWPowerConsumption=Eigenverbrauch ca. 0,7W - 0,9W
|HWPoweredBy=230V
|HWSize=45x55x33mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#EnOcean EnOcean]
|HWManufacturer=Eltako
}}

{{Randnotiz|RNText=Seite gilt nur für die '''bidirektionale''' Variante des Aktors ab Fertigungswoche 41/11}}

'''EnOcean-FSB61-Aktor-Beschattungselemente-Rollladen''' ist ein Aktor
* für
** Unterputzmontage
* für
** Steuerung von Rollladen und Beschattungselementen
== Features ==
Aktor für Beschattungselemente und Rolladen (ab Fertigungswoche 41/11 bidirektional)

== Hinweise zum Betrieb mit FHEM ==
Volle Funktionsfähigkeit erfordert, dass die Bestätigungstelegramme am Aktor eingeschaltet sind

=== Definition/Anlernvorgang ===
Der Aktor kann nicht vollautomatisch per autocreate in FHEM angelegt werden.
Die Einbindung in FHEM kann entweder über die Nutzung der inoffiziellen, gerätespezifischen EEP (empfohlen) '''oder''' über die manuelle Vorgehensweise erfolgen.

===== Nutzung der inoffziellen EEP =====
Folgende Schritte sind durchzuführen:
* FHEM-Device <name> (hier: EnO_switch_FSB61) mit dem inoffiziellen EEP für den FSB61 (G5-3F-7F) und der Sender-ID des FSB61 (siehe Rückseite des Aktors; hier: 01036620) durch Eingabe in das [[Konfiguration#Befehl-Eingabefeld|Befehls-Eingabefeld]] definieren:
: <code>define EnO_switch_FSB61 EnOcean 01036620 G5-3F-7F</code>
: Hierdurch wird ein FHEM-Device mit allen grundlegenden Attributen angelegt. Nur das Attribut <code>model</code> muss noch wie unten im Config-Auszug gezeigt mit dem Wert Eltako_FSB61 angelegt werden, bevor das FHEM-Device am Aktor angelernt werden kann.
* Am Aktor
** Oberer Funktions-Drehschalter: auf LRN
** Unterer Funktions-Drehschalter: auf MAX (zum Einlernen PC)
* FHEM Eingabefeld: <code>set EnO_switch_FSB61 teach</code>
* Am Aktor nach dem Einlernen beide Drehschalter in die ursprüngliche Position
* Abschließend müssen die Attribute <code>shutTime</code> und <code>shutTimeCloses</code> für die Laufzeitsteuerung angelegt und mit den individuellen Werten der zu steuernden Jalousien angepasst werden. Infos zu den Attributen finden sich unten im [[#FHEM_Config-Auszug|FHEM-Config-Auszug]].

===== Alternative: manuelle Vorgehensweise =====
Folgende Schritte sind durchzuführen:
* EnOcean-FHEM-Device <name> mit der Sender-ID des FSB (siehe Rückseite des Aktors) definieren
* Das Attribut subDef mit einer freien SenderId des TCMs anlegen ODER falls keine freie Sender-ID bekannt ist, das Attribut komplett weglassen, damit die Vergabe automatisch durch FHEM erfolgt
* Die Attribute subType, model und manufID wie nachfolgend im Config-Auszug anlegen
* Die Attribute shutTime und shutTimeCloses mit individullen Werten anlegen (vgl. Erläuterungen zum Config-Auszug)
* Am Aktor
** Oberer Funktions-Drehschalter: auf LRN
** Unterer Funktions-Drehschalter: auf MAX (zum Einlernen PC)
* FHEM Eingabefeld: „set <name> teach"
* Am Aktor nach dem Einlernen beide Drehschalter in die ursprüngliche Position

=== FHEM Config-Auszug ===
Ein exemplarischer Auszug aus der [[Konfiguration|fhem.cfg]]:
define EnO_switch_FSB61 EnOcean 01036620 <--- SenderID des FSB61 (Aktors)
attr EnO_switch_FSB61 eep A5-3F-7F
attr EnO_switch_FSB61 manufID 00D
attr EnO_switch_FSB61 model Eltako_FSB61
attr EnO_switch_FSB61 subDef AABBCC05 <--- AABBCC05 ist eine der 127 SenderID's des TCM mit der FHEM sendet
attr EnO_switch_FSB61 subType manufProfile
attr EnO_switch_FSB61 webCmd opens:stop:closes
attr EnO_switch_FSB61 shutTime 35
attr EnO_switch_FSB61 shutTimeCloses 40
* '''shutTime''': Zeit (in Sekunden) die der Rollladen von "vollständig geöffnet" bis "vollständig geschlossen" braucht. Diese Zeit verwendet FHEM um die Position des Rollladens zu errechnen. Fährt man den Rollladen von der oberen Endlage mit <pre>set EnO_switch_FSB61 position 50</pre> so fährt der Rollladen die Hälfte der shutTime in Sekunden runter bevor er stoppt. Der Rollladen steht nun in der Position 50%.
* '''shutTimeCloses''': Zeit (in Sekunden), um den Rollladen sicher in eine definierte Endlage zu fahren.
** shutTimeCloses ist größer als shutTime
** shutTimeCloses ist (etwas) größer als die am FSB61 eingestellte Rückfallverzögerung (unterer Drehschalter, 0-120 Sekunden)
: Fährt man den Rollladen von der oberen Endlage mit <pre>set EnO_switch_FSB61 closes</pre> zu, so fährt FHEM den Rollladen shutTimeCloses Sekunden runter -> die untere Endlage wird sicher erreicht und der FSB61 sendet die diesbezügliche Bestätigung.

== Einsatzbeispiel ==
=== Rollladensteuerung in Abhängigkeit von Sonnenauf- und -untergang ===
define RolladenHoch at *{sunrise(0,"07:00","09:00")} set EnO_switch_FSB61 opens
define RolladenZu at *{sunset(0,"17:30","22:00")} set EnO_switch_FSB61 closes

Der Rolladen wird

* morgens zum Sonnenaufgang, aber nicht vor 07:00 und nicht nach 09:00 Uhr hochgefahren und
* abends zum Sonnenuntergang zugefahren, aber nicht vor 17:30 Uhr und nicht nach 22:00 Uhr.

Siehe auch: [[SUNRISE_EL]]

=== Anzeige Rollladenstand im WebFrontend ===
Durch die folgenden zwei Attribute wird der Rollladenstand im WebFrontend bildlich dargestellt:
:<code>attr EnO_switch_FSB61 stateFormat position</code>
:<code>attr EnO_switch_FSB61 devStateIcon down:fts_shutter_100 up:fts_window_2w 1\d.*:fts_shutter_90 2\d.*:fts_shutter_80 3\d.*:fts_shutter_70 4\d.*:fts_shutter_60 5\d.*:fts_shutter_50 6\d.*:fts_shutter_40 7\d.*:fts_shutter_30 8\d.*:fts_shutter_20 9\d.*:fts_shutter_10 \d.*:fts_shutter_90</code>

Siehe auch [[FTUI_Snippets#Rollladen_Circle_Menu|diese Beispiel für Tablet UI]]

== Links ==
* Datenblatt: [https://www.eltako.com/fileadmin/downloads/de/datenblatt/Datenblatt_FSB61NP-230V.pdf PDF]
* Anleitung: [https://www.eltako.com/fileadmin/downloads/de/_bedienung/FSB61NP_30200430-7_dt.pdf PDF]

[[Kategorie:EnOcean Components]]
[[Kategorie:Rollladensteuerung]]

EnOcean Starter Guide

2018-02-08T14:49:17Z

Mikka:

{{Todo|Noch einzuarbeitetende Moduländerungen :: http://forum.fhem.de/index.php/topic,36237.msg285274.html#msg285274: Vereinfachte Anlage von FHEM-EnOcean-Devices gemäß 18 und 19 einarbeiten, Anlage Liste von nicht offiziellen EEPs und Zuordnung zu Geräten, bessere Einbindung von getNextId ++++ http://forum.fhem.de/index.php/topic,42354.0.html: Plot-Anlage einbinden ++++ http://forum.fhem.de/index.php/topic,45810.0.html: RLT}}

<div style="float:right">
{{Infobox Modul
|Name=TCM
|ModPurpose=Einbindung EnOcean-Gateway
|ModType=d
|ModCmdRef=TCM
|ModForumArea=EnOcean
|ModTechName=00_TCM.pm
|ModOwner=klaus.schauer ([http://forum.fhem.de/index.php?action=profile;u=293 Forum] / [[Benutzer Diskussion:Klaus.schauer|Wiki]])
}}
{{Infobox Modul
|Name=EnOcean
|ModPurpose=Ansteuerung EnOcean-Geräte über TCM
|ModType=d
|ModCmdRef=EnOcean
|ModForumArea=EnOcean
|ModTechName=10_EnOcean.pm
|ModOwner=klaus.schauer ([http://forum.fhem.de/index.php?action=profile;u=293 Forum] / [[Benutzer Diskussion:Klaus.schauer|Wiki]])
}}
</div>

== EnOcean ==
[http://www.enocean.com/de/ EnOcean] ist
* ein [http://www.enocean.com/de/enocean-wireless-standard/ ISO ratifizierter Funkstandard], ausgelegt für Funksensoren und Funksensornetze mit besonders niedrigem Energieverbrauch
* ein Anbieter batterieloser Funksensoren
EnOcean-Endgeräte mit dem von der EnOcean Alliance zur Verfügung gestellten EnOcean-Funkprotokoll werden von [http://www.enocean-alliance.org/de/hiererhaeltlich/ zahlreichen Hardware-Herstellern] angeboten.

=== EnOcean Equipment Profile ===
Abhängig von den Funktionen des EnOcean-Endgerätes werden bestimmte veröffentlichte Anwendungs-Profile/Funk-Telegramme, die sogenannten EnOcean Equipment Profiles (EEPs), zur Funkkommunikation genutzt. Technische Details zum EnOcean-Funkprotokoll und insbesondere zu den [http://www.enocean-alliance.org/eep/ EnOcean Equipment Profiles (EEPs)] sind auf der Internetseite der [http://www.enocean-alliance.org EnOcean Alliance] zu finden.

==== Manufacturer Specific Communication ====
EnOcean bietet - neben den veröffentlichten Standard-Enocean-Profilen - die Möglichkeit für die Nutzung von herstellerspezifischen Anwendungs-Profilen/Funk-Telegrammen (MSC = Manufacturer Specific Communication). Falls die Herstellerfirmen den Inhalt dieser MSC-Telegramme nicht veröffentlichen, ist eine Unterstützung durch FHEM grundsätzlich nicht möglich. Teilweise werden die Produkte sowohl mit MSC- als auch mit Standard-Enocean-Profilen vertrieben {{Link2Forum|Topic=19544|Message=132240}}. Angaben zu den verwendeten Profilen/Telegrammen sind den Bedienungsanleitungen der Produkte zu entnehmen.

=== uni- versus bidirektional ===
EnOcean-Endgeräte gibt es sowohl in uni- als auch in bidirektionalen Ausführungen. Bei '''unidirektionalen Endgeräten''' erfolgt die Funk-Kommunikation nur in eine Richtung. Einem Aktor, der Licht schaltet, kann zwar der Befehl zum An- bzw. Ausschalten gegeben werden, er liefert aber keine Rückinformation über die erfolgreiche Ausführung des Befehls. Bei '''bidirektionalen Endgeräten''' erfolgt die Funk-Kommunikation hingegen in zwei Richtungen: sie bieten
# Sende- und
# Empfangsmöglichkeiten.
Der bidirektionale Aktor kann somit unter anderem die erfolgreiche Ausführung eines empfangenen Befehls zurückmelden.

=== SenderID ===
Damit EnOcean Funk-Aktoren (z.B. Relais, Dimmer, Heizungsventil) auf EnOcean Sensoren (z.B. Taster, Temperatursensor, Fensterkontakt, Energieverbrauchsmesser) reagieren können, werden die Sensoren bei den Aktoren eingelernt (Teach-in). So wird festgelegt, dass z.B. "Funktaster 1" den "Dimmer 1" steuert.
Alle EnOcean Geräte mit Sendefunktion haben mindestens eine eindeutige, unabänderliche 8-stellige Hex-SenderID (z.B. ffc54500; teilweise auch dargestellt mit Punkten oder Doppelpunkten dazwischen). Die SenderID ist meist auf den EnOcean Geräten aufgedruckt oder liegt der Verpackung des Endgerätes bei. Beim Anlernvorgang wird die eindeutige SenderID des Sensors in der Empfängertabelle des Aktors gespeichert.

== EnOcean 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_EnOcean-Forum_enthalten.3F|Anfragen im Forum]] die Aktualität von FHEM überprüfen.

Die Nutzung von EnOcean in FHEM ist (nicht nur für den Anfänger) ausschließlich mit der standardmäßig eingeschalteten [[autocreate|autocreate-Funktion]] einfach umsetzbar. 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 EnOcean behandeln, so werden doch wesentliche Punkte für ein Verständnis von FHEM vermittelt.

Im Folgenden und auf den [[:Kategorie:EnOcean 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 SenderIDs der EnOcean-Geräte haben eine zentrale Bedeutung in FHEM. Sie sind eindeutiges Unterscheidungsmerkmal, werden von FHEM im Rahmen der Funkkommunikation genutzt und in der Definition der Geräte bzw. den Attributen des Geräte hinterlegt. Auch wenn FHEM die SenderIDs des Gateways regelmäßig automatisch vergeben kann, ist für einen Überblick über die SenderIDs hilfreich eine Tabelle mit folgender oder ähnlicher Struktur aufzubauen:

<table class="wikitable" border="1">
<tr>
<th> A
</th>
<th> B
</th>
<th> C
</th>
<th> D
</th>
<th> E
</th></tr>
<tr>
<th> Nr.
</th>
<th> Name EnOcean
</th>
<th> Name in FHEM
</th>
<th> HEX (Sender-ID)
</th>
<th> Zimmer
</th></tr>
<tr>
<td>
</td>
<td> <Name Hardwareschalter>
</td>
<td> <Name in FHEM>
</td>
<td> <HEX Code>
</td>
<td> <Raumname>
</td></tr>
<tr>
<td>
</td>
<td> TCM_ESP3_0
</td>
<td> TCM_ESP3_0
</td>
<td> AABBCC00
</td>
<td>
</td></tr>
<tr>
<td> 1
</td>
<td> EnO_switch_123456
</td>
<td> eg_fl_Licht
</td>
<td> AABBCC01
</td>
<td> EG_Flur
</td></tr>
<tr>
<td> ...
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td></tr>
<tr>
<td> 128
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td></tr></table>

== Definition von TCM / Gateway ==
FHEM kann mit einem Funkgateway, das auf einem TCM-Modul basiert, EnOcean-Funk empfangen und senden.
Bisher gibt es zwei Transceiver Chips von EnOcean:
* TCM120 (ausgelaufen)
** für den USB-Port: [https://embedded-intelligence.de/de/products/hardware/bsc-bor.html BSC BOR]
* TCM310
** als USB-Stick: [http://www.enocean.com/de/enocean_module/usb-300-oem/ USB 300] und [http://busware.de/tiki-index.php?page=EUL Busware EUL]
** als Aufsteckmodul für Raspberry Pi: [http://www.enocean.com/de/enocean-pi/ EnOceanPi]<BR>
::* Beim Raspberry Pi 3 muss der GPIO-Port auf den Hardware-UART0 umgestellt werden: [[Raspberry Pi 3: GPIO-Port Module und Bluetooth]]
::* Die seriellen Schnittstelle /dev/ttyAMA0 muss am Raspberry Pi freigeschaltet werden, damit das EnOceanPi-Modul funktionsfähig ist. Zur Vorgehensweise siehe: {{Link2Forum|Topic=14814|Message=95265}}

Zudem existiert eine {{Link2Forum|Topic=22635|Message=160582|LinkText=Lösung zur kabelgebundenen Anbindung}} des FHEM-Rechners mittels Eltako FGW14 an den [[EnOcean-Eltako-RS485-Bus|Eltako RS485-Bus]], über die sowohl Busaktoren als auch EnOcean-Funkaktoren gesteuert werden können und auch EnOcean-Funktelegramme über das [[EnOcean-Eltako-RS485-Bus|FAM14 Funkantennenmodul]] am RS485-Bus empfangen werden können.

Das TCM-basierte Gateway wird unter Linux nach Anschluss an den FHEM-Rechner beim 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 TCM-Moduls oder Eingriffe in die Konfiguration sind normalerweise nicht notwendig. Werden am FHEM-Server unter Linux mehrere USB-Gateways eingesetzt, empfiehlt es sich zur Erhöhung der Betriebsstabilität das TCM-Gateway über [[Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden|Serial-by-Id]] anzusprechen. Unter Windows ist ein manuelles Anlegen der Definition des TCM-Gateways wegen fehlender Unterstützung des Befehls <code>usb scan</code> notwendig.

Bei RS485-basierte Gateways (bspw. FGW14) muss in der [[Konfiguration]] zusätzlich manuell das Attribut <code>comType</code> auf <code>RS485</code> gesetzt werden.

Beispiele der automatisch erzeugten define-Zeile in der Konfiguration:

EnOceanPi an Raspberry Pi:
define TCM_ESP3_0 TCM ESP3 /dev/ttyAMA0@57600

TCM310/USB300 an Fritzbox oder Raspberry Pi:
define TCM_ESP3_0 TCM ESP3 /dev/ttyUSB0@57600

Hier folgt ein Beispiel der define-Zeile in der Konfiguration für kabelgebundene Anbindung mit FGW14 über serielle Schnittstelle
define TCM_ESP2_0 TCM ESP2 /dev/ttyS3@57600
attr TCM_ESP2_0 comType RS485 <---- Manuell zu setzen

Nach erfolgreicher Definition ist das Gateway im Raum "Everything" in der Gruppe "TCM" zu finden. Wenn neben dem Gatewaynamen "initialized" oder "opened" angezeigt wird, ist FHEM in der Lage mit den EnOcean-Geräten zu kommunizieren.

Wie im [[#SenderID|Einführungsabschnitt]] bereits erläutert hat jedes sendende EnOcean-Endgerät mindestens eine eindeutige SenderID. Diese SenderID kann aus Sicherheitsgründen nicht vom EnOcean-Gateway simuliert werden. Vielmehr hat das Gateway eigene SenderIDs, die separat in die Endgeräte/Aktoren angelernt werden müssen. Das Gateway stellt 128 verschiedene SenderIDs zur Verfügung. Ausgehend von der baseID, die bei jedem Gateway grundsätzlich anders ist, werden die SenderIDs fortlaufend hexadezimal hochgezählt:
* FHEM stehen 127 fortlaufende eigene SenderID zur Verfügung
* beginnend mit der baseID des TCM + 1

Die baseID des TCM erhält man durch Eingabe von
get TCM_ESP3_0 baseID
in das Befehl-Eingabefeld (TCM_ESP3_0 gegebenenfalls durch den eigenen Gatewaynamen ersetzen) oder duch Auswahl dieses Befehls in den Objektdetails des FHEM-Gateway-Device.

Das Webfrontend zeigt dann beispielsweise:
BaseID=AABBCC00,RemainingWriteCycles=0A
Die niedrigste SenderID in diesem Beispiel ist AABBCC0'''1''' (BaseID=AABBCC00 +1 HEX!!!), die nächste AABBCC0'''2''' usw.

Nach der Definition des Gateways und Ermittlung der baseID des Gateways kann nun der nächste Schritt, die Definition der EnOcean-Geräte in FHEM, erfolgen.

== Definition von Geräten ==
=== Definition / Anlernvorgang (Teach-In) ===
Damit FHEM und EnOcean-Geräte miteinander kommunizieren können, müssen sie miteinander bekannt gemacht werden. Dies geschieht durch Definition des Gerätes in FHEM und den Anlernvorgang. Dazu muss sich FHEM im {{Link2CmdRef|Anker=TCM_learningMode|Label=learningMode}} befinden. Viele Geräte werden von FHEM während des Anlernvorgangs automatisch erkannt und definiert. Dennoch ist ein grundlegendes Verständnis der Anlernvorgänge und Unterscheidungsprinzipen in FHEM und EnOcean notwendig. Sofern das Gerät Bestätigungstelegramme verschicken kann, sind diese zwingend '''vorher''' am Gerät einzuschalten (u.a. Eltako).

FHEM entnimmt die Angaben, wie ein Funk-Telegramm für ein bestimmtes Gerät aufgebaut ist, im Wesentlichen den folgenden Attributen der Definition des Gerätes:
*<code>subtype</code>: FHEM-Profilname, der als Klartextname das genutzte EEP des Gerätes (EEP steht meist in der Bedienungsanleitung des Gerätes) repräsentiert . Einige FHEM-Profile z. B. "roomSensorControl.01" bedienen mehrere ähnliche EEP gleichzeitig.
*<code>manufID</code>: Code für den Hersteller des Gerätes (Übersetzungstabelle Code zu Name ist in der [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/10_EnOcean.pm 10_EnOcean.pm] unter %EnO_manuf)
*<code>model</code>: Modell des Gerätes
*<code>eep</code>: EEP des Gerätes. Unter anderem werden die Informationen zur automatischen Anlage von [[FileLog]], [[SVG]] und des Attributs <code>webCmd</code> anhand des EEPs ermittelt.
Während des Anlernvorgangs werden diese Angaben von FHEM soweit wie möglich automatisch in der Definition vorbelegt. Hinweise zu den Besonderheiten von bestimmten Geräten und EEP finden sich oft in der {{Link2CmdRef|Anker=EnOcean}} zu EnOcean. Darum bitte immer in der commandref zunächst nach dem speziellen Gerät (Modellbezeichnung) suchen, wenn dies keinen Treffer liefert nach dem verwendeten EEP suchen. Die gegebenen Hinweise und Erläuterungen dort beachten.

Die Definition und der Anlernvorgang unterscheiden sich je nach Gerätetyp:
* Sensoren:
** [[#Schalter/Switch|Schalter (EEP RPS)]]: werden automatisch beim ersten empfangenen Funktelegramm in FHEM mit den notwendigen Attributen angelegt.
** [[#Kontakte|Kontakte (EEP 1BS)]]: werden automatisch beim ersten empfangenen Funktelegramm in FHEM mit den notwendigen Attributen angelegt.
** [[#Sonstige_Sensoren|Sonstige Sensoren (EEP 4BS)]]: Durch Versand eines speziellen Anlern-Funktelegramms können sie in FHEM automatisch mit den notwendigen Attributen angelegt werden. Im Anlerntelegramm übermittelt der Sensor FHEM die EEP-Profilangabe und die Hersteller-ID. Aufgrund dieser Angaben kann FHEM das Gerät eindeutig erkennen und die richtigen Attribute in FHEM setzen. Einige wenige Sensoren verschicken leider ein Anlerntelegramm ohne EEP-Profilangabe und/oder Herstellerangabe (Bsp: Omnio Ratio eagle-PM101). Bei diesen Sensoren müssen die Attribute subType, manufID und/oder model manuell in FHEM gesetzt werden, damit eine richtige Auswertung der Funktelegramme erfolgt.
* Aktoren (4BS, VLD, UTE, MSC): Bei den Aktoren gibt es je nach Gerätetyp verschiedene Anlernvorgänge, die unterschiedlich in FHEM ausgeführt werden. Einige Aktoren unterstützen auch mehrere Anlernvorgänge. Grundsätzlich muss wegen abweichender Vorgehensweise in FHEM unterschieden werden zwischen
** [[#uni- versus bidirektional|unidirektionalen]] Aktoren und
*** [[#Teach-In_als_Tasteremulation|Teach-In als Tasteremulation]]
*** [[#Teach-In_als_Gateway.2FPC-Steuerung|Teach-In als Gateway/PC-Steuerung]]
** [[#uni- versus bidirektional|bidirektionalen]] Aktoren
*** [[#Teach-In_als_Tasteremulation_2|Teach-In als Tasteremulation]]
*** [[#Unidirektionales_4BS-Teach-In|Unidirektionales 4BS-Teach-In]]
*** [[#Bidirektionales_4BS-Teach-In|Bidirektionales 4BS-Teach-In]]
*** [[#UTE-Teach-In|UTE-Teach-In]]

In den nachfolgenden Gliederungspunkten wird beispielhaft für je ein Gerät aus den obigen Gerätetypen die Einbindung in FHEM erläutert.

Grundlegend gilt immer:
FHEM legt sendende, noch nicht definierte EnOcean Geräte selbst an, wenn
* in Konfiguration autocreate aktiviert ist:
** <code>{{Link2CmdRef|Lang=de|Anker=autocreate|Label=define autocreate autocreate}}</code>
* FHEM/das TCM-Modul sich im <code>learningMode</code> befindet und
* FHEM eine Nachricht vom noch nicht definierten EnOcean Gerät empfängt
Im Webfrontend werden automatisch angelegte neue Geräte im Raum "EnOcean" angezeigt.

=== Sensoren ===
'''Sensoren Beispiele:'''

==== Schalter/Switch ====
[[EnOcean-PTM-210-Taster|PTM 210 - Schaltermodul]] ([http://www.enocean.com/de/enocean_module/ptm-210-data-sheet-pdf/ Datenblatt])

EEP: F6-02-xx

FHEM in den learningMode (<code>set <nowiki><IODev> teach <time/s></nowiki></code>) versetzen, dazu im Befehl-Eingabefeld eingeben:
set TCM_ESP3_0 teach 600

Dann einen beliebigen Taster des Moduls drücken (und loslassen). Beim Drücken des Tasters wird vom Taster eine Nachricht ausgesendet, die von FHEM empfangen wird. Daraufhin definiert FHEM automatisch den Taster und der Taster ist in FHEM angelernt. FHEM fügt dazu folgenden Code zur Konfiguration hinzu:
* exemplarischer Auszug aus Konfiguration
define EnO_switch_FFC54500 EnOcean FFC54500 <-- "FFC54500" ist die 8-stellige Hex-SenderID des Tasters
attr EnO_switch_FFC54500 IODev TCM_ESP3_0
attr EnO_switch_FFC54500 room EnOcean
attr EnO_switch_FFC54500 subType switch <-- handelt sich um einen Schalter
# attr EnO_switch_FFC54500 eventMap AI:off A0:on BI:an B0:aus <-- bei Bedarf ... die gemapten Werte (hier: off, on, an, aus) sollen eindeutig sein
define FileLog_EnO_switch_FFC54500 FileLog ./log/EnO_switch_FFC54500-%Y.log EnO_switch_FFC54500
attr FileLog_EnO_switch_FFC54500 logtype text

Ein Schalter (hier: FT55) hat vier Taster:
{|
| '''Taster''' || '''in FHEM'''
|-
| links oben || A0
|-
| links unten || AI (nicht "eins" sondern "i"!)
|-
| rechts oben || B0
|-
| rechts unten || BI
|}

Das Log FileLog_EnO_switch_FFC54500 zeichnet beim einmaligen Drücken des linken unteren Tasters ("AI") folgendes auf:
2014-01-01_07:00:01 EnO_switch_FFC54500 buttons: pressed
2014-01-01_07:00:01 EnO_switch_FFC54500 channelA: AI
2014-01-01_07:00:01 EnO_switch_FFC54500 AI
2014-01-01_07:00:02 EnO_switch_FFC54500 buttons: released

Der angelegte Sensor repräsentiert im Webfrontend den physischen Schalter (bspw. an der Wand). Ein Druck auf den physischen Taster ändert den Zustand im Webfrontend. Jedoch führt ein Schalten des Repräsentanten im Webfrontend nicht zu einer Schaltung des Aktors.

FHEM kann sich '''nicht''' als einer der vorhandenen (automatisch angelegten) physischen Sensoren ausgeben (um z.B. das Licht zu schalten), sondern verwendet eigene SenderIDs. Diese FHEM-eigenen SenderIDs können in EnOcean-Aktoren eingelernt werden, damit die Aktoren auf FHEM reagieren [[#Aktoren|siehe unten]].

==== Kontakte ====
[[EnOcean-STM-250-Fenster-T%C3%BCrkontakt|STM 320 Batterieloses Magnetkontakt-Funkmodul]] ([http://www.enocean.com/de/enocean_module/stm-320-data-sheet-pdf/ Datenblatt])

EEP: D5-00-01

FHEM in den learningMode versetzen, dazu im Befehl-Eingabefeld eingeben:
set TCM_ESP3_0 teach 600

Anlerntelegramm laut Anleitung verschicken oder Magnetkontakt öffnen und schließen.

Der Kontakt wird automatisch in FHEM definiert und ist angelernt.

* exemplarischer Auszug aus Konfiguration
define EnO_contact_0000FF53 EnOcean 0000FF53
attr EnO_contact_0000FF53 IODev TCM_ESP3_0
attr EnO_contact_0000FF53 room EnOcean
attr EnO_contact_0000FF53 subType contact
define FileLog_EnO_contact_0000FF53 FileLog ./log/EnO_contact_0000FF53-%Y.log EnO_contact_0000FF53
attr FileLog_EnO_contact_0000FF53 logtype text
attr FileLog_EnO_contact_0000FF53 room EnOcean

==== Sonstige Sensoren ====
===== 4BS-Teach-In =====
FHEM in den learningMode versetzen, dazu im Befehl-Eingabefeld eingeben:
set TCM_ESP3_0 teach 600
Dann das Anlerntelegramm laut Bedienungsanleitung am Sensor auslösen. Der Sensor wird dann automatisch in FHEM definiert und ist angelernt.

===== Profilloses 4BS-Teach-In =====
Omnio Ratio eagle-PM101 Licht- und Anwesenheitssensor ([http://www.omnio.ch/content-en/downloads/Betriebsanleitungen/2902000_Betriebsanleitung_ea.pdf Betriebsanleitung])

FHEM in den learningMode versetzen, dazu im Befehl-Eingabefeld eingeben:
set TCM_ESP3_0 teach 600

Das Anlerntelegramm vom Omnio Ratio eagle-PM101 verschicken (MÖGLICH??)

Im angelegten FHEM-Device manuell das Attribut <code>subType</code> auf <code>PM101</code> setzen.

=== Aktoren ===
Die Bedienungsanleitungen und die commandref liefern Informationen, welche Anlernvorgänge der Aktor unterstützt. Finden sich keine Hinweise auf besondere PC- oder Gateway-Anlernvorgänge, so kann FHEM als "Notlösung" immer als virtueller FHEM-Schalter (Tasteremulation) angelernt werden. Einige Aktoren unterstützen mehrere Arten von Anlernvorgängen. Hier ist der mit den meisten/besten Steuerungsmöglichkeiten zu bevorzugen.

'''Aktoren Beispiele:'''

==== unidirektionale Aktoren ====
Bei unidirektionalen Aktoren steht eine SenderID des TCM-Gateways immer im <code>define</code> des FHEM-Devices. Mit dieser SenderID steuert FHEM den Aktor. Diese SenderID muss dazu im Aktor eingelernt werden.
{{Hinweis|'''MERKE:''' Eine SenderID des TCM-Gateways muss bei unidirektionalen Aktoren immer im <code>define</code> des Devices stehen.<br/>
'''MERKE:''' Bei unidirektionalen Aktoren stimmt der Status des FHEM-Devices im Webfrontend nur mit dem realen Aktorzustand überein, wenn ausschließlich über FHEM gesteuert wird ([[#Physischer_EnOcean-_und_virtueller_FHEM-Schalter_zu_einem_Device_zusammenfassen|Abhilfe]])}}
===== Teach-In als Tasteremulation =====
PEHA 451 FU-EP o.T. (Schaltaktor unidirektional)

Eine [[#Wie ermittelt man freie Sender-IDs des TCM-basierten Funkgateways?|freie SenderID des TCM-basierten Gateways heraussuchen]] und diese als EnOcean-Gerät in FHEM definieren, dazu im Befehl-Eingabefeld eingeben:
define eg_fl_Licht EnOcean AABBCC01

Alternativ kann man FHEM auch anweisen, für das EnOcean-Gerät selbst die nächste freie SenderID zu ermitteln. Die Definition ist dann folgendermaßen vorzunehmen:
define eg_fl_Licht EnOcean getNextID

Anschließend das Attribut <code>subType</code> beim erzeugten Device auf <code>switch</code> setzen. Durch diese Definition wird ein 8-fach EnOcean-Taster erzeugt. Der Taster hat 4 Kanäle (A,B,C,D) zu je 2 Tasten (0,I). Alle diese 8 Taster senden mit der gleichen SenderID des TCM. Das entspricht einem Gerät mit 4 Schaltwippen die jeweils "oben" '''oder''' "unten" gedrückt sein können. FHEM emuliert mit diesem EnOcean-Gerät einen EnOcean-Schalter (darum auch "virtueller FHEM-Schalter"). Der Taster 0 des Kanal A wird "gedrückt" mit <code>set eg_fl_Licht A0</code>.

Dieser virtuelle FHEM-Schalter wird in den Aktor wie ein physischer Schalter eingelernt. Den Aktor in den Anlernmodus bringen (Taste LRN/SET drücken) und den virtuellen FHEM-Schalter betätigen, indem im Befehl-Eingabefeld eingeben wird:
set eg_fl_Licht B0
Wenn der Aktor den erfolgreichen Anlernvorgang signalisiert, den Anlernmodus am Aktor ausschalten.

* exemplarischer Auszug aus Konfiguration
define eg_fl_Licht EnOcean AABBCC01 <--- AABBCC01 ist eine der 127 SenderID's des TCM, mit der FHEM sendet
attr eg_fl_Licht room EG_Flur
attr eg_fl_Licht eventMap BI:off B0:on
attr eg_fl_Licht subType switch
define FileLog_eg_fl_Licht FileLog ./log/ eg_fl_Licht-%Y.log eg_fl_Licht
attr FileLog_eg_fl_Licht logtype text

Der Status des Devices im Webfrontend stimmt bei unidirektionalen Aktoren nur, wenn die Steuerung des Aktors ausschließlich über FHEM erfolgt. Wird der Aktor sowohl über einen physischen Schalter als auch über FHEM gesteuert, so müssen die Status der beiden Devices für physischen und virtuellen Schalter im Webfrontend verknüpft werden, damit der richtige Status des Aktors angezeigt wird ([[#Physischer EnOcean- und virtueller FHEM-Schalter zu einem Device zusammenfassen |siehe unten]]).

===== Teach-In als Gateway/PC-Steuerung =====
"ältere" Eltako FSB61 (Produktionszeitraum KW 43/10 - KW 40/11 [http://www.eltako.com/fileadmin/downloads/de/_bedienung/FSB61NP_30200420-3_dtsch.pdf Bedienungsanleitung])

EEP: A5-3F-7F

Eine [[#Wie ermittelt man freie Sender-IDs des TCM-basierten Funkgateways?|freie SenderID des TCM-basierten Gateways heraussuchen]] und diese als EnOcean-Gerät in FHEM definieren, dazu im Befehl-Eingabefeld eingeben:
define eg_fl_Rollo EnOcean AABBCC02

Alternativ kann man FHEM auch anweisen, für das EnOcean-Gerät selbst die nächste freie SenderID zu ermitteln. Die Definiton ist dann folgendermaßen vorzunehmen:
define eg_fl_Rollo EnOcean getNextID

Beim erzeugten FHEM-Device muss das Attribut <code>subType</code> auf <code>manufProfile</code> gesetzt werden. Die Attribute <code>manufID</code> und <code>model</code> sind auf die unten in der Konfiguration gezeigten Werte zu setzen.

Dieser virtuelle FHEM-Schalter wird in den Aktor als PC/Szenentaster angelernt indem im Befehl-Eingabefeld eingeben wird:
set eg_fl_Rollo teach
Wenn der Aktor den erfolgreichen Anlernvorgang signalisiert, den Anlernmodus am Aktor ausschalten.

* exemplarischer Auszug aus Konfiguration
define eg_fl_Rollo EnOcean AABBCC02 <--- AABBCC02 ist eine der 127 SenderID's des TCM, mit der FHEM sendet
attr eg_fl_Rollo room EG_Flur
attr eg_fl_Rollo subType manufProfile
attr eg_fl_Rollo manufID 00D
attr eg_fl_Rollo model Eltako_FSB61

Der Status des Devices im Webfrontend stimmt bei unidirektionalen Aktoren nur, wenn die Steuerung des Aktors ausschließlich über FHEM erfolgt. Wird der Aktor sowohl über einen physischen Schalter als auch über FHEM gesteuert, so müssen die Status der beiden Devices für physischen und virtuellen Schalter im Webfrontend verknüpft werden, damit der richtige Status des Aktors angezeigt wird ([[#Physischer EnOcean- und virtueller FHEM-Schalter zu einem Device zusammenfassen |siehe unten]]).

==== bidirektionale Aktoren ====
Bei bidirektionalen Aktoren steht die SenderID des Aktors im <code>define</code> des FHEM-Devices. FHEM ordnet empfangene Bestätigungstelegramme anhand der Aktor-SenderID dem passenden FHEM-Device zu. Eine SenderID des TCM-Gateways mit der FHEM den Aktor steuert steht bei bidirektionalen Aktoren immer im Attribut <code>subDef</code>. Diese SenderID muss dazu im Aktor eingelernt werden.
{{Hinweis|'''MERKE:''' Eine SenderID des TCM-Gateways muss bei bidirektionalen Aktoren immer im Attribut <code>subDef</code> des Devices stehen.<br/>
'''MERKE:''' Bei bidirektionalen Aktoren stimmt nach korrekter Einbindung in FHEM der Status des FHEM-Devices im Webfrontend immer mit dem realen Aktorzustand überein.}}
===== Teach-In als Tasteremulation =====
[[EnOcean-FSR61VA-10A-Stromsto%C3%9F-Schaltrelais_mit_Strommessung|10A-Stromstoß-Schaltrelais mit Strommessung FSR61VA]]<br/>
Schaltrelais (bidirektional)

FHEM in den learningMode versetzen, dazu im Befehl-Eingabefeld eingeben:
set TCM_ESP3_0 teach 600

Die [[#SenderID|SenderID]] des Aktors heraussuchen und diese als EnOcean-Gerät in FHEM definieren, dazu im Befehl-Eingabefeld eingeben:
define EnO_switch_FSR61VA EnOcean FFAABBC0

Eine freie SenderID des TCM-basierten Gateways heraussuchen und diese im Attribut <code>subDef</code> des angelegten Devices hinterlegen.

Anschließend die Attribute <code>subType</code> und <code>switchMode</code> wie im unten wiedergegebenen exemplarischen Auszug aus der Konfiguration anlegen.

Damit der FSR61VA auf FHEM reagieren kann (Ein/Ausschalten), wird das FHEM-Device EnO_switch_FSR61VA in den FSR61VA als Richtungstaster (bzw. Taster ein/aus) eingelernt:
# Unterer Drehschalter je nach Produktionswoche des FSR61VA (aufgedruckt):
## bis KW 2/13: "ca. Mitte" (Taster Ein/Aus einlernen)
## ab KW 3/13 bis KW 10/14: "60" (Taster Ein/Aus einlernen)
## ab KW 11/14: "40" (Richtungstaster einlernen)
# Oberer Funktions-Drehschalter: "LRN" (LED blinkt)
# FHEM Eingabefeld: „set EnO_switch_FSR61VA B0“, <Enter> (LED erlischt)
# Oberer Funktions-Drehschalter: Eine der ESV-Einstellungen
# Unterer Funktions-Drehschalter: auf "oo" einstellen (unendlich)

* exemplarischer Auszug aus der Konfiguration
define EnO_switch_FSR61VA EnOcean FFAABBC0 --> EnO_switch_FSR61VA ist ein frei gewählter eindeutiger Name
für das FHEM-Device.
FFAABBC0 ist die erste am Boden des FSR61VA aufgedruckte SenderID.
Damit sendet das FSR61VA den Schaltzustand (B0/BI --> ein/aus)
attr EnO_switch_FSR61VA IODev TCM_ESP3_0 --> TCM_ESP3_0 ist der Name des Devices, mit dem FHEM EnOcean-Funk
sendet und empfängt.
attr EnO_switch_FSR61VA subDef FF998877 --> FF998877 ist eine der 127 SendeIDs des TCM_ESP3_0, damit sendet FHEM an den FSR61VA
attr EnO_switch_FSR61VA subType switch --> es handelt sich um einen EnOcean Schalter (der kann A0, AI, B0, BI,...)
attr EnO_switch_FSR61VA switchMode pushbutton --> als "pushbutton" sendet FHEM bei einem
"set EnO_switch_FSR61VA B0" nach dem Kommando (B0) noch ein "release".
Das brauchts, wenn der FSR61VA als ES oder ESV betrieben wird.
Sonst wird jedes "set"-Kommando vom FSR61VA als
"länger als eine Sekunde gedrückt" interpretiert -> "Tasterdauerlicht".

===== Unidirektionales 4BS-Teach-In =====
[[EnOcean-FSR14-4x-RS485-Bus-Schaltaktor-4-Kanal-Stromsto%C3%9F-Schaltrelais|RS485-Bus-Aktor 4-Kanal-Stromstoß-Schaltrelais FSR14]]<br/>
Schaltrelais (bidirektional)

FHEM in den learningMode versetzen, dazu im Befehl-Eingabefeld eingeben:
set TCM_ESP3_0 teach 600

Die [[#SenderID|SenderID]] des Aktors heraussuchen und diese als EnOcean-Gerät in FHEM definieren, dazu im Befehl-Eingabefeld eingeben:
define EnOcean_switch_FEFF4AF8 EnOcean FEFF4AF8

{{Randnotiz|RNText=Ab {{Link2Forum|Topic=31450|Message=239937|LinkText=Updatestand 04.01.2015}} ist eine manuelle Vergabe einer freien SenderID per <code>subDef</code> nicht mehr notwendig. Beim ersten Senden des "teach"-Befehls an den Aktor wird eine freie SenderID vergeben, sofern keine gültige SenderID eingetragen war.}}
Eine freie SenderID des TCM-basierten Gateways heraussuchen und diese im Attribut <code>subDef</code> des angelegten Devices hinterlegen.

Anschließend die Attribute <code>subType</code> und <code>gwCmd</code> wie im unten wiedergegebenen exemplarischen Auszug aus der Konfiguration anlegen.

Jetzt den Aktor in den Lernmodus versetzen und dann von FHEM das Lerntelegramm verschicken:
set EnOcean_switch_FEFF4AF8 teach
Lernmodus am Aktor ausschalten

* exemplarischer Auszug aus Konfiguration
define EnOcean_switch_FEFF4AF8 EnOcean FEFF4AF8 <--- FEFF4AF8 ist hier die SenderID eines FSR14-Kanals (Aktor)
attr EnOcean_switch_FEFF4AF8 subDef AABBCC03 <--- AABBCC03 ist eine der 127 SenderID's des TCM, mit der FHEM sendet [[#Taster - physisch und in FHEM|(siehe unten)]]
attr EnOcean_switch_FEFF4AF8 room EnOcean # Der Raum kann angepasst werden
attr EnOcean_switch_FEFF4AF8 gwCmd switching # Wichtig für FSR14
attr EnOcean_switch_FEFF4AF8 subType gateway # Wichtig für FSR14
define FileLog_EnOcean_switch_FEFF4AF8 FileLog ./log/EnOcean_switch_FEFF4AF8-%Y.log EnOcean_switch_FEFF4AF8
attr FileLog_EnOcean_switch_FEFF4AF8 logtype text

===== Bidirektionales 4BS-Teach-In =====
[[EnOcean-MD15-Kleinstellantrieb|Kleinstellantrieb MD15-FTL-xx]]<br/>
Funkgesteuerter, batteriegespeister Kleinstellantrieb für Raumtemperaturregelung (bidirektional)

EEP: A5-20-01

4BS-Bidirektionales-Teach-In:

#Aktor möglichst komplett zurücksetzen, sofern nicht mehr im Original-Auslieferzustand
#Falls vorhanden, alle bisherigen FHEM-Devices des Aktors löschen und nach Speichern der geänderten Konfiguration FHEM neu starten
#FHEM in Lernmodus schalten: <code>set <nowiki><IODev> teach <time/s></nowiki></code>
#Taster am MD15-FTL-xx so lange drücken, bis ein Signalton ertönt. MD15 bestätigt erfolgreichen Anlernvorgang durch das Aufleuchten der Status-LED und 2 Signaltöne
#Aktor wird in FHEM automatisch mit allen notwendigen Parametern angelegt.

* exemplarischer Auszug aus Konfiguration
define EnO_sensor_01000EFA EnOcean 01000EFA
attr EnO_sensor_01000EFA IODev TCM_ESP3_0
attr EnO_sensor_01000EFA comMode biDir
attr EnO_sensor_01000EFA destinationID unicast
attr EnO_sensor_01000EFA manufID 00A
attr EnO_sensor_01000EFA room EnOcean
attr EnO_sensor_01000EFA subDef AABBCC04
attr EnO_sensor_01000EFA subType hvac.01
define FileLog_EnO_sensor_01000EFA FileLog ./log/EnO_sensor_01000EFA-%Y.log EnO_sensor_01000EFA
attr FileLog_EnO_sensor_01000EFA logtype text
attr FileLog_EnO_sensor_01000EFA room EnOcean

===== UTE-Teach-In =====
[[EnOcean-D-452-FU-EBIM-Aktor-2fach|Einbau-Aktor 452 FU-EBIM o.T.]]<br/>
2-Kanal-Multifunktionsaktor (bidirektional) mit Energiemessfunktion

EEP: D2-01-08

UTE-Teach-In:

#Aktor möglichst komplett zurücksetzen, sofern nicht mehr im Original-Auslieferzustand
#Falls vorhanden, alle bisherigen FHEM Devices des Aktors löschen und nach Speichern der geänderten Konfiguration FHEM neu starten
#FHEM in Lernmodus schalten: <code>set <nowiki><IODev> teach <time/s></nowiki></code>
#Aktor-Kanal 0 oder 1 in Lernmodus versetzen (immer nur einen Kanal)
#Aktor-Kanal 0 oder 1 wird in FHEM automatisch mit allen notwendigen Parametern angelegt.
#Das Anlernen für den zweiten Kanal wie nach 3. bis 5. beschrieben wiederholen

Die Kanäle können jetzt geschaltet werden mit:

*FHEM Device für Kanal 0: set <Name_0> on|off 0
*FHEM Device für Kanal 1: set <Name_1> on|off 1

Falls gewünscht, kann der Kanal mit dem Attribut attr <Name_0|1> defaultChannel 0|1 voreingestellt werden. Dann entfällt die Angabe des Kanals im set-Befehl.

Die Statusrückmeldungen mit den aktuellen Werten des Energieverbrauches und der Leistung werden vom Aktor automatisch gesendet. Sie werden sowohl als Telegramme nach EEP D2-01-08 als auch nach EEP A5-11-04 mit unterschiedlichen SenderIDs (vgl. Etikett in Original-Verpackung) gesendet.
Die Rückmeldungen nach EEP D2-01-08 werden von FHEM im Aktor-Device subType actuator.01 berücksichtigt. Die Rückmeldungen nach EEP A5-11-04 werden von FHEM in einem senor-device subType lightCtrlState.02 berücksichtigt.

== Besonderheiten für die Anzeige im WebFrontend ==

=== Aufteilung der Kanäle in unabhängige Devices ===
===== Mehrkanalige bidirektionale Aktoren =====
Mehrkanalige bidirektionale Aktoren (bspw. Eltako FMS61NP) haben teilweise nur eine SenderID und werden daher in FHEM über ein FHEM-Device im Webfrontend abgebildet und gesteuert. Um im WebFrontend für jeden Kanal ein separates FHEM-Device zur Anzeige und Steuerung zu erhalten, kann [[ReadingsProxy|readingsProxy]] genutzt werden.

Zunächst wird der Aktor standardmäßig in FHEM definiert/angelernt und die Funktion geprüft (hier am Beispiel eines Aktor mit dem Namen "Aktor"). Anschließend wird pro Kanal ein readingProxy-Device mit Bezug auf das Reading channelA, channelB, ... angelegt:

#Kanal A zur Steuerung mit on und off
define AktorKanalA readingsProxy Aktor:channelA
attr AktorKanalA setFn {($CMD eq "on")?"A0":"AI";;}
attr AktorKanalA setList off on
attr AktorKanalA valueFn {($VALUE eq "A0")?"on":"off"}
attr AktorKanalA webCmd off:on

#Kanal B zur Steuerung mit on und off
define AktorKanalB readingsProxy Aktor:channelB
attr AktorKanalB setFn {($CMD eq "on")?"B0":"BI";;}
attr AktorKanalB setList off on
attr AktorKanalB valueFn {($VALUE eq "B0")?"on":"off"}
attr AktorKanalB webCmd off:on

Jeder Kanal wird jetzt separat im WebFrontend durch das readingsProxy-Device abgebildet (Statusanzeige) und kann mit diesem gesteuert werden.

Ein ausführlicheres readingsProxy-Beispiel für einen mehrkanaligen Jalousieaktor mit Visualisierung über Slider enthält dieser {{Link2Forum|Topic=59418|Message=512758}}.
[[Datei:EnO_Jalousie_OmnioAktor_REGJ12-04.png|400px|thumb|center|readingsProxy-Beispiel für einen mehrkanaligen Jalousieaktor mit Visualisierung über Slider]]

===== Virtuelle Schalter für unidirektionale Aktoren =====
Um die 4 Kanäle jeweils einzeln als Schalter (einzelne Schaltwippe) im WebFrontend abzubilden kann [[ReadingsProxy|readingsProxy]] genutzt werden. So werden vier Schalter (im unten gezeigten Beispiel: fhemSchalterKanal[A-D]) mit nur einer der 127 eigenen SenderIDs zur Verfügung gestellt.
{{Randnotiz|RNTyp=i|RNText=Ab [[version|Modulversion]] 11866/31.7.2016 besitzen auch virtuelle Schalter die Readings channel[A-D]. Ein readingsProxy sollte seitdem besser von diesen Readings, wie im [[#Mehrkanalige_bidirektionale_Aktoren|vorherigen Abschnitt]] dargestellt, abgeleitet werden. }}
Anders als bei den bekannten bidirektionalen Aktoren und den FHEM-Devices der physischen Schalter, existiert bei den virtuellen Schaltern das Reading channelA, channelB, ... nicht. Daher muss das readingsProxy für den virtuellen Schalter vom Reading state abgeleitet werden:

#Kanal A zur Steuerung mit on und off
define fhemSchalterKanalA readingsProxy fhemSchalter:state
attr fhemSchalterKanalA setFn {($CMD eq "on")?"A0":"AI";;}
attr fhemSchalterKanalA setList on off
attr fhemSchalterKanalA valueFn {$LASTCMD}
attr fhemSchalterKanalA webCmd on:off

#Kanal B zur Steuerung mit on und off
define fhemSchalterKanalB readingsProxy fhemSchalter:state
attr fhemSchalterKanalB setFn {($CMD eq "on")?"B0":"BI";;}
attr fhemSchalterKanalB setList on off
attr fhemSchalterKanalB valueFn {$LASTCMD}
attr fhemSchalterKanalB webCmd on:off

#Kanal C zur Steuerung mit on und off
define fhemSchalterKanalC readingsProxy fhemSchalter:state
attr fhemSchalterKanalC setFn {($CMD eq "on")?"C0":"CI";;}
attr fhemSchalterKanalC setList on off
attr fhemSchalterKanalC valueFn {$LASTCMD}
attr fhemSchalterKanalC webCmd on:off

#Kanal D zur Steuerung mit on und off
define fhemSchalterKanalD readingsProxy fhemSchalter:state
attr fhemSchalteKanalD setFn {($CMD eq "on")?"D0":"DI";;}
attr fhemSchalterKanalD setList on off
attr fhemSchalterKanalD valueFn {$LASTCMD}
attr fhemSchalterKanalD webCmd on:off

Werden diese FHEM-Taster (und etwaige physische Taster) in EnOcean-Aktoren eingelernt (siehe Anleitung des Aktors), so können nun die EnOcean-Aktoren mit physischen Tastern (sendet mit der 8-stelligen SenderID des Tasters) und mit virtuellen FHEM-Readingsproxy-Schaltern (senden mit einer der 127 eigenen SenderIDs) bedient werden.

=== Physischer EnOcean- und virtueller FHEM-Schalter zu einem Device zusammenfassen ===
Um im Webfrontend die Aktionen beider Schalter in einem Element zusammengefasst und damit den realen Zustand bei '''unidirektionalen''' Aktoren zu sehen, kann man eine <code>structure</code> nutzen:
<br />
(Bei bidirektionalen Aktoren ist dies aufgrund der Statusrückmeldungen nicht notwendig. Achtung: Teilweise müssen Statusrückmeldungen/Bestätigungstelegramme erst am Aktor eingeschaltet werden)

#Definition des virtuellen FHEM-Schalters
define fhemSchalter EnOcean AABBCC01 <--- AABBCC01 ist eine der 127 SenderID's des TCM, mit der FHEM sendet
attr fhemSchalter eventMap BI:off B0:on
attr fhemSchalter icon icoBELEUCHTUNG.png
attr fhemSchalter subType switch

#Definition des physischen Tasters (z.B. durch autocreate erzeugt)
define EnO_switch_0021E4BB EnOcean 0021E4BB <--- 0021E4BB ist die (aufgedruckte) 8-stellige SenderID des physischen Tasters
attr EnO_switch_0021E4BB eventMap BI:off B0:on
attr EnO_switch_0021E4BB room EnOcean
attr EnO_switch_0021E4BB subType switch
attr EnO_switch_0021E4BB dummy

#fhemSchalter ist der Name des virtuellen FHEM-Schalters
#EnO_switch_0021E4BB ist der (z.B. per autocreate erstellte) FHEM-Taster
define Gruppe_test_notify structure room fhemSchalter EnO_switch_0021E4BB
attr Gruppe_test_notify eventMap BI:off B0:on
attr Gruppe_test_notify room Gaestezimmer
attr Gruppe_test_notify clientstate_behavior last

Alternativ kann man für diesen Zweck auch ein <code>notify</code> in Verbindung mit <code> setreading <device> state <state></code> nutzen:

define nAbgleich notify EnO_switch_0021E4BB:(on|off) setreading fhemSchalter state $EVENT

== FAQ ==
=== Warum schaltet mein Aktor nicht, wenn ich im WebFrontend auf das Icon für den physischen Taster/Schalter klicke bzw. mit <code>set <device> <command></code> ansteuere? ===
:Aus Sicherheitsgründen können bei EnOcean keine physischen Geräte(-adressen) durch FHEM bzw. das TCM-Gateway emuliert werden. FHEM muss zur Steuerung separat an den Aktor angelernt werden. Dazu eine der TCM-Adressen an den Aktor anlernen.

=== Welche Infos sollten Anfragen im EnOcean-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 devices (Ausgabe von <code>list <device></code>)
* passender Ausschnitt aus Logfile (siehe Link im FHEM-Menü links) generiert mit gesetztem Attribut verbose 5 am TCM-Device (<code>attr <IODev> verbose 5</code>)

=== Wie kann ich zur Fortentwicklung der EnOcean-Module beitragen? ===
* Erfolgreichen Einsatz von neuen/bisher nicht gemeldeten EnOcean-Geräten im Forum mitteilen
* In der {{Link2CmdRef}} als [untested] markierte EEPs bei erfolgreichen Tests im Forum als getestet melden
* Codeschnipsel und Ideen im Forum posten
* Fehler und Probleme im Forum melden
* Wiki: Neue Geräte ins Wiki aufnehmen; Codeschnipsel und Beispiele einpflegen

=== Wie findet man die Sender-ID eines bidirektionalen Aktors? ===
* Aufkleber auf dem Aktor oder beigelegte Information in der Aktorverpackung
* Ermittlung mit FHEM:
# Bestätigungstelegramme am Aktor aktivieren
# Funktaster am Aktor anlernen oder alternativ Taster am örtlichen Steuereingang anschließen
# FHEM in den learningMode versetzen: <code>set <nowiki><IODev> teach <time/s></nowiki></code>
# [[Event monitor|Event Monitor]] aufrufen
# Aktor mit Taster schalten
# Im Event Monitor wird nun die Sender-ID des Aktors durch das Bestätigungstelegramm angezeigt. Sofern ein Funktaster zur Ansteuerung genutzt wird, zeigt der Event Monitor auch dessen Sender-ID.
# FHEM hat mittels autocreate für das Bestätigungstelegramm ein Device angelegt, sofern das vorher noch nicht existierte. Dieses Device kann man nach eventueller Änderung des subType und dem Setzen anderer gegebenenfalls notwendiger Attribute an den Aktor anlernen.

=== Wie ermittelt man freie Sender-IDs des TCM-basierten Funkgateways? ===
FHEM ermittelt eine freie SenderID automatisch, wenn die Definition folgermaßen erfolgt:
* unidirektionaler Aktor:
: <code><nowiki>define <name> EnOcean getNextID <EEP></nowiki></code>
: Im definierten Device ist "getNextID" durch eine freie SenderID des TCMs ersetzt.
* bidirektionaler Aktor:
: <code><nowiki>define <name> EnOcean <SenderId des Aktors> <EEP></nowiki></code>
: Dem definierten Device wird das Attribut <code>subDef</code> mit dem Wert <code>getNextId</code> zugewiesen: <code><nowiki>attr <name> subDef getNextID</nowiki></code>. "getNextID" ersetzt FHEM automatisch durch eine freie SenderID des TCMs

Manuelle Ermittlung der freien SenderIDs, wenn die obige automatische mit FHEM fehlschlägt oder eine manuelle Vergabe gewünscht wird:
* Aus der oben [[EnOcean_Starter_Guide#Vorbereitung|gezeigten Tabelle]]
* Anzeige der nächsten freien Sender-ID: <pre>{EnOcean_CheckSenderID("getNextID", "<IODev>", "0000000")} </pre>
* Auflistung der bereits vergebenen Sender-IDs: <pre>{EnOcean_CheckSenderID("getUsedID", "<IODev>", "0000000")} </pre>
* Auflistung der noch nicht vergebenen Sender-IDs: <pre>{EnOcean_CheckSenderID("getFreeID", "<IODev>", "0000000")} </pre>
Den jeweiligen Befehl in das "[[Konfiguration#Befehl-Eingabefeld|Befehl-Eingabefeld]]" kopieren, <IODev> durch den Namen des TCM-Devices ersetzen und dann Auslösen.

=== Schaltet immer AI ein und A0 aus, BI ein und B0 aus usw. ? ===
Nein. <br>
Das Verhalten der Aktoren ist abhängig vom Hersteller und/oder vom Anlernvorgang. Laut EEP schaltet xI ein und x0 aus. Dies wird von den meisten Herstellern entsprechend umgesetzt. Eltako definiert dies genau andersherum: xI schaltet aus und x0 ein. Analog sind auch die jeweiligen Bestätigungstelegramme der Aktoren herstellerspezifisch festgelegt. Zudem kann bei einigen Aktoren auch je nach Anlernvorgang ein anderes Verhalten erreicht werden; Details enthalten die Bedienungsanleitungen.

=== Wie kann man einen Plot für ein EnOcean-Device anlegen? ===
Bei der manuellen Anlage von Devices über das EEP und bei der automatischen Anlage durch die autocreate-Funktion beim teach-in werden neben dem Device selbst auch das FileLog-Device und -soweit als Vorlage von FHEM mitgeliefert- die SVG-Devices mit .gplot-Datei für die Plots automatisch erzeugt. Manuell sollten die Devices deshalb möglichst über die Vorgabe des EEP erzeugt werden:
* <code><nowiki>define <name> EnOcean <ID> <EEP></nowiki></code> oder
* <code><nowiki>define <name> EnOcean <EEP></nowiki></code>

Beispiel:
<code><nowiki>define test EnOcean A5-04-02</nowiki></code>

Bei bestehenden Devices können die FileLog- und SVG-Devices nachträglich erzeugt werden. Hierzu wird im DEF das entsprechende EEP statt der ID eingetragen und {{Taste|modify <name>}} bestätigt. Nach dem automatischen Anlegen der zugehörigen Devices erscheint dort wieder die ID.

Sollte für das EEP keine .gplot-Vorlage für einen Plot bzw. das SVG-Device existieren, kann ein Plot mit dem [[Plots erzeugen|.gplot-Editor]] erstellt werden.

=== Was muss man beim Einsatz der "set extensions" (on-for-timer, on-till, ...) beachten? ===
Die {{Link2CmdRef|Anker=setExtensions|Label=set extensions}} werden von EnOcean grundsätzlich unterstützt, wenn das Device als
# set-Befehle "on" und "off" automatisch anbietet '''oder'''
# dies manuell durch das Mapping (bspw. <code>eventMap BI:on B0:off</code>) erreicht wird.

Im 1. Fall sind alle "set extensions"-Befehle automatisch funktionsfähig.

Im 2. Fall ist die eventMap jedoch zusätzlich - je nach gewünschten "set extensions"-Befehl - zwingend weiter zu ergänzen:
* on-tor-timer: <code>attr <device> eventMap on-for-timer:on-for-timer BI:on B0:off</code> ({{Link2Forum|Topic=28855|Message=214960}})
* off-tor-timer: <code>attr <device> eventMap off-for-timer:off-for-timer BI:on B0:off</code>
* on-till: <code>attr <device> eventMap on-till:on-till BI:on B0:off</code> ({{Link2Forum|Topic=29993|Message=226886}})
* off-till: <code>attr <device> eventMap off-till:off-till BI:on B0:off</code>
* blink: <code>attr <device> eventMap on-for-timer:on-for-timer BI:on B0:off</code> ({{Link2Forum|Topic=31358|Message=239151}})
* intervals: <code>attr <device> eventMap on-till:on-till BI:on B0:off</code>
Sollen mehrere "set extensions"-Befehle verwendet werden, so sind die obigen Codes entsprechend zu kombinieren.

=== Für mein EnOcean-Gerät gibt es keine spezielle Wiki-Seite; wo finde ich dann Informationen? ===
* In der {{Link2CmdRef}} nach dem Gerät suchen
* In der commandref nach dem verwendeten EEP suchen
* Im Wiki nach einem Gerät mit einer ähnlichen EEP/subType suchen
* Im EnOcean-Forum nach Threads zum Gerät/EEP suchen

=== Warum funktioniert mein Eltako-Gerät nicht wie in commandref/Wiki beschrieben? ===
* Eltako-Geräte haben bei gleicher Produktbezeichnung teilweise je nach Produktionswoche unterschiedliche Funktionen/Eigenschaften
* die Produktionswoche ist auf dem Gerät angegeben (z.B. 11/14 -> Elfte Woche im Jahr 2014)
* in den nach Produktionswoche untergliederten [http://www.eltako.com/de/bedienungsanleitungen/gebaeudefunk-powerline.html Bedienungsanleitungen] stehen genauere Angaben
* Angaben in commandref/Wiki analog für die Angaben laut Bedienungsanleitung für den speziellen Produktionszeitraum umsetzen
* bei gravierenden Abweichungen und Neuerungen Info im Forum/Wiki

=== Wie kann ich Eltako-Aktoren anhand Ihrer Modellbezeichnung grob unterscheiden? ===
* 12er Baureihe (ausgelaufen) = unidirektionale RS485-Bus-Aktoren für Hutschiene
* 14er Baureihe = bidirektionale RS485-Bus-Aktoren für Hutschiene
* 61er Baureihe = uni- und bidirektionale Aktoren je nach Produktionszeitraum für Einbaumontage (Hohlwanddose)
* 70/71er Baureihe = uni- und bidirektionale Aktoren je nach Produktionszeitraum für Einbaumontage (Zwischendecke)
* zwischen den Modellreihen gibt es bei uni- und bidirektonalen Aktoren bei der Ansteuerung Übereinstimmungen; Angaben können dementsprechend analog zwischen den Geräten übertragen werden

=== Wie kann ich PEHA-Aktoren anhand Ihrer Modellbezeichnung grob unterscheiden? ===
* Easyclick-Unterputzempfänger: unidirektionale Aktoren für Einbaumontage; Modellbezeichnung enthält typischerweise die Buchstaben EP
* Easyclickpro-Unterputzempfänger: bidirektionale Aktoren für Einbaumontage; Modellbezeichnung enthält die Buchstaben EBI oder EBIM (mit zusätzlicher Energiemessung)

=== Wo finde ich Angaben zu Jäger Direkt - OPUS GreenNet EnOcean-Geräten? ===
* Es handelt sich im Wesentlichen um umgelabelte Produkte anderer Hersteller (Peha, Eltako usw.). Anhand der Gehäuseform lassen sich Rückschlüsse ziehen
* Angaben zu den "Original"-Produkten können grundsätzlich -soweit bekannt- auf OPUS GreenNet Geräte übertragen werden

=== Wie ermittele ich die Signalstärke, Signalqualität durch die Anzeige des RSSI/Repeatingcounter? ===
* Durch anlegen einer readingsGroup: <code>define TCM_Signal readingsGroup TYPE=EnOcean:+TCM_ESP3_0_RSSI,+TCM_ESP3_0_ReceivingQuality,+TCM_ESP3_0_RepeatingCounter,+TCM_ESP3_0_TIME</code>
Dabei muss TCM_ESP3_0 durch den Devicenamen des eigenen TCMs ersetzt werden!

=== Wo genau ist der Unterschied zwischen "EEP Manufacturer Specific Applications" und "Inofficial EEP for special devices"? ===
* Die inoffiziellen EEPs sind nichts anderes als Device-Vorlagen für bestimmte Aktoren. Dadurch soll dem Anwender u.a. manuelle Attributzuweisungen abgenommen werden. Teilweise werden auch spezielle Plots angelegt.

[[Kategorie:HOWTOS]]
[[Kategorie:EnOcean Components]]

EnOcean Starter Guide

2018-02-08T14:42:04Z

Mikka:

{{Todo|Noch einzuarbeitetende Moduländerungen :: http://forum.fhem.de/index.php/topic,36237.msg285274.html#msg285274: Vereinfachte Anlage von FHEM-EnOcean-Devices gemäß 18 und 19 einarbeiten, Anlage Liste von nicht offiziellen EEPs und Zuordnung zu Geräten, bessere Einbindung von getNextId ++++ http://forum.fhem.de/index.php/topic,42354.0.html: Plot-Anlage einbinden ++++ http://forum.fhem.de/index.php/topic,45810.0.html: RLT}}

<div style="float:right">
{{Infobox Modul
|Name=TCM
|ModPurpose=Einbindung EnOcean-Gateway
|ModType=d
|ModCmdRef=TCM
|ModForumArea=EnOcean
|ModTechName=00_TCM.pm
|ModOwner=klaus.schauer ([http://forum.fhem.de/index.php?action=profile;u=293 Forum] / [[Benutzer Diskussion:Klaus.schauer|Wiki]])
}}
{{Infobox Modul
|Name=EnOcean
|ModPurpose=Ansteuerung EnOcean-Geräte über TCM
|ModType=d
|ModCmdRef=EnOcean
|ModForumArea=EnOcean
|ModTechName=10_EnOcean.pm
|ModOwner=klaus.schauer ([http://forum.fhem.de/index.php?action=profile;u=293 Forum] / [[Benutzer Diskussion:Klaus.schauer|Wiki]])
}}
</div>

== EnOcean ==
[http://www.enocean.com/de/ EnOcean] ist
* ein [http://www.enocean.com/de/enocean-wireless-standard/ ISO ratifizierter Funkstandard], ausgelegt für Funksensoren und Funksensornetze mit besonders niedrigem Energieverbrauch
* ein Anbieter batterieloser Funksensoren
EnOcean-Endgeräte mit dem von der EnOcean Alliance zur Verfügung gestellten EnOcean-Funkprotokoll werden von [http://www.enocean-alliance.org/de/hiererhaeltlich/ zahlreichen Hardware-Herstellern] angeboten.

=== EnOcean Equipment Profile ===
Abhängig von den Funktionen des EnOcean-Endgerätes werden bestimmte veröffentlichte Anwendungs-Profile/Funk-Telegramme, die sogenannten EnOcean Equipment Profiles (EEPs), zur Funkkommunikation genutzt. Technische Details zum EnOcean-Funkprotokoll und insbesondere zu den [http://www.enocean-alliance.org/eep/ EnOcean Equipment Profiles (EEPs)] sind auf der Internetseite der [http://www.enocean-alliance.org EnOcean Alliance] zu finden.

==== Manufacturer Specific Communication ====
EnOcean bietet - neben den veröffentlichten Standard-Enocean-Profilen - die Möglichkeit für die Nutzung von herstellerspezifischen Anwendungs-Profilen/Funk-Telegrammen (MSC = Manufacturer Specific Communication). Falls die Herstellerfirmen den Inhalt dieser MSC-Telegramme nicht veröffentlichen, ist eine Unterstützung durch FHEM grundsätzlich nicht möglich. Teilweise werden die Produkte sowohl mit MSC- als auch mit Standard-Enocean-Profilen vertrieben {{Link2Forum|Topic=19544|Message=132240}}. Angaben zu den verwendeten Profilen/Telegrammen sind den Bedienungsanleitungen der Produkte zu entnehmen.

=== uni- versus bidirektional ===
EnOcean-Endgeräte gibt es sowohl in uni- als auch in bidirektionalen Ausführungen. Bei '''unidirektionalen Endgeräten''' erfolgt die Funk-Kommunikation nur in eine Richtung. Einem Aktor, der Licht schaltet, kann zwar der Befehl zum An- bzw. Ausschalten gegeben werden, er liefert aber keine Rückinformation über die erfolgreiche Ausführung des Befehls. Bei '''bidirektionalen Endgeräten''' erfolgt die Funk-Kommunikation hingegen in zwei Richtungen: sie bieten
# Sende- und
# Empfangsmöglichkeiten.
Der bidirektionale Aktor kann somit unter anderem die erfolgreiche Ausführung eines empfangenen Befehls zurückmelden.

=== SenderID ===
Damit EnOcean Funk-Aktoren (z.B. Relais, Dimmer, Heizungsventil) auf EnOcean Sensoren (z.B. Taster, Temperatursensor, Fensterkontakt, Energieverbrauchsmesser) reagieren können, werden die Sensoren bei den Aktoren eingelernt (Teach-in). So wird festgelegt, dass z.B. "Funktaster 1" den "Dimmer 1" steuert.
Alle EnOcean Geräte mit Sendefunktion haben mindestens eine eindeutige, unabänderliche 8-stellige Hex-SenderID (z.B. ffc54500; teilweise auch dargestellt mit Punkten oder Doppelpunkten dazwischen). Die SenderID ist meist auf den EnOcean Geräten aufgedruckt oder liegt der Verpackung des Endgerätes bei. Beim Anlernvorgang wird die eindeutige SenderID des Sensors in der Empfängertabelle des Aktors gespeichert.

== EnOcean 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_EnOcean-Forum_enthalten.3F|Anfragen im Forum]] die Aktualität von FHEM überprüfen.

Die Nutzung von EnOcean in FHEM ist (nicht nur für den Anfänger) ausschließlich mit der standardmäßig eingeschalteten [[autocreate|autocreate-Funktion]] einfach umsetzbar. 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 EnOcean behandeln, so werden doch wesentliche Punkte für ein Verständnis von FHEM vermittelt.

Im Folgenden und auf den [[:Kategorie:EnOcean 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 SenderIDs der EnOcean-Geräte haben eine zentrale Bedeutung in FHEM. Sie sind eindeutiges Unterscheidungsmerkmal, werden von FHEM im Rahmen der Funkkommunikation genutzt und in der Definition der Geräte bzw. den Attributen des Geräte hinterlegt. Auch wenn FHEM die SenderIDs des Gateways regelmäßig automatisch vergeben kann, ist für einen Überblick über die SenderIDs hilfreich eine Tabelle mit folgender oder ähnlicher Struktur aufzubauen:

<table class="wikitable" border="1">
<tr>
<th> A
</th>
<th> B
</th>
<th> C
</th>
<th> D
</th>
<th> E
</th></tr>
<tr>
<th> Nr.
</th>
<th> Name EnOcean
</th>
<th> Name in FHEM
</th>
<th> HEX (Sender-ID)
</th>
<th> Zimmer
</th></tr>
<tr>
<td>
</td>
<td> <Name Hardwareschalter>
</td>
<td> <Name in FHEM>
</td>
<td> <HEX Code>
</td>
<td> <Raumname>
</td></tr>
<tr>
<td>
</td>
<td> TCM_ESP3_0
</td>
<td> TCM_ESP3_0
</td>
<td> AABBCC00
</td>
<td>
</td></tr>
<tr>
<td> 1
</td>
<td> EnO_switch_123456
</td>
<td> eg_fl_Licht
</td>
<td> AABBCC01
</td>
<td> EG_Flur
</td></tr>
<tr>
<td> ...
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td></tr>
<tr>
<td> 128
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td></tr></table>

== Definition von TCM / Gateway ==
FHEM kann mit einem Funkgateway, das auf einem TCM-Modul basiert, EnOcean-Funk empfangen und senden.
Bisher gibt es zwei Transceiver Chips von EnOcean:
* TCM120 (ausgelaufen)
** für den USB-Port: [https://embedded-intelligence.de/de/products/hardware/bsc-bor.html BSC BOR]
* TCM310
** als USB-Stick: [http://www.enocean.com/de/enocean_module/usb-300-oem/ USB 300] und [http://busware.de/tiki-index.php?page=EUL Busware EUL]
** als Aufsteckmodul für Raspberry Pi: [http://www.enocean.com/de/enocean-pi/ EnOceanPi]<BR>
::* Beim Raspberry Pi 3 muss der GPIO-Port auf den Hardware-UART0 umgestellt werden: [[Raspberry Pi 3: GPIO-Port Module und Bluetooth]]
::* Die seriellen Schnittstelle /dev/ttyAMA0 muss am Raspberry Pi freigeschaltet werden, damit das EnOceanPi-Modul funktionsfähig ist. Zur Vorgehensweise siehe: {{Link2Forum|Topic=14814|Message=95265}}

Zudem existiert eine {{Link2Forum|Topic=22635|Message=160582|LinkText=Lösung zur kabelgebundenen Anbindung}} des FHEM-Rechners mittels Eltako FGW14 an den [[EnOcean-Eltako-RS485-Bus|Eltako RS485-Bus]], über die sowohl Busaktoren als auch EnOcean-Funkaktoren gesteuert werden können und auch EnOcean-Funktelegramme über das [[EnOcean-Eltako-RS485-Bus|FAM14 Funkantennenmodul]] am RS485-Bus empfangen werden können.

Das TCM-basierte Gateway wird unter Linux nach Anschluss an den FHEM-Rechner beim 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 TCM-Moduls oder Eingriffe in die Konfiguration sind normalerweise nicht notwendig. Werden am FHEM-Server unter Linux mehrere USB-Gateways eingesetzt, empfiehlt es sich zur Erhöhung der Betriebsstabilität das TCM-Gateway über [[Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden|Serial-by-Id]] anzusprechen. Unter Windows ist ein manuelles Anlegen der Definition des TCM-Gateways wegen fehlender Unterstützung des Befehls <code>usb scan</code> notwendig.

Bei RS485-basierte Gateways (bspw. FGW14) muss in der [[Konfiguration]] zusätzlich manuell das Attribut <code>comType</code> auf <code>RS485</code> gesetzt werden.

Beispiele der automatisch erzeugten define-Zeile in der Konfiguration:

EnOceanPi an Raspberry Pi:
define TCM_ESP3_0 TCM ESP3 /dev/ttyAMA0@57600

TCM310/USB300 an Fritzbox oder Raspberry Pi:
define TCM_ESP3_0 TCM ESP3 /dev/ttyUSB0@57600

Hier folgt ein Beispiel der define-Zeile in der Konfiguration für kabelgebundene Anbindung mit FGW14 über serielle Schnittstelle
define TCM_ESP2_0 TCM ESP2 /dev/ttyS3@57600
attr TCM_ESP2_0 comType RS485 <---- Manuell zu setzen

Nach erfolgreicher Definition ist das Gateway im Raum "Everything" in der Gruppe "TCM" zu finden. Wenn neben dem Gatewaynamen "initialized" oder "opened" angezeigt wird, ist FHEM in der Lage mit den EnOcean-Geräten zu kommunizieren.

Wie im [[#SenderID|Einführungsabschnitt]] bereits erläutert hat jedes sendende EnOcean-Endgerät mindestens eine eindeutige SenderID. Diese SenderID kann aus Sicherheitsgründen nicht vom EnOcean-Gateway simuliert werden. Vielmehr hat das Gateway eigene SenderIDs, die separat in die Endgeräte/Aktoren angelernt werden müssen. Das Gateway stellt 128 verschiedene SenderIDs zur Verfügung. Ausgehend von der baseID, die bei jedem Gateway grundsätzlich anders ist, werden die SenderIDs fortlaufend hexadezimal hochgezählt:
* FHEM stehen 127 fortlaufende eigene SenderID zur Verfügung
* beginnend mit der baseID des TCM + 1

Die baseID des TCM erhält man durch Eingabe von
get TCM_ESP3_0 baseID
in das Befehl-Eingabefeld (TCM_ESP3_0 gegebenenfalls durch den eigenen Gatewaynamen ersetzen) oder duch Auswahl dieses Befehls in den Objektdetails des FHEM-Gateway-Device.

Das Webfrontend zeigt dann beispielsweise:
BaseID=AABBCC00,RemainingWriteCycles=0A
Die niedrigste SenderID in diesem Beispiel ist AABBCC0'''1''' (BaseID=AABBCC00 +1 HEX!!!), die nächste AABBCC0'''2''' usw.

Nach der Definition des Gateways und Ermittlung der baseID des Gateways kann nun der nächste Schritt, die Definition der EnOcean-Geräte in FHEM, erfolgen.

== Definition von Geräten ==
=== Definition / Anlernvorgang (Teach-In) ===
Damit FHEM und EnOcean-Geräte miteinander kommunizieren können, müssen sie miteinander bekannt gemacht werden. Dies geschieht durch Definition des Gerätes in FHEM und den Anlernvorgang. Dazu muss sich FHEM im {{Link2CmdRef|Anker=TCM_learningMode|Label=learningMode}} befinden. Viele Geräte werden von FHEM während des Anlernvorgangs automatisch erkannt und definiert. Dennoch ist ein grundlegendes Verständnis der Anlernvorgänge und Unterscheidungsprinzipen in FHEM und EnOcean notwendig. Sofern das Gerät Bestätigungstelegramme verschicken kann, sind diese zwingend '''vorher''' am Gerät einzuschalten (u.a. Eltako).

FHEM entnimmt die Angaben, wie ein Funk-Telegramm für ein bestimmtes Gerät aufgebaut ist, im Wesentlichen den folgenden Attributen der Definition des Gerätes:
*<code>subtype</code>: FHEM-Profilname, der als Klartextname das genutzte EEP des Gerätes (EEP steht meist in der Bedienungsanleitung des Gerätes) repräsentiert . Einige FHEM-Profile z. B. "roomSensorControl.01" bedienen mehrere ähnliche EEP gleichzeitig.
*<code>manufID</code>: Code für den Hersteller des Gerätes (Übersetzungstabelle Code zu Name ist in der [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/10_EnOcean.pm 10_EnOcean.pm] unter %EnO_manuf)
*<code>model</code>: Modell des Gerätes
*<code>eep</code>: EEP des Gerätes. Unter anderem werden die Informationen zur automatischen Anlage von [[FileLog]], [[SVG]] und des Attributs <code>webCmd</code> anhand des EEPs ermittelt.
Während des Anlernvorgangs werden diese Angaben von FHEM soweit wie möglich automatisch in der Definition vorbelegt. Hinweise zu den Besonderheiten von bestimmten Geräten und EEP finden sich oft in der {{Link2CmdRef|Anker=EnOcean}} zu EnOcean. Darum bitte immer in der commandref zunächst nach dem speziellen Gerät (Modellbezeichnung) suchen, wenn dies keinen Treffer liefert nach dem verwendeten EEP suchen. Die gegebenen Hinweise und Erläuterungen dort beachten.

Die Definition und der Anlernvorgang unterscheiden sich je nach Gerätetyp:
* Sensoren:
** [[#Schalter/Switch|Schalter (EEP RPS)]]: werden automatisch beim ersten empfangenen Funktelegramm in FHEM mit den notwendigen Attributen angelegt.
** [[#Kontakte|Kontakte (EEP 1BS)]]: werden automatisch beim ersten empfangenen Funktelegramm in FHEM mit den notwendigen Attributen angelegt.
** [[#Sonstige_Sensoren|Sonstige Sensoren (EEP 4BS)]]: Durch Versand eines speziellen Anlern-Funktelegramms können sie in FHEM automatisch mit den notwendigen Attributen angelegt werden. Im Anlerntelegramm übermittelt der Sensor FHEM die EEP-Profilangabe und die Hersteller-ID. Aufgrund dieser Angaben kann FHEM das Gerät eindeutig erkennen und die richtigen Attribute in FHEM setzen. Einige wenige Sensoren verschicken leider ein Anlerntelegramm ohne EEP-Profilangabe und/oder Herstellerangabe (Bsp: Omnio Ratio eagle-PM101). Bei diesen Sensoren müssen die Attribute subType, manufID und/oder model manuell in FHEM gesetzt werden, damit eine richtige Auswertung der Funktelegramme erfolgt.
* Aktoren (4BS, VLD, UTE, MSC): Bei den Aktoren gibt es je nach Gerätetyp verschiedene Anlernvorgänge, die unterschiedlich in FHEM ausgeführt werden. Einige Aktoren unterstützen auch mehrere Anlernvorgänge. Grundsätzlich muss wegen abweichender Vorgehensweise in FHEM unterschieden werden zwischen
** [[#uni- versus bidirektional|unidirektionalen]] Aktoren und
*** [[#Teach-In_als_Tasteremulation|Teach-In als Tasteremulation]]
*** [[#Teach-In_als_Gateway.2FPC-Steuerung|Teach-In als Gateway/PC-Steuerung]]
** [[#uni- versus bidirektional|bidirektionalen]] Aktoren
*** [[#Teach-In_als_Tasteremulation_2|Teach-In als Tasteremulation]]
*** [[#Unidirektionales_4BS-Teach-In|Unidirektionales 4BS-Teach-In]]
*** [[#Bidirektionales_4BS-Teach-In|Bidirektionales 4BS-Teach-In]]
*** [[#UTE-Teach-In|UTE-Teach-In]]

In den nachfolgenden Gliederungspunkten wird beispielhaft für je ein Gerät aus den obigen Gerätetypen die Einbindung in FHEM erläutert.

Grundlegend gilt immer:
FHEM legt sendende, noch nicht definierte EnOcean Geräte selbst an, wenn
* in Konfiguration autocreate aktiviert ist:
** <code>{{Link2CmdRef|Lang=de|Anker=autocreate|Label=define autocreate autocreate}}</code>
* FHEM/das TCM-Modul sich im <code>learningMode</code> befindet und
* FHEM eine Nachricht vom noch nicht definierten EnOcean Gerät empfängt
Im Webfrontend werden automatisch angelegte neue Geräte im Raum "EnOcean" angezeigt.

=== Sensoren ===
'''Sensoren Beispiele:'''

==== Schalter/Switch ====
[[EnOcean-PTM-210-Taster|PTM 210 - Schaltermodul]] ([http://www.enocean.com/de/enocean_module/ptm-210-data-sheet-pdf/ Datenblatt])

EEP: F6-02-xx

FHEM in den learningMode (<code>set <nowiki><IODev> teach <time/s></nowiki></code>) versetzen, dazu im Befehl-Eingabefeld eingeben:
set TCM_ESP3_0 teach 600

Dann einen beliebigen Taster des Moduls drücken (und loslassen). Beim Drücken des Tasters wird vom Taster eine Nachricht ausgesendet, die von FHEM empfangen wird. Daraufhin definiert FHEM automatisch den Taster und der Taster ist in FHEM angelernt. FHEM fügt dazu folgenden Code zur Konfiguration hinzu:
* exemplarischer Auszug aus Konfiguration
define EnO_switch_FFC54500 EnOcean FFC54500 <-- "FFC54500" ist die 8-stellige Hex-SenderID des Tasters
attr EnO_switch_FFC54500 IODev TCM_ESP3_0
attr EnO_switch_FFC54500 room EnOcean
attr EnO_switch_FFC54500 subType switch <-- handelt sich um einen Schalter
# attr EnO_switch_FFC54500 eventMap AI:off A0:on BI:an B0:aus <-- bei Bedarf ... die gemapten Werte (hier: off, on, an, aus) sollen eindeutig sein
define FileLog_EnO_switch_FFC54500 FileLog ./log/EnO_switch_FFC54500-%Y.log EnO_switch_FFC54500
attr FileLog_EnO_switch_FFC54500 logtype text

Ein Schalter (hier: FT55) hat vier Taster:
{|
| '''Taster''' || '''in FHEM'''
|-
| links oben || A0
|-
| links unten || AI (nicht "eins" sondern "i"!)
|-
| rechts oben || B0
|-
| rechts unten || BI
|}

Das Log FileLog_EnO_switch_FFC54500 zeichnet beim einmaligen Drücken des linken unteren Tasters ("AI") folgendes auf:
2014-01-01_07:00:01 EnO_switch_FFC54500 buttons: pressed
2014-01-01_07:00:01 EnO_switch_FFC54500 channelA: AI
2014-01-01_07:00:01 EnO_switch_FFC54500 AI
2014-01-01_07:00:02 EnO_switch_FFC54500 buttons: released

Der angelegte Sensor repräsentiert im Webfrontend den physischen Schalter (bspw. an der Wand). Ein Druck auf den physischen Taster ändert den Zustand im Webfrontend. Jedoch führt ein Schalten des Repräsentanten im Webfrontend nicht zu einer Schaltung des Aktors.

FHEM kann sich '''nicht''' als einer der vorhandenen (automatisch angelegten) physischen Sensoren ausgeben (um z.B. das Licht zu schalten), sondern verwendet eigene SenderIDs. Diese FHEM-eigenen SenderIDs können in EnOcean-Aktoren eingelernt werden, damit die Aktoren auf FHEM reagieren [[#Aktoren|siehe unten]].

==== Kontakte ====
[[EnOcean-STM-250-Fenster-T%C3%BCrkontakt|STM 320 Batterieloses Magnetkontakt-Funkmodul]] ([http://www.enocean.com/de/enocean_module/stm-320-data-sheet-pdf/ Datenblatt])

EEP: D5-00-01

FHEM in den learningMode versetzen, dazu im Befehl-Eingabefeld eingeben:
set TCM_ESP3_0 teach 600

Anlerntelegramm laut Anleitung verschicken oder Magnetkontakt öffnen und schließen.

Der Kontakt wird automatisch in FHEM definiert und ist angelernt.

* exemplarischer Auszug aus Konfiguration
define EnO_contact_0000FF53 EnOcean 0000FF53
attr EnO_contact_0000FF53 IODev TCM_ESP3_0
attr EnO_contact_0000FF53 room EnOcean
attr EnO_contact_0000FF53 subType contact
define FileLog_EnO_contact_0000FF53 FileLog ./log/EnO_contact_0000FF53-%Y.log EnO_contact_0000FF53
attr FileLog_EnO_contact_0000FF53 logtype text
attr FileLog_EnO_contact_0000FF53 room EnOcean

==== Sonstige Sensoren ====
===== 4BS-Teach-In =====
FHEM in den learningMode versetzen, dazu im Befehl-Eingabefeld eingeben:
set TCM_ESP3_0 teach 600
Dann das Anlerntelegramm laut Bedienungsanleitung am Sensor auslösen. Der Sensor wird dann automatisch in FHEM definiert und ist angelernt.

===== Profilloses 4BS-Teach-In =====
Omnio Ratio eagle-PM101 Licht- und Anwesenheitssensor ([http://www.omnio.ch/content-en/downloads/Betriebsanleitungen/2902000_Betriebsanleitung_ea.pdf Betriebsanleitung])

FHEM in den learningMode versetzen, dazu im Befehl-Eingabefeld eingeben:
set TCM_ESP3_0 teach 600

Das Anlerntelegramm vom Omnio Ratio eagle-PM101 verschicken (MÖGLICH??)

Im angelegten FHEM-Device manuell das Attribut <code>subType</code> auf <code>PM101</code> setzen.

=== Aktoren ===
Die Bedienungsanleitungen und die commandref liefern Informationen, welche Anlernvorgänge der Aktor unterstützt. Finden sich keine Hinweise auf besondere PC- oder Gateway-Anlernvorgänge, so kann FHEM als "Notlösung" immer als virtueller FHEM-Schalter (Tasteremulation) angelernt werden. Einige Aktoren unterstützen mehrere Arten von Anlernvorgängen. Hier ist der mit den meisten/besten Steuerungsmöglichkeiten zu bevorzugen.

'''Aktoren Beispiele:'''

==== unidirektionale Aktoren ====
Bei unidirektionalen Aktoren steht eine SenderID des TCM-Gateways immer im <code>define</code> des FHEM-Devices. Mit dieser SenderID steuert FHEM den Aktor. Diese SenderID muss dazu im Aktor eingelernt werden.
{{Hinweis|'''MERKE:''' Eine SenderID des TCM-Gateways muss bei unidirektionalen Aktoren immer im <code>define</code> des Devices stehen.<br/>
'''MERKE:''' Bei unidirektionalen Aktoren stimmt der Status des FHEM-Devices im Webfrontend nur mit dem realen Aktorzustand überein, wenn ausschließlich über FHEM gesteuert wird ([[#Physischer_EnOcean-_und_virtueller_FHEM-Schalter_zu_einem_Device_zusammenfassen|Abhilfe]])}}
===== Teach-In als Tasteremulation =====
PEHA 451 FU-EP o.T. (Schaltaktor unidirektional)

Eine [[#Wie ermittelt man freie Sender-IDs des TCM-basierten Funkgateways?|freie SenderID des TCM-basierten Gateways heraussuchen]] und diese als EnOcean-Gerät in FHEM definieren, dazu im Befehl-Eingabefeld eingeben:
define eg_fl_Licht EnOcean AABBCC01

Alternativ kann man FHEM auch anweisen, für das EnOcean-Gerät selbst die nächste freie SenderID zu ermitteln. Die Definition ist dann folgendermaßen vorzunehmen:
define eg_fl_Licht EnOcean getNextID

Anschließend das Attribut <code>subType</code> beim erzeugten Device auf <code>switch</code> setzen. Durch diese Definition wird ein 8-fach EnOcean-Taster erzeugt. Der Taster hat 4 Kanäle (A,B,C,D) zu je 2 Tasten (0,I). Alle diese 8 Taster senden mit der gleichen SenderID des TCM. Das entspricht einem Gerät mit 4 Schaltwippen die jeweils "oben" '''oder''' "unten" gedrückt sein können. FHEM emuliert mit diesem EnOcean-Gerät einen EnOcean-Schalter (darum auch "virtueller FHEM-Schalter"). Der Taster 0 des Kanal A wird "gedrückt" mit <code>set eg_fl_Licht A0</code>.

Dieser virtuelle FHEM-Schalter wird in den Aktor wie ein physischer Schalter eingelernt. Den Aktor in den Anlernmodus bringen (Taste LRN/SET drücken) und den virtuellen FHEM-Schalter betätigen, indem im Befehl-Eingabefeld eingeben wird:
set eg_fl_Licht B0
Wenn der Aktor den erfolgreichen Anlernvorgang signalisiert, den Anlernmodus am Aktor ausschalten.

* exemplarischer Auszug aus Konfiguration
define eg_fl_Licht EnOcean AABBCC01 <--- AABBCC01 ist eine der 127 SenderID's des TCM, mit der FHEM sendet
attr eg_fl_Licht room EG_Flur
attr eg_fl_Licht eventMap BI:off B0:on
attr eg_fl_Licht subType switch
define FileLog_eg_fl_Licht FileLog ./log/ eg_fl_Licht-%Y.log eg_fl_Licht
attr FileLog_eg_fl_Licht logtype text

Der Status des Devices im Webfrontend stimmt bei unidirektionalen Aktoren nur, wenn die Steuerung des Aktors ausschließlich über FHEM erfolgt. Wird der Aktor sowohl über einen physischen Schalter als auch über FHEM gesteuert, so müssen die Status der beiden Devices für physischen und virtuellen Schalter im Webfrontend verknüpft werden, damit der richtige Status des Aktors angezeigt wird ([[#Physischer EnOcean- und virtueller FHEM-Schalter zu einem Device zusammenfassen |siehe unten]]).

===== Teach-In als Gateway/PC-Steuerung =====
"ältere" Eltako FSB61 (Produktionszeitraum KW 43/10 - KW 40/11 [http://www.eltako.com/fileadmin/downloads/de/_bedienung/FSB61NP_30200420-3_dtsch.pdf Bedienungsanleitung])

EEP: A5-3F-7F

Eine [[#Wie ermittelt man freie Sender-IDs des TCM-basierten Funkgateways?|freie SenderID des TCM-basierten Gateways heraussuchen]] und diese als EnOcean-Gerät in FHEM definieren, dazu im Befehl-Eingabefeld eingeben:
define eg_fl_Rollo EnOcean AABBCC02

Alternativ kann man FHEM auch anweisen, für das EnOcean-Gerät selbst die nächste freie SenderID zu ermitteln. Die Definiton ist dann folgendermaßen vorzunehmen:
define eg_fl_Rollo EnOcean getNextID

Beim erzeugten FHEM-Device muss das Attribut <code>subType</code> auf <code>manufProfile</code> gesetzt werden. Die Attribute <code>manufID</code> und <code>model</code> sind auf die unten in der Konfiguration gezeigten Werte zu setzen.

Dieser virtuelle FHEM-Schalter wird in den Aktor als PC/Szenentaster angelernt indem im Befehl-Eingabefeld eingeben wird:
set eg_fl_Rollo teach
Wenn der Aktor den erfolgreichen Anlernvorgang signalisiert, den Anlernmodus am Aktor ausschalten.

* exemplarischer Auszug aus Konfiguration
define eg_fl_Rollo EnOcean AABBCC02 <--- AABBCC02 ist eine der 127 SenderID's des TCM, mit der FHEM sendet
attr eg_fl_Rollo room EG_Flur
attr eg_fl_Rollo subType manufProfile
attr eg_fl_Rollo manufID 00D
attr eg_fl_Rollo model Eltako_FSB61

Der Status des Devices im Webfrontend stimmt bei unidirektionalen Aktoren nur, wenn die Steuerung des Aktors ausschließlich über FHEM erfolgt. Wird der Aktor sowohl über einen physischen Schalter als auch über FHEM gesteuert, so müssen die Status der beiden Devices für physischen und virtuellen Schalter im Webfrontend verknüpft werden, damit der richtige Status des Aktors angezeigt wird ([[#Physischer EnOcean- und virtueller FHEM-Schalter zu einem Device zusammenfassen |siehe unten]]).

==== bidirektionale Aktoren ====
Bei bidirektionalen Aktoren steht die SenderID des Aktors im <code>define</code> des FHEM-Devices. FHEM ordnet empfangene Bestätigungstelegramme anhand der Aktor-SenderID dem passenden FHEM-Device zu. Eine SenderID des TCM-Gateways mit der FHEM den Aktor steuert steht bei bidirektionalen Aktoren immer im Attribut <code>subDef</code>. Diese SenderID muss dazu im Aktor eingelernt werden.
{{Hinweis|'''MERKE:''' Eine SenderID des TCM-Gateways muss bei bidirektionalen Aktoren immer im Attribut <code>subDef</code> des Devices stehen.<br/>
'''MERKE:''' Bei bidirektionalen Aktoren stimmt nach korrekter Einbindung in FHEM der Status des FHEM-Devices im Webfrontend immer mit dem realen Aktorzustand überein.}}
===== Teach-In als Tasteremulation =====
[[EnOcean-FSR61VA-10A-Stromsto%C3%9F-Schaltrelais_mit_Strommessung|10A-Stromstoß-Schaltrelais mit Strommessung FSR61VA]]<br/>
Schaltrelais (bidirektional)

FHEM in den learningMode versetzen, dazu im Befehl-Eingabefeld eingeben:
set TCM_ESP3_0 teach 600

Die [[#SenderID|SenderID]] des Aktors heraussuchen und diese als EnOcean-Gerät in FHEM definieren, dazu im Befehl-Eingabefeld eingeben:
define EnO_switch_FSR61VA EnOcean FFAABBC0

Eine freie SenderID des TCM-basierten Gateways heraussuchen und diese im Attribut <code>subDef</code> des angelegten Devices hinterlegen.

Anschließend die Attribute <code>subType</code> und <code>switchMode</code> wie im unten wiedergegebenen exemplarischen Auszug aus der Konfiguration anlegen.

Damit der FSR61VA auf FHEM reagieren kann (Ein/Ausschalten), wird das FHEM-Device EnO_switch_FSR61VA in den FSR61VA als Richtungstaster (bzw. Taster ein/aus) eingelernt:
# Unterer Drehschalter je nach Produktionswoche des FSR61VA (aufgedruckt):
## bis KW 2/13: "ca. Mitte" (Taster Ein/Aus einlernen)
## ab KW 3/13 bis KW 10/14: "60" (Taster Ein/Aus einlernen)
## ab KW 11/14: "40" (Richtungstaster einlernen)
# Oberer Funktions-Drehschalter: "LRN" (LED blinkt)
# FHEM Eingabefeld: „set EnO_switch_FSR61VA B0“, <Enter> (LED erlischt)
# Oberer Funktions-Drehschalter: Eine der ESV-Einstellungen
# Unterer Funktions-Drehschalter: auf "oo" einstellen (unendlich)

* exemplarischer Auszug aus der Konfiguration
define EnO_switch_FSR61VA EnOcean FFAABBC0 --> EnO_switch_FSR61VA ist ein frei gewählter eindeutiger Name
für das FHEM-Device.
FFAABBC0 ist die erste am Boden des FSR61VA aufgedruckte SenderID.
Damit sendet das FSR61VA den Schaltzustand (B0/BI --> ein/aus)
attr EnO_switch_FSR61VA IODev TCM_ESP3_0 --> TCM_ESP3_0 ist der Name des Devices, mit dem FHEM EnOcean-Funk
sendet und empfängt.
attr EnO_switch_FSR61VA subDef FF998877 --> FF998877 ist eine der 127 SendeIDs des TCM_ESP3_0, damit sendet FHEM an den FSR61VA
attr EnO_switch_FSR61VA subType switch --> es handelt sich um einen EnOcean Schalter (der kann A0, AI, B0, BI,...)
attr EnO_switch_FSR61VA switchMode pushbutton --> als "pushbutton" sendet FHEM bei einem
"set EnO_switch_FSR61VA B0" nach dem Kommando (B0) noch ein "release".
Das brauchts, wenn der FSR61VA als ES oder ESV betrieben wird.
Sonst wird jedes "set"-Kommando vom FSR61VA als
"länger als eine Sekunde gedrückt" interpretiert -> "Tasterdauerlicht".

===== Unidirektionales 4BS-Teach-In =====
[[EnOcean-FSR14-4x-RS485-Bus-Schaltaktor-4-Kanal-Stromsto%C3%9F-Schaltrelais|RS485-Bus-Aktor 4-Kanal-Stromstoß-Schaltrelais FSR14]]<br/>
Schaltrelais (bidirektional)

FHEM in den learningMode versetzen, dazu im Befehl-Eingabefeld eingeben:
set TCM_ESP3_0 teach 600

Die [[#SenderID|SenderID]] des Aktors heraussuchen und diese als EnOcean-Gerät in FHEM definieren, dazu im Befehl-Eingabefeld eingeben:
define EnOcean_switch_FEFF4AF8 EnOcean FEFF4AF8

{{Randnotiz|RNText=Ab {{Link2Forum|Topic=31450|Message=239937|LinkText=Updatestand 04.01.2015}} ist eine manuelle Vergabe einer freien SenderID per <code>subDef</code> nicht mehr notwendig. Beim ersten Senden des "teach"-Befehls an den Aktor wird eine freie SenderID vergeben, sofern keine gültige SenderID eingetragen war.}}
Eine freie SenderID des TCM-basierten Gateways heraussuchen und diese im Attribut <code>subDef</code> des angelegten Devices hinterlegen.

Anschließend die Attribute <code>subType</code> und <code>gwCmd</code> wie im unten wiedergegebenen exemplarischen Auszug aus der Konfiguration anlegen.

Jetzt den Aktor in den Lernmodus versetzen und dann von FHEM das Lerntelegramm verschicken:
set EnOcean_switch_FEFF4AF8 teach
Lernmodus am Aktor ausschalten

* exemplarischer Auszug aus Konfiguration
define EnOcean_switch_FEFF4AF8 EnOcean FEFF4AF8 <--- FEFF4AF8 ist hier die SenderID eines FSR14-Kanals (Aktor)
attr EnOcean_switch_FEFF4AF8 subDef AABBCC03 <--- AABBCC03 ist eine der 127 SenderID's des TCM, mit der FHEM sendet [[#Taster - physisch und in FHEM|(siehe unten)]]
attr EnOcean_switch_FEFF4AF8 room EnOcean # Der Raum kann angepasst werden
attr EnOcean_switch_FEFF4AF8 gwCmd switching # Wichtig für FSR14
attr EnOcean_switch_FEFF4AF8 subType gateway # Wichtig für FSR14
define FileLog_EnOcean_switch_FEFF4AF8 FileLog ./log/EnOcean_switch_FEFF4AF8-%Y.log EnOcean_switch_FEFF4AF8
attr FileLog_EnOcean_switch_FEFF4AF8 logtype text

===== Bidirektionales 4BS-Teach-In =====
[[EnOcean-MD15-Kleinstellantrieb|Kleinstellantrieb MD15-FTL-xx]]<br/>
Funkgesteuerter, batteriegespeister Kleinstellantrieb für Raumtemperaturregelung (bidirektional)

EEP: A5-20-01

4BS-Bidirektionales-Teach-In:

#Aktor möglichst komplett zurücksetzen, sofern nicht mehr im Original-Auslieferzustand
#Falls vorhanden, alle bisherigen FHEM-Devices des Aktors löschen und nach Speichern der geänderten Konfiguration FHEM neu starten
#FHEM in Lernmodus schalten: <code>set <nowiki><IODev> teach <time/s></nowiki></code>
#Taster am MD15-FTL-xx so lange drücken, bis ein Signalton ertönt. MD15 bestätigt erfolgreichen Anlernvorgang durch das Aufleuchten der Status-LED und 2 Signaltöne
#Aktor wird in FHEM automatisch mit allen notwendigen Parametern angelegt.

* exemplarischer Auszug aus Konfiguration
define EnO_sensor_01000EFA EnOcean 01000EFA
attr EnO_sensor_01000EFA IODev TCM_ESP3_0
attr EnO_sensor_01000EFA comMode biDir
attr EnO_sensor_01000EFA destinationID unicast
attr EnO_sensor_01000EFA manufID 00A
attr EnO_sensor_01000EFA room EnOcean
attr EnO_sensor_01000EFA subDef AABBCC04
attr EnO_sensor_01000EFA subType hvac.01
define FileLog_EnO_sensor_01000EFA FileLog ./log/EnO_sensor_01000EFA-%Y.log EnO_sensor_01000EFA
attr FileLog_EnO_sensor_01000EFA logtype text
attr FileLog_EnO_sensor_01000EFA room EnOcean

===== UTE-Teach-In =====
[[EnOcean-D-452-FU-EBIM-Aktor-2fach|Einbau-Aktor 452 FU-EBIM o.T.]]<br/>
2-Kanal-Multifunktionsaktor (bidirektional) mit Energiemessfunktion

EEP: D2-01-08

UTE-Teach-In:

#Aktor möglichst komplett zurücksetzen, sofern nicht mehr im Original-Auslieferzustand
#Falls vorhanden, alle bisherigen FHEM Devices des Aktors löschen und nach Speichern der geänderten Konfiguration FHEM neu starten
#FHEM in Lernmodus schalten: <code>set <nowiki><IODev> teach <time/s></nowiki></code>
#Aktor-Kanal 0 oder 1 in Lernmodus versetzen (immer nur einen Kanal)
#Aktor-Kanal 0 oder 1 wird in FHEM automatisch mit allen notwendigen Parametern angelegt.
#Das Anlernen für den zweiten Kanal wie nach 3. bis 5. beschrieben wiederholen

Die Kanäle können jetzt geschaltet werden mit:

*FHEM Device für Kanal 0: set <Name_0> on|off 0
*FHEM Device für Kanal 1: set <Name_1> on|off 1

Falls gewünscht, kann der Kanal mit dem Attribut attr <Name_0|1> defaultChannel 0|1 voreingestellt werden. Dann entfällt die Angabe des Kanals im set-Befehl.

Die Statusrückmeldungen mit den aktuellen Werten des Energieverbrauches und der Leistung werden vom Aktor automatisch gesendet. Sie werden sowohl als Telegramme nach EEP D2-01-08 als auch nach EEP A5-11-04 mit unterschiedlichen SenderIDs (vgl. Etikett in Original-Verpackung) gesendet.
Die Rückmeldungen nach EEP D2-01-08 werden von FHEM im Aktor-Device subType actuator.01 berücksichtigt. Die Rückmeldungen nach EEP A5-11-04 werden von FHEM in einem senor-device subType lightCtrlState.02 berücksichtigt.

== Besonderheiten für die Anzeige im WebFrontend ==

=== Aufteilung der Kanäle in unabhängige Devices ===
===== Mehrkanalige bidirektionale Aktoren =====
Mehrkanalige bidirektionale Aktoren (bspw. Eltako FMS61NP) haben teilweise nur eine SenderID und werden daher in FHEM über ein FHEM-Device im Webfrontend abgebildet und gesteuert. Um im WebFrontend für jeden Kanal ein separates FHEM-Device zur Anzeige und Steuerung zu erhalten, kann [[ReadingsProxy|readingsProxy]] genutzt werden.

Zunächst wird der Aktor standardmäßig in FHEM definiert/angelernt und die Funktion geprüft (hier am Beispiel eines Aktor mit dem Namen "Aktor"). Anschließend wird pro Kanal ein readingProxy-Device mit Bezug auf das Reading channelA, channelB, ... angelegt:

#Kanal A zur Steuerung mit on und off
define AktorKanalA readingsProxy Aktor:channelA
attr AktorKanalA setFn {($CMD eq "on")?"A0":"AI";;}
attr AktorKanalA setList off on
attr AktorKanalA valueFn {($VALUE eq "A0")?"on":"off"}
attr AktorKanalA webCmd off:on

#Kanal B zur Steuerung mit on und off
define AktorKanalB readingsProxy Aktor:channelB
attr AktorKanalB setFn {($CMD eq "on")?"B0":"BI";;}
attr AktorKanalB setList off on
attr AktorKanalB valueFn {($VALUE eq "B0")?"on":"off"}
attr AktorKanalB webCmd off:on

Jeder Kanal wird jetzt separat im WebFrontend durch das readingsProxy-Device abgebildet (Statusanzeige) und kann mit diesem gesteuert werden.

Ein ausführlicheres readingsProxy-Beispiel für einen mehrkanaligen Jalousieaktor mit Visualisierung über Slider enthält dieser {{Link2Forum|Topic=59418|Message=512758}}.
[[Datei:EnO_Jalousie_OmnioAktor_REGJ12-04.png|400px|thumb|center|readingsProxy-Beispiel für einen mehrkanaligen Jalousieaktor mit Visualisierung über Slider]]

===== Virtuelle Schalter für unidirektionale Aktoren =====
Um die 4 Kanäle jeweils einzeln als Schalter (einzelne Schaltwippe) im WebFrontend abzubilden kann [[ReadingsProxy|readingsProxy]] genutzt werden. So werden vier Schalter (im unten gezeigten Beispiel: fhemSchalterKanal[A-D]) mit nur einer der 127 eigenen SenderIDs zur Verfügung gestellt.
{{Randnotiz|RNTyp=i|RNText=Ab [[version|Modulversion]] 11866/31.7.2016 besitzen auch virtuelle Schalter die Readings channel[A-D]. Ein readingsProxy sollte seitdem besser von diesen Readings, wie im [[#Mehrkanalige_bidirektionale_Aktoren|vorherigen Abschnitt]] dargestellt, abgeleitet werden. }}
Anders als bei den bekannten bidirektionalen Aktoren und den FHEM-Devices der physischen Schalter, existiert bei den virtuellen Schaltern das Reading channelA, channelB, ... nicht. Daher muss das readingsProxy für den virtuellen Schalter vom Reading state abgeleitet werden:

#Kanal A zur Steuerung mit on und off
define fhemSchalterKanalA readingsProxy fhemSchalter:state
attr fhemSchalterKanalA setFn {($CMD eq "on")?"A0":"AI";;}
attr fhemSchalterKanalA setList on off
attr fhemSchalterKanalA valueFn {$LASTCMD}
attr fhemSchalterKanalA webCmd on:off

#Kanal B zur Steuerung mit on und off
define fhemSchalterKanalB readingsProxy fhemSchalter:state
attr fhemSchalterKanalB setFn {($CMD eq "on")?"B0":"BI";;}
attr fhemSchalterKanalB setList on off
attr fhemSchalterKanalB valueFn {$LASTCMD}
attr fhemSchalterKanalB webCmd on:off

#Kanal C zur Steuerung mit on und off
define fhemSchalterKanalC readingsProxy fhemSchalter:state
attr fhemSchalterKanalC setFn {($CMD eq "on")?"C0":"CI";;}
attr fhemSchalterKanalC setList on off
attr fhemSchalterKanalC valueFn {$LASTCMD}
attr fhemSchalterKanalC webCmd on:off

#Kanal D zur Steuerung mit on und off
define fhemSchalterKanalD readingsProxy fhemSchalter:state
attr fhemSchalteKanalD setFn {($CMD eq "on")?"D0":"DI";;}
attr fhemSchalterKanalD setList on off
attr fhemSchalterKanalD valueFn {$LASTCMD}
attr fhemSchalterKanalD webCmd on:off

Werden diese FHEM-Taster (und etwaige physische Taster) in EnOcean-Aktoren eingelernt (siehe Anleitung des Aktors), so können nun die EnOcean-Aktoren mit physischen Tastern (sendet mit der 8-stelligen SenderID des Tasters) und mit virtuellen FHEM-Readingsproxy-Schaltern (senden mit einer der 127 eigenen SenderIDs) bedient werden.

=== Physischer EnOcean- und virtueller FHEM-Schalter zu einem Device zusammenfassen ===
Um im Webfrontend die Aktionen beider Schalter in einem Element zusammengefasst und damit den realen Zustand bei '''unidirektionalen''' Aktoren zu sehen, kann man eine <code>structure</code> nutzen:
<br />
(Bei bidirektionalen Aktoren ist dies aufgrund der Statusrückmeldungen nicht notwendig. Achtung: Teilweise müssen Statusrückmeldungen/Bestätigungstelegramme erst am Aktor eingeschaltet werden)

#Definition des virtuellen FHEM-Schalters
define fhemSchalter EnOcean AABBCC01 <--- AABBCC01 ist eine der 127 SenderID's des TCM, mit der FHEM sendet
attr fhemSchalter eventMap BI:off B0:on
attr fhemSchalter icon icoBELEUCHTUNG.png
attr fhemSchalter subType switch

#Definition des physischen Tasters (z.B. durch autocreate erzeugt)
define EnO_switch_0021E4BB EnOcean 0021E4BB <--- 0021E4BB ist die (aufgedruckte) 8-stellige SenderID des physischen Tasters
attr EnO_switch_0021E4BB eventMap BI:off B0:on
attr EnO_switch_0021E4BB room EnOcean
attr EnO_switch_0021E4BB subType switch
attr EnO_switch_0021E4BB dummy

#fhemSchalter ist der Name des virtuellen FHEM-Schalters
#EnO_switch_0021E4BB ist der (z.B. per autocreate erstellte) FHEM-Taster
define Gruppe_test_notify structure room fhemSchalter EnO_switch_0021E4BB
attr Gruppe_test_notify eventMap BI:off B0:on
attr Gruppe_test_notify room Gaestezimmer
attr Gruppe_test_notify clientstate_behavior last

Alternativ kann man für diesen Zweck auch ein <code>notify</code> in Verbindung mit <code> setreading <device> state <state></code> nutzen:

define nAbgleich notify EnO_switch_0021E4BB:(on|off) setreading fhemSchalter state $EVENT

== FAQ ==
=== Warum schaltet mein Aktor nicht, wenn ich im WebFrontend auf das Icon für den physischen Taster/Schalter klicke bzw. mit <code>set <device> <command></code> ansteuere? ===
:Aus Sicherheitsgründen können bei EnOcean keine physischen Geräte(-adressen) durch FHEM bzw. das TCM-Gateway emuliert werden. FHEM muss zur Steuerung separat an den Aktor angelernt werden. Dazu eine der TCM-Adressen an den Aktor anlernen.

=== Welche Infos sollten Anfragen im EnOcean-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 devices (Ausgabe von <code>list <device></code>)
* passender Ausschnitt aus Logfile (siehe Link im FHEM-Menü links) generiert mit gesetztem Attribut verbose 5 am TCM-Device (<code>attr <IODev> verbose 5</code>)

=== Wie kann ich zur Fortentwicklung der EnOcean-Module beitragen? ===
* Erfolgreichen Einsatz von neuen/bisher nicht gemeldeten EnOcean-Geräten im Forum mitteilen
* In der {{Link2CmdRef}} als [untested] markierte EEPs bei erfolgreichen Tests im Forum als getestet melden
* Codeschnipsel und Ideen im Forum posten
* Fehler und Probleme im Forum melden
* Wiki: Neue Geräte ins Wiki aufnehmen; Codeschnipsel und Beispiele einpflegen

=== Wie findet man die Sender-ID eines bidirektionalen Aktors? ===
* Aufkleber auf dem Aktor oder beigelegte Information in der Aktorverpackung
* Ermittlung mit FHEM:
# Bestätigungstelegramme am Aktor aktivieren
# Funktaster am Aktor anlernen oder alternativ Taster am örtlichen Steuereingang anschließen
# FHEM in den learningMode versetzen: <code>set <nowiki><IODev> teach <time/s></nowiki></code>
# [[Event monitor|Event Monitor]] aufrufen
# Aktor mit Taster schalten
# Im Event Monitor wird nun die Sender-ID des Aktors durch das Bestätigungstelegramm angezeigt. Sofern ein Funktaster zur Ansteuerung genutzt wird, zeigt der Event Monitor auch dessen Sender-ID.
# FHEM hat mittels autocreate für das Bestätigungstelegramm ein Device angelegt, sofern das vorher noch nicht existierte. Dieses Device kann man nach eventueller Änderung des subType und dem Setzen anderer gegebenenfalls notwendiger Attribute an den Aktor anlernen.

=== Wie ermittelt man freie Sender-IDs des TCM-basierten Funkgateways? ===
FHEM ermittelt eine freie SenderID automatisch, wenn die Definition folgermaßen erfolgt:
* unidirektionaler Aktor:
: <code><nowiki>define <name> EnOcean getNextID <EEP></nowiki></code>
: Im definierten Device ist "getNextID" durch eine freie SenderID des TCMs ersetzt.
* bidirektionaler Aktor:
: <code><nowiki>define <name> EnOcean <SenderId des Aktors> <EEP></nowiki></code>
: Dem definierten Device wird das Attribut <code>subDef</code> mit dem Wert <code>getNextId</code> zugewiesen: <code><nowiki>attr <name> subDef getNextID</nowiki></code>. "getNextID" ersetzt FHEM automatisch durch eine freie SenderID des TCMs

Manuelle Ermittlung der freien SenderIDs, wenn die obige automatische mit FHEM fehlschlägt oder eine manuelle Vergabe gewünscht wird:
* Aus der oben [[EnOcean_Starter_Guide#Vorbereitung|gezeigten Tabelle]]
* Anzeige der nächsten freien Sender-ID: <pre>{EnOcean_CheckSenderID("getNextID", "<IODev>", "0000000")} </pre>
* Auflistung der bereits vergebenen Sender-IDs: <pre>{EnOcean_CheckSenderID("getUsedID", "<IODev>", "0000000")} </pre>
* Auflistung der noch nicht vergebenen Sender-IDs: <pre>{EnOcean_CheckSenderID("getFreeID", "<IODev>", "0000000")} </pre>
Den jeweiligen Befehl in das "[[Konfiguration#Befehl-Eingabefeld|Befehl-Eingabefeld]]" kopieren, <IODev> durch den Namen des TCM-Devices ersetzen und dann Auslösen.

=== Schaltet immer AI ein und A0 aus, BI ein und B0 aus usw. ? ===
Nein. <br>
Das Verhalten der Aktoren ist abhängig vom Hersteller und/oder vom Anlernvorgang. Laut EEP schaltet xI ein und x0 aus. Dies wird von den meisten Herstellern entsprechend umgesetzt. Eltako definiert dies genau andersherum: xI schaltet aus und x0 ein. Analog sind auch die jeweiligen Bestätigungstelegramme der Aktoren herstellerspezifisch festgelegt. Zudem kann bei einigen Aktoren auch je nach Anlernvorgang ein anderes Verhalten erreicht werden; Details enthalten die Bedienungsanleitungen.

=== Wie kann man einen Plot für ein EnOcean-Device anlegen? ===
Bei der manuellen Anlage von Devices über das EEP und bei der automatischen Anlage durch die autocreate-Funktion beim teach-in werden neben dem Device selbst auch das FileLog-Device und -soweit als Vorlage von FHEM mitgeliefert- die SVG-Devices mit .gplot-Datei für die Plots automatisch erzeugt. Manuell sollten die Devices deshalb möglichst über die Vorgabe des EEP erzeugt werden:
* <code><nowiki>define <name> EnOcean <ID> <EEP></nowiki></code> oder
* <code><nowiki>define <name> EnOcean <EEP></nowiki></code>

Beispiel:
<code><nowiki>define test EnOcean A5-04-02</nowiki></code>

Bei bestehenden Devices können die FileLog- und SVG-Devices nachträglich erzeugt werden. Hierzu wird im DEF das entsprechende EEP statt der ID eingetragen und {{Taste|modify <name>}} bestätigt. Nach dem automatischen Anlegen der zugehörigen Devices erscheint dort wieder die ID.

Sollte für das EEP keine .gplot-Vorlage für einen Plot bzw. das SVG-Device existieren, kann ein Plot mit dem [[Plots erzeugen|.gplot-Editor]] erstellt werden.

=== Was muss man beim Einsatz der "set extensions" (on-for-timer, on-till, ...) beachten? ===
Die {{Link2CmdRef|Anker=setExtensions|Label=set extensions}} werden von EnOcean grundsätzlich unterstützt, wenn das Device als
# set-Befehle "on" und "off" automatisch anbietet '''oder'''
# dies manuell durch das Mapping (bspw. <code>eventMap BI:on B0:off</code>) erreicht wird.

Im 1. Fall sind alle "set extensions"-Befehle automatisch funktionsfähig.

Im 2. Fall ist die eventMap jedoch zusätzlich - je nach gewünschten "set extensions"-Befehl - zwingend weiter zu ergänzen:
* on-tor-timer: <code>attr <device> eventMap on-for-timer:on-for-timer BI:on B0:off</code> ({{Link2Forum|Topic=28855|Message=214960}})
* off-tor-timer: <code>attr <device> eventMap off-for-timer:off-for-timer BI:on B0:off</code>
* on-till: <code>attr <device> eventMap on-till:on-till BI:on B0:off</code> ({{Link2Forum|Topic=29993|Message=226886}})
* off-till: <code>attr <device> eventMap off-till:off-till BI:on B0:off</code>
* blink: <code>attr <device> eventMap on-for-timer:on-for-timer BI:on B0:off</code> ({{Link2Forum|Topic=31358|Message=239151}})
* intervals: <code>attr <device> eventMap on-till:on-till BI:on B0:off</code>
Sollen mehrere "set extensions"-Befehle verwendet werden, so sind die obigen Codes entsprechend zu kombinieren.

=== Für mein EnOcean-Gerät gibt es keine spezielle Wiki-Seite; wo finde ich dann Informationen? ===
* In der {{Link2CmdRef}} nach dem Gerät suchen
* In der commandref nach dem verwendeten EEP suchen
* Im Wiki nach einem Gerät mit einer ähnlichen EEP/subType suchen
* Im EnOcean-Forum nach Threads zum Gerät/EEP suchen

=== Warum funktioniert mein Eltako-Gerät nicht wie in commandref/Wiki beschrieben? ===
* Eltako-Geräte haben bei gleicher Produktbezeichnung teilweise je nach Produktionswoche unterschiedliche Funktionen/Eigenschaften
* die Produktionswoche ist auf dem Gerät angegeben (z.B. 11/14 -> Elfte Woche im Jahr 2014)
* in den nach Produktionswoche untergliederten [http://www.eltako.com/de/bedienungsanleitungen/gebaeudefunk-powerline.html Bedienungsanleitungen] stehen genauere Angaben
* Angaben in commandref/Wiki analog für die Angaben laut Bedienungsanleitung für den speziellen Produktionszeitraum umsetzen
* bei gravierenden Abweichungen und Neuerungen Info im Forum/Wiki

=== Wie kann ich Eltako-Aktoren anhand Ihrer Modellbezeichnung grob unterscheiden? ===
* 12er Baureihe (ausgelaufen) = unidirektionale RS485-Bus-Aktoren für Hutschiene
* 14er Baureihe = bidirektionale RS485-Bus-Aktoren für Hutschiene
* 61er Baureihe = uni- und bidirektionale Aktoren je nach Produktionszeitraum für Einbaumontage (Hohlwanddose)
* 70/71er Baureihe = uni- und bidirektionale Aktoren je nach Produktionszeitraum für Einbaumontage (Zwischendecke)
* zwischen den Modellreihen gibt es bei uni- und bidirektonalen Aktoren bei der Ansteuerung Übereinstimmungen; Angaben können dementsprechend analog zwischen den Geräten übertragen werden

=== Wie kann ich PEHA-Aktoren anhand Ihrer Modellbezeichnung grob unterscheiden? ===
* Easyclick-Unterputzempfänger: unidirektionale Aktoren für Einbaumontage; Modellbezeichnung enthält typischerweise die Buchstaben EP
* Easyclickpro-Unterputzempfänger: bidirektionale Aktoren für Einbaumontage; Modellbezeichnung enthält die Buchstaben EBI oder EBIM (mit zusätzlicher Energiemessung)

=== Wo finde ich Angaben zu Jäger Direkt - OPUS GreenNet EnOcean-Geräten? ===
* Es handelt sich im Wesentlichen um umgelabelte Produkte anderer Hersteller (Peha, Eltako usw.). Anhand der Gehäuseform lassen sich Rückschlüsse ziehen
* Angaben zu den "Original"-Produkten können grundsätzlich -soweit bekannt- auf OPUS GreenNet Geräte übertragen werden

=== Wie ermittele ich die Signalstärke, Signalqualität durch die Anzeige des RSSI/Repeatingcounter? ===
* Durch anlegen einer readingsGroup: <code>define TCM_Signal readingsGroup TYPE=EnOcean:+TCM_ESP3_0_RSSI,+TCM_ESP3_0_ReceivingQuality,+TCM_ESP3_0_RepeatingCounter,+TCM_ESP3_0_TIME</code>
Dabei muss TCM_ESP3_0 durch den Devicenamen des eigenen TCMs ersetzt werden!

[[Kategorie:HOWTOS]]
[[Kategorie:EnOcean Components]]