Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Homoran]

@andygr42 sagte in Werteabhängiges loggen per Skript:

@homoran Negative Vorzeichen und schnell wechselnde Lasten wären bei der einfachen Durchschnittsrechnung kein Problem. So lange Array Länge eine ganzzahliges, Vielfaches der Update Frequenz ist, stimmt auch der Durchschnitt.

ja, das klappt problemlos.
Ich hatre aber bisher nur die Entladung "fertig"

Bedingung ist dass alle 0 und alle Werte über einer gewissen Schwelle (im Moment 1000W) sofort geschrieben werden, alles andere soll gemittelt und alle 2 Minuten geschrieben werden.
Kommt innerhalb der 2 Minuten ein (oder mehrere) "Priority Wert" soll erst danach in 2 Minuten der nächster gemittelte Wert geschrieben werden.

klappt soweit auch fast immer. jetzt muss ich nur noch herausfinden warum nicht wirklich immer.

@andygr42 sagte in Werteabhängiges loggen per Skript:

ich hab es nochmal für mehrere DP in einem Script optimiert.

das ist ganz lieb von dir, aber ich möchte es verstehen, damit ich es später selber machen kann.
Das ist mit Javascript für mich nicht machbar.
selbst das letzte Blockly von @paul53 nachzuvollziehen habe ich noch nicht vollständig geschafft.
von verstehen reden wir jetzt gar nicht.
Scheint wieder eine hochoptimierte Version a la Paul von dem zu sein, was mir vorschwebte.

[AndyGR42]

@homoran sagte in Werteabhängiges loggen per Skript:

Bedingung ist dass alle 0 und alle Werte über einer gewissen Schwelle (im Moment 1000W) sofort geschrieben werden, alles andere soll gemittelt und alle 2 Minuten geschrieben werden.
Kommt innerhalb der 2 Minuten ein (oder mehrere) "Priority Wert" soll erst danach in 2 Minuten der nächster gemittelte Wert geschrieben werden.

Was willst Du damit erreichen? Im Grunde verfälschst Du damit deine Daten und alle Aggregationen von Flott wären mehr oder weniger falsch (vermutlich fast immer zu hoch).

Ich vermute mal, Du möchtest zwei Dinge erreichen:

• Reduzierung der Daten für die Langzeitaufzeichnung. Bei einer Aggregation über Monate oder Jahre spielt eine Auflösung von 1 Sekunden keine Rolle. Dennoch sollten die Mittelwerte halbwegs stimmen.

• Eine sehr granulare Sicht auf einen kurzen Zeitraum, mit der Möglichkeit sekundengenau zu beobachten, das System zu optimieren und Fehler zu finden.

Das bekommst Du meiner Meinung nach nicht unter einen Hut. Ich würde daher zwei Werte nutzen. Den hochfrequenten Messwert, ggf. mit Glättung im Flott Diagramm, aber nur 2 Wochen oder einen Monat History. Mehr macht hier auch kaum Sinn. Das Langzeitdiagramm verwendet dann die gemittelten Werte für einen sehr langen Zeitraum.

Natürlich könnte man die Langzeit Daten auch von Flott aggregieren und Glätten lassen. Das würde aber einen große, robuste Datenbank vorrausetzen. Bei den meisten Benutzern würden wahrscheinlich schon bei deinen aktuellen 50GB Probleme auftreten.

[Homoran]

@andygr42 sagte in Werteabhängiges loggen per Skript:

Was willst Du damit erreichen?

ich benötige die Übersicht über Leistungsspitzen
und die 0 damit es nicht zu den Artefakten kommt.

Das war der Aufhänger für die gesamte Diskussion.

[AndyGR42]

@homoran Über welchen Zeitraum?

P.S.: anders gefragt, wie lange willst Du diese Ansicht mit diesem Zeitausschnitt aufbewahren?

[Homoran]

@andygr42 den Kontext zu dieser Frage sehe ich jetzt nicht.

Insgesamt soll die Datenaufzeichnung darauf ausgelegt sein.
Ich will nicht alle Werte doppelt aufzeichnen und eigentlich auch nicht per Skript manipulieren.
Deswegen war das Ursprungsthema auf die Filterrfunktionen von History bezogen.

[AndyGR42]

@homoran In der Regel manipuliert man die Daten in der Ansicht und nicht in der Speicherung. Daher halt meine Frage, wie weit eine so granulare Ansicht zurückreichen soll. Und wie genau die historischen Werte sein sollen, wenn Du z.B. mal die Daten über mehrere Monate vergleichst

[Homoran]

@andygr42 sagte in Werteabhängiges loggen per Skript:

wie weit eine so granulare Ansicht zurückreichen soll.

die soll ja nur die Spitzen zeigen, der Rest ist nicht feingranular

[AndyGR42]

