TibberLink Adapter

[ReblausGT]

@ralph-0 hast du schon mal bis nach 17:00 gewartet? Dann sollte es eingetragen werden.

[Ralph 0]

@reblausgt
Ja, hab mehrere Tage gewartet, es bleiben die Striche stehen.
Da es mit Neustart des Adapters funktioniert, ist das aber als Lösung für mich erstmal in Ordnung. Ich starte den dann einfach per Script vor oder nach meinem Block neu.
Ich teste das aber parallel noch weiter. Falls da was rauskommt, teile ich das gern.

[ChrisWitt]

@reblausgt anfängerfrage :

Wie bekomme ich aus der Zahl (Z.b. im stundenblcok) eine Uhrzeit im 24h Format?

Danke

[Ralph 0]

@chriswitt
Ungetestet:
"Zahl" ist die aus dem Stundenblock.

let Uhrzeit = new Date(); 
Uhrzeit.setHours(Zahl, 0, 0, 0);
let UhrzeitString = Uhrzeit.toTimeString().substring(0, 5);

[ReblausGT]

@chriswitt said in TibberLink Adapter:

Wie bekomme ich aus der Zahl (Z.b. im stundenblcok) eine Uhrzeit im 24h Format?

Du meinst z.B, aus diesem Strin: 2024-11-23T22:00:00.000+01:00 ...?
Ich nutze gerne die bibliothek date-fns:

import { parseISO, format } from 'date-fns';

// Dein ISO-Datumsstring
const isoString = "2024-11-23T22:00:00.000+01:00";

// Den String in ein Date-Objekt umwandeln
const date = parseISO(isoString);

// Die Uhrzeit im 24-Stunden-Format extrahieren
const time24h = format(date, "HH:mm");

console.log(time24h); // Ausgabe: "22:00"

[allesQuark]

@reblausgt said in TibberLink Adapter:

@ralph-0 hast du schon mal bis nach 17:00 gewartet? Dann sollte es eingetragen werden.

Ich habe exakt die gleiche Problematik, dachte schon ich bin zu doof.
Auch nach mehreren Tagen Wartezeit keine neuen Werte. Nach Neustart des Adapters werden die Werte zwar aktualisiert, das finde ich aber unschön und ist so sicher nicht gedacht.
Repeat steht auf 1

[Ralph 0]

@allesQuark
@ReblausGT
Sehr gut, danke für die Rückmeldung, dann liegt's also auch nicht an mir :-).

Was ich inzwischen noch rausgefunden hab, vielleicht hilft's ja bei der Fehlersuche:
Der Neustart des Adapters per Script funktioniert. Wenn dieser allerdings vor der Startzeit des LTF-Blocks erfolgt, werden Start- und Endstunde auch zur Startzeit des LTF-Blocks nicht aktualisiert. Es bleiben Striche stehen.
Lasse ich den Adapter per Script eine Minute nach der Startzeit des Blocks neustarten, sind Start- und Endstunde sofort mit den richtigen Zahlen gefüllt.

Beispiel:
LTF- Block von 17-08, 14 Uhr Neustart des Adapters -> Striche vor und nach 17 Uhr

Neustart des Adapters um 17:01 -> Start- und Endstunde sofort korrekt eingetragen.

[allesQuark]

@ralph-0 Nach Updates vom Adapter auf v3.5.3 beta (vorher Version v3.5.1), Node.js auf v20.18.1 (vorher Version v18.20.5) und js-controller auf 7.03 (vorher Version 6.0.11) funktionierte es heute zum ersten Mal.

Den Adapter hatte ich schon vor mehreren Tagen upgedatet, das hatte nichts an der Problematik geändert.
Ich tippe bei mir auf Node.js als Lösung, verifizieren kann ich es allerdings nicht mehr.

[Ralph 0]

@allesQuark @ReblausGT
Werde ich mal bei mir testen. Bin derzeit beim js-controller auch auf 7.0.3, allerdings beim Adapter auf der stable und Node.js bei 20.18.0.

Einziges Update in den letzten Tagen war bei mir js-controller. Wenn es bei mir jetzt auch funktionieren sollte, würde ich behaupten, der war's.

[ReblausGT]

@ralph-0
@allesQuark
Also da hat es einen Fehler im Adapter.... Calculator Channel Type BestBlockLTF läuft nur einen Tag und verändert ab da nur noch die Startzeit und Endzeit entsprechend dem Repeat.... Issue 593

Ich habe da akut aber noch nicht wirklich eine Idee was das sein soll .... aber das wird schon.

Angeregt durch einen fleißigen Tester (Danke ULF!) ist aber eine andere Sache aufgekommen ... fällt vor allem bei BestSingleHoursLTF auf .... für was kann man eigentlich mehr wie 2 Tage einstellen??

Vorschlag wäre dass der Adapter für LTF Channels Start und Ende grundsätzlich nur für 2 aufeinander folgende Tage annimmt.... mehr Kostendaten hat er eh nie zur Verfügung. Mehr Reichweite geht dann nur über Wiederholungen. (hierbei müsste zusätzlich dann noch die Start-Uhrzeit großer/gleich der End-Zeit sein)
-> was haltet ihr davon? Ich denke die üblichen Use-Cases sollte man damit abbilden können.

Dann bleibt noch die Frage wie soll er umgehen mit z.B. LTF 10:00 Heute bis 14:00 Morgen .... Best Hour - nur eine Stunde.... Wenn heute die beste Stunde von 11:00 bis 12:00 ist würde er die nehmen.... die könnte aber das doppelte kosten wie alle Stunden die morgen kommen, er kennt die Daten aber halt noch nicht...
-> Ideen? Meinungen?

[Ralph 0]

@reblausgt
Schon mal besten Dank für die Suche.
Für meinen UseCase würden mir zwei Tage reichen. Ich suche die billigsten Stunden zwischen dem Nachmittag/Abendpeak und dem nächsten Morgenpeak.

Zur Frage bzgl. Deines letzten Absatzes. Für Daten, die noch nicht bekannt sind, kannst Du/Dein Adapter ja nichts. Das, denke ich, muss man dann selber sehen, wie man damit umgeht.

[Merlin123]

Gestern gab es ja eine Störung bei Tibber und tibberlink hat die Verbindung verloren.
Heute morgen ist mir aufgefallen, dass der immer noch orange ist und keine Verbindung hat. Nach manuellem Neustart ging alles wieder problemlos.

Wieso ist der nicht wieder alleine online gegangen?
Und: wie kann ich ggf. das am besten beheben, dass er wieder allein online geht (kenne ja nur zyklischer Neustart oder ein Script, dass "wenn offline" alle x Minuten nen restart versucht)

[ReblausGT]

@merlin123 Also bei mir gab es keine Störung - das ist - so meine Vermutung - Server abhängig. Mal hat man Pech, mal erwischt es alle

Bei mit läuft immer ein Adapter auf dem Testsystem mit, mit dem Test-Token.... den erwischt es immer als ersten, bzw. jeden Tag. Das geht aber auch wieder alleine online. Ist jetzt im Nachhinein schwer zu sagen was das bei Dir war.... evtl. auch nur Zufall, dass es beim Neustart wieder ging. Der Adapter erhöht die Abstände zwischen den Versuchen kontinuierlich, nach einer Nacht Ausfall ist das schon recht lange, da kann dein manueller Neustart etwas bewirken.

Die Logs der Nacht sind nicht zufällig noch da?

[Merlin123]

@reblausgt ne, die Logs hab ich nicht mehr... Vielleicht war es wirklich noch einfach die "restart Pause" vom Adapter....
Hatte das bisher in der Art noch nicht.
Mal beobachten.....

Was ist Sinn der Erhöhung der Wartezeit? Passiert was, wenn es zu oft versucht wird?

[ReblausGT]

@merlin123 Ja, die Server sind ja auch mal überlastet. Wenn man es kpl. übertreibt wird man eh gesperrt. '
Ich versuche halt auf dem Wege Last vom Server zu nehmen wenn er nicht mehr nachkommt - was halt leider viel zu oft passiert.

[Merlin123]

@reblausgt Ah OK. Macht Sinn

[Merlin123]

Seit dem Update auf die 4er Version geht
tibberlink.0.info.connection
häufig kurz auf false, dann wieder auf true.
Bisher ging der nur bei nem echten Problem auf false.
Hatte das 10:01, 10:02, 10:03 und jetzt wieder 10:50, 10:51 und 10:53.

Ist das Absicht mit der neuen Version oder soll ich ein Issue aufmachen?

[ReblausGT]

@merlin123 said in TibberLink Adapter:

Ist das Absicht mit der neuen Version oder soll ich ein Issue aufmachen?

Nö, keine Absicht.... muss ich mir mal ein LOG drauf setzen.... 10:50 macht jetzt im Rahmen der Änderungen spontan auch keinen Sinn.... Hm.....

[ReblausGT]

@merlin123 said in TibberLink Adapter:

Bisher ging der nur bei nem echten Problem auf false.

Also ich kann es akut nur so feststellen.... Schalte mal den Debug Mode an.... da hat sich nichts geändert, ich schreibe nur nicht mehr so viel in das normale Log....

[Merlin123]

@reblausgt OK. Danke schonmal für's Prüfen. Ich hab jetzt mal das Debuglog aktiviert und schaue mal, ob es wieder auftritt.