HM-CC-RT-DN

[michi1983]

Hallo zusammen,

bin gerade darauf gestoßen, dass es eine eine FW 1.4.001 vom 20.10.2014 gibt:

http://www.eq-3.de/Downloads/Software/Firmware/changelog_hm_cc_rt_dn_update_V1_4_001_141020.txt

Hat die schon jemand ausprobiert? Funktioniert die besser oder schlechter als die 1.3?

Danke und Grüße,

Michi

[le66ck]

Hallo michi1983

Wahrscheinlich, sicher besser....!
Siehe hier http://forum.fhem.de/index.php/topic,25527.0.html

CK

[holzwurm83]

Hallo zusammen,

habe schon einiges durchstöbert, aber nicht so richtig auf den Nenner gekommen.

Ich habe habe mir Drahtgebundene Fensterkontakte über ein Wiredmodul eingebaut.

Würde gerne diese nun mit den RTs peeren und habe dazu auch schon was zu Virtuelle Entities gelesen. Aber ich komme nicht wirklich weiter. 

Der Fensterstaus wird wird mit dieser *.cfg realisiert:

Code Auswählen Erweitern

define WZ_Fenster_SUED_R DOIF ([HMW_Sen_SC_12_DR_JEQ0545703_01:sensor] == 51200 and [HMW_Sen_SC_12_DR_JEQ0545703_02:sensor] == 0) DOELSEIF ([HMW_Sen_SC_12_DR_JEQ0545703_01:sensor] == 0 and [HMW_Sen_SC_12_DR_JEQ0545703_02:sensor] == 51200) DOELSEIF ([HMW_Sen_SC_12_DR_JEQ0545703_01:sensor] == 51200 and [HMW_Sen_SC_12_DR_JEQ0545703_02:sensor] == 51200)
attr WZ_Fenster_SUED_R alias SÜD R
attr WZ_Fenster_SUED_R cmdState zu|gekippt|offen
attr WZ_Fenster_SUED_R devStateIcon zu:fts_window_1w offen:fts_window_1w_open@red gekippt:fts_window_1w_tilt@red
attr WZ_Fenster_SUED_R group Fenster
attr WZ_Fenster_SUED_R icon fts_door_right
attr WZ_Fenster_SUED_R room Wohnzimmer

[le66ck]

Hallo holzwurm83

Vielleicht hilft Dir das etwas weiter

Code Auswählen Erweitern

define Fensteroffen_Forian DOIF ([Fenster_Florian] eq "open") (set ThermostatFlorian_Clima controlManu off) DOELSEIF ([Fenster_Florian] eq "closed")(set ThermostatFlorian_Clima controlManu 18)

Fenster_Florian ist ein Funk-Tür-/Fensterkontakt, optisch und der Rest sollte/könnte selbsterklärend sein.
Beides ist nur an Fhem angelernt. Vielleicht hift es Dir weiter.

CK

[holzwurm83]

Hallo le66ck,

Danke für dein Feedback. Ich würde das gerne so umsetzen, das man den Kanal für die Fensterkontakte am RT ansteuert. Das sollte doch auch gehen?

[michi1983]

Hallo michi1983

Wahrscheinlich, sicher besser....!
Siehe hier http://forum.fhem.de/index.php/topic,25527.0.html

CK

Danke!

[holzwurm83]

Hallo le66ck,

Danke für dein Feedback. Ich würde das gerne so umsetzen, das man den Kanal für die Fensterkontakte am RT ansteuert. Das sollte doch auch gehen?

[le66ck]

Hallo holzwurm83

Ich würde das gerne so umsetzen, das man den Kanal für die Fensterkontakte am RT ansteuert. Das sollte doch auch gehen?

Wenn Du direkt peeren meinst, also ohne Fhem (hört nur mit), ja!?
Fhem-Befehl dazu habe ich gerade nicht vorrätig...

CK

[FHEMbeta]

Ich habe einen HM-CC-RT-DN. Dazu ein virtuelles HM-Thermometer, welches seine Temperatur direkt von einem realen Thermometer erhält. Der Kanal Clima des Heizkörperthermostats ist mit diesem virtuellen HomeMatic Device gepeert. Dazu habe ich folgenden Befehl in der FHEM Kommandozeile ausgeführt:

Code Auswählen Erweitern

set Temp_Esszimmer_Weather peerChan 0 HZ_Esszimmer_Weather single set
Auch habe ich es mit folgendem Befehl getestet, bin mir aber über dessen Bedeutung im Vergleich zum vorherigen nicht sicher:

Code Auswählen Erweitern

set Temp_Esszimmer_Weather peerChan 0 HZ_Esszimmer_Weather single

