Tibber Grid Rewards und openWB

[kai9555]

Das Thema ist grundsätzlich interessant, da es zum einen der Netzstabilität dient und zum anderen auch noch mit etwas Gutschrift in der monatlichen Stromrechnung belohnt wird. Ich erhalte Montag den Zugang.

https://tibber.com/de/magazine/power-ha ... qvnwfmglbg

Ich habe es im Kopf hoch und runter gespielt, sehe aber keine Möglichkeit wie so etwas harmonisch mit der openWB zusammenarbeiten kann.

Zielgruppe sind eher "dumme" Wallboxen, da man hier Tibber am Ende das "Zielladen" erledigen lässt.

Was meint Ihr - habe ich etwas übersehen..können die Grid Rewards eventuell doch erhalten, trotz das ich alles über die openWB steuere?

VG Kai

[Gero]

Puh, das ist wieder so ein Text, den man erst mal durch eine KI schubsen muss, damit man das ganze Marketing-Gewäsch nicht lesen muss.

Ich denke aber mal, dass das in die Richtung geht, die auch octopus beschreitet: du lässt den Stromverkäufer dein Auto per OEM-API zum laden programmieren und bekommst dafür irgendwelche Goodies.

Tja, auch wenn es eine API gäbe, wo man sich die Ladezeiten abholen könnte, wäre es immer noch fraglich, wie man die erfolgte Ladung nachweisen kann. Ob das Auto nun lädt oder die Sauna lauft, bekommt man am Zähler ja nicht raus.

[kai9555]

Puh, das ist wieder so ein Text, den man erst mal durch eine KI schubsen muss, damit man das ganze Marketing-Gewäsch nicht lesen muss

Das stimmt - ich verstehe es so: Du stellst in Tibber Zielladen ein und das Fahrzeug kann außerhalb der berechneten Day Ahead Preise auch zu "vermeintlich" höheren Preisen geladen werden, da an der Börse neben den Day Ahead Preisen noch kurzfristige Energiemengen gehandelt werden. Für das Abgreifen der kruzfristigen Spitzen bekommt man dann Gutschriften. Oder wenn man zur Drosselung bereit ist.

Ich denke aber mal, dass das in die Richtung geht, die auch octopus beschreitet: du lässt den Stromverkäufer dein Auto per OEM-API zum laden programmieren und bekommst dafür irgendwelche Goodies.

Naja es sind ja nicht irgendwelche Goodies oder Guthaben, sondern tatsächliche eine reale Gutschrift auf deine monatliche Stromrechnung.

Tja, auch wenn es eine API gäbe, wo man sich die Ladezeiten abholen könnte, wäre es immer noch fraglich, wie man die erfolgte Ladung nachweisen kann. Ob das Auto nun lädt oder die Sauna lauft, bekommt man am Zähler ja nicht raus.

Gemäß Tibber würde es bei meiner Hardware vollständig über Tesla laufen (geht auch über Wallboxen wie go-e, aber nicht über openWB). Würde bedeuten man stellt beispielsweise die Wallbox auf Sofortladen und in Tibber dann Zielladen für morgen 9 Uhr ein und Tibber sagt dann dem Auto wann es wie schnell laden soll.

Erstens glaube ich das die angepriesen 150€ Ersparnis nur Best Case sind und man wohl realistisch deutlich darunter liegen kann, dennoch lässt es mich nicht ganz kalt, dass Geld liegen bleibt, wenn ich Zielladen nicht über Tibber aktivieren würde. Zweitens fühlt es sich aber gleichzeitig auch falsch an die openWB zu übergehen und stumpf auf Sofortladen zu stellen.

Aber grundsätzlich: Das Thema wird auch bei EVCC diskutiert und sollte bei openWB nicht unter dem Radar laufen.
https://github.com/evcc-io/evcc/discussions/27320

[Gero]

Stimmt, octopus kann auch Wallboxen steuern. Aber dann muss die vermutlich von draussen immer erreichbar sein, was ja mit der openWB-Cloud eigentlich auch ginge. Oder sollte der go-e bei tibber regelmäßig nachhaken, ob da nun geladen werden kann?

Eine APi-Doku wäre ja mal nett.

[Thomas aus W]

Man könnte die OWB sich ja per OCPP beim Stromanbieter anmelden lassen um darüber Ladebefehle entgegen zu nehmen, aber ich fürchte, dass Tibber und Co nicht soooo sehr standardaffin sind...

bye
TW

[kai9555]

So scheint es ja auch bei anderen Wallboxen zu funktionieren. Hier ein Screenshot der Wallboxen die sich über Tibber steuern lassen.

[Gero]

Tesla Wall connector per OCPP? Ist wohl noch ein Gerücht, bei Tesla selbst steht da nichts von. Tesla wird aber eine Steuerungsmöglichkeit haben, denn die können ja auch überschuss in Verbindung mit ihrer Powerwall.

Aber davon mal abgesehen: Bislang habe ich OCPP so verstanden, dass eine angefragte Ladesession autorisiert und dann geloggt wird. Die openWB spart sich das autorisieren und loggt nur. Sollte OCPP auch in der Lage sein, die Autorisierung um ein paar Stunden zu verzögern und dann auch noch nur eine gewisse Strommenge zu autorisieren? Und das dann auch noch mehrfach in das selbe Auto in mehreren Ladesessions ohne ab- und anstecken? Ohne jetzt die OCPP-Specs en Detail zu kennen, halte ich das für eine arge Ausdehnung des OCPP-Protokolls. Schon das Weglassen der Autorisierung bei der openWB ist ja wohl nicht ganz normkonform.

Ich denke, das ist eine andere Schnittstelle, die da genutzt wird. („Wallbox“ war übrigens mal die einzige von octopus steuerbare Wallbox)

[openWB]

OCPP sieht Smart charging profile vor.
Kannst mal googeln.

[Gero]

Dann muss man sich mit abrechenbarem Firmenwagen ja nur noch entscheiden, welchen OCPP-Server man in der openWB einträgt. (So das denn eines Tages mal implementiert wird. Vielelicht als Bestandteil von eco-Laden als Alternative zu dynamischen Preisen / Netzentgelten vielleicht?)

[kai9555]

Update mit ersten Erfahrungen zur aktuellen Konstellation

Ich habe die openWB auf Sofortladen gestellt und gestern in Tibber das Zielladen für heute 9 Uhr aktiviert.
In der Auswertung ist zu sehen, dass in zwei kurzen Zeitfenstern Grid Rewards aktiviert wurde.

Das bedeutet: Hätte ich keinen Ladeplan hinterlegt, hätte das Fahrzeug in diesen Zeiträumen ebenfalls kurz geladen – allein dadurch, dass es angesteckt war. Soweit so gut.

Dabei sind mir aktuell drei Probleme in der Kombination aufgefallen:

1. Protokollierung in openWB

Da die Grid-Rewards-Funktion verlangt, dass das Fahrzeug dauerhaft angeschlossen bleibt, kann ich in openWB die tatsächlichen Ladekosten nicht vergleichen. Der Ladevorgang wird dort erst protokolliert, wenn das Fahrzeug abgesteckt wird. Das hat mich unabhängig von dieser Konstellation auch in der Vergangenheit schon gestört. Sinnvoll wäre es, wenn auch „unvollständige“ Ladevorgänge im Protokoll erscheinen würden – beispielsweise mit einem Hinweis wie „noch nicht abgeschlossen“.

2. Abweichende Kostenanzeige

Solange die Ladepreise nicht per API in openWB übernommen werden, stimmt die dortige Auswertung nicht mehr mit Tibber überein. Um einen Eintrag im Protokoll zu erzeugen, habe ich das Fahrzeug zwischenzeitlich kurz abgesteckt und wieder angesteckt. Danach wurde der Ladevorgang angezeigt.

openWB: 6,58 €
Tibber ohne Grid Rewards: 6,29 €
Tibber mit Grid Rewards: 6,11 €

Zumindest die ersten beiden Werte hätte ich identisch erwartet. Ich benötige die Auswertung nicht unbedingt, aber stimmen sollte sie ja trotzdem.


3. Steuerung über Tesla statt openWB

Da openWB nicht direkt in Tibber integriert ist, läuft die Regelung durch Tibber über Tesla. Wenn openWB auf Sofortladen steht, beginnt das Fahrzeug beim erneuten Anstecken sofort mit dem Laden. Ich möchte das Fahrzeug jedoch nur für Grid Rewards angeschlossen haben – ohne aktiv zu laden. In diesem Fall muss ich das Laden manuell im Tesla stoppen. Erst dann steht das Fahrzeug Tibber für Grid Rewards zur Verfügung.

Fazit:
Pain in the Ass

Die Funktion macht niemanden reich. Aber wenn es tatsächlich der Netzstabilität dient und man dafür sogar noch etwas belohnt wird find ich den Ansatz gut.

Solange es jedoch in openWB nicht sinnvoll integriert ist (wenn es denn überhaupt geht) werde ich es nicht nutzen.

VG Kai