Ich bin gerade mal wieder dabei rauszufinden, woher meine gelegentlichen Verzögerungen im System kommen. Unter anderem bescheinigt apptime dem Dummy_Set eine Verzögerungen von einer Sekunde:
bd_activity dummy_Set 1074 47 1113 23.68 0 HASH(bd_activity); bd_activity; on
presence dummy_Set 1069 67 1560 23.28 0 HASH(presence); presence; home
Ich bin da etwas ratlos, da Dummy_Set doch eigentlich nix macht außer einen Wert zu setzen. Hat jemand eine Idee, wieso das blockieren könnte?
Mein FHEM läuft einer Ubuntu-VM auf meinem i5 unter Win10. Also ich denke OS-mäßig sollte es da nicht zu Verzögerungen im Sekundenbereich kommen können, oder?
Hier mein vollständiges apptime:
name function max count total average maxDly
wz_xbmc XBMC_Read 2177 694 13920 20.06 0 HASH(wz_xbmc)
nty_wzKodi notify_Exec 2174 231 10293 44.56 0 HASH(nty_wzKodi); HASH(wz_xbmc)
smartlights SMARTLIGHTS_Set 1121 11260 17502 1.55 0 HASH(smartlights); smartlights; submit
tmr-DOIF_SleepTrigger HASH(0x6d5e4a0) 1078 2 1115 557.50 12 HASH(bd_di_detectActivity)
bd_activity dummy_Set 1074 47 1113 23.68 0 HASH(bd_activity); bd_activity; on
sys_di_detectWakeupByBath DOIF_Notify 1072 27507 1107 0.04 0 HASH(sys_di_detectWakeupByBath); HASH(bd_activity)
presence dummy_Set 1069 67 1560 23.28 0 HASH(presence); presence; home
nty_presence notify_Exec 1064 38 1613 42.45 0 HASH(nty_presence); HASH(presence)
tmr-at_Exec HASH(0x9dcf518) 1040 1 1040 1040.00 2 HASH(ku_motionTimer)
HMLAN0 HMLAN_Read 1028 18409 100481 5.46 0 HASH(HMLAN0)
nty_envLuminosity notify_Exec 1016 27507 4963 0.18 0 HASH(nty_envLuminosity); HASH(env_thpl)
wz_lightLedTv WifiLight_Set 601 76 4614 60.71 0 HASH(wz_lightLedTv); wz_lightLedTv; HSV; 144,12,100; 6
ku_lightLedFloor WifiLight_Set 555 105 3990 38.00 0 HASH(ku_lightLedFloor); ku_lightLedFloor; HSV; 144,12,0; 6
ku_lightLedCeil WifiLight_Set 525 90 3830 42.56 0 HASH(ku_lightLedCeil); ku_lightLedCeil; HSV; 144,12,0; 6
wz_lightLedCouch WifiLight_Set 523 76 4420 58.16 0 HASH(wz_lightLedCouch); wz_lightLedCouch; HSV; 144,12,100; 6
tmr-PRESENCE_StartLocalScan HASH(0x62b5e38) 311 4168 23187 5.56 478 HASH(fl_ben)
tmr-SB_PLAYER_GetStatus HASH(0x4b43e28) 251 457 59642 130.51 20 HASH(ku_sb)
tmr-SB_PLAYER_GetStatus HASH(0x4a3a8a0) 250 455 58523 128.62 118 HASH(bd_sb)
nty_buttonSz1 notify_Exec 243 2 424 212.00 0 HASH(nty_buttonSz1); HASH(sz_presenceTaster_Btn1)
sbserver SB_SERVER_Read 228 3810 14483 3.80 0 HASH(sbserver)
tmr-SYSSTAT_GetUpdate HASH(0x6d622d0) 222 1148 38033 33.13 122 HASH(fl_benStats)
Set loest (je nach Modul direkt) ein Event aus. Vmtl. zaehlt apptime die dabei aufgerufenen Funktionen auch mit.
Ahh danke, ja. Das macht irgendwie Sinn.
Das bedeutet dann aber auch, dass apptime Zeiten doppelt zählt. Also in meinem Fall hängen die hier per Event alle hintereinander:
tmr-DOIF_SleepTrigger HASH(0x6d5e4a0) 1078 2 1115 557.50 12 HASH(bd_di_detectActivity)
bd_activity dummy_Set 1074 47 1113 23.68 0 HASH(bd_activity); bd_activity; on
sys_di_detectWakeupByBath DOIF_Notify 1072 27507 1107 0.04 0 HASH(sys_di_detectWakeupByBath); HASH(bd_activity)
presence dummy_Set 1069 67 1560 23.28 0 HASH(presence); presence; home
nty_presence notify_Exec 1064 38 1613 42.45 0 HASH(nty_presence); HASH(presence)
Das läuft bei mir ungefähr so:
bd_di_detectActivity -> bd_activity -> sys_di_detectWakeupByBath -> presence -> nty_presence
Und das Delay >1s taucht dann scheinbar bei allen Instanzen auf.
Besten Dank, das ist sehr wichtig zu wissen für mich!