Geräte zu Stundenpreisen (EPEX) oder PV-Überschuss betreiben
-
-
So, schnell mal neu geladen und es kommen jetzt keine 'Warnings' mehr, nur hier scheint noch was nicht zu stimmen
Ich konzentriere mich momentan auf das Tibber Script und es füllt momentan noch keine Werte auf. -
@dieterh sagte in Geräte zu Stundenpreisen (EPEX) oder PV-Überschuss betreiben:
So, schnell mal neu geladen und es kommen jetzt keine 'Warnings' mehr, nur hier scheint noch was nicht zu stimmen
Ich konzentriere mich momentan auf das Tibber Script und es füllt momentan noch keine Werte auf.Hallo Dieter, vielen Dank für Deine Rücksichtnahme :-).
Kannst Du bitte mal schauen, ob an der markierten Stelle, in Deinem Script die Konvertierung "Nach Zahl" enthalten ist?
Die Konvertierung ist im letzten Script-Export vom 29.12.2022 auch enthalten, war aber zwischenzeitlich dazugekommen, da ich den Fehler auch bekam. Mit der Konvertierung war der Fehler bei mir weg.Was meinst Du bitte mit "... es füllt ... keine Werte auf..."? Gar keine? Keine welche?
Gruß, Thomas
-
@thomkast
Ich hab da mal eine Frage zu deinem Geräte Script, du sprichst in der Beschreibung von:Wird die Betriebsart = "Start sofort" gesetzt":.......
Wie wählst du aus welche Betriebsart man möchte? Durch einen extra Schalter? Oder wie erfolgt das? Das ist mir nicht ganz klar....
-
@gizi
Hi. Wie Du den Wert setzt ist Dir überlassen. Der Datenpunkt ist bereits so angelegt, dass nur aus den möglichen Werten ausgewählt werden kann.
Anfänglich habe ich die Betriebsart darüber gewählt. Für meine Frau ist dann eine VIS mit Auswahlschalter entstanden
-
@thomkast
ah ja, super, dann mach ich das einfach mit nem Shelly WLAN Knopf an der Spühlmaschiene...... -
@gizi Achte nur darauf, dass Du genau die erwarteten Werte zurück gibst...
-
@thomkast ich müsste es noch so modifizieren das ich den PV teil raus nehme, die PV kommt erst noch (lieferzeit etc...)
Mit dem Knopf würde ich direkt den Wert steuern.
Ich würde ers gerne so machen das per "default" es immer auf Sofort steht. Erst wenn der Knopf gedrückt wird dann kommt EPEX zum tragen.
So kann man dann entescheiden, macht man NIX geht sie sofort an. Drückt man den Knopf springt EPEX an..... -
@gizi
Auch schön. In dem Fall müsstest Du die Betriebsart am Ende des Waschvorgangs aber wieder auf Deinen Default-Wert setzen.
In meinem Konzept bleibt die Betriebsart immer unverändert auf der letzten Auswahl stehen. Ist eine Konzeptfrage, über die wir nicht philosophieren brauchen. Beides geht und macht Sinn.
-
@thomkast
Ah - die Konvertierung hat bei mir gefehlt. Inzwischen läuft das Script - nach langem Suchen hatte ich herausgefunden, dass ich in einer Instanz noch 2 Haken setzen musste.
Ganz herzlichen Dank für Deine Unterstützung. -
@dieterh
Magst Du die 2 Haken kurz benennen? Vielleicht gehört es in die Beschreibung rein?..? -
@thomkast Das setzen des Wertes könnte etwas "tricki" werden, die Frage ist, wann weiss ich das sie fertig ist?
Die beiden Haken sind das hier im Java script adapter
-
@gizi
Danke für die Häkchen. Werde es oben mit einbauen.Deine Frage nach dem Waschende irritiert... und ich hoffe ich verstehe es nicht falsch. Denn...
Ganz am Anfang des Threads wird auf den Ursprungs-Thread verwiesen. Dort findet sich der Ablauf, die Erkennung der Stati und die einzelnen Stati erklärt. Danach weißt Du dann auch warum es den Datenpunkt "waschvorgang" gibt und wie das Waschende erkannt wird.
Solltest Du noch nicht reingeschaut haben... Es wäre ein Idee.
Gruß, Thomas
-
@thomkast hmm, stimmt, sollte ich mir nochmal anschauen, danke für den Hinweis.
-
Hallo zusammen - ich wünsche Euch allen ein gutes neues Jahr.
Thomas, ich habe die letzten Tage damit verbracht, mich in dein Werk einzuarbeiten.
Ich ziehe meinen imaginären Hut, denn Du hast ja wirklich alle Register gezogen und ein sehr komplexes Werk geschaffen.
Ich habe bereits begonnen es auf meine Belange anzupassen und lerne auch jeden Tag dazu. Ich muss gestehen, dass ich die letzten Jahre meine Hausautomatisierung auf SYMCON aufgebaut habe, dort werden die Scripte in PHP geschrieben.Nun aber noch eine Beobachtung die ich die letzten Stunden gemacht habe:
Obwohl Tibber bereits die Daten vom nächsten Tag zur Verfügung gestellt hat, wurden diese nicht von deinem Tibber-Script übernommen. Ich hatte die Abholzeit 15:00 eingetragen und das Script ist dann wohl auch gelaufen, denn es hat die Werte für heute übernommen - für morgen aber alles mit (NULL) gefüllt. Damit fehlten dann auch die Berechnungen für die günstigsten Stunden.
Hast Du eine Idee, was das sein könnte? -
@dieterh Hallo, hatte ich auch erst gedacht. Die Preise für morgen waren aber auf der API auch noch nicht da. Die Preise für morgen werden seit ca 15:30 angeboten. Lass dein Script nochmal laufen. Die Preise sollten dann aktualisiert werden.
-
@mikerow said in Geräte zu Stundenpreisen (EPEX) oder PV-Überschuss betreiben:
@dieterh Hallo, hatte ich auch erst gedacht. Die Preise für morgen waren aber auf der API auch noch nicht da. Die Preise für morgen werden seit ca 15:30 angeboten. Lass dein Script nochmal laufen. Die Preise sollten dann aktualisiert werden.
@mikerow - du hast recht, um 16:00 Uhr waren dann auch die Daten von morgen drin.
Eine Sache stört mich jedoch: nach dem Lauf zeigte 'Geringster_Preis' einen Wert von heute Morgen um 03:00 Uhr - also aus der Vergangenheit.
Vielleicht sollten wir versuchen, die Funktion 'guenstigster_preis' von der aktuellen Stunde bis Mitternacht einzugrenzen? -
@dieterh Ich denke da muss @ThomKast was zu sagen. Betrachtet auf den laufenden Tag wäre es ok. In seinem Script zieht er die Preise bei Tageswechsel um. Dann müsste eine Neuermittlung der günstigsten Stunden stattfinden. Er hat das vermutlich berücksichtigt.
Ich werde das aber für mich etwas anders machen. Ich zapfe die Daten von Thomas an und schaue ob der aktuelle Preis über oder unter dem Durchschnitt ist.
Ähnlich wie in diesem Scriptable Script für IOS.
Für meine Frau ist das besser zu erfassen. -
@dieterh said in Geräte zu Stundenpreisen (EPEX) oder PV-Überschuss betreiben:
@ThomKast,
folgendes ist mir aufgefallen: ich habe heute die Tibber Files um 15:30 Uhr gezogen und nach dem Lauf zeigte 'Geringster_Preis' einen Wert von heute Morgen um 03:00 Uhr - also aus der Vergangenheit.
Es sieht auch so aus, als ob 'Preis_Hysterese_Stunden' die Werte von heute Morgen zeigt und nicht die Werte von heute Nacht, bzw. morgen früh.Vielleicht sollten wir versuchen, die Funktion 'guenstigster_preis' von der aktuellen Stunde bis Mitternacht einzugrenzen, um realistischere Werte zu erhalten?
-
Hallo zusammen. Ich bin diese Woche unterwegs und kann leider nur sehr eingeschränkt antworten...
Die günstigste Stunde ist erst mal nur eine Information. Ob diese in der Vergangenheit liegt ist daher unerheblich. Eigentlich diente mir der Datenpunkt nur zur Kontrolle.
Wichtiger ist der geringste Preis, der zu dieser Stunde gilt, denn auf diesen wird der prozentuale Aufschlag "Hysterese" gerechnet. Alle Stunden, in denen die Preise kleiner-gleich dieses Preises sind, werden als günstigeStunden ausgewiesen. Und zu diesen Stunden "Preis_Hysterese_Stunden" wird die epex-Freigabe erteilt. Dies können dann auch wieder Stunden in der Zukunft am selben Tag sein.
Nachts um 00:02 erfolgt der Umzug der tomorrow-Werte auf today und es erfolgt erneut die Bestimmung des geringsten Preises und,..., von vorn...Ja, die Preise stehen teils erst zum 1600 oder später zur Verfügung. Darauf habe ich keinen Einfluss. Einfach die Abholzeit etwas später wählen. Es geht ja nix verloren
.Beste Grüße, Thomas
