Support: SoC Leaf

[Maxify23]

Guten Abend
Gibt es schon Fortschritte mit dem Nissan SOC für die OpenWB FW 2 ?
VG

[StefanVer]

Inzwischen wieder 3 Monate vergangen, allerdings ist die letzte Release wohl auch von 2023-09-27. Gibt es hier irgendwelche Neuigkeiten?
Ich hab gesehen, dass auf Github schon ein soc_leaf existiert. Arbeitet da schon jemand dran? Kann man unterstützen? Danke!

[Michael_F]

Meines Wissens gibts noch kein SoC-Modul in der 2.x, auch nicht in Arbeit. Wo auf Github hast du das gesehen?
Wäre aber auch sehr an dem SoC Modul für die 2.x interessiert, das ist einer der Gründe warum ich noch nicht wechsle. Ich würde aber auch unterstützen wenn sich jmd bereit erklärt zu programmieren.

Ich weiß auch nicht ob das zielführend ist, die SoC-Module an die Community "auszulagern". Zumindest die die in der 1.9er drinnen sind sollten für einen (niederschwelligen) Umstieg vom oWB-Team portiert werden.

[Phase1]

Na dann - leg los .
Github heißt die Spielwiese. https://github.com/snaptec/openWB/tree/master/modules
SoC-Module werden aktuell meist von der community gepflegt, weil die Ressourcen bei openWB beschränkt sind.

Ich war jetzt mal auf der "Spielwiese" https://github.com/snaptec/openWB/tree/ ... s/soc_leaf
Beim Leaf ist die SoC Abfrage für V1.9 schon recht speziell. Da gibt es zwei Modulpakete von Jason Horne von 2016. pycarwings2.py enthält die eigentlichen Kommunikationsmodule zum Nissan-Server und die Module in responses.py werten die Antworten vom Server aus. soc.py nutzt etliche Module aus diesen Paketen. soc.py wiederum wird von der Shell main.sh aufgerufen und erhält von dort auch die Login-Daten zum Nissan Server.
Grober Ablauf:
soc.py wird von main.sh im Regeltakt der OpenWB (alle 10 sek) aufgerufen. soc.py erhöht dann nur den soctimer um 1. Bei 180 wird der soctimer wieder genullt.
Nur wenn der soctimer = 10 ist, erfolgt die eigentliche SoC Abfrage. Dabei wird eine https-Verbindung zum Nissan Server aufgebaut. Dann folgt der Login, dann die Abfrage des letzten SoC-Wertes vom Server, dann die Aufforderung an den Server, sich den neuesten Stand vom Auto zu holen, dann warten bis neuer Wert auf dem Server verfügbar ist, dann Abfrage des neuen SoC-Wertes vom Server und Abspeicherung im socFile der OpenWB.
Für diese SoC Abfrage benötigt soc.py mindestens 40 Sekunden. Es können aber auch 60 oder mehr Sekunden sein, jenachdem wie schnell das Auto antwortet.

Daraus ergibt sich für mich eine Verständnisfrage an die Profis.
Wenn soc.py für die Abfrage volle 40 Sekunden braucht, warum erfolgt dann lt. EV SoC Log trotzdem alle 10 Sekunden ein Update des soctimers?
Wird da einfach im 10 sek-Regeltakt erneut soc.py in einem separaten parallen Prozess aufgerufen und dort nur der soctimer inkrementiert?

Sodann nutzen soc.py und die o.g. Module fleißig den Logger EV SoC Log. Es werden je Abfrage mehr als 100 Zeilen in den Logger eingetragen. Sind die EV SoC Logger von 1.9 und 2.0 kompatibel? Oder muss das ganze Logging angepasst werden?

[StefanVer]

