openhabforum.de

Hallo!

Ich benötige mal etwas Rat, für meine E-Auto Ladungen.
Ich werde nächste Woche zu Tibber als Stromanbieter wechseln, mit einem dynamischen, stündlichen Tarif.
Was mir jetzt noch fehlt, ist …
A) eine Übersicht über die Ladekosten.
B) eine Ladeplanung fürs E-Auto, die sich nach dem Preis richtet.

Was habe ich zurzeit:
Eine Ladeplanung, bei der ich über den Google-Kalender das Ladeende einstelle. Der Ladestart wird entsprechend berechnet und erfolgt automatisch, indem über den go-eCharger das Laden freigegeben wird.
Das gewünschte Ladelimit (in Prozent) ist über ein Item definiert, was ich über eine Sitemap nach belieben einstellen kann.
Bei Ladebeginn wird mir eine Telegramnachricht geschickt, mit dem gewünschten Ladeziel (Prozent).
Nach Ladeende wird mir eine Telegramnachricht geschickt, mit den geladenen kWh.

Die Ladegeschwindigkeit ist als interne Variable (val Number prozentProStunde = 6.8) vorhanden.

Meine Hardwareausstattung:

• Auf dem Stromzähler ein Tibber Pulse
• Zusätzlich noch ein Shelly 3EM
• Wallbox go-eCharger
• Fiat 500e

Meine Items:

• Auto_Fiat_Batterieladung (Number) - Aktueller Ladestand des Autos.
• Auto_Fiat_LadelimitProzent (Dimmer) - Eingestelltes Ladelimit für den Akku.
• Auto_Laden_Ende (DateTime) - Gewünschtes Ladeende aus dem Google-Kalender.
• Auto_Laden_BeginnBerechnet (DateTime) - Berechneter nötiger Ladebeginn.
• Garage_GoeCharger_GeladeneEnergie (Number) - Die bei dem aktuellen Ladevorgang geladene Energie.
• Garage_GoeCharger_GeladeneEnergieGesamt (Number:Energy) - Stromzähler im go-eCharger.
• Tibber_Current_Total_Price (Number) - Aktueller Strompreis (in Euro/kWh).
• aWATTar_BesterPreis_Startzeit (DateTime) - Uhrzeit mit dem niedrigsten Börsenpreis an diesem Tag.

Wie setze ich das jetzt um?
Für A) war meine erste Idee, während des Ladevorganges, zu jeder Stunde die in dieser Stunde geladene Energie mit dem in der Stunde aktuellen Strompreis zu multiplizieren und das Ergebnis dann immer mit der Stunde zuvor zu addieren.
Über die influxDB werden die Werte auch persistiert. Deswegen kam mir als weitere Idee, nach dem Ladevorgang die Werte zusammenzusuchen und die Kosten auszurechnen.

Für B) habe ich ehrlich gesagt überhaupt noch keine Idee. Ich stelle mir das auch relativ komplex vor. Denn die Zeit mit dem niedrigsten Preis ist ja nicht automatisch auch die Startzeit. Sondern eher nur ein Anhaltspunkt.
Der go-eCharger hat so etwas allerdings auch schon integriert, was ich ggf. nutzen kann.
Priorität hat für mich erst einmal A), um die Kosten im Blick zu haben. Dabei reicht mir auch tatsächlich eine Telegrambenachrichtigung.

Und danke an alle, die bis hierher gelesen haben.
Gruß

Zu a) Letztlich gibt es ja nicht viele Möglichkeiten. Du musst im Grunde eine Tabelle erzeugen, in der die bezogene Energiemenge (in kWh) pro Zeitabschnitt und der kWh Preis für den Zeitabschnitt stehen, dann kannst Du aus dem Produkt berechnen, was der Bezug genau gekostet hat.
Ich kenne Tibber nicht, aber irgendwoher musst Du ja immer den aktuellen, den historischen und außerdem auch den zukünftigen Preis bekommen - Letzterer ist mit gehörigem Vorlauf die Bedingung für Punkt b - was nutzt es Dir, zu wissen, dass in der nächsten Stunde der Strom teurer wird, wenn Du den Akku voll bekommen musst...
Wenn der Preis stündlich wechselt, hast Du damit auch das notwendige Zeitraster Deiner Tabelle. Am Einfachsten ist es dann vermutlich, jeweils zum Ende des Zeitabschnitts die Energiemenge auszulesen (kWh gesamt aktuell minus kWh gesamt vor einer Stunde) und diesen Wert in einem eigenen Item zu persistieren. Dann kannst Du wahlweise für einen beliebigen Zeitpunkt die Summe der Vorstunde abrufen oder auch mit sumSince() oder sumBetween() die Summe der Werte in einem Zeitabschnitt auslesen. Wenn Du die Daten für das Auto extra haben möchtest, brauchst Du natürlich ein eigenes Item mit der separaten Energiemenge des Ladegeräts. Die Summe der Vorstunde darf nur exakt einmal pro Stunde persistiert werden, sonst bekommst Du bei den Summenfunktionen fehlerhafte Ergebnisse. Natürlich kann man die Zeitabschnitte auch kleiner wählen, z.B. einmal pro Minute, damit die Kosten nicht erst zum Ende der Stunde zur Verfügung stehen, sondern spätestens eine Minute Nach Ladeende.

