E3DC Hauskraftwerk steuern

[jh537]

@arnod Habe ich natürlich noch nicht gemacht-sorry

[jh537]

Was besagen die beiden Werte? Welcher Zeitraum wird für den Abend verwendet?

[Georg Hermann]

@jh537

"Durch Charge-Control gesicherte":
kWh, die CC meint durch das intelligente Laden "gerettet" zu haben.

"Durchschnittsverbrauch Abend:"
Durchschnittliche kWh Eigenverbrauch von 0:00 Uhr bis 8:00 Uhr

[jh537]

@georg-hermann
Okay danke

[jans_ios]

@ArnoD
Hi, ich habe da mal wieder ein Phänomen Also - morgens wird "Batterie entladen stoppen 0W" gesetzt, sobald der PV-Ertrag den Hausverbrauch übersteigt, soweit gut. Schalte ich dann aber den Heizstab zur Warmwasser-Generierung ein, der sowohl für das Skript als auch den E3DC nur ein Stromverbraucher ist, wird das Batterie-Entladen nicht wieder aktiviert und die 3KW werden aus dem Netz gezogen. Starte ich das Skript bei aktiviertem Heizstab neu, entlädt sich der Akku weiter, bis erneut die Situation PV-Ertrag>Hausverbrauch eintritt.

Kann man da was ändern? Wenn mein Akku morgens noch halb voll ist, würde ich den Strom bei Bedarf gerne zu Warmwasser machen und den Kessel auslassen.

Danke!

[jh537]

Aber ist auch nicht weiter wichtig.

[jh537]

Was ist denn 0_userdata.0.Charge_Control.Allgemein.Autonomiezeit. Die schwankt sekündlich zwischen 400 und 1000 Stunden?

Hatte den Fehler:

You are assigning a string to the state "0_userdata.0.Charge_Control.Allgemein.Autonomiezeit" which expects a number. Please fix your code to use a number or change the state type to string. This warning might become an error in future versions.

Habe es auf String geändert, nun ist der Fehler weg aber die Werte sind sehr hoch???

[jh537]

@jh537 Wenn nichts aus der Batt gezogen wird, hält sie ewig, deshalb der hohe Wert. Entscheidend ist der Wert wenn die Batt geleert wird-nach der Beschreibung.

[ArnoD]

@jans_ios sagte in E3DC Hauskraftwerk steuern:

Also - morgens wird "Batterie entladen stoppen 0W" gesetzt, sobald der PV-Ertrag den Hausverbrauch übersteigt, soweit gut.

Verstehe ich das richtig?
Wenn am Morgen, also vor Regelbeginn das Laden der Batterie verhindert wird, und dann ein Verbraucher zu einem Entladen der Batterie führen würde, wird nicht auf Entladen umgeschaltet?

Das muss ich mir mal ansehen, ist eigentlich nicht so gedacht

[ArnoD]

@jh537 sagte in E3DC Hauskraftwerk steuern:

Habe es auf String geändert, nun ist der Fehler weg aber die Werte sind sehr hoch???

Habe es bei mir gerade geprüft, die Objekt ID 0_userdata.0.Charge_Control.Allgemein.Autonomiezeitwird als string angelegt.
Kann aber sein, dass es in einer vorherigen Version mal als number deklariert wurde.

Wenn nichts aus der Batt gezogen wird, hält sie ewig, deshalb der hohe Wert. Entscheidend ist der Wert wenn die Batt geleert wird-nach der Beschreibung.

Richtig. In der VIS wird der Wert deswegen nur beim Entladen der Batterie angezeigt und beim Laden ausgeblendet.

[jans_ios]

@arnod
Ja, genau den Effekt habe ich hier. Der Witz ist - starte ich das Skript einmal neu, läuft es ab dann sauber…

[nerg]

@arnod ich habe heute das erste Mal einen Tag wieder wo das Skript wirklich regeln müsste. Aber es bleibt rot. Phänomen bleibt gleich.