Hallo Phase1,
vielen Dank nochmal für den Hinweis auf die Spielwiese.
Gibt es irgendwo eine Anleitung, ein HowTo, wie, wenn man Änderungen an so einem Modul bewerkstelligt, wie man diese testen kann und letztlich auch in die eigene Version auf der OpenWB draufbekommt? Einen fähigen Python Programmierer hätte ich ja ggf an der Hand, aber so steht man doch erstmal wie Ochs vorm Berg.
Oder gibt es irgendwelche Neuigkeiten seitens OpenWB?
Ist schade - kann die neue Version (und damit eigentlich OpenWB) kaum wirklich weiterempfehlen, wenn das alles so zähflüssig verläuft. Bitte, will damit niemand persönlich angreifen. Hatte nur gedacht, dass da sich im Laufe der Zeit auch etwas tut.

[Phase1]

Gibt es irgendwo eine Anleitung, ein HowTo, wie, wenn man Änderungen an so einem Modul bewerkstelligt, wie man diese testen kann und letztlich auch in die eigene Version auf der OpenWB draufbekommt? Einen fähigen Python Programmierer hätte ich ja ggf an der Hand, aber so steht man doch erstmal wie Ochs vorm Berg.

ja, hatte rleidner schon weiter oben drauf hingewiesen:

Ich würde mit dem Wiki beginnen:
https://github.com/openWB/core/wiki/Neu ... grammieren
Dann mal in eines der bereits portierten SOC Module sehen und als Muster nehmen.

Die SoC Module in OpenWB 1.9 sind wie oben schon geschrieben hier https://github.com/snaptec/openWB/tree/ ... s/soc_leaf
Ein Muster SoC Modul für OpenWB 2.0 ist hier https://github.com/openWB/core/tree/mas ... le_vehicle
Und die bereits existierenden SoC Module für OpenWB 2.0 sind hier https://github.com/openWB/core/tree/mas ... s/vehicles

Wie ich oben schon schrieb, sind mir die ganzen Schnittstellen zwischen dem SoC Modul und dem übergeordneten OpenWB 2.0 noch nicht klar. Insbesondere das ganze Logging, aber auch die Übergabe der Login-Daten und die Rückgabe des SoC-Wertes. Wenn ich das raffe, melde ich mich hier wieder.

@StefanVer, wenn der "fähige Programmierer" tatsächlich anfängt, zu programmieren, dann bitte hier melden.

[StefanVer]

