Ich habe schon länger sporadisch Abstürze von FHEM, deren Ursache ich bisher nicht ergründen konnte.
Im Sommer habe ich dann den RasPi gewechselt (von 3B auf 4B mit 4 GB RAM). Die Abstürze sind seitdem deutlich geringer, treten aber immer wieder "aus dem nichts" auf.
Ich hatte schon länger das Gefühl, dass es durch das Ausschalten meines Stand-PCs "getriggert" wird, d.h. die Abstürze tendenziell dann auftreten, wenn ich diesen Rechner in den Ruhezustand versetze.
Kann ich das irgendwie überprüfen? Das FHEM-Log ist diesbezüglich "leer", da ist nur der Neustart verzeichnet.
Ich habe einen Watchdog im Betriebssystem eingerichtet, der auf die Aktualisierung einer Datei, dessen Zeitstempel ich aus FHEM heraus zyklisch aktualisiere, prüft. Der Watchdog schlägt an, aber warum FHEM "hängt", konnte ich noch nicht herausfinden. Meistens "erfängt" es sich auch nicht mehr von alleine, in seltenen Fällen aber doch.
Tagsüber sind typischerweise mehrere Geräte mit dem Web-Frontend verbunden, das Problem scheint nur von einem der Clients ausgelöst zu werden:
iOS über Safari über "WEBphone" & DynDNS, tendenziell unproblematisch
FireOS über den integrierten Browser über "WEB" & DynDNS, tendenziell unproblematisch
Win-11 über Firefox über "WEB" & externe-IP, tendenziell unproblematisch
Win-10 über Firefox über "WEB" & interne-IP, problematisch
Hier die Definitionen von "WEB" und "WEBphone":
defmod WEB FHEMWEB IPV6:8083 global
attr WEB HTTPS 1
attr WEB SVGcache 1
attr WEB plotfork 1
attr WEB stylesheetPrefix dark
attr WEB title Georgs FHEM
attr WEB verbose 0defmod WEBphone FHEMWEB IPV6:8084 global
attr WEBphone HTTPS 1
attr WEBphone SVGcache 1
attr WEBphone plotfork 1
attr WEBphone stylesheetPrefix darksmallscreen
attr WEBphone title Georgs FHEM
attr WEBphone verbose 0
Hier noch "global" mit anonymisierten GPS-Koordinaten:
attr global userattr cmdIcon devStateIcon devStateIcon:textField-long devStateStyle icon msgContactAudio msgContactLight msgContactMail msgContactPush msgContactScreen msgParams msgPriority msgRecipient msgRecipientAudio msgRecipientLight msgRecipientMail msgRecipientPush msgRecipientScreen msgRecipientText msgTitle msgTitleShrt msgType:text,push,mail,screen,light,audio,queue powerMap:textField-long powerMap_interval powerMap_noEnergy:1,0 powerMap_noPower:1,0 powerMap_rname_E:textField powerMap_rname_P:textField sortby webCmd webCmdLabel:textField-long widgetOverride
attr global altitude xxx
attr global autoload_undefined_devices 1
attr global autosave 0
attr global dnsServer 10.0.0.138
attr global language DE
attr global latitude xxx
attr global logfile ./log/fhem-%Y-%m.log
attr global longitude xxx
attr global modpath .
attr global motd 1
attr global pidfilename /var/run/fhem/fhem.pid
attr global sslVersion TLSv12:!SSLv3
attr global statefile ./log/fhem.save
attr global verbose 1
Ich sehe gerade, dass ich "verbose" für die FHEMWEB-Instanzen auf 0 gesetzt habe. Werde das mal hochsetzen und weiter beobachten, weitere sachdienliche Hinweise sind gerne willkommen.
Verbose fuer FHEMWEB Instanzen zu aendern wird vmtl. nicht die Ursache eines Absturzes verraten, selbst ein "attr global verbose 5" wird nur waage Hinweise geben.
Ich wuerde fhem im Terminal mit "perl fhem.pl -d fhem.cfg" starten, und nach dem Absturz die letzten Zeilen im Terminal inspizieren.
Zitat von: rudolfkoenig am 17 September 2025, 09:18:40Ich wuerde fhem im Terminal mit "perl fhem.pl (https://fhem.pl/) -d fhem.cfg" starten, und nach dem Absturz die letzten Zeilen im Terminal inspizieren.
Schwierig... ich habe nur Remote-Zugang zu dem RasPi... wenn ich das mache, müsste ich die SSH-Shell permanent verbunden lassen.
Ich kann natürlich versuchen das Ein-/Ausschalten ein paarmal durchzuführen und hoffen, dass es dann auftritt.
Oder würde es funktionieren an den Aufruf noch zusätzlich eine Ausgabe dranzuhängen, also z.B.
perl fhem.pl -d fhem.cfg > /media/RAMDisk/debuglog.txt
https://wiki.ubuntuusers.de/Screen/
ZitatOder würde es funktionieren an den Aufruf noch zusätzlich eine Ausgabe dranzuhängen, also z.B.
perl fhem.pl -d fhem.cfg > /media/RAMDisk/debuglog.txt
Wichtig ist in diesem Fall auch STDERR umzuleiten:
$ perl fhem.pl -d fhem.cfg > /media/RAMDisk/debuglog.txt 2>&1
Gilt fuer sh, bash, und verwandte.
Oder screen bzw. eine der Alternativen.
OK, Danke für eure raschen Antworten. Das sollte ich hinkriegen, wobei mir auf den ersten Blick die "screen" Variante besser gefällt.
D.h. einfach FHEM beenden, FHEM-Service deaktivieren und über screen und die Shell neu starten.
Und dann warten... zuletzt ist's über 2 Wochen unauffällig gewesen.
So, ich habe das mal gestartet... doch ohne "screen", weil ich das auf meinem etwas älteren Raspbian nicht installiert bekommen habe.
Allerdings wird das debug-log sehr schnell sehr groß, ich glaube das wird die RAMDisk voll machen bevor ich was sehe :-(
Muss wohl doch versuchen "screen" zum Laufen zu bekommen.
Was mir auch noch aufgefallen ist:
Das fhem.log wird nun nicht befüllt ((Neu-) Start ist nicht drin), alle anderen Logs scheinen soweit iO zu sein. Ist das erwartet?
Zitat von: TheTrumpeter am 19 September 2025, 08:40:52auf meinem etwas älteren Raspbian
Vielleicht wäre das mal die erste Baustelle ...
Welche Version läuft denn noch bei dir?
Zitat von: TheTrumpeter am 17 September 2025, 06:48:27Im Sommer habe ich dann den RasPi gewechselt
Bzw. hast du hier auf dem neuen Pi dann nicht sowieso mit einem frischen System gestartet? Falls nicht, auch wenn das bei Linux vielleicht nicht so kritisch ist, kann es schon sein, dass da noch irgendein "Müll" übrig ist, der dir jetzt Probleme macht.
Zitat von: passibe am 19 September 2025, 09:33:06Welche Version läuft denn noch bei dir?
Buster
Zitat von: passibe am 19 September 2025, 09:33:06Bzw. hast du hier auf dem neuen Pi dann nicht sowieso mit einem frischen System gestartet?
Nein erstmal nicht, das gab die Zeit dann nicht mehr her, weil ich beim Umbau Probleme hatte und die Hardware nun doch nicht so ist wie ich das wollte (kombiniertes RS485/RS232-HAT habe ich nicht zum Laufen gebracht, drum läuft RS485 noch/wieder über ein billiges China-USB-Dongle).
Steht aber auf meiner ToDo-Liste.
Zitat von: passibe am 19 September 2025, 09:33:06kann es schon sein, dass da noch irgendein "Müll" übrig ist, der dir jetzt Probleme macht.
Vielleicht habe ich es eingangs nicht verständlich genug ausgedrückt:
Mit dem alten RasPi kam es häufig zu dem Absturz/Neustart, mal mehrmals am Tag, mal alle paar Tage.
Mit dem neuen RasPi beobachte ich es nur noch alle 10-14 Tage.
Ob es wirklich am RasPi liegt oder ich wg. längerem Urlaub nach dem Umbau bisher einfach viel seltener bzw. mit weniger Geräten gleichzeitig verbunden war & das die Ursache ist, kann ich nicht sagen. Allerdings ist der Urlaub auch schon wieder seit 3 Wochen aus und an der oben genannten Frequenz hat sich nix geändert. Mir ist es nur wieder aufgefallen, als ich den Stand-PC abgedreht hatte.
Seit dem Umbau habe ich die Intervalle einiger periodischer Auslese-Prozesse aber auch deutlich verkürzt, d.h. die allgemeine Last ist nun gestiegen.
Was ich "von außen" im Nachhinein (bzw. teilweise auch während dem "Hänger") sehe, lässt mich ratlos zurück.
Selbst wenn FHEM nicht mehr reagiert, kann ich mich problemlos per SSH verbinden, Prozessor- und RAM-Last ist unaufgeregt, das FHEM-service wird als "running" angezeigt, aber es tut nix mehr. Den RasPi selbst musste/habe ich da nie neu gestartet.
ZitatDas fhem.log wird nun nicht befüllt ((Neu-) Start ist nicht drin), alle anderen Logs scheinen soweit iO zu sein. Ist das erwartet?
Die Option -d setzt verbose level auf 5 und logfile auf - (d.h. STDOUT), damit wird fhem.log nicht mehr befuellt.
Zitat von: TheTrumpeter am 19 September 2025, 09:56:54Mit dem alten RasPi kam es häufig zu dem Absturz/Neustart, mal mehrmals am Tag, mal alle paar Tage.
Mit dem neuen RasPi beobachte ich es nur noch alle 10-14 Tage.
Ah ok, danke, jetzt verstehe ich.
Hm. Das ist schon dubios. Und es lässt sich wirklich genau auf den Zeitpunkt zurückführen, wenn du den einen Computer ausschaltest? Also diesen:
Zitat von: TheTrumpeter am 17 September 2025, 06:48:27Win-10 über Firefox über "WEB" & interne-IP, problematisch
Ist der Browser mit der FHEM-Seite immer offen, wenn du ihn in den Ruhezustand versetzt? Was passiert, wenn du nur den Browser schließt, den PC aber an lässt?
Falls es deine Netzwerkinfrastruktur zulässt (wenn Fritzbox, dann unproblematisch möglich (https://www.heise.de/hintergrund/Solarinverter-Sicherheit-auf-dem-Pruefstand-9715912.html?seite=5)): Kannst du eventuell mal von einem anderen Gerät aus den Netzwerkverkehr mitlesen und schauen, ob da irgendwas auffälliges passiert, sobald du den PC in den Ruhezustand versetzt? Auch wenn schwer vorstellbar, könnte es ja sein, dass FHEM auf dem Pi irgendwie versucht den PC noch zu erreichen, das aber nicht mehr kann und dann daran (warum auch immer) kaputtgeht.
Zitat von: passibe am 19 September 2025, 14:16:13Und es lässt sich wirklich genau auf den Zeitpunkt zurückführen, wenn du den einen Computer ausschaltest?
Zu 100% kann ich das natürlich nicht behaupten, aber beim letzten Mal war es so. Also PC in den Ruhezustand versetzt, 1min später vom Laptop versucht im Browser neu zu laden, keine Antwort. Vom Mobiltelefon identisch, kurz darauf kamen schon die eMails vom Watchdog.
Und das war auch davor schon öfter so, aber ob es immer so ist & was es wirklich triggert, kann ich nicht sagen.
Seitdem habe ich den PC schon wieder öfter ein- und ausgeschalten, nix ist passiert.
Zitat von: passibe am 19 September 2025, 14:16:13Ist der Browser mit der FHEM-Seite immer offen, wenn du ihn in den Ruhezustand versetzt?
Ja.
Zitat von: passibe am 19 September 2025, 14:16:13Was passiert, wenn du nur den Browser schließt, den PC aber an lässt?
5x probiert, nix passiert.
Es tritt ja auch nicht immer auf, und vielleicht triggert es auch was anderes.
Zitat von: passibe am 19 September 2025, 14:16:13Kannst du eventuell mal von einem anderen Gerät aus den Netzwerkverkehr mitlesen und schauen, ob da irgendwas auffälliges passiert, sobald du den PC in den Ruhezustand versetzt
Du meinst generell, oder nur wenn das Problem auftritt? Letzteres kann ich ja wie gesagt noch nicht wirklich reproduzieren, d.h. Mitlesen wäre eher sinnlos.
Danke für die Infos. Habe leider spontan aber auch keine weitere Idee, woran das liegen könne.
Zitat von: TheTrumpeter am 19 September 2025, 15:38:38Du meinst generell, oder nur wenn das Problem auftritt?
Generell schadet natürlich auch mal nicht, vielleicht ist da ja ein Zufallsfund dabei, aber ja, für das Problem hier bringt das vermutlich nichts.
Wäre eher dann, wenn es mal wieder so weit ist.
Was mir grade einfällt, du kannst natürlich auch einfach mit tcpdump am Pi mitschneiden. Ist vielleicht einfacher als über den Router.
Aber ja, es irgendwie reproduzierbar zu machen, wäre vielleicht der erste Schritt. Wüsste aber auch da nicht, wie, vor allem, wenn du sowieso schon versucht hast den PC in den Ruhezustand zu versetzen, etc.
Zitat von: passibe am 19 September 2025, 17:41:40Aber ja, es irgendwie reproduzierbar zu machen, wäre vielleicht der erste Schritt.
Bei der aktuell geringen Auftretenshäufigkeit macht alles andere aktuell wohl keinen Sinn, zumindest nichts, das dann nicht automatisch stoppt.
Die aktuell laufende Debug-Ausgabe in die Konsole muss beim Absturz von FHEM ja automatisch enden, d.h. da kann man sich dann wohl einfach von unten nach oben arbeiten und entdeckt dabei hoffentlich was auffälliges.
tcpdump produziert eine Unmenge an Daten, mit deren Zuordnung bzw. Analyse ich komplett überfordert wäre.
In meiner Branche sagt man: Wenn man ein Problem ausreichend gut reproduzieren kann, dann findet man auch dessen Ursache mittels strukturierter Herangehensweise. Solange das nicht klappt, stochert man im Nebel. (Das heißt nicht, dass man nicht trotzdem auf was treffen kann, aber die Wahrscheinlichkeit ist gering, und vor allem selbst wenn man was findet, kann man schwer überprüfen, ob es das Problem löst.)
So, das Problem ist endlich wieder aufgetreten.
Natürlich hat Murphy zugeschlagen, sodass ich gerade unterwegs bin. Habe es nun zumindest geschafft ein neues Screen-Fenster zu starten, um FHEM neu zu starten.
Den Dump aus dem anderen Fenster mit dem Abbruch poste ich am späteren Nachmittag.
Gestern hat's dann nicht mehr geklappt, hier nun die letzten Ausgaben. Insgesamt gab's gestern 3 Vorkommnisse, wobei nur beim 1. Mal auch der eingangs verdächtigte Stand-PC daheim eingeschaltet war. In der Ausgabe finde ich dazu aber nichts.
Ich habe die Ausgaben verglichen, am Ende bleibt immer der WEBphone-Requst als letzter Eintrag stehen, was ich grundsätzlich komisch finde, da ich von genau diesem Gerät sehr häufig zugreife. Warum's da grad gestern 3x das Problem gab ist mir nicht ganz klar.
MÖGLICHERWEISE ist der Absturz immer dann aufgetreten, wenn ich vom LTE- ins WLAN gewechselt bin, d.h. die Seitenaktualisierung aus dem LTE-Netz getriggert habe, kurz darauf (oder genau dabei) aber ins WLAN gewechselt bin.
Absturz 1 (nach über 3 Wochen unauffälligem Betrieb):
2025.10.16 09:15:24 4: myHuawei: CreateDataObjects assigns value Netz verbunden to Device_status
2025.10.16 09:15:24 5: myHuawei: CreateParseInfoCache called
2025.10.16 09:15:24 5: myHuawei: CreateDataObjects unpacked 0000 with n to 0
2025.10.16 09:15:24 5: myHuawei: perl expression eval evaluated package main; my @val = @{$oRef->{'%val'}};$val/1 to 0
2025.10.16 09:15:24 4: myHuawei: CreateDataObjects assigns value 0 to Faultcode
2025.10.16 09:15:24 5: myHuawei: CreateParseInfoCache called
2025.10.16 09:15:24 5: myHuawei: CreateDataObjects unpacked 0000 with n to 0
2025.10.16 09:15:24 5: myHuawei: perl expression eval evaluated package main; my @val = @{$oRef->{'%val'}};$val/1 to 0
2025.10.16 09:15:24 4: myHuawei: CreateDataObjects assigns value 0 to Alarm_1
2025.10.16 09:15:24 5: myHuawei: CreateParseInfoCache called
2025.10.16 09:15:24 5: myHuawei: CreateDataObjects unpacked 0000 with n to 0
2025.10.16 09:15:24 5: myHuawei: perl expression eval evaluated package main; my @val = @{$oRef->{'%val'}};$val/1 to 0
2025.10.16 09:15:24 4: myHuawei: CreateDataObjects assigns value 0 to Alarm_2
2025.10.16 09:15:24 5: myHuawei: CreateParseInfoCache called
2025.10.16 09:15:24 5: myHuawei: CreateDataObjects unpacked 0000 with n to 0
2025.10.16 09:15:24 5: myHuawei: perl expression eval evaluated package main; my @val = @{$oRef->{'%val'}};$val/1 to 0
2025.10.16 09:15:24 4: myHuawei: CreateDataObjects assigns value 0 to Alarm_3
2025.10.16 09:15:24 5: myHuawei: ParseDataString created 19 readings, errcode undef
2025.10.16 09:15:24 4: myHuawei: HandleResponse done, current frame / read buffer: 00f4000000a90103a6000000000000000000000000000087e51999019b199900001989019a198900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000014cb0fde0fd40fdd09260923092d00001d3b00001d4100001d2b000014740000146a0000000403e81389265a01900bb802000000, id 1, fCode 3, tid 244,
request: id 1, read fc 3 h32008, len 83, tid 244, master device myHuawei, reading Alarm_1 (getUpdate for Alarm_1 len 83), queued 0.89 secs ago, sent 0.88 secs ago,
response: id 1, fc 3, h32008, len 83, values 000000000000000000000000000087e51999019b199900001989019a198900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000014cb0fde0fd40fdd09260923092d00001d3b00001d4100001d2b000014740000146a0000000403e81389265a01900bb802000000
2025.10.16 09:15:24 5: myHuawei: ResetExpect for HandleResponse from response to idle
2025.10.16 09:15:24 5: myHuawei: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2025.10.16 09:15:24 5: myHuawei: DropFrame called from ReadFn - drop 00f4000000a90103a6000000000000000000000000000087e51999019b199900001989019a198900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000014cb0fde0fd40fdd09260923092d00001d3b00001d4100001d2b000014740000146a0000000403e81389265a01900bb802000000
2025.10.16 09:15:24 5: myHuawei: readFn end buffer: mode master, expect idle
2025.10.16 09:15:24 5: Cmd: >setreading myHuawei Eigennutzung_momentan {(([myHuawei:Active_Power:d]<[SmartMeterRestAPI:Momentanleistungsbedarf:d])?([myHuawei:Active_Power:d]):([SmartMeterRestAPI:Momentanleistungsbedarf:d]))} W<
2025.10.16 09:15:24 5: Starting notify loop for myHuawei, 1 event(s), first is Eigennutzung_momentan: 2842 W
2025.10.16 09:15:24 5: statistics PVAnlage.Statistik: DoStatistics.455 Assigned reading 'Ersparnis_Eigennutzung' from attribute 'deltaReadings' to statistic type 2.
2025.10.16 09:15:24 5: statistics PVAnlage.Statistik: DoStatistics.455 Assigned reading 'Ersparnis_Einspeisung' from attribute 'deltaReadings' to statistic type 2.
2025.10.16 09:15:24 5: statistics PVAnlage.Statistik: DoStatistics.455 Assigned reading 'Accumulated_energy_yield' from attribute 'deltaReadings' to statistic type 2.
2025.10.16 09:15:24 4: statistics PVAnlage.Statistik: doStatisticDelta.778 Calculating delta statistics for 'myHuawei:Ersparnis_Eigennutzung = 2179.372028342'
2025.10.16 09:15:24 5: statistics PVAnlage.Statistik: doStatisticDelta.882 Set '.myHuawei:Ersparnis_Eigennutzung'='LastValue: 2179.372028342 ShowDate: 0 DecPlaces: 9'
2025.10.16 09:15:24 5: statistics PVAnlage.Statistik: doStatisticDelta.888 Set 'statErsparnis_Eigennutzung'='Hour: 0.211863132 Day: 0.556531966 Month: 22.722844371 Year: 867.330851059'
2025.10.16 09:15:24 4: statistics PVAnlage.Statistik: doStatisticDelta.778 Calculating delta statistics for 'myHuawei:Ersparnis_Einspeisung = 3549.2036394275'
2025.10.16 09:15:24 5: statistics PVAnlage.Statistik: doStatisticDelta.882 Set '.myHuawei:Ersparnis_Einspeisung'='LastValue: 3549.2036394275 ShowDate: 0 DecPlaces: 10'
2025.10.16 09:15:24 5: statistics PVAnlage.Statistik: doStatisticDelta.888 Set 'statErsparnis_Einspeisung'='Hour: 0.0239400000 Day: 0.1210500000 Month: 20.1858300000 Year: 861.5289450002'
2025.10.16 09:15:24 4: statistics PVAnlage.Statistik: doStatisticDelta.778 Calculating delta statistics for 'myHuawei:Accumulated_energy_yield = 50958.66'
2025.10.16 09:15:24 5: statistics PVAnlage.Statistik: doStatisticDelta.882 Set '.myHuawei:Accumulated_energy_yield'='LastValue: 50958.66 ShowDate: 0 DecPlaces: 2'
2025.10.16 09:15:24 5: statistics PVAnlage.Statistik: doStatisticDelta.888 Set 'statAccumulated_energy_yield'='Hour: 1.31 Day: 4.64 Month: 528.50 Year: 18257.79'
2025.10.16 09:15:24 5: Starting notify loop for PVAnlage.Statistik, 1 event(s), first is Updated stats for: myHuawei
2025.10.16 09:15:24 5: End notify loop for PVAnlage.Statistik
2025.10.16 09:15:24 5: statistics PVAnlage.Statistik: Notify.301 Notification of 'myHuawei' received. Update statistics.
2025.10.16 09:15:24 5: End notify loop for myHuawei
2025.10.16 09:15:24 5: Cmd: >setreading myHuawei Ersparnis_Einspeisung {(([SmartMeterRestAPI:Einspeisung_Tag:d])*[Energiepreise:Strom_Einspeisung:d]+[myHuawei:Ersparnis_Einspeisung_bisgestern:d])} EUR<
2025.10.16 09:15:24 5: Cmd: >sleep 0 quiet<
2025.10.16 09:15:24 5: myHuawei: ProcessRequestQueue called from Fhem internal timer as queue:myHuawei, qlen 7, request: request: id 1, read fc 3 h32016, len 6, tid 254, master device myHuawei, reading PV1_voltage (getUpdate for PV1_voltage len 6), queued 0.90 secs ago
2025.10.16 09:15:24 5: myHuawei: checkDelays clientSwitchDelay is not relevant
2025.10.16 09:15:24 5: myHuawei: checkDelays busDelayRead is not required
2025.10.16 09:15:24 5: myHuawei: checkDelays sendDelay, last send to same device was 0.895 secs ago, required delay is 0.1
2025.10.16 09:15:24 5: myHuawei: checkDelays commDelay, last communication with same device was 0.051 secs ago, required delay is 0.1
2025.10.16 09:15:24 4: myHuawei: checkDelays found commDelay not over, set timer to try again in 0.049
2025.10.16 09:15:24 4: ESPEasy myESPBridge_10.0.0.95_54049: Received content length ok
2025.10.16 09:15:24 5: ESPEasy ESPEasy_SprinklerControl_Ventilschacht: Received: SprinklerControl_Ventilschacht::10.0.0.95::1::0::1::i||unit||0||0|||i||sleep||0||0|||i||build||21186||0|||i||build_git||mega-20250430||0|||i||build_notes|| - Mega32||0|||i||version||3||0|||i||node_type_id||33||0|||r||Feuchtigkeit||99.9||2|||r||Temperatur||9.8||2
2025.10.16 09:15:24 4: ESPEasy ESPEasy_SprinklerControl_Ventilschacht: Feuchtigkeit: 99.9
2025.10.16 09:15:24 4: ESPEasy ESPEasy_SprinklerControl_Ventilschacht: Temperatur: 9.8
2025.10.16 09:15:24 5: ESPEasy ESPEasy_SprinklerControl_Ventilschacht: Internals: unit:0 sleep:0 build:21186 build_git:mega-20250430 build_notes: - Mega32 version:3 node_type_id:ESP Easy 32
2025.10.16 09:15:24 5: Cmd: >setreading SmartMeterRestAPI Zaehlerstand_Eigennutzung {([myHuawei:Accumulated_energy_yield:d]-[SmartMeterRestAPI:Zaehlerstand_Einspeisung:d])} kWh<
2025.10.16 09:15:24 4: Connection accepted from WEBphone_::ffff:194.39.218.13_60651
2025.10.16 09:15:24 5: myHuawei: ProcessRequestQueue called from Fhem internal timer as queue:myHuawei, qlen 7, request: request: id 1, read fc 3 h32016, len 6, tid 254, master device myHuawei, reading PV1_voltage (getUpdate for PV1_voltage len 6), queued 1.20 secs ago
2025.10.16 09:15:24 5: myHuawei: checkDelays busDelayRead is not required
2025.10.16 09:15:24 5: myHuawei: checkDelays sendDelay, last send to same device was 1.189 secs ago, required delay is 0.1
2025.10.16 09:15:24 5: myHuawei: checkDelays clientSwitchDelay is not relevant
2025.10.16 09:15:24 5: myHuawei: checkDelays commDelay, last communication with same device was 0.345 secs ago, required delay is 0.1
2025.10.16 09:15:24 4: myHuawei: ProcessRequestQueue (V4.5.6 - 7.11.2023) qlen 7, sending 00fe0000000601037d100006 via 10.0.0.94:502, read buffer empty,
request: id 1, read fc 3 h32016, len 6, tid 254, master device myHuawei, reading PV1_voltage (getUpdate for PV1_voltage len 6), queued 1.20 secs ago
2025.10.16 09:15:24 5: myHuawei: Send called from ProcessRequestQueue
2025.10.16 09:15:24 5: DevIo_SimpleWrite myHuawei: 00fe0000000601037d100006
2025.10.16 09:15:24 5: myHuawei: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2025.10.16 09:15:28 5: GET /fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DStrom%3Bsince%3D1760598915.8880098%3Bfmt%3DJSON&fw_id=1760587126.90304×tamp=1760598924249 HTTP/1.1
Host: <entfernt>:8084
Accept: */*
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 18_7_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.7 Mobile/15E148 Safari/604.1
Referer: https://<entfernt>:8084/fhem?room=Strom
Sec-Fetch-Dest: empty
Authorization: Basic <entfernt>
Accept-Language: de-DE,de;q=0.9
Priority: u=3, i
Accept-Encoding: gzip, deflate, br
Cookie: dashboard_activetab=2
Connection: keep-alive
2025.10.16 09:15:28 4: WEBphone_::ffff:194.39.218.13_60651 GET /fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DStrom%3Bsince%3D1760598915.8880098%3Bfmt%3DJSON&fw_id=1760587126.90304×tamp=1760598924249; BUFLEN:0
Killed
Absturz 2 (kurz nach dem Neustart, siehe Zeitstempel):
2025.10.16 09:48:49 5: myHuawei: ResetExpect for HandleResponse from response to idle
2025.10.16 09:48:49 5: myHuawei: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2025.10.16 09:48:49 5: myHuawei: DropFrame called from ReadFn - drop 005d0000000701030400001a1d
2025.10.16 09:48:49 5: myHuawei: readFn end buffer: mode master, expect idle
2025.10.16 09:48:49 5: myHuawei: ProcessRequestQueue called from Fhem internal timer as queue:myHuawei, qlen 2, request: request: id 1, read fc 3 h32086, len 1, tid 25, master device myHuawei, reading Efficiency (getUpdate for Efficiency len 1), queued 4.49 secs ago
2025.10.16 09:48:49 5: myHuawei: checkDelays busDelayRead is not required
2025.10.16 09:48:49 5: myHuawei: checkDelays sendDelay, last send to same device was 0.171 secs ago, required delay is 0.1
2025.10.16 09:48:49 5: myHuawei: checkDelays clientSwitchDelay is not relevant
2025.10.16 09:48:49 5: myHuawei: checkDelays commDelay, last communication with same device was 0.006 secs ago, required delay is 0.1
2025.10.16 09:48:49 4: myHuawei: checkDelays found commDelay not over, set timer to try again in 0.094
2025.10.16 09:48:49 5: myHuawei: ProcessRequestQueue called from Fhem internal timer as queue:myHuawei, qlen 2, request: request: id 1, read fc 3 h32086, len 1, tid 25, master device myHuawei, reading Efficiency (getUpdate for Efficiency len 1), queued 4.59 secs ago
2025.10.16 09:48:49 5: myHuawei: checkDelays commDelay, last communication with same device was 0.102 secs ago, required delay is 0.1
2025.10.16 09:48:49 5: myHuawei: checkDelays sendDelay, last send to same device was 0.267 secs ago, required delay is 0.1
2025.10.16 09:48:49 5: myHuawei: checkDelays clientSwitchDelay is not relevant
2025.10.16 09:48:49 5: myHuawei: checkDelays busDelayRead is not required
2025.10.16 09:48:49 4: myHuawei: ProcessRequestQueue (V4.5.6 - 7.11.2023) qlen 2, sending 00190000000601037d560001 via 10.0.0.94:502, read buffer empty,
request: id 1, read fc 3 h32086, len 1, tid 25, master device myHuawei, reading Efficiency (getUpdate for Efficiency len 1), queued 4.59 secs ago
2025.10.16 09:48:49 5: myHuawei: Send called from ProcessRequestQueue
2025.10.16 09:48:49 5: DevIo_SimpleWrite myHuawei: 00190000000601037d560001
2025.10.16 09:48:49 5: myHuawei: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2025.10.16 09:48:49 4: Connection accepted from WEBphone_::ffff:194.39.218.13_54153
2025.10.16 09:48:50 4: Connection accepted from WEBphone_::ffff:194.39.218.13_54154
2025.10.16 09:48:50 5: myHuawei: readFn buffer: 0019000000050103022663 mode master, expect response
2025.10.16 09:48:50 5: myHuawei: ParseFrameStart called from ReadFn protocol TCP expecting id 1
2025.10.16 09:48:50 4: myHuawei: ParseFrameStart (TCP, master) extracted id 1, fCode 3, tid 25, dlen 5 and potential data 022663
2025.10.16 09:48:50 5: myHuawei: HandleResponse called from ReadFn
2025.10.16 09:48:50 5: myHuawei: HandleResponse is now creating response hash, masterHash is HASH(0x55af532e58)
2025.10.16 09:48:50 5: myHuawei: HandleResponse is now calling ParseResponse, masterHash is HASH(0x55af532e58)
2025.10.16 09:48:50 5: myHuawei: ParseResponse called from HandleResponse, fc 3
2025.10.16 09:48:50 5: myHuawei: now parsing response data objects, master is myHuawei relay is undefined
2025.10.16 09:48:50 5: myHuawei: ParseDataString called from HandleResponse with data hex 2663, type h, adr 32086, op read
2025.10.16 09:48:50 5: myHuawei: SplitDataString called from ParseDataString with data hex 2663, type h, adr 32086, valuesLen 1, op read
2025.10.16 09:48:50 5: myHuawei: CreateDataObjects called from ParseDataString with objList h32086
2025.10.16 09:48:50 5: myHuawei: CreateDataObjects sortedList h32086
2025.10.16 09:48:50 5: myHuawei: CreateParseInfoCache called
2025.10.16 09:48:50 5: myHuawei: CreateDataObjects unpacked 2663 with n! to 9827
2025.10.16 09:48:50 5: myHuawei: perl expression eval evaluated package main; my @val = @{$oRef->{'%val'}};$val/100 to 98.27
2025.10.16 09:48:50 4: myHuawei: CreateDataObjects assigns value 98.27 to Efficiency
2025.10.16 09:48:50 5: myHuawei: ParseDataString created 1 readings, errcode undef
2025.10.16 09:48:50 4: myHuawei: HandleResponse done, current frame / read buffer: 0019000000050103022663, id 1, fCode 3, tid 25,
request: id 1, read fc 3 h32086, len 1, tid 25, master device myHuawei, reading Efficiency (getUpdate for Efficiency len 1), queued 4.88 secs ago, sent 0.29 secs ago,
response: id 1, fc 3, h32086, len 1, values 2663
2025.10.16 09:48:50 5: myHuawei: ResetExpect for HandleResponse from response to idle
2025.10.16 09:48:50 5: myHuawei: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2025.10.16 09:48:50 5: myHuawei: DropFrame called from ReadFn - drop 0019000000050103022663
2025.10.16 09:48:50 5: myHuawei: readFn end buffer: mode master, expect idle
2025.10.16 09:48:50 5: GET /fhem/images/default/fhemicon_darksmall.png HTTP/1.1
Host: <entfernt>:8084
Accept: image/webp,image/avif,image/jxl,image/heic,image/heic-sequence,video/*;q=0.8,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5
Sec-Fetch-Site: same-origin
If-None-Match: "1686895353"
Sec-Fetch-Mode: no-cors
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 18_7_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.7 Mobile/15E148 Safari/604.1
Referer: https://<entfernt>:8084/fhem?room=Strom
Sec-Fetch-Dest: image
Authorization: Basic <entfernt>
Accept-Language: de-DE,de;q=0.9
Priority: u=5, i
Accept-Encoding: gzip, deflate, br
Cookie: dashboard_activetab=2
Connection: keep-alive
2025.10.16 09:48:50 4: WEBphone_::ffff:194.39.218.13_54153 GET /fhem/images/default/fhemicon_darksmall.png; BUFLEN:0
2025.10.16 09:48:50 4: WEBphone_::ffff:194.39.218.13_54153 => 304 Not Modified
2025.10.16 09:48:50 5: myHuawei: ProcessRequestQueue called from Fhem internal timer as queue:myHuawei, qlen 1, request: request: id 1, read fc 3 h32091, len 2, tid 5, master device myHuawei, reading Startup_Time (getUpdate for Startup_Time len 2), queued 4.88 secs ago
2025.10.16 09:48:50 5: myHuawei: checkDelays commDelay, last communication with same device was 0.008 secs ago, required delay is 0.1
2025.10.16 09:48:50 5: myHuawei: checkDelays clientSwitchDelay is not relevant
2025.10.16 09:48:50 5: myHuawei: checkDelays sendDelay, last send to same device was 0.289 secs ago, required delay is 0.1
2025.10.16 09:48:50 5: myHuawei: checkDelays busDelayRead is not required
2025.10.16 09:48:50 4: myHuawei: checkDelays found commDelay not over, set timer to try again in 0.092
2025.10.16 09:48:50 5: GET /fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DStrom%3Bsince%3D1760600924.27315%3Bfmt%3DJSON&fw_id=1760600925.27317×tamp=1760600929788 HTTP/1.1
Host: <entfernt>:8084
Accept: */*
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 18_7_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.7 Mobile/15E148 Safari/604.1
Referer: https://<entfernt>:8084/fhem?room=Strom
Sec-Fetch-Dest: empty
Authorization: Basic <entfernt>
Accept-Language: de-DE,de;q=0.9
Priority: u=3, i
Accept-Encoding: gzip, deflate, br
Cookie: dashboard_activetab=2
Connection: keep-alive
2025.10.16 09:48:50 4: WEBphone_::ffff:194.39.218.13_54154 GET /fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DStrom%3Bsince%3D1760600924.27315%3Bfmt%3DJSON&fw_id=1760600925.27317×tamp=1760600929788; BUFLEN:0
Killed
Absturz 3:
2025.10.16 11:45:41 5: Triggering MythzDummy_notify
2025.10.16 11:45:41 4: MythzDummy_notify exec {THZ_SplitReadings($NAME,"Dummy",$EVENT,1)}
2025.10.16 11:45:41 5: Cmd: >{THZ_SplitReadings($NAME,"Dummy",$EVENT,1)}<
2025.10.16 11:45:41 5: Cmd: >setreading MythzDummy sDHW sDHW: dhwTemp: 51.6 outsideTemp: 13.1 dhwSetTemp: 10 compBlockTime: 0 out: 0000 heatBlockTime: 0 dhwBoosterStage: 0 pasteurisationMode: 0 dhwOpMode: setback x36: C525<
2025.10.16 11:45:41 5: Starting notify loop for MythzDummy, 1 event(s), first is sDHW: sDHW: dhwTemp: 51.6 outsideTemp: 13.1 dhwSetTemp: 10 compBlockTime: 0 out: 0000 heatBlockTime: 0 dhwBoosterStage: 0 pasteurisationMode: 0 dhwOpMode: setback x36: C525
2025.10.16 11:45:41 5: End notify loop for MythzDummy
2025.10.16 11:45:41 5: Cmd: >setreading MythzDummy HtPmp_tDHWAct 51.6<
2025.10.16 11:45:41 5: Starting notify loop for MythzDummy, 1 event(s), first is HtPmp_tDHWAct: 51.6
2025.10.16 11:45:41 5: End notify loop for MythzDummy
2025.10.16 11:45:41 5: Cmd: >setreading MythzDummy AmbAir_t 13.1<
2025.10.16 11:45:41 5: rg_thz: not on any display, ignoring notify
2025.10.16 11:45:41 5: rg_thz_stat: not on any display, ignoring notify
2025.10.16 11:45:41 5: End notify loop for Mythz
2025.10.16 11:45:41 5: Cmd: >sleep 0.1 quiet<
2025.10.16 11:45:41 3: Mythz.Gets.30s: dhwTemp: 51.6 outsideTemp: 13.1 dhwSetTemp: 10 compBlockTime: 0 out: 0000 heatBlockTime: 0 dhwBoosterStage: 0 pasteurisationMode: 0 dhwOpMode: setback x36: C525
2025.10.16 11:45:41 5: redefine at command Mythz.Gets.30s as +*00:00:30
get Mythz sDHW;
sleep 0.1 quiet;
get Mythz sFan;
sleep 0.1 quiet;
get Mythz sControl
2025.10.16 11:45:41 5: Starting notify loop for Mythz.Gets.30s, 1 event(s), first is Next: 11:46:10
2025.10.16 11:45:41 5: End notify loop for Mythz.Gets.30s
2025.10.16 11:45:41 4: BindingsIo (fhempy_local): >>> WS: {"awaitId": 90727029, "NAME": "tuya_local_bfea531a427393198ebq7p", "msgtype": "command", "command": "readingsBulkUpdateIfChanged($defs{'tuya_local_bfea531a427393198ebq7p'},'dp_21','1');;"}
2025.10.16 11:45:41 5: BindingsIo_storeMessage: {"awaitId": 90727029, "NAME": "tuya_local_bfea531a427393198ebq7p", "msgtype": "command", "command": "readingsBulkUpdateIfChanged($defs{'tuya_local_bfea531a427393198ebq7p'},'dp_21','1');;"}
2025.10.16 11:45:41 5: BindingsIo_checkResponseByAllNames size 1
2025.10.16 11:45:41 4: BindingsIo(fhempy_local): processCommand (90727029): readingsBulkUpdateIfChanged($defs{'tuya_local_bfea531a427393198ebq7p'},'dp_21','1');;
2025.10.16 11:45:41 4: BindingsIo (fhempy_local): <<< WS: {"awaitId":90727029,"result":null,"error":0}
2025.10.16 11:45:41 5: DevIo_SimpleWrite fhempy_local: 7b2261776169744964223a39303732373032392c22726573756c74223a6e756c6c2c226572726f72223a307d
2025.10.16 11:45:41 5: BindingsIo_checkResponseByAllNames size 0
2025.10.16 11:45:41 5: BindingsIo (fhempy_local): Waiting for id 0
2025.10.16 11:45:41 4: BindingsIo (fhempy_local): >>> WS: {"awaitId": 82011281, "NAME": "tuya_local_bfea531a427393198ebq7p", "msgtype": "command", "command": "readingsBulkUpdateIfChanged($defs{'tuya_local_bfea531a427393198ebq7p'},'dp_22','567');;"}
2025.10.16 11:45:41 5: BindingsIo_storeMessage: {"awaitId": 82011281, "NAME": "tuya_local_bfea531a427393198ebq7p", "msgtype": "command", "command": "readingsBulkUpdateIfChanged($defs{'tuya_local_bfea531a427393198ebq7p'},'dp_22','567');;"}
2025.10.16 11:45:41 5: BindingsIo_checkResponseByAllNames size 1
2025.10.16 11:45:41 4: BindingsIo(fhempy_local): processCommand (82011281): readingsBulkUpdateIfChanged($defs{'tuya_local_bfea531a427393198ebq7p'},'dp_22','567');;
2025.10.16 11:45:41 4: BindingsIo (fhempy_local): <<< WS: {"error":0,"result":null,"awaitId":82011281}
2025.10.16 11:45:41 5: DevIo_SimpleWrite fhempy_local: 7b226572726f72223a302c22726573756c74223a6e756c6c2c2261776169744964223a38323031313238317d
2025.10.16 11:45:41 5: BindingsIo_checkResponseByAllNames size 0
2025.10.16 11:45:41 5: BindingsIo (fhempy_local): Waiting for id 0
2025.10.16 11:45:41 4: BindingsIo (fhempy_local): >>> WS: {"awaitId": 43624516, "NAME": "tuya_local_bfea531a427393198ebq7p", "msgtype": "command", "command": "readingsBulkUpdateIfChanged($defs{'tuya_local_bfea531a427393198ebq7p'},'dp_23','29735');;"}
2025.10.16 11:45:41 5: BindingsIo_storeMessage: {"awaitId": 43624516, "NAME": "tuya_local_bfea531a427393198ebq7p", "msgtype": "command", "command": "readingsBulkUpdateIfChanged($defs{'tuya_local_bfea531a427393198ebq7p'},'dp_23','29735');;"}
2025.10.16 11:45:41 5: BindingsIo_checkResponseByAllNames size 1
2025.10.16 11:45:41 4: BindingsIo(fhempy_local): processCommand (43624516): readingsBulkUpdateIfChanged($defs{'tuya_local_bfea531a427393198ebq7p'},'dp_23','29735');;
2025.10.16 11:45:41 4: BindingsIo (fhempy_local): <<< WS: {"result":null,"awaitId":43624516,"error":0}
2025.10.16 11:45:41 5: DevIo_SimpleWrite fhempy_local: 7b22726573756c74223a6e756c6c2c2261776169744964223a34333632343531362c226572726f72223a307d
2025.10.16 11:45:41 5: BindingsIo_checkResponseByAllNames size 0
2025.10.16 11:45:41 5: BindingsIo (fhempy_local): Waiting for id 0
2025.10.16 11:45:41 4: BindingsIo (fhempy_local): >>> WS: {"awaitId": 37057844, "NAME": "tuya_local_bfea531a427393198ebq7p", "msgtype": "command", "command": "readingsBulkUpdateIfChanged($defs{'tuya_local_bfea531a427393198ebq7p'},'dp_24','16145');;"}
2025.10.16 11:45:41 5: BindingsIo_storeMessage: {"awaitId": 37057844, "NAME": "tuya_local_bfea531a427393198ebq7p", "msgtype": "command", "command": "readingsBulkUpdateIfChanged($defs{'tuya_local_bfea531a427393198ebq7p'},'dp_24','16145');;"}
2025.10.16 11:45:41 5: BindingsIo_checkResponseByAllNames size 1
2025.10.16 11:45:41 4: BindingsIo(fhempy_local): processCommand (37057844): readingsBulkUpdateIfChanged($defs{'tuya_local_bfea531a427393198ebq7p'},'dp_24','16145');;
2025.10.16 11:45:41 4: BindingsIo (fhempy_local): <<< WS: {"error":0,"awaitId":37057844,"result":null}
2025.10.16 11:45:41 5: DevIo_SimpleWrite fhempy_local: 7b226572726f72223a302c2261776169744964223a33373035373834342c22726573756c74223a6e756c6c7d
2025.10.16 11:45:41 5: BindingsIo_checkResponseByAllNames size 0
2025.10.16 11:45:41 5: BindingsIo (fhempy_local): Waiting for id 0
2025.10.16 11:45:41 4: BindingsIo (fhempy_local): >>> WS: {"awaitId": 39083664, "NAME": "tuya_local_bfea531a427393198ebq7p", "msgtype": "command", "command": "readingsBulkUpdateIfChanged($defs{'tuya_local_bfea531a427393198ebq7p'},'dp_25','2580');;"}
2025.10.16 11:45:41 5: BindingsIo_storeMessage: {"awaitId": 39083664, "NAME": "tuya_local_bfea531a427393198ebq7p", "msgtype": "command", "command": "readingsBulkUpdateIfChanged($defs{'tuya_local_bfea531a427393198ebq7p'},'dp_25','2580');;"}
2025.10.16 11:45:41 5: BindingsIo_checkResponseByAllNames size 1
2025.10.16 11:45:41 4: BindingsIo(fhempy_local): processCommand (39083664): readingsBulkUpdateIfChanged($defs{'tuya_local_bfea531a427393198ebq7p'},'dp_25','2580');;
2025.10.16 11:45:41 4: BindingsIo (fhempy_local): <<< WS: {"error":0,"result":null,"awaitId":39083664}
2025.10.16 11:45:41 5: DevIo_SimpleWrite fhempy_local: 7b226572726f72223a302c22726573756c74223a6e756c6c2c2261776169744964223a33393038333636347d
2025.10.16 11:45:41 5: BindingsIo_checkResponseByAllNames size 0
2025.10.16 11:45:41 5: BindingsIo (fhempy_local): Waiting for id 0
2025.10.16 11:45:41 4: BindingsIo (fhempy_local): >>> WS: {"awaitId": 18585184, "NAME": "tuya_local_bfea531a427393198ebq7p", "msgtype": "command", "command": "readingsBulkUpdateIfChanged($defs{'tuya_local_bfea531a427393198ebq7p'},'dp_26','0');;"}
2025.10.16 11:45:41 5: BindingsIo_storeMessage: {"awaitId": 18585184, "NAME": "tuya_local_bfea531a427393198ebq7p", "msgtype": "command", "command": "readingsBulkUpdateIfChanged($defs{'tuya_local_bfea531a427393198ebq7p'},'dp_26','0');;"}
2025.10.16 11:45:41 5: BindingsIo_checkResponseByAllNames size 1
2025.10.16 11:45:41 4: BindingsIo(fhempy_local): processCommand (18585184): readingsBulkUpdateIfChanged($defs{'tuya_local_bfea531a427393198ebq7p'},'dp_26','0');;
2025.10.16 11:45:41 4: BindingsIo (fhempy_local): <<< WS: {"error":0,"result":null,"awaitId":18585184}
2025.10.16 11:45:41 5: DevIo_SimpleWrite fhempy_local: 7b226572726f72223a302c22726573756c74223a6e756c6c2c2261776169744964223a31383538353138347d
2025.10.16 11:45:41 5: BindingsIo_checkResponseByAllNames size 0
2025.10.16 11:45:41 5: BindingsIo (fhempy_local): Waiting for id 0
2025.10.16 11:45:41 5: GET /fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DStrom%3Bsince%3D1760607932.9526498%3Bfmt%3DJSON&fw_id=1760606289.98467×tamp=1760607939626 HTTP/1.1
Host: <entfernt>:8084
Accept: */*
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 18_7_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.7 Mobile/15E148 Safari/604.1
Referer: https://<entfernt>:8084/fhem?room=Strom
Sec-Fetch-Dest: empty
Authorization: Basic <entfernt>
Accept-Language: de-DE,de;q=0.9
Priority: u=3, i
Accept-Encoding: gzip, deflate, br
Cookie: dashboard_activetab=2
Connection: keep-alive
2025.10.16 11:45:41 4: WEBphone_::ffff:194.39.218.13_54678 GET /fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DStrom%3Bsince%3D1760607932.9526498%3Bfmt%3DJSON&fw_id=1760606289.98467×tamp=1760607939626; BUFLEN:0
Killed
ZitatKilled
Das war kein "Absturz", der Prozess wurde (von aussen) terminiert.
Eine moegliche Ursache ist Speicherleck.
Wenn ein Prozess zu gross wird, dann wird es vom Kernel terminiert, das wird dann auch im Kernel-Log als solches dokumentiert.
Sudo dmesg -f kern -T zeigt im relevanten Zeitbereich nichts an.
Kannst Du bitte trotzdem beobachten, wie gross der Speicherbedarf bzw. -wachstum von FHEM ist?
Wenn das nicht der Kernel war, dann jemand anderes.
Der Text "Killed" kommt nicht von FHEM, sondern von Shell (im Terminal), wo FHEM gestartet wurde, und zeigt, das der gestartete Pozess mit Signal 9 (SIGKILL) beendet wurde.
Soweit ich sehe, gibt es ein paar Module (DbLog, CoProcess, SubProcess), die SIGKILL versenden, allerdings nur an Unterprozesse.
Das versehentlich der Hauptprozess dabei getroffen wird, ist unwahrscheinlich.
Hm naja, extern gekillt oder nicht – es tritt ja schon immer nach Aufruf dieser URL auf, oder?
Zitat von: TheTrumpeter am 17 Oktober 2025, 07:04:362025.10.16 09:15:28 5: GET /fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DStrom%3Bsince%3D1760598915.8880098%3Bfmt%3DJSON&fw_id=1760587126.90304×tamp=1760598924249 HTTP/1.1
Host: <entfernt>:8084
Accept: */*
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 18_7_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.7 Mobile/15E148 Safari/604.1
Referer: https://<entfernt>:8084/fhem?room=Strom
Sec-Fetch-Dest: empty
Authorization: Basic <entfernt>
Accept-Language: de-DE,de;q=0.9
Priority: u=3, i
Accept-Encoding: gzip, deflate, br
Cookie: dashboard_activetab=2
Connection: keep-alive
2025.10.16 09:15:28 4: WEBphone_::ffff:194.39.218.13_60651 GET /fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DStrom%3Bsince%3D1760598915.8880098%3Bfmt%3DJSON&fw_id=1760587126.90304×tamp=1760598924249; BUFLEN:0
Woher genau kommt dieser Aufruf und was wird damit abgerufen? Bin nicht so tief im FHEMWEB-Game drin, ist das irgendeine automatische Aktualisierung im Hintergrund (JavaScript?) oder erfolgt so ein Request erst, wenn man manuell auf den jeweiligen Raum (hier "Strom") klickt?
Vielleicht auch mal den Raum "Strom" checken, ob da irgendwas auffälliges drin ist? Eventuell auch mal Devices einzeln raus-verschieben, um ggfs. die Fehlerquelle zu isolieren?
Vielleicht kann man die URL ja auch mal mit curl aufrufen und schauen, ob man so einen Absturz provozieren kann.
Zitat von: rudolfkoenig am 17 Oktober 2025, 09:55:50Kannst Du bitte trotzdem beobachten, wie gross der Speicherbedarf bzw. -wachstum von FHEM ist?
Speicherverlauf von gestern gebe ich in den Anhang.
Ich nutze fhempy, das definitiv ein "Speicherleck" hat. Daher starte ich fhempy ab einer bestimmten Speicherschwelle neu, was aber seit dem Wechsel auf den RasPi-4B mit 4 GB nicht mehr erforderlich war. Für mich schaut der Speicherverlauf jedenfalls unkritisch aus, insbesondere nach dem ersten Absturz (weil dadurch auch fhempy neu gestartet wurde).
Zitat von: rudolfkoenig am 17 Oktober 2025, 09:55:50Der Text "Killed" kommt nicht von FHEM, sondern von Shell (im Terminal), wo FHEM gestartet wurde, und zeigt, das der gestartete Pozess mit Signal 9 (SIGKILL) beendet wurde.
Hm...
Ich habe tatsächlich vor langer Zeit einen Watchdog auf Systemebene eingerichtet, der auf die Aktualisierung einer bestimmten Datei im RAM-Drive prüft, um ein "eingefrorenes FHEM" erkennen zu können. Dieser killt den FHEM-Prozess dann nach ein paar Minuten und startet ihn neu. Der Neustart funktioniert derzeit natürlich nicht, weil FHEM mit der Debug-Ausgabe von weiter oben manuell gestartet wurde.
Es kommen dann auch im Minutentakt eMails, die das Problem anzeigen, d.h. ich glaube 2x "hängt" und 1x "Neustart versucht".
In seltenen Fällen hat sich das System nach 1 oder 2 eMails wieder "erfangen", d.h. FHEM hat wohl 1-2 Minuten die Datei nicht aktualisiert, dann aber doch "weitergemacht".
Müsste später nachschauen wie lange es dauert, bis "gekillt" wird, aber ich meine mindestens 3 Minuten.
D.h. das erklärt dann das "killed" in der Ausgabe. Warum sich davor (mindestens) 3 Minuten nichts mehr tut bleibt weiterhin offen.
Zitat von: passibe am 17 Oktober 2025, 11:31:31Woher genau kommt dieser Aufruf und was wird damit abgerufen? Bin nicht so tief im FHEMWEB-Game drin, ist das irgendeine automatische Aktualisierung im Hintergrund (JavaScript?) oder erfolgt so ein Request erst, wenn man manuell auf den jeweiligen Raum (hier "Strom") klickt?
Das kann ich auch nicht sagen, aber ich glaube, dass es gestern immer ein "manuelles Aktualisieren" über den Browser war. Typischerweise habe ich dem Raum "Strom" geöffnet, wenn ich den Browser aufrufe aktualisiere ich dann das Tab.
Zitat von: passibe am 17 Oktober 2025, 11:31:31Vielleicht auch mal den Raum "Strom" checken, ob da irgendwas auffälliges drin ist? Eventuell auch mal Devices einzeln raus-verschieben, um ggfs. die Fehlerquelle zu isolieren?
Ich glaube, dass es Zufall war, weil das der typischweise geöffnete Raum ist.
Abgesehen von "SolarForecast", das tatsächlich eine sich laufend aktualisierende Grafik anzeigt, sind da einfach viele Devices gelistet (Steckdosen zum ein/ausschalten), von denen 2 zusätzlich mittels "StateFormat" dynamisch Werte geändert werden.
Gibt's noch irgendwelche Ideen was ich tun könnte um dem Problem auf die Schliche zu kommen?
Ansonsten würd' ich meinen Watchdog so umbauen, dass er nach 1 Minute ohne Rückmeldung das FHEM-Service einfach neu startet...
Also aber es stimmt schon, dass das immer nach diesem Aufruf kommt?
Zitat von: passibe am 17 Oktober 2025, 11:31:31Zitat2025.10.16 09:15:28 4: WEBphone_::ffff:194.39.218.13_60651 GET /fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DStrom%3Bsince%3D1760598915.8880098%3Bfmt%3DJSON&fw_id=1760587126.90304×tamp=1760598924249; BUFLEN:0
Wenn ja, würde ich wirklich mal nach und nach devices raus-verschieben bis es nicht mehr auftritt.
Kürzlich gab es auch Probleme (zwar kein Absturz, but still), als große Datenmengen über Websocket übermittelt wurden: https://forum.fhem.de/index.php?topic=142910.0
Vielleicht ist das hier irgendwas ähnliches, heißt, der Browser fragt irgendwelche Daten ab, die dann im weiteren Verlauf – wie auch immer – Dinge durcheinanderbringen und zack, Absturz.
Zitat von: passibe am 03 November 2025, 18:05:42Also aber es stimmt schon, dass das immer nach diesem Aufruf kommt?
Zitat von: passibe am 17 Oktober 2025, 11:31:31Zitat2025.10.16 09:15:28 4: WEBphone_::ffff:194.39.218.13_60651 GET /fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DStrom%3Bsince%3D1760598915.8880098%3Bfmt%3DJSON&fw_id=1760587126.90304×tamp=1760598924249; BUFLEN:0
Wenn ja, würde ich wirklich mal nach und nach devices raus-verschieben bis es nicht mehr auftritt.
Bisher konnte ich es immer damit "einfangen". Abgesehen von den Logs weiter oben konnte ich es bisher nicht beobachten. Ich musste die Debug-Ausgabe vor gut 2 Wochen beenden, weil ich seitdem wieder öfter unterwegs bin und da ggf. nicht zeitnah FHEM neu starten hätte können.
In dieser Zeit kam es nur 1x zu dem Problem, nämlich gestern als ich den initial verdächtigten Stand-Rechner ausgeschaltet habe und kurz darauf das iPhone in die Hand genommen habe. Da das Logging aber nicht lief, kann ich nicht sehen ob es derselbe Aufruf gewesen wäre. Da aber wie gesagt normalerweise immer dieser Raum geöffnet ist, ist die Wahrscheinlichkeit sehr hoch.
Ich kann das mit dem Rausschieben ja mal versuchen. Das würde im Endeffekt so aussehen, dass ich im 1. Schritt das SolarForecast-Gerät woanders hinschieben würde und dann den neuen Raum "SolarForecast" geöffnet hätte & nur gelegentlich zu "Strom" wechseln würde.
Zitat von: passibe am 03 November 2025, 18:05:42Kürzlich gab es auch Probleme (zwar kein Absturz, but still), als große Datenmengen über Websocket übermittelt wurden: https://forum.fhem.de/index.php?topic=142910.0
Vielleicht ist das hier irgendwas ähnliches, heißt, der Browser fragt irgendwelche Daten ab, die dann im weiteren Verlauf – wie auch immer – Dinge durcheinanderbringen und zack, Absturz.
Manchmal "erfängt" sich FHEM ja wieder... ich erhalte zwar 1-2 eMails, dass das System "hängt", es geht dann aber doch irgendwann wieder weiter.
Am Wochenende kann ich hoffentlich das Logging wieder aktivieren, dann versuch' ich den Ansatz mit dem Rausschieben vom SolarForecast-Gerät mal.
Da werden aber keine Bilder übertragen so wie im oben verlinkten Problem, d.h. ich glaube nicht, dass es ein ähnliches Problem ist.
Zitat von: TheTrumpeter am 04 November 2025, 08:36:23Da werden aber keine Bilder übertragen so wie im oben verlinkten Problem, d.h. ich glaube nicht, dass es ein ähnliches Problem ist.
Ich meinte ähnlich nur vom Konzept her.
Zitat von: TheTrumpeter am 04 November 2025, 08:36:23Das würde im Endeffekt so aussehen, dass ich im 1. Schritt das SolarForecast-Gerät woanders hinschieben würde und dann den neuen Raum "SolarForecast" geöffnet hätte & nur gelegentlich zu "Strom" wechseln würde.
So rum geht es vermutlich auch. Ich dachte eher, dass du ein device nach dem anderen in einen Raum "Temporärer Abstellraum" (oder so) verschiebst, aber immer Strom geöffnet lässt und den Temporären Abstellraum selten. Stürzt es ab, kommt das Device wieder zurück in Strom und das nächste wandert und Temporärer Abstellraum. Bin mir grade noch nicht sicher, was sinnvoller ist.
Zitat von: passibe am 04 November 2025, 13:13:10Bin mir grade noch nicht sicher, was sinnvoller ist.
Abgesehen von "SolarForecast" sind alles Geräte mit einfacher Statusanzeige oder ein/aus-Schaltmöglichkeit: schaltbare Steckdosen, SmartMeter, Wechselrichter, sowie ein paar watchdogs und notifys. Wenn davon irgendwas ein Problem verursachen würde, müsste es doch auch andere betreffen.
Nur "SolarForecast" ist relativ neu mit einer ziemlich umfangreichen Anzeige"grafik", die recht dynamisch aktualisiert wird.
Deshalb mein Ansatz mit dem zu beginnen.