evcc-io / evcc

Sonne tanken ☀️🚘
https://evcc.io
MIT License
3.32k stars 606 forks source link

Ladesession wird bei Fahrzeugwechsel nicht beendet/ neu gestartet #10623

Closed hoermto closed 10 months ago

hoermto commented 10 months ago

Describe the bug

Situation:1 Wallbox, 2 KFZ. Beide nicht mit SOC bekannt, aber als eigene Vehicle konfiguriert (1x 2P, 30kWh, 1x 3P, 80kWh) Stecker von einem ins andere Auto gesteckt. In der GUI das auto manuel umgestellt. Ladevorgang nicht aktiv, evcc in mode "auto/pv"

Konsequenz: 1) Ladelog / Ladesession wird weitergeführt 2) bereits geladene Lademenge wurde nicht zurückgesetzt. Dadurch wurde das zweite Fhzg nachts nicht geladen, obwohl "Cheap" time.

Wenn das Auto in der GUI gewechselt wird, sollte das wie ein komplett neuer Ladevorgang behandelt werden (abstecken/anstecken).

Steps to reproduce

  1. Auto an Wallbox stecken, etwas laden
  2. Auto wechseln oder Stecker raus und wieder rein, innerhalb kurzer Zeit
  3. in der GUI das Auto manuell umstellen/wechseln
  4. geladene Energiemenge bleibt bestehen, Ladeziel ebenfalls (gilt dann als erreicht)
  5. Automatikladen findet dann nicht mehr statt

Configuration details

- Wallbox: SmartWB
- Vehicle 1: 3P, 80kWh, ohne SOC Integration
- Vehicle 2: 2P, 32 kWh, ohne SOC Integration

Log details

...

What type of operating system are you running?

Linux

Version

0.120.3

andig commented 10 months ago

Wenn das Auto in der GUI gewechselt wird, sollte das wie ein komplett neuer Ladevorgang behandelt werden (abstecken/anstecken).

Sehe ich auch so!

premultiply commented 10 months ago

Nicht unbedingt denn bei einer manuell korrigierten Fehlzuordnung soll ja nicht alles bisher geladene verworfen werden.

Das Problem hier ist eigentlich nur dass evcc das Abziehen des Steckers nicht realisiert.

Hier ist interval zu lang.

andig commented 10 months ago

Hier ist interval zu lang.

Darum gehts nur bedingt. Wir können nie ausschließen, dass das Umstecken nicht schneller als interval erfolgt. Wenn das Fahrzeug sich nicht selbst über den Charger identifiziert können wir das nicht mitkriegen (...und auch einen ID-Wechsel würde wir heute- bei gleich bleibendem Status B/C- nicht auswerten).

Das Problem hab ich bei mir auch da beide Ladeports direkt nebeneinander liegen und das Umstecken sehr schnell geht.

Nicht unbedingt denn bei einer manuell korrigierten Fehlzuordnung soll ja nicht alles bisher geladene verworfen werden.

Der Hinweis ist natürlich richtig. Wie wollen wir das differenzieren?

premultiply commented 10 months ago

interval muss so kurz wie möglich aber so lang wie nötig sein.

Wie lang war es denn hier?

Den neuen Default von 30s halte ich hier für viel zu lang. Die gefühlte durchschnittliche Wahrheit hinsichtlich der Regelung liegt eher so zwischen 4 und 18s (je nach Kombination).

Oder wir müssen hier unterschiedliche Intervalle (oder vielfache davon?) für Status, Metering und Regelung (Stromänderung) verwenden.

Ein Disconnect sollte bzw. muss zuverlässig und zeitnah erkannt werden. Das ist ziemlich obligatorisch.

andig commented 10 months ago

interval muss so kurz wie möglich aber so lang wie nötig sein.

Das wird dennoch ein Problem bleiben. Bei mir dauert umstecken 3s!

Ein Disconnect sollte bzw. muss zuverlässig und zeitnah erkannt werden. Das ist ziemlich obligatorisch.

Das ist im allgemeinen Fall unmöglich solange die Charger uns nicht ein "war zwischendurch mal disconnected" Flag liefern.

hoermto commented 10 months ago

Hier ist das Interval bei evcc 15s, das Umstecken war vlt 5-10 sek. Da die Wallbox gepollt wird, ist der Status aus Sicht evcc zum jeweiligen Abfragezeitpunkt unverändert. Das ist auch ok, aber der manuelle Fahrzeugwechsel in der GUI sollte wie eine Neuverbindung laufen. Der Ladevorgang war zu dem Zeitpunkt nicht aktiv. Im worst case würde im Ladelog eine bestehende Session unterbrochen und eine neue eröffnet werden (was ja im Sinne des Nutzers wäre, wenn der das Auto wechselt). Jetzt wurde alles dem "neuen" Auto zugeordnet, und damit hatte ich dann rechnerisch 120% in das Auto geladen.

premultiply commented 10 months ago

Im worst case würde im Ladelog eine bestehende Session unterbrochen und eine neue eröffnet werden (was ja im Sinne des Nutzers wäre, wenn der das Auto wechselt).

Genau das ist bei einer Fehlzuordnung nicht gewünscht. Hier will man die bereits vorhandenen Sessiondaten unbedingt behalten und nur das Fahrzeug neu zuordnen.

Problem hier ist wirklich nur dass der Disconnect nicht erkannt wurde.

Hier könnte man theoretisch hilfsweise auf (sofern vorhanden) weitere Daten der Box zurückgreifen wie einem zwischen zwei Intervallen festgestellter Rücksprung von ChargeDuration und ChargedEnergy. Das wäre aber auch nur eine weitere Heuristik 🤔

andig commented 10 months ago

Genau das ist bei einer Fehlzuordnung nicht gewünscht. Hier will man die bereits vorhandenen Sessiondaten unbedingt behalten und nur das Fahrzeug neu zuordnen.

Können wir die Use cases differenzieren?

Das ist allerdings subtil.

/cc @naltatis

hoermto commented 10 months ago

Ist ein Edgecase. Mein eigentliches Problem ist gewesen, dass aufgrund der vorigen Ladung das andere Auto wegen Erreichen des Ladelimits nicht mehr "cheap" geladen hat. Hier dachte ich eigentlich, dass Cheap und PV immer die Ladung aktivieren, auch wenn ein vorgegebenes Ladelimit erreicht wurde? Ansonsten könnte ich mir einen Button vorstellen, die Ladesession neu zu starten, oder beim Wechsel des Vehicle über die GUI zu fragen, ob eine neue Session gestartet werden soll, oder die alte fortgesetzt werden soll.

andig commented 10 months ago

Das ist jetzt aber OT!

Mein eigentliches Problem ist gewesen, dass aufgrund der vorigen Ladung das andere Auto wegen Erreichen des Ladelimits nicht mehr "cheap" geladen hat. Hier dachte ich eigentlich, dass Cheap und PV immer die Ladung aktivieren, auch wenn ein vorgegebenes Ladelimit erreicht wurde?

Nein, ein Limit ist ein Limit. Das dient ja v.a. der "Akkuschonung". In https://github.com/evcc-io/evcc/issues/10330 werden wir aber die Ziele für den Plan (das Minimum zum Zeitpunkt) und PV (das Maximum das so Überschuss vorhanden ins Fahrzeug soll) voneinander trennen.

andig commented 10 months ago

Das ist allerdings subtil.

Also was machen wir jetzt- works as implemented?

premultiply commented 10 months ago

Erstmal, ja. Vielleicht sollten wir zukünfitg die Poll- und Regelintervalle differenzieren. Damit würde dies hier dann auch gelöst oder zumindest reduziert.