HM-CC-RT-DN

[chris1284]

Hi,

ich hatte bereits den rt mehrmals reseted, batterien raus , den pi neu installiert usw usw. der rt hatte auch immer keinen "funkmasten" im display (war also nie gepaired).

was mir neben bei noch aufällt ist das die led am COC dauer an ist nach dem fhem staret. füre ich dann zb ein getconfig durch oder schalte eine meiner itr 1500 geht die led aus... ist dies normal?

EDIT: Habe jetz mal die 5.5 installiert, den rt paired und dann das update durchgeführt. bis jetzt läufts

[papillon81]

@chris1284: Danke für den Tip. Ich habe seit gestern versucht ein Pairing mit der letzten SVN Version hinzubekommen. Ohne Erfolg. Jetzt nach einem downgrade auf 5.5 ging es sofort. Mich würde interessieren, was da kaputt gegangen ist. Evtl. ein SVN bisect machen? Aber ich gehe davon aus,  dass Martin weiß woher die Problematik kommt...
Ansonsten teste ich gerne weiter.

Gruß
Chris

[chris1284]

so wie es aussieht ist das einzige was für ein erfolgreiches paaren noch fehlt eine bestätigung seitens fhem. meine vermutung wenn ich mir die logs anschaue, bin ja nur "leihe".

wenn man schaut wird durch autocreate das device angelegt, das sieht auch alles normal aus, am rt jedoch keine AC-meldung. der "sendemast" ist auch nicht zu sehen.

[papillon81]

Kann ich so bestätigen, ja. Es erscheint weder Sendemast noch ein Ack, die Devices werden aber angelegt.

[Mr. P]

so wie es aussieht ist das einzige was für ein erfolgreiches paaren noch fehlt eine bestätigung seitens fhem. meine vermutung wenn ich mir die logs anschaue, bin ja nur "leihe".

wenn man schaut wird durch autocreate das device angelegt, das sieht auch alles normal aus, am rt jedoch keine AC-meldung. der "sendemast" ist auch nicht zu sehen.

Hej chris1284,

genau so ist es. Ein autocreate alleine führt noch kein pairing durch. Es legt lediglich die Geräte in FHEM an (eben autocreate und nicht autopair).
Ist als Einsteiger durchaus nicht gleich zu durchschauen. Geräte werden schließlich angezeigt, warum also nicht auch gepairt.

Jedenfalls ist es unumgänglich, dass du für deine RTs auch immer noch ein Pairing durchführst, damit diese auch wirklich wissen, mit wem sie zukünftig plaudern müssen.

[chris1284]

hi mr.p,

schon klar, nur das funktioniert nicht meiner meinung nach. wie gesagt wenns in der 5.5 geht, aber in der aktuellsten svn nicht liegt wohl genau da der fehler, nicht bei mir. da es reproduzierbar ist, erhärtet sich der verdacht. und mehr als hmpairforsec und hmpairserial kann ich ja nicht ausführen zum pairen.

noch mal etwas deutlicher:
ausgehend von gleich aufgesetztem pi, gleicher softwarestand
fhem 5.5
-> set cul hmpairforsec 600
-> knopf am rt gedrückt
-> sofort AC
-> gerät in fhem paired und angelegt

aktueller svn
-> set cul hmpairforsec 600
-> knopf am rt gedrückt
-> zeit läuft die 30sec auf 0, kein AC, kein "sendemast"(visuelle bestätigung das paired)
-> in fhem wurde das gerät wie gewohnt angelegt, keine komunikation (klar, ist ja auch nicht erfolgreich paired)

nehm ich das gleiche system und haue nur die svn-version runter, ziehe danach wieder 5.5 drauf klappt es auf anhieb. natürlich wurde jedes mal der rt komplet resetet

[Mr. P]

Hej chris1284,

folgender Vorschlag: Ich muss heute ohnehin noch eine HM-Installation vorbereiten und dabei sind auch 4RTs zu pairen.
Ich schau mir das heute am Abend an und dann kann ich dann kann ich dir auch um einiges besser helfen.
Muss zuvor nur noch ein paar Weihnachtseinkäufe erledigen.

[Mr. P]

So... gerade eben noch ein Update gemacht und FHEM neu gestartet.
Im Anschluss die Batterien in den RT, schnell durchgegeklickt, bis 'Ins' erscheint,  'set myCUN hmPairForSec 20' in die Konsole gehämmert und den Boost-Button lang gedrückt.

Autocreate tut seinen Job, der ActionDetector wurde angelegt und der Sendemasten am RT ist ebenfalls da.

[holzwurm83]

Hallo zusammen,

da es aktuell mit dem CUNO noch Schwierigkeiten gibt und ich noch einen CUL besitze habe ich dies für die Zeit bis zur Problem Behebung getauscht und fürs erste zwei RTs mit dem CUL gepairt.

Ich habe allerdings immer noch kein Kanal der "ClimRT_tr"!? Nach einem "getconfig" verändert sich das auch nicht!? Ich weiß nicht warum? Heißt der nur anders?

Hier mal die "list" noch dem RT. Mit meinem Anfängerauge betrachtet sollte, aber alles passen???

