search

evcc-io / evcc

Sonne tanken ☀️🚘
https://evcc.io
MIT License
3.59k stars 663 forks source link

Critical Bug: Max current in yml ignored when vehicle is plugged in #10456

Closed davidgiga1993 closed 1 year ago

davidgiga1993 commented 1 year ago

Describe the bug

EVCC resets / overrides the maxCurrent defined in the yml file as soon as a vehicle has been detected.

This causes a lot of issues as it also overrides the maximum current configured on the charger (PMCC) causing the breaker to trip on overload.

Steps to reproduce

  1. Use specified evcc.yaml
  2. Start evcc, the max current should be correct in the UI
  3. Connect vehicle, the max current now resets to the maximum value

Configuration details

network:
  # schema is the HTTP schema
  # setting to `https` does not enable https, it only changes the way URLs are generated
  schema: https
  # 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: some-host.domain.com
  # port is the listening port for UI and api
  # evcc will listen on all available interfaces
  port: 7070

interval: 30s # 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: debug
levels:
  eebus: info
  site: debug
  lp-1: debug
  lp-2: debug
  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: grid
    type: template
    template: sma-home-manager
    usage: grid
    host: pv-manager.home.local

  - name: pv
    type: template
    template: sma-inverter
    usage: pv
    host: pv-inverter.home.local

# 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: porscheMobileConnect
    type: template
    template: pmcc
    ski: 'a372-107b-9dbf-8672-456b-7178-58e8-e8d3-13fd-3c69'
    ip: iccpd-0123207.home.local

#  - name: wallbox
#    type: template
#    template: eebus
#    ski: '08c98392731d7539d430a4feb29746591de817cf'
#    ip: wallbox.home.local

# 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: taycan
    type: template
    template: iso15118
    capacity: 83.7
    title: Taycan
    mode: pv

# site describes the EVU connection, PV and home battery
site:
  title: Home # display name for UI
  meters:
    grid: grid # grid meter
    pv:
      - pv # list of pv inverters/ meters
    battery: []  # list of battery meters
  residualPower: -390 # allow charging from 50% grid (6A * 50% -> 690W)
  prioritySoc: 0 # give home battery priority up to this soc (empty to disable)
  bufferSoc: 0 # continue charging on battery above soc (0 to disable)
  bufferStartSoc: 0 # start charging on battery above soc (0 to disable)
  maxGridSupplyWhileBatteryCharging: 0 # ignore battery charging if AC consumption is above this value
  smartCostLimit: 0 # set cost limit for automatic charging in PV mode

# loadpoint describes the charger, charge meter and connected vehicle
loadpoints:
  - title: PorscheMobile # display name for UI
    charger: porscheMobileConnect # charger
    mode: "pv" # set default charge mode, use "off" to disable by default if charger is publicly available
    vehicle: taycan # set default vehicle (disables vehicle detection)
    resetOnDisconnect: true # set defaults when vehicle disconnects
    phases: 3 # electrical connection (normal charger: default 3 for 3 phase, 1p3p charger: 0 for "auto" or 1/3 for fixed phases)
    minCurrent: 1 # minimum charge current (default 6A)
    maxCurrent: 15 # maximum charge current (default 16A)

    # remaining settings are experts-only and best left at default values
    priority: 0 # relative priority for concurrent charging in PV mode with multiple loadpoints (higher values have higher priority)
    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: 5m
      estimate: true # set false to disable interpolating between api updates (not recommended)
    enable: # pv mode enable behavior
      delay: 4m # 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: 10m # threshold must be exceeded for this long
      threshold: 0 # maximum import power (W)
    guardDuration: 15m # switch charger contactor not more often than this (default 5m)

