UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[ArnoD]

@azzkikrboy
Dann stimmt bei dir was nicht, das Script ruft nur einmal zwischen 4:00 Uhr und 5:00 Uhr die Daten ab.
Entweder laufen bei dir zwei Instanzen oder es wurde etwas nicht sauber beendet.
Du kannst mal versuchen, den Javascript Adapter zu stoppen und wieder zu starten und dann prüfen ob es wieder funktioniert.

[ArnoD]

@psrelax

Der Unterschied zwischen Spitzenstrompreis und niedrigstem Strompreis ist doch viel zu gering, um den Batteriepreis zu übersteigen.

Kann dir hier nicht ganz folgen :-)
Der Batteriepreis ist bei dir 0,1057 € bedeutet, dass die Entladesperre deaktiviert wird, sobald der Tibberpreis höher ist. Das hat erstmal nichts mit dem Schwellwert zu tun.

Dann Einstellung Schwellwert hoher Strompreis bei 0,26 € bedeutet, wenn Tibber Preis darüber ist, hohe Preisphase, es wird nur geladen um eine Spitzenstrompreisphase (Peak) zu überbrücken, ansonsten wird nicht geladen.
Wenn der Tibber Preis aber über Schwellwert hoher Strompreis plus Ladeverluste ist = 0,2955 dann ist gerade eine Spitzenstrompreisphase (Peak) und es wird gar nicht mehr geladen, solange diese andauert, sondern entladen, außer dein Batteriepreis wäre noch höher, dann wird auch da nicht entladen.

Das ist der Grund, warum bei der Einstellung Schwellwert hoher Strompreis bei 0,26 € nicht geladen wird.

Dann Einstellung Schwellwert hoher Strompreis bei 0,50 € bedeutet, wenn Tibber Preis darunter ist, normale Preisphase, es wird der günstigste Preis gesucht und die Batterie bis auf eingestellten max. SOC geladen. Wenn während dem Laden durch die Verlängerung der Batteriereichweite ein günstigerer Preis gefunden wird, wird das Laden abgebrochen und gewartet bis diese Preisphase erreicht wird, um dann da zu laden. Entladen wird hier nur, wenn der Tibber Preis über Schwellwert hoher Strompreis ist und der Batteriepreis kleiner aktueller Tibber Preis ist.

Deswegen wird bei Einstellung Schwellwert hoher Strompreis bei 0,50 € geladen.

Die Frage ist halt was du bei dem Tibber Diagramm erreichen willst. Wenn du willst das z.B um 7:00 Uhr geladen wird um dann ab 16:00 Uhr zu entladen musst du den Schwellwert hoher Strompreis auf 0,31 € einstellen.

Wenn du aber der Meinung bist der Strompreis ist dir schon zu hoch um überhaupt zu laden, dann kannst du den
den Schwellwert hoher Strompreis auf 0,26 € einstellen und nur noch bei diesem Preis Laden.

Um aber zu verstehen wie du dir die Regelung vorstellst müsstest du mir ein Bild vom Tibber Diagramm schicken und mir sagen wann du gerne laden und wann entladen würdest.
Es gibt auch die Möglichkeit die Schwellwerte automatisch nach dem günstigsten Strompreis innerhalb 48 h zu setzen und somit das ganze dynamisch zu gestalten. Hat halt dann den Nachteil das man es nicht mehr selber im Griff hat bis zu welchem Strompreis man seine Batterie noch verwenden will um aus dem Netz zu laden.

[ArnoD]

Ich mache mir mal Gedanken über eine automatische Anpassung vom Schwellwert, ich denke, das ist eventuell weniger verwirrend und man muss keine Einstellungen anpassen.
Das ganze werde ich zum an und abwählen ausführen, sodass man es sich selber noch aussuchen kann, was einem lieber ist. :-)

[ArnoD]

Tibber Skript,
Version: 1.3.0 auf Github hochgeladen.

Änderungen:

• neue Anwahl für automatische Preisanpassung in der View hinzugefügt
• Aktueller Batteriepreis wird wieder in der View angezeigt.
• Die Schwellwerte werden bei Anwahl autom. Preisanpassung jetzt dynamisch nach dem günstigsten Tibber Preis innerhalb 48 bzw. 24 Stunden gesetzt. (Testphase :-) )
• Neue Objekt ID "automPreisanpassung"
• Fehler behoben, dass noch mal nachgeladen wurde, wenn der Batterie SOC um 1% abgefallen ist. Das führte zu ständigem ein und ausschalten der Batterieladung.

[psrelax]

