Monatsrückblick Januar/Februar 2026 ist online!

[SKB]

@koilapo Wenn Du möchtest, kannst Du einmal die Version direkt von Github laden und dann den Modus im Tab "Animation" anpassen.

[koilapo]

@SKB Vielen Dank, das funktioniert.

Allerdings habe ich im Energiesparmodus jetzt eine leicht höhere CPU-Auslastung und höheren Stromverbrauch. Der 0.8.1 Energiesparmodus war da tatsächlich sparsamer gegenüber dem Normalmodus.

[SKB]

@koilapo An dem Modus ansich hat sich so gesehen nichts geändert.
Natürlich kann es sein, das die CPU-Last anhand der langsamen Zeit anders berechnet.

[koilapo]

@SKB Mit Version 0.8.1 habe ich im Sparmodus ca. 15-30% CPU-Auslastung, mit der 0.8.2 zwischen 45 und 60%. Bin grad nochmal zurückgewechselt zum Vergleich.

[SKB]

Das kann mit vielen anderen Faktoren zu tun haben - wurde der Browser komplett geschlossen? Läuft zu dem Zeitpunkt noch etwas Anderes im Hintergrund usw.
So lässt sich das auf keinen Fall nachvollziehen - außer, man nutzt das gleiche System einmal mit Version x und das andere mit Version y.
Wie gesagt - an der Animations-Logik hat sich nichts geändert. Auch rechnet das System viel mehr, wenn die Animation langsamer läuft.

[koilapo]

@SKB Der Browser wurde jeweils neu gestartet. Auf dem Gerät läuft nur noch ein MQTT-Broker, im Hintergrund tut sich da nicht viel.

Mit 0.8.1 ist der Sparmodus tatsächlich deutlich sparsamer (CPU und Stromaufnahme des Windows-Tablets) als der Sparmodus mit 0.8.2 (siehe oben).

Ich habe nun mit 0.8.1 die Punkte von Länge 5 und Abstand 5 auf 10 und 24 geändert. So ist es nicht so "hektisch".

Aber irgendwas ist an der neuen Version ja schon anders, sonst würde ich das nicht so deutlich sehen. Was ist denn genau der Unterschied Normalmodus/Geringe Leistung? CSS vs. JS?

[SKB]

@koilapo an der Version ist auch weiterhin nichts anders - je öfter du auch fragst.

Zu deiner neuen Frage:
Ja, der Stromsparmodus nutzt Javascript und kein CSS.

[koilapo]

@SKB sagte in Test Adapter Energiefluss-erweitert v0.8.x GitHub/Latest:

an der Version ist auch weiterhin nichts anders - je öfter du auch fragst.

Ich beschreibe nur meine Beobachtung. Kann ja nichts dafür, dass es so ist.

Was ist mit der Beschreibung für 0.8.2 genau gemeint:

"Neu: Der Modus „Geringe Leistung“ wurde verbessert, indem die möglichen Animationsframes berechnet werden, anstatt statische Zeiten zu verwenden."

[SKB]

@koilapo Vorher wurde die Länge der Linie berechnet und anhand dessen die Zeit, welche die Animation benötigt.

Dies wurde durch die JavaScript Komponente requestAnimationFrame ersetzt!

[koilapo]

@SKB Danke, dann haben wir die Ursache ja wahrscheinlich schon:

The window.requestAnimationFrame() method tells the browser you wish to perform an animation. It requests the browser to call a user-supplied callback function before the next repaint.

Quelle

-> call a user-supplied callback function before the next repaint
-> also 60 mal je Sekunde wird die Funktion aufgerufen gegenüber Null Aufrufen für einen statischen Wert.

[SKB]

@koilapo Welche Ursache? Für eine höhere CPU Last? Nein, denn die Funktion ruft sich nicht 60 Mal pro Sekunde auf, sondern reserviert sich selbst für den nächsten repaint, was CPU schonender ist, als eine for-Schleife - das Bild wird eh 60 Mal die Sekunde neu gezeichnet. Das ist der Standard auf einem 60 Hertz Monitor.

[koilapo]

@SKB Vielleicht hängt die tatsächliche Effizienz vom Betriebssystem und Browser ab. Mit Edge unter Win10 läuft es jedenfalls ineffizienter mit requestAnimationFrame als mit der einfachen Schleife - ist jedenfalls meine Beobachtung/Messung.

Aber damit derselbe Energiefluss möglichst einheitlich auf verschiedenen Bildschirmen/Systemen läuft, ist Dein Weg schon sinnvoll.

[SKB]

@koilapo Ich würde an deiner Stelle einmal Chrome (auch Chromium wie Edge) oder Firefox (Webkit) ausprobieren. Die funktionieren aktuell am Zuverlässigsten beim EF.

Allerdings schaue ich gleich noch einmal, was sich noch optimieren lässt - habe da schon etwas im Kopf.

[koilapo]

@SKB Danke für den Tipp. Edge ist mit Abstand der schnellste Browser auf der Kiste, habe schon verschiedene ausprobiert. Chromium ist fast gleichauf.

[SKB]

@koilapo So, ich habe nun noch einmal etwas angepasst, um die Animation optimierter zu bekommen. Kannst gerne nochmal die Version von Github drüber installieren und deine Eindrücke mitteilen.
Ich denke, es sollte nochmals ein merklicher Unterschied da sein, machte bei mir in etwa 20-25% aus - je nachdem, wieviele Linien sichtbar sind.

[koilapo]

@SKB Vielen Dank. Also ich merke keine Verbesserung im Sparmodus, aber im Normalmodus ist nun das Tempo nicht mehr einstellbar, es ist immer ziemlich langsam, egal welchen Wert ich dort eintrage. Vorhin ging das noch.

[SKB]

@koilapo Ich liebe es immer, wenn ich Updates herausbringe, das etwas nicht mehr geht.

Immer folgende Reihenfolge einhalten, wenn von Github installiert wird:

• von Github installieren
• Upload des Adapters vornehmen
• Browser mit Strg + F5 neuladen

Dann funktioniert auch alles wie vorher und eben besser ;)

[koilapo]

@SKB Danke, war wohl gecacht.

Nach wie vor erzeugt der Normalmodus deutlich weniger CPU-Last als der Sparmodus in 0.8.2. Wobei der Sparmodus in 0.8.1 am besten ist (außer vom Tempo).

[SKB]

@koilapo Dann wird dies wohl ein Problem mit dem Edge sein.

[koilapo]

@SKB sagte in Test Adapter Energiefluss-erweitert v0.8.x GitHub/Latest:

Dann wird dies wohl ein Problem mit dem Edge sein

Oder an irgendwas anderem auf dem nicht mehr ganz frischen Gerät, was auf neuen CPUs anders läuft. Das Teil ist ja leider nicht Win11 -kompatibel, aber eigentlich recht flott für den Zweck.

Schade, dass in der nächsten Version dann der alte JS-Modus nicht mehr vorhanden ist, aber soweit läuft 0.8.1 ja perfekt.