Skip to content

Update tibber/electricity_tariff.vue - add resolution selection#913

Draft
tpd-opitz wants to merge 1 commit intoopenWB:mainfrom
tpd-opitz:feature-select-tiber-time-resolution
Draft

Update tibber/electricity_tariff.vue - add resolution selection#913
tpd-opitz wants to merge 1 commit intoopenWB:mainfrom
tpd-opitz:feature-select-tiber-time-resolution

Conversation

@tpd-opitz
Copy link
Copy Markdown
Contributor

@tpd-opitz tpd-opitz commented Feb 28, 2026

Ich habe gerade fest stellen müssen, dass Tibber zwar viertelstündliche Preise veröffentlicht, die Abrechnung aber tatsächlich auf stündlichen Durchschnittspreisen beruht. Dass kann zu erheblichen Fehlentscheidungen führen zum Beispiel gen (01.03.2026), entwickelt sich der viertelstündliche Börsenpreis so:

               {
                  "energy": 0,
                  "startsAt": "2026-03-01T15:00:00.000+01:00"
                },
                {
                  "energy": 0.0001,
                  "startsAt": "2026-03-01T15:15:00.000+01:00"
                },
                {
                  "energy": 0.0336,
                  "startsAt": "2026-03-01T15:30:00.000+01:00"
                },
                {
                  "energy": 0.0701,
                  "startsAt": "2026-03-01T15:45:00.000+01:00"
                },

Zielladen und ECO-Laden würde nun den spätesten niedrigpreisigen Timeslot zum Laden auswählen. in der Annahme, es würde 0ct Börsenpreis + Netzentgelt abgerechnet. Tatsächlich wird aber schon in der ersten halben Stunde der Stundendurchschnittspreis zur Berechnung heran gezogen, den die Tibber-API so aus gibt:

                {
                  "energy": 0.026,
                  "startsAt": "2026-03-01T15:00:00.000+01:00"
                },

Ich halte es daher für sinnvoll, in der UI vorläufig auf stündliche Preise zurück stellen zu können

@tpd-opitz tpd-opitz marked this pull request as draft February 28, 2026 19:42
@tpd-opitz tpd-opitz closed this Feb 28, 2026
@tpd-opitz tpd-opitz force-pushed the feature-select-tiber-time-resolution branch from a455121 to a0ac6df Compare February 28, 2026 19:54
@tpd-opitz tpd-opitz reopened this Feb 28, 2026
@tpd-opitz tpd-opitz changed the title Update electricity_tariff.vue - add resolution selection Update tibber/electricity_tariff.vue - add resolution selection Feb 28, 2026
@tpd-opitz
Copy link
Copy Markdown
Contributor Author

war das schon alles oder muss noch irgendwo 'ne Verbindung geknüpft werden?

@Kai9555
Copy link
Copy Markdown

Kai9555 commented Mar 1, 2026

Ich habe gerade fest stellen müssen, dass Tibber zwar viertelstündliche Preise veröffentlicht, die Abrechnung aber tatsächlich auf stündlichen Durchschnittspreisen beruht. Dass kann zu erheblichen Fehlentscheidungen führen zum Beispiel gen (01.03.2026), entwickelt sich der viertelstündliche Börsenpreis so:

               {
                  "energy": 0,
                  "startsAt": "2026-03-01T15:00:00.000+01:00"
                },
                {
                  "energy": 0.0001,
                  "startsAt": "2026-03-01T15:15:00.000+01:00"
                },
                {
                  "energy": 0.0336,
                  "startsAt": "2026-03-01T15:30:00.000+01:00"
                },
                {
                  "energy": 0.0701,
                  "startsAt": "2026-03-01T15:45:00.000+01:00"
                },

Zielladen und ECO-Laden würde nun den spätesten niedrigpreisigen Timeslot zum Laden auswählen. in der Annahme, es würde 0ct Börsenpreis + Netzentgelt abgerechnet. Tatsächlich wird aber schon in der ersten halben Stunde der Stundendurchschnittspreis zur Berechnung heran gezogen, den die Tibber-API so aus gibt:

                {
                  "energy": 0.026,
                  "startsAt": "2026-03-01T15:00:00.000+01:00"
                },

Ich halte es daher für sinnvoll, in der UI vorläufig auf stündliche Preise zurück stellen zu können

Wo hast du denn die Information her, dass nicht nach den 15min Slots abgerechnet wird?

Laut Tibber:

„Die tatsächliche Abrechnung erfolgt jedoch auf Basis der 15-Minuten-Intervalle, nicht nach stündlichen Durchschnitten - unabhängig davon, welche Auflösung du in der API abfragst.“

@tpd-opitz
Copy link
Copy Markdown
Contributor Author

tpd-opitz commented Mar 1, 2026

Wo hast du denn die Information her, dass nicht nach den 15min Slots abgerechnet wird?

Laut Tibber:

„Die tatsächliche Abrechnung erfolgt jedoch auf Basis der 15-Minuten-Intervalle, nicht nach stündlichen Durchschnitten - unabhängig davon, welche Auflösung du in der API abfragst.“

Gut, dann muss ich noch mal die Rechnung nachprüfen.

@Kai9555
Copy link
Copy Markdown

Kai9555 commented Mar 1, 2026

Es gibt ja tatsächlich Szenarien in denen nicht in Echtzeit (15min Intervall) abgerechnet wird, sondern der Durchschnittspreis genommen wird - das ist wohl dann der Fall, wenn man kein fertig konfiguriertes imsys oder Puls IR hat. Wenn der Pulse IR keine Verbindung (Batterie leer, Sitz schief) hat wird auch nicht nach 15min abgerechnet.

Ob alles richtig lief sieht man auch in der Tibber App in der Historie (siehe Anhang).

Ich habe ein iMSys und bei mir dauert es auch bis die richtigen Werte verfügbar sind. Das schwankt bei mir etwas zwischen 24 und 48h. Wenn das der Fall ist, steht bei mir in der Historie dann „ Deine Abrechnung enthält geschätzte
Verbrauchswerte.“ als ich noch den Pulse hatte, hatte ich ab und zu auch mal nur geschätzte Werte (der Wortlaut war glaube ich aber anders) vor allem weil ich den Pulse mit einem Batterie Eliminator betreiben wollte, was nicht stabil lief.
IMG_7049

@Kai9555
Copy link
Copy Markdown

Kai9555 commented Mar 1, 2026

Hier noch einmal der Link mit der Bestätigung für die 15min:

https://support.tibber.com/de/articles/4406375-tibber-stromrechnung-erklart

@tpd-opitz
Copy link
Copy Markdown
Contributor Author

Hier noch einmal der Link mit der Bestätigung für die 15min:

https://support.tibber.com/de/articles/4406375-tibber-stromrechnung-erklart

Ich habe jetzt noch mal die Werte auf meiner Januar-Rechnung mit den Zahlen aus der API verglichen. Die aufsummierten Kosten aus der API sind 0,28% höher als die Stromkosten auf der Rechnung. Da hätte ich mehr Unterschied erwartet...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants