Drehgriffsensor soll Wandthermosthat steuern

Bennemannc · 13 Januar 2016, 18:25:51

Hallo,

es gibt zwei Informationen. Zum eine Fenster auf / zu und zum anderen die Temperatur die bei open eingestellt wird. Ich würde die Temperatur mit regSet direkt am Gerät (Heizkörperthermostat) einstellen.
Die von Dir beschriebene Variante setzt die Temperatur nur für diese eine Fenster.
Wenn Fenster zu vom Kontakt kommt, sollte das Thermostat automatich wieder auf den "alten" Wert und Modus (Auto/Manu/...) gehen.

Gruß Christoph

DerFrickler · 13 Januar 2016, 20:23:07

Hallo,

das mit dem Absenken der Temperatur klappt wunderbar, der Rest leider nicht ganz so.

Den Fenster-Drehgriffkontakt habe ich wie jedes andere HM Device angelernt. Das funktionierte relativ schnell und unkompliziert, die korrekten Stati (open, tilted und closed) werden auch gemäß Drehgriffposition übermittelt.

Das Wandthermostat (HM-TC-IT-WM-W-EU) ist mit dem Heizungsregler (HM-CC-RT-DN) gepeert, sowohl über den Weather- als auch über den Climate-Kanal. Im Grunde dient das Wandthermostat nur der zusätzlichen Messung der Luftfeuchte (da Kellerraum), ist aber auch ganz praktisch da etwas höher montiert nicht in Reichweite von Kinderhänden. Deshalb auch das Peering.

Da die Motivation das Kellerfenster auch in sehr kalten Winternächten zu schliessen nicht immer bei allen anwesenden gleich hoch ist, habe ich mir den Fenster-Drehgriffkontakt zugelegt und nach (zumindest aus meiner Sicht) erfolgreichen Inbetriebnahme gemäß Wiki Eintrag "HM-TC-IT-WM-W-EU Funk-Wandthermostat AP" über den WindowRec Kanal gepeert.

dabei habe ich folgende Anweisungen aus dem Wiki genutzt:

set <HM-Sec-SC> peerChan 0 <HM-TC-IT-WM-W-EU-Gerät>_WindowRec single set
set <tc_WindowRec> regSet winOpnTemp <Temp> <fensterSensor>

Beim Öffnen des Fensters wird die desired-temp auf 10 °C herunter geregelt, was dann auch schnell bis zum Heizungsregler durchgereicht wird. Es wird auch ein Fenster-Symbol im Display des Wandthermostates angezeigt. Ob dieses schon vorher da war kann ich jetzt nicht sagen, zumindest ist das Symbol im Display nach schliessen des Fensters immer noch da. Die desired-temp im Wandthermostat sowie im Heizungsregler sind beide immer noch auf 10 °C (winOpnTemp).

Hier der Fenster-Drehgriffkontakt:

Code Auswählen

