HS/FS Tibber-Preise auf dem HomeServer

[SvenB]

Noch in der Entstehung und mangels API-Key mit variablen Preisen auch noch nicht fertig getestet:
Die Tibber-Preise von heute und morgen (kommen Nachmittags) am Baustein mit ein paar Auswertungen.

Tibber_1.png
Die Ausgänge sind denke ich selbsterklärend außer die Stunden: Es handelt sich um eine Art Ringpuffer. Soweit vorliegend ist die aktuelle Stunde und alle nachfolgenden Stunden von heute und morgen. Sprich die letzte Stunde ist schon der Preis von morgen (oder -999 wenn leer). Denke die Zukunft ist interessanter als die Vergangenheit. Hab aber auch überlegt, ob man hier einen Eingang zur Konfiguration macht. Aber dann auch wieder schwierig, ob die Berechnungen (siehe unten) die alten Werte noch mitbetrachten oder nicht.

Wie funktioniert es

• Jede Stunde ruft der Baustein die Tibber-API ab und speichert die Ergebnisse zwischen. Wenn ich es richtig verstehe geht es auch nur um die "Day ahead-Preise" und nicht um die Live-Preise bei Tibber, also ausreichend oft.
• Alle 15s Läuft der LBS über die gecachten Preise, passt diese bei neuer Stunde an und legt sich wieder hin. - Evtl. optimiere ich das noch, wobei das so schon wenig Last ist.

Steuern könnte man nun entlang von nachgelagerten Bausteinen:

• current price <= x
• %avg <= 0,8
• weitere Ideen durch eigene Rechnung möglich

Die Werte könnten etwas springen: Bei einer neuen Stunde fällt die letzte Stunde raus aus der Berechnung oder wird durch die Stunde vom nächsten Tag ersetzt. Da die Werte vom nächsten Tag erst Nachmittags kommen werden mit den Werten alle Werte stark springen.

Aber fehlt noch was, was man lieber im Baustein macht? Denke hier an "Signalisiere die günstigsten N Stunden am Stück" und N ist ein Eingangswert.
Offene Diskussion, was würde fehlen?

Bevor nun jemand den aWattar-Baustein anfängt: Hier die Fetch-Methode austauschen ist nachher 5min Arbeit. Mache ich gern, wenn mir jemand dann einen Test-API Key gibt.

Todos:

• Brauche nen Tibber API-Key, der variable Preise im Tarif hat. (alle Kontakte haben bisher diese noch nicht)
• Tests, ob alles hin haut
• Closed Beta-Release
• Entscheidung, ob der Baustein mal kostenpflichtig wird oder nicht. Sicherlich am Ende wieder frei. Kein Bock auf 40€ Rechnungen schreiben und Gewährleistung.

Die Berechnungen und Ergebnisse sind alle ohne Gewähr. Für Verluste haftet ihr selbst. Tut ihr für die Gewinne daraus ja auch :-P

P.S.: Dieser Baustein ist nur für die Preise da. Nicht zum Melden oder Live-Werte von Tibber. Letzteres setzt auch GraphQL-Transport-WS voraus und die Libraries kriegt man mit Python 2.7 und dem Classloader-Wirr nicht zum fliegen - oder zumindest ich nicht.

Wer auch Tibber will kann am besten einer Empfehlung folgen. Es bekommen dann beide (Nutzer und Empfehler) 50€ für den internen Store und die kann man dann in den Tibber Pulse investieren: https://invite.tibber.com/5d3le6rs

[SvenB]

Kleines Update. Mein bestehender API-Key / Zugang geht ab morgen mit variablen Preisen und läuft sogar schon wie geplant. Für Ideen zur Steuerung bin ich offen.
ToDo was oben dazu kommt: SBC einführen für alle Eingänge die es noch nicht sind.

Tibber_2.png

Werden das nun mal testen und falls jemand Ideen hat: Immer gern her damit.

