HM-CC-RT-DN

geek · 21 März 2014, 20:14:58

Ohne eventMap gehts. Danke fürs Augen öffnen.

Mit fortschreitender Nutzung verstehe ich immer weniger wie die eventMap tickt. Aber das ist keine HM Thema also OT

andrejs · 15 Juni 2014, 12:19:49

Dear all!

I few days ago I bought 1x Homematic wireless radiator Thermostat HM-CC-RT-DN. I managed to install it and connected (paired) to Fhem server (runs on linux) through USB Stick (HM-CFG-USB USB-2). In fhem.cfg file I used the following definition:
define hmusb HMLAN 127.0.0.1:1234
attr hmusb hmId F11234
define spalnica_radiator CUL_HM 2553BA

The system without any problems read the data every 2 to 3 minutes but the problem is that I am not able to control the thermostat. I tried to change the following:
set spalnica_radiator_Clima controlMode day
set spalnica_radiator_Clima controlManu 30.0
set spalnica_radiator_Clima contolMode day
set spalnica_radiator_Clima desired-temp 15.0

Unfortunately nothing has changed on thermostat. What I doing wrong?

I am attaching to this message the log file and the definitions of HMUSB + Thermostat device (CUL_HM).

Mr. P · 15 Juni 2014, 12:36:22

Hej andrejs,

at first sight it seems, you don't have paired your RT.
Possibly autocreate has created the device in FHEM (so you can see some information) but the device doesn't know anything from FHEM.

So try to open your console, enter:
set hmusb hmPairForSec 60
This command activate the pairing mode in FHEM for 60 seconds.
So go to your RT, press and hold the middle button for some moments. A backward counter starting with 30 should appear and disappear some moments later (after successful pairing).
When this happens, you have paired FHEM with your RT.
After that enter:
set spalnica_radiator getConfig
in your Console and wait some minutes (because the RT wakes up only approximately every 2.5 minutes).
After that you should see a line in your RT device section like
2014-05-10 23:29:40 R-pairCentral 0xF11234
This line (and only this line) tells you, that the RT reported the correct pairing to your FHEM.

andrejs · 15 Juni 2014, 16:26:10

Thanks Mr.P for your help. It works!!!!

Mr. P · 15 Juni 2014, 19:13:17

You're welcome!

geek · 16 Juli 2014, 19:56:33

Hi,

Situation:

Aus verschiedenen Gründen betreibe ich meine RT-DN im manual mode - leider vergessen die das aber gelegentlich Also habe ich nen Job laufen, der alle 15min prüft, ob sie sich auf auto geschaltet haben (was meißt mit einer Änderung der desired-temp einhergeht) und ihnen mittels "set $name controlManu $temp" wieder den richtigen mode + temp gibt. Das gleiche passiert mir übrigens bei den TC-IT. Kommt nicht vom fhem und ist laut raw log auch kein "Freund".

Soweit egal - nur als Hintergrund, mein "Problem":

Seit einem der letzten updates sehe ich aber in dem Reading "mode" nur noch "set_manual". Früher war da der aktuelle mode drin. Habe ich jetzt umgebaut auf "controlMode" - aber der verwaiste "mode" irritiert mich jedes mal. Ist das Absicht?

Rainer

Mr. P · 17 Juli 2014, 00:50:23

Hej Rainer,

Zitat von: geek am 16 Juli 2014, 19:56:33
Seit einem der letzten updates sehe ich aber in dem Reading "mode" nur noch "set_manual". Früher war da der aktuelle mode drin. Habe ich jetzt umgebaut auf "controlMode" - aber der verwaiste "mode" irritiert mich jedes mal. Ist das Absicht?

Hab es mir gerade angesehen. Bin mir recht sicher, dass es so nicht geplant war. Aber da müssen wir wohl auf ein Feedback von Martin warten.

Zitat von: geek am 16 Juli 2014, 19:56:33
Aus verschiedenen Gründen betreibe ich meine RT-DN im manual mode - leider vergessen die das aber gelegentlich Also habe ich nen Job laufen, der alle 15min prüft, ob sie sich auf auto geschaltet haben (was meißt mit einer Änderung der desired-temp einhergeht) und ihnen mittels "set $name controlManu $temp" wieder den richtigen mode + temp gibt. Das gleiche passiert mir übrigens bei den TC-IT. Kommt nicht vom fhem und ist laut raw log auch kein "Freund".

