RasPi 5 zu schwach ? Benötige ich eine andere Hardware?

Begonnen von Guzzi-Charlie, 13 April 2025, 11:53:08

Vorheriges Thema - Nächstes Thema

Guzzi-Charlie

Hallo,

nachdem meine FHEM-Installation über die Jahre immer weiter gewachsen ist und ich deswegen auch schon mehrfach die HW (RasPi) aufgerüstet habe (vom ursprünglichen RasPi 3 auf momentan RasPi 5, 4GB) glaube ich das ich so langsam am Ende der Möglichkeiten des RasPi's angekommen bin. Speziell jetzt mit Beginn der "Sonnensaison" wo nun wieder alle meine PV-WR richtig produzieren (außer Leistung auch seeehr viele Events) steigt die CPU-Last (FHEM-Anteil) pünktlich Morgens mit Sonnenaufgang bis Abends zum Sonnenuntergang von ca. 50% auf nahezu 100%. Dabei habe ich schon versucht die Datenbelastung (Events) an mehreren Stellen einzuschränken (MQTT-Daten nur alle 2 Minuten, Event nur bei Änderung um > 15W, nur die nötigsten Daten loggen, etc.). Trotzdem komme ich kaum unter 90%.

Das führt dann manchmal dazu das Daten die zwischen dem FHEM-RasPi und dem Loxone Miniserver über UDP/HTTP ausgetauscht werden verloren gehen. Das darf natürlich nicht sein.

Ich bräuchte deshalb mal Eure Einschätzung ob ich noch was optimieren könnte, etwas grundsätzliches falsch mache, wo ich vielleicht noch nachschauen könnte oder ob der RasPi für meine große FHEM-Installation (denke zumindest das meine FHEM-Installation groß ist) tatsächlich nicht mehr ausreichend ist.

So nun zu meinem System:
HW: RasPi 5, 4GB
OS: Bookworm
SW: FHEM, pivccu3 (für homematic-Geräte)

FHEM-Devices:
  25x at
  57x di
110x dy
  10x EC3000
  17x FBDECT
396x FileLog
  17x fhempy
  28x homematic
    8x http
  14x Modbus
    7x Modbusattr
181x MQTT2-Device
131x MQTT2-Server
  98x notify
    3x OBIS
  82x readingsgroup
    1x Statistics-Device
203x SVG-Plot
    2x watchdog

Signalaustausch mit Loxone:
175x HTTP, Loxone ==> FHEM
260x UDP, FHEM ==> Loxone

Laut FHEM Event-Monitor gibt es Nachts ca. 20 Events/s und tagsüber bis zu 50 Events/s, wobei ich hier nicht wirklich weiß ob überhaupt alle Events durchkommen und im Eventmonitor angezeigt werden.



So, nun bin ich mal auf Eure Kommentare gespannt.
- RasPi 5: Cuno-V2 -2x KS300,JeeLink -13x EC3000
- Stromzähler: 6x SDM120M,9x XTM100A,38x DRS110M,3x eHz
- LAN: IT-GW 34x RMF-R1(Roll-Mot.),- 1x Loxone MSgo
- WLAN: 89x Shelly,12x Gosund SP111,16x D1-Mini,15x Sonoff Basic,85x 1wire T-Sens.
- DECT: 6x DECT200,11x DECT301,-HmIP: 3x FalmotC12,16x WTH2

Beta-User

Ohne in die Details zu gehen wird das schwierig.

Auf den ersten Blick sieht das aber "offenkundig inneffizent" aus:
Die Zahl der FileLog ist astronomisch (DbLog?), und warum man über 100 MQTT2_SERVER benötigen sollte, erschließt sich mir nicht...
Da gibt es bestimmt noch viel mehr Ineffizienz, wenn man unter der Haube nachschaut :D .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

RappaSan

Ich kann mir gerade nix unter
57x di
110x dy
vorstellen. Was ist das?

Guzzi-Charlie

- RasPi 5: Cuno-V2 -2x KS300,JeeLink -13x EC3000
- Stromzähler: 6x SDM120M,9x XTM100A,38x DRS110M,3x eHz
- LAN: IT-GW 34x RMF-R1(Roll-Mot.),- 1x Loxone MSgo
- WLAN: 89x Shelly,12x Gosund SP111,16x D1-Mini,15x Sonoff Basic,85x 1wire T-Sens.
- DECT: 6x DECT200,11x DECT301,-HmIP: 3x FalmotC12,16x WTH2

Guzzi-Charlie

@beta-user
Wieso ist die Anzahl der Filelogs astronomisch? Es gibt ja auch entsprechend viele Devices. Mit DbLog hab ich mich noch nie beschäftig. Davon habe ich keine Ahnung. Die MQTT2-Server werden doch von FHEM für jedes MQTT-Gerät automatisch angelegt. Verstehe ich da grundsätzlich was falsch?

Das mit den Ineffizienzen mag ja sein, ist sogar wahrscheinlich, aber die Hauptfrage ist ja ob ein RasPi 5 das von mir betriebene System bewältigen können sollte, oder bei dem angegebenen Umfang die Grenzen naheliegen oder nicht. Ich will auch gerne jede Info posten die notwendig ist um eine Antwort auf meine Frage zu erhalten.
- RasPi 5: Cuno-V2 -2x KS300,JeeLink -13x EC3000
- Stromzähler: 6x SDM120M,9x XTM100A,38x DRS110M,3x eHz
- LAN: IT-GW 34x RMF-R1(Roll-Mot.),- 1x Loxone MSgo
- WLAN: 89x Shelly,12x Gosund SP111,16x D1-Mini,15x Sonoff Basic,85x 1wire T-Sens.
- DECT: 6x DECT200,11x DECT301,-HmIP: 3x FalmotC12,16x WTH2

Beta-User

OK, an temporäre MQTT2-Server-Instanzen hatte ich nicht gedacht.

Sowas besser (leider nicht perfekt) per "fheminfo" abrufen, dann steht da auch direkt "dummy".

Da der Pi nicht zu swappen scheint, ist es zumindest kein RAM-Problem.

FileLog: für jede Event-loop muss halt (wenn was zu loggen ist) das File geöffnet werden, DbLog puffert das erst mal. Dass FHEM erst mal den "einfachen" Mechanismus einrichtet, heißt ja nicht, dass das ein Muss ist.
Wie groß sind denn deine logfiles?

Letztendlich würde ich auch den Eventmonitor mal zu Rate ziehen und schauen, was und wie Event(-loop)s generiert, und wie man das ggf. reduzieren kann.
Fleißarbeit...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Guzzi-Charlie

Wenn sich mit DbLog signifikant was in der Performance verbessern läßt, dann schaue ich mir das gerne mal an. Vielleicht ist die Umstellung ja auch ganz einfach??

Meine Logfiles sind alle als Monats-Logfiles angelegt und sind zwischen 50k und 200MB groß. Für 03-2025 sind das 302 Dateien mit zusammen ca. 2,8GB an Daten.

Optimierungs-Fleißrunden habe ich schon mehrfach gedreht, aber den richtigen Befreiungsschlag bisher noch nicht erreicht. Und eigentlich würde ich, zumindest was die ganzen Stromflüsse betrifft, lieber noch feiner aufgelöste Daten haben (also mindestens Minutenwerte).
- RasPi 5: Cuno-V2 -2x KS300,JeeLink -13x EC3000
- Stromzähler: 6x SDM120M,9x XTM100A,38x DRS110M,3x eHz
- LAN: IT-GW 34x RMF-R1(Roll-Mot.),- 1x Loxone MSgo
- WLAN: 89x Shelly,12x Gosund SP111,16x D1-Mini,15x Sonoff Basic,85x 1wire T-Sens.
- DECT: 6x DECT200,11x DECT301,-HmIP: 3x FalmotC12,16x WTH2

Beta-User

Zitat von: Guzzi-Charlie am 13 April 2025, 13:30:27Vielleicht ist die Umstellung ja auch ganz einfach??
Na ja, du würdest in dem Fall nicht drumrum kommen, dich in die allgemeine Datenbankthematik einzulesen und einzudenken.

Zitat von: Guzzi-Charlie am 13 April 2025, 13:30:27200MB
Das kommt mir schon "ordentlich" vor. Vielleicht mal einen Blick reinwerfen, was da alles geloggt wird?

