Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)

[zut]

Guten Tag,

hier verweise ich auf meinen soc_helper, der den SOC des Fahrzeugs in die OpenWB übertragen kann, wenn das Fahrzeug in den Bereich des heimischen WLANs fährt. Eine automatisierte Nutzung von Spritmonitor ist möglich.
Es ist ein spezieller OBD-Dongle nötig sowie ein einfacher Rechner im Haus, der immer läuft (Raspi Zero W genügt), dafür kann man sich das Hersteller-Abo und die Abhängigkeit von dessen Server für das Zielladen sparen.
Entwickelt und getestet wird mit einem VW e-up; das Programm dürfte mit entsprechender Konfiguration auch mit anderen Fahrzeugen funktionieren.

Projektstand:

Funktioniert:

eUp
VW MEB (ID3, ID4 und abgeleitete Varianten von Skoda,Seat)
Standard-Abfragen für Verbrenner sofern unterstützt: Tankfüllstand (als SOC an die Wallbox), Kilometerstand
eGolf
Renault Zoe alt (PH1)

Vorbereitet (Tester gesucht):

Ora Funky Cat
Renault Zoe neu (PH2) (kein km-Stand, kein Spritmonitor)
Fiat 500e

Andere Fahrzeuge sind leicht zu ergänzen, sofern SOC-Request und -Response der OBD2-Kommunikation bekannt sind.

Das Projekt ist im Zustand "works for me and my collegue" und lebt von Eurem Feedback - meine Wünsche werden erfüllt, Eure kenne ich nicht.

Code: Alles auswählen

2024-09-06:
* Überflüssige Zuweisungen für Nicht-UDS_Fahrzeuge entfernt
* Loglevel für empfangene Botschaften von Nicht-UDS-Fahrzeugen von info
  auf debug gestellt, um Vollmüllen des Logs auf info zu vermeiden.

2024-09-05:
* Erster Versuch, den Kilometerstand der ZoePH1 auszulesen

2024-08-30:
* Bugfix: Geparste empfangene Message löschen, um nicht bei jeder nicht
  relevanten empfangenen Botschaft die alte Message wieder neu zu parsen.

2024-08-26:
* Prüfung bei Start bricht nicht mehr ab, falls noch keine Ladung bei
  Spritmonitor hinterlegt ist.

Ein Abzug des aktuellen Entwicklungsstandes von (github) des komplett überarbeiteten soc_helper: https://github.com/DerHerrW/soc_helper/ ... 2024-09-06

==================
Ursprungspost:

Guten Tag zusammen,

