HM-CC-RT-DN: motorErr communicationERR, trotzdem alles ok

Thorsten Pferdekaemper · 24 Januar 2014, 09:55:05

Hi,
ich habe seit heute morgen ein "motorErr communicationERR" in einem meiner RT's. Außerdem blinkt das Funk-Symbol am RT. Es funktioniert aber alles, einschließlich Kommandos ans Device (bzw. den Channel) senden.
Das Teil ist seit ein paar Wochen in Betrieb und heute ist das erste Mal, dass ich das sehe.
Hier sind ein paar Logeinträge:

Code Auswählen


2014.01.24 09:38:58.763 0: HMLAN_Parse: HMLAN1 R:E21F833   stat:0000 t:00B5E616 d:FF r:FFCA     m:80 8610 21F833 000000 0AB0F190041E
2014.01.24 09:41:22.513 0: HMLAN_Parse: HMLAN1 R:E21F833   stat:0000 t:00B817B0 d:FF r:FFCA     m:81 8610 21F833 000000 0AB0F290041E
2014.01.24 09:43:31.761 0: HMLAN_Parse: HMLAN1 R:E21F833   stat:0000 t:00BA10A3 d:FF r:FFCA     m:82 8610 21F833 000000 0AB0F290041E
2014.01.24 09:46:30.511 0: HMLAN_Parse: HMLAN1 R:E21F833   stat:0000 t:00BCCAFA d:FF r:FFCA     m:83 8610 21F833 000000 0AB0F290041E

Ein list vom Channel (hier sieht man den communicationErr):

Code Auswählen


Internals:
   DEF        21F83304
   HMLAN1_MSGCNT 861
   HMLAN1_RAWMSG E21F833,0000,00C197A9,FF,FFCA,85861021F8330000000AB0F390041E
   HMLAN1_RSSI -54
   HMLAN1_TIME 2014-01-24 09:51:45
   LASTInputDev HMLAN1
   MSGCNT     861
   NAME       og_bd_HeizungOp
   NR         46
   STATE      T: 24.3 desired: 22 valve: 4 %
   TYPE       CUL_HM
   chanNo     04
   device     og_bd_Heizung
   Readings:
     2014-01-08 20:15:48   R-boostPeriod   5 min
     2014-01-08 20:15:48   R-boostPos      80 %
     2014-01-08 20:15:48   R-btnNoBckLight off
     2014-01-08 20:15:48   R-dayTemp       21 C
     2014-01-08 20:15:48   R-daylightSaveTime on
     2014-01-08 20:15:48   R-decalcTime    11:00
     2014-01-08 20:15:48   R-decalcWeekday Sat
     2014-01-08 20:15:48   R-modePrioManu  all
     2014-01-08 20:15:48   R-modePrioParty all
     2014-01-08 20:15:48   R-nightTemp     17 C
     2014-01-08 20:15:48   R-noMinMax4Manu off
     2014-01-08 20:15:48   R-regAdaptive   on
     2014-01-08 20:15:48   R-reguExtI      15
     2014-01-08 20:15:48   R-reguExtP      30
     2014-01-08 20:15:48   R-reguExtPstart 30
     2014-01-08 20:15:48   R-reguIntI      15
     2014-01-08 20:15:48   R-reguIntP      30
     2014-01-08 20:15:48   R-reguIntPstart 30
     2014-01-08 20:15:48   R-showInfo      time
     2014-01-08 20:15:48   R-showWeekday   off
     2014-01-24 08:33:25   R-sign          off 
     2014-01-08 20:15:48   R-tempMax       30.5 C
     2014-01-08 20:15:48   R-tempMin       4.5 C
     2014-01-08 20:15:48   R-tempOffset    0.0K
     2014-01-08 20:15:48   R-valveErrPos   15 %
     2014-01-08 20:15:48   R-valveMaxPos   100 %
     2014-01-08 20:15:48   R-valveOffsetRt 0 %
     2014-01-08 20:15:48   R-winOpnBoost   off
     2014-01-08 20:15:48   R-winOpnDetFall 1.4 K
     2014-01-08 20:15:48   R-winOpnMode    on
     2014-01-08 20:15:48   R-winOpnPeriod  15 min
     2014-01-08 20:15:48   R-winOpnTemp    12 C
     2014-01-24 09:51:45   ValvePosition   4 %
     2014-01-24 09:51:45   desired-temp    22
     2014-01-24 09:51:45   measured-temp   24.3
     2014-01-24 09:51:45   mode            auto
     2014-01-24 09:51:45   motorErr        communicationERR
     2014-01-24 09:51:45   state           T: 24.3 desired: 22 valve: 4 %
     2014-01-08 20:15:48   tempListFri     06:00 17.0 10:00 22.0 18:00 20.0 20:00 22.0 22:00 20.0 24:00 17.0
     2014-01-08 20:15:48   tempListMon     06:00 17.0 10:00 22.0 18:00 20.0 20:00 22.0 22:00 20.0 24:00 17.0
     2014-01-08 20:15:48   tempListSat     06:00 17.0 10:00 22.0 18:00 20.0 20:00 22.0 22:00 20.0 24:00 17.0
     2014-01-08 20:15:48   tempListSun     06:00 17.0 10:00 22.0 18:00 20.0 20:00 22.0 22:00 20.0 24:00 17.0
     2014-01-08 20:15:48   tempListThu     06:00 17.0 10:00 22.0 18:00 20.0 20:00 22.0 22:00 20.0 24:00 17.0
     2014-01-08 20:15:48   tempListTue     06:00 17.0 10:00 22.0 18:00 20.0 20:00 22.0 22:00 20.0 24:00 17.0
     2014-01-08 20:15:48   tempListWed     06:00 17.0 10:00 22.0 18:00 20.0 20:00 22.0 22:00 20.0 24:00 17.0
     2014-01-08 20:15:48   tempList_State  verified
   Helper:
     getCfgListNo 
     Role:
       chn        1
     Shadowreg:
Attributes:
   expert     1
   model      HM-CC-RT-DN
   peerIDs    
   room       og_Bad

...und noch ein list vom Device:

Code Auswählen

Internals:
   DEF        21F833
   HMLAN1_MSGCNT 927
   HMLAN1_RAWMSG E21F833,0000,00C197A9,FF,FFCA,85861021F8330000000AB0F390041E
   HMLAN1_RSSI -54
   HMLAN1_TIME 2014-01-24 09:51:45
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     927
   NAME       og_bd_Heizung
   NR         42
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 og_bd_Heizung_Weather
   channel_02 og_bd_Heizung_Climate
   channel_03 og_bd_Heizung_WindowRec
   channel_04 og_bd_HeizungOp
   channel_05 og_bd_Heizung_ClimaTeam
   channel_06 og_bd_Heizung_Remote
   lastMsg    No:85 - t:10 s:21F833 d:000000 0AB0F390041E
   protLastRcv 2014-01-24 09:51:45
   protSnd    64 last_at:2014-01-24 09:13:33
   protState  CMDs_done
   rssi_at_HMLAN1 avg:-56.75 min:-77 max:-49 lst:-54 cnt:927 
   Readings:
     2014-01-22 21:34:48   Activity        alive
     2014-01-24 09:13:33   CommandAccepted yes
     2014-01-24 08:35:40   PairedTo        0x23A3F4 
     2014-01-05 18:04:24   R-backOnTime    10 s
     2014-01-24 08:35:40   R-btnLock       unlock 
     2014-01-24 08:35:40   R-burstRx       off 
     2014-01-24 08:35:40   R-cyclicInfoMsg on 
     2014-01-24 08:35:40   R-cyclicInfoMsgDis 0 
     2014-01-24 08:35:40   R-globalBtnLock off 
     2014-01-24 08:35:40   R-localResDis   off 
     2014-01-05 18:04:24   R-lowBatLimitRT 2.1 V
     2014-01-24 08:35:40   R-modusBtnLock  off 
     2014-01-24 08:35:40   R-pairCentral   0x23A3F4 
     2014-01-24 08:35:40   RegL_00:          01:00 02:01 09:01 0A:23 0B:A3 0C:F4 0E:0A 0F:00  11:00 12:15 16:00 18:00 19:00 1A:00 00:00
     2014-01-24 06:32:58   RegL_07:        CA:0F CB:1E CC:1D
     2014-01-24 09:51:45   actuator        4 %
     2014-01-24 09:51:45   battery         ok
     2014-01-24 09:51:45   batteryLevel    3.1 V
     2014-01-24 09:51:45   desired-temp    22
     2014-01-24 09:51:45   measured-temp   24.3
     2014-01-24 09:13:33   state           CMDs_done
     2014-01-23 17:55:45   time-request    -
   Helper:
     cSnd       0123A3F421F83306040000000001
     mId        0095
     rxType     140
     Io:
       nextSend   1390553505.10285
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf   
       qReqStat   
     Role:
       dev        1
     Rssi:
       At_hmlan1:
         avg        -56.7551240560949
         cnt        927
         lst        -54
         max        -49
         min        -77
     Shadowreg:
       RegL_07:   