@arnod
Bis jetzt schaut es sehr gut aus.
Heute war eine blöde Konstellation der Spitzen. Sag mir mal bitte, ob hier theoretisch geladen hätte werden müssen. Ich meine ja, zwischen den beiden Bergen.
Wenn du noch Logs brauchst, gib mir bescheid.

[ArnoD]

@psrelax
Da ist bereits der Preis zu hoch um zu laden, wenn dann hätte vorher von 0:00 Uhr bis 4:00 Uhr die Batterie noch geladen werden müssen.
Von 2:00 Uhr bis 3:00 Uhr wurde ja auch geladen, die Frage ist halt, ob die eingestellten 80 % erreicht wurden und wenn ja, ob man den Soll SOC nicht auf 90 % oder 100 % einstellen sollte, wenn man weis das eher nicht mit Sonne zu rechnen ist.
Es wird aber immer solche Situationen geben, wo man sich überlegt, ob es nicht besser wäre da noch mal zu laden.
Wenn man es sich aber mal ausrechnet, was man dann gespart hätte, ist das eher zu vernachlässigen.

Wenn ich mal davon ausgehe, dass du einen Stromverbrauch von 1000W hast, dann würde in der Situation folgende Berechnung zutreffen.

Kosten Laden von 12:00 Uhr - 13:00 Uhr 10 kWh Laden = 5 kWh *0,3784 = 1,892 € + 5 kWh * 0,3723 = 3,7535 €

Kosten ohne laden von 12:00 - 22:00 Uhr 0,3784+0,3723+0,3936+0,4465+0,5107+,05644+0,4543+0,39+0,363+0,3431+0,3237 = 4,54 €

Somit reden wir in dem Fall von 4,54 - 3,75 = 0,79 € Ersparnis, wenn man da geladen hätte.

[psrelax]

@arnod
Hast Recht, der SOC war bereits bei 80%. Ich hab ihn jetzt auf 99% gestellt.

[ArnoD]

Tibber Skript,
Version: 1.3.1 auf Github hochgeladen.

Änderungen:

• kleinere Optimierungen bei der automatischen Preisanpassung.

[ArnoD]

Tibber Skript,
Version: 1.3.2 auf Github hochgeladen.

Änderungen:

• kleinere Fehler behoben und code aufgeräumt

[Modulo-N]

@arnod : Hallo Arno...
Ich bekomme leider mehrmals am Tag diese Fehlermeldungen en masse (jeweils einmal pro Minute im Doppelpack):

javascript.0 20:10:53.850 error script.js.E3DC-Control.Tibber-1_3_2: Fehler in Funktion bestLoadTime: Cannot read properties of undefined (reading 'total')
javascript.0 20:10:53.852 error script.js.E3DC-Control.Tibber-1_3_2: Fehler in Funktion tibberSteuerungHauskraftwerk: Cannot read properties of undefined (reading 'getTime')

Der zweite scheint ein "Folgefehler" zu sein, aber der erste sieht komisch aus...

Ich glaube es liegt an der Zeile
blockPreis += entry.total;
denn dort ist der einzige Abruf von .total in der Funktion...

Vielleicht in index-Fehler?

Ich konnte den Fehler quick&dirty mit
if (entry != null) blockPreis += entry.total
also einer Prüfung auf Definiertheit von entry unterdrücken und siehe da, auch der Folgefehler ist weg. Das ist aber nur Rumdoktern an den Symptomen, die Ursache für den Fehler habe ich nicht finden können, muss aber irgendwie am Preis-Array liegen...

[ArnoD]

@modulo-n
Ja, den Fehler habe ich schon bemerkt, nur die Ursache noch nicht gefunden.
Habe bei mir bereits ein zusätzliches debug LOG eingefügt, um den Fehler einzugrenzen, aber seit dem ist er bei mir nicht mehr aufgetreten.

[Modulo-N]

@arnod
Ich hatte den Fehler gerade wieder und habe mir mal die Werte i und j sowie das Array ausgeben lassen. Das Array (siehe Anhang) hatte nur 24 Einträge (0 - 23) und somit gab es bei i=22 und j=2 erwartungsgemäß einen Indexfehler...
Die 24 Einträge sind die Einträge von heute, die von morgen fehlen (noch). Vielleicht hilft dir das bei der Fehlersuche.

Gruß

Michael
Array

[Modulo-N]

