SOC aktualisierung am Ladeende

[rleidner]

Hmm, interessant, der relevante Teil des Log ist:

Code: Alles auswählen

2025-03-26 13:36:09,516 - {modules.common.configurable_vehicle:59} - {DEBUG:fetch soc_ev5} - General Config GeneralVehicleConfig(use_soc_from_cp=False, request_interval_charging=300, request_interval_not_charging=1800, request_only_plugged=False)
2025-03-26 13:39:30,582 - {modules.common.configurable_vehicle:59} - {DEBUG:fetch soc_ev6} - General Config GeneralVehicleConfig(use_soc_from_cp=False, request_interval_charging=300, request_interval_not_charging=43200, request_only_plugged=False)

Das erklärt warum
- der i4 (request_interval_not_charging=43200) nicht mehr abfragt
- der vw (request_interval_not_charging=1800) schon.
Ich würde das non-charging Intervall des i4 einfach noch mal ändern und neu speichern.

Weiter ist dies interessant:

Code: Alles auswählen

2025-03-26 13:24:45,802 - {modules.vehicles.bmwbc.api:161} - {INFO:fetch soc_ev6} -  SOC/Range: 96%/349.0KM@2025-03-26T13:24:40Z
2025-03-26 13:24:45,812 - {modules.common.store._api:31} - {INFO:store soc_ev6} - Saving CarState(soc=96, range=349.0, soc_timestamp=1742995485.803082)
2025-03-26 13:29:43,594 - {modules.vehicles.bmwbc.api:161} - {INFO:fetch soc_ev6} -  SOC/Range: 99%/383.0KM@2025-03-26T13:29:38Z
2025-03-26 13:29:43,605 - {modules.common.store._api:31} - {INFO:store soc_ev6} - Saving CarState(soc=99, range=383.0, soc_timestamp=1742995783.59565)
2025-03-26 13:34:39,415 - {modules.vehicles.bmwbc.api:161} - {INFO:fetch soc_ev6} -  SOC/Range: 99%/383.0KM@2025-03-26T13:34:35Z
2025-03-26 13:34:39,427 - {modules.common.store._api:31} - {INFO:store soc_ev6} - Saving CarState(soc=99, range=383.0, soc_timestamp=1742996079.416491)
2025-03-26 13:39:38,696 - {modules.vehicles.bmwbc.api:161} - {INFO:fetch soc_ev6} -  SOC/Range: 99%/383.0KM@2025-03-26T13:39:33Z
2025-03-26 13:39:38,707 - {modules.common.store._api:31} - {INFO:store soc_ev6} - Saving CarState(soc=99, range=383.0, soc_timestamp=1742996378.697174)
2025-03-26 15:35:08,463 - {modules.vehicles.bmwbc.api:161} - {INFO:fetch soc_ev6} -  SOC/Range: 100%/390.0KM@2025-03-26T15:34:59Z
2025-03-26 15:35:08,474 - {modules.common.store._api:31} - {INFO:store soc_ev6} - Saving CarState(soc=100, range=390.0, soc_timestamp=1743003308.465068)
2025-03-26 15:40:05,956 - {modules.vehicles.bmwbc.api:161} - {INFO:fetch soc_ev6} -  SOC/Range: 99%/390.0KM@2025-03-26T15:40:01Z
2025-03-26 15:40:05,967 - {modules.common.store._api:31} - {INFO:store soc_ev6} - Saving CarState(soc=99, range=390.0, soc_timestamp=1743003605.957061)
2025-03-26 15:45:03,517 - {modules.vehicles.bmwbc.api:161} - {INFO:fetch soc_ev6} -  SOC/Range: 99%/390.0KM@2025-03-26T15:44:59Z
2025-03-26 15:45:03,531 - {modules.common.store._api:31} - {INFO:store soc_ev6} - Saving CarState(soc=99, range=390.0, soc_timestamp=1743003903.518454)
2025-03-26 15:50:00,044 - {modules.vehicles.bmwbc.api:161} - {INFO:fetch soc_ev6} -  SOC/Range: 99%/390.0KM@2025-03-26T15:47:20Z
2025-03-26 15:50:00,053 - {modules.common.store._api:31} - {INFO:store soc_ev6} - Saving CarState(soc=99, range=390.0, soc_timestamp=1743004200.045586)
2025-03-26 15:54:55,760 - {modules.vehicles.bmwbc.api:161} - {INFO:fetch soc_ev6} -  SOC/Range: 99%/390.0KM@2025-03-26T15:54:52Z
2025-03-26 15:54:55,771 - {modules.common.store._api:31} - {INFO:store soc_ev6} - Saving CarState(soc=99, range=390.0, soc_timestamp=1743004495.761631)
2025-03-26 15:59:52,310 - {modules.vehicles.bmwbc.api:161} - {INFO:fetch soc_ev6} -  SOC/Range: 99%/390.0KM@2025-03-26T15:59:48Z
2025-03-26 15:59:52,320 - {modules.common.store._api:31} - {INFO:store soc_ev6} - Saving CarState(soc=99, range=390.0, soc_timestamp=1743004792.310948)
2025-03-26 16:05:10,636 - {modules.vehicles.bmwbc.api:161} - {INFO:fetch soc_ev6} -  SOC/Range: 99%/390.0KM@2025-03-26T16:02:06Z
2025-03-26 16:05:10,647 - {modules.common.store._api:31} - {INFO:store soc_ev6} - Saving CarState(soc=99, range=390.0, soc_timestamp=1743005110.637513)
2025-03-26 18:02:24,789 - {modules.vehicles.bmwbc.api:161} - {INFO:fetch soc_ev6} -  SOC/Range: 100%/390.0KM@2025-03-26T16:15:13Z
2025-03-26 18:02:24,801 - {modules.common.store._api:31} - {INFO:store soc_ev6} - Saving CarState(soc=100, range=390.0, soc_timestamp=1743012144.790914)
2025-03-26 18:12:40,316 - {modules.vehicles.bmwbc.api:161} - {INFO:fetch soc_ev6} -  SOC/Range: 100%/395.0KM@2025-03-26T18:12:32Z
2025-03-26 18:12:40,326 - {modules.common.store._api:31} - {INFO:store soc_ev6} - Saving CarState(soc=100, range=395.0, soc_timestamp=1743012760.317718)