# tariffs are the fixed or variable tariffs
tariffs:
  currency: EUR # three letter ISO-4217 currency code (default EUR)
  grid:
    # either static grid price (or price zones)
    type: fixed
    price: 0.5547 # EUR/kWh

    # or variable tariffs
    # type: tibber
    # token: "476c477d8a039529478ebd690d35ddd80e3308ffc49b59c65b142321aee963a4" # access token
    # homeid: "cc83e83e-8cbf-4595-9bf7-c3cf192f7d9c" # optional if multiple homes associated to account

    # type: awattar
    # region: de # optional, choose at for Austria
    # charges: # optional, additional charges per kWh
    # tax: # optional, additional tax (0.1 for 10%)

    # type: octopusenergy
    # tariff: AGILE-FLEX-22-11-25 # Tariff code
    # region: A # optional

    # type: elering # Nordpool
    # region: ee # or lt, lv, fi
    # charges: # optional, additional charges per kWh
    # tax: # optional, additional tax (0.1 for 10%)

    # type: energinet # Energinet using the price in DKK
    # region: dk1 # or dk2
    # charges: # optional, additional charges per kWh
    # tax: # optional, additional tax (0.1 for 10%)
  feedin:
    # rate for feeding excess (pv) energy to the grid
    type: fixed
    price: 0.1079 # EUR/kWh

    # type: octopusenergy
    # tariff: AGILE-FLEX-22-11-25 # Tariff code
    # region: A # optional
  co2:
    # co2 tariff provides co2 intensity forecast and is for co2-optimized target charging if no variable grid tariff is specified
    # type: grünstromindex # GrünStromIndex (Germany only)
    # zip: <zip>

    # type: electricitymaps # https://app.electricitymaps.com/map
    # uri: <uri>
    # token: <token>
    # zone: DE

    # type: ngeso # National Grid Electricity System Operator data (United Kingdom only) https://carbonintensity.org.uk/
    # provides national data if both region and postcode are omitted - do not supply both at the same time!
    # region: 1 # optional, coarser than using a postcode - see https://api.carbonintensity.org.uk/ for full list
    # postcode: SW1A1AA # optional

# 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:
  shipid: EVCC-6163316413771377
  interfaces: [eth0]

# 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