Zitat von: Guzzi-Charlie am 13 April 2025, 13:30:27Optimierungs-Fleißrunden habe ich schon mehrfach gedreht, aber den richtigen Befreiungsschlag bisher noch nicht erreicht. Und eigentlich würde ich, zumindest was die ganzen Stromflüsse betrifft, lieber noch feiner aufgelöste Daten haben (also mindestens Minutenwerte).
Bei der "Auflösung" geht es ums Loggen? DbLog kennt Filter, die dann zumindest nicht alle Events ins Log schreiben.

Ansonsten: Die Optimierung betrifft nicht nur "event-on-change-reading" &Co. passend zu setzen ;) .

Da geht es auch darum, Eventhandler sauber abzugrenzen (z.B. NOTIFYDEV bei deinen notify gesetzt?), und dann den anschließenden Code auch effektiv zu halten. Z.B. myUtils statt "on-the-fly"-Umwandlung von Code in DEF, schnelle Profung von "ist es überhaupt relevant?" usw. usf..
Es gibt hier so viele schlechte Beispiele zu finden, in denen erst alles mögliche an Variablen zugewiesen wird, berechnet und transformiert, nur um am Ende noch eine Prüfung einzubauen, die alles vorher ad absurdum führt, und die man auch direkt vorne hätte machen können. Sowas muss nicht sein und erzeugt nur unnötig Hitze im Prozessor ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

rabehd

Zitat von: Guzzi-Charlie am 13 April 2025, 12:40:19Wieso ist die Anzahl der Filelogs astronomisch? Es gibt ja auch entsprechend viele Devices.
Ich habe gerade mal 12, selbst davon sind nur 4-5 relevant um schnell nachzuschauen und nicht eine Abfrage für die Datenbank machen zu müssen.
Man kann einstellen, ob dasAnlegen eines Logfiles Standard ist oder nicht, alternativ weglöschen, wenn das Device fertig eingerichtet und "abgenommen" ist.
Für Diagramme z.B. nutze ich die Datenbank und da kommt nur das rein was ich will.
Genauso bei Events, weniger ist immer mehr.
Auch funktionierende Lösungen kann man hinterfragen.

Guzzi-Charlie

Zitat von: Beta-User am 13 April 2025, 16:34:33
Zitat von: Guzzi-Charlie am 13 April 2025, 13:30:27200MB
Das kommt mir schon "ordentlich" vor. Vielleicht mal einen Blick reinwerfen, was da alles geloggt wird?
Naja, das sind nur zwei und eine davon habe ich gerade weiter zusammengestutzt. Die Andere ist der Logfile einer PV-Anlage mit 7 Micro-Wechselrichtern und jeweils zwei MPP-Trackern. Die Daten hätte ich zum Regeln am liebsten noch genauer (alle 20s statt alle 2 Minuten). Die meisten liegen unter 10MB.
ZitatBei der "Auflösung" geht es ums Loggen?
Ja und event-on-change-reading, etc. (inkl. Triggerschwelle) nutze ich natürlich schon und schreibe auch nur das was ich wirklich haben möchte. Aber irgendwie scheint es für den RasPi zuviel zu sein.
ZitatDa geht es auch darum, Eventhandler sauber abzugrenzen (z.B. NOTIFYDEV bei deinen notify gesetzt?)
Bei den meisten schon, aber da kann ich ja nochmal hinschauen. Aber ich glaube nicht das es am nicht perfekten Code liegt da der Pi Nachts nur mit ca. 40-50% läuft und erst am Tag mit Erscheinen der Eventflut aus den ganzen PV-Wechselrichtern an den Anschlag läuft. Ich hab auch keine Ahnung wieviele Events ein RasPi 5 unter FHEM überhaupt verarbeiten kann. Gibt es da irgendwelche Anhaltspunkte? Es bringt ja nichts wenn ich tage- oder wochenlang versuche alles Mögliche zu optimieren (was mit auch relativ schwerfallen dürfte) um am Ende festzustellen das die HW einfach für meine Installation nicht ausreicht. Dann würde ich eher auf eine leistungsfähigere HW umziehen, obwohl es mir davor grausen würde. Dann bekomme ich sicherlich wieder viele andere Probleme.

