Remove enable/disable thresholds

[andig]

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

[StefanSchoof]

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.

[andig]

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.

[StefanSchoof]

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.

[VolkerK62]

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.

[Webwanze]

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

[tobiasbayer]

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.

[Webwanze]

@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 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.

[tobiasbayer]

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.

[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..).

@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.

[andig]

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]

@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 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.

@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.

[Webwanze]

@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 Vorzeichen aux) dann -2,8Grid und damit die Startleistung für @StefanSchoof. Immer Grid == Site solange keine Batterie oder Hausverbrauch ums einfach zu machen.

[andig]

Guter Punkt. Back to the drawing board.

[Webwanze]

@StefanSchoof beschreibt ein Verhalten ähnlich dem Lademodus Min+PV.

[tobiasbayer]

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.

[StefanSchoof]

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.

[Webwanze]

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.

[tobiasbayer]

Und genau das macht der normale PV-Modus mit Thresholds.

[tobiasbayer]

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.

[andig]

Ich war da vorschnell. Ich machs zu bis ich eine gute Idee habe.

[kscholty]

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?

[andig]

@kscholty Prioritäten haben damit gar nichts zu tun, siehe https://github.com/evcc-io/evcc/pull/6107

[kscholty]

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.

[andig]

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?

[Webwanze]

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.

[StefanSchoof]

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)

[Webwanze]

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.

[tobiasbayer]

Ja, das wäre das, was ich oben meinte: „man könnte das in den Min+PV bauen“. Fände ich gut.

[Webwanze]

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.

[andig]

Summary bis hierher nach meinem Verständnis:

• enable/disable Thresholds beeinflussen das Start/Stop Verhalten, aber nicht den Arbeitspunkt der Regelung
• Arbeitspunkt der Regelung wird über residualPower eingestellt- so machen wir das heute bei Hausbatterie (residualPower leicht 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.

[StefanSchoof]

Ich habe den Wert bisher immer gleich gehabt und da die beiden unterschiedliche Vorzeichen haben, würde ein gemeinsamer Parameter die Konfiguration vereinfachen.

[VolkerK62]

Ich nutze es nicht (bzw. default). Aber, dann würde dieser "Trick" nicht mehr funktionieren https://docs.evcc.io/docs/guides/charging#pv-erzeugung-im-winter-nutzen

[andig]

Guter Hinweis. Ich denke es wäre anders, aber nicht funktioniert dennoch.

Ich hab mal den Versuch gemacht das was ich meine aufzudröseln. Oben die As-is Situation, im gelben Kasten die neue Konfiguration. Der erste Fall- alle Werte sind Null ist heute/morgen identisch:

Wenn man das so anschaut wird klar, dass der neue "Arbeitspunkt" ein Netzbezugslimit darstellt. Alternative Möglichkeiten wären das als Einspeiselimit abzubilden oder als prozentualen Deckungsgrad der EV-Mindestleistung. Das wäre nochmal eine Diskussion wert. Mit diesem Parameter sind wir m.E. auch deutlich näher an der Realisierung eines Sommer/Wintermodus dran.

Wir nehmen allerdings auch Hysterese weg, aber das ist a) heute in den Standardeinstellung auch so, kann b) über die Timer realisiert werden und wird c) im Tagesverlauf durch steigenden Sonnenstand kompensiert.

Was übersehe ich oder was fehlt?

[VolkerK62]

Bei enable.threshold: -200 spielt die Mindestladeleistung keine Rolle. Es wird eingeschaltet, wenn 200 W Einspeisung vorhanden sind.

[StefanSchoof]

Wie würde sich der Arbeitspunkt mit einem residual Power auswirken?

[andig]

Bei enable.threshold: -200 spielt die Mindestladeleistung keine Rolle. Es wird eingeschaltet, wenn 200 W Einspeisung vorhanden sind.

@VolkerK62 macht vom Ergebnis aber keinen Unterschied. Am Ende hängt ja ein Auto dran das lädt. Oder?

Wie würde sich der Arbeitspunkt mit einem residual Power auswirken?

@StefanSchoof residualPower wirkt vorher und verschiebt den für den Ladepunkt sichtbaren Netzbezug.

[VolkerK62]

@VolkerK62 macht vom Ergebnis aber keinen Unterschied. Am Ende hängt ja ein Auto dran das lädt. Oder?

Für die Vergleichbarkeit macht es schon einen Unterschied

[andig]

Für die Vergleichbarkeit macht es schon einen Unterschied

Ist das eine Korrektur zu meiner Tabelle oben? Für welchen Szenario? Falls nein: was meinst Du mit "Vergleichbarkeit", was ist vergleichbar womit und inwiefern ist das für evcc relevant?

[VolkerK62]

Ja, sollte eine Korrektur sein von Fall 2 (aktueller Zustand). Und Vergleichbarkeit war bezogen auf die 2 Fälle im gelben Kasten.

Wenn der neue Arbeitspunkt bei enable die Mindestladeleistung berücksichtigt, dann sehe ich erhebliche Verständnisprobleme. Man muss "200W" einstellen, wenn bei "1200W" Einspeisung bei 1p die Ladung starten soll.

[andig]

Guter Punkt. Bleiben wir aber nochmal bei aktuellen Verhalten. So korrekt?

Dann zeigen die Felder in rot, dass das aufgrund Fehlkonfiguration schwingt. Auch nicht schön.

[VolkerK62]

So ist der status quo.

Dann zeigen die Felder in rot, dass das aufgrund Fehlkonfiguration schwingt.

Stimmt, hier wirkt nur das delay dem schwingen entgegen.

[naltatis]

@andig Wollen wir den hier zu machen? Ich find die aktuellen Thresholds relativ gut verständlich aus Nutzersicht und hilfreich, wenn wenig PV Leistung existiert.

[andig]

Ich würde gerne nochmal drauf rum kauen, vllt. mit @premultiply. Die Ambition statt zwei Werten einen Slider analog SHM zu haben finde ich immer noch gut. Ist aber nix kurzfristiges...

[naltatis]

Ok, dann lass uns gerne zusammen drüber sprechen. In meinem Kopf wären die jetzigen Thresholds auch nur ein Slider in der UI bei dem man den Anteil des akzeptablen Netzbezugs einstellt. Die beiden Zahlen würde ich daraus ableiten.

[VolkerK62]

Zumindest negative disable threshold kann weg, weil wirkungslos. https://github.com/evcc-io/docs/issues/559