Tibber: Support smartcharging by relative price level

[cschlipf]

Is your feature request related to a problem? Please describe. Smart charging using tibber works only via a fixed price. However the prices are changing. What is considered expensive this week, might be considered cheap next week. Now the car might not be charging because the fixed price will not be achieved during the next week.

Describe the solution you'd like Enable smart charging based on the price levels provided by tibber. They provide a 'level' attribute, which can be taken as a relative price, which is a value of 'VERY_EXPENSIVE', 'EXPENSIVE', 'NORMAL', 'CHEAP', 'VERY_CHEAP'.

See additional context below for a sample request.

With this level the user could select a level instead of a price. For example if the user sets 'CHEAP', smart charging would start, when it sees a cheap price, instead of a fixed level. It could even be smarter and check if in the next 2-3 hours a 'VERY CHEAP' occurs and delay charging until then automatically.

Describe alternatives you've considered Alternative would be a statistical analysis of past and future Tibber prices and do the rating with EVCC. However as Tibber provides the info already, using this would be easier.

Additional context Tibber GraphQL example:

Request:

{
  viewer {
    homes {
      currentSubscription{
        priceInfo{
          current{
            total
            energy
            tax
            startsAt
            level
          }
          today {
            total
            energy
            tax
            startsAt
            level
          }
        }
      }
    }
  }
}

Response:

{
  "data": {
    "viewer": {
      "homes": [
        {
          "currentSubscription": {
            "priceInfo": {
              "current": {
                "total": 0.3146,
                "energy": 0.1288,
                "tax": 0.1858,
                "startsAt": "2023-11-20T15:00:00.000+01:00",
                "level": "EXPENSIVE"
              },
              "today": [
                {
                  "total": 0.2426,
                  "energy": 0.0683,
                  "tax": 0.1743,
                  "startsAt": "2023-11-20T00:00:00.000+01:00",
                  "level": "NORMAL"
                },
                {
                  "total": 0.2359,
                  "energy": 0.0627,
                  "tax": 0.1732,
                  "startsAt": "2023-11-20T01:00:00.000+01:00",
                  "level": "NORMAL"
                },
                {
                  "total": 0.2326,
                  "energy": 0.0599,
                  "tax": 0.1727,
                  "startsAt": "2023-11-20T02:00:00.000+01:00",
                  "level": "CHEAP"
                },
                {
                  "total": 0.2328,
                  "energy": 0.06,
                  "tax": 0.1728,
                  "startsAt": "2023-11-20T03:00:00.000+01:00",
                  "level": "NORMAL"
                },
                {
                  "total": 0.2384,
                  "energy": 0.0648,
                  "tax": 0.1736,
                  "startsAt": "2023-11-20T04:00:00.000+01:00",
                  "level": "NORMAL"
                },
                {
                  "total": 0.2571,
                  "energy": 0.0804,
                  "tax": 0.1767,
                  "startsAt": "2023-11-20T05:00:00.000+01:00",
                  "level": "NORMAL"
                },
                {
                  "total": 0.2836,
                  "energy": 0.1028,
                  "tax": 0.1808,
                  "startsAt": "2023-11-20T06:00:00.000+01:00",
                  "level": "NORMAL"
                },
                {
                  "total": 0.3138,
                  "energy": 0.1281,
                  "tax": 0.1857,
                  "startsAt": "2023-11-20T07:00:00.000+01:00",
                  "level": "EXPENSIVE"
                },
                {
                  "total": 0.3121,
                  "energy": 0.1267,
                  "tax": 0.1854,
                  "startsAt": "2023-11-20T08:00:00.000+01:00",
                  "level": "EXPENSIVE"
                },
                {
                  "total": 0.3023,
                  "energy": 0.1184,
                  "tax": 0.1839,
                  "startsAt": "2023-11-20T09:00:00.000+01:00",
                  "level": "EXPENSIVE"
                },
                {
                  "total": 0.2948,
                  "energy": 0.1122,
                  "tax": 0.1826,
                  "startsAt": "2023-11-20T10:00:00.000+01:00",
                  "level": "NORMAL"
                },
                {
                  "total": 0.2875,
                  "energy": 0.106,
                  "tax": 0.1815,
                  "startsAt": "2023-11-20T11:00:00.000+01:00",
                  "level": "NORMAL"
                },
                {
                  "total": 0.2839,
                  "energy": 0.103,
                  "tax": 0.1809,
                  "startsAt": "2023-11-20T12:00:00.000+01:00",
                  "level": "NORMAL"
                },
                {
                  "total": 0.2969,
                  "energy": 0.114,
                  "tax": 0.1829,
                  "startsAt": "2023-11-20T13:00:00.000+01:00",
                  "level": "EXPENSIVE"
                },
                {
                  "total": 0.3046,
                  "energy": 0.1204,
                  "tax": 0.1842,
                  "startsAt": "2023-11-20T14:00:00.000+01:00",
                  "level": "EXPENSIVE"
                },
                {
                  "total": 0.3146,
                  "energy": 0.1288,
                  "tax": 0.1858,
                  "startsAt": "2023-11-20T15:00:00.000+01:00",
                  "level": "EXPENSIVE"
                },
                {
                  "total": 0.3279,
                  "energy": 0.1399,
                  "tax": 0.188,
                  "startsAt": "2023-11-20T16:00:00.000+01:00",
                  "level": "EXPENSIVE"
                },
                {
                  "total": 0.3363,
                  "energy": 0.147,
                  "tax": 0.1893,
                  "startsAt": "2023-11-20T17:00:00.000+01:00",
                  "level": "EXPENSIVE"
                },
                {
                  "total": 0.3279,
                  "energy": 0.14,
                  "tax": 0.1879,
                  "startsAt": "2023-11-20T18:00:00.000+01:00",
                  "level": "EXPENSIVE"
                },
                {
                  "total": 0.3161,
                  "energy": 0.1301,
                  "tax": 0.186,
                  "startsAt": "2023-11-20T19:00:00.000+01:00",
                  "level": "EXPENSIVE"
                },
                {
                  "total": 0.3042,
                  "energy": 0.12,
                  "tax": 0.1842,
                  "startsAt": "2023-11-20T20:00:00.000+01:00",
                  "level": "EXPENSIVE"
                },
                {
                  "total": 0.2887,
                  "energy": 0.107,
                  "tax": 0.1817,
                  "startsAt": "2023-11-20T21:00:00.000+01:00",
                  "level": "NORMAL"
                },
                {
                  "total": 0.2899,
                  "energy": 0.108,
                  "tax": 0.1819,
                  "startsAt": "2023-11-20T22:00:00.000+01:00",
                  "level": "NORMAL"
                },
                {
                  "total": 0.2776,
                  "energy": 0.0977,
                  "tax": 0.1799,
                  "startsAt": "2023-11-20T23:00:00.000+01:00",
                  "level": "NORMAL"
                }
              ]
            }
          }
        }
      ]
    }
  }
}