evcc  | [main  ] INFO 2023/10/23 17:55:32 evcc 0.121.2
evcc  | [main  ] INFO 2023/10/23 17:55:32 using config file: /etc/evcc.yaml
evcc  | [main  ] INFO 2023/10/23 17:55:32 starting ui and api at :7070
evcc  | [eebus ] INFO 2023/10/23 17:55:32 Local SKI:  02c8da7dba7837c0adbe1ab371d7661f0cf6d9cd
evcc  | [site  ] INFO 2023/10/23 17:55:37 site config:
evcc  | [site  ] INFO 2023/10/23 17:55:37   meters:      grid ✓ pv ✓ battery ✗
evcc  | [site  ] INFO 2023/10/23 17:55:37     grid:      power ✓ energy ✓ currents ✓
evcc  | [site  ] INFO 2023/10/23 17:55:37     pv 1:      power ✓ energy ✓ currents ✓
evcc  | [site  ] INFO 2023/10/23 17:55:37   vehicles:
evcc  | [site  ] INFO 2023/10/23 17:55:37     vehicle 1: range ✗ finish ✗ status ✗ climate ✗ wakeup ✗
evcc  | [lp-1  ] INFO 2023/10/23 17:55:37 loadpoint 1:
evcc  | [lp-1  ] INFO 2023/10/23 17:55:37   mode:        pv
evcc  | [lp-1  ] INFO 2023/10/23 17:55:37   charger:     power ✓ energy ✗ currents ✓ phases ✗ wakeup ✗
evcc  | [lp-1  ] INFO 2023/10/23 17:55:37   meters:      charge ✓
evcc  | [lp-1  ] INFO 2023/10/23 17:55:37     charge:    power ✓ energy ✗ currents ✓
evcc  | [lp-1  ] DEBUG 2023/10/23 17:55:37 phase timer inactive
evcc  | [lp-1  ] DEBUG 2023/10/23 17:55:37 pv timer inactive
evcc  | [lp-1  ] DEBUG 2023/10/23 17:55:37 guard timer inactive
evcc  | [lp-1  ] INFO 2023/10/23 17:55:37 vehicle updated: unknown -> Taycan
evcc  | [lp-1  ] DEBUG 2023/10/23 17:55:37 set charge mode: pv
evcc  | [site  ] DEBUG 2023/10/23 17:55:37 ----
evcc  | [lp-1  ] DEBUG 2023/10/23 17:55:37 charge power: 0W
evcc  | [site  ] DEBUG 2023/10/23 17:55:37 pv power: 27W
evcc  | [site  ] DEBUG 2023/10/23 17:55:37 grid power: 11688W
evcc  | [site  ] DEBUG 2023/10/23 17:55:37 grid powers: [3902 4022 3764]W
evcc  | [site  ] DEBUG 2023/10/23 17:55:37 grid currents: [16.9 17.3 16.2]A
evcc  | [site  ] DEBUG 2023/10/23 17:55:37 site power: 11298W
evcc  | [lp-1  ] DEBUG 2023/10/23 17:55:37 charge currents: [0 0 0]A
evcc  | [lp-1  ] DEBUG 2023/10/23 17:55:37 charger status: A
evcc  | [lp-1  ] INFO 2023/10/23 17:55:37 car disconnected
evcc  | [lp-1  ] DEBUG 2023/10/23 17:55:37 set charge mode: pv
evcc  | [lp-1  ] DEBUG 2023/10/23 17:55:37 set min current: 1
evcc  | [lp-1  ] DEBUG 2023/10/23 17:55:37 set max current: 15
evcc  | [lp-1  ] DEBUG 2023/10/23 17:55:37 set priority: 0
evcc  | [lp-1  ] DEBUG 2023/10/23 17:55:37 set charge mode: pv
evcc  | [site  ] DEBUG 2023/10/23 17:56:07 ----
evcc  | [lp-1  ] DEBUG 2023/10/23 17:56:07 charge power: 11211W
evcc  | [site  ] DEBUG 2023/10/23 17:56:07 pv power: 27W
evcc  | [site  ] DEBUG 2023/10/23 17:56:07 grid power: 10630W
evcc  | [site  ] DEBUG 2023/10/23 17:56:07 grid powers: [3536 3698 3396]W
evcc  | [site  ] DEBUG 2023/10/23 17:56:07 grid currents: [15.3 15.9 14.7]A
evcc  | [site  ] DEBUG 2023/10/23 17:56:07 site power: 10240W
evcc  | [lp-1  ] DEBUG 2023/10/23 17:56:07 charge currents: [16 15.8 14.4]A
evcc  | [lp-1  ] DEBUG 2023/10/23 17:56:07 set min current: 2.2
evcc  | [lp-1  ] DEBUG 2023/10/23 17:56:07 set max current: 32
evcc  | [lp-1  ] DEBUG 2023/10/23 17:56:07 charger status: C
evcc  | [lp-1  ] INFO 2023/10/23 17:56:07 car connected
evcc  | [lp-1  ] DEBUG 2023/10/23 17:56:07 pv timer elapse
evcc  | [lp-1  ] DEBUG 2023/10/23 17:56:07 pv timer inactive
evcc  | [lp-1  ] DEBUG 2023/10/23 17:56:07 charger: guard elapse
evcc  | [lp-1  ] DEBUG 2023/10/23 17:56:07 guard timer inactive
evcc  | [lp-1  ] INFO 2023/10/23 17:56:07 start charging ->
evcc  | [lp-1  ] DEBUG 2023/10/23 17:56:07 wake-up timer: stop
evcc  | [lp-1  ] DEBUG 2023/10/23 17:56:07 charger vehicle id: 00:18:87:00:98:92
evcc  | [lp-1  ] WARN 2023/10/23 17:56:07 charger out of sync: expected disabled, got enabled
evcc  | [lp-1  ] DEBUG 2023/10/23 17:56:07 forced charging at vehicle soc 30% (< 40% min soc)
evcc  | [lp-1  ] DEBUG 2023/10/23 17:56:07 max charge current: 32A
evcc  | [site  ] DEBUG 2023/10/23 17:56:37 ----
evcc  | [lp-1  ] DEBUG 2023/10/23 17:56:37 charge power: 22064W
evcc  | [lp-1  ] DEBUG 2023/10/23 17:56:37 forced charging at vehicle soc 30% (< 40% min soc)
evcc  | [site  ] DEBUG 2023/10/23 17:56:37 pv power: 27W
evcc  | [site  ] DEBUG 2023/10/23 17:56:37 grid power: 22578W
evcc  | [site  ] DEBUG 2023/10/23 17:56:37 grid powers: [7542 7590 7446]W
evcc  | [site  ] DEBUG 2023/10/23 17:56:37 grid currents: [32.7 32.7 32.2]A
evcc  | [site  ] DEBUG 2023/10/23 17:56:37 site power: 22188W
evcc  | [lp-1  ] DEBUG 2023/10/23 17:56:37 charge currents: [32.2 31.9 32.5]A
evcc  | [lp-1  ] DEBUG 2023/10/23 17:56:37 detected active phases: 3p
evcc  | [lp-1  ] DEBUG 2023/10/23 17:56:37 charger status: C
evcc  | [lp-1  ] DEBUG 2023/10/23 17:56:37 forced charging at vehicle soc 30% (< 40% min soc)
evcc  | [lp-1  ] DEBUG 2023/10/23 17:57:01 set max current: 16
evcc  | [site  ] DEBUG 2023/10/23 17:57:07 ----
evcc  | [lp-1  ] DEBUG 2023/10/23 17:57:07 charge power: 21979W
evcc  | [lp-1  ] DEBUG 2023/10/23 17:57:07 forced charging at vehicle soc 30% (< 40% min soc)
evcc  | [site  ] DEBUG 2023/10/23 17:57:07 pv power: 27W
evcc  | [site  ] DEBUG 2023/10/23 17:57:07 grid power: 620W
evcc  | [site  ] DEBUG 2023/10/23 17:57:07 grid powers: [228 319 73]W
evcc  | [site  ] DEBUG 2023/10/23 17:57:07 grid currents: [1.7 1.82 0.777]A
evcc  | [site  ] DEBUG 2023/10/23 17:57:07 site power: 230W
evcc  | [lp-1  ] DEBUG 2023/10/23 17:57:07 charge currents: [32.1 31.8 32.5]A
evcc  | [lp-1  ] DEBUG 2023/10/23 17:57:07 detected active phases: 3p
evcc  | [lp-1  ] DEBUG 2023/10/23 17:57:07 set max current: 32
evcc  | [lp-1  ] DEBUG 2023/10/23 17:57:07 charger status: C
evcc  | [lp-1  ] DEBUG 2023/10/23 17:57:07 forced charging at vehicle soc 30% (< 40% min soc)
evcc  | [site  ] DEBUG 2023/10/23 17:57:37 ----
evcc  | [lp-1  ] DEBUG 2023/10/23 17:57:37 charge power: 0W
evcc  | [lp-1  ] DEBUG 2023/10/23 17:57:37 forced charging at vehicle soc 30% (< 40% min soc)
evcc  | [site  ] DEBUG 2023/10/23 17:57:37 pv power: 28W
evcc  | [site  ] DEBUG 2023/10/23 17:57:37 grid power: 567W
evcc  | [site  ] DEBUG 2023/10/23 17:57:37 grid powers: [230 266 72]W
evcc  | [site  ] DEBUG 2023/10/23 17:57:37 grid currents: [1.72 1.65 0.794]A
evcc  | [site  ] DEBUG 2023/10/23 17:57:37 site power: 177W
evcc  | [lp-1  ] DEBUG 2023/10/23 17:57:37 charge currents: [0 0 0]A
evcc  | [lp-1  ] ERROR 2023/10/23 17:57:37 charger: timeout

