Ladestand Kia Niro

[sosarasp]

Describe the bug

Hallo,

Seit dem Update auf 0.130.0 bis 0.130.13 wird der aktuelle Ladestand vom Kia Niro nicht mehr angezeigt. Bis 0129.0 hat das immer funktioniert. Jetzt wird nur noch der geladene Anteil angezeigt. Unter Konfiguration wird bei Fahrzeug SoC der richtige Wert angezeigt. Wahrscheinlich selbe Ursache wie Issue #15561

Steps to reproduce

Update von 0.129.0 auf 0.130.0 bis 0.130.13

Configuration details

chargers:
- name: Wallbox_Hof
  type: template
  template: ocpp
  stationid: 10383320
  remotestart: true
  
vehicles:
- name: Kia_Sonja
  type: template
  template: kia
  title: Kia_Sonja
  user: xxx
  password: xxx
  vin: xxx
  capacity: 64
  language: de
  icon: car
  phases: 3
  cache: 30m
  mode: OFF
  minCurrent: 6 
  maxCurrent: 16
  # Kann meist erst später eingetragen werden, siehe: https://docs.evcc.io/docs/features/vehicle (optional)

    
loadpoints:
- title: Hof
  charger: Wallbox_Hof
  vehicle: Kia_Sonja
  mode: off
  phases: 0
  mincurrent: 6
  maxcurrent: 16
  enable:
    threshold: 0
    delay: 1m
  disable:
    threshold: -100 # maximum import power (W)
    delay: 3m
  guardduration: 1m
  priority: 1
  soc:
    poll:
      mode: connected
      # mode: always
      interval: 30m
    estimate: true

Log details

Soc:           65%
Capacity:      64.0kWh
Charge status: C
Range:         293km
Odometer:      13816km
Finish time:   2024-10-13 21:56:00 +0200 CEST
Position:      50.081714,9.248683
Limit Soc:     100%
OnIdentified:  Mode:off, MinCurrent:6, MaxCurrent:16

What type of operating system are you running?

Linux

Nightly build

• I have verified that the issue is reproducible with the latest nightly build

Version

evcc version 0.130.13 (01c2d97)

[sosarasp]

Hier noch das Trace Log
evcc-20241013-143117-trace.log

[VolkerK62]

