andig
commented
3 years ago Mit anderen Worten: wenn ein Fahrzeug sich nicht Normkonform verhält liegt die Regelung um den Betrag der Abweichung daneben.
Warum regeln wir auf Ist-Ströme: weil dadurch ein Aufschwingen der Regelung vermieden wird. Phantomabweichungen werden immer auf Basis der Echtwerte bewertet. Refs https://github.com/evcc-io/evcc/pull/877
Einfacher Workaround: mit ResidualPower kompensieren.
/cc @premultiply wie siehst Du das Thema Regelung?
Alestrix
premultiply
Describe the bug
Wenn EVCC nur die Leistung am Netzanschlusspunkt zur Verfügung hat, wird der an die Wallbox gesendete Soll-Strom korrekt geregelt, so dass am Netzübergang im Schnitt 0W bzw die eingestellte
residualpoweranliegt - im Bild unten Bereich (1) (residualPower=100).Zugehöriges Log:
Sobald aber ein Charger in der Konfiguration definiert ist, der EVCC den tatsächlich zum Auto fließenden Strom mitteilt, wird nicht mehr korrekt geregelt (Bereich (2),
residualPower=100)Zugehöriges Log:
To Reproduce
Man benötigt ein Auto, dass sich nicht exakt an die Vorgabe durch die Wallbox hält (das dürften wohl die meisten Autos sein, bei Zoe ist es aber wohl ein Extremfall) und einen Wallbox-Charger, der die Ströme liefern kann. Dann beobachtet man die sitePower einmal mit konfigurierter Wallbox-Strommessung und mal ohne.
In meinem Fall:
Expected behavior
EVCC hat nur Einfluss auf den an die Wallbox per API gesendeten Sollstrom (=Regler) und versucht darüber zyklisch, die Regelgröße (=Netzbezug) auf einen Sollwert (0W bzw. residualpower) zu regeln. Ist der Netzbezug zu groß, muss der Regler heruntergedreht werden, ist der Netzbezug zu klein bzw. die Einspeisung zu groß, muss der Regler hochgedreht werden. EVCC sollte sich nicht von den Messwerten an der Wallbox "verwirren" lassen.
EVCC details: Show output of
evcc -v:Git master von gestern (23.08.2021), da in der Release Version noch ganze Ampere an die Wallbox (WARP Charger) gesendet werden.
Show output of
evcc dump -c configfile:Show evcc configuration file
evcc.yaml:uri: 0.0.0.0:7070 # uri for ui interval: 5s # control cycle interval log: error levels: core: info #debug lp-1: debug #info #debug meters: - name: grid type: custom power: source: http uri: http://192.168.8.240/status jq: .emeters | map(.power) | add currents: - source: http uri: http://192.168.8.240/emeter/0 jq: .current - source: http uri: http://192.168.8.240/emeter/1 jq: .current - source: http uri: http://192.168.8.240/emeter/2 jq: .current - name: pv type: custom power: source: mqtt topic: energy/solarpower - name: warpmeter type: custom power: source: http uri: http://192.168.8.217/status jq: .emeters | map(.power) | add chargers: - name: warp type: warp broker: pi:1883 topic: warp useMeter: false # WARP Charger Pro timeout: 30s # currents: # - source: http # uri: http://192.168.8.217/emeter/0 # jq: .current # - source: http # uri: http://192.168.8.217/emeter/1 # jq: .current # - source: http # uri: http://192.168.8.217/emeter/2 # jq: .current vehicles: - name: zoe type: renault title: Zoe capacity: 52 # kWh user: xxx password: xxx site: title: Home # display name for UI meters: grid: grid # grid meter pv: pv # pv meter residualPower: 100 loadpoints: - title: Stellplatz # display name for UI charger: warp meters: charge: warpmeter # charge meter vehicle: zoe mode: pv soc: poll: mode: charging interval: 60m min: 0 # immediately charge to 0% regardless of mode unless "off" (disabled) target: 85 # always charge to 75% estimate: false # set true to interpolate between api updates onDisconnect: # set defaults when vehicle disconnects mode: pv # switch back to pv mode targetSoC: 85 # charge to 75% phases: 1 #3 # ev phases (default 3) enable: # pv mode enable behavior delay: 1m # threshold must be exceeded for this long threshold: 0 # minimum grid power in Watts. Negative values denote 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: 460 # maximum import power (W) guardduration: 5m # switch charger contactor not more often than this (default 10m) mincurrent: 8 # minimum charge current (default 6A) maxcurrent: 21 # maximum charge current (default 16A) mqtt: broker: pi:1883 topic: evcc # root topic for publishing, set empty to disable influx: url: http://pi:8086 database: evccShow evcc log output with
--log debug:Mitigation Es könnte ausreichen, EVCC nicht über die Ströme zu informieren (wie oben durch die Auskommentierung getan). Ich kann mir aber vorstellen, dass z.B. die automatische Unterscheidung zwischen 1P und 3P zuverlässiger funktioniert, wenn EVCC Zugriff auf die Ströme hat. Ob EVCC die Wallbox-Ströme noch für andere Zwecke nutzen kann, ist mir nicht bekannt.