FHEMWiki - Benutzerbeiträge [de]

HM-LGW-O-TW-W-EU Funk-LAN Gateway

2018-01-06T13:10:23Z

Octo: Einleitungstext überarbeitet.

{{Infobox Hardware
|Bild=HM-LGW-O-TW-W-EU-2.jpg
|Bildbeschreibung=HomeMatic Funk-LAN Gateway
|HWProtocol=[[HomeMatic]]
|HWType=[[Interface]]
|HWCategory=HomeMatic
|HWComm=868,3/869,525 MHz
|HWChannels=''n/a''
|HWVoltage=5V DC
|HWPowerConsumption=0,8W
|HWPoweredBy=externes Netzteil
|HWSize=116x150x34mm
|HWDeviceFHEM=[[HMUARTLGW]]
|HWManufacturer=ELV / eQ-3
}}

Das [[HM-LGW-O-TW-W-EU Funk-LAN Gateway|HM-LGW-O-TW-W-EU(-2) Funk-LAN Gateway]] ist ein [[Interface]] für [[HomeMatic]]-Geräte, ähnlich dem [[HM-CFG-LAN LAN Konfigurations-Adapter|LAN-Konfigurationsadapter]]. Es existieren zwei Revisionen dieses Geräts, HM-LGW-O-TW-W-EU und HM-LGW-O-TW-W-EU-2. Die folgende Beschreibung bezieht sich – sofern nicht anders angegeben – auf beide Geräterevisionen.

Das Gateway unterstützt ausschließlich das HomeMatic-Protokoll und kann ''nicht'' mit [[HomeMatic IP|HomeMatic-IP]]-Geräten kommunizieren.

== Features ==
(Noch zu ergänzen)
* ...

== Hinweise zum Betrieb mit FHEM ==
Juni 2016: Beginn der Entwicklung eines FHEM-Moduls (HMUARTLGW) für dieses Interface, beschrieben im Forum unter dem Titel {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}. Dieses Modul unterstützt gleichzeitig auch das [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi|Funkmodul für Raspberry Pi]].

Juli 2016: [[HMUARTLGW]] wird über FHEM [[update]] verteilt, damit ist dieses Funkmodul offiziell unterstützt.

=== Definition in FHEM ===

define meinLGW HMUARTLGW 192.168.42.23
attr meinLGW lgwPw LGWPasswort
attr meinLGW hmId C0FFEE

* <code>192.168.42.23</code> ist die IP-Adresse des LAN-Gateways.
* <code>LGWPasswort</code> muss durch das Passwort des LAN-Gateways zu ersetzen ist. Das Default-Passwort ist auf der Rückseite des Geräts aufgedruckt.
* <code>C0FFEE</code> ist die [[HomeMatic Devices pairen#hmId|Homematic-ID (hmId)]], mit der [[HomeMatic Devices pairen|Homematic-Geräte gepaired]] werden.

=== Verschlüsselung ===

Das Modul beherrscht von sich die verschlüsselte Kommunikation mit den Homematic-Geräten. [[AES Encryption]] bietet Informationen zu diesem Thema.

Die LAN-Kommunikation ist standardmäßig ebenfalls verschlüsselt. Dazu wird das <code>Crypt::Rijndael</code> Perl-Modul benötigt. Wenn das Modul fehlt, weißen Log-Einträge darauf hin. Unter [[Raspberry Pi]] kann <code>Crypt::Rijndael</code> mit folgendem Befehlt installiert werden: <code>sudo apt-get install libcrypt-rijndael-perl</code>. Anschließend muss FHEM neugestartet werden, um das Modul zu finden. Die LAN-Verschlüsselung kann mit dem "NetFinder"-Tool von eQ-3 aktiviert und deaktiviert werden.

== Firmware ==

Das LAN-Gateway hat zwei Firmwares ("Applikations-Firmware" und "LAN-Firmware") die ggf. aktualisiert werden sollten. Frühere Versionen haben Stabilitätsprobleme. Die LAN-Firmware sollte mindestens auf Version 1.1.5 sein, die Applikations-Firmware sollte mindestens auf Version 1.4.1 sein.

Die Applikations-Firmware kann direkt aus FHEM aktualisiert werden, für die Aktualisierung der LAN-Firmware wird entweder der [http://www.eq-3.de/service/downloads.html?id=53 HomeMatic Netfinder] (Java, läuft unter Linux/OSX/Windows, [https://github.com/eq-3/occu/raw/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/hm-lgw-o-tw-w-eu_update.eq3 passendes Firmware-Image v. 1.1.5]) oder die eQ-3 Tools unter Linux benötigt. Die eQ-3 Tools liegen nur in 32bit vor, weshalb auf einem x86_64 System (amd64) noch die 32bit Kompatibilitätsbibliotheken ''libc6-i386'' und ''lib32stdc++6'' installiert werden müssen.

'''Bekannte Probleme:''' Nachdem die Firmware 1.1.5 über NetFinder geladen wurde, wird das LAN-Gateway automatisch neu gestartet. Nach dem Neustart zeigt NetFinder eine ''ältere'' Version an (zum Beispiel vorher "1.1.3", nachher "1.1.1"). Durch einen erneuten Neustart des LAN-Gateways (durch Ziehen des Netzsteckers) kann das Problem behoben werden und NetFinder zeigt die richtige Version an.

=== Vorbereitung des LAN-Firmwareupdates mit den eQ-3 Tools ===

Installation der Kompatibilitätsbibliotheken (nur auf x86_64/amd64 ohne konfiguriertes Multiarch):
$ sudo apt-get install libc6-i386 lib32stdc++6

Auschecken und Vorbereitung der eQ-3-Tools:
$ git clone https://github.com/eq-3/occu
...
$ cd occu
$ sudo ln -s $(pwd)/firmware /firmware

Auf arm:
$ cd arm-gnueabihf/packages-eQ-3/LinuxBasis/bin

Auf x86 bzw. x86_64:
$ cd X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin (auf X86/X86_64)

Wieder gemeinsam auf allen Plattformen:
$ chmod 755 eq3configcmd

=== Update der LAN-Firmware mit den eQ-3 Tools ===

Um das Update durchzuführen, muss man sich im Verzeichnis ''occu/arm-gnueabihf/packages-eQ-3/LinuxBasis/bin'' bzw. ''occu/X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin'' befinden.

Im Folgenden <code>NEQ0218723</code> durch die Seriennummer des Funk-LAN-Gateway und <code>geheimesLGWPasswort</code> durch das Lan-Gateway-Passwort (steht auf der Rückseite des Geräts) ersetzen. Falls die Verschlüsselung deaktiviert wurde entfällt die <code>-k</code>-Option.

export LD_LIBRARY_PATH='../lib:../../RFD/lib'
LGW_SERIAL='NEQ0218723'
LGW_PASSWD='geheimesLGWPasswort'
./eq3configcmd update-lgw-firmware -u ../../../../firmware/hm-lgw-o-tw-w-eu_update.eq3 -s "${LGW_SERIAL}" -k "${LGW_PASSWD}" -console -l 1
2016/07/28 09:25:24.264 <Info> LAN Gateway Firmware Update...

2016/07/28 09:25:24.265 <Info> Gateway NEQ0218723
2016/07/28 09:25:26.273 <Info> Gateway type is eQ3-HM-LGW-App
cryptEnabled true2016/07/28 09:25:33.313 <Info> Updating firmware....

2016/07/28 09:25:38.467 <Info> Update performed. Waiting for gateway to get ready.

=== Update der Applikationsfirmware mit FHEM ===

# Firmware herunterladen
## Verbinden Sie sich auf ihren Raspberry <code>ssh pi@$IPADRESSE</code>
## Wechseln Sie in das Firmware-Verzeichnis von FHEM <code>cd /opt/fhem/FHEM/firmware/</code>
## Firmware herunderladen <code>wget https://raw.githubusercontent.com/eq-3/occu/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/coprocessor_update_hm_only.eq3</code>
# Flashen der neuen Firmware über die Befehlszeile in FHEM <code>set meinLGW updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update_hm_only.eq3</code>

== Bekannte Probleme ==
Das LGW hat (anders als das UART-Modul) keine eigene ''hmId'' (das Reading ''D-HMIdOriginal'' ist auf FFFFFF gesetzt). Es muss also mit
:<code>attr meinLGW hmId xxxxxx</code>
eine nach den in der [http://fhem.de/commandref.html#hmId commandref] definierten Regeln gewählte Id gesetzt werden.

== Links ==
* {{Link2Forum|Topic=41203|LinkText=Forenthread}} mit Nachfrage zur Unterstützung dieses Geräts in FHEM
* {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}
* [http://www.elv.de/homematic-funk-lan-gateway.html Produktseite] bei ELV
* {{DocLink|elv|/Assets/Produkte/10/1040/104029/Downloads/104029_lan_gateway_um.pdf Bedienungsanleitung}}

[[Kategorie:HomeMatic Components]]
[[Kategorie:Interfaces]]

HM-LGW-O-TW-W-EU Funk-LAN Gateway

2018-01-06T10:01:10Z

Octo: /* Update der LAN-Firmware mit den eQ-3 Tools */ Seriennummer und Passwort in Variablen ausgelagert, um Aufruf lesbarer zu machen.

{{Infobox Hardware
|Bild=HM-LGW-O-TW-W-EU-2.jpg
|Bildbeschreibung=HomeMatic Funk-LAN Gateway
|HWProtocol=HomeMatic
|HWType=Gateway
|HWCategory=HomeMatic
|HWComm=868,3/869,525 MHz
|HWChannels=n/a
|HWVoltage=5V DC
|HWPowerConsumption=0,8W
|HWPoweredBy=DC-Buchse
|HWSize=116x150x34mm
|HWDeviceFHEM=[[HMUARTLGW]]
|HWManufacturer=ELV / eQ-3
}}

Das [[HM-LGW-O-TW-W-EU Funk-LAN Gateway|HM-LGW-O-TW-W-EU(-2) Funk-LAN Gateway]] ist ein [[Interface]] zu [[HomeMatic]] Geräten, ähnlich dem [[HM-CFG-LAN LAN Konfigurations-Adapter|LAN Konfigurations-Adapter]]. Die folgende Beschreibung bezieht sich sowohl auf HM-LGW-O-TW-W-EU als auch auf HM-LGW-O-TW-W-EU-2 (wenn nicht anders angegeben).

Das Gateway unterstützt ausschließlich das Homematic Funkprotokoll und kann nicht zur Reichweitenverlängerung von [[HomeMatic IP|Homematic IP]] eingesetzt werden

== Features ==
(Noch zu ergänzen)
* ...

== Hinweise zum Betrieb mit FHEM ==
Juni 2016: Beginn der Entwicklung eines FHEM-Moduls (HMUARTLGW) für dieses Interface, beschrieben im Forum unter dem Titel {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}. Dieses Modul unterstützt gleichzeitig auch das [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi|Funkmodul für Raspberry Pi]].

Juli 2016: [[HMUARTLGW]] wird über FHEM [[update]] verteilt, damit ist dieses Funkmodul offiziell unterstützt.

=== Definition in FHEM ===

define meinLGW HMUARTLGW 192.168.42.23
attr meinLGW lgwPw LGWPasswort
attr meinLGW hmId C0FFEE

* <code>192.168.42.23</code> ist die IP-Adresse des LAN-Gateways.
* <code>LGWPasswort</code> muss durch das Passwort des LAN-Gateways zu ersetzen ist. Das Default-Passwort ist auf der Rückseite des Geräts aufgedruckt.
* <code>C0FFEE</code> ist die [[HomeMatic Devices pairen#hmId|Homematic-ID (hmId)]], mit der [[HomeMatic Devices pairen|Homematic-Geräte gepaired]] werden.

=== Verschlüsselung ===

Das Modul beherrscht von sich die verschlüsselte Kommunikation mit den Homematic-Geräten. [[AES Encryption]] bietet Informationen zu diesem Thema.

Die LAN-Kommunikation ist standardmäßig ebenfalls verschlüsselt. Dazu wird das <code>Crypt::Rijndael</code> Perl-Modul benötigt. Wenn das Modul fehlt, weißen Log-Einträge darauf hin. Unter [[Raspberry Pi]] kann <code>Crypt::Rijndael</code> mit folgendem Befehlt installiert werden: <code>sudo apt-get install libcrypt-rijndael-perl</code>. Anschließend muss FHEM neugestartet werden, um das Modul zu finden. Die LAN-Verschlüsselung kann mit dem "NetFinder"-Tool von eQ-3 aktiviert und deaktiviert werden.

== Firmware ==

Das LAN-Gateway hat zwei Firmwares ("Applikations-Firmware" und "LAN-Firmware") die ggf. aktualisiert werden sollten. Frühere Versionen haben Stabilitätsprobleme. Die LAN-Firmware sollte mindestens auf Version 1.1.5 sein, die Applikations-Firmware sollte mindestens auf Version 1.4.1 sein.

Die Applikations-Firmware kann direkt aus FHEM aktualisiert werden, für die Aktualisierung der LAN-Firmware wird entweder der [http://www.eq-3.de/service/downloads.html?id=53 HomeMatic Netfinder] (Java, läuft unter Linux/OSX/Windows, [https://github.com/eq-3/occu/raw/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/hm-lgw-o-tw-w-eu_update.eq3 passendes Firmware-Image v. 1.1.5]) oder die eQ-3 Tools unter Linux benötigt. Die eQ-3 Tools liegen nur in 32bit vor, weshalb auf einem x86_64 System (amd64) noch die 32bit Kompatibilitätsbibliotheken ''libc6-i386'' und ''lib32stdc++6'' installiert werden müssen.

'''Bekannte Probleme:''' Nachdem die Firmware 1.1.5 über NetFinder geladen wurde, wird das LAN-Gateway automatisch neu gestartet. Nach dem Neustart zeigt NetFinder eine ''ältere'' Version an (zum Beispiel vorher "1.1.3", nachher "1.1.1"). Durch einen erneuten Neustart des LAN-Gateways (durch Ziehen des Netzsteckers) kann das Problem behoben werden und NetFinder zeigt die richtige Version an.

=== Vorbereitung des LAN-Firmwareupdates mit den eQ-3 Tools ===

Installation der Kompatibilitätsbibliotheken (nur auf x86_64/amd64 ohne konfiguriertes Multiarch):
$ sudo apt-get install libc6-i386 lib32stdc++6

Auschecken und Vorbereitung der eQ-3-Tools:
$ git clone https://github.com/eq-3/occu
...
$ cd occu
$ sudo ln -s $(pwd)/firmware /firmware

Auf arm:
$ cd arm-gnueabihf/packages-eQ-3/LinuxBasis/bin

Auf x86 bzw. x86_64:
$ cd X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin (auf X86/X86_64)

Wieder gemeinsam auf allen Plattformen:
$ chmod 755 eq3configcmd

=== Update der LAN-Firmware mit den eQ-3 Tools ===

Um das Update durchzuführen, muss man sich im Verzeichnis ''occu/arm-gnueabihf/packages-eQ-3/LinuxBasis/bin'' bzw. ''occu/X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin'' befinden.

Im Folgenden <code>NEQ0218723</code> durch die Seriennummer des Funk-LAN-Gateway und <code>geheimesLGWPasswort</code> durch das Lan-Gateway-Passwort (steht auf der Rückseite des Geräts) ersetzen. Falls die Verschlüsselung deaktiviert wurde entfällt die <code>-k</code>-Option.

export LD_LIBRARY_PATH='../lib:../../RFD/lib'
LGW_SERIAL='NEQ0218723'
LGW_PASSWD='geheimesLGWPasswort'
./eq3configcmd update-lgw-firmware -u ../../../../firmware/hm-lgw-o-tw-w-eu_update.eq3 -s "${LGW_SERIAL}" -k "${LGW_PASSWD}" -console -l 1
2016/07/28 09:25:24.264 <Info> LAN Gateway Firmware Update...

2016/07/28 09:25:24.265 <Info> Gateway NEQ0218723
2016/07/28 09:25:26.273 <Info> Gateway type is eQ3-HM-LGW-App
cryptEnabled true2016/07/28 09:25:33.313 <Info> Updating firmware....

2016/07/28 09:25:38.467 <Info> Update performed. Waiting for gateway to get ready.

=== Update der Applikationsfirmware mit FHEM ===

# Firmware herunterladen
## Verbinden Sie sich auf ihren Raspberry <code>ssh pi@$IPADRESSE</code>
## Wechseln Sie in das Firmware-Verzeichnis von FHEM <code>cd /opt/fhem/FHEM/firmware/</code>
## Firmware herunderladen <code>wget https://raw.githubusercontent.com/eq-3/occu/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/coprocessor_update_hm_only.eq3</code>
# Flashen der neuen Firmware über die Befehlszeile in FHEM <code>set meinLGW updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update_hm_only.eq3</code>

== Bekannte Probleme ==
Das LGW hat (anders als das UART-Modul) keine eigene ''hmId'' (das Reading ''D-HMIdOriginal'' ist auf FFFFFF gesetzt). Es muss also mit
:<code>attr meinLGW hmId xxxxxx</code>
eine nach den in der [http://fhem.de/commandref.html#hmId commandref] definierten Regeln gewählte Id gesetzt werden.

== Links ==
* {{Link2Forum|Topic=41203|LinkText=Forenthread}} mit Nachfrage zur Unterstützung dieses Geräts in FHEM
* {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}
* [http://www.elv.de/homematic-funk-lan-gateway.html Produktseite] bei ELV
* {{DocLink|elv|/Assets/Produkte/10/1040/104029/Downloads/104029_lan_gateway_um.pdf Bedienungsanleitung}}

[[Kategorie:HomeMatic Components]]
[[Kategorie:Interfaces]]

HM-LGW-O-TW-W-EU Funk-LAN Gateway

2018-01-06T09:21:08Z

Octo: /* Firmware */ Markup verbessert, einige Formulierungen verbessert.

{{Infobox Hardware
|Bild=HM-LGW-O-TW-W-EU-2.jpg
|Bildbeschreibung=HomeMatic Funk-LAN Gateway
|HWProtocol=HomeMatic
|HWType=Gateway
|HWCategory=HomeMatic
|HWComm=868,3/869,525 MHz
|HWChannels=n/a
|HWVoltage=5V DC
|HWPowerConsumption=0,8W
|HWPoweredBy=DC-Buchse
|HWSize=116x150x34mm
|HWDeviceFHEM=[[HMUARTLGW]]
|HWManufacturer=ELV / eQ-3
}}

Das [[HM-LGW-O-TW-W-EU Funk-LAN Gateway|HM-LGW-O-TW-W-EU(-2) Funk-LAN Gateway]] ist ein [[Interface]] zu [[HomeMatic]] Geräten, ähnlich dem [[HM-CFG-LAN LAN Konfigurations-Adapter|LAN Konfigurations-Adapter]]. Die folgende Beschreibung bezieht sich sowohl auf HM-LGW-O-TW-W-EU als auch auf HM-LGW-O-TW-W-EU-2 (wenn nicht anders angegeben).

Das Gateway unterstützt ausschließlich das Homematic Funkprotokoll und kann nicht zur Reichweitenverlängerung von [[HomeMatic IP|Homematic IP]] eingesetzt werden

== Features ==
(Noch zu ergänzen)
* ...

== Hinweise zum Betrieb mit FHEM ==
Juni 2016: Beginn der Entwicklung eines FHEM-Moduls (HMUARTLGW) für dieses Interface, beschrieben im Forum unter dem Titel {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}. Dieses Modul unterstützt gleichzeitig auch das [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi|Funkmodul für Raspberry Pi]].

Juli 2016: [[HMUARTLGW]] wird über FHEM [[update]] verteilt, damit ist dieses Funkmodul offiziell unterstützt.

=== Definition in FHEM ===

define meinLGW HMUARTLGW 192.168.42.23
attr meinLGW lgwPw LGWPasswort
attr meinLGW hmId C0FFEE

* <code>192.168.42.23</code> ist die IP-Adresse des LAN-Gateways.
* <code>LGWPasswort</code> muss durch das Passwort des LAN-Gateways zu ersetzen ist. Das Default-Passwort ist auf der Rückseite des Geräts aufgedruckt.
* <code>C0FFEE</code> ist die [[HomeMatic Devices pairen#hmId|Homematic-ID (hmId)]], mit der [[HomeMatic Devices pairen|Homematic-Geräte gepaired]] werden.

=== Verschlüsselung ===

Das Modul beherrscht von sich die verschlüsselte Kommunikation mit den Homematic-Geräten. [[AES Encryption]] bietet Informationen zu diesem Thema.

Die LAN-Kommunikation ist standardmäßig ebenfalls verschlüsselt. Dazu wird das <code>Crypt::Rijndael</code> Perl-Modul benötigt. Wenn das Modul fehlt, weißen Log-Einträge darauf hin. Unter [[Raspberry Pi]] kann <code>Crypt::Rijndael</code> mit folgendem Befehlt installiert werden: <code>sudo apt-get install libcrypt-rijndael-perl</code>. Anschließend muss FHEM neugestartet werden, um das Modul zu finden. Die LAN-Verschlüsselung kann mit dem "NetFinder"-Tool von eQ-3 aktiviert und deaktiviert werden.

== Firmware ==

Das LAN-Gateway hat zwei Firmwares ("Applikations-Firmware" und "LAN-Firmware") die ggf. aktualisiert werden sollten. Frühere Versionen haben Stabilitätsprobleme. Die LAN-Firmware sollte mindestens auf Version 1.1.5 sein, die Applikations-Firmware sollte mindestens auf Version 1.4.1 sein.

Die Applikations-Firmware kann direkt aus FHEM aktualisiert werden, für die Aktualisierung der LAN-Firmware wird entweder der [http://www.eq-3.de/service/downloads.html?id=53 HomeMatic Netfinder] (Java, läuft unter Linux/OSX/Windows, [https://github.com/eq-3/occu/raw/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/hm-lgw-o-tw-w-eu_update.eq3 passendes Firmware-Image v. 1.1.5]) oder die eQ-3 Tools unter Linux benötigt. Die eQ-3 Tools liegen nur in 32bit vor, weshalb auf einem x86_64 System (amd64) noch die 32bit Kompatibilitätsbibliotheken ''libc6-i386'' und ''lib32stdc++6'' installiert werden müssen.

'''Bekannte Probleme:''' Nachdem die Firmware 1.1.5 über NetFinder geladen wurde, wird das LAN-Gateway automatisch neu gestartet. Nach dem Neustart zeigt NetFinder eine ''ältere'' Version an (zum Beispiel vorher "1.1.3", nachher "1.1.1"). Durch einen erneuten Neustart des LAN-Gateways (durch Ziehen des Netzsteckers) kann das Problem behoben werden und NetFinder zeigt die richtige Version an.

=== Vorbereitung des LAN-Firmwareupdates mit den eQ-3 Tools ===

Installation der Kompatibilitätsbibliotheken (nur auf x86_64/amd64 ohne konfiguriertes Multiarch):
$ sudo apt-get install libc6-i386 lib32stdc++6

Auschecken und Vorbereitung der eQ-3-Tools:
$ git clone https://github.com/eq-3/occu
...
$ cd occu
$ sudo ln -s $(pwd)/firmware /firmware

Auf arm:
$ cd arm-gnueabihf/packages-eQ-3/LinuxBasis/bin

Auf x86 bzw. x86_64:
$ cd X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin (auf X86/X86_64)

Wieder gemeinsam auf allen Plattformen:
$ chmod 755 eq3configcmd

=== Update der LAN-Firmware mit den eQ-3 Tools ===

Um das Update durchzuführen, muss man sich im Verzeichnis ''occu/arm-gnueabihf/packages-eQ-3/LinuxBasis/bin'' bzw. ''occu/X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin'' befinden.

Im Folgenden <code>NEQ0218723</code> durch die Seriennummer des Funk-LAN-Gateway und <code>geheimesLGWPasswort</code> durch das Lan-Gateway-Passwort (steht auf der Rückseite des Geräts) ersetzen. Falls die Verschlüsselung deaktiviert wurde entfällt die <code>-k</code>-Option.

$ LD_LIBRARY_PATH=../lib:../../RFD/lib ./eq3configcmd update-lgw-firmware -u ../../../../firmware/hm-lgw-o-tw-w-eu_update.eq3 -console -l 1 -s NEQ0218723 -k 'geheimesLGWPasswort'
2016/07/28 09:25:24.264 <Info> LAN Gateway Firmware Update...

2016/07/28 09:25:24.265 <Info> Gateway NEQ0218723
2016/07/28 09:25:26.273 <Info> Gateway type is eQ3-HM-LGW-App
cryptEnabled true2016/07/28 09:25:33.313 <Info> Updating firmware....

2016/07/28 09:25:38.467 <Info> Update performed. Waiting for gateway to get ready.

=== Update der Applikationsfirmware mit FHEM ===

# Firmware herunterladen
## Verbinden Sie sich auf ihren Raspberry <code>ssh pi@$IPADRESSE</code>
## Wechseln Sie in das Firmware-Verzeichnis von FHEM <code>cd /opt/fhem/FHEM/firmware/</code>
## Firmware herunderladen <code>wget https://raw.githubusercontent.com/eq-3/occu/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/coprocessor_update_hm_only.eq3</code>
# Flashen der neuen Firmware über die Befehlszeile in FHEM <code>set meinLGW updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update_hm_only.eq3</code>

== Bekannte Probleme ==
Das LGW hat (anders als das UART-Modul) keine eigene ''hmId'' (das Reading ''D-HMIdOriginal'' ist auf FFFFFF gesetzt). Es muss also mit
:<code>attr meinLGW hmId xxxxxx</code>
eine nach den in der [http://fhem.de/commandref.html#hmId commandref] definierten Regeln gewählte Id gesetzt werden.

== Links ==
* {{Link2Forum|Topic=41203|LinkText=Forenthread}} mit Nachfrage zur Unterstützung dieses Geräts in FHEM
* {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}
* [http://www.elv.de/homematic-funk-lan-gateway.html Produktseite] bei ELV
* {{DocLink|elv|/Assets/Produkte/10/1040/104029/Downloads/104029_lan_gateway_um.pdf Bedienungsanleitung}}

[[Kategorie:HomeMatic Components]]
[[Kategorie:Interfaces]]

HM-LGW-O-TW-W-EU Funk-LAN Gateway

2018-01-06T08:43:13Z

Octo: /* Firmware */ Hinweis auf zu ersetzenden Platzhalter näher an das Code-Schnippselchen rangerückt.

{{Infobox Hardware
|Bild=HM-LGW-O-TW-W-EU-2.jpg
|Bildbeschreibung=HomeMatic Funk-LAN Gateway
|HWProtocol=HomeMatic
|HWType=Gateway
|HWCategory=HomeMatic
|HWComm=868,3/869,525 MHz
|HWChannels=n/a
|HWVoltage=5V DC
|HWPowerConsumption=0,8W
|HWPoweredBy=DC-Buchse
|HWSize=116x150x34mm
|HWDeviceFHEM=[[HMUARTLGW]]
|HWManufacturer=ELV / eQ-3
}}

Das [[HM-LGW-O-TW-W-EU Funk-LAN Gateway|HM-LGW-O-TW-W-EU(-2) Funk-LAN Gateway]] ist ein [[Interface]] zu [[HomeMatic]] Geräten, ähnlich dem [[HM-CFG-LAN LAN Konfigurations-Adapter|LAN Konfigurations-Adapter]]. Die folgende Beschreibung bezieht sich sowohl auf HM-LGW-O-TW-W-EU als auch auf HM-LGW-O-TW-W-EU-2 (wenn nicht anders angegeben).

Das Gateway unterstützt ausschließlich das Homematic Funkprotokoll und kann nicht zur Reichweitenverlängerung von [[HomeMatic IP|Homematic IP]] eingesetzt werden

== Features ==
(Noch zu ergänzen)
* ...

== Hinweise zum Betrieb mit FHEM ==
Juni 2016: Beginn der Entwicklung eines FHEM-Moduls (HMUARTLGW) für dieses Interface, beschrieben im Forum unter dem Titel {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}. Dieses Modul unterstützt gleichzeitig auch das [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi|Funkmodul für Raspberry Pi]].

Juli 2016: [[HMUARTLGW]] wird über FHEM [[update]] verteilt, damit ist dieses Funkmodul offiziell unterstützt.

=== Definition in FHEM ===

define meinLGW HMUARTLGW 192.168.42.23
attr meinLGW lgwPw LGWPasswort
attr meinLGW hmId C0FFEE

* <code>192.168.42.23</code> ist die IP-Adresse des LAN-Gateways.
* <code>LGWPasswort</code> muss durch das Passwort des LAN-Gateways zu ersetzen ist. Das Default-Passwort ist auf der Rückseite des Geräts aufgedruckt.
* <code>C0FFEE</code> ist die [[HomeMatic Devices pairen#hmId|Homematic-ID (hmId)]], mit der [[HomeMatic Devices pairen|Homematic-Geräte gepaired]] werden.

=== Verschlüsselung ===

Das Modul beherrscht von sich die verschlüsselte Kommunikation mit den Homematic-Geräten. [[AES Encryption]] bietet Informationen zu diesem Thema.

Die LAN-Kommunikation ist standardmäßig ebenfalls verschlüsselt. Dazu wird das <code>Crypt::Rijndael</code> Perl-Modul benötigt. Wenn das Modul fehlt, weißen Log-Einträge darauf hin. Unter [[Raspberry Pi]] kann <code>Crypt::Rijndael</code> mit folgendem Befehlt installiert werden: <code>sudo apt-get install libcrypt-rijndael-perl</code>. Anschließend muss FHEM neugestartet werden, um das Modul zu finden. Die LAN-Verschlüsselung kann mit dem "NetFinder"-Tool von eQ-3 aktiviert und deaktiviert werden.

== Firmware ==

Es sollte darauf geachtet werden, dass die beiden Firmware-Versionen des Funk-LAN Gateway aktuell sind (aktuell: Applikation: 1.4.1, LAN: 1.1.5). LAN-Firmwareversionen < 1.1.5 haben Stabilitätsprobleme.

Die Applikationsfirmware kann direkt aus FHEM aktualisiert werden, für die Aktualisierung der LAN-Firmware wird entweder der [http://www.eq-3.de/service/downloads.html?id=53 HomeMatic Netfinder] (Java, läuft unter Linux/OSX/Windows, [https://github.com/eq-3/occu/raw/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/hm-lgw-o-tw-w-eu_update.eq3 passendes Firmware-Image v. 1.1.5]) oder die eQ-3 Tools unter Linux benötigt. Die eQ-3 Tools liegen nur in 32bit vor, weshalb auf einem x86_64 System (amd64) noch die 32bit Kompatibilitätsbibliotheken ''libc6-i386'' und ''lib32stdc++6'' installiert werden müssen.

Bekannte Probleme: Nachdem die Firmware 1.1.5 über die Software Netfinder geladen wurde, wird das Gateway automatisch neu gestartet. Nach dem Neustart wird im Netfinder eine ältere Version angezeigt (z.B. vorher 1.1.3 nachher 1.1.1). Am Homatic Gateway muss der Netzstecker gezogen und wieder gesteckt werden. Nach dem Neustart wird dann die richtige Version angezeigt.

=== Vorbereitung des LAN-Firmwareupdates mit den eQ-3 Tools ===

Installation der Kompatibilitätsbibliotheken (nur auf x86_64/amd64 ohne konfiguriertes Multiarch):
$ sudo apt-get install libc6-i386 lib32stdc++6

Auschecken und Vorbereitung der eQ-3-Tools:
$ git clone https://github.com/eq-3/occu
...
$ cd occu
$ sudo ln -s $(pwd)/firmware /firmware

Auf arm:
$ cd arm-gnueabihf/packages-eQ-3/LinuxBasis/bin

Auf x86 bzw. x86_64:
$ cd X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin (auf X86/X86_64)

Wieder gemeinsam auf allen Plattformen:
$ chmod 755 eq3configcmd

=== Update der LAN-Firmware mit den eQ-3 Tools ===

Um das Update durchzuführen, muss man sich im Verzeichnis ''occu/arm-gnueabihf/packages-eQ-3/LinuxBasis/bin'' bzw. ''occu/X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin'' befinden.

Im Folgenden <code>NEQ0218723</code> durch die Seriennummer des Funk-LAN-Gateway und <code>geheimesLGWPasswort</code> durch das Lan-Gateway-Passwort (steht auf der Rückseite des Geräts) ersetzen. Falls die Verschlüsselung deaktiviert wurde entfällt die <code>-k</code>-Option.

$ LD_LIBRARY_PATH=../lib:../../RFD/lib ./eq3configcmd update-lgw-firmware -u ../../../../firmware/hm-lgw-o-tw-w-eu_update.eq3 -console -l 1 -s NEQ0218723 -k 'geheimesLGWPasswort'
2016/07/28 09:25:24.264 <Info> LAN Gateway Firmware Update...

2016/07/28 09:25:24.265 <Info> Gateway NEQ0218723
2016/07/28 09:25:26.273 <Info> Gateway type is eQ3-HM-LGW-App
cryptEnabled true2016/07/28 09:25:33.313 <Info> Updating firmware....

2016/07/28 09:25:38.467 <Info> Update performed. Waiting for gateway to get ready.

=== Update der Applikationsfirmware mit FHEM ===

1. Firmware herunterladen
a: Verbinden Sie sich auf ihren Raspberry
ssh pi@ipadresse
b: Wechseln Sie in das Firmware Verzeichnis von FHEM
cd /opt/fhem/FHEM/firmware/
c: Firmware Downloaden
wget https://raw.githubusercontent.com/eq-3/occu/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/coprocessor_update_hm_only.eq3
2. Flashen der neuen Firmware über die Befehlszeile in FHEM
set meinLGW updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update_hm_only.eq3

== Bekannte Probleme ==
Das LGW hat (anders als das UART-Modul) keine eigene ''hmId'' (das Reading ''D-HMIdOriginal'' ist auf FFFFFF gesetzt). Es muss also mit
:<code>attr meinLGW hmId xxxxxx</code>
eine nach den in der [http://fhem.de/commandref.html#hmId commandref] definierten Regeln gewählte Id gesetzt werden.

== Links ==
* {{Link2Forum|Topic=41203|LinkText=Forenthread}} mit Nachfrage zur Unterstützung dieses Geräts in FHEM
* {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}
* [http://www.elv.de/homematic-funk-lan-gateway.html Produktseite] bei ELV
* {{DocLink|elv|/Assets/Produkte/10/1040/104029/Downloads/104029_lan_gateway_um.pdf Bedienungsanleitung}}

[[Kategorie:HomeMatic Components]]
[[Kategorie:Interfaces]]

HM-LGW-O-TW-W-EU Funk-LAN Gateway

2018-01-06T08:37:41Z

Octo: /* Verschlüsselung */ Abschnitt umbenannt.

{{Infobox Hardware
|Bild=HM-LGW-O-TW-W-EU-2.jpg
|Bildbeschreibung=HomeMatic Funk-LAN Gateway
|HWProtocol=HomeMatic
|HWType=Gateway
|HWCategory=HomeMatic
|HWComm=868,3/869,525 MHz
|HWChannels=n/a
|HWVoltage=5V DC
|HWPowerConsumption=0,8W
|HWPoweredBy=DC-Buchse
|HWSize=116x150x34mm
|HWDeviceFHEM=[[HMUARTLGW]]
|HWManufacturer=ELV / eQ-3
}}

Das [[HM-LGW-O-TW-W-EU Funk-LAN Gateway|HM-LGW-O-TW-W-EU(-2) Funk-LAN Gateway]] ist ein [[Interface]] zu [[HomeMatic]] Geräten, ähnlich dem [[HM-CFG-LAN LAN Konfigurations-Adapter|LAN Konfigurations-Adapter]]. Die folgende Beschreibung bezieht sich sowohl auf HM-LGW-O-TW-W-EU als auch auf HM-LGW-O-TW-W-EU-2 (wenn nicht anders angegeben).

Das Gateway unterstützt ausschließlich das Homematic Funkprotokoll und kann nicht zur Reichweitenverlängerung von [[HomeMatic IP|Homematic IP]] eingesetzt werden

== Features ==
(Noch zu ergänzen)
* ...

== Hinweise zum Betrieb mit FHEM ==
Juni 2016: Beginn der Entwicklung eines FHEM-Moduls (HMUARTLGW) für dieses Interface, beschrieben im Forum unter dem Titel {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}. Dieses Modul unterstützt gleichzeitig auch das [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi|Funkmodul für Raspberry Pi]].

Juli 2016: [[HMUARTLGW]] wird über FHEM [[update]] verteilt, damit ist dieses Funkmodul offiziell unterstützt.

=== Definition in FHEM ===

define meinLGW HMUARTLGW 192.168.42.23
attr meinLGW lgwPw LGWPasswort
attr meinLGW hmId C0FFEE

* <code>192.168.42.23</code> ist die IP-Adresse des LAN-Gateways.
* <code>LGWPasswort</code> muss durch das Passwort des LAN-Gateways zu ersetzen ist. Das Default-Passwort ist auf der Rückseite des Geräts aufgedruckt.
* <code>C0FFEE</code> ist die [[HomeMatic Devices pairen#hmId|Homematic-ID (hmId)]], mit der [[HomeMatic Devices pairen|Homematic-Geräte gepaired]] werden.

=== Verschlüsselung ===

Das Modul beherrscht von sich die verschlüsselte Kommunikation mit den Homematic-Geräten. [[AES Encryption]] bietet Informationen zu diesem Thema.

Die LAN-Kommunikation ist standardmäßig ebenfalls verschlüsselt. Dazu wird das <code>Crypt::Rijndael</code> Perl-Modul benötigt. Wenn das Modul fehlt, weißen Log-Einträge darauf hin. Unter [[Raspberry Pi]] kann <code>Crypt::Rijndael</code> mit folgendem Befehlt installiert werden: <code>sudo apt-get install libcrypt-rijndael-perl</code>. Anschließend muss FHEM neugestartet werden, um das Modul zu finden. Die LAN-Verschlüsselung kann mit dem "NetFinder"-Tool von eQ-3 aktiviert und deaktiviert werden.

=== Firmware ===

Es sollte darauf geachtet werden, dass die beiden Firmware-Versionen des Funk-LAN Gateway aktuell sind (aktuell: Applikation: 1.4.1, LAN: 1.1.5). LAN-Firmwareversionen < 1.1.5 haben Stabilitätsprobleme.

Die Applikationsfirmware kann direkt aus FHEM aktualisiert werden, für die Aktualisierung der LAN-Firmware wird entweder der [http://www.eq-3.de/service/downloads.html?id=53 HomeMatic Netfinder] (Java, läuft unter Linux/OSX/Windows, [https://github.com/eq-3/occu/raw/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/hm-lgw-o-tw-w-eu_update.eq3 passendes Firmware-Image v. 1.1.5]) oder die eQ-3 Tools unter Linux benötigt. Die eQ-3 Tools liegen nur in 32bit vor, weshalb auf einem x86_64 System (amd64) noch die 32bit Kompatibilitätsbibliotheken ''libc6-i386'' und ''lib32stdc++6'' installiert werden müssen.

Bekannte Probleme: Nachdem die Firmware 1.1.5 über die Software Netfinder geladen wurde, wird das Gateway automatisch neu gestartet. Nach dem Neustart wird im Netfinder eine ältere Version angezeigt (z.B. vorher 1.1.3 nachher 1.1.1). Am Homatic Gateway muss der Netzstecker gezogen und wieder gesteckt werden. Nach dem Neustart wird dann die richtige Version angezeigt.

(Im folgenden "NEQ0218723" durch die eigene Seriennummer des Funk-LAN Gateway ersetzen und "geheimesLGWPasswort" durch das LGW-Passwort. Falls die Verschlüsselung deaktiviert wurde, dann das -k komplett weglassen.

=== Vorbereitung des LAN-Firmwareupdates mit den eQ-3 Tools ===

Installation der Kompatibilitätsbibliotheken (nur auf x86_64/amd64 ohne konfiguriertes Multiarch):
$ sudo apt-get install libc6-i386 lib32stdc++6

Auschecken und Vorbereitung der eQ-3-Tools:
$ git clone https://github.com/eq-3/occu
...
$ cd occu
$ sudo ln -s $(pwd)/firmware /firmware

Auf arm:
$ cd arm-gnueabihf/packages-eQ-3/LinuxBasis/bin

Auf x86 bzw. x86_64:
$ cd X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin (auf X86/X86_64)

Wieder gemeinsam auf allen Plattformen:
$ chmod 755 eq3configcmd

=== Update der LAN-Firmware mit den eQ-3 Tools ===

Um das Update durchzuführen, muss man sich im Verzeichnis ''occu/arm-gnueabihf/packages-eQ-3/LinuxBasis/bin'' bzw. ''occu/X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin'' befinden.

$ LD_LIBRARY_PATH=../lib:../../RFD/lib ./eq3configcmd update-lgw-firmware -u ../../../../firmware/hm-lgw-o-tw-w-eu_update.eq3 -console -l 1 -s NEQ0218723 -k 'geheimesLGWPasswort'
2016/07/28 09:25:24.264 <Info> LAN Gateway Firmware Update...

2016/07/28 09:25:24.265 <Info> Gateway NEQ0218723
2016/07/28 09:25:26.273 <Info> Gateway type is eQ3-HM-LGW-App
cryptEnabled true2016/07/28 09:25:33.313 <Info> Updating firmware....

2016/07/28 09:25:38.467 <Info> Update performed. Waiting for gateway to get ready.

=== Update der Applikationsfirmware mit FHEM ===

1. Firmware herunterladen
a: Verbinden Sie sich auf ihren Raspberry
ssh pi@ipadresse
b: Wechseln Sie in das Firmware Verzeichnis von FHEM
cd /opt/fhem/FHEM/firmware/
c: Firmware Downloaden
wget https://raw.githubusercontent.com/eq-3/occu/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/coprocessor_update_hm_only.eq3
2. Flashen der neuen Firmware über die Befehlszeile in FHEM
set meinLGW updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update_hm_only.eq3

=== Logbeispiel ===

== Bekannte Probleme ==
Das LGW hat (anders als das UART-Modul) keine eigene ''hmId'' (das Reading ''D-HMIdOriginal'' ist auf FFFFFF gesetzt). Es muss also mit
:<code>attr meinLGW hmId xxxxxx</code>
eine nach den in der [http://fhem.de/commandref.html#hmId commandref] definierten Regeln gewählte Id gesetzt werden.

== Links ==
* {{Link2Forum|Topic=41203|LinkText=Forenthread}} mit Nachfrage zur Unterstützung dieses Geräts in FHEM
* {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}
* [http://www.elv.de/homematic-funk-lan-gateway.html Produktseite] bei ELV
* {{DocLink|elv|/Assets/Produkte/10/1040/104029/Downloads/104029_lan_gateway_um.pdf Bedienungsanleitung}}

[[Kategorie:HomeMatic Components]]
[[Kategorie:Interfaces]]

HM-LGW-O-TW-W-EU Funk-LAN Gateway

2018-01-06T08:34:59Z

Octo:

{{Infobox Hardware
|Bild=HM-LGW-O-TW-W-EU-2.jpg
|Bildbeschreibung=HomeMatic Funk-LAN Gateway
|HWProtocol=HomeMatic
|HWType=Gateway
|HWCategory=HomeMatic
|HWComm=868,3/869,525 MHz
|HWChannels=n/a
|HWVoltage=5V DC
|HWPowerConsumption=0,8W
|HWPoweredBy=DC-Buchse
|HWSize=116x150x34mm
|HWDeviceFHEM=[[HMUARTLGW]]
|HWManufacturer=ELV / eQ-3
}}

Das [[HM-LGW-O-TW-W-EU Funk-LAN Gateway|HM-LGW-O-TW-W-EU(-2) Funk-LAN Gateway]] ist ein [[Interface]] zu [[HomeMatic]] Geräten, ähnlich dem [[HM-CFG-LAN LAN Konfigurations-Adapter|LAN Konfigurations-Adapter]]. Die folgende Beschreibung bezieht sich sowohl auf HM-LGW-O-TW-W-EU als auch auf HM-LGW-O-TW-W-EU-2 (wenn nicht anders angegeben).

Das Gateway unterstützt ausschließlich das Homematic Funkprotokoll und kann nicht zur Reichweitenverlängerung von [[HomeMatic IP|Homematic IP]] eingesetzt werden

== Features ==
(Noch zu ergänzen)
* ...

== Hinweise zum Betrieb mit FHEM ==
Juni 2016: Beginn der Entwicklung eines FHEM-Moduls (HMUARTLGW) für dieses Interface, beschrieben im Forum unter dem Titel {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}. Dieses Modul unterstützt gleichzeitig auch das [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi|Funkmodul für Raspberry Pi]].

Juli 2016: [[HMUARTLGW]] wird über FHEM [[update]] verteilt, damit ist dieses Funkmodul offiziell unterstützt.

=== Definition in FHEM ===

define meinLGW HMUARTLGW 192.168.42.23
attr meinLGW lgwPw LGWPasswort
attr meinLGW hmId C0FFEE

* <code>192.168.42.23</code> ist die IP-Adresse des LAN-Gateways.
* <code>LGWPasswort</code> muss durch das Passwort des LAN-Gateways zu ersetzen ist. Das Default-Passwort ist auf der Rückseite des Geräts aufgedruckt.
* <code>C0FFEE</code> ist die [[HomeMatic Devices pairen#hmId|Homematic-ID (hmId)]], mit der [[HomeMatic Devices pairen|Homematic-Geräte gepaired]] werden.

=== Verwendung AES in FHEM===

Das Modul beherrscht von sich die verschlüsselte Kommunikation mit den Homematic-Geräten. [[AES Encryption]] bietet Informationen zu diesem Thema.

Die LAN-Kommunikation ist standardmäßig ebenfalls verschlüsselt. Dazu wird das <code>Crypt::Rijndael</code> Perl-Modul benötigt. Wenn das Modul fehlt, weißen Log-Einträge darauf hin. Unter [[Raspberry Pi]] kann <code>Crypt::Rijndael</code> mit folgendem Befehlt installiert werden: <code>sudo apt-get install libcrypt-rijndael-perl</code>. Anschließend muss FHEM neugestartet werden, um das Modul zu finden. Die LAN-Verschlüsselung kann mit dem "NetFinder"-Tool von eQ-3 aktiviert und deaktiviert werden.

=== Firmware ===

Es sollte darauf geachtet werden, dass die beiden Firmware-Versionen des Funk-LAN Gateway aktuell sind (aktuell: Applikation: 1.4.1, LAN: 1.1.5). LAN-Firmwareversionen < 1.1.5 haben Stabilitätsprobleme.

Die Applikationsfirmware kann direkt aus FHEM aktualisiert werden, für die Aktualisierung der LAN-Firmware wird entweder der [http://www.eq-3.de/service/downloads.html?id=53 HomeMatic Netfinder] (Java, läuft unter Linux/OSX/Windows, [https://github.com/eq-3/occu/raw/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/hm-lgw-o-tw-w-eu_update.eq3 passendes Firmware-Image v. 1.1.5]) oder die eQ-3 Tools unter Linux benötigt. Die eQ-3 Tools liegen nur in 32bit vor, weshalb auf einem x86_64 System (amd64) noch die 32bit Kompatibilitätsbibliotheken ''libc6-i386'' und ''lib32stdc++6'' installiert werden müssen.

Bekannte Probleme: Nachdem die Firmware 1.1.5 über die Software Netfinder geladen wurde, wird das Gateway automatisch neu gestartet. Nach dem Neustart wird im Netfinder eine ältere Version angezeigt (z.B. vorher 1.1.3 nachher 1.1.1). Am Homatic Gateway muss der Netzstecker gezogen und wieder gesteckt werden. Nach dem Neustart wird dann die richtige Version angezeigt.

(Im folgenden "NEQ0218723" durch die eigene Seriennummer des Funk-LAN Gateway ersetzen und "geheimesLGWPasswort" durch das LGW-Passwort. Falls die Verschlüsselung deaktiviert wurde, dann das -k komplett weglassen.

=== Vorbereitung des LAN-Firmwareupdates mit den eQ-3 Tools ===

Installation der Kompatibilitätsbibliotheken (nur auf x86_64/amd64 ohne konfiguriertes Multiarch):
$ sudo apt-get install libc6-i386 lib32stdc++6

Auschecken und Vorbereitung der eQ-3-Tools:
$ git clone https://github.com/eq-3/occu
...
$ cd occu
$ sudo ln -s $(pwd)/firmware /firmware

Auf arm:
$ cd arm-gnueabihf/packages-eQ-3/LinuxBasis/bin

Auf x86 bzw. x86_64:
$ cd X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin (auf X86/X86_64)

Wieder gemeinsam auf allen Plattformen:
$ chmod 755 eq3configcmd

=== Update der LAN-Firmware mit den eQ-3 Tools ===

Um das Update durchzuführen, muss man sich im Verzeichnis ''occu/arm-gnueabihf/packages-eQ-3/LinuxBasis/bin'' bzw. ''occu/X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin'' befinden.

$ LD_LIBRARY_PATH=../lib:../../RFD/lib ./eq3configcmd update-lgw-firmware -u ../../../../firmware/hm-lgw-o-tw-w-eu_update.eq3 -console -l 1 -s NEQ0218723 -k 'geheimesLGWPasswort'
2016/07/28 09:25:24.264 <Info> LAN Gateway Firmware Update...

2016/07/28 09:25:24.265 <Info> Gateway NEQ0218723
2016/07/28 09:25:26.273 <Info> Gateway type is eQ3-HM-LGW-App
cryptEnabled true2016/07/28 09:25:33.313 <Info> Updating firmware....

2016/07/28 09:25:38.467 <Info> Update performed. Waiting for gateway to get ready.

=== Update der Applikationsfirmware mit FHEM ===

1. Firmware herunterladen
a: Verbinden Sie sich auf ihren Raspberry
ssh pi@ipadresse
b: Wechseln Sie in das Firmware Verzeichnis von FHEM
cd /opt/fhem/FHEM/firmware/
c: Firmware Downloaden
wget https://raw.githubusercontent.com/eq-3/occu/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/coprocessor_update_hm_only.eq3
2. Flashen der neuen Firmware über die Befehlszeile in FHEM
set meinLGW updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update_hm_only.eq3

=== Logbeispiel ===

== Bekannte Probleme ==
Das LGW hat (anders als das UART-Modul) keine eigene ''hmId'' (das Reading ''D-HMIdOriginal'' ist auf FFFFFF gesetzt). Es muss also mit
:<code>attr meinLGW hmId xxxxxx</code>
eine nach den in der [http://fhem.de/commandref.html#hmId commandref] definierten Regeln gewählte Id gesetzt werden.

== Links ==
* {{Link2Forum|Topic=41203|LinkText=Forenthread}} mit Nachfrage zur Unterstützung dieses Geräts in FHEM
* {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}
* [http://www.elv.de/homematic-funk-lan-gateway.html Produktseite] bei ELV
* {{DocLink|elv|/Assets/Produkte/10/1040/104029/Downloads/104029_lan_gateway_um.pdf Bedienungsanleitung}}

[[Kategorie:HomeMatic Components]]
[[Kategorie:Interfaces]]

HM-LGW-O-TW-W-EU Funk-LAN Gateway

2018-01-06T07:31:04Z

Octo: /* Definition in FHEM */ Dokumentiert, wo das Default-Passwort zu finden ist.

{{Infobox Hardware
|Bild=HM-LGW-O-TW-W-EU-2.jpg
|Bildbeschreibung=HomeMatic Funk-LAN Gateway
|HWProtocol=HomeMatic
|HWType=Gateway
|HWCategory=HomeMatic
|HWComm=868,3/869,525 MHz
|HWChannels=n/a
|HWVoltage=5V DC
|HWPowerConsumption=0,8W
|HWPoweredBy=DC-Buchse
|HWSize=116x150x34mm
|HWDeviceFHEM=[[HMUARTLGW]]
|HWManufacturer=ELV / eQ-3
}}

Das [[HM-LGW-O-TW-W-EU Funk-LAN Gateway|HM-LGW-O-TW-W-EU(-2) Funk-LAN Gateway]] ist ein [[Interface]] zu [[HomeMatic]] Geräten, ähnlich dem [[HM-CFG-LAN LAN Konfigurations-Adapter|LAN Konfigurations-Adapter]]. Die folgende Beschreibung bezieht sich sowohl auf HM-LGW-O-TW-W-EU als auch auf HM-LGW-O-TW-W-EU-2 (wenn nicht anders angegeben).

Das Gateway unterstützt ausschließlich das Homematic Funkprotokoll und kann nicht zur Reichweitenverlängerung von [[HomeMatic IP|Homematic IP]] eingesetzt werden

== Features ==
(Noch zu ergänzen)
* ...

== Hinweise zum Betrieb mit FHEM ==
Juni 2016: Beginn der Entwicklung eines FHEM-Moduls (HMUARTLGW) für dieses Interface, beschrieben im Forum unter dem Titel {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}. Dieses Modul unterstützt gleichzeitig auch das [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi|Funkmodul für Raspberry Pi]].

Juli 2016: [[HMUARTLGW]] wird über FHEM [[update]] verteilt, damit ist dieses Funkmodul offiziell unterstützt.

=== Definition in FHEM ===

define meinLGW HMUARTLGW 192.168.42.23
attr meinLGW lgwPw LGWPasswort
attr meinLGW hmId C0FFEE

* <code>192.168.42.23</code> ist die IP-Adresse des LAN-Gateways.
* <code>LGWPasswort</code> muss durch das Passwort des LAN-Gateways zu ersetzen ist. Das Default-Passwort ist auf der Rückseite des Geräts aufgedruckt.
* <code>C0FFEE</code> ist die [[HomeMatic Devices pairen#hmId|Homematic-ID (hmId)]], mit der [[HomeMatic Devices pairen|Homematic-Geräte gepaired]] werden.

=== Verwendung AES in FHEM===
Das Modul beherrscht von sich aus AES zu den Geräten. Für weitere Informationen zum Thema Verschlüsselung gibt es den Beitrag [[AES Encryption]].
Soll auch die LAN Kommunikation verschlüsselt ablaufen wird das Modul Crypt::Rijndael (Linux Befehl: "sudo apt-get install libcrypt-rijndael-perl" siehe auch unter [[Raspberry Pi]]) benötigt (siehe auch Meldung im Log).
Die LAN Verschlüsselung kann mit dem Tool Lankonfigurator (netfinder) von eq3 aktiviert oder deaktiviert werden. Im Auslieferungszustand ist sie aktiviert.
Da das Modul Crypt::Rijndael für die Kommunikation mit den Rauchmeldern SD2 auch benötigt wird, kann man dieses Modul per default installieren.

=== Firmware ===

Es sollte darauf geachtet werden, dass die beiden Firmware-Versionen des Funk-LAN Gateway aktuell sind (aktuell: Applikation: 1.4.1, LAN: 1.1.5). LAN-Firmwareversionen < 1.1.5 haben Stabilitätsprobleme.

Die Applikationsfirmware kann direkt aus FHEM aktualisiert werden, für die Aktualisierung der LAN-Firmware wird entweder der [http://www.eq-3.de/service/downloads.html?id=53 HomeMatic Netfinder] (Java, läuft unter Linux/OSX/Windows, [https://github.com/eq-3/occu/raw/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/hm-lgw-o-tw-w-eu_update.eq3 passendes Firmware-Image v. 1.1.5]) oder die eQ-3 Tools unter Linux benötigt. Die eQ-3 Tools liegen nur in 32bit vor, weshalb auf einem x86_64 System (amd64) noch die 32bit Kompatibilitätsbibliotheken ''libc6-i386'' und ''lib32stdc++6'' installiert werden müssen.

Bekannte Probleme: Nachdem die Firmware 1.1.5 über die Software Netfinder geladen wurde, wird das Gateway automatisch neu gestartet. Nach dem Neustart wird im Netfinder eine ältere Version angezeigt (z.B. vorher 1.1.3 nachher 1.1.1). Am Homatic Gateway muss der Netzstecker gezogen und wieder gesteckt werden. Nach dem Neustart wird dann die richtige Version angezeigt.

(Im folgenden "NEQ0218723" durch die eigene Seriennummer des Funk-LAN Gateway ersetzen und "geheimesLGWPasswort" durch das LGW-Passwort. Falls die Verschlüsselung deaktiviert wurde, dann das -k komplett weglassen.

=== Vorbereitung des LAN-Firmwareupdates mit den eQ-3 Tools ===

Installation der Kompatibilitätsbibliotheken (nur auf x86_64/amd64 ohne konfiguriertes Multiarch):
$ sudo apt-get install libc6-i386 lib32stdc++6

Auschecken und Vorbereitung der eQ-3-Tools:
$ git clone https://github.com/eq-3/occu
...
$ cd occu
$ sudo ln -s $(pwd)/firmware /firmware

Auf arm:
$ cd arm-gnueabihf/packages-eQ-3/LinuxBasis/bin

Auf x86 bzw. x86_64:
$ cd X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin (auf X86/X86_64)

Wieder gemeinsam auf allen Plattformen:
$ chmod 755 eq3configcmd

=== Update der LAN-Firmware mit den eQ-3 Tools ===

Um das Update durchzuführen, muss man sich im Verzeichnis ''occu/arm-gnueabihf/packages-eQ-3/LinuxBasis/bin'' bzw. ''occu/X86_32_Debian_Wheezy/packages-eQ-3/LinuxBasis/bin'' befinden.

$ LD_LIBRARY_PATH=../lib:../../RFD/lib ./eq3configcmd update-lgw-firmware -u ../../../../firmware/hm-lgw-o-tw-w-eu_update.eq3 -console -l 1 -s NEQ0218723 -k 'geheimesLGWPasswort'
2016/07/28 09:25:24.264 <Info> LAN Gateway Firmware Update...

2016/07/28 09:25:24.265 <Info> Gateway NEQ0218723
2016/07/28 09:25:26.273 <Info> Gateway type is eQ3-HM-LGW-App
cryptEnabled true2016/07/28 09:25:33.313 <Info> Updating firmware....

2016/07/28 09:25:38.467 <Info> Update performed. Waiting for gateway to get ready.

=== Update der Applikationsfirmware mit FHEM ===

1. Firmware herunterladen
a: Verbinden Sie sich auf ihren Raspberry
ssh pi@ipadresse
b: Wechseln Sie in das Firmware Verzeichnis von FHEM
cd /opt/fhem/FHEM/firmware/
c: Firmware Downloaden
wget https://raw.githubusercontent.com/eq-3/occu/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/coprocessor_update_hm_only.eq3
2. Flashen der neuen Firmware über die Befehlszeile in FHEM
set meinLGW updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update_hm_only.eq3

=== Logbeispiel ===

== Bekannte Probleme ==
Das LGW hat (anders als das UART-Modul) keine eigene ''hmId'' (das Reading ''D-HMIdOriginal'' ist auf FFFFFF gesetzt). Es muss also mit
:<code>attr meinLGW hmId xxxxxx</code>
eine nach den in der [http://fhem.de/commandref.html#hmId commandref] definierten Regeln gewählte Id gesetzt werden.

== Links ==
* {{Link2Forum|Topic=41203|LinkText=Forenthread}} mit Nachfrage zur Unterstützung dieses Geräts in FHEM
* {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}
* [http://www.elv.de/homematic-funk-lan-gateway.html Produktseite] bei ELV
* {{DocLink|elv|/Assets/Produkte/10/1040/104029/Downloads/104029_lan_gateway_um.pdf Bedienungsanleitung}}

[[Kategorie:HomeMatic Components]]
[[Kategorie:Interfaces]]

HM-RC-2-PBU-FM Unterputz-Wandsender

2016-03-02T19:19:18Z

Octo: /* Hinweise zur Hardware-Installation */ Abschnitt hinzugefügt.

{{Infobox Hardware
|Bild=HM-RC-2-PBU-FM.JPG
|Bildbeschreibung=Vorderseite des HM-RC-2-PBU-FM
|HWProtocol=BidCoS ([[HomeMatic]])
|HWType=[[HomeMatic Type Remote|remote]]
|HWCategory=[[:Kategorie:Schalter (Sender)|Schalter (Sender)]]
|HWComm=868,3 MHz
|HWChannels=2
|HWVoltage=230 V
|HWPowerConsumption=0,22 W (Ruhebetrieb)
|HWPoweredBy=Netz
|HWSize=71x71x37 mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}

Der [[HM-RC-2-PBU-FM Unterputz-Wandsender]] ist ein 2-Kanal-Sender zur Unterputz-Montage, der sich in Schalterprogramme einiger Hersteller integrieren lässt. Aus Sicht von Fhem verhält er sich wie eine [[HomeMatic Type Remote|Fernbedienung]] mit zwei Tasten.

== Hinweise zur Hardware-Installation ==

* Zur Integration in ein bestehendes Schalterprogramm bitte den entsprechenden Adapter mit bestellen.
* Der HM-RC-2-PBU-FM besitzt nur Anschlüsse für Phase (L) und Neutralleiter (N). Diese können ''nicht'' durch das Gerät "durchgeschleift" werden, das heißt für weitere Verbraucher muss gegebenenfalls Platz für eine Lüsterklemme oder Ähnliches eingeplant werden. 40mm-tiefe Schalterdosen sind dafür ''sehr'' knapp bemessen.

<gallery>
Datei:HM-RC-2-PBU-FM (Rueckseite).JPG|Rückseite
</gallery>

== Links ==

* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-RC-2-PBU-FM_UM_GE_eQ-3_web.pdf Bedienungsanleitung] (PDF)

[[Kategorie:HomeMatic Components]]
[[Kategorie:Schalter (Sender)]]

Datei:HM-RC-2-PBU-FM (Rueckseite).JPG

2016-03-02T19:00:01Z

Octo: Rückseite des HM-RC-2-PBU-FM Unterputz-Wandsenders Quelle: Eigenes Bild von Benutzer:Octo Lizenz: Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)

Rückseite des [[HM-RC-2-PBU-FM Unterputz-Wandsender]]s
Quelle: Eigenes Bild von [[Benutzer:Octo]]
Lizenz: Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)

HM-RC-2-PBU-FM Unterputz-Wandsender

2016-03-02T18:52:31Z

Octo: Bild in der Infobox eingefügt.

Datei:HM-RC-2-PBU-FM.JPG

2016-03-02T18:51:13Z

Octo: Vorderseite des HM-RC-2-PBU-FM Unterputz-Wandsenders Quelle: Eigenes Bild von Benutzer:Octo Lizenz: Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)

Vorderseite des [[HM-RC-2-PBU-FM Unterputz-Wandsender]]s
Quelle: Eigenes Bild von [[Benutzer:Octo]]
Lizenz: Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)

Virtueller Controller VCCU

2016-02-26T09:44:15Z

Octo: /* Virtuelle Kanäle der VCCU */ Nomenklatur (IO-Entities) von HomeMatic übernommen.

Eine '''Virtuelle CCU''', auch '''VCCU''' genannt, ist eine Zentrale für [[HomeMatic]]-Geräte. Die VCCU tritt beim [[Pairing und Peering|Pairing]] an die Stelle des ''I/O-Devices'' (auch "Schnittstelle" genannt, zum Beispiel [[CUL]] und [[HM-CFG-LAN]]).

HomeMatic-Geräte werden überlicherweise mit einer Zentrale gepaired, um sie zentral verwalten zu können. Der Pairing-Partner ist im einfachsten Fall das I/O-Device ([[CUL]], [[HM-CFG-LAN]], …) selbst. Durch das Pairen der Geräte mit einer virtuellen CCU ergeben sich folgende Vorteile:

* Die Verwendung mehrerer I/O-Devices wird möglich. Das sorgt für Redundanz (Ausfallsicherheit) und/oder Reichweiten-Vergrößerung.
* Der Tausch eines I/O-Devices ist transparent für gepairte Geräte.
* Die VCCU stellt virtuelle Kanälen zur Verfügung, mit denen HomeMatic-Geräte [[Homematic Peering Beispiele|gepeert]] werden können.
* "Geordnete" Termination von Nachrichten.

Der einzige Nachteil einer VCCU gegenüber dem direkten Pairing mit dem I/O-Device ist ein Mehraufwand bei der initialen Konfiguration vom Fhem.

== Mehrere VCCUs in einer Installation==

Theoretisch erlaubt Fhem die parallele Nutzung mehrer VCCUs, praktisch ergeben sich dadurch jedoch keine Vorteile gegenüber einer einzigen VCCU. Insbesondere kann eine VCCU verschiedene I/O-Devices bedienen, zum Beispiel einen [[CUL]] ''und'' ein [[HM-CFG-LAN]].

Jede VCCUs muss eine eindeutige ''HomeMatic-ID'' haben, mit der HomeMatic-Geräte gepaired werden. Folglich kann jedes HomeMatic-Gerät nur mit ''einer'' VCCU gepaired werden.

{{Todo|Können mehrere VCCU das selbe I/O-Device nutzen?}}
{{Todo|Können HomeMatic-Geräte, die mit unterschiedlichen VCCUs gepaired wurden, untereinander gepeert werden?}}

== Definition der VCCU==
=== hmId wählen ===
Eine VCCU benötigt wie alle HM Devices eine Adresse, mit der sie angesprochen wird. Bei Schnittstellen und Zentralen ist dies eine ''hmId''. Da die VCCU eine (virtuelle) Zentrale ist, muss sie auch mit einer ''hmId'' versehen werden. Dies geschieht per define analog zur Anlage einer physischen Schnittstelle (siehe weiter unten)

Eine VCCU gibt die ''hmId'' an die ihr zugewiesenen IOs (Funkschnittstellen) weiter.

Definiert man eine VCCU nachdem IOs (CUL oder HMLAN) für Homematic angelegt sind, sollte die ''hmId'' der bereits vorhandene Funkschnittstelle verwenden, hierdurch kann man sich das Neupairen der HM Devices ersparen.

Allerdings muss das attr IOgrp eines vor Anlage der VCCU gepairten Gerätes auf die VCCU angelegt/geändert werden., z.B. so
attr <device> IOgrp VCCU
(Sie weiter unten ein Tipp, wie dies leicht nachträglich erledigt werden kann)

Mit der Anlage einer VCCU hat das eventuell angelegte attribut IODev eines HM_Devices keine Funktion mehr. Vielmehr setzt die VCCU das IODev automatisch je nach Verfügbarkeit und Funklage. Es ist jedoch nicht erforderlich angelegte IODev Attribute zu entfernen.

=== Einrichten ===
define VCCU CUL_HM <hmId>
attr vccu model CCU-FHEM
attr vccu IOList <io1>[,<io2>,...]

Das Attribut IOList dient dazu festzulegen, welche physikalischen Schnittstellen ("IO") von der VCCU genutzt werden, dies sind in der Regel alle HM-fähigen Schnittstellen einer Installtion.
IOList beinhaltet die Komma-getrennte Liste der IOs, so wie sie in FHEM angelegt sind.

Es seien z.b. in FHEM bereits die beiden Schnittstellen HMLAN und CULHM angelegt:

define HMLAN0 HMLAN 192.168.168.2:1000
attr HMLAN0 hmId 123456
attr HMLAN0 hmLanQlen 1_min
attr HMLAN0 icon hm_lan

define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 hmId 123456
attr CUL0 icon cul_cul
attr CUL0 rfmode HomeMatic

Dann kann zusätzlich die VCCU mit der selben hmId angelgt werden und die beiden physikalischen Schnittstellen ihr zugewiesen:

define VCCU CUL_HM 123456
attr VCCU IOList CUL0,HMLAN0
attr VCCU model CCU-FHEM
attr VCCU subType virtual
attr VCCU webCmd virtual:update

Wird die VCCU mit einer von vorhandene Schnittstellen abweichenden ''hmId'' angelegt, so wird die ''hmId'' der ihr zugewiesenen Schnittstelle(n) automatische angepasst. Dies hat in der Regel zur Folge, das HM Devices neu gepairt werden müssen.

=== Auswirkungen auf IOs / Funkschnittstellen===
Sind IOs durch das Attribut IOList einer VCCU zugewiesen, werden die notwendigen Attribute im IO gesetzt, so wird die hmId durch die VCCU kontrolliert. Ein HMLAN/USB ist etwas enger verbunden als CUL IOs. Beim HMLAN kann die HMId nicht mehr geändert werden. Die kontrollierende VCCU wird in den Internals ''owner'' und ''owner_CCU'' des IO automatisch eingetragen. 

=== Pairen von HM Devices===
HM Devices sollten vorzugsweise direkt mit der VCCU gepairt werden, hierzu werden die normalen Befehle
hmPairForSec
hmPairSerial
verwendet. Es ist im übrigen weiter möglich (aber nicht sinnvoll / empfehlenswert) auch nach Anlage einer VCCU HM Devices mit diesen Kommandos direkt an ein IO zu pairen, d.h. diese Kommandos haben auch nach Anlage einer VCCU noch eine Funktion an der physikalischen Schnittstelle (im Gegensatz z.b. zum attr IODev)

== Dynamisches IO ==
FHEM sendet Befehle an an ein HM Device in der Regel immer über das gleiche IO-Device. Fällt es aus wird nicht mehr gesendet, selbst wenn ein zweites IO verfügbar wäre. Ausserdem gibt es ''bewegliche'' Fernbedienungen welche ihre Verbindung zu einem IO verlieren, aber über ein andere IO gut empfangen werden könnten.

Die VCCU adressiert beide Probleme:

Durch das Attibut IOgrp
attr <dev> IOgrp <vccu>:<preferredIO>
kann bestimmt werden, wie die VCCU die IO Devices genau nutzt. Insbesondere ist optional ein Preferd IO Device definierbar: bei stationären Devices - der häufigste Fall - sollte man das beste IO auswählen und als Default nutzen. Ein weiteres IO wird bei Ausfall des Ersten genutzt.

Das preferredIO ist jedoch optional und kann insbesondere bei beweglichen HM Devices (Fernbedienungen) weggelassen werden.

Beispiele:

Durch
attr <device> IOgrp VCCU:HMLAN1
wird die VCCU zuerst versuchen Befehle an <device> mit HMLAN1 zu senden, falls seine condition=ok.
Falls nicht wird (einer) der verbleibende(n) IOs verwendet, hier der mit dem besten RSSI.

Durch
attr <device> IOgrp VCCU
wird durch die VCCU der IO mit dem besten RSSI zum Device gewählt, falls seine condition=ok ist.

Da dies für jedes angelegte HM Device einzeln definiert werden kann/muss, kann so auch eine Verteilung des Funkverkehrs vorgenommen werden, z.b. um die 1%-Regel (HighLoad) zu berücksichtigen, dennoch bleibt die Redunanz bei Ausfall einer Schnittstelle erhalten.

=== Bemerkungen ===
Es wird empfohlen, das Attribut IOgrp in allen Devices zu setzen. Kanäle senden nicht selbständig, haben daher kein Attribut IOgrp. 
Das Attribut '''IODev''' wird automatisch gesetzt, Usereinträge haben keine Funktion. Es zeigt jedoch indirekt das letzte genutzte output-device. 
Die besprochene Steuerung betrifft das '''Senden'''. Empfangen und verarbeitet werden Nachrichten immer von allen verfügbaren Quellen.

=== Setzen der IOgrp auf (fast) allen Devices mit einem einzigen Befehl ===
Hat man eine bestehende Fhem-Installation mit mehreren/vielen Devices, kann das Setzen der ''IOgrp'' aufwändig sein. Erleichtern kann man dies mittels des Befehls:

attr TYPE=CUL_HM:FILTER=DEF=...... IOgrp vccu
save

Dieser Befehl (in der Fhem-Eingabezeile eingeben und mit <Return> bestätigen).

== Virtuelle Kanäle der VCCU==
: ''→ Siehe auch: [[HomeMatic#IO_Entities]]''

Eine VCCU kann bis zu 50 virtuelle Kanäle, sogenannte '''IO-Entities''', bedienen. Diese können als Sender/Sensoren oder Empfänger genutzt werden. Man kann diese Kanäle mit einem realen Kanal peeren und Aktionen triggern.

Man peert beispielsweise einen Dimmer mit einer IO-Entity um "Tastendrücke" in der Zentrale auslösen zu können. Sowohl kurze (short) als auch lange (long) Tastendrücke können so an den Dimmer gesendet werden.
Auch mehrere Aktoren können mit einer IO-Entity gepeert werden, beispielsweise um alle Lichter der Gruppe mit einem "press" gleichzeitig zu schalten.

=== Anlegen ===
set vccu virtual <AnzahlButton>
z.B.
set vccu virtual 10
legt 10 Kanäle für die VCCU an, die Kanäle 1-10. Evtl. vorhandene Kanäle größer 10 werden gelöscht.

=== Kommandos ===
: ''→ Siehe auch: [http://fhem.de/commandref.html#CUL_HMvirtual CommandRef]''

Verfügbare Kommandos auflisten:

get vccu_Btn1 cmdList

Insbesondere gibt es:

set vccu_Btn1 press short
set vccu_Btn1 press long
set vccu_Btn1 postEvent <condition>

[[Kategorie:HomeMatic Components]]
[[Kategorie:HOWTOS]]

HomeMatic

2016-02-26T08:57:31Z

Octo: /* IO Entities */ Abschnitt überarbeitet.

'''Achtung, diese Seite wird derzeit im Sinne einer klareren Beschreibung überarbeitet'''

'''HomeMatic''' (HM) ist ein System des Herstellers eQ-3 zur Steuerung und Überwachung von zahlreichen Aufgaben und Situationen im Haus. Erhältlich sind sowohl Geräte mit Funkschnittstelle 868.3 MHz, als auch (seit 2008) drahtgebundene Geräte mit RS485-Schnittstelle. Im Programm sind Geräte zur Heizungs- und Lichtsteuerung, Temperatur-, Luftfeuchte- und Feuchtemessung, Zutrittskontrolle, als Wasser-, Brand- und Bewegungsmelder sowie als Wetterstation, ferner gibt es noch Fernbedienungen und Statusdisplays.

=Grundlagen=
HomeMatic-Geräte können untereinander ''gepeert'' werden (engl. ''peers'' = "Gleiche"), im einfachsten Fall kann deshalb bereits ein Sensor (z.B. ein Temperatursensor) mit einem Aktor (z.B. einem Heizkörperregler) verbunden werden und diesen steuern. Hierbei können mehrere Sensoren und Aktoren untereinander verbunden werden, die Vorstellung der "Gleichen" ist also zutreffend.

HomeMatic-Geräte können auch mit einer Zentrale verbunden (''gepairt'') werden, die dann einen Teil der Steuerungslogik übernehmen kann. Bei dieser Verbindung spricht man vom ''Pairing'', weil jedes HomeMatic-Gerät nur mit einer Zentrale verbunden werden kann. Gepairte Geräte können auch nicht mehr direkt gepeert werden - dies geht dann nur noch unter Beteiligung der Zentrale.

==Voraussetzungen==
Für den Betrieb ohne Zentrale sind keine weiteren Voraussetzungen zu erfüllen.
===Zentrale von eQ-3===
Vom Hersteller eQ-3 selbst wird eine Zentrale (derzeit aktuell CCU-2) und Windows-Software zur Steuerung und Auswertung der HM-Komponenten angeboten.

===Fhem als Zentrale===
Zur Kommunikation mit HomeMatic benötigt Fhem eine Schnittstelle, die im 868,3-MHz-Band funken kann. Infrage kommen:
* [[CUL]] (USB)
* [[HM-CFG-USB USB Konfigurations-Adapter|HM-CFG-USB]] (USB)
* [[CUNO]] (LAN)
* [[HM-CFG-LAN]] (oft auch "HMLAN" genannt; LAN)

Für ''HomeMatic Wired'' benötigt man eine RS485-Schnittstelle. Verfügbar sind:
* [[HomeMatic Wired RS485 LAN Gateway|HMW-LGW-O-DR-GS-EU]] (LAN)

===Migration von CCU-2 zu Fhem===
Der Umzug einer bestehenden HomeMatic Installation von einer HomeMatic CCU-2 auf Fhem ist möglich. Um die an die Zentrale angebundenen Devices in Fhem ohne größere Umkonfiguration weiter verwenden zu können, muß die HM-Id und, falls verwendet, die AES-Schlüssel der CCU-2 in Fhem übernommen werden. Um diese Daten aus der CCU-2 auszulesen, wird eine SSH-Verbindung (zum Beispiel mit PuTTY unter Windows) aufgebaut. Die HM-Id befindet sich in der Datei <code>/usr/local/etc/config/rfd/BidCoS-RF.dev</code> in einer Zeile wie dieser:

<device serial="BidCoS-RF" type="HM-RCV-50" address="0xABCDEF" aes_key_index="0" firmware_version="2.11.9" bidcos_interface="KEQ1234567" roaming="true">

Die HM-Id ist der Wert des <code>address</code>-Attributs. Die dort angegebene hexadezimale Zahl (hier <code>0xABCDEF</code>) ist die HM-Id und wird in Fhem ohne das "0x"-Präfix verwendet.

Falls AES-Schlüssel eingerichtet sind, sind diese in der Datei <code>/etc/config_templates/crypttool.cfg</code> zu finden und können 1:1 als Schlüssel im [[HM-CFG-LAN]] in der gleichen Reihenfolge hinterlegt werden.
{{Todo|Wie werden AES-Schlüssel in HM-CFG-LAN "hinterlegt"?}}

==Prototokoll==
HM-Geräte kommunizieren untereinander mit dem Protokoll ''Bidirectional Communication Standard'', abgekürzt ''BidCoS''. Jedes HM-Gerät enthält also Sender und Empfänger, das ist einer der wesentlichen Unterschiede z.B. zum FS20-System.
*Jedes HM-Gerät meldet beim Empfang eines Steuerbefehls durch einen Peer an diesen eine Bestätigung „ACK“ zurück. Erkennt das HM-Gerät den Befehl nicht, sendet es ein ''NACK''. Kommt vom HM-Gerät keine Rückmeldung innerhalb einer festgelegten Zeit, meldet der steuernde Peer ein ''MISSING ACK''.
*Jedes HM-Gerät meldet ferner seinen Status nach dem Erhalt eines Steuerbefehls zurück - so kann auch ein lokal am Gerät erfolgender Tastendruck in beim steuernden Peer oder in der Zentrale registriert werden.

Das Protokoll ''BidCoS'' wurde zum großen Teil entschlüsselt, seine offen verfügbare Variante heißt ''AskSin''. Unter Verwendung der AskSin-Library entstehen derzeit erste Geräte, die in das HomeMatic-System eingebunden werden können. Zur Unterscheidung zwischen HM und den neuen Geräten werden diese als [[HomeBrew]] (HB) bezeichnet.

=Betrieb mit Fhem=
Die Kenntnis des Dokumentes [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Einsteigerdokuments "Heimautomatisierung mit Fhem"] wird vorausgesetzt. Im Anhang dieses Dokuments findet sich ein Teil über den Aufbau und die Funktion von HM-Geräten.

=== Einrichten des IO-Devices (Funkschnittstelle)===
Zuerst muss ein IO-Device eingerichtet werden, um mit HM Geräten kommunizieren zu können. Siehe hierzu [[HMLAN Konfigurator]].

=== Struktur von HM Geräten===
HM Geräte sind logisch in ein '''Device''' und ein oder mehrere '''Kanäle''' gegliedert. Jedes Device und jeder Kanal (Channel) wird in einer Entity in FHEM repräsentiert. 
Ausnahme: Sollte ein Gerät nur einen Kanal haben wird dieser in einer Entity mit dem Device eingerichtet.
====Device====
Das Device ist für die Kommunikation verantwortlich. Es sortiert und ordnet die zu sendenden und empfangenden Nachrichten.
Man kann prüfen, ob alle Nachrichten übertragen sind, oder ob es Probleme gegeben hat. Die Variablen "prot..." geben Auskunft darüber. Siehe auch [[Homematic_HMInfo#protoEvents]].
Zu beachten sind zudem die Übertragungsmodi. Nicht alle Devices sind ständig auf Empfang - FHEM muss berücksichtigen, wann gesendet werden kann. In '''protState''' kann man sehen, ob Kommandos auf Verarbeitung warten, also pending sind.
Einige Devices unterstützen mehrere Modi parallel.
===== Config=====
Wird von allen Devices unterstützt, auch wenn es bei Always kaum genutzt werden kann.
Man setzt die Kommandos in FHEM ab und diese warten in der Kommando-queue.
Wenn die config-funktion am Device ausgelöst wird (Anlerntaste drücken) sendet FHEM die wartenden Nachrichten der Reihe nach.
Config wird bei allen Devices zum pairen genutzt.
===== Always=====
Trifft man meist bei netzbetriebenen Geräten an, da diese kein Problem mit dem Energieverbrauch haben. Man kann immer mit dem Device kommunizieren.
===== Burst=====
Nur der Empfänger des Device ist aktiv. Über eine Aufweck-sequenz kann das Device geweckt werden. Man kann quasi immer mit dem Device kommunizieren. Nachteil des Aufwecken ist zum Einen, dass immer ALLE Devices im Funknetz geweckt werden, was deren Batterie belastet. Zum Andere ist die Aufweck-sequenz funktechnisch aufwändig und belastet die maximal erlaubte Sendekapazität des IO device je Stunde.
===== ConditionalBurst=====
Bei einigen Devices kann man den Burst mode zuschalten. Dies sind Devices, die zusätzlich über andere modi verfügen, so z.B. wakeup. Schaltet man burst-empfang ein kann man immer und sofort mit dem Device reden, es kostet aber etwas mehr Batterie. Siehe hierzu Attribut '''burstAccess''', Kommando '''burstXmit''' und Register '''burstRx'''
===== LazyConfig=====
Kommandos in der Queue werden bearbeitet, wenn eine Aktion vom Device ausgeht. So zum Beispiel ein Tastendruck bei einer Fernbedienung.
Dieser mode wird von CUL/CUNO nicht unterstützt. FHEM ignoriert diese Option automatisch und wartet i.a. auf ein Config.

===== Wakeup=====
Die Devices wachen regelmäßig auf und senden Daten, z.B. Temperatursensoren. Zu diesem Zeitpunkt kann FHEM die Nachrichten übertragen. Die Aufwachperiode ist unterschiedlich von 3 min bis zu 24h.

====Kanal====
Ein Kanal ist die Funktionseinheit des Geräts. Hier ist die Funktion des Sensors oder Aktors realisiert.
=== Variablen===
Wie alle FHEM Entities werden 4 Gruppen von Daten unterstützt:
* Internals: Im Web-Interface sichtbare Variablen, die allgemeine Informationen über den Zustand enthalten.
* Readings: Im Web-Interface sichtbare Variablen. Sie werden aus von Entites empfangenen Nachrichten generiert. Man kann mit notify Trigger auf die setzen. Readings werden im Statefile bei save und gewissen neustarts gesichert und beim Booten eingelesen. Readings haben einen Zeitstempel.
* Attribute: Im Web-Interface sichtbare Variablen. Über sie kann man die Eigenschaften der Entity in FHEM steuern.
* Helper: Im Web-Interface nicht sichtbare Variablen. Man kann sie mit dem Kommando 'list' sehen. Es sind hilfsvariablen, die für den User keine Bedeutung haben sollen.
==== Internals====
Viele Variablen sind nicht HM spezifisch - deren Bedeutung muss in allgemeinen Teil nachgelesen werden. Spezifische Variablen sind:
*Device
** channel_xx: Liste der Kanäle, die dem Device zugeordnet sind.
** prot... : Gruppe von Daten zum Zustand des [[HomeMatic#Protokol|Protokolls]], also der Kommunikation mit dem Device.
** rssi...: Gruppe von Daten die den [[HomeMatic#Rssi|Empfangspegel]] des Device bei IOs, Peers und Repeatern darstellt.

*Kanäle
** device: Das übergeordnete Device
** chanNo: Die Kanalnummer
** peerList: Ist die Entity mit einem anderen gepeert ist steht hier der Name der Peers. Siehe auch attribut peerIDs und Reading peerList. Diese Variable ist mit dem peer verlinkt, man kann darauf 'clicken'.

==== Readings====
Readings für HM Entites unterliegenden allgemeinen FHEM Regeln.
Generell gilt, dass ein Wert, der von FHEM gesetzt wurde mit dem prefix '''"set_"''' versehen wird. Wenn der Zustand bestätigt ist wird das set_ entfernt. Sollte man also ein Reading mit diesem prefix haben, das sich nicht selbst entfernt sollt man unbedingt den Zustand kontrollieren. 
So ist nach einem "set Licht on" der Zustand des Licht erst einemal "set_on". Mit der Antwort des Device wird es dann auf "on" gesetzt. 
Register machen eine Ausnahme:
=====Register=====
Register sind Konfigurationsparameter, die '''im Device flash''' gespeichert werden. Daten, die Registern zureordnet sind beginnen mit "R-". Sollte das Register einem peer zugeordnet sein kommt dieser danach. Der Namen ist also
'''R-<peer>-<registerName>''' 
Der Zugriff ist indirekt, geht also nur über Methoden und Kommandos. Man kann die Konfiguration (Register und peers) mit '''getConfig''' aus dem Device lesen und in FHEM dargestellen. FHEM bemüht sich, die angezeigten Register aktuell zu halten - der User muss aber ein gewisse Vorsicht im Umgang damit walten lassen. Register können mit '''regSet''' gesetzt werden. Ob die gelesenen Register komplett sind prüft [[Homematic_HMInfo#Integrit.C3.A4tspr.C3.BCfungen|configCheck]].
Da einige Entities viele Register haben kann man mit dem Attribut '''expert''' die Sichtbarkeit steuern. 
siehe auch [[Homematic_HMInfo#Infos|register]]. 
Von einigen Devices sind Register schwer zu lesen, z.B. config devices. Man kann die Register-Readings [[Homematic_HMInfo#archConfig|archivieren]] und beim reboot wieder [[Homematic_HMInfo#archConfig|laden]].

==== Attribute====
Attribute sind i.a. Parameter, die das Verhalten der Entity steuern. Sie werden mit '''save''' in fhem.cfg oder einem seiner subfiles gespeichert. Nach einer Änderung sollte der User ein "save" machen, sonst sind diese nach einem Reboot verloren. 
Hier werden nur '''HM spezifische Attribute''' besprochen. 
Attribute, die das System '''automatisch''' anlegt. Sollten diese nicht mehr stimmen kann der User anlernen am Device drücken und sie werden wieder hergestellt. Der User sollte sie '''nicht ändern'''.
* model
* subType
* peerIDs: HMIds der peers. Wird gelegentlich verschoben!
* serialNr: auslaufend - durch Reading D-serianNr ersetzt
* firmware: auslaufend - durch Reading D-firmware ersetzt

Attribute für HM Entities, die der User steuern kann
* webCmd: FHEM setzt ggf. einen Default, der User kann dies anpassen
* expert: schaltet mehr oder weniger Readings sichtbar - dient der Übersichtlichkeit des Web-Interface.
* autoReadReg: steuert das automatische Lesen der Konfiguration - ggf. zeitverzögert um Resourcen zu schonen. Es wird Level 5 empfohlen

Attribute für HM Entities am Device, die der User steuern kann
* msgRepeat: kann man im Device einstellen. Es legt fest wir oft eine Nachricht wiederholt werden soll, falls sie nicht empfangen wird. Beachte, dass unabhängig davon ein HMLAN/USB immer 3-mal probiert zu senden. Insbesondere bei Burst Devices sollte man einen niedrigen level einstellen.
* IODev: Sollte man auf das IO device setzen, über das zu diesem Device gesendet werden soll. Es wird i.a. beim Pairen gesetzt.

Empfohlene Attribute außerhalb von HM
* event-on-change-reading .*

===Kommandos===
====Allgemein====
* get <name> cmdList ''# zeigt alle Kommandos mit Parametern für diese Entity an''
* clear [readings|register|rssi|msgEvents] ''# löschen von Readings oder Zählern''
====Register kommandos====
* set <name> getConfig ''# liest alle Peers und Register. Auf ein Device angewendet werden ALLE channels auch gelesen''
* set <name> regSet [prep|exec] <regName> <value> ... [<peerChannel>]'' #schreiben eines Registerwerts. Das Kommando landet im Kommandstack''
* set <name> regbulk ...''# kommando zum setzen von rohdaten und ganzen Registerlisten. Ausser zum re-configurieren eines ganzen Device eher nicht für den User zu gebrauchen''

* set <name> sign [on|off ''# setzt das Register um AES einzuschalten. Man sollte sich über AES '''vorher''' einlesen!!''

* get <name> regList ''# zeigt alle Register, die diese Entity '''unterstützt''' - incl Beschreibung und Wertebereich. Als Anfänger sollte man einmal hinsehen!''
* get <name> reg all ''# zeigt alle Register, die diese Entity '''hat''' und den aktuellen Wert''
===Kommunikation===
Die Kommunikation zwischen Device und der Zentrale folgt einem Protokoll. Für die meisten Nachrichten erwartet der Sender eine Empfangsbestätigung. FHEM beachtet das Protokoll und implementiert es entsprechend der Fähigkeiten des IO device. 
Grundsätzlich kann jedes Device an jedes andere Nachrichten senden. Damit dies auch einen erfolg hat, müssen die Kanäle gepeert werden. 
Um FHEM zu erlauben, Nachrichten an das Device zu richten muss FHEM gepairt werden. 
Das Senden der Nachrichten macht IMMER das Device - ein Kanal selbst kann nicht wirklich senden.
====Protokoll====
Da für das Senden das Device verantwortlich ist sind hier die entsprechenden Informationen zu finden. Zu Beachten sind die [[HomeMatic#Device|Übertragungsmodi]], die ein Device unterstützt. Die Internals "prot..." enthalten alle notwendigen Daten.
* protState: Der Zustand der Protokollmaschine
** CMDs_done: alle Nachrichten übertragen, keine Fehler in diesem Durchgang aufgetreten
** CMDs_done_Error:xx : es hat xx Fehler bei der letzten Übertragung gegeben.
** CMDs_pending: Nachrichten warten auf das Senden
** CMDs_processing... : die Nachrichtenübertragung ist im Gange
** Info_Cleared: die Protokoll Statistik wurde rückgesetzt
* protCmdPend: Anzahl der Nachrichten, die auf das Senden warten
* protCmdDel: Anzahl gelöschter Nachrichten aufgrund von Fehlern
* protCmdNack: Anzahl der negativen Acknowledges
* protCmdResnd: Anzahl der Wiederholungen - die Nachrichten wurden nicht gelöscht.
* protCmdResndFail: Anzahl der fehlgeschlagenen Wiederholungen - die Nachrichten wurden gelöscht.
* protCmdIOerr: Anzahl der IO Fehler - Übertragung war nicht Möglich, weil das IO Device Probleme hatte. Der Grund sollte im IO Device nachgesehen werden.
* protCmdIOdly: Anzahl der Verzögerungen aufgrund von IO Problemen
* protCmdTimedOn: Anzahl der Nachrichten, wenn ein Timer im Device genutzt wird - z.B. durch on-for-timer
* protCmdRcv: Anzahl empfangene Nachrichten
* protCmdSnd: Anzahl gesendete Nachrichten
* protCmdErrIoId_...: Anzahl der Sendeversuche zum Device von einer anderen Zentrale
* protCmdErrIoAttack: Anzahl der Sendeversuche zum Device die nicht von FHEM kam- es könnte ein Versuch sein, das System zu hacken. Dies wird auch im Reading '''sabotageAttack''' ausgegeben und man kann ein notify darauf ansetzen.

* protCmdEvt_AESCom: Anzahl der AES Nachrichten von Device
* protCmdEvt_AESKey: Benutzter AES key

Die Zähler können mit '''set <device> clear msgEvents''' rückgesetzt werden. Dies kann vor Konfigurationsänderungen Sinn machen, um Probleme besser erkennen zu können. 
Eine Übersicht kann man mit HMInfo [[Homematic_HMInfo#protoEvents|protoEvents]] erhalten. Auch das Löschen aller Zähler ist von HMInfo aus möglich.

====Rssi====
Zeigt den Empfangspegel, den ein Device von einem Anderen misst. Die Variablen sind in Internals abgelegt. Angegeben werden minimale und maximale Wert. Außerdem wird der Durchschnitt und die Anzahl der Nachrichten ausgewertet. 
HM liefert Empfangspegel am IO Device (FHEM standard) aber auch den Empfangspegel am Device selbst. Ebenfalls ausgewertet werden Pegel, die beim Senden zwischen Peers erreicht werden. 
Die Zähler können mit '''set <device> clear rssi''' rückgesetzt werden. 
Eine Übersicht erhält man mit HMInfo [[Homematic_HMInfo#RSSI|Rssi]]. Das Löschen der Zähler aller HM devices ist von HMInfo aus möglich. 

Man kann RSSI kontinuierlich aufzeichnen, wenn das Attribut '''rssiLog''' im Device gesetzt ist. Es wird ein Reading rssi_<name> erzeugt. Das generelle setzen dieses Attributs wird aus Performance-gründen nicht empfohlen.

== Pairen und Peeren ==
: ''→ Siehe auch: [[Pairing und Peering]]''

HomeMatic-Geräte können mit einer Zentrale (Fhem) ''gepairt'' und mit anderen HM-Geräten ''gepeert'' werden.

=== Pairen ===
: ''→ Hauptartikel: [[HomeMatic Devices pairen]]''

HM-Geräte können mit und ohne Zentrale betrieben werden. Fhem geht davon aus, dass Geräte immer von einer Zentrale aus gesteuert werden können. Dazu muss das Gerät mit der Zentrale ''gepairt'' werden.

=== Peeren ===
: ''→ Siehe auch: [[Homematic Peering Beispiele]]

Um es Geräten zu ermöglichen auch ohne Zentrale zu interagieren (zum Beispiel wenn die Zentrale einen Defekt hat), können HM-Geräte untereinander ''gepeert'' werden.
Dazu wird ein Sensor-Kanal mit einem Aktor-Kanal verknüpft.

== HMInfo ==
: ''→ Siehe auch: [[Homematic HMInfo]]''

Bei der Betreuung einer HomeMatic-Installation ist das Modul [[Homematic_HMInfo|HMInfo]] sehr hilfreich. Es stellt eine Übersicht der HomeMatic-Komponenten zur Verfügung, kann die Konfiguration prüfen und Alarmierungen gesammelt auswerten.

== Besondere Entites ==

=== Virtuelle Entities ===
Virtuelle Entities sind nicht reale HM Devices und Kanäle. Man kann sie als Sender und Empfänger nutzen, auch im Zusammenhang mit Rauchmeldern oder zur Steuerung von Heizungsventilen. Die spezifischen Anwendungen sind im entsprechenden Kapitel nachzulesen. 
Angelegt wird das Device, dann wird per Kommando eine Anzahl Kanäle angelegt.
define <virtDev> CUL_HM 112233
set <virtDev> virtual 10
jetzt hat man ein virtuelles Device mit 10 Kanälen angelegt.
Die die gültigen Kommandos kann man wie immer mit '''get <entity> cmdList''' erfahren. 
Auch einem Virtuellen Device sollte man das '''Attribut IODev setzen '''.
=== IO Entities ===
: ''→ Siehe auch: [[Virtueller Controller VCCU#Virtuelle Kanäle der VCCU]]

'''IO-Entities''' sind virtuelle Kanäle der Zentrale, mit denen andere HomeMatic-Geräte gepeert werden können. Diese Kanäle sind einem ''IO-Device'' zugeordnet – im Unterschied zu ''virtuellen Entities'' gibt es kein virtuelles Homematic-Gerät welches die Kanäle beherbergt.

Jedem IO-Device können bis zu 50 Kanäle zugewiesen werden. Wenn mehrere IO-Devices die gleiche HMId nutzen, zum Beispiel wenn ein [[Virtueller Controller VCCU|virtueller Controller]] verwendet wird, teilen sich diese IO-Devices die Kanäle.

'''Anlegen:'''

# IO-Device definieren
define <IO-Device> CUL_HM c0ffee
attr <IO-Device> model CCU-FHEM

# 4 IO-Entities definieren
set <IO-Device> virtual 4

Aktuell werden IO-Entities in Fhem nicht dargestellt.

=== Action Detector===
Einige Devices der HM-Geräteserie senden periodisch Nachrichten. Manche alle 3 Minuten, andere alle 3 Tage. Wenn so eine Zeit für einen Device spezifiziert ist wird diese automatisch vom ActionDetector überwacht. 
Meist sind dies batteriebetriebene Geräte. Sollte aus irgendwelchen Gründen der Batteriealarm übersehen werden und das Gerät keine Nachricht mehr senden wird es auf Dead gesetzt.
Die Kontrollinstanz ist ein Pseudo-Gerät "ActionDetector" mit der HMId "000000"

* attribut
** actCycle: gibt an, in welchen Abständen sich das Device melden muss
** actStatus: gibt den Zustand an
*** alive: Device hat sich in der erwarteten Zeit min einmal gemeldet
*** dead: Device hat sich in der erwarteten Zeit nicht gemeldet
*** unknown: Device hat sich nicht gemeldet, es ist aber seit dem letzten reboot die Zykluszeit noch nicht abgelaufen.

* readings
** Activity: entsprechend dem actStatus.

* get
** listDevice: Gibt alle Objekte zurück
** listDevice notActive: Gibt alle Objekte zurück die nicht "alive" sind
** listDevice alive: Gibt alle Objekte zurück die "alive" sind
** listDevice unknown: Gibt alle Objekte zurück die "unknown" sind
** listDevice dead: Gibt alle Objekte zurück die "dead" sind

Durch das Setzen des Attributs im HM device wird der ActionDetector automatisch definiert - nach einem save steht er auch in der fhem.cfg.
Alternativ ist auch eine manuelle Definition möglich und sollte in etwa so aussehen:

define ActionDetector CUL_HM 000000
attr ActionDetector actCycle 30
attr ActionDetector event-on-change-reading .*
attr ActionDetector model ActionDetector

Die HMId "000000" darf nicht geändert werden.

In der Entity actionDetector kann man die Infos gesammelt einsehen.
Der User kann durch das Setzen des Attributs actCycle jedes Device in diese Liste aufnehmen. Es wird dann geprüft, ob sich das Device in dieser Zeit auch meldet. Der User muss dies aber selbst sicherstellen.

== Tipps / HowTos / Beispiele ==

* [[HomeMatic Devices pairen|HM Devices pairen]] zum '''Pairen''' der Geräte untereinander.
* [[CUL]] (also gleichzeitig)?
* [[Slider für HM-Rolladensteuerung anzeigen]]
* Für den "Fall der Fälle": Erstellen Sie eine Liste aller HM-Geräte mit den Installationsorten, HM-Namen, Fhem-Namen '''und''' den Geräte-IDs. Falls Sie sich ihr Fhem einmal zerschießen, wird diese Liste sehr hilfreich sein. Zur Abwicklung von Gewährleistungsansprüchen sind Daten über Kaufdatum und Lieferant (bei größeren Installationen mit Zukauf in zeitlichen Abständen) ebenfalls angebracht.

== Probleme ==

=== Messages Sniffen ===
Um Probleme besser nachvollziehen zu können, kann man [[Homematic_Nachrichten_sniffen|Nachrichten mitsniffen]]

=== Daten können empfangen werden, Befehle werden nicht übertragen ===

Das kann mehrere Ursachen haben:
* Pairing nicht abgeschlossen (bei den ''Readings'' "PairedTo" bzw. "R-pairCentral" steht der Wert '''set_'''0x1A2B3C). Das Pairing ist erst dann erfolgreich abgeschlossen, wenn das '''set_''' fehlt, also nur noch (beispielhaft) "0x1A2B3C" steht. Siehe [[HomeMatic_Devices_pairen]]
* Sender (CUL/HM-LAN) und Empfänger (HM-Device) stehen zu nah (RSSI-Werte bei ~ "-17") beieinander
* Sender (CUL/HM-LAN) und Empfänger (HM-Device) stehen zu weit (RSSI-Werte bei unter ~ "-80") voneinander entfernt
* ...

=== Notifys und anderes funktionieren nach einem Fhem-Neustart nicht mehr oder nicht mehr zeitnah ===

Obwohl HomeMatic wegen der höhren Datenübertragungsrate wesentlich weniger von der [[1% Regel]] betroffen ist als z.b. FS20 oder FHT, so kann es dennoch zu Funkkontingentüberschreitungen kommen.

Insbesondere ist bei FHEM Versionen ab Oktober 2013 das Attribut ''autoReadReg'' auf "4_reqStatus" gesetzt. Damit wird für jedes HM-Device mit diesem so gesetzten Attribut beim Fhem-Start ein ''getConfig'' durchgeführt, was viel Funkverkehr erfordert.

Je nach Anzahl der Geräte kann dazu führen, dass insgesamt zu viel Funklast erzeugt wird, im Logfile erscheint dann eine Meldung wie:

2013.10.03 13:41:18 2: HMLAN_Parse: HMLAN1 new condition ERROR-Overload

Ab diesem Moment werden eben auch keine anderen Befehle mehr an weitere HM-Geräte geschickt, da das Funkkontigent aufgebraucht ist. Erst nach einer Stunde kann erneut gesendet werden. Als '''Notbehelf''' kann die Funkschnittstelle resetted oder ([[HMLAN Konfigurator]]) kurz stromlos gemacht werden. Dann wird der Zähler wieder auf Null gesetzt.

Alternativ können so viele HM-Geräte wie möglich auf ''autoReadReg 0_off'' gesetzt werden.

Siehe auch: [[1% Regel]]

=== Spannungsversorgung ===
Die Batterielebensdauer der HomaMatic Komponenten ist durchwachsen. Besonders die mitgelieferten Batterien sind mitunter schon nach wenigen Wochen leer, trotzdem werden öfters keine ''battery low'' Meldung erzeugt. Bei Störung des Funkverkehrs (z.b. blinkendes Antennensymbol im HM-CC-TC und kurzes piepen zur vollen Stunde von morgens bis abends, fehlende ACK Meldungen, nicht auslösende IR-Bewegungssensoren und ähnliches) sollte also immer auch eine schlechte Spannungsversorgung in Betracht gezogen werden.

Gute neue Batterien halten jedoch i.d.R. 12 Monate und mehr, auch Lebensdauern über 2 Jahre sind bei einigen Geräten (Tür/Fensterkontakte, Sender, Retroanzeige, IR-Bewegungsmelder) keine Seltenheit.

== Links ==
* [http://www.homematic.com/ HomeMatic] Homepage
* Hersteller [http://www.eq-3.de eQ-3]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Glossary]]

Diskussion:HomeMatic HMinfo Templates erstellen

2016-02-18T12:25:33Z

Octo: /* "on" vs. "no" */ Woher kommen die "no"-Einträge?

== "on" vs. "no" ==

In der Tabelle mit dem Ausgangszustand kommen insbesondere "on" und "off" vor; in der Tabelle für das neue Verhalten taucht plötzlich "no" auf. Ist das korrekt oder ein Tippfehle?

SwJtDlyOff off '''no''' on '''no'''
SwJtDlyOn off '''no''' on '''no'''
SwJtOff off on dlyOn '''no'''
SwJtOn dlyOff '''no''' on off

Außerdem hätte ich erwartet, dass nur die Spalten 3 und 5 getauscht werden müssen um den gewünschten Effekt zu erhalten, also:

SwJtDlyOff off on on off
SwJtDlyOn off on on off
SwJtOff off dlyOn dlyOn off
SwJtOn dlyOff on on dlyOff

Insbesondere die vielen "no" / "on" Einträge in der 5. Spalte verwirren mich. Eine Erklärung, warum die geänderte Tabelle das gewünschte Verhalten darstellt, würden den Artikel deutlich hilfreicher machen. 
—[[Benutzer:Octo|Octo]] ([[Benutzer Diskussion:Octo|Diskussion]]) 13:25, 18. Feb. 2016 (CET)

HM-ES-TX-WM Zählersensor für Strom- und Gaszähler

2016-02-17T18:42:51Z

Octo: /* Betrieb mit FHEM */ Feraris -> Ferraris

{{Infobox Hardware
|Bild=HM-EM-TX-WM.jpg
|Bildbeschreibung=HomeMatic Zählersensor
|HWProtocol=HomeMatic
|HWType=Powersensor
|HWCategory=HomeMatic
|HWComm=868 MHz
|HWChannels=1
|HWVoltage=6 V
|HWPowerConsumption=30 mA
|HWPoweredBy=4 Batterien LR6/AA/Mignon
|HWSize=68x105x30mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

'''Dieses Device ist seit Anfang Feb. 2015 als Bausatz auf dem Markt - dieser Artikel ist im Aufbau - bitte Verständnis für Unvollständigkeiten und fehlende Bereiche '''

== Features ==
Der Zählersensor ist ein Datenerfassungssystem, das den Energieverbräuche (Strom, Gas) direkt am Zähler erfasst und in FHEM als laufender Saldo und als Momentanwerte verfügbar macht.

'''Technische Daten:'''

Gewicht: 195 g (inkl. 4 LR6/Mignon/AA-Batterien)

== Anwendungsszenarien ==
Mit den erfassten und gesammelten Daten lassen sich Aktionen beim Erreichen bestimmter Schwellwerte auslösen, Verbrauchs- und Kostenstatistiken ableiten sowie beliebige weitere Abhängigkeiten bilden. Durch die Funkdatenübertragung sowie den Batteriebetrieb (1 bis 2 Jahre Betriebsdauer verspricht der Hersteller mit einem Satz) ist die Installation denkbar einfach und erfordert lediglich beim Anbringen der Leseeinheit Genauigkeit.

Aktuell (Feb. 2015) hat die Auslieferung der Geräte als (einfacher) Bausatz begonnen, zu dem es einen Ferraris-Sensor (für Stromzähler mit den markanten Laufscheiben), LED-Sensor (für neue Zähler mit S0-Schnittstelle) sowie BK-G4-Gaszähler von Elster-Kromschröder, die an einer Ziffernrolle einen kleinen Magneten haben, der über einen Sensor mit Reedkontakt erfasst wird. Es ist laut Hersteller [http://www.elv.de/homematic-zaehlersensor-strom-gas-bausatz.html ELV] nur der Bausatz verfügbar. Ein Fertiggerät ist aktuell nicht geplant.

Die Zähler werden mit rückstandslos entfernbaren Klebepads angebracht.

== Parameter ==
'''list: register | range | peer | description'''
0: pairCentral | 0 to 16777215 | | pairing to central
1: mtrConstGas | 0 to 655.36 | | constant gas
1: mtrConstIr | 0 to 65536 | | constant IR
1: mtrConstLed | 0 to 65536 | | constant led
1: mtrSensIr | -99 to 99 | | sensiblity IR
1: mtrType | literal | | type of measurement options:LED,gas,unknown,IR

== Probleme ==

Der HM-ES-TX-WM sendet zyklisch im 3-Minuten Takt die aktuellsten Verbrauchsdaten. Dabei ist für das Reading "power" (aktuelle Stromleistung in Watt) zu beachten, dass alle 3 Minuten der ''zuletzt bekannte Wert'' gesendet wird. Das heißt im Besonderen:

* Sollten innerhalb der 3 Minuten mehrfache Impulse auftreten mit unterschiedlichen Leistungswerten, wird nur der zuletzt bekannte Wert genommen. Es findet keine Aggregation der Impulse (Mittelwert, Summe, …) statt.
* Sollten innerhalb der 3 Minuten keinerlei Impulse auftreten, wird dennoch der zuletzt bekannte Leistungswert gesendet, auch wenn er mehrere Minuten/Stunden/Tage alt ist.

== Betrieb mit FHEM ==
Der Sensor wird mit einem FHEM im Update-Stand vom (mindestens) 7.2.2015 funktionsfähig eingebunden (getestet in der Variante mit Ferraris-Fühler). Es werden der Fühlertyp und die Fühlerkonstante richtig ausgelesen und im Reading "Energy" die errechnete Energiemenge ausgegeben (bei Strom: Wattstunden, Wh).

Für die perfekte Konfiguration wird auf [[Heizleistung_und_Gasverbrauch]] verwiesen, wo eine vollständige Lösung für die Umrechnung von Gasverbrauch in kW/h, Graphen und Hilfsprogramme vorgestellt wird.

=== Readings ===
'''Reading: |Beispiel'''
D-firmware |1.0
D-serialNr |MEQ0025452
battery |ok
boot |off
current |0
eState |E: 6199.9 P: 1713 I: 0 U: 0 f: 50
energy |6199.9
energyOffset |84413.2
frequency |50
power |1713
powerOn |2015-03-26 14:57:48
voltage |0

=== Events Auszug ===
'''Event |Beispielswert'''
battery* |ok
energy |10186.6
power |283
current |0
voltage |0
frequency |50
eState |E: 10186.6 P: 283 I: 0 U: 0 f: 50
boot |off

<nowiki>*</nowiki> - Ein battery-Event wird nicht zyklisch getriggert. Erst wenn die Batterie tatsächlich leer ist, wird eine entsprechende Meldung vom Gerät selber gesendet und ein battery-Event getriggert (battery: low).

Mit einem Userreading lässt sich die Angabe aus Energy zum Beispiel für einen Stromzähler (Wh) in die auf dem Zähler übliche Angabe kWh umrechnen und zugleich mit dem Aufaddieren des Unterschieds beim Start (das Zählermodul beginnt ja mit 0 Wh, während der Zähler meist schon einige Jahre auf der "Rolle" hat) die Angaben gleichziehen:

attr <DeviceName> userReadings kWh {sprintf("%.1f",ReadingsVal("<DeviceName>","energy","???")/1000+72031.5639)}

=== Konfiguration ===
Nach dem Erkennen durch [[autocreate]] wird der Zählersensor mit diesen Angaben eingebunden:

define CUL_HM_HM_ES_TX_WM_353594 CUL_HM 353594
attr CUL_HM_HM_ES_TX_WM_353594 IODev CUL_0
attr CUL_HM_HM_ES_TX_WM_353594 actCycle 000:10
attr CUL_HM_HM_ES_TX_WM_353594 actStatus alive
attr CUL_HM_HM_ES_TX_WM_353594 expert 2_full
attr CUL_HM_HM_ES_TX_WM_353594 firmware 1.0
attr CUL_HM_HM_ES_TX_WM_353594 model HM-ES-TX-WM
attr CUL_HM_HM_ES_TX_WM_353594 subType powerSensor

Für den Betrieb mit den verschiedenen Zählern muß eines der Readings '''R-mtrConst'''XXX auf den jeweiligen verwendeten Zähler konfiguriert werden. Z.B. kann ein Ferraris-Stromzähler 100, 150 oder 200 Umdrehungen je kWh benötigen. Dies geschieht z.B. für 150 Meldungen je Einheit für einen Ferraris-Zähler mit dem Befehl

set CUL_HM_HM_ES_TX_WM_353594 regSet mtrConstIr 150

oder für einen Gaszähler auf der 1. Rolle (d.h. 1 Impuls je 0.1 m^3)

set CUL_HM_HM_ES_TX_WM_353594 regSet mtrConstGas 0.1

In fhem bis zum Anfang November 2015 war hier ein kleiner Bug enthalten, der diesen Wert nicht akzeptierte. In diesem Fall läßt sich die Anzahl der Impulse direkt am Gerät über das Display einstellen.

== Logging/Graph. Darstellung ==
[[Datei:PlotStromverbrauchProStunde.png|mini|400px|rechts|Beispiel der graph. Darstellung]]
Der Zähler wird ja fortlaufend aufaddiert. Mit der delta-Funktion von SVG-Plot können die Verbräuche sehr gut visualisiert werden.
Beispiel Stromzähler:

set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Stündlicher Stromverbrauch | aktuell: $data{currval1} ($data{min1} / $data{avg1} / $data{max1}) kWh'
set ytics
set y2tics
set grid ytics
set ylabel "kWh/h"
set y2label "kWh/h"
#FileLog 4:CUL_HM_HM_ES_TX_WM_353594.kWh\x3a:0:delta-h
plot "<IN>" using 1:2 axes x1y2 title 'Line 1' ls l0 lw 2 with bars

== Links ==
* Handbuch: [http://files.elv.de/Assets/Produkte/14/1401/140143/Downloads/140143_sensor_um.pdf]
* Produktseite ELV: [http://www.elv.de/homematic-zaehlersensor-strom-gas-bausatz.html]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Energieverbrauchsmessung]]
[[Kategorie:Energieerzeugungsmessung]]

HM-ES-TX-WM Zählersensor für Strom- und Gaszähler

2016-02-17T18:39:34Z

Octo: /* Probleme */ Grammatik korrigiert.

{{Infobox Hardware
|Bild=HM-EM-TX-WM.jpg
|Bildbeschreibung=HomeMatic Zählersensor
|HWProtocol=HomeMatic
|HWType=Powersensor
|HWCategory=HomeMatic
|HWComm=868 MHz
|HWChannels=1
|HWVoltage=6 V
|HWPowerConsumption=30 mA
|HWPoweredBy=4 Batterien LR6/AA/Mignon
|HWSize=68x105x30mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

'''Dieses Device ist seit Anfang Feb. 2015 als Bausatz auf dem Markt - dieser Artikel ist im Aufbau - bitte Verständnis für Unvollständigkeiten und fehlende Bereiche '''

== Features ==
Der Zählersensor ist ein Datenerfassungssystem, das den Energieverbräuche (Strom, Gas) direkt am Zähler erfasst und in FHEM als laufender Saldo und als Momentanwerte verfügbar macht.

'''Technische Daten:'''

Gewicht: 195 g (inkl. 4 LR6/Mignon/AA-Batterien)

== Anwendungsszenarien ==
Mit den erfassten und gesammelten Daten lassen sich Aktionen beim Erreichen bestimmter Schwellwerte auslösen, Verbrauchs- und Kostenstatistiken ableiten sowie beliebige weitere Abhängigkeiten bilden. Durch die Funkdatenübertragung sowie den Batteriebetrieb (1 bis 2 Jahre Betriebsdauer verspricht der Hersteller mit einem Satz) ist die Installation denkbar einfach und erfordert lediglich beim Anbringen der Leseeinheit Genauigkeit.

Aktuell (Feb. 2015) hat die Auslieferung der Geräte als (einfacher) Bausatz begonnen, zu dem es einen Ferraris-Sensor (für Stromzähler mit den markanten Laufscheiben), LED-Sensor (für neue Zähler mit S0-Schnittstelle) sowie BK-G4-Gaszähler von Elster-Kromschröder, die an einer Ziffernrolle einen kleinen Magneten haben, der über einen Sensor mit Reedkontakt erfasst wird. Es ist laut Hersteller [http://www.elv.de/homematic-zaehlersensor-strom-gas-bausatz.html ELV] nur der Bausatz verfügbar. Ein Fertiggerät ist aktuell nicht geplant.

Die Zähler werden mit rückstandslos entfernbaren Klebepads angebracht.

== Parameter ==
'''list: register | range | peer | description'''
0: pairCentral | 0 to 16777215 | | pairing to central
1: mtrConstGas | 0 to 655.36 | | constant gas
1: mtrConstIr | 0 to 65536 | | constant IR
1: mtrConstLed | 0 to 65536 | | constant led
1: mtrSensIr | -99 to 99 | | sensiblity IR
1: mtrType | literal | | type of measurement options:LED,gas,unknown,IR

== Probleme ==

Der HM-ES-TX-WM sendet zyklisch im 3-Minuten Takt die aktuellsten Verbrauchsdaten. Dabei ist für das Reading "power" (aktuelle Stromleistung in Watt) zu beachten, dass alle 3 Minuten der ''zuletzt bekannte Wert'' gesendet wird. Das heißt im Besonderen:

* Sollten innerhalb der 3 Minuten mehrfache Impulse auftreten mit unterschiedlichen Leistungswerten, wird nur der zuletzt bekannte Wert genommen. Es findet keine Aggregation der Impulse (Mittelwert, Summe, …) statt.
* Sollten innerhalb der 3 Minuten keinerlei Impulse auftreten, wird dennoch der zuletzt bekannte Leistungswert gesendet, auch wenn er mehrere Minuten/Stunden/Tage alt ist.

== Betrieb mit FHEM ==
Der Sensor wird mit einem FHEM im Update-Stand vom (mindestens) 7.2.2015 funktionsfähig eingebunden (getestet in der Variante mit Feraris-Fühler). Es werden der Fühlertyp und die Fühlerkonstante richtig ausgelesen und im Reading Energy die errechnete Energiemenge ausgegeben (bei Strom: Wattstunden, Wh).

Für die perfekte Konfiguration wird auf [[Heizleistung_und_Gasverbrauch]] verwiesen, wo eine vollständige Lösung für die Umrechnung von Gasverbrauch in kW/h, Graphen und Hilfsprogramme vorgestellt wird.

=== Readings ===
'''Reading: |Beispiel'''
D-firmware |1.0
D-serialNr |MEQ0025452
battery |ok
boot |off
current |0
eState |E: 6199.9 P: 1713 I: 0 U: 0 f: 50
energy |6199.9
energyOffset |84413.2
frequency |50
power |1713
powerOn |2015-03-26 14:57:48
voltage |0

=== Events Auszug ===
'''Event |Beispielswert'''
battery* |ok
energy |10186.6
power |283
current |0
voltage |0
frequency |50
eState |E: 10186.6 P: 283 I: 0 U: 0 f: 50
boot |off

<nowiki>*</nowiki> - Ein battery-Event wird nicht zyklisch getriggert. Erst wenn die Batterie tatsächlich leer ist, wird eine entsprechende Meldung vom Gerät selber gesendet und ein battery-Event getriggert (battery: low).

Mit einem Userreading lässt sich die Angabe aus Energy zum Beispiel für einen Stromzähler (Wh) in die auf dem Zähler übliche Angabe kWh umrechnen und zugleich mit dem Aufaddieren des Unterschieds beim Start (das Zählermodul beginnt ja mit 0 Wh, während der Zähler meist schon einige Jahre auf der "Rolle" hat) die Angaben gleichziehen:

attr <DeviceName> userReadings kWh {sprintf("%.1f",ReadingsVal("<DeviceName>","energy","???")/1000+72031.5639)}

=== Konfiguration ===
Nach dem Erkennen durch [[autocreate]] wird der Zählersensor mit diesen Angaben eingebunden:

define CUL_HM_HM_ES_TX_WM_353594 CUL_HM 353594
attr CUL_HM_HM_ES_TX_WM_353594 IODev CUL_0
attr CUL_HM_HM_ES_TX_WM_353594 actCycle 000:10
attr CUL_HM_HM_ES_TX_WM_353594 actStatus alive
attr CUL_HM_HM_ES_TX_WM_353594 expert 2_full
attr CUL_HM_HM_ES_TX_WM_353594 firmware 1.0
attr CUL_HM_HM_ES_TX_WM_353594 model HM-ES-TX-WM
attr CUL_HM_HM_ES_TX_WM_353594 subType powerSensor

Für den Betrieb mit den verschiedenen Zählern muß eines der Readings '''R-mtrConst'''XXX auf den jeweiligen verwendeten Zähler konfiguriert werden. Z.B. kann ein Ferraris-Stromzähler 100, 150 oder 200 Umdrehungen je kWh benötigen. Dies geschieht z.B. für 150 Meldungen je Einheit für einen Ferraris-Zähler mit dem Befehl

set CUL_HM_HM_ES_TX_WM_353594 regSet mtrConstIr 150

oder für einen Gaszähler auf der 1. Rolle (d.h. 1 Impuls je 0.1 m^3)

set CUL_HM_HM_ES_TX_WM_353594 regSet mtrConstGas 0.1

In fhem bis zum Anfang November 2015 war hier ein kleiner Bug enthalten, der diesen Wert nicht akzeptierte. In diesem Fall läßt sich die Anzahl der Impulse direkt am Gerät über das Display einstellen.

== Logging/Graph. Darstellung ==
[[Datei:PlotStromverbrauchProStunde.png|mini|400px|rechts|Beispiel der graph. Darstellung]]
Der Zähler wird ja fortlaufend aufaddiert. Mit der delta-Funktion von SVG-Plot können die Verbräuche sehr gut visualisiert werden.
Beispiel Stromzähler:

set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Stündlicher Stromverbrauch | aktuell: $data{currval1} ($data{min1} / $data{avg1} / $data{max1}) kWh'
set ytics
set y2tics
set grid ytics
set ylabel "kWh/h"
set y2label "kWh/h"
#FileLog 4:CUL_HM_HM_ES_TX_WM_353594.kWh\x3a:0:delta-h
plot "<IN>" using 1:2 axes x1y2 title 'Line 1' ls l0 lw 2 with bars

== Links ==
* Handbuch: [http://files.elv.de/Assets/Produkte/14/1401/140143/Downloads/140143_sensor_um.pdf]
* Produktseite ELV: [http://www.elv.de/homematic-zaehlersensor-strom-gas-bausatz.html]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Energieverbrauchsmessung]]
[[Kategorie:Energieerzeugungsmessung]]

HM-TC-IT-WM-W-EU Funk-Wandthermostat AP

2016-02-16T09:43:12Z

Octo: Bildbeschreibung in der Infobox korrigiert.

{{Infobox Hardware
|Bild=HM-TC-IT-WM-W-EU.jpg
|Bildbeschreibung=HM-TC-IT-WM-W-EU Wandthermostat
|Bildbeschreibung=HM-TC-IT-WM-W-EU mit Standard-Einstellungen
|HWProtocol=[[HomeMatic]]
|HWType=[[HomeMatic Type Thermostat|thermostat]]
|HWCategory=[[:Kategorie:Temperatursensoren|Temperatursensoren]]
|HWComm=868,3 MHz
|HWChannels=7
|HWVoltage=3 V
|HWPowerConsumption=40 mA (max)
|HWPoweredBy=2 x LR6/Mignon/AA
|HWSize=ohne Rahmen: 55 x 55 x 20 mm mit Rahmen: 86 x 86 x 21,5 mm
|HWDeviceFHEM=[[CUL_HM]]

|HWManufacturer=ELV / eQ-3
}}
'''HM-TC-IT-WM-W-EU Funk-Wandthermostat AP'''

HomeMatic-Wandthermostat Aufputz. Verfügbar seit Februar 2014. Nachfolger des [[HM-CC-TC_Funk-Wandthermostat|HM-CC-TC]].

== Vorbemerkungen ==
: ''→ Allgemeine Informationen, die alle HomeMatic Thermostate betreffen, sind unter [[HomeMatic Type Thermostat]] zu finden.''

Der '''HM-TC-IT-WM-W-EU Funk-Wandthermostat''' misst die Raumtemperatur und Luftfeuchtigkeit. Er verfügt über individuell einstellbare Wochenprogramme und Programmierung direkt am Gerät. Zusätzlich ist auch eine Boost-Funktion vorhanden (ermöglicht ein schnelles, kurzzeitiges Aufheizen des Heizkörpers). Er verfügt über ein eigenes Anzeigedisplay für Soll- und Isttemperatur sowie Luftfeuchtigkeit. Er kann mittels Klebestreifen irgendwo aufgeklebt werden, soll aber auch in Mehrfachrahmen von Berker, ELSO, Gira, Merten und JUNG passen.

== Technische Daten ==

'''Technische Daten:'''
* Versorgungsspannung: 2 Stck. 1,5 V LR03/Micro/AAA
* Stromaufnahme (max.): 40 mA
* Schutzart: IP20
* Schutzklasse: III
* Abmessungen (BxHxT ohne Rahmen): 55 x 55 x 20 mm
* Abmessungen (BxHxT mit Rahmen): 86 x 86 x 21,5 mm
* Gewicht (ohne Batterien): 74 g
* Temperaturwahl in Schritten von: 0,5 °C

Im Gegensatz zum HM-CC-TC kann der HM-TC-IT-WM-W-EU auch andere HomeMatic-Schaltaktoren (z.B. [[HM-LC-SW1-FM_Schaltaktor_1-fach_UP|HM-LC-SW1-FM]]) über den Channel 07 SwitchTr direkt anlernen, womit z.B. die Steuerung elektrischer Heizungen möglich wird. Der HM-CC-TC konnte direkt nur die HM-CC-VD steuern.

== Betrieb mit FHEM ==

Zuerst muss das Wandthermostat natürlich mit FHEM gepairt werden. Danach kann das Peering mit den Heizkörperthermostaten des betreffenden Raumes stattfinden:

=== Channels (Kanäle) ===

==== Channel (Kanal) 01 _Weather ====
Damit das Heizkörperthermostat HM-CC-RT-DN die Temperatur des Wandthermostats übernimmt, muss der Weather Kanal gepeert werden:

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

==== Channel (Kanal) 02 _Climate ====
Damit der Heizkörperthermostat vom Wandthermostat auch eingestellt werden kann (Soll-Temperatur, Mode etc.), muss der Climate Kanal gepeert werden:

set <HM-TC-IT-WM-W-EU-Gerät>_Climate peerChan 0 <HM-CC-RT-DN-Gerät>_Climate single set
Dies muss für jedes zu steuernde Heizkörperthermostat wiederholt werden.

==== Channel (Kanal) 03 _WindowRec ====
Mit diesem Kanal lassen sich Fensterkontakte (HM-SEC-SC oder HM-SEC-RHS) peeren, die ihren Fensterstatus (geöffnet/gekippt) an ein oder mehrere Thermostate senden. Die Thermostate stellen anschließend die entsprechende (konfigurierbare) Temperatur ein. Der Temperaturwert kann je Fenster-Sensor unterschiedlich definiert werden. Sind mehrere Fenster gleichzeitig geöffnet, so wird der Thermostat auf die Temperatur des Sensors mit dem geringsten Temperaturwert eingestellt.

Das Peering mit einem Tür-Fensterkontakt läuft wie folgt ab:

set <HM-Sec-SC> peerChan 0 <HM-TC-IT-WM-W-EU-Gerät>_WindowRec single set

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

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

Der Befehl zum peeren lautet, wobei <button> die Kanalbezeichnung der Fernbedienung und <tc-remote> die Kanalbezeichnung des Heizkörperthermostates ist:
<pre>set <button> peerChan 0 <rt-remote> single</pre>

==== Channel (Kanal) 07 _SwitchTr ====
Das Peering mit einem Schaltaktor läuft z.B. wie folgt ab:

set <HM-TC-IT-WM-W-EU_SwitchTr> peerChan 0 <HM-LC-SW1-FM> single set
set <HM-LC-SW1-FM> regSet shCtOn ltLo <HM-TC-IT-WM-W-EU_SwitchTr>

== Einstellungen ==

Die folgenden Einstellungen werden in **Registern** des HM-TC-IT-WM-W-EU vorgenommen. Das heißt, dass diese Einstellungen im Gerät selbst gespeichert werden, nicht in der Konfigurations-Datei von Fhem.

=== Anzeige ===

Register im Kanal 2 ''(_Climate)'' erlauben es zu konfigurieren, welche Daten der HM-TC-IT-WM-W-EU in seinem LC-Display anzeigt.

==== showInfo time|date ====

Wählt aus, ob die ''Uhrzeit'' (<code>time</code>, Standard-Einstellung) oder das ''Datum'' (<code>date</code>) angezeigt wird. Der folgende Befehl erlaubt es das Datum anzeigen zu lassen:

set <HM-TC-IT-WM-W-EU>_Climate regSet showInfo date

==== showSetTemp actTemp|setTemp ====

Wählt aus, ob die ''Ist-Temperatur'' (<code>actTemp</code>, Standard-Einstellung) oder die ''Soll-Temperatur'' (<code>setTemp</code>) im Display angezeigt wird.

set <HM-TC-IT-WM-W-EU>_Climate regSet showSetTemp setTemp

==== showHumidity temp|tempHum ====

Wählt aus, ob dauerhaft die ''Temperatur'' (<code>temp</code>, Standard-Einstellung) oder ''Temperatur und Luftfeuchtigkeit'' im Wechsel (<code>tempHum</code>) im Display angezeigt werden.

set <HM-TC-IT-WM-W-EU>_Climate regSet showHumidity tempHum

=== Tastensperre ===

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

set <HM-TC-IT-WM-W-EU> regSet btnLock on

Rückgängig machen geht per:

set <HM-TC-IT-WM-W-EU> regSet btnLock off

Diese Tastensperre kann man aber am Thermostat durch eine Tastenkombination wieder zurücksetzen. Um sie nur per Fhem rücksetzen zu können, muss

set <HM-TC-IT-WM-W-EU> regSet globalBtnLock on

abgesetzt werden. Rückgängig wieder per:

set <HM-TC-IT-WM-W-EU> regSet globalBtnLock off

=== Temperaturlisten ===

Die Temperaturlisten des HM-TC-IT-WM-W-EU werden identisch zu anderern HomeMatic Thermostaten verwaltet, siehe [[HomeMatic Type Thermostat#Temperaturlisten|HomeMatic Type Thermostat]]. Beim HM-TC-IT-WM-W-EU ist der Kanal 2 ''(_Climate)'' für die Temperaturlisten zuständig.

== Fhem-Log ==
=== Event monitor ===

Hier habe ich einmal die Wunschtemperatur erhöht, damit auch was passiert:

2014-04-09 09:35:11 CUL_HM KH_Bad_Therm CMDs_pending
2014-04-09 09:35:11 CUL_HM KH_Bad_Therm_Climate set_desired-temp 18.0
2014-04-09 09:35:11 CUL_HM KH_Bad_Therm CMDs_done

Bei mir ist es so, das der SwitchTr Kanal nur mit dem gepeerten Device spricht, hier ein HM-LC-SW1-FM:

2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung trig_KH_Bad_Therm_SwitchTr: 200
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung trigLast: KH_Bad_Therm_SwitchTr :200

Der hat auch prompt reagiert und die Heizung eingeschaltet:

2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung level: 100
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung pct: 100
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung deviceMsg: on (to KH_Bad_Therm)
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung on
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung timedOn: off

und noch ein wenig Geplauder der vorhandenen Kanäle:

2014-04-09 09:36:39 CUL_HM KH_Bad_Therm_Climate measured-temp: 16.0
2014-04-09 09:36:39 CUL_HM KH_Bad_Therm_Climate desired-temp: 18.0
2014-04-09 09:36:39 CUL_HM KH_Bad_Therm_Climate humidity: 50
2014-04-09 09:36:39 CUL_HM KH_Bad_Therm_Climate T: 16.0 desired: 18.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm battery: ok
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm batteryLevel: 3
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm measured-temp: 16.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm desired-temp: 18.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm_Climate measured-temp: 16.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm_Climate desired-temp: 18.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm_Climate mode: auto
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm_Climate T: 16.0 desired: 18.0
2014-04-09 09:36:59 CUL_HM KH_Bad_Therm_Weather temperature: 16.0
2014-04-09 09:36:59 CUL_HM KH_Bad_Therm_Weather humidity: 50
2014-04-09 09:36:59 CUL_HM KH_Bad_Therm_Weather T: 16.0 H: 50

== Firmware Update ==
Updates für den HM-TC-IT-WM-W-EU können von der eQ-3 Webseite heruntergeladen werden. Genauere Informationen gibt es unter [[HomeMatic_Firmware_Update]]. Das Thermostat wird in den Updatemodus gebracht, indem beide äußeren Tasten gedrückt werden, während die Batterien eingesetzt werden. Das Display zeigt "FUP" an.

== Bekannte Probleme ==
Bei der Firmware 1.2 und dem Kanal Climate funktioniert die Einstellung der Hysterese über das Register hyst2point nicht. Der Eintrag wird ignoriert.

Siehe auch Bericht im [http://www.elv.de/topic/hystereseeinstellung-bei-hm-tc-it-wm-w-eu-firmware-1-2-wird-ignoriert.html Forum von ELV]

== Links ==
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-TC-IT-WM-W-EU_UM_V1.0_GE_eQ-3_20131211_web.pdf Manual]
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/Funk-Wandthermostat_132030_Produktdatenblatt_V1.0.pdf Produktdatenblatt]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Feuchtesensoren]]
[[Kategorie:Temperatursensoren]]

HM-TC-IT-WM-W-EU Funk-Wandthermostat AP

2016-02-16T09:41:02Z

Octo: /* Einstellungen */ Informationen zur Anzeige hinzugefügt.

{{Infobox Hardware
|Bild=HM-TC-IT-WM-W-EU.jpg
|Bildbeschreibung=HM-TC-IT-WM-W-EU Wandthermostat
|Bildbeschreibung=HM-CC-RT-DN an Heizkörper montiert
|HWProtocol=[[HomeMatic]]
|HWType=[[HomeMatic Type Thermostat|thermostat]]
|HWCategory=[[:Kategorie:Temperatursensoren|Temperatursensoren]]
|HWComm=868,3 MHz
|HWChannels=7
|HWVoltage=3 V
|HWPowerConsumption=40 mA (max)
|HWPoweredBy=2 x LR6/Mignon/AA
|HWSize=ohne Rahmen: 55 x 55 x 20 mm mit Rahmen: 86 x 86 x 21,5 mm
|HWDeviceFHEM=[[CUL_HM]]

|HWManufacturer=ELV / eQ-3
}}
'''HM-TC-IT-WM-W-EU Funk-Wandthermostat AP'''

HomeMatic-Wandthermostat Aufputz. Verfügbar seit Februar 2014. Nachfolger des [[HM-CC-TC_Funk-Wandthermostat|HM-CC-TC]].

== Vorbemerkungen ==
: ''→ Allgemeine Informationen, die alle HomeMatic Thermostate betreffen, sind unter [[HomeMatic Type Thermostat]] zu finden.''

Der '''HM-TC-IT-WM-W-EU Funk-Wandthermostat''' misst die Raumtemperatur und Luftfeuchtigkeit. Er verfügt über individuell einstellbare Wochenprogramme und Programmierung direkt am Gerät. Zusätzlich ist auch eine Boost-Funktion vorhanden (ermöglicht ein schnelles, kurzzeitiges Aufheizen des Heizkörpers). Er verfügt über ein eigenes Anzeigedisplay für Soll- und Isttemperatur sowie Luftfeuchtigkeit. Er kann mittels Klebestreifen irgendwo aufgeklebt werden, soll aber auch in Mehrfachrahmen von Berker, ELSO, Gira, Merten und JUNG passen.

== Technische Daten ==

'''Technische Daten:'''
* Versorgungsspannung: 2 Stck. 1,5 V LR03/Micro/AAA
* Stromaufnahme (max.): 40 mA
* Schutzart: IP20
* Schutzklasse: III
* Abmessungen (BxHxT ohne Rahmen): 55 x 55 x 20 mm
* Abmessungen (BxHxT mit Rahmen): 86 x 86 x 21,5 mm
* Gewicht (ohne Batterien): 74 g
* Temperaturwahl in Schritten von: 0,5 °C

Im Gegensatz zum HM-CC-TC kann der HM-TC-IT-WM-W-EU auch andere HomeMatic-Schaltaktoren (z.B. [[HM-LC-SW1-FM_Schaltaktor_1-fach_UP|HM-LC-SW1-FM]]) über den Channel 07 SwitchTr direkt anlernen, womit z.B. die Steuerung elektrischer Heizungen möglich wird. Der HM-CC-TC konnte direkt nur die HM-CC-VD steuern.

== Betrieb mit FHEM ==

Zuerst muss das Wandthermostat natürlich mit FHEM gepairt werden. Danach kann das Peering mit den Heizkörperthermostaten des betreffenden Raumes stattfinden:

=== Channels (Kanäle) ===

==== Channel (Kanal) 01 _Weather ====
Damit das Heizkörperthermostat HM-CC-RT-DN die Temperatur des Wandthermostats übernimmt, muss der Weather Kanal gepeert werden:

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

==== Channel (Kanal) 02 _Climate ====
Damit der Heizkörperthermostat vom Wandthermostat auch eingestellt werden kann (Soll-Temperatur, Mode etc.), muss der Climate Kanal gepeert werden:

set <HM-TC-IT-WM-W-EU-Gerät>_Climate peerChan 0 <HM-CC-RT-DN-Gerät>_Climate single set
Dies muss für jedes zu steuernde Heizkörperthermostat wiederholt werden.

==== Channel (Kanal) 03 _WindowRec ====
Mit diesem Kanal lassen sich Fensterkontakte (HM-SEC-SC oder HM-SEC-RHS) peeren, die ihren Fensterstatus (geöffnet/gekippt) an ein oder mehrere Thermostate senden. Die Thermostate stellen anschließend die entsprechende (konfigurierbare) Temperatur ein. Der Temperaturwert kann je Fenster-Sensor unterschiedlich definiert werden. Sind mehrere Fenster gleichzeitig geöffnet, so wird der Thermostat auf die Temperatur des Sensors mit dem geringsten Temperaturwert eingestellt.

Das Peering mit einem Tür-Fensterkontakt läuft wie folgt ab:

set <HM-Sec-SC> peerChan 0 <HM-TC-IT-WM-W-EU-Gerät>_WindowRec single set

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

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

Der Befehl zum peeren lautet, wobei <button> die Kanalbezeichnung der Fernbedienung und <tc-remote> die Kanalbezeichnung des Heizkörperthermostates ist:
<pre>set <button> peerChan 0 <rt-remote> single</pre>

==== Channel (Kanal) 07 _SwitchTr ====
Das Peering mit einem Schaltaktor läuft z.B. wie folgt ab:

set <HM-TC-IT-WM-W-EU_SwitchTr> peerChan 0 <HM-LC-SW1-FM> single set
set <HM-LC-SW1-FM> regSet shCtOn ltLo <HM-TC-IT-WM-W-EU_SwitchTr>

== Einstellungen ==

Die folgenden Einstellungen werden in **Registern** des HM-TC-IT-WM-W-EU vorgenommen. Das heißt, dass diese Einstellungen im Gerät selbst gespeichert werden, nicht in der Konfigurations-Datei von Fhem.

=== Anzeige ===

Register im Kanal 2 ''(_Climate)'' erlauben es zu konfigurieren, welche Daten der HM-TC-IT-WM-W-EU in seinem LC-Display anzeigt.

==== showInfo time|date ====

Wählt aus, ob die ''Uhrzeit'' (<code>time</code>, Standard-Einstellung) oder das ''Datum'' (<code>date</code>) angezeigt wird. Der folgende Befehl erlaubt es das Datum anzeigen zu lassen:

set <HM-TC-IT-WM-W-EU>_Climate regSet showInfo date

==== showSetTemp actTemp|setTemp ====

Wählt aus, ob die ''Ist-Temperatur'' (<code>actTemp</code>, Standard-Einstellung) oder die ''Soll-Temperatur'' (<code>setTemp</code>) im Display angezeigt wird.

set <HM-TC-IT-WM-W-EU>_Climate regSet showSetTemp setTemp

==== showHumidity temp|tempHum ====

Wählt aus, ob dauerhaft die ''Temperatur'' (<code>temp</code>, Standard-Einstellung) oder ''Temperatur und Luftfeuchtigkeit'' im Wechsel (<code>tempHum</code>) im Display angezeigt werden.

set <HM-TC-IT-WM-W-EU>_Climate regSet showHumidity tempHum

=== Tastensperre ===

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

set <HM-TC-IT-WM-W-EU> regSet btnLock on

Rückgängig machen geht per:

set <HM-TC-IT-WM-W-EU> regSet btnLock off

Diese Tastensperre kann man aber am Thermostat durch eine Tastenkombination wieder zurücksetzen. Um sie nur per Fhem rücksetzen zu können, muss

set <HM-TC-IT-WM-W-EU> regSet globalBtnLock on

abgesetzt werden. Rückgängig wieder per:

set <HM-TC-IT-WM-W-EU> regSet globalBtnLock off

=== Temperaturlisten ===

Die Temperaturlisten des HM-TC-IT-WM-W-EU werden identisch zu anderern HomeMatic Thermostaten verwaltet, siehe [[HomeMatic Type Thermostat#Temperaturlisten|HomeMatic Type Thermostat]]. Beim HM-TC-IT-WM-W-EU ist der Kanal 2 ''(_Climate)'' für die Temperaturlisten zuständig.

== Fhem-Log ==
=== Event monitor ===

Hier habe ich einmal die Wunschtemperatur erhöht, damit auch was passiert:

2014-04-09 09:35:11 CUL_HM KH_Bad_Therm CMDs_pending
2014-04-09 09:35:11 CUL_HM KH_Bad_Therm_Climate set_desired-temp 18.0
2014-04-09 09:35:11 CUL_HM KH_Bad_Therm CMDs_done

Bei mir ist es so, das der SwitchTr Kanal nur mit dem gepeerten Device spricht, hier ein HM-LC-SW1-FM:

2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung trig_KH_Bad_Therm_SwitchTr: 200
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung trigLast: KH_Bad_Therm_SwitchTr :200

Der hat auch prompt reagiert und die Heizung eingeschaltet:

2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung level: 100
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung pct: 100
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung deviceMsg: on (to KH_Bad_Therm)
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung on
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung timedOn: off

und noch ein wenig Geplauder der vorhandenen Kanäle:

2014-04-09 09:36:39 CUL_HM KH_Bad_Therm_Climate measured-temp: 16.0
2014-04-09 09:36:39 CUL_HM KH_Bad_Therm_Climate desired-temp: 18.0
2014-04-09 09:36:39 CUL_HM KH_Bad_Therm_Climate humidity: 50
2014-04-09 09:36:39 CUL_HM KH_Bad_Therm_Climate T: 16.0 desired: 18.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm battery: ok
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm batteryLevel: 3
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm measured-temp: 16.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm desired-temp: 18.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm_Climate measured-temp: 16.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm_Climate desired-temp: 18.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm_Climate mode: auto
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm_Climate T: 16.0 desired: 18.0
2014-04-09 09:36:59 CUL_HM KH_Bad_Therm_Weather temperature: 16.0
2014-04-09 09:36:59 CUL_HM KH_Bad_Therm_Weather humidity: 50
2014-04-09 09:36:59 CUL_HM KH_Bad_Therm_Weather T: 16.0 H: 50

== Firmware Update ==
Updates für den HM-TC-IT-WM-W-EU können von der eQ-3 Webseite heruntergeladen werden. Genauere Informationen gibt es unter [[HomeMatic_Firmware_Update]]. Das Thermostat wird in den Updatemodus gebracht, indem beide äußeren Tasten gedrückt werden, während die Batterien eingesetzt werden. Das Display zeigt "FUP" an.

== Bekannte Probleme ==
Bei der Firmware 1.2 und dem Kanal Climate funktioniert die Einstellung der Hysterese über das Register hyst2point nicht. Der Eintrag wird ignoriert.

Siehe auch Bericht im [http://www.elv.de/topic/hystereseeinstellung-bei-hm-tc-it-wm-w-eu-firmware-1-2-wird-ignoriert.html Forum von ELV]

== Links ==
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-TC-IT-WM-W-EU_UM_V1.0_GE_eQ-3_20131211_web.pdf Manual]
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/Funk-Wandthermostat_132030_Produktdatenblatt_V1.0.pdf Produktdatenblatt]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Feuchtesensoren]]
[[Kategorie:Temperatursensoren]]

HM-TC-IT-WM-W-EU Funk-Wandthermostat AP

2016-02-16T09:23:49Z

Octo: /* Betrieb mit FHEM */ Einstellungen / Register in einen eigenen Abschnitt verschoben.

{{Infobox Hardware
|Bild=HM-TC-IT-WM-W-EU.jpg
|Bildbeschreibung=HM-TC-IT-WM-W-EU Wandthermostat
|Bildbeschreibung=HM-CC-RT-DN an Heizkörper montiert
|HWProtocol=[[HomeMatic]]
|HWType=[[HomeMatic Type Thermostat|thermostat]]
|HWCategory=[[:Kategorie:Temperatursensoren|Temperatursensoren]]
|HWComm=868,3 MHz
|HWChannels=7
|HWVoltage=3 V
|HWPowerConsumption=40 mA (max)
|HWPoweredBy=2 x LR6/Mignon/AA
|HWSize=ohne Rahmen: 55 x 55 x 20 mm mit Rahmen: 86 x 86 x 21,5 mm
|HWDeviceFHEM=[[CUL_HM]]

|HWManufacturer=ELV / eQ-3
}}
'''HM-TC-IT-WM-W-EU Funk-Wandthermostat AP'''

HomeMatic-Wandthermostat Aufputz. Verfügbar seit Februar 2014. Nachfolger des [[HM-CC-TC_Funk-Wandthermostat|HM-CC-TC]].

== Vorbemerkungen ==
: ''→ Allgemeine Informationen, die alle HomeMatic Thermostate betreffen, sind unter [[HomeMatic Type Thermostat]] zu finden.''

Der '''HM-TC-IT-WM-W-EU Funk-Wandthermostat''' misst die Raumtemperatur und Luftfeuchtigkeit. Er verfügt über individuell einstellbare Wochenprogramme und Programmierung direkt am Gerät. Zusätzlich ist auch eine Boost-Funktion vorhanden (ermöglicht ein schnelles, kurzzeitiges Aufheizen des Heizkörpers). Er verfügt über ein eigenes Anzeigedisplay für Soll- und Isttemperatur sowie Luftfeuchtigkeit. Er kann mittels Klebestreifen irgendwo aufgeklebt werden, soll aber auch in Mehrfachrahmen von Berker, ELSO, Gira, Merten und JUNG passen.

== Technische Daten ==

'''Technische Daten:'''
* Versorgungsspannung: 2 Stck. 1,5 V LR03/Micro/AAA
* Stromaufnahme (max.): 40 mA
* Schutzart: IP20
* Schutzklasse: III
* Abmessungen (BxHxT ohne Rahmen): 55 x 55 x 20 mm
* Abmessungen (BxHxT mit Rahmen): 86 x 86 x 21,5 mm
* Gewicht (ohne Batterien): 74 g
* Temperaturwahl in Schritten von: 0,5 °C

Im Gegensatz zum HM-CC-TC kann der HM-TC-IT-WM-W-EU auch andere HomeMatic-Schaltaktoren (z.B. [[HM-LC-SW1-FM_Schaltaktor_1-fach_UP|HM-LC-SW1-FM]]) über den Channel 07 SwitchTr direkt anlernen, womit z.B. die Steuerung elektrischer Heizungen möglich wird. Der HM-CC-TC konnte direkt nur die HM-CC-VD steuern.

== Betrieb mit FHEM ==

Zuerst muss das Wandthermostat natürlich mit FHEM gepairt werden. Danach kann das Peering mit den Heizkörperthermostaten des betreffenden Raumes stattfinden:

=== Channels (Kanäle) ===

==== Channel (Kanal) 01 _Weather ====
Damit das Heizkörperthermostat HM-CC-RT-DN die Temperatur des Wandthermostats übernimmt, muss der Weather Kanal gepeert werden:

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

==== Channel (Kanal) 02 _Climate ====
Damit der Heizkörperthermostat vom Wandthermostat auch eingestellt werden kann (Soll-Temperatur, Mode etc.), muss der Climate Kanal gepeert werden:

set <HM-TC-IT-WM-W-EU-Gerät>_Climate peerChan 0 <HM-CC-RT-DN-Gerät>_Climate single set
Dies muss für jedes zu steuernde Heizkörperthermostat wiederholt werden.

==== Channel (Kanal) 03 _WindowRec ====
Mit diesem Kanal lassen sich Fensterkontakte (HM-SEC-SC oder HM-SEC-RHS) peeren, die ihren Fensterstatus (geöffnet/gekippt) an ein oder mehrere Thermostate senden. Die Thermostate stellen anschließend die entsprechende (konfigurierbare) Temperatur ein. Der Temperaturwert kann je Fenster-Sensor unterschiedlich definiert werden. Sind mehrere Fenster gleichzeitig geöffnet, so wird der Thermostat auf die Temperatur des Sensors mit dem geringsten Temperaturwert eingestellt.

Das Peering mit einem Tür-Fensterkontakt läuft wie folgt ab:

set <HM-Sec-SC> peerChan 0 <HM-TC-IT-WM-W-EU-Gerät>_WindowRec single set

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

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

Der Befehl zum peeren lautet, wobei <button> die Kanalbezeichnung der Fernbedienung und <tc-remote> die Kanalbezeichnung des Heizkörperthermostates ist:
<pre>set <button> peerChan 0 <rt-remote> single</pre>

==== Channel (Kanal) 07 _SwitchTr ====
Das Peering mit einem Schaltaktor läuft z.B. wie folgt ab:

set <HM-TC-IT-WM-W-EU_SwitchTr> peerChan 0 <HM-LC-SW1-FM> single set
set <HM-LC-SW1-FM> regSet shCtOn ltLo <HM-TC-IT-WM-W-EU_SwitchTr>

== Einstellungen ==

Die folgenden Einstellungen werden in **Registern** des HM-TC-IT-WM-W-EU vorgenommen. Das heißt, dass diese Einstellungen im Gerät selbst gespeichert werden, nicht in der Konfigurations-Datei von Fhem.

=== Tastensperre ===

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

set <HM-TC-IT-WM-W-EU> regSet btnLock on

Rückgängig machen geht per:

set <HM-TC-IT-WM-W-EU> regSet btnLock off

Diese Tastensperre kann man aber am Thermostat durch eine Tastenkombination wieder zurücksetzen. Um sie nur per Fhem rücksetzen zu können, muss

set <HM-TC-IT-WM-W-EU> regSet globalBtnLock on

abgesetzt werden. Rückgängig wieder per:

set <HM-TC-IT-WM-W-EU> regSet globalBtnLock off

=== Temperaturlisten ===

Die Temperaturlisten des HM-TC-IT-WM-W-EU werden identisch zu anderern HomeMatic Thermostaten verwaltet, siehe [[HomeMatic Type Thermostat#Temperaturlisten|HomeMatic Type Thermostat]]. Beim HM-TC-IT-WM-W-EU ist der Kanal 2 ''(_Climate)'' für die Temperaturlisten zuständig.

== Fhem-Log ==
=== Event monitor ===

Hier habe ich einmal die Wunschtemperatur erhöht, damit auch was passiert:

2014-04-09 09:35:11 CUL_HM KH_Bad_Therm CMDs_pending
2014-04-09 09:35:11 CUL_HM KH_Bad_Therm_Climate set_desired-temp 18.0
2014-04-09 09:35:11 CUL_HM KH_Bad_Therm CMDs_done

Bei mir ist es so, das der SwitchTr Kanal nur mit dem gepeerten Device spricht, hier ein HM-LC-SW1-FM:

2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung trig_KH_Bad_Therm_SwitchTr: 200
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung trigLast: KH_Bad_Therm_SwitchTr :200

Der hat auch prompt reagiert und die Heizung eingeschaltet:

2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung level: 100
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung pct: 100
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung deviceMsg: on (to KH_Bad_Therm)
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung on
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung timedOn: off

und noch ein wenig Geplauder der vorhandenen Kanäle:

2014-04-09 09:36:39 CUL_HM KH_Bad_Therm_Climate measured-temp: 16.0
2014-04-09 09:36:39 CUL_HM KH_Bad_Therm_Climate desired-temp: 18.0
2014-04-09 09:36:39 CUL_HM KH_Bad_Therm_Climate humidity: 50
2014-04-09 09:36:39 CUL_HM KH_Bad_Therm_Climate T: 16.0 desired: 18.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm battery: ok
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm batteryLevel: 3
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm measured-temp: 16.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm desired-temp: 18.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm_Climate measured-temp: 16.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm_Climate desired-temp: 18.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm_Climate mode: auto
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm_Climate T: 16.0 desired: 18.0
2014-04-09 09:36:59 CUL_HM KH_Bad_Therm_Weather temperature: 16.0
2014-04-09 09:36:59 CUL_HM KH_Bad_Therm_Weather humidity: 50
2014-04-09 09:36:59 CUL_HM KH_Bad_Therm_Weather T: 16.0 H: 50

== Firmware Update ==
Updates für den HM-TC-IT-WM-W-EU können von der eQ-3 Webseite heruntergeladen werden. Genauere Informationen gibt es unter [[HomeMatic_Firmware_Update]]. Das Thermostat wird in den Updatemodus gebracht, indem beide äußeren Tasten gedrückt werden, während die Batterien eingesetzt werden. Das Display zeigt "FUP" an.

== Bekannte Probleme ==
Bei der Firmware 1.2 und dem Kanal Climate funktioniert die Einstellung der Hysterese über das Register hyst2point nicht. Der Eintrag wird ignoriert.

Siehe auch Bericht im [http://www.elv.de/topic/hystereseeinstellung-bei-hm-tc-it-wm-w-eu-firmware-1-2-wird-ignoriert.html Forum von ELV]

== Links ==
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-TC-IT-WM-W-EU_UM_V1.0_GE_eQ-3_20131211_web.pdf Manual]
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/Funk-Wandthermostat_132030_Produktdatenblatt_V1.0.pdf Produktdatenblatt]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Feuchtesensoren]]
[[Kategorie:Temperatursensoren]]

HM-TC-IT-WM-W-EU Funk-Wandthermostat AP

2016-02-15T14:48:50Z

Octo: Infobox hinzugefügt.

{{Infobox Hardware
|Bild=HM-TC-IT-WM-W-EU.jpg
|Bildbeschreibung=HM-TC-IT-WM-W-EU Wandthermostat
|Bildbeschreibung=HM-CC-RT-DN an Heizkörper montiert
|HWProtocol=[[HomeMatic]]
|HWType=[[HomeMatic Type Thermostat|thermostat]]
|HWCategory=[[:Kategorie:Temperatursensoren|Temperatursensoren]]
|HWComm=868,3 MHz
|HWChannels=7
|HWVoltage=3 V
|HWPowerConsumption=40 mA (max)
|HWPoweredBy=2 x LR6/Mignon/AA
|HWSize=ohne Rahmen: 55 x 55 x 20 mm mit Rahmen: 86 x 86 x 21,5 mm
|HWDeviceFHEM=[[CUL_HM]]

|HWManufacturer=ELV / eQ-3
}}
'''HM-TC-IT-WM-W-EU Funk-Wandthermostat AP'''

HomeMatic-Wandthermostat Aufputz. Verfügbar seit Februar 2014. Nachfolger des [[HM-CC-TC_Funk-Wandthermostat|HM-CC-TC]].

== Vorbemerkungen ==
: ''→ Allgemeine Informationen, die alle HomeMatic Thermostate betreffen, sind unter [[HomeMatic Type Thermostat]] zu finden.''

Der '''HM-TC-IT-WM-W-EU Funk-Wandthermostat''' misst die Raumtemperatur und Luftfeuchtigkeit. Er verfügt über individuell einstellbare Wochenprogramme und Programmierung direkt am Gerät. Zusätzlich ist auch eine Boost-Funktion vorhanden (ermöglicht ein schnelles, kurzzeitiges Aufheizen des Heizkörpers). Er verfügt über ein eigenes Anzeigedisplay für Soll- und Isttemperatur sowie Luftfeuchtigkeit. Er kann mittels Klebestreifen irgendwo aufgeklebt werden, soll aber auch in Mehrfachrahmen von Berker, ELSO, Gira, Merten und JUNG passen.

== Technische Daten ==

'''Technische Daten:'''
* Versorgungsspannung: 2 Stck. 1,5 V LR03/Micro/AAA
* Stromaufnahme (max.): 40 mA
* Schutzart: IP20
* Schutzklasse: III
* Abmessungen (BxHxT ohne Rahmen): 55 x 55 x 20 mm
* Abmessungen (BxHxT mit Rahmen): 86 x 86 x 21,5 mm
* Gewicht (ohne Batterien): 74 g
* Temperaturwahl in Schritten von: 0,5 °C

Im Gegensatz zum HM-CC-TC kann der HM-TC-IT-WM-W-EU auch andere HomeMatic-Schaltaktoren (z.B. [[HM-LC-SW1-FM_Schaltaktor_1-fach_UP|HM-LC-SW1-FM]]) über den Channel 07 SwitchTr direkt anlernen, womit z.B. die Steuerung elektrischer Heizungen möglich wird. Der HM-CC-TC konnte direkt nur die HM-CC-VD steuern.

== Betrieb mit FHEM ==

Zuerst muss das Wandthermostat natürlich mit FHEM gepairt werden. Danach kann das Peering mit den Heizkörperthermostaten des betreffenden Raumes stattfinden:

=== Channels (Kanäle) ===

==== Channel (Kanal) 01 _Weather ====
Damit das Heizkörperthermostat HM-CC-RT-DN die Temperatur des Wandthermostats übernimmt, muss der Weather Kanal gepeert werden:

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

==== Channel (Kanal) 02 _Climate ====
Damit der Heizkörperthermostat vom Wandthermostat auch eingestellt werden kann (Soll-Temperatur, Mode etc.), muss der Climate Kanal gepeert werden:

set <HM-TC-IT-WM-W-EU-Gerät>_Climate peerChan 0 <HM-CC-RT-DN-Gerät>_Climate single set
Dies muss für jedes zu steuernde Heizkörperthermostat wiederholt werden.

==== Channel (Kanal) 03 _WindowRec ====
Mit diesem Kanal lassen sich Fensterkontakte (HM-SEC-SC oder HM-SEC-RHS) peeren, die ihren Fensterstatus (geöffnet/gekippt) an ein oder mehrere Thermostate senden. Die Thermostate stellen anschließend die entsprechende (konfigurierbare) Temperatur ein. Der Temperaturwert kann je Fenster-Sensor unterschiedlich definiert werden. Sind mehrere Fenster gleichzeitig geöffnet, so wird der Thermostat auf die Temperatur des Sensors mit dem geringsten Temperaturwert eingestellt.

Das Peering mit einem Tür-Fensterkontakt läuft wie folgt ab:

set <HM-Sec-SC> peerChan 0 <HM-TC-IT-WM-W-EU-Gerät>_WindowRec single set

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

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

Der Befehl zum peeren lautet, wobei <button> die Kanalbezeichnung der Fernbedienung und <tc-remote> die Kanalbezeichnung des Heizkörperthermostates ist:
<pre>set <button> peerChan 0 <rt-remote> single</pre>

==== Channel (Kanal) 07 _SwitchTr ====
Das Peering mit einem Schaltaktor läuft z.B. wie folgt ab:

set <HM-TC-IT-WM-W-EU_SwitchTr> peerChan 0 <HM-LC-SW1-FM> single set
set <HM-LC-SW1-FM> regSet shCtOn ltLo <HM-TC-IT-WM-W-EU_SwitchTr>

=== Tastensperre ===

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

set <HM-TC-IT-WM-W-EU> regSet btnLock on

Rückgängig machen geht per:

set <HM-TC-IT-WM-W-EU> regSet btnLock off

Diese Tastensperre kann man aber am Thermostat durch eine Tastenkombination wieder zurücksetzen. Um sie nur per Fhem rücksetzen zu können, muss

set <HM-TC-IT-WM-W-EU> regSet globalBtnLock on

abgesetzt werden. Rückgängig wieder per:

set <HM-TC-IT-WM-W-EU> regSet globalBtnLock off

=== Temperaturlisten ===
Die Temperaturlisten des HM-TC-IT-WM-W-EU werden identisch zu anderern HomeMatic Thermostaten verwaltet, siehe [[HomeMatic Type Thermostat#Temperaturlisten|HomeMatic Type Thermostat]]. Beim HM-TC-IT-WM-W-EU ist der Kanal 4 ''(_Climate)'' für die Temperaturlisten zuständig.

== Fhem-Log ==
=== Event monitor ===

Hier habe ich einmal die Wunschtemperatur erhöht, damit auch was passiert:

2014-04-09 09:35:11 CUL_HM KH_Bad_Therm CMDs_pending
2014-04-09 09:35:11 CUL_HM KH_Bad_Therm_Climate set_desired-temp 18.0
2014-04-09 09:35:11 CUL_HM KH_Bad_Therm CMDs_done

Bei mir ist es so, das der SwitchTr Kanal nur mit dem gepeerten Device spricht, hier ein HM-LC-SW1-FM:

2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung trig_KH_Bad_Therm_SwitchTr: 200
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung trigLast: KH_Bad_Therm_SwitchTr :200

Der hat auch prompt reagiert und die Heizung eingeschaltet:

2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung level: 100
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung pct: 100
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung deviceMsg: on (to KH_Bad_Therm)
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung on
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung timedOn: off

und noch ein wenig Geplauder der vorhandenen Kanäle:

2014-04-09 09:36:39 CUL_HM KH_Bad_Therm_Climate measured-temp: 16.0
2014-04-09 09:36:39 CUL_HM KH_Bad_Therm_Climate desired-temp: 18.0
2014-04-09 09:36:39 CUL_HM KH_Bad_Therm_Climate humidity: 50
2014-04-09 09:36:39 CUL_HM KH_Bad_Therm_Climate T: 16.0 desired: 18.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm battery: ok
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm batteryLevel: 3
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm measured-temp: 16.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm desired-temp: 18.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm_Climate measured-temp: 16.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm_Climate desired-temp: 18.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm_Climate mode: auto
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm_Climate T: 16.0 desired: 18.0
2014-04-09 09:36:59 CUL_HM KH_Bad_Therm_Weather temperature: 16.0
2014-04-09 09:36:59 CUL_HM KH_Bad_Therm_Weather humidity: 50
2014-04-09 09:36:59 CUL_HM KH_Bad_Therm_Weather T: 16.0 H: 50

== Firmware Update ==
Updates für den HM-TC-IT-WM-W-EU können von der eQ-3 Webseite heruntergeladen werden. Genauere Informationen gibt es unter [[HomeMatic_Firmware_Update]]. Das Thermostat wird in den Updatemodus gebracht, indem beide äußeren Tasten gedrückt werden, während die Batterien eingesetzt werden. Das Display zeigt "FUP" an.

== Bekannte Probleme ==
Bei der Firmware 1.2 und dem Kanal Climate funktioniert die Einstellung der Hysterese über das Register hyst2point nicht. Der Eintrag wird ignoriert.

Siehe auch Bericht im [http://www.elv.de/topic/hystereseeinstellung-bei-hm-tc-it-wm-w-eu-firmware-1-2-wird-ignoriert.html Forum von ELV]

== Links ==
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-TC-IT-WM-W-EU_UM_V1.0_GE_eQ-3_20131211_web.pdf Manual]
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/Funk-Wandthermostat_132030_Produktdatenblatt_V1.0.pdf Produktdatenblatt]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Feuchtesensoren]]
[[Kategorie:Temperatursensoren]]

Datei:HM-TC-IT-WM-W-EU.jpg

2016-02-15T14:35:17Z

Octo: Bild des HM-TC-IT-WM-W-EU Wandthermostats. Quelle: Benutzer:Octo (eigenes Bild)

Bild des HM-TC-IT-WM-W-EU Wandthermostats.

Quelle: [[Benutzer:Octo]] (eigenes Bild)

HM-RC-2-PBU-FM Unterputz-Wandsender

2016-02-07T20:28:36Z

Octo: /* Links */ Abschnitt hinzugefügt.

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=
|HWProtocol=BidCoS ([[HomeMatic]])
|HWType=[[HomeMatic Type Remote|remote]]
|HWCategory=[[:Kategorie:Schalter (Sender)|Schalter (Sender)]]
|HWComm=868,3 MHz
|HWChannels=2
|HWVoltage=230 V
|HWPowerConsumption=0,22 W (Ruhebetrieb)
|HWPoweredBy=Netz
|HWSize=71x71x37 mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}

Der [[HM-RC-2-PBU-FM Unterputz-Wandsender]] ist ein 2-Kanal-Sender zur Unterputz-Montage, der sich in Schalterprogramme einiger Hersteller integrieren lässt. Aus Sicht von Fhem verhält er sich wie eine [[HomeMatic Type Remote|Fernbedienung]] mit zwei Tasten.

== Links ==

* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-RC-2-PBU-FM_UM_GE_eQ-3_web.pdf Bedienungsanleitung] (PDF)

[[Kategorie:HomeMatic Components]]
[[Kategorie:Schalter (Sender)]]

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

2016-02-04T21:06:03Z

Octo: Einleitungssatz überarbeitet.

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

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

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

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

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

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

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

Aktuelle Firmware: 1.4

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

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

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

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

set <tempSensor> peerChan 0 <HM-CC-RT-DN>_Weather single

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

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

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

Der Befehl zum Peeren lautet, wobei <fensterSensor> die Fhem-Kanalbezeichnung für den Fensterkontakt ist und <rt_WindowRec> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates:
set <fensterSensor> peerChan 0 <HM-CC-RT-DN>_WindowRec single

Zum Löschen (=unpeeren) dieser Kopplung:
set <fensterSensor> peerChan 0 <HM-CC-RT-DN>_WindowRec single unset

'''Achtung''': Der Peer-(Lösch)Vorgang muss am Fensterkontakt durch Drücken der Anlerntaste bestätigt werden, und zwar auch dann, wenn der Fensterkontakt schon vorher mit Fhem gepairt wurde. Wichtig scheint auch, dass der Fensterkontakt geschlossen ist wenn man die Anlerntaste drückt.

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

==== Channel (Kanal) 04 _Clima ====
Dieser Kanal dient zum Einstellen der Betriebsparameter, auch [[#Temperaturlisten|Temperaturlisten]] sind hierauf zu übertragen.
{{Hinweis|In älteren Versionen von Fhem wurde dieser Kanal durch ''autocreate'' als <code>_ClimRT_tr</code> angelegt. Der Hersteller hat hier offenbar die internen Bezeichnungen geändert, denn beim Vorläufernmodell HM-CC-TC mussten Temperaturlisten auf den Kanal ''Climate'' übertragen werden.}}
Die maximale Öffnung des Ventils kann mittels folgendem Befehl eingestellt werden (hier auf 80 %):
set <HM-CC-RT-DN>_Clima regSet valveMaxPos 80

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

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

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

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

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

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

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

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

==== Modus Manu ====
Die Temperatur wird manuell eingestellt, das Wochenprogramm wird nicht abgearbeitet.

==== Modus Party (Urlaub) ====
Die eingestellte Temperatur gilt bis zu einem gegebenen Endzeitpunkt, anschließend wechselt das Thermostat in den ''Auto''-Modus. So kann beispielsweise bei Abwesenheit ein niedrigeres Temperaturprofil eingestellt werden ohne dass die Temperaturlisten verändert werden müssen.

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

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

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

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

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

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

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

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

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

=== Tastensperre ===

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

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

Rückgängig machen geht per:

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

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

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

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

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

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

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

eingeschaltet. Abschalten geht mit:

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

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

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

'''Burst – wie es funktioniert'''

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

'''HMLAN und burst'''

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

'''Burst devices'''

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

'''ConditionalBurst devices'''

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

'''Attribut burstAccess'''

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

'''Kommando burstXmit'''

Mit diesem Kommando, das bei Devices mit contitional-Burst zu Verfügung steht, wird der burst gezielt von User angestossen.

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

Dann sendet der User ein set burstXmit.

Es passiert das gleiche wie bei burstAccess.

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

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

''' FHEM und burst devices'''

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

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

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

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

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

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

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

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

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

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

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

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

== Simulation von Fensterkontakten und externen Temperatursensoren ==
grober Ablauf:
* erstellen ein virtuelles Device
* erstelle dazu einen virtuellen Kanal
* peeren den Kanal mit dem RT (als fenster-kontakt oder als remote, wen du willst)
* sende ein postEvent

=== Fensterkontakte ===
''Entnommen aus diesem {{Link2Forum|Topic=31078|Message=236245|LinkText=Forenbeitrag}}''
define virSC CUL_HM 221133
attr virSC autoReadReg 4_reqStatus
attr virSC expert 2_full
attr virSC model virtual_1
attr virSC peerIDs
attr virSC subType virtual
attr virSC webCmd press short:press long

define virtualKitchenDoor CUL_HM 22113301
attr virtualKitchenDoor dummy 1
attr virtualKitchenDoor expert 1
attr virtualKitchenDoor group Virtual
attr virtualKitchenDoor model virtual_1
attr virtualKitchenDoor webCmd postEvent open:postEvent closed

Anschließend peeren und Temperatur festlegen mit:
set virtualKitchenDoor peerChan 0 <Thermostat_Window_Rec> single set
set <Thermostat_Window_Rec> regSet winOpnTemp 5 virtualKitchenDoor

Die virtuelle Tür wird dann dann entsprechend über ein Notify getriggert:
define notify_virtualKitchenDoor notify (Fensterkontakt_1|Fensterkontakt_2) {if(Value("Fensterkontakt") eq "open" && Value("Fensterkontakt_2") eq "open"){fhem("set virtualKitchenDoor postEvent open")}else{fhem("set virtualKitchenDoor postEvent closed")}}

=== Temperatursensoren ===
''Entnommen aus diesem {{Link2Forum|Topic=19686|Message=233788|LinkText=Forenbeitrag}}''

1. Virtuelles HomeMatic Device mit _deiner_ HM Id definieren:
define wz_vT CUL_HM <hmId>

2. Dem Device einen virtuellen Kanal (Default ist ein virtueller Button) hinzufügen:
set wz_vT virtual 1

3. Es ist kein virtueller Button sondern ein virtueller Temperatursensor - darum rename:
rename wz_vT_Btn1 wz_vT_Sensor1

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

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

6. Gemessene Temperatur vom z.B. 1-Wire DS1820 dem virtuellen HM Sensor übergeben. Z.B. alle zwei Minuten per at:
define at_wz_vT at +*00:02 { my $T=(ReadingsVal("<DS1820B>","temperature",20.0)); fhem "set wz_vT_Sensor1 virtTemp $T" }

Fertig.

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

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

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

== Links ==
* [http://www.eq-3.de/produkt-detail-aktoren/items/homematic-funk-heizkoerperthermostat.html Produktinfo]
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-CC-RT-DN_UM_GE_eQ-3_web.pdf Bedienungsanleitung (PDF)]
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/Funk-Heizkoerperthermostat_105155_Produktdatenblatt_V2.2.pdf Datenblatt (PDF)]
* [http://www.eq-3.de/Downloads/eq3/downloads/Ventilkompatibilitaeten.pdf Ventil-Kompatibilitätsliste (PDF)]
* {{Link2Forum|Topic=14738|LinkText=Forenthema zum Thermostat}}

[[Kategorie:HomeMatic Components]]
[[Kategorie:Heizungsventile]]

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

2016-02-04T21:01:09Z

Octo: /* Vorbemerkungen */ Überarbeitet.

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

|HWManufacturer=ELV / eQ-3
}}
'''HM-CC-RT-DN''' ist ein '''Funk-Heizkörperthermostate mit integriertem Stellantrieb''', der als Nachfolger den [[HM-CC-VD]] ablöst und seit Mitte September 2013 verfügbar ist.

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

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

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

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

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

Aktuelle Firmware: 1.4

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

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

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

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

set <tempSensor> peerChan 0 <HM-CC-RT-DN>_Weather single

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

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

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

Der Befehl zum Peeren lautet, wobei <fensterSensor> die Fhem-Kanalbezeichnung für den Fensterkontakt ist und <rt_WindowRec> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates:
set <fensterSensor> peerChan 0 <HM-CC-RT-DN>_WindowRec single

Zum Löschen (=unpeeren) dieser Kopplung:
set <fensterSensor> peerChan 0 <HM-CC-RT-DN>_WindowRec single unset

'''Achtung''': Der Peer-(Lösch)Vorgang muss am Fensterkontakt durch Drücken der Anlerntaste bestätigt werden, und zwar auch dann, wenn der Fensterkontakt schon vorher mit Fhem gepairt wurde. Wichtig scheint auch, dass der Fensterkontakt geschlossen ist wenn man die Anlerntaste drückt.

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

==== Channel (Kanal) 04 _Clima ====
Dieser Kanal dient zum Einstellen der Betriebsparameter, auch [[#Temperaturlisten|Temperaturlisten]] sind hierauf zu übertragen.
{{Hinweis|In älteren Versionen von Fhem wurde dieser Kanal durch ''autocreate'' als <code>_ClimRT_tr</code> angelegt. Der Hersteller hat hier offenbar die internen Bezeichnungen geändert, denn beim Vorläufernmodell HM-CC-TC mussten Temperaturlisten auf den Kanal ''Climate'' übertragen werden.}}
Die maximale Öffnung des Ventils kann mittels folgendem Befehl eingestellt werden (hier auf 80 %):
set <HM-CC-RT-DN>_Clima regSet valveMaxPos 80

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

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

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

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

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

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

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

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

==== Modus Manu ====
Die Temperatur wird manuell eingestellt, das Wochenprogramm wird nicht abgearbeitet.

==== Modus Party (Urlaub) ====
Die eingestellte Temperatur gilt bis zu einem gegebenen Endzeitpunkt, anschließend wechselt das Thermostat in den ''Auto''-Modus. So kann beispielsweise bei Abwesenheit ein niedrigeres Temperaturprofil eingestellt werden ohne dass die Temperaturlisten verändert werden müssen.

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

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

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

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

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

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

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

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

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

=== Tastensperre ===

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

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

Rückgängig machen geht per:

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

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

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

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

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

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

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

eingeschaltet. Abschalten geht mit:

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

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

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

'''Burst – wie es funktioniert'''

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

'''HMLAN und burst'''

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

'''Burst devices'''

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

'''ConditionalBurst devices'''

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

'''Attribut burstAccess'''

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

'''Kommando burstXmit'''

Mit diesem Kommando, das bei Devices mit contitional-Burst zu Verfügung steht, wird der burst gezielt von User angestossen.

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

Dann sendet der User ein set burstXmit.

Es passiert das gleiche wie bei burstAccess.

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

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

''' FHEM und burst devices'''

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

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

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

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

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

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

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

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

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

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

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

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

== Simulation von Fensterkontakten und externen Temperatursensoren ==
grober Ablauf:
* erstellen ein virtuelles Device
* erstelle dazu einen virtuellen Kanal
* peeren den Kanal mit dem RT (als fenster-kontakt oder als remote, wen du willst)
* sende ein postEvent

=== Fensterkontakte ===
''Entnommen aus diesem {{Link2Forum|Topic=31078|Message=236245|LinkText=Forenbeitrag}}''
define virSC CUL_HM 221133
attr virSC autoReadReg 4_reqStatus
attr virSC expert 2_full
attr virSC model virtual_1
attr virSC peerIDs
attr virSC subType virtual
attr virSC webCmd press short:press long

define virtualKitchenDoor CUL_HM 22113301
attr virtualKitchenDoor dummy 1
attr virtualKitchenDoor expert 1
attr virtualKitchenDoor group Virtual
attr virtualKitchenDoor model virtual_1
attr virtualKitchenDoor webCmd postEvent open:postEvent closed

Anschließend peeren und Temperatur festlegen mit:
set virtualKitchenDoor peerChan 0 <Thermostat_Window_Rec> single set
set <Thermostat_Window_Rec> regSet winOpnTemp 5 virtualKitchenDoor

Die virtuelle Tür wird dann dann entsprechend über ein Notify getriggert:
define notify_virtualKitchenDoor notify (Fensterkontakt_1|Fensterkontakt_2) {if(Value("Fensterkontakt") eq "open" && Value("Fensterkontakt_2") eq "open"){fhem("set virtualKitchenDoor postEvent open")}else{fhem("set virtualKitchenDoor postEvent closed")}}

=== Temperatursensoren ===
''Entnommen aus diesem {{Link2Forum|Topic=19686|Message=233788|LinkText=Forenbeitrag}}''

1. Virtuelles HomeMatic Device mit _deiner_ HM Id definieren:
define wz_vT CUL_HM <hmId>

2. Dem Device einen virtuellen Kanal (Default ist ein virtueller Button) hinzufügen:
set wz_vT virtual 1

3. Es ist kein virtueller Button sondern ein virtueller Temperatursensor - darum rename:
rename wz_vT_Btn1 wz_vT_Sensor1

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

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

6. Gemessene Temperatur vom z.B. 1-Wire DS1820 dem virtuellen HM Sensor übergeben. Z.B. alle zwei Minuten per at:
define at_wz_vT at +*00:02 { my $T=(ReadingsVal("<DS1820B>","temperature",20.0)); fhem "set wz_vT_Sensor1 virtTemp $T" }

Fertig.

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

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

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

== Links ==
* [http://www.eq-3.de/produkt-detail-aktoren/items/homematic-funk-heizkoerperthermostat.html Produktinfo]
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-CC-RT-DN_UM_GE_eQ-3_web.pdf Bedienungsanleitung (PDF)]
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/Funk-Heizkoerperthermostat_105155_Produktdatenblatt_V2.2.pdf Datenblatt (PDF)]
* [http://www.eq-3.de/Downloads/eq3/downloads/Ventilkompatibilitaeten.pdf Ventil-Kompatibilitätsliste (PDF)]
* {{Link2Forum|Topic=14738|LinkText=Forenthema zum Thermostat}}

[[Kategorie:HomeMatic Components]]
[[Kategorie:Heizungsventile]]

HomeMatic HMInfo TempList/Weekplan

2016-02-04T20:48:49Z

Octo: /* Erstellen des ersten Files */ Überarbeitet.

{{Todo|Dieser Artikel überschneidet sich inhaltlich mit [[HomeMatic Type Thermostat#Templates]].}}
{{Infobox Modul
|ModPurpose=Behandlung von Wochenplänen für Thermostate
|ModType=d
|ModCmdRef=HMinfo Weekplan
|ModForumArea=HomeMatic
|ModTechName=98_HMinfo.pm
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])
}}

'''HMInfo TempList''' ist eine Funktion des Moduls [[Homematic_HMInfo|HMInfo]] das es erlaubt Temperaturlisten (Wochenpläne) von [[HomeMatic Type Thermostat|Thermostaten]] zu Verwalten.

== Einleitung==
Homematic bietet eine Reihe von Heizkörperthermostaten welche mit einem Wochenplan eigenständig einen Automatikmode unterstützen. Die Erstellung und Verwaltung dieser Pläne ist im Device zumindest umständlich.
Wochenpläne werden in den Devices gespeichert und können über FHEM abgefragt werden.
== Begriffe==
Wir müssen strikt 3 Wochenpläne unterscheiden:
* ''activeList'' Wochenplan im Device. Dieser, und nur dieser ist '''wirksam'''. Er kann nicht direkt in FHEM dargestellt werden. FHEM muss die Daten auslesen um sie verarbeiten zu können. Siehe hierzu kommandos und attribute des Device:getConfig und autoReagReg.
* ''referenceList'' Wochenplan in FHEM. Für jedes Device wird ein Wochenplan (bei einigen Devices können es sogar mehrere sein) dargestellt. Dies ist die aus dem Device gelesene activeList. Es liegt in der Verantwortung des User, die Liste aktuell zu halten.
* ''tempTemplates'' Vorlagen für Wochenpläne. Diese werden in Files erstellt. Man kann Devices eines der tempTemplates zuweisen um es zu prüfen oder einzuspielen.

== Wochenplan Files==
=== Mögliche Files===
tempListTemplates werden immer in Files verwaltet. Man kann Templates in mehreren Files verwalten. Ferner gibt es unterschiedliche Methoden, ein File zu spezifizieren.
* '''attr tempListTmpl im Device''': hier spezifiziert man das Template. Will man sich von tempaltes entkoppeln sollte man '''tempListTmpl none''' unbedingt setzen.
** '''Wohnzimmer''': das template '''Wohnzimmer''' wird im default File gesucht
** '''myWeekplan.cfg:Wohnzimmer''': das template '''Wohnzimmer''' wird im File ''myWeekplan.cfg'' mit relativen Pfad von FHEM home gesucht
** '''./setup/myWeekplan.cfg:Wohnzimmer''': das template '''Wohnzimmer''' wird im File ''myWeekplan.cfg'' mit relativen Pfad ''./setup'' gesucht
** '''/opt/fhem/myWeekplan.cfg:Wohnzimmer''': das template '''Wohnzimmer''' wird im File ''myWeekplan.cfg'' mit absoluten Pfad ''/opt/fhem/'' gesucht
* '''attr configTempFile in HMInfo''': spezifiziert weekplan configurationsfiles. Es ist eine Liste Wochenplan Files welche genutzt werden. Ist das Attribut nicht gesetzt wird als ''default tempList.cfg'' genutzt.
** '''attr hm configTempFile myWeekPlan.cfg''': FHEM kennt ein File mit Wochenplan. Dies ist auch das Default für alle tempListTmpl in denen kein File spezifiziert.
** '''attr hm configTempFile mySummerPlan.cfg,myWinterPlan.cfg,myPartyPlan.cfg''': FHEM sind 3 Files bekannt. Der erste Eintrag ''mySummerPlan.cfg'' ist der Default für tempListTmpl .
* '''attr configDir in HMInfo''': spezifiziert einen Pfad, der ''auch'' für configTemplFile genutzt wird. Es erleichtert Konfigurations-Dateien in einem separaten Verzeichnis anzulegen. ''attr hm configDir setup'' wäre ein sinnvoller Eintrag. Das Verzeichnis ''setup'' unter fhem sollte erstellt werden. Ist das Attribut nicht gesetzt ist fhemHome der default.

=== Der File Inhalt - Syntax ===
entities:HK1,HK2
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
R_1_tempListSun>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
R_2_tempListMon>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_3_tempListTue>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 15.0
R_4_tempListWed>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_5_tempListThu>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_6_tempListFri>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 14.0
entities:HK3
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
R_1_tempListSun>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
R_2_tempListMon>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_3_tempListTue>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 15.0
R_4_tempListWed>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_5_tempListThu>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_6_tempListFri>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 14.0

* '''entities''': ist der Name des Wochenplans. Eine Liste kann mehrere Namen haben, welche mit Komma separiert werden.
** ein Name darf in einem File '''nicht''' doppelt vorkommen.
** der gleiche Name darf in unterschiedlichen File genutzt werden.
* '''R_0_tempListSat>''': sind die Einträge je Wochentag. Es muss ein Eintrag je Wochentag vorhanden sein.
* '''08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0''': gemäß homematic syntax fängt der Plan immer um 00:00Uhr an. Das erste Paar 08:00 14.0 bedeuted, dass von 00:00 bis 08:00 eine Temperatur von 14.0 eingestellt werden soll. 15:00 18.0 bedeuted das von 08:00 bis 15:00 18.0 Grad einzustellen sind
** es sind immer Paare einzutragen
** der Beginn um 00:00 ist nicht einzutragen
** der Letzte Eintrag '''muss''' 24:00 an jeden Tag sein
** Uhrzeiten sind auf halbe Stunden beschränkt. Einträge 08:00 und 08:30 sind gültig. 08:20 ist ungültig.
==== Erstellen des ersten Files====

Um nicht auf der grünen Wiese beginnen zu müssen empfiehlt es sich den aktuellen Ist-Zustand ''(referenceList)'' mit <code>save</code> in eine Datei zu schreiben. Vorab sollten die HMInfo-Attribute <code>configDir</code> und <code>configTempFile</code> gesetzt sein.

attr <HMInfo> configDir setup
attr <HMInfo> configTempFile myWeekplan.cfg
set <HMInfo> tempList save

Der letzte Befehl speichert die ''referenceList'' jedes Gerätz in der Datei <code>setup/myWeekplan.cfg</code>. Als ''Entity'' wird der Name des Thermostats verwendet – das Attribut ''tempListTmpl'' wird nicht beachtet.

Die Datei kann anschließend mit einem Text-Editor bearbeitet werden. Wochenpläne können zusammengefasst und verändert werden.

=== HMInfo Kommandos ===

Die HMInfo-Befehle, die Temperaturlisten verwalten, folgen dem Schema:

set <HMInfo> tempList <Befehl>

Die verfügbaren Befehle sind:

; <code>save</code>
: Speichert den aktuellen Zustand der Thermostate (''referenceList'') in der ''tempList''-Datei ab.
; <code>verify</code>
: Vergleicht den Ist-Zustand (''referenceList'') mit dem Soll-Zustand (dem Wochenplan aus dem ''tempListTmpl''-Attribut). Abweichungen werden angezeigt aber nicht behoben. Diese Prüfung ist auch Teil von HMInfos <code>configCheck</code>.
; <code>restore</code>
: Stellt den Soll-Zustand wieder her. Funktioniert im Prinzip wie <code>verify</code>, jedoch werden alle Abweichungen vom Soll-Zustand korrigiert. Zu beachten ist die Verzögerung beim Schreiben (siehe [[HomeMatic HMInfo#protoEvents|HMInfo protoEvents]], Device Status und Beschreibung des Device) und dass nach dem Schreiben die ''referenceList'' neu geladen werden muss. Wir empfehlen <code>autoReadReg</code> auf Level 5 zu setzen. Ein Restore kann jederzeit ausgeführt werden. Sind alle Daten aktuell wird ''keine'' Temperaturliste geschrieben; es erfolgt keinerlei Funkverkehr.
; <code>status</code>
: Gibt eine Übersicht über die genutzten Templates aus.

Das Web-Frontend verwendet den nahezu identischen Befehl <code>tempListG</code>. Da dieser Befehl keine weiteren Argumente zulässt kann das Frontend ein Pulldown-Menü anzeigen. Das "G" steht für "Global" – da keine Filter unterstützt werden wirken alle Befehle auf alle HomeMatic-Geräte.

==Nutzungsbeispiele==
=== Mehrere Heizkörper in einem Raum===
Wenn sich in einem Raum mehrere Heizkörperthermostate befinden, sollten diese – wie in [[HM-CC-RT-DN]] beschrieben – gepeert werden.
HomeMatic geht davon aus, dass alle HM-CC-RT-DNs den selben Wochenplan haben (gilt ggf. auch für einen zugehörigen [[HM-TC-IT-WM-W-EU]]).

Um dies zu erreichen definiert man einen Wochenplan für das Zimmer, beispielsweise <code>Wohnzimmer.cfg</code>. Anschließend wird dieser Wochenplan allen Teammitgliedern zugewiesen:

attr <HM-CC-RT-DN#1>_Clima tempListTmpl Wohnzimmer
attr <HM-CC-RT-DN#2>_Clima tempListTmpl Wohnzimmer
attr <HM-CC-RT-DN#3>_Clima tempListTmpl Wohnzimmer
attr <HM-TC-IT-WM-W-EU>_Climate tempListTmpl Wohnzimmer
set hm tempListG restore

=== Mehrere Heizkörper mit gleichen Profil===
Will man Wohnräume identisch behandeln im Hinblick auf den Wochenplan weisst man den Thermostaten identische Profile zu.

attr RTSusi_Clima tempListTmpl Kinderzimmer
attr RTjonas_Clima tempListTmpl Kinderzimmer
attr RTwohnzimmer_Clima tempListTmpl Kinderzimmer
set hm tempListG restore
=== Wohnungsnutzung umschalten===
Das Heizprofil kann man Zentral umstellen. Verlässt man die Wohnung zum Urlaub, der Sommer naht, man macht die üblich 3-Woche Party... . Alle Thermostate sollen umgestellt werden, zentral mit wenigen Kommandos, einfach zu prüfen. Sinnvoll ist es mehrere tempList.cfg Files anzulegen. Nehmen wir 4 Files an, Winter, Urlaub zu hause UrlaubIn, Urlaub nicht zu hause UrlaubOut sowie Sommer. Ferner hat man (der Einfachheit halber) 3 RTs: RTwohn, RTschlaf, RTkueche.
Die RTs haben jeweils ihr attr tempListTmpl gesetzt entsprechend ihrem Namen.
Man legt also die 4 Files an mit entities die man zusammenfassen kann (templisten muss man natürlich befüllen:
File Winter.cfg
entity: RTwohn
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...
entity: RTschlaf
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...
entity: RTkueche
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...

File UrlaubIn.cfg
entity: RTwohn,RTkueche
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...
entity: RTschlaf
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...

File UrlaubOut.cfg
entity: RTwohn,RTschlaf,RTkueche
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...

File Sommer.cfg
entity: RTwohn,RTschlaf,RTkueche
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...

In HMInfo sollte man nun verwalten:
attr RTwohn_Clima tempListTmpl RTwohn
attr RTkueche_Clima tempListTmpl RTkueche
attr RTschlaf_Clima tempListTmpl RTschlaf
attr hm configTempFile Winter.cfg,Sommer.cfg,UrlaubIn.cfg,UrlaubOut.cfg

Winter.cfg ist nun default. Mit set hm tempListG verify kann man prüfen, dass es entsprechend genutzt ist. Nun will man in Urlaub fahren. Man schaltet das Default durch umstellen der Reihenfolge um und aktiviert es durch ein restore:
attr hm configTempFile UrlaubOut.cfg,Winter.cfg,Sommer.cfg,UrlaubIn.cfg
set hm tempListG restore

UrlaubOut.cfg ist default. Alle notwendigen Änderungen werden in die RTs programmiert.
Unberührt bleibt Opas Zimmer, der nicht das default file sondern ein dediziertes nutzt.

attr RTopa_Clima tempListTmpl Winter.cfg:RTopa

Das template RTopa muss also nur im File Winter.cfg vorhanden sein:

[[Kategorie:HomeMatic Components]]
[[Kategorie:HOWTOS]]

HomeMatic HMInfo TempList/Weekplan

2016-02-04T20:41:40Z

Octo: /* HMInfo Kommandos */ Abschnitt überarbeitet.

{{Todo|Dieser Artikel überschneidet sich inhaltlich mit [[HomeMatic Type Thermostat#Templates]].}}
{{Infobox Modul
|ModPurpose=Behandlung von Wochenplänen für Thermostate
|ModType=d
|ModCmdRef=HMinfo Weekplan
|ModForumArea=HomeMatic
|ModTechName=98_HMinfo.pm
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])
}}

'''HMInfo TempList''' ist eine Funktion des Moduls [[Homematic_HMInfo|HMInfo]] das es erlaubt Temperaturlisten (Wochenpläne) von [[HomeMatic Type Thermostat|Thermostaten]] zu Verwalten.

== Einleitung==
Homematic bietet eine Reihe von Heizkörperthermostaten welche mit einem Wochenplan eigenständig einen Automatikmode unterstützen. Die Erstellung und Verwaltung dieser Pläne ist im Device zumindest umständlich.
Wochenpläne werden in den Devices gespeichert und können über FHEM abgefragt werden.
== Begriffe==
Wir müssen strikt 3 Wochenpläne unterscheiden:
* ''activeList'' Wochenplan im Device. Dieser, und nur dieser ist '''wirksam'''. Er kann nicht direkt in FHEM dargestellt werden. FHEM muss die Daten auslesen um sie verarbeiten zu können. Siehe hierzu kommandos und attribute des Device:getConfig und autoReagReg.
* ''referenceList'' Wochenplan in FHEM. Für jedes Device wird ein Wochenplan (bei einigen Devices können es sogar mehrere sein) dargestellt. Dies ist die aus dem Device gelesene activeList. Es liegt in der Verantwortung des User, die Liste aktuell zu halten.
* ''tempTemplates'' Vorlagen für Wochenpläne. Diese werden in Files erstellt. Man kann Devices eines der tempTemplates zuweisen um es zu prüfen oder einzuspielen.

== Wochenplan Files==
=== Mögliche Files===
tempListTemplates werden immer in Files verwaltet. Man kann Templates in mehreren Files verwalten. Ferner gibt es unterschiedliche Methoden, ein File zu spezifizieren.
* '''attr tempListTmpl im Device''': hier spezifiziert man das Template. Will man sich von tempaltes entkoppeln sollte man '''tempListTmpl none''' unbedingt setzen.
** '''Wohnzimmer''': das template '''Wohnzimmer''' wird im default File gesucht
** '''myWeekplan.cfg:Wohnzimmer''': das template '''Wohnzimmer''' wird im File ''myWeekplan.cfg'' mit relativen Pfad von FHEM home gesucht
** '''./setup/myWeekplan.cfg:Wohnzimmer''': das template '''Wohnzimmer''' wird im File ''myWeekplan.cfg'' mit relativen Pfad ''./setup'' gesucht
** '''/opt/fhem/myWeekplan.cfg:Wohnzimmer''': das template '''Wohnzimmer''' wird im File ''myWeekplan.cfg'' mit absoluten Pfad ''/opt/fhem/'' gesucht
* '''attr configTempFile in HMInfo''': spezifiziert weekplan configurationsfiles. Es ist eine Liste Wochenplan Files welche genutzt werden. Ist das Attribut nicht gesetzt wird als ''default tempList.cfg'' genutzt.
** '''attr hm configTempFile myWeekPlan.cfg''': FHEM kennt ein File mit Wochenplan. Dies ist auch das Default für alle tempListTmpl in denen kein File spezifiziert.
** '''attr hm configTempFile mySummerPlan.cfg,myWinterPlan.cfg,myPartyPlan.cfg''': FHEM sind 3 Files bekannt. Der erste Eintrag ''mySummerPlan.cfg'' ist der Default für tempListTmpl .
* '''attr configDir in HMInfo''': spezifiziert einen Pfad, der ''auch'' für configTemplFile genutzt wird. Es erleichtert Konfigurations-Dateien in einem separaten Verzeichnis anzulegen. ''attr hm configDir setup'' wäre ein sinnvoller Eintrag. Das Verzeichnis ''setup'' unter fhem sollte erstellt werden. Ist das Attribut nicht gesetzt ist fhemHome der default.

=== Der File Inhalt - Syntax ===
entities:HK1,HK2
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
R_1_tempListSun>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
R_2_tempListMon>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_3_tempListTue>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 15.0
R_4_tempListWed>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_5_tempListThu>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_6_tempListFri>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 14.0
entities:HK3
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
R_1_tempListSun>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
R_2_tempListMon>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_3_tempListTue>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 15.0
R_4_tempListWed>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_5_tempListThu>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_6_tempListFri>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 14.0

* '''entities''': ist der Name des Wochenplans. Eine Liste kann mehrere Namen haben, welche mit Komma separiert werden.
** ein Name darf in einem File '''nicht''' doppelt vorkommen.
** der gleiche Name darf in unterschiedlichen File genutzt werden.
* '''R_0_tempListSat>''': sind die Einträge je Wochentag. Es muss ein Eintrag je Wochentag vorhanden sein.
* '''08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0''': gemäß homematic syntax fängt der Plan immer um 00:00Uhr an. Das erste Paar 08:00 14.0 bedeuted, dass von 00:00 bis 08:00 eine Temperatur von 14.0 eingestellt werden soll. 15:00 18.0 bedeuted das von 08:00 bis 15:00 18.0 Grad einzustellen sind
** es sind immer Paare einzutragen
** der Beginn um 00:00 ist nicht einzutragen
** der Letzte Eintrag '''muss''' 24:00 an jeden Tag sein
** Uhrzeiten sind auf halbe Stunden beschränkt. Einträge 08:00 und 08:30 sind gültig. 08:20 ist ungültig.
==== Erstellen des ersten Files====
Hat man HMInfo eingerichtet kann man alle ''referenceList'' in das File schreiben und dann mit der Bearbeitung beginnen. Vorab sollte man '''nach Wunsch''' folgendes einstellen:
attr hm configDir setup
attr hm configTempFile myWeekplan.cfg
set hm tempListG save

* '''set hm tempListG save''': es wird für jedes Device die ''referenceList'' in das File angehängt. Entity ist der Name des Thermostats. Das Attribut tempListTmpl ist hierbei nicht relevant.
Das File kann nun mit einem Editor bearbeitet werden. Wochenpläne können zusammengefasst und verändert werden.

=== HMInfo Kommandos ===

Die HMInfo-Befehle, die Temperaturlisten verwalten, folgen dem Schema:

set <HMInfo> tempList <Befehl>

Die verfügbaren Befehle sind:

; <code>save</code>
: Speichert den aktuellen Zustand der Thermostate (''referenceList'') in der ''tempList''-Datei ab.
; <code>verify</code>
: Vergleicht den Ist-Zustand (''referenceList'') mit dem Soll-Zustand (dem Wochenplan aus dem ''tempListTmpl''-Attribut). Abweichungen werden angezeigt aber nicht behoben. Diese Prüfung ist auch Teil von HMInfos <code>configCheck</code>.
; <code>restore</code>
: Stellt den Soll-Zustand wieder her. Funktioniert im Prinzip wie <code>verify</code>, jedoch werden alle Abweichungen vom Soll-Zustand korrigiert. Zu beachten ist die Verzögerung beim Schreiben (siehe [[HomeMatic HMInfo#protoEvents|HMInfo protoEvents]], Device Status und Beschreibung des Device) und dass nach dem Schreiben die ''referenceList'' neu geladen werden muss. Wir empfehlen <code>autoReadReg</code> auf Level 5 zu setzen. Ein Restore kann jederzeit ausgeführt werden. Sind alle Daten aktuell wird ''keine'' Temperaturliste geschrieben; es erfolgt keinerlei Funkverkehr.
; <code>status</code>
: Gibt eine Übersicht über die genutzten Templates aus.

Das Web-Frontend verwendet den nahezu identischen Befehl <code>tempListG</code>. Da dieser Befehl keine weiteren Argumente zulässt kann das Frontend ein Pulldown-Menü anzeigen. Das "G" steht für "Global" – da keine Filter unterstützt werden wirken alle Befehle auf alle HomeMatic-Geräte.

==Nutzungsbeispiele==
=== Mehrere Heizkörper in einem Raum===
Wenn sich in einem Raum mehrere Heizkörperthermostate befinden, sollten diese – wie in [[HM-CC-RT-DN]] beschrieben – gepeert werden.
HomeMatic geht davon aus, dass alle HM-CC-RT-DNs den selben Wochenplan haben (gilt ggf. auch für einen zugehörigen [[HM-TC-IT-WM-W-EU]]).

Um dies zu erreichen definiert man einen Wochenplan für das Zimmer, beispielsweise <code>Wohnzimmer.cfg</code>. Anschließend wird dieser Wochenplan allen Teammitgliedern zugewiesen:

attr <HM-CC-RT-DN#1>_Clima tempListTmpl Wohnzimmer
attr <HM-CC-RT-DN#2>_Clima tempListTmpl Wohnzimmer
attr <HM-CC-RT-DN#3>_Clima tempListTmpl Wohnzimmer
attr <HM-TC-IT-WM-W-EU>_Climate tempListTmpl Wohnzimmer
set hm tempListG restore

=== Mehrere Heizkörper mit gleichen Profil===
Will man Wohnräume identisch behandeln im Hinblick auf den Wochenplan weisst man den Thermostaten identische Profile zu.

attr RTSusi_Clima tempListTmpl Kinderzimmer
attr RTjonas_Clima tempListTmpl Kinderzimmer
attr RTwohnzimmer_Clima tempListTmpl Kinderzimmer
set hm tempListG restore
=== Wohnungsnutzung umschalten===
Das Heizprofil kann man Zentral umstellen. Verlässt man die Wohnung zum Urlaub, der Sommer naht, man macht die üblich 3-Woche Party... . Alle Thermostate sollen umgestellt werden, zentral mit wenigen Kommandos, einfach zu prüfen. Sinnvoll ist es mehrere tempList.cfg Files anzulegen. Nehmen wir 4 Files an, Winter, Urlaub zu hause UrlaubIn, Urlaub nicht zu hause UrlaubOut sowie Sommer. Ferner hat man (der Einfachheit halber) 3 RTs: RTwohn, RTschlaf, RTkueche.
Die RTs haben jeweils ihr attr tempListTmpl gesetzt entsprechend ihrem Namen.
Man legt also die 4 Files an mit entities die man zusammenfassen kann (templisten muss man natürlich befüllen:
File Winter.cfg
entity: RTwohn
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...
entity: RTschlaf
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...
entity: RTkueche
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...

File UrlaubIn.cfg
entity: RTwohn,RTkueche
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...
entity: RTschlaf
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...

File UrlaubOut.cfg
entity: RTwohn,RTschlaf,RTkueche
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...

File Sommer.cfg
entity: RTwohn,RTschlaf,RTkueche
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...

In HMInfo sollte man nun verwalten:
attr RTwohn_Clima tempListTmpl RTwohn
attr RTkueche_Clima tempListTmpl RTkueche
attr RTschlaf_Clima tempListTmpl RTschlaf
attr hm configTempFile Winter.cfg,Sommer.cfg,UrlaubIn.cfg,UrlaubOut.cfg

Winter.cfg ist nun default. Mit set hm tempListG verify kann man prüfen, dass es entsprechend genutzt ist. Nun will man in Urlaub fahren. Man schaltet das Default durch umstellen der Reihenfolge um und aktiviert es durch ein restore:
attr hm configTempFile UrlaubOut.cfg,Winter.cfg,Sommer.cfg,UrlaubIn.cfg
set hm tempListG restore

UrlaubOut.cfg ist default. Alle notwendigen Änderungen werden in die RTs programmiert.
Unberührt bleibt Opas Zimmer, der nicht das default file sondern ein dediziertes nutzt.

attr RTopa_Clima tempListTmpl Winter.cfg:RTopa

Das template RTopa muss also nur im File Winter.cfg vorhanden sein:

[[Kategorie:HomeMatic Components]]
[[Kategorie:HOWTOS]]

HMinfo

2016-02-04T20:35:10Z

Octo: /* protoEvents */ Grammatik und Markup verbessert.

{{Infobox Modul
|ModPurpose=Übersicht über alle HomeMatic Geräte
|ModType=h
|ModCmdRef=HMinfo
|ModForumArea=HomeMatic
|ModTechName=98_HMinfo.pm
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])
}}

'''HMInfo''' ist ein Modul, das einen Überblick über alle definierten [[HomeMatic]] Geräte gibt. Es bietet Funktionen zur Übersicht, Kontrolle, Archivierung und, begrenzt, zur Programmierung der HomeMatic Komponenten. Somit soll es eine Hilfestellung bei Konfiguration und Fehlerbehandlung geben.

== Definition ==
HMInfo wird erstellt / angelegt mit dem Befehl
:<code>define hm HMinfo</code>

Danach können alle Funktionen aufgelistet werden mit
:<code>get hm help</code>

== Integritätsprüfungen ==
Befehle, um die Gültigkeit von verschiedenen HomeMatic Eigenschaften zu überprüfen:

=== peerCheck ===
Mit dem Befehl
:<code>get hm peerCheck</code>
wird der Zustand der Peerings überprüft, d.h., ob alle Peerings auch beidseitig sind. Mögliche Meldungen, die eine Überarbeitung und/oder Korrektur von Definitionen erforderlich machen können:
;peer not verified. Check that peer is set on both sides
:ausgegebener Wert (z.B.): actorChan p:switchChan
:erforderliche Korrekturmaßnahme: ???

=== regCheck ===
Mit dem Befehl
:<code>get hm regCheck</code>
wird überprüft, ob alle Register korrekt gelesen wurden. Mögliche Meldungen:
;missing register list
:ausgegebener Wert (z.B.): <code>dev01Ch01: RegL_01: </code>
:erforderliche Korrekturmaßnahme: <code>set dev01Ch01 getConfig</code>
:oder <code>device01Ch01: .RegL_03:sensor01Ch01,.RegL_03:sensor01Ch02</code>
:erforderliche Korrekturmaßnahme: ???
;Register changes pending
:ausgegebener Wert (z.B.): <code>sensor01Ch01</code>

=== configCheck ===
Mit dem Befehl
:<code>get hm configCheck</code> werden die Befehle '''peerCheck''' und '''regCheck''' ausgeführt. Zusätzlich können noch Ergebnisse auftauchen wie
;PairedTo mismatch to IODev
:ausgegebener Wert (z.B.): <code>sensor01Ch01 paired:0x000000 IO attr: xxxxxx.</code>
:erforderliche Korrekturmaßnahme: ???

== Anzeigen zur Übertragungssituation ==
===RSSI ===
;<code>get hm rssi [<filter>]</code>
:Erzeugt eine Tabelle aller RSSI Werte.
;<code>set hm clear [<filter>] rssi</code>
:setzt die RSSI Werte aller devices gemäß filter zurück. Eine neue Messung kann beginnen

===protoEvents ===
;<code>get hm protoEvents [<filter>][short|long] </code>
:Es wird eine Tabelle mit allen wichtigen Ereignissen zur Datenübertragung erzeugt. Dies beinhaltet Wiederholungen sowie Übertragungsfehler.
<code>short</code> ist eine Fassung ohne Zeitstempel und lässt sich besser am Bildschirm darstellen.
Ausserdem kann man sehen, welche Abfragen noch in der Queue sind, z.B. durch <code>autoReadReg</code> erzeugt.
Die Zustände aller für HM zuständigen IOs sind beinhaltet.
Alles in allem ist hier ein kompletter Überblick zur Kommunikation zu sehen. Der Befehl
set hm clear [<filter>] Protocol
setzt die Protokoleinträge aller HomeMatic-Geräte gemäß Filter zurück. Das kann gut vor einer Konfigurationsaktion genutzt werden um zu kontrollieren, ob Fehler aufgetreten sind.

===msgStat===
;<code>set hm msgStat </code>
:Statistic der Übertragenen Messages insgesamt. Es gibt eine Tabelle über die letzten 24h und eine über die letzte Woche.

== Speichern von Konfigurationen==
HMInfo speichert Konfigurationen der Geräte in Files. Mit dem Attribut configDir kann man ein Verzeichnis festlegen, in das alles geschrieben wird.

=== saveConfig===
Peers und Register werden in eine Datei geschrieben. Die Daten kann man ggf. wieder in ein Gerät oder ein Austauschgerät schreiben. Die Speicherung erfolgt kumulativ, man kann alles in eine Datei schreiben.
:<code>set hm saveConfig [<filter>] [<file>] </code>

=== archConfig ===
Arbeitet prinzipiell wie saveConfig. Es werden jedoch nur vollständige Registersätze gespeichert, was einen höheren Level an Sicherheit der Dateninhalte gewährt.
:<code>set hm archConfig [-a] [<file>] </code>
Mit dem '''Attribut autoArchive''' kann man einstellen, dass automatisch nach erfolgreichem Lesen einer Device-Konfiguration diese archiviert wird.
Das Speichern erfolgt kumulativ. Ab einer Dateigröße von 1MB wird gepurged, also alles bis auf den neusten Eintrag jeder Entity gelöscht.

Um eine Konfiguration zu sichern, sollte eine Kopie des Archivs gemacht werden. Das Archiv wird bei Gelegenheit überschrieben.

Template erstellen:
:<code>set hm saveConfig -f ^meinDevice$ <myTempalteFile> </code>

=== loadConfig ===
;<code>set hm loadConfig [<filter>] [<filename>] </code>
:Liest die Registerwerte, die für eine Entity in einem File gespeichert sind, zurück in die Readings. Sollten die Register schon in FHEM vorhanden sein, wird '''nicht''' überschrieben.
Sinn macht dies beispielsweise für remotes, die nicht automatisch gelesen werden sollen. Man kann somit nach einem system-reboot die Register "rekonstruieren" und wieder darstellen.
Es liegt im ermessen des User, eine bekannt aktuelle Version der Register einzulesen.

=== purgeConfig===
;<code>set hm purgeConfig [<filename>] </code>
:Löscht alle älteren Datensätze in einem File.

== Konfigurationen bearbeiten ==
=== Templates ===
HMInfo erlaubt das Erstellen und Nutzen von Templates. Das sind Schablonen, die das Setzen von Registern abstrahieren und auf eine höhere Ebene heben. So kann man das Setzen der Konfiguration eines Aktors beispielsweise um mit einem Bewegungsmelder zusammen zu arbeiten in einem Kommando zusammenfassen.
Faktisch setzt das Template also eine Gruppe von Registern auf einmal.

====templateList ====
Die vorhandenen templates kann man mit templateList sehen.
get hm templateList

SwOnCond params:level cond Info:switch: execute only if condition [geLo|ltLo] level is below limit
SwToggle params: Info:Switch: toggle on trigger
autoOff params:time Info:staircase - auto off after <time>, extend time with each trigger
motionOnDim params:ontime brightness Info:Dimmer: on for time if MDIR-brightness below level
motionOnSw params:ontime brightness Info:Switch: on for time if MDIR-brightness below level
Die Liste der verfügbaren Tempaltes, deren Parameter falls nötig und eine kurze Info, was das Template bewirken soll

get hm templateList autoOff

autoOff params:time Info:staircase - auto off after <time>, extend time with each trigger
ActionType :jmpToTarget
OffTime :111600
OnTime :time
SwJtDlyOff :dlyOn
SwJtDlyOn :no
SwJtOff :dlyOn
SwJtOn :on
Ein templateList auf ein einzelnes Template zeigt im Detail, was das Template verändern wird.

====templateSet ====
Um ein Template auf einen Aktor anzuwenden,muss man den Bereich wählen, auf den er angewendet werden soll. Je nach template kann das die Gruppe der Register zu einem Peer, zu short oder long eines Peer oder Register ohne peer sein.
set hm templateSet <entity> <templateName> <peer:[long|short]> [<param1> ...]
set hm templateSet Licht1 autoOff FB1_Btn2:short 10
set hm templateSet Licht1 SwOn FB1_Btn2:long
set hm templateSet Licht1 SwOff FB1_Btn2:short
set hm templateSet Licht1 SwOnOff FB1_Btn2:both
set hm templateSet LichtDev setHost 0
Licht1 soll, wenn ein kurzer Trigger von FB1_Btn2 kommt für 10 sec eingeschaltet werden, dann ausgehen (Treppenhausfunktion). Kommt aber ein langer Tastendruck wird das Licht dauerhaft eingeschaltet.
set hm templateSet Licht1 motionOnSw MD1:short 30 20
Der Switch Aktor Licht1 soll mit einem Bewegungsmelder betrieben werden. Der Bewegungsmelder sendet keine 'langen' Trigger sondern nur kurze. Im Beispiel wird Licht1 für 30 Sekunden eingeschaltet, wenn der Bewegungsmelder einen Trigger sendet UND es dunkler ist als "20" (Brightness level).

====templateDef ====
Neben den vorbereiteten Templates kann der User eigene definieren oder von anderen Usern sich Templates geben lassen. Die Definition von Templates ist für erfahrene User gedacht, im Gegensatz zur Nutzung eines Templates mit set - das ist für Anfänger gedacht. Man kann sein template manuell definieren oder ein bekanntes Device als Muster nutzen (fromMaster). Ein Template kann nur Gruppen von Registern setzen, nicht alle Register eines Device. Um die Gruppen anzusprechen muss man "peer" wie folgt setzen:
0 Register ohne peer
<peer>:both Register eines peers
<peer>:short Register eines peers nur Short
<peer>:long Register eines peers nur Long
setzen.
Man kann das template "dynamisch" gestalten, indem man einzelne Register beim templateSet übergibt.
Erst einmal statische Templates. Param ist hier "0"

set hm templateDef <templateName> <param1[:<param2>...] <description> <reg1>:<val1> [<reg2>:<val2>] ...

set hm templateDef t1 0 "TP1" OnTime:10 OffTime:20 OnDly:0

set hm templateDef t1 fromMaster <entity> 0
set hm templateDef t2 fromMaster <entity> <peer>:both
set hm templateDef t3 fromMaster <entity> <peer>:short
set hm templateDef t4 fromMaster <entity> <peer>:long

set hm templateDef t4 fromMaster LichtWz remoteBtn1:long

Dynamische templates haben eine Parameterliste (bis zu 9) <param1[:<param2>...]. Diese werden als p0 bis p8 genutzt - der Name ist dabei egal, er dient dem User also Hilfe beim templateList

set hm templateDef myTemplate anzeit:auszeit "licht schaltet ständig an und aus" OnTime:p0 OffTime:p1 OnDly:0

set hm templateDef myAutoOff AnZeit "treppenhausschalter" ActionType:jmpToTarget OffTime:unused OnTime:p0 SwJtDlyOff:dlyOn SwJtDlyOn:no SwJtOff:dlyOn SwJtOn:on

Die "Anzeit" ist der erste Parameter, also p0. Der Wert, den man bei Set einträgt wird in OnTime geschrieben. OnTime:p0

Beim Definieren eines Templates wird die Registergültigkeit nicht geprüft. Das kommt beim Set.

====templateChk ====
Template definitionen und zuweisungen (set) kann man mit
set hm archConfig
speichern und mit
set hm loadConfig
mach einem reboot laden. Welche templates einer entity zugewiesen sind kann man mit
attr <entity> expert 12
in den Readings sichtbar machen. Siehe auch templateUsg.

Man kann prüfen, ob ein Aktor/Peer gemäss einem Template programmiert ist. Sinnvoll ist eine komplette Prüfung aller zugewiesenen templates. Man kann aber auch filtern.
get hm templateChk
get hm templateChk [<filter>]
get hm templateChk [<filter>] <templateName> <peer:[long|short]> [<param1> ...]
get hm templateChk -f Rollo RolloHoch self01 5
Es wird geprüft für alle HM-Komponenten, die "Rollo" im Namen haben (siehe [[Homematic HMInfo#Filter|Filter]]) dem (hoffentlich vorhandenen) template "RolloHoch" verglichen. Geprüft wird nur der Peer "self01", aber für long UND short.
get hm templateChk -f Rollo RolloHoch self01:sort 5
das selbe, nur für short Einträge

====templateUsg ====
Gibt eine Liste der zugewiesenen templates zurück
get hm templateUsg
get hm templateUsg sortTemplate
get hm templateUsg sortPeer

====templateExe ====
Nach einem loadConfig oder einem templateChk können Fehler erkannt worden sein, die Register entspreche nicht dem Template. Mit diesem Kommando werden alle nicht korrekten Register in die Devices geschrieben. Sollte die Werte stimmen wird nichts gemacht.
set hm templateExe

Das Kommando kann also bedenkenlos eingesetzt werden, wenn die templates schon stimmen. Es wird nichts gesendet, keine Funklast erzeugt.

====templateDel ====
eine zuweisung des Templates kann gelöscht werden
set hm templateDel <entity> <template>

===Temperaturlisten===
HMInfo bietet verschiedene Methoden, Temperaturlisten für Thermostate (CC-TC, TC-IT oder RT) zu verwalten und zu nutzen. Siehe hierzu [[HomeMatic HMInfo TempList/Weekplan|Homematic Weekplan]]

=== Registersätze kopieren ===
HMInfo erlaubt das Kopieren von Register-Listen. Über Register wird ein HM-Gerät eingestellt und die Register sind in Listen gruppiert. Die Reaktion und das Verhalten eines Aktors auf einen Trigger eines Sensors wird in dem Registersatz zu diesem Peer komplett beschrieben.
Durch die Möglichkeit einen solchen Registersatz im Device zu kopieren kann man das Verhalten, das man für einen Knopf/Sensor festgelegt hat identisch in einen zweiten kopieren.
HMInfo geht davon aus, dass die vom Gerät gelesene Konfiguration vor dem Kommando aktuell und komplett ist.
set hm cpRegs Licht1:FB3_Btn2 Licht3:FB1_Btn4
set hm cpRegs Licht2:FB3_Btn2 Licht2:FB1_Btn4
set hm cpRegs Licht4:FB3_Btn2 Licht4:FB5_Btn2
Die obigen Beispiele bewirken der Reihe nach:
Duplizieren das Verhalten, das Fernbedienungsknopf 2 der Fernbedienung 3 bei Aktor Licht1 hervorruft auch nach Licht3 für Fernbedienungsknopf4 der Fernbedienung 1.
Duplizieren das Verhalten, das Fernbedienungsknopf 2 der Fernbedienung 3 bei Aktor Licht2 hervorruft auch nach Licht2 (selber Aktor) für Fernbedienungsknopf4 der Fernbedienung 1.

== Web Einträge und Readings ==
Readings und Internals von HMInfo bieten eine Zusammenfassung des Zustands aller HM Komponenten. Diese sind in Fehler '''ERR' , Warnungen '''W_''' und Information '''I_''' untergliedert. Die Prüfung und Erneuerung der Zähler und Werte wird mit:
:<code>set hm update </code>
erreicht. Mit dem Attribut autoUpdate kann man es automatisch regelmäßig starten.

=== Fehlermeldungen ===
Als Fehler erkannte Zustände werden in Variablen beginnend mit '''ERR''' dargestellt. Erfasste Fehler sind kritische RSSI Werte und Protokoll-/Übertragungsfehler. Ausserdem kann man im Attribut sumERROR eintragen, welche Readings zu einer Fehlermeldung führen sollen. Eingetragen werden:
Reading:<gutwert>. Wenn ein Reading mit einen anderen als dem "gutwert" gefunden wird, wird dies alarmiert.
Beispiel:
:<code>battery:ok </code>
hat eine HM Komponente ein Reading "battery" und dieses hat einen anderen Wert als "ok" wird dies alarmiert.
In den Readings von HMInfo würde im Feherfall
internal:
ERR_names <devicename1>,<devicename2>
Readings:
ERR_battery low:2

Der default aller Error-meldungen ist
battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed

Diese Zusammenfassung der Fehlermeldungen könnte man nutzen, um über notify einen Alarm auszulösen oder eine E-Mail zu senden.

=== Warnungen===
Hierzu gehören Wiederholungen von Nachrichten (nicht aber Abbrüche, das sind Fehler). Es wird auch ausstehendes Lesen der Konfiguration, das durch autoReadReg getriggert wird, hier angezeigt.

=== Statusmeldungen ===
Analog zu den Fehlermeldungen kann man mit dem Attribut sumStatus gewisse Readings zählen lassen. Beipiel wäre
attr HM sumStatus motor
HMInfo zeigt in dem Reading I_sum_motor dann an, welcher Inhalt des Readings "motor" wie oft gefunden wurde. Es könnte so aussehen
stop:on:4;stop:1;
Vier Komponenten stehen auf motor: stop:on und eine steht auf motor: stop

Das Internal '''I_HM_IOdevices''' zeigt die von HM Komponenten genutzten IOs und deren State.

== Infos ==
get hm models [-f <regexp>]
get hm models
get hm models -f remote
get hm models -f HM_RC
Zeigt alle in FHEM unterstützten Modelle und deren wesentliche Parameter. Man kann mittels regexp die Liste filtern.

get hm param [<typefilter>] [-f <nameFilter>] parameter1 parameter2
get hm param -d IODev DEF model
get hm param -c -f Rollo peerList
man kann sich listen von Parametern anzeigen lassen

get hm register [<typefilter>] [-f <nameFilter>]
zeigt Register in tabellarischer Form.

get hm peerXref[<typefilter>] [-f <nameFilter>]
gibt an, wer mit wem gepeert ist

== Rücksetzen von Variablen und Zählern ==
set HM clear [<typeFilter>] [Protocol|readings|msgStat|register|rssi]
*register löscht alle Register-readings
*readings löscht '''alle''' readings
*Protocol löscht alle Protokol-einträge, pending Kommandos und Protokoll-fehler.
*rssi löscht alle ermittelten RSSI Werte
*msgStat setzt die Message Statistik zurück

== Filter ==
Kommandos in HMInfo wirken auf alle HM Komponenten. Man kann dies mit Hilfe der Filter einschränken. Zum einen gibt es '''modelsFilter''', womit man nur devices, nur channels, nur virtuelle Entities bearbeiten kann
set <name> <cmd> '''[-dcasevi]''' [params]
entities according to list will be processed"
d - device :include devices"
c - channels :include channels"
i - ignore :include devices marked as ignore"
v - virtual :supress fhem virtual"
p - physical :supress physical"
a - aktor :supress actor"
s - sensor :supress sensor"
e - empty :include results even if requested fields are empty"

Ein auf '''-d''' gefiltertes Kommando wird nur auf devices, nicht aber auf channels angewendet.

Dann gibt es noch den '''nameFilter''', mit dem mittels regexp auf den Namen der Entity gefiltert werden kann
-f Rollo # alle Entities mit Rollo im Namen
-f ^Rollo$ # nur Entity mit Namen "Rollo"
-f Rollo$ # nur Entity deren Name auf Rollo endet

Die Filter kann man kombinieren mit
-c -f Rollo # alle Kanäle mit Rollo im Namen

Beispiel:
Zeige mir die Parameter IODev und room der Devices mit Rollo im Namen
set hm param -d -f Rollo IODev room

== Attribute ==
* '''autoArchive ''' automatisch archivieren von vollständigen Konfigurationen.
* '''autoUpdate''' startet regelmäßig das Komamndo "update". Die Wiederholzeit wird eingestellt mit hh:mm. Sinnvoll erscheint z.B. alle 5 Minuten, also 00:05.
* '''configDir''' bietet die Möglichkeit, ein Verzeichnis zu definieren, in das HMInfo Dateien ablegen und von dem es die Dateien lesen wird. Default ist fhem_root.
* '''configFilename''' legt einen default Namen fest, der bei save und archive genutzt wird. Default ist regSave.cfg.
* '''hmAutoReadScan''' zeitinterval in Minuten, in denen CUL_HM prüft, ob offene autoRead bereitstehen und die IOs die Kapazität haben. Default ist 4 min.

== Quellen ==
* Thread [http://forum.fhem.de/index.php?topic=11035.0 HMinfo] im Fhem Forum
* Thread [http://forum.fhem.de/index.php/topic,20119.0.html HMINfo, Intention, Sinn und Zweck] im Fhem Forum

[[Kategorie:HomeMatic Components]]
[[Kategorie:HOWTOS]]

Google-Kalender zur Steuerung von Dummies

2016-02-03T19:06:16Z

Octo: Markup verbessert.

Mit dem Kalendermodul [http://fhem.de/commandref.html Calendar] ist es möglich, Ereignisse aus Kalendern im
ICal-Format abzufragen.
Dies und der Wiki-Eintrag [[Wochenende, Feiertage und Schulferien]] hat mich dazu veranlasst, dass ich durch
Kalendereinträge im Google-Kalender den Status meiner beiden [[dummy|Dummies]] "Urlaub" und "Besuch" steuere. Durch diese
beiden Dummies werden zum Beispiel die Rolläden im Schlafzimmer oder Gästezimmer bei Besuch oder Urlaub anders
gesteuert als ohne Besuch oder unter der Woche. Auch meine Zirkulationspumpe soll so bedarfsgerecht gesteuert werden.
Dass am Wochenende anders gesteuert wird, ist ja mit $we kein Problem.
Zuerst wird dafür der Kalender definiert:

define Kalender_Christian Calendar ical url <der richtige Kalenderlink> 14400

Den Kalenderlink [https://support.google.com/calendar/answer/37103?hl=de] findet man wie beschrieben heraus.
Dann habe ich meine Dummies definiert:

define Urlaub_dummy dummy
attr Urlaub_dummy room Kalender
attr Urlaub_dummy setList ja nein
attr Urlaub_dummy webCmd ja:nein
define Gast_dummy dummy
attr Gast_dummy room Kalender
attr Gast_dummy setList ja nein
attr Gast_dummy webCmd ja:nein

Und nun mussten die Notifys definiert werden, um bei entsprechenden Einträgen im Google-Kalender den Status der
Dummies zu setzen.

define Kalender_Christian_Start notify Kalender_Christian:modeStarted.*googlecom.* {\
Kalenderstart("$EVENT");;\
}
define Kalender_Christian_Ende notify Kalender_Christian:modeEnded.*googlecom.* {\
Kalenderende("$EVENT");;\
}

Um nicht für verschiedene Dummies immer einzelne Notifys zu bauen, wird hier bei mir je eine Funktion aus meiner [[99 myUtils anlegen|99_MyUtils.pm]] aufgerufen und das Event als Parameter übergeben. Die beiden zugehörigen
Funktionen für den Start und das Ende des Kalenderevents schauen so aus:
<source lang="perl">
sub
Kalenderstart ($)
{
my ($Ereignis) = @_;
my @Ereignisarray = split(/.*:\s/,$Ereignis);
my $Ereignisteil1 = $Ereignisarray[1];
my @uids = split(/;/,$Ereignisteil1);
foreach my $uid (@uids) {
my $Kalendertext = fhem("get Kalender_Christian summary $uid");
if ($Kalendertext =~ /Urlaub/) {
fhem("set Urlaub_dummy ja");
}
if ($Kalendertext =~ /Besuch/) {
fhem("set Gast_dummy ja");
}
}
}
sub Kalenderende ($) {
my ($Ereignis) = @_;
my @Ereignisarray = split(/.*:\s/,$Ereignis);
my $Ereignisteil1 = $Ereignisarray[1];
my @uids = split(/;/,$Ereignisteil1);
foreach my $uid (@uids) {
my $Kalendertext = fhem("get Kalender_Christian summary $uid");
if ($Kalendertext =~ /Urlaub/) {
fhem("set Urlaub_dummy nein");
}
if ($Kalendertext =~ /Besuch/) {
fhem("set Gast_dummy nein");
}
}
}
</source>

Zur Erläuterung: Als Ereignis wird z.B. "''modeStarted: 9aas2amo7td47th4sf7mlocl48googlecom''" oder bei 2 gleichzeitigen
Ereignissen: "''modeStarted: arqpe2a2snu6qn64dt0men7nd0googlecom;j0pjiupfb1sk3m5s64hbeo6880googlecom''"
übergeben. Da uns aber nur die eindeutige UID interessiert, wird das Ereignis beim Vorkommen der Zeichen ": Leerzeichen"
also nach modeStarted: geteilt (<code>split(/.*:\s/,$Ereignis)</code>). Die beiden Teile werden in ein Array (<code>@Ereignisarray</code>) gespeichert.
Und als 2. Element in dem Array ist nun die uns interessierende UID (<code>$Ereignisarray[1]</code>) vorhanden, mit welcher wir weiter
arbeiten. Da auch mit dem Fall mehrerer gleichzeitiger Ereignisse umgegangen werden können soll, müssen wir bei mehreren
UIDs diese wieder splitten. Diesmal beim Vorkommen des Semikolons als Trennzeichen (<code>split(/;/,$Ereignisteil1)</code>). Auch die
UIDs werden wieder in einem Array gespeichert und dann mittels der foreach-Schleife nacheinander abgearbeitet. Und
hierbei wird abhängig von der mittels UID abgerufenen Kalenderbeschreibung (<code>fhem("get Kalender_Christian summary
$uid")</code>) ein Vergleich auf die Werte "Besuch" oder "Urlaub" durchgeführt (<code>if ($Kalendertext =~ /Urlaub/)</code>) und davon
abhängig der Dummy-Status gesetzt.
Abhängig von diesen Dummies reagiert dann meine Rollosteuerung.

[[Kategorie:Code Snippets]]

HM-SEC-SD Rauchmelder

2016-02-02T19:53:08Z

Octo: /* Readings */ Fehlerhafte <pre>-Tags entfernt.

{{Infobox Hardware
|Bild=HM-SEC-SD o.jpeg 
|Bildbeschreibung=HomeMatic HM-SEC-SD Rauchmelder Oberseite
|HWProtocol=HomeMatic
|HWType=Aktor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=
|HWVoltage=9V
|HWPowerConsumption= W im Standby
|HWPoweredBy=3 x 1,5 V LR6/AA
|HWSize=120x44mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

== Features ==
Der [[HM-SEC-SD Rauchmelder|HM-SEC-SD]] ist ein VdS-zertifizierter Rauchmelder. Mehrere Rauchmelder können unabhängig von einer Zentrale zu einer Gruppe zusammengefasst werden. Auch ohne FHEM-Zentrale meldet ein Rauchmelder seinen Alarm immer an die anderen vernetzten Rauchmelder weiter.

== Hinweise zum Betrieb mit FHEM ==
Der HM-SEC-SD Rauchmelder beherrscht kein AES. Der Betrieb ist mit [[HMLAN Konfigurator]] oder mit [[CUL]] möglich. Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden.

=== Teams ===
Rauchmelder können/sollen in Teams gruppiert werden. Jeder SD kann einem Team angehören - und das sollte man auch einrichten. Nutzt man nur einen SD sollte man diesen mit sich selbst Teamen.

Beispiele:
nutzt man einen SD und will diesen nicht mit anderen in einem team haben peert man ihn mit sich selbst. Damit ist der SD sein eigener TeamLead.
:<code>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set actor</code>

Hat man mehrere SDs, die in einem Team zusammengefasst werden sollen, wird der TeamLead festgelegt und alle SDs werden mit ihm gepeert. Das Team kann jederzeit erweitert werden.
<pre>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set actor
set Rauchmelder_Flur peerChan 0 Rauchmelder_WZ single set actor
set Rauchmelder_Flur peerChan 0 Rauchmelder_SZ single set actor
set Rauchmelder_Flur peerChan 0 Rauchmelder_KZ single set actor </pre>

Nutzt man einen virtuellen TeamLead - (siehe [[#virtueller TeamLead|virtueller TeamLead]]) - werden alle realen SDs mit diesem gepeert
<pre>set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set actor
set Rauchmelder_Team peerChan 0 Rauchmelder_WZ single set actor
set Rauchmelder_Team peerChan 0 Rauchmelder_SZ single set actor
set Rauchmelder_Team peerChan 0 Rauchmelder_KZ single set actor
</pre>

Ein SD kann aus einem Team mittels unset entfernt werden.
:<code>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single unset actor </code>

Um einen SD von einem Team in ein anderes zu transferieren, muss man ihn erst mit ''unset'' aus dem Team entfernen, dann mit ''set'' in das neue Team eintragen. Einen physkalischen TeamLead kann man nur aus dem Team nehmen, indem man ihn aus allen Teammitgliedern entfernt.

Die korrekte Gruppierung sollte nach der Konfiguration durch einen teamCall geprüft werden.

Der Betrieb mehrer Teams ist möglich, ein SD kann aber nur einem Team angehören. Will man einen SD von einem Team in ein anderes umhängen, muss man ihn erst aus dem ersten Team entfernen und dann in das Neue aufnehmen.

=== TeamLead ===
Für ein Team muss immer ein TeamLead festgelegt werden. Anders als der Name suggeriert, gibt es hier keinen Master. Sinn und Zweck ist einzig, eine Team-Adresse (HMId) festzulegen, unter der man alle SDs eines Teams ansprechen kann. Diese muss, wie alle HMIds, einzig im System sein. Um dies zu erreichen, verwendet HM beim Teamen ohne Zentrale die HMId eines der SDs. Verwendet man eine Zentrale (FHEM) kann man dies auch entzerren und einen virtuellen SD als TeamLead nutzen. Siehe hierzu [[#virtueller TeamLead|virtueller TeamLead]].

Nutzt man nur einen einzelnen SD, sollte man diesen mit sich selbst teamen.

=== Kommandos ===
Es gibt Team-Nachrichten, die jeder SD senden kann und auf die jeder SD im Team reagiert. Jeder SD kann somit einen teamcall auslösen oder einen Alarm ausgeben. Die Kommandos werden '''nicht''' von einem SD zum anderen weitergereicht. Auch der TeamLead hat '''keine''' Sonderfunktion. Der einzelne SD sendet seine Nachricht an das Team und jeder im Team reagiert darauf.

Es ist somit darauf zu achten, dass auch die entferntesten SDs sich gegenseitig erreichen können.

Die Kommandos können von der Zentrale getriggert werden. Da sie unter der TeamId gesendet werden, stehen sie nur bei der Komponente des TeamLeads zu Verfügung.

Dazu gehören teamCall, alarmOn und alarmOff.

Sie stehen nur für die Entity des TeamLeads zu Verfügung.
<pre>set EurerTeamLeader alarmOn
set EurerTeamLeader alarmOff
set EurerTeamLeader teamCall</pre>

'''teamCall''' testet die Zugehörigkeit und Erreichbarkeit aller SDs im Team. Alle SDs sollten 10 mal leise piepen.

Einzelne SDs kann man mit "statusRequest" abfragen.

== virtueller TeamLead ==
Nutzt man nur einen einzelnen SD, kann/sollte man diesen mit sich selbst teamen (peerChan). In allen andere Fällen braucht man einen TeamLead um eine team-ID zu erhalten. Man kann hierzu einen der SDs nutzen. Wird dieser einmal ausgewechselt, hat man allerdings seine team-ID verloren.

Wenn man mit Zentrale (FHEM) arbeitet, gibt es eigentlich keinen vernünftigen Grund (ausser 1-SD-Teams), einen der SDs als lead zu nutzen. Man kann genauso gut einen virtuellen Aktor bauen und diesen zum Lead machen. Das ergibt eine sauberere Struktur.

Erzeugen eines virtuellen TeamLeads könnte so aussehen:
<pre>define TeamDev CUL_HM 111111
set TeamDev virtual 1
rename TeamDev_Btn1 Rauchmelder_Team</pre>

Bitte beachten: '''die HMID muss für die gesamte Installation einmalig sein'''.

Anschließend muss man noch einen Homematic-Kanal für das Peering definieren.

Jeder Rauchmelder muss jetzt in das Team aufgenommen werden:
<pre>set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set actor
set Rauchmelder_Team peerChan 0 Rauchmelder_WZ single set actor
...
save</pre>

Hierbei ist "Rauchmelder_Team" der Name des virtuellen TeamLeaders und "Rauchmelder_Flur" der Name des jeweiligen Rauchmelders.

Das "save" ist notwendig, um auch die Einstellungen des virtuellen SDs in der [[Konfiguration]] zu sichern.

Bei jedem Rauchmelder sollte der Name des virtuellen TeamLeaders in der peerList stehen und beim virtuellen TeamLeader jeder Rauchmelder.

Mit teamCall sollte man die korrekte Funktion des Teams prüfen, wer will auch mit alarmOn.

== Variablen ==
=== Internals ===
Keine Spezifischen.

=== Readings ===
Für '''jeden''' SD sind folgende Readings relevant:

teamCall from <name>:<count>
state:[off|smoke-Alarm_<count>]
smoke_detect:<von_name>
battery:[ok|low]
level:<0..200>

*'''count''' ist ein Zähler, den das Gerät liefert um neue Alarme unterscheiden zu können
*'''level''' ist ein Wert zwischen 0 und 200. 200 ist Alarm, 199 bedeutet Alarm, aber die Sirene ist abgeschaltet.

Beim '''TeamLead''' laufen alle Alarme auf

teamCall: from <name>:<count>
recentAlarm:<von_name>
level:<0..200>
eventNo:<count>
state:[off|smoke-Alarm_<count>]
smoke_detect:<von_name>
SDteam:[add_<name>|remove_<name>]

*'''von_name''' ist der Name des SD, der gemeldet hat.
*'''smoke_detect''' ist der aktuelle Alarm, während '''recentAlarm''' die letzte Alarmquelle anzeigt, auch wenn der Alarm schon behoben ist.
*'''SDteam''' kommt gelegentlich bei Konfigurationsereignissen zum Tragen.

=== Attribute ===
besondere Attribute
* '''msgRepeat''' sollte auf 1 stehen. SD ist ein burst device, wiederholen von Nachrichten belastet das HMLAN besonders. Die Team-kommandos sind hiervon nicht beeinflusst, also auch nicht das Auslösen eines Alarms.
* '''actCycle''' wird auf 99 Stunden gesetzt. Ein SD meldet sich alle 3 Tage bei der Zentrale, was der ActionDetector prüft.
* '''msgRepeat''' 1
Allgemein vorgeschlagen
:'''IODev''' [HMLAN/HMUSB/CUL]
:'''autoReadReg''' 5_readMissing
:'''event-on-change-reading''' .*
Optional, nur als Anregung zu verstehen
:'''devStateIcon''' off:general_ok *:secur_alarm
:'''group''' smokeDetect
:'''icon''' secur_smoke_detector

== Alarme ==
Meldet ein SD einen Alarm, wird dieser in dem SD und im TeamLead angezeigt.

Nutzt man [[HomeMatic HMInfo|HMinfo]], wird ein Rauchalarm auch hier als "Error" gemeldet. In HMinfo wird dies für alle SD-teams im System gemacht.

== Nützliche Notifies ==
Codefragmente, die man einsetzen kann. Ggf. muss man etwas anpassen, zumindest können sie als Anregung nützlich sein.
* Bei Alarm email schicken und Licht im Flur anschalten
<pre>
define sd.nf.report notify sdTeam:.*smoke-Alarm.* {\
<Mail versenden>;;
fhem("set LichtTreppenhaus on");;
}\
</pre>

* Bei Alarm alle SDs des Team stumm schalten durch stumm Schalten eines einzelnen
:<code>define sd.nf.quiet notify sdTeam:.*level:.199 set sdTeam alarmOff</code>

== Links ==
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/83454_HM-Sec-SD_GE_V1.4_20131011.pdf Anleitung (PDF)]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Rauchmelder]]

Benutzer Diskussion:Octo

2016-01-31T21:40:42Z

Octo: /* Bearbeitung Artikel VCCU */ Antwort.

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

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

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

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

== Bearbeitung Artikel VCCU ==

Uff … Octo

Ich muss sagen, ich bin nicht uneingeschränkt glücklich mit deiner Bearbeitung des Artikels VCCU (to say the least). Sicherlich war mein Text noch mit der einen oder anderen Redundanz und unschönen Formulierung versehen und auch z.t. etwas holprig. Allerdings hat der Aufbau ( soweit er nicht ein Rest der vorherigen Version war) einen bestimmten Grund. Ich hatte die VCCU nicht verstanden und unmittelbar nachdem ich das dann einigermaßen durchdrungen hatte, den Artikel genau mit den Hinweisen versehen, die mich auf die richtige Spur gebracht hätten. Ich habe ausserdem alle Fragen beantwortet die im Forumsthread gestellt wurden und bin insbesondere auf die Fragen des Threads detailliert eingegangen, die dort besondere Verständisprobleme bereiteten.

Davon hast du erhebliche Teile weggeworfen.

Am besten ist, dass du sogar einen Teil rausgeworfen has, der eine der von dir selbst als unter "TODO" gestellte Frage quasi en passant beantwortet hatte. Aus meiner Sicht hast du den Artikel also so weit gekürzt, das du selber nun Fragen hast, die vorher beantwortet wurden.

Man mag zu meinem Text stehen wie man will und ich gebe zu, dass er noch Verbesserungsbedarf hatte, aber etwas nerfig finde ich, dass der Artikel monatelang extrem rudimentär und für die meisten unverständlich hier im Wiki und im Forum für viel Verwirrung gesorgt hat, sich KEINER rantraut da mal was sinnvolles reinzuschreiben - ich mache mich dann Ende Dezember bis Anfang Januar da dran, den endlich mal so umzuschreiben, das man wenigstens kapieren kann, wozu , wieso warum, und schreibst du das Dingen nur 2 Wochen später komplett um - nebenbei am ERSTEN TAG in dem du hier tätig wirst.
Das hat mir offen gestanden wenig Spass gebracht gerade.

Gut, ist ein Wiki, KANN man machen.

Ich lasse das jetzt erstmal so stehen, behalte mir aber expliziet vor, das später ggf auch zu reverten.

Grüsse,

[[Benutzer:Soulman|Soulman]] ([[Benutzer Diskussion:Soulman|Diskussion]]) 23:04, 30. Jan. 2016 (CET)

: Hallo Soulman,
: Vielen Dank, dass du [[Virtueller Controller VCCU]] geschrieben hast – die Seite hat mir erst erlaubt die VCCU zu verstehen. Schade, dass dir meine Bearbeitung nicht gefällt.
: Die Ursprungsversion hat etwa drei mal das Gleiche beschrieben, zum Beispiel "vielfältige Möglichkeiten" in der Einleitung, "verschieden Vorteile" in der Kurzbeschreibung und letztlich ein Absatz "Wann ist eine VCCU sinnvoll". In meiner Überarbeitung habe ich versucht Füllsätze wegzulassen und zum Punkt zu kommen, zum Beispiel: "Durch das Pairen der Geräte mit einer virtuellen CCU ergeben sich folgende Vorteile" und dann eine Liste. Ich denke, dass ist einfacher zu lesen und leichter verständlich.
: Ich habe versucht, keine relevanten Informationen wegzulassen. Welche Fragen hat denn die vorherige Version beantwortet, die jetzt offen bleiben? Ich arbeite mit redundanten Systemen und bin gewohnt damit umzugehen – habe ich vielleicht die Ausfallsicherheit / Reichweite zu knapp abgehandelt?
: Auf meine TODO-Fragen habe ich in der Ursprungsversion leider keine Antwort finden können – wenn du mich einweihen kannst bin ich gerne bereit das nachzutragen.
: Vielleicht hast du ja noch ein wenig ''konstruktive'' Kritik für mich … Bis jetzt weiß ich leider nur, was dir ''nicht'' gefallen hat.
: Viele Grüße, —[[Benutzer:Octo|Octo]] ([[Benutzer Diskussion:Octo|Diskussion]]) 22:40, 31. Jan. 2016 (CET)

Datei:HM-LC-BL1PBU schritt 05.jpg

2016-01-27T20:52:45Z

Octo: Octo lud eine neue Version von Datei:HM-LC-BL1PBU schritt 05.jpg hoch

Importing image file

HM-LC-Bl1PBU-FM Funk-Rollladenaktor für Markenschalter

2016-01-27T20:48:20Z

Octo: Bild in der Infobox aktualisiert.

{{Infobox Hardware
|Bild=HM-LC-Bl1PBU-FM.jpg
|Bildbeschreibung=HM-LC-Bl1PBU-FM montiert, ohne Adapter
|HWProtocol=BidCoS ([[HomeMatic]])
|HWType=[[HomeMatic Type Blind|Blind]]
|HWCategory=[[:Kategorie:Rollladensteuerung|Rollladensteuerung]]
|HWComm=868,3 MHz
|HWChannels=1
|HWVoltage=230 V
|HWPowerConsumption=0,5 W (Stand-by)
|HWPoweredBy=Netz
|HWSize=71x71x37 mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}
== Features ==

Schalten eines angeschlossenen Jalousiemotors mittels CUL/CUN/HMLAN Konfigurator und über lokalen, in bestehendes Schalterprogramm integrierte Schaltwippe.

'''Technische Daten:'''
* Gerätebezeichnung: HM-LC-Bl1PBU-FM
* Versorgungsspannung: 230 V / 50 Hz
* Maximale Schaltleistung: 230 VA (Motorlast)
* Standby-Verbrauch: 0,5 W
* Schaltvermögen: 1 A (Motorlast)
* Funkfrequenz: 868,3 MHz
* Empfängerklasse: SRD Class 2
* Maximale Sendeleistung: 10 mW
* Schutzart: IP20
* Schutzklasse: II
* Umgebungstemperatur: +5°C bis +35°C
* Abmessungen (B x H x T): 71 x 71 x 37 mm
* Gewicht: 43 g

== Hinweise zur Hardware-Installation ==

Der Schaltaktor ersetzt den Unterputzschalter der bestehenden Elektroinstallation. Arbeiten am 230 V Netz dürfen nur von einer Elektrofachkraft durchgeführt werden! Sicherheitsregeln anwenden:

* Freischalten (Sicherung abschalten),
* gegen Wiedereinschalten sichern,
* Spannungsfreiheit feststellen, (Messgerät vor und '''nach''' Messung auf Funktion überprüfen)
* Erden und Kurzschließen,
* benachbarte, unter Spannung stehende Teile abdecken.

Zur Integration in ein bestehendes Schalterprogramm bitte den entsprechenden Adapter mit bestellen.

<gallery>
Datei:HM-LC-BL1PBU schritt 01.jpg|Ausgangssituation
Datei:HM-LC-BL1PBU schritt 02.jpg|Schalter abbauen, Rahmen entfernen, Unterputzschalter lösen
Datei:HM-LC-BL1PBU schritt 03.jpg|Bestehender Anschluss
Datei:HM-LC-BL1PBU schritt 04.jpg|Neuer Anschluss. Achtung: zusätzlicher Nullleiteranschluss!
Datei:HM-LC-BL1PBU schritt 05.jpg|Einbau ohne Adapter
Datei:HM-LC-BL1PBU schritt 06.jpg|Adapter aufsetzen
Datei:HM-LC-BL1PBU schritt 07.jpg|Fertig eingebauter HM-LC-BL1PBU-FM
</gallery>

== Hinweise zum Betrieb mit FHEM ==

Der Schalter wird seit FHEM 5.3 unterstützt. Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden. Dazu wird der Config-Taster kurz gedrückt.
Zur Darstellung im Webfrontend siehe [[Slider für HM-Rolladensteuerung anzeigen]].

=== FHEM Config-Auszug ===
Ein exemplarischer Auszug aus der fhem.cfg:

define WZ_Rollo_Links CUL_HM ABCDEF
attr WZ_Rollo_Links devInfo 010100
attr WZ_Rollo_Links eventMap on:hoch off:runter stop:stop
attr WZ_Rollo_Links firmware 2.1
attr WZ_Rollo_Links hmClass receiver
attr WZ_Rollo_Links model HM-LC-Bl1PBU-FM
attr WZ_Rollo_Links room Wohnzimmer
attr WZ_Rollo_Links serialNr JEQxxxxxxx
attr WZ_Rollo_Links subType blindActuator
attr WZ_Rollo_Links webCmd pct

=== Variablen===
==== Attribute====
Dem Device können neben den Allgemeinen auch spezielle Attribute gesetzt werden.
* '''param levelInverse''': HM Blind Aktoren stehen auf 100% wenn sie offen sind und auf 0% wenn sie geschlossen sind. Das ist oftmals nicht intuitiv. In FHEM kann man dies "drehen" durch dieses Attribut. Damit dreht sich auch die Bedeutung von On und Off.

Desweiteren empfehlen sich die üblichen Homematic Attribute (wie autoReadReg, event-on-change-reading, expert) zu setzten. Weitere Informationen dazu unter [[HomeMatic#Attribute]]

==== Readings====
*'''level''' numerischer Wert der den Stand des Rollo wiedergibt. Achtung: Der Aktor kennt nicht den Stand des Rollos sondern errechnet diesen aus den Fahrzeiten. Nach einem powerUp wird ein Stand von 50% angenommen.
*'''motor''': zeigt den Zustand des Motors an, ob er steht oder in welche Richtung er fährt
*'''pct''': analog "level"

== Konfiguration==
Die Konfiguration des Devices betrifft Register und Peerings. Dies sind Werte, die zwar über FHEM gesetzt werden, aber im Device im Flash gespeichert werden.
Man kann die Devices mit Sensoren und Tastern [[Homematic_Peering_Beispiele|peeren]]

===Fahrzeiten kalibrieren===
Um die Jalousie mit Prozentangaben auf eine bestimmte Position fahren zu lassen, muss der Aktor die Fahrtzeiten kennen um daraus die relativen Positionen erechnen zu können. Dazu müssen 3 Werte manuell mit einer Stoppuhr gemessen werden.

* Fahrtzeit nach oben
* Fahrtzeit nach unten (ist meistens identisch mit der Fahrzeit nach oben bei herkömlichen Jalousiemotoren)
* Wechsel der Fahrtrichtung

Diese 3 Zeiten werden in Sekunden gemessen und anschließend einmalig mit den folgenden Befehlen eingestellt:
set <name> regSet driveUp 27.0 # Fahrtzeit nach oben in Sekunden
set <name> regSet driveDown 27.0 # Fahrtzeit nach unten in Sekunden
set <name> regSet driveTurn 0.5 # Die Zeit die gebraucht wird um die Fahrtrichtung zu wechseln in Sekunden

=== Tasterverhalten ===
Um den fahrenden Rollladen bei jedem Tastendruck anzuhalten und nicht nur bei Druck auf die entgegengesetzte Richtung:

* Die internen Taster sichtbar schalten und die config abfragen
set <device> regSet intKeyVisib visib
set <device> getConfig

* Die Taster konfigurieren
set <device> regBulk RegL_03:self01 0B:94 0D:63 8B:94
set <device> regBulk RegL_03:self02 0B:18 0D:63 8B:18

* Die internen Taster unsichtbar schalten und die config überprüfen
set <device> regSet intKeyVisib invisib
set <device> getConfig

Wichtig: nach jedem Schritt jeweils die Anlern-Taste drücken und in den Internals schauen ob die kommandos ohne Fehler abgearbeitet wurden.

== Mögliche Schaltoperationen ==

Der Aktor versteht folgende Befehle:
set <name> on -> Schaltet den Aktor ein
set <name> off -> Schaltet den Aktor aus
set <name> toggle -> Ändert den logischen Zustand des Aktors.
set <name> <Prozentangabe[0 bis 100]> -> Öffnet die Jalousie auf absolut prozentuale Öffnungsposition, berechnet aus definierter Laufzeit.
set <name> up/down <Prozentangabe[0 bis 100]> -> Öffnet oder schließt die Jalousie um den prozentualen Wert, berechnet aus definierter Laufzeit. Keine Angabe => 10%

== Log-Auszug ==
In FHEM ist nach dem Schalten des HM-LC-BL1-FM folgendes Log zu sehen:
2013.02.26 07:00:12 2: CUL_HM set WZ_Rollo_Rechts on rxt:1

== Links ==
* [http://www.elv-downloads.de/Assets/Produkte/10/1030/103038/Downloads/103038_FunkRollladenaktor_um.pdf Bedienungsanleitung (PDF)]

[[Kategorie:HomeMatic Components]]
[[Kategorie:HomeMatic Type Blind]]
[[Kategorie:Rollladensteuerung]]

Datei:HM-LC-Bl1PBU-FM.jpg

2016-01-27T20:46:46Z

Octo: Symbolbild für den HM-LC-Bl1PBU-FM Unterputz-Jalousieaktor basierend auf Datei:HM-LC-BL1PBU schritt 05.jpg.

Symbolbild für den [[HM-LC-Bl1PBU-FM Unterputz-Jalousieaktor]] basierend auf [[Datei:HM-LC-BL1PBU schritt 05.jpg]].

HM-LC-Bl1PBU-FM Funk-Rollladenaktor für Markenschalter

2016-01-27T20:38:38Z

Octo: Infobox Hardware eingefügt.

{{Infobox Hardware
|Bild=HM-LC-BL1PBU schritt 05.jpg
|Bildbeschreibung=HM-LC-Bl1PBU-FM montiert, ohne Adapter
|HWProtocol=BidCoS ([[HomeMatic]])
|HWType=[[HomeMatic Type Blind|Blind]]
|HWCategory=[[:Kategorie:Rollladensteuerung|Rollladensteuerung]]
|HWComm=868,3 MHz
|HWChannels=1
|HWVoltage=230 V
|HWPowerConsumption=0,5 W (Stand-by)
|HWPoweredBy=Netz
|HWSize=71x71x37 mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}
== Features ==

Schalten eines angeschlossenen Jalousiemotors mittels CUL/CUN/HMLAN Konfigurator und über lokalen, in bestehendes Schalterprogramm integrierte Schaltwippe.

'''Technische Daten:'''
* Gerätebezeichnung: HM-LC-Bl1PBU-FM
* Versorgungsspannung: 230 V / 50 Hz
* Maximale Schaltleistung: 230 VA (Motorlast)
* Standby-Verbrauch: 0,5 W
* Schaltvermögen: 1 A (Motorlast)
* Funkfrequenz: 868,3 MHz
* Empfängerklasse: SRD Class 2
* Maximale Sendeleistung: 10 mW
* Schutzart: IP20
* Schutzklasse: II
* Umgebungstemperatur: +5°C bis +35°C
* Abmessungen (B x H x T): 71 x 71 x 37 mm
* Gewicht: 43 g

== Hinweise zur Hardware-Installation ==

Der Schaltaktor ersetzt den Unterputzschalter der bestehenden Elektroinstallation. Arbeiten am 230 V Netz dürfen nur von einer Elektrofachkraft durchgeführt werden! Sicherheitsregeln anwenden:

* Freischalten (Sicherung abschalten),
* gegen Wiedereinschalten sichern,
* Spannungsfreiheit feststellen, (Messgerät vor und '''nach''' Messung auf Funktion überprüfen)
* Erden und Kurzschließen,
* benachbarte, unter Spannung stehende Teile abdecken.

Zur Integration in ein bestehendes Schalterprogramm bitte den entsprechenden Adapter mit bestellen.

<gallery>
Datei:HM-LC-BL1PBU schritt 01.jpg|Ausgangssituation
Datei:HM-LC-BL1PBU schritt 02.jpg|Schalter abbauen, Rahmen entfernen, Unterputzschalter lösen
Datei:HM-LC-BL1PBU schritt 03.jpg|Bestehender Anschluss
Datei:HM-LC-BL1PBU schritt 04.jpg|Neuer Anschluss. Achtung: zusätzlicher Nullleiteranschluss!
Datei:HM-LC-BL1PBU schritt 05.jpg|Einbau ohne Adapter
Datei:HM-LC-BL1PBU schritt 06.jpg|Adapter aufsetzen
Datei:HM-LC-BL1PBU schritt 07.jpg|Fertig eingebauter HM-LC-BL1PBU-FM
</gallery>

== Hinweise zum Betrieb mit FHEM ==

Der Schalter wird seit FHEM 5.3 unterstützt. Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden. Dazu wird der Config-Taster kurz gedrückt.
Zur Darstellung im Webfrontend siehe [[Slider für HM-Rolladensteuerung anzeigen]].

=== FHEM Config-Auszug ===
Ein exemplarischer Auszug aus der fhem.cfg:

define WZ_Rollo_Links CUL_HM ABCDEF
attr WZ_Rollo_Links devInfo 010100
attr WZ_Rollo_Links eventMap on:hoch off:runter stop:stop
attr WZ_Rollo_Links firmware 2.1
attr WZ_Rollo_Links hmClass receiver
attr WZ_Rollo_Links model HM-LC-Bl1PBU-FM
attr WZ_Rollo_Links room Wohnzimmer
attr WZ_Rollo_Links serialNr JEQxxxxxxx
attr WZ_Rollo_Links subType blindActuator
attr WZ_Rollo_Links webCmd pct

=== Variablen===
==== Attribute====
Dem Device können neben den Allgemeinen auch spezielle Attribute gesetzt werden.
* '''param levelInverse''': HM Blind Aktoren stehen auf 100% wenn sie offen sind und auf 0% wenn sie geschlossen sind. Das ist oftmals nicht intuitiv. In FHEM kann man dies "drehen" durch dieses Attribut. Damit dreht sich auch die Bedeutung von On und Off.

Desweiteren empfehlen sich die üblichen Homematic Attribute (wie autoReadReg, event-on-change-reading, expert) zu setzten. Weitere Informationen dazu unter [[HomeMatic#Attribute]]

==== Readings====
*'''level''' numerischer Wert der den Stand des Rollo wiedergibt. Achtung: Der Aktor kennt nicht den Stand des Rollos sondern errechnet diesen aus den Fahrzeiten. Nach einem powerUp wird ein Stand von 50% angenommen.
*'''motor''': zeigt den Zustand des Motors an, ob er steht oder in welche Richtung er fährt
*'''pct''': analog "level"

== Konfiguration==
Die Konfiguration des Devices betrifft Register und Peerings. Dies sind Werte, die zwar über FHEM gesetzt werden, aber im Device im Flash gespeichert werden.
Man kann die Devices mit Sensoren und Tastern [[Homematic_Peering_Beispiele|peeren]]

===Fahrzeiten kalibrieren===
Um die Jalousie mit Prozentangaben auf eine bestimmte Position fahren zu lassen, muss der Aktor die Fahrtzeiten kennen um daraus die relativen Positionen erechnen zu können. Dazu müssen 3 Werte manuell mit einer Stoppuhr gemessen werden.

* Fahrtzeit nach oben
* Fahrtzeit nach unten (ist meistens identisch mit der Fahrzeit nach oben bei herkömlichen Jalousiemotoren)
* Wechsel der Fahrtrichtung

Diese 3 Zeiten werden in Sekunden gemessen und anschließend einmalig mit den folgenden Befehlen eingestellt:
set <name> regSet driveUp 27.0 # Fahrtzeit nach oben in Sekunden
set <name> regSet driveDown 27.0 # Fahrtzeit nach unten in Sekunden
set <name> regSet driveTurn 0.5 # Die Zeit die gebraucht wird um die Fahrtrichtung zu wechseln in Sekunden

=== Tasterverhalten ===
Um den fahrenden Rollladen bei jedem Tastendruck anzuhalten und nicht nur bei Druck auf die entgegengesetzte Richtung:

* Die internen Taster sichtbar schalten und die config abfragen
set <device> regSet intKeyVisib visib
set <device> getConfig

* Die Taster konfigurieren
set <device> regBulk RegL_03:self01 0B:94 0D:63 8B:94
set <device> regBulk RegL_03:self02 0B:18 0D:63 8B:18

* Die internen Taster unsichtbar schalten und die config überprüfen
set <device> regSet intKeyVisib invisib
set <device> getConfig

Wichtig: nach jedem Schritt jeweils die Anlern-Taste drücken und in den Internals schauen ob die kommandos ohne Fehler abgearbeitet wurden.

== Mögliche Schaltoperationen ==

Der Aktor versteht folgende Befehle:
set <name> on -> Schaltet den Aktor ein
set <name> off -> Schaltet den Aktor aus
set <name> toggle -> Ändert den logischen Zustand des Aktors.
set <name> <Prozentangabe[0 bis 100]> -> Öffnet die Jalousie auf absolut prozentuale Öffnungsposition, berechnet aus definierter Laufzeit.
set <name> up/down <Prozentangabe[0 bis 100]> -> Öffnet oder schließt die Jalousie um den prozentualen Wert, berechnet aus definierter Laufzeit. Keine Angabe => 10%

== Log-Auszug ==
In FHEM ist nach dem Schalten des HM-LC-BL1-FM folgendes Log zu sehen:
2013.02.26 07:00:12 2: CUL_HM set WZ_Rollo_Rechts on rxt:1

== Links ==
* [http://www.elv-downloads.de/Assets/Produkte/10/1030/103038/Downloads/103038_FunkRollladenaktor_um.pdf Bedienungsanleitung (PDF)]

[[Kategorie:HomeMatic Components]]
[[Kategorie:HomeMatic Type Blind]]
[[Kategorie:Rollladensteuerung]]

HM-LC-Dim1TPBU-FM 1-Kanal-Dimmer UP

2016-01-27T20:19:41Z

Octo: Abmessungen in der Infobox korrigiert.

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=
|HWProtocol=BidCoS ([[HomeMatic]])
|HWType=[[HomeMatic Type Dimmer|Dimmer]]
|HWCategory=[[:Kategorie:Dimmer|Dimmer]]
|HWComm=868,3 MHz
|HWChannels=1
|HWVoltage=230 V
|HWPowerConsumption=1 W (Stand-by)
|HWPoweredBy=Netz
|HWSize=71x71x37 mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}
Der '''HM-LC-Dim1TPBU-FM 1-Kanal-Dimmer UP''' ist ein Phasenabschnitts-Dimmer für die Unterputzmontage. Er verfügt über eine Schalterwippe, die sich mit einem Adapter in einige Schalterprogramme verschiedener Hersteller integrieren lässt. Der Dimmer kann sowohl vor Ort über die Schalterwippe als auch per Funk gesteuert werden.

== Features ==

Schaltdoseneinsatz als Ersatz für vorhandenen Dimmer-Einsatz (erfordert keine tiefere Schaltdose). Kann mittels Adapter in bestehende Schalterserien wie Busch Jäger, Gira usw. integriert werden.

=== Technische Daten ===

* Versorgungsspannung: 230 V / 50 Hz
* Minimallast: 10 VA
* Minimalstrom: 40 mA
* Maximale Schaltleistung: 180 VA
* Standby-Verbrauch: 1 W
* Dimmverfahren: Phasenabschnitt
* Funkfrequenz: 868,3 MHz
* Empfängerklasse: SRD Class 2
* Maximale Sendeleistung: 10 mW
* Schutzart: IP20
* Schutzklasse: II
* Umgebungstemperatur: +5 °C bis +35 °C
* Abmessungen (BxHxT): 71x71x37 mm
* Gewicht: 43 g

=== Schalter ===

Der HM-LC-Dim1TPBU-FM besitzt zwei Schalter, die über eine Wippe angewählt werden können. Das Standard-Verhalten entspricht im Prinzip dem [[HM-LC-Bl1PBU-FM Unterputz-Jalousieaktor]]:

* Ein kurzer Druck nach oben Schaltet den Verbraucher ein (100 % Leistung).
* Ein kurzer Durck nach unten Schaltet den Verbraucher aus (0 % Leistung).
* Ein langer Druck nach oben erhöht die Leistung bis der Schalter losgelassen wird.
* Ein langer Druck nach unten verringert die Leistung bis der Schalter losgelassen wird.

== Hinweise zur Hardware-Installation ==

Der HM-LC-Dim1TPBU-FM verfügt über vier Anschlussklemmen: Phase, gedimmte Phase und zwei kurzgeschlossene Klemmen für den Neutralleiter. Das heißt, dass der Neutralleiter "durchgeschleift" werden kann.

Der HM-LC-Dim1TPBU-FM füllt die Schalterdose links und rechts nahezu aus. Wenn möglich ist eine Zuführung der Leitungen von oben oder unten zu bevorzugen.

== Kompatible Leuchtmittel ==

In der Detailansicht vieler LED-Lampen auf der Webseite von ELV.de lässt sich eine Dimmer-Kompatibilitätsliste für das jeweilige Modell herunterladen.

== Links ==

* Anleitung: http://files.elv.de/Assets/Produkte/10/1030/103020/Downloads/103020_FunkDimmaktor_um.pdf

[[Kategorie:HomeMatic Components]]
[[Kategorie:Dimmer]]

HM-LC-Dim1TPBU-FM 1-Kanal-Dimmer UP

2016-01-27T20:18:31Z

Octo: /* Features */ Leeszeichen eingefügt.

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=
|HWProtocol=BidCoS ([[HomeMatic]])
|HWType=[[HomeMatic Type Dimmer|Dimmer]]
|HWCategory=[[:Kategorie:Dimmer|Dimmer]]
|HWComm=868,3 MHz
|HWChannels=1
|HWVoltage=230 V
|HWPowerConsumption=1 W (Stand-by)
|HWPoweredBy=Netz
|HWSize=71x71x34 mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}
Der '''HM-LC-Dim1TPBU-FM 1-Kanal-Dimmer UP''' ist ein Phasenabschnitts-Dimmer für die Unterputzmontage. Er verfügt über eine Schalterwippe, die sich mit einem Adapter in einige Schalterprogramme verschiedener Hersteller integrieren lässt. Der Dimmer kann sowohl vor Ort über die Schalterwippe als auch per Funk gesteuert werden.

== Features ==

Schaltdoseneinsatz als Ersatz für vorhandenen Dimmer-Einsatz (erfordert keine tiefere Schaltdose). Kann mittels Adapter in bestehende Schalterserien wie Busch Jäger, Gira usw. integriert werden.

=== Technische Daten ===

* Schaltvermögen: 10–180 VA
* Art: Phasenabschnittsdimmer
* Versorgungsspannung: 230 V / 50 Hz
* Minimallast: 10 VA
* Minimalstrom: 40 mA
* Maximale Schaltleistung: 180 VA
* Standby-Verbrauch: 1 W
* Dimmverfahren: Phasenabschnitt
* Funkfrequenz: 868,3 MHz
* Empfängerklasse: SRD Class 2
* Maximale Sendeleistung: 10 mW
* Schutzart: IP20
* Schutzklasse: II
* Umgebungstemperatur: +5 °C bis +35 °C
* Abmessungen (BxHxT): 71x71x37 mm
* Gewicht: 43 g

=== Schalter ===

Der HM-LC-Dim1TPBU-FM besitzt zwei Schalter, die über eine Wippe angewählt werden können. Das Standard-Verhalten entspricht im Prinzip dem [[HM-LC-Bl1PBU-FM Unterputz-Jalousieaktor]]:

* Ein kurzer Druck nach oben Schaltet den Verbraucher ein (100 % Leistung).
* Ein kurzer Durck nach unten Schaltet den Verbraucher aus (0 % Leistung).
* Ein langer Druck nach oben erhöht die Leistung bis der Schalter losgelassen wird.
* Ein langer Druck nach unten verringert die Leistung bis der Schalter losgelassen wird.

== Hinweise zur Hardware-Installation ==

Der HM-LC-Dim1TPBU-FM verfügt über vier Anschlussklemmen: Phase, gedimmte Phase und zwei kurzgeschlossene Klemmen für den Neutralleiter. Das heißt, dass der Neutralleiter "durchgeschleift" werden kann.

Der HM-LC-Dim1TPBU-FM füllt die Schalterdose links und rechts nahezu aus. Wenn möglich ist eine Zuführung der Leitungen von oben oder unten zu bevorzugen.

== Kompatible Leuchtmittel ==

In der Detailansicht vieler LED-Lampen auf der Webseite von ELV.de lässt sich eine Dimmer-Kompatibilitätsliste für das jeweilige Modell herunterladen.

== Links ==

* Anleitung: http://files.elv.de/Assets/Produkte/10/1030/103020/Downloads/103020_FunkDimmaktor_um.pdf

[[Kategorie:HomeMatic Components]]
[[Kategorie:Dimmer]]

HM-LC-Dim1TPBU-FM 1-Kanal-Dimmer UP

2016-01-27T20:18:05Z

Octo: Artikel überarbeitet.

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=
|HWProtocol=BidCoS ([[HomeMatic]])
|HWType=[[HomeMatic Type Dimmer|Dimmer]]
|HWCategory=[[:Kategorie:Dimmer|Dimmer]]
|HWComm=868,3 MHz
|HWChannels=1
|HWVoltage=230 V
|HWPowerConsumption=1 W (Stand-by)
|HWPoweredBy=Netz
|HWSize=71x71x34 mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}
Der '''HM-LC-Dim1TPBU-FM 1-Kanal-Dimmer UP''' ist ein Phasenabschnitts-Dimmer für die Unterputzmontage. Er verfügt über eine Schalterwippe, die sich mit einem Adapter in einige Schalterprogramme verschiedener Hersteller integrieren lässt. Der Dimmer kann sowohl vor Ort über die Schalterwippe als auch per Funk gesteuert werden.

== Features ==

Schaltdoseneinsatz als Ersatz für vorhandenen Dimmer-Einsatz (erfordert keine tiefere Schaltdose). Kann mittels Adapter in bestehende Schalterserien wie Busch Jäger, Gira usw. integriert werden.

=== Technische Daten ===

* Schaltvermögen: 10–180 VA
* Art: Phasenabschnittsdimmer
* Versorgungsspannung: 230 V / 50 Hz
* Minimallast: 10 VA
* Minimalstrom: 40 mA
* Maximale Schaltleistung: 180 VA
* Standby-Verbrauch: 1 W
* Dimmverfahren: Phasenabschnitt
* Funkfrequenz: 868,3 MHz
* Empfängerklasse: SRD Class 2
* Maximale Sendeleistung: 10 mW
* Schutzart: IP20
* Schutzklasse: II
* Umgebungstemperatur: +5 °C bis +35 °C
* Abmessungen (BxHxT):71x71x37 mm
* Gewicht: 43 g

=== Schalter ===

Der HM-LC-Dim1TPBU-FM besitzt zwei Schalter, die über eine Wippe angewählt werden können. Das Standard-Verhalten entspricht im Prinzip dem [[HM-LC-Bl1PBU-FM Unterputz-Jalousieaktor]]:

* Ein kurzer Druck nach oben Schaltet den Verbraucher ein (100 % Leistung).
* Ein kurzer Durck nach unten Schaltet den Verbraucher aus (0 % Leistung).
* Ein langer Druck nach oben erhöht die Leistung bis der Schalter losgelassen wird.
* Ein langer Druck nach unten verringert die Leistung bis der Schalter losgelassen wird.

== Hinweise zur Hardware-Installation ==

Der HM-LC-Dim1TPBU-FM verfügt über vier Anschlussklemmen: Phase, gedimmte Phase und zwei kurzgeschlossene Klemmen für den Neutralleiter. Das heißt, dass der Neutralleiter "durchgeschleift" werden kann.

Der HM-LC-Dim1TPBU-FM füllt die Schalterdose links und rechts nahezu aus. Wenn möglich ist eine Zuführung der Leitungen von oben oder unten zu bevorzugen.

== Kompatible Leuchtmittel ==

In der Detailansicht vieler LED-Lampen auf der Webseite von ELV.de lässt sich eine Dimmer-Kompatibilitätsliste für das jeweilige Modell herunterladen.

== Links ==

* Anleitung: http://files.elv.de/Assets/Produkte/10/1030/103020/Downloads/103020_FunkDimmaktor_um.pdf

[[Kategorie:HomeMatic Components]]
[[Kategorie:Dimmer]]

Diskussion:Virtueller Controller VCCU

2016-01-27T15:37:40Z

Octo: Antwort

== Vorteile ==
mir wird nicht klar, warum ich eine VCCU verwenden soll, bzw. wo der Vorteil gegenüber der direkten Anbindung an einen HML Konfigurator liegt.
Kann das noch mal einer versuchen zu erklären? [[Benutzer:Soulman|Soulman]] ([[Benutzer Diskussion:Soulman|Diskussion]]) 04:02, 27. Mär. 2015 (CET)
:Hier lesen bringt Punkte http://forum.fhem.de/index.php/topic,28568.0.html
:Ich habe mich jetzt mal dran gemacht, den Artikel zu verfeinern und mit einer Einführung und so zu versehen, sodass leichter verständlich ist, warum man das machen will.[[Benutzer:Soulman|Soulman]] ([[Benutzer Diskussion:Soulman|Diskussion]]) 00:43, 24. Dez. 2015 (CET)
: Ich habe die Einleitung in großen Teilen überarbeitet mit einem Absatz über Vorteile. Reviews willkommen! :-) —[[Benutzer:Octo|Octo]] ([[Benutzer Diskussion:Octo|Diskussion]]) 16:37, 27. Jan. 2016 (CET)

Virtueller Controller VCCU

2016-01-27T15:32:49Z

Octo: Einleitung überarbeitet und dedupliziert.

Eine '''Virtuelle CCU''', auch '''VCCU''' genannt, ist eine Zentrale für [[HomeMatic]]-Geräte. Die VCCU tritt beim [[Pairing und Peering|Pairing]] an die Stelle des ''I/O-Devices'' (auch "Schnittstelle" genannt, zum Beispiel [[CUL]] und [[HM-CFG-LAN]]).

HomeMatic-Geräte werden überlicherweise mit einer Zentrale gepaired, um sie zentral verwalten zu können. Der Pairing-Partner ist im einfachsten Fall das I/O-Device ([[CUL]], [[HM-CFG-LAN]], …) selbst. Durch das Pairen der Geräte mit einer virtuellen CCU ergeben sich folgende Vorteile:

* Die Verwendung mehrerer I/O-Devices wird möglich. Das sorgt für Redundanz (Ausfallsicherheit) und/oder Reichweiten-Vergrößerung.
* Der Tausch eines I/O-Devices ist transparent für gepairte Geräte.
* Die VCCU stellt virtuelle Kanälen zur Verfügung, mit denen HomeMatic-Geräte [[Homematic Peering Beispiele|gepeert]] werden können.
* "Geordnete" Termination von Nachrichten.

Der einzige Nachteil einer VCCU gegenüber dem direkten Pairing mit dem I/O-Device ist ein Mehraufwand bei der initialen Konfiguration vom Fhem.

== Mehrere VCCUs in einer Installation==

Theoretisch erlaubt Fhem die parallele Nutzung mehrer VCCUs, praktisch ergeben sich dadurch jedoch keine Vorteile gegenüber einer einzigen VCCU. Insbesondere kann eine VCCU verschiedene I/O-Devices bedienen, zum Beispiel einen [[CUL]] ''und'' ein [[HM-CFG-LAN]].

Jede VCCUs muss eine eindeutige ''HomeMatic-ID'' haben, mit der HomeMatic-Geräte gepaired werden. Folglich kann jedes HomeMatic-Gerät nur mit ''einer'' VCCU gepaired werden.

{{Todo|Können mehrere VCCU das selbe I/O-Device nutzen?}}
{{Todo|Können HomeMatic-Geräte, die mit unterschiedlichen VCCUs gepaired wurden, untereinander gepeert werden?}}

== Definition der VCCU==
=== hmId wählen ===
Eine VCCU benötigt wie alle HM Devices eine Adresse, mit der sie angesprochen wird. Bei Schnittstellen und Zentralen ist dies eine ''hmId''. Da die VCCU eine (virtuelle) Zentrale ist, muss sie auch mit einer ''hmId'' versehen werden. Dies geschieht per define analog zur Anlage einer physischen Schnittstelle (siehe weiter unten)

Eine VCCU gibt die ''hmId'' an die ihr zugewiesenen IOs (Funkschnittstellen) weiter.

Definiert man eine VCCU nachdem IOs (CUL oder HMLAN) für Homematic angelegt sind, sollte die ''hmId'' der bereits vorhandene Funkschnittstelle verwenden, hierdurch kann man sich das Neupairen der HM Devices ersparen.

Allerdings muss das attr IOgrp eines vor Anlage der VCCU gepairten Gerätes auf die VCCU angelegt/geändert werden., z.B. so
attr <device> IOgrp VCCU
(Sie weiter unten ein Tipp, wie dies leicht nachträglich erledigt werden kann)

Mit der Anlage einer VCCU hat das eventuell angelegte attribut IODev eines HM_Devices keine Funktion mehr. Vielmehr setzt die VCCU das IODev automatisch je nach Verfügbarkeit und Funklage. Es ist jedoch nicht erforderlich angelegte IODev Attribute zu entfernen.

=== Einrichten ===
define VCCU CUL_HM <hmId>
attr vccu model CCU-FHEM
attr vccu IOList <io1>[,<io2>,...]

Das Attribut IOList dient dazu festzulegen, welche physikalischen Schnittstellen ("IO") von der VCCU genutzt werden, dies sind in der Regel alle HM-fähigen Schnittstellen einer Installtion.
IOList beinhaltet die Komma-getrennte Liste der IOs, so wie sie in FHEM angelegt sind.

Es seien z.b. in FHEM bereits die beiden Schnittstellen HMLAN und CULHM angelegt:

define HMLAN0 HMLAN 192.168.168.2:1000
attr HMLAN0 hmId 123456
attr HMLAN0 hmLanQlen 1_min
attr HMLAN0 icon hm_lan

define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 hmId 123456
attr CUL0 icon cul_cul
attr CUL0 rfmode HomeMatic

Dann kann zusätzlich die VCCU mit der selben hmId angelgt werden und die beiden physikalischen Schnittstellen ihr zugewiesen:

define VCCU CUL_HM 123456
attr VCCU IOList CUL0,HMLAN0
attr VCCU model CCU-FHEM
attr VCCU subType virtual
attr VCCU webCmd virtual:update

Wird die VCCU mit einer von vorhandene Schnittstellen abweichenden ''hmId'' angelegt, so wird die ''hmId'' der ihr zugewiesenen Schnittstelle(n) automatische angepasst. Dies hat in der Regel zur Folge, das HM Devices neu gepairt werden müssen.

=== Auswirkungen auf IOs / Funkschnittstellen===
Sind IOs durch das Attribut IOList einer VCCU zugewiesen, werden die notwendigen Attribute im IO gesetzt, so wird die hmId durch die VCCU kontrolliert. Ein HMLAN/USB ist etwas enger verbunden als CUL IOs. Beim HMLAN kann die HMId nicht mehr geändert werden. Die kontrollierende VCCU wird in den Internals ''owner'' und ''owner_CCU'' des IO automatisch eingetragen. 

=== Pairen von HM Devices===
HM Devices sollten vorzugsweise direkt mit der VCCU gepairt werden, hierzu werden die normalen Befehle
hmPairForSec
hmPairSerial
verwendet. Es ist im übrigen weiter möglich (aber nicht sinnvoll / empfehlenswert) auch nach Anlage einer VCCU HM Devices mit diesen Kommandos direkt an ein IO zu pairen, d.h. diese Kommandos haben auch nach Anlage einer VCCU noch eine Funktion an der physikalischen Schnittstelle (im Gegensatz z.b. zum attr IODev)

== Dynamisches IO ==
FHEM sendet Befehle an an ein HM Device in der Regel immer über das gleiche IO-Device. Fällt es aus wird nicht mehr gesendet, selbst wenn ein zweites IO verfügbar wäre. Ausserdem gibt es ''bewegliche'' Fernbedienungen welche ihre Verbindung zu einem IO verlieren, aber über ein andere IO gut empfangen werden könnten.

Die VCCU adressiert beide Probleme:

Durch das Attibut IOgrp
attr <dev> IOgrp <vccu>:<preferredIO>
kann bestimmt werden, wie die VCCU die IO Devices genau nutzt. Insbesondere ist optional ein Preferd IO Device definierbar: bei stationären Devices - der häufigste Fall - sollte man das beste IO auswählen und als Default nutzen. Ein weiteres IO wird bei Ausfall des Ersten genutzt.

Das preferredIO ist jedoch optional und kann insbesondere bei beweglichen HM Devices (Fernbedienungen) weggelassen werden.

Beispiele:

Durch
attr <device> IOgrp VCCU:HMLAN1
wird die VCCU zuerst versuchen Befehle an <device> mit HMLAN1 zu senden, falls seine condition=ok.
Falls nicht wird (einer) der verbleibende(n) IOs verwendet, hier der mit dem besten RSSI.

Durch
attr <device> IOgrp VCCU
wird durch die VCCU der IO mit dem besten RSSI zum Device gewählt, falls seine condition=ok ist.

Da dies für jedes angelegte HM Device einzeln definiert werden kann/muss, kann so auch eine Verteilung des Funkverkehrs vorgenommen werden, z.b. um die 1%-Regel (HighLoad) zu berücksichtigen, dennoch bleibt die Redunanz bei Ausfall einer Schnittstelle erhalten.

=== Bemerkungen ===
Es wird empfohlen, das Attribut IOgrp in allen Devices zu setzen. Kanäle senden nicht selbständig, haben daher kein Attribut IOgrp. 
Das Attribut '''IODev''' wird automatisch gesetzt, Usereinträge haben keine Funktion. Es zeigt jedoch indirekt das letzte genutzte output-device. 
Die besprochene Steuerung betrifft das '''Senden'''. Empfangen und verarbeitet werden Nachrichten immer von allen verfügbaren Quellen.

=== Setzen der IOgrp auf (fast) allen Devices mit einem einzigen Befehl ===
Hat man eine bestehende Fhem-Installation mit mehreren/vielen Devices, kann das Setzen der ''IOgrp'' aufwändig sein. Erleichtern kann man dies mittels des Befehls:

attr TYPE=CUL_HM:FILTER=DEF=...... IOgrp vccu
save

Dieser Befehl (in der Fhem-Eingabezeile eingeben und mit <Return> bestätigen).

== Virtuelle Kanäle der VCCU==
Eine VCCU kann bis zu 50 virtuelle Kanäle bedienen. Diese können als Sender/Sensoren oder Empfänger genutzt werden. Man kann diese Kanäle mit einem realen Kanal peeren und Aktionen triggern.

Man peert beispielsweise eine virtuellen Kanal mit einem Dimmer um das Verhalten bei Tastendruck lang und kurz festzulegen. Aus der Zentrale kann man den Tastendruck auslösen. Es können mehrere Aktoren an einen virtuellen Kanal gepeert werden und so alle Lichter der Gruppe mit einem "press" verzögerungslos schalten.

=== Anlegen ===
set vccu virtual <AnzahlButton>
z.B.
set vccu virtual 10
legt 10 Kanäle für die VCCU an, die Kanäle 1-10. Evtl. vorhandene Kanäle größer 10 werden gelöscht.

=== Kommandos ===
für Kommandos siehe CommandRef und
get vccu_Btn1 cmdList
insbesondere gibt es
set vccu_Btn1 press short
set vccu_Btn1 press long
set vccu_Btn1 postEvent <condition>

[[Kategorie:HomeMatic Components]]
[[Kategorie:HOWTOS]]

CUL HM

2016-01-27T10:47:30Z

Octo: /* Virtuelle CCU (VCCU) */ Beispiel-Definition hinzugefügt.

{{Infobox Modul
|ModPurpose=HomeMatic Geräte (über CUL oder HMLAN)
|ModType=d
|ModCmdRef=CUL_HM
|ModForumArea=HomeMatic
|ModTechName=10_CUL_HM.pm
|ModOwner=martinp876 ([http://forum.fhem.de/index.php?action=profile;u=251 Forum] / [[Benutzer Diskussion:Martinp876|Wiki]])
}}

[[CUL_HM]] implementiert die Unterstützung für [[HomeMatic]]-Geräte, die über einen [[CUL]] oder
[[HM-CFG-LAN LAN Konfigurations-Adapter|HMLAN Konfigurator]] angebunden sind.

== Voraussetzungen ==
HomeMatic [[Interface]]: CUL im HomeMatic Modus oder [[HM-CFG-LAN LAN Konfigurations-Adapter|HMLAN Konfigurator]].

== Anwendung ==
=== Define ===
Details in der [http://fhem.de/commandref.html#CUL_HM commandref].

define <name> CUL_HM <6-digit-hex-code|8-digit-hex-code>

=== Attribute ===
Details in der commandref.

==== Virtuelle CCU (VCCU) ====
[[Datei:VirtualCCU.png|mini|400px|rechts|Standarddarstellung einer Virtual CCU im Webinterface]]
: ''→ Hauptartikel: [[Virtueller Controller VCCU]]''

Eine ''Virtuelle CCU'' implemmentiert einen HomeMatic-Controller und abstrahiert von den I/O-Devices, beispielsweise [[CUL]].

define vccu CUL_HM <hmId>
attr vccu model CCU-FHEM
attr vccu IOList <ioDev1>[,<ioDev2>,…]

'''Siehe auch:'''
* Foren-Thread {{Link2Forum|Topic=23008|LinkText="HM virtual CCU"}} (April 2014)
* Foren-Beitrag {{Link2Forum|Topic=24048|Message=194876|LinkText="virtual CCU (Homematic)"}} (August 2014)

== Anwendungsbeispiele ==
=== Virtuellen Aktor erstellen ===
Ein virtueller Aktor ist nötig, damit Taster wie z.B. der [[HM-PB-6-WM55_6fach-Funk-Wandtaster|6fach-Wandtaster]] oder der [[HM-PB-2-WM55_2fach-Funk-Wandtaster|2fach-Wandtaster]] einen Tastendruck mit grünem Aufleuchten bestätigen. Diese Rückmeldung geben die Taster normalerweise wenn sie den Tastendruck an ihre Peers weitergeben haben. Hat man aber keine Homematic-Peers direkt gekoppelt (also nur die Zentrale gepairt), leuchten die Taster lediglich orange.

Mit einer virtuellen CCU kann man virtuelle Aktoren erstellen, mit denen man die Taster dann peeren kann. Zunächst muss dazu eine virtuelle CCU angelegt werden <code>define virtualCCU CUL_HM XXXXXX</code>, wobei XXXXXX der hmId des HMLAN-Interfaces entspricht (bzw. dessen was statt HMLAN verwendet wird). Mit <code>attr virtualCCU model CCU-FHEM</code> gibt man der CCU noch den korrekten Typ.
Virtuelle Aktoren kann man in der benötigten Anzahl (d.h. Anzahl aller Tasterbuttons) nun mit <code>set virtualCCU virtual X</code> anlegen, wobei X der benötigten Anzahl virtueller Aktoren entspricht. Danach existieren die virtuellen Aktoren als z.b. <code>virtualCCU_Btn1, virtualCCU_Btn2</code> usw. in FHEM.

Die Peerings zwischen Tastern und den Buttons stellt man dann folgendermaßen her (CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 und CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 sind jeweils die Buttons des Tasters CUL_HM_HM_PB_2_WM55_1F1xxx):
<pre>
set CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 peerChan 0 virtualCCU_Btn1 single set
set CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 peerChan 0 virtualCCU_Btn2 single set
</pre>

Danach führt man ein <code>set CUL_HM_HM_PB_2_WM55_1F1xxx getConfig</code> aus und drückt einmal kurz den Anlern-Button des Tasters. Danach sollte der Taster mehrmals kurz orange blinken.

Wenn alles geklappt hat wird nach dem betätigen der Taster in den States von CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 bzw. CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 ein "(to virtualCCU)" stehen.

Save Config nicht vergessen :-).

==== Tipps ====
* Es wäre auch möglich nur einen virtuellen Aktor anzulegen und alle Buttons damit zu peeren.

== Links ==
* [http://forum.fhem.de/index.php/topic,23008.msg163510.html Forenthread] zum Thema ''virtuelle CCU''.

[[Kategorie:HomeMatic Components]]

CUL HM

2016-01-27T10:42:34Z

Octo: /* Virtuelle CCU (VCCU) */ Abschnitt überarbeitet.

{{Infobox Modul
|ModPurpose=HomeMatic Geräte (über CUL oder HMLAN)
|ModType=d
|ModCmdRef=CUL_HM
|ModForumArea=HomeMatic
|ModTechName=10_CUL_HM.pm
|ModOwner=martinp876 ([http://forum.fhem.de/index.php?action=profile;u=251 Forum] / [[Benutzer Diskussion:Martinp876|Wiki]])
}}

[[CUL_HM]] implementiert die Unterstützung für [[HomeMatic]]-Geräte, die über einen [[CUL]] oder
[[HM-CFG-LAN LAN Konfigurations-Adapter|HMLAN Konfigurator]] angebunden sind.

== Voraussetzungen ==
HomeMatic [[Interface]]: CUL im HomeMatic Modus oder [[HM-CFG-LAN LAN Konfigurations-Adapter|HMLAN Konfigurator]].

== Anwendung ==
=== Define ===
Details in der [http://fhem.de/commandref.html#CUL_HM commandref].

define <name> CUL_HM <6-digit-hex-code|8-digit-hex-code>

=== Attribute ===
Details in der commandref.

==== Virtuelle CCU (VCCU) ====
[[Datei:VirtualCCU.png|mini|400px|rechts|Standarddarstellung einer Virtual CCU im Webinterface]]
: ''→ Hauptartikel: [[Virtueller Controller VCCU]]''

Eine ''Virtuelle CCU'' implemmentiert einen HomeMatic-Controller und abstrahiert von den I/O-Devices, beispielsweise [[CUL]].

'''Siehe auch:'''
* Foren-Thread {{Link2Forum|Topic=23008|LinkText="HM virtual CCU"}} (April 2014)
* Foren-Beitrag {{Link2Forum|Topic=24048|Message=194876|LinkText="virtual CCU (Homematic)"}} (August 2014)

== Anwendungsbeispiele ==
=== Virtuellen Aktor erstellen ===
Ein virtueller Aktor ist nötig, damit Taster wie z.B. der [[HM-PB-6-WM55_6fach-Funk-Wandtaster|6fach-Wandtaster]] oder der [[HM-PB-2-WM55_2fach-Funk-Wandtaster|2fach-Wandtaster]] einen Tastendruck mit grünem Aufleuchten bestätigen. Diese Rückmeldung geben die Taster normalerweise wenn sie den Tastendruck an ihre Peers weitergeben haben. Hat man aber keine Homematic-Peers direkt gekoppelt (also nur die Zentrale gepairt), leuchten die Taster lediglich orange.

Mit einer virtuellen CCU kann man virtuelle Aktoren erstellen, mit denen man die Taster dann peeren kann. Zunächst muss dazu eine virtuelle CCU angelegt werden <code>define virtualCCU CUL_HM XXXXXX</code>, wobei XXXXXX der hmId des HMLAN-Interfaces entspricht (bzw. dessen was statt HMLAN verwendet wird). Mit <code>attr virtualCCU model CCU-FHEM</code> gibt man der CCU noch den korrekten Typ.
Virtuelle Aktoren kann man in der benötigten Anzahl (d.h. Anzahl aller Tasterbuttons) nun mit <code>set virtualCCU virtual X</code> anlegen, wobei X der benötigten Anzahl virtueller Aktoren entspricht. Danach existieren die virtuellen Aktoren als z.b. <code>virtualCCU_Btn1, virtualCCU_Btn2</code> usw. in FHEM.

Die Peerings zwischen Tastern und den Buttons stellt man dann folgendermaßen her (CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 und CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 sind jeweils die Buttons des Tasters CUL_HM_HM_PB_2_WM55_1F1xxx):
<pre>
set CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 peerChan 0 virtualCCU_Btn1 single set
set CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 peerChan 0 virtualCCU_Btn2 single set
</pre>

Danach führt man ein <code>set CUL_HM_HM_PB_2_WM55_1F1xxx getConfig</code> aus und drückt einmal kurz den Anlern-Button des Tasters. Danach sollte der Taster mehrmals kurz orange blinken.

Wenn alles geklappt hat wird nach dem betätigen der Taster in den States von CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 bzw. CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 ein "(to virtualCCU)" stehen.

Save Config nicht vergessen :-).

==== Tipps ====
* Es wäre auch möglich nur einen virtuellen Aktor anzulegen und alle Buttons damit zu peeren.

== Links ==
* [http://forum.fhem.de/index.php/topic,23008.msg163510.html Forenthread] zum Thema ''virtuelle CCU''.

[[Kategorie:HomeMatic Components]]

CUL HM

2016-01-27T10:31:58Z

Octo: /* Define */ Link zur commandref eingefügt.

{{Infobox Modul
|ModPurpose=HomeMatic Geräte (über CUL oder HMLAN)
|ModType=d
|ModCmdRef=CUL_HM
|ModForumArea=HomeMatic
|ModTechName=10_CUL_HM.pm
|ModOwner=martinp876 ([http://forum.fhem.de/index.php?action=profile;u=251 Forum] / [[Benutzer Diskussion:Martinp876|Wiki]])
}}

[[CUL_HM]] implementiert die Unterstützung für [[HomeMatic]]-Geräte, die über einen [[CUL]] oder
[[HM-CFG-LAN LAN Konfigurations-Adapter|HMLAN Konfigurator]] angebunden sind.

== Voraussetzungen ==
HomeMatic [[Interface]]: CUL im HomeMatic Modus oder [[HM-CFG-LAN LAN Konfigurations-Adapter|HMLAN Konfigurator]].

== Anwendung ==
=== Define ===
Details in der [http://fhem.de/commandref.html#CUL_HM commandref].

define <name> CUL_HM <6-digit-hex-code|8-digit-hex-code>

=== Attribute ===
Details in der commandref.

==== Virtuelle CCU (VCCU) ====
[[Datei:VirtualCCU.png|mini|400px|rechts|Standarddarstellung einer Virtual CCU im Webinterface]]
Die Definition von (z.B.)
:<code>define myVCCU CUL_HM 5C0C05</code>
:<code>attr myVCCU model CCU-FHEM</code>
führt zum Anlegen eines CUL_HM Device ''myVCCU'' als '''virtuelle CCU'''. Das Device bekommt (automatisch) ein Attribut <code>subType</code> mit dem Wert <code>virtual</code> und wird im [[PGM2|Webinterface]] wie in der Abbildung gezeigt dargestellt. Die einzelnen Elemente bedeuten:
;myVCCU
:Name des Device
;myHMLAN
:Name(n) des (der) zugeordneten IO Device(s) (mit dem angehängten aktuellen Status, hier <code>:ok</code>)
;Schieberegler
:???
;<code>update</code>
:Schaltfläche zum ...???

In den zugeordneten IO Devices wird automatisch(?) ein ''internal value'' mit Namen <code>owner_CCU</code> und dem Wert <code>myVCCU</code> angelegt.

Details zum Konzept, den Vorteilen und der Benutzung finden sich derzeit in {{Link2Forum|Topic=23008|LinkText=diesem Forenthread}} und auch {{Link2Forum|Topic=24048|Message=194876|LinkText=hier}}.

{{Todo|Das VCCU-Konzept wird mittlerweile detailliert auf der Wiki-Seite [[Virtueller_Controller_VCCU]] beschrieben, so dass hier eine Anpassung erfolgen sollte}}

== Anwendungsbeispiele ==
=== Virtuellen Aktor erstellen ===
Ein virtueller Aktor ist nötig, damit Taster wie z.B. der [[HM-PB-6-WM55_6fach-Funk-Wandtaster|6fach-Wandtaster]] oder der [[HM-PB-2-WM55_2fach-Funk-Wandtaster|2fach-Wandtaster]] einen Tastendruck mit grünem Aufleuchten bestätigen. Diese Rückmeldung geben die Taster normalerweise wenn sie den Tastendruck an ihre Peers weitergeben haben. Hat man aber keine Homematic-Peers direkt gekoppelt (also nur die Zentrale gepairt), leuchten die Taster lediglich orange.

Mit einer virtuellen CCU kann man virtuelle Aktoren erstellen, mit denen man die Taster dann peeren kann. Zunächst muss dazu eine virtuelle CCU angelegt werden <code>define virtualCCU CUL_HM XXXXXX</code>, wobei XXXXXX der hmId des HMLAN-Interfaces entspricht (bzw. dessen was statt HMLAN verwendet wird). Mit <code>attr virtualCCU model CCU-FHEM</code> gibt man der CCU noch den korrekten Typ.
Virtuelle Aktoren kann man in der benötigten Anzahl (d.h. Anzahl aller Tasterbuttons) nun mit <code>set virtualCCU virtual X</code> anlegen, wobei X der benötigten Anzahl virtueller Aktoren entspricht. Danach existieren die virtuellen Aktoren als z.b. <code>virtualCCU_Btn1, virtualCCU_Btn2</code> usw. in FHEM.

Die Peerings zwischen Tastern und den Buttons stellt man dann folgendermaßen her (CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 und CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 sind jeweils die Buttons des Tasters CUL_HM_HM_PB_2_WM55_1F1xxx):
<pre>
set CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 peerChan 0 virtualCCU_Btn1 single set
set CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 peerChan 0 virtualCCU_Btn2 single set
</pre>

Danach führt man ein <code>set CUL_HM_HM_PB_2_WM55_1F1xxx getConfig</code> aus und drückt einmal kurz den Anlern-Button des Tasters. Danach sollte der Taster mehrmals kurz orange blinken.

Wenn alles geklappt hat wird nach dem betätigen der Taster in den States von CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 bzw. CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 ein "(to virtualCCU)" stehen.

Save Config nicht vergessen :-).

==== Tipps ====
* Es wäre auch möglich nur einen virtuellen Aktor anzulegen und alle Buttons damit zu peeren.

== Links ==
* [http://forum.fhem.de/index.php/topic,23008.msg163510.html Forenthread] zum Thema ''virtuelle CCU''.

[[Kategorie:HomeMatic Components]]

HM-RC-2-PBU-FM Unterputz-Wandsender

2016-01-27T06:22:48Z

Octo: Leistungsaufnahme korrigiert.

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=
|HWProtocol=BidCoS ([[HomeMatic]])
|HWType=[[HomeMatic Type Remote|remote]]
|HWCategory=[[:Kategorie:Schalter (Sender)|Schalter (Sender)]]
|HWComm=868,3 MHz
|HWChannels=2
|HWVoltage=230 V
|HWPowerConsumption=0,22 W (Ruhebetrieb)
|HWPoweredBy=Netz
|HWSize=71x71x37 mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}

Der [[HM-RC-2-PBU-FM Unterputz-Wandsender]] ist ein 2-Kanal-Sender zur Unterputz-Montage, der sich in Schalterprogramme einiger Hersteller integrieren lässt. Aus Sicht von Fhem verhält er sich wie eine [[HomeMatic Type Remote|Fernbedienung]] mit zwei Tasten.

[[Kategorie:HomeMatic Components]]
[[Kategorie:Schalter (Sender)]]

HM-RC-2-PBU-FM Unterputz-Wandsender

2016-01-27T05:48:39Z

Octo: Artikel-Stub angelegt.

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=
|HWProtocol=BidCoS ([[HomeMatic]])
|HWType=[[HomeMatic Type Remote|remote]]
|HWCategory=[[:Kategorie:Schalter (Sender)|Schalter (Sender)]]
|HWComm=868 MHz
|HWChannels=2
|HWVoltage=230 V
|HWPowerConsumption=9 mA (max)
|HWPoweredBy=Netz
|HWSize=71x71x37 mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}

Der [[HM-RC-2-PBU-FM Unterputz-Wandsender]] ist ein 2-Kanal-Sender zur Unterputz-Montage, der sich in Schalterprogramme einiger Hersteller integrieren lässt. Aus Sicht von Fhem verhält er sich wie eine [[HomeMatic Type Remote|Fernbedienung]] mit zwei Tasten.

[[Kategorie:HomeMatic Components]]
[[Kategorie:Schalter (Sender)]]

HomeMatic Type Thermostat

2016-01-26T16:29:16Z

Octo: /* Templates */ Formulierung verbessert.

{{HMType}} 
HomeMatic-Geräte vom Typ '''Thermostat''' ermöglichen es die Raumtemperatur zu regeln. Derzeit werden die folgenden Geräte unterstützt:

* [[HM-CC-RT-DN Funk-Heizkörperthermostat]]
* [[HM-CC-TC Funk-Wandthermostat]]
* [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]]

Die Geräte unterscheiden sich im Funktionsumfang und in einigen Details. Einzelheiten sind im jeweiligen Wiki-Topic dokumentiert.
Gemeinsam ist allen Geräten, dass sie eine oder mehrere ''Temperaturlisten'', oft auch ''Wochenprogramm'' genannt, unterstützen.

== Temperaturlisten ==

Temperaturlisten erlauben die Solltemperatur in Abhängigkeit des Wochentags und der Urzeit einzustellen.

{{Hinweis|Der zuständige Kanal heißt bei den Wandthermostaten ''_Climate'', beim [[HM-CC-RT-DN]] ''_Clima'' (ohne "te").}}

=== Allgemein ===

Temperaturlisten werden mit folgenden sieben Kommandos gesetzt, eines für jeden Wochentag: ''tempListMon'', ''tempListTue'', ''tempListWed'', ''tempListThu'', ''tempListFri'', ''tempListSat'' und ''tempListSun''. Die Kommandos müssen auf den Kanal ''_Climate'' (beim [[HM-CC-RT-DN]]: ''_Clima'' ohne "te") angewendet werden.

'''Syntax:'''

set <thermostat>_Climate tempList<Tag> [<End-Zeitpunkt> <Temperatur> […]] 24:00 <Temperatur>

Der (implizite) Start-Zeitpunkt einer Temperaturliste ist 0:00 Uhr. Es folgen Paare von End-Zeitpunkt und (Soll-)Temperatur. Die Zeitpunkte können 30-Minuten genau, die Temperaturen 0,1-Kelvin genau eingestellt werden. Der letzte End-Zeitpunkt ''muss'' 24:00 Uhr sein.

'''Beispiel:'''

set <thermostat>_Climate tempListFri 05:30 16.0 07:00 22.0 16:00 18.5 21:30 21.0 24:00 16.0

Dieses Kommando setzt das Temperaturprofil für Freitag. Der (implizite) Start-Zeitpunkt ist 0:00 Uhr. Es folgen paare von End-Zeitpunkt und Solltemperatur. Der letzte End-Zeitpunkt ''muss'' 24:00 Uhr sein. Das Beispiel stellt folgendes Profil ein:
{| class="wikitable"
! Zeitspanne
! Temperatur
|-
| style="color: blue;" | 00:00–05:30 Uhr
| style="color: blue; text-align: right;" | 16.0 °C
|-
| style="color: red;" | 05:30–07:00 Uhr
| style="color: red; text-align: right;" | 22.0 °C
|-
| style="color: green;" | 07:00–16:00 Uhr
| style="color: green; text-align: right;" | 18.5 °C
|-
| style="color: orange;" | 16:00–21:30 Uhr
| style="color: orange; text-align: right;" | 21.0 °C
|-
| style="color: blue;" | 21:30–24:00 Uhr
| style="color: blue; text-align: right;" | 16.0 °C
|}

=== Massenänderung ===

Bei Änderung mehrerer Tage empfiehlt es sich die Änderungen mit <code>prep</code> vorzubereiten und anschließend mit <code>exec</code> an das Gerät zu übertragen, da die Übertragung "teuer" (zeitaufwendig) ist.

'''Beispiel:'''

set Thermostat_Climate tempListMon prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0
set Thermostat_Climate tempListTue prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0
set Thermostat_Climate tempListWed prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0
set Thermostat_Climate tempListThu prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0
set Thermostat_Climate tempListFri prep 05:30 19.0 07:00 20.5 15:00 19.0 20:30 20.0 24:00 17.0
set Thermostat_Climate tempListSat prep 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0
set Thermostat_Climate tempListSun exec 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0

=== Alternative Wochenprogramme setzen (HM-TC-IT-WM-W-EU) ===

Das [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]] verfügt über weitere Wochenprogramme, P2 und P3.

Um das Wochenprogramm "P2" eines HM-TC-IT-WM-W-EU zu setzen, wird der Temperaturliste "p2" vorangestellt.

'''Beispiel:'''

set <HM-TC-IT-WM-W-EU>_Climate tempListSat p2 07:30 16.0 17:00 20.0 19:00 21.0 24:00 16.0

===Templates ===
{{Todo|Dieser Absatz überschneidet sich inhaltlich mit [[HomeMatic HMInfo TempList/Weekplan]].}}

Komfortabler ist es, Wochenprogramme in einer Datei abzulegen und zu verwalten. Eine Datei kann mehrere Wochenprogramme enthalten, die mit einem Namen angesprochen werden. Diese Wochenprogramme kann man den Thermostaten zuweisen. So kann man ein Wochenprogramm beliebig vielen Thermostaten zuweisen. Bei Änderungen kann man alle betroffenen Thermostate, die das gleiche Wochenprogramm nutzen, erreichen.

Zusammenfassend:
* Temperaturlisten der Devices in ein file schreiben
* Templates definieren, die man mehreren Devices zuordnen kann
* Template-Änderungen gleichzeitig in mehrere Devices einspielen
* Temperaturlisten gegen ein Template prüfen

====File erstellen und verwalten ====
Ein File mit den Temperaturlisten (Wochenplänen) muss erzeugt werden. Zur Verwaltung der Temperaturprofile sollte die Datei tempList.cfg im Verzeichnis FHEM liegen, dann kann sie mit dem Web-Interface editiert werden.
HMInfo unterstützt das speichern allen temperaturlisten in ein File mit [[Homematic_HMInfo#Speichern|temperaturListen speichern]]. Dies kann man gut als Startpunkt nutzen.
Bsp:

Angenommen HMInfo ist definiert per
define hm HMinfo
legt dieser Aufruf ein initiales Template an.
set hm tempList save FHEM/tempList.cfg

Die Wochenprogramme sollten in FHEM vorliegen. ggf. mit getConfig auslesen.

entities:tempTmpl1
tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
tempListSun>08:00 14.0 15:00 18.0 21:30 19.0 24:00 17.0
tempListMon>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListTue>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 15.0
tempListWed>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListThu>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListFri>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 14.0
entities:tempTWohnzimmer
tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 17.0
tempListSun>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
tempListMon>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListTue>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 15.0
tempListWed>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListThu>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListFri>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 14.0

====Templates zuweisen ====
Das Attribut tempListTmpl sollte man allen Thermostaten zuweisen. Dies ist dem jeweiligen Steuerungschannel zuzuweisen
attr hk1_Clima tempListTmpl setup/tempList.cfg:tempTmpl1
attr hk2_Clima tempListTmpl setup/tempList.cfg:tempTmpl1
attr hk3_Clima tempListTmpl setup/tempList.cfg:tempTWohnzimmer

In entsprechenden Kommandos muss man nun nicht mehr den Namen des Templates für den HK angeben, es wird der aus dem Attribut genommen. Man gibt das File an und dann den Namen des Templates im File.

==== Überprüfen/Einlesen ====
Mit dem verify-Kommando wird überprüft, ob das gegenwärtig vorhandene Temperaturprofil mit dem in der Datei befindlichen übereinstimmt.
set thermostat_Climate tempListTmpl verify FHEM/tempList.cfg:room1
Mit dem restore-Kommando wird das Temperaturprofil des Heizkörperthermostaten mit dem in der Datei befindlichen überschrieben.
set thermostat_Climate tempListTmpl restore FHEM/tempList.cfg:room1
* FHEM/tempList.cfg ist die Datei, in dem das Temperaturprofil zu suchen ist. '''room1''' ist der Name des Temperaturprofils, welches in der Datei gesucht wird. Wird keine Datei angegeben wird "template.cfg" im "fhem"-Verzeichnis angenommen.
Man kann einem Thermostat das '''Attribut tempListTmpl''' geben. Damit wird der Default-Name des Temperaturprofils für dieses Device gesetzt.
attr thermostat_Climate tempListTmpl FHEM/tempList.cfg:room1
set thermostat_Climate tempListTmpl
prüft das gegenwärtige Temperaturprofil gegen FHEM/tempList.cfg:room1 (da verify der Default ist). Die Prüfung des Profils ist auch Teil des configCheck von HMInfo.
Will man explizit kein Temperaturprofil zuweisen sollte man tempListTmpl auf none setzen.
set thermostat_Climate tempListTmpl restore
überschreibt das gegenwärtige Temperaturprofil des Heizkörperthermostaten mit dem in der Datei befindlichen überschrieben.

==== Templates systemweit nutzen ====
Sinnvoll erscheint es, das ganze systemweit zu machen. Man legt ein File mit allen Wochenplänen an, die man nutzen will. Dann weißt man die TemplateNamen den Thermostaten zu. Und schließlich prüft oder updates man alle Thermostate in einem System mit einem Kommando. Siehe hierzu [[Homematic_HMInfo#Temperaturlisten|HMInfo temperaturlisten]].

[[Kategorie:HomeMatic Components]]
[[Kategorie:Heizungssteuerung]]

HomeMatic HMInfo TempList/Weekplan

2016-01-26T15:23:27Z

Octo: /* Mehrere Heizkörper in einem Raum */ Abschnitt überarbeitet.

{{Todo|Dieser Artikel überschneidet sich inhaltlich mit [[HomeMatic Type Thermostat#Templates]].}}
{{Infobox Modul
|ModPurpose=Behandlung von Wochenplänen für Thermostate
|ModType=d
|ModCmdRef=HMinfo Weekplan
|ModForumArea=HomeMatic
|ModTechName=98_HMinfo.pm
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])
}}

'''HMInfo TempList''' ist eine Funktion des Moduls [[Homematic_HMInfo|HMInfo]] das es erlaubt Temperaturlisten (Wochenpläne) von [[HomeMatic Type Thermostat|Thermostaten]] zu Verwalten.

== Einleitung==
Homematic bietet eine Reihe von Heizkörperthermostaten welche mit einem Wochenplan eigenständig einen Automatikmode unterstützen. Die Erstellung und Verwaltung dieser Pläne ist im Device zumindest umständlich.
Wochenpläne werden in den Devices gespeichert und können über FHEM abgefragt werden.
== Begriffe==
Wir müssen strikt 3 Wochenpläne unterscheiden:
* ''activeList'' Wochenplan im Device. Dieser, und nur dieser ist '''wirksam'''. Er kann nicht direkt in FHEM dargestellt werden. FHEM muss die Daten auslesen um sie verarbeiten zu können. Siehe hierzu kommandos und attribute des Device:getConfig und autoReagReg.
* ''referenceList'' Wochenplan in FHEM. Für jedes Device wird ein Wochenplan (bei einigen Devices können es sogar mehrere sein) dargestellt. Dies ist die aus dem Device gelesene activeList. Es liegt in der Verantwortung des User, die Liste aktuell zu halten.
* ''tempTemplates'' Vorlagen für Wochenpläne. Diese werden in Files erstellt. Man kann Devices eines der tempTemplates zuweisen um es zu prüfen oder einzuspielen.

== Wochenplan Files==
=== Mögliche Files===
tempListTemplates werden immer in Files verwaltet. Man kann Templates in mehreren Files verwalten. Ferner gibt es unterschiedliche Methoden, ein File zu spezifizieren.
* '''attr tempListTmpl im Device''': hier spezifiziert man das Template. Will man sich von tempaltes entkoppeln sollte man '''tempListTmpl none''' unbedingt setzen.
** '''Wohnzimmer''': das template '''Wohnzimmer''' wird im default File gesucht
** '''myWeekplan.cfg:Wohnzimmer''': das template '''Wohnzimmer''' wird im File ''myWeekplan.cfg'' mit relativen Pfad von FHEM home gesucht
** '''./setup/myWeekplan.cfg:Wohnzimmer''': das template '''Wohnzimmer''' wird im File ''myWeekplan.cfg'' mit relativen Pfad ''./setup'' gesucht
** '''/opt/fhem/myWeekplan.cfg:Wohnzimmer''': das template '''Wohnzimmer''' wird im File ''myWeekplan.cfg'' mit absoluten Pfad ''/opt/fhem/'' gesucht
* '''attr configTempFile in HMInfo''': spezifiziert weekplan configurationsfiles. Es ist eine Liste Wochenplan Files welche genutzt werden. Ist das Attribut nicht gesetzt wird als ''default tempList.cfg'' genutzt.
** '''attr hm configTempFile myWeekPlan.cfg''': FHEM kennt ein File mit Wochenplan. Dies ist auch das Default für alle tempListTmpl in denen kein File spezifiziert.
** '''attr hm configTempFile mySummerPlan.cfg,myWinterPlan.cfg,myPartyPlan.cfg''': FHEM sind 3 Files bekannt. Der erste Eintrag ''mySummerPlan.cfg'' ist der Default für tempListTmpl .
* '''attr configDir in HMInfo''': spezifiziert einen Pfad, der ''auch'' für configTemplFile genutzt wird. Es erleichtert Konfigurations-Dateien in einem separaten Verzeichnis anzulegen. ''attr hm configDir setup'' wäre ein sinnvoller Eintrag. Das Verzeichnis ''setup'' unter fhem sollte erstellt werden. Ist das Attribut nicht gesetzt ist fhemHome der default.

=== Der File Inhalt - Syntax ===
entities:HK1,HK2
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
R_1_tempListSun>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
R_2_tempListMon>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_3_tempListTue>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 15.0
R_4_tempListWed>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_5_tempListThu>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_6_tempListFri>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 14.0
entities:HK3
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
R_1_tempListSun>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
R_2_tempListMon>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_3_tempListTue>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 15.0
R_4_tempListWed>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_5_tempListThu>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_6_tempListFri>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 14.0

* '''entities''': ist der Name des Wochenplans. Eine Liste kann mehrere Namen haben, welche mit Komma separiert werden.
** ein Name darf in einem File '''nicht''' doppelt vorkommen.
** der gleiche Name darf in unterschiedlichen File genutzt werden.
* '''R_0_tempListSat>''': sind die Einträge je Wochentag. Es muss ein Eintrag je Wochentag vorhanden sein.
* '''08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0''': gemäß homematic syntax fängt der Plan immer um 00:00Uhr an. Das erste Paar 08:00 14.0 bedeuted, dass von 00:00 bis 08:00 eine Temperatur von 14.0 eingestellt werden soll. 15:00 18.0 bedeuted das von 08:00 bis 15:00 18.0 Grad einzustellen sind
** es sind immer Paare einzutragen
** der Beginn um 00:00 ist nicht einzutragen
** der Letzte Eintrag '''muss''' 24:00 an jeden Tag sein
** Uhrzeiten sind auf halbe Stunden beschränkt. Einträge 08:00 und 08:30 sind gültig. 08:20 ist ungültig.
==== Erstellen des ersten Files====
Hat man HMInfo eingerichtet kann man alle ''referenceList'' in das File schreiben und dann mit der Bearbeitung beginnen. Vorab sollte man '''nach Wunsch''' folgendes einstellen:
attr hm configDir setup
attr hm configTempFile myWeekplan.cfg
set hm tempListG save

* '''set hm tempListG save''': es wird für jedes Device die ''referenceList'' in das File angehängt. Entity ist der Name des Thermostats. Das Attribut tempListTmpl ist hierbei nicht relevant.
Das File kann nun mit einem Editor bearbeitet werden. Wochenpläne können zusammengefasst und verändert werden.

=== HMInfo Kommandos ===
* set hm '''tempList''' und '''tempListG''': Die Kommandos sind quasi identisch. Die Duplizierung ist dem FHEM Webfrontend geschuldet. Damit man ein pull-down bekommen kann sind weitere Parameter verboten. '''G''' steht für global und zeigt ein pull-down. Ohne G kann man die üblichen Filter aus HMInfo nutzen.
* '''tempList save''':Speichert die ''referenceList'' in das tempList file anhängend.
* '''tempList verify''':vergleicht die ''referenceList'' mit dem im attribut tempListTmpl definierten Wochenplan. Abweichungen werden angezeigt aber nicht behoben. Diese Prüfung ist auch Teil von HMInfo ''configCheck''.
* '''tempList restore''':wie ''verify', jedoch werden alle Unterschiede in das Device geschrieben. Zu beachten ist hierbei die Verzögerung beim Schreiben (siehe HMInfo protoEvents, Device Status und Beschreibung des Device). Ferner ist zu beachten, dass nach dem Schreiben die ''referenceList'' erneuert werden muss um sinnvoll weiter arbeiten zu können. Siehe '''autoReadReg''' welcher auf Level 5 empfohlen wird. Ein restore kann jederzeit ausgeführt werden. Sind alle Daten aktuell wird '''keine''' Temperaturliste geschrieben. Es erfolgt keinerlei Funkverkehr.
* '''tempList status''':gibt eine Übersicht über genutzte Templates.

==Nutzungsbeispiele==
=== Mehrere Heizkörper in einem Raum===
Wenn sich in einem Raum mehrere Heizkörperthermostate befinden, sollten diese – wie in [[HM-CC-RT-DN]] beschrieben – gepeert werden.
HomeMatic geht davon aus, dass alle HM-CC-RT-DNs den selben Wochenplan haben (gilt ggf. auch für einen zugehörigen [[HM-TC-IT-WM-W-EU]]).

Um dies zu erreichen definiert man einen Wochenplan für das Zimmer, beispielsweise <code>Wohnzimmer.cfg</code>. Anschließend wird dieser Wochenplan allen Teammitgliedern zugewiesen:

attr <HM-CC-RT-DN#1>_Clima tempListTmpl Wohnzimmer
attr <HM-CC-RT-DN#2>_Clima tempListTmpl Wohnzimmer
attr <HM-CC-RT-DN#3>_Clima tempListTmpl Wohnzimmer
attr <HM-TC-IT-WM-W-EU>_Climate tempListTmpl Wohnzimmer
set hm tempListG restore

=== Mehrere Heizkörper mit gleichen Profil===
Will man Wohnräume identisch behandeln im Hinblick auf den Wochenplan weisst man den Thermostaten identische Profile zu.

attr RTSusi_Clima tempListTmpl Kinderzimmer
attr RTjonas_Clima tempListTmpl Kinderzimmer
attr RTwohnzimmer_Clima tempListTmpl Kinderzimmer
set hm tempListG restore
=== Wohnungsnutzung umschalten===
Das Heizprofil kann man Zentral umstellen. Verlässt man die Wohnung zum Urlaub, der Sommer naht, man macht die üblich 3-Woche Party... . Alle Thermostate sollen umgestellt werden, zentral mit wenigen Kommandos, einfach zu prüfen. Sinnvoll ist es mehrere tempList.cfg Files anzulegen. Nehmen wir 4 Files an, Winter, Urlaub zu hause UrlaubIn, Urlaub nicht zu hause UrlaubOut sowie Sommer. Ferner hat man (der Einfachheit halber) 3 RTs: RTwohn, RTschlaf, RTkueche.
Die RTs haben jeweils ihr attr tempListTmpl gesetzt entsprechend ihrem Namen.
Man legt also die 4 Files an mit entities die man zusammenfassen kann (templisten muss man natürlich befüllen:
File Winter.cfg
entity: RTwohn
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...
entity: RTschlaf
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...
entity: RTkueche
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...

File UrlaubIn.cfg
entity: RTwohn,RTkueche
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...
entity: RTschlaf
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...

File UrlaubOut.cfg
entity: RTwohn,RTschlaf,RTkueche
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...

File Sommer.cfg
entity: RTwohn,RTschlaf,RTkueche
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...

In HMInfo sollte man nun verwalten:
attr RTwohn_Clima tempListTmpl RTwohn
attr RTkueche_Clima tempListTmpl RTkueche
attr RTschlaf_Clima tempListTmpl RTschlaf
attr hm configTempFile Winter.cfg,Sommer.cfg,UrlaubIn.cfg,UrlaubOut.cfg

Winter.cfg ist nun default. Mit set hm tempListG verify kann man prüfen, dass es entsprechend genutzt ist. Nun will man in Urlaub fahren. Man schaltet das Default durch umstellen der Reihenfolge um und aktiviert es durch ein restore:
attr hm configTempFile UrlaubOut.cfg,Winter.cfg,Sommer.cfg,UrlaubIn.cfg
attr hm tempListG restore

UrlaubOut.cfg ist default. Alle notwendigen Änderungen werden in die RTs programmiert.
Unberührt bleibt Opas Zimmer, der nicht das default file sondern ein dediziertes nutzt. Das template RTopa muss also nur im File Winter.cfg vorhanden sein:
attr RTopa_Clima tempListTmpl Winter.cfg:RTopa

[[Kategorie:HomeMatic Components]]
[[Kategorie:HOWTOS]]

HM-TC-IT-WM-W-EU

2016-01-26T14:27:52Z

Octo: Weiterleitung angelegt.

#REDIRECT [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]]

HomeMatic HMInfo TempList/Weekplan

2016-01-26T14:20:15Z

Octo: Todo-Block for Infobox (bessere Darstellung).

{{Todo|Dieser Artikel überschneidet sich inhaltlich mit [[HomeMatic Type Thermostat#Templates]].}}
{{Infobox Modul
|ModPurpose=Behandlung von Wochenplänen für Thermostate
|ModType=d
|ModCmdRef=HMinfo Weekplan
|ModForumArea=HomeMatic
|ModTechName=98_HMinfo.pm
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])
}}

'''HMInfo TempList''' ist eine Funktion des Moduls [[Homematic_HMInfo|HMInfo]] das es erlaubt Temperaturlisten (Wochenpläne) von [[HomeMatic Type Thermostat|Thermostaten]] zu Verwalten.

== Einleitung==
Homematic bietet eine Reihe von Heizkörperthermostaten welche mit einem Wochenplan eigenständig einen Automatikmode unterstützen. Die Erstellung und Verwaltung dieser Pläne ist im Device zumindest umständlich.
Wochenpläne werden in den Devices gespeichert und können über FHEM abgefragt werden.
== Begriffe==
Wir müssen strikt 3 Wochenpläne unterscheiden:
* ''activeList'' Wochenplan im Device. Dieser, und nur dieser ist '''wirksam'''. Er kann nicht direkt in FHEM dargestellt werden. FHEM muss die Daten auslesen um sie verarbeiten zu können. Siehe hierzu kommandos und attribute des Device:getConfig und autoReagReg.
* ''referenceList'' Wochenplan in FHEM. Für jedes Device wird ein Wochenplan (bei einigen Devices können es sogar mehrere sein) dargestellt. Dies ist die aus dem Device gelesene activeList. Es liegt in der Verantwortung des User, die Liste aktuell zu halten.
* ''tempTemplates'' Vorlagen für Wochenpläne. Diese werden in Files erstellt. Man kann Devices eines der tempTemplates zuweisen um es zu prüfen oder einzuspielen.

== Wochenplan Files==
=== Mögliche Files===
tempListTemplates werden immer in Files verwaltet. Man kann Templates in mehreren Files verwalten. Ferner gibt es unterschiedliche Methoden, ein File zu spezifizieren.
* '''attr tempListTmpl im Device''': hier spezifiziert man das Template. Will man sich von tempaltes entkoppeln sollte man '''tempListTmpl none''' unbedingt setzen.
** '''Wohnzimmer''': das template '''Wohnzimmer''' wird im default File gesucht
** '''myWeekplan.cfg:Wohnzimmer''': das template '''Wohnzimmer''' wird im File ''myWeekplan.cfg'' mit relativen Pfad von FHEM home gesucht
** '''./setup/myWeekplan.cfg:Wohnzimmer''': das template '''Wohnzimmer''' wird im File ''myWeekplan.cfg'' mit relativen Pfad ''./setup'' gesucht
** '''/opt/fhem/myWeekplan.cfg:Wohnzimmer''': das template '''Wohnzimmer''' wird im File ''myWeekplan.cfg'' mit absoluten Pfad ''/opt/fhem/'' gesucht
* '''attr configTempFile in HMInfo''': spezifiziert weekplan configurationsfiles. Es ist eine Liste Wochenplan Files welche genutzt werden. Ist das Attribut nicht gesetzt wird als ''default tempList.cfg'' genutzt.
** '''attr hm configTempFile myWeekPlan.cfg''': FHEM kennt ein File mit Wochenplan. Dies ist auch das Default für alle tempListTmpl in denen kein File spezifiziert.
** '''attr hm configTempFile mySummerPlan.cfg,myWinterPlan.cfg,myPartyPlan.cfg''': FHEM sind 3 Files bekannt. Der erste Eintrag ''mySummerPlan.cfg'' ist der Default für tempListTmpl .
* '''attr configDir in HMInfo''': spezifiziert einen Pfad, der ''auch'' für configTemplFile genutzt wird. Es erleichtert Konfigurations-Dateien in einem separaten Verzeichnis anzulegen. ''attr hm configDir setup'' wäre ein sinnvoller Eintrag. Das Verzeichnis ''setup'' unter fhem sollte erstellt werden. Ist das Attribut nicht gesetzt ist fhemHome der default.

=== Der File Inhalt - Syntax ===
entities:HK1,HK2
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
R_1_tempListSun>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
R_2_tempListMon>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_3_tempListTue>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 15.0
R_4_tempListWed>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_5_tempListThu>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_6_tempListFri>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 14.0
entities:HK3
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
R_1_tempListSun>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
R_2_tempListMon>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_3_tempListTue>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 15.0
R_4_tempListWed>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_5_tempListThu>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_6_tempListFri>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 14.0

* '''entities''': ist der Name des Wochenplans. Eine Liste kann mehrere Namen haben, welche mit Komma separiert werden.
** ein Name darf in einem File '''nicht''' doppelt vorkommen.
** der gleiche Name darf in unterschiedlichen File genutzt werden.
* '''R_0_tempListSat>''': sind die Einträge je Wochentag. Es muss ein Eintrag je Wochentag vorhanden sein.
* '''08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0''': gemäß homematic syntax fängt der Plan immer um 00:00Uhr an. Das erste Paar 08:00 14.0 bedeuted, dass von 00:00 bis 08:00 eine Temperatur von 14.0 eingestellt werden soll. 15:00 18.0 bedeuted das von 08:00 bis 15:00 18.0 Grad einzustellen sind
** es sind immer Paare einzutragen
** der Beginn um 00:00 ist nicht einzutragen
** der Letzte Eintrag '''muss''' 24:00 an jeden Tag sein
** Uhrzeiten sind auf halbe Stunden beschränkt. Einträge 08:00 und 08:30 sind gültig. 08:20 ist ungültig.
==== Erstellen des ersten Files====
Hat man HMInfo eingerichtet kann man alle ''referenceList'' in das File schreiben und dann mit der Bearbeitung beginnen. Vorab sollte man '''nach Wunsch''' folgendes einstellen:
attr hm configDir setup
attr hm configTempFile myWeekplan.cfg
set hm tempListG save

* '''set hm tempListG save''': es wird für jedes Device die ''referenceList'' in das File angehängt. Entity ist der Name des Thermostats. Das Attribut tempListTmpl ist hierbei nicht relevant.
Das File kann nun mit einem Editor bearbeitet werden. Wochenpläne können zusammengefasst und verändert werden.

=== HMInfo Kommandos ===
* set hm '''tempList''' und '''tempListG''': Die Kommandos sind quasi identisch. Die Duplizierung ist dem FHEM Webfrontend geschuldet. Damit man ein pull-down bekommen kann sind weitere Parameter verboten. '''G''' steht für global und zeigt ein pull-down. Ohne G kann man die üblichen Filter aus HMInfo nutzen.
* '''tempList save''':Speichert die ''referenceList'' in das tempList file anhängend.
* '''tempList verify''':vergleicht die ''referenceList'' mit dem im attribut tempListTmpl definierten Wochenplan. Abweichungen werden angezeigt aber nicht behoben. Diese Prüfung ist auch Teil von HMInfo ''configCheck''.
* '''tempList restore''':wie ''verify', jedoch werden alle Unterschiede in das Device geschrieben. Zu beachten ist hierbei die Verzögerung beim Schreiben (siehe HMInfo protoEvents, Device Status und Beschreibung des Device). Ferner ist zu beachten, dass nach dem Schreiben die ''referenceList'' erneuert werden muss um sinnvoll weiter arbeiten zu können. Siehe '''autoReadReg''' welcher auf Level 5 empfohlen wird. Ein restore kann jederzeit ausgeführt werden. Sind alle Daten aktuell wird '''keine''' Temperaturliste geschrieben. Es erfolgt keinerlei Funkverkehr.
* '''tempList status''':gibt eine Übersicht über genutzte Templates.

==Nutzungsbeispiele==
=== Mehrere Heizkörper in einem Raum===
Nutzt man mehrere Thermostate in einem Raum sollte man diese Koppel. Hierzu sind die RTs zu peeren - dies ist im RT nachzulesen.
Da HomeMatic davon ausgeht, dass Wochenpläne jeweils in allen RTs zu Verfügung stehen und Synchron sind (gilt auch für TC-IT, welches mit einem RT gekoppelt ist) sollte man dies auch so einreichten. Man definiert demnach ein Profil für das Zimmer im File WochenplanFile. Diesen Wochenplan weisst man nun allen Teammitgliedern zu.
attr RT1_Clima tempListTmpl Wohnzimmer
attr RT2_Clima tempListTmpl Wohnzimmer
attr RT3_Clima tempListTmpl Wohnzimmer
attr TCwz_Climate tempListTmpl Wohnzimmer
set hm tempListG restore

=== Mehrere Heizkörper mit gleichen Profil===
Will man Wohnräume identisch behandeln im Hinblick auf den Wochenplan weisst man den Thermostaten identische Profile zu.

attr RTSusi_Clima tempListTmpl Kinderzimmer
attr RTjonas_Clima tempListTmpl Kinderzimmer
attr RTwohnzimmer_Clima tempListTmpl Kinderzimmer
set hm tempListG restore
=== Wohnungsnutzung umschalten===
Das Heizprofil kann man Zentral umstellen. Verlässt man die Wohnung zum Urlaub, der Sommer naht, man macht die üblich 3-Woche Party... . Alle Thermostate sollen umgestellt werden, zentral mit wenigen Kommandos, einfach zu prüfen. Sinnvoll ist es mehrere tempList.cfg Files anzulegen. Nehmen wir 4 Files an, Winter, Urlaub zu hause UrlaubIn, Urlaub nicht zu hause UrlaubOut sowie Sommer. Ferner hat man (der Einfachheit halber) 3 RTs: RTwohn, RTschlaf, RTkueche.
Die RTs haben jeweils ihr attr tempListTmpl gesetzt entsprechend ihrem Namen.
Man legt also die 4 Files an mit entities die man zusammenfassen kann (templisten muss man natürlich befüllen:
File Winter.cfg
entity: RTwohn
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...
entity: RTschlaf
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...
entity: RTkueche
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...

File UrlaubIn.cfg
entity: RTwohn,RTkueche
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...
entity: RTschlaf
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...

File UrlaubOut.cfg
entity: RTwohn,RTschlaf,RTkueche
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...

File Sommer.cfg
entity: RTwohn,RTschlaf,RTkueche
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...

In HMInfo sollte man nun verwalten:
attr RTwohn_Clima tempListTmpl RTwohn
attr RTkueche_Clima tempListTmpl RTkueche
attr RTschlaf_Clima tempListTmpl RTschlaf
attr hm configTempFile Winter.cfg,Sommer.cfg,UrlaubIn.cfg,UrlaubOut.cfg

Winter.cfg ist nun default. Mit set hm tempListG verify kann man prüfen, dass es entsprechend genutzt ist. Nun will man in Urlaub fahren. Man schaltet das Default durch umstellen der Reihenfolge um und aktiviert es durch ein restore:
attr hm configTempFile UrlaubOut.cfg,Winter.cfg,Sommer.cfg,UrlaubIn.cfg
attr hm tempListG restore

UrlaubOut.cfg ist default. Alle notwendigen Änderungen werden in die RTs programmiert.
Unberührt bleibt Opas Zimmer, der nicht das default file sondern ein dediziertes nutzt. Das template RTopa muss also nur im File Winter.cfg vorhanden sein:
attr RTopa_Clima tempListTmpl Winter.cfg:RTopa

[[Kategorie:HomeMatic Components]]
[[Kategorie:HOWTOS]]

HomeMatic HMInfo TempList/Weekplan

2016-01-26T14:19:24Z

Octo: Überschneidungs-Hinweis eingefügt.

{{Infobox Modul
|ModPurpose=Behandlung von Wochenplänen für Thermostate
|ModType=d
|ModCmdRef=HMinfo Weekplan
|ModForumArea=HomeMatic
|ModTechName=98_HMinfo.pm
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])
}}

{{Todo|Dieser Artikel überschneidet sich inhaltlich mit [[HomeMatic Type Thermostat#Templates]].}}

'''HMInfo TempList''' ist eine Funktion des Moduls [[Homematic_HMInfo|HMInfo]] das es erlaubt Temperaturlisten (Wochenpläne) von [[HomeMatic Type Thermostat|Thermostaten]] zu Verwalten.

== Einleitung==
Homematic bietet eine Reihe von Heizkörperthermostaten welche mit einem Wochenplan eigenständig einen Automatikmode unterstützen. Die Erstellung und Verwaltung dieser Pläne ist im Device zumindest umständlich.
Wochenpläne werden in den Devices gespeichert und können über FHEM abgefragt werden.
== Begriffe==
Wir müssen strikt 3 Wochenpläne unterscheiden:
* ''activeList'' Wochenplan im Device. Dieser, und nur dieser ist '''wirksam'''. Er kann nicht direkt in FHEM dargestellt werden. FHEM muss die Daten auslesen um sie verarbeiten zu können. Siehe hierzu kommandos und attribute des Device:getConfig und autoReagReg.
* ''referenceList'' Wochenplan in FHEM. Für jedes Device wird ein Wochenplan (bei einigen Devices können es sogar mehrere sein) dargestellt. Dies ist die aus dem Device gelesene activeList. Es liegt in der Verantwortung des User, die Liste aktuell zu halten.
* ''tempTemplates'' Vorlagen für Wochenpläne. Diese werden in Files erstellt. Man kann Devices eines der tempTemplates zuweisen um es zu prüfen oder einzuspielen.

== Wochenplan Files==
=== Mögliche Files===
tempListTemplates werden immer in Files verwaltet. Man kann Templates in mehreren Files verwalten. Ferner gibt es unterschiedliche Methoden, ein File zu spezifizieren.
* '''attr tempListTmpl im Device''': hier spezifiziert man das Template. Will man sich von tempaltes entkoppeln sollte man '''tempListTmpl none''' unbedingt setzen.
** '''Wohnzimmer''': das template '''Wohnzimmer''' wird im default File gesucht
** '''myWeekplan.cfg:Wohnzimmer''': das template '''Wohnzimmer''' wird im File ''myWeekplan.cfg'' mit relativen Pfad von FHEM home gesucht
** '''./setup/myWeekplan.cfg:Wohnzimmer''': das template '''Wohnzimmer''' wird im File ''myWeekplan.cfg'' mit relativen Pfad ''./setup'' gesucht
** '''/opt/fhem/myWeekplan.cfg:Wohnzimmer''': das template '''Wohnzimmer''' wird im File ''myWeekplan.cfg'' mit absoluten Pfad ''/opt/fhem/'' gesucht
* '''attr configTempFile in HMInfo''': spezifiziert weekplan configurationsfiles. Es ist eine Liste Wochenplan Files welche genutzt werden. Ist das Attribut nicht gesetzt wird als ''default tempList.cfg'' genutzt.
** '''attr hm configTempFile myWeekPlan.cfg''': FHEM kennt ein File mit Wochenplan. Dies ist auch das Default für alle tempListTmpl in denen kein File spezifiziert.
** '''attr hm configTempFile mySummerPlan.cfg,myWinterPlan.cfg,myPartyPlan.cfg''': FHEM sind 3 Files bekannt. Der erste Eintrag ''mySummerPlan.cfg'' ist der Default für tempListTmpl .
* '''attr configDir in HMInfo''': spezifiziert einen Pfad, der ''auch'' für configTemplFile genutzt wird. Es erleichtert Konfigurations-Dateien in einem separaten Verzeichnis anzulegen. ''attr hm configDir setup'' wäre ein sinnvoller Eintrag. Das Verzeichnis ''setup'' unter fhem sollte erstellt werden. Ist das Attribut nicht gesetzt ist fhemHome der default.

=== Der File Inhalt - Syntax ===
entities:HK1,HK2
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
R_1_tempListSun>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
R_2_tempListMon>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_3_tempListTue>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 15.0
R_4_tempListWed>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_5_tempListThu>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_6_tempListFri>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 14.0
entities:HK3
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
R_1_tempListSun>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
R_2_tempListMon>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_3_tempListTue>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 15.0
R_4_tempListWed>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_5_tempListThu>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
R_6_tempListFri>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 14.0

* '''entities''': ist der Name des Wochenplans. Eine Liste kann mehrere Namen haben, welche mit Komma separiert werden.
** ein Name darf in einem File '''nicht''' doppelt vorkommen.
** der gleiche Name darf in unterschiedlichen File genutzt werden.
* '''R_0_tempListSat>''': sind die Einträge je Wochentag. Es muss ein Eintrag je Wochentag vorhanden sein.
* '''08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0''': gemäß homematic syntax fängt der Plan immer um 00:00Uhr an. Das erste Paar 08:00 14.0 bedeuted, dass von 00:00 bis 08:00 eine Temperatur von 14.0 eingestellt werden soll. 15:00 18.0 bedeuted das von 08:00 bis 15:00 18.0 Grad einzustellen sind
** es sind immer Paare einzutragen
** der Beginn um 00:00 ist nicht einzutragen
** der Letzte Eintrag '''muss''' 24:00 an jeden Tag sein
** Uhrzeiten sind auf halbe Stunden beschränkt. Einträge 08:00 und 08:30 sind gültig. 08:20 ist ungültig.
==== Erstellen des ersten Files====
Hat man HMInfo eingerichtet kann man alle ''referenceList'' in das File schreiben und dann mit der Bearbeitung beginnen. Vorab sollte man '''nach Wunsch''' folgendes einstellen:
attr hm configDir setup
attr hm configTempFile myWeekplan.cfg
set hm tempListG save

* '''set hm tempListG save''': es wird für jedes Device die ''referenceList'' in das File angehängt. Entity ist der Name des Thermostats. Das Attribut tempListTmpl ist hierbei nicht relevant.
Das File kann nun mit einem Editor bearbeitet werden. Wochenpläne können zusammengefasst und verändert werden.

=== HMInfo Kommandos ===
* set hm '''tempList''' und '''tempListG''': Die Kommandos sind quasi identisch. Die Duplizierung ist dem FHEM Webfrontend geschuldet. Damit man ein pull-down bekommen kann sind weitere Parameter verboten. '''G''' steht für global und zeigt ein pull-down. Ohne G kann man die üblichen Filter aus HMInfo nutzen.
* '''tempList save''':Speichert die ''referenceList'' in das tempList file anhängend.
* '''tempList verify''':vergleicht die ''referenceList'' mit dem im attribut tempListTmpl definierten Wochenplan. Abweichungen werden angezeigt aber nicht behoben. Diese Prüfung ist auch Teil von HMInfo ''configCheck''.
* '''tempList restore''':wie ''verify', jedoch werden alle Unterschiede in das Device geschrieben. Zu beachten ist hierbei die Verzögerung beim Schreiben (siehe HMInfo protoEvents, Device Status und Beschreibung des Device). Ferner ist zu beachten, dass nach dem Schreiben die ''referenceList'' erneuert werden muss um sinnvoll weiter arbeiten zu können. Siehe '''autoReadReg''' welcher auf Level 5 empfohlen wird. Ein restore kann jederzeit ausgeführt werden. Sind alle Daten aktuell wird '''keine''' Temperaturliste geschrieben. Es erfolgt keinerlei Funkverkehr.
* '''tempList status''':gibt eine Übersicht über genutzte Templates.

==Nutzungsbeispiele==
=== Mehrere Heizkörper in einem Raum===
Nutzt man mehrere Thermostate in einem Raum sollte man diese Koppel. Hierzu sind die RTs zu peeren - dies ist im RT nachzulesen.
Da HomeMatic davon ausgeht, dass Wochenpläne jeweils in allen RTs zu Verfügung stehen und Synchron sind (gilt auch für TC-IT, welches mit einem RT gekoppelt ist) sollte man dies auch so einreichten. Man definiert demnach ein Profil für das Zimmer im File WochenplanFile. Diesen Wochenplan weisst man nun allen Teammitgliedern zu.
attr RT1_Clima tempListTmpl Wohnzimmer
attr RT2_Clima tempListTmpl Wohnzimmer
attr RT3_Clima tempListTmpl Wohnzimmer
attr TCwz_Climate tempListTmpl Wohnzimmer
set hm tempListG restore

=== Mehrere Heizkörper mit gleichen Profil===
Will man Wohnräume identisch behandeln im Hinblick auf den Wochenplan weisst man den Thermostaten identische Profile zu.

attr RTSusi_Clima tempListTmpl Kinderzimmer
attr RTjonas_Clima tempListTmpl Kinderzimmer
attr RTwohnzimmer_Clima tempListTmpl Kinderzimmer
set hm tempListG restore
=== Wohnungsnutzung umschalten===
Das Heizprofil kann man Zentral umstellen. Verlässt man die Wohnung zum Urlaub, der Sommer naht, man macht die üblich 3-Woche Party... . Alle Thermostate sollen umgestellt werden, zentral mit wenigen Kommandos, einfach zu prüfen. Sinnvoll ist es mehrere tempList.cfg Files anzulegen. Nehmen wir 4 Files an, Winter, Urlaub zu hause UrlaubIn, Urlaub nicht zu hause UrlaubOut sowie Sommer. Ferner hat man (der Einfachheit halber) 3 RTs: RTwohn, RTschlaf, RTkueche.
Die RTs haben jeweils ihr attr tempListTmpl gesetzt entsprechend ihrem Namen.
Man legt also die 4 Files an mit entities die man zusammenfassen kann (templisten muss man natürlich befüllen:
File Winter.cfg
entity: RTwohn
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...
entity: RTschlaf
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...
entity: RTkueche
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...

File UrlaubIn.cfg
entity: RTwohn,RTkueche
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...
entity: RTschlaf
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...

File UrlaubOut.cfg
entity: RTwohn,RTschlaf,RTkueche
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...

File Sommer.cfg
entity: RTwohn,RTschlaf,RTkueche
R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
...

In HMInfo sollte man nun verwalten:
attr RTwohn_Clima tempListTmpl RTwohn
attr RTkueche_Clima tempListTmpl RTkueche
attr RTschlaf_Clima tempListTmpl RTschlaf
attr hm configTempFile Winter.cfg,Sommer.cfg,UrlaubIn.cfg,UrlaubOut.cfg

Winter.cfg ist nun default. Mit set hm tempListG verify kann man prüfen, dass es entsprechend genutzt ist. Nun will man in Urlaub fahren. Man schaltet das Default durch umstellen der Reihenfolge um und aktiviert es durch ein restore:
attr hm configTempFile UrlaubOut.cfg,Winter.cfg,Sommer.cfg,UrlaubIn.cfg
attr hm tempListG restore

UrlaubOut.cfg ist default. Alle notwendigen Änderungen werden in die RTs programmiert.
Unberührt bleibt Opas Zimmer, der nicht das default file sondern ein dediziertes nutzt. Das template RTopa muss also nur im File Winter.cfg vorhanden sein:
attr RTopa_Clima tempListTmpl Winter.cfg:RTopa

[[Kategorie:HomeMatic Components]]
[[Kategorie:HOWTOS]]

HomeMatic Type Thermostat

2016-01-26T14:19:17Z

Octo: /* Templates */ Überschneidungs-Hinweis eingefügt.

{{HMType}} 
HomeMatic-Geräte vom Typ '''Thermostat''' ermöglichen es die Raumtemperatur zu regeln. Derzeit werden die folgenden Geräte unterstützt:

* [[HM-CC-RT-DN Funk-Heizkörperthermostat]]
* [[HM-CC-TC Funk-Wandthermostat]]
* [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]]

Die Geräte unterscheiden sich im Funktionsumfang und in einigen Details. Einzelheiten sind im jeweiligen Wiki-Topic dokumentiert.
Gemeinsam ist allen Geräten, dass sie eine oder mehrere ''Temperaturlisten'', oft auch ''Wochenprogramm'' genannt, unterstützen.

== Temperaturlisten ==

Temperaturlisten erlauben die Solltemperatur in Abhängigkeit des Wochentags und der Urzeit einzustellen.

{{Hinweis|Der zuständige Kanal heißt bei den Wandthermostaten ''_Climate'', beim [[HM-CC-RT-DN]] ''_Clima'' (ohne "te").}}

=== Allgemein ===

Temperaturlisten werden mit folgenden sieben Kommandos gesetzt, eines für jeden Wochentag: ''tempListMon'', ''tempListTue'', ''tempListWed'', ''tempListThu'', ''tempListFri'', ''tempListSat'' und ''tempListSun''. Die Kommandos müssen auf den Kanal ''_Climate'' (beim [[HM-CC-RT-DN]]: ''_Clima'' ohne "te") angewendet werden.

'''Syntax:'''

set <thermostat>_Climate tempList<Tag> [<End-Zeitpunkt> <Temperatur> […]] 24:00 <Temperatur>

Der (implizite) Start-Zeitpunkt einer Temperaturliste ist 0:00 Uhr. Es folgen Paare von End-Zeitpunkt und (Soll-)Temperatur. Die Zeitpunkte können 30-Minuten genau, die Temperaturen 0,1-Kelvin genau eingestellt werden. Der letzte End-Zeitpunkt ''muss'' 24:00 Uhr sein.

'''Beispiel:'''

set <thermostat>_Climate tempListFri 05:30 16.0 07:00 22.0 16:00 18.5 21:30 21.0 24:00 16.0

Dieses Kommando setzt das Temperaturprofil für Freitag. Der (implizite) Start-Zeitpunkt ist 0:00 Uhr. Es folgen paare von End-Zeitpunkt und Solltemperatur. Der letzte End-Zeitpunkt ''muss'' 24:00 Uhr sein. Das Beispiel stellt folgendes Profil ein:
{| class="wikitable"
! Zeitspanne
! Temperatur
|-
| style="color: blue;" | 00:00–05:30 Uhr
| style="color: blue; text-align: right;" | 16.0 °C
|-
| style="color: red;" | 05:30–07:00 Uhr
| style="color: red; text-align: right;" | 22.0 °C
|-
| style="color: green;" | 07:00–16:00 Uhr
| style="color: green; text-align: right;" | 18.5 °C
|-
| style="color: orange;" | 16:00–21:30 Uhr
| style="color: orange; text-align: right;" | 21.0 °C
|-
| style="color: blue;" | 21:30–24:00 Uhr
| style="color: blue; text-align: right;" | 16.0 °C
|}

=== Massenänderung ===

Bei Änderung mehrerer Tage empfiehlt es sich die Änderungen mit <code>prep</code> vorzubereiten und anschließend mit <code>exec</code> an das Gerät zu übertragen, da die Übertragung "teuer" (zeitaufwendig) ist.

'''Beispiel:'''

set Thermostat_Climate tempListMon prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0
set Thermostat_Climate tempListTue prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0
set Thermostat_Climate tempListWed prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0
set Thermostat_Climate tempListThu prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0
set Thermostat_Climate tempListFri prep 05:30 19.0 07:00 20.5 15:00 19.0 20:30 20.0 24:00 17.0
set Thermostat_Climate tempListSat prep 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0
set Thermostat_Climate tempListSun exec 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0

=== Alternative Wochenprogramme setzen (HM-TC-IT-WM-W-EU) ===

Das [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]] verfügt über weitere Wochenprogramme, P2 und P3.

Um das Wochenprogramm "P2" eines HM-TC-IT-WM-W-EU zu setzen, wird der Temperaturliste "p2" vorangestellt.

'''Beispiel:'''

set <HM-TC-IT-WM-W-EU>_Climate tempListSat p2 07:30 16.0 17:00 20.0 19:00 21.0 24:00 16.0

===Templates ===
{{Todo|Dieser Absatz überschneidet sich inhaltlich mit [[HomeMatic HMInfo TempList/Weekplan]].}}

Etwas komfortabler kann man Wochenprogramme in einem File verwalten. Man kann beliebig viele templates erzeugen und diese in einem File ablegen. Diese unterschiedlichen Wochenprogramme kann man den Thermostaten zuweisen. So kann man ein Wochenprogramm beliebig vielen Thermostaten zuweisen. Bei Änderungen kann man alle betroffenen Thermostate, die das gleiche Template nutzen sollen, erreichen.

Zusammenfassend:
* Temperaturlisten der Devices in ein file schreiben
* Templates definieren, die man mehreren Devices zuordnen kann
* Template-Änderungen gleichzeitig in mehrere Devices einspielen
* Temperaturlisten gegen ein Template prüfen

====File erstellen und verwalten ====
Ein File mit den Temperaturlisten (Wochenplänen) muss erzeugt werden. Zur Verwaltung der Temperaturprofile sollte die Datei tempList.cfg im Verzeichnis FHEM liegen, dann kann sie mit dem Web-Interface editiert werden.
HMInfo unterstützt das speichern allen temperaturlisten in ein File mit [[Homematic_HMInfo#Speichern|temperaturListen speichern]]. Dies kann man gut als Startpunkt nutzen.
Bsp:

Angenommen HMInfo ist definiert per
define hm HMinfo
legt dieser Aufruf ein initiales Template an.
set hm tempList save FHEM/tempList.cfg

Die Wochenprogramme sollten in FHEM vorliegen. ggf. mit getConfig auslesen.

entities:tempTmpl1
tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
tempListSun>08:00 14.0 15:00 18.0 21:30 19.0 24:00 17.0
tempListMon>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListTue>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 15.0
tempListWed>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListThu>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListFri>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 14.0
entities:tempTWohnzimmer
tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 17.0
tempListSun>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
tempListMon>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListTue>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 15.0
tempListWed>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListThu>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListFri>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 14.0

====Templates zuweisen ====
Das Attribut tempListTmpl sollte man allen Thermostaten zuweisen. Dies ist dem jeweiligen Steuerungschannel zuzuweisen
attr hk1_Clima tempListTmpl setup/tempList.cfg:tempTmpl1
attr hk2_Clima tempListTmpl setup/tempList.cfg:tempTmpl1
attr hk3_Clima tempListTmpl setup/tempList.cfg:tempTWohnzimmer

In entsprechenden Kommandos muss man nun nicht mehr den Namen des Templates für den HK angeben, es wird der aus dem Attribut genommen. Man gibt das File an und dann den Namen des Templates im File.

==== Überprüfen/Einlesen ====
Mit dem verify-Kommando wird überprüft, ob das gegenwärtig vorhandene Temperaturprofil mit dem in der Datei befindlichen übereinstimmt.
set thermostat_Climate tempListTmpl verify FHEM/tempList.cfg:room1
Mit dem restore-Kommando wird das Temperaturprofil des Heizkörperthermostaten mit dem in der Datei befindlichen überschrieben.
set thermostat_Climate tempListTmpl restore FHEM/tempList.cfg:room1
* FHEM/tempList.cfg ist die Datei, in dem das Temperaturprofil zu suchen ist. '''room1''' ist der Name des Temperaturprofils, welches in der Datei gesucht wird. Wird keine Datei angegeben wird "template.cfg" im "fhem"-Verzeichnis angenommen.
Man kann einem Thermostat das '''Attribut tempListTmpl''' geben. Damit wird der Default-Name des Temperaturprofils für dieses Device gesetzt.
attr thermostat_Climate tempListTmpl FHEM/tempList.cfg:room1
set thermostat_Climate tempListTmpl
prüft das gegenwärtige Temperaturprofil gegen FHEM/tempList.cfg:room1 (da verify der Default ist). Die Prüfung des Profils ist auch Teil des configCheck von HMInfo.
Will man explizit kein Temperaturprofil zuweisen sollte man tempListTmpl auf none setzen.
set thermostat_Climate tempListTmpl restore
überschreibt das gegenwärtige Temperaturprofil des Heizkörperthermostaten mit dem in der Datei befindlichen überschrieben.

==== Templates systemweit nutzen ====
Sinnvoll erscheint es, das ganze systemweit zu machen. Man legt ein File mit allen Wochenplänen an, die man nutzen will. Dann weißt man die TemplateNamen den Thermostaten zu. Und schließlich prüft oder updates man alle Thermostate in einem System mit einem Kommando. Siehe hierzu [[Homematic_HMInfo#Temperaturlisten|HMInfo temperaturlisten]].

[[Kategorie:HomeMatic Components]]
[[Kategorie:Heizungssteuerung]]