FHEMWiki - Benutzerbeiträge [de]

HM-WDS30-OT2-SM Differenz-Temperatur-Sensor

2016-03-01T07:55:17Z

Barit: /* bekannte Probleme */

{{Infobox Hardware
|Bild=HM-WDS30-OT2-SM.jpg
|Bildbeschreibung=geöffneter HM-WDS30-OT2-SM Differenz-Temperatur-Sensor
|HWProtocol=[[HomeMatic]]
|HWType=[[HomeMatic Type THSensor|THSensor]]
|HWCategory=[[:Kategorie:Temperatursensoren|Temperatursensoren]]
|HWComm=868MHz
|HWChannels=5
|HWVoltage=3V
|HWPowerConsumption= 40 mA max; Standby 3µW
|HWPoweredBy=2x1,5V LR03/Micro AAA
|HWSize=63 x 58 x 35 mm (BxHxT)
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=[http://www.elv.de ELV] / [http://www.eq-3.de eQ-3]
}}

== Features ==
'''Technische Daten:'''
Beide Messfühler werden '''zeitgleich''' ausgewertet und in '''einem''' Funktelegramm gesendet.
Beide Fühlertemperaturen können getrennt verarbeitet werden.
Per Parameter ist es möglich, alle Werte der Kanäle im Status des Devices zu vereinigen.

* Temperatur 1
* Temperatur 2
* Differenz T1-T2
* Differenz T2-T1

* Messbereich: -30 bis +100 °C, Genauigkeit je ±1,5 K, Fühler Plastik und nicht dauerhaft wasserdicht.
* 2 Fühler mit mit je 2,8 m Zuleitung
* Schutzart: IP 65; Gehäuse Aufputz
* Gewicht: 101 g (ohne Batterien)

== Anwendungsszenarien ==
Gerade bei Steuerungsaufgaben mit schnell ändernden Temperaturen ist es von Vorteil, wenn beide Messwerte zeitgleich aufgenommen und gleich lokal verarbeitet werden.
Eingesetzt werden kann der Sensor aufgrund seines Messbereiches bis 100° C (anders als der ansonsten sehr ähnliche einkanalige WDS30-T-0)für Überwachung von Vor- und Rücklauftemperaturen bei Heiz- bzw. Warmwasserkreisläufen.
Nicht geeignet ist er leider für die Steuerung von Thermo-Solar-Anlagen, weil dort im Vorlauf Temeperaturen bis 150° C kurzzeitig entstehen können.

Ein spannender Aspekt ist der Aufbau eines Sonnensensors für Beschattungsaufgaben, den das ELV-Journal beschreibt.

== Inbetriebnahme und Installation ==
Nach Einsetzen der Batterien, während FHEM im Anlernmodus ist, werden das Device und seine 5 Channels problemlos erkannt. Wiederholung des Anlernens durch Drücken des Mikroschalters, bei Erfolg blinkt abschließend eine LED grün.
Reset auf Auslieferungszustand: Taster 5 s drücken bis es rot blinkt, loslassen, erneut 5 s drücken, bis es schnell rot blinkt.

== Betrieb mit FHEM ==
Nach erfolgreichen Pairen sendet das Modul alle 120-180 Sekunden aktuelle Messwerte auf den Kanälen 1-4. Die Events auf Kanälen 1 bis 4 lauten jeweils

=== Channels (Kanäle) ===
==== Channel (Kanal) 01 _T1 ====
Dieser Kanal liefert die Temperatur des ersten Messfühlers zurück.
==== Channel (Kanal) 02 _T2 ====
Dieser Kanal liefert die Temperatur des zweiten Messfühlers zurück.
==== Channel (Kanal) 03 _T1_T2 ====
Dieser Kanal liefert die Differenz (T1 - T2) der Temperatur des ersten Messfühlers zum zweiten Messfühler zurück.
==== Channel (Kanal) 04 _T2_T1 ====
Dieser Kanal liefert die Differenz (T2 - T1) der Temperatur des zweiten Messfühlers zum ersten Messfühler zurück.
==== Channel (Kanal) 05 _Event ====
< Funktion nicht bekannt, ggf. ergänzen >

=== Parameter ===

'''list: register | range | peer | description'''
0: burstRx | literal | | device reacts on Burst options:on,off
0: cyclicInfoMsgDis | 0 to 255 | | cyclic message
0: intKeyVisib | literal | | visibility of internal channel options:visib,invisib
0: localResDis | literal | | local reset disable options:on,off
0: pairCentral | 0 to 16777215 | | pairing to central
0: paramSel | literal | | data transfered to peer options:T1,T1_T2,T2_T1,off,T2

=== Temperaturen in Reading des Devices ===
Um nicht für jeden Kanal ein Logfile zu erstellen und die Temperaturen der einzelnen Kanäle in den Readings des Devices zur Verfügung zu haben, hilft die Definition folgenden userReadings:
attr <HM-WDS30-OT2-SM> userReadings
T1 { ReadingsVal("HM.DiffTemp.FbHz_T1","temperature",0)},
T2 { ReadingsVal("HM.DiffTemp.FbHz_T2","temperature",0)},
T1_T2 { ReadingsVal("HM.DiffTemp.FbHz_T1_T2","temperature",0)},
T2_T1 { ReadingsVal("HM.DiffTemp.FbHz_T2_T1","temperature",0)}

== Fhem-Log ==
=== Device Log ===
2016.02.10 21:40:24 2: CUL_HM Unknown device HM_40448D is now defined
2016.02.10 21:40:24 2: autocreate: define HM_40448D CUL_HM 40448D
2016.02.10 21:40:24 2: autocreate: define FileLog_HM_40448D FileLog ./log/HM_40448D-%Y-%m.log HM_40448D
2016.02.10 21:40:25 3: Device HM_40448D added to ActionDetector with 012:00 time
2016.02.10 21:40:25 3: CUL_HM pair: HM_40448D THSensor, model HM-WDS30-OT2-SM serialNr
2016.02.10 21:40:29 3: Device HM_40448D added to ActionDetector with 012:00 time

=== Event monitor ===
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM battery: ok
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM T1: 34.0
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM T1_T2: 3.4
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM T2_T1: -3.4
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM T2: 31.1
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM_T1 T: 34.0
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM_T1 temperature: 34.0
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM_T1_T2 T: 2.9
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM_T1_T2 temperature: 2.9
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM_T2 T: 31.1
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM_T2 temperature: 31.1
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM_T2_T1 T: -2.9
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM_T2_T1 temperature: -2.9

== bekannte Probleme ==

* Eventuelle Temperatur-Differenzen zwischen den beiden Sensoren können nicht über FHEM beispielsweise durch einen "Offset" ausgeglichen werden, sondern müssen in den weiterverarbeitenden Routinen berücksichtigt werden.
* Manche Geräte scheinen reproduzierbar keine Daten mehr zu senden nachdem ein "set getConfig" zum Gerät gesendet wurde. Das Problem wird im [http://forum.fhem.de/index.php/topic,39125.msg401171.html#msg401171| Forum] diskutiert. Möglicher Workaround ist, das Attribut ''autoReadReg'' mit dem Wert "0_off" hinzuzufügen.

== Links ==

* Manual: (nicht online verfügbar?)
* [http://www.elv.de/differenz-temperatur-sensor-hm-wds30-ot2-sm-komplettbausatz.html Produktseite ELV]

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

HM-LC-Sw1-DR 1fach Schaltaktor Hutschiene

2016-02-15T07:01:59Z

Barit: /* Logbeispiel */ Logifilezeilen ergänzt

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=Platzhalter
|HWProtocol=HomeMatic
|HWType=Aktor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=1
|HWVoltage=230 V
|HWPowerConsumption=0,35 W
|HWPoweredBy=Netz
|HWSize=18 x 65 x 87 mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}

[[HM-LC-Sw1-DR 1fach Schaltaktor Hutschiene|HM-LC-Sw1-DR]] ist ein 1-kanaliger HomeMatic Schaltaktor für die Hutschienenmontage. Er besitzt einen Tastereingang. Damit kann der Aktor auch unabhängig von HomeMatic eingesetzt werden. (bspw. als Treppenhausschalter).

== Features ==
* Schutzart: IP 20
* Schutzklasse: II
* Relais: 1 Schließer (potentialfreier Kontakt)
* Schaltvermögen: 6 A
* Standard-Hutschienengehäuse, 1TE
* Abm. (B x H x T): 18 x 65 x 87 mm

== Hinweise zum Betrieb mit FHEM ==
Das Pairing sollte wie unter [[HomeMatic Devices pairen]] beschrieben durchgeführt werden.

=== Definition ===
Exemplarischer Auszug aus der fhem.cfg:
define HM_41555D CUL_HM 41555D
attr HM_41555D IODev hmusb
attr HM_41555D IOgrp vccu:hmusb
attr HM_41555D autoReadReg 4_reqStatus
attr HM_41555D firmware 2.8
attr HM_41555D model HM-LC-Sw1-DR
attr HM_41555D peerIDs 00000000,
attr HM_41555D serialNr MEQxxxxxxx
attr HM_41555D subType switch
attr HM_41555D webCmd statusRequest:toggle:on:off

=== Attribute ===
<<< folgt >>>

=== Logbeispiel ===
Beim Schalten des Aktors werden folgende Zeilen ins Logfile geschrieben:
2016-02-15_07:56:52 HM_41555D deviceMsg: on (to vccu)
2016-02-15_07:56:52 HM_41555D level: 100
2016-02-15_07:56:52 HM_41555D pct: 100
2016-02-15_07:56:52 HM_41555D on
2016-02-15_07:56:52 HM_41555D timedOn: off

== Bekannte Probleme ==
Keine.

== Links ==
* [http://files.elv.de/Assets/Produkte/14/1413/141379/Downloads/141379_schaltaktor_um.pdf Bedienungsanleitung(PDF)]
* [http://files.elv.de/Assets/Produkte/14/1413/141378/Downloads/141378_aktor_data.pdf Datenblatt(PDF)]

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

HM-LC-SW1-FM Schaltaktor 1-fach UP

2016-02-15T06:58:12Z

Barit: /* Nützliches Zubehör */ Hinweis auf HM-LC-Sw1-DR eingefügt

Homematic Funk-Schaltaktor 1-fach (Unterputz)

== Features ==

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

'''Technische Daten:'''
* Schaltvermögen: 16A bei 230V/50Hz (ohmsche Last)
* Relais: 1x Schließer
* Standby Verbrauch: 0,5W
* Maße(BxHxT): 53x53x30mm

== Hinweise zur Hardware-Installation ==

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

Je nach vorhandenen Schalterdosen empfiehlt es sich bestehende Schalterdosen nach hinten auszuweiten, d.h. die Abdeckung nach hinten heraus zu brechen, da die Aktoren und Kabel nicht gerade sparsam mit dem Platz umgehen. Alternativ könnte man den Aktor auch in eine zusätzliche Schalterdosen unterbringen und diese mit einem Federdeckel abschließen. Dies hat den Vorteil, dass man auch durch relativ dicke Tapete die LED und somit den Zustand des Aktors ablesen kann.

Der Aktor kann auch gänzlich ohne Taster, also nur per ''set''-Befehlen durch Fhem oder per gepeerten Geräten gesteuert werden, jedoch muss zumindest für das Anlernen zeitweise ein Taster angeschlossen werden.

== Hinweise zum Betrieb mit FHEM ==

Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden. Hierfür wird ein am Aktor temporär angeschlossener spannungsfester Taster zwingend benötigt.

# Sicherstellen, dass ''autocreate'' aktiv ist
# Am CUL/HMLAN o.ä. <code>set HMLAN hmPairForSec 60</code>
# Binnen 60 Sekunden Aktor in Anlernmodus bringen (Taster 4s festhalten bis LED blinkt) -> Device wird in fhem angelegt, z.B. als CUL_HM_HM_LC_SW1_FM_2BAD45
# <code>rename <Aktor> <AktorNameNeu></code> -> richtigen Namen zuordnen

=== FHEM Config-Auszug ===

Ein exemplarischer Auszug aus der fhem.cfg:

<pre>
define LichtTerasse CUL_HM 17AEA6
attr LichtTerasse devInfo 010100
attr LichtTerasse firmware 1.9
attr LichtTerasse hmClass receiver
attr LichtTerasse model HM-LC-SW1-FM
attr LichtTerasse room Terasse
attr LichtTerasse serialNr IEQ00xxxx
attr LichtTerasse subType switch
</pre>

=== Mögliche Schaltoperationen ===

Der Aktor versteht folgende Aktionen:
<pre>
set <name> on -> Schaltet den Aktor ein
set <name> off -> Schaltet den Aktor aus
set <name> toggle -> Ändert den Zustand des Aktors, d.h. ein eingeschalteter Aktor wird ausgeschaltet
</pre>

=== Log-Auszug ===

In FHEM ist nach dem Schalten des HM-LC-SW1-FM folgendes Log zu sehen:
<pre>
2012.02.05 16:51:44 2: CUL_HM set LichtTerasse on
2012.02.05 16:52:14 2: CUL_HM set LichtTerasse off
2012.02.05 16:52:15 2: CUL_HM set LichtTerasse toggle
</pre>

== Nützliches Zubehör ==

Wer den Schaltaktor im Sicherungskasten selbst einbauen möchte, z.B. um einen Stromstossschalter zu ersetzen, dem kann folgendes Zubehör empfohlen werden: Hutschienengehäuse CNMB-4V-Kit, Bestellnr. 532659 bei conrad. Das ist zwar sicher auch nicht VdE-konform, aber besser wie ohne. Alternativ kann auch der [[HM-LC-Sw1-DR 1fach Schaltaktor Hutschiene]] zur direkten Montage auf Hutschienen eingesetzt werde.

== Probleme ==

Um den HM-LC-SW1-FM in den Anlernmodus zu versetzen, soll man lt. Anleitung den (temporär) angeschlossenen Taster für 4 Sekunden gedrückt halten. Falls dies bei Ihnen nicht funktioniert, so versuchen Sie den Taster einfach mal ca. 7 bis 8 Sekunden gedrückt zu halten (bis die LED des SW1-FM kurz aufleuchtet).

== Links ==

Ein Integrationsbeispiel ist in [[Jalousie und Beleuchtung in mehreren Räumen]] zu finden.

[http://www.elv-downloads.de/service/manuals/76793_HM_Unterputzschalter_UM.pdf Anleitung (PDF)]

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

HM-LC-Sw1-DR 1fach Schaltaktor Hutschiene

2016-02-15T06:51:14Z

Barit: /* Definition */ Auszug aus der fhem.cfg eingefügt

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=Platzhalter
|HWProtocol=HomeMatic
|HWType=Aktor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=1
|HWVoltage=230 V
|HWPowerConsumption=0,35 W
|HWPoweredBy=Netz
|HWSize=18 x 65 x 87 mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}

[[HM-LC-Sw1-DR 1fach Schaltaktor Hutschiene|HM-LC-Sw1-DR]] ist ein 1-kanaliger HomeMatic Schaltaktor für die Hutschienenmontage. Er besitzt einen Tastereingang. Damit kann der Aktor auch unabhängig von HomeMatic eingesetzt werden. (bspw. als Treppenhausschalter).

== Features ==
* Schutzart: IP 20
* Schutzklasse: II
* Relais: 1 Schließer (potentialfreier Kontakt)
* Schaltvermögen: 6 A
* Standard-Hutschienengehäuse, 1TE
* Abm. (B x H x T): 18 x 65 x 87 mm

== Hinweise zum Betrieb mit FHEM ==
Das Pairing sollte wie unter [[HomeMatic Devices pairen]] beschrieben durchgeführt werden.

=== Definition ===
Exemplarischer Auszug aus der fhem.cfg:
define HM_41555D CUL_HM 41555D
attr HM_41555D IODev hmusb
attr HM_41555D IOgrp vccu:hmusb
attr HM_41555D autoReadReg 4_reqStatus
attr HM_41555D firmware 2.8
attr HM_41555D model HM-LC-Sw1-DR
attr HM_41555D peerIDs 00000000,
attr HM_41555D serialNr MEQxxxxxxx
attr HM_41555D subType switch
attr HM_41555D webCmd statusRequest:toggle:on:off

=== Attribute ===
<<< folgt >>>

=== Logbeispiel ===
<<< folgt >>>

== Bekannte Probleme ==
Keine.

== Links ==
* [http://files.elv.de/Assets/Produkte/14/1413/141379/Downloads/141379_schaltaktor_um.pdf Bedienungsanleitung(PDF)]
* [http://files.elv.de/Assets/Produkte/14/1413/141378/Downloads/141378_aktor_data.pdf Datenblatt(PDF)]

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

HM-Sen-DB-PCB

2016-02-12T10:07:12Z

Barit: Weiterleitung nach HM-Sen-DB-PCB Klingelsignalsensor erstellt

#WEITERLEITUNG [[HM-Sen-DB-PCB Klingelsignalsensor]]

HM-Sen-DB-PCB Klingelsignalsensor

2016-02-12T10:05:35Z

Barit: Seite neu angelegt

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=
|HWProtocol=BidCoS ([[HomeMatic]])
|HWType=Sensor
|HWCategory=Sensor
|HWComm=868,3 MHz
|HWChannels=1
|HWVoltage=3 V
|HWPowerConsumption=30 mA (max)
|HWPoweredBy=2x1,5 V (Micro/AAA/LR03)
|HWSize=68 x 127 x 23 mm (mit Antenne), 68 x 58 x 23 mm (ohne Antenne)
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}

[[HM-Sen-DB-PCB]] ist ein Funk-Klingelsignalsensor, der auf externe Signalspannung reagiert und angelernte HomeMatic-Geräte über Funk steuert.

== Features / Funktionen ==
Die auslösende Signalspannung kann sowohl Gleich- und Wechselspannungen sein die zwischen 5 und 12 V liegt. Das Gerät kann somit direkt in eine bestehende Klingelanlage integriert werden. Alternativ kann ein potentialfreier Taster zur Auslösung verwendet werden.
* Als Sensor zur Spannungserkennung oder als Taster-Sender einsetzbar
* Kann andere HomeMatic-Geräte direkt ansteuern oder Anbindung über Fhem möglich
* lange Batterielebensdauer (ca. 5 Jahre)

== Hinweise zum Betrieb mit Fhem ==
Das Pairing sollte wie unter [[HomeMatic Devices pairen]] beschrieben durchgeführt werden.

== Bekannte Probleme ==
Der Klingelsignalsensor sendet keine zyklische Statusmeldung und Batterieüberwachung. Erst bei Signalerkennung sendet das Gerät den erkannten Tastendruck und liefert den aktuellen Status.

== Weblinks ==
* [http://www.elv.de/homematic-funk-klingelsignalsensor-bausatz.html Produktbeschreibung bei ELV]

[[Kategorie:HomeMatic Components]]

Kategorie Diskussion:HomeBrew

2016-02-11T10:54:08Z

Barit:

Sollten die Beschreibung der Class ID nicht eher in einen passenden Artikel (bspw. [[Neues HomeMatic Device]] oder [[HomeBrew]] einsortiert werden? ClassID ist ja auch nicht HomeBrew spezifisch sondern wird auch bei HomeMatic verwendet. Die Auflistung der Geräte ist m.E. in Ordnung, wird jedoch schon durch die Kategorisierung innerhalb des Artikel zum Gerät erreicht. --[[Benutzer:Barit|Barit]] ([[Benutzer Diskussion:Barit|Diskussion]]) 16:24, 10. Feb. 2016 (CET)
<hr />
:Hallo Barit,
:ich sammle mal meine Kommentare zu deinen Änderungen im Zusammenhang mit "HomeBrew" hier:
:* Kategorie HomeBrew ist Unterkategorie von HomeMatic Devices, daher bitte nicht beide Kategorien auf der gleichen Seite verwenden (wie z.B. derzeit im HomeBrew Artikel).
:* Nachdem Du jetzt einen eigenen Artikel für HomeBrew angelegt hast, fände ich es gut, wenn Artikel/Kategorie ähnlich strukturiert würden wie (z.B.) bei HomeMatic: auf der Kategorieseite eine kurze Erläuterung incl. Namensschema für neue Artikel (+ Hinweis, dass die Regeln der HomeMatic Components Kategorie auch gelten, soweit nicht anderweitig erwähnt) und die ganzen übrigen Informationen auf der HomeBrew Seite
:* Du hast mehrfach mit dem Hinweis ''Links auf Kategorien aus Artikel sollte vermieden werden'' Bezüge auf ''':Kategorie:Homebrew''' "umgebaut". Solange das kontextabhängig geschieht (also je nach dem, ob ein Link auf den Begriff Homebrew oder ein Link auf die Liste der verfügbaren Geräte angebracht ist), bin ich damit einverstanden; als "generelle Regel" haben wir das hier im Fhem-Wiki bisher nicht verankert.
:* Wenn ClassID (oder meinst Du ModelID?) generell für HomeMatic gilt, sollte es auch dahin (in den HomeMatic Basisartikel); hier sieht es aber für mich eher so aus, als sollten die Unterschiede in der Benutzung der ModelID (Wertebereiche) festgelegt werden
:* Bei der Auflistung der Geräte sollte klar sein (bzw. klargestellt werden), ob das exemplarisch ist oder ob ein Anspruch auf Vollständigkeit besteht
:Ich denke, das war's erstmal. Herzlichen Dank übrigens für Deine bisherige Arbeit im Wiki. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 07:05, 11. Feb. 2016 (CET)
<hr />
Hi Peter, besten Dank für die Hinweise. Im Thema HomeBrew bin ich inhaltlich nicht wirklich drin, hatte aber einige strukturelle Schwierigkeiten im Wiki entdeckt. Den ersten deiner Punkte habe ich bereits umgesetzt. Den Hinweis ''Links auf Kategorien aus Artikel sollte vermieden werden'' habe ich eingefügt, da es zumindest bei Wikipedia so gehandhabt wird. Wo es Sinn macht, können wir hier natürlich anders verfahren. Die eher technischen Dinge zu Homebrew würde ich dann einem "Experten" überlassen oder zumindest deren Input aufgreifen.
Besten Gruß, Barit --[[Benutzer:Barit|Barit]] ([[Benutzer Diskussion:Barit|Diskussion]]) 11:54, 11. Feb. 2016 (CET)

HomeBrew

2016-02-11T10:42:02Z

Barit: Entfernen der Kategorie "HomeMatic Devices" da die Kategorie HomeBrew Unterkategorie von "HomeMatic Devices" ist

Zur Abgrenzung von HomeMatic und zur Vermeidung von Urheberrechtsprobleme werden Geräte, die mit Hilfe der [[HomeMatic_Asksin_Library | AskSin Library]] das Protokoll '''BidCos''' der HomeMatic-Devices implementieren und dabei HomeMatic-Geräte nachbauen (emulieren) als HomeBrew-Geräte bezeichnet. Beispiele für HomeBrew-Geräte sind folgende Devices:

* [[HB-UW-Sen-THPL#Innensensor|HB-UW-Sen-THPL-I]], [[HB-UW-Sen-THPL#Au.C3.9Fensensor|HB-UW-Sen-THPL-O]]
* HB-PB-1-6 Homematic-Homebrew-Taster ({{Link2Forum|Topic=19657|Message=132656|LinkText=Thread dazu im Fhem-Forum)}}
* HB-IRU (HM <-> Infrarot-Umsetzer)
* HB-UW-Sen-IMP (HM Impuls-Zähler-Sensor)
* HB-1W-''xxx''
* [[HBW-1W-T10|HBW-1W-T10]]

[[Kategorie:HomeBrew]]

HM-WDS30-OT2-SM Differenz-Temperatur-Sensor

2016-02-11T10:38:01Z

Barit: größere Überarbeitung und Ergänzungen

{{Infobox Hardware
|Bild=HM-WDS30-OT2-SM.jpg
|Bildbeschreibung=geöffneter HM-WDS30-OT2-SM Differenz-Temperatur-Sensor
|HWProtocol=HomeMatic
|HWType=Temeperatursensor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=5
|HWVoltage=3V
|HWPowerConsumption= 40 mA max; Standby 3µW
|HWPoweredBy=2x1,5V LR03/Micro AAA
|HWSize=63 x 58 x 35 mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}

== Features ==
'''Technische Daten:'''
Beide Messfühler werden '''zeitgleich''' ausgewertet und in '''einem''' Funktelegramm gesendet.
Beide Fühlertemperaturen können getrennt verarbeitet werden.
Per Parameter ist es möglich, alle Werte der Kanäle im Status des Devices zu vereinigen.

* Temperatur 1
* Temperatur 2
* Differenz T1-T2
* Differenz T2-T1

* Messbereich: -30 bis +100 °C, Genauigkeit je ±1,5 K, Fühler Plastik und nicht dauerhaft wasserdicht.
* 2 Fühler mit mit je 2,8 m Zuleitung
* Schutzart: IP 65; Gehäuse Aufputz
* Gewicht: 101 g (ohne Batterien)

== Anwendungsszenarien ==
Gerade bei Steuerungsaufgaben mit schnell ändernden Temperaturen ist es von Vorteil, wenn beide Messwerte zeitgleich aufgenommen und gleich lokal verarbeitet werden.
Eingesetzt werden kann der Sensor aufgrund seines Messbereiches bis 100° C (anders als der ansonsten sehr ähnliche einkanalige WDS30-T-0)für Überwachung von Vor- und Rücklauftemperaturen bei Heiz- bzw. Warmwasserkreisläufen.
Nicht geeignet ist er leider für die Steuerung von Thermo-Solar-Anlagen, weil dort im Vorlauf Temeperaturen bis 150° C kurzzeitig entstehen können.

Ein spannender Aspekt ist der Aufbau eines Sonnensensors für Beschattungsaufgaben, den das ELV-Journal beschreibt.

== Inbetriebnahme und Installation ==
Nach Einsetzen der Batterien, während FHEM im Anlernmodus ist, werden das Device und seine 5 Channels problemlos erkannt. Wiederholung des Anlernens durch Drücken des Mikroschalters, bei Erfolg blinkt abschließend eine LED grün.
Reset auf Auslieferungszustand: Taster 5 s drücken bis es rot blinkt, loslassen, erneut 5 s drücken, bis es schnell rot blinkt.

== Betrieb mit FHEM ==
Nach erfolgreichen Pairen sendet das Modul alle 120-180 Sekunden aktuelle Messwerte auf den Kanälen 1-4. Die Events auf Kanälen 1 bis 4 lauten jeweils

=== Channels (Kanäle) ===
==== Channel (Kanal) 01 _T1 ====
Dieser Kanal liefert die Temperatur des ersten Messfühlers zurück.
==== Channel (Kanal) 02 _T2 ====
Dieser Kanal liefert die Temperatur des zweiten Messfühlers zurück.
==== Channel (Kanal) 03 _T1_T2 ====
Dieser Kanal liefert die Differenz (T1 - T2) der Temperatur des ersten Messfühlers zum zweiten Messfühler zurück.
==== Channel (Kanal) 04 _T2_T1 ====
Dieser Kanal liefert die Differenz (T2 - T1) der Temperatur des zweiten Messfühlers zum ersten Messfühler zurück.
==== Channel (Kanal) 05 _Event ====
< Funktion nicht bekannt, ggf. ergänzen >

=== Parameter ===

'''list: register | range | peer | description'''
0: burstRx | literal | | device reacts on Burst options:on,off
0: cyclicInfoMsgDis | 0 to 255 | | cyclic message
0: intKeyVisib | literal | | visibility of internal channel options:visib,invisib
0: localResDis | literal | | local reset disable options:on,off
0: pairCentral | 0 to 16777215 | | pairing to central
0: paramSel | literal | | data transfered to peer options:T1,T1_T2,T2_T1,off,T2

=== Temperaturen in Reading des Devices ===
Um nicht für jeden Kanal ein Logfile zu erstellen und die Temperaturen der einzelnen Kanäle in den Readings des Devices zur Verfügung zu haben, hilft die Definition folgenden userReadings:
attr <HM-WDS30-OT2-SM> userReadings
T1 { ReadingsVal("HM.DiffTemp.FbHz_T1","temperature",0)},
T2 { ReadingsVal("HM.DiffTemp.FbHz_T2","temperature",0)},
T1_T2 { ReadingsVal("HM.DiffTemp.FbHz_T1_T2","temperature",0)},
T2_T1 { ReadingsVal("HM.DiffTemp.FbHz_T2_T1","temperature",0)}

== Fhem-Log ==
=== Device Log ===
2016.02.10 21:40:24 2: CUL_HM Unknown device HM_40448D is now defined
2016.02.10 21:40:24 2: autocreate: define HM_40448D CUL_HM 40448D
2016.02.10 21:40:24 2: autocreate: define FileLog_HM_40448D FileLog ./log/HM_40448D-%Y-%m.log HM_40448D
2016.02.10 21:40:25 3: Device HM_40448D added to ActionDetector with 012:00 time
2016.02.10 21:40:25 3: CUL_HM pair: HM_40448D THSensor, model HM-WDS30-OT2-SM serialNr
2016.02.10 21:40:29 3: Device HM_40448D added to ActionDetector with 012:00 time

=== Event monitor ===
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM battery: ok
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM T1: 34.0
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM T1_T2: 3.4
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM T2_T1: -3.4
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM T2: 31.1
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM_T1 T: 34.0
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM_T1 temperature: 34.0
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM_T1_T2 T: 2.9
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM_T1_T2 temperature: 2.9
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM_T2 T: 31.1
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM_T2 temperature: 31.1
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM_T2_T1 T: -2.9
2016-02-11 11:17:26 CUL_HM HM_40448D CUL_HM_T2_T1 temperature: -2.9

== bekannte Probleme ==

* Eventuelle Temperatur-Differenzen zwischen den beiden Sensoren können nicht über FHEM beispielsweise durch einen "Offset" ausgeglichen werden, sondern müssen in den weiterverarbeitenden Routinen berücksichtigt werden.
* Manche Geräte scheinen reproduzierbar keine Daten mehr zu senden nachdem ein "set getConfig" zum Gerät gesendet wurde. Das Problem wird im [http://forum.fhem.de/index.php/topic,39125.msg401171.html#msg401171| Forum] diskutiert

== Links ==

Manual: (nicht online verfügbar?)

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

HomeMatic Namen verstehen

2016-02-10T15:27:43Z

Barit: Links auf Kategorien aus Artikel sollte vermieden werden. Daher Link zum Artikel "HomeBrew" gesetzt

[[HomeMatic]] Sender und Aktoren sind oft mit den Bezeichnungen des Herstellers (die ELV Tochtergesellschaft eQ-3) benannt.

Da es sich um Buchstaben und Zahlenkürzel handelt, ist nicht immer sofort erkennbar, um was für ein Gerät es sich handelt.

== Namensschema ==
Die Namen sind jedoch meist nach einem Schema aufgebaut, der Aufbau ist:

Medientyp - Generelle Funktion - Sensor/Sender/Aktorfunktion [mit Taster] - [Montageart]

also z. B. HM-LC-SW1-FM

Die Gross- und Kleinschreibung wird nicht durchgängig stringent eingehalten. So wird die Aktorfunktion Schalter mal mit SW, mal mit Sw bezeichnet.
[ ] umschliessen optionale Bestandteile

Ferner hält sich ELV nicht vollumfänglich an sein Namenschema.
Die LED Statusanzeige heisst z. B. HM-OU-LED16, müsste nach Namenschema aber eigentlich HM-Dis-16 heissen.

Es bedeuten (Liste unvollständig):

== Medientyp ==
* HM = HomeMatic Funk
* HMW = HomeMatic Wired
* HB = [[HomeBrew]] = HomeMatic Eigenentwicklungen, Nachbauten und Erweiterungen
* HBW = [[HomeBrew]] = HomeMatic-Wired Eigenentwicklungen, Nachbauten und Erweiterungen

== Funktion ==
* CC = Heizungssteuerung (Climate Control)
* LC = Licht/Strom (Light Control)
* SEC = Überwachung (Security) (auch Sec)
* RC = Fernbedienung (Radio Control)
* Sen = Sensor
* WDSxx = Feuchte- und/oder Temperatursensor
* PB = Wandtaster (Push Button)
* PBI = Tasterschnittstelle (Push Button Interface)
* DIMxT = Dimmer mit x Kanälen mit Phasenschnittsteuerung (Thyristor Dimmer)
* DIMxL = Dimmer mit x Kanälen Leistungsdimmer für ohmsche/induktive Lasten
* OU = Klang
* Dis = Anzeige
* 1W = Ankopplung an [[:Kategorie:1-Wire|1-Wire Komponenten]]

== Sensor/Sender/Aktorfunktion ==
* SWx = Schaltaktor mit x Kanälen (Switch) (oft auch Swx)
* TiS = Neigungssensor (Tilt Sensor)
* Px = Paniksender mit x Kanälen (Panic)
* WDS = Wassermelder
* SC = Tür- / Fenster / Schliesserkontakt (Shutter Contact)
* EP = (Sensor für) Elektrische Impulse
* TH = Temperatur und Feuchtesensor (Temperature & Humidity)
* T = Temperatursensor
* MDIR = Infrarot Bewegungsmelder (Motion Detector Infrared)
* BLx = Jalousieaktor mit x Kanälen (Blind) (oft auch Blx)
* VD = Stellantrieb (Ventile Drive)
* SCD = Luftgütesensor (Sensor Carbon Dioxide)
* CF = Gong (Chime)
* KEY = Schließsystem
* 2 = Zweikanal
* 4 = Vierkanal
* 12 = Zwölfkanal
* 16 = Sechzehnkanal
* 19 = Neunzehnkanal

== Montageart ==
Optional, nur soweit bedeutsam, z. B. um Geräte ansonsten gleicher Funktion zu unterscheiden, wird die Montageart angefügt:

* FM = Unterputz (Floating Mount)
* WM = beliebige Festmontage, meist Aufklebegerät (Wall Mount)
* SM = Aufputz (Surface Mount)
* CV = Zwischendeckenmontage (Ceiling mount)
* PL = Zwischenstecker (Plug) (oft auch Pl)
* DR = Hutschienenmontage (DIN Rail)
* O = Aussenmontage (Outdoor)
* I = Innenmontage (Indoor)
* T = Frei aufstellbares Gerät (eventuell von "Tabletop")

==Sonstiges==

* B = schwarz
* SW = weiss
* PCB = Bausatz / Platinenversion

== Beispiel ==
[[HM-LC-SW1-FM Schaltaktor 1-fach UP|HM-LC-SW1-FM]] = HomeMatic Funk - Licht/Strom - Schaltaktor mit einem Kanal - Unterputzmontage

[[HM-LC-Sw2PB-FM Schaltaktor mit Tasteraufsatz 2fach|HM-LC-Sw2PB-FM]] = HomeMatic Funk - Licht/Strom - Schaltaktor mit zwei Kanälen UND Tastern - Unterputzmontage

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

Kategorie Diskussion:HomeBrew

2016-02-10T15:24:42Z

Barit:

Kategorie Diskussion:HomeBrew

2016-02-10T15:24:15Z

Barit:

Kategorie Diskussion:HomeBrew

2016-02-10T15:22:10Z

Barit: Vorschlag die Beschreibung der ClassID zu verschieben --~~~~

HomeMatic

2016-02-10T15:15:44Z

Barit: /* Prototokoll */ Aktualisierung des Link für HomeBrew. Statt Link auf die Kategorie nun auf den Artikel

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Besondere Entites ==

=== Virtuelle Entities ===
Virtuelle Entities sind nicht reale HM Devices und Kanäle. Man kann sie als Sender und Empfänger nutzen, auch im Zusammenhang mit Rauchmeldern oder zur Steuerung von Heizungsventilen. Die spezifischen Anwendungen sind im entsprechenden Kapitel nachzulesen. 
Angelegt wird das Device, dann wird per Kommando eine Anzahl Kanäle angelegt.
define <virtDev> CUL_HM 112233
set <virtDev> virtual 10
jetzt hat man ein virtuelles Device mit 10 Kanälen angelegt.
Die die gültigen Kommandos kann man wie immer mit '''get <entity> cmdList''' erfahren. 
Auch einem Virtuellen Device sollte man das '''Attribut IODev setzen '''.
=== IO Entities ===
Analog virtuellen Entities kann man auch IO entities erzeugen. IO ist nicht ganz korrekt, eigentlich sind es Kanäle einer Zentrale. Da diese in FHEM nicht abgebildet wird sind sie teilweise in den IOs realisiert. 
Faktisch ist es ein Kanal, der der HMId des gewählten IO device zugeordnet ist. Aktuell wird dieser Kanal nicht in FHEM dargestellt. Man kann diese Entity jedoch peeren. 
Man kann jeder HMId bis zu 50 Kanäle zuweisen. Da mehrere IO devices die gleiche HMId nutzen können, teilen sich diese in diesem Fall die Kanäle.

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

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

* readings
** Activity: entsprechend dem actStatus.

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

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

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

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

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

== Tipps / HowTos / Beispiele ==

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

== Probleme ==

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

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

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

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

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

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

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

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

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

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

Siehe auch: [[1% Regel]]

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

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

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

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

HomeBrew

2016-02-10T15:13:32Z

Barit: Seite neu angelegt, da es bisher lediglich eine Kategorie-Seite für HomeBrew gibt.

HomeMatic

2016-02-10T14:43:39Z

Barit: /* Prototokoll */ Link auf HomeBrew aktualisiert

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Besondere Entites ==

=== Virtuelle Entities ===
Virtuelle Entities sind nicht reale HM Devices und Kanäle. Man kann sie als Sender und Empfänger nutzen, auch im Zusammenhang mit Rauchmeldern oder zur Steuerung von Heizungsventilen. Die spezifischen Anwendungen sind im entsprechenden Kapitel nachzulesen. 
Angelegt wird das Device, dann wird per Kommando eine Anzahl Kanäle angelegt.
define <virtDev> CUL_HM 112233
set <virtDev> virtual 10
jetzt hat man ein virtuelles Device mit 10 Kanälen angelegt.
Die die gültigen Kommandos kann man wie immer mit '''get <entity> cmdList''' erfahren. 
Auch einem Virtuellen Device sollte man das '''Attribut IODev setzen '''.
=== IO Entities ===
Analog virtuellen Entities kann man auch IO entities erzeugen. IO ist nicht ganz korrekt, eigentlich sind es Kanäle einer Zentrale. Da diese in FHEM nicht abgebildet wird sind sie teilweise in den IOs realisiert. 
Faktisch ist es ein Kanal, der der HMId des gewählten IO device zugeordnet ist. Aktuell wird dieser Kanal nicht in FHEM dargestellt. Man kann diese Entity jedoch peeren. 
Man kann jeder HMId bis zu 50 Kanäle zuweisen. Da mehrere IO devices die gleiche HMId nutzen können, teilen sich diese in diesem Fall die Kanäle.

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

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

* readings
** Activity: entsprechend dem actStatus.

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

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

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

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

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

== Tipps / HowTos / Beispiele ==

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

== Probleme ==

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

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

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

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

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

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

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

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

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

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

Siehe auch: [[1% Regel]]

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

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

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

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

HomeMatic

2016-02-10T13:00:36Z

Barit: /* Probleme */ Typo

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

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

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

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

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

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

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

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

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

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

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

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

Das Protokoll ''BidCoS'' wurde zum großen Teil entschlüsselt, seine offen verfügbare Variante heißt ''AskSin''. Unter Verwendung der AskSin-Library entstehen derzeit erste Geräte, die in das HomeMatic-System eingebunden werden können. Zur Unterscheidung zwischen HM und den neuen Geräten werden diese als HomeBrew (HB) bezeichnet, siehe hier [[Kategorie:HomeBrew]]
=Betrieb mit Fhem=
Die Kenntnis des Dokumentes [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Einsteigerdokuments "Heimautomatisierung mit Fhem"] wird vorausgesetzt. Im Anhang dieses Dokuments findet sich ein Teil über den Aufbau und die Funktion von HM-Geräten.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Besondere Entites ==

=== Virtuelle Entities ===
Virtuelle Entities sind nicht reale HM Devices und Kanäle. Man kann sie als Sender und Empfänger nutzen, auch im Zusammenhang mit Rauchmeldern oder zur Steuerung von Heizungsventilen. Die spezifischen Anwendungen sind im entsprechenden Kapitel nachzulesen. 
Angelegt wird das Device, dann wird per Kommando eine Anzahl Kanäle angelegt.
define <virtDev> CUL_HM 112233
set <virtDev> virtual 10
jetzt hat man ein virtuelles Device mit 10 Kanälen angelegt.
Die die gültigen Kommandos kann man wie immer mit '''get <entity> cmdList''' erfahren. 
Auch einem Virtuellen Device sollte man das '''Attribut IODev setzen '''.
=== IO Entities ===
Analog virtuellen Entities kann man auch IO entities erzeugen. IO ist nicht ganz korrekt, eigentlich sind es Kanäle einer Zentrale. Da diese in FHEM nicht abgebildet wird sind sie teilweise in den IOs realisiert. 
Faktisch ist es ein Kanal, der der HMId des gewählten IO device zugeordnet ist. Aktuell wird dieser Kanal nicht in FHEM dargestellt. Man kann diese Entity jedoch peeren. 
Man kann jeder HMId bis zu 50 Kanäle zuweisen. Da mehrere IO devices die gleiche HMId nutzen können, teilen sich diese in diesem Fall die Kanäle.

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

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

* readings
** Activity: entsprechend dem actStatus.

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

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

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

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

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

== Tipps / HowTos / Beispiele ==

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

== Probleme ==

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

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

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

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

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

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

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

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

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

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

Siehe auch: [[1% Regel]]

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

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

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

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

HomeMatic Namen verstehen

2016-02-10T12:58:51Z

Barit: /* Beispiel */ Links zu den genannten Beispielaktoren eingefügt

[[HomeMatic]] Sender und Aktoren sind oft mit den Bezeichnungen des Herstellers (die ELV Tochtergesellschaft eQ-3) benannt.

Da es sich um Buchstaben und Zahlenkürzel handelt, ist nicht immer sofort erkennbar, um was für ein Gerät es sich handelt.

== Namensschema ==
Die Namen sind jedoch meist nach einem Schema aufgebaut, der Aufbau ist:

Medientyp - Generelle Funktion - Sensor/Sender/Aktorfunktion [mit Taster] - [Montageart]

also z. B. HM-LC-SW1-FM

Die Gross- und Kleinschreibung wird nicht durchgängig stringent eingehalten. So wird die Aktorfunktion Schalter mal mit SW, mal mit Sw bezeichnet.
[ ] umschliessen optionale Bestandteile

Ferner hält sich ELV nicht vollumfänglich an sein Namenschema.
Die LED Statusanzeige heisst z. B. HM-OU-LED16, müsste nach Namenschema aber eigentlich HM-Dis-16 heissen.

Es bedeuten (Liste unvollständig):

== Medientyp ==
* HM = HomeMatic Funk
* HMW = HomeMatic Wired
* HB = [[:Kategorie:HomeBrew|HomeBrew]] = HomeMatic Eigenentwicklungen, Nachbauten und Erweiterungen
* HBW = [[:Kategorie:HomeBrew|HomeBrew]] = HomeMatic-Wired Eigenentwicklungen, Nachbauten und Erweiterungen

== Funktion ==
* CC = Heizungssteuerung (Climate Control)
* LC = Licht/Strom (Light Control)
* SEC = Überwachung (Security) (auch Sec)
* RC = Fernbedienung (Radio Control)
* Sen = Sensor
* WDSxx = Feuchte- und/oder Temperatursensor
* PB = Wandtaster (Push Button)
* PBI = Tasterschnittstelle (Push Button Interface)
* DIMxT = Dimmer mit x Kanälen mit Phasenschnittsteuerung (Thyristor Dimmer)
* DIMxL = Dimmer mit x Kanälen Leistungsdimmer für ohmsche/induktive Lasten
* OU = Klang
* Dis = Anzeige
* 1W = Ankopplung an [[:Kategorie:1-Wire|1-Wire Komponenten]]

== Sensor/Sender/Aktorfunktion ==
* SWx = Schaltaktor mit x Kanälen (Switch) (oft auch Swx)
* TiS = Neigungssensor (Tilt Sensor)
* Px = Paniksender mit x Kanälen (Panic)
* WDS = Wassermelder
* SC = Tür- / Fenster / Schliesserkontakt (Shutter Contact)
* EP = (Sensor für) Elektrische Impulse
* TH = Temperatur und Feuchtesensor (Temperature & Humidity)
* T = Temperatursensor
* MDIR = Infrarot Bewegungsmelder (Motion Detector Infrared)
* BLx = Jalousieaktor mit x Kanälen (Blind) (oft auch Blx)
* VD = Stellantrieb (Ventile Drive)
* SCD = Luftgütesensor (Sensor Carbon Dioxide)
* CF = Gong (Chime)
* KEY = Schließsystem
* 2 = Zweikanal
* 4 = Vierkanal
* 12 = Zwölfkanal
* 16 = Sechzehnkanal
* 19 = Neunzehnkanal

== Montageart ==
Optional, nur soweit bedeutsam, z. B. um Geräte ansonsten gleicher Funktion zu unterscheiden, wird die Montageart angefügt:

* FM = Unterputz (Floating Mount)
* WM = beliebige Festmontage, meist Aufklebegerät (Wall Mount)
* SM = Aufputz (Surface Mount)
* CV = Zwischendeckenmontage (Ceiling mount)
* PL = Zwischenstecker (Plug) (oft auch Pl)
* DR = Hutschienenmontage (DIN Rail)
* O = Aussenmontage (Outdoor)
* I = Innenmontage (Indoor)
* T = Frei aufstellbares Gerät (eventuell von "Tabletop")

==Sonstiges==

* B = schwarz
* SW = weiss
* PCB = Bausatz / Platinenversion

== Beispiel ==
[[HM-LC-SW1-FM Schaltaktor 1-fach UP|HM-LC-SW1-FM]] = HomeMatic Funk - Licht/Strom - Schaltaktor mit einem Kanal - Unterputzmontage

[[HM-LC-Sw2PB-FM Schaltaktor mit Tasteraufsatz 2fach|HM-LC-Sw2PB-FM]] = HomeMatic Funk - Licht/Strom - Schaltaktor mit zwei Kanälen UND Tastern - Unterputzmontage

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

Kopp Allgemein

2016-02-10T10:46:07Z

Barit: Ergänzender Hinweis auf das Kopp Free-control System und Link zur Hersteller-HP

Allgemeine Informationen zur Steuerung von Kopp Aktuatoren via FHEM. Das vom Hersteller Kopp unter dem Namen [http://www.kopp.eu/de/service/praktische-tipps/technische-informationen-zum-funk-system-free-control Free-control] angebotene Funk-System unterstützt verschieden Aktoren und Schalter zur Steuerung in Haus und Wohnung.
 
== Allgemeine Hinweise ==
 
=== Derzeit unterstützte Funkmodule ===
CCD
CUL Version 3
nanoCUL
 
=== Unterstützte Aktuatoren ===
Folgende Kopp Aktuatoren werden zur Zeit unterstützt:
''8011.00 = Dimmer''
''8080.01 = Schalter''
''8080.02 = Rolladenschalter''
''8080.04 = Timer/Schalter'' (bisher nur im RAW Mode)

Hinweis:

Manche Aktoren konnen in verschiedenen Modi betrieben werden 
a) Einzel Taste (jeder Tastendruck toggelt den Zustand) 
b) Zwei Tasten Mode (Bsp.: Taste 1 schaltet ein, Taste 2 schaltet aus). 
'''Im Zwei Tastenmode müssen beide Tasten in einem Anlernzyklus angelernt werden''' (Anlernvorgang: siehe Kopp Handbuch)
 

=== Kopp Sender auswerten ===

Um erste FHEM Erfahrungen mit Kopp Sender und Aktuatoren zu machen ist es sinnvoll
innerhalb von FHEM ein Device anzulegen, das die selben Kommando versendet wie ein vorhandener Kopp Sender.
Nachdem z.B. einem CUL USB Stick das Kopp Protokoll zugeswiesen wurde können in der FHEM Oberfläche
über den Link "CUL_0" (mein Beispiel) vom Kopp Sender übermittelte Telegramme ausgewertet werden.
Drückt man danach eine Taste des Senders und aktualisiert das Browser Fensert, ist dort ein Eintrag ähnlich:

''RAWMSG kr07C2AD1A30CC0F0328''

zu sehen.
Dabei handelt es sich um die vom Sender gesendeten Roh Daten, die wir teilweise innerhalb von FHEM wiederverwenden.

Aufbau der Rohdaten:
kr07C2AD1A30CC0F0328
|| |||| || ++-------- '''Transmitter Code 2'''
|| |||| ++-------------- '''Keycode'''
|| ++++------------------ '''Transmitter Code 1'''
++------------------------ kr wird von der culfw bei Empfang einer Kopp Botschaft als Kennung gesendet

Keycode und Tranmitter Code 1/2 werden zur Definition eines Kopp Devices in FHEM benötig.
 
== Erste Schritte ==
=== Kopp Protokoll aktivieren / einem Funk Device zuordnen ===
Damit FHEM in der Lage ist mit Kopp Devices zu kommunizieren, muss als erster Schritt das Kopp Protokoll aktiviert werden.
Dies erfolgt indem die Funk Hardware definiert wird (z.B. CUL Version3, CCD) das Attribut "rfmode KOPP_FC" zugewiesen wird.

Bsp.:
:<code>define CUL_0 CUL /dev/ttyACM0@38400 1234</code>
:<code>attr CUL_0 rfmode KOPP_FC</code>
Details zur Definition einen CUL Devices kann man in der Commandref (FHEM Oberfläche -> Commandref -> CUL) nachlesen

'''Unbedingt beachten:'''
Einem CUL oder CCD Device darf nebem dem Kopp Protokoll '''kein''' weiteres Protokoll zugewiesen werden 
 

=== Beispiele zur Festlegung von Schaltern, Dimmer und anderen Aktuatoren ===
Syntax:
define DimmerDevice_OnOff KOPP_FC 65 FA5E 02 55 75
|||||||||||||||||| ||||||| || |||| || || ++- Keycode 3 (Taster 3, optional)
|||||||||||||||||| ||||||| || |||| || ++---- Keycode 2 (Taster 2, optional)
|||||||||||||||||| ||||||| || |||| ++------- Transmittercode 2 (fix)
|||||||||||||||||| ||||||| || ++++---------- Transmittercode 1 (fix)
|||||||||||||||||| ||||||| ++--------------- Keycode 1 (Taster 1)
|||||||||||||||||| +++++++------------------ Zu nutzendes Funkprotokoll=KOPP_FC
++++++++++++++++++-------------------------- Name des neu definierten Devices (frei wählbar)
Die Tastencodes und Transmittercodes müssen jeweils den Codes eines Kopp Senders entsprechen oder dem entsprechenden Aktuator angelernt werden.
(siehe Kopp Handbuch)
 
==== Darstellung in der FHEM Oberflache ====
Folgende Beispiele in die fhem.cfg kopieren, das Ergebnis ist im Raum "Test" zu finden (siehe Bild) 
 
[[Datei:Kopp-Aktuatoren.jpg]]
 
==== Dimmer (8011.00), über einen Taster gesteuert (on/off, dimm, stop)====
Für dieses Devide ist ein Tastencode festzulegen.

<code>define Dimmer KOPP_FC 65 FA5E 02</code> 
<code>attr Dimmer IODev CUL_0</code> 
<code>attr Dimmer devStateIcon OnOff:toggle:dimm dimm:dim50%:stop stop:on:dimm off:toggle:dimm</code> 
<code>attr Dimmer eventMap on:OnOff dimm:dimm stop:stop</code> 
<code>attr Dimmer group Dimmer_1KeyMode</code> 
<code>attr Dimmer model Dimm_8011_00</code> 
<code>attr Dimmer room Test</code> 
<code>attr Dimmer webCmd OnOff:dimm:stop</code> 
 
==== Dimmer (8011.00), über drei Taster gesteuert (on, off, dimm, stop) ====
'''Achtung:''' hier müssen zwingend 3 Tastencodes definiert werden. 
Die Software macht hier noch keine Fehlerprüfung, fehlenden Tastencodes könnte unerwartetes Verhalten der Devices zur Folge haben. 
<code>define DimmerDevice_OnOff KOPP_FC 65 FA5E 02 55 75</code> 
<code>attr DimmerDevice_OnOff IODev CUL_0</code> 
<code>attr DimmerDevice_OnOff devStateIcon dimm:dim50%:stop stop:on:off on:on:off off:off:on</code> 
<code>attr DimmerDevice_OnOff group Dimmer_Via_KOPP_FC_3TastenMode</code> 
<code>attr DimmerDevice_OnOff model Dimm_8011_00_3Key</code> 
<code>attr DimmerDevice_OnOff room Test</code> 
 
<code>define DimmerDevice_Dimm dummy</code> 
<code>attr DimmerDevice_Dimm devStateIcon dimm:dim50%:stop stop:off:dimm</code> 
<code>attr DimmerDevice_Dimm group Dimmer_Via_KOPP_FC_3TastenMode</code> 
<code>attr DimmerDevice_Dimm room Test</code> 
<code>attr DimmerDevice_Dimm webCmd dimm:stop</code> 
<code>define DimmerDevice_DimmInAction notify DimmerDevice_Dimm set DimmerDevice_OnOff $EVENT</code> 
 
==== Rolladen (8080.02), über zwei Taster gesteuert (top, up, stop, down, bottom) ====
'''Achtung:''' hier müssen zwingend 2 Tastencodes definiert werden. 
<code>define TasteUp KOPP_FC 10 C2AD 03 00</code> 
<code>attr TasteUp IODev CUL_0</code> 
<code>attr TasteUp devStateIcon up:fts_shutter_up down:fts_shutter_down stop:fts_shutter_updown top:fts_shutter_10 bottom:fts_shutter_90</code> 
<code>attr TasteUp eventMap up:up down:down stop:stop top:top bottom:bottom</code> 
<code>attr TasteUp group Rolladen</code> 
<code>attr TasteUp model Blind_8080_02</code> 
<code>attr TasteUp room Test</code> 
<code>attr TasteUp webCmd top:up:stop:down:bottom</code> 
 
==== Schalter/Switch (8080.01), über zwei Taster gesteuert (on, off) ====
'''Achtung:''' hier müssen zwingend 2 Tastencodes definiert werden. 
<code>define 2Switch KOPP_FC 30 C2AD 03 20</code> 
<code>attr 2Switch IODev CUL_0</code> 
<code>attr 2Switch group Switch</code> 
<code>attr 2Switch model Switch_8080_01_2Key</code> 
<code>attr 2Switch room Test</code> 
<code>attr 2Switch webCmd on:off</code> 
 
==== Schalter/Switch (8080.01), über einen Taster gesteuert (on, off) ====
Jeder Tastendruck toggelt den Zustand. 
<code>define Switch KOPP_FC 00 C2AD 03</code> 
<code>attr Switch IODev CUL_0</code> 
<code>attr Switch group Switch</code> 
<code>attr Switch model Switch_8080_01</code> 
<code>attr Switch room Test</code>

HM-LC-Sw1-DR 1fach Schaltaktor Hutschiene

2016-02-10T10:19:32Z

Barit: Seite neu angelegt

HM-WDS30-OT2-SM Differenz-Temperatur-Sensor

2016-02-10T09:07:38Z

Barit: Foto eingefügt

{{Infobox Hardware
|Bild=HM-WDS30-OT2-SM.jpg
|Bildbeschreibung=geöffneter HM-WDS30-OT2-SM Differenz-Temperatur-Sensor
|HWProtocol=HomeMatic
|HWType=Temeperatursensor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=2
|HWVoltage=3V
|HWPowerConsumption= 40 mA max; Standby 3µW
|HWPoweredBy=2x1,5V LR03/Micro AAA
|HWSize=63 x 58 x 35 mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}

= Features =

'''Technische Daten:'''
Beide Messfühler werden '''zeitgleich''' ausgewertet und in '''einem''' Funktelegramm gesendet.
Beide Fühlertemperaturen können getrennt verarbeitet werden.
Per Parameter ist es möglich, alle Werte der Kanäle im Status des Devices zu vereinigen.

* Temperatur 1
* Temperatur 2
* Differenz T1-T2
* Differenz T2-T1

* Messbereich: -30 bis +100 °C, Genauigkeit je ±1,5 K, Fühler Plastik und nicht dauerhaft wasserdicht.
* 2 Fühler mit mit je 2,8 m Zuleitung
* Schutzart: IP 65; Gehäuse Aufputz
* Gewicht: 101 g (ohne Batterien)

----
=Anwendungsszenarien=

Gerade bei Steuerungsaufgaben mit schnell ändernden Temperaturen ist es von Vorteil, wenn beide Messwerte zeitgleich aufgenommen und gleich lokal verarbeitet werden.
Eingesetzt werden kann der Sensor aufgrund seines Messbereiches bis 100° C (anders als der ansonsten sehr ähnliche einkanalige WDS30-T-0)für Überwachung von Vor- und Rücklauftemperaturen bei Heiz- bzw. Warmwasserkreisläufen.
Nicht geeignet ist er leider für die Steuerung von Thermo-Solar-Anlagen, weil dort im Vorlauf Temeperaturen bis 150° C kurzzeitig entstehen können.

Ein spannender Aspekt ist der Aufbau eines Sonnensensors für Beschattungsaufgaben, den das ELV-Journal beschreibt.

= Hinweise zur Inbetriebnahme und Installation =

Nach Einsetzen der Batterien, während FHEM im Anlernmodus ist, werden das Device und seine 5 Channels problemlos erkannt. Wiederholung des Anlernens durch Drücken des Mikroschalters, bei Erfolg blinkt abschliessend eine LED grün.
Reset auf Auslieferungszustand: Taster 5 s drücken bis es rot blinkt, loslassen, erneut 5 s drücken, bis es schnell rot blinkt.

----

= Parameter =

'''list: register | range | peer | description'''
0: burstRx | literal | | device reacts on Burst options:on,off
0: cyclicInfoMsgDis | 0 to 255 | | cyclic message
0: intKeyVisib | literal | | visibility of internal channel options:visib,invisib
0: localResDis | literal | | local reset disable options:on,off
0: pairCentral | 0 to 16777215 | | pairing to central
0: paramSel | literal | | data transfered to peer options:T1,T1_T2,T2_T1,off,T2

= Probleme =

Eventuelle Temperatur-Differenzen zwischen den beiden Sensoren können nicht über FHEM beispielsweise durch einen "Offset" ausgeglichen werden, sondern müssen in den weiterverarbeitenden Routinen berücksichtigt werden.

<ggfls. ergänzen>

= Betrieb mit FHEM =

== event Monitor ==

Das Device erzeugt diese Events:
WDS30_T1 T: 49.9
WDS30_T1 temperature: 49.9
WDS30_T2 T: 32.0
WDS30_T2 temperature: 32.0
WDS30_T1_T2 T: 17.9
WDS30_T1_T2 temperature: 17.9
WDS30_T2_T1 T: -17.9
WDS30_T2_T1 temperature: -17.9

== fhem.log Auszug ==

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

:'''define WDS30_Device CUL_HM 20BEDC'''
:attr WDS30_Device .devInfo 010500
:attr WDS30_Device .stc 70
:attr WDS30_Device actCycle 000:10
:attr WDS30_Device actStatus alive
:attr WDS30_Device autoReadReg 0_off
:attr WDS30_Device expert 2_full
:attr WDS30_Device firmware 1.1
:attr WDS30_Device model HM-WDS30-OT2-SM
:attr WDS30_Device peerIDs
:attr WDS30_Device room InArbeit
:attr WDS30_Device serialNr KEQ0178415
:attr WDS30_Device subType THSensor
:attr WDS30_Device webCmd getConfig

:'''define WDS30_T1 CUL_HM 20BEDC01'''
:attr WDS30_T1 autoReadReg 1_restart
:attr WDS30_T1 expert 2_full
:attr WDS30_T1 group Heizung
:attr WDS30_T1 model HM-WDS30-OT2-SM
:attr WDS30_T1 peerIDs 00000000,
:attr WDS30_T1 room Heizung
:attr WDS30_T1 subType THSensor

:'''define WDS30_T2 CUL_HM 20BEDC02'''
:attr WDS30_T2 autoReadReg 1_restart
:attr WDS30_T2 expert 2_full
:attr WDS30_T2 group Heizung
:attr WDS30_T2 model HM-WDS30-OT2-SM
:attr WDS30_T2 peerIDs 00000000,
:attr WDS30_T2 room Heizung
:attr WDS30_T2 subType THSensor

:'''define WDS30_T1_T2 CUL_HM 20BEDC03'''
:attr WDS30_T1_T2 expert 1
:attr WDS30_T1_T2 model HM-WDS30-OT2-SM
:attr WDS30_T1_T2 peerIDs 00000000,
:attr WDS30_T1_T2 room Unsorted

:'''define WDS30_T2_T1 CUL_HM 20BEDC04:'''
:attr WDS30_T2_T1 expert 1
:attr WDS30_T2_T1 model HM-WDS30-OT2-SM
:attr WDS30_T2_T1 peerIDs 00000000,
:attr WDS30_T2_T1 room Unsorted

:'''define WDS30_Event CUL_HM 20BEDC05'''
:attr WDS30_Event expert 1
:attr WDS30_Event model HM-WDS30-OT2-SM
:attr WDS30_Event peerIDs 00000000,
:attr WDS30_Event room Unsorted

= Links =

Manual:

{{Todo|Artikel vervollständigen}}

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

Datei:HM-WDS30-OT2-SM.jpg

2016-02-10T09:04:52Z

Barit: Barit lud eine neue Version von Datei:HM-WDS30-OT2-SM.jpg hoch

Foto eines offenen HM-WDS30-OT2-SM

Datei:HM-WDS30-OT2-SM.jpg

2016-02-10T09:01:59Z

Barit: Foto eines offenen HM-WDS30-OT2-SM

Foto eines offenen HM-WDS30-OT2-SM

Kategorie Diskussion:Hardware Typen

2016-02-07T13:37:39Z

Barit: Type ThreeState aktualisiert --~~~~

== 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
|-
| Fenster-/Türkontakt || HomeMatic Type ThreeState || z.B. HM-SEC-SCo
|-
| 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-SEC-TIS Funk-Neigungssensor

2016-02-03T13:57:54Z

Barit: /* Links */ Link zur Anleitung aktualisiert

{{Infobox Hardware
|Bild=platzHalter.png 
|Bildbeschreibung=HomeMatic Funk-Neigungssensor
|HWProtocol=HomeMatic
|HWType=Sensor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=1
|HWVoltage=
|HWPowerConsumption=Betriebszustand: 40 mA, Ruhezustand: 1,5 µA
|HWPoweredBy=Batterie (1 x Lithium-Knopfzelle CR2032)
|HWSize=50x50x35mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

== Features ==
[[HomeMatic]] Funk-Neigungssensor zur Erkennung von Tor-, Tür- bzw. Fensteröffnungen oder -schließungen durch Neigung, z.B. beim Garagentor. Der Sensor kann nur die Zustände "offen" und "geschlossen" erkennen, keine Neigungswinkel bzw. teilweisen Öffnungen.

== Hinweis ==
Das meiste zum [[HM-SEC-SC Tür-Fensterkontakt|HM-SEC-SC]] Beschriebene zur Nutzung gilt auch für den HM-SEC-TIS.

Der Sensor wird (im Gegensatz zu den meisten Fensterkontakten mittlerweile) mit

<code>R-cyclicInfoMsg off</code>

ausgeliefert. Zum Aktivieren der regelmäßigen Batteriestatusmeldungen eines schon angelernten HM-SEC-TIS bitte

<code>set <HM-SEC-TIS> regSet cyclicInfoMsg on</code>

ausführen. Danach den Anlernknopf betätigen, damit das Kommando übertragen werden kann.

== Bekannte Probleme ==

== Links ==
* Anleitung [http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-Sec-TIS%20GE_UM_web.pdf PDF]
* Datenblatt [http://www.eq-3.de/Downloads/eq3/pdf_produkte/Funk-Neigungssensor_83146_Produktdatenblatt.pdf PDF]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Neigungssensor]]

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

2016-02-01T08:05:00Z

Barit: /* Links */ Links zu Produktinfo, Datenblatt und Ventilliste aktualisiert. Alle Links verweisen nun auf die Herstellerseite eQ-3 statt auf ELV.

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

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

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

Im Gegensatz zum Vorgänger 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 {{Link2Forum|Topic=14738|LinkText=Forum}}).

Der '''HM-CC-RT-DN''' scheint das erste HomeMatic-Device zu sein, bei dem ein Update der Firmware auch vom Anwender durchgeführt werden kann. Ein Firmware-Update erfordert einen [[HM-CFG-USB_USB_Konfigurations-Adapter|USB Konfigurations-Adapter]] und eine auf der eQ-3 Webseite herunterladbare Firmware Update Software. Weitere Details sind unter [[HM-CC-RT-DN_Funk-Heizkörperthermostat#Firmware Update|Firmware Update]] beschrieben.
{{Hinweis|Die Solltemperaturen eines HM-CC-RT-DN lassen sich ''nicht'' durch einen [[HM-CC-TC Funk-Wandthermostat]] steuern. Dieser kann höchstens die Ist-Temperatur an den HM-CC-RT-DN weitergeben, damit die Raumtemperatur nicht am HM-CC-RT-DN 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.4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Tastensperre ===

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

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

Rückgängig machen geht per:

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

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

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

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

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

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

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

eingeschaltet. Abschalten geht mit:

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

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

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

'''Burst – wie es funktioniert'''

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

'''HMLAN und burst'''

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

'''Burst devices'''

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

'''ConditionalBurst devices'''

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

'''Attribut burstAccess'''

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

'''Kommando burstXmit'''

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

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

Dann sendet der User ein set burstXmit.

Es passiert das gleiche wie bei burstAccess.

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

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

''' FHEM und burst devices'''

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fertig.

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

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

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

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

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

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

2016-01-29T18:25:14Z

Barit: Fotos des HM-CC-RT-DN hinzugefügt. Quelle: selbsterstelltes Foto

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

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

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

Im Gegensatz zum Vorgänger 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 {{Link2Forum|Topic=14738|LinkText=Forum}}).

Der '''HM-CC-RT-DN''' scheint das erste HomeMatic-Device zu sein, bei dem ein Update der Firmware auch vom Anwender durchgeführt werden kann. Ein Firmware-Update erfordert einen [[HM-CFG-USB_USB_Konfigurations-Adapter|USB Konfigurations-Adapter]] und eine auf der eQ-3 Webseite herunterladbare Firmware Update Software. Weitere Details sind unter [[HM-CC-RT-DN_Funk-Heizkörperthermostat#Firmware Update|Firmware Update]] beschrieben.
{{Hinweis|Die Solltemperaturen eines HM-CC-RT-DN lassen sich ''nicht'' durch einen [[HM-CC-TC Funk-Wandthermostat]] steuern. Dieser kann höchstens die Ist-Temperatur an den HM-CC-RT-DN weitergeben, damit die Raumtemperatur nicht am HM-CC-RT-DN 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.4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Tastensperre ===

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

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

Rückgängig machen geht per:

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

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

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

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

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

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

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

eingeschaltet. Abschalten geht mit:

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

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

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

'''Burst – wie es funktioniert'''

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

'''HMLAN und burst'''

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

'''Burst devices'''

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

'''ConditionalBurst devices'''

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

'''Attribut burstAccess'''

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

'''Kommando burstXmit'''

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

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

Dann sendet der User ein set burstXmit.

Es passiert das gleiche wie bei burstAccess.

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

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

''' FHEM und burst devices'''

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fertig.

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

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

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

== Links ==
* [http://www.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)]
* {{Link2Forum|Topic=14738|LinkText=Forenthema zum Thermostat}}

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

Datei:HM-CC-RT-DN.jpg

2016-01-29T18:21:38Z

Barit: HM-CC-RT-DN

HM-CC-RT-DN

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

2016-01-28T13:34:16Z

Barit: /* Links */ Link zum Datenblatt aktualisiert

{{Infobox Hardware
|Bild=HM-SEC-SCo.jpg
|Bildbeschreibung=HomeMatic Tür-Fensterkontakt, optisch
|HWProtocol=HomeMatic
|HWType=Sensor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=1
|HWVoltage=1,5 V DC
|HWPowerConsumption=max. 100 mA
|HWPoweredBy=Batterie (1x 1,5V LR03/Micro/AAA)
|HWSize=15x100x18mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

== Features ==
[[HomeMatic]] Funk-Tür-/Fensterkontakt zur optischen Erkennung von Tür- bzw. Fensteröffnungen oder -schließungen, z.B. zur Sicherheit oder um automatisch, bei vorhandenem [[HM-CC-RT-DN]], die Heizung herunter zu regeln, sobald ein Fenster oder eine Tür geöffnet wird.

== Hinweis ==
Das meiste zum [[HM-SEC-SC Tür-Fensterkontakt|HM-SEC-SC]] Beschriebene zur Nutzung gilt auch für den HM-SEC-SCo.

Wird mit aktiviertem [[AES Encryption|AES]] ausgeliefert und kann nur mit Gateways, die AES unterstützen, gepaired werden ([[HM-CFG-USB USB Konfigurations-Adapter|HM-LAN-CFG]], [[HM-CFG-LAN LAN Konfigurations-Adapter|HM-USB-CFG]] und [[CUL]] (seit Juli 2015)).

== Betrieb mit FHEM ==
=== Event-Monitor ===
Wird z. B. das Fenster geöffnet, wird Folgendes vom Gerät übermittelt:
<pre>
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG trigger_cnt: 11
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG trigDst_2573FB: noConfig
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG battery: ok
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG open
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG contact: open (to MyHMLAN)
</pre>

Beim Schließen wird Folgendes übermittelt:
<pre>
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG trigger_cnt: 12
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG trigDst_2573FB: noConfig
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG battery: ok
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG closed
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG contact: closed (to MyHMLAN)
</pre>

=== fhem.cfg ===
Bei eingeschaltetem Autocreate werden die erforderlichen Definitionen beim Pairen selbstständig erstellt.

<pre>
define HM_Fensterstatus_BadEG CUL_HM 35E390
attr HM_Fensterstatus_BadEG IODev MyHMLAN
attr HM_Fensterstatus_BadEG actCycle 000:50
attr HM_Fensterstatus_BadEG actStatus dead
attr HM_Fensterstatus_BadEG autoReadReg 4_reqStatus
attr HM_Fensterstatus_BadEG expert 2_full
attr HM_Fensterstatus_BadEG firmware 1.0
attr HM_Fensterstatus_BadEG model HM-SEC-SCo
attr HM_Fensterstatus_BadEG peerIDs 00000000,
attr HM_Fensterstatus_BadEG room CUL_HM
attr HM_Fensterstatus_BadEG serialNr LEQxxxxxxx
attr HM_Fensterstatus_BadEG subType threeStateSensor
</pre>

=== Aktionen durchführen, wenn Fenster zu lange geöffnet ist ===
Mit der nachfolgenden DOIF-Definition wird ein Log-Eintrag erzeugt, eine Meldung auf der [[Enigma2 Receiver (Dreambox, VUplus etc.) steuern|Dreambox]] angezeigt, falls diese angeschaltet ist, und eine Nachricht per Prowl (funktioniert vermutlich nur unter Linux) verschickt.

Der Code ist hier so angegeben, wie er in der Weboberfläche nach einem Klick auf das [[Konfiguration|DEF-Feld]] übernommen werden kann. Das DOIF ist vorab zu definieren, zum Beispiel mit:
:<code>def DOIF_FensterOffenMsg DOIF ([HM_Fensterstatus_BadEG])</code>

<pre>
([HM_Fensterstatus_BadEG] eq "open") ({
Log 1, "Fenster seit mehr als 2 Stunden (7200 Sekunden) offen";;
system( "/path/to/prowl.pl -apikeyfile=/path/to/prowl-apikey -event=Info -notification='Fenster ist noch offen' &" );;
fhem( "set E2_Dreambox showText Fenster ist noch offen" ) if ReadingsVal("E2_Dreambox","state","") eq "on";;
})
DOELSE
</pre>

Damit der Code-Block erst nach 7200 Sekunden getriggert wird, ist noch Folgendes auszuführen:

:<code>attr DOIF_FensterOffenMsg wait 7200:0</code>

=== Anzeige des Zeitpunkts der letzten Öffnung im STATE ===
Das Reading ''contact'' beinhaltet die Zustände ''open'' und ''closed''. Und der Zeitstempel der Änderung wird regelmäßig aktualisiert. Aus diesem Grund fällt die Nutzung des Attributs ''showtime'' hier weg. Wenigstens, wenn man nicht den Zeitpunkt des letzten Auslesens wissen will, sondern den, der letzten Öffnung.

Folgende Schreibweise ermöglicht es, dass im STATE-Internal der Zeitpunkt des letzten ''open'' verleibt (zum Übernehmen als Einzeler kopieren):
:<code><nowiki>attr Sensor stateFormat {if (ReadingsVal("Sensor","contact","") =~ "open.*") {"open " . ReadingsTimestamp("Sensor","contact","")} else {InternalVal("Sensor","STATE","")}}</nowiki></code>

Ein Thread zu diesem Thema findet sich im Forum unter dem Titel {{Link2Forum|Topic=41347|LinkText=HM-SEC-SCo: Letzte Türöffnung im State anzeigen}}.

== Bekannte Probleme ==
Teilweise (siehe Diskussion im {{Link2Forum|Topic=33264|LinkText=Forum}}) werden die Fensterkontakte regelmäßig wiederkehrend als "dead" angezeigt. Grund ist, dass beim Anlernen ein actCycle von 50 Minuten eingetragen wird, während die Kontakte auch gerne mal länger brauchen, um sich bei der Zentrale zu melden.
<pre style="width:500px;">
2015-01-31_17:57:39 Fstr_AusgTerrasse alive: yes
2015-01-31_17:57:39 Fstr_AusgTerrasse battery: ok
2015-01-31_17:57:39 Fstr_AusgTerrasse sabotageError: off
2015-01-31_17:57:39 Fstr_AusgTerrasse closed
2015-01-31_17:57:39 Fstr_AusgTerrasse contact: closed (to HMLAN1)
2015-01-31_18:54:09 Fstr_AusgTerrasse Activity: dead
2015-01-31_18:58:03 Fstr_AusgTerrasse alive: yes
2015-01-31_18:58:03 Fstr_AusgTerrasse battery: ok
2015-01-31_18:58:03 Fstr_AusgTerrasse sabotageError: off
2015-01-31_18:58:03 Fstr_AusgTerrasse closed
2015-01-31_18:58:03 Fstr_AusgTerrasse contact: closed (to HMUSB)
2015-01-31_19:04:09 Fstr_AusgTerrasse Activity: alive
</pre>

Um Abhilfe zu schaffen, den actCycle auf 01:05 setzen:
:<code>attr <HM-SEC-SCo> actCycle 001:05</code>

Save config nicht vergessen.

== Links ==
* Anleitung [http://www.eq-3.de/Downloads/eq3/pdf_produkte/130873_HM-Sec-SCo_UM_GE_eQ-3_20141013_web.pdf PDF]
* Datenblatt [http://www.eq-3.de/Downloads/eq3/pdf_produkte/Funk-Tuer-Fensterkontakt-optisch_130297_Produktdatenblatt_V1.2.pdf PDF]

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