evcc
evcc copied to clipboard
evcc-io
Remove enable/disable thresholds
The thresholds today have two roles. They act as hysteresis plus they adjust the operating point. The hysteresis function is also covered by the PV mode enable/disable timers. With https://github.com/evcc-io/evcc/issues/6106 we have added a new type of meter for smart loads, that is devices that react to power consumption by themselves but are not controllable by evcc. As per https://github.com/evcc-io/evcc/issues/6106#issuecomment-1424232257 it becomes clear, that the smart loads (renamed to aux in https://github.com/evcc-io/evcc/pull/6167) are themselves really an adjustment of the operating point.
I propose to remove the enable/disable thresholds and replace them by using aux meters plus- potentially- an additional static operating point setting. The proposed winter PV mode would operate in a similar way- by moving the operating point from no consumption to no feed-in.
Purpose of this issue is to discuss the approach and understand the scenarios.
/cc @webwanze @StefanSchoof @tobiasbayer @premultiply @naltatis
How does the static operation point works?
Is this the correct understanding? If I need 2,8 kw to start charge and the operation point is 1 kw, the charge will start at 1,8 kw sun with 2,8 charge power. And when sun power is increasing to 2,8 it will still charge with 2,8. After it drops below 1,8 the charge will stop.
Since I always have my threshold at the same value (with different signs), I think this would make the use of such thing easier.
Exactly. The aux meter adjusts the site power before it is given to the loadpoint. The sign is inverted:
site.publish("auxPower", auxPower)
sitePower -= auxPower
That is, positive auxPower will simulate more available grid power.
If we add an operatingPoint power or something like that we should probably inverse the sign, i.e.
sitePower += operatingPoint
Before we do that though it would be good to gain more insights. You can create an aux meter using mqtt or any other plugin and play with the behaviour.
And since you asked for use cases:
Since we use under the week rarely our car, we have a low energy requirement for driving. My wallbox loads between 2,8 to 7,4 kw, but in the dark winter months my PV does provide not enough time with more then 2,8 kw. Start to load with 2,8 kw when we have 1,8 kw sun, seems to match our driving energy requirement in most times well.
I have aux in use. It is working fine.
My usecase: Prioritysoc=100%, but when the soc ist at 75%, the value aux is changed from 0 to 600, to reduce the chargepower of my battery.
Just to be sure…
@StefanSchoof described an UseCase for the operatingPoint. In this case, operationPoint influences the max. useable grid power for charging.
If I need 2,8 kw to start charge and the operation point is 1 kw, the charge will start at 1,8 kw sun with 2,8 charge power. And when sun power is increasing to 2,8 it will still charge with 2,8. After it drops below 1,8 the charge will stop.
@andig in your explanation below, both parameters/counters are just influencing sitePower. This would not match the UseCase described. With operationPoint 1 kW and PV at 2,8 kW charging power would be at 3,8 kW. (Not considering any other loads like house etc..).
Exactly. The
auxmeter adjusts the site power before it is given to the loadpoint. The sign is inverted:site.publish("auxPower", auxPower) sitePower -= auxPowerThat is, positive
auxPowerwill simulate more available grid power.If we add an
operatingPointpower or something like that we should probably inverse the sign, i.e.sitePower += operatingPointBefore we do that though it would be good to gain more insights. You can create an
auxmeter using mqtt or any other plugin and play with the behaviour.
LGTM. My problem with working with the operating point was, that it leads to unnecessary grid consumption when the minimum charge power (1,2 kW in my case) would be sufficient. But this seems to be mitigated when using the operating point in combination with an aux meter. My use case is quite similar to the one @StefanSchoof mentioned. I want to put as much solar power as possible into the car's battery instead of feeding it to the grid. But I do not want to consume more power from the grid than necessary to meet the minimum charging power.
@VolkerK62 If your battery is at 80% and PV power is 0 kW, your battery would be drained with 600 W for charging a vehicle…
I have
auxin use. It is working fine.
My usecase: Prioritysoc=100%, but when the soc ist at 75%, the value
auxis changed from 0 to 600, to reduce the chargepower of my battery.
Other things aside, why would you like to remove the thresholds? At least, these seem to be much easier to understand for the end user than the combination of operating point and aux meter. To be honest, I didn't even think of the thresholds to serve the hysteresis adjustment. In my considerations this was always the delay's job.
in your explanation below, both parameters/counters are just influencing sitePower. This would not match the UseCase described. With operationPoint 1 kW and PV at 2,8 kW charging power would be at 3,8 kW. (Not considering any other loads like house etc..).
@Webwanze ich machs mal auf Deutsch. Warum? 1,8PV entspricht -1,8Grid ohne weitere Lasten. Mit operatingPoint (oder eben umgedrehtem Vorzeichen aux) dann -2,8Grid und damit die Startleistung für @StefanSchoof. Immer Grid == Site solange keine Batterie oder Hausverbrauch ums einfach zu machen.
Other things aside, why would you like to remove the thresholds? At least, these seem to be much easier to understand for the end user than the combination of operating point and aux meter.
Having operating point plus thresholds would make it even more confusing. OpPoint is only one parameter, thresholds are two and often simply match each other.
"Normal user" needs neither thresholds not aux meters. Furthermore, operatingPoint would likely be controlled by UI "sunny/cloudy" setting.
To be honest, I didn't even think of the thresholds to serve the hysteresis adjustment. In my considerations this was always the delay's job.
Agreed!
@VolkerK62 If your battery is at 80% and PV power is 0 kW, your battery would be drained with 600 W for charging a vehicle…
I have
auxin use. It is working fine.My usecase: Prioritysoc=100%, but when the soc ist at 75%, the value
auxis changed from 0 to 600, to reduce the chargepower of my battery.
@Webwanze
not really. there is another check if chargepower plus batterypower is lower than 1,2 kW (the maximum of my battery) . In that case, aux is set back to 0.
@andig Um in deinem Beispiel zu bleiben: PV jetzt 2,8 kW. operationPoint weiterhin 1,0 kW. Dann würde weiterhin 1,0 kW aus dem Netz gezogen werden. Das Auto würde mit 3,8 kW geladen werden.
@StefanSchoof möchte aber, dass in diesem Fall mit 2,8 kW geladen wird.
Ihr habt ein unterschiedliches Verständnis, wie der Parameter wirken soll.
in your explanation below, both parameters/counters are just influencing sitePower. This would not match the UseCase described. With operationPoint 1 kW and PV at 2,8 kW charging power would be at 3,8 kW. (Not considering any other loads like house etc..).
@Webwanze ich machs mal auf Deutsch. Warum? 1,8PV entspricht -1,8Grid ohne weitere Lasten. Mit
operatingPoint(oder eben umgedrehtem Vorzeichenaux) dann -2,8Grid und damit die Startleistung für @StefanSchoof. Immer Grid == Site solange keine Batterie oder Hausverbrauch ums einfach zu machen.
Genau. Aber mit einstellbarem Start/Stop Einspeisung/Bezug. Das geht aktuell mit den Thresholds im normalen PV Modus. Dann hatte ich das falsch verstanden. Ich dachte, die Verwendung von aux führt dazu, dass man den unnötigen Netzbezug bei Verschiebung des Operation Point verhindern könnte.
Vielleicht helfen Virtualisierungen, um die gewünschten Verhalten zu beschrieben. Ich denke das wäre für meine Kombination von Größe PV Anlage mit eine Wallbox ohne Phasenumschaltung im Verhältnis zu Autostrombedarf die optimale Winterausnutzung der PV Energie.
Du willst also ein Verhalten ähnlich Min+PV.
Also X+PV, wobei X einstellbar sein soll. Wenn X+PV > Min (Ladepunkt) soll mit dem Laden begonnen werden.
Man könnte das natürlich auch in den Min+PV Modus bauen, wenn man die Thresholds im normalen PV-Modus loswerden will. Wahrscheinlich wäre das für den Anwender die am einfachsten zu verstehende Option.
So wie ich das sehe, sind die Aux Lasten so wie die thresholds wieder nur ein Sonderfall eines allgemeineren Problems. Es geht hier doch am Ende darum, Lasten, und dazu zähle ich auch Batterien und Ladepunkte, nach Prioritäten zu bedienen. Und diese Prioritäten sind auch noch dynamisch. Höchste Prio hat der Hausverbrauch, 2. Batterie, so lange sie nicht den Mindest-soc hat. 3. Ladepunkt 4. Das was hier unter Aux-Lasten läuft. 5. Batterien mit Mindest-Soc
Bezogen auf die Ladestation müsste vom verfügbaren Budget alles mit höherer Prio abgezogen werden.
Könnte man den Use-Case nicht mittels Prioritäten, kombiniert mit Mindest-Soc an Batterien lösen?
@kscholty Prioritäten haben damit gar nichts zu tun, siehe https://github.com/evcc-io/evcc/pull/6107
Aber #6107 und all die anderen Mechanismen lösen alle doch dasselbe Problem: Wie verteile ich das vorhandene Budget an Energie auf die verschiedenen Lasten? Statische Lasten, Batterien, intelligente Lasten, Evcc gesteuerte Lasten. Für jeden dieser Typen haben wir jetzt andere Parameter, die angeben, wie sie zu berücksichtigen sind. Ich bin der Meinung, dass man die alle durch ein durchgängiges Konzept, basierend auf dynamischen Prioritäten, ersetzen sollte. Deiner Aussage kann ich deshalb nicht zustimmen. Die Prioritäten aus #6107 sind eine Untermenge dessen, was mir vorschwebt.
Vielleicht hab ich jetzt wieder einen Denkfehler, aber @StefanSchoof geht es ja nur darum, den Start/Stop Punkt zu verschieben. Die Regelung innerhalb der Ladephase bleibt wie gehabt. Deshalb greift auch mein Vorschlag des verschobenen Arbeitspunktes nicht, da der immer wirkt.
Das wäre also eine Art kombiniertes Enable/Disable Threshold. Wo müsste das angesiedelt sein, insbesondere bei >1 Wallbox oder Fahrzeugen mit ggf. unterschiedlichem Mindestbedarf? Global, also an der Site? Je Loadpoint analog heute?
Müsste wohl am Auto hängen, da die Min-Ladeleistung am Auto hängt. Ebenfalls die Anzahl der Phasen.
Bei der Auswertung kommt dann der Loadpoint dazu. Evtl. kann die Kombination Auto+Loadpoint ja weniger als das Auto.
Ja, ich möchte den Start Stop Punkt verschieben, um keine Sonne unnötig einzuspeisen. Wenn damit ein Ladevorgang mit zusätzlichem Netzbezug läuft, sollte kein weiter starten (es wird ja schon nichts mehr eingespeist) Daher glaube ich das ein global erlaubter zusätzlicher Netzbezug ehr mein Use Case trifft.
(Ein Akku ist in meinem Setup auch nicht vorhanden. Was nicht heißen, dass es nicht zu bedecken ist, sondern rein zur Klarstellung meines Use Cases)
Nur als Denkanstoß:
Wie wäre ein Parameter für den Modus Min+PV? MaxGrid oder so.
MaxGrid = 1000 W Min errechnet sich anhand MinStrom und Phasenzahl. zB 6 A bei 2 Phasen = 2760 W. Sobald also 1760 W von der PV kommen, wird im Modus PV+Min geladen.
Könnte man auch nutzen, wenn man zB nachts mit reduzierter Leistung (aus Hausakku) laden möchte. Dann MaxGrid auf 4600 W. Nachts kommt nix von PV. Also würde mit dieser Leistung aus dem Akku geladen werden.
Ja, das wäre das, was ich oben meinte: „man könnte das in den Min+PV bauen“. Fände ich gut.
Andere Idee:
wir haben ja keine Ahnung von der Entladeleistung des Hausakkus. In meinem Fall wären das 4.600 W. Ich könnte mir aber vorstellen, dass ich den Akku evtl. Nur mit 3.000 W entladen möchte. Ein Parameter maxdischargepower (oder so) wäre hier denkbar.
Wenn der soc des Hausakkus über buffersoc ist, könnte diese Leistung automatisch als aux mitberücksichtigt werden. im Modus PV würde das Auto weitergeladen werden, bis der Hausakku auf buffersoc runter ist. Im Modus Min+PV würde mit dieser Leistung geladen werden, wenn diese größer Min ist. Ab buffersoc gehts dann mit Min weiter.
Summary bis hierher nach meinem Verständnis:
enable/disableThresholds beeinflussen das Start/Stop Verhalten, aber nicht den Arbeitspunkt der Regelung- Arbeitspunkt der Regelung wird über
residualPowereingestellt- so machen wir das heute bei Hausbatterie (residualPowerleicht positiv)
Fazit: Idee wäre damit, die enable/disable Thresholds durch einen Parameter zu ersetzen. Der Arbeitspunkt bleibt davon unabhängig. Ein Modus i.s. von MinPV wird dadurch auch nicht beeinflusst.