What type of operating system are you running?

Docker container

Version

0.121.0 - 0.121.2

Additional infos

davidgiga1993 commented 1 year ago

Some further analysis: The charger reports 16A as max current, which is correct given that the charger limit is set to 16A for this test. The eebus code updates the max current to 16A. I would open a discussion here that the max current of the charger should not be able to override the max current of the loadpoint if LP.maxCurrent < charger.maxCurrent. If you agree with this I can create an MR for that.

It's still unclear to me where the 32A came from, either the charger reported wrong values or something else in EVCC sets this to 32A.

Update 2: Disabling the eebus maxCurrent update by setting a maxCurrent for the vehicle seems to resolve the issue. Thus there are 2 points:

  1. The logic I mentioned above should be revisited.
  2. The PMCC seems to report wrong max current values from time to time.
andig commented 1 year ago

@davidgiga1993 thanks for getting in contact! Always nice to hear from you.

The logic I mentioned above should be revisited.

Works as (currently) designed. We've already noticed that this has its drawbacks. The EEBus charger overrides the currents. We will change this with https://github.com/evcc-io/evcc/pull/10335. See precedent rules there.

The PMCC seems to report wrong max current values from time to time.

/cc @DerAndereAndi

davidgiga1993 commented 1 year ago

Thanks @andig! One question: The new logic has the min/maxcurrent priority vehicle, charger, lp. From a pure abstract perspective I would see the LP value as more important than the charger because the loadpoint in my mind includes the electrical installation. Or is the idea that the values from the charger are always seen as "more correct"?

