feat: used information about planed car charging to build load profile #103
Conversation
with this any planned charging is added to the profile. The information that charging will happen exist so we can use it to build a more precise prediction. For simplicity the amount needed energy is evenly distributed over the charging hours. This is wrong if for example the late-charge option is set so that there is a pause between start and finish of the charging session.
|
in general - nice idea and something to discuss... ;-) => what is your suggested goal -> taking all the needed car charge energy also via the optimized sources? means car charging from battery is here an option? => from my perspective house battery is much smaller than the car battery another or parallel approach:
what are your ideas? |
|
Hi @paulelsner , short trigger again -> what do you think ? |
|
Sorry for the late response. |
Hier noch einmal zum Thema correctness. Das Auto lädt und das System weiß das auch. Der Akku wird aber nicht den prognostizierten Stand erreichen, schließlich geht ja in der Lastprognose das Auto.
|
|
Ok, bleiben wir in Deutsch ;-) Wie ich schon versucht hatte zu beschreiben, der Ansatz ist super ... nur ist es wichtig wo und wie diese Daten eingesetzt werden. D.h .wenn ich aktiv meinen Hausspeicher auch zum Laden Fahrzeugs benutzen möchte, dann sollten, wie von Dir gezeigt, die geplanten Ladezeiten "einfach" auf die predicted load aufgeschlagen werden. Wenn man aber nicht aus dem Hausspeicher ziehen möchte (geplanter Modus ist immer schnell laden) dann wäre es hier kontraproduktiv. Da dann load in der Optimierung in naher Zukuft sichtbar ist, die für das zu optimierende System (PV, Bat, Grid + Household) sogar falsch wäre, da eben dafür nicht die Hausbatterie oder mglw. PV Quellen herangezogen werden. Und somit zu viel Energie für zu wenig Abnahme vorgehalten wird, so dass es dann effektiv nicht "optmiert" ist (preislich, sowie energetisch) Darum wäre ich beim 2. Ansatz: lass uns die Planungsdaten von evcc nehmen und diese in die Load Prediction und PV prediction negativ aufnehmen, denn wenn schnell geladen wird, sperren wir dann ja aktiv das Entladen aus der Hausbatterie (aber auch Laden der Hausbatterie aus Grid) und ziehen in der Zeit aus dem Netz. Damit bekommt EOS für den Zeitraum/ Zeiträume des geplanten Ladens eine Load von Null und kann damit besser die vorzuhaltende Energie abschätzen. ... wenn ich nun deinen letzten Post richtig einordne - dann wärst du nun auch bei dem 2. Ansatz, da ja der Akku während des Auto-Ladens wiederum auch kein PV bekommt... da EOS noch nicht weiss das in der evcc geplanten Zeit kein PV in den Speicher kommt .... @WolfImBusch fyi... das ist dann auch der per DM besprochene Fall: geplantes Laden aktiv + PV vorhanden --- von EOS gestellte Anforderung für Grid-Charge wird hier derzeit ignoriert + neue Präzisierung: reduzierte PV-Prognose für den Plan-Ladezeiteraum an EOS geben, damit entsprechend der Realität die Ladung vom Hausspeicher von EOS angepasst wird (gridcharge + korrekte Menge) |
|
Nein, ich wäre nicht bei Ansatz 2. Ich verstehe nicht, warum man dem EOS hier Daten vorgaukeln sollen. Also irgendwas vorher voneinander abziehen soll oder nicht. |
|
Ich meine ja ... EOS optimiert derzeit leider das eAuto ... nicht ... zumindest nicht so wie du (und ich es ursprünglich auch) erwarten würden... siehe dazu auch #34 Daher ist es eben wie von mir beschrieben auch kontraproduktiv die car load mit drauf zu nehmen und das war auch der damalige Grund warum der CarLoad Sensor explizit angegeben werden kann, damit eben nicht auf die Fehllast optimiert wird. Hoffe das ich nicht hier noch einen Klemmer im Hirn habe.... |
|
Ok, die Carload habe ich bei mir auch nicht angegeben. Dazu fehlt mir der passende Sensor im HA. Mein Ziel ist aktuell auch keine Autooptimierung. Das macht EVCC ja von alleine. Mit meinem Vorschlag würde diese Optimierung dann in die EOS Berechnung mit eingehen. Am Besten würde man EVCC sogar noch erweitern, dass es selbst ein Lastarray ausgibt für die geplante Last. |
|
Ich glaube wir reden weiter aneinander vorbei... ;-) Ich versuche es nochmal ... Prämisse: Schnellladen über EVCC ist immer ohne Batterieunterstützung daher bereits existent in EOS - wenn EVCC aktuell schnell lädt (egal ob aus now, smart cost oder geplant) dann über EOS_connect AVOID_DISCHARGE gesetzt -> keine Batterieentnahme Wenn wir nun mit deiner Integration fortfahren wird jedes zukünftige Ladeereignis in die Optimierung mitaufgenommen, die aber real nicht zum Tragen kommt, weil EOS nicht weiss das wir beim Laden sperren. Darum ist auch der CarLoadSensor wichtig, damit nicht aus den Historiendaten eine falscher Forecast erstellt wird. .... Daher
Wenn du nur die Plandaten auf die Prognose draufschlägst kommt es eben zu der Fehloptimierung, weil evcc oder eben eos_connect die Batterie sperrt und EOS davon nichts weiss btw. das Lastarray für das geplante Laden wird vom EVCC schon ausgegeben... |
|
Ok, ich glaube langsam verstehe ich es. Ich versuche es mal wie von dir vorgeschlagen umzusetzen. |
|
@paulelsner hattest Du schon Chance hier weiter zu kommen? |
2 participants
with this any planned charging is added to the profile. The information that charging will happen exist so we can use it to build a more precise prediction. For simplicity the amount needed energy is evenly distributed over the charging hours. This is wrong if for example the late-charge option is set so that there is a pause between start and finish of the charging session.
Let me know what you thing about this in general and if I should implement sth. in a different way