NEU: EVCC SoC Integration für zahlreiche Fahrzeugtypen

[Daniel2202]

Das hört sich gut an. Update kommt dann mit dem nächsten Nightly?
Grüße Daniel

[Bucky2k]

Müsste eigentlich jetzt schon gehen, die Logik des EVCC Moduls liegt auf dem Server, an der Binary/im OpemWB Code muss mutmaßlich nix angepasst werden

[Daniel2202]

Kann bestätigen das Skoda jetzt funktioniert. Danke super Arbeit. Grüße Daniel

[LutzB]

Müsste eigentlich jetzt schon gehen, die Logik des EVCC Moduls liegt auf dem Server, an der Binary/im OpemWB Code muss mutmaßlich nix angepasst werden

Da muss ich jetzt aber mal genauer nachfragen:

Bis jetzt wurde damit geworben, dass die Zugangsdaten lokal bleiben und die Logik ebenfalls auf dem Raspi läuft. Lediglich eine Berechtigung über das Abo-Token wird auf dem Evcc Server geprüft.

Wie kann es da sein, dass die Logik jetzt auf einmal in der Cloud liegt? Dann werden die Zugangsdaten ja zwangsläufig ebenfalls dort zumindest zwischengespeichert. Gibt es eine Datenschutzerklärung, was wie verarbeitet wird?

[Bucky2k]

Müsste eigentlich jetzt schon gehen, die Logik des EVCC Moduls liegt auf dem Server, an der Binary/im OpemWB Code muss mutmaßlich nix angepasst werden

Da muss ich jetzt aber mal genauer nachfragen:

Bis jetzt wurde damit geworben, dass die Zugangsdaten lokal bleiben und die Logik ebenfalls auf dem Raspi läuft. Lediglich eine Berechtigung über das Abo-Token wird auf dem Evcc Server geprüft.

Wie kann es da sein, dass die Logik jetzt auf einmal in der Cloud liegt? Dann werden die Zugangsdaten ja zwangsläufig ebenfalls dort zumindest zwischengespeichert. Gibt es eine Datenschutzerklärung, was wie verarbeitet wird?

Das kann AndiG sicher erläutern, evtl. habe ich es auch falsch verstanden. Gespeichert werden die Zugangsdaten nicht, laufen aber einmal über den Server wenn ich mich nicht täusche

[andig]

Das Vorgehen war hier viewtopic.php?p=30495#p30495 schonmal beschrieben. Die Fahrzeugdaten gehen genau beim erstellen des Fahrzeugs in die Cloud, werden dort aber nicht gespeichert. Sie existieren im Hauptspeicher genau so lange wie die Abfrage läuft.
Die Datenschutzerklärung ist in Erstellung und wir asap nachgereicht.

Dein Modell das lokal zu machen wäre auch möglich. Dann müsste aber openWB so schnell beim Binary compilieren sein, wie ich Fehler beheben kann. Z.B. wurde gestern Abend ein Problem bei Daniel mit Skoda behoben. Die Lösung konnte ich sofort deployen- wie soll das bei eincompilieren in das Image funktionieren?

Viele Grüße,
Andreas

[snoerenberg]

Hallo,

da ich auch Interesse an dem EVCC habe, verfolge ich die Threads hier.
Es erklärt sich mir die Implementierung nicht ganz, vielleich kannst du mich da erhellen.

Die Daten (AudiUser/AudiPass/VIN) liegen nur lokal auf der WB.
Einmalig wird ein Token zu der EVCC Cloud geschickt.

Die Response von der Cloud ist jedoch lediglich eine Art Lizenzschlüssel, die die Funktionalität aktiviert?
Oder wird dort der AccessToken/RefreshToken von Audi zurückgegeben?
Wie oft wird eine Verbindung zur EVCC Cloud erstellt? Nur einmalig (so wie ich es gelesen habe).

Falls dann ein Problem mit dem EVCC Modul auftritt, kann dies mEn auch nur durch ein Update der OpenWB behoben werden.

Danke dir
Gruß Stephan

[andig]

Hast Du den Link oben gelesen?

Alle Requests zum Fahrzeug laufen über die Cloud. Jedoch OHNE dort Fahrzeugdaten zu speichern. Die Eintrittskarte für die Cloudverarbeitung ist ein gültiges Token das 1x mit Hilfe der Sponsordaten von Github erzeugt wird.

Vorteil des Setups: Fehlerbehebungen können (und werden) sofort erfolgen wenn sie bei EVCC umgesetzt sind ohne den Umweg über das OpenWB Releasemanagement.

Viele Grüße,
Andreas

[LutzB]

Ich denke, es läuft so:

OpenWB startet die SoC Abfrage an den EVCC Server. Übertragen werden das Abo-Token sowie die Zugangsdaten für das Fahrzeug. Der Server redet dann mit den Servern der Fahrzeughersteller. Zu diesem Zeitpunkt kann potentiell alles mit den Zugangsdaten passieren. Der EVCC Server liefert dann den SoC an openWB zurück.

Einziger Unterschied zu Tronity ist, dass dort die Zugangsdaten auch in der Cloud gespeichert werden. Der Vorteil wiederum davon ist, dass die sich darum kümmern, die Fahrzeugdaten so abzurufen, dass das Fahrzeug nicht unnötig geweckt wird. OpenWB bekommt immer schnell eine Antwort direkt von Tronity.

[andig]

Einziger Unterschied zu Tronity ist, dass dort die Zugangsdaten auch in der Cloud gespeichert werden. Der Vorteil wiederum davon ist, dass die sich darum kümmern, die Fahrzeugdaten so abzurufen, dass das Fahrzeug nicht unnötig geweckt wird. OpenWB bekommt immer schnell eine Antwort direkt von Tronity.

Ich verstehe nicht, welchen Vorteil Du bei Tronity siehst. Könntest Du das bitte konkret erläutern? Woher weiss Tronity, ob das Fahrzeug unnötig geweckt wird? Was meinst Du mit "wecken" bzw. welche Fahrzeugtypen sind betroffen?
Bitte auch in Differenzierung zum "alten" EVCC Modul bei dem es diese Diskussion bisher nicht gab?

Viele Grüße, Andreas

PS.: bei evcc wird das Fahrzeug abgefragt wenn es notwendig ist- ich gehe davon aus, dass das bei OpenWB auch der Fall ist.