Zielladen

[naltatis]

Hier kann zum Zielladen-Feature #1434 diskutiert werden.

[blenni]

Sehr cool, finde ich toll.

Wie läuft die Berechnung momentan?
Was ist z.B. bei folgendem Szenario:
Ich komme an einem Tag mit leeren Akku zu Hause um 16:00 an und stelle ein, dass ich am nächsten Tag um 07:00 mit 80% losfahren will. Prognostizierte Ladezeit bei 16A 1-phasig sagen wir mal 8h.
Bis 18:00 reicht mein PV-Überschuss zum Laden, da wird dann natürlich entlang des PV-Überschuss geladen.
Von 18:00 bis 19:30 habe ich noch PV-Überschuss, aber zu wenig, um die 6A 1-phasig zu erreichen. Nutzt der Algorithmus das trotzdem? Es wäre insgesamt ja noch besser als dann in der Nacht von 01:00-07:00 komplett aus dem Netz zu laden.

Ist auch angedacht, regelmäßige Abfahrtszeiten zu implementieren? Z.B. Mo-Fr statt eines einzelnen Tages? Könnte für viele Pendler interessant sein.

Wird - trotz aktivem Zielladen - bei mehr PV-Überschuss auch über das gesetzte Ziel geladen?

[andig]

Ich würde das Zielladen dafür nutzen, einen Mindest-SOC (bei mir 60%) zu haben, damit ich meine Pendelstrecke schaffe - alles darüber hinaus sollte aber nicht eingespeist, sondern trotzdem ins Auto geladen werden.

So ist es. Nett sich PV Modus plus Zielladen. Genau das liefern wir.

Sowas hatte ich ja mal vorgeschlagen, weil ich es grundsätzlich auch für sinnvoll halte. Wurde abgelehnt.

Verstehe ich nicht

Was wäre, wenn man beim Zielladen von einem PV-Modus (nur oder max+) zeitgesteuert in den Modus Sofortladen wechseln würde? Anschließend zurück.

S.o. der Modus bleibt PV, Zielladen nutzt "Sofort" falls notwendig.

Dann hätte man unterschiedliche Ziel-SoCs.

Nein, hast Du nicht.

[blenni]

Ich würde das Zielladen dafür nutzen, einen Mindest-SOC (bei mir 60%) zu haben, damit ich meine Pendelstrecke schaffe - alles darüber hinaus sollte aber nicht eingespeist, sondern trotzdem ins Auto geladen werden.

So ist es. Nett sich PV Modus plus Zielladen. Genau das liefern wir.

Nein, bzw. nur teilweise - oder hab ich jetzt nen Denkfehler?
Wenn ich bis zum Zielzeitpunkt x keine überschüssige PV mehr habe, dann gebe ich dir recht. Scheint aber noch die Sonne, habe ich einen Unterschied:

PV-Modus + Zielladen: Hier gebe ich einen Max-SOC vor, der zu einem Zeitpunkt x spätestens erreicht werden soll. Wenn ich meinem Max-SOC auf 70% setzte und noch mehr PV-Energie bis zum Zeitpunkt x verfügbar wäre, würde das Auto nicht mehr weiter geladen werden.

Was ich meine, ist:
Ziel-Min-SOC + PV: Hier gebe ich einen Min-SOC vor, der zu einem Zeitpunkt x spätestens erreicht werden soll. Wenn ich den Min-SOC auf 70% setzte und noch mehr PV-Energie bis zum Zeitpunkt x verfügbar wäre, würde das Auto auch noch bis 100% (oder einem gesetzten Max-SOC) weitergeladen werden.

[andig]

Stimmt- danke für die Darstellung!

[DerAndereAndi]

Man kann momentan in der Konfiguration einen soc: min: Wert angeben. Wenn das EV einen SoC darunter hat, wird der im Modus Sofort geladen, d.h. so schnell wie möglich. Und wenn man in der UI den PV Modus eingeschaltet hat, wird dann PV oben drauf geladen. Ist aber kein Mindest SoC auf einen Zielzeitpunkt.

[blenni]

Genau - diesen Wert in der Konfig kenne ich. Aber wie du sagst, wird dann Sofort bis zu diesem SOC geladen.
Wenn meine nächste Abfahrt noch weit genug entfernt ist, könnte man bis zu diesem Min-SOC auch die Sonne nutzen.

Wie oben schon geschrieben ist das für mich kein Beinbruch und auch manuell gut regelbar - sollte nur als Idee/Anregung für die Zukunft dienen.

[Webwanze]

Hallo,

mich finde das gut gelöst. Der ‚Abfahrtskalender‘ wäre noch ein nettes Zusatzfeature für die Zukunft.

Jetzt könnte man noch mit unterschiedlichen Strompreisen herumtun. Also bevorzugt im Niedertarif laden. Oder sogar variablen Strompreisen. Aber ich denke, das macht die Bedienung zu kompliziert.

Thomas

[DerAndereAndi]

Unterschiedliche Strompreise hat hiermit wenig zu tun, wenn du PV Überschuß auf als (dynamisch) niedrigen Strompreis betrachtest. Da wird die Reise auch hingehen, ob man PV Strom, oder niedrigen Stromtarif, oder dynamischen Stromtarif, oder eine Kombi davon hat, ist ja eigentlich egal. Bis zum Ziel soll so günstig wie möglich geladen werden, egal ob das Ziel einen Zeitpunkt hat oder nicht. Die UI wird sich da nicht ändern müssen.

[naltatis]

Thema "Abfahrtskalender" und wiederkehrende Zeiten und Regeln wird kommen. Dafür brauchen wir aber auf jeden Fall vorher Persistenz der Konfiguration.

[andig]

kommt, hetzt mich nicht ;)

[schenlap]

Erster Versuch hat nich so recht geklappt. Ich bin mir aber nicht sicher ob es am Zielladen gelegen hat oder am Soc Estimator irgendwas nicht stimmt. Was mir jetzt aufgefallen ist:

{"type":"parameters","list":[{"vehicleState":2,"evseState":false,"maxCurrent":16,"actualCurrent":0,"actualPower":0,"duration":256000,"alwaysActive":true,"lastActionUser":"API","lastActionUID":"API","energy":0.19,"mileage":1.2,"meterReading":138.09,"currentP1":0,"currentP2":0,"currentP3":0,"voltageP1":0,"voltageP2":0,"voltageP3":0,"useMeter":true,"RFIDUID":""}]}
[lp-1  ] DEBUG 2021/08/26 08:38:32 soc estimated: 30.31% (vehicle: 28.00%)
[lp-1  ] DEBUG 2021/08/26 08:38:32 vehicle soc: 30%
[lp-1  ] DEBUG 2021/08/26 08:38:32 vehicle range: 9km
[cache ] DEBUG 2021/08/26 08:38:32 vehicleSoc: 30
[cache ] DEBUG 2021/08/26 08:38:32 chargeEstimate: -1ns
**<-- wie kann er negativ sein, 1ns ist auch etwas wenig**

[cache ] DEBUG 2021/08/26 08:38:32 chargeRemainingEnergy: 4253.333333333326
[cache ] DEBUG 2021/08/26 08:38:32 range: 9
[evse  ] TRACE 2021/08/26 08:38:32 GET http://10.0.0.208/getParameters
[evse  ] TRACE 2021/08/26 08:38:32 
...
{"type":"parameters","list":[{"vehicleState":2,"evseState":false,"maxCurrent":16,"actualCurrent":0,"actualPower":0,"duration":256000,"alwaysActive":true,"lastActionUser":"API","lastActionUID":"API","energy":0.19,"mileage":1.2,"meterReading":138.09,"currentP1":0,"currentP2":0,"currentP3":0,"voltageP1":0,"voltageP2":0,"voltageP3":0,"useMeter":true,"RFIDUID":""}]}
[lp-1  ] DEBUG 2021/08/26 08:38:32 target charging active for 2021-08-29 20:45:00 +0200 CEST: projected 2021-08-25 21:11:00 +0200 CEST (-11h28m0s remaining) 
**<-- -11h? in 2 Stunden sollte das Auto jedenfalls voll sein, und wieso negativ?**

[cache ] DEBUG 2021/08/26 08:38:32 timerSet: true
[lp-1  ] DEBUG 2021/08/26 08:38:32 max charge current: 0.0A = 0.0A + -0.2A (47W @ 1p)
[lp-1  ] DEBUG 2021/08/26 08:38:32 reset pv enable timer: 1m0s
[lp-1  ] DEBUG 2021/08/26 08:38:32 pv enable timer: keep disabled
[lp-1  ] DEBUG 2021/08/26 08:38:32 pv max charge current: 0A
[cache ] DEBUG 2021/08/26 08:38:32 timerActive: false
[lp-1  ] DEBUG 2021/08/26 08:38:32 climater active: false, target temp: 22.0°C, outside temp: 23.0°C
[cache ] DEBUG 2021/08/26 08:38:32 climater: off
[cache ] DEBUG 2021/08/26 08:38:42 pvPower: 171.62
[cache ] DEBUG 2021/08/26 08:38:42 gridPower: 39
[cache ] DEBUG 2021/08/26 08:38:42 mode: pv

Wie ist Zielladen zu verwenden? PV Mode einschalten und anschließend den Zeitpunk auswählen?

[andig]

Was hat nicht recht geklappt?

[schenlap]

laden hat nicht gestartet

[andig]

Wenn ich 2x den Dialog öffne steht noch der alte Wert drin-> sollte der gesetzte sein. Wenn wir keinen Wert haben Zielzeit 7:00 Uhr statt 22:00 Uhr?

[bacanol]

Ich habe es heute auch einmal ausprobiert mit dem Zielladen, es hat soweit erkennbar gestartet, ist dann aber nach 0,5kw / 12 Minuten wieder ausgegangen. Theoretisch hätte es 40 Minuten laden sollen. Anbei entsprechendes Logfile:

evcc-zielladung.txt

[andig]

Verschiedene Bugfixes siehe #1470

[schenlap]

Im Modus "STOP" kann ich eine Zielzeit setzen, diese wird aber erst angezeigt wenn der Modus gewechselt wird. Ist irgendwie verwirrend.

[schenlap]

Hi,

ich würde die Anzeige von Bezug und Verbrauch umdrehen. Aktuell scheint es auf den ersten Blick so dass das Auto komplett mit PV Strom geladen wird und das Haus einen Bezug verursacht. Ich sehe das aber anders, der Hausverbraucht ist der nicht beeinflussbare Teil und den will ich mit zuerst mit PV decken, erst der Rest ist für das Auto. Daher würde ich den Bezug dem Auto zurechnen, nicht dem Haus. Im Sceenshot sieht man dass das Haus 1,1kW Bezug verursacht.

Ich würde daher das Symbol für Auto und Haus tauschen, damit wäre optisch der Bezug dem Auto zuzurechnen.

[DerAndereAndi]

Guter Punkt finde ich. Netzbezug kommt oben drauf weil PV/Batterie nicht ausreicht, also das nach rechts.

[bacanol]

Gibt es hier schon weitere Erkenntnisse? Ich halte das Feature für richtig gut!

[andig]

Mir fehlt aktuell die Zeit das wieder ordentlich zu reparieren, sorry.

[bacanol]

@andig Alles gut. Freue mich auf das Feature und wenn es nicht gänzlich vom Tisch ist, bin ich froh.

[MicFre173]

Wie komme ich denn in der GUI zur Einstellung des Zielzeitpunkts? Muss ich dazu in der Config (am Vehicle? am Loadpoint?) etwas ändern?

Sorry, ich Blick es gerade irgendwie nicht. Bin aber auch GitHub-Neuling und finde es noch recht unübersichtlich.

[naltatis]

Wir hatten das Feature zeitweise mal mit "experimentell" Hinweis released.

Die Zielladen UI ist aktuell aber deaktiviert da der Algorithmus noch nicht das tut was er soll.

[MicFre173]

Danke für die schnelle Rückmeldung. Dann harre ich mal der Dinge, die da kommen und behalte die Release Notes im Auge. 😉

Finde das Feature/die Idee sehr nützlich!

[MicFre173]

der Algorithmus noch nicht das tut was er soll.

