Alle HM-CC-RT-DN und 1 HM-WDS40-TH-I gleichzeitig mind. 1x am Tag auf dead

Begonnen von rrr, 10 März 2014, 00:23:23

Vorheriges Thema - Nächstes Thema

rrr

Bei mir gehen seit 4 Tagen ca. 1-2x am Tag alle (5 Stück) HM-CC-RT-DN Thermostate sowie 1 
HM-WDS40-TH-I gleichzeitig auf "dead". Ein noch vorhandener HM-SCI-3-FM sowie ein HM-SEC-RHS bleiben jedoch auf "alive".
Erst nach einem FHEM-Neustart funktionieren die Geräte wieder für mind. einen halben Tag.

Als Interface wird ein CUNO jedoch im USB-Modus verwendet.

Wie, gesagt, bis vor ein paar Tagen lief alles problemlos, erst als es draussen wärmer wurde fing das ganze merkwürdigerweise an...

Hier noch eine Ausgabe der Apptime, falls es helfen sollte...

                                name             function    max  count    total  average maxDly
                         tmr-at_Exec      HASH(0x26f2338)   1451    346     3103     8.97      1 HASH(0x26f2338)
                     check_gasburner          notify_Exec   1448    346     2390     6.91      0 HASH(0x26f10e0); HASH(0x26f10e0)
                                CUNO             CUL_Read    266   3504    31338     8.94      0 HASH(0x24903e0)
                  FileLog_ku_Heizung          FileLog_Log    258    579      258     0.45      0 HASH(0x2ce5728); HASH(0x2ce4fa8)
                  FileLog_bz_Heizung          FileLog_Log     90    569      196     0.34      0 HASH(0x2cc27e8); HASH(0x2cc2218)
                   FileLog_wz_Sensor          FileLog_Log     68    579      195     0.34      0 HASH(0x2cefd80); HASH(0x2cef1f8)
            FileLog_wz_Heizung_Couch          FileLog_Log     29    579       29     0.05      0 HASH(0x2cfba90); HASH(0x2cf7d40)
                        modus_change          notify_Exec     22   6769       44     0.01      0 HASH(0x26f04c8); HASH(0x26f04c8)
                  FileLog_gz_Heizung          FileLog_Log     20    580       21     0.04      0 HASH(0x2cdaf50); HASH(0x2cccc10)
                            doorbell          notify_Exec     17   6769       22     0.00      0 HASH(0x2cc0360); HASH(0x278dcb0)
          rz_U_Gastherme_EcoMode           CUL_HM_Set     13     81      153     1.89      0 HASH(0x2cacc20); rz_U_Gastherme_EcoMode; off
                 tmr-CUL_HM_ActCheck       ActionDetector     12    173      162     0.94      1 ActionDetector
                   FileLog_wz_Sensor          FileLog_Get      9     24      102     4.25      0 HASH(0x2cefd80); FileLog_wz_Sensor; CURRENT; INT; 2014-03-08_00:00:00; 2014-03-09_00:00:01; 4:RegExp::
                 check_residencemode          notify_Exec      5   6769     7289     1.08      0 HASH(0x26f0ca8); HASH(0x2cc47a0)
              wz_Heizung_S_ClimRT_tr           CUL_HM_Set      4    575        8     0.01      0 HASH(0x2cf1c58); wz_Heizung_S_ClimRT_tr; controlManu; 17.0
                       n_battery_chk          notify_Exec      3   6769      644     0.10      0 HASH(0x25a8538); HASH(0x2ce4fa8)
          wz_Heizung_Couch_ClimRT_tr           CUL_HM_Set      3    576        5     0.01      0 HASH(0x2cfd130); wz_Heizung_Couch_ClimRT_tr; controlManu; 17.0
         FHEMWEB:192.168.10.21:52580              FW_Read      1      4        2     0.50      0 HASH(0x32ce828)
              FileLog_ActionDetector          FileLog_Get      1     25       15     0.60      0 HASH(0x2d02938); FileLog_ActionDetector; CURRENT; INT; 2014-03-08_00:00:00; 2014-03-09_00:00:01; 4:RegExp::
                              WEBapi              FW_Read      1 100946        1     0.00      0 HASH(0x1da3510)
                             booster          notify_Exec      1      1        1     1.00      0 HASH(0x26f08d0); HASH(0x26f08d0)

martinp876

Hi rrr,

jedes device hat seinen eigenen timeout - je nachdem, wie oft sie sich melden sollen. Ein RT alle maar minuten, ein SC einmal am tag. Schau das Attribut actCycle an, da koenntest du es auch verstellen.
Wenn es also zu einer Unterbrechung kommt (z.B. IO) werden die RTs nach 10 min auf dead gehen, die SCs leben laenger. SDs sogar 3 Tage.

Dein Problem ist evtl, das nichts mehr empfangen wird.
=> wie ist der Zustand des IO device? Status,...
Die Verzoegerungen nach apptime sind nicht bedenklich. Der Fehler liegt anderswo

Gruss Martin

rrr

Hallo Martin,

bei den "dead"-Devices steht der actCycle auf "000:10".

Der Status des IO devices (CUNO) steht auf Initalized. Jedoch ist das letzte Reading von 10:23:54 Uhr . Um 10:32:55 Uhr ging dann eines der RT's auf "dead" und genau 10 min. später die anderen RT's und das WDS40-TH auf "dead".

Es scheint also am IO device zu liegen. Nur wie finde ich heraus was genau schief läuft?

betateilchen

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rrr

Bei mir läuft die "4829 2014-02-07". Es lief aber bis vor ein paar Tagen problemlos, so dass ich das nicht darauf schieben würde...

martinp876

wir sind fast bei 5200 - ein update ist m.E. fällig - dann sehen wir weiter

rrr

Auch wenn ich immer noch rätsel wie ein geschlossenes System, welches kein Update erhalten hat, von heute auf morgen "sowas" macht - seit dem Update auf die Version 5179 läuft es seit einer Woche ohne Probleme.

Vielen Dank für die Hilfe!