Tibber API documentation on the price level attribute: https://developer.tibber.com/docs/reference#pricelevel

[andig]

Ich bin nicht davon überzeugt, dass das sinnvoll ist. Was Tibber für günstig hält muss nichts mit meiner lokalen Versorgungssituation zu tun haben? Und falls es das bräuchte wäre es vielleicht sinnvoller, diese Ranges lokal und API-unabhängig zu berechnen?

[cschlipf]

Ich sehe das auch nicht als Ersatz des aktuellen Modus an, sondern als bequemere Alternative, die verhindert, dass mann wöchentlich die Preisgrenze manuell anpassen muss.

Und wie Tibber dieses Rating berechnet haben sie ja dokumentiert. Eine lokale Berechnung hätte natürlich den Vorteil, dass es auch mit anderen dynamischen Stromanbietern funktioniert.

[goebelmeier]

Und falls es das bräuchte wäre es vielleicht sinnvoller, diese Ranges lokal und API-unabhängig zu berechnen?

Das halte ich für eine gute Idee. Das nutze ich aktuell in Home Assistant und baue mir dieses Ranking über die letzten 3 Tage, so wie Tibber es tut, und über den aktuellen Tag und entscheide anhand dessen wann ich meinem Heimspeicher den Befehl gebe sich nachzuladen. Aufgrund der Ein- und Ausspeiseverluste lasse ich den nur bei VERY_CHEAP laden. Elektroautos könnte man aber ggf schon bei CHEAP laden lassen.

