UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[stiwy18]

Hallo Arno,

wahrscheinlich fällt mir das dann erst auf seit dem niedrigen Verbrauch. :blush:
Ich hab die 1.0.12 installiert und melde mich wieder, wie es sich jetzt verhält.

Danke!
Stefan

[TbsJah]

@arnod ab wann wird der Unload getriggert?
Änderungen in der VIS oder direkt im Parameter haben keine Auswirkung.

Wenn ich es richtig verstehe müsste bei dem Beginn der Regelung zuerst entladen werden auf den angegebenen Wert
Eingegeben habe ich 30% Unload. Das scheint aber nicht zu greifen.

[stephan61]

Hallo Arno
habe nach Umzug auf neuen Nuc von eba auf dein Programm umgestellt
läuft soweit sehr gut.
In der Vis prognose sind oben beim Datum noch der der verweis auf 0 Userdata E3Dc Control
statt auf Charge control.
Frage du nimmst die Werte von Modbus die Werte sind doch auch in E3dc Rscp hat das einen Grund?
dann bräuchte ich Modbus nicht mehr

Gruß Stephan

[ArnoD]

@tbsjah sagte in E3DC Hauskraftwerk steuern:

@arnod ab wann wird der Unload getriggert?
Änderungen in der VIS oder direkt im Parameter haben keine Auswirkung.

Wenn ich es richtig verstehe müsste bei dem Beginn der Regelung zuerst entladen werden auf den angegebenen Wert
Eingegeben habe ich 30% Unload. Das scheint aber nicht zu greifen.

Wenn die Ladeschwelle höher ist als Unload, wird Unload ignoriert, oder auch wenn der Notstrom SOC erreicht wurde.
Was ist denn bei Ladeschwelle eingestellt?

[TbsJah]

@arnod
Ladschwelle waren 50% - habe es auf den selben Wert vom Unload gesetzt

Hatte es so verstanden, dass auf Unload Wert entladen wird. Dann auf Ladeschwelle ohne und ab Erreichen der Ladschwelle
mit Reglung geladen wird

Danke für deine Korrektur

[ArnoD]

@stephan61 sagte in E3DC Hauskraftwerk steuern:

In der Vis prognose sind oben beim Datum noch der der verweis auf 0 Userdata E3Dc Control
statt auf Charge control.

Stimmt, hatte das zwar bei mir korrigiert, aber dann nicht mehr auf GitHub hochgeladen.
Danke für den Hinweis.

Frage du nimmst die Werte von Modbus die Werte sind doch auch in E3dc Rscp hat das einen Grund?

Wenn du beim e3dc-rscp Adapter zu viele Werte das Abfrageintervall auf S=kurz einstellst und du das Abfrageintervall auf 2 sek. einstellst (was man zum Steuern mindestens benötigt), dann geht die CPU Last nach oben.
Das ging bei mir sogar so weit, dass der iobroker nicht mehr reagierte. Hängt natürlich von der Ausstattung des Systems ab, welches man einsetzt.
Beim Modbus Adapter habe ich ein Abfrageintervall von 1,5 sek. ohne dass die Auslastung der CPU merklich ansteigt.
Wenn jemand weiß, woran das liegt oder was man am e3dc-rscp Adapter anders programmieren muss, damit das funktioniert, würde Uli sich sicher über Unterstützung freuen.

[ArnoD]

@tbsjah
Die Logik von Eba ist mir bei der Thematik nicht klar, warum er das so programmiert hat.
Wenn ich mit der Ladeschwelle erreichen will, dass mein Speicher immer bis zu einem bestimmten Wert geladen wird, ist es doch nicht logisch diesen vorher auf einen niedrigeren Wert zu entladen.
Da lass ich doch den Speicher auf dem Wert Ladeschwelle und warte mit der Regelung bis Start Regelbeginn.
Wenn ich mehr Puffer für den Überschuss benötige, muss ich auch die Ladeschwelle niedriger setzen, sonst würde die Batterie mit max. möglicher PV-Leistung vor Start Regelzeitraum wieder geladen und mein Puffer ist somit wieder weg.
Kann aber auch sein das ich da was übersehe oder einfach nicht verstehe.

[stephan61]

@arnod
habe Abfrage Intervall S auf 1 sec gestellt kein Veränderung an CPU Last
habe die Modbus Werte mal auf E3dc rscp geändert ,
Mal sehen was passiert
Gruß Stephan

[Basti97]

@arnod Wie misst du die Eingasspannug des Wechselrichters bzw Ausgangsspannung der Module?

[ArnoD]

@basti97
Bin mir nicht sicher, ob ich dich richtig verstehe, die Spannung und Strom der einzelnen Strings erhalte ich über den Modbus Adapter.

[stiwy18]

Guten Morgen Arno,

ich verstehe gerade nicht, warum die Ladesteuerung nicht gestartet wurde:

Hier siehst du er lädt fleißig:

Im Log steht Ladesteuerung gestoppt:

Und noch eine Frage, ein paar Beiträge weiter oben schreibst du die Unload Funktion von Eba hast du noch nicht verstanden, heisst das der Wert Unload führt aktuell nichts bei dir aus?

Viele Grüße
Stefan

[ArnoD]

@stiwy18
Im LOG siehst du das er gerne mit 242W laden würde, da du aber den unteren Ladekorridor auf 350 W eingestellt hast, wird er mit der Regelung warten bis die 350 W erreicht sind und erst dann laden.
Was nicht passt ist das die Ladesteuerung gestoppt wurde, eigentlich sollte nicht geladen werden.
Das muss ich mir noch mal genauer ansehen.

Und noch eine Frage, ein paar Beiträge weiter oben schreibst du die Unload Funktion von Eba hast du noch nicht verstanden, heisst das der Wert Unload führt aktuell nichts bei dir aus?

Ich habe die Unload Funktion nur anders umgesetzt als Eba, bei mir wird Unload ignoriert, wenn die Ladeschwelle >= Unload ist. Wenn das nicht der Fall ist, wird mit Beginn Solarleistung bis auf Unload in das Netz entladen.

[ArnoD]

@stiwy18
Ich habe mir das jetzt noch mal angesehen und das Problem entsteht eigentlich durch den frühen Regelbeginn bei dir.
Da die Steuerung über den e3dc-rscp Adapter und Script etwas träge ist, stoppt das Script die Regelung, wenn nur noch 500W zum Einspeisen oder Laden übrig bleiben. Damit verhindere ich, dass bei starken Leistungswechsel ständig aus dem Netz bezogen wird.
In deinem Fall hast du 649 W PV-Leistung und 348 W Hausverbrauch und somit bleiben nur noch 300W übrig und das ist eben unter 500W.

Ich will das aber erstmal auch nicht ändern, da die Nachteile, nämlich der Netzbezug für mich gravierender sind.

Die einfache Lösung ist, deine Einstellung zu ändern und somit erst um 12:11 Uhr mit der Regelung zu starten. Du wirst ja auch nie um 8:48 Uhr bereits so viel Überschuss erreichen, dass du die Einspeisegrenze überschreitest.
Nach deinem Diagramm weiter oben ist die kritische Zeit bei dir von ca. 12:30 Uhr bis 18:00 Uhr.
Versuch mal folgende Einstellungen:
Winter Minimum = 13
Sommer Maximum = 16.5
Sommer Ladeende = 18
Ladeschwelle würde ich auf den SOC setzen, den ich mindestens benötige, um über die Nacht zu kommen und noch ausreichend Reserve für Notstrom zu haben.
Wenn du 50% in der Batterie hast, ist diese dann am nächsten Tag auf 20% ? wenn nicht, würde ich auch mit diesem Wert weiter runtergehen.

[ArnoD]

Habe eine neue Version Charge-Control auf GitHub hochgeladen.
Version: 1.0.13
Änderungen:

• Prognose von Proplanta wird jetzt auch für die nächsten 6 Tage abgerufen.

[stiwy18]

@arnod
Guten Morgen Arno,
vielen Dank für die Erklärung, sowohl der 500 Watt als auch der Unloadfunktion :-)

Eins ist mir gestern noch aufgefallen (einfach ignorieren, wenn es zu viele Fragen sind : )
Eba hat (wenn ich mich richtige erinnere) wenn der SOC über dem Ziel-Sollwert ist, wieder entladen, sobald der die Einspeisegrenze dies erlaubt hat, damit wieder „Puffer“ für Überschuss frei ist, macht das Charge-Control auch?

Danke und viele Grüße,
Stefan

[ArnoD]

@stiwy18
Nein, wofür wäre das den gut?
Man kann mit Unload den Speicher vor der Regelung entladen, sodass ausreichend Platz ist.

[stiwy18]

@arnod Mir ist das aufgefallen, als gestern die Prognose den Modus „12-18 Uhr bewölkt“ verwendet hat, aber dann doch der Sonnenschein ganztags da war.
Der Akku wurde schneller vollgeladen und wegen dem Überschuss am Nachmittag wurde der Akku früh auf 100% geladen, die bewölkte Stunde hat er dann nicht zum entladen verwendet.

Der Fall tritt sehr selten auf, aber kommt vor :-)

Viele Grüße
Stefan

[stiwy18]

@arnod
Guten Morgen Arno,

ich hab die Version eingespielt, von Proplanta bekomme ich jetzt komische Werte, auf der Proplanta:

