Welcher Raspberry Pi ist für FHEM am sinnvollsten

Begonnen von Marlon, 13 September 2020, 16:51:26

Vorheriges Thema - Nächstes Thema

Adimarantis

Ich verwende einen Raspberry PI 1 mit 8GB SD Karte - der steuert meine ganze Heizungsanlage mit 1Wire, Modbus, A/D Wandler, Relais-Platine etc. Es ist glaube ich keine einzige GPIO mehr frei. Das packt der lässig (CPU langweilt sich) und wird auch nicht heiß.
Sowas günstig über Ebay reicht also vollkommen (hab gleich welche in Reserve gekauft, falls doch mal einer ausfällt, aber der läuft jetzt schon 2 Jahre stabil).

Für Homematic habe ich einen 4GB Raspberry 4 im Einsatz. Da läuft aber auch noch pi-hole und Prozesse für meine Kameras (ffmpeg) drauf. Dem habe ich jetzt einen PWM geregelten Lüfter verpasst, da er doch gerne heiß wurde. Liegt aber hauptsächlich am ffmpeg Prozess der die CPU über 20% zieht.

Gruß,
Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

tentaclejoe

Ich wollte für meine Frage keinen extra Thread auf machen da es sich um das gleiche Thema handelt.
Ich benutze momentan einen Rpi3 B+ mit 1GB RAM und ioBroker. An sich läuft es aber durch den knappen RAM muss ich mich bei ioBroker entscheiden welche Module ich benutzen will, da pro Modul eine nicht unerhebliche Menge an RAM gebraucht wird. Nun bin ich auf der Suche nach einer alternativen Smart Home Software mit der ich meine bestehende Hardware am besten ausnutzen kann.
Wie verhält es sich hier mir FHEM? Ist man durch die RAM Menge auch stark limitiert? Wie sehr steigt der RAM Verbrauch durch die Benutzung weiterer Module? Was sind euere Erfahrungen und was würdet ihr mir empfehlen?

isy

Dein Pi3 mit 1GB reicht, ich habe mit mehr als 20 aktiven Modulen (Fhem: "540 Entities", das sind die Geräte und die Regeln zur Automatisierung etc.) 200 MB belegt, der Rest ist Puffer.
Ein Weg wird erst zu einem Weg, wenn man ihn geht

frober

Fhem läuft auch auf einem Raspi 1b, mein Testsystem...

Kommt immer darauf an, was man tuen möchte. Sind zeitlich kritische Funktionen dabei, wir eh empfohlen ein zweites Fhem auf weiterer Hardware zu betreiben und die Prozesse entsprechend zu trennen.
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

Wernieman

Was ich so nicht unterschreiben würde. Bei zeitkritischen Systemen sollte man sich eine bessere Hardware als Pi (Egal bei welcher Hausautomatisation) zulegen.

- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

MadMax-FHEM

#35
Zeitkritisch und "Sicherheitskritisch" würde ich sogar (und mache ich auch [wo möglich/nötig]) auf den Aktor auslagern...

Schade, hier war früher auch zu sehen welche Plattform (oder?): https://fhem.de/stats/statistics.html

Evtl. mal die Signaturen von Usern ansehen...
...(sehr) viele (mich eingeschlossen) laufen auf einem PI2 oder PI3(+)...

Man sollte (sollte man aber eh, egal auf welcher Plattform / "dicke HW" verschleiert ja "Probleme"/"Unsauberkeiten"/"Performance-Frass" nur) eben schauen, dass man die Flut an Events die durch's System rauschen auf ein Minimum/gutes Maß zusammenstreicht...

Dann kann man schon so einiges mit einem PI machen :)

Und: viele "Anleitungen" sind eben für einen PI, mindestens aber für eine Linux Plattform...
(sieht man ja an den Statistiken "warum" ;)  )

Allerdings: es gibt auch "Konstellationen", die über Speicher klagen, meist "Speicherfrass"/Speicheranstieg (über die Zeit)...

Hatte ich auch mal, ist aber jetzt (bei MIR!) mit Umstieg auf Buster erledigt...

Hier mal einer der Threads zu diesem Thema: https://forum.fhem.de/index.php/topic,84372.msg766405.html#msg766405

Aber an sich ist die Anzahl geladener fhem Module/Instanzen/Devices eher kein Speicherproblem...

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)

tentaclejoe

Danke für die Aufklärung. Dann scheint sich FHEM in der Hinsicht deutlich von ioBroker zu unterscheiden denn dort schlägt ein zusätzliches Modul gerne mal mit mindestens 50MB zu Buche.
Hat man mehrere eigene JS Scripte am laufen sind die 1GB des Raspberry schnell voll.

Wernieman

Was erwartest Du von Java? Ist doch bekannt, d es Speicher schluckt ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

tentaclejoe

ioBroker läuft nicht unter Java sondern Node.js, glaube du verwechselst das mit openHAB.

frober

Ich habe nichts empfohlen, falls das jemand missverstanden hat.

Zeitkritisch, bzw. eher Zeitsteuerungen laufen bei mir autark auf Mikrokontroller. Die werden nur überwacht, bzw. der Zeitablauf wird z.B. bei der Bewässerung von Fhem angestoßen.

Ich wollte nur erwähnen, dass es möglich ist, Fhem mit "kleiner" Konfiguration, auch auf schwacher HW zu betreiben.

Mein Hauptsystem läuft auf einem 3b.
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

Beta-User

Zitat von: tentaclejoe am 08 August 2021, 08:45:31
Nun bin ich auf der Suche nach einer alternativen Smart Home Software mit der ich meine bestehende Hardware am besten ausnutzen kann.
Grundsätzlich glaube ich nicht, dass es zielführend ist, die Software wegen  der Hardware zu wechseln... Eine performantere neue Hardware kostet zwar erst mal etwas Geld (und das muss kein Pi sein, der an sich ja auch ein paar "Problemchen" mitbringt!), aber das ist eventuell die "günstigere" Variante, wenn man den Einarbeitungsaufwand (egal in welches System) mit berücksichtigt.

Grundsätzlich kommt FHEM mit relativ geringen Ressourcen aus, (aktuell belegt FHEM hier etwa 256MB auf einer x86-Maschine, und da ist Homematic-classic (CUL_HM), ZWave, ZigBee (HUE.*-Module) und MQTT (MQTT2-Module einschl. internem MQTT-Server!) am laufen...), und zusätzliche Geräte schlagen praktisch nicht wirklich zu Buche, aber man _kann_ auch FHEM so konfigurieren, dass es (meistens kurzzeitig) deutlich mehr Speicher braucht, indem man z.B. mehrfach "forks" erzeugt. Wenn die geforkten Prozesse dann längere Laufzeiten benötigen, fängt der Pi3 dann an zu swappen, und dann ist aus vielerlei Gründen schnell "aus mit lustig".

(Es ist so oder so zu empfehlen, ein Testsystem vorzuhalten, eine zweite Plattform kann daher auch aus diesem Grund nicht schaden!)

Deine Frage wäre evtl. in einem neuen Thread oder in https://forum.fhem.de/index.php/topic,81534.msg736218.html#msg736218 besser aufgehoben gewesen.

Ergo: Du darfst  FHEM gerne testen, es ist "schlank", und es ist auch anzunehmen, dass du das, was auf ioBroker läuft, in FHEM deutlich weniger Ressourcen verbrauchen wird! Aber Wunder darfst du ebensowenig erwarten wie eine stressfreie Einarbeitung!
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