Wenn das von dir gemeldete auch sicher geregelt gehört, würde ich in deinem Fall dennoch aufhören, mich um einen Workaround zu kümmern und stattdessen eher die Ursache ausfindig machen.
Scheinen in deiner FHEM-Installation fremde Geräte auf? Klingt ja beinahe so, als hättest du einen Nachbarn, der dir in die Quere kommt.
Prüfe, ob außer von deinen Geräten noch andere "herumschwirren", ändere einmal deine HMID und wenn alles nichts hilft, würde ich mir doch überlegen, AES zu aktivieren. Es gibt auch irgendwie in FHEM die Möglichkeit zu kontrollieren, ob dein FHEM-Server Daten von Eindringlingen (anderen FHEM-Servern mit der selben HMID) empfängt. Musst du im Forum nachsehen, wie das klappt.

Deudi · 17 Juli 2014, 07:44:28

Zitat von: geek am 16 Juli 2014, 19:56:33
Seit einem der letzten updates sehe ich aber in dem Reading "mode" nur noch "set_manual". Früher war da der aktuelle mode drin. Habe ich jetzt umgebaut auf "controlMode"...

Wann war das letzte Update denn? Die Steuerung war zwischenzeitlich bzgl. Manual etwas derangiert.
Das findest du hier:
http://forum.fhem.de/index.php/topic,24880.msg182270.html#msg182270
Mach mal ein Update. Vielleicht ist es ja schon wieder gut...

geek · 17 Juli 2014, 08:50:22

Zitat von: Mr. P am 17 Juli 2014, 00:50:23
Hab es mir gerade angesehen. Bin mir recht sicher, dass es so nicht geplant war. Aber da müssen wir wohl auf ein Feedback von Martin warten.

ja, genau das war meine Idee.

Zitat von: Mr. P am 17 Juli 2014, 00:50:23
Wenn das von dir gemeldete auch sicher geregelt gehört, würde ich in deinem Fall dennoch aufhören, mich um einen Workaround zu kümmern und stattdessen eher die Ursache ausfindig machen.

Ich halte das für einen Firmware bug. Habe den HM Traffic ne Weile Raw mitgeschnitten und da ist nix. Weder von Fhem noch von Fremden. Attack detection schlägt auch nicht zu. Window open detection ist auch aus (soll laut changelog vor 1.2 Probleme damit gegeben haben).

Zitat von: Deudi am 17 Juli 2014, 07:44:28
Wann war das letzte Update denn? Die Steuerung war zwischenzeitlich bzgl. Manual etwas derangiert.
Das findest du hier:
http://forum.fhem.de/index.php/topic,24880.msg182270.html#msg182270
Mach mal ein Update. Vielleicht ist es ja schon wieder gut...

Vor meinen letzten updates in den letzten Tagen lief die Installation länger ohne Änderungen. Der Thread könnte also was damit zu tun haben.

Das letzte update war gestern, bevor ich geposted habe.

Rainer

Mr. P · 17 Juli 2014, 11:20:41

Zitat von: geek am 17 Juli 2014, 08:50:22
Ich halte das für einen Firmware bug. Habe den HM Traffic ne Weile Raw mitgeschnitten und da ist nix. Weder von Fhem noch von Fremden. Attack detection schlägt auch nicht zu. Window open detection ist auch aus (soll laut changelog vor 1.2 Probleme damit gegeben haben).

Wäre es ein Firmwarebug, dann müssten aber alle RTs von allen davon betroffen sein. Da ich aber sonst niemanden mit dem Problem kenne, halte ich das für sehr unwahrscheinlich.

Könntest du rein Interesse halber einmal das Logging für einen deiner RTs aufdrehen und nach besagten umschalten das Log gemeinsam mit einem Listing von deinem RT (Device + Channels) einmal posten? Würde trotz allem gerne einmal einen Blick darauf machen.

peterk_de · 17 Juli 2014, 12:08:51

Also meine Laufen seit Anfang des Sommers im Manual-mode und schalten sich nicht allein nach Auto. Firmware 1.2. Das einzige, was ich mir spontan noch vorstellen könnte, ist dass jemand ausversehen auf die linke Taste kommt. Bei uns passierte das ab und an mal - durch unsere Katze, die es sich auf der Heizung bequem gemacht hat. Bei ihren Lieblingsheizkörpern hab ich deshalb nun die Tastensperre gesetzt

reibuehl · 17 Juli 2014, 13:52:19