Attributes:
   IODev      HMLAN1
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   1.0
   model      HM-CC-RT-DN
   peerIDs    
   room       og_Bad
   serialNr   KEQ0506349
   subType    thermostat
   webCmd     getConfig:burstXmit

Wird da jemand schlau draus?
Wie gesagt, die Fehlermeldung bleibt bestehen, aber ich kann keinerlei Fehlfunktion entdecken.
Gruß,
Thorsten

martinp876 · 24 Januar 2014, 11:48:15

Hi,

der Fehler wird klar gemeldet. was er genau bedeuted... etwas mit der Communikation. Evtl auch zu einem der peers!
ich würde erwarten, dass das Antennensymbol blinkt.
Mit wenn ist den der RT gepeert? Hat einer dieser peers ein Problem?

Gruss Martin

Thorsten Pferdekaemper · 24 Januar 2014, 12:07:59

Hi,
ja, das Antennensymbol blinkt, aber es scheint alles zu funktionieren.
Das Teil ist ein Einzelkämpfer, also keine Peers.
Bei den beiden anderen RTs (einer mit und einer ohne Peer) tritt das Problem nicht auf.
Kann es sein, dass es halt mal ein Kommunikationsproblem gab und die Meldung vom RT nicht von alleine zurückgesetzt wird?
Gruß,
Thorsten

martinp876 · 24 Januar 2014, 14:22:32

Hi Thorsten,

du bist sicher, das in keinem Kanal ein peer eingetragen ist und hast es mit einem aktuellen getConfig verifiziert? Nur zur Sicherheit.
Ich denke schon, dass dieses Signal wieder verschwindet, so das Problem gelöst ist.
hast du schon einmal nach Anleitung das SFA menue am RT aufgesucht und die Fehlermeldungen angesehen? Ist da etwas zu sehen? Sollte eigentlich...

Gruss Martin

Thorsten Pferdekaemper · 24 Januar 2014, 14:44:37

Hi,
also ich bin jetzt nochmal alle Kanäle durchgegangen. Überall zeigt peerIDs entweder nichts oder "000000" an. Ich habe das auch mit einem anderen RT verglichen, da ist es genauso. getConfigs habe ich einige gemacht...
Das SFA-Menü zeigt "CCU" an. Eine echte CCU habe ich nicht, nur ein HMLAN und FHEM.
Wenn es tatsächlich ein so hartnäckiges Kommunikationsproblem gäbe, dann müsste man das doch auch woanders sehen, oder? Die Readings kommen brav alle 2 bis 3 Minuten und sehen sinnvoll aus. Auch ein set desired-temp funktioniert wie erwartet.
Gruß,
Thorsten

martinp876 · 24 Januar 2014, 19:38:44

wenn er CCU anmekert dann ist dies FHEM, die Zentrale eben.
der RT sieht evtl das ACK nicht....
Aber kommandos kann er gut empfangen? die pairing ID passt? dann weiss ich auch nicht. Auch nicht ob man es weg-clicken kann - habe nichts gelesen dazu
Gruss Martin