Im Log finde ich eine Fehlermeldung, evtl. hängt es damit zusammen:
2022-08-14 00:50:00.010 - info: javascript.0 (611) script.js.Charge-Control: ******************* Es wird die Globalstrahlung ab Tag 0 von Proplanta abgerufen *******************
2022-08-14 00:50:00.576 - info: javascript.0 (611) script.js.Charge-Control: Rueckmeldung InterrogateProplanta XHR.Status= 200
2022-08-14 00:50:00.580 - error: javascript.0 (611) script.js.Charge-Control: TypeError: Cannot read properties of undefined (reading 'slice')
2022-08-14 00:50:00.580 - error: javascript.0 (611) at script.js.Charge-Control:1164:115
2022-08-14 00:50:00.580 - error: javascript.0 (611) at runMicrotasks ()
2022-08-14 00:50:00.580 - error: javascript.0 (611) at processTicksAndRejections (node:internal/process/task_queues:96:5)
2022-08-1404:00:00.001 - info: javascript.0 (611) script.js.Charge-Control: ****************************** Es wird Solcast Dach 1 abgerufen ******************************
2022-08-14 04:00:01.969 - info: javascript.0 (611) script.js.Charge-Control: Rueckmeldung XHR.Status Solcast= 200
2022-08-14 04:00:01.969 - info: javascript.0 (611) script.js.Charge-Control: Summe PV Leistung Tag 2022-08-14 pv_estimate= 45.73 pv_estimate90= 45.99
2022-08-14 04:00:01.969 - info: javascript.0 (611) script.js.Charge-Control: Summe PV Leistung Tag 2022-08-15 pv_estimate= 29.53 pv_estimate90= 44.47
2022-08-14 04:00:01.969 - info: javascript.0 (611) script.js.Charge-Control: Summe PV Leistung Tag 2022-08-16 pv_estimate= 43.83 pv_estimate90= 44.6
2022-08-14 04:00:01.969 - info: javascript.0 (611) script.js.Charge-Control: Summe PV Leistung Tag 2022-08-17 pv_estimate= 38.62 pv_estimate90= 42.87
2022-08-14 04:00:01.969 - info: javascript.0 (611) script.js.Charge-Control: Summe PV Leistung Tag 2022-08-18 pv_estimate= 25.47 pv_estimate90= 45.33
2022-08-14 04:00:01.970 - info: javascript.0 (611) script.js.Charge-Control: Summe PV Leistung Tag 2022-08-19 pv_estimate= 18.31 pv_estimate90= 45.03
2022-08-14 04:00:01.970 - info: javascript.0 (611) script.js.Charge-Control: Summe PV Leistung Tag 2022-08-20 pv_estimate= 26.76 pv_estimate90= 46.78
2022-08-14 04:00:02.020 - info: javascript.0 (611) script.js.Charge-Control: Prognose Solcast in kWh = 40.3
2022-08-14 04:00:02.020 - info: javascript.0 (611) script.js.Charge-Control: Prognose Solcast 90 Perzentil in kWh = 45.99
2022-08-14 04:00:02.020 - info: javascript.0 (611) script.js.Charge-Control: Prognose Proplanta in kWh = 681.8448000000001
2022-08-14 04:00:02.020 - info: javascript.0 (611) script.js.Charge-Control: Prognose_kWh nach Abzug Korrekturfaktor = 36.269999999999996
2022-08-14 04:00:02.020 - info: javascript.0 (611) script.js.Charge-Control: Bereits produzierte PV-Leistung = 0
2022-08-14 04:00:02.066 - info: javascript.0 (611) script.js.Charge-Control: Prognose_kWh_heute für Berechnung = 36.269999999999996
2022-08-14 04:00:02.170 - info: javascript.0 (611) script.js.Charge-Control: BatterieProzent(wert)=17.969999999999995
2022-08-14 04:00:02.170 - info: javascript.0 (611) script.js.Charge-Control: Eigenverbrauch Tag = 15
2022-08-14 04:00:02.170 - info: javascript.0 (611) script.js.Charge-Control: AktSpeicherSoC in % = 70
2022-08-14 04:00:02.170 - info: javascript.0 (611) script.js.Charge-Control: Ueberschuss in kWh 17.969999999999995 = (Prognose kWh 36.269999999999996 - Berechneter Eigenverbrauch 15) - FreieKapBatterie_kWh 3.3
2022-08-14 04:00:02.170 - info: javascript.0 (611) script.js.Charge-Control: Ueberschuss in Prozent = 100
2022-08-14 04:00:02.214 - info: javascript.0 (611) script.js.Charge-Control: Bewölkungsgrad 12 Uhr Proplanta 200
2022-08-14 04:00:02.214 - info: javascript.0 (611) script.js.Charge-Control: Bewölkungsgrad 15 Uhr Proplanta 200
2022-08-14 04:00:02.214 - warn: javascript.0 (611) script.js.Charge-Control: -==== Bewölkungsgrad_12 oder Bewölkungsgrad_15 wurde nicht abgerufen. 12=200 15=200 ====-

Viele Grüße und Danke
Stefan

[ArnoD]

@stiwy18
Habe ich heute bei mir auch festgestellt.
Wenn ich das Script aber neu starte, funktioniert alles normal.
Bin aber dabei, den Fehler zu finden.

[ArnoD]

Habe eine neue Version Charge-Control auf GitHub hochgeladen.
Version: 1.0.15
Änderungen:

• Fehler, dass beim Abrufen der Wetterdaten Proplanta über Timer die falsche URL verwendet wurde, behoben.
• Kleinere Script Optimierungen durchgeführt.