Die Zeitstempel (links wie nach dem @ ) sollten eigentlich lokale Zeit sein aber das ist nicht so wichtig.
bis 2025-03-26 13:39:38 99% im 5 min Intervall dann Ladeende.
um 2025-03-26 15:35:08 100%, also nach einer knappen Stunde, also mehr als 30 min, ab hier wieder im 5 min Intervall
2025-03-26 15:40:05 99%
2025-03-26 15:45:03 99%
...
bis 2025-03-26 16:05:10 99% hier endet 5 min Intervall
Dann wird nicht mehr abgerufen wegen der 720 Min bis
Um 2025-03-26 18:02:24 100% manuell abgerufen wird.
Die 100% bzw. dann wieder 99% und später manuell 100% kommen so vom BMW-Server.
Es sind auch immer aktuelle Zeitstempel nach dem @, die werden so vom BMW-Server gemeldet.
D.h. der Wagen lädt, stoppt dann für , und beginnt dann noch mal für ca. 30 min weiter zu laden, weil der SoC auf 99% ist.
Könnte es sein dass der i4 hier ein Zellen-Balancing gemacht hat?

[Meli]

ich habe den Wert noch mal geändert und wieder zurück auf 30 minuten gesetzt, evtl bringt das ja was.

Um 16:35 war dann wirklich noch einmal bis 17:05 ein Nachladen (ausgelösst durch die Klimaautonmatik)
also einmal 100% und dann nur die 99%

Die zeit ist übrigens doch wirklich um eine Stunde gegenüber der GUI versetzt (passt auch zur Klimaeinstellung in der APP) , oder sehe ich das etwas falsch ?

[rleidner]

OK, das mit der Klima erklärt die 2. "Ladephase" mit 99%.
Wenn das Intervall jetzt korrekt gespeichert ist, sollte es funktionieren wie "designed".

Zum eigentlichen Thema:
Eine weitere automatische Abfrage nach Ladeende wäre zentral zu implementieren, die SoC-Module können da nichts ausrichten. Von "aussen" (home automation z.B. node red) ginge es allerdings auch per MQTT.

[Meli]

Ja, jetzt scheint es zumindest so weit wie zu erwarten zu funktionieren.

Soll bedeuten , die 100% sind eine halbe Stunde nach Ladeende in der GUI.

An welcher Stelle wäre denn die Änderung im System notwendig, wenn so ein "Nachlauf" der kurzen Pollingzeit rein kommen würde?
Evtl. sogar als Option in der GUI.

[rleidner]

