Beiträge von rhizom

    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?

    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.

    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

    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.

    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.

    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...

    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?

    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.

    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