Kann (meistens) kein desired-temp an hm-cc-tc schicken

[URHome]

Hallo Leute,
meine hm-cc-tc's stellen sich plötzlich fast immer quer wenn ich die Soll-Temperatur umstellen will. Das Problem hatte ich früher ganz ganz vereinzelt mal. Ich habe mal die LogLevel für einen der beiden hm-cc-tc und für mein HMLAN angepasst. Das sieht dann so aus:

Code Auswählen Erweitern


2013.10.03 16:54:39 2: CUL_HM set AZ.Thermostat desired-temp 19.0
2013.10.03 16:54:39 0: HMLAN_Send:  HMLAN1 S:S7ED041D9 stat:  00 t:00000000 d:01 r:7ED041D9 m:14 B112 115D28 1D9582
2013.10.03 16:54:39 0: HMLAN_Send:  HMLAN1 I:K
2013.10.03 16:54:39 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315411 d:1C66D2 O:115D28 t:0065FB51 IDcnt:0003
2013.10.03 16:54:41 0: HMLAN_Parse: HMLAN1 R:R7ED041D9 stat:0008 t:00000000 d:FF r:7FFF     m:14 B112 115D28 1D9582
2013.10.03 16:54:41 0: HMLAN_Parse: HMLAN1 no ACK from 1D9582
2013.10.03 16:54:43 0: HMLAN_Send:  HMLAN1 S:S7ED05261 stat:  00 t:00000000 d:01 r:7ED05261 m:14 B112 115D28 1D9582
2013.10.03 16:54:43 0: CUL_HM_Resend: AZ.Thermostat nr 251
2013.10.03 16:54:45 0: HMLAN_Parse: HMLAN1 R:R7ED05261 stat:0008 t:00000000 d:FF r:7FFF     m:14 B112 115D28 1D9582
2013.10.03 16:54:45 0: HMLAN_Parse: HMLAN1 no ACK from 1D9582
2013.10.03 16:54:49 0: HMLAN_Send:  HMLAN1 S:S7ED068FE stat:  00 t:00000000 d:01 r:7ED068FE m:14 B112 115D28 1D9582
2013.10.03 16:54:49 0: CUL_HM_Resend: AZ.Thermostat nr 252
2013.10.03 16:54:51 0: HMLAN_Parse: HMLAN1 R:R7ED068FE stat:0008 t:00000000 d:FF r:7FFF     m:14 B112 115D28 1D9582
2013.10.03 16:54:51 0: HMLAN_Parse: HMLAN1 no ACK from 1D9582
2013.10.03 16:54:54 0: HMLAN_Send:  HMLAN1 S:S7ED07F08 stat:  00 t:00000000 d:01 r:7ED07F08 m:14 B112 115D28 1D9582
2013.10.03 16:54:54 0: CUL_HM_Resend: AZ.Thermostat nr 253
2013.10.03 16:54:56 0: HMLAN_Parse: HMLAN1 R:R7ED07F08 stat:0008 t:00000000 d:FF r:7FFF     m:14 B112 115D28 1D9582
2013.10.03 16:54:56 0: HMLAN_Parse: HMLAN1 no ACK from 1D9582
2013.10.03 16:55:00 0: HMLAN_Send:  HMLAN1 S:S7ED0959D stat:  00 t:00000000 d:01 r:7ED0959D m:14 B112 115D28 1D9582


Das geht dann mit dem ReSend lustig weiter und irgendwann geht der HMLAN in den Overload.

Hier mal noch die cfg für das Teil:

Code Auswählen Erweitern


define AZ.Thermostat CUL_HM 1D9582
attr AZ.Thermostat actStatus unknown
attr AZ.Thermostat expert 2_full
attr AZ.Thermostat firmware 2.1
attr AZ.Thermostat model HM-CC-TC
attr AZ.Thermostat peerIDs
attr AZ.Thermostat room Arbeitszimmer
attr AZ.Thermostat serialNr JEQ0552941
attr AZ.Thermostat subType thermostat


