[raspi] zu erwartende Performace für "größeres" FHEM System auf Raspberry Pi

[ronny332]

Hallo zusammen,

als Wechseler von einem CCU2 basierten Homematic System war ich anfangs von der "unglaublichen" Performance von FHEM auf einem Raspberry Pi (Modell B+) überaus positiv überrascht.

Mittlerweile laufen so einige Geräte (9 Fritz!Dect Steckdosen, EngeryCam via WMBus, 8 HM Heizungssteller, 6 HM Wandtemperatur Fühler, HM Regensensor, HM Aussen Thermometer, HM Key-Sec, HM wired Relais + Rolladen, ...). Zusammen gekommen sind bisher (vieles ist noch an der CCU2 angelernt und kommt erst nach und nach rüber) ca. 30 Geräte. Die Funklast ist dank FHEM und verschiedener Schnittstellen endlich kein Problem mehr.

Die Performance des Raspberry Pi ist allerdings mittlerweile im Webinterface doch recht schleppend geworden. Eine kleine Änderung in der fhem.cfg erzeugt 5-15s Wartezeit, auch längere Log Dateien bringen Graphen ziemlich ins Stocken.

Ganz lasch und laienhaft gefragt: "Wird das noch viel schlimmer?"

Hier im Haus läuft ein i7 Quad Macmini welcher FHEM problemlos "nebenbei" laufen lassen könnte, aber eigentlich wollte ich die Vermischung von System vermeiden (auch Dinge wie DNS Cache oder DHCP laufen auf einem extra Raspberry Pi, auch wenn OS X das problemlos beherrscht).

Mir ist bewusst, dass Anfragen dieser Art eher schwer global zu beantworten sind, dennoch würden mich kurze Meinungen zum Thema Raspberry Pi interessieren, besonders was Langzeit Erfahrungen angeht, welche ich noch nicht habe.
Meine Erfahrungen mit einer CCU2 waren in jedem Fall mehr als unschön, viel zu träge und überfordert wirkte mir das Gerät mit der letzten Konfiguration.

[betateilchen]

Mir ist bewusst, dass Anfragen dieser Art eher schwer global zu beantworten sind,

Dir ist hoffentlich auch bewusst, dass diese Frage hier im Forum schon unzählige Male gestellt UND beantwortet wurde?
Schau doch einfach mal im Bereich Hardware -> Einplatinencomputer. Ich glaube nicht, dass da noch eine Deiner Fragen unbeantwortet bleibt.

[Puschel74]

Hallo,

Eine kleine Änderung in der fhem.cfg erzeugt 5-15s Wartezeit,

Aber nur wenn man meint die fhem.cfg direkt bearbeiten zu müssen.
Nach einem save wird natürlich die gesamte Konfig neu eingelesen und das kann durchaus dauern.

Tipp: Lass die Finger von der fhem.cfg und mach alles über das Frontend.
Man muss sich zwar erst dran gewöhnen aber es ist praktikabel und macht Spaß da es viel angenehmer und schneller von der Hand geht.

auch längere Log Dateien bringen Graphen ziemlich ins Stocken.

Ja aber das wurde ja schon etliche Male im Forum erwähnt.

Den Rest hat ja betateilchen schon beantwortet 

Grüße

P.S.: Ich habe übrigens nur wegen der Plots auf einen Cubietruck gewechselt - für FHEM selbst wäre mein RasPi immer noch flott genug gewesen.
Ok, eigentlich war ja der Spieltrieb ausschlaggebend 

[ronny332]

Hallo,

danke für die Antworten.

Dann muss ich mich wohl noch etwas an die Suche hier gewöhnen. Ich bin absoluter Hasser von neuen Threads aber in dem Fall hatte ich nichts in dieser Art gefunden. Die Frage war wie beschrieben allgemeiner Natur und zielte auf einen Ratschlag ab, ob vielleicht jetzt schon die Zeit dafür gekommen ist direkt auf den Mac-Server zu wechseln (wo allerdings die EngeryCam dank WMBus im ersten Anlauf Probleme machte).