(Bitte keine Grundsatzdiskussion über variable Stromtarife hier im Thread!)

[En3rGy]

Ich meine, die API hat auch einen Wert, ob es aktuell teuer oder günstig ist. Der Ausgang ist auch noch interessant, um ad-hoc Verbraucher zu starten oder ggf. zu stoppen.

[SvenB]

Danke, ich gucke mir die API nochmal an.
Ich hab aber auch am Baustein weiter gemacht. Er sucht selbst schon nach der günstigsten Periode von N Stunden. Die Stunden kann man zw. 2-6 definieren.

Greenshot 2023-02-04 21.36.04.png

Bin noch nicht happy. Zum einen ist das rollieren der Preise zwar Ausgangs-Reduzierend, aber auch verwirrend. Ich denke ich mache mal 48 Ausgänge.
Und aktuell berechnet er die günstigsten Stunden immer neu. Das hat aber Nachteile, weil es ggf. nicht die günstigste Zeit am Tag ist, weil dieser schon war. Um Mitternacht immer neu rechnen mag gehen, muss aber zwingend den nächsten Tag berücksichtigen. So war gestern die günstigste Zeit 22-2 Uhr.

Also bin noch am Tüddeln :-) Alpha-Tester gern her.

[En3rGy]

Das mit den vielen Ausgängen finde ich schwierig. Was sind denn die Use Cases?

Mich interessiert doch eigentlich nur so was wie:
Wann ist es wie lange günstig?
Was ist der günstigste Preis?
Was der teuerste?
Lohnt es sich zu warten?

Ein Ausgang sollte ein bool sein „ist günstig“.

Wie wäre es dann einfach die extremsten Preise auszugeben und das nächste günstige Zeitfenster als Zahl (Start, Stop).

Dann noch den aktuellen Preis?

[SvenB]

Ja ich bin auch nur halb happy mit dem Strompreisausgängen. Vorallem isr das rollieren komplex zu verstehen und man müsste sonst 48 Ausgänge nur für Preise nehmen. Und außer Visu macht man damit nix. Und die HS Visu kann ja eher nur Archivdaten darstellen und da schreibt man „current price“ rein.

Tendiere daher auch dazu was du meinst: Alle Stundenpreise raus. Und nur noch den Aktuellen und Extreme. Sprich lieber noch mehr Such-Funktionen nach günstigsten Preisen heute, morgen, overall. Das wozu man sonst sehr sehr viele Bausteine bräuchte. Fokus auf Steuerung.

(Ausgangsgruppen und ein/ausblenden wäre hilfreich bei den Ausgängen wie Loxone es glaube ich hat)

[En3rGy]

Du kannst einen Ausgang machen, auf dem z.B. stündlich ein Json-String mit den zukünftigen stündlichen Preisen ausgegeben wir.
weiß nicht, wie die API aussieht aber wenn da was als String kommt, kannst du das auf einem Ausgang auch einfach durchschleifen.

[MichaelR]

Der Baustein wäre ideal für die Steuerung des Ladezeitpunkts und der Ladedauer durch die Wallbox. Meine Zappi läßt sich per ext. Schaltsignal entsprechend steuern. Andere Hersteller sicher auch. Gut wäre ein einstellbares "Vorschaufenster". Je nach dem wie schnell die Ladung erfolgen sollte bzw. das Fahrzeug wieder auf die Piste soll.

[SvenB]

Ein Lebenszeichen vom Tibber-LBS: Ich bekomme selber Tibber zum Monatsende und hab seit etwa zwei Wochen den Pulse.
Das führt dann zu neuen Motivationen und wird sicherlich bald eine Beta geben.

Neue Features: Die Live-Daten werden mittels Websocket (Danke derPaul für den Tipp nach der Python 2.7 kompatiblen Lib) und graphql-transport-ws immer an den Homeserver gepushed. Auch die Zählerstände, Spannungen etc.:

image.png