Thorsten Pferdekaemper · 24 Januar 2014, 20:36:43

Hi,

ja, es hat alles funktioniert.
Ich habe jetzt dem Teil trotzdem mal einen Reset verpasst und neu gepairt. Das Pairen hat erst im zweiten Anlauf geklappt, also so ganz sauber ist das wohl nicht.
Er hat sich dann fast sofort die richtige Uhrzeit geholt und Einstellen der TempLists per FHEM war auch kein Problem. Das getConfig danach auch ohne Probleme.
Das Funk-Icon blinkt nicht mehr und motorErr zeigt auch "ok".

Vielleicht ist das noch eine nützliche Information: 13 Minuten bevor der communicationErr das erste mal im FileLog auftauchte gab es einen HMLAN disconnect. Dazwischen gab's aber noch ein paar ganz normale Readings.

Gruß,
Thorsten

Thorsten Pferdekaemper · 25 Januar 2014, 10:47:36

Hi,
sehr seltsam, möglicherweise ist mein System ein Morgenmuffel.
Heute morgen gegen 5:05 war der HMLAN für fast eine Minute disconnected. Ab 6:35 dann wieder der communicationErr ohne weitere Auswirkungen. Das Funksymbol blinkt und am HMLAN flackert die Status LED manchmal rot.
An mir kann's nicht liegen, ich habe bis etwa 7:00 tief und fest geschlafen...
Ich habe inzwischen den Verdacht, dass irgendein Nachbar ein Gerät hat, was auf derselben Funkfrequenz liegt und irgendwas schickt, was das System verwirrt. Das erklärt natürlich die disconnects vom HMLAN nicht.
Hat da jemand eine Idee?
Gruß,
Thorsten

martinp876 · 25 Januar 2014, 11:09:42

Hi Thorsten,

am Nachbarn kann es nicht liegen, wenn HMLAN disconnected.
was steht jetzt im HMLAN? da sind ein paar Performanceindikatoren vorhanden - was sagen die?

schalte einmal die roh-message logs ein und starte apptime. Dann kannst du am nächsten Morgen nachsehen.
Das der Alarm nicht verschwindet ist inerwartet. kannst du einmal mitloggen?

Gruss Martin

Thorsten Pferdekaemper · 25 Januar 2014, 12:15:36

Hi,
klar, das mit den Disconnects kann kaum am Nachbarn liegen, außer er macht was wirklich fieses elektromagnetisches...
Hier ist ein list HMLAN:

Code Auswählen


Internals:
   DEF        192.168.178.152:1000
   DeviceName 192.168.178.152:1000
   FD         11
   HMLAN1_MSGCNT 6079
   HMLAN1_TIME 2014-01-25 12:09:02
   HM_CMDNR   74
   NAME       HMLAN1
   NR         20
   NTFY_ORDER 50-HMLAN1
   PARTIAL    
   RAWMSG     E21F923,0000,0183AA30,FF,FFC4,B2861021F9230000000A90B68F0A22
   RSSI       -60
   STATE      opened
   TYPE       HMLAN
   XmitOpen   1
   assignIDs  21F923,21FBB2
   assignIDsCnt 2
   assignIDsReport 2
   firmware   0.961
   msgKeepAlive dlyMax:1.763 bufferMin:3
   msgLoadEst 1hour:0% 10min steps: 0/0/0/0/0/0
   msgParseDly min:-13 max:4592 last:7 cnt:6049
   owner      23A3F4
   serialNr   KEQ0851839
   uptime     000 07:03:26.000
   Readings:
     2014-01-25 05:06:37   Xmit-Events     ok:1 
     2014-01-25 05:06:37   cond            ok
     2014-01-25 05:05:28   prot_disconnected last
     2014-01-25 05:06:37   prot_init       last
     2014-01-25 05:06:37   prot_ok         last
     2014-01-25 05:05:28   prot_timeout    last
   Helper:
     000001:
       flg        0
       msg        
       to         1390622799.50964
     21f833:
       chn        04
       flg        0
       msg        
       name       og_bd_Heizung
       newChn     +21F833,00,01,
       to         1390591574.01461
     21f923:
       chn        02
       flg        0
       msg        
       name       og_sz_Heizung
       newChn     +21F923,00,01,
       to         1390641759.20265
     21fbb2:
       chn        86
       flg        0
       msg        
       name       og_ku_Heizung
       newChn     +21FBB2,00,01,
       to         1390640806.79842
     23a3f4:
       flg        0
     Dly:
       cnt        6049
       lst        7
       max        4592
       min        -13
     K:
       BufMin     3
       DlyMax     1.763
       Next       1390648160.65423
       Start      1390648135.65423
     Log:
       all        0
       sys        0
       ids:
     Q:
       HMcndN     0
       answerPend 0
       hmLanQlen  1
       keepAliveRec 1
       keepAliveRpt 0
       apIDs:
       Cap:
         0          0
         1          0
         2          0
         3          0
         4          0
         5          0
         last       0
         sum        0
     Ref:
       drft       -0.000159929630962377
       hmtL       25398665
       kTs        0
       offL       1390622736993
       sysL       1390648135658