// Es scheint so, als würde er - wenn er einmal die Kontrolle hat - diese auch behalten. Als würde er aber den Einstieg verpassen.
Er hat die Kontrolle aber übernommen, nachdem ich das Skript neu gestartet hab (sonst nichts)

/// Hab auch Mal nach eurem zweiten Phänomen geschaut, ob ich das nachstellen kann. Zumindest jetzt nach dem restart läuft es sauber (vorher hat er aber ja eh nichts gemacht)

//// 3. Nachtrag: nun nach circa 30-40 Minuten ist die Kontrolle wieder weg.

[ArnoD]

@nerg
Fangen wir mal von vorne an.
Das Script läuft und beim Start vom Script werden die Wetterdaten abgeholt und das ist im LOG ersichtlich?
Der Adapter e3dc-rscp läuft und hat auch beim Start keine Fehlermeldungen im LOG?

Das Script schreibt (nur wenn auch ausreichend PV-Leistung vorhanden ist) alle 5 sek. Werte in die Objekt ID e3dc-rscp.0.EMS.SET_POWER_VALUE und es wird dann trotzdem unter e3dc-rscp.0.EMS.STATUS_7false angezeigt ?

Wenn die Objekt ID e3dc-rscp.0.EMS.SET_POWER_VALUE sich nicht alle 5 sek. ändert, wird vom Script gerade in die Regelung nicht eingegriffen oder das Script läuft nicht.
Das Script hat nicht dauernd die Kontrolle über die Regelung, sondern nur, wenn die Ladeleistung begrenzt werden muss oder die Notstromreserve erreicht ist oder das Laden vor Regelbeginn verhindert werden soll usw.

Du kannst ja mal Bilder von deinen Einstellungen hier schicken, dann kann ich mal sehen, ob diese schon mal in Ordnung sind.

Dein Bild ist aber ein gutes Beispiel, wo gerade NICHT geregelt wird:
PV-Leistung 3456 W Hausverbrauch 5591W bedeutet das nichts zum Laden übrig ist und die Batterie entladen werden muss. Da greift das Script nicht ein, da das E3DC besser kann.

[ArnoD]

@jans_ios
kannst du mir mal ein LOG File schicken, wo es gerade nicht funktioniert und dann mit Neustart funktioniert?
Kann auf den ersten Blick keinen Fehler finden, eigentlich sollte das Entladen der Batterie immer möglich sein außer die Notstromgrenze ist erreicht.
Kann es im Moment auch bei mir nicht nachstellen, da das Wetter leider nicht mitspielt.

Nachtrag: Kannst du mir sagen wie der Batterie SOC in dem Moment war und was du bei Unload ,Ladeschwelle und unterer Ladekorridor eingestellt hattest?

[nerg]

@arnod
Danke schon mal für deine Unterstützung!

Gerne der Reihe nach:
RSCP startet problemlos und besorgt fröhlich Daten.

Das Skript lädt auch sauber durch und bestimmt die Einstellung. Heute war es 2, was auch den Werten entspricht. Er hat heute morgen auch die 2 sauber ermittelt, aber nicht die Kontrolle über den E3DC übernommen. Er hat nicht entladen bzw. später das Laden des Akkus verhindert. Ich habe dann das Skript neugestartet und sofort wurde alles eingespeist. Das hat ca. eine halbe Stunde sauber funktioniert.
Irgendwann hört er aber auf den E3DC zu kontrollieren. Ich muss gestehen, dass ich noch nicht auf die Idee gekommen bin zu schauen, ob er in den RSCP Adapter schreibt. Das hole ich Morgen nach. Das sollte ja nochmal die 2 kommen
Ich konnte aebr selbst im erweiterten Logging erst mal nichts sehen, warum er die Kontrolle aufgibt. Ich muss da mal dran bleiben und vielleicht auch den RSCP auf debug stellen.
Ich hab das Skript übrigens nicht neu, letztes Jahr lief es problemlos die Saison durch. Dieses Jahr nicht mehr. Ich hab deshalb als erstes nur erstmal alles aktualisiert. Nun gehen mir halt langsam leider die Ideen aus wie ich selbst das Problem in den Griff kriege und ich freue mich, dass du so engagiert unterstützt!
Ich gehe schon davon aus, dass das Problem bei mir ist, sonst wären ja mehr Leute hier. Aber ... ich find es nicht

