Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
-
_daniel
- Beiträge: 117
- Registriert: Fr Apr 09, 2021 6:03 pm
- Has thanked: 1 time
- Been thanked: 2 times
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Welchen Export benötigst du, die Aufzechnung während man sich Sensoren anschaut (brc, csv) oder den Adapterlog?
Bzgl Spritmonitor ging es mir wirklich darum, ob automatisch Einträge auf der Webseite erzeugt werden.
Da ich ja nicht immer ein Display mit SSH Zugriff auf den rpi parat habe.
Aktuell ist das Auto voll und wird wenig bewegt. Da steckt dann auch kein Stecker.
Die Tage mal schauen, ob der soc-helper noch brav im Hintergrund läuft.
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Meine Lösung basiert auf dem bekannten Meatpi WiCan Dongle aus Australien
Gekauft via Mouser Deutschland (kam aber aus den USA, von daher beim Bestellen aufpassen, weil die mouser.de zwar gratis ab 50€ liefern (sonst 20€ Versand - kein Scherz, weil es aus Texas mit Flieger in 3 Tagen an der Haustür ist), aber man am Ende noch die Mehrwertsteuer drauf rechnen darf. Wenn da 30€ steht, dann bedeutet es am Ende rund 36€.
ABER VORSICHT: Ob dann jenseits 150€ Warenwert auch noch Zoll fällig werden, das weiß ich nicht, aber ich würde davon abraten, gleich 4 Dongle für 160€ zu bestellen, weil im Falle des Falles DHL dann noch für ein paar Cent Zoll glatt 8€ Inkasso will.
GRUNDLAGEN
Der Meatpi WiCan OBD2 Dongle hat sein eigenes WLAN und kann sich zugleich wie eine Bridge ins heimische WLAN verbinden und damit Daten senden, sobald er heim kommt oder fährt. Die GOLF Control Units arbeiten aber meist nur mit Zündung an.
Der Meatpi Dongle legt sich nach dem Zündung aus nach einiger Zeit auch schlafen, wobei man im Dongle das noch bescheunigen kann auf Basis der Bordspannung. Ist Zündung aus und sinkt die Spannung unter x Volt wie bei mir unter 13 Volt, dann schaltet der sich aus bzw. schläft.
Während des Ladens schreibt ja evcc eh den Ladestand fort auf Basis des SOC bei Ankunft, der Ladeleistung [kW] x Ladedauer im Verhältnis zur Batteriegröße aufgrund der Zeile "capacity: 31.5".
DER AUSLÖSER - die Automation
Wenn das Fahrzeug heim rollt und ins WLAN kommt, so greift eine Automation, die permanent fragt, ob der WiCan Dongle seinen Zustand auf Online gewechselt hat.
WICHTIG: wenn man beim Testen im Auto sein sollte, läuft häufig die Automation nicht, von daher einen weiteren Trigger einbauen, der in ein paar Sekunden auslöst. Ansonsten kann man Stunden im Auto verbringen, weil nix passiert, denn die Automation greift nur beim Wechsel von was auch immer für einen Zustand zu "ONLINE". Zündung aus schaltet den Dongle nicht ab, somit auch kein Wechsel zu Online, damit kein Trigger.
Es würde nur eines noch helfen: DONGLE ABZIEHEN und wieder einstecken
Aber besser den Timer pflegen beim Testen.
DAS PROCEDERE = NACHRICHTENFLUSS
Falls der Donlge "ONLINE" geht, so stellt die Automation sofort die CanBus Anfragen (im Rhytmus von X Sekunden / 1 MInute bis der Dongle Status <> "ONLINE" ist). Die Anfragen kommen per mqtt via WLAN im Dongle an und gehen von da ans adressierte Steuergerät .
.
Das antwortet mit einer Kennung und der Meatpi Dongle, der ja neben dem WLAN wie ein fahrzeugeigenes Steuergerät im CanBus hängt, kriegt die Nachricht mit und überträgt sie via seinem mqqt zum HA mosquito broker und wird unter HA via Automation und configuration.yaml in den Sensoren SOC, Reichweite und Km Stand verarbeitet. Dazu wird geprüft, ob die Nachricht eine Antwort auf die Anfrage ist und dann eine inhaltliche Prüfung vorgenommen. Das passiert u.a. bei der Reichweite, wo zu prüfen ist, dass die Zahl eben >0 ist und somit kein Datenmüll dort ankommt, was zwischenzeitlich bei der Reichweite mal passiert war, wo dann statt x km eben nur noch 0 km stand bei SOC 80%. Problem ist aber letzte Woche gelöst worden durch die Abfrage, dass km Stand nur aktualisiert wird wenn >0.
DIE BLAUPAUSE AUS DER VOGELPERSPEKTIVE AUF DIE ENTWICKLUNGSHISTORIE
Die ganz Geschichte im Detail hat sich über 10 Tage Entwicklung gezogen und Dank der Hilfe von HisN wie auch JabeBRD mit einem Erfolg abschließen lassen. 10 Tage meint 10 Tage x gut 10 h / Tag, bis das alles so halbwegs lief.
Der Code ist hart, aber herzlich zusammengepfuscht, aber tut zumindest für einen e-GOLF 300 aus 2020 mit 55000 km. Die Grundidee wurde NICHT vom e-Up übernommen, weil die tagelang nur Probleme gemacht hatte beim e-GOLF. Die Grundidee stammt von JabeBRD aus Finnland, der einen Passat GTE mit 10 kWh und dann einen neueren GTE mit 13 kWh Batterie nebst e-Up nutzt.
BEISPIEL SOC
Der Rest der Historie sind dann meine Irrungen, Wirrungen,Erkenntnisse, die Suchen und am Ende das Ergebnis seiner Hilfen, um CanBus zu zumindest im e-GOLF ein wenig zu verstehen. Ich habe dazu die CarScanner Pro App gekauft für 5€ oder so und damit die Messages getracked und somit die Werte gekannt wie beim e-GOLF der SoC um 0,4% sich entwickelt, immer nur 0,4% rauf oder runter kann, weil die bruttokapazität vom BMS mit 0 bis 100% getracked wird, aber nur in 0,4% Schritten. Klingt schräg, aber wer 100% / 250 Schritte teilt, der landet dann bei 0,4% Schritten.
Nimmt man dann 0,4% x brutto 36 kWh, so ist jeder Schritt 36.000 Wh * 0,4% = 144 Wh oder grob 1 km.
Und wer dem nun gefolgt ist, würde so auf der Nase landen, denn das ist die brutto Kapazität. Ich habe also per Car Scanner App die Werte ausgelesen, die der eGOLF liefert, wenn der Wagen voll geladen ist und total leer gefahren. Ich meine damit 0 km Reichweite übrig und genauer gesagt -1 km weiter gefahren als bei 20 km Restreichweite angezeigt worden ist. Nochmals: Im Auto bei 100 km / h werden 20 km angezeigt, auf Basis 55000 km sollte ich bei 55.020 km 0% haben, wenn der Verbrauch so bleibt. Ich bin bei 55021 km auf den Hof gerollt mit 8% Steigung.
Ergebnis: Wenn der WAgen das Laden abbricht, dann teilt das BMS 96% SOC mit und wenn der Akku leer ist auf 0 km so sind es was ?
8%.
Daher das nutzbare Band von 8% bis 96% , sprich 88% Punkt von 36.000 Wh sind nutzbar = 31.680 Wh.
Das sind dann unsere 100% SOC.
Da es ja nachher in medias res gehen wird, gleich vorab: Wir erinnern uns, dass die brutto batterie mit 250 Werte vom BMS in 0,4% Schritten verwaltet wird.
Der Canbus hat also bei Reichweite 0 mit dem Wert 20 geantwortet, daher 20 x 0,4% = 8%.
Ist der Akku voll, lautet die Antwort nicht 250, sondern nur 240 und damit 96%.
Somit verteilt sich die nutzbare netto Akkukapazität auf wie viele Schritte ?
Es sind 250 insgesamt und unter halb von 20 und oberhalb von 240 können nicht genutzt werden, somit sind es 220 Schritte, auf die sich die Nettokapazität verteilt.
Wenn man also vom Auto die Antwort 108 bekommt, dann sind davon nur noch 88 Schritte nutzbar.
Der SOC ist dann 88 / 220 . Dem Kenner sagt das nix, aber das war eins meiner ersten Erfolgserlebnisse. 40% sind das oder 0,4
DIE SCHRITT FÜR SCHRITT LÖSUNG
Die eigentliche Lösung und wie sie entstand existiert bereits als ein 10 h Zusammenschrieb, der noch unveröffentlicht im Akkudoktorforum als Entwurf schlummert, weil das Akkuforum irgendwann begann, meinen "code" als schädlich abzulehnen, also die Software hat automatisch meinen Text nicht mehr gespeichert, weil der Code bzw. Befehle darin gestört haben. Daher eben unveröffentlicht. Da das formatiert ist und viele Links und Screenshot enthält, ohne dass ich ahnte, dass fast alles beim Speichern verloren ginge, ist der größte Teil dort fertig, aber es hängt am Rest, den ich nicht mehr anfügen kann.
Bis zur Veröffentlichung kannst Du aber jeden Schritt inklusive aller Irrungen und Wirrungen auf github über 80 Kommentare lang bis zum letzten Wochenende hier verfolgen https://github.com/meatpiHQ/wican-fw/issues/168
Und danach ist man wohl auch in der Lage, dann andere Dinge abzufragen, weil dort auch die Quellen stehen wie die Amigo Liste.
So hat es jedenfalls geklappt und klappt auch heute, von daher such Dir das passende raus. Als Ganzes funktioniert es, was passiert, wenn man nur Teile nimmt, muss man halt sehen. Mein Weg zum Erfolg waren am Ende die Rohdaten und keine Vorverarbeitung von WiCan dongle, denn das hatte nicht oder nur bedingt geklappt.
Gekauft via Mouser Deutschland (kam aber aus den USA, von daher beim Bestellen aufpassen, weil die mouser.de zwar gratis ab 50€ liefern (sonst 20€ Versand - kein Scherz, weil es aus Texas mit Flieger in 3 Tagen an der Haustür ist), aber man am Ende noch die Mehrwertsteuer drauf rechnen darf. Wenn da 30€ steht, dann bedeutet es am Ende rund 36€.
ABER VORSICHT: Ob dann jenseits 150€ Warenwert auch noch Zoll fällig werden, das weiß ich nicht, aber ich würde davon abraten, gleich 4 Dongle für 160€ zu bestellen, weil im Falle des Falles DHL dann noch für ein paar Cent Zoll glatt 8€ Inkasso will.
GRUNDLAGEN
Der Meatpi WiCan OBD2 Dongle hat sein eigenes WLAN und kann sich zugleich wie eine Bridge ins heimische WLAN verbinden und damit Daten senden, sobald er heim kommt oder fährt. Die GOLF Control Units arbeiten aber meist nur mit Zündung an.
Der Meatpi Dongle legt sich nach dem Zündung aus nach einiger Zeit auch schlafen, wobei man im Dongle das noch bescheunigen kann auf Basis der Bordspannung. Ist Zündung aus und sinkt die Spannung unter x Volt wie bei mir unter 13 Volt, dann schaltet der sich aus bzw. schläft.
Während des Ladens schreibt ja evcc eh den Ladestand fort auf Basis des SOC bei Ankunft, der Ladeleistung [kW] x Ladedauer im Verhältnis zur Batteriegröße aufgrund der Zeile "capacity: 31.5".
DER AUSLÖSER - die Automation
Wenn das Fahrzeug heim rollt und ins WLAN kommt, so greift eine Automation, die permanent fragt, ob der WiCan Dongle seinen Zustand auf Online gewechselt hat.
WICHTIG: wenn man beim Testen im Auto sein sollte, läuft häufig die Automation nicht, von daher einen weiteren Trigger einbauen, der in ein paar Sekunden auslöst. Ansonsten kann man Stunden im Auto verbringen, weil nix passiert, denn die Automation greift nur beim Wechsel von was auch immer für einen Zustand zu "ONLINE". Zündung aus schaltet den Dongle nicht ab, somit auch kein Wechsel zu Online, damit kein Trigger.
Es würde nur eines noch helfen: DONGLE ABZIEHEN und wieder einstecken
Aber besser den Timer pflegen beim Testen.
DAS PROCEDERE = NACHRICHTENFLUSS
Falls der Donlge "ONLINE" geht, so stellt die Automation sofort die CanBus Anfragen (im Rhytmus von X Sekunden / 1 MInute bis der Dongle Status <> "ONLINE" ist). Die Anfragen kommen per mqtt via WLAN im Dongle an und gehen von da ans adressierte Steuergerät .
.
Das antwortet mit einer Kennung und der Meatpi Dongle, der ja neben dem WLAN wie ein fahrzeugeigenes Steuergerät im CanBus hängt, kriegt die Nachricht mit und überträgt sie via seinem mqqt zum HA mosquito broker und wird unter HA via Automation und configuration.yaml in den Sensoren SOC, Reichweite und Km Stand verarbeitet. Dazu wird geprüft, ob die Nachricht eine Antwort auf die Anfrage ist und dann eine inhaltliche Prüfung vorgenommen. Das passiert u.a. bei der Reichweite, wo zu prüfen ist, dass die Zahl eben >0 ist und somit kein Datenmüll dort ankommt, was zwischenzeitlich bei der Reichweite mal passiert war, wo dann statt x km eben nur noch 0 km stand bei SOC 80%. Problem ist aber letzte Woche gelöst worden durch die Abfrage, dass km Stand nur aktualisiert wird wenn >0.
DIE BLAUPAUSE AUS DER VOGELPERSPEKTIVE AUF DIE ENTWICKLUNGSHISTORIE
Die ganz Geschichte im Detail hat sich über 10 Tage Entwicklung gezogen und Dank der Hilfe von HisN wie auch JabeBRD mit einem Erfolg abschließen lassen. 10 Tage meint 10 Tage x gut 10 h / Tag, bis das alles so halbwegs lief.
Der Code ist hart, aber herzlich zusammengepfuscht, aber tut zumindest für einen e-GOLF 300 aus 2020 mit 55000 km. Die Grundidee wurde NICHT vom e-Up übernommen, weil die tagelang nur Probleme gemacht hatte beim e-GOLF. Die Grundidee stammt von JabeBRD aus Finnland, der einen Passat GTE mit 10 kWh und dann einen neueren GTE mit 13 kWh Batterie nebst e-Up nutzt.
BEISPIEL SOC
Der Rest der Historie sind dann meine Irrungen, Wirrungen,Erkenntnisse, die Suchen und am Ende das Ergebnis seiner Hilfen, um CanBus zu zumindest im e-GOLF ein wenig zu verstehen. Ich habe dazu die CarScanner Pro App gekauft für 5€ oder so und damit die Messages getracked und somit die Werte gekannt wie beim e-GOLF der SoC um 0,4% sich entwickelt, immer nur 0,4% rauf oder runter kann, weil die bruttokapazität vom BMS mit 0 bis 100% getracked wird, aber nur in 0,4% Schritten. Klingt schräg, aber wer 100% / 250 Schritte teilt, der landet dann bei 0,4% Schritten.
Nimmt man dann 0,4% x brutto 36 kWh, so ist jeder Schritt 36.000 Wh * 0,4% = 144 Wh oder grob 1 km.
Und wer dem nun gefolgt ist, würde so auf der Nase landen, denn das ist die brutto Kapazität. Ich habe also per Car Scanner App die Werte ausgelesen, die der eGOLF liefert, wenn der Wagen voll geladen ist und total leer gefahren. Ich meine damit 0 km Reichweite übrig und genauer gesagt -1 km weiter gefahren als bei 20 km Restreichweite angezeigt worden ist. Nochmals: Im Auto bei 100 km / h werden 20 km angezeigt, auf Basis 55000 km sollte ich bei 55.020 km 0% haben, wenn der Verbrauch so bleibt. Ich bin bei 55021 km auf den Hof gerollt mit 8% Steigung.
Ergebnis: Wenn der WAgen das Laden abbricht, dann teilt das BMS 96% SOC mit und wenn der Akku leer ist auf 0 km so sind es was ?
8%.
Daher das nutzbare Band von 8% bis 96% , sprich 88% Punkt von 36.000 Wh sind nutzbar = 31.680 Wh.
Das sind dann unsere 100% SOC.
Da es ja nachher in medias res gehen wird, gleich vorab: Wir erinnern uns, dass die brutto batterie mit 250 Werte vom BMS in 0,4% Schritten verwaltet wird.
Der Canbus hat also bei Reichweite 0 mit dem Wert 20 geantwortet, daher 20 x 0,4% = 8%.
Ist der Akku voll, lautet die Antwort nicht 250, sondern nur 240 und damit 96%.
Somit verteilt sich die nutzbare netto Akkukapazität auf wie viele Schritte ?
Es sind 250 insgesamt und unter halb von 20 und oberhalb von 240 können nicht genutzt werden, somit sind es 220 Schritte, auf die sich die Nettokapazität verteilt.
Wenn man also vom Auto die Antwort 108 bekommt, dann sind davon nur noch 88 Schritte nutzbar.
Der SOC ist dann 88 / 220 . Dem Kenner sagt das nix, aber das war eins meiner ersten Erfolgserlebnisse. 40% sind das oder 0,4
DIE SCHRITT FÜR SCHRITT LÖSUNG
Die eigentliche Lösung und wie sie entstand existiert bereits als ein 10 h Zusammenschrieb, der noch unveröffentlicht im Akkudoktorforum als Entwurf schlummert, weil das Akkuforum irgendwann begann, meinen "code" als schädlich abzulehnen, also die Software hat automatisch meinen Text nicht mehr gespeichert, weil der Code bzw. Befehle darin gestört haben. Daher eben unveröffentlicht. Da das formatiert ist und viele Links und Screenshot enthält, ohne dass ich ahnte, dass fast alles beim Speichern verloren ginge, ist der größte Teil dort fertig, aber es hängt am Rest, den ich nicht mehr anfügen kann.
Bis zur Veröffentlichung kannst Du aber jeden Schritt inklusive aller Irrungen und Wirrungen auf github über 80 Kommentare lang bis zum letzten Wochenende hier verfolgen https://github.com/meatpiHQ/wican-fw/issues/168
Und danach ist man wohl auch in der Lage, dann andere Dinge abzufragen, weil dort auch die Quellen stehen wie die Amigo Liste.
So hat es jedenfalls geklappt und klappt auch heute, von daher such Dir das passende raus. Als Ganzes funktioniert es, was passiert, wenn man nur Teile nimmt, muss man halt sehen. Mein Weg zum Erfolg waren am Ende die Rohdaten und keine Vorverarbeitung von WiCan dongle, denn das hatte nicht oder nur bedingt geklappt.
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Mach dir keine Arbeit, ich meinte Jonny. Versuch du erstmal, ob mit der derzeitigen Konfiguration im Alltag zuverlässig Werte kommen. Wenn der Kilometerstand klemmt, können wir noch die Abfrage versuchen, die Jonny in der Verlinkung erwähnt und die anscheinend zum Passat GTE gehört._daniel hat geschrieben: ↑Di Aug 27, 2024 7:04 pmWelchen Export benötigst du, die Aufzechnung während man sich Sensoren anschaut (brc, csv) oder den Adapterlog?
Bzgl Spritmonitor ging es mir wirklich darum, ob automatisch Einträge auf der Webseite erzeugt werden.
Da ich ja nicht immer ein Display mit SSH Zugriff auf den rpi parat habe.
Aktuell ist das Auto voll und wird wenig bewegt. Da steckt dann auch kein Stecker.
Die Tage mal schauen, ob der soc-helper noch brav im Hintergrund läuft.
Der eUp hat übrigens noch eine andere Anfragemethode für den Kilometerstand, der springt aber in 10er-Schritten.
Bei mir fährt der WiCAN immer mit, Dank 0,6m Verlängerung im Sicherungskasten und Dank Schlafmodus ohne große Batterieentladung. Hier eine ähnliche Lösung aus den thread: https://forum.openwb.de/viewtopic.php?p=111704#p111704
-
ChristophR
- Beiträge: 709
- Registriert: So Okt 30, 2022 8:07 am
- Has thanked: 12 times
- Been thanked: 19 times
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
So, das Thema Alarmanlage sollte nun erledigt sein.ChristophR hat geschrieben: ↑Di Aug 20, 2024 9:57 pmEin paar Hersteller, darunter auch VW legen auf PIN1 des ODB2-Steckers, der in der Norm frei definierbar ist, Zündplus:zut hat geschrieben: ↑Di Aug 20, 2024 9:12 pmWenn man ein Fahrzeug hat, das per UDS kommuniziert, wird der soc_helper immer dann, wenn der WiCAN seinen Status auf online setzt, die Abfragen rausschicken. Das kann auch dann passieren, wenn eine Ladung mangels Sonne abgebrochen wurde und einige Zeit danach wieder startet. Das Fahrzeug lädt dann meiner Erfahrung nach die NV-Batterie und der aktuelle SoC wird abgefragt.ChristophR hat geschrieben: ↑Di Aug 20, 2024 7:24 pm Daher nun meine Frage: Was ist der Auslöser der Abfrage im soc_helper, erkennt der den Unterschied zwischen "aus Schlafmodus aufwachen" und dem normalen "Einfahren ins WLAN" ganz zu Beginn?
Das sieht nicht so gut aus- ich wüsste gerade auch nicht, wie man solche Fälle (Ankunft / Abfahrt / Wiederaufwecken) zuverlässig unterscheiden kann. Dazu müsste man die Fahrbereitschaft haben, aber die darf man nicht aktiv abfragen. UDS schickt nichts von alleine. Wenn die Versorgungsspannung der Buchse auf Zündplus (Klemme 15 oder 87) statt Dauerplus (Klemme 30) gelegt würde, ginge es, aber bei Firmenwagen wäre das wohl nicht so gut.
https://www.flexihub.com/de/oobd2-pinout/#volkswagen
Vielleicht kann man das im WiCAN Dongle umverkabeln? Dann geht es ohne Eingriff ins Fahrzeug.
Schaue ich mir mal an, wenn der Dongle da ist.
Dann muss die SoC-Abfrage nur fertig sein, bevor ich den "Motor" ausmache, das sollte aber m.E. reichen.
Edit:
Ich habe tatsächlich auf PIN1 Zündungsplus.
Wenn alles läuft werde ich das ggf. mit einem Adapter umbauen, dann bleibt auch der Dongle ganz.
Nur fraglich, ob der das so toll findet ständig abgeschaltet zu werden...
Ich habe lange nach einem passenden Kabel gesucht, bei dem man einen Stecker öffnen kann, um die PINs zu "korrigieren".
Schließlich bin ich auf das hier gestoßen:
https://www.amazon.de/VW-Audi-bbfly-B66 ... B0CT527LQ4
Das Kabel ist eigentlich dafür gedacht, die vorhandene Buchse auszuklinken, mit dem Splitter zu verbinden und dann die Buchse am kurzen Ende wieder in die originale Buchse im Fahrzeug einzuklinken.
So wundert sich die Werkstatt nicht, da die normale Buchse ja frei ist.
Zusätzlich geht der Winkelstecker genau in die richtige Richtung, so dass der Fußraum nun wieder frei ist.
Am kurzen Ende kommt man super leicht an die Kabel und kann diese austauschen, die lila Abdeckung lässt sich einfach seitlich wegschieben und dann kommt man ganz einfach an die Kontakte ran.
Ich habe bei mir einfach PIN 1 und PIN 16 getauscht. Da auf PIN1 sowieso Zündungsplus liegt, also auch die 12V, kann das den Dongle auch nicht stören, wenn da immer 12V anliegen.
Funktioniert natürlich nur, weil auf PIN1 Zündungsplus liegt, was nicht bei allen Herstellern so ist, siehe:
https://www.flexihub.com/de/oobd2-pinout/#main
Wenn ich den Dongle zum Testen mal normal angeschlossen haben möchte, benutze ich einfach den langen Anschluss.
P.S: Der Tipp mit dem Seitenfach ist super, das ist beim Born zwar etwas kleiner, aber für den Dongle reicht es gerade so.
Vielen Dank
openWB Series 2 Standard+, SW-Version 2
SolarEdge SE10K-RWS, BYD LVS 8, 16,8 kWp.
CUPRA Born
SolarEdge SE10K-RWS, BYD LVS 8, 16,8 kWp.
CUPRA Born
-
_daniel
- Beiträge: 117
- Registriert: Fr Apr 09, 2021 6:03 pm
- Has thanked: 1 time
- Been thanked: 2 times
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Mein Versuch:
soc_helper Sktipt mit log auf Debug gestartet (Fahrzeug offline, WICAN offline, kein Ladevorgang). Ladepunkt 7 und 8 auf "false". Läuft erfolgreich und korrekt an:
Code: Alles auswählen
2024-08-30 10:58:26,955; INFO;[ cars.py: 61 - cb_status() ] WiCAN-Status: others/wican/egolf/status b'{"status": "offline"}'
2024-08-30 10:58:26,955; INFO;[ cars.py: 84 - cb_status() ] Fahrzeug egolf ist <<offline>>
...
2024-08-30 10:58:26,911; DEBUG;[ chargepoints.py: 59 - cb_connectedVehicle() ] ID des mit Ladepunkt 7 verbundenes Fahrzeugs: 1
2024-08-30 10:58:26,913; DEBUG;[ chargepoints.py: 51 - cb_energycounter() ] Zählerstand auf Ladepunkt 7: 10180850.0
2024-08-30 10:58:26,913; DEBUG;[ chargepoints.py: 63 - cb_plug() ] Steckerzustand von Ladepunkt 7: b'false'
2024-08-30 10:58:26,916; DEBUG;[ chargepoints.py: 59 - cb_connectedVehicle() ] ID des mit Ladepunkt 8 verbundenes Fahrzeugs: 2
2024-08-30 10:58:26,917; DEBUG;[ chargepoints.py: 51 - cb_energycounter() ] Zählerstand auf Ladepunkt 8: 2709637.94
Code: Alles auswählen
2024-08-30 10:58:26,892; DEBUG;[ soc_helper.py:102 - checkConfig() ] Letzter Spritmonitor-Kilometerstand von Fahrzeug egolf erfolgreich abgerufen: {'id': 55472462, 'type': 'first', 'date': '26.08.2024', 'odometer': '79613.00', 'trip': None, 'fuelsortid': 19, 'quantity': None, 'quantityunitid': 5, 'quantity_converted': None, 'cost': None, 'currencyid': 0, 'cost_converted': None, 'note': '', 'attributes': None, 'streets': '', 'consumption': None, 'bc_speed': '0.00', 'bc_quantity': '0.00', 'bc_consumption': '0.00', 'position': None, 'stationname': None, 'tankid': 1, 'country': 'D', 'location': '', 'percent': '98.0', 'charging_power': None, 'charging_duration': None, 'charging_info': 'source_vehicle'}.
Auffällig Zählerstand der Ladepunkte 7 und 8 werden alle 3s aktualisiert. Auch der Steckerzustand vom Ladepunkt 7 wird alle 3s aktualisiert (Ladepunkt 8 nicht, erst wieder bei Änderung). Diese Einträge werden über die komplete Laufzeit erzeugt.
Code: Alles auswählen
2024-08-30 10:58:27,910; DEBUG;[ chargepoints.py: 63 - cb_plug() ] Steckerzustand von Ladepunkt 7: b'false'
2024-08-30 10:58:27,978; DEBUG;[ chargepoints.py: 51 - cb_energycounter() ] Zählerstand auf Ladepunkt 7: 10180850.0
2024-08-30 10:58:28,870; DEBUG;[ chargepoints.py: 51 - cb_energycounter() ] Zählerstand auf Ladepunkt 8: 2709637.94
2024-08-30 10:58:30,991; DEBUG;[ chargepoints.py: 51 - cb_energycounter() ] Zählerstand auf Ladepunkt 7: 10180850.0
2024-08-30 10:58:31,022; DEBUG;[ chargepoints.py: 51 - cb_energycounter() ] Zählerstand auf Ladepunkt 8: 2709637.94
2024-08-30 10:58:31,033; DEBUG;[ chargepoints.py: 63 - cb_plug() ] Steckerzustand von Ladepunkt 7: b'false'
2024-08-30 10:58:31,176; DEBUG;[ chargepoints.py: 51 - cb_energycounter() ] Zählerstand auf Ladepunkt 7: 10180850.0
2024-08-30 10:58:33,039; DEBUG;[ chargepoints.py: 51 - cb_energycounter() ] Zählerstand auf Ladepunkt 8: 2709637.94
2024-08-30 10:58:34,115; DEBUG;[ chargepoints.py: 51 - cb_energycounter() ] Zählerstand auf Ladepunkt 7: 10180850.0Als der e-Golf dann in den Hof gefahren kommt, gibt es keine Status Veränderungen bis der Stecker gesteckt (LP8) und der Ladevorgang gestartet wurde:
Code: Alles auswählen
2024-08-30 11:53:59,585; DEBUG;[ chargepoints.py: 63 - cb_plug() ] Steckerzustand von Ladepunkt 8: b'true'
2024-08-30 11:53:59,585; DEBUG;[ chargepoints.py: 73 - cb_plug() ] Angestecktes Fahrzeug mit openwbId 2 als egolf in der Fahrzeugliste identifiziert
2024-08-30 11:53:59,585; INFO;[ chargepoints.py: 76 - cb_plug() ] Angestecktes Fahrzeug egolf, ID 2 mit SoC 0 angestecktCode: Alles auswählen
2024-08-30 11:55:42,110; DEBUG;[ cars.py: 60 - cb_status() ] cb_status von Fahrzeug egolf aufgerufen
2024-08-30 11:55:42,110; INFO;[ cars.py: 61 - cb_status() ] WiCAN-Status: others/wican/egolf/status b'{"status": "online"}'
2024-08-30 11:55:42,111; INFO;[ cars.py: 68 - cb_status() ] Fahrzeug egolf ist online. Sende SOC- und ODO-Anforderung
2024-08-30 11:55:42,111; INFO;[ cars.py: 73 - cb_status() ] Sende SOC-Anforderung: { "bus": "0", "type": "tx", "frame": [{ "id": 2021, "dlc": 8, "rtr": false, "extd": false, "data": [3, 34, 2, 140, 170, 170, 170, 170] }] }
2024-08-30 11:55:42,112; INFO;[ cars.py: 79 - cb_status() ] Sende ODO-Anforderung: { "bus": "0", "type": "tx", "frame": [{ "id": 2021, "dlc": 8, "rtr": false, "extd": false, "data": [3, 34, 2, 189, 170, 170, 170, 170] }] }
2024-08-30 11:55:42,158; DEBUG;[ cars.py:101 - cb_rx() ] cb_rx von Fahrzeug egolf aufgerufen
2024-08-30 11:55:42,159; DEBUG;[ cars.py:102 - cb_rx() ] Empfangene CAN-Botschaft: b'{"bus":"0","type":"rx","ts":18547,"frame":[{"id":2029,"dlc":8,"rtr":false,"extd":false,"data":[4,98,2,140,206,170,170,170]}]}'
2024-08-30 11:55:42,159; DEBUG;[ cars.py:108 - cb_rx() ] Gesamte Frames: [{'id': 2029, 'dlc': 8, 'rtr': False, 'extd': False, 'data': [4, 98, 2, 140, 206, 170, 170, 170]}]
2024-08-30 11:55:42,159; DEBUG;[ cars.py:122 - cb_rx() ] Frame: {'id': 2029, 'dlc': 8, 'rtr': False, 'extd': False, 'data': [4, 98, 2, 140, 206, 170, 170, 170]}
2024-08-30 11:55:42,159; DEBUG;[ cars.py:166 - cb_rx() ] Einteilige Botschaft: [2029, 98, 2, 140, 206, 170, 170, 170]
2024-08-30 11:55:42,160; DEBUG;[ cars.py:176 - cb_rx() ] Erwarteter SOC_Header: lenSOC: 3; expectSOC: [98, 2, 140]
2024-08-30 11:55:42,160; DEBUG;[ cars.py:180 - cb_rx() ] Erwarteter ODO-Header: lenODO: 3; expectODO: [98, 2, 189]
2024-08-30 11:55:42,160; DEBUG;[ cars.py:245 - calcSOC() ] Daten für SoC-Berechnung: [2029, 98, 2, 140, 206, 170, 170, 170]
2024-08-30 11:55:42,160; INFO;[ cars.py:189 - cb_rx() ] Fahrzeug-SOC ist 85
2024-08-30 11:55:42,161; DEBUG;[ cars.py:190 - cb_rx() ] SOC-Wert von 85 an openWB/set/vehicle/2/soc_module/calculated_soc_state/manual_soc schicken.
Code: Alles auswählen
2024-08-30 11:55:42,162; DEBUG;[ cars.py:101 - cb_rx() ] cb_rx von Fahrzeug egolf aufgerufen
2024-08-30 11:55:42,163; DEBUG;[ cars.py:102 - cb_rx() ] Empfangene CAN-Botschaft: b'{"bus":"0","type":"rx","ts":18566,"frame":[{"id":2029,"dlc":8,"rtr":false,"extd":false,"data":[16,13,98,2,189,159,1,55]}]}'
2024-08-30 11:55:42,163; DEBUG;[ cars.py:108 - cb_rx() ] Gesamte Frames: [{'id': 2029, 'dlc': 8, 'rtr': False, 'extd': False, 'data': [16, 13, 98, 2, 189, 159, 1, 55]}]
2024-08-30 11:55:42,163; DEBUG;[ cars.py:122 - cb_rx() ] Frame: {'id': 2029, 'dlc': 8, 'rtr': False, 'extd': False, 'data': [16, 13, 98, 2, 189, 159, 1, 55]}
2024-08-30 11:55:42,164; DEBUG;[ cars.py:135 - cb_rx() ] Ersten Teil einer mehrteiligen Botschaft empfangen: [2029, 98, 2, 189, 159, 1, 55]
2024-08-30 11:55:42,164; DEBUG;[ cars.py:148 - cb_rx() ] Aufforderung für Folgeteile absetzen: { "bus": "0", "type": "tx", "frame": [{ "id": 2021, "dlc": 8, "rtr": false, "extd": false, "data": [48,0,100,170,170,170,170,170] }] }
2024-08-30 11:55:42,210; DEBUG;[ cars.py:101 - cb_rx() ] cb_rx von Fahrzeug egolf aufgerufen
2024-08-30 11:55:42,210; DEBUG;[ cars.py:102 - cb_rx() ] Empfangene CAN-Botschaft: b'{"bus":"0","type":"rx","ts":18597,"frame":[{"id":2029,"dlc":8,"rtr":false,"extd":false,"data":[33,84,0,0,98,60,189,224]}]}'
2024-08-30 11:55:42,211; DEBUG;[ cars.py:108 - cb_rx() ] Gesamte Frames: [{'id': 2029, 'dlc': 8, 'rtr': False, 'extd': False, 'data': [33, 84, 0, 0, 98, 60, 189, 224]}]
2024-08-30 11:55:42,211; DEBUG;[ cars.py:122 - cb_rx() ] Frame: {'id': 2029, 'dlc': 8, 'rtr': False, 'extd': False, 'data': [33, 84, 0, 0, 98, 60, 189, 224]}
2024-08-30 11:55:42,211; DEBUG;[ cars.py:159 - cb_rx() ] Mehrteilige Botschaft komplett: [2029, 98, 2, 189, 159, 1, 55, 84, 0, 0, 98, 60, 189, 224]
2024-08-30 11:55:42,212; DEBUG;[ cars.py:176 - cb_rx() ] Erwarteter SOC_Header: lenSOC: 3; expectSOC: [98, 2, 140]
2024-08-30 11:55:42,212; DEBUG;[ cars.py:180 - cb_rx() ] Erwarteter ODO-Header: lenODO: 3; expectODO: [98, 2, 189]
2024-08-30 11:55:42,212; DEBUG;[ cars.py:249 - calcODO() ] Daten für ODO-Berechnung: [2029, 98, 2, 189, 159, 1, 55, 84, 0, 0, 98, 60, 189, 224]
2024-08-30 11:55:42,212; INFO;[ cars.py:200 - cb_rx() ] Fahrzeug-Kilometerstand ist 79700Der Kilometerstand wird regelmäßig ausgelesen bis sich der WICAN von alleine nach ca. 30min Laufzeit abmeldet. Möglicherweise weil der Slepp-Mode (12.5V) eingesetzt hat.
Code: Alles auswählen
2024-08-30 12:21:22,444; INFO;[ cars.py: 61 - cb_status() ] WiCAN-Status: others/wican/egolf/status b'{"status": "offline"}'Das Fahrzeug erhält online keine weitere Einträge
Carscanner meldet nach dem Laden einen SoC von 85,6 (PID H-V Battery charge state) bzw 83,92% (PID State of charge)
cars.py
Dem sehr umfangreichen EGolf-Issue von Jonny kann man abweichende Berechnungsmethoden (SoC-Berechnung, ODO-Berechnung) entnehmen.
Ich würde es mal als Perfektion betrachten, die Erkenntnisse lasse sich evt. in das Skript cars.py aufnehmen?
Außerdem werden andere ID Telegramme (ODO-REQ_ID=1808 & ODO-RESP_ID=1918) für den Kilometerstand verwendet.
Die Reichweite ist nicht so relevant, hier verwende Jonny die IDs 1812 und 1914
Das vollständige Log ist zu groß, habe ich gezippt
- Dateianhänge
-
- debug_log3.zip.txt
- (1.93 MiB) 44-mal heruntergeladen
Zuletzt geändert von _daniel am Fr Aug 30, 2024 3:35 pm, insgesamt 1-mal geändert.
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Vielen Dank für das umfangreiche Log und die Analyse! Es erleichtert mich, daß sowohl SoC als auch Kilometerstand bei deinem eGolf genauso funktionieren wie beim aktuellen eUp. Welches Baujahr hat der Golf?
Daß der Steckerzustand und in der WB gespeicherte SoC periodisch übertragen werden, kenne ich so von meinem Setup ebenfalls. Ich gebe das nur auf Loglevel Debug aus.
Ich kenne es auch vom eUp so, daß eine gewisse Zeit nach Ladebeginn der WiCAN einschläft und erkläre mir das so, daß die NV-Batterie dann voll geladen ist und das NV-Ladegerät schlafen geht, woraufhin der WiCAN nach weiteren 3 Minuten einschläft. Das soll so.
Was mich wundert ist, daß nicht schon beim Heranfahren an die Wallbox der Status auf online geht und die Abfrage von Kilometerstand und SoC erfolgt. Eigentlich sollte es so funktionieren:
Zum Thema alternativer Kilometerstand:
Wenn du hier https://www.goingelectric.de/wiki/VW-e-up-OBD2-SG17 mal schaust, ist der Kilometerstand ebenfalls unter 0x714/0x77E (Request 1812 / Response 1918) vom Schalttafeleinsatz auch vom eUp abrufbar - das hatte ich anfangs auch so implementiert, hat aber den Nachteil, dass die Genauigkeit lediglich 10km beträgt und die Schalttafel nur bei eingeschalteter Zündung aktiv ist. Dafür muss man sich nicht mit mehrteiligen Botschaften herumärgern. Nachdem ich mehrteilige Botschaften gelernt hatte, habe ich umgestellt auf das Hybrid-SG, wo die Genauigkeit 1km beträgt: https://www.goingelectric.de/wiki/VW-e-up-OBD2-SG8C.
Die Reichweite wollte ich nicht mit in die Anfragen aufnehmen.
Dein Log hat mir übrigens noch einen Fehler offenbart: Die ständige Wiederhollung des Kilometerstandes kommt durch die ständig wiederholte seltsame Botschaft mit der 29-Bit-ID. Eigentlich sollte die einfach verworfen werden. Der soc_helper parst aber jedes mal die zuletzt erfolgreich empfangene Botschaft. Ich muß hier nach dem erfolgreichen Parsen die zuletzt empfangene Botschaft löschen, dann passiert nichts mehr, nachdem die seltsame Botschaft verworfen wurde. Ich bedanke mich!
Der Spritmonitor-Eintrag wird erst dann erzeugt, wenn der Ladestecker aus der Buchse entfernt wird ein Ladevorgang erfolgreich durchgeführt worden ist. Die Ladung kann ja durchaus mehrere Tage dauern zwischen An- und Abstecken. Der soc_helper muß dabei permanent laufen, um die beim Anstecken vorhandene Werte für km-Stand und Zählerstand parat zu haben.
Daß der Steckerzustand und in der WB gespeicherte SoC periodisch übertragen werden, kenne ich so von meinem Setup ebenfalls. Ich gebe das nur auf Loglevel Debug aus.
Ich kenne es auch vom eUp so, daß eine gewisse Zeit nach Ladebeginn der WiCAN einschläft und erkläre mir das so, daß die NV-Batterie dann voll geladen ist und das NV-Ladegerät schlafen geht, woraufhin der WiCAN nach weiteren 3 Minuten einschläft. Das soll so.
Was mich wundert ist, daß nicht schon beim Heranfahren an die Wallbox der Status auf online geht und die Abfrage von Kilometerstand und SoC erfolgt. Eigentlich sollte es so funktionieren:
- WiCAN ist dauerhaft gesteckt und während der Fahrt aktiv, Fahrzeug nähert sich dem Zuhause.
- WiCAN findet das heimische WLAN und meldet den online-Status an die Wallbox.
- soc_helper bekommt die Nachricht und schickt die Abfragen los.
- soc_helper bekommt via Broker die Antworten und schickt den berechneten SoC an die Wallbox.
- Ladestecker wird gesteckt, Ladung beginnt (möglicherweise mit erneutem Aufwachen und Abfragen, wenn längere Zeit gestanden).
- SoC wird lediglich von der OpenWB anhand der geladenen Energiemenge hochgerechnet.
Zum Thema alternativer Kilometerstand:
Wenn du hier https://www.goingelectric.de/wiki/VW-e-up-OBD2-SG17 mal schaust, ist der Kilometerstand ebenfalls unter 0x714/0x77E (Request 1812 / Response 1918) vom Schalttafeleinsatz auch vom eUp abrufbar - das hatte ich anfangs auch so implementiert, hat aber den Nachteil, dass die Genauigkeit lediglich 10km beträgt und die Schalttafel nur bei eingeschalteter Zündung aktiv ist. Dafür muss man sich nicht mit mehrteiligen Botschaften herumärgern. Nachdem ich mehrteilige Botschaften gelernt hatte, habe ich umgestellt auf das Hybrid-SG, wo die Genauigkeit 1km beträgt: https://www.goingelectric.de/wiki/VW-e-up-OBD2-SG8C.
Die Reichweite wollte ich nicht mit in die Anfragen aufnehmen.
Dein Log hat mir übrigens noch einen Fehler offenbart: Die ständige Wiederhollung des Kilometerstandes kommt durch die ständig wiederholte seltsame Botschaft mit der 29-Bit-ID. Eigentlich sollte die einfach verworfen werden. Der soc_helper parst aber jedes mal die zuletzt erfolgreich empfangene Botschaft. Ich muß hier nach dem erfolgreichen Parsen die zuletzt empfangene Botschaft löschen, dann passiert nichts mehr, nachdem die seltsame Botschaft verworfen wurde. Ich bedanke mich!
Der Spritmonitor-Eintrag wird erst dann erzeugt, wenn der Ladestecker aus der Buchse entfernt wird ein Ladevorgang erfolgreich durchgeführt worden ist. Die Ladung kann ja durchaus mehrere Tage dauern zwischen An- und Abstecken. Der soc_helper muß dabei permanent laufen, um die beim Anstecken vorhandene Werte für km-Stand und Zählerstand parat zu haben.
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Ich habe jetzt mal einen Bugfix-Versuch hochgeladen, aber noch nicht ausprobiert. Mach ruhig den Ladevorgang fertig, _daniel, um spritmonitor zu prüfen. Wenn du dich traust, kannst du danach mal die aktuelle cars.py von github herunterladen und bei dir austauschen. Ein neues Release mache ich erst, wenn zumindest bei mir keine neuen Fehlermeldungen auftauchen.
-
_daniel
- Beiträge: 117
- Registriert: Fr Apr 09, 2021 6:03 pm
- Has thanked: 1 time
- Been thanked: 2 times
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Danke für Das Projekt.
Freut mich, dass ich was beisteuern kann.
Meine Rückmeldung klingt womöglich aufwendig, ich kann aber nur jeden Laien ermutigen, es einfach zu probiere.
Mir langt der SoC (auch wenn es Abweichungen gibt), damit kann ich die Batterie schonen (maximal SoC) und zielgerichteter laden
Spritmonitor.
Hier probiere ich einen vollständigen Zyklus nach dem nächsten Laden.
Bisher hatte ich die Skripte gestoppt und anschließend ohne Logging neugestartet, damit das Log nicht sekündlich weiter läuft.
Hier hätte ich der Vollständigkeitswegen den Stecker noch ziehen müssen bevor ich das Skript neustarte.
Ich kann bei Gelegenheit kontrollieren, ob das Geräte-WLAN aktiv ist (bei Abfahrt, vor der Einfahrt…)
Der Austausch der Datei ist kein Problem.
Neustart des rpi ist noch ein Thema. Soc_helper.py läuft nicht an. Die Pfade hatte ich kontrolliert und schon auf relative angepasst. Hab jetzt gesehen, dass startatboot.sh ein Log erzeugen müsste, das muss ich noch prüfen. Ich hab crontab -e unter dem aktuellen User ergänzt.
Freut mich, dass ich was beisteuern kann.
Meine Rückmeldung klingt womöglich aufwendig, ich kann aber nur jeden Laien ermutigen, es einfach zu probiere.
Mir langt der SoC (auch wenn es Abweichungen gibt), damit kann ich die Batterie schonen (maximal SoC) und zielgerichteter laden
Spritmonitor.
Hier probiere ich einen vollständigen Zyklus nach dem nächsten Laden.
Bisher hatte ich die Skripte gestoppt und anschließend ohne Logging neugestartet, damit das Log nicht sekündlich weiter läuft.
Hier hätte ich der Vollständigkeitswegen den Stecker noch ziehen müssen bevor ich das Skript neustarte.
Der WiCAN war bereits lange vor der Abfahrt gesteckt und wurde nicht neu gesteckt.
Ich kann bei Gelegenheit kontrollieren, ob das Geräte-WLAN aktiv ist (bei Abfahrt, vor der Einfahrt…)
Der Austausch der Datei ist kein Problem.
Neustart des rpi ist noch ein Thema. Soc_helper.py läuft nicht an. Die Pfade hatte ich kontrolliert und schon auf relative angepasst. Hab jetzt gesehen, dass startatboot.sh ein Log erzeugen müsste, das muss ich noch prüfen. Ich hab crontab -e unter dem aktuellen User ergänzt.
Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)
Ich habe das Vergnügen, ein Release zu veröffentlichen, daß die alten Renault Zoe (ZoePH1) vollständig (SoC, Kilometerstand, Spritmonitor) unterstützt.
Link zu Github: https://github.com/DerHerrW/soc_helper
Link zu den Releases: https://github.com/DerHerrW/soc_helper/releases
Ich rate den Nutzern von Golf und Derivaten auf Grund eines Fehlers in der Verarbeitung von "seltsamen" Botschaften auf Release 2024-08-30 oder 2024-09-06 zu aktualisieren.
Im letzten Release ist auch Code für die ZoePH2 (ab etwa 2018) enthalten, der noch nicht getestet wurde. Interessenten können sich gerne bei mir melden, falls Interesse besteht.
Link zu Github: https://github.com/DerHerrW/soc_helper
Link zu den Releases: https://github.com/DerHerrW/soc_helper/releases
Ich rate den Nutzern von Golf und Derivaten auf Grund eines Fehlers in der Verarbeitung von "seltsamen" Botschaften auf Release 2024-08-30 oder 2024-09-06 zu aktualisieren.
Im letzten Release ist auch Code für die ZoePH2 (ab etwa 2018) enthalten, der noch nicht getestet wurde. Interessenten können sich gerne bei mir melden, falls Interesse besteht.