Hallo zusammen,
ich empfinde das aufspüren von "possible freezes" mit Hilfe von PERFMON, ggf. verbose 5 und apptime als extrem umständlich. Daher habe ich auf Basis von PERFMON ein Modul geschnitzt.
(zur Entstehungsgeschichte siehe hier https://forum.fhem.de/index.php/topic,83748.msg760053.html#msg760053)
Bitte beachten! FREEZEMON versucht nur intelligent zu erraten, welches Device einen freeze verursacht haben könnte (basierend auf den Timern die laufen sollten). Es gibt eine Menge anderer Faktoren (intern oder extern) die einen Freeze verursachen können. FREEZEMON ersetzt keine detaillierte Analyse. Das Modul versucht nur Hinweise zu geben, was optimiert werden könnte.
FREEZEMON überwacht - ähnlich wie PERFMON mögliche Freezes, allerdings ist FREEZEMON ein echtes Modul und hat daher:
- Readings - die geloggt werden können und damit viel einfacher ausgewertet werden können
- Attribute - mit denen das Verhalten von freezemon beeinflusst werden kann
- zusätzliche Funktionalität - die versucht das den Freeze verursachende Device zu identifizieren
FREEZEMON ist noch in einem sehr frühen Stadium, läuft bei mir aber seit ein paar Tagen stabil, Daher würde ich mich freuen wenn der ein oder andere sich traut zu testen und Feedback gibt.
Ich würde empfehlen, PERFMON zu deaktivieren, wenn FREEZEMON aktiv ist, da beide auf die selbe Art Freezes erkennen und dann nur alles doppelt kommt.
FREEZEMON wird ohne Parameter definiert.
define myFreezemon freezemondamit ist der Freezemon aktiv (im Log sollte eine entsprechende Meldung geschrieben werden)
Readings (nach dem ersten erkannten Freeze):freezeTime: Dauer des Freezes
freezeDevice: Liste von möglicherweise den Freeze auslösenden Funktionen(Devices)
fcDay: kumulierte Anzahl der Freezes pro Tag
ftDay: kumulierte Dauer der Freezes pro Tag
fcDayLast: speichert die kumulierte Anzahl der Freezes des vergangenen Tages (um tageweise plots zu erstellen)
fcDayLast: speichert die kumulierte Dauer der Freezes des vergangenen Tages (um tageweise plots zu erstellen)
state: s:<StartZeit> e:<EndeZeit>f:<Dauer> d:<Devices>
Attributefm_freezeTime: Wert in Sekunden (Default: 1) - Nur Freezes länger als fmFreezeTime werden als Freeze betrachtet
fm_forceApptime: Wenn FREEZEMON aktiv ist wird automatisch apptime gestartet (falls nicht aktiv)
fm_log: dynamischer Loglevel, nimmt einen String der Form 10:1 5:2 1:3 entgegen, was bedeutet: Freezes > 10 Sekunden werden mit Loglevel 1 geloggt, >5 Sekunden mit Loglevel 2 usw...
disable: aktivieren/deaktivieren der Freeze-Erkennung
Getfreeze: gibt die letzten 20 freezes zurück (in Kompakter Darstellung, wie im state) - Dies dient einem schnellen Überblick, für detailliertere Auswertungen empfehle ich die Daten zu loggen.
Prima Oli.
Mir fehlte noch der Link zu Ursprungspost (https://forum.fhem.de/index.php/topic,83748.0.html), damit neue Nutzer des Moduls vorab ein Gefühl für das Modul bekommen(und gleiche Fragen nicht noch einmal stellen ::))
Grüße Markus
Hat er doch eh oben gepostet:
Zitat(zur Entstehungsgeschichte und letzte Version siehe hier https://forum.fhem.de/index.php/topic,83748.msg760053.html#msg760053)
Moin KernSani,
hab heute morgen ein Update gemacht. Version 0.0.07 ist im svn. Im Changelog steht aber bereits die 0.0.0.8 drin...
Aus der Modulhilfe:
Zitatfm_freezeTime: Wert in Sekunden (Default: 1) - Nur Freezes länger als fmFreezeTime werden als Freeze betrachtet
fmFreezeTime hast Du ja umbenannt in fm_freezeThreshold. Mit fm_freezeThreshold=5 werden troztdem Freezes <=5s als solche gewertet:
freezeTime 2.627 2018-02-06 09:39:02Ist das so gewollt?
VG Sebastian
Hi Stefan, ich Blinder. :-[
Ich kann das Ergebnis von Sebastian nur bestätigen:
freezeTime 1.905
fm_freezeThreshold 4
Zitat von: binford6000 am 06 Februar 2018, 09:48:38
Aus der Modulhilfe:fmFreezeTime hast Du ja umbenannt in fm_freezeThreshold. Mit fm_freezeThreshold=5 werden troztdem Freezes <=5s als solche gewertet:
Vielen Dank für den Hinweis, das ist wohl seit Version 0.0.2 so ???
Fix für das nur teilweise umbenannte Attribut fm_freezeThreshold ist eingecheckt und kommt mit dem morgigen update.
Und die Versionsnummer habe ich diesmal auch aktualisiert ;-)
Hi Oli,
ich habe heute morgen ein Update ausgeführt und nun greift "fm_freezeThreshold" und alles läuft wie erwartet!
Und die Versionsnummer passt auch :D
Was ich noch schick finden würde wären set-Befehle wie:
set SystemFreeze active/inactive
set SystemFreeze reset
"active/inactive" um attr disable 0/1 <save> zu vermeiden und "reset" um alle Readings zurückzusetzen.
Was hältst Du davon? Vielleicht steht das ja sogar schon auf deiner ToDo-List ;)
VG Sebastian
Hallo KernSani,
ist es möglich noch ein Beispiel für die LogFile Konfiguration und eine SVG-Grafik beizufügen, das wäre perfekt.
Vielen Dank für das Module.
lg darkT
Zitat von: binford6000 am 07 Februar 2018, 11:59:37
Hi Oli,
Was ich noch schick finden würde wären set-Befehle wie:
set SystemFreeze active/inactive
set SystemFreeze reset
"active/inactive" um attr disable 0/1 <save> zu vermeiden und "reset" um alle Readings zurückzusetzen.
Was hältst Du davon? Vielleicht steht das ja sogar schon auf deiner ToDo-List ;)
Hi Sebastian,
explizit auf der todo-Liste hatte ich es noch nicht, aber im Hinterkopf war der Gedanke schon. Magst du mal kurz angehängte Version testen? (Neue Set Befehle active, inactive und clear)
Todo: Doku aktualisieren
Grüße,
Oli
Hi Oli,
ZitatMagst du mal kurz angehängte Version testen? (Neue Set Befehle active, inactive und clear)
Klaro: Schon gemacht und keine Fehler festgestellt.
set, get und clear funktionieren wie gewünscht! :D
Um die Anfrage von DarkT aufzugreifen:
Zitatist es möglich noch ein Beispiel für die LogFile Konfiguration und eine SVG-Grafik beizufügen, das wäre perfekt.
Man könnte das Modul ja auch nach der Definition in einen Standard-Raum "Freeze" packen und dort per autocreate
durch dein Modul ein Log- und einen Plot-Device erstellen lassen. Wer es nicht braucht, löscht die devices halt wieder raus. Ist nur so eine Idee...
Ein puristischer (Linux)-Ansatz: Die DEFs der Log- und SVG-Devices in die Modulhilfe oder in einen WIKI-Artikel gepackt.
VG Sebastian
Hallo Oli,
ein kleiner Hinweis meinerseits:
#map new Attribute names
$hash->{AttrRenameMap} = { "fmForceApptime:0,1" => "fm_forceApptime:0,1",
"fmFreezeTime" => "fm_freezeThreshold"
};
Die AttrRenameMap darf nur reine Attributnamen enthalten (ohne Widgets/Wertelisten), da hier nur Attributname alt zu Attributname neu zugeordnet wird. Also bspw. so:
#map new Attribute names
$hash->{AttrRenameMap} = { "fmForceApptime" => "fm_forceApptime",
"fmFreezeTime" => "fm_freezeThreshold"
};
Viele Grüße
Markus
Zitat von: KernSani am 07 Februar 2018, 18:04:56
Todo: Doku aktualisieren
Dort heißt das Attribut "fm_freezeThreshold" auch noch "fm_freezeTime" ;)
Zitat von: Rudy am 07 Februar 2018, 18:58:46
Dort heißt das Attribut "fm_freezeThreshold" auch noch "fm_freezeTime" ;)
Sorry. Tut es doch nicht. :-[ Habe wohl trotz update noch eine alte Version davon laufen. Morgen düfte es dann auch bei mir passen.
Sehr Interessant!
/Mit lese Marker gesetzt/
Zitat von: DarkT am 07 Februar 2018, 12:55:35
ist es möglich noch ein Beispiel für die LogFile Konfiguration und eine SVG-Grafik beizufügen, das wäre perfekt.
Noch was zum testen: Angehängte files nach /www/gplot kopieren
Filelog für das Device anlegen (Annahme: das freezemon Device heisst "freezemon":
define FileLog_freezemon FileLog %L/FileLog_freezemon.log freezemonEinen Plot mit einzelnen Freezes erstellen:
define SVG_FileLog_freezemon SVG FileLog_freezemon:freezemon_gplot:CURRENT
attr SVG_FileLog_freezemon plotReplace TL={"Freezes today: ".$data{max1}." - Longest Freeze ".sprintf("%.2f ",$data{max2}) }
Eine Übersicht über die Freezes der letzten Tage (um genau zu sein des Monats - aber viele Tage können das ja noch nicht sein ;-)):
define SVG_FileLog_freezemon_day SVG FileLog_freezemon:freezemon_day:CURRENT
attr SVG_FileLog_freezemon_day fixedrange month
attr SVG_FileLog_freezemon_day plotReplace TL={"Max Freezes: ".$data{max1}." - Max Freezetime ".sprintf("%.2f ",$data{max2}) }
Edit: Anhänge angehängt :o
Zitat von: Markus Bloch am 07 Februar 2018, 18:48:09
Die AttrRenameMap darf nur reine Attributnamen enthalten (ohne Widgets/Wertelisten), da hier nur Attributname alt zu Attributname neu zugeordnet wird. Also bspw. so:
Danke, Markus. Hab's rausgenommen. Ist wahrscheinlich ohnehin unnötig, da es die alten Attributnamen nur in der allerersten Version gab.
was mach ich jetzt damit ;) :)
2018-02-07_11:03:37 freezemon .fm_freezes: s:11:06:42 e:11:06:43 f:1.083 d:I2C_SUSV_Poll_GPIO(SUSV),s:20:58:01 e:20:58:03 f:2.096 d:I2C_SUSV_Poll_GPIO(SUSV),s:22:06:40 e:22:07:20 f:40.212 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:00:35:01 e:00:35:21 f:20.042 d:I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_U12928654),s:07:01:28 e:07:02:08 f:40.216 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:08:44:54 e:08:44:56 f:2.565 d:I2C_SUSV_Poll_GPIO(SUSV),s:08:47:13 e:08:47:14 f:1.282 d:no bad guy found :-(,s:08:47:23 e:08:47:24 f:1.023 d:I2C_SUSV_Poll_GPIO(SUSV) withings_InitWait(Waage) withings_InitWait(withings_U12928654) withings_InitWait(withings_D4736933) AMADDevice_GetUpdate(WandTabletWohnzimmer),s:11:03:36 e:11:03:37 f:1.061 d:I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_11:03:37 freezemon s:11:03:36 e:11:03:37 f:1.061 d:I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_11:03:37 freezemon freezeTime: 1.061
2018-02-07_11:03:37 freezemon fcDay: 6
2018-02-07_11:03:37 freezemon ftDay: 66.189
2018-02-07_11:03:37 freezemon freezeDevice: I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_12:26:07 freezemon .fm_freezes: s:11:06:42 e:11:06:43 f:1.083 d:I2C_SUSV_Poll_GPIO(SUSV),s:20:58:01 e:20:58:03 f:2.096 d:I2C_SUSV_Poll_GPIO(SUSV),s:22:06:40 e:22:07:20 f:40.212 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:00:35:01 e:00:35:21 f:20.042 d:I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_U12928654),s:07:01:28 e:07:02:08 f:40.216 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:08:44:54 e:08:44:56 f:2.565 d:I2C_SUSV_Poll_GPIO(SUSV),s:08:47:13 e:08:47:14 f:1.282 d:no bad guy found :-(,s:08:47:23 e:08:47:24 f:1.023 d:I2C_SUSV_Poll_GPIO(SUSV) withings_InitWait(Waage) withings_InitWait(withings_U12928654) withings_InitWait(withings_D4736933) AMADDevice_GetUpdate(WandTabletWohnzimmer),s:11:03:36 e:11:03:37 f:1.061 d:I2C_SUSV_Poll_GPIO(SUSV),s:12:26:06 e:12:26:07 f:1.168 d:I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_12:26:07 freezemon s:12:26:06 e:12:26:07 f:1.168 d:I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_12:26:07 freezemon freezeTime: 1.168
2018-02-07_12:26:07 freezemon fcDay: 7
2018-02-07_12:26:07 freezemon ftDay: 67.357
2018-02-07_12:26:07 freezemon freezeDevice: I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_13:19:49 freezemon .fm_freezes: s:11:06:42 e:11:06:43 f:1.083 d:I2C_SUSV_Poll_GPIO(SUSV),s:20:58:01 e:20:58:03 f:2.096 d:I2C_SUSV_Poll_GPIO(SUSV),s:22:06:40 e:22:07:20 f:40.212 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:00:35:01 e:00:35:21 f:20.042 d:I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_U12928654),s:07:01:28 e:07:02:08 f:40.216 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:08:44:54 e:08:44:56 f:2.565 d:I2C_SUSV_Poll_GPIO(SUSV),s:08:47:13 e:08:47:14 f:1.282 d:no bad guy found :-(,s:08:47:23 e:08:47:24 f:1.023 d:I2C_SUSV_Poll_GPIO(SUSV) withings_InitWait(Waage) withings_InitWait(withings_U12928654) withings_InitWait(withings_D4736933) AMADDevice_GetUpdate(WandTabletWohnzimmer),s:11:03:36 e:11:03:37 f:1.061 d:I2C_SUSV_Poll_GPIO(SUSV),s:12:26:06 e:12:26:07 f:1.168 d:I2C_SUSV_Poll_GPIO(SUSV),s:13:19:47 e:13:19:49 f:2.014 d:I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_13:19:49 freezemon s:13:19:47 e:13:19:49 f:2.014 d:I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_13:19:49 freezemon freezeTime: 2.014
2018-02-07_13:19:49 freezemon fcDay: 8
2018-02-07_13:19:49 freezemon ftDay: 69.371
2018-02-07_13:19:49 freezemon freezeDevice: I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_14:20:23 freezemon .fm_freezes: s:11:06:42 e:11:06:43 f:1.083 d:I2C_SUSV_Poll_GPIO(SUSV),s:20:58:01 e:20:58:03 f:2.096 d:I2C_SUSV_Poll_GPIO(SUSV),s:22:06:40 e:22:07:20 f:40.212 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:00:35:01 e:00:35:21 f:20.042 d:I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_U12928654),s:07:01:28 e:07:02:08 f:40.216 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:08:44:54 e:08:44:56 f:2.565 d:I2C_SUSV_Poll_GPIO(SUSV),s:08:47:13 e:08:47:14 f:1.282 d:no bad guy found :-(,s:08:47:23 e:08:47:24 f:1.023 d:I2C_SUSV_Poll_GPIO(SUSV) withings_InitWait(Waage) withings_InitWait(withings_U12928654) withings_InitWait(withings_D4736933) AMADDevice_GetUpdate(WandTabletWohnzimmer),s:11:03:36 e:11:03:37 f:1.061 d:I2C_SUSV_Poll_GPIO(SUSV),s:12:26:06 e:12:26:07 f:1.168 d:I2C_SUSV_Poll_GPIO(SUSV),s:13:19:47 e:13:19:49 f:2.014 d:I2C_SUSV_Poll_GPIO(SUSV),s:14:20:21 e:14:20:23 f:2.816 d:HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_14:20:23 freezemon s:14:20:21 e:14:20:23 f:2.816 d:HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_14:20:23 freezemon freezeTime: 2.816
2018-02-07_14:20:23 freezemon fcDay: 9
2018-02-07_14:20:23 freezemon ftDay: 72.187
2018-02-07_14:20:23 freezemon freezeDevice: HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_14:29:38 freezemon .fm_freezes: s:11:06:42 e:11:06:43 f:1.083 d:I2C_SUSV_Poll_GPIO(SUSV),s:20:58:01 e:20:58:03 f:2.096 d:I2C_SUSV_Poll_GPIO(SUSV),s:22:06:40 e:22:07:20 f:40.212 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:00:35:01 e:00:35:21 f:20.042 d:I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_U12928654),s:07:01:28 e:07:02:08 f:40.216 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:08:44:54 e:08:44:56 f:2.565 d:I2C_SUSV_Poll_GPIO(SUSV),s:08:47:13 e:08:47:14 f:1.282 d:no bad guy found :-(,s:08:47:23 e:08:47:24 f:1.023 d:I2C_SUSV_Poll_GPIO(SUSV) withings_InitWait(Waage) withings_InitWait(withings_U12928654) withings_InitWait(withings_D4736933) AMADDevice_GetUpdate(WandTabletWohnzimmer),s:11:03:36 e:11:03:37 f:1.061 d:I2C_SUSV_Poll_GPIO(SUSV),s:12:26:06 e:12:26:07 f:1.168 d:I2C_SUSV_Poll_GPIO(SUSV),s:13:19:47 e:13:19:49 f:2.014 d:I2C_SUSV_Poll_GPIO(SUSV),s:14:20:21 e:14:20:23 f:2.816 d:HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:14:29:37 e:14:29:38 f:1.789 d:I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_14:29:38 freezemon s:14:29:37 e:14:29:38 f:1.789 d:I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_14:29:38 freezemon freezeTime: 1.789
2018-02-07_14:29:38 freezemon fcDay: 10
2018-02-07_14:29:38 freezemon ftDay: 73.976
2018-02-07_14:29:38 freezemon freezeDevice: I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_15:41:15 freezemon .fm_freezes: s:11:06:42 e:11:06:43 f:1.083 d:I2C_SUSV_Poll_GPIO(SUSV),s:20:58:01 e:20:58:03 f:2.096 d:I2C_SUSV_Poll_GPIO(SUSV),s:22:06:40 e:22:07:20 f:40.212 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:00:35:01 e:00:35:21 f:20.042 d:I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_U12928654),s:07:01:28 e:07:02:08 f:40.216 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:08:44:54 e:08:44:56 f:2.565 d:I2C_SUSV_Poll_GPIO(SUSV),s:08:47:13 e:08:47:14 f:1.282 d:no bad guy found :-(,s:08:47:23 e:08:47:24 f:1.023 d:I2C_SUSV_Poll_GPIO(SUSV) withings_InitWait(Waage) withings_InitWait(withings_U12928654) withings_InitWait(withings_D4736933) AMADDevice_GetUpdate(WandTabletWohnzimmer),s:11:03:36 e:11:03:37 f:1.061 d:I2C_SUSV_Poll_GPIO(SUSV),s:12:26:06 e:12:26:07 f:1.168 d:I2C_SUSV_Poll_GPIO(SUSV),s:13:19:47 e:13:19:49 f:2.014 d:I2C_SUSV_Poll_GPIO(SUSV),s:14:20:21 e:14:20:23 f:2.816 d:HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:14:29:37 e:14:29:38 f:1.789 d:I2C_SUSV_Poll_GPIO(SUSV),s:15:41:10 e:15:41:15 f:5.391 d:I2C_SUSV_Poll_GPIO(SUSV) I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits)
2018-02-07_15:41:15 freezemon s:15:41:10 e:15:41:15 f:5.391 d:I2C_SUSV_Poll_GPIO(SUSV) I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits)
2018-02-07_15:41:15 freezemon freezeTime: 5.391
2018-02-07_15:41:15 freezemon fcDay: 11
2018-02-07_15:41:15 freezemon ftDay: 79.367
2018-02-07_15:41:15 freezemon freezeDevice: I2C_SUSV_Poll_GPIO(SUSV) I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits)
2018-02-07_15:54:56 freezemon .fm_freezes: s:11:06:42 e:11:06:43 f:1.083 d:I2C_SUSV_Poll_GPIO(SUSV),s:20:58:01 e:20:58:03 f:2.096 d:I2C_SUSV_Poll_GPIO(SUSV),s:22:06:40 e:22:07:20 f:40.212 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:00:35:01 e:00:35:21 f:20.042 d:I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_U12928654),s:07:01:28 e:07:02:08 f:40.216 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:08:44:54 e:08:44:56 f:2.565 d:I2C_SUSV_Poll_GPIO(SUSV),s:08:47:13 e:08:47:14 f:1.282 d:no bad guy found :-(,s:08:47:23 e:08:47:24 f:1.023 d:I2C_SUSV_Poll_GPIO(SUSV) withings_InitWait(Waage) withings_InitWait(withings_U12928654) withings_InitWait(withings_D4736933) AMADDevice_GetUpdate(WandTabletWohnzimmer),s:11:03:36 e:11:03:37 f:1.061 d:I2C_SUSV_Poll_GPIO(SUSV),s:12:26:06 e:12:26:07 f:1.168 d:I2C_SUSV_Poll_GPIO(SUSV),s:13:19:47 e:13:19:49 f:2.014 d:I2C_SUSV_Poll_GPIO(SUSV),s:14:20:21 e:14:20:23 f:2.816 d:HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:14:29:37 e:14:29:38 f:1.789 d:I2C_SUSV_Poll_GPIO(SUSV),s:15:41:10 e:15:41:15 f:5.391 d:I2C_SUSV_Poll_GPIO(SUSV) I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits),s:15:54:16 e:15:54:56 f:40.227 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) I2C_SUSV_Poll_GPIO(SUSV) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits)
2018-02-07_15:54:56 freezemon s:15:54:16 e:15:54:56 f:40.227 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) I2C_SUSV_Poll_GPIO(SUSV) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits)
2018-02-07_15:54:56 freezemon freezeTime: 40.227
2018-02-07_15:54:56 freezemon fcDay: 12
2018-02-07_15:54:56 freezemon ftDay: 119.594
2018-02-07_15:54:56 freezemon freezeDevice: I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) I2C_SUSV_Poll_GPIO(SUSV) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits)
2018-02-07_16:16:44 freezemon .fm_freezes: s:11:06:42 e:11:06:43 f:1.083 d:I2C_SUSV_Poll_GPIO(SUSV),s:20:58:01 e:20:58:03 f:2.096 d:I2C_SUSV_Poll_GPIO(SUSV),s:22:06:40 e:22:07:20 f:40.212 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:00:35:01 e:00:35:21 f:20.042 d:I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_U12928654),s:07:01:28 e:07:02:08 f:40.216 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:08:44:54 e:08:44:56 f:2.565 d:I2C_SUSV_Poll_GPIO(SUSV),s:08:47:13 e:08:47:14 f:1.282 d:no bad guy found :-(,s:08:47:23 e:08:47:24 f:1.023 d:I2C_SUSV_Poll_GPIO(SUSV) withings_InitWait(Waage) withings_InitWait(withings_U12928654) withings_InitWait(withings_D4736933) AMADDevice_GetUpdate(WandTabletWohnzimmer),s:11:03:36 e:11:03:37 f:1.061 d:I2C_SUSV_Poll_GPIO(SUSV),s:12:26:06 e:12:26:07 f:1.168 d:I2C_SUSV_Poll_GPIO(SUSV),s:13:19:47 e:13:19:49 f:2.014 d:I2C_SUSV_Poll_GPIO(SUSV),s:14:20:21 e:14:20:23 f:2.816 d:HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:14:29:37 e:14:29:38 f:1.789 d:I2C_SUSV_Poll_GPIO(SUSV),s:15:41:10 e:15:41:15 f:5.391 d:I2C_SUSV_Poll_GPIO(SUSV) I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits),s:15:54:16 e:15:54:56 f:40.227 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) I2C_SUSV_Poll_GPIO(SUSV) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits),s:16:16:43 e:16:16:44 f:1.164 d:I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_16:16:44 freezemon s:16:16:43 e:16:16:44 f:1.164 d:I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_16:16:44 freezemon freezeTime: 1.164
2018-02-07_16:16:44 freezemon fcDay: 13
2018-02-07_16:16:44 freezemon ftDay: 120.758
2018-02-07_16:16:44 freezemon freezeDevice: I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_19:45:29 freezemon .fm_freezes: s:11:06:42 e:11:06:43 f:1.083 d:I2C_SUSV_Poll_GPIO(SUSV),s:20:58:01 e:20:58:03 f:2.096 d:I2C_SUSV_Poll_GPIO(SUSV),s:22:06:40 e:22:07:20 f:40.212 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:00:35:01 e:00:35:21 f:20.042 d:I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_U12928654),s:07:01:28 e:07:02:08 f:40.216 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:08:44:54 e:08:44:56 f:2.565 d:I2C_SUSV_Poll_GPIO(SUSV),s:08:47:13 e:08:47:14 f:1.282 d:no bad guy found :-(,s:08:47:23 e:08:47:24 f:1.023 d:I2C_SUSV_Poll_GPIO(SUSV) withings_InitWait(Waage) withings_InitWait(withings_U12928654) withings_InitWait(withings_D4736933) AMADDevice_GetUpdate(WandTabletWohnzimmer),s:11:03:36 e:11:03:37 f:1.061 d:I2C_SUSV_Poll_GPIO(SUSV),s:12:26:06 e:12:26:07 f:1.168 d:I2C_SUSV_Poll_GPIO(SUSV),s:13:19:47 e:13:19:49 f:2.014 d:I2C_SUSV_Poll_GPIO(SUSV),s:14:20:21 e:14:20:23 f:2.816 d:HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:14:29:37 e:14:29:38 f:1.789 d:I2C_SUSV_Poll_GPIO(SUSV),s:15:41:10 e:15:41:15 f:5.391 d:I2C_SUSV_Poll_GPIO(SUSV) I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits),s:15:54:16 e:15:54:56 f:40.227 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) I2C_SUSV_Poll_GPIO(SUSV) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits),s:16:16:43 e:16:16:44 f:1.164 d:I2C_SUSV_Poll_GPIO(SUSV),s:19:44:54 e:19:45:29 f:35.378 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_19:45:29 freezemon s:19:44:54 e:19:45:29 f:35.378 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_19:45:29 freezemon freezeTime: 35.378
2018-02-07_19:45:29 freezemon fcDay: 14
2018-02-07_19:45:29 freezemon ftDay: 156.136
2018-02-07_19:45:29 freezemon freezeDevice: I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_20:57:34 freezemon .fm_freezes: s:11:06:42 e:11:06:43 f:1.083 d:I2C_SUSV_Poll_GPIO(SUSV),s:20:58:01 e:20:58:03 f:2.096 d:I2C_SUSV_Poll_GPIO(SUSV),s:22:06:40 e:22:07:20 f:40.212 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:00:35:01 e:00:35:21 f:20.042 d:I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_U12928654),s:07:01:28 e:07:02:08 f:40.216 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:08:44:54 e:08:44:56 f:2.565 d:I2C_SUSV_Poll_GPIO(SUSV),s:08:47:13 e:08:47:14 f:1.282 d:no bad guy found :-(,s:08:47:23 e:08:47:24 f:1.023 d:I2C_SUSV_Poll_GPIO(SUSV) withings_InitWait(Waage) withings_InitWait(withings_U12928654) withings_InitWait(withings_D4736933) AMADDevice_GetUpdate(WandTabletWohnzimmer),s:11:03:36 e:11:03:37 f:1.061 d:I2C_SUSV_Poll_GPIO(SUSV),s:12:26:06 e:12:26:07 f:1.168 d:I2C_SUSV_Poll_GPIO(SUSV),s:13:19:47 e:13:19:49 f:2.014 d:I2C_SUSV_Poll_GPIO(SUSV),s:14:20:21 e:14:20:23 f:2.816 d:HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:14:29:37 e:14:29:38 f:1.789 d:I2C_SUSV_Poll_GPIO(SUSV),s:15:41:10 e:15:41:15 f:5.391 d:I2C_SUSV_Poll_GPIO(SUSV) I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits),s:15:54:16 e:15:54:56 f:40.227 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) I2C_SUSV_Poll_GPIO(SUSV) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits),s:16:16:43 e:16:16:44 f:1.164 d:I2C_SUSV_Poll_GPIO(SUSV),s:19:44:54 e:19:45:29 f:35.378 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:20:57:15 e:20:57:34 f:19.524 d:I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_D4736933)
2018-02-07_20:57:34 freezemon s:20:57:15 e:20:57:34 f:19.524 d:I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_D4736933)
2018-02-07_20:57:34 freezemon freezeTime: 19.524
2018-02-07_20:57:34 freezemon fcDay: 15
2018-02-07_20:57:34 freezemon ftDay: 175.66
2018-02-07_20:57:34 freezemon freezeDevice: I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_D4736933)
2018-02-07_20:57:55 freezemon .fm_freezes: s:11:06:42 e:11:06:43 f:1.083 d:I2C_SUSV_Poll_GPIO(SUSV),s:20:58:01 e:20:58:03 f:2.096 d:I2C_SUSV_Poll_GPIO(SUSV),s:22:06:40 e:22:07:20 f:40.212 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:00:35:01 e:00:35:21 f:20.042 d:I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_U12928654),s:07:01:28 e:07:02:08 f:40.216 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:08:44:54 e:08:44:56 f:2.565 d:I2C_SUSV_Poll_GPIO(SUSV),s:08:47:13 e:08:47:14 f:1.282 d:no bad guy found :-(,s:08:47:23 e:08:47:24 f:1.023 d:I2C_SUSV_Poll_GPIO(SUSV) withings_InitWait(Waage) withings_InitWait(withings_U12928654) withings_InitWait(withings_D4736933) AMADDevice_GetUpdate(WandTabletWohnzimmer),s:11:03:36 e:11:03:37 f:1.061 d:I2C_SUSV_Poll_GPIO(SUSV),s:12:26:06 e:12:26:07 f:1.168 d:I2C_SUSV_Poll_GPIO(SUSV),s:13:19:47 e:13:19:49 f:2.014 d:I2C_SUSV_Poll_GPIO(SUSV),s:14:20:21 e:14:20:23 f:2.816 d:HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:14:29:37 e:14:29:38 f:1.789 d:I2C_SUSV_Poll_GPIO(SUSV),s:15:41:10 e:15:41:15 f:5.391 d:I2C_SUSV_Poll_GPIO(SUSV) I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits),s:15:54:16 e:15:54:56 f:40.227 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) I2C_SUSV_Poll_GPIO(SUSV) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits),s:16:16:43 e:16:16:44 f:1.164 d:I2C_SUSV_Poll_GPIO(SUSV),s:19:44:54 e:19:45:29 f:35.378 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:20:57:15 e:20:57:34 f:19.524 d:I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_D4736933),s:20:57:35 e:20:57:55 f:20.138 d:I2C_SUSV_Poll_GPIO(SUSV) FRITZBOX_Readout_Start(Fritzbox.Readout) I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) FW_closeInactiveClients(0) withings_poll(withings_U12928654)
2018-02-07_20:57:55 freezemon s:20:57:35 e:20:57:55 f:20.138 d:I2C_SUSV_Poll_GPIO(SUSV) FRITZBOX_Readout_Start(Fritzbox.Readout) I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) FW_closeInactiveClients(0) withings_poll(withings_U12928654)
2018-02-07_20:57:55 freezemon freezeTime: 20.138
2018-02-07_20:57:55 freezemon fcDay: 16
2018-02-07_20:57:55 freezemon ftDay: 195.798
2018-02-07_20:57:55 freezemon freezeDevice: I2C_SUSV_Poll_GPIO(SUSV) FRITZBOX_Readout_Start(Fritzbox.Readout) I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) FW_closeInactiveClients(0) withings_poll(withings_U12928654)
2018-02-07_21:15:32 freezemon .fm_freezes: s:11:06:42 e:11:06:43 f:1.083 d:I2C_SUSV_Poll_GPIO(SUSV),s:20:58:01 e:20:58:03 f:2.096 d:I2C_SUSV_Poll_GPIO(SUSV),s:22:06:40 e:22:07:20 f:40.212 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:00:35:01 e:00:35:21 f:20.042 d:I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_U12928654),s:07:01:28 e:07:02:08 f:40.216 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:08:44:54 e:08:44:56 f:2.565 d:I2C_SUSV_Poll_GPIO(SUSV),s:08:47:13 e:08:47:14 f:1.282 d:no bad guy found :-(,s:08:47:23 e:08:47:24 f:1.023 d:I2C_SUSV_Poll_GPIO(SUSV) withings_InitWait(Waage) withings_InitWait(withings_U12928654) withings_InitWait(withings_D4736933) AMADDevice_GetUpdate(WandTabletWohnzimmer),s:11:03:36 e:11:03:37 f:1.061 d:I2C_SUSV_Poll_GPIO(SUSV),s:12:26:06 e:12:26:07 f:1.168 d:I2C_SUSV_Poll_GPIO(SUSV),s:13:19:47 e:13:19:49 f:2.014 d:I2C_SUSV_Poll_GPIO(SUSV),s:14:20:21 e:14:20:23 f:2.816 d:HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:14:29:37 e:14:29:38 f:1.789 d:I2C_SUSV_Poll_GPIO(SUSV),s:15:41:10 e:15:41:15 f:5.391 d:I2C_SUSV_Poll_GPIO(SUSV) I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits),s:15:54:16 e:15:54:56 f:40.227 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) I2C_SUSV_Poll_GPIO(SUSV) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits),s:16:16:43 e:16:16:44 f:1.164 d:I2C_SUSV_Poll_GPIO(SUSV),s:19:44:54 e:19:45:29 f:35.378 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:20:57:15 e:20:57:34 f:19.524 d:I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_D4736933),s:20:57:35 e:20:57:55 f:20.138 d:I2C_SUSV_Poll_GPIO(SUSV) FRITZBOX_Readout_Start(Fritzbox.Readout) I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) FW_closeInactiveClients(0) withings_poll(withings_U12928654),s:21:15:31 e:21:15:32 f:1.39 d:I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_21:15:32 freezemon s:21:15:31 e:21:15:32 f:1.39 d:I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_21:15:32 freezemon freezeTime: 1.39
2018-02-07_21:15:32 freezemon fcDay: 17
2018-02-07_21:15:32 freezemon ftDay: 197.188
2018-02-07_21:15:32 freezemon freezeDevice: I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_21:45:08 freezemon .fm_freezes: s:20:58:01 e:20:58:03 f:2.096 d:I2C_SUSV_Poll_GPIO(SUSV),s:22:06:40 e:22:07:20 f:40.212 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:00:35:01 e:00:35:21 f:20.042 d:I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_U12928654),s:07:01:28 e:07:02:08 f:40.216 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:08:44:54 e:08:44:56 f:2.565 d:I2C_SUSV_Poll_GPIO(SUSV),s:08:47:13 e:08:47:14 f:1.282 d:no bad guy found :-(,s:08:47:23 e:08:47:24 f:1.023 d:I2C_SUSV_Poll_GPIO(SUSV) withings_InitWait(Waage) withings_InitWait(withings_U12928654) withings_InitWait(withings_D4736933) AMADDevice_GetUpdate(WandTabletWohnzimmer),s:11:03:36 e:11:03:37 f:1.061 d:I2C_SUSV_Poll_GPIO(SUSV),s:12:26:06 e:12:26:07 f:1.168 d:I2C_SUSV_Poll_GPIO(SUSV),s:13:19:47 e:13:19:49 f:2.014 d:I2C_SUSV_Poll_GPIO(SUSV),s:14:20:21 e:14:20:23 f:2.816 d:HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:14:29:37 e:14:29:38 f:1.789 d:I2C_SUSV_Poll_GPIO(SUSV),s:15:41:10 e:15:41:15 f:5.391 d:I2C_SUSV_Poll_GPIO(SUSV) I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits),s:15:54:16 e:15:54:56 f:40.227 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) I2C_SUSV_Poll_GPIO(SUSV) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits),s:16:16:43 e:16:16:44 f:1.164 d:I2C_SUSV_Poll_GPIO(SUSV),s:19:44:54 e:19:45:29 f:35.378 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:20:57:15 e:20:57:34 f:19.524 d:I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_D4736933),s:20:57:35 e:20:57:55 f:20.138 d:I2C_SUSV_Poll_GPIO(SUSV) FRITZBOX_Readout_Start(Fritzbox.Readout) I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) FW_closeInactiveClients(0) withings_poll(withings_U12928654),s:21:15:31 e:21:15:32 f:1.39 d:I2C_SUSV_Poll_GPIO(SUSV),s:21:45:07 e:21:45:08 f:1.019 d:at_Exec(atTraffic) I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_21:45:08 freezemon s:21:45:07 e:21:45:08 f:1.019 d:at_Exec(atTraffic) I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_21:45:08 freezemon freezeTime: 1.019
2018-02-07_21:45:08 freezemon fcDay: 18
2018-02-07_21:45:08 freezemon ftDay: 198.207
2018-02-07_21:45:08 freezemon freezeDevice: at_Exec(atTraffic) I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_23:04:55 freezemon .fm_freezes: s:22:06:40 e:22:07:20 f:40.212 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:00:35:01 e:00:35:21 f:20.042 d:I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_U12928654),s:07:01:28 e:07:02:08 f:40.216 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:08:44:54 e:08:44:56 f:2.565 d:I2C_SUSV_Poll_GPIO(SUSV),s:08:47:13 e:08:47:14 f:1.282 d:no bad guy found :-(,s:08:47:23 e:08:47:24 f:1.023 d:I2C_SUSV_Poll_GPIO(SUSV) withings_InitWait(Waage) withings_InitWait(withings_U12928654) withings_InitWait(withings_D4736933) AMADDevice_GetUpdate(WandTabletWohnzimmer),s:11:03:36 e:11:03:37 f:1.061 d:I2C_SUSV_Poll_GPIO(SUSV),s:12:26:06 e:12:26:07 f:1.168 d:I2C_SUSV_Poll_GPIO(SUSV),s:13:19:47 e:13:19:49 f:2.014 d:I2C_SUSV_Poll_GPIO(SUSV),s:14:20:21 e:14:20:23 f:2.816 d:HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:14:29:37 e:14:29:38 f:1.789 d:I2C_SUSV_Poll_GPIO(SUSV),s:15:41:10 e:15:41:15 f:5.391 d:I2C_SUSV_Poll_GPIO(SUSV) I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits),s:15:54:16 e:15:54:56 f:40.227 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) I2C_SUSV_Poll_GPIO(SUSV) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits),s:16:16:43 e:16:16:44 f:1.164 d:I2C_SUSV_Poll_GPIO(SUSV),s:19:44:54 e:19:45:29 f:35.378 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:20:57:15 e:20:57:34 f:19.524 d:I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_D4736933),s:20:57:35 e:20:57:55 f:20.138 d:I2C_SUSV_Poll_GPIO(SUSV) FRITZBOX_Readout_Start(Fritzbox.Readout) I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) FW_closeInactiveClients(0) withings_poll(withings_U12928654),s:21:15:31 e:21:15:32 f:1.39 d:I2C_SUSV_Poll_GPIO(SUSV),s:21:45:07 e:21:45:08 f:1.019 d:at_Exec(atTraffic) I2C_SUSV_Poll_GPIO(SUSV),s:23:04:36 e:23:04:55 f:19.267 d:withings_poll(withings_D4736933) I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_23:04:55 freezemon s:23:04:36 e:23:04:55 f:19.267 d:withings_poll(withings_D4736933) I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_23:04:55 freezemon freezeTime: 19.267
2018-02-07_23:04:55 freezemon fcDay: 19
2018-02-07_23:04:55 freezemon ftDay: 217.474
2018-02-07_23:04:55 freezemon freezeDevice: withings_poll(withings_D4736933) I2C_SUSV_Poll_GPIO(SUSV)
2018-02-07_23:05:16 freezemon .fm_freezes: s:00:35:01 e:00:35:21 f:20.042 d:I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_U12928654),s:07:01:28 e:07:02:08 f:40.216 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:08:44:54 e:08:44:56 f:2.565 d:I2C_SUSV_Poll_GPIO(SUSV),s:08:47:13 e:08:47:14 f:1.282 d:no bad guy found :-(,s:08:47:23 e:08:47:24 f:1.023 d:I2C_SUSV_Poll_GPIO(SUSV) withings_InitWait(Waage) withings_InitWait(withings_U12928654) withings_InitWait(withings_D4736933) AMADDevice_GetUpdate(WandTabletWohnzimmer),s:11:03:36 e:11:03:37 f:1.061 d:I2C_SUSV_Poll_GPIO(SUSV),s:12:26:06 e:12:26:07 f:1.168 d:I2C_SUSV_Poll_GPIO(SUSV),s:13:19:47 e:13:19:49 f:2.014 d:I2C_SUSV_Poll_GPIO(SUSV),s:14:20:21 e:14:20:23 f:2.816 d:HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:14:29:37 e:14:29:38 f:1.789 d:I2C_SUSV_Poll_GPIO(SUSV),s:15:41:10 e:15:41:15 f:5.391 d:I2C_SUSV_Poll_GPIO(SUSV) I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits),s:15:54:16 e:15:54:56 f:40.227 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_U12928654) withings_poll(withings_D4736933) LaCrosseGateway_OnConnectTimer(WlanJeeLink) I2C_SUSV_Poll_GPIO(SUSV) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits),s:16:16:43 e:16:16:44 f:1.164 d:I2C_SUSV_Poll_GPIO(SUSV),s:19:44:54 e:19:45:29 f:35.378 d:I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) withings_poll(withings_D4736933) withings_poll(withings_U12928654) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) I2C_SUSV_Poll_GPIO(SUSV),s:20:57:15 e:20:57:34 f:19.524 d:I2C_SUSV_Poll_GPIO(SUSV) withings_poll(withings_D4736933),s:20:57:35 e:20:57:55 f:20.138 d:I2C_SUSV_Poll_GPIO(SUSV) FRITZBOX_Readout_Start(Fritzbox.Readout) I2C_SUSV_Poll(SUSV) SIGNALduino_KeepAlive(Signal_Stick) LaCrosseGateway_OnConnectTimer(WlanJeeLink) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) FW_closeInactiveClients(0) withings_poll(withings_U12928654),s:21:15:31 e:21:15:32 f:1.39 d:I2C_SUSV_Poll_GPIO(SUSV),s:21:45:07 e:21:45:08 f:1.019 d:at_Exec(atTraffic) I2C_SUSV_Poll_GPIO(SUSV),s:23:04:36 e:23:04:55 f:19.267 d:withings_poll(withings_D4736933) I2C_SUSV_Poll_GPIO(SUSV),s:23:04:56 e:23:05:16 f:20.163 d:BlockingKill(N/A) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) PRESENCE_StartLocalScan(WernerS4) withings_poll(withings_U12928654)
2018-02-07_23:05:16 freezemon s:23:04:56 e:23:05:16 f:20.163 d:BlockingKill(N/A) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) PRESENCE_StartLocalScan(WernerS4) withings_poll(withings_U12928654)
2018-02-07_23:05:16 freezemon freezeTime: 20.163
2018-02-07_23:05:16 freezemon fcDay: 20
2018-02-07_23:05:16 freezemon ftDay: 237.637
2018-02-07_23:05:16 freezemon freezeDevice: BlockingKill(N/A) HMUARTLGW_CheckCredits(HMUARTLGW_CheckCredits) PRESENCE_StartLocalScan(WernerS4) withings_poll(withings_U12928654)
Gute Nacht
Zitat von: Intruder1956 am 07 Februar 2018, 23:37:46
was mach ich jetzt damit ;) :)
Nja es fällt auf, dass I2C_SUSV_Poll_GPIO alle 30 Minuten einen Freeze zu verursachen scheint... und zwar häufig um die 20 Sekunden... Das ist ziemlich lang. Wenn dich das stört kannst du mal genauer nachforschen woran das liegen könnte. Z.B. könnte das Modul "blocking" sein (schlecht, sollte vom Modulautor geändert werden) oder du hast irgendwelche timer mit (Perl-)"sleep" eingebaut o.ä. Zumindest ist ein Ansatz zur Optimierung da....
Coole Sache das
Mal sehen ob ich doch noch rausfinde, wer mich gelegentlich so ausbremst!
Danke, mal sehen ob ich das noch vor dem Stammtisch (kein fhem) eingebaut bekomme!
Gruss Christoph
Was haltet ihr davon?
2018.02.08 08:29:54 3: CALVIEW myCalView - CALENDAR:MyCalendar triggered, updating CALVIEW myCalView ...
2018.02.08 08:30:01 1: FreezeMon: myFreezemon possible freeze starting at 08:29:55, delay is 6.396 possibly caused by no bad guy found :-(
2018.02.08 09:29:55 3: CALVIEW myCalView - CALENDAR:MyCalendar triggered, updating CALVIEW myCalView ...
2018.02.08 09:30:01 1: FreezeMon: myFreezemon possible freeze starting at 09:29:55, delay is 6.432 possibly caused by no bad guy found :-(
2018.02.08 10:29:54 3: CALVIEW myCalView - CALENDAR:MyCalendar triggered, updating CALVIEW myCalView ...
2018.02.08 10:30:01 1: FreezeMon: myFreezemon possible freeze starting at 10:29:55, delay is 6.483 possibly caused by no bad guy found :-(
2018.02.08 11:29:54 3: CALVIEW myCalView - CALENDAR:MyCalendar triggered, updating CALVIEW myCalView ...
2018.02.08 11:30:00 1: FreezeMon: myFreezemon possible freeze starting at 11:29:55, delay is 5.925 possibly caused by no bad guy found :-(
Sieht so aus, als ob CALVIEW das System jeweisl für 5 Sekunden einfriert, oder?
- dahinter hängt ein Apple ICloud Calender -
@KernSani.... Wie funktioniert die BadGuy Detection? Kannst Du diesen Fall erkennen?
Kann man solche halbgaren Module nicht erstmal in ./contrib einchecken, bevor man sie auf die Menschheit losläßt?
Damit eingeschlossen meine ich auch die merkwürdigen .gplot Dateien...
Zitat von: DarkT am 08 Februar 2018, 11:50:35
Sieht so aus, als ob CALVIEW das System jeweisl für 5 Sekunden einfriert, oder?
- dahinter hängt ein Apple ICloud Calender -
@KernSani.... Wie funktioniert die BadGuy Detection? Kannst Du diesen Fall erkennen?
Tatsächlich ist es nicht der CALVIEW selbst, der das System einfriert (sonst hätte freezemon das erkannt), sondern irgendwas was danach passiert (und nicht Timer-gesteuert ist). Vielleicht mal mit verbose 5 anschauen, was da passiert.
Grundsätzlich macht freezemon genau das gleiche, was PERFMON macht - nämlich jede Sekunde nachschauen ob eine Sekunde vergangen ist - wenn mehr als eine Sekunde vergangen ist, hat irgendwas das System gebremst. In diesem Fall wertet freezemon die Timer aus, die zu diesem Zeitpunkt geplant waren und gibt sie als mögliche Schuldige zurück. Wenn etwas anderes (also nicht Timer gesteuertes, z.B. ein einfaches Perl-Sleep) den freeze verursacht hat, kann freezemon das nicht erkennen und gibt "no bad guy found" zurück.
Zitat von: betateilchen am 08 Februar 2018, 15:57:38
Kann man solche halbgaren Module nicht erstmal in ./contrib einchecken, bevor man sie auf die Menschheit losläßt?
Damit eingeschlossen meine ich auch die merkwürdigen .gplot Dateien...
Ich bin offen für konstruktive Kritik. Jörg (hermannj), auf dessen PERFMON das Modul basiert, hat sich das Modul angesehen, bevor ich es eingecheckt habe und sein ok gegeben. Die gplot Dateien sind - zugegeben - sehr simpel - aber erfüllen für mich ihren Zweck (und waren ein Userwunsch) - auch hier bin ich offen für Verbesserungsvorschläge.
Mach Dir keine Hoffnungen. Betateilchen stänkert nur gerne. An der Mitarbeit bei Verbesserungen ist er meiner Erfahrung nach nicht interessiert, solange es ihm nicht nützt.
[OT]
@willybauss:
Bitte überdenke, ob dein Post nicht besser überarbeitet werden sollte. Es ist zum einen nicht der Stil dieses Forums, andere pauschal runterzumachen. Deutliche Kritik darf zwar sein, sollte aber auf klare Fälle beschränkt sein.
Zum anderen ist deine Kritik es auch in der Sache schlicht falsch. Zwar versteht wenn man als "Normalsterblicher" nicht immer gleich, was mit ggf. deutlich von dieser Seite geübter Kritik gemeint sein könnte. Aber alleine die Zahl der (akzeptierten) Patches spricht Bände! Wir können das gerne unter 4 Augen im Detail diskutieren, aber bis dahin wäre meine Bitte, solche Pauschalaussagen zu unterlassen.
[/OT]
Zudem hat betateilchen in der Sache vollkommen recht.
Um mal zum Thema zurück zu kommen, vlt. kann man das andere Thema in einem anderen Thread (oder noch besser im Gespäch eruieren) ....
Zitat von: KernSani am 08 Februar 2018, 17:15:13
Vielleicht mal mit verbose 5 anschauen, was da passiert.
Die folgenden Meldung finde ich im Log (verbose 5)
2018.02.09 08:29:55 3: CALVIEW myCalView - CALENDAR:MyCalendar triggered, updating CALVIEW myCalView ...
2018.02.09 08:30:02 5: CALVIEW myCalView - nextday = 10 , endday = 10 , startday = 09 , btime 00:00:00 , etime 00:00:00
.... scheint, doch dass das Auslesen des Kalenders 7 Sekunden dauert... und das blockierend?
Dazu passt dann auch die Ausgabe von apptime:
maxDly avgDly TS Max call param Max call
myCalView CALVIEW_Notify 6769 216 6789.92 31.43
Zitat von: marvin78 am 09 Februar 2018, 08:07:22
Zudem hat betateilchen in der Sache vollkommen recht.
auch dich würde ich bitten konstruktive Kritik zu äußern und nicht nur pauschal das Modul als "doof" zu bezeichnen.
Habe ich nicht. Doof hast nur du geschrieben. Was diese seltsamen gplot Dateien sollen, verstehe ich nicht. Sowas kann jeder selbst schnell erstellen.
Zitat von: marvin78 am 09 Februar 2018, 09:19:09
Habe ich nicht. Doof hast nur du geschrieben. Was diese seltsamen gplot Dateien sollen, verstehe ich nicht. Sowas kann jeder selbst schnell erstellen.
Ich hatte deinen Kommentar auf die Aussage zum "halbgaren" Modul bezogen.
Wenn du dich auf die gplots beziehst hast du Recht, habe ich ja auch oben schonmal gesagt.
Zitat von: marvin78 am 09 Februar 2018, 09:19:09
Habe ich nicht. Doof hast nur du geschrieben. Was diese seltsamen gplot Dateien sollen, verstehe ich nicht. Sowas kann jeder selbst schnell erstellen.
Richtig, dass kann bestimmt jeder. Ich hatte ihn darum gebeten mir ein Beispiel zu geben. Liegt also mehr an meiner fehlenden Erfahrung.
Also Puls runter und wieder auf das wesentliche konzentrieren, man braucht keinem einen Vorwurf für eine freiwillig erbrachte Leistung machen. Danke
Zum Them, Kerni... habe ich das richtig verstanden?
Zitat von: DarkT am 09 Februar 2018, 08:15:49
Die folgenden Meldung finde ich im Log (verbose 5)
2018.02.09 08:29:55 3: CALVIEW myCalView - CALENDAR:MyCalendar triggered, updating CALVIEW myCalView ...
2018.02.09 08:30:02 5: CALVIEW myCalView - nextday = 10 , endday = 10 , startday = 09 , btime 00:00:00 , etime 00:00:00
.... scheint, doch dass das Auslesen des Kalenders 7 Sekunden dauert... und das blockierend?
Dazu passt dann auch die Ausgabe von apptime:
maxDly avgDly TS Max call param Max call
myCalView CALVIEW_Notify 6769 216 6789.92 31.43
Zitat von: DarkT am 09 Februar 2018, 09:27:57
man braucht keinem einen Vorwurf für eine freiwillig erbrachte Leistung machen. Danke
Doch, wenn sie sinnlos mit dem update kommen schon. Mein Puls ist im Übrigen bei 60. Ich lasse mir lediglich nicht gerne Worte in den Mund legen.
Zitat von: marvin78 am 09 Februar 2018, 09:31:49
Doch, wenn sie sinnlos mit dem update kommen schon. Mein Puls ist im Übrigen bei 60. Ich lasse mir lediglich nicht gerne Worte in den Mund legen.
Alles gut. Ist ja geklärt. Die gplots einzuchecken war ein Fehler, (aber kriege ich die wieder raus?)
Zitat von: DarkT am 09 Februar 2018, 09:27:57
Zum Them, Kerni... habe ich das richtig verstanden?
Ja, so würde ich das auch interpretieren. Prinzipiell hast du jetzt alle Infos um im entsprechenden Unterforum nachzufragen, woran das liegen...
Könntest du so einen "set <> clear "einbauen um die alten freezes zu löschen?
Danke
ZitatKönntest du so einen "set <> clear "einbauen um die alten freezes zu löschen?
siehe hier:
https://forum.fhem.de/index.php/topic,83909.msg762434.html#msg762434 (https://forum.fhem.de/index.php/topic,83909.msg762434.html#msg762434)
VG Sebastian
Zitat von: KernSani am 09 Februar 2018, 09:45:24
Alles gut. Ist ja geklärt. Die gplots einzuchecken war ein Fehler, (aber kriege ich die wieder raus?)
Ja, so würde ich das auch interpretieren. Prinzipiell hast du jetzt alle Infos um im entsprechenden Unterforum nachzufragen, woran das liegen...
Danke, dann habe ich jetzt verstanden wie es funktioniert. Aus diesen Erfahrungen könnte man das Modul wie folgt erweitern, so als Ideen:
- Erweiterte Analyse aktivieren/deaktivieren
- Bei erweiterter Analyse -> Log Level auf verbose 5 setzten, bei freeze "apptime" ausführen und sowohl diese Ausgabe als auch Teilabschnitt des Logs zum Freeeze wegspeichern - aber das ist natürlich nur ein Traum ^^
Zitat von: marvin78 am 09 Februar 2018, 09:19:09
Was diese seltsamen gplot Dateien sollen, verstehe ich nicht. Sowas kann jeder selbst schnell erstellen.
Es ist m.E. schon in Ordnung, die zur Verfügung zu stellen, auch wenn sie simpel sind, allerdings gehören die definitiv nicht mit in die Standardverteilung von FHEM. Ich würde die auch, wenn überhaupt, in contrib sehen (wollen).
Oder einfach hier im Forum als Beispiele anhängen.
Ansonsten finde ich das Modul und die Zusatzmöglichkeiten gegenüber perfmon prima!
Vielen Dank dafür!
gb#
eigentlich gehört es zu apptime, aber da hier gerade fleissig getestet wird:
ich hätte zwei vorschlage für apptime:
1. statt nur die funktionsnamen zu loggen könnte man auch den callstack loggen.
wenn man den callstack als key verwendet kann man unterscheiden über welchen weg genau der aufruf einer funktion die zeit verbraucht. und man kann sehen auf welcher ebene die zeit verbraucht wird.
das schaut dann z.b. so aus: name function max count total average maxDly avgDly TS Max call param Max call
telnetPort_192.168.161.236_56587 telnet_Read 2012 2 2012.18 1006.09 0.00 0.00 09.02. 18:55:12 HASH(telnetPort_192.168.161.236_56587)
timer telnet_Read->dummy_Set 2011 2 4016.09 2008.04 0.00 0.00 09.02. 18:55:12 HASH(timer); timer; on
tf telnet_Read->dummy_Set->notify_Exec 2003 2 4006.18 2003.09 0.00 0.00 09.02. 18:55:14 HASH(tf); HASH(timer)
tmr-freezemon_ProcessTimer HASH(0x7f8acd162b50) 10 6 14.95 2.49 3479.39 913.01 09.02. 18:55:06 HASH(freezmon)
hier sieht man das die zeit im notify_Exec verbraucht wird das durch ein dummy_Set über eine telnet verbindung eingegeben wurde. wenn man die total zeiten vergleicht sieht man auch das die zeit tatsächlich auf der untersten ebene verbraucht wird und nicht schon vorher. d.h. das notify das am event hängt kostet zeit, nicht das set selber.
wenn man sich die zeiten merkt könnte man in der auswertung auch die 'falsch positiven' ausblenden und nur die 'echten' verursacher zeigen. d.h. im beispiel oben würde telnet und set nicht mehr auftauchen. nur das notify.
2. für notify zusätzlich die events die zum notify geführt haben als key verwenden. so kann man unterscheiden welches ereignis tatsächlich probleme macht: name function max count total average maxDly avgDly TS Max call param Max call
telnetPort_192.168.161.236_56878 telnet_Read 6023 2 6023.49 3011.75 0.00 0.00 09.02. 19:35:57 HASH(telnetPort_192.168.161.236_56878)
timer telnet_Read->dummy_Set 6022 2 12037.19 6018.60 0.00 0.00 09.02. 19:35:57 HASH(timer); timer; on
tf telnet_Read->dummy_Set->notify_Exec(on) 4007 2 8013.88 4006.94 0.00 0.00 09.02. 19:36:03 HASH(tf2); HASH(timer)
tf telnet_Read->dummy_Set->notify_Exec(off) 2006 2 4011.68 2005.84 0.00 0.00 09.02. 19:35:53 HASH(tf); HASH(timer)
eine ähnliche sonderbehandlung könnte man auch für DOIF einbauen.
hier sieht man das die ausführung des notify im fall on doppelt so lange dauert wie im fall off.
die zusatzinfo könnte man konfigurierbar aktivieren.
der patch für alles beides schaut so aus:
Index: 98_apptime.pm
===================================================================
--- 98_apptime.pm (revision 16133)
+++ 98_apptime.pm (working copy)
@@ -170,10 +170,27 @@
else {return $ret[0];}
}
+my @callstack;
sub apptime_getTiming($$$@) {
my ($e,$fnName,$fn,$tim,@arg) = @_;
my $h;
my $ts1;
+
+ if( @callstack ) {
+ $fnName = join('->', @callstack)."->$fnName";
+ if( @arg && ref($arg[0]) eq 'HASH' ) {
+ if( my $name = $arg[0]->{NAME} ) {
+ if( $fn eq 'notify_Exec' ) {
+ my $events = deviceEvents($arg[1], AttrVal($arg[0]->{NAME}, "addStateEvent", 0));
+ $fnName .= '(';
+ $fnName .= join( ',', @{$events});
+ $fnName .= ')';
+ }
+ }
+ }
+ }
+
if ($apptimeStatus){
if (!$defs{$e}{helper} ||
!$defs{$e}{helper}{bm} ||
@@ -203,9 +220,11 @@
}
}
+ push @callstack, $fn;
no strict "refs";
my @ret = &{$fn}(@arg);
use strict "refs";
+ pop @callstack;
if ($apptimeStatus){
$ts1 = gettimeofday()-$ts1;
Zitat von: DarkT am 09 Februar 2018, 10:20:18
Danke, dann habe ich jetzt verstanden wie es funktioniert. Aus diesen Erfahrungen könnte man das Modul wie folgt erweitern, so als Ideen:
- Erweiterte Analyse aktivieren/deaktivieren
- Bei erweiterter Analyse -> Log Level auf verbose 5 setzten, bei freeze "apptime" ausführen und sowohl diese Ausgabe als auch Teilabschnitt des Logs zum Freeeze wegspeichern - aber das ist natürlich nur ein Traum ^^
Im Grunde macht Freezemon bei der Ermittlung der "bad guys" nichts anderes als apptime, mit dem Unterschied, dass apptime Werte über die Laufzeit aggregiert, während freezemon die Prozesse, die zum Zeitpunkt des freezes aktiv waren sammelt. Während eines freezes irgendwas zu tun geht leider nicht... deshalb ist es ja ein Freeze... Zudem kann man apptime zwar einschalten, aber nicht ohne restart ausschalten.
Zitat von: justme1968 am 09 Februar 2018, 19:46:18
eigentlich gehört es zu apptime, aber da hier gerade fleissig getestet wird:
Danke. Das sieht sehr interessant aus... Muss mir das Coding mal in Ruhe ansehen (und verstehen) und schauen, ob man das in Freezemon übernehmen könnte
Und noch was: Nachdem ich ja jetzt genug Haue bekommen habe - wegen der gplot-Files - habe ich nun zwei Möglichkeiten:
1. Ich baue die gplot-files so um, dass sie eine Komplexität aufweisen, die einer Veröffentlichung würdig ist
2. Ich finde raus wie ich die gplots wieder aus der distribution werfe.
Da mir für Punkt 1 sowohl das Wissen, als auch die Ideen fehlen geht die Wahrscheinlichkeit gegen 100%, dass es auf 2. rauslaufen wird. Ich empfehle also jedem, der die gplot-Files nutzt, sie unter eigenem zu sichern - sie werden in absehbarer Zeit verschwinden.
Da die Plot-Dateien im 1. Beitrag angehängt sind sollte 2. kein Problem sein.
Ich habe auf meinem QNAP das folgende Problem:
2018.02.11 11:22:45 0: Type of arg 1 to keys must be hash (not private array) at ./FHEM/98_freezemon.pm line 203, near "@freezes >"
Type of arg 1 to keys must be hash (not private array) at ./FHEM/98_freezemon.pm line 203, near "@freezes >"
2018.02.11 11:22:45 1: reload: Error:Modul 98_freezemon deactivated:
2018.02.11 11:19:48 0: Server started with 15 defined entities (fhem.pl:16107/2018-02-07 perl:5.010000 os:linux user:fhem pid:1019)
2018.02.11 11:19:48 0: Featurelevel: 5.8
Über eine Lösung würde ich mich freuen.
Zitat von: P.A.Trick am 11 Februar 2018, 11:26:53
Ich habe auf meinem QNAP das folgende Problem:
Über eine Lösung würde ich mich freuen.
Tritt das Problem erst seit dem heutigen update auf, oder schon länger?
Hallo KernSani,
ich habe immer die gleichen Kandidaten in der Freeze-Liste, z.B. meine HUE-Sensoren:
HUEDevice_GetUpdate(fl_bwm) HUEDevice_GetUpdate(Light_hue) HUEDevice_GetUpdate(Temp_hue)
Wie wäre es mit einer Art Whitelist für devices bei denen bekannt ist, dass sie Freezes produzieren,
es aber toleriert oder ignoriert werden kann?
VG Sebastian
Zitat von: P.A.Trick am 11 Februar 2018, 11:26:53
Ich habe auf meinem QNAP das folgende Problem:
Hab's... hängt mit deiner älteren Perl Version zusammen (mal an ein update gedacht?)
Ersetze bitte mal Zeile 203, aus
while (keys @freezes > 20) { sollte werden:
while (scalar(@freezes) > 20) { Das sollte helfen. Kommt morgen auch im Update.
Zitat von: binford6000 am 11 Februar 2018, 13:28:27
Wie wäre es mit einer Art Whitelist für devices bei denen bekannt ist, dass sie Freezes produzieren,
es aber toleriert oder ignoriert werden kann?
Yep, den Gedanken hatte ich auch schon, auch aus einem anderen Gedanken heraus, es gibt Prozesse, die einfach ständig laufen (bei mir z.B. der HMLAN_KeepAlive) und die daher sehr häufig unter den möglichen Kandidaten erscheinen obwohl sie natürlich keiner sind... Mal schauen, vielleicht gibt's heute noch eine Version zum Testen.
Zitat von: KernSani am 11 Februar 2018, 14:01:28
Hab's... hängt mit deiner älteren Perl Version zusammen (mal an ein update gedacht?)
Ersetze bitte mal Zeile 203, aus
while (keys @freezes > 20) {
sollte werden:
while (scalar(@freezes) > 20) {
Das sollte helfen. Kommt morgen auch im Update.
Perfekt das klappt! Vielen lieben Dank!
zum Update: ist leider auf der QNAP nicht so einfach möglich!
VG Patrick
Zitat von: binford6000 am 11 Februar 2018, 13:28:27
Hallo KernSani,
ich habe immer die gleichen Kandidaten in der Freeze-Liste, z.B. meine HUE-Sensoren:
HUEDevice_GetUpdate(fl_bwm) HUEDevice_GetUpdate(Light_hue) HUEDevice_GetUpdate(Temp_hue)
Wie wäre es mit einer Art Whitelist für devices bei denen bekannt ist, dass sie Freezes produzieren,
es aber toleriert oder ignoriert werden kann?
VG Sebastian
Hi Sebastian,
die angehängte Version hat ein neues Attribut:
- fm_ignoreDev: Liste von Komma-getrennten Devices. Wenn alle möglicherweise einen Freeze verursachenden Device in dieser Liste sind, wird der Freeze ignoriert (nicht geloggt)
Wäre schön, wenn du ein bisschen testen könntest, bevor ich das einchecke.
Danke,
Oli
Edit:
bei einem Blick ins Log ist mir heute morgen aufgefallen, das die angehängte Version einen Bug in der Ausgabeformatierung enthält, sowie eine Debug Meldung versehentlich mit Loglevel 3 kommt. Fixe ich im Laufe des TagesEdit2: Aktualisierung angehängt
Hi.
Danke fürs Modul.
Kannst du vielleicht die neueste Version immer im ersten Thread anhängen?
Das ist (meines Wissens nach) hier gängige Praxis und macht es, vor allem für Modul-Einsteiger, einfacher einzusteigen oder updaten ohne den Überblick über alle Posts zu haben :)
cheers
Sollen Einsteiger immer die letzte Testversion finden? Macht es nicht mehr Sinn, wenn die die Version vom Feed nehmen?
ZitatEdit2: Aktualisierung angehängt
Moin,
ich habe mit der ersten neuen Version auch weiterhin die ignorDev-devices im Log:
fm_ignoreDev
Wohnung,fl_bwm,Light_hue,Temp_hue,HarmonyLog:
2018.02.12 08:54:53 2: FreezeMon: SystemFreeze possible freeze starting at 08:54:47, delay is 6.081 possibly caused by harmony_connect(Harmony) HOMEMODE_GetUpdate(Wohnung) HUEDevice_GetUpdate(Light_hue) HUEDevice_GetUpdate(Temp_hue) HUEDevice_GetUpdate(fl_bwm) FW_closeInactiveClients(N/A)
2018.02.12 08:59:03 2: FreezeMon: SystemFreeze possible freeze starting at 08:58:58, delay is 5.522 possibly caused by harmony_connect(Harmony) HOMEMODE_GetUpdate(Wohnung) HUEDevice_GetUpdate(Light_hue) HUEDevice_GetUpdate(Temp_hue) HUEDevice_GetUpdate(fl_bwm)
Teste jetzt mal die neue Version.
VG Sebastian
ZitatMacht es nicht mehr Sinn, wenn die die Version vom Feed nehmen?
Sehe ich auch so. Die letzte stabile Version gibts im SVN und alle Testversionen hier im Thread.
VG Sebastian
Zitat von: binford6000 am 12 Februar 2018, 09:50:59
Die letzte stabile Version gibts im SVN...
... oh my bad ;D
Ich hab verpasst, dass das Modul schon im SVN ist.
Dachte das gibts bisher nur hier im Thread. Für Patch-versions stimme ich euch zu.
case closed ;)
Ich habe mit der neuen Version immer noch Freezes der igrnorDev im Log:
fm_ignoreDev Wohnung,fl_bwm,Light_hue,Temp_hue,Harmony
get <device> Freeze:
2 - 2018-02-12: s:10:02:43 e:10:02:48 f:5.906 d:harmony_connect(Harmony) HOMEMODE_GetUpdate(Wohnung) HUEDevice_GetUpdate(Light_hue) HUEDevice_GetUpdate(Temp_hue) HU...
Im Log:
2018.02.12 10:02:48 2: FreezeMon: SystemFreeze possible freeze starting at 10:02:43, delay is 5.906 possibly caused by harmony_connect(Harmony) HOMEMODE_GetUpdate(Wohnung) HUEDevice_GetUpdate(Light_hue) HUEDevice_GetUpdate(Temp_hue) HUEDevice_GetUpdate(fl_bwm) HttpUtils_Err(wz_aurora_licht) HttpUtils_Err(moebHUEs) HttpUtils_Err(moebHUEs)
VG Sebastian
Zitat von: binford6000 am 12 Februar 2018, 09:47:50
Moin,
ich habe mit der ersten neuen Version auch weiterhin die ignorDev-devices im Log:
fm_ignoreDev
Wohnung,fl_bwm,Light_hue,Temp_hue,Harmony
Log:
2018.02.12 08:54:53 2: FreezeMon: SystemFreeze possible freeze starting at 08:54:47, delay is 6.081 possibly caused by harmony_connect(Harmony) HOMEMODE_GetUpdate(Wohnung) HUEDevice_GetUpdate(Light_hue) HUEDevice_GetUpdate(Temp_hue) HUEDevice_GetUpdate(fl_bwm) FW_closeInactiveClients(N/A)
2018.02.12 08:59:03 2: FreezeMon: SystemFreeze possible freeze starting at 08:58:58, delay is 5.522 possibly caused by harmony_connect(Harmony) HOMEMODE_GetUpdate(Wohnung) HUEDevice_GetUpdate(Light_hue) HUEDevice_GetUpdate(Temp_hue) HUEDevice_GetUpdate(fl_bwm)
Teste jetzt mal die neue Version.
VG Sebastian
Hmmm... beim ersten Freeze hat sich noch der CloseInactiveClients mit eingeschlichen... aber der zweite müsste eigentlich ignoriert werden. Muss ich mir mal in Ruhe ansehen, könnte dann aber bis Ende der Woche dauern...
Kurz, weil mobil...
Ich habe nochmal gebastelt und fleissig getestet. Das neue ignoreDev sollte eigentlich funktionieren, wie designed. Es gibt jetzt ein zusätzliches Attribute "fm_ignoreMode":
fm_ignoreMode: Kann die Werte off,single oder all annehmen. Wenn in fm_ignoreDev Devices angegeben sind wirken sich der ignoreMode wie folgt aus: all: Ein Freeze wird nur dann ignoriert, wenn alle möglicherweise dern Freeze verursachenden Devices in der Ignore-Liste enthalten sind. Dies führt unter Umständen dazu, dass mehr Freezes geloggt werden als erwartet.
single: Ein Freeze wird ignoriert, sobald ein möglicher Verursacher in der Ignorierliste enthalten ist. Dies führt möglicherweise dazu, dass Freezes übersehen werden.
off: Alle Freezes werden geloggt, unabhängig von ignoreDev.
Sofern das Attribut nicht gesetzt ist, aber Ignore-Devices angegeben sind, wird im Modus "all" ignoriert.
AKtualisierung von fm_ignoreDev:
fm_ignoreDev: Liste von Komma-getrennten Devices. Wenn einzelne möglicherweise einen Freeze verursachenden Device in dieser Liste sind, wird der Freeze ignoriert (nicht geloggt). Bitte das Attribut fm_ignoreMode beachten
Grüße,
Oli
Hallo,
vielen Dank für das Modul, liefert sehr aufschlussreiche Ergebnisse.
:)
Eine Frage habe ich noch, im FHEM-Log tauchen bei mir des öfteren solche Log-Einträge auf:
2018.02.13 12:07:22.009 3: Freezemon: Reference found: CODE/__ANON__/CODE(0xc406cc0)
2018.02.13 12:07:23.007 3: Freezemon: Reference found: CODE/__ANON__/CODE(0xc357228)
2018.02.13 12:07:56.003 3: Freezemon: Reference found: CODE/__ANON__/CODE(0xbe50fc8)
2018.02.13 12:07:57.005 3: Freezemon: Reference found: CODE/__ANON__/CODE(0xbe50fc8)
Kommen wohl mit Loglevel 3 aus der Sub freezemon_apptime() nur leider sagen sie mir nichts.
Kann mir jemand ein bisschen den Hintergrund für diese Log-Einträge erläutern?
Vielen Dank,
Andreas
Hi Oli,
habe mal über den Tag die verschiedenen Modi gurchgetestet. Aber irgendwie habe ich das Gefühl, dass zu wenig geloggt wird.
Selbst wenn ich die Attribute fm_ignoreDev und fm_ignoreMode lösche, tauchen weiterhin Freezes auf welche nicht im Log landen.
Dafür aber das hier:
2018.02.13 19:15:19 1: PERL WARNING: Use of uninitialized value $aVal in concatenation (.) or string at ./FHEM/98_freezemon.pm line 404.
Auch ein set clear, inactive, active ändert daran nichts.
Übrigens vermisse ich auch get Freezes
VG Sebastian
Hi Sebastian, danke für's testen. Schaue ich mir nochmal an. In der Zwischenzeit: Könntest du Freezemon auf verbose 5 stellen? Dann sollten Meldungen im Log erscheinen, warum etwas geloggt wurde (oder eben nicht)
Kurz, weil mobil...
ZitatKönntest du Freezemon auf verbose 5 stellen? Dann sollten Meldungen im Log erscheinen, warum etwas geloggt wurde (oder eben nicht)
Sorry, mein Fehler... Hatte fm_log noch auf 10:1 5:2 1:3 stehen... :o
Das wars. Ich denke jetzt kommen auch die passenden Logeinträge.
VG Sebastian
Zitat von: binford6000 am 13 Februar 2018, 19:24:26
Übrigens vermisse ich auch get Freezes
Ist in der angehängten Version wieder da :-)
Zitat von: scooty am 13 Februar 2018, 12:31:46
Eine Frage habe ich noch, im FHEM-Log tauchen bei mir des öfteren solche Log-Einträge auf:
2018.02.13 12:07:22.009 3: Freezemon: Reference found: CODE/__ANON__/CODE(0xc406cc0)
2018.02.13 12:07:23.007 3: Freezemon: Reference found: CODE/__ANON__/CODE(0xc357228)
2018.02.13 12:07:56.003 3: Freezemon: Reference found: CODE/__ANON__/CODE(0xbe50fc8)
2018.02.13 12:07:57.005 3: Freezemon: Reference found: CODE/__ANON__/CODE(0xbe50fc8)
Sorry, das sollte eigentlich eine Log 5 Meldung sein. Ist in der Testversion im vorigen Post behoben... Prinzipiell kannst du die Meldung ignorieren (interessant ist sie aber). Freezemon greift FHEM-interne Variablen ab, um Mögliche Verursacher von Freezes zu identifizieren. In 98% aller Fälle sehen diese gleich aus und der Devicename kann einfach ausgelesen werden. In einigen wenigen Fällen, sehen die hashes aber anders aus (z.B. bei DOIF-Timern). So einen "Abweichler" (der aber nicht gleichbedeutend mit einem Freeze ist) haben wir hier aufgespürt. Was das wirklich ist... keine AHnung... irgendwas generiert eine anonyme sub... Ich habe eine Idee, wie ich das genauer untersuchen kann und evtl. zusätzliche Erkenntnisse gewinnen kann, insofern war der Bug ganz hilfreich ;-)
Hallo KernSani,
danke für die Erläuterungen, beruhigend, dass es nichts problematisches war.
Ich probiere es dann erst einmal mit der Testversion.
Vielen Dank nochmal,
Andreas
ZitatIst in der angehängten Version wieder da :-)
Jaaaaa :D
Also bis jetzt funktioniert alles bestens.
Auch ganz interessant ist, dass unter verbose 5 auch eine Begründung für ein ignore zu sehen ist:
018.02.14 10:00:26 5: FreezeMon SystemFreeze ignoring HUEDevice_GetUpdate:Light_hue HUEDevice_GetUpdate:Temp_hue Calendar_PollChild:nextcloud_kalender HOMEMODE_GetUpdate:Wohnung HttpUtils_Err:moebHUEs HttpUtils_Err:moebHUEs in single mode, because Wohnung is ignoredVG Sebastian
Funktioniert weiterhin alles bestens? Dann würde ich demnächst mal einchecken...
Hi Oli,
ja also bei mir schon. Hab mal ein paar Kombinationen durch und dabei nichts negatives festgestellt.
Alles tut so wie es soll. Also wegen mir ab damit ins SVN. Dann kann ich es auch wieder aus exclude_from_update rausnehmen ;D
VG Sebastian
Zitat von: KernSani am 13 Februar 2018, 22:29:41
Sorry, das sollte eigentlich eine Log 5 Meldung sein.
Hallo KernSani,
nur 'ne Kleinigkeit, die Meldungen aus der Sub freezemon_apptime()
Freezemon: Reference found:sind in Version
98_freezemon.pm 16196 2018-02-16 20:15:39Z KernSanimit Loglevel 3.
Hatte Dich so verstanden, dass Du diese auf Loglevel 5 ändern wolltest?
Andreas
Zitat von: scooty am 17 Februar 2018, 08:53:45
Hatte Dich so verstanden, dass Du diese auf Loglevel 5 ändern wolltest?
Mist. Eine Stelle hatte ich übersehen - Fix ist eingecheckt und sollte mit dem Update morgen kommen
Jetzt passt es, vielen Dank!
:)
Andreas
Mir ist gerade mein FHEM abgekachelt, vermutlich durch freezemon,
Meldung im Log:
Can't use string ("hm:1") as a HASH ref while "strict refs" in use at ./FHEM/98_freezemon.pm line 516.
Mehr stand da leider nicht.
Ups. Muss ich mir ansehen. In der aktuellen Version? Update von heute morgen?
Kurz, weil mobil...
Zitat von: KernSani am 18 Februar 2018, 19:27:44
Ups. Muss ich mir ansehen. In der aktuellen Version? Update von heute morgen?
Kurz, weil mobil...
In beiden!
Ist mir irgendwie nicht klar, wie es zu em Fehler kommen kann... sehen die Zeilen 515-517 bei dir so aus:
if ( $fn eq "BlockingKill" ) {
$shortarg = $shortarg->{abortArg}{NAME};
}
Aus irgendeinem Grund scheint der Hash nicht immer gleich auszusehen, um dem Fehler auf den Grund zu gehen (ohne dein FHEM abzuschiessen) könntest du Zeile 516
$shortarg = $shortarg->{abortArg}{NAME};
durch
Log3 undef, 1, "Freezemon:Problem in $fn" . Dumper($shortarg);
ersetzen?
Dann sollte im Log irgendwann ein längerer "Baum" auftauchen. Den bräuchte ich...
Danke,
Oli
Werde ich morgen versuchen, ist halt doof wenn FHEM nicht stabil läuft. Ich habe freezemon ersteinmal deaktiviert.
Zitat von: KernSani am 18 Februar 2018, 21:13:28
Ist mir irgendwie nicht klar, wie es zu em Fehler kommen kann... sehen die Zeilen 515-517 bei dir so aus:
if ( $fn eq "BlockingKill" ) {
$shortarg = $shortarg->{abortArg}{NAME};
}
Ja siehe Screenshot!
Ok. Um sicher zu gehen habe ich eine neue Version gebastelt,
Zur Erläuterung: Freezemon greift die internen Timer von FHEM ab, um mögliche Verursacher zu identifizieren. Normlerweise haben diese ein Attribut NAME, über das sich das Device ermitteln lässt. In einigen Fällen fehlt dieses Attribut (in apptime erscheinen diese dann als UNNAMED_HASH o.ä.). Für manche dieser Fälle versucht Freezemon trotzdem das auslösende Device zu ermitteln - unter der Annahme, dass die Hashes für die selbe Funktion immer gleich aussehen. Dies scheint nicht immer der Fall zu sein und führt dann ggf. zu einem Crash.
Daher gibt es jetzt in Freezemon ein neues Attribut fm_extDetail, mit dem die oben geschilderte Funktionalität ein- und ausgeschaltet werden kann.
Achtung: Die angehängte Version benötigt "shutdown restart", "reload" alleine reicht nicht.
Ok ich habe die neue Version eingespielt und freezemon wieder aktiviert. Bei dem dumper Befehl habe ich Problem mit. Dort werden mir zuviele "intime" Informationen mit protokolliert. Kannst du mir genauer sagen wonach du suchst!?
Ich habe das gleiche Problem beobachtet. Betroffen bei mir ist ein Device mit Internal NAME Vitodens300 ( Modul VCONTROL300 ).
Allerdings ist dieses Device inaktiv, d.h. Attribut disable = 1.
Kann es damit zusammenhängen?
Mobil gesendet, darum kurz...
Hallo zusammen,
nach einem Update von fhem, Neustart und Aktivieren von freezemon hängt sich mein fhem auf. Im Log ist der letzte Eintrag:
argument is not a reference at ./FHEM/98_freezemon.pm line 566.
Woran liegt das?
Beste Grüße
Torsten
@P.A.Trick, tpm88: Bei euch läuft's mit der neuen Version?
@ToKa: Das ist interessant, das ist eine Codingstelle, die seit der ersten Version so existiert (und mehr oder weniger so aus apptime übernommen wurde). Zudem zum ersten Mal, dass ich sehe, dass die prioQueues verwendet werden (eine relativ neue Entwicklung in fhem.pl).
Die angehängte Version sollte das fixen (interessant wäre aber ob apptime dein FHEM auch zum Absturz bringt).
Zitat von: P.A.Trick am 18 Februar 2018, 23:09:15
Ok ich habe die neue Version eingespielt und freezemon wieder aktiviert. Bei dem dumper Befehl habe ich Problem mit. Dort werden mir zuviele "intime" Informationen mit protokolliert. Kannst du mir genauer sagen wonach du suchst!?
war wahrscheinlich keine so gute Idee mit dem Dumper. Eigentlich suche ich {NAME} (und den "Pfad" dorthin) das sich irgendwo in dem Hash verstecken sollte... Vielleicht kannst du einfach mal einen Dumper-Auszug anhängen. Ich fürchte aber, insgesamt ist das ohnehin ein sinnloses Unterfangen, wenn ich nicht davon ausgehen kann, dass die Hashes bei der selben Funktion immer gleich aufgebaut sind.
Hallo KernSani,
ja ich versuche gerade einem Problem mit NO ACK Meldungen auf die Spur zukommen und habe dazu "prioQueues" eingebaut. Parallel wollte ich mir mit freezemon anschauen, was so im System passiert.
Auch apptime stürzt ab:
argument is not a reference at ./FHEM/98_apptime.pm line 128.
Leider aber auch die neue freezemon Version:
Can't call method "fn" on an undefined value at ./FHEM/98_freezemon.pm line 567.
Hoffe die Fehlermeldung reicht aus.
Beste Grüße
Torsten
Kannst du mir noch deinen prioqueues code schicken, dann kann ich das nachbauen...
Kurz, weil mobil...
Klar und schon mal danke!
## Alle Heizungsventile bis auf Badezimmer E4 auf gewünschten Modus setzen
my @THKV_Heizkoerper = devspec2array("TYPE=ZWave:FILTER=NAME=(?!E4_bz_).*_THKV_Heizkoerper_.*");
$i = 1;
foreach(@THKV_Heizkoerper) {
$cmd = "fhem 'set $_ $event'";
Log $LogLevel, $i." myHeatingControl - set thermostatMode: ".$cmd;
PrioQueue_add(sub(){
## InternalTimer(gettimeofday()+$i*7.5,sub(){
my ($arg1,$LogArg) = @{$_[0]};
Log $LogArg, "myHeatingControl - set thermostatMode Timer: ".$arg1;
eval $arg1;
}, [$cmd,$LogLevel_Debug]);
## }, ["$cmd","$LogLevel_Debug"]);
$i = $i + 1;
}
## Aktuell gültige Temperatur bei zeitgesteuerten Heizungen einstellen
my @THKV_Heizkoerper_hC = devspec2array("TYPE=Heating_Control");
foreach(@THKV_Heizkoerper_hC) {
Log $LogLevel, $i." myHeatingControl - Heating_Control_SetTemp: ".$_;
PrioQueue_add(sub(){
## InternalTimer(gettimeofday()+$i*7.5,sub() {
my ($arg1,$LogArg) = @{$_[0]};
Log $LogArg, "myHeatingControl - Heating_Control_SetTemp Timer: ".$arg1;
Heating_Control_SetTemp("$arg1"); ## SetAllTemps
}, [$_,$LogLevel_Debug]);
## }, ["$_","$LogLevel_Debug"]);
$i = $i + 1;
Gruß
Torsten
Hi ToKa,
ich kann das Problem nachvollziehen, kriege es aber heute nicht mehr zufriedenstellend gelöst. Die angehängte Version sollte aber zumindest keine crashes mehr verursachen.
Grüße,
Oli
Hallo @ all,
da ich seit einer weile auch Probleme mit der Reaktionsgeschwindigkeit meines Fhem's zu tun habe bin ich irgendwie hier gelandet...
Anbei ein Auszug meiner letzten 20 Freeze
1 - 2018-02-20: s:14:12:49 e:14:12:51 f:2.934 d:BOSEST_checkWebSocketConnection(BOSE_38D2696EAB40) BOSEST_checkWebSocketConnection(BOSE_38D2696EAB40) BOSEST_checkWe...
1 - 2018-02-20: s:14:13:52 e:14:13:55 f:3.005 d:BOSEST_checkWebSocketConnection(BOSE_38D2696EAB40) BOSEST_checkWebSocketConnection(BOSE_A81B6A26A3B6) BOSEST_checkWe...
1 - 2018-02-20: s:14:14:55 e:14:14:57 f:2.971 d:BOSEST_checkWebSocketConnection(BOSE_38D2696EAB40) BOSEST_checkWebSocketConnection(BOSE_A81B6A26A3B6) ModbusTCPServe...
1 - 2018-02-20: s:14:15:58 e:14:16:01 f:3.014 d:BOSEST_checkWebSocketConnection(BOSE_38D2696EAB40) BOSEST_checkWebSocketConnection(BOSE_A81B6A26A3B6) ModbusTCPServe...
1 - 2018-02-20: s:14:17:01 e:14:17:04 f:3.111 d:BOSEST_checkWebSocketConnection(BOSE_A81B6A26A3B6) ModbusTCPServer_Poll(N/A) BOSEST_checkWebSocketConnection(BOSE_A8...
1 - 2018-02-20: s:14:19:05 e:14:19:08 f:3.002 d:BOSEST_checkWebSocketConnection(BOSE_38D2696EAB40) ModbusTCPServer_Poll(N/A) CUL_HM_procQs(N/A) BOSEST_checkWebSocke...
1 - 2018-02-20: s:14:20:09 e:14:20:11 f:2.363 d:SIP_watch_listen(N/A) BOSEST_checkWebSocketConnection(BOSE_A81B6A26A3B6) ModbusTCPServer_Poll(N/A) DENON_AVR_Connect...
1 - 2018-02-20: s:14:21:12 e:14:21:14 f:2.306 d:ModbusTCPServer_Poll(N/A) BOSEST_checkWebSocketConnection(BOSE_A81B6A26A3B6) BOSEST_checkWebSocketConnection(BOSE_A8...
1 - 2018-02-20: s:14:22:15 e:14:22:16 f:1.176 d:SIP_watch_listen(N/A) BOSEST_checkWebSocketConnection(BOSE_A81B6A26A3B6) ModbusTCPServer_Poll(N/A) DENON_AVR_Connect...
1 - 2018-02-20: s:14:23:16 e:14:23:19 f:3.068 d:BOSEST_checkWebSocketConnection(BOSE_38D2696EAB40) BOSEST_checkWebSocketConnection(BOSE_A81B6A26A3B6) BOSEST_checkWe...
1 - 2018-02-20: s:14:24:19 e:14:24:22 f:3.005 d:BOSEST_checkWebSocketConnection(BOSE_38D2696EAB40) ModbusTCPServer_Poll(N/A) BOSEST_checkWebSocketConnection(BOSE_A8...
1 - 2018-02-20: s:14:25:23 e:14:25:25 f:2.509 d:ModbusTCPServer_Poll(N/A) SIP_watch_listen(N/A) DENON_AVR_ConnectionCheck(DenonAVR2400RicoMaster) DbLog_execmemcache...
1 - 2018-02-20: s:14:26:26 e:14:26:28 f:2.58 d:ModbusTCPServer_Poll(N/A) BOSEST_checkWebSocketConnection(BOSE_38D2696EAB40) BOSEST_checkWebSocketConnection(BOSE_38D...
1 - 2018-02-20: s:14:27:29 e:14:27:31 f:2.79 d:BOSEST_checkWebSocketConnection(BOSE_38D2696EAB40) ModbusTCPServer_Poll(N/A) CUL_HM_procQs(N/A) SIP_watch_listen(N/A)...
1 - 2018-02-20: s:14:28:32 e:14:28:34 f:2.786 d:ModbusTCPServer_Poll(N/A) CUL_HM_procQs(N/A) BOSEST_checkWebSocketConnection(BOSE_A81B6A26A3B6) SIP_watch_listen(N/A...
1 - 2018-02-20: s:14:29:35 e:14:29:36 f:1.232 d:BOSEST_checkWebSocketConnection(BOSE_38D2696EAB40) ModbusTCPServer_Poll(N/A) CUL_HM_procQs(N/A) BOSEST_checkWebSocke...
1 - 2018-02-20: s:14:30:36 e:14:30:38 f:2.92 d:BOSEST_checkWebSocketConnection(BOSE_38D2696EAB40) BOSEST_checkWebSocketConnection(BOSE_38D2696EAB40) BOSEST_checkWeb...
1 - 2018-02-20: s:14:31:03 e:14:31:06 f:3.991 d:BOSEST_checkWebSocketConnection(BOSE_A81B6A26A3B6) ModbusTCPServer_Poll(N/A) BOSEST_checkWebSocketConnection(BOSE_38...
1 - 2018-02-20: s:14:31:39 e:14:31:42 f:3.002 d:CUL_HM_procQs(N/A) ModbusTCPServer_Poll(N/A) BOSEST_checkWebSocketConnection(BOSE_A81B6A26A3B6) BOSEST_checkWebSocke...
1 - 2018-02-20: s:14:32:42 e:14:32:45 f:3.002 d:BOSEST_checkWebSocketConnection(BOSE_A81B6A26A3B6) BOSEST_checkWebSocketConnection(BOSE_38D2696EAB40) BOSEST_checkWe...
Entweder stimmt bei mir was Grundsätzlich nicht oder aber mein System ist am Ende...(So mein Gefühl).
Zum System
Fhem läuft auf einem Raspi 2, weitere Frage beantworte ich gern um mein Performance Problem zu lösen.
Kann mir jedoch nicht vorstellen das so viele Module Probleme verursachen!
Update1
Auszug Eventmonitor
2018-02-20 15:05:13 freezemon myFreezemon s:15:05:10 e:15:05:13 f:3.041 d:ModbusTCPServer_Poll(N/A) CUL_HM_procQs(N/A) SIP_watch_listen(N/A) DENON_AVR_ConnectionCheck(DenonAVR2400RicoMaster)
2018-02-20 15:05:13 freezemon myFreezemon freezeTime: 3.041
2018-02-20 15:05:13 freezemon myFreezemon fcDay: 874
2018-02-20 15:05:13 freezemon myFreezemon ftDay: 2325.449
2018-02-20 15:05:13 freezemon myFreezemon freezeDevice: ModbusTCPServer_Poll(N/A) CUL_HM_procQs(N/A) SIP_watch_listen(N/A) DENON_AVR_ConnectionCheck(DenonAVR2400RicoMaster)
2018-02-20 15:06:16 freezemon myFreezemon s:15:06:13 e:15:06:16 f:3.002 d:ModbusTCPServer_Poll(N/A) CUL_HM_procQs(N/A)
2018-02-20 15:06:16 freezemon myFreezemon freezeTime: 3.002
2018-02-20 15:06:16 freezemon myFreezemon fcDay: 875
2018-02-20 15:06:16 freezemon myFreezemon ftDay: 2328.451
2018-02-20 15:06:16 freezemon myFreezemon freezeDevice: ModbusTCPServer_Poll(N/A) CUL_HM_procQs(N/A)
2018-02-20 15:07:19 freezemon myFreezemon s:15:07:16 e:15:07:19 f:3.002 d:ModbusTCPServer_Poll(N/A) CUL_HM_procQs(N/A)
2018-02-20 15:07:19 freezemon myFreezemon freezeTime: 3.002
2018-02-20 15:07:19 freezemon myFreezemon fcDay: 876
2018-02-20 15:07:19 freezemon myFreezemon ftDay: 2331.453
2018-02-20 15:07:19 freezemon myFreezemon freezeDevice: ModbusTCPServer_Poll(N/A) CUL_HM_procQs(N/A)
2018-02-20 15:08:20 freezemon myFreezemon s:15:08:19 e:15:08:20 f:1.739 d:ModbusTCPServer_Poll(N/A) CUL_HM_procQs(N/A) PRESENCE_StartLocalScan(LEDEinfahrtWIFILIGHT)
2018-02-20 15:08:20 freezemon myFreezemon freezeTime: 1.739
2018-02-20 15:08:20 freezemon myFreezemon fcDay: 877
2018-02-20 15:08:20 freezemon myFreezemon ftDay: 2333.192
2018-02-20 15:08:20 freezemon myFreezemon freezeDevice: ModbusTCPServer_Poll(N/A) CUL_HM_procQs(N/A) PRESENCE_StartLocalScan(LEDEinfahrtWIFILIGHT)
2018-02-20 15:09:24 freezemon myFreezemon s:15:09:21 e:15:09:24 f:3.002 d:ModbusTCPServer_Poll(N/A) CUL_HM_procQs(N/A)
2018-02-20 15:09:24 freezemon myFreezemon freezeTime: 3.002
2018-02-20 15:09:24 freezemon myFreezemon fcDay: 878
2018-02-20 15:09:24 freezemon myFreezemon ftDay: 2336.194
2018-02-20 15:09:24 freezemon myFreezemon freezeDevice: ModbusTCPServer_Poll(N/A) CUL_HM_procQs(N/A)
2018-02-20 15:10:27 freezemon myFreezemon s:15:10:24 e:15:10:27 f:3.002 d:CUL_HM_procQs(N/A) ModbusTCPServer_Poll(N/A)
2018-02-20 15:10:27 freezemon myFreezemon freezeTime: 3.002
2018-02-20 15:10:27 freezemon myFreezemon fcDay: 879
2018-02-20 15:10:27 freezemon myFreezemon ftDay: 2339.196
2018-02-20 15:10:27 freezemon myFreezemon freezeDevice: CUL_HM_procQs(N/A) ModbusTCPServer_Poll(N/A)
2018-02-20 15:11:30 freezemon myFreezemon s:15:11:27 e:15:11:30 f:3.052 d:CUL_HM_procQs(N/A) ModbusTCPServer_Poll(N/A)
2018-02-20 15:11:30 freezemon myFreezemon freezeTime: 3.052
2018-02-20 15:11:30 freezemon myFreezemon fcDay: 880
2018-02-20 15:11:30 freezemon myFreezemon ftDay: 2342.248
2018-02-20 15:11:30 freezemon myFreezemon freezeDevice: CUL_HM_procQs(N/A) ModbusTCPServer_Poll(N/A)
2018-02-20 15:12:33 freezemon myFreezemon s:15:12:31 e:15:12:33 f:2.509 d:ModbusTCPServer_Poll(N/A) SIP_watch_listen(N/A) DENON_AVR_ConnectionCheck(DenonAVR2400RicoMaster) CUL_HM_procQs(N/A) DbLog_execmemcache(logdb) PRESENCE_StartLocalScan(FernseherRicoPresence)
2018-02-20 15:12:33 freezemon myFreezemon freezeTime: 2.509
2018-02-20 15:12:33 freezemon myFreezemon fcDay: 881
2018-02-20 15:12:33 freezemon myFreezemon ftDay: 2344.757
2018-02-20 15:12:33 freezemon myFreezemon freezeDevice: ModbusTCPServer_Poll(N/A) SIP_watch_listen(N/A) DENON_AVR_ConnectionCheck(DenonAVR2400RicoMaster) CUL_HM_procQs(N/A) DbLog_execmemcache(logdb) PRESENCE_StartLocalScan(FernseherRicoPresence)
2018-02-20 15:13:36 freezemon myFreezemon s:15:13:34 e:15:13:36 f:2.701 d:ModbusTCPServer_Poll(N/A) SIP_watch_listen(N/A) DENON_AVR_ConnectionCheck(DenonAVR2400RicoMaster) DbLog_execmemcache(logdb) PRESENCE_StartLocalScan(HandyHermann) CUL_HM_procQs(N/A)
2018-02-20 15:13:36 freezemon myFreezemon freezeTime: 2.701
2018-02-20 15:13:36 freezemon myFreezemon fcDay: 882
2018-02-20 15:13:36 freezemon myFreezemon ftDay: 2347.458
2018-02-20 15:13:36 freezemon myFreezemon freezeDevice: ModbusTCPServer_Poll(N/A) SIP_watch_listen(N/A) DENON_AVR_ConnectionCheck(DenonAVR2400RicoMaster) DbLog_execmemcache(logdb) PRESENCE_StartLocalScan(HandyHermann) CUL_HM_procQs(N/A)
MFG Rico
Hi Rico,
irgendwie steht überall das "CheckWebsocketConnection" drin.
Evtl. ist das blocking programmiert?
Und wenn es dann (bei dir) auf irgendwelche Timeouts läuft, dann steht fhem eben...
Ich nutze das Modul nicht, daher kann ich das nicht sagen.
EDIT: evtl. für das konkrete Problem/Frage einen eigenen, passenden Thread aufmachen. Hier geht es doch eher um das Modul (und damit verbundenen Problemen)... Äh: meine Meinung... ;)
Gruß, Joachim
Hallo Oli,
leider noch keine Erfolgsmeldung... auch mit der letzten Version hier aus dem Forum kommt es zu einem Absturz von fhem. Letzte Meldung im log
2018.02.20 18:36:17.549 1: PERL WARNING: Use of uninitialized value $shortarg in concatenation (.) or string at ./FHEM/98_freezemon.pm line 586.
Can't use an undefined value as a subroutine reference at fhem.pl line 3094.
Falls Du ein verbose 5 log brauchst, sag Bescheid.
Beste Grüße
Torsten
Zitat von: ToKa am 20 Februar 2018, 18:40:20
Can't use an undefined value as a subroutine reference at fhem.pl line 3094.
der Absturz kommt aber aus der fhem.pl und zwar aus der Zeile in der die prioqueues abgearbeitet werden. Habe ich auf meinem Testsystem auch gesehen, als ich deinen Code nachgebaut habe. Schau ich mir später nochmal an.
Hi,
danke für das Modul :-)
Hatte zwar noch keine Freezes, aber besser schon einmal gerüstet sein ...
kannst Du noch das Coding der Umlaute in der Deutschen Commandref anpassen?
als Beispiel
freezeDevice: Liste von möglicherweise den Freeze auslösenden Funktionen(Devices)
Ich habe es endlich geschafft, mich mal um die PrioQueues zu kümmern (und die Umlaute in der Commandref bereinigt). Wäre dankbar für ein paar Tests bevor ich einchecke.
Hallo Oli,
den bisherige Fehler / Absturz des Systems konnte ich damit nicht mehr provozieren.
Danke für die neue Version!
Gruß
Torsten
Oft wird geraten, für eine detailliertere Analyse das loglevel hochzusetzen und das so erzeugte Log zu analysieren. Allerdings möchte man vielleicht nicht unbedingt generell ein global verbose 5 gesetzt haben.
Deshalb im Anhang ein Patch, der Log3 mit einem Wrapper versieht, der zunächst generell alle Log-Meldungen ungeachtet des Loglevels zwischenspeichert. Bei einem Freeze werden diese dann in eine Datei geschrieben. Dazu kann über das neue Attribut fm_logFile der Dateiname (mit den üblichen Datumswildcards) für Logfiles gesetzt werden (um für jeden Freeze eine eigene Datei zu erzeugen, bietet sich z.B. log/freeze-%Y%m%d-%H%M%S.log an). Kommt es nicht zum Freeze, werden die Meldungen wieder verworfen.
Schau mal, ob Du das so übernehmen möchtest. Könnte mir vorstellen, dass sich das auch noch gut erweitern lässt, z.B. mit zusätzlichen Informationen aus apptime, etc.
Beste Grüße,
Andy.
@Andy: coole Funktion. Vielen Dank. Habe sie etwas angepasst und in angehängter Version übernommen.
Achtung - die angehängte Version ist zusätzlich bez. der internalTimer optimiert, die seit ca. 20. Feb. in fhem.pl verfügbar sind, d.h. ein aktuelles FHEM ist Voraussetzung.
Edit: Todo wäre noch, die zusätzlichen Logs leicht zugänglich zu machen. Meine Idee wäre im "get freeze" popup einen Link auf das jeweilige Log einzubauen. Bessere Ideen?
Danke fürs Übernehmen. Die Anpassungen gefallen mir, werde das bei nächster Gelegenheit testen :)
Die Idee mit dem Link ist gar nicht so schlecht, für das Arbeiten über die Webschnittstelle ist das sicher ein guter Ansatz.
In meinem Produktivsystem (cubietruck mit 650 defined entities) kommt es bei aktviertem Log3 Wrapper phasenweise zu zusätzlichen Freezes, wenn der Threshold bei einer Sekunde liegt. Die Abarbeitung aller Devices und aller Trigger benötigt meist knapp eine Sekunde, manchmal aber auch mehr. Die zusätzlichen Log-Dumps scheinen das dann aufzuschaukeln :o Evtl wäre hier noch ein Hinweis in der command_ref wertvoll, den Thresholdwert auf einen vernünftigen Wert hochzusetzen.
Cheers,
Andy.
Neue Version ist eingecheckt und steht morgen mit dem Update zur Verfügung:
* angepasst an neue internal Timer (https://forum.fhem.de/index.php/topic,81365.0.html)
* Logging von loglevel 5 Meldungen bei freeze (nochmal danke gandy) mit zusätzlichem get-Befehl um komfortabel aufs Log zuzugreifen.
Hallo KernSani,
habe nun auch wieder das FREEZEMON Device aktiv, und werde es ab jetzt anstelle von Perfmon verwenden.
Es ist mir aufgefallen, dass (nach shutdown restart) einige Meldungen bei mir im log stehen:
2018.03.04 15:28:49 1: PERL WARNING: "my" variable $sfl masks earlier declaration in same scope at ./FHEM/98_freezemon.pm line 414, <$fh> line 3375.
2018.03.04 15:28:49 3: freezemon defined freezemon freezemon
2018.03.04 15:28:49 0: [FREEZEMON] freezemon: Wrapping Log3
2018.03.04 15:28:49 1: PERL WARNING: Subroutine main::Log3 redefined at ./FHEM/98_freezemon.pm line 741, <$fh> line 3380.
2018.03.04 15:28:49 1: Including ./log/fhem.save
......
......
2018.03.04 15:30:02 1: PERL WARNING: Subroutine HandleTimeout redefined at ./FHEM/98_apptime.pm line 42.
2018.03.04 15:30:02 1: PERL WARNING: Subroutine CallFn redefined at ./FHEM/98_apptime.pm line 151.
Der Fehler, in Verbindung mit apptime (einfrieren des Systems wenn apptime aktiv) sollte ja zwischenzeitlich gelöst sein.
Die Lösung mit fm_logFile gefällt mir sehr gut, hätte aber dazu noch eine Idee.
Wäre es möglich die erzeugten Logfiles nach XTagen automatisiert über ein einstellbares attr (1-30 Tage) wieder zu löschen?
Ich habe die Befürchtung, bei häufigen Freeze wird das Logfile ziemlich strapaziert, wenn hier nicht per Hand aufgeräumt wird.
Tolles Modul, Danke für deine Arbeit für die Fhem Gemeinde.
Gruß Reinhard
Gruß Reinhard
Hi Reinhard,
Zitat
2018.03.04 15:28:49 1: PERL WARNING: "my" variable $sfl masks earlier declaration in same scope at ./FHEM/98_freezemon.pm line 414, <$fh> line 3375.
Das ist mir auch schon aufgefallen und wird mit dem nächsten Update gefixt.
Zitat
PERL WARNING: Subroutine main::Log3 redefined at ./FHEM/98_freezemon.pm line 741, <$fh> line 3380.
liegt daran, dass freezemon (um die Level 5 Meldungen zu bekommen) die originale Log-Funktion überschreibt (ähnlich wie apptime das macht)
Ich bin mir übrigens nicht ganz sicher, ob apptime gefixt ist - Mein Testsystem ist auf fast aktuellem Stand und da ist es noch problematisch.
Logfile löschen dachte ich auch schon... Die Frage ist nur, wie ich das mache... Nach Datum ist schwerig, da man ja theoretisch auch ein Jahreslog für Freezemon definieren kann. Ich denke ich werde das ähnlich wie beim globalen Logfile machen (die letzten x logfiles behalten).
Neue Version eingecheckt, mit neuem Attribut fm_logKeep, wo man angeben kann, wieviele Logfiles behalten werden sollen.
Neue Version von apptime wurde übrigens von Martin auch heute eingecheckt.
Beides mit dem Update morgen verfügbar.
Hallo KernSani,
die Warnung wegen upptime kam gestern leider zu spät für mich, habe dieses aktiv geschaltet und die Logfunktion von Freezemon eingeschaltet. Ich kann dir sagen, alles hat so wie geplant funktioniert, die Logs werden wirklich zuverlässig erzeugt, in meinem Fall über 13200 Stück ::).
Eben habe ich das Update gemacht und Freezemon läuft nun wieder mit aktiven apptime und der Logfunktion, jetzt aber begrenzt auf 500 Dateien (gute Lösung von dir mit der Zahlenmäßigen Begrenzung).
Nach dem Update waren keinerlei Fehler von Frezemon mehr im Log zu sehen.
Bei mir läuft ständig eine Modbuskommunikation (alle 10 Sekunden), somit steht natürlich im Log von Freezemon immer als Verursacher der ModbusTCPServer, da dieser ja immer, auch während eines einfrieren aktiv ist. Dies erschwert natürlich jegliche Auswertung um den Verursacher zu finden. Ich muss mal meine Log's auf dem Raspi auswerten, eventuell kann ich ja da den Verursacher in den 5 Sekunden vor auftreten finden.
2018.03.05 17:48:14 1: PERL WARNING: Subroutine HandleTimeout redefined at ./FHEM/98_apptime.pm line 46.
2018.03.05 17:48:14 1: PERL WARNING: Subroutine CallFn redefined at ./FHEM/98_apptime.pm line 149.
2018.03.05 17:48:39 3: [Freezemon] freezemon: dumping 462 log entries to ./log/freeze-20180305-174839.log
2018.03.05 17:48:39 2: [Freezemon] freezemon: possible freeze starting at 17:48:37, delay is 2.557 possibly caused by ModbusTCPServer_Poll(N/A)
Die beiden Perl Warnungen bezüglich apptime stehen nach dem ersten Freeze immer noch im Log.
Gruß Reinhard
Hi Reinhard,
autsch... da war FHEM nur noch mit Logfiles schreiben beschäftigt :-S
Zu den Warnungen von apptime - die lassen sich nicht verhindern - auch wenn du apptime manuell startest tauchen die im Log auf (liegt einfach daran, dass apptime Routinen aus der fhem.pl überschreibt).
Bez. des Modbus: Ich habe auch so Kandidaten, die (fast) immer als mögliche Verursacher auftauchen. Ich denke über eine Blacklist nach, in die man die aufnehmen kann und die dann als mögliche Verursacher ignoriert werden (anders als die existierenden ignoreDev - bei denen der komplette Freeze ignoriert wird).
Zum Logging an sich: Wie Andy (der Erfinder des Loggings) sehe ich auf meinem Produktivsystem auch gelegentlich Ausreisser, bei denen das Logging selbst einen zusätzlichen Freeze verursacht, daher werde ich versuchen die ganze Freeze-Behandlung im Laufe der WOche mal auf non-blocking umzustellen.
Grüße,
Oli
Hallo Oli,
die Idee mit der Blacklist finde ich gut, somit können zumindest solche "Kandidaten" in den Hintergrund treten und machen die Sicht auf die wahrscheinlichsten Verursacher der Freezes frei.
Ich hatte auch den Eindruck Freezemon führt in einigen Fällen beim logging zum Freeze, Nonblocking würde da natürlich Abhilfe schaffen.
Ich denke einige attr kannst du dem Modul noch zumuten, aber es besteht immer die Gefahr wenn es zu viele werden, dass es von der Bedienung für "Neueinsteiger" nahezu nicht mehr zu verstehen ist. Den Ausgleich kann hier nur eine gute Doku (Wiki, Commandref) schaffen.
Auch das löschen der Log-Dateien funktioniert bei mir prima, spätestens Morgenvormittag werden ich sehen ob apptime jetzt OK ist. ;)
Danke nochmals für deine Arbeit.
Gruß Reinhard
Bei mir im LOG erscheinen zur Zeit immer wieder folgende Einträge:
2018.03.08 07:01:24 1: PERL WARNING: Use of uninitialized value $link in concatenation (.) or string at ./FHEM/98_freezemon.pm line 837.
2018.03.08 07:01:24 1: stacktrace:
2018.03.08 07:01:24 1: main::__ANON__ called by ./FHEM/98_freezemon.pm (837)
2018.03.08 07:01:24 1: main::freezemon_logLink called by ./FHEM/98_freezemon.pm (290)
2018.03.08 07:01:24 1: main::freezemon_ProcessTimer called by fhem.pl (3089)
2018.03.08 07:01:24 1: main::HandleTimeout called by fhem.pl (618)
Zitat von: michael.winkler am 08 März 2018, 09:15:59
Bei mir im LOG erscheinen zur Zeit immer wieder folgende Einträge:
2018.03.08 07:01:24 1: PERL WARNING: Use of uninitialized value $link in concatenation (.) or string at ./FHEM/98_freezemon.pm line 837.
2018.03.08 07:01:24 1: stacktrace:
2018.03.08 07:01:24 1: main::__ANON__ called by ./FHEM/98_freezemon.pm (837)
2018.03.08 07:01:24 1: main::freezemon_logLink called by ./FHEM/98_freezemon.pm (290)
2018.03.08 07:01:24 1: main::freezemon_ProcessTimer called by fhem.pl (3089)
2018.03.08 07:01:24 1: main::HandleTimeout called by fhem.pl (618)
Hi Michael,
habe aktuell keinen Zugriff, da ich beruflich unterwegs bin, aber auch ohne das Cosing zu sehen ist mir klar wo der Fehler liegt - werde ich am Wochenende fixen (Du hast das neue fm_fileLog Attribut nicht gepflegt, richtig?)
Grüße,
Oli
Zitat von: KernSani am 08 März 2018, 23:34:42
Hi Michael,
habe aktuell keinen Zugriff, da ich beruflich unterwegs bin, aber auch ohne das Cosing zu sehen ist mir klar wo der Fehler liegt - werde ich am Wochenende fixen (Du hast das neue fm_fileLog Attribut nicht gepflegt, richtig?)
Grüße,
Oli
ja, das ist richtig
Hallo Oli,
Ich bin auf dein Modul aufmerksam geworden und versuche es gerade zu nutzen.
Da ich seit ca. 1.5 Stunden noch keinen freeze hatte, und deshalb noch keine Erfahrungswerte bei mir vorliegen, wollte ich fragen, wie ich das folgende Attribut verstehen muss:
fm_log: dynamischer Loglevel, nimmt einen String der Form 10:1 5:2 1:3 entgegen, was bedeutet: Freezes > 10 Sekunden werden mit Loglevel 1 geloggt, >5 Sekunden mit Loglevel 2 usw...
Heißt das, dass bei LogLevel 1 viel geloggt wird?
Bei verbose ist es aber genau umgekehrt.
Vielen Dank
Gisbert
Hallo Gisbert,
das Attribut sorgt dafür dass du nur die kritischen Freezes siehst. Nehmen wir an, verbose ist auf 2, dann würdest du - mit den angegebenen Beispielwerten - nur Freezes ab einer Dauer von 5 Sekunden sehen, da diese mit level 2 (oder ab 10 Sekunden sogar mit level 1) geloggt werden.
War das verständlich?
Zum Testen habe ich übrigens ein AT, in dem ich einfach ein perl-sleep aufrufe ;-)
Kurz, weil mobil...
Hallo Oli,
dankeschön, deine Erklärung ist jetzt verständlich.
Noch 3 Fragen:
Was ist eine sinnvolle Zeit für das Attribut fm_logExtraSeconds? Ist 60 Sekunden viel zu lang?
Ist es richtig, dass der Logfile der mit dem Attribut fm_logFile erzeugt wird, nicht in der Übersicht (FileLog) in Fhem erscheint, sondern nur im Fileverzeichnis im RPi?
Wie sieht dein Test "AT ... sleep" genau aus?
Viele Grüße Gisbert
Hi Gisbert,
Ja, 60 Sekunden sind viel zu viel. Default (1 Sekunde) reicht normalerweise.
Das Logfile das erzeugt wird, wird nur in den angegebenen Folder gedumpt. Erreichbar ist es auch über die Übersicht, die man mit ,,get freezes" erhält
define myat at +00:00:02 {sleep(2)}
Kurz, weil mobil...
Mahlzeit!
Eine kurze Frage: Das Plotbeispiel für die Zahl der Freezes pro Tag plottet ja um einen Tag versetzt durch die Nutzung von fcDayLast, d. h. dem 10.03. wird der Wert vom 09.03. zugeordnet. Gibt es dafür eine elegante Lösung?
Patrick
Zitat von: PatrickR am 11 März 2018, 15:44:29
Mahlzeit!
Eine kurze Frage: Das Plotbeispiel für die Zahl der Freezes pro Tag plottet ja um einen Tag versetzt durch die Nutzung von fcDayLast, d. h. dem 10.03. wird der Wert vom 09.03. zugeordnet. Gibt es dafür eine elegante Lösung?
Patrick
Ich arbeite mit logproxy und einem negativem Offset...
Neue Version ist eingecheckt und steht morgen mit dem Update zur Verfügung:
1.) das zusätzliche Logfile (fm_logFile), das mitunter einige hundert EInträge haben kann, wird jetzt non-blocking geschrieben
2.) ein neues Attribut fm_whitelistSub ermöglicht es Subs, die permanent etwas tun (und daher immer bei "possibly caused by" auftauchen) zu ignorieren.
3.) Die Warnung (siehe Michaels Beitrag etwas weiter oben) kommt nicht mehr und ein/zwei andere kleine Bugfixes.
Hi,
leider habe ich immer noch Fehlermeldungen in meinem LOG
2018.03.13 03:21:19.414 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_freezemon.pm line 190.
2018.03.13 03:21:19.414 3: eval: {freezemon_freezeDone('myFreezemon')}
2018.03.13 03:21:19.414 1: stacktrace:
2018.03.13 03:21:19.414 1: main::__ANON__ called by ./FHEM/98_freezemon.pm (190)
2018.03.13 03:21:19.414 1: main::freezemon_freezeDone called by (eval 3420) (1)
2018.03.13 03:21:19.414 1: (eval) called by fhem.pl (1095)
2018.03.13 03:21:19.414 1: main::AnalyzePerlCommand called by fhem.pl (1118)
2018.03.13 03:21:19.414 1: main::AnalyzeCommand called by fhem.pl (1042)
2018.03.13 03:21:19.414 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (241)
2018.03.13 03:21:19.414 1: main::telnet_Read called by fhem.pl (3546)
2018.03.13 03:21:19.414 1: main::CallFn called by fhem.pl (706)
Gruß
Michael
Oh Mann, ich Hirsch...Den einen Bug gefixt, aber bei der Umstellung auf non-Blocking den gleichen Fehler nochmal gemacht. Sorry, kommt heute Abend...
Kurz, weil mobil...
Hi Michael,
Ich kann die Warnung bei mir leider nicht nachstellen... EIgentlich sollte die Sub garnicht ausgeführt werden, wenn du kein fm_logfile gepflegt hast, aber selbst wenn, dann dürfte keine WARNING kommen. Könntest du ein list von myFreezemon posten?
Danke,
Oli
Zitat von: KernSani am 13 März 2018, 22:27:40
Hi Michael,
Ich kann die Warnung bei mir leider nicht nachstellen... EIgentlich sollte die Sub garnicht ausgeführt werden, wenn du kein fm_logfile gepflegt hast, aber selbst wenn, dann dürfte keine WARNING kommen. Könntest du ein list von myFreezemon posten?
Danke,
Oli
anbei ein List ...
Internals:
NAME myFreezemon
NR 55
NTFY_ORDER 99-myFreezemon
STATE s:07:00:08 e:07:00:09 f:1.092 d:HttpUtils_Err(N/A) HttpUtils_Err(N/A) HttpUtils_Err(N/A) HttpUtils_Err(N/A) HttpUtils_Err(N/A) HttpUtils_Err(N/A)
TYPE freezemon
VERSION 0.0.17
READINGS:
2018-03-13 07:00:09 fcDay 9
2018-03-13 00:01:15 fcDayLast 3
2018-03-13 07:00:09 freezeDevice HttpUtils_Err(N/A) HttpUtils_Err(N/A) HttpUtils_Err(N/A) HttpUtils_Err(N/A) HttpUtils_Err(N/A) HttpUtils_Err(N/A)
2018-03-13 07:00:09 freezeTime 1.092
2018-03-13 07:00:09 ftDay 1083.85
2018-03-13 00:01:15 ftDayLast 3.43
2018-03-13 07:00:09 state s:07:00:08 e:07:00:09 f:1.092 d:HttpUtils_Err(N/A) HttpUtils_Err(N/A) HttpUtils_Err(N/A) HttpUtils_Err(N/A) HttpUtils_Err(N/A) HttpUtils_Err(N/A)
helper:
DISABLED 0
TIMER 1520976683
apptime 1520976689.68532-echodevice_GetSettings:ECHO_G000MW07735605DQ 1520976689.7019-echodevice_GetSettings:Amazon.echo 1520976689.96264-echodevice_GetSettings:ECHO_G090LV0363720DLW 1520976689.96495-echodevice_GetSettings:ECHO_G090L90964350E96 1520976690.39603-echodevice_GetSettings:ECHO_G090LF0964830SVM 1520976690.39903-echodevice_GetSettings:ECHO_G090L90964430DS6 1520976690.40217-echodevice_GetSettings:ECHO_774e1637fa004eae8a62a05adf3fdf64 1520976693.90135-echodevice_GetSettings:ECHO_G090L910732605D0 1520976702-FW_closeInactiveClients:N/A 1520976723.45121-echodevice_GetSettings:ECHO_f97a21db1d8e4f58b1e9e9936bd48051 1520976723.45142-echodevice_GetSettings:ECHO_960afe2ab0ad494c9256e39d443b0a90 1520976986.78941-CUL_HM_ActCheck:N/A 1520981940-at_Exec:FHEM.Backup 1520981940-at_Exec:MariaDB.Backup 1520982000-at_Exec:reboot 1520982001-FileLog_dailySwitch:N/A 1521039615.48292-CUL_HM_statCntRfresh:N/A
fn
freeze 1.09249305725098
intCount 6
logfile
msg [Freezemon] myFreezemon: possible freeze starting at 07:00:08, delay is 1.092 possibly caused by: HttpUtils_Err(N/A) HttpUtils_Err(N/A) HttpUtils_Err(N/A) HttpUtils_Err(N/A) HttpUtils_Err(N/A) HttpUtils_Err(N/A)
now 1520920809.09249
logqueue:
Attributes:
room ZZ_FHEM
Danke für die schnelle Antwort... Ich bekomme es aber immernoch nicht nachgestellt (und kann es auch nicht logisch nachvollziehen, wie es an der Stelle zu einer WARNING kommen kann).
Angehängte Version sollte das Problem aber trotzdem beheben. Wäre dankbar für ein kurzes Feedback.
Danke,
Oli
Habe heute auch mal dein Modul in meinem aktiven System eingesetzt und bekomme regelmäßig folgende Meldung:
2018-03-14: s:18:12:40 e:18:12:43 f:3.1 d:RESIDENTStk_DurationTimer(rr_Anja_DurationTimer) RESIDENTStk_DurationTimer(rr_Etienne_DurationTimer) RESIDENTStk_DurationTimer(rgr_Zuhause_DurationTimer) MQTT((Timer(Mosquitto) RESIDENTStk_DurationT...
Das heißt wenn ich nun rr_Etienne,rr_Anja,rgr_Zuhause,Mosquitto auf die ignore-liste setze, dann bekomme ich diese Meldung nicht mehr? Und denkst du ich sollte den Modulmaintainer informieren, dass seine Funktion DurationTimer regelmäßig länger als 2 Sekunden (thereshold steht bei mir auf 2sek) brauchen?
Hi Etienne,
Die Residents sind nicht die Ursache... Die kommen bei mir auch laufend. Vielleicht mal im Log schauen, ob da nicht noch was anderes läuft. Freezemon versucht nur aufgrund der internen Timer zu erraten, was einen Freeze verursachen könnte, aber es ist eben nicht alles Timer-gesteuert...
Wenn du das Device auf die ignoreDevs setzt, wird der Freeze nicht mehr geloggt. Wenn du die Sub auf die Whitelist setzt, werden die Freezes noch geloggt, aber die Residents als Verursacher ausgeschlossen.
Grüße,
Oli
Kurz, weil mobil...
Na dann werde ich das mal so machen und schauen. Ansonsten cooles Modul. Dank dir dafür Oli.
Danke für das Modul, gefällt mir bisher sehr gut!
Eine kleine Warning beim Start von FHEM bekomme ich aber:
2018.03.17 15:31:54.836 3: freezemon defined sys_freezemon freezemon
2018.03.17 15:31:54.837 0: [Freezemon] sys_freezemon: Wrapping Log3
2018.03.17 15:31:54.837 1: PERL WARNING: Subroutine main::Log3 redefined at ./FHEM/98_freezemon.pm line 823, <$fh> line 2973.
Um die verbose 5 Meldungen abzufangen überschreibt Freezemon die Log3 Funktion, das erzeugt eine Warnung... (Ähnliches Prinzip wie bei apptime, da gibt's auch Warnungen). Och schau mal, ob ich das irgendwie unterdrücken kann.
Kurz, weil mobil...
Schon so ein bisschen geahnt, dass das prinzipbedingt sein könnte. Im Zweifel könnte man ja evtl. davor noch eine Logzeile machen so in der Art "nicht wundern: gleich kommt ne Warning" ^^
Neue Version zum Testen im Anhang. Feedback wie immer willkommen.
- Die Warnungen beim überschreiben von FHEM-Funktionenetc... werden nun unterdrückt
- Neues Attribut: fm_catchCallFn: wenn aktiviert, werden zusätzlich FHEM-interne Funktionsaufrufe überwacht, in einigen Fällen kann das zusätzliche Hinweise auf den Freeze-Verursacher geben
- Neues Attribut: fm_catchCmds: wenn aktiviert, werden zusätzlich FHEM-Kommandos überwacht, in einigen Fällen kann das zusätzliche Hinweise auf den Freeze-Verursacher geben
Hi,
nach dem ersten Setup meines FHEM-Systems vor gut 2 Jahren habe ich mal mit perfmon aufgeräumt. In letzter Zeit waren mir dann wieder "freezes" aufgefallen - die konnte ich auf Yeelight zurückführen und dank der Version von "vbs" beseitigen.
Allerdings habe ich immer noch einen Freeze von 2-3sec, der ziemlich genau alle 63 Sekunden auftritt. Danke freezemon komme ich jetzt zu folgender Auswertung:
1 - 2018-03-21 [Log]: s:10:56:52 e:10:56:55 f:3.086 d:TSCUL_XmitAwaitTo(N/A) TSCUL_SendPingHM(N/A) TSCUL_Timed_Clear_SlowRF_Stat(N/A) HttpUtils_E...
1 - 2018-03-21 [Log]: s:10:57:55 e:10:57:58 f:3.009 d:no bad guy found :-(
1 - 2018-03-21 [Log]: s:10:58:59 e:10:59:01 f:2.103 d:CUL_HM_procQs(N/A)
1 - 2018-03-21 [Log]: s:11:00:02 e:11:00:04 f:2.421 d:no bad guy found :-(
1 - 2018-03-21 [Log]: s:11:01:04 e:11:01:07 f:3.009 d:no bad guy found :-(
1 - 2018-03-21 [Log]: s:11:02:08 e:11:02:10 f:2.042 d:TSCUL_SendPingHM(N/A) TSCUL_XmitAwaitTo(N/A)
1 - 2018-03-21 [Log]: s:11:03:11 e:11:03:13 f:2.859 d:no bad guy found :-(
1 - 2018-03-21 [Log]: s:11:04:13 e:11:04:16 f:3.007 d:no bad guy found :-(
1 - 2018-03-21 [Log]: s:11:05:17 e:11:05:19 f:2.084 d:DbLog_execmemcache(dblog) BlockingKill(TK.KG.FB)
1 - 2018-03-21 [Log]: s:11:06:20 e:11:06:22 f:2.067 d:DbLog_execmemcache(dblog) BlockingKill(KL.OG.FTV.pres)
Also in rund der Hälfte der Fälle ein "no bad guy found".
Mein System läuft auf einem NUC - generell habe ich keine Performance-Probleme - aber für Tipps, wie ich diesen freeze rauskriege (ohne device für device zu löschen) bin ich sehr dankbar.
Achja: Als Feedback: Gutes Modul - perfmon und apptime erledigen zwar auch viel von dem Job, aber so finde ich es komfortabler. Danke hierfür.
Gruß,
Tom
Hi Tom,
der erste Schritt wäre mal das fm_logFile Attribut zu setzen, dann bekommst du ein verbose 5 Log von jedem Freeze, das vielleicht zusätzliche Erkenntnisse liefert. Wenn du mutig bist kannst du auch noch die 2 Posts weiter oben angehängte Version ausprobieren, die nochmal ein paar mehr Erkenntnisse liefern kann. Bei mir läuft sie seit ein paar Tagen stabil im Produktivsystem.
Grüße,
Oli
Hi Oli,
das Logfile läuft bei mir schon - das hat jetzt im ersten Ansatz auch nicht wirklich was gebracht. Dann habe ich schon diverse Module / Devices gekillt, die oben in der Liste uaftauchen - no avail. Hat auch nichts gebracht -nur mehr "no bad guys...". Und andere Kandidaten rücken nach vorne. Aber da geht es dann schon an echte phys. IO-Devices (Culs etc).
Ich teste ab morgen mal Deine neue Version.
Was mir aufgefallen ist (Irrtum oder falsche config) Das Logfile beginnt ziemlich genau dann, wenn der Freeze zuende ist - und nicht ein paar Sekunden vorher. Wenn also der Freeze laut Meldung um 10:05:02 beginnt und 3 sekunden dauert, beginnt das Logfile ungefähr um 10:05:05. Entweder mach ich was falsch oder ... works as designed - aber ich dachte, man müsse das log ab beginndes freezes betrachten - zumindest habe ihc das immer so bei perfmon gemacht.
In jedem Fall danke - morgen abend mehr feedback.
Tom
hallo tom,
ZitatDann habe ich schon diverse Module / Devices gekillt, die oben in der Liste uaftauchen - no avail. Hat auch nichts gebracht -nur mehr "no bad guys...". Und andere Kandidaten rücken nach vorne.
denk mal genau darüber nach, was bei sich bei dir alle 60 sek wiederholt. at's, sysmon, presence, fritzbox, ...
eventuell auch mal apptime clearen und nach genau einer stunde aufrufen und einträge mit count~60 suchen.
Hi Tom,
ich habe hier einen bösen Verdacht. Freezemon macht ein paar Dinge jede Minute (Überprüfen ob apptime läuft, wenn das Attribut gesetzt ist etc...). Mir ist nicht wirklich klar, wie das einen Freeze verursachen könnte, aber das würde auch erklären, warum dein Log nicht so aussieht, wie es aussehen sollte.
Das sollten wir heute abend mal genauer untersuchen...
Grüße,
Oli
Zitat von: frank am 22 März 2018, 09:40:14
hallo tom,
denk mal genau darüber nach, was bei sich bei dir alle 60 sek wiederholt. at's, sysmon, presence, fritzbox, ...
eventuell auch mal apptime clearen und nach genau einer stunde aufrufen und einträge mit count~60 suchen.
Hi Frank,
was sich alle 60 Sekunde wiederholt - inklusive aller "at" - habe ich überprüft, auf 120sek gestellt, einfach gelöscht - keine Änderung. Das war die erste Maßnahme, die ich dieses Mal auch wieder angeleiert habe.
Das mit apptime und eine Stunde warten - gefällt mir.
Ich steige jetzt erstmal auf die neueste Version um und schaue mir dann das Verhalten an.
Gruß,
Tom
Zitat von: KernSani am 22 März 2018, 11:57:54
Hi Tom,
ich habe hier einen bösen Verdacht. Freezemon macht ein paar Dinge jede Minute (Überprüfen ob apptime läuft, wenn das Attribut gesetzt ist etc...). Mir ist nicht wirklich klar, wie das einen Freeze verursachen könnte, aber das würde auch erklären, warum dein Log nicht so aussieht, wie es aussehen sollte.
Das sollten wir heute abend mal genauer untersuchen...
Grüße,
Oli
Jederzeit. ;-) Und danke.
Hi Tom,
ich habe das nochmal gecheckt. Eigentlich macht freezemon nur wenige Dinge jede Minute:
1.) Checken ob apptime läuft und ggf. starten - kannst du einfach unterbinden, indem du fm_forceApptime löschst oder auf 0 setzt
2.) Checken ob wir einen neuen Tag haben und - wenn ja - die lastDay values setzen (das sollte wirklich keinen Freeze verursachen)
3.) ALte log files löschen - kannst du einfach unterbinden, indem du fm_logKeep löschst.
Kannst du 1. und 3. mal ausprobieren und zusätzlich ein list des freezemon-devices posten?
Danke,
Oli
Moin,
also in der Nacht haben sich natürlich die erwarteten 400++ freezes angesammelt ;-) Immerhin ist Verlass auf das Phänomen.
Habe jetzt die von Dir vorgeschlagenen Änderungen durchgeführt, das Device nochmal neu initialisiert (nicht, dass da noch bit-rot rumliegt) und schaue zu, wie der Zähler minütlich hochgeht.
Alle 62-64 Sekunden wieder zuverlässig der Eintrag. Vermutlich werde ich am Wochenende tatsächlich mal Device für Device rauslöschen.
Internals:
CFGFN
NAME freeze
NR 515
NTFY_ORDER 99-freeze
STATE s:08:10:19 e:08:10:22 f:3.009 d:no bad guy found :-(
TYPE freezemon
VERSION 0.0.16
READINGS:
2018-03-23 08:10:22 fcDay 4
2018-03-23 08:07:04 fcDayLast 0
2018-03-23 08:10:22 freezeDevice no bad guy found :-(
2018-03-23 08:10:22 freezeTime 3.009
2018-03-23 08:10:22 ftDay 10.968
2018-03-23 08:07:04 ftDayLast 0
2018-03-23 08:10:22 state s:08:10:19 e:08:10:22 f:3.009 d:no bad guy found :-(
helper:
DISABLED 0
TIMER 1521789031
apptime 1521789030.56895-at_Exec:SZ.OG.CUL.at 1521789038.37998-PRESENCE_StartLocalScan:KL.OG.FTV.pres
fn
freeze 3.00900793075562
intCount 2
logfile ./log/freeze-20180323-081022.log
msg [Freezemon] freeze: possible freeze starting at 08:10:19, delay is 3.009 possibly caused by: no bad guy found :-(
now 1521789022.00901
logqueue:
ARRAY(0x56400bfdbc08)
ARRAY(0x56400bf002f0)
ARRAY(0x56400bfa02b8)
ARRAY(0x56400bde7d48)
ARRAY(0x56400beeb758)
ARRAY(0x56400bfba460)
ARRAY(0x56400bf01780)
ARRAY(0x56400bfc5740)
ARRAY(0x56400bf93e08)
ARRAY(0x56400b3297d0)
ARRAY(0x56400bf8ce38)
ARRAY(0x56400bf55cc0)
ARRAY(0x56400bfbbc00)
ARRAY(0x56400beeacf0)
ARRAY(0x56400bf48d18)
ARRAY(0x56400be156f0)
Attributes:
fm_extDetail 1
fm_forceApptime 0
fm_freezeThreshold 2
fm_logFile ./log/freeze-%Y%m%d-%H%M%S.log
room ,system
Ein paar Minuten weiter und ich habe wieder folgende Meldungen beisammen:
1 - 2018-03-23 [Log]: s:08:07:10 e:08:07:13 f:3.007 d:no bad guy found :-(
1 - 2018-03-23 [Log]: s:08:08:14 e:08:08:16 f:2.452 d:PWM_Calculate(FBH.COMF.PWM) DbLog_execmemcache(dblog) TSCUL_SendPingHM(N/A)
1 - 2018-03-23 [Log]: s:08:09:17 e:08:09:19 f:2.5 d:PWM_Calculate(FBH.COMF.PWM) DbLog_execmemcache(dblog) TSCUL_SendPingHM(N/A) JeeLink_OnTimer(N...
1 - 2018-03-23 [Log]: s:08:10:19 e:08:10:22 f:3.009 d:no bad guy found :-(
1 - 2018-03-23 [Log]: s:08:11:23 e:08:11:25 f:2.363 d:PWM_Calculate(FBH.COMF.PWM) LaCrosseGateway_OnConnectTimer(KU.ELW.LGW) DbLog_execmemcache(d...
1 - 2018-03-23 [Log]: s:08:12:26 e:08:12:28 f:2.354 d:PWM_Calculate(FBH.COMF.PWM) DbLog_execmemcache(dblog) TSCUL_SendPingHM(N/A)
1 - 2018-03-23 [Log]: s:08:13:28 e:08:13:31 f:3.014 d:FW_closeInactiveClients(N/A)
Bin echt clueless - zumal ich beide regelmäßig auftretende Devices (PWM/PWMR zur Heizungssteuerung und DBLOG) schon gelöscht habe - dann rutschen nur andere Kandidaten nach und es gibt mehr "no bad guys found" Meldungen. Bleibt wohl nur systematisches Löschen der devices - und bei den klassischen IO-Devs (MAX, TSCUL, 1-wire, Lacrosse Gateway...) habe ich bisher diesen Schritt nicht machen wollen.
Danke in jedem Fall für die Hilfe.
Tom
So,
gelöst.
Es blieb ja nichts anderes übrig als Device für Device zu löschen und zu schauen, ob die Freezes aufhören. Angefangen bei 20 Fensterkontakten,15 Homematic devices, der gesamten PWM-Steuerung für die Fußbodenheizung und 17 Heizkreisläufe, sämtliche Timer... bis hin zu den IO-Devices (CUL, 1wire, CUN, HM-CFG-LAN...)
Naja, am Ende ist es immer so, dass erst ganz am Ende der Freeze ausblieb... als ich eine XBMC-Definition gelöscht habe (jetzt KODI).
Von vermeintlich 4 XBMC-Devices war bei dem fraglichen Device das "fork" Attribut nicht gesetzt - und das hat bei ausgeschalteten XBMC dafür gesorgt, dass regelmäßig diese Freezes auftraten. Steht sogar in der commandref. Wäre ich aber trotz mehrfachen Lesens nicht drauf gekommen, da ich solche Attribute über cmdalias direkt auf alles Devices eines Typs setze.
Egal.
Danke an alle, die mir bei der Suche geholfen haben, insbesondere an KernSani für freezemon, hermannj für perfmon und alle anderen, die mir via PM oder Antwort Tips gegeben haben.
Endlich ein nahezu freezefreier FHEM-Server.
Danke, Tom
Ist ja cool, dass du es gefunden hast, was mich aber sehr irritiert, ist das der Kodi nicht in den "possibly caused by" auftaucht. Ich habe mir das Modul angesehen und es verwendet (wie nicht anders zu erwarten) die ganz normale InternalTimer Funktion - und die sollte Freezemon eigentlich finden...Kannst du mal noch eines der logfiles posten?
Btw.: Ich würde dir empfehlen, das fm_logKeep Attribut zu setzen (bei mir steht es auf 100), sonst müllt dir Freezemon die Platte voll...
Hi Oli,
über folgenden Fall bin ich etwas verwundert
2018.03.24 04:57:06 3: FRITZBOX: get Fritzbox tr064Command WANIPConnection:1 wanipconnection1 ForceTermination
2018.03.24 04:57:07 2: FRITZBOX Fritzbox: TR064_Cmd.4302 TR064-Error 707:DisconnectInProgress (service='WANIPConnection:1', control='wanipconnection1', action='ForceTermination')
2018.03.24 04:57:07 3: act_on_FB_Inet_check return value: Service='WANIPConnection:1' Control='wanipconnection1' Action='ForceTermination'
----------------------------------------------------------------------
$VAR1 = {
'UPnPError' => {
'errorDescription' => 'DisconnectInProgress',
'errorCode' => '707'
}
};
2018.03.24 04:57:12 1: [Freezemon] freezedetect: possible freeze starting at 04:57:07, delay is 5.873 possibly caused by: NEUTRINO_GetStatus(DBox) at_Exec(check_jammer) echodevice_GetSettings(echo) GPIO4_DeviceUpdateLoop(RPi_OW_KS)
2018.03.24 04:57:13 3: [Freezemon] freezedetect: possible freeze starting at 04:57:13, delay is 0.507 possibly caused by: GPIO4_DeviceUpdateLoop(RPi_OW_VT) GPIO4_DeviceUpdateLoop(RPi_OW_RT) GPIO4_DeviceUpdateLoop(RPi_OW_WW) GPIO4_DeviceUpdateLoop(RPi_OW_WZ) GPIO4_DeviceUpdateLoop(RPi_OW_TC1) GPIO4_DeviceUpdateLoop(RPi_OW_TCar) GPIO4_DeviceUpdateLoop(RPi_OW_TK) GPIO4_DeviceUpdateLoop(RPi_OW_SL) GPIO4_DeviceUpdateLoop(RPi_OW_ZW) fitbit_poll(fitbit_D485470325) SYSMON_Update(sys_mon) STV_Init(Fernseher) fitbit_poll(fitbit_U62ZJV3) HttpUtils_Err(N/A) GPIO4_DeviceUpdateLoop(RPi_OW_WWL) at_Exec(check_jammer) HttpUtils_Err(N/A) BlockingKill(N/A)
2018.03.24 04:57:13 3: [Freezemon] freezedetect: dumping 41 log entries to ./log/freeze-20180324.log
2018.03.24 04:57:13 3: [Freezemon] freezedetect: dumping 79 log entries to ./log/freeze-20180324.log
Der Verursacher ist klar. Aber wieso ein kurzer freeze während einem langen ??? Ggfs. kann ich das Freeze-Log zur Verfügung stellen.
Könntest Du die Ausgabe der "gedumpten Log-Entries" auf Level 4 oder 5 stellen ? Hat irgendwie nicht so wirklich einen besonderen Informationsgehalt und macht das Log aber unübersichtlicher/voller.
<OT> hier (https://forum.fhem.de/index.php/topic,86012.msg785961.html#msg785961) könnte ich Dich unterstützen<OT>
Grüße Markus
Hi Markus,
die Freezes kommen direkt hintereinander. Die Dumpausgabe erfolgt per blockingCall und kommt deshalb verzögert.
Loglevel ist bei meiner aktuellen Testversion schon geändert (hat mich auch genervt ;))
Bez. Offtopic: Danke :-)
Kurz, weil mobil...
Zitat von: KernSani am 24 März 2018, 00:18:22
Ist ja cool, dass du es gefunden hast, was mich aber sehr irritiert, ist das der Kodi nicht in den "possibly caused by" auftaucht. Ich habe mir das Modul angesehen und es verwendet (wie nicht anders zu erwarten) die ganz normale InternalTimer Funktion - und die sollte Freezemon eigentlich finden...Kannst du mal noch eines der logfiles posten?
Btw.: Ich würde dir empfehlen, das fm_logKeep Attribut zu setzen (bei mir steht es auf 100), sonst müllt dir Freezemon die Platte voll...
Siehe PM - bei logfiles ist das so ne Sache ;-)
Danke für den Tip mit den Logfiles - aber da läuft bei mir logrotate...
Wie bekomme ich diese Meldung weg:
MQTT((Timer(Mosquitto)
Weder fm_ignoreDev Mosquitto noch fm_whitelistSub MQTT hat geholfen. Irgendwas mache ich falsch. Das Device heißt Mosquitto und die Funktion doch MQTT, wenn ich das richtig sehe, oder nicht?
Hi Etienne,
irgendwie sieht das komisch aus... die Klammersetzung stimmt nicht...
Das Device Mosquitto ist korrekt, aber die sub die aufgerufen wird ist MQTT::Timer. Da der Doppelpunkt bei Freezemon als Trennzeichen verwendet wird, scheint das nicht korrekt aufgelöst (und später bei der Ausgabe dann nicht korrekt formatiert) zu werden. Du kannst mal versuchen, "MQTT::Timer" in die whitelist aufzunehmen.
Grüße,
Oli
Na schau an, werde ich heute Abend mal versuchen. Dank dir.
Hallo zusammen,
ich nehme gerade einen größeren (internen) Umbau an Freezemon vor. in diesem Zuge würde ich gerne zwei Attribute entfernen, da ich sie persönlich für unnötig halte, würde aber gerne eure Meinung dazu hören:
* disable: die Funktionalität ist durch set inactive/active abgedeckt. die Kombination der beiden kann meiner Meinung nach nur zu Verwirrung führen.
* fm_logExtraSeconds: Aus meiner persönlichen Erfahrung macht es keinen Sinn hier einen Sekundenwert anzugeben, der default (1 Sekunde vor Beginn des Freezes) ist m.E. ausrecihend
Wenn irgendwer diese Attribute nutzt, bitte melden, ansonsten werde ich sie ausbauen.
Grüße,
Oli
Ich persönlich bin ja lieber ein Freund von disable, als von einem eigenen inactive oder so. Finde das passt besser zum gesamt System, weil es auch bei anderen Modulen so ist.
Ja, wollte auch gerade schreiben, dass das disable-Attribut der in fhem deutlich üblicher zu sein scheint.
Zitat* disable: die Funktionalität ist durch set inactive/active abgedeckt
mir egal. Habs immer aktiv. Immer interessant. ;D
Zitat* fm_logExtraSeconds: Aus meiner persönlichen Erfahrung macht es keinen Sinn hier einen Sekundenwert anzugeben
braucht man nicht.
Zitat von: Amenophis86 am 02 April 2018, 20:06:35
Ich persönlich bin ja lieber ein Freund von disable, als von einem eigenen inactive oder so. Finde das passt besser zum gesamt System, weil es auch bei anderen Modulen so ist.
Ok, dann lass ich das drin... Attribut benötigt nur immer ein "Save"... Ich schau mir mal genau an, wie andere Module (z.B. "at") das handhaben, wenn active/inactive und disable nicht zusammen passen.
Nimm lieber das Attribut dann kannst mit der Funktion
IsDisabled($name)
abfragen.
Zitat von: CoolTux am 02 April 2018, 22:06:05
Nimm lieber das Attribut dann kannst mit der Funktion
IsDisabled($name)
abfragen.
isDisabled hört auch auf state und STATE "inactive"... nutze ich schon ;-)
Hallo Oli,
ich hab heute morgen (ca. 8:25) das Modul 98_freezemon.pm upgedatet, d.h. nur dieses einzelne Modul.
Das Ergebnis war folgendes :(:
2018.04.03 08:27:48 3: freezemon defined myFreezemon freezemon
Undefined subroutine &main::isDisabled called at .//FHEM/98_freezemon.pm line 595, <$fh> line 35.
Und die Konsequenz war, dass Fhem nicht mehr erreichbar war.
Ich hab dann den RPi runtergefahren, es kam die gleiche Reaktion, wieder :(:
2018.04.03 08:42:28 3: freezemon defined myFreezemon freezemon
Undefined subroutine &main::isDisabled called at .//FHEM/98_freezemon.pm line 595, <$fh> line 35.
Nachdem ich aus dem Backup die Vorgängerversion nach Fhem geschoben habe, startet Fhem auch wieder.
Viele Grüße Gisbert
Edit:
Noch ein list meines freezemons, nachdem es wieder mit der Vorgängerversion läuft:
Internals:
CFGFN ./FHEM/NetzwerkRPiPerformance.cfg
NAME myFreezemon
NR 393
NTFY_ORDER 99-myFreezemon
STATE Last freeze:<br/>2018-04-03 08:51:32
TYPE freezemon
VERSION 0.0.18
READINGS:
2018-04-03 08:51:32 Zeitstempel 2018-04-03 08:51:32
2018-04-03 08:51:32 fcDay 7
2018-04-03 00:00:00 fcDayLast 16
2018-04-03 08:51:32 freezeDevice CUL_HM_respPendTout(N/A) BlockingKill(N/A)
2018-04-03 08:51:32 freezeTime 3.746
2018-04-03 08:51:32 ftDay 189.187
2018-04-03 00:00:00 ftDayLast 34.387
2018-04-03 08:51:32 state s:08:51:29 e:08:51:32 f:3.746 d:CUL_HM_respPendTout(N/A) BlockingKill(N/A)
helper:
DISABLED 0
TIMER 1522738831
apptime 1522738832.81047-HMLAN_KeepAlive:N/A 1522738834.02203-HMUARTLGW_CheckCredits:N/A 1522738835.25623-PRESENCE_StartLocalScan:LGG6 1522738837.75537-PRESENCE_StartLocalScan:SamsungGalaxyA5 1522738838.05528-PRESENCE_StartLocalScan:MotorolaG2 1522738839.16352-PRESENCE_StartLocalScan:Honor8 1522738858.99659-SYSMON_Update:RPi.Sysmon 1522738860-DOIF_TimerTrigger:Garagentor.Alarm 1522738863.6728-at_Exec:heartbeat 1522738864.49735-CUL_HM_ActCheck:N/A 1522738868-DOIF_TimerTrigger:Klingeln 1522738868.63763-MQTT::Timer:MyBroker 1522738869.04886-HTTPMOD_GetUpdate:N/A 1522738869.05737-HTTPMOD_GetUpdate:N/A 1522738869.06152-HTTPMOD_GetUpdate:N/A 1522738869.06525-HTTPMOD_GetUpdate:N/A 1522738869.06895-HTTPMOD_GetUpdate:N/A 1522738869.07278-HTTPMOD_GetUpdate:N/A 1522738869.18854-TRAFFIC_StartUpdate:DormagenNachhause 1522738869.20379-TRAFFIC_StartUpdate:ZuhauseDormagen 1522738869.20459-TRAFFIC_StartUpdate:DormagenKoelnLuetticherStr 1522738869.2142-BlockingKill:N/A 1522738869.2403-HTTPMOD_GetUpdate:N/A 1522738869.24528-HTTPMOD_GetUpdate:N/A 1522738869.24896-HTTPMOD_GetUpdate:N/A 1522738869.2527-HTTPMOD_GetUpdate:N/A 1522738869.25657-HTTPMOD_GetUpdate:N/A 1522738869.26032-HTTPMOD_GetUpdate:N/A 1522738869.26399-HTTPMOD_GetUpdate:N/A 1522738871.18345-SIGNALduino_KeepAlive:mySIGNALduino 1522738876.60892-DOIF_SleepTrigger:Anwesenheit.Zuhause 1522738877-FW_closeInactiveClients:N/A 1522738879.02468-FRITZBOX_Readout_Start:N/A 1522738879.05074-FRITZBOX_Readout_Start:N/A 1522738898.99099-Weather_GetUpdate:Wetter.Leverkusen 1522738912.95951-DOIF_SleepTrigger:Warmwasser.Zirkulation 1522738920-DOIF_TimerTrigger:SensorAktualitaet 1522738943.16762-Buienradar_ScheduleUpdate:Buienradar 1522738968.87013-at_Exec:at.Haushaltsraum.Ventilator.on 1522738980-DOIF_TimerTrigger:SensorAktualitaet 1522738988.68285-AMADDevice_checkDeviceState:myLGG6 1522739039.80477-HttpUtils_Err:N/A 1522739100-DOIF_TimerTrigger:SensorAktualitaet 1522739118-Twilight_sunpos:myTwilight_sunpos 1522739409.26023-TRAFFIC_StartUpdate:ZuhauseDeutz 1522740058.65412-CUL_HM_complConfigTO:N/A 1522740068.95066-PROPLANTA_Start:Wetter.Proplanta 1522740092.81008-CUL_HM_qStateUpdatIfEnab:N/A 1522740600-DOIF_TimerTrigger:SensorAktualitaet 1522740660-DOIF_TimerTrigger:SensorAktualitaet 1522740720-DOIF_TimerTrigger:SensorAktualitaet 1522740780-DOIF_TimerTrigger:SensorAktualitaet 1522740840-DOIF_TimerTrigger:SensorAktualitaet 1522740900-DOIF_TimerTrigger:SensorAktualitaet 1522741878.92477-Astro_Update:myAstro 1522741884.49829-airquality_GetUpdate:Luftqualitaet 1522742395-statistics_PeriodChange:Statistik 1522742400-DOIF_TimerTrigger:Warmwasser.Zirkulation 1522742400.19774-HourCounter_Run:N/A 1522742400.22994-HourCounter_Run:N/A 1522743658.86785-speedtest_GetUpdate:Speedtest 1522751400-DOIF_TimerTrigger:Update.FHEM 1522752300-DOIF_TimerTrigger:Update.FHEM 1522752671.18001-Calendar_Wakeup:Muelltonnen.Kalender.AVEA 1522753200-DOIF_TimerTrigger:Treppenhaus.Markisensteuerung 1522759871.793-Calendar_Wakeup:NRW.Feiertage.Kalender 1522759873.0293-Pushover_ValidateUser:Pushover.Nachricht 1522769400-DOIF_TimerTrigger:Muellabfuhr 1522773891.95-Twilight_WeatherTimerUpdate:myTwilight_weather 1522777491.95-Twilight_fireEvent:myTwilight_ss_weather 1522778106.96-Twilight_fireEvent:myTwilight_ss_indoor 1522778491.97-Twilight_fireEvent:myTwilight_ss 1522779640-DOIF_TimerTrigger:Schalter.1.Schaltzeit 1522779940-DOIF_TimerTrigger:Haustuer.Licht.Aus 1522780180-DOIF_TimerTrigger:Haustuer.Licht.Schaltzeit 1522780240-DOIF_TimerTrigger:SensorAktualitaet 1522780240-DOIF_TimerTrigger:Terrasse.Licht.Schaltzeit 1522780480-DOIF_TimerTrigger:Terrasse.Licht.Schaltzeit 1522780510-DOIF_TimerTrigger:CamWatchAlarm.on 1522780839.98-Twilight_fireEvent:myTwilight_ss_civil 1522783285.99-Twilight_fireEvent:myTwilight_ss_naut 1522783800-DOIF_TimerTrigger:Warmwasser.Zirkulation 1522785155-DOIF_TimerTrigger:Terrasse.Licht.Schaltzeit 1522785540-DOIF_TimerTrigger:Warmwasser.Zirkulation 1522785600-DOIF_TimerTrigger:Haushaltsraum.Lueftung 1522785600-DOIF_TimerTrigger:Treppenhaus.Markisensteuerung 1522785600-DOIF_TimerTrigger:Warmwasser.Zirkulation 1522785660-DOIF_TimerTrigger:Warmwasser.Zirkulation 1522785912-Twilight_fireEvent:myTwilight_ss_astro 1522786706-DOIF_TimerTrigger:Haustuer.Licht.Aus 1522787400-DOIF_TimerTrigger:Anwesenheit.Zuhause 1522787400-DOIF_TimerTrigger:Muellabfuhr 1522787401-DOIF_TimerTrigger:Anwesenheit.Zuhause 1522792801-Twilight_Midnight:myTwilight_Midnight 1522792801-FileLog_dailySwitch:N/A 1522805940-DOIF_TimerTrigger:Warmwasser.Zirkulation 1522806000-DOIF_TimerTrigger:Warmwasser.Zirkulation 1522807560-DOIF_TimerTrigger:Warmwasser.Zirkulation 1522809540-DOIF_TimerTrigger:Warmwasser.Zirkulation 1522809600-DOIF_TimerTrigger:Warmwasser.Zirkulation 1522810258.45588-CUL_HM_statCntRfresh:N/A 1522811160-DOIF_TimerTrigger:Warmwasser.Zirkulation 1522813500-DOIF_TimerTrigger:Warmwasser.Zirkulation 1522814340-DOIF_TimerTrigger:Warmwasser.Zirkulation 1522814400-DOIF_TimerTrigger:Warmwasser.Zirkulation 1522816199-DOIF_TimerTrigger:Anwesenheit.Zuhause 1522816200-DOIF_TimerTrigger:Anwesenheit.Zuhause 1522816200-DOIF_TimerTrigger:Schalter.1.Schaltzeit 1522816800-DOIF_TimerTrigger:Haustuer.Licht.Aus 1522816987-DOIF_TimerTrigger:CamWatchAlarm.on 1522817100-DOIF_TimerTrigger:Haustuer.Licht.Schaltzeit 1522817395-DOIF_TimerTrigger:SensorAktualitaet 1522817495-DOIF_TimerTrigger:Haustuer.Licht.Aus 1522817495-DOIF_TimerTrigger:Terrasse.Licht.Schaltzeit 1522818000-DOIF_TimerTrigger:Haushaltsraum.Lueftung 1522818900-DOIF_TimerTrigger:Schalter.1.Schaltzeit 1522819800-DOIF_TimerTrigger:Muellabfuhr 1522820700-DOIF_TimerTrigger:Haustuer.Licht.Schaltzeit 1522823400-DOIF_TimerTrigger:Muellabfuhr 1523337487.60984-FB_CALLLIST_deleteExpiredCalls:N/A
fn
freeze 3.74677109718323
intCount 18
logfile ./log/myFreezemon-2018-04-03.log
msg [Freezemon] myFreezemon: possible freeze starting at 08:51:29, delay is 3.746 possibly caused by: CUL_HM_respPendTout(N/A) BlockingKill(N/A)
now 1522738292.74677
bm:
freezemon_Get:
cnt 1
dmx -1000
dtot 0
dtotcnt 0
mTS 03.04. 09:00:14
max 0.00111889839172363
tot 0.00111889839172363
mAr:
HASH(0x41ce970)
myFreezemon
?
freezemon_Notify:
cnt 589
dmx -1000
dtot 0
dtotcnt 0
mTS 03.04. 08:56:21
max 0.0016319751739502
tot 0.0810480117797852
mAr:
HASH(0x41ce970)
HASH(0x289b1e8)
freezemon_Set:
cnt 3
dmx -1000
dtot 0
dtotcnt 0
mTS 03.04. 09:00:14
max 5.69820404052734e-05
tot 0.000139951705932617
mAr:
HASH(0x41ce970)
myFreezemon
?
logqueue:
ARRAY(0x4c0dd00)
ARRAY(0x47fd1a8)
ARRAY(0x4a2c980)
Attributes:
fm_forceApptime 1
fm_log 10:1 5:2 1:3
fm_logFile ./log/myFreezemon-%Y-%m-%d.log
fm_logKeep 5
group Performance
icon system_fhem
room Mobile
stateFormat Last freeze:<br/>Zeitstempel
userReadings Zeitstempel {substr(ReadingsTimestamp('myFreezemon','state',''),0,19)}
Arg... gestern war nicht mien Tag :( Das kommt wenn man mit drei Versionen gleichzeitig hantiert... Sorry, gefixte Version angehängt und eingecheckt.
Wie angekündigt, habe ich Freezemon intern ein bisschen umgebaut. Die angehängte Version läuft seit ca 48 Stunden stabil in meinem Produktivsystem, ich will aber nicht ausschliessen, dass es noch das ein oder andere Problemchen gibt, daher wäre ich dankbar für Test und Feedback.
Was wurde geändert:
* ein Haufen Funktionalität, die früher in jedem Durchlauf (also jede Sekunde) ausgeführt wurde, wird jetzt nur noch im Falle eines Freezes ausgeführt. Dies sollte zu einer deutlich geringeren permanenten Systembelastung führen
* Blocking Calls (also das schreiben des verbose 5 logs in das Filesystem) werden nun mittels eine Queue-Mechanismus durchgeführt, was ebenfalls zu reduzierter Systemlast führt.
* fm_logExtraSeconds wird nicht mehr berücksichtigt
* Kombination von disable-Attribut mit set inactive/active wird analog zu anderen Modulen gehandhabt
* wrapping und unwrapping von FHEM-Funktionen sauberer implementiert
Danke!
produktiv im Einsatz.... ;)
Zitat von: KölnSolar am 06 April 2018, 10:07:33
produktiv im Einsatz.... ;)
Dito.
Also auf meinem Testsystem...
Gruß, Joachim
Angsthase ;D
Die neue Version tut seit 2 Tagen Dienst, wie es soll.
Die PID des blockingcall würde mit mit v.level 5 genügen ;)
Das Angebot in der Diskussion m. Boris f. ein Attr und früherem Start (bereits vor INITIALIZED) beim FHEM-Start fänd ich interessant, aber nicht notwendig(sprich Deine invest. Zeit sollte Entscheidungsgrundlage sein)
Grüße Markus
Zitat von: KölnSolar am 08 April 2018, 09:32:26
Die neue Version tut seit 2 Tagen Dienst, wie es soll.
Ok, Danke für die Rückmeldung. Da auch sonst nix kam: eingecheckt...
Zitat von: KölnSolar am 08 April 2018, 09:32:26
Die PID des blockingcall würde mit mit v.level 5 genügen ;)
Ups, das habe ich noch korrigiert (vor dem einchecken;))
Zitat von: KölnSolar am 08 April 2018, 09:32:26
Das Angebot in der Diskussion m. Boris f. ein Attr und früherem Start (bereits vor INITIALIZED) beim FHEM-Start fänd ich interessant, aber nicht notwendig(sprich Deine invest. Zeit sollte Entscheidungsgrundlage sein)
Boris hat sich ja nichtmehr gemeldet... Sonst noch jemand Interesse?
Mal eine Verständnisfrage zu Freezes. Werden eigentlich empfangene Kommandos, Ereignisse von CUL, TRX oder HMLAN erst an FHEM weitergereicht wenn dieses wieder "frei" ist oder gehen diese während des Freezes komplett verloren. Ich habe ab und an sehr kurze Phasen von Freezes von unter 2 Sekunden. Ich frage mich, was passiert wenn gerade in dieser Zeit ein Sensor meldet oder ich eine Aktion auf einem FS20 oder HM Taster ausgelöst wird.
die gehen normalerweise nicht verloren da sie im seriellen buffer stehen bis sie ausgelesen werden. so lange der freeze nicht so lange dauert das der buffer voll oder über läuft geht im prinzip nichts verloren.
aber: hm erwartet das ack innerhalb einer bestimmten zeit. wenn das nicht vom io selber erzeugt wird sondern von fhem kann es folge probleme geben.
andere bidirektionale protokolle verhalten sich vermutlich ähnlich.
Hallo Oli,
ich nutze dein Modul, vielen Dank für die Bereitstellung und Unterstützung im Forum.
Über den Tag verteilt gibt es 20 bis 30 Meldungen im Freezemonitor bis max. 3 Sekunden.
Ich vermute, dass das im Rahmen des Üblichen liegt.
Der benutzte Speicher auf dem RPi3B (mit Sysmon geloggt) nimmt im Laufe einer Woche von ca. 25% auf ca. 60% zu, aktuell hab ich 48%, mehr oder wenig linear.
2018-04-13_07:20:09 RPi.Sysmon ram: Total: 923.35 MB, Used: 443.86 MB, 48.07 %, Free: 479.49 MB
In den letzten 2-3 Wochen gab es ab ca. 60% große Probleme, die mit dem Speicher zu tun hatten und im Fhem Logfile auftauchten. Ich hab den genauen Wortlaut nicht mehr im Kopf, so ähnlich wie "Cannot fork ...".
Es half dann nur den Raspberry neu zu starten.
Hängt die zunehmende Speichernutzung mit Freezmon selbst zusammen?
Gibt es andere Ursachen?
Bevor ich Freezmon eingesetzt habe, hatte ich die "Cannot fork ..."-Meldungen noch nie gesehen. Die Speichernutzung habe ich mir allerdings damals nicht angeschaut.
Viele Grüße Gisbert
Auf meinem Hauptsystem hab ich (aktuell) nur 1 freez knapp über einer Sek.
Freezemon sagt: Statistikmodul "Tagwechsel"...
Damit kann ich gut leben...
Beim Hauptsystem meiner Freundin ähnlich...
Mein Testsystem sieht freez-technisch aus wie deins, Gisbert...
Daher schaue ich auf dem Testsystem genau bevor es ein Modul ins Hauptsystem schafft... ;)
Dank auch hier an FreezeMon!!
Bzgl. Speicher hab ich auch ein Wachstum aber noch nie die cannot fork Meldung...
In einem Monat in etwa 10% mehr Verbrauch...
...daher noch nicht akut...
Gruß, Joachim
Speicherproblem: https://forum.fhem.de/index.php/topic,84372.0.html
Ich bekomme regelmäßig:
1 - 2018-04-15: s:10:50:06 e:10:50:12 f:6.243 d:tmr-CUL_HM_procQs(N/A)
Hatt jemand eine Idee, wie ich diesen Timer besser eingrenzen kann?
die funktion etscheint bei mir auch ständig, aber fälschlicher weise. nutze das logfile attr. da siehst du dann die verursacher. CUL_HM_procQs habe ich jetzt auf die whitelist gesetzt.
Ah ok, das sieht schon anders aus... vielen Dank.
Kann mir jemand helfen, ich kriege diese Nachrichten
1 - 2018-04-17: s:19:52:02 e:19:52:05 f:3.008 d:tmr-FW_closeInactiveClients(N/A)
1 - 2018-04-17: s:19:53:05 e:19:53:08 f:3.008 d:tmr-FW_closeInactiveClients(N/A)
1 - 2018-04-17: s:19:54:08 e:19:54:11 f:3.009 d:tmr-FW_closeInactiveClients(N/A)
1 - 2018-04-17: s:19:55:11 e:19:55:14 f:3.009 d:tmr-FW_closeInactiveClients(N/A)
1 - 2018-04-17: s:19:56:14 e:19:56:17 f:3.008 d:tmr-FW_closeInactiveClients(N/A)
1 - 2018-04-17: s:19:57:17 e:19:57:20 f:3.008 d:tmr-FW_closeInactiveClients(N/A)
1 - 2018-04-17: s:19:58:20 e:19:58:23 f:3.008 d:tmr-FW_closeInactiveClients(N/A)
1 - 2018-04-17: s:19:59:23 e:19:59:26 f:3.008 d:tmr-FW_closeInactiveClients(N/A)
1 - 2018-04-17: s:20:00:26 e:20:00:29 f:3.008 d:tmr-FW_closeInactiveClients(N/A)
1 - 2018-04-17: s:20:01:29 e:20:01:32 f:3.006 d:tmr-FW_closeInactiveClients(N/A)
1 - 2018-04-17: s:20:02:32 e:20:02:35 f:3.008 d:tmr-FW_closeInactiveClients(N/A)
1 - 2018-04-17: s:20:03:35 e:20:03:38 f:3.008 d:tmr-FW_closeInactiveClients(N/A)
1 - 2018-04-17: s:20:04:38 e:20:04:41 f:3.009 d:tmr-FW_closeInactiveClients(N/A)
1 - 2018-04-17: s:20:05:41 e:20:05:44 f:3.008 d:tmr-FW_closeInactiveClients(N/A)
1 - 2018-04-17: s:20:06:44 e:20:06:47 f:3.009 d:tmr-FW_closeInactiveClients(N/A)
1 - 2018-04-17: s:20:07:47 e:20:07:50 f:3.008 d:tmr-FW_closeInactiveClients(N/A)
1 - 2018-04-17: s:20:08:50 e:20:08:53 f:3.008 d:tmr-FW_closeInactiveClients(N/A)
1 - 2018-04-17: s:20:09:53 e:20:09:56 f:3.009 d:tmr-FW_closeInactiveClients(N/A)
1 - 2018-04-17: s:20:10:56 e:20:10:59 f:3.009 d:tmr-FW_closeInactiveClients(N/A)
1 - 2018-04-17: s:20:11:59 e:20:12:02 f:3.009 d:tmr-FW_closeInactiveClients(N/A)
und kann damit nichts anfangen, da mir der Prozess nichts sagt (google auch nicht).
Das ist auch so ein whitelist-Kandidat (s.o). Auch hier gilt: Versuche mit fm_logFile und ggf. den catch.*-Attributen den wahren Verursacher heraus zu finden.
Kurz, weil mobil...
Hey,
danke erstmal für dein super Erweiterung. Habe den 99_perfmon.pm nun in Rente geschickt.
Habe nur eine Frage. Bekomme immer beim neustart von FHEM diese Meldung.
2018.04.23 13:10:01 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/98_freezemon.pm line 322.
2018.04.23 13:10:01 1: [Freezemon] myFreezemon: possible freeze starting at 13:09:58, delay is 3.463 possibly caused by: no bad guy found :-(
2018.04.23 13:10:01 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at ./FHEM/98_freezemon.pm line 1206.
Habe ich das was falsch gemacht.
Version --> 98_freezemon.pm 16571 2018-04-08 19:57:54Z KernSani
Gruß Gerd
Hi Gerd,
die WARNINGS sind komisch... Die erste Warning deutet darauf hin, dass ein Freeze erkannt wird, bevor der freeze-Cycle richtig begonnen hat - das kann eigentlich nicht sein... Und die zweite Warning sagt, dass FHEMWEB noch nicht geladen ist, was eigentlich auch nicht sein sollte, außer du verwendest die Weboberfläche nicht, oder du hast freezemon manuell in der fhem.cfg vor FHEMWEB geschoben... Ist eines davon der Fall?
Grüße,
Oli
Warum werden bei mir eigentlich manche Timer die definiert werden als Freezes erkannt?
13:54:39, delay is 1.729 possibly caused by: tmr-at_Exec(A_Bewaesserung_Next_Kreis_5)
Diese AT werden bei mir aus der myUtils heraus erzeugt.
Hi Dittel,
die Ausführung des ats (durch die Sub at_Exec des at-Moduls) scheint länger zu dauern. Genaueres bekommst du vermutlich über das logFile (Attribut fm_logFile) heraus.
Grüße,
Oli
Hmmm, also im Log kann ich richtig "lange" Verzögerungen nur von "createNotifyHash" ausmachen. Das dauert dort immer ca. eine halbe Sekunde. Was passiert hier?
Was macht denn das AT? Magst du das Log posten (Achtung bei persönlichen Daten)
Kurz, weil mobil...
So viel passiert da eigentlich gar nicht. Es wird ein Reading geschrieben und ein HM Wired Aktor betätigt.
fhem ("define A_Bewaesserung_Ende_Kreis_$durchgang at +00:$dauer setreading Bewaesserung_Kreis_Vorwahl status$durchgang abgeschlossen;;set HMW_Kreis_$durchgang off")
Habe mal das den kompletten Freezelog für diesen Abschnitt per PM geschickt.
Moin zusammen,
ich habe seit einigen Tagen ständig Meldungen von tmr Aufrufen im Log :(
1 - 2018-05-25 [Log]: s:18:35:35 e:18:35:37 f:2.214 d:tmr-harmony_ping(hub1) tmr-VIERA_GetStatus(Viera_Wz)
1 - 2018-05-25 [Log]: s:18:37:35 e:18:37:37 f:2.034 d:tmr-VIERA_GetStatus(Viera_Wz)
1 - 2018-05-25 [Log]: s:18:38:35 e:18:38:39 f:4.411 d:no bad guy found :-(
1 - 2018-05-25 [Log]: s:18:38:47 e:18:38:49 f:2.124 d:tmr-SIGNALduino_KeepAlive(sduino) tmr-SIGNALduino_KeepAlive(sduino3) tmr-SYSMON_Update...
1 - 2018-05-25 [Log]: s:18:39:35 e:18:39:37 f:2.092 d:tmr-HMUARTLGW_CheckCredits(N/A) tmr-VIERA_GetStatus(Viera_Wz)
1 - 2018-05-25 [Log]: s:18:41:35 e:18:41:37 f:2.222 d:tmr-VIERA_GetStatus(Viera_Wz)
1 - 2018-05-25 [Log]: s:18:43:35 e:18:43:37 f:2.177 d:tmr-CUL_HM_procQs(N/A) tmr-VIERA_GetStatus(Viera_Wz)
1 - 2018-05-25 [Log]: s:18:45:35 e:18:45:37 f:2.18 d:tmr-harmony_ping(hub1) tmr-VIERA_GetStatus(Viera_Wz)
1 - 2018-05-25 [Log]: s:18:47:35 e:18:47:37 f:2.01 d:tmr-HMLAN_KeepAlive(N/A) tmr-VIERA_GetStatus(Viera_Wz)
1 - 2018-05-25 [Log]: s:18:48:59 e:18:49:01 f:2.134 d:tmr-SIGNALduino_KeepAlive(sduino) tmr-SIGNALduino_KeepAlive(sduino3) tmr-SYSMON_Update...
1 - 2018-05-25 [Log]: s:18:59:11 e:18:59:13 f:2.209 d:tmr-at_Exec(heartbeat) tmr-SIGNALduino_KeepAlive(sduino) tmr-SIGNALduino_KeepAlive(sdu...
1 - 2018-05-25 [Log]: s:19:01:49 e:19:01:51 f:2.448 d:tmr-HMLAN_KeepAliveCheck(N/A) tmr-CUL_HM_procQs(N/A) tmr-CUL_MAX_BroadcastTime(cm) tmr...
1 - 2018-05-25 [Log]: s:19:04:18 e:19:04:20 f:2.936 d:tmr-HMLAN_KeepAlive(N/A) tmr-WOL_UpdateReadings(NAS542_ping) tmr-SIGNALduino_KeepAlive...
1 - 2018-05-25 [Log]: s:19:10:26 e:19:10:28 f:2.146 d:tmr-PRESENCE_StartLocalScan(IPCam) tmr-SIGNALduino_KeepAlive(sduino) tmr-SIGNALduino_K...
1 - 2018-05-25 [Log]: s:19:14:31 e:19:14:33 f:2.154 d:tmr-SIGNALduino_KeepAlive(sduino) tmr-SIGNALduino_KeepAlive(sduino3) tmr-SYSMON_Update...
1 - 2018-05-25 [Log]: s:19:17:36 e:19:17:40 f:4.373 d:tmr-VIERA_GetStatus(Viera_Wz) tmr-SIGNALduino_KeepAlive(sduino) tmr-SIGNALduino_KeepAl...
1 - 2018-05-25 [Log]: s:19:21:43 e:19:21:45 f:2.111 d:tmr-SIGNALduino_KeepAlive(sduino) tmr-SIGNALduino_KeepAlive(sduino3) tmr-SYSMON_Update...
1 - 2018-05-25 [Log]: s:19:25:48 e:19:25:50 f:2.076 d:tmr-SIGNALduino_KeepAlive(sduino) tmr-SIGNALduino_KeepAlive(sduino3) tmr-SYSMON_Update...
1 - 2018-05-25 [Log]: s:19:31:55 e:19:31:57 f:2.1 d:tmr-SIGNALduino_KeepAlive(sduino) tmr-SIGNALduino_KeepAlive(sduino3) tmr-SYSMON_Update(R...
1 - 2018-05-25 [Log]: s:19:32:35 e:19:32:38 f:3.409 d:tmr-rssFeed_GetUpdate(My_VMZrss) tmr-rssFeed_GetUpdate(My_NPrss)
List vom freezemon:
Internals:
CFGFN
NAME myFreezemon
NR 923
NTFY_ORDER 99-myFreezemon
STATE s:19:42:07 e:19:42:09 f:2.1 d:tmr-SIGNALduino_KeepAlive(sduino) tmr-SIGNALduino_KeepAlive(sduino3) tmr-SYSMON_Update(Raspi)
TYPE freezemon
VERSION 0.0.20
Helper:
DBLOG:
fcDay:
fhemlogDB:
TIME 1527270129.17463
VALUE 194
freezeDevice:
fhemlogDB:
TIME 1527270129.17463
VALUE tmr-SIGNALduino_KeepAlive(sduino) tmr-SIGNALduino_KeepAlive(sduino3) tmr-SYSMON_Update(Raspi)
freezeTime:
fhemlogDB:
TIME 1527270129.17463
VALUE 2.1
ftDay:
fhemlogDB:
TIME 1527270129.17463
VALUE 445.639
state:
fhemlogDB:
TIME 1527270129.17463
VALUE s:19:42:07 e:19:42:09 f:2.1 d:tmr-SIGNALduino_KeepAlive(sduino) tmr-SIGNALduino_KeepAlive(sduino3) tmr-SYSMON_Update(Raspi)
READINGS:
2018-05-25 19:42:09 fcDay 194
2018-05-25 00:00:26 fcDayLast 327
2018-05-25 19:42:09 freezeDevice tmr-SIGNALduino_KeepAlive(sduino) tmr-SIGNALduino_KeepAlive(sduino3) tmr-SYSMON_Update(Raspi)
2018-05-25 19:42:09 freezeTime 2.1
2018-05-25 19:42:09 ftDay 445.639
2018-05-25 00:00:26 ftDayLast 755.082
2018-05-25 19:42:09 state s:19:42:07 e:19:42:09 f:2.1 d:tmr-SIGNALduino_KeepAlive(sduino) tmr-SIGNALduino_KeepAlive(sduino3) tmr-SYSMON_Update(Raspi)
helper:
DISABLED 0
TIMER 1527270353
apptime
fn
freeze 2.10040211677551
intCount 26
msg [Freezemon] myFreezemon: possible freeze starting at 19:42:07, delay is 2.1 possibly caused by: tmr-SIGNALduino_KeepAlive(sduino) tmr-SIGNALduino_KeepAlive(sduino3) tmr-SYSMON_Update(Raspi)
now 1527270129.1004
bm:
freezemon_Get:
cnt 5
dmx -1000
dtot 0
dtotcnt 0
mTS 25.05. 19:35:38
max 0.022130012512207
tot 0.0885062217712402
mAr:
HASH(0x63c69f8)
myFreezemon
freeze
freezemon_Notify:
cnt 150705
dmx -1000
dtot 0
dtotcnt 0
mTS 25.05. 11:26:08
max 0.00241708755493164
tot 12.5764615535736
mAr:
HASH(0x63c69f8)
HASH(0x66621e0)
freezemon_Set:
cnt 266
dmx -1000
dtot 0
dtotcnt 0
mTS 25.05. 06:24:22
max 0.000212907791137695
tot 0.0114676952362061
mAr:
HASH(0x63c69f8)
myFreezemon
?
inAt:
HASH(0x8e45198)
HASH(0x8c60db8)
HASH(0x8e8f998)
HASH(0x91bd438)
HASH(0x91bcb68)
HASH(0x91b0488)
HASH(0x91c5178)
HASH(0x91b6090)
HASH(0x91be4d0)
HASH(0x91b1df8)
HASH(0x7a853f8)
HASH(0x91ca6c0)
HASH(0x91c87b8)
HASH(0x6b2a990)
HASH(0x8eabee0)
HASH(0x91c7bd8)
HASH(0x8e6cbf8)
HASH(0x8c148b0)
HASH(0x91b8140)
HASH(0x8fc7628)
HASH(0x91b5fb8)
HASH(0x8c61760)
HASH(0x1c33090)
HASH(0x90fed60)
HASH(0x80817f0)
HASH(0x8ebadb8)
HASH(0x87bdec8)
HASH(0x8813f78)
HASH(0x91b09b0)
HASH(0x90ff3d8)
HASH(0x91b60f0)
HASH(0x8227330)
HASH(0x8fb7a40)
HASH(0x91c8998)
HASH(0x8fc6ff8)
HASH(0x91b9c80)
HASH(0x8e458a0)
HASH(0x8c21a00)
HASH(0x91b30a8)
HASH(0x89d0c80)
HASH(0x91b1ee8)
HASH(0x8601748)
HASH(0x7812350)
HASH(0x74c1570)
HASH(0x8e8ae10)
HASH(0x6ae9a98)
HASH(0x8fc23b8)
HASH(0x8eb5120)
HASH(0x91a2748)
HASH(0x8fc20a0)
HASH(0x8c58288)
HASH(0x8c6a5a0)
HASH(0x9050e00)
HASH(0x9101478)
HASH(0x849c6d8)
HASH(0x9019130)
HASH(0x8a8ab28)
HASH(0x905eae8)
HASH(0x8eb6728)
HASH(0x91b78a0)
HASH(0x393ef28)
HASH(0x6b451c8)
HASH(0x393eac0)
HASH(0x6a74080)
HASH(0x832a0f8)
HASH(0x455f070)
HASH(0x66e70d8)
HASH(0x6ae0728)
HASH(0x1c30668)
HASH(0x393edd8)
HASH(0x6a68448)
HASH(0x6b461c0)
HASH(0x6b47ac0)
HASH(0x1d36b88)
HASH(0x6ae8998)
HASH(0x1df2ae8)
HASH(0x6a3da90)
HASH(0x6b46028)
HASH(0x6a6a278)
HASH(0x6a71020)
HASH(0x6a7c3d8)
HASH(0x1e0eee0)
HASH(0x393f0f0)
HASH(0x1d7f948)
HASH(0x8e98658)
HASH(0x6a13c60)
HASH(0x45c9fe0)
HASH(0x4f812a0)
HASH(0x7a082b8)
HASH(0x21f6680)
HASH(0x56c35d0)
HASH(0x43f5198)
HASH(0x262b680)
HASH(0x456c958)
HASH(0x3bd6250)
HASH(0x3c1e4e0)
HASH(0x6b48da0)
HASH(0x1e1f918)
HASH(0x6ab2ed0)
HASH(0x6abc670)
HASH(0x6b43a50)
HASH(0x6a7c870)
HASH(0x6b48ae8)
HASH(0x6b7c190)
HASH(0x1e19148)
HASH(0x6b912f8)
HASH(0x2a3da88)
HASH(0x6b43df8)
HASH(0x6b48810)
HASH(0x6b48ce0)
HASH(0x6b7c328)
HASH(0x1bf11b0)
HASH(0x1d776e0)
HASH(0x7343f40)
HASH(0x6779ee8)
HASH(0x680ff90)
HASH(0x687c5e8)
HASH(0x737e3c8)
HASH(0x73802e0)
HASH(0x6d34360)
HASH(0x6f91d28)
HASH(0x6d3f278)
HASH(0x765d598)
HASH(0x69f0b98)
HASH(0x1c39468)
HASH(0x76f12f0)
HASH(0x7740318)
HASH(0x1d83cd8)
HASH(0x6c5f800)
HASH(0x77b6750)
HASH(0x77bc5f8)
HASH(0x6b46388)
HASH(0x7bf5820)
HASH(0x7bfa5c0)
HASH(0x77fb058)
HASH(0x9019bb0)
HASH(0x68b4f68)
HASH(0x7b475f8)
HASH(0x79e8398)
HASH(0x6a0ad60)
HASH(0x7bf9e28)
HASH(0x7b691c8)
HASH(0x7bcf7c0)
HASH(0x6a6a518)
HASH(0x8e79610)
HASH(0x8e86608)
HASH(0x903e570)
logfilequeue:
logqueue:
ARRAY(0x91bcd18)
ARRAY(0x91b78e8)
ARRAY(0x8fe9c80)
ARRAY(0x91ca8b8)
ARRAY(0x91a5028)
ARRAY(0x91c9028)
ARRAY(0x8fc3af8)
ARRAY(0x91a2478)
ARRAY(0x91b3138)
ARRAY(0x74bec78)
ARRAY(0x91cfa48)
ARRAY(0x91d0498)
Attributes:
fm_forceApptime 1
fm_freezeThreshold 2
fm_log 100
fm_logFile ./log/freeze-%Y%m%d-%H%M%S.log
fm_logKeep 100
Echte Verzögerungen sind aber nicht wahrnehmbar. Was muss ich tun damit mir das Log nicht zugemüllt wird?
Danke & Gruß
Arthur
Hmmm... kannst du vielleicht mal ein Log eines "unechten" Freezes anhängen? Evtl. helfen auch die fm_catch.* Attribute dem Übeltäter auf die Spur zu kommen...
Grüße,
Oli
Hier mal ein Log von heute Morgen:
jump to the end
=========================================================
[Freezemon] myFreezemon: possible freeze starting at 08:19:54, delay is 2.491 possibly caused by: tmr-PRESENCE_StartLocalScan(Raspi2) tmr-SIGNALduino_KeepAlive(sduino) tmr-SIGNALduino_KeepAlive(sduino3) tmr-SYSMON_Update(Raspi) tmr-DbLog_execmemcache(fhemlogDB) tmr-JeeLink_OnTimer(N/A) tmr-JeeLink_OnTimer(N/A) tmr-CUL_HM_procQs(N/A) tmr-HMUARTLGW_CheckCredits(N/A)
2018.06.01 08:19:53.057 5: PRESENCE (Raspi2) - stopping timer
2018.06.01 08:19:53.058 5: PRESENCE (Raspi2) - starting blocking call for mode lan-ping
2018.06.01 08:19:53.079 4: BlockingCall (PRESENCE_DoLocalPingScan): created child (25504), uses tPortLocal to connect back
2018.06.01 08:19:53.120 4: Connection accepted from tPortLocal_127.0.0.1_47888
2018.06.01 08:19:53.124 5: Cmd: >{BlockingRegisterTelnet($cl,2529)}<
--- log skips 3.282 secs.
2018.06.01 08:19:56.406 4: sduino/keepalive ok, retry = 0
2018.06.01 08:19:56.406 4: sduino3/keepalive ok, retry = 0
2018.06.01 08:19:56.409 5: SYSMON Raspi: updateReadings.1060
2018.06.01 08:19:56.433 4: BlockingCall (SYSMON_blockingCall): created child (25509), uses tPortLocal to connect back
2018.06.01 08:19:56.440 4: DbLog fhemlogDB -> ################################################################
2018.06.01 08:19:56.440 4: DbLog fhemlogDB -> ### New database processing cycle - asynchronous ###
2018.06.01 08:19:56.440 4: DbLog fhemlogDB -> ################################################################
2018.06.01 08:19:56.440 4: DbLog fhemlogDB -> MemCache contains 74 entries to process
2018.06.01 08:19:56.440 4: DbLog fhemlogDB -> DbLogType is: History
2018.06.01 08:19:56.442 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:23|mapleCUN1|CUL|UNKNOWNCODE N0298C1903D798053EA01B2237B|state|UNKNOWNCODE N0298C1903D798053EA01B2237B|
2018.06.01 08:19:56.442 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:23|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N03020406795A00FFFFFFFFF759BB1D7D26102E1C65E190C09149F03391D8DEDC6B|state|UNKNOWNCODE N03020406795A00FFFFFFFFF759BB1D7D26102E1C65E190C09149F03391D8DEDC6B|
2018.06.01 08:19:56.442 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:23|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N03020406795A00000000067764AAF4C8DCC967CB13FF6D377674FD17BD2B89DB77|state|UNKNOWNCODE N03020406795A00000000067764AAF4C8DCC967CB13FF6D377674FD17BD2B89DB77|
2018.06.01 08:19:56.442 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:23|BM_HM_Kueche|CUL_HM|state: noMotion|state|noMotion|
2018.06.01 08:19:56.442 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:23|log_all_events|DOIF|cmd_nr: 1|cmd_nr|1|
2018.06.01 08:19:56.442 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:23|log_all_events|DOIF|cmd: 1|cmd|1|
2018.06.01 08:19:56.442 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:23|log_all_events|DOIF|cmd_event: BM_HM_Kueche|cmd_event|BM_HM_Kueche|
2018.06.01 08:19:56.442 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:23|log_all_events|DOIF|state: cmd_1|state|cmd_1|
2018.06.01 08:19:56.442 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:23|mapleCUN1|CUL|UNKNOWNCODE N0299065243BB802E7C0C1C2E48|state|UNKNOWNCODE N0299065243BB802E7C0C1C2E48|
2018.06.01 08:19:56.443 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:25|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N03010426E3B600FFFFFFFF64E81CEF9C4A7C6211218E9CB5AC3BB31CD4604608EF|state|UNKNOWNCODE N03010426E3B600FFFFFFFF64E81CEF9C4A7C6211218E9CB5AC3BB31CD4604608EF|
2018.06.01 08:19:56.443 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:26|mapleCUN1|CUL|UNKNOWNCODE N029086396AA806149884C904F6|state|UNKNOWNCODE N029086396AA806149884C904F6|
2018.06.01 08:19:56.443 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:26|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N03070406CF3300FFFFFFFF12170253D03BE7E26AA15E2FEB7E712A79A6A6EEBCD6|state|UNKNOWNCODE N03070406CF3300FFFFFFFF12170253D03BE7E26AA15E2FEB7E712A79A6A6EEBCD6|
2018.06.01 08:19:56.443 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:27|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N03030426E3C600FFFFFFFFA4B73A61EFF77E27B25993D88159ABE21AACE37BFBE8|state|UNKNOWNCODE N03030426E3C600FFFFFFFFA4B73A61EFF77E27B25993D88159ABE21AACE37BFBE8|
2018.06.01 08:19:56.443 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:27|mapleCUN1|CUL|UNKNOWNCODE N029A06334520311637C60332B8|state|UNKNOWNCODE N029A06334520311637C60332B8|
2018.06.01 08:19:56.443 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:27|HMS100TF_4328_Balkon|HMS|temperature: 23.3|temperature|23.3|°C
2018.06.01 08:19:56.443 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:29|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N0304040384EC00FFFFFFFF05542CDB577765FCDB043E2F933069F82FCCC5A7452F|state|UNKNOWNCODE N0304040384EC00FFFFFFFF05542CDB577765FCDB043E2F933069F82FCCC5A7452F|
2018.06.01 08:19:56.443 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:31|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N03030426E3C600FFFFFFFFA4B79A720C56551BCA34031E8F8A5E17028A9AD6C8BF|state|UNKNOWNCODE N03030426E3C600FFFFFFFFA4B79A720C56551BCA34031E8F8A5E17028A9AD6C8BF|
2018.06.01 08:19:56.443 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:31|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N03030426E3C600000000C6260AAAA3F8F80890C64067FC1A63B00FEFF24DDC6AA3|state|UNKNOWNCODE N03030426E3C600000000C6260AAAA3F8F80890C64067FC1A63B00FEFF24DDC6AA3|
2018.06.01 08:19:56.444 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:31|mapleCUN1|CUL|UNKNOWNCODE N029984791138E32C86EC188402|state|UNKNOWNCODE N029984791138E32C86EC188402|
2018.06.01 08:19:56.444 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:31|Kuehlschrank|LACROSSE|temperature: 7.9|temperature|7.9|°C
2018.06.01 08:19:56.444 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:31|Kuehlschrank|LACROSSE|ttstemp: 7,9|ttstemp|7,9|
2018.06.01 08:19:56.444 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:32|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N03080426D9FC00FFFFFFFF8DBBDBE88EB5725F72A43A90F1A196E99E893C149DD7|state|UNKNOWNCODE N03080426D9FC00FFFFFFFF8DBBDBE88EB5725F72A43A90F1A196E99E893C149DD7|
2018.06.01 08:19:56.444 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:32|mapleCUN1|CUL|UNKNOWNCODE N029846653B8FE168A3AF4E2072|state|UNKNOWNCODE N029846653B8FE168A3AF4E2072|
2018.06.01 08:19:56.444 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:32|mapleCUN1|CUL|UNKNOWNCODE N029A06334520FA8153148A8D0C|state|UNKNOWNCODE N029A06334520FA8153148A8D0C|
2018.06.01 08:19:56.444 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:32|mapleCUN1|CUL|UNKNOWNCODE N029806583E7A901D08E23E23EE|state|UNKNOWNCODE N029806583E7A901D08E23E23EE|
2018.06.01 08:19:56.444 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:33|mapleCUN1|CUL|UNKNOWNCODE N0298C1903D7606940A34A431AC|state|UNKNOWNCODE N0298C1903D7606940A34A431AC|
2018.06.01 08:19:56.444 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:33|mapleCUN1|CUL|UNKNOWNCODE N0299065243BBA02E0A277CCAA7|state|UNKNOWNCODE N0299065243BBA02E0A277CCAA7|
2018.06.01 08:19:56.444 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:34|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N03080426D9FC00FFFFFFFF8DBB2F0086AC26FBFC95B77302C39FA28B38B5BEAEB2|state|UNKNOWNCODE N03080426D9FC00FFFFFFFF8DBB2F0086AC26FBFC95B77302C39FA28B38B5BEAEB2|
2018.06.01 08:19:56.444 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:34|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N03080426D9FC00000000808E91AAAA394DD996C3FD4A0C0CE64CBD73767BD44534|state|UNKNOWNCODE N03080426D9FC00000000808E91AAAA394DD996C3FD4A0C0CE64CBD73767BD44534|
2018.06.01 08:19:56.444 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:34|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N03080406DDF300FFFFFFFFA138BE3AA68E2E71322B6C600000000010001EFAFCFF|state|UNKNOWNCODE N03080406DDF300FFFFFFFFA138BE3AA68E2E71322B6C600000000010001EFAFCFF|
2018.06.01 08:19:56.444 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:36|mapleCUN1|CUL|UNKNOWNCODE N029086396AA800854E24D84180|state|UNKNOWNCODE N029086396AA800854E24D84180|
2018.06.01 08:19:56.444 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:37|mapleCUN1|CUL|UNKNOWNCODE N029A06334520EF07864E80F53C|state|UNKNOWNCODE N029A06334520EF07864E80F53C|
2018.06.01 08:19:56.445 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:38|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N03080406B91000FFFFFFFF4B96E0E2792E60321C325B9B3ADF7D1E9A85C3823DCE|state|UNKNOWNCODE N03080406B91000FFFFFFFF4B96E0E2792E60321C325B9B3ADF7D1E9A85C3823DCE|
2018.06.01 08:19:56.445 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:38|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N03080426D9AE00FFFFFFFFFDEDB1AAB284100C0CE99799DFC3CAB36BFF8F6CD196|state|UNKNOWNCODE N03080426D9AE00FFFFFFFFFDEDB1AAB284100C0CE99799DFC3CAB36BFF8F6CD196|
2018.06.01 08:19:56.445 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:38|PCA301Statistics|STATISTICS|state: Updated stats for: PCA301_9|state|Updated stats for|PCA301_9
2018.06.01 08:19:56.445 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:38|PCA301_9|PCA301|power: 23.9|power|23.9|
2018.06.01 08:19:56.445 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:38|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N03080426D9AE0100EF0C31D855AAFCA0AE1FBE896E4A4A30FB03A1AE923E1CD35D|state|UNKNOWNCODE N03080426D9AE0100EF0C31D855AAFCA0AE1FBE896E4A4A30FB03A1AE923E1CD35D|
2018.06.01 08:19:56.445 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:41|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N030804078A9600FFFFFFFF7B2E936C18B7FF8526F9903176683BCFF869CDF9EA66|state|UNKNOWNCODE N030804078A9600FFFFFFFF7B2E936C18B7FF8526F9903176683BCFF869CDF9EA66|
2018.06.01 08:19:56.445 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:41|PCA301Statistics|STATISTICS|state: Updated stats for: PCA301_7|state|Updated stats for|PCA301_7
2018.06.01 08:19:56.445 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:41|PCA301_7|PCA301|power: 243.5|power|243.5|
2018.06.01 08:19:56.445 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:41|mapleCUN1|CUL|UNKNOWNCODE N0299847911389880F51E00556F|state|UNKNOWNCODE N0299847911389880F51E00556F|
2018.06.01 08:19:56.445 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:42|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N03050406977200FFFFFFFFF7FB043C0A785003805A6FAEBB1FDF0C8AF9562E6E8A|state|UNKNOWNCODE N03050406977200FFFFFFFFF7FB043C0A785003805A6FAEBB1FDF0C8AF9562E6E8A|
2018.06.01 08:19:56.445 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:42|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N030504069772000000000077D2AA4475966FDADFA93F21C93D3D8EADC79FA6C5FB|state|UNKNOWNCODE N030504069772000000000077D2AA4475966FDADFA93F21C93D3D8EADC79FA6C5FB|
2018.06.01 08:19:56.445 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:42|mapleCUN1|CUL|UNKNOWNCODE N029846653B8FDD35A73E31194A|state|UNKNOWNCODE N029846653B8FDD35A73E31194A|
2018.06.01 08:19:56.445 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:42|mapleCUN1|CUL|UNKNOWNCODE N029A0634458E61C68F3AC74C55|state|UNKNOWNCODE N029A0634458E61C68F3AC74C55|
2018.06.01 08:19:56.446 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:42|HMS100TF_4328_Balkon|HMS|temperature: 23.4|temperature|23.4|°C
2018.06.01 08:19:56.446 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:42|Thermo_Balkon|LACROSSE|temperature: 23.4|temperature|23.4|°C
2018.06.01 08:19:56.446 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:42|Thermo_Balkon|LACROSSE|ttstemp: 23,4|ttstemp|23,4|
2018.06.01 08:19:56.446 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:42|heating_Ku|DOIF|cmd_nr: 3|cmd_nr|3|
2018.06.01 08:19:56.446 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:42|heating_Ku|DOIF|cmd: 3|cmd|3|
2018.06.01 08:19:56.446 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:42|heating_Ku|DOIF|cmd_event: Thermo_Balkon|cmd_event|Thermo_Balkon|
2018.06.01 08:19:56.446 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:42|heating_Ku|DOIF|state: 5.0|state|5.0|
2018.06.01 08:19:56.446 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:42|mapleCUN1|CUL|UNKNOWNCODE N029806583E7AE540F80B03D48A|state|UNKNOWNCODE N029806583E7AE540F80B03D48A|
2018.06.01 08:19:56.446 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:43|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N03070426D9C300FFFFFFFF054462D261573F05884CD971417E032315B31B487F7E|state|UNKNOWNCODE N03070426D9C300FFFFFFFF054462D261573F05884CD971417E032315B31B487F7E|
2018.06.01 08:19:56.446 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:43|PCA301Statistics|STATISTICS|state: Updated stats for: PCA301_15|state|Updated stats for|PCA301_15
2018.06.01 08:19:56.446 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:43|PCA301_15|PCA301|power: 11.3|power|11.3|
2018.06.01 08:19:56.446 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:43|mapleCUN1|CUL|UNKNOWNCODE N0298C1903D60E0115645913D56|state|UNKNOWNCODE N0298C1903D60E0115645913D56|
2018.06.01 08:19:56.446 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:43|mapleCUN1|CUL|UNKNOWNCODE N0299065243BB50170701A80001|state|UNKNOWNCODE N0299065243BB50170701A80001|
2018.06.01 08:19:56.446 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:46|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N03010426E40500FFFFFFFFEB2386DCFBCB72ED48EE73CFABA6F0DB3730F9F9459F|state|UNKNOWNCODE N03010426E40500FFFFFFFFEB2386DCFBCB72ED48EE73CFABA6F0DB3730F9F9459F|
2018.06.01 08:19:56.446 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:46|mapleCUN1|CUL|UNKNOWNCODE N029086396AA8016A0BB8331114|state|UNKNOWNCODE N029086396AA8016A0BB8331114|
2018.06.01 08:19:56.446 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:47|mapleCUN1|CUL|UNKNOWNCODE N029A06334520EF871C84942218|state|UNKNOWNCODE N029A06334520EF871C84942218|
2018.06.01 08:19:56.446 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:47|HMS100TF_4328_Balkon|HMS|temperature: 23.3|temperature|23.3|°C
2018.06.01 08:19:56.446 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:47|Thermo_Balkon|LACROSSE|temperature: 23.3|temperature|23.3|°C
2018.06.01 08:19:56.447 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:47|Thermo_Balkon|LACROSSE|ttstemp: 23,3|ttstemp|23,3|
2018.06.01 08:19:56.447 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:48|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N03010426DADE00FFFFFFFF1E171C6E841BE6B768AF7E6C539350329F9C198DD7F2|state|UNKNOWNCODE N03010426DADE00FFFFFFFF1E171C6E841BE6B768AF7E6C539350329F9C198DD7F2|
2018.06.01 08:19:56.447 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:48|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N03010426DADE00000000C71CAFAAAB84F7401F2CB38BCFA4F2D7A2EE38F8E9CFE3|state|UNKNOWNCODE N03010426DADE00000000C71CAFAAAB84F7401F2CB38BCFA4F2D7A2EE38F8E9CFE3|
2018.06.01 08:19:56.447 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:51|mapleCUN1|CUL|UNKNOWNCODE N0299847911380193C1294E3DDD|state|UNKNOWNCODE N0299847911380193C1294E3DDD|
2018.06.01 08:19:56.447 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:52|mapleCUN1|CUL|UNKNOWNCODE N029846653B8F82717FA270D081|state|UNKNOWNCODE N029846653B8F82717FA270D081|
2018.06.01 08:19:56.447 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:52|mapleCUN4|STACKABLE_CC|UNKNOWNCODE N03050426D98C00FFFFFFFFED270004B9C994561D2AC91D62E47A158E2BACEE2736|state|UNKNOWNCODE N03050426D98C00FFFFFFFFED270004B9C994561D2AC91D62E47A158E2BACEE2736|
2018.06.01 08:19:56.447 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:52|mapleCUN1|CUL|UNKNOWNCODE N029A0634458EE0C5E601E5C08B|state|UNKNOWNCODE N029A0634458EE0C5E601E5C08B|
2018.06.01 08:19:56.447 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:52|HMS100TF_4328_Balkon|HMS|temperature: 23.4|temperature|23.4|°C
2018.06.01 08:19:56.447 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:52|Thermo_Balkon|LACROSSE|temperature: 23.4|temperature|23.4|°C
2018.06.01 08:19:56.447 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:52|Thermo_Balkon|LACROSSE|ttstemp: 23,4|ttstemp|23,4|
2018.06.01 08:19:56.447 5: DbLog fhemlogDB -> MemCache contains: 2018-06-01 08:19:52|mapleCUN1|CUL|UNKNOWNCODE N029806583E7A9185D9B0F9DFBE|state|UNKNOWNCODE N029806583E7A9185D9B0F9DFBE|
2018.06.01 08:19:56.475 4: BlockingCall (DbLog_PushAsync): created child (25510), uses tPortLocal to connect back
2018.06.01 08:19:56.476 5: DbLog fhemlogDB -> DbLog_PushAsync called with timeout: 86400
2018.06.01 08:19:56.485 5: HMUARTLGW WLAN_CUL_HM checking credits (from timer)
2018.06.01 08:19:56.487 5: HMUARTLGW WLAN_CUL_HM send: 00 08
2018.06.01 08:19:56.488 5: HMUARTLGW WLAN_CUL_HM send: (8): fd0003009408603a
2018.06.01 08:19:56.488 5: SW: fd0003009408603a
2018.06.01 08:19:56.492 5: [Freezemon] myFreezemon: ----------- Starting Freeze handling at 2018.06.01 08:19:56.491 ---------------------
[Freezemon] myFreezemon: possible freeze starting at 08:19:54, delay is 2.491 possibly caused by: tmr-PRESENCE_StartLocalScan(Raspi2) tmr-SIGNALduino_KeepAlive(sduino) tmr-SIGNALduino_KeepAlive(sduino3) tmr-SYSMON_Update(Raspi) tmr-DbLog_execmemcache(fhemlogDB) tmr-JeeLink_OnTimer(N/A) tmr-JeeLink_OnTimer(N/A) tmr-CUL_HM_procQs(N/A) tmr-HMUARTLGW_CheckCredits(N/A)
jump to the top
Die fm_catch.* Atrribute hab ich mal beide aktiviert.
Gruß
Arthur
Hallo
Ich habe immer wieder (2--3 mal am Tag) Freezes mit diesem Inhalt.
[Freezemon] Freezemon: possible freeze starting at 09:19:52, delay is 3.401 possibly caused by: tmr-HMUARTLGW_SendKeepAlive(LGW1)
2018.06.07 09:19:51.102 5: HMUARTLGW LGW1:keepAlive send (3): K3c
2018.06.07 09:19:51.102 5: SW: K3c
2018.06.07 09:19:51.103 5: HMUARTLGW LGW1:keepAlive read raw (6): 3e4b33630d0a
2018.06.07 09:19:51.103 5: HMUARTLGW LGW1:keepAlive read (4): >K3c
--- log skips 4.299 secs.
2018.06.07 09:19:55.401 5: [Freezemon] Freezemon: ----------- Starting Freeze handling at 2018.06.07 09:19:55.401 ---------------------
[Freezemon] Freezemon: possible freeze starting at 09:19:52, delay is 3.401 possibly caused by: tmr-HMUARTLGW_SendKeepAlive(LGW1)
Hat jemand eine Idee was diese verursachen könnte? Und wie ich das abstellen kann. ;-)
Gruß
Daniel
Guten Morgen,
ich hab minütlich diese Meldung:
2018.06.09 08:01:22 1: [Freezemon] freeze: possible freeze starting at 08:01:19, delay is 3.012 possibly caused by: tmr-CUL_HM_procQs(N/A) tmr-FW_closeInactiveClients(N/A)
Habt ihr eine Idee?
LG
Marlen
Gesendet von meinem Aquaris U Plus mit Tapatalk
Hi,
keine konkrete Idee für den Verursacher, aber eine Idee, wie man dem auf die Schliche kommt.
1. Mittels Apptime versuchen, die Prozesse zu identifizieren, die ebenfalls minütlich ablaufen
2. Das Logging generell auf 5 hochdrehen und mit "tail -f <logfile>" auf Hinweise spähen (bei mir hat der freezemon-Logauszug nicht immer gepasst)
Somit habe ich bei mir einige freezes aus dem System beseitigt. Dann blieb noch einer im Minutentakt. Am Ende habe ich alles devices gelöscht, Stück für Stück, bis der Freeze ausblieb. Hat funktioniert, seitdem habe ich ein (nahezu) freeze-freies System - von einem Freeze pro Tag mal abgesehen, aber den kenne ich ;-)
Gruß,
Tom
War STV für meinen Fernseher.... geht aber aus der Meldung nicht hervor!
LG
Marlen
Gesendet von meinem Aquaris U Plus mit Tapatalk
teste und lese mit
Moin Oli,
ich probiere gerade dein Modul aus.
Ich habe lediglich die Definition vorgenommen und schon fingen an sich die Readings zu füllen.
Hier mal ein kurzer Auszug
1 - 2018-09-11 [Log]: s:10:02:54 e:10:02:57 f:3.052 d:no bad guy found :-(
1 - 2018-09-11 [Log]: s:10:03:14 e:10:03:16 f:2.212 d:HMUARTLGW_CheckCredits(N/A) HMUARTLGW_CheckCredits(N/A)
1 - 2018-09-11 [Log]: s:10:03:57 e:10:04:00 f:3.006 d:no bad guy found :-(
1 - 2018-09-11 [Log]: s:10:04:16 e:10:04:19 f:3.005 d:no bad guy found :-(
1 - 2018-09-11 [Log]: s:10:05:00 e:10:05:03 f:3.007 d:PRESENCE_StartLocalScan(PRESENCE_rr_Mathze) BlockingKill(N/A)
1 - 2018-09-11 [Log]: s:10:05:19 e:10:05:22 f:3.006 d:HttpUtils_Err(N/A)
1 - 2018-09-11 [Log]: s:10:06:03 e:10:06:06 f:3.007 d:PRESENCE_StartLocalScan(PRESENCE_rr_Mathze) BlockingKill(N/A)
1 - 2018-09-11 [Log]: s:10:06:23 e:10:06:25 f:2.081 d:HMUARTLGW_CheckCredits(N/A) HMUARTLGW_CheckCredits(N/A) PRESENCE_StartLocalScan(PRESENCE_rr_Mathze) BlockingKill(N/A)
1 - 2018-09-11 [Log]: s:10:07:07 e:10:07:09 f:2.172 d:MQTT((Timer(myBroker) SIGNALduino_KeepAlive(SIGNALduino) HUEBridge_GetUpdate(HueBridge) DLCD_GetUpdate(dlcd_WeMoS_LCD) SONOS_IsSub...
1 - 2018-09-11 [Log]: s:10:07:26 e:10:07:28 f:2.094 d:HMUARTLGW_CheckCredits(N/A) HMUARTLGW_CheckCredits(N/A)
1 - 2018-09-11 [Log]: s:10:07:36 e:10:07:41 f:5.319 d:at_Exec(check_Rollo) BlockingKill(N/A)
1 - 2018-09-11 [Log]: s:10:08:10 e:10:08:12 f:2.116 d:MQTT((Timer(myBroker) SIGNALduino_KeepAlive(SIGNALduino) HUEBridge_GetUpdate(HueBridge)
1 - 2018-09-11 [Log]: s:10:08:29 e:10:08:31 f:2.467 d:HMUARTLGW_CheckCredits(N/A) HMUARTLGW_CheckCredits(N/A) at_Exec(at_fl_Zeit)
1 - 2018-09-11 [Log]: s:10:09:12 e:10:09:15 f:3.043 d:PRESENCE_StartLocalScan(QNAP) BlockingKill(N/A)
1 - 2018-09-11 [Log]: s:10:09:31 e:10:09:34 f:3.019 d:no bad guy found :-(
1 - 2018-09-11 [Log]: s:10:10:16 e:10:10:18 f:2.219 d:MQTT((Timer(myBroker) SIGNALduino_KeepAlive(SIGNALduino) HUEBridge_GetUpdate(HueBridge) DLCD_GetUpdate(dlcd_WeMoS_LCD) SONOS_IsSub...
1 - 2018-09-11 [Log]: s:10:10:35 e:10:10:37 f:2.188 d:HMUARTLGW_CheckCredits(N/A) HMUARTLGW_CheckCredits(N/A)
1 - 2018-09-11 [Log]: s:10:11:19 e:10:11:21 f:2.203 d:MQTT((Timer(myBroker) SIGNALduino_KeepAlive(SIGNALduino) HUEBridge_GetUpdate(HueBridge) DLCD_GetUpdate(dlcd_WeMoS_LCD) SONOS_IsSub...
1 - 2018-09-11 [Log]: s:10:11:38 e:10:11:40 f:2.247 d:HMUARTLGW_CheckCredits(N/A) HMUARTLGW_CheckCredits(N/A) ESPEasy_statusRequest(WeMos_LCD)
1 - 2018-09-11 [Log]: s:10:12:22 e:10:12:24 f:2.178 d:MQTT((Timer(myBroker) SIGNALduino_KeepAlive(SIGNALduino) HUEBridge_GetUpdate(HueBridge) DLCD_GetUpdate(dlcd_WeMoS_LCD) SONOS_IsSub...
1 - 2018-09-11 [Log]: s:10:12:41 e:10:12:43 f:2.225 d:HMUARTLGW_CheckCredits(N/A) HMUARTLGW_CheckCredits(N/A)
1 - 2018-09-11 [Log]: s:10:13:24 e:10:13:27 f:3.012 d:no bad guy found :-(
1 - 2018-09-11 [Log]: s:10:13:44 e:10:13:46 f:2.293 d:HMUARTLGW_CheckCredits(N/A) HMUARTLGW_CheckCredits(N/A)
1 - 2018-09-11 [Log]: s:10:14:27 e:10:14:30 f:3.004 d:HttpUtils_Err(N/A)
1 - 2018-09-11 [Log]: s:10:14:46 e:10:14:49 f:3.006 d:no bad guy found :-(
1 - 2018-09-11 [Log]: s:10:15:30 e:10:15:33 f:3.006 d:no bad guy found :-(
1 - 2018-09-11 [Log]: s:10:15:50 e:10:15:52 f:2.058 d:HMUARTLGW_CheckCredits(N/A) HMUARTLGW_CheckCredits(N/A)
1 - 2018-09-11 [Log]: s:10:16:34 e:10:16:36 f:2.131 d:MQTT((Timer(myBroker) SIGNALduino_KeepAlive(SIGNALduino) HUEBridge_GetUpdate(HueBridge) DLCD_GetUpdate(dlcd_WeMoS_LCD) SONOS_IsSub...
1 - 2018-09-11 [Log]: s:10:16:53 e:10:16:55 f:2.155 d:HMUARTLGW_CheckCredits(N/A) HMUARTLGW_CheckCredits(N/A)
1 - 2018-09-11 [Log]: s:10:17:37 e:10:17:39 f:2.21 d:MQTT((Timer(myBroker) SIGNALduino_KeepAlive(SIGNALduino) HUEBridge_GetUpdate(HueBridge) DLCD_GetUpdate(dlcd_WeMoS_LCD) SONOS_IsSubp...
Man kann fast sagen, dass es im Minuten- / Sekundentakt zu neuen Einträgen kommt.
Einige Einträge, wie z.B. HMUARTLGW, PRESENCE sagt mir auch was. Hierbei handelt es sich ja um eins meiner HM Module (habe zwei, 1x WLAN und 1x USB), beim PRESENCE vermute ich Bluetooth.
Bei beiden Geräten habe ich aber aber keinerlei Einfluss auf die Freeze's.
Beim letzten Freeze in der Liste, habe ich eine Routine in meiner 99_myUtils, welche alle 15Minuten per AT aufgerufen wird, wieso hier ein Freeze von über 5Sekunden zustande kommt, ist mir bisher ein Rätsel.
Ich weiß nun leider nicht wie ich weiter vorgehen soll, um die Freezes zu entfernen?
Habe nun zuerst einmal auf die aktuellste Version 0.0.20 geupdatet.
Ich lege zuerst einmal mein Hauptaugenmerkt auf die bad guys.
Nachdem ich ein
attr myFreezemon fm_CatchFnCalls 0
gemacht habe, hat FHEM den Dienst quittiert.
Musste FHEM per SSH und restart neustarten, danach lief es ohne das Attribut dann wieder.
Ein
attr myFreezemon fm_CatchCmds 0
hat FHEM angenommen.
Gruß
Mathze
Hallo,
irgendwie kann ich den Freezmon nicht laden,
das steht in der fhem.cfg
define myFreezemon freezemon
und das steht dann im fhem log
reload: Error:Modul 98_freezemon deactivated:
Global symbol "$FW_ME" requires explicit package name at ./FHEM/98_freezemon.pm line 1206, <$fh> line 17.
2018.09.13 07:50:32 0: Global symbol "$FW_ME" requires explicit package name at ./FHEM/98_freezemon.pm line 1206, <$fh> line 17.
fhem ist soweit aktuell, das letzte update ist ca 2 wochen her.
irgendwelche ideen?
Zitat von: hgw77 am 13 September 2018, 09:05:54
fhem ist soweit aktuell, das letzte update ist ca 2 wochen her.
Ähm nein, ist es nicht. Es ist zwei Wochen alt. Bring es doch mal auf den wirklich aktuellen Stand oder prüfe zumindest mit updatecheck, ob bei Freezmon etwas geändert wurde seit deinem letzten Update.
Mahlzeit!
Ich habe aktuell eine Reihe von Freezes der Art:
Mon 08.10.2018 16:07:44 freezemon s:16:07:40 e:16:07:44 f:4.028 d:tmr-CODE(0x9952408)(__ANON__)
Kann man dem irgendwie weiter auf die Spur kommen? An Hand der Freezelogs habe ich zwar einen Verdacht, aber eine genauere Eingrenzung wäre hilfreich.
Patrick
Ich finde das Modul ja super, aber ich werde aus ihm einfach nicht schlau :(
Aktuelles Beispiel:
Ich hatte regelmäßig Freezes. Freezemon schlägt auch an. Das Log dazu:
[Freezemon] sys_freezemon: possible freeze starting at 17:39:37, delay is 2.378 possibly caused by: tmr-DbLog_execmemcache(benDbLog) tmr-EspLedController_Check(ku_lightLedCeil) tmr-EspLedController_Check(wz_lightLedCouch) tmr-EspLedController_Check(wz_lightLedTv) tmr-EspLedController_Check(ku_lightLedFloor) tmr-EspLedController_Check(sz_lightLedWall) tmr-HMUARTLGW_CheckCredits(N/A) tmr-PRESENCE_StartLocalScan(sz_s8_pres)
2018.11.18 17:39:39.360 4: ku_lightLedCeil: EspLedController_CheckConnection: Connection still alive. Last data received 54.8333749771118 s ago
2018.11.18 17:39:39.360 4: wz_lightLedCouch: EspLedController_CheckConnection: Connection still alive. Last data received 49.5493350028992 s ago
2018.11.18 17:39:39.360 4: wz_lightLedTv: EspLedController_CheckConnection: Connection still alive. Last data received 13.2357280254364 s ago
2018.11.18 17:39:39.361 4: ku_lightLedFloor: EspLedController_CheckConnection: Connection still alive. Last data received 52.7793941497803 s ago
2018.11.18 17:39:39.361 4: sz_lightLedWall: EspLedController_CheckConnection: Connection still alive. Last data received 23.6232011318207 s ago
2018.11.18 17:39:39.361 5: HMUARTLGW sys_culHm checking credits (from timer)
2018.11.18 17:39:39.361 5: HMUARTLGW sys_culHm send: 00 08
2018.11.18 17:39:39.361 5: HMUARTLGW sys_culHm send: (8): fd0003005008f836
2018.11.18 17:39:39.361 5: SW: fd0003005008f836
2018.11.18 17:39:39.364 5: PRESENCE (sz_s8_pres) - stopping timer
2018.11.18 17:39:39.364 5: PRESENCE (sz_s8_pres) - starting blocking call for mode function
2018.11.18 17:39:39.377 4: BlockingCall (PRESENCE_DoLocalFunctionScan): created child (112068), uses telnetPort to connect back
2018.11.18 17:39:39.379 5: [Freezemon] sys_freezemon: ----------- Starting Freeze handling at 2018.11.18 17:39:39.379 ---------------------
[Freezemon] sys_freezemon: possible freeze starting at 17:39:37, delay is 2.378 possibly caused by: tmr-DbLog_execmemcache(benDbLog) tmr-EspLedController_Check(ku_lightLedCeil) tmr-EspLedController_Check(wz_lightLedCouch) tmr-EspLedController_Check(wz_lightLedTv) tmr-EspLedController_Check(ku_lightLedFloor) tmr-EspLedController_Check(sz_lightLedWall) tmr-HMUARTLGW_CheckCredits(N/A) tmr-PRESENCE_StartLocalScan(sz_s8_pres)
Verstehe nicht so ganz, welches jetzt der vermutete Übeltäter ist. Oder sind das hier einfach mehrere mögliche Kandidaten?
tmr-DbLog_execmemcache(benDbLog) tmr-EspLedController_Check(ku_lightLedCeil) tmr-EspLedController_Check(wz_lightLedCouch) tmr-EspLedController_Check(wz_lightLedTv) tmr-EspLedController_Check(ku_lightLedFloor) tmr-EspLedController_Check(sz_lightLedWall) tmr-HMUARTLGW_CheckCredits(N/A) tmr-PRESENCE_StartLocalScan(sz_s8_pres)
Interessanterweise zeigte apptime nur genau ein Modul mit >1 Sekunde Delay an und das war mein Device "wz_tv" vom Typ "STV". Das taucht in der Freezemon-Liste jedoch nicht auf.
Das mit den mehreren Kandidaten begreife ich jetzt auch langsam...
Ich stelle mich hier auch mal ganz doof und bitte um eine grobe Einschätzung oder einen Vergleich. fm_freezeThreshold = 4 Sekunden.
Ich habe in einem halben Monat fast 1200 Freezes in der Logdatei. "Verursacher" (ist ja nicht klar ob) sind diverse Kandidaten, mal kein "bad guy", mal ein Dutzend.
Bis zu 22 Sekunden werden gemeldet, wobei ich noch nie aktiv eine solche Verzögerung erlebt habe. Dass das System für 10 Sekunden mal nicht reagiert, kommt schon öfter vor, aber noch zu selten um sich ernsthaft einen Reim drauf machen zu können.
Um einen groben Überblick zu bekommen, habe ich mir kurz ein Proggi zusammengehauen, was die "möglichen Kandidaten" einzeln erfasst und die dazugehörigen Freeze-Zeiten. Nachfolgend nach Häufigkeit sortiert also Anzahl, Kandidat und Zeitspanne der Freezes. Ich erhoffte mir dadurch eine eindeutige Identifikation, aber das Ergebnis ist immer noch "querbeet".
Freezeanalyzing for D:\VolkerDaten\Documents\Diverse\VB\UNDEF\fhem-2018-11.log
1183 freezes total
362x tmr-FileLog_dailySwitch(N/A), 4,29-5,22s
362x tmr-IrBlaster_TimerStatusRequest(IRBl3), 4-15s
362x tmr-MQTT::Timer(myBroker), 4-15s
362x tmr-ENIGMA2_GetStatus(DB500HD), 4-11,8s
362x tmr-IrBlaster_TimerStatusRequest(IRWz), 4-19,3s
307x tmr-IrBlaster_TimerStatusRequest(IRBl2), 4-15s
155x tmr-HMUARTLGW_CheckCredits(N/A), 4-19,3s
154x tmr-PRESENCE_StartLocalScan(GretkesHandy_WLAN), 4-13,9s
151x tmr-PRESENCE_StartLocalScan(RobotronFB), 4,02-15s
145x tmr-PRESENCE_StartLocalScan(RobertsHandy_FB), 4,02-15s
129x tmr-PRESENCE_StartLocalScan(VolkersHandy_FB), 4,02-15s
112x tmr-PRESENCE_StartLocalScan(VolkersEifonFB), 4-15s
108x tmr-PRESENCE_StartLocalScan(GretkesHandy_FB), 4-15s
107x tmr-PRESENCE_StartLocalScan(TeufelConnector1), 4-19,3s
107x tmr-sequence_Trigger(N/A), 5,33-5,33s
107x tmr-CUL_HM_respPendTout(N/A), 4,01-13,6s
107x tmr-PRESENCE_StartLocalScan(PhilipsTV), 4,03-15s
105x tmr-FW_closeInactiveClients(N/A), 4-13,6s
103x tmr-PRESENCE_StartLocalScan(VolkersPCPing), 4-13,6s
84x tmr-DOIF_SleepTrigger(FK_KGSuedL), 4,08-5,99s
83x tmr-PRESENCE_StartLocalScan(TeufelConnector3), 4,03-15s
81x tmr-HMUARTLGW_CheckCmdResp(HMUART), 4,05-15s
76x tmr-HMUARTLGW_CheckCmdResp(HMWLAN1), 4,05-15s
67x no bad guy found :-(, 4-22,5s
64x tmr-CUL_HandleWriteQueue(CUL1), 4,07-10,3s
62x tmr-DOIF_SleepTrigger(di_AlarmanlageLicht), 4,49-9,26s
56x tmr-PRESENCE_StartLocalScan(VolkersHandy_WLAN), 4-14,4s
53x tmr-PRESENCE_StartLocalScan(VolkersHandy_BT), 4,02-12,9s
48x tmr-BlockingKill(N/A), 4,22-15s
44x tmr-DOIF_TimerTrigger(di_LogPresenceEveryHour), 4,03-7,5s
43x tmr-DOIF_TimerTrigger(di_SaveDewpoints), 4,01-7,77s
41x tmr-DOIF_TimerTrigger(di_SaveIndoorValues), 4,01-7,77s
38x tmr-DOIF_TimerTrigger(di_SaveOutdoorValues), 4,01-7,77s
35x tmr-DOIF_TimerTrigger(di_UpdateFHEMStatusOnHMSA), 4,01-15s
31x tmr-HMUARTLGW_SendPendingTimer(HMWLAN1), 4,08-6,67s
29x tmr-PRESENCE_StartLocalScan(GretkesHandy_BT), 4,02-15s
28x tmr-PRESENCE_StartLocalScan(BennisIPhone), 4,01-12s
14x tmr-PRESENCE_StartLocalScan(Dreambox), 4,23-11,4s
13x tmr-HttpUtils_Err(N/A), 4-21,1s
12x tmr-PRESENCE_StartLocalScan(RobertsHandy_WLAN),
Irgendwie werde ich den Eindruck nicht los, dass hier eigentlich ein ganz anderes Problem vorliegt. Es sind auffallend viele Aktionen, die mit dem Netzwerk zu tun haben, meist Erreichbarkeitstests (PRESENCE - aber auch Bluetooth, IR-Blaster, HMLAN-WLAN-Gateway, ENIGMA), aber auch DOIFs. Aber auch die "no bad guys" sind nicht selten - und die längsten Freezes.
Ich gehe den 15-Sekunden-Freezes auch mal näher. Außerdem werde ich mal eine neue Speicherkarte avisieren, wobei die meisten Freezes definitiv keine Speicherkartenaktionen auslösen oder davon abhängen. Bis dahin:
Irgendeiner ne Idee was da nicht läuft?
edit: PRESENCE mit _FB sind Fritzbox-Abfragen, und die rangieren ja wirklich recht weit vorn.
Ich hab wenig Glück generell, mit dem Freezemon den Verursacher zu identifizieren... Was sagt denn "apptime" bei dir?
Und mir ist auch öfter aufgefallen, dass freezemon einen Freeze meldet (sagen wir 2 s), aber apptime gar kein Delay festgestellt hat. Ist das erklärbar?
ZitatUnd mir ist auch öfter aufgefallen, dass freezemon einen Freeze meldet (sagen wir 2 s), aber apptime gar kein Delay festgestellt hat. Ist das erklärbar?
das kenne ich auch.
manchmal habe ich den verdacht, dass dann eventuell freezes von einem fhem-fork festgestellt werden. ist das technisch überhaupt möglich?
in die verursacher liste schaue ich schon gar nicht mehr. echte hinweise bringt eigentlich nur die log option, finde ich.
Zitatin die verursacher liste schaue ich schon gar nicht mehr. echte hinweise bringt eigentlich nur die log option, finde ich.
Das sehe ich auch so. Wenn einmal die "schlimmsten" Verursacher identifiziert sind, wird es sehr zäh und freezemon liefert "nur" den Anstoß mal in das freeze-log zu gucken.
Zitatmanchmal habe ich den verdacht, dass dann eventuell freezes von einem fhem-fork festgestellt werden. ist das technisch überhaupt möglich?
So einen Verdacht habe ich auch. Ich hatte zufällig heute Morgen einen 15 Sek. freeze im Log. Im freeze-Log war noch nicht einmal die typische Zeile ...---log skips..... Davor aber ein "kurzer" freeze. Ich habs mal übersichtlich zusammenkopiert. Unverdächtige wie RFXTRX entfernt.
=========================================================
[Freezemon] freezedetect: possible freeze starting at 07:53:40, delay is 1.177 possibly caused by: tmr-GPIO4_DeviceUpdateLoop(RPi_OW_VL)
2018.11.21 07:53:39.196 4: Connection accepted from telnetForBlockingFn_1542634689_127.0.0.1_55124
2018.11.21 07:53:39.201 5: Cmd: >{BlockingRegisterTelnet($cl,66153)}<
2018.11.21 07:53:39.245 5: Cmd: >{BlockingStart('66153')}<
2018.11.21 07:53:39.251 5: Cmd: >{SYSMON_blockingFinish('name|sys_mon|fhemuptime|148526|fhemstarttime_text|19.11.2018 14:38:13|fhemstarttime|1542634693|fhemuptime_text|1 days, 17 hours, 15 minutes')}<
2018.11.21 07:53:39.252 5: SYSMON sys_mon: blockingFinish.1041 name|sys_mon|fhemuptime|148526|fhemstarttime_text|19.11.2018 14:38:13|fhemstarttime|1542634693|fhemuptime_text|1 days, 17 hours, 15 minutes
2018.11.21 07:53:39.252 5: SYSMON sys_mon: updateReadings.1060
.
.
2018.11.21 07:53:39.631 4: https://layla.amazon.de/api/device-preferences: HTTP response code 200
2018.11.21 07:53:39.632 5: HttpUtils https://layla.amazon.de/api/device-preferences: Got data, length: 1045
2018.11.21 07:53:39.632 5: HttpUtils response header: .....
2018.11.21 07:53:39.632 4: [echomaster] [echodevice_Parse] [getdevicesettings]
2018.11.21 07:53:39.634 5: [echomaster] [echodevice_Parse] [getdevicesettings] DATA Dumper=$VAR1 = ...
2018.11.21 07:53:39.648 5: End notify loop for echomaster
2018.11.21 07:53:39.670 5: End notify loop for echo
2018.11.21 07:53:39.672 4: [echomaster] [echodevice_HandleCmdQueue] [listitems_shopping] send command=...
2018.11.21 07:53:39.672 5: HttpUtils url=https://layla.amazon.de/api/todos?size=......
2018.11.21 07:53:39.675 5: IP: layla.amazon.de -> 52.94.220.236
2018.11.21 07:53:39.945 5: HttpUtils request header: GET /api/todos?size=100&...type=SHOPPING_ITEM.....
2018.11.21 07:53:39.948 5: GPIO4: GPIO4_DeviceUpdateLoop(RPi_OW_VL), pollingInterval:40
2018.11.21 07:53:39.966 4: BlockingCall (GPIO4_Get): created child (19707), uses telnetForBlockingFn_1542634689 to connect back
2018.11.21 07:53:39.976 5: TRX/RAW: ...
.
.
2018.11.21 07:53:39.986 5: TRX_WEATHER: name=Mess_4 device=REVOLT_40da energy_freq=50
--- log skips 1.186 secs.
2018.11.21 07:53:41.173 5: End notify loop for Mess_4
2018.11.21 07:53:41.173 5: TRX_Read END
2018.11.21 07:53:41.175 4: Connection accepted from telnetForBlockingFn_1542634689_127.0.0.1_55128
2018.11.21 07:53:41.177 5: [Freezemon] freezedetect: ----------- Starting Freeze handling at 2018.11.21 07:53:41.177 ---------------------
[Freezemon] freezedetect: possible freeze starting at 07:53:40, delay is 1.177 possibly caused by: tmr-GPIO4_DeviceUpdateLoop(RPi_OW_VL)
=========================================================
[Freezemon] freezedetect: possible freeze starting at 07:53:42, delay is 15.067 possibly caused by: tmr-NEUTRINO_GetStatus(DBox)
2018.11.21 07:53:56.952 4: Connection accepted from WEB_192.168.178.35_65451
2018.11.21 07:53:56.953 5: Cmd: >{BlockingStart('66152')}<
2018.11.21 07:53:56.957 5: Cmd: >{GPIO4_GetfinishFn('RPi_OW_ZW|28|000005fab536|T: 1.437|1.437')}<
2018.11.21 07:53:56.958 5: GPIO4: GPIO4_GetfinishFn(RPi_OW_ZW) Start
2018.11.21 07:53:56.959 5: GPIO4: GPIO4_GetfinishFn(RPi_OW_ZW) End
2018.11.21 07:53:56.963 4: https://layla.amazon.de/api/todos?size=100&startTime=&endTime=&completed=false&type=SHOPPING_ITEM...
2018.11.21 07:53:56.963 5: HttpUtils https://layla.amazon.de/api/todos??size=100...&type=SHOPPING_ITEM...
2018.11.21 07:53:56.963 5: HttpUtils response header: .....
2018.11.21 07:53:56.963 4: [echomaster] [echodevice_Parse] [listitems_shopping]
2018.11.21 07:53:56.965 5: [echomaster] [echodevice_Parse] [listitems_shopping] DATA Dumper=$VAR1 = '{"values":[]}';
2018.11.21 07:53:56.978 5: End notify loop for echomaster
2018.11.21 07:53:56.991 5: End notify loop for echomaster
2018.11.21 07:53:56.993 4: [echomaster] [echodevice_HandleCmdQueue] [listitems_task] send command=https:...
2018.11.21 07:53:56.993 5: HttpUtils url=https://layla.amazon.de/api/todos?size=....
2018.11.21 07:53:56.996 5: IP: layla.amazon.de -> 52.94.220.236
2018.11.21 07:53:56.998 5: TRX/RAW: /.....
.
.
2018.11.21 07:53:57.058 5: End notify loop for Mess_4
2018.11.21 07:53:57.058 5: TRX_Read END
2018.11.21 07:53:57.060 4: Connection accepted from telnetForBlockingFn_1542634689_127.0.0.1_55130
2018.11.21 07:53:57.064 5: NEUTRINO DBox [NEUTRINO_GetStatus] called function
2018.11.21 07:53:57.064 5: NEUTRINO DBox [NEUTRINO_SendCommand] called function CMD =
2018.11.21 07:53:57.064 5: NEUTRINO DBox [NEUTRINO_SendCommand] using unencrypted connection via HTTP
2018.11.21 07:53:57.064 4: NEUTRINO DBox [NEUTRINO_SendCommand] SERVICE = powerstate
2018.11.21 07:53:57.065 5: NEUTRINO DBox [NEUTRINO_HD_SendCommand] - append to queue http://192.168.178.30:80/control/standby
2018.11.21 07:53:57.065 5: NEUTRINO DBox [NEUTRINO_HD_HandleCmdQueue] - send command
2018.11.21 07:53:57.065 5: HttpUtils url=http://192.168.178.30:80/control/standby
2018.11.21 07:53:57.066 5: IP: 192.168.178.30 -> 192.168.178.30
2018.11.21 07:53:57.067 5: [Freezemon] freezedetect: ----------- Starting Freeze handling at 2018.11.21 07:53:57.067 ---------------------
[Freezemon] freezedetect: possible freeze starting at 07:53:42, delay is 15.067 possibly caused by: tmr-NEUTRINO_GetStatus(DBox)
=========================================================
Das NEUTRINO-Modul ist sicherlich nicht der eigentliche Verursacher. Zwar hat es meines Wissens tatsächlich blocking calls, aber die Kiste ist die ganze Zeit aus und der freeze müsste folglich regelmäßig auftauchen.
GPIO4 hab ich höchst persönlich auf non-blocking umgestellt.
SYSMON hab ich immer mal im Verdacht, aber glaub ich eher nicht.
Das echo-Modul scheint am auffälligsten, arbeitet aber meines Wissens non-blocking. Irritierend ist aber, dass kurz vor dem langen freeze ein kurzer freeze war. Und dass erst mit dem 2. freeze der echo um 07:53:56.965 e ine Antwort der Abfrage von 07:53:39.945 zu liefern scheint(Stichwort: listitems_shopping), diese dann aber mit DATA Dumper=$VAR1 = '{"values":[]}, was mich annehmen lässt dass der HTTP-Zugriff fehlgeschlagen ist ? :-\ ???
Grüße Markus
Das sagt apptime bei mir:
active-timers: 108; max-active timers: 128; max-timer-load: 18 min-tmrHandlingTm: 0.0ms; max-tmrHandlingTm: 6401.0ms; totAvgDly: 397.1ms
name function max count total average maxDly avgDly TS Max call param Max call
HMWLAN1 HMUARTLGW_Read 12482 43363 2213463.02 51.04 0.00 0.00 21.11. 19:12:33 HASH(HMWLAN1)
tmr-Weather_GetUpdate HASH(0x43a05a0) 5044 116 8997.99 77.57 6593.49 247.91 20.11. 18:33:30 HASH(MeinWetter)
tmr-DOIF_SleepTrigger HASH(0x3f057e0) 4699 35 13086.08 373.89 3085.34 395.48 21.11. 10:04:25 HASH(di_GaragentorSensorAntriebscheck)
tmr-DOIF_SleepTrigger HASH(0x3fecae0) 4460 8 11747.81 1468.48 2646.27 760.91 19.11. 20:09:34 HASH(di_MakroMusik)
VolkerFon andnotify_Set 4435 73 15151.66 207.56 0.00 0.00 21.11. 10:04:24 HASH(VolkerFon); VolkerFon; send; Garagentor-Zu-Ersatzmeldung|FHEM:; Garagentor; zu; ohne; Antriebsmeldung|Garagentor:; unklar; geschlossen|Problem|2
IRcmd dummy_Set 4196 13 9729.31 748.41 0.00 0.00 19.11. 20:09:34 HASH(IRcmd); IRcmd; YamahaReceiverOFF
di_Send_IRcmd DOIF_Notify 4130 172290 47742.74 0.28 0.00 0.00 19.11. 20:09:34 HASH(di_Send_IRcmd); HASH(IRcmd)
CUL433 CUL_Read 4049 51408 1686737.39 32.81 0.00 0.00 19.11. 13:25:33 HASH(CUL433)
HMUART HMUARTLGW_Read 3802 63987 6440959.57 100.66 0.00 0.00 19.11. 13:25:37 HASH(HMUART)
tmr-HMUARTLGW_CheckCmdResp HASH(0x26db2d8) 3418 809 26812.41 33.14 16482.34 170.72 21.11. 19:13:06 HASH(HMUART)
di_AlarmanlageZustand DOIF_Notify 3103 172290 58190.63 0.34 0.00 0.00 19.11. 13:29:09 HASH(di_AlarmanlageZustand); HASH(AAZS)
MySensorsGW MYSENSORS::Ready 3019 824717 10194384.30 12.36 0.00 0.00 21.11. 18:39:48 HASH(MySensorsGW)
HMLAN1 HMLAN_Ready 3012 824717 10221801.62 12.39 0.00 0.00 19.11. 23:41:51 HASH(HMLAN1)
AlarmanlageZustand dummy_Set 2935 38 18273.37 480.88 0.00 0.00 19.11. 13:29:09 HASH(AlarmanlageZustand); AlarmanlageZustand; Vollscharf
tmr-DOIF_SleepTrigger HASH(0x3fe8ea0) 2869 10 7272.85 727.28 2538.23 434.57 20.11. 00:00:18 HASH(di_MakroTV)
tmr-HMUARTLGW_CheckCmdResp HASH(0x449d528) 2544 946 18437.86 19.49 11129.18 193.09 19.11. 13:25:43 HASH(HMWLAN1)
tmr-at_Exec HASH(0x341a278) 2491 2 4192.77 2096.39 6.81 5.49 21.11. 06:59:06 HASH(VergesseneLichterAus)
nfyAlarmAnlZustandNotify notify_Exec 2304 18 8349.48 463.86 0.00 0.00 19.11. 13:29:09 HASH(nfyAlarmAnlZustandNotify); HASH(AlarmanlageZustand)
tmr-DOIF_SleepTrigger HASH(0x3d76850) 2293 4 7999.13 1999.78 1144.92 290.36 19.11. 13:29:12 HASH(di_AlarmanlageLicht)
AlleFon andnotify_Set 2186 41 7051.28 171.98 0.00 0.00 19.11. 13:29:09 HASH(AlleFon); AlleFon; send; Alarmanlage; wurde; auf; Vollscharf; geschaltet|FHEM:; Alarmanlage=Vollscharf|Alarmanlagenzustand:; Vollscharf|Statusmeldung|2
Alle_Lichter structure_Set 2155 1218 7634.93 6.27 0.00 0.00 19.11. 13:29:12 HASH(Alle_Lichter); Alle_Lichter; aus
tmr-DOIF_SleepTrigger HASH(0x3ee4220) 1968 19 17562.86 924.36 3203.59 176.59 21.11. 10:05:31 HASH(di_GaragentorZustandByDF)
myDuoFernStick DUOFERNSTICK_Read 1926 249 21690.55 87.11 0.00 0.00 20.11. 20:50:47 HASH(myDuoFernStick)
GaragentorZustand dummy_Set 1847 119 32664.25 274.49 0.00 0.00 21.11. 10:05:31 HASH(GaragentorZustand); GaragentorZustand; closed
tmr-DOIF_SleepTrigger HASH(0x3ec6bc0) 1825 15 23444.53 1562.97 3416.59 582.62 21.11. 16:40:40 HASH(FK_EGWzTerrasse)
tmr-DOIF_SleepTrigger HASH(0x402df98) 1691 8 12685.47 1585.68 3762.87 1111.86 19.11. 22:26:20 HASH(FK_KGSuedL)
tmr-DOIF_SleepTrigger HASH(0x36a3c20) 1645 3 4832.87 1610.96 1025.71 345.19 19.11. 23:11:50 HASH(di_AlarmanlageZustand)
di_GaragentorZustand_Mitteilung DOIF_Notify 1490 172290 49696.61 0.29 0.00 0.00 21.11. 10:05:30 HASH(di_GaragentorZustand_Mitteilung); HASH(GaragentorZustand)
CUL1 CUL_Read 1457 6216 543297.96 87.40 0.00 0.00 19.11. 12:51:51 HASH(CUL1)
myDuoFernStick DUOFERNSTICK_Set 1455 194 3684.76 18.99 0.00 0.00 19.11. 18:52:39 HASH(myDuoFernStick); myDuoFernStick; reopen
VolkersHandy structure_Notify 1448 172290 150343.30 0.87 0.00 0.00 21.11. 17:32:57 HASH(VolkersHandy); HASH(VolkersHandy_BT)
tmr-DOIF_SleepTrigger HASH(0x4348c38) 1443 14 6946.96 496.21 7688.88 1492.61 21.11. 00:51:20 HASH(di_MakroHeimkino)
CUL433 CUL_Get 1363 12 5766.48 480.54 0.00 0.00 19.11. 12:36:56 HASH(CUL433); ; raw; is1110D1F11F00
FK_KGSuedL DOIF_Notify 1338 172290 53384.56 0.31 0.00 0.00 21.11. 01:00:19 HASH(FK_KGSuedL); HASH(SensorKGSzLiU)
di_Briefklappe DOIF_Notify 1329 172290 41518.00 0.24 0.00 0.00 21.11. 15:15:34 HASH(di_Briefklappe); HASH(Briefkastenklappe)
di_AutofernbedienungGaragentor DOIF_Notify 1295 172290 43813.46 0.25 0.00 0.00 19.11. 13:27:04 HASH(di_AutofernbedienungGaragentor); HASH(DUOFERN_A707A8)
tmr-CUL_HM_respPendTout respPend 1291 1150 72259.03 62.83 12676.83 302.02 19.11. 18:00:20 respPend:41D287
tmr-IrBlaster_TimerStatusRequest HASH(0x4470068) 1248 3303 567181.95 171.72 15832.92 2914.02 20.11. 20:28:30 HASH(IRBl3)
GretkesHandy structure_Notify 1247 172290 217109.95 1.26 0.00 0.00 20.11. 18:55:18 HASH(GretkesHandy); HASH(GretkesHandy_BT)
tmr-DOIF_TimerTrigger REF(0x59974f8) 1239 1 1239.16 1239.16 6.67 6.67 19.11. 10:50:01 REF(0x59974f8)
di_GarageAussentaster DOIF_Notify 1223 172290 38975.77 0.23 0.00 0.00 19.11. 19:49:27 HASH(di_GarageAussentaster); HASH(GarageAussentaster)
Die fettesten Hänger entstehen nach meiner Interpretation rund um das HM-WLAN-Dingens sowie meine Infrarot-Blaster - also beides Netzwerksachen. Was die DOIF-Sleeptrigger da zu suchen haben, erschließt sich mir hingegen gar nicht, das ist eigentlich alles ganz unkompliziertes Zeugs.
Sind da behandlungswürdige Ausreißer dabei oder gehört das noch zum Grundrauschen?
Also alles größer 1 Sekunde find ich behandlungswürdig, ehrlich gesagt. Ist ja ein richtiges Schlachtfest bei dir :)
Kann es sein, dass dein FHEM als Ganzes bzw. der ganze Rechner ab und zu blockiert ist? Kernel-Hänger oder andere Prozesse, die sich die CPU mopsen? Kann mir kaum was anderes vorstellen bei der Vielzahl und Verschiedenartigkeit der betroffenen Module?
Zitat von: vbs am 21 November 2018, 22:13:18
Also alles größer 1 Sekunde find ich behandlungswürdig, ehrlich gesagt. Ist ja ein richtiges Schlachtfest bei dir :)
Na toll. Ist's also doch so schlimm ???
Zitat
Kann es sein, dass dein FHEM als Ganzes bzw. der ganze Rechner ab und zu blockiert ist? Kernel-Hänger oder andere Prozesse, die sich die CPU mopsen? Kann mir kaum was anderes vorstellen bei der Vielzahl und Verschiedenartigkeit der betroffenen Module?
Das dachte ich mir irgendwie auch schon mal. Generell ist der Raspi 2B seit geraumer Zeit unaufgeräumt, rannte vor zwei Jahren einwandfrei, hat danach eigentlich nur ein JeeLink-Gateway dazubekommen und MQTT. Ein Quell ständigen Ärgernisses ist die WLAN-Verbindung. Ich werde mal das HM-WLAN rauswerfen und das alte HMLAN reaktivieren und den Raspi per LAN ankoppeln - und der 3er liegt seit einem halben Jahr für die Neueinrichtung. Das scheint sich ja dann wirklich endlich mal zu lohnen...
edit: Ich bin sowas von gar kein LINUX-Experte. Ne Idee, wie man dem Raspi auf Betriebssystemebene ein Monitoring bezüglich solcher Hänger verpassen kann? grobe Richtung reicht.
Guck doch mal mit "dmesg -T", was der Kernel so von sich gegeben hat. Vielleicht sieht man da was. Ansonsten erstmal Prozessliste beobachten, denk ich.
Gibt noch LTTng (https://en.wikipedia.org/wiki/LTTng), aber das ist sicherlich etwas übertrieben für den Anfang.
"dmseg -T" liefert nach dem heutigen Reboot (FHEM meldete gestern erstmals "cannot fork ...", ich vermute apptime als Mitverursacher, weil ebenfalls erstmals länger in Nutzung, und heute morgen war FHEM dann tot) nach vielen Systemmeldungen vom Neustart dann mit viel Regelmäßigkeit (timeouts alle 1-3 Minuten und die zweite Meldung alle 15-20 Minuten) Meldungen wie
[Thu Nov 22 11:19:58 2018] Bluetooth: hci0 command 0x0419 tx timeout
[Thu Nov 22 11:22:16 2018] Transfer to device 8 endpoint 0x1 frame 994 failed - FIQ reported NYET. Data may have been lost.
Kurzes Googlen bringt das in Zusammenhang mit Bluetooth. Die PRESENCEs mit Bluetooth-Scan sind jetzt disabled - und die Meldungen kommen nicht mehr.
"top" listet perl mit user fhem zwischen 2 und 12%, CPU-Last, mit einer laufenden Websession etwa 5-10% mehr. Rufe ich dort mal ein SVG mit langem Zeitraum auf, bleibt die CPU-Last von FHEM stabil um 99.5%, bis das Diagramm fertig ist. Das sieht für mich alles unverdächtig aus, in dem Sinne dass FHEM so ziemlich der einzige Lastfresser auf dem Pi zu sein scheint.
Freezes kommen leider immer noch:
2018.11.22 12:14:04 1: [Freezemon] freezemon: possible freeze starting at 12:13:57, delay is 7.74 possibly caused by: no bad guy found :-(
2018.11.22 12:14:22 1: [Freezemon] freezemon: possible freeze starting at 12:14:15, delay is 7.093 possibly caused by: no bad guy found :-(
2018.11.22 12:16:02 1: [Freezemon] freezemon: possible freeze starting at 12:15:55, delay is 7.544 possibly caused by: tmr-PRESENCE_StartLocalScan(VolkersEifonFB) tmr-PRESENCE_StartLocalScan(RobotronFB) tmr-HMUARTLGW_CheckCredits(N/A) tmr-HMUARTLGW_CheckCredits(N/A) tmr-PRESENCE_StartLocalScan(VolkersHandy_WLAN)
edit: Allerdings hatte ich in genau der Zeit FHEM mit den SVGs ausgelastet. Nicht dass diese Freezes eben doch irrtümlich gemeldet werden?
Ich baue jetzt einen Raspi 3 von Grund auf neu und ziehe mein FHEM anschließend dahin um...
@Pfriemler:
sieht auf den ersten Block "normal" aus
mein Bauch sagt, dass auch Probleme mit der Stromversorgung bzw. der Temperatur vorhanden sein könnten
btw: Bei mir will ich auch für mein Zuhause 2.0 die FHEM Installation in verschiedene Instanzen splitten und via MQTT quatschen lassen
nach meinen erfahrungen muss man mindestens 3 "auffälligkeiten" unterscheiden.
1. speicherleck in perl/fhem.(zb https://forum.fhem.de/index.php/topic,84372.0.html (https://forum.fhem.de/index.php/topic,84372.0.html))
freezemon mit option apptime verstärkt den effekt enorm, zumindestens bei mir. dazu gibt es inzwischen das event "global:CANNOT_FORK", um zb einen fhem restart auszulösen.
2. freezes ohne "log skipps"
hierzu hatte ich schon riesige verbose 5 logs, in denen nach den timestamps der logeinträge bei weitem kein "platz" für ein freeze der angegebenen dauer war.
3. freezes mit "log skipps"
hier kann es zum freeze start hinweise zum auslöser des freeze geben.
"get freezemon log" hat bei mir gerade einen eigenen freeze (12s => no bad gay) ausgelöst.
Zitat von: Wuppi68 am 22 November 2018, 13:49:55
@Pfriemler: sieht auf den ersten Blick "normal" aus ...
mein Bauch sagt, dass auch Probleme mit der Stromversorgung bzw. der Temperatur vorhanden sein könnten
Temperatur laut System zwischen 42 und 45 Grad. Stromversorgung - tja, die rote LED leuchtet mit kurzen Unterbrechnungen fast ständig, trotz guter Kabel und kräftigem Netzteil (mit 5.2V Ausgangsspannung), aber das tut sie ebenfalls schon seit Jahren und als das System noch klaglos rannte. So ein Hänger wie heute früh ist neben einem vor drei Wochen der erste seit mehr als einem Jahr, ohne dass das System regelmäßig rebootet wird (schon gar nicht über eine Automatik) - ich mach nur so alle 3-4 Monate ein Speicherkartenbackup, währenddessen das System natürlich down ist. So lange liefen Raspi und auch FHEM jedenfalls bisher ohne Probs durch...
ou ... und wenn ich franks Hinweise lese ... und den Fred dazu ... ist das mit einem frischen Raspian und dem Raspi 3 mit einem Male doch keine so gute Idee ... und der WAF sinkt weiter ...
Man liest sich, danke für alles Mitgefühl bis hierher ...
Nur kurz meine überraschende Erkenntnis:
Dank Olis Modul konnte ich die dicken Freezes(GPIO4, eigenes Modul...) eliminieren. Irgendwie wurden danach die freezes immer mehr, ohne dass ich "Schuldige" ermitteln konnte. Dann hatte ich gar Abstürze.
Ursache: nicht etwa ein Modul, sondern mein USB-Boot-Stick. Neue SD in Kombination mit aktuellstem Stretch == kein einziger freeze(< 0,7s) diese Nacht. ;D ;D ;D
Grüße Markus
PS: Zwischen meinem letzten Raspbian und aktuellem sind syslog-messages bei undervoltage eingeführt worden !!! War für mich sehr hilfreich, denn trotz visueller Überwachung mit einem Mess-Adapter tauchten im syslog (überraschend/unerwartet) undervoltages auf.
Zitat von: hgw77 am 13 September 2018, 09:05:54
[...]
reload: Error:Modul 98_freezemon deactivated:
Global symbol "$FW_ME" requires explicit package name at ./FHEM/98_freezemon.pm line 1206, <$fh> line 17.
2018.09.13 07:50:32 0: Global symbol "$FW_ME" requires explicit package name at ./FHEM/98_freezemon.pm line 1206, <$fh> line 17.
[...]
Hatte ich gerade auch. Du musst freezemon
NACH define FHEMWEB in der fhem.cfg einfügen.
Zitat von: stanford am 08 Dezember 2018, 10:18:38
Hatte ich gerade auch. Du musst freezemon NACH define FHEMWEB in der fhem.cfg einfügen.
module installiert man über das web-interface.
Hi,
ich habe nach einem Fhem Neustart folgende Meldung im Log
2019.01.08 19:07:02.847 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/98_freezemon.pm line 324.
2019.01.08 19:07:02.847 1: stacktrace:
2019.01.08 19:07:02.848 1: main::__ANON__ called by ./FHEM/98_freezemon.pm (324)
2019.01.08 19:07:02.848 1: main::freezemon_ProcessTimer called by fhem.pl (3153)
2019.01.08 19:07:02.849 1: main::HandleTimeout called by fhem.pl (650)
2019.01.08 19:07:02.850 1: [Freezemon] myFreezemon: possible freeze starting at 19:06:45, delay is 17.845 possibly caused by: no bad guy found :-(
Woher kommt das?
Danke
Hi Tommy,
welche Version hast du denn im Einsatz? Scheint mir nicht ganz die aktuelle zu sein... Kannst du mal ein "list -r" des freezemons posten?
Grüße,
Oli
Hi,
hier die Ausgabe
define myFreezemon freezemon
attr myFreezemon fm_forceApptime 1
attr myFreezemon group Info
attr myFreezemon room Zentral
setstate myFreezemon s:20:54:31 e:20:54:32 f:1.209 d:no bad guy found :-(
setstate myFreezemon 2019-01-09 20:54:32 .fm_freezes 2019-01-08: s:01:53:36 e:01:53:37 f:1.011 d:no bad guy found :-(,2019-01-08: s:02:02:00 e:02:02:23 f:23.075 d:tmr-MQTT2_SERVER_keepaliveChecker(MQTT2_FHEM_Server) tmr-at_Exec(at_fp_time) tmr-at_Exec(DbLog_aufrauumen) ,2019-01-08: s:05:30:00 e:05:30:01 f:1.18 d:tmr-at_Exec(at_fp_time) tmr-at_Exec(Weihnachtsdeko_an_am) ,2019-01-08: s:07:03:06 e:07:03:27 f:21.919 d:tmr-MQTT2_SERVER_keepaliveChecker(MQTT2_FHEM_Server) tmr-Calendar_Wakeup(AbfallA),2019-01-08: s:18:19:38 e:18:19:55 f:17.075 d:no bad guy found :-(,2019-01-08: s:18:29:33 e:18:29:34 f:1.039 d:tmr-CUL_HM_ActCheck(N/A) ,2019-01-08: s:18:30:00 e:18:30:01 f:1.165 d:tmr-at_Exec(Mila_Licht_1_an) tmr-at_Exec(Mila_Licht_2_an),2019-01-08: s:19:02:29 e:19:02:46 f:17.999 d:no bad guy found :-(,2019-01-08: s:19:02:47 e:19:02:48 f:1.197 d:tmr-HUEDevice_GetUpdate(HUEGroup1) tmr-HUEDevice_GetUpdate(HUEGroup0) tmr-at_Exec(at_fp_time) tmr-MQTT2_SERVER_keepaliveChecker(MQTT2_FHEM_Server) tmr-FRITZBOX_Readout_Start(N/A) tmr-CUL_HM_procQs(N/A) tmr-HMLAN_KeepAliveCheck(N/A),2019-01-08: s:23:13:39 e:23:13:58 f:19.536 d:no bad guy found :-(,2019-01-08: s:23:16:29 e:23:16:31 f:2.78 d:tmr-MQTT2_SERVER_keepaliveChecker(MQTT2_FHEM_Server) tmr-BlinkCamera_PollInfo(Kameras) ,2019-01-08: s:23:24:00 e:23:24:01 f:1.339 d:tmr-WOL_UpdateReadings(WinServer_ping) tmr-MQTT2_SERVER_keepaliveChecker(MQTT2_FHEM_Server) ,2019-01-08: s:23:30:24 e:23:30:27 f:3.307 d:no bad guy found :-(,2019-01-09: s:19:15:51 e:19:15:52 f:1.862 d:no bad guy found :-(,2019-01-09: s:19:30:37 e:19:31:06 f:29.048 d:no bad guy found :-(,2019-01-09: s:20:47:55 e:20:48:17 f:22.821 d:no bad guy found :-(,2019-01-09: s:20:48:19 e:20:48:20 f:1.094 d:tmr-CUL_HM_procQs(N/A) tmr-HMLAN_KeepAliveCheck(N/A) ,2019-01-09: s:20:51:00 e:20:51:05 f:5.701 d:tmr-at_Exec(at_fp_time) ,2019-01-09: s:20:52:53 e:20:52:58 f:5.716 d:no bad guy found :-(,2019-01-09: s:20:54:31 e:20:54:32 f:1.209 d:no bad guy found :-(
setstate myFreezemon 2019-01-09 19:16:42 .lastDay 2019-01-09
setstate myFreezemon 2019-01-09 20:54:32 fcDay 6
setstate myFreezemon 2019-01-09 19:16:42 fcDayLast 17
setstate myFreezemon 2019-01-09 20:54:32 freezeDevice no bad guy found :-(
setstate myFreezemon 2019-01-09 20:54:32 freezeTime 1.209
setstate myFreezemon 2019-01-09 20:54:32 ftDay 65.589
setstate myFreezemon 2019-01-09 19:16:42 ftDayLast 121.326
setstate myFreezemon 2019-01-09 20:54:32 state s:20:54:31 e:20:54:32 f:1.209 d:no bad guy found :-(
Ist diese Version
98_freezemon.pm 18087 2018-12-29 19:33:14Z KernSani
hab grad bei update check gesehen das es ein update gibt, ich spiel das mal ein
Zitat von: Tommy82 am 09 Januar 2019, 20:56:34
hab grad bei update check gesehen das es ein update gibt, ich spiel das mal ein
Ich bin mir ziemlich sicher, dass das nicht helfen wird.
Ich kann die warning, die bei dir auftritt nicht ganz nachvollziehen, ich habe aber gerade eben einen Fix hochgeladen, der andere Warnings beim FHEM start behebt - vielleicht hilft der auch bei dir. Ist mit dem Update morgen verfügbar.
Hi,
ok werde das Update auch einspielen und dann mal weiter beobachten.
Danke
Guten Morgen, habe heute Morgen wieder eine Meldung im LOg
2019.01.11 01:03:28.240 1: [Freezemon] myFreezemon: possible freeze starting at 01:03:24, delay is 4.236 possibly caused by: tmr-BlinkCamera_PollInfo(Kameras)
2019.01.11 02:02:39.500 1: [Freezemon] myFreezemon: possible freeze starting at 02:02:00, delay is 39.499 possibly caused by: tmr-at_Exec(DbLog_aufrauumen)
2019.01.11 02:02:41.519 1: [Freezemon] myFreezemon: possible freeze starting at 02:02:40, delay is 1.515 possibly caused by: tmr-WOL_UpdateReadings(WinServer_ping) tmr-at_Exec(at_fp_time) tmr-BlinkCamera_PollInfo(Kameras) tmr-SYSMON_Update(sysmon) tmr-MQTT2_SERVER_keepaliveChecker(MQTT2_FHEM_Server) tmr-MQTT2_SERVER_keepaliveChecker(MQTT2_FHEM_Server) tmr-ENIGMA2_GetStatus(VU_Ultimo) tmr-ENIGMA2_GetStatus(Uno_Schlafzimmer) tmr-HMLAN_KeepAlive(N/A) tmr-HUEBridge_GetUpdate(HUE) tmr-PRESENCE_StartLocalScan(Iphone7Plus) tmr-AMAD_checkDeviceState(Android_Tablett_Wohnzimmer)
2019.01.11 02:02:41.582 1: PERL WARNING: Use of uninitialized value $shortarg in concatenation (.) or string at ./FHEM/98_freezemon.pm line 854.
2019.01.11 02:02:41.583 1: stacktrace:
2019.01.11 02:02:41.583 1: main::__ANON__ called by ./FHEM/98_freezemon.pm (854)
2019.01.11 02:02:41.584 1: main::freezemon_apptime called by ./FHEM/98_freezemon.pm (538)
2019.01.11 02:02:41.584 1: main::freezemon_ProcessTimer called by fhem.pl (3153)
2019.01.11 02:02:41.585 1: main::HandleTimeout called by fhem.pl (650)
2019.01.11 02:54:55.382 1: [Freezemon] myFreezemon: possible freeze starting at 02:54:41, delay is 14.379 possibly caused by: tmr-Calendar_Wakeup(AbfallA)
Version ist
98_freezemon.pm 18169 2019-01-07 10:22:00Z KernSani
Guten Morgen,
Du bist aber früh wach ;-) Ich schau mir das heute abend mal an... An der Stelle hab ich seit ewigen Zeiten nichts geändert...
Kurz, weil mobil
Hi Tommy,
ich hab mir die entsprechende Stelle angesehen. Eigentlich sollte es m.E. garnicht möglich sein, dass die Variable an der Stelle undefiniert ist, ich fange es jetzt aber trotzdem ab. Kommt demnächst im Update.
Etwas anderes ist mir aufgefallen (hat nichts direkt mit Freezemon zu tun) :
2019.01.11 02:02:39.500 1: [Freezemon] myFreezemon: possible freeze starting at 02:02:00, delay is 39.499 possibly caused by: tmr-at_Exec(DbLog_aufrauumen)
Ich vermute du rufst hier reduceLog auf - verwendest du noch die alte Variante? Mit der non-blocking Variante reduceLogNbl sollte dir dieser Freeze erspart bleiben...
Grüße,
Oli
Zitat von: KernSani am 11 Januar 2019, 21:23:10
Hi Tommy,
ich hab mir die entsprechende Stelle angesehen. Eigentlich sollte es m.E. garnicht möglich sein, dass die Variable an der Stelle undefiniert ist, ich fange es jetzt aber trotzdem ab. Kommt demnächst im Update.
Etwas anderes ist mir aufgefallen (hat nichts direkt mit Freezemon zu tun) :
2019.01.11 02:02:39.500 1: [Freezemon] myFreezemon: possible freeze starting at 02:02:00, delay is 39.499 possibly caused by: tmr-at_Exec(DbLog_aufrauumen)
Ich vermute du rufst hier reduceLog auf - verwendest du noch die alte Variante? Mit der non-blocking Variante reduceLogNbl sollte dir dieser Freeze erspart bleiben...
Grüße,
Oli
Hi, danke, auch für den Hinweis, ich nutzte zwar kein reduceLog, aber deleteOldDays und das in DbLog_aufrauumen, hab das dann mal auf deleteOldDaysNbl geändert, damit sollte es ja dann besser laufen. Ich hab aber heute z.b. noch mehr solcher meldungen im Log.
2019.01.12 01:30:12.170 1: [Freezemon] myFreezemon: possible freeze starting at 01:30:07, delay is 5.168 possibly caused by: tmr-FBAHAHTTP_Poll(FB6590) tmr-HTTPMOD_GetUpdate(N/A) tmr-HTTPMOD_GetUpdate(N/A)
2019.01.12 01:30:15.123 1: [Freezemon] myFreezemon: possible freeze starting at 01:30:14, delay is 1.121 possibly caused by: tmr-HMLAN_KeepAliveCheck(N/A)
2019.01.12 01:35:09.209 1: [Freezemon] myFreezemon: possible freeze starting at 01:35:08, delay is 1.207 possibly caused by: no bad guy found :-(
2019.01.12 01:40:09.082 1: [Freezemon] myFreezemon: possible freeze starting at 01:40:08, delay is 1.081 possibly caused by: tmr-HttpUtils_Err(N/A)
2019.01.12 05:30:01.124 1: [Freezemon] myFreezemon: possible freeze starting at 05:30:00, delay is 1.122 possibly caused by: tmr-MQTT2_SERVER_keepaliveChecker(MQTT2_FHEM_Server) tmr-MQTT2_SERVER_keepaliveChecker(MQTT2_FHEM_Server) tmr-at_Exec(Weihnachtsdeko_an_am)
2019.01.12 08:30:01.175 1: [Freezemon] myFreezemon: possible freeze starting at 08:30:00, delay is 1.173 possibly caused by: tmr-at_Exec(Weihnachtsdeko_aus_am)
2019.01.12 08:50:10.013 1: [Freezemon] myFreezemon: possible freeze starting at 08:50:09, delay is 1.01 possibly caused by: tmr-PRESENCE_StartLocalScan(GalaxyS8)
2019.01.12 08:54:55.705 1: [Freezemon] myFreezemon: possible freeze starting at 08:54:41, delay is 14.703 possibly caused by: tmr-Calendar_Wakeup(AbfallA)
2019.01.12 09:10:10.089 1: [Freezemon] myFreezemon: possible freeze starting at 09:10:09, delay is 1.086 possibly caused by: no bad guy found :-(
2019.01.12 09:15:39.115 1: [Freezemon] myFreezemon: possible freeze starting at 09:15:38, delay is 1.113 possibly caused by: tmr-MQTT2_SERVER_keepaliveChecker(MQTT2_FHEM_Server)
2019.01.12 10:40:10.093 1: [Freezemon] myFreezemon: possible freeze starting at 10:40:09, delay is 1.091 possibly caused by: tmr-HTTPMOD_GetUpdate(N/A)
2019.01.12 10:45:10.546 1: [Freezemon] myFreezemon: possible freeze starting at 10:45:09, delay is 1.545 possibly caused by: tmr-HTTPMOD_GetUpdate(N/A)
2019.01.12 10:55:10.422 1: [Freezemon] myFreezemon: possible freeze starting at 10:55:09, delay is 1.42 possibly caused by: tmr-HTTPMOD_GetUpdate(N/A)
2019.01.12 10:57:07.169 1: [Freezemon] myFreezemon: possible freeze starting at 10:57:03, delay is 4.167 possibly caused by: tmr-BlinkCamera_PollInfo(Kameras)
Ja, jetzt fängt die Arbeit an...
Im Prinzip musst (solltest) du jetzt die Freezes einzeln durchgehen und analysieren, warum die so lange brauchen. Am besten noch Attribut fm_logFile setzen, dann werden Logs erzeugt, die dir genau zeigen, was in deinem System abläuft.
Bei manchen kann man nichts machen (dann können sie auch auch auf die blacklist gepackt werden), bei anderen kann man häufig was optimieren (z.B. event-on-... Attribute setzen, logging einschränken etc...)
Moin KernSani,
vielen Dank für Dein Modul.
Wie kann ich die Freezes von tmr-HttpUtils_Err(N/A) verhindern?
Vielen Dank.
Grüße Mave
Zitat von: Mave am 13 Januar 2019, 09:04:30
Moin KernSani,
vielen Dank für Dein Modul.
Wie kann ich die Freezes von tmr-HttpUtils_Err(N/A) verhindern?
Vielen Dank.
Grüße Mave
HttpUtils_Err ist meistens nicht der eigentliche Verursacher. Schau mal in die freeze-Logs, ob da ein bestimmtes Midul auffällig ist
Kurz, weil mobil
Zitat von: KernSani am 12 Januar 2019, 21:47:04
Ja, jetzt fängt die Arbeit an...
Im Prinzip musst (solltest) du jetzt die Freezes einzeln durchgehen und analysieren, warum die so lange brauchen. Am besten noch Attribut fm_logFile setzen, dann werden Logs erzeugt, die dir genau zeigen, was in deinem System abläuft.
Bei manchen kann man nichts machen (dann können sie auch auch auf die blacklist gepackt werden), bei anderen kann man häufig was optimieren (z.B. event-on-... Attribute setzen, logging einschränken etc...)
Hi,
ich hab mal das Attribut fm_logFile gesetzt, mal sehen was jetzt passiert:-)
Im anschluss daran hatte ich aber dann diese Meldung im Log
2019.01.13 12:34:05.586 1: PERL WARNING: Use of uninitialized value $path in pattern match (m//) at ./FHEM/98_freezemon.pm line 696.
2019.01.13 12:34:05.587 1: stacktrace:
2019.01.13 12:34:05.587 1: main::__ANON__ called by ./FHEM/98_freezemon.pm (696)
2019.01.13 12:34:05.587 1: main::freezemon_Attr called by fhem.pl (3610)
2019.01.13 12:34:05.588 1: main::CallFn called by fhem.pl (2881)
2019.01.13 12:34:05.588 1: main::CommandAttr called by fhem.pl (1218)
2019.01.13 12:34:05.588 1: main::AnalyzeCommand called by ./FHEM/01_FHEMWEB.pm (2600)
2019.01.13 12:34:05.589 1: main::FW_fC called by ./FHEM/01_FHEMWEB.pm (877)
2019.01.13 12:34:05.589 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (548)
2019.01.13 12:34:05.589 1: main::FW_Read called by fhem.pl (3610)
2019.01.13 12:34:05.589 1: main::CallFn called by fhem.pl (727)
2019.01.13 12:34:05.590 1: PERL WARNING: Use of uninitialized value $path in opendir at ./FHEM/98_freezemon.pm line 697.
2019.01.13 12:34:05.590 1: stacktrace:
2019.01.13 12:34:05.590 1: main::__ANON__ called by ./FHEM/98_freezemon.pm (697)
2019.01.13 12:34:05.591 1: main::freezemon_Attr called by fhem.pl (3610)
2019.01.13 12:34:05.591 1: main::CallFn called by fhem.pl (2881)
2019.01.13 12:34:05.591 1: main::CommandAttr called by fhem.pl (1218)
2019.01.13 12:34:05.591 1: main::AnalyzeCommand called by ./FHEM/01_FHEMWEB.pm (2600)
2019.01.13 12:34:05.592 1: main::FW_fC called by ./FHEM/01_FHEMWEB.pm (877)
2019.01.13 12:34:05.592 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (548)
2019.01.13 12:34:05.592 1: main::FW_Read called by fhem.pl (3610)
2019.01.13 12:34:05.592 1: main::CallFn called by fhem.pl (727)
2019.01.13 12:34:05.593 1: PERL WARNING: Use of uninitialized value $path in concatenation (.) or string at ./FHEM/98_freezemon.pm line 702.
2019.01.13 12:34:05.593 1: stacktrace:
2019.01.13 12:34:05.594 1: main::__ANON__ called by ./FHEM/98_freezemon.pm (702)
2019.01.13 12:34:05.594 1: main::freezemon_Attr called by fhem.pl (3610)
2019.01.13 12:34:05.594 1: main::CallFn called by fhem.pl (2881)
2019.01.13 12:34:05.594 1: main::CommandAttr called by fhem.pl (1218)
2019.01.13 12:34:05.595 1: main::AnalyzeCommand called by ./FHEM/01_FHEMWEB.pm (2600)
2019.01.13 12:34:05.595 1: main::FW_fC called by ./FHEM/01_FHEMWEB.pm (877)
2019.01.13 12:34:05.595 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (548)
2019.01.13 12:34:05.595 1: main::FW_Read called by fhem.pl (3610)
2019.01.13 12:34:05.596 1: main::CallFn called by fhem.pl (727)
Zitat von: KernSani am 13 Januar 2019, 12:09:49
HttpUtils_Err ist meistens nicht der eigentliche Verursacher. Schau mal in die freeze-Logs, ob da ein bestimmtes Midul auffällig ist
Kurz, weil mobil
Okay, schau ich gleich Mal nach.
Kannst Du Dir erklären, wieso ich relativ regelmäßig diese Devices im Log habe: tmr-HUEDevice_GetUpdate
Vielen Dank.
Zitat von: Mave am 13 Januar 2019, 20:47:45
Okay, schau ich gleich Mal nach.
Kannst Du Dir erklären, wieso ich relativ regelmäßig diese Devices im Log habe: tmr-HUEDevice_GetUpdate
Vielen Dank.
Das Device habe ich auch öfters drin
Zitat von: Tommy82 am 13 Januar 2019, 14:33:18
Hi,
ich hab mal das Attribut fm_logFile gesetzt, mal sehen was jetzt passiert:-)
Das Log ist ja releativ schnell recht groß, wie geh ich dann am besten vor?
Zitat von: Tommy82 am 13 Januar 2019, 20:55:09
Das Log ist ja releativ schnell recht groß, wie geh ich dann am besten vor?
mit
attr <device> fm_logFile ./log/freeze-%Y%m%d-%H%M%S.logbekommst du ein Logfile pro Freeze - finde ich persönlich am angenehmsten. Mit fm_logKeep kannst du dann noch sagen wieviele Logfiles es maximal geben soll (freezemon löscht dann die ältesten)
HUEDevice_GetUpdate ist wahrscheinlich so ein Dingens, das im Sekundentakt läuft o.ä. und daher quasi immer als potentieller Verursacher erkannt wird. Am Besten auf fm_whitelistSub setzen (siehe Doku).
Ok versuch ich mal.
Ich habe aber immer noch Perl Warnungen im Log
2019.01.15 06:46:52.352 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at ./FHEM/98_freezemon.pm line 1221.
2019.01.15 06:46:52.353 1: stacktrace:
2019.01.15 06:46:52.353 1: main::__ANON__ called by ./FHEM/98_freezemon.pm (1221)
2019.01.15 06:46:52.354 1: main::freezemon_logLink called by ./FHEM/98_freezemon.pm (427)
2019.01.15 06:46:52.354 1: main::freezemon_ProcessTimer called by fhem.pl (3153)
2019.01.15 06:46:52.354 1: main::HandleTimeout called by fhem.pl (650)
2019.01.15 06:46:56.170 1: PERL WARNING: Use of uninitialized value $shortarg in concatenation (.) or string at ./FHEM/98_freezemon.pm line 854.
2019.01.15 06:46:56.173 1: stacktrace:
2019.01.15 06:46:56.174 1: main::__ANON__ called by ./FHEM/98_freezemon.pm (854)
2019.01.15 06:46:56.175 1: main::freezemon_apptime called by ./FHEM/98_freezemon.pm (538)
2019.01.15 06:46:56.175 1: main::freezemon_ProcessTimer called by fhem.pl (3153)
2019.01.15 06:46:56.176 1: main::HandleTimeout called by fhem.pl (650)
Guten Mirgen,
@Tommy: Die erste Meldung habe ich gestern gefixt, aber noch nicht eingecheckt. Die zweite schaue ich mir heute abend nochmal an.
Kurz, weil mobil
Ich kann die zweite Warnung logisch immernoch nicht nachvollziehen, habe aber nochmal etwas ein bisschen umgebaut (was das Ganze auch einen winzigen Ticken effizienter macht) und gemeinsam mit dem Fix für FW_ME eingecheckt. Morgen im Update verfügbar.
Hi,
super danke.
Jetzt aber mal noch eine grundsätzliche Frage zur Fehler suche.
Hab jetzt heute nacht diese Log meldung von freezemon
=========================================================
[Freezemon] myFreezemon: possible freeze starting at 05:30:00, delay is 1.148 possibly caused by: tmr-at_Exec(Weihnachtsdeko_an_am)
2019.01.16 05:30:00.002 5: exec at command Weihnachtsdeko_an_am
2019.01.16 05:30:00.002 5: Cmd: >set Steckdose_aussen on<
2019.01.16 05:30:00.003 3: Cul433 IT_set: Steckdose_aussen on
2019.01.16 05:30:00.008 4: DbLog myDbLog -> ################################################################
2019.01.16 05:30:00.008 4: DbLog myDbLog -> ### start of new Logcycle ###
2019.01.16 05:30:00.008 4: DbLog myDbLog -> ################################################################
2019.01.16 05:30:00.008 4: DbLog myDbLog -> number of events received: 1 for device: Steckdose_aussen
2019.01.16 05:30:00.009 4: DbLog myDbLog -> check Device: Steckdose_aussen , Event: state: on
2019.01.16 05:30:00.009 5: DbLog myDbLog -> parsed Event: Steckdose_aussen , Event: state: on
2019.01.16 05:30:00.010 4: DbLog myDbLog -> added event - Timestamp: 2019-01-16 05:30:00, Device: Steckdose_aussen, Type: IT, Event: state: on, Reading: state, Value: on, Unit:
2019.01.16 05:30:00.010 4: DbLog myDbLog -> ################################################################
2019.01.16 05:30:00.010 4: DbLog myDbLog -> ### New database processing cycle - synchronous ###
2019.01.16 05:30:00.010 4: DbLog myDbLog -> ################################################################
2019.01.16 05:30:00.010 4: DbLog myDbLog -> DbLogType is: Current/History
2019.01.16 05:30:00.010 4: DbLog myDbLog -> AutoCommit mode: ON, Transaction mode: ON
2019.01.16 05:30:00.020 5: DbLog myDbLog -> Primary Key used in /media/Platte/home/fhem.db.history: none
2019.01.16 05:30:00.021 5: DbLog myDbLog -> Primary Key used in /media/Platte/home/fhem.db.current: none
2019.01.16 05:30:00.021 4: DbLog myDbLog -> processing event Timestamp: 2019-01-16 05:30:00, Device: Steckdose_aussen, Type: IT, Event: state: on, Reading: state, Value: on, Unit:
2019.01.16 05:30:00.024 4: DbLog myDbLog -> 1 of 1 events inserted into table history
2019.01.16 05:30:00.029 4: DbLog myDbLog -> insert table history committed by autocommit
2019.01.16 05:30:00.034 4: DbLog myDbLog -> 1 of 1 events updated in table current
2019.01.16 05:30:00.037 4: DbLog myDbLog -> insert / update table current committed by autocommit
2019.01.16 05:30:00.038 5: DbLog myDbLog -> DbLog_Push Returncode: 0
2019.01.16 05:30:00.040 5: rd_Batterie: not on any display, ignoring notify
2019.01.16 05:30:00.040 5: rd_Batterie_Level: not on any display, ignoring notify
2019.01.16 05:30:00.046 5: End notify loop for Steckdose_aussen
2019.01.16 05:30:00.046 5: Cul433 IT_set: Type=CUL Protocol=V3
2019.01.16 05:30:00.047 5: SW: isr12
2019.01.16 05:30:00.049 5: CUL/RAW (ReadAnswer): 12
2019.01.16 05:30:00.054 4: DbLog myDbLog -> ################################################################
2019.01.16 05:30:00.054 4: DbLog myDbLog -> ### start of new Logcycle ###
2019.01.16 05:30:00.054 4: DbLog myDbLog -> ################################################################
2019.01.16 05:30:00.054 4: DbLog myDbLog -> number of events received: 1 for device: Cul433
2019.01.16 05:30:00.054 4: DbLog myDbLog -> check Device: Cul433 , Event: raw: 12
2019.01.16 05:30:00.055 5: DbLog myDbLog -> parsed Event: Cul433 , Event: raw: 12
2019.01.16 05:30:00.055 4: DbLog myDbLog -> added event - Timestamp: 2019-01-16 05:30:00, Device: Cul433, Type: CUL, Event: raw: 12, Reading: raw, Value: 12, Unit:
2019.01.16 05:30:00.056 4: DbLog myDbLog -> ################################################################
2019.01.16 05:30:00.056 4: DbLog myDbLog -> ### New database processing cycle - synchronous ###
2019.01.16 05:30:00.056 4: DbLog myDbLog -> ################################################################
2019.01.16 05:30:00.056 4: DbLog myDbLog -> DbLogType is: Current/History
2019.01.16 05:30:00.056 4: DbLog myDbLog -> AutoCommit mode: ON, Transaction mode: ON
2019.01.16 05:30:00.066 5: DbLog myDbLog -> Primary Key used in /media/Platte/home/fhem.db.history: none
2019.01.16 05:30:00.066 5: DbLog myDbLog -> Primary Key used in /media/Platte/home/fhem.db.current: none
2019.01.16 05:30:00.066 4: DbLog myDbLog -> processing event Timestamp: 2019-01-16 05:30:00, Device: Cul433, Type: CUL, Event: raw: 12, Reading: raw, Value: 12, Unit:
2019.01.16 05:30:00.069 4: DbLog myDbLog -> 1 of 1 events inserted into table history
2019.01.16 05:30:00.078 4: DbLog myDbLog -> insert table history committed by autocommit
2019.01.16 05:30:00.084 4: DbLog myDbLog -> 1 of 1 events updated in table current
2019.01.16 05:30:00.087 4: DbLog myDbLog -> insert / update table current committed by autocommit
2019.01.16 05:30:00.088 5: DbLog myDbLog -> DbLog_Push Returncode: 0
2019.01.16 05:30:00.090 5: rd_Batterie: not on any display, ignoring notify
2019.01.16 05:30:00.090 5: rd_Batterie_Level: not on any display, ignoring notify
2019.01.16 05:30:00.094 5: End notify loop for Cul433
2019.01.16 05:30:00.094 4: IT set ITrepetition: isr12 for Cul433
2019.01.16 05:30:00.094 5: SW: is00111100110101010110011111010011
2019.01.16 05:30:01.040 5: CUL/RAW (ReadAnswer): is00111100110101010110011111010011
2019.01.16 05:30:01.047 4: DbLog myDbLog -> ################################################################
2019.01.16 05:30:01.048 4: DbLog myDbLog -> ### start of new Logcycle ###
2019.01.16 05:30:01.048 4: DbLog myDbLog -> ################################################################
2019.01.16 05:30:01.048 4: DbLog myDbLog -> number of events received: 1 for device: Cul433
2019.01.16 05:30:01.048 4: DbLog myDbLog -> check Device: Cul433 , Event: raw: is00111100110101010110011111010011
2019.01.16 05:30:01.049 5: DbLog myDbLog -> parsed Event: Cul433 , Event: raw: is00111100110101010110011111010011
2019.01.16 05:30:01.049 4: DbLog myDbLog -> added event - Timestamp: 2019-01-16 05:30:01, Device: Cul433, Type: CUL, Event: raw: is00111100110101010110011111010011, Reading: raw, Value: is00111100110101010110011111010011, Unit:
2019.01.16 05:30:01.050 4: DbLog myDbLog -> ################################################################
2019.01.16 05:30:01.050 4: DbLog myDbLog -> ### New database processing cycle - synchronous ###
2019.01.16 05:30:01.050 4: DbLog myDbLog -> ################################################################
2019.01.16 05:30:01.050 4: DbLog myDbLog -> DbLogType is: Current/History
2019.01.16 05:30:01.050 4: DbLog myDbLog -> AutoCommit mode: ON, Transaction mode: ON
2019.01.16 05:30:01.065 5: DbLog myDbLog -> Primary Key used in /media/Platte/home/fhem.db.history: none
2019.01.16 05:30:01.065 5: DbLog myDbLog -> Primary Key used in /media/Platte/home/fhem.db.current: none
2019.01.16 05:30:01.066 4: DbLog myDbLog -> processing event Timestamp: 2019-01-16 05:30:01, Device: Cul433, Type: CUL, Event: raw: is00111100110101010110011111010011, Reading: raw, Value: is00111100110101010110011111010011, Unit:
2019.01.16 05:30:01.070 4: DbLog myDbLog -> 1 of 1 events inserted into table history
2019.01.16 05:30:01.075 4: DbLog myDbLog -> insert table history committed by autocommit
2019.01.16 05:30:01.081 4: DbLog myDbLog -> 1 of 1 events updated in table current
2019.01.16 05:30:01.084 4: DbLog myDbLog -> insert / update table current committed by autocommit
2019.01.16 05:30:01.084 5: DbLog myDbLog -> DbLog_Push Returncode: 0
2019.01.16 05:30:01.087 5: rd_Batterie: not on any display, ignoring notify
2019.01.16 05:30:01.087 5: rd_Batterie_Level: not on any display, ignoring notify
2019.01.16 05:30:01.090 5: End notify loop for Cul433
2019.01.16 05:30:01.090 5: IT_Set: GetFn(raw): message = is00111100110101010110011111010011 Antwort = raw => is00111100110101010110011111010011
2019.01.16 05:30:01.091 4: ITSet: Answer from Cul433: raw => is00111100110101010110011111010011
2019.01.16 05:30:01.091 5: SW: isr6
2019.01.16 05:30:01.093 5: CUL/RAW (ReadAnswer): 6
2019.01.16 05:30:01.097 4: DbLog myDbLog -> ################################################################
2019.01.16 05:30:01.098 4: DbLog myDbLog -> ### start of new Logcycle ###
2019.01.16 05:30:01.098 4: DbLog myDbLog -> ################################################################
2019.01.16 05:30:01.098 4: DbLog myDbLog -> number of events received: 1 for device: Cul433
2019.01.16 05:30:01.098 4: DbLog myDbLog -> check Device: Cul433 , Event: raw: 6
2019.01.16 05:30:01.098 5: DbLog myDbLog -> parsed Event: Cul433 , Event: raw: 6
2019.01.16 05:30:01.099 4: DbLog myDbLog -> added event - Timestamp: 2019-01-16 05:30:01, Device: Cul433, Type: CUL, Event: raw: 6, Reading: raw, Value: 6, Unit:
2019.01.16 05:30:01.099 4: DbLog myDbLog -> ################################################################
2019.01.16 05:30:01.099 4: DbLog myDbLog -> ### New database processing cycle - synchronous ###
2019.01.16 05:30:01.099 4: DbLog myDbLog -> ################################################################
2019.01.16 05:30:01.099 4: DbLog myDbLog -> DbLogType is: Current/History
2019.01.16 05:30:01.099 4: DbLog myDbLog -> AutoCommit mode: ON, Transaction mode: ON
2019.01.16 05:30:01.110 5: DbLog myDbLog -> Primary Key used in /media/Platte/home/fhem.db.history: none
2019.01.16 05:30:01.110 5: DbLog myDbLog -> Primary Key used in /media/Platte/home/fhem.db.current: none
2019.01.16 05:30:01.110 4: DbLog myDbLog -> processing event Timestamp: 2019-01-16 05:30:01, Device: Cul433, Type: CUL, Event: raw: 6, Reading: raw, Value: 6, Unit:
2019.01.16 05:30:01.115 4: DbLog myDbLog -> 1 of 1 events inserted into table history
2019.01.16 05:30:01.118 4: DbLog myDbLog -> insert table history committed by autocommit
2019.01.16 05:30:01.125 4: DbLog myDbLog -> 1 of 1 events updated in table current
2019.01.16 05:30:01.132 4: DbLog myDbLog -> insert / update table current committed by autocommit
2019.01.16 05:30:01.133 5: DbLog myDbLog -> DbLog_Push Returncode: 0
2019.01.16 05:30:01.138 5: rd_Batterie: not on any display, ignoring notify
2019.01.16 05:30:01.138 5: rd_Batterie_Level: not on any display, ignoring notify
2019.01.16 05:30:01.143 5: End notify loop for Cul433
2019.01.16 05:30:01.143 3: IT set ITrepetition back: isr6 for Cul433
2019.01.16 05:30:01.144 5: Cmd: >sleep 10<
2019.01.16 05:30:01.144 4: sleeping for 10
2019.01.16 05:30:01.145 5: redefine at command Weihnachtsdeko_an_am as *05:30:00 set Steckdose_aussen on; sleep 10;
set Steckdose_Weihnachten_Wohnzimmer on; sleep 10;
set Steckdose_Haustuer on; sleep 10;
set Steckdose_Kueche on
2019.01.16 05:30:01.149 5: [Freezemon] myFreezemon: ----------- Starting Freeze handling at 2019.01.16 05:30:01.149 ---------------------
[Freezemon] myFreezemon: possible freeze starting at 05:30:00, delay is 1.148 possibly caused by: tmr-at_Exec(Weihnachtsdeko_an_am)
Ein at was nachts ausgeführt wird, aber was muss/ kann ich da jetzt machne`?
Internals:
COMMAND set Steckdose_aussen on; sleep 10;
set Steckdose_Weihnachten_Wohnzimmer on; sleep 10;
set Steckdose_Haustuer on; sleep 10;
set Steckdose_Kueche on
DEF *05:30:00 set Steckdose_aussen on; sleep 10;
set Steckdose_Weihnachten_Wohnzimmer on; sleep 10;
set Steckdose_Haustuer on; sleep 10;
set Steckdose_Kueche on
NAME Weihnachtsdeko_an_am
NR 282
PERIODIC yes
RELATIVE no
REP -1
STATE Next: 05:30:00
TIMESPEC 05:30:00
TRIGGERTIME 1547699400
TRIGGERTIME_FMT 2019-01-17 05:30:00
TYPE at
READINGS:
2019-01-16 05:30:01 state Next: 05:30:00
Attributes:
group Info
room Zentral
Hi Tommy,
was ich daraus lerne: Du hast immernoch die Weihnachtsdeko hängen? ;)
Scherz beiseite. Der Freeze ist knapp über eine Sekunde, wenn das nicht all zu häufig auftritt kann man es ignorieren. Was ich aber sehe:
* Du loggst synchron - meistens ist asynchron die bessere Variante
* Du loggst in history und current - ist das notwendig?
* Du loggst deine Steckdose??
* Du loggst auch raw events?
Warum das dann eine Sekunde dauert kann ich dir leider nicht sagen, aber insgesamt gibt es da doch einige Punkte, das logging zu reduzieren und damit die Last ein bisschen zu verringern.
Grüße,
Oli
Zitat von: KernSani am 16 Januar 2019, 21:33:41
Hi Tommy,
was ich daraus lerne: Du hast immernoch die Weihnachtsdeko hängen? ;)
Scherz beiseite. Der Freeze ist knapp über eine Sekunde, wenn das nicht all zu häufig auftritt kann man es ignorieren. Was ich aber sehe:
* Du loggst synchron - meistens ist asynchron die bessere Variante
* Du loggst in history und current - ist das notwendig?
* Du loggst deine Steckdose??
* Du loggst auch raw events?
Warum das dann eine Sekunde dauert kann ich dir leider nicht sagen, aber insgesamt gibt es da doch einige Punkte, das logging zu reduzieren und damit die Last ein bisschen zu verringern.
Grüße,
Oli
Hi Oli,
tjaja irgendwie ende Weihnachten doch nie:-)
Das tritt in diesem fall nur 4x am Tag auf, zumindest solange Weihnachten ist :-) damit könnte ich leben.
Zei deinen anmerkungen zum Log hab ich dann doch ein paar Fragen.
Zitat* Du loggst synchron - meistens ist asynchron die bessere Variante
Ok hab ich verstanden und umgestellt
Zitat* Du loggst in history und current - ist das notwendig?
Was würdest du empfehlen? Nur History?
Zitat* Du loggst deine Steckdose??
Was ist daran falsch?#
Zitat* Du loggst auch raw events?
brauch man wahrscheinlich nicht, allerdings hab ich gerade auch keine richtige Ahnung wie ich das deaktiviere
Ich bin beeindruckt was du alles in so einem kleinen Log siehst:-)
Heute nacht hatte ich nochmal eine Meldung zu freezemon im LOg
2019.01.17 02:04:23.575 1: [Freezemon] myFreezemon: possible freeze starting at 02:03:02, delay is 81.564 possibly caused by: tmr-MQTT2_SERVER_keepaliveChecker(MQTT2_FHEM_Server) tmr-ENIGMA2_GetStatus(VU_Ultimo) tmr-HMLAN_KeepAlive(N/A) tmr-at_Exec(at_fp_time) tmr-ENIGMA2_GetStatus(Uno_Schlafzimmer) tmr-FW_closeInactiveClients(N/A) tmr-BlinkCamera_PollInfo(Kameras) tmr-SYSMON_Update(sysmon) tmr-WOL_UpdateReadings(WHS_2011_ping) tmr-WOL_UpdateReadings(WinServer_ping) tmr-AMAD_checkDeviceState(Android_Tablett_Wohnzimmer) tmr-FBAHAHTTP_Poll(FB6590) tmr-HTTPMOD_GetUpdate(N/A) tmr-HTTPMOD_GetUpdate(N/A) tmr-HUEBridge_GetUpdate(HUE)
2019.01.17 02:04:25.353 1: PERL WARNING: Use of uninitialized value $a[1] in exists at ./FHEM/98_freezemon.pm line 336.
2019.01.17 02:04:25.354 1: stacktrace:
2019.01.17 02:04:25.355 1: main::__ANON__ called by ./FHEM/98_freezemon.pm (336)
2019.01.17 02:04:25.355 1: main::freezemon_ProcessTimer called by fhem.pl (3200)
2019.01.17 02:04:25.356 1: main::HandleTimeout called by fhem.pl (656)
2019.01.17 02:04:25.356 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_freezemon.pm line 346.
2019.01.17 02:04:25.357 1: stacktrace:
2019.01.17 02:04:25.357 1: main::__ANON__ called by ./FHEM/98_freezemon.pm (346)
2019.01.17 02:04:25.357 1: main::freezemon_ProcessTimer called by fhem.pl (3200)
2019.01.17 02:04:25.358 1: main::HandleTimeout called by fhem.pl (656)Danke für deine Hilfe
'n abend,
irgendwie wird das immer länger, daher kurz:
Deine Datenbank scheint nicht die schnellste zu sein (vielleicht weil du zu viel loggst und sie daher groß ist?), daher meine persönliche Meinung, nur die Devices loggen, die du wirklich brauchst (oder erfreust du dich an einem Chart, wann deine Steckdose an war?) und nur die Events loggen, die du brauchst (event-on-change setzen, oder mit DBLogExclude-Attribut). In history loggen reicht i.f.R. (ich glaube nur der Plot-Editor schaut in current).
Das Gute an der Meldung, die du heute im Log hattest: Der letzte Fix hat getan, was er soll. Ich habe aber übersehen, das auch im darauf folgenden Schritt abzufangen. Fix kommt morgen im Update.
Hallo,
Ich bin mal wieder auf der Suche nach den Übeltätern, die die vielen Freezes bei mir verursachen. Dabei kann mir die Idee, dass eine (zuschaltbare?) Statistik nicht schlecht wäre, die die einzelnen möglichen Verursacher zählt: pro "possibly caused by" wird ein reading angelegt, in dem die Häufigkeit gezählt wird. Damit kommt man vielleicht den häufigen Übeltätern leichter auf die Spur? Wäre es möglich und sinnvoll, so etwas einzubauen?
Vielen Dank
Ronny
Gesendet von meinem LYA-L29 mit Tapatalk
Ich habe mir für diesen Zweck ein quick&dirty in VB6 zusammengebastelt. Die Ergebnisse waren nicht sonderlich erhellend...
Details ggf. per PM.
Zitat von: RoBra81 am 19 Januar 2019, 13:58:10
Ich bin mal wieder auf der Suche nach den Übeltätern, die die vielen Freezes bei mir verursachen. Dabei kann mir die Idee, dass eine (zuschaltbare?) Statistik nicht schlecht wäre, die die einzelnen möglichen Verursacher zählt: pro "possibly caused by" wird ein reading angelegt, in dem die Häufigkeit gezählt wird. Damit kommt man vielleicht den häufigen Übeltätern leichter auf die Spur? Wäre es möglich und sinnvoll, so etwas einzubauen?
Die Überlegung hatte ich auch schon mal. Möglich ist das bestimmt, sinnvoll? Weiß ich nicht... Ich persönlich kenne meine Pappenheimer auch so... aber ich schau mal was ich hin bekomme, kann man dann ja evtl. optimieren.
Anbei mal eine Version zum testen. Wenn Attribut fm_statistics auf 1 gesetzt wird, wird für jedes Device "probably causing a freeze" ein Reading angelegt und gezählt, wie oft es möglicherweise an einem Freeze beteiligt ist.
nach /FHEM kopieren und einen shutdown restart machen.
I have frequent freezes with the updated Weather module with Dark Sky integration.
Never had any freeze with the previous Yahoo Weather integration.
1 - 2019-01-19 [Log]: s:08:02:41 e:08:02:42 f:1.217 d:tmr-Weather_GetUpdate(Weather_Ganshoren)
1 - 2019-01-19 [Log]: s:10:02:54 e:10:02:55 f:1.01 d:tmr-Weather_GetUpdate(Weather_Ganshoren)
1 - 2019-01-19 [Log]: s:13:03:14 e:13:03:15 f:1.155 d:no bad guy found :-(
1 - 2019-01-19 [Log]: s:21:04:08 e:21:04:09 f:1.249 d:tmr-Weather_GetUpdate(Weather_Ganshoren)
1 - 2019-01-19 [Log]: s:23:46:42 e:23:46:44 f:2.144 d:cmd-set Weather_Ganshoren update (WEB) fn-SetFn(Weather_Ganshoren) fn-ReadFn(WEB_172.16.3...
1 - 2019-01-20 [Log]: s:00:06:46 e:00:06:47 f:1.553 d:tmr-Weather_GetUpdate(Weather_Ganshoren)
1 - 2019-01-20 [Log]: s:00:56:52 e:00:56:53 f:1.035 d:tmr-Weather_GetUpdate(Weather_Ganshoren)
1 - 2019-01-20 [Log]: s:09:07:47 e:09:07:48 f:1.024 d:tmr-Weather_GetUpdate(Weather_Ganshoren)
It seems that DarkSky API is somewhat slower to respond but it doesn't matter since the HTTP requests should be non-blocking (and DNSServer attribute is also set in Global).
I don't know a lot about Fhem internals but it seems the freeze is happening between the publishing of the Weather state and the end of the notify loop.
The freeze of a second is always here (with fm_logFile enabled):
2019.01.20 09:07:46.941 4: Weather_Ganshoren: T: -4 °C H: 87 % W: 5 km/h P: 1016 hPa
--- log skips 1.083 secs.
2019.01.20 09:07:48.023 5: End notify loop for Weather_Ganshoren
freezemon, such a useful modul. 8)
You better should post your issue in the appropriate subforum, since the developer of DarkSky API will not read this post.
Regards Markus
I posted this already in Weather thread but was redirected here...
https://forum.fhem.de/index.php/topic,95823.msg889675.html#msg889675
Ah, since the author of freezemon gave that advice, it might be an issue with the freezemon_modul....
@SenH: Could you post the complete fm_log of the freeze? I actually don't think it's an issue with the freezemon or the weather module. In my experience this happens if modules update a lot of readings, which trigger a lot of events etc... so setting appropriate "event-on-.*" attributes might help.
@SenH: Could you set the fm_Catch.* attributes in freezemon? Additionally I'd recommend to set the fm_logFile to something like ./log/freeze-%Y%m%d-%H%M%S.log. That way you would get a single logfile per freeze.
They are already set, I will update the fm_logfile.
Attributes:
fm_CatchCmds 1
fm_CatchFnCalls 1
fm_forceApptime 1
fm_logFile ./log/system/freezemon-%Y.log
fm_whitelistSub ModbusLD_GetUpdate,Modbus_ProcessRequestQueue
icon alert-circle
room System->Fhem
Bin gespannt was dabei raus kommt.
Alternativ wird es die Tage ein Update geben wo man die Forecastreadings begrenzen kann.
Andere Baustelle, mit der Bitte um Reaktionen...
Nach der Bereinigung meiner fhem.cfg haben sich meine haufenweise Freezes mittlerweile gemäßigt, ohne aber signifikant abzunehmen. Ich habe ohnehin nur Chancen mich um alles länger als 4 Sekunden zu kümmern. Nach längerer Interpretation bin ich zum Schluss gekommen, dass viele der Alarme Fehlmeldungen sind, weil just in diesem Moment (so etwa zu jeder vollen Stunde) diverse kleine Routinearbeiten abgearbeitet werden und das System damit schlicht am Limit läuft (auf einem 2er Raspi).
Richtig dicke Hunde fabriziere ich aber beim Aufrufen einiger meiner Räume: So dauert der Aufbau der Anzeige meines randvollen "CUL_HM"-Raumes mit gut 100 oder sogar mehr Einträgen inzwischen etwas über 20 Sekunden - und prompt gibt es einen Freeze im Log, eben mal ohne "bad guy", andererseits mit zwei Dutzend möglichen Schuldigen, wobei es sich dabei eigentlich ausschließlich um eben diese routinemäßig sonst unauffälligen Aufgaben handelt. Da bin ich derzeit dabei, die terminlich zu "entballen" durch die Variation der Intervalle in denen sie aufgerufen werden.
Definitiv also ist das Arbeiten an FHEM durch die zähen Aufrufe eine Ursache der Alarme. Nun sollte ich vielleicht daran gehen, die Seiten zu entschlacken. Ein Raum mit diversen Readingsgroups reagiert dabei deutlich flüssiger als eben dieser "CUL_HM" - "Unsorted" geht eigentlich schon gar nicht mehr, da meldet sogar der Browser einen Verbindungsabbruch...
Nun an die Erfahrenen: Was sind in dieser Hinsicht möglicherweise "Performancekiller"
- stateFormats (ich nutze bspw. "[$name:state] ([$name:state:t])" gern um das Alter eines Readings anzuzeigen bei wackliger Kommunikation)
- icon für Geräte/Kanäle
- cmdIcon (zur Aufhübschung der Bedienung)
- ???
also was sind eventuell "Todsünden" des "Designs"?
Mittelfristig braucht's eh einen neuen Rechner - wegen der Einkernigkeit von FHEM vermutlich lieber einen 2,x GHz Dualcore als einen 1,6 GHz Quad ... (?)
Hallo,
ich habe eine ältere FHEM-Version und eben versucht nur dieses eine Modul per Modulupdate einzubinden.
Ein define myFreezemon freezemon führt dann zu Cannot load module freezemon
Im Log steht :
2019.01.20 12:12:53.365 1: reload: Error:Modul 98_freezemon deactivated:
Global symbol "@intAtA" requires explicit package name at ./FHEM/98_freezemon.pm line 306.
BEGIN not safe after errors--compilation aborted at ./FHEM/98_freezemon.pm line 499.
2019.01.20 12:12:53.366 0: Global symbol "@intAtA" requires explicit package name at ./FHEM/98_freezemon.pm line 306.
BEGIN not safe after errors--compilation aborted at ./FHEM/98_freezemon.pm line 499.
Auch wenn das hier wahrscheinlich keiner hören will, ein Komplettupdate von FHEM wage ich derzeit nicht. ::)
Weiss jemand, was den Fehler verursacht und wie man ihn behebt ?
Schöne Grüße
Ralf
Zitat von: KernSani am 20 Januar 2019, 11:22:37
I actually don't think it's an issue with the freezemon or the weather module. In my experience this happens if modules update a lot of readings, which trigger a lot of events etc...
verstehe ich das richtig?:
alleine die existenz einer genügend grossen "flut" von events erzeugt bereits freezes.
Zitat von: rasti am 20 Januar 2019, 12:33:36
Hallo,
ich habe eine ältere FHEM-Version und eben versucht nur dieses eine Modul per Modulupdate einzubinden.
Ein define myFreezemon freezemon führt dann zu Cannot load module freezemon
Im Log steht :
2019.01.20 12:12:53.365 1: reload: Error:Modul 98_freezemon deactivated:
Global symbol "@intAtA" requires explicit package name at ./FHEM/98_freezemon.pm line 306.
BEGIN not safe after errors--compilation aborted at ./FHEM/98_freezemon.pm line 499.
2019.01.20 12:12:53.366 0: Global symbol "@intAtA" requires explicit package name at ./FHEM/98_freezemon.pm line 306.
BEGIN not safe after errors--compilation aborted at ./FHEM/98_freezemon.pm line 499.
Auch wenn das hier wahrscheinlich keiner hören will, ein Komplettupdate von FHEM wage ich derzeit nicht. ::)
Weiss jemand, was den Fehler verursacht und wie man ihn behebt ?
Schöne Grüße
Ralf
intAtA wurde vor fast einem Jahr von Hash auf Array umgestellt. Daher bedarf es einem Update von fhem.pl. Es müssen aber noch andere Module ein Update erhalten. Welche genau weiß ich leider nicht mehr.
Zitat von: CoolTux am 20 Januar 2019, 12:55:26
intAtA wurde vor fast einem Jahr von Hash auf Array umgestellt. Daher bedarf es einem Update von fhem.pl. Es müssen aber noch andere Module ein Update erhalten. Welche genau weiß ich leider nicht mehr.
OK. Das hört sich leider so an, als ob ich in nächster Zukunft auf freezemon verzichten müsste :'(
Zitat von: rasti am 20 Januar 2019, 13:06:49
OK. Das hört sich leider so an, als ob ich in nächster Zukunft auf freezemon verzichten müsste :'(
Du willst also dein ein Jahr altes System nicht updaten?
Nur eine Frage.
Zitat von: CoolTux am 20 Januar 2019, 13:08:35
Du willst also dein ein fast 3 Jahre altes System nicht updaten?
Nur eine Frage.
Genau. Aber bitte deswegen jetzt keine Diskussion lostreten..... ;)
Zitat von: CoolTux am 20 Januar 2019, 12:55:26
intAtA wurde vor fast einem Jahr von Hash auf Array umgestellt. Daher bedarf es einem Update von fhem.pl. Es müssen aber noch andere Module ein Update erhalten. Welche genau weiß ich leider nicht mehr.
Wenn ich mich recht erinnere war nur apptime auch betroffen
Kurz, weil mobil
Zitat von: rasti am 20 Januar 2019, 13:06:49
OK. Das hört sich leider so an, als ob ich in nächster Zukunft auf freezemon verzichten müsste :'(
Im SVN müsste es noch die Version von vor der Umstellung geben. Habe aber keine Ahnung, was da an anderen Problemen auftreten kann...
Kurz, weil mobil
Zitat von: frank am 20 Januar 2019, 12:47:07
verstehe ich das richtig?:
alleine die existenz einer genügend grossen "flut" von events erzeugt bereits freezes.
nach meiner bescheidenen Sicht ja, aber indirekt. Events wollen abgearbeitet werden, und jedes Event wirft die globale Notifyschleife erneut an. Kommen diese Events entsprechend so häufig, dass dazwischen kein Platz mehr für anderes bleibt, gibt es Freezes.
Ein besonders erfolgreicher Punkt meiner Aufräumung war tatsächlich die umfassende Einführung von detaillierten "event-on-change-reading". Seither tröpfelt es nur noch im EventMonitor, sehr übersichtlich ...
Zitat von: frank am 20 Januar 2019, 12:47:07
verstehe ich das richtig?:
alleine die existenz einer genügend grossen "flut" von events erzeugt bereits freezes.
Keine Freezes im eigentlichen Sinne, FHEM ist dann nur so mit der Abarbeitung der Events beschäftigt, vor allem wenn z.B. wahllos geloggt wird, dass andere Commands nicht mehr drankommen (das ist eine empirische Beobachtung, keine technisch validierte Aussage)
Kurz, weil mobil
Zitat von: rasti am 20 Januar 2019, 13:12:16
Genau. Aber bitte deswegen jetzt keine Diskussion lostreten..... ;)
Ich würde niemals über sowas diskutieren. Muss es nur wissen damit ich nicht umsonst meine kostbare Zeit bei Deinen Problemen verschwende. Von daher danke für Deine Ehrlichkeit und Dein Verständnis.
Zitat von: KernSani am 20 Januar 2019, 13:17:13
Im SVN müsste es noch die Version von vor der Umstellung geben. Habe aber keine Ahnung, was da an anderen Problemen auftreten kann...
Das wäre ein Hoffnungsfunke.
In https://svn.fhem.de/trac/log/trunk/fhem/FHEM/98_freezemon.pm habe ich @16276 genommen.
Das führt aber beim Einbinden zu:
Global symbol "%prioQueues" requires explicit package name at ./FHEM/98_freezemon.pm line 571.
Global symbol "%prioQueues" requires explicit package name at ./FHEM/98_freezemon.pm line 573.
Global symbol "%prioQueues" requires explicit package name at ./FHEM/98_freezemon.pm line 574.
Zitat von: rasti am 20 Januar 2019, 13:39:13
Das wäre ein Hoffnungsfunke.
In https://svn.fhem.de/trac/log/trunk/fhem/FHEM/98_freezemon.pm habe ich @16276 genommen.
Das führt aber beim Einbinden zu:
Global symbol "%prioQueues" requires explicit package name at ./FHEM/98_freezemon.pm line 571.
Global symbol "%prioQueues" requires explicit package name at ./FHEM/98_freezemon.pm line 573.
Global symbol "%prioQueues" requires explicit package name at ./FHEM/98_freezemon.pm line 574.
Ohje... die Prioqueues sind noch älter.... Vielleicht probierst du es mit PERFMON, damit entdeckst du Freezes, aber ohne viel zusätzliche Info zum Verursacher...
Kurz, weil mobil
Zitatund jedes Event wirft die globale Notifyschleife erneut an.
Ich hatte kürzlich einen Fall, der dem etwas widerspricht. Nicht die events alleine sind das Problem, sondern nur dann, wenn ein notify matched und (Spekulation) der auszuführende Teil etwas träge ist.
In meinem fast freezefreien System hatte ich plötzlich permanente freezes. Zeitlich leicht für mich zu identifizieren, weil meinem simplen Drahtüberschwemmungssensor ein paar Wassertropfen zu nah gekommen waren. Bedeutet dann permanente events und Alarmierung über Alarmanlagenmodul(notify) mit Sprachausgabe auf dem Dot. (performance von FHEWEB war übelst). Im Rpi-GPIO-Modul gibt es aber leider weder inactive, noch disable, um die event-Flut abzuschalten. Nachdem ich das notify inactive gesetzt hatte war Schluss mit freezes(FHEMWEB blieb träge).
Grüße Markus
@SenH: I don't know how well you understand German - basically the discussion above was about what happens if a lot of events are fired, Conclusion: if a lot of events are fired (because a lot of readings are updated), FHEM is busy processing all these events, which might cause a freeze. This can be avoided by setting the event-on-.* attributes, so you only get the events you're really interested in (i.e. which are needed to trigger notifies etc... or should be logged).
Zitat von: KernSani am 20 Januar 2019, 01:02:53
Anbei mal eine Version zum testen. Wenn Attribut fm_statistics auf 1 gesetzt wird, wird für jedes Device "probably causing a freeze" ein Reading angelegt und gezählt, wie oft es möglicherweise an einem Freeze beteiligt ist.
Hatte sich das eigentlich jemand angesehen? Nachdem das Ding bei mir jetzt knapp 24h gelaufen ist, dachte ich, könnte man noch ein bisschen optimieren:
* es gibt ein set freezemon clear statistics
* Devices wie WEB_123.123.12.3_56789 werden jetzt in ein reading fc_WEB zusammengefasst
* Leere Devices werden rausgefiltert
Wenn kein großer Protest kommt, würde ich das wahrscheinlich morgen im SVN einchecken...
Zitat von: KernSani am 20 Januar 2019, 17:38:28
@SenH: I don't know how well you understand German - basically the discussion above was about what happens if a lot of events are fired, Conclusion: if a lot of events are fired (because a lot of readings are updated), FHEM is busy processing all these events, which might cause a freeze. This can be avoided by setting the event-on-.* attributes, so you only get the events you're really interested in (i.e. which are needed to trigger notifies etc... or should be logged).
Thanks for the explanation KernSani. Changing
event-on-change-reading from
.* to
state in the
Weather module cleared all freezes. I'm only logging the state so this should make sense. It's also logical that the freezes happened at the beginning of the hour since all the hourly forecasts are then updated and this generates a lot of events.
Frage zu der fm_whitelistSub, wenn ich so eine Meldung im Log habe 2019.01.22 05:30:01.012 1: [Freezemon] myFreezemon: possible freeze starting at 05:30:00, delay is 1.01 possibly caused by: tmr-HMLAN_KeepAlive(N/A) tmr-at_Exec(Weihnachtsdeko_an_am) was muss in die Whitelist wenn ich diese zukünftig nicht mehr haben möchte, da ich die für unkritisch halte?
Danke
Zitat von: Tommy82 am 22 Januar 2019, 06:03:52
Frage zu der fm_whitelistSub, wenn ich so eine Meldung im Log habe 2019.01.22 05:30:01.012 1: [Freezemon] myFreezemon: possible freeze starting at 05:30:00, delay is 1.01 possibly caused by: tmr-HMLAN_KeepAlive(N/A) tmr-at_Exec(Weihnachtsdeko_an_am) was muss in die Whitelist wenn ich diese zukünftig nicht mehr haben möchte, da ich die für unkritisch halte?
Danke
Nur für den Fall das es untergegangen ist:-)
Zitat von: Tommy82 am 24 Januar 2019, 20:22:16
Nur für den Fall das es untergegangen ist:-)
nicht untergegangen - ich habe mich nur in den letzten Tagen mit zigbee2mqtt beschäftigt und das war dann doch mehr Aufwand als erwartet ;)
Ganz kurz:
1. FHEM hat intern einen Hash, der alle anstehenden Timer enthält. Freezemon greift sich diese Timer um potentielle Verursacher von Freezes zu identifizieren. Funktionen, die nicht als Verursacher in Frage kommen (wie z.B. der HMLAN_KeepAlive, der eigentlich immer da ist) kann man an dieser Stelle bereits über das whitelist-Attribut ausschließen. D.h. diese Funktion wird nie als Verursacher aufgelistet, wenn es zum Freeze kommt, wird dieser aber geloggt (ggf. mit "no bad guy".
2. Wenn es zum Freeze kommt werden die potentiellen Verursacher gegen die ignore-Attribute geprüft und je nach Einstellung wird der Freeze dann möglicherweise ignoriert (also nicht geloggt). Das würde sich für die Weihnachtsdeko anbieten.
Grüße,
Oli
Hi,
ja das hatte ich auch so verstanden, aber was muss ich in die Whitelist jetzt eintragen?
Wenn ich
Weihnachtsdeko_an_am eintrage, taucht das trotzdem weiter im Log auf
Die Weihnachtsdeko muss ins ignoreDev (siehe Pkt. 2 oben)
Kurz, weil mobil
Mal eine generelle Frage: Wie hättet Ihr es hier gern: Probleme mit dem Freezemon selbst hier und für Hilfestellung zu Freezes einen eigenen Thread in "Sonstiges" aufmachen oder auch hier?
Also irgendwie hab ich glaub ich immer noch eine "Denk blockade" ???
Ich habe fm_ignoreDev
Weihnachtsdeko_an_am, VU_Ultimo, MQTT2_FHEM_Server, Kameras, HUE
trotzdem habe ich im Fhem Log diese Meldungen
2019.01.30 08:34:04.339 1: [Freezemon] myFreezemon: possible freeze starting at 08:33:56, delay is 8.323 possibly caused by: tmr-Calendar_Wakeup(AbfallA) tmr-MQTT2_SERVER_keepaliveChecker(MQTT2_FHEM_Server)
2019.01.30 10:34:35.009 1: [Freezemon] myFreezemon: possible freeze starting at 10:34:32, delay is 3.005 possibly caused by: tmr-BlinkCamera_PollInfo(Kameras)
Auf was steht denn ignoreMode?
Kurz, weil mobil
Das Attribute habe ich garnicht gesetzt, also sollte es auf "All" stehen!?
Hi Tommy,
default-Wert für ignoreDev ist "all", d.h. alle "möglichen Verursacher" eines Freezes müssen in der ignoreDev stehen (das ist im ersten Beispiel nicht der Fall). Im zweiten Fall sieht es so aus als müsste der Freeze eigentlich ignoriert werden - ich fürchte aber, das Leerzeichen nach dem Komma ist Schuld, dass dem nicht so ist... Nimm das bitte mal raus. Ich baue mal noch ein "trim" ins Modul ein.
Grüße,
Oli
Zitat von: Pfriemler am 30 Januar 2019, 10:45:24
Mal eine generelle Frage: Wie hättet Ihr es hier gern: Probleme mit dem Freezemon selbst hier und für Hilfestellung zu Freezes einen eigenen Thread in "Sonstiges" aufmachen oder auch hier?
Hier sollten meiner Meinung nach Probleme mit dem Modul an sich diskutiert werden. Hilfestellung zu Freezes (Identifizieren der Verursacher etc...) bitte in separaten Threads
Zitat von: KernSani am 30 Januar 2019, 23:56:44
Hi Tommy,
default-Wert für ignoreDev ist "all", d.h. alle "möglichen Verursacher" eines Freezes müssen in der ignoreDev stehen (das ist im ersten Beispiel nicht der Fall). Im zweiten Fall sieht es so aus als müsste der Freeze eigentlich ignoriert werden - ich fürchte aber, das Leerzeichen nach dem Komma ist Schuld, dass dem nicht so ist... Nimm das bitte mal raus. Ich baue mal noch ein "trim" ins Modul ein.
Grüße,
Oli
Hi,
ich habe mal ein update gemacht und auch die Leerstellen entfernt, aber trotzdem noch diese Meldungen im Log
2019.02.03 03:18:32.665 1: [Freezemon] myFreezemon: possible freeze starting at 03:18:31, delay is 1.662 possibly caused by: tmr-BlinkCamera_PollInfo(Kameras) tmr-MQTT2_SERVER_keepaliveChecker(MQTT2_FHEM_Server) Wenn meine definition in freezemon richtig ist, dürften die doch nicht mehr aufschlagen!?
Internals:
FUUID 5c48d22e-f33f-f412-186b-0107db6ad27425fa
NAME myFreezemon
NR 388
NTFY_ORDER 99-myFreezemon
STATE s:12:17:48 e:12:17:50 f:2.578 d:no bad guy found :-(
TYPE freezemon
VERSION 0.0.26
Helper:
DBLOG:
fcDay:
myDbLog:
TIME 1549192670.59004
VALUE 5
fcDayLast:
myDbLog:
TIME 1549148403.01087
VALUE 7
freezeDevice:
myDbLog:
TIME 1549192670.59004
VALUE no bad guy found :-(
freezeTime:
myDbLog:
TIME 1549192670.59004
VALUE 2.578
ftDay:
myDbLog:
TIME 1549192670.59004
VALUE 14.231
ftDayLast:
myDbLog:
TIME 1549148403.01087
VALUE 22.837
state:
myDbLog:
TIME 1549192670.59004
VALUE s:12:17:48 e:12:17:50 f:2.578 d:no bad guy found :-(
READINGS:
2019-02-03 12:17:50 fcDay 5
2019-02-03 00:00:03 fcDayLast 7
2019-02-03 12:17:50 freezeDevice no bad guy found :-(
2019-02-03 12:17:50 freezeTime 2.578
2019-02-03 12:17:50 ftDay 14.231
2019-02-03 00:00:03 ftDayLast 22.837
2019-02-03 12:17:50 state s:12:17:48 e:12:17:50 f:2.578 d:no bad guy found :-(
helper:
DISABLED 0
TIMER 1549192692
apptime
fn
freeze 2.57811594009399
intCount 56
msg [Freezemon] myFreezemon: possible freeze starting at 12:17:48, delay is 2.578 possibly caused by: no bad guy found :-(
now 1549192670.57812
inAt:
HASH(0x5977600)
HASH(0x55ad5f0)
HASH(0x4d7eaa0)
HASH(0x567bd98)
HASH(0x56c3ec0)
HASH(0x5606428)
HASH(0x55a6408)
HASH(0x54fb3d0)
HASH(0x5686860)
HASH(0x565c678)
HASH(0x5502e30)
HASH(0x5664530)
HASH(0x5a2f238)
HASH(0x58594d0)
HASH(0x56c5e80)
HASH(0x5848018)
HASH(0x5843150)
HASH(0x5850a48)
HASH(0x5675958)
HASH(0x561a270)
HASH(0x5508718)
HASH(0x547a400)
HASH(0x4e406f0)
HASH(0x5703c08)
HASH(0x59b86e8)
HASH(0x55185b0)
HASH(0x58b82a8)
HASH(0x55001f0)
HASH(0x552a268)
HASH(0x55c9f58)
HASH(0x552ef08)
HASH(0x54a85a0)
HASH(0x55651b8)
HASH(0x550c0d8)
HASH(0x55027e8)
HASH(0x5501508)
HASH(0x5560f10)
HASH(0x555e620)
HASH(0x563b5d8)
HASH(0x585d2e8)
HASH(0x55d95b0)
HASH(0x5713530)
HASH(0x570d240)
HASH(0x56563c0)
HASH(0x55170a0)
HASH(0x56c2808)
HASH(0x568cf50)
HASH(0x5849878)
logfilequeue:
logqueue:
ARRAY(0x5849e30)
ARRAY(0x5740070)
ARRAY(0x573c748)
ARRAY(0x5854050)
ARRAY(0x5652a10)
ARRAY(0x546e650)
ARRAY(0x584eeb8)
ARRAY(0x556d690)
Attributes:
fm_ignoreDev Weihnachtsdeko_an_am,VU_Ultimo,MQTT2_FHEM_Server,Kameras,HUE,AbfallA,LED_Leiste_Bett_AutoAus
fm_ignoreMode off
fm_logFile /tmp/freeze-%Y%m%d-%H%M%S.log
fm_logKeep 10
group Info
room Zentral
Zitat von: Tommy82 am 03 Februar 2019, 12:18:28
Wenn meine definition in freezemon richtig ist, dürften die doch nicht mehr aufschlagen!?
da gebe ich dir vollkommen recht... komisch... Kannst du mal das zugehörige Log posten? Da müssten dann eigentlich auch ein paar verbose 5 Meldungen vom Freezemon kommen, die etwas Licht ins dunkel bringen könnten.
Hi,
hier der log
Zitat von: Tommy82 am 03 Februar 2019, 19:56:11
Hi,
hier der log
Thanks... leider steht nicht drin, was ich mir erhofft hatte... Kann ich dir zumuten freezemon auf verbose 5 zu stellen, bis der Freeze kommt (oder kannst du den Freeze provozieren)
Grüße,
Oli
Ich wüsste grade nicht wie ich den provozieren soll, ich stell verbose 5 ein, und da es bis jetzt jede Nacht aufgetreten ist, geh ich davon aus das ich dir morgen früh etwas schicken kann.
Cool. Danke. Ich hoffe das wird nicht zu viel Müll, der da geloggt wird...
Kurz, weil mobil
Morgen,
das hab ich dann heute morgen mit verbose 5 im Log
2019.02.04 02:43:52.488 3: ABFALL myAbfall - CALENDAR:AbfallA triggered, updating ABFALL myAbfall ...
2019.02.04 02:43:59.243 5: [Freezemon] myFreezemon: ----------- Starting Freeze handling at 2019.02.04 02:43:59.243 ---------------------
2019.02.04 02:43:59.250 1: [Freezemon] myFreezemon: possible freeze starting at 02:43:53, delay is 6.242 possibly caused by: tmr-Calendar_Wakeup(AbfallA) tmr-MQTT2_SERVER_keepaliveChecker(MQTT2_FHEM_Server)
2019.02.04 02:43:59.310 5: [Freezemon] myFreezemon: ----------- Ending Freeze handling at 2019.02.04 02:43:59.309 after 0.066887 --------
2019.02.04 02:44:03.029 5: [Freezemon] myFreezemon: Blocking Call started with PID 1002
2019.02.04 02:44:03.084 4: [Freezemon] myFreezemon: dumping 2181 log entries to /tmp/freeze-20190204-024359.log
2019.02.04 02:44:03.430 5: [Freezemon] myFreezemon: Blocking Call with PID 1002 ended
2019.02.04 02:44:33.004 4: [Freezemon] myFreezemon: Deleting freeze-20190203-120700.log
und im Anhang der freezelog
Zitat von: Tommy82 am 04 Februar 2019, 05:20:48
Morgen,
das hab ich dann heute morgen mit verbose 5 im Log
irgendwie ignoriert der das ignoreDev total, bei dir... Ich muss das irgendwie bei mir nachstellen... könnte ein bisschen dauern...
Korrigiere mich... das hätte ich schon vorher sehen müssen... Laut deinem "list" oben hast du ignoreMode auf "off" stehen... Dann ignoriert er nix...
Jetzt wo du es sagst, ja so ist es, hab es jetzt mal auf single gestellt, dann müsste doch jedes einzelne Device welches in der fm_ignoreDev steht ignoriert werden!?
Korrekt. Oder um es präzise zu formulieren: Bei "single" wird der Freeze ignoriert, wenn mindestens eines der Freeze-verursachenden Devices in ignoreDev steht
moin,
ich habe gerade bemerkt, dass die freeze zähler für heute und gestern falsch zählen.
fcDay zeigt einen freeze zu wenig an. (verglichen mit heutigem tages-log und der ansicht "get freeze")
fcDayLast zeigt einen freeze zu viel an. (verglichen mit gestrigem tages-log)
die summe ist demnach korrekt.
eventuell liegt es am zeitpunkt des ersten freezes für heute, da dieser sehr "früh" stattgefunden hat.
[Freezemon] myFreezemon: possible freeze starting at 00:00:06, delay is 1.111 possibly caused by: tmr-UWZ_Start(Unwetterzentrale)
edit:
das nachrechnen der zeitsummen ergibt jeweils eine differenz von 1,111sek. demnach wird der 1. freeze von heute falsch "einsortiert".
gruss frank
Zitat von: frank am 07 Februar 2019, 13:27:54
eventuell liegt es am zeitpunkt des ersten freezes für heute, da dieser sehr "früh" stattgefunden hat.
[Freezemon] myFreezemon: possible freeze starting at 00:00:06, delay is 1.111 possibly caused by: tmr-UWZ_Start(Unwetterzentrale)
Das ist korrekt... Freezemon macht ja (je nach Einstellung) jede Sekunde etwas (nach Freezes zu schauen). Um die Last zu verringern, werden aber weniger wichtige Dinge (wie z.B. zu schauen, ob ein neuer Tag ist, Logs löschen etc...) nur jede Minute gemacht... Ich könnte das relativ einfach ändern (auf Kosten der Systemlast) wenn es wichtig ist...
ZitatIch könnte das relativ einfach ändern (auf Kosten der Systemlast) wenn es wichtig ist...
nein, danke.
mir würde ein hinweis in der commandref genügen, zb bei der beschreibung der readings.
Zitat von: frank am 07 Februar 2019, 14:25:20
mir würde ein hinweis in der commandref genügen, zb bei der beschreibung der readings.
eingecheckt.
merci. :)
Hi,
ich hatte heute plötzlich nochmal einen Fehler im Log
2019.02.07 11:43:49.489 1: PERL WARNING: Use of uninitialized value $devname in exists at ./FHEM/98_freezemon.pm line 326.
2019.02.07 11:43:49.490 1: stacktrace:
2019.02.07 11:43:49.490 1: main::__ANON__ called by ./FHEM/98_freezemon.pm (326)
2019.02.07 11:43:49.491 1: main::freezemon_ProcessTimer called by fhem.pl (3227)
2019.02.07 11:43:49.491 1: main::HandleTimeout called by fhem.pl (660)
2019.02.07 11:43:49.492 1: PERL WARNING: Use of uninitialized value $devname in concatenation (.) or string at ./FHEM/98_freezemon.pm line 336.
2019.02.07 11:43:49.492 1: stacktrace:
2019.02.07 11:43:49.492 1: main::__ANON__ called by ./FHEM/98_freezemon.pm (336)
2019.02.07 11:43:49.493 1: main::freezemon_ProcessTimer called by fhem.pl (3227)
2019.02.07 11:43:49.493 1: main::HandleTimeout called by fhem.pl (660)
Fix ist eingecheckt und mit dem morgigen Update verfügbar... Du hast irgendwie komische Devices ;) Falls Du Lust hast, ich habe mal eine Version angehängt, die ein paar hässliche Dumps ins Log schreibt, wenn sowas auftritt. Würde mir helfen, die Erkennungsrate zu verbessern...
Zitat von: KernSani am 07 Februar 2019, 23:09:48
Fix ist eingecheckt und mit dem morgigen Update verfügbar... Du hast irgendwie komische Devices ;) Falls Du Lust hast, ich habe mal eine Version angehängt, die ein paar hässliche Dumps ins Log schreibt, wenn sowas auftritt. Würde mir helfen, die Erkennungsrate zu verbessern...
Hi,
Komischer Typ, komische Devices :-)
Werd deinen Anhang mal testen
Hi,
hab dann heute diese Meldung im Log
2019.02.09 07:40:35.903 3: [Freezemon] myFreezemon found something that's not a HASH HTTPMOD_GetUpdate $VAR1 = 'update:TV_Programme';
2019.02.09 07:40:35.905 3: [Freezemon] myFreezemon found something that's not a HASH HTTPMOD_GetUpdate $VAR1 = 'update:TV_Programme_abend';
Zitat von: Tommy82 am 09 Februar 2019, 20:04:15
Hi,
hab dann heute diese Meldung im Log
2019.02.09 07:40:35.903 3: [Freezemon] myFreezemon found something that's not a HASH HTTPMOD_GetUpdate $VAR1 = 'update:TV_Programme';
2019.02.09 07:40:35.905 3: [Freezemon] myFreezemon found something that's not a HASH HTTPMOD_GetUpdate $VAR1 = 'update:TV_Programme_abend';
Das ist ja schonmal was... Hast du auch einen zugehörigen Freeze?
Leider Nein,
im Log steht nichts weiter und einen freeze Log dazu gibt es dazu nicht/nicht mehr.
Hab heute dann die Meldung
2019.02.10 09:58:58.350 3: [Freezemon] myFreezemon found something that's not a HASH HMLAN_KeepAliveCheck $VAR1 = 'keepAliveCk:hmusb';
2019.02.10 09:58:58.351 1: [Freezemon] myFreezemon: possible freeze starting at 09:58:57, delay is 1.347 possibly caused by: tmr-HMLAN_KeepAliveCheck(N/A)
Dazu gibt es auch einen Log
Heute dann noch ein anderer
2019.02.12 02:16:14.164 3: [Freezemon] myFreezemon found something that's not a HASH CUL_HM_ActCheck $VAR1 = 'ActionDetector';
Auch dazu gibt es keinen Log
Hi,
heute Morgen habe ich folgendes im Log
2019.02.15 01:16:04.469 1: PERL WARNING: Use of uninitialized value $devname in exists at ./FHEM/98_freezemon.pm line 326.
2019.02.15 01:16:04.470 1: stacktrace:
2019.02.15 01:16:04.470 1: main::__ANON__ called by ./FHEM/98_freezemon.pm (326)
2019.02.15 01:16:04.470 1: main::freezemon_ProcessTimer called by fhem.pl (3232)
2019.02.15 01:16:04.471 1: main::HandleTimeout called by fhem.pl (665)
2019.02.15 01:16:04.471 1: PERL WARNING: Use of uninitialized value $devname in concatenation (.) or string at ./FHEM/98_freezemon.pm line 336.
2019.02.15 01:16:04.472 1: stacktrace:
2019.02.15 01:16:04.472 1: main::__ANON__ called by ./FHEM/98_freezemon.pm (336)
2019.02.15 01:16:04.472 1: main::freezemon_ProcessTimer called by fhem.pl (3232)
2019.02.15 01:16:04.473 1: main::HandleTimeout called by fhem.pl (665)
2019.02.15 01:16:04.474 1: [Freezemon] myFreezemon: possible freeze starting at 01:16:01, delay is 3.467 possibly caused by: tmr-BlinkCamera_RetryDo() tmr-at_Exec(at_fp_time)
Moin ich habe eine Fhem Instanz mit freezemon. Mir schmiert leider manchmal mein mapleCUN ab. Leider tötet dabei freezemon meinen laufenden Fhem-Prozess
Undefined subroutine &main::Dumper called at ./FHEM/98_freezemon.pm line 1072.
Gruß
Maui
wenn ich mir Oli's Sourcecode angucke, scheint er da etwas übersehen zu haben.
Wenn Du Data::Dumper installiert hast, kannst Du einfach in Zeile 105 das Kommentarzeichen entfernen.
Danke für den Tipp. Hab freezemon jetzt erstmal runter geschmissen.
Brauche ich eh nicht so dringend.
Gruß
I have following error in log upon: get freezemon statistic
2019.11.07 18:43:23 1: PERL WARNING: Use of uninitialized value $i in numeric gt (>) at ./FHEM/98_freezemon.pm line 742.
Simple fix:
--- - 2019-11-08 10:13:12.000000000 +0100
+++ FHEM/98_freezemon.pm 2019-11-08 10:13:12.000000000 +0100
@@ -737,7 +737,7 @@
sort { $stats{$b}{cnt} <=> $stats{$a}{cnt} or $stats{$b}{time} <=> $stats{$a}{time} } keys %stats;
my $ret = "<html>";
$ret .= "<table><tr><th>Device</th><th>Count</th><th>Time</th></tr>";
- my $i;
+ my $i = 0;
foreach my $p (@positioned) {
last if $i > 20;
$i++;
Hi,
ich habe seit einem der letzten Updates den Log voll mit:
2019.11.26 00:01:24.208 1: [Freezemon] myFreezemon: possible freeze starting at 00:01:23, delay is 1.198 possibly caused by: no bad guy found :-(
alle irgendwo um 1.1 sekunden rum. gibts irgendeine möglichkeit rauszufinden was das verursacht?
Danke
Hi,
ich hab heute folgende Meldung im Log:
2019.11.28 17:05:55.912 1: PERL WARNING: Use of uninitialized value $devname in exists at ./FHEM/98_freezemon.pm line 331.
2019.11.28 17:05:55.913 1: stacktrace:
2019.11.28 17:05:55.913 1: main::__ANON__ called by ./FHEM/98_freezemon.pm (331)
2019.11.28 17:05:55.914 1: main::freezemon_ProcessTimer called by fhem.pl (3297)
2019.11.28 17:05:55.914 1: main::HandleTimeout called by fhem.pl (677)
2019.11.28 17:05:55.915 1: PERL WARNING: Use of uninitialized value $devname in concatenation (.) or string at ./FHEM/98_freezemon.pm line 341.
2019.11.28 17:05:55.915 1: stacktrace:
2019.11.28 17:05:55.915 1: main::__ANON__ called by ./FHEM/98_freezemon.pm (341)
2019.11.28 17:05:55.916 1: main::freezemon_ProcessTimer called by fhem.pl (3297)
2019.11.28 17:05:55.916 1: main::HandleTimeout called by fhem.pl (677)
Hi,
ich habe heute plötzlich diese Meldungen im Log:
2020.01.06 14:30:21.934 1: PERL WARNING: Use of uninitialized value $devname in exists at ./FHEM/98_freezemon.pm line 333.
2020.01.06 14:30:21.935 1: stacktrace:
2020.01.06 14:30:21.936 1: main::__ANON__ called by ./FHEM/98_freezemon.pm (333)
2020.01.06 14:30:21.936 1: main::freezemon_ProcessTimer called by fhem.pl (3306)
2020.01.06 14:30:21.937 1: main::HandleTimeout called by fhem.pl (679)
2020.01.06 14:30:21.937 1: PERL WARNING: Use of uninitialized value $devname in concatenation (.) or string at ./FHEM/98_freezemon.pm line 343.
2020.01.06 14:30:21.938 1: stacktrace:
2020.01.06 14:30:21.938 1: main::__ANON__ called by ./FHEM/98_freezemon.pm (343)
2020.01.06 14:30:21.938 1: main::freezemon_ProcessTimer called by fhem.pl (3306)
2020.01.06 14:30:21.938 1: main::HandleTimeout called by fhem.pl (679)
Fhem ist aktuell,letztes Update gestern
Hmmm... Das tut nicht weh, sollte aber eigentlich nicht passieren... Muss ich mir im Detail anschauen, eigentlich müsste $devname immer existieren...
Update: Habe den Schurken gefunden... Kommt morgen mit dem Update. (Ist übrigens der gleiche, wie der im November gemeldete...) Hat sich das "bad guy" Problem oben gelöst?
Moin KernSani,
Hast dir das thema aus dem Juni Mal angeschaut?
Mit dumper
Wer wars denn?:-)
Es gibt immer mal wieder bad guys...
2020.01.07 05:58:59.363 1: [Freezemon] myFreezemon: possible freeze starting at 05:58:57, delay is 2.341 possibly caused by: no bad guy found :-(
Hab aber auch noch so eine seltsame Meldung im Log
2020.01.07 06:03:18.744 0: [Freezemon] myFreezemon: Unwrapping CallFn
2020.01.07 06:03:18.744 0: [Freezemon] myFreezemon: Unwrapping AnalyzeCommand
2020.01.07 06:03:18.745 0: [Freezemon] myFreezemon: Unwrapping Log3
2020.01.07 14:02:59.258 1: [Freezemon] myFreezemon: possible freeze starting at 14:02:55, delay is 4.255 possibly caused by: tmr-CUL_HM_procQs(N/A)
Zitat von: Tommy82 am 07 Januar 2020, 20:26:27
Wer wars denn?:-)
Eine übersehene Zuweisung in einem endlosen IF/ELSIF-Baum
Zitat
Es gibt immer mal wieder bad guys...
2020.01.07 05:58:59.363 1: [Freezemon] myFreezemon: possible freeze starting at 05:58:57, delay is 2.341 possibly caused by: no bad guy found :-(
Bei den Bad guys hilft es sich das Freezemon-Log anzusehen, was da passiert. Wenn zusätzlich noch catchCmds und CatchFn gesetzt sind können die weitere Hinweise geben.
Zitat
Hab aber auch noch so eine seltsame Meldung im Log
2020.01.07 06:03:18.744 0: [Freezemon] myFreezemon: Unwrapping CallFn
2020.01.07 06:03:18.744 0: [Freezemon] myFreezemon: Unwrapping AnalyzeCommand
2020.01.07 06:03:18.745 0: [Freezemon] myFreezemon: Unwrapping Log3
Das sieht aus, als würdest du den Freezemon auf inaktiv bzw. disabled setzen (dann werden von freezemon überschriebene subs wieder in ihren Originalzustand versetzt)
Zitat2020.01.07 14:02:59.258 1: [Freezemon] myFreezemon: possible freeze starting at 14:02:55, delay is 4.255 possibly caused by: tmr-CUL_HM_procQs(N/A)
Da hätte ich prinzipiell mal den Verdacht, dass es sich eigentlich um einen "bad guy" handelt. Ich weiß nicht so genau, was der CUL da macht, aber gefühlt ist er nicht der wahre Verursacher (es gilt das was ich zu den bad guys oben schon gesagt habe).
Zitat von: Maui am 07 Januar 2020, 08:31:24
Moin KernSani,
Hast dir das thema aus dem Juni Mal angeschaut?
Mit dumper
Ja, das habe ich gefixt (am 20.12. - also im letzten Jahrzehnt :D)
Zitat von: KernSani am 07 Januar 2020, 21:11:43
Ja, das habe ich gefixt (am 20.12. - also im letzten Jahrzehnt :D)
Okay danke. Good to know ;)
Ich hab im Log grade mal wieder einen bad guy
2020.01.10 20:59:07.408 1: [Freezemon] myFreezemon: possible freeze starting at 20:59:06, delay is 1.404 possibly caused by: no bad guy found :-(, dazu steht dann im freezmon log folgendes:
Freezemon] myFreezemon: possible freeze starting at 20:59:06, delay is 1.404 possibly caused by: no bad guy found :-(
2020.01.10 20:59:05.294 4: https://layla.amazon.de/api/np/player?deviceSerialNumber=90F00718642405VR&deviceType=AB72C64C86AW2&screenWidth=1392&_=1578686344: HTTP response code 200
2020.01.10 20:59:06.058 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc5_precipIntensityMaxTime: Di, 14 Jan 2020 11:14, Reading: fc5_precipIntensityMaxTime, Value: Di, 14 Jan 2020 11:14, Unit:
2020.01.10 20:59:06.058 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc5_precipProbability: 33
2020.01.10 20:59:06.059 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc5_precipProbability: 33
2020.01.10 20:59:06.059 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc5_precipProbability: 33, Reading: fc5_precipProbability, Value: 33, Unit:
2020.01.10 20:59:06.059 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc5_wind_speed: 20
2020.01.10 20:59:06.060 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc5_wind_speed: 20
2020.01.10 20:59:06.060 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc5_wind_speed: 20, Reading: fc5_wind_speed, Value: 20, Unit:
2020.01.10 20:59:06.061 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc5_apparentTempHigh: 5
2020.01.10 20:59:06.061 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc5_apparentTempHigh: 5
2020.01.10 20:59:06.061 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc5_apparentTempHigh: 5, Reading: fc5_apparentTempHigh, Value: 5, Unit:
2020.01.10 20:59:06.062 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc5_tempHigh: 8
2020.01.10 20:59:06.062 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc5_tempHigh: 8
2020.01.10 20:59:06.062 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc5_tempHigh: 8, Reading: fc5_tempHigh, Value: 8, Unit:
2020.01.10 20:59:06.063 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc5_ozone: 335.3
2020.01.10 20:59:06.063 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc5_ozone: 335.3
2020.01.10 20:59:06.064 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc5_ozone: 335.3, Reading: fc5_ozone, Value: 335.3, Unit:
2020.01.10 20:59:06.064 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc5_windGustTime: Di, 14 Jan 2020 19:25
2020.01.10 20:59:06.065 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc5_windGustTime: Di, 14 Jan 2020 19:25
2020.01.10 20:59:06.065 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc5_windGustTime: Di, 14 Jan 2020 19:25, Reading: fc5_windGustTime, Value: Di, 14 Jan 2020 19:25, Unit:
2020.01.10 20:59:06.066 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc5_tempLowTime: Mi, 15 Jan 2020 04:04
2020.01.10 20:59:06.066 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc5_tempLowTime: Mi, 15 Jan 2020 04:04
2020.01.10 20:59:06.066 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc5_tempLowTime: Mi, 15 Jan 2020 04:04, Reading: fc5_tempLowTime, Value: Mi, 15 Jan 2020 04:04, Unit:
2020.01.10 20:59:06.067 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc5_wind_condition: Wind: SSW 20 km/h
2020.01.10 20:59:06.067 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc5_wind_condition: Wind: SSW 20 km/h
2020.01.10 20:59:06.067 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc5_wind_condition: Wind: SSW 20 km/h, Reading: fc5_wind_condition, Value: Wind, Unit: SSW 20 km/h
2020.01.10 20:59:06.068 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc6_windGustTime: Mi, 15 Jan 2020 00:29
2020.01.10 20:59:06.068 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc6_windGustTime: Mi, 15 Jan 2020 00:29
2020.01.10 20:59:06.068 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc6_windGustTime: Mi, 15 Jan 2020 00:29, Reading: fc6_windGustTime, Value: Mi, 15 Jan 2020 00:29, Unit:
2020.01.10 20:59:06.069 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc6_tempLowTime: Do, 16 Jan 2020 07:49
2020.01.10 20:59:06.069 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc6_tempLowTime: Do, 16 Jan 2020 07:49
2020.01.10 20:59:06.070 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc6_tempLowTime: Do, 16 Jan 2020 07:49, Reading: fc6_tempLowTime, Value: Do, 16 Jan 2020 07:49, Unit:
2020.01.10 20:59:06.070 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc6_ozone: 333.5
2020.01.10 20:59:06.070 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc6_ozone: 333.5
2020.01.10 20:59:06.071 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc6_ozone: 333.5, Reading: fc6_ozone, Value: 333.5, Unit:
2020.01.10 20:59:06.071 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc6_precipProbability: 28
2020.01.10 20:59:06.072 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc6_precipProbability: 28
2020.01.10 20:59:06.072 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc6_precipProbability: 28, Reading: fc6_precipProbability, Value: 28, Unit:
2020.01.10 20:59:06.072 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc6_wind_speed: 17
2020.01.10 20:59:06.073 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc6_wind_speed: 17
2020.01.10 20:59:06.073 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc6_wind_speed: 17, Reading: fc6_wind_speed, Value: 17, Unit:
2020.01.10 20:59:06.074 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc6_apparentTempHigh: 5
2020.01.10 20:59:06.074 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc6_apparentTempHigh: 5
2020.01.10 20:59:06.074 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc6_apparentTempHigh: 5, Reading: fc6_apparentTempHigh, Value: 5, Unit:
2020.01.10 20:59:06.075 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc6_precipIntensity: 0.0935
2020.01.10 20:59:06.075 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc6_precipIntensity: 0.0935
2020.01.10 20:59:06.076 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc6_precipIntensity: 0.0935, Reading: fc6_precipIntensity, Value: 0.0935, Unit:
2020.01.10 20:59:06.076 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc6_uvIndexTime: Mi, 15 Jan 2020 12:39
2020.01.10 20:59:06.077 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc6_uvIndexTime: Mi, 15 Jan 2020 12:39
2020.01.10 20:59:06.077 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc6_uvIndexTime: Mi, 15 Jan 2020 12:39, Reading: fc6_uvIndexTime, Value: Mi, 15 Jan 2020 12:39, Unit:
2020.01.10 20:59:06.077 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc6_precipIntensityMaxTime: Mi, 15 Jan 2020 19:28
2020.01.10 20:59:06.078 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc6_precipIntensityMaxTime: Mi, 15 Jan 2020 19:28
2020.01.10 20:59:06.078 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc6_precipIntensityMaxTime: Mi, 15 Jan 2020 19:28, Reading: fc6_precipIntensityMaxTime, Value: Mi, 15 Jan 2020 19:28, Unit:
2020.01.10 20:59:06.079 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc6_apparentTempLow: 1
2020.01.10 20:59:06.079 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc6_apparentTempLow: 1
2020.01.10 20:59:06.079 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc6_apparentTempLow: 1, Reading: fc6_apparentTempLow, Value: 1, Unit:
2020.01.10 20:59:06.080 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc6_apparentTempHighTime: Mi, 15 Jan 2020 16:24
2020.01.10 20:59:06.080 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc6_apparentTempHighTime: Mi, 15 Jan 2020 16:24
2020.01.10 20:59:06.080 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc6_apparentTempHighTime: Mi, 15 Jan 2020 16:24, Reading: fc6_apparentTempHighTime, Value: Mi, 15 Jan 2020 16:24, Unit:
2020.01.10 20:59:06.081 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc6_tempHighTime: Mi, 15 Jan 2020 07:59
2020.01.10 20:59:06.081 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc6_tempHighTime: Mi, 15 Jan 2020 07:59
2020.01.10 20:59:06.082 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc6_tempHighTime: Mi, 15 Jan 2020 07:59, Reading: fc6_tempHighTime, Value: Mi, 15 Jan 2020 07:59, Unit:
2020.01.10 20:59:06.082 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc6_precipIntensityMax: 0.4126
2020.01.10 20:59:06.082 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc6_precipIntensityMax: 0.4126
2020.01.10 20:59:06.083 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc6_precipIntensityMax: 0.4126, Reading: fc6_precipIntensityMax, Value: 0.4126, Unit:
2020.01.10 20:59:06.083 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc6_cloudCover: 81
2020.01.10 20:59:06.084 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc6_cloudCover: 81
2020.01.10 20:59:06.084 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc6_cloudCover: 81, Reading: fc6_cloudCover, Value: 81, Unit:
2020.01.10 20:59:06.085 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc6_apparentTempLowTime: Do, 16 Jan 2020 06:04
2020.01.10 20:59:06.085 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc6_apparentTempLowTime: Do, 16 Jan 2020 06:04
2020.01.10 20:59:06.085 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc6_apparentTempLowTime: Do, 16 Jan 2020 06:04, Reading: fc6_apparentTempLowTime, Value: Do, 16 Jan 2020 06:04, Unit:
2020.01.10 20:59:06.086 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc6_windGust: 61
2020.01.10 20:59:06.086 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc6_windGust: 61
2020.01.10 20:59:06.086 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc6_windGust: 61, Reading: fc6_windGust, Value: 61, Unit:
2020.01.10 20:59:06.087 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc6_wind_direction: 211
2020.01.10 20:59:06.087 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc6_wind_direction: 211
2020.01.10 20:59:06.087 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc6_wind_direction: 211, Reading: fc6_wind_direction, Value: 211, Unit:
2020.01.10 20:59:06.088 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc6_tempLow: 3
2020.01.10 20:59:06.088 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc6_tempLow: 3
2020.01.10 20:59:06.089 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc6_tempLow: 3, Reading: fc6_tempLow, Value: 3, Unit:
2020.01.10 20:59:06.089 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc6_wind: 17
2020.01.10 20:59:06.090 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc6_wind: 17
2020.01.10 20:59:06.090 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc6_wind: 17, Reading: fc6_wind, Value: 17, Unit:
2020.01.10 20:59:06.090 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc6_low_c: 3
2020.01.10 20:59:06.091 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc6_low_c: 3
2020.01.10 20:59:06.091 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc6_low_c: 3, Reading: fc6_low_c, Value: 3, Unit:
2020.01.10 20:59:06.091 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc6_humidity: 83
2020.01.10 20:59:06.092 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc6_humidity: 83
2020.01.10 20:59:06.092 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc6_humidity: 83, Reading: fc6_humidity, Value: 83, Unit:
2020.01.10 20:59:06.093 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc6_wind_condition: Wind: SSW 17 km/h
2020.01.10 20:59:06.093 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc6_wind_condition: Wind: SSW 17 km/h
2020.01.10 20:59:06.093 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc6_wind_condition: Wind: SSW 17 km/h, Reading: fc6_wind_condition, Value: Wind, Unit: SSW 17 km/h
2020.01.10 20:59:06.094 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_code: 32
2020.01.10 20:59:06.094 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_code: 32
2020.01.10 20:59:06.095 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_code: 32, Reading: fc7_code, Value: 32, Unit:
2020.01.10 20:59:06.095 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_windGustTime: Do, 16 Jan 2020 16:53
2020.01.10 20:59:06.095 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_windGustTime: Do, 16 Jan 2020 16:53
2020.01.10 20:59:06.096 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_windGustTime: Do, 16 Jan 2020 16:53, Reading: fc7_windGustTime, Value: Do, 16 Jan 2020 16:53, Unit:
2020.01.10 20:59:06.096 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_tempLowTime: Fr, 17 Jan 2020 05:57
2020.01.10 20:59:06.097 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_tempLowTime: Fr, 17 Jan 2020 05:57
2020.01.10 20:59:06.097 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_tempLowTime: Fr, 17 Jan 2020 05:57, Reading: fc7_tempLowTime, Value: Fr, 17 Jan 2020 05:57, Unit:
2020.01.10 20:59:06.098 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_precipProbability: 13
2020.01.10 20:59:06.098 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_precipProbability: 13
2020.01.10 20:59:06.098 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_precipProbability: 13, Reading: fc7_precipProbability, Value: 13, Unit:
2020.01.10 20:59:06.099 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_wind_speed: 9
2020.01.10 20:59:06.099 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_wind_speed: 9
2020.01.10 20:59:06.099 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_wind_speed: 9, Reading: fc7_wind_speed, Value: 9, Unit:
2020.01.10 20:59:06.100 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_condition: Den ganzen Tag lang Klar.
2020.01.10 20:59:06.100 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_condition: Den ganzen Tag lang Klar.
2020.01.10 20:59:06.101 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_condition: Den ganzen Tag lang Klar., Reading: fc7_condition, Value: Den ganzen Tag lang Klar., Unit:
2020.01.10 20:59:06.101 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_apparentTempHigh: 4
2020.01.10 20:59:06.101 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_apparentTempHigh: 4
2020.01.10 20:59:06.102 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_apparentTempHigh: 4, Reading: fc7_apparentTempHigh, Value: 4, Unit:
2020.01.10 20:59:06.102 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_dewPoint: 2
2020.01.10 20:59:06.103 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_dewPoint: 2
2020.01.10 20:59:06.103 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_dewPoint: 2, Reading: fc7_dewPoint, Value: 2, Unit:
2020.01.10 20:59:06.103 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_tempHigh: 7
2020.01.10 20:59:06.104 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_tempHigh: 7
2020.01.10 20:59:06.104 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_tempHigh: 7, Reading: fc7_tempHigh, Value: 7, Unit:
2020.01.10 20:59:06.105 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_ozone: 336.1
2020.01.10 20:59:06.105 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_ozone: 336.1
2020.01.10 20:59:06.105 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_ozone: 336.1, Reading: fc7_ozone, Value: 336.1, Unit:
2020.01.10 20:59:06.106 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_apparentTempHighTime: Do, 16 Jan 2020 16:21
2020.01.10 20:59:06.106 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_apparentTempHighTime: Do, 16 Jan 2020 16:21
2020.01.10 20:59:06.106 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_apparentTempHighTime: Do, 16 Jan 2020 16:21, Reading: fc7_apparentTempHighTime, Value: Do, 16 Jan 2020 16:21, Unit:
2020.01.10 20:59:06.107 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_tempHighTime: Do, 16 Jan 2020 14:14
2020.01.10 20:59:06.107 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_tempHighTime: Do, 16 Jan 2020 14:14
2020.01.10 20:59:06.107 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_tempHighTime: Do, 16 Jan 2020 14:14, Reading: fc7_tempHighTime, Value: Do, 16 Jan 2020 14:14, Unit:
2020.01.10 20:59:06.108 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_precipIntensityMax: 0.0351
2020.01.10 20:59:06.108 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_precipIntensityMax: 0.0351
2020.01.10 20:59:06.109 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_precipIntensityMax: 0.0351, Reading: fc7_precipIntensityMax, Value: 0.0351, Unit:
2020.01.10 20:59:06.109 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_iconAPI: clear-day
2020.01.10 20:59:06.110 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_iconAPI: clear-day
2020.01.10 20:59:06.110 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_iconAPI: clear-day, Reading: fc7_iconAPI, Value: clear-day, Unit:
2020.01.10 20:59:06.110 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_apparentTempLow: 3
2020.01.10 20:59:06.111 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_apparentTempLow: 3
2020.01.10 20:59:06.111 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_apparentTempLow: 3, Reading: fc7_apparentTempLow, Value: 3, Unit:
2020.01.10 20:59:06.111 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_precipIntensity: 0.0014
2020.01.10 20:59:06.112 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_precipIntensity: 0.0014
2020.01.10 20:59:06.112 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_precipIntensity: 0.0014, Reading: fc7_precipIntensity, Value: 0.0014, Unit:
2020.01.10 20:59:06.113 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_uvIndexTime: Do, 16 Jan 2020 12:39
2020.01.10 20:59:06.113 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_uvIndexTime: Do, 16 Jan 2020 12:39
2020.01.10 20:59:06.113 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_uvIndexTime: Do, 16 Jan 2020 12:39, Reading: fc7_uvIndexTime, Value: Do, 16 Jan 2020 12:39, Unit:
2020.01.10 20:59:06.114 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_pressure: 1024
2020.01.10 20:59:06.114 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_pressure: 1024
2020.01.10 20:59:06.115 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_pressure: 1024, Reading: fc7_pressure, Value: 1024, Unit:
2020.01.10 20:59:06.115 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_precipIntensityMaxTime: Do, 16 Jan 2020 00:00
2020.01.10 20:59:06.115 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_precipIntensityMaxTime: Do, 16 Jan 2020 00:00
2020.01.10 20:59:06.116 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_precipIntensityMaxTime: Do, 16 Jan 2020 00:00, Reading: fc7_precipIntensityMaxTime, Value: Do, 16 Jan 2020 00:00, Unit:
2020.01.10 20:59:06.116 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_low_c: 5
2020.01.10 20:59:06.117 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_low_c: 5
2020.01.10 20:59:06.117 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_low_c: 5, Reading: fc7_low_c, Value: 5, Unit:
2020.01.10 20:59:06.118 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_humidity: 84
2020.01.10 20:59:06.118 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_humidity: 84
2020.01.10 20:59:06.118 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_humidity: 84, Reading: fc7_humidity, Value: 84, Unit:
2020.01.10 20:59:06.119 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_high_c: 7
2020.01.10 20:59:06.119 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_high_c: 7
2020.01.10 20:59:06.119 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_high_c: 7, Reading: fc7_high_c, Value: 7, Unit:
2020.01.10 20:59:06.120 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_windGust: 41
2020.01.10 20:59:06.120 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_windGust: 41
2020.01.10 20:59:06.121 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_windGust: 41, Reading: fc7_windGust, Value: 41, Unit:
2020.01.10 20:59:06.121 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_tempLow: 5
2020.01.10 20:59:06.121 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_tempLow: 5
2020.01.10 20:59:06.122 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_tempLow: 5, Reading: fc7_tempLow, Value: 5, Unit:
2020.01.10 20:59:06.122 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_wind_direction: 165
2020.01.10 20:59:06.123 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_wind_direction: 165
2020.01.10 20:59:06.123 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_wind_direction: 165, Reading: fc7_wind_direction, Value: 165, Unit:
2020.01.10 20:59:06.123 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_wind: 9
2020.01.10 20:59:06.124 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_wind: 9
2020.01.10 20:59:06.124 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_wind: 9, Reading: fc7_wind, Value: 9, Unit:
2020.01.10 20:59:06.125 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_cloudCover: 32
2020.01.10 20:59:06.125 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_cloudCover: 32
2020.01.10 20:59:06.125 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_cloudCover: 32, Reading: fc7_cloudCover, Value: 32, Unit:
2020.01.10 20:59:06.126 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_apparentTempLowTime: Fr, 17 Jan 2020 06:07
2020.01.10 20:59:06.126 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_apparentTempLowTime: Fr, 17 Jan 2020 06:07
2020.01.10 20:59:06.126 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_apparentTempLowTime: Fr, 17 Jan 2020 06:07, Reading: fc7_apparentTempLowTime, Value: Fr, 17 Jan 2020 06:07, Unit:
2020.01.10 20:59:06.127 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_icon: sunny
2020.01.10 20:59:06.127 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_icon: sunny
2020.01.10 20:59:06.128 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_icon: sunny, Reading: fc7_icon, Value: sunny, Unit:
2020.01.10 20:59:06.128 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc7_wind_condition: Wind: SSO 9 km/h
2020.01.10 20:59:06.129 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc7_wind_condition: Wind: SSO 9 km/h
2020.01.10 20:59:06.129 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc7_wind_condition: Wind: SSO 9 km/h, Reading: fc7_wind_condition, Value: Wind, Unit: SSO 9 km/h
2020.01.10 20:59:06.130 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_tempHigh: 7
2020.01.10 20:59:06.130 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_tempHigh: 7
2020.01.10 20:59:06.130 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_tempHigh: 7, Reading: fc8_tempHigh, Value: 7, Unit:
2020.01.10 20:59:06.131 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_ozone: 346.6
2020.01.10 20:59:06.131 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_ozone: 346.6
2020.01.10 20:59:06.132 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_ozone: 346.6, Reading: fc8_ozone, Value: 346.6, Unit:
2020.01.10 20:59:06.132 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_condition: Leichter Regen am Nachmittag und Abend.
2020.01.10 20:59:06.133 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_condition: Leichter Regen am Nachmittag und Abend.
2020.01.10 20:59:06.133 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_condition: Leichter Regen am Nachmittag und Abend., Reading: fc8_condition, Value: Leichter Regen am Nachmittag und Abend., Unit:
2020.01.10 20:59:06.134 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_precipProbability: 81
2020.01.10 20:59:06.134 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_precipProbability: 81
2020.01.10 20:59:06.134 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_precipProbability: 81, Reading: fc8_precipProbability, Value: 81, Unit:
2020.01.10 20:59:06.135 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_wind_speed: 12
2020.01.10 20:59:06.135 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_wind_speed: 12
2020.01.10 20:59:06.135 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_wind_speed: 12, Reading: fc8_wind_speed, Value: 12, Unit:
2020.01.10 20:59:06.136 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_apparentTempHigh: 4
2020.01.10 20:59:06.136 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_apparentTempHigh: 4
2020.01.10 20:59:06.137 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_apparentTempHigh: 4, Reading: fc8_apparentTempHigh, Value: 4, Unit:
2020.01.10 20:59:06.137 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_dewPoint: 3
2020.01.10 20:59:06.137 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_dewPoint: 3
2020.01.10 20:59:06.138 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_dewPoint: 3, Reading: fc8_dewPoint, Value: 3, Unit:
2020.01.10 20:59:06.138 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_visibility: 16
2020.01.10 20:59:06.139 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_visibility: 16
2020.01.10 20:59:06.139 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_visibility: 16, Reading: fc8_visibility, Value: 16, Unit:
2020.01.10 20:59:06.139 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_windGustTime: Fr, 17 Jan 2020 22:15
2020.01.10 20:59:06.140 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_windGustTime: Fr, 17 Jan 2020 22:15
2020.01.10 20:59:06.140 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_windGustTime: Fr, 17 Jan 2020 22:15, Reading: fc8_windGustTime, Value: Fr, 17 Jan 2020 22:15, Unit:
2020.01.10 20:59:06.141 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_wind_direction: 192
2020.01.10 20:59:06.141 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_wind_direction: 192
2020.01.10 20:59:06.141 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_wind_direction: 192, Reading: fc8_wind_direction, Value: 192, Unit:
2020.01.10 20:59:06.142 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_windGust: 29
2020.01.10 20:59:06.142 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_windGust: 29
2020.01.10 20:59:06.142 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_windGust: 29, Reading: fc8_windGust, Value: 29, Unit:
2020.01.10 20:59:06.143 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_tempLow: 3
2020.01.10 20:59:06.143 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_tempLow: 3
2020.01.10 20:59:06.143 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_tempLow: 3, Reading: fc8_tempLow, Value: 3, Unit:
2020.01.10 20:59:06.144 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_high_c: 7
2020.01.10 20:59:06.144 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_high_c: 7
2020.01.10 20:59:06.145 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_high_c: 7, Reading: fc8_high_c, Value: 7, Unit:
2020.01.10 20:59:06.145 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_wind: 12
2020.01.10 20:59:06.146 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_wind: 12
2020.01.10 20:59:06.146 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_wind: 12, Reading: fc8_wind, Value: 12, Unit:
2020.01.10 20:59:06.147 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_cloudCover: 78
2020.01.10 20:59:06.147 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_cloudCover: 78
2020.01.10 20:59:06.147 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_cloudCover: 78, Reading: fc8_cloudCover, Value: 78, Unit:
2020.01.10 20:59:06.148 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_low_c: 3
2020.01.10 20:59:06.148 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_low_c: 3
2020.01.10 20:59:06.148 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_low_c: 3, Reading: fc8_low_c, Value: 3, Unit:
2020.01.10 20:59:06.149 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_humidity: 84
2020.01.10 20:59:06.149 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_humidity: 84
2020.01.10 20:59:06.149 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_humidity: 84, Reading: fc8_humidity, Value: 84, Unit:
2020.01.10 20:59:06.150 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_apparentTempLow: 2
2020.01.10 20:59:06.150 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_apparentTempLow: 2
2020.01.10 20:59:06.151 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_apparentTempLow: 2, Reading: fc8_apparentTempLow, Value: 2, Unit:
2020.01.10 20:59:06.151 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_uvIndexTime: Fr, 17 Jan 2020 12:39
2020.01.10 20:59:06.151 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_uvIndexTime: Fr, 17 Jan 2020 12:39
2020.01.10 20:59:06.152 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_uvIndexTime: Fr, 17 Jan 2020 12:39, Reading: fc8_uvIndexTime, Value: Fr, 17 Jan 2020 12:39, Unit:
2020.01.10 20:59:06.152 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_precipIntensity: 0.1235
2020.01.10 20:59:06.153 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_precipIntensity: 0.1235
2020.01.10 20:59:06.153 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_precipIntensity: 0.1235, Reading: fc8_precipIntensity, Value: 0.1235, Unit:
2020.01.10 20:59:06.153 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_precipIntensityMaxTime: Fr, 17 Jan 2020 16:02
2020.01.10 20:59:06.154 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_precipIntensityMaxTime: Fr, 17 Jan 2020 16:02
2020.01.10 20:59:06.154 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_precipIntensityMaxTime: Fr, 17 Jan 2020 16:02, Reading: fc8_precipIntensityMaxTime, Value: Fr, 17 Jan 2020 16:02, Unit:
2020.01.10 20:59:06.155 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_pressure: 1021
2020.01.10 20:59:06.155 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_pressure: 1021
2020.01.10 20:59:06.155 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_pressure: 1021, Reading: fc8_pressure, Value: 1021, Unit:
2020.01.10 20:59:06.156 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_tempHighTime: Fr, 17 Jan 2020 16:27
2020.01.10 20:59:06.156 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_tempHighTime: Fr, 17 Jan 2020 16:27
2020.01.10 20:59:06.156 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_tempHighTime: Fr, 17 Jan 2020 16:27, Reading: fc8_tempHighTime, Value: Fr, 17 Jan 2020 16:27, Unit:
2020.01.10 20:59:06.157 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_apparentTempHighTime: Fr, 17 Jan 2020 16:54
2020.01.10 20:59:06.157 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_apparentTempHighTime: Fr, 17 Jan 2020 16:54
2020.01.10 20:59:06.158 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_apparentTempHighTime: Fr, 17 Jan 2020 16:54, Reading: fc8_apparentTempHighTime, Value: Fr, 17 Jan 2020 16:54, Unit:
2020.01.10 20:59:06.158 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_precipIntensityMax: 0.8924
2020.01.10 20:59:06.158 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_precipIntensityMax: 0.8924
2020.01.10 20:59:06.159 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_precipIntensityMax: 0.8924, Reading: fc8_precipIntensityMax, Value: 0.8924, Unit:
2020.01.10 20:59:06.159 4: DbLog myDbLog -> check Device: YahooWetter , Event: fc8_wind_condition: Wind: SSW 12 km/h
2020.01.10 20:59:06.160 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: fc8_wind_condition: Wind: SSW 12 km/h
2020.01.10 20:59:06.160 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: fc8_wind_condition: Wind: SSW 12 km/h, Reading: fc8_wind_condition, Value: Wind, Unit: SSW 12 km/h
2020.01.10 20:59:06.160 4: DbLog myDbLog -> check Device: YahooWetter , Event: state: T: 4 °C F: 95 % W: 12 km/h P: 1028 hPa
2020.01.10 20:59:06.161 5: DbLog myDbLog -> parsed Event: YahooWetter , Event: state: T: 4 °C F: 95 % W: 12 km/h P: 1028 hPa
2020.01.10 20:59:06.161 4: DbLog myDbLog -> added event - Timestamp: 2020-01-10 20:59:05, Device: YahooWetter, Type: WEATHER, Event: state: T: 4 °C F: 95 % W: 12 km/h P: 1028 hPa, Reading: state, Value: T: 4 °C F: 95 % W: 12 km/h P: 1028 hPa, Unit:
--- log skips 1.242 secs.
2020.01.10 20:59:07.403 5: End notify loop for YahooWetter
2020.01.10 20:59:07.404 4: Weather YahooWetter: Rearm new Timer
2020.01.10 20:59:07.405 5: [Freezemon] myFreezemon: ----------- Starting Freeze handling at 2020.01.10 20:59:07.404 ---------------------
[Freezemon] myFreezemon: possible freeze starting at 20:59:06, delay is 1.404 possibly caused by: no bad guy found :-(
Ich musste einige Zeile aus dem freezmon Log löschen, da ich ansonsten den Beitrag hier nicht verfassen konnte
Was ist
catchCmds und CatchFn
und wo kann ich das setzen?
Hi Tommy,
Zitat von: Tommy82 am 10 Januar 2020, 21:15:52
Was ist
catchCmds und CatchFn
und wo kann ich das setzen?
1. du solltest event-on-change-reading bei YahooWetter auf die readings setzen, die dich wirklich interessieren.
2. es gibt im Freezemon Modul die Attribute fm_CatchFnCalls und fm_CatchCmds, wenn du diese auf einen Wert >= 1 setzt, werden zusätzliche (möglicherweise redundante) Informationen gesammelt, schau dir mal die Commandref dazu an, oder setze sie einfach auf "3".
Hi,
ich hab die beiden Attribute mal aktiviert und habe jetzt im Log z.b. diese Meldung:
2020.01.14 05:11:56.329 3: [Freezemon] myFreezemon: Long function call detected ReadFn:WEBtablet_192.168.188.55_56030 - 2.410978 seconds
2020.01.14 05:11:56.334 1: [Freezemon] myFreezemon: possible freeze starting at 05:11:54, delay is 2.33 possibly caused by: fn-ReadFn(WEBtablet_192.168.188.55_56030) tmr-echodevice_GetSettings(Echos) tmr-KODI_Check(Kodi)
2020.01.14 03:37:55.375 3: [Freezemon] myFreezemon: Long running Command detected {FRITZBOX_Readout_Done('FritzBox6590|ZmhlbS0+c2lkfGUyMzY5MTg5NDg4ZWY2Y2F8ZmhlbS0+c2lkVGltZXwxNTc4OTY5NDc0LjYzNDUyfGRlY3QxfFdvaG56aW1tZXJ8ZGVjdDFfaW50ZXJufDYxMXxkZWN0MV9hbGFybVJpbmdUb25lfHxkZWN0MV9pbnRSaW5nVG9uZXxIYW5kc2V0RGVmYXVsdHxkZWN0MV9yYWRpb3xEZXV0c2NobGFuZGZ1bmt8ZGVjdDFfY3VzdFJpbmdUb25lfGZpbGU6Ly8vdmFyL0ludGVybmVyU3BlaWNoZXIvRlJJVFovZm9ucmluZy8xNTQ0OTAxNjkzLmc3MjJ8ZGVjdDFfY3VzdFJpbmdUb25lTmFtZXxXZWlobmFjaHRlbnxkZWN0MV9pbWFnZVBhdGh8L3Zhci9JbnRlcm5lclNwZWljaGVyL0ZSSVRaL2ZvbnBpeC8xNTQ0OTAyMDcyLTEuanBnfGZoZW0tPjYxMS0+aWR8MnxmaGVtLT42MTEtPnVzZXJJZHwxfGRlY3QxX21hbnVmYWN0dXJlcnxBVk18ZGVjdDFfbW9kZWx8QzR8ZGVjdDFfZndWZXJzaW9ufDQuMjV8ZmhlbS0+NjExLT5icmFuZHxBVk18ZmhlbS0+NjExLT5tb2RlbHxDNHxyYWRpbzAwfERldXRzY2hsYW5kZnVua3xmaGVtLT5yYWRpby0+MHxEZXV0c2NobGFuZGZ1bmt8cmFkaW8wMXxEUmFkaW8gS3VsdHVyfGZoZW0tPnJhZGlvLT4xfERSYWRpbyBLdWx0dXJ8cmFkaW8wMnxEUmFkaW8gV2lzc2VufGZoZW0tPnJhZGlvLT4yfERSYWRpbyBXaXNzZW58cmFkaW8wM3xFaW5zIExpdmUgRGlnZ2l8ZmhlbS0+cmFkaW8tPjN8RWlucyBMaXZlIERpZ2dpfHJhZGlvMDR8cmFkaW9laW5zfGZoZW0tPnJhZGlvLT40fHJhZGlvZWluc3xyYWRpbzA1fFJhZGlvIEZyaXR6fGZoZW0tPnJhZGlvLT41fFJhZGlvIEZyaXR6fHJhZGlvMDZ8U3B1dG5payBMaXZlc3RyZWFtfGZoZW0tPnJhZGlvLT42fFNwdXRuaWsgTGl2ZXN0cmVhbXxyYWRpbzA3fFN3aXNzZ3Jvb3ZlfGZoZW0tPnJhZGlvLT43fFN3aXNzZ3Jvb3ZlfHJhZGlvMDh8fGZoZW0tPnJhZGlvLT44fHxyYWRpbzA5fHxmaGVtLT5yYWRpby0+OXx8cmFkaW8xMHx8ZmhlbS0+cmFkaW8tPjEwfHxyYWRpbzExfHxmaGVtLT5yYWRpby0+MTF8fHJhZGlvMTJ8fGZoZW0tPnJhZGlvLT4xMnx8cmFkaW8xM3x8ZmhlbS0+cmFkaW8tPjEzfHxyYWRpbzE0fHxmaGVtLT5yYWRpby0+MTR8fHJhZGlvMTV8fGZoZW0tPnJhZGlvLT4xNXx8cmFkaW8xNnx8ZmhlbS0+cmFkaW8tPjE2fHxyYWRpbzE3fHxmaGVtLT5yYWRpby0+MTd8fHJhZGlvMTh8fGZoZW0tPnJhZGlvLT4xOHx8cmFkaW8xOXx8ZmhlbS0+cmFkaW8tPjE5fHxyYWRpbzIwfHxmaGVtLT5yYWRpby0+MjB8fHJhZGlvMjF8fGZoZW0tPnJhZGlvLT4yMXx8cmFkaW8yMnx8ZmhlbS0+cmFkaW8tPjIyfHxyYWRpbzIzfHxmaGVtLT5yYWRpby0+MjN8fHJhZGlvMjR8fGZoZW0tPnJhZGlvLT4yNHx8cmFkaW8yNXx8ZmhlbS0+cmFkaW8tPjI1fHxyYWRpbzI2fHxmaGVtLT5yYWRpby0+MjZ8fHJhZGlvMjd8fGZoZW0tPnJhZGlvLT4yN3x8cmFkaW8yOHx8ZmhlbS0+cmFkaW8tPjI4fHxyYWRpbzI5fHxmaGVtLT5yYWRpby0+Mjl8fHJhZGlvMzB8fGZoZW0tPnJhZGlvLT4zMHx8cmFkaW8zMXx8ZmhlbS0+cmFkaW8tPjMxfHxyYWRpbzMyfHxmaGVtLT5yYWRpby0+MzJ8fHJhZGlvMzN8fGZoZW0tPnJhZGlvLT4zM3x8cmFkaW8zNHx8ZmhlbS0+cmFkaW8tPjM0fHxyYWRpbzM1fHxmaGVtLT5yYWRpby0+MzV8fHJhZGlvMzZ8fGZoZW0tPnJhZGlvLT4zNnx8cmFkaW8zN3x8ZmhlbS0+cmFkaW8tPjM3fHxyYWRpbzM4fHxmaGVtLT5yYWRpby0+Mzh8fHJhZGlvMzl8fGZoZW0tPnJhZGlvLT4zOXx8ZmhlbS0+cmFkaW9Db3VudHw0MHxmaGVtLT53bGFuRGV2aWNlLT5FMF9BQ19DQl8yNV8yRV8zNi0+c3BlZWR8MHxmaGVtLT53bGFuRGV2aWNlLT5FMF9BQ19DQl8yNV8yRV8zNi0+c3BlZWRfcnh8MHxmaGVtLT53bGFuRGV2aWNlLT5FMF9BQ19DQl8yNV8yRV8zNi0+cnNzaXwwfGZoZW0tPndsYW5EZXZpY2UtPkE4X0RCXzAzX0JDXzUzX0ExLT5zcGVlZHwxNzN8ZmhlbS0+d2xhbkRldmljZS0+QThfREJfMDNfQkNfNTNfQTEtPnNwZWVkX3J4fDI4fGZoZW0tPndsYW5EZXZpY2UtPkE4X0RCXzAzX0JDXzUzX0ExLT5yc3NpfC04NHxmaGVtLT53bGFuRGV2aWNlLT4yNF8xQl83QV83Ql81Ml80Qy0+c3BlZWR8MHxmaGVtLT53bGFuRGV2aWNlLT4yNF8xQl83QV83Ql81Ml80Qy0+c3BlZWRfcnh8MHxmaGVtLT53bGFuRGV2aWNlLT4yNF8xQl83QV83Ql81Ml80Qy0+cnNzaXwwfGZoZW0tPndsYW5EZXZpY2UtPjU4X0UyXzhGXzgyXzlDXzMyLT5zcGVlZHwwfGZoZW0tPndsYW5EZXZpY2UtPjU4X0UyXzhGXzgyXzlDXzMyLT5zcGVlZF9yeHwwfGZoZW0tPndsYW5EZXZpY2UtPjU4X0UyXzhGXzgyXzlDXzMyLT5yc3NpfDB8ZmhlbS0+d2xhbkRldmljZS0+MjhfRkNfRjZfMEJfNTBfM0QtPnNwZWVkfDB8ZmhlbS0+d2xhbkRldmljZS0+MjhfRkNfRjZfMEJfNTBfM0QtPnNwZWVkX3J4fDB8ZmhlbS0+d2xhbkRldmljZS0+MjhfRkNfRjZfMEJfNTBfM0QtPnJzc2l8MHxmaGVtLT53bGFuRGV2aWNlLT41NF9CQV9ENl8xQl9GMF8wOC0+c3BlZWR8NjUwfGZoZW0tPndsYW5EZXZpY2UtPjU0X0JBX0Q2XzFCX0YwXzA4LT5zcGVlZF9yeHwzNTF8ZmhlbS0+d2xhbkRldmljZS0+NTRfQkFfRDZfMUJfRjBfMDgtPnJzc2l8LTc5fGZoZW0tPndsYW5EZXZpY2UtPjc4X0REXzA4X0Y5X0NBX0ZBLT5zcGVlZHwwfGZoZW0tPndsYW5EZXZpY2UtPjc4X0REXzA4X0Y5X0NBX0ZBLT5zcGVlZF9yeHwwfGZoZW0tPndsYW5EZXZpY2UtPjc4X0REXzA4X0Y5X0NBX0ZBLT5yc3NpfDB8ZmhlbS0+d2xhbkRldmljZS0+MUNfQkZfQ0VfNTNfNjVfOTMtPnNwZWVkfDB8ZmhlbS0+d2xhbkRldmljZS0+MUNfQkZfQ0VfNTNfNjVfOTMtPnNwZWVkX3J4fDB8ZmhlbS0+d2xhbkRldmljZS0+MUNfQkZfQ0VfNTNfNjVfOTMtPnJzc2l8MHxmaGVtLT53bGFuRGV2aWNlLT40OF9FMV9FOV81MF8wNV9GOS0+c3BlZWR8NzJ8ZmhlbS0+d2xhbkRldmljZS0+NDhfRTFfRTlfNTBfMDVfRjktPnNwZWVkX3J4fDcyfGZoZW0tPndsYW5EZXZpY2UtPjQ4X0UxX0U5XzUwXzA1X0Y5LT5yc3NpfC02OHxmaGVtLT53bGFuRGV2aWNlLT42RV80OV83OV82Q183Ql9CRC0+c3BlZWR8MHxmaGVtLT53bGFuRGV2aWNlLT42RV80OV83OV82Q183Ql9CRC0+c3BlZWRfcnh8MHxmaGVtLT53bGFuRGV2aWNlLT42RV80OV83OV82Q183Ql9CRC0+cnNzaXwwfGZoZW0tPndsYW5EZXZpY2UtPjZFXzQ5Xzc5XzZDXzdCX0JELT5zcGVlZHwxMHxmaGVtLT53bGFuRGV2aWNlLT42RV80OV83OV82Q183Ql9CRC0+c3BlZWRfcnh8MjE1fGZoZW0tPndsYW5EZXZpY2UtPjZFXzQ5Xzc5XzZDXzdCX0JELT5yc3NpfC00MXxmaGVtLT53bGFuRGV2aWNlLT45MF9FMV83Ql83RV8yRl9EMy0+c3BlZWR8MHxmaGVtLT53bGFuRGV2aWNlLT45MF9FMV83Ql83RV8yRl9EMy0+c3BlZWRfcnh8MHxmaGVtLT53bGFuRGV2aWNlLT45MF9FMV83Ql83RV8yRl9EMy0+cnNzaXwwfGZoZW0tPndsYW5EZXZpY2UtPjQwXzgzXzFEXzAxXzBEX0M1LT5zcGVlZHwwfGZoZW0tPndsYW5EZXZpY2UtPjQwXzgzXzFEXzAxXzBEX0M1LT5zcGVlZF9yeHwwfGZoZW0tPndsYW5EZXZpY2UtPjQwXzgzXzFEXzAxXzBEX0M1LT5yc3NpfDB8ZmhlbS0+d2xhbkRldmljZS0+QTBfOTlfOUJfRDlfMzhfRkUtPnNwZWVkfDB8ZmhlbS0+d2xhbkRldmljZS0+QTBfOTlfOUJfRDlfMzhfRkUtPnNwZWVkX3J4fDB8ZmhlbS0+d2xhbkRldmljZS0+QTBfOTlfOUJfRDlfMzhfRkUtPnJzc2l8MHxmaGVtLT53bGFuRGV2aWNlLT5COF81M19BQ181N18yN18yRC0+c3BlZWR8MHxmaGVtLT53bGFuRGV2aWNlLT5COF81M19BQ181N18yN18yRC0+c3BlZWRfcnh8MHxmaGVtLT53bGFuRGV2aWNlLT5COF81M19BQ181N18yN18yRC0+cnNzaXwwfGZoZW0tPndsYW5EZXZpY2UtPjVDX0NGXzdGXzdBXzlEX0VBLT5zcGVlZHw1MnxmaGVtLT53bGFuRGV2aWNlLT41Q19DRl83Rl83QV85RF9FQS0+c3BlZWRfcnh8MjR8ZmhlbS0+d2xhbkRldmljZS0+NUNfQ0ZfN0ZfN0FfOURfRUEtPnJzc2l8LTgzfGZoZW0tPndsYW5EZXZpY2UtPjdDXzYxXzY2Xzg0X0ZFXzEyLT5zcGVlZHwwfGZoZW0tPndsYW5EZXZpY2UtPjdDXzYxXzY2Xzg0X0ZFXzEyLT5zcGVlZF9yeHwwfGZoZW0tPndsYW5EZXZpY2UtPjdDXzYxXzY2Xzg0X0ZFXzEyLT5yc3NpfDB8ZmhlbS0+d2xhbkRldmljZS0+NDZfNjVfMTFfQzFfOUFfQzAtPnNwZWVkfDI3MHxmaGVtLT53bGFuRGV2aWNlLT40Nl82NV8xMV9DMV85QV9DMC0+c3BlZWRfcnh8Mzl8ZmhlbS0+d2xhbkRldmljZS0+NDZfNjVfMTFfQzFfOUFfQzAtPnJzc2l8LTc5fGZoZW0tPndsYW5EZXZpY2UtPkNDXzlFX0EyXzgwXzYzXzA1LT5zcGVlZHwwfGZoZW0tPndsYW5EZXZpY2UtPkNDXzlFX0EyXzgwXzYzXzA1LT5zcGVlZF9yeHwwfGZoZW0tPndsYW5EZXZpY2UtPkNDXzlFX0EyXzgwXzYzXzA1LT5yc3NpfDB8ZmhlbS0+d2xhbkRldmljZS0+RjRfQjhfNUVfNjdfNTBfNEMtPnNwZWVkfDB8ZmhlbS0+d2xhbkRldmljZS0+RjRfQjhfNUVfNjdfNTBfNEMtPnNwZWVkX3J4fDB8ZmhlbS0+d2xhbkRldmljZS0+RjRfQjhfNUVfNjdfNTBfNEMtPnJzc2l8MHxmaGVtLT53bGFuRGV2aWNlLT5GNF9COF81RV8zNl8yM180NC0+c3BlZWR8MHxmaGVtLT53bGFuRGV2aWNlLT5GNF9COF81RV8zNl8yM180NC0+c3BlZWRfcnh8MHxmaGVtLT53bGFuRGV2aWNlLT5GNF9COF81RV8zNl8yM180NC0+cnNzaXwwfGZoZW0tPndsYW5EZXZpY2UtPkRDXzRGXzIyXzM3X0I0Xzk3LT5zcGVlZHwwfGZoZW0tPndsYW5EZXZpY2UtPkRDXzRGXzIyXzM3X0I0Xzk3LT5zcGVlZF9yeHwwfGZoZW0tPndsYW5EZXZpY2UtPkRDXzRGXzIyXzM3X0I0Xzk3LT5yc3NpfDB8ZmhlbS0+d2xhbkRldmljZS0+RENfNEZfMjJfMzdfQjRfOTctPnNwZWVkfDQwfGZoZW0tPndsYW5EZXZpY2UtPkRDXzRGXzIyXzM3X0I0Xzk3LT5zcGVlZF9yeHwxN3xmaGVtLT53bGFuRGV2aWNlLT5EQ180Rl8yMl8zN19CNF85Ny0+cnNzaXwtNzB8ZmhlbS0+d2xhbkRldmljZS0+MDBfMDNfN0ZfRkZfRjlfRTEtPnNwZWVkfDB8ZmhlbS0+d2xhbkRldmljZS0+MDBfMDNfN0ZfRkZfRjlfRTEtPnNwZWVkX3J4fDB8ZmhlbS0+d2xhbkRldmljZS0+MDBfMDNfN0ZfRkZfRjlfRTEtPnJzc2l8MHxmaGVtLT53bGFuRGV2aWNlLT4wMF8wM183Rl9GRl9GOV9FMS0+c3BlZWR8MTUwfGZoZW0tPndsYW5EZXZpY2UtPjAwXzAzXzdGX0ZGX0Y5X0UxLT5zcGVlZF9yeHw4OHxmaGVtLT53bGFuRGV2aWNlLT4wMF8wM183Rl9GRl9GOV9FMS0+cnNzaXwtMzN8ZmhlbS0+d2xhbkRldmljZS0+MTBfRDBfN0FfOERfQ0FfNzEtPnNwZWVkfDB8ZmhlbS0+d2xhbkRldmljZS0+MTBfRDBfN0FfOERfQ0FfNzEtPnNwZWVkX3J4fDB8ZmhlbS0+d2xhbkRldmljZS0+MTBfRDBfN0FfOERfQ0FfNzEtPnJzc2l8MHxmaGVtLT53bGFuRGV2aWNlLT4xMF9EMF83QV84RF9DQV83MS0+c3BlZWR8NzJ8ZmhlbS0+d2xhbkRldmljZS0+MTBfRDBfN0FfOERfQ0FfNzEtPnNwZWVkX3J4fDM5fGZoZW0tPndsYW5EZXZpY2UtPjEwX0QwXzdBXzhEX0NBXzcxLT5yc3NpfC02MXxmaGVtLT53bGFuRGV2aWNlLT40Q183Q181Rl9EOV8wOF8yNy0+c3BlZWR8MHxmaGVtLT53bGFuRGV2aWNlLT40Q183Q181Rl9EOV8wOF8yNy0+c3BlZWRfcnh8MHxmaGVtLT53bGFuRGV2aWNlLT40Q183Q181Rl9EOV8wOF8yNy0+cnNzaXwwfGZoZW0tPndsYW5EZXZpY2UtPjM0XzQxXzVEX0NDXzAwX0NFLT5zcGVlZHwwfGZoZW0tPndsYW5EZXZpY2UtPjM0XzQxXzVEX0NDXzAwX0NFLT5zcGVlZF9yeHwwfGZoZW0tPndsYW5EZXZpY2UtPjM0XzQxXzVEX0NDXzAwX0NFLT5yc3NpfDB8ZmhlbS0+d2xhbkRldmljZS0+NkNfNTZfOTdfMkNfNzlfQTctPnNwZWVkfDB8ZmhlbS0+d2xhbkRldmljZS0+NkNfNTZfOTdfMkNfNzlfQTctPnNwZWVkX3J4fDB8ZmhlbS0+d2xhbkRldmljZS0+NkNfNTZfOTdfMkNfNzlfQTctPnJzc2l8MHxmaGVtLT53bGFuRGV2aWNlLT43OF9FMV8wM19FNl8zRV9FMi0+c3BlZWR8MTQ0fGZoZW0tPndsYW5EZXZpY2UtPjc4X0UxXzAzX0U2XzNFX0UyLT5zcGVlZF9yeHw3OHxmaGVtLT53bGFuRGV2aWNlLT43OF9FMV8wM19FNl8zRV9FMi0+cnNzaXwtNzl8ZmhlbS0+d2xhbkRldmljZS0+NjhfQUJfMUVfMzNfQzdfNjgtPnNwZWVkfDB8ZmhlbS0+d2xhbkRldmljZS0+NjhfQUJfMUVfMzNfQzdfNjgtPnNwZWVkX3J4fDB8ZmhlbS0+d2xhbkRldmljZS0+NjhfQUJfMUVfMzNfQzdfNjgtPnJzc2l8MHxmaGVtLT53bGFuRGV2aWNlLT4xMF9EM184QV9CM18wOF9ERC0+c3BlZWR8MHxmaGVtLT53bGFuRGV2aWNlLT4xMF9EM184QV9CM18wOF9ERC0+c3BlZWRfcnh8MHxmaGVtLT53bGFuRGV2aWNlLT4xMF9EM184QV9CM18wOF9ERC0+cnNzaXwwfGZoZW0tPndsYW5EZXZpY2UtPjEwX0QzXzhBX0IzXzA4X0RELT5zcGVlZHw3MnxmaGVtLT53bGFuRGV2aWNlLT4xMF9EM184QV9CM18wOF9ERC0+c3BlZWRfcnh8MzV8ZmhlbS0+d2xhbkRldmljZS0+MTBfRDNfOEFfQjNfMDhfREQtPnJzc2l8LTU2fGZoZW0tPndsYW5EZXZpY2UtPjY4XzU0X0ZEX0YzXzI0X0JGLT5zcGVlZHw3MnxmaGVtLT53bGFuRGV2aWNlLT42OF81NF9GRF9GM18yNF9CRi0+c3BlZWRfcnh8NTh8ZmhlbS0+d2xhbkRldmljZS0+NjhfNTRfRkRfRjNfMjRfQkYtPnJzc2l8LTc1fGZoZW0tPndsYW5EZXZpY2UtPjc0X0UyX0Y1XzM5XzVBXzc0LT5zcGVlZHwwfGZoZW0tPndsYW5EZXZpY2UtPjc0X0UyX0Y1XzM5XzVBXzc0LT5zcGVlZF9yeHwwfGZoZW0tPndsYW5EZXZpY2UtPjc0X0UyX0Y1XzM5XzVBXzc0LT5yc3NpfDB8ZmhlbS0+d2xhbkRldmljZS0+MTBfMEJfQTlfM0NfQUZfMTQtPnNwZWVkfDB8ZmhlbS0+d2xhbkRldmljZS0+MTBfMEJfQTlfM0NfQUZfMTQtPnNwZWVkX3J4fDB8ZmhlbS0+d2xhbkRldmljZS0+MTBfMEJfQTlfM0NfQUZfMTQtPnJzc2l8MHxmaGVtLT53bGFuRGV2aWNlLT4xOF82NV85MF82N183Rl9BQS0+c3BlZWR8MHxmaGVtLT53bGFuRGV2aWNlLT4xOF82NV85MF82N183Rl9BQS0+c3BlZWRfcnh8MHxmaGVtLT53bGFuRGV2aWNlLT4xOF82NV85MF82N183Rl9BQS0+cnNzaXwwfGZoZW0tPndsYW5EZXZpY2UtPkFDXzYzX0JFXzg1XzlGXzVGLT5zcGVlZHwzMDB8ZmhlbS0+d2xhbkRldmljZS0+QUNfNjNfQkVfODVfOUZfNUYtPnNwZWVkX3J4fDMwMHxmaGVtLT53bGFuRGV2aWNlLT5BQ182M19CRV84NV85Rl81Ri0+cnNzaXwtNjd8ZmhlbS0+d2xhbkRldmljZS0+RjRfODFfMzlfODlfMkJfQ0YtPnNwZWVkfDB8ZmhlbS0+d2xhbkRldmljZS0+RjRfODFfMzlfODlfMkJfQ0YtPnNwZWVkX3J4fDB8ZmhlbS0+d2xhbkRldmljZS0+RjRfODFfMzlfODlfMkJfQ0YtPnJzc2l8MHxmaGVtLT53bGFuRGV2aWNlLT5GNF84MV8zOV84OV8yQl9DRi0+c3BlZWR8MTUwfGZoZW0tPndsYW5EZXZpY2UtPkY0XzgxXzM5Xzg5XzJCX0NGLT5zcGVlZF9yeHw5OXxmaGVtLT53bGFuRGV2aWNlLT5GNF84MV8zOV84OV8yQl9DRi0+cnNzaXwtNDF8ZmhlbS0+d2xhbkRldmljZS0+MDBfMjJfRjRfRjNfNTVfMTItPnNwZWVkfDB8ZmhlbS0+d2xhbkRldmljZS0+MDBfMjJfRjRfRjNfNTVfMTItPnNwZWVkX3J4fDB8ZmhlbS0+d2xhbkRldmljZS0+MDBfMjJfRjRfRjNfNTVfMTItPnJzc2l8MHxmaGVtLT53bGFuRGV2aWNlLT43RV80OV83OV81RF9CM18xMy0+c3BlZWR8MHxmaGVtLT53bGFuRGV2aWNlLT43RV80OV83OV81RF9CM18xMy0+c3BlZWRfcnh8MXxmaGVtLT53bGFuRGV2aWNlLT43RV80OV83OV81RF9CM18xMy0+cnNzaXwtNzd8ZmhlbS0+d2xhbkRldmljZS0+N0VfNDlfNzlfNURfQjNfMTQtPnNwZWVkfDY1MHxmaGVtLT53bGFuRGV2aWNlLT43RV80OV83OV81RF9CM18xNC0+c3BlZWRfcnh8NTI2fGZoZW0tPndsYW5EZXZpY2UtPjdFXzQ5Xzc5XzVEX0IzXzE0LT5yc3NpfC03MXxmaGVtLT53bGFuRGV2aWNlLT5EMF83RV8zNV8wRl9ERl9ERS0+c3BlZWR8MHxmaGVtLT53bGFuRGV2aWNlLT5EMF83RV8zNV8wRl9ERl9ERS0+c3BlZWRfcnh8MHxmaGVtLT53bGFuRGV2aWNlLT5EMF83RV8zNV8wRl9ERl9ERS0+cnNzaXwwfGZoZW0tPndsYW5EZXZpY2UtPjE4XzY1XzkwXzkzXzlDXzZELT5zcGVlZHwwfGZoZW0tPndsYW5EZXZpY2UtPjE4XzY1XzkwXzkzXzlDXzZELT5zcGVlZF9yeHwwfGZoZW0tPndsYW5EZXZpY2UtPjE4XzY1XzkwXzkzXzlDXzZELT5yc3NpfDB8ZmhlbS0+d2xhbkRldmljZS0+QTRfMzFfMzVfQkRfRDhfOUUtPnNwZWVkfDB8ZmhlbS0+d2xhbkRldmljZS0+QTRfMzFfMzVfQkRfRDhfOUUtPnNwZWVkX3J4fDB8ZmhlbS0+d2xhbkRldmljZS0+QTRfMzFfMzVfQkRfRDhfOUUtPnJzc2l8MHxmaGVtLT53bGFuRGV2aWNlLT4yOF9GQ19GNl8wQV8yNV9DMi0+c3BlZWR8MHxmaGVtLT53bGFuRGV2aWNlLT4yOF9GQ19GNl8wQV8yNV9DMi0+c3BlZWRfcnh8MHxmaGVtLT53bGFuRGV2aWNlLT4yOF9GQ19GNl8wQV8yNV9DMi0+cnNzaXwwfGZoZW0tPndsYW5EZXZpY2UtPjA0X0Q2X0FBX0FBX0Y5XzJFLT5zcGVlZHwwfGZoZW0tPndsYW5EZXZpY2UtPjA0X0Q2X0FBX0FBX0Y5XzJFLT5zcGVlZF9yeHwwfGZoZW0tPndsYW5EZXZpY2UtPjA0X0Q2X0FBX0FBX0Y5XzJFLT5yc3NpfDB8ZmhlbS0+d2xhbkRldmljZS0+RkNfNjVfREVfRDdfM0VfNjQtPnNwZWVkfDE0NHxmaGVtLT53bGFuRGV2aWNlLT5GQ182NV9ERV9EN18zRV82NC0+c3BlZWRfcnh8MTQ0fGZoZW0tPndsYW5EZXZpY2UtPkZDXzY1X0RFX0Q3XzNFXzY0LT5yc3NpfC03MnxmaGVtLT53bGFuRGV2aWNlLT42Q181Nl85N18yQl84M19COC0+c3BlZWR8MHxmaGVtLT53bGFuRGV2aWNlLT42Q181Nl85N18yQl84M19COC0+c3BlZWRfcnh8MHxmaGVtLT53bGFuRGV2aWNlLT42Q181Nl85N18yQl84M19COC0+cnNzaXwwfGZoZW0tPndsYW5EZXZpY2UtPjI0XzRDX0UzXzgyXzhEXzdCLT5zcGVlZHw3MnxmaGVtLT53bGFuRGV2aWNlLT4yNF80Q19FM184Ml84RF83Qi0+c3BlZWRfcnh8NjV8ZmhlbS0+d2xhbkRldmljZS0+MjRfNENfRTNfODJfOERfN0ItPnJzc2l8LTY0fGZoZW0tPndsYW5EZXZpY2UtPjI4X0ZDX0Y2XzBCXzUyX0I0LT5zcGVlZHwwfGZoZW0tPndsYW5EZXZpY2UtPjI4X0ZDX0Y2XzBCXzUyX0I0LT5zcGVlZF9yeHwwfGZoZW0tPndsYW5EZXZpY2UtPjI4X0ZDX0Y2XzBCXzUyX0I0LT5yc3NpfDB8ZmhlbS0+d2xhbkRldmljZS0+RTRfRjhfOUNfM0JfQzBfMEUtPnNwZWVkfDB8ZmhlbS0+d2xhbkRldmljZS0+RTRfRjhfOUNfM0JfQzBfMEUtPnNwZWVkX3J4fDB8ZmhlbS0+d2xhbkRldmljZS0+RTRfRjhfOUNfM0JfQzBfMEUtPnJzc2l8MHxmaGVtLT53bGFuRGV2aWNlLT44MF8yQl9GOV8zNF82MF8yNy0+c3BlZWR8MHxmaGVtLT53bGFuRGV2aWNlLT44MF8yQl9GOV8zNF82MF8yNy0+c3BlZWRfcnh8MHxmaGVtLT53bGFuRGV2aWNlLT44MF8yQl9GOV8zNF82MF8yNy0+cnNzaXwwfGZoZW0tPndsYW5EZXZpY2UtPkUwXzMzXzhFXzcyXzk0XzNDLT5zcGVlZHwwfGZoZW0tPndsYW5EZXZpY2UtPkUwXzMzXzhFXzcyXzk0XzNDLT5zcGVlZF9yeHwwfGZoZW0tPndsYW5EZXZpY2UtPkUwXzMzXzhFXzcyXzk0XzNDLT5yc3NpfDB8ZmhlbS0+d2xhbkRldmljZS0+NTBfRjVfREFfNkZfNkVfNzEtPnNwZWVkfDB8ZmhlbS0+d2xhbkRldmljZS0+NTBfRjVfREFfNkZfNkVfNzEtPnNwZWVkX3J4fDB8ZmhlbS0+d2xhbkRldmljZS0+NTBfRjVfREFfNkZfNkVfNzEtPnJzc2l8MHxmaGVtLT53bGFuRGV2aWNlLT5BNF8zNF9EOV9GRl82RF9DNC0+c3BlZWR8MHxmaGVtLT53bGFuRGV2aWNlLT5BNF8zNF9EOV9GRl82RF9DNC0+c3BlZWRfcnh8MHxmaGVtLT53bGFuRGV2aWNlLT5BNF8zNF9EOV9GRl82RF9DNC0+cnNzaXwwfGZoZW0tPndsYW5EZXZpY2UtPkFDXzgzX0YzXzA1XzlGXzIyLT5zcGVlZHwwfGZoZW0tPndsYW5EZXZpY2UtPkFDXzgzX0YzXzA1XzlGXzIyLT5zcGVlZF9yeHwwfGZoZW0tPndsYW5EZXZpY2UtPkFDXzgzX0YzXzA1XzlGXzIyLT5yc3NpfDB8ZmhlbS0+d2xhbkRldmljZS0+MUNfMTJfQjBfRUZfNUZfRDYtPnNwZWVkfDB8ZmhlbS0+d2xhbkRldmljZS0+MUNfMTJfQjBfRUZfNUZfRDYtPnNwZWVkX3J4fDB8ZmhlbS0+d2xhbkRldmljZS0+MUNfMTJfQjBfRUZfNUZfRDYtPnJzc2l8MHxmaGVtLT53bGFuRGV2aWNlLT43NF9DMV80Rl8yMF82M185Mi0+c3BlZWR8MnxmaGVtLT53bGFuRGV2aWNlLT43NF9DMV80Rl8yMF82M185Mi0+c3BlZWRfcnh8NXxmaGVtLT53bGFuRGV2aWNlLT43NF9DMV80Rl8yMF82M185Mi0+cnNzaXwtODd8ZmhlbS0+d2xhbkRldmljZS0+ODhfNUZfRThfNjBfN0ZfN0EtPnNwZWVkfDB8ZmhlbS0+d2xhbkRldmljZS0+ODhfNUZfRThfNjBfN0ZfN0EtPnNwZWVkX3J4fDB8ZmhlbS0+d2xhbkRldmljZS0+ODhfNUZfRThfNjBfN0ZfN0EtPnJzc2l8MHxmaGVtLT5sYW5kZXZpY2UtPjE5Mi4xNjguMTg4LjMwfEFsbG5ldFRhYnxmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTY3MzZ8QWxsbmV0VGFifG1hY18xMF9EMF83QV84RF9DQV83MXxBbGxuZXRUYWIgKFdMQU4sIDcyIC8gMzkgTWJpdC9zLCAtNjEpfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguNjZ8QW1hem9uLUVjaG8tRG90LVNjaGxhZnppbW1lcnxmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTMyMzN8QW1hem9uLUVjaG8tRG90LVNjaGxhZnppbW1lcnxtYWNfNjhfNTRfRkRfRjNfMjRfQkZ8QW1hem9uLUVjaG8tRG90LVNjaGxhZnppbW1lciAoV0xBTiwgNzIgLyA1OCBNYml0L3MsIC03NSl8ZmhlbS0+bGFuZGV2aWNlLT4xOTIuMTY4LjE4OC4yMXxBbWF6b25FY2hvfGZoZW0tPmxhbmRldmljZS0+bGFuZGV2aWNlNzQzNXxBbWF6b25FY2hvfG1hY19BQ182M19CRV84NV85Rl81RnxBbWF6b25FY2hvIChXTEFOLCAzMDAgLyAzMDAgTWJpdC9zLCAtNjcpfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguNzJ8QW1hem9uRWNob0xheWF8ZmhlbS0+bGFuZGV2aWNlLT5sYW5kZXZpY2U2NzQ4fEFtYXpvbkVjaG9MYXlhfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguNzd8QW1hem9uRmlyZVRWU3RpY2t8ZmhlbS0+bGFuZGV2aWNlLT5sYW5kZXZpY2UyMjM5fEFtYXpvbkZpcmVUVlN0aWNrfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguNjJ8QW1hem9uU2hvd0t1ZWNoZXxmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTE1Nzh8QW1hem9uU2hvd0t1ZWNoZXxtYWNfNzhfRTFfMDNfRTZfM0VfRTJ8QW1hem9uU2hvd0t1ZWNoZSAoV0xBTiwgMTQ0IC8gNzggTWJpdC9zLCAtNzkpfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguMjd8QW1hem9uU2hvd01pbGF8ZmhlbS0+bGFuZGV2aWNlLT5sYW5kZXZpY2UyNTI5fEFtYXpvblNob3dNaWxhfG1hY19GQ182NV9ERV9EN18zRV82NHxBbWF6b25TaG93TWlsYSAoV0xBTiwgMTQ0IC8gMTQ0IE1iaXQvcywgLTcyKXxmaGVtLT5sYW5kZXZpY2UtPjE5Mi4xNjguMTg4LjIzfEFuZHJvaWQtVGFibGV0dC1XYW5kfGZoZW0tPmxhbmRldmljZS0+bGFuZGV2aWNlMjA5MnxBbmRyb2lkLVRhYmxldHQtV2FuZHxmaGVtLT5sYW5kZXZpY2UtPjE5Mi4xNjguMTg4LjI0fEFwcGxlV2FOYXRhc2NoYXxmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTcxODd8QXBwbGVXYU5hdGFzY2hhfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguODh8QXBwbGVXYWh2b25KdWxlfGZoZW0tPmxhbmRldmljZS0+bGFuZGV2aWNlNjA1fEFwcGxlV2Fodm9uSnVsZXxmaGVtLT5sYW5kZXZpY2UtPjE5Mi4xNjguMTg4LjQ0fEFwcGxlV2FvblRob21hc3xmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTYwNnxBcHBsZVdhb25UaG9tYXN8ZmhlbS0+bGFuZGV2aWNlLT4xOTIuMTY4LjE4OC41OXxCZW5qYW1pbkhhbmR5fGZoZW0tPmxhbmRldmljZS0+bGFuZGV2aWNlOTk4OHxCZW5qYW1pbkhhbmR5fGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguMzV8QmVuamFtaW5NdWhyfGZoZW0tPmxhbmRldmljZS0+bGFuZGV2aWNlMjU2MnxCZW5qYW1pbk11aHJ8ZmhlbS0+bGFuZGV2aWNlLT4xOTIuMTY4LjE4OC44NnxCZW5qYW1pbk5ldXxmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTc3NDB8QmVuamFtaW5OZXV8ZmhlbS0+bGFuZGV2aWNlLT4xOTIuMTY4LjE4OC42N3xCbGlua0JyaWRnZXxmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTY3Mzd8QmxpbmtCcmlkZ2V8bWFjXzAwXzAzXzdGX0ZGX0Y5X0UxfEJsaW5rQnJpZGdlIChXTEFOLCAxNTAgLyA4OCBNYml0L3MsIC0zMyl8ZmhlbS0+bGFuZGV2aWNlLT4xOTIuMTY4LjE4OC43MXxCbGlua0hhdXN0dWVyfGZoZW0tPmxhbmRldmljZS0+bGFuZGV2aWNlNjc0N3xCbGlua0hhdXN0dWVyfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguNjh8QmxpbmtLZWxsZXJlaW5nYW5nfGZoZW0tPmxhbmRldmljZS0+bGFuZGV2aWNlNjc0M3xCbGlua0tlbGxlcmVpbmdhbmd8ZmhlbS0+bGFuZGV2aWNlLT4xOTIuMTY4LjE4OC4zN3xDYW5vbi1NWC05MjV8ZmhlbS0+bGFuZGV2aWNlLT5sYW5kZXZpY2UyMDkzfENhbm9uLU1YLTkyNXxtYWNfRjRfODFfMzlfODlfMkJfQ0Z8Q2Fub24tTVgtOTI1IChXTEFOLCAxNTAgLyA5OSBNYml0L3MsIC00MSl8ZmhlbS0+bGFuZGV2aWNlLT4xOTIuMTY4LjE4OC4yNXxDb3JlRUxFQ3xmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTIwMDh8Q29yZUVMRUN8ZmhlbS0+bGFuZGV2aWNlLT4xOTIuMTY4LjE4OC4zOHxDb3JlRUxFQy1XTEFOfGZoZW0tPmxhbmRldmljZS0+bGFuZGV2aWNlNDMwMnxDb3JlRUxFQy1XTEFOfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguODB8Q29yZUVMRUMtV0xBTjVHaHp8ZmhlbS0+bGFuZGV2aWNlLT5sYW5kZXZpY2UzNTMyfENvcmVFTEVDLVdMQU41R2h6fGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguNDd8Q3ViaWV8ZmhlbS0+bGFuZGV2aWNlLT5sYW5kZXZpY2U3NDQ0fEN1YmllfG1hY18wMl80NV8wNV9DMV80Ql81OXxDdWJpZXxmaGVtLT5sYW5kZXZpY2UtPjE5Mi4xNjguMTg4LjU2fERFU0tUT1AtRDQzS0hMN3xmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTYwNHxERVNLVE9QLUQ0M0tITDd8ZmhlbS0+bGFuZGV2aWNlLT4xOTIuMTY4LjE4OC40OHxERVNLVE9QLVNRTEo0RUx8ZmhlbS0+bGFuZGV2aWNlLT5sYW5kZXZpY2U1Nzh8REVTS1RPUC1TUUxKNEVMfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguNDJ8RGFzaEJ1dHRvbnxmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTE3NjB8RGFzaEJ1dHRvbnxmaGVtLT5sYW5kZXZpY2UtPjE5Mi4xNjguMTg4LjY0fERvcHBlbHN0ZWNrZG9zZS1UZXJyYXNzZXxmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTM1MzF8RG9wcGVsc3RlY2tkb3NlLVRlcnJhc3NlfG1hY180OF9FMV9FOV81MF8wNV9GOXxEb3BwZWxzdGVja2Rvc2UtVGVycmFzc2UgKFdMQU4sIDcyIC8gNzIgTWJpdC9zLCAtNjgpfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguNTB8RWNoby1Eb3QtYXVzZW58ZmhlbS0+bGFuZGV2aWNlLT5sYW5kZXZpY2U5MjE1fEVjaG8tRG90LWF1c2VufG1hY18yNF80Q19FM184Ml84RF83QnxFY2hvLURvdC1hdXNlbiAoV0xBTiwgNzIgLyA2NSBNYml0L3MsIC02NCl8ZmhlbS0+bGFuZGV2aWNlLT4xOTIuMTY4LjE4OC4yOHxGaXJlVFZ8ZmhlbS0+bGFuZGV2aWNlLT5sYW5kZXZpY2UyNjF8RmlyZVRWfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguMzR8RnJpdHpCb3g3NDMwfGZoZW0tPmxhbmRldmljZS0+bGFuZGV2aWNlODcyMHxGcml0ekJveDc0MzB8bWFjXzVDXzQ5Xzc5XzZDXzdCX0JCfEZyaXR6Qm94NzQzMHxmaGVtLT5sYW5kZXZpY2UtPjE5Mi4xNjguMTg4Ljg3fEdhbGF4eS1TMTB8ZmhlbS0+bGFuZGV2aWNlLT5sYW5kZXZpY2U1OTd8R2FsYXh5LVMxMHxtYWNfQThfREJfMDNfQkNfNTNfQTF8R2FsYXh5LVMxMCAoV0xBTiwgMTczIC8gMjggTWJpdC9zLCAtODQpfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguNDl8R2FsYXh5LVM4LVRpbmF8ZmhlbS0+bGFuZGV2aWNlLT5sYW5kZXZpY2UyNTIxfEdhbGF4eS1TOC1UaW5hfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguNTh8R2FsYXh5LVRhYi1UaG9tYXN8ZmhlbS0+bGFuZGV2aWNlLT5sYW5kZXZpY2UzMjY5fEdhbGF4eS1UYWItVGhvbWFzfG1hY18xMF9EM184QV9CM18wOF9ERHxHYWxheHktVGFiLVRob21hcyAoV0xBTiwgNzIgLyAzNSBNYml0L3MsIC01Nil8ZmhlbS0+bGFuZGV2aWNlLT4xOTIuMTY4LjE4OC4yMnxIb21lLVNlcnZlcnxmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTkwNzd8SG9tZS1TZXJ2ZXJ8bWFjX0M4XzYwXzAwXzM2X0JEX0ZEfEhvbWUtU2VydmVyfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguNDN8SnVsZUxhcHRvcHxmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTg3MjV8SnVsZUxhcHRvcHxmaGVtLT5sYW5kZXZpY2UtPjE5Mi4xNjguMTg4LjU3fEtlbGxlcjE3NTBFfGZoZW0tPmxhbmRldmljZS0+bGFuZGV2aWNlNzQ0MHxLZWxsZXIxNzUwRXxtYWNfNDJfNDlfNzlfNURfQjNfMTN8S2VsbGVyMTc1MEV8ZmhlbS0+bGFuZGV2aWNlLT4xOTIuMTY4LjE4OC4zMnxMYXB0b3AtVGhvbWFzLUxhbnxmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTIwMTV8TGFwdG9wLVRob21hcy1MYW58ZmhlbS0+bGFuZGV2aWNlLT4xOTIuMTY4LjE4OC42MHxMYXlhLUZpcmVUYWJ8ZmhlbS0+bGFuZGV2aWNlLT5sYW5kZXZpY2U0MzEwfExheWEtRmlyZVRhYnxmaGVtLT5sYW5kZXZpY2UtPjE5Mi4xNjguMTg4LjY5fExheWFNaWNreXxmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTY3Mzl8TGF5YU1pY2t5fG1hY19EQ180Rl8yMl8zN19CNF85N3xMYXlhTWlja3kgKFdMQU4sIDQwIC8gMTcgTWJpdC9zLCAtNzApfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguNzl8TGlicmVFTEVDfGZoZW0tPmxhbmRldmljZS0+bGFuZGV2aWNlMTc2MzV8TGlicmVFTEVDfG1hY183MF84NV9DMl82RF9BQV84NnxMaWJyZUVMRUN8ZmhlbS0+bGFuZGV2aWNlLT4xOTIuMTY4LjE4OC41NXxMaW51eC1QQy1CdWVyb3xmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTMyMzV8TGludXgtUEMtQnVlcm98ZmhlbS0+bGFuZGV2aWNlLT4xOTIuMTY4LjE4OC4zM3xNaWxhLUxpY2h0fGZoZW0tPmxhbmRldmljZS0+bGFuZGV2aWNlMTg4OXxNaWxhLUxpY2h0fG1hY181Q19DRl83Rl83QV85RF9FQXxNaWxhLUxpY2h0IChXTEFOLCA1MiAvIDI0IE1iaXQvcywgLTgzKXxmaGVtLT5sYW5kZXZpY2UtPjE5Mi4xNjguMTg4LjQ1fE1pbGFGaXJlVGFiOHxmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTI1NjF8TWlsYUZpcmVUYWI4fGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguNDZ8TWlsYVRhYnxmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTM2OTl8TWlsYVRhYnxmaGVtLT5sYW5kZXZpY2UtPjE5Mi4xNjguMTg4LjgxfE1pcmtvcy1pUGhvbmV8ZmhlbS0+bGFuZGV2aWNlLT5sYW5kZXZpY2UzNTI1fE1pcmtvcy1pUGhvbmV8ZmhlbS0+bGFuZGV2aWNlLT4xOTIuMTY4LjE4OC4zOXxOYXRhc2NoYXNpUGhvbmV8ZmhlbS0+bGFuZGV2aWNlLT5sYW5kZXZpY2U1ODN8TmF0YXNjaGFzaVBob25lfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguNzV8TmVsZXxmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTU4MnxOZWxlfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguMzZ8TmVsZXxmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTU2Nzl8TmVsZXxmaGVtLT5sYW5kZXZpY2UtPjE5Mi4xNjguMTg4LjQwfE5lbGUtSXBvZHxmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTU2ODJ8TmVsZS1JcG9kfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguNDF8TmVsZUxhcHRvcHxmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTg3MjJ8TmVsZUxhcHRvcHxmaGVtLT5sYW5kZXZpY2UtPjE5Mi4xNjguMTg4LjIwMXxQQy0xOTItMTY4LTE4OC0yMDF8ZmhlbS0+bGFuZGV2aWNlLT5sYW5kZXZpY2U2MDB8UEMtMTkyLTE2OC0xODgtMjAxfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguODV8UEMtMTkyLTE2OC0xODgtODV8ZmhlbS0+bGFuZGV2aWNlLT5sYW5kZXZpY2U1Nzl8UEMtMTkyLTE2OC0xODgtODV8bWFjXzc0X0MxXzRGXzIwXzYzXzkyfFBDLTE5Mi0xNjgtMTg4LTg1IChXTEFOLCAyIC8gNSBNYml0L3MsIC04Nyl8ZmhlbS0+bGFuZGV2aWNlLT4xOTIuMTY4LjE4OC43NnxQWldOQjIwMTM2fGZoZW0tPmxhbmRldmljZS0+bGFuZGV2aWNlNTc3fFBaV05CMjAxMzZ8ZmhlbS0+bGFuZGV2aWNlLT4xOTIuMTY4LjE4OC43MHxQaGlsaXBzLWh1ZUJyaWRnZXxmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTY3NDF8UGhpbGlwcy1odWVCcmlkZ2V8bWFjXzAwXzE3Xzg4X0FFXzgzXzExfFBoaWxpcHMtaHVlQnJpZGdlfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguMzF8UG93ZXJsaW5lS2VsbGVyYmFyfGZoZW0tPmxhbmRldmljZS0+bGFuZGV2aWNlNzY4NHxQb3dlcmxpbmVLZWxsZXJiYXJ8bWFjXzJBXzY1XzExX0MxXzlBX0MwfFBvd2VybGluZUtlbGxlcmJhcnxmaGVtLT5sYW5kZXZpY2UtPjE5Mi4xNjguMTg4LjgyfFByaXZhdHJlY2huZXJ8ZmhlbS0+bGFuZGV2aWNlLT5sYW5kZXZpY2U1ODF8UHJpdmF0cmVjaG5lcnxmaGVtLT5sYW5kZXZpY2UtPjE5Mi4xNjguMTg4LjYzfFNhbXN1bmctQlItUGxheWVyfGZoZW0tPmxhbmRldmljZS0+bGFuZGV2aWNlNjE2MXxTYW1zdW5nLUJSLVBsYXllcnxmaGVtLT5sYW5kZXZpY2UtPjE5Mi4xNjguMTg4LjI2fFNlcnZlci1CYWNrdXB8ZmhlbS0+bGFuZGV2aWNlLT5sYW5kZXZpY2U5MDc2fFNlcnZlci1CYWNrdXB8bWFjX0JDXzVGX0Y0X0ZCXzdGX0RFfFNlcnZlci1CYWNrdXB8ZmhlbS0+bGFuZGV2aWNlLT4xOTIuMTY4LjE4OC44M3xUaG9tYXMtUDMwUHJvfGZoZW0tPmxhbmRldmljZS0+bGFuZGV2aWNlNzczNHxUaG9tYXMtUDMwUHJvfG1hY181NF9CQV9ENl8xQl9GMF8wOHxUaG9tYXMtUDMwUHJvIChXTEFOLCA2NTAgLyAzNTEgTWJpdC9zLCAtNzkpfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguMjB8VGluYS1MYXB0b3B8ZmhlbS0+bGFuZGV2aWNlLT5sYW5kZXZpY2U2OTQ2fFRpbmEtTGFwdG9wfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguNjV8VGluYXMtSVBhZC0zfGZoZW0tPmxhbmRldmljZS0+bGFuZGV2aWNlMjU5fFRpbmFzLUlQYWQtM3xmaGVtLT5sYW5kZXZpY2UtPjE5Mi4xNjguMTg4LjI5fFZVLVVuby1LZWxsZXJiYXJ8ZmhlbS0+bGFuZGV2aWNlLT5sYW5kZXZpY2UyNDJ8VlUtVW5vLUtlbGxlcmJhcnxtYWNfMDBfMURfRUNfMDJfRTlfNUV8VlUtVW5vLUtlbGxlcmJhcnxmaGVtLT5sYW5kZXZpY2UtPjE5Mi4xNjguMTg4LjUzfFZ1LVVsdGltb3xmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTc0Mzh8VnUtVWx0aW1vfG1hY18wMF8xRF9FQ18wM181Rl8xNnxWdS1VbHRpbW98ZmhlbS0+bGFuZGV2aWNlLT4xOTIuMTY4LjE4OC41MnxXaW4xMC1MYXB0b3AtVGhvbWFzfGZoZW0tPmxhbmRldmljZS0+bGFuZGV2aWNlMjA5OHxXaW4xMC1MYXB0b3AtVGhvbWFzfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguODR8YW5kcm9pZC0zZDA5ZjhlNjEyY2Y3YzU3fGZoZW0tPmxhbmRldmljZS0+bGFuZGV2aWNlNTgwfGFuZHJvaWQtM2QwOWY4ZTYxMmNmN2M1N3xmaGVtLT5sYW5kZXZpY2UtPjE5Mi4xNjguMTg4LjF8ZnJpdHouYm94fGZoZW0tPmxhbmRldmljZS0+bGFuZGV2aWNlNTg4fGZyaXR6LmJveHxtYWNfNDRfNEVfNkRfOUJfRERfRTd8ZnJpdHouYm94fGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguNjF8aVBhZHZvbk5hdGFzY2hhfGZoZW0tPmxhbmRldmljZS0+bGFuZGV2aWNlNTg1fGlQYWR2b25OYXRhc2NoYXxmaGVtLT5sYW5kZXZpY2UtPjE5Mi4xNjguMTg4LjU0fGlQaG9uZXxmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTU4NHxpUGhvbmV8ZmhlbS0+bGFuZGV2aWNlLT4xOTIuMTY4LjE4OC41MXxpUGhvbmUtN1BsdXMtVGhvbWFzfGZoZW0tPmxhbmRldmljZS0+bGFuZGV2aWNlMjA5NnxpUGhvbmUtN1BsdXMtVGhvbWFzfGZoZW0tPmxhbmRldmljZS0+MTkyLjE2OC4xODguNzh8aVBob25lLXByaXZhdHxmaGVtLT5sYW5kZXZpY2UtPmxhbmRldmljZTU3NXxpUGhvbmUtcHJpdmF0fGJveF93bGFuQ291bnR8MTV8Ym94X2d1ZXN0V2xhbkNvdW50fDB8Ym94X3dsYW5fMi40R0h6fG9ufGJveF93bGFuXzVHSHp8b258Ym94X2d1ZXN0V2xhbnxvZmZ8Ym94X2d1ZXN0V2xhblJlbWFpbnwwfGJveF9kZWN0fG9ufGJveF9tb2h8ZGVmYXVsdHxib3hfcG93ZXJSYXRlfDM2fGZoZW0tPmlzX2RvdWJsZV93bGFufDF8Ym94X2Z3VmVyc2lvbnwxNDguMDcuMTJ8Ym94X2Z3VXBkYXRlfDB8Ym94X3RyMDY0fG9ufGJveF90cjA2OXxvbnxib3hfc3RkRGlhbFBvcnR8YWxsRm9uc3xib3hfaXBFeHRlcm58NS4yMzEuMTYyLjE1OHxib3hfY29ubmVjdHw1fGJveF9jcHVUZW1wfDQwfGdzbV9yc3NpfHxnc21fc3RhdGV8fGdzbV90ZWNobm9sb2d5fHxnc21faW50ZXJuZXR8MHxhbGFybTF8V2Vja2VyIDF8YWxhcm0xX3N0YXRlfG9mZnxhbGFybTFfdGltZXwwMDowMHxhbGFybTFfdGFyZ2V0fEZPTiAxfGFsYXJtMV93ZGF5c3xkYWlseXxhbGFybTJ8V2Vja2VyIDJ8YWxhcm0yX3N0YXRlfG9mZnxhbGFybTJfdGltZXwwMDowMHxhbGFybTJfdGFyZ2V0fEZPTiAxfGFsYXJtMl93ZGF5c3xkYWlseXxhbGFybTN8V2Vja2VyIDN8YWxhcm0zX3N0YXRlfG9mZnxhbGFybTNfdGltZXwwMDowMHxhbGFybTNfdGFyZ2V0fEZPTiAxfGFsYXJtM193ZGF5c3xkYWlseXx0YW0xfEFucnVmYmVhbnR3b3J0ZXJ8dGFtMV9zdGF0ZXxvbnx0YW0xX25ld01zZ3wwfHRhbTFfb2xkTXNnfDN8dXNlcjAxfChndWVzdCl8dXNlcjAxX3RoaXNNb250aFRpbWV8MDowMHx1c2VyMDFfdG9kYXlUaW1lfDA6MDB8dXNlcjAxX3RvZGF5U2Vjb25kc3wwfHVzZXIwMV90eXBlfEd1ZXN0fHVzZXJUaWNrZXQwMXw3NjU4MTd8LmJveF9Ub2RheUJ5dGVzUmVjZWl2ZWRIaWdofDB8LmJveF9Ub2RheUJ5dGVzUmVjZWl2ZWRMb3d8MTEwOTI4NDgxfC5ib3hfVG9kYXlCeXRlc1NlbnRIaWdofDB8LmJveF9Ub2RheUJ5dGVzU2VudExvd3wzODAxOTA1OHxyZWFkb3V0VGltZXwxLjg3')}:telnetPort - 0.535284 seconds
2020.01.14 03:37:55.377 3: [Freezemon] myFreezemon: Long function call detected ReadFn:telnetPort_127.0.0.1_49834 - 0.54062 seconds
Guten Morgen,
amBesten stellst du die beiden Attribute auf loglevel 4 oder 5. So richtig Sinn machen die nir, wenn tatsächlich Freezes auftreten.
Zur Interpretation: Das Auslesen der Fritzbox dauert länger als eine halbe Sekunde. Das ist ertmal unkritisch, wenn es aber in einem Freeze auftreten würde, könnte es einen Hinweis geben.
Grüße
Oli
Kurz, weil mobil
Hi KernSani,
freezemon zeigt auch lange Laufzeiten, die in einem BlockingCall oder nonblocking_get entstehen an, oder ? Sprich, es wirdt gelogged, obwohl es sich gar nicht um einen freeze handelt, oder ? Ich frage, weil ich einen freeze angezeigt bekomme, im freeze-Log aber nur http-Zugriffe sehe, die eigentlich non_blocking_get sein müssten.
Zitat=========================================================
[Freezemon] freezedetect: possible freeze starting at 07:19:31, delay is 0.63 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-Nina_Start(NinaTest)
.
.
2020.01.15 07:19:30.272 5: HttpUtils request header:
GET /api/notifications HTTP/1.1
Host: layla.amazon.de
2020.01.15 07:19:30.362 5: HttpUtils request header:
GET /api/bootstrap HTTP/1.1
Host: layla.amazon.de
2020.01.15 07:19:30.378 4: BlockingCall (Nina_Run): created child (5660), uses telnetForBlockingFn_1578672571 to connect back
2020.01.15 07:19:30.405 4: BlockingCall (Nina_Run): created child (5661), uses telnetForBlockingFn_1578672571 to connect back
2020.01.15 07:19:30.412 4: Connection accepted from telnetForBlockingFn_1578672571_127.0.0.1_35580
2020.01.15 07:19:30.418 5: Cmd: >{BlockingRegisterTelnet($cl,193492)}<
2020.01.15 07:19:30.426 4: Connection accepted from telnetForBlockingFn_1578672571_127.0.0.1_35582
2020.01.15 07:19:30.429 5: Cmd: >{BlockingRegisterTelnet($cl,193493)}<
2020.01.15 07:19:30.516 4: https://layla.amazon.de/api/bootstrap: HTTP response code 200
2020.01.15 07:19:30.516 5: HttpUtils https://layla.amazon.de/api/bootstrap: Got data, length: 181
2020.01.15 07:19:30.516 5: HttpUtils response header:
HTTP/1.1 200 OK
2020.01.15 07:19:30.517 4: [echomaster] [echodevice_ParseAuth] [cookielogin6]
2020.01.15 07:19:30.519 5: [echomaster] [echodevice_ParseAuth] [cookielogin6] DATA Dumper=$VAR1 = '{"authentication
2020.01.15 07:19:30.520 4: [echomaster] [echodevice_ParseAuth] JSON OK = {authentication}{authenticated}
2020.01.15 07:19:30.554 4: https://layla.amazon.de/api/notifications: HTTP response code 200
2020.01.15 07:19:30.555 5: HttpUtils https://layla.amazon.de/api/notifications: Got data, length: 2277
2020.01.15 07:19:30.555 5: HttpUtils response header:
HTTP/1.1 200 OK
2020.01.15 07:19:30.555 4: [echomaster] [echodevice_Parse] [getnotifications]
2020.01.15 07:19:30.556 5: [echomaster] [echodevice_Parse] [getnotifications] DATA Dumper=$VAR1 = '{"notifications":
2020.01.15 07:19:30.563 4: [echomaster] [echodevice_HandleCmdQueue] [getsettingstraffic] send command=https://layla.amazon.de/api/traffic/settings Data=
2020.01.15 07:19:30.563 5: HttpUtils url=https://layla.amazon.de/api/traffic/settings
2020.01.15 07:19:30.563 4: IP: layla.amazon.de -> 13.224.231.222
2020.01.15 07:19:30.706 5: HttpUtils request header:
GET /api/traffic/settings HTTP/1.1
2020.01.15 07:19:30.852 4: https://layla.amazon.de/api/traffic/settings: HTTP response code 200
2020.01.15 07:19:30.853 5: HttpUtils https://layla.amazon.de/api/traffic/settings: Got data, length: 511
2020.01.15 07:19:30.853 5: HttpUtils response header:
HTTP/1.1 200 OK
2020.01.15 07:19:30.853 4: [echomaster] [echodevice_Parse] [getsettingstraffic]
2020.01.15 07:19:30.854 5: [echomaster] [echodevice_Parse] [getsettingstraffic] DATA Dumper=$VAR1 =
2020.01.15 07:19:30.858 4: [echomaster] [echodevice_HandleCmdQueue] [getbehavior] send command=https://layla.amazon.de/api/behaviors/automations?limit=100 Data=
2020.01.15 07:19:30.858 5: HttpUtils url=https://layla.amazon.de/api/behaviors/automations?limit=100
2020.01.15 07:19:30.859 4: IP: layla.amazon.de -> 13.224.231.222
2020.01.15 07:19:31.624 5: HttpUtils request header:
GET /api/behaviors/automations?limit=100 HTTP/1.1
2020.01.15 07:19:31.631 5: [Freezemon] freezedetect: ----------- Starting Freeze handling at 2020.01.15 07:19:31.631 ---------------------
[Freezemon] freezedetect: possible freeze starting at 07:19:31, delay is 0.63 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-Nina_Start(NinaTest)
=========================================================
Grüße Markus
Hi Markus,
das ist eine gute Frage, die ich mir kürzlich auch gestellt habe. Dazu müsste ich mal genau verstehen, was beim fork passiert und da bin ich noch nicht dazu gekommen, mich einzulesen... Interessanterweise habe ich mir die Frage auch im Zusammenhang mit dem echodevice gestellt... Ich schau mir das die nächsten Tage nochmal an.
Grüße,
Oli
Kurz, weil mobil
Dann sind wir da ja gemeinsam dran. ;D Das Modul macht bei mir die meisten DNS-Anfragen. Im gesamten Netzwerk. Und dann taucht es immer wieder bei "freezes" auf, obwohl Michael Stein u. Bein behauptet, dass das wegen nonblocking_get nicht sein kann. Wäre prima, wenn wir da zu einer endgültigen "Feststellung", und wenn es nur ist, dass das Modul fälschlicherweise als Bremse verdächtigt wird, kämen. In meinem Fall könnte es der dns-server gewesen sein, da ich den nicht in global gesetzt habe.
Ich schraube gerade meinen threshold runter, um einerseits verdächtige Module zu "enttarnen" und andererseits noch etwas mehr über die Ausgaben von freezemon zu verstehen, damit ich anderen helfen kann. Ich bin auf 0.4 und wenige freezes. Nur einmal waren direkt 4 innerhalb einer min. >:( Den dns setzte ich jetzt mal, um den als "Bremse" auszuschließen.
Grüße Markus
Korrektur: global dnsServer war gesetzt. ::)
Dann schreibe ich es hier auch noch mal bzgl. echodevice ;)
Also ich habe ja 2 Installationen mit echodevice.
Gleicher "Umfang", da selber Account...
Bei meinem Hauptsystem (wo ich nat. auf jeden Fall schaue möglichst "smooth" zu laufen) habe ich kaum Freezes (mal so 3 am Tag :) ) und daher nat. auch kaum vom echodevice (ist aber schon mal mit dabei ;) )...
Auf meinem Testsystem (wo in Summe [deutlich] weniger "los ist") habe ich so einige Freezes :-\ aber da ist das nicht soooo wichtig ;)
Und da (nat.) auch (vermehrt) vom echodevice-Modul...
dnsServer Attribut ist auf beiden Systemen gleich gesetzt...
Auch OS/fhem Aktualität ist ähnlich...
...wobei (nat.) auf dem Testsystem mehr/alles mögliche installiert/ausprobiert wird...
Ich bin nicht sicher, ob da wirklich was blockiert durch das Modul...
Daher würde mich das auch interessieren, ob das nun tatsächlich blockiert (warum dann auf meinem Hauptsystem nicht/so wenig, obwohl dort noch ein paar HTTPMODs laufen [im Gegensatz zum Testsystem]) oder "nur" false-positives sind...
Gruß, Joachim
Zitat von: KernSani am 15 Januar 2020, 10:57:57
Hi Markus,
das ist eine gute Frage, die ich mir kürzlich auch gestellt habe. Dazu müsste ich mal genau verstehen, was beim fork passiert und da bin ich noch nicht dazu gekommen, mich einzulesen... Interessanterweise habe ich mir die Frage auch im Zusammenhang mit dem echodevice gestellt... Ich schau mir das die nächsten Tage nochmal an.
Grüße,
Oli
Moin & ja, ist möglich.
Einfach: freezemon läuft. fork cloned den Prozess -> danach gibt es 2 identische Prozesse mit zwei freezemon. Im Child darf "der Vorgang" (was auch immer) länger dauern, deswegen wurde ja geforked.
Wenn jetzt im Child die Stelle erreicht wird, wo geloggt wird (das kann / muss aber nicht), dann wüsste, der jetzt zweite, freezemon nicht das er eine Kopie ist. Ob bei blockingcall die Stelle im code erreicht wird, dass müsstet ihr untersuchen.
Im Clon sollten aber keine Timer laufen und Freezemon ist ja letztendlich nur ein Timer, der schaut, ob er pünktlich dran kommt...
Kurz, weil mobil
der geforkte child prozess ist eine 1 zu 1 Kopie des Elternprozess. timer im parent -> timer im child. Die Frage ist ob im child die codestelle erreicht wird wo der timer ausgewertet wird.
Mir scheint das, was Jörg schreibt, ist plausibel. Ich hab mir den Code noch einmal genau unter dem Aspekt dieses freezes angeguckt
Zitat[Freezemon] freezedetect: possible freeze starting at 13:25:48, delay is 0.558 possibly caused by: no bad guy found :-(
2020.01.15 13:25:47.045 5: Cmd: >{BlockingStart('204241')}<
2020.01.15 13:25:47.049 5: Cmd: >{Nina_Done('NinaTest|durationFetchReadings|1.00|WarnCount|0|WarnCountInArea|0')}<
2020.01.15 13:25:47.049 5: Nina Nina: Done.464 Beginning processing of selected data.
----dies ist ein Insider für Jörg: Nina verwendet also schon BlockingCall ;-)
.
.
2020.01.15 13:25:47.052 4: Nina NinaTest: Done.550 3 values captured
2020.01.15 13:25:47.064 5: End notify loop for NinaTest
2020.01.15 13:25:47.233 5: TRX: TRX_Read '0f5c01017ef5e5000000007cb9003260'
.
2
2020.01.15 13:25:47.357 4: https://layla.amazon.de/api/devices-v2/device?cached=true&_=1579091145: HTTP response code 200
2020.01.15 13:25:47.357 5: HttpUtils https://layla.amazon.de/api/devices-v2/device?cached=true&_=1579091145: Got data, length: 1283
2020.01.15 13:25:47.357 5: HttpUtils response header:
HTTP/1.1 200 OK ......
2020.01.15 13:25:47.358 4: [echomaster] [echodevice_Parse] [devicesstate]
2020.01.15 13:25:47.359 5: [echomaster] [echodevice_Parse] [devicesstate] DATA Dumper=$VAR1 = '{"devices": .....[
2020.01.15 13:25:47.363 4: [echomaster] [echodevice_HandleCmdQueue] [getisonline] send command=https://layla.amazon.de/api/devices-v2/device?cached=true&_=1579091145 Data=
2020.01.15 13:25:47.364 5: HttpUtils url=https://layla.amazon.de/api/devices-v2/device?cached=true&_=1579091145
2020.01.15 13:25:47.364 4: IP: layla.amazon.de -> 99.86.111.54
2020.01.15 13:25:47.371 5: TRX: TRX_Read '0f5c010240dae6'
.
.
2020.01.15 13:25:47.406 5: TRX_Read END
2020.01.15 13:25:47.504 5: HttpUtils request header:
GET /api/devices-v2/device?cached=true&_=1579091145 HTTP/1.1
Host: layla.amazon.de
2020.01.15 13:25:47.508 4: Connection accepted from telnetForBlockingFn_1578672571_127.0.0.1_56182
2020.01.15 13:25:47.510 5: Cmd: >{BlockingStart('204242')}<
2020.01.15 13:25:47.514 5: Cmd: >{GPIO4_PollfinishFn('RPi_OW_WWL|28|0317717e8aff|T: 28.312|28.312')}<
2020.01.15 13:25:47.514 5: GPIO4: GPIO4_PollfinishFn(RPi_OW_WWL) Start
2020.01.15 13:25:47.514 5: GPIO4: GPIO4_PollfinishFn(RPi_OW_WWL) EndreadingsBulkUpdate
2020.01.15 13:25:47.515 5: GPIO4: GPIO4_PollfinishFn(RPi_OW_WWL) EndreadingsUpdate
2020.01.15 13:25:47.515 5: GPIO4: GPIO4_PollfinishFn(RPi_OW_WWL) End
2020.01.15 13:25:47.870 4: https://layla.amazon.de/api/devices-v2/device?cached=true&_=1579091145: HTTP response code 200
2020.01.15 13:25:47.871 5: HttpUtils https://layla.amazon.de/api/devices-v2/device?cached=true&_=1579091145: Got data, length: 1283
2020.01.15 13:25:47.871 5: HttpUtils response header:
HTTP/1.1 200 OK
2020.01.15 13:25:47.871 4: [echomaster] [echodevice_Parse] [getisonline]
2020.01.15 13:25:47.872 5: [echomaster] [echodevice_Parse] [getisonline] DATA Dumper=$VAR1 = '{"devices":....
2020.01.15 13:25:47.873 4: [echomaster] [echodevice_HandleCmdQueue] [getdevicesettings] send command=https://layla.amazon.de/api/device-preferences Data=
2020.01.15 13:25:47.873 5: HttpUtils url=https://layla.amazon.de/api/device-preferences
2020.01.15 13:25:47.874 4: IP: layla.amazon.de -> 99.86.111.54
2020.01.15 13:25:48.552 5: HttpUtils request header:
GET /api/device-preferences HTTP/1.1
2020.01.15 13:25:48.558 5: [Freezemon] freezedetect: ----------- Starting Freeze handling at 2020.01.15 13:25:48.558 ---------------------
[Freezemon] freezedetect: possible freeze starting at 13:25:48, delay is 0.558 possibly caused by: no bad guy found :-(
[
hier
2020.01.15 13:25:47.364 5: HttpUtils url=https://layla.amazon.de/api/devices-v2/device?cached=true&_=1579091145
war der nonblocking_get request. dann der dns
2020.01.15 13:25:47.364 4: IP: layla.amazon.de -> 99.86.111.54
und nun die Antwort
2020.01.15 13:25:47.870 4: https://layla.amazon.de/api/devices-v2/device?cached=true&_=1579091145: HTTP response code 200
Also 500 ms, die aber gar nicht wehtun.
Vor der Antwort war ein
2020.01.15 13:25:47.515 5: GPIO4: GPIO4_PollfinishFn(RPi_OW_WWL) End
350ms wo nichts passierte. Aber eben kein freeze, sondern nur 2 verschiedene Prozesse(GPIO4_PollfinishFn ist die FinishFN eines BlockingCall).
Was meinst Du, Oli ?
Klingt auf die Schnell plausibel... Ich spiele heute abend mal ein bisschen rum...
Kurz, weil mobil
Hi,
ich habe immer wieder freezes und finde den Verursacher nicht. Hier mal die Ausgabe des logs von freezemon:
=========================================================
[Freezemon] myFreezemon: possible freeze starting at 15:46:16, delay is 179.938 possibly caused by: tmr-BOTVAC::GetStatus(Horst) tmr-CUL_HM_procQs(N/A) tmr-perfmon_ProcessTimer(N/A)
2020.01.15 15:46:15.038 5: BOTVAC Horst: called function GetStatus()
2020.01.15 15:46:15.039 4: BOTVAC Horst: Read password from file
2020.01.15 15:46:15.040 5: BOTVAC Horst: called function SendCommand()
2020.01.15 15:46:15.040 4: BOTVAC Horst: REQ messages/getRobotState
2020.01.15 15:46:15.040 4: BOTVAC Horst: successors 0: messages,getSchedule 1: messages,getGeneralInfo 2: messages,getPreferences
2020.01.15 15:46:15.040 5: BOTVAC Horst: POST https://nucleo.neatocloud.com:4443/vendors/neato/robots/XXX/messages ({"reqId":"0","cmd":"getRobotState"})
2020.01.15 15:46:15.040 5: BOTVAC Horst: header Accept: application/vnd.neato.nucleo.v1^M
Content-Type: application/json^M
Date: Wed, 15 Jan 2020 14:46:15 GMT^M
Authorization: NEATOAPP XXX
2020.01.15 15:46:15.040 5: HttpUtils url=https://nucleo.neatocloud.com:4443/vendors/neato/robots/XXX/messages
2020.01.15 15:46:15.054 4: IP: nucleo.neatocloud.com -> 54.90.247.80
2020.01.15 15:46:15.387 5: HttpUtils request header:
POST /vendors/neato/robots/XXX/messages HTTP/1.0^M
Host: nucleo.neatocloud.com:4443^M
User-Agent: fhem^M
Accept-Encoding: gzip,deflate^M
Accept: application/vnd.neato.nucleo.v1^M
Content-Type: application/json^M
Date: Wed, 15 Jan 2020 14:46:15 GMT^M
Authorization: NEATOAPP XXX^M
Content-Length: 35^M
2020.01.15 15:46:15.742 4: https://nucleo.neatocloud.com:4443/vendors/neato/robots/XXX/messages: HTTP response code 200
2020.01.15 15:46:15.742 5: HttpUtils https://nucleo.neatocloud.com:4443/vendors/neato/robots/XXX/messages: Got data, length: 757
2020.01.15 15:46:15.742 5: HttpUtils response header:
HTTP/1.0 200 OK^M
server: Cowboy^M
date: Wed, 15 Jan 2020 14:46:14 GMT^M
content-length: 757^M
Access-Control-Allow-Origin: *^M
Access-Control-Allow-Methods: GET,POST,PUT,DELETE,OPTIONS^M
Access-Control-Allow-Headers: Accept,Date,X-Date,Authorization^M
Content-Type: application/json
2020.01.15 15:46:15.742 5: BOTVAC Horst: called function ReceiveCommand() rc: HASH(0x34d1ee0) err: data: {"version":1,"reqId":"0","result":"ok","data": {},"error":null,"alert":null,"state":1,"action":0,"cleaning": {"category":0,"mode":1,"modifier":1,"navigationMode":1,"spotWidth":0,"spotHeight":0},"details": {"isCharging":false,"isDocked":true,"isScheduleEnabled":false,"dockHasBeenSeen":false,"charge":98},"availableCommands": {"start":true,"stop":false,"pause":false,"resume":false,"goToBase":false},"availableServices": {"findMe":"basic-1","generalInfo":"basic-1","houseCleaning":"basic-4","IECTest":"advanced-1","logCopy":"basic-1","manualCleaning":"basic-1","maps":"basic-2","preferences":"basic-2","schedule":"basic-2","softwareUpdate":"basic-1","spotCleaning":"basic-3","wifi":"basic-1"},"meta": {"modelName":"BotVacD7Connected","firmware":"4.5.3-189"}}
2020.01.15 15:46:15.742 4: BOTVAC Horst: RCV messages/getRobotState
2020.01.15 15:46:15.742 4: BOTVAC Horst: successors 0: messages,getSchedule 1: messages,getGeneralInfo 2: messages,getPreferences
2020.01.15 15:46:15.742 4: BOTVAC Horst: RES messages/getRobotState - {"version":1,"reqId":"0","result":"ok","data": {},"error":null,"alert":null,"state":1,"action":0,"cleaning": {"category":0,"mode":1,"modifier":1,"navigationMode":1,"spotWidth":0,"spotHeight":0},"details": {"isCharging":false,"isDocked":true,"isScheduleEnabled":false,"dockHasBeenSeen":false,"charge":98},"availableCommands": {"start":true,"stop":false,"pause":false,"resume":false,"goToBase":false},"availableServices": {"findMe":"basic-1","generalInfo":"basic-1","houseCleaning":"basic-4","IECTest":"advanced-1","logCopy":"basic-1","manualCleaning":"basic-1","maps":"basic-2","preferences":"basic-2","schedule":"basic-2","softwareUpdate":"basic-1","spotCleaning":"basic-3","wifi":"basic-1"},"meta": {"modelName":"BotVacD7Connected","firmware":"4.5.3-189"}}
2020.01.15 15:46:15.744 4: BOTVAC Horst: Read password from file
2020.01.15 15:46:15.744 5: BOTVAC Horst: called function SendCommand()
2020.01.15 15:46:15.744 4: BOTVAC Horst: REQ messages/getSchedule
2020.01.15 15:46:15.745 4: BOTVAC Horst: successors 0: messages,getGeneralInfo 1: messages,getPreferences
2020.01.15 15:46:15.745 5: BOTVAC Horst: POST https://nucleo.neatocloud.com:4443/vendors/neato/robots/XXX/messages ({"reqId":"0","cmd":"getScheduleEvents"})
2020.01.15 15:46:15.745 5: BOTVAC Horst: header Accept: application/vnd.neato.nucleo.v1^M
Content-Type: application/json^M
Date: Wed, 15 Jan 2020 14:46:15 GMT^M
Authorization: NEATOAPP XXX
2020.01.15 15:46:15.745 5: HttpUtils url=https://nucleo.neatocloud.com:4443/vendors/neato/robots/XXX/messages
2020.01.15 15:46:15.746 4: IP: nucleo.neatocloud.com -> 54.90.247.80
--- log skips 180.191 secs.
2020.01.15 15:49:15.938 4: HttpUtils: https://nucleo.neatocloud.com:4443/vendors/neato/robots/XXX/messages: Can't connect(2) to https://nucleo.neatocloud.com:4443: SSL wants a read first
2020.01.15 15:49:15.938 5: BOTVAC Horst: called function ReceiveCommand() rc: HASH(0x341c0a0) err: https://nucleo.neatocloud.com:4443/vendors/neato/robots/XXX/messages: Can't connect(2) to https://nucleo.neatocloud.com:4443: SSL wants a read first data:
2020.01.15 15:49:15.938 4: BOTVAC Horst:messages/getScheduleEvents RCV https://nucleo.neatocloud.com:4443/vendors/neato/robots/XXX/messages: Can't connect(2) to https://nucleo.neatocloud.com:4443: SSL wants a read first
2020.01.15 15:49:15.938 4: BOTVAC Horst: drop successors
2020.01.15 15:49:15.938 4: BOTVAC Horst: successors 0: messages,getGeneralInfo 1: messages,getPreferences
2020.01.15 15:49:15.938 1: Perfmon: possible freeze starting at 15:46:16, delay is 179.938
2020.01.15 15:49:15.939 5: [Freezemon] myFreezemon: ----------- Starting Freeze handling at 2020.01.15 15:49:15.939 ---------------------
2020.01.15 15:49:15.939 5: [Freezemon] myFreezemon found something that's not a REF CUL_HM_procQs
2020.01.15 15:49:15.939 5: Freezemon: something went wrong CUL_HM_procQs
[Freezemon] myFreezemon: possible freeze starting at 15:46:16, delay is 179.938 possibly caused by: tmr-BOTVAC::GetStatus(Horst) tmr-CUL_HM_procQs(N/A) tmr-perfmon_ProcessTimer(N/A)
Hat das was mit Homematic zu tun? Wonach könnte ich denn suchen? Welche logs würden helfen?
Danke schon mal!
Nein, mit Deinem Staubsauger(Vermutung)
Respekt 189 Sek.
Du kannst im 1. Schritt mal dnsServer im global-device setzen(wenn Du nichts besseres hast müsste 8.8.8.8 funktionieren).
Wenn es bei den freezes bleibt, müsstest Du den Modulautor fragen, ob er nonblocking_get einsetzt. Wenn nicht, sollte er das tun....
und bitte nicht perfmon und freezemon parallel laufen lassen
Zurück zur Blocking Diskussion:
ich habe mir blocking.pm angesehen und ein bisschen über fork gelesen und ein bisschen getestet (einen BlockingCall gebastelt der für ein paar Sekunden sleep macht, Log schreibt, nochmal schläft etc...), folgende Erkenntnis: ich konnte freezemon nicht dazu bringen, den blocking call auszuwerten, obwohl es logisch gesehen eigentlich möglich sein müsste
Zur Sicherheit könnte ich noch im freezemon eine Abfrage einbauen, Rudi ist nämlich so nett und setz im Child $fhemForked, man kann also leicht rausfinden ob man parent oder child ist.
Nun zum eigentlichen Thema HttpUtils_NonblockingGet: Hier sieht das anders aus... Ich bin davon ausgegangen, dass HttpUtils intern blocking nutzt. Ist aber nicht so. HttpUtils_NonblockingGet läuft mit IO::Socket::INET im non-blocking mode... Da bin ich Netzwerk- und perltechnisch leider nicht wirklich in der Lage zu sagen, was da genau passiert. Aber so wie ich das verstehe läuft es im selben Prozess - d.h. m.E. sind Freezes die hier auftreten echte Freezes. Wie genau sich das äußert und warum echodevice da irgendwie auffällig ist muss ich irgendwie noch genauer untersuchen (auch wenn ich gerade nicht weiß wie).
ZitatZur Sicherheit könnte ich noch im freezemon eine Abfrage einbauen,
Und da wollte ich Dir gerade vorschlagen $PID beim define des freezemon-devices in einem Internal abzulegen und dann im Betrieb abzugleichen. Aber es macht sicherlich Sinn, entweder in den childs nicht mehr zu loggen oder die pid mitzuloggen.(zumindest als Testversion)
ZitatIO::Socket::INET im non-blocking mode... Da bin ich Netzwerk- und perltechnisch leider nicht wirklich in der Lage zu sagen, was da genau passiert. Aber so wie ich das verstehe läuft es im selben Prozess
Ich les mal.Vielleicht fällt mir was auf...
nach code Durchsicht in blocking.pm: sehe ich auch so. Die einzige Möglichkeit hier wäre wenn jemand innerhalb der blocking fn fhem io benutzt. So etwas wie HttpUtils_NonblockingGet. Sonst ist die select loop wo der timer ausgewertet wird eigentlich unerreichbar.
da war wieder einer schneller... u. der weiß es auch noch viel besser...
ZitatAber so wie ich das verstehe läuft es im selben Prozess
yes. auch hier select (https://jameshfisher.com/2017/04/05/set_socket_nonblocking/) das Stichwort.
Ist dann aber auch kein freeze. Und ich glaub beim echodevice sieht das dann im freeze-log so "komisch" aus, weil ja eine ganze Latte requests für die Statusermittlung abgesetzt werden.
oder aber es sind doch freezes. Möglicherweise ist die pauschale Aussage mit global dnsServer gäbe es kein blockierendes Verhalten bei nonblocking_get falsch.
Mein dns u. pi-hole läuft auf dem rpi, wo auch fhem läuft. global dnsServer ist auf dessen IP gesetzt.
Nun hatte ich heute morgen relativ viel lokalen Netzverkehr. Und nun bekam ich ne Menge freezes angezeigt
2020.01.16 10:46:44.159 4: [echomaster] [echodevice_HandleCmdQueue] [getnotifications] send command=https://layla.amazon.de/api/notifications Data=
2020.01.16 10:46:44.159 5: HttpUtils url=https://layla.amazon.de/api/notifications
2020.01.16 10:46:44.159 4: IP: layla.amazon.de -> 99.86.111.54
.
nun werden 14 weitere nonblocking_gets vom echodevice abgesetzt
.
2020.01.16 10:46:44.558 5: HttpUtils request header:
GET /api/notifications HTTP/1.1 (das ist dann der request nachdem der dns längst die IP aufgelöst hat
ein (ungekürztes) Beispiel, was sicherlich ein echter bedeutender freeze war
Zitat[Freezemon] freezedetect: possible freeze starting at 10:47:45, delay is 1.346 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-at_Exec(check_jammer)
2020.01.16 10:47:44.181 5: [echomaster] [echodevice_GetSettings] start refresh settings
2020.01.16 10:47:44.181 4: [echomaster] [echodevice_SendCommand] [getnotifications] START
2020.01.16 10:47:44.183 4: [echomaster] [echodevice_SendCommand] [getnotifications] PushToCmdQueue SendURL =https://layla.amazon.de/api/notifications
2020.01.16 10:47:44.183 4: [echomaster] [echodevice_SendCommand] [getnotifications] PushToCmdQueue SendData=
2020.01.16 10:47:44.185 4: [echomaster] [echodevice_HandleCmdQueue] [getnotifications] send command=https://layla.amazon.de/api/notifications Data=
2020.01.16 10:47:44.185 5: HttpUtils url=https://layla.amazon.de/api/notifications
2020.01.16 10:47:44.187 5: DNS QUERY 707201000001000000000000056c61796c6106616d617a6f6e0264650000010001
2020.01.16 10:47:44.187 4: [echomaster] [echodevice_SendCommand] [alarmvolume] START
2020.01.16 10:47:44.188 4: [echomaster] [echodevice_SendCommand] [alarmvolume] PushToCmdQueue SendURL =https://layla.amazon.de/api/device-notification-state?_=1579168064
2020.01.16 10:47:44.189 4: [echomaster] [echodevice_SendCommand] [alarmvolume] PushToCmdQueue SendData=
2020.01.16 10:47:44.190 4: [echomaster] [echodevice_SendCommand] [bluetoothstate] START
2020.01.16 10:47:44.191 4: [echomaster] [echodevice_SendCommand] [bluetoothstate] PushToCmdQueue SendURL =https://layla.amazon.de/api/bluetooth?cached=true&_=1579168064
2020.01.16 10:47:44.191 4: [echomaster] [echodevice_SendCommand] [bluetoothstate] PushToCmdQueue SendData=
2020.01.16 10:47:44.192 4: [echomaster] [echodevice_SendCommand] [getdnd] START
2020.01.16 10:47:44.193 4: [echomaster] [echodevice_SendCommand] [getdnd] PushToCmdQueue SendURL =https://layla.amazon.de/api/dnd/device-status-list?_=1579168064
2020.01.16 10:47:44.193 4: [echomaster] [echodevice_SendCommand] [getdnd] PushToCmdQueue SendData=
2020.01.16 10:47:44.193 4: [echomaster] [echodevice_SendCommand] [wakeword] START
2020.01.16 10:47:44.194 4: [echomaster] [echodevice_SendCommand] [wakeword] PushToCmdQueue SendURL =https://layla.amazon.de/api/wake-word?_=1579168064
2020.01.16 10:47:44.194 4: [echomaster] [echodevice_SendCommand] [wakeword] PushToCmdQueue SendData=
2020.01.16 10:47:44.195 4: [echomaster] [echodevice_SendCommand] [listitems_task] START
2020.01.16 10:47:44.196 4: [echomaster] [echodevice_SendCommand] [listitems_task] PushToCmdQueue SendURL =https://layla.amazon.de/api/todos?size=100&startTime=&endTime=&completed=false&type=TASK&deviceSerialNumber=&deviceType=&_=1579168064
2020.01.16 10:47:44.196 4: [echomaster] [echodevice_SendCommand] [listitems_task] PushToCmdQueue SendData=TASK
2020.01.16 10:47:44.197 4: [echomaster] [echodevice_SendCommand] [listitems_shopping] START
2020.01.16 10:47:44.198 4: [echomaster] [echodevice_SendCommand] [listitems_shopping] PushToCmdQueue SendURL =https://layla.amazon.de/api/todos?size=100&startTime=&endTime=&completed=false&type=SHOPPING_ITEM&deviceSerialNumber=&deviceType=&_=1579168064
2020.01.16 10:47:44.198 4: [echomaster] [echodevice_SendCommand] [listitems_shopping] PushToCmdQueue SendData=SHOPPING_ITEM
2020.01.16 10:47:44.199 4: [echomaster] [echodevice_SendCommand] [getdevicesettings] START
2020.01.16 10:47:44.200 4: [echomaster] [echodevice_SendCommand] [getdevicesettings] PushToCmdQueue SendURL =https://layla.amazon.de/api/device-preferences
2020.01.16 10:47:44.200 4: [echomaster] [echodevice_SendCommand] [getdevicesettings] PushToCmdQueue SendData=
2020.01.16 10:47:44.201 4: [echomaster] [echodevice_SendCommand] [getisonline] START
2020.01.16 10:47:44.201 4: [echomaster] [echodevice_SendCommand] [getisonline] PushToCmdQueue SendURL =https://layla.amazon.de/api/devices-v2/device?cached=true&_=1579168064
2020.01.16 10:47:44.202 4: [echomaster] [echodevice_SendCommand] [getisonline] PushToCmdQueue SendData=
2020.01.16 10:47:44.202 4: [echomaster] [echodevice_SendCommand] [devicesstate] START
2020.01.16 10:47:44.203 4: [echomaster] [echodevice_SendCommand] [devicesstate] PushToCmdQueue SendURL =https://layla.amazon.de/api/devices-v2/device?cached=true&_=1579168064
2020.01.16 10:47:44.203 4: [echomaster] [echodevice_SendCommand] [devicesstate] PushToCmdQueue SendData=
2020.01.16 10:47:44.204 4: [echomaster] [echodevice_SendCommand] [account] START
2020.01.16 10:47:44.205 4: [echomaster] [echodevice_SendCommand] [account] PushToCmdQueue SendURL =https://alexa-comms-mobile-service.amazon.com/accounts
2020.01.16 10:47:44.205 4: [echomaster] [echodevice_SendCommand] [account] PushToCmdQueue SendData=
2020.01.16 10:47:44.206 4: [echomaster] [echodevice_SendLoginCommand] [cookielogin6]
2020.01.16 10:47:44.207 5: HttpUtils url=https://layla.amazon.de/api/bootstrap
2020.01.16 10:47:44.208 5: DNS QUERY 707201000001000000000000056c61796c6106616d617a6f6e0264650000010001
2020.01.16 10:47:44.209 5: [echomaster] [echodevice_GetSettings] refresh voice command
2020.01.16 10:47:44.209 4: [echomaster] [echodevice_SendCommand] [activities] START
2020.01.16 10:47:44.210 4: [echomaster] [echodevice_SendCommand] [activities] PushToCmdQueue SendURL =https://layla.amazon.de/api/activities?startTime=&size=50&offset=1&_=1579168064
2020.01.16 10:47:44.210 4: [echomaster] [echodevice_SendCommand] [activities] PushToCmdQueue SendData=
2020.01.16 10:47:44.211 4: [echomaster] [echodevice_SendCommand] [getbehavior] START
2020.01.16 10:47:44.212 4: [echomaster] [echodevice_SendCommand] [getbehavior] PushToCmdQueue SendURL =https://layla.amazon.de/api/behaviors/automations?limit=100
2020.01.16 10:47:44.212 4: [echomaster] [echodevice_SendCommand] [getbehavior] PushToCmdQueue SendData=
2020.01.16 10:47:44.213 4: [echomaster] [echodevice_SendCommand] [getsettingstraffic] START
2020.01.16 10:47:44.214 4: [echomaster] [echodevice_SendCommand] [getsettingstraffic] PushToCmdQueue SendURL =https://layla.amazon.de/api/traffic/settings
2020.01.16 10:47:44.214 4: [echomaster] [echodevice_SendCommand] [getsettingstraffic] PushToCmdQueue SendData=
2020.01.16 10:47:44.215 4: [echomaster] [echodevice_GetSettings] Timer INTERVAL = 60
2020.01.16 10:47:44.238 4: BlockingCall (Nina_Run): created child (30526), uses telnetForBlockingFn_1578672571 to connect back
2020.01.16 10:47:44.274 4: Connection accepted from telnetForBlockingFn_1578672571_127.0.0.1_46010
2020.01.16 10:47:44.283 5: Cmd: >{BlockingRegisterTelnet($cl,241845)}<
2020.01.16 10:47:44.344 5: DNS ANSWER 166:707281800001000400000000056c61796c6106616d617a6f6e0264650000010001c00c00050001000000120012056c61796c6106616d617a6f6e03636f6d00c02d000500010000022f0020056c61796c6106616d617a6f6e03636f6d0866726f6e746965720361327ac03ac04b000500010000003c001f0e64337273717570337463786a31610a636c6f756466726f6e74036e657400c077000100010000003c000463566f36
2020.01.16 10:47:44.344 4: DNS result for layla.amazon.de: 99.86.111.54, ttl:60
2020.01.16 10:47:44.345 4: IP: layla.amazon.de -> 99.86.111.54
2020.01.16 10:47:44.357 5: DNS ANSWER 166:707281800001000400000000056c61796c6106616d617a6f6e0264650000010001c00c000500010000029f0012056c61796c6106616d617a6f6e03636f6d00c02d00050001000005a10020056c61796c6106616d617a6f6e03636f6d0866726f6e746965720361327ac03ac04b000500010000003c001f0e64337273717570337463786a31610a636c6f756466726f6e74036e657400c077000100010000003c000463566f36
2020.01.16 10:47:44.358 4: DNS result for layla.amazon.de: 99.86.111.54, ttl:60
2020.01.16 10:47:44.358 4: IP: layla.amazon.de -> 99.86.111.54
--- log skips 1.944 secs.
2020.01.16 10:47:46.302 5: HttpUtils request header:
GET /api/notifications HTTP/1.1
Host: layla.amazon.de
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0
Accept-Language: de,en-US;q=0.7,en;q=0.3
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1
csrf: -633661467
Content-Type: application/json; charset=UTF-8
2020.01.16 10:47:46.309 5: exec at command check_jammer
2020.01.16 10:47:46.310 5: Cmd: >{if (ReadingsAge('TRXUSB','state',0) > 40 || ReadingsVal('CULFB','state','opened') ne 'Initialized') {Voicecmd('jammer')}}<
2020.01.16 10:47:46.312 5: redefine at command check_jammer as +*00:00:05 {if (ReadingsAge('TRXUSB','state',0) > 40 || ReadingsVal('CULFB','state','opened') ne 'Initialized') {Voicecmd('jammer')}}
2020.01.16 10:47:46.346 5: End notify loop for check_jammer
2020.01.16 10:47:46.347 5: [Freezemon] freezedetect: ----------- Starting Freeze handling at 2020.01.16 10:47:46.347 ---------------------
[Freezemon] freezedetect: possible freeze starting at 10:47:45, delay is 1.346 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-at_Exec(check_jammer)
man sieht den freeze von 1,944 sec. Davor die DNS-Auflösung und danach den http-request
ähnliches Bild
Zitat--- log skips 4.410 secs.
2020.01.16 10:47:53.006 5: HttpUtils request header:
GET /api/traffic/settings HTTP/1.1
Host: layla.amazon.de
2020.01.16 10:47:55.533 4: IP: layla.amazon.de -> 99.86.111.54
2020.01.16 10:47:56.468 5: HttpUtils request header:
GET /api/activities?startTime=&size=50&offset=1&_=1579168064 HTTP/1.1
Host: layla.amazon.de
--- log skips 1.199 secs.
2020.01.16 10:48:46.503 5: HttpUtils request header:
GET /api/bootstrap HTTP/1.1
2020.01.16 10:48:49.831 5: TRX_Read END
2020.01.16 10:48:50.730 5: HttpUtils request header:
GET /api/activities?startTime=&size=50&offset=1&_=1579168124 HTTP/1.1
Host: layla.amazon.de
2020.01.16 10:48:51.705 5: HttpUtils url=https://alexa-comms-mobile-service.amazon.com/accounts
2020.01.16 10:48:51.705 4: IP: alexa-comms-mobile-service.amazon.com -> 99.86.117.220
--- log skips 1.796 secs.
2020.01.16 10:48:53.501 5: HttpUtils request header:
GET /accounts HTTP/1.1
2020.01.16 10:49:44.385 5: Cmd: >{BlockingRegisterTelnet($cl,241910)}<
--- log skips 1.047 secs.
2020.01.16 10:49:45.432 5: HttpUtils request header:
GET /api/notifications HTTP/1.1
Host: layla.amazon.de
2020.01.16 10:49:46.138 5: [Freezemon] freezedetect: Blocking Call with PID 30720 ended
--- log skips 2.465 secs.
2020.01.16 10:49:48.603 5: HttpUtils request header:
GET /api/traffic/settings HTTP/1.1
Host: layla.amazon.de
2020.01.16 10:49:51.103 5: [Freezemon] freezedetect: Blocking Call with PID 30732 ended
--- log skips 2.238 secs.
2020.01.16 10:49:53.341 5: HttpUtils request header:
GET /api/behaviors/automations?limit=100 HTTP/1.1
Host: layla.amazon.de
2020.01.16 10:49:55.744 5: GPIO4: GPIO4_PollfinishFn(RPi_OW_TK) End
--- log skips 2.004 secs.
2020.01.16 10:49:57.748 5: HttpUtils request header:
GET /api/device-preferences HTTP/1.1
Host: layla.amazon.de
2020.01.16 10:50:00.542 4: BlockingCall (GPIO4_Poll): created child (30752), uses telnetForBlockingFn_1578672571 to connect back
--- log skips 1.128 secs.
2020.01.16 10:50:01.669 5: HttpUtils request header:
GET /api/todos?size=100&startTime=&endTime=&completed=false&type=SHOPPING_ITEM&deviceSerialNumber=&deviceType=&_=1579168184 HTTP/1.1
Host: layla.amazon.de
2020.01.16 10:50:02.414 5: End notify loop for PVzaehler
--- log skips 1.664 secs.
2020.01.16 10:50:04.079 5: HttpUtils request header:
GET /api/todos?size=100&startTime=&endTime=&completed=false&type=TASK&deviceSerialNumber=&deviceType=&_=1579168184 HTTP/1.1
Host: layla.amazon.de
Nachdem es im lokalen Netzwerk ruhiger war, blieben auch freeze-Meldungen aus.
Ich ziehe da jetzt mal ein paar Schlüsse draus:
1. es sind die dns-Anfragen die zum freeze führen
2. global dnsServer ist nicht das Allheilmittel nonblocking_get wirklich non-blocking zu machen
3. aufgrund der Vielzahl der dns-Anfragen verschlimmert das echodevice-Modul das Problem
Lösung: Aufruf der nonblocking_get mit IP (ich kenne jetzt keine Funktion, aber dürfte ja nicht so schwierig sein, EINMAL die IP zu ermitteln)
Was meint Ihr ?
@Joachim: Könntest Du Dir mit diesem Ansatz das unterschiedliche Verhalten Deiner beiden Systeme erklären ?
Zitat von: KölnSolar am 16 Januar 2020, 18:49:46
Nachdem es im lokalen Netzwerk ruhiger war, blieben auch freeze-Meldungen aus.
Ich ziehe da jetzt mal ein paar Schlüsse draus:
1. es sind die dns-Anfragen die zum freeze führen
2. global dnsServer ist nicht das Allheilmittel nonblocking_get wirklich non-blocking zu machen
3. aufgrund der Vielzahl der dns-Anfragen verschlimmert das echodevice-Modul das Problem
Lösung: Aufruf der nonblocking_get mit IP (ich kenne jetzt keine Funktion, aber dürfte ja nicht so schwierig sein, EINMAL die IP zu ermitteln)
Was meint Ihr ?
@Joachim: Könntest Du Dir mit diesem Ansatz das unterschiedliche Verhalten Deiner beiden Systeme erklären ?
Äh, hmmm.
Nicht so wirklich.
Wahrscheinlich habe ich nur "nix" verstanden ;)
Weil die beiden Systeme sind sehr ähnlich.
Ähnlicher Stand bzgl. OS und ähnlichr Stand bzgl. fhem.
Es ist nat. auf dem Testsystem schon so einiges mal hin- und weginstalliert worden, Testsytem halt...
Auch dnsServer ist auf beiden Systemen gleicht gesetzt.
Allerdings: das Testsystem ist per WLAN angebunden...
Also kurz: was könnte ich tun um da weiter zu helfen!?
Sorry, Joachim
ZitatWahrscheinlich habe ich nur "nix" verstanden
verstehe ich. ;D
Ich versteh ja selber nicht, wo es wirklich hängt. Ich versteh aber auch nicht, was das setzen des dnsServers konkret bedeutet. Ich dachte, da hättest Du vielleicht mehr Hintergründe...Hab jetzt mal im Code geguckt und weiß nun, dass ohne gesetzten dnsServer blockierende Perl-Standardfunktionen aufgerufen werden, ansonsonsten FHEM-Code, der nicht blockieren sollte, es aber wohl doch stellenweise tut.
ZitatAllerdings: das Testsystem ist per WLAN angebunden...
Zumindest ein Anhaltspunkt. Und wenn Du den mal per LAN einbindest ?
ZitatAuch dnsServer ist auf beiden Systemen gleicht gesetzt.
extern oder auch lokal vorgelagert ?
ich versuch mal verständlicher :-\ zu beschreiben, was wir wissen und was meine Bsp. zeigen
- echodevice setzt über zehn nonblocking_get je Statuszyklus ab
- wir haben 3 Aktivitäten beim nonblocking_get: IP-Ermittlung, http-request, http-answer
Timelags zw. request u. answer sind unkritisch, weil über select gesteuert
irgendwo bei der IP-Ermittlung oder in der Schnittstelle zum request hakt es. Warum ? Meine Bsp. zeigen, dass nach einem freeze immer
ein request folgt
- nonblocking_get läuft komplett im Hauptprozess ab. Das lässt den Schluss zu, dass es echte freezes sind, die freezemon zeigt.
In der Zeit ist in FHEM nichts passiert, sonst wäre es gelogged. Der Prozess hat auf etwas von außen gewartet.
- mit IP anstatt hostname sollte es wirklich non-blocking sein
Ich les mal weiter httputils.....
Ah ok klarer...
...etwas ;)
Also genau bzgl. dnsServer hast du ja selbst geklärt ;)
Ich habe aktuell (noch) bei beiden meine FB gesetzt, also lokal.
Obwohl die eigentlich NICHT (mehr) mein DNS sein soll(te) weil ich ja piHole laufen habe...
Aber da aktuell nur meine fhem-Server (noch) über die FB direkt "nach außen" gehen ist mir das nicht so wichtig (gewesen umzustellen)...
Hmmm, wobei: also die WLAN-Installation (Testsystem) hat auf OS-Ebene piHole als DNS. In fhem ist die FB gesetzt... (sollte aber egal sein, beides sollte DNS gut machen ;) )
Kann ich aber auch mal ändern...
...wenn Zeit ist.
Klar auch das mit LAN statt WLAN kann ich mal machen...
Hmmm, wenn man so drüber nachdenkt sind dann doch so ein paar Unterschiede... ;)
Ich werde das mal angehen und berichten...
Gruß, Joachim
Zitat- nonblocking_get läuft komplett im Hauptprozess ab. Das lässt den Schluss zu, dass es echte freezes sind, die freezemon zeigt.
In der Zeit ist in FHEM nichts passiert, sonst wäre es gelogged. Der Prozess hat auf etwas von außen gewartet.
oder
es gab nicht zu tun in FHEM(außer anstehende requests) ? Es hat nur lange gedauert bis der request von "außen"(von was ?) "getriggered" wurde ? Für diese Annahme, kann nur Oli erklären, was überhaupt der Grund war, dass freezemon einen freeze gemeldet hat....
Markus,
sorry, aber ich glaube du bist mit dem DNS auf dem Holzweg... aus deinem ausführlichen Log: Ganz oben wird der Call für die notifications an die Queue von echodevice übergeben und quasi sofort abgearbeitet, HTTPUtils_nonBolocking Get beginnt mit dem DNS Call:
2020.01.16 10:47:44.181 4: [echomaster] [echodevice_SendCommand] [getnotifications] START
2020.01.16 10:47:44.183 4: [echomaster] [echodevice_SendCommand] [getnotifications] PushToCmdQueue SendURL =https://layla.amazon.de/api/notifications
2020.01.16 10:47:44.183 4: [echomaster] [echodevice_SendCommand] [getnotifications] PushToCmdQueue SendData=
2020.01.16 10:47:44.185 4: [echomaster] [echodevice_HandleCmdQueue] [getnotifications] send command=https://layla.amazon.de/api/notifications Data=
2020.01.16 10:47:44.185 5: HttpUtils url=https://layla.amazon.de/api/notifications
2020.01.16 10:47:44.187 5: DNS QUERY 707201000001000000000000056c61796c6106616d617a6f6e0264650000010001
FHEM (bzw. hier echodevice) arbeitet ganz normal weiter (baut weitere Calls auf), bis der DNS antwortet:
2020.01.16 10:47:44.357 5: DNS ANSWER 166:707281800001000400000000056c61796c6106616d617a6f6e0264650000010001c00c000500010000029f0012056c61796c6106616d617a6f6e03636f6d00c02d00050001000005a10020056c61796c6106616d617a6f6e03636f6d0866726f6e746965720361327ac03ac04b000500010000003c001f0e64337273717570337463786a31610a636c6f756466726f6e74036e657400c077000100010000003c000463566f36
2020.01.16 10:47:44.358 4: DNS result for layla.amazon.de: 99.86.111.54, ttl:60
2020.01.16 10:47:44.358 4: IP: layla.amazon.de -> 99.86.111.54
bis hier ist m.E. alles ok, aber dann macht HTTPUtils irgendwas, was blockiert, noch bevor der eigentliche GET rausgeht:
--- log skips 1.944 secs.
2020.01.16 10:47:46.302 5: HttpUtils request header:
GET /api/notifications HTTP/1.1
Host: layla.amazon.de
Was ich interessant finde, ist das zwischendrin:
2020.01.16 10:47:44.206 4: [echomaster] [echodevice_SendLoginCommand] [cookielogin6]
2020.01.16 10:47:44.207 5: HttpUtils url=https://layla.amazon.de/api/bootstrap
2020.01.16 10:47:44.208 5: DNS QUERY 707201000001000000000000056c61796c6106616d617a6f6e0264650000010001
Echodevice sendet das Login ebenfalls über nonBlocking, geht dabei aber nicht über seine eigene Queue, sondern ruft direkt den nonBlocking auf, ich nehme an, damit pfuscht er dem zuvor erfolgten nonBlocking-Aufruf irgendwie ins Handwerk...
ZitatEchodevice sendet das Login ebenfalls über nonBlocking, geht dabei aber nicht über seine eigene Queue
Ich glaube, da bist Du auf dem Holzweg. ;D Meines Erachtens gibt es keine Queue.
echodevice_SendCommand($hash,"getnotifications","");
echodevice_SendCommand($hash,"alarmvolume","");
echodevice_SendCommand($hash,"bluetoothstate","");
echodevice_SendCommand($hash,"getdnd","");
echodevice_SendCommand($hash,"wakeword","");
echodevice_SendCommand($hash,"listitems_task","TASK");
echodevice_SendCommand($hash,"listitems_shopping","SHOPPING_ITEM");
echodevice_SendCommand($hash,"getdevicesettings","");
echodevice_SendCommand($hash,"getisonline","");
echodevice_SendCommand($hash,"devices","") if ($hash->{helper}{VERSION} eq "");
echodevice_SendCommand($hash,"devicesstate","");
echodevice_SendCommand($hash,"account","") if ($hash->{helper}{".COMMSID"} eq "");
echodevice_SendLoginCommand($hash,"cookielogin6","");in sendCommand erfolgt jeweils ein nonblocking_get.
Zitates gab nicht zu tun in FHEM(außer anstehende requests) ? Es hat nur lange gedauert bis der request von "außen"(von was ?) "getriggered" wurde ?
Und wenn der FHEM-Prozess keine CPU-Zeit mehr bekam(requests mit niedriger Priorität) und der trigger von außen ist nur wieder neue Zuteilung von Rechenzeit ? :-\ :-\ :-\
Zitat von: KölnSolar am 16 Januar 2020, 23:32:17
Ich glaube, da bist Du auf dem Holzweg. ;D Meines Erachtens gibt es keine Queue.
doch gibt es (außer du hast lange kein Update gemacht), ganz am Ende von SendCommand kommt:
#2018.01.14 - PushToCmdQueue
push @{$hash->{helper}{CMD_QUEUE}}, $SendParam;
echodevice_HandleCmdQueue($hash);
steht übrigens auch in deinem Log ;-)
2020.01.16 10:47:44.183 4: [echomaster] [echodevice_SendCommand] [getnotifications] PushToCmdQueue SendData=
2020.01.16 10:47:44.185 4: [echomaster] [echodevice_HandleCmdQueue] [getnotifications] send command=https://layla.amazon.de/api/notifications Data=
Zitat
es gab nicht zu tun in FHEM(außer anstehende requests) ? Es hat nur lange gedauert bis der request von "außen"(von was ?) "getriggered" wurde ?
FHEM hat immer was zu tun :-) Wenn Freezemon läuft dann ruft FHEM zumindest jede Sekunde einmal Freezemon auf (oder versucht es - nur wenn Freezemon um <threshold> Sekunden verspätet aufgerufen wird, kommt es zum Freeze).
EDIT: Ich habe versucht das Szenario mit zwei unmittelbar aufeinander folgenden nonBlockingGets in myUtils nachzustellen, gelingt mir aber irgendwie nicht, einen Freeze zu produzieren, habe aber gelernt, dass HTTPUtils einen DNS Cache hat.
nur nicht richtig geguckt ::) :-[
Zitateinen DNS Cache hat.
Ja den sah ich auch schon. Hab ihn aber noch nicht wirklich verstanden. :-[
ZitatWenn Freezemon läuft dann ruft FHEM zumindest jede Sekunde einmal Freezemon auf
OK, dann eher
ZitatUnd wenn der FHEM-Prozess keine CPU-Zeit mehr bekam(requests mit niedriger Priorität) und der trigger von außen ist nur wieder neue Zuteilung von Rechenzeit ? :-\ :-\ :-\
Es muss ja irgendetwas mit der hohen Nicht-FHEM-Belastung auf dem Rpi zu tun haben. Heute nacht nur ein einziger winziger freeze gemeldet. Woran "sieht" freezemon den hier ?
[Freezemon] freezedetect: possible freeze starting at 05:30:00, delay is 0.48 possibly caused by: tmr-GPIO4_DeviceUpdateLoop(RPi_OW_WWL) tmr-at_Exec(tMH) tmr-at_Exec(check_jammer)
2020.01.17 05:29:59.404 5: GPIO4: GPIO4_DeviceUpdateLoop(RPi_OW_WWL), pollingInterval:5
2020.01.17 05:29:59.425 4: BlockingCall (GPIO4_Poll): created child (20213), uses telnetForBlockingFn_1578672571 to connect back
2020.01.17 05:30:00.009 5: exec at command tMH
2020.01.17 05:30:00.010 5: Cmd: >set schalter1 on<
2020.01.17 05:30:00.012 3: FS20 set schalter1 on
2020.01.17 05:30:00.014 5: CULFB sending F35aa3811
2020.01.17 05:30:00.015 5: SW: F35aa3811
2020.01.17 05:30:00.052 5: Triggering act_on_Heizung
2020.01.17 05:30:00.053 4: act_on_Heizung exec {heiz_toggle($EVENT)}
2020.01.17 05:30:00.053 5: Cmd: >{heiz_toggle($EVENT)}<
2020.01.17 05:30:00.056 5: Cmd: >set schalter4 off<
2020.01.17 05:30:00.057 3: FS20 set schalter4 off
2020.01.17 05:30:00.058 5: CULFB sending F35aa3b00
2020.01.17 05:30:00.113 5: End notify loop for schalter4
2020.01.17 05:30:00.114 5: Cmd: >set schalter4 off<
2020.01.17 05:30:00.114 3: FS20 set schalter4 off
2020.01.17 05:30:00.114 5: CULFB sending F35aa3b00
2020.01.17 05:30:00.136 5: End notify loop for schalter4
2020.01.17 05:30:00.136 5: Cmd: >set schalter3 on-for-timer 192<
2020.01.17 05:30:00.137 3: FS20 set schalter3 on-for-timer 192
2020.01.17 05:30:00.137 5: CULFB sending F35aa3a396c
2020.01.17 05:30:00.145 4: Follow: +00:03:12 setstate schalter3 off
2020.01.17 05:30:00.156 5: End notify loop for schalter3_timer
2020.01.17 05:30:00.159 5: createNotifyHash
2020.01.17 05:30:00.185 5: statistics stat_sl: Notify.280 Notification of 'global' received. Device not monitored.
2020.01.17 05:30:00.186 5: statistics stat_wr: Notify.280 Notification of 'global' received. Device not monitored.
2020.01.17 05:30:00.199 5: End notify loop for global
2020.01.17 05:30:00.227 5: End notify loop for schalter3
2020.01.17 05:30:00.227 5: Cmd: >set schalter3 on-for-timer 192<
2020.01.17 05:30:00.228 3: FS20 set schalter3 on-for-timer 192
2020.01.17 05:30:00.228 5: CULFB sending F35aa3a396c
2020.01.17 05:30:00.230 5: statistics stat_sl: Notify.280 Notification of 'global' received. Device not monitored.
2020.01.17 05:30:00.230 5: statistics stat_wr: Notify.280 Notification of 'global' received. Device not monitored.
2020.01.17 05:30:00.241 5: End notify loop for global
2020.01.17 05:30:00.241 4: Follow: +00:03:12 setstate schalter3 off
2020.01.17 05:30:00.252 5: End notify loop for schalter3_timer
2020.01.17 05:30:00.253 5: createNotifyHash
2020.01.17 05:30:00.278 5: statistics stat_sl: Notify.280 Notification of 'global' received. Device not monitored.
2020.01.17 05:30:00.279 5: statistics stat_wr: Notify.280 Notification of 'global' received. Device not monitored.
2020.01.17 05:30:00.290 5: End notify loop for global
2020.01.17 05:30:00.316 5: End notify loop for schalter3
2020.01.17 05:30:00.317 5: Cmd: >attr schalter3 ignore 1<
2020.01.17 05:30:00.318 5: statistics stat_sl: Notify.280 Notification of 'global' received. Device not monitored.
2020.01.17 05:30:00.318 5: statistics stat_wr: Notify.280 Notification of 'global' received. Device not monitored.
2020.01.17 05:30:00.344 5: End notify loop for global
2020.01.17 05:30:00.345 5: Cmd: >defmod temp_mixer_on at +00:04:00 deleteattr schalter3 ignore<
2020.01.17 05:30:00.356 5: End notify loop for temp_mixer_on
2020.01.17 05:30:00.358 5: createNotifyHash
2020.01.17 05:30:00.385 5: statistics stat_sl: Notify.280 Notification of 'global' received. Device not monitored.
2020.01.17 05:30:00.385 5: statistics stat_wr: Notify.280 Notification of 'global' received. Device not monitored.
2020.01.17 05:30:00.396 5: End notify loop for global
2020.01.17 05:30:00.397 5: Cmd: >set schalter1 on-for-timer 9216<
2020.01.17 05:30:00.397 3: FS20 set schalter1 on-for-timer 9216
2020.01.17 05:30:00.398 5: CULFB sending F35aa3839c9
2020.01.17 05:30:00.398 4: Follow: +02:33:36 setstate schalter1 off
2020.01.17 05:30:00.408 5: End notify loop for schalter1_timer
2020.01.17 05:30:00.409 5: createNotifyHash
2020.01.17 05:30:00.434 5: statistics stat_sl: Notify.280 Notification of 'global' received. Device not monitored.
2020.01.17 05:30:00.434 5: statistics stat_wr: Notify.280 Notification of 'global' received. Device not monitored.
2020.01.17 05:30:00.446 5: End notify loop for global
2020.01.17 05:30:00.446 5: Cmd: >setreading schalter1 temperature 16.25<
2020.01.17 05:30:00.447 5: Cmd: >setreading schalter1 running off<
2020.01.17 05:30:00.467 5: End notify loop for schalter1
2020.01.17 05:30:00.467 5: redefine at command tMH as *05:30:00 set schalter1 on
2020.01.17 05:30:00.469 5: exec at command check_jammer
2020.01.17 05:30:00.469 5: Cmd: >{if (ReadingsAge('TRXUSB','state',0) > 40 || ReadingsVal('CULFB','state','opened') ne 'Initialized') {Voicecmd('jammer')}}<
2020.01.17 05:30:00.470 5: redefine at command check_jammer as +*00:00:05 {if (ReadingsAge('TRXUSB','state',0) > 40 || ReadingsVal('CULFB','state','opened') ne 'Initialized') {Voicecmd('jammer')}}
2020.01.17 05:30:00.480 5: End notify loop for check_jammer
2020.01.17 05:30:00.481 5: [Freezemon] freezedetect: ----------- Starting Freeze handling at 2020.01.17 05:30:00.480 ---------------------
[Freezemon] freezedetect: possible freeze starting at 05:30:00, delay is 0.48 possibly caused by: tmr-GPIO4_DeviceUpdateLoop(RPi_OW_WWL) tmr-at_Exec(tMH) tmr-at_Exec(check_jammer)
Ich seh da nur den BlockingCall und dann 0,5s später den pünktlichen Start meines at's. Danach dann normale Verarbeitung. Was hat denn da die freeze-Meldung ausgelöst ? Ist es die Ausführung des at's aber erst 05:30:00.467 das redefine dieses zyklischen at's ?
Ich hab an anderer Stelle Rudi mal gebeten einen Blick auf unsere echodevice/httputils Diskussion zu werfen...
Zitat von: KölnSolar am 16 Januar 2020, 18:49:46
Mein dns u. pi-hole läuft auf dem rpi, wo auch fhem läuft. global dnsServer ist auf dessen IP gesetzt.
Nun hatte ich heute morgen relativ viel lokalen Netzverkehr. Und nun bekam ich ne Menge freezes angezeigt
Diese Idee hatte ich auch - FHEM und pi-Hole liefen im letzten Jahr kurzzeitig auf einem Pi3. In dieser Konstallation hatte ich freezes ohne Ende. Inzwischen läuft FHEM auf einem Pi4 und pi-Hole auf einem ausgemustertem Pi2.
So ist Ruhe...
Peter
Zitat von: PSI69 am 17 Januar 2020, 08:25:55
Diese Idee hatte ich auch - FHEM und pi-Hole liefen im letzten Jahr kurzzeitig auf einem Pi3. In dieser Konstallation hatte ich freezes ohne Ende. Inzwischen läuft FHEM auf einem Pi4 und pi-Hole auf einem ausgemustertem Pi2.
So ist Ruhe...
Peter
Exakt mein Szenario (nur dass ich Pihole nie auf dem FHEM Server hatte)
Zitat von: KölnSolar am 17 Januar 2020, 08:22:56
Ich seh da nur den BlockingCall und dann 0,5s später den pünktlichen Start meines at's. Danach dann normale Verarbeitung. Was hat denn da die freeze-Meldung ausgelöst ? Ist es die Ausführung des at's aber erst 05:30:00.467 das redefine dieses zyklischen at's ?
Der Start dürfte das hier sein:
05:30:00.009 5: exec at command tMHDanach kommt eine Kette von Verarbeitungsschritten, die keinen anderen Timer mehr reinlässt. Dein Threshold von 0,5 ist natürlich auch extrem ;)
Zitat
einen DNS Cache hat.
erfolgreiche DNS Anfragen werden in einen Hash geschrieben und bleiben die vom DNS Server gemeldete TTL Sekunden da drin.
Ich hab an anderer Stelle Rudi mal gebeten einen Blick auf unsere echodevice/httputils Diskussion zu werfen...yep, da lese ich auch mit :)
ZitatDein Threshold von 0,5 ist natürlich auch extrem ;)
0,4 ;D
ZitatDanach kommt eine Kette von Verarbeitungsschritten, die keinen anderen Timer mehr reinlässt.
Ich verstehe Deine Aussage, aber nicht den Grund. Es wird eine Funktion aufgerufen. In dieser laufen ein paar FHEM-Befehle mit fhem(".."). Der letzte ist dann ("set schalter1 running off") und dann kommt das von mir angesprochene redefine des zyklischen at's. Das at hat dann tatsächlich 0,458s+ gedauert. Ich glaub beim schreiben hab ich es verstanden....Jetzt kann ich erkannte "freezes" und das freeze-Log wieder etwas besser interpretieren. ;)
du bringst mich gerade ins Grübeln... wenn die mit fhem() aufgerufen werden, sollten die eigentlich in die fhem-command-queue gehen und damit den freezemon-timer (oder andere anstehende Prozesse) reinlassen... Muss ich mir heute Abend nochmal anschauen...
Zitatman sieht den freeze von 1,944 sec. Davor die DNS-Auflösung und danach den http-request
Vmtl. liegt das an der Aushandlung der HTTPS Verschluesselung, das ist naemlich das, was zwischen "IP: layla.amazon.de -> 99.86.111.54" und "HttpUtils request header" erfolgt. Das ist leider blockierend, um es zu fixen muesste ich IO::Socket::SSL umbauen.
ZitatIch versteh aber auch nicht, was das setzen des dnsServers konkret bedeutet.
Falls gesetzt, ruft HttpUtils_NonblockingGet nicht die (blockierende) Linux Bibliothek fuer Namensaufloesung auf, sondern die nicht blockierende Implementation in HttpUtils.pm. Diese kann man auch separat testen mit:
{ HttpUtils_gethostbyname({timeout=>4}, "fhem.de", 1,sub(){my($h,$e,$a)=@_;; Log 1, $e ? "ERR:$e": ("IP:".ip2str($a)) }) }Zitataufgrund der Vielzahl der dns-Anfragen verschlimmert das echodevice-Modul das Problem
Die DNS-Aufloesung in HttpUtils.pm implementiert einen Cache, d.h. fuer ttl (TimeToLive) Sekunden nach der ersten Anfrage wird keine weitere fuer diesen Namen gemacht. ttl wird vom "Auskunftsgeber" bzw. Domain-Owner vorgegeben. Wenn man die Aussage korrigiert: "Aufgrund der vielen neu aufzubauenden verschluesselten Verbindungen", dann stimmt sie :)
Ich wuerde versuchen mehrere Request ueber die gleiche Verbindung abzusetzen (in der Hoffnung, dass der Server das unterstuetzt), damit spart man N-1 SSL-Verdindungsaufbauten. Dafuer muss man beim HttpUtils_NonblockingGet den gleichen Hash verwenden, und keepalive setzen. In etwa so:
fhem> { $data{mhc} = { callback=>sub($$$){ Log 1,"ERR:$_[1] DATA:".length($_[2]) }, keepalive=>1 } }
fhem> { $data{mhc}{url} = "https://fhem.de/index.html", HttpUtils_NonblockingGet($data{mhc}) }
fhem> { $data{mhc}{url} = "https://fhem.de/MAINTAINER.txt", HttpUtils_NonblockingGet($data{mhc}) }
Na da hat doch der Rudi kurz mal aus dem Ärmel geschüttelt was wir in tagelanger Diskussion nicht zur Hälfte verstanden haben und gleich eine (mögliche) Lösung geliefert :)
Vielleicht ergänzend noch zum DNS: Die TTL bei layla.amazon.de ist bei gerade mal 30 Sekunden, d.h. der Cache überlebt im Normalfall gerade mal einen Status Refresh, aber da der DNS ja hier nicht das Problem ist, kann man das ja ignorieren. Was mich irritiert ist, warum das SSL aushandeln dann bei dir manchmal so lange dauert, aber nicht immer...
Erst mal danke Rudi. Und ich lag dann ja gar nicht soooo falsch mit meinen Annahmen. Nur die konkrete Erklärung fehlte noch.
ZitatIch wuerde versuchen mehrere Request ueber die gleiche Verbindung abzusetzen (in der Hoffnung, dass der Server das unterstuetzt), damit spart man N-1 SSL-Verdindungsaufbauten. Dafuer muss man beim HttpUtils_NonblockingGet den gleichen Hash verwenden, und keepalive setzen.
Oder mein anderes Thema: ganz auslagern. ;D (ich weiß, auch nicht Allheilmittel und .....)
Aber prima, dann kennen wir jetzt den 2. Grund warum nonblocking nicht unbedingt non-blocking ist. Und da ohne TLS heute fast nichts mehr geht, ist eigentlich jedes Modul potenziell betroffen, dass per https(vermutlich auch mqtts....?) kommuniziert. :'(
Zitatum es zu fixen muesste ich IO::Socket::SSL umbauen.
Macht ja eher wenig Sinn ein Standard-Modul zu verändern.
ZitatWas mich irritiert ist, warum das SSL aushandeln dann bei dir manchmal so lange dauert, aber nicht immer...
Mich nicht. Ich schrieb ja mehrfach, dass es irgendwie mit dem traffic zusammenhängen muss. Und wenn hier im lokalen Netzwerk viel los ist, dann dauert es halt, bis die TLS-Kommunikation aufgebaut ist. Sind ja ein paar Kommunikationsschritte hin-und-her.
Non blocking SSL Connect würde aber eigentlich gehen
und mir hat die ganze Experimentiererei einen Hinweis gegeben, wo "no bad guy found" herkommen kann, auch wenn ich noch keine Idee habe, wie ich den "bad guy" in so einem Szenario abfangen könnte...
Ich nehme an, wenn die Callback-Verarbeitung einen Freeze verursacht (und im fraglichen Zeitraum kein anderer Kandidat vorhanden ist) kommt es zu "no bad guy found". Wenn so ein nonBlockingGet zurück kommt (und wahrscheinlich auch sein Kollege, der fork) dann fällt der Aufruf - aus FHEM Sicht - spontan vom Himmel. Das Command oder der Timer, die urspünglich mal den nonBlockingGet aufgerufen haben sind beendet, daher kommen sie nicht als Kandidaten in Frage. Der Callback meldet sich aber nicht irgendwo im FHEM und sagt: "Hier bin ich, darf ich mal", sondern wird einfach abgearbeitet... Grübel (ich denke laut), das heißt Freezemon müsste mich in nonBlockingGet reinhängen, sich den Callback merken und bei einem Freeze auswerten... Nicht schön, aber wäre einen Versuch Wert... Danke für's zuhören :)
Zitat von: KölnSolar am 17 Januar 2020, 10:06:34
0,4 ;DIch verstehe Deine Aussage, aber nicht den Grund. Es wird eine Funktion aufgerufen. In dieser laufen ein paar FHEM-Befehle mit fhem(".."). Der letzte ist dann ("set schalter1 running off") und dann kommt das von mir angesprochene redefine des zyklischen at's. Das at hat dann tatsächlich 0,458s+ gedauert. Ich glaub beim schreiben hab ich es verstanden....Jetzt kann ich erkannte "freezes" und das freeze-Log wieder etwas besser interpretieren. ;)
Ich habe das gerade nochmal empirisch untersucht. Ich habe ein DOIF (weil besser zum Testen als ein at) gebaut, das hintereinander ziemlich oft die gleiche Lampe einschaltet. Das führt zu einem Freeze von fast 5 Sekunden. Der Versuch währenddessen ein anderes Licht (manuell über WebUI) einzuschalten hat eine merkliche Verzögerung, und schaltet erst, wenn das DOIF durch ist.
Im echten Leben ist es vermutlich sehr unwahrscheinlich, dass während solcher Ketten von Kommandos ein kritisches Ereignis eintritt, wo die verzögerte Ausführung einen echten Impact hat, aber trotzdem was, was man sich merken sollte.
ZitatNon blocking SSL Connect würde aber eigentlich gehen
Theoretisch schon (geek hat vor 5 Jahren fuer Nonblocking Write in FHEMWEB einen Patch gebaut, was SSL explizit beruecksichtigt), aber ich meine unser SSL-accept ist immer noch blocking, da $clientinfo[0]->blocking(0) auf manchen Systemen Probleme verursachte (https://forum.fhem.de/index.php/topic,24799.msg183664.html#msg183664).
Kennt jemand eine Methode, wie ich das Problem reproduzieren kann, zwecks nonblocking-ssl-connect Einbau?
Wenn ich Joachims und meine Beobachtungen zusammenpacke, hilft sicherlich eine schlechte bzw. viel genutzt WLAN-Verbindung und häufige https-requests, um das Problem zu reproduzieren.
Wenn Du mir Codeschnipsel schickst, kann ich hier in meiner Umgebung gerne testen, wenn Du darin einen gangbaren Weg siehst.
Zitat von: KölnSolar am 18 Januar 2020, 13:24:01
Wenn ich Joachims und meine Beobachtungen zusammenpacke, hilft sicherlich eine schlechte bzw. viel genutzt WLAN-Verbindung und häufige https-requests, um das Problem zu reproduzieren.
Wenn Du mir Codeschnipsel schickst, kann ich hier in meiner Umgebung gerne testen, wenn Du darin einen gangbaren Weg siehst.
Für Tests schließe ich mich an...
Wenn es noch Sinn macht, dann baue ich auch mal um auf LAN etc.
Allerdings erst morgen oder am Mo...
Gruß, Joachim
Danke fuer die Angebote, aber ich muss das schon selbst testen.
Blockieren muss es bei der SSL-Handshake, nicht davor, und nicht danach.
Gedankenspiel. Simulieren durch einen Server dessen Bandbreite künstlich begrenzt ist, zb auf 10byte/ Sekunde. Kann das ein weg sein?
ZitatIch wuerde versuchen mehrere Request ueber die gleiche Verbindung abzusetzen
Für "Nina"" hab ich das schon einmal umgesetzt. Scheint zu funktionieren. Nur noch 1 DNS-Aufruf/Zyklus(folglich auch nur 1 TLS-handshake). Somit um 80% traffic reduziert. ;D
Ich frag mich nur, warum ohne das keepalive nicht bereits vorher nur einmal die DNS-Abfrage erfolgte und die weiteren 4 vom FHEM-DNS-Cache "beantwortet" wurden. :-\ Die Antwort sah so aus
2020.01.19 11:54:37 5: HttpUtils response header:
HTTP/1.1 200 OK
Server: nginx
Cache-Control: max-age=2
Content-Type: application/json
Strict-Transport-Security: max-age=31536000; includeSubdomains;
Date: Sun, 19 Jan 2020 10:54:37 GMT
Expires: Sun, 19 Jan 2020 10:54:39 GMT
X-Xss-Protection: 1; mode=block;
ETag: "5e1c93d7-2"
X-Content-Type-Options: nosniff;
Connection: close
Last-Modified: Mon, 13 Jan 2020 15:59:19 GMT
X-Frame-Options: SAMEORIGIN
Content-Length: 2Schönen Restsonntag
Markus
ZitatIch frag mich nur, warum ohne das keepalive nicht bereits vorher nur einmal die DNS-Abfrage erfolgte und die weiteren 4 vom FHEM-DNS-Cache "beantwortet" wurden.
Kannst du das mit einem Log belegen?
Ich brauche etwas mit "attr global verbose 5", wo man auch "DNS result for..." Zeilen sieht, mit ttl.
mit verbose 5 (auch global) sehe ich weder DNS query, answer, result noch IP. kein einziges mal. :o Bei anderen Modulen sehe ich die. :-\
Ich sehe nur 5 requests in meinem pi-hole.
Vielleicht zur Info: blockingcall mit 5 blockingget auf die selbe Domain.
Sorry, habs vergessen zu sagen:
- "IP: name -> a.b.c.d" sieht man nur bei Http_NonblockingGet, falls verbose ueber $hash->{loglevel} (Voreinstellung ist 4)
- "DNS*" Meldungen nur bei gesetzten dnsServer Attribut, falls die Adressen nicht aus dem Cache (siehe ttl) beantwortet werden, global verbose 4/5
Hmm,
IP also nicht, da blockingget,
Aber trotz dnsServer=pi-hole=FHEM, nicht gecached(sonst würd ich sie ja nicht im pi-hole-Log sehen) und global verbose 5, nix zu sehen von DNS* ???
Zitat von: KölnSolar am 19 Januar 2020, 22:49:11
Hmm,
IP also nicht, da blockingget,
Aber trotz dnsServer=pi-hole=FHEM, nicht gecached(sonst würd ich sie ja nicht im pi-hole-Log sehen) und global verbose 5, nix zu sehen von DNS* ???
Du kannst auch einfach mal mit einem
{HttpUtils_dumpDnsCache()}checken, was im DNS Cache steht
Liebe Freeze-Freaks,
zwei Dinge:
1. Ich habe ein weiteres Attribut fm_catchHttp gebastelt, das versucht lang laufende Callback-Funktionen zu erkennen, als weiteren Schritt, "bad guys" zu identifizieren. Die Version läuft in meinem Produktivsystem und wenn sie bis morgen abend durchläuft ohne das System zu töten, würde ich sie morgen hier zum Test bereitstellen
2. Die Analyse von Freezes bzw. den Verursachern ist immernoch eklig und erfordert eine gewisse Erfahrung. Das würde ich gerne für den normalen Anwender vereinfachen. Mir schwebt eine "Analyze"-Funktion vor, die dem Anwender genauere Hinweise gibt, wo er mal schauen sollte und was er getrost ignorieren kann. Es gibt so ein paar Kandidaten, die permanent laufen (im Sekundentakt) und daher immer, oder sehr häufig als potentielle Freeze-Verursacher auftauchen, bei mir sind das aktuell:
HMLAN_KeepAliveCheck,HMLAN_KeepAlive,RESIDENTStk_DurationTimer,PRESENCE_StartLocalScan,MQTT2_SERVER_keepaliveChecker
Mich würde interessieren, welche weiteren von diesen "immer da" Prozessen ihr habt (also, was ihr in fm_whitelistSub eingetragen habt)
Danke,
Grüße,
Oli
ZitatIP also nicht, da blockingget,
Aber trotz dnsServer=pi-hole=FHEM, nicht gecached(sonst würd ich sie ja nicht im pi-hole-Log sehen) und global verbose 5, nix zu sehen von DNS*
Die HttpUtils eigene, nicht blockierende DNS-Aufloesung wird nur bei NonblockingGet aufgerufen: fuer BlockingGet sehe ich den Sinn nicht, und es waere aufwendig zu implementieren.
Zitatfuer BlockingGet sehe ich den Sinn nicht, und es waere aufwendig zu implementieren.
ich auch nicht. ;)
ZitatDie HttpUtils eigene, nicht blockierende DNS-Aufloesung wird nur bei NonblockingGet aufgerufen
diese klare Info fehlte halt nur. Also alles gut.
ZitatMich würde interessieren, welche weiteren von diesen "immer da" Prozessen ihr habt (also, was ihr in fm_whitelistSub eingetragen habt)
Nichts. Und ich bin aktuell runter auf threshold=0,3 ;D
ZitatDie Version läuft in meinem Produktivsystem und wenn sie bis morgen abend durchläuft ohne das System zu töten, würde ich sie morgen hier zum Test bereitstellen
Gerne auch vorher. Ich bin da auch nicht so ängstlich mit meinem Produktivsystem und heute bleibe ich "daneben" sitzen. :)
So, here we go, neue Version zum Testen.
* neues Attribut fm_catchHttp: echt hässliches Ding, aber scheint zu funktionieren... biegt beim Aufruf von HttpUtils_nonBlockingGet die callback-Funktion auf Freezemon um, Freezemon nimmt die Zeit und ruft dann die Originalfunktion auf
* altes Attribut fm_logExtraSeconds: wieder reaktiviert, erlaubt es zusätzliche Sekunden vor dem Freeze zu loggen
* Kleinkram
shutdown restart benötigt, reload reicht nicht (und rereadcfg traue ich nicht)
Dann bin ich mal so fei und probiere das aus ;)
Dann wieder "nur" get Log bei FreezeMon!?
Ohne irgendwas verbose bei global (steht verm. auf 3) oder beim echodevice (steht verm. auf 0 ;) ) zu drehen!?
Ergebnis dann im anderen Thread: https://forum.fhem.de/index.php/topic,107465.msg1015391.html#msg1015391
Danke, Joachim
ZitatOhne irgendwas verbose bei global (steht verm. auf 3) oder beim echodevice (steht verm. auf 0 ) zu drehen!?
Genau. Jetzt stehen fm_logExtraSeconds zusätzlich im freeze-log. Ich denke Du solltest es auf 3 setzen.
Klingt gut Oli. Danke.
Grüße Markus
Dann sollte ich es mit 5 ja richtig gemacht haben...
Bin aber nicht sicher, ob da wirklich mehr drin steht...
Siehe anderer Thread...
EDIT: oder soll ich den wieder "schließen" und (nur noch) hier weiter machen!?
Wir werden sehen... ;)
Gruß, Joachim
Wenn keine Einwände kommen, würde ich dann demnächst mal die Version aus dem Post oben (https://forum.fhem.de/index.php/topic,83909.msg1015390.html#msg1015390) im SVN einchecken...
Hi Oli,
wie kommt die freeze Dauer zustande ? Nur für mein Verständnis.
Die beiden blocking calls machen doch nix böses, oder ? Könnte man(also Du ;D) dann nicht deren Funktionen aus dem "possibly caused" rausnehmen ?
2020.04.19 18:35:35 3: [Freezemon] freezedetect: possible freeze starting at 18:35:35, delay is 0.474 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-USBWRF_GetUpdate(Fronius) tmr-GPIO4_DeviceUpdateLoop(RPi_OW_KS)
[Freezemon] freezedetect: possible freeze starting at 18:35:35, delay is 0.474 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-USBWRF_GetUpdate(Fronius) tmr-GPIO4_DeviceUpdateLoop(RPi_OW_KS)
2020.04.19 18:35:34.332 5: [echomaster] [echodevice_GetSettings] start refresh settings
2020.04.19 18:35:34.332 4: [echomaster] [echodevice_SendCommand] [getnotifications] START
2020.04.19 18:35:34.333 4: [echomaster] [echodevice_SendCommand] [getnotifications] PushToCmdQueue SendURL =https://layla.amazon.de/api/notifications
2020.04.19 18:35:34.333 4: [echomaster] [echodevice_SendCommand] [getnotifications] PushToCmdQueue SendData=
2020.04.19 18:35:34.334 4: [echomaster] [echodevice_HandleCmdQueue] [getnotifications] send command=https://layla.amazon.de/api/notifications Data=
2020.04.19 18:35:34.335 5: HttpUtils url=https://layla.amazon.de/api/notifications
2020.04.19 18:35:34.335 5: HttpUtils request header:
GET /api/notifications HTTP/1.1
Host: layla.amazon.de
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0
Accept-Language: de,en-US;q=0.7,en;q=0.3
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Cookie:meinCokie
csrf: -642580457
Content-Type: application/json; charset=UTF-8
2020.04.19 18:35:34.336 4: [echomaster] [echodevice_SendCommand] [alarmvolume] START
2020.04.19 18:35:34.336 4: [echomaster] [echodevice_SendCommand] [alarmvolume] PushToCmdQueue SendURL =https://layla.amazon.de/api/device-notification-state?_=1587314134
2020.04.19 18:35:34.336 4: [echomaster] [echodevice_SendCommand] [alarmvolume] PushToCmdQueue SendData=
2020.04.19 18:35:34.337 4: [echomaster] [echodevice_SendCommand] [bluetoothstate] START
2020.04.19 18:35:34.338 4: [echomaster] [echodevice_SendCommand] [bluetoothstate] PushToCmdQueue SendURL =https://layla.amazon.de/api/bluetooth?cached=true&_=1587314134
2020.04.19 18:35:34.338 4: [echomaster] [echodevice_SendCommand] [bluetoothstate] PushToCmdQueue SendData=
2020.04.19 18:35:34.339 4: [echomaster] [echodevice_SendCommand] [getdnd] START
2020.04.19 18:35:34.339 4: [echomaster] [echodevice_SendCommand] [getdnd] PushToCmdQueue SendURL =https://layla.amazon.de/api/dnd/device-status-list?_=1587314134
2020.04.19 18:35:34.339 4: [echomaster] [echodevice_SendCommand] [getdnd] PushToCmdQueue SendData=
2020.04.19 18:35:34.340 4: [echomaster] [echodevice_SendCommand] [wakeword] START
2020.04.19 18:35:34.341 4: [echomaster] [echodevice_SendCommand] [wakeword] PushToCmdQueue SendURL =https://layla.amazon.de/api/wake-word?_=1587314134
2020.04.19 18:35:34.341 4: [echomaster] [echodevice_SendCommand] [wakeword] PushToCmdQueue SendData=
2020.04.19 18:35:34.341 4: [echomaster] [echodevice_SendCommand] [listitems_task] START
2020.04.19 18:35:34.342 4: [echomaster] [echodevice_SendCommand] [listitems_task] PushToCmdQueue SendURL =https://layla.amazon.de/api/todos?size=100&startTime=&endTime=&completed=false&type=TASK&deviceSerialNumber=&deviceType=&_=1587314134
2020.04.19 18:35:34.342 4: [echomaster] [echodevice_SendCommand] [listitems_task] PushToCmdQueue SendData=TASK
2020.04.19 18:35:34.343 4: [echomaster] [echodevice_SendCommand] [listitems_shopping] START
2020.04.19 18:35:34.343 4: [echomaster] [echodevice_SendCommand] [listitems_shopping] PushToCmdQueue SendURL =https://layla.amazon.de/api/todos?size=100&startTime=&endTime=&completed=false&type=SHOPPING_ITEM&deviceSerialNumber=&deviceType=&_=1587314134
2020.04.19 18:35:34.343 4: [echomaster] [echodevice_SendCommand] [listitems_shopping] PushToCmdQueue SendData=SHOPPING_ITEM
2020.04.19 18:35:34.344 4: [echomaster] [echodevice_SendCommand] [getdevicesettings] START
2020.04.19 18:35:34.344 4: [echomaster] [echodevice_SendCommand] [getdevicesettings] PushToCmdQueue SendURL =https://layla.amazon.de/api/device-preferences
2020.04.19 18:35:34.344 4: [echomaster] [echodevice_SendCommand] [getdevicesettings] PushToCmdQueue SendData=
2020.04.19 18:35:34.345 4: [echomaster] [echodevice_SendCommand] [getisonline] START
2020.04.19 18:35:34.345 4: [echomaster] [echodevice_SendCommand] [getisonline] PushToCmdQueue SendURL =https://layla.amazon.de/api/devices-v2/device?cached=true&_=1587314134
2020.04.19 18:35:34.345 4: [echomaster] [echodevice_SendCommand] [getisonline] PushToCmdQueue SendData=
2020.04.19 18:35:34.346 4: [echomaster] [echodevice_SendCommand] [devicesstate] START
2020.04.19 18:35:34.347 4: [echomaster] [echodevice_SendCommand] [devicesstate] PushToCmdQueue SendURL =https://layla.amazon.de/api/devices-v2/device?cached=true&_=1587314134
2020.04.19 18:35:34.347 4: [echomaster] [echodevice_SendCommand] [devicesstate] PushToCmdQueue SendData=
2020.04.19 18:35:34.347 4: [echomaster] [echodevice_SendCommand] [account] START
2020.04.19 18:35:34.348 4: [echomaster] [echodevice_SendCommand] [account] PushToCmdQueue SendURL =https://alexa-comms-mobile-service.amazon.com/accounts
2020.04.19 18:35:34.348 4: [echomaster] [echodevice_SendCommand] [account] PushToCmdQueue SendData=
2020.04.19 18:35:34.349 4: [echomaster] [echodevice_SendLoginCommand] [cookielogin6]
2020.04.19 18:35:34.350 5: HttpUtils url=https://layla.amazon.de/api/bootstrap
2020.04.19 18:35:34.350 4: IP: layla.amazon.de -> 99.84.157.56
2020.04.19 18:35:34.352 5: [echomaster] [echodevice_GetSettings] refresh voice command
2020.04.19 18:35:34.352 4: [echomaster] [echodevice_SendCommand] [activities] START
2020.04.19 18:35:34.352 4: [echomaster] [echodevice_SendCommand] [activities] PushToCmdQueue SendURL =https://layla.amazon.de/api/activities?startTime=&size=50&offset=1&_=1587314134
2020.04.19 18:35:34.352 4: [echomaster] [echodevice_SendCommand] [activities] PushToCmdQueue SendData=
2020.04.19 18:35:34.353 4: [echomaster] [echodevice_SendCommand] [getbehavior] START
2020.04.19 18:35:34.354 4: [echomaster] [echodevice_SendCommand] [getbehavior] PushToCmdQueue SendURL =https://layla.amazon.de/api/behaviors/automations?limit=100
2020.04.19 18:35:34.354 4: [echomaster] [echodevice_SendCommand] [getbehavior] PushToCmdQueue SendData=
2020.04.19 18:35:34.354 4: [echomaster] [echodevice_SendCommand] [getsettingstraffic] START
2020.04.19 18:35:34.355 4: [echomaster] [echodevice_SendCommand] [getsettingstraffic] PushToCmdQueue SendURL =https://layla.amazon.de/api/traffic/settings
2020.04.19 18:35:34.355 4: [echomaster] [echodevice_SendCommand] [getsettingstraffic] PushToCmdQueue SendData=
2020.04.19 18:35:34.356 4: [echomaster] [echodevice_GetSettings] Timer INTERVAL = 60
2020.04.19 18:35:34.380 4: BlockingCall (Nina_Run): created child (16938), uses telnetForBlockingFn_1586790614 to connect back
2020.04.19 18:35:34.422 4: Connection accepted from telnetForBlockingFn_1586790614_127.0.0.1_40506
2020.04.19 18:35:34.426 5: Cmd: >{BlockingRegisterTelnet($cl,247973)}<
2020.04.19 18:35:35.424 5: HttpUtils request header:
GET /api/bootstrap HTTP/1.1
Host: layla.amazon.de
User-Agent: fhem
Accept-Encoding: gzip,deflate
Connection: Close
Cookie: meinCookie
2020.04.19 18:35:35.430 4: USBWRF device Fronius request message sent(hex): 8080800001011012
2020.04.19 18:35:35.430 5: SW: 8080800001011012
2020.04.19 18:35:35.432 4: USBWRF device Fronius request message sent(hex): 8080800001021013
2020.04.19 18:35:35.432 5: SW: 8080800001021013
2020.04.19 18:35:35.433 4: USBWRF device Fronius request message sent(hex): 8080800001011214
2020.04.19 18:35:35.433 5: SW: 8080800001011214
2020.04.19 18:35:35.434 4: USBWRF device Fronius request message sent(hex): 8080800001021215
2020.04.19 18:35:35.434 5: SW: 8080800001021215
2020.04.19 18:35:35.436 4: USBWRF device Fronius request message sent(hex): 8080800001011719
2020.04.19 18:35:35.436 5: SW: 8080800001011719
2020.04.19 18:35:35.437 4: USBWRF device Fronius request message sent(hex): 808080000102171a
2020.04.19 18:35:35.437 5: SW: 808080000102171a
2020.04.19 18:35:35.438 4: USBWRF device Fronius request message sent(hex): 808080000101181a
2020.04.19 18:35:35.439 5: SW: 808080000101181a
2020.04.19 18:35:35.440 4: USBWRF device Fronius request message sent(hex): 808080000102181b
2020.04.19 18:35:35.440 5: SW: 808080000102181b
2020.04.19 18:35:35.441 4: USBWRF device Fronius request message sent(hex): 8080800001013739
2020.04.19 18:35:35.441 5: SW: 8080800001013739
2020.04.19 18:35:35.443 4: USBWRF device Fronius request message sent(hex): 808080000102373a
2020.04.19 18:35:35.443 5: SW: 808080000102373a
2020.04.19 18:35:35.444 4: USBWRF Fronius timer set for automatic value requests, period: 60 seconds
2020.04.19 18:35:35.469 4: BlockingCall (GPIO4_Poll): created child (16939), uses telnetForBlockingFn_1586790614 to connect back
2020.04.19 18:35:35.476 5: [Freezemon] freezedetect: ----------- Starting Freeze handling at 2020.04.19 18:35:35.475 ---------------------
[Freezemon] freezedetect: possible freeze starting at 18:35:35, delay is 0.474 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-USBWRF_GetUpdate(Fronius) tmr-GPIO4_DeviceUpdateLoop(RPi_OW_KS)
=========================================================
Grüße Markus
Moin Markus,
Das müsstest du über White- bzw. Blacklist machen. Freezemon weiss ja nur, dass er nicht zur geplanten Zeit dran kam und diese 4 Kollegen vor ihm an der Reihe waren... Wenn du eine gute Idee hast, herauszufinden, wer harmlos ist, baue ich das gerne ein:-)
Grüße,
Oli
Kurz, weil mobil....
ZitatWenn du eine gute Idee hast, herauszufinden, wer harmlos ist, baue ich das gerne ein:-)
Ha, natürlich nicht auf Modulebene. Da ist sicherlich blacklist das Mittel. ;) Aber im konkreten Fall
Zitat.
.
.
2020.04.19 18:35:34.380 4: BlockingCall (Nina_Run): created child (16938), uses telnetForBlockingFn_1586790614 to connect back
2020.04.19 18:35:34.422 4: Connection accepted from telnetForBlockingFn_1586790614_127.0.0.1_40506
2020.04.19 18:35:34.426 5: Cmd: >{BlockingRegisterTelnet($cl,247973)}<
.
.
.
2020.04.19 18:35:35.469 4: BlockingCall (GPIO4_Poll): created child (16939), uses telnetForBlockingFn_1586790614 to connect back
.
.
.
ist es ja eine Ebene höher(tiefer ? :-\), der BlockingCall. Der ist ja erst einmal im Grundsatz unverdächtig/harmlos. Ließe der sich nicht generell wie blacklist behandeln ?
Ich versteh halt in dem Fall nicht, was da überhaupt geblocked haben soll und wieso 0,474 s ? Warum mag da das echodevice einen "Sprung" von 1s (zw. letztem Logging u. httputils[wieder das SSL-Thema ?])haben, obwohl der blockingcall dazwischen gefunkt hat.
Zitat2020.04.19 18:35:34.355 4: [echomaster] [echodevice_SendCommand] [getsettingstraffic] PushToCmdQueue SendData=
2020.04.19 18:35:34.356 4: [echomaster] [echodevice_GetSettings] Timer INTERVAL = 602020.04.19 18:35:34.380 4: BlockingCall (Nina_Run): created child (16938), uses telnetForBlockingFn_1586790614 to connect back
2020.04.19 18:35:34.422 4: Connection accepted from telnetForBlockingFn_1586790614_127.0.0.1_40506
2020.04.19 18:35:34.426 5: Cmd: >{BlockingRegisterTelnet($cl,247973)}<
2020.04.19 18:35:35.424 5: HttpUtils request header:
GET /api/bootstrap HTTP/1.1
Host: layla.amazon.de
User-Agent: fhem
Accept-Encoding: gzip,deflate
Connection: Close
Cookie: meinCookie
2020.04.19 18:35:35.430 4: USBWRF device Fronius request message sent(hex): 8080800001011012
Nimm mich bitte an die Hand, wenn Du etwas mehr Zeit hast, den Vorgang genauer zu analysieren.
Grüße Markus
Hi Oli,
Michael hatte dann doch ein spätes Einsehen und an einer Stelle noch ein keepalive ins echodevice eingebaut.
Ich bin jetzt runter auf TRESHOLD 0,2. Mal sehen, was nun so kommt. ;D
Vielleicht kannst Du mir bei Gelegenheit ja mal erklären, wie das gemeldete delay sich bestimmt. Da stolpere ich immer wieder drüber.
Grüße Markus
Hi, hab immer mal wieder so ein paar Meldungen, wie kann ich die noch beseitigen?
2020.06.07 00:00:30.466 1: [Freezemon] myFreezemon: possible freeze starting at 00:00:29, delay is 1.463 possibly caused by: fn-ReadFn(Myalexa)
2020.06.07 08:10:26.565 1: [Freezemon] myFreezemon: possible freeze starting at 08:10:21, delay is 5.562 possibly caused by: fn-ReadFn(WEBtablet_192.168.188.30_34902) fn-ReadFn(WEBtablet_192.168.188.30_34894) tmr-ENIGMA2_GetStatus(Uno_Schlafzimmer)
2020.06.07 10:02:29.485 1: [Freezemon] myFreezemon: possible freeze starting at 10:02:28, delay is 1.482 possibly caused by: fn-ReadFn(WEBtablet_192.168.188.30_36022)
2020.06.07 10:03:00.919 1: [Freezemon] myFreezemon: possible freeze starting at 10:02:42, delay is 18.916 possibly caused by: fn-ReadFn(WEBtablet_192.168.188.30_36020) fn-ReadFn(WEBtablet_192.168.188.30_36026)
2020.06.07 10:03:07.065 1: [Freezemon] myFreezemon: possible freeze starting at 10:03:04, delay is 3.063 possibly caused by: fn-ReadFn(WEBtablet_192.168.188.30_36026)
Danke
Moin,
die Webtablet Dinger kommen mit ziemlicher Sicherheit daher, dass du einen Raum aufrufst wo der Seitenaufbau lange braucht, z.B. wegen umfangreichen Plots. Damit musst du leben (oder die Plots optimieren, z.B. weniger Datenpunkte durch event-on-change-reading mit Threshold)
Grüße,
Oli
Kurz, weil mobil....
ZitatPlots optimieren, z.B. weniger Datenpunkte durch event-on-change-reading mit Threshold
Und/oder mit plotEmbed=2 / plotFork das Rendern vom Haupt-FHEM entkoppeln.
Zitat von: rudolfkoenig am 07 Juni 2020, 12:50:14
Und/oder mit plotEmbed=2 / plotFork das Rendern vom Haupt-FHEM entkoppeln.
Danke für den Tip, hab beides mal gesetzt und gefühlt wird die Seite jetzt deutlich schneller aufgerufen. Werd es mal im Auge behalten
Hallo Zusammen,
ich habe seit einiger Zeit die Fehlermeldung "cannot fork" im log. Nach einem Fhem Neustart kommt sie erstmal nicht mehr, aber nach ca. 2 Tagen kommt sie wieder und dann immer häufiger. Scheinbar gibt es also ein Speicherleck irgendwo und ich versuche dies mit Hilf evon freezemon herauszufinden.
Freezemon meldet mir nun als mögliche freezeDevices
tmr-CODE(0x72f6fa0)(ProcessRequestQueue) tmr-CODE(0x71f3138)(ResponseTimeout) tmr-CODE(0x71f3138)(ResponseTimeout) tmr-CODE(0x71f91c8)(GetUpdate) tmr-CODE(0x71f91c8)(GetUpdate)
Kann mir jemand sagen, was das bedeutet bzw. wie ich daraus die möglichlerweise verursachenden fhem devices herausfinden kann?
Damit lässt sich noch nicht viel anfangen.
Es sind timer, aber scheinbar aus Systemfunktionen(in den Klammern würde sonst ein echter devicename stehen).
nofork hast Du nicht im global device gesetzt ?
Mehr fällt mir erst einmal nicht ein.
Den freezes könntest Du über das zusätzliche Logfile im freezemon device auf die Spur kommen.
Grüße Markus
danke erstmal.
Nein, nofork habe ich nicht gesetzt.
Ich habe jetzt erstmal zwei zuletzt hinzugefügte devices disabled und beobachte 2 Tage, ob es an einem dieser beiden liegt. Falls das Problem bestehen bleibt, probiere ich mal mit dem vorgeschlagenem freezemon logfile mehr herauszufinden.
cannot fork ist leider erneut aufgetreten, die zwei disabled devices können also nicht die Ursache gewesen sein.
Man sieht, dass innerhalb von 2 Tagen die RAM-Nutzung ganz langsam ansteigt. Ich denke es muss also wohl irgendwo ein kleines Speicherleck geben.
Um dem auf die Spur zu kommen habe ich jetzt im freezemon das attr fm_logFile gesetzt und es wurden zwei Logfiles geschrieben zum Zeitpunkt des "cannot fork". Die Meldung kommt direkt nach dem PRESENCE-Modul (s.u.). Ist das ein Hinweis, dass es vom PRESENCE-Modul kommen könnte?
2022.08.30 20:45:04.646 4: PRESENCE (presence_raspcam2) - rescheduling next check in 10 seconds
2022.08.30 20:45:04.703 5: PRESENCE (presence_raspcam) - stopping timer
2022.08.30 20:45:04.704 5: PRESENCE (presence_raspcam) - starting blocking call for mode lan-ping
2022.08.30 20:45:04.734 1: Cannot fork: Cannot allocate memory
2022.08.30 20:45:04.735 1: Cannot fork: Cannot allocate memory
Der Blocking Call des PRESENCE-Moduls könnte aber auch nur das "Fass" zum Überlaufen gebracht haben (kein Speicher mehr) und das eigentliche Speicherleck ist in einem andern Modul. Nur wie bekomme ich den eigentlichen Verursacher heraus?
PRESENCE taucht in letzter Zeit gerne mal als "Störenfried" auf.
Ansonsten kann ich Deiner Analyse nur zustimmen ohne eine Idee zu haben, wie Du dem Verursacher auf die Spur kommen kannst. Siehst Du im System(sudo ps -e) "verstorbene" FHEM-Prozesse ?
Ich würde das ganze zu Fuß analysieren.
Der RAM wird sicherlich halbwegs stetig anwachsen, ich würde ihn loggen und im Plot angucken.
Dann hast du grob ein Gefühl für die Steigung und kannst nach und nach einzelne devices disablen bis der Anstieg aufhört. Also immer nur 1 device pro 3 Std oder so disablen. Dabei würde ich mit den Exoten anfangen, also doif, at etc würde ich erst einmal ignorieren und eher sowas wie alexa, telegram, httpmod am anfang ins visier nehmen.
Ja, die RAM Nutzung zeichne ich auf und es ist ein ganz langsamer Anstieg zu sehen über mehrere Tage (s. Bilder).
Wie erkenne ich denn verstorbene Prozesse? Sudo ps -e zeigt alle Prozesse. Ein Top sortiert nach Memory-Bedarf (Shift-M) sieht für mich nicht nach einem verstorbenen Prozess aus (siehe Screenshot).
Ich überlege schon auf den Raspi 4 mit 8 GB RAM umzusteigen. Vermutlich ist mein Raspi 3 mit 1 GB auch mit meiner fhem Installation langsam überfordert. HAbe >1200 devices.
Du siehst ja die pid, aus der auf das Alter schließen lässt.
Dein top zeigt meines Erachtens uralte Prozesse. Mit kill bekommst Du sie weg. Wie Du dann das forking monitoren kannst weiß ich aber auch nicht. Vielleicht mal einen neuen Thread aufmachen, dass die Spezies aufmerksam werden ?
ZitatIch überlege schon auf den Raspi 4 mit 8 GB RAM umzusteigen. Vermutlich ist mein Raspi 3 mit 1 GB auch mit meiner fhem Installation langsam überfordert. HAbe >1200 devices.
Ich denke eher, dass es ein anderes Problem ist.
Ich hätte ehrlich gesagt mit einem steileren Anstieg gerechnet. Sieht fast so aus, als wäre RAM gar nicht dein eigentliches Problem.
Guck doch mal wie viele fhem prozesse du hast, zb so
sudo ps aux | grep fhem.pl | wc -l
Ach und einen kannst da abziehen beim Ergebnis, weil der grep sich selbst findet.
Ich denke auch nicht dass ein neuer Pi dein Problem wirklich lösen wird, der wird höchstens länger durchhalten
Es gab hier im Forum ein Bericht, dass das FREEZEMON Modul selbst zu Speicherverlust fuehrt, weiss aber nicht mehr wo. Das Modul bietet mW keine Moeglichkeit, die Ursache des Speicherlochs festzustellen, ich weiss nach etlichen Versuchen auch nicht, wie man das Suchen nach der Ursache benutzerfreundlich gestalten koennte.
FHEM verwendet fork fuer parallelisiertes Rechnen (z.Bsp. bei der Erstellung der SVGs), und zum Vermeiden der Blockierung (z.Bsp. per BlockingCall). Der urspruengliche fork() Aufruf hat den kompletten Speicherbereich des Aufrufers dupliziert. In modernen Systemen ist das deutlich komplizierter, es bedeutet aber weiterhin das Reservieren von zusaetzlichen RAM, dessen Groesse vom Aufrufer abhaengt.
D.h. je groesser FHEM vor dem fork() ist, desto eher gibt es Probleme beim fork().
Da der Speicher wahrscheinlich nur reserviert, aber nicht verwendet wird, koennte das Einrichten eines (groesseren) swap Bereiches, oder das Aendern des Reservierungsfaktors (Stichwort overcommit, eher was fuer Experten) helfen. Das ist keine Loesung, nur ein Workaround, der das Unvermeidbare verschiebt.
Genauso wie der Kauf eines Rechners mit mehr RAM.
Eine Frage: Ich habe sehr viele presence / lan-ping devices. Macht es Sinn bzw. ist es möglich, die BlockingCalls von solchen devices wie presence irgendwie möglichst gleichmäßig zeitlich zu verteilen, damit nicht alle gleichzeitig forken / Speicher anfragen?
Man könnte es manuell über ein alignTime attr machen, wäre aber aufwändig und ist auch glaube ich nicht vorgesehen im presence modul. Oder kann das fhem irgendwie automatisch?
Brauchst du denn wirklich so viele pings und reicht es nicht wenn sie seltener laufen?
Bzw. Bist du nicht mit nmap oder Zugriff auf fritz box besser dran?
ZitatEine Frage: Ich habe sehr viele presence / lan-ping devices. Macht es Sinn bzw. ist es möglich, die BlockingCalls von solchen devices wie presence irgendwie möglichst gleichmäßig zeitlich zu verteilen, damit nicht alle gleichzeitig forken / Speicher anfragen?
Es gibt ein global Attribut blockingCallMax (Voreinstellung 32), was die Anzahl dieser Prozesse begrenzt.
Ueberzaehlige Aufrufe werden in eine Warteschlange gesteckt.
Beobachten kann man die Schlange mit dem FHEM Befehl blockinginfo, er ist nur vorhanden, wenn BlockingCall schon verwendet wurde.
Zitat von: FhemPiUser am 31 August 2022, 17:40:34
Eine Frage: Ich habe sehr viele presence / lan-ping devices.
Es gibt da eine "inoffizielle" Variante: https://forum.fhem.de/index.php?topic=117007.0
die genau das besser macht!
Die habe ich quasi seit sie existiert, erfolgreich mit vielen lan-ping im Einsatz.
gb#
Ich habe jetzt durch Ausprobieren bzw. disablen der zuletzt angelegten devices folgenden Zusammenhang zwischen steigender RAM-Nutzung / cannot-fork-Fehlermeldungen erkannt:
Ich habe 4-5 Tage 2 modbusattr relay devices disabled laufen lassen -> Keine steigende RAM-Nutzung. Gestern habe ich dann die beiden modbusattr relay devices wieder enabled -> heute steigende RAM-Nutzung und cannot fork. Sonst habe ich nichts verändert. Ich habe noch 2 weitere mobusattr devices, die nicht im relay-Modus laufen. Die liefen die ganze Zeit durch ohne steigend RAM-Nutzung.
Das klingt für mich danach, dass die beiden modbusattr relay devices irgendetwas mit dem Speicherleck/steigenen RAM-Bedarf zu tun haben. Die beiden modbusattr relay devices werden von evcc (https://evcc.io/ (https://evcc.io/)) genutzt, um über den relay per modbus mit 2 Sungrow SH10RT Wechselrichtern zu sprechen (die jeweils nur einen modbus client erlauben) und das funktioniert sonst auch gut. Ich bin absoluter Fan vom modbusattr device im relay modus und würde es gerne weiter verwenden. Momentan muss ich leider fhem alle 2-3 Tage neu starten aufgrund des Speicherlecks. Den Modulentwiockler StefanStrobl habe ich bereits informiert.
Die modbusattr relay devices sind wie folgt definiert:
defmod SH10rt_1_relay ModbusAttr 11 relay 192.168.1.xx:1502 TCP to SH10rt_1
defmod SH10rt_2_relay ModbusAttr 11 relay 192.168.1.xx:1503 TCP to SH10rt_2
Die modbusattr devices sind wie folgt definiert:
defmod SH10rt_1 ModbusAttr 1 30 192.168.3.xxx:502 TCP
defmod SH10rt_2 ModbusAttr 1 30 192.168.3.xxx:502 TCP
Letztere haben allerdings jeweils sehr viele modbus Attribute (>1200 attr Zeilen). Ich könnte mir vorstellen, dass dadurch ein sehr kleines Speicherleck bei mir auffällt, was bei anderen mit wenigen modbus Attributen nicht auffällt.
Oder kann es daran liegen, dass einige requests vom Wechselrichter nicht beantwortet werden (ist leider eine schlechte modbus-Implementierung im Wechselrichter SH10RT) und dadurch states im relay "hängen" bleiben?
Die modbusattr relay devices haben außerdem folgenden stacktrace als Reading:
TcpServer_Close:1712 Modbus::DoClose:903 Modbus::SetLDInactive:881 Modbus::AttrLDFn:3955 CallFn:3178 CommandAttr:1274 AnalyzeCommand:2806 FW_fC:984 FW_answerCall:609 FW_Read:3955 CallFn:782
Hat noch jemand eine Idee oder kann ich noch irgendetwas tun, um der Ursache und der Lösung auf die Spur zu kommen?
P.S.: Danke Benni für den Tipp mit den presence-devices. Schaue ich mir mal an zur Optimierung, die presence devcies scheinen aber nichts mit meinem Speicherleck-Problem zu tun zu haben.
ZitatDie modbusattr relay devices haben außerdem folgenden stacktrace als Reading:
Hier wurde leider das Wesentliche an der Fehlermeldung weggelassen, das ist vmtl. eine Zeile mit WARNING davor.
Wir wissen jetzt wo das Problem ausgeloest wurde, aber nicht, was das Problem ist.
Zum Thema Speicherleck habe ich leider keine Idee.
danke, ich warte mal auf den nächsten error, dann poste ich das ganze stacktrace nochmal.
Ich habe erstmal kurz mit verbose 5 beim modbusattr relay mitgeloggt - falls es hilft.
Da kommt öfter "read from TCP server connection got null -> closing" und "_UnDef is closing SH10rt_1_relay" nach dem send. Ich weiß nicht, ob das relevant ist...
022.09.05 12:24:54.222 5: SH10rt_1_relay: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo inactive active
2022.09.05 12:24:54.223 5: SH10rt_1_relay: UpdateSetList: getList=
2022.09.05 12:24:55.431 4: Connection accepted from SH10rt_1_relay_192.168.x.x_48796
2022.09.05 12:24:55.432 4: SH10rt_1_relay: HandleServerConnection accepted new TCP connection as device SH10rt_1_relay_192.168.x.x_48796
2022.09.05 12:24:55.807 5: SH10rt_1_relay_192.168.x.x_48796: readFn buffer: 0988000000060b0413980002
2022.09.05 12:24:55.809 5: SH10rt_1_relay_192.168.x.x_48796: ParseFrameStart called from ReadFn
2022.09.05 12:24:55.810 4: SH10rt_1_relay_192.168.x.x_48796: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 2440, dlen 6 and potential data 13980002
2022.09.05 12:24:55.811 5: SH10rt_1_relay_192.168.x.x_48796: HandleRequest called from ReadFn
2022.09.05 12:24:55.812 5: SH10rt_1_relay_192.168.x.x_48796: ParseRequest called from HandleRequest
2022.09.05 12:24:55.813 4: SH10rt_1_relay_192.168.x.x_48796: HandleRequest, current frame / read buffer: 0988000000060b0413980002, id 11, fCode 4, tid 2440,
request: id 11 fc 4 i5016, len 2, tid 2440
2022.09.05 12:24:55.815 4: SH10rt_1_relay_192.168.x.x_48796: RelayRequest called from HandleRequest
2022.09.05 12:24:55.816 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 12:24:55.817 4: SH10rt_1_relay_192.168.x.x_48796: RelayRequest via SH10rt_1, Proto TCP with id 1, current frame / read buffer: 0988000000060b0413980002, id 11, fCode 4, tid 2440,
request: id 11 fc 4 i5016, len 2, tid 2440, for relay device SH10rt_1_relay_192.168.x.x_48796
2022.09.05 12:24:55.827 4: SH10rt_1_relay_192.168.x.x_48796: HandleRequest Done, current frame / read buffer: 0988000000060b0413980002, id 11, fCode 4, tid 2440,
request: id 11 fc 4 i5016, len 2, tid 2440, for relay device SH10rt_1_relay_192.168.x.x_48796
2022.09.05 12:24:55.828 5: SH10rt_1_relay_192.168.x.x_48796: DropFrame called from ReadFn - drop 0988000000060b0413980002
2022.09.05 12:24:56.089 3: SH10rt_1_relay_192.168.x.x_48796: read from TCP server connection got null -> closing
2022.09.05 12:24:56.089 3: SH10rt_1_relay_192.168.x.x_48796: _UnDef is closing SH10rt_1_relay_192.168.x.x_48796
2022.09.05 12:24:56.090 5: SH10rt_1_relay_192.168.x.x_48796: Close called from UndefLDFn with noState and noDelete
2022.09.05 12:24:56.090 4: SH10rt_1_relay_192.168.x.x_48796: Close TCP server listening connection and delete hash
2022.09.05 12:24:56.270 5: SH10rt_1_relay_192.168.x.x_48796: Close is removing lastconn from parent device SH10rt_1_relay
2022.09.05 12:24:56.461 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 1d130000, type i, adr 5016
2022.09.05 12:24:56.461 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 1d130000, type i, adr 5016, valuesLen 2
2022.09.05 12:24:56.461 5: SH10rt_1_relay: SplitDataString has no information about handling i5016
2022.09.05 12:24:56.462 5: SH10rt_1_relay: SplitDataString has no information about handling i5017
2022.09.05 12:24:56.462 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 12:24:56.462 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 12:24:56.463 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 12:24:56.463 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Modbus.pm line 3067.
2022.09.05 12:24:56.464 1: PERL WARNING: Use of uninitialized value $proto in string eq at ./FHEM/98_Modbus.pm line 3694.
2022.09.05 12:24:56.464 1: PERL WARNING: Use of uninitialized value $proto in string eq at ./FHEM/98_Modbus.pm line 3698.
2022.09.05 12:24:56.464 1: PERL WARNING: Use of uninitialized value $proto in string eq at ./FHEM/98_Modbus.pm line 3703.
2022.09.05 12:24:56.464 1: PERL WARNING: Use of uninitialized value $proto in concatenation (.) or string at ./FHEM/98_Modbus.pm line 3709.
2022.09.05 12:24:56.592 4: Connection accepted from SH10rt_1_relay_192.168.x.x_48798
2022.09.05 12:24:56.592 4: SH10rt_1_relay: HandleServerConnection accepted new TCP connection as device SH10rt_1_relay_192.168.x.x_48798
2022.09.05 12:24:56.751 5: SH10rt_1_relay_192.168.x.x_48798: readFn buffer: 0989000000060b0413980002
2022.09.05 12:24:56.752 5: SH10rt_1_relay_192.168.x.x_48798: ParseFrameStart called from ReadFn
2022.09.05 12:24:56.752 4: SH10rt_1_relay_192.168.x.x_48798: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 2441, dlen 6 and potential data 13980002
2022.09.05 12:24:56.752 5: SH10rt_1_relay_192.168.x.x_48798: HandleRequest called from ReadFn
2022.09.05 12:24:56.753 5: SH10rt_1_relay_192.168.x.x_48798: ParseRequest called from HandleRequest
2022.09.05 12:24:56.753 4: SH10rt_1_relay_192.168.x.x_48798: HandleRequest, current frame / read buffer: 0989000000060b0413980002, id 11, fCode 4, tid 2441,
request: id 11 fc 4 i5016, len 2, tid 2441
2022.09.05 12:24:56.753 4: SH10rt_1_relay_192.168.x.x_48798: RelayRequest called from HandleRequest
2022.09.05 12:24:56.754 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 12:24:56.754 4: SH10rt_1_relay_192.168.x.x_48798: RelayRequest via SH10rt_1, Proto TCP with id 1, current frame / read buffer: 0989000000060b0413980002, id 11, fCode 4, tid 2441,
request: id 11 fc 4 i5016, len 2, tid 2441, for relay device SH10rt_1_relay_192.168.x.x_48798
2022.09.05 12:24:56.760 4: SH10rt_1_relay_192.168.x.x_48798: HandleRequest Done, current frame / read buffer: 0989000000060b0413980002, id 11, fCode 4, tid 2441,
request: id 11 fc 4 i5016, len 2, tid 2441, for relay device SH10rt_1_relay_192.168.x.x_48798
2022.09.05 12:24:56.760 5: SH10rt_1_relay_192.168.x.x_48798: DropFrame called from ReadFn - drop 0989000000060b0413980002
2022.09.05 12:24:56.993 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 1d140000, type i, adr 5016
2022.09.05 12:24:56.994 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 1d140000, type i, adr 5016, valuesLen 2
2022.09.05 12:24:56.994 5: SH10rt_1_relay: SplitDataString has no information about handling i5016
2022.09.05 12:24:56.994 5: SH10rt_1_relay: SplitDataString has no information about handling i5017
2022.09.05 12:24:56.995 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 12:24:56.995 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 12:24:56.995 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 12:24:56.996 5: SH10rt_1_relay_192.168.x.x_48798: Send called from RelayResponse
2022.09.05 12:24:56.996 4: SH10rt_1_relay_192.168.x.x_48798: Send 0989000000070b04041d140000
2022.09.05 12:24:57.089 5: SH10rt_1_relay_192.168.x.x_48798: readFn buffer: 098a000000060b0432dd0001
2022.09.05 12:24:57.090 5: SH10rt_1_relay_192.168.x.x_48798: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 12:24:57.090 4: SH10rt_1_relay_192.168.x.x_48798: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 2442, dlen 6 and potential data 32dd0001
2022.09.05 12:24:57.090 5: SH10rt_1_relay_192.168.x.x_48798: HandleRequest called from ReadFn
2022.09.05 12:24:57.090 5: SH10rt_1_relay_192.168.x.x_48798: ParseRequest called from HandleRequest
2022.09.05 12:24:57.091 4: SH10rt_1_relay_192.168.x.x_48798: HandleRequest, current frame / read buffer: 098a000000060b0432dd0001, id 11, fCode 4, tid 2442,
request: id 11 fc 4 i13021, len 1, tid 2442
2022.09.05 12:24:57.091 4: SH10rt_1_relay_192.168.x.x_48798: RelayRequest called from HandleRequest
2022.09.05 12:24:57.091 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 12:24:57.092 4: SH10rt_1_relay_192.168.x.x_48798: RelayRequest via SH10rt_1, Proto TCP with id 1, current frame / read buffer: 098a000000060b0432dd0001, id 11, fCode 4, tid 2442,
request: id 11 fc 4 i13021, len 1, tid 2442, for relay device SH10rt_1_relay_192.168.x.x_48798
2022.09.05 12:24:57.097 4: SH10rt_1_relay_192.168.x.x_48798: HandleRequest Done, current frame / read buffer: 098a000000060b0432dd0001, id 11, fCode 4, tid 2442,
request: id 11 fc 4 i13021, len 1, tid 2442, for relay device SH10rt_1_relay_192.168.x.x_48798
2022.09.05 12:24:57.098 5: SH10rt_1_relay_192.168.x.x_48798: DropFrame called from ReadFn - drop 098a000000060b0432dd0001
2022.09.05 12:24:57.102 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 07e2, type i, adr 13021
2022.09.05 12:24:57.102 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 07e2, type i, adr 13021, valuesLen 1
2022.09.05 12:24:57.103 5: SH10rt_1_relay: SplitDataString has no information about handling i13021
2022.09.05 12:24:57.103 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 12:24:57.103 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 12:24:57.103 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 12:24:57.104 5: SH10rt_1_relay_192.168.x.x_48798: Send called from RelayResponse
2022.09.05 12:24:57.104 4: SH10rt_1_relay_192.168.x.x_48798: Send 098a000000050b040207e2
2022.09.05 12:24:57.110 5: SH10rt_1_relay_192.168.x.x_48798: readFn buffer: 098b000000060b0432c80001
2022.09.05 12:24:57.110 5: SH10rt_1_relay_192.168.x.x_48798: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 12:24:57.110 4: SH10rt_1_relay_192.168.x.x_48798: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 2443, dlen 6 and potential data 32c80001
2022.09.05 12:24:57.111 5: SH10rt_1_relay_192.168.x.x_48798: HandleRequest called from ReadFn
2022.09.05 12:24:57.111 5: SH10rt_1_relay_192.168.x.x_48798: ParseRequest called from HandleRequest
2022.09.05 12:24:57.111 4: SH10rt_1_relay_192.168.x.x_48798: HandleRequest, current frame / read buffer: 098b000000060b0432c80001, id 11, fCode 4, tid 2443,
request: id 11 fc 4 i13000, len 1, tid 2443
2022.09.05 12:24:57.112 4: SH10rt_1_relay_192.168.x.x_48798: RelayRequest called from HandleRequest
2022.09.05 12:24:57.112 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 12:24:57.112 4: SH10rt_1_relay_192.168.x.x_48798: RelayRequest via SH10rt_1, Proto TCP with id 1, current frame / read buffer: 098b000000060b0432c80001, id 11, fCode 4, tid 2443,
request: id 11 fc 4 i13000, len 1, tid 2443, for relay device SH10rt_1_relay_192.168.x.x_48798
2022.09.05 12:24:57.205 4: SH10rt_1_relay_192.168.x.x_48798: HandleRequest Done, current frame / read buffer: 098b000000060b0432c80001, id 11, fCode 4, tid 2443,
request: id 11 fc 4 i13000, len 1, tid 2443, for relay device SH10rt_1_relay_192.168.x.x_48798
2022.09.05 12:24:57.206 5: SH10rt_1_relay_192.168.x.x_48798: DropFrame called from ReadFn - drop 098b000000060b0432c80001
2022.09.05 12:24:57.211 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 0000, type i, adr 13000
2022.09.05 12:24:57.211 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 0000, type i, adr 13000, valuesLen 1
2022.09.05 12:24:57.211 5: SH10rt_1_relay: SplitDataString has no information about handling i13000
2022.09.05 12:24:57.211 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 12:24:57.212 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 12:24:57.212 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 12:24:57.213 5: SH10rt_1_relay_192.168.x.x_48798: Send called from RelayResponse
2022.09.05 12:24:57.213 4: SH10rt_1_relay_192.168.x.x_48798: Send 098b000000050b04020000
2022.09.05 12:24:57.218 5: SH10rt_1_relay_192.168.x.x_48798: readFn buffer: 098c000000060b0432c80001
2022.09.05 12:24:57.219 5: SH10rt_1_relay_192.168.x.x_48798: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 12:24:57.219 4: SH10rt_1_relay_192.168.x.x_48798: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 2444, dlen 6 and potential data 32c80001
2022.09.05 12:24:57.219 5: SH10rt_1_relay_192.168.x.x_48798: HandleRequest called from ReadFn
2022.09.05 12:24:57.220 5: SH10rt_1_relay_192.168.x.x_48798: ParseRequest called from HandleRequest
2022.09.05 12:24:57.220 4: SH10rt_1_relay_192.168.x.x_48798: HandleRequest, current frame / read buffer: 098c000000060b0432c80001, id 11, fCode 4, tid 2444,
request: id 11 fc 4 i13000, len 1, tid 2444
2022.09.05 12:24:57.220 4: SH10rt_1_relay_192.168.x.x_48798: RelayRequest called from HandleRequest
2022.09.05 12:24:57.221 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 12:24:57.221 4: SH10rt_1_relay_192.168.x.x_48798: RelayRequest via SH10rt_1, Proto TCP with id 1, current frame / read buffer: 098c000000060b0432c80001, id 11, fCode 4, tid 2444,
request: id 11 fc 4 i13000, len 1, tid 2444, for relay device SH10rt_1_relay_192.168.x.x_48798
2022.09.05 12:24:57.313 4: SH10rt_1_relay_192.168.x.x_48798: HandleRequest Done, current frame / read buffer: 098c000000060b0432c80001, id 11, fCode 4, tid 2444,
request: id 11 fc 4 i13000, len 1, tid 2444, for relay device SH10rt_1_relay_192.168.x.x_48798
2022.09.05 12:24:57.313 5: SH10rt_1_relay_192.168.x.x_48798: DropFrame called from ReadFn - drop 098c000000060b0432c80001
2022.09.05 12:24:57.318 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 0000, type i, adr 13000
2022.09.05 12:24:57.318 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 0000, type i, adr 13000, valuesLen 1
2022.09.05 12:24:57.318 5: SH10rt_1_relay: SplitDataString has no information about handling i13000
2022.09.05 12:24:57.319 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 12:24:57.319 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 12:24:57.319 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 12:24:57.320 5: SH10rt_1_relay_192.168.x.x_48798: Send called from RelayResponse
2022.09.05 12:24:57.320 4: SH10rt_1_relay_192.168.x.x_48798: Send 098c000000050b04020000
2022.09.05 12:24:57.326 5: SH10rt_1_relay_192.168.x.x_48798: readFn buffer: 098d000000060b0432d10002
2022.09.05 12:24:57.326 5: SH10rt_1_relay_192.168.x.x_48798: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 12:24:57.326 4: SH10rt_1_relay_192.168.x.x_48798: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 2445, dlen 6 and potential data 32d10002
2022.09.05 12:24:57.327 5: SH10rt_1_relay_192.168.x.x_48798: HandleRequest called from ReadFn
2022.09.05 12:24:57.327 5: SH10rt_1_relay_192.168.x.x_48798: ParseRequest called from HandleRequest
2022.09.05 12:24:57.327 4: SH10rt_1_relay_192.168.x.x_48798: HandleRequest, current frame / read buffer: 098d000000060b0432d10002, id 11, fCode 4, tid 2445,
request: id 11 fc 4 i13009, len 2, tid 2445
2022.09.05 12:24:57.328 4: SH10rt_1_relay_192.168.x.x_48798: RelayRequest called from HandleRequest
2022.09.05 12:24:57.328 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 12:24:57.328 4: SH10rt_1_relay_192.168.x.x_48798: RelayRequest via SH10rt_1, Proto TCP with id 1, current frame / read buffer: 098d000000060b0432d10002, id 11, fCode 4, tid 2445,
request: id 11 fc 4 i13009, len 2, tid 2445, for relay device SH10rt_1_relay_192.168.x.x_48798
2022.09.05 12:24:57.420 4: SH10rt_1_relay_192.168.x.x_48798: HandleRequest Done, current frame / read buffer: 098d000000060b0432d10002, id 11, fCode 4, tid 2445,
request: id 11 fc 4 i13009, len 2, tid 2445, for relay device SH10rt_1_relay_192.168.x.x_48798
2022.09.05 12:24:57.420 5: SH10rt_1_relay_192.168.x.x_48798: DropFrame called from ReadFn - drop 098d000000060b0432d10002
2022.09.05 12:24:57.440 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 02470000, type i, adr 13009
2022.09.05 12:24:57.441 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 02470000, type i, adr 13009, valuesLen 2
2022.09.05 12:24:57.441 5: SH10rt_1_relay: SplitDataString has no information about handling i13009
2022.09.05 12:24:57.441 5: SH10rt_1_relay: SplitDataString has no information about handling i13010
2022.09.05 12:24:57.442 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 12:24:57.442 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 12:24:57.442 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 12:24:57.443 5: SH10rt_1_relay_192.168.x.x_48798: Send called from RelayResponse
2022.09.05 12:24:57.443 4: SH10rt_1_relay_192.168.x.x_48798: Send 098d000000070b040402470000
2022.09.05 12:24:57.449 5: SH10rt_1_relay_192.168.x.x_48798: readFn buffer: 098e000000060b0432de0001
2022.09.05 12:24:57.449 5: SH10rt_1_relay_192.168.x.x_48798: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 12:24:57.449 4: SH10rt_1_relay_192.168.x.x_48798: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 2446, dlen 6 and potential data 32de0001
2022.09.05 12:24:57.450 5: SH10rt_1_relay_192.168.x.x_48798: HandleRequest called from ReadFn
2022.09.05 12:24:57.450 5: SH10rt_1_relay_192.168.x.x_48798: ParseRequest called from HandleRequest
2022.09.05 12:24:57.450 4: SH10rt_1_relay_192.168.x.x_48798: HandleRequest, current frame / read buffer: 098e000000060b0432de0001, id 11, fCode 4, tid 2446,
request: id 11 fc 4 i13022, len 1, tid 2446
2022.09.05 12:24:57.451 4: SH10rt_1_relay_192.168.x.x_48798: RelayRequest called from HandleRequest
2022.09.05 12:24:57.451 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 12:24:57.451 4: SH10rt_1_relay_192.168.x.x_48798: RelayRequest via SH10rt_1, Proto TCP with id 1, current frame / read buffer: 098e000000060b0432de0001, id 11, fCode 4, tid 2446,
request: id 11 fc 4 i13022, len 1, tid 2446, for relay device SH10rt_1_relay_192.168.x.x_48798
2022.09.05 12:24:57.528 4: SH10rt_1_relay_192.168.x.x_48798: HandleRequest Done, current frame / read buffer: 098e000000060b0432de0001, id 11, fCode 4, tid 2446,
request: id 11 fc 4 i13022, len 1, tid 2446, for relay device SH10rt_1_relay_192.168.x.x_48798
2022.09.05 12:24:57.529 5: SH10rt_1_relay_192.168.x.x_48798: DropFrame called from ReadFn - drop 098e000000060b0432de0001
2022.09.05 12:24:57.535 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 0348, type i, adr 13022
2022.09.05 12:24:57.535 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 0348, type i, adr 13022, valuesLen 1
2022.09.05 12:24:57.535 5: SH10rt_1_relay: SplitDataString has no information about handling i13022
2022.09.05 12:24:57.535 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 12:24:57.536 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 12:24:57.536 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 12:24:57.537 5: SH10rt_1_relay_192.168.x.x_48798: Send called from RelayResponse
2022.09.05 12:24:57.537 4: SH10rt_1_relay_192.168.x.x_48798: Send 098e000000050b04020348
2022.09.05 12:25:02.455 3: SH10rt_1_relay_192.168.x.x_48798: read from TCP server connection got null -> closing
2022.09.05 12:25:02.456 3: SH10rt_1_relay_192.168.x.x_48798: _UnDef is closing SH10rt_1_relay_192.168.x.x_48798
2022.09.05 12:25:02.456 5: SH10rt_1_relay_192.168.x.x_48798: Close called from UndefLDFn with noState and noDelete
2022.09.05 12:25:02.456 4: SH10rt_1_relay_192.168.x.x_48798: Close TCP server listening connection and delete hash
2022.09.05 12:25:02.625 5: SH10rt_1_relay_192.168.x.x_48798: Close is removing lastconn from parent device SH10rt_1_relay
2022.09.05 12:25:05.029 4: Connection accepted from SH10rt_1_relay_192.168.x.x_48862
2022.09.05 12:25:05.029 4: SH10rt_1_relay: HandleServerConnection accepted new TCP connection as device SH10rt_1_relay_192.168.x.x_48862
2022.09.05 12:25:05.104 5: SH10rt_1_relay_192.168.x.x_48862: readFn buffer: 098f000000060b0413980002
2022.09.05 12:25:05.104 5: SH10rt_1_relay_192.168.x.x_48862: ParseFrameStart called from ReadFn
2022.09.05 12:25:05.105 4: SH10rt_1_relay_192.168.x.x_48862: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 2447, dlen 6 and potential data 13980002
2022.09.05 12:25:05.105 5: SH10rt_1_relay_192.168.x.x_48862: HandleRequest called from ReadFn
2022.09.05 12:25:05.105 5: SH10rt_1_relay_192.168.x.x_48862: ParseRequest called from HandleRequest
2022.09.05 12:25:05.106 4: SH10rt_1_relay_192.168.x.x_48862: HandleRequest, current frame / read buffer: 098f000000060b0413980002, id 11, fCode 4, tid 2447,
request: id 11 fc 4 i5016, len 2, tid 2447
2022.09.05 12:25:05.106 4: SH10rt_1_relay_192.168.x.x_48862: RelayRequest called from HandleRequest
2022.09.05 12:25:05.107 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 12:25:05.107 5: SH10rt_1_relay: CreateResponse called from RelayRequest ErrCode=6
2022.09.05 12:25:05.108 5: SH10rt_1_relay: CreateResponse calls PackFrame to prepare response pdu
2022.09.05 12:25:05.108 5: SH10rt_1_relay_192.168.x.x_48862: PackResponse called from CreateResponse
2022.09.05 12:25:05.115 4: SH10rt_1_relay: CreateResponse sends response: id 11, fc 132, error code 6, i5016, len 2, tid 2447, device SH10rt_1_relay (TCP), pdu 8406, V 4.4.04 - 17.7.2021
2022.09.05 12:25:05.116 5: SH10rt_1_relay_192.168.x.x_48862: Send called from CreateResponse
2022.09.05 12:25:05.116 4: SH10rt_1_relay_192.168.x.x_48862: Send 098f000000030b8406
2022.09.05 12:25:05.117 4: SH10rt_1_relay_192.168.x.x_48862: HandleRequest Done, error: relay forward path busy, current frame / read buffer: 098f000000060b0413980002, id 11, fCode 4, tid 2447,
request: id 11 fc 4 i5016, len 2, tid 2447, for relay device SH10rt_1_relay_192.168.x.x_48862,
response: id 11, fc 132, error code 6, i5016, len 2, tid 2447, error: relay forward path busy
2022.09.05 12:25:05.117 5: SH10rt_1_relay_192.168.x.x_48862: DropFrame called from ReadFn - drop 098f000000060b0413980002
2022.09.05 12:25:05.167 3: SH10rt_1_relay_192.168.x.x_48862: read from TCP server connection got null -> closing
2022.09.05 12:25:05.168 3: SH10rt_1_relay_192.168.x.x_48862: _UnDef is closing SH10rt_1_relay_192.168.x.x_48862
2022.09.05 12:25:05.168 5: SH10rt_1_relay_192.168.x.x_48862: Close called from UndefLDFn with noState and noDelete
2022.09.05 12:25:05.168 4: SH10rt_1_relay_192.168.x.x_48862: Close TCP server listening connection and delete hash
2022.09.05 12:25:05.350 5: SH10rt_1_relay_192.168.x.x_48862: Close is removing lastconn from parent device SH10rt_1_relay
2022.09.05 12:25:05.670 4: Connection accepted from SH10rt_1_relay_192.168.x.x_48864
2022.09.05 12:25:05.671 4: SH10rt_1_relay: HandleServerConnection accepted new TCP connection as device SH10rt_1_relay_192.168.x.x_48864
2022.09.05 12:25:05.865 5: SH10rt_1_relay_192.168.x.x_48864: readFn buffer: 0990000000060b0413980002
2022.09.05 12:25:05.866 5: SH10rt_1_relay_192.168.x.x_48864: ParseFrameStart called from ReadFn
2022.09.05 12:25:05.867 4: SH10rt_1_relay_192.168.x.x_48864: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 2448, dlen 6 and potential data 13980002
2022.09.05 12:25:05.868 5: SH10rt_1_relay_192.168.x.x_48864: HandleRequest called from ReadFn
2022.09.05 12:25:05.869 5: SH10rt_1_relay_192.168.x.x_48864: ParseRequest called from HandleRequest
2022.09.05 12:25:05.870 4: SH10rt_1_relay_192.168.x.x_48864: HandleRequest, current frame / read buffer: 0990000000060b0413980002, id 11, fCode 4, tid 2448,
request: id 11 fc 4 i5016, len 2, tid 2448
2022.09.05 12:25:05.871 4: SH10rt_1_relay_192.168.x.x_48864: RelayRequest called from HandleRequest
2022.09.05 12:25:05.872 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 12:25:05.873 4: SH10rt_1_relay_192.168.x.x_48864: RelayRequest via SH10rt_1, Proto TCP with id 1, current frame / read buffer: 0990000000060b0413980002, id 11, fCode 4, tid 2448,
request: id 11 fc 4 i5016, len 2, tid 2448, for relay device SH10rt_1_relay_192.168.x.x_48864
2022.09.05 12:25:05.883 4: SH10rt_1_relay_192.168.x.x_48864: HandleRequest Done, current frame / read buffer: 0990000000060b0413980002, id 11, fCode 4, tid 2448,
request: id 11 fc 4 i5016, len 2, tid 2448, for relay device SH10rt_1_relay_192.168.x.x_48864
2022.09.05 12:25:05.884 5: SH10rt_1_relay_192.168.x.x_48864: DropFrame called from ReadFn - drop 0990000000060b0413980002
2022.09.05 12:25:05.929 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 1d0c0000, type i, adr 5016
2022.09.05 12:25:05.929 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 1d0c0000, type i, adr 5016, valuesLen 2
2022.09.05 12:25:05.930 5: SH10rt_1_relay: SplitDataString has no information about handling i5016
2022.09.05 12:25:05.930 5: SH10rt_1_relay: SplitDataString has no information about handling i5017
2022.09.05 12:25:05.931 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 12:25:05.931 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 12:25:05.931 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 12:25:05.932 5: SH10rt_1_relay_192.168.x.x_48864: Send called from RelayResponse
2022.09.05 12:25:05.933 4: SH10rt_1_relay_192.168.x.x_48864: Send 0990000000070b04041d0c0000
2022.09.05 12:25:06.189 5: SH10rt_1_relay_192.168.x.x_48864: readFn buffer: 0991000000060b0432dd0001
2022.09.05 12:25:06.189 5: SH10rt_1_relay_192.168.x.x_48864: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 12:25:06.190 4: SH10rt_1_relay_192.168.x.x_48864: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 2449, dlen 6 and potential data 32dd0001
2022.09.05 12:25:06.190 5: SH10rt_1_relay_192.168.x.x_48864: HandleRequest called from ReadFn
2022.09.05 12:25:06.191 5: SH10rt_1_relay_192.168.x.x_48864: ParseRequest called from HandleRequest
2022.09.05 12:25:06.191 4: SH10rt_1_relay_192.168.x.x_48864: HandleRequest, current frame / read buffer: 0991000000060b0432dd0001, id 11, fCode 4, tid 2449,
request: id 11 fc 4 i13021, len 1, tid 2449
2022.09.05 12:25:06.192 4: SH10rt_1_relay_192.168.x.x_48864: RelayRequest called from HandleRequest
2022.09.05 12:25:06.192 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 12:25:06.193 4: SH10rt_1_relay_192.168.x.x_48864: RelayRequest via SH10rt_1, Proto TCP with id 1, current frame / read buffer: 0991000000060b0432dd0001, id 11, fCode 4, tid 2449,
request: id 11 fc 4 i13021, len 1, tid 2449, for relay device SH10rt_1_relay_192.168.x.x_48864
2022.09.05 12:25:06.199 4: SH10rt_1_relay_192.168.x.x_48864: HandleRequest Done, current frame / read buffer: 0991000000060b0432dd0001, id 11, fCode 4, tid 2449,
request: id 11 fc 4 i13021, len 1, tid 2449, for relay device SH10rt_1_relay_192.168.x.x_48864
2022.09.05 12:25:06.200 5: SH10rt_1_relay_192.168.x.x_48864: DropFrame called from ReadFn - drop 0991000000060b0432dd0001
2022.09.05 12:25:06.205 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 07e2, type i, adr 13021
2022.09.05 12:25:06.206 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 07e2, type i, adr 13021, valuesLen 1
2022.09.05 12:25:06.206 5: SH10rt_1_relay: SplitDataString has no information about handling i13021
2022.09.05 12:25:06.207 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 12:25:06.207 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 12:25:06.208 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 12:25:06.209 5: SH10rt_1_relay_192.168.x.x_48864: Send called from RelayResponse
2022.09.05 12:25:06.209 4: SH10rt_1_relay_192.168.x.x_48864: Send 0991000000050b040207e2
2022.09.05 12:25:06.216 5: SH10rt_1_relay_192.168.x.x_48864: readFn buffer: 0992000000060b0432c80001
2022.09.05 12:25:06.216 5: SH10rt_1_relay_192.168.x.x_48864: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 12:25:06.217 4: SH10rt_1_relay_192.168.x.x_48864: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 2450, dlen 6 and potential data 32c80001
2022.09.05 12:25:06.217 5: SH10rt_1_relay_192.168.x.x_48864: HandleRequest called from ReadFn
2022.09.05 12:25:06.218 5: SH10rt_1_relay_192.168.x.x_48864: ParseRequest called from HandleRequest
2022.09.05 12:25:06.218 4: SH10rt_1_relay_192.168.x.x_48864: HandleRequest, current frame / read buffer: 0992000000060b0432c80001, id 11, fCode 4, tid 2450,
request: id 11 fc 4 i13000, len 1, tid 2450
2022.09.05 12:25:06.219 4: SH10rt_1_relay_192.168.x.x_48864: RelayRequest called from HandleRequest
2022.09.05 12:25:06.220 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 12:25:06.220 4: SH10rt_1_relay_192.168.x.x_48864: RelayRequest via SH10rt_1, Proto TCP with id 1, current frame / read buffer: 0992000000060b0432c80001, id 11, fCode 4, tid 2450,
request: id 11 fc 4 i13000, len 1, tid 2450, for relay device SH10rt_1_relay_192.168.x.x_48864
2022.09.05 12:25:06.307 4: SH10rt_1_relay_192.168.x.x_48864: HandleRequest Done, current frame / read buffer: 0992000000060b0432c80001, id 11, fCode 4, tid 2450,
request: id 11 fc 4 i13000, len 1, tid 2450, for relay device SH10rt_1_relay_192.168.x.x_48864
2022.09.05 12:25:06.308 5: SH10rt_1_relay_192.168.x.x_48864: DropFrame called from ReadFn - drop 0992000000060b0432c80001
2022.09.05 12:25:06.319 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 0000, type i, adr 13000
2022.09.05 12:25:06.320 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 0000, type i, adr 13000, valuesLen 1
2022.09.05 12:25:06.320 5: SH10rt_1_relay: SplitDataString has no information about handling i13000
2022.09.05 12:25:06.321 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 12:25:06.321 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 12:25:06.321 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 12:25:06.322 5: SH10rt_1_relay_192.168.x.x_48864: Send called from RelayResponse
2022.09.05 12:25:06.322 4: SH10rt_1_relay_192.168.x.x_48864: Send 0992000000050b04020000
2022.09.05 12:25:06.328 5: SH10rt_1_relay_192.168.x.x_48864: readFn buffer: 0993000000060b0432c80001
2022.09.05 12:25:06.328 5: SH10rt_1_relay_192.168.x.x_48864: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 12:25:06.329 4: SH10rt_1_relay_192.168.x.x_48864: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 2451, dlen 6 and potential data 32c80001
2022.09.05 12:25:06.329 5: SH10rt_1_relay_192.168.x.x_48864: HandleRequest called from ReadFn
2022.09.05 12:25:06.329 5: SH10rt_1_relay_192.168.x.x_48864: ParseRequest called from HandleRequest
2022.09.05 12:25:06.330 4: SH10rt_1_relay_192.168.x.x_48864: HandleRequest, current frame / read buffer: 0993000000060b0432c80001, id 11, fCode 4, tid 2451,
request: id 11 fc 4 i13000, len 1, tid 2451
2022.09.05 12:25:06.330 4: SH10rt_1_relay_192.168.x.x_48864: RelayRequest called from HandleRequest
2022.09.05 12:25:06.331 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 12:25:06.331 4: SH10rt_1_relay_192.168.x.x_48864: RelayRequest via SH10rt_1, Proto TCP with id 1, current frame / read buffer: 0993000000060b0432c80001, id 11, fCode 4, tid 2451,
request: id 11 fc 4 i13000, len 1, tid 2451, for relay device SH10rt_1_relay_192.168.x.x_48864
2022.09.05 12:25:06.422 4: SH10rt_1_relay_192.168.x.x_48864: HandleRequest Done, current frame / read buffer: 0993000000060b0432c80001, id 11, fCode 4, tid 2451,
request: id 11 fc 4 i13000, len 1, tid 2451, for relay device SH10rt_1_relay_192.168.x.x_48864
2022.09.05 12:25:06.422 5: SH10rt_1_relay_192.168.x.x_48864: DropFrame called from ReadFn - drop 0993000000060b0432c80001
2022.09.05 12:25:06.434 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 0000, type i, adr 13000
2022.09.05 12:25:06.434 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 0000, type i, adr 13000, valuesLen 1
2022.09.05 12:25:06.435 5: SH10rt_1_relay: SplitDataString has no information about handling i13000
2022.09.05 12:25:06.435 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 12:25:06.435 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 12:25:06.436 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 12:25:06.437 5: SH10rt_1_relay_192.168.x.x_48864: Send called from RelayResponse
2022.09.05 12:25:06.437 4: SH10rt_1_relay_192.168.x.x_48864: Send 0993000000050b04020000
2022.09.05 12:25:06.442 5: SH10rt_1_relay_192.168.x.x_48864: readFn buffer: 0994000000060b0432d10002
2022.09.05 12:25:06.443 5: SH10rt_1_relay_192.168.x.x_48864: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 12:25:06.443 4: SH10rt_1_relay_192.168.x.x_48864: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 2452, dlen 6 and potential data 32d10002
2022.09.05 12:25:06.444 5: SH10rt_1_relay_192.168.x.x_48864: HandleRequest called from ReadFn
2022.09.05 12:25:06.444 5: SH10rt_1_relay_192.168.x.x_48864: ParseRequest called from HandleRequest
2022.09.05 12:25:06.444 4: SH10rt_1_relay_192.168.x.x_48864: HandleRequest, current frame / read buffer: 0994000000060b0432d10002, id 11, fCode 4, tid 2452,
request: id 11 fc 4 i13009, len 2, tid 2452
2022.09.05 12:25:06.445 4: SH10rt_1_relay_192.168.x.x_48864: RelayRequest called from HandleRequest
2022.09.05 12:25:06.445 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 12:25:06.446 4: SH10rt_1_relay_192.168.x.x_48864: RelayRequest via SH10rt_1, Proto TCP with id 1, current frame / read buffer: 0994000000060b0432d10002, id 11, fCode 4, tid 2452,
request: id 11 fc 4 i13009, len 2, tid 2452, for relay device SH10rt_1_relay_192.168.x.x_48864
2022.09.05 12:25:06.536 4: SH10rt_1_relay_192.168.x.x_48864: HandleRequest Done, current frame / read buffer: 0994000000060b0432d10002, id 11, fCode 4, tid 2452,
request: id 11 fc 4 i13009, len 2, tid 2452, for relay device SH10rt_1_relay_192.168.x.x_48864
2022.09.05 12:25:06.537 5: SH10rt_1_relay_192.168.x.x_48864: DropFrame called from ReadFn - drop 0994000000060b0432d10002
2022.09.05 12:25:06.556 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 01910000, type i, adr 13009
2022.09.05 12:25:06.556 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 01910000, type i, adr 13009, valuesLen 2
2022.09.05 12:25:06.556 5: SH10rt_1_relay: SplitDataString has no information about handling i13009
2022.09.05 12:25:06.557 5: SH10rt_1_relay: SplitDataString has no information about handling i13010
2022.09.05 12:25:06.557 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 12:25:06.557 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 12:25:06.558 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 12:25:06.559 5: SH10rt_1_relay_192.168.x.x_48864: Send called from RelayResponse
2022.09.05 12:25:06.559 4: SH10rt_1_relay_192.168.x.x_48864: Send 0994000000070b040401910000
2022.09.05 12:25:06.570 5: SH10rt_1_relay_192.168.x.x_48864: readFn buffer: 0995000000060b0432de0001
2022.09.05 12:25:06.571 5: SH10rt_1_relay_192.168.x.x_48864: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 12:25:06.571 4: SH10rt_1_relay_192.168.x.x_48864: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 2453, dlen 6 and potential data 32de0001
2022.09.05 12:25:06.571 5: SH10rt_1_relay_192.168.x.x_48864: HandleRequest called from ReadFn
2022.09.05 12:25:06.572 5: SH10rt_1_relay_192.168.x.x_48864: ParseRequest called from HandleRequest
2022.09.05 12:25:06.572 4: SH10rt_1_relay_192.168.x.x_48864: HandleRequest, current frame / read buffer: 0995000000060b0432de0001, id 11, fCode 4, tid 2453,
request: id 11 fc 4 i13022, len 1, tid 2453
2022.09.05 12:25:06.573 4: SH10rt_1_relay_192.168.x.x_48864: RelayRequest called from HandleRequest
2022.09.05 12:25:06.573 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 12:25:06.573 4: SH10rt_1_relay_192.168.x.x_48864: RelayRequest via SH10rt_1, Proto TCP with id 1, current frame / read buffer: 0995000000060b0432de0001, id 11, fCode 4, tid 2453,
request: id 11 fc 4 i13022, len 1, tid 2453, for relay device SH10rt_1_relay_192.168.x.x_48864
2022.09.05 12:25:06.658 4: SH10rt_1_relay_192.168.x.x_48864: HandleRequest Done, current frame / read buffer: 0995000000060b0432de0001, id 11, fCode 4, tid 2453,
request: id 11 fc 4 i13022, len 1, tid 2453, for relay device SH10rt_1_relay_192.168.x.x_48864
2022.09.05 12:25:06.659 5: SH10rt_1_relay_192.168.x.x_48864: DropFrame called from ReadFn - drop 0995000000060b0432de0001
2022.09.05 12:25:06.668 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 0348, type i, adr 13022
2022.09.05 12:25:06.669 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 0348, type i, adr 13022, valuesLen 1
2022.09.05 12:25:06.669 5: SH10rt_1_relay: SplitDataString has no information about handling i13022
2022.09.05 12:25:06.669 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 12:25:06.670 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 12:25:06.670 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 12:25:06.671 5: SH10rt_1_relay_192.168.x.x_48864: Send called from RelayResponse
2022.09.05 12:25:06.671 4: SH10rt_1_relay_192.168.x.x_48864: Send 0995000000050b04020348
2022.09.05 12:25:11.562 3: SH10rt_1_relay_192.168.x.x_48864: read from TCP server connection got null -> closing
2022.09.05 12:25:11.562 3: SH10rt_1_relay_192.168.x.x_48864: _UnDef is closing SH10rt_1_relay_192.168.x.x_48864
2022.09.05 12:25:11.563 5: SH10rt_1_relay_192.168.x.x_48864: Close called from UndefLDFn with noState and noDelete
2022.09.05 12:25:11.563 4: SH10rt_1_relay_192.168.x.x_48864: Close TCP server listening connection and delete hash
2022.09.05 12:25:11.730 5: SH10rt_1_relay_192.168.x.x_48864: Close is removing lastconn from parent device SH10rt_1_relay
2022.09.05 12:25:15.027 4: Connection accepted from SH10rt_1_relay_192.168.x.x_48870
2022.09.05 12:25:15.028 4: SH10rt_1_relay: HandleServerConnection accepted new TCP connection as device SH10rt_1_relay_192.168.x.x_48870
2022.09.05 12:25:15.119 5: SH10rt_1_relay_192.168.x.x_48870: readFn buffer: 0996000000060b0413980002
2022.09.05 12:25:15.119 5: SH10rt_1_relay_192.168.x.x_48870: ParseFrameStart called from ReadFn
2022.09.05 12:25:15.120 4: SH10rt_1_relay_192.168.x.x_48870: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 2454, dlen 6 and potential data 13980002
2022.09.05 12:25:15.120 5: SH10rt_1_relay_192.168.x.x_48870: HandleRequest called from ReadFn
2022.09.05 12:25:15.121 5: SH10rt_1_relay_192.168.x.x_48870: ParseRequest called from HandleRequest
2022.09.05 12:25:15.122 4: SH10rt_1_relay_192.168.x.x_48870: HandleRequest, current frame / read buffer: 0996000000060b0413980002, id 11, fCode 4, tid 2454,
request: id 11 fc 4 i5016, len 2, tid 2454
2022.09.05 12:25:15.122 4: SH10rt_1_relay_192.168.x.x_48870: RelayRequest called from HandleRequest
2022.09.05 12:25:15.123 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 12:25:15.123 4: SH10rt_1_relay_192.168.x.x_48870: RelayRequest via SH10rt_1, Proto TCP with id 1, current frame / read buffer: 0996000000060b0413980002, id 11, fCode 4, tid 2454,
request: id 11 fc 4 i5016, len 2, tid 2454, for relay device SH10rt_1_relay_192.168.x.x_48870
2022.09.05 12:25:15.130 4: SH10rt_1_relay_192.168.x.x_48870: HandleRequest Done, current frame / read buffer: 0996000000060b0413980002, id 11, fCode 4, tid 2454,
request: id 11 fc 4 i5016, len 2, tid 2454, for relay device SH10rt_1_relay_192.168.x.x_48870
2022.09.05 12:25:15.131 5: SH10rt_1_relay_192.168.x.x_48870: DropFrame called from ReadFn - drop 0996000000060b0413980002
2022.09.05 12:25:15.153 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 1d030000, type i, adr 5016
2022.09.05 12:25:15.154 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 1d030000, type i, adr 5016, valuesLen 2
2022.09.05 12:25:15.154 5: SH10rt_1_relay: SplitDataString has no information about handling i5016
2022.09.05 12:25:15.155 5: SH10rt_1_relay: SplitDataString has no information about handling i5017
2022.09.05 12:25:15.155 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 12:25:15.155 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 12:25:15.156 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 12:25:15.157 5: SH10rt_1_relay_192.168.x.x_48870: Send called from RelayResponse
2022.09.05 12:25:15.157 4: SH10rt_1_relay_192.168.x.x_48870: Send 0996000000070b04041d030000
2022.09.05 12:25:15.232 5: SH10rt_1_relay_192.168.x.x_48870: readFn buffer: 0997000000060b0432dd0001
2022.09.05 12:25:15.233 5: SH10rt_1_relay_192.168.x.x_48870: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 12:25:15.233 4: SH10rt_1_relay_192.168.x.x_48870: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 2455, dlen 6 and potential data 32dd0001
2022.09.05 12:25:15.233 5: SH10rt_1_relay_192.168.x.x_48870: HandleRequest called from ReadFn
2022.09.05 12:25:15.234 5: SH10rt_1_relay_192.168.x.x_48870: ParseRequest called from HandleRequest
2022.09.05 12:25:15.234 4: SH10rt_1_relay_192.168.x.x_48870: HandleRequest, current frame / read buffer: 0997000000060b0432dd0001, id 11, fCode 4, tid 2455,
request: id 11 fc 4 i13021, len 1, tid 2455
2022.09.05 12:25:15.235 4: SH10rt_1_relay_192.168.x.x_48870: RelayRequest called from HandleRequest
2022.09.05 12:25:15.235 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 12:25:15.235 4: SH10rt_1_relay_192.168.x.x_48870: RelayRequest via SH10rt_1, Proto TCP with id 1, current frame / read buffer: 0997000000060b0432dd0001, id 11, fCode 4, tid 2455,
request: id 11 fc 4 i13021, len 1, tid 2455, for relay device SH10rt_1_relay_192.168.x.x_48870
2022.09.05 12:25:15.241 4: SH10rt_1_relay_192.168.x.x_48870: HandleRequest Done, current frame / read buffer: 0997000000060b0432dd0001, id 11, fCode 4, tid 2455,
request: id 11 fc 4 i13021, len 1, tid 2455, for relay device SH10rt_1_relay_192.168.x.x_48870
2022.09.05 12:25:15.242 5: SH10rt_1_relay_192.168.x.x_48870: DropFrame called from ReadFn - drop 0997000000060b0432dd0001
2022.09.05 12:25:15.246 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 07e2, type i, adr 13021
2022.09.05 12:25:15.246 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 07e2, type i, adr 13021, valuesLen 1
2022.09.05 12:25:15.247 5: SH10rt_1_relay: SplitDataString has no information about handling i13021
2022.09.05 12:25:15.247 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 12:25:15.247 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 12:25:15.248 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 12:25:15.248 5: SH10rt_1_relay_192.168.x.x_48870: Send called from RelayResponse
2022.09.05 12:25:15.249 4: SH10rt_1_relay_192.168.x.x_48870: Send 0997000000050b040207e2
2022.09.05 12:25:15.254 5: SH10rt_1_relay_192.168.x.x_48870: readFn buffer: 0998000000060b0432c80001
2022.09.05 12:25:15.254 5: SH10rt_1_relay_192.168.x.x_48870: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 12:25:15.255 4: SH10rt_1_relay_192.168.x.x_48870: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 2456, dlen 6 and potential data 32c80001
2022.09.05 12:25:15.255 5: SH10rt_1_relay_192.168.x.x_48870: HandleRequest called from ReadFn
2022.09.05 12:25:15.255 5: SH10rt_1_relay_192.168.x.x_48870: ParseRequest called from HandleRequest
2022.09.05 12:25:15.256 4: SH10rt_1_relay_192.168.x.x_48870: HandleRequest, current frame / read buffer: 0998000000060b0432c80001, id 11, fCode 4, tid 2456,
request: id 11 fc 4 i13000, len 1, tid 2456
2022.09.05 12:25:15.256 4: SH10rt_1_relay_192.168.x.x_48870: RelayRequest called from HandleRequest
2022.09.05 12:25:15.257 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 12:25:15.257 4: SH10rt_1_relay_192.168.x.x_48870: RelayRequest via SH10rt_1, Proto TCP with id 1, current frame / read buffer: 0998000000060b0432c80001, id 11, fCode 4, tid 2456,
request: id 11 fc 4 i13000, len 1, tid 2456, for relay device SH10rt_1_relay_192.168.x.x_48870
2022.09.05 12:25:15.348 4: SH10rt_1_relay_192.168.x.x_48870: HandleRequest Done, current frame / read buffer: 0998000000060b0432c80001, id 11, fCode 4, tid 2456,
request: id 11 fc 4 i13000, len 1, tid 2456, for relay device SH10rt_1_relay_192.168.x.x_48870
2022.09.05 12:25:15.349 5: SH10rt_1_relay_192.168.x.x_48870: DropFrame called from ReadFn - drop 0998000000060b0432c80001
2022.09.05 12:25:15.356 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 0000, type i, adr 13000
2022.09.05 12:25:15.357 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 0000, type i, adr 13000, valuesLen 1
2022.09.05 12:25:15.357 5: SH10rt_1_relay: SplitDataString has no information about handling i13000
2022.09.05 12:25:15.358 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 12:25:15.358 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 12:25:15.358 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 12:25:15.359 5: SH10rt_1_relay_192.168.x.x_48870: Send called from RelayResponse
2022.09.05 12:25:15.359 4: SH10rt_1_relay_192.168.x.x_48870: Send 0998000000050b04020000
2022.09.05 12:25:15.365 5: SH10rt_1_relay_192.168.x.x_48870: readFn buffer: 0999000000060b0432c80001
2022.09.05 12:25:15.365 5: SH10rt_1_relay_192.168.x.x_48870: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 12:25:15.366 4: SH10rt_1_relay_192.168.x.x_48870: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 2457, dlen 6 and potential data 32c80001
2022.09.05 12:25:15.366 5: SH10rt_1_relay_192.168.x.x_48870: HandleRequest called from ReadFn
2022.09.05 12:25:15.366 5: SH10rt_1_relay_192.168.x.x_48870: ParseRequest called from HandleRequest
2022.09.05 12:25:15.367 4: SH10rt_1_relay_192.168.x.x_48870: HandleRequest, current frame / read buffer: 0999000000060b0432c80001, id 11, fCode 4, tid 2457,
request: id 11 fc 4 i13000, len 1, tid 2457
2022.09.05 12:25:15.367 4: SH10rt_1_relay_192.168.x.x_48870: RelayRequest called from HandleRequest
2022.09.05 12:25:15.368 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 12:25:15.368 4: SH10rt_1_relay_192.168.x.x_48870: RelayRequest via SH10rt_1, Proto TCP with id 1, current frame / read buffer: 0999000000060b0432c80001, id 11, fCode 4, tid 2457,
request: id 11 fc 4 i13000, len 1, tid 2457, for relay device SH10rt_1_relay_192.168.x.x_48870
2022.09.05 12:25:15.458 4: SH10rt_1_relay_192.168.x.x_48870: HandleRequest Done, current frame / read buffer: 0999000000060b0432c80001, id 11, fCode 4, tid 2457,
request: id 11 fc 4 i13000, len 1, tid 2457, for relay device SH10rt_1_relay_192.168.x.x_48870
2022.09.05 12:25:15.458 5: SH10rt_1_relay_192.168.x.x_48870: DropFrame called from ReadFn - drop 0999000000060b0432c80001
2022.09.05 12:25:15.463 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 0000, type i, adr 13000
2022.09.05 12:25:15.463 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 0000, type i, adr 13000, valuesLen 1
2022.09.05 12:25:15.464 5: SH10rt_1_relay: SplitDataString has no information about handling i13000
2022.09.05 12:25:15.464 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 12:25:15.465 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 12:25:15.465 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 12:25:15.466 5: SH10rt_1_relay_192.168.x.x_48870: Send called from RelayResponse
2022.09.05 12:25:15.466 4: SH10rt_1_relay_192.168.x.x_48870: Send 0999000000050b04020000
2022.09.05 12:25:15.471 5: SH10rt_1_relay_192.168.x.x_48870: readFn buffer: 099a000000060b0432d10002
2022.09.05 12:25:15.472 5: SH10rt_1_relay_192.168.x.x_48870: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 12:25:15.472 4: SH10rt_1_relay_192.168.x.x_48870: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 2458, dlen 6 and potential data 32d10002
2022.09.05 12:25:15.473 5: SH10rt_1_relay_192.168.x.x_48870: HandleRequest called from ReadFn
2022.09.05 12:25:15.473 5: SH10rt_1_relay_192.168.x.x_48870: ParseRequest called from HandleRequest
2022.09.05 12:25:15.474 4: SH10rt_1_relay_192.168.x.x_48870: HandleRequest, current frame / read buffer: 099a000000060b0432d10002, id 11, fCode 4, tid 2458,
request: id 11 fc 4 i13009, len 2, tid 2458
2022.09.05 12:25:15.474 4: SH10rt_1_relay_192.168.x.x_48870: RelayRequest called from HandleRequest
2022.09.05 12:25:15.474 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 12:25:15.475 4: SH10rt_1_relay_192.168.x.x_48870: RelayRequest via SH10rt_1, Proto TCP with id 1, current frame / read buffer: 099a000000060b0432d10002, id 11, fCode 4, tid 2458,
request: id 11 fc 4 i13009, len 2, tid 2458, for relay device SH10rt_1_relay_192.168.x.x_48870
2022.09.05 12:25:15.565 4: SH10rt_1_relay_192.168.x.x_48870: HandleRequest Done, current frame / read buffer: 099a000000060b0432d10002, id 11, fCode 4, tid 2458,
request: id 11 fc 4 i13009, len 2, tid 2458, for relay device SH10rt_1_relay_192.168.x.x_48870
2022.09.05 12:25:15.566 5: SH10rt_1_relay_192.168.x.x_48870: DropFrame called from ReadFn - drop 099a000000060b0432d10002
2022.09.05 12:25:15.586 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex ffabffff, type i, adr 13009
2022.09.05 12:25:15.586 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex ffabffff, type i, adr 13009, valuesLen 2
2022.09.05 12:25:15.587 5: SH10rt_1_relay: SplitDataString has no information about handling i13009
2022.09.05 12:25:15.587 5: SH10rt_1_relay: SplitDataString has no information about handling i13010
2022.09.05 12:25:15.587 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 12:25:15.588 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 12:25:15.588 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 12:25:15.589 5: SH10rt_1_relay_192.168.x.x_48870: Send called from RelayResponse
2022.09.05 12:25:15.589 4: SH10rt_1_relay_192.168.x.x_48870: Send 099a000000070b0404ffabffff
2022.09.05 12:25:15.595 5: SH10rt_1_relay_192.168.x.x_48870: readFn buffer: 099b000000060b0432de0001
2022.09.05 12:25:15.595 5: SH10rt_1_relay_192.168.x.x_48870: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 12:25:15.596 4: SH10rt_1_relay_192.168.x.x_48870: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 2459, dlen 6 and potential data 32de0001
2022.09.05 12:25:15.596 5: SH10rt_1_relay_192.168.x.x_48870: HandleRequest called from ReadFn
2022.09.05 12:25:15.596 5: SH10rt_1_relay_192.168.x.x_48870: ParseRequest called from HandleRequest
2022.09.05 12:25:15.597 4: SH10rt_1_relay_192.168.x.x_48870: HandleRequest, current frame / read buffer: 099b000000060b0432de0001, id 11, fCode 4, tid 2459,
request: id 11 fc 4 i13022, len 1, tid 2459
2022.09.05 12:25:15.597 4: SH10rt_1_relay_192.168.x.x_48870: RelayRequest called from HandleRequest
2022.09.05 12:25:15.597 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 12:25:15.598 4: SH10rt_1_relay_192.168.x.x_48870: RelayRequest via SH10rt_1, Proto TCP with id 1, current frame / read buffer: 099b000000060b0432de0001, id 11, fCode 4, tid 2459,
request: id 11 fc 4 i13022, len 1, tid 2459, for relay device SH10rt_1_relay_192.168.x.x_48870
2022.09.05 12:25:15.674 4: SH10rt_1_relay_192.168.x.x_48870: HandleRequest Done, current frame / read buffer: 099b000000060b0432de0001, id 11, fCode 4, tid 2459,
request: id 11 fc 4 i13022, len 1, tid 2459, for relay device SH10rt_1_relay_192.168.x.x_48870
2022.09.05 12:25:15.674 5: SH10rt_1_relay_192.168.x.x_48870: DropFrame called from ReadFn - drop 099b000000060b0432de0001
2022.09.05 12:25:15.679 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 0348, type i, adr 13022
2022.09.05 12:25:15.680 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 0348, type i, adr 13022, valuesLen 1
2022.09.05 12:25:15.680 5: SH10rt_1_relay: SplitDataString has no information about handling i13022
2022.09.05 12:25:15.681 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 12:25:15.681 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 12:25:15.681 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 12:25:15.682 5: SH10rt_1_relay_192.168.x.x_48870: Send called from RelayResponse
2022.09.05 12:25:15.682 4: SH10rt_1_relay_192.168.x.x_48870: Send 099b000000050b04020348
2022.09.05 12:25:20.760 3: SH10rt_1_relay_192.168.x.x_48870: read from TCP server connection got null -> closing
2022.09.05 12:25:20.761 3: SH10rt_1_relay_192.168.x.x_48870: _UnDef is closing SH10rt_1_relay_192.168.x.x_48870
2022.09.05 12:25:20.761 5: SH10rt_1_relay_192.168.x.x_48870: Close called from UndefLDFn with noState and noDelete
2022.09.05 12:25:20.761 4: SH10rt_1_relay_192.168.x.x_48870: Close TCP server listening connection and delete hash
2022.09.05 12:25:20.938 5: SH10rt_1_relay_192.168.x.x_48870: Close is removing lastconn from parent device SH10rt_1_relay
Und ein Log während ich mit EVCC lade:
[code]2022.09.05 13:25:08.317 5: SH10rt_1_relay: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo inactive active
2022.09.05 13:25:08.317 5: SH10rt_1_relay: UpdateSetList: getList=
2022.09.05 13:25:11.040 3: SH10rt_1_relay_192.168.x.x_57356: read from TCP server connection got null -> closing
2022.09.05 13:25:11.040 3: SH10rt_1_relay_192.168.x.x_57356: _UnDef is closing SH10rt_1_relay_192.168.x.x_57356
2022.09.05 13:25:11.046 5: SH10rt_1_relay_192.168.x.x_57356: Close called from UndefLDFn with noState and noDelete
2022.09.05 13:25:11.047 4: SH10rt_1_relay_192.168.x.x_57356: Close TCP server listening connection and delete hash
2022.09.05 13:25:11.051 5: SH10rt_1_relay_192.168.x.x_57356: Close is removing lastconn from parent device SH10rt_1_relay
2022.09.05 13:25:15.031 4: Connection accepted from SH10rt_1_relay_192.168.x.x_57362
2022.09.05 13:25:15.032 4: SH10rt_1_relay: HandleServerConnection accepted new TCP connection as device SH10rt_1_relay_192.168.x.x_57362
2022.09.05 13:25:15.145 5: SH10rt_1_relay_192.168.x.x_57362: readFn buffer: 125c000000060b0413980002
2022.09.05 13:25:15.146 5: SH10rt_1_relay_192.168.x.x_57362: ParseFrameStart called from ReadFn
2022.09.05 13:25:15.147 4: SH10rt_1_relay_192.168.x.x_57362: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 4700, dlen 6 and potential data 13980002
2022.09.05 13:25:15.147 5: SH10rt_1_relay_192.168.x.x_57362: HandleRequest called from ReadFn
2022.09.05 13:25:15.148 5: SH10rt_1_relay_192.168.x.x_57362: ParseRequest called from HandleRequest
2022.09.05 13:25:15.149 4: SH10rt_1_relay_192.168.x.x_57362: HandleRequest, current frame / read buffer: 125c000000060b0413980002, id 11, fCode 4, tid 4700,
request: id 11 fc 4 i5016, len 2, tid 4700
2022.09.05 13:25:15.150 4: SH10rt_1_relay_192.168.x.x_57362: RelayRequest called from HandleRequest
2022.09.05 13:25:15.151 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 13:25:15.152 4: SH10rt_1_relay_192.168.x.x_57362: RelayRequest via SH10rt_1, Proto TCP with id 1, current frame / read buffer: 125c000000060b0413980002, id 11, fCode 4, tid 4700,
request: id 11 fc 4 i5016, len 2, tid 4700, for relay device SH10rt_1_relay_192.168.x.x_57362
2022.09.05 13:25:15.162 4: SH10rt_1_relay_192.168.x.x_57362: HandleRequest Done, current frame / read buffer: 125c000000060b0413980002, id 11, fCode 4, tid 4700,
request: id 11 fc 4 i5016, len 2, tid 4700, for relay device SH10rt_1_relay_192.168.x.x_57362
2022.09.05 13:25:15.163 5: SH10rt_1_relay_192.168.x.x_57362: DropFrame called from ReadFn - drop 125c000000060b0413980002
2022.09.05 13:25:15.220 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 1bc30000, type i, adr 5016
2022.09.05 13:25:15.220 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 1bc30000, type i, adr 5016, valuesLen 2
2022.09.05 13:25:15.221 5: SH10rt_1_relay: SplitDataString has no information about handling i5016
2022.09.05 13:25:15.221 5: SH10rt_1_relay: SplitDataString has no information about handling i5017
2022.09.05 13:25:15.221 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 13:25:15.221 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 13:25:15.222 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 13:25:15.222 5: SH10rt_1_relay_192.168.x.x_57362: Send called from RelayResponse
2022.09.05 13:25:15.223 4: SH10rt_1_relay_192.168.x.x_57362: Send 125c000000070b04041bc30000
2022.09.05 13:25:15.316 5: SH10rt_1_relay_192.168.x.x_57362: readFn buffer: 125d000000060b0432dd0001
2022.09.05 13:25:15.316 5: SH10rt_1_relay_192.168.x.x_57362: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 13:25:15.316 4: SH10rt_1_relay_192.168.x.x_57362: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 4701, dlen 6 and potential data 32dd0001
2022.09.05 13:25:15.317 5: SH10rt_1_relay_192.168.x.x_57362: HandleRequest called from ReadFn
2022.09.05 13:25:15.317 5: SH10rt_1_relay_192.168.x.x_57362: ParseRequest called from HandleRequest
2022.09.05 13:25:15.317 4: SH10rt_1_relay_192.168.x.x_57362: HandleRequest, current frame / read buffer: 125d000000060b0432dd0001, id 11, fCode 4, tid 4701,
request: id 11 fc 4 i13021, len 1, tid 4701
2022.09.05 13:25:15.318 4: SH10rt_1_relay_192.168.x.x_57362: RelayRequest called from HandleRequest
2022.09.05 13:25:15.318 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 13:25:15.318 4: SH10rt_1_relay_192.168.x.x_57362: RelayRequest via SH10rt_1, Proto TCP with id 1, current frame / read buffer: 125d000000060b0432dd0001, id 11, fCode 4, tid 4701,
request: id 11 fc 4 i13021, len 1, tid 4701, for relay device SH10rt_1_relay_192.168.x.x_57362
2022.09.05 13:25:15.324 4: SH10rt_1_relay_192.168.x.x_57362: HandleRequest Done, current frame / read buffer: 125d000000060b0432dd0001, id 11, fCode 4, tid 4701,
request: id 11 fc 4 i13021, len 1, tid 4701, for relay device SH10rt_1_relay_192.168.x.x_57362
2022.09.05 13:25:15.324 5: SH10rt_1_relay_192.168.x.x_57362: DropFrame called from ReadFn - drop 125d000000060b0432dd0001
2022.09.05 13:25:15.329 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 0000, type i, adr 13021
2022.09.05 13:25:15.329 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 0000, type i, adr 13021, valuesLen 1
2022.09.05 13:25:15.329 5: SH10rt_1_relay: SplitDataString has no information about handling i13021
2022.09.05 13:25:15.329 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 13:25:15.330 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 13:25:15.330 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 13:25:15.331 5: SH10rt_1_relay_192.168.x.x_57362: Send called from RelayResponse
2022.09.05 13:25:15.331 4: SH10rt_1_relay_192.168.x.x_57362: Send 125d000000050b04020000
2022.09.05 13:25:15.336 5: SH10rt_1_relay_192.168.x.x_57362: readFn buffer: 125e000000060b0432c80001
2022.09.05 13:25:15.337 5: SH10rt_1_relay_192.168.x.x_57362: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 13:25:15.337 4: SH10rt_1_relay_192.168.x.x_57362: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 4702, dlen 6 and potential data 32c80001
2022.09.05 13:25:15.337 5: SH10rt_1_relay_192.168.x.x_57362: HandleRequest called from ReadFn
2022.09.05 13:25:15.338 5: SH10rt_1_relay_192.168.x.x_57362: ParseRequest called from HandleRequest
2022.09.05 13:25:15.338 4: SH10rt_1_relay_192.168.x.x_57362: HandleRequest, current frame / read buffer: 125e000000060b0432c80001, id 11, fCode 4, tid 4702,
request: id 11 fc 4 i13000, len 1, tid 4702
2022.09.05 13:25:15.338 4: SH10rt_1_relay_192.168.x.x_57362: RelayRequest called from HandleRequest
2022.09.05 13:25:15.339 5: SH10rt_1_relay: GetRelayIO found SH10rt_1 as Modbus relay forward io device for SH10rt_1 with id 1
2022.09.05 13:25:15.339 4: SH10rt_1_relay_192.168.x.x_57362: RelayRequest via SH10rt_1, Proto TCP with id 1, current frame / read buffer: 125e000000060b0432c80001, id 11, fCode 4, tid 4702,
request: id 11 fc 4 i13000, len 1, tid 4702, for relay device SH10rt_1_relay_192.168.x.x_57362
2022.09.05 13:25:15.432 4: SH10rt_1_relay_192.168.x.x_57362: HandleRequest Done, current frame / read buffer: 125e000000060b0432c80001, id 11, fCode 4, tid 4702,
request: id 11 fc 4 i13000, len 1, tid 4702, for relay device SH10rt_1_relay_192.168.x.x_57362
2022.09.05 13:25:15.432 5: SH10rt_1_relay_192.168.x.x_57362: DropFrame called from ReadFn - drop 125e000000060b0432c80001
2022.09.05 13:25:15.470 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 0000, type i, adr 13000
2022.09.05 13:25:15.471 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 0000, type i, adr 13000, valuesLen 1
2022.09.05 13:25:
Hallo FhemPiUser,
Für die Fehlersuche bräuchte ich nicht nur die Logs der Relay-Devices sondern parallel auch die der vom Relay verwendeten Master-Devices.
Um die Fehlersuche zu vereinfachen wäre es schön, wenn Du die Relay-Funktion mal von Deinen regulären Master-Abfragen trennen könntest. Dazu einfach alle Objekt-Attribute aus SH10rt_1 und SH0rt_2 entfernen und auch im Define das Intervall auf 0 setzen.
Dann haben wir nur noch die Relay-Funktion ohne eigene Parallele Abfragen und alle Requests kommen vom evcc.
Wenn dann immer noch der RAM-Verbrauch steigt, sollte das einfacher zu finden sein.
Zudem müsste ich wissen, welche Version des Moduls Du verwendest, sonst passen Deine Zeilennummern nicht zu meinen.
Gruß
Stefan
Hallo Stefan,
ok, danke.
Die bestehenden SH10rt_1 & SH10rt_2 devices würde ich ungern leeren und Interval 0 auf setzen, da dann meine Statistiken fehlen.
Ich würde zwei neue devices SH10rt_1_1 & SH10rt_2_1 zusätzlich anlegen mit Interval 0 und die bestehenden relay devices an diese weiterleiten lassen.
Ich beobachte dann die nächsten Stunden/Tage, ob die RAM-Nutzung steigt.
Modulversion ist Modbus 4.4.04 - 17.7.2021
Anbei schonmal das Log für SH10rt_1_1 und SH10rt_1 relay:
response: id 11, fc 4, i13009, len 2, values fff0ffff, tid 47
2022.09.05 19:44:30.934 5: SH10rt_1_relay_192.168.x.x: Send called from RelayResponse
2022.09.05 19:44:30.935 4: SH10rt_1_relay_192.168.x.x: Send 002f000000070b0404fff0ffff
2022.09.05 19:44:30.936 4: SH10rt_1_1: HandleResponse done, current frame / read buffer: 001700000007010404fff0ffff, id 1, fCode 4, tid 23,
request: id 1 fc 4 i13009, len 2, tid 23, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.11 secs ago, sent 0.11 secs ago,
response: id 11, fc 4, i13009, len 2, values fff0ffff, tid 47
2022.09.05 19:44:30.937 5: SH10rt_1_1: ResetExpect for HandleResponse from response to idle
2022.09.05 19:44:30.941 5: SH10rt_1_1: DropFrame called from ReadFn - drop 001700000007010404fff0ffff
2022.09.05 19:44:30.952 5: SH10rt_1_relay_192.168.x.x: readFn buffer: 0030000000060b0432de0001
2022.09.05 19:44:30.953 5: SH10rt_1_relay_192.168.x.x: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 19:44:30.954 4: SH10rt_1_relay_192.168.x.x: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 48, dlen 6 and potential data 32de0001
2022.09.05 19:44:30.955 5: SH10rt_1_relay_192.168.x.x: HandleRequest called from ReadFn
2022.09.05 19:44:30.955 5: SH10rt_1_relay_192.168.x.x: ParseRequest called from HandleRequest
2022.09.05 19:44:30.956 4: SH10rt_1_relay_192.168.x.x: HandleRequest, current frame / read buffer: 0030000000060b0432de0001, id 11, fCode 4, tid 48,
request: id 11 fc 4 i13022, len 1, tid 48
2022.09.05 19:44:30.957 4: SH10rt_1_relay_192.168.x.x: RelayRequest called from HandleRequest
2022.09.05 19:44:30.957 5: SH10rt_1_relay: GetRelayIO found SH10rt_1_1 as Modbus relay forward io device for SH10rt_1_1 with id 1
2022.09.05 19:44:30.958 4: SH10rt_1_relay_192.168.x.x: RelayRequest via SH10rt_1_1, Proto TCP with id 1, current frame / read buffer: 0030000000060b0432de0001, id 11, fCode 4, tid 48,
request: id 11 fc 4 i13022, len 1, tid 48, for relay device SH10rt_1_relay_192.168.x.x
2022.09.05 19:44:30.959 5: SH10rt_1_1: QueueRequest called from RelayRequest with i13022, qlen 0 from master SH10rt_1_1 for relay SH10rt_1_relay_192.168.x.x through io device SH10rt_1_1
2022.09.05 19:44:30.960 5: SH10rt_1_1: ProcessRequestQueue called from QueueRequest as direct:SH10rt_1_1, qlen 1, force, request: request: id 1 fc 4 i13022, len 1, tid 199, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.00 secs ago
2022.09.05 19:44:30.961 5: SH10rt_1_1: checkDelays busDelayRead, last activity on bus was 0.040 secs ago, required delay is 0
2022.09.05 19:44:30.962 5: SH10rt_1_1: checkDelays sendDelay, last send to same device was 0.051 secs ago, required delay is 0.1
2022.09.05 19:44:30.962 5: SH10rt_1_1: checkDelays clientSwitchDelay is not relevant
2022.09.05 19:44:30.962 5: SH10rt_1_1: checkDelays commDelay, last communication with same device was 0.040 secs ago, required delay is 0.1
2022.09.05 19:44:30.963 4: SH10rt_1_1: checkDelays found commDelay not over, sleep for 0.060 forced
2022.09.05 19:44:31.023 4: SH10rt_1_1: checkDelays sleep done, go on with sending
2022.09.05 19:44:31.027 4: SH10rt_1_1: ProcessRequestQueue (V4.4.04 - 17.7.2021) qlen 1, sending 00c700000006010432de0001 via 192.168.3.160:502, read buffer empty,
request: id 1 fc 4 i13022, len 1, tid 199, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.07 secs ago
2022.09.05 19:44:31.027 5: SH10rt_1_1: Send called from ProcessRequestQueue
2022.09.05 19:44:31.028 5: DevIo_SimpleWrite SH10rt_1_1: 00c700000006010432de0001
2022.09.05 19:44:31.033 4: SH10rt_1_relay_192.168.x.x: HandleRequest Done, current frame / read buffer: 0030000000060b0432de0001, id 11, fCode 4, tid 48,
request: id 11 fc 4 i13022, len 1, tid 48, for relay device SH10rt_1_relay_192.168.x.x
2022.09.05 19:44:31.034 5: SH10rt_1_relay_192.168.x.x: DropFrame called from ReadFn - drop 0030000000060b0432de0001
2022.09.05 19:44:31.036 5: SH10rt_1_1: readFn buffer: 00c70000000501040203dc
2022.09.05 19:44:31.037 5: SH10rt_1_1: ParseFrameStart called from ReadFn protocol TCP expecting id 1
2022.09.05 19:44:31.038 4: SH10rt_1_1: ParseFrameStart (TCP, master) extracted id 1, fCode 4, tid 199, dlen 5 and potential data 0203dc
2022.09.05 19:44:31.038 5: SH10rt_1_1: HandleResponse called from ReadFn
2022.09.05 19:44:31.039 5: SH10rt_1_1: ParseResponse called from HandleResponse
2022.09.05 19:44:31.040 5: SH10rt_1_1: now parsing response data objects, master is SH10rt_1_1 relay is SH10rt_1_relay
2022.09.05 19:44:31.040 5: SH10rt_1_1: ParseDataString called from HandleResponse with data hex 03dc, type i, adr 13022
2022.09.05 19:44:31.041 5: SH10rt_1_1: SplitDataString called from ParseDataString with data hex 03dc, type i, adr 13022, valuesLen 1
2022.09.05 19:44:31.042 5: SH10rt_1_1: SplitDataString has no information about handling i13022
2022.09.05 19:44:31.042 5: SH10rt_1_1: CreateDataObjects called from ParseDataString with objList
2022.09.05 19:44:31.043 5: SH10rt_1_1: CreateDataObjects sortedList
2022.09.05 19:44:31.044 5: SH10rt_1_1: ParseDataString created 0 readings
2022.09.05 19:44:31.044 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 03dc, type i, adr 13022
2022.09.05 19:44:31.045 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 03dc, type i, adr 13022, valuesLen 1
2022.09.05 19:44:31.045 5: SH10rt_1_relay: SplitDataString has no information about handling i13022
2022.09.05 19:44:31.046 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 19:44:31.046 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 19:44:31.047 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 19:44:31.048 4: SH10rt_1_1: RelayResponse via SH10rt_1_relay_192.168.x.x, ioDev SH10rt_1_relay_192.168.x.x, current frame / read buffer: 00c70000000501040203dc, id 1, fCode 4, tid 199,
request: id 1 fc 4 i13022, len 1, tid 199, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.09 secs ago, sent 0.09 secs ago,
response: id 11, fc 4, i13022, len 1, values 03dc, tid 48
2022.09.05 19:44:31.049 5: SH10rt_1_relay_192.168.x.x: Send called from RelayResponse
2022.09.05 19:44:31.049 4: SH10rt_1_relay_192.168.x.x: Send 0030000000050b040203dc
2022.09.05 19:44:31.050 4: SH10rt_1_1: HandleResponse done, current frame / read buffer: 00c70000000501040203dc, id 1, fCode 4, tid 199,
request: id 1 fc 4 i13022, len 1, tid 199, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.09 secs ago, sent 0.09 secs ago,
response: id 11, fc 4, i13022, len 1, values 03dc, tid 48
2022.09.05 19:44:31.051 5: SH10rt_1_1: ResetExpect for HandleResponse from response to idle
2022.09.05 19:44:31.056 5: SH10rt_1_1: DropFrame called from ReadFn - drop 00c70000000501040203dc
2022.09.05 19:44:35.944 3: SH10rt_1_relay_192.168.x.x: read from TCP server connection got null -> closing
2022.09.05 19:44:35.944 3: SH10rt_1_relay_192.168.x.x: _UnDef is closing SH10rt_1_relay_192.168.x.x
2022.09.05 19:44:35.951 5: SH10rt_1_relay_192.168.x.x: Close called from UndefLDFn with noState and noDelete
2022.09.05 19:44:35.951 4: SH10rt_1_relay_192.168.x.x: Close TCP server listening connection and delete hash
2022.09.05 19:44:36.121 5: SH10rt_1_relay_192.168.x.x: Close is removing lastconn from parent device SH10rt_1_relay
2022.09.05 19:44:40.345 4: Connection accepted from SH10rt_1_relay_192.168.x.x
2022.09.05 19:44:40.345 4: SH10rt_1_relay: HandleServerConnection accepted new TCP connection as device SH10rt_1_relay_192.168.x.x
2022.09.05 19:44:40.444 5: SH10rt_1_relay_192.168.x.x: readFn buffer: 0031000000060b0413980002
2022.09.05 19:44:40.445 5: SH10rt_1_relay_192.168.x.x: ParseFrameStart called from ReadFn
2022.09.05 19:44:40.445 4: SH10rt_1_relay_192.168.x.x: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 49, dlen 6 and potential data 13980002
2022.09.05 19:44:40.445 5: SH10rt_1_relay_192.168.x.x: HandleRequest called from ReadFn
2022.09.05 19:44:40.446 5: SH10rt_1_relay_192.168.x.x: ParseRequest called from HandleRequest
2022.09.05 19:44:40.447 4: SH10rt_1_relay_192.168.x.x: HandleRequest, current frame / read buffer: 0031000000060b0413980002, id 11, fCode 4, tid 49,
request: id 11 fc 4 i5016, len 2, tid 49
2022.09.05 19:44:40.447 4: SH10rt_1_relay_192.168.x.x: RelayRequest called from HandleRequest
2022.09.05 19:44:40.448 5: SH10rt_1_relay: GetRelayIO found SH10rt_1_1 as Modbus relay forward io device for SH10rt_1_1 with id 1
2022.09.05 19:44:40.449 4: SH10rt_1_relay_192.168.x.x: RelayRequest via SH10rt_1_1, Proto TCP with id 1, current frame / read buffer: 0031000000060b0413980002, id 11, fCode 4, tid 49,
request: id 11 fc 4 i5016, len 2, tid 49, for relay device SH10rt_1_relay_192.168.x.x
2022.09.05 19:44:40.449 5: SH10rt_1_1: QueueRequest called from RelayRequest with i5016, qlen 0 from master SH10rt_1_1 for relay SH10rt_1_relay_192.168.x.x through io device SH10rt_1_1
2022.09.05 19:44:40.450 5: SH10rt_1_1: ProcessRequestQueue called from QueueRequest as direct:SH10rt_1_1, qlen 1, force, request: request: id 1 fc 4 i5016, len 2, tid 151, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.00 secs ago
2022.09.05 19:44:40.451 5: SH10rt_1_1: checkDelays commDelay, last communication with same device was 9.412 secs ago, required delay is 0.1
2022.09.05 19:44:40.452 5: SH10rt_1_1: checkDelays clientSwitchDelay is not relevant
2022.09.05 19:44:40.452 5: SH10rt_1_1: checkDelays sendDelay, last send to same device was 9.421 secs ago, required delay is 0.1
2022.09.05 19:44:40.452 5: SH10rt_1_1: checkDelays busDelayRead, last activity on bus was 9.412 secs ago, required delay is 0
2022.09.05 19:44:40.454 4: SH10rt_1_1: ProcessRequestQueue (V4.4.04 - 17.7.2021) qlen 1, sending 009700000006010413980002 via 192.168.3.160:502, read buffer empty,
request: id 1 fc 4 i5016, len 2, tid 151, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.00 secs ago
2022.09.05 19:44:40.455 5: SH10rt_1_1: Send called from ProcessRequestQueue
2022.09.05 19:44:40.456 5: DevIo_SimpleWrite SH10rt_1_1: 009700000006010413980002
2022.09.05 19:44:40.459 4: SH10rt_1_relay_192.168.x.x: HandleRequest Done, current frame / read buffer: 0031000000060b0413980002, id 11, fCode 4, tid 49,
request: id 11 fc 4 i5016, len 2, tid 49, for relay device SH10rt_1_relay_192.168.x.x
2022.09.05 19:44:40.459 5: SH10rt_1_relay_192.168.x.x: DropFrame called from ReadFn - drop 0031000000060b0413980002
2022.09.05 19:44:40.465 5: SH10rt_1_1: readFn buffer: 00970000000701040400000000
2022.09.05 19:44:40.465 5: SH10rt_1_1: ParseFrameStart called from ReadFn protocol TCP expecting id 1
2022.09.05 19:44:40.466 4: SH10rt_1_1: ParseFrameStart (TCP, master) extracted id 1, fCode 4, tid 151, dlen 7 and potential data 0400000000
2022.09.05 19:44:40.466 5: SH10rt_1_1: HandleResponse called from ReadFn
2022.09.05 19:44:40.466 5: SH10rt_1_1: ParseResponse called from HandleResponse
2022.09.05 19:44:40.467 5: SH10rt_1_1: now parsing response data objects, master is SH10rt_1_1 relay is SH10rt_1_relay
2022.09.05 19:44:40.467 5: SH10rt_1_1: ParseDataString called from HandleResponse with data hex 00000000, type i, adr 5016
2022.09.05 19:44:40.468 5: SH10rt_1_1: SplitDataString called from ParseDataString with data hex 00000000, type i, adr 5016, valuesLen 2
2022.09.05 19:44:40.468 5: SH10rt_1_1: SplitDataString has no information about handling i5016
2022.09.05 19:44:40.469 5: SH10rt_1_1: SplitDataString has no information about handling i5017
2022.09.05 19:44:40.469 5: SH10rt_1_1: CreateDataObjects called from ParseDataString with objList
2022.09.05 19:44:40.470 5: SH10rt_1_1: CreateDataObjects sortedList
2022.09.05 19:44:40.470 5: SH10rt_1_1: ParseDataString created 0 readings
2022.09.05 19:44:40.471 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 00000000, type i, adr 5016
2022.09.05 19:44:40.471 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 00000000, type i, adr 5016, valuesLen 2
2022.09.05 19:44:40.471 5: SH10rt_1_relay: SplitDataString has no information about handling i5016
2022.09.05 19:44:40.472 5: SH10rt_1_relay: SplitDataString has no information about handling i5017
2022.09.05 19:44:40.472 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 19:44:40.472 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 19:44:40.473 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 19:44:40.473 4: SH10rt_1_1: RelayResponse via SH10rt_1_relay_192.168.x.x, ioDev SH10rt_1_relay_192.168.x.x, current frame / read buffer: 00970000000701040400000000, id 1, fCode 4, tid 151,
request: id 1 fc 4 i5016, len 2, tid 151, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.02 secs ago, sent 0.02 secs ago,
response: id 11, fc 4, i5016, len 2, values 00000000, tid 49
2022.09.05 19:44:40.474 5: SH10rt_1_relay_192.168.x.x: Send called from RelayResponse
2022.09.05 19:44:40.474 4: SH10rt_1_relay_192.168.x.x: Send 0031000000070b040400000000
2022.09.05 19:44:40.475 4: SH10rt_1_1: HandleResponse done, current frame / read buffer: 00970000000701040400000000, id 1, fCode 4, tid 151,
request: id 1 fc 4 i5016, len 2, tid 151, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.03 secs ago, sent 0.02 secs ago,
response: id 11, fc 4, i5016, len 2, values 00000000, tid 49
2022.09.05 19:44:40.476 5: SH10rt_1_1: ResetExpect for HandleResponse from response to idle
2022.09.05 19:44:40.478 5: SH10rt_1_1: DropFrame called from ReadFn - drop 00970000000701040400000000
2022.09.05 19:44:40.571 5: SH10rt_1_relay_192.168.x.x: readFn buffer: 0032000000060b0432dd0001
2022.09.05 19:44:40.571 5: SH10rt_1_relay_192.168.x.x: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 19:44:40.571 4: SH10rt_1_relay_192.168.x.x: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 50, dlen 6 and potential data 32dd0001
2022.09.05 19:44:40.572 5: SH10rt_1_relay_192.168.x.x: HandleRequest called from ReadFn
2022.09.05 19:44:40.572 5: SH10rt_1_relay_192.168.x.x: ParseRequest called from HandleRequest
2022.09.05 19:44:40.573 4: SH10rt_1_relay_192.168.x.x: HandleRequest, current frame / read buffer: 0032000000060b0432dd0001, id 11, fCode 4, tid 50,
request: id 11 fc 4 i13021, len 1, tid 50
2022.09.05 19:44:40.573 4: SH10rt_1_relay_192.168.x.x: RelayRequest called from HandleRequest
2022.09.05 19:44:40.573 5: SH10rt_1_relay: GetRelayIO found SH10rt_1_1 as Modbus relay forward io device for SH10rt_1_1 with id 1
2022.09.05 19:44:40.574 4: SH10rt_1_relay_192.168.x.x: RelayRequest via SH10rt_1_1, Proto TCP with id 1, current frame / read buffer: 0032000000060b0432dd0001, id 11, fCode 4, tid 50,
request: id 11 fc 4 i13021, len 1, tid 50, for relay device SH10rt_1_relay_192.168.x.x
2022.09.05 19:44:40.574 5: SH10rt_1_1: QueueRequest called from RelayRequest with i13021, qlen 0 from master SH10rt_1_1 for relay SH10rt_1_relay_192.168.x.x through io device SH10rt_1_1
2022.09.05 19:44:40.575 5: SH10rt_1_1: ProcessRequestQueue called from QueueRequest as direct:SH10rt_1_1, qlen 1, force, request: request: id 1 fc 4 i13021, len 1, tid 158, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.00 secs ago
2022.09.05 19:44:40.576 5: SH10rt_1_1: checkDelays busDelayRead, last activity on bus was 0.109 secs ago, required delay is 0
2022.09.05 19:44:40.576 5: SH10rt_1_1: checkDelays sendDelay, last send to same device was 0.118 secs ago, required delay is 0.1
2022.09.05 19:44:40.576 5: SH10rt_1_1: checkDelays clientSwitchDelay is not relevant
2022.09.05 19:44:40.576 5: SH10rt_1_1: checkDelays commDelay, last communication with same device was 0.109 secs ago, required delay is 0.1
2022.09.05 19:44:40.578 4: SH10rt_1_1: ProcessRequestQueue (V4.4.04 - 17.7.2021) qlen 1, sending 009e00000006010432dd0001 via 192.168.3.160:502, read buffer empty,
request: id 1 fc 4 i13021, len 1, tid 158, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.00 secs ago
2022.09.05 19:44:40.579 5: SH10rt_1_1: Send called from ProcessRequestQueue
2022.09.05 19:44:40.579 5: DevIo_SimpleWrite SH10rt_1_1: 009e00000006010432dd0001
2022.09.05 19:44:40.582 4: SH10rt_1_relay_192.168.x.x: HandleRequest Done, current frame / read buffer: 0032000000060b0432dd0001, id 11, fCode 4, tid 50,
request: id 11 fc 4 i13021, len 1, tid 50, for relay device SH10rt_1_relay_192.168.x.x
2022.09.05 19:44:40.583 5: SH10rt_1_relay_192.168.x.x: DropFrame called from ReadFn - drop 0032000000060b0432dd0001
2022.09.05 19:44:40.584 5: SH10rt_1_1: readFn buffer: 009e0000000501040201d8
2022.09.05 19:44:40.585 5: SH10rt_1_1: ParseFrameStart called from ReadFn protocol TCP expecting id 1
2022.09.05 19:44:40.585 4: SH10rt_1_1: ParseFrameStart (TCP, master) extracted id 1, fCode 4, tid 158, dlen 5 and potential data 0201d8
2022.09.05 19:44:40.586 5: SH10rt_1_1: HandleResponse called from ReadFn
2022.09.05 19:44:40.586 5: SH10rt_1_1: ParseResponse called from HandleResponse
2022.09.05 19:44:40.586 5: SH10rt_1_1: now parsing response data objects, master is SH10rt_1_1 relay is SH10rt_1_relay
2022.09.05 19:44:40.587 5: SH10rt_1_1: ParseDataString called from HandleResponse with data hex 01d8, type i, adr 13021
2022.09.05 19:44:40.587 5: SH10rt_1_1: SplitDataString called from ParseDataString with data hex 01d8, type i, adr 13021, valuesLen 1
2022.09.05 19:44:40.588 5: SH10rt_1_1: SplitDataString has no information about handling i13021
2022.09.05 19:44:40.588 5: SH10rt_1_1: CreateDataObjects called from ParseDataString with objList
2022.09.05 19:44:40.588 5: SH10rt_1_1: CreateDataObjects sortedList
2022.09.05 19:44:40.589 5: SH10rt_1_1: ParseDataString created 0 readings
2022.09.05 19:44:40.589 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 01d8, type i, adr 13021
2022.09.05 19:44:40.589 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 01d8, type i, adr 13021, valuesLen 1
2022.09.05 19:44:40.590 5: SH10rt_1_relay: SplitDataString has no information about handling i13021
2022.09.05 19:44:40.590 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 19:44:40.590 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 19:44:40.591 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 19:44:40.591 4: SH10rt_1_1: RelayResponse via SH10rt_1_relay_192.168.x.x, ioDev SH10rt_1_relay_192.168.x.x, current frame / read buffer: 009e0000000501040201d8, id 1, fCode 4, tid 158,
request: id 1 fc 4 i13021, len 1, tid 158, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.02 secs ago, sent 0.02 secs ago,
response: id 11, fc 4, i13021, len 1, values 01d8, tid 50
2022.09.05 19:44:40.592 5: SH10rt_1_relay_192.168.x.x: Send called from RelayResponse
2022.09.05 19:44:40.592 4: SH10rt_1_relay_192.168.x.x: Send 0032000000050b040201d8
2022.09.05 19:44:40.593 4: SH10rt_1_1: HandleResponse done, current frame / read buffer: 009e0000000501040201d8, id 1, fCode 4, tid 158,
request: id 1 fc 4 i13021, len 1, tid 158, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.02 secs ago, sent 0.02 secs ago,
response: id 11, fc 4, i13021, len 1, values 01d8, tid 50
2022.09.05 19:44:40.593 5: SH10rt_1_1: ResetExpect for HandleResponse from response to idle
2022.09.05 19:44:40.596 5: SH10rt_1_1: DropFrame called from ReadFn - drop 009e0000000501040201d8
2022.09.05 19:44:40.599 5: SH10rt_1_relay_192.168.x.x: readFn buffer: 0033000000060b0432c80001
2022.09.05 19:44:40.599 5: SH10rt_1_relay_192.168.x.x: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 19:44:40.599 4: SH10rt_1_relay_192.168.x.x: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 51, dlen 6 and potential data 32c80001
2022.09.05 19:44:40.600 5: SH10rt_1_relay_192.168.x.x: HandleRequest called from ReadFn
2022.09.05 19:44:40.600 5: SH10rt_1_relay_192.168.x.x: ParseRequest called from HandleRequest
2022.09.05 19:44:40.601 4: SH10rt_1_relay_192.168.x.x: HandleRequest, current frame / read buffer: 0033000000060b0432c80001, id 11, fCode 4, tid 51,
request: id 11 fc 4 i13000, len 1, tid 51
2022.09.05 19:44:40.601 4: SH10rt_1_relay_192.168.x.x: RelayRequest called from HandleRequest
2022.09.05 19:44:40.602 5: SH10rt_1_relay: GetRelayIO found SH10rt_1_1 as Modbus relay forward io device for SH10rt_1_1 with id 1
2022.09.05 19:44:40.602 4: SH10rt_1_relay_192.168.x.x: RelayRequest via SH10rt_1_1, Proto TCP with id 1, current frame / read buffer: 0033000000060b0432c80001, id 11, fCode 4, tid 51,
request: id 11 fc 4 i13000, len 1, tid 51, for relay device SH10rt_1_relay_192.168.x.x
2022.09.05 19:44:40.603 5: SH10rt_1_1: QueueRequest called from RelayRequest with i13000, qlen 0 from master SH10rt_1_1 for relay SH10rt_1_relay_192.168.x.x through io device SH10rt_1_1
2022.09.05 19:44:40.603 5: SH10rt_1_1: ProcessRequestQueue called from QueueRequest as direct:SH10rt_1_1, qlen 1, force, request: request: id 1 fc 4 i13000, len 1, tid 44, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.00 secs ago
2022.09.05 19:44:40.604 5: SH10rt_1_1: checkDelays clientSwitchDelay is not relevant
2022.09.05 19:44:40.604 5: SH10rt_1_1: checkDelays sendDelay, last send to same device was 0.023 secs ago, required delay is 0.1
2022.09.05 19:44:40.604 5: SH10rt_1_1: checkDelays busDelayRead, last activity on bus was 0.018 secs ago, required delay is 0
2022.09.05 19:44:40.605 5: SH10rt_1_1: checkDelays commDelay, last communication with same device was 0.018 secs ago, required delay is 0.1
2022.09.05 19:44:40.605 4: SH10rt_1_1: checkDelays found commDelay not over, sleep for 0.082 forced
2022.09.05 19:44:40.687 4: SH10rt_1_1: checkDelays sleep done, go on with sending
2022.09.05 19:44:40.690 4: SH10rt_1_1: ProcessRequestQueue (V4.4.04 - 17.7.2021) qlen 1, sending 002c00000006010432c80001 via 192.168.3.160:502, read buffer empty,
request: id 1 fc 4 i13000, len 1, tid 44, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.09 secs ago
2022.09.05 19:44:40.690 5: SH10rt_1_1: Send called from ProcessRequestQueue
2022.09.05 19:44:40.691 5: DevIo_SimpleWrite SH10rt_1_1: 002c00000006010432c80001
2022.09.05 19:44:40.694 4: SH10rt_1_relay_192.168.x.x: HandleRequest Done, current frame / read buffer: 0033000000060b0432c80001, id 11, fCode 4, tid 51,
request: id 11 fc 4 i13000, len 1, tid 51, for relay device SH10rt_1_relay_192.168.x.x
2022.09.05 19:44:40.695 5: SH10rt_1_relay_192.168.x.x: DropFrame called from ReadFn - drop 0033000000060b0432c80001
2022.09.05 19:44:40.697 5: SH10rt_1_1: readFn buffer: 002c000000050104020000
2022.09.05 19:44:40.698 5: SH10rt_1_1: ParseFrameStart called from ReadFn protocol TCP expecting id 1
2022.09.05 19:44:40.698 4: SH10rt_1_1: ParseFrameStart (TCP, master) extracted id 1, fCode 4, tid 44, dlen 5 and potential data 020000
2022.09.05 19:44:40.699 5: SH10rt_1_1: HandleResponse called from ReadFn
2022.09.05 19:44:40.699 5: SH10rt_1_1: ParseResponse called from HandleResponse
2022.09.05 19:44:40.700 5: SH10rt_1_1: now parsing response data objects, master is SH10rt_1_1 relay is SH10rt_1_relay
2022.09.05 19:44:40.701 5: SH10rt_1_1: ParseDataString called from HandleResponse with data hex 0000, type i, adr 13000
2022.09.05 19:44:40.701 5: SH10rt_1_1: SplitDataString called from ParseDataString with data hex 0000, type i, adr 13000, valuesLen 1
2022.09.05 19:44:40.702 5: SH10rt_1_1: SplitDataString has no information about handling i13000
2022.09.05 19:44:40.702 5: SH10rt_1_1: CreateDataObjects called from ParseDataString with objList
2022.09.05 19:44:40.702 5: SH10rt_1_1: CreateDataObjects sortedList
2022.09.05 19:44:40.703 5: SH10rt_1_1: ParseDataString created 0 readings
2022.09.05 19:44:40.703 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 0000, type i, adr 13000
2022.09.05 19:44:40.704 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 0000, type i, adr 13000, valuesLen 1
2022.09.05 19:44:40.704 5: SH10rt_1_relay: SplitDataString has no information about handling i13000
2022.09.05 19:44:40.705 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 19:44:40.705 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 19:44:40.706 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 19:44:40.706 4: SH10rt_1_1: RelayResponse via SH10rt_1_relay_192.168.x.x, ioDev SH10rt_1_relay_192.168.x.x, current frame / read buffer: 002c000000050104020000, id 1, fCode 4, tid 44,
request: id 1 fc 4 i13000, len 1, tid 44, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.10 secs ago, sent 0.10 secs ago,
response: id 11, fc 4, i13000, len 1, values 0000, tid 51
2022.09.05 19:44:40.707 5: SH10rt_1_relay_192.168.x.x: Send called from RelayResponse
2022.09.05 19:44:40.707 4: SH10rt_1_relay_192.168.x.x: Send 0033000000050b04020000
2022.09.05 19:44:40.708 4: SH10rt_1_1: HandleResponse done, current frame / read buffer: 002c000000050104020000, id 1, fCode 4, tid 44,
request: id 1 fc 4 i13000, len 1, tid 44, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.11 secs ago, sent 0.11 secs ago,
response: id 11, fc 4, i13000, len 1, values 0000, tid 51
2022.09.05 19:44:40.709 5: SH10rt_1_1: ResetExpect for HandleResponse from response to idle
2022.09.05 19:44:40.712 5: SH10rt_1_1: DropFrame called from ReadFn - drop 002c000000050104020000
2022.09.05 19:44:40.748 5: SH10rt_1_relay_192.168.x.x: readFn buffer: 0034000000060b0432c80001
2022.09.05 19:44:40.749 5: SH10rt_1_relay_192.168.x.x: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 19:44:40.749 4: SH10rt_1_relay_192.168.x.x: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 52, dlen 6 and potential data 32c80001
2022.09.05 19:44:40.749 5: SH10rt_1_relay_192.168.x.x: HandleRequest called from ReadFn
2022.09.05 19:44:40.750 5: SH10rt_1_relay_192.168.x.x: ParseRequest called from HandleRequest
2022.09.05 19:44:40.750 4: SH10rt_1_relay_192.168.x.x: HandleRequest, current frame / read buffer: 0034000000060b0432c80001, id 11, fCode 4, tid 52,
request: id 11 fc 4 i13000, len 1, tid 52
2022.09.05 19:44:40.751 4: SH10rt_1_relay_192.168.x.x: RelayRequest called from HandleRequest
2022.09.05 19:44:40.751 5: SH10rt_1_relay: GetRelayIO found SH10rt_1_1 as Modbus relay forward io device for SH10rt_1_1 with id 1
2022.09.05 19:44:40.751 4: SH10rt_1_relay_192.168.x.x: RelayRequest via SH10rt_1_1, Proto TCP with id 1, current frame / read buffer: 0034000000060b0432c80001, id 11, fCode 4, tid 52,
request: id 11 fc 4 i13000, len 1, tid 52, for relay device SH10rt_1_relay_192.168.x.x
2022.09.05 19:44:40.752 5: SH10rt_1_1: QueueRequest called from RelayRequest with i13000, qlen 0 from master SH10rt_1_1 for relay SH10rt_1_relay_192.168.x.x through io device SH10rt_1_1
2022.09.05 19:44:40.752 5: SH10rt_1_1: ProcessRequestQueue called from QueueRequest as direct:SH10rt_1_1, qlen 1, force, request: request: id 1 fc 4 i13000, len 1, tid 121, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.00 secs ago
2022.09.05 19:44:40.753 5: SH10rt_1_1: checkDelays commDelay, last communication with same device was 0.054 secs ago, required delay is 0.1
2022.09.05 19:44:40.753 5: SH10rt_1_1: checkDelays sendDelay, last send to same device was 0.060 secs ago, required delay is 0.1
2022.09.05 19:44:40.754 5: SH10rt_1_1: checkDelays busDelayRead, last activity on bus was 0.054 secs ago, required delay is 0
2022.09.05 19:44:40.754 5: SH10rt_1_1: checkDelays clientSwitchDelay is not relevant
2022.09.05 19:44:40.754 4: SH10rt_1_1: checkDelays found commDelay not over, sleep for 0.046 forced
2022.09.05 19:44:40.800 4: SH10rt_1_1: checkDelays sleep done, go on with sending
2022.09.05 19:44:40.802 4: SH10rt_1_1: ProcessRequestQueue (V4.4.04 - 17.7.2021) qlen 1, sending 007900000006010432c80001 via 192.168.3.160:502, read buffer empty,
request: id 1 fc 4 i13000, len 1, tid 121, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.05 secs ago
2022.09.05 19:44:40.803 5: SH10rt_1_1: Send called from ProcessRequestQueue
2022.09.05 19:44:40.803 5: DevIo_SimpleWrite SH10rt_1_1: 007900000006010432c80001
2022.09.05 19:44:40.806 4: SH10rt_1_relay_192.168.x.x: HandleRequest Done, current frame / read buffer: 0034000000060b0432c80001, id 11, fCode 4, tid 52,
request: id 11 fc 4 i13000, len 1, tid 52, for relay device SH10rt_1_relay_192.168.x.x
2022.09.05 19:44:40.807 5: SH10rt_1_relay_192.168.x.x: DropFrame called from ReadFn - drop 0034000000060b0432c80001
2022.09.05 19:44:40.810 5: SH10rt_1_1: readFn buffer: 0079000000050104020000
2022.09.05 19:44:40.810 5: SH10rt_1_1: ParseFrameStart called from ReadFn protocol TCP expecting id 1
2022.09.05 19:44:40.810 4: SH10rt_1_1: ParseFrameStart (TCP, master) extracted id 1, fCode 4, tid 121, dlen 5 and potential data 020000
2022.09.05 19:44:40.811 5: SH10rt_1_1: HandleResponse called from ReadFn
2022.09.05 19:44:40.811 5: SH10rt_1_1: ParseResponse called from HandleResponse
2022.09.05 19:44:40.812 5: SH10rt_1_1: now parsing response data objects, master is SH10rt_1_1 relay is SH10rt_1_relay
2022.09.05 19:44:40.812 5: SH10rt_1_1: ParseDataString called from HandleResponse with data hex 0000, type i, adr 13000
2022.09.05 19:44:40.812 5: SH10rt_1_1: SplitDataString called from ParseDataString with data hex 0000, type i, adr 13000, valuesLen 1
2022.09.05 19:44:40.813 5: SH10rt_1_1: SplitDataString has no information about handling i13000
2022.09.05 19:44:40.813 5: SH10rt_1_1: CreateDataObjects called from ParseDataString with objList
2022.09.05 19:44:40.813 5: SH10rt_1_1: CreateDataObjects sortedList
2022.09.05 19:44:40.814 5: SH10rt_1_1: ParseDataString created 0 readings
2022.09.05 19:44:40.814 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 0000, type i, adr 13000
2022.09.05 19:44:40.814 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 0000, type i, adr 13000, valuesLen 1
2022.09.05 19:44:40.815 5: SH10rt_1_relay: SplitDataString has no information about handling i13000
2022.09.05 19:44:40.815 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 19:44:40.815 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 19:44:40.816 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 19:44:40.816 4: SH10rt_1_1: RelayResponse via SH10rt_1_relay_192.168.x.x, ioDev SH10rt_1_relay_192.168.x.x, current frame / read buffer: 0079000000050104020000, id 1, fCode 4, tid 121,
request: id 1 fc 4 i13000, len 1, tid 121, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.06 secs ago, sent 0.06 secs ago,
response: id 11, fc 4, i13000, len 1, values 0000, tid 52
2022.09.05 19:44:40.817 5: SH10rt_1_relay_192.168.x.x: Send called from RelayResponse
2022.09.05 19:44:40.817 4: SH10rt_1_relay_192.168.x.x: Send 0034000000050b04020000
2022.09.05 19:44:40.818 4: SH10rt_1_1: HandleResponse done, current frame / read buffer: 0079000000050104020000, id 1, fCode 4, tid 121,
request: id 1 fc 4 i13000, len 1, tid 121, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.07 secs ago, sent 0.07 secs ago,
response: id 11, fc 4, i13000, len 1, values 0000, tid 52
2022.09.05 19:44:40.818 5: SH10rt_1_1: ResetExpect for HandleResponse from response to idle
2022.09.05 19:44:40.821 5: SH10rt_1_1: DropFrame called from ReadFn - drop 0079000000050104020000
2022.09.05 19:44:40.824 5: SH10rt_1_relay_192.168.x.x: readFn buffer: 0035000000060b0432d10002
2022.09.05 19:44:40.824 5: SH10rt_1_relay_192.168.x.x: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 19:44:40.825 4: SH10rt_1_relay_192.168.x.x: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 53, dlen 6 and potential data 32d10002
2022.09.05 19:44:40.825 5: SH10rt_1_relay_192.168.x.x: HandleRequest called from ReadFn
2022.09.05 19:44:40.825 5: SH10rt_1_relay_192.168.x.x: ParseRequest called from HandleRequest
2022.09.05 19:44:40.826 4: SH10rt_1_relay_192.168.x.x: HandleRequest, current frame / read buffer: 0035000000060b0432d10002, id 11, fCode 4, tid 53,
request: id 11 fc 4 i13009, len 2, tid 53
2022.09.05 19:44:40.826 4: SH10rt_1_relay_192.168.x.x: RelayRequest called from HandleRequest
2022.09.05 19:44:40.827 5: SH10rt_1_relay: GetRelayIO found SH10rt_1_1 as Modbus relay forward io device for SH10rt_1_1 with id 1
2022.09.05 19:44:40.827 4: SH10rt_1_relay_192.168.x.x: RelayRequest via SH10rt_1_1, Proto TCP with id 1, current frame / read buffer: 0035000000060b0432d10002, id 11, fCode 4, tid 53,
request: id 11 fc 4 i13009, len 2, tid 53, for relay device SH10rt_1_relay_192.168.x.x
2022.09.05 19:44:40.827 5: SH10rt_1_1: QueueRequest called from RelayRequest with i13009, qlen 0 from master SH10rt_1_1 for relay SH10rt_1_relay_192.168.x.x through io device SH10rt_1_1
2022.09.05 19:44:40.828 5: SH10rt_1_1: ProcessRequestQueue called from QueueRequest as direct:SH10rt_1_1, qlen 1, force, request: request: id 1 fc 4 i13009, len 2, tid 23, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.00 secs ago
2022.09.05 19:44:40.829 5: SH10rt_1_1: checkDelays commDelay, last communication with same device was 0.017 secs ago, required delay is 0.1
2022.09.05 19:44:40.829 5: SH10rt_1_1: checkDelays sendDelay, last send to same device was 0.024 secs ago, required delay is 0.1
2022.09.05 19:44:40.829 5: SH10rt_1_1: checkDelays busDelayRead, last activity on bus was 0.017 secs ago, required delay is 0
2022.09.05 19:44:40.830 5: SH10rt_1_1: checkDelays clientSwitchDelay is not relevant
2022.09.05 19:44:40.830 4: SH10rt_1_1: checkDelays found commDelay not over, sleep for 0.083 forced
2022.09.05 19:44:40.913 4: SH10rt_1_1: checkDelays sleep done, go on with sending
2022.09.05 19:44:40.915 4: SH10rt_1_1: ProcessRequestQueue (V4.4.04 - 17.7.2021) qlen 1, sending 001700000006010432d10002 via 192.168.3.160:502, read buffer empty,
request: id 1 fc 4 i13009, len 2, tid 23, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.09 secs ago
2022.09.05 19:44:40.916 5: SH10rt_1_1: Send called from ProcessRequestQueue
2022.09.05 19:44:40.916 5: DevIo_SimpleWrite SH10rt_1_1: 001700000006010432d10002
2022.09.05 19:44:40.919 4: SH10rt_1_relay_192.168.x.x: HandleRequest Done, current frame / read buffer: 0035000000060b0432d10002, id 11, fCode 4, tid 53,
request: id 11 fc 4 i13009, len 2, tid 53, for relay device SH10rt_1_relay_192.168.x.x
2022.09.05 19:44:40.920 5: SH10rt_1_relay_192.168.x.x: DropFrame called from ReadFn - drop 0035000000060b0432d10002
2022.09.05 19:44:40.976 5: SH10rt_1_1: readFn buffer: 001700000007010404fff2ffff
2022.09.05 19:44:40.979 5: SH10rt_1_1: ParseFrameStart called from ReadFn protocol TCP expecting id 1
2022.09.05 19:44:40.984 4: SH10rt_1_1: ParseFrameStart (TCP, master) extracted id 1, fCode 4, tid 23, dlen 7 and potential data 04fff2ffff
2022.09.05 19:44:40.985 5: SH10rt_1_1: HandleResponse called from ReadFn
2022.09.05 19:44:40.986 5: SH10rt_1_1: ParseResponse called from HandleResponse
2022.09.05 19:44:40.987 5: SH10rt_1_1: now parsing response data objects, master is SH10rt_1_1 relay is SH10rt_1_relay
2022.09.05 19:44:40.989 5: SH10rt_1_1: ParseDataString called from HandleResponse with data hex fff2ffff, type i, adr 13009
2022.09.05 19:44:40.990 5: SH10rt_1_1: SplitDataString called from ParseDataString with data hex fff2ffff, type i, adr 13009, valuesLen 2
2022.09.05 19:44:40.991 5: SH10rt_1_1: SplitDataString has no information about handling i13009
2022.09.05 19:44:40.992 5: SH10rt_1_1: SplitDataString has no information about handling i13010
2022.09.05 19:44:40.993 5: SH10rt_1_1: CreateDataObjects called from ParseDataString with objList
2022.09.05 19:44:40.994 5: SH10rt_1_1: CreateDataObjects sortedList
2022.09.05 19:44:40.996 5: SH10rt_1_1: ParseDataString created 0 readings
2022.09.05 19:44:40.996 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex fff2ffff, type i, adr 13009
2022.09.05 19:44:40.997 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex fff2ffff, type i, adr 13009, valuesLen 2
2022.09.05 19:44:40.998 5: SH10rt_1_relay: SplitDataString has no information about handling i13009
2022.09.05 19:44:40.998 5: SH10rt_1_relay: SplitDataString has no information about handling i13010
2022.09.05 19:44:40.999 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 19:44:40.999 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 19:44:41.000 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 19:44:41.001 4: SH10rt_1_1: RelayResponse via SH10rt_1_relay_192.168.x.x, ioDev SH10rt_1_relay_192.168.x.x, current frame / read buffer: 001700000007010404fff2ffff, id 1, fCode 4, tid 23,
request: id 1 fc 4 i13009, len 2, tid 23, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.17 secs ago, sent 0.17 secs ago,
response: id 11, fc 4, i13009, len 2, values fff2ffff, tid 53
2022.09.05 19:44:41.002 5: SH10rt_1_relay_192.168.x.x: Send called from RelayResponse
2022.09.05 19:44:41.003 4: SH10rt_1_relay_192.168.x.x: Send 0035000000070b0404fff2ffff
2022.09.05 19:44:41.004 4: SH10rt_1_1: HandleResponse done, current frame / read buffer: 001700000007010404fff2ffff, id 1, fCode 4, tid 23,
request: id 1 fc 4 i13009, len 2, tid 23, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.18 secs ago, sent 0.18 secs ago,
response: id 11, fc 4, i13009, len 2, values fff2ffff, tid 53
2022.09.05 19:44:41.005 5: SH10rt_1_1: ResetExpect for HandleResponse from response to idle
2022.09.05 19:44:41.011 5: SH10rt_1_1: DropFrame called from ReadFn - drop 001700000007010404fff2ffff
2022.09.05 19:44:41.030 5: SH10rt_1_relay_192.168.x.x: readFn buffer: 0036000000060b0432de0001
2022.09.05 19:44:41.030 5: SH10rt_1_relay_192.168.x.x: ParseFrameStart called from ReadFn protocol TCP expecting id 11
2022.09.05 19:44:41.031 4: SH10rt_1_relay_192.168.x.x: ParseFrameStart (TCP, relay) extracted id 11, fCode 4, tid 54, dlen 6 and potential data 32de0001
2022.09.05 19:44:41.031 5: SH10rt_1_relay_192.168.x.x: HandleRequest called from ReadFn
2022.09.05 19:44:41.032 5: SH10rt_1_relay_192.168.x.x: ParseRequest called from HandleRequest
2022.09.05 19:44:41.033 4: SH10rt_1_relay_192.168.x.x: HandleRequest, current frame / read buffer: 0036000000060b0432de0001, id 11, fCode 4, tid 54,
request: id 11 fc 4 i13022, len 1, tid 54
2022.09.05 19:44:41.033 4: SH10rt_1_relay_192.168.x.x: RelayRequest called from HandleRequest
2022.09.05 19:44:41.034 5: SH10rt_1_relay: GetRelayIO found SH10rt_1_1 as Modbus relay forward io device for SH10rt_1_1 with id 1
2022.09.05 19:44:41.035 4: SH10rt_1_relay_192.168.x.x: RelayRequest via SH10rt_1_1, Proto TCP with id 1, current frame / read buffer: 0036000000060b0432de0001, id 11, fCode 4, tid 54,
request: id 11 fc 4 i13022, len 1, tid 54, for relay device SH10rt_1_relay_192.168.x.x
2022.09.05 19:44:41.035 5: SH10rt_1_1: QueueRequest called from RelayRequest with i13022, qlen 0 from master SH10rt_1_1 for relay SH10rt_1_relay_192.168.x.x through io device SH10rt_1_1
2022.09.05 19:44:41.036 5: SH10rt_1_1: ProcessRequestQueue called from QueueRequest as direct:SH10rt_1_1, qlen 1, force, request: request: id 1 fc 4 i13022, len 1, tid 100, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.00 secs ago
2022.09.05 19:44:41.037 5: SH10rt_1_1: checkDelays sendDelay, last send to same device was 0.119 secs ago, required delay is 0.1
2022.09.05 19:44:41.038 5: SH10rt_1_1: checkDelays clientSwitchDelay is not relevant
2022.09.05 19:44:41.038 5: SH10rt_1_1: checkDelays busDelayRead, last activity on bus was 0.051 secs ago, required delay is 0
2022.09.05 19:44:41.038 5: SH10rt_1_1: checkDelays commDelay, last communication with same device was 0.051 secs ago, required delay is 0.1
2022.09.05 19:44:41.039 4: SH10rt_1_1: checkDelays found commDelay not over, sleep for 0.049 forced
2022.09.05 19:44:41.088 4: SH10rt_1_1: checkDelays sleep done, go on with sending
2022.09.05 19:44:41.090 4: SH10rt_1_1: ProcessRequestQueue (V4.4.04 - 17.7.2021) qlen 1, sending 006400000006010432de0001 via 192.168.3.160:502, read buffer empty,
request: id 1 fc 4 i13022, len 1, tid 100, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.05 secs ago
2022.09.05 19:44:41.091 5: SH10rt_1_1: Send called from ProcessRequestQueue
2022.09.05 19:44:41.091 5: DevIo_SimpleWrite SH10rt_1_1: 006400000006010432de0001
2022.09.05 19:44:41.094 4: SH10rt_1_relay_192.168.x.x: HandleRequest Done, current frame / read buffer: 0036000000060b0432de0001, id 11, fCode 4, tid 54,
request: id 11 fc 4 i13022, len 1, tid 54, for relay device SH10rt_1_relay_192.168.x.x
2022.09.05 19:44:41.095 5: SH10rt_1_relay_192.168.x.x: DropFrame called from ReadFn - drop 0036000000060b0432de0001
2022.09.05 19:44:41.101 5: SH10rt_1_1: readFn buffer: 00640000000501040203dc
2022.09.05 19:44:41.101 5: SH10rt_1_1: ParseFrameStart called from ReadFn protocol TCP expecting id 1
2022.09.05 19:44:41.102 4: SH10rt_1_1: ParseFrameStart (TCP, master) extracted id 1, fCode 4, tid 100, dlen 5 and potential data 0203dc
2022.09.05 19:44:41.102 5: SH10rt_1_1: HandleResponse called from ReadFn
2022.09.05 19:44:41.102 5: SH10rt_1_1: ParseResponse called from HandleResponse
2022.09.05 19:44:41.103 5: SH10rt_1_1: now parsing response data objects, master is SH10rt_1_1 relay is SH10rt_1_relay
2022.09.05 19:44:41.103 5: SH10rt_1_1: ParseDataString called from HandleResponse with data hex 03dc, type i, adr 13022
2022.09.05 19:44:41.104 5: SH10rt_1_1: SplitDataString called from ParseDataString with data hex 03dc, type i, adr 13022, valuesLen 1
2022.09.05 19:44:41.104 5: SH10rt_1_1: SplitDataString has no information about handling i13022
2022.09.05 19:44:41.104 5: SH10rt_1_1: CreateDataObjects called from ParseDataString with objList
2022.09.05 19:44:41.105 5: SH10rt_1_1: CreateDataObjects sortedList
2022.09.05 19:44:41.105 5: SH10rt_1_1: ParseDataString created 0 readings
2022.09.05 19:44:41.105 5: SH10rt_1_relay: ParseDataString called from HandleResponse with data hex 03dc, type i, adr 13022
2022.09.05 19:44:41.106 5: SH10rt_1_relay: SplitDataString called from ParseDataString with data hex 03dc, type i, adr 13022, valuesLen 1
2022.09.05 19:44:41.106 5: SH10rt_1_relay: SplitDataString has no information about handling i13022
2022.09.05 19:44:41.106 5: SH10rt_1_relay: CreateDataObjects called from ParseDataString with objList
2022.09.05 19:44:41.107 5: SH10rt_1_relay: CreateDataObjects sortedList
2022.09.05 19:44:41.107 5: SH10rt_1_relay: ParseDataString created 0 readings
2022.09.05 19:44:41.108 4: SH10rt_1_1: RelayResponse via SH10rt_1_relay_192.168.x.x, ioDev SH10rt_1_relay_192.168.x.x, current frame / read buffer: 00640000000501040203dc, id 1, fCode 4, tid 100,
request: id 1 fc 4 i13022, len 1, tid 100, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.07 secs ago, sent 0.07 secs ago,
response: id 11, fc 4, i13022, len 1, values 03dc, tid 54
2022.09.05 19:44:41.108 5: SH10rt_1_relay_192.168.x.x: Send called from RelayResponse
2022.09.05 19:44:41.109 4: SH10rt_1_relay_192.168.x.x: Send 0036000000050b040203dc
2022.09.05 19:44:41.109 4: SH10rt_1_1: HandleResponse done, current frame / read buffer: 00640000000501040203dc, id 1, fCode 4, tid 100,
request: id 1 fc 4 i13022, len 1, tid 100, master device SH10rt_1_1, for relay device SH10rt_1_relay_192.168.x.x (relayed), queued 0.07 secs ago, sent 0.07 secs ago,
response: id 11, fc 4, i13022, len 1, values 03dc, tid 54
2022.09.05 19:44:41.110 5: SH10rt_1_1: ResetExpect for HandleResponse from response to idle
2022.09.05 19:44:41.112 5: SH10rt_1_1: DropFrame called from ReadFn - drop 00640000000501040203dc
2022.09.05 19:44:46.094 3: SH10rt_1_relay_192.168.x.x: read from TCP server connection got null -> closing
2022.09.05 19:44:46.101 3: SH10rt_1_relay_192.168.x.x: _UnDef is closing SH10rt_1_relay_192.168.x.x
2022.09.05 19:44:46.102 5: SH10rt_1_relay_192.168.x.x: Close called from UndefLDFn with noState and noDelete
2022.09.05 19:44:46.102 4: SH10rt_1_relay_192.168.x.x: Close TCP server listening connection and delete hash
2022.09.05 19:44:46.105 5: SH10rt_1_relay_192.168.x.x: Close is removing lastconn from parent device SH10rt_1_relay
Ich hatte außerdem mal die Modbus ID des einen Relays auf 12 geändert, damit nicht beide die gleiche ID haben (11), aber das scheint keinen Unterschied zu machen.
Hallo FhemPiUser,
wenn Du Deinen Wechselrichter mit mehreren Mastern anfragst, dann wird das Probleme geben. Soweit ich mich erinnere, verkraftet der nur einen Kommunikationspartner.
Ich gehe auch davon aus, dass das Speicherleck nicht von einem Bug im Modul kommt sondern vom einem Bug in Deinem Perl-Interpreter. Vermutlich wird der getriggert, wenn die Abfragen von evcc vom Relay über Dein Master-Device geleitet werden, in dem selbst eine zyklische Abfrage und viele Register definiert sind.
Eine andere Perl-Version oder ein Relay in einer VM auf einem anderen OS etc. könnten den Bug eventuell auch umgehen.
Zum Testen wäre es aber sehr hilfreich, wenn wir die Relay-Funktion von Deinen eigenen Abfragen und der Interpretation der Objekte trennen könnten.
Du könntest auch das Relay auf einem weiteren Pi aufsetzen und dann sowohl evcc als auch Deine eigenen Abfragen über dieses zusätzliche Relay schicken. Haupsache in der Fhem-Instanz mit dem Relay laufen keine weiteren Abfragen und keine Aufbereitung der Register ...
Gruß
Stefan
Merkwürdigerweise gibt es keine Probleme mit dem Wechselrichter, obwohl ich mit mehreren Mastern anfrage (wie beschrieben zwei neue devices SH10rt_1_1 & SH10rt_2_1 zusätzlich zu SH10rt_1 und SH10rt_2). Evtl. weil die Anfragen von der gleichen IP-Adresse kommen. Jedenfalls trat das Speicherleck wieder auf, auch mit den leeren devices SH10rt_1_1 & SH10rt_2_1, an die der relay weiterleitet.
Wenn das nicht weiterhilft, müsste ich mal den Vorschlag mit dem weiteren Pi aufgreifen. Ich würde dann eine frische fhem Installation auf dem zweiten Pi machen und dort nur den relay und die leeren master devices SH10rt_1_1 & SH10rt_2_1 einrichten und evcc auf den relay auf dem zweiten pi konfigurieren - in der Hoffnugn der Wechselrichter kriegt das dann hin, da dann ja die Anfragen von einer anderen IP Adresse kommen. Würde der Test helfen?
Update: Habe das jetzt so umgestellt wie von Dir empfohlen, d.h. eigene fhem Instanz auf eigenem Pi, auf dem nur die Relays (die evcc abfragen) und die dazugehörigen leeren Master-Device SH10rt_1_1 & SH10rt_2_1 (die wiederum den WR abfragen) laufen. Das funktioniert. Was soll ich nun testen?
P.S.: Interessanterweise lehnt der WR die Verbindungen ab, wenn evcc direkt mit dem WR spricht. Es funktioniert aber mit dem fhem modbusattr relay dazwischen (der auf dem gleichem Pi läuft wie evcc).
Ok, wenn das Problem auf dem separaten Pi auch auftritt obwohl nur noch die Relay-Funktion aktiv ist und keine eigenen Abfragen mehr gemacht werden, dann müssten wir es identifizieren und beheben können.
Dazu bräuchte ich die vollständige Konfiguration und ausführliche Logs wobei alle Modbus-Devices auf verbose 5 stehen. Am besten über den ganzen Zeitraum, in dem man einen signifikanten Speicheranstieg sehe kann.
Gruß Stefan
Nach 2 Seiten individueller Thematik, die nichts mit freezemon zu tun hat: Ist es nicht sinniger das Thema in einem eigenen Thread abzuhandeln ? ::)
Habe ein neues Thema dafür erstellt unter folgendem Link: https://forum.fhem.de/index.php/topic,129098.0.html (https://forum.fhem.de/index.php/topic,129098.0.html)
Hi Oli,
bist ja wieder etwas mehr aktiv(freu).
Ich hab da einen freeze, den mein Modul verursacht. >:(
Wenn ich fhem stoppe, läuft FHEM komischerweise wieder und fährt runter. ???
Es wird dann auch der freezemon-Eintrag gelogged.
2023.03.17 22:44:46 1: [Freezemon] freezedetect: possible freeze starting at 23:45:37, delay is 82749.8 possibly caused by: no bad guy found :-(Nur weder am 16.3., noch am 17.3. steht irgendetwas in meinen täglichen freezemon-Logs. War die Dauer zu lang ?
Ein anderer Rpi hatte 16.3. 23:45 dasselbe Problem. Der fährt FHEM aber automatisch und schneller runter. Da fand ich Einträge im freezemon-Log.2023.03.17 00:15:56.475 5: [Freezemon] freezedetect: ----------- Starting Freeze handling at 2023.03.17 00:15:56.475 ---------------------
[Freezemon] freezedetect: possible freeze starting at 23:45:37, delay is 1819.474 possibly caused by: no bad guy found :-(-
Idee ?
Grüße Markus
EDIT: Wenn es gewünscht wird könnte ich hierfür auch einen eigenen Thread aufmachen.
Hallo zusammen,
seit gestern habe nun auch freezemon aktiviert, da es immer wieder zu kleinen warte Zeiten kommt.
Ich habe keine spezielle Konfiguration gemacht, da ich das Modul noch nicht kenne und so auch schon Meldungen im Log erscheinen :-)
Diese Meldung kann ich bisher gar nicht zuordnen, was könnte das denn sein?
2023.06.02 10:18:04.859 1: [Freezemon] myFreezemon: possible freeze starting at 10:18:03, delay is 1.858 possibly caused by: tmr-CODE(0x5566547368)(ProcessRequestQueue) tmr-CODE(0x5566547368)(ProcessRequestQueue)
Könnte ich zur besseren Diagnose noch irgendwelche Einstellungen im freezemon vornehmen?
Was bisher geschah :-)
Ich habe stündlich eine KI Prognose für die PV-Anlage, bei der das SQL SELECT als Prozedur im MySQL Docker Container ca. 70 Sekunden läuft.
Danach wird asynchron ein Python Skript mit ebenfalls ca. 60 Sekunden gestartet. Das ganze wird NonBlocking mit DbRep ausgeführt und
erscheint somit auch nicht beim freezemon. Zur Ausführungszeit geht die RPI4 CPU Zeit von MySQL und anschließend vom Python Skript
auf 100%, was jedoch anscheinend keinen direkten Einfluss auf FHEM zuhaben scheint.
Dann taucht manchmal tmr-DbLog_execMemCacheAsync(LogDB_2) auf, was wohl durch das PV-Anlagen Logging mit dem Wegschreiben in die DB zusammen hängt.
Ein tmr-HttpUtils_TimeoutErr(N/A), manchmal alle 6 Minuten habe ich wohl schon gefunden, da dort das selbe HTTPMOD Device direkt
hintereinander mit unterschiedlichem Kommando aufgerufen wurde.
Das habe ich jetzt mit einer timer Verzögerung im DOIF etwas verschoben. Jetzt scheint es besser zu passen.
Ich habe bereits einige Funktionalitäten zu Docker Containern ausgelagert, was bereits seit 2019 zu einem flüssigeren und stabielerem Ablauf geführt hat.
fhem_2022_fhem_1 fhem/fhem:latest
fhem_2022_grafana_old_1 grafana/grafana:7.5.11
fhem_2022_mysql_1 mysql/mysql-server
fhem_2022_node-red_ nodered/node-red:latest
fhem_2022_portainer_1 portainer/portainer:latest
fhem_2022_sonos_1 ghcr.io/svrooij/sonos2mqtt
fhem_2022_vallox_1 mruettgers/vallox-mqtt-bridge:latest
fhem_2022_zigbee2mqtt_1 koenkk/zigbee2mqtt:latest
VG Christian
Hallo in die Runde
Habe vergangenen Sonntag ein komplettes FHEM-Update gemacht (ansonsten in diesem Jahr immer bisher nur Module einzeln).
Lt. Log war 98_freezemon.pm im Update nicht dabei - letzte Version Oktober 2021. Ich hatte in der Vergangenheit mal zum Test ein Freezemon definiert - ich meine es wäre zwischnzeitlich inaktiv gesetzt worden.
Lt. aktueller fhem.cfg ist das Device weg ??? Im RestoreVerzeichnis von Sonntag steht noch:
define FreezeMon freezemon
setuuid FreezeMon 63a5bf25-f33f-a8ec-00cc-416f512fef277bc1
attr FreezeMon fm_statistics 1und auch im Log vom hochfahren steht:
2023.06.25 00:35:41.017 3: freezemon defined FreezeMon freezemon
...
2023.06.25 00:38:45.917 0: [Freezemon] FreezeMon: Unwrapping CallFn
2023.06.25 00:38:45.919 0: [Freezemon] FreezeMon: Unwrapping AnalyzeCommand
2023.06.25 00:38:45.920 0: [Freezemon] FreezeMon: Unwrapping HttpUtils_NonblockingGet
2023.06.25 00:38:45.921 0: [Freezemon] FreezeMon: Unwrapping Log3
Danach scheint es "irgendwie/automatisch" aus der fhem.cfg gelöscht worde zu sein, da es nicht mehr enthalten ist.
Wer weiss/hat eine Idee wie es dazu kommen kann?
Gruß Ralf
Edit:
die fhem.cfg trägt den Zeitstempel des Logeintrags "-rw-r--r-- 1 fhem dialout 104700 Jun 25 00:38 fhem.cfg"
Also ich hab bisher immer apptime verwendet, um Freezes auf die Schliche zu kommen, aber wollte nun auch mal freezemon einsetzen. Aber irgendwie kann ich mit freezemon den Verursacher nicht identifizieren - mit apptime aber schon.
Aktuelles Fallbeispiel:
Ich hab ein Gerät (also physisch) "CO2Mini". Das hängt an einem Raspi. Wenn der nicht erreichbar ist, führt das minütlich zu 3 sekündingen Freezes in FHEM.
apptime sagt dazu Folgendes:
name function max count total average maxDly avgDly TS Max call param Max call
sz_co2mini co2mini_Ready 3004 2 6009.04 3004.52 0.00 0.00 23.07. 11:24:01 HASH(sz_co2mini)
sys_cul868 CUL_Read 29 14 91.91 6.56 0.00 0.00 23.07. 11:23:32 HASH(sys_cul868)
sys_cul433 CUL_Read 28 14 81.95 5.85 0.00 0.00 23.07. 11:23:32 HASH(sys_cul433)
Also sofort sehr klar zu sehen, woran es liegt.
freezemon meldet minütlich sowas:
s:11:32:23 e:11:32:25 f:2.281 d:tmr-FW_closeInactiveClients(N/A) tmr-CODE(0x560294518be0)(YAMAHA_AVR_GetStatus) tmr-DbLog_execMemCacheAsync(benDbLog) tmr-MQTT2_CLIENT_keepalive(sys_mqtt) tmr-EspLedController_Check(wz_lightLedCouch) tmr-EspLedController_Check(ku_lightLedCeil) tmr-EspLedController_Check(sz_lightLedWall) tmr-EspLedController_Check(ku_lightLedFloor) tmr-HMUARTLGW_CheckCredits(sys_culHm) tmr-EspLedController_Check(wz_lightLedTv) tmr-PRESENCE_StartLocalScan(sz_s8_pres)
Da ist mir nicht ganz klar, wie das zu lesen ist. Das sind vermutlich einfach alles mögliche Kandidaten? Also das sind ne ganze Menge, aber ausgerechnet der tatsächliche Verursacher taucht nicht auf. :-\
Hallo zusammen! Nutzt Ihr das Modul noch?
Ich habe es heute zum 1. Mal verwendet (inkl. Plots) und bin hierüber verwundert:
ZitatFreezes today: 36.845 - Longest Freeze 0.00
Sollen das 36.845 Freezes sein? Aber dann 0.00?
EDIT: Ah, die Anzahl wird in Bruchzahlen im Plot-Titel angegeben. Zumindest sieht es so aus, wenn ich mir die Logs anschaue. Wieso hier aber überhaupt erst eine Bruchzahl entsteht, weiß ich nicht.
define MyFreezemon freezemon
setuuid MyFreezemon xxxxx
attr MyFreezemon room Server
define FileLog_MyFreezemon FileLog /opt/fhem/log/MyFreezemon-%Y-%m.log MyFreezemon
setuuid FileLog_MyFreezemon xxxxx
attr FileLog_MyFreezemon archivedir /opt/fhem/log/archive/
attr FileLog_MyFreezemon createGluedFile 1
attr FileLog_MyFreezemon nrarchive 2
define SVG_FileLog_MyFreezemon SVG FileLog_MyFreezemon:freezemon_gplot:CURRENT
setuuid SVG_FileLog_MyFreezemon xxxxx
attr SVG_FileLog_MyFreezemon plotReplace TL={"Freezes today: ".$data{max1}." - Longest Freeze ".sprintf("%.2f ",$data{max2}) }
attr SVG_FileLog_MyFreezemon room Server
define SVG_FileLog_MyFreezemon_day SVG FileLog_MyFreezemon:freezemon_day:CURRENT
setuuid SVG_FileLog_MyFreezemon_day xxxxx
attr SVG_FileLog_MyFreezemon_day fixedrange month
attr SVG_FileLog_MyFreezemon_day plotReplace TL={"Max Freezes: ".$data{max1}." - Max Freezetime ".sprintf("%.2f ",$data{max2}) }
attr SVG_FileLog_MyFreezemon_day room ServerIch weiß, dass das THZ-Modul (für eine SE/Tecalor Wärmepumpe) hin und wieder Hänger hat, aber die o.g. Zahl macht für mich keinen Sinn.
Blick ins komplette Freezemon Log:
2023-11-13_14:16:01 MyFreezemon s:14:16:00 e:14:16:01 f:1.414 d:tmr-THZ_GetRefresh(N/A)
2023-11-13_14:16:01 MyFreezemon freezeTime: 1.414
2023-11-13_14:16:01 MyFreezemon fcDay: 3
2023-11-13_14:16:01 MyFreezemon ftDay: 7.143
2023-11-13_14:16:01 MyFreezemon freezeDevice: tmr-THZ_GetRefresh(N/A)
2023-11-13_14:18:24 MyFreezemon s:14:18:22 e:14:18:24 f:2.476 d:tmr-THZ_GetRefresh(N/A)
2023-11-13_14:18:24 MyFreezemon freezeTime: 2.476
2023-11-13_14:18:24 MyFreezemon fcDay: 4
2023-11-13_14:18:24 MyFreezemon ftDay: 9.619
2023-11-13_14:18:24 MyFreezemon freezeDevice: tmr-THZ_GetRefresh(N/A)
2023-11-13_14:18:47 MyFreezemon s:14:18:46 e:14:18:47 f:1.306 d:no bad guy found :-(
2023-11-13_14:18:47 MyFreezemon freezeTime: 1.306
2023-11-13_14:18:47 MyFreezemon fcDay: 5
2023-11-13_14:18:47 MyFreezemon ftDay: 10.925
2023-11-13_14:18:47 MyFreezemon freezeDevice: no bad guy found :-(
2023-11-13_14:22:43 MyFreezemon s:14:22:41 e:14:22:43 f:2.464 d:tmr-THZ_GetRefresh(N/A)
2023-11-13_14:22:43 MyFreezemon freezeTime: 2.464
2023-11-13_14:22:43 MyFreezemon fcDay: 6
2023-11-13_14:22:43 MyFreezemon ftDay: 13.389
2023-11-13_14:22:43 MyFreezemon freezeDevice: tmr-THZ_GetRefresh(N/A)
2023-11-13_14:26:59 MyFreezemon s:14:26:57 e:14:26:59 f:2.458 d:tmr-THZ_GetRefresh(N/A)
2023-11-13_14:26:59 MyFreezemon freezeTime: 2.458
2023-11-13_14:26:59 MyFreezemon fcDay: 7
2023-11-13_14:26:59 MyFreezemon ftDay: 15.847
2023-11-13_14:26:59 MyFreezemon freezeDevice: tmr-THZ_GetRefresh(N/A)
2023-11-13_14:29:43 MyFreezemon s:14:29:41 e:14:29:43 f:2.474 d:tmr-THZ_GetRefresh(N/A)
2023-11-13_14:29:43 MyFreezemon freezeTime: 2.474
2023-11-13_14:29:43 MyFreezemon fcDay: 8
2023-11-13_14:29:43 MyFreezemon ftDay: 18.321
2023-11-13_14:29:43 MyFreezemon freezeDevice: tmr-THZ_GetRefresh(N/A)
2023-11-13_14:32:59 MyFreezemon s:14:32:57 e:14:32:59 f:2.465 d:tmr-THZ_GetRefresh(N/A)
2023-11-13_14:32:59 MyFreezemon freezeTime: 2.465
2023-11-13_14:32:59 MyFreezemon fcDay: 9
2023-11-13_14:32:59 MyFreezemon ftDay: 20.786
2023-11-13_14:32:59 MyFreezemon freezeDevice: tmr-THZ_GetRefresh(N/A)
2023-11-13_14:35:12 MyFreezemon s:14:35:10 e:14:35:12 f:2.449 d:tmr-THZ_GetRefresh(N/A)
2023-11-13_14:35:12 MyFreezemon freezeTime: 2.449
2023-11-13_14:35:12 MyFreezemon fcDay: 10
2023-11-13_14:35:12 MyFreezemon ftDay: 23.235
2023-11-13_14:35:12 MyFreezemon freezeDevice: tmr-THZ_GetRefresh(N/A)
2023-11-13_14:37:22 MyFreezemon s:14:37:20 e:14:37:22 f:2.438 d:tmr-THZ_GetRefresh(N/A)
2023-11-13_14:37:22 MyFreezemon freezeTime: 2.438
2023-11-13_14:37:22 MyFreezemon fcDay: 11
2023-11-13_14:37:22 MyFreezemon ftDay: 25.673
2023-11-13_14:37:22 MyFreezemon freezeDevice: tmr-THZ_GetRefresh(N/A)
2023-11-13_14:40:29 MyFreezemon s:14:40:27 e:14:40:29 f:2.439 d:tmr-THZ_GetRefresh(N/A)
2023-11-13_14:40:29 MyFreezemon freezeTime: 2.439
2023-11-13_14:40:29 MyFreezemon fcDay: 12
2023-11-13_14:40:29 MyFreezemon ftDay: 28.112
2023-11-13_14:40:29 MyFreezemon freezeDevice: tmr-THZ_GetRefresh(N/A)
2023-11-13_15:08:56 MyFreezemon s:15:08:54 e:15:08:56 f:2.169 d:tmr-THZ_GetRefresh(N/A)
2023-11-13_15:08:56 MyFreezemon freezeTime: 2.169
2023-11-13_15:08:56 MyFreezemon fcDay: 13
2023-11-13_15:08:56 MyFreezemon ftDay: 30.281
2023-11-13_15:08:56 MyFreezemon freezeDevice: tmr-THZ_GetRefresh(N/A)
2023-11-13_15:21:56 MyFreezemon s:15:21:54 e:15:21:56 f:2.178 d:tmr-THZ_GetRefresh(N/A)
2023-11-13_15:21:56 MyFreezemon freezeTime: 2.178
2023-11-13_15:21:56 MyFreezemon fcDay: 14
2023-11-13_15:21:56 MyFreezemon ftDay: 32.459
2023-11-13_15:21:56 MyFreezemon freezeDevice: tmr-THZ_GetRefresh(N/A)
2023-11-13_15:24:16 MyFreezemon s:15:24:14 e:15:24:16 f:2.187 d:tmr-THZ_GetRefresh(N/A)
2023-11-13_15:24:16 MyFreezemon freezeTime: 2.187
2023-11-13_15:24:16 MyFreezemon fcDay: 15
2023-11-13_15:24:16 MyFreezemon ftDay: 34.646
2023-11-13_15:24:16 MyFreezemon freezeDevice: tmr-THZ_GetRefresh(N/A)
2023-11-13_15:29:11 MyFreezemon s:15:29:09 e:15:29:11 f:2.199 d:tmr-THZ_GetRefresh(N/A)
2023-11-13_15:29:11 MyFreezemon freezeTime: 2.199
2023-11-13_15:29:11 MyFreezemon fcDay: 16
2023-11-13_15:29:11 MyFreezemon ftDay: 36.845
2023-11-13_15:29:11 MyFreezemon freezeDevice: tmr-THZ_GetRefresh(N/A)
Was ist das denn? Verursacher des Freezes nicht identifiziert?
Zitatno bad guy found :-(
Hallo sunrise,
ich nutze das Modul immer noch. Seit ein paar Monaten bin ich von einem HP T610 auf einen Fujitsu Futro S740 (mit Proxmox) umgestiegen. Letzter ist ca. 5-6mal schneller als der HP, weshalb ich nur noch wenige kurze Freezes habe
Viele Grüße Gisbert