Tibber & Tibber Pulse

Begonnen von hyper2910, 20 November 2022, 10:27:31

Vorheriges Thema - Nächstes Thema

ch.eick

Hallo zusammen,
ich habe jetzt mein contrib aktualisiert. Das alte EVU_Tibber_connect mit Stundenbasis ist nicht mehr vorhanden und wurde ersetzt.
Generell werde ich nun überwiegend an dem neuen Stromboerse und Stromboerse_connect weiter arbeiten, bei dem die Funktionalität
vom EVU_Tibber_connect als Tibber_Live mit einfließt.

Zu finden ist das hier

VG   Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

jnewton957

Danke für deine Mühe.
Ich hatte mir das zwar alles schon auf Basis der EVU_Tibber_connect15 gebaut - aber gut, dass es nun im "Standard" ist.

Was mir auffällt:
Du berechnest nun avg,min,max praktisch ab 14 Uhr als 2-Tageswerte. In der Folge sind dann die Trigger, die sich darauf beziehen, auch auf 2-Tagesbasis. Was ist der Grund dafür?
Ich habe es auf FC0_ und FC1_ gelassen und somit auch die trigger auf 1-Tagesbasis. Nur so kann ich (in meiner Konstellation) insb. die Trigger für Speicherladen tagesaktuell verwenden. Gerade bei den Schanklungen zum Wochenende bzw. in der Nacht war das ansonsten sehr "ungenau" bzw. die Trigger wurden nicht gezogen. Und heutiges FC1 wird ja automatisch in der Nacht zu FC0 und so greife ich auch z.B. Trigger ab 0 Uhr bis in den Morgen ab.

Die Wirtschaftlichkeitsberechnung fc_avg - compensation_grid(Einspeisevergütung) beim fc_trigger_price kann ich irgendwie nicht nachvollziehen. Mittelwert - Einspeisevergütung und davon 85%(wegen Speicherverlust?). Auch hier kommt es dazu, dass der Trigger nicht zieht.
Beispiel heute: avg 33.78, min 31.17, trigger_price 28. Also keine Beladung bzw. Auslösen des Trigegrs, da selbst min über dem trigger liegt. Während ohne die Wirtschaftlichkeitsberechnung der Wert bei 32.6 liegen würde.

Klar kann man sich das alles selber bauen ... Oder habe ich da einen Gedankenfehler ?

Danke definitiv für deine Mühe und das coding.

FHEM6.2 auf Pi5
V 1.66 nanoCUL 433 (IT)
V 1.66 nanoCUL868 (HM)
sqlite3 LogDb
ELRO AB440, DECT200,  TFA30.3125, esp8266, HM, TabletUI, IR-Schreiblesekopf (Udo),tibber Pulse, Kostal Pico, cfos Wallbox, Modbus TCP

ch.eick

Zitat von: jnewton957 am 20 Dezember 2025, 10:56:18Danke für deine Mühe.
Ich hatte mir das zwar alles schon auf Basis der EVU_Tibber_connect15 gebaut - aber gut, dass es nun im "Standard" ist.

Was mir auffällt:
Du berechnest nun avg,min,max praktisch ab 14 Uhr als 2-Tageswerte. In der Folge sind dann die Trigger, die sich darauf beziehen, auch auf 2-Tagesbasis. Was ist der Grund dafür?
Ich habe es auf FC0_ und FC1_ gelassen und somit auch die trigger auf 1-Tagesbasis. Nur so kann ich (in meiner Konstellation) insb. die Trigger für Speicherladen tagesaktuell verwenden. Gerade bei den Schanklungen zum Wochenende bzw. in der Nacht war das ansonsten sehr "ungenau" bzw. die Trigger wurden nicht gezogen. Und heutiges FC1 wird ja automatisch in der Nacht zu FC0 und so greife ich auch z.B. Trigger ab 0 Uhr bis in den Morgen ab.
Die Berechnung über alle verfügbaren fc0 und fc1 Werte macht sinn, wenn es bei fc1 morgens tiefere Werte gibt, als zur Nacht von fc0, dann verschiebt sich die Triggerzeit z.b. von 22:00 auf 01:00 , da es nit den fc1 Werten einen niedrigeren Trigger_Price gibt. Ich kann aber gerne auch fc0 und fc1 Werte zusätzlich rein bauen. Gib einfach bescheid.
Beobachte mal den Trigger mit on/off, der geht auch über Nacht von fc0 auf fc1.

ZitatDie Wirtschaftlichkeitsberechnung fc_avg - compensation_grid(Einspeisevergütung) beim fc_trigger_price kann ich irgendwie nicht nachvollziehen. Mittelwert - Einspeisevergütung und davon 85%(wegen Speicherverlust?). Auch hier kommt es dazu, dass der Trigger nicht zieht.
Beispiel heute: avg 33.78, min 31.17, trigger_price 28. Also keine Beladung bzw. Auslösen des Trigegrs, da selbst min über dem trigger liegt. Während ohne die Wirtschaftlichkeitsberechnung der Wert bei 32.6 liegen würde.
Zum darmaligen Zeitpunkt und je nach Einspeisevergütung war es sinnvoller anstatt zu Laden doch besser ins Netz einzuspeisen, da auch noch die Ladeverluste anfallen.
Die Berechnung kann man gerne ändern, wenn es was besseres gibt.
Dieser Trigger hat definitiv einen niedrigeren Preis, ab dem das Laden dann "wirtschaftlich" wäre. Es soll nur eine Möglichkeit bieten zu einem anderen berechneten Preis den Speicher zu laden.

[/quote]
Klar kann man sich das alles selber bauen ... Oder habe ich da einen Gedankenfehler ?
[/quote]
Ich bau gerne alles ein, jedoch kam seit Jahren keine Rückmeldung oder Wünsche :-) Ich denke ich war der Zeit etwas voraus.

Falls Du also Ideen oder Wünsche hast, schick mir das einfach und wir bauen zusammen eine komplette Version, dann kann man auch zusammen die Fehler beseitigen, da ich durch die recht große PV-Anlage keine EVU Börsen Tarife verwende. Nach meiner Berechnung komme ich im besten Fall auf eine Null Runde und bekomme die höheren Grundgebüren gerade wieder raus. Nac meiner Preiserhöhung von eprimo habe ich ab Januar einen Arbeitspreis von 28 ct und mein Grundpreis liegt immer noch unter dem von Tibber.

VG   Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick