capi
eDacia-Neuling
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
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