Attributes:
   hmId       23A3F4
   hmLanQlen  1_min
   logIDs     
   wdTimer    25

Was mir aufgefallen ist: Bei den assignIDs taucht der betreffende RT nicht auf, nur die anderen beiden. Unter "Helper" stehen aber alle drei. Der externe Temperatursensor taucht gar nicht auf.

Mitloggen werde ich erst heute Abend starten.

Gruß,
Thorsten

martinp876 · 25 Januar 2014, 12:40:32

Hi Thorsten,

die IDs werden dem HMLAN (HW) assigned, wenn FHEM etwas über diesen HMLAN an das Device sendet. Bei einem Disconnect ist alles weg, wird ggf wieder neu aufgebaut.
FHEM sendet sicher selten an einen externen temp-sensor - also ist die ID nicht eingetragen.

msgKeepAlive dlyMax:1.763 bufferMin:3
es gab einen delay von 1,7 sec - das sollte noch funktionieren

msgParseDly min:-13 max:4592 last:7 cnt:6049
zumindest einmal musste eine message 4,6sec auf Bearbeitung in FHEM warten... Da waren wir sicher zuspät.

Also kein klarer Anhaltspunkt...
Gruss Martin

Thorsten Pferdekaemper · 25 Januar 2014, 12:52:19

Hi,
jetzt ist noch ein zweiter mit dem Problem dazugekommen. Ich denke mal, da können wir eine Fehlfunktion des einen RT ausschließen. (Oder es liegt an der Firmware, die hat bei beiden dieselbe Version.)
Kann man das msgParseDly irgendwo mitloggen? Die FileLogs wollen ja nur Readings...
Gruß,
Thorsten

martinp876 · 25 Januar 2014, 13:09:20

ZitatKann man das msgParseDly irgendwo mitloggen?

nein, aber man könnte es aus den rohmessages nachrechnen.

Aber ich gehe davon aus, das der RT beleidigt ist, wenn die temp-message an die Zentrale nicht mit einem ACK beantwortet wird.
hm... das könnte etwas sein....

die ACKs werden vom HMLAN, nicht von FHEM gesendet (anders als bei CUL).
Die Acks werden aber nur gesendet, wenn das device "assigned" ist.
Wenn dein HMLAN reseted (warum auch immer) löscht es seine "Assings"
Was assigned ist kann ich nicht auslesen, es wird mitgeschrieben. Was ich sehen kann ist, wieviele IDs assigned sind
assignedIDsCnt 11
assignedIDsReport 11
sollten gleich sein

assignedIDs 2340B9,234548.....
hier sollten deine Heizkörper stehen

Ist da eine diskrepanz? Dann können wir hier einhaken.

