[Featurewunsch] plot.periode mit mehreren modes

[Chris46]

Hallo,

gestern ist bei mir der Featurewunsch entstanden mehrerer modes für einen plot.periode anzugeben. Im konkreten Fall wollte ich die von der Heizung pro Tag produzierte Wärmemenge mit dem mode='max' darstellen, das funktioniert auch wunderbar. Ich würde aber gern die Außentemperatur im Vergleich sehen wollen, dabei wäre es aber eher sinnvoll den mode='avg' zu benutzen, denn die Maximalwerte werden in der aktuellen Jahreszeit meist nur kurz erreicht und sind somit wenig aussagekräftig was den Wärmebedarf vom Haus betrifft. Ich habe auch den mode='minmaxavg' getestet, welcher mir aber nicht zusagt.

Wäre es möglich zukünftig mehrere modes in einem Plot zu verwenden? Ich hatte gerade kurz in die plot.js geschaut und nur ein paar Stellen ausfindig machen können, wo "mode" überhaupt verwendet wird. Bin mir aber fast sicher, dass dieser auch im Treiber oder an anderen Stellen Verwendung findet?

Viele Grüße Chris

[smai]

Lustigerweise bin ich eben vergangene Woche auch genau darauf gestossen, weil ich "avg" und "on" mischen wollte.

Wenn ich es richtig einschätze, müsste dies tatsächlich recht einfach zu implementieren sein. Wahrscheinlich muss es nur im Twig Makro (also in der Datei widgets/plot.html) angepasst werden.
Im JS wird einzig minmax(avg) speziell behandelt, weil da die Datenreiehen für min und max zu einer Serie im Chart zusammengefasst werden müssen. Die grösste Herausforderung wird also sein, entweder das Mischen auch für Kombinationen mit minmax(avg) zum Laufen zu bringen oder zumindest zu verhindern, dass minmax(avg) mit anderem kombiniert wird (sprich: eine entsprechende Fehlermeldung anzeigen).

Aus Interesse habe ich aber noch Fragen zu deinem Anwendungsfall:
Wie führst du die produzierte Wärmemenge genau, dass du diese mit "max" abfragst? Falls du das database Plugin in SHNG verwendest, könnte vielleicht "diff:max" interessant sein (Details dazu im Readme des Plugins)
Und wie erreichst du das "pro Tag"? Fragst du z.B. mit count=365 und tmin=1y ab?

[Chris46]

Cool, und ich dachte schon ich bin der einzige, der solche Sonderlocken braucht.

Aus Interesse habe ich aber noch Fragen zu deinem Anwendungsfall:
Wie führst du die produzierte Wärmemenge genau, dass du diese mit "max" abfragst? Falls du das database Plugin in SHNG verwendest, könnte vielleicht "diff:max" interessant sein (Details dazu im Readme des Plugins)
Und wie erreichst du das "pro Tag"? Fragst du z.B. mit count=365 und tmin=1y ab?

Dazu muss ich ergänzen, dass ich FHEM nutze, was hier wahrscheinlich die Ausnahme ist, aber die Unterstützung zu smartVISU ist hier einfach um ein Vielfaches besser.

Zu deinen Fragen: Die Wärmemenge stellt das Stiebel EItron ISG über eine Website zur Verfügung und zwar Gesamt und für den aktuellen Tag. Ich logge mit FHEM was auf der Website angezeigt wird. Die Wärmemenge steigt natürlich im laufe eines Tages, weswegen ich die "max" Funktion in von plot.period verwende, um nur den Tageshöchstwert anzuzeigen.
Klar ich könnte jetzt auch jeden Tag 23:59:59 den Wert für die Wärmemenge extra speichern und dann mit 'raw' im Plot anzeigen. Ich mag aber die genialen Funktionen von den plots, die mir die vorherige Bearbeitung der Daten abnehmen und ich nicht immer vorher schon wissen muss, was ich ggf. zukünftig noch anzeigen möchte. Rückwirkende Bearbeitung und Berechnung ist zwar möglich, aber oftmals auch nicht ganz trivial.

[smai]

So, ist nun umgesetzt.
Bei dieser Gelegenheit habe ich auch gleich   count  pro Item gemacht. Damit kann man z.b. den gesamten Temperaturverlauf sowie den täglichen durchschnitt in einem Plot anzeigen.

minmax war tatsächlich eine Herausfoderung, funktioniert nun aber auch.

