[V4.0 IP8.1] NodeRed und Tibber-Preisanalyse
Verfasst: Do Mär 14, 2024 6:56 pm
Hallo zusammen,
ich beschäftige mich aktuell etwas mit NodeRed und der Auswertung meiner Tibber-Daten.
Da ich meine PV-Speicher im Winter noch mehr Ladenzyklen bescheren möchte, brauche ich hier mehr Informationen zum Preisniveau der aktuellen Stunde und wann denn demnächst wieder günstiger aus der Batterie entnommen werden kann als direkt aus der "Steckdose".
Ich will den Thread hier mal dazu verwenden meine Umsetzungen zu beschreiben und nehme gerne weitere Anregungen entgegen.
Es darf sich auch gern jemand mit profundem JavaScript Kenntnissen gern melden für einen CodeReview. Denn die Hilfe von MS-Copilot bringt zwar was man funktionell will, aber das es guter Code ist bedeutet es noch lange nicht.
Die Anbindung der Tibberpreise für 24h Heute und den 24h Morgen mache ich jeweils einmal am Tag. Um 0:00 Uhr wird die API für heute abgefragt und kurz nach 13:00 Uhr wird die API für die Preise Morgen abgefragt. Dafür gibt es im NR auch passende fertige Tibber-Nodes.
Ich speichere diese JSONs direkt jeweils in einer Contextvariable.
Damit diese Context-Variablen auch einen Restart und Reboot des TWS-Containers überleben, muss man in der settings.js (man erreicht sie über einen SSH Zugriff auf dem angelegten data volume für den Container) noch die Option setzen, dass die Contextvariablen auch auf dem Filesystem gesichert werden und nicht nur im RAM. Die Sicherung erfolgt dann im 30-Sekunden Takt das ist wohl irgendwo fest hinterlegt.
Die Passage war bei mir in dem Settings file bereits enthalten aber per // auskommentiert.
Die Kommentierungen entfernt und den NR-Container restartet und schon werden Context-Variablen auch im Filesystem persistiert.
Hinter dem Datenabzug habe ich nun jeweils einen Function-Node gesetzt.
Mit dem nächtlichen Abzug der Tagespreise werden direkt auch Statistiken berechnet. Die Statistiken berechne ich für alle drei Preisbestandteile getrennt (Gesamtpreis, Strom, Steuer).
Ich berechne hier über 30-Tage (Der Parameter kann eingestellt werden) Minimum, Maximum, Durchschnitt, Standardabweichung, für die letzten 7-Tage auch noch Minimum und Maximum.
Dazu bilde ich quasi aus den tgl. einlaufenden JSON ein großes Sammel-JSON was dann bis zu 30*24 Array Elemente aus diesen Preisen erhält. Das JSON wird dann quasi rollierend erweitert, hinten 24 rein vorne 24 raus. Das JSON wird ebenfalls in einer Context-Variable gespeichert dabei entsorge ich aber die Spalten Währung und Level.
Im direkten Anschluss erfolgt dann über zwei for each Schleifen die Berechnung der Statistiken.
Es ist ein etwas umständlicher Weg, aber die Berechnung dauert nicht so lange und ich wollte das alles nicht erst irgendwie in eine Datenbank umgewandelt speichern und dann per SQL wieder auslesen, auch wenn mit dem SQL die Berechnungen ebenfalls einfach möglich wären. Ich habe aber keinen Rechner wo ich da eine passende Datenbank drauf habe und will das auch nicht irgendwo einrichten.
Bei der stündlichen Abfrage des aktuellen IST-Preises habe ich ja eh die Daten im TWS in der Influx für bunte Bilder im Grafana und der Visu.
Datenspeicherung mit Zukunftszeitstempeln in der TWS-Influx-Instanz sind ja nicht möglich, daher gehe ich halt Wege ohne dies zu benötigen, da ich auch keine zweite Influx-Instanz aufsetzen möchte. Die Charts würden da zwar sicher schöner aussehen mit Forecast Informationen für den Tag. Aber derzeit tut es das auch so.
An die Abfrage der Zukunftsdaten habe ich ebenfalls eine function gebaut die für kommenden 24h plus der restlichen zukünftigen Stunden des laufenden Tages, die gleichen Statistiken berechnet (Minimum, Maximum, Durchschnitt, Standardabweichung).
Nächster Schritt wird sein, diese Statistiken für die Zukünftigen Daten stündlich neu zu berechnen und jeweils die vergangene Stunde aus der Berechnung wegzulassen.
Im Anschluss ergeben sich dann schon recht einfache Möglichkeiten in einfachen Wertevergleichen ob es sich lohnt in der laufenden Stunde den Akku zum Beladen oder Entladen für Eigenverbrauch frei zuschalten.
Je nach Größe der vorhanden PV Anlagenkapazität und Ertragspotentiale (Jahreszeiten) ergeben sich da ja recht unterschiedliche Schaltoptionen.
Bei mir geht es bei aktuelle PV-Kapazität eher darum ein wenig über die untertägigen oder teilweise mehrtägigen Preisschwankung die Stromrechnung zu reduzieren.
letztlich hatte ich den Akku in 3h komplett gefüllt dann einige Stunden abgeschalten, da noch Sonne kam und ab dem Abend wieder eingeschaltet und dann den Folgetag mit erheblich höheren Strompreisen komplett aus dem Akku bedient.
Ja das sind alles nur einstellige EUR die ich da derzeit sparen kann, aber es geht hier erstmal um das Funktionsprinzip.
Die Statistikergebnisse will ich dann an den TWS schicken und in seinen Logiken die Schwellwertabgleiche erledigen. Ich will mich ja nicht nur in Java-Script weiterbilden, sondern auch mit der TWS Logik.
ich beschäftige mich aktuell etwas mit NodeRed und der Auswertung meiner Tibber-Daten.
Da ich meine PV-Speicher im Winter noch mehr Ladenzyklen bescheren möchte, brauche ich hier mehr Informationen zum Preisniveau der aktuellen Stunde und wann denn demnächst wieder günstiger aus der Batterie entnommen werden kann als direkt aus der "Steckdose".
Ich will den Thread hier mal dazu verwenden meine Umsetzungen zu beschreiben und nehme gerne weitere Anregungen entgegen.
Es darf sich auch gern jemand mit profundem JavaScript Kenntnissen gern melden für einen CodeReview. Denn die Hilfe von MS-Copilot bringt zwar was man funktionell will, aber das es guter Code ist bedeutet es noch lange nicht.
Die Anbindung der Tibberpreise für 24h Heute und den 24h Morgen mache ich jeweils einmal am Tag. Um 0:00 Uhr wird die API für heute abgefragt und kurz nach 13:00 Uhr wird die API für die Preise Morgen abgefragt. Dafür gibt es im NR auch passende fertige Tibber-Nodes.
Ich speichere diese JSONs direkt jeweils in einer Contextvariable.
Damit diese Context-Variablen auch einen Restart und Reboot des TWS-Containers überleben, muss man in der settings.js (man erreicht sie über einen SSH Zugriff auf dem angelegten data volume für den Container) noch die Option setzen, dass die Contextvariablen auch auf dem Filesystem gesichert werden und nicht nur im RAM. Die Sicherung erfolgt dann im 30-Sekunden Takt das ist wohl irgendwo fest hinterlegt.
Code: Alles auswählen
/** Context Storage
* The following property can be used to enable context storage. The configuration
* provided here will enable file-based context that flushes to disk every 30 seconds.
* Refer to the documentation for further options: https://nodered.org/docs/api/context/
*/
contextStorage: {
default: {
module:"localfilesystem"
},
},Die Kommentierungen entfernt und den NR-Container restartet und schon werden Context-Variablen auch im Filesystem persistiert.
Hinter dem Datenabzug habe ich nun jeweils einen Function-Node gesetzt.
Mit dem nächtlichen Abzug der Tagespreise werden direkt auch Statistiken berechnet. Die Statistiken berechne ich für alle drei Preisbestandteile getrennt (Gesamtpreis, Strom, Steuer).
Ich berechne hier über 30-Tage (Der Parameter kann eingestellt werden) Minimum, Maximum, Durchschnitt, Standardabweichung, für die letzten 7-Tage auch noch Minimum und Maximum.
Dazu bilde ich quasi aus den tgl. einlaufenden JSON ein großes Sammel-JSON was dann bis zu 30*24 Array Elemente aus diesen Preisen erhält. Das JSON wird dann quasi rollierend erweitert, hinten 24 rein vorne 24 raus. Das JSON wird ebenfalls in einer Context-Variable gespeichert dabei entsorge ich aber die Spalten Währung und Level.
Im direkten Anschluss erfolgt dann über zwei for each Schleifen die Berechnung der Statistiken.
Es ist ein etwas umständlicher Weg, aber die Berechnung dauert nicht so lange und ich wollte das alles nicht erst irgendwie in eine Datenbank umgewandelt speichern und dann per SQL wieder auslesen, auch wenn mit dem SQL die Berechnungen ebenfalls einfach möglich wären. Ich habe aber keinen Rechner wo ich da eine passende Datenbank drauf habe und will das auch nicht irgendwo einrichten.
Bei der stündlichen Abfrage des aktuellen IST-Preises habe ich ja eh die Daten im TWS in der Influx für bunte Bilder im Grafana und der Visu.
Datenspeicherung mit Zukunftszeitstempeln in der TWS-Influx-Instanz sind ja nicht möglich, daher gehe ich halt Wege ohne dies zu benötigen, da ich auch keine zweite Influx-Instanz aufsetzen möchte. Die Charts würden da zwar sicher schöner aussehen mit Forecast Informationen für den Tag. Aber derzeit tut es das auch so.
An die Abfrage der Zukunftsdaten habe ich ebenfalls eine function gebaut die für kommenden 24h plus der restlichen zukünftigen Stunden des laufenden Tages, die gleichen Statistiken berechnet (Minimum, Maximum, Durchschnitt, Standardabweichung).
Nächster Schritt wird sein, diese Statistiken für die Zukünftigen Daten stündlich neu zu berechnen und jeweils die vergangene Stunde aus der Berechnung wegzulassen.
Im Anschluss ergeben sich dann schon recht einfache Möglichkeiten in einfachen Wertevergleichen ob es sich lohnt in der laufenden Stunde den Akku zum Beladen oder Entladen für Eigenverbrauch frei zuschalten.
Je nach Größe der vorhanden PV Anlagenkapazität und Ertragspotentiale (Jahreszeiten) ergeben sich da ja recht unterschiedliche Schaltoptionen.
Bei mir geht es bei aktuelle PV-Kapazität eher darum ein wenig über die untertägigen oder teilweise mehrtägigen Preisschwankung die Stromrechnung zu reduzieren.
letztlich hatte ich den Akku in 3h komplett gefüllt dann einige Stunden abgeschalten, da noch Sonne kam und ab dem Abend wieder eingeschaltet und dann den Folgetag mit erheblich höheren Strompreisen komplett aus dem Akku bedient.
Ja das sind alles nur einstellige EUR die ich da derzeit sparen kann, aber es geht hier erstmal um das Funktionsprinzip.
Die Statistikergebnisse will ich dann an den TWS schicken und in seinen Logiken die Schwellwertabgleiche erledigen. Ich will mich ja nicht nur in Java-Script weiterbilden, sondern auch mit der TWS Logik.
