openWB Forum

Hi Chris,

ja, die verfügbaren Datenpunkte hängen vom Fahrzeug ab. Das Script prüft automatisch beide Felder:

vehicle.drivetrain.electricEngine.charging.level
vehicle.drivetrain.batteryManagement.header

Bitte aktiviere vehicle.drivetrain.batteryManagement.header in deiner CarData Datenauswahl – das sollte für deinen iX3 und i3s funktionieren. Feedback ob es klappt wäre super!

Viele Grüße
Dennis

Hi Dennis!

Danke, so bin ich schon ein Stück weiter!
Aber bei der Abfrage gibt es dann einen Fehler.
Grundsätzlich funktioniert die Abfrage bei Cardata, die VIN wird korrekt ausgegeben.
Aber dann verschluckt er sich wohl. Sorry, habe Null Python Kenntnis .
Anbei die Meldung vom Raspi:

raspberry@raspi3:~ $ python bmw_cardata_bridge.py
2026-03-24 18:49:46
• [INFO] Start (VIN: •..xxxxxx)
2026-03-24 18:49:46 [INFO]
container-ID wird einmalig via API ermittelt und gespeichert..•
Traceback (most recent call last):
File "/home/raspberry/bmw_cardata_bridge.py", line 310, in <module> main ()
-~-A
File "/home/raspberry/bmw_cardata_bridge.py", line 287, in main
data = fetch_data(token)
File "/home/raspberry/bmw_cardata_bridge.py", line 185, in fetch_data
raise RuntimeError ("Keine aktiven container!")
RuntimeError: Keine aktiven container!
raspberry@Rasp13:~ $

DerDennis hat geschrieben: Mo Mär 23, 2026 8:09 pm ich habe einen funktionierenden Proof of Concept für ein BMW CarData SoC Modul erstellt.

Bei allem Respekt vor Deiner Arbeit, aber warum pollst Du die CarData Daten per REST-API? Der Vorteil von CarData ist, dass die Daten bereits per MQTT Stream kommen. Wie ich hier schonmal geschrieben hatte, gibt es dafür schon länger ein Modul: https://github.com/dj0abr/bmw-mqtt-bridge
Das ist die technisch bessere Lösung weil die Daten sofort vorliegen, sobald sie auf dem BMW Server aktualisiert werden.

Das einzige was hier hätte getan werden müssen ist die Topics auf die der OpenWB "umzumappen".

Hi,

danke für den Hinweis auf die bmw-mqtt-bridge – die kenne ich und sie ist technisch interessant. Ich möchte aber erklären, warum ich mich bewusst für die REST-API entschieden haben und was mein Ansatz anders macht.

Der grundlegende Unterschied ist das Ziel: Ich entwickel ein natives openWB-SoC-Modul, das direkt in openWB integriert ist – ohne externe Abhängigkeiten. Die bmw-mqtt-bridge ist ein externes Tool, das dauerhaft auf einem separaten System (NAS, Raspberry Pi etc.) laufen muss. Das ist prinzipiell derselbe Ansatz wie mein Bridge-Script, das ich bereits veröffentlicht habe: https://github.com/GERDerDennis/bmw-cardata-openwb

Was mein natives Modul konkret leistet:

- Vollständige Integration in openWB – kein externes System nötig
- Konfiguration direkt in der openWB-Oberfläche (Client ID, VIN, Testmodus)
- BMW OAuth Device Flow direkt aus der openWB-UI anstoßbar
- Testmodus ohne einen einzigen BMW-API-Call
- Token- und Container-ID werden persistent gespeichert, dadurch typischerweise nur 1 API-Call pro Poll
- Sauberes Fehlerhandling für das BMW-Tageslimit (50 Calls/Tag)

Zur Frage ob 50 REST-Calls/Tag reichen: Ja, bei einem sinnvollen Poll-Intervall von 30 Minuten sind das maximal 48 Calls pro Tag – das passt genau.

Zur Zukunft: Ein MQTT-Stream-Modus wäre technisch sicherlich eine sinnvolle Ergänzung, da er Echtzeit-Updates liefert und kein Tageslimit hat. Das steht auf der Roadmap als optionaler zweiter Modus. Für die initiale Integration ist REST aber der richtigere Weg, weil er einfacher zu implementieren, zu debuggen und für den Endnutzer einfacher einzurichten ist.

Der aktuelle Stand:
- Modul funktioniert mit echten BMW-Daten (getestet mit iX M60, SoC und Reichweite)
- UI-Integration ist in Arbeit
- PR für openWB/core und openwb-ui-settings folgt

Feedback und Tester sind weiterhin willkommen!

Viele Grüße
Dennis

Hi,
ich würde gerne testen, dazu bräuchte ich aber Hilfe bei oben genannter Fehlermeldung. Ich bekomme das aufgrund fehlendem Container irgendwie nicht zum Laufen.

Gruß,
Chris

Hi Dennis!

DerDennis hat geschrieben: Di Mär 24, 2026 5:21 pm Hi Chris,

ja, die verfügbaren Datenpunkte hängen vom Fahrzeug ab. Das Script prüft automatisch beide Felder:

vehicle.drivetrain.electricEngine.charging.level
vehicle.drivetrain.batteryManagement.header

Bitte aktiviere vehicle.drivetrain.batteryManagement.header in deiner CarData Datenauswahl – das sollte für deinen iX3 und i3s funktionieren. Feedback ob es klappt wäre super!

Ich finde es super, dass Du Dich dem Modul angenommen hast!
Leider komme ich im Moment grad nicht dazu, das Testmodul auszuprobieren, ich hoffe dass ich mich am WE mal damit beschäftigen kann.

Aber ich habe schon mal für meine beiden Fahrzeuge die Cardata-Streams konfiguriert, dabei ist mir aufgefallen dass entgegen Deiner Doku für meinen iX1 (BJ 11/23, OS9, i-Stufe 26-03-530) ebenfalls nur das "alte" Feld "...batteryManagement.header" für den SoC vorhanden ist.

Aufgrund der begrenzen Abfragen: Die Abfrage alle 30min. per Cron ist für das Testscript ok, aber für das spätere Modul ist das MMn. nicht praktikabel, da es so bis zu 30min. dauern kann bis der Ladevorgang gestartet wird. Die Abfrage sollte MMn _einmalig_ direkt nach dem Anstecken des Fahrzeuges erfolgen und anschließend der SoC auf Basis der geladenen Energie berechnet werden oder - idealerweise konfigurierbar - dann in kürzeren Intervallen erfolgen solange das Fzg. angesteckt ist. Eine zyklische Abfrage bei nicht angestecktem Fahrzeug sollte abschaltbar sein.

BTW: Wird das fertige Modul mit mehreren Fahrzeugen umgehen können?

Viele Grüße, Michael

DerDennis hat geschrieben: Do Mär 26, 2026 6:42 am Der grundlegende Unterschied ist das Ziel: Ich entwickel ein natives openWB-SoC-Modul, das direkt in openWB integriert ist

Ah... Missverständnis meinerseits. Ich hatte nicht verstanden, dass das Script nur ein Test-Zwischenschritt ist.

Ich möchte trotzdem dringend empfehlen auf den MQTT Stream zu schwenken und dies auch in Zukunft nicht optional anzubieten, sondern als einziges und damit zwingend. Die Vergangenheit hat gezeigt, dass Autohersteller ihre APIs sehr schnell sperren oder kostenpflichtig machen, sobald die Menge der API Calls durch die steigende vielzahl an SmartHome Systemen zunimmt. BMW war bislang sehr fair das ganze (noch) kostenlos anzubieten, aber auch BMW hat sicherlich eine Schmerzgrenze.

Ich verstehe den Ansatz die erste Implementierung möglichst einfach umzusetzen, aber bekanntermaßen hält nichts länger als ein Provisorium und ich befürchte, dass wenn es per API Calls erstmal funktioniert, es auf absehbare Zeit auch so bleiben wird. Weiterhin gutes gelingen!

Frizzel hat geschrieben: Do Mär 26, 2026 10:22 am Hi,
ich würde gerne testen, dazu bräuchte ich aber Hilfe bei oben genannter Fehlermeldung. Ich bekomme das aufgrund fehlendem Container irgendwie nicht zum Laufen.

Gruß,
Chris

Hi Chris,

ich habe dir eine PN geschrieben. Schau mal in dein Postfach, wenn du mir schreiben kannst was genau bei der Ausgabe angezeigt wird kann ich bestimmt helfen.

heidanei hat geschrieben: Do Mär 26, 2026 11:30 am Hi Dennis!

DerDennis hat geschrieben: Di Mär 24, 2026 5:21 pm Hi Chris,

ja, die verfügbaren Datenpunkte hängen vom Fahrzeug ab. Das Script prüft automatisch beide Felder:

vehicle.drivetrain.electricEngine.charging.level
vehicle.drivetrain.batteryManagement.header

Bitte aktiviere vehicle.drivetrain.batteryManagement.header in deiner CarData Datenauswahl – das sollte für deinen iX3 und i3s funktionieren. Feedback ob es klappt wäre super!

Ich finde es super, dass Du Dich dem Modul angenommen hast!
Leider komme ich im Moment grad nicht dazu, das Testmodul auszuprobieren, ich hoffe dass ich mich am WE mal damit beschäftigen kann.

Aber ich habe schon mal für meine beiden Fahrzeuge die Cardata-Streams konfiguriert, dabei ist mir aufgefallen dass entgegen Deiner Doku für meinen iX1 (BJ 11/23, OS9, i-Stufe 26-03-530) ebenfalls nur das "alte" Feld "...batteryManagement.header" für den SoC vorhanden ist.