Zum Screenshot: ja das ist mir schon klar Das war ja zu der Zeit , wo er verhindert hat , dass der Akku geladen wird - und wenn ich das Problem von jans_ios richtig verstanden habe konnte er in diesem Zeitraum ja bei Bedarf nicht auf den Akku zugreifen. Daher hab ich das mal nachgestellt, da ich eh grad dran war.

// ich habe mal den gesamten Objektbaum gelöscht und neu initialisiert. Vielleicht war ja da irgendwo Grütze drin.

[ArnoD]

@nerg
Ok das es schon ein Jahr funktioniert hat, ist schon mal eine wichtige Information
Was steht den im LOG File?
Wenn aus dem LOG File hervorgeht, dass alle 5 sek. ein Wert an den e3dc-rscp Adapter geschickt wird, dann würde ich erstmal dort prüfen, ob diese Werte auch eingetragen werden.
Wenn das der Fall ist, würde ich den e3dc-rscp Adapter auf debug stellen und prüfen, ob die Übertragung zum E3DC über die rscp Schnittstelle auch funktioniert.
Wenn das auch funktioniert, kann es immer noch am Netzwerk liegen, dass es da sporadische Verbindungsprobleme gibt.
Aber das würde dann auch im LOG stehen.

[nerg]

@arnod es muss irgendwas in den Datenpunkten gewesen sein. Nachdem ich den Baum gelöscht hab gestern Abend und alles neu eingetragen habe, läuft er heute wie ein Kätzchen.
Sorry für die Umstände und ganz lieben Dank für die Unterstützung

[jans_ios]

@ArnoD
Ich glaube, ich habe MEINEN Fehler gefunden - ich muss noch testen, das scheint aber nicht auf Dein Sktipt zurückzuführen zu sein.

Viele Grüße, Jan

[grori]

@jans_ios
Kannst du genauer darauf eingehen was du als Fehler vermutest? Ich habe nämlich ein ähnliches Problem, allerdings bereits nachmittags/abends und nicht erst morgens.

@ArnoD
Vielleicht kannst du mal in mein Logfile schauen ob du eine Idee hast wo das Problem liegt.

Wenn das Sommerladeende (gestern 18:32:57) überschritten wird und der SOC bis dahin den Wert von Ladeende2 erreicht hat wird die Regelung erst mal E3DC überlassen, aber einige Zeit später (gestern waren es knapp 26 Minuten) wird "Batterie entladen stoppen 0W. Schritt = 4 LadenStoppen = true" gesetzt. Zwischendurch toggelt das Skript noch ein paar mal zwischen den zwei Werten (gegen 19:30 Uhr), bleibt dann aber bei "Batterie entladen stoppen" bis ich um 20:28 Uhr das Skript neu gestartet habe. Erst ab diesem Zeitpunkt wird die Batterie dann entladen.

Vorletzte Nacht hatte ich das gleiche Problem, habe es aber erst gestern Morgen festgestellt, deswegen startet das Logfile mit dem Neustart des Skriptes um 6:19 Uhr

iobroker.2023-05-14.log.gz.txt

[stiwy18]

Hi Arno,
ich habe folgenden Fehler, eben wurde das Elektroauto angesteckt, aber das Skript stoppt die Entladung aus der Akku. Stoppe ich das Skript, wird Strom aus dem Akku bezogen.

Anbei die Debugausgabe des Skripts, vielleich hast du eine Idee, was da los ist.
E3DC Control.txt

VG
Stefan