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
| # Copyright 2016 Jason Horne | ||
| # | ||
| # Licensed under the Apache License, Version 2.0 (the "License"); | ||
| # you may not use this file except in compliance with the License. | ||
| # You may obtain a copy of the License at | ||
| # | ||
| # http://www.apache.org/licenses/LICENSE-2.0 | ||
| # | ||
| # Unless required by applicable law or agreed to in writing, software | ||
| # distributed under the License is distributed on an "AS IS" BASIS, | ||
| # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
| # See the License for the specific language governing permissions and | ||
| # limitations under the License. |
There was a problem hiding this comment.
Es ist leider nicht möglich einen Teil der Software unter eine Lizenz zu stellen. pycarwings2 kann aber auch über pip installiert werden. Dazu in requirements.txt pycarwings2==2.14 ergänzen. Dann wird das Paket beim Starten installiert.
There was a problem hiding this comment.
pycarwings2 ist in V1.9 wie in meinem soc-draft eingebunden. Siehe hier:
https://github.com/snaptec/openWB/blob/master/modules/soc_leaf/pycarwings2.py
Wenn es in V1.9 genutzt wird, dann muss dafür ja früher mal ein OK eingeholt worden sein. Oder?
There was a problem hiding this comment.
Wenn ich auf die Zusammenfassung https://de.wikipedia.org/wiki/Apache-Lizenz#Eigenschaften schaue, dann sehe ich auch kein Problem, pycarwings2 weiterhin zu nutzen.
There was a problem hiding this comment.
Ja, in 1.9 ist das so gewesen. In software2 verfolgen wir eine anderen Linie. Hier wird die komplette Software unter eine Lizenz gestellt.
Bitte probiere, pycarwings über pip zu installieren. Vielleicht hat sich damit auch gleich das Crypto.Cipher-Problem gelöst.
Die imports musst du dann wieder auf import pycarwings2 ändern.
In der requirements.txt pycarwings2==2.14 hinzufügen und dann mit sudo systemctl restart openwb2.service den Sercvice neu starten. Dann wird das Package installiert. Das siehst du dann auch im main.log.
There was a problem hiding this comment.
Die Apache Lizenz ist nach meinem Verständnis ein Copy-Left und kein Copyright. Der beschriebene Lizenz-Umweg mag für Testzwecke gehen und für einige Nutzer von V2 ein möglicher Workaround sein. Das ist aber keine allgemeine Lösung für OpenWB V2 Nutzer mit einem älteren Leaf oder NV200. Mit dem vorgeschlagenen Workaround sind viele überfordert. Wie müsste eine Lösung aussehen, die man mit einem normalen Softwareupdate aufspielen kann?
Das Crypto.Cipher-Problem überschaue ich noch nicht. In der V1.9 ist Crypto.Cypher anscheinend noch enthalten. Sonst würde pycarwings2 dort ja nicht laufen.
Ich musste auf meinem PC mit Python 3.12 zusätzlich Pycryptodome mit "pip install pycryptodome" installieren, um Crypto.Cipher verfügbar zu haben. Inwieweit Crypto.Cipher bereits/noch auf der OpenWB mit V2 verfügbar ist, kann ich nicht sagen. Bitte prüfen.
There was a problem hiding this comment.
Was für ein Workaround? Die requirements.txt ist der Standardweg, um nach einem Softwareupdate fehlende Python-Packages zu installieren. Der Endbenutzer muss dafür gar nichts tun.
pycryptodome ist nicht vorhanden. Aber ist das überhaupt erforderlich, wenn man pycarwings über den Paketmanager installiert?
EDIT: In der Alpha wurde es mit bimmer-connected installiert.
openwb@openwb-2:~ $ pip show pycryptodome
Name: pycryptodome
Version: 3.20.0
Summary: Cryptographic library for Python
Home-page: https://www.pycryptodome.org
Author: Helder Eijs
Author-email: [email protected]
License: BSD, Public Domain
Location: /home/openwb/.local/lib/python3.9/site-packages
Requires:
Required-by: bimmer-connected
There was a problem hiding this comment.
Gut, die Crypto-Software ist also schon als Bibliothekspaket in V2.14 enthalten.
Ich hatte den (Um-)Weg über pip und requirements.txt nicht verstanden und angenommen, jeder V2.14 Anwender muss hier selbst einsteigen und pycarwings manuell installieren.
Jetzt fehlt nach wie vor noch eine Ausprobe des Leaf-Moduls im V2.14 Umfeld.
ddraeyer schlägt unten die Ausprobe eines V2.14 Abbildes auf einer VM mit Debian 11 vor.
Wäre das ausreichend? Oder muss der Test auf einer OpenWB mit RPi und V2.14 laufen?
There was a problem hiding this comment.
Hallo @mekrapp
Ausreichend ist es nicht. Sobald es jedoch als auf der VM als lauffähig gemeldet ist, werde ich sofort auf dem RasPi mit openWB 2.14 einen Test durchführen. Bitte jetzt auf der VM bis zur Lauffähigkeit entwickeln.
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 <[email protected]>
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.
still a LF inside, that I can't delete. So I will replace __init__.py by a really empty file to get flake 8 quiet
|
@LKuemmel |
|
Noch etwas zum Eintrag in requirements.txt: |
|
Außerdem ist der Modulname "responses" doch recht allgemein und es besteht eine hohe Wahrscheinlichkeit, dass es an anderer Stelle bereits ein Modul oder gar Paket mit diesem Namen gibt. Es könnte deshalb Importprobleme auslösen, wenn dieses Modul an anderer Stelle als in ./vehicles/leaf liegt. Soll ich es umbenennen, z.B. in "pycarwings2_responses"? Den zugehörigen Import in pycarwings2 müsste ich dann entsprechend anpassen. |
|
Zuletzt noch die Frage, wo ich die Module pycarwings2 und responses statt in .vehicles/leaf ablegen soll? In Fall eines Umzugs muss ich nämlich auch noch den Import von pycarwings2 innerhalb soc.py anpassen. |
Das ist eine warning, der Test läuft trotzdem durch. Das Problem mit der configurable beheben wir, wenn die requirements.txt geändert ist. |
|
Die anderen Fragen sollten sich erledigen, wenn Du pycarwings2 wie oben besprochen über die requirements.txt installierst. Bitte passe die requirements.txt in Deinen PR entsprechend an. Dann können die beiden Dateien aus dem PR entfallen und die Importe erfolgen direkt aus pycarwings2. ( |
pycarwings2 added to load this library (for the SOC module of Nissan Leaf) during start
|
Ich habe in meinem branch in requirements.txt "pycarwings2==2.14" hinzugefügt. |
Dann bitte auch die Dateien |
Co-authored-by: LKuemmel <[email protected]>
File deleted at this position as requested
File deleted at this position as requested
erledigt |
|
@LKuemmel Danke für den Abschluss. Wo finde ich die beiden Module pycarwings2 und responses ab nun in Github? |
|
Es wird das pycarwings2 Package aus dem Paketmanager genutzt: https://pypi.org/project/pycarwings2/ |
|
Das Paket ist dort seit 2-3 Jahren nicht mehr gepflegt worden und läuft definitiv nicht mehr. Im Mai hat Nissan die URL zu seiner API geändert. Das pycarwings2 von filcole enthält z.B. noch die alte URL. Ich habe damals das in V1.9 integrierte pycarwings2 Modul aktualisiert und in V1.9.304N einfließen lassen. Seither kann V1.9 den Leaf wieder auslesen. |
|
@LKuemmel ich habe mich inzwischen beim pycarwings2 Package von filcole umgeschaut. Es gibt dort seit 18. Mai einen PR, um die URL der Nissan API zu aktualisieren: filcole/pycarwings2#47 |
|
Ich habe mir die Comments der vergangenen 3 Wochen angeschaut. Ich habe noch nicht genau verstanden, ob es bereits etwas gibt, was ich auschecken könnte, um auf meiner VM mit Debian11 oder auf meinem Raspi mit openWB2 zu testen. Bitte meldet Euch, wenn ich Tests durchführen soll. |
|
@ddraeyer Derzeit gibt es nichts zu testen. |
|
Was genau meinst Du mit "ist nicht 1:1 einsetzbar"? Das Beispiel https://github.com/ev-freaks/pycarwings3/blob/master/examples/get-leaf-info.py entspricht doch in etwa, was in der api.py ablaufen soll. Statt asnycio.run, kannst Du auch eine asyncio event loop benutzen, so wie hier: core/packages/modules/vehicles/bmwbc/api.py Line 137 in f76bba6 |
|
Bislang importiere ich in soc.py das Paket pycarwings2 und nutze in der Funktion fetch_soc() mehrere Funktionen aus pycarwings2 wie get_leaf(), get_latest_battery_status(), etc. In pycarwings3 gibt es zwar prinzipiell die gleichen Funktionen. Aber das läuft nun alles asynchron unter asyncio mit await ab. Ich habe keine Ahnung, welche Konsequenzen das für soc.py und darüber hinaus hat. Gibt es da evtl. Kollisionen mit anderen asynchronen Prozessen? Müssen potentiell neue Exceptions abgefangen werden? Gibt es in pycarwings2 vs. pycarwings3 Unterschiede bei den Übergabeparametern der einzelnen Funktionen? Zumindest rund ums Handling der base_URL meine ich Unterschiede gesehen zu haben. usw. usw. ... Remus selbst schreibt: The library underwent significant changes, especially adopting asynchronous programming, which led to a break in backward compatibility with pycarwings2. Mit einem einfachen "import pycarwings3" statt "import pycarwings2" ist es jedenfalls nicht getan. Und damit ist pycarwings3 für mich auch kein 1:1 Ersatz. Außerdem ist pycarwings3 noch in einer jungen Phase (aktuell V0.7.7) und wird sicherlich noch einige Updates sehen. Ist das Paket in diesem Zustand schon in OpenWB willkommen? |
|
Lieber das pycarwings3-Paket, das noch gepflegt wird, als das pycarwings2-paket, dass schon seit 2 Jahren keine Updates mehr enthält. Ich würde lieber auf das neue Paket setzen, das noch gepflegt wird, als auf ein altes, wo man dann hoffen muss, dass es keine allzu großen Änderungen von Nissan gibt, weil sonst die Abfrage auch nicht mehr funktioniert. |
|
OK, ich schaue es mir an. |
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.