Ich bin auch der Meinung, dass ein statisches Limit vor 2-3 Jahren gut und ausreichend war. Die Preise sind und werden aber immer volatiler, so dass eine Abweichung vom Average möglicherweise das sinnvollere Entscheidungskriterium ist.

[andig]

Das halte ich für eine gute Idee. Das nutze ich aktuell in Home Assistant und baue mir dieses Ranking über die letzten 3 Tage,

Müsste man hier eher forward-looking über die Tarife machen da wir die alten Daten nicht persistieren. Das gäbe dann aber maximal 48h.

Stellt sich dann wieder die Frage, wie der Anwender das einstellen sollte?

[cschlipf]

Das halte ich für eine gute Idee. Das nutze ich aktuell in Home Assistant und baue mir dieses Ranking über die letzten 3 Tage,

Müsste man hier eher forward-looking über die Tarife machen da wir die alten Daten nicht persistieren. Das gäbe dann aber maximal 48h.

2 Tage sind doch schon echt gut

Stellt sich dann wieder die Frage, wie der Anwender das einstellen sollte?

Könnte man im Preisgrenze Drop Down einfach ein paar Platzhalter oben einfügen:

• Sehr teuer
• Teuer
• Normal
• Billig
• Sehr billig (wobei man die ersten beiden Werte vermutlich gar nicht bräuchte)

[andig]

@naltatis mir fällt (wieder?) auf, dass der Verbindungsstrich in dem Font unglücklich ist. Sollen wir lieber die ... verwenden?

[Hofyyy]

Das wäre auch nice um den Speicher zu laden. Da würde ich Super Cheap setzen und gut ist :-)

[cschlipf]

Das wäre auch nice um den Speicher zu laden. Da würde ich Super Cheap setzen und gut ist :-)

Mache ich in Home Assistant so ;-)

[naltatis]

@naltatis mir fällt (wieder?) auf, dass der Verbindungsstrich in dem Font unglücklich ist. Sollen wir lieber die ... verwenden?

Das ist ein alter Screenshot. So sieht das heute nicht aus.

[naltatis]

Ich halt das Feature für gut. Ich wäre auf jeden Fall dafür, das anbieterunabhängig direkt in evcc zu berechnen. Für Einfachheit würde ich das auf jeden Fall stateless machen. Also keine historischen Daten sammeln, sondern den Durchschnitt auf Basis aller momentan sichtbaren Preisfenster berechnen. Wir könnten erstmal mit dem Algorithmus von Tibber starten (60% below avg, 90% below avg). Das wäre ja relativ leicht umzusetzen.

[naltatis]

Vom Wording sollten wir hier generisch auf LOW / VERY LOW gehen damit das auch für gCO2eq anwendbar ist.

[premultiply]

Top! 👍🏼 Muss ich demnächst doch auch noch unter die Strompreiszocker gehen? 🤔

[Hofyyy]

Ich sage nur Netzdienlich. Alles im Namen des Volkes … 😎

[andig]

Vom Wording sollten wir hier generisch auf LOW / VERY LOW gehen

Brauchen wir denn dann überhaupt noch Preislevel? Oder nicht eher eine relative Preisgrenze analog 60%=very cheap? Wenn ich bei "cheap" laden will kann ich ja die Grenze ändern. Braucht es dann noch relative und absolute Grenze oder reicht die relative?

[cschlipf]

Wie macht man im UI klar, dass 60% = 60% unter Durchschnitt von 2 Tagen ist?

Denke Low und Very Low wäre da vielleicht verständlicher, wenn auch nicht ganz so fein. Und man sieht dann ja trotzdem in der Preview, wann der Ladevorgang starten würde.

[cschlipf]

Man könnte im Drop down vielleicht:

• Ø - 30%
• Ø - 60%
• Ø - 90%

als Listenpunkt führen?

[andig]

Erstmal sollten wir klären was es braucht, dann wie es Angezeigt wird.

[naltatis]

Erstmal sollten wir klären was es braucht, dann wie es Angezeigt wird.

Das hängt doch immer zusammen. Vom User denken und so :D