Wenn ich das richtig verstehe, besteht das Problem darin, per Algorithmus vorherzusagen, wann der Ladevorgang beginnen muss, um zum Wunschzeitpunkt den eingestellten SoC zu treffen.
Vielleicht wäre es eine gute Übergangslösung, ohne Algorithmus einfach den Startzeitpunkt der Ladung einstellen zu können.

Würde mein persönliches Problem schon lösen - brauche morgens genug SoC für den Weg zur Arbeit und zurück. So könnte ich über Tag im PV-Modus so viel Sonne wie möglich reinladen und als Fallback abends ab 23 Uhr (= nach Sonnenuntergang) bis zum Min-SoC laden.
Diese Lösung wäre nicht so elegant und würde Leuten nicht helfen, die irgendwann im Tagesverlauf losfahren, aber es wäre auch deutlich weniger Komplexität/Logik erforderlich.

In diesem Zusammenhang wäre es sogar sinnvoll, einen Min-SoC (Bedarf Pendelstrecke) und einen Max-SoC (zur Akkuschonung) definieren zu können. So wie ich das mitbekommen habe, ist das aber wegen der damit steigenden GUI-Komplexität nicht gewünscht, wobei ich den Min-Wert auch durchaus als festen Wert im Config-File sehen würde (oder halt später als Menüeinstellung wenn die GUI eine Persistenz hat).

[andig]

Die Funktion ist jetzt in master wieder drin. Der Dank gebührt @schenlap

[TheSpirit]

hab grad den aktuellen master getestet.
wenn ich ich modus pv bin und dann im pop-up Fenster auf "keine Zielzeit" klicke, wird trotzdem das laden gestartet.
ich bekomm das mit dem ziehlzeit laden erst wieder weg wenn ich evcc neu starte.
hab jetzt erstmal wieder die release 0.73 am laufen

[schenlap]

Hi,

ja, ist mir auch schon aufgefallen, habe schon ein Issue geöffnet.
#2064

Die Zielzeit geht auch nach dem Laden wieder weg, es ist nur ein Problem wenn man es setzt und dann entschließt wieder weg haben zu wollen.

[andig]

Ist behoben

[andig]

Was wollen wir egtl. als Zielzeit setzen wenn noch keine eingestellt ist? Aktuell ist es "now + 12h":

Ich könnte mir vorstellen, dass wir stattdessen sowas wie "morgen 7:00h" nehmen oder die default Tageszeit vielleicht auch konfigurierbar machen?

PS.: den Typo korrigier ich gleich!

[schenlap]

Ich könnte mir vorstellen, dass wir stattdessen sowas wie "morgen 7:00h" nehmen oder die default Tageszeit vielleicht auch konfigurierbar machen?

morgen 7:00 würde bei mir zufällig auch passen. Vielleicht wäre es aber noch sinnvoller wenn die letzte eingestellte Uhrzeit gemerkt wird und dies mit Datum "morgen" verwendet wird?

[andig]

Siehe #2075

[int5749]

Plant ihr „nur“ ein Zielladen auf 100% oder auch auf den eingestellten SoC?

Mangels Sonne und darüberhinaus ob der Kälte in der Nacht, habe ich mir über openHAB eine Regel geschrieben das EV zu einer bestimmten Zeit auf den eingestellten SoC zu laden. Um den Akku zu schonen wird dabei mit 6A begonnen, alle 15Min um 2A erhöht bis auf 12A. Dies wird alles in einem bei der Berechnung berücksichtigt um die Startzeit - basierend auf dem momentanen SoC - fürs laden zu ermitteln. Somit ist der Akku dann direkt für die Abfahrtzeit vorgewärmt.

Unterm Strich steuere ich „lediglich“ EVCC => setze dies zur Startzeit auf 6A und „now“ und erhöhe den Ladestrom. EVCC übernimmt dann das beenden des Ladevorgangs bei erreichen des Ziel-SoC

[premultiply]

Der Ziel-SoC wird über den normalen SoC-Schieber eingestellt.

[lukasbisdorf]

Ich schau mal ob ich Zeit für ein mock-up finde. Hab da eine Idee wie das aussehen könnte. Komme am Wochenende aber nicht dazu. :)

…

Am 14.01.2022 um 18:47 schrieb andig ***@***.***>:  Das wäre dann der Dritte PV-Modus. Wir suchen eher nach einer Reduktion der Modi, z.B. „Schnell“ und „Günstig“. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.

[Webwanze]

Hallo,

mich habe jetzt das Zielladen mehrfach verwendet. Funktioniert wie es soll. Super Sache!

Zwei Anmerkungen:

1. Wenn die Systemzeit nicht stimmt, funktioniert auch die Auswahl der Zielzeit nicht korrekt. Mein Raspi stand auf Standardzeit. Habe ich dann in der UI 6:00 ausgewählt, so wurde 7:00 angezeigt.
2. Wenn ich auf Zielzeit klicke kommt immer 7:00 als Default. Zu 99% bräuchte ich persönlich 6:00. Hier wäre eine optionale Konfiguration sicher eine gute Idee.

Danke euch,

Thomas

[schenlap]

Eigentlich war 7:00 nur der Defaultwert, für die nächsten Tage wird dann die letzte gesetzte Uhrzeit verwendet. Zumindest war das die Idee, vielleicht aber noch nicht umgesetzt?

[blenni]

Ich hatte gestern den Fall, dass das Target Charging nicht gestartet hat.

Laut log wurde eine Zeit berechnet und der Ladestart sollte um 8:25 erfolgen - Zielzeit war auf 9:15 gesetzt.
Ich habe um die Zeit rum zufällig geschaut und gesehen, dass der Ladestart noch nicht erfolgt ist - und habe dann manuell den Lademodus auf now gesetzt - zufällig um 8:26, ohne vorher in die Log-Datei zu schauen :)

Hier der Log-Auszug:

raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:08 charge power: 0W
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:08 charge currents: [0 0 0]A
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:08 charger status: B
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:08 estimated charge duration: 49m0s to 100% at 3680W
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:08 projected start: 2022-01-14 08:25:46.666666667 +0100 CET
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:08 max charge current: 0A = 0A + -0.477A (110W @ 1p)
raspberrypi evcc[1073]: [lp-1  ] ERROR 2022/01/14 08:25:08 climater: Get "https://fal-3a.prd.eu.dp.vwg-connect.com/fs-car/bs/climatisation/v1/VW/ES/vehicles/<VIN>/climater": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:08 charge power: 0W
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:08 charge currents: [0 0 0]A
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:28 charge power: 0W
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:28 charge currents: [0 0 0]A
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:28 charger status: B
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:28 estimated charge duration: 49m0s to 100% at 3680W
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:28 projected start: 2022-01-14 08:25:46.666666667 +0100 CET
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:28 max charge current: 0A = 0A + -0.304A (70W @ 1p)
raspberrypi evcc[1073]: [lp-1  ] ERROR 2022/01/14 08:25:28 climater: Get "https://fal-3a.prd.eu.dp.vwg-connect.com/fs-car/bs/climatisation/v1/VW/ES/vehicles/<VIN>/climater": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:28 charge power: 0W
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:28 charge currents: [0 0 0]A

Hier hätte Zielladen eigentlich starten sollen, hat es aber nicht; Kann das was mit der Zeitzone zu tun haben?

raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:48 charge power: 0W
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:48 charge currents: [0 0 0]A
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:48 charger status: B
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:48 estimated charge duration: 49m0s to 100% at 3680W
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:48 projected start: 2022-01-14 08:25:46.666666667 +0100 CET
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:48 max charge current: 0A = 0A + -0.329A (76W @ 1p)
raspberrypi evcc[1073]: [lp-1  ] ERROR 2022/01/14 08:25:48 climater: Get "https://fal-3a.prd.eu.dp.vwg-connect.com/fs-car/bs/climatisation/v1/VW/ES/vehicles/<VIN>/climater": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:48 charge power: 0W
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:25:48 charge currents: [0 0 0]A
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:08 charge power: 0W
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:08 charge currents: [0 0 0]A
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:08 charger status: B
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:08 estimated charge duration: 49m0s to 100% at 3680W
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:08 projected start: 2022-01-14 08:25:46.666666667 +0100 CET
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:08 max charge current: 0A = 0A + -0.427A (98W @ 1p)
raspberrypi evcc[1073]: [lp-1  ] ERROR 2022/01/14 08:26:08 climater: Get "https://fal-3a.prd.eu.dp.vwg-connect.com/fs-car/bs/climatisation/v1/VW/ES/vehicles/<VIN>/climater": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:08 charge power: 0W
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:08 charge currents: [0 0 0]A
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:28 charge power: 0W
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:28 charge currents: [0 0 0]A
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:28 charger status: B
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:28 estimated charge duration: 49m0s to 100% at 3680W
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:28 projected start: 2022-01-14 08:25:46.666666667 +0100 CET
raspberrypi evcc[1073]: [lp-1  ] INFO 2022/01/14 08:26:28 target charging active for 2022-01-14 09:15:00 +0100 CET: projected 2022-01-14 09:16:00 +0100 CET (49m0s remaining)
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:28 target charging: speedup (16A)
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:28 max charge current: 16A
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:28 charger enable
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:28 charge power: 0W
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:28 charge currents: [0 0 0]A

Hier habe ich dann den Lademodus auf Sofort gesetzt:

raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:34 set charge mode: now
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:34 pv action: inactive
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:34 charge power: 59W
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:34 charge currents: [0.596 0 0.001]A
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:34 charger status: C
raspberrypi evcc[1073]: [lp-1  ] INFO 2022/01/14 08:26:34 start charging ->
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:35 soc estimated: 61.50% (vehicle: 55.00%)
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:35 vehicle soc: 61%
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:35 vehicle range: 16km
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:35 vehicle odometer: 4010km
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:35 target charging: disable
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:35 charge power: 7W
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:35 charge currents: [0.493 0.001 0]A
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:48 charge power: 3491W
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:48 charge currents: [15.3 0 0]A
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:48 detected phases: 1p [15.3 0 0]A
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:48 charger status: C
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:48 soc estimated: 61.61% (vehicle: 55.00%)
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:48 vehicle soc: 61%
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:48 vehicle range: 16km
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:48 vehicle odometer: 4010km
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:48 charge power: 3496W
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:48 charge currents: [15.3 0 0]A
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:26:48 detected phases: 1p [15.3 0 0]A
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:27:00 set target charge: 0 @ 0001-01-01 00:00:00 +0000 UTC
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:27:08 charge power: 3497W
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:27:08 charge currents: [15.3 0 0.001]A
raspberrypi evcc[1073]: [lp-1  ] DEBUG 2022/01/14 08:27:08 detected phases: 1p [15.3 0 0.001]A

Zusätzlich habe ich auch noch mit den 49 Minuten bis Vollladung ein kleines Problem.
Vom Fahrzeug werden 55% SOC gemeldet, der interne Schätzer steht auf 61%.
In der Konfig sind 11 kWh Speichergröße hinterlegt, für Zielladen stehen soweit ich mich erinnere die Ladeverluste auf 20%, also effektiv 13,75 kWh.
Rest-SOC sind dann 39 % (bzw. 45% für den vom Fahrzeug gemeldeten Wert), das entspricht dann 5,36 kWh (bzw. 6,19 kWh).
Bei einer Ladeleistung von 3,6 kW komme ich nach meiner Rechnung auf 89 min (bzw. 130 min).
Kann es sein, dass für das Zielladen auch der Wert aus dem Estimator und nicht aus der Konfig genommen wird?
Hier spielt dann wahrscheinlich wieder das Thema aus #1538 hinein, das ich in unregelmäßigen Abständen bei beiden Fahrzeugen (BMW i3s und Cupra Leon) immer mal wieder beobachte...
Um auf Nummer sicher zu gehen, dass der Ladevorgang rechtzeitig fertig ist, wäre es evtl. sinnvoll, die Restzeit mit den Werten aus der Config zu berechnen?

edit: Ja, ich hab das nochmal im logfile geprüft, aus dem davor schon gelaufenen Ladevorgang (ohne Abstecken vor dem Zielladen) hatte ich am Ende eine virtualCapacity von 7056 Wh - das kommt mit den 49 Minuten dann ziemlich genau hin.

