Hi zusammen,
ich habe nun auch vermehrt mit freezern zutun.
Aktuell im Minutentakt.
Ich hatte das in der jüngeren Vergangenheit schonmal, da lag es eigtl. immer am HMLAN, nach einem reset waren die freezer weg.
Der HMLAN Adapter ist auf der neuesten FW, ebenso wie FHEM selbst.
apptime bringt folgendes:
name function max count total average maxDly avgDly TS Max call param Max call
tmr-freezemon_ProcessTimer HASH(0x53f23f8) 18 17822 7034.03 0.39 3019.03 42.09 28.11. 14:55:16 HASH(myFreezemon)
tmr-FW_closeInactiveClients 0 3 302 617.52 2.04 3016.41 30.07 28.11. 15:10:16 0
tmr-Shelly_status HASH(0x4043298) 15 302 2772.25 9.18 3010.00 49.65 28.11. 19:12:23 HASH(dg_li)
tmr-Shelly_status HASH(0x4182c68) 12 302 2876.28 9.52 3006.38 47.29 28.11. 16:51:35 HASH(og_fl_li)
tmr-HttpUtils_Err HASH_unnamed 3 82 59.28 0.72 2476.28 201.59 28.11. 16:28:34 HASH(0x5f42a20)
tmr-HMLAN_KeepAlive keepAlive 6 1438 1461.43 1.02 2452.09 22.75 28.11. 19:15:45 keepAlive:HMLAN_AZ
tmr-Unifi_DoUpdate HASH(0x4f36f10) 1 251 328.81 1.31 2389.20 271.98 28.11. 14:58:53 HASH(UnifiController)
tmr-HMLAN_KeepAliveCheck keepAliveCk 135 1459 213.80 0.15 2347.73 61.53 28.11. 14:54:09 keepAliveCk:HMLAN_AZ
tmr-DOIF_SleepTrigger HASH(0x4b774f0) 54 15 635.69 42.38 2333.02 229.62 28.11. 18:23:31 HASH(di_dg_sz_led)
tmr-dnsQuery HASH(0x8d73800) 0 1 0.14 0.14 2225.62 2225.62 28.11. 17:55:39 HASH(DNS)
tmr-echodevice_NPMWaitForCookie HASH(0x27fd090) 13 5 14.71 2.94 2145.70 429.83 28.11. 18:21:39 HASH(amazon)
tmr-BOTVAC::GetStatus HASH(0x3f44ce0) 23 213 4139.75 19.44 2035.73 23.71 28.11. 18:11:12 HASH(yoshi)
tmr-CUL_HM_readStateTo sUpdt 63 9 485.12 53.90 2003.05 231.42 28.11. 17:54:00 sUpdt:eg_wz_rm
Die Elkos des HMLAN sehen von außen iO aus.
Unifi, echo, botvac, shelly und sopotify habe ich schon mal deaktiviert, aber ohne Erfolg :(
Hat noch wer eine Idee?
Danke & Gruß,
Tobi
"attr global mseclog" setzen, und im FHEM-Log nach Zeitspruengen suchen.
Das Problem kann aber auch an anderen Prozessen/OS/Festplatte liegen.
Danke, habe ich mal aktiviert.
2019.11.28 20:10:39 1: [Freezemon] myFreezemon: possible freeze starting at 20:10:38, delay is 1.683 possibly caused by: no bad guy found :-(
2019.11.28 20:11:39 1: [Freezemon] myFreezemon: possible freeze starting at 20:11:38, delay is 1.564 possibly caused by: no bad guy found :-(
2019.11.28 20:12:39 1: [Freezemon] myFreezemon: possible freeze starting at 20:12:38, delay is 1.61 possibly caused by: no bad guy found :-(
2019.11.28 20:13:39 1: [Freezemon] myFreezemon: possible freeze starting at 20:13:38, delay is 1.714 possibly caused by: tmr-HMLAN_KeepAliveCheck(hmusb)
2019.11.28 20:14:39.742 1: [Freezemon] myFreezemon: possible freeze starting at 20:14:38, delay is 1.742 possibly caused by: no bad guy found :-(
2019.11.28 20:15:39.667 1: [Freezemon] myFreezemon: possible freeze starting at 20:15:38, delay is 1.666 possibly caused by: no bad guy found :-(
Bleibt beim Minutentakt.
Ich verwende einen RPi 4, auf dem läuft nichts anderes und den habe ich im Monitoring, der "langeweilt" sich. Gut, theoretisch könnte es natürlich noch an der SD Karte liegen.
Was genau meinst Du mit Zeitsprüngen?
Sorry, habs vergessen zu sagen: freezemon deaktivieren, und "attr global verbose 5" setzen.
Das waere meine praeferierte Methode, es gibt auch Andere, mit anderen Nachteilen :)
Mit "apptime" gestaltet sich die Suche auch sehr gut. Vorgehensweise wurde auch im freezemon-Support-Thread schonmal beschrieben.
Einfach jede Minute "apptime" oder "apptime maxDly" aufrufen und schauen, bei welchem Aufruf der Counter um eines hochgeht.
In der Regel sind es Module, die Status über das Netzwerk abfragen. In der Vergangenheit bei mir xbmc, NUT und ähnliches: Kaum war das überwachte / definierte Gerät nicht mehr im Netz oder runtergefahren, kamen die Hänger - meist im Minutentakt.
Vielleicht hilft es Dir ja.
Besten Dank!
Es war mein Monitoring System. Ich hatte das vor kurzem umgestellt alle devices anzuzeigen um festzustellen welche Umstellungen Auswirkungen auf die Performance haben...[emoji85]