fhem auf Raspi 4 100% cpu load

Begonnen von Hackstall, 04 Januar 2026, 20:27:15

Vorheriges Thema - Nächstes Thema

Hackstall

Hi mein fhem ist sehr langsam geworden.
Immer wieder alle 20 braucht mein fhem ca 100% für 10sec.

Ich habe schon viel gelesen aber alles hat nicht geholfen.

Ich betreiber fhem in einem DockerContainer und auch den MQTT Server in einem anderen Container.
Beides läuft auf einem RASPI4.

Irgendwie mache ich mir Sorgen für Erweiterungen.

Ich habe diese Verhalten seit ungefähr 6 Monaten und war anfänglich der Meinung dass es nach einem
Update kam.

Gibt es etwas dass ich überprüfen kann?
Wie geht man hier am besten vor?

Einen Umzug auf einen NUC würde dann doch etwas Arbeit bedürfen wobei ich natürlich zunächst herausfinden möchte woran es liegt?

Danke für Eure Hilfe

P.S.: Auch der Start dauert sehr lange. Am Memory liegt es nicht. Genug vorhanden und kein Swapping
P.P.S: Ich habe dann doch einige Fhem2Fhem Devices auf einem anderen Rechner der viele Devices aus meinem langsamen Raspi spiegelt. Ist das ev. ein Problem?

rabehd

Auch funktionierende Lösungen kann man hinterfragen.

tomcat.x

Wenn Du schreibst, dass fhem 100% (CPU?) braucht, hast Du schon geschaut, dass es wirklich der fhem Prozess ist. Sonst hätte ich gesagt, dass man erst mal mit "top" schauen könnte, ob es fhem, der MQTT-Server oder was anderes ist.

Dann wäre natürlich die Frage von rabehd interessant: Alle 20 Sekunden (?) für 10 Sekunden? Dann läuft ja fast nichts mehr. Sieht man zu der Zeit im Log, was da aktiv ist/war? Ansonsten könnte es entweder ein bestimmtes Modul sein oder irgendwas löst zu einem Zeitpunkt viele Events aus, auf die vielleicht auch noch was anderes reagiert. So was hatte ich mir schon mit einer User-Function "gebaut" ;-) Da nutze ich gerne die DOIF-Tools (auch ohne DOIF). Da gibt es eine Funktion, Events statistisch auszuwerten. Da sieht man schön, ob da was außerordentlich viel auslöst. Geht natürlich auch ohne die DOIF-Tools, aber ich finde das praktisch und kann man ja hinterher wieder raus schmeißen.

Falls es von einem einzelnen Modul kommt und man nichts konkretes findet, könnte man die nur nacheinander deaktivieren und dann schauen. Ideal wäre natürlich, wenn man einen Verdacht hat ...

Viele Grüße
Thomas
FHEM: 6.3 auf Raspi 4B, Raspbian (noch Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 8.10), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

KölnSolar

Ich werfe mal das freezemon-Modul zur Analyse in den Ring......
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Hackstall

Danke für die Antworten und ja so ziemlich alle 10sec und ja est ist der Perl FHEM.pl Prozess gemäß htop.

Events im Event Monitor angezeigt halten sich in Grenzen. Im Lig ist auch nichts auffälliges.
Muss ich hierfür logging aufdrehen?

Werde mal schauen was freezeMon ist.

Danke für jeden weiteren Tip.


MadMax-FHEM

Ich denke Events schauen (Eventmonitor) bzw. DOIF-Tools ist ein guter Weg.
Komisch, wenn nicht viel los ist bzgl. Events.

Weil hohe Last wäre entweder viele Events, die es "gleichzeitig" zu verarbeiten gibt...
...oder aber ein Event bzw. Eventverarbeitung (kann bzw. kommt verm. "von dir", z.B. myUtils oder innerhalb notify/DOIF etc.) die eine "Schleife" dreht, also ganz viel(, ganz schnell) abarbeiten muss...
Evtl. mal schauen, ob nach/bei einem bestimmten Event die Last hochgeht...

Also Eventmonitor und htop parallel kucken...

Daher denke ich wird Freezemon u.U. wenig helfen.
Da hier eher ermittelt wird, wenn fhem wegen "warten auf was (externes)" nicht weiterarbeitet...
...und da ist der fhem Prozess eher "idle" als 100% ausgelastet...
Oder bin ich falsch?

Aber für Blockaden in fhem ist freezemon spitzenklasse! :)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Hackstall

Danke,

Mal ne dumme Frage gibt es da nicht in FHEM einen Eventcounter der pro Zeit zählt und ggfs. auch für Hochphasen einen Timestamp gibt. Oder sogar bei Max Anzahl die Events loggt. Wäre doch eine coole erwErweitetung des Eventmonitors oder eines Moduls

MadMax-FHEM

DOIF-Tools wurde doch (mehrfach) genannt...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Sailor

