FHEMWiki - Benutzerbeiträge [de]

Virtueller Controller VCCU

2015-02-12T08:23:26Z

Rohan: /* Setzen der IOgrp auf (fast) allen Devices mit einem einzigen Befehl */ Anpassung des Namens, einheitlich "vccu"

Ein virtueller Controller '''vccu''' ist der Protokoll-Endpunkt der Zentrale.
Weiter können Ihr IO devices zugeordnet werden und IOs dynamisch verwaltet werden.
== Wann ist eine VCCU Sinnvoll ==
Eine vccu sollte '''immer''' angelegt werden. 
FHEM erlaubt die Nutzung mehrer vccus parallel. Der Nutzer kann damit sein System in Gruppen aufteilen und jeder vccu eine Reihe von IOs zuweisen. 
Empfohlen wird die Definition einer einzigen vccu, welcher man alle IOs für HM zuweist.

Anders ausgedrückt:

Manchmal ist es sehr hilfreich, mehrere HM Sender (=IOs) im Gebäude zu verteilen. Beispielsweise weil einige Geräte nicht mehr zuverlässig in Funkreichweite sind. Die VCCU kümmert sich dann automatisch darum, mit welchem Sendemodul (also HM-CFG-LAN, HM-CFG-USB oder CUL) die einzelnen HM Aktoren am besten angesprochen werden können.

== Definition ==
=== HMId wählen ===
Eine vccu benötigt wie alle HM devices eine Adresse, mit der sie angesprochen wird. Diese muss eindeutig in System sein, man muss also eine Wählen, die noch nicht verwendet wird. 
Eine vccu wird ihre HMId an die ihr zugewiesenen IOs weitergeben. Definiert man eine vccu erst nachdem schon IOs (CUL oder HMLAN) für Homematic angelegt sind sollte die HMId des IO verwendet werden. 
Wenn die HMId im System ein-eindeitig für ein Device sein muss trifft des also nicht auf IOs zu. IOs sind keine CUL_HM devices. 
 
In der Regel nimmt man die HMId des IOs, welcher später der vccu zugeordnet werden soll.
=== Einrichten ===
define vccu CUL_HM <HMId>
attr vccu model CCU-FHEM
attr vccu IOList <io1>[,<io2>,...]

=== Auswirkungen auf IOs===
Sind IOs durch das Attribut IOList einer vccu zugewiesen werden die entsprechenden Attribute im IO gesetzt. Die HMId wird 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 internals owner und owner_CCU eingetragen. 
=== Best Current Practice ===
Folgenden Aktionen sind weiter möglich, werden aber besser in der vccu erledigt
hmPairForSec
hmPairSerial
== Dynamisches IO ==
Devices senden in der Regel immer über das gleiche IO device. Kommt es zu einem Ausfall werden keine Nachrichten mehr gesendet, auch wenn ein zweites IO bereit stehen würde. Ferner könnte man bewegliche Fernbedienungen haben, welche ihre Verbindung zu einem IO verlieren, aber über ein andere IO gut empfangen könnten. 
Es können hierzu 2 Methoden angewendet werden.
=== IO Ersatzschaltung ===
Bei stationären Devices - meist die Masse der genutzten Devices - kann man i.d.R. das beste IO finden und will dies nutzen. Eine Umschaltung auf ein 2. IO würde nur sinnvoll sein, wenn das bevorzugte IO ausgefallen ist. Diese Zuordnung macht man über
attr <dev> IOgrp <vccu>:<preferedIO>
In der Praxis könnte es heißen
attr LichtFlur IOgrp vccu:HMLAN1
FHEM sendet zum Device LichtFlur immer über HMLAN1, so lange dies verfügbar ist. Sollte HMLAN1 nicht mehr erreichbar sein wird im Attribut IOList der vccu nach einem Ersatz gesucht. 
HMLAN1 muss in der IOList der vccu eingerichtet sein, incl preferedIO. 

=== IO nach Empfangspegel ===
Bewegliche Fernbedienungen haben naturgemäß kein preferedIO. Daher wird dieser Eintrag nicht gesetzt. Es wird nun versucht, das IO mit dem aktuell besten Empfangspegel zu nutzen.
attr Fernbedienung1 IOgrp vccu

=== Bemerkungen ===
Es wird empfohlen, das Attribut IOgrp in allen Devices zu setzen. Kanäle senden nicht selbständig, haben daher auch kein Attribut IOgrp. 
Das Attribut '''IODev''' wird automatisch gesetzt, der User muss hier nichts mehr eintragen. Es ist aus Systemgründen weiter notwendig und kann sich verändern. Es zeigt das letzte genutzte output-device an. 
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

Dieser Befehl (in der Fhem-Eingabezeile eingeben und mit <Return> bestätigen) setzt das Attribut bei allen Devices, und zwar allen, deren '''DEF''' genau 6 Zeichen lang ist.

== virtuelle Kanäle der vccu==
Eine vccu kann bis zu 50 virtuelle Kanäle bedienen. Diese können als Sender/Sensoren oder Empfänger eingesetzt werden. Man kann diese Kanäle mit einem realen Kanal peeren und Aktionen triggern. 
Man peert z.B. eine virtuellen Kanal mit einem Dimmer. Nun kann man im Dimmer das Verhalten bei Tastendruck lang und kurz festlegen. Aus der Zentrale kann man schließlich den Tastendruck simulieren, der Dimmer wird reagieren. Selbstverständlich kann man einen virtuellen Kanal mit mehreren Aktoren parallel peeren und so z.B. alle lichter einer Gruppe mit einem "press" ausschalten.
=== 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]]

Virtueller Controller VCCU

2015-02-12T08:21:50Z

Rohan: /* Setzen der IOgrp auf (fast) allen Devices mit einem einzigen Befehl */ unnötigen Text gelöscht

Ein virtueller Controller '''vccu''' ist der Protokoll-Endpunkt der Zentrale.
Weiter können Ihr IO devices zugeordnet werden und IOs dynamisch verwaltet werden.
== Wann ist eine VCCU Sinnvoll ==
Eine vccu sollte '''immer''' angelegt werden. 
FHEM erlaubt die Nutzung mehrer vccus parallel. Der Nutzer kann damit sein System in Gruppen aufteilen und jeder vccu eine Reihe von IOs zuweisen. 
Empfohlen wird die Definition einer einzigen vccu, welcher man alle IOs für HM zuweist.

Anders ausgedrückt:

Manchmal ist es sehr hilfreich, mehrere HM Sender (=IOs) im Gebäude zu verteilen. Beispielsweise weil einige Geräte nicht mehr zuverlässig in Funkreichweite sind. Die VCCU kümmert sich dann automatisch darum, mit welchem Sendemodul (also HM-CFG-LAN, HM-CFG-USB oder CUL) die einzelnen HM Aktoren am besten angesprochen werden können.

== Definition ==
=== HMId wählen ===
Eine vccu benötigt wie alle HM devices eine Adresse, mit der sie angesprochen wird. Diese muss eindeutig in System sein, man muss also eine Wählen, die noch nicht verwendet wird. 
Eine vccu wird ihre HMId an die ihr zugewiesenen IOs weitergeben. Definiert man eine vccu erst nachdem schon IOs (CUL oder HMLAN) für Homematic angelegt sind sollte die HMId des IO verwendet werden. 
Wenn die HMId im System ein-eindeitig für ein Device sein muss trifft des also nicht auf IOs zu. IOs sind keine CUL_HM devices. 
 
In der Regel nimmt man die HMId des IOs, welcher später der vccu zugeordnet werden soll.
=== Einrichten ===
define vccu CUL_HM <HMId>
attr vccu model CCU-FHEM
attr vccu IOList <io1>[,<io2>,...]

=== Auswirkungen auf IOs===
Sind IOs durch das Attribut IOList einer vccu zugewiesen werden die entsprechenden Attribute im IO gesetzt. Die HMId wird 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 internals owner und owner_CCU eingetragen. 
=== Best Current Practice ===
Folgenden Aktionen sind weiter möglich, werden aber besser in der vccu erledigt
hmPairForSec
hmPairSerial
== Dynamisches IO ==
Devices senden in der Regel immer über das gleiche IO device. Kommt es zu einem Ausfall werden keine Nachrichten mehr gesendet, auch wenn ein zweites IO bereit stehen würde. Ferner könnte man bewegliche Fernbedienungen haben, welche ihre Verbindung zu einem IO verlieren, aber über ein andere IO gut empfangen könnten. 
Es können hierzu 2 Methoden angewendet werden.
=== IO Ersatzschaltung ===
Bei stationären Devices - meist die Masse der genutzten Devices - kann man i.d.R. das beste IO finden und will dies nutzen. Eine Umschaltung auf ein 2. IO würde nur sinnvoll sein, wenn das bevorzugte IO ausgefallen ist. Diese Zuordnung macht man über
attr <dev> IOgrp <vccu>:<preferedIO>
In der Praxis könnte es heißen
attr LichtFlur IOgrp vccu:HMLAN1
FHEM sendet zum Device LichtFlur immer über HMLAN1, so lange dies verfügbar ist. Sollte HMLAN1 nicht mehr erreichbar sein wird im Attribut IOList der vccu nach einem Ersatz gesucht. 
HMLAN1 muss in der IOList der vccu eingerichtet sein, incl preferedIO. 

=== IO nach Empfangspegel ===
Bewegliche Fernbedienungen haben naturgemäß kein preferedIO. Daher wird dieser Eintrag nicht gesetzt. Es wird nun versucht, das IO mit dem aktuell besten Empfangspegel zu nutzen.
attr Fernbedienung1 IOgrp vccu

=== Bemerkungen ===
Es wird empfohlen, das Attribut IOgrp in allen Devices zu setzen. Kanäle senden nicht selbständig, haben daher auch kein Attribut IOgrp. 
Das Attribut '''IODev''' wird automatisch gesetzt, der User muss hier nichts mehr eintragen. Es ist aus Systemgründen weiter notwendig und kann sich verändern. Es zeigt das letzte genutzte output-device an. 
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

Dieser Befehl (in der Fhem-Eingabezeile eingeben und mit <Return> bestätigen) setzt das Attribut bei allen Devices, und zwar allen, deren '''DEF''' genau 6 Zeichen lang ist.

== virtuelle Kanäle der vccu==
Eine vccu kann bis zu 50 virtuelle Kanäle bedienen. Diese können als Sender/Sensoren oder Empfänger eingesetzt werden. Man kann diese Kanäle mit einem realen Kanal peeren und Aktionen triggern. 
Man peert z.B. eine virtuellen Kanal mit einem Dimmer. Nun kann man im Dimmer das Verhalten bei Tastendruck lang und kurz festlegen. Aus der Zentrale kann man schließlich den Tastendruck simulieren, der Dimmer wird reagieren. Selbstverständlich kann man einen virtuellen Kanal mit mehreren Aktoren parallel peeren und so z.B. alle lichter einer Gruppe mit einem "press" ausschalten.
=== 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]]

Plots erzeugen

2015-02-12T08:18:51Z

Rohan: /* Datum und Zeit */ neue <code>-Formatierung berücksichtigt

'''Plots erzeugen'''

== .gplot-Editor ==

Fhem verfügt über einen ".gplot-Editor" (auch als Ploteditor bezeichnet), um die .gplot-Datei zur Erstellung eines Plots menügeführt zu generieren. Ein manuelles Anlegen der .gplot-Datei ist für Spezialisten und normalerweise nicht notwendig. Der .gplot-Editor sollte für Standardfälle grundsätzlich verwendet werden.

Details zum .gplot-Editor können im Ankündigungshinweis im {{Link2Forum|Topic=11275|Message=75594|LinkText=Fhem-Forum}} nachgelesen werden.

Zur Einarbeitung in die Funktionsweise des .gplot-Editor existieren ausführliche, bebilderte Beispiele:

*Grundlegendes Beispiel zur Erzeugung von Plots:
:* [[Buderus_Web_Gateway#Mit_FileLog|Schrittweises Beispiel für Temperaturkurven]]

*Spezielle Erläuterungen zur Erzeugung von Plots mit Stati:
:* {{Link2Forum|Topic=12945|Message=78887|LinkText=Fhem-Forum}}
:* [[EnOcean-STM-250-Fenster-Türkontakt#Türstatus in einem Plot darstellen|Schrittweises Beispiel bei Kontakten]],
:* [[EnOcean-D-452-FU-EBIM-Aktor-2fach#Aktorstatus_in_einem_Plot_darstellen|Schrittweises Beispiel zum Aktorstatus]]

Verhinderung von Perl-Warnungen bei LogFiles mit unterschiedlicher Spaltenanzahl in Log-Zeilen: {{Link2Forum|Topic=27835}}

<big>'''Achtung'''</big>:

Verwenden Sie diesen Editor nicht, wenn das Fhem-Device bereits angelegt ist und Sie für dieses Device ein bestehendes, allgemeines gplot-File verwenden, das auch für andere Devices benutzt wird. Beim Abspeichern wird ein Filter im gplot-File gesetzt, das das gplot-File nur für genau dieses Device verwendbar macht.

Beispiel:

aus

#FileLog 4:::

wird

#FileLog 4:DS2423.energy_a\x3a::

in dem entsprechenden gplot-File.

Die anderen Devices, die evtl. dieses gplot-File verwenden, haben danach keine funktionierende Plot-Anzeige mehr. Bevor also etwas geändert wird, sollte mit

set weblink_irgendwas copyGplotFile

ein Duplikat angelegt werden, das ausschließlich für diesen Plot verwendet wird. Der Befehl kann unterhalb des ersten Kasten per Dropdown ausgewählt werden.

== Individuell / Manuell ==

'''Vorbemerkungen:'''

* Fhem bediente sich früher für die Erstellung der Plots des Programms ''Gnuplot'' [http://www.gnuplot.info/]. Hierbei reichen die "einfacheren" Funktionalitäten dieses Programms aus (''Gnuplot'' kann noch viel mehr).
* aktuelle Fhem-Versionen haben die Plot-Funktionen (angelehnt an die Plot-File-Syntax von Gnuplot) integriert.
* die Beispieldateien für die in Fhem integrierten Plots finden Sie in Ihrem Fhem-Programmordner unter ''www/gplot''.
* Angaben wie <SIZE>, <OUT>, <L1>, <IN> usw. im Plot-File sind Platzhalter bzw. Feldbezeichner für Fhem. Diese sind case-sensitive (Groß-/Kleinschreibung beachten).
* Weitere Möglichkeiten Plots anzupassen und zu ergänzen bietet das Fhem-Hilfsmodul [[LogProxy|logProxy]].

Ein Beispiel (''temp4hum4.gplot'') aus diesem Verzeichnis:

# Attribute 'small' is useful for gnuplot/-scroll only,
# if plotsize is less than 800,400
#set terminal png transparent small size <SIZE> crop

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 ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics

set y2label "Temperature in C"
set ylabel "Humidity (%)"

#FileLog 4:temperature:10:
#FileLog 4:humidity:50:

plot \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Measured temperature' with lines,\
"< egrep 'humidity' <IN>"\
using 1:4 axes x1y1 title 'Humidity (%)' with lines\

Die Zeilen, die mit ''set'' beginnen, beeinflussen wesentlich das Erscheinungsbild und Aussehen Ihrer Plots (Achsenbeschriftungen, Skalen usw.). Dabei sollten Sie die Zeilen, die eine Angabe zwischen "<" und ">" enthalten, zunächst unverändert lassen. Weitere (ausführliche) Hinweise (zu Gnuplot!) finden Sie in einer [http://www.home.uni-osnabrueck.de/elsner/Skripte/gnuplot.pdf PDF-Datei]. Eingeschränktere, aber für die meisten Belange von Fhem ausreichende Infos finden Sie auf [http://www.aurbacher.net/gnuplot/gnuplot.html dieser Web-Seite].

=== Benutzung der Variablen ===
{| class="wikitable"
! Variable
! Nutzung in gplot-File
! Füllung mit inhalt in fhem.cfg
|-
| <TL>
| set title '<TL>'
| attr weblink title "Dies füllt den Platzhalter <TL>"
|-
| <L1>
| set xlabel '<L1>'
| attr weblink label "Dies füllt das Label <L1>"
|-
| <L2>
| set title '<L2>'
| attr weblink label "Dies füllt das Label <L1>"::"Dies füllt das Label <L2>"
|}

=== Welche Daten werden dargestellt ===

Die Zeilen

#FileLog 5::0:
#FileLog 14::0:

in einer gplot-Datei tragen zwar zu Beginn das Kommentarzeichen "#", jedoch handelt es sich durchaus nicht um solche. Vielmehr trifft man mit den Werten hinter ''FileLog'' Vorgaben, welche Werte wie von Fhem an ''gnuplot'' zwecks grafischer Darstellung übergeben werden.

Im o.a. Beispiel werden das 5. und das 14. Wertfeld (voneinander getrennt durch ein Leerzeichen (Blank)) an gnuplot weiter gegeben.

Eine dazu passende Log-Dateizeile könnte beispielsweise so aussehen

2013-11-14_17:32:00 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200
----1. Feld-------- --2. Feld-- --3.---- -4.- -5. -6. 7. 8. -9. 10. 11 12 --13.- --14.---

^ ^
werden ausgewertet --| --|

Diese Parameter können auch als Attribut übergeben werden:

attr weblink plotfunction "FileLog 5::0:"

Anhand der Anmerkungen wird hoffentlich die Wirkungsweise deutlich. Zu den restlichen - optionalen - Parametern hinter ''FileLog'' wird zunächst auf die [http://fhem.de/commandref.html#FileLogget commandref] verwiesen.

=== Datum und Zeit ===

'''Anmerkungen / Hinweise:'''

Fhem erwartet das Datum '''und''' die Uhrzeit der Log-Dateieinträge '''zwingend''' an <ins>erster Stelle</ins> der Datenzeile und zwar im Format

<code>JJJJ-MM-TT_SS:mm:ss</code>

wobei

* JJJJ die 4-stellige Jahreszahl
* MM der 2-stellige Monat (ggfls. mit Vornull)
* TT der 2-stellige Tag (ggfls. mit Vornull)
* SS die 2-stellige Stunde (ggfls. mit Vornull)
* mm die 2-stellige Minute (ggfls. mit Vornull)
* ss die 2-stellige Sekunde (ggfls. mit Vornull)

bedeutet. Bitte beachten Sie auch die Stelle der Zeichen "-", "_" und ":". Stehen diese nicht an den angegebenen Stellen, wird die entsprechende Zeile beim Erzeugen des Plots nicht beachtet. Ggfls. wird gar kein Plot angezeigt.

Eine Änderung/Anpassung der *.gplot-Datei in der Zeile

set timefmt "..."

hat auf dieses Verhalten von Fhem '''keine''' Auswirkungen, sondern nur auf die Darstellung von Datum und Zeit durch ''Gnuplot'' .

Dazu ein Beispiel:

Mit

2013-11-14_17:32:00 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200

kann Fhem etwas anfangen. Mit

20131114173200 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200

oder

14.11.2013 17:32 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200

dagegen nicht.

Im ersten Fehler-Beispiel fehlen die notwendigen Trennzeichen, im zweiten Fehler-Beispiel ist die Reihenfolge im Datum verkehrt, außerdem werden die falschen Trenner verwendet. Zudem fehlen die Sekunden.

=== Plot der letzten 24 Stunden statt des aktuellen Tages ===

Hierzu kann man in der ''Fhem.cfg'' für die Einträge

define WEB FHEMWEB 8083 global

das Attribut

attr WEB endPlotNow 1

setzen. Gleiches geht auch für ''WEBphone'' und ''WEBtablet''. Da muss es dann lauten

attr WEBphone endPlotNow 1

bzw.

attr WEBtablet endPlotNow 1

Das Attribut gilt dann aber für '''alle''' Plots der jeweiligen Ansichten. Wenn man wieder zurück zu den Plots ab jeweils 00:00 Uhr des aktuellen Tages möchte, löscht man dieses Attribut wieder bzw. setzt es auf den Wert "0".

=== Legende links platzieren ===

Gerade im Verbund mit dem Attribut ''endPlotNow'' macht das seit dem 11.01.2015 neue Attribut ''captionLeft'' Sinn, da dann die Legende nicht mehr rechts oben, sondern links oben im Plot erscheint. Dadurch wird die Sichtbarkeit der aktuellen Werte verbessert.

[[Kategorie:FAQ]]
[[Kategorie:HOWTOS]]

Plots erzeugen

2015-02-12T08:10:40Z

Rohan: /* Individuell / Manuell */ Hinweis auf das logProxy-Modul eingearbeitet

'''Plots erzeugen'''

== .gplot-Editor ==

Fhem verfügt über einen ".gplot-Editor" (auch als Ploteditor bezeichnet), um die .gplot-Datei zur Erstellung eines Plots menügeführt zu generieren. Ein manuelles Anlegen der .gplot-Datei ist für Spezialisten und normalerweise nicht notwendig. Der .gplot-Editor sollte für Standardfälle grundsätzlich verwendet werden.

Details zum .gplot-Editor können im Ankündigungshinweis im {{Link2Forum|Topic=11275|Message=75594|LinkText=Fhem-Forum}} nachgelesen werden.

Zur Einarbeitung in die Funktionsweise des .gplot-Editor existieren ausführliche, bebilderte Beispiele:

*Grundlegendes Beispiel zur Erzeugung von Plots:
:* [[Buderus_Web_Gateway#Mit_FileLog|Schrittweises Beispiel für Temperaturkurven]]

*Spezielle Erläuterungen zur Erzeugung von Plots mit Stati:
:* {{Link2Forum|Topic=12945|Message=78887|LinkText=Fhem-Forum}}
:* [[EnOcean-STM-250-Fenster-Türkontakt#Türstatus in einem Plot darstellen|Schrittweises Beispiel bei Kontakten]],
:* [[EnOcean-D-452-FU-EBIM-Aktor-2fach#Aktorstatus_in_einem_Plot_darstellen|Schrittweises Beispiel zum Aktorstatus]]

Verhinderung von Perl-Warnungen bei LogFiles mit unterschiedlicher Spaltenanzahl in Log-Zeilen: {{Link2Forum|Topic=27835}}

<big>'''Achtung'''</big>:

Verwenden Sie diesen Editor nicht, wenn das Fhem-Device bereits angelegt ist und Sie für dieses Device ein bestehendes, allgemeines gplot-File verwenden, das auch für andere Devices benutzt wird. Beim Abspeichern wird ein Filter im gplot-File gesetzt, das das gplot-File nur für genau dieses Device verwendbar macht.

Beispiel:

aus

#FileLog 4:::

wird

#FileLog 4:DS2423.energy_a\x3a::

in dem entsprechenden gplot-File.

Die anderen Devices, die evtl. dieses gplot-File verwenden, haben danach keine funktionierende Plot-Anzeige mehr. Bevor also etwas geändert wird, sollte mit

set weblink_irgendwas copyGplotFile

ein Duplikat angelegt werden, das ausschließlich für diesen Plot verwendet wird. Der Befehl kann unterhalb des ersten Kasten per Dropdown ausgewählt werden.

== Individuell / Manuell ==

'''Vorbemerkungen:'''

* Fhem bediente sich früher für die Erstellung der Plots des Programms ''Gnuplot'' [http://www.gnuplot.info/]. Hierbei reichen die "einfacheren" Funktionalitäten dieses Programms aus (''Gnuplot'' kann noch viel mehr).
* aktuelle Fhem-Versionen haben die Plot-Funktionen (angelehnt an die Plot-File-Syntax von Gnuplot) integriert.
* die Beispieldateien für die in Fhem integrierten Plots finden Sie in Ihrem Fhem-Programmordner unter ''www/gplot''.
* Angaben wie <SIZE>, <OUT>, <L1>, <IN> usw. im Plot-File sind Platzhalter bzw. Feldbezeichner für Fhem. Diese sind case-sensitive (Groß-/Kleinschreibung beachten).
* Weitere Möglichkeiten Plots anzupassen und zu ergänzen bietet das Fhem-Hilfsmodul [[LogProxy|logProxy]].

Ein Beispiel (''temp4hum4.gplot'') aus diesem Verzeichnis:

# Attribute 'small' is useful for gnuplot/-scroll only,
# if plotsize is less than 800,400
#set terminal png transparent small size <SIZE> crop

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 ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics

set y2label "Temperature in C"
set ylabel "Humidity (%)"

#FileLog 4:temperature:10:
#FileLog 4:humidity:50:

plot \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Measured temperature' with lines,\
"< egrep 'humidity' <IN>"\
using 1:4 axes x1y1 title 'Humidity (%)' with lines\

Die Zeilen, die mit ''set'' beginnen, beeinflussen wesentlich das Erscheinungsbild und Aussehen Ihrer Plots (Achsenbeschriftungen, Skalen usw.). Dabei sollten Sie die Zeilen, die eine Angabe zwischen "<" und ">" enthalten, zunächst unverändert lassen. Weitere (ausführliche) Hinweise (zu Gnuplot!) finden Sie in einer [http://www.home.uni-osnabrueck.de/elsner/Skripte/gnuplot.pdf PDF-Datei]. Eingeschränktere, aber für die meisten Belange von Fhem ausreichende Infos finden Sie auf [http://www.aurbacher.net/gnuplot/gnuplot.html dieser Web-Seite].

=== Benutzung der Variablen ===
{| class="wikitable"
! Variable
! Nutzung in gplot-File
! Füllung mit inhalt in fhem.cfg
|-
| <TL>
| set title '<TL>'
| attr weblink title "Dies füllt den Platzhalter <TL>"
|-
| <L1>
| set xlabel '<L1>'
| attr weblink label "Dies füllt das Label <L1>"
|-
| <L2>
| set title '<L2>'
| attr weblink label "Dies füllt das Label <L1>"::"Dies füllt das Label <L2>"
|}

=== Welche Daten werden dargestellt ===

Die Zeilen

#FileLog 5::0:
#FileLog 14::0:

in einer gplot-Datei tragen zwar zu Beginn das Kommentarzeichen "#", jedoch handelt es sich durchaus nicht um solche. Vielmehr trifft man mit den Werten hinter ''FileLog'' Vorgaben, welche Werte wie von Fhem an ''gnuplot'' zwecks grafischer Darstellung übergeben werden.

Im o.a. Beispiel werden das 5. und das 14. Wertfeld (voneinander getrennt durch ein Leerzeichen (Blank)) an gnuplot weiter gegeben.

Eine dazu passende Log-Dateizeile könnte beispielsweise so aussehen

2013-11-14_17:32:00 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200
----1. Feld-------- --2. Feld-- --3.---- -4.- -5. -6. 7. 8. -9. 10. 11 12 --13.- --14.---

^ ^
werden ausgewertet --| --|

Diese Parameter können auch als Attribut übergeben werden:

attr weblink plotfunction "FileLog 5::0:"

Anhand der Anmerkungen wird hoffentlich die Wirkungsweise deutlich. Zu den restlichen - optionalen - Parametern hinter ''FileLog'' wird zunächst auf die [http://fhem.de/commandref.html#FileLogget commandref] verwiesen.

=== Datum und Zeit ===

'''Anmerkungen / Hinweise:'''

Fhem erwartet das Datum '''und''' die Uhrzeit der Log-Dateieinträge '''zwingend''' an <ins>erster Stelle</ins> der Datenzeile und zwar im Format

<code>
JJJJ-MM-TT_SS:mm:ss
</code>

wobei

* JJJJ die 4-stellige Jahreszahl
* MM der 2-stellige Monat (ggfls. mit Vornull)
* TT der 2-stellige Tag (ggfls. mit Vornull)
* SS die 2-stellige Stunde (ggfls. mit Vornull)
* mm die 2-stellige Minute (ggfls. mit Vornull)
* ss die 2-stellige Sekunde (ggfls. mit Vornull)

bedeutet. Bitte beachten Sie auch die Stelle der Zeichen "-", "_" und ":". Stehen diese nicht an den angegebenen Stellen, wird die entsprechende Zeile beim Erzeugen des Plots nicht beachtet. Ggfls. wird gar kein Plot angezeigt.

Eine Änderung/Anpassung der *.gplot-Datei in der Zeile

set timefmt "..."

hat auf dieses Verhalten von Fhem '''keine''' Auswirkungen, sondern nur auf die Darstellung von Datum und Zeit durch ''Gnuplot'' .

Dazu ein Beispiel:

Mit

2013-11-14_17:32:00 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200

kann Fhem etwas anfangen. Mit

20131114173200 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200

oder

14.11.2013 17:32 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200

dagegen nicht.

Im ersten Fehler-Beispiel fehlen die notwendigen Trennzeichen, im zweiten Fehler-Beispiel ist die Reihenfolge im Datum verkehrt, außerdem werden die falschen Trenner verwendet. Zudem fehlen die Sekunden.

=== Plot der letzten 24 Stunden statt des aktuellen Tages ===

Hierzu kann man in der ''Fhem.cfg'' für die Einträge

define WEB FHEMWEB 8083 global

das Attribut

attr WEB endPlotNow 1

setzen. Gleiches geht auch für ''WEBphone'' und ''WEBtablet''. Da muss es dann lauten

attr WEBphone endPlotNow 1

bzw.

attr WEBtablet endPlotNow 1

Das Attribut gilt dann aber für '''alle''' Plots der jeweiligen Ansichten. Wenn man wieder zurück zu den Plots ab jeweils 00:00 Uhr des aktuellen Tages möchte, löscht man dieses Attribut wieder bzw. setzt es auf den Wert "0".

=== Legende links platzieren ===

Gerade im Verbund mit dem Attribut ''endPlotNow'' macht das seit dem 11.01.2015 neue Attribut ''captionLeft'' Sinn, da dann die Legende nicht mehr rechts oben, sondern links oben im Plot erscheint. Dadurch wird die Sichtbarkeit der aktuellen Werte verbessert.

[[Kategorie:FAQ]]
[[Kategorie:HOWTOS]]

Rolladensteuerung mit Eingabemöglichkeiten

2015-02-12T07:47:12Z

Rohan: Kategorisiert

In diesem Artikel beschreibe ich, wie ich meine Rollläden steuere.

==Grundsätzliche Beschreibung==
Meine Rollläden im Haus sind allesamt mit HM Aktoren versehen, welche ich nachträglich UP gelegt habe.
Vorher waren die Rolläden manuell bedienbar gewesen.

Da ich eine Photovoltaikanlage besitze habe ich ein kleines Modul geschrieben, welches mir die Ertragsleistung in FHEM darstellt.
Anhand dieser Werte steuere ich Rolläden, welche zur Südseite gerichtet sind. Dadurch wird dann dynamisch die Sonneneinstrahlung und damit die Erwärmung der Zimmer eingestellt.
Zwischenzeitlich ist ein Helligkeitssensor installiert worden. Dieser sorgt für das Herunterfahren der Rolläden bei Eintreten der Dunkelheit.

Dieser Wert korreliert zwar mit den Werten der PV Anlage, dies habe ich aber bislang noch nicht aufgelöst.

==Komponenten==
1. HM Funk-Jalousieaktor HM-LC-Bi1PBU-FM

2. Solarlog-Modul

3. Helligkeitssensor aus diesem Posting
[http://forum.fhem.de/index.php/topic,20620.0.html Selbstbau HM_WDS10_TH_O mit Luftdruckmessung]

==Visualisierung==
Hier ist der Status eines jeden Rolladens ersichtlich und dieser ist bedienbar.

[[Datei:Dashboard01.png]]

Über diese Einstellungsseite können diverse Parameter der Steuerung gesetzt werden.

[[Datei:Dashboard02.png]]

==Einstellungen==
;'''Automatik aktiv:'''
:Hiermit wird die komplette Steuerung der Rolläden ein- bzw ausgeschaltet.
:Sofern der Modus "aus" aktiv ist, werden meine Rolläden lediglich über die Aktoren direkt oder eine HM Fernbedienung gesteuert.

;'''Art:'''
:Hier werden derzeit drei Modi unterstützt:

:''1. Normal''
:Bei diesem Modus fahren die Rollläden zu den definierten Zeiten hoch. Dabei wird eine Unterscheidung zwischen Wochentagen und Wochenenden berücksichtigt. Ausserdem werden mit Hilfe einer Holiday-Datei auch Feiertage und Urlaube berücksichtigt.
:Abends ist ein Zeitraum und ein Helligkeitswert definiert. Sobald dieser Helligkeitswert in dem Zeitfenster unterschritten wird, fahren die Rolläden runter. Spätestens aber zum Ende des Zeitfensters.

:''2. Weihnachten''
:Vom Prinzip arbeitet dieser Modus wie der Modus "Normal". Lediglich ein Rolladen fährt zum Ende des Zeitfensters runter und nicht bei Unterschreitung des Helligkeitswertes, damit die Weihnachtsaussenbeleuchtung auch von innen begutachtet werden kann.

:''3. Urlaub''
:Dieser Modus schaltet die Rolläden genauso wie der Modus "Normal". Des Weiteren aktiviere ich noch eine Zufallssteuerung für eine Anwesenheitsbeleuchtung.

;'''PV:'''
:Hiermit wird der Ertrag der Photovoltaikanlage mit einbezogen, damit die Rolläden zur Südseite anhand definierter Werte geschaltet werden.

;'''Zeit hoch:'''
:Hier wird der Zeitpunkt definiert, wann die Rollläden an Werktagen geöffnet werden sollen.

;'''Zeit hoch WE:'''
:Dies definiert die Zeit, wann die Rolläden am Wochenende bzw an Tagen, welche in einer Holiday Datei definiert sind hoch gehen sollen.

;'''Helligkeit runter:'''
:Dieser Wert ist der untere Schwellwert des Helligkeitssensors, ab wann die Rolläden in dem definierten Zeitraum geschlossen werden sollen.

;'''Zeit runter start:'''
:Ab dieser Zeit fahren die Rolläden bei Erreichen des Helligkeitswertes runter. Sofern eventuelle Tür-/Fensterkontakte den Status "closed" aufweisen. Während des Zeitraums gehen diese Rolläden hoch und auch wieder runter, sofern eine Tür/ein Fenster geöffnet bzw geschlossen wird.

;'''Zeit runter ende:'''
:Dies ist das Ende des Zeitraums. Wenn bis dahin die Helligkeit nicht unterschritten wurde, fahren die Rolläden nun spätestens runter.

==Codierung==
Meine Aktoren haben den folgenden Aufbau, was den Namen angeht:

'''OG_ki1_RO_Carport'''

Die ersten zwei Zeichen geben das Geschoss an.
Die Zeichen 4-6 beschreiben das Zimmer.
Die Zeichen 8 und 9 stellen die Art des Aktors dar.
Ab Zeichen 11 wird noch weiter beschrieben wo sich der Aktor befindet bzw was für eine Funktion dieser besitzt.

===Dummys===
Beginnen möchte ich hier mit den Dummys, welche die Konfiguration der Steuerung darstellen.

;'''Automatik aktiv:'''

<nowiki>NAME du_Rollo_Master
TYPE dummy

Attributes:
alias Automatik aktiv:
devStateIcon .*:rc_BLANK
group Rollos_Settings
icon fts_shutter_automatic
room LichtRollo
setList state:an,aus
sortby 01
webCmd state</nowiki>

;'''Art:'''

<nowiki>NAME du_Rollo_Art
TYPE dummy

Attributes:
alias Art:
devStateIcon .*:rc_BLANK
group Rollos_Settings
icon fts_shutter_updown
room LichtRollo
setList state:Normal,Urlaub,Weihnachten
sortby 02
webCmd state</nowiki>

;'''PV:'''

<nowiki>NAME du_Rollo_PV
TYPE dummy

Attributes:
alias PV:
devStateIcon .*:rc_BLANK
group Rollos_Settings
icon weather_sun
room LichtRollo
setList state:an,aus
sortby 03
webCmd state</nowiki>

;'''Zeit hoch:'''

<nowiki>NAME du_Rollo_Zeit_ho
TYPE dummy

Attributes:
alias Zeit hoch:
devStateIcon .*:rc_BLANK
group Rollos_Settings
icon icoUhr
room LichtRollo
setList state:time
sortby 10
webCmd state</nowiki>

;'''Zeit hoch WE:'''

<nowiki> NAME du_Rollo_Zeit_ho_WE
TYPE dummy

Attributes:
alias Zeit hoch WE:
devStateIcon .*:rc_BLANK
group Rollos_Settings
icon icoUhr
room LichtRollo
setList state:time
sortby 11
webCmd state</nowiki>

;'''Helligkeit runter:'''

<nowiki>NAME du_Rollo_Luminosity_ru
TYPE dummy

Attributes:
alias Helligkeit runter
devStateIcon .*:rc_BLANK
group Rollos_Settings
icon sani_solar
room LichtRollo
setList state:textField
sortby 20
webCmd state</nowiki>

;'''Zeit runter start:'''

<nowiki>NAME du_Rollo_Zeit_ru_start
TYPE dummy

Attributes:
alias Zeit runter start:
devStateIcon .*:rc_BLANK
group Rollos_Settings
icon icoUhr
room LichtRollo
setList state:time
sortby 21
webCmd state</nowiki>

;'''Zeit runter ende:'''

<nowiki>NAME du_Rollo_Zeit_ru_ende
TYPE dummy

Attributes:
alias Zeit runter ende:
devStateIcon .*:rc_BLANK
group Rollos_Settings
icon icoUhr
room LichtRollo
setList state:time
sortby 22
webCmd state</nowiki>

===DOIFs===

'''di_EG_ku_RO_StrasseLinks'''

Dieses DOIF beachtet den Helligkeitswert und den Modus "Weihnachten".
D.h., daß dieser Rollo erst am Ende des definierten Zeitraums herunterfährt.

<nowiki>([du_Rollo_Master] eq "an" and ([EG_dr_TS_Terrasse:luminosity] < [du_Rollo_Luminosity_ru] and
[du_Rollo_Art] ne "Weihnachten" and
[{ReadingsVal("du_Rollo_Zeit_ru_start", "state", "22:00:00")}-{ReadingsVal("du_Rollo_Zeit_ru_ende", "state", "22:00:00")}])
or [{ReadingsVal("du_Rollo_Zeit_ru_ende", "state", "22:00:00")}])
(set EG_ku_RO_StrasseLinks off)
DOELSEIF ([du_Rollo_Master] eq "an" and ([{ReadingsVal("du_Rollo_Zeit_ho", "state", "10:00:00")}|8] or
[{ReadingsVal("du_Rollo_Zeit_ho_WE", "state", "10:00:00")}|7]))
(set EG_ku_RO_StrasseLinks on)</nowiki>

'''di_EG_ku_RO_StrasseRechts'''

Hier wird ein Fensterkontakt mit in die Schaltung einbezogen.
D.h. während des definierten Zeitraums gehen Rollos hoch, wenn eine Tür oder ein Fenster geöffnet wird. Ebenso wieder runter, sofern der Kontakt wieder geschlossen wird.

<nowiki>([du_Rollo_Master] eq "an" and [EG_ku_TK_Strasse] eq "closed" and ([EG_dr_TS_Terrasse:luminosity] < [du_Rollo_Luminosity_ru:state]
and [{ReadingsVal("du_Rollo_Zeit_ru_start", "state", "22:00:00")}-{ReadingsVal("du_Rollo_Zeit_ru_ende", "state", "22:00:00")}])
or [{ReadingsVal("du_Rollo_Zeit_ru_ende", "state", "22:00:00")}])
(set EG_ku_RO_StrasseRechts off)
DOELSEIF ([du_Rollo_Master] eq "an" and ([{ReadingsVal("du_Rollo_Zeit_ho", "state", "10:00:00")}|8] or
[{ReadingsVal("du_Rollo_Zeit_ho_WE", "state", "10:00:00")}|7]) or ([EG_ku_TK_Strasse:state] eq "open"))
(set EG_ku_RO_StrasseRechts on)</nowiki>

'''di_EG_wz_RO_TerrasseLinks'''

Dieses DOIF beachtet einen Fensterkontakt und bezieht die Photovoltaikanlage mit ein.
Dieser Rollo geht während des Zeitraums der Dunkelheit rauf und runter, sofern der Türkontakt geöffnet oder geschlossen wird.

<nowiki>([du_Rollo_Master] eq "an" and [EG_wz_TK_Terrasse] eq "closed" and (([EG_dr_TS_Terrasse:luminosity] < [du_Rollo_Luminosity_ru:state]
and [{ReadingsVal("du_Rollo_Zeit_ru_start", "state", "22:00:00")}-{ReadingsVal("du_Rollo_Zeit_ru_ende", "state", "22:00:00")}])
or [{ReadingsVal("du_Rollo_Zeit_ru_ende", "state", "22:00:00")}]))
(set EG_wz_RO_TerrasseLinks off)
DOELSEIF ([du_Rollo_Master] eq "an" and ([{ReadingsVal("du_Rollo_Zeit_ho", "state", "10:00:00")}|8]
or [{ReadingsVal("du_Rollo_Zeit_ho_WE", "state", "10:00:00")}|7]) or ([EG_wz_TK_Terrasse] eq "open"))
(set EG_wz_RO_TerrasseLinks on)
DOELSEIF ([du_Rollo_PV] eq "an" and [EG_wz_TK_Terrasse] eq "closed" and [mySL:Pac_avg] >= 2100)
(set EG_wz_RO_TerrasseLinks 0)
DOELSEIF ([du_Rollo_PV] eq "an" and [EG_wz_TK_Terrasse] eq "closed" and [mySL:Pac_avg] >= 1501)
(set EG_wz_RO_TerrasseLinks 30)
DOELSEIF ([du_Rollo_PV] eq "aus")
(set EG_wz_RO_TerrasseLinks on)

wait 0:0:300:300:0 </nowiki>

Alle anderen Aktoren sind vereinfachte Versionen der genannten DOIFs und werden daher hier nicht genannt.

'''di_Rollo_Art'''

Dieses DOIF enabled und disabled einen Randomtimer, welcher ein Zufallslicht schaltet.

<nowiki>([du_Rollo_Art:state] eq "Urlaub") (attr UrlaubTimer disable 0, attr at_Urlaub_DG_hz_SD_Zirkpumpe disable 0)
DOELSE ([du_Rollo_Art:state] ne "Urlaub") (attr UrlaubTimer disable 1, attr at_Urlaub_DG_hz_SD_Zirkpumpe disable 1)</nowiki>

Hier folgt nun ein interessantes DOIF.
Sofern manuelle Änderungen in den Text- bzw Zeitdummys durchgeführt werden, aktualisiert dieses DOIF die Definitionen der Rollo-DOIFs.
Dadurch werden die neuen Werte aus den Dummys für die Timer der DOIFs aktualisiert.

Auch aktualisiert dieses DOIF bei einem Neustart von FHEM die DOIFs.
Andernfalls würden die Defaultwerte der ReadingsVal(...) in den Definitionen die Defaultwerte zurückliefern.

'''di_Rollo_SetTime'''

<nowiki>([global:?INITIALIZED] or [du_Rollo_Zeit_ho:?] or [du_Rollo_Zeit_ho_WE:?] or [du_Rollo_Luminosity_ru:?]
or [du_Rollo_Zeit_ru_start:?] or [du_Rollo_Zeit_ru_ende:?]) (modify di_EG_ku_RO_StrasseLinks [di_EG_ku_RO_StrasseLinks:&DEF],
modify di_EG_ku_RO_StrasseRechts [di_EG_ku_RO_StrasseRechts:&DEF],
modify di_EG_wz_RO_Carport [di_EG_wz_RO_Carport:&DEF], modify di_EG_wz_RO_TerrasseLinks [di_EG_wz_RO_TerrasseLinks:&DEF],
modify di_EG_wz_RO_TerrasseRechts [di_EG_wz_RO_TerrasseRechts:&DEF], modify di_OG_elt_RO_Strasse [di_OG_elt_RO_Strasse:&DEF],
modify di_OG_ki1_RO_Carport [di_OG_ki1_RO_Carport:&DEF], modify di_OG_ki1_RO_Garten [di_OG_ki1_RO_Garten:&DEF],
modify di_OG_ki2_RO_Garten [di_OG_ki2_RO_Garten:&DEF])</nowiki>

===ReadingsGroup===

Hier seien noch die beiden ReadingsGroup aufgeführt, welche im Dashboard dargestellt werden.

Folgende Funktionen sind in der myRollosUtils.pm gespeichert und dienen der Bedienung ausgehend aus den ReadingsGroups.

<nowiki>############## Rollos hoch/runter in Readingsgroup

sub myRollosUtils_RollosUpDown($$) {
my($DEVICE,$CMD) = @_;

my $icon = $CMD;
my $link;

if( $CMD eq "up" ) {
$icon = "remotecontrol/black_btn_CHUP";
$link = "setreading $DEVICE cmd-new on";
} elsif( $CMD eq "down" ) {
$icon = "remotecontrol/black_btn_CHDOWN";
$link = "setreading $DEVICE cmd-new off";
} elsif( $CMD eq "stop" ) {
$icon = "remotecontrol/black_btn_STOP";
$link = "setreading $DEVICE cmd-new stop";
}

my $notify = "no_RollosUpDown";
if( !defined($defs{$notify}) ) {
CommandDefine(undef,
"$notify notify .*:cmd-new.* "
."{ myRollos_RollosUpDownNotify(\$NAME,\$EVTPART1); }" );
}

my $ret = "%$icon";
$ret .= "%$link" if( $link );

return $ret;
}

sub myRollosUtils_RollosUpDownNotify($$) {
my($DEVICE,$CMD) = @_;

return if( $CMD eq "" );

CommandSet(undef, "$DEVICE $CMD");

return undef;
}

sub myRollosUtils_RollosIcon($) {
my($DEVICE) = @_;
my $level = ReadingsVal($DEVICE,"level", "0");
my $pct = ReadingsVal($DEVICE, "pct", "0");

my $ret = int((100 - $level)/10)*10;

my $icon;
if ($ret eq "0") {
$icon = "fts_window_2w\@orange";
} else {
$icon = "fts_shutter_".$ret."\@orange";
}

return $pct." %";
}
</nowiki>

'''EG_rg_Rolllaeden'''

<nowiki>EG.*_RO_S.*:level,<{myRollosUtils_RollosUpDown($DEVICE,"up")}>,<{myRollosUtils_RollosUpDown($DEVICE,"stop")}>,
<{myRollosUtils_RollosUpDown($DEVICE,"down")}> EG.*_RO_C.*:level,<{myRollosUtils_RollosUpDown($DEVICE,"up")}>,
<{myRollosUtils_RollosUpDown($DEVICE,"stop")}>,<{myRollosUtils_RollosUpDown($DEVICE,"down")}> EG.*_RO_T.*:level,
<{myRollosUtils_RollosUpDown($DEVICE,"up")}>,<{myRollosUtils_RollosUpDown($DEVICE,"stop")}>,
<{myRollosUtils_RollosUpDown($DEVICE,"down")}> EG.*_RO_M.*:level,<{myRollosUtils_RollosUpDown($DEVICE,"up")}>,
<{myRollosUtils_RollosUpDown($DEVICE,"stop")}>,<{myRollosUtils_RollosUpDown($DEVICE,"down")}>

Attributes:
group Rollos/Markise_EG
mapping %ALIAS
valueFormat {pct => "%.1f"}
valueIcon %VALUE </nowiki>

===Notify===

Ein Notify ist für die Bedienung ausgehend aus den ReadingsGroup notwendig.

<nowiki>DEF .*:cmd-new.* { myRollosUtils_RollosUpDownNotify($NAME,$EVTPART1); }
NAME no_RollosUpDown
TYPE notify

Attributes:
group notify</nowiki>

[[Kategorie:HOWTOS]]

Virtueller Controller VCCU

2015-02-11T21:37:27Z

Rohan: /* Dynamisches IO */

Ein virtueller Controller '''vccu''' ist der Protokoll-Endpunkt der Zentrale.
Weiter können Ihr IO devices zugeordnet werden und IOs dynamisch verwaltet werden.
== Wann ist eine VCCU Sinnvoll ==
Eine vccu sollte '''immer''' angelegt werden. 
FHEM erlaubt die Nutzung mehrer vccus parallel. Der Nutzer kann damit sein System in Gruppen aufteilen und jeder vccu eine Reihe von IOs zuweisen. 
Empfohlen wird die Definition einer einzigen vccu, welcher man alle IOs für HM zuweist.

Anders ausgedrückt:

Manchmal ist es sehr hilfreich, mehrere HM Sender (=IOs) im Gebäude zu verteilen. Beispielsweise weil einige Geräte nicht mehr zuverlässig in Funkreichweite sind. Die VCCU kümmert sich dann automatisch darum, mit welchem Sendemodul (also HM-CFG-LAN, HM-CFG-USB oder CUL) die einzelnen HM Aktoren am besten angesprochen werden können.

== Definition ==
=== HMId wählen ===
Eine vccu benötigt wie alle HM devices eine Adresse, mit der sie angesprochen wird. Diese muss eindeutig in System sein, man muss also eine Wählen, die noch nicht verwendet wird. 
Eine vccu wird ihre HMId an die ihr zugewiesenen IOs weitergeben. Definiert man eine vccu erst nachdem schon IOs (CUL oder HMLAN) für Homematic angelegt sind sollte die HMId des IO verwendet werden. 
Wenn die HMId im System ein-eindeitig für ein Device sein muss trifft des also nicht auf IOs zu. IOs sind keine CUL_HM devices. 
 
In der Regel nimmt man die HMId des IOs, welcher später der vccu zugeordnet werden soll.
=== Einrichten ===
define vccu CUL_HM <HMId>
attr vccu model CCU-FHEM
attr vccu IOList <io1>[,<io2>,...]

=== Auswirkungen auf IOs===
Sind IOs durch das Attribut IOList einer vccu zugewiesen werden die entsprechenden Attribute im IO gesetzt. Die HMId wird 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 internals owner und owner_CCU eingetragen. 
=== Best Current Practice ===
Folgenden Aktionen sind weiter möglich, werden aber besser in der vccu erledigt
hmPairForSec
hmPairSerial
== Dynamisches IO ==
Devices senden in der Regel immer über das gleiche IO device. Kommt es zu einem Ausfall werden keine Nachrichten mehr gesendet, auch wenn ein zweites IO bereit stehen würde. Ferner könnte man bewegliche Fernbedienungen haben, welche ihre Verbindung zu einem IO verlieren, aber über ein andere IO gut empfangen könnten. 
Es können hierzu 2 Methoden angewendet werden.
=== IO Ersatzschaltung ===
Bei stationären Devices - meist die Masse der genutzten Devices - kann man i.d.R. das beste IO finden und will dies nutzen. Eine Umschaltung auf ein 2. IO würde nur sinnvoll sein, wenn das bevorzugte IO ausgefallen ist. Diese Zuordnung macht man über
attr <dev> IOgrp <vccu>:<preferedIO>
In der Praxis könnte es heißen
attr LichtFlur IOgrp vccu:HMLAN1
FHEM sendet zum Device LichtFlur immer über HMLAN1, so lange dies verfügbar ist. Sollte HMLAN1 nicht mehr erreichbar sein wird im Attribut IOList der vccu nach einem Ersatz gesucht. 
HMLAN1 muss in der IOList der vccu eingerichtet sein, incl preferedIO. 

=== IO nach Empfangspegel ===
Bewegliche Fernbedienungen haben naturgemäß kein preferedIO. Daher wird dieser Eintrag nicht gesetzt. Es wird nun versucht, das IO mit dem aktuell besten Empfangspegel zu nutzen.
attr Fernbedienung1 IOgrp vccu

=== Bemerkungen ===
Es wird empfohlen, das Attribut IOgrp in allen Devices zu setzen. Kanäle senden nicht selbständig, haben daher auch kein Attribut IOgrp. 
Das Attribut '''IODev''' wird automatisch gesetzt, der User muss hier nichts mehr eintragen. Es ist aus Systemgründen weiter notwendig und kann sich verändern. Es zeigt das letzte genutzte output-device an. 
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

Dieser Befehl (in der Fhem-Eingabezeile eingeben und mit <Return> bestätigen) setzt das Attribut bei allen Devices, und zwar allen, deren '''DEF''' genau 6 Zeichen lang ist.

Mittels des Befehls

== virtuelle Kanäle der vccu==
Eine vccu kann bis zu 50 virtuelle Kanäle bedienen. Diese können als Sender/Sensoren oder Empfänger eingesetzt werden. Man kann diese Kanäle mit einem realen Kanal peeren und Aktionen triggern. 
Man peert z.B. eine virtuellen Kanal mit einem Dimmer. Nun kann man im Dimmer das Verhalten bei Tastendruck lang und kurz festlegen. Aus der Zentrale kann man schließlich den Tastendruck simulieren, der Dimmer wird reagieren. Selbstverständlich kann man einen virtuellen Kanal mit mehreren Aktoren parallel peeren und so z.B. alle lichter einer Gruppe mit einem "press" ausschalten.
=== 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]]

HomeMatic Type Thermostat

2015-02-09T21:27:13Z

Rohan: /* Temperaturlisten */ Beispiel für setzen der weiteren Wochenprogramme eingefügt

<div style="clear: both; border-width:3px; border-color:#00AA00; border-style:solid; padding:5px; background-color:#FFEFEF; margin:1em; margin-left:5em; margin-right:5em;">Dieser Artikel befindet sich zur Zeit im Umbau, nicht alle Informationen sind unbedingt Korrekt.</div>

Es gibt verschiedene HomeMatic Geräte-Typen. Hier gibt es eine allgemeine Beschreibung für den Typ "Thermostat" und deren speziellen Eigenschaften und Einstellungen

== HomeMatic Geräte vom Typ Blind ==
Die in der aktuellen Version unterstützten Modelle kann man in [[Homematic_HMInfo#Infos|HMInfo]] sehen mit
set hm models -f thermostat
*[[HM-CC-RT-DN Funk-Heizkörperthermostat]]
*[[HM-CC-TC Funk-Wandthermostat]]
*[[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]]

== Hinweise zur Konfiguration ==
Die Thermostate unterscheiden sich in vielen Details und Funktionen. Daher sind Einzelheiten im Device nachzulesen.
Gemeinsam ist den Controllern, dass sie eine oder mehr Temperaturlisten als Wochenprogramm unterstützen.
=== Temperaturlisten ===

====manuell====

Hinweis: Bei den Wandthermostaten heißt der Kanal _climate, beim HM-CC-RT-DN ist der Kanal _Clima zuständig für die Wochenprogramme.

===== Allgemein =====

Mit dem Kommando
set Thermostat_Climate tempListMon 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0
kann man das Temperaturprofil für den Wochentag ''Montag'' einstellen. Die nach dem Schaltzeitpunkt stehende Temperatur gilt immer '''bis''' zu diesen Zeitpunkt, nicht ab diesem Zeitpunkt. Der letzte Wert muss immer Mitternacht (24:00) sein.
damit ist also 00:00 - 05:30 = 16Grad, 05:30 - 07:30 = 18 Grad. Die Zeit kann in Schritten von 30min eingestellt werden, die Temperatur in 0.1 Grad.
Der Tage beginnt immer um 00:00, der letzte Abschnitt MUSS 24:00 sein.

Ändert man mehrere Tage auf einmal sollte man unbedingt mit "prep" und "exec" arbeiten, da es sonst zu Wiederholungen und langen Bearbeitungen kommen kann. Prep bereitet die Änderung in FHEM nur vor, mit exec werden die Daten dann an das Device übertragen. Das könnte in einem Fhem-Script lauten

######################################################
# Temperatur-Liste für Zimmer
# setzen per Aufruf von "{SetTempList_Heizung}"
######################################################
sub
SetTempList_Heizung()
{
{ fhem ("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")};
{ fhem ("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")};
{ fhem ("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")};
{ fhem ("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")};
{ fhem ("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")};
{ fhem ("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")};
{ fhem ("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")};
}
# End SetTempList_Heizung

===== Wochenprogramme des HM-TC-IT-WM-W-EU setzen =====

Der HM-TC-IT-WM-W-EU verfügt über weitere Wochenprogramme P2 und P3.

Um z.B. das 2. Wochenprogramm eines HM-TC-IT-WM-W-EU zu setzen, kann man (hier beispielhaft für den Samstag) folgenden Befehl benutzen:

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

HM-PB-2-WM55 2fach-Funk-Wandtaster

2015-02-07T21:55:26Z

Rohan: etwas überarbeitet

HomeMatic HM-PB-2-WM55 2fach-Funk-Wandtaster

== Features ==

<bitte eintragen>

== Hinweise zur Hardware-Installation ==
Die Integration in FHEM läuft wie mit allen Komponenten. Den LAN-Adapter in FHEM auf hmPairForSec 60 (Zahl bedeutet die Zeit des Zustands in Sekunden und kann beliebig geändert werden) setzen und den Knopf auf der Rückseite des Schalters drücken. Dann sollte der Schalter wie unten dargestellt in FHEM angelegt werden (wird in die fhem.cfg eingetragen). Je nach Einstellungen in autocreate (http://fhem.de/commandref.html#autocreate) kann es sein, dass auch noch weitere Aktionen ausgeführt wurden.

== Hinweise zum Betrieb mit FHEM ==

=== Auszug aus der fhem.cfg ===
Hier der Originaleintrag aus der fhem.cfg der automatisch erstellt wird (mit den "xxx" habe ich meine Nummer erstetzt):
<pre>
define CUL_HM_HM_PB_2_WM55_1F1xxx CUL_HM 1F1xxx
attr CUL_HM_HM_PB_2_WM55_1F1xxx .devInfo 020000
attr CUL_HM_HM_PB_2_WM55_1F1xxx .stc 40
attr CUL_HM_HM_PB_2_WM55_1F1xxx firmware 1.1
attr CUL_HM_HM_PB_2_WM55_1F1xxx model HM-PB-2-WM55
attr CUL_HM_HM_PB_2_WM55_1F1xxx room Bad
attr CUL_HM_HM_PB_2_WM55_1F1xxx serialNr KEQ003xxx
attr CUL_HM_HM_PB_2_WM55_1F1xxx subType pushButton
define FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx FileLog ./log/CUL_HM_HM_PB_2_WM55_1F1xxx-%Y.log CUL_HM_HM_PB_2_WM55_1F1xxx
attr FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx logtype text
attr FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx room CUL_HM
define CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 CUL_HM 1F1xxx01
attr CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 model HM-PB-2-WM55
attr CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 room CUL_HM
define FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 FileLog ./log/CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01-%Y.log CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01
attr FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 logtype text
attr FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 room CUL_HM
define CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 CUL_HM 1F1xxx02
attr CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 model HM-PB-2-WM55
attr CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 room CUL_HM
define FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 FileLog ./log/CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02-%Y.log CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02
attr FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 logtype text
attr FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 room CUL_HM
</pre>

=== Bearbeiten ===
Das ist der Standardeintrag, den fhem automatisch erstellt. Es macht aber Sinn, einiges zu verändern.
Zum einen sollten die Entities umbenannt werden, um sie besser finden und somit bedienen zu können. Das geht entweder manuell in der fhem.cfg (suche "CUL_HM_HM_PB_2_WM55_1F1xxx" ersetze mit neuem Begriff) oder besser per Befehl:
<pre>
rename CUL_HM_HM_PB_2_WM55_1F1xxx LichtFlurDev
rename CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 LichtFlur1
rename CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 LichtFlur2
</pre>

Auch ist es nicht sinnvoll, für jede Entity (in diesem Fall 3: Schalter und die beiden Knöpfe) je ein eigenes Logfile anzulegen, auch wenn autocreate das so macht, denn das kostet Performance und Übersichtlichkeit. Das Beispiel unten zeigt, wie die Ereignisse aller drei Entities mitgeschrieben werden - achtet auf das .* am Ende:

<pre>
define FileLog_LichtFlur FileLog ./log/LichtFlur-%Y.log LichtFlur.*
attr FileLog_LichtFlur logtype text
attr FileLog_LichtFlur room CUL_HM
</pre>

Und jetzt natürlich noch aufräumen und die alten Logfiles entsorgen:
<pre>
delete FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx
delete FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01
delete FileLog_CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02
</pre>

'''Wichtig:''' Folgende Attribute solltet ihr '''nicht aendern''': .devInfo, .stc, model, firmware, serialNr, subType

Weitere interessante Attribute, die man nutzen sollte (siehe auch commandref)sind:room, group, expert, webCmd: gruppieren und darstellen auf der webseite, autoRegRead: automatisches Lesen der Register (für push-Button sollte es auf 0 stehen)

Letztendlich könnte die "gepflegte" fhem.cfg so aussehen:
<pre>
#====== Das Device
define LichtFlurDev CUL_HM 1F1xxx
attr LichtFlurDev .devInfo 020000
attr LichtFlurDev .stc 40
attr LichtFlurDev firmware 1.1
attr LichtFlurDev model HM-PB-2-WM55
attr LichtFlurDev serialNr KEQ003xxx
attr LichtFlurDev subType pushButton
#--- user Attribute zum Device
attr LichtFlurDev room Flur,Device,Licht
attr LichtFlurDev group Schalter
attr LichtFlurDev webCmd statusRequest:getConfig
attr LichtFlurDev expert 1
attr LichtFlurDev autoRegRead 0
#--- erste Taste
define LichtFlur1 CUL_HM 1F1xxx01
attr LichtFlur1 model HM-PB-2-WM55
attr LichtFlur1 room Flur,Button,Licht
attr LichtFlur1 group Schalter
#--- zweite Taste
define LichtFlur2 CUL_HM 1F1xxx02
attr LichtFlur2 model HM-PB-2-WM55
attr LichtFlur2 room Flur,Button,Licht
attr LichtFlur2 group Schalter

define FileLog_LichtFlur FileLog ./log/LichtFlur-%Y.log LichtFlur.*
attr FileLog_LichtFlur logtype text
attr FileLog_LichtFlur room logfiles
</pre>

=== Mit virtuellem Aktor verbinden ===
Wenn man den Taster nicht direkt mit einem Aktor verbindet, erhält er keine Rückmeldungen, wird also immer orange und rot blinken, wenn ihr einen Befehl absetzt. Dieser wird zwar von fhem verarbeitet, fhem weiß aber nicht, dass es etwas zurückmelden soll. Daher solltet ihr Euch einen virtuellen Aktor anlegen und den Taster dann mit diesem verbinden:

In der FHEM-Web Oberfläche gebt ihr in der Kommandozeile ein (die hmId kann freigewählt werden, darf aber in echt nicht existieren):
define virtueller_Aktor CUL_HM 123456
sowie:
set virtueller_Aktor virtual 2

Jetzt habt ihr einen Virtuellen Aktor mit einem Kanal erstellt, jetzt gilt es noch das ganze mit dem realen Taster zu verbinden. Verbunden werden zuerst die Kanäle und dann wird die ganze Konfiguration am Taster gespeichert:

set LichtFlur1 peerChan 0 virtueller_Aktor_Btn1 single set
set LichtFlur2 peerChan 0 virtueller_Aktor_Btn2 single set
set LichtFlurDev getConfig

und am Taster einmal anlernen drücken, ggf. nochmal ein <code>set LichtFlurDev getConfig</code>

Nun drückt einmal einen Button eures Tasters. Wenn alles geklappt hatte, sollte bei Euren Kanälen im State ein (to virtueller_Aktor_Btn1) dahinter stehen und unter den Attributen etwas in den peerIDs auftauchen. Diesen virtuellen Aktor kann man übrigens als Gegenpart für beliebig viele Taster nehmen, ihr braucht also nicht für jeden Taster einen virtuellen Aktor erstellen. Um den virtuellen Aktor zu erweitern einfach ein <code>set virtueller_Aktor virtual [Gesamtanzahl aller Kanäle]</code> ausführen, schon habt ihr weitere Kanäle die ihr mit euren echten Tastern peeren könnt.

Am Ende umbedingt einmal "Save config" drücken, damit der virtuelle Aktor in der fhem.cfg abgespeichert wird.

=== Mit Rolladenaktor verbinden (peeren) ===

Der HM-PB-2-WM55 kann auch z.B. direkt mit einem [[HM-LC-BL1-FM_Funk-Jalousieaktor|HM-LC-BL1-FM Rollladenaktor]] gepeert werden. Hierdurch lässt er sich ohne Fhem nutzen. Weitere Infos dazu finden Sie [[HM-LC-BL1-FM_Funk-Jalousieaktor#Peeren_mit_einem_HM-PB-2-WM55|hier]].

== Probleme ==

=== Bausatz: Der Taster lässt sich nicht anlernen / rotes Dauerblinken ===
Dann stimmt vermutlich etwas mit der Lötung nicht. Am besten insbesondere die Lötungen des Funkmoduls (8 auf jeder Seite überprüfen).
Am besten mal in der fhem.cfg
<pre>
attr LANInterface loglevel 1
</pre>
eintragen und dann die Logdatei anschauen, was dort für Funkverkehr aufgezeichnet wird. Euren Schalter könnt ihr identifizieren, indem ihr den kleineren QR-code auf der Platine des Schalters z.B. mit einem Android Handy und Barcoo auslest. Die App zeigt Euch dann den sechsstelligen Gerätecode an (wenn der Code siebenstellig erscheint, dann die erste Ziffer / Buchtstaben weglassen), den ihr in der Logdatei suchen könnt.

== Links ==

Anleitung: [http://www.elv-downloads.de/Assets/Produkte/10/1030/103076/Downloads/103076_HM_PB_2_WM55_UM.pdf PDF]

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

HM-LC-BL1-FM Funk-Jalousieaktor

2015-02-07T21:41:13Z

Rohan: /* Hinweise zum Betrieb mit FHEM */ Peeren mit einem HM-PB-2-WM55

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=HomeMatic Unterputz Funk Rollladenaktor
|HWProtocol=HomeMatic
|HWType=Aktor
|HWCategory=HomeMatic
|HWComm=868 MHz
|HWChannels=1
|HWVoltage=230V
|HWPowerConsumption=<0,5W (Ruhebetrieb)
|HWPoweredBy=Netz
|HWSize=53x53x30mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

Homematic Funk-Jalousieaktor 1-fach (Unterputz)

== Features ==
Schalten eines angeschlossenen Jalousiemotors mittels [[CUL]]/CUN/[[HMLAN Konfigurator]] und über einen mechanischen spannungsfesten Taster.

'''Technische Daten:'''
* Schaltvermögen: 250W Motorlast 230V/50Hz
* Relais: 1x Schließer und 1 Wechsler
* Standby Verbrauch: 0,5W
* Maße(BxHxT): 53x53x30mm

== Installation ==
Will man die Funk-Schaltaktoren auch manuell betreiben, so sind Taster notwendig. Schalter können notfalls mittels einer zusätzlichen Feder zum Taster umgebaut werden, Tastschalter sind nicht geeignet. Schalter und Tastschalter führen dazu, dass der Aktor nach Betätigung des Schalters in den Anlernmodus versetzt wird und auch in diesem verbleibt.

Je nach vorhandenen Schalterdosen empfiehlt es sich, bestehende Schalterdosen nach hinten auszuweiten, d.h. die Abdeckung nach hinten heraus zu brechen, da die Aktoren und Kabel nicht gerade sparsam mit dem Platz umgehen. Alternativ kann der Aktor auch in einer zusätzlichen Schalterdosen untergebracht und diese mit einem Federdeckel verschlossen werden. Dies hat den Vorteil, dass auch durch eine relativ dicke Tapete die LED und somit der Zustand des Aktors erkannt werden kann.

== Hinweise zum Betrieb mit FHEM ==
Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden. Hierfür wird ein am Aktor temporär angeschlossener spannungsfester Taster zwingend benötigt oder es erfolgt über Fhem mittels der Seriennummer.

=== Konfiguration ===
Ein exemplarischer Auszug aus der [[Konfiguration]] (fhem.cfg):

<pre>
define JalousieWohnzimmer CUL_HM 17E43C
attr JalousieWohnzimmer devInfo 010100
attr JalousieWohnzimmer firmware 1.5
attr JalousieWohnzimmer hmClass receiver
attr JalousieWohnzimmer model HM-LC-BL1-FM
attr JalousieWohnzimmer room Wohnzimmer
attr JalousieWohnzimmer serialNr IEQ0xxxxxx
attr JalousieWohnzimmer subType blindActuator
</pre>

=== Mögliche Schaltoperationen ===
Der Aktor versteht folgende Aktionen:

<pre>
set <name> on -> Schaltet den Aktor ein
set <name> off -> Schaltet den Aktor aus
set <name> toggle -> Ändert den logischen Zustand des Aktors, d.h. ein eingeschalteter Aktor wird ausgeschaltet. Im Falle der 10% geöffneten Jalousie wird diese geschlossen.
set <name> <Zweistellige Zahl> -> Schaltet den Aktor ein und öffnet die Jalousie um <Zweistellige Zahl>%. 100% entspricht dabei einem "on"
</pre>

=== Fahrtzeiten 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 drei Zeiten werden in Sekunden gemessen und anschließend einmalig mit den folgenden Befehlen eingestellt:

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

Wichtig: Danach unbedingt am Aktor auf Anlernen drücken, damit er die regSets abarbeiten kann. Ob alles geklappt hat, kann überprüft werden mit:
<pre>
set <name> getConfig
get <name> reg all
</pre>
Dort sollten dann die Werte stehen, z.B.
<pre>
WZ_Jal_Rechts type:blindActuator -
list:peer register :value
0: intKeyVisib :invisib
0: pairCentral :0xE1F88A
1: driveDown :27 s
1: driveTurn :0.5 s
1: driveUp :27 s
1: refRunCounter :0
1: sign :off
</pre>

wenn noch z.B. bei driveDown steht <code>set_27</code>, dann hat es noch nicht geklappt, dann müsst ihr nochmal anlernen drücken.
Und am besten jetzt nochmal im Eingabefeld in fhem ein "save" absetzen. Wenn ihr die Konfiguration des Schalters für Euch als Textdatei speichern wollt, dann hilft Euch ein
:<code>get <name> saveConfig <dateiname></code>

Das legt dann eine Datei in Eurem fhem-"root" Verzeichnis ab, in der alle Werte stehen.

=== Tasterverhalten ===

Das Tasterverhalten kann auch (zusätzlich) auf 1-Tasten-Bedienung (1 Taste drücken für rauf oder runter, die selbe Taste drücken zum Stoppen) umgestellt werden. Hierzu ist wie beim [[HM-LC-Bl1PBU-FM_Unterputz-Jalousieaktor#Tasterverhalten|HM-LC-Bl1PBU-FM]] vorzugehen. Diese Konfiguration hat beim HM-LC-BL1-FM aber die evtl. unerwünschte Nebenwirkung, dass die Funktionalität der Tasten umgedreht wird: Aus der Rauf-Taste wird die Runter-Taste und umgekehrt. Wer dies nicht möchte, sollte diese Änderung nicht vornehmen. Sobald eine Lösung existiert, wird diese hier beschrieben.

=== Peeren mit einem HM-PB-2-WM55 ===

Um bei einem Ausfall von Fhem den Rollladenaktor ersatzweise mit einem Schalter bedienen zu können, kann auch ein [[HM-PB-2-WM55_2fach-Funk-Wandtaster|HM-PB-2-WM55]] gewählt werden, der direkt mit dem Rolladenaktor gepeert wird.

Mittels des Befehls

set <HM-PB-2-WM55>_01 peerChan 0 <HM-LC-BL1-FM>

werden gleich beide Taster (rauf/runter) mit dem Rolladenaktor gep'''ee'''rt. Der Channel 02 des Tasters übernimmt dann die Rauf-Funktion, der Channel 01 die Runter-Funktion. Mittels kurzem Druck des entsprechenden Tasters wird der Rolladen komplett hoch- bzw. runtergefahren (stopp mit dem jeweils anderen Taster). Ein langer Druck erzeugt eine Fahrt des Rolladen in die gewünschte Richtung '''für die Dauer''' des Tastendrucks.

=== Log-Auszug ===
In FHEM ist nach dem Schalten des HM-LC-BL1-FM folgendes Log zu sehen:

<pre>
2012.02.12 17:53:08 2: CUL_HM set JalousieWohnzimmer on
2012.02.12 17:53:09 2: CUL_HM set JalousieWohnzimmer off
2012.02.12 21:25:14 2: CUL_HM set JalousieWohnzimmer 37
</pre>

= Links =
* [[Jalousie und Beleuchtung in mehreren Räumen]]
* [[Slider für HM-Rollladensteuerung anzeigen]]
* [http://www.elv-downloads.de/service/manuals/76793_HM_Unterputzschalter_UM.pdf Bedienungsanleitung] (PDF, ELV)

[[Kategorie:HomeMatic Components]]
[[Kategorie:HomeMatic Type Blind]]
[[Kategorie:Rollladensteuerung]]

Denon AV-Receiver

2015-02-06T13:33:17Z

Rohan: /* Installation */ Typo

== Features / Funktionen ... ==

Für AV-Receiver des Herstellers D&M Holding (Marken Denon und Marantz) gibt es ein FHEM-Modul, welches allerdings aktuell noch nicht offiziell aufgenommen wurde. Es gibt entsprechend auch noch keinen Eintrag in der CommandRef. Dieser Wiki-Eintrag enthält daher das Wichtigste zum Einstieg in die Nutzung.

== Hinweise zum Betrieb mit Fhem ==

===Voraussetzungen AVR===

Der zu steuernde AVR sollte so eingestellt sein, dass er auch im Stand-by eine Netzwerkverbindung hat (s. jeweilige Anleitung). Außerdem muss die IP des AVR bekannt sein; hierzu dem AVR entweder direkt oder über den DHCP-Server eine feste IP zuordnen.

===Installation===

Das Modul von [https://github.com/xusader/fhem-denon/blob/master/FHEM/71_DENON_AVR.pm github] laden, im Modules-Verzeichnis speichern (Rechte beachten!) und durch

<code>reload 71_DENON_AVR.pm</code>

in fhem laden.

===Einrichten===

<code>define <gewählter_Gerätename> DENON_AVR <IP_des_Gerätes></code>

Zum Beispiel also:

<code>define Marantz DENON_AVR 192.168.1.22</code>

===Readings===

Zur Nutzung in FHEM können die folgenden Readings (Beispiel) ausgewertet werden:

<pre style="width:500px;">
2015-02-06 13:15:05 input MPLAY
2015-02-06 13:15:05 mute off
2015-02-06 13:50:10 power =2
2015-02-06 13:16:08 sound STEREO
2015-02-06 13:15:04 state opened
2015-02-06 13:16:08 volume 40
2015-02-06 13:16:08 volumeStraight -40
</pre>

<code>volumeStraight</code> entspricht dabei der Lautstärkeangabe in dB.

Das Reading <code>power</code> scheint gerätespezifisch mehr als an oder aus auszugeben. Bei einem Maratz SR7008 z.B. ist "1" aus, "2" an. Davor steht teilweise "=", teilweise "r:", bisher ohne erkennbare Systematik.

===Ein-/Ausschalten===

<code>set <gewählter_Gerätename> [on|off]</code>

===Stumm an/aus===

<code>set <gewähler_Gerätename> mute [on|off]</code>

===Quellenwahl===

<code>set <gewählter_Gerätename> input <Quelle></code>

<Quelle> hängt dabei vom jeweiligen AVR ab. Eine Übersicht über mögliche Quellen sind z.B. in der am Ende dieses Artikels verlinkten Übersicht über Command-Codes für viele Geräte abrufbar.

Zum Beispiel für die Quelle "Media Player" bei Marantz:

<code>set Marantz input MPLAY</code>

== Bekannte Probleme ==

Beim Neustart von FHEM oder beim Einschalten des Stroms für den AVR ist der Status des Moduls "disconnected". Das lässt sich nur über die Neuinstallation des Moduls oder über ein

<code>modify <gewählter_Gerätename> <IP_des_Gerätes></code>

beheben. Läuft der AVR an einer von FHEM ansteuerbaren Steckdose, lässt sich das für das Einschalten des AVR auch automatisieren, z.B.:

<code>define Poweron notify FS20Schalter:on sleep 75;;modify <gewählter_Gerätename> <IP></code>

== Links ==

* [http://forum.fhem.de/index.php/topic,11338.msg66536.html Forumthread inkl. Modul]
* [http://www.denon.de/ Herstellerseite zur Marke Denon]
* [http://www.marantz.de/ Herstellerseite zur Marke Marantz]
* [http://www.awe-europe.com/ir_232.html Seite, auf der die Command-Codes für viele Geräte abrufbar sind]

[[Kategorie:Unterhaltungselektronik]]

Backup

2015-01-29T10:26:30Z

Rohan: /* Backup manuell ausführen (Weboberfläche) */ erläuternden Hinweis eingefügt

{{SEITENTITEL:backup}}
{{Infobox Modul
|ModPurpose=Datensicherung der Fhem-Installation
|ModType=c
|ModCmdRef=backup
|ModForumArea=Sonstiges
|ModTechName=98_backup.pm
|ModOwner=rudolfkoenig ([http://forum.fhem.de/index.php?action=profile;u=8 Forum] / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}
{{Randnotiz|RNTyp=Warn|RNText=Die Datensicherung kann je nach verwendeter Server Hardware recht lange dauern.}}
Für Datensicherungszwecke ist in Fhem der Befehl '''backup''' integriert.

Im Auslieferungszustand von fhem werden die erstellten Backups im Ordner <code>/var/opt/fhem/Backup</code> abgelegt. Die Datensicherung umfasst das komplette Fhem-Verzeichnis. Damit sind alle angepassten und selbst erstellten Dateien und Icons enthalten. Das Backup wird als .tar.gz Datei abgelegt und trägt dabei im Namen das Datum und die Uhrzeit, an dem das Backup ausgeführt wurde.

Weitere Details zu dem Befehl ''backup'' können der [http://fhem.de/commandref.html#backup commandref] entnommen werden.

== Backup manuell ausführen (Eingabefeld) ==
Um ein Backup zu erstellen genügt es, in der fhem [[PGM2|Benutzeroberfläche]] im Eingabefeld den Befehl ''backup'' zu schreiben und mit return auszuführen (nicht den Save-Button betätigen, das würde nämlich kein Backup erstellen).

Danach findet sich eine Backupdatei in dem oben genannten Verzeichnis. In der Fhem Logdatei sollte ein Eintrag
:<code>backup done: FHEM-<Datum>_<Build>.tar.gz (<Größe> Bytes)</code>
zu finden sein.

== Backup manuell ausführen (Weboberfläche) ==
Der Backup-Befehl kann in die Weboberfläche als manuell ausführbare Aktion eingebunden. Das lässt sich mit dem folgenden Code in der fhem.cfg erreichen:

#########################################################################
## Funktion......: FHEM Backup
## Besonderheiten: Manuelles Backup
#########################################################################
define SYS_Backup dummy
attr SYS_Backup alias FHEM Backup ausführen
attr SYS_Backup room Server
attr SYS_Backup webCmd Ausführen
define SYS_BackupRun notify SYS_Backup:* backup
attr SYS_BackupRun room Server
#########################################################################

Alternativ kann man das notify noch etwas weiter aufbohren, dann wird in der dummy-Variablen angezeigt, welche Backups bereits gemacht wurden. Nicht vergessen, den Pfad einzutragen!

Der folgende Code ist in die Datei [[99_myUtils_anlegen|99_myUtils.pm]] einzuarbeiten

#########################################################################
## Funktion......: FHEM Backup
## Besonderheiten: Anzeige der vorhandenen Backups im dummy
#########################################################################
SYS_Backup:* {
fhem("backup");;
opendir DIR, "Hier_den_Pfad_zu_Eurem_Backupverzeichnis" or die $!;;
my $mybackups = "";;
while(my $file = readdir DIR){
next if($file eq "." || $file eq "..");;
$mybackups = $mybackups."$file ";;
}
closedir DIR;;
fhem("set SYS_Backup ".$mybackups);;
}
#########################################################################

== Backup automatisch ausführen ==
Die regelmäßige automatische Erstellung einer Datensicherung lässt sich mit folgenden Einträgen in der fhem.cfg erreichen:

#########################################################################
## Funktion......: FHEM Backup
## Besonderheiten: Autom. Backup
#########################################################################
define NTFY_BackupRun at *23:59:00 set SYS_Backup Ausführen
attr NTFY_BackupRun room Server
#########################################################################

Damit wird täglich um 23:59 ein Backup erstellt.

== Backup vor Update ==
Ist in der fhem.cfg der Eintrag
:<code>attr global backup_before_update 1</code>
enthalten, wird vor der Durchführung eines Update erst eine Datensicherung in das festgelegte Backup Verzeichnis durchgeführt.

[[Kategorie:HOWTOS]]
[[Kategorie:Glossary]]

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

2015-01-28T19:17:43Z

Rohan: /* Tastensperre */ Ausdrucksfehler korrigiert.

Beim '''HM-CC-RT-DN''' handelt es sich um einen '''Funk-Heizkörperthermostaten mit integriertem Stellantrieb''', der als Nachfolger den [[HM-CC-VD]] ablöst und seit Mitte September 2013 verfügbar ist.

== Vorbemerkungen ==

Im Gegensatz zum Vorgänger misst der HM-CC-RT-DN selbst die Temperatur und verfügt über eine Boost-Funktion. Er braucht zur Steuerung kein separates Raumregelungsgerät mehr und hat eine eigene Fenster-Offen-Erkennung. Ein passender Wandthermostat ([[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]]) ist seit Februar 2014 verfügbar.

Das Gerät wird seit Anfang Oktober 2013 von Fhem unterstützt (siehe Diskussion im [http://forum.fhem.de/index.php/topic,14738.0.html 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 Firmware Update Software. Weitere Details sind unter [[HM-CC-RT-DN_Funk-Heizkörperthermostat#Firmware_Update|Firmware Update ]] beschrieben.

'''Achtung:''' Die Solltemperaturen eines HM-CC-RT-DN lassen sich <ins>nicht</ins> durch einen [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]] steuern. Dieser kann höchstens die Ist-Temperatur an den RT weiter geben, damit die Raumtemperatur nicht am RT selbst zur Ventilsteuerung genommen 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
gep'''ee'''rt 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.3

== Betrieb mit FHEM ==
Der Funk-Heizkörperthermostat muss zuerst mit Fhem [[HomeMatic_Devices_pairen|gepairt]] werden. Da es den RT noch nicht lange gibt, sollten Sie sicher stellen, 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 kann z.B. ein HomeMatic HM-WDS10-TH-O Funk-Temperatur-/Luftfeuchtesensor OTH dienen.

Der Befehl zum peeren lautet, wobei <tempSensor> die Fhem-Kanalbezeichnung für den Sensor ist und <rt_Weather> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates:
set <tempSensor> peerChan 0 <rt_Weather> single

==== Channel (Kanal) 02 _Climate ====
Der Climate-channel dient der Kommunikation mit einem Temperatur-Kontroller (aktuell nur [[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]]).
Zum peeren von TC und RT siehe [[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP#Hinweise zur Inbetriebnahme und Installation|HM-TC-IT-WM-W-EU]]

==== 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.
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]] näher 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 <rt_WindowRec> single

Zum Löschen (=unpeeren) dieser Kopplung:
set <fensterSensor> peerChan 0 <rt_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 <rt_WindowRec> regSet winOpnTemp <Temp> <fensterSensor>

==== Channel (Kanal) 04 _Clima ====
Dieser Kanal dient zum Einstellen der Betriebsparameter, auch [[#Temperaturlisten]] sind hierauf zu übrtragen.

'''Achtung:''' In älteren Versionen von Fhem wurde dieser Kanal durch autocreate als "_ClimRT_tr" angelegt. Der Hersteller hat hier offenbar die internen Bezeichnunen 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 <rt_Clima> regSet valveMaxPos 80

Die interne "Fenster-auf" Erkennung kann man wie folgt abschalten:
set <rt_Clima> regSet winOpnMode off

==== Channel (Kanal) 05 _ClimaTeam ====
Dieser Kanal dient zum peeren von mehreren Heizkörperthermostaten untereinander. 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 <rt1-ClimaTeam> und <rt2-ClimaTeam> die Kanalbezeichnungen der beiden ClimaTeam-Kanäle sind:
set <rt1-ClimaTeam> peerChan 0 <rt2-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:
<pre>set <button> peerChan 0 <rt-remote> single</pre>

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

Im Automode kann man die Temperatur am Einstellrad des RT ändern. Zum nächsten Schaltpunkt wird dies dann überschrieben. Will man dies nicht (z.B. lange Party, ...), kann man auf manuell schalten. Dann bleibt die mit dem Drehregler (oder der Zentrale) eingestellte Temperatur stehen bis ''ultimo''. Es gibt dann noch den Party- oder Urlaubsmodus. In diesen kann man den Automodus für eine gegebene Zeit überschreiben.

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

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

==== Modus Manu ====
Das Wochenprogramm wird nicht abgearbeitet, die Temperatur wird manuell eingestellt.

==== Modus Party (Urlaub) ====

Will man für eine festgesetzte Zeit (Stunden oder Tage) die Temperatur auf einen festen Wert einstellen (z.B. weil man in Urlaub fährt), kann man dies zwar auch durch Änderungen der Temperaturlisten erreichen, einfacher ist aber die Zuweisung über den Urlaubsmodus, da nach dessen Ablaufdatum und -zeitpunkt automatisch in den Auto-Modus gewechselt wird.

'''Ein Beispiel:'''

<pre>
set HM-CC-RT-DN_Clima controlParty 16 06.12.13 16:30 09.12.13 05:00
</pre>

Dadurch wird

* vom 06.12.2013, 16:30 Uhr,
* bis zum 09.12.2013, 05:00 Uhr
* die gewünschte Raumtemperatur auf 16 °C

eingestellt.

'''Hinweise:'''
* Der Befehl muss auf den Channel 4 ("_Clima") erfolgen.
* Es werden nur Uhrzeiten zu jeder vollen oder halben Stunde angenommen (Minuten also 00 oder 30).

Mit der Funktion "Urlaub" kann man eine ganze Wohnung (also mehrere RT´s) mit nur einem Befehl in den Party-mode versetzen. 
Der Name "Urlaub" kann natürlich frei gewählt werden.
Im Beispiel werden 2 Heizkörper (Treppenhaus und Kammer) angesteuert.

Zu beachten sind folgende Dinge:
# Aktuelle Dateien (z.B. 10_CUL_HM) verwenden!
# Bei dem partycontrol-Befehl in der Funktion KEIN Komma zwischen den Parametern.
# Bei der Funktion die Parameterübergabe definieren ($$$$$)

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

'''Funktion:'''
<pre>
my $Urlaub;
sub
Urlaub($$$$$)
{
#lokale Variablendeklaration
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/;

#Sendebefehl für ein HM-CC-RT-DN
{fhem ("set Kammer controlParty $temp $startDate $startTime $endDate $endTime")}

# alternative Schreibweise der Parameter:
{fhem ("set Treppenhaus controlParty @_[0] @_[1] @_[2] @_[3] @_[4]")};
}
</pre>

=== 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 Kommanods. 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 RT muss den Receiver wach halten. Der RT und alle anderen Burst-Devices erwachen bei '''jedem''' Burst (egal für wen) und legen sich dann wieder schlafen.
* jeder Burst-trigger kostet Batterie für '''alle''' Burst-Geräte im System
* wenn Burst enabled ist kostet es dem RT Batteriekapazität

'''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 messages 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 message. 
 
'''ConditionalBurst devices''' 
Devices mit abschaltbarem burst wie z.B. der 'HM-CC-RT-DN', gibt es ein Register burstRx mit dem das burst-erwachen eingestellt werden kann.
Sender, 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 Hminfo kommando 'models' um festzustellen, welche devices welchen mode 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) 
<pre>set WZ1_4 regSet burstRx on </pre>
prüfen mit: 
<pre>get WZ1_4 reg burstRx </pre>
''Nun in FHEM den Burst mode einschalten (sofern nicht burstXmit verwendet wird)'' 
<pre>attr WZ1 burstAccess 1_auto</pre>

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

=== Temperaturprofile ===
Im Kanal ''Clima'' kann man einen Wochenplan (ein Temperaturprofil) hinterlegen. Im automatischen Betrieb stellt der Heizkörperhermostat dann die Wunschtemperatur gemäß diesem Profil ein. Die Daten werden in Registern des Heizkörperthermostates abgelegt, es gibt gesonderte Kommandos zur Verwaltung des Profils. Die Darstellung des Temperaturprofils unterliegt aber dennoch den Regeln der Register: Fhem muss die Daten aus dem Device lesen (getConfig), um sie darzustellen.
Ändert man eine der Temperaturlisten müssen die Daten an das Device übertragen werden. Bis dies bestätigt ist wird in Reading '''R_tempList_State''' '''set''' angezeigt. Sobald die daten aus dem Device zurückgelesen sind steht wird es auf '''verified''' gesetzt (sollte der Normalzustand sein). '''incomplete''' wird gesetzt, falls beim Lesen der Register ein Teil der Daten nicht empfangen wurde.
==== Manuelle Änderung ====
Mit dem Kommando
set <rt>_Clima tempListMon 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0
kann man das Temperaturprofil für den Wochentag ''Montag'' einstellen. Die nach dem Schaltzeitpunkt stehende Temperatur gilt immer '''bis''' zu diesen Zeitpunkt, nicht ab diesem Zeitpunkt. Der letzte Wert muss immer Mitternacht (24:00) sein.
damit ist also 00:00 - 05:30 = 16Grad, 05:30 - 07:30 = 18 Grad. Die Zeit kann in Schritten von 30min eingestellt werden, die Temperatur in 0.1 Grad.
Der Tage beginnt immer um 00:00, der letzte Abschnitt MUSS 24:00 sein.

Ändert man mehrere Tage auf einmal sollte man unbedingt mit "prep" und "exec" arbeiten, da es sonst zu Wiederholungen und langen Bearbeitungen kommen kann. Prep bereitet die Änderung in FHEM nur vor, mit exec werden die Daten dann an das Device übertragen. Das könnte in einem Fhem-Script lauten
sub
SetTempList_UG_Treppe_Heizung()
{
{ fhem ("set UG.Treppe.Heizung_Clima tempListMon prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListTue prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListWed prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListThu prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListFri prep 05:30 16.0 07:00 18.0 15:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListSat prep 07:00 16.0 09:00 18.0 15:00 18.5 21:00 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListSun '''exec''' 07:00 16.0 09:00 18.0 15:00 18.5 21:00 19.0 24:00 16.0")};
}

==== Temperaturprofile in einer Datei====
Eleganter ist die Verwaltung von Temperaturprofilen in einer Datei. Damit kann man
* 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

===== Dateiformat =====
Die Temperaturprofile werden in einer Datei abgelegt im Format
entities:room1
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 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
entities:room2,room3
tempListSat>08:00 18.0 15:00 18.0 21:30 19.0 24:00 14.0
tempListSun>08:00 18.0 15:00 18.0 21:30 19.0 24:00 14.0
...

* '''entities''' ist eine komma-separierte Liste der Namen des folgenden Temperaturprofils. Das erste Temperaturprofil im Beispiel hat den Namen "room1", das 2. hat zwei Namen, "room2" und "room3".
* '''tempList...''' ist die Liste der Schaltzeiten und Temperaturen des Tages. Die nach dem Schaltzeitpunkt stehende Temperatur gilt immer '''bis''' zu diesen Zeitpunkt, nicht ab diesem Zeitpunkt. Der letzte Wert muss immer Mitternacht (24:00) sein.

===== Temp Profil Datei erstellen/updaten =====
Mit HMInfo kann man eine Temperaturdatei ???  oder updaten.
set hm tempList save <filename>
set hm tempList save -f <channelName> <filename>
Die Temperaturlisten der Devices, ggf. nur der gefilterten Devices - werden in das File abgelegt. Sollte für die Entity bereits ein Eintrag vorhanden sein wird dieser ersetzt. Vorhandene weitere Einträge werden nicht geändert. Das save ist unabhängig von attribut tempListTmpl.
Default für Filename ist "tempList.cfg". Als Entity wird der Name des Kanals genutzt.

===== Überprüfen/Einlesen =====
Mit dem verify-Kommando wird überprüft, ob das gegenwärtig vorhandene Temperaturprofil mit dem in der Datei befindlichen übereinstimmt.
set <rt>_Clima tempListTmpl verify FHEM/tempList.cfg:room1
Mit dem restore-Kommando wird das Temperaturprofil des Heizkörperthermostaten mit dem in der Datei befindlichen überschrieben.
set <rt>_Clima 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 <rt>_Clima tempListTmpl FHEM/tempList.cfg:room1
set <rt>_Clima 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 <rt>_Clima tempListTmpl restore
überschreibt das gegenwärtige Temperaturprofil des Heizkörperthermostaten mit dem in der Datei befindlichen überschrieben.
===== Vorschlag =====
Zur Verwaltung der Temperaturprofile sollte die Datei tempList.cfg im Verzeichnis FHEM liegen, dann kann sie mit dem Web-Interface editiert werden.
Wenn man im Sommer allen HKs das gleiche Profil geben will, kann man dies in der Datei erstellen und weist allen das template zu. Hier ein Beispiel für RT's:
attr TYPE=CUL_HM:FILTER=DEF=......04:FILTER=model=HM-CC-RT-DN tempListTmpl tempList.cfg:sommer
set hm tempListTmpl restore
set hm tempListTmpl verify
Nach dem Restore natürlich warten, bis die Daten geschrieben sind.

==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 15.07.2014 gibt es für den HM-CC-RT-DN die neue Firmware Version 1.3. 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.

== 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 dem Forum: [http://forum.fhem.de/index.php/topic,31078.msg236245.html#msg236245 Thread]''
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 dem Forum: [http://forum.fhem.de/index.php/topic,19686.msg233788.html#msg233788 Thread]''

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 Type hmInfo existiert):
set hm peerXref
Beispiel-Ausgabe:
peerXref done:
x-ref list
wz_Thermostat_Weather => wz_vT_Sensor1
wz_vT_Sensor1 => wz_Thermostat_Weather

6. Gemessene Temperatur vom zb. 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. Nähere Informationen zu dieser Funktion siehe [[FHEM_Command_Beispiele#update_...|hier]].

== Links ==
* [http://www.elv.de/homematic-heizkoerperthermostat-1.html Produktinfo]
* [http://www.elv-downloads.de/Assets/Produkte/10/1051/105155/Downloads/105155_thermostat_um.pdf Bedienungsanleitung (PDF)]
* [http://www.elv-downloads.de/Assets/Produkte/10/1051/105155/Downloads/105155_thermostat_data.pdf Datenblatt (PDF)]
* [http://www.elv-downloads.de/service/manuals/ventilkompatibilitaet.pdf Ventil-Kompatibilitätsliste (PDF)]

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

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

2015-01-28T19:15:30Z

Rohan: /* Links */ Infos zur Tastensperre eingearbeitet

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

HomeMatic-Wandthermostat Aufputz.

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

Verfügbar seit Februar 2014.

Nachfolger des [[HM-CC-TC_Funk-Wandthermostat|HM-CC-TC]].

Integration in Fhem ist mittlerweile möglich, ist aber evtl. noch nicht komplett.

== Features ==

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

== Hinweise zur Inbetriebnahme und Installation ==

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

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

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.

Das Peering mit einem Schaltaktor läuft z.B. wie folgt ab:

set <HM-TC-IT-WM-W-EU-Gerät>_SwitchTr peerChan 0 <HM-LC-SW1-FM> single set

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

== Probleme ==
< Bitte ergänzen >

== Betrieb mit FHEM ==

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

=== fhem.log Auszug ===
< Bitte ergänzen >

=== fhem.cfg ===
< Bitte ergänzen >

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

== 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-CC-RT-DN Funk-Heizkörperthermostat

2015-01-28T19:10:08Z

Rohan: /* Betriebsmodus Auto, Manu, Party (Urlaub) */ Anmerkung zur Tastensperre eingearbeitet

Beim '''HM-CC-RT-DN''' handelt es sich um einen '''Funk-Heizkörperthermostaten mit integriertem Stellantrieb''', der als Nachfolger den [[HM-CC-VD]] ablöst und seit Mitte September 2013 verfügbar ist.

== Vorbemerkungen ==

Im Gegensatz zum Vorgänger misst der HM-CC-RT-DN selbst die Temperatur und verfügt über eine Boost-Funktion. Er braucht zur Steuerung kein separates Raumregelungsgerät mehr und hat eine eigene Fenster-Offen-Erkennung. Ein passender Wandthermostat ([[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]]) ist seit Februar 2014 verfügbar.

Das Gerät wird seit Anfang Oktober 2013 von Fhem unterstützt (siehe Diskussion im [http://forum.fhem.de/index.php/topic,14738.0.html 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 Firmware Update Software. Weitere Details sind unter [[HM-CC-RT-DN_Funk-Heizkörperthermostat#Firmware_Update|Firmware Update ]] beschrieben.

'''Achtung:''' Die Solltemperaturen eines HM-CC-RT-DN lassen sich <ins>nicht</ins> durch einen [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]] steuern. Dieser kann höchstens die Ist-Temperatur an den RT weiter geben, damit die Raumtemperatur nicht am RT selbst zur Ventilsteuerung genommen 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
gep'''ee'''rt 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.3

== Betrieb mit FHEM ==
Der Funk-Heizkörperthermostat muss zuerst mit Fhem [[HomeMatic_Devices_pairen|gepairt]] werden. Da es den RT noch nicht lange gibt, sollten Sie sicher stellen, 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 kann z.B. ein HomeMatic HM-WDS10-TH-O Funk-Temperatur-/Luftfeuchtesensor OTH dienen.

Der Befehl zum peeren lautet, wobei <tempSensor> die Fhem-Kanalbezeichnung für den Sensor ist und <rt_Weather> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates:
set <tempSensor> peerChan 0 <rt_Weather> single

==== Channel (Kanal) 02 _Climate ====
Der Climate-channel dient der Kommunikation mit einem Temperatur-Kontroller (aktuell nur [[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]]).
Zum peeren von TC und RT siehe [[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP#Hinweise zur Inbetriebnahme und Installation|HM-TC-IT-WM-W-EU]]

==== 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.
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]] näher 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 <rt_WindowRec> single

Zum Löschen (=unpeeren) dieser Kopplung:
set <fensterSensor> peerChan 0 <rt_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 <rt_WindowRec> regSet winOpnTemp <Temp> <fensterSensor>

==== Channel (Kanal) 04 _Clima ====
Dieser Kanal dient zum Einstellen der Betriebsparameter, auch [[#Temperaturlisten]] sind hierauf zu übrtragen.

'''Achtung:''' In älteren Versionen von Fhem wurde dieser Kanal durch autocreate als "_ClimRT_tr" angelegt. Der Hersteller hat hier offenbar die internen Bezeichnunen 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 <rt_Clima> regSet valveMaxPos 80

Die interne "Fenster-auf" Erkennung kann man wie folgt abschalten:
set <rt_Clima> regSet winOpnMode off

==== Channel (Kanal) 05 _ClimaTeam ====
Dieser Kanal dient zum peeren von mehreren Heizkörperthermostaten untereinander. 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 <rt1-ClimaTeam> und <rt2-ClimaTeam> die Kanalbezeichnungen der beiden ClimaTeam-Kanäle sind:
set <rt1-ClimaTeam> peerChan 0 <rt2-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:
<pre>set <button> peerChan 0 <rt-remote> single</pre>

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

Im Automode kann man die Temperatur am Einstellrad des RT ändern. Zum nächsten Schaltpunkt wird dies dann überschrieben. Will man dies nicht (z.B. lange Party, ...), kann man auf manuell schalten. Dann bleibt die mit dem Drehregler (oder der Zentrale) eingestellte Temperatur stehen bis ''ultimo''. Es gibt dann noch den Party- oder Urlaubsmodus. In diesen kann man den Automodus für eine gegebene Zeit überschreiben.

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

Rückgängig wieder per

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

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

==== Modus Manu ====
Das Wochenprogramm wird nicht abgearbeitet, die Temperatur wird manuell eingestellt.

==== Modus Party (Urlaub) ====

Will man für eine festgesetzte Zeit (Stunden oder Tage) die Temperatur auf einen festen Wert einstellen (z.B. weil man in Urlaub fährt), kann man dies zwar auch durch Änderungen der Temperaturlisten erreichen, einfacher ist aber die Zuweisung über den Urlaubsmodus, da nach dessen Ablaufdatum und -zeitpunkt automatisch in den Auto-Modus gewechselt wird.

'''Ein Beispiel:'''

<pre>
set HM-CC-RT-DN_Clima controlParty 16 06.12.13 16:30 09.12.13 05:00
</pre>

Dadurch wird

* vom 06.12.2013, 16:30 Uhr,
* bis zum 09.12.2013, 05:00 Uhr
* die gewünschte Raumtemperatur auf 16 °C

eingestellt.

'''Hinweise:'''
* Der Befehl muss auf den Channel 4 ("_Clima") erfolgen.
* Es werden nur Uhrzeiten zu jeder vollen oder halben Stunde angenommen (Minuten also 00 oder 30).

Mit der Funktion "Urlaub" kann man eine ganze Wohnung (also mehrere RT´s) mit nur einem Befehl in den Party-mode versetzen. 
Der Name "Urlaub" kann natürlich frei gewählt werden.
Im Beispiel werden 2 Heizkörper (Treppenhaus und Kammer) angesteuert.

Zu beachten sind folgende Dinge:
# Aktuelle Dateien (z.B. 10_CUL_HM) verwenden!
# Bei dem partycontrol-Befehl in der Funktion KEIN Komma zwischen den Parametern.
# Bei der Funktion die Parameterübergabe definieren ($$$$$)

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

'''Funktion:'''
<pre>
my $Urlaub;
sub
Urlaub($$$$$)
{
#lokale Variablendeklaration
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/;

#Sendebefehl für ein HM-CC-RT-DN
{fhem ("set Kammer controlParty $temp $startDate $startTime $endDate $endTime")}

# alternative Schreibweise der Parameter:
{fhem ("set Treppenhaus controlParty @_[0] @_[1] @_[2] @_[3] @_[4]")};
}
</pre>

=== 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 Kommanods. 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 RT muss den Receiver wach halten. Der RT und alle anderen Burst-Devices erwachen bei '''jedem''' Burst (egal für wen) und legen sich dann wieder schlafen.
* jeder Burst-trigger kostet Batterie für '''alle''' Burst-Geräte im System
* wenn Burst enabled ist kostet es dem RT Batteriekapazität

'''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 messages 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 message. 
 
'''ConditionalBurst devices''' 
Devices mit abschaltbarem burst wie z.B. der 'HM-CC-RT-DN', gibt es ein Register burstRx mit dem das burst-erwachen eingestellt werden kann.
Sender, 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 Hminfo kommando 'models' um festzustellen, welche devices welchen mode 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) 
<pre>set WZ1_4 regSet burstRx on </pre>
prüfen mit: 
<pre>get WZ1_4 reg burstRx </pre>
''Nun in FHEM den Burst mode einschalten (sofern nicht burstXmit verwendet wird)'' 
<pre>attr WZ1 burstAccess 1_auto</pre>

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

=== Temperaturprofile ===
Im Kanal ''Clima'' kann man einen Wochenplan (ein Temperaturprofil) hinterlegen. Im automatischen Betrieb stellt der Heizkörperhermostat dann die Wunschtemperatur gemäß diesem Profil ein. Die Daten werden in Registern des Heizkörperthermostates abgelegt, es gibt gesonderte Kommandos zur Verwaltung des Profils. Die Darstellung des Temperaturprofils unterliegt aber dennoch den Regeln der Register: Fhem muss die Daten aus dem Device lesen (getConfig), um sie darzustellen.
Ändert man eine der Temperaturlisten müssen die Daten an das Device übertragen werden. Bis dies bestätigt ist wird in Reading '''R_tempList_State''' '''set''' angezeigt. Sobald die daten aus dem Device zurückgelesen sind steht wird es auf '''verified''' gesetzt (sollte der Normalzustand sein). '''incomplete''' wird gesetzt, falls beim Lesen der Register ein Teil der Daten nicht empfangen wurde.
==== Manuelle Änderung ====
Mit dem Kommando
set <rt>_Clima tempListMon 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0
kann man das Temperaturprofil für den Wochentag ''Montag'' einstellen. Die nach dem Schaltzeitpunkt stehende Temperatur gilt immer '''bis''' zu diesen Zeitpunkt, nicht ab diesem Zeitpunkt. Der letzte Wert muss immer Mitternacht (24:00) sein.
damit ist also 00:00 - 05:30 = 16Grad, 05:30 - 07:30 = 18 Grad. Die Zeit kann in Schritten von 30min eingestellt werden, die Temperatur in 0.1 Grad.
Der Tage beginnt immer um 00:00, der letzte Abschnitt MUSS 24:00 sein.

Ändert man mehrere Tage auf einmal sollte man unbedingt mit "prep" und "exec" arbeiten, da es sonst zu Wiederholungen und langen Bearbeitungen kommen kann. Prep bereitet die Änderung in FHEM nur vor, mit exec werden die Daten dann an das Device übertragen. Das könnte in einem Fhem-Script lauten
sub
SetTempList_UG_Treppe_Heizung()
{
{ fhem ("set UG.Treppe.Heizung_Clima tempListMon prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListTue prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListWed prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListThu prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListFri prep 05:30 16.0 07:00 18.0 15:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListSat prep 07:00 16.0 09:00 18.0 15:00 18.5 21:00 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListSun '''exec''' 07:00 16.0 09:00 18.0 15:00 18.5 21:00 19.0 24:00 16.0")};
}

==== Temperaturprofile in einer Datei====
Eleganter ist die Verwaltung von Temperaturprofilen in einer Datei. Damit kann man
* 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

===== Dateiformat =====
Die Temperaturprofile werden in einer Datei abgelegt im Format
entities:room1
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 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
entities:room2,room3
tempListSat>08:00 18.0 15:00 18.0 21:30 19.0 24:00 14.0
tempListSun>08:00 18.0 15:00 18.0 21:30 19.0 24:00 14.0
...

* '''entities''' ist eine komma-separierte Liste der Namen des folgenden Temperaturprofils. Das erste Temperaturprofil im Beispiel hat den Namen "room1", das 2. hat zwei Namen, "room2" und "room3".
* '''tempList...''' ist die Liste der Schaltzeiten und Temperaturen des Tages. Die nach dem Schaltzeitpunkt stehende Temperatur gilt immer '''bis''' zu diesen Zeitpunkt, nicht ab diesem Zeitpunkt. Der letzte Wert muss immer Mitternacht (24:00) sein.

===== Temp Profil Datei erstellen/updaten =====
Mit HMInfo kann man eine Temperaturdatei ???  oder updaten.
set hm tempList save <filename>
set hm tempList save -f <channelName> <filename>
Die Temperaturlisten der Devices, ggf. nur der gefilterten Devices - werden in das File abgelegt. Sollte für die Entity bereits ein Eintrag vorhanden sein wird dieser ersetzt. Vorhandene weitere Einträge werden nicht geändert. Das save ist unabhängig von attribut tempListTmpl.
Default für Filename ist "tempList.cfg". Als Entity wird der Name des Kanals genutzt.

===== Überprüfen/Einlesen =====
Mit dem verify-Kommando wird überprüft, ob das gegenwärtig vorhandene Temperaturprofil mit dem in der Datei befindlichen übereinstimmt.
set <rt>_Clima tempListTmpl verify FHEM/tempList.cfg:room1
Mit dem restore-Kommando wird das Temperaturprofil des Heizkörperthermostaten mit dem in der Datei befindlichen überschrieben.
set <rt>_Clima 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 <rt>_Clima tempListTmpl FHEM/tempList.cfg:room1
set <rt>_Clima 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 <rt>_Clima tempListTmpl restore
überschreibt das gegenwärtige Temperaturprofil des Heizkörperthermostaten mit dem in der Datei befindlichen überschrieben.
===== Vorschlag =====
Zur Verwaltung der Temperaturprofile sollte die Datei tempList.cfg im Verzeichnis FHEM liegen, dann kann sie mit dem Web-Interface editiert werden.
Wenn man im Sommer allen HKs das gleiche Profil geben will, kann man dies in der Datei erstellen und weist allen das template zu. Hier ein Beispiel für RT's:
attr TYPE=CUL_HM:FILTER=DEF=......04:FILTER=model=HM-CC-RT-DN tempListTmpl tempList.cfg:sommer
set hm tempListTmpl restore
set hm tempListTmpl verify
Nach dem Restore natürlich warten, bis die Daten geschrieben sind.

==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 15.07.2014 gibt es für den HM-CC-RT-DN die neue Firmware Version 1.3. 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.

== 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 dem Forum: [http://forum.fhem.de/index.php/topic,31078.msg236245.html#msg236245 Thread]''
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 dem Forum: [http://forum.fhem.de/index.php/topic,19686.msg233788.html#msg233788 Thread]''

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 Type hmInfo existiert):
set hm peerXref
Beispiel-Ausgabe:
peerXref done:
x-ref list
wz_Thermostat_Weather => wz_vT_Sensor1
wz_vT_Sensor1 => wz_Thermostat_Weather

6. Gemessene Temperatur vom zb. 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. Nähere Informationen zu dieser Funktion siehe [[FHEM_Command_Beispiele#update_...|hier]].

== Links ==
* [http://www.elv.de/homematic-heizkoerperthermostat-1.html Produktinfo]
* [http://www.elv-downloads.de/Assets/Produkte/10/1051/105155/Downloads/105155_thermostat_um.pdf Bedienungsanleitung (PDF)]
* [http://www.elv-downloads.de/Assets/Produkte/10/1051/105155/Downloads/105155_thermostat_data.pdf Datenblatt (PDF)]
* [http://www.elv-downloads.de/service/manuals/ventilkompatibilitaet.pdf Ventil-Kompatibilitätsliste (PDF)]

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

HM-CC-TC Funk-Wandthermostat

2015-01-28T18:59:25Z

Rohan: /* Steuerungsmodi */ Anmerkung zum setzen der Tastensperre eingefügt.

'''HM-CC-TC Funk-Wandthermostat'''

Programmierbarer Raumthermostat, der bis zu 4 [[HM-CC-VD Funk-Stellantrieb]] steuern kann.

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt).'''

Nachfolgeprodukt ist der [[HM-CC-RT-DN]] bzw. (ab März 2014) [[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]].

= Features =
* Am Raumthermostat programmierbare Tages- und Nachttemperatur.
* Pro Wochentag können bis zu 24 Schaltpunkte definiert werden.
* Anbindung von <ins>jeweils</ins> '''maximal''' 4 Tür- bzw. Fensterkontakten ([[HM-Sec-RHS]]) zur Absenkung der Temperatur auf einen eigens eingestellten Temperaturwert (ab Werk: 12°C) bei offenem Fenster bzw. offener Tür.
* Anzeige der Temperatur und Luftfeuchtigkeit im Raum und Hintergrundbeleuchtung des Displays.

Alle 120 bis 184 Sekunden überträgt der Wandthermostat vorhandene Befehle zu den Stellantrieben. Jeder empfangene Befehl wird vom Stellantrieb bestätigt und dann ausgeführt. Täglich gegen Mitternacht synchronisiert ein HM-CC-TC seine Uhrzeit mit der HomeMatic-Zentrale (CCU, HMLAN).

= Hinweise zum Betrieb mit FHEM =
Vor dem Einsatz mit einer Zentrale sind erst alle Stellantriebe und Tür-/Fensterkontakte mit dem HM-CC-TC zu verbinden (P'''ee'''r).
Damit das ganze dann in FHEM auftaucht, muss der TC noch mit dem [[HMLAN Konfigurator]] gep'''ai'''rt werden.

Mit

<nowiki>set CUL hmPairForSec 300</nowiki>
setzt man das CUL / den HMLAN-Konfigurator für 5 Minuten in den Anlernmodus. Danach am Thermostaten 5 Sekunden lang die OK-Taste drücken und es wird eine Zeit von 20 auf 0 Sekunden gezählt:

* Klappt das Anlernen in diesen 20 Sekunden, wird der Countdown sofort beendet, anschließend für ca. 2-3 Sekunden "OK" angezeigt und der Thermostat ist in FHEM eingebunden.
* Gelingt das Anlernen nicht in den 20 Sekunden, erscheint nach Erreichen der "0" noch für 2 bis 3 Sekunden ein "NOK" ('''N'''ot '''OK''') im Display des TCs.

'''Alternativ'''(und so vom Entwickler des Fhem-HomeMatic-Moduls empfohlen) kann wie folgt vorgegangen werden:

* Alle Stellantriebe und Tür-/Fensterkontakte sowie den HM-CC-TC mit Fhem p'''ai'''ren (also ''set CUL hmPairForSec 300'' und an allen Devices den Anlernknopf drücken innerhalb des Zeitfensters von 300 Sekunden).
* Die Stellantriebe und Tür-/Fensterkontakte mit den ''Channels'' (siehe unten) p'''ee'''ren (siehe <nowiki>[http://fhem.de/commandref.html#CUL_HMpeerChan commandref :peerChan]</nowiki>). Hierzu werden die entsprechenden Fhem-Befehle über das Webinterface von Fhem erteilt.

'''Hinweis:'''
* Alle in der FHEM-Eingabezeile eingegebenen ''attr''-, ''define''-Befehle usw. müssen zum Schluss noch per Klick auf den "Save"-Button dauerhaft in der ''fhem.cfg'' gespeichert werden, sonst sind sie nach z.B. einem Systemabsturz verloren.
* Falls in der FHEM-Weboberfläche für ihren HM-CC-TC etwas wie ''X CMDs pending'' steht, sollten Sie ihren HM-CC-TC zur Hand nehmen und für 20 Sekunden auf die OK-Taste drücken. Dadurch werden alle noch ausstehenden Befehle eingelesen.

== Auszug aus der fhem.cfg ==
Die nachfolgenden Einstellungen zum HM-CC-TC werden von FHEM <ins>weitestgehend</ins> automatisch gesetzt. Die Pfadangaben für die Log-Dateien sind system-, die Raumbenennungen benutzerabhängig. Zu ''autoReadReg''und ''expert''siehe unten. Neben dem eigentlichen Basis-Gerät (HM-CC-TC) werden in FHEM automatisch noch 3 weitere "Unter"-Geräte (Channels/Kanäle), nämlich

* ''_Weather''
* ''_Climate''
* ''_WindowRec''

definiert (durch das Anlernen des TC an FHEM; siehe unten), deren Benennung sich (jeweils mit einem vorangestellten Unterstrich "_") am Namen des Basis-Gerätes orientiert.

'''Anmerkung:'''Die in den unten gezeigten ''fhem.cfg''-Auszügen markierten <ins>Peer</ins>-Einträge tauchen erst auf, sobald man die Daten aus dem TC mit ''set HM-CC-TC-Basisname getConfig''bzw. ''autoReadReg''ausgelesen hat.

=== Hauptgerät ===
<nowiki>define <HM-CC-TC>.Heizung CUL_HM 1DA491
attr <HM-CC-TC>.Heizung actCycle 000:10
attr <HM-CC-TC>.Heizung actStatus alive
attr <HM-CC-TC>.Heizung autoReadReg 1
attr <HM-CC-TC>.Heizung devInfo 00FFFF
attr <HM-CC-TC>.Heizung expert 2_full
attr <HM-CC-TC>.Heizung firmware 2.1
attr <HM-CC-TC>.Heizung hmClass receiver
attr <HM-CC-TC>.Heizung model HM-CC-TC
attr <HM-CC-TC>.Heizung room <IhrRaum>
attr <HM-CC-TC>.Heizung serialNr JE********
attr <HM-CC-TC>.Heizung subType thermostat</nowiki>
=== Channel (Kanal) 01 _Weather ===
<nowiki>define <HM-CC-TC>.Heizung_Weather CUL_HM 1DA49101 <<<=== 01 = Kanal 1
attr <HM-CC-TC>.Heizung_Weather model HM-CC-TC
attr <HM-CC-TC>.Heizung_Weather peerIDs
attr <HM-CC-TC>.Heizung_Weather room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_Weather FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_Weather-%Y-%m.log <HM-CC-TC>.Heizung_Weather
attr FileLog_<HM-CC-TC>.Heizung_Weather logtype text
attr FileLog_<HM-CC-TC>.Heizung_Weather room CUL_HM,<IhrRaum></nowiki>
=== Channel (Kanal) 02 _Climate ===
<nowiki>define <HM-CC-TC>.Heizung_Climate CUL_HM 1DA49102 <<<=== 02 = Kanal 2
attr <HM-CC-TC>.Heizung_Climate model HM-CC-TC
attr <HM-CC-TC>.Heizung_Climate peerIDs 1AD52B01,1B7A4C01,1C4CD101,1C48EC01, <<<=== gepeerte HM-CC-VDs
attr <HM-CC-TC>.Heizung_Climate room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_Climate FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_Climate-%Y-%m.log <HM-CC-TC>.Heizung_Climate
attr FileLog_<HM-CC-TC>.Heizung_Climate logtype text
attr FileLog_<HM-CC-TC>.Heizung_Climate room CUL_HM,<IhrRaum></nowiki>
=== Channel (Kanal) 03 _WindowRec ===
<nowiki>define <HM-CC-TC>.Heizung_WindowRec CUL_HM 1DA49103 <<<=== 03 = Kanal 3
attr <HM-CC-TC>.Heizung_WindowRec model HM-CC-TC
attr <HM-CC-TC>.Heizung_WindowRec peerIDs 1CFBB001, <<<=== gepeerte HM-Sec-SCs
attr <HM-CC-TC>.Heizung_WindowRec room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_WindowRec FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_WindowRec-%Y-%m.log <HM-CC-TC>.Heizung_WindowRec
attr FileLog_<HM-CC-TC>.Heizung_WindowRec logtype text
attr FileLog_<HM-CC-TC>.Heizung_WindowRec room CUL_HM,<IhrRaum></nowiki>
== Einstellungen eines HM-CC-TC lesen, anzeigen und sichern ==
=== expert ===
Anfang Februar 2013 wurde eine Änderung bei der Anzeige der so genannten ''Readings'' (Register usw.), also der Einstellungen bzw. Eigenschaften eines HM-Devices, eingeführt. '''Alle''' Werte sieht man nur noch, wenn man am HM-CC-TC das Attribut ''expert'' auf ''2_all'' setzt. Per '''default''' (nicht in ''fhem.cfg'' gesetzt) steht dieser Wert auf ''0_off'' (nur die notwendigsten Readings/Eigenschaften werden angezeigt). Mittelweg ist der Wert ''1_on''.

Mittels

<nowiki>attr <HM-CC-TC-Name> expert 2_full</nowiki>
in der FHEM-Befehlszeile mit anschließendem <Enter> setzt man diesen Level.

Falls man mit '''Temperaturlisten''' arbeitet (siehe unten), dann kann man die komplette Liste im "Channel" (Kanal) ''<HM-CC-TC-Name>__Climate'' einsehen. Auch für diesen Kanal ist evtl. ein setzen des Attributes ''expert 2_full'' angeraten.

<ins>Anmerkung:</ins> Es gibt auch noch sogenannte "hidden datas" (versteckte interne Werte, Register oder Eigenschaften deren Namen mit einem "." beginnen). Diese sieht man nur dann, wenn auch das Attribut ''showInternalValues 1'' gesetzt ist (default: 0 bzw. nicht gesetzt).

=== autoReadReg ===
Mitte Januar 2013 wurde das neue Attribut ''autoReadReg'' eingeführt, welches auf ''0'' voreingestellt ist (kein Eintrag in der ''fhem.cfg''). Das Setzen dieses Attributes auf ''1'' bewirkt, dass <ins>beim Neustart von FHEM</ins> die Einstellungen des entsprechenden HM-Gerätes ausgelesen werden. Dies wird bei mehreren ''autoReadReg''s automatisch zeitversetzt vorgenommen, um die Funk-Kommunikation nicht unnötig zu belasten.

Mittels

<nowiki>attr <HM-CC-TC-Name> autoReadReg 1 </nowiki>
in der FHEM-Befehlszeile mit anschließendem <Enter> setzt man diesen Wert.

=== list ===
Um sich alle Eigenschaften/Readings eines Gerätes anzusehen, gibt es den Befehl ''list''.

Mittels

<nowiki>list <HM-CC-TC-Name></nowiki>
und Bestätigung mit <Enter> erhalten Sie die gewünschte Anzeige Ihres TCs <ins>incl.</ins> seiner 3 Channels. Über

<nowiki>list <HM-CC-TC-Name>_<Channel-Name></nowiki>
werden nur die Daten des angegebenen Channels angezeigt.

=== Einstellungen sichern ===
Die Durchführung von ''autoReadReg'' kann durchaus mehrere Minuten dauern. Anschließend besteht die Möglichkeit, diese per

<nowiki>get HM-CC-TC-Basisname saveConfig [/Verzeichnis/mit/Schreibrechten/]<Dateiname></nowiki>
für jedes HM-CC-TC getrennt zu sichern (für eine später notwendige Wiederherstellung). Die Sicherungsdatei wird regulär im ''modpath'' (siehe ''fhem.cfg'') abgelegt. Falls dies nicht zum Erfolg führt (es wird - ohne Fehlermeldungen bei regulärem ''verbose'' und ''loglevel'' - im ''modpath'' keine Datei angelegt), müssen Sie vor dem Dateinamen einen vollständigen Pfad mit Schreibrechten für den Benutzer, unter dem FHEM läuft, angeben.

In der <ins>Log-Datei</ins> von FHEM erscheinen danach Meldungen folgender Art

<nowiki><Datum>_<Zeit> 2: CUL_HM set <HM-CC-TC-Name> statusRequest rxt:12
<Datum>_<Zeit> 2: CUL_HM set <HM-CC-TC-Name> getConfig rxt:12</nowiki>
Hierbei kann es (im <ins>Event monitor</ins> von FHEM) zu folgenden Fehlermeldungen kommen

<nowiki><Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:RegisterRead
<Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:PeerList
<Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:StatusReq</nowiki>
Diese Meldungen können auch mehrfach pro Gerät auftreten. Dann hat das Auslesen der Einstellungen nicht geklappt und sollte nochmals durchgeführt werden. Dafür muss man FHEM aber nicht neu starten, sondern das HM-Device per

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
in der Befehlszeile von FHEM und anschließendem <Enter> (nicht "save") darauf einstellen.

Die Channels (z.B. <HM-CC-TC-Name>_Climate, _Weather, _WindowRec) eines HM-Gerätes brauchen nicht (können aber bei Bedarf) separat ausgelesen bzw. gesichert zu werden, da sie Bestandteil der Basisabfrage sind.

== Funkprobleme auffangen ==
Der wohl am häufigsten an den HM-CC-TC gesendete Befehl ist "set desired-temp", mit dem die Wunschtemperatur neu gesetzt wird.
Funktioniert dieser Befehl jedoch nicht zuverlässig, wird die Wohnung ggf. zu lange oder nicht rechtzeitig beheizt.
Der folgende Mechanismus soll die Sicherheit erhöhen, indem die Antworten des HM-CC-TC geprüft werden und ggf. das Funktelegramm erneut gesendet wird.

Um den Sollwert zum erneuten Senden des Funktelegramms verfügbar zu haben, wird ein dummy definiert:

<nowiki>define HM_TC_Solltemperatur dummy</nowiki>
Wann immer die Solltemperatur geändert wird, setzt man die neue desired-temp nicht nur auf dem HM-TC-CC (hier HM_TC genannt), sondern auch auf dem dummy. Der Befehl (z.B. in der [[Zuhause-Status|Routine zum HomeStatus]]) sieht dann so aus:

<nowiki>set HM_TC desired-temp 21;set HM_TC_Solltemperatur 21</nowiki>
Falls das ausgehende Funktelegramm verlorengeht, fehlt die Antwort "command accepted". Dies kann mit einem watchdog aufgefangen werden, der dann den Befehl an den HM-CC-TC erneut sendet:

<nowiki>define w_HM_TC watchdog HM_TC:set_desired-temp.* 00:02:30 HM_TC_Climate:CommandAccepted:.yes { \
Log 1, ">>>>>>>>> w_HM_TC desired temp - missing response.";\
fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\
}</nowiki>
Falls ein Fehler bei der Funkkommunikation auftritt, erhält man die Antwort "missing ACK" oder "NACK". Auch in diesem Fall soll das Telegramm zum Ändern der Wunschtemperatur erneut an den HM-CC-TC gesendet werden:

<nowiki>define n_HM_TC_err notify HM_TC:(MISSING.ACK.*|.*NACK.*) {\
Log 1, ">>>>>>>>> n_HM_TC desired temp - missing ack/nack.\n";\
fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\
}</nowiki>
Mit diesen beiden Helfern ist die Funkkommunikation zum HM-CC-TC sehr zuverlässig.

== Plots / Grafiken ==
=== Problem ===
Durch ''autocreate'' wird zwar ein Log angelegt, aber kein Plot (Grafische Auswertung). Dem kann man aber abhelfen (siehe unten).

=== Plots erzeugen ===
''PGM2'' ist die Standardansicht des Fhem-Web-Interfaces. Um hier Plots/Grafiken zu erzeugen einfach unter dem ''Filelog'' des Thermostaten das ''attr logtype'' auf ''temp4hum6:Plot,text'' setzen und es wird ein Plot-Link neben dem Text-Link angezeigt. Nun können Sie auf diesen Plot-Link klicken und ...

=== alternative Plots ===
Mit dem fht.gplot funktioniert die Anzeige der Ventilstellung (actuator) nicht.

Mit folgendem angepassten .gplot File wird die gemessene Temperatur und Ventilstellung angezeigt.

<nowiki>############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define <filelogname> FileLog /var/log/fhem/actuator_name-%Y.log <actuator_name>:(measured-temp|actuator).*

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 ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics

set y2label "Temperatur in C"
set ylabel "Ventil (%)"

#FileLog 4:measured:10:
#FileLog 4:actuator:50:

plot \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Temperatur in C' with lines,\
"< egrep 'actuator' <IN>"\
using 1:4 axes x1y1 title 'Ventil (%)' with lines\</nowiki>
=== Alles-drin-Plot ===
dazu nimmt man folgendes .gplot. Man/Fra beachte, dass hierfür alle Parameter nach der define-Anweisung in das Logfile geschrieben werden.

<nowiki>############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define <filelogname> FileLog /var/log/fhem/HM_CC_TC-%Y.log <HM_CC_TC-name>
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 ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics
set y2label "Temperature in C"
set ylabel "Actuator (%)"
#FileLog 4:temperature:0:
#FileLog 4:desired:0:
#FileLog 4:humidity:0:
#FileLog 4:actuator:0:int
plot \
"< awk '/temperature/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Measured temperature' with lines lw 2,\
"< awk '/desired/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Desired temperature' with steps,\
"< awk '/humidity/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Humidity (%)' with lines,\
"< awk '/actuator/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Actuator (%)' with lines\</nowiki>

== Steuerungsmodi ==
Das Wandthermostat hat 4 verschiedene Steuerungsmöglichkeiten:

* Auto (automatisch)
* Cent (Zentrale)
* Manu (manuell)
* Prog / Koffer-Symbol (Urlaubs/Party-Modus, wird hier nicht näher erörtert)

Der Steuerungsmodus wird über wiederholtes Drücken der linken Taste des HM-CC-TC ausgewählt bzw. gewechselt.

'''Hinweis:''' Durch das P'''ai'''ren des HM-CC-TC <ins>und</ins> der Stellantrieb sowie Tür-/Fensterkontakte an Fhem verlieren Sie '''nicht''' die Steuerungsmöglichkeiten. Im Gegenteil: Nur wenn auch die VDs usw. mit Fhem gep'''ai'''rt sind, haben Sie die Möglichkeit, auch diese zu überwachen. Die Steuerung '''können''' Sie dennoch allein dem HM-CC-TC überlassen.

=== Auto-Modus ===
Im Modus '''Auto''' wird die Temperaturregelung über die im TC hinterlegten Temperaturlisten vorgenommen. Das Thermostat arbeitet also selbständig, somit unabhängig von einer Zentrale / FHEM. Nur in diesem Modus werden die evtl. per FHEM an das TC übermittelten "templist" abgearbeitet. Über das Senden von angepassten Temperatur-Listen kann eine indirekte Steuerung per FHEM erfolgen. '''Jederzeit''' kann zudem die Raumtemperatur über das Drehrad des Wandthermostaten oder die FHEM-Web-Oberfläche verändert werden. Diese ''Übersteuerung'' der Temperaturliste gilt bis zur nächsten Temperaturänderung nach der vorgenannten Liste.

=== Cent-Modus ===
Im Modus '''Cent''' steuert eine HomeMatic-Zentrale (CCU) oder eben ein FHEM-Server mit z.B. [[HMLAN Konfigurator]] zu den in der FHEM-Config hinterlegten Zeiten und mit den dort festgelegten Temperaturen. Fällt also die HM-Zentrale aus, erfolgt keine Steuerung der Thermostaten bzw. Heizungsventile mehr.

<ins>Anmerkung</ins>: Der Modus ''cent'' erscheint nur dann im Display des HM-CC-TC, wenn er an eine Zentrale bzw. das [[CUL]] angelernt (gepairt) wurde.

=== Manu-Modus ===
Der Modus '''Manu''' übersteuert die im TC hinterlegten Temperaturlisten und die evtl. von der HM-Zentrale / dem FHEM <ins>vor Umstellung auf ''Manu''</ins> gesendeten Einstellungen. Es wird also bis zur nächsten Modusumstellung bzw. manuellen Temperaturverstellung der per Einstellrad gesetzte Temperaturwert gefahren.

Aber auch in diesem Modus kann man die ''desired-temperature'' per FHEM verstellen. Der dadurch eingestellte Wert gilt ab sofort als der neue im ''Manu-Modus'' zu haltende Wert.

=== Tastensperre ===

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

set <HM-CC-TC> regSet btnLock on

Rückgängig machen geht per:

set <HM-CC-TC> regSet btnLock off

=== Auslesen des eingestellten Steuerungsmodus ===
Der eingestellte Steuerungsmodus erscheint normalerweise in den ''Readings'' des HM-CC-TC unter ''controlMode''. Zusätzlich haben Sie die Möglichkeit, diesen Modus auch in der FHEM-Weboberfläche ''everything'' => Abschnitt ''thermostat'' zu sehen, '''wenn''' Sie für den HM-CC-TC das folgende Attribut setzen:

<nowiki>attr <HM-CC-TC-Name> stateFormat T:measured-temp, H:humidity, VD:actuator, controlMode</nowiki>
Erscheint dort selbst nach einem

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
kein "Reading" ''controlMode'' oder keine Angabe des aktuell eingestellten Modus bzw. nur das Wort "controlMode", dann setzen Sie ihren HM-CC-TC von Hand in einen anderen Kontrollmodus und machen einen Browser-Refresh. Klappt dies nicht, geben Sie bitte erneut den Befehl

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
ein. Halten Sie anschließend die Taste <OK> am HM-CC-TC für 5 Sekunden gedrückt (oder warten ca. 5 Minuten) und machen in der FHEM-Weboberfläche einen Browser-Refresh (FF => <F5>). Jetzt sollte der manuell eingestellte Kontrollmodus erscheinen (ggfls. muss dieser Vorgang einmal wiederholt werden). Jetzt können Sie wieder den gewünschten Modus einstellen, erneut ein

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
absetzen und nach erneutem Drücken der <OK>-Taste für 5 Sekunden mit nachfolgendem Browser-Refresh sollte alles richtig angezeigt werden.

Dies setzt natürlich voraus, dass der HM-CC-TC richtig gepairt ist.

== Temperaturlisten ==
Die Temperaturlisten des TC werden identisch denen des RT bearbeitet und verwaltet, siehe [[HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Temperaturprofile|HM-CC-RT-DN]].
Beim TC ist der Kanal 4 (_Climate) für die Temperaturlisten zuständig (nicht _Clima wie beim RT!)

== Batteriealarme des HM-CC-VD in Verbindung mit HM-CC-TC ==
1. bei U-Bat. < 2,4 V erscheint im Display des VD und des TC das Batteriesymbol mit '''battery: low''' in den Readings und Events!

2. bei U-Bat. < 2,3 V erscheint im Display des VD zusätzlich '''F4''' mit '''battery: critical''' in den Readings und Events!

Es wird dringend geraten, die Batterien bei battery: low zu tauschen!

== Log-Auszug ==
HM-CC-TC sendet alle 2 Minuten folgenden Statusbericht:

<nowiki>Datum-Zeit <Device Name> T: 17.3 H: 66 
Datum-Zeit <Device Name> measured-temp: 17.3 
Datum-Zeit <Device Name> temperature: 17.3 
Datum-Zeit <Device Name> humidity: 66 
Datum-Zeit <Device Name> actuator: 96 % </nowiki>
Bei Status-Änderungen sendet HM-CC-TC auch entsprechende Meldungen, z.b.:

<nowiki>Datum-Zeit <Device Name> desired-temp: 15.5 </nowiki>

= Probleme =

== Verstellen der Solltemperatur am HM-CC-TC per Drehrad ==

'''Symptom:''' Beim Verstellen der Solltemperatur per seitlichem Drehrad wurde die aktuelle Solltemperatur - '''egal ob''' man hoch oder runter drehte - immer nur in 0,5 °C Schritten '''runter''' gestellt, bis schließlich die Mindesttemperatur von 6,0 °C erreicht war. Weitere Änderungen waren nicht möglich

'''Abhilfe:''' Letztlich half nur das kurzzeitige Entfernen einer Batterie. Das danach für einige Zeit erscheinende Batteriesymbol zeigte den kleinstmöglichen guten Zustand an, in FHEM wurde das ''Reading'' des Batteriezustandes mit ''ok'' ausgegeben (wie in den Logs aber vorher auch). '''Letztlich half aber nur''' das Einsetzen neuer Batterien, denn die o.a. Störung trat nach ca. 2 Stunden erneut auf. Die "alten" Batterien (die, die dem HM-CC-TC ab Werk beilagen) hatten somit eine Nutzungsdauer von knapp 11 Monaten, waren aber auch in einem HM-CC-TC, der mit 4 Stck. HM-Sec-SC (mussten sehr oft "Meldung machen") und 4 Stck. HM-CC-VD gepeert war. ''Ohne Last'' zeigten die beiden alten AA-Batterien eine Spannung von jeweils 1,29 V an.

'''Hinweis:''' Die unter ''Abhilfe'' beschriebene Lösung war leider nur von kurzer Dauer. Bereits kurz danach zeigte der HM-CC-TC die gleichen Ausfallerscheinungen. Bei ELV gibt es das Bauteil für das Drehrad (Inkrementalgeber) als [http://www.elv.de/inkrementalgeber-fuer-fs20-str-fht-8-und-homematic-hm-cc-tc.html Ersatzteil]. Sobald dieses geliefert und ein Reparaturversuch unternommen wurde, wird an dieser Stelle weiter berichtet.

== HM-CC-TC misst zu hohe/niedrige Luftfeuchte-Werte ==

'''Symptom:''' In den Fhem-Logs und demzufolge auch in den Plots/Grafiken eines seit über 18 Monaten im Einsatz befindlichen HM-CC-TC wurden viel zu hohe (einzelne Spitzenwerte von 98 oder 99 %) bzw. ständig zu niedrige (um die 20 oder sogar vereinzelt nur 2 %) Werte für die relative Luftfeuchte gemessen (im direkten Vergleich zu anderen HM-CC-TCs). Die anderen Werte (Temperatur, Actuator) waren aber schlüssig.

'''Abhilfe:''' Batteriewechsel. Die alten Batterien hatten (unbelastet) noch knapp über 1 V Spannung.

'''Hinweis:''' Eine Batteriewarnung des Gerätes gab es nicht. Im Display war das entsprechende Symbol noch auf 1 Balken.

= Firmware =
Aktuelle Firmware-Version: 2.1

= Links =
Anleitung [http://www.elv-downloads.de/service/manuals/76787_76175_HM_Wandthermostat_UM.pdf PDF]

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

HM-CFG-LAN LAN Konfigurations-Adapter

2015-01-28T14:30:05Z

Rohan: /* HMUSB */ Hinweis auf OTA-Firmware-Updatemöglichkeit eingearbeitet

[[Datei:HM-CFG-LAN.jpg|thumb|right|HomeMatic LAN Konfigurations-Adapter]]
== Vorbemerkungen ==
Der HomeMatic Konfigurations-Adapter LAN ([http://www.eq-3.de/produkt-detail-zentralen-und-gateways/items/hm-cfg-lan.html HM-CFG-LAN]), kurz HMLAN, ist ein Schnittstellengerät (IO) ohne wesentliche Intelligenz. Die Aufgabe ist, ein Interface von der Zentrale zu den Geräten bereitzustellen. Ein HMLAN selbst steuert keine Geräte, es überträgt nur Nachrichten in beide Richtungen.

=== Alternativen ===
Alternativen zu einem HMLAN sind [[HM-CFG-USB USB Konfigurations-Adapter]], [[CUN]], [[CUNO]] und [[CUL]].

==== HMUSB ====
Ein HMUSB hat nahezu identische Eigenschaften wie ein HMLAN. Der wesentliche Unterschied ist die Anbindung über USB anstatt Ethernet. Es hat sich erwiesen, dass USB eine bessere Latenz hat als LAN - also eine kürzere Verzögerung. Damit hat ein HMUSB leichte Vorteile zu HMLAN, was aber in den bei Weitem meisten Fällen durch die interne Timing Kalkulation abgefangen wird. Zudem können über den HMUSB (ab Version 2) auch Firmware-Updates OTA (over-the-air, also per Funkverbindung) auf entsprechende HM-Geräte (z.B. den HM-CC-RT-DN) durchgeführt werden.

Dafür bietet der HMLAN mit seinem Netzwerkanschluss Vorteile bei der Platzierung.

==== CUL/CUN(O) ====
* Die Devices liefern keine eigenen Zeitstempel, wodurch eine Timingkorrektur durch FHEM nicht möglich ist. Je nach Systemgeschwindigkeit kann dies zu Problemen, Nachrichten wiederholen und ggf. auch Nachrichtenverlust führen
* Da USB kurze Reaktionszeiten und geringe Timingschwankungen hat ist der Einsatz von [[CUL]] und [[CUNO]] mit HM möglich. Die Timingschwankungen der Ethernet-schnittstelle hingegen können in FHEM nicht ausgeglichen werden. Daher kann der Einsatz der [[CUNO]] über Ethernet '''nicht empfohlen''' werden.
* [[AES Encryption]] wird nicht unterstützt
* lazyConfig (ein Übertragungsmode) wird nicht unterstützt

=== Funktionen ===
==== AES ====
siehe [[AES Encryption]].

==== Übertragungsmodus ====
Es werden alle HM-Modi unterstützt. Diese sind Always, Burst, Wakeup und Config. Weiter gibt es lazyConfig und conditionalBurst. Siehe [[HomeMatic]] für Details.

==== KeepAlive ====
Das HMLAN baut eine Verbindung zur Zentrale über das LAN Interface auf. HMLAN erwartet alle 30 Sekunden eine keep-alive Nachricht von der Zentrale. Sollte diese ausbleiben, baut HMLAN die LAN-Verbindung ab. Das führt zu einem Disconnect, der in State gemeldet wird. Die Verbindung wird automatisch wieder aufgebaut.
FHEM sendet den keep-alive alle 25 Sekunden, was einen 5 Sekunden Puffer einräumt. In Internals '''msgKeepAlive''' kann man sehen, wie hoch die maximale Verzögerung der Zentrale beim Senden war und wie viel Puffer (in Sekunden) noch verfügbar war.
Die Wiederholrate von 25 Sekunden des keep-alive kann mit dem Attribut '''wdTimer''' reduziert werden, was den Puffer erhöhen. Es wird jedoch dringend geraten, im Problemfall die Ursache der Verzögerung zu suchen und zu eliminieren.

==== Nachrichtenübertragung - Performance ====
* Mit Internal '''msgParseDly''' kann man ablesen, welche Verzögerung eine Nachricht vom Empfang im HMLAN bis zur Verarbeitung in der Zentrale hat.
* HMLAN hält sich an den Funkstandard, der einem Sender eine maximale Sendezeit je Stunde erlaubt. Wird dieser Wert überschritten, stellt HMLAN das Senden ein. Empfangen wird weiter. Ist eine Kapazität von 90% erreicht, wird im Reading '''cond''' '''Warning-HighLoad''' gemeldet. Bei cond '''ERROR-Overload''' wird das Senden eingestellt ist.

==== Loggen/Mitschneiden ====
Es stehen die üblichen Funktionen des Attribute '''verbose''' zu Verfügung. Darüber hinaus gibt es die Attribute hmProtocolEvents und logIDs. Siehe auch [[Homematic Nachrichten sniffen|Homematic Nachrichten sniffen]].

== Vorbereitung ==
[[Datei:HMLAN_CONFIG_IP_AES.png|300px|thumb|right|HomeMatic Lan-Interface Configurator]][[Datei:HMLAN_CONFIG_AES.png|300px|thumb|right|HomeMatic Konfigurator]]
Bevor man den HMLAN mit Fhem nutzen kann, müssen noch Einstellungen vorgenommen werden. Dazu braucht man Software die bei [http://www.eq-3.de/software.html HomeMatic] in der Version 1.512 (Stand 19. Dezember 2013) herunter zu laden ist und nach der Installation mit der Verknüpfung "HomeMatic-Lan-Interface konfigurieren" oder "HomeMatic-Komponenten konfigurieren" gestartet wird und unter Windows läuft. Für andere Betriebssystem (siehe Anhang im Beitrag {{Link2Forum|Topic=11506|Message=67417|LinkText=Anleitung für OS X}}) braucht man eine Windows-Emulation. Dem HMLAN liegen zwei Konfigurationsprogramme bei, bitte darauf achten, das richtige zu verwenden. Wenn das Konfigurationsprogramm den HMLAN-Konfigurator nicht findet, sollten alle nicht benutzten Netzwerkinterfaces vorübergehend deaktiviert werden, siehe {{Link2Forum|Topic=10933|Message=62960|LinkText=Beitrag im Fhem Forum}} und [[HM-CFG-LAN_LAN_Konfigurations-Adapter#Bekannte_Probleme|bekannte Probleme]].

=== Firmware ===
Die aktuelle Firmware Version des HMLAN ist 0.964 (Stand November 2014). Ein Update ist unter ''"Update Firmware"'' mit der ''"HomeMatic Lan-Interface Configurator"'' Software möglich.

=== IP Adresse ===
Der HMLAN Konfigurator ist ähnlich wie der CUN(O) ein Netzwerkgerät. Er beherrscht DHCP und bezieht bei einem im Netzwerk erreichbaren DHCP Servers von diesem eine IP-Adresse. Da Fhem zwecks Kommunikation die IP-Adresse wissen muss, ist es sinnvoll, dem HMLAN eine statische Adresse zuzuweisen.
* mit der auf der CD mitgelieferten ''"HomeMatic Lan-Interface Configurator"'' Software unter ''"Change IP Settings"'' oder
* im DHCP-Server eine feste IP-Adresse zuzuweisen (sofern dies vom gegeben DHCP Server als Konfigurationsoption unterstützt wird).

=== AES Encryptet LAN Communication ===
Wichtig ist, dass vor Verwendung die "AES Encryptet LAN Communication" abgeschaltet wird, da diese FHEM nicht unterstützt. Dies ist unter ''"Change IP Settings"'' der ''"HomeMatic Lan-Interface Configurator"'' Software möglich. AES auf dem LAN ist zu unterscheiden von HMLAN auf der Funktschnittstelle. siehe [[AES Encryption]].

== Einbindung in FHEM ==
Der HMLAN-Konfigurator muss in FHEM [[Konfiguration|konfiguriert]] werden. Das erfolgt mit diesen Befehlen:
:<code>define HMLAN1 HMLAN <IP Adresse>:1000</code>
:<code>attr HMLAN1 hmId 123ABC</code>
Der Name (im obigen Beispiel ''HMLAN1'') kann frei vergeben werden. Standard IP-Port des HMLAN-Konfigurators ist 1000.

HMLAN kennt mehrere Attribute ([http://fhem.de/commandref.html#HMLAN commandref]).
Wichtig ist es, die '''hmId''' zu vergeben. Diese ist ein 3-Byte hexadezimal-Wert, somit eine 6-stellige Zeichenfolge in '''Großbuchstaben'''. 000000 und FFFFFF sind ungültig.
Wenn HM-Geräte mit der Zentrale gepairt werden, wird ihnen diese hmId eingetragen. Wechselt man die hmId müssen '''alle''' damit gepairten Geräte neu gepairt werden.

Die Adresse wird in Grossbuchstaben eingegeben, siehe [[HMLAN_Konfigurator#Bekannte_Probleme|"Bekannte Probleme"]].

Ein '''gleichzeitiger''' Zugriff von Fhem und der HomeMatic-Software auf den HMLAN-Konfigurator ist nicht möglich, da letzterer nur eine Verbindung zulässt. Wollen Sie temporär z.B. mit der Windows-Software von HomeMatic zugreifen, ist Fhem zu deaktivieren.
Sinnvoll ist es, die hmId mit der der PC-Software gleichzusetzen. Dann kann man von beiden Zentralen alternativ zugreifen ohne pairen zu müssen.

=== Nutzung mehrere IOs ===
==== Empfangen ====
Man kann an einem FHEM mehrere IOs (HMLAN/USB, CUL/CUNO) betreiben. Generell empfangen alle IOs von allen Geräten in ihrem Empfangsbereich - unabhängig von der hmId.

==== Senden ====
An ein Gerät wird nur über das IO gesendet, das in Internals->IODev angezeigt wird. Nutzt man mehrere IOs sollte im HM Device das Attribut IODev auf das gewünschte IO setzen. Ansonsten sucht FHEM zufällig ein IO aus.

==== hmId bei mehreren IOs ====
Man kann allen IOs die gleiche HMId setzen. Das erlaubt die wahlfreie Umschaltung des Sende-IOs für das Device. Sollte man unterschiedliche hmIds wählen simuliert dies mehrere Zentralen. Das Device, an das man sendet, muss über ein IO angesprochen werden, mit einer hmId auf die das Device gepairt ist.

=== Attribute ===
* '''hmId''': Adresse, die das IO auf der Funkstrecke nutzt. Es ist ein 3-byte hexwert (6 Zeichen) in Großbuchstaben.
* '''hmkey, hmkey2..5''': bis zu 5 AES keys, die auf der Funkstrecke genutzt werden. Siehe [[AES Encryption]]
* '''hmLanQlen''' legt fest, wie viele Nachrichten parallel gesendet werden dürfen, also auf wie viele Antworten die Zentrale parallel warten darf. Ein Wert von 1 ist max defensiv, erzeugt aber eine höhere Verzögerung. Wählt man einen höheren Wert kann es zu Nachrichten-Wiederholunge kommen.
* '''hmProtocolEvents''': alle Nachrichten werden dekodiert ausgegeben. Diese Einstellung benötigt einige Performance insbesondere bei höheren Level. Man sollte es vorsichtig nutzen.
* '''logIDs''': zeichnet Rohmessages auf und bietet die genaueste Methode bei der Fehlersuche. Da Nachrichten undekodiert ausgegeben werden ist es im Wesentlichen für Spezialisten von Bedeutung. Man gibt eine Komma getrennte Liste von IDs an, die geloggt werden sollen. Mit '''all''' werden alle IDs aufgezeichnet. '''sys''' zeichnet zusätzlich Systemmessages auf. '''sys,all''' somit alles.
* '''respTime''': Antwortzeit des HMLAN auf ein keep-alive kann hier eingestellt werden. Normalerweise sollte das HMLAN in einer Sekunde der Zentrale antworten. Sollte dies nicht passieren, wird die Message wiederholt. Der Wert sollte nur in Ausnahmefällen verändert werden.

=== Readings ===
* '''Xmit-Events''': Anzahl der Ereignisse
* '''cond''': aktueller Zustand des IO.
** ok
** Warning-HighLoad: 90% der 1h sendekapazität sind erreicht
** ERROR-Overload: 100% der sendekapazität sind erreicht, '''das IO sendet nicht mehr'''
** timeout
** disconnected: die Verbindung FHEM /IO ist unterbrochen
** Overload-released: das IO ist aus ERROR-Overload zurück im Sendebetrieb
** init: Das IO wurde neu initialisiert.
* '''prot_ERROR-Overload''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_Warning-HighLoad''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_disconnected''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_init''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_ok''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_timeout''': Anzahl des Events, Zeitstempel des letzten Auftretens

=== Internals ===
* '''XmitOpen''': 1 = HMLAN ist sende bereit
* '''assignedIDs''': HMIDs der HM Devices, die über dieses IO bedient werden
* '''assignedIDsCnt''': Anzahl der zugewiesenen HMIds von FHEM
* '''assignedIDsReport''': Anzahl der HMIds, die das HMLAN angibt zu bedienen. Die Zahl sollte identisch sein mit assignedIDsCnt
* '''msgKeepAlive''': dlyMax: maximale Verzögerung, die ein keep-alive hatte. bufferMin: der minimale Zeitpuffer, der übrig blieb, bis das keep-alive zu spät gekommen wäre. Der Puffer sollte 2 oder größer sein, sonst könnte man gelegentlich disconnects bekommen.
* '''msgLoadEst''': Funkbelastung des HMLAN. Der Wert wird über 1 Stunde akkumuliert. Sollten 100% erreicht sein, wird das HMLAN den Sendebetrieb einstellen. Der Wert ist eine Hochrechnung in FHEM. Es ist möglich, dass das HMLAN mehr belastet ist. Die 10 min werte zeigen die Belastung in den letzten 10min Perioden an.
* '''msgParseDly''': Verzögerung der Message Verarbeitung vom Empfang im IO bis zur Verarbeitung in FHEM. Eine Verzögerung kann durch Prozesse an LAN, durch FHEM Prozesse oder sonstige Prozesse/Applikationen der CPU hervorgerufen werden.

== Pairen von Geräten ==
Jedes HM Geräte muss vor Verwendung mit der HM-Zentrale gepairt werden. Dabei wird die hmId des gewählten IOs in das Device programmiert. Ändert man die hmId des IO, mit man das Device anspricht, muss man das Device neu pairen.
Alle Geräte haben eine eigene Seriennummer, die nicht änderbar ist. Details zum Pairen auf der Seite [[HomeMatic Devices pairen]].

== Bekannte Probleme ==
Selten lehnt der HMLAN-Konfigurator ohne erkennbaren Grund nach monatelangem störungsfreiem Betrieb die Verbindung ab:

Opening HMLAN1 device 192.168.168.60:1000
192.168.168.60:1000 connection refused
Der HMLAN-Konfigurator kann aber über die mitgelieferte Konfigurationssoftware problemlos erreicht werden. Der Zustand lässt sich auch durch einen Reboot des HMLAN-Konfigurators (oder Fhem) nicht beheben, wohl aber durch eine Aktualisierung der Firmware des HMLAN-Konfigurators, selbst wenn die installierte Version aktuell ist.

Wenn das Konfigurationsprogramm Probleme hat, den HM-CFG-LAN LAN Konfigurations-Adapter zu finden, sollten alle nicht benutzten Netzwerkinterfaces vorübergehend deaktiviert werden. Vereinzelt gibt es Hinweise darauf, dass es unter Windows 7 eventuell nicht reicht, die Netzwerkverbindungen im "Netzwerk- und Freigabecenter" zu deaktivieren, sondern ein Deaktivierung der Netzwerkadapter im Gerätemanager erforderlich ist.

== Verbesserung der Antennenleistung ==

Die Sende- und Empfangsleistung kann man verbessern. Wie, das finden sie [[Trick_der_Woche#HM_LAN_Konfig-Adapter_Antenne_verbessern|hier]].

== Wechsel von CUL zu HMLAN ==
Sollten Sie ein [[CUL]] als IO für Homematic-Geräte eingesetzt haben und jetzt einen Wechsel auf den HMLAN Konfigurator planen, hält sich der Aufwand in Grenzen:

* deaktivieren Sie das CUL in der ''fhem.cfg''.
* konfigurieren Sie den HMLAN Konfigurator '''von Hand'''
* Ändern sie das Attribut IODev aller HM-Devices vom Namen der CUL auf den Namen des HMLAN
* sollte sie das Attribut IODev nicht nutzen (nicht empfohlen) achten sie darauf, dass im fhem.cfg das IO vor allen HM-devices definiert wird. Eine automatischen Zuweisung des IO zu den Devices ist sonst nicht möglich.
** der HMLAN '''muss''' die gleiche ''hmId'' wie das bisherige CUL erhalten. Ansonsten müssen alle Geräte neu gepairt / angelernt werden.
** AES muss im HMLAN abgeschaltet werden.
* verbinden Sie den HMLAN Konfigurator mit ihrem Netzwerk und ziehen das CUL aus der USB-Buchse.
* geben Sie in der FHEM-Befehlszeile ''shutdown restart'' gefolgt von <Enter> (nicht "save") ein (evtl. reicht auch ein ''rereadcfg'').
* kontrollieren Sie im Event-Monitor und in den HM-Device-Logs von Fhem die Kommunikation.

Bitte beachten: Falls dem CUL keine explizite hmId per Attribut zugewiesen wurde, wird diese ID aus "F1<FHT-ID>" zusammengebaut. Die hmId muss auf dem HMLAN explizit gesetzt werden.

== Links ==
* [http://www.eq-3.de/software.html Software] für den Konfigurationsadapter von der eQ-3 Site

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

HM-CFG-LAN LAN Konfigurations-Adapter

2015-01-28T14:22:09Z

Rohan: /* Bekannte Probleme */ Link auf Tipp der Woche zur Verbesserung der Antenne eingearbeitet

[[Datei:HM-CFG-LAN.jpg|thumb|right|HomeMatic LAN Konfigurations-Adapter]]
== Vorbemerkungen ==
Der HomeMatic Konfigurations-Adapter LAN ([http://www.eq-3.de/produkt-detail-zentralen-und-gateways/items/hm-cfg-lan.html HM-CFG-LAN]), kurz HMLAN, ist ein Schnittstellengerät (IO) ohne wesentliche Intelligenz. Die Aufgabe ist, ein Interface von der Zentrale zu den Geräten bereitzustellen. Ein HMLAN selbst steuert keine Geräte, es überträgt nur Nachrichten in beide Richtungen.

=== Alternativen ===
Alternativen zu einem HMLAN sind [[HM-CFG-USB USB Konfigurations-Adapter]], [[CUN]], [[CUNO]] und [[CUL]].

==== HMUSB ====
Ein HMUSB hat nahezu identische Eigenschaften wie ein HMLAN. Der wesentliche Unterschied ist die Anbindung über USB anstatt Ethernet. Es hat sich erwiesen, dass USB eine bessere Latenz hat als LAN - also eine kürzere Verzögerung. Damit hat ein HMUSB leichte Vorteile zu HMLAN, was aber in den bei Weitem meisten Fällen durch die interne Timing Kalkulation abgefangen wird.

Dafür bietet der HMLAN mit seinem Netzwerkanschluss Vorteile bei der Platzierung.

==== CUL/CUN(O) ====
* Die Devices liefern keine eigenen Zeitstempel, wodurch eine Timingkorrektur durch FHEM nicht möglich ist. Je nach Systemgeschwindigkeit kann dies zu Problemen, Nachrichten wiederholen und ggf. auch Nachrichtenverlust führen
* Da USB kurze Reaktionszeiten und geringe Timingschwankungen hat ist der Einsatz von [[CUL]] und [[CUNO]] mit HM möglich. Die Timingschwankungen der Ethernet-schnittstelle hingegen können in FHEM nicht ausgeglichen werden. Daher kann der Einsatz der [[CUNO]] über Ethernet '''nicht empfohlen''' werden.
* [[AES Encryption]] wird nicht unterstützt
* lazyConfig (ein Übertragungsmode) wird nicht unterstützt

=== Funktionen ===
==== AES ====
siehe [[AES Encryption]].

==== Übertragungsmodus ====
Es werden alle HM-Modi unterstützt. Diese sind Always, Burst, Wakeup und Config. Weiter gibt es lazyConfig und conditionalBurst. Siehe [[HomeMatic]] für Details.

==== KeepAlive ====
Das HMLAN baut eine Verbindung zur Zentrale über das LAN Interface auf. HMLAN erwartet alle 30 Sekunden eine keep-alive Nachricht von der Zentrale. Sollte diese ausbleiben, baut HMLAN die LAN-Verbindung ab. Das führt zu einem Disconnect, der in State gemeldet wird. Die Verbindung wird automatisch wieder aufgebaut.
FHEM sendet den keep-alive alle 25 Sekunden, was einen 5 Sekunden Puffer einräumt. In Internals '''msgKeepAlive''' kann man sehen, wie hoch die maximale Verzögerung der Zentrale beim Senden war und wie viel Puffer (in Sekunden) noch verfügbar war.
Die Wiederholrate von 25 Sekunden des keep-alive kann mit dem Attribut '''wdTimer''' reduziert werden, was den Puffer erhöhen. Es wird jedoch dringend geraten, im Problemfall die Ursache der Verzögerung zu suchen und zu eliminieren.

==== Nachrichtenübertragung - Performance ====
* Mit Internal '''msgParseDly''' kann man ablesen, welche Verzögerung eine Nachricht vom Empfang im HMLAN bis zur Verarbeitung in der Zentrale hat.
* HMLAN hält sich an den Funkstandard, der einem Sender eine maximale Sendezeit je Stunde erlaubt. Wird dieser Wert überschritten, stellt HMLAN das Senden ein. Empfangen wird weiter. Ist eine Kapazität von 90% erreicht, wird im Reading '''cond''' '''Warning-HighLoad''' gemeldet. Bei cond '''ERROR-Overload''' wird das Senden eingestellt ist.

==== Loggen/Mitschneiden ====
Es stehen die üblichen Funktionen des Attribute '''verbose''' zu Verfügung. Darüber hinaus gibt es die Attribute hmProtocolEvents und logIDs. Siehe auch [[Homematic Nachrichten sniffen|Homematic Nachrichten sniffen]].

== Vorbereitung ==
[[Datei:HMLAN_CONFIG_IP_AES.png|300px|thumb|right|HomeMatic Lan-Interface Configurator]][[Datei:HMLAN_CONFIG_AES.png|300px|thumb|right|HomeMatic Konfigurator]]
Bevor man den HMLAN mit Fhem nutzen kann, müssen noch Einstellungen vorgenommen werden. Dazu braucht man Software die bei [http://www.eq-3.de/software.html HomeMatic] in der Version 1.512 (Stand 19. Dezember 2013) herunter zu laden ist und nach der Installation mit der Verknüpfung "HomeMatic-Lan-Interface konfigurieren" oder "HomeMatic-Komponenten konfigurieren" gestartet wird und unter Windows läuft. Für andere Betriebssystem (siehe Anhang im Beitrag {{Link2Forum|Topic=11506|Message=67417|LinkText=Anleitung für OS X}}) braucht man eine Windows-Emulation. Dem HMLAN liegen zwei Konfigurationsprogramme bei, bitte darauf achten, das richtige zu verwenden. Wenn das Konfigurationsprogramm den HMLAN-Konfigurator nicht findet, sollten alle nicht benutzten Netzwerkinterfaces vorübergehend deaktiviert werden, siehe {{Link2Forum|Topic=10933|Message=62960|LinkText=Beitrag im Fhem Forum}} und [[HM-CFG-LAN_LAN_Konfigurations-Adapter#Bekannte_Probleme|bekannte Probleme]].

=== Firmware ===
Die aktuelle Firmware Version des HMLAN ist 0.964 (Stand November 2014). Ein Update ist unter ''"Update Firmware"'' mit der ''"HomeMatic Lan-Interface Configurator"'' Software möglich.

=== IP Adresse ===
Der HMLAN Konfigurator ist ähnlich wie der CUN(O) ein Netzwerkgerät. Er beherrscht DHCP und bezieht bei einem im Netzwerk erreichbaren DHCP Servers von diesem eine IP-Adresse. Da Fhem zwecks Kommunikation die IP-Adresse wissen muss, ist es sinnvoll, dem HMLAN eine statische Adresse zuzuweisen.
* mit der auf der CD mitgelieferten ''"HomeMatic Lan-Interface Configurator"'' Software unter ''"Change IP Settings"'' oder
* im DHCP-Server eine feste IP-Adresse zuzuweisen (sofern dies vom gegeben DHCP Server als Konfigurationsoption unterstützt wird).

=== AES Encryptet LAN Communication ===
Wichtig ist, dass vor Verwendung die "AES Encryptet LAN Communication" abgeschaltet wird, da diese FHEM nicht unterstützt. Dies ist unter ''"Change IP Settings"'' der ''"HomeMatic Lan-Interface Configurator"'' Software möglich. AES auf dem LAN ist zu unterscheiden von HMLAN auf der Funktschnittstelle. siehe [[AES Encryption]].

== Einbindung in FHEM ==
Der HMLAN-Konfigurator muss in FHEM [[Konfiguration|konfiguriert]] werden. Das erfolgt mit diesen Befehlen:
:<code>define HMLAN1 HMLAN <IP Adresse>:1000</code>
:<code>attr HMLAN1 hmId 123ABC</code>
Der Name (im obigen Beispiel ''HMLAN1'') kann frei vergeben werden. Standard IP-Port des HMLAN-Konfigurators ist 1000.

HMLAN kennt mehrere Attribute ([http://fhem.de/commandref.html#HMLAN commandref]).
Wichtig ist es, die '''hmId''' zu vergeben. Diese ist ein 3-Byte hexadezimal-Wert, somit eine 6-stellige Zeichenfolge in '''Großbuchstaben'''. 000000 und FFFFFF sind ungültig.
Wenn HM-Geräte mit der Zentrale gepairt werden, wird ihnen diese hmId eingetragen. Wechselt man die hmId müssen '''alle''' damit gepairten Geräte neu gepairt werden.

Die Adresse wird in Grossbuchstaben eingegeben, siehe [[HMLAN_Konfigurator#Bekannte_Probleme|"Bekannte Probleme"]].

Ein '''gleichzeitiger''' Zugriff von Fhem und der HomeMatic-Software auf den HMLAN-Konfigurator ist nicht möglich, da letzterer nur eine Verbindung zulässt. Wollen Sie temporär z.B. mit der Windows-Software von HomeMatic zugreifen, ist Fhem zu deaktivieren.
Sinnvoll ist es, die hmId mit der der PC-Software gleichzusetzen. Dann kann man von beiden Zentralen alternativ zugreifen ohne pairen zu müssen.

=== Nutzung mehrere IOs ===
==== Empfangen ====
Man kann an einem FHEM mehrere IOs (HMLAN/USB, CUL/CUNO) betreiben. Generell empfangen alle IOs von allen Geräten in ihrem Empfangsbereich - unabhängig von der hmId.

==== Senden ====
An ein Gerät wird nur über das IO gesendet, das in Internals->IODev angezeigt wird. Nutzt man mehrere IOs sollte im HM Device das Attribut IODev auf das gewünschte IO setzen. Ansonsten sucht FHEM zufällig ein IO aus.

==== hmId bei mehreren IOs ====
Man kann allen IOs die gleiche HMId setzen. Das erlaubt die wahlfreie Umschaltung des Sende-IOs für das Device. Sollte man unterschiedliche hmIds wählen simuliert dies mehrere Zentralen. Das Device, an das man sendet, muss über ein IO angesprochen werden, mit einer hmId auf die das Device gepairt ist.

=== Attribute ===
* '''hmId''': Adresse, die das IO auf der Funkstrecke nutzt. Es ist ein 3-byte hexwert (6 Zeichen) in Großbuchstaben.
* '''hmkey, hmkey2..5''': bis zu 5 AES keys, die auf der Funkstrecke genutzt werden. Siehe [[AES Encryption]]
* '''hmLanQlen''' legt fest, wie viele Nachrichten parallel gesendet werden dürfen, also auf wie viele Antworten die Zentrale parallel warten darf. Ein Wert von 1 ist max defensiv, erzeugt aber eine höhere Verzögerung. Wählt man einen höheren Wert kann es zu Nachrichten-Wiederholunge kommen.
* '''hmProtocolEvents''': alle Nachrichten werden dekodiert ausgegeben. Diese Einstellung benötigt einige Performance insbesondere bei höheren Level. Man sollte es vorsichtig nutzen.
* '''logIDs''': zeichnet Rohmessages auf und bietet die genaueste Methode bei der Fehlersuche. Da Nachrichten undekodiert ausgegeben werden ist es im Wesentlichen für Spezialisten von Bedeutung. Man gibt eine Komma getrennte Liste von IDs an, die geloggt werden sollen. Mit '''all''' werden alle IDs aufgezeichnet. '''sys''' zeichnet zusätzlich Systemmessages auf. '''sys,all''' somit alles.
* '''respTime''': Antwortzeit des HMLAN auf ein keep-alive kann hier eingestellt werden. Normalerweise sollte das HMLAN in einer Sekunde der Zentrale antworten. Sollte dies nicht passieren, wird die Message wiederholt. Der Wert sollte nur in Ausnahmefällen verändert werden.

=== Readings ===
* '''Xmit-Events''': Anzahl der Ereignisse
* '''cond''': aktueller Zustand des IO.
** ok
** Warning-HighLoad: 90% der 1h sendekapazität sind erreicht
** ERROR-Overload: 100% der sendekapazität sind erreicht, '''das IO sendet nicht mehr'''
** timeout
** disconnected: die Verbindung FHEM /IO ist unterbrochen
** Overload-released: das IO ist aus ERROR-Overload zurück im Sendebetrieb
** init: Das IO wurde neu initialisiert.
* '''prot_ERROR-Overload''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_Warning-HighLoad''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_disconnected''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_init''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_ok''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_timeout''': Anzahl des Events, Zeitstempel des letzten Auftretens

=== Internals ===
* '''XmitOpen''': 1 = HMLAN ist sende bereit
* '''assignedIDs''': HMIDs der HM Devices, die über dieses IO bedient werden
* '''assignedIDsCnt''': Anzahl der zugewiesenen HMIds von FHEM
* '''assignedIDsReport''': Anzahl der HMIds, die das HMLAN angibt zu bedienen. Die Zahl sollte identisch sein mit assignedIDsCnt
* '''msgKeepAlive''': dlyMax: maximale Verzögerung, die ein keep-alive hatte. bufferMin: der minimale Zeitpuffer, der übrig blieb, bis das keep-alive zu spät gekommen wäre. Der Puffer sollte 2 oder größer sein, sonst könnte man gelegentlich disconnects bekommen.
* '''msgLoadEst''': Funkbelastung des HMLAN. Der Wert wird über 1 Stunde akkumuliert. Sollten 100% erreicht sein, wird das HMLAN den Sendebetrieb einstellen. Der Wert ist eine Hochrechnung in FHEM. Es ist möglich, dass das HMLAN mehr belastet ist. Die 10 min werte zeigen die Belastung in den letzten 10min Perioden an.
* '''msgParseDly''': Verzögerung der Message Verarbeitung vom Empfang im IO bis zur Verarbeitung in FHEM. Eine Verzögerung kann durch Prozesse an LAN, durch FHEM Prozesse oder sonstige Prozesse/Applikationen der CPU hervorgerufen werden.

== Pairen von Geräten ==
Jedes HM Geräte muss vor Verwendung mit der HM-Zentrale gepairt werden. Dabei wird die hmId des gewählten IOs in das Device programmiert. Ändert man die hmId des IO, mit man das Device anspricht, muss man das Device neu pairen.
Alle Geräte haben eine eigene Seriennummer, die nicht änderbar ist. Details zum Pairen auf der Seite [[HomeMatic Devices pairen]].

== Bekannte Probleme ==
Selten lehnt der HMLAN-Konfigurator ohne erkennbaren Grund nach monatelangem störungsfreiem Betrieb die Verbindung ab:

Opening HMLAN1 device 192.168.168.60:1000
192.168.168.60:1000 connection refused
Der HMLAN-Konfigurator kann aber über die mitgelieferte Konfigurationssoftware problemlos erreicht werden. Der Zustand lässt sich auch durch einen Reboot des HMLAN-Konfigurators (oder Fhem) nicht beheben, wohl aber durch eine Aktualisierung der Firmware des HMLAN-Konfigurators, selbst wenn die installierte Version aktuell ist.

Wenn das Konfigurationsprogramm Probleme hat, den HM-CFG-LAN LAN Konfigurations-Adapter zu finden, sollten alle nicht benutzten Netzwerkinterfaces vorübergehend deaktiviert werden. Vereinzelt gibt es Hinweise darauf, dass es unter Windows 7 eventuell nicht reicht, die Netzwerkverbindungen im "Netzwerk- und Freigabecenter" zu deaktivieren, sondern ein Deaktivierung der Netzwerkadapter im Gerätemanager erforderlich ist.

== Verbesserung der Antennenleistung ==

Die Sende- und Empfangsleistung kann man verbessern. Wie, das finden sie [[Trick_der_Woche#HM_LAN_Konfig-Adapter_Antenne_verbessern|hier]].

== Wechsel von CUL zu HMLAN ==
Sollten Sie ein [[CUL]] als IO für Homematic-Geräte eingesetzt haben und jetzt einen Wechsel auf den HMLAN Konfigurator planen, hält sich der Aufwand in Grenzen:

* deaktivieren Sie das CUL in der ''fhem.cfg''.
* konfigurieren Sie den HMLAN Konfigurator '''von Hand'''
* Ändern sie das Attribut IODev aller HM-Devices vom Namen der CUL auf den Namen des HMLAN
* sollte sie das Attribut IODev nicht nutzen (nicht empfohlen) achten sie darauf, dass im fhem.cfg das IO vor allen HM-devices definiert wird. Eine automatischen Zuweisung des IO zu den Devices ist sonst nicht möglich.
** der HMLAN '''muss''' die gleiche ''hmId'' wie das bisherige CUL erhalten. Ansonsten müssen alle Geräte neu gepairt / angelernt werden.
** AES muss im HMLAN abgeschaltet werden.
* verbinden Sie den HMLAN Konfigurator mit ihrem Netzwerk und ziehen das CUL aus der USB-Buchse.
* geben Sie in der FHEM-Befehlszeile ''shutdown restart'' gefolgt von <Enter> (nicht "save") ein (evtl. reicht auch ein ''rereadcfg'').
* kontrollieren Sie im Event-Monitor und in den HM-Device-Logs von Fhem die Kommunikation.

Bitte beachten: Falls dem CUL keine explizite hmId per Attribut zugewiesen wurde, wird diese ID aus "F1<FHT-ID>" zusammengebaut. Die hmId muss auf dem HMLAN explizit gesetzt werden.

== Links ==
* [http://www.eq-3.de/software.html Software] für den Konfigurationsadapter von der eQ-3 Site

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

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

2015-01-28T14:08:30Z

Rohan: /* Channel (Kanal) 04 _Clima */ Hinweis auf "set <rt_Clima> regSet valveMaxPos XX" eingearbeitet

Beim '''HM-CC-RT-DN''' handelt es sich um einen '''Funk-Heizkörperthermostaten mit integriertem Stellantrieb''', der als Nachfolger den [[HM-CC-VD]] ablöst und seit Mitte September 2013 verfügbar ist.

== Vorbemerkungen ==

Im Gegensatz zum Vorgänger misst der HM-CC-RT-DN selbst die Temperatur und verfügt über eine Boost-Funktion. Er braucht zur Steuerung kein separates Raumregelungsgerät mehr und hat eine eigene Fenster-Offen-Erkennung. Ein passender Wandthermostat ([[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]]) ist seit Februar 2014 verfügbar.

Das Gerät wird seit Anfang Oktober 2013 von Fhem unterstützt (siehe Diskussion im [http://forum.fhem.de/index.php/topic,14738.0.html 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 Firmware Update Software. Weitere Details sind unter [[HM-CC-RT-DN_Funk-Heizkörperthermostat#Firmware_Update|Firmware Update ]] beschrieben.

'''Achtung:''' Die Solltemperaturen eines HM-CC-RT-DN lassen sich <ins>nicht</ins> durch einen [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]] steuern. Dieser kann höchstens die Ist-Temperatur an den RT weiter geben, damit die Raumtemperatur nicht am RT selbst zur Ventilsteuerung genommen 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
gep'''ee'''rt 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.3

== Betrieb mit FHEM ==
Der Funk-Heizkörperthermostat muss zuerst mit Fhem [[HomeMatic_Devices_pairen|gepairt]] werden. Da es den RT noch nicht lange gibt, sollten Sie sicher stellen, 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 kann z.B. ein HomeMatic HM-WDS10-TH-O Funk-Temperatur-/Luftfeuchtesensor OTH dienen.

Der Befehl zum peeren lautet, wobei <tempSensor> die Fhem-Kanalbezeichnung für den Sensor ist und <rt_Weather> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates:
set <tempSensor> peerChan 0 <rt_Weather> single

==== Channel (Kanal) 02 _Climate ====
Der Climate-channel dient der Kommunikation mit einem Temperatur-Kontroller (aktuell nur [[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]]).
Zum peeren von TC und RT siehe [[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP#Hinweise zur Inbetriebnahme und Installation|HM-TC-IT-WM-W-EU]]

==== 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.
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]] näher 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 <rt_WindowRec> single

Zum Löschen (=unpeeren) dieser Kopplung:
set <fensterSensor> peerChan 0 <rt_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 <rt_WindowRec> regSet winOpnTemp <Temp> <fensterSensor>

==== Channel (Kanal) 04 _Clima ====
Dieser Kanal dient zum Einstellen der Betriebsparameter, auch [[#Temperaturlisten]] sind hierauf zu übrtragen.

'''Achtung:''' In älteren Versionen von Fhem wurde dieser Kanal durch autocreate als "_ClimRT_tr" angelegt. Der Hersteller hat hier offenbar die internen Bezeichnunen 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 <rt_Clima> regSet valveMaxPos 80

Die interne "Fenster-auf" Erkennung kann man wie folgt abschalten:
set <rt_Clima> regSet winOpnMode off

==== Channel (Kanal) 05 _ClimaTeam ====
Dieser Kanal dient zum peeren von mehreren Heizkörperthermostaten untereinander. 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 <rt1-ClimaTeam> und <rt2-ClimaTeam> die Kanalbezeichnungen der beiden ClimaTeam-Kanäle sind:
set <rt1-ClimaTeam> peerChan 0 <rt2-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:
<pre>set <button> peerChan 0 <rt-remote> single</pre>

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

Im Automode kann man die Temperatur am Einstellrad des RT ändern. Zum nächsten Schaltpunkt wird dies dann überschrieben. Will man dies nicht (z.B. lange Party, ...), kann man auf manuell schalten. Dann bleibt die mit dem Drehregler (oder der Zentrale) eingestellte Temperatur stehen bis ''ultimo''. Es gibt dann noch den Party- oder Urlaubsmodus. In diesen kann man den Automodus für eine gegebene Zeit überschreiben.

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

==== Modus Manu ====
Das Wochenprogramm wird nicht abgearbeitet, die Temperatur wird manuell eingestellt.

==== Modus Party (Urlaub) ====

Will man für eine festgesetzte Zeit (Stunden oder Tage) die Temperatur auf einen festen Wert einstellen (z.B. weil man in Urlaub fährt), kann man dies zwar auch durch Änderungen der Temperaturlisten erreichen, einfacher ist aber die Zuweisung über den Urlaubsmodus, da nach dessen Ablaufdatum und -zeitpunkt automatisch in den Auto-Modus gewechselt wird.

'''Ein Beispiel:'''

<pre>
set HM-CC-RT-DN_Clima controlParty 16 06.12.13 16:30 09.12.13 05:00
</pre>

Dadurch wird

* vom 06.12.2013, 16:30 Uhr,
* bis zum 09.12.2013, 05:00 Uhr
* die gewünschte Raumtemperatur auf 16 °C

eingestellt.

'''Hinweise:'''
* Der Befehl muss auf den Channel 4 ("_Clima") erfolgen.
* Es werden nur Uhrzeiten zu jeder vollen oder halben Stunde angenommen (Minuten also 00 oder 30).

Mit der Funktion "Urlaub" kann man eine ganze Wohnung (also mehrere RT´s) mit nur einem Befehl in den Party-mode versetzen. 
Der Name "Urlaub" kann natürlich frei gewählt werden.
Im Beispiel werden 2 Heizkörper (Treppenhaus und Kammer) angesteuert.

Zu beachten sind folgende Dinge:
# Aktuelle Dateien (z.B. 10_CUL_HM) verwenden!
# Bei dem partycontrol-Befehl in der Funktion KEIN Komma zwischen den Parametern.
# Bei der Funktion die Parameterübergabe definieren ($$$$$)

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

'''Funktion:'''
<pre>
my $Urlaub;
sub
Urlaub($$$$$)
{
#lokale Variablendeklaration
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/;

#Sendebefehl für ein HM-CC-RT-DN
{fhem ("set Kammer controlParty $temp $startDate $startTime $endDate $endTime")}

# alternative Schreibweise der Parameter:
{fhem ("set Treppenhaus controlParty @_[0] @_[1] @_[2] @_[3] @_[4]")};
}
</pre>

=== 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 Kommanods. 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 RT muss den Receiver wach halten. Der RT und alle anderen Burst-Devices erwachen bei '''jedem''' Burst (egal für wen) und legen sich dann wieder schlafen.
* jeder Burst-trigger kostet Batterie für '''alle''' Burst-Geräte im System
* wenn Burst enabled ist kostet es dem RT Batteriekapazität

'''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 messages 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 message. 
 
'''ConditionalBurst devices''' 
Devices mit abschaltbarem burst wie z.B. der 'HM-CC-RT-DN', gibt es ein Register burstRx mit dem das burst-erwachen eingestellt werden kann.
Sender, 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 Hminfo kommando 'models' um festzustellen, welche devices welchen mode 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) 
<pre>set WZ1_4 regSet burstRx on </pre>
prüfen mit: 
<pre>get WZ1_4 reg burstRx </pre>
''Nun in FHEM den Burst mode einschalten (sofern nicht burstXmit verwendet wird)'' 
<pre>attr WZ1 burstAccess 1_auto</pre>

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

=== Temperaturprofile ===
Im Kanal ''Clima'' kann man einen Wochenplan (ein Temperaturprofil) hinterlegen. Im automatischen Betrieb stellt der Heizkörperhermostat dann die Wunschtemperatur gemäß diesem Profil ein. Die Daten werden in Registern des Heizkörperthermostates abgelegt, es gibt gesonderte Kommandos zur Verwaltung des Profils. Die Darstellung des Temperaturprofils unterliegt aber dennoch den Regeln der Register: Fhem muss die Daten aus dem Device lesen (getConfig), um sie darzustellen.
Ändert man eine der Temperaturlisten müssen die Daten an das Device übertragen werden. Bis dies bestätigt ist wird in Reading '''R_tempList_State''' '''set''' angezeigt. Sobald die daten aus dem Device zurückgelesen sind steht wird es auf '''verified''' gesetzt (sollte der Normalzustand sein). '''incomplete''' wird gesetzt, falls beim Lesen der Register ein Teil der Daten nicht empfangen wurde.
==== Manuelle Änderung ====
Mit dem Kommando
set <rt>_Clima tempListMon 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0
kann man das Temperaturprofil für den Wochentag ''Montag'' einstellen. Die nach dem Schaltzeitpunkt stehende Temperatur gilt immer '''bis''' zu diesen Zeitpunkt, nicht ab diesem Zeitpunkt. Der letzte Wert muss immer Mitternacht (24:00) sein.
damit ist also 00:00 - 05:30 = 16Grad, 05:30 - 07:30 = 18 Grad. Die Zeit kann in Schritten von 30min eingestellt werden, die Temperatur in 0.1 Grad.
Der Tage beginnt immer um 00:00, der letzte Abschnitt MUSS 24:00 sein.

Ändert man mehrere Tage auf einmal sollte man unbedingt mit "prep" und "exec" arbeiten, da es sonst zu Wiederholungen und langen Bearbeitungen kommen kann. Prep bereitet die Änderung in FHEM nur vor, mit exec werden die Daten dann an das Device übertragen. Das könnte in einem Fhem-Script lauten
sub
SetTempList_UG_Treppe_Heizung()
{
{ fhem ("set UG.Treppe.Heizung_Clima tempListMon prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListTue prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListWed prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListThu prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListFri prep 05:30 16.0 07:00 18.0 15:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListSat prep 07:00 16.0 09:00 18.0 15:00 18.5 21:00 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListSun '''exec''' 07:00 16.0 09:00 18.0 15:00 18.5 21:00 19.0 24:00 16.0")};
}

==== Temperaturprofile in einer Datei====
Eleganter ist die Verwaltung von Temperaturprofilen in einer Datei. Damit kann man
* 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

===== Dateiformat =====
Die Temperaturprofile werden in einer Datei abgelegt im Format
entities:room1
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 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
entities:room2,room3
tempListSat>08:00 18.0 15:00 18.0 21:30 19.0 24:00 14.0
tempListSun>08:00 18.0 15:00 18.0 21:30 19.0 24:00 14.0
...

* '''entities''' ist eine komma-separierte Liste der Namen des folgenden Temperaturprofils. Das erste Temperaturprofil im Beispiel hat den Namen "room1", das 2. hat zwei Namen, "room2" und "room3".
* '''tempList...''' ist die Liste der Schaltzeiten und Temperaturen des Tages. Die nach dem Schaltzeitpunkt stehende Temperatur gilt immer '''bis''' zu diesen Zeitpunkt, nicht ab diesem Zeitpunkt. Der letzte Wert muss immer Mitternacht (24:00) sein.

===== Temp Profil Datei erstellen/updaten =====
Mit HMInfo kann man eine Temperaturdatei ???  oder updaten.
set hm tempList save <filename>
set hm tempList save -f <channelName> <filename>
Die Temperaturlisten der Devices, ggf. nur der gefilterten Devices - werden in das File abgelegt. Sollte für die Entity bereits ein Eintrag vorhanden sein wird dieser ersetzt. Vorhandene weitere Einträge werden nicht geändert. Das save ist unabhängig von attribut tempListTmpl.
Default für Filename ist "tempList.cfg". Als Entity wird der Name des Kanals genutzt.

===== Überprüfen/Einlesen =====
Mit dem verify-Kommando wird überprüft, ob das gegenwärtig vorhandene Temperaturprofil mit dem in der Datei befindlichen übereinstimmt.
set <rt>_Clima tempListTmpl verify FHEM/tempList.cfg:room1
Mit dem restore-Kommando wird das Temperaturprofil des Heizkörperthermostaten mit dem in der Datei befindlichen überschrieben.
set <rt>_Clima 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 <rt>_Clima tempListTmpl FHEM/tempList.cfg:room1
set <rt>_Clima 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 <rt>_Clima tempListTmpl restore
überschreibt das gegenwärtige Temperaturprofil des Heizkörperthermostaten mit dem in der Datei befindlichen überschrieben.
===== Vorschlag =====
Zur Verwaltung der Temperaturprofile sollte die Datei tempList.cfg im Verzeichnis FHEM liegen, dann kann sie mit dem Web-Interface editiert werden.
Wenn man im Sommer allen HKs das gleiche Profil geben will, kann man dies in der Datei erstellen und weist allen das template zu. Hier ein Beispiel für RT's:
attr TYPE=CUL_HM:FILTER=DEF=......04:FILTER=model=HM-CC-RT-DN tempListTmpl tempList.cfg:sommer
set hm tempListTmpl restore
set hm tempListTmpl verify
Nach dem Restore natürlich warten, bis die Daten geschrieben sind.

==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 15.07.2014 gibt es für den HM-CC-RT-DN die neue Firmware Version 1.3. 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.

== 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 dem Forum: [http://forum.fhem.de/index.php/topic,31078.msg236245.html#msg236245 Thread]''
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 dem Forum: [http://forum.fhem.de/index.php/topic,19686.msg233788.html#msg233788 Thread]''

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 Type hmInfo existiert):
set hm peerXref
Beispiel-Ausgabe:
peerXref done:
x-ref list
wz_Thermostat_Weather => wz_vT_Sensor1
wz_vT_Sensor1 => wz_Thermostat_Weather

6. Gemessene Temperatur vom zb. 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. Nähere Informationen zu dieser Funktion siehe [[FHEM_Command_Beispiele#update_...|hier]].

== Links ==
* [http://www.elv.de/homematic-heizkoerperthermostat-1.html Produktinfo]
* [http://www.elv-downloads.de/Assets/Produkte/10/1051/105155/Downloads/105155_thermostat_um.pdf Bedienungsanleitung (PDF)]
* [http://www.elv-downloads.de/Assets/Produkte/10/1051/105155/Downloads/105155_thermostat_data.pdf Datenblatt (PDF)]
* [http://www.elv-downloads.de/service/manuals/ventilkompatibilitaet.pdf Ventil-Kompatibilitätsliste (PDF)]

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

Plots erzeugen

2015-01-27T08:03:23Z

Rohan: /* Individuell / Manuell */ Anmerkung ergänzt und Typos

'''Plots erzeugen'''

== .gplot-Editor ==

Fhem verfügt über einen ".gplot-Editor", um die .gplot-Datei zur Erstellung eines Plots menügeführt zu generieren. Ein manuelles Anlegen der .gplot-Datei ist für Spezialisten und normalerweise nicht notwendig. Der .gplot-Editor sollte für Standardfälle grundsätzlich verwendet werden.

Details zum .gplot-Editor können im Ankündigungshinweis im {{Link2Forum|Topic=11275|Message=75594|LinkText=Fhem-Forum}} nachgelesen werden.

Spezielle Erläuterungen zur Erzeugung von Plots mit Stati: {{Link2Forum|Topic=12945|Message=78887|LinkText=Fhem-Forum}}, [[EnOcean-STM-250-Fenster-Türkontakt#Türstatus in einem Plot darstellen|Schrittweises Beispiel bei Kontakten]], [[EnOcean-D-452-FU-EBIM-Aktor-2fach#Aktorstatus_in_einem_Plot_darstellen|Schrittweises Beispiel zum Aktorstatus]]

Verhinderung von Perl-Warnungen bei LogFiles mit unterschiedlicher Spaltenanzahl in Log-Zeilen: {{Link2Forum|Topic=27835}}

<big>'''Achtung'''</big>:

Verwenden Sie diesen Editor nicht, wenn das Fhem-Device bereits angelegt ist und Sie für dieses Device ein bestehendes, allgemeines gplot-File verwenden, das auch für andere Devices benutzt wird. Beim Abspeichern wird ein Filter im gplot-File gesetzt, das das gplot-File nur für genau dieses Device verwendbar macht.

Beispiel:

aus

#FileLog 4:::

wird

#FileLog 4:DS2423.energy_a\x3a::

in dem entsprechenden gplot-File.

Die anderen Devices, die evtl. dieses gplot-File verwenden, haben danach keine funktionierende Plot-Anzeige mehr. Bevor also etwas geändert wird, sollte mit

set weblink_irgendwas copyGplotFile

ein Duplikat angelegt werden, das ausschließlich für diesen Plot verwendet wird. Der Befehl kann unterhalb des ersten Kasten per Dropdown ausgewählt werden.

== Individuell / Manuell ==

'''Vorbemerkungen:'''

* Fhem bediente sich früher für die Erstellung der Plots des Programms ''Gnuplot'' [http://www.gnuplot.info/]. Hierbei reichen die "einfacheren" Funktionalitäten dieses Programms aus (''Gnuplot'' kann noch viel mehr).
* aktuelle Fhem-Versionen haben die Plot-Funktionen (angelehnt an die Plot-File-Syntax von Gnuplot) integriert.
* die Beispieldateien für die in Fhem integrierten Plots finden Sie in Ihrem Fhem-Programmordner unter ''www/gplot''.
* Angaben wie <SIZE>, <OUT>, <L1>, <IN> usw. im Plot-File sind Platzhalter bzw. Feldbezeichner für Fhem. Diese sind case-sensitive (Groß-/Kleinschreibung beachten).

Ein Beispiel (''temp4hum4.gplot'') aus diesem Verzeichnis:

# Attribute 'small' is useful for gnuplot/-scroll only,
# if plotsize is less than 800,400
#set terminal png transparent small size <SIZE> crop

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 ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics

set y2label "Temperature in C"
set ylabel "Humidity (%)"

#FileLog 4:temperature:10:
#FileLog 4:humidity:50:

plot \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Measured temperature' with lines,\
"< egrep 'humidity' <IN>"\
using 1:4 axes x1y1 title 'Humidity (%)' with lines\

Die Zeilen, die mit ''set'' beginnen, beeinflussen wesentlich das Erscheinungsbild und Aussehen Ihrer Plots (Achsenbeschriftungen, Skalen usw.). Dabei sollten Sie die Zeilen, die eine Angabe zwischen "<" und ">" enthalten, zunächst unverändert lassen. Weitere (ausführliche) Hinweise (zu Gnuplot!) finden Sie in einer [http://www.home.uni-osnabrueck.de/elsner/Skripte/gnuplot.pdf PDF-Datei]. Eingeschränktere, aber für die meisten Belange von Fhem ausreichende Infos finden Sie auf [http://www.aurbacher.net/gnuplot/gnuplot.html dieser Web-Seite].

=== Benutzung der Variablen ===
{| class="wikitable"
! Variable
! Nutzung in gplot-File
! Füllung mit inhalt in fhem.cfg
|-
| <TL>
| set title '<TL>'
| attr weblink title "Dies füllt den Platzhalter <TL>"
|-
| <L1>
| set xlabel '<L1>'
| attr weblink label "Dies füllt das Label <L1>"
|-
| <L2>
| set title '<L2>'
| attr weblink label "Dies füllt das Label <L1>"::"Dies füllt das Label <L2>"
|}

=== Welche Daten werden dargestellt ===

Die Zeilen

#FileLog 5::0:
#FileLog 14::0:

in einer gplot-Datei tragen zwar zu Beginn das Kommentarzeichen "#", jedoch handelt es sich durchaus nicht um solche. Vielmehr trifft man mit den Werten hinter ''FileLog'' Vorgaben, welche Werte wie von Fhem an ''gnuplot'' zwecks grafischer Darstellung übergeben werden.

Im o.a. Beispiel werden das 5. und das 14. Wertfeld (voneinander getrennt durch ein Leerzeichen (Blank)) an gnuplot weiter gegeben.

Eine dazu passende Log-Dateizeile könnte beispielsweise so aussehen

2013-11-14_17:32:00 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200
----1. Feld-------- --2. Feld-- --3.---- -4.- -5. -6. 7. 8. -9. 10. 11 12 --13.- --14.---

^ ^
werden ausgewertet --| --|

Diese Parameter können auch als Attribut übergeben werden:

attr weblink plotfunction "FileLog 5::0:"

Anhand der Anmerkungen wird hoffentlich die Wirkungsweise deutlich. Zu den restlichen - optionalen - Parametern hinter ''FileLog'' wird zunächst auf die [http://fhem.de/commandref.html#FileLogget commandref] verwiesen.

=== Datum und Zeit ===

'''Anmerkungen / Hinweise:'''

Fhem erwartet das Datum '''und''' die Uhrzeit der Log-Dateieinträge '''zwingend''' an <ins>erster Stelle</ins> der Datenzeile und zwar im Format

<code>
JJJJ-MM-TT_SS:mm:ss
</code>

wobei

* JJJJ die 4-stellige Jahreszahl
* MM der 2-stellige Monat (ggfls. mit Vornull)
* TT der 2-stellige Tag (ggfls. mit Vornull)
* SS die 2-stellige Stunde (ggfls. mit Vornull)
* mm die 2-stellige Minute (ggfls. mit Vornull)
* ss die 2-stellige Sekunde (ggfls. mit Vornull)

bedeutet. Bitte beachten Sie auch die Stelle der Zeichen "-", "_" und ":". Stehen diese nicht an den angegebenen Stellen, wird die entsprechende Zeile beim Erzeugen des Plots nicht beachtet. Ggfls. wird gar kein Plot angezeigt.

Eine Änderung/Anpassung der *.gplot-Datei in der Zeile

set timefmt "..."

hat auf dieses Verhalten von Fhem '''keine''' Auswirkungen, sondern nur auf die Darstellung von Datum und Zeit durch ''Gnuplot'' .

Dazu ein Beispiel:

Mit

2013-11-14_17:32:00 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200

kann Fhem etwas anfangen. Mit

20131114173200 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200

oder

14.11.2013 17:32 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200

dagegen nicht.

Im ersten Fehler-Beispiel fehlen die notwendigen Trennzeichen, im zweiten Fehler-Beispiel ist die Reihenfolge im Datum verkehrt, außerdem werden die falschen Trenner verwendet. Zudem fehlen die Sekunden.

=== Plot der letzten 24 Stunden statt des aktuellen Tages ===

Hierzu kann man in der ''Fhem.cfg'' für die Einträge

define WEB FHEMWEB 8083 global

das Attribut

attr WEB endPlotNow 1

setzen. Gleiches geht auch für ''WEBphone'' und ''WEBtablet''. Da muss es dann lauten

attr WEBphone endPlotNow 1

bzw.

attr WEBtablet endPlotNow 1

Das Attribut gilt dann aber für '''alle''' Plots der jeweiligen Ansichten. Wenn man wieder zurück zu den Plots ab jeweils 00:00 Uhr des aktuellen Tages möchte, löscht man dieses Attribut wieder bzw. setzt es auf den Wert "0".

=== Legende links platzieren ===

Gerade im Verbund mit dem Attribut ''endPlotNow'' macht das seit dem 11.01.2015 neue Attribut ''captionLeft'' Sinn, da dann die Legende nicht mehr rechts oben, sondern links oben im Plot erscheint. Dadurch wird die Sichtbarkeit der aktuellen Werte verbessert.

[[Kategorie:FAQ]]
[[Kategorie:HOWTOS]]

HomeMatic

2015-01-26T13:16:56Z

Rohan: /* Fhem als Zentrale */ Hinweis und Link auf HM-CFG-USB eingetragen

'''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 a-ngeboten.
===Fhem als Zentrale===
Für den Einsatz mit Fhem wird eine Funkschnittstelle benötigt, in Frage kommen [[CUL]], der [[HMLAN Konfigurator]] oder ein [[HM-CFG-USB_USB_Konfigurations-Adapter|HM-CFG-USB]].
'''Fehlt Bemerkung zu Wired'''

==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, siehe hier [[Kategorie:HomeBrew]]
=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, eine 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 erkä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.

== Pair / Peer bzw. pairen und peeren ==
HM Geräte können mit und ohne Zentrale betrieben werden. In FHEM wird davon ausgegangen, dass Geräte immer von einer Zentrale aus gesteuert werden können. Um dies zu erreichen muss das Device mit der Zentrale gepairt werden.

=> [[HomeMatic Devices pairen|Devices Pairen]]

Um einen Betrieb (auch)ohne Zentrale zu ermöglichen kann man Kanäle <ins>p'''ee'''ren</ins>. Hier bei wird ein Sensor-Kanal mit einem Aktor-Kanal verknüpft werden.
siehe [[Homematic_Peering_Beispiele|Channels peeren]] für Details.

== HMInfo ==
Mit [[Homematic_HMInfo|HMInfo]] kann man eine Übersicht der HM Installation erhalten, Konfiguration prüfen und Alarme 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 ===
Analog virtuellen Entities kann man auch IO entities erzeugen. IO ist nicht ganz korrekt, eigentlich sind es Kanäle einer Zentrale. Da diese in FHEM nicht abgebildet wird sind sie teilweise in den IOs realisiert. 
Faktisch ist es ein Kanal, der der HMId des gewählten IO device zugeordnet ist. Aktuell wird dieser Kanal nicht in FHEM dargestellt. Man kann diese Entity jedoch peeren. 
Man kann jeder HMId bis zu 50 Kanäle zuweisen. Da mehrere IO devices die gleiche HMId nutzen können, teilen sich diese in diesem Fall die Kanäle.

=== 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:
* P'''ai'''ring nicht abgeschlossen (bei den ''Readings'' "PairedTo" bzw. "R-pairCentral" steht der Wert '''set_'''0x1A2B3C). Das P'''ai'''ring 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]]

HM-LC-BL1-FM Funk-Jalousieaktor

2015-01-15T20:41:23Z

Rohan: /* Tasterverhalten */ Anmerkung zur Umstellung des Tasterverhaltens.

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=HomeMatic Unterputz Funk Rollladenaktor
|HWProtocol=HomeMatic
|HWType=Aktor
|HWCategory=HomeMatic
|HWComm=868 MHz
|HWChannels=1
|HWVoltage=230V
|HWPowerConsumption=<0,5W (Ruhebetrieb)
|HWPoweredBy=Netz
|HWSize=53x53x30mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

Homematic Funk-Jalousieaktor 1-fach (Unterputz)

== Features ==
Schalten eines angeschlossenen Jalousiemotors mittels [[CUL]]/CUN/[[HMLAN Konfigurator]] und über einen mechanischen spannungsfesten Taster.

'''Technische Daten:'''
* Schaltvermögen: 250W Motorlast 230V/50Hz
* Relais: 1x Schließer und 1 Wechsler
* Standby Verbrauch: 0,5W
* Maße(BxHxT): 53x53x30mm

== Installation ==
Will man die Funk-Schaltaktoren auch manuell betreiben, so sind Taster notwendig. Schalter können notfalls mittels einer zusätzlichen Feder zum Taster umgebaut werden, Tastschalter sind nicht geeignet. Schalter und Tastschalter führen dazu, dass der Aktor nach Betätigung des Schalters in den Anlernmodus versetzt wird und auch in diesem verbleibt.

Je nach vorhandenen Schalterdosen empfiehlt es sich, bestehende Schalterdosen nach hinten auszuweiten, d.h. die Abdeckung nach hinten heraus zu brechen, da die Aktoren und Kabel nicht gerade sparsam mit dem Platz umgehen. Alternativ kann der Aktor auch in einer zusätzlichen Schalterdosen untergebracht und diese mit einem Federdeckel verschlossen werden. Dies hat den Vorteil, dass auch durch eine relativ dicke Tapete die LED und somit der Zustand des Aktors erkannt werden kann.

== Hinweise zum Betrieb mit FHEM ==
Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden. Hierfür wird ein am Aktor temporär angeschlossener spannungsfester Taster zwingend benötigt oder es erfolgt über Fhem mittels der Seriennummer.

=== Konfiguration ===
Ein exemplarischer Auszug aus der [[Konfiguration]] (fhem.cfg):

<pre>
define JalousieWohnzimmer CUL_HM 17E43C
attr JalousieWohnzimmer devInfo 010100
attr JalousieWohnzimmer firmware 1.5
attr JalousieWohnzimmer hmClass receiver
attr JalousieWohnzimmer model HM-LC-BL1-FM
attr JalousieWohnzimmer room Wohnzimmer
attr JalousieWohnzimmer serialNr IEQ0xxxxxx
attr JalousieWohnzimmer subType blindActuator
</pre>

=== Mögliche Schaltoperationen ===
Der Aktor versteht folgende Aktionen:

<pre>
set <name> on -> Schaltet den Aktor ein
set <name> off -> Schaltet den Aktor aus
set <name> toggle -> Ändert den logischen Zustand des Aktors, d.h. ein eingeschalteter Aktor wird ausgeschaltet. Im Falle der 10% geöffneten Jalousie wird diese geschlossen.
set <name> <Zweistellige Zahl> -> Schaltet den Aktor ein und öffnet die Jalousie um <Zweistellige Zahl>%. 100% entspricht dabei einem "on"
</pre>

=== Fahrtzeiten 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 drei Zeiten werden in Sekunden gemessen und anschließend einmalig mit den folgenden Befehlen eingestellt:

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

Wichtig: Danach unbedingt am Aktor auf Anlernen drücken, damit er die regSets abarbeiten kann. Ob alles geklappt hat, kann überprüft werden mit:
<pre>
set <name> getConfig
get <name> reg all
</pre>
Dort sollten dann die Werte stehen, z.B.
<pre>
WZ_Jal_Rechts type:blindActuator -
list:peer register :value
0: intKeyVisib :invisib
0: pairCentral :0xE1F88A
1: driveDown :27 s
1: driveTurn :0.5 s
1: driveUp :27 s
1: refRunCounter :0
1: sign :off
</pre>

wenn noch z.B. bei driveDown steht <code>set_27</code>, dann hat es noch nicht geklappt, dann müsst ihr nochmal anlernen drücken.
Und am besten jetzt nochmal im Eingabefeld in fhem ein "save" absetzen. Wenn ihr die Konfiguration des Schalters für Euch als Textdatei speichern wollt, dann hilft Euch ein
:<code>get <name> saveConfig <dateiname></code>

Das legt dann eine Datei in Eurem fhem-"root" Verzeichnis ab, in der alle Werte stehen.

=== Tasterverhalten ===

Das Tasterverhalten kann auch (zusätzlich) auf 1-Tasten-Bedienung (1 Taste drücken für rauf oder runter, die selbe Taste drücken zum Stoppen) umgestellt werden. Hierzu ist wie beim [[HM-LC-Bl1PBU-FM_Unterputz-Jalousieaktor#Tasterverhalten|HM-LC-Bl1PBU-FM]] vorzugehen. Diese Konfiguration hat beim HM-LC-BL1-FM aber die evtl. unerwünschte Nebenwirkung, dass die Funktionalität der Tasten umgedreht wird: Aus der Rauf-Taste wird die Runter-Taste und umgekehrt. Wer dies nicht möchte, sollte diese Änderung nicht vornehmen. Sobald eine Lösung existiert, wird diese hier beschrieben.

=== Log-Auszug ===
In FHEM ist nach dem Schalten des HM-LC-BL1-FM folgendes Log zu sehen:

<pre>
2012.02.12 17:53:08 2: CUL_HM set JalousieWohnzimmer on
2012.02.12 17:53:09 2: CUL_HM set JalousieWohnzimmer off
2012.02.12 21:25:14 2: CUL_HM set JalousieWohnzimmer 37
</pre>

= Links =
* [[Jalousie und Beleuchtung in mehreren Räumen]]
* [[Slider für HM-Rollladensteuerung anzeigen]]
* [http://www.elv-downloads.de/service/manuals/76793_HM_Unterputzschalter_UM.pdf Bedienungsanleitung] (PDF, ELV)

[[Kategorie:HomeMatic Components]]
[[Kategorie:HomeMatic Type Blind]]
[[Kategorie:Rollladensteuerung]]

HM-ES-PMSw1-Pl Funk-Schaltaktor 1-fach mit Leistungsmessung

2015-01-15T20:34:00Z

Rohan: Tipp aus dem Forum eingearbeitet

'''HM-ES-PMSw1-Pl'''
[[Datei:HM-ES-PMSw1-PI-Frontansicht.jpg|thumb|HM-ES-PMSw1-PI Frontansicht]]
[[Datei:HM-ES-PMSw1-PI-Seitenansicht.jpg|thumb|HM-ES-PMSw1-PI Seitenansicht]]
HomeMatic Funk-Schaltaktor 1-fach mit Leistungsmessung. Bauform: Zwischenstecker

Verfügbar seit dem 20.12.2013.

== Features ==

HomeMatic Funk-Schaltaktor mit Leistungsmessung für zwei Funktionsbereiche:
* Schalten von angeschlossenen Verbrauchern (Schaltkanal)
* Messen von Spannung, Strom, Wirkleistung, Frequenz und Energieverbrauch (Messkanal)
* Automatische Schalten von angelernten Aktoren beim Über- oder Unterschreiten von definierten Schwellwerten (Sensorkanäle)

Der Schaltkanal kann angeschlossene Verbraucher oder angelernte HomeMatic Aktoren ein- bzw. ausschalten.
Der Messkanal verfügt über eine Messfunktion und Empfangs- sowie Übertragungsmöglichkeit von Messdaten (z. B. Spannung, Strom, Wirkleistung, Frequenz und Energieverbrauch bis 3680 Watt/16 A). Die Messdaten werden je nach Verbraucherverhalten in Abständen von einigen Sekunden bis mehreren Minuten übertragen, der Sendezyklus kann durch verschiedene Register konfiguriert werden (Änderungsschwellwerte). Des weiteren kann er - in Abhängigkeit von definierbaren Schwellwerten (Über- / Unterschreitung) - andere Aktoren schalten.

'''Technische Daten:'''
* Spannungsversorgung: 230 V/50 Hz
* Stromaufnahme: 16 A max.
* Leistungsaufnahme Ruhebetrieb: < 0,6 W
* Max. Schaltleistung: 3680 W (ohmsche Last)
* Schutzart: IP 20
* Relais: Schließer
* Schaltzyklen: 50.000 bei cosφ=1
* Abmessungen (B x H x T): 59 x 123 x 40 mm
* Gewicht: 165 g (ohne Netzstecker)
* Messauflösung Leistung: 0,01 W
* Messbereich Leistung: 0–3.680 W
* Messgenauigkeit Leistung: 1 % ±0,03 W
* Messauflösung Strom: 1 mA
* Messbereich Strom: 0–16 A
* Messgenauigkeit Strom: 1 % ±1 mA
* Messauflösung Spannung: 0,1 V
* Messbereich Spannung: 200–255 V
* Messgenauigkeit Spannung: 0,5 % ±0,1 V
* Messauflösung Frequenz: 0,01 Hz
* Messbereich Frequenz: 48,72–51,27 Hz
* Messgenauigkeit Frequenz: 0,1 % ±0,01 Hz

(Angaben ohne Gewähr)

== Hinweise zur Inbetriebnahme und Installation ==

Der PMSw1 funktioniert "out-of-the-box", nachdem er an Fhem angelernt (gepairt) worden ist.

== Probleme ==

* Sobald der PMSw1 selbst von der Spannungsversorgung getrennt worden ist, verliert er die bisherigen Verbrauchswerte.
* Nach einem Stromausfall steht der Schalter auf "Aus", das angeschlossene Gerät ist also ebenfalls aus. Dies kann - falls man den Aktor nur zur reinen Verbrauchsmessung verwendet - bei der Messung von z.B. Kühlschrank, Kühltruhe oder Heizung zu unerfreulichen Auswirkungen führen. Eine Abhilfe schaffen die unter "Tipps" weiter unten aufgeführten Register-Einstellungen.

== Betrieb mit FHEM ==

Der PMSw1 verfügt über insgesamt 6 Kanäle (HM-Jargon: channels), von denen der Schaltkanal (Kanal 1) und der Messkanal (Kanal 2) in FHEM primär genutzt werden. Die Kanäle 3 - 6 sind zur Konfiguration der Schaltvorgänge gepeerter Aktoren bei Änderungen des Leistungsverbrauchs (Kanal 3), des Stromverbrauchs (Kanal 4), der elektrischen Spannung (Kanal 5) oder der Frequenz (Kanal 6). Diese Kanäle können ausschließlich über Register konfiguriert werden.

=== Channels (Kanäle) 01 bis 06 ===

==== Channel 01 (_SW) ====

Der eigentliche Schaltkanal, über den die am PMSw1 eingesteckten Verbraucher ein- und ausgeschaltet werden können.

Log-Datei des Kanals:

<Datum>_<Zeit> HMPMSW_01_Sw set_on
<Datum>_<Zeit> HMPMSW_01_Sw level: 100 %
<Datum>_<Zeit> HMPMSW_01_Sw pct: 100
<Datum>_<Zeit> HMPMSW_01_Sw deviceMsg: on (to HMLAN1)
<Datum>_<Zeit> HMPMSW_01_Sw timedOn: off
<Datum>_<Zeit> HMPMSW_01_Sw set_off
<Datum>_<Zeit> HMPMSW_01_Sw level: 0 %
<Datum>_<Zeit> HMPMSW_01_Sw pct: 0
<Datum>_<Zeit> HMPMSW_01_Sw deviceMsg: off (to HMLAN1)
<Datum>_<Zeit> HMPMSW_01_Sw timedOn: off

==== Channel 02 (_Pwr) ====

Der Messkanal des PMSw1, über den die momentane Netzspannung, die Frequenz (in Hz), die aktuellen Verbrauchswerte (Last, Watt) sowie die seit Inbetriebnahme umgewandelte Leistung ("Verbrauch", Wh) usw. an die Zentrale (hier Fhem) übermittelt werden.

Log-Datei des Kanals:

<Datum>_<Zeit> HMPMSW_01_Pwr energy: 153.2
<Datum>_<Zeit> HMPMSW_01_Pwr power: 90.92
<Datum>_<Zeit> HMPMSW_01_Pwr current: 427
<Datum>_<Zeit> HMPMSW_01_Pwr voltage: 233.4
<Datum>_<Zeit> HMPMSW_01_Pwr 50: -
<Datum>_<Zeit> HMPMSW_01_Pwr boot: on
<Datum>_<Zeit> HMPMSW_01_Pwr energy: 153.8
<Datum>_<Zeit> HMPMSW_01_Pwr power: 80.85
<Datum>_<Zeit> HMPMSW_01_Pwr current: 384
<Datum>_<Zeit> HMPMSW_01_Pwr voltage: 232.2
<Datum>_<Zeit> HMPMSW_01_Pwr 50: -
<Datum>_<Zeit> HMPMSW_01_Pwr boot: on
<Datum>_<Zeit> HMPMSW_01_Pwr energy: 157.5
<Datum>_<Zeit> HMPMSW_01_Pwr power: 86.41
<Datum>_<Zeit> HMPMSW_01_Pwr current: 409
<Datum>_<Zeit> HMPMSW_01_Pwr voltage: 232.6
<Datum>_<Zeit> HMPMSW_01_Pwr 50: -
<Datum>_<Zeit> HMPMSW_01_Pwr boot: on

==== Channel 03 (_SenPwr) ====

Dieser Sensorkanal beinhaltet die Logik für eine automatische Schaltung aller angelernten Aktoren auf Basis des '''momentanen Leistungsverbrauchs''' (Überschreitung oder Unterschreitung) der angeschlossenen Verbraucher. Mittels der verfügbaren Register kann man genau einstellen, nach welchen Bedingungen aufgrund des '''momentanen Leistungsverbrauches''' ein Schaltbefehl gesendet werden soll.

Log-Datei des Kanals (verfügbaren Register):

<Datum>_<Zeit> HMPMSW_01_SenPwr R-cndTxCycBelow: 0
<Datum>_<Zeit> HMPMSW_01_SenPwr R-txThrLoPwr: 200 W
<Datum>_<Zeit> HMPMSW_01_SenPwr R-transmitTryMax: 6
<Datum>_<Zeit> HMPMSW_01_SenPwr R-cndTxCycAbove: 200
<Datum>_<Zeit> HMPMSW_01_SenPwr R-cndTxFalling: off
<Datum>_<Zeit> HMPMSW_01_SenPwr R-txThrHiPwr: 100 W
<Datum>_<Zeit> HMPMSW_01_SenPwr R-cndTxRising: off
<Datum>_<Zeit> HMPMSW_01_SenPwr R-ledOnTime: 0.5 s

Dieser Kanal dient nur zum auslesen und setzen der Register für die Schaltautomaik und stellt daher keine Readings oder spezielle Kommandos zur Verfügung.

<weiter Infos folgen>

==== Channel 04 (_SenI) ====

Dieser Sensorkanal beinhaltet die Logik für eine automatische Schaltung aller angelernten Aktoren auf Basis des '''momentanen Stromverbrauchs''' (Überschreitung oder Unterschreitung) der angeschlossenen Verbraucher. Mittels der verfügbaren Register kann man genau einstellen, nach welchen Bedingungen aufgrund des '''momentanen Stromverbrauchs''' ein Schaltbefehl gesendet werden soll.

Log-Datei des Kanals (verfügbaren Register):

<Datum>_<Zeit> HMPMSW_01_SenI R-cndTxCycBelow: 0
<Datum>_<Zeit> HMPMSW_01_SenI R-txThrLoCur: 20 mA
<Datum>_<Zeit> HMPMSW_01_SenI R-transmitTryMax: 6
<Datum>_<Zeit> HMPMSW_01_SenI R-cndTxCycAbove: 200
<Datum>_<Zeit> HMPMSW_01_SenI R-cndTxFalling: off
<Datum>_<Zeit> HMPMSW_01_SenI R-txThrHiCur: 10 mA
<Datum>_<Zeit> HMPMSW_01_SenI R-cndTxRising: off
<Datum>_<Zeit> HMPMSW_01_SenI R-ledOnTime: 0.5 s

Dieser Kanal dient nur zum auslesen und setzen der Register für die Abschaltautomatik und stellt daher keine Readings oder spezielle Kommandos zur Verfügung.

<weiter Infos folgen>

==== Channel 05 (_SenU) ====

Dieser Sensorkanal beinhaltet die Logik für eine automatische Schaltung aller angelernten Aktoren auf Basis der aktuell anliegenden '''elektrischen Spannung''' (Überschreitung oder Unterschreitung). Mittels der verfügbaren Register kann man genau einstellen, nach welchen Bedingungen auf Basis der '''elektrischen Spannung''' ein Schaltbefehl durchgeführt werden soll.

Log-Datei des Kanals (verfügbaren Register):

<Datum>_<Zeit> HMPMSW_01_SenU R-cndTxCycBelow: 0
<Datum>_<Zeit> HMPMSW_01_SenU R-transmitTryMax: 6
<Datum>_<Zeit> HMPMSW_01_SenU R-txThrLoVlt: 24 V
<Datum>_<Zeit> HMPMSW_01_SenU R-cndTxCycAbove: 200
<Datum>_<Zeit> HMPMSW_01_SenU R-cndTxFalling: off
<Datum>_<Zeit> HMPMSW_01_SenU R-txThrHiVlt: 22 V
<Datum>_<Zeit> HMPMSW_01_SenU R-cndTxRising: off
<Datum>_<Zeit> HMPMSW_01_SenU R-ledOnTime: 0.5 s

<weiter Infos folgen>

==== Channel 06 (_SenF) ====

Dieser Sensorkanal beinhaltet die Logik für eine automatische Schaltung aller angelernten Aktoren auf Basis der '''Frequenz''' (Überschreitung oder Unterschreitung) der anliegenden Spannung. Mittels der verfügbaren Register kann man genau einstellen, nach welchen Bedingungen auf Basis der '''Frequenz''' ein Schaltbefehl durchgeführt werden soll.

Die Abschaltung erfolgt dann selbstständig durch den Aktor.

Log-Datei des Kanals (verfügbaren Register):

<Datum>_<Zeit> HMPMSW_01_SenF R-cndTxCycBelow: 0
<Datum>_<Zeit> HMPMSW_01_SenF R-txThrHiFrq: 49.8 Hz
<Datum>_<Zeit> HMPMSW_01_SenF R-txThrLoFrq: 50.2 Hz
<Datum>_<Zeit> HMPMSW_01_SenF R-transmitTryMax: 6
<Datum>_<Zeit> HMPMSW_01_SenF R-cndTxCycAbove: 200
<Datum>_<Zeit> HMPMSW_01_SenF R-cndTxFalling: off
<Datum>_<Zeit> HMPMSW_01_SenF R-cndTxRising: off
<Datum>_<Zeit> HMPMSW_01_SenF R-ledOnTime: 0.5 s

Dieser Kanal dient nur zum auslesen und setzen der Register für die Abschaltautomatik und stellt daher keine Readings oder spezielle Kommandos zur Verfügung.

<weiter Infos folgen>

=== event Monitor ===
<Bitte ergänzen>

=== fhem.log Auszug ===

2013.12.29 19:06:11.957 3: CUL_HM Unknown device CUL_HM_HM_ES_PMSw1_Pl_24A920, please define it
2013.12.29 19:06:11.976 2: autocreate: define CUL_HM_HM_ES_PMSw1_Pl_24A920 CUL_HM 24A920 A1A5B840024A9200000001400AC4B455130393635383038513F0100
2013.12.29 19:06:11.994 2: autocreate: define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920 FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920
2013.12.29 19:06:16.879 3: Device CUL_HM_HM_ES_PMSw1_Pl_24A920 added to ActionDetector with 000:10 time
2013.12.29 19:06:16.889 3: CUL_HM pair: CUL_HM_HM_ES_PMSw1_Pl_24A920 powerMeter, model HM-ES-PMSw1-Pl serialNr KEQ0965808
2013.12.29 19:06:16.998 3: Device CUL_HM_HM_ES_PMSw1_Pl_24A920 added to ActionDetector with 000:10 time
2013.12.29 19:06:17.905 2: autocreate: define CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw CUL_HM 24A92001
2013.12.29 19:06:17.909 2: autocreate: define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw
2013.12.29 19:06:18.906 2: autocreate: define CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr CUL_HM 24A92002
2013.12.29 19:06:18.909 2: autocreate: define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr
2013.12.29 19:06:19.906 2: autocreate: define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr CUL_HM 24A92003
2013.12.29 19:06:19.909 2: autocreate: define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr
2013.12.29 19:06:20.906 2: autocreate: define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI CUL_HM 24A92004
2013.12.29 19:06:20.910 2: autocreate: define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI
2013.12.29 19:06:21.907 2: autocreate: define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU CUL_HM 24A92005
2013.12.29 19:06:21.974 2: autocreate: define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU
2013.12.29 19:06:22.096 2: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_24A920 getConfig
2013.12.29 19:06:22.917 2: autocreate: define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF CUL_HM 24A92006
2013.12.29 19:06:22.921 2: autocreate: define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF
2013.12.29 19:06:28.968 2: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw statusRequest
2013.12.29 19:06:29.980 2: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU getConfig
2013.12.29 19:06:33.990 2: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF getConfig

=== fhem.cfg ===
<pre>define CUL_HM_HM_ES_PMSw1_Pl_24A920 CUL_HM 24A920
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 .devInfo 3F0100
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 .stc 51
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 IODev LANCUL
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 actCycle 000:10
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 actStatus alive
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 autoReadReg 4_reqStatus
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 expert 2_full
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 firmware 1.4
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 model HM-ES-PMSw1-Pl
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 peerIDs
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 room CUL_HM
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 serialNr KEQ0965808
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 subType powerMeter
attr CUL_HM_HM_ES_PMSw1_Pl_24A920 webCmd getConfig

define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920 FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920 logtype text
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920 room CUL_HM

define CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw CUL_HM 24A92001
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw expert 1
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw model HM-ES-PMSw1-Pl
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw peerIDs 00000000,
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw room CUL_HM

define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw logtype text
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Sw room CUL_HM

define CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr CUL_HM 24A92002
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr expert 1
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr model HM-ES-PMSw1-Pl
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr peerIDs
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr room CUL_HM

define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr logtype text
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_Pwr room CUL_HM

define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr CUL_HM 24A92003
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr expert 1
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr model HM-ES-PMSw1-Pl
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr peerIDs 00000000,
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr room CUL_HM

define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr logtype text
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenPwr room CUL_HM

define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI CUL_HM 24A92004
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI expert 1
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI model HM-ES-PMSw1-Pl
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI peerIDs 00000000,
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI room CUL_HM

define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI logtype text
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenI room CUL_HM

define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU CUL_HM 24A92005
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU expert 1
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU model HM-ES-PMSw1-Pl
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU peerIDs 00000000,
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU room CUL_HM

define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU logtype text
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenU room CUL_HM

define CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF CUL_HM 24A92006
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF expert 1
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF model HM-ES-PMSw1-Pl
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF peerIDs 00000000,
attr CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF room CUL_HM

define FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF FileLog /usr/local/FHEM/var/log/CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF-%Y.log CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF logtype text
attr FileLog_CUL_HM_HM_ES_PMSw1_Pl_24A920_SenF room CUL_HM
</pre>

=== Plots/Grafiken ===

Hier ein Beispielplot für den Channel 02 (Pwr):

[[Datei:HM-ES-PMSw1-PI cut.jpg|Plot des HM-ES-PMSw1-PI (Channel 02)]]

Inhalt der zugehörigen gplot-Datei (SVG_FileLog_HMPMSW_01_Pwr_1.gplot):

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 '<TL>'
set ytics
set y2tics
set grid
set ylabel "Energie"
set y2label "Power"

#FileLog 4:HMPMSW_01_Pwr.energy\x3a::
#FileLog 4:HMPMSW_01_Pwr.power\x3a::

plot "<IN>" using 1:2 axes x1y1 title 'Energie' ls l0 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Power' ls l1 lw 1 with lines

und die Definitionen dafür beim Device (fhem.cfg):

define SVG_FileLog_HMPMSW_01_Pwr_1 SVG FileLog_HMPMSW_01_Pwr:SVG_FileLog_HMPMSW_01_Pwr_1:CURRENT

== Tipps ==

Um dafür zu sorgen, dass nach einem Stromausfall der Aktor den Schaltausgang von sich aus auf "An" stellt (per default "Aus"), kann man wie folgt vorgehen:

#1: Device auf übliche Weise mit Fhem pairen

#2: Interne Peers/Register für Fhem aktivieren:
set <deviceName> regSet intKeyVisib visib

#3: Erneutes getConfig auf das Device durchführen
set <deviceName> getConfig

#4: Ch01 (Sw) mit Ch05 (SenU) peeren:
set <deviceName>_SenU peerChan 0 <deviceName>_Sw single set

#5: Erneutes getConfig auf das Device durchführen
set <deviceName> getConfig

#6: Register auf Ch01 (Sw) setzen:
set <deviceName>_Sw regSet lgSwJtDlyOff on self01
set <deviceName>_Sw regSet lgSwJtOn on self01
set <deviceName>_Sw regSet shSwJtDlyOff on self01
set <deviceName>_Sw regSet shSwJtOn on self01
set <deviceName>_Sw regSet lgSwJtDlyOff on self05
set <deviceName>_Sw regSet lgSwJtOn on self05
set <deviceName>_Sw regSet shSwJtDlyOff on self05
set <deviceName>_Sw regSet shSwJtOn on self05

#7: Register auf Ch05 (SenU) setzen:
set <deviceName>_SenU regSet cndTxRising on
set <deviceName>_SenU regSet txThrHiVlt 200
set <deviceName>_SenU regSet txThrLoVlt 180

== Links ==
* [http://www.elv-downloads.de/Assets/Produkte/13/1302/130248/Downloads/130248_schaltaktor_messfunktion_um.pdf Manual]
* [http://www.elv-downloads.de/Assets/Produkte/13/1302/130248/Downloads/130248_schaltaktor_messfunktion_data.pdf Datenblatt]
* [http://www.eq-3.de/produkt-detail-aktoren/items/homematic-funk-schaltaktor-1-fach-mit-leistungsmessung-zwischens.html Produktinfo]

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

Trick der Woche

2015-01-14T12:42:44Z

Rohan: /* CUL & CO über Serial ID einbinden */ Kleinigkeiten bereinigt

Diese Seite enthält Tipps und Tricks, die zu unbedeutend sind, einen eigenen Artikel zu rechtfertigen, alternative Schreibweisen/Lösungen für eine Problem darstellen, Ungenauigkeiten oder unklare Formulierungen in den offiziellen Dokumenten ergänzen und ähnliches. Jeder Eintrag ist typischerweise sehr kurz (wenige Zeilen lang) und beleuchtet vielleicht nur einen Aspekt von Fhem, er kann allgemeiner Natur sein, oder sich auf ein spezielles Gerät oder einen speziellen Anwendungsfall beziehen. Dieser Artikel wendet sich eher an den Anfänger.
== Januar 2015 ==
=== CUL & CO über Serial ID-einbinden ===
Bei mehreren USB-Geräten kann es vorkommen, dass sie vertauscht werden z.B. ''/dev/ttyUSB0'' zu'' /dev/ttyUSB1'' oder ''/dev/ttyACM0'' zu ''/dev/ttyACM1''.

Um dies zu umgehen, kann man sie über ihre Serial-ID in Fhem einbinden.

Dieser Befehl zeigt die Serial-ID:

:<code>ls -l /dev/serial/by-id</code>

Hier die Beispielausgabe eines CUL868, JeeLink, RFXtrx und eines CUL433

user@xxxx:~# ls -l /dev/serial/by-id
lrwxrwxrwx 1 root root 13 Jan 9 23:34 usb-busware.de_CUL868-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0-> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-RFXCOM_RFXtrx433_A1WZWL5Y-if00-port0-> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jan 9 21:29 usb-busware.de_CUL433-if00 -> ../../ttyACM1

Damit lässt sich folgende Definition erstellen:

z.B. für einen CUL868

:<code>define CUL868 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1134</code>

oder einen JeeLink

:<code>define Jeelink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0@57600</code>

'''Einschränkung:''' Bei CULs von Busware lassen sich nur CUL433 und CUL868 unterscheiden. Zwei CUL868 haben z.B. immer die gleiche Serial-ID.

== August 2014 ==
=== Perl-Skripte Online testen ===
Im Internet existieren Webseiten auf denen man Perl-Code online testen kann. Beispielsweise auf [http://www.compileonline.com/execute_perl_online.php www.compileonline.com] kann man Code zum Testen eingeben und die Auswirkungen betrachten. Dies eignet sich zur schnellen Fehleranalyse oder um Perl zu lernen. Natürlich lassen sich keine Fhem-Besonderheiten nutzen.

== Juli 2014 ==
=== Funklast reduzieren===
Bewegungsmelder erzeugen in der Regel eine recht hohe Funklast, wenn sie oft ausgelöst werden, also z.b. Licht in einem Zimmer schalten sollen.

Konstruktionen der Art:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* set Licht_Flur on-for-timer 256</code>
haben daher den Nachteil bei viel Bewegung im Flur und je nach Einstellung des Sendeabstandes des Bewegungsmelders mindestens alle 120 Sekunde oder öfter ein
:<code>on-for-timer 256</code>
zu senden. Das erzeugt eine hohe Funklast, speziell wenn der Aktor ein SlowRF Gerät ist (z.b. FS20 Unterputzschalter).
In solchen Fällen kann es helfen, nur dann einen Befehl zu senden, wenn das Licht nicht schon an ist:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur") eq "off") { fhem ("set Licht_Flur1 on-for-timer 256") } }</code>
Nachteilig ist aber, dass eine Auslösung innerhalb 256 Sekunden die Einschaltzeit nicht verlängert. Dies kann man umgehen, indem man nicht on-for-timer verwendet, sondern den Aktor selber verzögert auschaltet und bei weiteren Auslösungen nur die Verzögerung erneut anlegt:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur1") eq "off") { fhem ("set Licht_Flur on ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") } else { fhem ("delete FlurLicht_aus ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") }}</code>

== Juni 2014 ==
=== Batteriestatus bei HomeMatic Devices aktivieren===
Zumindest einige (wenn nicht alle) batteriegespeisten HM-Geräte können Batteriemeldungen senden, tun dies in der normalen Konfiguration aber nicht.
Dazu muss das Register cyclicInfoMsg auf on gesetzt werden.

Wie man das macht steht z.b. hier
[[HM-SEC-SC_Tür-Fensterkontakt#Batteriestatus_aktivieren]]
und hier
[[HomeMatic_Type_ThreeState]]

== Mai 2014 ==
=== Dummywert mit aktueller Uhrzeit versehen in anderen Dummy kopieren===
Der Inhalt von Dummy1 soll erweitert um Uhrzeit und Datum in Dummy2 kopiert werden (z.b. um die Urzeit der letzten Auslösung einer Alarmanlage anzuzeigen)
:<code>{ fhem("set dummy2 " . (Value("Dummy1")." ".TimeNow()) ) } </code>

=== Zwei Dummywerte in einen anderen Dummy kopieren ===
Der String in Dummy1 soll um den String in Dummy2 erweitert und nach Dummy3 kopiert werden:
:<code>{ fhem("set Dummy3 ".(Value("Dummy1")+Value("Dummy2"))) } </code>
(Achtung: "+" ist Zahlen addieren, "." ist String konkatenieren)

== April 2014==
=== Code sparen ===
Wer Definitionen wie die aus dem März zum [[Trick der Woche#Zuverlässigkeit von FS20 Schaltungen erhöhen|Abfangen von Fehlbedienungen]] verwendet, kann durch eine ELSE Erweiterung auch gleich das Auschalten erledigen.
:<code>define act_on_TV_on notify TV { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") } else { fhem("set TV off") } }</code>

Hierdurch schaltet ON oder versehentlich zu langes Drücken (also DIMUP) den Fernseher ein, jeder ''andere'' Tastendruck (also insbesondere die OFF Taste oder zu langes Drücken der OFF Taste -> DIMDOWN) den Fernseher aus.

Voraussetzung ist, dass die Fernbedienung standardkonfiguriert ist, siehe auch nächster Tip.

=== Konfiguration eines FS20 Senders prüfen ===
Gelegentlich reagieren bestimmte notifys nicht, die von Sendern (Fernbedienungen, Sensoren oder Schaltern) ausgelöst werden sollen. Speziell bei FS20 aber auch bei HomeMatic kann das daran liegen, dass der Sender nicht sendet was man denkt. So gut wie alle FS20 Sender kennen nämlich nicht nur ON und OFF, sondern über ein Dutzend Schaltzustände. Dimmen ist einem noch hinreichend bewusst, es gibt aber auch exotische Dinge wie Ein-für-Zeitdauer, Ein-auf-alte-Helligkeit, Aus-für-Zeitdauer (nur FS20), Ein-für-Zeitdauer-dannach-alter-Zustand und vieles mehr.

Was also ein Infrarot-Bewegungsmelder bei Auslösung sendet und auch was eine Fernbedienungstaste sendet ist einstellbar. Wenn jetzt zum Beispiel an einer Fernbedienung auf Tastendruck nicht ON sondern Ein-für-Zeitdauer (ON-FOR-TIMER) gesendet wird, wird
:<code>define act_on_TV_on notify TV:on set TV on</code>
seltsamerweise nicht auslösen, obwohl die richtige Taste (und diese auch nicht zu lang) gedrückt wurde.

Auch wenn man sich sicher ist, das Richtige in die Fernbedienung/Sensoren einprogramiert zu haben, ist ein einfacher Test immer, dies mit
:<code>define act_on_TV notify TV set TV on</code>
zu prüfen. Dieses notify löst immer aus, wenn "TV" ''irgendetwas'' sendet, egal was. (Beachte: Man kann dann den Fernseher aber nicht mehr ausschalten, da auch die Austaste das notify auslöst und zum TV-Aktor nur "on" sendet). Geht die Schaltung jetzt (kann man den Fernseher also jetzt EINschalten), liegt der Verdacht nahe, dass die Konfiguration des Senders / Sensors anders ist, als man denkt. Das Logfile gibt Aufschluss, welcher Befehl tatsächlich empfangen wurde.

=== Alles in FHEM, nichts in der Fernbedienung ===
Versuche in deiner FHEM Umgebung nicht, das Verhalten von Aktoren durch entsprechende Befehle aus Sensoren oder Fernbedienungen zu steuern. An Besten senden die nur ON und OFF oder DIM, den Rest möglichst immer in FHEM erledigen.

Wer eine Lampe immer für vier Minuten einschalten will, programmiert seinen Schalter (Fernbedienung) also so, das nur "on" gesendet wird und erledigt den Rest in FHEM:
:<code>define act_on_Schalter notify Schalter set Lampe-on-for-timer 240</code>

== März 2014==
=== Zuverlässigkeit von FS20 Schaltungen erhöhen ===
FS20 Fernbedienungen senden bei Tastendrücken von mehr als 0,4 Sekunden anstatt ON bzw. OFF DIMUP bzw DIMDOWN.

Das führt gelegentlich zu allgemein schlechter Bedienbarkeit (und schlechtem WAF), da 0,4 Sekunden relativ kurz ist und gerne aus versehen länger gedrückt wird. Das ist vor allem problematisch, wenn etwas geschaltet werden soll, was keinen Dimmer hat oder Dimmen nicht unterstützt.

Eine Konfiguration wie
:<code>define act_on_TV_on notify TV:on set TV on</code>
hat also dann den Nachteil, dass bei versehentlich zu langem Tastendruck das TV nicht angeht. Da die meisten Nutzer unbewusst dazu neigen, bei Misserfolg die selbe Taste erneut aber länger zu drücken (was erneut keinen Erfolg zeigt) ist Frustration zu erwarten.

Es kann daher speziell bei nicht dimmbaren Aktoren von Vorteil sein, auch dimmen abzufangen, z.b. durch eine zweite zusätzliche Definition:

:<code>define act_on_TV_dimup notify TV:dimup set TV on</code>

Es ist in der Regel einfacher, einige dieser zusätzlichen Definitionen einzufügen, als allen Bedienern des Systems zu erklären, dass man keinesfalls länger als 0,4 Sekunden drücken darf.

Alternativ kann man auch beide Befehle in einer Definition durch Perlbefehle {} abfangen:

:<code>define act_on_TV_on notify TV { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") }}</code>

Andere Möglichkeiten vergleiche: [[Trick der Woche#notify durch mehrere Ereignisse auslösen lassen|Notify durch mehrere Ereignisse auslösen lassen]]

== Februar 2014==
=== Sequence nutzen ===
Man kann Aktionen statt mit einem Tastedruck auch mit einer Sequenz von Tastendücken auslösen. Das Format des Befehle ist:

:<code>define <name> sequence <re1> <timeout1> <re2> [<timeout2> <re3> ...] </code>

wobei <re1> ...<re_n> die Aktionen sind und <timeout_n> der maximale Abstand der Tastendrücke in Sekunden.

Angenommen, man wolle z.B. eine Lampe dann anschalten, wenn man zuerst Taste1 EIN, dann Taste2 AUS und dann wieder Taste1 EIN einer Fernbedienung drückt, könnte das konkret so aussehen:

:<code>define MeineLampenSequenz1 sequence Btn1:on 0.5 Btn2:off 0.5 Btn1:on</code>

Zwischen jedem der Tastendrücke darf eine halbe Sekunde Abstand sein. Diese Definition selbst löst die Lampe nicht aus, sondern definiert nur wie die Sequenz aussehen soll. Um die Lampe bei erfolgreicher Betätigung der Sequenz auch einzuschalten, bedarf es zusätzlich etwas wie:

:<code>define MeineLampe notify MeineLampenSequenz1:trigger set Lampe on</code>

Sequence kann man gut nutzen, um mit einer Fernbedienung mehr Funktionen zu schalten als Tasten zur Verfügung stehen. Ebenso könnte man damit simple Codeschlösser für Alarmanlagen bauen, z.b. um eine Anlage auszuschalten, wenn eine bestimmte Abfolge von Tasten gedrückt wird.

Je nach Funksystem nimmt die Zuverlässigkeit aber rasch ab. Angenommen im Bereich FS20 (das System ist etwas unzuverlässiger ist als z.b. HomeMatic) seien 95% aller Funktsignale ungestört übertragbar, dann würden in der Praxis von 100 Tastendrücken an einer Fernbedienung 95x Erfolg zeigen und 5x fehlschlagen; das ist sicher tolerabel.

Bei einer Sequenzlänge von nur 4 Tasten würde die kombinierte Erfolgsquote der Sequenz jedoch nur noch ca. 80% sein, zum Ausschalten einer Alarmanlage vermutlich bereits unpraktisch.

== Januar 2014==
===isday===
Bekanntlich kann man mit "isday" leicht testen ob es draussen hell ist oder nicht. isday ist eine Funktion des (automatisch geladenen) 99_SUNRISE_EL.pm Moduls das auch sunset und sunrise enthält.

Problematisch bei isday ist die fehlende Möglichkeit, Sonnenaufgang und Untergang einzustellen (zumindest wenn man nicht 99_SUNRISE_EL.pm verändern will): isday ist wahr, wenn die Sonne im gegebenen Breitengrad sichtbar ist. Wenn örtliche Gegebenheiten eine Anpassung erfordern, kann man sich auch ein eigenes isday basteln, in dem man sunrise und sunset verwendet und dieses mit getrennten offsets versieht.

Zuerst definiert man sich eine Variable ("dummy") der anstelle isday eingesetzt werden soll, z.b.:

:<code>define Tageslicht dummy </code>

Dann wird diese mit sunset und sunrise befüllt:

define SetDummy1 at *{sunset(-3600)} set Tageslicht hell
define SetDummy2 at *{sunrise(+1800)} set Tageslicht dunkel

Jetzt kann für jeden Wechsel ein eigener Offset gewählt werden, im Beispiel 3600 Sekunden vor Sonnenuntergang und 1800 Sekunden nach Sonnenaufgang. Anstatt das Dummy "Tageslicht" mit den Werten "hell/dunkel" zu befüllen, kann natürlich auch 1/0 oder "Tag/Nacht" etc. verwendet werden, je nach dem was bei der Anwendung besser passt.

Für höhere Ansprüche könnte hingegen das Twiglight-Modul verwendet werden, das Dämmerungsstufen kennt.

===Struktur von "else if" Schleifen===
define ... notify ... {\
if ... {\
fhem ("... ;; ...")\
}\
elsif {\
if ... {\
fhem ("... ;; ...")\
}\
elsif {\
if ... {\
fhem ("... ;; ...")\
}\
else {\
if ... {\
fhem ("... ;; ...")\
}\
}}}}

Achtung: es muss tatsächlich "elsif" heissen und nicht "elseif" oder "else if"

== Dezember 2013==
===notify durch mehrere Ereignisse auslösen lassen===
Bekanntermassen löst

:<code>define irgendwas notify MeinSchalter …</code>

aus, wenn irgendein Ereignis vom Sender "MeinSchalter" eintrifft.

Mit

:<code>define irgendwas notify MeinSchalter:on …</code>

wird das notify jedoch nur ausgelöst, wenn dieses Ereignis eine "on" ist.
Wenn man aber möchte, das z.B. "on" und "off" auslöst (um etwa Dim-Befehle auszuschliessen) kann dies wie folgt erreicht werden:

:<code>define irgendwas notify MeinSchalter:(on|off) …</code>

Die Klammern sind wichtig, vergleiche eine Lösung, bei der zwei Sender alternativ das notify auslösen können:

:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter:on …</code>

Selbstverständlich geht z.B. auch folgendes:

:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter …</code>

Hier wird ausgelöst wenn "MeinSchalter" das Ereignis "on" liefert oder "MeinAndererSchalter" irgendein Ereignis

=== Aktoren über mehrere Funkschnittstellen ansprechen ===
Falls man mehrere Funkschnittstellen zur Reichweitenverlängerung hat (CUL / CUNO etc), und ein Aktor von beiden Funkschnittstellen in etwa gleich (schlecht) erreichbar ist, mag der Wunsch aufkommen, einen Funkbefehl über beide Schnittstellen auszusenden. Dies ist bei Funkprotokollen möglich, die kein echtes Pairing der Aktoren an die Funkschnittstelle erfordern, also z.b. FS20 oder Intertechno, nicht jedoch bei HomeMatic.

Problematisch ist aber, dass die Funkschnittstelle über IODev eindeutige je Aktor festgelegt werden muss, eine Zuordnung mehrerer IODevs ist nicht vorgesehen.
(wenn man IODev nicht setzt, wird per default die LETZTE definiert Schnittstelle verwendet)

Diess Problem kann mit einem Trick aber umgangen werden. Und zwar legt man den Aktor 2x mit gleicher Adresse aber abweichenden Namen und IOdevs an, z.b. so:

define brenner_CUL1 FS20 11114244 11
attr brenner_CUL1 IODev CUL1
attr brenner_CUL2 room Keller

define brenner_CUL2 FS20 11114244 11
attr brenner_CUL2 IODev CUL2
attr brenner_CUL2 room Keller

Ein Befehl der Art:

set brenner_CUL1,brenner_CUL2 on

sendet den ON Befehl für den FS20 Aktor 11114244 11 jetzt tatsächlich über beide CULs aus!

Achtung: Wenn die Schnittstellen gleichschnell angebunden sind, sollte vermutlich der [[Sendpool]] verwendet werden, da die Aussendungen sonst tatsächlich gleichzeitig erfolgen könnten und sich dann gegenseitig stören würden.

=== Retrycount bei FHTs ist überflüssig===
Das von der Funktion ''autocreate'' älterer FHEM Versionen beim Anlegen von FHT80 Heizungsreglern voreingetragene attribute "retrycount" hat in den allermeisten Fällen keine Wirkung, da es NUR greift, wenn man als Funkschnittstelle eine FHZ1X00PC verwendet und dann den Softbuffer einschaltet. Selbst wenn man diese Konfiguration nutzt, will gut überlegt werden, ob die Wirkung postiv ist: Bei ungenügender Empfangslage vergrössert es Kommunikationsprobleme eventuell sogar.

Es kann also in der Regel entfernt oder auf den Wert "1" gesetzt werden.

define Heizung_Bad FHT 060d
attr Heizung_Bad retrycount 3 <=== Diese Zeile entfernen

Siehe auch:[[Kommunikationsprobleme mit FHT]]

== November 2013 ==
=== FS20 Funksteckdose sicherer schalten===
Seltsamerweise kommt es vor, das FS20 Aktoren - insbesondere die FS20 Funksteckdose - an der Grenze der Funkreichweite bestimmte Befehle eines Typs empfängt, andere aber nicht. Z.B. lässt sich die FS20 Steckdose zwar immer einschalten, aber oft nicht mehr aus (oder umgekehrt).

Gelegentlich kann man die Zuverlässigkeit erhöhen, indem man statt dem nicht funktionierenden Befehl das Gegenteil mit "for-timer 1" verwendet.

Im Fall, dass eine FS20 Steckdose sich also einwandfrei EINschalten lässt:
:<code>set SteckdoseA on</code>
aber oft ein AUSschalten mittels
:<code>set SteckdoseA off</code>
nicht funktioniert, kann man versuchen die Dose anstelle mit "off" mit dem Befehl
:<code>set SteckdoseA on-for-timer 1</code>
auszuschalten.

Analog kann man mit off-for-timer arbeiten, wenn sich Aktoren nicht einschalten lassen, ausschalten aber geht.

Achtung: Dieser Trick funtioniert ausdrücklich nur, wenn der "on/off-for-timer" Befehl im Aktor selber abgebildet wird. Daher ist der Trick vermutlich nicht auf andere Funksysteme übertragbar.

=== Mehrere Geräte zugleich schalten===
Ein Ereignis soll mehrere Geräte schalten:

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on;;set Lampe2 on;;set FunksteckdoseA on</code>

Aus Übersichtlichkeitsgründen können vor und nach den Semikolons auch Leerzeichen eingefügt werden (obwohl in einigen Dokumentation behauptet wird, dies dürfe man nicht machen):

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on ;; set Lampe2 on ;; set FunksteckdoseA on</code>

Wenn der Schaltbefehl bei allen Geräten gleich ist, kann man wie folgt zusammenfassen:

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1,Lampe2,FunksteckdoseA on</code>

Das Komma wird nicht [[Escapen in Perlbefehlen|escaped]] (verdoppelt), hier darf tatsächlich KEIN Leerzeichen vor oder nach dem Komma eingefügt werden.

=== Logfileinträge unterdrücken===
Das Attribute "verbose 0" verhindert, dass das Gerät Logfileinträge erzeugt.

Beispiel:

define Funksteckdose FS20 22224222 01
attr Funksteckdose verbose 0

===FHT Lazy Mode benutzen===
Es gibt wenig Gründe, den FHT "Lazy Mode" nicht zu verwenden
define Heizung_Bad FHT 060d
attr Heizung_Bad lazy

Dieser sorgt dafür, dass Temperaturänderungen (genau genommen alle Änderungen, auch z.B. date) nur übertragen werden, wenn sie nicht sowieso schon am FHT eingestellt sind und veringern die Funklast dadurch deutlich.

Siehe auch: [[Kommunikationsprobleme mit FHT]]

== Oktober 2013 ==
=== Zuverlässigkeit von Wiedereinschalten erhöhen ===
Speziell bei FS20 Aktoren ist wegen des fehlenden Rückkanals nicht leicht erkennbar, ob ein Einschaltbefehl Wirkung gezeigt hat. Das hat ganz schlechten WAF, wenn man z.B. mit einem FS20 Aktor eine Heizung ausschaltet und das Wiedereinschalten nach z.B. einer Stunde nicht klappt.

Hier empfiehlt es sich, das Ausschalten mittels
:<code>set Heizungs_schalter off-for-timer 3584</code> (= fast eine Stunde)
zu erledigen. Da bei FS20 der off-for-timer Befehl im Aktor abgewickelt wird (und nicht durch FHEM), schaltet sich der Aktor auch dann garantiert wieder ein, wenn Fhem abstürzt, eine Funkstörung vorliegt oder ähnliches. Bei Bedarf kann der Befehl off-for-timer zur Verlängerung der Ausschaltzeit wiederholt werden. Dies kann z.B. nötig sein, wenn die Ausschaltung länger als 4,5 Stunden (15360 Sekunden, der Maximalwert des Timers) dauern soll.

Achtung: dieser Trick funktioniert nur, wenn der Aktor "off-for-timer" selbst beherrscht. FS20 Geräte können das, HomeMatic können aber nur "on-for-timer". Man kann off-for-timer mit HomeMatic trotzdem verwenden, aber in diesem Fall sendet Fhem den Einschaltbefehl nach der Timerzeit. InterTechno, RSL etc, können gar keinen Timer, hier sendet Fhem immer 2 Befehle im passenden Abstand.

=== FS20 Timerzeiten ===
FS20 Timer werden in Sekunden angegeben. Es sind jedoch nicht alle Werte einstellbar. Da der Timer Wert in 7 Bit übertragen werden muss, sind nur 128 Werte möglich. Um mit diesen Werten im unteren Bereich möglichst fein aufzulösen, andererseits aber auch lange Zeiten zu ermöglichen, ist die Verteilung nicht linear. Einstellbar sind folgende Zeiten in Sekunden;

0,25 0,5 0,75 1 1,25 1,5 1,75 2 2,25 2,5 2,75 3 3,25 3,5 3,75
4 4,5 5 5,5 6 6,5 7 7,5 8 9 10 11 12 13 14 15 16 18 20 22
24 26 28 30 32 36 40 44 48 52 56 60 64 72 80 88 96 104 112
120 128 144 160 176 192 208 224 240 256 288 320 352 384 416
448 480 512 576 640 704 768 832 896 960 1024 1152 1280 1408
1536 1664 1792 1920 2048 2304 2560 2816 3072 3328 3584 3840 4096
4608 5120 5632 6144 6656 7168 7680 8192 9216 10240 11264 12288
13312 14336 15360
(etwas übersichtlicher formatiert auch [[FS20 Allgemein#ON/OFF Befehle mit Time Parameter|hier]]).

Andere Zeiten werden von Fhem gerundet. Ein neues Setzen des Timer für FS20 löscht den alten Wert.

===Butterflecken in Wollpullovern===
Butterflecken in Wollpullovern können leicht durch grossflächiges Aufstreichen von Teer beseitigt werden.

HM-LC-BL1-FM Funk-Jalousieaktor

2015-01-13T19:30:14Z

Rohan: Hinweis zum Verändern des Tasterverhaltens eingebaut

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=HomeMatic Unterputz Funk Rollladenaktor
|HWProtocol=HomeMatic
|HWType=Aktor
|HWCategory=HomeMatic
|HWComm=868 MHz
|HWChannels=1
|HWVoltage=230V
|HWPowerConsumption=<0,5W (Ruhebetrieb)
|HWPoweredBy=Netz
|HWSize=53x53x30mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

Homematic Funk-Jalousieaktor 1-fach (Unterputz)

== Features ==
Schalten eines angeschlossenen Jalousiemotors mittels [[CUL]]/CUN/[[HMLAN Konfigurator]] und über einen mechanischen spannungsfesten Taster.

'''Technische Daten:'''
* Schaltvermögen: 250W Motorlast 230V/50Hz
* Relais: 1x Schließer und 1 Wechsler
* Standby Verbrauch: 0,5W
* Maße(BxHxT): 53x53x30mm

== Installation ==
Will man die Funk-Schaltaktoren auch manuell betreiben, so sind Taster notwendig. Schalter können notfalls mittels einer zusätzlichen Feder zum Taster umgebaut werden, Tastschalter sind nicht geeignet. Schalter und Tastschalter führen dazu, dass der Aktor nach Betätigung des Schalters in den Anlernmodus versetzt wird und auch in diesem verbleibt.

Je nach vorhandenen Schalterdosen empfiehlt es sich, bestehende Schalterdosen nach hinten auszuweiten, d.h. die Abdeckung nach hinten heraus zu brechen, da die Aktoren und Kabel nicht gerade sparsam mit dem Platz umgehen. Alternativ kann der Aktor auch in einer zusätzlichen Schalterdosen untergebracht und diese mit einem Federdeckel verschlossen werden. Dies hat den Vorteil, dass auch durch eine relativ dicke Tapete die LED und somit der Zustand des Aktors erkannt werden kann.

== Hinweise zum Betrieb mit FHEM ==
Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden. Hierfür wird ein am Aktor temporär angeschlossener spannungsfester Taster zwingend benötigt oder es erfolgt über Fhem mittels der Seriennummer.

=== Konfiguration ===
Ein exemplarischer Auszug aus der [[Konfiguration]] (fhem.cfg):

<pre>
define JalousieWohnzimmer CUL_HM 17E43C
attr JalousieWohnzimmer devInfo 010100
attr JalousieWohnzimmer firmware 1.5
attr JalousieWohnzimmer hmClass receiver
attr JalousieWohnzimmer model HM-LC-BL1-FM
attr JalousieWohnzimmer room Wohnzimmer
attr JalousieWohnzimmer serialNr IEQ0xxxxxx
attr JalousieWohnzimmer subType blindActuator
</pre>

=== Mögliche Schaltoperationen ===
Der Aktor versteht folgende Aktionen:

<pre>
set <name> on -> Schaltet den Aktor ein
set <name> off -> Schaltet den Aktor aus
set <name> toggle -> Ändert den logischen Zustand des Aktors, d.h. ein eingeschalteter Aktor wird ausgeschaltet. Im Falle der 10% geöffneten Jalousie wird diese geschlossen.
set <name> <Zweistellige Zahl> -> Schaltet den Aktor ein und öffnet die Jalousie um <Zweistellige Zahl>%. 100% entspricht dabei einem "on"
</pre>

=== Fahrtzeiten 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 drei Zeiten werden in Sekunden gemessen und anschließend einmalig mit den folgenden Befehlen eingestellt:

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

Wichtig: Danach unbedingt am Aktor auf Anlernen drücken, damit er die regSets abarbeiten kann. Ob alles geklappt hat, kann überprüft werden mit:
<pre>
set <name> getConfig
get <name> reg all
</pre>
Dort sollten dann die Werte stehen, z.B.
<pre>
WZ_Jal_Rechts type:blindActuator -
list:peer register :value
0: intKeyVisib :invisib
0: pairCentral :0xE1F88A
1: driveDown :27 s
1: driveTurn :0.5 s
1: driveUp :27 s
1: refRunCounter :0
1: sign :off
</pre>

wenn noch z.B. bei driveDown steht <code>set_27</code>, dann hat es noch nicht geklappt, dann müsst ihr nochmal anlernen drücken.
Und am besten jetzt nochmal im Eingabefeld in fhem ein "save" absetzen. Wenn ihr die Konfiguration des Schalters für Euch als Textdatei speichern wollt, dann hilft Euch ein
:<code>get <name> saveConfig <dateiname></code>

Das legt dann eine Datei in Eurem fhem-"root" Verzeichnis ab, in der alle Werte stehen.

=== Tasterverhalten ===

Das Tasterverhalten kann auch (zusätzlich) auf 1-Tasten-Bedienung (1 Taste drücken für rauf oder runter, die selbe Taste drücken zum Stoppen) umgestellt werden. Hierzu ist wie beim [[HM-LC-Bl1PBU-FM_Unterputz-Jalousieaktor#Tasterverhalten|HM-LC-Bl1PBU-FM]] vorzugehen.

=== Log-Auszug ===
In FHEM ist nach dem Schalten des HM-LC-BL1-FM folgendes Log zu sehen:

<pre>
2012.02.12 17:53:08 2: CUL_HM set JalousieWohnzimmer on
2012.02.12 17:53:09 2: CUL_HM set JalousieWohnzimmer off
2012.02.12 21:25:14 2: CUL_HM set JalousieWohnzimmer 37
</pre>

= Links =
* [[Jalousie und Beleuchtung in mehreren Räumen]]
* [[Slider für HM-Rollladensteuerung anzeigen]]
* [http://www.elv-downloads.de/service/manuals/76793_HM_Unterputzschalter_UM.pdf Bedienungsanleitung] (PDF, ELV)

[[Kategorie:HomeMatic Components]]
[[Kategorie:HomeMatic Type Blind]]
[[Kategorie:Rollladensteuerung]]

HM-SCI-3-FM 3-Kanal-Funk-Schließerkontakt-Interface

2015-01-12T12:12:33Z

Rohan: /* Betrieb mit FHEM */ Ausführung zu den 3 Channels

'''HM-SCI-3-FM'''
HomeMatic 3-Kanal-Funk-Schließerkontakt-Interface
= Features =
Auswertung des Zustand von Schaltkontakten um z.B. Aktionen bei einem Statuswechsel der Kontakte auszulösen. Das Modul meldet den Zustand des Kontaktes, anders als das ähnliche HM-S'''W'''I-3-FM, welches bei Schaltzustandsänderung nur einen Trigger sendet.

'''Technische Daten:'''
Anzahl Kontakteingänge: 3
Stromversorgung: 1x Lithium-Knopfzelle CR2032
Schutzart: IP 20
Abmessungen (Ø x H): 50 x 10 mm
Gewicht: 30 g (ohne Batterie)

= Hinweise zu Inbetriebnahme und Installation =
Bei der Inbetriebnahme (Batterie einlegen) des HM-SCI-3-FM ist (regulär) folgendes Blinkverhalten der LED zu beobachten:

* erst orange
* dann grün
* wieder orange
* 1 Sekunde blinkendes grün
* LED aus
= Probleme =
<ggfls. ergänzen>

= Betrieb mit FHEM =

In Fhem stellt sich das Gerät wie folgt dar (siehe u.a. Log-Auszug):

* Das Device: ''CUL_HM_threeStateSensor_1DD5FE''
* Channel 1: ''CUL_HM_threeStateSensor_1DD5FE_Sw_01''
* Channel 2: ''CUL_HM_threeStateSensor_1DD5FE_Sw_02''
* Channel 3: ''CUL_HM_threeStateSensor_1DD5FE_Sw_03''

Die Sequenz "1DD5FE" lautet immer anders. In den Channels/Kanälen werden die Schaltzustände gemeldet.

== fhem.log Auszug ==
So zeigt sich ein HM-SCI-3-FM, sobald FHEM ihn erstmalig entdeckt:

<nowiki><Datum>_<Zeit> 3: CUL_HM Unknown device CUL_HM_threeStateSensor_1DD5FE, please define it
<Datum>_<Zeit> 2: autocreate: define CUL_HM_threeStateSensor_1DD5FE CUL_HM 1DD5FE A1A0684001DD5FE00000010005F4A45513036353436373380030000
<Datum>_<Zeit> 3: Device CUL_HM_threeStateSensor_1DD5FE added to ActionDetector with 028:00 time
<Datum>_<Zeit> 3: CUL_HM pair: CUL_HM_threeStateSensor_1DD5FE threeStateSensor, model HM-SCI-3-FM serialNr JEQ0654673
<Datum>_<Zeit> 2: autocreate: define FileLog_CUL_HM_threeStateSensor_1DD5FE FileLog /var/log/fhem/CUL_HM_threeStateSensor_1DD5FE-%Y.log CUL_HM_threeStateSensor_1DD5FE
<Datum>_<Zeit> 2: autocreate: define CUL_HM_threeStateSensor_1DD5FE_Sw_01 CUL_HM 1DD5FE01
<Datum>_<Zeit> 2: autocreate: define FileLog_CUL_HM_threeStateSensor_1DD5FE_Sw_01 FileLog /var/log/fhem/CUL_HM_threeStateSensor_1DD5FE_Sw_01-%Y.log CUL_HM_threeStateSensor_1DD5FE_Sw_01
<Datum>_<Zeit> 2: autocreate: define CUL_HM_threeStateSensor_1DD5FE_Sw_02 CUL_HM 1DD5FE02
<Datum>_<Zeit> 2: autocreate: define FileLog_CUL_HM_threeStateSensor_1DD5FE_Sw_02 FileLog /var/log/fhem/CUL_HM_threeStateSensor_1DD5FE_Sw_02-%Y.log CUL_HM_threeStateSensor_1DD5FE_Sw_02
<Datum>_<Zeit> 2: autocreate: define CUL_HM_threeStateSensor_1DD5FE_Sw_03 CUL_HM 1DD5FE03
<Datum>_<Zeit> 2: autocreate: define FileLog_CUL_HM_threeStateSensor_1DD5FE_Sw_03 FileLog /var/log/fhem/CUL_HM_threeStateSensor_1DD5FE_Sw_03-%Y.log CUL_HM_threeStateSensor_1DD5FE_Sw_03
<Datum>_<Zeit> 2: autocreate: define ActionDetector CUL_HM 000000
<Datum>_<Zeit> 2: autocreate: define FileLog_ActionDetector FileLog /var/log/fhem/ActionDetector-%Y.log ActionDetector
<Datum>_<Zeit> 3: Device CUL_HM_threeStateSensor_1DD5FE added to ActionDetector with 028:00 time</nowiki>
<bitte ergänzen>

= Links =
Manual: [http://www.elv-downloads.de/Assets/Produkte/9/914/91461/Downloads/91461_HM_SCI_3FMD1_GB_um.pdf PDF]

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

Plots erzeugen

2015-01-12T08:41:22Z

Rohan: /* Plot der letzten 24 Stunden statt des aktuellen Tages */ Hinweis auf Attribut "captionLeft" eingearbeitet.

'''Plots erzeugen'''

== .gplot-Editor ==

Fhem verfügt über einen ".gplot-Editor", um die .gplot-Datei zur Erstellung eines Plots menügeführt zu generieren. Ein manuelles Anlegen der .gplot-Datei ist für Spezialisten und normalerweise nicht notwendig. Der .gplot-Editor sollte für Standardfälle grundsätzlich verwendet werden.

Details zum .gplot-Editor können im Ankündigungshinweis im {{Link2Forum|Topic=11275|Message=75594|LinkText=Fhem-Forum}} nachgelesen werden.

Spezielle Erläuterungen zur Erzeugung von Plots mit Stati: {{Link2Forum|Topic=12945|Message=78887|LinkText=Fhem-Forum}}, [[EnOcean-STM-250-Fenster-Türkontakt#Türstatus in einem Plot darstellen|Schrittweises Beispiel bei Kontakten]], [[EnOcean-D-452-FU-EBIM-Aktor-2fach#Aktorstatus_in_einem_Plot_darstellen|Schrittweises Beispiel zum Aktorstatus]]

Verhinderung von Perl-Warnungen bei LogFiles mit unterschiedlicher Spaltenanzahl in Log-Zeilen: {{Link2Forum|Topic=12945}}

<big>'''Achtung'''</big>:

Verwenden Sie diesen Editor nicht, wenn das Fhem-Device bereits angelegt ist und Sie für dieses Device ein bestehendes, allgemeines gplot-File verwenden, das auch für andere Devices benutzt wird. Beim Abspeichern wird ein Filter im gplot-File gesetzt, das das gplot-File nur für genau dieses Device verwendbar macht.

Beispiel:

aus

#FileLog 4:::

wird

#FileLog 4:DS2423.energy_a\x3a::

in dem entsprechenden gplot-File.

Die anderen Devices, die evtl. dieses gplot-File verwenden, haben danach keine funktionierende Plot-Anzeige mehr. Bevor also etwas geändert wird, sollte mit

set weblink_irgendwas copyGplotFile

ein Duplikat angelegt werden, das ausschließlich für diesen Plot verwendet wird. Der Befehl kann unterhalb des ersten Kasten per Dropdown ausgewählt werden.

== Individuell / Manuell ==

'''Vorbemerkungen:'''

* Fhem bedient sich für die Erstellung der Plots des Programms ''Gnuplot'' [http://www.gnuplot.info/]. Hierbei reichen die "einfacheren" Funktionalitäten dieses Programms aus (''Gnuplot'' kann noch viel mehr).
* die Beispieldateien für die in Fhem integrierten Plots finden Sie in Ihrem Fhem-Programmordner unter ''www/gplot''.
* Angaben wie <SIZE>, <OUT>, <L1>, <IN> usw. im Plot-File sind Platzhalter bzw. Feldbezeichner für Fhem. Diese sind case-sensitive (Groß-/Kleinschreibung beachten).

Ein Beispiel (''temp4hum4.gplot'') aus diesem Verzeichnis:

# Attribute 'small' is useful for gnuplot/-scroll only,
# if plotsize is less than 800,400
#set terminal png transparent small size <SIZE> crop

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 ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics

set y2label "Temperature in C"
set ylabel "Humidity (%)"

#FileLog 4:temperature:10:
#FileLog 4:humidity:50:

plot \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Measured temperature' with lines,\
"< egrep 'humidity' <IN>"\
using 1:4 axes x1y1 title 'Humidity (%)' with lines\

Die Zeilen, die mit ''set'' beginnen, beeinflussen wesentlich das Erscheinungsbild und Aussehen Ihrer Plots (Achsenbeschriftungen, Skalen usw.). Dabei sollten Sie die Zeilen, die eine Angabe zwischen "<" und ">" enthalten, zunächst unverändert lassen. Weitere (ausführliche) Hinweise (zu Gnuplot!) finden Sie in einer [http://www.home.uni-osnabrueck.de/elsner/Skripte/gnuplot.pdf PDF-Datei]. Eingeschränktere, aber für die meisten Belange von Fhem ausreichende Infos finden Sie auf [http://www.aurbacher.net/gnuplot/gnuplot.html dieser Web-Seite].

=== Benutzung der Variablen ===
{| class="wikitable"
! Variable
! Nutzung in gplot-File
! Füllung mit inhalt in fhem.cfg
|-
| <TL>
| set title '<TL>'
| attr weblink title "Dies füllt den Platzhalter <TL>"
|-
| <L1>
| set xlabel '<L1>'
| attr weblink label "Dies füllt das Label <L1>"
|-
| <L2>
| set title '<L2>'
| attr weblink label "Dies füllt das Label <L1>"::"Dies füllt das Label <L2>"
|}

=== Welche Daten werden dargestellt ===

Die Zeilen

#FileLog 5::0:
#FileLog 14::0:

in einer gplot-Datei tragen zwar zu Beginn das Kommentarzeichen "#", jedoch handelt es sich durchaus nicht um solche. Vielmehr trifft man mit den Werten hinter ''FileLog'' Vorgaben, welche Werte wie von Fhem an ''gnuplot'' zwecks grafischer Darstellung übergeben werden

Im o.a. Beispiel werden das 5. und das 14. Wertfeld (voneinander getrennt durch ein Leerzeichen (Blank)) an gnuplot weiter gegeben.

Eine dazu passende Log-Dateizeile könnte beispielsweise so aussehen

2013-11-14_17:32:00 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200
----1. Feld-------- --2. Feld-- --3.---- -4.- -5. -6. 7. 8. -9. 10. 11 12 --13.- --14.---

^ ^
werden ausgewertet --| --|

Diese Parameter können auch als attribut übergeben werden:

attr weblink plotfunction "FileLog 5::0:"

Anhand der Anmerkungen wird hoffentlich die Wirkweise deutlich. Zu den restlichen - optionalen - Parametern hinter ''FileLog'' wird zunächst auf die [http://fhem.de/commandref.html#FileLogget commanref] verwiesen.

=== Datum und Zeit ===

'''Anmerkungen / Hinweise:'''

Fhem erwartet das Datum '''und''' die Uhrzeit der Log-Dateieinträge '''zwingend''' an <ins>erster Stelle</ins> der Datenzeile und zwar im Format

<code>
JJJJ-MM-TT_SS:mm:ss
</code>

wobei

* JJJJ die 4-stellige Jahreszahl
* MM der 2-stellige Monat (ggfls. mit Vornull)
* TT der 2-stellige Tag (ggfls. mit Vornull)
* SS die 2-stellige Stunde (ggfls. mit Vornull)
* mm die 2-stellige Minute (ggfls. mit Vornull)
* ss die 2-stellige Sekunde (ggfls. mit Vornull)

bedeutet. Bitte beachten Sie auch die Stelle der Zeichen "-", "_" und ":". Stehen diese nicht an den angegebenen Stellen, wird die entsprechende Zeile beim Erzeugen des Plots nicht beachtet. Ggfls. wird gar kein Plot angezeigt.

Eine Änderung/Anpassung der *.gplot-Datei in der Zeile

set timefmt "..."

hat auf dieses Verhalten von Fhem '''keine''' Auswirkungen, sondern nur auf die Darstellung von Datum und Zeit durch ''Gnuplot'' .

Dazu ein Beispiel:

Mit

2013-11-14_17:32:00 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200

kann Fhem etwas anfangen. Mit

20131114173200 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200

oder

14.11.2013 17:32 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200

dagegen nicht.

Im ersten Fehler-Beispiel fehlen die notwendigen Trennzeichen, im zweiten Fehler-Beispiel ist die Reihenfolge im Datum verkehrt, außerdem werden die falschen Trenner verwendet. Zudem fehlen die Sekunden.

=== Plot der letzten 24 Stunden statt des aktuellen Tages ===

Hierzu kann man in der ''Fhem.cfg'' für die Einträge

define WEB FHEMWEB 8083 global

das Attribut

attr WEB endPlotNow 1

setzen. Gleiches geht auch für ''WEBphone'' und ''WEBtablet''. Da muss es dann lauten

attr WEBphone endPlotNow 1

bzw.

attr WEBtablet endPlotNow 1

Das Attribut gilt dann aber für '''alle''' Plots der jeweiligen Ansichten. Wenn man wieder zurück zu den Plots ab jeweils 00:00 Uhr des aktuellen Tages möchte, löscht man dieses Attribut wieder bzw. setzt es auf den Wert "0".

=== Legende links platzieren ===

Gerade im Verbund mit dem Attribut ''endPlotNow'' macht das seit dem 11.01.2015 neue Attribut ''captionLeft'' Sinn, da dann die Legende nicht mehr rechts oben, sondern links oben im Plot erscheint. Dadurch wird die Sichtbarkeit der aktuellen Werte verbessert.

[[Kategorie:FAQ]]
[[Kategorie:HOWTOS]]

HM-Sen-RD-O Funk-Regensensor

2015-01-09T20:18:41Z

Rohan: /* Steuerung / Betrieb */ Syntax-Fehler korrigiert

== Allgemeines ==

Beim HM-Sen-RD-O (RD-O) handelt es sich um einen Funk-Regensensor. Stand 26.06.2013 war er noch nicht lieferbar, ab August 2013 waren die Fertiggeräte verfügbar und seit Dezember 2013 sind auch die Bausätze lieferbar.

Er erkennt beginnenden Regen und kann über mit ihm gep'''ee'''rte Aktoren Reaktionen veranlassen. Zudem verfügt er über eine eingebaute Heizung sowie eine optische Anzeige (grüne LED) direkt im Gehäuse, die durch Aufleuchten die Regenerkennung darstellt. Er wird mittels einer externen Spannungsversorgung (DC 7,5 bis 30 V) betrieben (nicht im Lieferumfang).

Die eingebaute Heizung in der Sensorfläche soll Fehlmeldungen (Betauung, z.B. durch Nebel, bzw. Vereisung) vermeiden helfen.

== Technische Daten ==

* Aktuelle Firmware: 1.4 (Stand Dezember 2013)
* Versorgungsspannung: 7,5–30 V DC
* Max. Stromaufnahme: 250 mA
* IP-Schutzart: IP44
* Leistungsaufnahme Ruhebetrieb: 0,4 W (ohne Sensorheizung)
* Leistungsaufnahme Sensorheizung: ca. 1 W
* Abmessungen (B x H x T): 80 x 82 x 55 mm
* Gewicht: 286 gr.

Man kann den RD-O auch als "ARR"-Bausatz bestellen, dann ist er ein paar Euro preiswerter. Der Zusammenbau erfordert keine Profi-Lötkenntnisse, da nur ein paar bedrahtete Bauteile (Elko, LEDs, Transceiver-Modul usw.) einzulöten sind. Dem Bausatz liegt (entgegen sonstiger Bausätze von ELV) keine Aufbauanleitung (meist in Form einer Kopie des Artikels zur Produktvorstellung aus dem jeweiligen ELV-Journal) bei, die jedoch mit einer freundlichen E-Mail an den ELV-Support angefordert werden kann und als PDF-Dokument übersandt wird.

== Betrieb mit FHEM ==

Mit Stand Dezember 2013 wird der RD-O von Fhem unterstützt (Ausnahme siehe "Probleme"). Voraussetzung ist ein halbwegs aktueller Fhem-Versionsstand, da es sich um ein relativ neues HomeMatic-Gerät handelt. Zunächst ist der RD-O mit Fhem zu p'''ai'''ren. Nun kann man das Device umbenennen ("renamen"). Die Kanäle (siehe unten) wurden <ins>hier</ins> dabei (leider) nicht automatisch mitumbenannt, dies kann aber durch entsprechende ''rename''-Befehle von Hand nachgeholt werden. Danach ein ''save config'' und ''rereadcfg'' und weiter ...

=== Geräte-Kanäle (Device-channels) ===

Der RD-O hat 2 Kanäle zusätzlich zum "Channel 00", der das eigentliche Device darstellt.
* Channel 01, dieser enthält alles um die eigentliche Erkennung ob es gerade regnet oder nicht
* Channel 02, über diesen kann das Verhalten der internen Heizung gesteuert werden

==== Channel 00 ====

Die Register:
list: register | range | peer | description
0: localResDis | literal | | local reset disable options:on,off
0: pairCentral | 0 to 16777215 | | pairing to central
0: transmDevTryMax | 1 to 10 | | max message re-transmit

==== Channel 01 ====

Die Register:
list: register | range | peer | description
1: condTxThrhHi | 0 to 3000mV | | threshold high condition
1: eventFilterTimeB | 5 to 7620s | | event filter time
1: evntRelFltTime | 1 to 7620s | | event filter release time
1: highHoldTime | 60 to 7620s | | hold time on high state
1: transmitTryMax | 1 to 10 | | max message re-transmit
4: expectAES | literal | required | expect AES options:on,off
4: peerNeedsBurst | literal | required | peer expects burst options:on,off

==== Channel 02 ====

Z. Zt. sind keine Register verfügbar.

=== fhem.cfg ===

Bei eingeschaltetem ''autocreate'' werden die erforderlichen Definitionen zum erkannten Sen-RD-O überwiegend selbstständig angelernt:

define Regensensor CUL_HM 20CE4B
attr Regensensor .devInfo 040101
attr Regensensor .stc 70
attr Regensensor autoReadReg 4_reqStatus
attr Regensensor firmware 1.4
attr Regensensor model HM-Sen-RD-O
attr Regensensor peerIDs
attr Regensensor room CUL_HM
attr Regensensor serialNr KEQ0117756
attr Regensensor subType sensRain
attr Regensensor webCmd getConfig
define FileLog_Regensensor FileLog /opt/fhem/log/Regensensor-%Y-%m.log Regensensor
attr FileLog_Regensensor logtype text
attr FileLog_Regensensor room CUL_HM
# Channel 01 => 20CE4B01
define Regensensor_EsRegnet CUL_HM 20CE4B01
attr Regensensor_EsRegnet expert 1
attr Regensensor_EsRegnet model HM-Sen-RD-O
attr Regensensor_EsRegnet peerIDs 00000000,
attr Regensensor_EsRegnet room CUL_HM
define FileLog_Regensensor_EsRegnet FileLog /opt/fhem/log/Regensensor_EsRegnet-%Y-%m.log Regensensor_EsRegnet
attr FileLog_Regensensor_EsRegnet logtype text
attr FileLog_Regensensor_EsRegnet room CUL_HM
define SVG_FileLog_Regensensor_EsRegnet SVG FileLog_Regensensor_EsRegnet:Regensensor:CURRENT
attr SVG_FileLog_Regensensor_EsRegnet room CUL_HM
# Channel 02 => 20CE4B02
define Regensensor_Heizung CUL_HM 20CE4B02
attr Regensensor_Heizung expert 1
attr Regensensor_Heizung model HM-Sen-RD-O
attr Regensensor_Heizung peerIDs
attr Regensensor_Heizung room CUL_HM
define FileLog_Regensensor_Heizung FileLog /opt/fhem/log/Regensensor_Heizung-%Y-%m.log Regensensor_Heizung
attr FileLog_Regensensor_Heizung logtype text
attr FileLog_Regensensor_Heizung room CUL_HM

=== Steuerung / Betrieb ===

Über die Veränderung der entsprechenden Register kann man das Verhalten des RD-O seinen eigenen Bedürfnissen anpassen. So läuft z.B. ab Werk die Heizung nach Anschluss der Spannungsversorgung ständig mit. Nach der Verbindung mit einer Zentrale (hier Fhem) kann man dies steuern. Mittels (bitte auf den Channel 02)

<code>
set Regensensor_Heizung off
</code>

wird die Heizung aus- und durch

<code>
set Regensensor_Heizung on
</code>

wieder eingeschaltet. Evtl. sollte man die Heizung in Abhängigkeit von Temperatur und/oder relativer Luftfeuchte ein- bzw. ausschalten (Stromverbrauch; Materialschonung, denn die Sensorfläche wird merklich warm). Ein Einschalten bei erkanntem Regen ist sicher ebenfalls sinnvoll, denn die Heizung sorgt für ein schnelleres Abtrocknen der Sensorfläche und somit einer zeitnahen Regenende-Erkennung.

Hierzu könnte man folgendes in Fhem definieren:

define DoIf_RegenSensorHzgOnOff DOIF ([Aussen.ThermoHygro:temperature]<5 or [Regensensor_EsRegnet] eq "rain") (set Regensensor_Heizung on) DOELSEIF ([Aussen.ThermoHygro:temperature]>6 and [Regensensor_EsRegnet] eq "dry") (set Regensensor_Heizung off)
attr DoIf_RegenSensorHzgOnOff room Wetter

Die Sensor-Heizung wird damit bei Temperaturen unter 5 °C '''oder''' bei erkanntem Regen eingeschaltet. Die Abschaltung der Heizung erfolgt, sobald die Temperatur über 6 °C beträgt '''und''' es trocken ist.

Der RD-O reagiert bereits bei der Berührung der Sensorfläche mit einem Finger mit der Meldung "Es regnet". Dies erfolgt auch, sobald man einen kleinen Bereich mit einem Tropfen Wasser befeuchtet. Die Meldung bleibt (ab Werk) einige Minuten erhalten. Das Ansprech- und Rücksetzverhalten kann über die Veränderung der entsprechenden Register angepasst werden.

=== Log-Daten ===

Auszüge aus den Logs unmittelbar nach Anschluss der Spannungsversorgung und dem ersten Drücken der Anlerntaste am RD-O:

==== Event monitor ====

<Datum> <Zeit> Global global UNDEFINED CUL_HM_HM_Sen_RD_O_20EC4B CUL_HM 20EC4B A1A02840020EC4B0000001400A74B45513031313730363770040101
<Datum> <Zeit> Global global DEFINED CUL_HM_HM_Sen_RD_O_20EC4B
<Datum> <Zeit> Global global DEFINED FileLog_CUL_HM_HM_Sen_RD_O_20EC4B
<Datum> <Zeit> Global global SAVE
<Datum> <Zeit> Global global UNDEFINED CUL_HM_HM_Sen_RD_O_20EC4B_Rain CUL_HM 20EC4B01
<Datum> <Zeit> Global global DEFINED CUL_HM_HM_Sen_RD_O_20EC4B_Rain
<Datum> <Zeit> Global global DEFINED FileLog_CUL_HM_HM_Sen_RD_O_20EC4B_Rain
<Datum> <Zeit> Global global SAVE
<Datum> <Zeit> Global global UNDEFINED CUL_HM_HM_Sen_RD_O_20EC4B_Heating CUL_HM 20EC4B02
<Datum> <Zeit> Global global DEFINED CUL_HM_HM_Sen_RD_O_20EC4B_Heating
<Datum> <Zeit> Global global DEFINED FileLog_CUL_HM_HM_Sen_RD_O_20EC4B_Heating
<Datum> <Zeit> Global global SAVE
... und kurz darauf ...
<Datum> <Zeit> CUL_HM CUL_HM_HM_Sen_RD_O_20EC4B_Rain timedOn: off
<Datum> <Zeit> CUL_HM CUL_HM_HM_Sen_RD_O_20EC4B_Rain dry

==== Fhem-Log ====

<Datum> <Zeit> 3: CUL_HM Unknown device CUL_HM_HM_Sen_RD_O_20EC4B, please define it
<Datum> <Zeit> 2: autocreate: define CUL_HM_HM_Sen_RD_O_20EC4B CUL_HM 20EC4B A1A02840020EC4B0000001400A74B45513031313730363770040101
<Datum> <Zeit> 2: autocreate: define FileLog_CUL_HM_HM_Sen_RD_O_20EC4B FileLog /opt/fhem/log/CUL_HM_HM_Sen_RD_O_20EC4B-%Y-%m.log CUL_HM_HM_Sen_RD_O_20EC4B
<Datum> <Zeit> 2: autocreate: define CUL_HM_HM_Sen_RD_O_20EC4B_Rain CUL_HM 20EC4B01
<Datum> <Zeit> 2: autocreate: define FileLog_CUL_HM_HM_Sen_RD_O_20EC4B_Rain FileLog /opt/fhem/log/CUL_HM_HM_Sen_RD_O_20EC4B_Rain-%Y-%m.log CUL_HM_HM_Sen_RD_O_20EC4B_Rain
<Datum> <Zeit> 2: autocreate: define CUL_HM_HM_Sen_RD_O_20EC4B_Heating CUL_HM 20EC4B02
<Datum> <Zeit> 2: autocreate: define FileLog_CUL_HM_HM_Sen_RD_O_20EC4B_Heating FileLog /opt/fhem/log/CUL_HM_HM_Sen_RD_O_20EC4B_Heating-%Y-%m.log CUL_HM_HM_Sen_RD_O_20EC4B_Heating
<Datum> <Zeit> 2: CUL_HM set CUL_HM_HM_Sen_RD_O_20EC4B getConfig

==== Device-Logs ====

==== Channel 01 Log (Es regnet) ====

<Datum> <Zeit> Regensensor_EsRegnet timedOn: off
<Datum> <Zeit> Regensensor_EsRegnet dry
<Datum> <Zeit> Regensensor_EsRegnet timedOn: off
<Datum> <Zeit> Regensensor_EsRegnet rain
<Datum> <Zeit> Regensensor_EsRegnet timedOn: off
<Datum> <Zeit> Regensensor_EsRegnet dry
<Datum> <Zeit> Regensensor_EsRegnet timedOn: off
<Datum> <Zeit> Regensensor_EsRegnet rain
<Datum> <Zeit> Regensensor_EsRegnet timedOn: off
<Datum> <Zeit> Regensensor_EsRegnet dry

Sie sehen, dass der Sen-RD-O Zustandsänderungen genau 1 Mal meldet und danach nicht wiederholt.

==== Channel 02 Log (Heizung an oder aus) ====

<Datum> <Zeit> Regensensor_Heizung timedOn: off
<Datum> <Zeit> Regensensor_Heizung on
<Datum> <Zeit> Regensensor_Heizung set_off
<Datum> <Zeit> Regensensor_Heizung timedOn: off
<Datum> <Zeit> Regensensor_Heizung off
<Datum> <Zeit> Regensensor_Heizung set_on
<Datum> <Zeit> Regensensor_Heizung timedOn: off
<Datum> <Zeit> Regensensor_Heizung on

=== Plot / Grafische Darstellung ===

Der RD-O meldet im Channel_01-Log die Zustände "rain" (für: es regnet) und "dry" (für: es regnet nicht). Diese Werte kann man in Fhem-Plots natürlich nicht so auswerten wie numerische Angaben. Aber auch dafür bietet Fhem eine Lösung. Hier zunächst der Plot:

[[Datei:HM-Sen-RD-O_cut.jpg|Plot des HM-Sen-RD-O]]

Und hier die dazugehörige Plot-Datei:

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 'Regnet es: Ja/Nein'
set ytics ("Trocken" 0, "Regen" 1)
set y2tics ("Trocken" 0, "Regen" 1)
set grid
set ylabel ""
set y2label ""
set yrange [-0.1:1.1]
set y2range [-0.1:1.1]

#FileLog 3::0:$fld[2]=~"rain"?1:0

plot "<IN>" using 1:2 axes x1y2 title 'Regnet es?' ls l0 lw 1 with steps

Dieser Plot hat noch einen Mangel. Um kurz vor 20:00 Uhr hat es erneut angefangen zu regnen und obwohl es jetzt nach 22:00 Uhr ist, deutet der Plot an, dass es momentan "nicht regnet". An einer plausibleren Darstellung wird gearbeitet.

=== Probleme ===

==== getConfig ====

Anfangs (Mitte Dezember 2013) gab es noch ein Problem mit dem ''getConfig''. Dieser Befehl wurde quittiert mit den Meldungen:

protState CMDs_done_Errors:1
...
state RESPONSE TIMEOUT:RegisterRead

Andere Befehle (wie oben z.B. Heizung an/aus) wurden dagegen umgehend erfolgreich abgearbeitet.

Dieses Problem ist mittlerweile gelöst, so dass der RD-O voll genutzt werden kann.

==== Erst Minuten nach Regenende meldet der RD-O "dry" (also kein Regen mehr) ====

Das liegt zum einen daran, dass der auf der Sensorfläche befindliche Niederschlag erst einmal durch die interne Sensorheizung "verdampft" werden muss. Zum anderen ist der RD-O so eingestellt, dass er erst 5 Minuten nach Abtrocknen der Sensorfläche wieder den Zustand "dry" an Fhem meldet. Zuständig dafür ist das RD-O-Register ''highHoldTime'' im Channel '''01''', das werksseitig auf 300 Sekunden (also 5 Minuten) eingestellt ist. Dieses Register kann man aber auf einen Wert von (minimal, kürzer geht nicht) z.B. 60 Sekunden setzen:

set Regensensor_EsRegnet regSet highHoldTime 60

==== Korrosion / eindringendes Wasser ====

In den Käuferbewertungen und im Kundenforum von ELV gibt es Meldungen, dass möglicherweise die Sensorfläche "korrodiert" bzw. der RD-O mit Wasser "voll läuft". Diese Meldungen scheinen sich allerdings auf eine frühere Version des ARR-bausatzes zu beziehen, bei der man die Sensorfläche noch selbst in den Gehäusedeckel (wasserdicht) einkleben musste. Dieses Einkleben war bei dem Bausatz von Mitte Dezember 2013 nicht mehr erforderlich. Sobald dazu Erfahrungswerte vorliegen, werden diese hier eingetragen.

== Links ==

* [http://www.elv.de/homematic-funk-regensensor-1.html Produktinfo]
* [http://www.elv-downloads.de/Assets/Produkte/13/1302/130220/Downloads/130220_hm_regensensor_um.pdf Bedienungsanleitung (PDF)]
* [http://www.elv-downloads.de/Assets/Produkte/13/1302/130220/Downloads/130220_hm_regensensor_data.pdf Datenblatt (PDF)]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Regensensor]]

HM-Sen-RD-O Funk-Regensensor

2015-01-09T20:10:35Z

Rohan: /* Steuerung / Betrieb */ DEF für An- und Abschaltung der Heizung eingefügt

== Allgemeines ==

Beim HM-Sen-RD-O (RD-O) handelt es sich um einen Funk-Regensensor. Stand 26.06.2013 war er noch nicht lieferbar, ab August 2013 waren die Fertiggeräte verfügbar und seit Dezember 2013 sind auch die Bausätze lieferbar.

Er erkennt beginnenden Regen und kann über mit ihm gep'''ee'''rte Aktoren Reaktionen veranlassen. Zudem verfügt er über eine eingebaute Heizung sowie eine optische Anzeige (grüne LED) direkt im Gehäuse, die durch Aufleuchten die Regenerkennung darstellt. Er wird mittels einer externen Spannungsversorgung (DC 7,5 bis 30 V) betrieben (nicht im Lieferumfang).

Die eingebaute Heizung in der Sensorfläche soll Fehlmeldungen (Betauung, z.B. durch Nebel, bzw. Vereisung) vermeiden helfen.

== Technische Daten ==

* Aktuelle Firmware: 1.4 (Stand Dezember 2013)
* Versorgungsspannung: 7,5–30 V DC
* Max. Stromaufnahme: 250 mA
* IP-Schutzart: IP44
* Leistungsaufnahme Ruhebetrieb: 0,4 W (ohne Sensorheizung)
* Leistungsaufnahme Sensorheizung: ca. 1 W
* Abmessungen (B x H x T): 80 x 82 x 55 mm
* Gewicht: 286 gr.

Man kann den RD-O auch als "ARR"-Bausatz bestellen, dann ist er ein paar Euro preiswerter. Der Zusammenbau erfordert keine Profi-Lötkenntnisse, da nur ein paar bedrahtete Bauteile (Elko, LEDs, Transceiver-Modul usw.) einzulöten sind. Dem Bausatz liegt (entgegen sonstiger Bausätze von ELV) keine Aufbauanleitung (meist in Form einer Kopie des Artikels zur Produktvorstellung aus dem jeweiligen ELV-Journal) bei, die jedoch mit einer freundlichen E-Mail an den ELV-Support angefordert werden kann und als PDF-Dokument übersandt wird.

== Betrieb mit FHEM ==

Mit Stand Dezember 2013 wird der RD-O von Fhem unterstützt (Ausnahme siehe "Probleme"). Voraussetzung ist ein halbwegs aktueller Fhem-Versionsstand, da es sich um ein relativ neues HomeMatic-Gerät handelt. Zunächst ist der RD-O mit Fhem zu p'''ai'''ren. Nun kann man das Device umbenennen ("renamen"). Die Kanäle (siehe unten) wurden <ins>hier</ins> dabei (leider) nicht automatisch mitumbenannt, dies kann aber durch entsprechende ''rename''-Befehle von Hand nachgeholt werden. Danach ein ''save config'' und ''rereadcfg'' und weiter ...

=== Geräte-Kanäle (Device-channels) ===

Der RD-O hat 2 Kanäle zusätzlich zum "Channel 00", der das eigentliche Device darstellt.
* Channel 01, dieser enthält alles um die eigentliche Erkennung ob es gerade regnet oder nicht
* Channel 02, über diesen kann das Verhalten der internen Heizung gesteuert werden

==== Channel 00 ====

Die Register:
list: register | range | peer | description
0: localResDis | literal | | local reset disable options:on,off
0: pairCentral | 0 to 16777215 | | pairing to central
0: transmDevTryMax | 1 to 10 | | max message re-transmit

==== Channel 01 ====

Die Register:
list: register | range | peer | description
1: condTxThrhHi | 0 to 3000mV | | threshold high condition
1: eventFilterTimeB | 5 to 7620s | | event filter time
1: evntRelFltTime | 1 to 7620s | | event filter release time
1: highHoldTime | 60 to 7620s | | hold time on high state
1: transmitTryMax | 1 to 10 | | max message re-transmit
4: expectAES | literal | required | expect AES options:on,off
4: peerNeedsBurst | literal | required | peer expects burst options:on,off

==== Channel 02 ====

Z. Zt. sind keine Register verfügbar.

=== fhem.cfg ===

Bei eingeschaltetem ''autocreate'' werden die erforderlichen Definitionen zum erkannten Sen-RD-O überwiegend selbstständig angelernt:

define Regensensor CUL_HM 20CE4B
attr Regensensor .devInfo 040101
attr Regensensor .stc 70
attr Regensensor autoReadReg 4_reqStatus
attr Regensensor firmware 1.4
attr Regensensor model HM-Sen-RD-O
attr Regensensor peerIDs
attr Regensensor room CUL_HM
attr Regensensor serialNr KEQ0117756
attr Regensensor subType sensRain
attr Regensensor webCmd getConfig
define FileLog_Regensensor FileLog /opt/fhem/log/Regensensor-%Y-%m.log Regensensor
attr FileLog_Regensensor logtype text
attr FileLog_Regensensor room CUL_HM
# Channel 01 => 20CE4B01
define Regensensor_EsRegnet CUL_HM 20CE4B01
attr Regensensor_EsRegnet expert 1
attr Regensensor_EsRegnet model HM-Sen-RD-O
attr Regensensor_EsRegnet peerIDs 00000000,
attr Regensensor_EsRegnet room CUL_HM
define FileLog_Regensensor_EsRegnet FileLog /opt/fhem/log/Regensensor_EsRegnet-%Y-%m.log Regensensor_EsRegnet
attr FileLog_Regensensor_EsRegnet logtype text
attr FileLog_Regensensor_EsRegnet room CUL_HM
define SVG_FileLog_Regensensor_EsRegnet SVG FileLog_Regensensor_EsRegnet:Regensensor:CURRENT
attr SVG_FileLog_Regensensor_EsRegnet room CUL_HM
# Channel 02 => 20CE4B02
define Regensensor_Heizung CUL_HM 20CE4B02
attr Regensensor_Heizung expert 1
attr Regensensor_Heizung model HM-Sen-RD-O
attr Regensensor_Heizung peerIDs
attr Regensensor_Heizung room CUL_HM
define FileLog_Regensensor_Heizung FileLog /opt/fhem/log/Regensensor_Heizung-%Y-%m.log Regensensor_Heizung
attr FileLog_Regensensor_Heizung logtype text
attr FileLog_Regensensor_Heizung room CUL_HM

=== Steuerung / Betrieb ===

Über die Veränderung der entsprechenden Register kann man das Verhalten des RD-O seinen eigenen Bedürfnissen anpassen. So läuft z.B. ab Werk die Heizung nach Anschluss der Spannungsversorgung ständig mit. Nach der Verbindung mit einer Zentrale (hier Fhem) kann man dies steuern. Mittels (bitte auf den Channel 02)

<code>
set Regensensor_Heizung off
</code>

wird die Heizung aus- und durch

<code>
set Regensensor_Heizung on
</code>

wieder eingeschaltet. Evtl. sollte man die Heizung in Abhängigkeit von Temperatur und/oder relativer Luftfeuchte ein- bzw. ausschalten (Stromverbrauch; Materialschonung, denn die Sensorfläche wird merklich warm). Ein Einschalten bei erkanntem Regen ist sicher ebenfalls sinnvoll, denn die Heizung sorgt für ein schnelleres Abtrocknen der Sensorfläche und somit einer zeitnahen Regenende-Erkennung.

Hierzu könnte man folgendes in Fhem definieren:

define DoIf_RegenSensorHzgOnOff DOIF ([Aussen.ThermoHygro:temperature]<5 || [Regensensor_EsRegnet] eq "rain") (set Regensensor_Heizung on) DOELSEIF ([Aussen.ThermoHygro:temperature]>6 and [Regensensor_EsRegnet] eq "dry") (set Regensensor_Heizung off)
attr DoIf_RegenSensorHzgOnOff room Wetter

Die Sensor-Heizung wird damit bei Temperaturen unter 5 °C '''oder''' bei erkanntem Regen eingeschaltet. Die Abschaltung der Heizung erfolgt, sobald die Temperatur über 6 °C beträgt '''und''' es trocken ist.

Der RD-O reagiert bereits bei der Berührung der Sensorfläche mit einem Finger mit der Meldung "Es regnet". Dies erfolgt auch, sobald man einen kleinen Bereich mit einem Tropfen Wasser befeuchtet. Die Meldung bleibt (ab Werk) einige Minuten erhalten. Das Ansprech- und Rücksetzverhalten kann über die Veränderung der entsprechenden Register angepasst werden.

=== Log-Daten ===

Auszüge aus den Logs unmittelbar nach Anschluss der Spannungsversorgung und dem ersten Drücken der Anlerntaste am RD-O:

==== Event monitor ====

<Datum> <Zeit> Global global UNDEFINED CUL_HM_HM_Sen_RD_O_20EC4B CUL_HM 20EC4B A1A02840020EC4B0000001400A74B45513031313730363770040101
<Datum> <Zeit> Global global DEFINED CUL_HM_HM_Sen_RD_O_20EC4B
<Datum> <Zeit> Global global DEFINED FileLog_CUL_HM_HM_Sen_RD_O_20EC4B
<Datum> <Zeit> Global global SAVE
<Datum> <Zeit> Global global UNDEFINED CUL_HM_HM_Sen_RD_O_20EC4B_Rain CUL_HM 20EC4B01
<Datum> <Zeit> Global global DEFINED CUL_HM_HM_Sen_RD_O_20EC4B_Rain
<Datum> <Zeit> Global global DEFINED FileLog_CUL_HM_HM_Sen_RD_O_20EC4B_Rain
<Datum> <Zeit> Global global SAVE
<Datum> <Zeit> Global global UNDEFINED CUL_HM_HM_Sen_RD_O_20EC4B_Heating CUL_HM 20EC4B02
<Datum> <Zeit> Global global DEFINED CUL_HM_HM_Sen_RD_O_20EC4B_Heating
<Datum> <Zeit> Global global DEFINED FileLog_CUL_HM_HM_Sen_RD_O_20EC4B_Heating
<Datum> <Zeit> Global global SAVE
... und kurz darauf ...
<Datum> <Zeit> CUL_HM CUL_HM_HM_Sen_RD_O_20EC4B_Rain timedOn: off
<Datum> <Zeit> CUL_HM CUL_HM_HM_Sen_RD_O_20EC4B_Rain dry

==== Fhem-Log ====

<Datum> <Zeit> 3: CUL_HM Unknown device CUL_HM_HM_Sen_RD_O_20EC4B, please define it
<Datum> <Zeit> 2: autocreate: define CUL_HM_HM_Sen_RD_O_20EC4B CUL_HM 20EC4B A1A02840020EC4B0000001400A74B45513031313730363770040101
<Datum> <Zeit> 2: autocreate: define FileLog_CUL_HM_HM_Sen_RD_O_20EC4B FileLog /opt/fhem/log/CUL_HM_HM_Sen_RD_O_20EC4B-%Y-%m.log CUL_HM_HM_Sen_RD_O_20EC4B
<Datum> <Zeit> 2: autocreate: define CUL_HM_HM_Sen_RD_O_20EC4B_Rain CUL_HM 20EC4B01
<Datum> <Zeit> 2: autocreate: define FileLog_CUL_HM_HM_Sen_RD_O_20EC4B_Rain FileLog /opt/fhem/log/CUL_HM_HM_Sen_RD_O_20EC4B_Rain-%Y-%m.log CUL_HM_HM_Sen_RD_O_20EC4B_Rain
<Datum> <Zeit> 2: autocreate: define CUL_HM_HM_Sen_RD_O_20EC4B_Heating CUL_HM 20EC4B02
<Datum> <Zeit> 2: autocreate: define FileLog_CUL_HM_HM_Sen_RD_O_20EC4B_Heating FileLog /opt/fhem/log/CUL_HM_HM_Sen_RD_O_20EC4B_Heating-%Y-%m.log CUL_HM_HM_Sen_RD_O_20EC4B_Heating
<Datum> <Zeit> 2: CUL_HM set CUL_HM_HM_Sen_RD_O_20EC4B getConfig

==== Device-Logs ====

==== Channel 01 Log (Es regnet) ====

<Datum> <Zeit> Regensensor_EsRegnet timedOn: off
<Datum> <Zeit> Regensensor_EsRegnet dry
<Datum> <Zeit> Regensensor_EsRegnet timedOn: off
<Datum> <Zeit> Regensensor_EsRegnet rain
<Datum> <Zeit> Regensensor_EsRegnet timedOn: off
<Datum> <Zeit> Regensensor_EsRegnet dry
<Datum> <Zeit> Regensensor_EsRegnet timedOn: off
<Datum> <Zeit> Regensensor_EsRegnet rain
<Datum> <Zeit> Regensensor_EsRegnet timedOn: off
<Datum> <Zeit> Regensensor_EsRegnet dry

Sie sehen, dass der Sen-RD-O Zustandsänderungen genau 1 Mal meldet und danach nicht wiederholt.

==== Channel 02 Log (Heizung an oder aus) ====

<Datum> <Zeit> Regensensor_Heizung timedOn: off
<Datum> <Zeit> Regensensor_Heizung on
<Datum> <Zeit> Regensensor_Heizung set_off
<Datum> <Zeit> Regensensor_Heizung timedOn: off
<Datum> <Zeit> Regensensor_Heizung off
<Datum> <Zeit> Regensensor_Heizung set_on
<Datum> <Zeit> Regensensor_Heizung timedOn: off
<Datum> <Zeit> Regensensor_Heizung on

=== Plot / Grafische Darstellung ===

Der RD-O meldet im Channel_01-Log die Zustände "rain" (für: es regnet) und "dry" (für: es regnet nicht). Diese Werte kann man in Fhem-Plots natürlich nicht so auswerten wie numerische Angaben. Aber auch dafür bietet Fhem eine Lösung. Hier zunächst der Plot:

[[Datei:HM-Sen-RD-O_cut.jpg|Plot des HM-Sen-RD-O]]

Und hier die dazugehörige Plot-Datei:

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 'Regnet es: Ja/Nein'
set ytics ("Trocken" 0, "Regen" 1)
set y2tics ("Trocken" 0, "Regen" 1)
set grid
set ylabel ""
set y2label ""
set yrange [-0.1:1.1]
set y2range [-0.1:1.1]

#FileLog 3::0:$fld[2]=~"rain"?1:0

plot "<IN>" using 1:2 axes x1y2 title 'Regnet es?' ls l0 lw 1 with steps

Dieser Plot hat noch einen Mangel. Um kurz vor 20:00 Uhr hat es erneut angefangen zu regnen und obwohl es jetzt nach 22:00 Uhr ist, deutet der Plot an, dass es momentan "nicht regnet". An einer plausibleren Darstellung wird gearbeitet.

=== Probleme ===

==== getConfig ====

Anfangs (Mitte Dezember 2013) gab es noch ein Problem mit dem ''getConfig''. Dieser Befehl wurde quittiert mit den Meldungen:

protState CMDs_done_Errors:1
...
state RESPONSE TIMEOUT:RegisterRead

Andere Befehle (wie oben z.B. Heizung an/aus) wurden dagegen umgehend erfolgreich abgearbeitet.

Dieses Problem ist mittlerweile gelöst, so dass der RD-O voll genutzt werden kann.

==== Erst Minuten nach Regenende meldet der RD-O "dry" (also kein Regen mehr) ====

Das liegt zum einen daran, dass der auf der Sensorfläche befindliche Niederschlag erst einmal durch die interne Sensorheizung "verdampft" werden muss. Zum anderen ist der RD-O so eingestellt, dass er erst 5 Minuten nach Abtrocknen der Sensorfläche wieder den Zustand "dry" an Fhem meldet. Zuständig dafür ist das RD-O-Register ''highHoldTime'' im Channel '''01''', das werksseitig auf 300 Sekunden (also 5 Minuten) eingestellt ist. Dieses Register kann man aber auf einen Wert von (minimal, kürzer geht nicht) z.B. 60 Sekunden setzen:

set Regensensor_EsRegnet regSet highHoldTime 60

==== Korrosion / eindringendes Wasser ====

In den Käuferbewertungen und im Kundenforum von ELV gibt es Meldungen, dass möglicherweise die Sensorfläche "korrodiert" bzw. der RD-O mit Wasser "voll läuft". Diese Meldungen scheinen sich allerdings auf eine frühere Version des ARR-bausatzes zu beziehen, bei der man die Sensorfläche noch selbst in den Gehäusedeckel (wasserdicht) einkleben musste. Dieses Einkleben war bei dem Bausatz von Mitte Dezember 2013 nicht mehr erforderlich. Sobald dazu Erfahrungswerte vorliegen, werden diese hier eingetragen.

== Links ==

* [http://www.elv.de/homematic-funk-regensensor-1.html Produktinfo]
* [http://www.elv-downloads.de/Assets/Produkte/13/1302/130220/Downloads/130220_hm_regensensor_um.pdf Bedienungsanleitung (PDF)]
* [http://www.elv-downloads.de/Assets/Produkte/13/1302/130220/Downloads/130220_hm_regensensor_data.pdf Datenblatt (PDF)]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Regensensor]]

Harmony

2015-01-09T10:59:33Z

Rohan: einige Typos

{{SEITENTITEL:harmoony}}
{{Infobox Modul
|ModPurpose=Anbindung Logitech Harmony Hub basierter Fernsbedienungen
|ModType=d
|ModCmdRef=harmony
|ModForumArea=Multimedia
|ModTechName=37_harmony.pm
|ModOwner=Andre ([http://forum.fhem.de/index.php?action=profile;u=430 Forum] / [[Benutzer Diskussion:justme|Wiki]])}}

Das Fhem-[[:Kategorie:Gerätemodul|Gerätemodul]] [[harmony]] bietet die Möglichkeit Logitech Harmony Hub basierte Fernbedienungen an Fhem anzubinden und so von Fhem aus Aktivitäten zu starten und zu stoppen, in Fhem auf das Starten und Stoppen von Aktivitäten über eine der mit dem Hub verbundenen Fernbedienungen zu reagieren oder auf Geräteebene jedes im Hub konfigurierte Gerät über IR, Bluetooth und/oder einen Smart Keyboard USB Dongle zu steuern.

Unterstützt werden zur Zeit die Modelle Ulitimate Hub, Ultimate Smart Control, Ultimate, Smart Keyboard sowie alle darauf basierenden Kombinationen mit Smart Control und Smart Keyboard Add-On.

== Define ==
define <hub> harmony <ip>

==Allgemeines==
Aktivitäten und Geräte lassen sich an allen Stellen entweder als ID oder als Name angeben. Wenn der Name angegeben wird müssen hierbei Leerzeichen durch einen Punkt ersetzt werden. Dies kann auch für eventuell andere im Namen vorhandene Sonderzeichen gelten.

== Aktivität ==
Das Reading <code>currentActivity</code> enthält die gerade laufende Aktivität. Beim Wechsel zwischen Aktivitäten erzeugt es Events auf die in Fhem über ''notify'' reagiert werden kann. Das Reading <code>previousActivity</code> enthält die davor laufende Aktivität sofern diese bekannt ist. Dieses Reading erzeugt keine Events.

In den Internals <code>currentActivityID</code> und <code>previousActivityID</code> stehen die dazu gehörenden IDs der Aktivitäten.

Innerhalb einer laufenden Aktivität kann mit
set <hub> command <command>
ein IR-Kommando an eines der beteiligten Geräte gesendet werden.

== Geräteebene ==
Innerhalb und außerhalb einer laufenden Aktivität kann mit
set <hub> command <id|name> <command>
ein IR-Kommando an eines der im Hub bekannten Geräte gesendet werden. Hierbei ist darauf zu achten, dass innerhalb einer Aktivität keine Kommandos verwendet werden sollten, die den Smart-State betreffen.

=== Fhem Devices auf Geräteebene ===

Es ist möglich sich für einzelne oder alle im Hub konfigurierten Geräte ein zugehöriges FHEM-Device anlegen zu lassen:
set <hub> autocreate [<id|name>]

Beim Umschalten zwischen Aktivitäten wird in diesen FHEM-Devices wird im Reading power den in der Aktivität konfigurierten Einschaltzustand: on,off oder manual. Mit einem ''notify'' auf <code>power</code> Events lässt sich in Fhem auf einzelne Geräte reagieren.

'''Wichtig:''' Diese FHEM-Device spiegeln nicht den tatsächlichen Gerätezustand wieder, sondern den innerhalb einer Aktivität beabsichtigen Zustand. Der tatsächliche Zustand kann z.b. auf Grund von Empfangsproblemen abweichen.

Das get <code>commands</code> sowie die set <code>command</code>, <code>hidDevice</code>, <code>text</code>, <code>cursor</code> und <code>special</code> Kommandos auf Hub-Ebene stehen hier direkt und ohne Angabe von Device-ID oder Name zur Verfügung.

== Smart Keyboard ==
Der Harmony Hub kann über Bluetooth oder die zum Smart Keyboard gehörenden USB-Dongel mit einem Rechner, Media PC oder sonstigem Gerät, das Tastatureingabe unterstützt, verbunden werden. Fhem kann diese Verbindung nutzen, um beliebige Tastendrücke an ein solches Gerät zu senden. Das können Texte sein, Cursorbewegungen oder die Power-, Multimedia oder sonstigen Funktionstasten, die das Gerät unterstützt.

Alle gesendeten Tastendrücke beziehen sich normalerweise auf das zur gerade laufenden Aktivität gehörende Tastatureingabegerät. Mit dem <code>hidDevice</code> Kommando lässt sich die Tastatureingabe auf jedes im Hub dafür konfigurierte Gerät umschalten.

'''Wichtig:''' Dieses Umschalten kann einige Sekunden dauern, da hierbei die bestehende Bluetooth-Verbindung getrennt und eine neue aufgebaut wird.

Es stehen die Kommandos <code>text</code>, <code>cursor</code> und <code>special</code> zur Verfügung.

Beispiele:

Gehe in PLEX auf die Library Musik und spiele das erste Item in der OnDeck Liste:
set <hub> text M
set <hub> cursor right
set <hub> text p

== Beispiele ==

=== Vorgeschaltete Funksteckdose ansteuern ===

'''Vorbereitung Harmony'''

Nachdem die Geräte mit Strom versorgt werden, benötigen Sie einige Sekunden, bis Sie ihre Einschaltsignale verarbeiten können. Diese Verzögerung wird durch ein Dummy Gerät in jeder Aktion erzeugt.

1) In MyHarmony einen Amazon Fire TV anlegen und ihm einen passenden Namen geben (z.B. Pause)

2) Unter "Geräte" dieses markieren und per "Ändern der Betriebseinstellungen" die Einstellungen aufrufen

3) Punkt "Ich möchte dieses Gerät eingeschaltet lassen, wenn Aktionen gewechselt werden und nur durch Drücken der Off-Taste ausschalten" auswählen

4) Einen harmlosen Befehl einfügen ("Search"), danach eine Verzögerung von 5000ms einbauen und dann noch einen Befehl ("Search"). Dies bewirkt eine Verzögerung von 5 Sekunden beim Ein- und Ausschalten

5) Unter Aktionen die Aktion auswählen und per "Einstellung ändern" das neue Gerät hinzufügen

6) Per "Diese Aktion anpassen" das neue Gerät an die erste Stelle schieben

7) Schritte 5-7 für alle Aktionen wiederholen

'''Konfiguration in FHEM'''

1) Der Harmony Hub muss existieren

#Harmony Hub Wohnzimmer definieren
define wz_harmonyhub harmony 192.168.123.123

2) Ihr benötigt eine fertig konfigurierte Funksteckdose (hier "wz_Multimedia")

3) Ihr baut eine Bedingung, die auf den Ein- und Ausschaltvorgang des Harmony Hub (hier wz_harmonyhub) reagiert und die Steckdose (hier wz_Multimedia) schaltet. Es wird eine '''zusätzliche''' Pause genutzt von 0 Sekunden bei der ersten Bedingung (wäre kontraproduktiv) und 10 Sekunden bei der zweiten Bedingung (DOELSEIF). Bei der Nutzung eines Beamers lässt sich hierüber die Abkühlzeit einstellen. Im Beispiel bleiben den Geräten somit 15 Sekunden zum Ausschalten und 5 Sekunden um die Empfangsbereitschaft herzustellen.

#Auf den Schaltvorgang des Hubs reagieren
define wz_Multimedia_Automatik DOIF ([wz_harmonyhub:currentActivity] ne "PowerOff") (set wz_Multimedia on) DOELSEIF ([wz_harmonyhub:currentActivity] eq "PowerOff") (set wz_Multimedia off)
attr wz_Multimedia_Automatik wait 0:10

== Weblinks ==
* [http://myharmony.com myHarmony] Logitech Harmony Hersteller
* [http://www.harmony-remote-forum.de/portal.php Harmony Remote Forum] deutsches Harmony Forum
* [http://forum.fhem.de/index.php/topic,14163.0.html Thread im FHEM Forum] Weitere Infos im FHEM Forum Thread

[[Kategorie:Unterhaltungselektronik]]
[[Kategorie:IP Components]]

HomeMatic Firmware Update

2015-01-06T08:39:16Z

Rohan: *Anmerkungen zu möglichen Problemen

== Varianten für Firmwareupdates ==
Seit 2014 ist es möglich bei einigen [[HomeMatic]] Komponenten selbst Firmware Updates durchzuführen. Vorher ging das nur per CCU oder durch Einsenden des Gerätes an ELV.
Dabei gibt es verschiedene Möglichkeiten das Firmware Update durchzuführen. Um in Fhem die aktuelle Firmware nach dem Update angezeigt zu bekommen, ist ein erneutes Pairen mit Fhem notwendig. Es muss aber nicht gelöscht oder zurückgesetzt werden.

=== Firmware Update mit CUL/HM-CFG-USB unter FHEM ===
FW Updates sind in FHEM möglich. Benötigt wird dafür ein CUL oder ein HM-CFG-USB. Mit einem HMLAN ist ein Update nicht möglich.
Vor dem Update ist sicherzustellen, dass das korrekte IO für das Device genutzt wird (falls mehrere IOs im System zu Verfügung stehen). Siehe Attribut IODev und IOgrp bei der Verwendung einer vCCU.
Um das Update durchführen zu können, wird die in dem entsprechenden Zip-File vorhandene .eq3-Datei benötigt. Bitte genau darauf achten, dass nicht aus versehen ein falsches Firmware-File verwendet wird. Der Vorgang selbst erfolgt mittels folgenden Befehl:
set <device> fwUpdate <filename> [<time>]
<filename> ist der Name des .eq3 Files inkl. absolutem oder relativem Pfad zu fhem-Root.
Die Angabe von [<time>] ist optional. Es ist die Zeit, die FHEM wartet, bis das Device in den Bootloader versetzt wird. Bei den meisten Devices ist die Zeit nicht notwendig, da FHEM das Gerät selbst in den Bootloader-Mode versetzen kann.
Bei einigen älteren FW-Versionen wie zB bei den RT v1.0 geht das allerdings nicht automatisch. Um den Flashvorgang zu starten, müssen hier noch die Batterien entfernt werden und beim wiedereinlegen die beiden äußeren Knöpfe gedrückt werden. Jene Zeit, die man für eben diese Aktion benötigt, wird hier eingegeben.

Wichtig - Während des Updates können keine weiteren Nachrichten in FHEM von Homematic verarbeitet werden.

Da nach dem Update immer noch die alte FW-Version in FHEM steht, kann man entweder bei einigen Geräten die Version mit:
set <device> getVersion
auslesen oder wenn das Kommando wie zB bei den RTs nicht zur Verfügung steht, genügt es, am Gerät selbst den Config-Button zu drücken (was am Beispiel der RTs bedeutet, dass die Boost-Taste für min. 3 Sekunden gedrückt werden muss). Nach dem Aktualisieren des FW-Stand in FHEM, muss die FHEM-Config noch gespeichert werden, damit die neue Information auch noch nach dem nächsten Neustart vorhanden ist.

=== Firmware Update mit CUL/HM-CFG-USB unter Linux ===
Für Linux hat mgernoth ein Updatetool programmiert.

Als erstes müssen wir sicherstellen, dass alle benötigten Pakete installiert sind. Um das Tool zu installieren und auszuführen werden unter Debian die Pakete aus dem folgenden apt-get Befehl benötigt:
sudo apt-get install libusb-1.0-0-dev git build-essential

Als nächstes wird der Sourcecode für das Tool heruntergeladen (vorher zB in den Pfad /usr/src wechseln):
git clone git://git.zerfleddert.de/hmcfgusb

Und erzeugen daraus eine ausführbare Datei:
cd hmcfgusb
make

Nun Laden wir die nötige Firmware herunter und entpacken diese. Die offiziellen Updates gibt es unter [http://www.eq-3.de/downloads.html eq-3 Downloads]. Alle Befehle um an das benötigte eq-3 für die Firmware Version 1.2 des HM-CC-RT-DN zu gelangen lauten:
wget http://www.eq-3.de/Downloads/Software/Firmware/hm_cc_rt_dn_update_V1_2_007_131202.tar.gz
tar xvzf hm_cc_rt_dn_update_V1_2_007_131202.tar.gz

Zu guter Letzt müssen wir nur noch das Tool mit einigen Parametern und der Seriennummer des HomeMatic Devices aufrufen.

Für ein Update mit einem CUL muss folgendes eingegeben werden (/dev/ttyACM0 ist die Adresse des CULs):
sudo ./flash-ota -c /dev/ttyACM0 -f hm_cc_rt_dn_update_V1_2_007_131202.eq3 -s KEQ1234567

Für ein Update mit einem COC muss folgendes eingegeben werden (/dev/ttyAMA0):
sudo ./flash-ota -c /dev/ttyAMA0 -f hm_cc_rt_dn_update_V1_2_007_131202.eq3 -s KEQ1234567

Für ein Update mit HM-CFG-USB
sudo ./flash-ota -f hm_cc_rt_dn_update_V1_2_007_131202.eq3 -s KEQ1234567

Nun muss nur noch das HomeMatic Gerät in den Update-Modus versetzt werden. Wie das geht, steht in der jeweils mitgelieferten ReadMe der Firmwaredatei.

=== Firmware Update mit HM-CFG-USB unter Windows ===

Für ein Firmwareupdate unter Windows wird das "HomeMatic Firmware Update Tool" von eq-3 benötigt: [http://www.eq-3.de/downloads.html eQ-3 Downloads]. Zur Zeit ist das Update damit nur mit dem HM-CFG-USB-2 möglich, nicht aber mit dem HM-CFG-LAN oder dem HM-CFG-USB der ersten Generation.

Nach dem Start muss die Seriennummer des HomeMatic-Device eingegeben und die Firmware-Datei ausgewählt werden. Dann wird das Update-Tool durch einen Klick auf den entsprechenden Button in "Bereitschaft" gesetzt und anschließend muss das HomeMatic-Gerät in den Update-Modus versetzt werden.

Falls das Update-Tool beim Auswählen der Firmware-Datei abstürzt ("Home Matic Firmware Update Tool funktioniert nicht mehr"), dann stimmt wahrscheinlich etwas mit der Firmware-Datei nicht. Die Datei darf nicht ausgepackt, sondern muss als ".tar.gz"-Datei, so wie sie heruntergeladen wurde, benutzt werden. Es kann Probleme geben, wenn die Datei mit dem Internet Explorer heruntergeladen wurde. Am einfachsten ist es, die Datei mit einem anderen Browser herunterzuladen.

== Mögliche Probleme ==

Lässt sich die Firmware nicht OTA auf das HomeMatic-Device flashen, kann dies folgende Ursachen haben:

* Die Fhem-Software ist nicht auf dem neuesten Stand. Bitte vorher ein ''update'' durchführen.
* '''Entfernung''' zwischen Sender und Empfänger '''zu klein'''. 1,5 bis 2 m Abstand sollten beide Geräte zueinander mindestens haben.
* '''Entfernung''' zwischen Sender und Empfänger '''zu groß'''. Überprüfen Sie die RSSI-Werte des zu flashenden Device. Schlechter als - 70 sollten sie nicht sein (also keine - 75 oder noch kleiner). Ansonsten muss der Abstand für die Dauer des Flashens verringert werden.
* <bei Bedarf ergänzen>

== Links ==
* [http://www.eq-3.de/downloads.html Firmware Download] Seite von eq-3
* [git://git.zerfleddert.de/hmcfgusb Firmware Update Tool] von mgernoth

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

Plots erzeugen

2015-01-03T15:13:47Z

Rohan: /* Plot der letzten 24 Stunden statt des aktuellen Tages */

'''Plots erzeugen'''

== .gplot-Editor ==

Fhem verfügt über einen ".gplot-Editor", um die .gplot-Datei zur Erstellung eines Plots menügeführt zu generieren. Ein manuelles Anlegen der .gplot-Datei ist für Spezialisten und normalerweise nicht notwendig. Der .gplot-Editor sollte für Standardfälle grundsätzlich verwendet werden.

Details zum .gplot-Editor können im Ankündigungshinweis im {{Link2Forum|Topic=11275|Message=75594|LinkText=Fhem-Forum}} nachgelesen werden.

Spezielle Erläuterungen zur Erzeugung von Plots mit Stati: {{Link2Forum|Topic=12945|Message=78887|LinkText=Fhem-Forum}}, [[EnOcean-STM-250-Fenster-Türkontakt#Türstatus in einem Plot darstellen|Schrittweises Beispiel bei Kontakten]], [[EnOcean-D-452-FU-EBIM-Aktor-2fach#Aktorstatus_in_einem_Plot_darstellen|Schrittweises Beispiel zum Aktorstatus]]

Verhinderung von Perl-Warnungen bei LogFiles mit unterschiedlicher Spaltenanzahl in Log-Zeilen: {{Link2Forum|Topic=12945}}

<big>'''Achtung'''</big>:

Verwenden Sie diesen Editor nicht, wenn das Fhem-Device bereits angelegt ist und Sie für dieses Device ein bestehendes, allgemeines gplot-File verwenden, das auch für andere Devices benutzt wird. Beim Abspeichern wird ein Filter im gplot-File gesetzt, das das gplot-File nur für genau dieses Device verwendbar macht.

Beispiel:

aus

#FileLog 4:::

wird

#FileLog 4:DS2423.energy_a\x3a::

in dem entsprechenden gplot-File.

Die anderen Devices, die evtl. dieses gplot-File verwenden, haben danach keine funktionierende Plot-Anzeige mehr. Bevor also etwas geändert wird, sollte mit

set weblink_irgendwas copyGplotFile

ein Duplikat angelegt werden, das ausschließlich für diesen Plot verwendet wird. Der Befehl kann unterhalb des ersten Kasten per Dropdown ausgewählt werden.

== Individuell / Manuell ==

'''Vorbemerkungen:'''

* Fhem bedient sich für die Erstellung der Plots des Programms ''Gnuplot'' [http://www.gnuplot.info/]. Hierbei reichen die "einfacheren" Funktionalitäten dieses Programms aus (''Gnuplot'' kann noch viel mehr).
* die Beispieldateien für die in Fhem integrierten Plots finden Sie in Ihrem Fhem-Programmordner unter ''www/gplot''.
* Angaben wie <SIZE>, <OUT>, <L1>, <IN> usw. im Plot-File sind Platzhalter bzw. Feldbezeichner für Fhem. Diese sind case-sensitive (Groß-/Kleinschreibung beachten).

Ein Beispiel (''temp4hum4.gplot'') aus diesem Verzeichnis:

# Attribute 'small' is useful for gnuplot/-scroll only,
# if plotsize is less than 800,400
#set terminal png transparent small size <SIZE> crop

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 ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics

set y2label "Temperature in C"
set ylabel "Humidity (%)"

#FileLog 4:temperature:10:
#FileLog 4:humidity:50:

plot \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Measured temperature' with lines,\
"< egrep 'humidity' <IN>"\
using 1:4 axes x1y1 title 'Humidity (%)' with lines\

Die Zeilen, die mit ''set'' beginnen, beeinflussen wesentlich das Erscheinungsbild und Aussehen Ihrer Plots (Achsenbeschriftungen, Skalen usw.). Dabei sollten Sie die Zeilen, die eine Angabe zwischen "<" und ">" enthalten, zunächst unverändert lassen. Weitere (ausführliche) Hinweise (zu Gnuplot!) finden Sie in einer [http://www.home.uni-osnabrueck.de/elsner/Skripte/gnuplot.pdf PDF-Datei]. Eingeschränktere, aber für die meisten Belange von Fhem ausreichende Infos finden Sie auf [http://www.aurbacher.net/gnuplot/gnuplot.html dieser Web-Seite].

=== Benutzung der Variablen ===
{| class="wikitable"
! Variable
! Nutzung in gplot-File
! Füllung mit inhalt in fhem.cfg
|-
| <TL>
| set title '<TL>'
| attr weblink title "Dies füllt den Platzhalter <TL>"
|-
| <L1>
| set xlabel '<L1>'
| attr weblink label "Dies füllt das Label <L1>"
|-
| <L2>
| set title '<L2>'
| attr weblink label "Dies füllt das Label <L1>"::"Dies füllt das Label <L2>"
|}

=== Welche Daten werden dargestellt ===

Die Zeilen

#FileLog 5::0:
#FileLog 14::0:

in einer gplot-Datei tragen zwar zu Beginn das Kommentarzeichen "#", jedoch handelt es sich durchaus nicht um solche. Vielmehr trifft man mit den Werten hinter ''FileLog'' Vorgaben, welche Werte wie von Fhem an ''gnuplot'' zwecks grafischer Darstellung übergeben werden

Im o.a. Beispiel werden das 5. und das 14. Wertfeld (voneinander getrennt durch ein Leerzeichen (Blank)) an gnuplot weiter gegeben.

Eine dazu passende Log-Dateizeile könnte beispielsweise so aussehen

2013-11-14_17:32:00 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200
----1. Feld-------- --2. Feld-- --3.---- -4.- -5. -6. 7. 8. -9. 10. 11 12 --13.- --14.---

^ ^
werden ausgewertet --| --|

Diese Parameter können auch als attribut übergeben werden:

attr weblink plotfunction "FileLog 5::0:"

Anhand der Anmerkungen wird hoffentlich die Wirkweise deutlich. Zu den restlichen - optionalen - Parametern hinter ''FileLog'' wird zunächst auf die [http://fhem.de/commandref.html#FileLogget commanref] verwiesen.

=== Datum und Zeit ===

'''Anmerkungen / Hinweise:'''

Fhem erwartet das Datum '''und''' die Uhrzeit der Log-Dateieinträge '''zwingend''' an <ins>erster Stelle</ins> der Datenzeile und zwar im Format

<code>
JJJJ-MM-TT_SS:mm:ss
</code>

wobei

* JJJJ die 4-stellige Jahreszahl
* MM der 2-stellige Monat (ggfls. mit Vornull)
* TT der 2-stellige Tag (ggfls. mit Vornull)
* SS die 2-stellige Stunde (ggfls. mit Vornull)
* mm die 2-stellige Minute (ggfls. mit Vornull)
* ss die 2-stellige Sekunde (ggfls. mit Vornull)

bedeutet. Bitte beachten Sie auch die Stelle der Zeichen "-", "_" und ":". Stehen diese nicht an den angegebenen Stellen, wird die entsprechende Zeile beim Erzeugen des Plots nicht beachtet. Ggfls. wird gar kein Plot angezeigt.

Eine Änderung/Anpassung der *.gplot-Datei in der Zeile

set timefmt "..."

hat auf dieses Verhalten von Fhem '''keine''' Auswirkungen, sondern nur auf die Darstellung von Datum und Zeit durch ''Gnuplot'' .

Dazu ein Beispiel:

Mit

2013-11-14_17:32:00 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200

kann Fhem etwas anfangen. Mit

20131114173200 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200

oder

14.11.2013 17:32 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200

dagegen nicht.

Im ersten Fehler-Beispiel fehlen die notwendigen Trennzeichen, im zweiten Fehler-Beispiel ist die Reihenfolge im Datum verkehrt, außerdem werden die falschen Trenner verwendet. Zudem fehlen die Sekunden.

=== Plot der letzten 24 Stunden statt des aktuellen Tages ===

Hierzu kann man in der ''Fhem.cfg'' für die Einträge

define WEB FHEMWEB 8083 global

das Attribut

attr WEB endPlotNow 1

setzen. Gleiches geht auch für ''WEBphone'' und ''WEBtablet''. Da muss es dann lauten

attr WEBphone endPlotNow 1

bzw.

attr WEBtablet endPlotNow 1

Das Attribut gilt dann aber für '''alle''' Plots der jeweiligen Ansichten. Wenn man wieder zurück zu den Plots ab jeweils 00:00 Uhr des aktuellen Tages möchte, löscht man dieses Attribut wieder bzw. setzt es auf den Wert "0".

[[Kategorie:FAQ]]
[[Kategorie:HOWTOS]]

Plots erzeugen

2015-01-03T15:09:31Z

Rohan: Anmerkungen zu "Plot der letzten 24 Stunden statt des aktuellen Tages" hinzugefügt

'''Plots erzeugen'''

== .gplot-Editor ==

Fhem verfügt über einen ".gplot-Editor", um die .gplot-Datei zur Erstellung eines Plots menügeführt zu generieren. Ein manuelles Anlegen der .gplot-Datei ist für Spezialisten und normalerweise nicht notwendig. Der .gplot-Editor sollte für Standardfälle grundsätzlich verwendet werden.

Details zum .gplot-Editor können im Ankündigungshinweis im {{Link2Forum|Topic=11275|Message=75594|LinkText=Fhem-Forum}} nachgelesen werden.

Spezielle Erläuterungen zur Erzeugung von Plots mit Stati: {{Link2Forum|Topic=12945|Message=78887|LinkText=Fhem-Forum}}, [[EnOcean-STM-250-Fenster-Türkontakt#Türstatus in einem Plot darstellen|Schrittweises Beispiel bei Kontakten]], [[EnOcean-D-452-FU-EBIM-Aktor-2fach#Aktorstatus_in_einem_Plot_darstellen|Schrittweises Beispiel zum Aktorstatus]]

Verhinderung von Perl-Warnungen bei LogFiles mit unterschiedlicher Spaltenanzahl in Log-Zeilen: {{Link2Forum|Topic=12945}}

<big>'''Achtung'''</big>:

Verwenden Sie diesen Editor nicht, wenn das Fhem-Device bereits angelegt ist und Sie für dieses Device ein bestehendes, allgemeines gplot-File verwenden, das auch für andere Devices benutzt wird. Beim Abspeichern wird ein Filter im gplot-File gesetzt, das das gplot-File nur für genau dieses Device verwendbar macht.

Beispiel:

aus

#FileLog 4:::

wird

#FileLog 4:DS2423.energy_a\x3a::

in dem entsprechenden gplot-File.

Die anderen Devices, die evtl. dieses gplot-File verwenden, haben danach keine funktionierende Plot-Anzeige mehr. Bevor also etwas geändert wird, sollte mit

set weblink_irgendwas copyGplotFile

ein Duplikat angelegt werden, das ausschließlich für diesen Plot verwendet wird. Der Befehl kann unterhalb des ersten Kasten per Dropdown ausgewählt werden.

== Individuell / Manuell ==

'''Vorbemerkungen:'''

* Fhem bedient sich für die Erstellung der Plots des Programms ''Gnuplot'' [http://www.gnuplot.info/]. Hierbei reichen die "einfacheren" Funktionalitäten dieses Programms aus (''Gnuplot'' kann noch viel mehr).
* die Beispieldateien für die in Fhem integrierten Plots finden Sie in Ihrem Fhem-Programmordner unter ''www/gplot''.
* Angaben wie <SIZE>, <OUT>, <L1>, <IN> usw. im Plot-File sind Platzhalter bzw. Feldbezeichner für Fhem. Diese sind case-sensitive (Groß-/Kleinschreibung beachten).

Ein Beispiel (''temp4hum4.gplot'') aus diesem Verzeichnis:

# Attribute 'small' is useful for gnuplot/-scroll only,
# if plotsize is less than 800,400
#set terminal png transparent small size <SIZE> crop

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 ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics

set y2label "Temperature in C"
set ylabel "Humidity (%)"

#FileLog 4:temperature:10:
#FileLog 4:humidity:50:

plot \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Measured temperature' with lines,\
"< egrep 'humidity' <IN>"\
using 1:4 axes x1y1 title 'Humidity (%)' with lines\

Die Zeilen, die mit ''set'' beginnen, beeinflussen wesentlich das Erscheinungsbild und Aussehen Ihrer Plots (Achsenbeschriftungen, Skalen usw.). Dabei sollten Sie die Zeilen, die eine Angabe zwischen "<" und ">" enthalten, zunächst unverändert lassen. Weitere (ausführliche) Hinweise (zu Gnuplot!) finden Sie in einer [http://www.home.uni-osnabrueck.de/elsner/Skripte/gnuplot.pdf PDF-Datei]. Eingeschränktere, aber für die meisten Belange von Fhem ausreichende Infos finden Sie auf [http://www.aurbacher.net/gnuplot/gnuplot.html dieser Web-Seite].

=== Benutzung der Variablen ===
{| class="wikitable"
! Variable
! Nutzung in gplot-File
! Füllung mit inhalt in fhem.cfg
|-
| <TL>
| set title '<TL>'
| attr weblink title "Dies füllt den Platzhalter <TL>"
|-
| <L1>
| set xlabel '<L1>'
| attr weblink label "Dies füllt das Label <L1>"
|-
| <L2>
| set title '<L2>'
| attr weblink label "Dies füllt das Label <L1>"::"Dies füllt das Label <L2>"
|}

=== Welche Daten werden dargestellt ===

Die Zeilen

#FileLog 5::0:
#FileLog 14::0:

in einer gplot-Datei tragen zwar zu Beginn das Kommentarzeichen "#", jedoch handelt es sich durchaus nicht um solche. Vielmehr trifft man mit den Werten hinter ''FileLog'' Vorgaben, welche Werte wie von Fhem an ''gnuplot'' zwecks grafischer Darstellung übergeben werden

Im o.a. Beispiel werden das 5. und das 14. Wertfeld (voneinander getrennt durch ein Leerzeichen (Blank)) an gnuplot weiter gegeben.

Eine dazu passende Log-Dateizeile könnte beispielsweise so aussehen

2013-11-14_17:32:00 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200
----1. Feld-------- --2. Feld-- --3.---- -4.- -5. -6. 7. 8. -9. 10. 11 12 --13.- --14.---

^ ^
werden ausgewertet --| --|

Diese Parameter können auch als attribut übergeben werden:

attr weblink plotfunction "FileLog 5::0:"

Anhand der Anmerkungen wird hoffentlich die Wirkweise deutlich. Zu den restlichen - optionalen - Parametern hinter ''FileLog'' wird zunächst auf die [http://fhem.de/commandref.html#FileLogget commanref] verwiesen.

=== Datum und Zeit ===

'''Anmerkungen / Hinweise:'''

Fhem erwartet das Datum '''und''' die Uhrzeit der Log-Dateieinträge '''zwingend''' an <ins>erster Stelle</ins> der Datenzeile und zwar im Format

<code>
JJJJ-MM-TT_SS:mm:ss
</code>

wobei

* JJJJ die 4-stellige Jahreszahl
* MM der 2-stellige Monat (ggfls. mit Vornull)
* TT der 2-stellige Tag (ggfls. mit Vornull)
* SS die 2-stellige Stunde (ggfls. mit Vornull)
* mm die 2-stellige Minute (ggfls. mit Vornull)
* ss die 2-stellige Sekunde (ggfls. mit Vornull)

bedeutet. Bitte beachten Sie auch die Stelle der Zeichen "-", "_" und ":". Stehen diese nicht an den angegebenen Stellen, wird die entsprechende Zeile beim Erzeugen des Plots nicht beachtet. Ggfls. wird gar kein Plot angezeigt.

Eine Änderung/Anpassung der *.gplot-Datei in der Zeile

set timefmt "..."

hat auf dieses Verhalten von Fhem '''keine''' Auswirkungen, sondern nur auf die Darstellung von Datum und Zeit durch ''Gnuplot'' .

Dazu ein Beispiel:

Mit

2013-11-14_17:32:00 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200

kann Fhem etwas anfangen. Mit

20131114173200 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200

oder

14.11.2013 17:32 2013-Nov-14 17:32:00 17.9 5.8 4.9 58 94 0.0 0.0 N 5.8 572.91 1015.200

dagegen nicht.

Im ersten Fehler-Beispiel fehlen die notwendigen Trennzeichen, im zweiten Fehler-Beispiel ist die Reihenfolge im Datum verkehrt, außerdem werden die falschen Trenner verwendet. Zudem fehlen die Sekunden.

=== Plot der letzten 24 Stunden statt des aktuellen Tages ===

Hierzu kann man in der ''Fhem.cfg'' für die Einträge

define WEB FHEMWEB 8083 global

das Attribut

attr WEB endPlotNow 1

setzen. Gleiches geht auch für ''WEBphone'' und ''WEBtablet''. Da muss es dann lauten

attr WEBphone endPlotNow 1

bzw.

attr WEBtablet endPlotNow 1

Das Attribut gilt dann aber für '''alle''' Plots der jeweiligen Ansichten.

[[Kategorie:FAQ]]
[[Kategorie:HOWTOS]]

Readings in verschiedene Log-Dateien aufsplitten

2014-12-31T16:05:15Z

Rohan: Syntax-Fehler korrigiert und Kategorisierung

Aus verschiedenen Gründen kann es wünschenswert sein, die Readings eines Fhem-Devices in unterschiedliche Log-Dateien aufzuteilen. Dies kann man auch verwenden, um bestimmte Werte (Readings) '''nicht''' zu loggen.

Gegeben ist hier als Beispiel folgender Log-Dateiinhalt:

2014-12-09_11:12:32 DS2423_1 gaspower_B: 0
2014-12-09_11:12:32 DS2423_1 energy_A: 8148.093
2014-12-09_11:12:32 DS2423_1 power_A: 0.600743655234849
2014-12-09_11:12:32 DS2423_1 statEnergy_A: Hour: 0.068 Day: 3.570 Month: 102.140 Year: 102.140 (since: 2014-12-02 )
2014-12-09_11:12:32 DS2423_1 statEnergy_AHour: 0.068
2014-12-09_11:12:32 DS2423_1 statEnergy_ADay: 3.570
2014-12-09_11:12:32 DS2423_1 statEnergy_AMonth: 102.140
2014-12-09_11:12:32 DS2423_1 statEnergy_AYear: 102.140
2014-12-09_11:12:32 DS2423_1 energy_A: 8148.093
2014-12-09_11:12:32 DS2423_1 gasenergy_B: 536.9
2014-12-09_11:14:32 DS2423_1 counters.A: 8148103
2014-12-09_11:14:32 DS2423_1 counters.B: 5369
2014-12-09_11:14:32 DS2423_1 energy_A: 8148.103
2014-12-09_11:14:32 DS2423_1 power_A: 0.601512186542027
2014-12-09_11:14:32 DS2423_1 gaspower_B: 0
2014-12-09_11:14:32 DS2423_1 gasenergy_B: 536.9
2014-12-09_11:14:32 DS2423_1 statEnergy_A: Hour: 0.078 Day: 3.580 Month: 102.150 Year: 102.150 (since: 2014-12-02 )
2014-12-09_11:14:32 DS2423_1 statEnergy_AHour: 0.078
2014-12-09_11:14:32 DS2423_1 statEnergy_ADay: 3.580
2014-12-09_11:14:32 DS2423_1 statEnergy_AMonth: 102.150
2014-12-09_11:14:32 DS2423_1 statEnergy_AYear: 102.150
2014-12-09_11:14:32 DS2423_1 energy_A: 8148.103
2014-12-09_11:14:32 DS2423_1 gasenergy_B: 536.9
2014-12-09_11:16:32 DS2423_1 counters.A: 8148113
2014-12-09_11:16:32 DS2423_1 counters.B: 5369
2014-12-09_11:16:32 DS2423_1 gaspower_B: 0

Zum Hintergrund: Es handelt sich um einen per 1-Wire angeschlossenen DS2423-Zählers (zweifach), der die S0-Signale eines Gas- und eines Drehstromzählers mitzählt und deren Werte Fhem-intern in die entsprechenden Werte umgerechnet werden sowie um die Ausgabe des auf diese Werte angesetzten [http://fhem.de/commandref_DE.html#statistics Statistik-Moduls] von Fhem (alle Zeilen, die die Zeichenkette "stat" enthalten).

Geloggt wurden diese Werte (Readings) bisher mittels folgender Definitionen in einer Fhem-CFG-Datei:

define FileLog_DS2423_1 FileLog /opt/fhem/log/DS2423_1-%Y-%m.log DS2423_1

Nun sollen die Zeilen mit "stat..." und die anderen (also ohne "stat...") in '''getrennte''' Log-Dateien geschrieben werden. Dazu braucht es folgende Defintionen:

# Basis-Readings des Device
define FileLog_DS2423_1 FileLog /opt/fhem/log/DS2423_1-%Y-%m.log DS2423_1:(?!statEnergy).*

Hierdurch werden alle Readings, die '''nicht''' die Zeichenkette "statEnergy" enthalten (also die Basiswerte), in die angegebene Datei ''DS2423_1-%Y-%m.log'' geschrieben. Wichtig ist das "!", welches die Bedingung negiert.

Mittels

# Logfile für Werte des Statistik-Moduls zum DS2423_1
define FileLog_DS2423_1_Stat FileLog /opt/fhem/log/DS2423_1_Stat-%Y-%m.log DS2423_1:(statEnergy).*

werden die Readings, welche die Zeichenkette "statEnergy" enthalten, in die Log-Datei ''DS2423_1'''_Stat'''-%Y-%m.log'' geschrieben.

[[Kategorie:HOWTOS]]

HM-CC-TC Funk-Wandthermostat

2014-12-30T07:51:57Z

Rohan: /* Temperaturlisten */ Typo

'''HM-CC-TC Funk-Wandthermostat'''

Programmierbarer Raumthermostat, der bis zu 4 [[HM-CC-VD Funk-Stellantrieb]] steuern kann.

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt).'''

Nachfolgeprodukt ist der [[HM-CC-RT-DN]] bzw. (ab März 2014) [[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]].

= Features =
* Am Raumthermostat programmierbare Tages- und Nachttemperatur.
* Pro Wochentag können bis zu 24 Schaltpunkte definiert werden.
* Anbindung von <ins>jeweils</ins> '''maximal''' 4 Tür- bzw. Fensterkontakten ([[HM-Sec-RHS]]) zur Absenkung der Temperatur auf einen eigens eingestellten Temperaturwert (ab Werk: 12°C) bei offenem Fenster bzw. offener Tür.
* Anzeige der Temperatur und Luftfeuchtigkeit im Raum und Hintergrundbeleuchtung des Displays.

Alle 120 bis 184 Sekunden überträgt der Wandthermostat vorhandene Befehle zu den Stellantrieben. Jeder empfangene Befehl wird vom Stellantrieb bestätigt und dann ausgeführt. Täglich gegen Mitternacht synchronisiert ein HM-CC-TC seine Uhrzeit mit der HomeMatic-Zentrale (CCU, HMLAN).

= Hinweise zum Betrieb mit FHEM =
Vor dem Einsatz mit einer Zentrale sind erst alle Stellantriebe und Tür-/Fensterkontakte mit dem HM-CC-TC zu verbinden (P'''ee'''r).
Damit das ganze dann in FHEM auftaucht, muss der TC noch mit dem [[HMLAN Konfigurator]] gep'''ai'''rt werden.

Mit

<nowiki>set CUL hmPairForSec 300</nowiki>
setzt man das CUL / den HMLAN-Konfigurator für 5 Minuten in den Anlernmodus. Danach am Thermostaten 5 Sekunden lang die OK-Taste drücken und es wird eine Zeit von 20 auf 0 Sekunden gezählt:

* Klappt das Anlernen in diesen 20 Sekunden, wird der Countdown sofort beendet, anschließend für ca. 2-3 Sekunden "OK" angezeigt und der Thermostat ist in FHEM eingebunden.
* Gelingt das Anlernen nicht in den 20 Sekunden, erscheint nach Erreichen der "0" noch für 2 bis 3 Sekunden ein "NOK" ('''N'''ot '''OK''') im Display des TCs.

'''Alternativ'''(und so vom Entwickler des Fhem-HomeMatic-Moduls empfohlen) kann wie folgt vorgegangen werden:

* Alle Stellantriebe und Tür-/Fensterkontakte sowie den HM-CC-TC mit Fhem p'''ai'''ren (also ''set CUL hmPairForSec 300'' und an allen Devices den Anlernknopf drücken innerhalb des Zeitfensters von 300 Sekunden).
* Die Stellantriebe und Tür-/Fensterkontakte mit den ''Channels'' (siehe unten) p'''ee'''ren (siehe <nowiki>[http://fhem.de/commandref.html#CUL_HMpeerChan commandref :peerChan]</nowiki>). Hierzu werden die entsprechenden Fhem-Befehle über das Webinterface von Fhem erteilt.

'''Hinweis:'''
* Alle in der FHEM-Eingabezeile eingegebenen ''attr''-, ''define''-Befehle usw. müssen zum Schluss noch per Klick auf den "Save"-Button dauerhaft in der ''fhem.cfg'' gespeichert werden, sonst sind sie nach z.B. einem Systemabsturz verloren.
* Falls in der FHEM-Weboberfläche für ihren HM-CC-TC etwas wie ''X CMDs pending'' steht, sollten Sie ihren HM-CC-TC zur Hand nehmen und für 20 Sekunden auf die OK-Taste drücken. Dadurch werden alle noch ausstehenden Befehle eingelesen.

== Auszug aus der fhem.cfg ==
Die nachfolgenden Einstellungen zum HM-CC-TC werden von FHEM <ins>weitestgehend</ins> automatisch gesetzt. Die Pfadangaben für die Log-Dateien sind system-, die Raumbenennungen benutzerabhängig. Zu ''autoReadReg''und ''expert''siehe unten. Neben dem eigentlichen Basis-Gerät (HM-CC-TC) werden in FHEM automatisch noch 3 weitere "Unter"-Geräte (Channels/Kanäle), nämlich

* ''_Weather''
* ''_Climate''
* ''_WindowRec''

definiert (durch das Anlernen des TC an FHEM; siehe unten), deren Benennung sich (jeweils mit einem vorangestellten Unterstrich "_") am Namen des Basis-Gerätes orientiert.

'''Anmerkung:'''Die in den unten gezeigten ''fhem.cfg''-Auszügen markierten <ins>Peer</ins>-Einträge tauchen erst auf, sobald man die Daten aus dem TC mit ''set HM-CC-TC-Basisname getConfig''bzw. ''autoReadReg''ausgelesen hat.

=== Hauptgerät ===
<nowiki>define <HM-CC-TC>.Heizung CUL_HM 1DA491
attr <HM-CC-TC>.Heizung actCycle 000:10
attr <HM-CC-TC>.Heizung actStatus alive
attr <HM-CC-TC>.Heizung autoReadReg 1
attr <HM-CC-TC>.Heizung devInfo 00FFFF
attr <HM-CC-TC>.Heizung expert 2_full
attr <HM-CC-TC>.Heizung firmware 2.1
attr <HM-CC-TC>.Heizung hmClass receiver
attr <HM-CC-TC>.Heizung model HM-CC-TC
attr <HM-CC-TC>.Heizung room <IhrRaum>
attr <HM-CC-TC>.Heizung serialNr JE********
attr <HM-CC-TC>.Heizung subType thermostat</nowiki>
=== Channel (Kanal) 01 _Weather ===
<nowiki>define <HM-CC-TC>.Heizung_Weather CUL_HM 1DA49101 <<<=== 01 = Kanal 1
attr <HM-CC-TC>.Heizung_Weather model HM-CC-TC
attr <HM-CC-TC>.Heizung_Weather peerIDs
attr <HM-CC-TC>.Heizung_Weather room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_Weather FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_Weather-%Y-%m.log <HM-CC-TC>.Heizung_Weather
attr FileLog_<HM-CC-TC>.Heizung_Weather logtype text
attr FileLog_<HM-CC-TC>.Heizung_Weather room CUL_HM,<IhrRaum></nowiki>
=== Channel (Kanal) 02 _Climate ===
<nowiki>define <HM-CC-TC>.Heizung_Climate CUL_HM 1DA49102 <<<=== 02 = Kanal 2
attr <HM-CC-TC>.Heizung_Climate model HM-CC-TC
attr <HM-CC-TC>.Heizung_Climate peerIDs 1AD52B01,1B7A4C01,1C4CD101,1C48EC01, <<<=== gepeerte HM-CC-VDs
attr <HM-CC-TC>.Heizung_Climate room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_Climate FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_Climate-%Y-%m.log <HM-CC-TC>.Heizung_Climate
attr FileLog_<HM-CC-TC>.Heizung_Climate logtype text
attr FileLog_<HM-CC-TC>.Heizung_Climate room CUL_HM,<IhrRaum></nowiki>
=== Channel (Kanal) 03 _WindowRec ===
<nowiki>define <HM-CC-TC>.Heizung_WindowRec CUL_HM 1DA49103 <<<=== 03 = Kanal 3
attr <HM-CC-TC>.Heizung_WindowRec model HM-CC-TC
attr <HM-CC-TC>.Heizung_WindowRec peerIDs 1CFBB001, <<<=== gepeerte HM-Sec-SCs
attr <HM-CC-TC>.Heizung_WindowRec room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_WindowRec FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_WindowRec-%Y-%m.log <HM-CC-TC>.Heizung_WindowRec
attr FileLog_<HM-CC-TC>.Heizung_WindowRec logtype text
attr FileLog_<HM-CC-TC>.Heizung_WindowRec room CUL_HM,<IhrRaum></nowiki>
== Einstellungen eines HM-CC-TC lesen, anzeigen und sichern ==
=== expert ===
Anfang Februar 2013 wurde eine Änderung bei der Anzeige der so genannten ''Readings'' (Register usw.), also der Einstellungen bzw. Eigenschaften eines HM-Devices, eingeführt. '''Alle''' Werte sieht man nur noch, wenn man am HM-CC-TC das Attribut ''expert'' auf ''2_all'' setzt. Per '''default''' (nicht in ''fhem.cfg'' gesetzt) steht dieser Wert auf ''0_off'' (nur die notwendigsten Readings/Eigenschaften werden angezeigt). Mittelweg ist der Wert ''1_on''.

Mittels

<nowiki>attr <HM-CC-TC-Name> expert 2_full</nowiki>
in der FHEM-Befehlszeile mit anschließendem <Enter> setzt man diesen Level.

Falls man mit '''Temperaturlisten''' arbeitet (siehe unten), dann kann man die komplette Liste im "Channel" (Kanal) ''<HM-CC-TC-Name>__Climate'' einsehen. Auch für diesen Kanal ist evtl. ein setzen des Attributes ''expert 2_full'' angeraten.

<ins>Anmerkung:</ins> Es gibt auch noch sogenannte "hidden datas" (versteckte interne Werte, Register oder Eigenschaften deren Namen mit einem "." beginnen). Diese sieht man nur dann, wenn auch das Attribut ''showInternalValues 1'' gesetzt ist (default: 0 bzw. nicht gesetzt).

=== autoReadReg ===
Mitte Januar 2013 wurde das neue Attribut ''autoReadReg'' eingeführt, welches auf ''0'' voreingestellt ist (kein Eintrag in der ''fhem.cfg''). Das Setzen dieses Attributes auf ''1'' bewirkt, dass <ins>beim Neustart von FHEM</ins> die Einstellungen des entsprechenden HM-Gerätes ausgelesen werden. Dies wird bei mehreren ''autoReadReg''s automatisch zeitversetzt vorgenommen, um die Funk-Kommunikation nicht unnötig zu belasten.

Mittels

<nowiki>attr <HM-CC-TC-Name> autoReadReg 1 </nowiki>
in der FHEM-Befehlszeile mit anschließendem <Enter> setzt man diesen Wert.

=== list ===
Um sich alle Eigenschaften/Readings eines Gerätes anzusehen, gibt es den Befehl ''list''.

Mittels

<nowiki>list <HM-CC-TC-Name></nowiki>
und Bestätigung mit <Enter> erhalten Sie die gewünschte Anzeige Ihres TCs <ins>incl.</ins> seiner 3 Channels. Über

<nowiki>list <HM-CC-TC-Name>_<Channel-Name></nowiki>
werden nur die Daten des angegebenen Channels angezeigt.

=== Einstellungen sichern ===
Die Durchführung von ''autoReadReg'' kann durchaus mehrere Minuten dauern. Anschließend besteht die Möglichkeit, diese per

<nowiki>get HM-CC-TC-Basisname saveConfig [/Verzeichnis/mit/Schreibrechten/]<Dateiname></nowiki>
für jedes HM-CC-TC getrennt zu sichern (für eine später notwendige Wiederherstellung). Die Sicherungsdatei wird regulär im ''modpath'' (siehe ''fhem.cfg'') abgelegt. Falls dies nicht zum Erfolg führt (es wird - ohne Fehlermeldungen bei regulärem ''verbose'' und ''loglevel'' - im ''modpath'' keine Datei angelegt), müssen Sie vor dem Dateinamen einen vollständigen Pfad mit Schreibrechten für den Benutzer, unter dem FHEM läuft, angeben.

In der <ins>Log-Datei</ins> von FHEM erscheinen danach Meldungen folgender Art

<nowiki><Datum>_<Zeit> 2: CUL_HM set <HM-CC-TC-Name> statusRequest rxt:12
<Datum>_<Zeit> 2: CUL_HM set <HM-CC-TC-Name> getConfig rxt:12</nowiki>
Hierbei kann es (im <ins>Event monitor</ins> von FHEM) zu folgenden Fehlermeldungen kommen

<nowiki><Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:RegisterRead
<Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:PeerList
<Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:StatusReq</nowiki>
Diese Meldungen können auch mehrfach pro Gerät auftreten. Dann hat das Auslesen der Einstellungen nicht geklappt und sollte nochmals durchgeführt werden. Dafür muss man FHEM aber nicht neu starten, sondern das HM-Device per

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
in der Befehlszeile von FHEM und anschließendem <Enter> (nicht "save") darauf einstellen.

Die Channels (z.B. <HM-CC-TC-Name>_Climate, _Weather, _WindowRec) eines HM-Gerätes brauchen nicht (können aber bei Bedarf) separat ausgelesen bzw. gesichert zu werden, da sie Bestandteil der Basisabfrage sind.

== Funkprobleme auffangen ==
Der wohl am häufigsten an den HM-CC-TC gesendete Befehl ist "set desired-temp", mit dem die Wunschtemperatur neu gesetzt wird.
Funktioniert dieser Befehl jedoch nicht zuverlässig, wird die Wohnung ggf. zu lange oder nicht rechtzeitig beheizt.
Der folgende Mechanismus soll die Sicherheit erhöhen, indem die Antworten des HM-CC-TC geprüft werden und ggf. das Funktelegramm erneut gesendet wird.

Um den Sollwert zum erneuten Senden des Funktelegramms verfügbar zu haben, wird ein dummy definiert:

<nowiki>define HM_TC_Solltemperatur dummy</nowiki>
Wann immer die Solltemperatur geändert wird, setzt man die neue desired-temp nicht nur auf dem HM-TC-CC (hier HM_TC genannt), sondern auch auf dem dummy. Der Befehl (z.B. in der [[Zuhause-Status|Routine zum HomeStatus]]) sieht dann so aus:

<nowiki>set HM_TC desired-temp 21;set HM_TC_Solltemperatur 21</nowiki>
Falls das ausgehende Funktelegramm verlorengeht, fehlt die Antwort "command accepted". Dies kann mit einem watchdog aufgefangen werden, der dann den Befehl an den HM-CC-TC erneut sendet:

<nowiki>define w_HM_TC watchdog HM_TC:set_desired-temp.* 00:02:30 HM_TC_Climate:CommandAccepted:.yes { \
Log 1, ">>>>>>>>> w_HM_TC desired temp - missing response.";\
fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\
}</nowiki>
Falls ein Fehler bei der Funkkommunikation auftritt, erhält man die Antwort "missing ACK" oder "NACK". Auch in diesem Fall soll das Telegramm zum Ändern der Wunschtemperatur erneut an den HM-CC-TC gesendet werden:

<nowiki>define n_HM_TC_err notify HM_TC:(MISSING.ACK.*|.*NACK.*) {\
Log 1, ">>>>>>>>> n_HM_TC desired temp - missing ack/nack.\n";\
fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\
}</nowiki>
Mit diesen beiden Helfern ist die Funkkommunikation zum HM-CC-TC sehr zuverlässig.

== Plots / Grafiken ==
=== Problem ===
Durch ''autocreate'' wird zwar ein Log angelegt, aber kein Plot (Grafische Auswertung). Dem kann man aber abhelfen (siehe unten).

=== Plots erzeugen ===
''PGM2'' ist die Standardansicht des Fhem-Web-Interfaces. Um hier Plots/Grafiken zu erzeugen einfach unter dem ''Filelog'' des Thermostaten das ''attr logtype'' auf ''temp4hum6:Plot,text'' setzen und es wird ein Plot-Link neben dem Text-Link angezeigt. Nun können Sie auf diesen Plot-Link klicken und ...

=== alternative Plots ===
Mit dem fht.gplot funktioniert die Anzeige der Ventilstellung (actuator) nicht.

Mit folgendem angepassten .gplot File wird die gemessene Temperatur und Ventilstellung angezeigt.

<nowiki>############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define <filelogname> FileLog /var/log/fhem/actuator_name-%Y.log <actuator_name>:(measured-temp|actuator).*

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 ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics

set y2label "Temperatur in C"
set ylabel "Ventil (%)"

#FileLog 4:measured:10:
#FileLog 4:actuator:50:

plot \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Temperatur in C' with lines,\
"< egrep 'actuator' <IN>"\
using 1:4 axes x1y1 title 'Ventil (%)' with lines\</nowiki>
=== Alles-drin-Plot ===
dazu nimmt man folgendes .gplot. Man/Fra beachte, dass hierfür alle Parameter nach der define-Anweisung in das Logfile geschrieben werden.

<nowiki>############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define <filelogname> FileLog /var/log/fhem/HM_CC_TC-%Y.log <HM_CC_TC-name>
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 ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics
set y2label "Temperature in C"
set ylabel "Actuator (%)"
#FileLog 4:temperature:0:
#FileLog 4:desired:0:
#FileLog 4:humidity:0:
#FileLog 4:actuator:0:int
plot \
"< awk '/temperature/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Measured temperature' with lines lw 2,\
"< awk '/desired/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Desired temperature' with steps,\
"< awk '/humidity/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Humidity (%)' with lines,\
"< awk '/actuator/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Actuator (%)' with lines\</nowiki>

== Steuerungsmodi ==
Das Wandthermostat hat 4 verschiedene Steuerungsmöglichkeiten:

* Auto (automatisch)
* Cent (Zentrale)
* Manu (manuell)
* Prog / Koffer-Symbol (Urlaubs/Party-Modus, wird hier nicht näher erörtert)

Der Steuerungsmodus wird über wiederholtes Drücken der linken Taste des HM-CC-TC ausgewählt bzw. gewechselt.

'''Hinweis:''' Durch das P'''ai'''ren des HM-CC-TC <ins>und</ins> der Stellantrieb sowie Tür-/Fensterkontakte an Fhem verlieren Sie '''nicht''' die Steuerungsmöglichkeiten. Im Gegenteil: Nur wenn auch die VDs usw. mit Fhem gep'''ai'''rt sind, haben Sie die Möglichkeit, auch diese zu überwachen. Die Steuerung '''können''' Sie dennoch allein dem HM-CC-TC überlassen.

=== Auto-Modus ===
Im Modus '''Auto''' wird die Temperaturregelung über die im TC hinterlegten Temperaturlisten vorgenommen. Das Thermostat arbeitet also selbständig, somit unabhängig von einer Zentrale / FHEM. Nur in diesem Modus werden die evtl. per FHEM an das TC übermittelten "templist" abgearbeitet. Über das Senden von angepassten Temperatur-Listen kann eine indirekte Steuerung per FHEM erfolgen. '''Jederzeit''' kann zudem die Raumtemperatur über das Drehrad des Wandthermostaten oder die FHEM-Web-Oberfläche verändert werden. Diese ''Übersteuerung'' der Temperaturliste gilt bis zur nächsten Temperaturänderung nach der vorgenannten Liste.

=== Cent-Modus ===
Im Modus '''Cent''' steuert eine HomeMatic-Zentrale (CCU) oder eben ein FHEM-Server mit z.B. [[HMLAN Konfigurator]] zu den in der FHEM-Config hinterlegten Zeiten und mit den dort festgelegten Temperaturen. Fällt also die HM-Zentrale aus, erfolgt keine Steuerung der Thermostaten bzw. Heizungsventile mehr.

<ins>Anmerkung</ins>: Der Modus ''cent'' erscheint nur dann im Display des HM-CC-TC, wenn er an eine Zentrale bzw. das [[CUL]] angelernt (gepairt) wurde.

=== Manu-Modus ===
Der Modus '''Manu''' übersteuert die im TC hinterlegten Temperaturlisten und die evtl. von der HM-Zentrale / dem FHEM <ins>vor Umstellung auf ''Manu''</ins> gesendeten Einstellungen. Es wird also bis zur nächsten Modusumstellung bzw. manuellen Temperaturverstellung der per Einstellrad gesetzte Temperaturwert gefahren.

Aber auch in diesem Modus kann man die ''desired-temperature'' per FHEM verstellen. Der dadurch eingestellte Wert gilt ab sofort als der neue im ''Manu-Modus'' zu haltende Wert.

=== Auslesen des eingestellten Steuerungsmodus ===
Der eingestellte Steuerungsmodus erscheint normalerweise in den ''Readings'' des HM-CC-TC unter ''controlMode''. Zusätzlich haben Sie die Möglichkeit, diesen Modus auch in der FHEM-Weboberfläche ''everything'' => Abschnitt ''thermostat'' zu sehen, '''wenn''' Sie für den HM-CC-TC das folgende Attribut setzen:

<nowiki>attr <HM-CC-TC-Name> stateFormat T:measured-temp, H:humidity, VD:actuator, controlMode</nowiki>
Erscheint dort selbst nach einem

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
kein "Reading" ''controlMode'' oder keine Angabe des aktuell eingestellten Modus bzw. nur das Wort "controlMode", dann setzen Sie ihren HM-CC-TC von Hand in einen anderen Kontrollmodus und machen einen Browser-Refresh. Klappt dies nicht, geben Sie bitte erneut den Befehl

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
ein. Halten Sie anschließend die Taste <OK> am HM-CC-TC für 5 Sekunden gedrückt (oder warten ca. 5 Minuten) und machen in der FHEM-Weboberfläche einen Browser-Refresh (FF => <F5>). Jetzt sollte der manuell eingestellte Kontrollmodus erscheinen (ggfls. muss dieser Vorgang einmal wiederholt werden). Jetzt können Sie wieder den gewünschten Modus einstellen, erneut ein

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
absetzen und nach erneutem Drücken der <OK>-Taste für 5 Sekunden mit nachfolgendem Browser-Refresh sollte alles richtig angezeigt werden.

Dies setzt natürlich voraus, dass der HM-CC-TC richtig gepairt ist.

== Temperaturlisten ==
Die Temperaturlisten des TC werden identisch denen des RT bearbeitet und verwaltet, siehe [[HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Temperaturprofile|HM-CC-RT-DN]].
Beim TC ist der Kanal 4 (_Climate) für die Temperaturlisten zuständig (nicht _Clima wie beim RT!)

== Batteriealarme des HM-CC-VD in Verbindung mit HM-CC-TC ==
1. bei U-Bat. < 2,4 V erscheint im Display des VD und des TC das Batteriesymbol mit '''battery: low''' in den Readings und Events!

2. bei U-Bat. < 2,3 V erscheint im Display des VD zusätzlich '''F4''' mit '''battery: critical''' in den Readings und Events!

Es wird dringend geraten, die Batterien bei battery: low zu tauschen!

== Log-Auszug ==
HM-CC-TC sendet alle 2 Minuten folgenden Statusbericht:

<nowiki>Datum-Zeit <Device Name> T: 17.3 H: 66 
Datum-Zeit <Device Name> measured-temp: 17.3 
Datum-Zeit <Device Name> temperature: 17.3 
Datum-Zeit <Device Name> humidity: 66 
Datum-Zeit <Device Name> actuator: 96 % </nowiki>
Bei Status-Änderungen sendet HM-CC-TC auch entsprechende Meldungen, z.b.:

<nowiki>Datum-Zeit <Device Name> desired-temp: 15.5 </nowiki>

= Probleme =

== Verstellen der Solltemperatur am HM-CC-TC per Drehrad ==

'''Symptom:''' Beim Verstellen der Solltemperatur per seitlichem Drehrad wurde die aktuelle Solltemperatur - '''egal ob''' man hoch oder runter drehte - immer nur in 0,5 °C Schritten '''runter''' gestellt, bis schließlich die Mindesttemperatur von 6,0 °C erreicht war. Weitere Änderungen waren nicht möglich

'''Abhilfe:''' Letztlich half nur das kurzzeitige Entfernen einer Batterie. Das danach für einige Zeit erscheinende Batteriesymbol zeigte den kleinstmöglichen guten Zustand an, in FHEM wurde das ''Reading'' des Batteriezustandes mit ''ok'' ausgegeben (wie in den Logs aber vorher auch). '''Letztlich half aber nur''' das Einsetzen neuer Batterien, denn die o.a. Störung trat nach ca. 2 Stunden erneut auf. Die "alten" Batterien (die, die dem HM-CC-TC ab Werk beilagen) hatten somit eine Nutzungsdauer von knapp 11 Monaten, waren aber auch in einem HM-CC-TC, der mit 4 Stck. HM-Sec-SC (mussten sehr oft "Meldung machen") und 4 Stck. HM-CC-VD gepeert war. ''Ohne Last'' zeigten die beiden alten AA-Batterien eine Spannung von jeweils 1,29 V an.

'''Hinweis:''' Die unter ''Abhilfe'' beschriebene Lösung war leider nur von kurzer Dauer. Bereits kurz danach zeigte der HM-CC-TC die gleichen Ausfallerscheinungen. Bei ELV gibt es das Bauteil für das Drehrad (Inkrementalgeber) als [http://www.elv.de/inkrementalgeber-fuer-fs20-str-fht-8-und-homematic-hm-cc-tc.html Ersatzteil]. Sobald dieses geliefert und ein Reparaturversuch unternommen wurde, wird an dieser Stelle weiter berichtet.

== HM-CC-TC misst zu hohe/niedrige Luftfeuchte-Werte ==

'''Symptom:''' In den Fhem-Logs und demzufolge auch in den Plots/Grafiken eines seit über 18 Monaten im Einsatz befindlichen HM-CC-TC wurden viel zu hohe (einzelne Spitzenwerte von 98 oder 99 %) bzw. ständig zu niedrige (um die 20 oder sogar vereinzelt nur 2 %) Werte für die relative Luftfeuchte gemessen (im direkten Vergleich zu anderen HM-CC-TCs). Die anderen Werte (Temperatur, Actuator) waren aber schlüssig.

'''Abhilfe:''' Batteriewechsel. Die alten Batterien hatten (unbelastet) noch knapp über 1 V Spannung.

'''Hinweis:''' Eine Batteriewarnung des Gerätes gab es nicht. Im Display war das entsprechende Symbol noch auf 1 Balken.

= Firmware =
Aktuelle Firmware-Version: 2.1

= Links =
Anleitung [http://www.elv-downloads.de/service/manuals/76787_76175_HM_Wandthermostat_UM.pdf PDF]

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

Readings in verschiedene Log-Dateien aufsplitten

2014-12-29T21:36:55Z

Rohan: Link zur commandref, statistics-Modul, eingefügt

Aus verschiedenen Gründen kann es wünschenswert sein, die Readings eines Fhem-Devices in unterschiedliche Log-Dateien aufzuteilen. Dies kann man auch verwenden, um bestimmte Werte (Readings) '''nicht''' zu loggen.

Gegeben ist hier als Beispiel folgender Log-Dateiinhalt:

2014-12-09_11:12:32 DS2423_1 gaspower_B: 0
2014-12-09_11:12:32 DS2423_1 energy_A: 8148.093
2014-12-09_11:12:32 DS2423_1 power_A: 0.600743655234849
2014-12-09_11:12:32 DS2423_1 statEnergy_A: Hour: 0.068 Day: 3.570 Month: 102.140 Year: 102.140 (since: 2014-12-02 )
2014-12-09_11:12:32 DS2423_1 statEnergy_AHour: 0.068
2014-12-09_11:12:32 DS2423_1 statEnergy_ADay: 3.570
2014-12-09_11:12:32 DS2423_1 statEnergy_AMonth: 102.140
2014-12-09_11:12:32 DS2423_1 statEnergy_AYear: 102.140
2014-12-09_11:12:32 DS2423_1 energy_A: 8148.093
2014-12-09_11:12:32 DS2423_1 gasenergy_B: 536.9
2014-12-09_11:14:32 DS2423_1 counters.A: 8148103
2014-12-09_11:14:32 DS2423_1 counters.B: 5369
2014-12-09_11:14:32 DS2423_1 energy_A: 8148.103
2014-12-09_11:14:32 DS2423_1 power_A: 0.601512186542027
2014-12-09_11:14:32 DS2423_1 gaspower_B: 0
2014-12-09_11:14:32 DS2423_1 gasenergy_B: 536.9
2014-12-09_11:14:32 DS2423_1 statEnergy_A: Hour: 0.078 Day: 3.580 Month: 102.150 Year: 102.150 (since: 2014-12-02 )
2014-12-09_11:14:32 DS2423_1 statEnergy_AHour: 0.078
2014-12-09_11:14:32 DS2423_1 statEnergy_ADay: 3.580
2014-12-09_11:14:32 DS2423_1 statEnergy_AMonth: 102.150
2014-12-09_11:14:32 DS2423_1 statEnergy_AYear: 102.150
2014-12-09_11:14:32 DS2423_1 energy_A: 8148.103
2014-12-09_11:14:32 DS2423_1 gasenergy_B: 536.9
2014-12-09_11:16:32 DS2423_1 counters.A: 8148113
2014-12-09_11:16:32 DS2423_1 counters.B: 5369
2014-12-09_11:16:32 DS2423_1 gaspower_B: 0

Zum Hintergrund: Es handelt sich um einen per 1-Wire angeschlossenen DS2423-Zählers (zweifach), der die S0-Signale eines Gas- und eines Drehstromzählers mitzählt und deren Werte Fhem-intern in die entsprechenden Werte umgerechnet werden sowie um die Ausgabe des auf diese Werte angesetzten [http://fhem.de/commandref_DE.html#statistics Statistik-Moduls] von Fhem (alle Zeilen, die die Zeichenkette "stat" enthalten).

Geloggt wurden diese Werte (Readings) bisher mittels folgender Definitionen in einer Fhem-CFG-Datei:

define FileLog_DS2423_1 FileLog /opt/fhem/log/DS2423_1-%Y-%m.log DS2423_1

Nun sollen die Zeilen mit "stat..." und die anderen (also ohne "stat...") in '''getrennte''' Log-Dateien geschrieben werden. Dazu braucht es folgende Defintionen:

# Basis-Readings des Device
define FileLog_DS2423_1 FileLog /opt/fhem/log/DS2423_1-%Y-%m.log DS2423_1:(!statEnergy).*

Hierdurch werden alle Readings, die '''nicht''' die Zeichenkette "statEnergy" enthalten (also die Basiswerte), in die angegebene Datei ''DS2423_1-%Y-%m.log'' geschrieben. Wichtig ist das "!", welches die Bedingung negiert.

Mittels

# Logfile für Werte des Statistik-Moduls zum DS2423_1
define FileLog_DS2423_1_Stat FileLog /opt/fhem/log/DS2423_1_Stat-%Y-%m.log DS2423_1:(statEnergy).*

werden die Readings, welche die Zeichenkette "statEnergy" enthalten, in die Log-Datei ''DS2423_1'''_Stat'''-%Y-%m.log'' geschrieben.

Readings in verschiedene Log-Dateien aufsplitten

2014-12-29T21:19:41Z

Rohan: Die Seite wurde neu angelegt: „Aus verschiedenen Gründen kann es wünschenswert sein, die Readings eines Fhem-Devices in unterschiedliche Log-Dateien aufzuteilen. Dies kann man auch verwend…“

Aus verschiedenen Gründen kann es wünschenswert sein, die Readings eines Fhem-Devices in unterschiedliche Log-Dateien aufzuteilen. Dies kann man auch verwenden, um bestimmte Werte (Readings) '''nicht''' zu loggen.

Gegeben ist hier als Beispiel folgender Log-Dateiinhalt:

2014-12-09_11:12:32 DS2423_1 gaspower_B: 0
2014-12-09_11:12:32 DS2423_1 energy_A: 8148.093
2014-12-09_11:12:32 DS2423_1 power_A: 0.600743655234849
2014-12-09_11:12:32 DS2423_1 statEnergy_A: Hour: 0.068 Day: 3.570 Month: 102.140 Year: 102.140 (since: 2014-12-02 )
2014-12-09_11:12:32 DS2423_1 statEnergy_AHour: 0.068
2014-12-09_11:12:32 DS2423_1 statEnergy_ADay: 3.570
2014-12-09_11:12:32 DS2423_1 statEnergy_AMonth: 102.140
2014-12-09_11:12:32 DS2423_1 statEnergy_AYear: 102.140
2014-12-09_11:12:32 DS2423_1 energy_A: 8148.093
2014-12-09_11:12:32 DS2423_1 gasenergy_B: 536.9
2014-12-09_11:14:32 DS2423_1 counters.A: 8148103
2014-12-09_11:14:32 DS2423_1 counters.B: 5369
2014-12-09_11:14:32 DS2423_1 energy_A: 8148.103
2014-12-09_11:14:32 DS2423_1 power_A: 0.601512186542027
2014-12-09_11:14:32 DS2423_1 gaspower_B: 0
2014-12-09_11:14:32 DS2423_1 gasenergy_B: 536.9
2014-12-09_11:14:32 DS2423_1 statEnergy_A: Hour: 0.078 Day: 3.580 Month: 102.150 Year: 102.150 (since: 2014-12-02 )
2014-12-09_11:14:32 DS2423_1 statEnergy_AHour: 0.078
2014-12-09_11:14:32 DS2423_1 statEnergy_ADay: 3.580
2014-12-09_11:14:32 DS2423_1 statEnergy_AMonth: 102.150
2014-12-09_11:14:32 DS2423_1 statEnergy_AYear: 102.150
2014-12-09_11:14:32 DS2423_1 energy_A: 8148.103
2014-12-09_11:14:32 DS2423_1 gasenergy_B: 536.9
2014-12-09_11:16:32 DS2423_1 counters.A: 8148113
2014-12-09_11:16:32 DS2423_1 counters.B: 5369
2014-12-09_11:16:32 DS2423_1 gaspower_B: 0

Zum Hintergrund: Es handelt sich um einen per 1-Wire angeschlossenen DS2423-Zählers (zweifach), der die S0-Signale eines Gas- und eines Drehstromzählers mitzählt und deren Werte Fhem-intern in die entsprechenden Werte umgerechnet werden sowie um die Ausgabe des auf diese Werte angesetzten Statistik-Moduls von Fhem (alle Zeilen, die die Zeichenkette "stat" enthalten).

Geloggt wurden diese Werte (Readings) bisher mittels folgender Definitionen in einer Fhem-CFG-Datei:

define FileLog_DS2423_1 FileLog /opt/fhem/log/DS2423_1-%Y-%m.log DS2423_1

Nun sollen die Zeilen mit "stat..." und die anderen (also ohne "stat...") in '''getrennte''' Log-Dateien geschrieben werden. Dazu braucht es folgende Defintionen:

# Basis-Readings des Device
define FileLog_DS2423_1 FileLog /opt/fhem/log/DS2423_1-%Y-%m.log DS2423_1:(!statEnergy).*

Hierdurch werden alle Readings, die '''nicht''' die Zeichenkette "statEnergy" enthalten (also die Basiswerte), in die angegebene Datei ''DS2423_1-%Y-%m.log'' geschrieben. Wichtig ist das "!", welches die Bedingung negiert.

Mittels

# Logfile für Werte des Statistik-Moduls zum DS2423_1
define FileLog_DS2423_1_Stat FileLog /opt/fhem/log/DS2423_1_Stat-%Y-%m.log DS2423_1:(statEnergy).*

werden die Readings, welche die Zeichenkette "statEnergy" enthalten, in die Log-Datei ''DS2423_1'''_Stat'''-%Y-%m.log'' geschrieben.

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

2014-12-29T21:17:17Z

Rohan: Typo

Beim '''HM-CC-RT-DN''' handelt es sich um einen '''Funk-Heizkörperthermostaten mit integriertem Stellantrieb''', der als Nachfolger den [[HM-CC-VD]] ablöst und seit Mitte September 2013 verfügbar ist.

== Vorbemerkungen ==

Im Gegensatz zum Vorgänger misst der HM-CC-RT-DN selbst die Temperatur und verfügt über eine Boost-Funktion. Er braucht zur Steuerung kein separates Raumregelungsgerät mehr und hat eine eigene Fenster-Offen-Erkennung. Ein passender Wandthermostat ([[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]]) ist seit Februar 2014 verfügbar.

Das Gerät wird seit Anfang Oktober 2013 von Fhem unterstützt (siehe Diskussion im [http://forum.fhem.de/index.php/topic,14738.0.html 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 Firmware Update Software. Weitere Details sind unter [[HM-CC-RT-DN_Funk-Heizkörperthermostat#Firmware_Update|Firmware Update ]] beschrieben.

'''Achtung:''' Die Solltemperaturen eines HM-CC-RT-DN lassen sich <ins>nicht</ins> durch einen [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]] steuern. Dieser kann höchstens die Ist-Temperatur an den RT weiter geben, damit die Raumtemperatur nicht am RT selbst zur Ventilsteuerung genommen 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
gep'''ee'''rt 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.3

== Betrieb mit FHEM ==
Der Funk-Heizkörperthermostat muss zuerst mit Fhem [[HomeMatic_Devices_pairen|gepairt]] werden. Da es den RT noch nicht lange gibt, sollten Sie sicher stellen, 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 kann z.B. ein HomeMatic HM-WDS10-TH-O Funk-Temperatur-/Luftfeuchtesensor OTH dienen.

Der Befehl zum peeren lautet, wobei <tempSensor> die Fhem-Kanalbezeichnung für den Sensor ist und <rt_Weather> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates:
set <tempSensor> peerChan 0 <rt_Weather> single

==== Channel (Kanal) 02 _Climate ====
Der Climate-channel dient der Kommunikation mit einem Temperatur-Kontroller (aktuell nur [[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]]).
Zum peeren von TC und RT siehe [[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP#Hinweise zur Inbetriebnahme und Installation|HM-TC-IT-WM-W-EU]]

==== 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.
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]] näher 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 <rt_WindowRec> single

Zum Löschen (=unpeeren) dieser Kopplung:
set <fensterSensor> peerChan 0 <rt_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 <rt_WindowRec> regSet winOpnTemp <Temp> <fensterSensor>

==== Channel (Kanal) 04 _Clima ====
Dieser Kanal dient zum Einstellen der Betriebsparameter, auch [[#Temperaturlisten]] sind hierauf zu übrtragen.

'''Achtung:''' In älteren Versionen von Fhem wurde dieser Kanal durch autocreate als "_ClimRT_tr" angelegt. Der Hersteller hat hier offenbar die internen Bezeichnunen geändert, denn beim Vorläufernmodell HM-CC-TC mussten Temperaturlisten auf den Kanal ''Climate'' übertragen werden.

Die interne "Fenster-auf" Erkennung kann man wie folgt abschalten:
set <rt_Clima> regSet winOpnMode off

==== Channel (Kanal) 05 _ClimaTeam ====
Dieser Kanal dient zum peeren von mehreren Heizkörperthermostaten untereinander. 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 <rt1-ClimaTeam> und <rt2-ClimaTeam> die Kanalbezeichnungen der beiden ClimaTeam-Kanäle sind:
set <rt1-ClimaTeam> peerChan 0 <rt2-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:
<pre>set <button> peerChan 0 <rt-remote> single</pre>

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

Im Automode kann man die Temperatur am Einstellrad des RT ändern. Zum nächsten Schaltpunkt wird dies dann überschrieben. Will man dies nicht (z.B. lange Party, ...), kann man auf manuell schalten. Dann bleibt die mit dem Drehregler (oder der Zentrale) eingestellte Temperatur stehen bis ''ultimo''. Es gibt dann noch den Party- oder Urlaubsmodus. In diesen kann man den Automodus für eine gegebene Zeit überschreiben.

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

==== Modus Manu ====
Das Wochenprogramm wird nicht abgearbeitet, die Temperatur wird manuell eingestellt.

==== Modus Party (Urlaub) ====

Will man für eine festgesetzte Zeit (Stunden oder Tage) die Temperatur auf einen festen Wert einstellen (z.B. weil man in Urlaub fährt), kann man dies zwar auch durch Änderungen der Temperaturlisten erreichen, einfacher ist aber die Zuweisung über den Urlaubsmodus, da nach dessen Ablaufdatum und -zeitpunkt automatisch in den Auto-Modus gewechselt wird.

'''Ein Beispiel:'''

<pre>
set HM-CC-RT-DN_Clima controlParty 16 06.12.13 16:30 09.12.13 05:00
</pre>

Dadurch wird

* vom 06.12.2013, 16:30 Uhr,
* bis zum 09.12.2013, 05:00 Uhr
* die gewünschte Raumtemperatur auf 16 °C

eingestellt.

'''Hinweise:'''
* Der Befehl muss auf den Channel 4 ("_Clima") erfolgen.
* Es werden nur Uhrzeiten zu jeder vollen oder halben Stunde angenommen (Minuten also 00 oder 30).

Mit der Funktion "Urlaub" kann man eine ganze Wohnung (also mehrere RT´s) mit nur einem Befehl in den Party-mode versetzen. 
Der Name "Urlaub" kann natürlich frei gewählt werden.
Im Beispiel werden 2 Heizkörper (Treppenhaus und Kammer) angesteuert.

Zu beachten sind folgende Dinge:
# Aktuelle Dateien (z.B. 10_CUL_HM) verwenden!
# Bei dem partycontrol-Befehl in der Funktion KEIN Komma zwischen den Parametern.
# Bei der Funktion die Parameterübergabe definieren ($$$$$)

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

'''Funktion:'''
<pre>
my $Urlaub;
sub
Urlaub($$$$$)
{
#lokale Variablendeklaration
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/;

#Sendebefehl für ein HM-CC-RT-DN
{fhem ("set Kammer controlParty $temp $startDate $startTime $endDate $endTime")}

# alternative Schreibweise der Parameter:
{fhem ("set Treppenhaus controlParty @_[0] @_[1] @_[2] @_[3] @_[4]")};
}
</pre>

=== 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 Kommanods. 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 RT muss den Receiver wach halten. Der RT und alle anderen Burst-Devices erwachen bei '''jedem''' Burst (egal für wen) und legen sich dann wieder schlafen.
* jeder Burst-trigger kostet Batterie für '''alle''' Burst-Geräte im System
* wenn Burst enabled ist kostet es dem RT Batteriekapazität

'''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 messages 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 message. 
 
'''ConditionalBurst devices''' 
Devices mit abschaltbarem burst wie z.B. der 'HM-CC-RT-DN', gibt es ein Register burstRx mit dem das burst-erwachen eingestellt werden kann.
Sender, 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 Hminfo kommando 'models' um festzustellen, welche devices welchen mode 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) 
<pre>set WZ1_4 regSet burstRx on </pre>
prüfen mit: 
<pre>get WZ1_4 reg burstRx </pre>
''Nun in FHEM den Burst mode einschalten (sofern nicht burstXmit verwendet wird)'' 
<pre>attr WZ1 burstAccess 1_auto</pre>

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

=== Temperaturprofile ===
Im Kanal ''Clima'' kann man einen Wochenplan (ein Temperaturprofil) hinterlegen. Im automatischen Betrieb stellt der Heizkörperhermostat dann die Wunschtemperatur gemäß diesem Profil ein. Die Daten werden in Registern des Heizkörperthermostates abgelegt, es gibt gesonderte Kommandos zur Verwaltung des Profils. Die Darstellung des Temperaturprofils unterliegt aber dennoch den Regeln der Register: Fhem muss die Daten aus dem Device lesen (getConfig), um sie darzustellen.
Ändert man eine der Temperaturlisten müssen die Daten an das Device übertragen werden. Bis dies bestätigt ist wird in Reading '''R_tempList_State''' '''set''' angezeigt. Sobald die daten aus dem Device zurückgelesen sind steht wird es auf '''verified''' gesetzt (sollte der Normalzustand sein). '''incomplete''' wird gesetzt, falls beim Lesen der Register ein Teil der Daten nicht empfangen wurde.
==== Manuelle Änderung ====
Mit dem Kommando
set <rt>_Clima tempListMon 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0
kann man das Temperaturprofil für den Wochentag ''Montag'' einstellen. Die nach dem Schaltzeitpunkt stehende Temperatur gilt immer '''bis''' zu diesen Zeitpunkt, nicht ab diesem Zeitpunkt. Der letzte Wert muss immer Mitternacht (24:00) sein.
damit ist also 00:00 - 05:30 = 16Grad, 05:30 - 07:30 = 18 Grad. Die Zeit kann in Schritten von 30min eingestellt werden, die Temperatur in 0.1 Grad.
Der Tage beginnt immer um 00:00, der letzte Abschnitt MUSS 24:00 sein.

Ändert man mehrere Tage auf einmal sollte man unbedingt mit "prep" und "exec" arbeiten, da es sonst zu Wiederholungen und langen Bearbeitungen kommen kann. Prep bereitet die Änderung in FHEM nur vor, mit exec werden die Daten dann an das Device übertragen. Das könnte in einem Fhem-Script lauten
sub
SetTempList_UG_Treppe_Heizung()
{
{ fhem ("set UG.Treppe.Heizung_Clima tempListMon prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListTue prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListWed prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListThu prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListFri prep 05:30 16.0 07:00 18.0 15:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListSat prep 07:00 16.0 09:00 18.0 15:00 18.5 21:00 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_Clima tempListSun '''exec''' 07:00 16.0 09:00 18.0 15:00 18.5 21:00 19.0 24:00 16.0")};
}

==== Temperaturprofile in einer Datei====
Eleganter ist die Verwaltung von Temperaturprofilen in einer Datei. Damit kann man
* 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

===== Dateiformat =====
Die Temperaturprofile werden in einer Datei abgelegt im Format
entities:room1
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 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
entities:room2,room3
tempListSat>08:00 18.0 15:00 18.0 21:30 19.0 24:00 14.0
tempListSun>08:00 18.0 15:00 18.0 21:30 19.0 24:00 14.0
...

* '''entities''' ist eine komma-separierte Liste der Namen des folgenden Temperaturprofils. Das erste Temperaturprofil im Beispiel hat den Namen "room1", das 2. hat zwei Namen, "room2" und "room3".
* '''tempList...''' ist die Liste der Schaltzeiten und Temperaturen des Tages. Die nach dem Schaltzeitpunkt stehende Temperatur gilt immer '''bis''' zu diesen Zeitpunkt, nicht ab diesem Zeitpunkt. Der letzte Wert muss immer Mitternacht (24:00) sein.

===== Temp Profil Datei erstellen/updaten =====
Mit HMInfo kann man eine Temperaturdatei ???  oder updaten.
set hm tempList save <filename>
set hm tempList save -f <channelName> <filename>
Die Temperaturlisten der Devices, ggf. nur der gefilterten Devices - werden in das File abgelegt. Sollte für die Entity bereits ein Eintrag vorhanden sein wird dieser ersetzt. Vorhandene weitere Einträge werden nicht geändert. Das save ist unabhängig von attribut tempListTmpl.
Default für Filename ist "tempList.cfg". Als Entity wird der Name des Kanals genutzt.

===== Überprüfen/Einlesen =====
Mit dem verify-Kommando wird überprüft, ob das gegenwärtig vorhandene Temperaturprofil mit dem in der Datei befindlichen übereinstimmt.
set <rt>_Clima tempListTmpl verify FHEM/tempList.cfg:room1
Mit dem restore-Kommando wird das Temperaturprofil des Heizkörperthermostaten mit dem in der Datei befindlichen überschrieben.
set <rt>_Clima 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 <rt>_Clima tempListTmpl FHEM/tempList.cfg:room1
set <rt>_Clima 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 <rt>_Clima tempListTmpl restore
überschreibt das gegenwärtige Temperaturprofil des Heizkörperthermostaten mit dem in der Datei befindlichen überschrieben.
===== Vorschlag =====
Zur Verwaltung der Temperaturprofile sollte die Datei tempList.cfg im Verzeichnis FHEM liegen, dann kann sie mit dem Web-Interface editiert werden.
Wenn man im Sommer allen HKs das gleiche Profil geben will, kann man dies in der Datei erstellen und weist allen das template zu. Hier ein Beispiel für RT's:
attr TYPE=CUL_HM:FILTER=DEF=......04:FILTER=model=HM-CC-RT-DN tempListTmpl tempList.cfg:sommer
set hm tempListTmpl restore
set hm tempListTmpl verify
Nach dem Restore natürlich warten, bis die Daten geschrieben sind.

==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 15.07.2014 gibt es für den HM-CC-RT-DN die neue Firmware Version 1.3. 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.

== 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. Nähere Informationen zu dieser Funktion siehe [[FHEM_Command_Beispiele#update_...|hier]].

== Links ==
* [http://www.elv.de/homematic-heizkoerperthermostat-1.html Produktinfo]
* [http://www.elv-downloads.de/Assets/Produkte/10/1051/105155/Downloads/105155_thermostat_um.pdf Bedienungsanleitung (PDF)]
* [http://www.elv-downloads.de/Assets/Produkte/10/1051/105155/Downloads/105155_thermostat_data.pdf Datenblatt (PDF)]
* [http://www.elv-downloads.de/service/manuals/ventilkompatibilitaet.pdf Ventil-Kompatibilitätsliste (PDF)]

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

HM-CFG-LAN: Überwachung der 1%-Regel

2014-12-10T20:09:54Z

Rohan: /* Plot von Highload/Overload und msgLoadEst-Werten */ Es fehlte eine Absatzschaltung im Code

== Einleitung ==
Gerade in der Entwicklungsphase kann es passieren, dass z.B. durch den Einsatz von Testroutinen der Bereich der [[1% Regel]] erreicht wird und dadurch ein Gerät vorübergehend nicht mehr senden kann.

In solchen Situationen kann es von Nutzen sein, mittels Plot einen Überblick über die aktuelle Auslastung zu bekommen, um eigene Codefehler von dem werksseitig eingebauten Sendestopp zu unterscheiden. Am Beispiel eines [[HomeMatic]]-Gerätes wird im Folgenden gezeigt, wie eine derartige "Überwachung" erreicht werden kann.

=== "ERROR-Overload" und "Warning-HighLoad" ===
Der Sendestopp der HMLAN-unit wird durch die Werte "ERROR-Overload" angezeigt bzw. durch "Warning-HighLoad" vorgewarnt. Dabei handelt es sich um direkte Readings der HMLAN-unit und sind auf alle Fälle als richtig bzw. "absolut" anzusehen. Sollte die HMLAN-unit in diesen Zustand sein, wird sie keine Telegramme mehr senden, jedoch wird sie weiterhin alle Telegramme empfangen.

=== "msgLoadEst 1hour" ===
Die angezeigten "msgLoadEst" - Werte stellen keine 100%ige Genauigkeit dar, da sie "nur" annähernd berechnet werden können. Es kann daher theoretisch vorkommen, dass der Plot die 100% - Marke noch nicht erreicht hat, aber der "ERROR-Overload" Indikator bereits anzeigt, dass die HMLAN-unit seine Sendungen eingestellt hat.

<pre>
msgLoadEst 1hour:44% 10min steps: 12/2/7/23/0/0
</pre>

besagt, dass in der aktuellen Stunde 44% der Sendekapazität verbraucht sind. Im aktuellen 10min-Rahmen sind es 12%, in den 10min davor waren es 2%, davor 7% und davor 23%.

Dieser Zähler befindet sich direkt in der HMLAN-unit somit kann FHEM diesen Zähler nicht zurücksetzen. Nur durch Warten oder einen Reset der HMLAN-unit ist ein Rückstellen möglich.

== Einschränkungen ==

Man muss die folgenden Einschränkungen hinsichtlich des Plots immer beachten:

* Nach dem (shutdown)-restart fängt FHEM wieder bei 0 an zu zählen. Da die HMLAN-unit aber nicht zwangsläufig ebenfalls reseted wurde, kann bereits eine messageload in der HMLAN-unit vorliegen die fhem aufgrund des restarts nicht erfassen kann.

* FHEM kann nicht zwischen einem reboot und einem disconnect der HMLAN-unit unterscheiden. Daher wird ein disconnect als reboot gewertet. Dies führt unter Umständen ebenfalls zu einer "ERROR-Overload" - Nachricht obwohl der Plot die 100%-Marke noch nicht erreicht hat.

* FHEM kann die automatischen Wiederholungen der HMLAN-unit nicht erfassen und können daher nicht berücksichtigt werden.

* Die AES Verschlüsselung, die weitere Telegramme sendet, kann aktuell nicht gezählt werden

== Versions Updates ==
[http://forum.fhem.de/index.php/topic,21678.msg151621.html#msg151621 Version 5278]: Die Länge des Nachrichtentelegrams wird berücksichtigt.

== Plot von Highload/Overload und msgLoadEst-Werten ==

[[Datei:Msgloadest_2_2.png|mini|350px|rechts|Beispiel-Plot mit einer Auslastung von ca. 80%]]
Dazu muss im Einzelnen wie folgt vorgegangen werden:
* Um einen Plot erzeugen zu können, wird ein Log benötigt.
* Um ein Log erzeugen zu können, wird ein Event benötigt, das geloggt werden kann.
* Um das Event loggen zu können, wird ein [http://de.wikipedia.org/wiki/Cronjob CronJob] benötigt, der dieses Event wiederholt im Abstand x bereitstellt.

Der CronJob wird mittels "at" im Zeitabstand x= 1 Minute als Reading bereitgestellt, das den Wert von "msgLoadEst-1hour" erhält. Hierdurch werden 60 Werte pro Stunde in die Logdatei geschrieben. Sollte dies zu Performanceeinbußen auf Seiten des [[Systemübersicht#Server|Fhem-Trägersystems]] führen, kann der "+*00:01:00"-Wert entsprechend erhöht werden.

Erforderliche Definition in der [[Konfiguration]] (fhem.cfg):
<pre>
define a_hmlan_internals at +*00:01:00 {\
my $trafficStr = InternalVal("HMLAN1","msgLoadEst","???");;\
my $trafficHour = $1 if($trafficStr =~ m/1hour:(.*)% 10min steps/);;\
fhem("setreading HMLAN1 hmTrfHour ".$trafficHour." %" );;\
}
</pre>

Dadurch wird ein Event ausgelöst, das (z.B. mit den folgenden Definitionen) geloggt werden kann:
<pre>
define FileLog_Technik_IO FileLog %L/Technik_IO-%Y-%M.log global:.*|HMLAN1:cond:.*|HMLAN1:hmTrfHour:.*
attr FileLog_Technik_IO logtype text
attr FileLog_Technik_IO room Log
</pre>

Die graphische Darstellung (Plot) wird durch die Definition
<pre>
define SVG_FileLog_Technik_IO_1 SVG FileLog_Technik_IO:SVG_FileLog_Technik_IO_1:CURRENT
# attr SVG_FileLog_Technik_IO_1 alias 10. hmlan
attr SVG_FileLog_Technik_IO_1 label "traffic: min [$data{min1}] - avg [$data{avg1}] - max [$data{max1}] - last [$data{currval1}] ----- [".localtime()."]"
attr SVG_FileLog_Technik_IO_1 room 90_Technik
</pre>

... in Verbindung mit folgenden [[Plots erzeugen|Plot]]-Anweisungen (im vorgestellten Beispiel in der SVG_FileLog_Technik_IO_1.gplot Datei) erzeugt:
<pre>
# Created by FHEM/98_SVG.pm, 2014-03-22 12:11:58 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 '<L1>'
set ytics "init" 6,"err" 4,"wng" 3,"?" 1,"ok" 0 set y2tics set grid y2tics set ylabel "condition"
set y2label "msgLoadEst % / hr"
set yrange [0:7]

#FileLog 4:HMLAN1.hmTrfHour\x3a::
#FileLog 4:HMLAN1.cond\x3a::$fld[3]=~"init"?6:$fld[3]=~"ERROR-Overload"?4:$fld[3]=~"Warning-HighLoad"?3:$fld[3]=~"ok"?0:1
#FileLog 3:global.*::$fld[2]=~"SHUTDOWN"?6:$fld[2]=~"INITIALIZED"?0:0

plot "<IN>" using 1:2 axes x1y2 title 'msgLoadEst' ls l6fill lw 1 with steps,\
"<IN>" using 1:2 axes x1y1 title 'condition' ls l0 lw 1 with steps,\
"<IN>" using 1:2 axes x1y1 title 'shutdown' ls l2fill lw 1 with steps
</pre>

== Links ==
* Beitrag / Diskussion zu diesem Thema im [http://forum.fhem.de/index.php/topic,21678.msg151772.html#msg151772 Fhem Forum]

[[Kategorie:HOWTOS]]
[[Kategorie:Code Snippets]]

HM-CC-TC Funk-Wandthermostat

2014-08-01T21:56:57Z

Rohan: /* HM-CC-TC misst zu hohe/niedrige Luftfeuchte-Werte */ kleine Ergänzung zu den Wertangaben

'''HM-CC-TC Funk-Wandthermostat'''

Programmierbarer Raumthermostat, der bis zu 4 [[HM-CC-VD Funk-Stellantrieb]] steuern kann.

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt).'''

Nachfolgeprodukt ist der [[HM-CC-RT-DN]] bzw. (ab März 2014) [[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]].

= Features =
* Am Raumthermostat programmierbare Tages- und Nachttemperatur.
* Pro Wochentag können bis zu 24 Schaltpunkte definiert werden.
* Anbindung von <ins>jeweils</ins> '''maximal''' 4 Tür- bzw. Fensterkontakten ([[HM-Sec-RHS]]) zur Absenkung der Temperatur auf einen eigens eingestellten Temperaturwert (ab Werk: 12°C) bei offenem Fenster bzw. offener Tür.
* Anzeige der Temperatur und Luftfeuchtigkeit im Raum und Hintergrundbeleuchtung des Displays.

Alle 120 bis 184 Sekunden überträgt der Wandthermostat vorhandene Befehle zu den Stellantrieben. Jeder empfangene Befehl wird vom Stellantrieb bestätigt und dann ausgeführt. Täglich gegen Mitternacht synchronisiert ein HM-CC-TC seine Uhrzeit mit der HomeMatic-Zentrale (CCU, HMLAN).

= Hinweise zum Betrieb mit FHEM =
Vor dem Einsatz mit einer Zentrale sind erst alle Stellantriebe und Tür-/Fensterkontakte mit dem HM-CC-TC zu verbinden (P'''ee'''r).
Damit das ganze dann in FHEM auftaucht, muss der TC noch mit dem [[HMLAN Konfigurator]] gep'''ai'''rt werden.

Mit

<nowiki>set CUL hmPairForSec 300</nowiki>
setzt man das CUL / den HMLAN-Konfigurator für 5 Minuten in den Anlernmodus. Danach am Thermostaten 5 Sekunden lang die OK-Taste drücken und es wird eine Zeit von 20 auf 0 Sekunden gezählt:

* Klappt das Anlernen in diesen 20 Sekunden, wird der Countdown sofort beendet, anschließend für ca. 2-3 Sekunden "OK" angezeigt und der Thermostat ist in FHEM eingebunden.
* Gelingt das Anlernen nicht in den 20 Sekunden, erscheint nach Erreichen der "0" noch für 2 bis 3 Sekunden ein "NOK" ('''N'''ot '''OK''') im Display des TCs.

'''Alternativ'''(und so vom Entwickler des Fhem-HomeMatic-Moduls empfohlen) kann wie folgt vorgegangen werden:

* Alle Stellantriebe und Tür-/Fensterkontakte sowie den HM-CC-TC mit Fhem p'''ai'''ren (also ''set CUL hmPairForSec 300'' und an allen Devices den Anlernknopf drücken innerhalb des Zeitfensters von 300 Sekunden).
* Die Stellantriebe und Tür-/Fensterkontakte mit den ''Channels'' (siehe unten) p'''ee'''ren (siehe <nowiki>[http://fhem.de/commandref.html#CUL_HMpeerChan commandref :peerChan]</nowiki>). Hierzu werden die entsprechenden Fhem-Befehle über das Webinterface von Fhem erteilt.

'''Hinweis:'''
* Alle in der FHEM-Eingabezeile eingegebenen ''attr''-, ''define''-Befehle usw. müssen zum Schluss noch per Klick auf den "Save"-Button dauerhaft in der ''fhem.cfg'' gespeichert werden, sonst sind sie nach z.B. einem Systemabsturz verloren.
* Falls in der FHEM-Weboberfläche für ihren HM-CC-TC etwas wie ''X CMDs pending'' steht, sollten Sie ihren HM-CC-TC zur Hand nehmen und für 20 Sekunden auf die OK-Taste drücken. Dadurch werden alle noch ausstehenden Befehle eingelesen.

== Auszug aus der fhem.cfg ==
Die nachfolgenden Einstellungen zum HM-CC-TC werden von FHEM <ins>weitestgehend</ins> automatisch gesetzt. Die Pfadangaben für die Log-Dateien sind system-, die Raumbenennungen benutzerabhängig. Zu ''autoReadReg''und ''expert''siehe unten. Neben dem eigentlichen Basis-Gerät (HM-CC-TC) werden in FHEM automatisch noch 3 weitere "Unter"-Geräte (Channels/Kanäle), nämlich

* ''_Weather''
* ''_Climate''
* ''_WindowRec''

definiert (durch das Anlernen des TC an FHEM; siehe unten), deren Benennung sich (jeweils mit einem vorangestellten Unterstrich "_") am Namen des Basis-Gerätes orientiert.

'''Anmerkung:'''Die in den unten gezeigten ''fhem.cfg''-Auszügen markierten <ins>Peer</ins>-Einträge tauchen erst auf, sobald man die Daten aus dem TC mit ''set HM-CC-TC-Basisname getConfig''bzw. ''autoReadReg''ausgelesen hat.

=== Hauptgerät ===
<nowiki>define <HM-CC-TC>.Heizung CUL_HM 1DA491
attr <HM-CC-TC>.Heizung actCycle 000:10
attr <HM-CC-TC>.Heizung actStatus alive
attr <HM-CC-TC>.Heizung autoReadReg 1
attr <HM-CC-TC>.Heizung devInfo 00FFFF
attr <HM-CC-TC>.Heizung expert 2_full
attr <HM-CC-TC>.Heizung firmware 2.1
attr <HM-CC-TC>.Heizung hmClass receiver
attr <HM-CC-TC>.Heizung model HM-CC-TC
attr <HM-CC-TC>.Heizung room <IhrRaum>
attr <HM-CC-TC>.Heizung serialNr JE********
attr <HM-CC-TC>.Heizung subType thermostat</nowiki>
=== Channel (Kanal) 01 _Weather ===
<nowiki>define <HM-CC-TC>.Heizung_Weather CUL_HM 1DA49101 <<<=== 01 = Kanal 1
attr <HM-CC-TC>.Heizung_Weather model HM-CC-TC
attr <HM-CC-TC>.Heizung_Weather peerIDs
attr <HM-CC-TC>.Heizung_Weather room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_Weather FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_Weather-%Y-%m.log <HM-CC-TC>.Heizung_Weather
attr FileLog_<HM-CC-TC>.Heizung_Weather logtype text
attr FileLog_<HM-CC-TC>.Heizung_Weather room CUL_HM,<IhrRaum></nowiki>
=== Channel (Kanal) 02 _Climate ===
<nowiki>define <HM-CC-TC>.Heizung_Climate CUL_HM 1DA49102 <<<=== 02 = Kanal 2
attr <HM-CC-TC>.Heizung_Climate model HM-CC-TC
attr <HM-CC-TC>.Heizung_Climate peerIDs 1AD52B01,1B7A4C01,1C4CD101,1C48EC01, <<<=== gepeerte HM-CC-VDs
attr <HM-CC-TC>.Heizung_Climate room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_Climate FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_Climate-%Y-%m.log <HM-CC-TC>.Heizung_Climate
attr FileLog_<HM-CC-TC>.Heizung_Climate logtype text
attr FileLog_<HM-CC-TC>.Heizung_Climate room CUL_HM,<IhrRaum></nowiki>
=== Channel (Kanal) 03 _WindowRec ===
<nowiki>define <HM-CC-TC>.Heizung_WindowRec CUL_HM 1DA49103 <<<=== 03 = Kanal 3
attr <HM-CC-TC>.Heizung_WindowRec model HM-CC-TC
attr <HM-CC-TC>.Heizung_WindowRec peerIDs 1CFBB001, <<<=== gepeerte HM-Sec-SCs
attr <HM-CC-TC>.Heizung_WindowRec room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_WindowRec FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_WindowRec-%Y-%m.log <HM-CC-TC>.Heizung_WindowRec
attr FileLog_<HM-CC-TC>.Heizung_WindowRec logtype text
attr FileLog_<HM-CC-TC>.Heizung_WindowRec room CUL_HM,<IhrRaum></nowiki>
== Einstellungen eines HM-CC-TC lesen, anzeigen und sichern ==
=== expert ===
Anfang Februar 2013 wurde eine Änderung bei der Anzeige der so genannten ''Readings'' (Register usw.), also der Einstellungen bzw. Eigenschaften eines HM-Devices, eingeführt. '''Alle''' Werte sieht man nur noch, wenn man am HM-CC-TC das Attribut ''expert'' auf ''2_all'' setzt. Per '''default''' (nicht in ''fhem.cfg'' gesetzt) steht dieser Wert auf ''0_off'' (nur die notwendigsten Readings/Eigenschaften werden angezeigt). Mittelweg ist der Wert ''1_on''.

Mittels

<nowiki>attr <HM-CC-TC-Name> expert 2_full</nowiki>
in der FHEM-Befehlszeile mit anschließendem <Enter> setzt man diesen Level.

Falls man mit '''Temperaturlisten''' arbeitet (siehe unten), dann kann man die komplette Liste im "Channel" (Kanal) ''<HM-CC-TC-Name>__Climate'' einsehen. Auch für diesen Kanal ist evtl. ein setzen des Attributes ''expert 2_full'' angeraten.

<ins>Anmerkung:</ins> Es gibt auch noch sogenannte "hidden datas" (versteckte interne Werte, Register oder Eigenschaften deren Namen mit einem "." beginnen). Diese sieht man nur dann, wenn auch das Attribut ''showInternalValues 1'' gesetzt ist (default: 0 bzw. nicht gesetzt).

=== autoReadReg ===
Mitte Januar 2013 wurde das neue Attribut ''autoReadReg'' eingeführt, welches auf ''0'' voreingestellt ist (kein Eintrag in der ''fhem.cfg''). Das Setzen dieses Attributes auf ''1'' bewirkt, dass <ins>beim Neustart von FHEM</ins> die Einstellungen des entsprechenden HM-Gerätes ausgelesen werden. Dies wird bei mehreren ''autoReadReg''s automatisch zeitversetzt vorgenommen, um die Funk-Kommunikation nicht unnötig zu belasten.

Mittels

<nowiki>attr <HM-CC-TC-Name> autoReadReg 1 </nowiki>
in der FHEM-Befehlszeile mit anschließendem <Enter> setzt man diesen Wert.

=== list ===
Um sich alle Eigenschaften/Readings eines Gerätes anzusehen, gibt es den Befehl ''list''.

Mittels

<nowiki>list <HM-CC-TC-Name></nowiki>
und Bestätigung mit <Enter> erhalten Sie die gewünschte Anzeige Ihres TCs <ins>incl.</ins> seiner 3 Channels. Über

<nowiki>list <HM-CC-TC-Name>_<Channel-Name></nowiki>
werden nur die Daten des angegebenen Channels angezeigt.

=== Einstellungen sichern ===
Die Durchführung von ''autoReadReg'' kann durchaus mehrere Minuten dauern. Anschließend besteht die Möglichkeit, diese per

<nowiki>get HM-CC-TC-Basisname saveConfig [/Verzeichnis/mit/Schreibrechten/]<Dateiname></nowiki>
für jedes HM-CC-TC getrennt zu sichern (für eine später notwendige Wiederherstellung). Die Sicherungsdatei wird regulär im ''modpath'' (siehe ''fhem.cfg'') abgelegt. Falls dies nicht zum Erfolg führt (es wird - ohne Fehlermeldungen bei regulärem ''verbose'' und ''loglevel'' - im ''modpath'' keine Datei angelegt), müssen Sie vor dem Dateinamen einen vollständigen Pfad mit Schreibrechten für den Benutzer, unter dem FHEM läuft, angeben.

In der <ins>Log-Datei</ins> von FHEM erscheinen danach Meldungen folgender Art

<nowiki><Datum>_<Zeit> 2: CUL_HM set <HM-CC-TC-Name> statusRequest rxt:12
<Datum>_<Zeit> 2: CUL_HM set <HM-CC-TC-Name> getConfig rxt:12</nowiki>
Hierbei kann es (im <ins>Event monitor</ins> von FHEM) zu folgenden Fehlermeldungen kommen

<nowiki><Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:RegisterRead
<Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:PeerList
<Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:StatusReq</nowiki>
Diese Meldungen können auch mehrfach pro Gerät auftreten. Dann hat das Auslesen der Einstellungen nicht geklappt und sollte nochmals durchgeführt werden. Dafür muss man FHEM aber nicht neu starten, sondern das HM-Device per

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
in der Befehlszeile von FHEM und anschließendem <Enter> (nicht "save") darauf einstellen.

Die Channels (z.B. <HM-CC-TC-Name>_Climate, _Weather, _WindowRec) eines HM-Gerätes brauchen nicht (können aber bei Bedarf) separat ausgelesen bzw. gesichert zu werden, da sie Bestandteil der Basisabfrage sind.

== Funkprobleme auffangen ==
Der wohl am häufigsten an den HM-CC-TC gesendete Befehl ist "set desired-temp", mit dem die Wunschtemperatur neu gesetzt wird.
Funktioniert dieser Befehl jedoch nicht zuverlässig, wird die Wohnung ggf. zu lange oder nicht rechtzeitig beheizt.
Der folgende Mechanismus soll die Sicherheit erhöhen, indem die Antworten des HM-CC-TC geprüft werden und ggf. das Funktelegramm erneut gesendet wird.

Um den Sollwert zum erneuten Senden des Funktelegramms verfügbar zu haben, wird ein dummy definiert:

<nowiki>define HM_TC_Solltemperatur dummy</nowiki>
Wann immer die Solltemperatur geändert wird, setzt man die neue desired-temp nicht nur auf dem HM-TC-CC (hier HM_TC genannt), sondern auch auf dem dummy. Der Befehl (z.B. in der [[Zuhause-Status|Routine zum HomeStatus]]) sieht dann so aus:

<nowiki>set HM_TC desired-temp 21;set HM_TC_Solltemperatur 21</nowiki>
Falls das ausgehende Funktelegramm verlorengeht, fehlt die Antwort "command accepted". Dies kann mit einem watchdog aufgefangen werden, der dann den Befehl an den HM-CC-TC erneut sendet:

<nowiki>define w_HM_TC watchdog HM_TC:set_desired-temp.* 00:02:30 HM_TC_Climate:CommandAccepted:.yes { \
Log 1, ">>>>>>>>> w_HM_TC desired temp - missing response.";\
fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\
}</nowiki>
Falls ein Fehler bei der Funkkommunikation auftritt, erhält man die Antwort "missing ACK" oder "NACK". Auch in diesem Fall soll das Telegramm zum Ändern der Wunschtemperatur erneut an den HM-CC-TC gesendet werden:

<nowiki>define n_HM_TC_err notify HM_TC:(MISSING.ACK.*|.*NACK.*) {\
Log 1, ">>>>>>>>> n_HM_TC desired temp - missing ack/nack.\n";\
fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\
}</nowiki>
Mit diesen beiden Helfern ist die Funkkommunikation zum HM-CC-TC sehr zuverlässig.

== Plots / Grafiken ==
=== Problem ===
Durch ''autocreate'' wird zwar ein Log angelegt, aber kein Plot (Grafische Auswertung). Dem kann man aber abhelfen (siehe unten).

=== Plots erzeugen ===
''PGM2'' ist die Standardansicht des Fhem-Web-Interfaces. Um hier Plots/Grafiken zu erzeugen einfach unter dem ''Filelog'' des Thermostaten das ''attr logtype'' auf ''temp4hum6:Plot,text'' setzen und es wird ein Plot-Link neben dem Text-Link angezeigt. Nun können Sie auf diesen Plot-Link klicken und ...

=== alternative Plots ===
Mit dem fht.gplot funktioniert die Anzeige der Ventilstellung (actuator) nicht.

Mit folgendem angepassten .gplot File wird die gemessene Temperatur und Ventilstellung angezeigt.

<nowiki>############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define <filelogname> FileLog /var/log/fhem/actuator_name-%Y.log <actuator_name>:(measured-temp|actuator).*

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 ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics

set y2label "Temperatur in C"
set ylabel "Ventil (%)"

#FileLog 4:measured:10:
#FileLog 4:actuator:50:

plot \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Temperatur in C' with lines,\
"< egrep 'actuator' <IN>"\
using 1:4 axes x1y1 title 'Ventil (%)' with lines\</nowiki>
=== Alles-drin-Plot ===
dazu nimmt man folgendes .gplot. Man/Fra beachte, dass hierfür alle Parameter nach der define-Anweisung in das Logfile geschrieben werden.

<nowiki>############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define <filelogname> FileLog /var/log/fhem/HM_CC_TC-%Y.log <HM_CC_TC-name>
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 ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics
set y2label "Temperature in C"
set ylabel "Actuator (%)"
#FileLog 4:temperature:0:
#FileLog 4:desired:0:
#FileLog 4:humidity:0:
#FileLog 4:actuator:0:int
plot \
"< awk '/temperature/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Measured temperature' with lines lw 2,\
"< awk '/desired/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Desired temperature' with steps,\
"< awk '/humidity/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Humidity (%)' with lines,\
"< awk '/actuator/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Actuator (%)' with lines\</nowiki>

== Steuerungsmodi ==
Das Wandthermostat hat 4 verschiedene Steuerungsmöglichkeiten:

* Auto (automatisch)
* Cent (Zentrale)
* Manu (manuell)
* Prog / Koffer-Symbol (Urlaubs/Party-Modus, wird hier nicht näher erörtert)

Der Steuerungsmodus wird über wiederholtes Drücken der linken Taste des HM-CC-TC ausgewählt bzw. gewechselt.

'''Hinweis:''' Durch das P'''ai'''ren des HM-CC-TC <ins>und</ins> der Stellantrieb sowie Tür-/Fensterkontakte an Fhem verlieren Sie '''nicht''' die Steuerungsmöglichkeiten. Im Gegenteil: Nur wenn auch die VDs usw. mit Fhem gep'''ai'''rt sind, haben Sie die Möglichkeit, auch diese zu überwachen. Die Steuerung '''können''' Sie dennoch allein dem HM-CC-TC überlassen.

=== Auto-Modus ===
Im Modus '''Auto''' wird die Temperaturregelung über die im TC hinterlegten Temperaturlisten vorgenommen. Das Thermostat arbeitet also selbständig, somit unabhängig von einer Zentrale / FHEM. Nur in diesem Modus werden die evtl. per FHEM an das TC übermittelten "templist" abgearbeitet. Über das Senden von angepassten Temperatur-Listen kann eine indirekte Steuerung per FHEM erfolgen. '''Jederzeit''' kann zudem die Raumtemperatur über das Drehrad des Wandthermostaten oder die FHEM-Web-Oberfläche verändert werden. Diese ''Übersteuerung'' der Temperaturliste gilt bis zur nächsten Temperaturänderung nach der vorgenannten Liste.

=== Cent-Modus ===
Im Modus '''Cent''' steuert eine HomeMatic-Zentrale (CCU) oder eben ein FHEM-Server mit z.B. [[HMLAN Konfigurator]] zu den in der FHEM-Config hinterlegten Zeiten und mit den dort festgelegten Temperaturen. Fällt also die HM-Zentrale aus, erfolgt keine Steuerung der Thermostaten bzw. Heizungsventile mehr.

<ins>Anmerkung</ins>: Der Modus ''cent'' erscheint nur dann im Display des HM-CC-TC, wenn er an eine Zentrale bzw. das [[CUL]] angelernt (gepairt) wurde.

=== Manu-Modus ===
Der Modus '''Manu''' übersteuert die im TC hinterlegten Temperaturlisten und die evtl. von der HM-Zentrale / dem FHEM <ins>vor Umstellung auf ''Manu''</ins> gesendeten Einstellungen. Es wird also bis zur nächsten Modusumstellung bzw. manuellen Temperaturverstellung der per Einstellrad gesetzte Temperaturwert gefahren.

Aber auch in diesem Modus kann man die ''desired-temperature'' per FHEM verstellen. Der dadurch eingestellte Wert gilt ab sofort als der neue im ''Manu-Modus'' zu haltende Wert.

=== Auslesen des eingestellten Steuerungsmodus ===
Der eingestellte Steuerungsmodus erscheint normalerweise in den ''Readings'' des HM-CC-TC unter ''controlMode''. Zusätzlich haben Sie die Möglichkeit, diesen Modus auch in der FHEM-Weboberfläche ''everything'' => Abschnitt ''thermostat'' zu sehen, '''wenn''' Sie für den HM-CC-TC das folgende Attribut setzen:

<nowiki>attr <HM-CC-TC-Name> stateFormat T:measured-temp, H:humidity, VD:actuator, controlMode</nowiki>
Erscheint dort selbst nach einem

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
kein "Reading" ''controlMode'' oder keine Angabe des aktuell eingestellten Modus bzw. nur das Wort "controlMode", dann setzen Sie ihren HM-CC-TC von Hand in einen anderen Kontrollmodus und machen einen Browser-Refresh. Klappt dies nicht, geben Sie bitte erneut den Befehl

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
ein. Halten Sie anschließend die Taste <OK> am HM-CC-TC für 5 Sekunden gedrückt (oder warten ca. 5 Minuten) und machen in der FHEM-Weboberfläche einen Browser-Refresh (FF => <F5>). Jetzt sollte der manuell eingestellte Kontrollmodus erscheinen (ggfls. muss dieser Vorgang einmal wiederholt werden). Jetzt können Sie wieder den gewünschten Modus einstellen, erneut ein

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
absetzen und nach erneutem Drücken der <OK>-Taste für 5 Sekunden mit nachfolgendem Browser-Refresh sollte alles richtig angezeigt werden.

Dies setzt natürlich voraus, dass der HM-CC-TC richtig gepairt ist.

== Temperaturlisten ==

'''Achtung:''' Die Listen mussten bis vor kurzem noch auf das Device HM-CC-TC, nunmehr aber auf dessen Channel HM-CC-TC_Climate gesetzt werden. Dadurch ändert sich die Benennung des Gerätes (wird in den u.a. Beispielen berücksichtigt).

Eine Temperaturliste für die Steuerung der Raumtemperatur im o.a. '''Auto-Modus''' kann man wie folgt erzeugen:

* Man legt sich eine eigene ''99_MyUtils.pm'' an (siehe [[99_myUtils anlegen]]). Dies ist wichtig, da es bei FHEM-Updates durchaus sein kann, dass die vorhandene ''99_Utils.pm'' erneuert und damit überschrieben wird und dann sind all ihre eigenen Subroutinen weg.
* Dort trägt man für '''jedes''' HM-CC-TC, dessen Werte man individuell einstellen will, eine '''eigene''' Subroutine ein, die z.B. wie folgt aussehen kann:

<pre>
######################################################
# Temperatur-Liste für das Wohnzimmer
# setzen per Aufruf von "{SetTempList_EG_WZ_Heizung}"
######################################################
sub
SetTempList_EG_WZ_Heizung()
{
{ fhem ("set EG.WZ.Heizung_Climate tempListMon 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListTue 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListWed 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListThu 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListFri 05:30 19.0 07:00 21.0 15:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListSat 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListSun 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.5")};
}
# End SetTempList_EG_WZ_Heizung
</pre>

* die Änderungen in der ''99_MyUtils.pm'' müssen jetzt abgespeichert werden
* in der FHEM-Befehlszeile ist ein ''reload 99_MyUtils.pm'' mit <Enter> / <Return> abzusetzen (erst dadurch werden die Eintragungen / Änderungen aktiviert)
* nun kann man in der Kommandozeile von FHEM den Befehl ''{SetTempList_EG_WZ_Heizung}'' eingeben und mit <Return> bzw. <Enter> bestätigen

Im FHEM-Logfile (das man vorher in einem weiteren Browser-Tab geöffnet hat, Refresh (F5) nicht vergessen) taucht danach folgendes auf:

<pre>
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListMon 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListTue 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListWed 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListThu 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListFri 05:30 17.0 07:00 21.0 15:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListSat 07:00 17.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListSun 07:00 17.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0
</pre>

'''Zur Erläuterung:'''

Mittels

<pre>
set EG.WZ.Heizung_Climate tempListMon 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
</pre>

setzt man den HM-CC-TC-Channel mit dem Namen ''EG.WZ.Heizung_Climate'' für jeden folgenden Montag

von 00:00 '''bis''' 05:30 Uhr auf 17,0 °C 
von 05:31 '''bis''' 07:00 Uhr auf 21,0 °C 
von 07:31 '''bis''' 16:00 Uhr auf 19,0 °C 
...

und so weiter. Dabei kann bei der Temperatur als Nachkommawert entweder eine 0 oder eine 5 stehen, ein Wert von z.B. 20,1 ist nicht erlaubt.

'''Achtung:''' Häufigste Fehlerquelle ist das Verstehen der Reihen- bzw. Abfolge der Zeit- und Temperaturwerte. Deshalb ein weiterer Beschreibungsversuch mit anderen Worten, der hoffentlich zum besseren Verständnis beiträgt:

Die Definition <ins>beginnt</ins> von selbst jeweils bei 00:00 Uhr eines Tages. Die danach angegebene Uhrzeit (im letzten Beispiel ''tempListMon'': 05:30 Uhr) beschreibt also den Zeitraum von 00:00 Uhr '''bis''' 05:30 Uhr. Der <ins>danach</ins> folgende Wert von 17.0 definiert also den in der Zeit von 00:00 Uhr '''bis''' 05:30 Uhr geltenden Wunschtemperaturwert von 17,0 °C. Die im vorgenannten Beispiel auf die Wertangabe ''17.0'' folgende Uhrzeit von ''07:00'' legt nun den Zeitraum von 05:30 Uhr '''bis''' 07:00 Uhr für den dahinter stehenden Temperaturwert von 21.0 fest. Die Abfolge kann dem Einen oder der Anderen unnatürlich vorkommen, aber es ist eine so von eQ3 festgelegte Notationsweise.

'''Beachten Sie bitte''', dass am Schluss der Liste <ins>immer</ins> eine Einstellung für 24:00 notiert sein '''muss'''. Ansonsten quittiert FHEM das Setzen der Liste mit einem solchen Eintrag im Logfile:

<pre>
Last time spec must be 24:00
</pre>

Im FHEM-Logfile-Browser-Tab sollten nach einigen Minuten folgende mehrfach wiederholten Einträge auftauchen:

<pre>
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate CommandAccepted: yes
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate CommandAccepted: yes
...
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate CommandAccepted: yes
</pre>

Wichtig ist ein nachfolgendes "ACK". Steht dort "MISSING ACK", dann wurde der Empfang der Werte vom HM-CC-TC nicht bestätigt und man sollte die TempList noch einmal schicken. Kommt auch nach mehreren Sendeversuchen kein "ACK" sollten Sie in den ''Readings''des Devices die ''TempList''überprüfen (siehe unten), denn es kann sein, dass diese Antwort schlicht nicht empfangen werden konnte, weil der Empfänger gerade anderweitig beschäftigt war, die Einstellungen aber dennoch übernommen wurden. Wird jedoch ein "NACK" vom HM-CC-TC gesendet, dann wurde die Temperaturliste explizit nicht akzeptiert. Kontrollieren Sie in diesem Fall die Korrektheit der Temperaturliste.

Welche Werte '''aktuell eingestellt'''sind, sieht man in den "Readings" des jeweiligen Devices; im obigen Fall also z.B. im linken Menü von FHEM auf den default-Eintrag ''Everything''klicken und dann auf den Eintrag mit dem Namen ''EG.WZ.Heizung''.

== Temperaturlisten (neu) ==

Seit Mitte Oktober 2013 kann man die Temperaturlisten "ressourcenschonender" an einen HM-CC-TC übertragen. Bisher wurde für jeden Tag ein Befehl abgeschickt (siehe obiges Beispiel). Nun kann man, wie beim [[HM-CC-RT-DN Funk-Heizkörperthermostat#Temperaturlisten setzen|HM-CC-RT-DN] (dem Nachfolger des HM-CC-TC), auch alles in ein einziges "Funktelegramm" packen. Dazu das folgende Beispiel (achten Sie bitte auf die Schlüsselwörter "prep" und "exec"):

######################################################
# Temperatur-Liste für Kinderzimmer
# setzen per Aufruf von "{SetTempList_Kind_Heizung}"
######################################################
sub
SetTempList_Kind_Heizung()
{
{ fhem ("set DG.Kind.Heizung_Climate tempListMon prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListTue prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListWed prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListThu prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListFri prep 05:30 19.0 07:00 20.5 15:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListSat prep 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListSun exec 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0")};
}
# End SetTempList_Kind_Heizung

Zum Verständnis: Mittels ''prep'' werden die Werte in einen "Puffer" gepackt und sobald ein "exec" auftaucht, wird er Puffer mit dem Nachfolgenden gefüllt und anschließend '''in einem Rutsch''' an den HM-CC-TC geschickt. Dies vermeidet/minimiert Übertragungsprobleme.

== Batteriealarme des HM-CC-VD in Verbindung mit HM-CC-TC ==
1. bei U-Bat. < 2,4 V erscheint im Display des VD und des TC das Batteriesymbol mit '''battery: low''' in den Readings und Events!

2. bei U-Bat. < 2,3 V erscheint im Display des VD zusätzlich '''F4''' mit '''battery: critical''' in den Readings und Events!

Es wird dringend geraten, die Batterien bei battery: low zu tauschen!

== Log-Auszug ==
HM-CC-TC sendet alle 2 Minuten folgenden Statusbericht:

<nowiki>Datum-Zeit <Device Name> T: 17.3 H: 66 
Datum-Zeit <Device Name> measured-temp: 17.3 
Datum-Zeit <Device Name> temperature: 17.3 
Datum-Zeit <Device Name> humidity: 66 
Datum-Zeit <Device Name> actuator: 96 % </nowiki>
Bei Status-Änderungen sendet HM-CC-TC auch entsprechende Meldungen, z.b.:

<nowiki>Datum-Zeit <Device Name> desired-temp: 15.5 </nowiki>

= Probleme =

== Verstellen der Solltemperatur am HM-CC-TC per Drehrad ==

'''Symptom:''' Beim Verstellen der Solltemperatur per seitlichem Drehrad wurde die aktuelle Solltemperatur - '''egal ob''' man hoch oder runter drehte - immer nur in 0,5 °C Schritten '''runter''' gestellt, bis schließlich die Mindesttemperatur von 6,0 °C erreicht war. Weitere Änderungen waren nicht möglich

'''Abhilfe:''' Letztlich half nur das kurzzeitige Entfernen einer Batterie. Das danach für einige Zeit erscheinende Batteriesymbol zeigte den kleinstmöglichen guten Zustand an, in FHEM wurde das ''Reading'' des Batteriezustandes mit ''ok'' ausgegeben (wie in den Logs aber vorher auch). '''Letztlich half aber nur''' das Einsetzen neuer Batterien, denn die o.a. Störung trat nach ca. 2 Stunden erneut auf. Die "alten" Batterien (die, die dem HM-CC-TC ab Werk beilagen) hatten somit eine Nutzungsdauer von knapp 11 Monaten, waren aber auch in einem HM-CC-TC, der mit 4 Stck. HM-Sec-SC (mussten sehr oft "Meldung machen") und 4 Stck. HM-CC-VD gepeert war. ''Ohne Last'' zeigten die beiden alten AA-Batterien eine Spannung von jeweils 1,29 V an.

'''Hinweis:''' Die unter ''Abhilfe'' beschriebene Lösung war leider nur von kurzer Dauer. Bereits kurz danach zeigte der HM-CC-TC die gleichen Ausfallerscheinungen. Bei ELV gibt es das Bauteil für das Drehrad (Inkrementalgeber) als [http://www.elv.de/inkrementalgeber-fuer-fs20-str-fht-8-und-homematic-hm-cc-tc.html Ersatzteil]. Sobald dieses geliefert und ein Reparaturversuch unternommen wurde, wird an dieser Stelle weiter berichtet.

== HM-CC-TC misst zu hohe/niedrige Luftfeuchte-Werte ==

'''Symptom:''' In den Fhem-Logs und demzufolge auch in den Plots/Grafiken eines seit über 18 Monaten im Einsatz befindlichen HM-CC-TC wurden viel zu hohe (einzelne Spitzenwerte von 98 oder 99 %) bzw. ständig zu niedrige (um die 20 oder sogar vereinzelt nur 2 %) Werte für die relative Luftfeuchte gemessen (im direkten Vergleich zu anderen HM-CC-TCs). Die anderen Werte (Temperatur, Actuator) waren aber schlüssig.

'''Abhilfe:''' Batteriewechsel. Die alten Batterien hatten (unbelastet) noch knapp über 1 V Spannung.

'''Hinweis:''' Eine Batteriewarnung des Gerätes gab es nicht. Im Display war das entsprechende Symbol noch auf 1 Balken.

= Firmware =
Aktuelle Firmware-Version: 2.1

= Links =
Anleitung [http://www.elv-downloads.de/service/manuals/76787_76175_HM_Wandthermostat_UM.pdf PDF]

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

HM-CC-TC Funk-Wandthermostat

2014-08-01T19:14:10Z

Rohan: /* Probleme */ Ursache für extrem falsche Luftfeuchtewerte

'''HM-CC-TC Funk-Wandthermostat'''

Programmierbarer Raumthermostat, der bis zu 4 [[HM-CC-VD Funk-Stellantrieb]] steuern kann.

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt).'''

Nachfolgeprodukt ist der [[HM-CC-RT-DN]] bzw. (ab März 2014) [[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]].

= Features =
* Am Raumthermostat programmierbare Tages- und Nachttemperatur.
* Pro Wochentag können bis zu 24 Schaltpunkte definiert werden.
* Anbindung von <ins>jeweils</ins> '''maximal''' 4 Tür- bzw. Fensterkontakten ([[HM-Sec-RHS]]) zur Absenkung der Temperatur auf einen eigens eingestellten Temperaturwert (ab Werk: 12°C) bei offenem Fenster bzw. offener Tür.
* Anzeige der Temperatur und Luftfeuchtigkeit im Raum und Hintergrundbeleuchtung des Displays.

Alle 120 bis 184 Sekunden überträgt der Wandthermostat vorhandene Befehle zu den Stellantrieben. Jeder empfangene Befehl wird vom Stellantrieb bestätigt und dann ausgeführt. Täglich gegen Mitternacht synchronisiert ein HM-CC-TC seine Uhrzeit mit der HomeMatic-Zentrale (CCU, HMLAN).

= Hinweise zum Betrieb mit FHEM =
Vor dem Einsatz mit einer Zentrale sind erst alle Stellantriebe und Tür-/Fensterkontakte mit dem HM-CC-TC zu verbinden (P'''ee'''r).
Damit das ganze dann in FHEM auftaucht, muss der TC noch mit dem [[HMLAN Konfigurator]] gep'''ai'''rt werden.

Mit

<nowiki>set CUL hmPairForSec 300</nowiki>
setzt man das CUL / den HMLAN-Konfigurator für 5 Minuten in den Anlernmodus. Danach am Thermostaten 5 Sekunden lang die OK-Taste drücken und es wird eine Zeit von 20 auf 0 Sekunden gezählt:

* Klappt das Anlernen in diesen 20 Sekunden, wird der Countdown sofort beendet, anschließend für ca. 2-3 Sekunden "OK" angezeigt und der Thermostat ist in FHEM eingebunden.
* Gelingt das Anlernen nicht in den 20 Sekunden, erscheint nach Erreichen der "0" noch für 2 bis 3 Sekunden ein "NOK" ('''N'''ot '''OK''') im Display des TCs.

'''Alternativ'''(und so vom Entwickler des Fhem-HomeMatic-Moduls empfohlen) kann wie folgt vorgegangen werden:

* Alle Stellantriebe und Tür-/Fensterkontakte sowie den HM-CC-TC mit Fhem p'''ai'''ren (also ''set CUL hmPairForSec 300'' und an allen Devices den Anlernknopf drücken innerhalb des Zeitfensters von 300 Sekunden).
* Die Stellantriebe und Tür-/Fensterkontakte mit den ''Channels'' (siehe unten) p'''ee'''ren (siehe <nowiki>[http://fhem.de/commandref.html#CUL_HMpeerChan commandref :peerChan]</nowiki>). Hierzu werden die entsprechenden Fhem-Befehle über das Webinterface von Fhem erteilt.

'''Hinweis:'''
* Alle in der FHEM-Eingabezeile eingegebenen ''attr''-, ''define''-Befehle usw. müssen zum Schluss noch per Klick auf den "Save"-Button dauerhaft in der ''fhem.cfg'' gespeichert werden, sonst sind sie nach z.B. einem Systemabsturz verloren.
* Falls in der FHEM-Weboberfläche für ihren HM-CC-TC etwas wie ''X CMDs pending'' steht, sollten Sie ihren HM-CC-TC zur Hand nehmen und für 20 Sekunden auf die OK-Taste drücken. Dadurch werden alle noch ausstehenden Befehle eingelesen.

== Auszug aus der fhem.cfg ==
Die nachfolgenden Einstellungen zum HM-CC-TC werden von FHEM <ins>weitestgehend</ins> automatisch gesetzt. Die Pfadangaben für die Log-Dateien sind system-, die Raumbenennungen benutzerabhängig. Zu ''autoReadReg''und ''expert''siehe unten. Neben dem eigentlichen Basis-Gerät (HM-CC-TC) werden in FHEM automatisch noch 3 weitere "Unter"-Geräte (Channels/Kanäle), nämlich

* ''_Weather''
* ''_Climate''
* ''_WindowRec''

definiert (durch das Anlernen des TC an FHEM; siehe unten), deren Benennung sich (jeweils mit einem vorangestellten Unterstrich "_") am Namen des Basis-Gerätes orientiert.

'''Anmerkung:'''Die in den unten gezeigten ''fhem.cfg''-Auszügen markierten <ins>Peer</ins>-Einträge tauchen erst auf, sobald man die Daten aus dem TC mit ''set HM-CC-TC-Basisname getConfig''bzw. ''autoReadReg''ausgelesen hat.

=== Hauptgerät ===
<nowiki>define <HM-CC-TC>.Heizung CUL_HM 1DA491
attr <HM-CC-TC>.Heizung actCycle 000:10
attr <HM-CC-TC>.Heizung actStatus alive
attr <HM-CC-TC>.Heizung autoReadReg 1
attr <HM-CC-TC>.Heizung devInfo 00FFFF
attr <HM-CC-TC>.Heizung expert 2_full
attr <HM-CC-TC>.Heizung firmware 2.1
attr <HM-CC-TC>.Heizung hmClass receiver
attr <HM-CC-TC>.Heizung model HM-CC-TC
attr <HM-CC-TC>.Heizung room <IhrRaum>
attr <HM-CC-TC>.Heizung serialNr JE********
attr <HM-CC-TC>.Heizung subType thermostat</nowiki>
=== Channel (Kanal) 01 _Weather ===
<nowiki>define <HM-CC-TC>.Heizung_Weather CUL_HM 1DA49101 <<<=== 01 = Kanal 1
attr <HM-CC-TC>.Heizung_Weather model HM-CC-TC
attr <HM-CC-TC>.Heizung_Weather peerIDs
attr <HM-CC-TC>.Heizung_Weather room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_Weather FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_Weather-%Y-%m.log <HM-CC-TC>.Heizung_Weather
attr FileLog_<HM-CC-TC>.Heizung_Weather logtype text
attr FileLog_<HM-CC-TC>.Heizung_Weather room CUL_HM,<IhrRaum></nowiki>
=== Channel (Kanal) 02 _Climate ===
<nowiki>define <HM-CC-TC>.Heizung_Climate CUL_HM 1DA49102 <<<=== 02 = Kanal 2
attr <HM-CC-TC>.Heizung_Climate model HM-CC-TC
attr <HM-CC-TC>.Heizung_Climate peerIDs 1AD52B01,1B7A4C01,1C4CD101,1C48EC01, <<<=== gepeerte HM-CC-VDs
attr <HM-CC-TC>.Heizung_Climate room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_Climate FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_Climate-%Y-%m.log <HM-CC-TC>.Heizung_Climate
attr FileLog_<HM-CC-TC>.Heizung_Climate logtype text
attr FileLog_<HM-CC-TC>.Heizung_Climate room CUL_HM,<IhrRaum></nowiki>
=== Channel (Kanal) 03 _WindowRec ===
<nowiki>define <HM-CC-TC>.Heizung_WindowRec CUL_HM 1DA49103 <<<=== 03 = Kanal 3
attr <HM-CC-TC>.Heizung_WindowRec model HM-CC-TC
attr <HM-CC-TC>.Heizung_WindowRec peerIDs 1CFBB001, <<<=== gepeerte HM-Sec-SCs
attr <HM-CC-TC>.Heizung_WindowRec room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_WindowRec FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_WindowRec-%Y-%m.log <HM-CC-TC>.Heizung_WindowRec
attr FileLog_<HM-CC-TC>.Heizung_WindowRec logtype text
attr FileLog_<HM-CC-TC>.Heizung_WindowRec room CUL_HM,<IhrRaum></nowiki>
== Einstellungen eines HM-CC-TC lesen, anzeigen und sichern ==
=== expert ===
Anfang Februar 2013 wurde eine Änderung bei der Anzeige der so genannten ''Readings'' (Register usw.), also der Einstellungen bzw. Eigenschaften eines HM-Devices, eingeführt. '''Alle''' Werte sieht man nur noch, wenn man am HM-CC-TC das Attribut ''expert'' auf ''2_all'' setzt. Per '''default''' (nicht in ''fhem.cfg'' gesetzt) steht dieser Wert auf ''0_off'' (nur die notwendigsten Readings/Eigenschaften werden angezeigt). Mittelweg ist der Wert ''1_on''.

Mittels

<nowiki>attr <HM-CC-TC-Name> expert 2_full</nowiki>
in der FHEM-Befehlszeile mit anschließendem <Enter> setzt man diesen Level.

Falls man mit '''Temperaturlisten''' arbeitet (siehe unten), dann kann man die komplette Liste im "Channel" (Kanal) ''<HM-CC-TC-Name>__Climate'' einsehen. Auch für diesen Kanal ist evtl. ein setzen des Attributes ''expert 2_full'' angeraten.

<ins>Anmerkung:</ins> Es gibt auch noch sogenannte "hidden datas" (versteckte interne Werte, Register oder Eigenschaften deren Namen mit einem "." beginnen). Diese sieht man nur dann, wenn auch das Attribut ''showInternalValues 1'' gesetzt ist (default: 0 bzw. nicht gesetzt).

=== autoReadReg ===
Mitte Januar 2013 wurde das neue Attribut ''autoReadReg'' eingeführt, welches auf ''0'' voreingestellt ist (kein Eintrag in der ''fhem.cfg''). Das Setzen dieses Attributes auf ''1'' bewirkt, dass <ins>beim Neustart von FHEM</ins> die Einstellungen des entsprechenden HM-Gerätes ausgelesen werden. Dies wird bei mehreren ''autoReadReg''s automatisch zeitversetzt vorgenommen, um die Funk-Kommunikation nicht unnötig zu belasten.

Mittels

<nowiki>attr <HM-CC-TC-Name> autoReadReg 1 </nowiki>
in der FHEM-Befehlszeile mit anschließendem <Enter> setzt man diesen Wert.

=== list ===
Um sich alle Eigenschaften/Readings eines Gerätes anzusehen, gibt es den Befehl ''list''.

Mittels

<nowiki>list <HM-CC-TC-Name></nowiki>
und Bestätigung mit <Enter> erhalten Sie die gewünschte Anzeige Ihres TCs <ins>incl.</ins> seiner 3 Channels. Über

<nowiki>list <HM-CC-TC-Name>_<Channel-Name></nowiki>
werden nur die Daten des angegebenen Channels angezeigt.

=== Einstellungen sichern ===
Die Durchführung von ''autoReadReg'' kann durchaus mehrere Minuten dauern. Anschließend besteht die Möglichkeit, diese per

<nowiki>get HM-CC-TC-Basisname saveConfig [/Verzeichnis/mit/Schreibrechten/]<Dateiname></nowiki>
für jedes HM-CC-TC getrennt zu sichern (für eine später notwendige Wiederherstellung). Die Sicherungsdatei wird regulär im ''modpath'' (siehe ''fhem.cfg'') abgelegt. Falls dies nicht zum Erfolg führt (es wird - ohne Fehlermeldungen bei regulärem ''verbose'' und ''loglevel'' - im ''modpath'' keine Datei angelegt), müssen Sie vor dem Dateinamen einen vollständigen Pfad mit Schreibrechten für den Benutzer, unter dem FHEM läuft, angeben.

In der <ins>Log-Datei</ins> von FHEM erscheinen danach Meldungen folgender Art

<nowiki><Datum>_<Zeit> 2: CUL_HM set <HM-CC-TC-Name> statusRequest rxt:12
<Datum>_<Zeit> 2: CUL_HM set <HM-CC-TC-Name> getConfig rxt:12</nowiki>
Hierbei kann es (im <ins>Event monitor</ins> von FHEM) zu folgenden Fehlermeldungen kommen

<nowiki><Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:RegisterRead
<Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:PeerList
<Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:StatusReq</nowiki>
Diese Meldungen können auch mehrfach pro Gerät auftreten. Dann hat das Auslesen der Einstellungen nicht geklappt und sollte nochmals durchgeführt werden. Dafür muss man FHEM aber nicht neu starten, sondern das HM-Device per

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
in der Befehlszeile von FHEM und anschließendem <Enter> (nicht "save") darauf einstellen.

Die Channels (z.B. <HM-CC-TC-Name>_Climate, _Weather, _WindowRec) eines HM-Gerätes brauchen nicht (können aber bei Bedarf) separat ausgelesen bzw. gesichert zu werden, da sie Bestandteil der Basisabfrage sind.

== Funkprobleme auffangen ==
Der wohl am häufigsten an den HM-CC-TC gesendete Befehl ist "set desired-temp", mit dem die Wunschtemperatur neu gesetzt wird.
Funktioniert dieser Befehl jedoch nicht zuverlässig, wird die Wohnung ggf. zu lange oder nicht rechtzeitig beheizt.
Der folgende Mechanismus soll die Sicherheit erhöhen, indem die Antworten des HM-CC-TC geprüft werden und ggf. das Funktelegramm erneut gesendet wird.

Um den Sollwert zum erneuten Senden des Funktelegramms verfügbar zu haben, wird ein dummy definiert:

<nowiki>define HM_TC_Solltemperatur dummy</nowiki>
Wann immer die Solltemperatur geändert wird, setzt man die neue desired-temp nicht nur auf dem HM-TC-CC (hier HM_TC genannt), sondern auch auf dem dummy. Der Befehl (z.B. in der [[Zuhause-Status|Routine zum HomeStatus]]) sieht dann so aus:

<nowiki>set HM_TC desired-temp 21;set HM_TC_Solltemperatur 21</nowiki>
Falls das ausgehende Funktelegramm verlorengeht, fehlt die Antwort "command accepted". Dies kann mit einem watchdog aufgefangen werden, der dann den Befehl an den HM-CC-TC erneut sendet:

<nowiki>define w_HM_TC watchdog HM_TC:set_desired-temp.* 00:02:30 HM_TC_Climate:CommandAccepted:.yes { \
Log 1, ">>>>>>>>> w_HM_TC desired temp - missing response.";\
fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\
}</nowiki>
Falls ein Fehler bei der Funkkommunikation auftritt, erhält man die Antwort "missing ACK" oder "NACK". Auch in diesem Fall soll das Telegramm zum Ändern der Wunschtemperatur erneut an den HM-CC-TC gesendet werden:

<nowiki>define n_HM_TC_err notify HM_TC:(MISSING.ACK.*|.*NACK.*) {\
Log 1, ">>>>>>>>> n_HM_TC desired temp - missing ack/nack.\n";\
fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\
}</nowiki>
Mit diesen beiden Helfern ist die Funkkommunikation zum HM-CC-TC sehr zuverlässig.

== Plots / Grafiken ==
=== Problem ===
Durch ''autocreate'' wird zwar ein Log angelegt, aber kein Plot (Grafische Auswertung). Dem kann man aber abhelfen (siehe unten).

=== Plots erzeugen ===
''PGM2'' ist die Standardansicht des Fhem-Web-Interfaces. Um hier Plots/Grafiken zu erzeugen einfach unter dem ''Filelog'' des Thermostaten das ''attr logtype'' auf ''temp4hum6:Plot,text'' setzen und es wird ein Plot-Link neben dem Text-Link angezeigt. Nun können Sie auf diesen Plot-Link klicken und ...

=== alternative Plots ===
Mit dem fht.gplot funktioniert die Anzeige der Ventilstellung (actuator) nicht.

Mit folgendem angepassten .gplot File wird die gemessene Temperatur und Ventilstellung angezeigt.

<nowiki>############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define <filelogname> FileLog /var/log/fhem/actuator_name-%Y.log <actuator_name>:(measured-temp|actuator).*

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 ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics

set y2label "Temperatur in C"
set ylabel "Ventil (%)"

#FileLog 4:measured:10:
#FileLog 4:actuator:50:

plot \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Temperatur in C' with lines,\
"< egrep 'actuator' <IN>"\
using 1:4 axes x1y1 title 'Ventil (%)' with lines\</nowiki>
=== Alles-drin-Plot ===
dazu nimmt man folgendes .gplot. Man/Fra beachte, dass hierfür alle Parameter nach der define-Anweisung in das Logfile geschrieben werden.

<nowiki>############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define <filelogname> FileLog /var/log/fhem/HM_CC_TC-%Y.log <HM_CC_TC-name>
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 ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics
set y2label "Temperature in C"
set ylabel "Actuator (%)"
#FileLog 4:temperature:0:
#FileLog 4:desired:0:
#FileLog 4:humidity:0:
#FileLog 4:actuator:0:int
plot \
"< awk '/temperature/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Measured temperature' with lines lw 2,\
"< awk '/desired/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Desired temperature' with steps,\
"< awk '/humidity/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Humidity (%)' with lines,\
"< awk '/actuator/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Actuator (%)' with lines\</nowiki>

== Steuerungsmodi ==
Das Wandthermostat hat 4 verschiedene Steuerungsmöglichkeiten:

* Auto (automatisch)
* Cent (Zentrale)
* Manu (manuell)
* Prog / Koffer-Symbol (Urlaubs/Party-Modus, wird hier nicht näher erörtert)

Der Steuerungsmodus wird über wiederholtes Drücken der linken Taste des HM-CC-TC ausgewählt bzw. gewechselt.

'''Hinweis:''' Durch das P'''ai'''ren des HM-CC-TC <ins>und</ins> der Stellantrieb sowie Tür-/Fensterkontakte an Fhem verlieren Sie '''nicht''' die Steuerungsmöglichkeiten. Im Gegenteil: Nur wenn auch die VDs usw. mit Fhem gep'''ai'''rt sind, haben Sie die Möglichkeit, auch diese zu überwachen. Die Steuerung '''können''' Sie dennoch allein dem HM-CC-TC überlassen.

=== Auto-Modus ===
Im Modus '''Auto''' wird die Temperaturregelung über die im TC hinterlegten Temperaturlisten vorgenommen. Das Thermostat arbeitet also selbständig, somit unabhängig von einer Zentrale / FHEM. Nur in diesem Modus werden die evtl. per FHEM an das TC übermittelten "templist" abgearbeitet. Über das Senden von angepassten Temperatur-Listen kann eine indirekte Steuerung per FHEM erfolgen. '''Jederzeit''' kann zudem die Raumtemperatur über das Drehrad des Wandthermostaten oder die FHEM-Web-Oberfläche verändert werden. Diese ''Übersteuerung'' der Temperaturliste gilt bis zur nächsten Temperaturänderung nach der vorgenannten Liste.

=== Cent-Modus ===
Im Modus '''Cent''' steuert eine HomeMatic-Zentrale (CCU) oder eben ein FHEM-Server mit z.B. [[HMLAN Konfigurator]] zu den in der FHEM-Config hinterlegten Zeiten und mit den dort festgelegten Temperaturen. Fällt also die HM-Zentrale aus, erfolgt keine Steuerung der Thermostaten bzw. Heizungsventile mehr.

<ins>Anmerkung</ins>: Der Modus ''cent'' erscheint nur dann im Display des HM-CC-TC, wenn er an eine Zentrale bzw. das [[CUL]] angelernt (gepairt) wurde.

=== Manu-Modus ===
Der Modus '''Manu''' übersteuert die im TC hinterlegten Temperaturlisten und die evtl. von der HM-Zentrale / dem FHEM <ins>vor Umstellung auf ''Manu''</ins> gesendeten Einstellungen. Es wird also bis zur nächsten Modusumstellung bzw. manuellen Temperaturverstellung der per Einstellrad gesetzte Temperaturwert gefahren.

Aber auch in diesem Modus kann man die ''desired-temperature'' per FHEM verstellen. Der dadurch eingestellte Wert gilt ab sofort als der neue im ''Manu-Modus'' zu haltende Wert.

=== Auslesen des eingestellten Steuerungsmodus ===
Der eingestellte Steuerungsmodus erscheint normalerweise in den ''Readings'' des HM-CC-TC unter ''controlMode''. Zusätzlich haben Sie die Möglichkeit, diesen Modus auch in der FHEM-Weboberfläche ''everything'' => Abschnitt ''thermostat'' zu sehen, '''wenn''' Sie für den HM-CC-TC das folgende Attribut setzen:

<nowiki>attr <HM-CC-TC-Name> stateFormat T:measured-temp, H:humidity, VD:actuator, controlMode</nowiki>
Erscheint dort selbst nach einem

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
kein "Reading" ''controlMode'' oder keine Angabe des aktuell eingestellten Modus bzw. nur das Wort "controlMode", dann setzen Sie ihren HM-CC-TC von Hand in einen anderen Kontrollmodus und machen einen Browser-Refresh. Klappt dies nicht, geben Sie bitte erneut den Befehl

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
ein. Halten Sie anschließend die Taste <OK> am HM-CC-TC für 5 Sekunden gedrückt (oder warten ca. 5 Minuten) und machen in der FHEM-Weboberfläche einen Browser-Refresh (FF => <F5>). Jetzt sollte der manuell eingestellte Kontrollmodus erscheinen (ggfls. muss dieser Vorgang einmal wiederholt werden). Jetzt können Sie wieder den gewünschten Modus einstellen, erneut ein

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
absetzen und nach erneutem Drücken der <OK>-Taste für 5 Sekunden mit nachfolgendem Browser-Refresh sollte alles richtig angezeigt werden.

Dies setzt natürlich voraus, dass der HM-CC-TC richtig gepairt ist.

== Temperaturlisten ==

'''Achtung:''' Die Listen mussten bis vor kurzem noch auf das Device HM-CC-TC, nunmehr aber auf dessen Channel HM-CC-TC_Climate gesetzt werden. Dadurch ändert sich die Benennung des Gerätes (wird in den u.a. Beispielen berücksichtigt).

Eine Temperaturliste für die Steuerung der Raumtemperatur im o.a. '''Auto-Modus''' kann man wie folgt erzeugen:

* Man legt sich eine eigene ''99_MyUtils.pm'' an (siehe [[99_myUtils anlegen]]). Dies ist wichtig, da es bei FHEM-Updates durchaus sein kann, dass die vorhandene ''99_Utils.pm'' erneuert und damit überschrieben wird und dann sind all ihre eigenen Subroutinen weg.
* Dort trägt man für '''jedes''' HM-CC-TC, dessen Werte man individuell einstellen will, eine '''eigene''' Subroutine ein, die z.B. wie folgt aussehen kann:

<pre>
######################################################
# Temperatur-Liste für das Wohnzimmer
# setzen per Aufruf von "{SetTempList_EG_WZ_Heizung}"
######################################################
sub
SetTempList_EG_WZ_Heizung()
{
{ fhem ("set EG.WZ.Heizung_Climate tempListMon 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListTue 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListWed 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListThu 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListFri 05:30 19.0 07:00 21.0 15:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListSat 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListSun 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.5")};
}
# End SetTempList_EG_WZ_Heizung
</pre>

* die Änderungen in der ''99_MyUtils.pm'' müssen jetzt abgespeichert werden
* in der FHEM-Befehlszeile ist ein ''reload 99_MyUtils.pm'' mit <Enter> / <Return> abzusetzen (erst dadurch werden die Eintragungen / Änderungen aktiviert)
* nun kann man in der Kommandozeile von FHEM den Befehl ''{SetTempList_EG_WZ_Heizung}'' eingeben und mit <Return> bzw. <Enter> bestätigen

Im FHEM-Logfile (das man vorher in einem weiteren Browser-Tab geöffnet hat, Refresh (F5) nicht vergessen) taucht danach folgendes auf:

<pre>
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListMon 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListTue 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListWed 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListThu 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListFri 05:30 17.0 07:00 21.0 15:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListSat 07:00 17.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListSun 07:00 17.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0
</pre>

'''Zur Erläuterung:'''

Mittels

<pre>
set EG.WZ.Heizung_Climate tempListMon 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
</pre>

setzt man den HM-CC-TC-Channel mit dem Namen ''EG.WZ.Heizung_Climate'' für jeden folgenden Montag

von 00:00 '''bis''' 05:30 Uhr auf 17,0 °C 
von 05:31 '''bis''' 07:00 Uhr auf 21,0 °C 
von 07:31 '''bis''' 16:00 Uhr auf 19,0 °C 
...

und so weiter. Dabei kann bei der Temperatur als Nachkommawert entweder eine 0 oder eine 5 stehen, ein Wert von z.B. 20,1 ist nicht erlaubt.

'''Achtung:''' Häufigste Fehlerquelle ist das Verstehen der Reihen- bzw. Abfolge der Zeit- und Temperaturwerte. Deshalb ein weiterer Beschreibungsversuch mit anderen Worten, der hoffentlich zum besseren Verständnis beiträgt:

Die Definition <ins>beginnt</ins> von selbst jeweils bei 00:00 Uhr eines Tages. Die danach angegebene Uhrzeit (im letzten Beispiel ''tempListMon'': 05:30 Uhr) beschreibt also den Zeitraum von 00:00 Uhr '''bis''' 05:30 Uhr. Der <ins>danach</ins> folgende Wert von 17.0 definiert also den in der Zeit von 00:00 Uhr '''bis''' 05:30 Uhr geltenden Wunschtemperaturwert von 17,0 °C. Die im vorgenannten Beispiel auf die Wertangabe ''17.0'' folgende Uhrzeit von ''07:00'' legt nun den Zeitraum von 05:30 Uhr '''bis''' 07:00 Uhr für den dahinter stehenden Temperaturwert von 21.0 fest. Die Abfolge kann dem Einen oder der Anderen unnatürlich vorkommen, aber es ist eine so von eQ3 festgelegte Notationsweise.

'''Beachten Sie bitte''', dass am Schluss der Liste <ins>immer</ins> eine Einstellung für 24:00 notiert sein '''muss'''. Ansonsten quittiert FHEM das Setzen der Liste mit einem solchen Eintrag im Logfile:

<pre>
Last time spec must be 24:00
</pre>

Im FHEM-Logfile-Browser-Tab sollten nach einigen Minuten folgende mehrfach wiederholten Einträge auftauchen:

<pre>
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate CommandAccepted: yes
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate CommandAccepted: yes
...
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate CommandAccepted: yes
</pre>

Wichtig ist ein nachfolgendes "ACK". Steht dort "MISSING ACK", dann wurde der Empfang der Werte vom HM-CC-TC nicht bestätigt und man sollte die TempList noch einmal schicken. Kommt auch nach mehreren Sendeversuchen kein "ACK" sollten Sie in den ''Readings''des Devices die ''TempList''überprüfen (siehe unten), denn es kann sein, dass diese Antwort schlicht nicht empfangen werden konnte, weil der Empfänger gerade anderweitig beschäftigt war, die Einstellungen aber dennoch übernommen wurden. Wird jedoch ein "NACK" vom HM-CC-TC gesendet, dann wurde die Temperaturliste explizit nicht akzeptiert. Kontrollieren Sie in diesem Fall die Korrektheit der Temperaturliste.

Welche Werte '''aktuell eingestellt'''sind, sieht man in den "Readings" des jeweiligen Devices; im obigen Fall also z.B. im linken Menü von FHEM auf den default-Eintrag ''Everything''klicken und dann auf den Eintrag mit dem Namen ''EG.WZ.Heizung''.

== Temperaturlisten (neu) ==

Seit Mitte Oktober 2013 kann man die Temperaturlisten "ressourcenschonender" an einen HM-CC-TC übertragen. Bisher wurde für jeden Tag ein Befehl abgeschickt (siehe obiges Beispiel). Nun kann man, wie beim [[HM-CC-RT-DN Funk-Heizkörperthermostat#Temperaturlisten setzen|HM-CC-RT-DN] (dem Nachfolger des HM-CC-TC), auch alles in ein einziges "Funktelegramm" packen. Dazu das folgende Beispiel (achten Sie bitte auf die Schlüsselwörter "prep" und "exec"):

######################################################
# Temperatur-Liste für Kinderzimmer
# setzen per Aufruf von "{SetTempList_Kind_Heizung}"
######################################################
sub
SetTempList_Kind_Heizung()
{
{ fhem ("set DG.Kind.Heizung_Climate tempListMon prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListTue prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListWed prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListThu prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListFri prep 05:30 19.0 07:00 20.5 15:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListSat prep 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListSun exec 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0")};
}
# End SetTempList_Kind_Heizung

Zum Verständnis: Mittels ''prep'' werden die Werte in einen "Puffer" gepackt und sobald ein "exec" auftaucht, wird er Puffer mit dem Nachfolgenden gefüllt und anschließend '''in einem Rutsch''' an den HM-CC-TC geschickt. Dies vermeidet/minimiert Übertragungsprobleme.

== Batteriealarme des HM-CC-VD in Verbindung mit HM-CC-TC ==
1. bei U-Bat. < 2,4 V erscheint im Display des VD und des TC das Batteriesymbol mit '''battery: low''' in den Readings und Events!

2. bei U-Bat. < 2,3 V erscheint im Display des VD zusätzlich '''F4''' mit '''battery: critical''' in den Readings und Events!

Es wird dringend geraten, die Batterien bei battery: low zu tauschen!

== Log-Auszug ==
HM-CC-TC sendet alle 2 Minuten folgenden Statusbericht:

<nowiki>Datum-Zeit <Device Name> T: 17.3 H: 66 
Datum-Zeit <Device Name> measured-temp: 17.3 
Datum-Zeit <Device Name> temperature: 17.3 
Datum-Zeit <Device Name> humidity: 66 
Datum-Zeit <Device Name> actuator: 96 % </nowiki>
Bei Status-Änderungen sendet HM-CC-TC auch entsprechende Meldungen, z.b.:

<nowiki>Datum-Zeit <Device Name> desired-temp: 15.5 </nowiki>

= Probleme =

== Verstellen der Solltemperatur am HM-CC-TC per Drehrad ==

'''Symptom:''' Beim Verstellen der Solltemperatur per seitlichem Drehrad wurde die aktuelle Solltemperatur - '''egal ob''' man hoch oder runter drehte - immer nur in 0,5 °C Schritten '''runter''' gestellt, bis schließlich die Mindesttemperatur von 6,0 °C erreicht war. Weitere Änderungen waren nicht möglich

'''Abhilfe:''' Letztlich half nur das kurzzeitige Entfernen einer Batterie. Das danach für einige Zeit erscheinende Batteriesymbol zeigte den kleinstmöglichen guten Zustand an, in FHEM wurde das ''Reading'' des Batteriezustandes mit ''ok'' ausgegeben (wie in den Logs aber vorher auch). '''Letztlich half aber nur''' das Einsetzen neuer Batterien, denn die o.a. Störung trat nach ca. 2 Stunden erneut auf. Die "alten" Batterien (die, die dem HM-CC-TC ab Werk beilagen) hatten somit eine Nutzungsdauer von knapp 11 Monaten, waren aber auch in einem HM-CC-TC, der mit 4 Stck. HM-Sec-SC (mussten sehr oft "Meldung machen") und 4 Stck. HM-CC-VD gepeert war. ''Ohne Last'' zeigten die beiden alten AA-Batterien eine Spannung von jeweils 1,29 V an.

'''Hinweis:''' Die unter ''Abhilfe'' beschriebene Lösung war leider nur von kurzer Dauer. Bereits kurz danach zeigte der HM-CC-TC die gleichen Ausfallerscheinungen. Bei ELV gibt es das Bauteil für das Drehrad (Inkrementalgeber) als [http://www.elv.de/inkrementalgeber-fuer-fs20-str-fht-8-und-homematic-hm-cc-tc.html Ersatzteil]. Sobald dieses geliefert und ein Reparaturversuch unternommen wurde, wird an dieser Stelle weiter berichtet.

== HM-CC-TC misst zu hohe/niedrige Luftfeuchte-Werte ==

'''Symptom:''' In den Fhem-Logs und demzufolge auch in den Plots/Grafiken eines seit über 18 Monaten im Einsatz befindlichen HM-CC-TC wurden viel zu hohe (einzelne Spitzenwerte von 98 oder 99 %) bzw. ständig zu niedrige Werte für die relative Luftfeuchte gemessen (im direkten Vergleich zu anderen HM-CC-TCs). Die anderen Werte (Temperatur, Actuator) waren aber schlüssig.

'''Abhilfe:''' Batteriewechsel. Die alten Batterien hatten (unbelastet) noch knapp über 1 V Spannung.

'''Hinweis:''' Eine Batteriewarnung des Gerätes gab es nicht. Im Display war das entsprechende Symbol noch auf 1 Balken.

= Firmware =
Aktuelle Firmware-Version: 2.1

= Links =
Anleitung [http://www.elv-downloads.de/service/manuals/76787_76175_HM_Wandthermostat_UM.pdf PDF]

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

HM-CC-TC Funk-Wandthermostat

2014-07-05T16:32:03Z

Rohan: /* autoReadReg */ Typo

'''HM-CC-TC Funk-Wandthermostat'''

Programmierbarer Raumthermostat, der bis zu 4 [[HM-CC-VD Funk-Stellantrieb]] steuern kann.

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt).'''

Nachfolgeprodukt ist der [[HM-CC-RT-DN]] bzw. (ab März 2014) [[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]].

= Features =
* Am Raumthermostat programmierbare Tages- und Nachttemperatur.
* Pro Wochentag können bis zu 24 Schaltpunkte definiert werden.
* Anbindung von <ins>jeweils</ins> '''maximal''' 4 Tür- bzw. Fensterkontakten ([[HM-Sec-RHS]]) zur Absenkung der Temperatur auf einen eigens eingestellten Temperaturwert (ab Werk: 12°C) bei offenem Fenster bzw. offener Tür.
* Anzeige der Temperatur und Luftfeuchtigkeit im Raum und Hintergrundbeleuchtung des Displays.

Alle 120 bis 184 Sekunden überträgt der Wandthermostat vorhandene Befehle zu den Stellantrieben. Jeder empfangene Befehl wird vom Stellantrieb bestätigt und dann ausgeführt. Täglich gegen Mitternacht synchronisiert ein HM-CC-TC seine Uhrzeit mit der HomeMatic-Zentrale (CCU, HMLAN).

= Hinweise zum Betrieb mit FHEM =
Vor dem Einsatz mit einer Zentrale sind erst alle Stellantriebe und Tür-/Fensterkontakte mit dem HM-CC-TC zu verbinden (P'''ee'''r).
Damit das ganze dann in FHEM auftaucht, muss der TC noch mit dem [[HMLAN Konfigurator]] gep'''ai'''rt werden.

Mit

<nowiki>set CUL hmPairForSec 300</nowiki>
setzt man das CUL / den HMLAN-Konfigurator für 5 Minuten in den Anlernmodus. Danach am Thermostaten 5 Sekunden lang die OK-Taste drücken und es wird eine Zeit von 20 auf 0 Sekunden gezählt:

* Klappt das Anlernen in diesen 20 Sekunden, wird der Countdown sofort beendet, anschließend für ca. 2-3 Sekunden "OK" angezeigt und der Thermostat ist in FHEM eingebunden.
* Gelingt das Anlernen nicht in den 20 Sekunden, erscheint nach Erreichen der "0" noch für 2 bis 3 Sekunden ein "NOK" ('''N'''ot '''OK''') im Display des TCs.

'''Alternativ'''(und so vom Entwickler des Fhem-HomeMatic-Moduls empfohlen) kann wie folgt vorgegangen werden:

* Alle Stellantriebe und Tür-/Fensterkontakte sowie den HM-CC-TC mit Fhem p'''ai'''ren (also ''set CUL hmPairForSec 300'' und an allen Devices den Anlernknopf drücken innerhalb des Zeitfensters von 300 Sekunden).
* Die Stellantriebe und Tür-/Fensterkontakte mit den ''Channels'' (siehe unten) p'''ee'''ren (siehe <nowiki>[http://fhem.de/commandref.html#CUL_HMpeerChan commandref :peerChan]</nowiki>). Hierzu werden die entsprechenden Fhem-Befehle über das Webinterface von Fhem erteilt.

'''Hinweis:'''
* Alle in der FHEM-Eingabezeile eingegebenen ''attr''-, ''define''-Befehle usw. müssen zum Schluss noch per Klick auf den "Save"-Button dauerhaft in der ''fhem.cfg'' gespeichert werden, sonst sind sie nach z.B. einem Systemabsturz verloren.
* Falls in der FHEM-Weboberfläche für ihren HM-CC-TC etwas wie ''X CMDs pending'' steht, sollten Sie ihren HM-CC-TC zur Hand nehmen und für 20 Sekunden auf die OK-Taste drücken. Dadurch werden alle noch ausstehenden Befehle eingelesen.

== Auszug aus der fhem.cfg ==
Die nachfolgenden Einstellungen zum HM-CC-TC werden von FHEM <ins>weitestgehend</ins> automatisch gesetzt. Die Pfadangaben für die Log-Dateien sind system-, die Raumbenennungen benutzerabhängig. Zu ''autoReadReg''und ''expert''siehe unten. Neben dem eigentlichen Basis-Gerät (HM-CC-TC) werden in FHEM automatisch noch 3 weitere "Unter"-Geräte (Channels/Kanäle), nämlich

* ''_Weather''
* ''_Climate''
* ''_WindowRec''

definiert (durch das Anlernen des TC an FHEM; siehe unten), deren Benennung sich (jeweils mit einem vorangestellten Unterstrich "_") am Namen des Basis-Gerätes orientiert.

'''Anmerkung:'''Die in den unten gezeigten ''fhem.cfg''-Auszügen markierten <ins>Peer</ins>-Einträge tauchen erst auf, sobald man die Daten aus dem TC mit ''set HM-CC-TC-Basisname getConfig''bzw. ''autoReadReg''ausgelesen hat.

=== Hauptgerät ===
<nowiki>define <HM-CC-TC>.Heizung CUL_HM 1DA491
attr <HM-CC-TC>.Heizung actCycle 000:10
attr <HM-CC-TC>.Heizung actStatus alive
attr <HM-CC-TC>.Heizung autoReadReg 1
attr <HM-CC-TC>.Heizung devInfo 00FFFF
attr <HM-CC-TC>.Heizung expert 2_full
attr <HM-CC-TC>.Heizung firmware 2.1
attr <HM-CC-TC>.Heizung hmClass receiver
attr <HM-CC-TC>.Heizung model HM-CC-TC
attr <HM-CC-TC>.Heizung room <IhrRaum>
attr <HM-CC-TC>.Heizung serialNr JE********
attr <HM-CC-TC>.Heizung subType thermostat</nowiki>
=== Channel (Kanal) 01 _Weather ===
<nowiki>define <HM-CC-TC>.Heizung_Weather CUL_HM 1DA49101 <<<=== 01 = Kanal 1
attr <HM-CC-TC>.Heizung_Weather model HM-CC-TC
attr <HM-CC-TC>.Heizung_Weather peerIDs
attr <HM-CC-TC>.Heizung_Weather room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_Weather FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_Weather-%Y-%m.log <HM-CC-TC>.Heizung_Weather
attr FileLog_<HM-CC-TC>.Heizung_Weather logtype text
attr FileLog_<HM-CC-TC>.Heizung_Weather room CUL_HM,<IhrRaum></nowiki>
=== Channel (Kanal) 02 _Climate ===
<nowiki>define <HM-CC-TC>.Heizung_Climate CUL_HM 1DA49102 <<<=== 02 = Kanal 2
attr <HM-CC-TC>.Heizung_Climate model HM-CC-TC
attr <HM-CC-TC>.Heizung_Climate peerIDs 1AD52B01,1B7A4C01,1C4CD101,1C48EC01, <<<=== gepeerte HM-CC-VDs
attr <HM-CC-TC>.Heizung_Climate room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_Climate FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_Climate-%Y-%m.log <HM-CC-TC>.Heizung_Climate
attr FileLog_<HM-CC-TC>.Heizung_Climate logtype text
attr FileLog_<HM-CC-TC>.Heizung_Climate room CUL_HM,<IhrRaum></nowiki>
=== Channel (Kanal) 03 _WindowRec ===
<nowiki>define <HM-CC-TC>.Heizung_WindowRec CUL_HM 1DA49103 <<<=== 03 = Kanal 3
attr <HM-CC-TC>.Heizung_WindowRec model HM-CC-TC
attr <HM-CC-TC>.Heizung_WindowRec peerIDs 1CFBB001, <<<=== gepeerte HM-Sec-SCs
attr <HM-CC-TC>.Heizung_WindowRec room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_WindowRec FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_WindowRec-%Y-%m.log <HM-CC-TC>.Heizung_WindowRec
attr FileLog_<HM-CC-TC>.Heizung_WindowRec logtype text
attr FileLog_<HM-CC-TC>.Heizung_WindowRec room CUL_HM,<IhrRaum></nowiki>
== Einstellungen eines HM-CC-TC lesen, anzeigen und sichern ==
=== expert ===
Anfang Februar 2013 wurde eine Änderung bei der Anzeige der so genannten ''Readings'' (Register usw.), also der Einstellungen bzw. Eigenschaften eines HM-Devices, eingeführt. '''Alle''' Werte sieht man nur noch, wenn man am HM-CC-TC das Attribut ''expert'' auf ''2_all'' setzt. Per '''default''' (nicht in ''fhem.cfg'' gesetzt) steht dieser Wert auf ''0_off'' (nur die notwendigsten Readings/Eigenschaften werden angezeigt). Mittelweg ist der Wert ''1_on''.

Mittels

<nowiki>attr <HM-CC-TC-Name> expert 2_full</nowiki>
in der FHEM-Befehlszeile mit anschließendem <Enter> setzt man diesen Level.

Falls man mit '''Temperaturlisten''' arbeitet (siehe unten), dann kann man die komplette Liste im "Channel" (Kanal) ''<HM-CC-TC-Name>__Climate'' einsehen. Auch für diesen Kanal ist evtl. ein setzen des Attributes ''expert 2_full'' angeraten.

<ins>Anmerkung:</ins> Es gibt auch noch sogenannte "hidden datas" (versteckte interne Werte, Register oder Eigenschaften deren Namen mit einem "." beginnen). Diese sieht man nur dann, wenn auch das Attribut ''showInternalValues 1'' gesetzt ist (default: 0 bzw. nicht gesetzt).

=== autoReadReg ===
Mitte Januar 2013 wurde das neue Attribut ''autoReadReg'' eingeführt, welches auf ''0'' voreingestellt ist (kein Eintrag in der ''fhem.cfg''). Das Setzen dieses Attributes auf ''1'' bewirkt, dass <ins>beim Neustart von FHEM</ins> die Einstellungen des entsprechenden HM-Gerätes ausgelesen werden. Dies wird bei mehreren ''autoReadReg''s automatisch zeitversetzt vorgenommen, um die Funk-Kommunikation nicht unnötig zu belasten.

Mittels

<nowiki>attr <HM-CC-TC-Name> autoReadReg 1 </nowiki>
in der FHEM-Befehlszeile mit anschließendem <Enter> setzt man diesen Wert.

=== list ===
Um sich alle Eigenschaften/Readings eines Gerätes anzusehen, gibt es den Befehl ''list''.

Mittels

<nowiki>list <HM-CC-TC-Name></nowiki>
und Bestätigung mit <Enter> erhalten Sie die gewünschte Anzeige Ihres TCs <ins>incl.</ins> seiner 3 Channels. Über

<nowiki>list <HM-CC-TC-Name>_<Channel-Name></nowiki>
werden nur die Daten des angegebenen Channels angezeigt.

=== Einstellungen sichern ===
Die Durchführung von ''autoReadReg'' kann durchaus mehrere Minuten dauern. Anschließend besteht die Möglichkeit, diese per

<nowiki>get HM-CC-TC-Basisname saveConfig [/Verzeichnis/mit/Schreibrechten/]<Dateiname></nowiki>
für jedes HM-CC-TC getrennt zu sichern (für eine später notwendige Wiederherstellung). Die Sicherungsdatei wird regulär im ''modpath'' (siehe ''fhem.cfg'') abgelegt. Falls dies nicht zum Erfolg führt (es wird - ohne Fehlermeldungen bei regulärem ''verbose'' und ''loglevel'' - im ''modpath'' keine Datei angelegt), müssen Sie vor dem Dateinamen einen vollständigen Pfad mit Schreibrechten für den Benutzer, unter dem FHEM läuft, angeben.

In der <ins>Log-Datei</ins> von FHEM erscheinen danach Meldungen folgender Art

<nowiki><Datum>_<Zeit> 2: CUL_HM set <HM-CC-TC-Name> statusRequest rxt:12
<Datum>_<Zeit> 2: CUL_HM set <HM-CC-TC-Name> getConfig rxt:12</nowiki>
Hierbei kann es (im <ins>Event monitor</ins> von FHEM) zu folgenden Fehlermeldungen kommen

<nowiki><Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:RegisterRead
<Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:PeerList
<Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:StatusReq</nowiki>
Diese Meldungen können auch mehrfach pro Gerät auftreten. Dann hat das Auslesen der Einstellungen nicht geklappt und sollte nochmals durchgeführt werden. Dafür muss man FHEM aber nicht neu starten, sondern das HM-Device per

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
in der Befehlszeile von FHEM und anschließendem <Enter> (nicht "save") darauf einstellen.

Die Channels (z.B. <HM-CC-TC-Name>_Climate, _Weather, _WindowRec) eines HM-Gerätes brauchen nicht (können aber bei Bedarf) separat ausgelesen bzw. gesichert zu werden, da sie Bestandteil der Basisabfrage sind.

== Funkprobleme auffangen ==
Der wohl am häufigsten an den HM-CC-TC gesendete Befehl ist "set desired-temp", mit dem die Wunschtemperatur neu gesetzt wird.
Funktioniert dieser Befehl jedoch nicht zuverlässig, wird die Wohnung ggf. zu lange oder nicht rechtzeitig beheizt.
Der folgende Mechanismus soll die Sicherheit erhöhen, indem die Antworten des HM-CC-TC geprüft werden und ggf. das Funktelegramm erneut gesendet wird.

Um den Sollwert zum erneuten Senden des Funktelegramms verfügbar zu haben, wird ein dummy definiert:

<nowiki>define HM_TC_Solltemperatur dummy</nowiki>
Wann immer die Solltemperatur geändert wird, setzt man die neue desired-temp nicht nur auf dem HM-TC-CC (hier HM_TC genannt), sondern auch auf dem dummy. Der Befehl (z.B. in der [[Zuhause-Status|Routine zum HomeStatus]]) sieht dann so aus:

<nowiki>set HM_TC desired-temp 21;set HM_TC_Solltemperatur 21</nowiki>
Falls das ausgehende Funktelegramm verlorengeht, fehlt die Antwort "command accepted". Dies kann mit einem watchdog aufgefangen werden, der dann den Befehl an den HM-CC-TC erneut sendet:

<nowiki>define w_HM_TC watchdog HM_TC:set_desired-temp.* 00:02:30 HM_TC_Climate:CommandAccepted:.yes { \
Log 1, ">>>>>>>>> w_HM_TC desired temp - missing response.";\
fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\
}</nowiki>
Falls ein Fehler bei der Funkkommunikation auftritt, erhält man die Antwort "missing ACK" oder "NACK". Auch in diesem Fall soll das Telegramm zum Ändern der Wunschtemperatur erneut an den HM-CC-TC gesendet werden:

<nowiki>define n_HM_TC_err notify HM_TC:(MISSING.ACK.*|.*NACK.*) {\
Log 1, ">>>>>>>>> n_HM_TC desired temp - missing ack/nack.\n";\
fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\
}</nowiki>
Mit diesen beiden Helfern ist die Funkkommunikation zum HM-CC-TC sehr zuverlässig.

== Plots / Grafiken ==
=== Problem ===
Durch ''autocreate'' wird zwar ein Log angelegt, aber kein Plot (Grafische Auswertung). Dem kann man aber abhelfen (siehe unten).

=== Plots erzeugen ===
''PGM2'' ist die Standardansicht des Fhem-Web-Interfaces. Um hier Plots/Grafiken zu erzeugen einfach unter dem ''Filelog'' des Thermostaten das ''attr logtype'' auf ''temp4hum6:Plot,text'' setzen und es wird ein Plot-Link neben dem Text-Link angezeigt. Nun können Sie auf diesen Plot-Link klicken und ...

=== alternative Plots ===
Mit dem fht.gplot funktioniert die Anzeige der Ventilstellung (actuator) nicht.

Mit folgendem angepassten .gplot File wird die gemessene Temperatur und Ventilstellung angezeigt.

<nowiki>############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define <filelogname> FileLog /var/log/fhem/actuator_name-%Y.log <actuator_name>:(measured-temp|actuator).*

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 ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics

set y2label "Temperatur in C"
set ylabel "Ventil (%)"

#FileLog 4:measured:10:
#FileLog 4:actuator:50:

plot \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Temperatur in C' with lines,\
"< egrep 'actuator' <IN>"\
using 1:4 axes x1y1 title 'Ventil (%)' with lines\</nowiki>
=== Alles-drin-Plot ===
dazu nimmt man folgendes .gplot. Man/Fra beachte, dass hierfür alle Parameter nach der define-Anweisung in das Logfile geschrieben werden.

<nowiki>############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define <filelogname> FileLog /var/log/fhem/HM_CC_TC-%Y.log <HM_CC_TC-name>
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 ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics
set y2label "Temperature in C"
set ylabel "Actuator (%)"
#FileLog 4:temperature:0:
#FileLog 4:desired:0:
#FileLog 4:humidity:0:
#FileLog 4:actuator:0:int
plot \
"< awk '/temperature/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Measured temperature' with lines lw 2,\
"< awk '/desired/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Desired temperature' with steps,\
"< awk '/humidity/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Humidity (%)' with lines,\
"< awk '/actuator/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Actuator (%)' with lines\</nowiki>

== Steuerungsmodi ==
Das Wandthermostat hat 4 verschiedene Steuerungsmöglichkeiten:

* Auto (automatisch)
* Cent (Zentrale)
* Manu (manuell)
* Prog / Koffer-Symbol (Urlaubs/Party-Modus, wird hier nicht näher erörtert)

Der Steuerungsmodus wird über wiederholtes Drücken der linken Taste des HM-CC-TC ausgewählt bzw. gewechselt.

'''Hinweis:''' Durch das P'''ai'''ren des HM-CC-TC <ins>und</ins> der Stellantrieb sowie Tür-/Fensterkontakte an Fhem verlieren Sie '''nicht''' die Steuerungsmöglichkeiten. Im Gegenteil: Nur wenn auch die VDs usw. mit Fhem gep'''ai'''rt sind, haben Sie die Möglichkeit, auch diese zu überwachen. Die Steuerung '''können''' Sie dennoch allein dem HM-CC-TC überlassen.

=== Auto-Modus ===
Im Modus '''Auto''' wird die Temperaturregelung über die im TC hinterlegten Temperaturlisten vorgenommen. Das Thermostat arbeitet also selbständig, somit unabhängig von einer Zentrale / FHEM. Nur in diesem Modus werden die evtl. per FHEM an das TC übermittelten "templist" abgearbeitet. Über das Senden von angepassten Temperatur-Listen kann eine indirekte Steuerung per FHEM erfolgen. '''Jederzeit''' kann zudem die Raumtemperatur über das Drehrad des Wandthermostaten oder die FHEM-Web-Oberfläche verändert werden. Diese ''Übersteuerung'' der Temperaturliste gilt bis zur nächsten Temperaturänderung nach der vorgenannten Liste.

=== Cent-Modus ===
Im Modus '''Cent''' steuert eine HomeMatic-Zentrale (CCU) oder eben ein FHEM-Server mit z.B. [[HMLAN Konfigurator]] zu den in der FHEM-Config hinterlegten Zeiten und mit den dort festgelegten Temperaturen. Fällt also die HM-Zentrale aus, erfolgt keine Steuerung der Thermostaten bzw. Heizungsventile mehr.

<ins>Anmerkung</ins>: Der Modus ''cent'' erscheint nur dann im Display des HM-CC-TC, wenn er an eine Zentrale bzw. das [[CUL]] angelernt (gepairt) wurde.

=== Manu-Modus ===
Der Modus '''Manu''' übersteuert die im TC hinterlegten Temperaturlisten und die evtl. von der HM-Zentrale / dem FHEM <ins>vor Umstellung auf ''Manu''</ins> gesendeten Einstellungen. Es wird also bis zur nächsten Modusumstellung bzw. manuellen Temperaturverstellung der per Einstellrad gesetzte Temperaturwert gefahren.

Aber auch in diesem Modus kann man die ''desired-temperature'' per FHEM verstellen. Der dadurch eingestellte Wert gilt ab sofort als der neue im ''Manu-Modus'' zu haltende Wert.

=== Auslesen des eingestellten Steuerungsmodus ===
Der eingestellte Steuerungsmodus erscheint normalerweise in den ''Readings'' des HM-CC-TC unter ''controlMode''. Zusätzlich haben Sie die Möglichkeit, diesen Modus auch in der FHEM-Weboberfläche ''everything'' => Abschnitt ''thermostat'' zu sehen, '''wenn''' Sie für den HM-CC-TC das folgende Attribut setzen:

<nowiki>attr <HM-CC-TC-Name> stateFormat T:measured-temp, H:humidity, VD:actuator, controlMode</nowiki>
Erscheint dort selbst nach einem

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
kein "Reading" ''controlMode'' oder keine Angabe des aktuell eingestellten Modus bzw. nur das Wort "controlMode", dann setzen Sie ihren HM-CC-TC von Hand in einen anderen Kontrollmodus und machen einen Browser-Refresh. Klappt dies nicht, geben Sie bitte erneut den Befehl

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
ein. Halten Sie anschließend die Taste <OK> am HM-CC-TC für 5 Sekunden gedrückt (oder warten ca. 5 Minuten) und machen in der FHEM-Weboberfläche einen Browser-Refresh (FF => <F5>). Jetzt sollte der manuell eingestellte Kontrollmodus erscheinen (ggfls. muss dieser Vorgang einmal wiederholt werden). Jetzt können Sie wieder den gewünschten Modus einstellen, erneut ein

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
absetzen und nach erneutem Drücken der <OK>-Taste für 5 Sekunden mit nachfolgendem Browser-Refresh sollte alles richtig angezeigt werden.

Dies setzt natürlich voraus, dass der HM-CC-TC richtig gepairt ist.

== Temperaturlisten ==

'''Achtung:''' Die Listen mussten bis vor kurzem noch auf das Device HM-CC-TC, nunmehr aber auf dessen Channel HM-CC-TC_Climate gesetzt werden. Dadurch ändert sich die Benennung des Gerätes (wird in den u.a. Beispielen berücksichtigt).

Eine Temperaturliste für die Steuerung der Raumtemperatur im o.a. '''Auto-Modus''' kann man wie folgt erzeugen:

* Man legt sich eine eigene ''99_MyUtils.pm'' an (siehe [[99_myUtils anlegen]]). Dies ist wichtig, da es bei FHEM-Updates durchaus sein kann, dass die vorhandene ''99_Utils.pm'' erneuert und damit überschrieben wird und dann sind all ihre eigenen Subroutinen weg.
* Dort trägt man für '''jedes''' HM-CC-TC, dessen Werte man individuell einstellen will, eine '''eigene''' Subroutine ein, die z.B. wie folgt aussehen kann:

<pre>
######################################################
# Temperatur-Liste für das Wohnzimmer
# setzen per Aufruf von "{SetTempList_EG_WZ_Heizung}"
######################################################
sub
SetTempList_EG_WZ_Heizung()
{
{ fhem ("set EG.WZ.Heizung_Climate tempListMon 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListTue 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListWed 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListThu 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListFri 05:30 19.0 07:00 21.0 15:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListSat 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListSun 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.5")};
}
# End SetTempList_EG_WZ_Heizung
</pre>

* die Änderungen in der ''99_MyUtils.pm'' müssen jetzt abgespeichert werden
* in der FHEM-Befehlszeile ist ein ''reload 99_MyUtils.pm'' mit <Enter> / <Return> abzusetzen (erst dadurch werden die Eintragungen / Änderungen aktiviert)
* nun kann man in der Kommandozeile von FHEM den Befehl ''{SetTempList_EG_WZ_Heizung}'' eingeben und mit <Return> bzw. <Enter> bestätigen

Im FHEM-Logfile (das man vorher in einem weiteren Browser-Tab geöffnet hat, Refresh (F5) nicht vergessen) taucht danach folgendes auf:

<pre>
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListMon 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListTue 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListWed 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListThu 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListFri 05:30 17.0 07:00 21.0 15:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListSat 07:00 17.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListSun 07:00 17.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0
</pre>

'''Zur Erläuterung:'''

Mittels

<pre>
set EG.WZ.Heizung_Climate tempListMon 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
</pre>

setzt man den HM-CC-TC-Channel mit dem Namen ''EG.WZ.Heizung_Climate'' für jeden folgenden Montag

von 00:00 '''bis''' 05:30 Uhr auf 17,0 °C 
von 05:31 '''bis''' 07:00 Uhr auf 21,0 °C 
von 07:31 '''bis''' 16:00 Uhr auf 19,0 °C 
...

und so weiter. Dabei kann bei der Temperatur als Nachkommawert entweder eine 0 oder eine 5 stehen, ein Wert von z.B. 20,1 ist nicht erlaubt.

'''Achtung:''' Häufigste Fehlerquelle ist das Verstehen der Reihen- bzw. Abfolge der Zeit- und Temperaturwerte. Deshalb ein weiterer Beschreibungsversuch mit anderen Worten, der hoffentlich zum besseren Verständnis beiträgt:

Die Definition <ins>beginnt</ins> von selbst jeweils bei 00:00 Uhr eines Tages. Die danach angegebene Uhrzeit (im letzten Beispiel ''tempListMon'': 05:30 Uhr) beschreibt also den Zeitraum von 00:00 Uhr '''bis''' 05:30 Uhr. Der <ins>danach</ins> folgende Wert von 17.0 definiert also den in der Zeit von 00:00 Uhr '''bis''' 05:30 Uhr geltenden Wunschtemperaturwert von 17,0 °C. Die im vorgenannten Beispiel auf die Wertangabe ''17.0'' folgende Uhrzeit von ''07:00'' legt nun den Zeitraum von 05:30 Uhr '''bis''' 07:00 Uhr für den dahinter stehenden Temperaturwert von 21.0 fest. Die Abfolge kann dem Einen oder der Anderen unnatürlich vorkommen, aber es ist eine so von eQ3 festgelegte Notationsweise.

'''Beachten Sie bitte''', dass am Schluss der Liste <ins>immer</ins> eine Einstellung für 24:00 notiert sein '''muss'''. Ansonsten quittiert FHEM das Setzen der Liste mit einem solchen Eintrag im Logfile:

<pre>
Last time spec must be 24:00
</pre>

Im FHEM-Logfile-Browser-Tab sollten nach einigen Minuten folgende mehrfach wiederholten Einträge auftauchen:

<pre>
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate CommandAccepted: yes
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate CommandAccepted: yes
...
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate CommandAccepted: yes
</pre>

Wichtig ist ein nachfolgendes "ACK". Steht dort "MISSING ACK", dann wurde der Empfang der Werte vom HM-CC-TC nicht bestätigt und man sollte die TempList noch einmal schicken. Kommt auch nach mehreren Sendeversuchen kein "ACK" sollten Sie in den ''Readings''des Devices die ''TempList''überprüfen (siehe unten), denn es kann sein, dass diese Antwort schlicht nicht empfangen werden konnte, weil der Empfänger gerade anderweitig beschäftigt war, die Einstellungen aber dennoch übernommen wurden. Wird jedoch ein "NACK" vom HM-CC-TC gesendet, dann wurde die Temperaturliste explizit nicht akzeptiert. Kontrollieren Sie in diesem Fall die Korrektheit der Temperaturliste.

Welche Werte '''aktuell eingestellt'''sind, sieht man in den "Readings" des jeweiligen Devices; im obigen Fall also z.B. im linken Menü von FHEM auf den default-Eintrag ''Everything''klicken und dann auf den Eintrag mit dem Namen ''EG.WZ.Heizung''.

== Temperaturlisten (neu) ==

Seit Mitte Oktober 2013 kann man die Temperaturlisten "ressourcenschonender" an einen HM-CC-TC übertragen. Bisher wurde für jeden Tag ein Befehl abgeschickt (siehe obiges Beispiel). Nun kann man, wie beim [[HM-CC-RT-DN Funk-Heizkörperthermostat#Temperaturlisten setzen|HM-CC-RT-DN] (dem Nachfolger des HM-CC-TC), auch alles in ein einziges "Funktelegramm" packen. Dazu das folgende Beispiel (achten Sie bitte auf die Schlüsselwörter "prep" und "exec"):

######################################################
# Temperatur-Liste für Kinderzimmer
# setzen per Aufruf von "{SetTempList_Kind_Heizung}"
######################################################
sub
SetTempList_Kind_Heizung()
{
{ fhem ("set DG.Kind.Heizung_Climate tempListMon prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListTue prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListWed prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListThu prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListFri prep 05:30 19.0 07:00 20.5 15:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListSat prep 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListSun exec 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0")};
}
# End SetTempList_Kind_Heizung

Zum Verständnis: Mittels ''prep'' werden die Werte in einen "Puffer" gepackt und sobald ein "exec" auftaucht, wird er Puffer mit dem Nachfolgenden gefüllt und anschließend '''in einem Rutsch''' an den HM-CC-TC geschickt. Dies vermeidet/minimiert Übertragungsprobleme.

== Batteriealarme des HM-CC-VD in Verbindung mit HM-CC-TC ==
1. bei U-Bat. < 2,4 V erscheint im Display des VD und des TC das Batteriesymbol mit '''battery: low''' in den Readings und Events!

2. bei U-Bat. < 2,3 V erscheint im Display des VD zusätzlich '''F4''' mit '''battery: critical''' in den Readings und Events!

Es wird dringend geraten, die Batterien bei battery: low zu tauschen!

== Log-Auszug ==
HM-CC-TC sendet alle 2 Minuten folgenden Statusbericht:

<nowiki>Datum-Zeit <Device Name> T: 17.3 H: 66 
Datum-Zeit <Device Name> measured-temp: 17.3 
Datum-Zeit <Device Name> temperature: 17.3 
Datum-Zeit <Device Name> humidity: 66 
Datum-Zeit <Device Name> actuator: 96 % </nowiki>
Bei Status-Änderungen sendet HM-CC-TC auch entsprechende Meldungen, z.b.:

<nowiki>Datum-Zeit <Device Name> desired-temp: 15.5 </nowiki>

= Probleme =

== Verstellen der Solltemperatur am HM-CC-TC per Drehrad ==

'''Symptom:''' Beim Verstellen der Solltemperatur per seitlichem Drehrad wurde die aktuelle Solltemperatur - '''egal ob''' man hoch oder runter drehte - immer nur in 0,5 °C Schritten '''runter''' gestellt, bis schließlich die Mindesttemperatur von 6,0 °C erreicht war. Weitere Änderungen waren nicht möglich

'''Abhilfe:''' Letztlich half nur das kurzzeitige Entfernen einer Batterie. Das danach für einige Zeit erscheinende Batteriesymbol zeigte den kleinstmöglichen guten Zustand an, in FHEM wurde das ''Reading'' des Batteriezustandes mit ''ok'' ausgegeben (wie in den Logs aber vorher auch). '''Letztlich half aber nur''' das Einsetzen neuer Batterien, denn die o.a. Störung trat nach ca. 2 Stunden erneut auf. Die "alten" Batterien (die, die dem HM-CC-TC ab Werk beilagen) hatten somit eine Nutzungsdauer von knapp 11 Monaten, waren aber auch in einem HM-CC-TC, der mit 4 Stck. HM-Sec-SC (mussten sehr oft "Meldung machen") und 4 Stck. HM-CC-VD gepeert war. ''Ohne Last'' zeigten die beiden alten AA-Batterien eine Spannung von jeweils 1,29 V an.

'''Hinweis:''' Die unter ''Abhilfe'' beschriebene Lösung war leider nur von kurzer Dauer. Bereits kurz danach zeigte der HM-CC-TC die gleichen Ausfallerscheinungen. Bei ELV gibt es das Bauteil für das Drehrad (Inkrementalgeber) als [http://www.elv.de/inkrementalgeber-fuer-fs20-str-fht-8-und-homematic-hm-cc-tc.html Ersatzteil]. Sobald dieses geliefert und ein Reparaturversuch unternommen wurde, wird an dieser Stelle weiter berichtet.

= Firmware =
Aktuelle Firmware-Version: 2.1

= Links =
Anleitung [http://www.elv-downloads.de/service/manuals/76787_76175_HM_Wandthermostat_UM.pdf PDF]

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

HM-CC-TC Funk-Wandthermostat

2014-07-05T16:30:58Z

Rohan: /* expert */

'''HM-CC-TC Funk-Wandthermostat'''

Programmierbarer Raumthermostat, der bis zu 4 [[HM-CC-VD Funk-Stellantrieb]] steuern kann.

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt).'''

Nachfolgeprodukt ist der [[HM-CC-RT-DN]] bzw. (ab März 2014) [[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]].

= Features =
* Am Raumthermostat programmierbare Tages- und Nachttemperatur.
* Pro Wochentag können bis zu 24 Schaltpunkte definiert werden.
* Anbindung von <ins>jeweils</ins> '''maximal''' 4 Tür- bzw. Fensterkontakten ([[HM-Sec-RHS]]) zur Absenkung der Temperatur auf einen eigens eingestellten Temperaturwert (ab Werk: 12°C) bei offenem Fenster bzw. offener Tür.
* Anzeige der Temperatur und Luftfeuchtigkeit im Raum und Hintergrundbeleuchtung des Displays.

Alle 120 bis 184 Sekunden überträgt der Wandthermostat vorhandene Befehle zu den Stellantrieben. Jeder empfangene Befehl wird vom Stellantrieb bestätigt und dann ausgeführt. Täglich gegen Mitternacht synchronisiert ein HM-CC-TC seine Uhrzeit mit der HomeMatic-Zentrale (CCU, HMLAN).

= Hinweise zum Betrieb mit FHEM =
Vor dem Einsatz mit einer Zentrale sind erst alle Stellantriebe und Tür-/Fensterkontakte mit dem HM-CC-TC zu verbinden (P'''ee'''r).
Damit das ganze dann in FHEM auftaucht, muss der TC noch mit dem [[HMLAN Konfigurator]] gep'''ai'''rt werden.

Mit

<nowiki>set CUL hmPairForSec 300</nowiki>
setzt man das CUL / den HMLAN-Konfigurator für 5 Minuten in den Anlernmodus. Danach am Thermostaten 5 Sekunden lang die OK-Taste drücken und es wird eine Zeit von 20 auf 0 Sekunden gezählt:

* Klappt das Anlernen in diesen 20 Sekunden, wird der Countdown sofort beendet, anschließend für ca. 2-3 Sekunden "OK" angezeigt und der Thermostat ist in FHEM eingebunden.
* Gelingt das Anlernen nicht in den 20 Sekunden, erscheint nach Erreichen der "0" noch für 2 bis 3 Sekunden ein "NOK" ('''N'''ot '''OK''') im Display des TCs.

'''Alternativ'''(und so vom Entwickler des Fhem-HomeMatic-Moduls empfohlen) kann wie folgt vorgegangen werden:

* Alle Stellantriebe und Tür-/Fensterkontakte sowie den HM-CC-TC mit Fhem p'''ai'''ren (also ''set CUL hmPairForSec 300'' und an allen Devices den Anlernknopf drücken innerhalb des Zeitfensters von 300 Sekunden).
* Die Stellantriebe und Tür-/Fensterkontakte mit den ''Channels'' (siehe unten) p'''ee'''ren (siehe <nowiki>[http://fhem.de/commandref.html#CUL_HMpeerChan commandref :peerChan]</nowiki>). Hierzu werden die entsprechenden Fhem-Befehle über das Webinterface von Fhem erteilt.

'''Hinweis:'''
* Alle in der FHEM-Eingabezeile eingegebenen ''attr''-, ''define''-Befehle usw. müssen zum Schluss noch per Klick auf den "Save"-Button dauerhaft in der ''fhem.cfg'' gespeichert werden, sonst sind sie nach z.B. einem Systemabsturz verloren.
* Falls in der FHEM-Weboberfläche für ihren HM-CC-TC etwas wie ''X CMDs pending'' steht, sollten Sie ihren HM-CC-TC zur Hand nehmen und für 20 Sekunden auf die OK-Taste drücken. Dadurch werden alle noch ausstehenden Befehle eingelesen.

== Auszug aus der fhem.cfg ==
Die nachfolgenden Einstellungen zum HM-CC-TC werden von FHEM <ins>weitestgehend</ins> automatisch gesetzt. Die Pfadangaben für die Log-Dateien sind system-, die Raumbenennungen benutzerabhängig. Zu ''autoReadReg''und ''expert''siehe unten. Neben dem eigentlichen Basis-Gerät (HM-CC-TC) werden in FHEM automatisch noch 3 weitere "Unter"-Geräte (Channels/Kanäle), nämlich

* ''_Weather''
* ''_Climate''
* ''_WindowRec''

definiert (durch das Anlernen des TC an FHEM; siehe unten), deren Benennung sich (jeweils mit einem vorangestellten Unterstrich "_") am Namen des Basis-Gerätes orientiert.

'''Anmerkung:'''Die in den unten gezeigten ''fhem.cfg''-Auszügen markierten <ins>Peer</ins>-Einträge tauchen erst auf, sobald man die Daten aus dem TC mit ''set HM-CC-TC-Basisname getConfig''bzw. ''autoReadReg''ausgelesen hat.

=== Hauptgerät ===
<nowiki>define <HM-CC-TC>.Heizung CUL_HM 1DA491
attr <HM-CC-TC>.Heizung actCycle 000:10
attr <HM-CC-TC>.Heizung actStatus alive
attr <HM-CC-TC>.Heizung autoReadReg 1
attr <HM-CC-TC>.Heizung devInfo 00FFFF
attr <HM-CC-TC>.Heizung expert 2_full
attr <HM-CC-TC>.Heizung firmware 2.1
attr <HM-CC-TC>.Heizung hmClass receiver
attr <HM-CC-TC>.Heizung model HM-CC-TC
attr <HM-CC-TC>.Heizung room <IhrRaum>
attr <HM-CC-TC>.Heizung serialNr JE********
attr <HM-CC-TC>.Heizung subType thermostat</nowiki>
=== Channel (Kanal) 01 _Weather ===
<nowiki>define <HM-CC-TC>.Heizung_Weather CUL_HM 1DA49101 <<<=== 01 = Kanal 1
attr <HM-CC-TC>.Heizung_Weather model HM-CC-TC
attr <HM-CC-TC>.Heizung_Weather peerIDs
attr <HM-CC-TC>.Heizung_Weather room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_Weather FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_Weather-%Y-%m.log <HM-CC-TC>.Heizung_Weather
attr FileLog_<HM-CC-TC>.Heizung_Weather logtype text
attr FileLog_<HM-CC-TC>.Heizung_Weather room CUL_HM,<IhrRaum></nowiki>
=== Channel (Kanal) 02 _Climate ===
<nowiki>define <HM-CC-TC>.Heizung_Climate CUL_HM 1DA49102 <<<=== 02 = Kanal 2
attr <HM-CC-TC>.Heizung_Climate model HM-CC-TC
attr <HM-CC-TC>.Heizung_Climate peerIDs 1AD52B01,1B7A4C01,1C4CD101,1C48EC01, <<<=== gepeerte HM-CC-VDs
attr <HM-CC-TC>.Heizung_Climate room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_Climate FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_Climate-%Y-%m.log <HM-CC-TC>.Heizung_Climate
attr FileLog_<HM-CC-TC>.Heizung_Climate logtype text
attr FileLog_<HM-CC-TC>.Heizung_Climate room CUL_HM,<IhrRaum></nowiki>
=== Channel (Kanal) 03 _WindowRec ===
<nowiki>define <HM-CC-TC>.Heizung_WindowRec CUL_HM 1DA49103 <<<=== 03 = Kanal 3
attr <HM-CC-TC>.Heizung_WindowRec model HM-CC-TC
attr <HM-CC-TC>.Heizung_WindowRec peerIDs 1CFBB001, <<<=== gepeerte HM-Sec-SCs
attr <HM-CC-TC>.Heizung_WindowRec room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_WindowRec FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_WindowRec-%Y-%m.log <HM-CC-TC>.Heizung_WindowRec
attr FileLog_<HM-CC-TC>.Heizung_WindowRec logtype text
attr FileLog_<HM-CC-TC>.Heizung_WindowRec room CUL_HM,<IhrRaum></nowiki>
== Einstellungen eines HM-CC-TC lesen, anzeigen und sichern ==
=== expert ===
Anfang Februar 2013 wurde eine Änderung bei der Anzeige der so genannten ''Readings'' (Register usw.), also der Einstellungen bzw. Eigenschaften eines HM-Devices, eingeführt. '''Alle''' Werte sieht man nur noch, wenn man am HM-CC-TC das Attribut ''expert'' auf ''2_all'' setzt. Per '''default''' (nicht in ''fhem.cfg'' gesetzt) steht dieser Wert auf ''0_off'' (nur die notwendigsten Readings/Eigenschaften werden angezeigt). Mittelweg ist der Wert ''1_on''.

Mittels

<nowiki>attr <HM-CC-TC-Name> expert 2_full</nowiki>
in der FHEM-Befehlszeile mit anschließendem <Enter> setzt man diesen Level.

Falls man mit '''Temperaturlisten''' arbeitet (siehe unten), dann kann man die komplette Liste im "Channel" (Kanal) ''<HM-CC-TC-Name>__Climate'' einsehen. Auch für diesen Kanal ist evtl. ein setzen des Attributes ''expert 2_full'' angeraten.

<ins>Anmerkung:</ins> Es gibt auch noch sogenannte "hidden datas" (versteckte interne Werte, Register oder Eigenschaften deren Namen mit einem "." beginnen). Diese sieht man nur dann, wenn auch das Attribut ''showInternalValues 1'' gesetzt ist (default: 0 bzw. nicht gesetzt).

=== autoReadReg ===
Mitte Januar 2013 wurde das neue Attribut ''autoReadReg'' eingeführt, welches auf ''0'' voreingestellt ist (kein Eintrag in der ''fhem.cfg''). Das setzen dieses Attributes auf ''1'' bewirkt, dass <ins>beim Neustart von FHEM</ins> die Einstellungen des entsprechenden HM-Gerätes ausgelesen werden. Dies wird bei mehreren ''autoReadReg''s automatisch zeitversetzt vorgenommen, um die Funk-Kommunikation nicht unnötig zu belasten.

Mittels

<nowiki>attr <HM-CC-TC-Name> autoReadReg 1 </nowiki>
in der FHEM-Befehlszeile mit anschließendem <Enter> setzt man diesen Wert.

=== list ===
Um sich alle Eigenschaften/Readings eines Gerätes anzusehen, gibt es den Befehl ''list''.

Mittels

<nowiki>list <HM-CC-TC-Name></nowiki>
und Bestätigung mit <Enter> erhalten Sie die gewünschte Anzeige Ihres TCs <ins>incl.</ins> seiner 3 Channels. Über

<nowiki>list <HM-CC-TC-Name>_<Channel-Name></nowiki>
werden nur die Daten des angegebenen Channels angezeigt.

=== Einstellungen sichern ===
Die Durchführung von ''autoReadReg'' kann durchaus mehrere Minuten dauern. Anschließend besteht die Möglichkeit, diese per

<nowiki>get HM-CC-TC-Basisname saveConfig [/Verzeichnis/mit/Schreibrechten/]<Dateiname></nowiki>
für jedes HM-CC-TC getrennt zu sichern (für eine später notwendige Wiederherstellung). Die Sicherungsdatei wird regulär im ''modpath'' (siehe ''fhem.cfg'') abgelegt. Falls dies nicht zum Erfolg führt (es wird - ohne Fehlermeldungen bei regulärem ''verbose'' und ''loglevel'' - im ''modpath'' keine Datei angelegt), müssen Sie vor dem Dateinamen einen vollständigen Pfad mit Schreibrechten für den Benutzer, unter dem FHEM läuft, angeben.

In der <ins>Log-Datei</ins> von FHEM erscheinen danach Meldungen folgender Art

<nowiki><Datum>_<Zeit> 2: CUL_HM set <HM-CC-TC-Name> statusRequest rxt:12
<Datum>_<Zeit> 2: CUL_HM set <HM-CC-TC-Name> getConfig rxt:12</nowiki>
Hierbei kann es (im <ins>Event monitor</ins> von FHEM) zu folgenden Fehlermeldungen kommen

<nowiki><Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:RegisterRead
<Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:PeerList
<Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:StatusReq</nowiki>
Diese Meldungen können auch mehrfach pro Gerät auftreten. Dann hat das Auslesen der Einstellungen nicht geklappt und sollte nochmals durchgeführt werden. Dafür muss man FHEM aber nicht neu starten, sondern das HM-Device per

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
in der Befehlszeile von FHEM und anschließendem <Enter> (nicht "save") darauf einstellen.

Die Channels (z.B. <HM-CC-TC-Name>_Climate, _Weather, _WindowRec) eines HM-Gerätes brauchen nicht (können aber bei Bedarf) separat ausgelesen bzw. gesichert zu werden, da sie Bestandteil der Basisabfrage sind.

== Funkprobleme auffangen ==
Der wohl am häufigsten an den HM-CC-TC gesendete Befehl ist "set desired-temp", mit dem die Wunschtemperatur neu gesetzt wird.
Funktioniert dieser Befehl jedoch nicht zuverlässig, wird die Wohnung ggf. zu lange oder nicht rechtzeitig beheizt.
Der folgende Mechanismus soll die Sicherheit erhöhen, indem die Antworten des HM-CC-TC geprüft werden und ggf. das Funktelegramm erneut gesendet wird.

Um den Sollwert zum erneuten Senden des Funktelegramms verfügbar zu haben, wird ein dummy definiert:

<nowiki>define HM_TC_Solltemperatur dummy</nowiki>
Wann immer die Solltemperatur geändert wird, setzt man die neue desired-temp nicht nur auf dem HM-TC-CC (hier HM_TC genannt), sondern auch auf dem dummy. Der Befehl (z.B. in der [[Zuhause-Status|Routine zum HomeStatus]]) sieht dann so aus:

<nowiki>set HM_TC desired-temp 21;set HM_TC_Solltemperatur 21</nowiki>
Falls das ausgehende Funktelegramm verlorengeht, fehlt die Antwort "command accepted". Dies kann mit einem watchdog aufgefangen werden, der dann den Befehl an den HM-CC-TC erneut sendet:

<nowiki>define w_HM_TC watchdog HM_TC:set_desired-temp.* 00:02:30 HM_TC_Climate:CommandAccepted:.yes { \
Log 1, ">>>>>>>>> w_HM_TC desired temp - missing response.";\
fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\
}</nowiki>
Falls ein Fehler bei der Funkkommunikation auftritt, erhält man die Antwort "missing ACK" oder "NACK". Auch in diesem Fall soll das Telegramm zum Ändern der Wunschtemperatur erneut an den HM-CC-TC gesendet werden:

<nowiki>define n_HM_TC_err notify HM_TC:(MISSING.ACK.*|.*NACK.*) {\
Log 1, ">>>>>>>>> n_HM_TC desired temp - missing ack/nack.\n";\
fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\
}</nowiki>
Mit diesen beiden Helfern ist die Funkkommunikation zum HM-CC-TC sehr zuverlässig.

== Plots / Grafiken ==
=== Problem ===
Durch ''autocreate'' wird zwar ein Log angelegt, aber kein Plot (Grafische Auswertung). Dem kann man aber abhelfen (siehe unten).

=== Plots erzeugen ===
''PGM2'' ist die Standardansicht des Fhem-Web-Interfaces. Um hier Plots/Grafiken zu erzeugen einfach unter dem ''Filelog'' des Thermostaten das ''attr logtype'' auf ''temp4hum6:Plot,text'' setzen und es wird ein Plot-Link neben dem Text-Link angezeigt. Nun können Sie auf diesen Plot-Link klicken und ...

=== alternative Plots ===
Mit dem fht.gplot funktioniert die Anzeige der Ventilstellung (actuator) nicht.

Mit folgendem angepassten .gplot File wird die gemessene Temperatur und Ventilstellung angezeigt.

<nowiki>############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define <filelogname> FileLog /var/log/fhem/actuator_name-%Y.log <actuator_name>:(measured-temp|actuator).*

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 ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics

set y2label "Temperatur in C"
set ylabel "Ventil (%)"

#FileLog 4:measured:10:
#FileLog 4:actuator:50:

plot \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Temperatur in C' with lines,\
"< egrep 'actuator' <IN>"\
using 1:4 axes x1y1 title 'Ventil (%)' with lines\</nowiki>
=== Alles-drin-Plot ===
dazu nimmt man folgendes .gplot. Man/Fra beachte, dass hierfür alle Parameter nach der define-Anweisung in das Logfile geschrieben werden.

<nowiki>############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define <filelogname> FileLog /var/log/fhem/HM_CC_TC-%Y.log <HM_CC_TC-name>
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 ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics
set y2label "Temperature in C"
set ylabel "Actuator (%)"
#FileLog 4:temperature:0:
#FileLog 4:desired:0:
#FileLog 4:humidity:0:
#FileLog 4:actuator:0:int
plot \
"< awk '/temperature/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Measured temperature' with lines lw 2,\
"< awk '/desired/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Desired temperature' with steps,\
"< awk '/humidity/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Humidity (%)' with lines,\
"< awk '/actuator/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Actuator (%)' with lines\</nowiki>

== Steuerungsmodi ==
Das Wandthermostat hat 4 verschiedene Steuerungsmöglichkeiten:

* Auto (automatisch)
* Cent (Zentrale)
* Manu (manuell)
* Prog / Koffer-Symbol (Urlaubs/Party-Modus, wird hier nicht näher erörtert)

Der Steuerungsmodus wird über wiederholtes Drücken der linken Taste des HM-CC-TC ausgewählt bzw. gewechselt.

'''Hinweis:''' Durch das P'''ai'''ren des HM-CC-TC <ins>und</ins> der Stellantrieb sowie Tür-/Fensterkontakte an Fhem verlieren Sie '''nicht''' die Steuerungsmöglichkeiten. Im Gegenteil: Nur wenn auch die VDs usw. mit Fhem gep'''ai'''rt sind, haben Sie die Möglichkeit, auch diese zu überwachen. Die Steuerung '''können''' Sie dennoch allein dem HM-CC-TC überlassen.

=== Auto-Modus ===
Im Modus '''Auto''' wird die Temperaturregelung über die im TC hinterlegten Temperaturlisten vorgenommen. Das Thermostat arbeitet also selbständig, somit unabhängig von einer Zentrale / FHEM. Nur in diesem Modus werden die evtl. per FHEM an das TC übermittelten "templist" abgearbeitet. Über das Senden von angepassten Temperatur-Listen kann eine indirekte Steuerung per FHEM erfolgen. '''Jederzeit''' kann zudem die Raumtemperatur über das Drehrad des Wandthermostaten oder die FHEM-Web-Oberfläche verändert werden. Diese ''Übersteuerung'' der Temperaturliste gilt bis zur nächsten Temperaturänderung nach der vorgenannten Liste.

=== Cent-Modus ===
Im Modus '''Cent''' steuert eine HomeMatic-Zentrale (CCU) oder eben ein FHEM-Server mit z.B. [[HMLAN Konfigurator]] zu den in der FHEM-Config hinterlegten Zeiten und mit den dort festgelegten Temperaturen. Fällt also die HM-Zentrale aus, erfolgt keine Steuerung der Thermostaten bzw. Heizungsventile mehr.

<ins>Anmerkung</ins>: Der Modus ''cent'' erscheint nur dann im Display des HM-CC-TC, wenn er an eine Zentrale bzw. das [[CUL]] angelernt (gepairt) wurde.

=== Manu-Modus ===
Der Modus '''Manu''' übersteuert die im TC hinterlegten Temperaturlisten und die evtl. von der HM-Zentrale / dem FHEM <ins>vor Umstellung auf ''Manu''</ins> gesendeten Einstellungen. Es wird also bis zur nächsten Modusumstellung bzw. manuellen Temperaturverstellung der per Einstellrad gesetzte Temperaturwert gefahren.

Aber auch in diesem Modus kann man die ''desired-temperature'' per FHEM verstellen. Der dadurch eingestellte Wert gilt ab sofort als der neue im ''Manu-Modus'' zu haltende Wert.

=== Auslesen des eingestellten Steuerungsmodus ===
Der eingestellte Steuerungsmodus erscheint normalerweise in den ''Readings'' des HM-CC-TC unter ''controlMode''. Zusätzlich haben Sie die Möglichkeit, diesen Modus auch in der FHEM-Weboberfläche ''everything'' => Abschnitt ''thermostat'' zu sehen, '''wenn''' Sie für den HM-CC-TC das folgende Attribut setzen:

<nowiki>attr <HM-CC-TC-Name> stateFormat T:measured-temp, H:humidity, VD:actuator, controlMode</nowiki>
Erscheint dort selbst nach einem

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
kein "Reading" ''controlMode'' oder keine Angabe des aktuell eingestellten Modus bzw. nur das Wort "controlMode", dann setzen Sie ihren HM-CC-TC von Hand in einen anderen Kontrollmodus und machen einen Browser-Refresh. Klappt dies nicht, geben Sie bitte erneut den Befehl

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
ein. Halten Sie anschließend die Taste <OK> am HM-CC-TC für 5 Sekunden gedrückt (oder warten ca. 5 Minuten) und machen in der FHEM-Weboberfläche einen Browser-Refresh (FF => <F5>). Jetzt sollte der manuell eingestellte Kontrollmodus erscheinen (ggfls. muss dieser Vorgang einmal wiederholt werden). Jetzt können Sie wieder den gewünschten Modus einstellen, erneut ein

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
absetzen und nach erneutem Drücken der <OK>-Taste für 5 Sekunden mit nachfolgendem Browser-Refresh sollte alles richtig angezeigt werden.

Dies setzt natürlich voraus, dass der HM-CC-TC richtig gepairt ist.

== Temperaturlisten ==

'''Achtung:''' Die Listen mussten bis vor kurzem noch auf das Device HM-CC-TC, nunmehr aber auf dessen Channel HM-CC-TC_Climate gesetzt werden. Dadurch ändert sich die Benennung des Gerätes (wird in den u.a. Beispielen berücksichtigt).

Eine Temperaturliste für die Steuerung der Raumtemperatur im o.a. '''Auto-Modus''' kann man wie folgt erzeugen:

* Man legt sich eine eigene ''99_MyUtils.pm'' an (siehe [[99_myUtils anlegen]]). Dies ist wichtig, da es bei FHEM-Updates durchaus sein kann, dass die vorhandene ''99_Utils.pm'' erneuert und damit überschrieben wird und dann sind all ihre eigenen Subroutinen weg.
* Dort trägt man für '''jedes''' HM-CC-TC, dessen Werte man individuell einstellen will, eine '''eigene''' Subroutine ein, die z.B. wie folgt aussehen kann:

<pre>
######################################################
# Temperatur-Liste für das Wohnzimmer
# setzen per Aufruf von "{SetTempList_EG_WZ_Heizung}"
######################################################
sub
SetTempList_EG_WZ_Heizung()
{
{ fhem ("set EG.WZ.Heizung_Climate tempListMon 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListTue 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListWed 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListThu 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListFri 05:30 19.0 07:00 21.0 15:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListSat 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListSun 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.5")};
}
# End SetTempList_EG_WZ_Heizung
</pre>

* die Änderungen in der ''99_MyUtils.pm'' müssen jetzt abgespeichert werden
* in der FHEM-Befehlszeile ist ein ''reload 99_MyUtils.pm'' mit <Enter> / <Return> abzusetzen (erst dadurch werden die Eintragungen / Änderungen aktiviert)
* nun kann man in der Kommandozeile von FHEM den Befehl ''{SetTempList_EG_WZ_Heizung}'' eingeben und mit <Return> bzw. <Enter> bestätigen

Im FHEM-Logfile (das man vorher in einem weiteren Browser-Tab geöffnet hat, Refresh (F5) nicht vergessen) taucht danach folgendes auf:

<pre>
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListMon 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListTue 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListWed 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListThu 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListFri 05:30 17.0 07:00 21.0 15:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListSat 07:00 17.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListSun 07:00 17.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0
</pre>

'''Zur Erläuterung:'''

Mittels

<pre>
set EG.WZ.Heizung_Climate tempListMon 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
</pre>

setzt man den HM-CC-TC-Channel mit dem Namen ''EG.WZ.Heizung_Climate'' für jeden folgenden Montag

von 00:00 '''bis''' 05:30 Uhr auf 17,0 °C 
von 05:31 '''bis''' 07:00 Uhr auf 21,0 °C 
von 07:31 '''bis''' 16:00 Uhr auf 19,0 °C 
...

und so weiter. Dabei kann bei der Temperatur als Nachkommawert entweder eine 0 oder eine 5 stehen, ein Wert von z.B. 20,1 ist nicht erlaubt.

'''Achtung:''' Häufigste Fehlerquelle ist das Verstehen der Reihen- bzw. Abfolge der Zeit- und Temperaturwerte. Deshalb ein weiterer Beschreibungsversuch mit anderen Worten, der hoffentlich zum besseren Verständnis beiträgt:

Die Definition <ins>beginnt</ins> von selbst jeweils bei 00:00 Uhr eines Tages. Die danach angegebene Uhrzeit (im letzten Beispiel ''tempListMon'': 05:30 Uhr) beschreibt also den Zeitraum von 00:00 Uhr '''bis''' 05:30 Uhr. Der <ins>danach</ins> folgende Wert von 17.0 definiert also den in der Zeit von 00:00 Uhr '''bis''' 05:30 Uhr geltenden Wunschtemperaturwert von 17,0 °C. Die im vorgenannten Beispiel auf die Wertangabe ''17.0'' folgende Uhrzeit von ''07:00'' legt nun den Zeitraum von 05:30 Uhr '''bis''' 07:00 Uhr für den dahinter stehenden Temperaturwert von 21.0 fest. Die Abfolge kann dem Einen oder der Anderen unnatürlich vorkommen, aber es ist eine so von eQ3 festgelegte Notationsweise.

'''Beachten Sie bitte''', dass am Schluss der Liste <ins>immer</ins> eine Einstellung für 24:00 notiert sein '''muss'''. Ansonsten quittiert FHEM das Setzen der Liste mit einem solchen Eintrag im Logfile:

<pre>
Last time spec must be 24:00
</pre>

Im FHEM-Logfile-Browser-Tab sollten nach einigen Minuten folgende mehrfach wiederholten Einträge auftauchen:

<pre>
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate CommandAccepted: yes
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate CommandAccepted: yes
...
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate CommandAccepted: yes
</pre>

Wichtig ist ein nachfolgendes "ACK". Steht dort "MISSING ACK", dann wurde der Empfang der Werte vom HM-CC-TC nicht bestätigt und man sollte die TempList noch einmal schicken. Kommt auch nach mehreren Sendeversuchen kein "ACK" sollten Sie in den ''Readings''des Devices die ''TempList''überprüfen (siehe unten), denn es kann sein, dass diese Antwort schlicht nicht empfangen werden konnte, weil der Empfänger gerade anderweitig beschäftigt war, die Einstellungen aber dennoch übernommen wurden. Wird jedoch ein "NACK" vom HM-CC-TC gesendet, dann wurde die Temperaturliste explizit nicht akzeptiert. Kontrollieren Sie in diesem Fall die Korrektheit der Temperaturliste.

Welche Werte '''aktuell eingestellt'''sind, sieht man in den "Readings" des jeweiligen Devices; im obigen Fall also z.B. im linken Menü von FHEM auf den default-Eintrag ''Everything''klicken und dann auf den Eintrag mit dem Namen ''EG.WZ.Heizung''.

== Temperaturlisten (neu) ==

Seit Mitte Oktober 2013 kann man die Temperaturlisten "ressourcenschonender" an einen HM-CC-TC übertragen. Bisher wurde für jeden Tag ein Befehl abgeschickt (siehe obiges Beispiel). Nun kann man, wie beim [[HM-CC-RT-DN Funk-Heizkörperthermostat#Temperaturlisten setzen|HM-CC-RT-DN] (dem Nachfolger des HM-CC-TC), auch alles in ein einziges "Funktelegramm" packen. Dazu das folgende Beispiel (achten Sie bitte auf die Schlüsselwörter "prep" und "exec"):

######################################################
# Temperatur-Liste für Kinderzimmer
# setzen per Aufruf von "{SetTempList_Kind_Heizung}"
######################################################
sub
SetTempList_Kind_Heizung()
{
{ fhem ("set DG.Kind.Heizung_Climate tempListMon prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListTue prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListWed prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListThu prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListFri prep 05:30 19.0 07:00 20.5 15:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListSat prep 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListSun exec 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0")};
}
# End SetTempList_Kind_Heizung

Zum Verständnis: Mittels ''prep'' werden die Werte in einen "Puffer" gepackt und sobald ein "exec" auftaucht, wird er Puffer mit dem Nachfolgenden gefüllt und anschließend '''in einem Rutsch''' an den HM-CC-TC geschickt. Dies vermeidet/minimiert Übertragungsprobleme.

== Batteriealarme des HM-CC-VD in Verbindung mit HM-CC-TC ==
1. bei U-Bat. < 2,4 V erscheint im Display des VD und des TC das Batteriesymbol mit '''battery: low''' in den Readings und Events!

2. bei U-Bat. < 2,3 V erscheint im Display des VD zusätzlich '''F4''' mit '''battery: critical''' in den Readings und Events!

Es wird dringend geraten, die Batterien bei battery: low zu tauschen!

== Log-Auszug ==
HM-CC-TC sendet alle 2 Minuten folgenden Statusbericht:

<nowiki>Datum-Zeit <Device Name> T: 17.3 H: 66 
Datum-Zeit <Device Name> measured-temp: 17.3 
Datum-Zeit <Device Name> temperature: 17.3 
Datum-Zeit <Device Name> humidity: 66 
Datum-Zeit <Device Name> actuator: 96 % </nowiki>
Bei Status-Änderungen sendet HM-CC-TC auch entsprechende Meldungen, z.b.:

<nowiki>Datum-Zeit <Device Name> desired-temp: 15.5 </nowiki>

= Probleme =

== Verstellen der Solltemperatur am HM-CC-TC per Drehrad ==

'''Symptom:''' Beim Verstellen der Solltemperatur per seitlichem Drehrad wurde die aktuelle Solltemperatur - '''egal ob''' man hoch oder runter drehte - immer nur in 0,5 °C Schritten '''runter''' gestellt, bis schließlich die Mindesttemperatur von 6,0 °C erreicht war. Weitere Änderungen waren nicht möglich

'''Abhilfe:''' Letztlich half nur das kurzzeitige Entfernen einer Batterie. Das danach für einige Zeit erscheinende Batteriesymbol zeigte den kleinstmöglichen guten Zustand an, in FHEM wurde das ''Reading'' des Batteriezustandes mit ''ok'' ausgegeben (wie in den Logs aber vorher auch). '''Letztlich half aber nur''' das Einsetzen neuer Batterien, denn die o.a. Störung trat nach ca. 2 Stunden erneut auf. Die "alten" Batterien (die, die dem HM-CC-TC ab Werk beilagen) hatten somit eine Nutzungsdauer von knapp 11 Monaten, waren aber auch in einem HM-CC-TC, der mit 4 Stck. HM-Sec-SC (mussten sehr oft "Meldung machen") und 4 Stck. HM-CC-VD gepeert war. ''Ohne Last'' zeigten die beiden alten AA-Batterien eine Spannung von jeweils 1,29 V an.

'''Hinweis:''' Die unter ''Abhilfe'' beschriebene Lösung war leider nur von kurzer Dauer. Bereits kurz danach zeigte der HM-CC-TC die gleichen Ausfallerscheinungen. Bei ELV gibt es das Bauteil für das Drehrad (Inkrementalgeber) als [http://www.elv.de/inkrementalgeber-fuer-fs20-str-fht-8-und-homematic-hm-cc-tc.html Ersatzteil]. Sobald dieses geliefert und ein Reparaturversuch unternommen wurde, wird an dieser Stelle weiter berichtet.

= Firmware =
Aktuelle Firmware-Version: 2.1

= Links =
Anleitung [http://www.elv-downloads.de/service/manuals/76787_76175_HM_Wandthermostat_UM.pdf PDF]

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

HM-CC-TC Funk-Wandthermostat

2014-07-05T16:30:01Z

Rohan: /* expert */

'''HM-CC-TC Funk-Wandthermostat'''

Programmierbarer Raumthermostat, der bis zu 4 [[HM-CC-VD Funk-Stellantrieb]] steuern kann.

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt).'''

Nachfolgeprodukt ist der [[HM-CC-RT-DN]] bzw. (ab März 2014) [[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]].

= Features =
* Am Raumthermostat programmierbare Tages- und Nachttemperatur.
* Pro Wochentag können bis zu 24 Schaltpunkte definiert werden.
* Anbindung von <ins>jeweils</ins> '''maximal''' 4 Tür- bzw. Fensterkontakten ([[HM-Sec-RHS]]) zur Absenkung der Temperatur auf einen eigens eingestellten Temperaturwert (ab Werk: 12°C) bei offenem Fenster bzw. offener Tür.
* Anzeige der Temperatur und Luftfeuchtigkeit im Raum und Hintergrundbeleuchtung des Displays.

Alle 120 bis 184 Sekunden überträgt der Wandthermostat vorhandene Befehle zu den Stellantrieben. Jeder empfangene Befehl wird vom Stellantrieb bestätigt und dann ausgeführt. Täglich gegen Mitternacht synchronisiert ein HM-CC-TC seine Uhrzeit mit der HomeMatic-Zentrale (CCU, HMLAN).

= Hinweise zum Betrieb mit FHEM =
Vor dem Einsatz mit einer Zentrale sind erst alle Stellantriebe und Tür-/Fensterkontakte mit dem HM-CC-TC zu verbinden (P'''ee'''r).
Damit das ganze dann in FHEM auftaucht, muss der TC noch mit dem [[HMLAN Konfigurator]] gep'''ai'''rt werden.

Mit

<nowiki>set CUL hmPairForSec 300</nowiki>
setzt man das CUL / den HMLAN-Konfigurator für 5 Minuten in den Anlernmodus. Danach am Thermostaten 5 Sekunden lang die OK-Taste drücken und es wird eine Zeit von 20 auf 0 Sekunden gezählt:

* Klappt das Anlernen in diesen 20 Sekunden, wird der Countdown sofort beendet, anschließend für ca. 2-3 Sekunden "OK" angezeigt und der Thermostat ist in FHEM eingebunden.
* Gelingt das Anlernen nicht in den 20 Sekunden, erscheint nach Erreichen der "0" noch für 2 bis 3 Sekunden ein "NOK" ('''N'''ot '''OK''') im Display des TCs.

'''Alternativ'''(und so vom Entwickler des Fhem-HomeMatic-Moduls empfohlen) kann wie folgt vorgegangen werden:

* Alle Stellantriebe und Tür-/Fensterkontakte sowie den HM-CC-TC mit Fhem p'''ai'''ren (also ''set CUL hmPairForSec 300'' und an allen Devices den Anlernknopf drücken innerhalb des Zeitfensters von 300 Sekunden).
* Die Stellantriebe und Tür-/Fensterkontakte mit den ''Channels'' (siehe unten) p'''ee'''ren (siehe <nowiki>[http://fhem.de/commandref.html#CUL_HMpeerChan commandref :peerChan]</nowiki>). Hierzu werden die entsprechenden Fhem-Befehle über das Webinterface von Fhem erteilt.

'''Hinweis:'''
* Alle in der FHEM-Eingabezeile eingegebenen ''attr''-, ''define''-Befehle usw. müssen zum Schluss noch per Klick auf den "Save"-Button dauerhaft in der ''fhem.cfg'' gespeichert werden, sonst sind sie nach z.B. einem Systemabsturz verloren.
* Falls in der FHEM-Weboberfläche für ihren HM-CC-TC etwas wie ''X CMDs pending'' steht, sollten Sie ihren HM-CC-TC zur Hand nehmen und für 20 Sekunden auf die OK-Taste drücken. Dadurch werden alle noch ausstehenden Befehle eingelesen.

== Auszug aus der fhem.cfg ==
Die nachfolgenden Einstellungen zum HM-CC-TC werden von FHEM <ins>weitestgehend</ins> automatisch gesetzt. Die Pfadangaben für die Log-Dateien sind system-, die Raumbenennungen benutzerabhängig. Zu ''autoReadReg''und ''expert''siehe unten. Neben dem eigentlichen Basis-Gerät (HM-CC-TC) werden in FHEM automatisch noch 3 weitere "Unter"-Geräte (Channels/Kanäle), nämlich

* ''_Weather''
* ''_Climate''
* ''_WindowRec''

definiert (durch das Anlernen des TC an FHEM; siehe unten), deren Benennung sich (jeweils mit einem vorangestellten Unterstrich "_") am Namen des Basis-Gerätes orientiert.

'''Anmerkung:'''Die in den unten gezeigten ''fhem.cfg''-Auszügen markierten <ins>Peer</ins>-Einträge tauchen erst auf, sobald man die Daten aus dem TC mit ''set HM-CC-TC-Basisname getConfig''bzw. ''autoReadReg''ausgelesen hat.

=== Hauptgerät ===
<nowiki>define <HM-CC-TC>.Heizung CUL_HM 1DA491
attr <HM-CC-TC>.Heizung actCycle 000:10
attr <HM-CC-TC>.Heizung actStatus alive
attr <HM-CC-TC>.Heizung autoReadReg 1
attr <HM-CC-TC>.Heizung devInfo 00FFFF
attr <HM-CC-TC>.Heizung expert 2_full
attr <HM-CC-TC>.Heizung firmware 2.1
attr <HM-CC-TC>.Heizung hmClass receiver
attr <HM-CC-TC>.Heizung model HM-CC-TC
attr <HM-CC-TC>.Heizung room <IhrRaum>
attr <HM-CC-TC>.Heizung serialNr JE********
attr <HM-CC-TC>.Heizung subType thermostat</nowiki>
=== Channel (Kanal) 01 _Weather ===
<nowiki>define <HM-CC-TC>.Heizung_Weather CUL_HM 1DA49101 <<<=== 01 = Kanal 1
attr <HM-CC-TC>.Heizung_Weather model HM-CC-TC
attr <HM-CC-TC>.Heizung_Weather peerIDs
attr <HM-CC-TC>.Heizung_Weather room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_Weather FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_Weather-%Y-%m.log <HM-CC-TC>.Heizung_Weather
attr FileLog_<HM-CC-TC>.Heizung_Weather logtype text
attr FileLog_<HM-CC-TC>.Heizung_Weather room CUL_HM,<IhrRaum></nowiki>
=== Channel (Kanal) 02 _Climate ===
<nowiki>define <HM-CC-TC>.Heizung_Climate CUL_HM 1DA49102 <<<=== 02 = Kanal 2
attr <HM-CC-TC>.Heizung_Climate model HM-CC-TC
attr <HM-CC-TC>.Heizung_Climate peerIDs 1AD52B01,1B7A4C01,1C4CD101,1C48EC01, <<<=== gepeerte HM-CC-VDs
attr <HM-CC-TC>.Heizung_Climate room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_Climate FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_Climate-%Y-%m.log <HM-CC-TC>.Heizung_Climate
attr FileLog_<HM-CC-TC>.Heizung_Climate logtype text
attr FileLog_<HM-CC-TC>.Heizung_Climate room CUL_HM,<IhrRaum></nowiki>
=== Channel (Kanal) 03 _WindowRec ===
<nowiki>define <HM-CC-TC>.Heizung_WindowRec CUL_HM 1DA49103 <<<=== 03 = Kanal 3
attr <HM-CC-TC>.Heizung_WindowRec model HM-CC-TC
attr <HM-CC-TC>.Heizung_WindowRec peerIDs 1CFBB001, <<<=== gepeerte HM-Sec-SCs
attr <HM-CC-TC>.Heizung_WindowRec room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_WindowRec FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_WindowRec-%Y-%m.log <HM-CC-TC>.Heizung_WindowRec
attr FileLog_<HM-CC-TC>.Heizung_WindowRec logtype text
attr FileLog_<HM-CC-TC>.Heizung_WindowRec room CUL_HM,<IhrRaum></nowiki>
== Einstellungen eines HM-CC-TC lesen, anzeigen und sichern ==
=== expert ===
Anfang Februar 2013 wurde eine Änderung bei der Anzeige der so genannten ''Readings'' (Register usw.), also der Einstellungen bzw. Eigenschaften eines HM-Devices, eingeführt. '''Alle''' Werte sieht man nur noch, wenn man am HM-CC-TC das Attribut ''expert'' auf ''2_all'' setzt. Per '''default''' (nicht in ''fhem.cfg'' gesetzt) steht dieser Wert auf ''0_off'' (nur die notwendigsten Readings/Eigenschaften werden angezeigt). Mittelweg ist der Wert ''1_on''.

Mittels

<nowiki>attr <HM-CC-TC-Name> expert 2_full</nowiki>
in der FHEM-Befehlszeile mit anschließendem <Enter> setzt man diesen Level.

Falls man mit '''Temperaturlisten''' arbeitet (siehe unten), dann kann man die komplette Liste im "Channel" (Kanal) ''<HM-CC-TC-Name>__Climate''einsehen. Auch für diesen Kanal ist evtl. ein setzen des Attributes ''expert 2_full'' angeraten.

<ins>Anmerkung:</ins> Es gibt auch noch sogenannte "hidden datas" (versteckte interne Werte, Register oder Eigenschaften deren Namen mit einem "." beginnen). Diese sieht man nur dann, wenn auch das Attribut ''showInternalValues 1'' gesetzt ist (default: 0 bzw. nicht gesetzt).

=== autoReadReg ===
Mitte Januar 2013 wurde das neue Attribut ''autoReadReg'' eingeführt, welches auf ''0'' voreingestellt ist (kein Eintrag in der ''fhem.cfg''). Das setzen dieses Attributes auf ''1'' bewirkt, dass <ins>beim Neustart von FHEM</ins> die Einstellungen des entsprechenden HM-Gerätes ausgelesen werden. Dies wird bei mehreren ''autoReadReg''s automatisch zeitversetzt vorgenommen, um die Funk-Kommunikation nicht unnötig zu belasten.

Mittels

<nowiki>attr <HM-CC-TC-Name> autoReadReg 1 </nowiki>
in der FHEM-Befehlszeile mit anschließendem <Enter> setzt man diesen Wert.

=== list ===
Um sich alle Eigenschaften/Readings eines Gerätes anzusehen, gibt es den Befehl ''list''.

Mittels

<nowiki>list <HM-CC-TC-Name></nowiki>
und Bestätigung mit <Enter> erhalten Sie die gewünschte Anzeige Ihres TCs <ins>incl.</ins> seiner 3 Channels. Über

<nowiki>list <HM-CC-TC-Name>_<Channel-Name></nowiki>
werden nur die Daten des angegebenen Channels angezeigt.

=== Einstellungen sichern ===
Die Durchführung von ''autoReadReg'' kann durchaus mehrere Minuten dauern. Anschließend besteht die Möglichkeit, diese per

<nowiki>get HM-CC-TC-Basisname saveConfig [/Verzeichnis/mit/Schreibrechten/]<Dateiname></nowiki>
für jedes HM-CC-TC getrennt zu sichern (für eine später notwendige Wiederherstellung). Die Sicherungsdatei wird regulär im ''modpath'' (siehe ''fhem.cfg'') abgelegt. Falls dies nicht zum Erfolg führt (es wird - ohne Fehlermeldungen bei regulärem ''verbose'' und ''loglevel'' - im ''modpath'' keine Datei angelegt), müssen Sie vor dem Dateinamen einen vollständigen Pfad mit Schreibrechten für den Benutzer, unter dem FHEM läuft, angeben.

In der <ins>Log-Datei</ins> von FHEM erscheinen danach Meldungen folgender Art

<nowiki><Datum>_<Zeit> 2: CUL_HM set <HM-CC-TC-Name> statusRequest rxt:12
<Datum>_<Zeit> 2: CUL_HM set <HM-CC-TC-Name> getConfig rxt:12</nowiki>
Hierbei kann es (im <ins>Event monitor</ins> von FHEM) zu folgenden Fehlermeldungen kommen

<nowiki><Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:RegisterRead
<Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:PeerList
<Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:StatusReq</nowiki>
Diese Meldungen können auch mehrfach pro Gerät auftreten. Dann hat das Auslesen der Einstellungen nicht geklappt und sollte nochmals durchgeführt werden. Dafür muss man FHEM aber nicht neu starten, sondern das HM-Device per

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
in der Befehlszeile von FHEM und anschließendem <Enter> (nicht "save") darauf einstellen.

Die Channels (z.B. <HM-CC-TC-Name>_Climate, _Weather, _WindowRec) eines HM-Gerätes brauchen nicht (können aber bei Bedarf) separat ausgelesen bzw. gesichert zu werden, da sie Bestandteil der Basisabfrage sind.

== Funkprobleme auffangen ==
Der wohl am häufigsten an den HM-CC-TC gesendete Befehl ist "set desired-temp", mit dem die Wunschtemperatur neu gesetzt wird.
Funktioniert dieser Befehl jedoch nicht zuverlässig, wird die Wohnung ggf. zu lange oder nicht rechtzeitig beheizt.
Der folgende Mechanismus soll die Sicherheit erhöhen, indem die Antworten des HM-CC-TC geprüft werden und ggf. das Funktelegramm erneut gesendet wird.

Um den Sollwert zum erneuten Senden des Funktelegramms verfügbar zu haben, wird ein dummy definiert:

<nowiki>define HM_TC_Solltemperatur dummy</nowiki>
Wann immer die Solltemperatur geändert wird, setzt man die neue desired-temp nicht nur auf dem HM-TC-CC (hier HM_TC genannt), sondern auch auf dem dummy. Der Befehl (z.B. in der [[Zuhause-Status|Routine zum HomeStatus]]) sieht dann so aus:

<nowiki>set HM_TC desired-temp 21;set HM_TC_Solltemperatur 21</nowiki>
Falls das ausgehende Funktelegramm verlorengeht, fehlt die Antwort "command accepted". Dies kann mit einem watchdog aufgefangen werden, der dann den Befehl an den HM-CC-TC erneut sendet:

<nowiki>define w_HM_TC watchdog HM_TC:set_desired-temp.* 00:02:30 HM_TC_Climate:CommandAccepted:.yes { \
Log 1, ">>>>>>>>> w_HM_TC desired temp - missing response.";\
fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\
}</nowiki>
Falls ein Fehler bei der Funkkommunikation auftritt, erhält man die Antwort "missing ACK" oder "NACK". Auch in diesem Fall soll das Telegramm zum Ändern der Wunschtemperatur erneut an den HM-CC-TC gesendet werden:

<nowiki>define n_HM_TC_err notify HM_TC:(MISSING.ACK.*|.*NACK.*) {\
Log 1, ">>>>>>>>> n_HM_TC desired temp - missing ack/nack.\n";\
fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\
}</nowiki>
Mit diesen beiden Helfern ist die Funkkommunikation zum HM-CC-TC sehr zuverlässig.

== Plots / Grafiken ==
=== Problem ===
Durch ''autocreate'' wird zwar ein Log angelegt, aber kein Plot (Grafische Auswertung). Dem kann man aber abhelfen (siehe unten).

=== Plots erzeugen ===
''PGM2'' ist die Standardansicht des Fhem-Web-Interfaces. Um hier Plots/Grafiken zu erzeugen einfach unter dem ''Filelog'' des Thermostaten das ''attr logtype'' auf ''temp4hum6:Plot,text'' setzen und es wird ein Plot-Link neben dem Text-Link angezeigt. Nun können Sie auf diesen Plot-Link klicken und ...

=== alternative Plots ===
Mit dem fht.gplot funktioniert die Anzeige der Ventilstellung (actuator) nicht.

Mit folgendem angepassten .gplot File wird die gemessene Temperatur und Ventilstellung angezeigt.

<nowiki>############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define <filelogname> FileLog /var/log/fhem/actuator_name-%Y.log <actuator_name>:(measured-temp|actuator).*

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 ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics

set y2label "Temperatur in C"
set ylabel "Ventil (%)"

#FileLog 4:measured:10:
#FileLog 4:actuator:50:

plot \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Temperatur in C' with lines,\
"< egrep 'actuator' <IN>"\
using 1:4 axes x1y1 title 'Ventil (%)' with lines\</nowiki>
=== Alles-drin-Plot ===
dazu nimmt man folgendes .gplot. Man/Fra beachte, dass hierfür alle Parameter nach der define-Anweisung in das Logfile geschrieben werden.

<nowiki>############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define <filelogname> FileLog /var/log/fhem/HM_CC_TC-%Y.log <HM_CC_TC-name>
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 ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics
set y2label "Temperature in C"
set ylabel "Actuator (%)"
#FileLog 4:temperature:0:
#FileLog 4:desired:0:
#FileLog 4:humidity:0:
#FileLog 4:actuator:0:int
plot \
"< awk '/temperature/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Measured temperature' with lines lw 2,\
"< awk '/desired/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Desired temperature' with steps,\
"< awk '/humidity/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Humidity (%)' with lines,\
"< awk '/actuator/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Actuator (%)' with lines\</nowiki>

== Steuerungsmodi ==
Das Wandthermostat hat 4 verschiedene Steuerungsmöglichkeiten:

* Auto (automatisch)
* Cent (Zentrale)
* Manu (manuell)
* Prog / Koffer-Symbol (Urlaubs/Party-Modus, wird hier nicht näher erörtert)

Der Steuerungsmodus wird über wiederholtes Drücken der linken Taste des HM-CC-TC ausgewählt bzw. gewechselt.

'''Hinweis:''' Durch das P'''ai'''ren des HM-CC-TC <ins>und</ins> der Stellantrieb sowie Tür-/Fensterkontakte an Fhem verlieren Sie '''nicht''' die Steuerungsmöglichkeiten. Im Gegenteil: Nur wenn auch die VDs usw. mit Fhem gep'''ai'''rt sind, haben Sie die Möglichkeit, auch diese zu überwachen. Die Steuerung '''können''' Sie dennoch allein dem HM-CC-TC überlassen.

=== Auto-Modus ===
Im Modus '''Auto''' wird die Temperaturregelung über die im TC hinterlegten Temperaturlisten vorgenommen. Das Thermostat arbeitet also selbständig, somit unabhängig von einer Zentrale / FHEM. Nur in diesem Modus werden die evtl. per FHEM an das TC übermittelten "templist" abgearbeitet. Über das Senden von angepassten Temperatur-Listen kann eine indirekte Steuerung per FHEM erfolgen. '''Jederzeit''' kann zudem die Raumtemperatur über das Drehrad des Wandthermostaten oder die FHEM-Web-Oberfläche verändert werden. Diese ''Übersteuerung'' der Temperaturliste gilt bis zur nächsten Temperaturänderung nach der vorgenannten Liste.

=== Cent-Modus ===
Im Modus '''Cent''' steuert eine HomeMatic-Zentrale (CCU) oder eben ein FHEM-Server mit z.B. [[HMLAN Konfigurator]] zu den in der FHEM-Config hinterlegten Zeiten und mit den dort festgelegten Temperaturen. Fällt also die HM-Zentrale aus, erfolgt keine Steuerung der Thermostaten bzw. Heizungsventile mehr.

<ins>Anmerkung</ins>: Der Modus ''cent'' erscheint nur dann im Display des HM-CC-TC, wenn er an eine Zentrale bzw. das [[CUL]] angelernt (gepairt) wurde.

=== Manu-Modus ===
Der Modus '''Manu''' übersteuert die im TC hinterlegten Temperaturlisten und die evtl. von der HM-Zentrale / dem FHEM <ins>vor Umstellung auf ''Manu''</ins> gesendeten Einstellungen. Es wird also bis zur nächsten Modusumstellung bzw. manuellen Temperaturverstellung der per Einstellrad gesetzte Temperaturwert gefahren.

Aber auch in diesem Modus kann man die ''desired-temperature'' per FHEM verstellen. Der dadurch eingestellte Wert gilt ab sofort als der neue im ''Manu-Modus'' zu haltende Wert.

=== Auslesen des eingestellten Steuerungsmodus ===
Der eingestellte Steuerungsmodus erscheint normalerweise in den ''Readings'' des HM-CC-TC unter ''controlMode''. Zusätzlich haben Sie die Möglichkeit, diesen Modus auch in der FHEM-Weboberfläche ''everything'' => Abschnitt ''thermostat'' zu sehen, '''wenn''' Sie für den HM-CC-TC das folgende Attribut setzen:

<nowiki>attr <HM-CC-TC-Name> stateFormat T:measured-temp, H:humidity, VD:actuator, controlMode</nowiki>
Erscheint dort selbst nach einem

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
kein "Reading" ''controlMode'' oder keine Angabe des aktuell eingestellten Modus bzw. nur das Wort "controlMode", dann setzen Sie ihren HM-CC-TC von Hand in einen anderen Kontrollmodus und machen einen Browser-Refresh. Klappt dies nicht, geben Sie bitte erneut den Befehl

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
ein. Halten Sie anschließend die Taste <OK> am HM-CC-TC für 5 Sekunden gedrückt (oder warten ca. 5 Minuten) und machen in der FHEM-Weboberfläche einen Browser-Refresh (FF => <F5>). Jetzt sollte der manuell eingestellte Kontrollmodus erscheinen (ggfls. muss dieser Vorgang einmal wiederholt werden). Jetzt können Sie wieder den gewünschten Modus einstellen, erneut ein

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
absetzen und nach erneutem Drücken der <OK>-Taste für 5 Sekunden mit nachfolgendem Browser-Refresh sollte alles richtig angezeigt werden.

Dies setzt natürlich voraus, dass der HM-CC-TC richtig gepairt ist.

== Temperaturlisten ==

'''Achtung:''' Die Listen mussten bis vor kurzem noch auf das Device HM-CC-TC, nunmehr aber auf dessen Channel HM-CC-TC_Climate gesetzt werden. Dadurch ändert sich die Benennung des Gerätes (wird in den u.a. Beispielen berücksichtigt).

Eine Temperaturliste für die Steuerung der Raumtemperatur im o.a. '''Auto-Modus''' kann man wie folgt erzeugen:

* Man legt sich eine eigene ''99_MyUtils.pm'' an (siehe [[99_myUtils anlegen]]). Dies ist wichtig, da es bei FHEM-Updates durchaus sein kann, dass die vorhandene ''99_Utils.pm'' erneuert und damit überschrieben wird und dann sind all ihre eigenen Subroutinen weg.
* Dort trägt man für '''jedes''' HM-CC-TC, dessen Werte man individuell einstellen will, eine '''eigene''' Subroutine ein, die z.B. wie folgt aussehen kann:

<pre>
######################################################
# Temperatur-Liste für das Wohnzimmer
# setzen per Aufruf von "{SetTempList_EG_WZ_Heizung}"
######################################################
sub
SetTempList_EG_WZ_Heizung()
{
{ fhem ("set EG.WZ.Heizung_Climate tempListMon 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListTue 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListWed 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListThu 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListFri 05:30 19.0 07:00 21.0 15:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListSat 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListSun 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.5")};
}
# End SetTempList_EG_WZ_Heizung
</pre>

* die Änderungen in der ''99_MyUtils.pm'' müssen jetzt abgespeichert werden
* in der FHEM-Befehlszeile ist ein ''reload 99_MyUtils.pm'' mit <Enter> / <Return> abzusetzen (erst dadurch werden die Eintragungen / Änderungen aktiviert)
* nun kann man in der Kommandozeile von FHEM den Befehl ''{SetTempList_EG_WZ_Heizung}'' eingeben und mit <Return> bzw. <Enter> bestätigen

Im FHEM-Logfile (das man vorher in einem weiteren Browser-Tab geöffnet hat, Refresh (F5) nicht vergessen) taucht danach folgendes auf:

<pre>
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListMon 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListTue 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListWed 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListThu 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListFri 05:30 17.0 07:00 21.0 15:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListSat 07:00 17.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListSun 07:00 17.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0
</pre>

'''Zur Erläuterung:'''

Mittels

<pre>
set EG.WZ.Heizung_Climate tempListMon 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
</pre>

setzt man den HM-CC-TC-Channel mit dem Namen ''EG.WZ.Heizung_Climate'' für jeden folgenden Montag

von 00:00 '''bis''' 05:30 Uhr auf 17,0 °C 
von 05:31 '''bis''' 07:00 Uhr auf 21,0 °C 
von 07:31 '''bis''' 16:00 Uhr auf 19,0 °C 
...

und so weiter. Dabei kann bei der Temperatur als Nachkommawert entweder eine 0 oder eine 5 stehen, ein Wert von z.B. 20,1 ist nicht erlaubt.

'''Achtung:''' Häufigste Fehlerquelle ist das Verstehen der Reihen- bzw. Abfolge der Zeit- und Temperaturwerte. Deshalb ein weiterer Beschreibungsversuch mit anderen Worten, der hoffentlich zum besseren Verständnis beiträgt:

Die Definition <ins>beginnt</ins> von selbst jeweils bei 00:00 Uhr eines Tages. Die danach angegebene Uhrzeit (im letzten Beispiel ''tempListMon'': 05:30 Uhr) beschreibt also den Zeitraum von 00:00 Uhr '''bis''' 05:30 Uhr. Der <ins>danach</ins> folgende Wert von 17.0 definiert also den in der Zeit von 00:00 Uhr '''bis''' 05:30 Uhr geltenden Wunschtemperaturwert von 17,0 °C. Die im vorgenannten Beispiel auf die Wertangabe ''17.0'' folgende Uhrzeit von ''07:00'' legt nun den Zeitraum von 05:30 Uhr '''bis''' 07:00 Uhr für den dahinter stehenden Temperaturwert von 21.0 fest. Die Abfolge kann dem Einen oder der Anderen unnatürlich vorkommen, aber es ist eine so von eQ3 festgelegte Notationsweise.

'''Beachten Sie bitte''', dass am Schluss der Liste <ins>immer</ins> eine Einstellung für 24:00 notiert sein '''muss'''. Ansonsten quittiert FHEM das Setzen der Liste mit einem solchen Eintrag im Logfile:

<pre>
Last time spec must be 24:00
</pre>

Im FHEM-Logfile-Browser-Tab sollten nach einigen Minuten folgende mehrfach wiederholten Einträge auftauchen:

<pre>
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate CommandAccepted: yes
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate CommandAccepted: yes
...
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate CommandAccepted: yes
</pre>

Wichtig ist ein nachfolgendes "ACK". Steht dort "MISSING ACK", dann wurde der Empfang der Werte vom HM-CC-TC nicht bestätigt und man sollte die TempList noch einmal schicken. Kommt auch nach mehreren Sendeversuchen kein "ACK" sollten Sie in den ''Readings''des Devices die ''TempList''überprüfen (siehe unten), denn es kann sein, dass diese Antwort schlicht nicht empfangen werden konnte, weil der Empfänger gerade anderweitig beschäftigt war, die Einstellungen aber dennoch übernommen wurden. Wird jedoch ein "NACK" vom HM-CC-TC gesendet, dann wurde die Temperaturliste explizit nicht akzeptiert. Kontrollieren Sie in diesem Fall die Korrektheit der Temperaturliste.

Welche Werte '''aktuell eingestellt'''sind, sieht man in den "Readings" des jeweiligen Devices; im obigen Fall also z.B. im linken Menü von FHEM auf den default-Eintrag ''Everything''klicken und dann auf den Eintrag mit dem Namen ''EG.WZ.Heizung''.

== Temperaturlisten (neu) ==

Seit Mitte Oktober 2013 kann man die Temperaturlisten "ressourcenschonender" an einen HM-CC-TC übertragen. Bisher wurde für jeden Tag ein Befehl abgeschickt (siehe obiges Beispiel). Nun kann man, wie beim [[HM-CC-RT-DN Funk-Heizkörperthermostat#Temperaturlisten setzen|HM-CC-RT-DN] (dem Nachfolger des HM-CC-TC), auch alles in ein einziges "Funktelegramm" packen. Dazu das folgende Beispiel (achten Sie bitte auf die Schlüsselwörter "prep" und "exec"):

######################################################
# Temperatur-Liste für Kinderzimmer
# setzen per Aufruf von "{SetTempList_Kind_Heizung}"
######################################################
sub
SetTempList_Kind_Heizung()
{
{ fhem ("set DG.Kind.Heizung_Climate tempListMon prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListTue prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListWed prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListThu prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListFri prep 05:30 19.0 07:00 20.5 15:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListSat prep 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListSun exec 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0")};
}
# End SetTempList_Kind_Heizung

Zum Verständnis: Mittels ''prep'' werden die Werte in einen "Puffer" gepackt und sobald ein "exec" auftaucht, wird er Puffer mit dem Nachfolgenden gefüllt und anschließend '''in einem Rutsch''' an den HM-CC-TC geschickt. Dies vermeidet/minimiert Übertragungsprobleme.

== Batteriealarme des HM-CC-VD in Verbindung mit HM-CC-TC ==
1. bei U-Bat. < 2,4 V erscheint im Display des VD und des TC das Batteriesymbol mit '''battery: low''' in den Readings und Events!

2. bei U-Bat. < 2,3 V erscheint im Display des VD zusätzlich '''F4''' mit '''battery: critical''' in den Readings und Events!

Es wird dringend geraten, die Batterien bei battery: low zu tauschen!

== Log-Auszug ==
HM-CC-TC sendet alle 2 Minuten folgenden Statusbericht:

<nowiki>Datum-Zeit <Device Name> T: 17.3 H: 66 
Datum-Zeit <Device Name> measured-temp: 17.3 
Datum-Zeit <Device Name> temperature: 17.3 
Datum-Zeit <Device Name> humidity: 66 
Datum-Zeit <Device Name> actuator: 96 % </nowiki>
Bei Status-Änderungen sendet HM-CC-TC auch entsprechende Meldungen, z.b.:

<nowiki>Datum-Zeit <Device Name> desired-temp: 15.5 </nowiki>

= Probleme =

== Verstellen der Solltemperatur am HM-CC-TC per Drehrad ==

'''Symptom:''' Beim Verstellen der Solltemperatur per seitlichem Drehrad wurde die aktuelle Solltemperatur - '''egal ob''' man hoch oder runter drehte - immer nur in 0,5 °C Schritten '''runter''' gestellt, bis schließlich die Mindesttemperatur von 6,0 °C erreicht war. Weitere Änderungen waren nicht möglich

'''Abhilfe:''' Letztlich half nur das kurzzeitige Entfernen einer Batterie. Das danach für einige Zeit erscheinende Batteriesymbol zeigte den kleinstmöglichen guten Zustand an, in FHEM wurde das ''Reading'' des Batteriezustandes mit ''ok'' ausgegeben (wie in den Logs aber vorher auch). '''Letztlich half aber nur''' das Einsetzen neuer Batterien, denn die o.a. Störung trat nach ca. 2 Stunden erneut auf. Die "alten" Batterien (die, die dem HM-CC-TC ab Werk beilagen) hatten somit eine Nutzungsdauer von knapp 11 Monaten, waren aber auch in einem HM-CC-TC, der mit 4 Stck. HM-Sec-SC (mussten sehr oft "Meldung machen") und 4 Stck. HM-CC-VD gepeert war. ''Ohne Last'' zeigten die beiden alten AA-Batterien eine Spannung von jeweils 1,29 V an.

'''Hinweis:''' Die unter ''Abhilfe'' beschriebene Lösung war leider nur von kurzer Dauer. Bereits kurz danach zeigte der HM-CC-TC die gleichen Ausfallerscheinungen. Bei ELV gibt es das Bauteil für das Drehrad (Inkrementalgeber) als [http://www.elv.de/inkrementalgeber-fuer-fs20-str-fht-8-und-homematic-hm-cc-tc.html Ersatzteil]. Sobald dieses geliefert und ein Reparaturversuch unternommen wurde, wird an dieser Stelle weiter berichtet.

= Firmware =
Aktuelle Firmware-Version: 2.1

= Links =
Anleitung [http://www.elv-downloads.de/service/manuals/76787_76175_HM_Wandthermostat_UM.pdf PDF]

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

HM-CC-TC Funk-Wandthermostat

2014-07-05T16:29:35Z

Rohan: /* expert */ Formatierung normalisiert

'''HM-CC-TC Funk-Wandthermostat'''

Programmierbarer Raumthermostat, der bis zu 4 [[HM-CC-VD Funk-Stellantrieb]] steuern kann.

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt).'''

Nachfolgeprodukt ist der [[HM-CC-RT-DN]] bzw. (ab März 2014) [[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]].

= Features =
* Am Raumthermostat programmierbare Tages- und Nachttemperatur.
* Pro Wochentag können bis zu 24 Schaltpunkte definiert werden.
* Anbindung von <ins>jeweils</ins> '''maximal''' 4 Tür- bzw. Fensterkontakten ([[HM-Sec-RHS]]) zur Absenkung der Temperatur auf einen eigens eingestellten Temperaturwert (ab Werk: 12°C) bei offenem Fenster bzw. offener Tür.
* Anzeige der Temperatur und Luftfeuchtigkeit im Raum und Hintergrundbeleuchtung des Displays.

Alle 120 bis 184 Sekunden überträgt der Wandthermostat vorhandene Befehle zu den Stellantrieben. Jeder empfangene Befehl wird vom Stellantrieb bestätigt und dann ausgeführt. Täglich gegen Mitternacht synchronisiert ein HM-CC-TC seine Uhrzeit mit der HomeMatic-Zentrale (CCU, HMLAN).

= Hinweise zum Betrieb mit FHEM =
Vor dem Einsatz mit einer Zentrale sind erst alle Stellantriebe und Tür-/Fensterkontakte mit dem HM-CC-TC zu verbinden (P'''ee'''r).
Damit das ganze dann in FHEM auftaucht, muss der TC noch mit dem [[HMLAN Konfigurator]] gep'''ai'''rt werden.

Mit

<nowiki>set CUL hmPairForSec 300</nowiki>
setzt man das CUL / den HMLAN-Konfigurator für 5 Minuten in den Anlernmodus. Danach am Thermostaten 5 Sekunden lang die OK-Taste drücken und es wird eine Zeit von 20 auf 0 Sekunden gezählt:

* Klappt das Anlernen in diesen 20 Sekunden, wird der Countdown sofort beendet, anschließend für ca. 2-3 Sekunden "OK" angezeigt und der Thermostat ist in FHEM eingebunden.
* Gelingt das Anlernen nicht in den 20 Sekunden, erscheint nach Erreichen der "0" noch für 2 bis 3 Sekunden ein "NOK" ('''N'''ot '''OK''') im Display des TCs.

'''Alternativ'''(und so vom Entwickler des Fhem-HomeMatic-Moduls empfohlen) kann wie folgt vorgegangen werden:

* Alle Stellantriebe und Tür-/Fensterkontakte sowie den HM-CC-TC mit Fhem p'''ai'''ren (also ''set CUL hmPairForSec 300'' und an allen Devices den Anlernknopf drücken innerhalb des Zeitfensters von 300 Sekunden).
* Die Stellantriebe und Tür-/Fensterkontakte mit den ''Channels'' (siehe unten) p'''ee'''ren (siehe <nowiki>[http://fhem.de/commandref.html#CUL_HMpeerChan commandref :peerChan]</nowiki>). Hierzu werden die entsprechenden Fhem-Befehle über das Webinterface von Fhem erteilt.

'''Hinweis:'''
* Alle in der FHEM-Eingabezeile eingegebenen ''attr''-, ''define''-Befehle usw. müssen zum Schluss noch per Klick auf den "Save"-Button dauerhaft in der ''fhem.cfg'' gespeichert werden, sonst sind sie nach z.B. einem Systemabsturz verloren.
* Falls in der FHEM-Weboberfläche für ihren HM-CC-TC etwas wie ''X CMDs pending'' steht, sollten Sie ihren HM-CC-TC zur Hand nehmen und für 20 Sekunden auf die OK-Taste drücken. Dadurch werden alle noch ausstehenden Befehle eingelesen.

== Auszug aus der fhem.cfg ==
Die nachfolgenden Einstellungen zum HM-CC-TC werden von FHEM <ins>weitestgehend</ins> automatisch gesetzt. Die Pfadangaben für die Log-Dateien sind system-, die Raumbenennungen benutzerabhängig. Zu ''autoReadReg''und ''expert''siehe unten. Neben dem eigentlichen Basis-Gerät (HM-CC-TC) werden in FHEM automatisch noch 3 weitere "Unter"-Geräte (Channels/Kanäle), nämlich

* ''_Weather''
* ''_Climate''
* ''_WindowRec''

definiert (durch das Anlernen des TC an FHEM; siehe unten), deren Benennung sich (jeweils mit einem vorangestellten Unterstrich "_") am Namen des Basis-Gerätes orientiert.

'''Anmerkung:'''Die in den unten gezeigten ''fhem.cfg''-Auszügen markierten <ins>Peer</ins>-Einträge tauchen erst auf, sobald man die Daten aus dem TC mit ''set HM-CC-TC-Basisname getConfig''bzw. ''autoReadReg''ausgelesen hat.

=== Hauptgerät ===
<nowiki>define <HM-CC-TC>.Heizung CUL_HM 1DA491
attr <HM-CC-TC>.Heizung actCycle 000:10
attr <HM-CC-TC>.Heizung actStatus alive
attr <HM-CC-TC>.Heizung autoReadReg 1
attr <HM-CC-TC>.Heizung devInfo 00FFFF
attr <HM-CC-TC>.Heizung expert 2_full
attr <HM-CC-TC>.Heizung firmware 2.1
attr <HM-CC-TC>.Heizung hmClass receiver
attr <HM-CC-TC>.Heizung model HM-CC-TC
attr <HM-CC-TC>.Heizung room <IhrRaum>
attr <HM-CC-TC>.Heizung serialNr JE********
attr <HM-CC-TC>.Heizung subType thermostat</nowiki>
=== Channel (Kanal) 01 _Weather ===
<nowiki>define <HM-CC-TC>.Heizung_Weather CUL_HM 1DA49101 <<<=== 01 = Kanal 1
attr <HM-CC-TC>.Heizung_Weather model HM-CC-TC
attr <HM-CC-TC>.Heizung_Weather peerIDs
attr <HM-CC-TC>.Heizung_Weather room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_Weather FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_Weather-%Y-%m.log <HM-CC-TC>.Heizung_Weather
attr FileLog_<HM-CC-TC>.Heizung_Weather logtype text
attr FileLog_<HM-CC-TC>.Heizung_Weather room CUL_HM,<IhrRaum></nowiki>
=== Channel (Kanal) 02 _Climate ===
<nowiki>define <HM-CC-TC>.Heizung_Climate CUL_HM 1DA49102 <<<=== 02 = Kanal 2
attr <HM-CC-TC>.Heizung_Climate model HM-CC-TC
attr <HM-CC-TC>.Heizung_Climate peerIDs 1AD52B01,1B7A4C01,1C4CD101,1C48EC01, <<<=== gepeerte HM-CC-VDs
attr <HM-CC-TC>.Heizung_Climate room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_Climate FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_Climate-%Y-%m.log <HM-CC-TC>.Heizung_Climate
attr FileLog_<HM-CC-TC>.Heizung_Climate logtype text
attr FileLog_<HM-CC-TC>.Heizung_Climate room CUL_HM,<IhrRaum></nowiki>
=== Channel (Kanal) 03 _WindowRec ===
<nowiki>define <HM-CC-TC>.Heizung_WindowRec CUL_HM 1DA49103 <<<=== 03 = Kanal 3
attr <HM-CC-TC>.Heizung_WindowRec model HM-CC-TC
attr <HM-CC-TC>.Heizung_WindowRec peerIDs 1CFBB001, <<<=== gepeerte HM-Sec-SCs
attr <HM-CC-TC>.Heizung_WindowRec room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_WindowRec FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_WindowRec-%Y-%m.log <HM-CC-TC>.Heizung_WindowRec
attr FileLog_<HM-CC-TC>.Heizung_WindowRec logtype text
attr FileLog_<HM-CC-TC>.Heizung_WindowRec room CUL_HM,<IhrRaum></nowiki>
== Einstellungen eines HM-CC-TC lesen, anzeigen und sichern ==
=== expert ===
Anfang Februar 2013 wurde eine Änderung bei der Anzeige der so genannten ''Readings'' (Register usw.), also der Einstellungen bzw. Eigenschaften eines HM-Devices, eingeführt. '''Alle'' 'Werte sieht man nur noch, wenn man am HM-CC-TC das Attribut ''expert'' auf ''2_all'' setzt. Per '''default''' (nicht in ''fhem.cfg'' gesetzt) steht dieser Wert auf ''0_off'' (nur die notwendigsten Readings/Eigenschaften werden angezeigt). Mittelweg ist der Wert ''1_on''.

Mittels

<nowiki>attr <HM-CC-TC-Name> expert 2_full</nowiki>
in der FHEM-Befehlszeile mit anschließendem <Enter> setzt man diesen Level.

Falls man mit '''Temperaturlisten''' arbeitet (siehe unten), dann kann man die komplette Liste im "Channel" (Kanal) ''<HM-CC-TC-Name>__Climate''einsehen. Auch für diesen Kanal ist evtl. ein setzen des Attributes ''expert 2_full'' angeraten.

<ins>Anmerkung:</ins> Es gibt auch noch sogenannte "hidden datas" (versteckte interne Werte, Register oder Eigenschaften deren Namen mit einem "." beginnen). Diese sieht man nur dann, wenn auch das Attribut ''showInternalValues 1'' gesetzt ist (default: 0 bzw. nicht gesetzt).

=== autoReadReg ===
Mitte Januar 2013 wurde das neue Attribut ''autoReadReg'' eingeführt, welches auf ''0'' voreingestellt ist (kein Eintrag in der ''fhem.cfg''). Das setzen dieses Attributes auf ''1'' bewirkt, dass <ins>beim Neustart von FHEM</ins> die Einstellungen des entsprechenden HM-Gerätes ausgelesen werden. Dies wird bei mehreren ''autoReadReg''s automatisch zeitversetzt vorgenommen, um die Funk-Kommunikation nicht unnötig zu belasten.

Mittels

<nowiki>attr <HM-CC-TC-Name> autoReadReg 1 </nowiki>
in der FHEM-Befehlszeile mit anschließendem <Enter> setzt man diesen Wert.

=== list ===
Um sich alle Eigenschaften/Readings eines Gerätes anzusehen, gibt es den Befehl ''list''.

Mittels

<nowiki>list <HM-CC-TC-Name></nowiki>
und Bestätigung mit <Enter> erhalten Sie die gewünschte Anzeige Ihres TCs <ins>incl.</ins> seiner 3 Channels. Über

<nowiki>list <HM-CC-TC-Name>_<Channel-Name></nowiki>
werden nur die Daten des angegebenen Channels angezeigt.

=== Einstellungen sichern ===
Die Durchführung von ''autoReadReg'' kann durchaus mehrere Minuten dauern. Anschließend besteht die Möglichkeit, diese per

<nowiki>get HM-CC-TC-Basisname saveConfig [/Verzeichnis/mit/Schreibrechten/]<Dateiname></nowiki>
für jedes HM-CC-TC getrennt zu sichern (für eine später notwendige Wiederherstellung). Die Sicherungsdatei wird regulär im ''modpath'' (siehe ''fhem.cfg'') abgelegt. Falls dies nicht zum Erfolg führt (es wird - ohne Fehlermeldungen bei regulärem ''verbose'' und ''loglevel'' - im ''modpath'' keine Datei angelegt), müssen Sie vor dem Dateinamen einen vollständigen Pfad mit Schreibrechten für den Benutzer, unter dem FHEM läuft, angeben.

In der <ins>Log-Datei</ins> von FHEM erscheinen danach Meldungen folgender Art

<nowiki><Datum>_<Zeit> 2: CUL_HM set <HM-CC-TC-Name> statusRequest rxt:12
<Datum>_<Zeit> 2: CUL_HM set <HM-CC-TC-Name> getConfig rxt:12</nowiki>
Hierbei kann es (im <ins>Event monitor</ins> von FHEM) zu folgenden Fehlermeldungen kommen

<nowiki><Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:RegisterRead
<Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:PeerList
<Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:StatusReq</nowiki>
Diese Meldungen können auch mehrfach pro Gerät auftreten. Dann hat das Auslesen der Einstellungen nicht geklappt und sollte nochmals durchgeführt werden. Dafür muss man FHEM aber nicht neu starten, sondern das HM-Device per

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
in der Befehlszeile von FHEM und anschließendem <Enter> (nicht "save") darauf einstellen.

Die Channels (z.B. <HM-CC-TC-Name>_Climate, _Weather, _WindowRec) eines HM-Gerätes brauchen nicht (können aber bei Bedarf) separat ausgelesen bzw. gesichert zu werden, da sie Bestandteil der Basisabfrage sind.

== Funkprobleme auffangen ==
Der wohl am häufigsten an den HM-CC-TC gesendete Befehl ist "set desired-temp", mit dem die Wunschtemperatur neu gesetzt wird.
Funktioniert dieser Befehl jedoch nicht zuverlässig, wird die Wohnung ggf. zu lange oder nicht rechtzeitig beheizt.
Der folgende Mechanismus soll die Sicherheit erhöhen, indem die Antworten des HM-CC-TC geprüft werden und ggf. das Funktelegramm erneut gesendet wird.

Um den Sollwert zum erneuten Senden des Funktelegramms verfügbar zu haben, wird ein dummy definiert:

<nowiki>define HM_TC_Solltemperatur dummy</nowiki>
Wann immer die Solltemperatur geändert wird, setzt man die neue desired-temp nicht nur auf dem HM-TC-CC (hier HM_TC genannt), sondern auch auf dem dummy. Der Befehl (z.B. in der [[Zuhause-Status|Routine zum HomeStatus]]) sieht dann so aus:

<nowiki>set HM_TC desired-temp 21;set HM_TC_Solltemperatur 21</nowiki>
Falls das ausgehende Funktelegramm verlorengeht, fehlt die Antwort "command accepted". Dies kann mit einem watchdog aufgefangen werden, der dann den Befehl an den HM-CC-TC erneut sendet:

<nowiki>define w_HM_TC watchdog HM_TC:set_desired-temp.* 00:02:30 HM_TC_Climate:CommandAccepted:.yes { \
Log 1, ">>>>>>>>> w_HM_TC desired temp - missing response.";\
fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\
}</nowiki>
Falls ein Fehler bei der Funkkommunikation auftritt, erhält man die Antwort "missing ACK" oder "NACK". Auch in diesem Fall soll das Telegramm zum Ändern der Wunschtemperatur erneut an den HM-CC-TC gesendet werden:

<nowiki>define n_HM_TC_err notify HM_TC:(MISSING.ACK.*|.*NACK.*) {\
Log 1, ">>>>>>>>> n_HM_TC desired temp - missing ack/nack.\n";\
fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\
}</nowiki>
Mit diesen beiden Helfern ist die Funkkommunikation zum HM-CC-TC sehr zuverlässig.

== Plots / Grafiken ==
=== Problem ===
Durch ''autocreate'' wird zwar ein Log angelegt, aber kein Plot (Grafische Auswertung). Dem kann man aber abhelfen (siehe unten).

=== Plots erzeugen ===
''PGM2'' ist die Standardansicht des Fhem-Web-Interfaces. Um hier Plots/Grafiken zu erzeugen einfach unter dem ''Filelog'' des Thermostaten das ''attr logtype'' auf ''temp4hum6:Plot,text'' setzen und es wird ein Plot-Link neben dem Text-Link angezeigt. Nun können Sie auf diesen Plot-Link klicken und ...

=== alternative Plots ===
Mit dem fht.gplot funktioniert die Anzeige der Ventilstellung (actuator) nicht.

Mit folgendem angepassten .gplot File wird die gemessene Temperatur und Ventilstellung angezeigt.

<nowiki>############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define <filelogname> FileLog /var/log/fhem/actuator_name-%Y.log <actuator_name>:(measured-temp|actuator).*

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 ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics

set y2label "Temperatur in C"
set ylabel "Ventil (%)"

#FileLog 4:measured:10:
#FileLog 4:actuator:50:

plot \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Temperatur in C' with lines,\
"< egrep 'actuator' <IN>"\
using 1:4 axes x1y1 title 'Ventil (%)' with lines\</nowiki>
=== Alles-drin-Plot ===
dazu nimmt man folgendes .gplot. Man/Fra beachte, dass hierfür alle Parameter nach der define-Anweisung in das Logfile geschrieben werden.

<nowiki>############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define <filelogname> FileLog /var/log/fhem/HM_CC_TC-%Y.log <HM_CC_TC-name>
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 ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics
set y2label "Temperature in C"
set ylabel "Actuator (%)"
#FileLog 4:temperature:0:
#FileLog 4:desired:0:
#FileLog 4:humidity:0:
#FileLog 4:actuator:0:int
plot \
"< awk '/temperature/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Measured temperature' with lines lw 2,\
"< awk '/desired/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Desired temperature' with steps,\
"< awk '/humidity/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Humidity (%)' with lines,\
"< awk '/actuator/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Actuator (%)' with lines\</nowiki>

== Steuerungsmodi ==
Das Wandthermostat hat 4 verschiedene Steuerungsmöglichkeiten:

* Auto (automatisch)
* Cent (Zentrale)
* Manu (manuell)
* Prog / Koffer-Symbol (Urlaubs/Party-Modus, wird hier nicht näher erörtert)

Der Steuerungsmodus wird über wiederholtes Drücken der linken Taste des HM-CC-TC ausgewählt bzw. gewechselt.

'''Hinweis:''' Durch das P'''ai'''ren des HM-CC-TC <ins>und</ins> der Stellantrieb sowie Tür-/Fensterkontakte an Fhem verlieren Sie '''nicht''' die Steuerungsmöglichkeiten. Im Gegenteil: Nur wenn auch die VDs usw. mit Fhem gep'''ai'''rt sind, haben Sie die Möglichkeit, auch diese zu überwachen. Die Steuerung '''können''' Sie dennoch allein dem HM-CC-TC überlassen.

=== Auto-Modus ===
Im Modus '''Auto''' wird die Temperaturregelung über die im TC hinterlegten Temperaturlisten vorgenommen. Das Thermostat arbeitet also selbständig, somit unabhängig von einer Zentrale / FHEM. Nur in diesem Modus werden die evtl. per FHEM an das TC übermittelten "templist" abgearbeitet. Über das Senden von angepassten Temperatur-Listen kann eine indirekte Steuerung per FHEM erfolgen. '''Jederzeit''' kann zudem die Raumtemperatur über das Drehrad des Wandthermostaten oder die FHEM-Web-Oberfläche verändert werden. Diese ''Übersteuerung'' der Temperaturliste gilt bis zur nächsten Temperaturänderung nach der vorgenannten Liste.

=== Cent-Modus ===
Im Modus '''Cent''' steuert eine HomeMatic-Zentrale (CCU) oder eben ein FHEM-Server mit z.B. [[HMLAN Konfigurator]] zu den in der FHEM-Config hinterlegten Zeiten und mit den dort festgelegten Temperaturen. Fällt also die HM-Zentrale aus, erfolgt keine Steuerung der Thermostaten bzw. Heizungsventile mehr.

<ins>Anmerkung</ins>: Der Modus ''cent'' erscheint nur dann im Display des HM-CC-TC, wenn er an eine Zentrale bzw. das [[CUL]] angelernt (gepairt) wurde.

=== Manu-Modus ===
Der Modus '''Manu''' übersteuert die im TC hinterlegten Temperaturlisten und die evtl. von der HM-Zentrale / dem FHEM <ins>vor Umstellung auf ''Manu''</ins> gesendeten Einstellungen. Es wird also bis zur nächsten Modusumstellung bzw. manuellen Temperaturverstellung der per Einstellrad gesetzte Temperaturwert gefahren.

Aber auch in diesem Modus kann man die ''desired-temperature'' per FHEM verstellen. Der dadurch eingestellte Wert gilt ab sofort als der neue im ''Manu-Modus'' zu haltende Wert.

=== Auslesen des eingestellten Steuerungsmodus ===
Der eingestellte Steuerungsmodus erscheint normalerweise in den ''Readings'' des HM-CC-TC unter ''controlMode''. Zusätzlich haben Sie die Möglichkeit, diesen Modus auch in der FHEM-Weboberfläche ''everything'' => Abschnitt ''thermostat'' zu sehen, '''wenn''' Sie für den HM-CC-TC das folgende Attribut setzen:

<nowiki>attr <HM-CC-TC-Name> stateFormat T:measured-temp, H:humidity, VD:actuator, controlMode</nowiki>
Erscheint dort selbst nach einem

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
kein "Reading" ''controlMode'' oder keine Angabe des aktuell eingestellten Modus bzw. nur das Wort "controlMode", dann setzen Sie ihren HM-CC-TC von Hand in einen anderen Kontrollmodus und machen einen Browser-Refresh. Klappt dies nicht, geben Sie bitte erneut den Befehl

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
ein. Halten Sie anschließend die Taste <OK> am HM-CC-TC für 5 Sekunden gedrückt (oder warten ca. 5 Minuten) und machen in der FHEM-Weboberfläche einen Browser-Refresh (FF => <F5>). Jetzt sollte der manuell eingestellte Kontrollmodus erscheinen (ggfls. muss dieser Vorgang einmal wiederholt werden). Jetzt können Sie wieder den gewünschten Modus einstellen, erneut ein

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
absetzen und nach erneutem Drücken der <OK>-Taste für 5 Sekunden mit nachfolgendem Browser-Refresh sollte alles richtig angezeigt werden.

Dies setzt natürlich voraus, dass der HM-CC-TC richtig gepairt ist.

== Temperaturlisten ==

'''Achtung:''' Die Listen mussten bis vor kurzem noch auf das Device HM-CC-TC, nunmehr aber auf dessen Channel HM-CC-TC_Climate gesetzt werden. Dadurch ändert sich die Benennung des Gerätes (wird in den u.a. Beispielen berücksichtigt).

Eine Temperaturliste für die Steuerung der Raumtemperatur im o.a. '''Auto-Modus''' kann man wie folgt erzeugen:

* Man legt sich eine eigene ''99_MyUtils.pm'' an (siehe [[99_myUtils anlegen]]). Dies ist wichtig, da es bei FHEM-Updates durchaus sein kann, dass die vorhandene ''99_Utils.pm'' erneuert und damit überschrieben wird und dann sind all ihre eigenen Subroutinen weg.
* Dort trägt man für '''jedes''' HM-CC-TC, dessen Werte man individuell einstellen will, eine '''eigene''' Subroutine ein, die z.B. wie folgt aussehen kann:

<pre>
######################################################
# Temperatur-Liste für das Wohnzimmer
# setzen per Aufruf von "{SetTempList_EG_WZ_Heizung}"
######################################################
sub
SetTempList_EG_WZ_Heizung()
{
{ fhem ("set EG.WZ.Heizung_Climate tempListMon 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListTue 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListWed 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListThu 05:30 19.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListFri 05:30 19.0 07:00 21.0 15:00 19.0 20:30 20.5 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListSat 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.5")};
{ fhem ("set EG.WZ.Heizung_Climate tempListSun 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.5")};
}
# End SetTempList_EG_WZ_Heizung
</pre>

* die Änderungen in der ''99_MyUtils.pm'' müssen jetzt abgespeichert werden
* in der FHEM-Befehlszeile ist ein ''reload 99_MyUtils.pm'' mit <Enter> / <Return> abzusetzen (erst dadurch werden die Eintragungen / Änderungen aktiviert)
* nun kann man in der Kommandozeile von FHEM den Befehl ''{SetTempList_EG_WZ_Heizung}'' eingeben und mit <Return> bzw. <Enter> bestätigen

Im FHEM-Logfile (das man vorher in einem weiteren Browser-Tab geöffnet hat, Refresh (F5) nicht vergessen) taucht danach folgendes auf:

<pre>
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListMon 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListTue 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListWed 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListThu 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListFri 05:30 17.0 07:00 21.0 15:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListSat 07:00 17.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListSun 07:00 17.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0
</pre>

'''Zur Erläuterung:'''

Mittels

<pre>
set EG.WZ.Heizung_Climate tempListMon 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
</pre>

setzt man den HM-CC-TC-Channel mit dem Namen ''EG.WZ.Heizung_Climate'' für jeden folgenden Montag

von 00:00 '''bis''' 05:30 Uhr auf 17,0 °C 
von 05:31 '''bis''' 07:00 Uhr auf 21,0 °C 
von 07:31 '''bis''' 16:00 Uhr auf 19,0 °C 
...

und so weiter. Dabei kann bei der Temperatur als Nachkommawert entweder eine 0 oder eine 5 stehen, ein Wert von z.B. 20,1 ist nicht erlaubt.

'''Achtung:''' Häufigste Fehlerquelle ist das Verstehen der Reihen- bzw. Abfolge der Zeit- und Temperaturwerte. Deshalb ein weiterer Beschreibungsversuch mit anderen Worten, der hoffentlich zum besseren Verständnis beiträgt:

Die Definition <ins>beginnt</ins> von selbst jeweils bei 00:00 Uhr eines Tages. Die danach angegebene Uhrzeit (im letzten Beispiel ''tempListMon'': 05:30 Uhr) beschreibt also den Zeitraum von 00:00 Uhr '''bis''' 05:30 Uhr. Der <ins>danach</ins> folgende Wert von 17.0 definiert also den in der Zeit von 00:00 Uhr '''bis''' 05:30 Uhr geltenden Wunschtemperaturwert von 17,0 °C. Die im vorgenannten Beispiel auf die Wertangabe ''17.0'' folgende Uhrzeit von ''07:00'' legt nun den Zeitraum von 05:30 Uhr '''bis''' 07:00 Uhr für den dahinter stehenden Temperaturwert von 21.0 fest. Die Abfolge kann dem Einen oder der Anderen unnatürlich vorkommen, aber es ist eine so von eQ3 festgelegte Notationsweise.

'''Beachten Sie bitte''', dass am Schluss der Liste <ins>immer</ins> eine Einstellung für 24:00 notiert sein '''muss'''. Ansonsten quittiert FHEM das Setzen der Liste mit einem solchen Eintrag im Logfile:

<pre>
Last time spec must be 24:00
</pre>

Im FHEM-Logfile-Browser-Tab sollten nach einigen Minuten folgende mehrfach wiederholten Einträge auftauchen:

<pre>
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate CommandAccepted: yes
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate CommandAccepted: yes
...
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate CommandAccepted: yes
</pre>

Wichtig ist ein nachfolgendes "ACK". Steht dort "MISSING ACK", dann wurde der Empfang der Werte vom HM-CC-TC nicht bestätigt und man sollte die TempList noch einmal schicken. Kommt auch nach mehreren Sendeversuchen kein "ACK" sollten Sie in den ''Readings''des Devices die ''TempList''überprüfen (siehe unten), denn es kann sein, dass diese Antwort schlicht nicht empfangen werden konnte, weil der Empfänger gerade anderweitig beschäftigt war, die Einstellungen aber dennoch übernommen wurden. Wird jedoch ein "NACK" vom HM-CC-TC gesendet, dann wurde die Temperaturliste explizit nicht akzeptiert. Kontrollieren Sie in diesem Fall die Korrektheit der Temperaturliste.

Welche Werte '''aktuell eingestellt'''sind, sieht man in den "Readings" des jeweiligen Devices; im obigen Fall also z.B. im linken Menü von FHEM auf den default-Eintrag ''Everything''klicken und dann auf den Eintrag mit dem Namen ''EG.WZ.Heizung''.

== Temperaturlisten (neu) ==

Seit Mitte Oktober 2013 kann man die Temperaturlisten "ressourcenschonender" an einen HM-CC-TC übertragen. Bisher wurde für jeden Tag ein Befehl abgeschickt (siehe obiges Beispiel). Nun kann man, wie beim [[HM-CC-RT-DN Funk-Heizkörperthermostat#Temperaturlisten setzen|HM-CC-RT-DN] (dem Nachfolger des HM-CC-TC), auch alles in ein einziges "Funktelegramm" packen. Dazu das folgende Beispiel (achten Sie bitte auf die Schlüsselwörter "prep" und "exec"):

######################################################
# Temperatur-Liste für Kinderzimmer
# setzen per Aufruf von "{SetTempList_Kind_Heizung}"
######################################################
sub
SetTempList_Kind_Heizung()
{
{ fhem ("set DG.Kind.Heizung_Climate tempListMon prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListTue prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListWed prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListThu prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListFri prep 05:30 19.0 07:00 20.5 15:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListSat prep 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0")};
{ fhem ("set DG.Kind.Heizung_Climate tempListSun exec 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0")};
}
# End SetTempList_Kind_Heizung

Zum Verständnis: Mittels ''prep'' werden die Werte in einen "Puffer" gepackt und sobald ein "exec" auftaucht, wird er Puffer mit dem Nachfolgenden gefüllt und anschließend '''in einem Rutsch''' an den HM-CC-TC geschickt. Dies vermeidet/minimiert Übertragungsprobleme.

== Batteriealarme des HM-CC-VD in Verbindung mit HM-CC-TC ==
1. bei U-Bat. < 2,4 V erscheint im Display des VD und des TC das Batteriesymbol mit '''battery: low''' in den Readings und Events!

2. bei U-Bat. < 2,3 V erscheint im Display des VD zusätzlich '''F4''' mit '''battery: critical''' in den Readings und Events!

Es wird dringend geraten, die Batterien bei battery: low zu tauschen!

== Log-Auszug ==
HM-CC-TC sendet alle 2 Minuten folgenden Statusbericht:

<nowiki>Datum-Zeit <Device Name> T: 17.3 H: 66 
Datum-Zeit <Device Name> measured-temp: 17.3 
Datum-Zeit <Device Name> temperature: 17.3 
Datum-Zeit <Device Name> humidity: 66 
Datum-Zeit <Device Name> actuator: 96 % </nowiki>
Bei Status-Änderungen sendet HM-CC-TC auch entsprechende Meldungen, z.b.:

<nowiki>Datum-Zeit <Device Name> desired-temp: 15.5 </nowiki>

= Probleme =

== Verstellen der Solltemperatur am HM-CC-TC per Drehrad ==

'''Symptom:''' Beim Verstellen der Solltemperatur per seitlichem Drehrad wurde die aktuelle Solltemperatur - '''egal ob''' man hoch oder runter drehte - immer nur in 0,5 °C Schritten '''runter''' gestellt, bis schließlich die Mindesttemperatur von 6,0 °C erreicht war. Weitere Änderungen waren nicht möglich

'''Abhilfe:''' Letztlich half nur das kurzzeitige Entfernen einer Batterie. Das danach für einige Zeit erscheinende Batteriesymbol zeigte den kleinstmöglichen guten Zustand an, in FHEM wurde das ''Reading'' des Batteriezustandes mit ''ok'' ausgegeben (wie in den Logs aber vorher auch). '''Letztlich half aber nur''' das Einsetzen neuer Batterien, denn die o.a. Störung trat nach ca. 2 Stunden erneut auf. Die "alten" Batterien (die, die dem HM-CC-TC ab Werk beilagen) hatten somit eine Nutzungsdauer von knapp 11 Monaten, waren aber auch in einem HM-CC-TC, der mit 4 Stck. HM-Sec-SC (mussten sehr oft "Meldung machen") und 4 Stck. HM-CC-VD gepeert war. ''Ohne Last'' zeigten die beiden alten AA-Batterien eine Spannung von jeweils 1,29 V an.

'''Hinweis:''' Die unter ''Abhilfe'' beschriebene Lösung war leider nur von kurzer Dauer. Bereits kurz danach zeigte der HM-CC-TC die gleichen Ausfallerscheinungen. Bei ELV gibt es das Bauteil für das Drehrad (Inkrementalgeber) als [http://www.elv.de/inkrementalgeber-fuer-fs20-str-fht-8-und-homematic-hm-cc-tc.html Ersatzteil]. Sobald dieses geliefert und ein Reparaturversuch unternommen wurde, wird an dieser Stelle weiter berichtet.

= Firmware =
Aktuelle Firmware-Version: 2.1

= Links =
Anleitung [http://www.elv-downloads.de/service/manuals/76787_76175_HM_Wandthermostat_UM.pdf PDF]

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

GW1 Gewitterwarner

2014-04-26T18:02:41Z

Rohan: /* Test */

'''GW1 - Gewitterwarner'''
Der '''GW1 Gewitterwarner''' von ELV ist ein Sensor zur Erkennung von heranziehenden Gewittern.

== Eigenschaften ==
=== Allgemeines ===
Der Gewitterwarner wird als Bausatz geliefert, dessen Zusammenbau nicht besonders schwierig ist, da alle SMD-Teile bereits fertig gelötet sind. Der Bausatz enthält alle notwendigen Teile inklusive eines fertig bearbeiteten und bedruckten Gehäuses. Er besitzt 3 Schaltausgänge, welche je nach Konfiguration des GW1 per Lötbrücke (J2 offen = statisches Signal, Blitz mit 1 Sekunde oder J2 geschlossen = Impuls von 300 ms Länge) mit einem der folgenden Sender

* HM-SCI-3-FM
* [[HM-PBI-4-FM]]
* HMW-Sen-SC-12-FM
* HMW-Sen-SC-12-DR
* HMW-IO-4-FM
* HMW-IO-12-FM
* HMW-IO-12-Sw7-DR
* HMW-IO-12-Sw14-DR
* FS20 S4M
* FS20 S8M
* FS20 S4UB
* FS20 TFK

zur Integration in Fhem genutzt werden können. Es kommt also darauf an, ob der Sender einen Schalt- oder Tastimpuls verarbeiten kann.

Im folgenden Beispiel wird die Nutzung mit einem [[HM-PBI-4-FM]] dargestellt (J2 also geschlossen). Dabei erfolgt die Verbindung zwischen GW1 und HM-PBI-4-FM nach folgendem Schema:

* schwarz: Masse
* 1: Entwarnung
* 2: Blitz
* 3: Warnung

'''Hinweise:'''

* Der GW1 ist <ins>kein</ins> Blitzorter wie er z.B. bei [http://www.blitzortung.org/Webpages/index.php Blitzortung.org] verwendet wird. Er kann also nicht die Richtung der detektierte Blitze bestimmen.
* Um die Empfindlichkeitswerte (z.B. in einer Umgebung mit stärkeren Störeinflüssen) oder andere Einstellungen zu verändern, sind auf der Platine insgesamt 18 DIP-Schalter angebracht. Die von ELV mitgelieferte (Auf-)Bauanleitung geht nur grob auf die Parameterveränderung ein und verweist auf das [http://www.ams.com/eng/Products/Lightning-Sensor/Franklin-Lightning-Sensor/AS3935 Datenblatt des Herstellers].

=== Techn. Daten ===
Der GW1 beruht auf einem [http://www.elv.de/controller.aspx?cid=758&detail=10&detail2=148 Franklin Lightning Sensor AS3935]. Zu diesem Sensor gibt es einige Links im WWW, vor allem auch zu einer Umsetzung mittels ''Arduino'', jedoch scheint keine dieser Umsetzungen "von Erfolg gekrönt zu sein" (Stand November 2013).

'''Bausatz:'''

* Versorgungsspannung: 5 - 12 V DC (Hohlstecker 3,5 x 1,3 mm, Plus innen)
* Stromaufnahme: 10 mA
* Schaltausgänge: 3 x Open Collector (30 V max., 100 mA max.)
* Schutzart: IP20
* Abmessungen (BxHxT): 40 x 70 x 16 mm
* Gewicht: 33 g

'''Ausgangsmodi''' (nur für alle 3 Ausgänge gemeinsam):

* Dauersignal (statisch, bei Blitz für 1 Sekunde)
* Schaltimpuls mit 300 ms Länge

== Alternativen ==
<ggfls. ergänzen>

== Hinweise zum Betrieb mit FHEM ==
Wie oben geschrieben, wird der GW1 über entsprechende HM- oder FS20-Sender in Fhem eingebunden.

=== HomeMatic ===
Nach dem Zusammenbau des GW1 wurde er nach obigem Schema mit dem [[HM-PBI-4-FM]] verbunden. Die Belegung ist natürlich wahlfrei, nur Masse des GW1 muss mit Masse des HM-PBI-4-FM (schwarzes Kabel) Verbindung haben.

=== FS20 ===
<bitte ergänzen>

=== Test ===
Das "Problem" liegt darin, dass nicht immer Gewitter ist. Es gibt ein Entwickler-Kit vom Hersteller des Sensor-ICs, dem auch ein "Blitzgenerator" beiliegt. Dieses Kit liegt preislich aber "jenseits von Gut und Böse". Schaltnetzteile und Piezo-Feuerzeuge funktionierten auch nicht. Diese erzeugten hier maximal ein Aufleuchten der Störimpuls-LED.

Was hier zum Testen funktioniert hat, ist ein normaler (etwas älterer) Schnurschalter (Wippe), der ein Meanwell-Schaltnetzteil ein- und ausgeschaltet hat. Beim Ein- und Ausschalten kommt es in dem Schalter wohl zu Abriss- bzw. Einschaltfunken. Alternativ zum Schaltnetzteil kann man auch eine Glühlampe (getestet mit einer alten 100 W Glüh"birne") mit dem Wippenschalter betätigen, denn wichtig ist der Wippenschalter, der in der Nähe des GW1 gehalten werden sollte (einige Zentimeter) bzw. dessen Abrissfunken.

'''Vorgehensweise:'''

Beim Einschalten bzw. Anschließen der Spannungsversorgung des GW1 wird nach der Initialisierung zunächst die Meldung "Entwarnung" abgesetzt und von Fhem gelogt.

Nun den GW1 direkt neben dem Wippenschalter legen/halten. Ein Ausschalten erzeugte hier ein kurzes Aufleuchten der Störimpuls-LED am GW1. Ein Einschalten brachte aber (mit ca. 1-sekündiger Verzögerung) die Blitz-LED zum Aufleuchten. Dies konnte mehrmals reproduziert werden. Zudem wurde der Ausgang "Warnung" aktiv.

Nach ca. 15 Minuten ohne Blitzerkennung schaltet der GW1 wieder auf "Entwarnung".

Hier ein Mitschnitt der entsprechenden Log-Datei:

<pre>
2013-12-11_21:13:42 Gewitterwarner battery: ok
2013-12-11_21:13:42 Gewitterwarner CUL_HM_HM_PBI_4_FM_1EFBFC_Btn_01 Short (to broadcast)
2013-12-11_21:14:10 Gewitterwarner battery: ok
2013-12-11_21:14:10 Gewitterwarner CUL_HM_HM_PBI_4_FM_1EFBFC_Btn_03 Short (to broadcast)
2013-12-11_21:14:20 Gewitterwarner battery: ok
2013-12-11_21:14:20 Gewitterwarner CUL_HM_HM_PBI_4_FM_1EFBFC_Btn_02 Short (to broadcast)
2013-12-11_21:14:27 Gewitterwarner battery: ok
2013-12-11_21:14:27 Gewitterwarner CUL_HM_HM_PBI_4_FM_1EFBFC_Btn_02 Short (to broadcast)
2013-12-11_21:14:40 Gewitterwarner battery: ok
2013-12-11_21:14:40 Gewitterwarner CUL_HM_HM_PBI_4_FM_1EFBFC_Btn_02 Short (to broadcast)
2013-12-11_21:14:48 Gewitterwarner battery: ok
2013-12-11_21:14:48 Gewitterwarner CUL_HM_HM_PBI_4_FM_1EFBFC_Btn_02 Short (to broadcast)
2013-12-11_21:30:45 Gewitterwarner battery: ok
2013-12-11_21:30:45 Gewitterwarner CUL_HM_HM_PBI_4_FM_1EFBFC_Btn_01 Short (to broadcast)
</pre>

* Btn_01 => Entwarnung
* Btn_03 => Warnung
* Btn_02 => Blitz wurde erkannt

Der GW1 mitsamt HM-PBI-4-FM wird nun an einen Ort "verfrachtet", wo er weitestgehend ungestört ist und sobald Erfahrungen mit realen Gewittern vorliegen, wird dieser Beitrag entsprechend ergänzt.

== Probleme ==
<ggfls. ergänzen>

== Tipps ==
<ggfls. ergänzen>

== Links ==
* [http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=43718 ELV-Bausatz]
* [http://forum.fhem.de/index.php/topic,15319.0.html Thread im Fhem-Forum]
* [http://www.mikrocontroller.net/search?query=AS3935 Beiträge zum AS3935 auf Mikrocontroller.net]

[[Kategorie:Gewittersensor]]

GW1 Gewitterwarner

2014-04-26T18:00:39Z

Rohan: /* Test */

'''GW1 - Gewitterwarner'''
Der '''GW1 Gewitterwarner''' von ELV ist ein Sensor zur Erkennung von heranziehenden Gewittern.

== Eigenschaften ==
=== Allgemeines ===
Der Gewitterwarner wird als Bausatz geliefert, dessen Zusammenbau nicht besonders schwierig ist, da alle SMD-Teile bereits fertig gelötet sind. Der Bausatz enthält alle notwendigen Teile inklusive eines fertig bearbeiteten und bedruckten Gehäuses. Er besitzt 3 Schaltausgänge, welche je nach Konfiguration des GW1 per Lötbrücke (J2 offen = statisches Signal, Blitz mit 1 Sekunde oder J2 geschlossen = Impuls von 300 ms Länge) mit einem der folgenden Sender

* HM-SCI-3-FM
* [[HM-PBI-4-FM]]
* HMW-Sen-SC-12-FM
* HMW-Sen-SC-12-DR
* HMW-IO-4-FM
* HMW-IO-12-FM
* HMW-IO-12-Sw7-DR
* HMW-IO-12-Sw14-DR
* FS20 S4M
* FS20 S8M
* FS20 S4UB
* FS20 TFK

zur Integration in Fhem genutzt werden können. Es kommt also darauf an, ob der Sender einen Schalt- oder Tastimpuls verarbeiten kann.

Im folgenden Beispiel wird die Nutzung mit einem [[HM-PBI-4-FM]] dargestellt (J2 also geschlossen). Dabei erfolgt die Verbindung zwischen GW1 und HM-PBI-4-FM nach folgendem Schema:

* schwarz: Masse
* 1: Entwarnung
* 2: Blitz
* 3: Warnung

'''Hinweise:'''

* Der GW1 ist <ins>kein</ins> Blitzorter wie er z.B. bei [http://www.blitzortung.org/Webpages/index.php Blitzortung.org] verwendet wird. Er kann also nicht die Richtung der detektierte Blitze bestimmen.
* Um die Empfindlichkeitswerte (z.B. in einer Umgebung mit stärkeren Störeinflüssen) oder andere Einstellungen zu verändern, sind auf der Platine insgesamt 18 DIP-Schalter angebracht. Die von ELV mitgelieferte (Auf-)Bauanleitung geht nur grob auf die Parameterveränderung ein und verweist auf das [http://www.ams.com/eng/Products/Lightning-Sensor/Franklin-Lightning-Sensor/AS3935 Datenblatt des Herstellers].

=== Techn. Daten ===
Der GW1 beruht auf einem [http://www.elv.de/controller.aspx?cid=758&detail=10&detail2=148 Franklin Lightning Sensor AS3935]. Zu diesem Sensor gibt es einige Links im WWW, vor allem auch zu einer Umsetzung mittels ''Arduino'', jedoch scheint keine dieser Umsetzungen "von Erfolg gekrönt zu sein" (Stand November 2013).

'''Bausatz:'''

* Versorgungsspannung: 5 - 12 V DC (Hohlstecker 3,5 x 1,3 mm, Plus innen)
* Stromaufnahme: 10 mA
* Schaltausgänge: 3 x Open Collector (30 V max., 100 mA max.)
* Schutzart: IP20
* Abmessungen (BxHxT): 40 x 70 x 16 mm
* Gewicht: 33 g

'''Ausgangsmodi''' (nur für alle 3 Ausgänge gemeinsam):

* Dauersignal (statisch, bei Blitz für 1 Sekunde)
* Schaltimpuls mit 300 ms Länge

== Alternativen ==
<ggfls. ergänzen>

== Hinweise zum Betrieb mit FHEM ==
Wie oben geschrieben, wird der GW1 über entsprechende HM- oder FS20-Sender in Fhem eingebunden.

=== HomeMatic ===
Nach dem Zusammenbau des GW1 wurde er nach obigem Schema mit dem [[HM-PBI-4-FM]] verbunden. Die Belegung ist natürlich wahlfrei, nur Masse des GW1 muss mit Masse des HM-PBI-4-FM (schwarzes Kabel) Verbindung haben.

=== FS20 ===
<bitte ergänzen>

=== Test ===
Das "Problem" liegt darin, dass nicht immer Gewitter ist. Es gibt ein Entwickler-Kit vom Hersteller des Sensor-ICs, dem auch ein "Blitzgenerator" beiliegt. Dieses Kit liegt preislich aber "jenseits von Gut und Böse". Schaltnetzteile und Piezo-Feuerzeuge funktionierten auch nicht. Diese erzeugten hier maximal ein Aufleuchten der Störimpuls-LED.

Was hier zum Testen funktioniert hat, ist ein normaler (etwas älterer) Schnurschalter (Wippe), der ein Meanwell-Schaltnetzteil ein- und ausgeschaltet hat. Beim Ein- und Ausschalten kommt es in dem Schalter wohl zu Abriss- bzw. Einschaltfunken. Alternativ zum Schaltnetzteil kann man auch eine Glühlampe mit dem Wippenschalter betätigen, denn wichtig ist der Wippenschalter, der in der Nähe des GW1 gehalten werden sollte (einige Zentimeter) bzw. dessen Abrissfunken.

'''Vorgehensweise:'''

Beim Einschalten bzw. Anschließen der Spannungsversorgung des GW1 wird nach der Initialisierung zunächst die Meldung "Entwarnung" abgesetzt und von Fhem gelogt.

Nun den GW1 direkt neben dem Wippenschalter legen/halten. Ein Ausschalten erzeugte hier ein kurzes Aufleuchten der Störimpuls-LED am GW1. Ein Einschalten brachte aber (mit ca. 1-sekündiger Verzögerung) die Blitz-LED zum Aufleuchten. Dies konnte mehrmals reproduziert werden. Zudem wurde der Ausgang "Warnung" aktiv.

Nach ca. 15 Minuten ohne Blitzerkennung schaltet der GW1 wieder auf "Entwarnung".

Hier ein Mitschnitt der entsprechenden Log-Datei:

<pre>
2013-12-11_21:13:42 Gewitterwarner battery: ok
2013-12-11_21:13:42 Gewitterwarner CUL_HM_HM_PBI_4_FM_1EFBFC_Btn_01 Short (to broadcast)
2013-12-11_21:14:10 Gewitterwarner battery: ok
2013-12-11_21:14:10 Gewitterwarner CUL_HM_HM_PBI_4_FM_1EFBFC_Btn_03 Short (to broadcast)
2013-12-11_21:14:20 Gewitterwarner battery: ok
2013-12-11_21:14:20 Gewitterwarner CUL_HM_HM_PBI_4_FM_1EFBFC_Btn_02 Short (to broadcast)
2013-12-11_21:14:27 Gewitterwarner battery: ok
2013-12-11_21:14:27 Gewitterwarner CUL_HM_HM_PBI_4_FM_1EFBFC_Btn_02 Short (to broadcast)
2013-12-11_21:14:40 Gewitterwarner battery: ok
2013-12-11_21:14:40 Gewitterwarner CUL_HM_HM_PBI_4_FM_1EFBFC_Btn_02 Short (to broadcast)
2013-12-11_21:14:48 Gewitterwarner battery: ok
2013-12-11_21:14:48 Gewitterwarner CUL_HM_HM_PBI_4_FM_1EFBFC_Btn_02 Short (to broadcast)
2013-12-11_21:30:45 Gewitterwarner battery: ok
2013-12-11_21:30:45 Gewitterwarner CUL_HM_HM_PBI_4_FM_1EFBFC_Btn_01 Short (to broadcast)
</pre>

* Btn_01 => Entwarnung
* Btn_03 => Warnung
* Btn_02 => Blitz wurde erkannt

Der GW1 mitsamt HM-PBI-4-FM wird nun an einen Ort "verfrachtet", wo er weitestgehend ungestört ist und sobald Erfahrungen mit realen Gewittern vorliegen, wird dieser Beitrag entsprechend ergänzt.

== Probleme ==
<ggfls. ergänzen>

== Tipps ==
<ggfls. ergänzen>

== Links ==
* [http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=43718 ELV-Bausatz]
* [http://forum.fhem.de/index.php/topic,15319.0.html Thread im Fhem-Forum]
* [http://www.mikrocontroller.net/search?query=AS3935 Beiträge zum AS3935 auf Mikrocontroller.net]

[[Kategorie:Gewittersensor]]

FHEM Command Beispiele

2014-01-26T21:03:44Z

Rohan: /* update ... */

'''Beispiele für FHEM-Befehle'''

<ins>Allgemeines</ins>

Dies soll kein Ersatz für die [[FHEM Command Reference]] sein. Es geht hier vorwiegend um voll ausgeschriebene Befehle zum besseren Verständnis. Die ''Command Reference'' listet alle Befehle, Optionen und Möglichkeiten auf, aber manchmal übersieht man in der Vielzahl an Informationen eine Kleinigkeit und schon funktioniert es nicht. Es werden nicht alle Optionen erläutert.

Sofern es im Wiki schon Beiträge gibt, die einzelne Befehle ähnlich diesem Beitrag abhandeln, finden Sie einen Verweis auf diese.
=== at ===
''at'' kann man vergleichen mit den "Geplanten Tasks" (Windows) oder "cron" (Linux). Abhängig von der Uhrzeit (immer um 04:00 Uhr) bzw. abgelaufenen Zeitspannen (alle 5 Minuten) werden weitere Befehle ausgelöst.

* [[AT zu einem absoluten Datum ausführen]]
* [[Sunset Sunrise]]

=== attr ===
Mit ''attr'' weist man einem FHEM-Gerät bestimmte '''Attr'''ibute (Merkmale / Eigenschaften) zu. Weiterhin setzt man damit z.B. auch allgemein gültige (''globale'') Eigenschaften der FHEM-Installation (''latitude'', ''longitude'', ''verbose'').

==== attr global latitude 5X.XYZ ====
Wert für die geographische Breite (früher Breitengrad) setzen. Erforderlich vor Nutzung der Sonnenauf- / Sonnenuntergangsfunktionen (sunrise/sunset usw.)

* [[Sunset Sunrise]]
==== attr global longitude 6.XYZ ====
Wert für die geographischen Länge (früher Längengrad) setzen. Erforderlich vor Nutzung der Sonnenauf- / Sonnenuntergangsfunktionen (sunrise/sunset usw.)

* [[Sunset Sunrise]]
==== attr global verbose X ====
Mit dem Wert "X" legt man die Detailtiefe der mitgeloggten Informationen fest.

Hat X den Wert

* 0 wird nur der Start und das Beenden des FHEM-Servers mitgeschnitten.
* 1 werden zusätzlich Fehlermeldungen und unbekannte Pakete ausgegeben.
* 2 erfolgt eine Ausgabe der wichtigen Ereignisse (events) und Alarmmeldungen.
* 3 werden ausgesendete Befehle geloggt.
* 4 sehen Sie, was von den verschiedenen Geräte empfangen wurde.
* 5 wird alles ausgegeben ("debugging", Fehlersuche)

Ein größerer Wert führt also zu einer höheren Detailtiefe.

Für den '''Normalgebrauch''' wird der Verbose-Level 3 empfohlen.

==== attr <Geräte-Name> ignore X ====
Ausblenden von fremden Geräten aus der FHEM-Konfiguration.

* [[Fremdgeräte ignorieren]]
==== attr <Geräte-Name> room <Raum1>[,Raum2] ====
Über dieses (optionale) Attribut weist man ein FHEM-Gerät einem Raum oder mehreren Räumen zu, der in der linken Spalte der FHEM-Weboberfläche erscheint. Alle diesem Raum zugewiesenen Geräte bzw. FHEM-Einträge tauchen nach einem Klick dieses Raumes dann auf der entsprechenden Raumseite auf.

Mit der erstmaligen Verwendung eines Raumnamens (also neuer Name) wird automatisch dieser Raum erzeugt und in die Raumliste eingefügt.

'''Hinweis:''' Ein evtl. zweiter Raumname ist mit Komma vom ersten Raumnamen zu trennen. Nach dem Komma darf kein Leerzeichen stehen, sonst würde

<pre> attr MeinGerät room Keller, Zentrale
</pre>

einen Raum " Zentrale" erstellen (also mit einem führenden Leerzeichen, das in der FHEM-Raumliste aber nicht sichtbar ist und die Fehlersuche erschwert).

Richtig lautet die o.a. Anweisung also
<pre>
attr MeinGerät room Keller,Zentrale
</pre>
Wenn Sie ein Device einem Raum "..., Zentrale" und ein anderes einem Raum "...,Zentrale" zuweisen, würden in der Raumliste dann 2 Räume mit dem Namen ''Zentrale'' erscheinen.

=== backup ===
* [[Backup]]

=== include ===
Man kann - z.B. aus Gründen der Übersichtlichkeit, Struktur, Ordnung - Teile der ''fhem.cfg'' in separate Dateien auslagern. Mittels des Befehls ''include'' können diese "Auslagerungsdateien" dann wieder in FHEM eingebunden werden.

<ins>Beispiel:</ins> ''include /opt/fhem/FHEM/homematic.cfg''

Ein <ins>Vorteil</ins> - wenn man diese Dateien nicht im selben Ordner wie die ''fhem.cfg''-Datei (hier wäre das ''/opt/fhem/''), sondern in ''/opt/fhem/FHEM/'' speichert - ist, dass diese Dateien dann innerhalb der FHEM-Weboberfläche über den Menüpunkt ''Edit files'' erreichbar (editierbar) sind. Sie stehen dann im Bereich der ''Own modules and helper files''. Ansonsten muss man auf diese Dateien per remote-Sitzung oder einem anderen Programm (SSH / FTP) zugreifen.

'''Hinweis:''' Diese separaten Dateien können per ''rereadcfg <Pfad>/homematic.cfg'' '''einzeln''' wieder eingelesen werden.
Die includes sollten unter der Hardwarekonfiguration (CUL/FHZ/...) in die fhem.cfg hinzugefügt werden, ansonsten bleiben die Aktoren ohne Funktion!

=== list ===
Mittels ''list'' können Sie sich z.B. die Eigenschaften / Auswirkungen eines ''at''-Befehls oder eines Gerätes ausgeben lassen.

* [[Sunset Sunrise]]

=== notify ===
* [[Batterieüberwachung]]
* [[Funktionsbeschreibung zu notify]]

=== reload ===
Eine einzelne Moduldatei soll neu eingelesen werden. Dadurch werden - ohne Neustart - vorgenommene Änderungen in dieser Moduldatei verfügbar.

<ins>Beispiel:</ins> ''reload 99_myUtils''

=== rereadcfg ===
Dieser Befehl, abgesetzt z.B. in der Kommandozeile der FHEM-Oberfläche, veranlasst ein Neueinlesen aller oder einzelner Konfigurationsdateien (*.cfg-Dateien). Im letzteren Fall muss der Name der neu einzulesenden Datei explizit angegeben werden.

=== twilight ===
* [[Twilight Anwendungsbeispiel]]

=== update ... ===
FHEM ab Version 5.3

Syntax:
<pre>
update [development|stable] [<file>|check|fhem|full] [force]
</pre>

'''Hinweise:'''
* Fhem führt (so voreingestellt) ein Backup der bisherigen Installations- '''und''' Konfigurationsdateien vor einem Update durch.
* Lesen Sie aufmerksam die nach dem Update auf dem Monitor erscheinenden Meldungen.
* Nach einem Update ist meist ein ''shutdown restart'' erforderlich.

==== update ====
Die ganze FHEM-Installation wird auf die neueste Version gebracht.

==== update check ====
Es wird angezeigt, was alles neu ist. Es wird nicht installiert.

==== update development ====
Sie führen ein Update auf die in der Entwicklung befindliche FHEM-Version durch. Dies kann dazu führen, dass einiges nicht (mehr) so läuft, wie Sie es gewohnt sind. Für ein bisher stabiles und produktiv eingesetztes FHEM-System sollte daher besser nur der Befehl ''update stable'' genutzt werden. Dazu sollte man aber eins wissen: Es gibt faktisch keinen Unterschied zwischen '''stable''' und '''development''', da nur eine Version gepflegt wird.

==== update force ====
Das Update wird erzwungen (falls es beim regulären ''update'' Probleme geben sollte).

==== update <Dateiname> ====
Mit z.B. ''update 02_HTTPSRV.pm'' installiert man nur eine neue Version der Datei ''02_HTTPSRV.pm''. Alle anderen FHEM-Dateien werden nicht angetastet.

[[Kategorie:FHEM]]

FHEM Command Beispiele

2014-01-26T20:58:33Z

Rohan: /* update development */

'''Beispiele für FHEM-Befehle'''

<ins>Allgemeines</ins>

Dies soll kein Ersatz für die [[FHEM Command Reference]] sein. Es geht hier vorwiegend um voll ausgeschriebene Befehle zum besseren Verständnis. Die ''Command Reference'' listet alle Befehle, Optionen und Möglichkeiten auf, aber manchmal übersieht man in der Vielzahl an Informationen eine Kleinigkeit und schon funktioniert es nicht. Es werden nicht alle Optionen erläutert.

Sofern es im Wiki schon Beiträge gibt, die einzelne Befehle ähnlich diesem Beitrag abhandeln, finden Sie einen Verweis auf diese.
=== at ===
''at'' kann man vergleichen mit den "Geplanten Tasks" (Windows) oder "cron" (Linux). Abhängig von der Uhrzeit (immer um 04:00 Uhr) bzw. abgelaufenen Zeitspannen (alle 5 Minuten) werden weitere Befehle ausgelöst.

* [[AT zu einem absoluten Datum ausführen]]
* [[Sunset Sunrise]]

=== attr ===
Mit ''attr'' weist man einem FHEM-Gerät bestimmte '''Attr'''ibute (Merkmale / Eigenschaften) zu. Weiterhin setzt man damit z.B. auch allgemein gültige (''globale'') Eigenschaften der FHEM-Installation (''latitude'', ''longitude'', ''verbose'').

==== attr global latitude 5X.XYZ ====
Wert für die geographische Breite (früher Breitengrad) setzen. Erforderlich vor Nutzung der Sonnenauf- / Sonnenuntergangsfunktionen (sunrise/sunset usw.)

* [[Sunset Sunrise]]
==== attr global longitude 6.XYZ ====
Wert für die geographischen Länge (früher Längengrad) setzen. Erforderlich vor Nutzung der Sonnenauf- / Sonnenuntergangsfunktionen (sunrise/sunset usw.)

* [[Sunset Sunrise]]
==== attr global verbose X ====
Mit dem Wert "X" legt man die Detailtiefe der mitgeloggten Informationen fest.

Hat X den Wert

* 0 wird nur der Start und das Beenden des FHEM-Servers mitgeschnitten.
* 1 werden zusätzlich Fehlermeldungen und unbekannte Pakete ausgegeben.
* 2 erfolgt eine Ausgabe der wichtigen Ereignisse (events) und Alarmmeldungen.
* 3 werden ausgesendete Befehle geloggt.
* 4 sehen Sie, was von den verschiedenen Geräte empfangen wurde.
* 5 wird alles ausgegeben ("debugging", Fehlersuche)

Ein größerer Wert führt also zu einer höheren Detailtiefe.

Für den '''Normalgebrauch''' wird der Verbose-Level 3 empfohlen.

==== attr <Geräte-Name> ignore X ====
Ausblenden von fremden Geräten aus der FHEM-Konfiguration.

* [[Fremdgeräte ignorieren]]
==== attr <Geräte-Name> room <Raum1>[,Raum2] ====
Über dieses (optionale) Attribut weist man ein FHEM-Gerät einem Raum oder mehreren Räumen zu, der in der linken Spalte der FHEM-Weboberfläche erscheint. Alle diesem Raum zugewiesenen Geräte bzw. FHEM-Einträge tauchen nach einem Klick dieses Raumes dann auf der entsprechenden Raumseite auf.

Mit der erstmaligen Verwendung eines Raumnamens (also neuer Name) wird automatisch dieser Raum erzeugt und in die Raumliste eingefügt.

'''Hinweis:''' Ein evtl. zweiter Raumname ist mit Komma vom ersten Raumnamen zu trennen. Nach dem Komma darf kein Leerzeichen stehen, sonst würde

<pre> attr MeinGerät room Keller, Zentrale
</pre>

einen Raum " Zentrale" erstellen (also mit einem führenden Leerzeichen, das in der FHEM-Raumliste aber nicht sichtbar ist und die Fehlersuche erschwert).

Richtig lautet die o.a. Anweisung also
<pre>
attr MeinGerät room Keller,Zentrale
</pre>
Wenn Sie ein Device einem Raum "..., Zentrale" und ein anderes einem Raum "...,Zentrale" zuweisen, würden in der Raumliste dann 2 Räume mit dem Namen ''Zentrale'' erscheinen.

=== backup ===
* [[Backup]]

=== include ===
Man kann - z.B. aus Gründen der Übersichtlichkeit, Struktur, Ordnung - Teile der ''fhem.cfg'' in separate Dateien auslagern. Mittels des Befehls ''include'' können diese "Auslagerungsdateien" dann wieder in FHEM eingebunden werden.

<ins>Beispiel:</ins> ''include /opt/fhem/FHEM/homematic.cfg''

Ein <ins>Vorteil</ins> - wenn man diese Dateien nicht im selben Ordner wie die ''fhem.cfg''-Datei (hier wäre das ''/opt/fhem/''), sondern in ''/opt/fhem/FHEM/'' speichert - ist, dass diese Dateien dann innerhalb der FHEM-Weboberfläche über den Menüpunkt ''Edit files'' erreichbar (editierbar) sind. Sie stehen dann im Bereich der ''Own modules and helper files''. Ansonsten muss man auf diese Dateien per remote-Sitzung oder einem anderen Programm (SSH / FTP) zugreifen.

'''Hinweis:''' Diese separaten Dateien können per ''rereadcfg <Pfad>/homematic.cfg'' '''einzeln''' wieder eingelesen werden.
Die includes sollten unter der Hardwarekonfiguration (CUL/FHZ/...) in die fhem.cfg hinzugefügt werden, ansonsten bleiben die Aktoren ohne Funktion!

=== list ===
Mittels ''list'' können Sie sich z.B. die Eigenschaften / Auswirkungen eines ''at''-Befehls oder eines Gerätes ausgeben lassen.

* [[Sunset Sunrise]]

=== notify ===
* [[Batterieüberwachung]]
* [[Funktionsbeschreibung zu notify]]

=== reload ===
Eine einzelne Moduldatei soll neu eingelesen werden. Dadurch werden - ohne Neustart - vorgenommene Änderungen in dieser Moduldatei verfügbar.

<ins>Beispiel:</ins> ''reload 99_myUtils''

=== rereadcfg ===
Dieser Befehl, abgesetzt z.B. in der Kommandozeile der FHEM-Oberfläche, veranlasst ein Neueinlesen aller oder einzelner Konfigurationsdateien (*.cfg-Dateien). Im letzteren Fall muss der Name der neu einzulesenden Datei explizit angegeben werden.

=== twilight ===
* [[Twilight Anwendungsbeispiel]]

=== update ... ===
FHEM ab Version 5.3

Syntax:
<pre>
update [development|stable] [<file>|check|fhem|full] [force]
</pre>

==== update ====
Die ganze FHEM-Installation wird auf die neueste Version gebracht.

==== update check ====
Es wird angezeigt, was alles neu ist. Es wird nicht installiert.

==== update development ====
Sie führen ein Update auf die in der Entwicklung befindliche FHEM-Version durch. Dies kann dazu führen, dass einiges nicht (mehr) so läuft, wie Sie es gewohnt sind. Für ein bisher stabiles und produktiv eingesetztes FHEM-System sollte daher besser nur der Befehl ''update stable'' genutzt werden. Dazu sollte man aber eins wissen: Es gibt faktisch keinen Unterschied zwischen '''stable''' und '''development''', da nur eine Version gepflegt wird.

==== update force ====
Das Update wird erzwungen (falls es beim regulären ''update'' Probleme geben sollte).

==== update <Dateiname> ====
Mit z.B. ''update 02_HTTPSRV.pm'' installiert man nur eine neue Version der Datei ''02_HTTPSRV.pm''. Alle anderen FHEM-Dateien werden nicht angetastet.

[[Kategorie:FHEM]]

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

2014-01-26T20:55:03Z

Rohan: /* TempList: Bad format ... */

Beim '''HM-CC-RT-DN''' handelt es sich um einen '''Funk-Heizkörperthermostaten''', der als Nachfolger den [[HM-CC-VD]] ablöst und seit Mitte September 2013 verfügbar ist.

== Vorbemerkungen ==

Im Gegensatz zum Vorgänger misst der HM-CC-RT-DN selbst die Temperatur und verfügt über eine Boost-Funktion. Er braucht zur Steuerung kein separates Raumregelungsgerät mehr und hat eine eigene Fenster-Offen-Erkennung. Laut Aussagen auf der ELV-Produktseite soll ein passender Wandthermostat ([[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]]) "im Laufe des Jahres 2014" erscheinen (eQ3 konkretisiert diese Angabe auf März 2014).

Das Gerät wird seit Anfang Oktober 2013 von Fhem unterstützt (siehe Diskussion im [http://forum.fhem.de/index.php/topic,14738.0.html 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. Zu dem "Wie" kann bisher noch nichts näheres gesagt werden.

'''Achtung:''' Die Solltemperaturen eines HM-CC-RT-DN lassen sich <ins>nicht</ins> durch einen [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]] steuern. Dieser kann höchstens die Ist-Temperatur an den RT weiter geben, damit die Raumtemperatur nicht am RT selbst zur Ventilsteuerung genommen 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
gep'''ee'''rt 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.2 (in CCU2 2.7.8)

== Betrieb mit FHEM ==
Der Funk-Heizkörperthermostat muss zuerst mit Fhem [[HomeMatic_Devices_pairen|gepairt]] werden. Da es den RT noch nicht lange gibt, sollten Sie sicher stellen, dass Fhem aktuell ist (update durchführen).

=== Channels (Kanäle) ===
==== Channel (Kanal) 01 _Weather ====
Dieser Kanal dient zur Einspeisung der "IST-Temperatur", als Sensor kann z.B. ein HomeMatic HM-WDS10-TH-O Funk-Temperatur-/Luftfeuchtesensor OTH dienen.

Befehl zum peeren:
set <thermoSensor> peerChan 0 <rt_Weather> single

==== Channel (Kanal) 02 _Climate ====

==== Channel (Kanal) 03 _WindowRec ====
Hier 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.
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_ClimRT_tr|Channel (Kanal) 04 _ClimRT_tr]] näher beschrieben).

Befehl zum peeren:
set <fenster-sensor> peerChan 0 <rt_WindowRec> single

Zum Löschen von einen peer:
set <fenster-sensor> peerChan 0 <rt_WindowRec> single unset

Der Peer-(Lösch)Vorgang muss auf dem SC/RHS Sensor durch "drücken" der Anlerntaste bestätigt werden.

Temperatur für Windowopen definieren:

set <rt_WindowRec> regSet winOpnTemp 10 <fenster-sensor>

==== Channel (Kanal) 04 _ClimRT_tr ====
Dieser Kanal ist "der" operationelle. Hier kann z.B. die Temperatur eingestellt werden.

'''Temperaturlisten setzen''': um gebündelt die Wunschtemperaturen für eine ganze Woche zu setzen, können, wie beim HM-CC-TC [[HM-CC-TC Funk-Wandthermostat#Temperaturlisten|beschrieben]], Temperaturlisten in der z.B. [[99_myUtils anlegen|99_MyUtils.pm]] angelegt werden. Anders als beim HM-CC-TC sind diese Listen aber nicht auf den Channel ''_Climate'', sondern auf den Channel ''_ClimRT_tr'' zu übertragen.

######################################################
# Temperatur-Liste für Kellertreppe
# setzen per Aufruf von "{SetTempList_UG_Treppe_Heizung}"
# Vorsicht, da kein HM-CC-TC, sondern HM-CC-RT-DN, ist hier ein anderer Channel
# zu nehmen. Zudem wird mit prep|exec gearbeitet, um nicht alle Zeilen als
# einzelnen Befehl zu senden, sondern per "prep" erst alles
# zusammenzufassen und dann per "exec" an das Thermostat zu senden.
# Also als ein einziger Befehl statt sieben. Vermeidet "NACKs"
######################################################
sub
SetTempList_UG_Treppe_Heizung()
{
{ fhem ("set UG.Treppe.Heizung_ClimRT_tr tempListMon prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_ClimRT_tr tempListTue prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_ClimRT_tr tempListWed prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_ClimRT_tr tempListThu prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_ClimRT_tr tempListFri prep 05:30 16.0 07:00 18.0 15:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_ClimRT_tr tempListSat prep 07:00 16.0 09:00 18.0 15:00 18.5 21:00 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_ClimRT_tr tempListSun exec 07:00 16.0 09:00 18.0 15:00 18.5 21:00 19.0 24:00 16.0")};
}
# End SetTempList_UG_Treppe_Heizung
Bitte beachten: Die Zeiten sind jeweils '''bis'''-Zeiten! In o.a. Beispiel regelt der Thermostat also am Wochenende zwischen 7 und 9 Uhr auf 18 Grad!

Sobald die neue/geänderte ''99_MyUtils.pm'' gespeichert ist, können per Fhem-Befehl ''<code>{SetTempList_UG_Treppe_Heizung}</code>'' (also inclusive der geschweiften Klammern) die neuen Temperaturen an den HM-CC-RT-DN gesendet werden.

'''Die interne Fernster auf Erkennung kann man wie folgt abschalten:'''

set <rt_ClimRT_tr> regSet winOpnMode off

==== Channel (Kanal) 05 _ClimaTeam ====
Dieser Kanal dient zum peeren von mehreren RTs untereinander, also wenn z.B. zwei RTs in einem Raum sind und sich synchronisieren sollen. Das funktioniert jedoch nur, wenn die Einstellungsänderungen direkt am Thermostat durchgeführt werden. Änderungen, die in FHEM (bzw. über den Channel 4) durchgeführt werden, werden (nach bisherigen Erkenntnissen firmwarebedingt) nicht unterstützt.

Die Temperaturen werden '''nicht''' ausgetauscht, wenn die Quelle (z.B. Fensterkontakt) 'in der Lage ist' es an alle RTs zu verteilen (so die HM Philosophie).

'''Folgende Änderungen werden "nicht" weitergegeben:'''
* Status der Fensterkontakte
* Temperaturvorgaben der Zentrale
* Temperaturlisten/Wochenplan

'''Folgende Änderungen werden weitergegeben:'''
* Änderung der Temperatur am Handrad
* Boost am Handrad

Befehl zum peeren:
<pre>set <rt1-ClimaTeam> peerChan 0 <rt2-ClimaTeam> single</pre>

==== Channel (Kanal) 06 _remote ====
Kann an eine Fernbedienung gekoppelt werden. Damit lässt sich z.B. mit der +/- Taste die Temperatur einstellen.

Befehl zum peeren:
<pre>set <button> peerChan 0 <rt-remote> single</pre>

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

Im Automode kann man die Temperatur am Einstellrad des RT ändern. Zum nächsten Schaltpunkt wird dies dann überschrieben. Will man dies nicht (z.B. lange Party, ...), kann man auf manuell schalten. Dann bleibt die mit dem Drehregler (oder der Zentrale) eingestellte Temperatur stehen bis ''ultimo''. Es gibt dann noch den Party- oder Urlaubsmodus. In diesen kann man den Automodus für eine gegebene Zeit überschreiben.

==== Modus Auto ====
< bitte ergänzen>

==== Modus Manu ====
< bitte ergänzen>

==== Modus Party (Urlaub) ====

Will man für eine festgesetzte Zeit (Stunden oder Tage) die Temperatur auf einen festen Wert einstellen (z.B. weil man in Urlaub fährt), kann man dies zwar auch durch Änderungen der Temperaturlisten erreichen, einfacher ist aber die Zuweisung über den Urlaubsmodus, da nach dessen Ablaufdatum und -zeitpunkt automatisch wieder zum vorher eingestellten Programm gewechselt wird.

'''Ein Beispiel:'''

<pre>
set HM-CC-RT-DN_ClimRT_tr controlParty 16 06.12.13 16:30 09.12.13 05:00
</pre>

Dadurch wird

* vom 06.12.2013, 16:30 Uhr,
* bis zum 09.12.2013, 05:00 Uhr
* die gewünschte Raumtemperatur auf 16 °C

eingestellt.

'''Hinweise:'''
- Der Befehl muss auf den Channel 4 ("_ClimRT_tr") erfolgen. 
- Es werden nur Uhrzeiten zu jeder vollen oder halben Stunde angenommen (Minuten also 00 oder 30). 

Mit der Funktion "Urlaub" kann man eine ganze Wohnung (also mehrere RT´s) mit nur einem Befehl in den Party-mode versetzen. 
Der Name "Urlaub" kann natürlich frei gewählt werden.
Im Beispiel werden 2 Heizkörper (Treppenhaus und Kammer) angesteuert. 

Zu beachten sind folgende Dinge: 
 

1) Aktuelle Dateien (z.B. 10_CUL_HM) verwenden! 
2) Bei dem partycontrol-Befehl in der Funktion KEIN Komma zwischen den Parametern. 
3) Bei der Funktion die Parameterübergabe definieren ($$$$$) 
 
'''Aufruf:'''
<pre> {Urlaub ("16", "06.12.13", "16:30", "09.12.13" ,"05:00")}
</pre>
 
'''Funktion:''' 
<pre>
my $Urlaub;
sub
Urlaub($$$$$)
{
#lokale Variablendeklaration
my ($temp,$startDate,$startTime,$endDate,$endTime) = @_;
#Sendebefehl für ein HM-CC-RT-DN
{fhem ("set Kammer controlParty $temp $startDate $startTime $endDate $endTime")}

# alternative Schreibweise der Parameter:
{fhem ("set Treppenhaus controlParty @_[0] @_[1] @_[2] @_[3] @_[4]")};
}
</pre>

=== 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 Kommanods. 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 RT muss den Receiver wach halten. Der RT und alle anderen Burst-Devices erwachen bei '''jedem''' Burst (egal für wen) und legen sich dann wieder schlafen.
* jeder Burst-trigger kostet Batterie für '''alle''' Burst-Geräte im System
* wenn Burst enabled ist kostet es dem RT Batteriekapazität

'''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 messages 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 message. 
 
'''ConditionalBurst devices''' 
Devices mit abschaltbarem burst wie z.B. der 'HM-CC-RT-DN', gibt es ein Register burstRx mit dem das burst-erwachen eingestellt werden kann.
Sender, 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 Hminfo kommando 'models' um festzustellen, welche devices welchen mode 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) 
<pre>set WZ1_4 regSet burstRx on </pre>
prüfen mit: 
<pre>get WZ1_4 reg burstRx </pre>
''Nun in FHEM den Burst mode einschalten (sofern nicht burstXmit verwendet wird)'' 
<pre>attr WZ1 burstAccess 1_auto</pre>

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

==Fhem-Log==
=== 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 %

== 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. Nähere Informationen zu dieser Funktion siehe [[FHEM_Command_Beispiele#update_...|hier]].

== Links ==
* [http://www.elv.de/homematic-heizkoerperthermostat-1.html Produktinfo]
* [http://www.elv-downloads.de/Assets/Produkte/10/1051/105155/Downloads/105155_thermostat_um.pdf Bedienungsanleitung (PDF)]
* [http://www.elv-downloads.de/Assets/Produkte/10/1051/105155/Downloads/105155_thermostat_data.pdf Datenblatt (PDF)]
* [http://www.elv-downloads.de/service/manuals/ventilkompatibilitaet.pdf Ventil-Kompatibilitätsliste (PDF)]

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

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

2014-01-26T20:51:04Z

Rohan: /* Bekannte Probleme */

Beim '''HM-CC-RT-DN''' handelt es sich um einen '''Funk-Heizkörperthermostaten''', der als Nachfolger den [[HM-CC-VD]] ablöst und seit Mitte September 2013 verfügbar ist.

== Vorbemerkungen ==

Im Gegensatz zum Vorgänger misst der HM-CC-RT-DN selbst die Temperatur und verfügt über eine Boost-Funktion. Er braucht zur Steuerung kein separates Raumregelungsgerät mehr und hat eine eigene Fenster-Offen-Erkennung. Laut Aussagen auf der ELV-Produktseite soll ein passender Wandthermostat ([[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]]) "im Laufe des Jahres 2014" erscheinen (eQ3 konkretisiert diese Angabe auf März 2014).

Das Gerät wird seit Anfang Oktober 2013 von Fhem unterstützt (siehe Diskussion im [http://forum.fhem.de/index.php/topic,14738.0.html 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. Zu dem "Wie" kann bisher noch nichts näheres gesagt werden.

'''Achtung:''' Die Solltemperaturen eines HM-CC-RT-DN lassen sich <ins>nicht</ins> durch einen [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]] steuern. Dieser kann höchstens die Ist-Temperatur an den RT weiter geben, damit die Raumtemperatur nicht am RT selbst zur Ventilsteuerung genommen 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
gep'''ee'''rt 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.2 (in CCU2 2.7.8)

== Betrieb mit FHEM ==
Der Funk-Heizkörperthermostat muss zuerst mit Fhem [[HomeMatic_Devices_pairen|gepairt]] werden. Da es den RT noch nicht lange gibt, sollten Sie sicher stellen, dass Fhem aktuell ist (update durchführen).

=== Channels (Kanäle) ===
==== Channel (Kanal) 01 _Weather ====
Dieser Kanal dient zur Einspeisung der "IST-Temperatur", als Sensor kann z.B. ein HomeMatic HM-WDS10-TH-O Funk-Temperatur-/Luftfeuchtesensor OTH dienen.

Befehl zum peeren:
set <thermoSensor> peerChan 0 <rt_Weather> single

==== Channel (Kanal) 02 _Climate ====

==== Channel (Kanal) 03 _WindowRec ====
Hier 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.
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_ClimRT_tr|Channel (Kanal) 04 _ClimRT_tr]] näher beschrieben).

Befehl zum peeren:
set <fenster-sensor> peerChan 0 <rt_WindowRec> single

Zum Löschen von einen peer:
set <fenster-sensor> peerChan 0 <rt_WindowRec> single unset

Der Peer-(Lösch)Vorgang muss auf dem SC/RHS Sensor durch "drücken" der Anlerntaste bestätigt werden.

Temperatur für Windowopen definieren:

set <rt_WindowRec> regSet winOpnTemp 10 <fenster-sensor>

==== Channel (Kanal) 04 _ClimRT_tr ====
Dieser Kanal ist "der" operationelle. Hier kann z.B. die Temperatur eingestellt werden.

'''Temperaturlisten setzen''': um gebündelt die Wunschtemperaturen für eine ganze Woche zu setzen, können, wie beim HM-CC-TC [[HM-CC-TC Funk-Wandthermostat#Temperaturlisten|beschrieben]], Temperaturlisten in der z.B. [[99_myUtils anlegen|99_MyUtils.pm]] angelegt werden. Anders als beim HM-CC-TC sind diese Listen aber nicht auf den Channel ''_Climate'', sondern auf den Channel ''_ClimRT_tr'' zu übertragen.

######################################################
# Temperatur-Liste für Kellertreppe
# setzen per Aufruf von "{SetTempList_UG_Treppe_Heizung}"
# Vorsicht, da kein HM-CC-TC, sondern HM-CC-RT-DN, ist hier ein anderer Channel
# zu nehmen. Zudem wird mit prep|exec gearbeitet, um nicht alle Zeilen als
# einzelnen Befehl zu senden, sondern per "prep" erst alles
# zusammenzufassen und dann per "exec" an das Thermostat zu senden.
# Also als ein einziger Befehl statt sieben. Vermeidet "NACKs"
######################################################
sub
SetTempList_UG_Treppe_Heizung()
{
{ fhem ("set UG.Treppe.Heizung_ClimRT_tr tempListMon prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_ClimRT_tr tempListTue prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_ClimRT_tr tempListWed prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_ClimRT_tr tempListThu prep 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_ClimRT_tr tempListFri prep 05:30 16.0 07:00 18.0 15:00 18.5 20:30 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_ClimRT_tr tempListSat prep 07:00 16.0 09:00 18.0 15:00 18.5 21:00 19.0 24:00 16.0")};
{ fhem ("set UG.Treppe.Heizung_ClimRT_tr tempListSun exec 07:00 16.0 09:00 18.0 15:00 18.5 21:00 19.0 24:00 16.0")};
}
# End SetTempList_UG_Treppe_Heizung
Bitte beachten: Die Zeiten sind jeweils '''bis'''-Zeiten! In o.a. Beispiel regelt der Thermostat also am Wochenende zwischen 7 und 9 Uhr auf 18 Grad!

Sobald die neue/geänderte ''99_MyUtils.pm'' gespeichert ist, können per Fhem-Befehl ''<code>{SetTempList_UG_Treppe_Heizung}</code>'' (also inclusive der geschweiften Klammern) die neuen Temperaturen an den HM-CC-RT-DN gesendet werden.

'''Die interne Fernster auf Erkennung kann man wie folgt abschalten:'''

set <rt_ClimRT_tr> regSet winOpnMode off

==== Channel (Kanal) 05 _ClimaTeam ====
Dieser Kanal dient zum peeren von mehreren RTs untereinander, also wenn z.B. zwei RTs in einem Raum sind und sich synchronisieren sollen. Das funktioniert jedoch nur, wenn die Einstellungsänderungen direkt am Thermostat durchgeführt werden. Änderungen, die in FHEM (bzw. über den Channel 4) durchgeführt werden, werden (nach bisherigen Erkenntnissen firmwarebedingt) nicht unterstützt.

Die Temperaturen werden '''nicht''' ausgetauscht, wenn die Quelle (z.B. Fensterkontakt) 'in der Lage ist' es an alle RTs zu verteilen (so die HM Philosophie).

'''Folgende Änderungen werden "nicht" weitergegeben:'''
* Status der Fensterkontakte
* Temperaturvorgaben der Zentrale
* Temperaturlisten/Wochenplan

'''Folgende Änderungen werden weitergegeben:'''
* Änderung der Temperatur am Handrad
* Boost am Handrad

Befehl zum peeren:
<pre>set <rt1-ClimaTeam> peerChan 0 <rt2-ClimaTeam> single</pre>

==== Channel (Kanal) 06 _remote ====
Kann an eine Fernbedienung gekoppelt werden. Damit lässt sich z.B. mit der +/- Taste die Temperatur einstellen.

Befehl zum peeren:
<pre>set <button> peerChan 0 <rt-remote> single</pre>

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

Im Automode kann man die Temperatur am Einstellrad des RT ändern. Zum nächsten Schaltpunkt wird dies dann überschrieben. Will man dies nicht (z.B. lange Party, ...), kann man auf manuell schalten. Dann bleibt die mit dem Drehregler (oder der Zentrale) eingestellte Temperatur stehen bis ''ultimo''. Es gibt dann noch den Party- oder Urlaubsmodus. In diesen kann man den Automodus für eine gegebene Zeit überschreiben.

==== Modus Auto ====
< bitte ergänzen>

==== Modus Manu ====
< bitte ergänzen>

==== Modus Party (Urlaub) ====

Will man für eine festgesetzte Zeit (Stunden oder Tage) die Temperatur auf einen festen Wert einstellen (z.B. weil man in Urlaub fährt), kann man dies zwar auch durch Änderungen der Temperaturlisten erreichen, einfacher ist aber die Zuweisung über den Urlaubsmodus, da nach dessen Ablaufdatum und -zeitpunkt automatisch wieder zum vorher eingestellten Programm gewechselt wird.

'''Ein Beispiel:'''

<pre>
set HM-CC-RT-DN_ClimRT_tr controlParty 16 06.12.13 16:30 09.12.13 05:00
</pre>

Dadurch wird

* vom 06.12.2013, 16:30 Uhr,
* bis zum 09.12.2013, 05:00 Uhr
* die gewünschte Raumtemperatur auf 16 °C

eingestellt.

'''Hinweise:'''
- Der Befehl muss auf den Channel 4 ("_ClimRT_tr") erfolgen. 
- Es werden nur Uhrzeiten zu jeder vollen oder halben Stunde angenommen (Minuten also 00 oder 30). 

Mit der Funktion "Urlaub" kann man eine ganze Wohnung (also mehrere RT´s) mit nur einem Befehl in den Party-mode versetzen. 
Der Name "Urlaub" kann natürlich frei gewählt werden.
Im Beispiel werden 2 Heizkörper (Treppenhaus und Kammer) angesteuert. 

Zu beachten sind folgende Dinge: 
 

1) Aktuelle Dateien (z.B. 10_CUL_HM) verwenden! 
2) Bei dem partycontrol-Befehl in der Funktion KEIN Komma zwischen den Parametern. 
3) Bei der Funktion die Parameterübergabe definieren ($$$$$) 
 
'''Aufruf:'''
<pre> {Urlaub ("16", "06.12.13", "16:30", "09.12.13" ,"05:00")}
</pre>
 
'''Funktion:''' 
<pre>
my $Urlaub;
sub
Urlaub($$$$$)
{
#lokale Variablendeklaration
my ($temp,$startDate,$startTime,$endDate,$endTime) = @_;
#Sendebefehl für ein HM-CC-RT-DN
{fhem ("set Kammer controlParty $temp $startDate $startTime $endDate $endTime")}

# alternative Schreibweise der Parameter:
{fhem ("set Treppenhaus controlParty @_[0] @_[1] @_[2] @_[3] @_[4]")};
}
</pre>

=== 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 Kommanods. 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 RT muss den Receiver wach halten. Der RT und alle anderen Burst-Devices erwachen bei '''jedem''' Burst (egal für wen) und legen sich dann wieder schlafen.
* jeder Burst-trigger kostet Batterie für '''alle''' Burst-Geräte im System
* wenn Burst enabled ist kostet es dem RT Batteriekapazität

'''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 messages 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 message. 
 
'''ConditionalBurst devices''' 
Devices mit abschaltbarem burst wie z.B. der 'HM-CC-RT-DN', gibt es ein Register burstRx mit dem das burst-erwachen eingestellt werden kann.
Sender, 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 Hminfo kommando 'models' um festzustellen, welche devices welchen mode 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) 
<pre>set WZ1_4 regSet burstRx on </pre>
prüfen mit: 
<pre>get WZ1_4 reg burstRx </pre>
''Nun in FHEM den Burst mode einschalten (sofern nicht burstXmit verwendet wird)'' 
<pre>attr WZ1 burstAccess 1_auto</pre>

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

==Fhem-Log==
=== 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 %

== 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. Nähere Informationen siehe [[FHEM_Command_Beispiele#update_...|hier]].

== Links ==
* [http://www.elv.de/homematic-heizkoerperthermostat-1.html Produktinfo]
* [http://www.elv-downloads.de/Assets/Produkte/10/1051/105155/Downloads/105155_thermostat_um.pdf Bedienungsanleitung (PDF)]
* [http://www.elv-downloads.de/Assets/Produkte/10/1051/105155/Downloads/105155_thermostat_data.pdf Datenblatt (PDF)]
* [http://www.elv-downloads.de/service/manuals/ventilkompatibilitaet.pdf Ventil-Kompatibilitätsliste (PDF)]

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