Ich würde sagen, wir brauchen auf jeden Fall beide Welten (fixe Grenze und relative Grenze). Möchte meinen Heizstab bspw. nur dann anwerfen, wenn der Strom günstiger als die Pellets (fixe Grenze). Beim Auto erspare ich mir vmtl. einiges nach Prüfen und Nachregeln, wenn wir ne relative Grenze haben.

Ich würd die Grenzen aber exklusiv zueinander bauen. Heißt, es gibt immer nur eine Grenze zur Zeit und die kann relativ oder absolut sein.

[andig]

Ich würde sagen, wir brauchen auf jeden Fall beide Welten (fixe Grenze und relative Grenze).

meine Frage war, ob es Levels braucht (very cheap, cheap…).

Brauchen wir denn dann überhaupt noch Preislevel?

Antwort: nein soweit ich das sehe.

[naltatis]

Doch, ich würd den Nutzer da ungern ne freie Prozentzahl eintragen lassen. Per API vielleicht, aber hier find ich die Idee von den benamten Stufen gut.

[naltatis]

In der Umsetzung können wir das natürlich zu nem reinen UI-Thema machen. Dafür bräuchte die UI die Info was der aktuelle Durchschnittspreis ist um hier mehr Kontext für den Nutzer geben zu können. Wie viele und welche Optionen dann für die relative Grenze angeboten werden, ist dann ein separates Thema.

[developer-stephan]

Könnte man es nicht einfacher machen? Eine Option zum Aktivieren oder Deaktivieren:

Nur die günstigen Stunden zum Laden automatisch verwenden.

[andig]

Einfach als was? Was sind „die günstigen“ Stunden?

[developer-stephan]

Auf die Schnelle skizziert. Man gibt im Feld 4 Stunden ein dann wird die 4 günstigste zum Laden ausgewählt. Preislevel-Definition ändert sich ständig. Je nach Jahreszeit. Limitierung immer wieder neu setzen. Das fällt alles weg wenn man einfach die günstigste Stunden für die benötigte Ladedauer pro Tag auswählen lässt.

[andig]

Ich würde sagen wir laden entweder kostenoptimiert oder am Ende. Keine komplexen Mischformen.

[developer-stephan]

Yap genau. Kiss-Prinzip. Kostenoptimiert. Mit Preis-Leveln oder überladene Einstellungen oder was auch immer macht keinem recht.

[chrostek]

Beim Auto wäre es wirklich einfach - Ladeziel (Uhrzeit) einstellen und das bis dahin günstigste Zeitfenster nutzen. Das löse ich mit einem kleinen Helper Script jetzt schon erfolgreich seit ein paar Wochen:

$tariff_json = file_get_contents("http://sc-evcc:7070/api/tariff/grid");
$tariff = json_decode($tariff_json, true);

$cheapest['price'] = 999;

// Freitags und Samstags muss das Auto nicht am nächsten Morgen voll sein
if(date("w") >= 5)
{
    $datetime = new DateTime('tomorrow');
    $ladeziel = $datetime->format('Y-m-d 23:59:59');
}
// Ladeziel 5 Uhr Folgetag
else
{
    $datetime = new DateTime('tomorrow');
    $ladeziel = $datetime->format('Y-m-d 05:00:01');
}

foreach ($tariff['result']['rates'] as $rate) {
    if(strtotime($rate['end']) > time() && strtotime($rate['start']) <= strtotime($ladeziel))
    {
        if($rate['price'] < $cheapest['price'])
        {
            $cheapest['price'] = $rate['price'];
            $cheapest['start'] = $rate['start'];
        }
    }
}

$opts = array('http' =>
    array(
        'method'  => 'POST'
    )
);

$context  = stream_context_create($opts);

$result = file_get_contents("http://sc-evcc:7070/api/smartcostlimit/".$cheapest['price'], false, $context);

(PHP Script, läuft unterm Linux einfach im Cron einmal die Stunde)

Insofern kann ich den Wunsch in diesem Issue sehr gut nachvollziehen - auch wenn ich es für mich mit wenig Aufwand schon gelöst habe. Aber für Wärmepumpen und andere Geräte ist es natürlich nicht so einfach. Da müsste wirklich ein Vergleich stattfinden, ob der Tibber Preis günstiger als der (fossile) Energieträger ist.