Abstauben und abwischen führt bei mir zuhause immer wieder zu solchen Effekten

Deudi · 17 Juli 2014, 16:55:54

Deswegen habe ich generell auch die globale Tastensperre drin

geek · 18 Juli 2014, 08:04:31

Hi,

Tastensperre hatte ich auch ne weile drin - ohne Veränderung.

Meine RT-DN haben erst vor ner Woche die 1.2 firmware bekommen. Habe das raw logging (für Mr. P) erst wieder seit gestern an. Die RT-DN haben bisher noch nicht wieder selbstständig umgeschaltet. Raw log kommt, sobald das wieder aufgetreten ist.

Das log zeigt aber, das nach einem "set xx controlManu yy" der RT-DN beim nächsten update oft controlMode=auto meldet.

Die TC-IT zeigen übrigens die gleichen Symptome.

set:

Code Auswählen

2014.07.17 22:06:45.268 3: CUL_HM set eg_of_heiz_climrt controlManu on
2014.07.17 22:07:00.148 0: HMLAN_Parse: HMEG R:E2217DC   stat:0000 t:1154BBB5 d:FF r:FFCE     m:4D 8610 2217DC 000000 0A90F10E0022
2014.07.17 22:07:00.244 0: HMLAN_Send:  HMEG S:S45EF5C7C stat:  00 t:00000000 d:01 r:45EF5C7C m:75 A112 83D2E0 2217DC 
2014.07.17 22:07:00.263 0: HMLAN_Parse: HMUG R:E2217DC   stat:0000 t:02D7C7FF d:FF r:FFA2     m:4D 8610 2217DC 000000 0A90F10E0022
2014.07.17 22:07:00.273 0: HMLAN_Parse: HMUG R:E83D2E0   stat:0000 t:02D7C87A d:FF r:FF9C     m:75 A112 83D2E0 2217DC 
2014.07.17 22:07:00.401 0: HMLAN_Parse: HMEG R:R45EF5C7C stat:0001 t:1154BCB7 d:FF r:FFCD     m:75 8002 2217DC 83D2E0 00
2014.07.17 22:07:00.502 0: HMLAN_Send:  HMEG S:+2217DC,02,01,00
2014.07.17 22:07:00.502 0: HMLAN_Send:  HMEG S:S45EF5D7A stat:  00 t:00000000 d:01 r:45EF5D7A m:76 A011 83D2E0 2217DC 81043D
2014.07.17 22:07:00.504 0: HMLAN_Parse: HMUG R:E2217DC   stat:0000 t:02D7C8FC d:FF r:FF9C     m:75 8002 2217DC 83D2E0 00
2014.07.17 22:07:00.679 0: HMLAN_Parse: HMUG R:E83D2E0   stat:0000 t:02D7CA10 d:FF r:FF9A     m:76 A011 83D2E0 2217DC 81043D
2014.07.17 22:07:00.808 0: HMLAN_Parse: HMEG R:R45EF5D7A stat:0001 t:1154BE4E d:FF r:FFD0     m:76 8002 2217DC 83D2E0 01043D103262
2014.07.17 22:07:00.823 0: HMLAN_Parse: HMUG R:E2217DC   stat:0000 t:02D7CA93 d:FF r:FFA3     m:76 8002 2217DC 83D2E0 01043D103262

und der periodische job findet dann beim nächsten lauf controlMode=auto.

Code Auswählen

2014.07.17 22:08:30.777 3: heizkoerper_manual eg_of_heiz_climrt: auto
2014.07.17 22:08:30.786 3: CUL_HM set eg_of_heiz_climrt controlManu on

list des obigen RT-DN:

Code Auswählen

