Reduce number of server round-trips

[andig]

/cc @maku1604

[andig]

@maku1604 das funktioniert bei mir jetzt ziemlich zuverlässig obwohl das Backend unglaublich langsam ist- t.w. >90s um überhaupt die TCP Verbindung herzustellen. Aus meiner Sicht good to go.

[maku1604]

Ich versuche heute Abend mal das für Carwings zu testen.

[maku1604]

So, Ich habe diesen PR jetzt mal testweise laufen und die Ergebnisse in evcc sind erstmal genauso wie ohne PR. Aber ich habe das Gefühl wir haben ein unterschiedliches Verständnis davon, wie der 2 stufige Datenabruf bei carwings funktioniert,

• Meinem Verständnis nach bekommt man mit carwings.BatteryStatus den letzten Batterie Zustand den der Server kennt.

• Mit ClimateControlStatus das Equivalent für die Klimasteuerung,

• Und um diese daten vom Fahrzeug zum server aktualisiert zu bekommen, muss man carwings.UpdateStatus aufrufen und dann auf das resultat warten (asynchron). Die Ankunft der Antwort kann man mit carvings.CheckUpdate prüfen, oder man erkennt ein update am Timestamp im Batterystatus.

• Es gibt aber keine Funktion um den ClimateControlStatus vom Fahrzeug abzuholen, sondern nur welche um selbst die HVAC anzusteuern. Wenn man also die Abfragen beim carwings server verringern will, muss man sowohl BatteryStatus als auch ClimateControlStatus cachen und zusätzlich aufpassen, dass UpdateStatus nicht zu häufig aufgerufen wird, damit man die 12V des Fahrzeugs nicht platt macht.

Meiner Erfahrung nach, wird man hier bei einem poll intervall unter 10min aber eh von carwings geblockt und temporär ausgesperrt. Daher bisher die Beschränkung des StatusUpdate auf 15min.

Es gibt im ClimateControlStatus auch einen timestamp, vielleicht sollten wir den mal ansehen um zu checken mit welchen calls der ClimateControlStatus aktualisiert wird.

[maku1604]

Zusätzlich hatte ich jetzt vorrübergehend noch folgenden Fehler im log:
vehicle charge state: received status code -2010 (INVALID PARAMS)

[andig]

UPDATED

Das Verhalten ist deutlich anders da jetzt viel weniger requests- siehst Du im Logging.

Meinem Verständnis nach bekommt man mit carwings.BatteryStatus den letzten Batterie Zustand den der Server kennt.

Genau. Mein Eindruck ist aber, dass dieses API VIEL langsamer ist als den Refresh Status abzufragen- falls es einen gibt daher diesen. Falls Refresh notwendig aber noch nicht passiert macht es auch keinen Sinn den BatteryStatus abzufragen.

Mit ClimateControlStatus das Equivalent für die Klimasteuerung,

Für den ClimateStatus gibts kein Update, also machst auch keinen Sinn dafür StatusG aufzurufen- daher entfernt.

Wenn man also die Abfragen beim carwings server verringern will

Das machen wir schon. Das Caching passiert aber im Loadpoint. Vehicle ist hier nur "last line of defense".

Ich hab jetzt deine Kritik nicht ganz verstanden.

Für den Fehler bräuchte es ein Logfile.

[andig]

@maku für mich siehts immer noxh gut aus

[maku1604]

Sorry, Ich komm gerade nicht dazu mich da nochmal tiefer mit zu beschäftigen. Nimms ruhig so rein und ich mach nochmal einen neuen PR auf wenn ich noch weitere Verbesserungen hab.