Decrease selected target SoC to vehicle target SoC

[tobiasbayer]

I makes no sense selecting a higher target soc than the vehicle's target soc other than getting an estimate for charging to a higher soc as charging would stop at the vehicle's target soc anyway.
This pr decreases the slider to the vehicle's target soc if it is lower than the currently selected target soc on UI loads and vehicle target soc adjustments.
So the slider is at the vehicle target soc's position at most by default and can be increased manually if a different estimation is desired by the user.

[Caibuk]

I object: there is more sense in setting a higher target soc in evcc than in the car.

As I described here: #3586 (reply in thread), I regularly set target SoC in evcc higher than in my car to let my car charge to a certain SoC (the one set in the car) but still be able to precondition my car using full power from the wallbox.

For me it would be cumbersome to manually set a higher target SoC in evcc each time I connect my car to achieve the above mentioned state.

edit: maybe it would be sufficient to just mark the car's internal SoC limit in the GUI if it is below the one set in evcc (so users are not puzzled by the fact their car stopped charging for no obvious reason)

[tobiasbayer]

IMHO this use case (preheating with power from the charger) should be implemented with an additional switch or something instead of working around by setting fictional target socs.

edit for the edit :D the vehicle target soc is already marked in the ui. The reason for this pr was mainly getting wrong estimations for remaining charging time rather than being puzzled why charging stops.

[Caibuk]

IMHO this use case (preheating with power from the charger) should be implemented with an additional switch or something instead of working around by setting fictional target socs.

This is absolutely true. But progress on that front is a bit stale and discussions are going on since almost the start of the project.

Frankly, I don't see the benefit in changing the behaviour of evcc - while affecting user's workarounds - without introducing an valid alternative ...
Don't get me wrong, I like the reasoning behind your PR. But suspect it will cause some pain for me.

[Caibuk]

edit for the edit :D the vehicle target soc is already marked in the ui. The reason for this pr was mainly getting wrong estimations for remaining charging time rather than being puzzled why charging stops.

Oh, that is interesting. I've never seen that mark. Is this function available for e-up or Enyaq?

Where should I see it? Enyaq (left) and e-up (right) are both set to internaly limit of 90 %.

[tobiasbayer]

It has to be implemented in the respective car connector. I know it is there for Tesla (click the pr for a screenshot) and Hyundai/Kia.

[tobiasbayer]

This is absolutely true. But progress on that front is a bit stale and discussions are going on since almost the start of the project.

Frankly, I don't see the benefit in changing the behaviour of evcc - while affecting user's workarounds - without introducing an valid alternative ... Don't get me wrong, I like the reasoning behind your PR. But suspect it will cause some pain for me.

I see. Maybe one of the maintainers (@andig?) could shed a light on the situation and their preference on how to proceed with this pr?

[andig]

Was soll dieser PR tun und zu welchem Zweck?

[tobiasbayer]

#5080 (comment)

[andig]

Ich versteh nur Bahnhof 🤣

[tobiasbayer]

Der Ladezielregler steht per Default auf 100%. Wenn ich jetzt im Auto z.B. nur 80% eingestellt habe, dann wird mir z.B. die geschätzte Restladezeit falsch angezeigt. Auch hat der eingestellte Wert keinen Effekt, weil das Auto ja vorher schon aufhört zu laden.
Der PR schiebt beim Laden der UI den Regler runter, wenn im Auto weniger eingestellt ist (auf den im Auto eingestellten Wert).

Einwand von @Caibuk: er benutzt das als Workaround, um die Wallbox dazu zu bringen, Strom zum Vorheizen zur Verfügung zu stellen.
Das würde ich aber eher über einen Schalter lösen als mit so einem Workaround über das Ladeziel.

[andig]

Also wenn irgendwas würde ich lieber den Fehler der Restladezeit beheben? Dafür müsste man allerdings

• einfach das Minimum aus beiden Werten verwursten (trivial)
• verbindlich verstehen, ob die Fahrzeuge evtl. auf 100% oder ihr Soc Limit rechnen
• oder das Remaining Time Api einfach mal aus allen Fahrzeugen ausbauen und stattdessen nur noch auf den Estimator setzen- damit hätten wir volle Kontrolle

/cc @premultiply

[tobiasbayer]

Das ist ja nicht unbedingt ein Fehler. Kann sogar ein Feature sein, wenn ich gucken will, wie lange es bis 100% dauern würde. Aber es ist halt nicht der Default-Fall (Ladeziel Auto = Ladeziel evcc)

[andig]

Ich hab jetzt als Nutzen die Restladedauer verstanden? Siehe Kommentar drüber. Selbst wenn wir das wie hier im PR machen wollten würde die Logik m.E. ins Backend gehören, nicht ins UI.

[tobiasbayer]

Jetzt versteh ich nur noch Bahnhof. 😂

ad backend: wieso? Das ist doch ein reines Anzeigethema.

[andig]

dann wird mir z.B. die geschätzte Restladezeit falsch angezeigt.

das wär anders und im Backend zu lösen

[tobiasbayer]

Ok, ich hab’s jetzt noch drei mal gelesen und mutmaßlich verstanden. 😃
Grundsätzlich scheint es eine gute Idee zu sein, erst mal alles zu vereinheitlichen und dann die Kontrolle über die Restladezeit zu übernehmen und entsprechend auf den Vehicle Target SoC zu reagieren.
Verlorengehen würde dann die Möglichkeit, mal schnell den Regler auf 100% hochzuziehen um zu sehen, wie lange es noch bis dahin dauern würde, auch wenn das Auto grade bei 80% aufhören würde. Das wäre aber akzeptabel, denke ich (habe ich selbst noch nie gebraucht).

[andig]

Falls wir das machen wollen dann im Backend, insofern hier erstmal wontfix.

[tobiasbayer]

👍

[RTTTC]

In my case (Enyaq) time remaining is updated to correct value by car itself after some charge is pumped in. And then EVCC shows that updated time remaining.

On the other hand Enyaq does not show set-in-car target charge mark in EVCC, as it most like is not published by Skoda (VW?)

[Caibuk]

On the other hand Enyaq does not show set-in-car target charge mark in EVCC, as it most like is not published by Skoda (VW?)

I guess since ME3.0 software the target SoC (limit) is - among a lot more info - available in the "API". I use the home assistant integration Skoda Connect (https://github.com/lendy007/homeassistant-skodaconnect/) and this provides the limit (my car was updated to ME3.0 a couple of weeks ago).
In the integration it is misleadingly called minimum charge level.

[andig]

Note to self: check skodaconnect/skodaconnect@a342c8b

[andig]

Wer das im API hat gerne mit Zugangsdaten bei info@evcc.io melden.

[Caibuk]

Wer das im API hat gerne mit Zugangsdaten bei info@evcc.io melden.

E-Mail ist unterwegs.