Tibber & Tibber Pulse

[tomhead]

Hallo Tom,

Ich habe es Dir dann mal etwas bereinigt, wobei es natürlich unschön ist das dann drei mal für next[1-3]_hour ins userReadings zu packen
Du müstest dann $i von 1-3 jeweils ändern, ansonsten habe ich den code korrigiert und gekürzt.

VG  Christian

Hi Christian, vielen vielen Dank! Ich weiß, dass das sicher nicht die eleganteste Methode ist, aber sie funktioniert erst mal. Und dann kann ich bei Gelegenheit mal schauen, ob ich das noch anders gelöst bekomme mit meinem bescheidenen Wissen über Perl und myutils

[ch.eick]

Hallo Tom,

Ich habe es Dir dann mal etwas bereinigt, wobei es natürlich unschön ist das dann drei mal für next[1-3]_hour ins userReadings zu packen
Du müstest dann $i von 1-3 jeweils ändern, ansonsten habe ich den code korrigiert und gekürzt.

VG  Christian

Hi Christian, vielen vielen Dank! Ich weiß, dass das sicher nicht die eleganteste Methode ist, aber sie funktioniert erst mal. Und dann kann ich bei Gelegenheit mal schauen, ob ich das noch anders gelöst bekomme mit meinem bescheidenen Wissen über Perl und myutils

Wenn Du das aus der myUtils aufrufen kannst, dann kann man das recht leicht umbauen.

[jnewton957]

Hallo,
ich habe nun meine erste Tibberrechnung erhalten und diese mit den Werten aus der EVU_Tibber_connect verglichen.

Ergebnis:
node_consumption passt sehr genau zur App und Rechnung
node_cost hat nur eine sehr geringe Abweichung (<3% geringer als Rechnung). Dies könnte aber auch an meinen vielen Anpassungen im Januar liegen und mir sind vielleicht Werte abhandengekommen.

fc0 und fc1 entsprechen den Werten der App.

Daher nochmals Danke an Christian für die Mühe und das coding.

Ich habe mir zwischenzeitlich ein paar hilfsdummies gebaut, da ich tibber auch mit anderen EVU mal vergleichen möchte.

Tibber_cost_avg_day = total_cost_day/ nodes_consumption_day
Das dann auch für month und year.

Und die Ergebnisse waren dann überraschend.

Eigentlich hätte ich erwartet, dass Tibber_cost_avg_day etwa  fc0_avg entspricht und nicht höher als fc_0_max sein darf. Ich habe eine Abweichung >10% zu fc0_avg und bin regelmäßig über fc_0_max.

Ich habe dann mal recherchiert: die forecastwerte von tibber enthalten den Arbeitspreis sowie die Nebenkosten wie Grundgebühr, Netzentgelte und Steuern. Diese natürlich herunter gebrochen auf Tag/Stunde und Schätzwert pro kWh. Aber sie sind in fc0_hr_total enthalten.

Ich habe dann mal Hilfsrechnungen vorgenommen:

fc0_hr_total x nodes_24_hr_consumption müsste ja etwa nodes_24_hr_cost entsprechen

Je nach nodes_24_hr_consumption ist meine Abweichung jedoch zwischen 5 und 10%. Das macht bei mir eben schnell 2-4 ct/kWh aus.
Ich habe noch nicht die echte Ursache bzw. einen fixen Korrekturfaktor finden können.

Letztlich nehme ich allerdings die fc0 Werte nur um eben die Tendenz teuer/preiswert abzulesen und den günstigsten Zeitpunkt für das E-Laden zu bestimmen. Für Personen, die damit aber Batterien beladen wollen oder Großverbrauchern steuern wollen, wären 10% Abweichungen schon relevant.

Ich hatte also 28,34 ct/kWh Arbeitspreis und 16,66 € Grundgebühr im Januar. Damit ist eigentlich tibber teurer als andere EVU. Letztlich macht die hohe verbrauchsunabhängige Grundgebühr bei mir tibber aktuell unwirtschaftlich.

Wie sind eure Erfahrungen mit den Werten bzw. fc0 Abweichungen ??

[hwahl]

Hallo,
ich bin Tibber Kunde und ein etwas fortgeschrittener FHEM Bastler. Tibber ist aktiv, aber erst ab 01.04.2024 mein Stromlieferant.

Ich hole mir meine Echtzeitdaten über die API das klappt ganz gut. Allerdings ist der gelieferte Wert für "power" immer null. Das ist sowohl bei meinem FHEM Skript so und auch im Tibber API Developer so.  In der Handy APP wird der Wert für den aktuellen power allerdings angezeigt.

Hat Tibber eventuell die Spezifikation geändert?

Gruß
Hans-Dieter

[ch.eick]

Hallo,
ich bin Tibber Kunde und ein etwas fortgeschrittener FHEM Bastler. Tibber ist aktiv, aber erst ab 01.04.2024 mein Stromlieferant.

Ich hole mir meine Echtzeitdaten über die API das klappt ganz gut. Allerdings ist der gelieferte Wert für "power" immer null. Das ist sowohl bei meinem FHEM Skript so und auch im Tibber API Developer so.  In der Handy APP wird der Wert für den aktuellen power allerdings angezeigt.

Hat Tibber eventuell die Spezifikation geändert?

Gruß
Hans-Dieter

Hallo Hans-Dieter,
in meinem EVU_Tibber Device wird der Power Wert nach wie vor geliefert, da dieser jedoch über das Internet von Tibber kommt, vermute ich  das das erst kommen wird, wenn Du als Kunde aktiv bist.

VG  Christian

[hwahl]

Hallo Christian,
danke für den Hinweis. Deine Erklärung klingt plausible, ich werde mal schauen ob die aktuelle Leistung ab 01.04 übertragen wird.

Gruß
Hans-Dieter

[horchundkuck]

Finde die EVU_Tibber_connect Definitionen sehr hilfreich zum smarten Steuern und bin damit auch gerade am Testen und Anpassen.
Da ich SQLite nutze, mussten (und müssen teilweise noch) einige Berechnungen angepasst werden. Siehe im Thema 'DbLog mit SQLite': https://forum.fhem.de/index.php?topic=136061.msg1306013#msg1306013

1. Frage
Zu fc_min und fc_max benötige die gültige Zeit, also ein Reading nach der Art '_startsAt', wie z. B. bei fc1_23_startsAt = 2024-03-07 23:00:00. Wie kann ich das umsetzen?

2. Frage
Können die Triggerzeiten 'fc1_trigger_start' u.ä. nicht wie bisher in HH:MM sondern ebenfalls im Format YYYY-MM-DD HH:MM:SS dargestellt werden?

Sonnige Grüße
Heinz

[ch.eick]

1. Frage
Zu fc_min und fc_max benötige die gültige Zeit, also ein Reading nach der Art '_startsAt', wie z. B. bei fc1_23_startsAt = 2024-03-07 23:00:00. Wie kann ich das umsetzen?

2. Frage
Können die Triggerzeiten 'fc1_trigger_start' u.ä. nicht wie bisher in HH:MM sondern ebenfalls im Format YYYY-MM-DD HH:MM:SS dargestellt werden?

Hallo Heinz,
Könntest Du den Anwendungsfall für 1 und 2 mal beschreiben ?

Für das Minimale und auch Maximale Fenster gibt es ja bereits Start und Stop Zeiten.
Das Datum ist impliziet im fc0 und fc1 , also heute und morgen, beinhaltet. Die Uhrzeit soll als Triggerzeit z.B. in einer DOIF Abfrage dienen. Da ist es jedoch einfacher direkt den Trigger zu verwenden.

VG Christian

[horchundkuck]