Einen Nutzen für den Price Level sehe ich aber auch nicht. Entweder der günstigste Preis bis das Auto voll sein soll (Ziel-Uhrzeit) oder Kostenvergleich mit anderem Energieträger.

[developer-stephan]

@chrostek Habe mir dein Code angeschaut. Sehr simple und effektiv. Vielleicht mach ich das auch :)

[andig]

Beim Auto wäre es wirklich einfach - Ladeziel (Uhrzeit) einstellen und das bis dahin günstigste Zeitfenster nutzen.

Du hast grad den aktuellen Planner beschrieben ;)

[chrostek]

Beim Auto wäre es wirklich einfach - Ladeziel (Uhrzeit) einstellen und das bis dahin günstigste Zeitfenster nutzen.

Du hast grad den aktuellen Planner beschrieben ;)

verdammt, den hätte ich mir vielleicht mal anschauen sollen 😂 Mein Script ist trotzdem etwas komfortabler, weil es ohne Eingreifen den Job einfach für jeden Wochentag individuell macht. Den Planner muss ich täglich manuell wieder einstellen. Aber ja, sonst scheint er genau dasselbe zu machen 😉

[cschlipf]

Hm, also ich weiß nicht, was ich vom Vorschlag von @developer-stephan halten soll. Wenn man immer bis zum nächsten Tag aufladen will, mag das eine gute Idee sein. Aber wenn ich gerade jetzt sehe was bei Tibber abgeht, dann ist da gerade eine hochpreisige Phase mit wenig Schwankung da.

Ich muss mein Auto - gerade über das Wochenende aber nicht unbedingt bis zum nächsten Tag aufladen. Daher würde ich 'Sehr günstig' wählen und akzeptieren, dass mein Auto erst in den nächsten Tagen oder falls das nicht klappt dann erst bis zur geplanten Abfahrtszeit aufgeladen wird. Oder vielleicht kommt dann am Sonntag sogar die Sonne raus?

Tibber gibt uns die Daten aber maximal für die nächsten 24 Std, nicht für die nächsten 3 Tage.

Also für mein Profil wäre der Vorschlag von Stephan nicht sonderlich nützlich.

Die Kostenlevel sind bei langfristigem Laden einfach sinnvoller: "Günstig", ich steigere die Wahrscheinlichkeit, dass mein Auto bald aufgeladen wird. "Sehr günstig", ich will eher sparen, akzeptiere aber, dass mein Auto nicht unbedingt zum nächsten Tag voll ist. Ich denke gerade in Kombination mit PV macht das mehr Sinn.

[chrostek]

@cschlipf das macht mein Script letztlich so - kann man als logischen Bug oder Feature beschreiben. Am Wochenende darf es bis 23 Uhr dauern, bis es voll ist. Wenn ich Freitag anklemme und der günstigste Preis Samstag 15 Uhr ist, kommen bis Samstag 15 Uhr aber nochmal neue Preise und vielleicht ist dann das günstigste Sonntag 3 Uhr. Somit lädt das Auto manchmal beim Anstecken am Freitag erst am Sonntag, dafür aber sehr günstig. Bei dem Price Level bin ich trotzdem skeptisch. Denn wenn ich very cheap einstelle und das kommt ne Woche lang nicht (was durchaus passiert), lädt das Auto eine Woche lang nicht ...

[developer-stephan]

@cschlipf Kommt drauf an wie du "sehr günstig" definierst. In dem Fall kann es passieren dass das Auto 3 Monate auf die Ladung warten muss bis es "sehr günstig" ist. Dann ist der Eingriff wieder nötig um das Auto laden zu können.

[cschlipf]

@cschlipf Kommt drauf an wie du "sehr günstig" definierst. In dem Fall kann es passieren dass das Auto 3 Monate auf die Ladung warten muss bis es "sehr günstig" ist. Dann ist der Eingriff wieder nötig um das Auto laden zu können.

Nein, das wird eben nicht der Fall sein, weil man ja keinen festen Preis hat (so wie es heute ist und so wie Du es beschreibst), sondern das anhand des Durschnittpreises relativ fest macht.

[cschlipf]

@cschlipf das macht mein Script letztlich so - kann man als logischen Bug oder Feature beschreiben. Am Wochenende darf es bis 23 Uhr dauern, bis es voll ist. Wenn ich Freitag anklemme und der günstigste Preis Samstag 15 Uhr ist, kommen bis Samstag 15 Uhr aber nochmal neue Preise und vielleicht ist dann das günstigste Sonntag 3 Uhr. Somit lädt das Auto manchmal beim Anstecken am Freitag erst am Sonntag, dafür aber sehr günstig. Bei dem Price Level bin ich trotzdem skeptisch. Denn wenn ich very cheap einstelle und das kommt ne Woche lang nicht (was durchaus passiert), lädt das Auto eine Woche lang nicht ...

Ja, und das ist mir ziemlich egal, weil ich noch den Min Charge Level habe und die geplante Abfahrtszeit.

[developer-stephan]

@cschlipf Ach ich verstehe jetzt nachdem ich dein Anfangspost nochmal gelesen habe. Prozentual nach Tibber-Methode. Man muss nicht den Preis festlegen was günstig ist.

[cschlipf]

Genau. Absolut haben wir doch schon längst. Siehe auch die Antwort von @naltatis : https://github.com/evcc-io/evcc/issues/10848#issuecomment-1823074408

[cschlipf]

Ein anderer Vorschlag. Ich bin vollkommen mit @andig einer Meinung, dass man nicht zuviele Optionen einbauen sollte. Aber wie wäre es mit einer Option 'Intelligentes, Kosten/CO2 optimiertes Laden?' in optionaler Kombination mit Zielladen?

Meine Idee bei aktivierter Option im PV Modus:

• Kein Zielladen aktiv:
  • Laden, wenn sehr günstig (relativ gesehen zum Zeitraum)
  • PV Überschuss immer laden.
  • Wenn Tibber günstiger als Einspeisevergütung, immer laden
• Zielladen aktiv:
  • Ziel mehr als ein Tag weg: Laden, wie wenn kein Zielladen aktiv (siehe oben)
  • Ziel in den nächsten 24 Std. Lade zu den günstigsten Zeiten in den nächsten 24 Std. Dabei sucht man sich die Stunden so heraus, dass man bis zum Ziel mindestens voll lädt. (also Auto braucht noch 3.6 Std, nehme die 4 günstigsten Stunden)
  • Erweiterung dazu: Für NMC Akkus: Lade bis auf 80% intelligent auf, und die restlichen 20% kurz vor Abfahrt, egal welcher Preis

[naltatis]

Zielladen aktiv:

• Ziel mehr als ein Tag weg: Laden, wie wenn kein Zielladen aktiv (siehe oben)

Hier sprichst du das Verhalten an, dass wir die Preisgrenze außer Kraft setzen, wenn eine Zielzeit angelegt wurde. Das müssen wir spätestens beim Einführen der wiederholenden Ladepläne sowieso noch mal angehen. Ich würd hier aber keine fixen Karenzzeiten (max. 1 Tag entfernt oder so) sehen. Dann lieber einfach beides aktiv haben. Sonst wird es schnell unverständlich.

[andig]

Dann lieber einfach beides aktiv haben

Das ist nur konsequent- PV Modus und Planner sind ja auch gleichzeitig aktiv.

[nicx]

coole diskussion. ich werfe noch einen gedanken ein:

aktuell zur winterzeit habe ich pv laden als modus an mit laden wenn preis unter 20cent bei tibber. funktioniert gut. einziges "problem": wenn das auto zb bereits 60% geladen ist und als max soc 80% konfiguriert ist, dann lödt evcc beim nächsten preisfenster unter 20cent sofort los. es passiert dann öfter, dass das auto bereits vollgeladen wird, auch wenn evtl. 4h später der preis noch günstiger gewesen wäre.

der preisladen modus könnte also intelligenter sein, und zumindest die evcc bekannten preise in einr art "automatisches zielladen bis zum socwunsch" mit einberechnen. im vergleich zu @cschlipf s vorschlag braucht das fahrzeug aber nich grundsätzlich als ziel vollgeladen sein. nur "falls" es voll würde, dann nutze die evcc bekannten günstigsten stunden.

ansonsten bin ich schon mit dem jetzigen modus glücklich. ich persönlich brauche keinen relativen preislevel, da ein "cheap" auch bei 40cent sein könnte... was ich eben nicht als günstig sehe ;)

[andig]

Was ist deine Botschaft? Findest Du die Idee der relativen Limits gut?

und zumindest die evcc bekannten preise in einr art "automatisches zielladen bis zum socwunsch" mit einberechnen.

Ich denke hier verwechselst Du das Werkzeug. Das ist die Ladeplanung, die garantiert "billigst".

[nicx]

Was ist deine Botschaft? Findest Du die Idee der relativen Limits gut?

nein, ich finde sie für den täglichen bedarf unnütz, da sie eben "relativ" sind und nichts über die tatsächlichen kosten aussagen.

und zumindest die evcc bekannten preise in einr art "automatisches zielladen bis zum socwunsch" mit einberechnen.

Ich denke hier verwechselst Du das Werkzeug. Das ist die Ladeplanung, die garantiert "billigst".

nein. ich kenne die ladeplanung. und die möchte ich eben nicht nutzen, und trotzdem "billigst" laden.

nochmal mein beispiel:

• auto hängt ständig am lader
• ziel soc des autos ist 80%
• auto hat 60% und bräuchte beispielhaft 1h um die fehlenden 20% zu laden.
• evcc modus ist pv
• preisgrenze ist auf kleiner 20ct gesetzt
• ladeplanung ist aus, da mir egal ist wann die 80% erreicht werden. mir ist auch egal ob überhaupt geladen wird.
• die tibberpreise schwanken beispielhaft in den kommenden 12h zwischen 22ct und 15ct.

in diesem besipiel könnte das fahrzeug über nacht mit zb 19ct/kwh beladen werden, obwohl vielleicht am frühen morgen der preis bei 15ct/kwh läge. zu dem zeitpunkt wäre das auto schon voll. damit verschenkt man bares.

evcc kennt die günstigeren preise des frühen morgens, und auch den soc und die ladeleistung des autos. damit könnte evcc berechnen, das die ladung eben nicht mit 19ct durchgeführt wird, sondern gewartet wird bis zu den 15ct.

[andig]

Versuchen wir mal aus dem Suchspiel eine Anforderung zu machen:

Falls die restliche Energiemenge für den Ladepunkt innhalb der vorhanden Tarifraten unterhalb des smartCostLimits geladen werden kann, sollen die güstigstens Slots anstatt aller Slots unterhalb des smartCostLimits verwendet werden.

Aktuell geht das nicht da smartCostLimit ein Thema der Site ist. Die Idee finde ich charmant, sehe aber noch nicht wie sich das elegant umsetzen lässt. Tatsächlich wäre das ein automatisch erstellter Ladeplan mit Zieltermin zum Ende Raten und gleichzeitige Deaktivierung des Smart Cost Limits.

Und es stellt sich die Frage: was wenn nicht? Dann bist Du beim Ladeplan wenn du günstigst laden willst.

Long story short: Ladepläne garantieren die besten Kosten.

[steve0564]

Brainstrommodus on: Lade die günstigsten "X"-Stunden unterhalb des smartCostLimits...... Bei "1" wird DIE günstigste Stunde genommen bei "2" die zwei günstigsten.. etc... Brainstormmodus off!

[nicx]

Falls die restliche Energiemenge für den Ladepunkt innhalb der vorhanden Tarifraten unterhalb des smartCostLimits geladen werden kann, sollen die güstigstens Slots anstatt aller Slots unterhalb des smartCostLimits verwendet werden.

ja so meine ich das. danke.

Long story short: Ladepläne garantieren die besten Kosten.

bei ladeplänen bräuchte ich immer einen "plan", also einen zeitpunkt wann der zielzustand erreicht sein soll. den habe ich im alltag im modus PV nicht. dort habe ich lediglich den wunsch billigst zu laden. mit überschuss, oder eben mit bezug unterhalb einer dedizierten kostengrenze. das funktioniert ja im grunde heute, mit der ausnahme meines beispiels. dort ließe sich noch geld "rausholen".

[gramss]

Super spannendes Thema.. Habe gemerkt, dass diese Komponente auch für Haus-Batterieladung im Winter bei wenig/kaum PV wichtig ist. Mit der Stromdynamik und Hausbatterie kann so trotzdem der Preis optimiert werden.. (Integration davon ist aber erstmal Offtopic). Daher ein paar Gedanken von mir:

