Beiträge von rhizom

  • ID.Software 3.7 : News, Informationen und konkrete Fakten

    Noch eine Erfolgsmeldung: Bei mir hat es auch geklappt, und 'ich' bin jetzt endlich auch ein 3.7er.

    Er hat meine Displaykonfiguration und meine Farben verloren, das Bordbuch wurde eine Zeitlang geladen, und der Shop bekam noch ein Update. Der Shop funktioniert irgendwie noch nicht, auch der erwähnte Restart (Motor aus, Aussteigen, Absperren, wieder rein & an) half leider nicht.

    Ich muss wohl auch WeCharge & Co. neu installieren. Naja, werde morgen Früh sehen ob sich das gelöst haben wird.


    Zum Glück gibt es das Forum hier - sonst hätte mich das vollkommen tote Auto während des Updates wirklich erschreckt: Kein Ladebalken im Display, keine Reaktion auf den Schlüssel: einfach nur ein komatöses, verschlossenes Auto. Aber dank der Infos hier hatte ich ja nichts Wichtiges im Kofferraum liegen gelassen :)


    Frohes Updaten allerseits

  • Eigene Visualisierung von Daten vom Auto

    Hallo Hardy1 ,


    bei mir stehen diese Fehler auch im Log, sie lösen bei mir aber keinen Abbruch der Locations-Aufzeichnung beim Fahren oder Laden aus:

    Code
    2024-10-18T20:26:29+0000:WARNING:connectionpool:Retrying (BlacklistRetry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'RemoteDisconnected('Remote end closed connection without response')': /oidc/v1/oauth/sso?clientId=<brrrZZZ>@apps_vw-dilab_com&relayState=<lieberMalErsetzt>&userId=<werWeißSchonObManDiesenHashZurückrechnenKann>&HMAC=<oderAuchDiesen>

    Da schlägt irgend ein SingleSignOn (SSO-)Request fehl - ich kenne mich mit OAUTH leider nicht aus. Es kann leicht sein, dass VW da etwas an der Authentifizierung verändert hat, und das nicht dokumentiert. Wir warten ja alle sicher auch gespannt auf die OTA SW 3.7 - VW ist da ja auch weniger gesprächig als so mancher Geheimdienst.


    Interessanterweise ist die o.g. Meldung die letzte bis jetzt. Seit heute, ca. Mitternacht, kam der Fehler also nicht mehr.
    ~1,5h später scheint VWsFriend sich neue Tokens zu holen:

    Code
    2024-10-18T21:30:26+0000:INFO:vwsfriend_base:Updating data from WeConnect
2024-10-18T21:30:26+0000:INFO:openid_session:Token expired
2024-10-18T21:30:26+0000:INFO:we_connect_session:Refreshing tokens

  • Eigene Visualisierung von Daten vom Auto

    Danke, @foo , für Monit. Habe schon gesehen, dass es das auch als Container gibt. Aber ggf. lasse ich das auch direkt auf meinem Raspi laufen. Werde es mir ansehen.


    Danke, stein, auch für Deine Rückmeldung. Alle meine Log-Fehler wurden auch mit einem SW 3.2 ID.4 'erfahren'. Das liegt also nicht an einem neueren SW-Stand (leider...). Mein Auto steht ja auch vollständig hier in den Metadaten. Evtl. verändert VW einfach seine API unabhängig vom SW-Stand, aber da bist Du eindeutig der Experte.


    Btw. ich könnte durchaus programmieren - wenngleich meine Erfahrung hauptsächlich Java ist. Ein bisschen Zeit, und noch mehr Motivation, hätte ich auch. Aber wie das immer so ist: Erstmal Codebasis und -Architektur kennenlernen, Verfolgte BestPractices, Unit-Tests?, Rollout und Aufbau & Prinzipien der DB. Dafür hat es bei mir bisher noch nicht gereicht.

    @all : Gibt es hier noch mehr von meiner Sorte? Wäre mal eine Telko mit stein sinnvoll, in der man bei sich mal das Dev-Setup einrichtet, und vllt. mal anfängt, das Wesentlichste zu besprechen. Weil den Changesets auf Git zufolge sind viele der unbekannten Status einfach in Konstantenlisten einzutragen - das ließe sich ja auch auf mehrere Schultern verteilen...

    stein, zu Deiner Aussage, alles was in den Logs wäre, stünde auch in der DB:
    Wenn ich /database/trips/list aufrufe, ist bei mir der letzte Trip von 2024-10-08 17:24:41+00:00.


    Du hast leider recht: Ich habe mich getäuscht. Lt. grep -i trip vwsfriend.log wurden seitdem keine Trips mehr geloggt (gefahren bin ich freilich).

  • Eigene Visualisierung von Daten vom Auto

    Hallo stein und alle anderen,


    seit 08.10., abends speichert VWsFriend bei mir keine Trips mehr. Auch ein Restart des Containers half nicht (das half in der Vergangenheit, wenn sich VWsFriend wg. eines Python-Fehlers aufhängte, zwar noch per Browser aufrufbar blieb, aber nichts mehr speicherte, was von der VW-API kommt).


    Ich habe mich im Log mal auf die Fehlersuche begeben, und neben einem Python-Stacktrace noch einige unbekannte Status gefunden. Da dort immer 'report this as a bug' steht, habe ich alles unter https://github.com/tillsteinbach/VWsFriend/issues eingetragen - ich hoffe, das ist so zweckdienlich.


    Nun noch eine allgemeine Frage:

    Bei mir ist die Datenbank aufgrund der diversen Fehler inwzischen mehr als lückenhaft. Soweit ich sehe, stehen aber sämtliche Informationen zur retrospektiven Rekonstruktion im Log. Wäre eine Shell- oder Web-GUI-Funktion zum Einspielen v. Logs nach einem Absturz sehr aufwendig zu implementieren?


    Ich will mich um Gottes Willen nicht über die hervorragende Arbeit hier beschweren - ich wünschte, ich könnte mehr beitragen. Aber durch die vielen Erfassungslücken komme ich gerade gefühlt etwas an die Grenze der Sinnhaftigkeit dieser Lösung. Anders herum formuliert: Ich wäre gerade sehr offen für Hinweise, wie Ihr einen dauerhaft stabilen Betrieb gewährleistet (d.h. vor allem eine lückenlose Speicherung der Daten).


    Bei mir habe ich z.B. einen nächtlichen Cronjob eingerichtet, der das hier macht:

    Bash
    #!/bin/bash

/usr/bin/docker restart vwsfriend_vwsfriend_1

    und


    Code
    usr@srv:~/vwsfriend $ crontab -l
...
5 4 * * * /HOME/vwsfriend/restartVWsFriend.sh

    Reicht das im Falle eines Absturzes, oder müssen alle drei Container restarted werden? Oder einfach gleich der ganze Docker-Service?

  • Ist Akku manuell vorheizen möglich mit SW 3.X ?

    Hallo zusammen,


    ein paar Fragen zur kalten Jahreszeit. Mein ID.4 ist 23er Baujahr, aber Pre-Facelift. Also definitiv ohne Akku-Vorkonditionierung, aber hardwareseitig durchaus mit der Möglichkeit, den Akku zu heizen wenn ich richtig informiert bin.

    Ich muss im Freien parken und habe keine Wallbox: Kann ich mich darauf verlassen, dass an den zu erwartenden 2 Tagen mit -10°C die Batterie auf einem Temperaturniveau gehalten wird, dass ich ohne dauerhafte Schädigung fahren kann?

    Und irgendwann muss ich dann auch laden. Ist der einzige Weg, jegliche Ladevorgänge bei unter 0°C zu vermeiden? (Irgendwo stand mal, dass z.B. Tesla bei einem einzigen Laden unter -5°C die Batteriegarantie aufkündigt... das kann doch nicht sein?)
    Habt Ihr da Best Practices, Erfahrungen, Informationen?

  • Eigene Visualisierung von Daten vom Auto

    stein , ich hätte einen neuen Bug (soll ich den als Issue direkt in Github anlegen?):


    Bei mir kam am Freitag die Warnung, dass meine Schlüsselbatterie leer sei und getauscht werden müsse. Nicht nur, wie bei dem climatisationOutside-Thema kam eine Fehlermeldung, sondern VWsFriend erfasste ab da überhaupt keine Daten mehr: Keine Trips, keine Ladevorgänge etc.


    Lt. Log hat ihm wohl die Farbe weiß zum 'Warning Light' nicht gepasst:

    Ich habe mal das gesamte Log seitdem hier mit angefügt. Man sieht: Es kam absolut nichts an, obwohl ich eine Menge gefahren bin & 2x geladen habe. VWsFriend konnte per Web aber jederzeit aufgerufen werden, nur Daten kamen keine mehr an.


    Nach einem Restart aller vier Container via Portainer (vwsfriend_grafana_1, vwsfriend_postgresdb_1, vwsfriend_vwsfriend_1, vwsfriend_watchtower_1) erscheint zumindest wieder der korrekte SOC in der Oberfläche. Gefahren bin ich jetzt noch nicht.

    Das Log nach dem Restart sieht aber so aus als würde VWsFriend jetzt wieder Daten abholen & bekommen.

  • Eigene Visualisierung von Daten vom Auto

    Naja, die meisten Computersysteme werfen Fehlermeldungen aller Art - und viele davon. Es ist trotzdem immer einen Versuch wert, erstmal die Anwendung aufzurufen. Auch kann eine Fehlermeldung kommen, die Anwendung trotzdem korrekt laufen, und der Zugriff wird z.B. von einer lokalen Firewall blockiert. Da lasse ich gerne mal einen nmap laufen, um die Ports zu prüfen. Oder bei Browsermeldungen einen curl -I auf die URL (auch localhost vs. Zugriff v. außen vergleichen).

    stein , ich weiß, Du hattest nach SW >3.x gefragt, und ich habe noch v.3.2. Aber bei mir kommt dieser Fehler climatisationTemperatureOutside-Fehler jetzt auch - und er kommt lt. meinen Logs exakt seit 2024-08-29T08:30:12+0000 (mein aktuelles Log geht zurück bis zum 19.07.)

    Code
     -1 }">2024-09-03T10:00:08+0000:WARNING:vehicle:/vehicles/<FIN>: Unknown attribute climatisationTemperatureOutside with value {'error': {'message': 'Bad Gateway', 'errorTimeStamp': '2024-09-03T10:00:08Z', 'info': 'Something went wrong. Please try to re-login. If the problem persists, please contact our support.', 'code': 4003, 'group': 3, 'retry': True}} in domain climatisation

    Passend zum zuvor Geschriebenen: Ich kann keinerlei negative Auswirkungen auf VWsFriends korrektes Funktionieren feststellen. Es wäre aber spannend zu erfahren, was so ein 'Unknown attribute' für Folgen haben kann/hat.


    Ich habe mal eine generelle Abfrage nach unbekannten Attributen über das Log laufen lassen:

    Code
    usr@raspi:/var/log/vwsfriend $ grep 'Unknown attribute' vwsfriend.log | cut -d ' ' -f8 | sort |uniq -c | sort -rn
   1451 climatisationTemperatureOutside
    377 chargingScenario
     20 temperatureOutsideStatus

  • weconnect-cli API (Python, Achtung: stark computerlastiges Thema)

    Hallo stein und alle,


    Ich habe jetzt mal ein allererstes, sehr einfaches CampMode-Skript zur Verwendung mit Cron erstellt. Das kann ich mit

    Code
    40,10 22,23,0,1,2,3,4,5,6 * * * /<Pfad>/climatisationStarter.sh >>/var/log/vwsfriend/climatisationStarter.log >>/var/log/vwsfriend/climatisationStarter.log 2>>/var/log/vwsfriend/climatisationStarter.log

    alle halbe Stunde aufrufen. Das Skript macht dann folgendes:


    Meine Erfahrungen damit:

    1. Die API sperrt einen sehr schnell aus, wenn zu viele Requests hintereinander kommen (liefert dann Auth-Errors, aber v.a. 403er), daher die vielen Sleeps
    2. Wenn nach 30min noch 2min ClimatisationTime übrig sind, wird mit dem Startbefehl nicht wieder auf 30min hochgesetzt. Also stoppe ich erst, warte, und starte dann neu
    3. Wenn damit die Klimaanlage aktiviert wurde, kann man sie nicht mehr über die VW-App stoppen. Wer das aktiviert, und kein Zauberlehrling sein möchte, sollte auch den Stop-Befehl per Shell beherrschen (vgl. https://github.com/tillsteinbach/WeConnect-cli )
      Ob das Fehlverhalten der App nach dem Skript auch an 1. liegt, vermag ich nicht zu sagen, entsprechend gewartet habe ich aber: erfolglos.

    Wie sind Eure Erfahrungen mit der Shell-Steuerung Eures ID? Ich wette, da gibt es noch bessere Skripte und Best Practices. Teilt sie doch bitte mal.

  • Eigene Visualisierung von Daten vom Auto

    Hallo zusammen,


    ich kann leider auch nur beisteuern, dass VWsFriend bei mir auf einem Raspi 5 läuft (nicht 4). Ich habe die Installation auch nach https://github.com/tillsteinba…Friend?tab=readme-ov-file bzw. dem Verlinkten Artikel zu Docker gemacht.

    Vllt. aufgrund des neueren Raspi ist mir nur aufgefallen, dass keiner der 'Known Issues' bei mir aufgetreten ist.


    Übrigens funktioniert bei mir seit einigen Wochen die Übermittlung der Koordinaten bei Trips & Charges wieder korrekt. Warum das einen Aussetzer hatte, kann ich bis heute nicht sagen. Aber Hauptsache läuft.

  • Eigene Visualisierung von Daten vom Auto

    Danke stein für das Update. Ich fürchte, ich verstehe etwas von Deiner Familiensituation; nimm' Dir soviel Zeit, wie Du brauchst.

    Habe das Update gleich eingespielt. Zuletzt hatte sich die API scheinbar total überschlagen: Nachdem ich am 31.07. einen Trip mit Koordinaten aufgezeichnet bekam, wurde überhaupt nichts mehr aufgezeichnet: also gar keine Trips. Ein Ladevorgang heute wurde hingegen registriert - ohne Koordinaten, also muss ich wieder die Ladesäule händisch nachtragen... Aber lt. Trips hat sich mein Auto dort heute über 100km einfache Strecke 'hingebeamt': Es ist keine Hin- oder Rückfahrt aufgezeichnet.

    Nach dem Update habe ich diese Log-Meldungen zu den Positionsdaten bekommen (die eigentlich auf ein korrektes Funktionieren hindeuten):

    Code
    2024-08-02T17:05:25+0000:INFO:agent_connector:Found matching vehicle for vin WVGZZZ... in database

2024-08-02T17:05:25+0000:WARNING:state_agent:Vehicle WVGZZZ... is still online in database. Looks like the session was closed when the vehicle was still online!

2024-08-02T17:05:25+0000:INFO:trip_agent:Vehicle WVGZZZ... provides a parkingPosition and thus allows to record trips based on position

2024-08-02T17:05:25+0000:INFO:warning_light_agent:Vehicle WVGZZZ... has still 0 warning lights on in the database.

2024-08-02T17:05:25+0000:INFO:abrp_agent:Reading abrp tokenfile /config/WVGZZZ...-ABRP.token

    Morgen fahre ich wieder - bin schon gespannt, ob mit Scotty's Hilfe, oder doch eher bodenständiger...

  • Eigene Visualisierung von Daten vom Auto

    Zitat von stein

    Meine einzige Vermutung war dass VW in der API irgendwas umbenannt hat und deswegen nichts mehr kommt. Aber dann würde es eigentlich auch bei allen nicht mehr gehen.


    Dumme Frage, aber du hast nicht diesen Parameter drin oder: --privacy no-locations

    Hallo stein ,


    nein, das habe ich nicht gesetzt. Lt. Portainer sind meine ADDITIONAL_PARAMETERS:

    ADDITIONAL_PARAMETERS --with-database --with-abrp -vv

    Und mein ABRP bekommt auch korrekte Positionsdaten.


    Das einzige was mir mal passiert ist, dass mein Rapi abgestürzt ist. Danach kam alles wieder hoch - und ich meine, das war auch eher vor dem Positionsausfall, d.h. ich meine danach wurden noch Positionen aufgezeichnet.


    Kann ich irgendwie die Konsistenz meiner Datenbank sicherstellen?

    stein : Meine letzte Fahrt steht jetzt wieder mit Positionsdaten da (hatte ich bei meinem Post gerade noch nicht gesehen).

    Ich habe heute Morgen auch im Auto nochmal alle meine Privacy-Einstellungen gecheckt; irgendwo hier stand ja, man solle auch mal die Einwilligungen deaktivieren und wieder aktivieren - das habe ich gemacht. Allerdings wurde die direkt darauf folgende Fahrt noch ohne Positionen aufgezeichnet, mein Ladevorgang heute hatte die Koordinaten der nächtlichen Parkposition (was deutlich leichter zu korrigieren war, als den Pin erstmal von südl. Westafrika nach Mittelreuropa ziehen zu müssen...).

    Und jetzt die Heimfahrt hat er offenbar korrekt mit Koordinaten aufgezeichnet.


    Also das 'Internal'-Dashboard zu den Server-Antwortzeiten bei VW finde ich schon seit längerem interessant. Der letzte Totalausfall war am ersten bayerischen Ferienwochenende: Es dürfen einfach nicht zu viele IDs gleichzeitig fahren...


    Fazit meiner ganzen Bemerkungen, auch nach Hardy 's Beobachtungen: Könnte das alles an der VW-API liefern, die halt macht was sie will?

  • Eigene Visualisierung von Daten vom Auto

    Zitat von stein

    Hmmm, kommen im log Fehler?

    Hallo stein ,


    ich kann im Log nichts finden. Habe in Portainer die Logs des Containers vwsfriend_vwsfriend_1 geprüft (die sind jetzt offenbar nur von heute). Auf der Shell habe ich StdOut & StdErr in eigene Dateien umgeleitet, dort sind aber keine Timestamps enthalten.
    Die einzigen Fehler, die ich sehen kann, sind im StdErr-Log (aber ob die zeitlich zu den fehlenden Koordinaten passen, weiß ich nicht). Und wenn die Verbindung grundsätzlich nicht möglich wäre, bekäme ich nach meinem Verständnis auch gar keine Daten, es fehlen aber nur die Koordinaten - der Rest kommt korrekt an.

  • Eigene Visualisierung von Daten vom Auto

    Hallo zusammen,


    VWsFriend 0.24.4 zeigt bei mir seit 29.07. auch keine Koordinaten mehr bei den Trips an. Auch Ladungen erscheinen ohne Geokoordinaten. Das Tool funktioniert eigentlich hervorragend und macht Spaß. Kann mir irgendjemand einen Tip geben, was sich geändert haben könnte?
    Ich habe online bereits meine Einwilligungen nochmals geprüft, und die VW-App zeigt meine Parkposition korrekt an.

    Ein Restart der Container half ebenfalls nicht.

    Was kann man da tun?


    Danke & Viele Grüße