Beiträge von ichderarnd

Für meine Reisekostenabrechnung ist die Funktion ausreichend. Bisher stimmen die Daten auch.

Von daher Daumen hoch.

Zitat von ichderarnd

Das weiß ich nicht, ich nutze den ioBroker und dort scheint die Abfrage noch zu funktionieren. Sicher kann ich es sagen, wenn ich mit dem Buzz von meiner Reise zurück bin und den Enyaq wieder bewege.

Unser Enyaq wird vom ioBroker weiter brav ausgelesen. Für den Buzz funktioniert die EDA Schnittstelle manchmal (aber mit viel Verzögerung). Für den eGolf und den ID.4 funktioniert die EDA Schnittstelle im Moment gar nicht. Die JSON Dateien enthalten zwar Daten, aber beim ID.4 weder SoC noch Reichweite. Manchmal ist der SoC enthalten, aber vollkommen falsch.

Warum es beim eGolf nicht geht, habe ich noch nicht nachgesehen. Es ist einfach zeitraubend die ganzen Dateien runterzuladen und zu analysieren. Und nach 7 Stunden sind die Daten ja schon wieder weg, weil nur 30 aufbewahrt werden.

Ich bin im Moment völlig genervt von diesem API Thema. Die 80% Ladegrenze des eGolf lässt ich ohne zeitnahe SoC Kontrolle natürlich auch nicht mehr realisieren.

Das weiß ich nicht, ich nutze den ioBroker und dort scheint die Abfrage noch zu funktionieren. Sicher kann ich es sagen, wenn ich mit dem Buzz von meiner Reise zurück bin und den Enyaq wieder bewege.

Ich habe spaßeshalber mal Gemini Pro nach seiner Meinung zur VW API gefragt und dabei ein Publisher/Subscriber Pattern vorgeschlagen.

Das unten stehende ist dabei herausgekommen. Ich hoffe, jemand bei VW fragt auch mal bei irgendeiner KI nach UND zieht die richtigen Schlüsse.

Selbst wenn die VW Server häufiger mal die Fahrzeuge mit der älteren Software pollen müssen: Mit etwas Nachdenken, kann man auch das optimieren. Ist das Auto offline, braucht es vom VW Server nicht angefragt zu werden. Fährt es oder wird es geladen, dann wird eben regelmäßig abgefragt und bei Änderungen die Information an die API weitergereicht.

Zitat

Dein Ärger ist absolut verständlich und du triffst mit deiner technischen Einschätzung genau ins Schwarze. Dass ein Weltkonzern wie VW von den API-Zugriffen „überrascht“ wird, zeigt, dass hier architektonisch in der Vergangenheit stark auf das falsche Pferd (klassisches, synchrones HTTP-Polling) gesetzt wurde.

Deine Überlegungen zum Publisher-Subscriber-Pattern (Pub/Sub) sind exakt der Weg, wie man so etwas nach aktuellem Stand der Technik (State of the Art) löst. Autos sind im Grunde nichts anderes als große IoT-Geräte (Internet of Things).

Hier ist eine Aufschlüsselung, wie eine sinnvolle Architektur aussehen müsste, ob das für VW machbar ist und wer so etwas bereits erfolgreich umsetzt.

1. Wie sähe eine State-of-the-Art API für Autos aus?

Ein reines REST-API mit Polling (also das ständige Nachfragen der App: „Gibt es was Neues?“) skaliert bei Millionen von Fahrzeugen nicht. Das ist faktisch ein gigantischer, selbstverschuldeter DDoS-Angriff auf die eigenen Server.

Die Lösung ist eine ereignisgesteuerte Architektur (Event-Driven Architecture), primär unter Nutzung des MQTT-Protokolls (Message Queuing Telemetry Transport) in Kombination mit WebSockets oder Webhooks.

Fahrzeug zu Cloud (MQTT): Das Auto baut bei Zündung oder aufgewachtem Steuergerät eine sparsame, dauerhafte Verbindung zur VW-Cloud (dem MQTT-Broker) auf. MQTT ist genau für solche instabilen Mobilfunknetze gemacht.
Zustandsänderungen (Telemetry): Das Auto sendet nur dann Daten (Publish), wenn sich etwas ändert (z.B. Akkustand +1 %, Tür wurde geöffnet). Diese Daten landen auf einem spezifischen "Topic" (z. B. vw/fahrzeuge/vin123/status/tueren).
Cloud zu Kunde (Webhooks / WebSockets): Deine App oder dein Smart-Home-Server (wie Home Assistant) abonniert diese Topics (Subscribe) via WebSockets oder registriert einen Webhook. Sobald das Auto eine Änderung meldet, pusht die Cloud diese Änderung in Echtzeit und ohne ständiges Abfragen an dein System.
Steuerungsbefehle (Commands): Wenn du die Klimaanlage starten willst, sendet deine App eine Nachricht an das Topic vw/fahrzeuge/vin123/commands/klima. Das Auto, das dieses Topic abonniert hat, empfängt den Befehl sofort, führt ihn aus und quittiert den Erfolg über ein Status-Topic.

2. Wäre das für VW machbar?

Absolut. Technologisch ist das keine Raketenwissenschaft, sondern absoluter Standard in der Cloud-Entwicklung (z.B. mit AWS IoT Core oder Azure IoT Hub). Dass VW hier strauchelt, hat meist andere Gründe:

Legacy-Hardware im Auto: Die Steuergeräte in älteren VW-Modellen (teilweise auch in der aktuellen ID-Serie) sind oft nicht für moderne, asynchrone IoT-Kommunikation ausgelegt, sondern hängen an internen CAN-Bussen mit veralteten Gateways.
Compliance & Silos: Die „EU Data Act Schnittstelle“ wurde vermutlich mit heißer Nadel von einer separaten Abteilung gestrickt, nur um der EU-Vorgabe (Data Act) gesetzlich zu genügen, nicht aber, um Entwicklern ein großartiges Erlebnis zu bieten.
Kosten: Jede dauerhaft offene TCP-Verbindung (MQTT) kostet Serverressourcen. Polling kann man bei Überlastung einfach drosseln (Rate Limiting) oder abschalten – das ist für schlechte Backend-Architekturen der einfachste Ausweg.

3. Positivbeispiele aus anderen Branchen (und Automotive)

Du hast Saugroboter und Mähroboter absolut richtig als Beispiel herangezogen.

Smart Home & Robotik:

Saugroboter (Roborock, iRobot) & Mähroboter (Husqvarna): Diese Geräte nutzen intern fast ausschließlich MQTT. Wenn du in der App siehst, wie der Saugroboter in Echtzeit auf der Karte durch dein Wohnzimmer fährt, dann sind das kleine MQTT-Nachrichten, die via Pub/Sub über einen Broker an dein Handy gestreamt werden. Polling wäre hier viel zu langsam.
Tuya (Smart Life): Die größte IoT-Plattform der Welt steuert Millionen von Smart-Home-Geräten über MQTT. Wenn du einen Lichtschalter in der App drückst, geht das Licht in Millisekunden an.
Automobilbranche:

Tesla: Tesla ist hier das Paradebeispiel. Sie bieten die Tesla Fleet API an. Für Telemetriedaten (Geschwindigkeit, GPS, Akkustand) bietet Tesla einen WebSocket-Stream an. Du abonnierst den Stream und bekommst die Daten in Echtzeit gepusht, sobald das Auto wach ist. Kein Polling nötig. Befehle werden über signierte Requests gesendet und das Auto reagiert meist in unter 2 Sekunden.
Rivian / Ford: Auch hier setzen die Hersteller zunehmend auf moderne Streaming-APIs für Entwickler, da sie verstanden haben, dass Polling die Cloud-Rechnung explodieren lässt.
Fazit: Deine Vorstellung einer Pub/Sub-Schnittstelle ist genau das, was die Industrie eigentlich als Best Practice definiert. Dass VW das aktuell nicht anbietet (bzw. nicht stabil hinbekommt), liegt nicht an fehlenden technischen Möglichkeiten auf dem Markt, sondern an internen architektonischen Altlasten und vermutlich daran, dass Software bei traditionellen Autobauern oft noch als "notwendiges Übel" und nicht als Kernkompetenz gesehen wird.

Alles anzeigen

Zitat von Klayer

Workaround für Octopus Energy Nutzer. Der SOC wird in der HA Integration jetzt übermittelt.
Es scheint, dass Octopus sich ganz schnell auf das neue API angepasst hat.

Interessant, ich habe einen Octopus Stromtarif, aber die Fahrzeugintegration nicht aktiviert. Muss ich mir mal näher ansehen, ob das auch mit ioBroker klappt.

Aktuell funktioniert die EU-Data-Act Abfrage gar nicht mehr. Geht - Geht nicht - Geht - Geht nicht …

Inzwischen funktioniert die EU Data Act Geschichte wieder einigermaßen. Der SoC ist auslesbar und sogar der max. Energiegehalt und der aktuelle Energiegehalt der Batterie. Nur die Reichweite teilweise nicht .

Schreibvorgänge sind gar nicht mehr möglich. Also mal eben die Ladegrenze erhöhen oder klimatisieren ist nicht.

Interessant, dass Skoda bzgl. der API hier kulanter agiert als VW. VW hat weder die Bedeutung der Schnittstelle für Privathaushalte noch die eigentlich notwendige Technik verstanden. Dass ein ständiges Abfragen der Werte nicht mehr zeitgemäß ist, hat sich dort noch nicht herumgesprochen.

Ergänzung: beim AC Laden wird das Laden nicht vollständig unterbrochen, nur die Ladeleistung auf ca. 150 Watt reduziert, so dass der Stecker gefahrlos gezogen werden könnte. Der Ladevorgang bleibt somit aktiv und muss an einer öffentlichen Ladesäule nicht neu authorisiert werden wenn nur aufgeschlossen aber der Stecker nicht gezogen wurde.

Zitat von hoaschter

Der 3. Lenkstockhebel für den Tempomat/ACC ist die beste Bedienung die es gibt mMn. Intuitiver geht es eigentlich nicht.

Und ich bin sehr froh, dass es ihn bei Skoda gibt und man dafür keinen Audi-Aufpreis mehr zahlen muss

Ich fahre unseren Enyaq und unseren Buzz abwechselnd mehrmals die Woche über die Autobahn und habe den direkten Vergleich: Auch nach über einem Jahr schaffe ich es nicht, die Tasten des Buzz blind zu bedienen. Es lenkt einfach ständig vom Verkehr ab.

Der Hebel am Enyaq ist genial. In jeder Fahrsituation blind zu bedienen und vor allem immer an derselben Stelle (dreht sich beim Lenken nicht mit )

Zitat von kuse-s

Mich nervt wahnsinnig die Heckklappe. Hatt heute richtig glück im Parkhaus. Ich habe relativ knapp rückwärts an ein anderes Fahrzeug geparkt und bin dann nur am Kofferraum vorbeigegangen und dieses dre@#s Ding geht einfach auf. Nur mit Glück nicht an das andere Fahrzeug gekommen und nach oben gerade noch gebremst sonst wärs an die relativ niedrige Decke.

Absoluter Witz. Software 5.4.

Habs jetzt ausgeschaltet. Super dass man bezahlte Sonderausstattung nicht nutzen kann.

Wir haben dasselbe Problem am ID.Buzz. Software 5.4 und mussten Easy Open abschalten.

Die Klappe schlägt einfach an der Garagenwand oder dem dahinter stehenden Fahrzeug an wenn man hinter dem Buzz langgeht und damit die Öffnung auslöst.