evcc: detection of loadpoint's second car fails after connection
Describe the bug
I have a loadpoint with two configured cars. Both have perfectly working online API access with indication of connected and charging states (Skoda Enyaq using type: enyaq as first in vehicles list and VW e-up using type: id as second).
Prerequisites:
- loadpoint is “idle” (no car connected) with the first car (Enyaq) assigned
- second car (e-up) gets plugged in
(faulty) behaviour: Even though the second car might start charging, the loadpoint sticks to the first car. Probable cause seems to me, that the second car gets polled too early and only once after getting plugged in (before the connected state gets updated in VW’s backend). I think this behaviour started with #1163 .
known workaround: Restart of evcc container while the second car is connected leads to detection of the correct car.
To Reproduce Steps to reproduce the behavior:
- configure evcc with a loadpoint with two vehicles
- start evcc without a car connected (so that the first car in vehicles list gets assigned to the loadpoint)
- plug in the second car in vehicles list
- second car won’t get detected and loadpoint sticks to the first car
Expected behavior After connection of the second car in vehicles list this car gets detected and shown in GUI.
EVCC details:
Show output of evcc -v:
evcc version 0.60 (986d734)
Show output of evcc dump -c configfile:
This is after restart of evcc and hence with correctly detected second car!
[main ] INFO 2021/07/30 10:25:14 evcc 0.60 (986d734)
[main ] INFO 2021/07/30 10:25:14 using config file /config/evcc.yaml
[mqtt ] INFO 2021/07/30 10:25:14 connecting evcc-668543700 at 10.0.1.97:1883
[mqtt ] DEBUG 2021/07/30 10:25:14 10.0.1.97:1883 connected
[lp-1 ] WARN 2021/07/30 10:25:19 poll mode '{always 2m0s}' may deplete your battery or lead to API misuse. USE AT YOUR OWN RISK.
[lp-1 ] WARN 2021/07/30 10:25:19 poll interval '2m0s' is lower than 1h0m0s and may deplete your battery or lead to API misuse. USE AT YOUR OWN RISK.
config
======
grid: grid
Power: 0W
Energy: 5509551.0kWh
pv: pv-dc-kostal
Power: 6978W
battery: battery-pv
Power: -2371W
SoC: 35%
loadpoint 1
charge: charge
Power: 3808W
Energy: 7688.2kWh
charger: wallbe
Charge status: C
Enabled: true
Duration: 1h26m52s
Diagnostic dump:
vehicle 0
SoC: 70%
Charge status: A
Capacity: 58kWh
Range: 236km
Finish time: not available
vehicle 1
SoC: 45%
Charge status: C
Capacity: 32kWh
Range: 101km
Finish time: 2021-07-30 12:29:00 +0000 UTC
Climate active: false
Outside temp: 21.0°C
Target temp: 21.0°C
Show evcc configuration file evcc.yaml:
uri: 0.0.0.0:7070 # uri for ui interval: 10s # control cycle intervallog settings
log: debug levels: #core: debug lp-1: debug #lp-2: debug #cache: trace #vw: trace id: debug enyaq: 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: modbus model: kostal uri: 10.0.1.57:502 id: 255 power: Power energy: Export
- name: pv-dc-kostal type: custom power: source: calc add: # The add plugin sums up both string values - source: modbus model: kostal value: 160:1:DCW # string 1 uri: 10.0.1.37:1502 id: 71 # Configured Modbus Device ID - source: modbus model: kostal value: 160:2:DCW # string 2 uri: 10.0.1.37:1502 id: 71 # Configured Modbus Device ID
- name: battery-pv type: modbus power: 802:W soc: 802:SoC uri: 10.0.1.37:1502 id: 71
- name: charge type: custom power: source: mqtt topic: mbmd/sdm2301-10/Power timeout: 30s energy: source: mqtt topic: mbmd/sdm2301-10/Import timeout: 30s
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: wallbe type: wallbe # Wallbe charger uri: 10.0.1.67:502 # ModBus address legacy: true
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: e-up type: id title: Uppsala capacity: 32.3 user: xxxxxxxxxxxxxxxx@googlemail.com # user password: xxxxxxxxxxxxxxxx # password vin: WVWxxxxxxxxxxxxxx cache: 2m
- name: enyaq type: enyaq title: Ladmila capacity: 58 user: xxxxxxxxxxxxxxxx@googlemail.com # user password: xxxxxxxxxxxxxxxx # password vin: TMBxxxxxxxxxxxxxx cache: 2m
site describes the EVU connection, PV and home battery
site: title: Home
residualpower: 250
meters: grid: grid # grid meter pv: pv-dc-kostal # pv meter battery: battery-pv # battery meter prioritySoC: 30 # give home battery priority up to this soc (0 to disable)
loadpoint describes the charger, charge meter and connected vehicle
loadpoints:
- title: Ladesäule
charger: wallbe # charger
meters:
charge: charge # charge meter
vehicles:
- enyaq
- e-up mode: pv soc: min: 30 # immediately charge to 30% regardless of mode unless “off” (disabled) target: 80 # always charge to 80% estimate: false # set true to interpolate between api updates poll: mode: always interval: 2m onDisconnect: mode: pv # switch back to pv mode
targetSoC: 80 # charge to xx%
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 exceeds minimum charge power to enable disable: # pv mode disable behavior delay: 10m # threshold must be exceeded for this long threshold: 500 # 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: 10.0.1.97:1883 user: mbmd password: xxxxxxxxxxxxxxxx
Show evcc log output with --log debug:
This is the first log, where detection of the second car fails on plugging in.
See attached file "2021-07-30_evcc_Autowechsel_01.log". Second car gets connected at: [lp-1 ] INFO 2021/07/30 08:49:38 car connected
2021-07-30 evcc Autowechsel 01.log
Show evcc log output with --log debug:
This is the second log, where the second car gets detected while plugged in after restart of evcc.
See attached file "2021-07-30_evcc_Autowechsel_02.log".
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 1
- Comments: 34 (29 by maintainers)
Der OBD Stecker funktioniert auch nicht immer, in unserem ID.3 hat der nach ner halben Stunde keinen Strom mehr, auch wenn das EV am AC laden ist. Nochmal, auch das mag/könnte bei manchen Konstellationen besser funktionieren, aber nicht bei allen.
https://www.sqrt.io/blog/obd2-wifi-adapter-absichern
@mark-sch Du meinst OBD ist schneller als API? Für mich ist das keine Massenlösung und ich persönlich will keinen Bastelstecker in meinem Auto. Es ist ja kein Problem EVNotify in evcc zu integrieren falls das jemand will- bei Bedarf fehlt einfach ein Beispiel für https://github.com/andig/evcc-config, oder?
Der OBD Stecker löst auch das Problem nicht wenn der Mobilfunkempfang schlecht ist.
Für alle bisherigen Varianten gibt es Problemfälle, bei manchen wird es gut funktionieren, bei anderen nicht. Egal was wir tun, es wird keine 100% Lösung sondern abhängig von der persönlichen Konstellation.
Die einzige „richtige“ Lösung kommt erst noch, wenn die Verbindung vom EV zum Charger auch bei AC über ISO15118 (-20) erfolgt, dort wird dann auch wie an den DC Säulen der SoC und eine Fahrzeugkennung übertragen. Es gibt bereits vereinzelte Ansätze für SoC, also herstellerpsezifische Erweiterungen für ISO15118 (-2) die das machen. Aber es ist eben auch keine Lösung für bestehende EVs und Charger.
Also wird es hier keinen allgemein funktionierenden Ansatz geben. Das ist nun mal so.
Du hast jetzt bis auf andere Konstanten genau den PR beschrieben 😉
@DerAndereAndi hatte noch eine interessante Anmerkung: die Erkennung muss Fahrzeuge ausschließen, die an anderen Ladepunkten schon erkannt wurden. Damit stellt sich die generelle Frage, ob eine Konfiguration von Fahrzeugen je Ladepunkt eigentlich sinnvoll ist oder diese nicht völlig flexibel sein sollten (mit den entsprechenden Nachteilen für Fahrzeuge ohne die notwendigen APIs). Ich schlage vor das Thema separat zu behandeln.
Idee: solang kein Auto identifiziert werden kann sollten die Abfragen- für definierte Zeit- weiter erfolgen um den langsameren APIs eine Chance zu geben aufzuholen.