Danke für deine Antwort.
Zu A) Ich werde am Sonntag dann mal etwas rum probieren. Wenn ich die Werte eine Minute vor bzw. nach jeder Stunde persistieren, müsste ich ja alle Infos haben, um die Kosten berechnen zu können. Eine Herausforderung (zumindest für mich) wird es noch, den Start und das Ende des Ladevorgangs richtig zu berücksichtigen. Ich werde das dann auf Minuten herunterbrechen müssen.
Die Preise lassen sich auch über die Tibber API als json-String abrufen. Das wäre ja quasi bereits meine Tabelle. Ist die Frage, was einfacher ist.

Ab 14 Uhr stehen die stündlichen Preise für den nächsten Tag fest. Die Preise lassen sich im Web relativ schön über aWATTar.de (runter scrollen) anschauen. Tibber schlägt dann hier in meiner Region noch 11,4 Cent/kWh drauf. Das ist im Preis, den ich von Tibber beziehe, (Tibber_Current_Total_Price) aber bereits drin.
Aber wie erwähnt, ich habe auch kein Problem damit, den Ladevorgang manuell zu planen. Deswegen ist mir Punkt B) erst einmal nicht so wichtig.

Oh, ich sehe gerade, das aWATTar-Binding bietet die Möglichkeit, die Länge der Niedrigpreisspanne anzugeben. Dann bekommt man direkt die Start- und Endzeit mitgeteilt.

Wir haben auch einen goe-Charger und einen 500e.

• Du kommst nicht so einfach an Auto_Fiat_Batterieladung, da Fiat keine offiz Dafür ntuze ich evcc und frage den Wert in openHAB via MQTT ab (es gibt auch ein evcc-Plugin, aber ich nutze immer MQTT, wenn es das gibt).
• Der goe-Charger kann doch mit dynamischen Tarifen umgehen, und seit einiger Zeit auch mit Tibber, oder?

evcc ist zwar für PV-Überschussladen gedacht, funktioniert aber auch ohne PV-Anlage.

Daher würde ich den Ladestand mittels evcc prüfen und ggf. bei 80% abbrechen, und den goe-Charger die Steuerung des Ladens machen lassen.

Komplett ohne die Steuerung durch den goe-Charger kannst du via evcc den Ladestrom zwischen 6A und 16A einstellen und zwischen 3 und 1 Phase umschalten. Dann rechnet dir evcc aus, wenn in etwa der gewünschte Ladegrad erreicht wird, so dass du dich an das Ziel heraniterieren kannst.

Wenn du dann den Preis von Tibber zurate ziehst, kannst du in einem nächsten Schritt bei günstigem Strom mit 16A / 3p arbeiten und ansonsten den Ladestrom so weit runterdrehen, dass du gerade den Zielakkustand in Time erhältst.

Am Ende ist es ein geschicktes Rechnen, welches Preisintergral den geringsten Flächeninhalt hat. Das geht aber eh nur für heute und den Folgetag, da du nicht mehr Daten von Tibber bekommst. Daher wird eine Langfristplanung nicht funktionieren.

evcc kann auch mit dynamischen Tarifen arbeiten. Ob es ein Preisintegral beherrscht, also auf möglichst geringe Kosten optimiert, weiß ich nicht, da ich keine dynamischen Tarif habe.

@Tokamak
Da habe ich meinen ersten Post vermutlich etwas missverständlich geschrieben. Ich habe in openHAB bereits ein Item "Auto_Fiat_Batterieladung". Das beinhaltet den aktuellen Batteriestand. Das beziehe ich in openHAB über ioBroker. Das Laden bis zu einer definierten Grenze funktioniert also bereits. Genauso die Berechnung, wann, bei angegebenen Zielwerten (Batteriestand und Ladeende), die Ladung begonnen werden muss. Und das Abschalten natürlich ebenfalls. Da ich dauerhaft einphasig mit 3KW lade, schaffe ich so ca. 6,8% / Stunde.
Die Ladesteuerung mit Hilfe des go-eChargers, wie oben im Screenshot zu sehen, wird leider anscheinend automatisiert aus openHAB heraus nicht funktionieren. Zumindest finde ich über die API nicht die entsprechenden Werte, die ich im Go-e dafür setzen müsste.

Ich habe es jetzt erst einmal so gelöst.
Ob man das wirklich jede Minute machen muss ... vermutlich reicht es auch, das alle fünf Minuten zu berechnen. Soooo genau muss ich die Kosten auch wieder nicht kennen.
Ich werde das jetzt erst einmal ein paar Ladungen so testen.

Zum Punkt B) Ladeplanung: Da könnte mir die Startzeit aus dem aWATTar Binding vielleicht ausreichen. Meine Ladungen sind relativ konstant, was die Ladedauer angeht.