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)
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
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?
Wie aktuell ist Deine fhem-Installation?
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...
wir sind fast bei 5200 - ein update ist m.E. fällig - dann sehen wir weiter
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!