Zwecks API Abhängigkeit (=Anbieterabhängigkeit?) @andig

Was Tibber für günstig hält muss nichts mit meiner lokalen Versorgungssituation zu tun haben? Ranges lokal und API-unabhängig zu berechnen?

Könnte das eine geeignete Datengrundlage sein (direkt den Spotmarktpreis nutzen) : netztransparenz.de ? Interessantes Feld vorallem: Mengengewichteter Day-Ahead Spotmarktpreis

Noch ein paar Ideen..:

Die fixen Nachtstromtarife sind ja schon über die [`smartCostLimit`](https://github.com/evcc-io/evcc/blob/a676fe5cda89dc859fe2ba8e7c7e0f6821ea95e7/core/site.go#L77) Grenze abgebildet. Gibt es überhaupt den Fall Nachtstromtarif & dynamischer Stromtarif? Hier geht es ja nur um dynamische Stromtarife.. Wenn es dir um die technische Lösung geht: Könnte `smartCostLimit` für den Nachtstromtarif-Fall nicht nur als Konstante sondern als tages dynamische Variable für dynamische Tarife via `SetSmartCostLimit` genutzt werden? Wenn das über ein Skript (o.ä.) lokal in `evcc` (1-Tag oder Wochenendminimum) die minimalen zeitlich-lokalen Stromkosten dort eintütet, sollte nicht viel verändert werden müssen? Pseudo-Code/Use Case Ladeplanung (was ich bisher verstanden habe): 1. Auto steckt immer an 2. Prüfen eventuelles Zeitzielladung die normal mit einem fixen-Grid-Preis (?) & PV arbeitet (hier fehlt noch die Interaktion mit dem aktuellen dynamischen Grid-Preis? -> nicht laden wenn "super teuer", aber "teuer" erlaubt?) 3. Die Variable `smartCostLimit` ("Super Cheap"?) wird vom (minuten/stunden) aktuellen geltenden Strompreis (ggf. inkl. "Anbieteraufschlag" zwecks vergleich im Sommer mit PV Kosten?) unterschritten. Solange unterschritten = laden 4. Sprung zurück zur eventuellen Zielladung Auf Basis des (europäischen) Börenpreises müsste man doch die günstigen Zonen Anbieterunabhängig identifizieren können. Was dann die Kostenberechnung angeht, könnte jeder seine Anbieterabhänigen Zuschläge selber eintragen. z.B.: Tibber = XY ct/kWh (kummuliert aus einzelnen Bausteinen, für Endpreis ja aber egal da Bausteine nicht dynamisch sind?) Das hat den Scharm, dass man sich in `evcc` so weitere API Wartungen pro dynamischen Anbieter spart. Bzw. sind die dynamischen Anbieter mit ihren realen Kosten ja schon drinnen. Es ging ja nur um das feststellen des "cheap" Fensters. Das sollte sich ja immer am Spotmarktpreis ableiten bei den dynamischen Anbietern.

[andig]

@gramss ich verstehe nur Bahnhof. Wie passt das in das Thema "relative SmartCost Limits"? Vielleicht lieber separate Diskussion, da müsstest Du Deine Vorschläge aber klarer machen damit ich Dir folgen kann ;)

[andreas-bulling]

Das wäre auch nice um den Speicher zu laden. Da würde ich Super Cheap setzen und gut ist :-)

kann man mit EVCC auch den Speicher laden?!

[andreas-bulling]

Ich finde den Vorschlag äußerst sinnvoll - bei mir zu Hause regle ich genau so, da die absoluten Preise bei einem dynamischen Tarif m.E. wenig Sinn machen bzw. man die ständig von Hand anpassen muss.

Die Preisniveaus von Tibber sind ja nicht gewürfelt, sondern basieren auf echten Werten. Die Niveaus passen sich dann immer automatisch an und man muss als Anwender/in nur noch entscheiden, ob man sein Auto bei CHEAP oder VERY_CHEAP laden möchte. Einfacher geht es nicht.

Tibber bietet über die API auch 24h forecasting an, d.h. man weiß im Voraus, wie sich die Preise stündlich innerhalb der nächsten 24h verändern werden. Das einzubauen macht das ganze noch genialer, da man dann den zukünftigen Preis mit einfließen lassen kann.