Ich habe FHEM schon länger auf einem Raspberry Pi B laufen und war damit bislang auch zufrieden.
Nun habe ich in letzter Zeit aber ein paar Dinge hinzugenommen, wo es doch mal hakelt bzw. FHEM spürbar blockiert wird (an vorübergehenden disconnects zu bemerken).
Kandidaten dafür sind:
-Kalender-Updates durch das Calendar-Modul
-Calview-Aktualisierung
-Proplanta-Abruf
Außerdem geht mir der Seitenaufbau bei der Tablet-UI teilweise zu langsam, wobei ich nicht sicher bin, ob das an FHEM oder am Tablet selbst liegt.
Meine Frage(n) also:
- Würde der Wechsel auf einen Raspberry Pi 2 mit seiner theoretisch deutlich stärkeren Rechenleistung hier Abhilfe schaffen?
- Müsste man zu einem noch größeren Kaliber greifen, um spürbare Verbesserungen zu erzielen?
- Oder liegt es eher an anderen Flaschenhälse wie Online-Abruf oder SD-Karten-Zugriffe, die sich dadurch auch nicht verbessern würden?
Wenn vielleicht jemand mit ähnlichen Voraussetzungen/Problemen diesen Wechsel schon vollzogen hat und aus eigener Erfahrung berichten kann, würde ich mich freuen.
Oder wenn es andere Ansätze gibt, solche Probleme zu vermeiden, wäre ich auch da für Anregungen dankbar. Habe auch schon überlegt, alles blockierende auf einen separaten Raspi auszulagern und dann nur die "Endergebnisse" ins Hauptsystem einzuspeisen. Aber im Prinzip würde ich solche Umwege und den damit verbundenen Aufwand gerne vermeiden.
Hi,
Kalender etc. habe ich nicht am laufen, jedoch bin auch ich von Raspi B+ auf Raspi 2 umgestiegen. An FHEM selber habe ich nicht viel bemerkt, am Aufbau der Diagramme sehr wohl. Auch hatte ich mit der damaligen Hardware SSL Probleme (ich deute dies auf Performance), die ich seit der neuen Hardware nur noch äußerst sporatisch habe.
Die positiven Aspekte gehen natürlich wahrscheinlich einher mit den negativen (Stromverbrauch)
mfg
NaCkHaYeD
Hallo Brockmann
im Thread http://forum.fhem.de/index.php/topic,38106 (http://forum.fhem.de/index.php/topic,38106) hat Deudi am 21.07. geschrieben, das er derzeit auf 2 FHEM-Installationen setzt, was er "Gewaltenteilung" nennt.
Meine Antwort dazu beschreibt ein bisschen den Hintergrund, warum bei der Verwendung vieler Module bzw. bestimmter Module Blockaden auftreten können.
Habe selbst einen RPi 2.0 und kann daher nicht mit einem RPi B vergleichen. Da für FHEM die Singel-Core-Performance entscheidend ist, dürfte der RPi 2.0 einen Vorteil bringen, wenn es viel zu tun gibt (schau dir mal mit "top" die CPU-Auslastung durch FHEM/perl an).
Blockaden, die durch externe Kommunikation verursacht werden, werden durch den RPi 2.0 nicht verkürzt. Hier müsste geprüft werden, ob man das verantwortlich Modul verbessern kann.
LG, jensb
Zitat von: jensb am 22 Juli 2015, 20:35:16
im Thread http://forum.fhem.de/index.php/topic,38106 (http://forum.fhem.de/index.php/topic,38106) hat Deudi am 21.07. geschrieben, das er derzeit auf 2 FHEM-Installationen setzt, was er "Gewaltenteilung" nennt.
Danke für den Hinweis. Ich habe mittlerweile auch weiter gelesen und überlegt. An der Erkenntnis, dass man das Problem "Blocking" auch durch mehr Rechenpower nicht lösen kann, führt kein Weg vorbei.
Sicher wäre es optimal, wenn die Blocking-Probleme innerhalb der Module gelöst würden. Aber das liegt jenseits meiner Möglichkeiten.
Wobei ich diese Blocking-Effekte mittlerweile auch weniger als Ursache sehe, sondern mehr als Symptom, das mir sagt: "Wenn Du ein System haben willst, dass einerseits regelmäßig alle möglichen Daten aus dem Netz beschafft und verarbeitet und das gleichzeitig stabil und quasi in Echtzeit auf Ereignisse reagieren soll, dann willst Du zuviel."
Mein Strategie zur Problemlösung sieht im Moment so aus:
- Kurzfristig: FHEM-Umzug von einem Raspberry Pi B auf einen Raspberry Pi 2 und vorläufiger Verzicht auf weitere Kalender & Co, in der Hoffnung, dass dann zumindest TabletUI schon mal flüssiger läuft.
- Mittelfristig: Installieren einer zweiten FHEM-Instanz und Auslagern aller "Blocking-Kandidaten" in diese zweite Instanz, so dass nur die "Endergebnisse" per FHEM2FHEM im Haupt-FHEM landen. Ich würde allerdings erstmal probieren, diese zweite FHEM-Instanz auf demselben Raspberry PI 2 laufen zu lassen, wie die erste. Rechenpower sollte er dafür genug haben.
- Langfristig: Wenn die Tablet-UI dann immer noch nicht flüssig genug läuft, würde ich versuchen, auch diese auf einen separaten Webserver auszulagern.
Bin gespannt, ob sich so eine dauerhaft solide Lösung erreichen lässt.
Ansonsten hatte ich noch überlegt, Android-Tablets, die ohnhin im Haus herumhängen und im wesentlichen nur Informationen anzeigen, mit Blocking-Aufgaben zu betrauen, soweit sich dafür Lösungen finden lassen. Im Prinzip kann man ja sogar Perl-Skripte auf Android ausführen, wobei FHEM auf einem Android-Tablet wohl etwas ambitioniert wäre. Aber probieren würde ich es... ;)
Das wäre aber eher Plan B, wenn Plan A nicht so wie gewünscht funktioniert.
Um das soweit abzuschließen:
Den Umzug von Raspberry Pi 1 B zum Raspberry Pi 2 habe ich mittlerweile vollzogen.
Der Performancegewinn ist deutlich spürbar. Wo er allerdings nichts oder wenig gebracht hat:
- Erwartungsgemäß bei Blocking-Problemen. Ein Proplanta-Abruf etwa dauert mit dem Pi 2 genauso lange wie mit dem Pi 1. Hier ist wohl die Antwortgeschwindigkeit des Servers der limitierende Faktor und nicht die Verarbeitung auf dem Pi.
- Nicht ganz so erwartet bei Tablet-UI. Hier ist der limitierende Faktor ganz klar das Rendern auf dem Client. Auf einem durchschnittlichen PC mit Chrome werden auch komplexe Seiten jetzt sehr zackig aufgebaut (spürbar schneller als beim Pi 1. Aber auf einem Android-Tablet ebenfalls mit Chrome-Browser dauert dieselbe Seite immer noch mehrere Sekunden.
Ich mache dann mal mit Schritt 2 weiter: Zweite FHEM-Instanz auf dem Pi 2, wohin die üblichen Blocking-Verdächtigen ausgelagert werden
Moin Brockmann,
Zitat von: Brockmann am 14 August 2015, 08:18:20
...auf einem Android-Tablet ebenfalls mit Chrome-Browser dauert dieselbe Seite immer noch mehrere Sekunden.
Hast Du schon mal mit:
- fwcompress=1
- plotEmbed=1
- plotfork=1
getestet ?
Viele Grüße
Sunny
Zitat von: Sunny am 14 August 2015, 20:19:40
Hast Du schon mal mit:
- fwcompress=1
- plotEmbed=1
- plotfork=1
getestet ?
Danke für den Tipp, aber die Performanceprobleme bestehen bei der TabletUI, wo sich das kaum auswirken dürfte. Plots benutze ich kaum und die laufen mit dem Raspi 2 jetzt ohnehin wirklich viel schneller. Plotfork hatte ich sogar getestet, aber subjektiv keinen Unterschied feststellen können. Und das Komprimieren von HTML ist doch ohnehin eher Kosmetik bzw. allenfalls bei langsamen Mobilfunkverbindungen interessant.
Und wie ich ja auch schon feststellte, der Flaschenhals ist der Browser, der das ganze JavaScript (von TabletUI) rendern muss.
Hallo!
Ich bin auch vom RPi 1B auf einen RPi 2 umgestiegen und der Unterschied war schon deutlich spürbar. Mittlerweile teilen sich die Pis bei mir die Aufgaben auch noch, der eine holt z.B. die Temperaturdaten von den Funksensoren und von Yahoo, der andere ist zum Schalten vom Licht etc. zuständig. Auf dem Tablet nehme ich die normale Webansicht, allerdings mit Floorplan für die wichtigsten Sachen, die ich schalten möchte. Und da merkt man den Umstieg auf den Pi 2 auch deutlich :)