Would it make sense to always use the min value of all the 3?

andig commented 1 year ago

because the loadpoint in my mind includes the electrical installation

Fully acknowledged. We treat the charger as logically controlled by evcc. We never override any of the "physical" layer limits in the charger. That is always afaik a separate "physical limits" settings.

davidgiga1993 commented 1 year ago

But shouldn't then the loadpoint settings have higher priority than the one reported from the charger itself? Or is the charger seen as "source of truth" about the physical layer?

andig commented 1 year ago

Not sure if you're referring to the current implementation or the PR? Point is: whatever we write to the charger, the chargers "this is the physical limit" setting will remain untouched and still be the upper boundary. That way safety is in hardware (or rather: in the charger's software), but not in evcc!

davidgiga1993 commented 1 year ago

Not sure if you're referring to the current implementation or the PR? Point is: whatever we write to the charger, the chargers "this is the physical limit" setting will remain untouched and still be the upper boundary. That way safety is in hardware (or rather: in the charger's software), but not in evcc!

This PR. And no, the PMCC for example specific tells the user that the current limit is overwritten by the Powermanagement system (aka evcc). So if I specific 5A on the PMCC itself and evcc sends 20A it will charge with 20A. I would have also expected the charger to always use its own limit, but it explicitly doesn't, see Screenshot_20231023-210434

andig commented 1 year ago

Evcc should set the „current“ but never (!) change the chargers min/max. Evcc will still send current within the min/max limits it is aware of. If these are outside charger limits, charger will clip/clamp them.

/cc @DerAndereAndi

davidgiga1993 commented 1 year ago

Yes exactly I agree, but the PMCC doesn't use it's own limits if evcc sends a "charge current" value. Therefore in this case evcc is the source of truth for the global charge current limiter :-)

That's why my idea above was that the LP limit should have higher priority than the values from the charger itself (as the PMCC also apparently reports the max value sometimes instead of the actual set limit). Or maybe it's just a bug in the PMCC communication. In that case the PR logic will be fine as long as the limits received from the PMCC are correct.

andig commented 1 year ago

I agree, but the PMCC doesn't use it's own limits if evcc sends a "charge current" value.

@DerAndereAndi is this due to the way we're using EEbus or is that a defect in the PMCC implementation?

andig commented 1 year ago

@davidgiga1993 lets please take one step back to better understand the context: how much current does your house installation allow and how is your PMCC connected? Reason for asking: physical connection (CEE16 vs CEE32) must match allowed physical limits.

