Beiträge von Gernot

Zitat von M_a-r_k-u_s

Wenn du mir eine Exportdatei mit einigen Datensätzen zur Verfügung stellen kannst, kann ich anbieten das mal in Claude Fable reinzustecken. Bin mir recht sicher, dass der dir das genau aufschlüsseln kann. Allerdings habe ich nur noch bis morgen die kostenlose Testversion, müsstest dich also beeilen. csv, json oder Markdown als Export wäre gut.

Vielen Dank. Habe ich Dir geschickt.
Allerdings glaube ich nicht, dass Claude alle Datenpunkte aufdröseln kann. Etwas, dass im ganzen Internet nirgends steht, weil VW nie eine brauchbare Aufschlüsselung geliefert hat, kann auch Claude nicht wissen. Einige Datenpunkte sind aufgrund des Feldnamens selbsterklärend (u.a. settings.target_soc, battery_state_report.soc, mileage.value, ...), viele halt nicht.

Zitat von SK73

Ich habe das, wegen der niedrigen Reichweite bei den heißen Temperaturen, mal kontrollieren wollen.

Wenn VW in Sachen Software nicht so megaschlecht wäre, könnte man das ggf. genauer aufdröseln. Die Daten, die man aus dem EU Data Act Portal bekommt, enthalten u.a. folgende Datenpunkte

additional_consumptions.interior_climatization_consumption: 2.6

additional_consumptions.residual_consumption: 1.5999999

Man weiß halt nicht, wie man die Daten deuten soll (Letzter Tag, pro 100 km, für letzte Fahrt, ...?). Das Data Dictionary von VW ist komplett nutzlos. Laut Google KI soll der zweite Wert den Standby-Verbrauch pro 100 km angeben, den Vampire Drain. Einen StandBy-Verbrauch als Wert pro 100 km anzugeben, erscheint mir aber komplett unlogisch.

Es gibt noch viele Datenpunkte mehr, die möglicherweise auch etwas zum State of Health und anderen Parametern aussagen, aber man kann das alles nicht deuten, weil VW nicht mal ein Mindestmaß an brauchbarer Doku liefert.

Zitat von fRank1e

Das soll doch ab ca 2029 dann passieren. Wenn die neue Software kommt.

Wie die App GUI oder die Fahrzeug-Software aussieht, ist hier irrelevant. Die Routenberechnung erfolgt serverseitig, in dem die App u.a. Requests an den Host routing.cariad.digital absetzt. Die dort erfolgende Routenberechnung kann man ändern/verbessern, ohne irgendwas an der App ändern zu müssen.

Hier funktioniert es mit Android 15 (auf einem Nothing Phone) und App Version 2.19.1 (20260619). Das ist die neueste Version im Play Store.

Wie oben beschrieben werden wieder Ladestopps geplant. Aber sinnvoll ist die Lade-Planung nicht. Das ist um so trauriger, als das VW ja mit 5 Mrd. bei Rivian eingestiegen ist und ein Software-Joint-Venture mit Rivian gegründet hat. Rivian gehört A-Better-Routeplanner. Wenn VW nichts gebacken bekommt, sollten sie die Technologie bei Rivian abgreifen können.

Hast recht, VW-Fahrzeuge waren diesbezüglich ja ein Sonderfall. Daran hatte ich nicht gedacht. Und das AutoCharge-Thema betrifft nicht nur Fastned, die in Deutschland ja noch kaum eine Rolle spielen, sondern auch Marktführer EnBW.

Habe mir die Fastned-App mal installiert. Die möchte gern die Berechtigung "Fahrzeuginformationen" (via Android Auto) haben, aber ich nehme an, dass Laden auch ohne diese Berechtigung funktioniert. Berechtigung die IMEI zu lesen, hat die App (auf aktuellen Androids) auch nicht. Das eröffnet dann vermutlich einiges an Missbrauchspotenzial für die Fastned-Aktion. Letztlich braucht man die Mobilfunknummer nur, um eine einzige SMS bei der Kontoerstellung zu empfangen. Es gibt ja online genug Anbieter, wo man für ein paar Cent SMS an virtuelle Mobilfunknummern empfangen kann.

