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:
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:
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.
werde ich mir ansehen.
da stimmt etwas mit der Umschaltung "condBurst" und wakeup nicht.
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
Hallo Martin,
erst mal dank für die schnelle Antwort.
Zitathast 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:
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:
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
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
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
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
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.
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
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!)
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
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.
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)