Ich habe vor ungefähr einer Woche meinen FHEM von der Fritzbox runter auf nen raspberry pi umgesetzt. Könnte unter Umständen auch damit zu tun haben. Gemerkt hab ich das jetzt die Tage als ich von der Arbeit kam und ne kalte Bude hatte. Die Kommunikation zu den anderen Geräten funktioniert wenn der HMLAN nicht gerade im Overload ist.

[martinp876]

werde ich mir ansehen.

da stimmt etwas mit der Umschaltung "condBurst" und wakeup nicht.

[martinp876]

habe es noch einmal getestet - funktioniert.

hast du die aktuelle SW?
kannst du ein list von device senden?

mache einmal ein
set <device> clear msgEvents
set <climate> desired-temp xxx

und zeichne es noch einmal auf, dann das list

[URHome]

Hallo Martin,

erst mal dank für die schnelle Antwort.

hast du die aktuelle SW?

Die war nicht ganz aktuell. Die hatte Stand 29.9.2013. Da hatte ich mein letztes Update gemacht.

Ich hab dann gestern Abend mal noch ein Update durchgeführt und siehe da, jetzt scheint es zu funktionieren. Zumindest wurden jetzt bei allen Versuchen die ich eben gemacht habe immer schön brav die Solltemperaturen umgesetzt ohne das der HMLAN Kernel-Panik bekommen hätte. Ich hab jetzt auch mal einen Durchgang aufgezeichnet und den List vom Device angefertigt. Wenns noch interessiert kannst du ja reinschauen :).

Log:

Code Auswählen Erweitern


2013.10.04 16:33:28 2: CUL_HM set AZ.Thermostat.Climate desired-temp 22.0
2013.10.04 16:33:28 0: HMLAN_Send:  HMLAN1 S:S83E33B83 stat:  00 t:00000000 d:01 r:83E33B83 m:2A B112 115D28 1D9582
2013.10.04 16:33:28 0: CUL_HM AZ.Thermostat protEvent:CMDs_processing... pending:1
2013.10.04 16:33:30 0: HMLAN_Parse: HMLAN1 R:R83E33B83 stat:0008 t:00000000 d:FF r:7FFF     m:2A B112 115D28 1D9582
2013.10.04 16:33:30 0: HMLAN_Parse: HMLAN1 no ACK from 1D9582
2013.10.04 16:33:32 0: CUL_HM AZ.Thermostat protEvent:CMDs_pending pending:1
2013.10.04 16:33:37 0: HMLAN_Send:  HMLAN1 I:K
2013.10.04 16:33:37 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315411 d:1C66D2 O:115D28 t:05793E7C IDcnt:0008
2013.10.04 16:34:02 0: HMLAN_Send:  HMLAN1 I:K
2013.10.04 16:34:02 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315411 d:1C66D2 O:115D28 t:0579A044 IDcnt:0008
2013.10.04 16:34:03 0: HMLAN_Parse: HMLAN1 R:E1D9582   stat:0000 t:0579A43F d:FF r:FFD2     m:14 8670 1D9582 000000 00E72F
2013.10.04 16:34:03 0: HMLAN_Send:  HMLAN1 S:S83E3C17C stat:  00 t:00000000 d:01 r:83E3C17C m:2B A112 115D28 1D9582
2013.10.04 16:34:03 0: CUL_HM AZ.Thermostat protEvent:CMDs_processing... pending:1
2013.10.04 16:34:03 0: HMLAN_Parse: HMLAN1 R:R83E3C17C stat:0001 t:0579A541 d:FF r:FFD2     m:2B 8002 1D9582 115D28 00
2013.10.04 16:34:03 0: HMLAN_Send:  HMLAN1 S:S83E3C27C stat:  00 t:00000000 d:01 r:83E3C27C m:2C A011 115D28 1D9582 02022C
2013.10.04 16:34:03 0: CUL_HM AZ.Thermostat protEvent:CMDs_processing... pending:0
2013.10.04 16:34:03 0: HMLAN_Parse: HMLAN1 R:R83E3C27C stat:0001 t:0579A6D5 d:FF r:FFD2     m:2C 8002 1D9582 115D28 01022C002C
2013.10.04 16:34:03 0: CUL_HM AZ.Thermostat protEvent:CMDs_done


List:

Code Auswählen Erweitern


