Tariff: re-add cheap setting

[andig]

Preis < X (entspricht cheap) gibt Ladung frei falls kein Planner aktiv ist. Sollte der Planner aktiv sein hat der im Zweifel einen noch besseren Plan oder der Slot gehört ohnehin zum Plan.

Originally posted by @andig in #6695 (reply in thread)

[naltatis]

Glaube bislang war cheap nur für Tibber/Awattar? Wir sollten das gleich so einführen, dass gCO2e und manuelle Zeittarife auch unterstützt werden.

[andig]

Ja, ich frag mich wo das hin soll. In die site? Naming (opportunistic charging :)? Und welche Tarife sollten wir berücksichtigen? Analog Planner dessen Tarif als auch Grid?

[naltatis]

@andig was hältst du davon das gar nicht in die Config zu packen sondern es, analog Zielzeit, rein am Loadpoint zur Laufzeit zu halten? Für die Zielzeit wollen wir ja auch eine Persistenzlogik #5271.
Vielleicht lässt sich das verbinden?

Der eingestellt Cheap Wert sollte mMn immer gegen die Datenquelle regeln mit der auch Zielladen arbeitet. Also das was auch unter GET /api/tariff/planner zurückkommt. Da steckt ja momentan eine Logik hinter die CO2 nimmt, sofern konfiguriert und sonst auf den Preis geht, sofern konfiguriert.

[andig]

Können wir machen. Ich hätte allerdings für Persistenz gerne eine allgemeine Lösung bevor wir das weitere Settings mit hinzu fügen. Yaml wär der schnelle Weg.

[naltatis]

Yaml hat halt den Nachteil, dass es nicht zur Laufzeit verstellbar ist. Wir können es auch erstmal ohne Persistenz (analog Zielzeit heute) machen.

[andig]

Wollen wir den cheap Parameter unter site packen? Das hätte den Vorteil 1:1 zum potenziellen API zu matchen. Wie sollte der heissen:

• chargeBelowCost
• cheapRate

finden wir noch was Sprechenderes?

/cc @sebnaf

[sebnaf]

Ich würde noch hinzunehmen dass dies grid Bezug ist:
gridChargeBelowCost

[andig]

Mhhhm. Etwas asynchron to buffer/prioritySoc- beide beschreiben die Schwelle, aber nicht das Verhalten. Und es sollte ja auch der Plannertarif angewandt werden, also nicht nur grid?

[sebnaf]

in dem Fall dann chargeBelowCost.

[andig]

Ist schön sprechend, aber:

Etwas asynchron to buffer/prioritySoc- beide beschreiben die Schwelle, aber nicht das Verhalten

Es fühlt sich auch blöd an, an der site- wo nix geladen wird- von charge zu reden. Aber vielleicht bin ich da zu kleinlich ;)

[sebnaf]

tibberLowPriceThreshold

[andig]

Wir konvergieren: autoChargeCostLimit? cost inkludiert CO2, es ist unabhängig vom Tarif (Tibber...) und der Zweck autoCharge wird auch klar?

/cc @naltatis

[sebnaf]

🚀 👍

[andig]

@sebnaf könntest Du den PR testen? Von meiner Seite fertig; Datenbankpersistenz ist ein anderes Thema.

[naltatis]

Naming: Mich stört das auto in autoChargeCostLimit. Gerade weils hier ja um Autos-Aufladen geht steckt da Verwechslungpotential drin. In der Planner-API sprechen wir überall von price und nicht von cost wenn wir Geld oder CO2 meinen. Daher wäre ich dafür hier auch price zu verwenden.

Nen richtig schönen Namen hab ich auch nicht. Hier aber ein paar weitere Vorschläge: alwaysChargeBelowPrice, gridCheapPrice, gridChargeBelowPrice, gridPriceLimit, gridPriceThreshold

