Hallo Zoe Ph2 Fahrer,
ich habe die OVMS3 Firmware geforked, um an einer Implementation für meine Zoe Phase 2 zu arbeiten, da die Renault Services nicht wirklich zuverlässig sind und auch später noch Geld kosten sollen. Ich bin durch Recherchen nach Alternativen über das OVMS Projekt gestoßen, welches ich sehr interessant finde.
Habe lange überlegt, aber mir dann trotzdem eine Box gekauft, obwohl ich wusste das die Phase2 nicht unterstützt würde.
Ich dachte mir ja die Firmware ist Open Source, ich kopiere die Phase 1 und gebe die richtigen Adressen ein und fertig. Naja so einfach war es dann doch nicht.
Zum einen bin ich kein C-Entwickler, habe zwar einige Projekte mit dem PlatformIO / Arduino Framework umgesetzt, aber da die OVMS diese nicht nutzt, war das einarbeiten erstmal sehr schwer. Die Komplexität der Software habe ich komplett unterschätzt, trotzdem habe ich mich dran gesetzt und viel mit gespielt und getestet. Die Lernkurve war extrem steil, was zum Beispiel die Syntax und der Aufbau der Firmware angeht.
Die nächste Hürde der CAN Bus an solches. Ich habe damit schon ein Projekt gemacht (RPi plus externes Display über CAN), aber eben nur CAN (Layer 2) wie er ist benutzt. Bis ich verstanden habe das die Zoe ISO-TP auf dem CAN verwendet und dieser nochmal eine Schicht oben drauf legt. Durch viel einlesen, loggen der Frames und herumrechnen ist es mir dann doch gelungen soweit durchzusteigen, dass ich Daten aus der Zoe bekomme.
Als Referenz habe ich mir erstmal CanZE zur Brust genommen, was für mich aber auch schwer war durchzublicken, da ich noch nie eine Android App programmiert hab. Ich hab die Datenpunktlisten nach interessanten Werten abgegrast und ins OVMS einprogrammiert. Das Ergebnis war, dass manche Abfragen unbeantwortet oder mit OutOfRange beantwortet wurden oder das seltsame Werte zurück kamen. Habe lange Zeit im trüben gestochert, bis ich mir dann die Mühe gemacht habe mit DDT4All und einer aktuellen Datenbank (11/2021) ins Auto gesetzt habe, um die Daten damit anzuschauen.
Viele interessante Datenpunkte waren gar nicht abrufbar oder unter einer anderen Adresse erreichbar, doppelt und dreifach vorhanden und nur eine davon ausgefüllt als Beispiel. Habe mir Screenshots erstellt und die zugehörigen XML Dateien analysiert, um die Adressen und die Umrechnung herauszufinden.
Dadurch bin ich sehr schnell an plausible Werte gekommen, die ich gut verarbeiten konnte.
Mittlerweile läuft die Kiste recht stabil und bringt auch immer saubere Werte, zumindest die die ich eingepflegt habe. Einige Datenpunkte musste ich wieder entfernen, da diese entweder unzuverlässig waren (mal gehts mal nicht) oder teilweise merkwürdige Werte geliefert haben. Fahre damit schon rund 2 Monate herum und fixe immer wieder Auffälligkeiten.
Am OBD Port gibt es sogar ein paar "Free Frames" die ich in meiner Implementation nutze, um den Wach Zustand zu erkennen und dann das Abfragen der Datenpunkte beginne. Da diese Implementation auf die einfache Möglichkeit des Anschlusses an den OBD Port ermöglichen soll, müssen alle Datenpunkte gepollt also abgefragt werden. Am einfachsten wäre es gewesen, permanent zu pollen und wenn Daten kommen diese zu verarbeiten.
In der Regel schläft die Zoe wenn sie nicht am Strom steckt, wie normal nach 10Minuten oder nach 1 Minute nach Abschließen ein und beantwortet jede Abfrage mit einem NAK vom Gateway, dies habe ich als Anhaltspunkt genommen das pollen zu stoppen und die Zoe als aus zu definieren. Aber wenn die Zoe angesteckt ist, aber die Wallbox abgeschaltet ist, hat dies einen gravierenden Nachteil. Und zwar ist die Zoe wenn die auf die Ladung wartet, im Halbschlaf. Das heißt EVC und LBC antworten auf das polling, laden aber die 12V Batterie nicht und die HV-Schütze sind ebenfalls aus. An sich nicht tragisch aber die Zoe versucht einzuschlafen, hört man an den Relais und das Abschalten der Displays, wacht aber mit einer weiteren Anfrage wieder auf. Dann kommt "Batterie im Sicherheitsmodus" im Display und sie versucht wieder einzuschlafen und wacht wieder auf. Dies passiert auch im abgeschlossenen Zustand.
Ich habe dies über Nacht getestet, das Resultat war das der 12V Akku komplett geleert wurde (~9V). Das OVMS hat aber sauber einen Alarm abgeschickt und die Zoe ist von selbst dann wach geblieben und hat den wieder auf knapp über 13V aufgeladen.
Dies hat mich dazu veranlasst den Ladungszustand "powerwait" zu beachten und das pollen komplett zu stoppen. Das führt allerdings dazu das das OVMS garnichts mehr mitbekommt. Aber zum Glück wenn die Zoe eingeschlafen ist und durch Aktivieren der Wallbox (oder aufschließen) sendet diese ein paar Freeframes an den OBD Port, welche ich detektiere und das pollen wieder starte. Daher die Warnung falls ihr die Firmware auch mal ausprobieren möchtet, das eventuell die 12V Batterie entladen werden kann.
Die FreeFrames habe ich mit der Logfunktion vom OVMS und Wireshark mit Can und ISOTP Decoder ausgewertet und mit auf die Repo unter Reference gelegt. Das LBC sendet nach Aufwecken oder Ladungsstart und -stopp die Heatmap mit wieviel SOC in welchem Temperaturbereich wieviel Zeit verbracht wurde (Reference/DDT/LBC/LBC Stats.png)
Des Weiteren kann ich nicht garantieren ob alle Softwareversionen der Steuergeräte in der Zoe, genauso reagieren wie meine.
Aufgrund meiner einfachen Programmierkenntnisse und der hohen Komplexität der Firmware, bitte ich die ggf. ineffziente Implementation nicht zu hart zu bewerten. Im Moment werden im Prinzip nur Werte aus der Zoe ausgelesen, um die Standard Metriken möglichst gut auszufüllen, um die bereits eingebauten Basisfunktionalitäten des OVMS zu nutzen (OVMS.V3/components/vehicle_renaultzoe_ph2_obd/docs/index.rst). Auch einige eigene Metriken habe ich angelegt, da mich auch die Drehzahl und Stromverbrauch der Wärmepumpe zum Beispiel interessieren.
Leider fehlen mir wichtige Datenpunkte wie, Restkilometer, Restladezeit, was ich durch Berechnen ausgleiche, aber dadurch nie die Werte angezeigt werden wie im Auto selbst und eben auch ungenau sind, da zum Bsp. die Ladekurve nicht beachtet wird.
Ich will auf jeden Fall wenn die Zoe Integration den Qualitätsstandard von anderen OVMS Integrationen erreicht, mit den Entwicklern Kontakt aufnehmen, damit diese in die Original Firmware integriert werden kann.
Da ich das Auto bis es auseinander fällt fahren und auch etwas Komfort genießen möchte, will ich die Integration nicht nur bei der Basisfunktionalität von OVMS belassen, sondern habe weitere Pläne auch Steuerungsfunktionen sowie auch Heizen beim Laden und andere Späße zu integrieren. Die OVMS Entwickler haben dafür sehr viele schöne Möglichkeiten integriert, die ich hier aktuell noch gar nicht nutzen kann. Dies erfordert natürlich das Anzapfen der CAN Busse nach dem Gateway oder knacken des Key-Austausch zur Freigabe des Schreibzugriffes über das Gateway. Dies erfordert aber das Dumpen der Firmware des Controllers und anstrengendes reverse engineeren, was sehr viel Zeit kosten würde.
Wer die Firmware bzw. mein Fork auf sein OVMS3.3 aufspielen möchte, kann einfach die URL von meinem Firmware OTA Server eingeben und das flashen "Flash from web" antriggern. Ich nutze die Versions-Tags wie das openvehicles-Team, sprich "main" kann geflasht werden und unter "edge" probiere ich wiederum neue Sachen aus, diese bitte nicht installieren.
OTA Server URL: https://ovms-ota.bit-cloud.de
Sourcecode: https://git.bit-cloud.de/carsten.schmiemann/OVMS3
Releases/Changelog: https://git.bit-cloud.de/carsten.schmiemann/OVMS3/releases
Feature list: https://git.bit-cloud.de/carsten.schmie ... /index.rst
Im Anhang die Metrics-Liste welche Metriken/Datenpunkte ausgelesen und berechnet wird und ein Screenshot des BMS Battery Monitors.
Dies ist ein Cross-Post aus dem goingelectric-Forum, um hier ebenfalls Zoe Ph2 Fahrer anzusprechen: [Ph2] OVMS 3.3 für Zoe Phase 2
Gruß
Carsten
