SOC: VWID

[rleidner]

Bei mir werden in Cloud und Beta-Cloud die SOC von ID.3 und smart korrekt angezeigt.
Lösche mal den Browser Cache (F5 bzw. Strg-F5).
Falls das nicht hilft, teste mal einen anderen Browser.

Leider auch nach Cache Löschen und Test mit Chrome sowie Firefox immer noch "--" ...
Gleiches auch in der "devweb" Variante.
Sehr seltsam, evtl. ein Konfigurationsbug?

Ich denke da kann nur das openwb-team helfen.

[pautz@t-online.de]

Hallo,

nun habe ich wiederum, aber andere Fehlermeldungen:

SoC-Log:

Code: Alles auswählen

022-06-15 14:02:32: PID: 2567: Lp1: SoC: Get status failed (LV0)
2022-06-15 14:02:27: PID: 2567: Lp1: Requesting SoC (LV0)
2022-06-15 13:59:50: PID: 14281: Lp1: SoC: Get status failed (LV0)
2022-06-15 13:59:44: PID: 14281: Lp1: Requesting SoC (LV0)
2022-06-15 13:54:19: PID: 6087: Lp1: SoC: Get status failed (LV0)
2022-06-15 13:54:14: PID: 6087: Lp1: Requesting SoC (LV0)
2022-06-15 13:44:09: PID: 27515: Lp1: SoC: Get status failed (LV0)
2022-06-15 13:44:04: PID: 27515: Lp1: Requesting SoC (LV0)
2022-06-15 13:34:03: PID: 16487: Lp1: SoC: 65 (LV0)

Debug-Log:

Code: Alles auswählen

./ladelog.sh: Zeile 32: ((: Get status failed: Syntaxfehler im Ausdruck. (Fehlerverursachendes Zeichen ist \"status failed\").
2022-06-15 14:09:14: PID: 19222: ungültiger Wert für soc: Get status failed (LV0)
./ladelog.sh: Zeile 32: ((: Get status failed: Syntaxfehler im Ausdruck. (Fehlerverursachendes Zeichen ist \"status failed\").
2022-06-15 14:09:04: PID: 17954: ungültiger Wert für soc: Get status failed (LV0)
./ladelog.sh: Zeile 32: ((: Get status failed: Syntaxfehler im Ausdruck. (Fehlerverursachendes Zeichen ist \"status failed\").
2022-06-15 14:08:54: PID: 16716: ungültiger Wert für soc: Get status failed (LV0)
./ladelog.sh: Zeile 32: ((: Get status failed: Syntaxfehler im Ausdruck. (Fehlerverursachendes Zeichen ist \"status failed\").
2022-06-15 14:08:44: PID: 15518: ungültiger Wert für soc: Get status failed (LV0)
./ladelog.sh: Zeile 32: ((: Get status failed: Syntaxfehler im Ausdruck. (Fehlerverursachendes Zeichen ist \"status failed\").
2022-06-15 14:08:34: PID: 14318: ungültiger Wert für soc: Get status failed (LV0)

SoC ist über die VW Apps abrufbar, jedoch nicht von der openWB.

Jemand ne Idee?

DANKE!

Der Abruf des SOC hat um 13:34:03 noch funktioniert:

Code: Alles auswählen

2022-06-15 13:34:03: PID: 16487: Lp1: SoC: 65 (LV0)

Wurde dann etwas verändert? Ist die Verbindung der oWB zum Internet stabil?

Die Meldungen im Debug Log sehen nach Folgefehler aus.

Ich würde noch mal einen Neustart (Einstellungen - System - Reboot, vorher Autos abstecken!) empfehlen.
Zusätzlich kannst du vor dem Neustart folgendes im Browser eingeben:
http://(ip der oWB)/ramdisk/soc_vwid_replylp1
Wenn der SOC-Abruf funktioniert, sollten die ersten bzw. letzten Zeilen so ähnlich aussehen:

Code: Alles auswählen

{
    "data": {
        "batteryStatus": {
            "carCapturedTimestamp": "2022-06-12T06:30:23Z",
            "currentSOC_pct": 80,
            "cruisingRangeElectric_km": 286
        },
        ...,
    "error": {}
}        

(ingesamt ca. 320 zeilen)
Falls hier etwas komplett anderes angezeigt wird, das Ergebnis hier posten.

Hallo,

nach dem reboot geht es wieder ohne Fehlereldung. Der Vorschlag mit dem Link / Adresse hat bei mir nicht funktioniert, daher kann ich davon kein log senden.

hier das SoC Log:

Code: Alles auswählen

2022-06-15 17:03:45: PID: 3026: Lp1: SoC: 100 (LV0)
2022-06-15 17:03:38: PID: 3026: Lp1: Requesting SoC (LV0)
**** REBOOT ****

[gvz]

Moin,

Ganz herzlichen Dank Dir für das Modul! Ich habe nach langer Update-Pause (meine Bugfixes kommen ja einfach nicht in die Software rein, aber das ist nicht Dein Problem) endlich mal wieder geupdated, Dein Modul gesehen: Und es funzt auf Anhieb!

Nun "mein" Problem, das ich für ein allgemeines Problem halte:
Wir stimmen ja m.W. bei VW irgendwie zu, dass wir brav sind und insbesondere nicht mit Scripten irgendwelchen Unfug treiben, der die Systeme belastet. Genau genommen ist aber die jetztige Implementierung ziemlich ressourcenbelastend bei VW:
- Jedesmal erfolgt ein Login
- ... der dann zu einem Refresh-Token (mit mutmaßlich "ewiger" Lebenszeit) führt
- ... und zur Anforderung eines Accesstokens
Halt der OAuth-Mechanismus. Wir produzieren doch damit tonnenweise (bei jedem Aufruf) gültige Refresh-Tokens bei VW!

Das Problem ist, dass die Library halt für den "Permanentbetrieb" in HomeAssistant geschrieben wurde, während das OpenWB-Modell halt die Einzelaufrufe sind. Die Library hat ja auch von Haus aus keinen State-Saving-Mechanismus.

Ich habe mich gerade mal hingesetzt und meinen absolut minimalen Python-Kenntnissen (und sehr viel Google) folgende Erweiterung geschrieben:

libvwid.py (am Ende eingefügt):

Code: Alles auswählen

        def save_tokens(self, filepath):
                pickle.dump(self.tokens, open(filepath, "wb"))
                return True

        def load_tokens(self, filepath):
                try:
                        self.tokens = pickle.load(open(filepath,"rb"))
                        self.headers['Authorization'] = 'Bearer %s' % self.tokens["accessToken"]
                        self.log.debug("Tokens loaded")
                        return True
                except:
                        return False

Und in Deinem Code die beiden Funktionen eingebunden:

Code: Alles auswählen

    async with aiohttp.ClientSession() as session:
        w = libvwid.vwid(session)
        w.set_vin(vin)
        w.set_credentials(id, pw)
        w.load_tokens("/tmp/vwid.tokens")

        data = await w.get_status()
        if (data):
            print (data['data']['batteryStatus']['currentSOC_pct'])
            try:
                f = open(replyFile, 'w', encoding='utf-8')
            except:
                os.system("sudo rm "+replyFile)
                f = open(replyFile, 'w', encoding='utf-8')
            json.dump(data, f, ensure_ascii=False, indent=4)
            f.close()
            w.save_tokens("/tmp/vwid.tokens")

Ich könnte mir vorstellen, dass das potentiellen Ärger mit VW einspart, und vermutlich ist es auch deutlich schneller und ggf. stabiler. Bei mir gehen nur 0,7 Sekunden auf die eigentliche Abfrage drauf (der Rest ist meinem lahmen Raspi geschuldet):

Code: Alles auswählen

pi@openwb:/var/www/html/openWB/modules/soc_vwid $ time ./soc_vwid.py --user $USER --password $PW --vin $FIN --chargepoint 1
73

real	0m1.870s
user	0m1.192s
sys	0m0.071s
pi@openwb:/var/www/html/openWB/modules/soc_vwid $ time ./soc_vwid.py --user $USER --password $PW --vin $FIN --chargepoint 1
73

real	0m1.965s
user	0m1.275s
sys	0m0.050s
pi@openwb:/var/www/html/openWB/modules/soc_vwid $ time ./soc_vwid.py --user $USER --password $PW --vin $FIN --chargepoint 1
73

real	0m1.869s
user	0m1.238s
sys	0m0.070s

Wie schon erwähnt: Nicht meine Sprache, und das Error-Handling ist unter aller Sau (keine Meldung, etc).
Aber vielleicht guckst Du es Dir mal bei Gelegenheit an...

[rleidner]

interessanter Verbesserungsvorschlag, vielen Dank.

Ich werde das in meiner Test-OWB 1.9 testen.
Wenn es problemlos funktioniert, werde ich über einen PR für 1.9 nachdenken.

Mein Konzept ist bisher, die library aus dem home assistant Umfeld unverändert zu verwenden.
Als VW das letzte mal (im Januar) am Server gedreht hat, war die library nach einem Tag angepasst und die Änderung kurz danach in der nightly.
Den zusätzlichen Code am Ende der library könnte man leicht bzw. automatisch nachziehen.

Das Performanceproblem ist aber auch Python geschuldet, jeder Programmstart benötigt einige Zeit für die Initialisierung.
Daher wäre ein weiterer Ansatz, den SOC-Prozess nur einmal zu starten und dann laufen zu lassen und den SOC im main.sh aus der ramdisk zu holen.
Das wäre ein "Permanentbetrieb" a la home assistant.

Ein Grund, das zu ändern wäre vor allem die Performance, die Serverbelastung bei VW sehe ich eher sekundär.

Und dann ist da noch 2.0.
Ich vermutee, die SOC-Abfragen werden in 2.0 anders laufen, möglicherweise sogar im "Permanentbetrieb", dann wäre das Problem dort nicht vorhanden.

[gvz]

Danke, und der erste Bug, der mir einfällt, ist, dass der Ladepunkt in dem Dateinamen fehlt.

Außerdem habe ich die Schutzkonzepte von Python überschätzt: Der Code muss gar nicht in die Library - man kann auch "von außen" auf die Objekte zugreifen.

Daher anbei eine gefixte Variante mit Ladepunkt im Namen, die mit der Original-Lib laufen sollte:

Zeiten von Erstaufruf (voller Login) und Zweitaufruf:

Code: Alles auswählen

time ./soc_vwid.py --user $USER --password $PW --vin $FIN --chargepoint 1
73

real	0m4.244s
user	0m1.536s
sys	0m0.172s
pi@openwb:/var/www/html/openWB/modules/soc_vwid $ time ./soc_vwid.py --user $USER --password $PW --vin $FIN --chargepoint 1
73

real	0m2.160s
user	0m1.448s
sys	0m0.051s
pi@openwb:/var/www/html/openWB/modules/soc_vwid $ time ./soc_vwid.py --user $USER --password $PW --vin $FIN --chargepoint 1
73

real	0m1.940s
user	0m1.255s
sys	0m0.052s

Die Datei heisst .txt, weil die zulässigen Extensions hier im Forum limitiert sind.

[rleidner]

Danke, so ähnlich habe ich es auch gedacht um den "import pickle" in der lib zu vermeiden.
chargepoint im file name ist klar
Das tokens file wird in die ramdisk geschrieben, wie alles andere auch.
Das token file wird jetzt immer neu geschrieben - ich werde mal sehen ob ich das nur schreibe, wenn sich das Token ändert.
Dann könnte man am timestamp des tokensFile auch sehen, wie lange der token schon gültig ist.

Ich lasse das jetzt mal einige Zeit laufen und denke dann über den PR nach.

[gvz]

Ich finde so was wie einen "Danke"-Button nicht, daher Text

Ob alle paar Minuten nun neben den zig Files, die sekündlich auf die Ram-Disk geschrieben werden, noch das Token-File dazu kommt, ist m.E. nicht so relevant. Ich weiß nicht, wie lange das Access-Token durch ein Refresh-Token erneuert werden muss, aber der Web-Login (full connect) dürfte wirklich nur so oft nötig sein, wie Du Dich auch bei der App wieder neu anmelden musst.
Wegen der ganzen Credential-Stuffing-Attacken führt man heutzutage so etwas (mit Passworteingabe) eigentlich immer über Webseiten, und wir können echt froh sein, dass da VW noch nicht Captchas etc. implementiert hat.

[rleidner]

PR 2302 created: https://github.com/snaptec/openWB/pull/2302

[rleidner]

PR 2302 merged in der Nightly: https://github.com/snaptec/openWB/pull/2302
Dank an gvz für die Anregung!

Bei meinen Tests bisher werden die Token nach 60 - 90 Minuten erneuert.
In diesem Fall wird in EV-Soc log eine Meldung wie diese geschrieben:

Code: Alles auswählen

2022-07-19 13:22:48: PID: 28612: Lp1: tokens_new != tokens_old, rewrite tokens file

Ich habe den SoC zum Test alle 5 Minuten abfragen lassen, da wurden die Token nach max. ca. 90 Minuten erneuert.
In anderen mir bekannten oauth Szenarien sind die Token deutlich länger gültig.
Möglicherweise geht VW auch da einen eigenen Weg.

Weiterhin werden einige Permission Exceptions besser behandelt und dazu Meldungen in soc.log geschrieben.
Diese neuen (1-zeiligen) Meldungen wie diese sind erwartet und kein Grund zur Sorge.

Code: Alles auswählen

2022-07-18 18:24:13: PID: 12018: Lp1: chmod replyFile exception, use sudo, e=[Errno 1] Operation not permitted: '/var/www/html/openWB/ramdisk/soc_vwid_replylp1'

EDIT: zu den recht kurzen Gültigkeiten der Token:
Ich frage den soc auch noch von meiner produktiven OWB (Stable) ab (120 min im Standby):
Das lässt den Token immer wieder ungültig werden.
Ich habe das jetzt mal auf MQTT konfiguriert - das sollte die token länger gültig lassen.
Falls das so sein sollte müßte man sich bei mehreren OWBs mit denselben SOC-Modulen überlegen, ob man die token (über mqtt?) abgleicht...

[derNeueDet]

Hast du schon mal getestet, ob ein Token auf einem anderen System funktioniert? Ich hätte erwartet, dass die Token auch eine Referenz zu einem System (IP oder was in der Richtung) haben, um einen Token Diebstahl zu verhindern.

VG
Det