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.
- 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.
