NEWS
Werteabhängiges loggen per Skript
-
@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. -
@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 nachdenkenAber 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
-
@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. -
@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.
-
So ist's besser:
-
@andygr42 Jetzt aber:
-
@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 -
@homoran
Im oberen mache-Zweig wird nur die Funktion aufgerufen, also wird der alte Wert vonlast_Power
noch 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.
-
@paul53
anscheinend habe ich dein Blockly doch noch nicht richtig verstanden.
Nachdem meine Modifikationen es noch schlimmer gemacht hatten, habe ich heute morgen auf dein Original zurück gestellt.Entgegen meiner Interpretation gestern abend scheinen doch nicht nur die Flanken der Spitzen (=Änderung des Betrags > 500W) zu detektieren.
Der erhöhte Level wird dauerhaft(?) geschrieben.Wo habe ich da den Denkfehler (gehabt)?
-
@homoran sagte: Das hat zur Folge dass nur ein Messwert zusätzlich/außerhalb der Mittelwertbildung protokolliert wird, egal wie lange dieser Verbrauch anhält.
Ein Messwert genügt, wenn die Dauer kleiner 2 Minuten ist. Dauert die abweichende Leistung länger als 2 Minuten, werden weitere Werte protokolliert.
-
@homoran sagte: auf dein Original zurück gestellt.
Korrektur: Habe das Leeren der Liste in die Funktion schreiben() verschoben, da es auch erfolgen muss, wenn aufgrund einer großen Leistungsänderung geschrieben und anschließend das Intervall gestartet wird.
-
@paul53 Danke!
werde ich anpassenläuft bisher wieder störungsfrei. Warum auch nicht.
-
@homoran sagte in Werteabhängiges loggen per Skript:
läuft bisher wieder störungsfrei.
das ist leider seit ein paar Tagen vorbei.
im log erscheint immer wieder
2023-03-06 12:40:32.248 - error: javascript.1 (203833) script.js.Victron.energy_logging_paul: TypeError: Reduce of empty array with no initial value 2023-03-06 12:40:32.248 - error: javascript.1 (203833) at Array.reduce () 2023-03-06 12:40:32.249 - error: javascript.1 (203833) at mathMean (script.js.Victron.energy_logging_paul:4:17) 2023-03-06 12:40:32.249 - error: javascript.1 (203833) at Object. (script.js.Victron.energy_logging_paul:39:33) 2023-03-06 12:40:32.249 - error: javascript.1 (203833) at Timeout._onTimeout (/opt/iobroker/node_modules/iobroker.javascript/lib/sandbox.js:2205:34) 2023-03-06 12:40:32.249 - error: javascript.1 (203833) at listOnTimeout (internal/timers.js:557:17) 2023-03-06 12:40:32.249 - error: javascript.1 (203833) at processTimers (internal/timers.js:500:7)
mal regelmäßig alle 2 Minuten, mal mit größeren, unregelmäßigen Pausen.
erst habe ich nur das Skript, dann auch die Instanz neu gestartet. Danach hat es immer wieder paar Stunden funktioniert (bis zu 24)Wenn ich den Fehler richtig verstehe ist eine leere Liste die Ursache.
Ich hab mir den Code jetzt paarmal angesehen, finde aber keine Konstellation, dass die Liste im laufenden Betrieb auch mal leer sein könnte.Wo kann ich weitersuchen?