Super, dann bleibt ein eher kosmetisches "Problem" übrig.
Wie bereits geschrieben, das müsste im zentralen Teil der Ladesteuerung realisiert werden.
Ähnlich wie beim Anstecken der SoC abgerufen wird, müsste beim Charge-Stop das ebenfalls eingebaut werden.

[rleidner]

Ich habe mal das Aktualisieren des SoC nach Ladestopp realisiert.
Es funktioniert und ist nicht wirklich kompliziert.

Ich könnte dazu einen PR erstellen, möchte aber erst Folgendes klären:
Es stellt sich die Frage was genau wir als Ladestopp definieren:
a) Jede Ladeunterbrechung also auch Unterbrechung im PV-Modus - jeder Wechsel des Ladestatus von True nach False
b) Ladestopp im Sinn "weiterladen nicht mehr möglich" - da wird z.B. auch eine evtl. laufende OCPP-Transaction abgeschlossen.

Ich vermute die initiale Fragestellung zielt eher auf a)?
Meinungen?

[Meli]

Ja, Ich würde auch eher zu a) tendieren.

In der Situation ist ja aus Sicht der Wallbox das Laden weiter möglich. Das Auto nimmt nur nichts mehr ab.

Hast du noch eine einzelne zusätzliche SOC Abfrage eingebaut ? und wenn ja, wann ?
Oder hast du dich am kurzen Poll-Abstand orientiert und den Timer quasi weiterlaufen lassen?

[rleidner]

Ja, Ich würde auch eher zu a) tendieren.

In der Situation ist ja aus Sicht der Wallbox das Laden weiter möglich. Das Auto nimmt nur nichts mehr ab.

Hast du noch eine einzelne zusätzliche SOC Abfrage eingebaut ? und wenn ja, wann ?
Oder hast du dich am kurzen Poll-Abstand orientiert und den Timer quasi weiterlaufen lassen?

OK, dann werde ich den PR so einreichen. Ich bin gespannt, ob es akzeptiert werden wird.
Was passiert technisch:
An den Intervallen hängt das nicht.
Neu ist: Im chargepoint Modul wird in jedem Durchlauf der Ladestatus/charge_state für alle Ladepunkte geprüft; wenn der von Laden auf Nicht-Laden wechselt (Ladestopp oder Ladeunterbrechung) wird für das angeschlossene Fahrzeug ein Soc-Abruf erzwungen. Der aktualisierte SoC sollte dann kurz nach dem Ladestopp im UI sichtbar werden.
PR: https://github.com/openWB/core/pull/2287

[aiole]

Hältst du dabei noch die konfigurierten Mindestpausenzeiten zw. den SoC-Abrufen ein? Nicht, dass zu häufiges SoC-Abfragen die Serverseite zur Sendungsverweigerung bringen.
Sollte durch "bei jedem Durchlauf" gewährleistet sein, oder?

[rleidner]

Hältst du dabei noch die konfigurierten Mindestpausenzeiten zw. den SoC-Abrufen ein? Nicht, dass zu häufiges SoC-Abfragen die Serverseite zur Sendungsverweigerung bringen.
Sollte durch "bei jedem Durchlauf" gewährleistet sein, oder?

Ich habe schon darüber nachgedacht. Generell sollte es keine Probleme geben.
Es sind auch nur einige EV-Hersteller, die zu häufige Abrufe mit Blockierungen "bestrafen".

Welche Fälle von Ladeunterbrechung/Ladestopp gibt es:
- Ladeende weil Fahrzeug voll: hier wird einmal (mehr) der SoC abgerufen - sollte unkritisch sein.
- Ladeunterbrechung bei PV-Laden: Ist über die Einstellungen steuerbar. Zu häufige Umschaltungen sollten vermieden werden um die Elektronik/Schütze zu schonen.
- Ladeunterbrechung bei Phasenumschaltung: sollte wegen der 16 Minuten unkritisch sein.

Der BMW&Mini SoC-Modul, der für diese "Bestrafung" bekannt ist, hat in der neuesten Version schon eine eingebaute Mindestzeit von 5 Minuten zwischen den Anfragen an den CD-Server. Das wurde notwendig um Accounts mit mehreren BMW&Mini-Fahrzeugen zu unterstützen. Häufigere Abfragen werden innerhalb des Moduls aus dem "Cache" beantwortet.

Diese Cache-Logik könnte man im Fall der Fälle auch in andere Module einbauen, die vom EV-Hersteller für zu häufige Anfragen "bestraft" werden.

Ich selbst benötige das nicht, ich kann mir aber vorstellen, dass es use-cases dafür gibt.