Von gestern auf heute spinnt FHEM plötzlich auf meinem RPi3, ich habe seit einigen Tagen keine Konfiguration geändert und auf dem RasPi generell schon länger nix mehr geändert.
Heute Früh dann plötzlich der erste (unbemerkte) Neustart, kurz nach dem Essen wieder und vorher schon wieder keine Reaktion.
Zu Mittag habe ich dann noch versucht FHEM zu stoppen, aber der Status blieb immer auf "FHEM is running".
Habe nach dem Neustart dann mal ein FHEM-"update" gemacht, aber auch nun tritt das Problem wieder auf. Diesmal ließ sich FHEM zumindest beim 2. Versuch über den init.d-Befehl beenden und neu starten.
FHEM-Log sieht unauffällig aus, einzig seit dem Update bekomme ich haufenweise Warnings vom FRITZBOX-Modul.
Im Syslog konnte ich auch nichts auffälliges erkennen.
Irgendwelche Hinweise wo ich noch suchen könnte?
Zitat von: TheTrumpeter am 19 April 2023, 17:15:45Habe nach dem Neustart dann mal ein FHEM-"update" gemacht, aber auch nun tritt das Problem wieder auf. Diesmal ließ sich FHEM zumindest beim 2. Versuch über den init.d-Befehl beenden und neu starten.
Das klingt nach einem sehr sehr alten System. Was sagen dann die Logs vom System.
/var/log/syslog
oder eventuell
/var/log/messages
Zitat von: TheTrumpeter am 19 April 2023, 17:15:45FHEM-Log sieht unauffällig aus, einzig seit dem Update bekomme ich haufenweise Warnings vom FRITZBOX-Modul.
"haufenweise Warnings" und "FHEM-Log sieht unauffällig aus" passt für mich aber nicht zusammen.
Prüfe mal welches Wetter-Modul du einsetzt. Ich hatte ein ähnliches Problem mit dem abgekündigten DarkSky - siehe auch https://forum.fhem.de/index.php?topic=95823.msg1270972#msg1270972 (https://forum.fhem.de/index.php?topic=95823.msg1270972#msg1270972)
Zitat von: betateilchen am 19 April 2023, 17:28:43Zitat von: TheTrumpeter am 19 April 2023, 17:15:45FHEM-Log sieht unauffällig aus, einzig seit dem Update bekomme ich haufenweise Warnings vom FRITZBOX-Modul.
"haufenweise Warnings" und "FHEM-Log sieht unauffällig aus" passt für mich aber nicht zusammen.
Ich habe schon ewig bestimmte Warnings von einem HTTPMOD Device, die ich nicht weg bekomme. Die sind aber schon ewig da.
Sonst war da nix bis zum Update, das ich nur wg. dem beschriebenen Problem gemacht habe. Seitdem wie gesagt neue Warnungen vom FRITZBoX-Modul, sonst nix.
Zitat von: Gigafix am 19 April 2023, 17:52:23Prüfe mal welches Wetter-Modul du einsetzt. Ich hatte ein ähnliches Problem mit dem abgekündigten DarkSky - siehe auch https://forum.fhem.de/index.php?topic=95823.msg1270972#msg1270972 (https://forum.fhem.de/index.php?topic=95823.msg1270972#msg1270972)
Danke, ich habe PROPLANTA, das funktioniert aber noch.
Zitat von: CoolTux am 19 April 2023, 17:23:22Zitat von: TheTrumpeter am 19 April 2023, 17:15:45Habe nach dem Neustart dann mal ein FHEM-"update" gemacht, aber auch nun tritt das Problem wieder auf. Diesmal ließ sich FHEM zumindest beim 2. Versuch über den init.d-Befehl beenden und neu starten.
Das klingt nach einem sehr sehr alten System. Was sagen dann die Logs vom System.
/var/log/syslog
Habe im relevanten Zeitraum meiner Meinung nach nix auffälliges gefunden, irgendeine Idee wonach ich im Speziellen suchen soll?
von was für einen System reden wir denn überhaupt?
Welche Distri in welcher Version?
Würde auf eine kaputte SD-Karte tippen. Scheint ein PI zu sein, der so schon "ewig" lief (original OS scheint noch init.d genutzt zu haben).
Zitat von: CoolTux am 19 April 2023, 18:22:11von was für einen System reden wir denn überhaupt?
Welche Distri in welcher Version?
pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch
Zitat von: TheTrumpeter am 19 April 2023, 18:33:42Zitat von: CoolTux am 19 April 2023, 18:22:11von was für einen System reden wir denn überhaupt?
Welche Distri in welcher Version?
pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch
Wie Beta-User schon schrieb. Das System ist Uralt. Ich würde neu installieren mit einer neuen SD Karte.
Nur weil jemand noch das fhem-Startskript in /etc/init.d liegen hat, muss das System nicht zwangsläufig veraltet sein.
Bei meinem aktuellen raspbian, das seit jessie von Generation zu Generation updates erfahren hat (immer auf die gleiche SD-Karte...) liegt das Skript dort auch noch. Und man kann damit bei einem manuellen Aufruf auch problemlos das über systemd gestartete FHEM beenden. Es ist ja nix anderes als jedes andere bash-Skript auch.
Zitat von: betateilchen am 19 April 2023, 19:14:36Nur weil jemand noch das fhem-Startskript in /etc/init.d liegen hat, muss das System nicht zwangsläufig veraltet sein.
Bei meinem aktuellen raspbian, das seit jessie von Generation zu Generation updates erfahren hat (immer auf die gleiche SD-Karte...) liegt das Skript dort auch noch. Und man kann damit bei einem manuellen Aufruf auch problemlos das über systemd gestartete FHEM beenden. Es ist ja nix anderes als jedes andere bash-Skript auch.
Zitatpi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch
Das hatte ich durchaus zur Kenntnis genommen.
Ändert aber nichts an meiner Aussage zum eindimensionalen Denken.
Zitat von: CoolTux am 19 April 2023, 18:55:22Wie Beta-User schon schrieb. Das System ist Uralt. Ich würde neu installieren mit einer neuen SD Karte.
Frage mich warum das "uralte" System hier irgendeine Relevanz hat.
Der RasPi hat genau 1 Aufgabe, nämlich FHEM mit seinen zahlreichen Modulen zu hosten. Das tut er seit über 6 Jahren zuverlässig.
Ich habe Log2RAM laufen sowie zusätzlich eine kleine RAM-Disk, in der die häufig geänderten Dateien liegen. Die FHEM-Logs liegen auf einem separaten USB-Stick, d.h. die SD-Karte sollte nicht allzu viel beschrieben werden.
Aber gut, falls wirklich nur die SD-Karte der Quell des Übels ist, dann tausche ich die einfach aus. Nur wird der Austausch so stattfinden, dass ich einfach das komplette Image vom 01.04.2023 auf die neue SD-Karte spiele und fertig. (1x monatlich wird die komplette SD-Karte gebackupt.)
Werde das bis zum Wochenende beobachten und dann weitersehen. Seit ich den Thread eröffnet habe, gibt's keine Auffälligkeiten.
Sehe nicht, welchen Vorteil ich davon hätte komplett neu zu starten und alles neu einzurichten, nur um die neueste Distri zu haben... zumal es da noch das Phänomen gibt, zu dem ich gleich unten komme...
Zitat von: Beta-User am 19 April 2023, 18:27:26Würde auf eine kaputte SD-Karte tippen. Scheint ein PI zu sein, der so schon "ewig" lief (original OS scheint noch init.d genutzt zu haben).
Das wäre mir grad zu viel Zufall. Hintergrund:
Habe vor kurzem 2 Model 3A+ angeschafft, weil ich meinen "Reserve 3B" von seinem Dasein als JDownload-Sklave befreien wollte, um ihn wg. der schlechten Verfügbarkeit der Teile wieder als "Reserve" zum FHEM-RasPi zu haben.
Anstatt einfach nur die SD-Karte vom "JDownload-RasPi" (Buster Lite von 2020) umzustecken, habe ich beschlossen die neueste Distri inkl. grafischer Oberfläche zu nehmen, weil es praktisch ist von unterwegs mit dem Mobiltelefon auf ein System mit grafischer Oberfläche zugreifen zu können (für myJDownloader).
Habe daher "Bullseye" in der 64bit Version auf eine nagelneue SD-Karte gespielt und losgelegt, aber ständig Probleme mit massiven Verzögerungen (über SSH) festgestellt, über VNC ging fast gar nix. Als ich 2016 mit dem Zeug angefangen habe, hab' ich auch erstmal mit grafischer Oberfläche begonnen, solche Probleme gab's da nicht.
Jedenfalls habe ich das Zeug dann beobachtet und festgestellt, dass immer bei den Verzögerungen offenbar SD-Zugriffe stattgefunden haben (grüne LED hat fast ständig geleuchtet). Nach mehrmaligem Neuaufspielen des Images hab' ich dann eine andere ebenfalls nagelneue SD-Karte probiert, da war's genauso.
Hab' dann wieder auf die 1. neue SD-Karte gewechselt und das Image nochmal neu aufgespielt, ein paar Stunden später war die SD-Karte dann hinüber. Bis dahin habe ich nicht mehr gemacht als den SSH-Port zu ändern, ein Netzlaufwerk zu mouten, VNC zu aktivieren und einfach nur über VNC verbunden zu sein. In der Zeit gab's immer wieder diese "Blockaden", ich hab' mir erstmal nix dabei gedacht und die SD-Karte (NoName, die ich irgendwo mal gratis bekommen habe) weggeworfen.
Die 2. SD-Karte (Transcend Premium), von der ein baugleiches Exemplar seit ca. 2 Jahren problemlos in dem "JDownloader-Raspi" läuft, hat wenige Stunden später das Zeitliche gesegnet. Die wird in einem Windows-Rechner zwar noch erkannt, aber als "schreibgeschützt" und die Boot-Partition hat nur fehlerhafte Sektoren, die 2. Partition hat am Anfang noch ein paar gute Blöcke, danach scheint auch alles fehlerhaft zu sein. Die Karte habe ich zuvor noch in dem 2. neuen 3A+ probiert, weil ich einen HW-Defekt am RasPi für das komische Verhalten vermutet habe.
Gestern habe ich dann eine 3. neue Karte (SanDisk Ultra) mit dem letzten "Buster Lite 32bit" Release bespielt, aber noch nicht weiter ausprobiert.
Einerseits kann ich mir nicht erklären was das Verhalten ausgelöst hat, aber andererseits kann ich auch nicht glauben, dass ein offizielles Release von der offiziellen RasPi-Seite so einen massiven Bug hätte, der dieses Verhalten erklären würde.
Und wenn dann jetzt jemand kommt und mir erklären will, dass die SD-Karte vom dem unauffälligen "FHEM-RasPi" praktisch zeitgleich kaputt wird, dann verstehe ich die Welt nicht mehr.
Zitat von: TheTrumpeter am 19 April 2023, 17:15:45.....einzig seit dem Update bekomme ich haufenweise Warnings vom FRITZBOX-Modul.
Ein Hinweis zu den vielen Meldungen vom FRITZBOX-Modul -wenn das System wieder läuft, vielleicht mit Update und aktualisiertem FRITZBOX-Modul.
Aufgrund der Anpassungen am Modul musst Du vermutlich das define ändern und IP oder Host dazufügen.
Zitatdefine <name> FRITZBOX <host>
Der Parameter host ist die Web-Adresse (Name oder IP) der FRITZ!BOX / Repeater.
und schau bitte hier die Infos aus der Version 07.50.10
| INFO | The support for telnet and operation on a Fritz!Box has been discontinued. The functions are disabled. |
| INFO2 | The following attributes are not longer supported: |
| | useGuiHack, ringWithIntern, defaultCallerName, allowTR064Command, |
| | forceTelnetConnection, telnetUser, telnetTimeOut |
| | Use deleteattr to delete from Attributes. |
| INFO3 | The attribute fritzBoxIP is not longer supported! |
| | May be you have to use deleteattr to delete fritzBoxIP from Attributes. |
| | The definition of the device has been adjusted. Please use 'Save config' |
Gruß
Zitat von: RalfRog am 20 April 2023, 00:19:24Zitat von: TheTrumpeter am 19 April 2023, 17:15:45.....einzig seit dem Update bekomme ich haufenweise Warnings vom FRITZBOX-Modul.
Ein Hinweis zu den vielen Meldungen vom FRITZBOX-Modul -wenn das System wieder läuft, vielleicht mit Update und aktualisiertem FRITZBOX-Modul.
Aufgrund der Anpassungen am Modul musst Du vermutlich das define ändern und IP oder Host dazufügen.
Zitatdefine <name> FRITZBOX <host>
Der Parameter host ist die Web-Adresse (Name oder IP) der FRITZ!BOX / Repeater.
Danke für den Hinweis, genau das war's.
Was das Problem mit dem nicht reagierenden FHEM betrifft habe ich auch einen Verdacht wodurch es ausgelöst wird. Werde das morgen mal genauer untersuchen bzw. gezielt zu reproduzieren versuchen.
Wenn sich der Verdacht bestätigt, hat es genau 0,0 mit der SD-Karte zu tun.
So, mal ein Update:
Mein Verdacht war, dass das FHEM-Problem durch einen Zugriff auf die Website von meinem Arbeits-Rechner getriggert wird.
Zwar hat das in der Vergangenheit noch nie Probleme verursacht & spontan könnte ich mir auch nicht erklären wie es zu dem Problem kommen sollte, aber tatsächlich habe ich die Probleme jedes Mal durch einen Zugriff vom Arbeitsrechner aus festgestellt & anhand der FHEM-Filelogs schien der Auftretenszeitpunkt auch immer zu dem Zugriffszeitpunkt zu passen.
Gestern konnte ich es dann nicht prüfen und heute Nacht gab es wohl einen kurzen Stromausfall bei uns. Seitdem konnte ich es nicht mehr reproduzieren, egal von welchem Rechner und mit welchem Browser ich es versuche, der Zugriff klappt problemlos.
Zitat von: TheTrumpeter am 21 April 2023, 14:37:47So, mal ein Update:
Mein Verdacht war, dass das FHEM-Problem durch einen Zugriff auf die Website von meinem Arbeits-Rechner getriggert wird.
Zwar hat das in der Vergangenheit noch nie Probleme verursacht & spontan könnte ich mir auch nicht erklären wie es zu dem Problem kommen sollte, aber tatsächlich habe ich die Probleme jedes Mal durch einen Zugriff vom Arbeitsrechner aus festgestellt & anhand der FHEM-Filelogs schien der Auftretenszeitpunkt auch immer zu dem Zugriffszeitpunkt zu passen.
Gestern konnte ich es dann nicht prüfen und heute Nacht gab es wohl einen kurzen Stromausfall bei uns. Seitdem konnte ich es nicht mehr reproduzieren, egal von welchem Rechner und mit welchem Browser ich es versuche, der Zugriff klappt problemlos.
Gerade ist es wieder aufgetreten, und bemerkt habe ich es zufälligerweise wieder durch einen Zugriff von meinem Arbeits-Rechner.
Habe mich dann gleich per SSH auf den RasPi verbunden, er sagte "FHEM is running" und die Prozessorlast war auch unauffällig.
Kurze Zeit später hat dann mein "Watchdog" FHEM neu gestartet.
Was mich wundert, ist, dass
- das Beenden von FHEM durch den Watchdog nicht im Logfile ersichtlich ist.
- der erste Neustart offenbar nicht erfolgreich war (wg. telnetPort-Fehler, den ich so noch nie gesehen habe)
Hier der Logfile-Auszug von dem Zeitpunkt, die letzte Zeile davor ist von 2023.04.27 02:02:14 vom PROPLATA-Modul, weil die Wetterdaten nicht abgerufen werden konnten.
2023.04.27 08:01:01 1: PERL WARNING: given is experimental at ./FHEM/99_myLWZUtils.pm line 389.
2023.04.27 08:01:01 1: PERL WARNING: when is experimental at ./FHEM/99_myLWZUtils.pm line 391.
2023.04.27 08:01:02 1: PERL WARNING: when is experimental at ./FHEM/99_myLWZUtils.pm line 392.
2023.04.27 08:01:02 1: PERL WARNING: when is experimental at ./FHEM/99_myLWZUtils.pm line 393.
2023.04.27 08:01:02 1: PERL WARNING: when is experimental at ./FHEM/99_myLWZUtils.pm line 394.
2023.04.27 08:01:02 1: PERL WARNING: when is experimental at ./FHEM/99_myLWZUtils.pm line 395.
2023.04.27 08:01:02 1: PERL WARNING: when is experimental at ./FHEM/99_myLWZUtils.pm line 396.
2023.04.27 08:01:02 1: PERL WARNING: when is experimental at ./FHEM/99_myLWZUtils.pm line 397.
2023.04.27 08:01:02 1: PERL WARNING: when is experimental at ./FHEM/99_myLWZUtils.pm line 398.
2023.04.27 08:01:02 1: PERL WARNING: when is experimental at ./FHEM/99_myLWZUtils.pm line 399.
2023.04.27 08:01:02 1: Including fhem.cfg
2023.04.27 08:01:02 1: telnetPort: Can't open server port at 7072: Address already in use. Exiting.
2023.04.27 08:01:09 0: Server shutdown
2023.04.27 08:02:20 1: PERL WARNING: given is experimental at ./FHEM/99_myLWZUtils.pm line 389.
2023.04.27 08:02:20 1: PERL WARNING: when is experimental at ./FHEM/99_myLWZUtils.pm line 391.
2023.04.27 08:02:20 1: PERL WARNING: when is experimental at ./FHEM/99_myLWZUtils.pm line 392.
2023.04.27 08:02:20 1: PERL WARNING: when is experimental at ./FHEM/99_myLWZUtils.pm line 393.
2023.04.27 08:02:20 1: PERL WARNING: when is experimental at ./FHEM/99_myLWZUtils.pm line 394.
2023.04.27 08:02:20 1: PERL WARNING: when is experimental at ./FHEM/99_myLWZUtils.pm line 395.
2023.04.27 08:02:20 1: PERL WARNING: when is experimental at ./FHEM/99_myLWZUtils.pm line 396.
2023.04.27 08:02:20 1: PERL WARNING: when is experimental at ./FHEM/99_myLWZUtils.pm line 397.
2023.04.27 08:02:20 1: PERL WARNING: when is experimental at ./FHEM/99_myLWZUtils.pm line 398.
2023.04.27 08:02:20 1: PERL WARNING: when is experimental at ./FHEM/99_myLWZUtils.pm line 399.
2023.04.27 08:02:20 1: Including fhem.cfg
2023.04.27 08:02:30 1: SmartMeterRestAPI: the attribute reading110Expr should no longer be used. Please use reading110OExpr instead
2023.04.27 08:02:30 1: SmartMeterRestAPI: For most old attributes you can specify enableControlSet and then set device upgradeAttributes to automatically modify the configuration
2023.04.27 08:02:30 1: SmartMeterRestAPI: the attribute reading111Expr should no longer be used. Please use reading111OExpr instead
2023.04.27 08:02:30 1: SmartMeterRestAPI: For most old attributes you can specify enableControlSet and then set device upgradeAttributes to automatically modify the configuration
2023.04.27 08:02:32 1: Including /opt/fhem/log/fhem.save
2023.04.27 08:02:33 0: Featurelevel: 6.2
2023.04.27 08:02:33 0: Server started with 314 defined entities (fhem.pl:27410/2023-04-07 perl:5.024001 os:linux user:fhem pid:11509)Der letzte Eintrag in den FileLogs stammt von 07:59:36, was ziemlich genau der Zeitpunkt meines Zugriffs vom Arbeitsrechner sein müsste.
Dann gibt es welche von 08:01:05 bis 08:01:09, was dem Zeitpunkt des ersten (erfolglosen) Neustarts entspricht.
Seit 08:02:36 geht's wieder weiter.
Habe nun erneut den Zugriff vom Arbeits-Rechner versucht, geht natürlich wieder problemlos.
Was kann ich vorbereitend tun, damit ich das Problem beim nächsten Mal "einfangen" kann?
Loglevel von FHEMweb hochsetzen?
Globales Loglevel hochsetzen?
Zitat von: TheTrumpeter am 27 April 2023, 08:25:07Kurze Zeit später hat dann mein "Watchdog" FHEM neu gestartet.
Was mich wundert, ist, dass
- das Beenden von FHEM durch den Watchdog nicht im Logfile ersichtlich ist.
- der erste Neustart offenbar nicht erfolgreich war (wg. telnetPort-Fehler, den ich so noch nie gesehen habe)
So, DIESES Rätsel dürfte ich gelöst haben... der Watchdog hat nach dem Absetzen des "/etc/init.d/fhem stop" bisher 3 Sekunden gewartet, bevor "/etc/init.d/fhem start" abgesetzt wurde. Die 3 Sekunden Wartezeit habe ich irgendwann mal zu Friedenszeiten ausprobiert.
Im aktuellen Problemfall scheint es aber länger zu dauern bis FHEM tatsächlich beendet wird, weshalb der erneute "Start" in den laufenden Betrieb kommt. Daher fehlt der "Server shutdown" Logeintrag und es kommt beim erneuten Start zum Fehler mit dem Telnet-Port, weil der durch den laufenden Prozess noch blockiert ist.
Ich hab' die Wartezeit nun mal auf 15 Sekunden erhöht (10 waren auch zu wenig), damit der Neustart zumindest sauber funktioniert, wenn ich schon die Problemursache noch nicht finden konnte.
Einen wirklichen Plan wann es auftritt habe ich noch immer nicht.
Kann es sein, dass du unterschiedliche (FHEM-Detail-) Seiten aufrufst von den verschiedenen Rechnern aus?
Dann _könnte_ es sein, dass FHEM forkt (z.B. um svg's zu produzieren) und dann der PI (evtl. nur bei zusätzlichen anderen forks) anfängt zu swappen, und dann "zu langsam" ist, um alle Prozesse sauber/schnell genug abzuarbeiten. Grade wenn/weil du eine ramdisk eingebaut hast, ist der Speicher evtl. etwas knapp.
Je nachdem, von wo du (bei diversen Modulen) versionsmäßig kommst, gab es evtl. auch Änderungen in der Art und Weise, wann/wie geforkt wird und wie viele Events erzeugt werden.
Zitat von: Beta-User am 27 April 2023, 13:41:25Kann es sein, dass du unterschiedliche (FHEM-Detail-) Seiten aufrufst von den verschiedenen Rechnern aus?
Kann Dir nicht ganz folgen, von den PCs gehe ich immer auf Port 8083 (FHEMweb), vom Smartphone auf 8084 (FHEMwebPhone).
Ich rufe immer wieder dieselben "rooms" auf, aber natürlich nicht immer nur einen.
Zitat von: Beta-User am 27 April 2023, 13:41:25Dann _könnte_ es sein, dass FHEM forkt (z.B. um svg's zu produzieren) und dann der PI (evtl. nur bei zusätzlichen anderen forks) anfängt zu swappen, und dann "zu langsam" ist, um alle Prozesse sauber/schnell genug abzuarbeiten. Grade wenn/weil du eine ramdisk eingebaut hast, ist der Speicher evtl. etwas knapp.
Heute um 8 habe ich ein Dashboard aufgerufen, von dem ich einfach meine Rollos/Raffstores aus steuern kann. Da ist praktisch nix zu laden.
Davor habe ich einige Minuten von keinem anderen Rechner aus zugegriffen. Zu dem Zeitpunkt waren ca. 800MB RAM frei (ist ein Pi3B mit 1GB, auf dem nur FHEM läuft, die RAM-Disk hat nur ein paar MB).
Zitat von: Beta-User am 27 April 2023, 13:41:25Je nachdem, von wo du (bei diversen Modulen) versionsmäßig kommst, gab es evtl. auch Änderungen in der Art und Weise, wann/wie geforkt wird und wie viele Events erzeugt werden.
Das Problem kam ja noch bevor ich ein "update" in FHEM gemacht habe, nach monatelangem problemlosen Betrieb. Das "update" habe ich nur gemacht, um das Problem dadurch ev. zufällig zu lösen, was leider nicht der Fall ist.
Ich habe im letzten Monat meine "große" PV-Anlage in Betrieb genommen und in dem Zuge erstmals ModbusAttrTCP konfiguriert bzw. in Betrieb genommen. Bis zum erstmaligen Problemauftritt ist es aber auch schon ca. 1 Monat gelaufen.
Eine Idee war grad, dass ev. die File-Logs dadurch deutlich größer sind als in der Vergangenheit, aber der Verdacht hat sich nicht bestätigt, die Files sind vergleichbar mit den ersten 3 Monaten in 2023. Dadurch sollte also auch keine höhere Last entstehen als früher.
Das Problem ist heute 2x so aufgetreten, dass der Browser (am Arbeitsrechner) gerade "connection lost, trying to reconnect every 5 seconds" oder so ähnlich geschrieben hat und ich dann einen anderen Raum angeklickt bzw. "aktualisieren" geklickt habe.
Und jetzt grad ist es wieder aufgetreten: ein Raum wurde noch vollständig geladen (ein paar SVG-Plots), ein paar Sekunden später habe ich einen anderen Raum angeklickt (Wettervorschau, d.h. keine SVGs zu produzieren). Als Status habe ich gerade noch den "TLS-Handshake" gesehen, danach wechselte es auf "Warten auf <IP-Adresse>" und da hängt's grad.
Der Watchdog ist dann wieder angesprungen und hat dem Treiben ein Ende gesetzt.
Zitat von: TheTrumpeter am 27 April 2023, 14:30:04Zitat von: Beta-User am 27 April 2023, 13:41:25Kann es sein, dass du unterschiedliche (FHEM-Detail-) Seiten aufrufst von den verschiedenen Rechnern aus?
Kann Dir nicht ganz folgen, von den PCs gehe ich immer auf Port 8083 (FHEMweb), vom Smartphone auf 8084 (FHEMwebPhone).
Ich rufe immer wieder dieselben "rooms" auf, aber natürlich nicht immer nur einen.
Na ja, du hattest geschrieben, dass du beobachtet hattest, dass das Problem evtl. damit zusammenhing, dass du von deinem "Arbeitsrechner" aus zugreifst. Wenn das zutreffend wäre, müßte es am auszuliefernden Inhalt liegen, also entweder irgendwas "browserspezifisches", das FHEM "drumrum" ausliefert, oder eben am darzustellenden Inhalt. Die aufgerufene Web-Seite (html-Link) könnte ja (unabhängig vom Port) unterschiedlich sein, z.B. weil über entsprechende Favoriten oder anderweitig gespeicherte Detaillinks eben nicht zwangsläufig immer die "Startseite" augerufen werden muss.
Aber anscheinend hängt es doch nicht am Endgerät, auf dem FHEMWEB irgendwas darstellen soll.
_Vielleicht_ ist einfach die Hardware sonst irgendwie kaputt...
Mal wieder ein Update:
Ende April trat das Problem immer mal wieder beim Zugriff von meinem Arbeitsrechner mit Firefox auf. Die genauen Abläufe wann es auftritt und wann nicht, konnte ich nicht herausfinden, aber es trat zuletzt 1-2x täglich auf.
Seitdem greife ich von diesem Rechner nur noch von Chrome aus zu, das Problem ist seither nicht mehr aufgetreten.
Ich bin daher nach wie vor der Meinung, dass es an irgendetwas liegen muss, was Firefox auf diesem Rechner "anders" macht.
Was könnte ich versuchen um das Problem "einzufangen"?
Würde es Sinn machen eine zusätzliche "FHEMweb"-Instanz mit anderem Port definieren, Loglevel dafür hochsetzen, und diesen Port nur vom Arbeitsrechner mit Firefox nutzen?