VW sperrt das öffentliche API und damit evcc, Home Assistant etc. aus

Zitat von renndachserl

Ironischerweise war oder ist das EU Data Act Portal erstmal überlastet, nach dem die Open Source Community das als mögliche Alternative implementiert hat.

Das hängt bei mir seit gestern.

Niels

Hier ist die aktuelle Beschreibung von evcc: https://docs.evcc.io/de/vehicl…kswagen-eu-data-act/#_top

Ich konnte nun die Anmeldung durchführen, finde aber auf der Seite nicht, wo ich die Datenlieferung alle 15 Minuten aktivieren kann. Ist der Punkt wegen der großen Nachfrage wieder verschwunden, oder liegt es daran, dass ich das gerade für unseren E-Golf versuche und die Karre zu alt ist? Und das ist wohl auch noch kostenpflichtig...

Niels

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.

Zitat von renndachserl

Der Shitstorm war wohl hilfreich:

603338503-e8631e66-8cf1-4fb8-b069-95edda7e5d70.png

Das ist mMn ein sehr löbliches Verhalten von Skoda, anders als die Konzernmutter den Rollout erst mal zurückzuhalten, um mit OpenSource-Anbietern (wie auch EVCC) zunächst einmal eine Lösung zu finden. Wir sind jetzt erst aus dem Urlaub zurück - ich hatte mich schon gewundert, dass EVCC problemlos läuft und die Ladung steuert. Dachte zunächst noch an die alte-Token-Erklärung, aber trotz Restarts von EVCC lief alles wie gehabt. Die Info von Skoda dürfte die Erklärung liefern.

Was ich nicht verstehe: Selbst wenn Skoda die ursprüngliche API deaktiviert hätte, weswegen kooperiert EVCC dann nicht z. B. mit Enode? Die haben eine Partnerschaft mit VW - viele Apps nutzen Enode (so z. B. auch ABRP) zum Auslesen der Live-Daten. Selbst wenn die Nutzung dann für den Einzelnen Kosten mit sich bringen würde, ließe sich dies doch mit einem Sponsor-Token (wie er bei EVCC auch für die Nutzung mancher Wallboxen üblich ist) finanzieren? Die 3 EUR im Monat wären mir das notfalls wert.

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

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.

Hatte eben eine 403 Meldung nun geht es aber scheinbar trotzdem, bin gespannt wie das wird. Wäre ja wirklich kacke der VW Gruppe und für mich wäre das ein Grund beim nächsten Auto ein Fahrzeug der Gruppe nicht in Betracht zu ziehen, auch wenn EVCC ja eigentlich auch ohne geht, dann halt nur nicht mit KM und so

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.

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 ichderarnd

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

Was ich aktuell an hiesiger Debatte nicht verstehe: Skoda hat doch die 'Notbremse' gezogen und den Rollout der API-Abschaltung für externe Dienste pausiert. Zumindest bei mir läuft EVCC wie gewohnt. Ist das in einer HA-Umgebung anders geregelt?