NEWS
E3DC Hauskraftwerk steuern
-
@arnod
Ja, genau den Effekt habe ich hier. Der Witz ist - starte ich das Skript einmal neu, läuft es ab dann sauber… -
@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.
-
@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 untere3dc-rscp.0.EMS.STATUS_7
false 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. -
@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?
-
@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 nichtZum 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.
-
@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. -
@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 -
@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
-
@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
-
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.txtVG
Stefan -
@grori
Ich habe im Skript den Datenpunkt für den Hausverbrauch ersetzt durch einen errechneten Hausverbrauch - der Heizstab erhöht den eigentlichen Hausverbrauch ja und er hätte so Priorität. Ich möchte, dass das Skript den Hausverbrauch ohne den des Heizstabs sieht und verwendet, also lasse ich in einem kleinen Skript immer bei Veränderung des E3DC-Hausverbrauchs einen Datenpunkt schreiben ohne den aktuellen Energiebedarf des Heizstabs.Morgens sorgt das dann aber dafür, dass wenn der Heizstab vielleicht angehen MUSS, um eine gweisse Mindesttemperatur zu halten, der Stromverbrauch durch das Skript nicht wahrgenommen wird - es sieht ja nur den um den Stromverbrauch des Heizstabs korrigierten Hausverbrauch und dadurch erscheint ein Entladen unnötig.
Ich muss also nochmal tiefer einsteigen, an welcher Stelle ich welche Verbräuche nutze
-
-
@arnod
Erst mal guten Morgen und vielen Dank für die Bereitschaft das am Wochenende genauer zu analysieren. Bin schon auf deine Erkenntnisse gespannt!Hier das Diagramm aus dem E3DC-Portal für den Zeitraum für den ich auch das Log zur Verfügung gestellt habe.
An dem Tag war ebenso wie heute Einstellung 3 aktiv:
-
@grori
Im Diagramm kann man es nur schwer erkennen, aber bis ca. 20:10 Uhr ist deine PV-Leistung höher als der Eigenverbrauch und deine Batterie hat die eingestellten 95% erreicht, da hat das Script das Laden gestoppt, was ja auch richtig ist.
Von 20:03 Uhr bis 20:28 Uhr ist bei dir irgendwas passiert, was das Script anscheinend gestoppt hat.
Hast du da irgendein Update oder Backup durchgeführt?Um 20:28 wurde dann das Script manuell neu gestartet und ist dann normal weitergelaufen bzw. hat die Regelung E3DC überlassen.
Ich kann dir leider nicht sagen, was bei dir in den 25 min. passiert ist, das müsstest du herausfinden.
-
@stiwy18
Leider ist das LOG File sehr kurz.
Ich kann nur erkenne, dass du das Script dreimal hintereinander neu gestartet hast, warum auch immer.
Dann hat die Berechnung der Ladeleistung 66W ergeben, weil deine Batterie bereits zu 88% geladen ist und du bis 90% laden willst. Jetzt weiß ich aber nicht, was du beim unteren Ladekorridor eingestellt hast.
Vermute, dass dieser über 66 W ist und deswegen auch nicht mehr geladen wurde.War in dem Zeitraum 13:06 Uhr - 13:07 Uhr dein E-Auto angesteckt?
Hier wäre jetzt dein Diagramm interessant, wie der Hausverbrauch und die PV-Leistung zu dem Zeitpunkt war. -
Neue Version Charge-Control auf GitHub hochgeladen.
Version: 1.2.11
Änderungen:- Fehler behoben, dass nicht mehr auf entladen umgeschaltet wurde, nachdem das Laden der Batterie gesperrt war.
@stiwy18 bitte mal testen, ich prüfe jetzt jedes Mal, ob die PV-Leistung > als der Eigenverbrauch ist, wenn ich das Laden der Batterie stoppe.
-
@arnod
Erst mal vielen Dank für das Prüfen der Logs!Es hat allerdings keine Backups oder Updates in der genannten Zeit gegeben und heute hat es sich wieder sehr ähnlich verhalten. Wie im Diagramm zu sehen ist hat die Abnahme der PV-Leistung und das Anspringen der Wärmepumpe zwischen 19 Uhr und 19:15 Uhr zu einem Netzbezug geführt. Die Batterie wurde erneut nicht entladen bis ich um 20:17 Uhr das Skript neu gestartet habe.
Im Log (ich habe diesmal erst die Logs ab 17 Uhr angehängt, kann aber gerne auch noch den Rest schicken wenn das relevant sein sollte) sehe ich nach dem Sommerladeende um 18:05:51 Uhr wieder keine weiteren Einträge des Skripts. Die letzte aktion bevor das Skript aufhört war aber um 18:05:24 ein "Batterie entladen stoppen 0W". Und das scheint dann auch trotz fehlender weiterer Logeinträge das zu sei was mein S10 X umsetzt. Nach dem Neustart um 20:17 ist die letzte Meldung auch um 20:17:18 "Regelung E3DC überlassen" und danach sieht es aus als würde das Skript nicht mehr laufen, aber ich gehe davon aus es wird (wie die letzten Tage) morgens wieder wie gewohnt regeln.
In der folgenden Grafik ist noch zu sehen wann die Batterie wie stark ge- oder entladen wurde. Auch hier sieht man den Start des Entladens nach dem Sommerladeende (bis auch kurze Phasen die auch im Log ersichtlich sind) erst um 20:17 Uhr.
Was ich auch noch nicht ganz verstanden habe ist dein erster Satz:
"...deine Batterie hat die eingestellten 95% erreicht, da hat das Script das Laden gestoppt, was ja auch richtig ist."
Das verstehe ich soweit schon, aber wenn das Laden gestoppt wird sollte doch nicht auch das Entladen gestoppt werden, oder? In der Ausgabe des Skriptes steht ja auch "Batterie entladen stoppen 0W. Schritt = 3 LadenStoppen = true". Das LadenStoppen ist für mich vollkommen nachvollziehbar, aber warum hier auch das entladen gestoppt wird verstehe ich nicht.
Wäre super wenn du hier doch noch einen Ansatz finden könntest wo mein Problem her kommt.
Wenn du mir sagst wie liefere ich auch gerne noch weitere Informationen!
-
@grori
kannst du mal bitte in den Einstellungen vom e3dc-rscp Adapter prüfen, ob du dort "SET_POWER Wiederholintervall s" = 0 eingetragen hast. -
@arnod
Nein, das steht nicht auf „0“ sondern auf „2“. Dachte ich hätte das alles nach der Anleitung im PDF eingestellt, aber wenn hier eine „0“ hin gehört stell ich das um und berichte ob das Problem damit gelöst ist. -
@grori sagte in E3DC Hauskraftwerk steuern:
Das verstehe ich soweit schon, aber wenn das Laden gestoppt wird sollte doch nicht auch das Entladen gestoppt werden, oder? In der Ausgabe des Skriptes steht ja auch "Batterie entladen stoppen 0W. Schritt = 3 LadenStoppen = true". Das LadenStoppen ist für mich vollkommen nachvollziehbar, aber warum hier auch das entladen gestoppt wird verstehe ich nicht.
Wenn das Script 0W an E3DC sendet, heißt das eben auch 0W, also wird beides verhindert.
Den Text kann ich in "Batterie entladen/laden stoppen 0W" ändern, dann ist es eventuell verständlicher.