Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Homoran]

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

[AndyGR42]

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

[AndyGR42]

@homoran So, ich hab es nochmal für mehrere DP in einem Script optimiert. Und dabei gelernt, dass man einen Trigger nicht in einer Funktion erstellen kann / sollte. Schade, aber auch irgendwie logisch.

Um die Komplexität nicht noch weiter zu erhöhen, benutzen alle DP die gleichen Vorgaben für Array Länge und Update Frequenz. Bei sehr vielen DP müsste man, allein der Übersichtlichkeit wegen, eh mehrere Skripte bauen.

Um die Anzahl globaler Variablen zu verringern, speichert das Skript einige Laufzeitdaten als DP. Um beim Neustart des Skripts fehlerhafte Mittelwerte auf Grund von veralteten Daten im Array zu verhindern, kann das Array optional beim Start zurückgesetzt werden. Wenn nicht benötigt die Zeilen einfach löschen oder auskommentieren.

Der Block mit dem Trigger kann beliebig per Copy & Paste vervielfältigt werden. Es müssen dann entsprechend die Pfade zu den DP angepasst werden.

/** global history array length and update frequency for ALL DP in this script */
/** the array length MUST be an integer multiple of the update frequency */

const inputArrayLength = 5;
const updateFrequency = 5;

/** reset input arrays if required */

resetInputArray('0_userdata.0.Test.TestArray01');
resetInputArray('0_userdata.0.Test.TestArray02');

/** Triggers */

on({id: '0_userdata.0.IoT.DaylightSensor.DayLight01', change: "any"}, function (obj) { /** Daylight Sensor 01 */
    var value = obj.state.val;

    const historyDP = '0_userdata.0.Test.Test01';
    const updateFrequencyCounterDP = '0_userdata.0.Test.TestCounter01';
    const inputArrayDP = '0_userdata.0.Test.TestArray01';

    updateHistory(value, historyDP, updateFrequencyCounterDP, inputArrayDP);
});

on({id: '0_userdata.0.IoT.DaylightSensor.DayLight02', change: "any"}, function (obj) { /** Daylight Sensor 02 */
    var value = obj.state.val;

    const historyDP = '0_userdata.0.Test.Test02';
    const updateFrequencyCounterDP = '0_userdata.0.Test.TestCounter02';
    const inputArrayDP = '0_userdata.0.Test.TestArray02';

    updateHistory(value, historyDP, updateFrequencyCounterDP, inputArrayDP);
});


/** nothing to chage below this line */
/** ------------------------------------------------------------------------------------------------------------------------ */

function updateHistory(value, historyDP, updateFrequencyCounterDP, inputArrayDP)
{
    let inputArray = new Array(inputArrayLength);
    var updateFrequencyCounter = getState(updateFrequencyCounterDP).val;
    inputArray = getState(inputArrayDP).val;

    updateArray(value,inputArray) /** shift and update input array */
    var index = inputArray.indexOf(-1);

    if (updateFrequencyCounter <= 1 && index == -1) /** update history DP when update cycle is reached */
    {
        var sum = inputArray.reduce((a, b) => a + b, 0); /** calculate average from the array */
        var avg = (sum / inputArray.length) || 0;
        
        setState(historyDP, Number(avg)); /** write history DP */
        updateFrequencyCounter = updateFrequency; /** reset update counter */
    }
    else
    {
        updateFrequencyCounter--; /** count down until next update */
    }

    setState(inputArrayDP, inputArray); /** save input array */
    setState(updateFrequencyCounterDP, updateFrequencyCounter); /** save update counter */
}

/** helper functions */

function updateArray(newValue, array) /** shift and update the array */
{
    var i;

    for (i = inputArrayLength - 1; i >= 0; i--) 
    {
        if (i > 0)
        {
           array[i] = array[i - 1];
        }
        else
        {
            array[i] = newValue;
        }
    }
    return array;
}

function resetInputArray(inputArrayDP) /** reset input array */
{
    let inputArray = new Array(inputArrayLength);
    //inputArray = getState(inputArrayDP).val;
    var i;

    for (i = 0; i < inputArrayLength; i++)
    {
    
        inputArray[i] = -1;
    }
    setState(inputArrayDP, inputArray);
}

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