NEWS
Werteabhängiges loggen per Skript
-
@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.@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 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
@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 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
-
@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.
@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 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.@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 sagte:
Meiner Meinung wird zu früh zwischen Laden und Entladen unterschieden.
ich habe einen Datenpunkt mit wechselndem Vorzeichen.
natürlich kann ich da eine Hysterese einbauen, aber was soll die bringen (für das Skript)?
je nach Verbraucher oder Wechsel in der Sonneneinstrahlung kann der Verbrauch/die Produktion immer schleichend an der Entscheidungsgrenze liegen oder auch noch nach einiger Zeit zwischen Be- und Entladung umschalten.Amüsantes Beispiel war heute Morgen die Moccamaster Kaffeemaschine, die Intervallbrühen betreibt, so dass mit 1500W oder 0W Last tatsächlich die Ladung dauernd umschaltete.
bin gerade dabei dein Blockly häppchenweise zu verdauen :-)
@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 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.@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 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. -
@homoran
Das sagt nichts anderes aus als
@paul53 sagte in Werteabhängiges loggen per Skript:Die Auswertung "Ladung/Entladung" erfolgt erst beim Schreiben.
@paul53 Danke!
jetzt hab ich noch was zum nachdenken :thinking_face:Aber ich glaube da komm ich noch hin.
-
@paul53 Danke!
jetzt hab ich noch was zum nachdenken :thinking_face:Aber ich glaube da komm ich noch hin.
@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 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 :)
@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 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.
-
@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.

@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 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.@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.

-
@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.

-
@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 sagte in Werteabhängiges loggen per Skript:
Ohne Script wird das vermutlich nicht funktionieren, es sei denn jemand baut die Logik in History ein.
Deswegen ist der Thread ja jetzt unter Blockly
@andygr42 sagte in Werteabhängiges loggen per Skript:
Entweder unter einer bestimmten Last auf Null setzen
Mein Ansatz war die Ladung auf 0, wenn die Entladung startete, egal in welcher Höhe - und umgekehrt.
-
So, neuer Zwischenstand.
Habe jetzt das Blockly von @paul53 genommen, da es ja anscheinend alles in sehr kompakter Form enthielt, was ich wollte.
Wie nicht anders zu erwarten lief es auf Anhieb. Nach und nach habe ich es dann unter Beobachtung der Ergebnisse sogar verstanden!Dabei fiel mir dann auf, dassxes genau das machte, warum ich nicht mit voriger Wert gearbeitet hatte. auch das abspeichern in der Variable scheint zu dem selben "Problem" zu führen.
Was in meiner Version zu breite Peaks gebracht hatte

(ggf. auch die träge Steuereung der Batterie??)ist jetzt nur noch einen Messwert breit

ACHTUNG! unterschiedliche Skalierung beachten.jetzt wollte ich irgendwie die Datenaufzeichnung auf die Zeit zwischen zwei Flanken einer größeren Änderung ausdehnen

leider ging das ganz schief

Ich weiß nicht ob es an der fortgeschrittenen Zeit liegt, jedenfalls finde ich keinen weiteren (?) Denkfehler mehr.
Habe noch lastPower auf den vorigen Wert und damit letzten hohen Betrag umgestellt.
Seitdem aber keine weiteren Leistungsspitzen mehr.
plätschert schön vor sich hin
-
So, neuer Zwischenstand.
Habe jetzt das Blockly von @paul53 genommen, da es ja anscheinend alles in sehr kompakter Form enthielt, was ich wollte.
Wie nicht anders zu erwarten lief es auf Anhieb. Nach und nach habe ich es dann unter Beobachtung der Ergebnisse sogar verstanden!Dabei fiel mir dann auf, dassxes genau das machte, warum ich nicht mit voriger Wert gearbeitet hatte. auch das abspeichern in der Variable scheint zu dem selben "Problem" zu führen.
Was in meiner Version zu breite Peaks gebracht hatte

(ggf. auch die träge Steuereung der Batterie??)ist jetzt nur noch einen Messwert breit

ACHTUNG! unterschiedliche Skalierung beachten.jetzt wollte ich irgendwie die Datenaufzeichnung auf die Zeit zwischen zwei Flanken einer größeren Änderung ausdehnen

leider ging das ganz schief

Ich weiß nicht ob es an der fortgeschrittenen Zeit liegt, jedenfalls finde ich keinen weiteren (?) Denkfehler mehr.
Habe noch lastPower auf den vorigen Wert und damit letzten hohen Betrag umgestellt.
Seitdem aber keine weiteren Leistungsspitzen mehr.
plätschert schön vor sich hin
-
@homoran
Im oberen mache-Zweig wird nur die Funktion aufgerufen, also wird der alte Wert vonlast_Powernoch mal geschrieben. Ist das so gewollt?
Aus welchem Grund hast Du es komplizierter gemacht?@paul53 sagte:
also wird der alte Wert von last_Power noch mal geschrieben. Ist das so gewollt?
Ja! (zumindest hielt ich es für die Lösung für das Problem):
In deiner Version wird auf Hohe Werteänderung geprüft. Das hat zur Folge dass nur ein Messwert zusätzlich/außerhalb der Mittelwertbildung protokolliert wird, egal wie lange dieser Verbrauch anhält.Das wollte ich durch den zusätzlichen Teil ändern.
Zumindest habe ich das Blockly so interpretiert, nachdem der Chart für mich das auch so darstellte.

