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

[BananaJoe]

@merlin123 sagte in TibberLink Adapter:

Und die für die Vis1 laufen unter Vis2 nicht.

Einspruch, Hörensagen ... Ja, die laufen nicht. Gibt es aber dafür https://github.com/inventwo/ioBroker.vis-2-widgets-inventwo/
Sehe ich bei mir sogar bei den verfügbaren Adaptern (ob das daran liegt das unter Beta unterwegs bin weis ich nicht)

[lesiflo]

@merlin123 Den Grauton stellst du hier ein:

[Merlin123]

@bananajoe Hab doch nix anderes gesagt.... Die für die Vis1 laufen unter 2 nicht und ich musste alles nachbauen... Mit denen für Vis2 (hab ich nicht explizit dazu geschrieben)

[Merlin123]

@lesiflo Danke! Schau ich mir mal an...

[BananaJoe]

@merlin123 mein Fehler!

[nkoebe]

@ReblausGT Super Arbeit mit dem Adapter, vielen Dank für deine Arbeit!

@lesiflo Auch von mir herzlichen Dank für's zur Verfügung stellen der View!
Eine Frage habe ich noch zu dem Schalter Autom. Limit, wie genau steuert der bei dir?

-> AN = Laden/Entladen nach einem Algorithmus (bin mir noch nicht 100% sicher, wie ich das genau steuern möchte)
-> AUS = Speicher wird gemäß Einstellungen der Schieber für jede Stunde konfiguriert

[Ralph 0]

Moin,

erstmal auch von mir vielen Dank für den Adapter!

Ich häng mich mal hier mit ran, weil es in meinen eigenen Thread leider keine Antwort gab.

Es geht um den LTF Stundenblock.

In der Instanz ist 'Bester Stundenblock LTF' angelegt. In den Objekten findet sich u. a. StartTime und StopTime.
Nach Eingabe beider Zeiten, StartTime: 2024-11-15T17:00:00.000+01:00 und StopTime: 2024-11-16T08:00:00.000+01:00, erschienen sofort die entsprechenden Stunden bei BlockStartFullHour und BlockEndFullHour.

Soweit so gut.

Nun hatte ich noch RepeatDays auf 1 gesetzt, damit nach Ablauf des Blocks am nächsten Morgen, dieser einen Tag weiter gesetzt wird. In Start- und StopTime stehen dann auch die neuen Zeiten korrekt, allerdings stehen in BlockStartFullHour und BlockEndFullHour nur Striche und keine neuen Werte.
Active ist true.

Klicke ich dann anschließend in den Wert StopTime und schließe das Fenster, ohne an dem Wert etwas geändert zu haben, erscheinen die neuen Werte für BlockStartFullHour und BlockEndFullHour sofort.

Wo ist mein Fehler?

[ReblausGT]

@ralph-0 Hi Ralph ..... könnte ein Bug sein .... wenn du nichts machst, und wartest bis kurz nach der nächsten vollen Stunde.... kommt dann BlockStart etc. von alleine?

[Ralph 0]

@reblausgt
Hi,
nein, bleibt mit Strichen stehen.
Was ich heute noch festgestellt hab, BlockStart und BlockEnd werden auch sofort aktualisiert, wenn der Adapter neu gestartet wird.

[ReblausGT]

@ralph-0 ..... jetzt habe ich mir meine code erst selbst noch mal anschauen müssen... LOL...
die start und stop werte werden eigentlich erst in der ersten Stunde des definierten Zeitraums erstmalig berechnet. Das soll auch so sein um je nach Zeitraum evtl. notwendige Preise des nächsten Tages schon zu haben.
Warum der Adapter das dann bei dir schon per Spezial "Trigger" schon um 8:xx macht - hab ich noch nicht verstanden.... das "Eintragen" der Zeit löst einen Berechnungslauf aus, aber er sollte trotzdem erst um 17:00 durchlaufen.
Ich meine schädlich ist es nicht... sollte aber nicht so sein.

[Ralph 0]

Ok, danke schon mal dafür.
Mein eigentliches Problem ist ja aber, dass die Start- und Endstunde des Blocks trotz Repeat=1 nur einmal angezeigt und dann für die nächsten Tage nicht aktualisiert wird.

[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.