Handle start conditions with battery SOC below minimal SOC#37
Conversation
|
@andig, this one is ready for review. |
Das klingt nach einer wirklich smarten Lösung. Aber: für den max soc lässt sich das ja so nicht lösen! Daher würde ich vmtl. eher- einfacher und konsistent- dabei bleiben, dass wir in diesem Fall das Problem auf der aufrufenden Seite lösen und damit auf #36 verzichten? Oder sollen wir das hier als plausible "halbe" Lösung mit rein nehmen? |
|
Wenn uns das sinnvoll erscheint, kann ich eine ähliche Behandlung für die SOC Obergrenze einführen. Dazu bräuchten wir allerdings eine zusätzliche Information, nämlich die tatsächliche Kapazität der Batterie (der max. SOC wird ja in Wh angegeben, das können 100% der Kapazität sein aber auch 70%). Ich könnte dann unterscheiden zwischen:
Ich kann das natürlich auch im Blindflug machen und einfach glauben, dass der start-SOC schon passt aber wohl wäre mir dabei nicht 🤔 ... deswegen auch erstmal nur die eine Hälfte ... |
|
Das Problem hier ist, dass sich auch 1) nicht für Fahrzeuge machen lässt. I.S. von Konsistenz würde ich daher dazu tendieren, das nicht zu machen. Bleibt die Frage, ob wir die Hälfte- Laden- trotzdem umsetzen wollen? |
|
ah du meinst, weil sie nicht entladen werden können 🤔 ... Gut, dann ist die max. Entladeleistung 0 und max. SOC wird bis Ende des Horizonts nicht unterschritten ... macht für den Optimierer keinen Unterschied, denke ich. |
|
... ich würde eher sagen, dass das ein echter Anwendungsfall ist, der real so auftreten kann: Auto kommt mit SOC > max. SOC an die Wallbox. |
|
Auch wieder wahr. Ok, also gerne PR für Beides? |
|
Yep, mache ich. |
|
I had to change the approach to penalties to make things work for initial max SOC violations. However, I found there are also some cases for violated min SOC that did not work with pre-calculated limits. So, this solution also covers some more remote cases in the s_min violation scenario. |
|
added an optional property for the battery capacity being a hard limit, also for s_initial. If it is not provided it will be equal s_max. |
|
Do you think this is worth adding in terms of model complexity? Atm I'm working around this in evcc. |
|
I think it does make sense as it makes the behavior more reliable once evcc does actual control based on the optimizer results. As the current situation in the home grid will occasionally deviate from the forecast the optimizer used to make its control recommendation, we will see (small) limit violations on a regular basis. The optimizer will get those as a starting point for its next run and should be robust regarding those deviations. |
|
@andig , let me know if you are ok to merge, I will then resolve the conflicts caused by the repo structure cleanup. |
|
Sure, purpose is clear. |
- Add s_capacity property to BatteryConfig - Add SOC penalty mechanism for initial SOC above s_max or below s_min - Use s_capacity (defaults to s_max) as variable bounds instead of s_min/s_max - Add time-decay to grid export limit penalty - Update openapi.yaml and regenerate Go client - Update test case 013 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
andig
force-pushed
the
12-avoid-infeasible-response-for-start-conditions-with-battery-soc-out-of-bounds
branch
from
7b037c6 to
1bbc629
Compare
|
@ekkea I've asked Claude- is the result ok for you? Are we missing tests now? |
|
Actually, Claude force-pushed. F*** |
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
mh, the test cases look weird now, I'm afraid something went wrong 🤔 |
|
|
Do you want me to try to restore to original state? Not sure if this is still possible, but I could try. |
|
let me see, I'm not that fast ... |
|
Looks good, let me add some test cases I had prepared and check whether their results are ok ... |
|
@andig , good to merge to main, I think everything survived Claude's little forced-push adventure ;-) |
2 participants
Fix #36