carwings async requests

[maku1604]

Change carwings requests to async, similar to ford and nissan async updates

[andig]

/rebase

[andig]

Doppelt?

[andig]

Ich habe die status Methode jetzt nochmal komplett neu aufgesetzt und vereinfacht. Was hälst du so davon?

Viel besser. Ich hab nochmal aufgeräumt- es waren noch einige Aktionen mehrfach im Code, tw. auch Altlasten. Magst Du's nochmal prüfen?

[maku1604]

OK, ja ich schau heute Abend nochmal drauf. Danke!

[andig]

Mich stören immer noch die erneuten Logins, bin aber nicht sicher ob die entfernt werden könnten? Im Prinzip würden sie noch an einer Stelle fehlen. Ggf. könnten wir das nochmal ein eine eigene Fehlerbehandlungsfunktion auslagern.

[maku1604]

Ein Problem beim Carwings Server ist leider, dass der scheinbar nur eine Session pro User hält. D.H immer wenn man die Nissan App verwendet, muss sich evcc hinterher neu connecten und andersrum auch in der App muss man sich dauernd neu anmelden....

[andig]

Na wenigstens lässt sich das Szenario gut testen :)

[maku1604]

Ich habe Fälle gesehen, in denen das Ergebnis zwischenzeitlich angekommen ist und elapsed dann nicht mehr über dem ExpiryTimeout war. Dann wurde der refreshKey nicht gelöscht und somit beim nächsten durchlauf erst nach einem veralteten Key gesucht. Ich versuche gerade das nochmal mit dem aktuellen Stand zu reproduzieren,

[maku1604]

Mit allen anderen Änderungen ausser evtl. der oben kommentierten bin ich einverstanden. Praxistest läuft gerade.

[maku1604]

Mit dem aktuellen Status bekomme ich nur noch 404 Fehler von Carwings. Ich tippe da ist was bei der Verschiebung von Session und Region im argen.

[andig]

Hättest Du evtl Zugangsdaten für mich damit ich selbst mal rein schauen kann ([email protected])?

[maku1604]

Ich schau mir das heute Abend nochmal an. Wollte nur erstmal Bescheid geben, dass der aktuelle Zustand nicht gemerged werden sollte.

[andig]

Den refresh key verstehe ich, aber was ist mit dem Login? Egtl. Sollte doch errnotloggedin kommen wenn man nicht drin ist und der dann immer abgefangen werden. Die zusätzliche needLogin Variable gefällt mir gar nicht.

[maku1604]

NeedLogin hat mir auch nicht wirklich gefallen. Ich habe das jetzt nochmal anders über das Fehler handling gelöst. Nachteil dieser Lösung ist, dass carwings bei jedem start von evcc erstmal bewusst falsch angesprochen wird und dann erst über das Error handling der login zustande kommt. Aber es funktioniert so.

[andig]

Warum nicht einfach einmal am Anfang einloggen? So hattest Du es doch zwischendurch? Warum erkennt carnet selbst nicht die 404 als notloggedin?

[maku1604]

Wenn am Anfang, dann nur ohne Error Detektion, sonst startet evcc nicht mehr sobald der Carwings server down ist. Den Login hattest du selbst im Dezember aus dem Grund schonmal von dort in die status Abfrage verschoben. PR #585.

[andig]

Ahhh, verstehe. Ist blöd, dass man damit nicht user/pw prüfen kann, aber ist halt so. D.h. Jetzt gehts und rein damit?

[maku1604]

Ich bin so jedenfalls zufrieden damit. Von mir aus rein damit.

[andig]

Ich hab den Sonderfall mal hier dokumentiert joeshaw/carwings#36

[andig]

Den verstehe ich noch nicht. Wenn es zum Timeout kommt, erzeuge ich beim ersten mal einen refreshRequest. Der wird irgendwann erfüllt und über refreshResult abgeholt. Im refreshResult wird der Key zurück gesetzt.

Warum ist das dann hier nochmal notwendig? Gibts da irgendwo noch einen Fehler in der Logik? Es riecht immer denn die Logik so verteilt ist nach versteckten Fehlern...

[maku1604]

Beim Batteriestatus request wird der timestamp der letzten Antwort gelesen. Ist jetzt seit dem letzten requestfinished mit result false die Antwort eingetrudelt, wird die so genommen und kein neuer Finish Check gemacht, da der elapsed wert nur weniger Sekunden hat=> der Key wird nicht gelöscht ohne den Else Zweig nicht gelöscht. Nach Ablauf des Cache (15min) wir dann der Finish Check mit dem alten Key gemacht... Returned success und damit bleiben die alten Werte weiter gecached anstatt neue zu requesten. Erst beim nächsten die Durchlauf (wieder 15 min) wird dann ein neuer Status request abgesetzt.

[andig]

Top, dann endlich rein damit. Vielen Dank für Deine Geduld!

[maku1604]

So viel wie ich mit Go noch selbst am lernen bin, muss ich wohl eher dir danken für deine Geduld. 😁 Sollten wir carwings für Nissan Fahrzeuge mit Auslieferung vor 5/19 noch irgendwie in der Doku vermerken?

[andig]

Gute Idee, mit cad5996 erledigt

[andig]

@maku1604 ich glaube ich habe 2 Bugs gefunden:

1. wenn es einen offenen RefreshRequest gibt, wird dennoch in StatusG immer zuerst die Batterie abgefragt. Das ist egtl. unnötig- hier sollte nur geprüft werden ob der Refresh erfolgreich war:

    if v.refreshKey != "" {
        if err := v.refreshResult(); err != nil {
            return err
        }
    }
   
    bs, err := v.session.BatteryStatus()
   

2. der Climater fragt selbst statusG ab, hat aber intern ein anderes API. Der statusG is vmtl irrelevant, ich glaube der Refresh greift hier nicht.

Könntest Du Dir das nochmal anschauen?

[maku1604]

OK, ich schau mir das nochmal an. Aus der Errinerung heraus, habe ich den Batteriestatus dort jeweils abgefragt um an das Alter der Daten zu kommen.

[andig]

OK, siehe #1157