Beiträge von CoMa

    Diese Töne sind vor allem für Beifahrer nervig, da sie ja nicht wissen, dass und warum ich Knöpfe drücke. Sie hören nur das unmotivierte Gepiepse.

    Bei meinem 1st Max mit zuletzt SW 3.0 war das auch so, dass ich das nach jedem Einschalten wieder neu abstellen musste. Ich glaube, vor SW 2.4 ging's noch richtig. Jetzt mit meinem neuen ID.3 Bj 2023 mit SW 3.5 bleibt es abgestellt.

    Update 21.02.2024: Heute hat [webApp] überhaupt keinen "Status" mehr, ohne dass ich etwas in der Richtung Richtung unternommen hätte. Es ist also wohl ein internes Objekt ohne Bedeutung. Weiterhin ohne Erklärung warum bei mir keine Batterietemperatur übertragen wird.

    Ein Punkt fällt mir beim Betrachten der Antworten des Servers auf : Es gibt bei mir ein Objekt "capabilities/webApp", das einen Fehlerstatus anzeigt. Mit weconnect-cli z.B.:

    % weconnect-cli get / |grep webApp

    [webApp] Status: MISSING_LICENSE disabling: False (expires 2053-10-26T23:59:59+00:00)

    Bei meinem alten ID.3 1st Max unter 3.0 war der Status: PLAY_PROTECTION (und das Verfallsdatum in 60 statt 30 Jahren).

    Was ist das, und hat das irgendeine Bedeutung? Die Data-Logger ignorieren dieses Objekt.

    Ja, aber die möglichen domains, die von `ls` aufgelistet werden, sind die, die im Programm vordefiniert sind. Ich glaubte auch anfangs, dass das `ls` irgendwie auf dem Server ausgeführt wird und wirklich zeigt, was dort maximal vorhanden ist. Dem ist aber nicht so. Wenn es beispielsweise ein domain 'batterydata' geben würde, ohne dass stein das weiß und in seinen Code aufgenommen hätte, würde es bei `ls` nicht auftauchen.


    Ergänzung: Umgekehrt taucht aber ein Attribut "temperatureBatteryStatus" bei `ls` in measurements auch nicht auf, obwohl es im Programm definiert ist, aber bei mir nicht vom Auto an den Server geschickt wird.:

    coma@mail.com@weconnect-sh:/vehicles/WVWZZZE1XPPxxxxxxdomains/measurements$ls

    ..

    rangeStatus

    odometerStatus

    fuelLevelStatus

    Die hier: https://github.com/mitch-dc/vo…ect_id?tab=readme-ov-file ?

    Die benutzt auch meine Bibliothek.

    Ich versuche gerade zu verstehen, wie das funktioniert, genauer in wie weit die genaue Datenstruktur auf dem Server bekannt sein muss, bevor man die Werte abfragen kann, bzw. wie weit der Server selbst sagt, welche Informationen zur Verfügung stehen.


    Zum einen bin ich mir jetzt sicher, dass bei mir diese Temperaturwerte nicht im domain 'measurements' vorhanden sind, auch nicht unter einem anderen Namen. Die Rohdaten vom Server sieht man hier (Teil des Outputs von

    `weconnect-cli -v -v -v --selective measurements get /vehicles/$VIN/domains/measurements`

    nach einer kleinen Modifikation von elements/vehicle.py):

    2024-02-13T10:34:54+0100:DEBUG:https://emea.bff.cariad.digital:443 "GET /vehicle/v1/vehicles/WVWZZZE1XPPxxxxxx/selectivestatus?jobs=measurements HTTP/1.1" 207 382

    2024-02-13T10:34:54+0100:DEBUG:Data fetched: {'measurements': {'rangeStatus': {'value': {'carCapturedTimestamp': '2024-02-12T16:28:46.666Z', 'electricRange': 305, 'totalRange_km': 305}}, 'odometerStatus': {'value': {'carCapturedTimestamp': '2024-02-12T16:28:47.656Z', 'odometer': 2434}}, 'fuelLevelStatus': {'value': {'carCapturedTimestamp': '2024-02-12T13:22:57.932Z', 'currentSOC_pct': 72, 'primaryEngineType': 'electric', 'carType': 'electric'}}}}


    Andererseits habe ich nicht gefunden, wie man dem Server entlocken kann, welche "domains" er kennt. Die Temperatur könnte bei mir ja in einem anderen solchen domain versteckt sein. Er listet brav die "capabilities" auf, aber wie man weiter unten im Daten-Spaghettihaufen was finden kann ohne zu wissen, wo wo man suchen muss, ist mir noch nicht klar. Beispielsweise führt 'weconnect-cli --selective all' zu nichts. Wo findet man dieses Insiderwissen?


    Immerhin habe ich verstanden, woher die oben erwähnten Warnings "Unknown attribute" herkommen, aber das hat leider nichts mit der Akku-Temperatur zu tun.

    haben diejenigen bei denen es nicht klappt in den Privatsphäreneinstellungen den Punkt "Temperaturhinweise" aktiviert oder nicht?

    Ich habe das normalerweise aktiviert, habe es aber auch mal abgeschaltet, um zu sehen, ob sich was ändert. Negativ.


    2024-02-12T15:46:38+0000:WARNING:/vehicles/VIN/domains/automation/climatisationTimer/timers/1/singleTimer: Unknown attribute targetDateTime with value 1999-12-31T23:00:00Z


    etc.

    Diese sehe ich auch. Diese Meldungen ändern sich im Detail, bleiben aber bestehen, wenn man im Menü Abfahrtszeiten was ändert. Ich habe das noch nie benutzt, habe auch keine Ladeorte definiert, da ich das nicht brauche (Rentner mit zu unregelmäßigem Tagesablauf :) ) . Sehe aber auch nicht, was das mit der Anzeige der Akku-Temperatur zu tun haben könnte.

    CoMa - hast du deinen ID in Frankreich bestellt? Vielleicht liegt das irgendwie daran, dass er für einen anderen Markt gebaut wurde?.

    Das ist durchaus denkbar, wenn auch schwer verständlich. Es geht ja nicht um Hardware, und selbst eine Übersetzung ist unnötig; auf diesem Niveau ist ja eh alles englisch. Ansonsten bin ich schon daran gewöhnt, dass man hier weniger Auswahl bei der Ausstattung hat und dafür alles deutlich teurer ist. :(

    Ich bin in der App und auf myvolkswagen nochmals alles sorgfältig durchgegangen auf der Suche nach einer evtl. relevanten Zustimmung, habe aber nichts gesehen. Alle irgend möglichen Zustimmungen sind aber sowieso schon erteilt. Ich habe extra alles nochmal auf deutsch angeschaut (normalerweise lasse ich es auf französisch), wo der Seitenaufbau manchmal etwas anders ist und mindestens in einem Fall (Digitales Bordbuch, gibt's nicht in der französischen Garage) eine zusätzliche Information existiert. Bisher keine Erklärung gefunden.

    Eben. Ich kann ja noch halbwegs verstehen (obwohl es mich ärgert), dass sie bei meinem ID.3, der bei der Bestellung 02/2023 das vollausgestattete Top-Modell war, keine hinteren Lautsprecher eingebaut haben: Da haben sie sicher einige € gespart. Aber ein paar Bytes weniger Daten in die Cloud zu schicken spart doch nichts, oder?

    % weconnect-cli --version

    weconnect-cli 0.38.2 (using WeConnect-python 0.59.5)


    Ich glaube, das ist die neueste Version. Außerdem sollte 'weconnect-cli get' eigentlich einfach lesen, was da ist, ohne Vorkenntnisse zu haben; die Version sollte daher keine große Rolle spielen. Das ist anders bei den nachgeschalteten Teilen der Graphikmodule, die die Daten aufbereiten und daher schon vorher wissen müssen, welche Variablen zu erwarten sind. Ich lasse mich aber gerne korrigieren.