Evtl. sollte man da das max. aus der konfigurierten und geschätzten Kapazität nehmen, um das Vollladen zur Zielzeit sicherstellen zu können

[schenlap]

Du bist etwas zu ungeduldig :-)

raspberrypi evcc[1073]: [lp-1 ] INFO 2022/01/14 08:26:28 target charging active for 2022-01-14 09:15:00 +0100 CET: projected 2022-01-14 09:16:00 +0100 CET (49m0s remaining)

raspberrypi evcc[1073]: [lp-1 ] DEBUG 2022/01/14 08:26:28 target charging: speedup (16A)
raspberrypi evcc[1073]: [lp-1 ] DEBUG 2022/01/14 08:26:28 max charge current: 16A
raspberrypi evcc[1073]: [lp-1 ] DEBUG 2022/01/14 08:26:28 charger enable
raspberrypi evcc[1073]: [lp-1 ] DEBUG 2022/01/14 08:26:28 charge power: 0W
raspberrypi evcc[1073]: [lp-1 ] DEBUG 2022/01/14 08:26:28 charge currents: [0 0 0]A

Das ist schon der Start. Wir sind hier 2 Zyklen hinter der berechneten Zeit bis zum Start (2 x 20 Sekunden), das ist mir auch schon aufgefallen, waren mir aber egal.

[schenlap]

Mit virtual capacity Berechnung habe ich auch immer wieder Probeme, da schreibe ich aber in #1538

[andig]

Zeitzonenprobleme sind theoretisch immer möglich, dafür wäre erstmal die Frage ob der Timestamp im Logfile stimmt.

@naltatis wir könnten auch überlegen, die Zielzeit als „in xyz“ Dauer zu übergeben statt als Timestamp. Das würde Zeitzonen von FE und BE entkoppeln. Jedenfalls, solange keine Schaltstunde dazwischen hängt. Alternativ könnten wir nochmal schauen, ob wir überall einheitlich mit UTC unterwegs sind?

[blenni]

Wie @schenlap schon schreibt, hat das mit dem Ladestart ja doch funktioniert (habe ich im Log übersehen) und fiel zufällig mit meinem manuellen Umschalten auf "now" zusammen.

Heute hat's bei mir mit dem Ladestart auch wieder gepasst, also scheine zumindest ich kein Problem mit der Zeitzone zu haben

[premultiply]

@naltatis wir könnten auch überlegen, die Zielzeit als „in xyz“ Dauer zu übergeben statt als Timestamp. Das würde Zeitzonen von FE und BE entkoppeln. Jedenfalls, solange keine Schaltstunde dazwischen hängt. Alternativ könnten wir nochmal schauen, ob wir überall einheitlich mit UTC unterwegs sind?

Hier ist es vermutlich hilfreich sich zu fragen: Was will der Nutzer?

Er möchte dass sein Fahrzeug zur angegebenen Zielzeit (=LOKALZEIT) geladen ist.
Dabei ist ihm die Zeit/Zeitzone/DST zum Eingabezeitpunkt und in der Zwischenzeit (DST-Sprünge) ziemlich egal.

Zeitspannen funktionieren daher nur wenn man auch dabei mögliche DST-Sprünge mit einberechnet.

Den Zielzeitpunkt und die verbleibende Dauer technisch mittels UTC zu verarbeiten ist daher nicht die schlechteste Variante.
Man muss nur aufpassen die Lokalzeit korrekt umgerechnet wird.
Dazu muss selbstverständlich auch die Zeitzoneninfo des Systems korrekt konfiguriert sein, was der ein oder andere Anwender vielleicht auch im Eifer des Gefechts mal vergisst... Doku-Thema.

[naltatis]

Ja, bei der Übermittlung der Zielzeit nutzten wir aktuell ja bereits UTC als Übergabe. Ich verifiziere das aber noch mal.

Dazu muss selbstverständlich auch die Zeitzoneninfo des Systems korrekt konfiguriert sein, was der ein oder andere Anwender vielleicht auch im Eifer des Gefechts mal vergisst... Doku-Thema.

Hier wäre theoretisch auch ne Erkennung vom Client her möglich und wir könnten ne Warnung ausspielen wenn die Serverzeit unplausible ist. Würde das aber, wie du schon schreibst, lieber erstmal nur in der Doku haben.

Eigentlich war 7:00 nur der Defaultwert, für die nächsten Tage wird dann die letzte gesetzte Uhrzeit verwendet. Zumindest war das die Idee, vielleicht aber noch nicht umgesetzt?

Bei der Implementierung der Default-Zeit haben wir leider vergessen das Zeitzonenthema zu berücksichtigen. Momentan verwendet die UI die Variable targetTimeHourSuggestion: Number um die Vorauswahl zu setzen. Hier laufen wir natürlich in Probleme wenn sich die Zeitzonen zwischen Client und Server unterscheiden.
Mein Vorschlag wäre, dass wir uns die letzte "aktivierte" Zielzeit (Stunde/Minute) nur im Browser merken (z.B. localStorage) und für diese beim nächste Mal wieder anzubieten. Der Wert targetTimeHourSuggestion würde dann aus der API verschwinden. Nachteil ist, dass wir dann keinen "Sync" zwischen Devices (Desktop/Phone) haben. Das halte ich aber erstmal für vertretbar.

[naltatis]

Ich hab mir zu dem Thema "Zeitvorschlag" einen Issue angelegt. Weitere Diskussion zu dem Thema gerne dort #2314

[ChristianNebendahl]

Hallo,
ich bin auf Euer Projekt EVCC gestossen und bin finde es sehr gut.
Mein Hyundai Ioniq Model 3 stellt leider keine SOC Daten zur Verfügung (kein BlueLink wie die späteren Modelle).
Da ich die Auto-Batterie typischerweise nicht über 80% lade, vermisse ich in EVCC eine einfache Einstellmöglichkeit (um z.B. per Schieberegler) die nachzuladende Energiemenge einstellen zu können.
Wird dies Feature noch nachgepflegt, falls keine SOC Daten abfragbar sind, um ein Zielladen zu ermöglichen?