davidgiga1993 commented 1 year ago

lets please take one step back to better understand the context: how much current does your house installation allow and how is your PMCC connected? Reason for asking: physical connection (CEE16 vs CEE32) must match allowed physical limits.

In this instance the power connection was made using CEE16, the limit on the PMCC was set to 15A (16A in the test above for testing purposes).

Also it looks like this rejected change did remove updating the LP min/max with the values reported by the charger. Might be related

DerAndereAndi commented 1 year ago

The PMCC is connected using CEE or Schuko plugs and has its limits set by the used cables automatically. Using EEBUS it assumes that overload protection is done dynamically with the connected HEMS, which evcc does not support as of now. This is usually the main feature of compatible EEBUS HEMS systems.

The algorithm is added in the EEBUS charger because more and more EEBUS chargers (including PMCC, Spelsberg, and more) also support ISO15118-2 connections over AC to the EV. And the min limits are lower than using PWM. And also an ISO connection can always falls back to PWM. And therefore the limits can always change and should not be hardcoded in any configuration. So the logic is not because of EEBUS, but because of corresponding EVSEs that also support ISO15118-2 and cars that do so (e.g. Porsche Taycan, Cayenne Hybrid, MEB based EVs, Mercedes, some BMW, and more).

If the EVSE doesn't have charging authorization turned on, the EV will charge immediately and evcc may take a few seconds to lower the charging limits due to the way EEBUS and ISO work. The time depends on how long the evcc interface is set up and when within that intervall the EV is plugged in. So even by setting up a loadpoint limit to lower than what the cable can provide, you might have the same effects! A change in logic and evcc implementation will not guarantee that it works for you.

Trying to set the max limit on the loadpoint imho is a workaround for your specific setup but falls short because of the described needs. The suggestion discussed in the ticket and the new PR would not solve that either as it defined as vehicles takes precedence over charger over loadpoint. To make this work in an optimal case the loadpoint should define outer limits (with minCurrent being 0!), the charger might only reduce these limits, and the vehicle further reducing these.

A workaround for now may be to let the charger implementation only overwrite the minCurrent limit, as mostly the maxCurrent does not change with the communication protocol.

davidgiga1993 commented 1 year ago

Thanks for confirming that! It would also be enough imho to just use the smalles value of the 3 sources (vehicle, loadpoint, charger) and use that for the maxCurrent value. Should be easy enough to do

andig commented 1 year ago

In this instance the power connection was made using CEE16, the limit on the PMCC was set to 15A (16A in the test above for testing purposes).

Which means 16A ist the limit that physics allow. Evcc can never go above this limit since PMCC would enforce 16A. If it does not do that (whatever setting evcc supplies) then that is a bad PMCC bug.

Evcc will not respect the 15A, partly because it's not even aware of that.

davidgiga1993 commented 1 year ago

In this instance the power connection was made using CEE16, the limit on the PMCC was set to 15A (16A in the test above for testing purposes).

Which means 16A ist the limit that physics allow. Evcc can never go above this limit since PMCC would enforce 16A. If it does not do that (whatever setting evcc supplies) then that is a bad PMCC bug.

Evcc will not respect the 15A, partly because it's not even aware of that.

No, the PMCC allowed 32A, causing the breaker to trip, because the PMCC reported 32A. Probably because it resets the reported limit when receiving a message from the HEMS.

Nevertheless I opened a PR which resolves the issue and is imho the only way to handle the merging of multiple limit definitions correct.

andig commented 1 year ago

That is a bad issue in the PMCC imho, because it would allow software (HEMS) to override hardware (cable) safety limits. I would suggest to immediately raise this with Porsche. Evcc is not designed to ensure physical safety- that is a hardware task!

davidgiga1993 commented 1 year ago

That is a bad issue in the PMCC imho, because it would allow software (HEMS) to override hardware (cable) safety limits. I would suggest to immediately raise this with Porsche. Evcc is not designed to ensure physical safety- that is a hardware task!

