FHEMWiki - Benutzerbeiträge [de]

Kategorie Diskussion:Hardware Typen

2015-02-02T08:24:07Z

Strauch: /* Konsolidierung der Seiten "HomeMatic Type xxx" */

== Konsolidierung der Seiten "HomeMatic Type xxx" ==

Zum Thema "HomeMatic Type xxx", die im Prinzip etwas ähnliches wie die Unterkategorien zu Hardware Typen dargestellt haben, gab es einen Mail-Austausch, den ich zur allgemeinen weiteren Diskussion hierher kopiere: (--[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 18:47, 30. Jan. 2015 (UTC))

:''ich habe die Einrichtung der "HomeMatic Type..."-Seiten in den letzten Wochen/Monaten schon bemerkt ... und nicht wirklich verstanden, was das letztendliche Ziel ist. Es beruhigt mich, dass Du selbst Zweifel daran bekommst, ob das der richtige Ansatz ist - ich fand ihn nämlich nicht sinnvoll, nicht zuletzt, weil er nicht sauber in das Fhem-Wiki interiert werden kann und irgendwie für mich auch generell nicht zum Wiki-Konzept passt.''
:''Ich würde vorschlagen, auf diese neuen/HM-spezifischen Typen zu verzichten und stattdessen die Geräte in die bestehenden Unterkategorien von '''[[:Kategorie:Hardware Typen|Hardware Typen]]''' einzusortieren. Das ist auch jetzt schon möglich und wird für viele andere (auch HomeMatic) Geräte so gemacht.''
:''Die Problematik des aktuellen "HomeMatic Type-"Konzepts kannst Du allein daran erkennen, dass sie nicht sauber untereinander verlinkt sind - eine Sache, die bei Verwendung der Kategorien automatisch funktioniert.''
:''Sollten einzelne HomeMatic Geräte überhaupt nicht in eine der bestehenden Hardware-Typen einzuordnen sein, besteht ja immer noch die Möglichkeit, eine neue Unterkategorie anzulegen - bisher sehe ich die Notwendigkeit noch nicht. Wenn es HomeMatic-spezifische Unterschiede oder Besonderheiten gibt, die sich am Gerätetyp festmachen lassen, würde ich das eher auf einer eigenen Seite (für alle Typen) beschreiben. Diese eine Seite sollte über die HomeMatic Hauptseite (deren Struktur meiner Ansicht nach auch dringend überarbeitet werden müsste) im richtigen Kontext erreichbar sein.''
:''Wir können - und sollten - das gern weiterdiskutieren bevor Du viel weiteren Aufwand in die Seiten steckst. Mein Vorschlag: wenn Du damit einverstanden bist, dann leg doch eine Seite "HomeMatic Hardware Typen - Besonderheiten" (oder ähnlich) an. Hier aber nur die grobe Struktur. Auf der Diskussionsseite zu dieser Seite (oder, falls Dir das lieber ist, auf Deiner Diskussionsseite) sollte dieser Mailthread als Start der Diskussion über das Gesamtkonzept stehen. Dann können auch andere Fhem-Wiki-Benutzer (Krikan war in den letzten Monaten auch recht engagiert, was die Wiki-Struktur und Kategorien angeht, ebenso Tupol vor längerer Zeit) ihre Ideen und Vorschläge einbringen. Ich denke, dann kann das eine runde, verständliche und komplette Sache werden.''

Die ursprüngliche Mail (von [[Benutzer Diskussion:Strauch|"Strauch"]]) war:
:''ich baue gerade am Fhemwiki im Bereich Homematic um. Ich hatte mit Martin irgendwann mal besprochen. Das wir die Gerätegruppen wie Thermostat, Remote, Threestate als Einzelseiten anlegen und dort die Informationen hinterlegen die für alle Geräte dieser Kartegorie zutreffen. Nun glaube ich würde es Sinn machen die entsprechenden Artikel als Subkategorie in Homematic anzulegen. Wie siehst du das? Wenn ja kannst du das entsprechend einrichten?''
:''Hier die vorhanden HomematicTyp Artikel (ich muss noch ein paar hinzufügen):''
::*''HomeMatic Type Blind''
::*''HomeMatic Type Dimmer''
::*''HomeMatic Type MotionDetector''
::*''HomeMatic Type PushButton''
::*''HomeMatic Type Remote''
::*''HomeMatic Type Switch''
::*''HomeMatic Type Thermostat''
::*''HomeMatic Type ThreeState''
::*''HomeMatic Type THSensor''

:''Beim ThermostatTyp bin ich am weitesten: [[HomeMatic Type Thermostat]]''
<hr />
::Also ich hatte die Idee von [[Benutzer Diskussion:Strauch|"Strauch"]] nicht als Konkurenz oder Ergänzung zu der allgemeinen Kategorie Hardware Type verstanden. Ich sehe sie als einen Versuch, '''HomeMatic-spezifische''' Informationen, die zur Zeit über die Seiten mehrerer Hardware Devices verstreut sind, die aber eine ganze Kategorie von HomeMatic Devices betreffen, an einer zentralen stelle zu sammeln. Damit kann vermieden werden, das z.B. Wiki-Updates, die den Umgang mit Temperatur Templates betreffen, im Artikel für jeden Heizungs- und Wandthermostat separat nachgetragen werden müssen (oder eben auch nicht passieren). Durch das sammeln solcher Teile in einem Typen- und HomeMatic-spezifischen Artikel kann dann von den Devices nur noch auf den Artikel verwiesen werden und wenn sich dann was ändert oder besser dokumentiert wird, profitieren alle Artikel davon. (--[[Benutzer:Reibuehl|Reibuehl]] ([[Benutzer Diskussion:Reibuehl|Diskussion]]) 08:23, 31. Jan. 2015 (UTC))
::<hr />
:::Mein Verständnis der neuen Seiten entspricht wohl der Vorstellung von [[Benutzer:Reibuehl]]. Mir ist überhaupt nicht klar, warum dafür neue Kategorien -vor allem als Unterkategorie (oder sollten das Oberkategorien sein?) zu Homeatic- benötigt werden sollten. Es sind Übersichtsseiten für jeweils eine bestimmte Art von Homematic Devices, die auf weitergehend Informationen zu speziellen Homematic-Geräten verlinken; analog meinem (nicht sehr gelungen) Versuch bei EnOcean [[EnOcean_subType]]. Für mich sind die "HomeMatic Type xyz"-Seiten als Grundlagen für Homematic zu verstehen, auf die ich in den Grundlagen-Wikiseiten für Homematic verweisen würde. Eine Zuordnung zu Kategorien "Hardware Type" kann man vornehmen, wenn es eindeutig ist; ansonsten würde ich es lassen und nur eine Zuordnung zur Kategorie "HomeMatic Components" vornehmen. @strauch: Deine Artikel finde ich sehr sinnvoll, auch wenn es hier diese Diskussion gibt. Also aus meiner Sicht bitte unbedingt weitermachen. Vielleicht kannst Du auch einmal eine genaueres Beispiel Deines Kategorien-Wunsches geben--[[Benutzer:Krikan|Krikan]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 12:04, 1. Feb. 2015 (UTC)
:::<hr />
::::Christian, ich habe mir gestern einige der ''HomeMatic Type xxx'' Seiten noch mal genauer angesehen und verstehe jetzt etwas besser, was damit überhaupt erreicht werden soll(te)... und Du hast recht, gedacht war das wohl so, wie [[Benutzer:Reibuehl|Reibuehl]] es beschreibt. Damit wird der Teil meines Vorschlags ''... auf diese neuen/HM-spezifischen Typen zu verzichten...'' hinfällig. Aber: das Konzept hinter den Seiten ist leider nicht offen ersichtlich. Ein Beispiel:
::::Ich habe in [[HomeMatic Type Blind]] eine Korrektur gemacht und dabei festgestellt, dass sich die HomeMatic Types auf das beziehen, was in HMInfo im Resultat des Befehls <code>get myHMInfo models</code> in der Spalte ''subType'' aufgeführt wird. Und das wäre für meine Begriffe im Wiki der richtige "Aufhänger" für die ganzen Informationen. Auf der [[Homematic HMInfo]]-Seite werden aber die HomeMatic Types mit keinem Wort erwähnt (heißen da wohl auch ''subType''?).
::::Insgesamt sind ohnehin viele Informationen zu HomeMatic (bzw. genauer: zu ''HomeMatic in Fhem'') sehr stark aus der Sicht der Implementierung (den Endanwender teilweise nur verwirrende Interna) geschrieben und vernachlässigen die Anwendersicht.
::::Somit: neuer/geänderter [[Kategorie Diskussion:Hardware Typen#HomeMatic Type xxx - Vorschlag zur Strukturierung|Vorschlag ...]] --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 07:54, 2. Feb. 2015 (UTC)
::::<hr />
:::::Hallo, hier ist ja schon eine Menge passiert. Ich hatte dieses Wochenende besuch und konnte vorher nicht reinschauen. Verzeiht mir bitte wenn ich hier irgendwas falsch einrücke oder Kennzeichne, ich hab bisher noch keine Diskussion auf einer Wikiseite gefunden. Das ganze Thema ist mit Sicherheit Erklärungsbedürftig. Ich will es noch mal aus meiner Sicht erklären auch wenn es vielleicht doppelt ist. Homematic Geräte werden in Typen eingeordnet z.B. thermostat und es gibt mehrere Geräte die diesem Typ entsprechen. Also bei Thermostat z.B. die alten und neuen Wandthermostate und Stellregler. Alle Geräte die zu einem Typ gehören haben oft gleiche Einstellungen, Registereinträge und Kanäle. Bisher wurden alle diese Informationen dann 4x mal bei dem jeweiligen Geräte hingeschrieben und das mehr oder weniger unvollständig. Nun ist der Sinn der Typ Seiten diese Informationen die alle Geräte eines Typen gleich betreffen, dort zusammen zufassen. So das die Information immer Aktuell und nicht redudant ist. Und beim Gerät selber nur noch gerätespezifische Sachen.
:::::Wenn ich unten die Tabelle bearbeiten darf, würde ich dort die Subtypen einmal alle auflisten und Beispiele dafür geben worum es sich handelt (Threestate sind z.B. Fenstersensoren, die können 3 Zustände haben (auf, zu, gekippt).
:::::Ich weiß auch diese Typen einzubauen ist eine Menge arbeit und wird auch einiges an Zeit brauchen. Wie man das nun am Besten im Wiki umsetzt übersteigt mein Momentanes Wissen, das war dann auch der Grund mich an Euch zu wenden. Ich wollte das auch stärker untereinander verlinkt haben, damit dies deutlich ist, auch für den Anwender der die Informationen vielleicht direkt beim Gerät und nicht beim Typen sucht. Also war meine Idee 1. Ebene: Homematic Components 2. Ebene Typ 3. Ebene Device.
:::::Die ganzen Typen bassieren darauf, was HMinfo ausspucken kann. Der Typ steht aber auch als attribut bei jedem Device unten drin. Und das ganze auf der Homematicseite zu erleutern wäre auch notwendig. Die Vorschläge zur Strukturierung fände ich gut. Ich sammele mal alle Typen und würde die Tabelle hier kompletieren, wenn ich das darf. ok? Und dann wäre unter Homematic Info ein Infotext fällig. Wie man das dann mit dem untereinander verlinken macht, vielleicht kann mir dabei jemand unter die Arme greifen. Danke für die Diskussion.
:::::--[[Benutzer:Strauch|Strauch]] ([[Benutzer Diskussion:Strauch|Diskussion]]) 08:23, 2. Feb. 2015 (UTC)

=== Zuordnung(sversuch) HomeMatic Type zu "Hardware Typen"-Unterkategorie ===
{| class="wikitable"
|-
! Hardware Typen !! HomeMatic Type !! Bemerkungen / Kommentare
|-
| Rollladensteuerung || HomeMatic Type Blind || ...
|-
| Dimmer || HomeMatic Type Dimmer || ...
|-
| Bewegungs- und Anwesenheitsmelder || HomeMatic Type MotionDetector || ...
|-
| ??? || HomeMatic Type PushButton || ...
|-
| Schalter (Sender) || HomeMatic Type Remote || ...
|-
| Schalter (Empfänger) || HomeMatic Type Switch || ...
|-
| Heizungssteuerung || HomeMatic Type Thermostat || Es gibt auch noch Kategorie Heizungsventile
|-
| ??? || HomeMatic Type ThreeState || Wofür wird dieser Typ benötigt? Ist er relevant für Endanwender?
|-
| Temperatursensoren / Feuchtesensoren || HomeMatic Type THSensor || ...
|-
|}

Ich denke, es ergibt sich schon eine fast vollständige Abdeckung. Es sollte geprüft werden, ob die Information, die derzeit auf einer "HomeMatic Type xxx" Seite steht - falls überhaupt erforderlich - auf die (Unter-)Kategorieseite passen würde. Mit einem HomeMatic-spezifischen Kommentar nur da wo er wirklich nötig ist.

=== HomeMatic Type xxx - Vorschlag zur Strukturierung ===
* Auf [[HomeMatic]] und/oder [[HomeMatic HMInfo]] entweder
** ein Link auf eine (neue) Seite ''HomeMatic Types''
** ein Abschnitt mit einer Liste der möglichen Typen; Links, wenn es eine eigene Seite zu einem Type gibt
* Die ''HomeMatic Type xxx'' Seiten sollten untereinander verlinkt sein; ließe sich wohl am besten mit einer Vorlage / einem Textbaustein machen
* Alle ''HomeMatic Type xxx'' Seiten nach gleichem Schema (Gliederung) aufgebaut
* Das Konzept der ''HomeMatic Type xxx'' Serie sollte "irgendwo" erklärt werden (d.h.: welche Informationen sollen auf diese Seiten? Strikte Vermeidung der Duplizierung von Informationen?)

Außerdem sollten die ''HomeMatic Type xxx'' Seiten in die ''Hardware Typen'' kategorisiert werden (bis auf ''ThreeState...'' vielleicht.

--[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 07:54, 2. Feb. 2015 (UTC)<hr />

Kategorie Diskussion:Hardware Typen

2015-02-02T08:23:42Z

Strauch: Kommentar hinzugefügt

== Konsolidierung der Seiten "HomeMatic Type xxx" ==

Zum Thema "HomeMatic Type xxx", die im Prinzip etwas ähnliches wie die Unterkategorien zu Hardware Typen dargestellt haben, gab es einen Mail-Austausch, den ich zur allgemeinen weiteren Diskussion hierher kopiere: (--[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 18:47, 30. Jan. 2015 (UTC))

:''ich habe die Einrichtung der "HomeMatic Type..."-Seiten in den letzten Wochen/Monaten schon bemerkt ... und nicht wirklich verstanden, was das letztendliche Ziel ist. Es beruhigt mich, dass Du selbst Zweifel daran bekommst, ob das der richtige Ansatz ist - ich fand ihn nämlich nicht sinnvoll, nicht zuletzt, weil er nicht sauber in das Fhem-Wiki interiert werden kann und irgendwie für mich auch generell nicht zum Wiki-Konzept passt.''
:''Ich würde vorschlagen, auf diese neuen/HM-spezifischen Typen zu verzichten und stattdessen die Geräte in die bestehenden Unterkategorien von '''[[:Kategorie:Hardware Typen|Hardware Typen]]''' einzusortieren. Das ist auch jetzt schon möglich und wird für viele andere (auch HomeMatic) Geräte so gemacht.''
:''Die Problematik des aktuellen "HomeMatic Type-"Konzepts kannst Du allein daran erkennen, dass sie nicht sauber untereinander verlinkt sind - eine Sache, die bei Verwendung der Kategorien automatisch funktioniert.''
:''Sollten einzelne HomeMatic Geräte überhaupt nicht in eine der bestehenden Hardware-Typen einzuordnen sein, besteht ja immer noch die Möglichkeit, eine neue Unterkategorie anzulegen - bisher sehe ich die Notwendigkeit noch nicht. Wenn es HomeMatic-spezifische Unterschiede oder Besonderheiten gibt, die sich am Gerätetyp festmachen lassen, würde ich das eher auf einer eigenen Seite (für alle Typen) beschreiben. Diese eine Seite sollte über die HomeMatic Hauptseite (deren Struktur meiner Ansicht nach auch dringend überarbeitet werden müsste) im richtigen Kontext erreichbar sein.''
:''Wir können - und sollten - das gern weiterdiskutieren bevor Du viel weiteren Aufwand in die Seiten steckst. Mein Vorschlag: wenn Du damit einverstanden bist, dann leg doch eine Seite "HomeMatic Hardware Typen - Besonderheiten" (oder ähnlich) an. Hier aber nur die grobe Struktur. Auf der Diskussionsseite zu dieser Seite (oder, falls Dir das lieber ist, auf Deiner Diskussionsseite) sollte dieser Mailthread als Start der Diskussion über das Gesamtkonzept stehen. Dann können auch andere Fhem-Wiki-Benutzer (Krikan war in den letzten Monaten auch recht engagiert, was die Wiki-Struktur und Kategorien angeht, ebenso Tupol vor längerer Zeit) ihre Ideen und Vorschläge einbringen. Ich denke, dann kann das eine runde, verständliche und komplette Sache werden.''

Die ursprüngliche Mail (von [[Benutzer Diskussion:Strauch|"Strauch"]]) war:
:''ich baue gerade am Fhemwiki im Bereich Homematic um. Ich hatte mit Martin irgendwann mal besprochen. Das wir die Gerätegruppen wie Thermostat, Remote, Threestate als Einzelseiten anlegen und dort die Informationen hinterlegen die für alle Geräte dieser Kartegorie zutreffen. Nun glaube ich würde es Sinn machen die entsprechenden Artikel als Subkategorie in Homematic anzulegen. Wie siehst du das? Wenn ja kannst du das entsprechend einrichten?''
:''Hier die vorhanden HomematicTyp Artikel (ich muss noch ein paar hinzufügen):''
::*''HomeMatic Type Blind''
::*''HomeMatic Type Dimmer''
::*''HomeMatic Type MotionDetector''
::*''HomeMatic Type PushButton''
::*''HomeMatic Type Remote''
::*''HomeMatic Type Switch''
::*''HomeMatic Type Thermostat''
::*''HomeMatic Type ThreeState''
::*''HomeMatic Type THSensor''

:''Beim ThermostatTyp bin ich am weitesten: [[HomeMatic Type Thermostat]]''
<hr />
::Also ich hatte die Idee von [[Benutzer Diskussion:Strauch|"Strauch"]] nicht als Konkurenz oder Ergänzung zu der allgemeinen Kategorie Hardware Type verstanden. Ich sehe sie als einen Versuch, '''HomeMatic-spezifische''' Informationen, die zur Zeit über die Seiten mehrerer Hardware Devices verstreut sind, die aber eine ganze Kategorie von HomeMatic Devices betreffen, an einer zentralen stelle zu sammeln. Damit kann vermieden werden, das z.B. Wiki-Updates, die den Umgang mit Temperatur Templates betreffen, im Artikel für jeden Heizungs- und Wandthermostat separat nachgetragen werden müssen (oder eben auch nicht passieren). Durch das sammeln solcher Teile in einem Typen- und HomeMatic-spezifischen Artikel kann dann von den Devices nur noch auf den Artikel verwiesen werden und wenn sich dann was ändert oder besser dokumentiert wird, profitieren alle Artikel davon. (--[[Benutzer:Reibuehl|Reibuehl]] ([[Benutzer Diskussion:Reibuehl|Diskussion]]) 08:23, 31. Jan. 2015 (UTC))
::<hr />
:::Mein Verständnis der neuen Seiten entspricht wohl der Vorstellung von [[Benutzer:Reibuehl]]. Mir ist überhaupt nicht klar, warum dafür neue Kategorien -vor allem als Unterkategorie (oder sollten das Oberkategorien sein?) zu Homeatic- benötigt werden sollten. Es sind Übersichtsseiten für jeweils eine bestimmte Art von Homematic Devices, die auf weitergehend Informationen zu speziellen Homematic-Geräten verlinken; analog meinem (nicht sehr gelungen) Versuch bei EnOcean [[EnOcean_subType]]. Für mich sind die "HomeMatic Type xyz"-Seiten als Grundlagen für Homematic zu verstehen, auf die ich in den Grundlagen-Wikiseiten für Homematic verweisen würde. Eine Zuordnung zu Kategorien "Hardware Type" kann man vornehmen, wenn es eindeutig ist; ansonsten würde ich es lassen und nur eine Zuordnung zur Kategorie "HomeMatic Components" vornehmen. @strauch: Deine Artikel finde ich sehr sinnvoll, auch wenn es hier diese Diskussion gibt. Also aus meiner Sicht bitte unbedingt weitermachen. Vielleicht kannst Du auch einmal eine genaueres Beispiel Deines Kategorien-Wunsches geben--[[Benutzer:Krikan|Krikan]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 12:04, 1. Feb. 2015 (UTC)
:::<hr />
::::Christian, ich habe mir gestern einige der ''HomeMatic Type xxx'' Seiten noch mal genauer angesehen und verstehe jetzt etwas besser, was damit überhaupt erreicht werden soll(te)... und Du hast recht, gedacht war das wohl so, wie [[Benutzer:Reibuehl|Reibuehl]] es beschreibt. Damit wird der Teil meines Vorschlags ''... auf diese neuen/HM-spezifischen Typen zu verzichten...'' hinfällig. Aber: das Konzept hinter den Seiten ist leider nicht offen ersichtlich. Ein Beispiel:
::::Ich habe in [[HomeMatic Type Blind]] eine Korrektur gemacht und dabei festgestellt, dass sich die HomeMatic Types auf das beziehen, was in HMInfo im Resultat des Befehls <code>get myHMInfo models</code> in der Spalte ''subType'' aufgeführt wird. Und das wäre für meine Begriffe im Wiki der richtige "Aufhänger" für die ganzen Informationen. Auf der [[Homematic HMInfo]]-Seite werden aber die HomeMatic Types mit keinem Wort erwähnt (heißen da wohl auch ''subType''?).
::::Insgesamt sind ohnehin viele Informationen zu HomeMatic (bzw. genauer: zu ''HomeMatic in Fhem'') sehr stark aus der Sicht der Implementierung (den Endanwender teilweise nur verwirrende Interna) geschrieben und vernachlässigen die Anwendersicht.
::::Somit: neuer/geänderter [[Kategorie Diskussion:Hardware Typen#HomeMatic Type xxx - Vorschlag zur Strukturierung|Vorschlag ...]] --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 07:54, 2. Feb. 2015 (UTC)
::::<hr />
:::::Hallo, hier ist ja schon eine Menge passiert. Ich hatte dieses Wochenende besuch und konnte vorher nicht reinschauen. Verzeiht mir bitte wenn ich hier irgendwas falsch einrücke oder Kennzeichne, ich hab bisher noch keine Diskussion auf einer Wikiseite gefunden. Das ganze Thema ist mit Sicherheit Erklärungsbedürftig. Ich will es noch mal aus meiner Sicht erklären auch wenn es vielleicht doppelt ist. Homematic Geräte werden in Typen eingeordnet z.B. thermostat und es gibt mehrere Geräte die diesem Typ entsprechen. Also bei Thermostat z.B. die alten und neuen Wandthermostate und Stellregler. Alle Geräte die zu einem Typ gehören haben oft gleiche Einstellungen, Registereinträge und Kanäle. Bisher wurden alle diese Informationen dann 4x mal bei dem jeweiligen Geräte hingeschrieben und das mehr oder weniger unvollständig. Nun ist der Sinn der Typ Seiten diese Informationen die alle Geräte eines Typen gleich betreffen, dort zusammen zufassen. So das die Information immer Aktuell und nicht redudant ist. Und beim Gerät selber nur noch gerätespezifische Sachen.
:::::Wenn ich unten die Tabelle bearbeiten darf, würde ich dort die Subtypen einmal alle auflisten und Beispiele dafür geben worum es sich handelt (Threestate sind z.B. Fenstersensoren, die können 3 Zustände haben (auf, zu, gekippt).
:::::Ich weiß auch diese Typen einzubauen ist eine Menge arbeit und wird auch einiges an Zeit brauchen. Wie man das nun am Besten im Wiki umsetzt übersteigt mein Momentanes Wissen, das war dann auch der Grund mich an Euch zu wenden. Ich wollte das auch stärker untereinander verlinkt haben, damit dies deutlich ist, auch für den Anwender der die Informationen vielleicht direkt beim Gerät und nicht beim Typen sucht. Also war meine Idee 1. Ebene: Homematic Components 2. Ebene Typ 3. Ebene Device.
:::::Die ganzen Typen bassieren darauf, was HMinfo ausspucken kann. Der Typ steht aber auch als attribut bei jedem Device unten drin. Und das ganze auf der Homematicseite zu erleutern wäre auch notwendig. Die Vorschläge zur Strukturierung fände ich gut. Ich sammele mal alle Typen und würde die Tabelle hier kompletieren, wenn ich das darf. ok? Und dann wäre unter Homematic Info ein Infotext fällig. Wie man das dann mit dem untereinander verlinken macht, vielleicht kann mir dabei jemand unter die Arme greifen. Danke für die Diskussion.
--[[Benutzer:Strauch|Strauch]] ([[Benutzer Diskussion:Strauch|Diskussion]]) 08:23, 2. Feb. 2015 (UTC)

=== Zuordnung(sversuch) HomeMatic Type zu "Hardware Typen"-Unterkategorie ===
{| class="wikitable"
|-
! Hardware Typen !! HomeMatic Type !! Bemerkungen / Kommentare
|-
| Rollladensteuerung || HomeMatic Type Blind || ...
|-
| Dimmer || HomeMatic Type Dimmer || ...
|-
| Bewegungs- und Anwesenheitsmelder || HomeMatic Type MotionDetector || ...
|-
| ??? || HomeMatic Type PushButton || ...
|-
| Schalter (Sender) || HomeMatic Type Remote || ...
|-
| Schalter (Empfänger) || HomeMatic Type Switch || ...
|-
| Heizungssteuerung || HomeMatic Type Thermostat || Es gibt auch noch Kategorie Heizungsventile
|-
| ??? || HomeMatic Type ThreeState || Wofür wird dieser Typ benötigt? Ist er relevant für Endanwender?
|-
| Temperatursensoren / Feuchtesensoren || HomeMatic Type THSensor || ...
|-
|}

Ich denke, es ergibt sich schon eine fast vollständige Abdeckung. Es sollte geprüft werden, ob die Information, die derzeit auf einer "HomeMatic Type xxx" Seite steht - falls überhaupt erforderlich - auf die (Unter-)Kategorieseite passen würde. Mit einem HomeMatic-spezifischen Kommentar nur da wo er wirklich nötig ist.

=== HomeMatic Type xxx - Vorschlag zur Strukturierung ===
* Auf [[HomeMatic]] und/oder [[HomeMatic HMInfo]] entweder
** ein Link auf eine (neue) Seite ''HomeMatic Types''
** ein Abschnitt mit einer Liste der möglichen Typen; Links, wenn es eine eigene Seite zu einem Type gibt
* Die ''HomeMatic Type xxx'' Seiten sollten untereinander verlinkt sein; ließe sich wohl am besten mit einer Vorlage / einem Textbaustein machen
* Alle ''HomeMatic Type xxx'' Seiten nach gleichem Schema (Gliederung) aufgebaut
* Das Konzept der ''HomeMatic Type xxx'' Serie sollte "irgendwo" erklärt werden (d.h.: welche Informationen sollen auf diese Seiten? Strikte Vermeidung der Duplizierung von Informationen?)

Außerdem sollten die ''HomeMatic Type xxx'' Seiten in die ''Hardware Typen'' kategorisiert werden (bis auf ''ThreeState...'' vielleicht.

--[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 07:54, 2. Feb. 2015 (UTC)<hr />

HM-CC-TC Funk-Wandthermostat

2015-01-29T14:23:54Z

Strauch: Verlinkung auf HomeMatic Type Thermostat

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

'''Einstellungen und Informationen die alle HomeMatic Thermostat betreffen sind unter [http://www.fhemwiki.de/wiki/HomeMatic_Type_Thermostat#Temperaturlisten|HomeMatic Type Thermostat] zu finden.'''

= 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 mit denen anderer HomeMatic Thermostate verwaltet, siehe [http://www.fhemwiki.de/wiki/HomeMatic_Type_Thermostat#Temperaturlisten|HomeMatic Type Thermostat].
Beim TC ist der Kanal 4 (_Climate) für die Temperaturlisten zuständig.

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

2015-01-29T14:22:36Z

Strauch: in fett

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

'''Einstellungen und Informationen die alle HomeMatic Thermostat betreffen sind unter [http://www.fhemwiki.de/wiki/HomeMatic_Type_Thermostat#Temperaturlisten|HomeMatic Type Thermostat] zu finden.'''

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.

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

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

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

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

== Firmware Update ==
Seit 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-29T14:22:23Z

Strauch: /* Vorbemerkungen */ in fett

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

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

== Vorbemerkungen ==
'''Einstellungen und Informationen die alle HomeMatic Thermostat betreffen sind unter [http://www.fhemwiki.de/wiki/HomeMatic_Type_Thermostat#Temperaturlisten|HomeMatic Type Thermostat] zu finden.'''

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.

== Technische Daten ==

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

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

== Betrieb mit FHEM ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Tastensperre ===

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

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

Rückgängig machen geht per:

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

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

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

abgesetzt werden. Rückgängig wieder per:

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

=== Temperaturlisten ===
Die Temperaturlisten des HM-TC-IT-WM-W-EU werden identisch mit denen anderer HomeMatic Thermostate verwaltet, siehe [http://www.fhemwiki.de/wiki/HomeMatic_Type_Thermostat#Temperaturlisten|HomeMatic Type Thermostat]. Beim HM-TC-IT-WM-W-EU ist der Kanal 4 (_Climate) für die Temperaturlisten zuständig.

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

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

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

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

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

Der hat auch prompt reagiert und die Heizung eingeschaltet:

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

und noch ein wenig Geplauder der vorhandenen Kanäle:

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

== Firmware Update ==
Updates für den HM-TC-IT-WM-W-EU können von der eQ-3 Webseite heruntergeladen werden. Genauere Informationen gibt es unter [[HomeMatic_Firmware_Update]]

== Bekannte Probleme ==
< Bitte ergänzen >

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

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

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

2015-01-29T14:22:03Z

Strauch: /* Vorbemerkungen */ Link auf HomeMatic Type Thermostat

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

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

== Vorbemerkungen ==
Einstellungen und Informationen die alle HomeMatic Thermostat betreffen sind unter [http://www.fhemwiki.de/wiki/HomeMatic_Type_Thermostat#Temperaturlisten|HomeMatic Type Thermostat] zu finden.

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.

== Technische Daten ==

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

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

== Betrieb mit FHEM ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Tastensperre ===

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

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

Rückgängig machen geht per:

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

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

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

abgesetzt werden. Rückgängig wieder per:

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

=== Temperaturlisten ===
Die Temperaturlisten des HM-TC-IT-WM-W-EU werden identisch mit denen anderer HomeMatic Thermostate verwaltet, siehe [http://www.fhemwiki.de/wiki/HomeMatic_Type_Thermostat#Temperaturlisten|HomeMatic Type Thermostat]. Beim HM-TC-IT-WM-W-EU ist der Kanal 4 (_Climate) für die Temperaturlisten zuständig.

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

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

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

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

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

Der hat auch prompt reagiert und die Heizung eingeschaltet:

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

und noch ein wenig Geplauder der vorhandenen Kanäle:

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

== Firmware Update ==
Updates für den HM-TC-IT-WM-W-EU können von der eQ-3 Webseite heruntergeladen werden. Genauere Informationen gibt es unter [[HomeMatic_Firmware_Update]]

== Bekannte Probleme ==
< Bitte ergänzen >

== 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-29T14:21:41Z

Strauch: Link auf Homematic Type Thermostat

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

Einstellungen und Informationen die alle HomeMatic Thermostat betreffen sind unter [http://www.fhemwiki.de/wiki/HomeMatic_Type_Thermostat#Temperaturlisten|HomeMatic Type Thermostat] zu finden.

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.

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

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

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

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

== Firmware Update ==
Seit 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-29T14:17:31Z

Strauch: Angleichen der Struktur an HM-CC-RT-DN

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

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

== Vorbemerkungen ==

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.

== Technische Daten ==

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

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

== Betrieb mit FHEM ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Tastensperre ===

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

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

Rückgängig machen geht per:

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

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

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

abgesetzt werden. Rückgängig wieder per:

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

=== Temperaturlisten ===
Die Temperaturlisten des HM-TC-IT-WM-W-EU werden identisch mit denen anderer HomeMatic Thermostate verwaltet, siehe [http://www.fhemwiki.de/wiki/HomeMatic_Type_Thermostat#Temperaturlisten|HomeMatic Type Thermostat]. Beim HM-TC-IT-WM-W-EU ist der Kanal 4 (_Climate) für die Temperaturlisten zuständig.

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

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

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

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

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

Der hat auch prompt reagiert und die Heizung eingeschaltet:

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

und noch ein wenig Geplauder der vorhandenen Kanäle:

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

== Firmware Update ==
Updates für den HM-TC-IT-WM-W-EU können von der eQ-3 Webseite heruntergeladen werden. Genauere Informationen gibt es unter [[HomeMatic_Firmware_Update]]

== Bekannte Probleme ==
< Bitte ergänzen >

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

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

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

2015-01-29T14:01:22Z

Strauch: /* Betrieb mit FHEM */ Verweis auf Temperaturlisten in Homematic TypeThermostat

'''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 ==
=== Temperaturlisten ===
Die Temperaturlisten des HM-TC-IT-WM-W-EU werden identisch mit denen anderer HomeMatic Thermostate verwaltet, siehe [http://www.fhemwiki.de/wiki/HomeMatic_Type_Thermostat#Temperaturlisten|HomeMatic Type Thermostat]. Beim HM-TC-IT-WM-W-EU ist der Kanal 4 (_Climate) für die Temperaturlisten zuständig.

=== 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-TC Funk-Wandthermostat

2015-01-29T14:00:16Z

Strauch: /* Temperaturlisten */ Link korrigiert

'''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 mit denen anderer HomeMatic Thermostate verwaltet, siehe [http://www.fhemwiki.de/wiki/HomeMatic_Type_Thermostat#Temperaturlisten|HomeMatic Type Thermostat].
Beim TC ist der Kanal 4 (_Climate) für die Temperaturlisten zuständig.

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

2015-01-29T13:59:47Z

Strauch: /* Temperaturprofile */ Infotext Temperaturlisten ausgelagert nach HomeMatic TypeThermostat um doppelte und dreifache Texte zu vermeiden.

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.

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

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

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

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

== Firmware Update ==
Seit 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]]

HomeMatic Type Thermostat

2015-01-29T13:57:19Z

Strauch: /* Templates */ Zusammenführen der Temperaturlistentext von TypeThermostat und HM-CC-RT-DN

<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#InfosHMInfo|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, das 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.

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

====Templates ====
Etwas komfortabler kann man Wochenprogramme in einem File verwalten. Man kann beliebig viele tempaltes erzeugen und diese in einem File ablegen. Diese unterschiedlichen Wochenprogramme kann man den Termostaten 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. Sie 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 Termostaten 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]]

HomeMatic Type Thermostat

2015-01-29T13:50:21Z

Strauch: /* manuell */ prep und exec Erklärung

<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#InfosHMInfo|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, das 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.

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

====Templates ====
Etwas komfortabler kann man Wochenprogramme in einem File verwalten. Man kann beliebig viele tempaltes erzeugen und diese in einem File ablegen. Diese unterschiedlichen Wochenprogramme kann man den Termostaten zuweisen. So kann man ein Wochenprogramm beliebig vielen Thermostaten zuweisen. Bei Änderungen kann man alle betroffenen Thermostate, die das gleiche Template nutzen sollen, erreichen.
=====File erstellen und verwalten =====
Ein File mit den Temperaturlisten (Wochenplänen) muss erzeugt werden.

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

HMInfo unterstützt das speichern allen temperaturlisten in ein File mit [[Homematic_HMInfo#speichern|temperaturListen speichern]]. Dies kann man gut als Startpunkt nutzen. Sie Wochenprogramme sollten in FHEM vorliegen. ggf. mit getConfig auslesen.
=====Templates zuweisen =====
Das Attribut tempListTmpl sollte man allen Termostaten 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.
=====Templates nutzen=====
FHEM bietet die Möglichkeit zu prüfen, ob der Wochenplan im Thermostat dem File entspricht. Außerdem kann man den Wochenplan in das Device schreiben. In beiden Aktionen wird davon ausgegangen, dass die gelesenen Daten aus dem Device in FHEM vorliegen. 
set hk1_Clima tempListTmpl verify
set hk1_Clima tempListTmpl restore
set hk2_Clima tempListTmpl restore
set hk2_Clima tempListTmpl verify
set hk3_Clima tempListTmpl restore

* verify prüft, ob die Listen übereinstimmen
* restore schreibt die Liste in das Device, wenn Unterschiede erkannt werden. Wenn die Daten übereinstimmen wird nichts geschrieben.
Ein verify sofort nach einem restore zumachen ist nicht sinnvoll. Man muss warten, bis das Schreiben beendet ist und die Register wieder aus dem Device gelesen sind.
Für weitere Parameter zum Kommando ist das Kommandref zu empfehlen.
=====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 eienm System mit einem Kommando. Siehe hierzu [[Homematic_HMInfo#Temperaturlisten|HMInfo temperaturlisten]].

[[Kategorie:HomeMatic Components]]

HomeMatic Type Thermostat

2015-01-29T13:49:36Z

Strauch: /* manuell */ Angleichen für alle HomematicThermostate

<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#InfosHMInfo|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, das 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.

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.

Temperaturlisten kann man per Kommando setzen. Man kann es in einer Subroutine zusammenfassen:

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

====Templates ====
Etwas komfortabler kann man Wochenprogramme in einem File verwalten. Man kann beliebig viele tempaltes erzeugen und diese in einem File ablegen. Diese unterschiedlichen Wochenprogramme kann man den Termostaten zuweisen. So kann man ein Wochenprogramm beliebig vielen Thermostaten zuweisen. Bei Änderungen kann man alle betroffenen Thermostate, die das gleiche Template nutzen sollen, erreichen.
=====File erstellen und verwalten =====
Ein File mit den Temperaturlisten (Wochenplänen) muss erzeugt werden.

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

HMInfo unterstützt das speichern allen temperaturlisten in ein File mit [[Homematic_HMInfo#speichern|temperaturListen speichern]]. Dies kann man gut als Startpunkt nutzen. Sie Wochenprogramme sollten in FHEM vorliegen. ggf. mit getConfig auslesen.
=====Templates zuweisen =====
Das Attribut tempListTmpl sollte man allen Termostaten 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.
=====Templates nutzen=====
FHEM bietet die Möglichkeit zu prüfen, ob der Wochenplan im Thermostat dem File entspricht. Außerdem kann man den Wochenplan in das Device schreiben. In beiden Aktionen wird davon ausgegangen, dass die gelesenen Daten aus dem Device in FHEM vorliegen. 
set hk1_Clima tempListTmpl verify
set hk1_Clima tempListTmpl restore
set hk2_Clima tempListTmpl restore
set hk2_Clima tempListTmpl verify
set hk3_Clima tempListTmpl restore

* verify prüft, ob die Listen übereinstimmen
* restore schreibt die Liste in das Device, wenn Unterschiede erkannt werden. Wenn die Daten übereinstimmen wird nichts geschrieben.
Ein verify sofort nach einem restore zumachen ist nicht sinnvoll. Man muss warten, bis das Schreiben beendet ist und die Register wieder aus dem Device gelesen sind.
Für weitere Parameter zum Kommando ist das Kommandref zu empfehlen.
=====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 eienm System mit einem Kommando. Siehe hierzu [[Homematic_HMInfo#Temperaturlisten|HMInfo temperaturlisten]].

[[Kategorie:HomeMatic Components]]

HM-CC-TC Funk-Wandthermostat

2015-01-29T13:46:49Z

Strauch: /* Temperaturlisten */ Auf Homematic TypeThermostat verwiesen. Dort sollen gleiche Informationen für bestimmte Homematic Typen gebündelt werden

'''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 mit denen anderer HomeMatic Thermostate verwaltet, siehe [[http://www.fhemwiki.de/wiki/HomeMatic_Type_Thermostat#Temperaturlisten|HomeMatic Type Thermostat]].
Beim TC ist der Kanal 4 (_Climate) für die Temperaturlisten zuständig.

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

HomeMatic Type motionDetector

2015-01-28T13:47:17Z

Strauch: Aktoren hinzugefügt

HomeMatic Type Dimmer

2015-01-28T13:44:12Z

Strauch: Aktoren hinzugefügt

HomeMatic Type threeStateSensor

2015-01-28T13:42:33Z

Strauch: SCo hinzugefügt

HM-Sec-SCo Tür-Fensterkontakt, optisch

2015-01-28T13:40:29Z

Strauch: /* Technische Daten */

Homematic Funk-Tür-Fensterkontakt, optisch
== Hinweis ==
Wird mit aktiviertem AES ausgeliefert und kann nur mit Gateways die AES unterstützen gepaired werden (HM-LAN-CFG und HM-USB-CFG).

== Features ==

[[Kategorie:HomeMatic Components]]

HM-Sec-SCo Tür-Fensterkontakt, optisch

2015-01-28T13:38:51Z

Strauch: korrektur nicht magnetisch

Homematic Funk-Tür-Fensterkontakt, optisch
== Technische Daten ==
Infos folgen

== Features ==

[[Kategorie:HomeMatic Components]]

HM-Sec-SCo Tür-Fensterkontakt, optisch

2015-01-28T13:37:39Z

Strauch:

Homematic Funk-Tür-Fensterkontakt, optisch
== Technische Daten ==
Infos folgen

== Features ==

[[Kategorie:HomeMatic Components]]
[[Kategorie:Kontaktsensor (magnetisch)]]

HM-Sec-SCo Tür-Fensterkontakt, optisch

2015-01-28T13:37:16Z

Strauch: Start

Homematic Funk-Tür-Fensterkontakt, optisch
== Technische Daten ==
Infos folgen

== Features ==

HomeMatic Type motionDetector

2015-01-28T13:32:27Z

Strauch: Start

HomeMatic Type Remote

2015-01-28T13:32:03Z

Strauch: Start

HomeMatic Type THSensor

2015-01-28T13:31:35Z

Strauch: Start

HomeMatic Type Switch

2015-01-28T13:31:07Z

Strauch: Start

HomeMatic Type Dimmer

2015-01-28T13:28:24Z

Strauch: Start

HomeMatic Type pushButton

2015-01-28T13:27:19Z

Strauch:

HomeMatic Type pushButton

2015-01-28T13:27:05Z

Strauch: Start

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

2015-01-28T13:02:39Z

Strauch: kleinere Korrekturen / Peer Beispiel

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

=== Beispielkonfiguration ===
Ein Master-Slave-Beispiel aus dem [http://forum.fhem.de/index.php/topic,32840.msg253040.html#msg253040 Forum] um einen HM-ES-PMSw1-Pl mit einem HM Aktor zu peeren:

Es gibt 4 Komparator-Channel: Leistung (chn03), Strom (chn04), Spannung (chn05) und Frequenz (chn06). Wenn in Abhängigkeit vom Strom geschaltet werden soll, wird der Strom-Komparator-Channel mit einem Aktor gepeert.

set HM-ES-PMSw1-Pl_Senl peerChan 0 hm_aktor set

Dann wird der Komparator eingestellt. Hier werden die Events konfiguriert die der Komparator an den Aktor senden soll. Eine Übersicht gibt es mit get regList:

list: register | range | peer | description
1: cndTxCycAbove | literal | | cyclic trigger if level is above cndTxDecAbove options:on,off
1: cndTxCycBelow | literal | | cyclic trigger if level is below cndTxCycBelow options:on,off
1: cndTxDecAbove | 0 to 255 | | level for cndTxCycAbove
1: cndTxDecBelow | 0 to 255 | | level for cndTxCycBelow
1: cndTxFalling | literal | | trigger if falling options:on,off
1: cndTxRising | literal | | trigger if rising options:on,off
1: ledOnTime | 0 to 1.275s | | LED ontime
1: sign | literal | | signature (AES) options:on,off
1: transmitTryMax | 1 to 10 | | max message re-transmit
1: txThrHiCur | 0 to 16000mA | | threshold low current
1: txThrLoCur | 0 to 16000mA | | threshold high current
4: expectAES | literal | required | expect AES options:on,off
4: peerNeedsBurst | literal | required | peer expects burst options:on,off

Zuerst musst entschieden werden, was wie geschaltet werden soll: Bei welchem Strom soll ein-/ausgeschaltet werden. Bei positiver oder negativer Flanke. Sollen die Schaltbefehle permanent wiederholt werden, oder nur bei Änderung kommen und welche Schaltwerte sollen bei den Ereignissen gesendet werden.

Beispiel, 2 Events erzeugen:
1. Wenn i von unter 10mA nach über 100mA wechselt, wird ein Event mit dem Wert 200 gesendet (daraus machen wir später im Aktor ein on).
2. Wenn i von über 100mA nach unter 10mA wechselt, wird ein Event mit dem Wert 0 gesendet (daraus machen wir später im Aktor ein off).

Schaltschwellen definieren:

txThrHiCur 100
txThrLoCur 10

Cyclisches Senden abschalten:

cndTxCycAbove off
cndTxCycBelow off

Beide Schaltflanken auswerten, positiv soll anschalten, negativ soll aus schalten:

cndTxFalling on
cndTxRising on

und zum Schluss die Werte setzen, Die der Messsensor bei den Events übermitteln soll. Zur erinnerung: positive Flanke => 200 und negative Flanke => 0:

cndTxDecAbove 200
cndTxDecBelow 0

Danach wird im Aktor festgelegt, was beim eintreffen von den Werten 0,200 geschehen soll.

=== 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 (Default ist "Aus"), kann man wie folgt vorgehen:

# Device auf übliche Weise mit Fhem pairen
# Interne Peers/Register für Fhem aktivieren <code>set <deviceName> regSet intKeyVisib visib</code>
# Erneutes getConfig auf das Device durchführen <code>set <deviceName> getConfig</code>
# Ch01 (Sw) mit Ch05 (SenU) peeren <code>set <deviceName>_SenU peerChan 0 <deviceName>_Sw single set</code>
# Erneutes getConfig auf das Device durchführen <code>set <deviceName> getConfig</code>
# Register auf Ch01 (Sw) setzen <code> set <deviceName>_Sw regSet lgSwJtDlyOff on self01 </code> <code> set <deviceName>_Sw regSet lgSwJtOn on self01 </code> <code> set <deviceName>_Sw regSet shSwJtDlyOff on self01 </code> <code> set <deviceName>_Sw regSet shSwJtOn on self01 </code> <code> set <deviceName>_Sw regSet lgSwJtDlyOff on self05 </code> <code> set <deviceName>_Sw regSet lgSwJtOn on self05 </code> <code> set <deviceName>_Sw regSet shSwJtDlyOff on self05 </code> <code> set <deviceName>_Sw regSet shSwJtOn on self05 </code>
# Register auf Ch05 (SenU) setzen <code> set <deviceName>_SenU regSet cndTxRising on </code> <code> set <deviceName>_SenU regSet txThrHiVlt 200 </code> <code> set <deviceName>_SenU regSet txThrLoVlt 180 </code>

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

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

2015-01-28T12:59:30Z

Strauch: /* Betrieb mit FHEM */ Konfigurationsbeispiel danke an frank

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

=== Beispielkonfiguration ===
Ein Master-Slave-Beispiel aus dem [http://forum.fhem.de/index.php/topic,32840.msg253040.html#msg253040 Forum] um einen HM-ES-PMSw1-Pl mit einem HM Aktor zu peeren:

Es gibt 4 Komparator-channel: Leistung (chn03), Strom (chn04), Spannung (chn05) und Frequenz (chn06). Wenn in Abhängigkeit vom Strom geschaltet werden soll, wird der Strom-Komparator-Channel mit deinem Aktor gepeert.

Dann wird der Komparator eingestellt. Hier werden die Events konfiguriert die der Komparator an den Aktor senden soll. Eine Übersicht gibt es mit get regList:

list: register | range | peer | description
1: cndTxCycAbove | literal | | cyclic trigger if level is above cndTxDecAbove options:on,off
1: cndTxCycBelow | literal | | cyclic trigger if level is below cndTxCycBelow options:on,off
1: cndTxDecAbove | 0 to 255 | | level for cndTxCycAbove
1: cndTxDecBelow | 0 to 255 | | level for cndTxCycBelow
1: cndTxFalling | literal | | trigger if falling options:on,off
1: cndTxRising | literal | | trigger if rising options:on,off
1: ledOnTime | 0 to 1.275s | | LED ontime
1: sign | literal | | signature (AES) options:on,off
1: transmitTryMax | 1 to 10 | | max message re-transmit
1: txThrHiCur | 0 to 16000mA | | threshold low current
1: txThrLoCur | 0 to 16000mA | | threshold high current
4: expectAES | literal | required | expect AES options:on,off
4: peerNeedsBurst | literal | required | peer expects burst options:on,off

Zuerst musst entschieden werden, was wie geschaltet werden soll: Bei welchem Strom soll ein-/ausgeschaltet werden. Bei positiver oder negativer Flanke. Sollen die Schaltbefehle permanent wiederholt werden, oder nur bei Änderung kommen und welche Schaltwerte sollen bei den Ereignissen gesendet werden.

Beispiel, 2 Events erzeugen:
1. Wenn i von unter 10mA nach über 100mA wechselt, wird ein Event mit dem Wert 200 gesendet (daraus machen wir später im Aktor ein on).
2. Wenn i von über 100mA nach unter 10mA wechselt, wird ein Event mit dem Wert 0 gesendet (daraus machen wir später im Aktor ein off).

Schaltschwellen definieren:

txThrHiCur 100
txThrLoCur 10

Cyclisches Senden abschalten:

cndTxCycAbove off
cndTxCycBelow off

Beide Schaltflanken auswerten, positiv soll anschalten, negativ soll aus schalten:

cndTxFalling on
cndTxRising on

und zum Schluss die Werte setzen, Die der Messsensor bei den Events übermitteln soll. Zur erinnerung: positive Flanke => 200 und negative Flanke => 0:

cndTxDecAbove 200
cndTxDecBelow 0

Danach wird im Aktor festgelegt, was beim eintreffen von den Werten 0,200 geschehen soll.

=== 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 (Default ist "Aus"), kann man wie folgt vorgehen:

# Device auf übliche Weise mit Fhem pairen
# Interne Peers/Register für Fhem aktivieren <code>set <deviceName> regSet intKeyVisib visib</code>
# Erneutes getConfig auf das Device durchführen <code>set <deviceName> getConfig</code>
# Ch01 (Sw) mit Ch05 (SenU) peeren <code>set <deviceName>_SenU peerChan 0 <deviceName>_Sw single set</code>
# Erneutes getConfig auf das Device durchführen <code>set <deviceName> getConfig</code>
# Register auf Ch01 (Sw) setzen <code> set <deviceName>_Sw regSet lgSwJtDlyOff on self01 </code> <code> set <deviceName>_Sw regSet lgSwJtOn on self01 </code> <code> set <deviceName>_Sw regSet shSwJtDlyOff on self01 </code> <code> set <deviceName>_Sw regSet shSwJtOn on self01 </code> <code> set <deviceName>_Sw regSet lgSwJtDlyOff on self05 </code> <code> set <deviceName>_Sw regSet lgSwJtOn on self05 </code> <code> set <deviceName>_Sw regSet shSwJtDlyOff on self05 </code> <code> set <deviceName>_Sw regSet shSwJtOn on self05 </code>
# Register auf Ch05 (SenU) setzen <code> set <deviceName>_SenU regSet cndTxRising on </code> <code> set <deviceName>_SenU regSet txThrHiVlt 200 </code> <code> set <deviceName>_SenU regSet txThrLoVlt 180 </code>

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

HM-Dis-WM55 Funk Statusanzeige

2015-01-28T11:21:15Z

Strauch: Fehlerkorrektur

'''HM-Dis-WM55'''

HomeMatic Funk-Statusanzeige WM55

= Features =

'''Technische Daten:'''
* Farbiges OLED-Display mit 128 x 128 RGB-Bildpunkten
* Frei programmierbar über HomeMatic-WebUI
* Dynamische Zuweisung von Anzeigeplätzen, Texten, Zustand von Systemvariablen, Symbolen
* In den Anzeigerahmen integrierte Taster für Anmeldung, Seitenfortschaltung und Auslösen von Zentralenprogrammen, z. B. Abfrage von Fensterzuständen bei Verlassen des Hauses
* Nur 19 mm flach, Schraub- oder Klebmontage, ortsunabhängiger Batteriebetrieb
* Lieferung mit weißem Rahmen, alternativ integrierbar in 55-mm-Installationsrahmen zahlreicher Installationsserien (Berker, ELSO, GIRA, merten, JUNG)

= Allgemeines =
Die Funk-Statusanzeige hat 10 Kanäle (HM-Dis-WM55_Dis_01 bis HM-Dis-WM55_Dis_10). Jedem der Kanäle können 2 Texte zugewiesen werden. Kanal 1 und 2 kommt eine Doppelrolle zu. Sie enthalten sowohl Texte, sind aber auch die beiden Tasten. Und so wird auch die Ausgabe der Displayanzeige auf diese beiden Kanäle gegeben.

Das Display hat 6 Zeilen zur Darstellung.

Die Zeilen können einzeln befüllt und getauscht werden, dies muss nicht in einem Rutsch passieren.

= Probleme =
Es gibt hin und wieder Probleme die Register auszulesen. Abhilfe ist msgrepeat auf 3 zu setzten und hartnäckig bleiben.

= Betrieb mit FHEM =
Das Gerät wird zur Zeit experimentell unterstützt.
msgrepeat sollte auf 3 gestellt werden, sonst gibt es öfters Timeouts:
attr HM-Dis-WM55 msgRepeat 3

Die Kanäle 1 und 2 sollten mit FHEM gepeered (zusätzlich zum pairing) werden
set HM-Dis-WM55_Dis_01 peerBulk <fhemID>01
set HM-Dis-WM55_Dis_02 peerBulk <fhemID>01

Um einen Kanal mit Text zu befüllen dient der text Befehl auf einen Kanal. Es werden beide Texte in einen Kanal gleichzeitig geschrieben. Will ich einen Text tauschen muss ich den anderen mit neu setzten. Für ein Leerzeichen \_ einsetzten
set HM-Dis-WM55_Dis_01 text Fenster\_auf Fenster\_zu

zum Übernehmen der Konfiguration den Config Taster auf der Rückseite nehmen und über das Menü übernehmen

Nun kann man z.B. mit einem notify die Information an den Schalter senden, wenn ein Fenster offen und oder zu ist:
set HM-Dis-WM55_Dis_01 displayWM short line2 txt01_1 red error

short bedeutet bei einem kurzen Tastendruck (es geht auch long). line bezieht sich auf die Zeile in die es geschrieben wird. Anschließend folgt der Text, die Farbe in der der Text angezeigt werden soll, sowie das Icon.

Mit
set HM-Dis-WM55_Dis_01 displayWM help
kann eine Übersicht der gesetzten Texte angezeigt werden. Sowie der möglichen Farben und Icons.

Folgende Farben und Icons gibt es:
color is one white, red, orange, yellow, green, blue
icon is one closed, error, ic12, ic13, info, newMsg, noIcon, off, ok, on, open, serviceMsg, sigGreen, sigYellow, sigred

Soll kein Text eingeblendet werden oder dieser nicht geändert werden kann man einfach nc schreiben Beispiel
set HM-Dis-WM55_Dis_01 displayWM short line2 nc nc error
Dann wird nur das Icon getauscht oder eben nur jenes angezeigt.

= Links =
http://forum.fhem.de/index.php/topic,29128.0.html

[[Kategorie:Schalter (Sender)]]
[[Kategorie:Schalter (Empfänger)]]
[[Kategorie:HomeMatic Components]]

HM-Dis-WM55 Funk Statusanzeige

2015-01-28T11:20:54Z

Strauch: /* Allgemeines */

'''HM-Dis-WM55'''

HomeMatic Funk-Statusanzeige WM55

= Features =

'''Technische Daten:'''
* Farbiges OLED-Display mit 128 x 128 RGB-Bildpunkten
* Frei programmierbar über HomeMatic-WebUI
* Dynamische Zuweisung von Anzeigeplätzen, Texten, Zustand von Systemvariablen, Symbolen
* In den Anzeigerahmen integrierte Taster für Anmeldung, Seitenfortschaltung und Auslösen von Zentralenprogrammen, z. B. Abfrage von Fensterzuständen bei Verlassen des Hauses
* Nur 19 mm flach, Schraub- oder Klebmontage, ortsunabhängiger Batteriebetrieb
* Lieferung mit weißem Rahmen, alternativ integrierbar in 55-mm-Installationsrahmen zahlreicher Installationsserien (Berker, ELSO, GIRA, merten, JUNG)

= Allgemeines =
Die Funk-Statusanzeige hat 10 Kanäle (HM-Dis-WM55_Dis_01 bis HM-Dis-WM55_Dis_10). Jedem der Kanäle können 2 Texte zugewiesen werden. Kanal 1 und 2 kommt eine Doppelrolle zu. Sie enthalten sowohl Texte, sind aber auch die beiden Tasten. Und so wird auch die Ausgabe der Displayanzeige auf diese beiden Kanäle gegeben.

Das Display hat 6 Zeilen zur Darstellung.

Die Zeilen können einzeln befüllt und getauscht werden, dies muss nicht in einem Rutsch passieren.

= Probleme =
Es gibt hin und wieder Probleme die Register auszulesen. Abhilfe ist msgrepeat auf 3 zu setzten und hartnäckig bleiben.

= Betrieb mit FHEM =
Das Gerät wird zur Zeit experimentell unterstützt.
msgrepeat sollte auf 3 gestellt werden, sonst gibt es öfters Timeouts:
attr HM-Dis-WM55 msgRepeat 3

Die Kanäle 1 und 2 sollten mit FHEM gepeered (zusätzlich zum pairing) werden
set HM-Dis-WM55_Dis_01 peerBulk <fhemID>01
set HM-Dis-WM55_Dis_02 peerBulk <fhemID>01

Um einen Kanal mit Text zu befüllen dient der text Befehl auf einen Kanal. Es werden beide Texte in einen Kanal gleichzeitig geschrieben. Will ich einen Text tauschen muss ich den anderen mit neu setzten. Für ein Leerzeichen \_ einsetzten
set HM-Dis-WM55_Dis_01 text Fenster\_auf Fenster\_zu

zum Übernehmen der Konfiguration den Config Taster auf der Rückseite nehmen und über das Menü übernehmen

Nun kann man z.B. mit einem notify die Information an den Schalter senden, wenn ein Fenster offen und oder zu ist:
set HM-Dis-WM55_Dis_01 displayWM short line2 txt03_1 red error

short bedeutet bei einem kurzen Tastendruck (es geht auch long). line bezieht sich auf die Zeile in die es geschrieben wird. Anschließend folgt der Text, die Farbe in der der Text angezeigt werden soll, sowie das Icon.

Mit
set HM-Dis-WM55_Dis_01 displayWM help
kann eine Übersicht der gesetzten Texte angezeigt werden. Sowie der möglichen Farben und Icons.

Folgende Farben und Icons gibt es:
color is one white, red, orange, yellow, green, blue
icon is one closed, error, ic12, ic13, info, newMsg, noIcon, off, ok, on, open, serviceMsg, sigGreen, sigYellow, sigred

Soll kein Text eingeblendet werden oder dieser nicht geändert werden kann man einfach nc schreiben Beispiel
set HM-Dis-WM55_Dis_01 displayWM short line2 nc nc error
Dann wird nur das Icon getauscht oder eben nur jenes angezeigt.

= Links =
http://forum.fhem.de/index.php/topic,29128.0.html

[[Kategorie:Schalter (Sender)]]
[[Kategorie:Schalter (Empfänger)]]
[[Kategorie:HomeMatic Components]]

HM-Dis-WM55 Funk Statusanzeige

2015-01-28T11:15:43Z

Strauch: Zusammenfassung der bisherigen Ergebnisse

'''HM-Dis-WM55'''

HomeMatic Funk-Statusanzeige WM55

= Features =

'''Technische Daten:'''
* Farbiges OLED-Display mit 128 x 128 RGB-Bildpunkten
* Frei programmierbar über HomeMatic-WebUI
* Dynamische Zuweisung von Anzeigeplätzen, Texten, Zustand von Systemvariablen, Symbolen
* In den Anzeigerahmen integrierte Taster für Anmeldung, Seitenfortschaltung und Auslösen von Zentralenprogrammen, z. B. Abfrage von Fensterzuständen bei Verlassen des Hauses
* Nur 19 mm flach, Schraub- oder Klebmontage, ortsunabhängiger Batteriebetrieb
* Lieferung mit weißem Rahmen, alternativ integrierbar in 55-mm-Installationsrahmen zahlreicher Installationsserien (Berker, ELSO, GIRA, merten, JUNG)

= Allgemeines =
Die Funk-Statusanzeige hat 10 Kanäle (HM-Dis-WM55_Dis_01 bis HM-Dis-WM55_Dis_10). Jedem der Kanäle können 2 Texte zugewiesen werden. Kanal 1 und 2 kommt eine Doppelrolle zu. Sie enthalten sowohl Texte, sind aber auch die beiden Tasten. Und so wird auch die Ausgabe der Displayanzeige auf diese beiden Kanäle gegeben.

Das Display hat 6 Zeilen zur Darstellung

= Probleme =
Es gibt hin und wieder Probleme die Register auszulesen. Abhilfe ist msgrepeat auf 3 zu setzten und hartnäckig bleiben.

= Betrieb mit FHEM =
Das Gerät wird zur Zeit experimentell unterstützt.
msgrepeat sollte auf 3 gestellt werden, sonst gibt es öfters Timeouts:
attr HM-Dis-WM55 msgRepeat 3

Die Kanäle 1 und 2 sollten mit FHEM gepeered (zusätzlich zum pairing) werden
set HM-Dis-WM55_Dis_01 peerBulk <fhemID>01
set HM-Dis-WM55_Dis_02 peerBulk <fhemID>01

Um einen Kanal mit Text zu befüllen dient der text Befehl auf einen Kanal. Es werden beide Texte in einen Kanal gleichzeitig geschrieben. Will ich einen Text tauschen muss ich den anderen mit neu setzten. Für ein Leerzeichen \_ einsetzten
set HM-Dis-WM55_Dis_01 text Fenster\_auf Fenster\_zu

zum Übernehmen der Konfiguration den Config Taster auf der Rückseite nehmen und über das Menü übernehmen

Nun kann man z.B. mit einem notify die Information an den Schalter senden, wenn ein Fenster offen und oder zu ist:
set HM-Dis-WM55_Dis_01 displayWM short line2 txt03_1 red error

short bedeutet bei einem kurzen Tastendruck (es geht auch long). line bezieht sich auf die Zeile in die es geschrieben wird. Anschließend folgt der Text, die Farbe in der der Text angezeigt werden soll, sowie das Icon.

Mit
set HM-Dis-WM55_Dis_01 displayWM help
kann eine Übersicht der gesetzten Texte angezeigt werden. Sowie der möglichen Farben und Icons.

Folgende Farben und Icons gibt es:
color is one white, red, orange, yellow, green, blue
icon is one closed, error, ic12, ic13, info, newMsg, noIcon, off, ok, on, open, serviceMsg, sigGreen, sigYellow, sigred

Soll kein Text eingeblendet werden oder dieser nicht geändert werden kann man einfach nc schreiben Beispiel
set HM-Dis-WM55_Dis_01 displayWM short line2 nc nc error
Dann wird nur das Icon getauscht oder eben nur jenes angezeigt.

= Links =
http://forum.fhem.de/index.php/topic,29128.0.html

[[Kategorie:Schalter (Sender)]]
[[Kategorie:Schalter (Empfänger)]]
[[Kategorie:HomeMatic Components]]

HM-Dis-WM55 Funk Statusanzeige

2014-12-21T14:54:25Z

Strauch:

HM-Dis-WM55 Funk Statusanzeige

2014-12-21T14:53:48Z

Strauch:

HM-Dis-WM55 Funk Statusanzeige

2014-12-21T14:53:34Z

Strauch: Einstieg

'''HM-OU-LED16'''

HomeMatic Funk-Statusanzeige WM55

= Features =

'''Technische Daten:'''
* Farbiges OLED-Display mit 128 x 128 RGB-Bildpunkten
* Frei programmierbar über HomeMatic-WebUI
* Dynamische Zuweisung von Anzeigeplätzen, Texten, Zustand von Systemvariablen, Symbolen
* In den Anzeigerahmen integrierte Taster für Anmeldung, Seitenfortschaltung und Auslösen von Zentralenprogrammen, z. B. Abfrage von Fensterzuständen bei Verlassen des Hauses
* Nur 19 mm flach, Schraub- oder Klebmontage, ortsunabhängiger Batteriebetrieb
* Lieferung mit weißem Rahmen, alternativ integrierbar in 55-mm-Installationsrahmen zahlreicher Installationsserien (Berker, ELSO, GIRA, merten, JUNG)

= Allgemeines =

= Hinweise zur Inbetriebnahme und Installation =

= Probleme =

= Betrieb mit FHEM =
Wird zur Zeit nicht unterstützt

== event Monitor ==

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

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

<Bitte ergänzen>
= Links =

[[Kategorie:Schalter (Sender)]]
[[Kategorie:Schalter (Empfänger)]]
[[Kategorie:HomeMatic Components]]

HM-SEC-SC Tür-Fensterkontakt

2014-11-29T10:11:47Z

Strauch: /* Problembehebung */

Homematic Funk-Tür-Fensterkontakt
== Technische Daten ==
Aktuelle Firmware: 2.1

== Features ==
Überwachung einer Tür oder eines Fensters zur Sicherheit oder um automatisch, bei vorhandenem [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]], die Heizung herunter zu regeln, sobald ein Fenster oder eine Tür geöffnet wird.

== Hinweise zum Betrieb mit FHEM ==
===Pairing===
Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden. Der Sensor muss hierfür geöffnet und die versenkte Anlerntaste mit einem spitzen Gegenstand betätigt werden. Bei erfolgreichem Pairing blinkt die LED grün.

===Nutzung mit Wandthermostat===
Bei Einsatz mit [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]] und Zentrale erst alle Tür-/Fensterkontakte mit dem HM-CC-TC verbinden (anlernen). Alternativ geht das auch nachträglich über entsprechende ''set''-Befehle von Fhem aus. Dafür müssen der HM-CC-TC und der HM-Sec-SC aber vorher mit Fhem gepairt worden sein.

Wenn ein bereits erfolgreich gepairter SC ein ''set <HM-Sec-SC-Name> getConfig'' beim anschließenden Drücken der Anlerntaste am SC mit einem lang andauernden Blinken der LED in orange mit anschließendem Leuchten der LED in rot (ca. 1 Sekunde) beantwortet wird, hilft meist ein ''set <HM-Sec-SC-Name> clear readings'', Anlernknopf drücken, nun wieder ''set <HM-Sec-SC-Name> getConfig'' und Anlernknopf drücken.

Dies sollte nun mit einem kurzen LED-Signal in orange mit anschließendem längeren Flackern der LED in grün beantwortet werden und nach einem Refresh der Browser-Seite sollten alle aktuellen Daten zum SC verfügbar sein.

===Batteriestatus aktivieren===
Der HM-SEC-SC sendet nur dann Batteriestatus, wenn der Sensor selber geöffnet wird (Batteriefach), nicht jedoch wenn er schaltet, noch in wiederkehrenden Abständen. Um dies zu ändern muss das Register cyclicInfoMsg auf on gesetzt werden.

Dazu wie folgt vorgehen:
in Fhem (Telnet oder Webfrontend)
get NameMeines_HM-SEC-SC reg all
set NameMeines_HM-SEC-SC regSet cyclicInfoMsg on
eingeben. Danach siehst man beim Device, dass mindestens ein Kommando pendig ist und in den Readings, dass das cyclicInfoMsg Register geschrieben werden soll.
Danach Fhem in den pairing modus versetzten, z.B. mit:
set HMLAN1 hmPairForSec 30
und den Knopf im Batteriefach des HM-SEC-SC drücken (Büroklammer).
Danach noch mal
get NameMeines_HM-SEC-SC reg all
in Fhem (Telnet oder WEbfrontend).
Jetzt sollten keine pendig commands mehr zu sehen sein und in den readings genau
R-cyclicInfoMsg on
stehen.

Danach bekommst man regelmäßig (etwa alle 24 Stunden) eine Batteriestatusmeldung, wenn der HM-SEC-SC Tür-Fensterkontakt etwa 24 Stunden lang '''nicht''' betätigt wurde.
(wenn er betätigt wurde erfolgt keine Meldung, da die erfolgreiche Betätigungsmeldung zeigt, das die Batterie noch in Ordnung ist).
Ohne diese Aktivierung kann auch der ActionDetector für dieses Geräte möglicherweise nicht verwendet werden.

Achtung: Hierdurch steigt der Batterieverbrauch etwas an, besonders wenn der HM-SEC-SC Tür-Fensterkontakt normalerweise sehr selten betätigt wird. Erfahrungswerte liegen hier zu aber nicht vor.

Vergleiche auch [[HomeMatic_Type_ThreeState]]

=== FHEM Config-Auszug ===
Ein exemplarischer Auszug aus der fhem.cfg:

define TuerKeller CUL_HM 1638AC
attr TuerKeller devInfo 810101
attr TuerKeller firmware 2.0
attr TuerKeller hmClass sender
attr TuerKeller model HM-SEC-SC
attr TuerKeller room Keller
attr TuerKeller serialNr IEQ0xxxxxx
attr TuerKeller subType threeStateSensor

== Hinweise zum Peeren mit HM-CC-TC ==
* Nur wenn der HM-Sec-SC mit einem [[HM-CC-TC_Funk-Wandthermostat|HM-CC-TC]] direkt gep'''ee'''rt wurde, steuert letzterer die Absenkung der Temperatur an den [[HM-CC-VD]]-Ventilen. Ansonsten muss diese Steuerung von FHEM erfolgen.
* Das P'''ee'''ren des SC mit einem CC <ins>mittels Anlerntaste</ins> muss vor dem P'''ai'''ren des TC mit FHEM/HMLAN erfolgen, sonst geht das Peeren nur noch über FHEM-Befehle.

* In der Anleitung des HM-Sec-SC steht:

<nowiki>Um den Tür-Fensterkontakt in den Anlernmodus zu bringen, drücken Sie mit einem spitzen Gegenstand auf die Anlerntaste.
Die Geräte-LED blinkt orange. (Abbruch durch kurze Betätigung der Anlerntaste, die Geräte-LED leuchtet dann rot auf.)"</nowiki>

Falls die LED nicht orange, sondern nach dem ersten Drücken rot blinkt, Knopf erneut drücken. Zumindest bei manchen Geräten lässt sich nur so ein Pairen mit den [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]] durchgeführen (Geräte-LED blinkt orange)

=== Problembehebung ===
Falls trotz korrekt gepeertem Fensterkontakt mit einem HM-CC-RT-DN oder HM-TC-IT-WM-W-EU die LED einen Fehler meldet (rot leuchtet). Überprüft im Fensterkontakt ob das Register "PeerNeedsBurst" gesetzt ist und im Wandthermostat bzw. Heizkörperregler das Attribut BurstAccess auf Auto.

PeerNeedsBurst kann mit folgendem Befehl gesetzt werden:
set <HM-SEC-SC> regSet peerNeedsBurst on <RT_oder_TC>_WindowRec

Danach muss entweder der Kontakt geschaltet werden (HM-SEC-SC-2) oder der Anlernknopf gedrückt werden (HM-SEC-SC)

== Mögliche Zustände ==
Der Sensor hat folgende Schaltzustände:

closed -> Der Sensor zeigt einen geschlossenen Zustand an
open -> Der Sensor zeigt einen geöffneten Zustand an
cover: open -> Das Gehäuse des Sensors wurde geöffnet
cover: closed -> Das Gehäuse des Sensors wurde geschlossen
alive: yes -> Wenn der SC über 24 Std. keine Statusänderung hatte, sendet er ein "Lebenszeichen" an Fhem
sabotage -> ?

Die Änderungen der Zustände werden unmittelbar nach Statusänderung an Fhem / die Zentrale bzw. die gepeerten HM-CC-TC gemeldet.

=== Log-Auszüge ===
In FHEM sind folgende Zustände des HM-SEC-SC im Log zu sehen:

2012-02-13_21:52:02 TuerKeller cover: open
2012-02-13_21:52:02 TuerKeller sabotage
2012-02-13_21:55:23 TuerKeller cover: closed
2012-02-13_21:55:23 TuerKeller alive: yes
2012-02-13_21:55:52 TuerKeller closed (to broadcast)
2012-02-13_21:55:53 TuerKeller open (to broadcast)

Wenn der HM-SEC-SC mit einem HM-CC-TC gepeert ist, sehen die Meldungen auch so aus:

YYYY-MM-TT_HH:mm:ss CUL_HM_threeStateSensor_XYZXYZ contact: open (to HMLAN1)
YYYY-MM-TT_HH:mm:ss CUL_HM_threeStateSensor_XYZXYZ open
YYYY-MM-TT_HH:mm:ss CUL_HM_threeStateSensor_XYZXYZ contact: open (to CUL_HM_thermostat_ZYXZYX)

und

YYYY-MM-TT_HH:mm:ss CUL_HM_threeStateSensor_XYZXYZ contact: closed (to HMLAN1)
YYYY-MM-TT_HH:mm:ss CUL_HM_threeStateSensor_XYZXYZ closed
YYYY-MM-TT_HH:mm:ss CUL_HM_threeStateSensor_XYZXYZ contact: closed (to CUL_HM_thermostat_ZYXZYX)

wobei hier für den SC und TC noch keine Aliase vergeben wurden.

Zusätzlich, wenn die Knopfzellen (2 Stück, Typ LR44, Sollspannung 1,5 V) nachlassen:

2012-02-13_21:55:53 TuerKeller battery: low

was ansonsten so aussieht:

2012-02-13_21:55:53 TuerKeller battery: ok

== Batterien ==
Es werden 2 Stück Knopfzellen vom Typ LR44 (je nach Hersteller auch L1154, AG13, V13GA, A76 oder GPA76 genannt) benötigt. Diese sind Bestandteil der Lieferung, jedoch sollte man vor Installation / Inbetriebnahme die Spannung der Knopfzellen überprüfen. Diese sollte über 1,5 V liegen. Da Batterien eine begrenzte Lagerfähigkeit haben, kann es durchaus vorkommen, dass diese schon überlagert sind, also nicht mehr die für einen längeren Betrieb erforderliche Spannung haben bzw. halten können oder bereits nach ein paar Tagen leer (low) sind.

== Links ==
* [[HomeMatic]]
* Anleitung [http://www.elv-downloads.de/service/manuals/76788_HM_Sec_SC_GE_V1_0_UM.pdf PDF]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Kontaktsensor (magnetisch)]]

HM-SEC-SC Tür-Fensterkontakt

2014-11-29T09:54:14Z

Strauch: Ergänzung PeerNeedsBurst

Homematic Funk-Tür-Fensterkontakt
== Technische Daten ==
Aktuelle Firmware: 2.1

== Features ==
Überwachung einer Tür oder eines Fensters zur Sicherheit oder um automatisch, bei vorhandenem [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]], die Heizung herunter zu regeln, sobald ein Fenster oder eine Tür geöffnet wird.

== Hinweise zum Betrieb mit FHEM ==
===Pairing===
Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden. Der Sensor muss hierfür geöffnet und die versenkte Anlerntaste mit einem spitzen Gegenstand betätigt werden. Bei erfolgreichem Pairing blinkt die LED grün.

===Nutzung mit Wandthermostat===
Bei Einsatz mit [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]] und Zentrale erst alle Tür-/Fensterkontakte mit dem HM-CC-TC verbinden (anlernen). Alternativ geht das auch nachträglich über entsprechende ''set''-Befehle von Fhem aus. Dafür müssen der HM-CC-TC und der HM-Sec-SC aber vorher mit Fhem gepairt worden sein.

Wenn ein bereits erfolgreich gepairter SC ein ''set <HM-Sec-SC-Name> getConfig'' beim anschließenden Drücken der Anlerntaste am SC mit einem lang andauernden Blinken der LED in orange mit anschließendem Leuchten der LED in rot (ca. 1 Sekunde) beantwortet wird, hilft meist ein ''set <HM-Sec-SC-Name> clear readings'', Anlernknopf drücken, nun wieder ''set <HM-Sec-SC-Name> getConfig'' und Anlernknopf drücken.

Dies sollte nun mit einem kurzen LED-Signal in orange mit anschließendem längeren Flackern der LED in grün beantwortet werden und nach einem Refresh der Browser-Seite sollten alle aktuellen Daten zum SC verfügbar sein.

===Batteriestatus aktivieren===
Der HM-SEC-SC sendet nur dann Batteriestatus, wenn der Sensor selber geöffnet wird (Batteriefach), nicht jedoch wenn er schaltet, noch in wiederkehrenden Abständen. Um dies zu ändern muss das Register cyclicInfoMsg auf on gesetzt werden.

Dazu wie folgt vorgehen:
in Fhem (Telnet oder Webfrontend)
get NameMeines_HM-SEC-SC reg all
set NameMeines_HM-SEC-SC regSet cyclicInfoMsg on
eingeben. Danach siehst man beim Device, dass mindestens ein Kommando pendig ist und in den Readings, dass das cyclicInfoMsg Register geschrieben werden soll.
Danach Fhem in den pairing modus versetzten, z.B. mit:
set HMLAN1 hmPairForSec 30
und den Knopf im Batteriefach des HM-SEC-SC drücken (Büroklammer).
Danach noch mal
get NameMeines_HM-SEC-SC reg all
in Fhem (Telnet oder WEbfrontend).
Jetzt sollten keine pendig commands mehr zu sehen sein und in den readings genau
R-cyclicInfoMsg on
stehen.

Danach bekommst man regelmäßig (etwa alle 24 Stunden) eine Batteriestatusmeldung, wenn der HM-SEC-SC Tür-Fensterkontakt etwa 24 Stunden lang '''nicht''' betätigt wurde.
(wenn er betätigt wurde erfolgt keine Meldung, da die erfolgreiche Betätigungsmeldung zeigt, das die Batterie noch in Ordnung ist).
Ohne diese Aktivierung kann auch der ActionDetector für dieses Geräte möglicherweise nicht verwendet werden.

Achtung: Hierdurch steigt der Batterieverbrauch etwas an, besonders wenn der HM-SEC-SC Tür-Fensterkontakt normalerweise sehr selten betätigt wird. Erfahrungswerte liegen hier zu aber nicht vor.

Vergleiche auch [[HomeMatic_Type_ThreeState]]

=== FHEM Config-Auszug ===
Ein exemplarischer Auszug aus der fhem.cfg:

define TuerKeller CUL_HM 1638AC
attr TuerKeller devInfo 810101
attr TuerKeller firmware 2.0
attr TuerKeller hmClass sender
attr TuerKeller model HM-SEC-SC
attr TuerKeller room Keller
attr TuerKeller serialNr IEQ0xxxxxx
attr TuerKeller subType threeStateSensor

== Hinweise zum Peeren mit HM-CC-TC ==
* Nur wenn der HM-Sec-SC mit einem [[HM-CC-TC_Funk-Wandthermostat|HM-CC-TC]] direkt gep'''ee'''rt wurde, steuert letzterer die Absenkung der Temperatur an den [[HM-CC-VD]]-Ventilen. Ansonsten muss diese Steuerung von FHEM erfolgen.
* Das P'''ee'''ren des SC mit einem CC <ins>mittels Anlerntaste</ins> muss vor dem P'''ai'''ren des TC mit FHEM/HMLAN erfolgen, sonst geht das Peeren nur noch über FHEM-Befehle.

* In der Anleitung des HM-Sec-SC steht:

<nowiki>Um den Tür-Fensterkontakt in den Anlernmodus zu bringen, drücken Sie mit einem spitzen Gegenstand auf die Anlerntaste.
Die Geräte-LED blinkt orange. (Abbruch durch kurze Betätigung der Anlerntaste, die Geräte-LED leuchtet dann rot auf.)"</nowiki>

Falls die LED nicht orange, sondern nach dem ersten Drücken rot blinkt, Knopf erneut drücken. Zumindest bei manchen Geräten lässt sich nur so ein Pairen mit den [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]] durchgeführen (Geräte-LED blinkt orange)

=== Problembehebung ===
Falls trotz korrekt gepeertem Fensterkontakt mit einem HM-CC-RT-DN oder HM-TC-IT-WM-W-EU die LED einen Fehler meldet (rot leuchtet). Überprüft im Fensterkontakt ob das Register "PeerNeedsBurst" gesetzt ist und im Wandthermostat bzw. Heizkörperregler das Attribut BurstAccess auf Auto.

PeerNeedsBurst kann mit folgendem Befehl gesetzt werden:
set <HM-SEC-SC> regSet peerNeedsBurst on <RT oder TC>_WindowRec

Danach muss entweder der Kontakt geschaltet werden (HM-SEC-SC-2) oder der Anlernknopf gedrückt werden (HM-SEC-SC)

== Mögliche Zustände ==
Der Sensor hat folgende Schaltzustände:

closed -> Der Sensor zeigt einen geschlossenen Zustand an
open -> Der Sensor zeigt einen geöffneten Zustand an
cover: open -> Das Gehäuse des Sensors wurde geöffnet
cover: closed -> Das Gehäuse des Sensors wurde geschlossen
alive: yes -> Wenn der SC über 24 Std. keine Statusänderung hatte, sendet er ein "Lebenszeichen" an Fhem
sabotage -> ?

Die Änderungen der Zustände werden unmittelbar nach Statusänderung an Fhem / die Zentrale bzw. die gepeerten HM-CC-TC gemeldet.

=== Log-Auszüge ===
In FHEM sind folgende Zustände des HM-SEC-SC im Log zu sehen:

2012-02-13_21:52:02 TuerKeller cover: open
2012-02-13_21:52:02 TuerKeller sabotage
2012-02-13_21:55:23 TuerKeller cover: closed
2012-02-13_21:55:23 TuerKeller alive: yes
2012-02-13_21:55:52 TuerKeller closed (to broadcast)
2012-02-13_21:55:53 TuerKeller open (to broadcast)

Wenn der HM-SEC-SC mit einem HM-CC-TC gepeert ist, sehen die Meldungen auch so aus:

YYYY-MM-TT_HH:mm:ss CUL_HM_threeStateSensor_XYZXYZ contact: open (to HMLAN1)
YYYY-MM-TT_HH:mm:ss CUL_HM_threeStateSensor_XYZXYZ open
YYYY-MM-TT_HH:mm:ss CUL_HM_threeStateSensor_XYZXYZ contact: open (to CUL_HM_thermostat_ZYXZYX)

und

YYYY-MM-TT_HH:mm:ss CUL_HM_threeStateSensor_XYZXYZ contact: closed (to HMLAN1)
YYYY-MM-TT_HH:mm:ss CUL_HM_threeStateSensor_XYZXYZ closed
YYYY-MM-TT_HH:mm:ss CUL_HM_threeStateSensor_XYZXYZ contact: closed (to CUL_HM_thermostat_ZYXZYX)

wobei hier für den SC und TC noch keine Aliase vergeben wurden.

Zusätzlich, wenn die Knopfzellen (2 Stück, Typ LR44, Sollspannung 1,5 V) nachlassen:

2012-02-13_21:55:53 TuerKeller battery: low

was ansonsten so aussieht:

2012-02-13_21:55:53 TuerKeller battery: ok

== Batterien ==
Es werden 2 Stück Knopfzellen vom Typ LR44 (je nach Hersteller auch L1154, AG13, V13GA, A76 oder GPA76 genannt) benötigt. Diese sind Bestandteil der Lieferung, jedoch sollte man vor Installation / Inbetriebnahme die Spannung der Knopfzellen überprüfen. Diese sollte über 1,5 V liegen. Da Batterien eine begrenzte Lagerfähigkeit haben, kann es durchaus vorkommen, dass diese schon überlagert sind, also nicht mehr die für einen längeren Betrieb erforderliche Spannung haben bzw. halten können oder bereits nach ein paar Tagen leer (low) sind.

== Links ==
* [[HomeMatic]]
* Anleitung [http://www.elv-downloads.de/service/manuals/76788_HM_Sec_SC_GE_V1_0_UM.pdf PDF]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Kontaktsensor (magnetisch)]]

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

2014-09-08T15:28:00Z

Strauch: Peering Tür Fensterkontakt hinzugefügt

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

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

E-Mail senden

2014-08-27T21:13:11Z

Strauch: Änderungen in der SSL.pm führen zu Problemen mit FHEMWEB und SSL. Der neue Tipp ändert das Problem direkt in sendEmail so funktioniert beides

Um aus FHEM heraus '''E-Mail senden''' zu können, sind abhängig von der verwendeten Platform unterschiedliche Vorgehensweisen erforderlich.

== Linux ==
=== FritzBox 7170 (non-chroot) oder "reine" Linuxe ===
Datei 99_email.pm im Modul-Verzeichnis mit folgender Funktion anlegen (oder in bestehende 99_irgendwas.pm kopieren):

<nowiki>sub fb_mail {
my $rcpt = $_[0];
my $subject = $_[1];
my $text = $_[2];
system("/bin/echo \"$text\" | /usr/bin/mail send -i - -s \"$subject\" -t \"$rcpt\"");
}</nowiki>
Aufruf dann mittels
:<code>{ fb_mail('empfaenger@@mail.de','Subject','text 123') }</code>
Darauf achten, dass der fhem-User Mails senden darf (in richtige Gruppe eintragen. Ggf. vorher einmal su fhem und probieren).

=== Fritz!Box 7390 ===
Auf der [[AVM Fritz!Box|FritzBox 7390]] ist diese Funktion seit 10/2012 Bestandteil der Fhem Standardauslieferung. Sie ist untergebracht in FritzBoxUtils.pm und heisst dort FB_mail($$$) (Groß-Kleinschreibung beachten).

Da der Dateiname von FritzBoxUtils.pm nicht mit 99_ beginnt, wird diese Programmdatei nicht automatisch beim Start von Fhem geladen. Fhem muss zum Laden dieser Programmdatei aufgefordert werden. Dazu (z. B. in 99_myUtils.pm) die Zeile ''use FritzBoxUtils;'' einfügen.

Mit dem Install von AVM.de wird fhem in einer chroot-Umgebung ausgeführt, die den Zugriff auf die Mailfunktion der Fritzbox nicht zulässt. Daher muss Fhem in der [http://fhem.de/fhem.html#Download Version von fhem.de] installiert sein. Sollte Ihre Fritzbox bisher mit dem install von AVM laufen, kann (nach einem backup!) das image von fhem.de einfach drüberinstalliert werden. Es sollten dabei alle Einstellungen erhalten bleiben.

<nowiki>sub fb_mail {
my $rcpt = $_[0];
my $subject = $_[1];
my $text = $_[2];
system("/bin/echo \"$text\" > /var/tmp/fhem_nachricht.txt");
system("/sbin/mailer send -i '/var/tmp/fhem_nachricht.txt' -s \"$subject\" -t \"$rcpt\"");
system("rm /var/tmp/fhem_nachricht.txt");
}</nowiki>

Aufruf dann mittels
:<code>{ fb_mail('empfaenger@mail.de','Subject','text 123') }</code>
bzw.
:<code>{ FB_mail('empfaenger@mail.de','Subject','text 123') }</code>

'''Hinweis:''' Wenn der Aufruf der Mailfunktion aus einem notify oder at erfolgt, muss das @@ in der Adresse des Mailempfängers verdoppelt werden, da ein einfaches @ sonst durch den Namen des getriggerten Devices ersetzt würde. Bei Verwendung in der fhem-Kommandozeile oder einem eigenen *Utils.pm ist diese Doppelung nicht erforderlich. Bitte bei den ersten Mails ins Log schauen, ob die Mailadresse wie gewünscht verwendet wird.

Dem Mailer können noch weitere Parameter hinzugefügt werden. Mehr dazu siehe: [http://www.wehavemorefun.de/fritzbox/Mailer Mailer]

=== OpenWRT ===
Die Anleitung wurde mit einer frühen Beta von Barrier Breaker (r391xx) mit einem TP_Lind WDR 4900 getestet. Da "sendEmail" nicht als Package vorliegt wird in dieser Anleitung "ssmtp" verwendet.
Die Installation erfolgt mittels:

<pre>
opkg update
opkg install ssmtp_2.64-4_mpc85xx.ipk
</pre>

Hierbei werden die Packete libopenssl und zlib mit installiert. Damit ssmtp funktioniert müssen die Dateien /etc/ssmtp/ssmtp.conf und /etc/ssmtp/revaliases angepasst werden.

/etc/ssmtp/ssmtp.conf
<nowiki>root=arnold@gmx.net
mailhub=mail.gmx.net:465
rewriteDomain=gmx.net
hostname=gmx.net
FromLineOverride=YES
UseTLS=YES
#UseSTARTTLS=YES
AuthUser=arnold@gmx.net
AuthPass=Passwort_von_arnold@gmx.net
</nowiki>

/etc/ssmtp/revaliases
<nowiki>
root:arnold@gmx.net:mail.gmx.net:465</nowiki>

In der [[99_myUtils_anlegen|99_myUtils]] folgende Unterroutine einfügen (von der RPi-Anleitung übernommen):

<nowiki>sub
OpenWRTMail
{
my $rcpt = shift;
my $subject = shift;
my $text = shift;
my $ret = "";
my $sender = "dockstar\@heye-tammo.de";
Log 1, "sendEmail RCP: $rcpt, Subject: $subject, Text: $text";
$ret .= qx(echo -e 'to:$rcpt\n from:$sender\nsubject:$subject\n$text\n' | ssmtp $rcpt);
$ret =~ s,[\r\n]*,,g; # remove CR from return-string
Log 1, "sendEmail returned: $ret";
}</nowiki>

Ab hier den entsprechenden Abschnitt unter "Raspberry Pi" lesen.

=== Synology DiskStation ===
Beim DSM 3.2 gab es keinen <code>sendmail</code>-Befehl, sondern nur eine Funktion für den Versand der System-Benachrichtigungen. Interessanterweise funktionierte aber der <code>php-mail</code>-Befehl, so dass man mittels folgendem Modul Mails frei versenden kann:

<nowiki>sub sendmail($$$) {
my($empf, $subj, $nachricht) = @_;
system("php -r 'mail(\"$empf\",\"$subj\",\"$nachricht\");'");
undef;
}</nowiki>

=== Raspberry Pi ===
In der weezy-Version, wie sie von busware zur Verfügung gestellt wird, muss auf einem [[Raspberry Pi]] noch sendEmail nachinstalliert werden:

<pre>
sudo apt-get update
sudo apt-get install sendEmail
</pre>

in der [[99_myUtils_anlegen|99_myUtils]] folgende Unterroutine einfügen:

<nowiki>######## DebianMail Mail auf dem RPi versenden ############
sub
DebianMail
{
my $rcpt = shift;
my $subject = shift;
my $text = shift;
my $ret = "";
my $sender = "absender\@account.de";
my $konto = "kontoname\@account.de";
my $passwrd = "passwrd";
my $provider = "smtp.provider.de:25";
Log 1, "sendEmail RCP: $rcpt";
Log 1, "sendEmail Subject: $subject";
Log 1, "sendEmail Text: $text";

$ret .= qx(sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -s '$provider' -xu '$konto' -xp '$passwrd' -o tls=no -o message-charset=utf-8);
$ret =~ s,[\r\n]*,,g; # remove CR from return-string
Log 1, "sendEmail returned: $ret";
}</nowiki>

Um die TLS Verschlüsselung (ehem. SSL) zu nutzen, muss in der 4. letzten Zeile tls=auto verwendet werden. Sollte anschließend keine Mail verschickt werden, siehe Probleme.

Beim Aufruf der Funktion gibt es zwei unterschiedliche Verhaltensweisen zu beachten. Wird DebianMail durch ein Fhem-Ereignis als Makro mit "Transferzeichen", wie @ oder % aufgerufen, so sind diese innerhalb des Aufrufs von DebianMail zu maskieren.

Siehe auch commandref:
* The character @ will be replaced with the device name. To use @ in the text itself, use the double mode (@@).
* The macro %<parameter> will expand to the current value of the named parameter. This can be either a parameter from the device definition or a parameter from the set or get command.

Beispiel:

<nowiki>define Sonstiges notify Fenster:Window:.*,.*Low.Batt*. {\
DebianMail('email@@email.domain','Subject','Text');;\
}</nowiki>

in allen anderen Fällen muss die Maskierung entfallen:

Beispiel:

<nowiki>define Sonstiges at *01:00:00 {\
DebianMail('email@email.domain','Subject','Text');;\
}</nowiki>

=== BeagleBoard-xM ===
Auf einem [[:Kategorie:BeagleBoard-xM|BeagleBoard-xM]] mit einem [http://en.opensuse.org/HCL:BeagleBoard-xM OpenSUSE 12.2] kann man ebenfalls das Perl-Programm ''sendEmail'' wie beim RPi nutzen. Dies gibt es aber nicht in den Repositories von openSUSE, sondern man muss sich ''sendEmail'' als Source herunterladen. Das geht am einfachsten per ''wget'', welches man ebenfalls erst installieren muss (aber aus einem Repository).

<nowiki>$ zypper in wget
$ cd /opt
$ wget http://caspian.dotconf.net/menu/Software/SendEmail/sendEmail-v1.56.tar.gz
$ tar xvfz sendEmail-v1.56.tar.gz
$ cd sendEmail-v1.56
$ cp sendMail /usr/local/bin</nowiki>
Dann geht man weiter vor wie unter RPi beschrieben (anlegen der SUB-Routine in 99_myUtils usw.).

'''Hinweis:''' Die Version 1.56 von ''sendEmail'' ist Stand Januar 2013 die aktuelle. Da diese Programmversion von 2009 stammt, ist mit neuen Versionen selten zu rechnen. Vielleicht schauen Sie trotzdem vorher auf der [http://caspian.dotconf.net/menu/Software/SendEmail/ Homepage von sendEmail] nach.

== Windows ==
# Kopiere die Datei sendEmail.exe* in Dein FHEM Verzeichnis (hier c:\fhem-5.0\); Quelle: [http://caspian.dotconf.net/menu/Software/SendEmail/ http://caspian.dotconf.net/menu/Software/SendEmail/]
# Erstelle im FHEM Verzeichnis die Datei wmail.bat mit folgendem Inhalt (eine Zeile): <code>sendEmail -f absender@domain.de -u "%1" -m " " -s SMTP-SERVERAdresse -xu SMTP_USERNAME -xp SMTP_PASSWORT -t empfänger@domain.de -o message-header="X-Message-Flag: FHEM"</code>
# Beispiel fhem.cfg
## Mail wenn sich der Status von Heizung.* oder Hzg.* ändert <code>define Mail_Heizung notify Heizung.*|Hzg.* { system("wmail @:%")}</code>
## Mail bei Signal Aussentemperatur (für dieses Beispiel wird [http://fhem.de/commandref.html#getstate http://fhem.de/commandref.html#getstate getstate] benötigt) <code>define Mail_Aussentemperatur notify Aussentemperatur {\</code> <code>my ($val);;\</code> <code>$val = fhem "getstate @";;\</code> <code>system("wmail \"@: $val\"");;\</code> <code>}</code>

== Probleme ==
=== sendEmail ===
Falls man keine E-Mails verschicken kann, kann man in einem ersten Test prüfen, ob sendEmail als solches funktioniert und die Konfiguration (Benutzer, Passwort, Server-Name usw.) des Mail-Kontos, über das die Mails abgesetzt werden sollen, richtig ist.

Hierzu setzt man in der FHEM-Befehlszeile die folgende Anweisung ab:
:<code>{ SUB-Routinen-Name('EMailAdresse@Mail.Domain','Test','Test-Text');; }</code>
und ersetzt ''SUB-Routinen-Name'' durch den Namen der in 99_myUtils erzeugten Prozedur. Statt ''EMailAdresse@Mail.Domain'' trägt man noch eine gültige E-Mail-Adresse ein und bestätigt den Befehl dann mittels <Enter> (nicht "save"). Empfangen Sie nicht kurzfristig eine entsprechende E-Mail, ist sehr wahrscheinlich an den Zugangsdaten etwas verkehrt.

Vor dem testen der Routine oben kann sendEmail auch über die Konsole (z. B. via Putty) getestet werden:
:<code>sendEmail -f 'fhemsystem@meinedomain.tld' -t 'ich@meinedomain.tld' -u 'subject' -m 'body' -s 'meinmailserver.meinedomain.de' -xu 'fhemmailer' -xp 'geheimespassword' -o tls=no</code>

=== Keine Mail mit TLS Verschlüsselung ===
Den Test über die Konsole durchführen. Erhält man folgende Fehlermeldung:
''invalid SSL_version specified at /usr/share/perl5/IO/Socket/SSL.pm line 332''
muss auf dem Raspberry folgende Datei angepasst werden: ''/usr/bin/sendEmail''.
In Zeile 1907 muss
if (! IO::Socket::SSL->start_SSL($SERVER, SSL_version => 'SSLv3 TLSv1')) {

in folgendes geändert werden
if (! IO::Socket::SSL->start_SSL($SERVER, SSL_version => 'SSLv23:!SSLv2')) {

Der frühere Tipp direkt in der SSL.pm Datei zu editieren führt zu Problemen wenn man auf FHEM per HTTPS zugreifen will und ist daher nicht zu empfehlen.

== Email laut Log gesendet aber nicht angekommen? ==
Dann bitte in der Fritzbox Oberfläche überpüfen, ob unter "System" -> "Push Service" selbiger eingerichtet und aktiviert wurde.

[[Kategorie:HOWTOS]]
[[Kategorie:FritzBox]]
[[Kategorie:BeagleBoard-xM]]
[[Kategorie:Raspberry Pi]]

HM-WDS10-TH-O Funk-Temperatur-/Feuchtesensor außen (OTH)

2014-05-19T12:20:10Z

Strauch: Link für neue Forensoftware angepasst

'''HM-WDS10-TH-O Funk-Temperatur-/Luftfeuchtesensor (außen)'''
Homematic Außensensor für Temperatur und relative Luftfeuchte.
== Features ==
* Batteriebetrieb (2 x AA)
* Möglichkeit der Wandmontage
* Eignung für Temp. von -19,9 °C bis +79,9 °C
* Datenübermittlung alle 120 bis 180 Sekunden
* Übermittlung des Batteriestatus
== Hinweise zum Betrieb mit FHEM ==
Das Pairing sollte wie unter [[HomeMatic Devices pairen]] beschrieben durchgeführt werden. Der Sensor muss hierfür geöffnet (obere Spritzwasser-Schutzkappe abziehen und Batteriefach-Abdeckung öffnen) und die Anlerntaste betätigt werden.

== Probleme ==
Siehe z.B.:

* [http://forum.fhem.de/index.php/topic,10445.html Temperaturwerte mit HM-WDS10-TH-O]

und

* [http://www.elv.de/homematic-hm-wds10-th-o-funk-temperatur-luftfeuchtesensor-oth.html hier] unter ''Bewertungen'', 2 Sterne => Kontakt zur Technik erwünscht.

Bessere Batterien ''können'' evtl. helfen:

* [http://homematic-forum.de/forum/viewtopic.php?f=27&t=8230 Link]

und

* [http://www.ip-symcon.de/forum/threads/17198-HM-WDS10-TH-O-Temperatur-Sensor-h%C3%A4ngt-ab-8-grad Link]

== FHEM Config-Auszug ==
Beispiel mit Sensor, Log und SVG-Grafik:
<pre>define Temperatur_Wohnung CUL_HM ******
attr Temperatur_Wohnung .devInfo 030100
attr Temperatur_Wohnung .stc 70
attr Temperatur_Wohnung actCycle 000:10
attr Temperatur_Wohnung actStatus alive
attr Temperatur_Wohnung autoReadReg 4_reqStatus
attr Temperatur_Wohnung expert 2_full
attr Temperatur_Wohnung firmware 1.2
attr Temperatur_Wohnung group Allgemein
attr Temperatur_Wohnung model HM-WDS10-TH-O
attr Temperatur_Wohnung peerIDs
attr Temperatur_Wohnung room Klima
attr Temperatur_Wohnung serialNr **********
attr Temperatur_Wohnung subType THSensor
define FileLog_Temperatur_Wohnung FileLog ./log/Temperatur_Wohnung-%Y.log Temperatur_Wohnung
attr FileLog_Temperatur_Wohnung logtype temp4hum6:Plot,text
attr FileLog_Temperatur_Wohnung room Logs
define Wohnen SVG FileLog_Temperatur_Wohnung:Wohnen:CURRENT
attr Wohnen room Klima</pre>

== FHEM Log-Auszug ==
<nowiki><Datum>_<Zeit> CUL_HM_THSensor_1ABCDE T: 21.8 H: 56
<Datum>_<Zeit> CUL_HM_THSensor_1ABCDE T: 21.8 H: 56
<Datum>_<Zeit> CUL_HM_THSensor_1ABCDE T: 21.8 H: 56
<Datum>_<Zeit> CUL_HM_THSensor_1ABCDE T: 21.8 H: 56</nowiki>
== Links ==
Anleitung [http://www.elv-downloads.de/Assets/Produkte/7/769/76923/Downloads/76923_HM_WDS10_TH-O_GE_V1_02_UM.pdf PDF]

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

E-Mail senden

2014-05-15T07:58:54Z

Strauch: /* Raspberry Pi */ sendEmail um utf8 charset erweitert, dann gibt es keine Probleme mehr mit Umlauten.

Um aus FHEM heraus '''E-Mail senden''' zu können, sind abhängig von der verwendeten Platform unterschiedliche Vorgehensweisen erforderlich.

== Linux ==
=== FritzBox 7170 (non-chroot) oder "reine" Linuxe ===
Datei 99_email.pm im Modul-Verzeichnis mit folgender Funktion anlegen (oder in bestehende 99_irgendwas.pm kopieren):

<nowiki>sub fb_mail {
my $rcpt = $_[0];
my $subject = $_[1];
my $text = $_[2];
system("/bin/echo \"$text\" | /usr/bin/mail send -i - -s \"$subject\" -t \"$rcpt\"");
}</nowiki>
Aufruf dann mittels
:<code>{ fb_mail('empfaenger@@mail.de','Subject','text 123') }</code>
Darauf achten, dass der fhem-User Mails senden darf (in richtige Gruppe eintragen. Ggf. vorher einmal su fhem und probieren).

=== Fritz!Box 7390 ===
Auf der [[AVM Fritz!Box|FritzBox 7390]] ist diese Funktion seit 10/2012 Bestandteil der Fhem Standardauslieferung. Sie ist untergebracht in FritzBoxUtils.pm und heisst dort FB_mail($$$) (Groß-Kleinschreibung beachten).

Da der Dateiname von FritzBoxUtils.pm nicht mit 99_ beginnt, wird diese Programmdatei nicht automatisch beim Start von Fhem geladen. Fhem muss zum Laden dieser Programmdatei aufgefordert werden. Dazu (z. B. in 99_myUtils.pm) die Zeile ''use FritzBoxUtils;'' einfügen.

Mit dem Install von AVM.de wird fhem in einer chroot-Umgebung ausgeführt, die den Zugriff auf die Mailfunktion der Fritzbox nicht zulässt. Daher muss Fhem in der [http://fhem.de/fhem.html#Download Version von fhem.de] installiert sein. Sollte Ihre Fritzbox bisher mit dem install von AVM laufen, kann (nach einem backup!) das image von fhem.de einfach drüberinstalliert werden. Es sollten dabei alle Einstellungen erhalten bleiben.

<nowiki>sub fb_mail {
my $rcpt = $_[0];
my $subject = $_[1];
my $text = $_[2];
system("/bin/echo \"$text\" > /var/tmp/fhem_nachricht.txt");
system("/sbin/mailer send -i '/var/tmp/fhem_nachricht.txt' -s \"$subject\" -t \"$rcpt\"");
system("rm /var/tmp/fhem_nachricht.txt");
}</nowiki>

Aufruf dann mittels
:<code>{ fb_mail('empfaenger@mail.de','Subject','text 123') }</code>
bzw.
:<code>{ FB_mail('empfaenger@mail.de','Subject','text 123') }</code>

'''Hinweis:''' Wenn der Aufruf der Mailfunktion aus einem notify oder at erfolgt, muss das @@ in der Adresse des Mailempfängers verdoppelt werden, da ein einfaches @ sonst durch den Namen des getriggerten Devices ersetzt würde. Bei Verwendung in der fhem-Kommandozeile oder einem eigenen *Utils.pm ist diese Doppelung nicht erforderlich. Bitte bei den ersten Mails ins Log schauen, ob die Mailadresse wie gewünscht verwendet wird.

Dem Mailer können noch weitere Parameter hinzugefügt werden. Mehr dazu siehe: [http://www.wehavemorefun.de/fritzbox/Mailer Mailer]

=== OpenWRT ===
Die Anleitung wurde mit einer frühen Beta von Barrier Breaker (r391xx) mit einem TP_Lind WDR 4900 getestet. Da "sendEmail" nicht als Package vorliegt wird in dieser Anleitung "ssmtp" verwendet.
Die Installation erfolgt mittels:

<pre>
opkg update
opkg install ssmtp_2.64-4_mpc85xx.ipk
</pre>

Hierbei werden die Packete libopenssl und zlib mit installiert. Damit ssmtp funktioniert müssen die Dateien /etc/ssmtp/ssmtp.conf und /etc/ssmtp/revaliases angepasst werden.

/etc/ssmtp/ssmtp.conf
<nowiki>root=arnold@gmx.net
mailhub=mail.gmx.net:465
rewriteDomain=gmx.net
hostname=gmx.net
FromLineOverride=YES
UseTLS=YES
#UseSTARTTLS=YES
AuthUser=arnold@gmx.net
AuthPass=Passwort_von_arnold@gmx.net
</nowiki>

/etc/ssmtp/revaliases
<nowiki>
root:arnold@gmx.net:mail.gmx.net:465</nowiki>

In der [[99_myUtils_anlegen|99_myUtils]] folgende Unterroutine einfügen (von der RPi-Anleitung übernommen):

<nowiki>sub
OpenWRTMail
{
my $rcpt = shift;
my $subject = shift;
my $text = shift;
my $ret = "";
my $sender = "dockstar\@heye-tammo.de";
Log 1, "sendEmail RCP: $rcpt, Subject: $subject, Text: $text";
$ret .= qx(echo -e 'to:$rcpt\n from:$sender\nsubject:$subject\n$text\n' | ssmtp $rcpt);
$ret =~ s,[\r\n]*,,g; # remove CR from return-string
Log 1, "sendEmail returned: $ret";
}</nowiki>

Ab hier den entsprechenden Abschnitt unter "Raspberry Pi" lesen.

=== Synology DiskStation ===
Beim DSM 3.2 gab es keinen <code>sendmail</code>-Befehl, sondern nur eine Funktion für den Versand der System-Benachrichtigungen. Interessanterweise funktionierte aber der <code>php-mail</code>-Befehl, so dass man mittels folgendem Modul Mails frei versenden kann:

<nowiki>sub sendmail($$$) {
my($empf, $subj, $nachricht) = @_;
system("php -r 'mail(\"$empf\",\"$subj\",\"$nachricht\");'");
undef;
}</nowiki>

=== Raspberry Pi ===
In der weezy-Version, wie sie von busware zur Verfügung gestellt wird, muss auf einem [[Raspberry Pi]] noch sendEmail nachinstalliert werden:

<pre>
sudo apt-get update
sudo apt-get install sendEmail
</pre>

in der [[99_myUtils_anlegen|99_myUtils]] folgende Unterroutine einfügen:

<nowiki>######## DebianMail Mail auf dem RPi versenden ############
sub
DebianMail
{
my $rcpt = shift;
my $subject = shift;
my $text = shift;
my $ret = "";
my $sender = "absender\@account.de";
my $konto = "kontoname\@account.de";
my $passwrd = "passwrd";
my $provider = "smtp.provider.de";
Log 1, "sendEmail RCP: $rcpt";
Log 1, "sendEmail Subject: $subject";
Log 1, "sendEmail Text: $text";

$ret .= qx(sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -s '$provider' -xu '$konto' -xp '$passwrd' -o tls=no -o message-charset=utf-8);
$ret =~ s,[\r\n]*,,g; # remove CR from return-string
Log 1, "sendEmail returned: $ret";
}</nowiki>

Um die TLS Verschlüsselung (ehem. SSL) zu nutzen, muss in der 4. letzten Zeile tls=auto verwendet werden. Sollte anschließend keine Mail verschickt werden, siehe Probleme.

Beim Aufruf der Funktion gibt es zwei unterschiedliche Verhaltensweisen zu beachten. Wird DebianMail durch ein Fhem-Ereignis als Makro mit "Transferzeichen", wie @ oder % aufgerufen, so sind diese innerhalb des Aufrufs von DebianMail zu maskieren.

Siehe auch commandref:
* The character @ will be replaced with the device name. To use @ in the text itself, use the double mode (@@).
* The macro %<parameter> will expand to the current value of the named parameter. This can be either a parameter from the device definition or a parameter from the set or get command.

Beispiel:

<nowiki>define Sonstiges notify Fenster:Window:.*,.*Low.Batt*. {\
DebianMail('email@@email.domain','Subject','Text');;\
}</nowiki>

in allen anderen Fällen muss die Maskierung entfallen:

Beispiel:

<nowiki>define Sonstiges at *01:00:00 {\
DebianMail('email@email.domain','Subject','Text');;\
}</nowiki>

=== BeagleBoard-xM ===
Auf einem [[:Kategorie:BeagleBoard-xM|BeagleBoard-xM]] mit einem [http://en.opensuse.org/HCL:BeagleBoard-xM OpenSUSE 12.2] kann man ebenfalls das Perl-Programm ''sendEmail'' wie beim RPi nutzen. Dies gibt es aber nicht in den Repositories von openSUSE, sondern man muss sich ''sendEmail'' als Source herunterladen. Das geht am einfachsten per ''wget'', welches man ebenfalls erst installieren muss (aber aus einem Repository).

<nowiki>$ zypper in wget
$ cd /opt
$ wget http://caspian.dotconf.net/menu/Software/SendEmail/sendEmail-v1.56.tar.gz
$ tar xvfz sendEmail-v1.56.tar.gz
$ cd sendEmail-v1.56
$ cp sendMail /usr/local/bin</nowiki>
Dann geht man weiter vor wie unter RPi beschrieben (anlegen der SUB-Routine in 99_myUtils usw.).

'''Hinweis:''' Die Version 1.56 von ''sendEmail'' ist Stand Januar 2013 die aktuelle. Da diese Programmversion von 2009 stammt, ist mit neuen Versionen selten zu rechnen. Vielleicht schauen Sie trotzdem vorher auf der [http://caspian.dotconf.net/menu/Software/SendEmail/ Homepage von sendEmail] nach.

== Windows ==
# Kopiere die Datei sendEmail.exe* in Dein FHEM Verzeichnis (hier c:\fhem-5.0\); Quelle: [http://caspian.dotconf.net/menu/Software/SendEmail/ http://caspian.dotconf.net/menu/Software/SendEmail/]
# Erstelle im FHEM Verzeichnis die Datei wmail.bat mit folgendem Inhalt (eine Zeile): <code>sendEmail -f absender@domain.de -u "%1" -m " " -s SMTP-SERVERAdresse -xu SMTP_USERNAME -xp SMTP_PASSWORT -t empfänger@domain.de -o message-header="X-Message-Flag: FHEM"</code>
# Beispiel fhem.cfg
## Mail wenn sich der Status von Heizung.* oder Hzg.* ändert <code>define Mail_Heizung notify Heizung.*|Hzg.* { system("wmail @:%")}</code>
## Mail bei Signal Aussentemperatur (für dieses Beispiel wird [http://fhem.de/commandref.html#getstate http://fhem.de/commandref.html#getstate getstate] benötigt) <code>define Mail_Aussentemperatur notify Aussentemperatur {\</code> <code>my ($val);;\</code> <code>$val = fhem "getstate @";;\</code> <code>system("wmail \"@: $val\"");;\</code> <code>}</code>

== Probleme ==
=== sendEmail ===
Falls man keine E-Mails verschicken kann, kann man in einem ersten Test prüfen, ob sendEmail als solches funktioniert und die Konfiguration (Benutzer, Passwort, Server-Name usw.) des Mail-Kontos, über das die Mails abgesetzt werden sollen, richtig ist.

Hierzu setzt man in der FHEM-Befehlszeile die folgende Anweisung ab:
:<code>{ SUB-Routinen-Name('EMailAdresse@Mail.Domain','Test','Test-Text');; }</code>
und ersetzt ''SUB-Routinen-Name'' durch den Namen der in 99_myUtils erzeugten Prozedur. Statt ''EMailAdresse@Mail.Domain'' trägt man noch eine gültige E-Mail-Adresse ein und bestätigt den Befehl dann mittels <Enter> (nicht "save"). Empfangen Sie nicht kurzfristig eine entsprechende E-Mail, ist sehr wahrscheinlich an den Zugangsdaten etwas verkehrt.

Vor dem testen der Routine oben kann sendEmail auch über die Konsole (z. B. via Putty) getestet werden:
:<code>sendEmail -f 'fhemsystem@meinedomain.tld' -t 'ich@meinedomain.tld' -u 'subject' -m 'body' -s 'meinmailserver.meinedomain.de' -xu 'fhemmailer' -xp 'geheimespassword' -o tls=no</code>

=== Keine Mail mit TLS Verschlüsselung ===
Den Test über die Konsole durchführen. Erhält man folgende Fehlermeldung:
''invalid SSL_version specified at /usr/share/perl5/IO/Socket/SSL.pm line 332''
muss auf dem Raspberry folgende Datei angepasst werden: ''/usr/share/perl5/IO/Socket/SSL.pm''.
In Zeile 1490 muss das '''$''' am Ende entfernt werden: m{^(!?)(?:(SSL(?:v2|v3|v23|v2/3))|(TLSv1[12]?))'''$'''}i

== Email laut Log gesendet aber nicht angekommen? ==
Dann bitte in der Fritzbox Oberfläche überpüfen, ob unter "System" -> "Push Service" selbiger eingerichtet und aktiviert wurde.

[[Kategorie:HOWTOS]]
[[Kategorie:FritzBox]]
[[Kategorie:BeagleBoard-xM]]
[[Kategorie:Raspberry Pi]]

HomeMatic Firmware Update

2014-05-14T08:49:28Z

Strauch:

= Varianten für Firmwareupdates =
Seit 2014 ist es möglich bei einige HomeMatic Komponenten selber Firmware Updates durchzuführen. Vorher ging es nur per CCU oder durch einsenden des Gerätes zu 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 ==
Noch nicht offiziell implementiert, weiter Infos gibt es im Forum: http://forum.fhem.de/index.php/topic,23329.0.html

== Firmware Update mit CUL/HM-CFG-USB unter Linux ==
Für Linux hat mgernoth eine Updatetool programmiert.

Als erstes müssen wir sicher stellen das alle nötigen Pakete installiert sind um das Tool zu installieren und auszuführen
sudo apt-get install libusb-1.0-0-dev && sudo apt-get install git && sudo apt-get install build-essential

Als nächstes laden wir das Tool
git clone git://git.zerfleddert.de/hmcfgusb

und installieren es
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
z.B. Firmware 1.2 für HM-CC-RT-DN:
wget http://www.eq-3.de/Downloads/Software/Firmware/hm_cc_rt_dn_update_V1_2_007_131202.tar.gz
tar -xvf hm_cc_rt_dn_update_V1_2_007_131202.tar.gz

Nun brauchen wir nur noch das Tool ausführen und die Seriennummer des HomeMatic Devices.

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 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 Updatemodus versetzt werden, wie das geht steht in der Readme zur Firmwaredatei (Ist mit im Archiv)

== 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 . Das Update ist damit zur Zeit nur mit dem HM-CFG-USB-2 möglich nicht mit dem HM-CFG-LAN und 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 Device in den Updatemodus versetzte 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 werden, sondern muss als ".tar.gz"-Datei, so wie heruntergeladen, benutzt werden. Außerdem gibt es Probleme, wenn die Datei mit dem Internet Explorer heruntergeladen wurde. Die Datei sollte mit einem anderen Browser heruntergeladen werden.

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

HomeMatic Firmware Update

2014-05-14T08:48:25Z

Strauch: /* Firmware Update mit HM-CFG-USB unter Windows */

= Varianten für Firmwareupdates =
Seit 2014 ist es möglich bei einige HomeMatic Komponenten selber Firmware Updates durchzuführen. Vorher ging es nur per CCU oder durch einsenden des Gerätes zu 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 =
Noch nicht offiziell implementiert, weiter Infos gibt es im Forum: http://forum.fhem.de/index.php/topic,23329.0.html

= Firmware Update mit CUL/HM-CFG-USB unter Linux =
Für Linux hat mgernoth eine Updatetool programmiert.

Als erstes müssen wir sicher stellen das alle nötigen Pakete installiert sind um das Tool zu installieren und auszuführen
sudo apt-get install libusb-1.0-0-dev && sudo apt-get install git && sudo apt-get install build-essential

Als nächstes laden wir das Tool
git clone git://git.zerfleddert.de/hmcfgusb

und installieren es
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
z.B. Firmware 1.2 für HM-CC-RT-DN:
wget http://www.eq-3.de/Downloads/Software/Firmware/hm_cc_rt_dn_update_V1_2_007_131202.tar.gz
tar -xvf hm_cc_rt_dn_update_V1_2_007_131202.tar.gz

Nun brauchen wir nur noch das Tool ausführen und die Seriennummer des HomeMatic Devices.

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 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 Updatemodus versetzt werden, wie das geht steht in der Readme zur Firmwaredatei (Ist mit im Archiv)

= 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 . Das Update ist damit zur Zeit nur mit dem HM-CFG-USB-2 möglich nicht mit dem HM-CFG-LAN und 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 Device in den Updatemodus versetzte 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 werden, sondern muss als ".tar.gz"-Datei, so wie heruntergeladen, benutzt werden. Außerdem gibt es Probleme, wenn die Datei mit dem Internet Explorer heruntergeladen wurde. Die Datei sollte mit einem anderen Browser heruntergeladen werden.

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

HomeMatic Firmware Update

2014-05-14T08:47:48Z

Strauch: /* Firmware Update mit CUL/HM-CFG-USB unter Linux */

= Varianten für Firmwareupdates =
Seit 2014 ist es möglich bei einige HomeMatic Komponenten selber Firmware Updates durchzuführen. Vorher ging es nur per CCU oder durch einsenden des Gerätes zu 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 =
Noch nicht offiziell implementiert, weiter Infos gibt es im Forum: http://forum.fhem.de/index.php/topic,23329.0.html

= Firmware Update mit CUL/HM-CFG-USB unter Linux =
Für Linux hat mgernoth eine Updatetool programmiert.

Als erstes müssen wir sicher stellen das alle nötigen Pakete installiert sind um das Tool zu installieren und auszuführen
sudo apt-get install libusb-1.0-0-dev && sudo apt-get install git && sudo apt-get install build-essential

Als nächstes laden wir das Tool
git clone git://git.zerfleddert.de/hmcfgusb

und installieren es
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
z.B. Firmware 1.2 für HM-CC-RT-DN:
wget http://www.eq-3.de/Downloads/Software/Firmware/hm_cc_rt_dn_update_V1_2_007_131202.tar.gz
tar -xvf hm_cc_rt_dn_update_V1_2_007_131202.tar.gz

Nun brauchen wir nur noch das Tool ausführen und die Seriennummer des HomeMatic Devices.

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 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 Updatemodus versetzt werden, wie das geht steht in der Readme zur Firmwaredatei (Ist mit im Archiv)

= 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 . Das Update ist damit zur Zeit nur mit dem HM-CFG-USB möglich nicht mit dem HM-CFG-LAN.

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 Device in den Updatemodus versetzte 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 werden, sondern muss als ".tar.gz"-Datei, so wie heruntergeladen, benutzt werden. Außerdem gibt es Probleme, wenn die Datei mit dem Internet Explorer heruntergeladen wurde. Die Datei sollte mit einem anderen Browser heruntergeladen werden.

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

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

2014-05-14T08:46:15Z

Strauch: /* Firmware Update */ Verlinkung auf den HomeMatic Firmware Artikel und entfernen der doppelten Information

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.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_Clima|Channel (Kanal) 04 _Clima]] 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 _Clima ====
Dieser Kanal ist "der" operationelle. Hier kann z.B. die Temperatur eingestellt werden. (In älteren Versionen wurde dieser Kanal durch autocreate als "_ClimRT_tr" angelegt.)

'''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 ''_Clima'' 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_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")};
}
# 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_Clima> regSet winOpnMode off

==== Channel (Kanal) 05 _ClimaTeam ====
Dieser Kanal dient zum peeren von mehreren RTs untereinander. Ein RT meldet Änderungen, die am device durchgeführt werden an seinen Teamkollegen. Änderungen von der Zentrale werden nicht gesyncht - das muss die Zentrale machen. Das gilt für alle anderen Änderungen ebenso (Fensterkontakt, Remote,...). Hier müssen diese Kontakte einfach mit allen RTs gepeert werden und identisch programmiert werden.
'''Folgende Änderungen werden "nicht" weitergegeben:'''
* Status der Fensterkontakte
* Temperaturvorgaben der Zentrale
* Temperaturlisten/Wochenplan und daraus folgende Änderungen
* Änderungen durch remotes
* Änderungen durch eine TC-IT Zentrale

'''Folgende Änderungen werden weitergegeben:'''
* Änderung der Temperatur am Handrad
* Boost am Taster

Befehl zum peeren:
<pre>set <rt1-ClimaTeam> peerChan 0 <rt2-ClimaTeam> single</pre>

==== Channel (Kanal) 06 _remote ====
Kann an eine Fernbedienung gekoppelt werden. Per Tastendruck kann man einen bestimmten Mode und/oder eine bestimmte Temperatur wählen. Man kann lang gesondert die Reaktion auf einen langen oder kurzen Tastendruck 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 ====
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 wieder zum vorher eingestellten Programm 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: 
 

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) = @_;

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

=== Temperaturlisten ===
Im Kanal "Clima" kann man einen Wochenplan hinterlegen. Im Automode stellt das Thermostat eine desired-temp gemäß diesen Daten ein. Die Daten werden in Registern im RT abgelegt. Wegen der schlichten Menge an Daten gibt es gesonderte Kommandos zur Verwaltung der Listen. Die Darstellung der Daten unterliegt aber dennoch den Regeln der Register: FHEM muss die Daten aus dem Device lesen (getConfig) um sie Darzustellen.
==== manuelle Änderung ====
Mit dem Kommando set <rt>_Clima tempListMon 05:30 16.0 ... 24:00 16.0 kann man das temperaturprofil für einen Tag einstellen. Der letzte Wert muss immer Mitternacht (24:00) sein. Die Temperatur gilt immer bis zu diesen Zeitpunkt '''nicht''' ab diesem Zeitpunkt.
Ändert man mehrere Tage auf einmal sollte man unbedingt mit "prep" und "exec" arbeiten, da es sonst zu Wiederholungen und langen Bearbeitungen kommen kann. Das könnte in eine script so aussehen
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====
Manuelle Änderungen sind jederzeit möglich, aber sicher nicht elegant. Besser ist die Verwaltung von Profilen in einem Konfigurationsfile. Es bietet somit auch eine Möglichkeit, Profile in einem Thermostat umzuschalten.
===== hinterlegen =====
Die Profile oder Templates werden in einen File abgelegt in der Form
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 an Namen des Templates. Das gleiche Profil kann unter mehreren Namen angesprochen werden. Das erste Template hat den Name "room1", das 2. hat zwei Namen, "room2" und "room3"
* '''tempList...''' ist die jeweiligen Liste der Temperaturen des Tages
===== nutzen =====
Die Kommandos sind
set <rt>_Clima tempListTmpl verify FHEM/tempList.cfg:room1
set <rt>_Clima tempListTmpl restore FHEM/tempList.cfg:room1
* '''FHEM/tempList.cfg:room1''' ist das Template. FHEM/tempList.cfg ist das File, in dem das Template zu suchen ist. room1 ist das Template,welches im File gesucht wird. Wird kein File angegeben wird "template.cfg" im "fhem" directory angenommen.
* '''verify''' vergleicht die gelesene templiste mit dem Template aus dem File. Verify ist default für das Kommando.
* '''restore''' schreibt die Templiste gemäß Template in das Device.

Man kann einem Thermostat das '''Attribut tempListTmpl''' geben. Damit wird der default für dieses Deivce gesetzt.
attr <rt>_Clima tempListTmpl FHEM/tempList.cfg:room1
set <rt>_Clima tempListTmpl
prüft <rt>_Clima gegen FHEM/tempList.cfg:room1
set <rt>_Clima tempListTmpl restore
schreibt das Template FHEM/tempList.cfg:room1 nach <rt>_Clima.

===== Vorschlag =====
Um Templates zu verwalten sollte man das File tempList.cfg im Directory FHEM ablegen. Das Verzeichnis ist im Prinzip egal, wenn es aber im Verzeichnis FHEM liegt kann man es aus dem web-interface editieren.
attr attr <rt>_Clima tempListTmpl FHEM/tempList.cfg:<name>
'''name''' wäre der Name des rt, so z.B. rt_wohnzimmer_Clima.

==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 31.01.2014 gibt es für den HM-CC-RT-DN eine neue Firmware Version (1.2). 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]]

HomeMatic Firmware Update

2014-05-14T08:44:53Z

Strauch: Nachtrag für Update mit Windows

= Varianten für Firmwareupdates =
Seit 2014 ist es möglich bei einige HomeMatic Komponenten selber Firmware Updates durchzuführen. Vorher ging es nur per CCU oder durch einsenden des Gerätes zu 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 =
Noch nicht offiziell implementiert, weiter Infos gibt es im Forum: http://forum.fhem.de/index.php/topic,23329.0.html

= Firmware Update mit CUL/HM-CFG-USB unter Linux =
Für Linux hat mgernoth eine Updatetool programmiert.

Als erstes müssen wir sicher stellen das alle nötigen Pakete installiert sind um das Tool zu installieren und auszuführen
sudo apt-get install libusb-1.0-0-dev && sudo apt-get install git && sudo apt-get install build-essential

Als nächstes laden wir das Tool
git clone git://git.zerfleddert.de/hmcfgusb

und installieren es
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
z.B. Firmware 1.2 für HM-CC-RT-DN:
wget http://www.eq-3.de/Downloads/Software/Firmware/hm_cc_rt_dn_update_V1_2_007_131202.tar.gz
tar -xvf hm_cc_rt_dn_update_V1_2_007_131202.tar.gz

Nun brauchen wir nur noch das Tool ausführen und die Seriennummer des HomeMatic Devices.
Für ein Update mit 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 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 Updatemodus versetzt werden, wie das geht steht in der Readme zur Firmwaredatei (Ist mit im Archiv)

= 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 . Das Update ist damit zur Zeit nur mit dem HM-CFG-USB möglich nicht mit dem HM-CFG-LAN.

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 Device in den Updatemodus versetzte 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 werden, sondern muss als ".tar.gz"-Datei, so wie heruntergeladen, benutzt werden. Außerdem gibt es Probleme, wenn die Datei mit dem Internet Explorer heruntergeladen wurde. Die Datei sollte mit einem anderen Browser heruntergeladen werden.

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

HomeMatic Firmware Update

2014-05-14T08:35:01Z

Strauch:

= Varianten für Firmwareupdates =
Seit 2014 ist es möglich bei einige HomeMatic Komponenten selber Firmware Updates durchzuführen. Vorher ging es nur per CCU oder durch einsenden des Gerätes zu ELV.
Dabei gibt es verschiedene Möglichkeiten das Firmware Update durchzuführen.

= Firmware Update mit CUL/HM-CFG-USB unter FHEM =
Noch nicht offiziell implementiert, weiter Infos gibt es im Forum: http://forum.fhem.de/index.php/topic,23329.0.html

= Firmware Update mit CUL/HM-CFG-USB unter Linux =
Für Linux hat mgernoth eine Updatetool programmiert.

Als erstes müssen wir sicher stellen das alle nötigen Pakete installiert sind um das Tool zu installieren und auszuführen
sudo apt-get install libusb-1.0-0-dev && sudo apt-get install git && sudo apt-get install build-essential

Als nächstes laden wir das Tool
git clone git://git.zerfleddert.de/hmcfgusb

und installieren es
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
z.B. Firmware 1.2 für HM-CC-RT-DN:
wget http://www.eq-3.de/Downloads/Software/Firmware/hm_cc_rt_dn_update_V1_2_007_131202.tar.gz
tar -xvf hm_cc_rt_dn_update_V1_2_007_131202.tar.gz

Nun brauchen wir nur noch das Tool ausführen und die Seriennummer des HomeMatic Devices.
Für ein Update mit 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 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 Updatemodus versetzt werden, wie das geht steht in der Readme zur Firmwaredatei (Ist mit im Archiv)

= 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 . Das Update ist damit zur Zeit nur mit dem HM-CFG-USB möglich nicht mit dem HM-CFG-LAN.

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 werden, sondern muss als ".tar.gz"-Datei, so wie heruntergeladen, benutzt werden. Außerdem gibt es Probleme, wenn die Datei mit dem Internet Explorer heruntergeladen wurde. Die Datei sollte mit einem anderen Browser heruntergeladen werden.

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

HomeMatic Firmware Update

2014-05-14T08:00:01Z

Strauch: Ein Anfang. Bitte alle erweitern die sich gut auskennen, auch gerade was die Homebrew Geräte angeht.