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

ZitatWeniger Daten nicht, aber deutlich weniger Event-loops
Das verstehe ich leider nicht. Magst Du mir das erklären?
- 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, 19:40:02
ZitatWeniger Daten nicht, aber deutlich weniger Event-loops
Das verstehe ich leider nicht. Magst Du mir das erklären?
Mehrere Events können zu einem "bulk" gehören und werden dann zusammen ausgewertet, was z.B. dann für diese Loop nur zu einem Öffnen von FileLog-Dateien führt.

Bei MQTT2_DEVICE entspricht jeder Topic (mind.) einem bulk.

JSON-Blobs werden dabei als ein bulk ausgewertet  ;) .

Zitat von: rabehd am 13 April 2025, 19:35:53
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

Habe nur 4, sagt count.

Aber meine kleine Installation läuft auch nicht auf einem Pi....
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

mumpitzstuff

Ich würde da jetzt nicht einfach so an einem funktionierenden System rum machen, ohne die Ursache zu kennen oder zumindest eingegrenzt zu haben. Schau doch mal nach apptime und versuch damit erst einmal zu ermitteln, was bei dir die Laufzeit wirklich frisst. Danach würde ich über Lösungen nachdenken.

Beta-User

Zitat von: mumpitzstuff am 13 April 2025, 22:40:41Ich würde da jetzt nicht einfach so an einem funktionierenden System rum machen, ohne die Ursache zu kennen oder zumindest eingegrenzt zu haben. Schau doch mal nach apptime und versuch damit erst einmal zu ermitteln, was bei dir die Laufzeit wirklich frisst. Danach würde ich über Lösungen nachdenken.
Die Ursache "Ahoy" würde ich auf alle Fälle bereinigen.

Meine Vermutung: die Load tagsüber geht dann nur noch auf um die 60% hoch und man kann dann tatsächlich sinnvolle Analysen über Tools wie z.B. apptime machen...

Da das im Prinzip alle Ahoy-User gleichermaßen betrifft, hier mein Beitrag im "passenden" Tread.
Zitat von: Beta-User am 14 April 2025, 09:06:25Moin zusammen,


nachdem hier jemand Probleme mit sehr viel Load hatte, hier mal zumindest meine (etwas bereinigte) aktuelle Fassung für einen der Inverter - Ahoy ist so eingestellt, dass JSON gesendet wird.

Bin mal gespannt, was das an load-Reduzierung in dem betreffenden Thread bringt ;) .

defmod Inverter_O_Mitte MQTT2_DEVICE inverter_O_Mitte
attr Inverter_O_Mitte alias Ost Mitte
attr Inverter_O_Mitte devStateIcon {FHEM::attrT_Ahoy_Utils::devStateIcon($name)}
attr Inverter_O_Mitte group Solar Inverter
attr Inverter_O_Mitte icon measure_photovoltaic_inst
attr Inverter_O_Mitte jsonMap 1_I_DC:I_DC1 1_P_DC:P_DC1 1_U_DC:U_DC1 1_Irradiation:Irradiation1 1_YieldDay:YieldDay1 1_YieldTotal:YieldTotal1 2_I_DC:I_DC2 2_P_DC:P_DC2 2_U_DC:U_DC2 2_Irradiation:Irradiation2 2_YieldDay:YieldDay2 2_YieldTotal:YieldTotal2 3_I_DC:I_DC3 3_P_DC:P_DC3 3_U_DC:U_DC3 3_Irradiation:Irradiation3 3_YieldDay:YieldDay3 3_YieldTotal:YieldTotal3 4_I_DC:I_DC4 4_P_DC:P_DC4 4_U_DC:U_DC4 4_Irradiation:Irradiation4 4_YieldDay:YieldDay4 4_YieldTotal:YieldTotal4 5_I_DC:I_DC5 5_P_DC:P_DC5 5_U_DC:U_DC5 5_Irradiation:Irradiation5 5_YieldDay:YieldDay5 5_YieldTotal:YieldTotal5 6_I_DC:I_DC6 6_P_DC:P_DC6 6_U_DC:U_DC6 6_Irradiation:Irradiation6 6_YieldDay:YieldDay6 6_YieldTotal:YieldTotal6 1_MaxPower:MaxPower1 2_MaxPower:MaxPower2 3_MaxPower:MaxPower3 4_MaxPower:MaxPower4 5_MaxPower:MaxPower5 6_MaxPower:MaxPower6 Temp:temperature
attr Inverter_O_Mitte model hoymiles_microinverter_inverter
attr Inverter_O_Mitte readingList inverter/O_Mitte/available:.* available\
  inverter/O_Mitte/last_success:.* last_success\
  inverter/O_Mitte/radio_stat:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  inverter/O_Mitte/dis_night_comm:.* dis_night_comm\
  inverter/O_Mitte/ack_pwr_limit:.* ack_pwr_limit\
  inverter/O_Mitte/firmware:.* { json2nameValue($EVENT) }\
  inverter/O_Mitte/hardware:.* { json2nameValue($EVENT) }\
  inverter/O_Mitte/ch0/active_PowerLimit:.* active_PowerLimit\
  inverter/O_Mitte/ch0/ALARM_MES_ID:.* ALARM_MES_ID\
  inverter/O_Mitte/ch0/LastAlarmCode:.* LastAlarmCode\
  inverter/O_Mitte/ch0/Efficiency:.* Efficiency\
  inverter/O_Mitte/ch0/YieldDay:.* YieldDay\
  inverter/O_Mitte/ch0/YieldTotal:.* YieldTotal\
  inverter/O_Mitte/alarm/cnt:.* alarmCnt\
  inverter/O_Mitte/alarm/[\d]+:.* { $TOPIC =~ m,alarm/([\d]+),;; { "alarm_${1}"=>$EVENT } }\
  inverter/O_Mitte/ch0/MaxTemp:.* MaxTemp\
  inverter/O_Mitte/ch1:.* { json2nameValue($EVENT,'1_',$JSONMAP) }\
  inverter/O_Mitte/ch2:.* { json2nameValue($EVENT,'2_',$JSONMAP) }\
  inverter/O_Mitte/ch3:.* { json2nameValue($EVENT,'3_',$JSONMAP) }\
  inverter/O_Mitte/ch4:.* { json2nameValue($EVENT,'4_',$JSONMAP) }\
  inverter/O_Mitte/ch0:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr Inverter_O_Mitte room Steuerung->Strom
attr Inverter_O_Mitte setList reboot:noArg inverter/ctrl/restart/2\
  limit inverter/ctrl/limit/2 $EVTPART1W\
  limit_pct:slider,2,1,100 inverter/ctrl/limit/2 $EVTPART1
attr Inverter_O_Mitte setStateList on off
attr Inverter_O_Mitte webCmd :
Durch das jsonMap bleiben dabei die bereits verwendeten Reading-Namen erhalten, man muss also "drumrum" nichts weiter anpassen.

Feedback ist willkommen, bei Gelegenheit wollte ich das auch mal in die attrTemplate einpflegen, bin aber auch überhaupt nicht traurig, wenn sich jemand anderes das mal anschaut und ggf. mit radio-Button die Option anbietet, die JSON-Variante statt der Klartext-Topics zu verwenden.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Guzzi-Charlie

Hallo,
  • mit dem Thema Ahoy-DTU muß ich mich erst noch tiefer beschäftigen. Ich denke im Prinzip habe ich die Idee dahinter verstanden, im Detail allerdings überhaupt noch nicht. Außerdem habe ich 7 Hoymiles-WR die über eine Ahoy-DTU angebunden sind.
  • mit dem Thema DbLog habe ich mich schon beschäftigt und mit etwas Suchen im Netz war es dann letztendlich gar nicht so schwierig die mySQL-Datenbank und DbLog einzurichten. Ich habe schon die ersten Devices und SVG's von FileLog auf DbLog umgestellt. Funktionieren tut das problemlos. Ich sehe auch durchaus den evtl. Performance-Gewinn durch Nutzung einer Datenbank anstatt einzelner FileLog-Dateien, aber ich stelle mir gerade schon die Frage "Was ist mit der Dateigröße der Datenbank?". Meine DbLog-Datenbank hat nach einem Tag schon eine Größe von fast 100MB bei nur 5 Devices. Alle meine ca. 5.000 FileLog-Dateien von einem Jahr zusammen haben ca. 50GB. Wie groß darf denn die Datenbank überhaupt werden? Geht das überhaupt mit einer Datenbank, oder müßte ich das dann auch wieder in mehrere Datenbanken aufteilen? Bisher habe ich die FileLogs pro Device und Monat strukturiert und dann so ca. 1x im Jahr die Files vom vorletzten Jahr auf mein NAS verschoben.
  • Zu meiner Hauptfrage ob der RasPi 5 für meine Systemgröße überhaupt ausreichend ist, bzw. bei wie vielen Events denn die Grenze liegt die ein RasPi 5 verkraftet gab es leider noch gar keine Antworten.
- 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

...ich habe mehr Ahoy-Kanäle wie du ;) ...
Genau aus dem Grund hatte ich damals den issue aufgemacht mit dem Anliegen, eine JSON-Option zu implementieren :P .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

JoWiemann

Hallo,

ZitatWie groß darf denn die Datenbank überhaupt werden?

Datenbanken wurden entwickelt um seeeehr große Datenmengen performant zu verwalten. Die Größe ist primär durch die Festplattenkapazität begrenzt. Die Performance durch die Rechnerleistung. Aber für Alles gibt es ein Endlich. Hierfür wurden dann spezielle Lösungen als Hardware/Datenbankkombination von den Herstellern entwickelt.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

GeZi3560

Zum Thema Datenbank Grösse.
Anpassen das nicht alles in die DB geschreiben wird.
Ich setze bei jedem Device zunächst das attr: DBLogExclude auf .*
Dann mit Attr: DBLogInclude alle Readings ich wir brauche.
So halten sich die Menge der Einträge in Grenzen.
Regelmässig mache ich dann Datenbank pflege und lösche nicht benötigte Readings.
Raspberry Pi 4 4GB, MariaDB,2 Cul V3 868 ,1 Cul V3, 433, Zwave-USB, Conbee2, DeConz, MAX WT und Ventile,HM, Somfy, Fibaro, Shellys, Tradfri, Lidl Zigbee

rabehd

Zitat von: GeZi3560 am 15 April 2025, 16:04:43Ich setze bei jedem Device zunächst das attr: DBLogExclude auf .*
Dann mit Attr: DBLogInclude alle Readings ich wir brauche.
Kannst Du Dir so sparen.
attr logdb DbLogSelectionMode Include damit sparst Du Dir DBLogExclude.

Auch funktionierende Lösungen kann man hinterfragen.

Beta-User

Zitat von: Guzzi-Charlie am 15 April 2025, 11:16:14Meine DbLog-Datenbank hat nach einem Tag schon eine Größe von fast 100MB bei nur 5 Devices. Alle meine ca. 5.000 FileLog-Dateien von einem Jahr zusammen haben ca. 50GB.
Der Hinweis auf DbLogValueFn kam wohl nicht an, und die Daten nachträglich auszudünnen geht mit Datenbankfunktionen (=>DbRep) auch "einfacher" als mit LogFiles.

Zitat von: Guzzi-Charlie am 15 April 2025, 11:16:14Zu meiner Hauptfrage ob der RasPi 5 für meine Systemgröße überhaupt ausreichend ist, bzw. bei wie vielen Events denn die Grenze liegt die ein RasPi 5 verkraftet gab es leider noch gar keine Antworten.
Zitat von: Beta-User am 13 April 2025, 12:04:17Da gibt es bestimmt noch viel mehr Ineffizienz, wenn man unter der Haube nachschaut :D .
Anders gesagt: Der Pi ist anscheinend im Moment bei 50% Dauerlast und reagiert _dann_ anscheinend auch noch hinreichend auf irgendwelche deiner Aktionen.

Jetzt reduzierst du die Last via DbLog (ggf. +ValueFn), dann landest du vermutlich bei deutlich verbesserten Werten.

Wenn die Inverter loslegen und auf JSON (+DbLog) umgestellt sind, hast du wieder eine erhöhte Last, klar, aber lass dich überraschen...

Mir wäre das vom Baugefühl her im Egebnis zu viel (da hängen wohl 2 Häuser dran, das klingt nach "relevant für viele Mitmenschen"...), aber der Pi packt das dann schon.

Und dann kannst du ja schauen, ob es tatsächlich die behaupteten ineffizenten Eventhandler (neben FileLog) gibt (Stichwort war apptime...).

Jedenfalls kann man das imo nicht einfach an irgendeiner absoluten Zahl von Events/Zeiteinheit festmachen, die Frage macht nur sehr bedingt Sinn.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files