Feature Idee: Tibber und laden wenn Preis < Wert

[sebnaf]

Ausgangssitution:
Tesla, an 5 von 7 Tagen an der Wallbox, Wächter aktiv

Wunsch:

• wenn PV Überschuss, dann lade bis gesetzter SoC erreicht - funktioniert bestens
• wenn Tibber Strompreis unter beispielhaft 20ct, dann lade entweder bis SoC erreicht oder Preis wieder über 20ct

Ich möchte keine Pläne über imaginäre Abfahrtszeiten oder ähnliches pflegen, sondern einfach "einstecken" und wissen dass es die Sonne regelt oder alles unter 20ct Einkauf.

[maf-soft]

Zusatzwunsch: wenn in dem Zeitraum, wo der Preis bekannt ist, mehr Stunden unter der Preisschwelle sind, als für die Ladung benötigt werden, werden davon nur die günstigsten genommen, ähnlich wie auch beim Zielladen.
Wenn dann noch von der Sonne geladen wird oder um 13:00 neue Preise bekannt werden, muss rekalkuliert werden.

Und natürlich möchte ich später die Schwelle über die Gui ändern können - für den ersten Test reicht die config. Wie wärs mit einem Parameter namens "cheap"? :)

P.S.: hier auch Tesla 🏎️ immer angeschlossen

[andig]

Mit anderen Worten: ihr wollt cheap zurück. Gilt das „immer“ oder wär das nur aktiv wenn eben grad kein Ladeplan eingestellt ist? Letzteres fände ich plausibel und würde auch gut passen. Ein Default von 0.0 würde dann dazu führen, dass bei negativen Rpeiswn immer geladen würde was auch noch netzdienlich wäre.

[andig]

Auch ne coole Idee! Letzlich entspräche das dann einem festen kWh Wert je Tag.

[sebnaf]

Für mich ist es ganz klar der Preis, den ich so konfiguriert habe, dass er sicher einmal die Woche "getroffen" wird.

[Optic00]

Könnte man statt dem Preis nicht einfach die von Tibber bereitgestellte Preisinfo nutzen? "Very Cheap", "Cheap", "Normal", "Expensive" und "Very Expensive" wird als Kategorie über die API mitgegeben. Einen fixen Preis zu nutzen wird vermutlich immer wieder Nacharbeit erfordern.

[sebnaf]

Das wäre sehr dynamisch https://developer.tibber.com/docs/reference#pricerating
Ich frage mich, für wen das Sinn macht. Ich für meinen UseCase wüsste genau, ab welchem ct-Beitrag ich das wollen würde. Ist auch stark von der Region abhängig.

Man könnte es konfigurierbar machen: use fixed (ct aus der config) / dynamic (aus pricerating) pricing

[naltatis]

Die Tibber Einstufungen sind natürlich nett. Der Einfachheit halber würde ich die aber erstmal raus lassen. Das wäre dann ja speziell auf einen Anbieter zugeschnitten. Keine Ahnung ob Octopus oder Awattar was ähnliches anbieten und ob/wie das dann kompatibel wäre.

[sebnaf]

Wenn ich das alles so lese, könnte ich mir vorstellen:

• cheap-Preis zurück in die Konfig
• Menü/Einstellungen Schalter "Tibber "cheap-laden"

Diese Option hat niedrigste Prio im Ladeverhalten und sämtliche PV-Vorgänge/Zeitpläne haben Vorrang.
Im Winter/Sommer einmal das Ding an/aus zu machen ist auch vertretbar.

Ein Laden/Stoppen-Flapping erwarte ich nicht, da die Tibber-API Preise auf Stundenbasis ausgibt - kleinste Ladeeinheit somit eine Stunde.
Idealerweise wird im Modes "Schnell" unter Berücksichtigung von 1p3p geladen (maximal schnell günstig laden)

[naltatis]

Aktuell ist der cheap Wert global definiert und hat (wenn ich mich richtig erinnere) auch keine API zu ändern zur Laufzeit.
Ich find die Idee gut in der UI direkt zwischen den Modi "Laden wenn Strom unter X€ ist" und "Lade zu Zeit X auf Y%" wählen zu können. Ich mach mir mal Gedanken wie das im Zielladen-Dialog aussehen könnte. Inkl Vorschau im Balkendiagramm.
Dafür bräuchten wir dann aber eine Schnittstelle mit der der cheap Wert pro Loadpoint (so funktioniert aktuell die Zielladen UI) gesetzt/entfernt werden kann.

[naltatis]

Das Thema "Lade X Stunden in Zeitraum Y" würde ich beim UI Konzept mit bedenken, aber erstmal noch nicht umsetzen. Das ist ja auch noch etwas komplexer (Zeiträume und so).

[naltatis]

Sollte der Planner aktiv sein hat der im Zweifel einen noch besseren Plan oder der Slot gehört ohnehin zum Plan.

Ja hier müssen wir ne klare Regelung finden, dass es da keine Verwirrung gibt. Fänd auch gut, wenn man der API bzw. dem State das gleich ansehen könnte. Bspw. dadurch dass das Setzen einer Zielzeit den cheap Wert des des LPs entfernt und anders herum. Alternativ kann man das auch als eine Modus ausimplementieren zwischen dem per API hin und hergewechselt werden kann. Aber das können wir auch später immer noch machen wenns komplexer wird.

[maf-soft]

API

Interessehalber: ist damit die API gemeint, auf die die GUI zugreift?

[naltatis]

Ja, die REST API
https://docs.evcc.io/docs/reference/api/#rest-api