Aufgrund der begrenzen Abfragen: Die Abfrage alle 30min. per Cron ist für das Testscript ok, aber für das spätere Modul ist das MMn. nicht praktikabel, da es so bis zu 30min. dauern kann bis der Ladevorgang gestartet wird. Die Abfrage sollte MMn _einmalig_ direkt nach dem Anstecken des Fahrzeuges erfolgen und anschließend der SoC auf Basis der geladenen Energie berechnet werden oder - idealerweise konfigurierbar - dann in kürzeren Intervallen erfolgen solange das Fzg. angesteckt ist. Eine zyklische Abfrage bei nicht angestecktem Fahrzeug sollte abschaltbar sein.

BTW: Wird das fertige Modul mit mehreren Fahrzeugen umgehen können?

Viele Grüße, Michael

Hi Michael,

danke für das Feedback!

Zum SoC-Feld beim iX1: Interessant, das ist eine wichtige Info. Es scheint als ob das neuere Feld 'charging.level' nicht nur vom Fahrzeugalter abhängt sondern auch von der i-Stufe. Unser Modul prüft automatisch beide Felder und fällt auf 'batteryManagement.header' zurück falls 'charging.level' nicht vorhanden ist – das sollte also für deinen iX1 direkt funktionieren.

Zum Abfrageintervall hast du absolut recht. Das Cron-Script war nur für das externe Bridge-Script gedacht. Das native openWB-Modul funktioniert anders – openWB selbst steuert das Abfrageintervall. In den Fahrzeugeinstellungen kannst du bereits jetzt konfigurieren:
• Intervall während der Ladung (z.B. alle 5 Minuten)
• Intervall ohne Ladung (z.B. alle 720 Minuten)
• 'Nur aktualisieren wenn angesteckt'

Das ist also bereits genau so lösbar wie du es dir vorstellst – einmalig nach dem Anstecken plus berechneter SoC während der Ladung über die 'SoC während Ladung berechnen' Option.

Zur Frage mehrere Fahrzeuge: Ja, da jedes Fahrzeug in openWB eine eigene Konfiguration mit eigener Client ID und VIN bekommt funktioniert das mit beliebig vielen Fahrzeugen.

Viele Grüße
Dennis

KLez hat geschrieben: Do Mär 26, 2026 12:14 pm

DerDennis hat geschrieben: Do Mär 26, 2026 6:42 am Der grundlegende Unterschied ist das Ziel: Ich entwickel ein natives openWB-SoC-Modul, das direkt in openWB integriert ist

Ah... Missverständnis meinerseits. Ich hatte nicht verstanden, dass das Script nur ein Test-Zwischenschritt ist.

Ich möchte trotzdem dringend empfehlen auf den MQTT Stream zu schwenken und dies auch in Zukunft nicht optional anzubieten, sondern als einziges und damit zwingend. Die Vergangenheit hat gezeigt, dass Autohersteller ihre APIs sehr schnell sperren oder kostenpflichtig machen, sobald die Menge der API Calls durch die steigende vielzahl an SmartHome Systemen zunimmt. BMW war bislang sehr fair das ganze (noch) kostenlos anzubieten, aber auch BMW hat sicherlich eine Schmerzgrenze.

Ich verstehe den Ansatz die erste Implementierung möglichst einfach umzusetzen, aber bekanntermaßen hält nichts länger als ein Provisorium und ich befürchte, dass wenn es per API Calls erstmal funktioniert, es auf absehbare Zeit auch so bleiben wird. Weiterhin gutes gelingen!

Hi,

du sprichst einen wichtigen Punkt an und ich kann diesen auch nachvollziehen.

Du hast recht dass REST-APIs von Herstellern schnell eingeschränkt oder kostenpflichtig gemacht werden können.
Gleichzeitig möchte ich erklären warum wir trotzdem mit REST gestartet sind und wie wir das langfristig sehen.

Der MQTT Stream hat einen entscheidenden Nachteil für ein natives openWB-Modul: Er benötigt eine dauerhafte Verbindung. BMW erlaubt nur einen gleichzeitigen MQTT-Client pro Account. Wer also bereits die BMW Home Assistant Integration oder die BimmerData App nutzt, hätte sofort einen Konflikt. REST hat dieses Problem nicht.

Dazu kommt: Das 50 Calls/Tag Limit ist bei sinnvoller Konfiguration (Abfrage nur wenn angesteckt, SoC während Ladung berechnen) in der Praxis kaum ein Problem.

Aber du hast recht was die Zukunftssicherheit angeht. Deshalb steht der MQTT Stream bereits auf unserer Roadmap als optionaler zweiter Modus. Die Architektur ist so aufgebaut dass beides möglich ist. Wir wollten aber erst eine stabile REST-Basis schaffen bevor wir die Komplexität eines dauerhaften MQTT-Streams hinzufügen.

Viele Grüße
Dennis