[naltatis]

Eher unwahrscheinlich. Die evcc Basisfunktionen (Schnell, PV geführtes Laden, Energievisualisierung) funktionieren unabhängig von Fahrzeugdaten. Für die fahrzeugspezifischen Funktionen (Mindest-SoC, Zielladen, Ladelimit, Fahrzeugdaten) benötigen wir immer den SoC und müssen erkennen können um welches Fahrzeug es sich bei der Ladung gerade handelt. Eine UI über die man die gewünschte kWh-Anzahl für den Ladevorgang einstellt ist momentan nicht in Planung.

[andig]

@naltatis ich find die Idee gar nicht soo schlecht. Statt target SoC halt target kWh. Können wir aber im nächsten Meeting mal schauen. Sicher keine Prio.

[naltatis]

Ich hab gestern mal wieder Zielladen verwendet. Hat alles funktioniert. Das Auto war wie gewünscht um 8:00 auf 70%. Allerdings ist der Ladevorgang früher gestartet, als ich erwartet hätte. Kann es sein, dass hier noch was mit 1p/3p nicht passt? Mit einphasigem Laden hätte der Startzeitung Sinn ergeben. Mit 3p hätte es auch ein paar Stunde später getan.

v0.83

Ein paar Stunden vor dem Ladevorgang

[lp-1  ] DEBUG 2022/02/18 00:46:47 estimated charge duration: 5h38m0s to 70% at 4600W
[lp-1  ] DEBUG 2022/02/18 00:46:47 projected start: 2022-02-18 02:21:50 +0100 CET
[lp-1  ] DEBUG 2022/02/18 00:46:47 max charge current: 0A = 0A + -1.03A (237W @ 1p)

Bevor das Laden gestartet wird stellt evcc die Wallbox von 1p auf 3p um.

Anfang des Ladevorgangs

[lp-1  ] DEBUG 2022/02/18 02:23:07 estimated charge duration: 2h13m0s to 70% at 11730W
[lp-1  ] DEBUG 2022/02/18 02:23:07 projected end: 2022-02-18 04:36:00 +0100 CET
[lp-1  ] DEBUG 2022/02/18 02:23:07 desired finish time: 2022-02-18 08:00:00 +0100 CET
[lp-1  ] DEBUG 2022/02/18 02:23:07 target charging: slowdown (16A)

[premultiply]

Huch, weshalb ist denn da dieses slowdown/speedup und so noch immer drin? Das macht ja wenig Sinn...
Ausserdem sollte natürlich mit dem verfügbaren Maximum an Phasen gerechnet werden. Aber das hängt vermutlich eher mit der gesamten Phasenproblematik zusammen. Ich tue es mal auf meine Prüfliste.

[andig]

Erstmal schauen ob überhaupt mit 3p gerechnet wird...

[premultiply]

Hab gerade geschaut. Es wird der zuletzt eingestellte Wert verwendet statt "min(lp, vehicle)". Habs schon notiert und in meinem Draft als Merker geändert.

[andig]

Und v.a. müsste man beim 1p3p Charger ja von 3 ausgehen (falls nicht auf 1p verdrahtet). #2638. Ich mach einen Fix...

[hoermto]

Zielladen: ich darf Rückmeldung geben :-) steht im Fenster. - Version 0.91 master build, läuft in einem Ubuntu Dockercontainer.
Ich stelle Zielzeit morgen 07:30 ein, aber im Anschluss zeigt das Fenster als Zielzeit 09:30 an. Ich muss auf 05:30 konfigurieren, damit im Hauptfenster 07:30 steht. Wenn ich danach wieder in die Einstellung der Zielzeit gehe, steht auch 07:30 drin. "Aktivieren" addiert dann wiederum 2h drauf. Ich vermute ein Zeitzonenproblem?

Ansonsten super Sache, das evcc!

[naltatis]

Kannst du posten was im log steht wenn du die Zielzeit setzt?

Und bei gesetzter Zielzeit einmal den targetTime wert den der /api/state REST endpoint liefert?

Eigentlich nutzen wir inzwischen durchgängig UTC sodass Zeitzonenunterschiede zwischen Client und Server keine Probleme machen sollten.

[hoermto]

der docker host läuft mit UTC:

docker@docker:~$ date
Sun May 15 08:53:11 UTC 2022

Der Container ebenso. Zeit ist synchronisiert.

[hoermto]

Kannst du posten was im log steht wenn du die Zielzeit setzt?

Und bei gesetzter Zielzeit einmal den targetTime wert den der /api/state REST endpoint liefert?

Eigentlich nutzen wir inzwischen durchgängig UTC sodass Zeitzonenunterschiede zwischen Client und Server keine Probleme machen sollten.

Die Ausgabe im Log, wenn für "morgen 07:00" gesetzt wird in der GUI:

[lp-1  ] DEBUG 2022/05/15 08:58:11 charge power: 0W
evcc    | [site  ] DEBUG 2022/05/15 08:58:11 pv power: 10301W
evcc    | [site  ] DEBUG 2022/05/15 08:58:11 battery power: -3529W
evcc    | [site  ] DEBUG 2022/05/15 08:58:11 grid power: -5881W
evcc    | [lp-1  ] DEBUG 2022/05/15 08:58:11 set target charge: 100 @ 2022-05-16 07:00:00 +0000 UTC
evcc    | [site  ] DEBUG 2022/05/15 08:58:11 battery soc 0: 93%
evcc    | [site  ] DEBUG 2022/05/15 08:58:11 site power: -9310W
evcc    | [lp-1  ] DEBUG 2022/05/15 08:58:11 charge currents: [0 0 0]A
evcc    | [lp-1  ] DEBUG 2022/05/15 08:58:11 charger status: B
evcc    | [lp-1  ] DEBUG 2022/05/15 08:58:11 next soc poll remaining time: 59m39s
evcc    | [lp-1  ] DEBUG 2022/05/15 08:58:11 estimated charge duration: 43m0s to 100% at 11040W
evcc    | [lp-1  ] DEBUG 2022/05/15 08:58:11 projected start: 2022-05-16 06:17:03.333333334 +0000 UTC
evcc    | [lp-1  ] DEBUG 2022/05/15 08:58:11 pv charge current: 13.5A = 0A + 13.5A (-9310W @ 3p)
evcc    | [lp-1  ] DEBUG 2022/05/15 08:58:11 max charge current: 13.5A
evcc    | [site  ] DEBUG 2022/05/15 08:58:11 ----
evcc    | [lp-1  ] DEBUG 2022/05/15 08:58:11 charge power: 0W
evcc    | [site  ] DEBUG 2022/05/15 08:58:11 pv power: 10299W
evcc    | [site  ] DEBUG 2022/05/15 08:58:11 battery power: -3510W
evcc    | [site  ] DEBUG 2022/05/15 08:58:11 grid power: -5881W
evcc    | [site  ] DEBUG 2022/05/15 08:58:11 battery soc 0: 93%
evcc    | [site  ] DEBUG 2022/05/15 08:58:11 site power: -9291W
evcc    | [lp-1  ] DEBUG 2022/05/15 08:58:11 charge currents: [0 0 0]A
evcc    | [lp-1  ] DEBUG 2022/05/15 08:58:11 charger status: B
evcc    | [lp-1  ] DEBUG 2022/05/15 08:58:11 next soc poll remaining time: 59m39s
evcc    | [lp-1  ] DEBUG 2022/05/15 08:58:12 estimated charge duration: 43m0s to 100% at 11040W
evcc    | [lp-1  ] DEBUG 2022/05/15 08:58:12 projected start: 2022-05-16 06:17:03.333333334 +0000 UTC
evcc    | [lp-1  ] DEBUG 2022/05/15 08:58:12 pv charge current: 13.5A = 0A + 13.5A (-9291W @ 3p)
evcc    | [lp-1  ] DEBUG 2022/05/15 08:58:12 max charge current: 13.5A

Danach erscheint im Statusfenster der GUI 09:00:

[hoermto]

und noch der api/state:

{"result":{"auth":{"vehicles":{}},"batteryConfigured":true,"batteryPower":-7.9,"batterySoC":100,"currency":"EUR","gridConfigured":true,"gridPower":-5924,"homePower":920.2000000000004,"loadpoints":[{"activePhases":3,"chargeCurrent":8.452028985507246,"chargeCurrents":[0,0,0],"chargeDuration":13799000000000,"chargePower":0,"chargeRemainingDuration":-1,"chargeRemainingEnergy":7111.111111111111,"chargedEnergy":0,"charging":false,"connected":true,"connectedDuration":0,"enabled":true,"hasVehicle":true,"loadpoint":1,"maxCurrent":16,"minCurrent":6,"minSoC":0,"mode":"pv","phases":3,"targetSoC":100,"targetTime":"2022-05-16T07:00:00Z","targetTimeProjectedStart":"2022-05-16T06:17:03.333333334Z","title":"Parken links","vehicleCapacity":32,"vehicleOdometer":0,"vehiclePresent":true,"vehicleRange":0,"vehicleSoC":80,"vehicleTitle":"eSchlumpf"}],"prioritySoC":25,"pvConfigured":true,"pvPower":6852.1,"savingsSince":1652605605,"siteTitle":"Bitbi","tariffFeedIn":0.088893,"tariffGrid":0.2804}}

[naltatis]

@hoermto ich hab dazu mal einen Issue aufgemacht. #3382

[hoermto]

Noch ein kleines Detail beim GUI des Zielladens: Wenn ich am Abend für den nächsten Tag die Zeit einstelle, dann steht in der GUI "Morgen 07:00".
Wenn die GUI nicht komplett neu geladen wird, steht am nächsten morgen immer noch "Morgen ...". Ein GUI Refresh aktualisiert das auf "Heute 07:00".
Also könnte die GUI das auch mit aktualisieren. Ich habe auf dem IPhone einen Link auf evcc auf den Startbildschirm gelegt. Das verbleibt als App im Hintergrund, und dann erscheint dies.

[int5749]

Auch wenn dies aus meiner SIcht off-topic ist. Auf meinem iPhone funktioniert dies ohne Probleme.
Ich habe auch einen Shortcut auf der Mainpage und es gerade nochmal getestet.

1. EVCC am PC aufgerufen und eine Zielzeit heute Nachmittag eingestellt
2. EVCC auf dem iPhone gestartet, Zielzeit wird korrekt angezeigt
3. EVCC auf dem iPhone in den Hintergrund
4. Über den PC eine andere Startzeit eingestellt
5. EVCC auf dem iPhone ausgewählt => ursprüngliche Startzeit wurde angezeigt aber in ca. 0,8 Sekunden aktualisiert

Dies habe ich 3x hintereinander mit dem gleichen Ergebnis nachgestellt.

[hoermto]

Ja, hier gehts mir aber nicht um die Uhrzeit, sondern um das Prefix "Morgen" bzw "Heute" vor der Uhrzeit, welches über Mitternacht nicht von "Morgen" auf "Heute" wechselt, wenn die GUI nicht manuell aktualisiert ist.
Ist wirklich ein winziges Detail ..

[hoermto]