Hallo Christian, Danke für deine schnelle Rückmeldung, die mir jetzt schon fast zu schnell kam.
Meine 2. Frage wollte ich nämlich nach weiteren Tests zurückziehen. Aus dem Grund, den du auch genannt hast: das wäre für DOIF gar nicht nutzbar.
Ich wollte das nächste min-Fenster nutzen, egal ob fc0 oder fc1.
Ich habe das bis jetzt so verstanden: wenn fc0_trigger on ist, gibt es heute ein Fenster, bei off gibt es heute keines (mehr). Ob es dann morgen ein Fenster gibt, lässt sich mit fc1_trigger_start (ein fc1_trigger on/off gibt es nicht?) feststellen. Ein existierendes fc1 Fenster wird nach Mitternacht zum fc0 Fenster. In der Praxis sieht das bei mir aber anders aus: die Zeiten des Fensters vor und nach Mitternacht sind unterschiedlich, wie auf den Screenshots zu sehen ist.
Das Zeitfenster fc0 ist dabei korrekt. Das werde ich für mich also auch nutzen.

Anwendungsfall für 1.:
Mir reicht eigentlich die (eine) Stunde mit dem niedrigsten Strompreis als Zeitfenster aus, um sie im DOIF für Aktionen zu nutzen. Das kann ich mit dem Preisvergleich current_price/fc_min auch lösen, eine direkte Zeit wäre natürlich flexibler, z.B. +/- 1 Stunde nutzbar.

VG Heinz

[ch.eick]

Ich wollte das nächste min-Fenster nutzen, egal ob fc0 oder fc1.
Ich habe das bis jetzt so verstanden: wenn fc0_trigger on ist, gibt es heute ein Fenster, bei off gibt es heute keines (mehr).

das rteading fc0_trigger ist direkt der Trigger, den Du verwenden kannst.
on bedeutet jetzt ist es im Trigger Fenster, somit bleibt der Trigger dann für die günstige Zeit auf on und geht am Ende des Fensters wieder auf off.

Ob es dann morgen ein Fenster gibt, lässt sich mit fc1_trigger_start (ein fc1_trigger on/off gibt es nicht?) feststellen.

Getriggert wird immer nur mit fc0_trigger
Die start/stop Zeiten wären dann für die eigene Planung noch zusätzlich, damit man sehen kann, ob überhaupt z.B. ein Laden des Speichers möglich sein wird.

Ein existierendes fc1 Fenster wird nach Mitternacht zum fc0 Fenster.

So sollte es sein, es sei denn ich habe einen Fehler eingebaut.

In der Praxis sieht das bei mir aber anders aus: die Zeiten des Fensters vor und nach Mitternacht sind unterschiedlich, wie auf den Screenshots zu sehen ist.
Das Zeitfenster fc0 ist dabei korrekt. Das werde ich für mich also auch nutzen.

Das passiert, wenn sich die Preise in der Zwischenzeit geändert haben, da die Berechnungen immer über alle verfügbaren Zeiten geschehen.
Somit ist die fc1 Prognose mit berücksichtigt, da die Preise ja beim fc1 noch mehr fallen können. Um Mittenacht fallen dann jedoch die fc0 Preise weg und die Berechnung wird nur mit fc1 Werten, die ja dann zu fc0 geworden sind, neu erstellt. Somit kann sich dann das Trigger Fenster verändern, denn man möchte dann ja wieder das beste Fenster haben.

Das Fenster von 11:00-16:00 Uhr war natürlich am Vortag auch bereits vorhanden, jedoch wird immer nur ein Fenster pro Tag angezeigt und mit dem min Preis von fc0+fc1 erschien es von 03:00-05:00 Uhr als nächstes Fenster noch günstig. Mit der aktualisierten Berechnung von nur fc1, was zu fc0 wurde, hat sich der min Preis von 29.7 auf 29.5 gesenkt und somit auch das Fenster verschoben.

Anwendungsfall für 1.:
Mir reicht eigentlich die (eine) Stunde mit dem niedrigsten Strompreis als Zeitfenster aus, um sie im DOIF für Aktionen zu nutzen. Das kann ich mit dem Preisvergleich current_price/fc_min auch lösen, eine direkte Zeit wäre natürlich flexibler, z.B. +/- 1 Stunde nutzbar.

In den meisten Fällen benötigt man jedoch mehrere Stunden für die Geräte (E-Auto, WP, Pool), weshalb ich ein Fenster unter einem bestimmten Preis berechnet habe.
In den userReadings wäre das an dieser Stelle, wo es bereits noch die Möglichkeit für eine Wirtschaftlichkeitsberechnung zum Speicherladen gibt.
Wenn Du dort das $price_level = $fc_min setzt, bekommst nur noch das Minimum, also unter Umständen nur eine Stunde als Trigger zurück.

Code Auswählen Erweitern

fc_trigger_price:fc_avg.* {
## fc_trigger_price:[fc_avg|compensation_grid].* {
  my $fc_avg = ReadingsVal("$NAME","fc_avg",0);
  my $fc_min = ReadingsVal("$NAME","fc_min",0);

  # Berechnung eines Default Schwellwertes als täglicher Niedrigpreis
  my $price_level = round( ($fc_avg - $fc_min)/2 + $fc_min , 1);            <<<< Hier wäre die bisherige Formel
 
  # Abschätzung von Wirtschaftlichkeit beim Speicher Laden, falls Tibber zu teuer wird
  if ( ReadingsVal("$NAME","compensation_grid",0) != 0 ) {
    my $price_level_battery = round( ($fc_avg - ReadingsVal("$NAME","compensation_grid",0)) *0.85 , 1) ;
    if ( $price_level > $price_level_battery ) {
      $price_level = $price_level_battery;
    }
  }
$price_level;
},

Eine weiter Variante wäre es rein reaktiv zu machen. indem Du im zu schaltenden Device jeweils current_price mit fc_min vergleichst, aber Achtung,Du musst current_price/100 rechnen, da ein reading in ct und eins in EUR angegeben ist. current_price ist in ct, da man das im EVU_Tibber als lesbar angezeigt bekommt und man den Strompreis meist in ct sehen möchte.

VG   Christian

[horchundkuck]

Wow, so schön ausführlich und nachvollziehbar. Da hatte ich doch ein Verständnisproblem, nun sehe ich klarer und werde mein DOIF besser anpassen können. Vielen Dank!

LG Heinz

[ch.eick]

Moin,
ich weiß nicht, ob ich es vergessen habe, aber in meiner aktuellen Version habe ich fc_min, fc_max und fc_avg im userReadings mit Perl berechnet, damit einige Datenbank Aufrufe entfallen. Für den fc_med bleibt es allerdings bei der DB, falls den Wert jemand verwendet.

VG  Christian

[horchundkuck]

_med musste ich aus dem Reading entfernen, da ich nur SQLite installiert habe (an der Installation von mySQL oder MariaDB auf meinem rasbpi bin ich gescheitert, darum kümmere ich mich später noch einmal), auch die Summen für heute, Monat und Jahr bekomme ich nicht richtig rechnend angepasst. Ist mir aber auch (noch) nicht so wichtig, da ich diese Daten nicht weiter verwende und auch in der TibberApp einsehen kann.

[ch.eick]

_med musste ich aus dem Reading entfernen, da ich nur SQLite installiert habe (an der Installation von mySQL oder MariaDB auf meinem rasbpi bin ich gescheitert, darum kümmere ich mich später noch einmal)

Das würde ich einfach als Docker Container verwenden.

, auch die Summen für heute, Monat und Jahr bekomme ich nicht richtig rechnend angepasst. Ist mir aber auch (noch) nicht so wichtig, da ich diese Daten nicht weiter verwende und auch in der TibberApp einsehen kann.

Dafür gibt es sicher eine standard SQL für SQLite, die man nur austauschen müsste.

[horchundkuck]

Dafür gibt es sicher eine standard SQL für SQLite, die man nur austauschen müsste.

Hab heute komplett auf MariaDB umgestellt, nun laufen alle deine Definitionen ohne dass ich dran "rumfummeln" muss ... und ich habe den Kopf wieder frei für andere Dinge 
Vielen Dank für deine Unterstützung
VG Heinz