I will try, but in my experience with software issues on cars and their accessories things like these will take years to get acknowledges and even longer to get fixed.

But if evcc should not include a workaround/solution in the meantime I'll probably just run a fork with my patch until something gets fixed :-)

andig commented 1 year ago

Absolutely! But this one is really gross. ❤️‍🩹

DerAndereAndi commented 1 year ago

Probably because it resets the reported limit when receiving a message from the HEMS.

This is absolutely not what is happening guys!

if the PMCC is connected to a CEE32 plug, it allows 32A per phase. And thus this is reported to the HEMS.

If the HEMS sets a lower charging limit, then it does it for this charging session only. Any higher values than reported by the plug connection will be rejected.

The suggested PR does NOT change the behvaiour or "fix" anything. I already mentioned what is going on and what the options are.

davidgiga1993 commented 1 year ago

The suggested PR does NOT change the behvaiour or "fix" anything. I already mentioned what is going on and what the options are.

Do you mean my PR or the other one? Because mine definitely fixes it :-) I'm using it right now and the max current used is 15A (as specified in the LP yml definition). Even when the vehicle is plugged in and evcc takes a bit to respond the pmcc first uses it's own limit setting (which is 15A) and then evcc sends 15A as max value due to the min clamping (evcc basically ignores the 32A maxCurrent reported by the pmcc). This can even be easily verified by unit testing the entire logic

DerAndereAndi commented 1 year ago

Your PR. It breaks other behaviour.

davidgiga1993 commented 1 year ago

Not sure I understand why because you mentioned

To make this work in an optimal case the loadpoint should define outer limits (with minCurrent being 0!), the charger might only reduce these limits, and the vehicle further reducing these.

Which is basically what's happening in the end since the minimum value for the "maxCurrent" wins, or am I overlooking something here? Not trying to argue, just trying to understand

DerAndereAndi commented 1 year ago

I provided a PR which would solve your issue and not break others.

In general: You would also get the same result without any code changes by setting the max current of the connected vehicle to your desired max. Update: If the identification happens before the breaker reacts.

andig commented 1 year ago

if the PMCC is connected to a CEE32 plug, it allows 32A per phase. And thus this is reported to the HEMS.

@DerAndereAndi @davidgiga1993 said its connected via CEE16

DerAndereAndi commented 1 year ago

No, the only reference I find is:

In this instance the power connection was made using CEE16, the limit on the PMCC was set to 15A (16A in the test above for testing purposes).

The limit in the PMCC is ONLY used, if no HEMS is connected. As it is stated in the screenshot mentioned in https://github.com/evcc-io/evcc/issues/10456#issuecomment-1775844020

I do not see a reference anywhere in here where it is stated that using a CEE16 cable a 32A limit is reported.

Update: I can see that following the discussion from the beginning where your understanding is coming from. For me it is still not clear what the actual physical setup looks like.

DerAndereAndi commented 1 year ago

Maybe it would help to get a clarification of the setup and what actually happens :)

The screenshot shows a reported max of 32A. So the charger must think it is connected to a 32A cable.

davidgiga1993 commented 1 year ago

To clarify: The pmcc cable is 32A, the wall plug CEE16. So from a pmcc side it detects a 32A cable. Thus the realization when the manual limit behavior didn't work as expected. Nevertheless, even with a CEE32 I wouldn't want to use the full 32A for charging. And yes the 16A pmcc cable would probably be better but it's not on stock and I still need to charge somehow until it gets shipped. But then again, I would like evcc to honor my settings, so #10478 should solve that.

DerAndereAndi commented 1 year ago

@davidgiga1993 So this all is expected behaviour from the PMCC side.

andig commented 1 year ago

The pmcc cable is 32A, the wall plug CEE16. So from a pmcc side it detects a 32A cable.

That is a physical security issue. Your setup cannot guarantee that the hardware can maintain the physical limits. The PMCC current limit is only a fallback limit for when a HEMS is not configured.