Ein device eintragen kannst du einfach dadurch erzwingen, dass du ein Kommando sendest (egal was). Hilft das?

Gruss Martin

Thorsten Pferdekaemper · 25 Januar 2014, 21:37:39

Hi,
also hier ist was der HMLan jetzt sagt:

Code Auswählen


   assignIDs  21F923,21FBB2,21F833
   assignIDsCnt 3
   assignIDsReport 3

Es sind also alle drei Thermostate vorhanden, aber trotzdem beharren zwei darauf, Kommunikationsprobleme zu haben.
Ich habe auf einen jetzt mal ein getConfig gemacht, das gab keine Probleme (im FileLog sieht man die recht längliche Antwort), aber der communicationErr steht immer noch da.
Ich habe jetzt das Logging eingeschaltet. Ich schick' Dir dann morgen das Ergebnis oder sag' mir, nach was ich suchen muss.
Gruß,
Thorsten

Thorsten Pferdekaemper · 26 Januar 2014, 10:02:31

Hi,
das ist schon sehr seltsam. Jetzt haben die Teile entschieden, dass doch alles ok ist. Für mich ist nicht erkennbar, was sich geändert haben soll.
Ich habe mir auch mal die Raw-Messages angeschaut und mit dem verglichen, was in den FileLogs steht. Ich habe die kompletten Raw-Messages hier drangehängt, aber ich denke, dass ich die interessanten Teile gefunden habe:

1. Der RT im Bad (der zuerst mit dem Theater angefangen hat) hat heute morgen zwischen 06:31:09 und 06:33:49 wieder auf "ok" geschaltet. Das ist ziemlich genau 24 Stunden nachdem er auf "communicationERR" gegangen ist (gestern zwischen 06:32:56 und 06:35:31).
Zu der Zeit als das Teil wieder auf "ok" ging, zeigen die Raw-Messages auch nicht die sonst übliche Monotonie, sondern das hier:

Code Auswählen


2014.01.26 06:31:09.330 0: HMLAN_Parse: HMLAN1 R:E21F833   stat:0000 t:0574D113 d:FF r:FFC8     m:2F 8610 21F833 000000 0AB0EC901D28
2014.01.26 06:32:09.213 0: HMLAN_Parse: HMLAN1 R:E21FBB2   stat:0000 t:0575BB07 d:FF r:FFCC     m:85 8610 21FBB2 000000 0AA8CE0F6422
2014.01.26 06:33:25.837 0: HMLAN_Parse: HMLAN1 R:E21F833   stat:0000 t:0576E661 d:FF r:FFC7     m:59 A010 21F833 23A3F4 04000000000007CA0FCB1ECC1C0000
2014.01.26 06:33:49.330 0: HMLAN_Parse: HMLAN1 R:E21F833   stat:0000 t:05774229 d:FF r:FFC8     m:30 8610 21F833 000000 0AB0F0101228

"21F833" ist der RT, um den es hier geht. "23A3F4" ist der HMLan.
Das scheint mir eine etwas speziellere Message zu sein.

2. Der RT im Schlafzimmer (der das Symptom später gezeigt hat) ist heute morgen zwischen 08:01:19 und 08:04:14 auf "ok" gegangen. Bei dem hat's nicht ganz 24h gedauert, er hatte den Fehler seit zwischen 08:38:44 und 08:41:05 (gestern).
Raw-Messages kann ich Dir dazu nicht liefern, da ich das für den nicht eingeschaltet hatte.

3. Ein weitere Ausnahme in den Raw-Messages ist das hier:

Code Auswählen