Updates kommen so alle 2-5s und ist alles Send-by-change mit vorheriger queue-Prüfung. Und das coole ist hier auch, dass die letzten beiden Ausgänge wirklich die Zähler-Stände vom Stromzähler sind. Also wer zu faul ist, um zum Zähler zu laufen bei ner Ablesung oder es in influxDB speichern will: Tada!

Wie man sieht habe ich dabei die Preisberechnung zerstört 😥

Die Preise von heute und morgen gibts je an nem Ausgang - wer die Details will.
Ich repariere es noch und dann will ich mehr Logiken rund um günstiger Preis und teurer Preis einbauen, um meine Wärmepumpe zu sperren oder das E-Auto zu laden.

[SvenB]

Wenn noch jemand auch Tibber möchte und noch keinen hat, der ihn wirbt. Mein Invite-Link: https://invite.tibber.com/5d3le6rs
Jeder bekommt 50€, die man im Tibber-Store z.B. gegen den Pulse einsetzen kann. Wenn der Regelmäßig verwendet wird, verschenke ich auch ein paar Pulse - weil hab sonst alles was ich brauche aus dem Store.

Ansonsten habe ich den LBS nun so, dass er funktioniert. Ich hab Common-Logik in eine eigene Library rausgezogen, so dass die Bausteine von mir alle etwas gleicher werden. Auch wurde das Fehler-Logging über das Debug stark ausgebaut.
Werde auch den Live-Data Ausgang noch so umbauen, dass der auf 0 geht, wenn was mit dem Pulse nicht passt. Hatte nun schon manchmal WLAN-Aussetzer (Unifi vs. Tibber)
Ich würde die Berechnung noch erweitern, aber könnte nun erstmal neue Alpha-Versionen raushauen. Also wenn jemand will: Eine PM schreiben.

Ich möchte aber wissen, was ihr vermisst / ändern würdet.
IMG_6170.jpg
Greenshot 2023-05-31 12.23.53.png

[BadSmiley]

Spaß mit Tibber:
Sven hat mich auch auf die dunkle Seite der Macht gezogen, nur um mich dann mit seinen Bausteinen und seiner Wunschliste auszuquetschen.
Einrichtung war lala, ich sage mal so.. ein Kabel, ist ein Kabel ist ein Kabel.
Heute muss ich laden, weil ich morgen nach München muss. Sonnenstrom gibt es heute nicht genug, Auto der Frau ist leer und Waschorgie nach dem Urlaub angesagt. Kurz, ich muss laden. äh egal.
Tibber App meldet, keine Verbindung zum Pulse, seit heute Nacht.
Also erstmal in den Keller marschiert und eine Stunde lang, das Stecker rein, Stecker raus Spiel gespielt. Verlängerung geholt, Bridge wo anders hin, kurz war Verbindung da, dann weg, dann da. Himmel.
Dann am Unifi Controller mal geschaut, Bridge hängt 2m vom AP im Keller, verbindet sich aber mit dem in der Werkstatt, klar dass da kaum was passiert. Also fest mit dem AP im Keller verbunden im Controller und nichts ging mehr. Also Verbindung aufgehoben, Bridge geht wieder in die Werkstatt. Mal die Logs angeschaut.. heute Nacht ging das fröhliche Roaming der Bridge zu den APs Werkstatt und Garage los...
Was war passiert? Der AP im Keller hat bei der nächtlichen Kanal Optimierung von Kanal 1 auf 6 gewechselt und seit dem war keine Verbindung mehr mit der Tibber Bridge möglich. Kanal fest auf 1 eingestellt, Bridge an den AP gebunden und seit dem ist alles optimal und ich kann laden.
Also wenn ihr auch so komische Probleme habt, mit plötzlich ist die Pulse/Bridge Verbindung weg und ihr habt ein Unifi Netzwerk. Schaut die Kanäle an und die Kanal Optimierung. Die Bridge, gefühlt keine 5€ beim Onkel Wong wert, kann nur 2,4Ghz und anscheinend nicht alle Kanäle.

