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

[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); 
    }

[ArnoD]

@modulo-n
Das ist merkwürdig, eigentlich müsste immer ein "billigsteZeit" gefunden werden, außer es gibt keine Tibber Preisdaten.
Hast du die neuste Version ohne async-Funktion bestLoadTime() ?
Diesen Fehler hatte ich gestern auch und konnte aber nicht herausfinden warum.
Wenn ich eine LOG Zeile vor "if (billigsteZeit)" einfüge, dann enthält die Variable "billigsteZeit" = null
Wenn ich dann aber in der for-Schleife die Variable "billigsteZeit" über einen log Eintrag zusätzlich abfrage, enthält diese ein Datum und alles funktioniert.

Das muss ich mir heute wenn ich daheim bin noch einmal ansehen.

[Modulo-N]

@arnod
Ich kann es mir auch nur so erklären, dass entweder keine Tibberdaten da waren... oder kein Block gefunden wurde.
Da der billigste Blockpreis ja auf infinity gesetzt ist rutscht das Skript ja automatisch in die Zuweisung einer billigsten Zeit, sobald überhaupt ein Blockpreis ermittelt werden konnte, denn egal wie hoch dieser ist, er ist < infinity und damit wird auch billigsteZeit vorbesetzt.
Komisch das Ganze...