name function max count total average maxDly
tmr-HUEBridge_GetUpdate HASH(0x1c679e8) 8996 42 22710 540.71 1106 HASH(HUELAN1)
HMLAN1 HMLAN_Read 7330 2108 401863 190.64 0 HASH(HMLAN1)
notifyLichtSceneAbendsHellBtn notify_Exec 6752 1 6752 6752.00 0 HASH(notifyLichtSceneAbendsHellBtn); HASH(HM_3657EB_Btn_04)
lightScenenLicht_Media LightScene_Set 6741 3 8422 2807.33 0 HASH(lightScenenLicht_Media); lightScenenLicht_Media; scene; Twilight_7_WohnzimmerFlur
tmr-watchdog_Trigger HASH(0x25e5650) 5573 1 5573 5573.00 10 HASH(wd_AnniKraussStr_absent)
Macro_AnniKraussStr_absent notify_Exec 5421 1 5421 5421.00 0 HASH(Macro_AnniKraussStr_absent); HASH(Macro_AnniKraussStr_absent)
tmr-watchdog_Trigger HASH(0x25e2098) 5309 1 5309 5309.00 12 HASH(wd_PresenceLocationMarko)
structureVerbraucherWohnung structure_Set 5188 2 5188 2594.00 0 HASH(structureVerbraucherWohnung); structureVerbraucherWohnung; off
rr_Marko ROOMMATE_Set 4743 5 5997 1199.40 0 HASH(rr_Marko); rr_Marko; absent
FHEMWEB:192.168.240.252:43750 FW_Read 4231 5 4315 863.00 0 HASH(FHEMWEB:192.168.240.252:43750)
tmr-Twilight_fireEvent HASH(0x1c66578) 3656 1 3656 3656.00 12 HASH(twilightStahnsdorf_sr_indoor)
doifSetDisplayBrightness DOIF_Notify 3163 2455 3777 1.54 0 HASH(doifSetDisplayBrightness); HASH(twilightStahnsdorf)
notify_rr_InetFWstatus notify_Exec 3117 2455 8631 3.52 0 HASH(notify_rr_InetFWstatus); HASH(rr_Marko)
tmr-statistics_PeriodChange HASH(0x2486660) 2870 4 10262 2565.50 378 HASH(STATISTIKEN)
structureVerbraucherWohnzimmer structure_Set 2468 2 2468 1234.00 0 HASH(structureVerbraucherWohnzimmer); structureVerbraucherWohnzimmer; off
WEBhook FW_Read 2242 6 4493 748.83 0 HASH(WEBhook)
tmr-at_Exec HASH(0x2dc3d50) 2200 7 6872 981.71 11 HASH(atGetDWD_CondWarnMaps)
structureLichtWohnzimmer structure_Set 2168 2 2168 1084.00 0 HASH(structureLichtWohnzimmer); structureLichtWohnzimmer; off
tmr-at_Exec HASH(0x11ca8f0) 2047 1 2047 2047.00 14 HASH(atIsabelHandyFWstatusErlaubtWeek)
buttonIsabelHandyFWstatus dummy_Set 2030 3 2030 676.67 0 HASH(buttonIsabelHandyFWstatus); buttonIsabelHandyFWstatus; erlaubt
notifyFirewall_IsabelHandy notify_Exec 1865 2455 7501 3.06 0 HASH(notifyFirewall_IsabelHandy); HASH(buttonIsabelHandyFWstatus)
Irgenwie habe ich das Gefühl das es hackt. Die Leute sagen doch immer alles über 1000 also eine Sekunde ist kritisch. Ich habe hier nur große Zahlen :-\
Was denkt ihr?
Grüße
Leon
Moin,
schade, ich dachte hinter dem Topic gibt es mehr Informationen ;-) Gibt es hier irgendwo ein Hinweis wie man das Apptime auswertet? Ich sehe da auch nicht so ganz durch. Mein FHEM spielt in letzter Zeit ziemlich verrückt mit zeitkritischen Sachen wie 1-Wire etc. Aber die Werte aus Apptime sagen mir nicht viel.
Wenn ich mal den folgenden Beispiel Auszug nehme:
name function max count total average maxDly avgDly TS Max call param Max call
Nextion01 Nextion_Ready 3000 4440 30280.30 6.82 0.00 0.00 13.10. 08:55:58 HASH(Nextion01)
KODI KODI_Ready 3000 4440 30273.60 6.82 0.00 0.00 13.10. 08:54:59 HASH(KODI)
tmr-OWID_GetValues HASH(0x72bac38) 1598 124 42745.19 344.72 2861.54 247.77 13.10. 09:02:54 HASH(fl_iButton_gelb)
tmr-OWID_GetValues HASH(0x72bb1f0) 1598 124 58474.05 471.56 3006.55 253.01 13.10. 08:56:39 HASH(fl_iButton_blau)
Notify_Schluessel_Anett notify_Exec 1420 16 20955.08 1309.69 0.00 0.00 13.10. 09:02:54 HASH(Notify_Schluessel_Anett); HASH(fl_iButton_gelb)
Notify_Schluessel_Daniel notify_Exec 1420 28 36629.70 1308.20 0.00 0.00 13.10. 08:56:39 HASH(Notify_Schluessel_Daniel); HASH(fl_iButton_blau)
tmr-at_Exec HASH(0x896f0d8) 812 2 1623.02 811.51 884.01 491.15 13.10. 08:56:40 HASH(Timer_ba_Temp_Steuereinheit)
ba_Temp_Steuereinheit ECMDDevice_Set 808 2 1617.11 808.56 0.00 0.00 13.10. 08:56:40 HASH(ba_Temp_Steuereinheit); ba_Temp_Steuereinheit; messen
HMLAN1 HMLAN_Read 499 143 8589.90 60.07 0.00 0.00 13.10. 08:58:05 HASH(HMLAN1)
Was ist denn da das, worauf ich achten muss?
Count = Anzahl der Aufrufe des Moduls?
Total= Gesamtzeit die das aufgerufenen Modul in Anspruch genommen hat?
Average = Durchschnittliche Aufrufzeit des Moduls, also Total/ Count?
MaxDly = Maximale Verzögerung beim Aufruf des Moduls, sprich hier blockiert etwas?
AvgDly = Durchschnittliche Verzögerung beim Aufruf des Moduls, vermutlich eher weniger spannend zur Fehlersuche oder? Auch ein einmaliges MaxDly ist zu viel und bedeutet das etwas unsauber programmiert ist, richtig?
Ist mein Verständnis richtig? Oder muss ich auf noch mehr achten? Und das MaxDly sollte überall unter 1000 sein oder wie? Aber die Aussage ist ja auch schwammig, 30 Module mit 900 sind dann am ende auch reichlich Stillstand oder wie?
Wäre nett wenn mir jemand mehr Licht ins Dunkel bringen könnte.
/Daniel
Ich habe immer nach average sortiert. Probier das mal. War glaube apptime average.
Mhh ok, da ist bei mir alles recht klein, also im 800er Bereich.
Aber woran erkenne ich jetzt ob dieses Modul in ein extra thread ausgelagert ist und nicht blockiert oder ob es eben doch blockiert?
Das ist echt schwer unter FHEM bestimme Verhalten zu untersuchen. Mit zunehmender Anzahl von Geräten passieren komische Sachen bei mir. Ich merke es dann immer an meinen 1Wire iButtons wenn die toggeln. Aber da bin ich schon dran, das wird umgebaut und dann kann ich den rest auch in diesem Async Modus laufen lassen. Man merkt es natürlich auch wenn das Licht 3 Sekunden später angeht als erwartet.
/Daniel
Zitat von: ext23 am 13 Oktober 2018, 09:48:09
Mhh ok, da ist bei mir alles recht klein, also im 800er Bereich.
Aber woran erkenne ich jetzt ob dieses Modul in ein extra thread ausgelagert ist und nicht blockiert oder ob es eben doch blockiert?
Das ist echt schwer unter FHEM bestimme Verhalten zu untersuchen. Mit zunehmender Anzahl von Geräten passieren komische Sachen bei mir. Ich merke es dann immer an meinen 1Wire iButtons wenn die toggeln. Aber da bin ich schon dran, das wird umgebaut und dann kann ich den rest auch in diesem Async Modus laufen lassen. Man merkt es natürlich auch wenn das Licht 3 Sekunden später angeht als erwartet.
/Daniel
Apptime zeigt Dir welche Funktion wie lange laufen und wie oft. Ist also schon mal ein guter Anfang wenn da alles unter 1s also unter 1000 liegt.
Es gibt noch ein weiteres Modul zum testen, mir fällt nur gerade der Name nicht ein. Es schreibt Dir ins Log wenn eine Funktion länger wie die von Dir eingestellte Zeit läuft.
Grüße
ZitatEs gibt noch ein weiteres Modul zum testen, mir fällt nur gerade der Name nicht ein.
freezemon ?
Jepp genau das war es. Vielen Dank Heiko
Super vielen Dank, schau ich mir mal an. Kannte ich noch nicht.
/Daniel
die beiden notify_schlüssel finde ich schon beachtenswert.
während der beobachtungszeit durch apptime haben sie fhem maximal 1,42s blockiert. da der avg wert nicht viel kürzer ist, muss hier bei jedem aufruf eine entsprechende blockade stattfinden. also systematisch, was eventuell vermeidbar ist.
ob das für dein system problematisch ist, kannst nur du entscheiden. gelegentliche freezes, die keine anderen funktionen verzögern, könnte man ja vielleicht beibehalten. allerdings können auch viele kleine freezes hintereinander "unangenehm" werden.
auch können kurze freezes probleme bereiten, wenn sie zu zeiten auftreten, wenn es auf timing ankommt.
bei maxDly/avgDly wurden die funktionen durch fhem verzögert.
Zitat von: frank am 15 Oktober 2018, 16:27:34
bei maxDly/avgDly wurden die funktionen durch fhem verzögert.
Ja das sind genau die blöden 1-Wire iButtons, aber ich hab das jetzt umgebaut, ich hab ein HB-HM Gerät zwischen was die iButtons ausliest und an FHEM schickt, kein polling mehr, keine Hänger...
OK, also ist doch maxDly der interessante Wert auf den man achten sollte.