In unregelmäßigen Abständen zeigt der Kanal Clima jedoch Temperaturen an, die von der Temperatur des virtuellen Homematic Devices abweichen. Die abweichenden Temperaturen sind allgemein höher als die Temperatur des virtuellen Devices. Daher gehe ich davon aus, dass der Heizkörperthermostat auf den internen Temperaturfühler umschaltet.

Wie kann ich dieses Verhalten unterbinden? Der HM-CC-RT-DN soll immer die Temperatur des virtuellen Devices als aktuelle Temperatur benutzen.

[tpm88]

Hallo Alexander,

Wie kann ich dieses Verhalten unterbinden? Der HM-CC-RT-DN soll immer die Temperatur des virtuellen Devices als aktuelle Temperatur benutzen.

Ich habe ähnliche Erfahrungen mit einem 1wire TemperaturSensor, der einen virtuellen HomeMatic Temperatursensor versorgt, gemacht - siehe hier: http://forum.fhem.de/index.php/topic,19686.msg137522.html#msg137522

Die gleichen Probleme gibt es auch mit Dirks HM Universalsensor, siehe hier: http://forum.fhem.de/index.php/topic,27980.msg208769.html#msg208769

In letzterem Thread hat Martin erklärt, wie das Senden der extern gemessenen Temperatur an den RT-DN funktioniert. Da ist genaues Timing wichtig.

Meine Vermutung ist, daß der Algorithmus zur Berechnung des genauen Sendezeitpunkts manchmal danebenliegt. Die gleiche Formel verwendet Dirk nämlich in seiner Firmware für den Eigenbausensor. Empfängt der RT-DN dann über einige Zeit keinen externen Temperaturwert, schaltet er kurz - bis zum erneuten Empfang des richtigen Temperaturwertes - wieder auf seinen internen Sensor um. Das erzeugt dann die hässlichen Peaks oder Drops, die bei mir außerdem zu wilden Regelsprüngen des RT-DN führen.

Eine Lösung gibt es leider (noch) nicht.

Gruß
Tobias

[FHEMbeta]

Hallo Tobias,

vielen Dank für die ausführliche Antwort. Also handelt es sich nicht um eine Fehlfunktion meiner beiden Heizkörperthermostate. Hoffentlich kann das Timing-Problem behoben werden. Ich würde gerne noch die übrigen Heizungen mit dem HM-CC-RT-DN ausstatten.

Momentan habe ich durch die Temperaturänderungen Schwankungen von ca. 1-1.5°C im Raum. Ich werde auch mit einer kleineren Öffnung des Ventils testen, ob es dann besser wird.

[martinp876]

Das timing ist mit VDs getestet worden - sollte m.E. immer identisch sein. Ich habe es nicht in Betrieb, habe also keine eigenen Messwerte.
schalte bei deinem virtuellen Aktor einmal loglevel auf 5 und die messages der Aktoren ein. dann logge über einige Zeit.

[tpm88]

Hallo Martin, Alexander,

Meine Vermutung ist, daß der Algorithmus zur Berechnung des genauen Sendezeitpunkts manchmal danebenliegt. Die gleiche Formel verwendet Dirk nämlich in seiner Firmware für den Eigenbausensor. Empfängt der RT-DN dann über einige Zeit keinen externen Temperaturwert, schaltet er kurz - bis zum erneuten Empfang des richtigen Temperaturwertes - wieder auf seinen internen Sensor um. Das erzeugt dann die hässlichen Peaks oder Drops, die bei mir außerdem zu wilden Regelsprüngen des RT-DN führen.

Eine Lösung gibt es leider (noch) nicht.

Ich muß meine Vermutung revidieren. Ich habe gestern meinen virtuellen Temperatursensor reaktiviert und jetzt 24h mitgeloggt. Resultat - KEIN EINZIGER Aussetzer!!

Seit meinen letzten Tests damit im letzten Winter & Frühjar hat sich natürlich einiges am Code getan. Zusätzlich habe ich mein FHEM auf einen schnelleren CubieTruck umgezogen. Offenbar hat damals etwas anderes ab und an das Timing verhunzt.

Ich werde jetzt noch weitere 24h verbose5 und raw packets mitloggen. Wenn das aber so stabil bleibt, bin ich schlicht begeistert.

Tobias

[phel]

Hallo zusammen,

rein Interessehalber - kommt man eigentlich noch an die realen Messwerte, wenn der Clima-Kanal gepeert ist?

Grüße
Phel

[tpm88]

rein Interessehalber - kommt man eigentlich noch an die realen Messwerte, wenn der Clima-Kanal gepeert ist?

Definiere "reale Messwerte". Wenn Du die vom Thermostat intern gemessenen meinst, dann Nein.

Gruß
Tobias