"Pulsierende" Ladung mit 2.0 master

[fawick]

Wollen wir deine Änderung und die Anpassungen am Test als PR einstellen, oder gibt es noch weitere Tester hier?

Mir wäre eigentlich am liebsten, wenn sich LutzB und/oder LenaK die Sache mal angucken würden, die haben im Gegensatz zu uns eher noch das gesamte Bild der Datenaggregation und der Regelung.
Dass mein Quickfix für mich funktioniert, heißt ja noch lange nicht, dass er der richtige Ansatz zur Problembehebung ist.

[vuffiraa]

Mir wäre eigentlich am liebsten, wenn sich LutzB und/oder LenaK die Sache mal angucken würden, die haben im Gegensatz zu uns eher noch das gesamte Bild der Datenaggregation und der Regelung.
Dass mein Quickfix für mich funktioniert, heißt ja noch lange nicht, dass er der richtige Ansatz zur Problembehebung ist.

Das soll doch so ein PR auch nur machen. Der wird auch nicht automatisch übernommen, aber Lena und Lutz sehen gleich, was dir aufgefallen ist und müssen nicht alle Nachrichten im Forum genau lesen. Und wenn sie uns sagen, woran wir nicht gedacht haben, dann können wir weitersuchen...

[fawick]

Ich kann Dich nicht aufhalten, wenn Du unbedingt einen PR erstellen willst.

Aber wenn man richtig an die Sachen rangehen will, muesste man eigentlich den gesamte if-Block ab https://github.com/openWB/core/blob/958 ... ll.py#L198 zur Diskussion stellen. Und es muesste zweifelsfrei klar sein, was die intendierte Semantik des Return-Values von BatAll.power_for_bat_charging() denn nun eigentlich sein soll (quasi der getter fuer charging_power_left). Aktuell sind die Methodenkommentare noch mehrdeutig.

Wenn man sich dann auch noch anguckt, dass der Returnwert von power_for_bat_charging() in control/counter.py in calc_surplus() und calc_raw_surplus() mit unterschiedlichen Vorzeichen verwendet wird, dann stellt sich ganz schnell die Frage, ob da nicht noch mehr im Argen liegt. Ich hab beruflich schon zu oft erlebt, dass Vorzeichenfehler / off-by-one-Fehler / Offset-Fehler an der falschen Stelle gefixt wurden und dann subtile andere Fehler hinzugefuegt bzw. schwerer zu finden gemacht haben.

Dass die Tests-Cases teilweise falsch zu sein scheinen, war dir ja auch schon aufgefallen.

<IMHO>In der Gemengelage da einfach einen Hotfix-PR rauszurocken, ohne die Intentionen und die Planung der urspruenglichen Autoren zu kennen, mag im Eifer nach einer guten Idee klingen, macht die Sache aber strenggenommen eher schlimmer als besser. Da spricht man besser vorher mal drueber.</IMHO>

[martinbrokate]

Ich habe keinen Speicher, und es schwingt sich trotzdem auf. Könnt ihr den Speicher mal testweise außenvor lassen?
Ist wenig Sonne wie aktuell und es wird nur mit 1 P. bis 3760 W geladen so ist alles tiptop, es fängt ja nur an sobald auf 3P umgeschaltet wird. Habe ich z.B. 8,5 Kw PV Produktion so wird halt dieser Wert über oder untersteuert. Auf Langsam ist es schon besser, aber wenn man es bei 1 P so exakt hin bekommt dann ist wäre es schön, wenn es bei 3P auch so wäre.

Aber echt klasse das ihr das in der Regler-Programmierung schon eingrenzen konntet, denn da bin raus.

Ist das vielleicht dann doch der Zustand, den ich auch bei mir beobachtet habe. Das hatte ich hier https://forum.openwb.de/viewtopic.php?p=102711#p102711 beschrieben.
Zusammengefasst ist die Frage, funktioniert das im Regelmodus "Ausgewogen" besser? Oder Ansonsten wäre auch ein Log interessant.

VG

