Guten Morgen zusammen,
ich weiß, ich bin mit folgendem ein ungern gesehener Außenseiter hier, wenn ich zugebe, dass FHEM bei mir unter Raspbian (mit GUI) problemlos läuft.
Folgende Frage habe ich im Vorfeld, um möglichen Schwierigkeiten aus dem Weg zu gehen bzw. mich für den Fall zu wappnen.
Mein FHEM-System inkl. Raspberry Pi mit Raspberry Pi OS "Buster" wird diesen Dezember genau 2 Jahre alt. Seither habe ich FHEM regelmäßig aktualisiert, ebenso diverse Hardwarekomponenten (deConz) und alles läuft soweit prima.
Worum ich mich nicht gekümmert habe, waren Updates des Betriebssystems, damals noch mit Linux Kernel Version 4.19. Inzwischen gibt es schon Version 5.10.17 und ebenso weitere aktualisierte Bestandteile des Betriebssystems. Es wäre möglicherweise sinnvoll, diese Updates nachzuholen.
Muss ich mir mit Bezug zu FHEM irgendwelche Gedanken vor dem Update machen?
Ich würde mich sonst regulär an die raspi-docu halten ( https://www.raspberrypi.org/documentation/computers/os.html#using-apt ).
Da mir jegliche Erfahrungen im Hinblick fehlen, möchte ich deshalb Eure Einschätzung vorher einholen.
VIelen Dank vorab.
Ich mache regelmäßig
apt update
apt upgrade
reboot
auf meinen Raspis
FHEM hat da gar kein Problem mit. Ich habe sogar schon ein update von Stretch->Buster hinter mir.
"Eigentlich" sollte das stressfrei gehen, FHEM an sich ist in der Regel nicht das Problem, schon gleich nicht, wenn man kein Distributions-upgrade macht (buster->bullseye)....
Die Haken, über die man sich bei einem OS-upgrade Gedanken machen sollte:
- Werden "tieferliegende" Funktionen verwendet, die über das OS laufen? Insbesondere: GPIO-Zugriffe könnten eine Falle darstellen (einer der Gründe, warum ich für sowas lieber einen Arduino etc. dazwischenschalte)
- Ändert sich was an Perl (in der Regel nicht bei buster->buster usw.)?
Würde dazu tendieren, hier eher noch zu warten, bis "bullseye" dann Basis von Raspi-OS ist und vorher nochmal zu schauen, dass die Perl-Funktionen "sauber" sind, also keine "unescaped löeft brace"-Meldungen im Log zu finden sind usw..
Dann einen Neuaufsatz (ohne GUI...) auf einer neuen SD-Karte; dann hast du die alte immer noch als Notlösung, falls was schief geht. (Oder eben direkt das aktuelle OS nehmen, und dann buster (aktuell) -> bullseye umziehen...
(Oder ist die GUI wichtig? Jedenfalls deconz-GUI kann man auch per "remote X-Server" starten, wenn man das braucht).
Also Prinzipiell "sollten" kleine Updates kein Problem machen. Da Du einen PI hast, hast Du eine Kopie der SD-Card? Vor allem bei größeren Veränderungen IMMER Sinvoll .....
Hi zusammen,
jau, eine Backup-SD Karte habe ich immer rumliegen, allein schon aus meinen Erfahrungen mit plötzlich gestorbenen SD-Cards.
Ich nutze den Pi ausschließlich für FHEM in Verbindung mit angeschlossenem Monitor zur grafischen Steuerung via FTUI und angeschlossenem ConBee II USB-Stick für mein Zigbee Netzwerk. Andere Aufgaben hat der Pi explizit nicht erhalten.
Kleiner Exkurs zur GUI-Entscheidung.... nunja ich sehe mich bei weitem nicht als "Kenner" von Unix, Linux & Co, der mit Kommandozeile arbeitet. Drum war es mir immer ein persönliches Bedürfnis, ein GUI-unterstütztes Betriebssystem zu haben, was an sich bei mir auch echt keine Probleme bereitet. Nachdem der Pi hochgefahren ist, startet sich die deConz Oberfläche, ich öffne den Chrome-Browser, logge mich in FHEM ein und starte FTUI im Vollbildmode, fertig.
Andere Frage:
besteht überhaupt eine zu MS Windows / macOS vergleichbare Notwendigkeit auf regelmäßige Updates des Betriebssystems? Das war mein eigentlicher Hintergrundgedanke für diese Thematik. Ich erwarte keine neuen Features damit, sondern höchstens Bugfixes oder erhöhte Stabilität bzw. ggf. gefixte kritische Sicherheitslücken. Mir fiel der Gedanke am Wochenende auf, als ich mal wieder diverse Updates meiner Netzwerk- und Serverdevices durchschob, dass einzig der Pi bisher überhaupt kein Update erhielt.
Zitat von: Dracolein am 28 September 2021, 09:09:19
Kleiner Exkurs zur GUI-Entscheidung.... nunja ich sehe mich bei weitem nicht als "Kenner" von Unix, Linux & Co, der mit Kommandozeile arbeitet.
...was hindert dich daran, "das bißchen" zu lernen?
Zitat
Drum war es mir immer ein persönliches Bedürfnis, ein GUI-unterstütztes Betriebssystem zu haben, was an sich bei mir auch echt keine Probleme bereitet. Nachdem der Pi hochgefahren ist,
...sollte sich der Paket-Manager des OS eigentlich direkt melden und mitteilen, dass diverse sicherheitskritische Updates zur Verfügung stehen...
Zitat
Andere Frage:
besteht überhaupt eine zu MS Windows / macOS vergleichbare Notwendigkeit auf regelmäßige Updates des Betriebssystems?
::) s.o....
Das "Problem" ist aber grade durch die GUI nicht kleiner, sondern größer, weil eben jedes installierte Paket auch Sicherheitslücken aufweisen kann. Von weiteren Fallstricken wie "modemmanager" reden wir dabei noch gar nicht...
MAn. solltest du dringend die Serverfunktion _headless!_ von FTUI trennen - für "Bedienzwecke" (so man überhaupt solche hat) reicht eigentlich auch ein mehr oder weniger beliebiges Endgerät mit Browser, von mir aus gerne auch ein weiterer Pi, wenn's denn unbedingt sein muss...
(Oder: die Experten können ggf. sogar Anleitungen liefern, wie man nur einen Fullscreen-Browser ohne den sonstigen Ballast einer GUI startet...)
Genau so haben wir das Monitoring in meiner alten Firma erledigt. Der Browser wurde automatisch (ohne GUI) beim Booten im XServer Hochgefahren ... leider habe ich das Image nicht mehr.
(Hinweis: System + XServer + GUI sind die 3 "Ebenen" des Rechners. Mann kann also unter Unix Grafische Probramme ohne GUI starten)
Was viele Vergessen: Schon die Existens der Libs der GUI kann Seurity Probleme bereiten.
Und was in diesem Thread viel Wichtiger ist: Je mehr installiert ist, desto mehr kann beim Update Probleme machen.
Hinweis: Dazu gehört auch CPAN!
Also ein "nacktes" Serverbetriebsystem für FHEM (Ohne GUI, CPAN und Hardwareanpassungen) ist "eigentlich" Problemlos upzudaten. Auch über Versionsgrenzen hinweg. Habe es beruflich auch schon mit LAMP (Bzw. LNMP, da Nginx anstatt Apache) mehr als ein mal Problemlos durchgeführt und da machen PHP-Versionen eigentlich die Probleme.
antworten auf die thread-frage können ja nur spekulationen sein.
daher würde ich auf einer neuen sdcard mit einem funktionierenden aktuellen image das update/upgrade ausführen und selber auf probleme achten (logs anschauen).
gibt es probleme, einfach mit alter sdcard fortfahren.
Trotz der 120 Tage, hol ich den "Mist" noch mal hier raus ...
JA, in der Tat ist ein Update von Buster auf Bullseye der letzte Krampf, um nicht zu sagen "fast" unmöglich ohne enormes Handanlegen (mit Fachkenntnis vorausgesetzt)!
Meine Vorgeschichte: FHEM Backup gemacht, Neue SD-Card (bullseye) komplett frisch, wie es ja so schön hier empfohlen wird gemacht.
(Ein nicht so sehr empfohlendes In-Upgrade auch probiert / Buster/Full-Upgrade/Bullseye), ohne Chance auf ein sauberes Reboot inkl. System!
... und dann bin ich keiner, der sich wenig mit Linux auskennt!
... weiter zum Thema:
Mein bestehendes voll funktionsfähiges FHEM umfasst ca. 500 Defines inkl. sämtlicher Zwave Fibaro usw. / Daher sträubte ich mich (und das nun aktuell völlig zurecht), für ein Neuaufsetzen inkl. Bullseye von meiner FHEM-Plattform. (Läuft ja auch :-) )
Beides völlig unlauffähig, was das ein Full-Update betrifft (Inlake-Upgrade , also Buster/Bullseye funktioniert nicht ohne Errors).
Oh, kein Problem mit Backup/- und Restore! Bitte völlig neu ein RaspiOS frischt auf SD-Card drauf und dann völlig (schmerzfrei dein FHEM-Backup) über Restore zurück ... / DAS geht völlig naneben, weil etliche Abhängigkeiten für FHEM fehlen (.z.B. CPAN etc.)!!
Dies war mir persönlich völlig unmöglich, selbst bei Neuaufsetzung von Raspbian, ein Backup von FHEM fehlerfrei zu restoren!
Hier sollte mal langsam seitens dem Entwickler (R.K.) nachjustiert werden, da eben auch gemäß des FHEM-Entwicklungstandes (6.1) einiges nicht mehr zeitgemäß zu scheinen ist!
Für mich, (und ich bin zur ersten Stunde ein FHEM Nutzer), bedarf es jetzt langsam der Überlegung, ein zeitgemäßeres Smarthome System zu nutzen, da hier aktuell wenig der Zeit mitgegangen wird.
Ein problemloses Upgrade auf neuere Debian-Dist ist leider laienhaft unmöglich!
Wie es mit ioBroker oder OPENHab/home-Assistant bezüglich der Upgrade-Funktionalität ist, vermag ich nicht zu beurteilen.
Allerdings, war aktuell die URL bei mir mit http:IP:8083 nicht mehr aufrufbar.
Nach LOG sämtlicher Errors , wie CPAN (Nachinstallierungen), keine Change auf Erfolg.
Letztendlich ist ein Upgrade in FHEM der völlige Kram, weil hier selbst nie dem Debian-Fortschritt nachgefolgt wird.
Grundsätzlich nutze ich seit vielen Jahren FHEM, nur habe ich aktuell "Bauchschmerzen" was die Zukunft in Bezug auf Upgrades betrifft.
Ich hatte schon damals ein Problem von Strech auf Buster zu schwenken ...
Zitat von: topa_LE am 01 Oktober 2022, 23:44:30
Letztendlich ist ein Upgrade in FHEM der völlige Kram, weil hier selbst nie dem Debian-Fortschritt nachgefolgt wird.
Das kann ich nicht nachvollziehen. Ein "nackiges" FHEM läuft nach meiner bisherigen Erfahrung ohne weiteres auf sehr vielen Debian-Versionen und auch auf extremst vielen Perl-Versionen...
Es wird seitens der meisten Modul-Maintainern auch darauf geachtet, externe Perl-Abhängigkeiten (v.a. von Modulen, die _nur_ über cpan zu bekommen sind!) möglichst gering zu halten.
Wenn du also Module im Einsatz hast, die was voraussetzen, das man separat über das OS (apt) nachinstallieren muss, oder nur per cpan bekommt, muss du dir das halt aufschreiben und/oder dann halt auf dem passenden Weg nachinstallieren. Gerade, wenn du ein "gebranntes Kind" bist, stellt sich mir die Frage, warum dazu keine Notizen vorhanden sind... (Otto123 hat ein paar Scripte im Angebot, mit denen man das ggf. vereinfacht nachholen könnte).
Und dann gäbe es da noch den "installer", mit dem man eine Konfiguration auf solche Abhängigkeiten untersuchen könnte und das im Vorhinein fixen.
Und dann gibt es eben sehr viele Module, die du ggf. von irgendwoher nachinstalliert haben könntest. Für deren Probleme dann die Community hier "verantwortlich" machen zu wollen, ist nicht eben fair...
Für die Schnittstelle zu cpan selbst gibt es dann auch wieder eine Vielzahl von Möglichkeiten, welche sollte man also nehmen (oder besser: "verordnen"?!?)...?
Da hier aber keiner weiß, welche KONKRETEN Probleme du hattest, kann auch keiner effektiv helfen, sorry.
Und ja, den Frust kann ich nachvollziehen, dass man sich da um plötzlich um Dinge kümmern muss, mit denen man nicht gerechnet hatte. Ich kenne andere Smarthome-Systeme nicht, aber erfahrungsgemäß ist es "überall" so, dass man irgendwann einen gewissen Aufwand damit hat, alles auf der Höhe der Zeit zu halten und sich gewisse Brüche nie vermeiden lassen. Dass ein System so langlebig ist wie FHEM, kommt mir eher wie die große Ausnahme vor.
Da kann ich nur zustimmen.
Ziehe schon seit Jahren/Jahrzehnten mit fhem von OS zu OS immer komplett neu.
Mit einem entsprechenden Backup-/Restore Konzept ist/war das noch nie ein Ding.
Wichtig ist halt zu notieren, welche Zusatzschritte für bestimmte Module (nicht nur fhem auch HW) notwendig sind...
Das bei der Erstinstallation alles zu tun, sich das nicht merken/notieren und sich dann beim Neuaufsetzen wundern/beschweren, dass diese MANUELLEN, von DIR SELBST, gemachten Schritte dann nicht "einfach so" passieren, tja...
Aber nun läuft es ja wieder?
Schritte DIESMAL wenigstens notiert!? ;)
Gruß, Joachim
P.S.: wenn bei anderen Systemen steht, dass du was aus git holen und dies und das einfügen musst, bin ich ziemlich sicher, dass das bei einer Neuinstallation (ohne sich das notiert zu haben) auch "auf die Füße fällt"...
Der Vorteil von anderen Systemen: Es giebt ein "install-Script". Der Nachteil von anderen Systemen: es giebt ein Install-Script ....
Ein Install-Sciprt macht es einfacher es erstmal laufen zu kriegen, ABER man weiß nie, was der Ersteller so an Hacks eingebaut hat. Wenn man dann nicht das System des Entwicklers verwendet (oder seine Ideen möchte), hat man ein viel Größeres Problem als bei FHEM. Und ja, 500 Geräte wird Dir bei jedem System ein Problem beim Update erzeugen.
Kurzgefasst:
Wie oben schon von anderen Gefragt: Wo war Dein Problem? (Abgesehen davon, das Du Module mit CPAN Abhängigkeiten verwendest)
Und nur mal am Rande:
Du hast 2 Möglichkeiten ein solches System aufzubauen:
1. Ein Hersteller suchen: Du bist an den Hersteller gebunden, Cloudzwang und Teuer, dafür (mit Glück und eventuell ) Support
2. Selber machen (FHEM, OpenHub etc.): Unabhängiger, Lokaler, Kein Offizieller Support und Einarbeitungszwang
Kurzgefasst: Bei 2 bezahlt Du mit Deiner Zeit, bei 1. mit Deinem Geld.
Zitat von: MadMax-FHEM am 02 Oktober 2022, 09:32:22
Aber nun läuft es ja wieder?
Schritte DIESMAL wenigstens notiert!? ;)
Ja, das alte System mit Buster ;-)
Stimme Euch beide auch zu, war auch kein Vorwurf gegen FHEM. Bin völlig zufrieden damit.
Wollte nur eben anmerken, das ein FHEM-Backup/Restore auf ein neues BullsEye OS nicht so ohne weiteres gelingt.
Notizen! :D , Tja wann ich das noch alles wüsste, was innerhalb von 7 Jahren alles zusätzlich auf die SD-Card gebrutzelt wurden?!
Ja, Otto hatte da mal etwas ... , finde es leider nicht.
Habe es gestern nach etlichen Stunden dann aufgegeben, das parallele System mit BullsEye zu laufen zu kriegen.
Was mich eben nur wundert ist, das das WebGUI :8083 nicht mal aufrufbar ist.
Welche Tools (installer etc.) sind das denn, um mal festzustellen welche Pakete/Abhängigkeiten für Bullseye nachinstalliert werden müssen?
Wäre ja nicht schlecht, so dann eben es doch lauffähig zu bekommen. (Irgendwann muss man es ja tun)
Wie gesagt, ist jetzt kein kleines FHEM, da ist schon jede Menge drin.
Noch der Nachtrag zu den Fehlern:
Aktuell noch der hier:
reload: Error:Modul 99_myUtils deactivated:
Can't locate Email/MIME.pm in @INC (you may need to install the Email::MIME module) (@INC contains: ./lib ./FHEM . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/arm-linux-gnueabihf/perl5/5.32 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl-base /usr/lib/arm-linux-gnueabihf/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at ./FHEM/99_myUtils.pm line 70, <$fh> line 16.
BEGIN failed--compilation aborted at ./FHEM/99_myUtils.pm line 70, <$fh> line 16.
Alle anderen haben ich bereinigt durch diverse Nachinstallationen. Ob nun wegen des o.g Fehlers das WebGUI nicht geht, weiß ich nicht.
ZitatOb nun wegen des o.g Fehlers das WebGUI nicht geht, weiß ich nicht.
Nicht wegen diesem Fehler.
DIe Ursache kann man aber mit Sicherheit im FHEM-Log sehen.
Irgendwo :)
Leider nix gefunden bisher. Ich setze mal in der fhem.cfg verbose auf 5 und reboote.
Schau dann nochmal genauer in das Fhem Log. Danke
ZitatLeider nix gefunden bisher. Ich setze mal in der fhem.cfg verbose auf 5 und reboote.
Ein Fehler beim Initialisiieren von FHEMWEB wird mit loglevel 2 oder kleiner protokolliert.
Laeuft FHEM ueberhaupt?
Ist beim define global gesetzt?
Ja klar läuft Fhem. Bevor ich das Backup komplett wiederhergestellt habe, war die Weboberfläche (nacktes FHEM) ja erreichbar.
Keine Ahnung wie ich die Ursache nun finden sollte.
Zitat von: topa_LE am 02 Oktober 2022, 13:25:36
Keine Ahnung wie ich die Ursache nun finden sollte.
Z.B. (nur eine Auswahl durch schnelle Suche):
https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche
https://wiki.fhem.de/wiki/Hilfe!_Mein_FHEM_funktioniert_nicht!
Also Backup einspielen und dann mal machen was in den Links steht oder einfach auf Linux-Ebene prüen, ob fhem startet/gestartet wurde (ps -ax oder service fhem status usw.) ob Port offen ist...
Wenn kein Zugriff per Web-Oberfläche, dann das Log auf Linux-Ebene anschauen (cat/tail/...).
Oder eben Dinge in den Links probieren, wie beispielsweise fhem im "Debug-Modus" starten usw.
Gruß, Joachim
@MadMax
Einiges schon gemacht, weiter ohne Erfolg.
root@Pi4-FHEM-Server-4:~# service fhem status
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2022-10-02 16:29:18 CEST; 20s ago
Process: 906 ExecStart=/usr/bin/perl fhem.pl fhem.cfg (code=exited, status=0/SUCCESS)
Main PID: 908 (perl)
Tasks: 1 (limit: 4915)
CPU: 6.635s
CGroup: /system.slice/fhem.service
└─908 /usr/bin/perl fhem.pl fhem.cfg
root@Pi4-FHEM-Server-4:~# ps ax | grep perl
1625 ? R 0:01 /usr/bin/perl fhem.pl fhem.cfg
1705 pts/0 S+ 0:00 grep perl
root@Pi4-FHEM-Server-4:~#
Das Log schon durchgeforstet, nix an Errors drin.
Starte nun mal FHEM im Debug Mode.
Eventuell fehlen hier eben weitere erforderliche Pakete.
Mit ... wie ich die Ursache lösen soll, meinte ich eigentlich , wie man zum Backup auf ein neues System feststellen könnte, welche Pakete fehlen eigentlich zum aktuelle Fhem-System ...
Das ich gestern schon geprüft habe, ob FHEM läuft ist selbstverständlich klar. ;)
Dein 2. Link hat keinen Inhalt.
Danke dir trotzdem.
Wenn FHEM erst seit 20 sek. läuft, ist was faul!
Vermutlich schlägt systemd zu, weil FHEM wegen irgendwas zu beschäftigt ist.
Setze verbose wieder auf einen sinnvollen Wert und (falls noch nicht geschehen) deaktiviere initialUsbCheck. Wenn es letzteres nicht ist, stoppe den service und starte FHEM manuell, sonst haben wir wenig Chancen festzustellen, was die Denkpause verursacht (es müßte im Log zu sehen sein, was beim Starten ggf. so lange dauert)...
Habe es gelöst. Im Debug Mode auf der Konsole steigt FHEM aus, da der Port 8088 belegt war.
WEB_Api: Can't open server port at 8088: Address already in use. Exiting.
influxDB war installiert , habe es wieder entfernt. Meine InfluxDB läuft eh in einer Proxmox Umgebung. Daher brauche ich das nicht noch auf dem FHEM-System. Wusste auch nicht mehr ganz genau, ob ich es auf dem Buster System drauf hatte.
Also alles gut, und Danke für eure Unterstützung. :)
Werde nun alles noch kontrollieren und auf das neue System (Bullseye) live umsteigen.
Noch ein Tipp dazu:
sudo netstat -lntp
Zeigt Dir, welche Port aktuell belegt sind und durch welche Programme ...
Ja, danke. Hat mir auch geholfen.
Komisch nur, das nun das Razberry V2 Modul für meine Zwave Defines nicht mehr erkannt wird. Hat sich da bei Bullseye scheinbar was geändert.
Muss mal sehen wie ich das ans Laufen kriege.
Mit der Definition:
/dev/serial0@115200
geht es nicht mehr.
Ändere ich auf: /dev/ttyAMA0@115200 wird das Modul initialisiert, kann aber dann meine Geräte nicht mehr schalten.
Wenn ich die nun wieder alle neu anlernen muss, steht mir Arbeit bevor.
Hast du die Vorbereitungen für die Nutzung eines Aufsteckmoduls durchgeführt?
Gruß, Joachim
Zitat von: MadMax-FHEM am 02 Oktober 2022, 20:42:58
Hast du die Vorbereitungen für die Nutzung eines Aufsteckmoduls durchgeführt?
Was meinst Du denn damit? Das Modul steckt doch schon Jahre darin im Pi3. Habe doch nur das neue System mit SD Card getauscht.
Muss denn bei einen komplett neuen OS trotz FHEM Restore irgendwas neu gemacht werden?
Du musst und musstest das zuvor auch schon auf OS Seite gewisse Dinge bzgl. serieller Schnittstelle einstellen.
Neue OS Installation -> Einstellungen wieder vornehmen...
EDIT: ist z.B. hier beschrieben
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
https://wiki.fhem.de/wiki/Raspberry_Pi
Gruß, Joachim
Zitat von: MadMax-FHEM am 02 Oktober 2022, 20:49:15
Du musst und musstest das zuvor auch schon auf OS Seite gewisse Dinge bzgl. serieller Schnittstelle einstellen.
Ok, danke. Das wusste ich nicht.
dmesg:
1.814472] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 114, base_baud = 0) is a PL011 rev2Wie müsste denn die Anpassung bei Bullseye aussehen?
Was soll mir die Ausgabe von dmesg mitteilen?
Welche Anpassungen zu machen sind steht doch in den verlinkten Wikis...
Einfach danach vorgehen und gut...
Gruß, Joachim
ok, danke für die Links oben (die waren eben noch nicht da).
Schau ich mir an.
Nachdem du schon diesen Thread hier "gekapert" hast, zu dem hier:
Zitat von: topa_LE am 04 Oktober 2022, 10:43:09
Hallo,
möchte gern den Thread nochmal hochholen, da ich seit geraumer Zeit ähnliches Problem haben.
(Auch mit frischem OS Bullseye und FHEM Restore)
FHEM wird nicht beendet und blockiert mächtig und der PID beendet sich und ist nicht mehr mit htop zu sehen.
WebGUI nicht mehr erreichbar, Logs und Event werden nicht mehr geloggt.
Irgendwann geht es dann wieder (so ca. nach 2-3 Min.)
freezMon hat was geloggt. An der Stelle steigt der FHEM Prozess vermutlich aus.
2022.10.03 16:48:07 1: [Freezemon] Monitor_Freezemon: possible freeze starting at 16:41:06, delay is 421.065 possibly caused by: tmr-CODE(0x76dc920)(Get3DStatus)
Wenn ich nun global verbose auf 5 setzte, könnte man feststellen, was der Verursacher sein kann?
Wenn der Prozess aussteigt (aber nicht FHEM selbst), loggt er dann trotzdem, damit ich durch verbose5 mehr sehen kann?
Danke.
Mach bitte einen neuen Thread dazu auf, und lass den alten in Frieden (dort wieder löschen?). Da ging es um 20 Minuten-Intervalle, du scheinst ziemlich sicher einen anderen Verursacher zu haben, jedenfalls deutlich andere Intervalle. Du darfst in dem neuen Thread gerne auf die Threads verlinken, die du dazu schon gelesen hast, und auch gerne mal nach dem Freeze-Verursacher hier im Forum suchen (Get3DStatus); da kommen nämlich ein paar Treffer ;) .