Zuverlässiges Laden mit evcc OHNE Renault Cloud

capi

eDacia-Neuling
Ort
Linz, Oberösterreich
Fahrzeug
Dacia Spring Extreme Electric 65
Modelljahr
2024
Hi Leute,

ich habe meinen Spring seit November 2024, und es ist mein erstes E-Auto. Da ich auch eine PV am Dach habe, war mir von Anfang an wichtig, dass ich möglichst viel Sonne tanken würde, was dank meiner geringen Pendelstrecke von 20-40km am Tag eigentlich recht gut machbar sein sollte.

Ein Arbeitskollege hat mir evcc zur Steuerung empfohlen, und da dort auch mein go-e Ladekabel unterstützt ist, war das schnell die Software meiner Wahl. Nachdem ich den Spring dann hatte, musste ich leider feststellen, dass ich absolut kein Fan davon bin, dass ich meine Ladedaten über die Renault Cloud abfragen muss, was einerseits offiziell gar nicht unterstützt wird, und anderseits relativ niedrige API Limits hat, um nicht gesperrt zu werden.

Zudem stellte ich fest, dass der Spring die unangenehme Eigenschaft hat, dass er nach längeren Ladepausen (z.B. über Nacht, oder aber auch nach ein paar Stunden zu wenig Sonne), auch gar nicht mehr auf die Ladefreigabe reagiert.

Um von der Renault Cloud los zu kommen, war schnell klar, dass ich über einen ODB-II Adapter die Daten auslesen wollte. Nach etwas Suchen bin ich beim meatPi WiCAN gelandet, weil dieser eine offene Firmware hat, und weil er sich automatisch in mein WiFi einbuchen kann, sobald der Spring vorm Haus steht und nicht einfach passwortloses Bluetooth ist...

Mit dem Adapter stellte ich dann schnell fest, dass ich damit den SoC problemlos auslesen konnte. ABER, was ich auch feststellte, beim automatischen Pollen wird das HV System laufend aufgeweckt, was natürlich nicht ideal ist. Daher beschloss ich, einen minimalen eigenen ELM327 Client zu schreiben, den ich besser unter Kontrolle hatte. Und was ich damit auch feststellte: die Abfrage nach dem SoC über ODB-II weckt das HV-System zuverlässig auf.

Somit waren beide Probleme auf einmal behoben: ich konnte den SoC ohne Renault Cloud auslesen, und ich konnte das Auto “aufwecken”. Da ich das aber nicht zu oft tun wollte (wie gesagt, weckt das HV System auf, drained die 12V Batterie, und man hört diverse mechanische Teile anlaufen), habe ich eine “intelligente” Logik geschrieben, die den SoC nur selten (alle paar Stunden) abfragt, bzw. wenn das System ohnehin wach ist (erkennbar an der 12V Spannung), oder aber wenn das System am Laden ist oder laden sollte.

Jetzt habe ich ein kleines Python-basiertes Service, springwatch, dass als kleiner Container neben evcc läuft, den SoC über MQTT veröffentlicht und somit für evcc die Ladeplanung ermöglicht, sowie bei Bedarf den Spring aufweckt (wenn evcc laden will, der Spring aber nicht).

Falls wer Interesse daran hat, der findet das Ganze auf Github unter Diskussion zu GitHub - capi/springwatch-elm327-evcc: Monitors Dacia Spring's HV charging state via ELM327 OBD-II and publishes data for evcc integration

Freue mich, wenn es jemandem hilft und natürlich über jedes sonstige Feedback.

Beste Grüße,
Martin
 
Super
Bei mir funktioniert es bisher nur über die Cloud (aber auch zuverlässig) und mit Iobroker und NodeRed.
Der Weg ohne Cloud gefällt mir aber deutlich besser.
Super - jetzt hab ich ein neues Projekt
Danke für die Info
 