Ja die Station steht auf "Ausgewogen" und arbeitet ohne Speicher. Anbei noch die Bilder wo man ganz deutlich das über/untersteuern sieht. Ab 10.33.15 Uhr geht das aufschwingen los.

[martinbrokate]

Noch ein Log Auszug.

2024-02-20 104930,899 - {control.al.txt

(16.18 KiB) 52-mal heruntergeladen

[vuffiraa]

Ich kann Dich nicht aufhalten, wenn Du unbedingt einen PR erstellen willst.

Aber wenn man richtig an die Sachen rangehen will, muesste man eigentlich den gesamte if-Block ab https://github.com/openWB/core/blob/958 ... ll.py#L198 zur Diskussion stellen. Und es muesste zweifelsfrei klar sein, was die intendierte Semantik des Return-Values von BatAll.power_for_bat_charging() denn nun eigentlich sein soll (quasi der getter fuer charging_power_left). Aktuell sind die Methodenkommentare noch mehrdeutig.

Wenn man sich dann auch noch anguckt, dass der Returnwert von power_for_bat_charging() in control/counter.py in calc_surplus() und calc_raw_surplus() mit unterschiedlichen Vorzeichen verwendet wird, dann stellt sich ganz schnell die Frage, ob da nicht noch mehr im Argen liegt. Ich hab beruflich schon zu oft erlebt, dass Vorzeichenfehler / off-by-one-Fehler / Offset-Fehler an der falschen Stelle gefixt wurden und dann subtile andere Fehler hinzugefuegt bzw. schwerer zu finden gemacht haben.

Dass die Tests-Cases teilweise falsch zu sein scheinen, war dir ja auch schon aufgefallen.

<IMHO>In der Gemengelage da einfach einen Hotfix-PR rauszurocken, ohne die Intentionen und die Planung der urspruenglichen Autoren zu kennen, mag im Eifer nach einer guten Idee klingen, macht die Sache aber strenggenommen eher schlimmer als besser. Da spricht man besser vorher mal drueber.</IMHO>

Du hast natürlich recht, überstürzte Aktivität hilft hier nicht. Für mich dient eine PR aber auch genau dazu, die Kommunikation zu einem Problem anzustoßen. Wenn der PR dann abgelehnt wird, weil der Code Teil eines größeren Konzeptes ist, ist es auch gut.

Ich meine wir habe hier eine kleine Änderung, die du bei dir testen konntest, und die ich durch Tests überprüfen konnte. Ich habe die Tests erweitert, dass sie genau unsere beiden Beobachtungen abbilden und zeigen, dass der Fix hier hilft.

Ich kann aber auch noch mal schauen, ob die vorhandenen Tests alle anderen Zweige im if-Block abdecken. Was ja bedeutet, dass sich dort schon mal jemand Gedanken gemacht hat. Außerdem werden solche PRs doch nicht eben mal als Hotfix angenommen, sie werden für die nächste Patch-Version getaggt und dann übernommen.

[vuffiraa]

Noch ein Log Auszug.2024-02-20 104930,899 - {control.al.txt

Das hier wäre der interessante Log Auszug. Er ist aber etwas zu kurz geraten. Log mal mehrere Durchläufe von # ***Start*** bis # ***Start*** wo über- bzw. unterregelt wurde. Aus dem Stück hier sehe ich nur, dass die Daten per Webaufruf von api.discovergy.com abgeholt werden. Meine Vermutung wäre, dass die gelieferten Daten leicht "hinterherhinken" dann nicht genau zu den restlichen Zahlen in deinem Setup passen. Deshalb schwankt dann auch der Hausverbrauch mit, weil er nur berechnet wird.

[martinbrokate]

Ok, erst mal vielen dank für deine Rückmeldung. Heute ist die PV Produktion größer wie 11 kw so dass nicht geregelt werden brauchte. Ja die daten kommen über die API von Discovergy. Wenn deren Server richtig laufen, so kann ich sekündlich hier in oWB die Änderungen sehen.
Habe aber trotzdem den Auszug hier rein gestellt, weil ich da einige Werte nicht verstehe:

2024-02-25 14:14:31,338 - {control.algorithm.min_current:18} - {INFO:MainThread} - Mode-Tuple Chargemode.PV_CHARGING - Chargemode.PV_CHARGING - False, Zähler 0
2024-02-25 14:14:31,339 - {control.counter:176} - {DEBUG:MainThread} - Zähler 0: [45.72, 47.54, 46.1]A verbleibende Ströme, 49874.11W verbleibende Leistung
2024-02-25 14:14:31,343 - {control.algorithm.common:95} - {INFO:MainThread} - LP5: Stromstärke 6A

Anbei der Log auszug, sowie Bilder vom Zähler. die hier im Auszug verwendeten Ampere und Leistungsdaten kann ich nicht zuordnen.

2024-02-25 141431,316 - {control.al.txt

(80.3 KiB) 46-mal heruntergeladen

Screenshot 2024-02-25 143238.png

(168.54 KiB) Noch nie heruntergeladen

Screenshot 2024-02-25 143747.png

(121.81 KiB) Noch nie heruntergeladen

[martinbrokate]

Nun war kurz weniger PV leistung.
Kann es sein das bei der Berechnung/Auswertung von Discovergy eine Kommastelle verrutscht ist. 4 Ampere mit einer Leistung von 4556 W würde besser passen.

2024-02-25 14:39:41,207 - {control.algorithm.min_current:18} - {INFO:MainThread} - Mode-Tuple Chargemode.PV_CHARGING - Chargemode.PV_CHARGING - False, Zähler 0
2024-02-25 14:39:41,209 - {control.counter:176} - {DEBUG:MainThread} - Zähler 0: [39.89, 40.34, 40.2]A verbleibende Ströme, 45560.88W verbleibende Leistung

2024-02-25 143941,186 - {control.al.txt

(55.19 KiB) 31-mal heruntergeladen

26.02.24 noch ein LOG Auszug, hier wieder mit starken Schwankungen

2024-02-26 140301,075 - {control.al.txt

(74.75 KiB) 32-mal heruntergeladen

[vuffiraa]

Nun war kurz weniger PV leistung.
Kann es sein das bei der Berechnung/Auswertung von Discovergy eine Kommastelle verrutscht ist. 4 Ampere mit einer Leistung von 4556 W würde besser passen.

2024-02-25 14:39:41,207 - {control.algorithm.min_current:18} - {INFO:MainThread} - Mode-Tuple Chargemode.PV_CHARGING - Chargemode.PV_CHARGING - False, Zähler 0
2024-02-25 14:39:41,209 - {control.counter:176} - {DEBUG:MainThread} - Zähler 0: [39.89, 40.34, 40.2]A verbleibende Ströme, 45560.88W verbleibende Leistung

2024-02-25 143941,186 - {control.al.txt

26.02.24 noch ein LOG Auszug, hier wieder mit starken Schwankungen

2024-02-26 140301,075 - {control.al.txt

So, jetzt habe ich die Zeit gefunden, mir deine Logs genau anzuschauen. Mir war beim ersten Überfliegen kein direktes Problem aufgefallen.

Erstmal zu deiner Frage zur Berechnung. Das hat so seine Richtigkeit.
Es wird angegeben, wieviel Energie in deinem Haus theoretisch zur Verfügung steht. Dazu werden die Angaben aus dem EVU-Zählermodul unter Einstellungen / Konfiguration / Lastmanagement genommen. Dort hast du die maximale Leistung auf 42 kW und die maximalen Ströme für alle 3 Phasen mit 35 A konfiguriert. Nach meiner Meinung hast du bei der maximalen Leistung einen falschen Wert, 3x 35 A entsprechen bei 230 V ca. 24 kW Leistung. Das solltest du korrigieren. Aber das hat jetzt nichts mit PV-Laden zu tun, ist mir nur aufgefallen.
Zu diesen möglichen Leistungswerten deines EVU-Zähler kommt dann noch die aktuelle PV-Leistung dazu. Laut der Zeile oben erzeugt dein WR gerade ca. 5 A pro Phase oder eben 45560.88 W - 42000 W PV-Leistung.
Also abgesehen vom Zahlendreher bei der maximalen Leistung am EVU-Zähler ist alles in Ordnung.

Jetzt der komplizierte Teil. Ich habe mal versucht die Regelung nachzustellen. Dabei werden im Log nach "***Start***" die aktuellen Werte eingesammelt und mit "# Algorithmus" daraus die Ladeeinstellungen berechnet.

# Algorithmus
Ladung wird auf 11 kW gesetzt:

Code: Alles auswählen

2024-02-26 14:03:01,146 - {control.process:111} - {INFO:MainThread} - LP5: set current 16 A, state CHARGING_ALLOWED

*** Start
Discovergy Zähler:
- Einspeisung: 2845,83 W

Code: Alles auswählen

2024-02-26 14:03:10,531 - {modules.common.req:11} - {DEBUG:device0} - Get-Response: {"time":1708952567084,"values":{"power":-2845830,"power3":-994950,"energyOut":2441392274058000,"power1":-893910,"energy":23237308205000,"power2":-956970}}

Discovergy Wechselrichter:
- Erzeugung: 8274,69 W

Code: Alles auswählen

2024-02-26 14:03:10,600 - {modules.common.req:11} - {DEBUG:device0} - Get-Response: {"time":1708952589832,"values":{"phase2Power":-2756880,"energyOut":746965350302000,"energy2":322668320000,"energy1":3891390000,"phase1Power":-2736600,"power":-8274690,"phase3Power":-2781200,"phase1Voltage":232300,"energy":326559711000,"phase2Voltage":231100,"phase3Voltage":230200}}

Ladepunkt:
- Ladung: 10794,98 W

Code: Alles auswählen

2024-02-26 14:03:10,894 - {control.chargepoint.chargepoint:665} - {INFO:MainThread} - LP 5, EV: EQA 250 (EV-Nr.2): Theoretisch benötigter Strom 6A, Lademodus pv_charging, Submodus: Chargemode.PV_CHARGING, Phasen: 3, Priorität: False, max. Ist-Strom: 15.87

Berechneter Hausverbrauch: PV - Einspeisung - Ladepunkt: 8274,69 W - 2845,83 W - 10794,98 W = -5366,12 W (ungültiger Wert!)

Code: Alles auswählen

2024-02-26 14:03:10,897 - {control.counter_all:101} - {ERROR:MainThread} - Ungültiger Hausverbrauch: -5366.119999999999W, Berücksichtigte Komponenten neben EVU [{'id': 5, 'type': 'cp', 'children': []}, {'id': 1, 'type': 'inverter', 'children': []}]

# Algorithmus
- verfügbare Leistung: PV - Hausverbrauch oder Ladung - EVU: 13640,81 W
- Leistung / 230 V / 3: 19,77 A => maximal 16 A erlaubt

Code: Alles auswählen

2024-02-26 14:03:11,004 - {control.process:111} - {INFO:MainThread} - LP5: set current 16 A, state CHARGING_ALLOWED

*** Start
Discovergy Zähler:
- Bezug: 2696,29 W

Code: Alles auswählen

2024-02-26 14:03:20,400 - {modules.common.req:11} - {DEBUG:device0} - Get-Response: {"time":1708952599078,"values":{"power":2696290,"power3":885760,"energyOut":2441392276466000,"power1":933000,"energy":23237489682000,"power2":877530}}

Discovergy Wechselrichter:
- Erzeugung: 8308,65 W

Code: Alles auswählen

2024-02-26 14:03:20,474 - {modules.common.req:11} - {DEBUG:device0} - Get-Response: {"time":1708952599832,"values":{"phase2Power":-2759800,"energyOut":746965580682000,"energy2":322668320000,"energy1":3891390000,"phase1Power":-2749280,"power":-8308650,"phase3Power":-2799560,"phase1Voltage":232600,"energy":326559711000,"phase2Voltage":231300,"phase3Voltage":230200}}

Ladepunkt:
- Ladung: 10793,77 W

Code: Alles auswählen

2024-02-26 14:03:20,698 - {control.chargepoint.chargepoint:665} - {INFO:MainThread} - LP 5, EV: EQA 250 (EV-Nr.2): Theoretisch benötigter Strom 6A, Lademodus pv_charging, Submodus: Chargemode.PV_CHARGING, Phasen: 3, Priorität: False, max. Ist-Strom: 15.87

Berechneter Hausverbrauch: PV + Bezug - Ladepunkt: 8308,65 W + 2696,29 W - 10793,77 W = 211,17 W

# Algorithmus
- verfügbare Leistung: PV - Hausverbrauch oder Ladung - EVU: 8097,48 W
- Leistung / 230 V / 3: 11,74 A
- Hier gibt es noch eine Anpassung weil das Auto "nur" mit 15,87 A anstelle von 16 A lädt. Deshalb wird eine etwas höhere Stromstärke gesetzt, in der Annahme, dass das Auto dann wirklich mit 11,74 A lädt.

Code: Alles auswählen

2024-02-26 14:03:20,881 - {control.process:111} - {INFO:MainThread} - LP5: set current 11.87 A, state CHARGING_ALLOWED

*** Start
Discovergy Zähler:
- Bezug: 2143,32 W

Code: Alles auswählen

2024-02-26 14:03:30,325 - {modules.common.req:11} - {DEBUG:device0} - Get-Response: {"time":1708952605078,"values":{"power":2143320,"power3":715270,"energyOut":2441392276466000,"power1":749910,"energy":23237532976000,"power2":678140}}

Discovergy Wechselrichter:
- Erzeugung: 8328,57 W

Code: Alles auswählen

2024-02-26 14:03:30,382 - {modules.common.req:11} - {DEBUG:device0} - Get-Response: {"time":1708952609833,"values":{"phase2Power":-2780930,"energyOut":746965811839000,"energy2":322668320000,"energy1":3891390000,"phase1Power":-2751520,"power":-8328570,"phase3Power":-2796110,"phase1Voltage":233000,"energy":326559711000,"phase2Voltage":231600,"phase3Voltage":230400}}

Ladepunkt:
- Ladung: 7954,37 W

Code: Alles auswählen

2024-02-26 14:03:30,634 - {control.chargepoint.chargepoint:665} - {INFO:MainThread} - LP 5, EV: EQA 250 (EV-Nr.2): Theoretisch benötigter Strom 6A, Lademodus pv_charging, Submodus: Chargemode.PV_CHARGING, Phasen: 3, Priorität: False, max. Ist-Strom: 11.7

# Algorithmus (ohne Log!)
- verfügbare Leistung: PV - Hausverbrauch oder Ladung - EVU: 5811,05 W
- Leistung / 230 V / 3: 8,42 A

Jetzt wird die Ladeleistung also noch mal reduziert und dann hat dein Zähler wahrscheinlich wieder eine Einspeisung gemeldet und die Ladeleistung ging wieder nach oben. Es scheint so, als ob die Werte deiner Discovergy Zähler nicht zu den aktuellen Ladewerten passen. Am Anfang wird noch eine Einspeisung gemeldet, obwohl das Auto schon "volle Pulle" lädt. Und am Ende des Logs wird die Ladeleistung weiter reduziert, weil von Zähler immer noch Bezug gemeldet wird.
Mit der langsamen Regelung werden die Werte einfach seltener abgerufen und passen dann eher zusammen. Ich kenne mich bei Discovergy nicht aus, wie schnell und wie oft die Werte dort übertragen werden, und ob man vielleicht auch dort noch etwas einstellen kann.

Soweit scheint bei dir alles in Ordnung zu sein und wenn über Discovergy die Werte etwas verzögert bereit stehen, muss man damit umgehen, siehe langsame Regelung.

Den einzigen Ansatzpunkt, den ich jetzt vielleicht sehe, wäre der ungültige Hausverbrauch. Bei der Berechnung wird der ja trotzdem als nutzbar einbezogen. Hier könnte man auf Plausibilität prüfen und die verfügbare Leistung entsprechen reduzieren. Das würde wenigstens das Überschwingen in den Bezug verringern.

Falls jemand meiner Theorie folgen kann, bitte kommentieren