Die Info ist jedenfalls da
[kia ] TRACE 2024/10/13 14:08:41 ...

 "evStatus": {
                    "batteryCharge": true,
                    "batteryStatus": 62,
                    "batteryPlugin": 2, 

Ich hab mit meinem Hyundai keine Probleme.
Ich habe aber auch kein soc.poll und kein cache konfiguriert.

[sosarasp]

Ja, die Info habe ich auch gesehen.
soc.poll und cache habe ich auch schon rausgenommen, jedoch ohne Erfolg.
Sonst noch eine Idee?

[VolkerK62]

@andig Ich hab mal etwas ausprobiert. Hilft evtl. weiter.
Auszüge aus /api/state

Fahrzeug nicht verbunden und nicht am Loadpoint ausgewählt

Fahrzeug nicht verbunden, aber am Loadpoint ausgewählt

Fahrzeug verbunden und automatisch erkannt

@sosarasp
nimm mal den vehicle Eintrag aus dem Loadpoint. (den hab ich auch nicht).
Dann sollte nach den anstecken der Soc angezeigt werden.

[sosarasp]

@VolkerK62
auch den vehicle Eintrag aus dem Loadpoint zu nehmen hat leider nichts gebracht.

[VolkerK62]

und das Auto wird automatisch erkannt?

[sosarasp]

Ja, Auto wird erkannt.

[VolkerK62]

Hast du mal ein trace Log wo das Anstecken des Fahrzeug mit drin ist.

[sosarasp]

evcc-20241013-202921-trace.log.txt
Hier das Trace Log von Start bis Auto eingesteckt. Erst Gastfahrzeug, dann der Kia. Keine Ladung gestartet.
Jetzt wird auf der Ui aber ein Ladestand von 100% gezeigt und eine Lademenge von 2,2 MWh. Tatsächlich ist der Ladestand aber bei 70%.

[VolkerK62]

Keine Ahnung, ob das mit dem eigentümlichen Ansteck-Verhalten der Wallbox zu tun hat.
Da kommen einige timeouts vom Wallbox-Meter.
Und dann das:
[lp-1 ] ERROR 2024/10/13 20:26:43 vehicle soc: timeout

Die 100% sind hochgerechnet, da (angeblich) in kürzester Zeit eine riesige Menge geladen wurde.
[lp-1 ] DEBUG 2024/10/13 20:27:02 soc estimated: 100.00% (vehicle: 0.00%)

[sosarasp]

Heute Morgen hatte ich das Auto nochmal getrennt und wieder neu verbunden. Danach wurde der Ladestand wieder nicht angezeigt.
LOG
[lp-1  ] INFO 2024/10/14 06:38:10 vehicle updated: unknown -> Kia_Sonja
[lp-1  ] DEBUG 2024/10/14 06:38:10 set charge mode: off
[lp-1  ] DEBUG 2024/10/14 06:38:10 soc estimated: 0.00% (vehicle: 0.00%)
[lp-1  ] DEBUG 2024/10/14 06:38:10 vehicle soc: 0%
[kia   ] TRACE 2024/10/14 06:38:10 GET https://prd.eu-ccapi.kia.com:8080/api/v1/spa/vehicles/24623c6a-e547-4518-9493-95c2745a0c35/status/latest

Hier noch das vollständige Trace Log.
evcc-20241014-064100-trace.log.txt

Wenn ich es aber richtig verstehe, wird der aktuelle Ladestand nicht erkannt , da wo 100% angezeigt wurde, war es ja der estimate.
Die Frage die ich mir Stelle, soll der Soc durch den Charger bereitgestellt werden, also ausgelesen werden oder wird dieser über die Kia Api bereitgestellt?
Wurde bei diesen OCPP Charger oder Kia Api etwas geändert in Bezug auf den Vihcle SoC zur Version 0.129.0.
Wallbox ist eine StarCharge Aurora 11KW ( wird auch von Enpal teilweise verbaut)
Wenn es am Charger liegt, wäre es möglich hier ein geändertes Template zur Verfügung zu stellen?

[VolkerK62]

Das ab- und wieder anstecken war zu schnell.

Soc über Charger vermute ich mal eher nicht. Da gibt es nur ganz weniger Wallbox/Auto Kombinationen, die das können.
Es gab mit 0.130.0 jede Menge Änderungen bei OCPP.

Was mich wundert, das Auto meldet, dass es nicht verbunden ist
"batteryPlugin": 0,
(und die andere Erkennungsart (offene Ladeklappe) ist in deiner Fahrzeugabfrage nicht enthalten)
trotzdem wird es offensichtlich "erkannt"
[lp-1 ] INFO 2024/10/14 06:16:07 vehicle updated: unknown -> Kia_Sonja
allerdings kommt kein Fahrzeugstatus.
Keine Ahnung, wie das funktioniert.

Das muss jemand ergründen, der tiefer drin steckt.

[andig]

Was mich wundert, das Auto meldet, dass es nicht verbunden ist

Fahrzeuge melden immer irgendwas- einfach ignorieren.

wird der aktuelle Ladestand vom Kia Niro nicht mehr angezeigt. ... Jetzt wird nur noch der geladene Anteil angezeigt.

Mir ist völlig unklar, was damit gemeint sein kann. Screenshot zeigt den SoC ja.

[sosarasp]

Mir ist völlig unklar, was damit gemeint sein kann. Screenshot zeigt den SoC ja.

Die % Angabe ist aber nur der aktuell hinzugeladene Teil siehe Issue Eröffnung hier werden 11% angezeigt, in der Konfiguration unter Fahrzeug wird der richtige Wert 63% angezeigt.

evcc-20241013-202921-trace.log.txt Hier das Trace Log von Start bis Auto eingesteckt. Erst Gastfahrzeug, dann der Kia. Keine Ladung gestartet. Jetzt wird auf der Ui aber ein Ladestand von 100% gezeigt und eine Lademenge von 2,2 MWh. Tatsächlich ist der Ladestand aber bei 70%.

Die hier angezeigten 100% stimmen ebenfalls nicht, tatsächlich lag der prozentuale SoC bei ca. 70%. Die angezeigten 100% kamen durch einen anderen Fehler. Ein Gastfahrzeug wurde mit 2,2 MWh angegeben. Gastfahrzeug wurde keins angesteckt oder geladen, sondern nur der Kia und das waren vielleicht ehr 2,2 KWh, also Kommafehler. Nach dem Ab und wieder Anstecken war dieser Fehler auch wieder weg, aber der Prozentuale SoC wird wieder nicht angezeigt.

[VolkerK62]

@sosarasp zur Eingrenzung: wenn du auf 0.129.0 zurückgehst, funktioniert es und ab 0.130.0 nicht mehr?

[sosarasp]

Bei Issue Erstellung hatte ich evcc vehicle ausgeführt. Die Abweichung 63% (aus Konfiguration) zu 65% (evcc vehicle) ist dem zeitlichen Abstand zwischen der Erstellung der Screenshots geschuldet.

evcc vehicle :

Soc: 65%
Capacity: 64.0kWh
Charge status: C
Range: 293km
Odometer: 13816km
Finish time: 2024-10-13 21:56:00 +0200 CEST
Position: 50.081714,9.248683
Limit Soc: 100%
OnIdentified: Mode:off, MinCurrent:6, MaxCurrent:16

Also evcc vehicle gibt den richtigen Wert aus.

[mfuchs1984]

Grund für die 100%:

Im initialen trace log sieht man, dass die metervalues zu alt sind, es schlägt isMeterTimeout zu

evcc/charger/ocpp/connector.go

Line 167 in 57aba0d

func (conn *Connector) isMeterTimeout() bool {

Zwei Sekunden vorher (20:26:41) wird zwar eine meterValues Nachricht empfangen, die Messwerte sind aber von 20:26:08, also schon mehr etwa 33 Sekunden alt.
Dadurch wird als Ladestart meter_start_kwh=NULL in die DB geschrieben. Bei Beendigung des Ladevorgangs gibt es wieder aktuelle Messwerte, und evcc nimmt den aktuellen minus NULL. Das ergibt 2230,93 geladene kWh und der estimator macht daraus 100%.

Habe jetzt auf die schnelle nicht herausgefunden, ob man das timeout im template verlängern kann, definiert ist es hier als "default request / response timeout on protocol level", wird hier aber als Meter timeout verwendet

evcc/charger/ocpp/const.go

Line 5 in 57aba0d

var Timeout = 30 * time.Second // default request / response timeout on protocol level

Zudem ist das timout in ocpp.go als deprecated markiert.

[mfuchs1984]

Kleine Auffälligkeit:

Man sieht im Log viele mehrfache MeterValues requests. Eine davon ist durch ein echtes timeout bedingt, der Rest durch das Verhalten von

evcc/charger/ocpp/connector.go

Line 84 in 57aba0d

func (conn *Connector) WatchDog(timeout time.Duration) {

Der watchdog bekommt ein timeout von 10 Sekunden, wenn diese überschritten sind, sendet er einen neuen MeterValues requests. Allerdings sendet er diesen mehrfach ab, wenn nicht innerhalb von 2 Sekunden eine Antwort kommt. Braucht eine wallbox also 8 Sekunden, um auf den ersten request zu antworten, bekommt sie 3 weitere requests im Abstand von 2 Sekunden bis zur Antwort. Keine Ahnung ob das so beabsichtigt ist, ich finde es jedenfalls ungewöhnlich.

[mfuchs1984]

Beim vehicle SoC gibt es auch einen timeout Error, und zwar bevor die API überhaupt gefragt wurde. Das liegt meines Erachtens auch am Meter timeout: estimator.go Funktion Soc fragt erst den charger. Da Soc in den metervalues vom charger verfügbar ist (0, vermutlich weil kein smart vehicle), wird er erst dort abgefragt. Durch das Meter timeout kommt ErrTimeout raus

evcc/charger/ocpp/connector.go

Line 308 in 57aba0d

return 0, api.ErrTimeout

Das führt meines Erachtens dazu, das die Funktion Soc im estimator direkt mit dem timeout rausspringt, ohne beim vehicle nachzufragen.

evcc/core/soc/estimator.go

Line 118 in 57aba0d

return 0, err

[mfuchs1984]

Die veralteten MeterValues tauchen übrigens im Log nur in dem Moment auf, in dem das Fahrzeug angesteckt und eine Transaction gestartet wird. Sieht aus als würde die wallbox da das sampling pausieren bzw. anders ausgelastet sein (in dem Moment antwortet sie auch einmal nicht auf einen MeterValues requests). Davor und danach sind sie jeweils nur 2 Sekunden alt.

[mfuchs1984]

evcc/core/soc/estimator.go

Line 113 in 57aba0d

// if the charger does or could provide Soc, we always use it instead of using the vehicle API

Diese Annahme führt hier m.E. zu einem Problem, unabhängig vom timeout. Der charger kann laut seiner Angaben grundsätzlich SoC, das Fahrzeug jedoch nicht. Deshalb kommt wohl immer 0 raus. Im der ocpp Spec finde ich auf den ersten Blick nichts, was das Verhalten in diesem Fall definiert.

[andig]

Arrgh, das ist doof. Sehen wir im Log, ob/was er da liefert?

[mfuchs1984]

Dieser charger liefert laut log 0

[2,"FnEIGQaBbfq8xmEKuXhWpw2JyKa2porrPqtQ","MeterValues",{ "connectorId": 1, "transactionId": 1728843888, "meterValue": [ { "timestamp": "2024-10-13T18:26:48.000Z", "sampledValue": [ {"value": "236.1", "context": "Sample.Periodic", "measurand": "Voltage", "location": "Outlet", "unit": "V", "phase": "L1"},{"value": "237.5", "context": "Sample.Periodic", "measurand": "Voltage", "location": "Outlet", "unit": "V", "phase": "L2"},{"value": "236.8", "context": "Sample.Periodic", "measurand": "Voltage", "location": "Outlet", "unit": "V", "phase": "L3"},{"value": "0.01", "context": "Sample.Periodic", "measurand": "Current.Import", "location": "Outlet", "unit": "A", "phase": "L1"},{"value": "0.00", "context": "Sample.Periodic", "measurand": "Current.Import", "location": "Outlet", "unit": "A", "phase": "L2"},{"value": "0.00", "context": "Sample.Periodic", "measurand": "Current.Import", "location": "Outlet", "unit": "A", "phase": "L3"},{ "value": "2", "context": "Sample.Periodic", "measurand": "Power.Active.Import","location": "Outlet", "unit": "W" },{ "value": "0", "context": "Sample.Periodic", "measurand": "SoC","location": "EV", "unit": "Percent" },{ "value": "0", "context": "Sample.Periodic", "measurand": "Power.Offered","location": "Outlet", "unit": "W" },{ "value": "0.00", "context": "Sample.Periodic", "measurand": "Current.Offered","location": "Outlet", "unit": "A" },{ "value": "2230930", "context": "Sample.Periodic", "measurand": "Energy.Active.Import.Register","location": "Outlet", "unit": "Wh" } ] } ] }]

[andig]

Das ist dann gelogen... deshalb bitte:

metervalues: -SoC

Alternativ könnten wir bei OCPP einen soc=0 immer als ungültig betrachten (obwohl es den natürlich real geben kann...)

/cc @premultiply

[mfuchs1984]

Und dann wäre das nächste Problem hier das 30 Sekunden timeout, weil der charger nach dem anstecken zumindest im ersten logfile zunächst Werte liefert, die 33 Sekunden alt sind. Siehe #16633 (comment) und #16633 (comment)

[mfuchs1984]

metervalues: -SoC

@sosarasp füge das mal deiner charger Konfiguration hinzu und mach ein neues trace Log vom Start + Ansteckvorgang.

[sosarasp]

Hallo zusammen, anbei das Trace Log von Start + Anstecken und Ladebeginn mit der geänderten charger Konfiguration

chargers:

• name: Wallbox_Hof
  type: template
  template: ocpp
  stationid: 10383320
  remotestart: true
  metervalues: -SoC

evcc-20241015-201504-trace.log

Das hinzufügen von:

metervalues: -SoC

war erfolgreich, jetzt wird der Ladestand in % wieder angezeigt.

Vielen Dank für die tolle Arbeit und der schnellen Bearbeitung.

Ein super Projekt.

Was mir noch aufgefallen ist , dass sobald ich das Fahrzeug anstecke, der Ladevorgang gestartet wird und dann auch sofort wieder gestoppt wird.
Stop wahrscheinlich weil im Loadpoint "mode: off" konfiguriert ist, aber warum wird überhaupt gestartet?

[mfuchs1984]

Aus den logs heraus würde ich sagen:

1. Wallbox meldet Auto angesteckt
2. Evcc startet eine Transaktion (remotestart)
3. Das veranlasst die Wallbox dazu, zu starten (mit dem Default Profile)
4. Dann stoppt evcc den Ladevorgang durch ein neues Profile mit Limit 0 wieder

[sosarasp]

Ok.
Den Remotestart Befehl habe ich mal rausgenommen und die Wallbox auf local PnC. Dann gibt es keinen autostart. Aber als Massage kommt nur die Meldung Fahrzeug angeschlossen, da der Kia bei generieren der Massage noch nicht den Kia erkannt hat. Das dauert halt vielleicht ca. 20 sec.
Wäre hilfreich wenn es die Möglichkeit gibt, die Massage um diese Zeit (bis Fahrzeugerkennung erfolgt ist) zu verzögern.
Hierzu das Trace Log
evcc-20241016-061438-trace.log

[mfuchs1984]

Verzögerungen sind normal. Das Log sieht gut aus.

[sosarasp]

Das die Verzögerung vorhanden ist, ist verständlich und auch ok. Kann man da aber eine Verzögerung der Meldung/Massage "Fahrzeug ... angeschlossen einstellen?

[VolkerK62]

Wenn ein Fahrzeug angesteckt wird, startet die automatische Erkennung. Je nach Fahrzeug-API dauert das etwas.
Keine Ahnung, wie lange dafür der timeout ist, bis (bei Nicht-Erkennung) endgültig "Gastfahrzeug" angezeigt wird.
Solange wäre dann nciht erkennbar, dass überhaupt ein Fahrzeug angesteckt wurde.