HM-CC-RT-DN ignoriert virtTemp und nimmt eigene "measured-temp"

Begonnen von rretsiem, 24 Februar 2015, 13:40:04

Vorheriges Thema - Nächstes Thema

rretsiem

Hallo,

seit 2 Tagen experimentiere ich mit dem Homematic HM-CC-RT-DN in einem Raum. Diesen habe ich mit dem HMLANUSB Adapter gepairt und ich kann das Thermostat auch via FHEM steuern.
Zusätzlich dazu habe ich ein TFA 303155.WD im Raum um die Temperatur von dort aus zu messen.

Dazu habe ich mir einen virtuellen HM Sensor angelegt den ich mit dem _Weather Channel meines RT verbunden habe. Soweit klappt das auch ganz gut.

Ein "set hm peerXref" zeigt:

peerXref done:
x-ref list
    Buero_virtTemp_Sensor1 => CUL_HM_HM_CC_RT_DN_2E2CCD_Weather
    CUL_HM_HM_CC_RT_DN_2E2CCD_Weather => Buero_virtTemp_Sensor1


Im Anschluß habe ich mir einen "at" definiert, der alle 2 Minuten die Temperatur des TFA in viertem schreibt.

define at_Buero_virtTemp at +*00:02 { my $T=(ReadingsVal("02Thermo","temperature",""));; fhem "set Buero_virtTemp_Sensor1 virtTemp $T" }



2015-02-24 13:35:10 LaCrosse 02Thermo temperature: 21.0
2015-02-24 13:35:10 LaCrosse 02Thermo humidity: 53
2015-02-24 13:35:11 CUL_HM Buero_virtTemp_Sensor1 temperature: 21.0
2015-02-24 13:35:11 CUL_HM Buero_virtTemp_Sensor1 set_virtTemp 21.0
2015-02-24 13:36:16 CUL_HM CUL_HM_HM_CC_RT_DN_2E2CCD_Clima measured-temp: 21.0
2015-02-24 13:36:16 CUL_HM CUL_HM_HM_CC_RT_DN_2E2CCD_Clima ValvePosition: 30
2015-02-24 13:36:16 CUL_HM CUL_HM_HM_CC_RT_DN_2E2CCD_Clima motorErr: ok
2015-02-24 13:36:16 CUL_HM CUL_HM_HM_CC_RT_DN_2E2CCD_Clima desired-temp: 21.0
2015-02-24 13:36:16 CUL_HM CUL_HM_HM_CC_RT_DN_2E2CCD_Clima controlMode: auto
2015-02-24 13:36:16 CUL_HM CUL_HM_HM_CC_RT_DN_2E2CCD_Clima boostTime: -
2015-02-24 13:36:16 CUL_HM CUL_HM_HM_CC_RT_DN_2E2CCD_Clima T: 21.0 desired: 21.0 valve: 30
2015-02-24 13:36:16 CUL_HM CUL_HM_HM_CC_RT_DN_2E2CCD_Clima partyStart: -
2015-02-24 13:36:16 CUL_HM CUL_HM_HM_CC_RT_DN_2E2CCD_Clima partyEnd: -
2015-02-24 13:36:16 CUL_HM CUL_HM_HM_CC_RT_DN_2E2CCD_Clima partyTemp: -
2015-02-24 13:36:16 CUL_HM CUL_HM_HM_CC_RT_DN_2E2CCD_Weather measured-temp: 21.0
2015-02-24 13:36:16 CUL_HM CUL_HM_HM_CC_RT_DN_2E2CCD_Weather 21.0
2015-02-24 13:36:16 CUL_HM HM.Thermostat01 measured-temp: 21.0
2015-02-24 13:36:16 CUL_HM HM.Thermostat01 batteryLevel: 3
2015-02-24 13:36:16 CUL_HM HM.Thermostat01 actuator: 30
2015-02-24 13:36:16 CUL_HM HM.Thermostat01 desired-temp: 21.0


Jetzt kommt es aber in sporadischen Abständen (heute bestimmt 3-4x) vor, das die "measured-temp" sich von der des TFA unterscheidet und zwar um ca. +1.5-2°C. Was mich darauf schließen lässt das das setzen des measured-temp mit dem "at" und anschließender Weitergabe an das RT nicht sauber funktioniert.
Nur leider finde ich nicht heraus wieso und sehe auch keine Fehler in den Logs. Nach einer Weile stimmt es dann wieder (teilweise 50-80 Minuten) und die measured-temp ist wieder exakt zu der des TFA.

Das Problem an der Geschichte ist, das sich durch diese sporadischen "Aussetzer" die Ventilstellung des RT natürlich jedes Mal ändert, weil es plötzlich wärmer ist als die desired-temp.


frank

das problem ist das timing der kommunikation zwischen virtSensor und rt. gibt schon reichlich threads dazu.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

rretsiem

Ich habe das mit dem Timing schon an mehreren Stellen gelesen, aber egal nach was ich hier im Forum suche, ich finde keinen Thread der eine Idee oder Lösung anbietet. Daher wäre ich für einen kurzen Tipp nach was ich denn suchen soll oder einen Hinweis dazu sehr dankbar!

