BMW SoC: Tageslimit viel zu schnell verbraucht (binnen 4 Minuten)

[346L3]

Ich habe ein (für mich) seltsames Problem mit dem BMW CarData SoC-Modul:

Das Tageslimit der API wird - egal was ich einstelle - binnen kürzester Zeit erreicht.
Spätestens (hier hatte ich nachgesehen) um ~10 Uhr aktualisiert der SoC schon nicht mehr, d.h. binnen 8 Stunden nach Reset des Zählers bei BMW. Ich vermute eher schon früher...

Dies passiert ziemlich unabhängig von den Einstellungen:
Ich hatte Standardwerte ausprobiert (30 Minuten bei Ladung, 720 Minuten ohne Ladung). (rechnerisch 48 Calls/Tag) - was kein Problem sein dürfte.
Jedoch ist auch bei 60 Minuten b. Ladung, 720 Minuten & nur Aktualisieren wenn angesteckt ebenfalls schon Vormittags Schluss.

CarData Stream ist aktiv, ich habe mittlerweile auch mehrfach den Zugang bei BMW gelöscht, neu erstellt & die OpenWB frisch gekoppelt, da ich ausschließen wollte, dass weitere Clients außer der OpenWB ggf. API-Calls verbrauchen.

Es ist auch nur 1 BMW als Fahrzeug angelegt mit diesem SoC-Modul.

Bei "Status" sieht der SoC manchmal auch rel. komisch aus: der Status "flackert" zwischen grün und dem gelben Ausrufezeichen.
D.h. das Modul zeigt hin und wieder "OK" an, im Wechsel mit HTTP 500, 403 gegen BMW-Endpunkte und "Tageslimit erreicht (CU-429)".

Der Log der OpenWB geht leider nur 1 Stunde rückwirkend - gibt es eine Möglichkeit, einen ganzen Tageslog des SoC-Moduls aufzeichnen zu lassen?
Einmal, um rauszufinden, wie schnell nach 2:00 die Calls versagen, andererseits um ggf. die Rate an API-Calls abzuschätzen, die von der OpenWB ausgehen...

Verstehe ich CarData Stream so richtig, dass - falls es genutzt wird - die Call-Limitierung eigentlich sogar kpl. entfallen sollte, weil man auf Updates des Fzg "subscribed" und diese ohne Poll geliefert kriegt? Kann man dann die Zeiten noch weiter fassen?
Das Wiki sagt hierzu leider nichts... Die alte Anbindung war ja m.W. nach ohne CarData Stream (aber auch ohne hatte ich schon das Problem...)

[seaspotter]

Der Main-Log auf Details geht vielleicht nur eine Stunde rückwärts wichtig und interesanter hier wäre aber der SOC Log, der sollte deutlich länger zurückreichen. Diesen bitte mal hier auf https://paste.openwb.de hochladen und verlinken.

[346L3]

Da ich heute sehr spät zurückgekommen bin, konnte ich grade live zusehen:

• SoC direkt auslesen aus
• SoC berechnen b. Ladung aus
• Nur SoC per SoC-Modul Cardata

Ladepunkt der Pro (Hardware) eingestellt auf nur PWM ohne Fahrzeugerkennung/SoC:

OpenWB pollt den SoC zwischen 2-8s Intervallen (vmtl. je nach Durchlaufgeschwindigkeit, das ist wohl die maximale Geschwindigkeit?), API-Limit war wieder um 2:04 aufgebraucht.

[....] Bin auf deinen Fix gespannt, ob er die Ursache erledigt....
Ist ja damit eigentlich gesichert Bug.
Das Verhalten der OpenWB je Fahrzeug beim SoC-Update sollte ja kpl. aus den sichtbaren Config-Einstellungen vorhersehbar sein...

Überlegung von mir war noch, das Fzg komplett zu löschen und neu zu machen, aber würde ungern den Testcase entfernen, falls es damit dann weg ist.

[346L3]

@seaspotter Ich habe, da mir das keine Ruhe lässt (und auch sehr störend ist....) mal testweise das Fzg gelöscht, neu angelegt, direkt nur mit SoC per CarData konfiguriert, aktualisieren nur wenn angesteckt, kein direktes auslesen, kein berechnen.
Effekt ist der selbe, sogar wenn das Fzg nicht (!) steckt, wird alle ~4s CarData angefragt.

Ebenso ist mir nun im Main-Log aufgefallen, dass der "rohe" Datenstempel des CP uralt ist, wenn ich das richtig interpretiere?
2026-10-03 21:17:22,456 - {modules.common.store._api:26} - {DEBUG:set values cp1} - Raw data ChargepointState( [....] charge_state=False, plug_state=False, rfid=None, rfid_timestamp=1781560859, charging_current=0, charging_power=0, charging_voltage=0, power_factors=[0.0, 0.0, 0.0], soc=30, soc_timestamp=1788081048, evse_current=0, max_evse_current=None, vehicle_id=None, current_branch=Release, current_commit=2026-09-07 09:50:42 +0200 [3ced7f9ce], version=2.2.3, evse_signaling=None, max_charge_power=None, max_discharge_power=None)

Die Unix-Time im soc_timestamp ist Sonntag, 30.08. 11:xx - hier steckte zuletzt ein Audi am Lader, der ist aber als eigenes Fzg angelegt und wird auch autom. erkannt & kann SOC-Abfrage.

D.h. der CP-Timestamp ist nicht dauerhaft neuer als der von Cardata, sondern viel, viel älter?
Gibt es neben dem rohen Zeitstempel des Ladekontrollers der Pro noch einen EV-Stempel und einen CP-Stempel in Software?
Weißt du, ob man die irgendwie resetten kann?

Grob passt das auch zeitlich, dass mein Cardata ging, bis der Audi das erste mal steckte (paar Monate her)... War nämlich ein paar Tage glücklich mit mindest-soc laden usw...

Gibt es die Möglichkeit, mehr Trace laufen zu lassen, um auch im Log zu lesen, welche Funktion den refresh triggert?

2026-10-03 21:34:33,487 - {modules.update_soc:62} - {DEBUG:SoC} - EV3: Nach dreimaliger erfolgloser SoC-Abfrage wird ein SoC von 0% angenommen. 2026-10-03 21:34:35,236 - {modules.update_soc:62} - {DEBUG:SoC} - EV3: Nach dreimaliger erfolgloser SoC-Abfrage wird ein SoC von 0% angenommen. 2026-10-03 21:34:43,484 - {modules.update_soc:62} - {DEBUG:SoC} - EV3: Nach dreimaliger erfolgloser SoC-Abfrage wird ein SoC von 0% angenommen. 2026-10-03 21:34:44,689 - {modules.update_soc:62} - {DEBUG:SoC} - EV3: Nach dreimaliger erfolgloser SoC-Abfrage wird ein SoC von 0% angenommen.

Im Main-Log erscheint das oben immer in 2 verschiedenen Intervallen (binnen ~1-2s und dann das nächste 2s-Paket nach ca. 8s - und jedes davon wohl 3 calls an die BMW-Api)

[seaspotter]

Ja, es gibt tatsächlich zwei getrennte Zeitstempel: den rohen CP-Zeitstempel (chargepoint.py:736, kommt von der Pro selbst, wird gesetzt wenn der Ladecontroller direkt per PWM erfolgreich einen SoC ausliest - unabhängig davon, welches Fahrzeug openWB gerade zugeordnet ist) und den EV-seitigen Zeitstempel (kommt vom konfigurierten SoC-Modul, bei dir CarData). Der CP-seitige Wert wird nirgends zurückgesetzt, wenn sich das zugeordnete Fahrzeug ändert - er bleibt MQTT-retained einfach stehen, bis die Pro selbst wieder erfolgreich direkt ausliest.

Zum Zurücksetzen: Du hast bisher das Fahrzeug gelöscht/neu angelegt - das reicht leider nicht, weil der rohe Zeitstempel am Ladepunkt hängt, nicht am Fahrzeug. Wenn du stattdessen den Ladepunkt selbst löschst und neu anlegst, werden dabei alle retained MQTT-Topics darunter entfernt (inkl. get/soc_timestamp), der alte Audi-Wert wäre dann weg. Musst dann halt neu einstellen. Alternativ n Backup einspielen von davor, das würde auch gehen.

Alternative: #4036 abwarten. Danach ist der alte Zeitstempel kein Problem mehr - er würde dann einmalig (harmlos) ein Update auslösen und danach nicht mehr erneut, auch ohne dass du den Ladepunkt anfasst.

Zum Tracing: Der Trigger loggt bereits bei Details-Level mit log.debug("SoC nach Anstecken") direkt an der Stelle, wo force_soc_update gepublished wird - sollte also schon in deinem SoC-Log auftauchen, einfach nach dieser Zeile suchen.

[346L3]

@seaspotter Vielen Dank für deine Unterstützung und den Commit!

Habe meine openWB vor ein paar Tagen auf den Entwicklungszweig umgestellt und den BMW nicht angesteckt: Cardata wurde nur alle 12 Stunden - wie eingestellt - abgefragt.
Eben Auto angesteckt: Einmalig beim Anstecken SoC abgefragt und wieder "Funkstille" danach (kein Ladevorgang).

Die Änderung scheint der Fix gewesen zu sein.

Ich muss mich jetzt mal bei der Gelegenheit etwas mit der neuen Gerätesteuerung vertraut machen - und wenn die im Release ist wieder auf Release statt Entwicklungszweig umschwenken.

[seaspotter]

Das Freut mich, immer gern. Dann mach ich hier mal zu 👍 :)