Mich verunsichert einfach die Tatsache, dass der Perl Prozess via "top" ständig zwischen 5 und 20% Last erzeugt, und das obwohl teilweise optisch nichts im Log und/oder via Telnet beim Funkverkehr stattfindet. Der Systemload ist allerdings noch in sehr schönen Dimensionen von 0.05 bis 0.15 über die letzten 5-15 Minuten.

Nachtrag:
das Unterforum hatte ich in der Tat komplett übersehen. Also ist das nächste Todo mal nicht Geräte einbinden sondern das Forum "erkunden" .

[juppzupp]

Wie hoch ist denn der 'wa' Anteil? Könnte auf eine zu langsame sdcard deuten.

[ronny332]

Hallo,

sorry für die verspätete Antwort, ich hatte mich an anderen Dingen festgebissen.

Mein Raspberry ist seit vorgestern spürbar erjüngt, der Geschwindigskeitszuwachs ist enorm, all das seit ich den "Eventlog" deaktiviert habe. Laut Command Ref wird dieser Eintrag für diverse Frontends benutzt, in meinem Fall hat er aber letztlich auch dieses Thema hier ausgelöst.

Bis vorgestern machte die Arbeit mit Fhem keinen Spaß mehr, es war nur noch träge und langsam. Die Anzeige von z.B. Details einer FileLog Konfiguration dauerte 10 Sekunden, damit wurden Änderungen fast unmöglich. Ich fühlte mich unweigerlich an meine letzte CCU2 erinnert, welche auch vollkommen überfordert wirkte.

Wie und wieso der Eintrage Eventlog in die fhem.cfg gekommen ist, kann ich nicht mehr nachvollziehen. Seit er deaktiviert ist gehen Seitenwechsel wieder ohne nennenswerte Verzögerung und jede Idee eines Wechsels vom Raspberry weg ist Geschichte. Die "trägen" Diagramme stören mich nicht weiter, hier bringt mein Verstand wohl ausnahmsweise genügend Geduld mit .

Einen schönen 3. Advent!

[tpm88]

Was genau meinst Du mit: "seit ich den "Eventlog" deaktiviert habe" ?? Welche Einträge in der fhem.cfg?

Tobias

[ronny332]

Sorry, da war ein Dreher drin. Ich meinte "EventTypes".

Der Eintrag war:

Code Auswählen Erweitern


define eventTypes eventTypes ./log/eventTypes.txt


Einige Minuten vor meiner letzten Antwort hatte ich viele FileLog Einträge geändert, daher kam wohl noch zuviel "Log" in meinen Gedanken vor .

Die eventTypes.txt war schon relativ groß geworden, im letzten Zustand über 8 MB.

[rudolfkoenig]

Die eventTypes.txt war schon relativ groß geworden, im letzten Zustand über 8 MB.

Kansst du diese Datei komprimiert hier anhaengen?

[ronny332]

Gerne, "siehe Angang".

Einen Blick habe ich eben in die Datei geworfen. Es scheint wirklich ein langfristiges und Sammelsurium an Events zu sein. Wenn ich mir aber überlege, dass die Datei ggf 2 Wochen gelaufen ist, ist es für einen kleinen Raspberry Pi auf Dauer wohl doch etwas viel des Guten (besonders wenn man den Aufwand des einsortierens zum passenden Devices im Hinterkopf behält, was auch eine recht große Schreiblast erzeugen würde).

[rudolfkoenig]

Danke, ich habe fuer RAWMSG eine weitere Ausnahme eingebaut, betrifft 96% der Daten.

Erstaunlich, wieviel mAn unnoetiges als Event vom HM-Modul generiert wird, anstatt es als Reading zu belassen. Kein Wunder, dass ein RPi mit HM langsam ist.