[bmx]

Was Du nun schon alles neues implementiert hast, da müßte man ja in der Doku einiges an Beispielen finden oder ;-)

[smai]

Tut man ja auch, bei plot.period sind es 7.
Ich habe mir noch überlegt, für das hier ebenfalls eines zu machen (evtl. sogar das erwähnte z.b. mit avg pro Tag und max mit höherer Auflösung).
Aber ich habe dann davon abgesehen, zu viele Beispiele macht es nicht übersichtlicher.

Aber beschrieben sind die Parameter natürlich, da achte ich immer sehr drauf.

[Chris46]

So, ist nun umgesetzt.
Bei dieser Gelegenheit habe ich auch gleich   count  pro Item gemacht. Damit kann man z.b. den gesamten Temperaturverlauf sowie den täglichen durchschnitt in einem Plot anzeigen.

minmax war tatsächlich eine Herausfoderung, funktioniert nun aber auch.

Genial, vielen Dank dafür, es funktioniert!

Ich habe mir noch überlegt, für das hier ebenfalls eines zu machen (evtl. sogar das erwähnte z.b. mit avg pro Tag und max mit höherer Auflösung).

Da würde mich interessieren wie das nur mit count möglich ist?
So wie ich es kenne bzw. herausgefunden habe, hängt das Aggregation-Intervall von dem duration-format ab. Heißt: Wenn ich bspw. 14d als duration angeben, dann wird mit der Aggregation ein Wert pro Tag im Plot dargestellt, wenn ich 72h als duration angebe, dann wird mit der Aggregation ein Wert pro Stunde im Plot dargestellt. Das ist zumindest meine Erfahrung mit dem FHEM-Backend.

[bmx]

Ich finde Beispiele als Use-Cases immer prima. Oftmals kommt man dann auf Ideen, wie etwas viel besser zu lösen wäre als man anfangs sich das ausgedacht hat.

Insofern Danke für deine Doku, ich freue mich immer wenn die erweitert worden ist.

[smai]

So wie ich es kenne bzw. herausgefunden habe, hängt das Aggregation-Intervall von dem duration-format ab. Heißt: Wenn ich bspw. 14d als duration angeben, dann wird mit der Aggregation ein Wert pro Tag im Plot dargestellt, wenn ich 72h als duration angebe, dann wird mit der Aggregation ein Wert pro Stunde im Plot dargestellt. Das ist zumindest meine Erfahrung mit dem FHEM-Backend.

OK, wusste ich nicht, das dies in FHEM so ist. Wird da denn count ignoriert?
In SmartHomeNG und ioBroker wird count für die Stückelung berücksichtigt, bei der Duration ist z.B. 168h, 7d und 1w absolut gleichwertig.

[Chris46]

smai: Für mich zum Verständnis: Wo genau findet denn die Aggregation statt? Ist diese ggf. für jedes Backend anders?

Ist gewollt, dass die Verteilung bei der Aggregation so inhomogen ist? Oder ist das auch ein Problem mit dem Backend?

[smai]

Die Aggregation macht das Backend. Die smartVISU zeigt einfach die erhaltenen Daten an, ohne diese weiter zu prüfen/verarbeiten.
ich kann aber natürlich nicht ausschliessen, dass die smartVISU auch etwas falsch macht. Speziell beim minmax, welches ich ja komplett umbauen musste.

Ein weiter Punkt für Fehler könnte auch der Backend-Treiber sein. Dieser ist zwar Teil der smartVISU, aber natürlich für jedes Backend anders.

[Chris46]

Ich werde bezüglich des Treibers im FHEM Forum mal anfragen. Mit einem anderen Backend treten die Probleme mit der Aggregation also nicht auf?

Vielen Dank für deine Unterstützung!

[smai]

Mit einem anderen Backend treten die Probleme mit der Aggregation also nicht auf?

Das habe ich ehrlich gesagt nicht getestet.
Sinnvollerweise müsste ich jede Änderung jeweils mit allen Backends testen. Weil ich das aber nur als Hobby mache, fehlt mir die Zeit dazu. Deshalb teste ich meist nur mit dem Offline-Treiber.
Mit diesem weiss ich auch genau, was ich kriege und muss nicht erst herausfinden, ob ein Fehler am Backend oder mir liegt.

[Msinn]

Gibt's Kuchen?

Die Aggregation macht das Backen.