Internals:
   DEF        1D9582
   EVENTS     4
   HMLAN1_MSGCNT 944
   HMLAN1_RAWMSG E1D9582,0000,0579F261,FF,FFD2,14A2581D95821D60710000
   HMLAN1_RSSI -46
   HMLAN1_TIME 2013-10-04 16:34:23
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     944
   NAME       AZ.Thermostat
   NR         93
   STATE      T: 23.1 H: 47
   TYPE       CUL_HM
   channel_02 AZ.Thermostat.Climate
   lastMsg    No:14 - t:58 s:1D9582 d:1D6071 0000
   protCondBurst off
   protLastRcv 2013-10-04 16:34:23
   protSnd    3 last_at:2013-10-04 16:34:03
   protState  CMDs_done
   rssi_HMLAN1 avg:-44 min:-45 max:-43 lst:-44 cnt:7
   rssi_at_HMLAN1 avg:-46.08 min:-49 max:-45 lst:-46 cnt:944
   Readings:
     2013-10-04 16:34:03   CommandAccepted yes
     2013-10-04 16:34:23   actuator        0 %
     2013-10-04 16:34:03   battery         ok
     2013-10-04 16:34:03   desired-temp    22.0
     2013-10-04 16:34:03   humidity        47
     2013-10-04 16:34:03   measured-temp   23.1
     2013-10-04 16:34:03   state           T: 23.1 H: 47
     2013-10-04 00:01:41   time-request    -
   Helper:
     mId        0039
     rxType     140
     Prt:
       awake      0
       sProc      0
       Rspwait:
     Role:
       chn        1
       dev        1
     Rssi:
       Hmlan1:
         avg        -44
         cnt        7
         lst        -44
         max        -43
         min        -45
       At_hmlan1:
         avg        -46.0805084745762
         cnt        944
         lst        -46
         max        -45
         min        -49
Attributes:
   actStatus  unknown
   expert     2_full
   firmware   2.1
   loglevel   0
   model      HM-CC-TC
   peerIDs    
   room       Arbeitszimmer
   serialNr   JEQ0552941
   subType    thermostat


[martinp876]

