evcc
evcc copied to clipboard
evcc-io
Retry soc poll on error
Describe the bug
Die Beschreibung mache ich mal auf deutsch. Dieses issue greift die in https://github.com/evcc-io/evcc/discussions/3430 und insbesondere in https://github.com/evcc-io/evcc/discussions/2772 beschriebene Problematik auf.
Je nach Fahrzeug treten häufiger oder seltener Fehler beim SOC-Abruf auf. Typische Fehlermeldungen im log sind dabei „vehicle soc: unexpected status: 500 (ignored by estimator)“, "context deadline exceeded" oder „"vehicle soc: timeout" im GUI.
Die Konsequenzen sind je nach Situation unterschiedlich. Bei „normalen“ Wallboxen lädt evcc z.B. dann mit voller Leistung, wenn ein „minSOC“ eingestellt ist. Bei schaltbaren Steckdosen kann es jedoch dazu kommen, dass der Ladevorgang über 15 min lang überhaupt nicht gestartet werden kann, siehe dazu https://github.com/evcc-io/evcc/issues/3846. Der Fehler hält üblicherweise 15 min, oder Vielfache davon an, weil evcc offensichtlich strikt in diesem Intervall die SOC-Abrufe macht.
In https://github.com/evcc-io/evcc/discussions/2772 wurde bereits von verschiedenen usern beschrieben, dass unmittelbar nach dem fehlerhaften SOC-Abruf in einer zweiten evcc-Instanz der SOC abgerufen werden kann, z.B. mit „evcc vehicle“. Es liegt also i.d.R. kein dauerhafter Fehler beim Server vor. Er antwortet nur einmalig verzögert.
Ich habe nun diesen Sachverhalt etwas weiter analysiert und mehrere Wochen beobachtet. Bei meinem Silence S01 tritt das besagte Problem ca. bei jedem zweiten Starten eines Ladevorgangs auf, was unerträglich oft ist. Wohlgemerkt nur beim Starten des Ladevorgangs, warum auch immer. Unmittelbar danach kann mit „evcc vehicle“ jedoch der SOC abgerufen werden. Während eines bereits laufenden Ladevorgangs passiert der Fehler extrem selten (und fallt auch nicht auf).
Interessant ist nun folgende Beobachtung: Wenn ich direkt nach dem Abstellen (also das Laden zu starten) versuche, mit „evcc vehicle“ den Fahrzeugstatus abzurufen, so kommt manchmal die Antwort nahezu sofort, ca. jedes 2. Mal aber erst nach bis zu 30 sec. Aber es kommt IMMER zu einem korrekten Abruf. Im Routinebetrieb kommt evcc aber viel eher als 30 sec. mit der einschlägigen Fehlermeldung im log, und versucht dann 15 min lang nicht wieder, den Fahrzeugstatus abzurufen.
Lösungsvorschlag: Der timeout für das Warten auf den Fahrzeugstatus sollte verlängert werden, bzw. das Verhalten sollte angepasst werden an dasjenige, welches bei „evcc vehicle“ abläuft. Alternativ sollte evcc im Falle eines solchen timeouts nicht erst nach 15 min einen erneuten Abruf starten. Evtl. werden bei „evcc vehicle“ tatsächlich mehrere Versuche im Falle eines Scheiterns gestartet?
Das Problem ist insbesondere störend in Zusammenhang mit der in https://github.com/evcc-io/evcc/issues/3846 beschriebenen Problematik.
Steps to reproduce
siehe oben.
Configuration details
Log details
siehe Anhang in https://github.com/evcc-io/evcc/discussions/2772#discussioncomment-2835182
What type of operating system are you running?
Linux
Version
0.94
Erstmal vielen Dank für die Mühe die Du Dir machst um gute Tickets zu schreiben- das ist super hilfreich!
Jetzt lass uns mal schauen:
Je nach Fahrzeug treten häufiger oder seltener Fehler beim SOC-Abruf auf. Typische Fehlermeldungen im log sind dabei „vehicle soc: unexpected status: 500 (ignored by estimator)“, "context deadline exceeded" oder „"vehicle soc: timeout" im GUI.
Das ist erstmal nicht erwünscht.
status: 500
Serverfehler- was sagt der S01 Support dazu?
context deadline exceeded
Wie schnell garantiert Dir S01 eine API Antwort? Du kannst die Wartezeit mit timeout anpassen.
timeout
Es kommt kein Update innerhalb der definierten Zeit. Wir können länger warten- wie lange wäre korrekt?
Da gibts sicher was zu verbessern, ist aber auf Tester mit entsprechenden Fahrzeugen und Good-will der Hersteller angewiesen.
dass der Ladevorgang über 15 min lang überhaupt nicht gestartet werden kann
Das verstehe ich nicht. Laden hängt nicht von SoC ab sondern von verfügbarer Grid Leistung.
oder Vielfache davon an, weil evcc offensichtlich strikt in diesem Intervall die SOC-Abrufe macht.
Siw kannst Du das anpassen.
dass unmittelbar nach dem fehlerhaften SOC-Abruf in einer zweiten evcc-Instanz der SOC abgerufen werden kann
Das ist nicht vergleichbar. In der zweiten Instanz gibts immer ein neues Login. Hier wäre herauszufinden, warum das erste Login nicht mehr funktioniert. Problem des APIs oder der Benutzung durch evcc? Trace log?
Lösungsvorschlag
Lass uns lieber den Root Cause finden und lösen!
Im Routinebetrieb kommt evcc aber viel eher als 30 sec. mit der einschlägigen Fehlermeldung im log
Logfile um das zu diagnostizieren?
Alternativ sollte evcc im Falle eines solchen timeouts nicht erst nach 15 min einen erneuten Abruf starten.
Das könnte man überlegen. Aber: es ist nicht klar, was die Ursache des Fehlers ist. Häufige Abfragen können für die Hersteller wie eine DOS Attacke aussehen. Wer kann sicher stellen, welches (geringere) Limit hier je Hersteller noch sicher ist?
Evtl. werden bei „evcc vehicle“ tatsächlich mehrere Versuche im Falle eines Scheiterns gestartet?
Nein
Erstmal vielen Dank für die Mühe die Du Dir machst um gute Tickets zu schreiben- das ist super hilfreich!
Danke! Gerne.
Jetzt lass uns mal schauen:
Je nach Fahrzeug treten häufiger oder seltener Fehler beim SOC-Abruf auf. Typische Fehlermeldungen im log sind dabei „vehicle soc: unexpected status: 500 (ignored by estimator)“, "context deadline exceeded" oder „"vehicle soc: timeout" im GUI.
Das ist erstmal nicht erwünscht.
status: 500
Serverfehler- was sagt der S01 Support dazu?
nichts, bzw. noch nicht gefragt. Die werden sagen, ist doch egal, mit unserer App geht ja alles. Dauert halt ggf ein paar Sek, bis die Daten angezeigt werden.
context deadline exceeded
Wie schnell garantiert Dir S01 eine API Antwort?
keine Ahnung...
Du kannst die Wartezeit mit
timeoutanpassen.
Das könnte schon die Lösung sein! Leider finde ich das nirgends dokumentiert. Wo muß das hin in dem Fall? Zeit in s oder ms? ...
timeout
Es kommt kein Update innerhalb der definierten Zeit. Wir können länger warten- wie lange wäre korrekt?
Da gibts sicher was zu verbessern, ist aber auf Tester mit entsprechenden Fahrzeugen und Good-will der Hersteller angewiesen.
Testen kann ich gerne.
dass der Ladevorgang über 15 min lang überhaupt nicht gestartet werden kann
Das verstehe ich nicht. Laden hängt nicht von SoC ab sondern von verfügbarer Grid Leistung.
War vielleicht ungüstig formuliert. Angenommen, man würde https://github.com/evcc-io/evcc/issues/3846 umsetzen, aber dieses Problem hier nicht lösen, so müsste evcc über 15 min den "out of sync"-Status tolerieren, weil früher kein neuer SOC-Abruf stattfindet.
oder Vielfache davon an, weil evcc offensichtlich strikt in diesem Intervall die SOC-Abrufe macht.
Siw kannst Du das anpassen.
Wo ist das dokumentiert? Ich dachte, der Poll-Intervall beim Laden wäre strikt immer 15 min? Laut Doku; "poll.interval: Definiert, wie oft das Fahrzeug nach neuen Daten abgefragt wird, wenn es NICHT lädt." Ich sehe das zu ändern aber gar nicht als zielführend.
dass unmittelbar nach dem fehlerhaften SOC-Abruf in einer zweiten evcc-Instanz der SOC abgerufen werden kann
Das ist nicht vergleichbar. In der zweiten Instanz gibts immer ein neues Login. Hier wäre herauszufinden, warum das erste Login nicht mehr funktioniert. Problem des APIs oder der Benutzung durch evcc? Trace log?
Ich vermute eher, dass der Server unmittelbar nach dem Abstellen des Fahrzeugs die aktuellen Daten noch nicht hat, und es ein paar sek nach dem Aufruf dauert, bis die kommen. Es deutet vieles darauf hin, der der Server die Daten vom Fahrzeug nur alle 10 min holt (oder das Fahrzeug sendet), so lange nichts forciert wird.
Lösungsvorschlag
Lass uns lieber den Root Cause finden und lösen!
Im Routinebetrieb kommt evcc aber viel eher als 30 sec. mit der einschlägigen Fehlermeldung im log
Logfile um das zu diagnostizieren?
Siehe Anhang. Kann ich das noch besser liefern? log_error500.txt Zwischen dem POST-Befehl und dem Fehler liegt laut log nur 1s.
Alternativ sollte evcc im Falle eines solchen timeouts nicht erst nach 15 min einen erneuten Abruf starten.
Das könnte man überlegen. Aber: es ist nicht klar, was die Ursache des Fehlers ist. Häufige Abfragen können für die Hersteller wie eine DOS Attacke aussehen. Wer kann sicher stellen, welches (geringere) Limit hier je Hersteller noch sicher ist?
Evtl. werden bei „evcc vehicle“ tatsächlich mehrere Versuche im Falle eines Scheiterns gestartet?
Nein
Wie gesagt, ich habe jetzt bestimmt 20x nach Fahrten probiert, mit "evcc vehicle" den Status abzufragen. Das hat immer geklappt, aber eben mit Wartezeit ca. jedes 2. Mal. Im normal laufenden evcc-Betrieb klappt es aber ca. jede 2. Mal nicht und es kommt der Fehler. Interessanterweise konnte übrigens das laufende evcc bei den 20x probieren nach "evcc vehicle" jedes mal sofort den SOC holen, ohne Fehler. Was eben darauf hindeutet, dass, aus welchen Gründen auch immer, der Server beim ersten Mal nach dem Abstellen länger braucht und das laufende evcc damit nicht zurecht kommt.
Wenn man die timeout-Zeit einstellen kann, wäre das dann der erste Lösungsweg aus meiner Sicht. Sobald ich also weiß, wo das hin muß...
Serverfehler- was sagt der S01 Support dazu?
nichts, bzw. noch nicht gefragt. Die werden sagen, ist doch egal, mit unserer App geht ja alles. Dauert halt ggf ein paar Sek, bis die Daten angezeigt werden.
Das ist ja bei evcc genau so. Kein Todo für uns.
Du kannst die Wartezeit mit
timeoutanpassen.Das könnte schon die Lösung sein! Leider finde ich das nirgends dokumentiert. Wo muß das hin in dem Fall? Zeit in s oder ms? ...
Ah, ich she tatsächlich dass es das für die Roller noch nicht gibt. Können wir nachreichen.
oder Vielfache davon an, weil evcc offensichtlich strikt in diesem Intervall die SOC-Abrufe macht.
Siw kannst Du das anpassen.
Wo ist das dokumentiert? Ich dachte, der Poll-Intervall beim Laden wäre strikt immer 15 min? Laut Doku; "poll.interval: Definiert, wie oft das Fahrzeug nach neuen Daten abgefragt wird, wenn es NICHT lädt." Ich sehe das zu ändern aber gar nicht als zielführend.
Das tut aber genau das- die 15min anpassen.
Siehe Anhang. Kann ich das noch besser liefern? log_error500.txt Zwischen dem POST-Befehl und dem Fehler liegt laut log nur 1s.
Server antwortet bei neuem Token mit HTTP 500. Das ist ein Problem beim Api, nicht bei evcc. Bitte Support fragen...
Alternativ sollte evcc im Falle eines solchen timeouts nicht erst nach 15 min einen erneuten Abruf starten.
...oder halt das Intervall verkürzen.
Wie gesagt, ich habe jetzt bestimmt 20x nach Fahrten probiert, mit "evcc vehicle" den Status abzufragen. Das hat immer geklappt, aber eben mit Wartezeit ca. jedes 2. Mal.
Problem des Apis.
Wenn man die timeout-Zeit einstellen kann, wäre das dann der erste Lösungsweg aus meiner Sicht. Sobald ich also weiß, wo das hin muß...
tbd
Timeout siehe https://github.com/evcc-io/evcc/pull/3854. Das wird allerdings nicht bei den HTTP 500 helfen.
Serverfehler- was sagt der S01 Support dazu?
nichts, bzw. noch nicht gefragt. Die werden sagen, ist doch egal, mit unserer App geht ja alles. Dauert halt ggf ein paar Sek, bis die Daten angezeigt werden.
Das ist ja bei evcc genau so. Kein Todo für uns.
Kann man so und so sehen. Die Api ist BEV-herstellerseitig ja ausschließlich dafür bereitgestellt, um mit der Smartphone-App zu reden. Nachdem da ein Mensch bei der Abfrage immer unmittelbar dransitzt, sind Verzögerungen oder einzelne Ausfälle viel eher zu tolerieren, als wie wenn die Api von vorne herein dafür konzipiert wäre, ständig in einem automatisierten Prozess mit anderen Softwares zu reden.
So gesehen möchte ich schon etwas provokant die Frage stellen, ob es nicht seitens evcc angemessen wäre, hier etwas mehr Fehlertoleranz zu bieten. Man könnte ja z.B. 3x mit jeweils 10s Abstand (oder einstellbare Werte) versuchen, und wenn es dann nicht klappt, halt erst wieder nach poll.interval. Das würde wahrscheinlich >90% der 500er-Fehler, die hier so berichtet werden, unproblematisch machen.
Du kannst die Wartezeit mit
timeoutanpassen.Das könnte schon die Lösung sein! Leider finde ich das nirgends dokumentiert. Wo muß das hin in dem Fall? Zeit in s oder ms? ...
Ah, ich she tatsächlich dass es das für die Roller noch nicht gibt. Können wir nachreichen.
Danke! Ich habe die Timeout-Einstellung jetzt an anderen Stellen gefunden. Auch da werde ich aber an der Kommentierung nicht ganz schlau. z.B.: (1) bei MQTT: "timeout: 30s # don't accept values older than timeout" (2) dann aber bei websocket: "timeout: 30s # error if no update received in 30 seconds" (2) ist das was wir hier brauchen. (1) verstehe ich aber eher analog zum poll.interval
oder Vielfache davon an, weil evcc offensichtlich strikt in diesem Intervall die SOC-Abrufe macht.
Siw kannst Du das anpassen.
Wo ist das dokumentiert? Ich dachte, der Poll-Intervall beim Laden wäre strikt immer 15 min? Laut Doku; "poll.interval: Definiert, wie oft das Fahrzeug nach neuen Daten abgefragt wird, wenn es NICHT lädt." Ich sehe das zu ändern aber gar nicht als zielführend.
Das tut aber genau das- die 15min anpassen.
Das ist dann aber unpräzise dokumentiert...
Siehe Anhang. Kann ich das noch besser liefern? log_error500.txt Zwischen dem POST-Befehl und dem Fehler liegt laut log nur 1s.
Server antwortet bei neuem Token mit HTTP 500. Das ist ein Problem beim Api, nicht bei evcc. Bitte Support fragen...
Alternativ sollte evcc im Falle eines solchen timeouts nicht erst nach 15 min einen erneuten Abruf starten.
...oder halt das Intervall verkürzen.
Halte ich für nicht zielführend. Man wollte es in der Situation ja nur vorübergehend verkürzen. Und zwar deutlich, denn 5 min statt 15 min helfen auch nicht wirklich. Ein dauerhaft kurzes Poll-Intervall birgt aber wieder das Risiko des Ärgers mit dem Anbieter. Nochmal die Frage, kann ich irgendwie, z.B. über die REST API, einen Abruf der Fahrzeugdaten außer der Reihe anstoßen? Oder vorübergehend poll.intervall ändern? Soweit ich das probiert habe, klappt ja nicht mal, dass man auf "aus" und dann wieder auf "sofort" schaltet. evcc wartet 15 min ab der letzten Abfrage, gleich, was dazwischen passiert.. Das wäre auch für externe Lösungen wichtig.
Wie gesagt, ich habe jetzt bestimmt 20x nach Fahrten probiert, mit "evcc vehicle" den Status abzufragen. Das hat immer geklappt, aber eben mit Wartezeit ca. jedes 2. Mal.
Problem des Apis.
Ich fasse nochmal meine Tests zusammen. Ich habe jetzt über mehrere Wochen logs ausgewertet und verschiedene Sachen probiert. Insges. ca. 40 Ladevorgänge und 80h Ladezeit. In der Zeit hatte ich nur ein einziges Mal einen 500er-Fehler während eines laufenden Ladevorgangs. Jedoch bei ca. jedem 2. Ladevorgang einen Fehler gleich zu Beginn. Mit "evcc vehicle" nie einen Fehler. Ob das nun an der Api liegt, oder ob evcc bei der ersten Abfrage etwas "ungeduldiger" ist, kann ich nicht sagen. Siehe aber mein einleitetendes Statement.
Und nochmal zu poll.interval. Denn ich komme da mit der Doku und Deiner Erklärung nicht klar.
In der Doku steht:
poll.Interval
Definiert, wie oft das Fahrzeug nach neuen Daten abgefragt wird, wenn es NICHT lädt.
Standardwert: 60m
Ich verstehe das so: wenn ich poll.mode auf "always" stelle und poll.interval auf "90 min", so pollt er alle 15 min, wenn er lädt, und alle 90 min, wenn er nicht lädt.
Nach Deiner Aussage pollt er dann aber auch beim Laden nur alle 90 min?
Verstehe ich nicht. Es macht doch gerade Sinn aus dem genannten potenziellen Ärger mit dem Anbieter, dass man zwei verschiedene Zeiten hat.
EDIT: gemäß https://github.com/evcc-io/evcc/discussions/856 stellt man den Poll-Intervall während des Ladens mit cache unter vehicles ein.
sind Verzögerungen oder einzelne Ausfälle viel eher zu tolerieren
evcc ist da völlig tolerant und funktioniert einfach weiter.
Ich weiß nicht wo die Diskussion hinführen soll. Sie scheint mir wenig konstruktiv. Wenn ichs richtig verstehe hättest Du gerne einen 3xRetry der SoC Abfrage? PR welcome.
Sorry, ich war die letzten 2 Tage verhindert.
Ich weiß nicht wo die Diskussion hinführen soll. Sie scheint mir wenig konstruktiv. Wenn ichs richtig verstehe hättest Du gerne einen 3xRetry der SoC Abfrage? PR welcome.
Ja, das wäre mein Vorschlag. Leider hindern mich meine nicht vorhandenen Kenntnisse in Go, das selber zu implementieren. So bleibt mir nur, mit einem externen Skript was zurechtzubasteln, was dann aber keinem anderen hilft.
Bei meinem Hybrid BMW ist es sehr ähnlich. Mit evcc vehicle klappt dir Abfrage vom SoC ca. jedes 2. Mal mit wechselnden Fehlermeldungen, deren Analyse glaub ich nicht weiterhelfen. Es zeigt ja aber, dass der Fehler immer nur temporär ist und dass das ein simpler Neuversuch helfen würde.
Hättest du trotzdem mal ein Log von so einer Abfrage? Ich kann das bei einmaligem Aufruf leider nicht reproduzieren, sehe es aber (leider ohne trace) immer wieder im Cloud log.
Na klar, gerne. Hier ist ein Log vom häufigsten Fehlerfall:
evcc vehicle --name bmw_hybrid --log trace [main ] INFO 2022/07/21 20:12:08 evcc 0.96 [main ] INFO 2022/07/21 20:12:08 using config file /home/pi/evcc.yaml [bmw ] TRACE 2022/07/21 20:12:08 POST https://customer.bmwgroup.com/gcdm/oauth/authenticate [bmw ] TRACE 2022/07/21 20:12:08 client_id=31c357a0-7a1d-4590-aa99-33b97244d048&code_challenge=jRucd2TxZBorP2cvjs2xDrikVcp1gVv2ztbq9kxOtRk&code_challenge_method=S256&grant_type=authorization_code&nonce=login_nonce&password=&redirect_uri=com.bmw.connected%3A%2F%2Foauth&response_type=code&scope=authenticate_user+vehicle_data+remote_services&state=cwU-gIE27j67poy2UcL3KQ&username= -- {"redirect_to" : "redirect_uri=com.bmw.connected://oauth?client_id=31c357a0-7a1d-4590-aa99-33b97244d048&response_type=code&scope=authenticate_user vehicle_data remote_services&state=cwU-gIE27j67poy2UcL3KQ&authorization=NoFWgIcx04rEKDV061SUEWX48yI.AAJTSQACMDIAAlNLABxUWm1VSUpIdEpKaVBhdTFTT1NqYWZ3YkJNV2c9AAR0eXBlAANDVFMAAlMxAAIwMQ.."} [bmw ] TRACE 2022/07/21 20:12:08 POST https://customer.bmwgroup.com/gcdm/oauth/authenticate [bmw ] TRACE 2022/07/21 20:12:08 authorization=NoFWgIcx04rEKDV061SUEWX48yI.%2AAAJTSQACMDIAAlNLABxUWm1VSUpIdEpKaVBhdTFTT1NqYWZ3YkJNV2c9AAR0eXBlAANDVFMAAlMxAAIwMQ..%2A&client_id=31c357a0-7a1d-4590-aa99-33b97244d048&code_challenge=jRucd2TxZBorP2cvjs2xDrikVcp1gVv2ztbq9kxOtRk&code_challenge_method=S256&nonce=login_nonce&redirect_uri=com.bmw.connected%3A%2F%2Foauth&response_type=code&scope=authenticate_user+vehicle_data+remote_services&state=cwU-gIE27j67poy2UcL3KQ [bmw ] TRACE 2022/07/21 20:12:08 POST https://customer.bmwgroup.com/gcdm/oauth/token [bmw ] TRACE 2022/07/21 20:12:08 code=aaq0Tehq3VOPylICleCP3vkVZXc&code_verifier=VG9lbUlTd2V3eDBhMmRyS1VGT3NrMWxTZkxJNG4xcEU&grant_type=authorization_code&redirect_uri=com.bmw.connected%3A%2F%2Foauth -- {"gcid":"c6e7e3f3-3ed7-4113-9f51-26fbde7700d2","token_type":"Bearer","access_token":"","refresh_token":"","scope":"vehicle_data remote_services authenticate_user","expires_in":3599} [bmw ] TRACE 2022/07/21 20:12:08 GET https://cocoapi.bmwgroup.com/eadrax-vcs/v1/vehicles?apptimezone=60&appDateTime=1658427128 [bmw ] TRACE 2022/07/21 20:12:09 [] .SoC: vehicle not available: cannot create vehicle 'template': cannot create vehicle 'bmw': cannot find vehicle: WBA*** Capacity: 0kWh
@DanielGlaas Das hat mit dem Thema hier nichts zu tun. Bei Dir startet evcc erst gar nicht weil das API keine Fahrzeuge „sieht“. Hier gehts aber um laufendes evcc das keine Antworten mehr auf SoC Abfragen liefert.
Ist Deine Aussage (unabhängig von diesem Issue), dass mehrere Aufrufe von evcc vehicle meist irgendwann zum Ergebnis führen?
Ist Deine Aussage (unabhängig von diesem Issue), dass mehrere Aufrufe von evcc vehicle meist irgendwann zum Ergebnis führen?
Ja, das ist im Prinzip meine Kernaussage. Irgendwann, nach genügend Versuchen, klappt diese Abfrage von SoC mal wieder.
Entschuldigt bitte, das ich hier das Thema vermischt habe. Ich weiß, solche Querschüsse sind nicht hilfreich, ich hatte das irgendwie als gleiches Thema interpretiert.
Nur so als Gedenken von mir dazu. Vorweggeschickt habe ich jedoch keinen Einblick, wie diese Authentifikation genau funktioniert. Ich sehe bei dem BMW-Fall aber gewisse Parallelen zu dem, wie es bei mir beim S01 ist.
So wie ich das verstehe, ist der poll-Vorgang Zweistufig. Im ersten Schritt wird vom Authentifiierungs-Server das bearer-token geholt. Im zweiten Schritt dann vom eigentlichen Daten-Server die Daten.
Mit "evcc vehicle" hatte ich bisher nie ein problem. Sehr wohl aber, wenn ich evcc vollständig neu starte. Wenn in dem Zustand mit dem S01 ein Fehler passiert, so kommen auch diese Fehlermeldungen "vehicle not available" und "cannot create vehicle". Siehe Anhang. log_s01_220601.txt
Was passiert eigentlich Server-seitig zwischen den beiden Servern (Auth, Daten) bei so einer Abfrage?
Ich kann nicht oft genug betonen, dass der fehler immer nur bei eriner Erst-Abfrage passiert. Das bearer-Token gilt ja eine Zeit lang und wird nicht jedes Mal neu erzeugt laut Log. Bei einer solchen Nach-Abfrage ist bei mir bisher nie ein Fehler aufgetreten, sondern immer nur, wen vorher das bearer-token abgefragt wird.
Eine naive Idee meinerseits: Evtl. kommt die eigentliche Anfrage der Daten zu schnell nach der bearer-Token-Antwort, und der Daten-Server ist noch nicht weit genug?
Patrick
Ich sehe bei dem BMW-Fall aber gewisse Parallelen zu dem, wie es bei mir beim S01 ist.
Sind grundunterschiedliche Dinge. Lass uns BMW hier mal vergessen...
So wie ich das verstehe, ist der poll-Vorgang Zweistufig. Im ersten Schritt wird vom Authentifiierungs-Server das bearer-token geholt
Nein, das ist nicht so. Die Tokens sind long-lived.
Eine naive Idee meinerseits: Evtl. kommt die eigentliche Anfrage der Daten zu schnell nach der bearer-Token-Antwort, und der Daten-Server ist noch nicht weit genug?
Möglich ist alles, wenn schlechte Software im Spiel ist...
@patbab lass uns das S01 mal bitte hier raus ziehen, das ist anders: https://github.com/evcc-io/evcc/issues/3918