Ein herzerfrischendes Moiun vom achtern Diek tosammen!

Ich hatte mal einen ähnlichen Fall. Gesucht aber nirgends einen Grund gefunden, warum fhem.pl die htop Liste ständig mit 100% angeführt hat.

Habe dann mal einen Backup der fhem.cfg gemacht und eine jungfräuliche genommen.
Erwartungsgemäß wieder bei 0% gelandet.
Dann nach und nach einzelne Sektionen vom Backup rüber gezogen bis die Auslastung wieder auf 100% geschnellt und somit der Schuldige identifiziert war.

Gruß
    Sailor
******************************
Man wird immer besser...

Hackstall

Hall MadMax,

Ja das mit DOIF habe ich wahrgenommen aber nicht die leiseste Ahnung wie ich hier vorgehen müsste. Hättet ihr hier ein paar schnipsel oder Denkanstöße um Events zu zählen und zeitlich zu loggen bei Maximum.
Danke.

Gruß Andreas

MadMax-FHEM

#10
Suche schon mal bemüht, in dem Fall die "Internet-Suche" aka googeln?

https://wiki.fhem.de/wiki/DOIFtools

Wie genau sich das gestaltet, also ob man dann Readings im Device hat auf die man dann reagieren kann (Alarme etc.) oder "nur" eine Auswertung per Logdatei weiß ich nicht mehr.
Ist schon ne Weile her, dass ich das verwendet habe...

EDIT: scheint auch zu gehen
Zitat von: commandrefReadings

    DOIFtools erzeugt bei der Aktualisierung von Readings keine Events, daher muss die Seite im Browser aktualisiert werden, um aktuelle Werte zu sehen.

    Action zeigt den Status der Event-Aufzeichnung an.
    DOIF_version zeigt die Version des DOIF an.
    FHEM_revision zeigt die Revision von FHEM an.
    doStatistics zeigt den Status der Statistikerzeugung an
    logfile gibt den Pfad und den Dateinamen mit Ersetzungszeichen an.
    recording_target_duration gibt an wie lange Daten erfasst werden sollen.
    stat_<devicename> zeigt die Anzahl der gezählten Ereignisse, die das jeweilige Gerät erzeugt hat.
    statisticHours zeigt die kumulierte Zeit für den Status enabled an, während der, Statistikdaten erfasst werden.
    statisticShowRate_ge zeigt die Event-Rate, ab der Geräte in die Auswertung einbezogen werden.
    statisticsDeviceFilterRegex zeigt den aktuellen Gerätefilterausdruck an.
    statisticsTYPEs zeigt eine Liste von TYPE an, für deren Geräte die Statistik erzeugt wird.
    targetDOIF zeigt das Ziel-DOIF, bei dem Readings gelöscht werden sollen.
    targetDevice zeigt das Ziel-Gerät, bei dem Readings gelöscht werden sollen.

Aber: was spricht gegen ausprobieren?

EDIT: oder auch einfach help doiftools
Zitat von: help doiftoolsModule: 98_DOIFtools.pm Maintainer: Ellert Forum: Automatisierung/DOIF (see MAINTAINER.txt for more info)
DOIFtools

    DOIFtools contains tools to support DOIF.

        create readingsGroup definitions for labeling frontend widgets.
        create a debug logfile for some DOIF and quoted devices with optional device listing each state or wait timer update.
        optional device listing in debug logfile each state or wait timer update.
        navigation between device listings in logfile if opened via DOIFtools.
        create userReadings in DOIF devices displaying real dates for weekday restricted timer.
        delete user defined readings in DOIF devices with multiple choice.
        delete visible readings in other devices with multiple choice, but not state.
        record statistics data about events.
        limitting recordig duration.
        generate a statistics report.
        lists every DOIF definition in probably associated with.
        access to DOIFtools from any DOIF device via probably associated with
        access from DOIFtools to existing DOIFtoolsLog logfiles
        show event monitor in device detail view and optionally in DOIFs detail view
        convert events to DOIF operands, a selected operand is copied to clipboard and the DEF editor will open
        check definitions and offer recommendations for DOIF MODEL FHEM
        create shortcuts
        optionally create a menu entry
        show a list of running wait timer
        scale values to color numbers and RGB values for coloration
        list subs declared by user in package DOIF

    Just one definition per FHEM-installation is allowed. More in the german section.

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Reinhart

ich hatte monatelang das selbe Problem, "perl" und "node" waren ständig auf 100% und alles war sehr zäh zu bedienen. Habe von Raspi4 auf Raspi5 mit SSD gewechselt und alles ist bei gleicher Konfiguration jetzt ok und sehr schnell. Jetzt sind die gleichen Prozesse auf maximal 10%.
Ich habe natürlich ein Konfiguration mit etwa 70 Funkdevices, Alexa sehr viel notify und DOIF im Einsatz, eben suksesivive über die Jahre gewachsen.
FHEM auf Raspy5 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa