Hallo,
bei mir läuft FHEM in der aktuellsten Version auf einem RPi B.
Das funktioniert soweit auch ganz gut.
Nun habe ich mich die letzten Tage mal mit dem RSS-Workshop von betateilchen beschäftigt und mir ein Layout gebasteln.
Nur dauert das laden des rss.png bzw. der refresh der rss.html bei mir etwa 5 sekunden.
In dieser Zeit ist der RPi anscheinend so ausgelastet, das auch FHEM in dem Zeitraum nicht reagiert. Bei der Anzeige über ein 10"Tablet erscheint in dem Zeitraum dadurch auch nur ein weißes Bild.
Da das Bild über die rss.html ja jede Minute neu geladen wird, wird natürlich alles regelmäßig blockiert.
Nun stellt sich mir die Frage, ob der RPi einfach zu schwach ist, um den Aufbau flüssig zu bewerkstelligen?
Oder kann man da noch einiges optimieren?
Gruß
Stefan
Hallo
hast wohl hier noch keine Antwort bekommen.
habe hier ein ähnliches phenomän.
hast du da schon näheres rausgefunden.
ich hab mal sudo apt-get install nmon
und dann mit nmon die CPU auslastung beobachtet, diese geht sehr oft auf 100%
Gruß Josty
es gibt diverse wege das problem zu lösen. rss ist sehr rechenintensiv beim erstellen des bildes.
-du kannst http://forum.fhem.de/index.php/topic,32828.0/topicseen.html nutzen
ZitatWas ist nun das Neue? Nun, die gesamte Ausgabe ist kein Bild, sondern eine html Seite mit SVG Elementen. Das heißt, das gesamte Rendern der Anzeige erfolgt im Browser und nicht mehr auf der fhem Plattform.
sprich der pi müsste nichts mehr machen sondern das tablet hätte die abreit. man müsste aber alles neu bauen
- das rss nicht immer beim zugriff des zb tablet's zu erstellen sondern das bild regelmäßig zu erstellen und es dann zb mit einem webserver auf dem pi zu hosten
so müsste das tablet nur das bild laden und nicht warten bis es neu gerendert wurde
- andere möglichkeit -> neue hardware ;) oder eines der vielen tollen anderen "frontends" (smartvisu, floorplan, usw)
Nach einigen Erfahrungen zu dem Thema würde ich zustimmen, dass der RASPI B etwas zu schwach ist, wenn das RSS-Image aufwändig ist bei der Erzeugung. Unter anderem aus dem Grund hatte ich meine FHEM-Installation auch auf zwei RASPIs verteilt. Die Entkoppelung hatte zumindest den Vorteil, dass RSS nicht den Steuerungsteil verzögerte. Aber auch danach, war die Leistung für den RSS-Teil nicht gerade der Bringer. Was offenbar sehr aufwändig ist, sind eingebundene Images, die relativ groß sind (z.B. die Radarmap des GDS-Moduls). Hier hat es deutlich geholfen, wenn ich die eingebundenen Images, bevor ich sie in RSS verwende, schon (z.B. mittels Imagemagick auf Linux-Ebene) auf die tatsächlich gebrauchte Größe geschrumpft habe. Trotzdem konnte ich ein 10-Sekunden-Refresh auf dem Bilderrahmen nur mit Unterbrechungen realisieren.
Was es aber dann entscheidend gebracht hat, war der Umzug auf einen Banana Pi. Damit ist ein 5-Sekunden-Refresh des (optimierten) RSS-Feeds kein Problem mehr. Und auch die anderen Sachen darauf laufen ohne Verzögerung.
Alternative ist natürlich das schon genannte Modul InfoPanel (cooles Teil, ganz neu von Betateilchen), wenn man auf Client-Seite einen Browser hat.
So, ich habe mittlerweile mal ein wenig aufgerüstet.
FHEM läuft nun auf einem Cubietruck.
Nur leider gibt es keine nennenswerten Verbesserungen. :'( An mangelnder Power dürfte es nicht liegen.
Ich werde mich dann wohl mal mit dem Infopanel oder einem der frontends beschäftigen.
Das finde ich interessant, dass der Cubietruck keine nennenswerten Verbesserungen bringt. Entweder ist der Cubietruck aus irgendwelchen Gründen nicht so performant wie der Banana Pi, oder das Performance-Problem liegt woanders (Netzwerk usw.). Wie gesagt, bei mir war der Performance-Schub mit dem Banana Pi deutlich, bei sonst gleicher Konfiguration...