list eg_of_heiz_climrt
Internals:
   CFGFN      ./cfg/eg_of.cfg
   DEF        2217DC04
   NAME       eg_of_heiz_climrt
   NR         828
   STATE      T: 24.0 desired: on valve: 100
   TYPE       CUL_HM
   chanNo     04
   device     eg_of_heiz
   Readings:
     2014-07-18 07:51:59   CommandAccepted yes
     2013-12-24 12:42:49   R-boostPeriod   5 min
     2014-01-26 20:15:37   R-boostPos      100 %
     2014-07-14 15:11:18   R-btnNoBckLight off
     2013-12-25 09:49:49   R-dayTemp       22 C
     2014-07-14 15:11:18   R-daylightSaveTime on
     2014-07-14 15:11:18   R-decalcTime    11:00
     2014-07-14 15:11:18   R-decalcWeekday Sat
     2014-07-14 15:11:18   R-modePrioManu  all
     2014-07-14 15:11:18   R-modePrioParty all
     2013-12-24 12:48:31   R-nightTemp     18 C
     2014-07-14 15:11:18   R-noMinMax4Manu off
     2014-07-14 15:11:18   R-regAdaptive   on
     2014-07-14 15:11:18   R-reguExtI      15
     2014-07-14 15:11:18   R-reguExtP      30
     2014-07-14 15:11:18   R-reguExtPstart 30
     2014-07-14 15:11:18   R-reguIntI      15
     2014-07-14 15:11:18   R-reguIntP      30
     2014-07-14 15:11:18   R-reguIntPstart 27
     2014-07-14 15:11:18   R-showInfo      time
     2014-07-14 15:11:18   R-showWeekday   off
     2014-07-14 15:11:14   R-sign          off
     2013-12-24 12:42:49   R-tempMax       30.5 C
     2013-12-24 12:42:49   R-tempMin       4.5 C
     2014-07-14 15:11:18   R-tempOffset    0.0K
     2014-01-26 20:15:37   R-valveErrPos   5 %
     2013-12-24 12:42:49   R-valveMaxPos   100 %
     2013-12-24 12:42:49   R-valveOffset   0 %
     2014-01-08 11:00:19   R-valveOffsetRt 0 %
     2014-07-14 15:11:18   R-winOpnBoost   off
     2014-04-18 21:16:58   R-winOpnDetFall 1.4 K
     2014-07-14 15:11:18   R-winOpnMode    off
     2013-12-24 12:42:49   R-winOpnPeriod  15 min
     2013-12-24 12:42:49   R-winOpnTemp    12 C
     2014-07-14 15:27:07   R_0_tempListSat 24:00 18.0
     2014-07-14 15:27:07   R_1_tempListSun 24:00 18.0
     2014-07-14 15:27:07   R_2_tempListMon 24:00 18.0
     2014-07-14 15:27:07   R_3_tempListTue 24:00 18.0
     2014-07-14 15:27:07   R_4_tempListWed 24:00 18.0
     2014-07-14 15:27:07   R_5_tempListThu 24:00 18.0
     2014-07-14 15:27:07   R_6_tempListFri 24:00 18.0
     2014-07-14 15:27:07   R_tempList_State verified
     2014-07-18 07:58:45   ValvePosition   100
     2014-07-18 07:58:45   controlMode     manual
     2014-07-18 07:58:45   desired-temp    on
     2014-07-18 07:58:45   measured-temp   24.0
     2014-07-18 07:50:31   mode            set_manual
     2014-07-18 07:58:45   motorErr        ok
     2014-07-18 07:51:59   recentStateType ack
     2014-07-18 07:58:45   state           T: 24.0 desired: on valve: 100
     2014-03-15 11:09:19   tempList_State  verified
   Helper:
     Role:
       chn        1
     Shregr:
       07         00
Attributes:
   event-on-change-reading .*
   expert     1
   group      Heizkoerper
   icon       sani_heating
   model      HM-CC-RT-DN
   peerIDs    00000000,
   room       eg_of,eg,D_heizung
   structexclude .*:.*
   subType    thermostat
   webCmd     desired-temp

Rainer

Hollo · 18 Juli 2014, 08:35:27

Zitat von: geek am 18 Juli 2014, 08:04:31...
Das log zeigt aber, das nach einem "set xx controlManu yy" der RT-DN beim nächsten update oft controlMode=auto meldet.
...

Den Effekt habe ich auch schon beobachtet. Wahrscheinlich bin ich aber beim Testen meist zu ungeduldig, ich nächsten Schritt passt es dann.
Wobei ich anfangs auch immer Fehlermeldungen (wie hier auch schon von anderen gepostet) bekommen habe, wenn ich meine Thermostate zusammen (mittels set .*_Heizung_Clima controlManu off) schalten wollte.
Genauso hat mein Wohnzimmer-Thermostat nach dem Fenster öffnen/schliessen auch immer wieder die desired-temp geändert (was ja bei auto auch richtig wäre); jetzt bleibt er auf manu off stehen.

Mit dem aktuellen FHEM-Stand und nach einigen get configs läuft es momentan, aber generell machen mich die Dinger wahnsinnig; das leidige Thema mit dem Temperatur-Istwert reicht ja schon.