Internals:
   CUL_1_MSGCNT 6
   CUL_1_RAWMSG A0FA686102207330000000A80C310000148
   CUL_1_RSSI -38
   CUL_1_TIME 2013-12-24 01:06:46
   DEF        220733
   IODev      CUL_1
   LASTInputDev CUL_1
   MSGCNT     6
   NAME       CUL_HM_HM_CC_RT_DN_220733
   NR         316
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 CUL_HM_HM_CC_RT_DN_220733_Weather
   channel_02 CUL_HM_HM_CC_RT_DN_220733_Climate
   channel_03 CUL_HM_HM_CC_RT_DN_220733_WindowRec
   channel_04 CUL_HM_HM_CC_RT_DN_220733_Clima
   channel_05 CUL_HM_HM_CC_RT_DN_220733_ClimaTeam
   channel_06 CUL_HM_HM_CC_RT_DN_220733_remote
   lastMsg    No:A6 - t:10 s:220733 d:000000 0A80C3100001
   protLastRcv 2013-12-24 01:06:46
   rssi_at_CUL_1 avg:-37.66 min:-38 max:-37.5 lst:-38 cnt:6
   CHANGETIME:
   Helper:
     Dblog:
       Activity:
         Mydblog:
           TIME       1387842798.12048
           VALUE      alive
       Actuator:
         Mydblog:
           TIME       1387843606.25386
           VALUE      0
       Battery:
         Mydblog:
           TIME       1387843606.25386
           VALUE      ok
       Batterylevel:
         Mydblog:
           TIME       1387843606.25386
           VALUE      3.1 V
       Desired-temp:
         Mydblog:
           TIME       1387843606.25386
           VALUE      16
       Measured-temp:
         Mydblog:
           TIME       1387843606.25386
           VALUE      19.5
   Readings:
     2013-12-24 00:53:18   Activity        alive
     2013-12-24 00:51:41   CommandAccepted yes
     2013-12-24 00:33:18   PairedTo        0xF11134
     2013-12-23 18:10:30   R-backOnTime    10 s
     2013-12-24 00:33:18   R-btnLock       unlock
     2013-12-24 00:33:18   R-burstRx       off
     2013-12-24 00:33:18   R-cyclicInfoMsg on
     2013-12-24 00:33:18   R-cyclicInfoMsgDis 0
     2013-12-24 00:33:18   R-globalBtnLock off
     2013-12-24 00:33:18   R-localResDis   off
     2013-12-23 18:10:30   R-lowBatLimitRT 2.1 V
     2013-12-24 00:33:18   R-modusBtnLock  off
     2013-12-24 00:33:18   R-pairCentral   0xF11134
     2013-12-24 00:33:18   RegL_00:        01:00 02:01 09:01 0A:F1 0B:11 0C:34 0E:0A 0F:00  11:00 12:15 16:00 18:00 19:00 1A:00 00:00
     2013-12-24 01:06:46   actuator        0 %
     2013-12-24 01:06:46   battery         ok
     2013-12-24 01:06:46   batteryLevel    3.1 V
     2013-12-24 01:06:46   desired-temp    16
     2013-12-24 01:06:46   measured-temp   19.5
     2013-12-23 18:07:12   powerOn         -
     2013-12-23 18:07:12   recentStateType info
     2013-12-24 00:51:42   state           CMDs_done
     2013-12-23 18:09:38   time-request    -
   Helper:
     mId        0095
     rxType     140
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf   
       qReqStat   
     Role:
       dev        1
     Rssi:
       At_cul_1:
         avg        -37.6666666666667
         cnt        6
         lst        -38
         max        -37.5
         min        -38
Attributes:
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   1.0
   model      HM-CC-RT-DN
   peerIDs   
   room       CUL_HM
   serialNr   KEQ0510374
   subType    thermostat
   webCmd     getConfig:burstXmit

[Mr. P]

Ich habe allerdings immer noch kein Kanal der "ClimRT_tr"!? Nach einem "getconfig" verändert sich das auch nicht!? Ich weiß nicht warum? Heißt der nur anders?

Ja, der Kanal *ClimRT_tr heißt jetzt *Clima und der ist bei dir vorhanden. Auch sonst sieht alles gut aus.
Wichtig für ein erfolgreiches Pairing ist immer das Register: pairCentral und das ist bei dir befüllt.

[Mr. P]

Hej chris1284,

hab gerade eine neue Version eingecheckt. Sollte in der Früh zur Verfügung stehen.
Probier es doch bitte einmal damit.

[chris1284]

so früh / spät noch unterwegs

habe das update eingespielt, folge: FHEM kommuniziert nicht mehr mit RT.
also rt zurück gesetzt. gerät aus fhem geschmissen (fhem.cfg, logs usw). danach war ein pairing sofort (<5sec) möglich. Gerät ist angelegt und es wird sich unterhalten.

[Mr. P]

so früh / spät noch unterwegs

Was sein muss, muss sein.

habe das update eingespielt, folge: FHEM kommuniziert nicht mehr mit RT.

Tut nicht?

also rt zurück gesetzt. gerät aus fhem geschmissen (fhem.cfg, logs usw). danach war ein pairing sofort (<5sec) möglich. Gerät ist angelegt und es wird sich unterhalten.

Tut doch? Kann dir nicht ganz folgen.
Hab gerade nochmal ein Gerät gepairt und dann auch die Temperatur über die Console eingestellt - hat alles funktioniert.

[chris1284]

Kann dir nicht ganz folgen.

ja, funktioniert nun. musste nach dem update nur den rt nochmal neu paaren und dann ging alles wieder, temp-listen eingefügt, temps manuel gesetzt usw.

[chris1284]

mal eine verständisfrage. warum taucht das gerät (rt) an sich als

thermostat

auf, aber alle channels die dazu gehören als

CUL_HM

. wäre es nicht sinvoller die mit unter dem thermostat zu listen?

des weiteren, ist der automatisch erstellte ActionDetector unter CUL_HM nur diesem thermostat zugeordnet?
sprich wenn ich den CUL_HM_HM_CC_RT_DN_xxxxxx der ordunghalber umbenne sollte der ActionDetector der zugehörigkeit halber auch umbenannt werden?