Ich denke, diese Zeile ist problematisch:

    for (let i = 0; i < datenTibberLink48h.length; i++) {

Da in der Prozedur ja noch j addiert wird und j nach oben durch ladezeit_h beschränkt wird, kommt es da zu Indexfehlern, wenn sich i dem Ende des Arrays nähert.

Eine Anpassung in

    for (let i = 0; i < datenTibberLink48h.length - ladezeit_h; i++) {

könnte das verhindern. Und da du ohnehin nach einem Block der Länge ladezeit_h suchst, wirst du in den dann verbleibenden letzten Einträgen des Arrays ohnehin nicht mehr fündig werden...

[ArnoD]

@modulo-n
Absolut richtig und deine Lösung ist auch richtig, Danke.
Bis zur Version 1.3.1 war das auch so, da hatte ich aber einen anderen Fehler drin und bei der Korrektur dann anscheinend zu viel gelöscht.

Vielen Dank für die Fehlersuche :-)

[ArnoD]

Tibber Skript,
Version: 1.3.3 auf Github hochgeladen.

Änderungen:

• Fehler in der Funktion bestLoadTime() behoben, danke an Modulo-N
• Fehler bei der Entladesperre behoben.
• kleinere Optimierungen

[Modulo-N]

@arnod
Jetzt gibt es einen neuen Fehler bei

        const diffBesteReichweiteLadezeit_h = (dateBesteReichweiteLadezeit_alt.getTime()-dateBesteReichweiteLadezeit.getTime())/ (1000 * 60 * 60)
        dateBesteReichweiteLadezeit_alt = dateBesteReichweiteLadezeit;

in tibberSteuerungHauskraftwerk

dataBesteReichweiteLadezeit_alt ist wohl in der ersten Zeile noch undefiniert und damit kann .getTime nicht ausgeführt werden...

Die Initiierung erfolgt in

     let hoherSchwellwert = 0, niedrigerSchwellwert = 0, peakSchwellwert = 0,dateBesteReichweiteLadezeit_alt = null;

und sollte ggf. mit einem Dummy vorbelegt werden... ich kenne die Logik nicht genau, aber ich habe mal den Wert mit dem aktuellen Datum belegt und der Fehler ist weg...

          let hoherSchwellwert = 0, niedrigerSchwellwert = 0, peakSchwellwert = 0
          let dateBesteReichweiteLadezeit_alt = new Date();

[ArnoD]

@modulo-n
Du hast meinen Fehler richtig korrigiert und ich werde es so übernehmen.
Habe aber gerade noch einen Fehler in der Funktion bestLoadTime() wo ich erst die Ursache finden muss und danach lade ich eine neue Version auf Github hoch.

[ArnoD]

Tibber Skript,
Version: 1.3.4 auf Github hochgeladen.

Änderungen:

• Fehler das die Variable "dataBesteReichweiteLadezeit_alt" bei der Deklaration falsch initialisiert wurde, danke an Modulo-N.
• Async bei der Funktion bestLoadTime() entfernt.

[ArnoD]

Tibber Skript,
Version: 1.3.5 auf Github hochgeladen.

Änderungen:

• Fehler das sich die Entladesperre immer aus und einschaltet behoben.
• Berechnung Batteriepreis optimiert.

[Modulo-N]

@arnod
Hi Arno... macht richtig Spaß, beim Debuggen zu helfen.

    if (billigsteZeit) {
        return new Date(billigsteZeit);
    } else {
        log(`function bestLoadTime: Kein Eintrag innerhalb des angegebenen Zeitraums gefunden`, 'error');
    }

Hier verbirgt sich auch noch eine kleine Falle, die mir heute Nacht das Log zugemüllt hat... Wenn keine billigsteZeit gefunden wurde, gibt die Funktion nix zurück und das erzeugt beim Aufrufer ein Problem, wenn dann <object>.getTime aufgerufen wird.
Mir fehlt allerdings eine Idee, was in diesem Fall ein sinnvoller Rückgabewert wäre, denn im gesamten Skript jeweils eine Überprüfung nachzuziehen, ob bestLoadTime() ein Date-Objekt geliefert hat, erscheint mir mühselig.
Die aktuelle Zeit zurückzugeben scheidet zumindest mal aus, weil dann das Skript ja sofort mit dem Laden beginnt.

Idee (nun also doch): Vielleicht sollte man einfach ein Datum-Objekt "aus der Zukunft" liefern, also z.B. now+48h. Das hätte den Charme, dass a) ein gültiges Objekt zurückkommt, mit dem das Skript arbeiten kann ( => Lade ich halt in 48h, es sei denn, es kommt dann vielleicht zwischenzeitlich was Günstigeres...) und b) das Laden tatsächlich unterbleibt, bis bestLoadTime() dann wirklich was Passendes in den "neuen" Tibberdaten findet.

Mein Vorschlag:

    if (billigsteZeit) {
        return new Date(billigsteZeit);
    } else {
        log(`function bestLoadTime: Kein Eintrag innerhalb des angegebenen Zeitraums gefunden`, 'error');
        return new Date(new Date().getTime() + 48 * 60 * 60 * 1000); 
    }