Easee Home - Übertragung Ladevorgänge fehlerhaft

[bit-driver]

Describe the bug

Ich habe ein Problem mit meiner Easee Home Wallbox

Während des Ladevorgangs wird die geladene Energie zwischen EVCC und Wallbox synchronisiert und "richtig" (analog zur App) angezeigt.
Nach dem beenden des Ladevorgangs wird dieser Wert auch in die Ladehistorie übertragen.
Wenn nun die Verbindung zum Fahrzeug getrennt wird scheint die Wallbox den Verbrauch noch einmal zu aktualisieren.
Dieser aktualisierte Wert wird nicht mehr in die Ladehistorie übernommen (Ladevorgang ist schon beendet)

Hier scheint es ein geändertes Verhalten seitens Easee zu geben.

Beispiel:
Fahrzeug geladen. EVCC und Easee App zeigen 15,3kwh an
Fahrzeug getrennt: 15,3kwh werden als geladen übertragen. Anzeige in der Easee App springt auf 16,2kwh

Folgende Werte stehen in den EVCC Details. Demnach müssten 15,9kwh geladen worden sein.
Anfangszählerstand | 560,4 kWh
Endzählerstand | 576,3 kWh

Teilweise, aber nicht immer, gibt es auch Inkosistenzen zwischen End- und Anfangszählerstand des nächsten Ladevorgangs.

Steps to reproduce

1. Ladevorgang durchführen
2. Verbindung zum Fahrzeug trennen
3. Geladene Energie wird nicht korrekt übertragen bzw. durch Cloud nocheinmal korrigiert.

Configuration details

sponsortoken: xxxxx
plant: xxxxx

network:
  # schema is the HTTP schema
  # setting to `https` does not enable https, it only changes the way URLs are generated
  schema: http
  # host is the hostname or IP address
  # if the host name contains a `.local` suffix, the name will be announced on MDNS
  # docker: MDNS announcements don't work. host must be set to the docker host's name.
  host: evcc.local
  # port is the listening port for UI and api
  # evcc will listen on all available interfaces
  port: 7070

interval: 10s # control cycle interval

# database configuration for persisting charge sessions and settings
# database:
#   type: sqlite
#   dsn: <path-to-db-file>

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

# telemetry enables aggregated statistics
#
# Telemetry allows collecting usage data (grid and green energy, charge power).
# Data is aggregated, no individual charging sessions are tracked. The collected,
# anonymous data can be retrieved using https://api.evcc.io.
#
# See https://github.com/evcc-io/evcc/pull/4343 or details.
#
# For time being, this is only available to sponsors, hence data is associated with
# the sponsor token's identity.
#
# telemetry: true

# log settings
log: info
levels:
  site: warn
  lp-1: warn
  lp-2: warn
  cache: error
  db: error

# modbus proxy for allowing external programs to reuse the evcc modbus connection
# each entry will start a proxy instance at the given port speaking Modbus TCP and
# relaying to the given modbus downstream device (either TCP or RTU, RS485 or TCP)
modbusproxy:
  #  - port: 5200
  #    uri: solar-edge:502
  #    # rtu: true
  #    # readonly: true

# meter definitions
# name can be freely chosen and is used as reference when assigning meters to site and loadpoints
# for documentation see https://docs.evcc.io/docs/devices/meters
meters:
  - name: mygrid
    type: template
    template: sungrow-hybrid
    usage: grid      
     
    # Modbus TCP
    modbus: tcpip
    id: 1
    host: 192.168.2.69 # Hostname
    port: 502 # Port 
    
  - name: mypv
    type: template
    template: sungrow-hybrid
    usage: pv      
     
    # Modbus TCP
    modbus: tcpip
    id: 1
    host: 192.168.2.69 # Hostname
    port: 502 # Port 
       
  - name: mybattery
    type: template
    template: sungrow-hybrid
    usage: battery      
    capacity: 9.6
     
    # Modbus TCP
    modbus: tcpip
    id: 1
    host: 192.168.2.69 # Hostname
    port: 502 # Port 
       
    
    
    
    
# charger definitions
# name can be freely chosen and is used as reference when assigning charger to vehicle
# for documentation see https://docs.evcc.io/docs/devices/chargers
chargers:
  - name: mycharger
    type: template
    template: easee
    user: +xxxxx
    password: xxxxx
    charger: xxxxx

# vehicle definitions
# name can be freely chosen and is used as reference when assigning vehicle to loadpoint
# for documentation see https://docs.evcc.io/docs/devices/vehicles
vehicles:
  - name: mycar
    type: template
    template: vw
    title: e-up! # Wird in der Benutzeroberfläche angezeigt # Optional
    user: xxxxx # Benutzerkonto (bspw. E-Mail Adresse, User Id, etc.)
    password: xxxxx# Passwort des Benutzerkontos (bei führenden Nullen bitte in einfache Hochkommata setzen)
    vin: xxxxx # Erforderlich, wenn mehrere Fahrzeuge des Herstellers vorhanden sind # Optional
    capacity: 32.2 # Akkukapazität in kWh # Optional 
    phases: 2
    targetSoc: 80

# site describes the EVU connection, PV and home battery
site:
  title: Home # display name for UI
  meters:
    grid: mygrid # grid meter
    pvs: mypv # list of pv inverters/ meters
    battery: mybattery # battery meter
  prioritySoc: 70 # give home battery priority up to this soc (empty to disable)
  bufferSoc: 80 # ignore home battery discharge above soc (empty to disable)
  residualPower: 100

# loadpoint describes the charger, charge meter and connected vehicle
loadpoints:
  - title: Carport # display name for UI
    charger: mycharger # charger
    meter: # charge meter
    mode: pv # set default charge mode, use "off" to disable by default if charger is publicly available
    vehicle: mycar # set default vehicle (disables vehicle detection)
    resetOnDisconnect: true # set defaults when vehicle disconnects
    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 (only supported for single vehicle)
        mode: charging
        # poll interval defines how often the vehicle API may be polled if NOT charging
        interval: 60m
      estimate: true # set false to disable interpolating between api updates (not recommended)
    phases: 0 # electrical connection (normal charger: default 3 for 3 phase, 1p3p charger: 0 for "auto" or 1/3 for fixed phases)
    enable: # pv mode enable behavior
      delay: 1m # threshold must be exceeded for this long
      threshold: 0 # grid power threshold (in Watts, negative=export). If zero, export must exceed minimum charge power to enable
    disable: # pv mode disable behavior
      delay: 3m # threshold must be exceeded for this long
      threshold: 0 # maximum import power (W)
    guardDuration: 5m # switch charger contactor not more often than this (default 5m)
    minCurrent: 6 # minimum charge current (default 6A)
    maxCurrent: 16 # maximum charge current (default 16A)

# tariffs are the fixed or variable tariffs
# cheap (tibber/awattar) can be used to define a tariff rate considered cheap enough for charging
tariffs:
  currency: EUR # three letter ISO-4217 currency code (default EUR)
  grid:
    # either static grid price (or price zones)
    type: fixed
    price: 0.3085 # EUR/kWh
    #zones:
    #  - days: Mo-Fr
    #    hours: 2-5
    #    price: 0.2 # EUR/kWh
    #  - days: Sa,So
    #    price: 0.15 # EUR/kWh

    # # or variable via tibber
    # type: tibber
    # cheap: 0.2 # EUR/kWh
    # token: "476c477d8a039529478ebd690d35ddd80e3308ffc49b59c65b142321aee963a4" # access token
    # homeid: "cc83e83e-8cbf-4595-9bf7-c3cf192f7d9c" # optional if multiple homes associated to account

    # # or variable via awattar
    # type: awattar
    # cheap: 0.2 # EUR/kWh
    # region: de # optional, choose at for Austria
  feedin:
    # rate for feeding excess (pv) energy to the grid
    type: fixed
    price: 0.082 # EUR/kWh
  planner:
    # planner tariff can be used for target charging if not grid tariff is specified
    # GrünStromIndex (Germany only) or ElectricityMaps provide CO2 intensity forecast

    # type: grünstromindex
    # zip: <zip>

    # type: electricitymaps
    # uri: <uri>
    # token: <token>
    # zone: DE

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

# influx database
influx:
  # url: http://localhost:8086
  # database: evcc
  # user:
  # password:

# eebus credentials
eebus:
  # uri: # :4712
  # interfaces: # limit eebus to specific network interfaces
  # - en0
  # certificate: # local signed certificate, required, can be generated via `evcc eebus-cert`
  #   public: # public key
  #   private: # private key

# 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}
#    soc: # vehicle soc update event
#      title: Soc updated
#      msg: Battery charged to ${vehicleSoc:%.0f}%
#    guest: # vehicle could not be identified
#      title: Unknown vehicle
#      msg: Unknown vehicle, guest connected?
  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>
  # - type: ntfy
  #   uri: https://<host>/<topics>
  #   priority: <priority>
  #   tags: <tags>

Log details

wird bei bedarf nachgereicht

What type of operating system are you running?

Docker container

Version

0.115.0

[andig]

Welchen Wert zeigt evcc denn in Deinem Szenario im Ladelog?

[bit-driver]

Auf der Hauptseite stand bis zum trennen der Verbindung zum Fahrzeug 15,3kwh. Diese sind auch im ladelog gespeichert.
Danach ist die Anzeige auf der Hauptseite irgendwann auf 16,2kwh gesprungen. (Nachdem auch der Wert in der easee App aktualisiert wurde)
Im Log bleibt es bei 15,3kwh

[andig]

Im Log bleibt es bei 15,3kwh

D.h. die 15,4 im Log passen auch nicht zu den Zählerständen im Log? Das ist schonmal schlecht!

Jetzt wäre nochmal ein Log hilfreich:

--log debug,easee:trace,db:trace

Von Start Ladung bis Abstecken und dann solange bis evcc die Hauptseite aktualisiert hat.

[bit-driver]

Anbei der Log.
Im Ladelog sind die 1,1 kwh von der ersten Aktualisierung der Wallbox (09:59:38) abgelegt. Der Wert auf der Hauptseite wurde anschließend auf 2,2kwh aktualisiert
log_easee.txt

[andig]

Ich denke ich verstehe das Problem. Ist aber doof:

[easee ] TRACE 2023/04/06 09:17:40 ProductUpdate EHAHJFZB: LIFETIME_ENERGY 576.6751313888892
[easee ] TRACE 2023/04/06 09:59:38 ProductUpdate EHAHJFZB: SESSION_ENERGY 1.067615032196045
[easee ] TRACE 2023/04/06 10:11:51 ProductUpdate EHAHJFZB: LIFETIME_ENERGY 577.7575702777781
[easee ] TRACE 2023/04/06 10:28:16 ProductUpdate EHAHJFZB: SESSION_ENERGY 2.1753227710723877
[db    ] TRACE 2023/04/06 10:28:17 UPDATE `sessions` SET `created`="2023-04-06 09:29:37.541",`finished`="2023-04-06 10:28:17.467",`loadpoint`="Carport",`identifier`="04680A72496580",`vehicle`="e-up!",`odometer`=3741.000000,`meter_start_kwh`=576.675131,`meter_end_kwh`=577.757570,`charged_kwh`=1.082439 WHERE `id` = 1 1 <nil>

Dann passiert:

chargedEnergy := lp.getChargedEnergy() / 1e3
if delta := lp.session.MeterStop - lp.session.MeterStart; delta < chargedEnergy && lp.session.MeterStart*lp.session.MeterStop > 0 {
	chargedEnergy = delta
}

für die Charger die es nicht schaffen, ihre Sessionenergie sinnvoll zurück zu setzen (#5696 und #6197).

Das ist maximal unglücklich, aber ich hab keine Idee, wir das aufzulösen wäre?

/cc @SirkoVZ @foto-andreas schlimmstenfalls müssen wir das zurück bauen :(

PS.: In jeden Fall bleibt aber, dass die Zählerstände bei der Easee nicht zur geladenen Energie passen...

[HeikoH78]

Könntest du nicht in die db die letzte LIFETIME_ENERGY plus die Menge an Energie der letzten Session reinschreiben lassen?
Beim nächsten Ladevorgang müsste die Easee die LIFETIME_ENERGY doch zusammengeführt melden, oder?

[andig]

Siehe #5696 (comment):

Seit #6940 wird eine Sessionenergie>0 beim Neustart ignoriert.

Damit kann die chargedEnergy() auch wieder direkt verwendet werden ohne mit den Zählerständen Workarounds bauen zu müssen.