wenn ich das richtig verstanden habe, gibt es SoC-Module, die nur den initialen SoC über die API beziehen und danach über die abgegebene Energiemenge den aktuellen SoC berechnen (müssen).
Ich würde mir wünschen, dass auch Module, die regelmäßig über die API einen neuen SoC-Wert bekommen, diese Berechnung nutzen könnten (und würden).
OpenWB bekommt den SoC unseres ID.3 über die VW API. Leider gibt es einige Situationen, bei denen das nicht sinnvoll funktionieren kann.
Das sind zum einen die Fälle, bei denen openWB gar keinen SoC bekommt (Änderungen an der API oder VW-Server/Internet down). Das könnte in der aktuellen Softwareversion halbwegs gut funktionieren, da ein SoC von 0% angenommen wird und daher lieber zu viel als zu wenig geladen wird (getestet habe ich das aber noch nicht).
Zum anderen gibt es die Situationen, bei denen zwar ein SoC ankommt, dieser aber falsch ist. Das passiert
1. Wenn ein Fahrer das Auto in den Gastnutzermodus oder Offlinemodus versetzt. Problematisch ist, wenn das direkt nach einem Vollladen auf 100% oder 80% passiert, da dann folgende Ladevorgänge mit SoC-Limit bockiert werden.
2. Wenn das Auto nur selten SoC-Updates schickt. Es macht teilweise auch bei aktivem Ladevorgang gerne mal eine Pause von einer Stunde oder mehr, was bei 11kW schon knapp 20% SoC ausmacht.
Beim Anstecken scheint aber zuverlässig ein Wert an VW geschickt zu werden, genauso bei "Start" des Ladevorgangs ("Stop"-->"Sofortladen"). Ich habe aber ein Beispiel, bei dem beim Ladestart selbst (Freischalten des Stroms durch openWB) kein aktueller Wert kam.
In jedem Fall kommt bei dem SoC-Abruf ein Zeitstempel mit, wann die Daten vom Fahrzeug erfasst wurden. Dieser "carCapturedTimestamp" kommt auch im SoC-Modul in openWB an:
Code: Alles auswählen
2025-02-18 21:55:22,660 - {modules.vehicles.vwid.api:86} - {DEBUG:fetch soc_ev1} - batteryStatus:
{
"value": {
"carCapturedTimestamp": "2025-02-18T20:00:19Z",
"currentSOC_pct": 40,
"cruisingRangeElectric_km": 137
}
}- Mit Anstecken holt sich openWB den SoC-Wert (darf auch gerne 10-20s warten, damit VW genug Zeit hat, den Wert zu verarbeiten).
- Wenn der SoC ungültig (API-Fehler), oder zu alt ist (älter als ein paar Minuten?), wird ein SoC von 0% angenommen.
- Ab diesem Zeitpunkt wird der SoC mit den Parametern des hinterlegten Fahrzeugs (Kapazität und Effizienz) berechnet.
- Im Rahmen des konfigurierten Abrufintervalls wird der SoC weiterhin über die API abgefragt. Wenn der Zeitstempel "neu" ist (z.B. kleiner Abfrageintervall), wird der SoC neu gesetzt und ab da neu gerechnet. API-Fehler werden ignoriert und weiter berechnet.
Dadurch ist Situation 1 etwas besser abgedeckt (Zielladen fängt zwar zu früh an, wartet aber zumindest bis zum letzten sicher möglichen Zeitpunkt und bei geeignetem (niedrigem) Ladeziel ist sogar noch etwas PV-Laden drin) und Situation 2 ist für die allermeisten Fälle gelöst.
Problematisch wären hier höchstens zusätzliche Verbräuche zum Vorheizen, etc.
Zusätzlicher Bonus: Das Sägezahnmuster in der Ladeleistung, das beim Zielladen manchmal insbesondere zum Ende hin auftritt, da sich der SoC nur alle paar Minuten aktualisiert, wäre auch Geschichte.
Mit relativ wenig zusätzlichem Aufwand (Speichern der geladenen Energiemenge und Zeitpunkt des letzten Abrufversuchs) kann das Modul sogar interpolieren, falls der abgerufene SoC schon ein paar Minuten alt ist. Das sollte aber eher nicht nötig sein.