frank

"die" lösung gibt es wohl auch nicht. dein system muss zuverlässig und exakt senden/empfangen. das ist zb abhängig von io, server-hardware, anzahl und art der dienste, die auf dem server ausgeführt werden, ....

ein gepeertes homematic-device (tc-it) hat ja sonst nichts zu tun. daher braucht es sich nur darauf zu konzentrieren.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

martinp876

das timing zuss präzise einem pseudo-random Ablauf folgen. wir haben es für einen virtuellen VD oder cc-tc erstellt. Ich vermute, dass es auch bei einem TC so abläuft.
du solltest also den virtuellen temp-sensor peeren (sicher schon passiert)
die temp wird über
set vd_chan virtTemp <value>
gesetzt.

gerne einmal loggen. Für den virtuellen Kanal verbose auf 5 setzen, dann kommt etwas mehr.

rretsiem

#5
Der Sensor ist "sauber" gepeert mit dem _Weather Kanal 1 des RT.

Ich habe einen Notify definiert der auf Events des eigentliche LaCrosse Sensors lauscht und dann einen set virtTemp absetzt:

02Thermo.temperature:.* IF ([02Thermo:temperature:d] != [HM.Thermostat01.Buero_Weather:measured-temp:d]) (set Buero_virtTemp_Sensor1 virtTemp %EVTPART1)

Das "set virtTemp" wird also nur dann gesetzt wenn sich die Temperatur auch geändert hat. Zusätzlich dazu habe ich die sehr geschwätzigen LaCross Thermometer mit einem

event-min-interval: state:600,temperature:120,humidity:120,battery:1800

etwas beruhigt.
Somit sollte doch max. alle 2 Minuten und auch nur wenn eine Änderung der gemessenen Temperatur stattgefunden hat ein "set virtTemp" erfolgen.

So sieht das im Log jetzt aus wenn ich "verbose 5" auf dem virtuellen Device setze:

2015.03.02 22:36:19 3: CUL_HM set Buero_virtTemp_Sensor1 virtTemp 19.4
2015.03.02 22:36:51 5: CUL_HM Buero_virtTemp_Sensor1 m:227 ->228 t:1425332211.76957->1425332391.76957  M:1425332211.77745 :180
2015.03.02 22:38:39 3: CUL_HM set Buero_virtTemp_Sensor1 virtTemp 19.5
2015.03.02 22:39:18 3: CUL_HM set Buero_virtTemp_Sensor1 virtTemp 19.5
2015.03.02 22:39:51 5: CUL_HM Buero_virtTemp_Sensor1 m:228 ->229 t:1425332391.77745->1425332557.27745  M:1425332391.78531 :165.5
2015.03.02 22:40:44 3: CUL_HM set Buero_virtTemp_Sensor1 virtTemp 19.5
2015.03.02 22:42:37 5: CUL_HM Buero_virtTemp_Sensor1 m:229 ->230 t:1425332557.28531->1425332708.28531  M:1425332557.29122 :151
2015.03.02 22:43:19 3: CUL_HM set Buero_virtTemp_Sensor1 virtTemp 19.4
2015.03.02 22:44:13 3: CUL_HM set Buero_virtTemp_Sensor1 virtTemp 19.4
2015.03.02 22:45:08 5: CUL_HM Buero_virtTemp_Sensor1 m:230 ->231 t:1425332708.29122->1425332845.04122  M:1425332708.29683 :136.75
2015.03.02 22:45:24 3: CUL_HM set Buero_virtTemp_Sensor1 virtTemp 19.4
2015.03.02 22:47:25 5: CUL_HM Buero_virtTemp_Sensor1 m:231 ->232 t:1425332845.04683->1425332967.29683  M:1425332845.05389 :122.25
2015.03.02 22:49:27 5: CUL_HM Buero_virtTemp_Sensor1 m:232 ->233 t:1425332967.30389->1425333139.05389  M:1425332967.31098 :171.75
2015.03.02 22:52:19 5: CUL_HM Buero_virtTemp_Sensor1 m:233 ->234 t:1425333139.06098->1425333296.31098  M:1425333139.06704 :157.25
2015.03.02 22:54:56 5: CUL_HM Buero_virtTemp_Sensor1 m:234 ->235 t:1425333296.31704->1425333439.31704  M:1425333296.32419 :143
2015.03.02 22:57:19 5: CUL_HM Buero_virtTemp_Sensor1 m:235 ->236 t:1425333439.32419->1425333567.82419  M:1425333439.33302 :128.5


Das ist meine jetzige Lösung, zum Zeitpunkt des Starts dieses Threads hier habe ich "einfacher" mit einem "at" alle 2 Minuten einfach die Temperatur des LaCross auf das virtuelle Device gesetzt. Mit all den Problemen, oder auch nicht, die zur Eröffnung dessen geführt haben.

martinp876