Hallo Phase1,
ich hab mal mit ihm draufgeguckt, hab github mit ihm angeschaut - und er hat mir die Aufgabe übertragen, das Ganze mal so hinzustellen, dass man auch mit dem Debugger draufgucken kann. Hab mal geschaut, dazu muß man wohl eine VM installieren, mit Raspi PI OS Lite 2.1 und da die github Sachen hinkopieren. Irgendwie ist das bei mir aber im Alltagsgeschäft untergegangen, als ich da hängengeblieben bin.
Auf dem PC bekommt man mit PyCharm das soc.py auch nicht zum rennen (beschwert sich in pycarwings2.py über Crypto.Cipher import Blowfish - no module named 'Crypto'. Hab dann versucht, entsprechende Library einzubinden, aber auch da hängen geblieben.
Wäre sicher schon hilfreich, mal direkt auf die OpenWB draufgucken zu können - aber da ist das Login per PuTTY (SSH) auch nicht möglich (bzw Login wird geheimgehalten - klar, will ja auch keiner supporten, wenn jeder Dummy da alles mögliche probiert).
Auf eienm Raspi ohne die ganze OpenWB Hardware hab ich auch schon mal versucht, aber mit Ausgabe über normale HDMI scheint der sich auch aufzuhängen (Kopie vom Image von meiner WB).
Da ich bislang noch kein HowTo gefunden habe, muß ich wohl noch einige Stunden durch die Foren jonglieren - auch um zu erfahren, wie ich das, wenn es denn wirklich mal eine Beta davon gibt, in die WB so implementiert bekomme, dass ich es irgendwie austesten kann.
Da programmiert man seit 40 Jahren - und steht doch wieder wie Ochs vorm Berg weil doch jede Entwicklungsumgebung anders ist.
Ich melde mich, wenn ich weitergekommen bin - oder wenn mir jemand noch Tips zukommen läßt

[Phase1]

Seit vorgestern, 20.05.2024 funktioniert die SoC Leaf Abfrage nicht mehr. Es kommt bereits beim Login in die API die Fehlermeldung "404 Not Found". Insgesamt sieht es so aus, wie es @LEAFerant bereits in seinem Post viewtopic.php?p=109666#p109666 beschreibt.
Bei Bedarf kann ich meinen Log auch noch posten.

Anscheinend hat Nissan die URL zur API geändert.
Bisher wird in meiner OpenWB V 1.9.277 vom SoC Leaf Modul innerhalb pycarwings2 die URL https://gdcportalgw.its-mo.com/api_v210707_NE/gdc/ aufgerufen.
Lt. Github https://github.com/evcc-io/evcc/issues/13941 lautet die neue URL https://gdcportalgw.its-mo.com/api_v230317_NE/gdc/
Mit etwas Glück ist das die einzige Änderung, die man am SoC Leaf Modul durchführen muss.

Hat noch jemand außer @LEAFerant und mir aktuell Probleme mit der SoC Abfrage vom Nissan Leaf?

Wer könnte in einer Nightly in https://github.com/snaptec/openWB/blob/ ... rwings2.py in Zeile 75 die BASE_URL von "https://gdcportalgw.its-mo.com/api_v210707_NE/gdc/" in "https://gdcportalgw.its-mo.com/api_v230317_NE/gdc/" ändern?

Ich wäre bereit, eine Nightly von V1.9 mit dieser Änderung zu testen.

[Phase1]

Die My Leaf App wurde am 22.05.2024 aktualisiert und greift im carwings Modul jetzt ebenfalls auf die neue BASE_URL https://gdcportalgw.its-mo.com/api_v230317_NE/gdc/ zu.

[Phase1]

...
Auf dem PC bekommt man mit PyCharm das soc.py auch nicht zum rennen (beschwert sich in pycarwings2.py über Crypto.Cipher import Blowfish - no module named 'Crypto'. Hab dann versucht, entsprechende Library einzubinden, aber auch da hängen geblieben.
...

Ich habe auf dem PC Python 3.12 laufen und dort auch Crypto.Cipher aus PyCryptodome installiert. Wie das geht, sieht man hier https://www.youtube.com/watch?v=qRuMf6yXXyA

Mit einem etwas angepasstem soc.py (u.a. ohne leaftimer) und der neuen BASE_URL (s.o.) konnte ich soc.py direkt in Python 312 zum laufen bringen und die API erreichen.
Leider bleibt soc.py dann beim Aufbau der verschlüsselten HTTPS Session hängen:

2024-05-26 20:59:41,358 - urllib3.connectionpool - DEBUG - Starting new HTTPS connection (1): gdcportalgw.its-mo.com:443
2024-05-26 20:59:43,518 - urllib3.connectionpool - DEBUG - https://gdcportalgw.its-mo.com:443 "POST /api_v230317_NE/gdc/UserLoginRequest.php HTTP/1.1" 200 None
2024-05-26 20:59:43,565 - pycarwings2 - DEBUG - Response HTTP Status Code: 200
2024-05-26 20:59:43,565 - pycarwings2 - DEBUG - Response HTTP Response Body: b'{"status":404,"message":"INVALID PARAMS"}'
2024-05-26 20:59:43,587 - pycarwings2 - ERROR - carwings error INVALID PARAMS: 404

Carwings bestätigt meinen UserLoginRequest also noch, meckert aber bei den von mir übergebenen Parametern. Im Vergleich zu einem alten SoC-Log aus der OpenWB vor der Änderung der BASE_URL hat sich an den übergebenen Parametern aber nichts geändert, auch nicht am verschlüsselten Passwort.

Bin gespannt, ob ich hier noch weiter komme.