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 #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 #6106 (comment) it becomes clear, that the smart loads (renamed to aux in #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.

[andig]

@kscholty Prioritäten haben damit gar nichts zu tun, siehe #6107

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

[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.
evcc-io/docs#559

[andig]

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.

Ich bin gedanklich noch nicht viel weiter. Ich versuche mal meine Gedanken durch Aufschreiben zu sortieren.

Heute haben wir eine Art "Netzanteil=0%" Regelung. Die Ladung beginnt dann, wenn minPower in Form von sitePower zur Verfügung steht und endet sobald as nicht mehr der Fall ist (plus/minus angepasste Thresholds).

Wenn wir stattdessen jetzt "Netzanteil=100%" machen wollten dann könnten wir immer laden (kommt ja eh aus dem Netz). Unterstellen wir mal, dass wir dafür mindestens die negative 0 sitePower für enable brauchen. Disable käme dann wenn >100% minPower bezogen würden (bin grad unsicher ob sitePower oder gridPower).

In beiden Fällen könnte man enable/disable thresholds jeweils aus dem Netzanteil und minPower für das jeweilige Fahrzeug berechnen. Es bräuchte dazu vmtl. noch eine Hysterese da wird sonst um delay schwingen.

Sonderthema: Nicht klar ist das Verhalten bei mehreren Ladepunkten. Die Definition von "Netzanteil=100%" bekommt hier einen neuen Geschmack. Es kann wohl nicht gemeint sein "100% der Summe aller Minimalleistungen" sondern eher "100% der maximalen Minimalleistung eines Ladepunkts".

In Summe: mir ist grad nicht ganz klar, woran wir hier eigentlich in der Umsetzung gescheitert sind. Seht ihr konzeptionelle Fehler? Sollen wir die Diskussion nochmal aufnehmen?

[StefanSchoof]

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

Ich muss diese Aussage mittlerweile revidieren.

Ich habe keinen Speicher. Daher hatte ich oft das Problem, dass morgens das Laden angefangen hat und dann aufgrund von einer kleinen Wolke oder einem zusätzlichen Verbraucher fast sofort wieder beendet wurde. Das habe ich jetzt durch einen höheren enable threshold, während der disable threshold normal ist gelöst.

Die Idee mit dem Solar share gefällt mir. Für meinen Usecase bräuchte ich aber noch eine Art von Einschaltschwelle.

[andig]

Das sofortige Ausschalten sollte ja eigentlich das Delay verhindern.

Die Idee mit dem Solar share gefällt mir. Für meinen Usecase bräuchte ich aber noch eine Art von Einschaltschwelle.

Eine zusätzliche Hysterese (z.B. default 50W) für den Arbeitspunkt könnte helfen. Dann sind wir aber doch wieder bei 2 Parametern statt einem und Deine Leistung springt bei Wolke sicher um mehr als 50W.

[VolkerK62]

Normalerweise schauen enable/disable auf sitePower .
Wenn man jetzt i.V.m. solarShare bei enable auf gridPower schaut, dann hätte man (positive) residualpower als Hysterese.

[andig]

Es muss weiter auf sitePower geschaut werden denn uns interessiert ja auch der Akku. Und da ist residualpower schon drin.

[StefanSchoof]

Das sofortige Ausschalten sollte ja eigentlich das Delay verhindern.

Die Idee mit dem Solar share gefällt mir. Für meinen Usecase bräuchte ich aber noch eine Art von Einschaltschwelle.

Eine zusätzliche Hysterese (z.B. default 50W) für den Arbeitspunkt könnte helfen. Dann sind wir aber doch wieder bei 2 Parametern statt einem und Deine Leistung springt bei Wolke sicher um mehr als 50W.

Ich möchte nicht das Ausschalten verhindern, sondern schon das ein Einschalten.

Ich habe den enable Threshold auf 2400. Das erreicht meine Anlage 1 Stunde später als die minimale Ladung von 1p. Im Sommer reicht meine Anlage für meine Kilometer auch ohne diese Stunde, wo die Ladung oft Unterbrochen wird, sei es durch einen Wasserkocher oder eine Wolke.

[VolkerK62]

Ich hoffe, ich habe das bisher richtig verstanden.
Mit diesem Regler "Solar Share" kann man festlegen, wieviel der minimalen Ladeleistung aus dem Netz kommen soll?
Wie wäre es, wenn man die Hysterese analog zur Solar Share Einstellung gestaltet.
Beispiel für 1p (min=1400W):
Solar Share Einstellung 50%.
Dann wird eingeschaltet wenn 700W Überschuss vorhanden sind. Wenn die Ladung läuft, sind 700W Netzbezug vorhanden. Disable threshold wäre in dem Fall dann bei 1050W Netzbezug (700W + 50% von 700)

Wenn man dem Regler einen Bereich von -100% bis +100% gibt, sähe es tabellarisch so aus

[andig]

Wozu würdest du einen Solaranteil von -100% verwenden? Ich verstehe auch deine Schellen nicht. Schau mal in den PR, da siehst du die angedachte Rechnung.

[VolkerK62]

Wozu würdest du einen Solaranteil von -100% verwenden?

um einen Anteil Einspeisung zuzulassen. Wenn z.B. nur der Mittagspeak weggespeichert werden soll.

Oder um am Anfang mögliches an/aus zu vermeiden.
So hatte ich den Beitrag von @StefanSchoof verstanden

Ich möchte nicht das Ausschalten verhindern, sondern schon das ein Einschalten.
Ich habe den enable Threshold auf 2400. Das erreicht meine Anlage 1 Stunde später als die minimale Ladung von 1p. Im Sommer reicht meine Anlage für meine Kilometer auch ohne diese Stunde, wo die Ladung oft Unterbrochen wird, sei es durch einen Wasserkocher oder eine Wolke.

[VolkerK62]

Schau mal in den PR, da siehst du die angedachte Rechnung.

enableThreshold := -lp.GetSolarShare() * lp.EffectiveMinPower()
Das bedeutet 100% entspricht dann aktuell threshold: 0
Dann macht natürlich auch -100% keinen Sinn.
Das bedeutet doch dann aber, sobald Überschuss = MinPower, wird eingeschaltet.
Wie kann ich dann "verspätet" einschalten lassen?

Edit: Ich hatte "SolarShare" falsch verstanden. Meine Tabelle basiert auf "Grid use"

[andig]

Ich möchte nicht das Ausschalten verhindern, sondern schon das ein Einschalten.

Ich hab ehrlich gesagt immer noch nicht verstanden warum. Ist Dein enable/disable delay einfach zu kurz?

um einen Anteil Einspeisung zuzulassen. Wenn z.B. nur der Mittagspeak weggespeichert werden soll.

Mhhm- würde man das nicht mit Residualpower erreichen? Das bleibt dann natürlich auch mittags so. Ich vestehe aber generell nicht so richtig, wozu das dienen soll. In der Mimik der PRs wäre das vmtl. eher ein Solaranteil von >100%.

[VolkerK62]

würde man das nicht mit Residualpower erreichen?

das wirkt dann aber global und nicht nur auf den Loadpoint.

In der Mimik der PRs wäre das vmtl. eher ein Solaranteil von >100%.

Deshalb wäre es evtl zu überlegen auf den "akzeptablen Netzbezug" (statt Solaranteil) zu gehen?

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.

[StefanSchoof]

Ich möchte nicht das Ausschalten verhindern, sondern schon das ein Einschalten.

Ich hab ehrlich gesagt immer noch nicht verstanden warum. Ist Dein enable/disable delay einfach zu kurz?

Es ist ein Weg um ein Einschalten in morgens um eine Stunde nach hinten zu schieben. Für diesen Effekt müsste ich das enable delay sehr stark erhöhen. Das würde dann auch Mittags, wenn die Wolken weg gehen wirken. Ich habe ein bisschen mit den Parametern rum gespielt und diese Kombination hat in Praxis für mein Setup gut funktioniert.

Ich denke eigentlich, dass ist ein Problem, dass mehr Nutzer ohne Akku haben müssten, aber wenn du entscheidest, mein Usecase ist zu speziell, werde ich schon eine andere Lösung für mich finden.

[andig]

Es ist ein Weg um ein Einschalten in morgens um eine Stunde nach hinten zu schieben.

Das hab ich schon verstanden. Aber warum? Mir gehts um den Use case, nicht um das Setting.

aber wenn du entscheidest, mein Usecase ist zu speziell, werde ich schon eine andere Lösung für mich finden.

Was ist ist der Use case? Was bezweckst Du mit "ich will verschieben"? Und würde Dir hier ein Solaranteil > 100% dafür als Parameter auch reichen?

[StefanSchoof]

Ziel ist es möglichst hohen PV Strom Anteil, wenn kein Hausakku im System ist und sehr viele An und Aus Zyklen bei der Wallbox zu vermeiden.

Wenn ich mit 1p minimal Leistung sofort anfange zu laden, kommt es oft vor, dass nicht mehr genug Leistung für das Auto vorhanden ist und bis zum disable delay Netzstrom gezogen wird und damit der PV Anteil runter geht.

Wenn die Ladung erst bei höheren Sonnenstand anfängt, kann die Ladung auch bei ein paar Minuten Wasserkocher oder Geschirrspüler weiter laufen. Damit ist dann mein PV Anteil für das Auto höher und die Wallbox schaltet nicht so oft an und aus.

[andig]

Ziel ist es möglichst hohen PV Strom Anteil, wenn kein Hausakku im System ist und sehr viele An und Aus Zyklen bei der Wallbox zu vermeiden.

Das verstehe ich :). Aber: das Problem hast Du morgens beim Start genauso wie tagsüber bei wechselnder Bewölkung. Ebenso abends bzw. beim Disable. Innerhalb des Intervalls musst Du prinzipiell mit Bezug rechnen. Daher passt hier m.E. ein Threshold viel schlechter als schlicht eine Verschiebung der Arbeitspunktes mittels residualpower.

Ebenso wäre für den PR denkbar, auch Solaranteil > 100% zu erlauben.

[StefanSchoof]

Vielleicht verstehe ich dann residualpower noch nicht richtig.

Mein Verständnis wäre:
Wenn bei residualpower: 1000 und 2400 Watt ins Netz geht, beginnt die Ladung des Autos. Wenn ich jetzt den Wasserkocher mit 900 Watt an mache würde nach 3 Minuten die Ladung beenden und wenn der Wasserkocher fertig ist wieder gestartet. Es gebe keinen Netzbezug.

Bei einem enable Threshold von 2400, würde zwischen anschalten des Wasserkocher und dem nächsten Intervall 900 Watt aus dem Netz geladen (also ein paar Sekunden), aber die restliche Zeit würde die Ladung des Autos und der Wasserkocher mit PV Strom fortgesetzt. Es wäre am Ende mehr Strom im Auto.

Das hat beides seine Vorteile und hängt davon, ob man möglichst viel Strom ins Auto bekommen möchte (weil bald eine lange Fahrt vor hat oder die Sonnenstunden im Herbst seltener werden) oder man Zeit hat das Auto voll zu bekommen.