E3DC Hauskraftwerk steuern

[ChrisChros]

@arnod nicht das ich wüsste.
Was ich aber gemacht habe, als mit aufgefallen ist das die Werte nicht stimmen, ist das Objekt

0_userdata.0.E3DC-Control.Allgemein.IstPvErtragLM0_kWh

händisch mit dem Wert aus dem E3DC-Portal zu überschreiben.

[ChrisChros]

@arnod So gestern war alles gut und heute schon wieder viel zu viel gezählt worden.
Ich habe keine Änderungen zu gestern vorgenommen, der Raspberry oder das Skript wurden nicht neu gestartet.
Ich lasse jetzt das Objekt "0_userdata.0.E3DC-Control.Allgemein.IstPvErtragLM0_kWh" in die History schreiben, eventuell kann man das was erkennen.

Skript: 127,50 kWh
E3DC: 62,71 kWh

Durch das zu viel zählen stellt das Skript automatisch auf Einstellung 1 um wodurch natürlich der Akku auf 100% SOC geladen wird, was er ja eigentlich nicht sollte.

UPDATE:
17:03 = 126,57 kWh
17:33 = 132,16 kWh

also irgendwie wird da falsch gezählt. Kann mir nicht vorstellen das ich mit meiner 16,16 kWp Anlage am späten Nachmittag innerhalb einer halben Stunde 5,5 kWh produziere.

[ArnoD]

@chrischros
Welche Version hast du bei dir am Laufen?

Ist bei dir am Ende vom Skript bereits diese Funktion vorhanden?

//Bei Scriptende alle Timer löschen
onStop(function () { 
        clearSchedule(Timer0);
        clearSchedule(Timer1);
        clearSchedule(Timer2);
}, 100);

Prüf mal bitte ob der State 0_userdata.0.E3DC-Control.Allgemein.IstPvErtragLM0_kWh wirklich nur jede Minute aktualisiert wird.
Wenn das häufiger passiert, stimmt bei dir was mit dem Timer nicht.

[ChrisChros]

@arnod habe das Skript in der version 4.2.0 am laufen und darin ist die oben genannte Funktion schon enthalten.
Laut den History-Daten wir jede Minute 2 mal Werte geschrieben.

Welche Admin Version hast du am laufen?

[ArnoD]

@chrischros
Dann wurde der Timer0 zweimal gestartet.
Stoppe mal das Skript und warte eine Minute, bevor du es wieder startest.
Dann prüfe wieder, ob der State jede Minute aktualisiert wird.

[ArnoD]

@ChrisChros
Admin 6.2.4

[ChrisChros]

@arnod nach dem Neustart des Skripts wird nur noch einmal pro Minute ein Wert geschrieben.

Von der Admin-Version sind wir schon mal identisch, daran sollte es nicht liegen.

[ArnoD]

@chrischros
Das Problem sind die Timer, die nicht sauber bei Skript Abbruch beendet werden.
Dachte eigentlich das Problem gelöst zu haben mit der letzten Änderung, ist aber anscheinend nicht so.
Wenn man etwas wartet, bevor das Script wieder gestartet wird, werden auch die Timer beendet, warum das aber so ist konnte ich noch nicht herausfinden.

Eventuell hilf beim Skript Start noch mal mit clearSchedule(Timer0); die Timer zu beenden, falls das beim Beenden vom Skript nicht funktioniert hat.

[ChrisChros]

@arnod ich lass mal das Objekt weiter in die History schreiben, eventuell kann ich dann nachvollziehen wann der Timer wieder falsch läuft.

[ArnoD]

Habe eine neue Version Charge-Control auf GitHub hochgeladen.
Version: 1.0.8
Änderungen:
Wenn die Notstromreserve erreicht ist, wird auch DISCHARGE_START_POWER, MAX_CHARGE_POWER und MAX_DISCHARGE_POWER auf 0 gesetzt, damit der WR in den Standby-Modus wechselt und die Batterie nicht weiter entladen wird.
Aktualisierung des State SET_POWER_VALUE auf 5 sek. reduziert und kleinere Fehler behoben.

Habe das 8 Stunden getestet, ohne das sich die Batterie weiter entladen hat, müsste somit funktionieren.

[ArnoD]

@chrischros

Versuch mal diesen code vor den Funktion Bereich im Script einzufügen, sodass dieser beim Start vom Script durchlaufen wird:

const list = getSchedules(false);
list.forEach(schedule => log('-==== Schedule war noch aktiv und wurde beendet ===-'+JSON.stringify(schedule),'warn'));
list.forEach(schedule => clearSchedule(schedule));

Sollte beim Start vom Script ein Timer noch aktiv sein, wird eine Warnmeldung im LOG ausgegeben und der Timer beendet.
Wenn es funktioniert, kannst du folgende Zeile

list.forEach(schedule => log('-==== Schedule war noch aktiv und wurde beendet ===-'+JSON.stringify(schedule),'warn'));

wieder löschen, wenn die Warnmeldung im LOG nicht angezeigt werden soll.

[stiwy18]

@arnod
Und schon wieder etwas megaschnell eingebaut. Vielen Dank!

[ChrisChros]

@arnod wäre das so richtig?

//***************************************************************************************************
//**************************************** Function Bereich *****************************************
//***************************************************************************************************

const list = getSchedules(false);
list.forEach(schedule => log('-==== Schedule war noch aktiv und wurde beendet ===-'+JSON.stringify(schedule),'warn'));
list.forEach(schedule => clearSchedule(schedule));

async function main()
{
    //Prognosen in kWh umrechen
    await Prognosen_Berechnen();
    // Diagramm aktualisieren
    await makeJson();
    // Einstellungen 1-5 je nach Überschuss PV Leistung Wetterprognose und Bewölkung anwählen 
    Einstellung(await Ueberschuss_Prozent());

}

[ArnoD]

@chrischros
Ja, ist so in Ordnung.

[Zelkin]

@arnod
Bin echt begeistert
Das Script läuft super .... echt erstaunlich, dass man sowas nicht annähernd innerhalb des E3DC Systems bekommt

Weil ihr es grad von den Leistungsmessern habt, bei mir im modbus wird der Leistungsmesser_6 L1 bis L3 verwendet, nicht 0!
Muss Ich hier im Script noch was anpassen bzw. wenn sich das je nach Installation ändert, kannst du hierfür ne Variable einbauen?

Derzeit verwende Ich 1.0.7

Ein seltsames Verhalten ist mir noch in Bezug auf den Effizienzwert aufgefallen!
Den hab Ich mitte Monat geändert
Das script scheint aber immer wieder den alten wert herangezogen zu haben:

anders kann Ich mir die Proplanta Prognose sonst nicht erklären!

Im Moment scheint er sich eingependelt zu haben, mich wundert hierbei nur das hin und her.
Es hat sich auch so verhalten, dass beim Neustart des scripts die in Zukunft liegenden Tage korrekt angezeigt wurden (z.B. um den 20. rum) und irgendwann wieder nach oben gesprungen sind

[ArnoD]

@zelkin sagte in E3DC Hauskraftwerk steuern:

Weil ihr es grad von den Leistungsmessern habt, bei mir im modbus wird der Leistungsmesser_6 L1 bis L3 verwendet, nicht 0!
Muss Ich hier im Script noch was anpassen bzw. wenn sich das je nach Installation ändert, kannst du hierfür ne Variable einbauen?

Nein, du musst nichts ändern.
Das Script verwendet die ID modbus.0.holdingRegisters.40068_PV_Leistung und modbus.0.holdingRegisters.40076_Zusaetzliche_Einspeiser_Leistung, um die PV-Leistung zu berechnen.

Ein seltsames Verhalten ist mir noch in Bezug auf den Effizienzwert aufgefallen!
Den hab Ich mitte Monat geändert

Welchen Wert meinst du da? Die Einstellung, mit welcher Prognose gerechnet werden soll?

[ArnoD]

@zelkin

In deiner View fehlt die Object ID zu den State, für welche Tage die Prognose Proplante abgerufen wurde:

Sollte so aussehen:

Die Object ID ist 0_userdata.0.Charge_Control.Proplanta.Datum_Tag_0 bis 3

[Zelkin]

@arnod

Prognose ist nachgetragen ... die "null" sind mir noch gar nicht aufgefallen

Es ging um den effizienzwert der Paneele

const nWirkungsgradModule = 21.1;                 // Wirkungsgrad / Effizienzgrad der Solarmodule in % bezogen auf die Globalstrahlung (aktuelle Module haben max. 24 %)

Den hatte Ich anfangs Fälschlicherweise auf 98% weil Ich den Wert Falsch verstanden hatte

[ArnoD]

@zelkin
Wenn der Wert jetzt richtig eingetragen ist, wird auch nur dieser verwendet, da der Alte nirgends gespeichert ist.
Was steht den im LOG für einen Prognosewert Proplanta ?

[Zelkin]

@arnod
in welchem log sollte Ich das jetzt checken??