@homoran Hast Du mal mit der Aggregation von Flott rumgespielt? Vielleicht reicht es hier die Parameter zu ändern, dann brauchst Du gar nichts an den Messwerten zu manipulieren.

[Homoran]

@andygr42 sagte in Werteabhängiges loggen per Skript:

Hast Du mal mit der Aggregation von Flott rumgespielt?

Natürlich!
aber das setzt die feingranuläre Historisierung voraus, von der ich weg will.

[AndyGR42]

@homoran Wie wäre dann die Idee, keinen absoluten Wert der Differenz als Trigger zu wählen, sondern einen prozentualen? Das würde das Problem am unteren Skalenende wieder auf Null zu kommen zumindest deutlich mittigeren

(geht natürlich nicht mit der vorhandenen Version von History)

[paul53]

@homoran sagte: Datenpunkt mit wechselndem Vorzeichen.

Das habe ich berücksichtigt. Zur Erläuterung:
Wenn die Differenz des aktuellen Wertes zum zuletzt geschriebenen Wert(lastPower) innerhalb von 2 Minuten einen bestimmten Betrag überschreitet, wird geschrieben. Andernfalls wird der Mittelwert der letzten 2 Minuten geschrieben. Die Auswertung "Ladung/Entladung" erfolgt erst beim Schreiben.

[Homoran]

@paul53 Soweit hab ich das auch verstanden.
Lediglich einzelne Details muss ich noch ventilieren.

Außerdem kann ich immer noch die Aussage

@paul53 sagte in Werteabhängiges loggen per Skript:

Meiner Meinung wird zu früh zwischen Laden und Entladen unterschieden.

nicht zuordnen.

Bei dir ist die Grenze +/- 100W, bei mir war sie beim Entladen auf 1000W, das Laden hatte ich noch nicht implementiert.
Natürlich weiss ich dass ich auch in deinem Blockly den Wert hochsetzen kann.

[paul53]

@homoran
Das sagt nichts anderes aus als
@paul53 sagte in Werteabhängiges loggen per Skript:

Die Auswertung "Ladung/Entladung" erfolgt erst beim Schreiben.

[Homoran]

@paul53 Danke!
jetzt hab ich noch was zum nachdenken :thinking_face:

Aber ich glaube da komm ich noch hin.

[AndyGR42]

@homoran Ich habe das mal eben hingeklimpert. Es schreibt den zweiten DP (mit einem geht das nicht, da die Änderung ja sofort in History geschrieben wird) nur bei Änderungen >20%. Das müsste eigentlich deinem Ziel, schnelle, große Peaks sofort und nicht geglättet zu schreiben ebenso entgegenkommen wie das Erreichen von Null bei Änderungen im unteren Skalenbereich. Zur Not könnte man beim Prozentwert auch noch zwischen Steigen und Fallen unterscheiden.

Vielleicht übernimmt apollon ja die Idee für den History Adapter :)

[Homoran]

@andygr42 sagte in Werteabhängiges loggen per Skript:

Vielleicht übernimmt apollon ja die Idee für den History Adapter

dazu muss es erst einmal laufen.

@andygr42 sagte in Werteabhängiges loggen per Skript:

Ich habe das mal eben hingeklimpert.

DANKE!
aber ich fürchte, dass ich den Versuch sofort wieder verworfen habe, da bei einer Abtastrate von 1Hz, nur der erste Messwert im Vergleich zum vorherigen die Kriterien erfüllt.
Bei 45 Sekunden Mikrowelle (oder 3 Minuten Duschen) wäre das nur 1 Messpunkt, der geschrieben wird.

Auch die 0 rutscht durch, wenn der Absturz bis auf wenige Watt stattfindet und dann langsam Richtung 0 geht.

[AndyGR42]

@homoran Ersteres ist ja kein Problem. Man könnte ja auch noch den vorherigen Wert schreiben. Der Zweite Punkt hängt vom Prozentsatz ab. Alternativ schreibt man unter eine Schwelle wieder jeden Wert.

[Homoran]

@andygr42 sagte in Werteabhängiges loggen per Skript:

Alternativ schreibt man unter eine Schwelle wieder jeden Wert.

das soll ja vermieden werden. Die plätschernde Grundlast ist (mir) egal.

Ersteres ist ja kein Problem. Man könnte ja auch noch den vorherigen Wert schreiben.

Ja! War dann auch mein Ansatz.
Aber das wurde dann nicht mehr das schnelle "mal eben" Skript, dass ich für diverse DP nutzen wollte.

[AndyGR42]

@homoran Entweder unter einer bestimmten Last auf Null setzen oder an der Stelle den Mittelwert errechnen, was aber deutlich aufwändiger wird. (wobei das hier Quick & Dirty ist und nochmal überarbeitet werden muss)

Ohne Script wird das vermutlich nicht funktionieren, es sei denn jemand baut die Logik in History ein.

[AndyGR42]

So ist's besser: