Repository navigation
Feature Request: Ladeprotokoll – Energie und Kosten je Tarifzeitraum (Feste Tarifstunden) #4111
Description
Hallo zusammen,
Anwendungsfall: Mit „Feste Tarifstunden“ (ab 2.3 mit Wochentagen, #3252) lassen sich Hoch-/Niedertarife abbilden, z. B. in den Niederlanden Niedertarif werktags 23–7 Uhr und am Wochenende, in Deutschland die Zeitfenster nach §14a Modul 3. Das Ladeprotokoll zeigt pro Ladevorgang aber nur die Gesamtkosten. Wer Ladevorgänge abrechnen oder erstatten lässt (z. B. beim Dienstwagen), braucht kWh und Kosten je Tarifzeitraum.
Vorschlag (rein additiv, opt-in):
fixed_hours: eine Hilfsfunktion, die für einen Zeitslot den passenden Tarif liefert – mit genau derselben Zuordnung wie beim Preis –, dazu optional ein Name für den Standardpreis (default_name).Optional.ep_get_current_tariff_name(): der Name für denselben Slot, denep_get_current_price()liefert (also der erste Eintrag, nichtnow()). Nur fürfixed_hours, sonstNone.- Tageslog: im
prices-Dict zusätzlich der Tarifname;None, wenn auf die Standardpreise zurückgefallen wird. - Ladeprotokoll: im
Logein zusätzlicher Zähler{Tarifname: {energy, costs}}– der Netzanteil jedes 5-Minuten-Intervalls mit dem Preis dieses Intervalls –, im Eintrag als optionaler Schlüssel unterdata.data.costsbleibt die maßgebliche Summe; alte Einträge ohne den Schlüssel bleiben gültig. - Oberfläche: neue Spalte „Tarifaufteilung“ (standardmäßig ausgeblendet, über
charge_log_data_config+upgrade_datastore), Summen und beide CSV-Exporte (neue Spalten am Ende, damit bestehende Auswertungen nicht verrutschen).
Für dynamische Tarife (Tibber, aWATTar …) bleibt das Feld leer.
Fragen vorab:
- Passt der Ansatz, den Namen per Lookup aus der
fixed_hours-Konfiguration zu holen, stattTariffStatefür alle Module zu erweitern? - Soll ich auf Feature fix charge costs #4110 warten und darauf aufbauen?
- Soll der letzte Teilabschnitt eines Ladevorgangs (END) dabei mit dem Preis des aktuellen Slots statt des vorherigen bewertet werden, damit Tarifgrenzen sauber zugeordnet werden – oder lieber separat?
Ich würde den Core- und den UI-PR (verknüpft) inklusive Tests beisteuern.
Activity
kevinwieland commentedon Oct 14, 2026
kWh und Kosten, üblicherweise sind das fix die Kosten pro kWh oder Kosten nach Aufteilung.
Wo kommt die Annahme bzw. Verpflichtung her das eine Aufschlüsselung nach Tarifzeitraum erforderlich ist?
buhito81 commentedon Oct 14, 2026
Danke für die Rückfrage! Eine allgemeine Pflicht gibt es nicht – relevant wird es, wenn nach dem tatsächlichen Arbeitspreis abgerechnet wird und der Vertrag zwei Arbeitspreise hat.
Mein Fall: Der Ladestrom des Dienstwagens wird zum Arbeitspreis meines Stromvertrags erstattet, und ab 2027 hat der Vertrag (NL) einen Normal- und einen Niedertarif. Welcher Betrag stimmt, hängt also davon ab, wie viele kWh in welchem Zeitraum geladen wurden – die Stromrechnung weist beide getrennt aus.
Vergleich Deutschland: Seit dem 1.1.2026 (BMF-Schreiben vom 11.11.2025) sind die monatlichen Pauschalen fürs Laden zu Hause weggefallen. Steuerfrei erstattet wird nur noch die gemessene Strommenge – entweder mit der kWh-Strompreispauschale oder per Einzelnachweis zum Arbeitspreis des eigenen Vertrags (plus anteiligem Grundpreis). Wer den Einzelnachweis wählt und einen HT/NT-Vertrag hat, rechnet mit zwei Arbeitspreisen; die kWh je Tarifzeitraum sind dafür die naheliegende Grundlage. Ähnlich bei §14a Modul 3: Man sieht, wie viel tatsächlich im günstigen Netzentgelt-Fenster geladen wurde.
openWB bewertet schon heute jedes 5-Minuten-Intervall mit dem dann gültigen Tarifpreis, speichert aber nur die Summe. Die Aufteilung macht diese Summe nachvollziehbar. Wer nur einen Preis pro kWh hat, merkt davon nichts – deshalb opt-in und standardmäßig ausgeblendet.
kevinwieland commentedon Oct 14, 2026
Und wer variable Tarife hat, hat je nach Ladedauer 5-10 Preise. Wobei das natürlich variable Netzentgelte und aber zusätzlich variable Strompreise sind.
Ich hinterfrage an der Stelle woher die Anforderung kommt das aufzuschlüsseln.
Ich möchte schlicht den Rahmen kennen und verstehen.
Bisher gab es die Anforderung nicht.
Dein Fall mit HT/NT ist ja sehr simpel.
Eine Ladung über 12 Stunden, mit 3 Netzentgeld Varianten, ggf. im 15 min Takt unterschiedlichen Arbeitspreisen in Kombination mit Speicher und ggf. PV Nutzung führen zu einem Roman an Erklärung für eine Ladesession.
Ist halt immer die Frage wo fängt man an, wo hört man auf.
buhito81 commentedon Oct 14, 2026
Berechtigte Frage – deshalb ist der Vorschlag bewusst eng gefasst:
Also kein Roman pro Ladevorgang, sondern z. B. „NT: 18,4 kWh / 4,73 € · HT: 3,1 kWh / 0,88 €“. Ob das für openWB passt, würde ich gern von @LKuemmel hören, bevor ich etwas baue.
kevinwieland commentedon Oct 14, 2026
Und warum? Weshalb ist hier die Anforderung anders bzw. nicht gegeben im Vergleich zu den Tarifstunden?
Müsstest aber neben Tarifstunden nicht auch nach variablen Netzentgelten unterscheiden?
buhito81 commentedon Oct 14, 2026
Der Unterschied liegt in der Abrechnung, nicht in der Anforderung:
Zu den variablen Netzentgelten: Die sind drin. §14a Modul 3 wird in openWB als Netzentgelt mit „Feste Tarifstunden“ konfiguriert, und dessen Zeitfenster haben Namen. Bei festem Arbeitspreis wird nach diesen Fenstern aufgeteilt. Sind Arbeitspreis und Netzentgelt beide feste Tarifstunden, werden die Namen kombiniert („NT / Modul 3 NT“); auch dann bleibt es bei wenigen Einträgen. Nur dynamischer Arbeitspreis plus Modul 3 bleibt bei der Summe. Wenn gewünscht, ließe sich auch dort nach den Netzentgelt-Fenstern aufteilen.
Ich stelle den Vorschlag als Entwurf (Core + UI) ein, damit man ihn konkret ansehen kann.
kevinwieland commentedon Oct 15, 2026
Warum? Wer verlangt das? Warum wird das bei einem dynamischen Tarif nicht verlangt?
Doch, hier gibt es feste und variable Posten. Warum ist es bei einem dynamischen Tarif nicht nötig den aufzuschlüsseln?
Das ist ja nur ein Thema das Wording. Beim dynamischen Tarif sind die Fenster nur kürzer. Ich möchte verstehen woher die Anforderung kommt das es einmal nötig ist und einmal nicht, nur weil die Fenstergröße eine andere ist. Anders formuliert, was rechtfertigt den Aufwand und die potentiellen Probleme dies zu implementieren obwohl es nicht gefordert ist. Wenn es denn gefordert ist, wer fordert das und warum? Wenn das eine rechtliche Anforderung ist muss das natürlich unbedingt rein. Wenn das eine KI generierte Quatschanforderung ist eher nicht ;)
buhito81 commentedon Oct 15, 2026
Zur Frage „wer verlangt das": das Steuerrecht – über die Abrechnungsgrundlage. In den Niederlanden darf der Arbeitgeber den Ladestrom eines Dienstwagens zu Hause nur auf zwei Wegen steuerfrei erstatten (Handboek Loonheffingen 2026, §23.3.9; Kennisgroep-Standpunkte KG:204:2024:13 und :14):
Was darüber hinausgeht, ist Lohn. Wird beim zweiten Weg der Arbeitspreis des eigenen Stromvertrags als Tarif vereinbart und hat dieser zwei Arbeitspreise, dann lautet die Rechnung an den Arbeitgeber „kWh je Zeitfenster × Arbeitspreis des Fensters". Die Summe unter „Kosten" stimmt, lässt sich ohne die Mengen je Preis aber nicht gegen Vertrag und Vereinbarung prüfen. Diese Mengen kennt nur die Wallbox; die Zählerregister des Hauses enthalten auch den Haushaltsverbrauch.
Genau diese Abrechnung bietet openWB selbst an: „openWB ermöglicht die Abrechnung von zu Hause geladenem Strom für Dienstwagen", u. a. per „Automatischer Datenexport durch Ladelog" oder als „Komplettabrechnung durch openWB".
Bei dynamischen Tarifen nennt der Vertrag keine festen Arbeitspreise, die man als Positionen ausweisen könnte; die Summe ist dort die Abrechnungsgrundlage. Der Unterschied liegt im Vertrag, nicht in der Fenstergröße.
buhito81 commentedon Oct 15, 2026
Kurze Änderung an beiden Draft-PRs: Die Aufteilung zeigt jetzt die gesamte geladene Energie je Tarifzeitraum, gemessen vom Zähler des Ladepunkts, plus die Kosten je Fenster, wie openWB sie heute berechnet (in Summe = „Kosten"). Vorher war es nur der Netzanteil. Der beruht aber auf der geschätzten Energieaufteilung (Hausmix je 5-Minuten-Intervall), und PV lässt sich daraus nicht verlässlich herausrechnen. Für eine Abrechnung zählt der Zählerwert.
Zum Hintergrund in den Niederlanden – das ist, neben dem Tüfteln, auch mein persönlicher Grund für eine openWB; dort bin ich damit noch einer der wenigen. Ab 2027 entfällt die Saldierung. Mein Vertrag für 2027 (inkl. Energiesteuer und MwSt.):
Eine kWh vom Dach ins Netz bringt also 0,5 ct. Dieselbe kWh im Dienstwagen bringt den vereinbarten Tarif: Im Rahmen der „zakelijke transactie" darf der Arbeitnehmer auch selbst erzeugten PV-Strom an den Arbeitgeber liefern (Handboek Loonheffingen 2026, §23.3.9). Auch mit einem dynamischen Vertrag bleibt der Abstand groß, denn auf den Bezug kommen Energiesteuer (2027 rund 10,6 ct/kWh inkl. MwSt.) und MwSt., auf die Einspeisung nicht.
Dazu kommen seit 2026 die ERE-Zertifikate (emissiereductie-eenheden): Für jede geladene kWh, gemessen von einem geeichten Zähler, zahlt ein registrierter Anbieter derzeit etwa 13–16 ct (marktabhängig). Die Daten gehen per OCPP an den Anbieter. openWB sendet dabei nur Start, Zählerstände und Stopp und nimmt keine Steuerbefehle an; die Regelung (PV-Überschuss, Zielladen) bleibt bei openWB. Abrechnung je Tarifzeitraum, ERE per OCPP und die eigene Regelung in einem Gerät: Für einen technikbegeisterten Niederländer ist openWB damit die naheliegende Wahl. Und deshalb wird jede geladene kWh abgerechnet, unabhängig von der Quelle, mit der Menge je Tarifzeitraum.
Rechenbeispiel: ein Monat bei uns. Wir haben mehrere Dienstwagen, die an der openWB laden, zusammen rund 750 kWh im Monat (Annahme: 30 % PV-Überschuss im Jahresmittel – im September waren es 41 %, im Winter fast nichts; Netzstrom überwiegend nachts):
Rund 160 € im Monat, knapp 2.000 € im Jahr. Dieser Business Case hängt an genau dem, was openWB kann: PV-Überschussladen, geeichter Zähler mit OCPP für ERE und eine Abrechnung, die die Menge je Tarifzeitraum belegt.
kevinwieland commentedon Oct 16, 2026
Damit ist doch klar das das in deinem Fall zwar die Tarifstunden sind aber für andere auch die variablen Kosten beinhalten muss (dynamischer Tarif).
Richtig. Bezogen auf Deutschland. Wir liefern regulär nicht in die Niederlande. Daher ja meine Frage nach der (rechtlichen/steuerlichen) Anforderung die in der Form wie du sie dir wünscht in Deutschland nicht existiert, in den Niederlanden aber anscheinend schon.
Deine gewünschte Änderung ist persönlich auf dich zugeschnitten. Das ist legitim, die meisten schauen erstmal wie es für Sie am besten passt. Der nächste hat ggf. den variablen Tarif. Das bläht das Log unheimlich auf mit Seiteneffekten die "mal eben" nicht zu beurteilen sind.
Laut deiner Aussage:
Wäre es da nicht analog zu Deutschland möglich den vereinbarten Preis von z.B. 34Cent zu verrechnen? Das ist in Deutschland die von der Finanzbehörde freigegebene Variante. Daher haben wir die auch entsprechend bei uns implementiert.
buhito81 commentedon Oct 16, 2026
Mein "variabel" war missverständlich. Gemeint ist verbrauchsabhängig, nicht dynamisch. Der integrale Kostenpreis ist ein einziger Preis, alle Stromkosten durch alle verbrauchten kWh, und braucht bei keinem Tarif eine Aufteilung.
Auch dort ist die Aufteilung nicht vorgeschrieben, das hatte ich gestern zu stark formuliert. Und dass ihr nicht regulär hierher liefert, wollt ihr das so lassen? ;-)
Der Anlass kommt von mir, klar. Bei dynamischem Tarif ändert sich aber nichts, weder an den Einträgen des Ladeprotokolls noch an den Summen, am CSV-Export oder im Tageslog. Aufgeteilt wird nur, wenn alle konfigurierten Preismodule "Feste Tarifstunden" sind (z.B. HT/NT, §14a Modul 3). Die Zahl der Posten hängt nur von den konfigurierten Zeitfenstern ab, nicht von der Ladedauer. Zusammen ergeben die Posten (bis auf Rundung) die bisherigen "Kosten".
Edit: Das Feld
tariff_nameim Tageslog steht jetzt nur noch drin, wenn es einen Tarifzeitraum gibt (#4117).Ja, ein vorab vereinbarter marktüblicher Festpreis geht, und das kann openWB heute schon (ohne Preismodul, Netz-, PV- und Speicherpreis gleich). Eine amtliche Pauschale wie eure 34 ct gibt es in den Niederlanden aber nicht. Welchen marktüblichen Tarif man ansetzt, machen Arbeitgeber und Arbeitnehmer unter sich aus. Ist es der eigene Vertrag mit HT/NT, braucht man die kWh je Zeitfenster.
Ob openWB das will, entscheidet ihr. Wenn nicht, mache ich die PRs zu.