Keine Überschussladung im Zusammenhang mit Hausbatterie

Describe the bug

Mir ist aufgefallen, dass evcc nicht mehr mit der Überschussladung startet (Version 0.87). Nachdem die Hausbatterie ihren vorgegebenen Ladestand erreicht hat, wird zwar der Überschuss erkannt, der Timer startet, jedoch resetet er sich immer wieder obwohl sich an der Überschusssituation nichts geändert hat. Das letzte Mal habe ich letztes Jahr eine erfolgreiche Ladung gehabt. Es müsste die Version 0.65 gewesen sein. Diese Version habe ich auch nochmal installiert und dort ist dieses Verhalten nicht zu beobachten.

Interessant wäre vielleicht noch zu erwähnen, dass die Wallbox nur 1-phasig angeschlossen ist.

Steps to reproduce

Configuration details

uri: 0.0.0.0:7070 # uri for ui
interval: 10s # control cycle interval

sponsortoken: 

# 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 # grid power
  type: custom
  power:
    source: modbus
    model: sunspec
    uri: 10.0.100.101:502
    id: 1
    subdevice: 1 # Metering device
    value: 203:W #
    scale: -1
- name: pv # pv power calculated from DC string and battery charge power
  type: custom
  power:
    source: calc
    add:
    - source: modbus
      model: sunspec
      uri: 10.0.100.101:502
      id: 1
      value: 103:DCW # SunSpec Model 103 DCW
    - source: modbus
      uri: 10.0.100.101:502
      id: 1
      register:
        address: 62836 # Battery 1 Instantaneous Power
        type: holding
        decode: float32s
- name: battery # battery charge/discharge power and SoC
  type: custom
  power:
    source: modbus
    uri: 10.0.100.101:502
    id: 1
    register:
      address: 62836 # Battery 1 Instantaneous Power
      type: holding
      decode: float32s
    scale: -1
  soc:
    source: modbus
    uri: 10.0.100.101:502
    id: 1
    register:
      address: 62852 # Battery 1 State of Energy (SOE)
      type: holding
      decode: float32s

# 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: easee_1
  type: easee
  user:
  password: 
  charger:

# 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: bmw
  type: bmw
  title: BMW
  capacity: 38 # kWh
  user: 
  password: 
  vin: 

# site describes the EVU connection, PV and home battery
site:
  title: Home # display name for UI
  meters:
    grid: grid # grid meter
    pv: pv # pv meter
    battery: battery # battery meter
  prioritySoC: 70 # 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: easee_1 # charger
  # meters:
  #   charge: easee # charge meter
  vehicle: bmw
  # vehicles: # use if multiple vehicles allowed to charge on this loadpoint
  # - ID.3
  # - e-Up
  mode: pv
  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
      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 (true or false)
  phases: 1 # 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: 100 # maximum import power (W)
  guardduration: 10m # switch charger contactor not more often than this (default 10m)
  mincurrent: 6 # minimum charge current (default 6A)
  maxcurrent: 13 # 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
    type: fixed
    price: 0.27 # 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.08 # EUR/kWh

# 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:

# 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>

Log details

Hier die Logs von Version 0.87 und 0.65 evcc065.txt evcc087.txt

Version 0.87

What type of operating system are you running?

Linux

Version

0.87

Ja aber mit dem Fix für dieses Problem müssen jetzt alle schauen was sie konfigurieren müssen.

Es muss niemand etwas konfigurieren, es sei denn er hat das Ursprungsproblem von @ttjaden. Genau wie vorher. Die Änderung ist nicht-invasiv.

Ja aber mit dem Fix für dieses Problem müssen jetzt alle schauen was sie konfigurieren müssen.

Es muss niemand etwas konfigurieren, es sei denn er hat das Ursprungsproblem von @ttjaden. Genau wie vorher. Die Änderung ist nicht-invasiv.

also wenn man den Parameter nicht nutzt dann ist es wie früher und die Batterie wird nie auf 0 gesetzt wenn er Strom aus dem Netz zieht?

aber wenn man ihn braucht heißt es doch das er es erstmal versucht und jedes mal in diesen Fehler läuft und wieder runter regeln muss bis er wieder >0W einspeist und dann wieder die Batterie mit einberechnet und wieder die Wallbox hochschraubt und so weiter. Oder hab ich da was falsch verstanden?

Ja aber mit dem Fix für dieses Problem müssen jetzt alle schauen was sie konfigurieren müssen.

Es muss niemand etwas konfigurieren, es sei denn er hat das Ursprungsproblem von @ttjaden. Genau wie vorher. Die Änderung ist nicht-invasiv.

Dem muss ich widersprechen @andig. Die Änderung, die ihr für @ttjaden seinerzeit eingeführt hattet, hat bei mir dazu geführt, dass es nicht mehr funktionierte, weil ein kleiner Netzbezug, die Batterie auf null gesetzt hat und somit nicht mehr genug Überschuss vorhanden war um die Ladung zu starten. Mit der Änderung grid > 50 Wurde es bei mir besser, muss den Wert aber noch weiter nach oben anpassen. Durch die Variable die ihr nun eingeführt habt lässt sich das natürlich leicht machen, so ganz nicht-invasiv sehe ich das jedoch nicht an. du hast recht, das Problem von @ttjaden kam erst einmal in zwei Jahren vor. Mein Problem jedoch kam durch die Änderung. Vielleicht ist mein SolarEdge WR mit seinem Meter aber auch zu träge - dazu kann ich natürlich nichts sagen weil es meiner erste PV Anlage ist :D Wie auch immer, dir @andig und dem ganzen Team hinter evcc vielen Dank für die tolle Arbeit!

Wichtig ist in jedem Fall, dass wir das nachhaltig und robust lösen. Zudem soll nicht der Eindruck entstehen, dass ich der einzige mit dem Problem bin. Ich bin wohl anscheinend nur der erste, dem die Herausforderung aufgefallen ist. Betroffen sind bestimmt mehrere Personen mit Hybrid-WR. Zukünftig wird das noch mehr:

Im Residential-Bereich wird der Hybrid-WR zur Standard-Lösung
Aus Kosten/Nutzen-Sicht hat man früher schon Wechselrichter kleiner als den Generator ausgelegt. Dies kommt nun auch wieder verstärkt vor
- weil die Hybrid-WR relativ teuer sind
- und weil sie größtenteils nur bis 10 kVA zur Verfügung stehen und dann gerne mal mit größeren PV-Anlagen versehen werden. Gerade bei Ost-West-Anlagen kann man gut 16 kWp die Geräte hängen.

Kurzer Exkurs: Und was SolarEdge oder auch Senec und Co. betrifft: Leider scheuen sich solche Hersteller im Gegensatz zu anderen (Kostal, Fronius, RCT, etc) vor der Teilnahme an der Stromspeicher-Inspektion oder in Bezug auf die aktive Mitarbeit zur Datenblatt-Norm für Batteriespeicher. Sobald die Vor-Norm (bei der ich mitgewirkt habe) zur Prüfung und Erstellung von Datenblättern für Stromspeicher veröffentlicht ist, steigt der Druck hier besser zu werden.

Hier mal eine Vorschau, welche Angaben in naher Zukunft auf Datenblättern zu Batteriespeichersystem zu finden sein werden:

grafik

Quelle: https://solar.htw-berlin.de/wp-content/uploads/Effizienzleitfaden-fuer-PV-Speichersysteme-2.0.1.pdf

Dem muss ich widersprechen @andig. Die Änderung, die ihr für @ttjaden seinerzeit eingeführt hattet, hat bei mir dazu geführt, dass es nicht mehr funktionierte, weil ein kleiner Netzbezug, die Batterie auf null gesetzt hat und somit nicht mehr genug Überschuss vorhanden war um die Ladung zu starten.

...und deshalb haben wir das auch geändert. Mein Aussage bleibt bestehen.

Es muss niemand etwas konfigurieren, es sei denn er hat das Ursprungsproblem von @ttjaden.

Jetzt lasst uns bitte die Diskussion in einem erledigten PR beenden und einfach mal den aktuellen Stand ausprobieren. Ich bin überzeugt davon, dass:

a) jeder außer Tjarko und Konfiguration glücklich wird (sic) b) Tjarko's Problem ebenfalls gelöst ist

Nur zur Info: es läuft wieder wie gehabt und gewollt bei mir mit dem letztem nightly build.

[site  ] DEBUG 2022/03/30 11:57:20 ----
[site  ] DEBUG 2022/03/30 11:57:20 pv power: 5031W
[site  ] DEBUG 2022/03/30 11:57:20 battery power: -2787W
[site  ] DEBUG 2022/03/30 11:57:20 grid power: 654W
[site  ] DEBUG 2022/03/30 11:57:20 battery soc 0: 73%
[site  ] DEBUG 2022/03/30 11:57:20 site power: -2133W

evcc-io / evcc