openWB Forum

rleidner hat geschrieben: ↑Mi Nov 16, 2022 1:41 pm Ich habe mir das gerade noch mal angesehen:
Im VW Modul wird beim Abholen der Daten die vin als Parameter mitgegeben.
Schritt 1 und 2 (post weiter oben) werden (hoffentlich) fehlschlagen, wenn die vin nicht im Account gefunden wird.
Nach Schritt 3 sollte alles wieder in sync sein.

Oder übersehe ich da was?

Nun haben wir einige APIs in der im PSA-Thread

In der PSA-API ist das etwas anders. Man meldet sich mit dem User an und hat dann Zugriff auf alle Fahrzeuge im Account.
Man kann nicht einmal direkt mit der VIN arbeiten, sondern muss sich eine FahrzeugID passend zur VIN aus der Liste der Fahrzeuge im Account heraussuchen.

Das PSA Soc Modul funktioniert aktuell ohne VIN, es wird also immer das 1. Fahrzeug im Account benutzt. Selbst nach mrinas und meinem Umbau wollten wir die VIN optional lassen, so dass in dem Fall ohne VIN das falsche Fahreug kommt und mit VIN kein Fahrzeug gefunden wird.

Aus User-Sicht wäre das bequemste das Fahrzeug per Select-Box auszuwählen, wie z.B. beim Tronity-Modul.
In dem Fall findet man also nie sein Fahrzeug

JHC hat geschrieben: ↑Mi Nov 16, 2022 1:51 pm

rleidner hat geschrieben: ↑Mi Nov 16, 2022 1:41 pm Ich habe mir das gerade noch mal angesehen:
Im VW Modul wird beim Abholen der Daten die vin als Parameter mitgegeben.
Schritt 1 und 2 (post weiter oben) werden (hoffentlich) fehlschlagen, wenn die vin nicht im Account gefunden wird.
Nach Schritt 3 sollte alles wieder in sync sein.

Oder übersehe ich da was?

Nun haben wir einige APIs in der im PSA-Thread

In der PSA-API ist das etwas anders. Man meldet sich mit dem User an und hat dann Zugriff auf alle Fahrzeuge im Account.
Man kann nicht einmal direkt mit der VIN arbeiten, sondern muss sich eine FahrzeugID passend zur VIN aus der Liste der Fahrzeuge im Account heraussuchen.

Das PSA Soc Modul funktioniert aktuell ohne VIN, es wird also immer das 1. Fahrzeug im Account benutzt. Selbst nach mrinas und meinem Umbau wollten wir die VIN optional lassen, so dass in dem Fall ohne VIN das falsche Fahreug kommt und mit VIN kein Fahrzeug gefunden wird.

Aus User-Sicht wäre das bequemste das Fahrzeug per Select-Box auszuwählen, wie z.B. beim Tronity-Modul.
In dem Fall findet man also nie sein Fahrzeug

Ich denke für das PSA Modul sind wir aktuell schon recht nah an einer guten Situation:
Die allermeisten User werden m.E. nur ein Fahrzeug im PSA Account haben. Für diese ändert sich nichts, es wird nur Benutzer&Kennwort eingegeben und die Daten des einzigen Fahrzeugs im Account abgerufen.

Für solche mit mehreren Fahrzeugen im Account gibt es die Möglichkeit die VIN anzugeben. Hierüber wird dann das Fahrzeug ausgesucht. -> Das kann noch weiter optimiert werden, bin ich dabei. Denkbar wäre z.b. ein DropDown mit allen verfügbaren Fahrzeugen (bzw. der VIN, hatte in den Antworten ad hoc leider keine Bezeichnung des Fahrzeugs gefunden). Optional könnte man diese Liste sogar filtern um nur solche mit Batterie zu listen. Womöglich könnte man mit diesem Filter auch solchen helfen die einen Verbrenner und ein BEV im Account haben, auch hier muss keine VIN angegeben werden.

Die VINs abrufen und zu speichern dürfte kein größeres Problem darstellen, die Liste wird ja eh' schon abgerufen. Allerdings muss das ad hoc aus dem Konfigurations-UI heraus getriggert werden. Geht bestimmt auch, wenn man - anders als ich - weiß wie

