Ich habe den Ölstand jetzt bei einem Kilometerstand von 115.000 prüfen lassen: Es fehlten von den vorgeschriebenen 0,8 Litern 0,2 Liter. Ich habe im Schiebebetrieb leise Getriebegeräusche.
Eigentlich wollte ich das Öl wechseln lassen, aber die Werkstatt meinte, es gibt keine Ablassschraube…
Gefunden 
Es ist auf der 4. Seite des Dashboards (siehe angehängte Datei, die vor dem Import erst mit ZIP entpackt werden muss)
Bitte, das müsste sie sein
Danke, das ist zumindest nicht die, die ich suche. Ich habe noch nicht verstanden, wie ich an das Histogramm für die Zellspannungen komme:
Ich suche weiter.
Alles anzeigenSelbstverständlich gibt es auch bei "Massagesitzen", wie bei vermutlich allen Produktfeatures in der Marktwirtschaft, Unterschiede in der Art der Implementierung, durch diese Unterschiede profilieren sich einzelne Marken und Modelle.
Soweit ich verstehe, gibt es in der VW Group / MEB Plattform derzeit folgende Ausbaustufen, die die einzelnen Marken und Modelle nutzen können1. Grundlegende Massagefunktion: Bewegung der Lenden (durch Zusatzfunktion der Lendenwirbelstütze).
2. ergoActive Sitze: Bewegung des ganzen Rückens (durch weitere Aktuatoren in der Sitzlehne)
3. ergoActive Premium Sitze: Bewegung des ganzen Rückens und des Beckens (durch noch weitere Aktuatoren in der Sitzfläche)
Für den Enyaq bietet Skoda die einfachste Stufe, für den ID.7 bietet VW die beste Stufe.
Diese Entscheidungen man mögen oder nicht, aber wie bei so vielen Themen hier im "was mich nervt..": Skodas Markenprofil sind erschwingliche Familienautos. Auch für den Enyaq müssen sie dafür Kompromisse eingehen, niemand kann Premium-Vollausstattung zum Mittelklassepreis bieten. Skoda erreicht günstige Preise unter anderem durch große Stückzahlen im Komponenten-Einkauf, indem sie nicht alle Optionen einzeln anbieten, sondern in Paketen. Mancher wird dadurch eine Lendenwirbelmassage bekommen, die er gar nicht braucht, andere werden eine Rücken/Beckenmassage vermissen, für die sie gerne extra bezahlt hätten. Wer granular konfigurieren möchte und es sich finanziell leisten kann, für den gibt's in der VW Markenwelt Audi oder Porsche.
Wir haben die Massagesitze im Buzz GTX. Die Massage drückt nur leicht im Lendenbereich in den Rücken, auch auf höchster Stufe. Das sind dann wohl auch die Sitze der einfachsten Stufe. Ist ja eins der teuersten Autos von VW 
Für das Auslesen der einzelnen Zellspannungen mit dem Carscanner empfehle ich das aktuelle Dashboard von Speicher :
https://www.evspeicher.eu/obd-daten-auslesen/
Hat noch jemand das Dashboard als Datei zum Import in den CarScanner?
Der Original-Download von Matthias ist leider nicht mehr verfügbar.
Der ID.3 meines Sohnes hat jetzt zwei Module, die bei 80% SoC ca. 300 mV weniger Spannung haben als die restlichen Zellen.
Die 58er Batterie zeigt beim SoC von 80% aktuell ca. 26.000 Wh Energiegehalt an 
Ich würde es gut finden, wenn die bei mir ohnehin ungenutzten Reku-Taster z.b. für die Soll-Geschwindigkeitsänderung in 1km/h-Schritten umgewidmet werden könnten.....
Woher kommt mir dieser Vorschlag bekannt vor?
Für meine Reisekostenabrechnung ist die Funktion ausreichend. Bisher stimmen die Daten auch.
Von daher Daumen hoch.
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.
ZitatAlles anzeigenDein Ä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.