2014.01.25 21:50:00.699 0: HMLAN_Parse: HMLAN1 R:E21F833   stat:0000 t:0397A088 d:FF r:FFC8     m:61 8610 21F833 000000 0AA0DC900028
2014.01.25 21:51:03.174 0: HMLAN_Parse: HMLAN1 R:E21FBB2   stat:0000 t:03989493 d:FF r:FFCE     m:B7 8610 21FBB2 000000 0AA0D50F0022
2014.01.25 21:51:03.271 0: HMLAN_Send:  HMLAN1 S:SCB2B8514 stat:  00 t:00000000 d:01 r:CB2B8514 m:5A A112 23A3F4 21FBB2 
2014.01.25 21:51:03.628 0: HMLAN_Parse: HMLAN1 R:RCB2B8514 stat:0001 t:039895A4 d:FF r:FFCE     m:5A 8002 21FBB2 23A3F4 00
2014.01.25 21:51:03.678 0: HMLAN_Send:  HMLAN1 S:SCB2B86BE stat:  00 t:00000000 d:01 r:CB2B86BE m:5B A011 23A3F4 21FBB2 86042C
2014.01.25 21:51:03.839 0: HMLAN_Parse: HMLAN1 R:RCB2B86BE stat:0001 t:0398973A d:FF r:FFCE     m:5B 8002 21FBB2 23A3F4 00
2014.01.25 21:52:23.448 0: HMLAN_Parse: HMLAN1 R:E21F833   stat:0000 t:0399CE39 d:FF r:FFC8     m:62 8610 21F833 000000 0AA0DC900028
2014.01.25 21:53:13.418 0: HMLAN_Parse: HMLAN1 R:E21FBB2   stat:0000 t:039A9171 d:FF r:FFCD     m:B8 8610 21FBB2 000000 0AB0D50F6422

Ich glaube, da habe ich ein getConfig gemacht. Das düfte aber wenig mit Punkt 1 und 2 zu tun haben, da zeitlich einfach zu weit weg.

4. Das hier sieht auch interessant aus:

Code Auswählen


2014.01.26 03:49:06.364 0: HMLAN_Parse: HMLAN1 R:E21F833   stat:0000 t:04E06F51 d:FF r:FFC8     m:EF 8610 21F833 000000 0A88C7900028
2014.01.26 03:49:56.870 0: HMLAN_Parse: HMLAN1 R:E21FBB2   stat:0000 t:04E134A2 d:FF r:FFCD     m:45 8610 21FBB2 000000 0AA0CA0F0022
2014.01.26 03:50:41.366 0: HMLAN_Parse: HMLAN1 R:E21FBB2   stat:0000 t:04E1E278 d:FF r:FFCD     m:1F A03F 21FBB2 23A3F4 
2014.01.26 03:50:41.462 0: HMLAN_Send:  HMLAN1 S:+21FBB2,00,01,
2014.01.26 03:50:41.464 0: HMLAN_Send:  HMLAN1 S:SCC74C6A6 stat:  00 t:00000000 d:01 r:CC74C6A6 m:5C 803F 23A3F4 21FBB2 02041A772671
2014.01.26 03:50:41.493 0: HMLAN_Parse: HMLAN1 R:E21FBB2   stat:0000 t:04E1E278 d:FF r:FFCD     m:1F A03F 21FBB2 23A3F4 
2014.01.26 03:50:41.758 0: HMLAN_Parse: HMLAN1 R:RCC74C6A6 stat:0002 t:00000000 d:FF r:7FFF     m:5C 803F 23A3F4 21FBB2 02041A772671
2014.01.26 03:51:29.115 0: HMLAN_Parse: HMLAN1 R:E21F833   stat:0000 t:04E29D03 d:FF r:FFC8     m:F0 8610 21F833 000000 0A88C7900028
2014.01.26 03:52:51.373 0: HMLAN_Parse: HMLAN1 R:E21FBB2   stat:0000 t:04E3DE61 d:FF r:FFCD     m:46 8610 21FBB2 000000 0AA0CA0F0022

Zur selben Zeit im FileLog:

Code Auswählen


2014-01-26_03:50:41 og_ku_Heizung time-request: -

Ich vermute mal, die Heizung in der Küche wollte wissen, wie viel Uhr es ist. Richtig?

5. Einen HMLan disconnect gab es gar nicht. Ich glaube sowieso, dass das mit dem Problem wenig zu tun hat, da die disconnects zeitlich nicht wirklich mit dem Auftreten der communicationERR zusammenfallen.

Gruß,
Thorsten