Die Anbindung an evcc ist relativ lose, ich denke, die REST API wird eigentlich nur abgefragt, ob gerade geladen werden soll und ob gerade wirklich geladen wird. Beides könnte man auch leicht so wegabstrahieren, dass die Info über MQTT oder ein beliebiges REST interface kommt.

Wenn ich irgendwo helfen kann, oder was erweitern soll, bitte einfach melden, macht mir Freude, wenn wer Nutzen daraus zieht.
 
Mit dem Adapter stellte ich dann schnell fest, dass ich damit den SoC problemlos auslesen konnte….
Cooles Projekt! Aber so problemlos erscheint es mir nicht. Wie bist du am Anfang auf den richtigen PID Code gekommen um den WiCan dazu zu bringen den SoC zurückzugeben und nix anderes?
Sorry ich bin noch totaler Anfänger auf dem Gebiet CAN und mqtt. Vielleicht könnt ihr mir hier etwas auf die Sprünge helfen. Kann man vielleicht das voreingestellte Protokoll von der Renault Zoe nehmen?
 
Die Anbindung an evcc ist relativ lose, ich denke, die REST API wird eigentlich nur abgefragt, ob gerade geladen werden soll und ob gerade wirklich geladen wird. Beides könnte man auch leicht so wegabstrahieren, dass die Info über MQTT oder ein beliebiges REST interface kommt.

Wenn ich irgendwo helfen kann, oder was erweitern soll, bitte einfach melden, macht mir Freude, wenn wer Nutzen daraus zieht.
In meinem Fall würde ich dir WiCan Daten in Home Assistant verarbeiten. Für meine Wallbox gibt es eine Anleitung wie man sie integriert. Auch andere Geräte im Haushalt werden über HA laufen. Ich bin auf jeden Fall an einem Austausch interessiert.
 
Wie bist du am Anfang auf den richtigen PID Code gekommen um den WiCan dazu zu bringen den SoC zurückzugeben und nix anderes?

Ich hab zuerst mit der App "Car Scanner" experimentiert. Da habe ich gesehen, was diese App alles auslesen kann. Das war (damals) nicht viel, aber der SoC war dabei. Die App kann ihre ELM327 Kommandos in ein Log-File protokollieren, das hab ich mir im Detail angesehen (und dann mal nichts verstanden ;-)). Das ist übrigens auch das Vorgehen, dass der Entwickler vom WiCAN in seinem Discord empfiehlt.

Als nächstes hab ich dann ELM327 Spezifikationen gesucht und gelesen und dann langsam verstanden, was Car Scanner da tut.
Der SoC kommt bei einer der standardisierten PIDs, 5B, zurück, und da ist dann die Formel auch dokumentiert. Was mir hier geholfen hat waren diesen beiden Seiten:
* Diskussion zu OBD2 Explained - A Simple Intro [2025]
* Diskussion zu OBD2 PID Overview [Lookup/Converter Tool, Table, CSV, DBC]

Der WiCAN kann im "Auto PID" Modus ein Set von PIDs periodisch pollen und nach MQTT senden. Allerdings hat sich dabei eben raus gestellt, dass er das 12V und das HV System wach hält, was ich definitiv nicht wollte.
Dann hab ich angefangen, nach meinem Verständnis der ELM327 Spezifikation mein Python Script zu bauen. Die oben angeführten Seite hat auch die Umrechnungsformel für PID 5B dabei. Ziel von dem Script war es, dass ich nur dann die Daten auslese, wenn ich sie brauche. Dass das Abfragen des 5B auch das schlafende System aufweckt (und nicht nur am Einschlafen hindert) war ein Zufallsfund und Glücksfall, weil es eben genau das zweite Problem, dass ich hatte, löste.
 
In meinem Fall würde ich dir WiCan Daten in Home Assistant verarbeiten.
Im Prinzip fragt mein Script derzeit folgende zwei Sachen von evcc ab:
1. Willst du gerade laden?
2. Wenn ja - Lädst du denn auch tatsächlich?

Diese beiden Informationen könnten leicht auch über einen anderen Kanal, z.B. MQTT, kommen.

Das Script funktioniert so, dass es periodisch den SoC abfragt. Was sich ändert, ist, wie _oft_ das passiert. Schläft der Spring, dann alle paar Stunden. Ist er "munter", dann öfter. Will das System laden, tut es aber nicht, dann jede Minute. Lädt das System, dann alle 3 Minuten.
Spezialbehandlung noch für den Fall, dass das Auto voll geladen ist, weil dann will die Box zwar laden, kann aber nicht. In dem Fall wird dann natürlich nicht das System alle 1 Minute wieder aufgeweckt.
 
Ich hoffe mal, daß einige der Mitglieder damit was anfangen können, denn es hört sich gut an. Ich bin da ungeeignet.
 
@capi
Vielen herzlichen Dank für deine ausführliche Antwort zu nächtlicher Stunde! Von CarScanner hatte ich gehört, wusste aber nicht, wie ich es benutzen soll. Das ist wirklich ein Glücksfall, dass die Abfrage das Auto aufweckt, denn mein Ladegerät kann das eben auch nicht. Ich denke, mit deinen Hinweisen sollte ich in der Lage sein den SoC rauszukriegen. Wie ich den dann weiter verarbeite muss ich noch schauen. Leicht wird es nicht, aber das Basteln und Programmieren soll ja auch ein kleines Abenteuer sein :cool:
Wahrscheinlich werde ich den SoC nur zu Beginn und und während des Ladevorgangs auslesen. Das reicht mir vollkommen aus und der Spring kann in der übrigen Zeit seinen wohlverdienten Schlaf genießen.
 
@astron
Das schöne am ELM327 Protokoll ist, dass es ein reines Text-Protokoll ist und an den alten Modem-Kommandos angelehnt ist (AT-Kommandos). Man kann das ganze auch händisch via telnet machen :)

Das Wichtigste ist eigentlich die Initialisierungs-Sequenz des ELM327 Chips (in meinem Fall emuliert durch den WiCAN), das ist Auto-Spezifisch, und für den Spring schaut das so aus: Diskussion zu springwatch-elm327-evcc/springwatch/elm327.py at main · capi/springwatch-elm327-evcc
Hier ist das "ATSP7" wichtig, weil es den Kommunikationsstandard und die Geschwindigkeit setzt. Alles andere ist dazu da, dass die Antworten in dem Format kommen, in dem ich sie erwarte damit ich das Ergebnis parsen kann.

Danach musst du eigentlich nur mehr das Kommando "01B5" als eigene Zeile schicken, und dann dann das letzte Byte (die letzten 2 Hex Zahlen) anschauen: Diskussion zu springwatch-elm327-evcc/springwatch/elm327.py at main · capi/springwatch-elm327-evcc, also den Wert * 100 / 255.
Damit es mit der Anzeige im Spring selbst übereinstimmt, muss ich noch ca 2.5% dazu zählen. Offensichtlich hält sich Dacia da ein wenig Reserve fürs "Überladen", wenn der Akku dann schwächer wird.

Achja, ein wichtiger Punkt noch: wenn der Spring "schläft", läuft der erste Poll in den Timeout ("NO DATA"), aber der Poll triggered eben die ECU und das System startet. Der zweite oder dritte Poll nach ein paar Sekunden geht dann durch.
 
Wow, toll das hört sich machbar an, vielen lieben Dank! Ich freue mich schon auf die Umsetzung.
 
@capi Super, Danke. Ich werde versuchen das mit springcontrol zu verbinden.
Die Idee, die Daten direkt vom Auto zu bekommen gefallen mir sehr. So kann über wlan alles abgerufen werden. Oder es geht über Mobilfunk, mit entsprecheder Ausstattung. Wenn mal nicht zuhause geladen werden soll.
 
Zurück
Oben