Internals: 
   CFGFN 
   CUL1_MSGCNT 59 
   CUL1_RAWMSG A0C4EA641345322FAFAFA014D00::-66:CUL1 
   CUL1_RSSI  -66 
   CUL1_TIME  2016-01-13 17:10:25 
   DEF        345322 
   IODev      CUL1 
   LASTInputDev CUL1 
   MSGCNT     59 
   NAME       window.sensor.Wohnkeller 
   NR         175 
   NTFY_ORDER 50-window.sensor.Wohnkeller 
   STATE      closed 
   TYPE       CUL_HM 
   lastMsg    No:4E - t:41 s:345322 d:FAFAFA 014D00 
   protCmdDel 20 
   protLastRcv 2016-01-13 17:10:25 
   protResndFail 4 last_at:2016-01-13 16:48:13 
   protSnd    60 last_at:2016-01-13 17:10:25 
   protState  CMDs_done 
   rssi_at_CUL1 avg:-69.99 min:-79 max:-63 lst:-66 cnt:59 
   CHANGETIME: 
   Helper: 
     Dblog: 
       Activity: 
         Dblog: 
           TIME       1452683328.86567 
           VALUE      alive 
       Rawmsg: 
         Dblog: 
           TIME       1452701425.7996 
           VALUE      A0C4EA641345322FAFAFA014D00::-66:CUL1 
       Rssi: 
         Dblog: 
           TIME       1452701425.7996 
           VALUE      -66 
       Battery: 
         Dblog: 
           TIME       1452701425.7996 
           VALUE      ok 
       Contact: 
         Dblog: 
           TIME       1452701425.7996 
           VALUE      closed (to CUL1) 
       State: 
         Dblog: 
           TIME       1452712127.85017 
           VALUE      closed 
       Trigdst_fafafa: 
         Dblog: 
           TIME       1452701425.7996 
           VALUE      noConfig 
       Trigger_cnt: 
         Dblog: 
           TIME       1452701425.7996 
           VALUE      77 
   Readings: 
     2016-01-13 12:08:48   Activity        alive 
     2016-01-13 11:05:48   CommandAccepted yes 
     2016-01-13 11:05:47   D-firmware      2.4 
     2016-01-13 11:05:47   D-serialNr      LEQ1251278 
     2016-01-13 11:05:47   R-pairCentral   set_0xFAFAFA 
     2016-01-13 11:57:23   R-wall.thermostat.Wohnkeller_WindowRec-expectAES set_off 
     2016-01-13 11:57:23   R-wall.thermostat.Wohnkeller_WindowRec-peerNeedsBurst set_on 
     2016-01-13 11:06:17   alive           yes 
     2016-01-13 17:10:25   battery         ok 
     2016-01-13 17:10:25   contact         closed (to CUL1) 
     2016-01-13 11:06:17   cover           closed 
     2016-01-13 11:06:17   recentStateType info 
     2016-01-13 17:10:25   state           closed 
     2016-01-13 17:10:25   trigDst_FAFAFA  noConfig 
     2016-01-13 17:10:25   trigger_cnt     77 
     Regl_00.: 
       VAL 
   Helper: 
     HM_CMDNR   78 
     cSnd       01FAFAFA345322010135B6D20300,01FAFAFA34532200040000000000 
     getCfgList all 
     getCfgListNo ,4 
     mId        0030 
     rxType     4 
     Expert: 
       def        1 
       det        1 
       raw        1 
       tpl        0 
     Io: 
       newChn     +345322,00,00,00 
       nextSend   1452701425.78282 
       prefIO 
       rxt        0 
       vccu 
       p: 
         345322 
         00 
         00 
         00 
     Mrssi: 
       mNo        4E 
       Io: 
         CUL1       -64 
     Prt: 
       bErr       0 
       sProc      0 
       Rspwait: 
     Q: 
       qReqConf 
       qReqStat 
     Role: 
       chn        1 
       dev        1 
     Rpt: 
       IO         CUL1 
       flg        A 
       ts         1452701425.68734 
       ack: 
         HASH(0x2ba00f0) 
         4E8002FAFAFA34532200 
     Rssi: 
       At_cul1: 
         avg        -70 
         cnt        59 
         lst        -66 
         max        -63 
         min        -79 
     Shadowreg: 
       RegL_04.wall.thermostat.Wohnkeller_WindowRec  01:01 
Attributes: 
   DbLogInclude CUL1_RSSI,state 
   IODev      CUL1 
   actCycle   028:00 
   actStatus  alive 
   alias      Fenstersensor (rechts) - Wohnkeller 
   autoReadReg 4_reqStatus 
   devStateIcon open:fts_window_2w_open_r@red closed:fts_window_2w@green tilted:fts_window_2w_tilt_r@yellow 
   expert     3_allReg+raw 
   firmware   2.4 
   group      Fenstersensor - Geräte 
   icon       fts_window_2w 
   model      HM-SEC-RHS 
   room       Fenster/Türen 
   subType    threeStateSensor

interessant könnten hier folgende Zeilen sein:

2016-01-13 11:57:23 R-wall.thermostat.Wohnkeller_WindowRec-expectAES set_off
2016-01-13 11:57:23 R-wall.thermostat.Wohnkeller_WindowRec-peerNeedsBurst set_on

Das Wandthermostat:

Code Auswählen

Internals: 
   CFGFN 
   DEF        35B6D203 
   NAME       wall.thermostat.Wohnkeller_WindowRec 
   NR         39 
   NTFY_ORDER 50-wall.thermostat.Wohnkeller_WindowRec 
   STATE      last:trigLast 
   TYPE       CUL_HM 
   chanNo     03 
   device     wall.thermostat.Wohnkeller 
   peerList   window.sensor.Wohnkeller, 
   CHANGETIME: 
   Readings: 
     2015-10-07 22:32:48   R-sign          off 
     2016-01-13 17:30:09   R-window.sensor.Wohnkeller_chn-01-shCtValLo 50 
     2016-01-13 17:30:09   R-window.sensor.Wohnkeller_chn-01-winOpnTemp 10 C 
     2016-01-13 17:30:07   RegL_01.          08:00 00:00 
     2016-01-13 17:30:09   RegL_03.window.sensor.Wohnkeller_chn-01   04:32 00:00 
     2016-01-13 17:30:09   RegL_07.window.sensor.Wohnkeller_chn-01   05:14 00:00 
     2016-01-13 17:30:07   peerList        window.sensor.Wohnkeller, 
     2016-01-13 17:30:07   state           unknown 
   Helper: 
     peerIDsRaw ,34532201,00000000 
     Expert: 
       def        1 
       det        1 
       raw        1 
       tpl        0 
     Role: 
       chn        1 
     Shadowreg: 
