Restladezeit optional von Fahrzeug-API

[premultiply]

Die Restladezeitschätzung sollte optional von der Fahrzeug-API übernommen werden können da diese weitere Faktoren in die Berechnung einfließen lassen kann (Ladekurve, Zelltemperaturen, ...) als nur der momentane Ladestand und die Ladegeschwindigkeit und damit eine genauere Vorhersage liefern.

Bekannterweise liefern mindestens die Renault- und Kia-Schnittstellen #297 solche Prognosen.
Andere Vermutlich auch. Rückfallebene ist immer die vorhandene interne Restzeitschätzung. #296

[issue-label-bot]

Issue-Label Bot is automatically applying the label feature_request to this issue, with a confidence of 0.98. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[andig]

Interessante Idee- wollen wir denn diesen APIs mehr vertrauen oder alternativ vielleicht die SoC Schätzung auch auf die Restladeprognose ausdehnen?

[premultiply]

Aus Erfahrung und Beobachtung ist der Eigenschätzung des Fahrzeugs (zumindest bei der ZOE) sehr viel mehr als der einfachen internen Berechnung in EVCC zu trauen. Bei ständig schwankenden Ladeleistungen sind natürlich beide Verfahren ziemlich machtlos.

Genau an der Verbesserung der internen Restladeprognose arbeite ich schon unter #296. ;)

Trotzdem finde ich den API-Weg optional und wo vorhanden sehr begrüßens- und wünschenswert.

[mclane]

Beim Kia kann man auch den TargetSoC vom Fahrzeug holen (kann man dort getrennt für AC und DC einstellen). Wenn vorhanden, sollte man diesen nutzen.

[andig]

Macht das Sinn oder sollte man- wenn evcc eingesetzt- den nicht immer in der App auf 100 stellen? Oder lässt sich der auch Remote ändern?

[mclane]

Naja, wenn ich in der evcc WebUI den TargetSoC auf 100% stelle das Auto aber bei 90% aufhört stimmt die Restladezeit in der WebUI nicht. Den TargetSoC kann man in der UVO connect app einstellen, es müsste demnach auch remote gehen. Dazu müsste man die Kommunikation der UVO connect app aber mal belauschen, damit man sieht, wie das geht.

[premultiply]

Ja, es macht bei EVCC absolut Sinn das Fahrzeug immer auf 100% zu stellen.

Trotzdem muss man u. U. für die Restzeitkalkulation berücksichtigen dass jemand trotzdem fahrzeugseitig einen niedrigeren End-SoC gewählt hat.

[andig]

Ja, es macht bei EVCC absolut Sinn das Fahrzeug immer auf 100% zu stellen. Trotzdem muss man u. U. für die Restzeitkalkulation berücksichtigen dass jemand trotzdem fahrzeugseitig einen niedrigeren End-SoC gewählt hat.

Wie soll das denn funktionieren? Ich könnte ja z.b. im UI dann nicht mehr auf 100% gehen. Was mache ich wenn auf 70% limitiert, fürs UI aber nur 60 und 80 verfügbar? Aus meiner Sicht ist TargetSoC auf Userseite zu lösen, Restladezeit wäre eine Möglichkeit zu ergänzen.

Wir müssen die beiden Themen hier in der Diskussion sauber trennen!

[andig]

Hier gehts um Ladezeit vom API. Ist die besser als unsere Kalkulation?

[premultiply]

Ja.

[andig]

Wenn #310 gemerged ist wird es deutlich einfacher optionale Erweiterungen im Code einzubauen. Ich warte eigentlich nur auf Bestätigung am Beispiel EVSE ob das gut funktioniert.

[andig]

So, #310 ist drin. Welche Fahrzeuge bieten das und machen es besser als wir selbst?

[premultiply]

Ich fange mal an:
Renault
Hyundai/Kia

[andig]

Ich bräuchte jeweils den API Aufruf und die JSON Struktur, idealerweise einfach als PR gegen die entsprechende Datei. Einbinden kann ich es schnell ;)

[premultiply]

Renault:
Kommt schon im vorhandenen battery-status Abruf mit (chargingRemainingTime in Minuten).

{
    "data": {
        "type": "Car",
        "id": "VF1AG______",
        "attributes": {
            "timestamp": "2020-01-20T17:46:13+01:00",
            "batteryLevel": 97,
            "batteryTemperature": 4,
            "batteryAutonomy": 203,
            "batteryCapacity": 0,
            "batteryAvailableEnergy": 0,
            "plugStatus": 1,
            "chargingStatus": 1.0,
            "chargingRemainingTime": 90,
            "chargingInstantaneousPower": 4200.0
        }
    }
}

Achtung: Der Wert kann in der Antwort aber je nach Zustand aber auch fehlen. Dann Fallback auf EVCC-interne Schätzung.

[premultiply]

Denk bitte dran dass sich die RemainingTime auf den unter timestamp angegebenen Zeitpunkt bezieht. Also im Prinzip wird damit eine Enduhrzeit definiert. Dann nur noch schnell die aktuelle Zeit von der Enduhrzeit abziehen und schon hat man die aktuelle Restzeit.

[andig]

Denk bitte dran dass sich die RemainingTime auf den unter timestamp angegebenen Zeitpunkt bezieht.

Guter Hinweis- PR aktualisiert. Du kannst das gerne mittels evcc vehicle testen, die remaining time wird jetzt mit ausgegeben.

[premultiply]

Mist, wir verwenden hier ja noch Version 1 der battery-status-API.
Da heissen die Parameter noch timeRequiredToFullSlow und lastUpdateTime

https://api-wired-prod-1-euw1.wrd-aws.com/commerce/v1/accounts/____/kamereon/kca/car-adapter/v1/cars/VF1AG___/battery-status?country=DE

{
  "data": {
    "type": "Car",
    "id": "VF1AG___",
    "attributes": {
      "batteryLevel": 55,
      "rangeHvacOff": 140,
      "chargeStatus": 1,
      "lastUpdateTime": "2020-09-02T13:18:58+02:00",
      "plugStatus": 1,
      "chargePower": 1,
      "instantaneousPower": 900,
      "batteryTemperature": 16,
      "timeRequiredToFullSlow": 920
    }
  }
}

Wir müssen hier also noch auf API v2 umstellen!