Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[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:

[AndyGR42]

@andygr42 Jetzt aber:

[Homoran]

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

[Homoran]

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

[paul53]

@homoran
Im oberen mache-Zweig wird nur die Funktion aufgerufen, also wird der alte Wert von last_Power noch mal geschrieben. Ist das so gewollt?
Aus welchem Grund hast Du es komplizierter gemacht?

[Homoran]

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

[Homoran]

@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)?

[paul53]

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

[paul53]

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

[Homoran]

@paul53 Danke!
werde ich anpassen

läuft bisher wieder störungsfrei. Warum auch nicht.

[Homoran]

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

[paul53]

@homoran sagte: Wo kann ich weitersuchen?

Reduce wird nur bei der Mittelwertbildung benutzt. Danach wird die Liste beim Schreiben gelöscht. Wird nicht oft genug getriggert, damit die Liste innerhalb von 2 Minuten wieder Werte enthält? Wenn das der Fall sein kann, ergänze innerhalb des Intervalls um die Abfrage "falls Länge von Liste > 0".

[Homoran]

@paul53 sagte:

Wird nicht oft genug getriggert, damit die Liste innerhalb von 2 Minuten wieder Werte enthält?

das wäre im Moment möglich, da die Batterie ziemlich leer ist und von der Steuerung das Entladen deaktiviert wurde.
Das passt auch zum Zeitrahmen

@paul53 sagte in Werteabhängiges loggen per Skript:

ergänze innerhalb des Intervalls um die Abfrage "falls Länge von Liste > 0".

werde ich machen!
Danke!