Beiträge von Marcy82

Kurzes Update: Umschiffen des AdGuard DNS (der übrigens auf dem gleichen Rechner in einem anderen Container läuft) hat geholfen. Da der Rechner definitiv Internet und DNS Zugang hat (andere Dienste laufen problemlos), scheint es an der Konfiguration des Containers oder der AdGuard-Config zu liegen... ich checke das die Tage mal...

Danke nochmal für den Stupser in die richtige Richtung.

Schönes Wochenende!

seltsam... von einem anderen PC im gleichen Netz (und DNS) kann ich die Grafana-Adresse öffnen.

Ich habe seit ein paar Wochen AdGuard als DNS laufen (und bisher lief alles sauber). Selbst mit Deaktivierung klappt es nicht. Ich werde sicherheitshalber am Wochenende mal den AdGuard vollständig "umschiffen" und schauen, ob es daran liegt.

Danke für den Tipp, manchmal sieht man den Wald vor lauter Bäumen nicht

bei mir läuft VWsFriend seit einem Neustart des Servers nicht mehr (ich vermute zumindest, dass es mit dem Neustart zusammen hängt... zeitlich kommt das ungefähr hin).

Zwei Fehlermeldungen gibt es:

1) Kommt mehrmals nacheinander (im Abstand von paar Sekunden):

grafana-1 | Error: ✗ Get "https://grafana.com/api/plugins/repo/marcusolsson-json-datasource": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

grafana-1 exited with code 0

Die Adresse ist aber erreichbar, Firewall deaktivieren macht auch keinen Unterschied.

2) etwas länglich, hier der erste Teil...

vwsfriend-1   | Traceback (most recent call last):
vwsfriend-1   |   File "/opt/venv/lib/python3.12/site-packages/urllib3/connection.py", line 203, in _new_conn
vwsfriend-1   |     sock = connection.create_connection(
vwsfriend-1   |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
vwsfriend-1   |   File "/opt/venv/lib/python3.12/site-packages/urllib3/util/connection.py", line 60, in create_connection
vwsfriend-1   |     for res in socket.getaddrinfo(host, port, family, socket.SOCK_STREAM):
vwsfriend-1   |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
vwsfriend-1   |   File "/usr/lib/python3.12/socket.py", line 963, in getaddrinfo
vwsfriend-1   |     for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
vwsfriend-1   |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
vwsfriend-1   | socket.gaierror: [Errno -3] Temporary failure in name resolution
vwsfriend-1   |
vwsfriend-1   | The above exception was the direct cause of the following exception:
vwsfriend-1   |
vwsfriend-1   | Traceback (most recent call last):
vwsfriend-1   |   File "/opt/venv/lib/python3.12/site-packages/urllib3/connectionpool.py", line 790, in urlopen
vwsfriend-1   |     response = self._make_request(
vwsfriend-1   |                ^^^^^^^^^^^^^^^^^^^
vwsfriend-1   |   File "/opt/venv/lib/python3.12/site-packages/urllib3/connectionpool.py", line 491, in _make_request
vwsfriend-1   |     raise new_e
vwsfriend-1   |   File "/opt/venv/lib/python3.12/site-packages/urllib3/connectionpool.py", line 467, in _make_request
vwsfriend-1   |     self._validate_conn(conn)
vwsfriend-1   |   File "/opt/venv/lib/python3.12/site-packages/urllib3/connectionpool.py", line 1096, in _validate_conn
vwsfriend-1   |     conn.connect()
vwsfriend-1   |   File "/opt/venv/lib/python3.12/site-packages/urllib3/connection.py", line 611, in connect
vwsfriend-1   |     self.sock = sock = self._new_conn()
vwsfriend-1   |                        ^^^^^^^^^^^^^^^^
vwsfriend-1   |   File "/opt/venv/lib/python3.12/site-packages/urllib3/connection.py", line 210, in _new_conn
vwsfriend-1   |     raise NameResolutionError(self.host, self, e) from e
vwsfriend-1   | urllib3.exceptions.NameResolutionError: <urllib3.connection.HTTPSConnection object at 0x7fff088ab8f0>: Failed to resolve 'emea.bff.cariad.digital' ([Errno -3] Temporary failure in name resolution)
vwsfriend-1   |

Jemand eine Idee?

bei mir synchronisiert er sich ebenfalls dauernd. Hat 3% Batterieladung über Nacht gekostet. Es schaltet alle paar Minuten das HV Relais...

ah, ok, dann achte ich in Zukunft darauf. Neue AGBs (mit Pflicht-Zustimmung) wurden mir nicht angeboten. Lediglich die (optionale) personalisierte Werbung. Schon faszinierend, dass die gesamte Kommunikation seitens VW unterbrochen wird, bis man dieses optionale "add-on" abgelehnt/zugestimmt hat...

scheint wohl doch ein Server Problem gewesen zu sein. EVCC konnte auch keine Verbindung aufbauen, habe ich aber erst beim Laden gemerkt.

Aktuell scheint es wieder zu funktionieren.

Ob VW das irgendwann mal in den Griff bekommt?!

Hallo,

bei mir läuft seit ein paar Tagen die Synchronisierung nicht mehr.

gerade nochmal den container neu gestartet und das Log sagt:

docker-vwsfriend-1 | 2023-04-21T11:32:05+0000:CRITICAL:vwsfriend_base:There was a problem when communicating with WeConnect. If this problem persists please open a bug report: No user id provided

docker-vwsfriend-1 | Traceback (most recent call last):

docker-vwsfriend-1 | File "/opt/venv/bin/vwsfriend", line 8, in <module>

docker-vwsfriend-1 | sys.exit(main())

docker-vwsfriend-1 | ^^^^^^

docker-vwsfriend-1 | File "/opt/venv/lib/python3.11/site-packages/vwsfriend/vwsfriend_base.py", line 558, in main

docker-vwsfriend-1 | if mqttCLient is not None:

docker-vwsfriend-1 | ^^^^^^^^^^

docker-vwsfriend-1 | UnboundLocalError: cannot access local variable 'mqttCLient' where it is not associated with a value

docker-vwsfriend-1 exited with code 0

docker-vwsfriend-1 | 2023-04-21T11:32:12+0000:CRITICAL:vwsfriend_base:There was a problem when communicating with WeConnect. If this problem persists please open a bug report: No user id provided

docker-vwsfriend-1 | Traceback (most recent call last):

docker-vwsfriend-1 | File "/opt/venv/bin/vwsfriend", line 8, in <module>

docker-vwsfriend-1 | sys.exit(main())

docker-vwsfriend-1 | ^^^^^^

docker-vwsfriend-1 | File "/opt/venv/lib/python3.11/site-packages/vwsfriend/vwsfriend_base.py", line 558, in main

docker-vwsfriend-1 | if mqttCLient is not None:

docker-vwsfriend-1 | ^^^^^^^^^^

docker-vwsfriend-1 | UnboundLocalError: cannot access local variable 'mqttCLient' where it is not associated with a value

docker-vwsfriend-1 exited with code 0

docker-vwsfriend-1 | 2023-04-21T11:32:19+0000:CRITICAL:vwsfriend_base:There was a problem when communicating with WeConnect. If this problem persists please open a bug report: No user id provided

docker-vwsfriend-1 | Traceback (most recent call last):

docker-vwsfriend-1 | File "/opt/venv/bin/vwsfriend", line 8, in <module>

docker-vwsfriend-1 | sys.exit(main())

docker-vwsfriend-1 | ^^^^^^

docker-vwsfriend-1 | File "/opt/venv/lib/python3.11/site-packages/vwsfriend/vwsfriend_base.py", line 558, in main

docker-vwsfriend-1 | if mqttCLient is not None:

docker-vwsfriend-1 | ^^^^^^^^^^

docker-vwsfriend-1 | UnboundLocalError: cannot access local variable 'mqttCLient' where it is not associated with a value

docker-vwsfriend-1 exited with code 0

Die VW App funktioniert bei mir aber problemlos (also scheint es kein generelles Serverproblem zu sein). Und was mich verwundert, ist der Hinweis auf MQTT client... da ich heute aus dem Urlaub zurück bin, kann ich Änderungen an meinem MQTT server in den letzten Tagen ziemlich sicher ausschließen

Hat noch jemand aktuell Probleme?

Viele Grüße!

nachdem meine Werkstatt etwas rumgezickt hat ("diese TPI ist uns nicht bekannt" bla bla), habe ich sie seit heute auch endlich drauf

Mal schauen, ob es auf Dauer hilft...

nein, nichts zu finden in den logs. Nach einem Container-Neustart wurde direkt wieder mit dem VW Server kommuniziert. Allerdings habe ich wieder den gleichen Fehler wie gestern Abend: Overview sagt "Update Auto 7 Uhr", Live sagt "Upate Auto 9.30 Uhr".

Ich vermute, wenn ich jetzt nochmal fahre, ist wieder alles korrekt (bis zum nächsten Hänger im Container).

Was mir noch aufgefallen ist: anscheinend wird jedesmal wenn ich die Seite öffne eine Kommunikation gestartet, und nicht nur fix alle 2 Minuten (wie eingestellt). Ist das neu?

Zitat von Marcy82

Update: Problem hat sich anscheinend von selbst gelöst Eine Fahrt heute Abend hat zum Aktualisieren aller falschen Werte geführt.

Bei mir waren seit dem Update die Anzeigen inkosistent und teilweise falsch:

Overview:

Letzte Daten vom Auto gestern Abend,

Auto lädt angeblich mit 10kW obwohl angezeigt wird, dass es nicht angesteckt ist.

Live:

Update heute Nachmittag,

Lädt nicht

Trips von heute sind auch nicht aufgezeichnet.

Ist das ein VW-Backend-Problem, ein Bug, oder ist meine Datenbank beschädigt?

Das Log gibt leider keinerlei Hinweise...

Alles anzeigen

Anscheinend hängt doch irgendwas...

heute Morgen 2 Fahrten, beide nicht registriert. Die Updatezeiten im Status sind auch unterschiedlich alt.

Screenshot_20230302_094009_Chrome.jpg

Und seit Stunden kein Abruf beim Server mehr. Die WeConnect App läuft aber problemlos.

Update: Problem hat sich anscheinend von selbst gelöst Eine Fahrt heute Abend hat zum Aktualisieren aller falschen Werte geführt.

Bei mir waren seit dem Update die Anzeigen inkosistent und teilweise falsch:

Overview:

Letzte Daten vom Auto gestern Abend,

Auto lädt angeblich mit 10kW obwohl angezeigt wird, dass es nicht angesteckt ist.

Live:

Update heute Nachmittag,

Lädt nicht

Trips von heute sind auch nicht aufgezeichnet.

Ist das ein VW-Backend-Problem, ein Bug, oder ist meine Datenbank beschädigt?

Das Log gibt leider keinerlei Hinweise...

Zitat von joernh

Moin zusammen und stein,

Kann es sein, dass VWsFriend nach einer gewissen Zeit "einschläft"? Heute morgen um 07:00 Uhr hatte ich wieder das Problem, dass die letzen Daten vom Server laut Grafana um kurz nach 05:30 Uhr geladen wurden. Somit waren die Daten vom zeitversetzten Laden zur Abfahrtszeit heute um 07:30 Uhr wieder nicht vorhanden. Laut Grafana SOC von 71% obwohl laut WeConnect ID ein SOC von 80% da war. Auch mehrfaches refresh der Datenabfrage brachten keine aktualisierten Daten zum Vorschein. Laut Portainer waren alle 3 Container auf "healthy". Nachdem ich die Container dann neu gestartet habe, kamen dann auch wieder aktuelle Daten. Hat da jemand von Euch ne Idee?

Bei mir lief der Container eine Weile auf einem Pi2 (der an seiner Leistungsgrenze war). Da ist der Container alle 2-3 Tage abgeschmiert. Ein Cron-job zum täglichen Neustart des Containers hat Abhilfe geschaffen.

Seit ein paar Wochen habe ich das ganze auf einen deutlich leistungsstärkeren Rechner umgezogen => lief fast 3 Wochen ohne irgendwelche Probleme durch. Erst vor ein paar Tagen dann der erste Crash (und ich war nicht zuhause um danach zu schauen). Wahrscheinlich werde ich "sicherheitshalber" wieder einen täglichen Container-Neustart einbauen. Ist kein Aufwand und beschränkt im worst-case den Ausfall auf <24h, egal ob ich Zugriff auf meinen Server habe oder gerade in Timbuktu im Urlaub bin

ok, "verschwinden" in den MQTT Messages heißt dann ja, dass es kein Update gibt und der alte Wert im Broker einfach erhalten bleibt. Irgendein Zahlenwert (z.B. "-1" als ungültig) wäre einfacher zu verarbeiten...

Fällt dir spontan ein work-around ein? Irgendein anderer Parameter?

Oder besteht die Möglichkeit in der nächsten Version einen Status auszugeben? Parking=true/false

die Server-Probleme von VW scheinen behoben... zumindest bei mir kommen wieder Updates zu Strecken, Ladung, etc. an.

joernh , als Strohhalm: hast du mal docker-compose als root gestartet?

Bei 64Bit hatte ich vor Jahren bei diversen Tools Probleme. Deshalb laufen auf meinen Pi(s) überall nur 32bit Systeme, leider.

Ganz andere Frage stein : Welcher Parameter (per MQTT verfügbar) wäre denn am sinnvollsten, um "Parken" von "Fahren" zu unterscheiden? In der GUI gibt es ein kleines "P" im Bild. Gibst du das als binären Zustand auch raus?

bei mir haben sie vorne und hinten ohne Träger montiert und die Schrauben mit farbigen Kunststoffkappen versehen.

Für den Fall, dass mal eine verloren geht, haben sie mir eine Hand voll in Weiß & Schwarz mitgegeben