ok
ich hatte (wie in einem der threats beschreiben :-(  )
das handling zugunsten "conditional-burst re-transmit" umgestellt. Da bist du wohl an eine semi-funktionale version gelangt.
sorry

[reini0815]

Hallo martin,

ich habe das gleiche Problem.
Häufig einen Overload im HMLAN nach dem Setzten der Temperatur im HM-TC

Habe die aktuelle 00_HMLAN.pm heute geladen:
# $Id: 00_HMALN.pm 4005 2013-10-04 14:28:11Z martinp876

habe ich die falsch HMLAN.pm?

Viele Grüße

Reinhard

[martinp876]

Hallo Reinhard,

bei URHome sollte das Problem mit dem Update gelöst sein.

das häufige overload verstehe ich nicht. kannst du einmal rohmessages mitloggen?
wenn nicht viel los ist sollte so etwas nicht vorkommen. (ansonsten auch nicht...)

Wie neue Version sendet auch nicht wirklich viel mehr messages...

Gruss Martin

[betateilchen]

Seit gestern kann ich an meinem HM-CC-TC auch keine desired-temp mehr einstellen.

Hier gibt es kein overload-Problem, er reagiert einfach nicht.
Und burstRx kann ich in dieser Verweigerungshaltung natürlich auch nicht abschalten.

Code Auswählen Erweitern


Internals:
   DEF        1D919A
   EVENTS     853
   HMUSB_MSGCNT 857
   HMUSB_RAWMSG E1D919A,0000,03EF0512,FF,FFCD,3FA2581D919A1DA1A90000
   HMUSB_RSSI -51
   HMUSB_TIME 2013-10-15 13:33:56
   IODev      HMUSB
   LASTInputDev HMUSB
   MSGCNT     857
   NAME       wz_FHT
   NR         264
   STATE      T: 20.8 H: 64
   TYPE       CUL_HM
   channel_01 wz_FHT_Weather
   channel_02 wz_FHT_Climate
   channel_03 wz_FHT_WindowRec
   lastMsg    No:3F - t:58 s:1D919A d:1DA1A9 0000
   protCmdDel 15
   protLastRcv 2013-10-15 13:33:56
   protResndFail 7 last_at:2013-10-15 13:26:02
   protSnd    51 last_at:2013-10-15 13:26:00
   protState  CMDs_done_Errors:1
   rssi_HMUSB avg:-46.83 min:-48 max:-46 lst:-48 cnt:6
   rssi_at_HMUSB avg:-51.12 min:-52 max:-50 lst:-51 cnt:857
   Readings:
     2013-10-15 07:39:54   Activity        alive
     2013-10-15 07:39:55   CommandAccepted yes
     2013-10-14 20:27:06   PairedTo        0x127000
     2013-10-14 20:27:06   R-backlOnMode   auto
     2013-10-14 20:27:06   R-backlOnTime   25
     2013-10-14 20:27:06   R-btnLock       unlock
     2013-10-14 20:27:06   R-burstRx       on
     2013-10-14 20:27:06   R-intKeyVisib   visib
     2013-10-14 20:27:06   R-pairCentral   0x127000
     2013-10-14 20:27:06   RegL_00:          01:01 02:81 05:85 0A:12 0B:70 0C:00 0F:00 00:00
     2013-10-15 13:33:56   actuator        0 %
     2013-10-15 07:39:56   battery         ok
     2013-10-14 20:27:13   controlMode     central
     2013-10-14 20:27:13   day-temp        21 C
     2013-10-14 20:27:13   decalcDay       Sat
     2013-10-15 07:39:56   desired-temp    20.5
     2013-10-14 20:27:13   displayMode     temp-hum
     2013-10-14 20:27:13   displayTemp     actual
     2013-10-14 20:27:13   displayTempUnit celsius
     2013-10-15 13:33:36   humidity        64
     2013-10-15 13:33:36   measured-temp   20.8
     2013-10-14 20:27:13   night-temp      17 C
     2013-10-14 20:27:13   party-temp      20 C
     2013-10-15 13:33:36   state           T: 20.8 H: 64
     2013-10-15 00:02:37   time-request    -
   Helper:
     mId        0039
     rxType     12
     Prt:
       bErr       1
       sProc      0
       Rspwait:
     Role:
       chn        1
       dev        1
     Rssi:
       Hmusb:
         avg        -46.8333333333333
         cnt        6
         lst        -48
         max        -46
         min        -48
       At_hmusb:
         avg        -51.1213535589265
         cnt        857
         lst        -51
         max        -50
         min        -52
     Shadowreg:
Attributes:
   Heizung    allHeatings
   actCycle   000:10
   actStatus  alive
   autoReadReg 3_onChange
   event-on-change-reading state
   event-on-update-reading state,actuator
   expert     2_full
   firmware   2.1
   group      Heizung
   icon       hc_wht_regler
   model      HM-CC-TC
   peerIDs   
   room       10_Wohnzimmer
   serialNr   JEQ0551882
   subType    thermostat


[betateilchen]

Ich bin jetzt bei 00_HMLAN und 10_CUL_HM auf die Rev 4029 zurückgegangen, nun funktioniert der TC wieder wie er soll, und burstRx steht auch wieder auf off (nicht von mir geändert!)

[Billy]

Also bei mir geht das mit dem update von heute.

00_HMLAN.pm 4040 2013-10-13

10_CUL_HM.pm 4042 2013-10-14

Billy

[betateilchen]

Gerade habe ich die aktuellen Versionen aus SVN geladen

# $Id: 00_HMLAN.pm 4040 2013-10-13 18:28:05Z martinp876 $
# $Id: 10_CUL_HM.pm 4042 2013-10-14 17:46:05Z martinp876 $

und es funktioniert nicht.

Entweder ich lande in MISSING ACK oder der state bleibt bei "set_desired-..." hängen.

Ich bleibe erstmal bei Rev 4029.

[martinp876]

einen log hast du nicht zufällig gezogen?
wenn burstRx auf off steht kann es nicht an einer andern Version liegen. FHEM schreibt ohne aufforderung keinerlei Register. Das muss also schon vorher drin gewesen sein.

bei tempList ist ein Bug drin... kommt in kürze (bin gerade mitten in anderen Änderungen)