Ich glaube die ich mag die Varianten die weniger das Verhalten beschreiben sondern eher die Eigenschaft des Wertes lieber. Also nicht, was dann passieren soll (gridCharge, alwaysCharge) sondern eher den Zustand den der Wert beschreibt (gibt gerade unverschämt günstigen Strom).

[naltatis]

Zum Verhalten: Im PR ist das Limit jetzt global (site) implementiert. Passt das vom Use-Case? Damit wäre es dann ja erstmal nicht mehr pro Ladepunkt steuerbar.

In den Diskussions gab es ja die Idee dieses Limit auch im Ziellade-Dialog (mit dem Preisdiagramm) einstellbar zu machen. Bspw. als alternativ Option. Zielladen findet aber auf Ladepunktebene statt. Heißt wenn ich den Wert für einen Ladepunkt setze gilt der natürlich auch für die anderen.

Das sind alles lösbare Probleme, spannend ist aber die Frage wie wir glauben dass das am häufigsten benutzt wird. Mit der jetzigen Umsetzung wäre der Cheap Preis die Standardoption die ggf. von Zielladen übersteuert wird.

[hessu]

On behavior: Up here in the north (Finland), our solar panels are still covered in snow. During winter the obvious benefit of using evcc would be to have charging happening during the cheapest market price hours, so getting this feature back will be great!

A static limit in configuration is a bit difficult to work with. On some nights the market price dips to below 0.10€/kWh, or even below 0.05€, and clearly one would want to charge during those hours. But if you configure a limit of 0.12€/kWh, there are plenty of nights when there is no price dip at all (no wind + cold weather), and charging would not happen. If a static limit is configured, it needs to be adjusted every evening, with knowledge of the prices for the next night.

Having a dynamic schedule would be best: I need the car charged at 7 AM, charge at the cheapest possible time depending on market price. But before that, in the mean time, it would be useful to be able to adjust the limit on the web UI in the evening, after checking prices. If that can't be done yet, it'll be a choice between the gridChargeBelowPrice or 'fast' immediate charging mode depending on if a suitable dip matching current static setting exists.

I implemented mqtt-based market price intake in evcc the other night already, to bring in Nordpool FI prices. I'll make a PR later.

[andig]

Schedule would be #5492

[andig]

Zum Verhalten: Im PR ist das Limit jetzt global (site) implementiert. Passt das vom Use-Case? Damit wäre es dann ja erstmal nicht mehr pro Ladepunkt steuerbar.

Denke ja. Günstige Energie bezieht sich auf die Herkunft, nicht auf die Verwendung.

In den Diskussions gab es ja die Idee dieses Limit auch im Ziellade-Dialog (mit dem Preisdiagramm) einstellbar zu machen. Bspw. als alternativ Option. Zielladen findet aber auf Ladepunktebene statt. Heißt wenn ich den Wert für einen Ladepunkt setze gilt der natürlich auch für die anderen.

Einstellbarkeit finde ich gut, aber nur global. Api dafür ist enthalten. Warum sollte "günstig" zwischen den Ladepunkten abweichen?

Das sind alles lösbare Probleme, spannend ist aber die Frage wie wir glauben dass das am häufigsten benutzt wird. Mit der jetzigen Umsetzung wäre der Cheap Preis die Standardoption die ggf. von Zielladen übersteuert wird.

So war es in der Diskussion erstmal angedacht. In der Form einloggen um erstmal einen Schritt weiter zu kommen?

[naltatis]

So war es in der Diskussion erstmal angedacht. In der Form einloggen um erstmal einen Schritt weiter zu kommen?

Ja können wir gerne so machen. Ich bin mir noch nicht ganz sicher wie wir das gut in der UI klar machen. Aber ich überleg mir was.

[andig]

I implemented mqtt-based market price intake in evcc the other night already, to bring in Nordpool FI prices. I'll make a PR later.

@hessu either MQTT input or Nordpool or ENTSO-E would be greatly appreciated. I'd be really interested in your approach to MQTT- didn't find a good generic pattern to design a reusable import interface.