Bei mir funktioniert die Planung von Langstrecken inkl. Ladestopps in der App jetzt wieder - also in dem Sinne, dass Ladestopps grundsätzlich eingeplant werden. Allerdings sind die geplanten Routen schlicht dumm. Ich habe testweise angegeben, dass ich ausschließlich bei EWE laden möchte. Alle großen anderen Ladenetzwerke habe ich explizit ausgeschlossen (Tesla, EnBW, Ionity, ...).

Für eine 800km lange Strecke plant die App (ausgehend von aktuell 50% Ladestand) 3 Ladestopps:

1. Ladestopp EWE von 16% auf 63%
2. Ladestopp Orlen von 11% auf 87%

3. Ladestopp EWE von 10 auf 58%

Beim 2. Ladestopp bei Orlen käme 41 km weiter an der Route die nächste EWE-Ladesäule. Würde beim 1. Ladestopp auf 73% statt 63% geladen, käme man da auch locker hin. Die Planung mit Orlen ergibt für mich dann grundsätzlich keinen Sinn.

Und wenn die Software aus unerfindlichen Gründen den 2. Ladestopp bei Orlen für nötig hält, wäre es trotzdem sinnvoll, beim ersten Ladestopp bei EWE, wo ich explizit laden will, mehr zu laden. Die Software plant jetzt so, dass da, wo ich laden will (EWE) nur 47% nachgeladen werden und da wo ich nicht laden will, soll ich 76% nachladen. Es wäre dann schlicht logisch, beim ersten Ladestopp auf 87 oder 90% zu laden und beim 2. Ladestopp statt von 11% auf 87% eben nur von 38 auf 87%. Das ist so einfach dumm.

Zitat von Coldfire

Mit einer zweiten E-Mail und Telefonnumer kann man sich da auch nochmal registrieren

Hast Du auch ausprobiert, ob sich das dann mit dem selben Fahrzeug einlösen lässt? Wenn der Typ2-Stecker ins Auto gestöpselt wird, schickt das Fahrzeug im zweiten Kommunikationsschritt eine eindeutige Fahrzeug-ID (EVCCID) an die Ladesäule. Darüber könnte Fastned theoretisch sicherstellen, dass der Gutschein pro Auto nur einmal verwendet werden kann. Möglicherweise war das Fastned aber zu aufwändig zu programmieren und die Gutscheine sind wirklich nur an Telefonnummer und/oder IMEI gebunden.

Nur zur Sicherheit: Es ist C.Thomsen mit 6 Standorten in Schleswig-Holstein und Hamburg gemeint?

Zitat von Harry1973

Kann ich bestätigen

Mit dem neuesten Update hat sich das Design der Buttons zum Ver- und Entriegeln deutlich geändert. Sie funktionieren hier aber weiter nicht. Und weiter gibt es keine Fehlermeldung. Es passiert einfach nichts. Connectivity ist gegeben. Wenn ich das Ladeziel ändere, dann funktioniert das.

Zitat von Leo

CuTa weil ein Webzugang potenziell weniger sicher ist

Definitiv nicht. All die Zugriffe auf APIs erfolgen heute über das "Web", d.h. auf Port 443 wo ein HTTP-Server lauscht. Es macht in Sachen Sicherheit keinen Unterschied, ob die Anfrage aus einem Browser oder aus einer App kommt. Viele Websites sind heute als Single Page Application umgesetzt, die auf Javascript-Framework wie React, angular, VueJS, ... basieren und auf exakt die gleichen Schnittstellen zugreifen, wie die Apps der Anbieter. In vielen Fällen sind die "Apps" heute auch lediglich Wrapper für eine Website.