besten Dank. May 16, 2022 8:42 AM, "Michael Geers" wrote: @hoermto (https://github.com/hoermto) ich hab dazu mal einen Issue aufgemacht. #3382 (#3382) — Reply to this email directly, view it on GitHub (#1433 (reply in thread)), or unsubscribe (https://github.com/notifications/unsubscribe-auth/ALPTWBHHDE4LZF427IBTHP3VKHU37ANCNFSM5CXQY3HA). You are receiving this because you were mentioned.Message ID:

[andig]

Schön wäre ein Log der relevanten Daten als Datei: ohne abb modbus. Das könnte ich dann durchsuchen ohne mich in x anderen Logs auf der Seite hier zu verlaufen. So weiss ich noch nichtmal, mit welchem der Ladepunkte Du überhaupt ein Problem hast.

[kfussmann]

Also das Problem habe ich am lp-1 und das ist ja die ABB Wallbox. Daher halte ich es für unklug die abb modbus zu entfernen.
Ich stelle dir hier aber gern mein log als Rohfassung rein. Allerdings ist da auch eine Menge anderer Einträge. Ich habe leider nicht die Werkzeuge es einfach und schnell auf die relevanten Einträge einzukürzen, da es sich über einen Zeitraum von über 10 Stunden zieht. Deswegen hatte ich ja die "Schnipsel" der entscheidenen Zeitpunkte eingefügt. Sorry, aber ich hoffe du kommst mit diesem log dennoch zurecht.
log090922_zielladen.log

[andig]

Ich habe leider nicht die Werkzeuge es einfach und schnell auf die relevanten Einträge einzukürzen

Dann erstell gerne eine Config, die nur LP1 und Site zeigt.

[kfussmann]

Hallo @andig
danke nochmal für die Unterstützung. Hier nun endlich das Log vom Zielladen mit LP-1 und Site im Tracemodus.
log140922.log

Wie schon beim letzten Mal hat es nicht funktioniert. Ab dem Zeitpunkt des berechneten Startens vom Laden hat er "Charger our of sync" gebracht und nichts geladen. Dann das etwas Merkwürdige, ab dem Zeitpunkt wo das Ziel erreicht werden sollte (in meinem Fall ab 9:00 Uhr) hat er dann zwar weiter "charger our of sync" gebracht aber dennoch im Minutentakt den Strom hochgezogen und ganz kurz geladen. Also sehr misteriös, da ich nichts von außen verändert habe. Im weiteren Verlauf des Vormittags bin ich dann kurz weggefahren und als ich dann den EV wieder angesteckt habe, hat er bei genügend PV-Überschuß auch wieder problemlos geladen.

[andig]

aber nun läuft alles soweit rund.

Ich fürchte das tut es nicht. Solange Du massenhafte "Charger our of sync" Meldungen bekommst stimmt da etwas nicht und es macht wenig Sinn, fortgeschrittene Funktionen zu analysieren wenn die Basics nicht klappen. Anders gesagt: wenn evcc Deine Wallbox nicht freischalten kann, dann wundert mich auch nicht, dass kein Zielladen geht!

Lass uns den Grund dafür gerne in einem neuen Thread analysieren.

[emcepe]

Guten Abend.

Gehts nur mir so oder ist es normal/gewollt, dass das Ziel-Laden nach erneutem Anstecken des Autos nicht wieder aktiviert wird? Ich muss nach jedem mal abziehen und erneutem Anstecken das Ziel-Laden neu konfigurieren. Oder gibt's da eine Config Option die das persistieren würde?
Ich würde mir sowas vorstellen wie Ziel-Laden solange aktiv lassen bis das Ziel erreicht ist, also:
a) Ziel-SoC erreicht
b) die Zeit überschritten wurde
c) deaktiviert wurde.

Danke :)

P.S.: ich benutze wie immer die aktuellste evcc Version.

[andig]

Du kannst das am Auto konfigurieren 👍🏻

[emcepe]

Ja, das wäre möglich. Aber zum einen ist Bluelink eine halbe Katastrophe und zum anderen für mich oft einfach nicht nutzbar (kein Login mehr möglich), weil das API Limit bei Hyundai so niedrig ist.

Also ist das kein Bug was ich geschildert habe?

[VolkerK62]

Ich habe heute Morgen zum ersten Mal Zielladen eingestellt.
Dann kam der Hinweis auf eine neue Version (0.108.0).
Nach dem update, waren die Einstellungen beim Zielladen weg.
Die werden noch nicht gespeichert?

[andig]

Das sollten wir machen: #5271. Im Moment wird (noch) fast nix gespeichert...

[ThiloBaWue]

Nachdem endlich auch mein Mokka-e da ist kann ich auch tatsächlich Dinge ausprobieren. Zielladen ist ein super Feature, jedoch wäre es auch für mich extrem hilfreich, wenn man das Zielladen nicht jedes mal neu aktivieren müsste.
Bei mir würde jeden Morgen 90% (gerade im Winter wo eh nichts mit PV los ist) passen. Irgendwann vergesse ich das Zielladen zu aktivieren und stehe dann morgens fast blank da. Den MinSOC habe ich nur auf 30%. Wegen meinen dynamischen Strompreisen ist der Strom wenn ich komme einfach zu teuer und will das Sofortladen möglichst unterdrücken. So will ich immer in der Nacht laden. Ein Häkchen für immer um z.B. 5:00 Uhr Zielzeit würde genügen. Wenn dann noch die Funktion "lade zum günstigsten Preis kommt" bin ich fast wunschlos glücklich.

[RTTTC]

This would help you I think #5291

[schenlap]

Da ist dann immer noch offen dass die Zielzeit nicht automatisch gesetzt werden kann. Wäre übrigens auch ein Featurewunsch meiner Frau 👍

[andig]

Das ist #5492, sollten wir machen!

[PeterMichaelMueller]

Bis Dienstag morgen funktionierte das Zielladen ohne Probleme bei mir. KIA EV6, go-e-Charger V3 mit RFID Zugangskontrolle.
In der Nacht von Mittwoch auf Donnerstag gab es dann Probleme. Folgende Meldungen erhielt ich vom go-e Charger

• Ladelogik verändert, Nicht laden während der Phasenumschaltung
• Ladelogik verändert, Laden manuell freigegeben
• Ladevorgang beendet, 0.643 kWh in 00:03:57 geladen
• Ladelogik verändert, Nicht laden, warten auf Zugangskontrolle
• Auto verbunden, Ladevorgang nicht freigegeben
  Am Donnerstag morgen stand ic h dann mit fast leerem Auto da :-(
  Heute (Freitag) habe ich EVCC von 0.110.1 auf die Version 0.111.1 gehoben. Das Problem ist jedoch unverändert.
  Wenn ich auf den Modus "Schnell" gehe, funktioniert das Laden. Arbeite ich mit dem "Zielladen" erhalte ich das gleiche Problem.
  Am Auto und go-e Charger habe ich keine Updates vorgenommen.

Hat jemand eine Idee an was dies liegen könnte?
Bin für jeden Tipp dankbar.
Peter

[andig]

Mach bitte ein neues Thema mit Logfile. Ich schließe hier da uralt und größtenteils Off-topic.