Falscher SoC nach Anstecken an die Wallbox

[TheSpirit]

Hi. Wenn ich nach Hause komme und meinen BMW i3s an die Easee Home Wallbox anschließe, wird ja in der UI der SoC angezeigt. Dieser ist leider falsch. Problem ist, das BMW den SoC nur beim losfahren und stehen bleiben den SoC in der API aktualisiert. Jetzt vermute ich, das im Moment des Ansteckens ihr den SoC von der Api holt, dieser aber noch der alte SoC beim losfahren ist. Ich bin heute in der Arbeit mit 100% losgefahren und zu Hause mit 79% angekommen. Nach dem Anstecken zeigt evcc aber 100% an. Somit würde bei Sonnenschein am nächsten Tag kein PV-Laden beginnen. Anbei ein Screenshot vom Befehl evcc -vehicle und der UI.

evcc Version 0.70

interval: 10s # control cycle interval

# sponsor token enables optional features (request at https://cloud.evcc.io)
sponsortoken: xxx

# log settings
log: error
levels:
  core: debug
  lp-1: debug
  lp-2: debug

# meter definitions
# name can be freely chosen and is used as reference when assigning meters to site and loadpoints
# for examples see https://github.com/andig/evcc-config#meters
meters:
- name: grid
  type: custom
  power:
    source: mqtt
    topic: evcc/fueberschuss
    timeout: 30s
    scale: 1000
- name: pv
  type: custom
  power:
    source: mqtt
    topic: evcc/fprod
    timeout: 30s
    scale: 1000

# charger definitions
# name can be freely chosen and is used as reference when assigning charger to vehicle
# for examples see https://github.com/andig/evcc-config#chargers
chargers:
- name: charger
  type: easee
  user: xxx@gmail.com
  password: xxx
  charger: xxx
  cache: 10s

# vehicle definitions
# name can be freely chosen and is used as reference when assigning vehicle to loadpoint
# for examples see https://github.com/andig/evcc-config#vehicles
#vehicles:
#- name: renault
#  type: renault
#  title: Zoe
#  capacity: 60 # kWh
#  user: # user
#  password: # password
#  vin: WREN...
#  cache: 5m
vehicles:
- name: i3s
  type: bmw
  title: BMW i3s
  capacity: 42 # kWh
  user: xxx@gmail.com
  password: xxx
  vin: xxx
  cache: 5m

# site describes the EVU connection, PV and home battery
site:
  title: WuF # display name for UI
  meters:
    grid: grid # grid meter
    pv: pv # pv meter
#    battery: battery # battery meter
#  prioritySoC: 0 # give home battery priority up to this soc (0 to disable)

# loadpoint describes the charger, charge meter and connected vehicle
loadpoints:
- title: Garage # display name for UI
  charger: charger # charger
#  meters:
#    charge: charge # charge meter
  vehicle: i3s
  # vehicles: # use if multiple vehicles allowed to charge on this loadpoint
  # - ID.3
  # - e-Up
  mode: pv
  soc:
    # polling defines usage of the vehicle APIs
    # Modifying the default settings it NOT recommended. It MAY deplete your vehicle's battery
    # or lead to vehicle manufacturer banning you from API use. USE AT YOUR OWN RISK.
    poll:
      # poll mode defines under which condition the vehicle API is called:
      #   charging: update vehicle ONLY when charging (this is the recommended default)
      #   connected: update vehicle when connected (not only charging), interval defines how often
      #   always: always update vehicle regardless of connection state, interval defines how often
      mode: charging
      # poll interval defines how often the vehicle API may be polled if NOT charging
      interval: 60m
    min: 0 # immediately charge to 0% regardless of mode unless "off" (disabled)
    target: 100 # always charge to 100%
    estimate: true # set true to interpolate between api updates
  onDisconnect: # set defaults when vehicle disconnects
    mode: pv # switch back to pv mode
    targetSoC: 100 # charge to 100%
  phases: 3 # ev phases (default 3)
  enable: # pv mode enable behavior
    delay: 1m # threshold must be exceeded for this long
    threshold: 0 # minimum export power (W). If zero, export must exceed minimum charge power to enable
  disable: # pv mode disable behavior
    delay: 10m # threshold must be exceeded for this long
    threshold: 200 # maximum import power (W)
  guardduration: 5m # switch charger contactor not more often than this (default 10m)
  mincurrent: 6 # minimum charge current (default 6A)
  maxcurrent: 16 # maximum charge current (default 16A)

# mqtt message broker
mqtt:
  broker: 192.168.178.xxx:1883
  topic: evcc # root topic for publishing, set empty to disable
  user: xxx
  password: xxx

# influx database
influx:
  url: http://192.168.178.xxx:8086
  database: evcc
  user: xxx
  password: xxx

# push messages
messaging:
  events:
    start: # charge start event
      title: Charge started
      msg: Started charging in "${mode}" mode
    stop: # charge stop event
      title: Charge finished
      msg: Finished charging ${chargedEnergy:%.1fk}kWh in ${chargeDuration}.
    connect: # vehicle connect event
      title: Car connected
      msg: "Car connected at ${pvPower:%.1fk}kW PV"
    disconnect: # vehicle connected event
      title: Car disconnected
      msg: Car disconnected after ${connectedDuration}
  services:
  # - type: pushover
  #   app: # app id
  #   recipients:
  #   - # list of recipient ids
  # - type: telegram
  #   token: # bot id
  #   chats:
  #   - # list of chat ids
  # - type: email
  #   uri: smtp://<user>:<password>@<host>:<port>/?fromAddress=<from>&toAddresses=<to>```

[andig]

Kann irgendein bekanntes Tool das besser? Gibts ein Logfile?

[TheSpirit]

Naja, wenn ich etwa 5 Minuten nach dem anstecken des Autos den SoC per evcc -vehicle abfrage, stimmt der SoC ja, aber er wird nicht in der UI angezeigt und somit wohl auch nicht zum Start des PV Überschussladens herangezogen. Also kann evcc den richtigen Wert schon holen, aber im moment des Ansteckens ist er wohl noch falsch. Müsste mal testen, wie lange es dauert nach dem Anstecken, bis der "richtige" SoC vorhanden ist.

[andig]

Das könntest Du über poll mode connected lösen, ansonsten fehlt eine Idee, wie wir den Soc bewusst refreshen könnten. Alternativ: wir betrachten 100% beim Anstecken als ungültig und machen zeitlich begrenzten Retry bis was Anderes kommt.

[TheSpirit]

über den poll mode connected wollte ich nicht gehen, da hier ja sonst ein relative kleines Intervall gewählt werden muss, damit der SoC auch Zeitnah neu geholt wird. Möglich wäre natürlich auch zu deinem Vorschlag bis zu 3 Mal den SoC nach dem Anstecken innerhalb von z.B. 5 Minuten zu holen. Mit der Zeit müsste man spielen ob das reicht. Aber so hätte man Zeitnah den richtigen Wert ohne den poll mode connected zu nutzen was zu sicher mehr API anfragen führt.

[andig]

Naja, wenn ich etwa 5 Minuten nach dem anstecken des Autos den SoC per evcc -vehicle abfrage, stimmt der SoC ja, aber er wird nicht in der UI angezeigt und somit wohl auch nicht zum Start des PV Überschussladens herangezogen. Also kann evcc den richtigen Wert schon holen, aber im moment des Ansteckens ist er wohl noch falsch. Müsste mal testen, wie lange es dauert nach dem Anstecken, bis der "richtige" SoC vorhanden ist.

Natürlich nicht. Du hast ja auch konfiguriert dass das nicht passieren soll.

[TheSpirit]

das verstehe ich jetzt nicht ganz was du meinst