Add a SoC module for Nissan Leaf till MY 2019 #1682
Conversation
includes newest Base URL to Nissan API: https://gdcportalgw.its-mo.com/api_v230317_NE/gdc/
copied 1:1 from OpenWB V1.9
included module "fetch-soc" is derived from former soc.py in OpenWB V1.9
LKuemmel
left a comment
LKuemmel
left a comment
There was a problem hiding this comment.
Hast du eine openWB mit software2 und einen Leaf zum testen? Dann kann ich deinen PR in einen Feature-Branch mergen, dann kannst du über das UI ein Update darauf machen.
Ich habe eine OpenWB Series 2+, jedoch noch mit V1.9.304N, weil es bislang noch kein SoC-Modul für meinen Leaf gab. Ich müsste also erst auf V2.0 umsteigen. Ich denke darüber nach und melde mich nochmals. |
|
Ich kann wieder helfen. Ich habe einen NISSAN Leaf 2.ZERO Edition (2018), einen RasPi mit openWB 1.9.275 und einen Test-RasPi mit openWB 2.14. Ich werde mir die Files runterladen und in meiner openWB2 testen. Bitte beachtet auch meine Thread https://forum.openwb.de/viewtopic.php?p=110908&hilit=myvehicle#p110908. Diese Aufgabe muss nämlich auch noch gelöst werden. Aber jetzt zuerst Schritt für Schritt. Ich hätte es übrigens in eine paar Tagen auch versucht mit der Zufügung von pycarwings2.py im vehicle-Folder. Das war also auch meine Idee. Ich war einfach nicht so schnell wie mekrapp. |
Der Code ist auf dem RasPI mit openWB2 2.14 noch nicht lauffähig. In main.log war erkennbar, dass das SoC-Modul nicht geladen wurde. Ich musste in zwei Files Jetzt werden jedoch in der main.log andere Fehler geworfen, die darauf deuten, dass ungültige oder unvollständige Methoden aufgerufen werden. Es geht also nicht ohne Beschaffung eines RasPi für die Entwicklung und fürs Debuggen. Ich weiss nicht, ob openWB2 auch in einer VM auf dem Intel-PC lauffähig ist (Raspberry Pi Desktop for PC or Mac). Hier noch Know How für den Entwicklungs-RasPi:
Python3 kennt pycryptodome bereits. |
|
Zuerst einmal Danke an ddraeyer. Bei dem Import war ich mir nicht sicher, ob es reicht, pycarwings2 einfach aus dem gleichen Ordner wie soc.py mit "import pycarwings2" zu laden. Über die Ordnerstruktur läuft es also. Auch gut. Das ändere ich ab. (ich hatte sogar schon einmal eine Version damit) Bei dem geworfenen Fehler bin ich etwas verwundert, weil z.B. in BMW soc.py und in KIA soc.Py der gleiche Import Wenn man in den Ordner helpermodules.cli schaut, dann gibt es dort ein py Modul "_run_using_positional_cli_args.py", also mit einem vorangestellten Unterstrich. Außerdem gibt es weder den Import Befehl noch die Zeilen Letztlich geht es hier darum, wie die ganzen Module zum User und Passwort für den Login in den Nissan Server kommen. |
|
pycryptodome musste ich meinem Python 3 auf dem PC auch erst hinzufügen. Ohne das Paket gibt es kein Crypto.Cipher |
Co-authored-by: LKuemmel <76958050+LKuemmel@users.noreply.github.com>
Ich habe Anzahl der Wartezyklen noch von 3 auf 9 erhöht, also insgesamt 3 Minuten Wartezeit. Bis dahin müsste der Nissan Server den Leaf in jedem Fall erreicht haben. Falls nicht, kehrt requestSoc() nach drei Minuten ohne Update des SoC auf dem Server zurück und das anschließende readSoc holt sich dann halt nur den alten SoC vom Server. In der Zeit haben die Funktionen von pycarwings2 und responses auch genug Zeit für Einträge ins Logging für eine evtl. notwendige Fehleranalyse.
|
Im Einstellungsbereich war ich bislang noch nicht und es gibt dort bislang auch kein vehicle.vue für den Leaf. Ich vermute mal, dass das erforderlich ist, um das komplette SoC-Package für den Leaf in einer OpenWB 2.14 Umgebung testen zu können. Ich hatte mich eh schon gefragt, wie das ganze SoC Package an die User-ID und das Passwort für den Nissan Server kommt. |
Nein, zum Testen ist es noch nicht erforderlich. Unter Konfiguration | Fahrzeuge findet sich dann unter Leaf bei 'Einstellungen für SoC-Modul "Leaf"' eine rudimentäre XML-Struktur: Dort kann man seine Nissan-User-ID und sein zugehöriges Pw eintippen und speichern. Prüfen kann man das vom Windows-PC aus, wenn man darauf MQTT Explorer installiert hat. Damit kann man sich den Mosquito von openWB2 anschnallen und in die Topics gucken. Ich werde folglich erst zu einem späteren Zeitpunkt helfen, das ganz am Schluss noch erforderliche "beautifying" fürs GUI beizusteuern. Den Namen "Leaf" sollten wir noch diskutieren. Bei meinen Experimenten nannte ich das vehicule "Nissan". Begründung: pycarwings2.py unterstützt nicht nur den Nissan Leaf sondern auch den NV200. Wie es mit dem Nissan Ariya steht, entzieht sich meiner Kenntnis. Aufs neutrale "Nissan" kam ich, weil ich mich an "Renault" orientierte. Im Forum gibt es eine Liste für die von openWB2 unterstützte Renault-Modelle. Mir schwebt vor, es für Nissan gleichartig zu handhaben. Und für den Fall, dass der Ariya eine andere Bibliothek als pycarwings2 benötigen sollte, kannt dann diejenige Person, welche die Erweiterung an die Hand nimmt, einfach im GUI noch einen Parameter zufügen à la |
|
Ich habe heute auf dem Windows-PC die Virtualisierungssoftware Oracle VirtualBox installiert. Darin kreierte ich eine VM mit "Raspberry Pi Desktop for PC and Mac" (x86, 32-bit). Ich schaffte es leider auf keine Art, die Dependency cryptography zu installieren. Die Installation von openWB2 lief nicht fehlerfrei durch. Es konnte kein Wheel für cryptography gebildet werden. Es wird angemeckert, dass das erforderliche rust 1.63.0 nicht installiert werden kann. Für i686 gibt es max. 1.48.0. Fürs Testen führt somit kein Weg daran vorbei, einen RasPi >= 3B zu beschaffen. Mit MQTT Explorer können ebenfalls Fehlermeldungen erkannt werden.
|
|
Für die Entwicklung kann man relativ gut eine debian12 (oder 11? Kann ich nochmal nachschauen) VM nutzen, die kommt dem Raspberry Pi Recht nahe. Nutze ich selbst auch. Wobei gerade für die Validierung von Bibliotheken und Abhängigkeiten ein Raspberry Pi notwendig ist. Bin da selbst mal reingelaufen. |
|
Ich würde auch erst einmal direkt auf dem Pi mit OpenWB2.14 weiterprobieren. |
Nein, habe ich nicht. Das war ja nur mein Versuch, soc.py einfach ab Kommandozeile aufzurufen. Das hat unter openWB 1.9 funktioniert und den Output in die soc.log geschrieben. soc.log wird unter 1.9 regelmässig gelesen und für die Anzeige im Browser-GUI genutzt. Unter 2.14 muss der Output ins Topic geschrieben werden (unter get|soc (siehe meinen Screenshot)). Ich weiss somit nicht, ob ein manueller Aufruf unter 2.14 auch machbar ist. Aus meiner Sicht benötigt der Programmierer entweder einen RasPI, um selbst testen und debuggen zu können oder alternativ eine VM mit Debian 11 (bullseye). |
|
Ich habe eine VM mit Debian 11 (amd64) aufgebaut und darin erfolgreich openWB2 installiert. Nach der Einrichtung einer fixen IP-Adresse und der Nachinstallation von SSH und cURL in Debian (sudo apt-get install openssh-server curl) lief der Installationsbefehl curl -s https://raw.githubusercontent.com/openWB/core/master/openwb-install.sh | sudo bash wie Butter durch. |
|
Das klingt sehr gut. Wie weit bist Du dabei gekommen? Nur die OpenWB V2.14 erfolgreich in der VM installiert oder auch schon das Modul SoC Modul für den Leaf erfolgreich getestet? |
In der VM wurde openWB 2.14 frisch installiert und kurz gestartet. Die Konfigurationsmasken im Browser-GUI sind fehlerfrei zugänglich. Die Files vom Pull Request sind noch nicht eingespielt worden. Es liefen somit noch keine Tests. Auch hat der User openwb noch kein Pw. Ein ZIP-File der VM habe ich auf Google Drive gelegt. https://drive.google.com/file/d/1g4xyowe6OS0p3WwpZzGSUGkSDVAWnE9h/view?usp=drive_link Login / Pw: pi / qwertz12345 (pi gehört zur Gruppe sudo) Es ist eine fixe IP-Adresse konfiguriert. Sie kann geändert werden mit: Damit wäre dann alles vorbereitet, um von Windows aus per PuTTY auf die gestartete VM zuzugreifen. Dann können die eigenen Tests beginnen. Wenn der User openwb mit einem Pw ausgestattet wurde, können die Files vom Pull Request per WinSCP auf die VM gelegt werden und zwar nach openwb@debian11:/var/www/html/openWB/packages/modules/vehicles/leaf. Viel Erfolg beim Runterladen, Unzippen und anschliessenden Testen! |
|
Bitte wie oben beschrieben die Datei pycarwings2.py entfernen und in requirements.txt |
empty line at end of file removed accoring to warning from test run on Jul 15.
|
@benderl |
|
@LKuemmel , @benderl |
|
@LKuemmel |
calc_while_charging removed
variable "vehicle" renamed to "charge_point"
trailing whitespaces removed
|
ich habe in der Hoffnung, den pytest zu bestehen, zwei Änderungen an soc.py vorgenommen. Leider ohne Erfolg.
Der pytest spricht nach meinem Verständnis bei der Erstellung der SoC-Modulliste an. Muss ich sonst noch irgendwo das neue SoC Modul anmelden? @ddraeyer, bitte das geänderte soc.py Modul auch noch mal in Deiner OpenWB Umgebung testen. |
|
@mekrapp, herzliche Gratulation zu Deinem Durchhaltevermögen und Deiner Beharrlichkeit. Grossartig, dass der pytest nun nicht mehr motzt. Auf meiner VM mit Debian 11 habe ich bereits erfolgreich ein Update der vorhandenen openWB 2.1.5 auf 2.1.8-Alpha.1 durchgeführt. Das Fahrzeug konnte ich konfigurieren. Den SOC-Status erhalte ich fehlerfrei angezeigt. Nun bitte ich um etwas Geduld. Ich werde ein RasPi mit frischem Raspi OS Bullseye herrichten und eine Erstinstallation durchtesten. Ich werde mich dazu kommende Woche mit dem Ergebnis melden. |
|
@ddraeyer Auch von meiner Seite vielen Dank für die Unterstützung. Jetzt kann ich meine OpenWB ja auch auf V 2 umstellen. |
|
Vielen Dank natürlich auch an @benderl @LKuemmel und @remuslazar |
|
@mekrapp, vom erfolgreichen Test mit der VM Debian 11 hatte ich ja bereits berichtet. Inzwischen habe ich noch folgende Tests ebenfalls erfolgreich durchgeführt:
Die beiden Tests bewiesen für das neue SOC-Modul folgendes: Neuinstallation auf dem RasPi v3 klappt und Upgrade von Vorgängerversion auf aktuellste Version klappt auf dem RasPi v3 ebenfalls. Den RasPi v2 habe ich ebenfalls ab https://github.com/openWB/core mit openWB 2.1.8-Alpha.1 frisch ausgestattet. Beide RasPis laufen nun im Dauerbetrieb; bisher ohne negativen Feststellungen. |
|
@ddraeyer Inzwischen konnte ich mir einen RasPi 3B ausleihen, mittels Raspberry Pi Imager eine SD-Karte mit bullseye lite und user "openwb" aufsetzen und gemäß README auf https://github.com/openWB/core/tree/master eine openWB V2.1.8-Alpha.1 installieren. |
|
@mekrapp, V2.1.7 Patch 1 ist im lateststableimage enthalten (mit Betonung auf stable). Das SOC-Modul für den Leaf hat es erstmals in die V2.1.8-Alpha.1 geschafft und ist daher vorerst nur in einer Alpha-Version enthalten und noch in keiner Stable-Version. Als etabliert können wir unser neues SOC-Modul erst dann bezeichen, wenn es von 2.1.8 auch eine Stable-Version geben wird. Das dürfte noch einige Wochen dauern. Wenn man sich auf seinem RasPi eine Alpha-Version installiert, kann man dennoch mit den Bordmitteln im GUI von openWB2 auf eine Stable-Version upgraden, sobald diese dann verfügbar ist. |
|
@ddraeyer , ich habe im openWB Forum eine PN gesendet. Wäre nett, wenn Du da mal reinschaust. |
|
@mekrapp, https://forum.openwb.de/viewtopic.php?p=126519#p126519 ist gemeint, richtig? Ja, klar. Sehr gerne werde ich Feedback zum SOC-Modul vom Leaf beachten. |
|
@ddraeyer nein, ich habe im Forum eine private Nachricht eingestellt. Bin aber nicht sicher, ob ich dort den richtigen Usernamen erwischt habe. Wirst Du benachrichtigt, wenn dort eine Nachricht eingeht? |
6 participants
Folder "leaf" added to folder "packages/modules/vehicles".
Empty module init.py added into folder leaf.
Based on examples from other cars within packages/modules/vehicles the module config.py was created and added.
Based on examples from other cars the module soc.py was created and added.
The function fetch_soc() within soc.py was derived from snaptec/openWB/blob/master/modules/soc_leaf/soc.py (V1.9)
The modules pycarwings2.py and responses.py have been taken over from snaptec/openWB/blob/master/modules/soc_leaf/ (V1.9)
I have already tested successfully the function fetch_soc() within soc.py together with pycarwings2.py and responses.py in combination with my Leaf MY2018 and a Windows PC.
The module config.py and the other parts within soc.py besides fetch-soc()) were not tested so far.
So the whole leaf package needs still to be tested in an openWB V2 environment.