Das prinzip von hm sowie die implementierung von fhem hast du noch nicht verstanden.
Der empfaenger wacht nicht alle 2min auf sondern pseudorandom alle 2min. Der sender muss die zwischen 2 und 3 min schwankende wachzeit genau treffen. Dazu muss er diese errechnen. Ein at hat keinerlei sinn
Fhem errechnet diese zeit und schickt regelmaessig den wert. Egal, ob du ein set sendest oder nicht. Es wird immer der letztgesetzte wert gesendet.
Sollte der empfaenger nicht mehr empfangen wird er nervoes und schaltet in den scan mode um sich erneut zu synchen.

Kannst du auch einmal die messages loggen, dann kann man sehen, aelchen wert der rt uebernommen hat

rretsiem

Zitat von: martinp876 am 05 März 2015, 20:23:11
Der empfaenger wacht nicht alle 2min auf sondern pseudorandom alle 2min. Der sender muss die zwischen 2 und 3 min schwankende wachzeit genau treffen. Dazu muss er diese errechnen. Ein at hat keinerlei sinn
Fhem errechnet diese zeit und schickt regelmaessig den wert.
Klar war mir das schon, aber das mit dem Timing nicht, es ist halt so, dass man hier im Forum viel liest und dann wird bei der Implementierung häufig auf das Wiki verwiesen, was auch vollkommen in Ordnung ist. Dort steht aber leider genau das mit dem "at" alle 2 Minuten. http://www.fhemwiki.de/wiki/HM-CC-RT-DN_Funk-Heizkörperthermostat#Temperatursensoren

Zitat
Kannst du auch einmal die messages loggen, dann kann man sehen, aelchen wert der rt uebernommen hat
Du meinst du Antworten vom HM Modul des entsprechenden RTs?

So etwas, oder was anderes:

2015.03.05 21:05:45 4: eventTypes: CUL_HM HM.Thermostat01 measured-temp: 19.2 -> measured-temp: .*
2015.03.05 21:05:45 4: eventTypes: CUL_HM HM.Thermostat01 batteryLevel: 2.8 -> batteryLevel: .*
2015.03.05 21:05:45 4: eventTypes: CUL_HM HM.Thermostat01 actuator: 0 -> actuator: .*
2015.03.05 21:05:45 4: eventTypes: CUL_HM HM.Thermostat01 desired-temp: 18.0 -> desired-temp: .*
2015.03.05 21:05:45 4: eventTypes: CUL_HM HM.Thermostat01.Buero_Clima measured-temp: 19.2 -> measured-temp: .*
2015.03.05 21:05:45 4: eventTypes: CUL_HM HM.Thermostat01.Buero_Clima ValvePosition: 0 -> ValvePosition: .*
2015.03.05 21:05:45 4: eventTypes: CUL_HM HM.Thermostat01.Buero_Clima motorErr: ok -> motorErr: ok
2015.03.05 21:05:45 4: eventTypes: CUL_HM HM.Thermostat01.Buero_Clima desired-temp: 18.0 -> desired-temp: .*
2015.03.05 21:05:45 4: eventTypes: CUL_HM HM.Thermostat01.Buero_Clima controlMode: auto -> controlMode: auto
2015.03.05 21:05:45 4: eventTypes: CUL_HM HM.Thermostat01.Buero_Clima boostTime: - -> boostTime: -
2015.03.05 21:05:45 4: eventTypes: CUL_HM HM.Thermostat01.Buero_Clima T: 19.2 desired: 18.0 valve: 0 -> T: .* desired: .* valve: .*
2015.03.05 21:05:45 4: eventTypes: CUL_HM HM.Thermostat01.Buero_Clima partyStart: - -> partyStart: -
2015.03.05 21:05:45 4: eventTypes: CUL_HM HM.Thermostat01.Buero_Clima partyEnd: - -> partyEnd: -
2015.03.05 21:05:45 4: eventTypes: CUL_HM HM.Thermostat01.Buero_Clima partyTemp: - -> partyTemp: -
2015.03.05 21:05:45 4: eventTypes: CUL_HM HM.Thermostat01.Buero_Clima state: T: 19.2 desired: 18.0 valve: 0 -> state: T: .* desired: .* valve: .*
2015.03.05 21:05:45 4: eventTypes: CUL_HM HM.Thermostat01.Buero_Weather measured-temp: 19.2 -> measured-temp: .*
2015.03.05 21:05:45 4: eventTypes: CUL_HM HM.Thermostat01.Buero_Weather 19.2 -> .*
2015.03.05 21:05:45 4: eventTypes: CUL_HM HM.Thermostat01.Buero_Weather state: 19.2 -> state: .*
2015.03.05 21:05:45 4: n_HM.Thermostat01.Buero_Weather.virtTemp exec IF ([Buero_virtTemp_Sensor1:temperature:d] != [HM.Thermostat01.Buero_Weather:measured-temp:d]) ({fhem('set Buero_virtTemp_Sensor1 virtTemp '.ReadingsVal('Buero_virtTemp_Sensor1', 'temperature', '18'))})

martinp876