Attributes: 
   DbLogExclude .* 
   event-on-change-reading .* 
   model      HM-TC-IT-WM-W-EU 
   peerIDs    00000000,34532201, 
   room       hidden 
   stateFormat last:trigLast

interessant sicherlich auch folgende Zeile:

2016-01-13 17:30:07 state unknown

dann noch das HMInfo:

Code Auswählen

configCheck done:

 missing register list
    window.sensor.Wohnkeller:	RegL_00.,RegL_01.

 Register changes pending
    window.sensor.Wohnkeller

 peer list incomplete. Use getConfig to read it.
    incomplete: window.sensor.Wohnkeller:

 peer not verified. Check that peer is set on both sides
    wall.thermostat.Wohnkeller_WindowRec p:window.sensor.Wohnkeller

 peering strange - likely not suitable
    smokeDetector.Vorkeller not peered!! add SD to any team !!

 trigger sent to undefined device
    triggerUndefined: window.sensor.Wohnkeller:FAFAFA

wenn jetzt dann noch jemand eine Idee hätte...

Danke!

Muschelpuster · 13 Januar 2016, 22:17:52

Zitat von: DerFrickler am 13 Januar 2016, 17:24:38
...nur kann man diese auch beim schliessen des Fensters anheben, bzw. zurück auf den Wert der Zeitsteuerung setzen?

Wenn die Absenkung funktioniert sollte der Rückweg eigentlich von alleine funktionieren.

automatische Grüße
Niels

DerFrickler · 13 Januar 2016, 23:11:25

Zitat von: Muschelpuster am 13 Januar 2016, 22:17:52
Wenn die Absenkung funktioniert sollte der Rückweg eigentlich von alleine funktionieren.

Der Auto-Modus bleibt erhalten, somit wird der abgesenkte Wert erst mit dem nächsten Schaltzyklus geändert und ist damit zurück auf dem Wert aus dem Temperaturprogramm.

Mittwoch: 06:00 16.0 12:00 19.0 14:00 16.0 22:00 19.0 24:00 16.0

1. Fenster auf, Temperatur von 19°C auf 10°C
2. 22:00 gemäß Programm Umschaltung der desired-temp auf 16°C
3. 22:36 die Frau öffnet (bz. kippt) das Fenster und die desired-temp geht zurück auf 10°C
4. 22:56 die Frau schliesst das Fenster und die desired-temp bleibt auf 10°C

ich gehe mal davon aus dass gemäß Programm um 24:00 die desired-temp auf 16°C umgestellt wird.

d.h., wenn ich hier nicht manuell eingreife wird das vor dem nächsten Schaltvorgang nichts

frank · 14 Januar 2016, 00:52:36

hast du die hminfo fehler mal abgearbeitet?

Muschelpuster · 14 Januar 2016, 10:05:00

Also was ich in diesem ganzen Prozess schmerzhaft gelernt habe ist der Fakt, dass die HM-Geräte ja nicht unbedingt die Programmierung gefressen haben, nur weil ich die Programmierung vorgenommen habe. Es sollten auf jeden Fall in den Internals unter protCmdPend keine Befehle mehr auf ihre Ausführung warten und unter protState
sollte CMDs_done stehen. Das kann man z.T. durch set burstXmit erreichen und z.T. durch Auslösen der Konfig-Funktion am Gerät. Wenn das alles nichts hilft, dann kommt ein set clear msgEvents zum Einsatz - gefolgt von einem set getConfig. Wenn dann der Status CMDs_done ist, dann sieht man, was das Gerät wirklich gefressen hat und kann die fehlenden Settings erneut übermitteln. Aber nicht zu viel in einem Rutsch - immer schon häppchenweise und auf die Abarbeitung der Kommandos warten bzw. diese anstoßen.

gemächliche Grüße
Niels

DerFrickler · 14 Januar 2016, 13:12:51

Zitat von: frank am 14 Januar 2016, 00:52:36
hast du die hminfo fehler mal abgearbeitet?

Nein, dazu könnte ich etwas Hilfe gebrauchen. Es erscheint mir aber auch als ob die Problematik mit der Nicht-Abarbeitung der CMDs zusammen hängen könnte.

Zitat von: Muschelpuster am 14 Januar 2016, 10:05:00
Es sollten auf jeden Fall in den Internals unter protCmdPend keine Befehle mehr auf ihre Ausführung warten und unter protState
sollte CMDs_done stehen.

Das ist aktuell der Fall, nur muss ich zugeben dass es auch Time-Outs während der Programmierung gab. Nach einem grundsätzlichen Anlernen mache ich im allgemeinen die weitere Programmierung vom Arbeitszimmer aus. Dazwischen befinden sich dann 2 Etagen. Bisher hatte ich die Situation noch nicht dass ich zur Abarbeitung der CMDs ständig das Device bedienen musste.

Zitat von: Muschelpuster am 14 Januar 2016, 10:05:00
Das kann man z.T. durch set burstXmit erreichen und z.T. durch Auslösen der Konfig-Funktion am Gerät. Wenn das alles nichts hilft, dann kommt ein set clear msgEvents zum Einsatz - gefolgt von einem set getConfig. Wenn dann der Status CMDs_done ist, dann sieht man, was das Gerät wirklich gefressen hat und kann die fehlenden Settings erneut übermitteln. Aber nicht zu viel in einem Rutsch - immer schon häppchenweise und auf die Abarbeitung der Kommandos warten bzw. diese anstoßen.

Demnach würde ein "set window.sensor.Wohnkeller burstXmit" das Drehen am Fenstergriff ersetzen? Das muss dann nach jedem CMD der Programmierung gemacht werden?
Reicht es die Programmierung
1. Das peeren
set window.sensor.Wohnkeller peerChan 0 wall.thermostat.Wohnkeller_WindowRec single set
2. Das Absenken der Temperatur
set wall.thermostat.Wohnkeller_WindowRec regSet winOpnTemp 10 window.sensor.Wohnkeller
jeweils gefolgt von einem set window.sensor.Wohnkeller burstXmit bzw. set wall.thermostat.Wohnkeller burstXmit
zu überschreiben? Oder ist es besser die bestehende Programmierung vorher rückgängig zu machen?

Gruß und Danke!

-----------------------------------------------------------------
Edit:

dann sind da noch folgende Einträge beim Fenster Sensor:

2016-01-13 11:05:47 R-pairCentral set_0xFAFAFA
2016-01-13 11:57:23 R-wall.thermostat.Wohnkeller_WindowRec-expectAES set_off
2016-01-13 11:57:23 R-wall.thermostat.Wohnkeller_WindowRec-peerNeedsBurst set_on

Ich habe mal im Forum danach gesucht...
zu R-pairCentral:
fehlt hier noch ein "set <FensterkontaktName> regSet pairCentral <hmId>"? bevor ich das peering mit dem Wandthermostat durchführe?

frank · 14 Januar 2016, 13:33:02

ZitatBisher hatte ich die Situation noch nicht dass ich zur Abarbeitung der CMDs ständig das Device bedienen musste.

der rhs muss immer "bedient" werden. der kann nur configmode (taste drücken), auch kein burst. sonst schläft der halt.
regelmässig aufwachende batterie-devices können meist auch wakeupmode. mit geduld ist irgendwann alles abgearbeitet.
burst muss man, sofern es das überhaupt gibt, meistens erst im device freischalten.

mit get hminfo models sieht man, was jedes model kann.

DerFrickler · 14 Januar 2016, 13:46:08

laut Wiki ist das Pairing nicht korrekt abgeschlossen worden:

Code Auswählen

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

Ich denke mal ich werde mich zuerst mal damit beschäftigen.

Edit:
Habe ich durch ein erneutes Pairing gelöst. Laut ConfigCheck verbleiben noch:

Code Auswählen

peer not verified. Check that peer is set on both sides
    wall.thermostat.Wohnkeller_WindowRec p:window.sensor.Wohnkeller

 peering strange - likely not suitable
    smokeDetector.Vorkeller not peered!! add SD to any team !!

 trigger sent to undefined device
    triggerUndefined: window.sensor.Wohnkeller:FAFAFA

Edit2:

mit "set window.sensor.Wohnkeller peerChan 0 wall.thermostat.Wohnkeller_WindowRec single set" erscheint..

1. im Kanal wall.thermostat.Wohnkeller_WindowRec peerList mit window.sensor.Wohnkeller und peerIDs mit 00000000,34532201

2. im window.sensor.Wohnkeller peerChan überhaupt nicht und peerIDs mit 00000000

jetzt stelle ich mal eine Vermutung auf:
ConfigCheck ergibt:
Register changes pending
window.sensor.Wohnkeller