@rabehd
Wenn Du nur 12 Logfiles hast, dann kann Deine Installation ja nicht besonders groß sein. Bei mir gibt es mehrere Hundert Aktoren/Sensoren. Hauptsächlich geht es dabei um Energieflüsse von PV, Hausverbrauch, E-Autos, Heizung, etc. und Temperaturmessungen für zwei Häuser. Für sehr viele dieser Messungen gibt es auch SVG-Plots und wenn ich mal einen neuen SVG-Plot (auch für die Vergangenheit) benötige, dann geht das eben nur wenn auch Daten vorhanden sind. Wenn die Verwendung von DbLog die Performance steigert, bzw. die Last auf dem Raspi reduzieren hilft, dann werde ich das auf jeden Fall mal ausprobieren. Bisher hatte sich mir die Frage aber nicht gestellt. Prinzipiell ist es mir doch egal wie die Daten gespeichert werden, solange es funktioniert und außerhalb von FHEM brauchte ich die Daten bisher noch nicht. Und die Umstellung ist ja auch ein nicht ganz unerheblicher Aufwand. Deshalb habe ich das bisher immer gescheut.
- RasPi 5: Cuno-V2 -2x KS300,JeeLink -13x EC3000
- Stromzähler: 6x SDM120M,9x XTM100A,38x DRS110M,3x eHz
- LAN: IT-GW 34x RMF-R1(Roll-Mot.),- 1x Loxone MSgo
- WLAN: 89x Shelly,12x Gosund SP111,16x D1-Mini,15x Sonoff Basic,85x 1wire T-Sens.
- DECT: 6x DECT200,11x DECT301,-HmIP: 3x FalmotC12,16x WTH2

Beta-User

Falls das Hoymiles-WR sind: umstellen auf Ahoy-JSON. Details bei Bedarf.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Guzzi-Charlie

ZitatFalls das Hoymiles-WR sind: umstellen auf Ahoy-JSON. Details bei Bedarf.
Ja, das sind Hoymiles-WR und die werden mit einer Ahoy-DTU (ESP32) abgefragt. Aber die Daten werden ja nicht weniger wenn ich eine andere Schnittstelle verwende? Das sind immerhin Daten von 24 PV-Modulen.
- RasPi 5: Cuno-V2 -2x KS300,JeeLink -13x EC3000
- Stromzähler: 6x SDM120M,9x XTM100A,38x DRS110M,3x eHz
- LAN: IT-GW 34x RMF-R1(Roll-Mot.),- 1x Loxone MSgo
- WLAN: 89x Shelly,12x Gosund SP111,16x D1-Mini,15x Sonoff Basic,85x 1wire T-Sens.
- DECT: 6x DECT200,11x DECT301,-HmIP: 3x FalmotC12,16x WTH2

schwatter

#12
Ich habe 6 Hoymiles und benutze OpenDTU-OnBattery. Mein Load war mit mit MQTT2-SERVER und MQTT2-DEVICE auch zu hoch.
Habe umgestellt auf pollen mit JsonMod (http://192.168.178.35/api/livedata/status/). Sind zwar viel weniger Infos drinne,
aber die wichtigsten Leistungsdaten und etwas mehr. Per MQTT wird wirklich jeder schei* versendet, ohne das man das irgendwie
einschränken kann...

edit:
Ich sehe gerade du hast geantwortet. Ich verzichte mittlerweile auf die ganzen Infos der Module. Wenn gucke ich bei der DTU rein. Unter Fhem habe ich
meine Module auch nie kontrolliert. Setzt dir einen Weblink zur DTU.


Gruß schwatter

Beta-User

Zitat von: Guzzi-Charlie am 13 April 2025, 18:58:25
ZitatFalls das Hoymiles-WR sind: umstellen auf Ahoy-JSON. Details bei Bedarf.
Ja, das sind Hoymiles-WR und die werden mit einer Ahoy-DTU (ESP32) abgefragt. Aber die Daten werden ja nicht weniger wenn ich eine andere Schnittstelle verwende? Das sind immerhin Daten von 24 PV-Modulen.
Weniger Daten nicht, aber deutlich weniger Event-loops ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

rabehd

Zitat von: Guzzi-Charlie am 13 April 2025, 18:33:49Wenn Du nur 12 Logfiles hast, dann kann Deine Installation ja nicht besonders groß sein.
Dein Denkfehler
Auch funktionierende Lösungen kann man hinterfragen.