[LKuemmel]

@rleidner Es stand ja noch ein Refactoring Deiner VW Implementierung aus.
Ich habe mich da mit der KI mal dran gewagt. Das Problem mit dem Hintergrund-Thread habe ich durch ein verkürztes Abfrage-Intervall, dass das Modul vorgeben kann, gelöst: #4147
Die Paket-Daten werden in Variablen abgelegt, nicht in Dateien. Die Anforderungen aufgrund der spezifischen Portal-Eigenheiten habe ich der KI mitgegeben. Bitte schau mal rein und teste, ob Du mit diesem Stand weiter arbeiten kannst.

Vor Nutzung muss die kontinuierliche Abfrage im Portal angestoßen werden:
https://eu-data-act.drivesomethinggreater.com/de/de/eu-data-act.html
Benutzerdefinierte Daten abrufen - All Data - 15 min.
Es kann mehrere Stunden dauern, bis erste nicht-leere Datenpakete ankommen.
Die Fahrzeugdaten können auch danach deutlich verzögert eintreffen.

Das Modul fragt das Portal synchron über den normalen openWB-SoC-Scheduler ab.
Empfehlung: die Abfrageintervalle während und außerhalb des Ladens auf 600 Sekunden
setzen. Bei Abruffehlern fordert das Modul über den Intervall-Callback höchstens
60 Sekunden bis zum nächsten Versuch an, unabhängig vom Drei-Fehler-Zähler.
Nach erfolgreichem Abruf gelten wieder die konfigurierten Intervalle.
Manuelle und reguläre frühere Abfragen bleiben möglich; die Einstellung für
Abfragen nur bei eingestecktem Fahrzeug gilt auch für Wiederholungen.

Alle noch nicht verarbeiteten Datenpakete werden von alt nach neu ausgewertet.
Fehlende, ungültige oder ältere SoC-Werte überschreiben keinen gültigen Stand.
Fehlende Reichweite und Kilometerstand bleiben aus dem letzten gültigen Stand
erhalten; der Kilometerstand wird nicht zurückgesetzt. Numerische Nullwerte gelten.
Der Zeitstempel stammt vorrangig aus dem Caddy-SoC-Feld timestampUtc, sonst aus
dem Maximum aller car_captured_time-Werte, ersatzweise aus timestamp (PR #4127).
Wenn keine Reichweite bekannt ist, wird sie aus SoC, Kapazität und Verbrauch berechnet.

Cache, verarbeitete Datensätze und Retry-Flag bleiben ausschließlich im Arbeitsspeicher
des Fahrzeugmoduls. Es werden weder persistente Zustandsdateien noch Rohdaten in der
Ramdisk gespeichert oder eingelesen. Nach einem Prozessneustart oder einer Neuerstellung
des Moduls muss der Cache durch einen erfolgreichen Portalabruf neu gefüllt werden.
Bei Portalausfall wird der Cache mit ursprünglichem Zeitstempel und Warnung
zurückgegeben. Ohne gültigen Cache wird ein Fehler gemeldet, kein künstlicher 0%-Wert.
In beiden Fällen wird nach höchstens einer Minute erneut versucht.

Code-Aufbau:
api.py Login, Wiederanmeldung und HTTP-/ZIP-Abrufe
vehicle_data.py Feldzuordnung, Zeitstempel und Datenauswertung
libeuda.py Synchroner Abruf und In-Memory-Cache
soc.py Einbindung und gemeinsamer Zustand der Scheduler-Callbacks

[LKuemmel]

Ich habe das VW-EUDA-Modul vorerst aus der Beta genommen. Sobald wir mit diesem PR eine konistente Lösung haben, nehmen wir es gerne ins 2.4.0 Release auf.

[rleidner]

@LKuemmel ,
tested and it basically works.
2 observations:

1. directly after restarting openWB I see 2 errors http 429, disappears after a few minutes
   EDIT: looks like error 429 is returned by the portal when all 30 datasets are downloaded in a very short time.
   I added for a test a time.sleep(.5) after each file and the 429 disappeared. #4161

2. in logging level DEBUG I get large binary data written to soc.log, example:
   2026-10-20 22:08:29,668 - {modules.common.req:53} - {DEBUG:fetch soc_ev2} - Get-Response: PC T]y J {G%WVWZZZE1Zxxxxxxxx_20261020200139.json [o 7 } _a u B N M GX[2d9 x @i j ....

Apart it works pretty well and refactored code is definitely a considerable improvement.

[LKuemmel]

Danke für Dein Feedback!

Punkt 2 habe ich hier gelöst: #4164