SOC BMW

[Thomas_0508]

Bei mir wars auch am 5. Mai. Nach genau einer Woche ist die Verbindung abgerissen.
Die BMW App habe ich geöffnet und habe den Ladestand gecheckt.
Ansonsten hab ich nur ein Fahrzeug.

[heidanei]

Also bei mir läufts völlig problemlos, noch immer mit der ersten Verbindung die ich damals angelegt hab als Du mir die Testdatei geschickt hast. (Die läuft auch immer noch!)

heidanei

[treborst]

Soeben ist es wieder aufgetreten
Auto angesteckt, hat nicht geladen
Kontrolle in OWB, Zielladestand schon erreicht, Status zeigt den beschriebenen Fehler.
Auto neu bei BMW angemeldet, funktioniert wieder

[multi]

Im MINI-Stream ist folgender Datenpunkt nicht vorhanden:

vehicle.drivetrain.electricEngine.charging.level

Die anderen 4 habe ich gefunden. Hat jemand eine Idee?

Das ist bei mir auch so. Es gibt 32 Felder zu Charging aber nichts zu level. Ist das Fahrzeugabhängig? Ich habe einen iX1 30

Danke

[aiole]

Im MINI-Stream ist folgender Datenpunkt nicht vorhanden:
vehicle.drivetrain.electricEngine.charging.level
Die anderen 4 habe ich gefunden. Hat jemand eine Idee?

Das ist bei mir auch so. Es gibt 32 Felder zu Charging aber nichts zu level. Ist das Fahrzeugabhängig? Ich habe einen iX1 30
Danke

Ja - das ist fahrzeugabhängig.
s. Hinweise zu den topics hier: https://github.com/GERDerDennis/bmw-cardata-openwb

vehicle.drivetrain.electricEngine.charging.level (neuere Fahrzeuge)
vehicle.drivetrain.batteryManagement.header (Fallback für ältere Modelle)

Bei mir liefert xxx.header korrekten SoC. (i3)

[DerDennis]

Hallo zusammen, ich konnte den Fehler jetzt tatsächlich nachstellen.

Die BMW CarData API erlaubt nur 50 Abfragen pro Tag (Rolling Window über 24 Stunden). Wenn dieses Limit überschritten wird, antwortet BMW mit einem Fehler (CU-429). Soweit noch handhabbar.
Das eigentliche Problem ist: Das Modul fragt den SOC je nach Einstellung weiterhin ab, so das man über die 50 pro 24 Stunden kommt. Dadurch werden immer wieder Anfragen an den BMW Server verschickt. Was BMW dann macht ist das eigentlich Unangenehme: Nach wiederholten Limit-Überschreitungen invalidiert BMW den Refresh Token aktiv. Das bedeutet, die gespeicherte BMW-Kopplung in openWB wird ungültig und man muss sich neu anmelden, genau wie ihr es hier beschrieben habt.
Die Neukopplung war also die richtige Lösung.
Ich arbeite bereits an einem Fix im Modul: Sobald BMW einen CU-429 zurückmeldet, werden für die nächsten 24 Stunden keine weiteren Abfragen gesendet. Damit wird das "Nachtreten" gegen ein bereits erschöpftes Limit verhindert, und BMW hat keinen Grund mehr, den Token zu invalidieren.

Danke für die Rückmeldungen.

[heidanei]

Hi!

Hallo zusammen, ich konnte den Fehler jetzt tatsächlich nachstellen.
...
Danke für die Rückmeldungen.

Ich finde es echt toll wie Du Dich hier engagierst!
MMn. solltest Du das unbedingt so umsetzen.

Allerdings frage ich mich warum die Anzahl der Abfragen überhaupt überschritten wird. Aus meiner Sicht braucht während des Ladevorgangs gar nicht über die API abgefragt werden, da die lokale Berechnung - vor allem beim PV-Laden - eh genauer und schneller ist, da bis Gen.5, also fast allen bis Dato auf der Straße befindlichen BMW, der SoC nur bei Ladestart und Ende, zwischendrin aber nur sporadisch an die BMW-Cloud übertragen wird und überwiegend serverseitig nur interpoliert wird, was bei wechselnden Ladeleistungen wie beim PV-Laden nur suboptimal funktioniert. (Ab Gen.6 soll das anders sein, aber hier werden mit dem neuen iX3 gerade erst die ersten Fahrzeuge ausgeliefert.)
Wenn kein Fahrzeug angesteckt ist braucht MMn. auch der SoC nicht abgefragt werden. Also sollte _eigentlich_ nur eine einzige Abfrage pro Ladevorgang beim Anstecken des Fahrzeugs ausreichen. (Ansonsten kann man ja auch immer über den Kreispfeil manuell aktualisieren)
Bei mir funktioniert das jetzt seit dem 24. April mit zwei BMW's problemlos und ohne dass ich mich neu anmelden musste.

heidanei

[KLez]

Die API braucht allgemein nicht abgefragt werden, weil die CarData API einen MQTT Stream bereitstellt, der die Daten dann "Live" anbietet. Dann wäre das Thema Abfragelimit komplett vom Tisch. Ich hatte mit Dennis dazu bereits in einem anderen Thread geschrieben. REST war wohl einfacher zu implementieren, auch wenn ich es ehrlichgesagt nicht verstehe.

[DerDennis]

Hi,

du hast technisch recht – die BMW CarData API bietet tatsächlich einen MQTT-basierten Stream an. Lass mich erklären warum ich trotzdem REST gewählt haben:

Warum REST und nicht MQTT Stream?

Das native openWB Fahrzeugmodul-System ist für zyklische REST-Abfragen konzipiert. Jedes Modul implementiert eine `fetch_soc()` Funktion die von openWB in konfigurierbaren Intervallen aufgerufen wird. Das ist der standardisierte Weg wie alle ~20 anderen Fahrzeugmodule funktionieren (Tesla, VW, Renault usw.).

Ein MQTT-Stream würde bedeuten:
- Einen dauerhaft laufenden Hintergrunddienst der die BMW MQTT-Verbindung aufrechterhält
- Eigenes Reconnect-Management bei Verbindungsabbruch
- Integration in das openWB-Ereignissystem statt des Intervall-Systems
- Komplett andere Architektur außerhalb des bestehenden Modul-Frameworks

Viele Grüße
Dennis

[KLez]

Ja, die Problematik ist mir klar, weil die OpenWB Software (Script)-Architektur einfach schund ist. Dadurch ist erheblicher Aufwand bei allem nötig, was irgendwie nebenläufig betrieben werden muss. Trotzdem ist es für mich die einzig sinnvolle Implementierung.