Hallo Freunde des FHEMS und der Homematic,
ich habe den RHS Fenster- und Türkontakt in meinem Wohnzimmer an die Terassentür montiert. Angelernt in FHEM und auf Funktionsfähigkeit getestet. Zeigt mir open, closed und tilted. Alles wunderbar.
Nun komme ich zu meiner Verständnisfrage: Ich habe das Heizungsthermostat HM-CC-RT-DN und das Wandthermostat (s. Betreff). Muss ich nun den WindowRec channel des Wandthermostat mit dem RHS peeren oder das RT mit dem RHS?
Mein Szenario ist eigentlich wie folgt: Wenn die Türe auf oder gekippt ist, soll die Temperatur auf den Wert, der unter readings steht (winOpnTemp-int), gesetzt werden.
Ich habe auch bereits das HowTo über FHEM mit Fritzbox gelesen. Dort stehen ein Paar nützliche Tipps drin, aber leider ist da kein Wandthermostat im Spiel. Vielleicht ist noch wichtig zu wissen, dass ich das ganze mit dem HM-LAN Gateway mache. Wobei, dass pairen ja geklappt hat, sehe die Stati ja in FHEM.
Danke schonmal für die Hilfe.
Grüße
herrmie
Hi Herrmie,
Sicher hat betateilchen schon Erfahrung damit. Zu erwarten ist, dass der TC hier mit dem SC gepeert wird und die aenderung an den RT sendet. Kannst du aber einfach ausprobieren
Die Frage ist, wie lange die Verzögerung ist...
Gruss Martin
Hi,
habe den TC-IT mit einem HM-SEC-SC und 2* RT gepeert.
Beim Öffnen/Schließen des Fensters überträgt der TC-IT in der Regel "zeitnah" (innerhalb von ein paar Sekunden) die neue Soll-Temperatur an die RTs. Meistens. Habe schon vereinzelt gesehen, daß es bei dem ein oder anderen RT nicht ankommt. SC/TC/RT haben dabei alle Sichtkontakt.
Rainer
Hallo,
ich habe nun mit einem
set hm.wohnzimmerTerassentuer peerChan 0 hm.wohnzimmerWT_WindowRec single den RHS mit den TC gepeert.
Unter meinem RHS sehe ich auch die folgende peerlist.
peerList hm.wohnzimmerWT_WindowRec
Jedoch müsste doch unter meinem TC nun auch die peerlist mit dem RHS stehen, oder?
Grüße
herrmie
Hallo,
ich habe jetzt nochmal getestet und unter dem TC_WindowRec wird der status, dass die Terassentür offen ist übergeben. Das funktioniert also. Nur die winOpn temp wird nicht übertragen.
Vielleicht muss ich hier noch irgendeinen parameter setzen?
Danke schonmal und Grüße,
jetzt mal langsam.
SC/RHS sendet an den TC Tür offen.
jetzt soll der TC an den RT die neue temp übertragen und das geht nicht? Oder wer überträgt an wen nicht?
Was zeiht der TC als desired-temp an?
Hallo,
ZitatSC/RHS sendet an den TC Tür offen.
ja
Zitatjetzt soll der TC an den RT die neue temp übertragen und das geht nicht?
ja
ZitatWas zeiht der TC als desired-temp an?
21°C, dass ist eben nicht die winOpnTemp
Grüße
was steht in winrec condition type? Sendet deine Tür einen level? Welchen? Sind rohmessages da?
das Problem scheint also nicht die Übertragung sondern die Behandlung in TC zu sein - der reagiert doch garnicht
wo finde ich den winrec condition type? Beim TC_WindowRec?
Mir ist aufgefallen, wenn ich die Terassentür auf mache, dann leuchtet die LED des RHS orange, dann rot. Aber in FHEM zeigt es mir an, dass die Tür offen ist.
Grüße
Schau dir die Register den TC window receiver an.
wenn der RHS rot leuchtet hat mindestens ein Empfänger nicht bestätigt. FHEM hat empfangen/gelauscht - war aber evtl nicht der Adressat.
Also erst einmal das peering prüfen
a) sind die register von RHS und TC aktuell?
b) optional HMInfo checkConfig ausführen, sehen ob etwas beanstandet wird
c) prüfen, dass Peers auf beiden seiten vorhanden sind.
d) prüfen, welche Adressaten im RHS angezeigt werden.
Gruss Martin
Hallo,
ich habe nun nochmal das peering gelöscht und jetzt ist beim öffnen der Terassentür erst kurz orange und dann grün. So wie es sein soll.
Ich würde nun den RHS mit meinem TC peeren:
set hm.wohnzimmerTerassentuer peerChan 0 hm.wohnzimmerWT_WindowRec single
Danach anlerntaste des TC und des RHS drücken
Muss ich danach noch mehr Befehle ausführen um den RHS mit dem TC zu peeren?
Grüße
herrmie
Die Türsensoren werden NUR mit dem TC gepeert sonst passieren manchmal komische Sachen ;)
das peering sollte abgeschlossen sein. Funktioniert es jetzt? Welche Peers sind jetzt eingetragen?
Sicher hat betateilchen recht, dass es reicht, wenn der RHS am TC gepeert ist - ist das jetzt so?
Hallo,
sorry, dass ich mich jetzt erst melde, aber bin erst heute dazugekommen.
Folgende Dinge habe ich ausgeführt:
set hm.wohnzimmerTerassentuer peerChan 0 hm.wohnzimmerWT_WindowRec single
Anlerntaste RHS gedrückt (Orange, dann grün)
set hm.wohnzimmerWT getConfig
Unter Readings des hm.wohnzimmerWT_WindowRec steht folgendes:
R-hm.wohnzimmerTerassentuer_chn-01-shCtValLo 50 2014-02-23 14:38:22
RegL_01: 08:00 00:00 2014-02-25 17:52:03
trigLast hm.wohnzimmerTerassentuer :closed 2014-02-25 17:40:55
trig_hm.wohnzimmerTerassentuer closed 2014-02-25 17:40:55
ein
get HM configCheck
bringt folgendes:
Register changes pending
hm.wohnzimmerTerassentuer
Das heißt wahrscheinlich soviel, dass mein RHS auf irgendetwas wartet.
ein weiterer Fehler unter configCheck ist:
incomplete register list
hm.wohnzimmerWT_Climate: RegL_07:,RegL_08:,RegL_09:
Das sollte aber für den RHS jetzt erstmal egal sein, nehme ich an.
Dennoch passiert nix am TC wenn ich die Türe öffne.
Danke schonmal und Grüße,
herrmie
gerade habe ich noch einen Fehler in "get HM configCheck"
peer list not read
empty: hm.wohnzimmerWT_WindowRec
Grüße,
ZitatDas heißt wahrscheinlich soviel, dass mein RHS auf irgendetwas wartet.
heisst, dass FHEM darauf wartet, dem RHS kommandos senden zu duerfen. Anlernen Druecken waere angesagt.
ZitatRegister changes pending
ist hoffentlich selbst erklaerend - es sind aenderungen eingegeben worden, aber nicht abgeschlossen, zumindest nicht verifiziert.
ZitatDas sollte aber für den RHS jetzt erstmal egal sein, nehme ich an.
eigentlich nicht - es ist eben noch nichts an den RHS gegangen
Zitatgerade habe ich noch einen Fehler in "get HM configCheck"
wenn du einen reboot u.ae. zwischenrein machst wird das Warten auf aenderungen und der commandstack geloescht - das entfernt evtl. einige warnings aus HMInfo, aber loest keine Probleme
Mache bestandsaufnahme:
- getConfig bei beiden Devices
- ggf Anlernen, jedenfalls pruefen, dass alle Kommandos bearbeitet sind (proto_state = cmds_done)
- registerlisten den RHS und des winrec posten
- peerlisten posten
Gruss Martin
Hallo,
ich habe fhem neu gestartet, dann waren die errors weg. Aber wie du schon gesagt hast, löst das die Probleme nicht.
Nun habe ich deine Befehle befolgt und dann waren die errors wieder da.
Hier nun RegList vom TC:
RegL_01: 08:00 00:00 2014-02-27 22:49:07
und die RegList vom RHS:
RegL_00: 02:01 09:00 0A:25 0B:74 0C:99 10:01 14:06 00:00 2014-02-27 22:50:25
RegL_01: 08:00 20:6C 21:00 22:64 30:06 00:00 2014-02-27 22:50:25
peerlist gibt es keine, dass wird unter anderem wahrscheinlich das Problem sein.
Grüße
herrmie
Hallo,
ES GEHT!!!!!!!!!!!!! ÄH ganzes Wochenende und es GEEEEEEEEEEEEEHT.
Problem ist einfach gewesen.
Statt
set hm.wohnzimmerTerassentuer peerChan 0 hm.wohnzimmerWT_WindowRec single
muss
set hm.wohnzimmerTerassentuer peerChan 0 hm.wohnzimmerWT_WindowRec single set
Dann bei beiden die Anlerntaste gedrückt und schwupp die wupp gings auch schon.
Grüße
herrmie
prima - nur den Grund kann ich nicht glauben.
set ist default - kann weg gelassen werden wenn es "set" und nicht "unset" ist und wenn der naechste Parameter nicht gebraucht wird, also (actor/remote/both) auf both stehen soll
Hallo,
ich bin darauf gekommen, weil die peerlist nicht da war. Klingt komisch ist aber so. ;)
Grüße und Danke für deine Zeit und Mühe.
Hallo,
ich bins nochmal. Mir ist aufgefallen, dass zwar mein TC die winOpn Temperatur setzt, aber mein Heizkörperthermostat nimmt dies nicht entgegen. An was kann das nun wieder liegen?
Wenn ich so am Rädle des TC drehe, dann ändert sich auch dir Temperatur am Heizkörperthermostat.
Grüße
herrmie
Hi,
- der TC ist mit dem RT gepeert
- der TC erkennt die win-open temp sendet sie aber nicht?
?? was steht in desired-temp des TC?
So der TC die desired-temp nicht auf winOpnTemp setzt bedeuted dies, dass der Fenster-OffenTrigger nicht akzeptiert wird. Hier solltest du "shCtValLo" betrachten
Gruss Martin
Zitat- der TC ist mit dem RT gepeert
ja
Zitat- der TC erkennt die win-open temp sendet sie aber nicht?
ja
Zitat?? was steht in desired-temp des TC?
desired-temp 12 2014-03-02 14:10:03
Ich nehme an, dass die shCtValLo unter dem TC bei channel WindowRec zu finden ist:
R-hm.wohnzimmerTerassentuer_chn-01-shCtValLo 50 2014-02-27 22:58:26Liegt es vielleicht daran, bekomme ich mit get HM configCheck:
incomplete register list
hm.wohnzimmerWT_Climate: RegL_07:,RegL_08:,RegL_09:Grüße,
Hallo,
Habe mir auch das neue TC zugelegt.
Habe selbe Kombination TC, RT und RHS.
Muss am RT eigentlich burstXmit aktiviert werden, damit das RT die Änderungen sofort empfängt und nicht erst nach 2,30min??
Und wenn ja wie kann ich das aktivieren? Ist ja soweit ich weiß standardmäßig aus Stromspargründen deaktiviert am RT. Geht des in Fhem oder nur mit der Homematic Konfigurationssoftware (zB vom HMLan)?
Grüße
philipp
Zitat von: Phil__ am 02 März 2014, 15:45:10
Muss am RT eigentlich burstXmit aktiviert werden
...
Und wenn ja wie kann ich das aktivieren?
Das Einschalten macht Sinn, und zum Einschalten kannst Du das Attribut burstAccess auf 1_auto schalten, das sollte reichen.
ZitatDas Einschalten macht Sinn, und zum Einschalten kannst Du das Attribut burstAccess auf 1_auto schalten, das sollte reichen.
Wie bzw. mit welchem Befehl mache ich das?
mal sortieren
- TC-RT burst
=> ob der TC dem RT das offene Fenster mit 'burst" uebertragen will muss man ausmessen. Wenn ihr die rohmessages aufzeichnet kann man es sehen
- RT burst einschalten
=> um den RT in burst zu versetzen muss das Register bustRx gesetzt werden. Das Attribut burstAccess ist 'FHEM-intern' und beauftragt FHEM immer einen burst zu versuchen, wenn nachrichten uebertragen werden sollen - von FHEM nach Device. Das funktioniert nur, wenn im device auch das Register gesetzt ist!
Alternativ zu attribut burstAccess gibt es noch das kommando burstXmit - damit kann man einen burst manuell triggern wenn FHEM etwas senden will.
set <rt> regSet burstRx on
attr <rt> burstAccess 1_auto
set <rt> brustXmit
- R-hm.wohnzimmerTerassentuer_chn-01-shCtValLo 50
=> der TC erkennt das Fenster-offen also nur, wenn der wert 50 ueberschritten ist. Dein fensterkontakt sendet einen wert bei jedem trigger - der liegt zwischen 0 (0%) und 200 (100%). Die 50 (25%) sollten eigentlich immer erreicht werden - du kannst es aber im Fenserkontakt umprogrammiert haben. Also sicherheitshalber die Register des Kontakts pruefen und einmal rohmessages loggen.
Hallo,
wie logge ich denn rohmessages?
Danke und Grüße,
http://forum.fhem.de/index.php/topic,16563.0.html
21E419 - Terassentuer
2621E5 - TC
257499 - HMLAN1
2014.03.04 16:28:17 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:58128022 IDcnt:000A
2014.03.04 16:28:27 0: HMLAN_Parse: HMLAN1 R:E21E419 stat:0000 t:5812A84D d:FF r:FFC6 m:9A A441 21E419 257499 015500
2014.03.04 16:28:27 0: HMLAN_Send: HMLAN1 S:S8DB5D55A stat: 00 t:00000000 d:01 r:8DB5D55A m:9A 8002 257499 21E419 0101C800
2014.03.04 16:28:28 0: HMLAN_Parse: HMLAN1 R:R8DB5D55A stat:0002 t:00000000 d:FF r:7FFF m:9A 8002 257499 21E419 0101C800
2014.03.04 16:28:28 0: HMLAN_Parse: HMLAN1 R:E21E419 stat:0000 t:5812AACC d:FF r:FFC3 m:9B B041 21E419 2621E5 015500
2014.03.04 16:28:28 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:5812AB4B d:FF r:FFB7 m:9B 8002 2621E5 21E419 00
2014.03.04 16:28:35 0: HMLAN_Parse: HMLAN1 R:E21E419 stat:0000 t:5812C78D d:FF r:FFBF m:9C A441 21E419 257499 0156C8
2014.03.04 16:28:35 0: HMLAN_Send: HMLAN1 S:S8DB5F499 stat: 00 t:00000000 d:01 r:8DB5F499 m:9C 8002 257499 21E419 0101C800
2014.03.04 16:28:36 0: HMLAN_Parse: HMLAN1 R:R8DB5F499 stat:0002 t:00000000 d:FF r:7FFF m:9C 8002 257499 21E419 0101C800
2014.03.04 16:28:36 0: HMLAN_Parse: HMLAN1 R:E21E419 stat:0000 t:5812CA0D d:FF r:FFC1 m:9D B041 21E419 2621E5 0156C8
2014.03.04 16:28:36 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:5812CA8C d:FF r:FFB4 m:9D 8002 2621E5 21E419 00
2014.03.04 16:28:42 0: HMLAN_Send: HMLAN1 I:K
2014.03.04 16:28:42 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:5812E1D9 IDcnt:000A
Das ist alles aus dem kompletten Logfile oder wolltest du was anderes?
Grüße,
herrmie
hi herrmie,
das war alles.
die tuer sagt dem TC erfolgreich bescheid, der TC akzeptiert den Zustand. ueber shCtValLo vergleicht er, ob der Level erreicht ist. Das regiser sollte einen kleinen wert enthalten - wahrscheinlich steht 50 drin..? Dann sollte der TC die dazugehoerige temp winOpnTemp einstellen. Das macht er - habe ich verstanden - weder am TC noch am RT (in den14 sec Aufzeichnung hat er nichts an den RT gesendet)
Einstellen kann man noch modePrioManu - wenn dein TC in manu ist kann man hier einige "eingaenge" blockieren.
Dann faellt mir noch inhibit ein - das hast du nicht zufaellig eingeschaltet? Man kann nicht erkennen, ob es gesetzt ist...
Gruss Martin
Hallo,
ich tue mich schwer die Werte auszulesen (inhibit). Ich habe nun unter meinem RC geschaut, da finde ich den Wert nicht.
shCtValLo , schau ich mir dann nochmal an, wenn ich zuhause bin un die Tür offen.
Grüße,
herrmie
inhibit kann man auch nicht auslesen - jedenfalls habe ich es noch nicht gefunden. Du koenntest aber ein inhibit off schicken - einfach einmal so.
Gruss Martin
Hallo,
Unknown command inhibit, try help.
was hast du eingegeben?
set tc inhibit off
?
Hallo,
ups ... jetzt ja. :)
Ich habe mir das nochmal durch den Kopf gehen lassen. Im Grunde genommen bekommt der TC ja eine Nachricht die Temp auf winOpn Temp zu stellen. Macht das dann auch. Und dann sollte er es an den RT senden.
Wenn ich z.B. über FHEM die Temperatur des TC ändere, dann ändert er mir das aber auch nicht an den RT, wäre zwar ein anderes Problem und hat hier nix zu suchen, aber vielleicht gibt es da einen Vergleich.
Grüße,
herrmie
ich denke schon, das es das gleiche ist. Der TC muss die Desired-temp an seine RTs durchreichen - das ist doch die primaere Idee eines Kontroller.
zeichne doch einmal die rohmessages uber min 10 min auf. Da sollten welche ausgetauscht werden zwischen TC und RT.
Hallo,
so wie es aussieht geht es nun, ich denke es lag an dem inhibit? Was macht dieses?
21E419 - Terassentuer
2621E5 - TC
257499 - HMLAN1
21CF03 - RT
2014.03.06 08:10:45.108 0: HMLAN_Send: HMLAN1 I:K
2014.03.06 08:10:45.114 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:60980610 IDcnt:000A
2014.03.06 08:10:58.659 0: HMLAN_Parse: HMLAN1 R:E21CF03 stat:0000 t:60983AF4 d:FF r:FFC4 m:6B 8610 21CF03 000000 0A60C40F0018
2014.03.06 08:11:10.111 0: HMLAN_Send: HMLAN1 I:K
2014.03.06 08:11:10.118 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:609867BE IDcnt:000A
2014.03.06 08:11:35.116 0: HMLAN_Send: HMLAN1 I:K
2014.03.06 08:11:35.122 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:6098C96F IDcnt:000A
2014.03.06 08:12:00.133 0: HMLAN_Send: HMLAN1 I:K
2014.03.06 08:12:00.139 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:60992B2B IDcnt:000A
2014.03.06 08:12:06.438 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:609943C1 d:FF r:FFBC m:79 865A 2621E5 000000 60C429
2014.03.06 08:12:25.137 0: HMLAN_Send: HMLAN1 I:K
2014.03.06 08:12:25.143 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:60998CDB IDcnt:000A
2014.03.06 08:12:26.437 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:609991E3 d:FF r:FFBC m:79 8470 2621E5 000000 00C429
2014.03.06 08:12:50.147 0: HMLAN_Send: HMLAN1 I:K
2014.03.06 08:12:50.153 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:6099EE90 IDcnt:000A
2014.03.06 08:13:15.151 0: HMLAN_Send: HMLAN1 I:K
2014.03.06 08:13:15.158 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:609A5040 IDcnt:000A
2014.03.06 08:13:33.392 0: HMLAN_Parse: HMLAN1 R:E21E419 stat:0000 t:609A9777 d:FF r:FFC0 m:B2 A441 21E419 257499 016100
2014.03.06 08:13:33.488 0: HMLAN_Send: HMLAN1 S:S963D741D stat: 00 t:00000000 d:01 r:963D741D m:B2 8002 257499 21E419 0101C800
2014.03.06 08:13:33.780 0: HMLAN_Parse: HMLAN1 R:R963D741D stat:0002 t:00000000 d:FF r:7FFF m:B2 8002 257499 21E419 0101C800
2014.03.06 08:13:34.033 0: HMLAN_Parse: HMLAN1 R:E21E419 stat:0000 t:609A99F8 d:FF r:FFC0 m:B3 B041 21E419 2621E5 016100
2014.03.06 08:13:34.158 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:609A9A76 d:FF r:FFBF m:B3 8002 2621E5 21E419 00
2014.03.06 08:13:40.156 0: HMLAN_Send: HMLAN1 I:K
2014.03.06 08:13:40.162 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:609AB1F0 IDcnt:000A
2014.03.06 08:13:43.440 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:609ABEB9 d:FF r:FFBD m:C9 8410 2621E5 000000 0B90C40F24
2014.03.06 08:13:58.910 0: HMLAN_Parse: HMLAN1 R:E21CF03 stat:0000 t:609AFB29 d:FF r:FFC7 m:6C 8610 21CF03 000000 0A60C40F0018
2014.03.06 08:14:05.159 0: HMLAN_Send: HMLAN1 I:K
2014.03.06 08:14:05.166 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:609B139F IDcnt:000A
2014.03.06 08:14:30.164 0: HMLAN_Send: HMLAN1 I:K
2014.03.06 08:14:30.171 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:609B7550 IDcnt:000A
2014.03.06 08:14:55.172 0: HMLAN_Send: HMLAN1 I:K
2014.03.06 08:14:55.178 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:609BD703 IDcnt:000A
2014.03.06 08:15:06.188 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:609C0201 d:FF r:FFBF m:7A 865A 2621E5 000000 90C52A
2014.03.06 08:15:16.190 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:609C2914 d:FF r:FFBE m:CA 8410 2621E5 000000 0B90C50F24
2014.03.06 08:15:20.180 0: HMLAN_Send: HMLAN1 I:K
2014.03.06 08:15:20.186 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:609C38B6 IDcnt:000A
2014.03.06 08:15:26.189 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:609C5024 d:FF r:FFBE m:7A 8470 2621E5 000000 00C52A
2014.03.06 08:15:45.184 0: HMLAN_Send: HMLAN1 I:K
2014.03.06 08:15:45.191 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:609C9A66 IDcnt:000A
2014.03.06 08:16:10.190 0: HMLAN_Send: HMLAN1 I:K
2014.03.06 08:16:10.197 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:609CFC18 IDcnt:000A
2014.03.06 08:16:35.196 0: HMLAN_Send: HMLAN1 I:K
2014.03.06 08:16:35.203 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:609D5DCA IDcnt:000A
2014.03.06 08:16:55.320 0: HMLAN_Parse: HMLAN1 R:E21CF03 stat:0000 t:609D82C0 d:FF r:FFC3 m:6D 8610 21CF03 000000 0A90C50F0018
2014.03.06 08:17:00.206 0: HMLAN_Send: HMLAN1 I:K
2014.03.06 08:17:00.213 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:609DBF7F IDcnt:000A
Grüße,
herrmie
Zitatso wie es aussieht geht es nun, ich denke es lag an dem inhibit? Was macht dieses?
ich habe keine umfassende Beschreibung des Inhibit. Generell blockiert es aenderungen fuer das Device/den Kanal.
Wie ich es aktuell sehe bedeuted dies
- die Zentrale darf weiter aendern
- eingaben von peers (auch den internen ) werden ignoriert
In wie fern dies fuer ein stellrad eines RT zutrifft kann ich nicht sagen - das ist kein peer (im gegensatz zu den eingebauten Tastern eines DimTBU)
Gut vorstellbar, dass der RT dann nicht mehr auf den TC reagiert.
Leider kann ich den Inhibit Zustand nicht auslesen - vielleicht finde ich es noch einmal irgendwo
Gruss Martin
Hallo,
falscher Alarm. Ich denke, dass ich falsch geschaut habe. Es geht immernoch nicht. Hier nochmal die rohmessages:
21E419 - Terassentuer
2621E5 - TC
257499 - HMLAN1
21CF03 - RT
2014.03.07 17:57:30.592 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 17:57:30.598 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67D7D7F2 IDcnt:0002
2014.03.07 17:57:44.407 0: HMLAN_Parse: HMLAN1 R:E21E419 stat:0000 t:67D80DDD d:FF r:FFC4 m:BC A441 21E419 257499 0166C8
2014.03.07 17:57:44.416 0: HMLAN_Send: HMLAN1 I:+21E419,00,00,
2014.03.07 17:57:44.500 0: HMLAN_Send: HMLAN1 S:+21E419,00,01,FE1F
2014.03.07 17:57:44.502 0: HMLAN_Send: HMLAN1 S:S9D7AA626 stat: 00 t:00000000 d:01 r:9D7AA626 m:BC 8002 257499 21E419 0101C800
2014.03.07 17:57:44.547 0: HMLAN_Parse: HMLAN1 R:R9D7AA626 stat:0002 t:00000000 d:FF r:7FFF m:BC 8002 257499 21E419 0101C800
2014.03.07 17:57:45.042 0: HMLAN_Parse: HMLAN1 R:E21E419 stat:0000 t:67D8105A d:FF r:FFC3 m:BD B041 21E419 2621E5 0166C8
2014.03.07 17:57:45.171 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:67D810D9 d:FF r:FFBE m:BD 8002 2621E5 21E419 00
2014.03.07 17:57:54.442 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:67D83511 d:FF r:FFBA m:EF 8410 2621E5 000000 0B60C82F24
2014.03.07 17:57:55.596 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 17:57:55.602 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67D839A2 IDcnt:0003
2014.03.07 17:58:15.670 0: HMLAN_Parse: HMLAN1 R:E21CF03 stat:0000 t:67D887FE d:FF r:FFC6 m:8A 8610 21CF03 000000 0AA8C80F6418
2014.03.07 17:58:20.600 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 17:58:20.747 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67D89B52 IDcnt:0003
2014.03.07 17:58:45.620 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 17:58:45.627 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67D8FD11 IDcnt:0003
2014.03.07 17:59:10.630 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 17:59:10.636 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67D95EC6 IDcnt:0003
2014.03.07 17:59:35.633 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 17:59:35.639 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67D9C075 IDcnt:0003
2014.03.07 17:59:42.190 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:67D9DA05 d:FF r:FFBB m:99 865A 2621E5 000000 60C827
2014.03.07 18:00:00.637 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 18:00:00.649 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67DA2225 IDcnt:0003
2014.03.07 18:00:02.190 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:67DA2828 d:FF r:FFB8 m:99 8470 2621E5 000000 00C827
2014.03.07 18:00:25.643 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 18:00:25.649 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67DA83D6 IDcnt:0003
2014.03.07 18:00:50.655 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 18:00:50.661 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67DAE58D IDcnt:0003
2014.03.07 18:01:15.672 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 18:01:15.679 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67DB474B IDcnt:0003
2014.03.07 18:01:16.669 0: HMLAN_Parse: HMLAN1 R:E21CF03 stat:0000 t:67DB4B21 d:FF r:FFC6 m:8B 8610 21CF03 000000 0AA8C80F6418
2014.03.07 18:01:40.682 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 18:01:40.688 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67DBA900 IDcnt:0003
2014.03.07 18:02:05.686 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 18:02:05.692 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67DC0AAF IDcnt:0003
2014.03.07 18:02:28.440 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:67DC6387 d:FF r:FFBA m:9A 865A 2621E5 000000 60C927
2014.03.07 18:02:30.691 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 18:02:30.697 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67DC6C60 IDcnt:0003
2014.03.07 18:02:44.900 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:67DC8A9A d:FF r:FFB9 m:F1 8410 2621E5 000000 0B60C92F24
2014.03.07 18:02:48.440 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:67DCB1AB d:FF r:FFB9 m:9A 8470 2621E5 000000 00C927
2014.03.07 18:02:55.700 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 18:02:55.706 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67DCCE15 IDcnt:0003
2014.03.07 18:03:20.703 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 18:03:20.710 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67DD2FC5 IDcnt:0003
2014.03.07 18:03:45.713 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 18:03:45.719 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67DD917A IDcnt:0003
2014.03.07 18:04:03.420 0: HMLAN_Parse: HMLAN1 R:E21CF03 stat:0000 t:67DDD699 d:FF r:FFC6 m:8C 8610 21CF03 000000 0AA8C90F6418
2014.03.07 18:04:10.717 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 18:04:10.723 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67DDF329 IDcnt:0003
2014.03.07 18:04:35.732 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 18:04:35.740 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67DE54E4 IDcnt:0003
2014.03.07 18:05:00.191 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:67DEB464 d:FF r:FFBA m:9B 865A 2621E5 000000 60C928
2014.03.07 18:05:00.736 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 18:05:00.749 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67DEB698 IDcnt:0003
2014.03.07 18:05:20.191 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:67DF0287 d:FF r:FFBA m:9B 8470 2621E5 000000 00C928
2014.03.07 18:05:25.749 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 18:05:25.755 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67DF184C IDcnt:0003
2014.03.07 18:05:50.760 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 18:05:50.766 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67DF7A02 IDcnt:0003
2014.03.07 18:06:15.777 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 18:06:15.784 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67DFDBC0 IDcnt:0003
2014.03.07 18:06:35.671 0: HMLAN_Parse: HMLAN1 R:E21CF03 stat:0000 t:67E0296A d:FF r:FFC5 m:8D 8610 21CF03 000000 0AA8C90F6418
2014.03.07 18:06:40.785 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 18:06:40.791 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67E03D73 IDcnt:0003
2014.03.07 18:07:05.790 0: HMLAN_Send: HMLAN1 I:K
2014.03.07 18:07:05.805 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023266 d:257499 O:257499 t:67E09F2C IDcnt:0003
Ich habe mir nun nochmal den TC und RT angeschaut. Ist das normal, dass beim RT unter channel Weather folgendes steht:
STATE ???
Normal eigentlich nicht oder? Wobei die peerlist i.O. ist.
peerList hm.wohnzimmerWT_Weather, 2014-03-07 17:49:16
Grüße,
herrmie
das mit der Status ist korrekt - ich werde aber ein paar der ??? 'entfernen', damit es nicht so sehr nach Fehler aussieht.
Dein TC bekommt den Winopen trigger 57:47. Um 59:42 sendet er 12C ueber den 'teamInform' an alle seine Freunde. Der RT scheint es zu ignorieren.
Der TC sendet kein 'burst' -muss ich noch einmal testen, ob das Normal ist.
Gruss Martin
Hmmm also ich stehe gerade vor nem ähnlichen Problem: Ich hatte, bevor ich den Wandthermostaten hatte, den Fensterkontakt direkt am Heizkörperthermostat. Das ging super, schnell und zuverlässig.
Jetzt, wenn ich den Fensterkontakt mit dem Wandthermostaten peere, und diesen dann mit dem Heizkörper, dann ist das - wenn überhaupt - lahm ohne Ende. Öffnen des Fensters klappt meist noch gut und so in 10-20 Sekunden. Aber schließen des Fensters kriegt der Heizkörper mal erst nach 2 Minuten mit, mal offenbar gar nicht.
Was spricht denn eigentlich genau dagegen, den Fensterkontakt mit dem Heizkörperthermostaten zu peeren? Das hab ich jetzt behelfsweise so (obwohl überall steht "so nicht") und es geht schnell und zuverlässig ... Ist das Problem damit, dass der Wandthermostat
a) ggf. die falsche Solltemperatur anzeigt oder dass er
b) während das Fenster offen ist, möglicherweise einen tempList-Schaltpunkt überträgt und der Thermostat dann hochfährt, obwohl das Fenster noch offen ist?
Mit a) könnte ich gut leben, mit b) weniger ;)
wenn du es eingerichtet hast könntest du sicher einfach einen Datensatz erstellen. Ich hätte gerne die Register - mache ein saveConfig in HMInfo, dann habe ich alle - vom TC, RT und den RHS.
Dann logge die Rohmessages
10 min betrieb
fenster öffnen, 10 min offen
schliessen, 15 min warten
Gruss Martin
Hallo,
ich hole mal diesen thread aus der Versenkung.
Setup: TC mit RT gepeered. RHS mit TC gepeered.
Problem: RHS an der Terassentür sendet "offen" an den TC, TC stellt die winOpenTemp ein (12°), RT bekommt das aber nicht mit.
21E419 - Terassentuer
2621E5 - TC
257499 - HMLAN1
21CF03 - RT
2014.10.05 15:33:23.688 0: HMLAN_Parse: HMLAN1 R:E21E419 stat:0000 t:892FF2EF d:FF r:FFAF m:5A A441 21E419 257499 01B300
2014.10.05 15:33:24.326 0: HMLAN_Parse: HMLAN1 R:E21E419 stat:0000 t:892FF56D d:FF r:FFB6 m:5B B041 21E419 2621E5 01B300
2014.10.05 15:33:24.452 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:892FF5EB d:FF r:FFC0 m:5B 8002 2621E5 21E419 00
2014.10.05 15:33:33.294 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:89301877 d:FF r:FFBB m:20 8410 2621E5 000000 0BA8CE0B1D
2014.10.05 15:33:37.792 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:89302A0B d:FF r:FFBF m:D0 865A 2621E5 000000 A8CE3C
2014.10.05 15:33:57.793 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:8930782E d:FF r:FFC0 m:D0 8470 2621E5 000000 00CE3C
2014.10.05 15:35:58.793 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:893250E8 d:FF r:FFBF m:D1 865A 2621E5 000000 A8CF3C
2014.10.05 15:36:08.795 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:893277FB d:FF r:FFBF m:22 8410 2621E5 000000 0BA8CF0B1D
2014.10.05 15:36:18.794 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:89329F0B d:FF r:FFC0 m:D1 8470 2621E5 000000 00CF3C
2014.10.05 15:36:48.443 0: HMLAN_Send: HMLAN1 S:SE086E081 stat: 00 t:00000000 d:01 r:E086E081 m:05 B011 257499 2621E5 0001
2014.10.05 15:36:48.961 0: HMLAN_Parse: HMLAN1 R:RE086E081 stat:0001 t:893314E8 d:FF r:FFC0 m:05 8002 2621E5 257499 00
2014.10.05 15:38:05.293 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:89343F1E d:FF r:FFBF m:D2 865A 2621E5 000000 A8CF3C
2014.10.05 15:38:25.294 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:89348D41 d:FF r:FFBF m:D2 8470 2621E5 000000 00CF3C
2014.10.05 15:38:52.803 0: HMLAN_Parse: HMLAN1 R:E21E419 stat:0000 t:8934F8BA d:FF r:FFBD m:5C A441 21E419 257499 01B4C8
2014.10.05 15:38:53.439 0: HMLAN_Parse: HMLAN1 R:E21E419 stat:0000 t:8934FB37 d:FF r:FFBE m:5D B041 21E419 2621E5 01B4C8
2014.10.05 15:38:53.566 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:8934FBB6 d:FF r:FFC0 m:5D 8002 2621E5 21E419 00
2014.10.05 15:39:03.295 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:893521B8 d:FF r:FFC0 m:24 8410 2621E5 000000 0B60CF2B1D
inhibit ist auf off beim TC.
shCtValLo 50 beim TC
Vielleicht hat einer eine idee.
Danke und Grüße,
herrmie
generell übernimmt der RT vom TC die temp?
Hallo,
ja, wenn ich am TC die Temperatur einstelle (am Gerät selber) dann übernimmt der RT alles.
Grüße,
Der tc sendet - aber keinen burst. Der rt kann also nicht aufwachen.
Muss einmal ueberlegen, was man machen kann. In jedem fall kann man den rhs mit den rt peeren
Hallo,
aber dennoch den RHS mit dem TC gepeered lassen? Oder mit TC unpeeren und dann peer mit RT?
burst heißt quasi: "wache auf um befehle zu empfangen"?
Grüße,
Genau
Burst ist ein "alle aufwachen ". Alle sind dabei die burst devices. Beim rt kann man einstellen, ob er auf burst hoert oder nicht - siehe register im device. Schaltest du es ein bleibt der rt im halbschlaf. Kommt ein burst - egal von oder fuer wen - schreckt er auf und prueft, ob er gemeint ist. Das kostet batterie, je oefter burst signal kommt um so mehr.
Wenn der tc ein fenster - auf melden soll wird er ein burst einleitend senden. Beim rt muss es also enabled sein
Hallo,
ich habe das nun enabled und funktioniert auch nur dauert es ca 2 Minuten bis der RT das mitbekommt. Gibt es da vielleicht noch einen timer, den man ändern könnte?
TC:
2014-10-11_14:25:21 hm.wohnzimmerWT desired-temp: 21.0
2014-10-11_14:49:17 hm.wohnzimmerWT time-request: -
2014-10-11_14:49:17 hm.wohnzimmerWT CMDs_done
2014-10-11_15:01:15 hm.wohnzimmerWT measured-temp: 21.6
2014-10-11_15:01:15 hm.wohnzimmerWT batteryLevel: 2.6
2014-10-11_15:01:15 hm.wohnzimmerWT desired-temp: 12.0
2014-10-11_15:04:00 hm.wohnzimmerWT measured-temp: 21.7
RT:
2014-10-11_15:00:51 hm.wohnzimmerHT desired-temp: 21.0
2014-10-11_15:03:44 hm.wohnzimmerHT measured-temp: 21.6
2014-10-11_15:03:44 hm.wohnzimmerHT batteryLevel: 2.9
2014-10-11_15:03:44 hm.wohnzimmerHT actuator: 0
2014-10-11_15:03:44 hm.wohnzimmerHT desired-temp: 12.0
2014-10-11_15:06:22 hm.wohnzimmerHT measured-temp: 21.7
15:01:15 - TC stellt auf winOpenTemp
15:03:44 - RT stellt auf winOpenTemp
Grüße,
herrmie
zeichne doch einmal die rohmessages auf, wenn das Fenster auf geht - und die folgenden 5 min.
vielleicht noch das Schliessen, auch mit 5min
Hallo,
heute ging es wieder nicht, dass der RT die Temp auf winOpenTemp setzt:
21E419 - Terassentuer
2621E5 - TC
257499 - HMLAN1
21CF03 - RT
2014.10.12 12:31:17 1: HMLAN_Parse: HMLAN1 new condition ok
2014.10.12 12:33:32.844 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:AC991B3B d:FF r:FFB8 m:12 865A 2621E5 000000 A8D53D
2014.10.12 12:33:49.201 0: HMLAN_Parse: HMLAN1 R:E21E419 stat:0000 t:AC995B22 d:FF r:FFBB m:B4 A441 21E419 257499 01E0C8
2014.10.12 12:33:49.840 0: HMLAN_Parse: HMLAN1 R:E21E419 stat:0000 t:AC995DA1 d:FF r:FFBB m:B5 B041 21E419 2621E5 01E0C8
2014.10.12 12:33:49.966 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:AC995E20 d:FF r:FFBD m:B5 8002 2621E5 21E419 00
2014.10.12 12:33:52.844 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:AC99695E d:FF r:FFBA m:12 8470 2621E5 000000 00D53D
2014.10.12 12:33:57.846 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:AC997CE9 d:FF r:FFBA m:9E 8410 2621E5 000000 0B60D52B02
2014.10.12 12:35:42.345 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:AC9B152A d:FF r:FFB9 m:13 865A 2621E5 000000 60D53D
2014.10.12 12:35:45.658 0: HMLAN_Parse: HMLAN1 R:E21CF03 stat:0000 t:AC9B221C d:FF r:FFBF m:8D 8610 21CF03 000000 0AA8D50E0018
2014.10.12 12:36:02.345 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:AC9B634D d:FF r:FFB9 m:13 8470 2621E5 000000 00D53D
2014.10.12 12:38:03.417 0: HMLAN_Parse: HMLAN1 R:E21CF03 stat:0000 t:AC9D3C4E d:FF r:FFC0 m:8E 8610 21CF03 000000 0AA8D50E0018
2014.10.12 12:38:41.345 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:AC9DD07C d:FF r:FFBA m:14 865A 2621E5 000000 60D53D
2014.10.12 12:39:01.345 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:AC9E1E9F d:FF r:FFB9 m:14 8470 2621E5 000000 00D53D
2014.10.12 12:40:06.660 0: HMLAN_Parse: HMLAN1 R:E21CF03 stat:0000 t:AC9F1DCB d:FF r:FFC0 m:8F 8610 21CF03 000000 0AA8D50E0018
2014.10.12 12:41:25.846 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:ACA05328 d:FF r:FFB9 m:15 865A 2621E5 000000 60D53D
2014.10.12 12:41:45.846 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:ACA0A14B d:FF r:FFBA m:15 8470 2621E5 000000 00D53D
2014.10.12 12:42:59.662 0: HMLAN_Parse: HMLAN1 R:E21CF03 stat:0000 t:ACA1C1AD d:FF r:FFC0 m:90 8610 21CF03 000000 0AA8D50E0018
2014.10.12 12:43:56.097 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:ACA29E27 d:FF r:FFBA m:16 865A 2621E5 000000 60D53D
2014.10.12 12:44:16.096 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:ACA2EC4A d:FF r:FFB9 m:16 8470 2621E5 000000 00D53D
2014.10.12 12:45:38.163 0: HMLAN_Parse: HMLAN1 R:E21CF03 stat:0000 t:ACA42CE9 d:FF r:FFC0 m:91 8610 21CF03 000000 0AA8D50E0018
2014.10.12 12:46:11.847 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:ACA4B081 d:FF r:FFB9 m:17 865A 2621E5 000000 60D53D
2014.10.12 12:46:31.847 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:ACA4FEA5 d:FF r:FFB9 m:17 8470 2621E5 000000 00D53D
2014.10.12 12:48:02.165 0: HMLAN_Parse: HMLAN1 R:E21CF03 stat:0000 t:ACA65F80 d:FF r:FFC0 m:92 8610 21CF03 000000 0AA8D50E0018
2014.10.12 12:48:13.098 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:ACA68A36 d:FF r:FFB9 m:18 865A 2621E5 000000 60D63D
2014.10.12 12:48:23.099 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:ACA6B149 d:FF r:FFB9 m:A4 8410 2621E5 000000 0B60D62B02
2014.10.12 12:48:33.097 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:ACA6D859 d:FF r:FFB9 m:18 8470 2621E5 000000 00D63D
2014.10.12 12:50:11.916 0: HMLAN_Parse: HMLAN1 R:E21CF03 stat:0000 t:ACA85A69 d:FF r:FFBF m:93 8610 21CF03 000000 0AA8D60E0018
2014.10.12 12:50:57.310 0: HMLAN_Parse: HMLAN1 R:E21E419 stat:0000 t:ACA90BC2 d:FF r:FFB7 m:B6 A441 21E419 257499 01E100
2014.10.12 12:50:57.949 0: HMLAN_Parse: HMLAN1 R:E21E419 stat:0000 t:ACA90E41 d:FF r:FFBD m:B7 B041 21E419 2621E5 01E100
2014.10.12 12:50:58.077 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:ACA90EC1 d:FF r:FFBA m:B7 8002 2621E5 21E419 00
2014.10.12 12:51:04.098 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:ACA92647 d:FF r:FFBA m:19 865A 2621E5 000000 A8D63E
2014.10.12 12:51:14.099 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:ACA94D5A d:FF r:FFB9 m:A5 8410 2621E5 000000 0BA8D60B02
2014.10.12 12:51:24.098 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:ACA9746A d:FF r:FFBA m:19 8470 2621E5 000000 00D63E
2014.10.12 12:53:11.167 0: HMLAN_Parse: HMLAN1 R:E21CF03 stat:0000 t:ACAB16B6 d:FF r:FFC1 m:94 8610 21CF03 000000 0AA8D60E0018
2014.10.12 12:53:40.598 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:ACAB89B2 d:FF r:FFB9 m:1A 865A 2621E5 000000 A8D63E
2014.10.12 12:54:00.598 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:ACABD7D5 d:FF r:FFB9 m:1A 8470 2621E5 000000 00D63E
2014.10.12 12:55:55.919 0: HMLAN_Parse: HMLAN1 R:E21CF03 stat:0000 t:ACAD9A5E d:FF r:FFC1 m:95 8610 21CF03 000000 0AA8D60E0018
2014.10.12 12:56:06.225 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:ACADB478 d:FF r:FFB8 m:1B 865A 2621E5 000000 A8D63E
2014.10.12 12:56:22.599 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:ACAE029B d:FF r:FFB9 m:1B 8470 2621E5 000000 00D63E
2014.10.12 12:58:10.099 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:ACAFA696 d:FF r:FFB8 m:1C 865A 2621E5 000000 A8D63E
2014.10.12 12:58:26.420 0: HMLAN_Parse: HMLAN1 R:E21CF03 stat:0000 t:ACAFE65A d:FF r:FFC1 m:96 8610 21CF03 000000 0AA8D60E0018
2014.10.12 12:58:30.126 0: HMLAN_Parse: HMLAN1 R:E2621E5 stat:0000 t:ACAFF4B9 d:FF r:FFB9 m:1C 8470 2621E5 000000 00D63E
der TC sendet fleissig - der RT ändert nichts. hm. gepeert ist der climate-kanal schon mit dem TC?
Hallo,
ja, ist er:
DEF
21CF0302
NAME
hm.wohnzimmerHT_Climate
NR
87
STATE
peered
TYPE
CUL_HM
chanNo
02
device
hm.wohnzimmerHT
peerList
hm.wohnzimmerWT_Climate
Ich habe einen RHS, einen TC und zwei RT.
Der RHS ist gepeered sowohl mit dem TC als auch mit den RT, die Öffnung der Tür wird innerhalb von Sekunden an die RT gemeldet, diese fahren das Ventil zu.
Beim peering wurde in den Readings des RHS automatisch gesetzt
R-WZ.HMHz1.WindowRec-peerNeedsBurst on
R-WZ.HMHz2.WindowRec-peerNeedsBurst on
R-WZ.HMTh.WindowRec-peerNeedsBurst on
So weit, so gut - denn ich habe eigentlich das umgekehrte Problem: Wenn der Kater rausgelassen wird, ist die Tür ca. 3 Sekunden offen. Ich möchte nicht, dass für eine so kurze Zeit nicht die Heizungsventile zu und wieder auf gefahren werden.
Der RHS hat ein Register
R-eventDlyTime 0 s
Wer hat Erfahrung damit ? Wenn ich das auf 10 setze, und innerhalb von 10 Sekunden die Tür wieder zu ist - wird dann überhaupt ein Event gesendet ?
LG
pah
würde ich so erwarten - könnte man einfach testen.
mit get regList kannst du sehen, dass man die Zeit bis 7620sec ausdehnen kann. Hast du sicher geprüft.
Sinn macht es m.E. immer um den Zwischenwert "offen" beim Kippen zu verhindern. Sollte auch bei Katzen helfen.
das register gibt an wie viele sekunden nach der letzten zustandsänderung der aktuelle zustand gesendet wird. wenn innerhalb der delay time ein neuer zustand kommt fängt der zähler wieder von vorne an.
in dem katzen beispiel würde also bei nur 3 sekunden öffnungszeit das open unterdrückt und es kommt nur ein einzelnes close 10 sekunden nach dem schliessen.
gruss
andre
Tut prima.
LG
pah
Nur fuer die pedanten wie mich :
Wenn du 10sec einstellst, das fenster auf - zu machst innerhalb 5sec : kommt eine message ?
Wenn du nun auf -5s warten -zu - 5s warten - auf - 5s warten.... machst - kommt der trigger 10s nach der letzten aenderung ooder 10s nach dem ersten auf ?
Hoffentlich ersteres
jede änderung setzt den zähler zurück und der timeout beginnt von neuem. erst wenn timeout sekunden keine änderung erfolgt ist wird ein mal der aktuelle zustand gesendet.
gruss
andre
danke.
delay ist dann der falsche Begriff - es ist ein Filter.
werde ich im Kommentar so eintragen
ich finde filter passt nicht.
das würde passen wenn man beim rhs z.b. tiltet heraus filtern und nur noch open und closed durch lassen würde.
hier wird ja die verzögerung angegeben die gewartet wird bis der aktuelle zustand gesendet wird. also passt delay gut.
Verhalten ist tatsächlich so, wie von justme beschrieben. Allerdings: ein Filter erzeugt keine Verzögerung. Verzögerung alleine trifft es zwar auch nicht ganz wegen des Neustarts - aber mit ein paar zusätzlichen Kommentaren ist das ok.
LG
pah
Hallo FHEM Freunde,
ich habe auch eine ähnliche Konstellation.
1x HM-TC-IT-WM-W-EU
1x HM-SEC-SC
2x HM-CC-RT-DN
Noch hält sich der Thread ja in Grenzen und ich habe alles gelesen. Auch den Wiki Artikel zum DN wo das Peeren mit den SC´s und TC erwähnt ist. Stichwort
Aber trotzdem bin ich jetzt nicht sicher wie ich vorgehen soll...
Ich habe nämlich eine Kombination aus den hier genannten Szenarien und NOCH NICHTS miteinander gepeert, sondern alles einzeln in FHEM eingebunden.
Ich habe auch zwei Katzen die ich mal eben rauslassen möchte, aber die Stellmotoren nicht gleich sofort loslaufen sollen.
Meine Verzögerungszeit soll aber 5 MINUTEN betragen und nicht 3 Sekunden.
Ich habe aktuell Zeitprofile in den beiden DN´s, und auch im TC
Der SC zeigt mir aktuell nur in FHEM an ob die Tür auf ist oder zu.
Könnt Ihr eine kurze Zusammenfassug posten was nun wie gepeert werden muss?
- Kann ich den SC nun mit dem TC UND den DN´s peeren oder nicht?
- Ist eine Lösung in Sicht warum der TC nicht sofort die Desired Temp an den DN sendet, bzw. dieser diese nicht sofort annimmt?
- Was soll ich jetzt mit dem burstXmit machen? setze ich den nun für die DN´s, den TC oder den SC?
- Und muss ich jetzt beim peeren mit dem TC ein "single" oder ein "single set" machen?
Ziel ist es:
- die Temp am HM-TC-IT-WM-W-EU manuell einzustellen wenn mir danach ist, und die beiden DN´s reagieren sofort darauf.
- Aber es sollen auch die Zeitprofile ziehen. schließlich kann ich ja auch mal kurz auf 26 Grad gestellt haben und dann vergesse ich es und dann bollter die HZG weiter. Da soll dann das Zeitprofil seinen Dienst tun.
- Wenn zu irgendeiner Zeit (egal ob manuell eingestellt oder Zeitprofil) die Tür auf geht, soll nach 5 Minuten auf 16 Grad gestellt werden. Und wenn die Tür wieder länger als 5 Minuten zu, dann wieder auf vorherige oder zeitgesteuerte Temp. zurückstellen.
Fazit:
aktuell weiss ich nicht was ich mit wem peeren soll, und ob ich was am burst für die DN´s , für den SC, oder für den TC ändern soll.
Danke Euch!
Gruß
der Merlin
Zitathier wird ja die verzögerung angegeben die gewartet wird bis der aktuelle zustand gesendet wird. also passt delay gut.
das habe ich anders von dir verstanden. Ein Delay würde wohl auch keinen sinn machen.
Also Frage:
Du stellet Filter auf 20sec
dann änderst du den Zustand im Abstand von 10sec den Zustand des Fensters, 20mal. Nach 200sec bist du fertig.
=> wenn es ein Delay ist bekommst du
20 trigger, den letzten nach 210sec (190+20)
=> wenn es ein Filter ist bekommst du
einen Trigger nach 210sec. Kürzere events werden
GEFILTERTIch habe verstanden, dass nur ein Trigger kommt und somit die Katze ohne Absenken der Heizung raus darf.
ZitatAllerdings: ein Filter erzeugt keine Verzögerung.
puh - durchschnaufen.
wo kommt dass den her? Echtzeitfilter erzeugen eigentlich immer eine Verzögerung. In Regelkreisen fängt man das ab. Hier haben wir keinen regelkreis sondern nur die Meldung. Die wird um die Filterzeit verzögert.
Akademisch könnte man behaupten, das Event ist nicht "fenster auf" sondern "Fenster auf für 20sec". Damit tritt der Event erst nach der Filterzeit auf... der Filter erzeugt keine Verzögerung.
Praktisch verstehen das aber nur Theoretiker. Für Anwender heisst es, der Filter
- filtert ereignisse die kürzer sind
- verzögert die Meldung um die Filterzeit
Um es in einer Zeile zu beschreiben
"filters short events, causes reporting delay"ZitatMeine Verzögerungszeit soll aber 5 MINUTEN betragen und nicht 3 Sekunden.
beachte den mit dem Filter einhergehenden Delay. Deine Heizung wird also ggf die temp absenken, aber erst wenn das Fenster 5min offen ist.
Zitat- Kann ich den SC nun mit dem TC UND den DN´s peeren oder nicht?
kannst du
Zitat- Ist eine Lösung in Sicht warum der TC nicht sofort die Desired Temp an den DN sendet, bzw. dieser diese nicht sofort annimmt?
ich habe noch keine gefunden. An anderen stellen wird (m.E.) von FHEM erwartet, dass externe tirgger (fensterkontakte) an alle gemeldet werden -also alle entsprechend zu peeren sind. Leider habe ich keineKontakte zu HM um das zu diskutieren.
Zitat- Was soll ich jetzt mit dem burstXmit machen? setze ich den nun für die DN´s, den TC oder den SC?
bursXmit ist ein Kommando - wo willst du das setzen?
Zitat- Und muss ich jetzt beim peeren mit dem TC ein "single" oder ein "single set" machen?
kommandref sollte klarmachen, dass set default ist. Was ein Default ist, ist klar?
hallo martin,
es kommt ein event nach 210sec.
ich bin aber trotzdem der meinung das filter das verhalten nicht beschreibt und verzögerung besser ist. besonders wenn man die randbedingung es gibt nur ein event betrachtet. das hat eine erst mal unbekannte lange und es wird nach einer verzögerung gesendet. jedes event das vorher passiert setzt den zähler zurück. am ende der verzögerung wird ein mal der aktuelle zustand gesendet.
send current state once after n seconds of inactivity wäre mein vorschlag.
die logik ist genau so wie bei den cyclic info messages. hier wird alle 24 stunden automatisch ein mal gesendet wenn es in den letzten 24 stunden nicht schon eine andere übertragung gegeben hat. eine übertragung egal wie getigert setzt den timer zurück und er fängt von vorne an zu laufen.
die verzögerungen in realen filter sind aber (unerwünschte) nebeneffekte und es wird versucht diese zu minimieren.
gruss
andre
Sehe ich auch so wie justme
Ein Filter hält ein paar Dinge zurück, andere nicht. Dass dabei - wegen der notwenigen "Bearbeitungszeit" - eine Latenz entsteht, ist ja ganz richtig.
Trifft aber hier nicht, denn sprechen ja hier nicht von einer Filter-Latenzzeit, sondern von einer einstellbaren Verzögerung.
Und das mit dem "current state" ist etwas irreführend, weil zum Zeitpunkt des Timerstarts "current" etwas anderes sein kann, als später. Mein Vorschlag:
eventDlyTime = 0 s => send new state immediately
eventDlyTime = x s => send new state after x seconds if not changed again (in this period)
Betreffend die 5-Minuten-Katze: Innerhalb eines so langen Zeitraums merken eventuell die RT schon den Temperaturabfall und steuern das Ventil zu. Müsste man mal testen.
LG
pah
Zitatbesonders wenn man die randbedingung es gibt nur ein event betrachtet.
es gibt 10 Events, die FW sieht alle. Es wird aber nur eins gemeldet, die FW unterdrückt gezielt die anderen (filtert?).
Zitatdas hat eine erst mal unbekannte lange
es sind schlicht mehrere
Zitatund es wird nach einer verzögerung gesendet.
es wird sofort nach erkennen gesendet. Die Erkennung dauert nur. Peter ist mit der Beschreibung einer Latentz da schon richtig. Ein Parameter des filters.
ZitatTrifft aber hier nicht, denn sprechen ja hier nicht von einer Filter-Latenzzeit, sondern von einer einstellbaren Verzögerung.
eine verzögerung macht was sie sagt - verzögert ereignisse, schlickt aber keine.
Das ist hier weder der Fall noch gewünscht. gewünscht ist, dass die Zeit ereignisse unterdrückt (das machen Filter).
ZitatEin Filter hält ein paar Dinge zurück, andere nicht.
korrekt. Hier sind es ereignisse, die eine bestimmte Zeit unterschreiten. Andere werden weitergeleitet. Sonstige parameter werden nicht berücksichtigt.
ZitateventDlyTime = 0 s => send new state immediately
eventDlyTime = x s => send new state after x seconds if not changed again (in this period)
zu lang - passt nicht in eine Zeile. Text gut für wiki, hier bitte kürzer.
0 ist eh kein sonderfall.
schöne Umschreibung eines glitch-filter für nicht-techniker. Professionell würde ich diesen Text ablehnen.
ZitatBetreffend die 5-Minuten-Katze: Innerhalb eines so langen Zeitraums merken eventuell die RT schon den Temperaturabfall und steuern das Ventil zu. Müsste man mal testen.
wird sicher so sein - wird aber nicht empfohlen.
- die eingebaute erkennung ist deutlich schneller - reagiert auf temp-abfall. Hängt also von der temp-differenz ab
- wenn es nach 5min das nicht merkt wäre es sinnlos
- verwendet man externe Sensoren (SCI/RHS) sollte man die interne erkennung abschalten. Diese ist nur ein Notbehelf, will man keine externen kaufen. gemischt wird es zu Problemen führen - insbesondere beim Wiedereinschalten
Zitatsend current state once after n seconds of inactivity wäre mein vorschlag.
send state if stable for n seconds
filter events shorter then n sec
send new state after x seconds if not changed again
send state after x sec if unchanged
send state after x sec if stable
send state if changes and stable for x sec
kein once, kein current kein new. Sollte klar sein, dass der zustand nicht mehrfach kommt und auch, dass kein alter gesendet wird.
man kann das ganze gerne mit prosa in wiki hinterlegen, für User, die sich unter einem glitchfilter nichts vorstellen können.
Gruss
Martin
Martin,
das Ereignis ist "Tür öffnen", nicht "Tür öffnen für 10 Sekunden". Das macht den Unterschied in der Sichtweise.
Sieh mir nach, dass ich nicht weiter in die Diskussion einsteige, das führt zwischen uns beiden zu nichts.
LG
pah
da hast du recht. Ich habe schon etliche debounce filter gebaut, die genau so funktionieren.
Wenn ich "Tür öffnen für 10 Sekunden" habe will muss ich sie nach 10 sec wieder zu machen.
Das Event ist auch nicht "Tür öffnen" - zumindest beschreibt es das nicht hinreichend.
Das Event ist "Tür wurde vor 10 sec geöffnet und dann nicht mehr bewegt". Das beschreibt das Event. Es wird hier implizit, aber nicht explizit klargestellt, dass kurze Ereignisse zu gar keinem trigger führen. Möglich, dass die Tür schon seit Stunden im Wind schaukelt (ok, unwahrscheinlich). Da bekomme ich nichts mit.
Und wenn die tür nach 9 sec wieder zu ist bekomme ich auch keinen delayed trigger.
Selbst rein Akademisch betrachtet kann ich delay weder als Idee hinter der Funktion noch Erklärung des Verhaltens gelten lassen - hast es ja selbst relativiert. Delay ist nur ein technisch nicht abwendbarer schmutzeffekt des Filters (seine Latenz)
sorry, wenn du es anders siehst. ich habe so etwas einfach schon zu oft in Produkte eingebaut - hat nie jemand anders bezeichnet. Auch keine Doktoren.
Gruss Martin
Du fängst schon wieder an, über akademische Titel herzuziehen.
Schade, das beendet hier die fachliche Diskussion.
LG
pah
Hallo Freunde...
Kann ich nochmal kurz auf das Thema hier zurückkommen?
Sorry wenn ich hier nachhake.
Kann jemand bitte die ganze Soße auf die wichtigen Fakten einkochen und alle Facts bestätigen oder korrigieren?
LEGENDE
HM-TC-IT-WM-W-EU = TC = WandThermostat
HM-Sec-RHS = RHS = Türkontakt
HM-Sec-SC-2 =
HM-SEC-SC =
HM-CC-RT-DN = RT = HeizungsThermostat
PEERING
- soll man nun TC nun mit RT UND mit RHS peeren?
- soll man RHS nur mit TC peeren?
- soll man nur RHS und TC peeren?
- Was ist jetzt mit dem burstXmit Setting? Ist das nun nötig zu disablen um die Meldungen v
ZEITPROFILE
- werden die nun NUR in den RT´s gesetzt?
- werden die in RT und in TC gesetzt?
- werden die nur in den TC´s gesetzt?
KNOWN ISSUES
- Ist es bestätigt dass der TC nicht sofort die Desired Temp an den DN sendet, bzw. dieser diese nicht sofort annimmt?
Wenn ja, ist dafür eine Lösung in Sicht?
- hängt das mit dem burstXmit zusammen?
BURSTXMIT
...auch wenn es auf die Batterielaufzeit geht...
- ist es ratsam bei den RT´s UND beim TC UND beim RHS den burstXmit zu setzen?
- wo setze ich den am geschicktesten?
COMMANDREF
- ist beim peeren mit dem TC nun der richtige Befehl der mit "single" oder der mit "single set" ?
ANFORDERUNG (meine jedenfalls)
- die Temp am HM-TC-IT-WM-W-EU manuell einzustellen wenn mir danach ist, und die beiden DN´s reagieren sofort darauf.
- Aber es sollen auch die Zeitprofile ziehen. Schließlich kann ich ja auch mal kurz auf 26 Grad gestellt haben und dann vergesse ich es und dann bollert die HZG weiter. Da soll dann das Zeitprofil seinen Dienst tun und es zur eingestellten Zeit wieder runter drehen.
- Wenn zu irgendeiner Zeit (egal ob manuell eingestellt oder Zeitprofil) die Tür auf geht, soll nach 5 Minuten auf z.B. 16 Grad gestellt werden. Und wenn die Tür wieder länger als 5 Minuten zu, dann wieder auf vorherige oder zeitgesteuerte Temp. zurückstellen.
Danke Euch
Gruß
der Merlin
Hallo zusammen,
auch wenn das Thema hier schon länger tot liegt, so habe ich mich erst kürzlich damit befasst. Da ich erst jetzt die HM-SEC-RHS einsetze.
Um meinen Senf zu Delay/Filter beizutragen:
Die Funktion ist meiner Meinung nach ganz klar ein Filter, denn es werden alle ungewünschten Events gefiltert.
Die Katze finde ich ein unglückliches Beispiel. Wenn ich die Katze rauslassen will dann ist mein gewünschtes Event eigentlich: closed, bzw. gar keins. Da ich nicht will das die Heizung auf ein solch kurzes Event reagiert. Dennoch sendet der RHS zumindest ein Event: closed.
Wenn ich nun aber das Öffnen eines Fensters auf Kipp betrachte, sieht die Situation anders aus. Mein gewünschtes Event: tilted. Die Information, dass ich vorher aber den Status open hatte interessiert mich nicht. Auch wenn ich ein unentschlossener Mensch bin und mich zwei Mal um entscheide ob ich das Fenster nun ganz öffnen möchte oder nur kippen, ist der Heizung egal. Also lasse ich sie weg oder anders gesagt: Ich filtere die unerwünschten Events.
Ein Delay (zu Deutsch: die Verzögerung) macht genau das was der Name sagt. Verzögern. Stelle ich nun ein Delay von 5 Sekunden ein, kommen alle Events einfach 5 Sekunden verzögert.
Just my 2 cents.
Nun aber zum Peeren:
Ich habe den RHS mit TC UND RT gepeert.
Mir ist aufgefallen das wenn ich den RHS nur mit dem TC peere, der TC keinen Burst an den RT sendet. Laut config (im FHEM und allen Devices) ist eigentlich alles richtig eingestellt. Dennoch sendet der TC die Daten erst bei der normalen Abfrage des RT. Warum ist mir ein Rätsel, da eine Temperaturänderung am TC sofort an den RT geht.
Etwa eine Woche läuft das ganze nun schon und ich kann keine Unstimmigkeiten feststellen können.
Meine Empfehlung:
Erst nur den RHS und den TC peeren und alles in Ruhe testen. Sollte einem dann die Reaktionsgeschwindigkeit des RT zu langsam sein, dann auch den RT peeren.
LG,
EssKaa