ich habe ein Python-Programm in der Entwicklung, welches mit Hilfe eines MeatPI WiCAN OBD-Adapters (https://www.meatpi.com/products/wican) den Fahrzeug-SOC ausliest und an die OpenWB schickt. Vorteil ist der Verzicht auf externe Cloud-Technik, die ausfallen kann und Geld kostet. Darüber hinaus ist eine optionale Spritmonitor-Anbindung in der Entwicklung - nach dem Abstecken wird der Kilometerstand des Fahrzeugs und die seit dem letzten Spritmonitor-Eintrag zurückgelegte Distanz sowie die seit Anstecken geladene Arbeit automatisiert bei Spritmonitor hochgeladen.

Ich vermute, daß eine Anpassung auch an andere Fahrzeugmarken relativ einfach möglich ist, sofern die Information vorliegt, wie man den SOC an der OBD-Buchse abfragt.

Das Projekt ist momentan im Alpha-Stadium und könnte gerne noch ein paar Tester gebrauchen. Bevor ich mir die Mühe mit den Lizenzen und der Dokumentation mache, würde ich gerne wissen, wie hoch das Interesse an einer Veröffentlichung ist.

Falls Interesse am Testen besteht, bitte hier im Thread melden.

[philipp123]

Hätte ich das ganze nicht schon mit OVMS gelöst, wäre ich dabei.

[KrailPV]

Wäre interessiert, habe einen eUP

[ID4U]

Im Prinzip auch für mich sehr interessant. Dazu ein paar Fragen:

- Wie funktioniert die Datenübertragung zur openWB (nur per WLAN)?
- Läuft das auch bei abgeschalteter Zündung?
- Wenn ja, wie stark wird die Batterie dann im Stand belastet?
- Ist noch weitere Hardware erforderlich?

Und: Gibts das auch für den ID.3 ?

[zut]

Hi,

ich werde mal das README anhängen, auch wenn das noch im Aufbau ist. Zu den Fragen:

Wie funktioniert die Datenübertragung zur openWB (nur per WLAN)?
- Läuft das auch bei abgeschalteter Zündung?
- Wenn ja, wie stark wird die Batterie dann im Stand belastet?
- Ist noch weitere Hardware erforderlich?

Und: Gibts das auch für den ID.3 ?

Es wird ein MeatPi WiCAN benötigt. Ein Dongle für den OBD-Port. Eine Voraussetzung für den Verbleib an der Buchse ist, daß der einen Schlafmodus hat: Wenn die Bordnetzspannung für drei Minuten unterhalb einer einstellbaren Schwelle ist, geht er schlafen und wacht erst wieder auf, wenn sie über die Schwelle steigt. Beim e-up ist der Dongle also bei hergestellter Fahrbereitschaft (Zündung reicht nicht) aktiv und bis zu drei nach Rücknahme der Fahrbereitschaft. Im Schlaf benötigt der Dongle weniger als 1mA.
Beim e-up ist das ganze Fahrzeug während der Ladung wach, da könnte man also auch Dinge tun, ich habe aber darauf verzichtet, damit man auch Fahrzeuge nutzen kann, die beim Laden nur die nötigen Steuergeräte befeuern.

Die Übertragung erfolgt über mqtt-Botschaften ausschließlich per WLAN an ein Netz mit einstellbarer ESSID und Kennwort. Das Einbuchen im WLAN ist der Trigger für die SOC-Abfrage des Autos. Als SOC-Modul in der Wallbox sollte Manuell+Berechnung gewählt sein. Es wäre möglich, während der Ladung zumindest beim e-up periodisch den SOC abzufragen, aber das erscheint mir zu unsicher und auch unnötig.

Als weitere Hardware ist ein dauerhaft laufender Rechner im Hausnetz nötig, ein Raspberry Zero W oder besser zum Beispiel - es muß python3 drauf laufen. Ich vermute, daß das kleine Programm auch auf der OpenWB laufen könnte, aber da möchte ich nicht eingreifen, weil ich momentan doch einiges an Daten ausgebe und die SD-Karte durch Schreibzugriffe stresse.

Ich halte es für wahrscheinlich, daß alle BEVs der Marke VW mit meinem Ansatz laufen, da sich die OBD-Befehle vermutlich nicht Fahrzeugmodellspezifisch ändern. Vermutlich würden auch die Fahrzeuge der anderen Marken (bis auf Audi / Porsche vielleicht) out of the box laufen. Ich köntne mir vorstellen, daß auch mit wenig Umkonfigurieren (Andere OBD-Befehle) Fahrzeuge anderer Hersteller mitspielen.

[ID4U]

Danke für die Infos!

Es wäre möglich, während der Ladung zumindest beim e-up periodisch den SOC abzufragen, aber das erscheint mir zu unsicher und auch unnötig.

Hmm, aber genau das wäre für Laden mit SoC-Begrenzung durch die openWB doch erforderlich, oder?

[zut]

Ich denke nicht, daß das permanente Abfragen nötig ist - bei mir funktioniert es mit Manuell und Berechnung von einem Startwert bis zum Ende. Möglicherweise ist es mit dem SOC-Modul "MQTT" so, daß das periodisch einen aktuellen SOC braucht.

Momentan gibt es noch die issues mit dem Manuell-Modul, daß nach der Ladung plus der einstellbaren Aktualisierungsrate der SOC von vor dem Laden eingesetzt wird, aber ich hoffe, daß das noch seitens OpenWB gelöst wird.

[zut]

Ach ja, bevor jetzt alle loslaufen und bei mouser in den USA ein einzelnes WiCAN bestellen: Ab 50€ Bestellwert übernehmen die den Versand und Taxes (immerhin 20€ in die EU). Also bitte immer mindestens zu zweit bestellen oder zwei Dongels auf einmal.

[ID4U]

Ich denke nicht, daß das permanente Abfragen nötig ist - bei mir funktioniert es mit Manuell und Berechnung von einem Startwert bis zum Ende.

Ich habe jetzt keine Erfahrung mit dem manuellen SoC-Modul: Aber ist das denn unter allen Bedingungen hinreichend genau ohne immer mal nachjustieren zu müssen? Auf ein paar wenige % Abweichung kommt es mir natürlich nicht an ...

[zut]

Der berechnete SOC ist bis auf einige % genau. Bei niedriger Ladeleistung schlägt der Standby-Verbrauch prozentual viel stärker durch (200W bei 1,36kW) als bei voller Ladeleistung (200W bei 7,2kW). Es hängt also vom Wetter ab. Bei mir habe ich für den Wirkungsgrad einen groben Mittelwert genommen. Bei wenig Sonne wird der SOC überschätzt, bei voller Einstrahlung unterschätzt.

Wenn man ein Fahrzeug hat, das die NV-Batterie beim Laden permanent lädt, kann man natürlich recht einfach periodisch (z.B. alle 2 Minuten) in der Hauptschleife den SOC anfordern, der Rest (Empfang der Botschaft, dekodieren und übertragen an die OpenWB) passiert dann automatisch. Der e-up wäre so ein Kandidat. Bei mir befindet sich die Wallbox aber gerade am Rand des Haus-WLANs, so daß schlechte Empfangsbedingungen im Fahrzeug keine Aktualisierung des SOCs bedingen würden. Deshalb lasse ich das. Die paar Zeilen kannst du aber gerne testen