[derPaul]

Darum ist in jedem Unifi Controller den ich administrieren muss/darf diese unsägliche "Kanaloptimierung" deaktiviert ... verursacht nur Probleme ...

[SvenB]

Ich hab auch schon zwei Orgien mit dem Unifi-Setup und dem Pulse hinter mir. Egal wo der Pulse-WLAN-Adapter steckt: RJ45 wären 50cm; so doof, dass das Ding auf nem ESP8688 oder so beruht und daher nur WLAN hat. Zumindest könnte Tibber mal ne Pushnachricht schicken, wenn eine Stunde oder zumindest ein Tag nix kam.
Motiviert mich aber sowas noch in den Baustein einzubauen: Livedaten sind verfügbar aber es kommen keine Daten ...
Ich hab die Kanaloptimierung des APs in der Nähe auch deaktiviert und nun geht alles.

ALPHA / BETA-Version

Da im Download-Bereich viele meinen "auch mit ner 0.x läuft alles toll": Ich veröffentliche die Vorversion erstmal hier: <removed - OLD>

Gebt gerne Feedback. Ich hab u.A. das Problem, dass wenn der HS ausgelastet ist, der Baustein die Queue vollspamed. Hier ist die HS-API auch selber schuld: Zwischen der Abfrage von ._can_set_output() und ._set_output_value(..) kann die Queue halt vollgeworden sein. Baustein stürzt dann nicht ab, man sieht es nur im Debug (wenn aktiviert).

Und auch wenn von Roman es so rüberkommt als werde ich damit reich: Das Gegenteil ist der Fall. Gerade in diesen Baustein sind fast 3-stellige Stunden gegangen. Reich wäre ich, wenn ich die Zeit in meine Firma investiert hätte ;-)

Todos:

• Hochpreisphasen berechnen
• Lücken zwischen Phasen auslassen
• Insgesamt bessere Berechnung
• Intern besseres Datenmodell für die Preise schaffen
• Weniger Debug-Nachrichten vom Prozess
• Ggf. aktuellen Verbrauch und aktuelle Einspeisung auf einen Ausgang legen und Einspeisung ist dann negativ.
• Fehler-Ausgang: Livedaten sollen da sein, aber es kommt nix mehr seit X Minuten.

Doku ist rudimentär vorhanden. Bitte erst da gucken!
Ich erwarte Feedback, Verbesserungen etc.

[SvenB]

Gibt's bisher Feedback zum Baustein?

Bei mir läuft er ganz gut. Aber ich seh gerade, dass er in 11 Tagen gut 1,1Mio mal auf die Ausgänge geschrieben hat. Davon gehen gut je 115k auf L1-L3 und je Volt und Ampere.

Ich würde mal consumption und production auf einen Ausgang legen, das spart schonmal gut 100k. Aber ich überlege, was ich mit den Volt und Ampere-Werte vom Stromzähler mache. Rechnen kann man mit denen ja auch nicht, da der CosPI fehlt. Hab das mal mit den Wechselrichtern und KSEM-Baustein verglichen: Die schreiben noch mehr, wenn sie alle 5s ein Update ziehen. Aber das ist genau der Punkt: Braucht man von 3 Geräten (Wechselrichter, KSEM, Stromzähler) die gleichen Werte.

Denke ich mache n Eingang und schalte sonst diese Zusatzinfos ab. Hat wer kein KSEM / Smartmeter, ist er ggf. sehr an den Werten interessiert.

So, euer Feedback so?

[En3rGy]

Wenn ich einen Ausgang nicht brauche, verbinde ich ihn nicht.
Ansonsten hänge ich ggf. einen SBC-Baustein mit Toleranz dran (weiter nur bei x% Prozent Änderung).
Di generierst einen Wert am Ausgang ja nur, wenn auch ein entsprechender Eingangswert rein kommt und nicht zyklisch. Das finde ich berechtigt.