mrinas hat geschrieben: ↑Mi Nov 16, 2022 2:03 pm Ich denke für das PSA Modul sind wir aktuell schon recht nah an einer guten Situation:
Die allermeisten User werden m.E. nur ein Fahrzeug im PSA Account haben. Für diese ändert sich nichts, es wird nur Benutzer&Kennwort eingegeben und die Daten des einzigen Fahrzeugs im Account abgerufen.

Ich denke auch, dass das fürs erste super ist. Wer mehr Autos hat, muss halt mal kurz die VIN nachgucken gehen.

mrinas hat geschrieben: ↑Mi Nov 16, 2022 2:03 pm Für solche mit mehreren Fahrzeugen im Account gibt es die Möglichkeit die VIN anzugeben. Hierüber wird dann das Fahrzeug ausgesucht. -> Das kann noch weiter optimiert werden, bin ich dabei. Denkbar wäre z.b. ein DropDown mit allen verfügbaren Fahrzeugen (bzw. der VIN, hatte in den Antworten ad hoc leider keine Bezeichnung des Fahrzeugs gefunden). Optional könnte man diese Liste sogar filtern um nur solche mit Batterie zu listen. Womöglich könnte man mit diesem Filter auch solchen helfen die einen Verbrenner und ein BEV im Account haben, auch hier muss keine VIN angegeben werden.

Die WebSite und App kennen die Fahrzeugbezeichnung. In der API Dokumentation sind die Felder auch beschrieben, allerdings wird es nicht mit ausgegeben. Entweder ist die API an der Stelle nicht fertig oder die Credentials haben nicht die Rechte dafür.

mrinas hat geschrieben: ↑Mi Nov 16, 2022 2:03 pm Die VINs abrufen und zu speichern dürfte kein größeres Problem darstellen, die Liste wird ja eh' schon abgerufen. Allerdings muss das ad hoc aus dem Konfigurations-UI heraus getriggert werden. Geht bestimmt auch, wenn man - anders als ich - weiß wie

Wie gesagt, könnte man bei Tronity luschern.

Es ist nicht sinnvoll, wenn jedes Modul seine eigene Logik implementiert um Refresh-Tokens zu speichern. Eigentlich ist selbst das aktuelle vorgehen, dass jedes Modul überhaupt manuell OAuth implementiert fragwürdig. Das erzeugt jede Menge Code der copy&pastet wird und mit der Zeit in jedem Modul leicht abweicht, so dass Fehlerbehebungen in einem Modul nicht den anderen Modulen zu Gute kommen und das sogar schwierig ist zu integrieren.

Es wäre einigermaßen einfach einen generisches OAuth, den alle Module mit wenig Aufwand nutzen können. Tatsächlich hat das sogar schon jemand gemacht: Requests-OAuthlib. Der Bibliothek muss man nur eine Konfiguration bestehend aus den Zugangsdaten, Domains etc. geben und dann dann ist die Arbeit erledigt.

yankee hat geschrieben: ↑Mo Nov 21, 2022 7:58 pm Es ist nicht sinnvoll, wenn jedes Modul seine eigene Logik implementiert um Refresh-Tokens zu speichern. Eigentlich ist selbst das aktuelle vorgehen, dass jedes Modul überhaupt manuell OAuth implementiert fragwürdig. Das erzeugt jede Menge Code der copy&pastet wird und mit der Zeit in jedem Modul leicht abweicht, so dass Fehlerbehebungen in einem Modul nicht den anderen Modulen zu Gute kommen und das sogar schwierig ist zu integrieren.

Es wäre einigermaßen einfach einen generisches OAuth, den alle Module mit wenig Aufwand nutzen können. Tatsächlich hat das sogar schon jemand gemacht: Requests-OAuthlib. Der Bibliothek muss man nur eine Konfiguration bestehend aus den Zugangsdaten, Domains etc. geben und dann dann ist die Arbeit erledigt.

Das ist ein interessanter Ansatz, der weiter diskutiert werden sollte.
Ich denke das Thema wäre aber in einem neuen Thread besser aufgehoben.
Vielleicht kann ja einer der Moderatoren das verschieben in z.B "SOC - Generisches OAUTH Modul".

rleidner hat geschrieben: ↑Di Nov 22, 2022 11:07 am Ich denke das Thema wäre aber in einem neuen Thread besser aufgehoben.
Vielleicht kann ja einer der Moderatoren das verschieben in z.B "SOC - Generisches OAUTH Modul".

Das hast du mich falsch verstanden. Ich will kein generisches OAuth-Modul. Man könnte natürlich das generische JSON-Modul um OAuth erweitern, aber man braucht hier schon recht viel Konfiguration. Ich halte es aus "Usability" schon sinnvoll, wenn es dazu geeignete Module gibt, die sich auch in der Masse updaten lassen, wenn es Änderungen gibt.

Was ich will ist, dass die Module die OAuth nutzen eine gemeinsame Code-Basis nutzen, die all das erledigt, was mit dem OAuth-Protokoll zu tun hat.

yankee hat geschrieben: ↑Di Nov 22, 2022 11:59 am

rleidner hat geschrieben: ↑Di Nov 22, 2022 11:07 am Ich denke das Thema wäre aber in einem neuen Thread besser aufgehoben.
Vielleicht kann ja einer der Moderatoren das verschieben in z.B "SOC - Generisches OAUTH Modul".

Das hast du mich falsch verstanden. Ich will kein generisches OAuth-Modul. Man könnte natürlich das generische JSON-Modul um OAuth erweitern, aber man braucht hier schon recht viel Konfiguration. Ich halte es aus "Usability" schon sinnvoll, wenn es dazu geeignete Module gibt, die sich auch in der Masse updaten lassen, wenn es Änderungen gibt.

Was ich will ist, dass die Module die OAuth nutzen eine gemeinsame Code-Basis nutzen, die all das erledigt, was mit dem OAuth-Protokoll zu tun hat.

Ich meine mit "Modul" auch ein Modul im Python Sinn, also eine "Library", die in den SOC - Modules benutzt werden kann.

Hallo zusammen,

ich häng mich mal an diesen Thread mit einer Frage. Ich habe heute meinen e2008 abgeholt und erstmals die openWB getestet mit den Einstellungen wie sie hier empfohlen werden. Bei PV Laden hat er auch brav Überschuss geladen. Einzig die SOC wird nicht korrekt ausgelesen. Er hat heute 7% geladen (knapp 5kWh) und so wird es mir auch von der Wallbox angezeigt im Eck unten rechts (7%). Das Auto bzw. die Peugeot App zeigt allerdings 98% SOC an.
Ich habe beim Ladepunkt das PSA Modul eingerichtet mit Benutzer und Passwort (dasselbe wie für die App nehme ich an?), ich habe die Client ID und Secret aus GitHub kopiert etc. pp. . Wo könnte das Problem liegen ? Ich habe die Version 1.9288 stable drauf.
Danke für eure Hilfe!

Viele Grüße

Korbinian

Was sagt denn das SOC log file?

sagt bei jeder abfrage fetching SoC...failed.
und bevor er gestartet hat mit laden (pv laden) das er auf 0 stellt.
hier mal ein Abschnitt rauskopiert:
2022-12-29 12:43:07: PID: 6039: Lp1: Fetching SoC from Peugeot failed (LV0)
2022-12-29 12:43:04: PID: 6039: Lp1: Fetching SoC from Peugeot (LV0)
2022-12-29 12:38:07: PID: 30129: Lp1: Fetching SoC from Peugeot failed (LV0)
2022-12-29 12:38:04: PID: 30129: Lp1: Fetching SoC from Peugeot (LV0)
2022-12-29 12:05:27: PID: 18254: Lp1: Fetching SoC from Peugeot failed. Setting 0 as start SoC. (LV0)
2022-12-29 12:05:24: PID: 18254: Lp1: Charging started. Fetching SoC from Peugeot out of order. (LV0)
2022-12-29 12:05:17: PID: 16882: Lp1: Fetching SoC from Peugeot failed (LV0)
2022-12-29 12:05:14: PID: 16882: Lp1: Fetching SoC from Peugeot (LV0)


Anbei auch ein Bild meiner Einstellungen.