möglicherweise bezieht sich das auf:
2016-01-13 11:57:23 R-wall.thermostat.Wohnkeller_WindowRec-expectAES set_off
2016-01-13 11:57:23 R-wall.thermostat.Wohnkeller_WindowRec-peerNeedsBurst set_on

und diese Register changes müssen erst durchgeführt werden um die peering Problematik zu lösen?

Eine weitere Beobachtung die ich gemacht habe ist folgende:
mache ich für den Fenstersensor ein getConfig, verschwinden die Register RegL_00. und RegL_01.
Beide erscheinen erst wieder wenn ich ein erneutes Pairing durchführe.

missing register list
window.sensor.Wohnkeller: RegL_00.,RegL_01.

Hat jemand eine Idee wie hier am besten vorzugehen ist?

Danke!

frank · 14 Januar 2016, 18:31:42

Zitat1. im Kanal wall.thermostat.Wohnkeller_WindowRec peerList mit window.sensor.Wohnkeller und peerIDs mit 00000000,34532201

ok

Zitat2. im window.sensor.Wohnkeller peerChan überhaupt nicht und peerIDs mit 00000000

jetzt stelle ich mal eine Vermutung auf:
ConfigCheck ergibt:
Register changes pending
window.sensor.Wohnkeller

du musst natürlich weiterhin auf den taster am fk drücken, wie bereits gesagt, sonst kann er das peering nicht abarbeiten. bei jedem pending bis cmds_done. wenn done_error, dann befehl wiederholen.

ZitatEine weitere Beobachtung die ich gemacht habe ist folgende:
mache ich für den Fenstersensor ein getConfig, verschwinden die Register RegL_00. und RegL_01.
Beide erscheinen erst wieder wenn ich ein erneutes Pairing durchführe.

auch hier taster drücken, nicht neu pairen, wenn das pairing bereits ok war.

DerFrickler · 14 Januar 2016, 19:17:21

Zitat von: frank am 14 Januar 2016, 18:31:42
ok

du musst natürlich weiterhin auf den taster am fk drücken, wie bereits gesagt, sonst kann er das peering nicht abarbeiten. bei jedem pending bis cmds_done. wenn done_error, dann befehl wiederholen.

Ich denke mit Taster drücken meinst Du den Fenstergriff bewegen. Das habe ich gemacht, mit der linken Hand am Laptop und der rechten am Griff; sowohl das Wandthermostat als auch der Fenstersensor zeigen beide CMDs_done. Leider ohne Erfolg, im Fenstersensor fehlt immer noch das Wandthermostat in der Peer-Liste.

Gruß!

martinp876 · 14 Januar 2016, 19:44:06

Das Kommando zum peeren absetzen und config drücken.
Config lesen und config drücken

Muschelpuster · 14 Januar 2016, 19:55:08

ich will diese Frage nochmal in die Runde werfen:

Zitat von: Muschelpuster am 09 Dezember 2015, 23:44:38Ist der Pairing-Weg überhaupt sinnvoll, oder macht es mehr Sinn, das Pairing zwischen Türsensor und Ventil durchzuführen, damit dann das Ventil den Wandthermostaten darüber informiert.

Anders herum wäre es doch zügiger: Der Sensor informiert das Ventil, welches runter fährt und den Wandthermostat informiert? Zumindest wenn man nur ein Ventil hat...
Oder kann man auch beide Geräte pairen?

nachgehakte Grüße
Niels

martinp876 · 14 Januar 2016, 20:07:12

Wieso sollte das ventil das wandthermostat informieren?
Peere einfach beide mit dem rhs

DerFrickler · 14 Januar 2016, 20:15:56

Zitat von: martinp876 am 14 Januar 2016, 19:44:06
Das Kommando zum peeren absetzen und config drücken.
Config lesen und config drücken

Was meinst Du mit Config drücken? Am Fenster-Drehgriffkontakt befindet sich lediglich eine Anlerntaste. Ansonsten ist da noch die Möglichkeit den Fenstergriff zu drehen um das Abarbeiten der CMDs zu handhaben. Das habe ich auch so gemacht.

Zu der Sache mit dem "R-wall.thermostat.Wohnkeller_WindowRec-peerNeedsBurst set_on" kann ich das beim HM-SEC-RHS genauso wie beim HM-SEC-SC bewerkstelligen=

set <HM-SEC-SC> regSet peerNeedsBurst on <RT_oder_TC>_WindowRec

Gruß!

Edit:
laut wiki Eintrag "HomeMatic Type ThreeState":

Bei HM-SEC-SC und HM-SEC-RHS z.B. kann man die Register nur beschreiben, indem der Anlernknopf im Batteriefach gedrückt wird.