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

[ReblausGT]

@merlin123 said in TibberLink Adapter:

Im Chart wird aber z.B. 0,3ct/kWh angezeigt, sind aber 0,3€/kWh

im Template steht

axisLabel: {formatter: "{value} ct/kWh"},

... da muss dann EUR oder € rein... soll ja so sein dass man sich das umbauen kann... du kannst ja auch einen BAR Graph daraus machen oder zur Not einen POLAR Chart....

Wie mache ich da jetzt die Stunden sichtbar, wo der Preis unterhalb des Triggerpreises liegt?

der Channel ist auf active = true? Der Preis hoch genug?

[ReblausGT]

@merlin123
FYI: bei der achse geht auch sowas:

axisLabel: {
       formatter: function (value) {
           return value * 100 + " ct/kWh";
       }
   }

da kann man zur Not auch in andere Währungen umrechnen :)

[Merlin123]

@reblausgt Danke für den Tipp mit der Beschriftung :)

Geht jetzt :)

Muss dann morgen mal schauen wie das Diagramm aussieht, wenn es noch keine Preise vom Folgetag gibt :)
Wann wird das Diagramm denn neu erzeugt? Zur vollen Stunde oder wenn es neue Preise gibt?

NACHTRAG:
Da ist doch noch ein Wurm drin...

Der Trigger steht auf 0.303, er zeigt aber für den 3.1. nicht alle Stunden an:

Sind das zu viele "Auto_laden" Blöcke? Oder hat das ne andere Ursache?

[ReblausGT]

@merlin123 said in TibberLink Adapter:

Der Trigger steht auf 0.303, er zeigt aber für den 3.1. nicht alle Stunden an:

Sind das zu viele "Auto_laden" Blöcke? Oder hat das ne andere Ursache?

Block Anzahl ist nicht begrenzt. Er macht aber was er soll.... der BestCost Typ arbeitet immer pro Kalendertag. Nachts um 0:00 würde sich dann das Ergebnis ändern.
Für andere Zeiträume nimm die LTF Variante.
Graph JSON wird jetzt jede Stunde neu geschrieben (wenn der aktuelle Preis empfangen wird). Und nach Änderungen der Einstellung.

Du kannst übrigens ruhig Leerzeichen in den Channel Namen verwenden.

[Steve 1]

Hallo liebe Leute,
ich bin seit 1.1. diesen Jahres Tibber-Kunde.
Auf meinem Handy läuft alle sehr gut.
Beim einrichten des Tibberlink-Adapters komme ich nicht weiter.
ich habe den API-Token eingetragen, bei Tibber-Haus sollte sich, nach lesen von diversen Anleitungen,
nach Neustart ein Wert eintragen.
Es passiert aber nichts, habe alles ausprobiert, wieder und wieder und jetzt frage ich euch wie es richtig gemacht wird.

Freue mich auf eure Hilfe.

PS: Habe die neueste Version 4.1.0

[SMS]

@paul53 Wie würde denn mein Blockly aussehen? Kannst du oder jemand mir dabei helfen?

Danke!

[Merlin123]

@reblausgt Leerzeichen: OK :)

so... nachdem heute der neue Tag ist sieht die Anzeige so aus:

Vorschläge:

1. Optional getrennte Diagramme für heute und morgen. Ich persönlich finde es verwirrend, wenn das Diagramm einmal nur heute und einmal heute und morgen anzeigt. (Vielleicht zur Erklärung: Ich bin neuodivers und für mich ist es einfacher, wenn Dinge immer gleich sind)
2. Anzeige der Blöcke auch für morgen. Gerade beim Auto Laden ist es ja oft so, dass die billigen Stunden Nachts sind. Und dann die Ladestunden nicht zu sehen ist nicht optimal.

Und allgemein: Danke für Deine Arbeit! Ist echt klasse! :+1:

[paul53]

@sms sagte in: Wie würde denn mein Blockly aussehen?

[Merlin123]

@paul53 ne... Da wo "Wert" ist kommt der Wert des DPs mit dem JSON rein (also das passt). Bei Attribut der Name des Attributes, z.B.
totalCost

Dann liefert der Block bei dem JSON aus dem DP

[{"from":"2025-01-01T00:00:00.000+01:00","to":"2025-01-02T00:00:00.000+01:00","cost":1.5221652831,"unitPrice":0.210564,"unitPriceVAT":0.033619,"consumption":7.229,"consumptionUnit":"kWh","totalCost":1.4510258931,"unitCost":1.5221652831,"currency":"EUR"}]

1.4510258931
zurück

EDIT: Hab das auf Grund des Hinweises von Homoran etwas umformuliert

[Homoran]

@merlin123 sagte in TibberLink Adapter:

Da wo "Wert" ist muss der DP mit dem JSON rein.

nein.
du triggerst auf Änderung des DP mit dem JSON.
Dann ist Wert das JSON

[mcm1957]

@merlin123 said in TibberLink Adapter:

@mcm1957 Und diese Antwort sagt mir jetzt was in Bezug auf "Neue Version = neue Versionsnummer"?

Ich habe lediglich gesagt, dass aus meiner Sicht eine neue Version eine neue Versionsnummer bekommen sollte, sobald diese "irgendwo" veröffentlicht wird.
Ich empfinde eine saubere Versionierung auch (oder vielleicht sogar gerade) bei Tests sehr wichtig und sinnvoll.

Ich hab ja oben das beste Beispiel geliefert:
Ich hatte V4.2.0 installiert. Nachdem ich neu von Git installiert hatte, stand da weiterhin 4.2.0.
Wurde jetzt wirklich die neue Version installiert? Oder ging vielleicht was schief?
und: Ich schreibe "bei V4.2.0" ist mir XY aufgefallen. Ein anderer sagt "Nö, das geht bei mir mit 4.2.0". Kein Mensch kann dann sagen, ob beide wirklich auf der gleichen Version sind.-

Das macht einfach alles unnötig kompliziert und ist halt sehr einfach vermeidbar.

Und wie gesagt: Das ist lediglich meine Meinung zu dem Thema Versionsnummern

Diese Antwort sagt, dass du keine Versionsnummer erwaten sollts wenn du von GITHUB installiert. Für versionierte Releases gibts NPM und die Repositories. Wenn du direkt vom Entwicklerstand installierst, dann sind Versionsnummern nicht relevant. Kein Mensch erhöht Versionsnummern bei jedem Commit.

und: Ich schreibe "bei V4.2.0" ist mir XY aufgefallen. Ein anderer sagt "Nö, ..

NÖ du hast eben nicht V4.2.0 installiert sondern eine GITHUB Version. Das ist was anderes. Wenn du nicht als Tester unterwegs bist solltest du halt nicht von Github installieren. Und wenn du gemeinsam mit dem Dev testest sind die Versionnummern irrelevant,

---

Nebenbemerkung:
Wenn es um den Test neuer Releases geht würde das Topic besser im Tester Bereich angesiedelt werden.

[mcm1957]

@reblausgt said in TibberLink Adapter:

@merlin123 Martin hat schon Recht... eigentlich sind das Arbeitsstände und keine Releases - damit keine Versionsnummer....
Aber Du hast auch Recht... wenn wir hier im Forum über Stände reden sollte man eine Build Nummer dazu haben. Daher:
Auf GIT gibt es jetzt eine 4.2.0-beta1 .... die aktualisiert die jsonFlexChart jetzt immer auch gleich bei Änderung der dynamischen Channel Config - nicht nur zur vollen Stunde

Wenn du den standard workflow für deploy verwendest dann werden x.y.z-alpha.n (oder -beta.n) auch auf npm deployed aber nicht mit latest sondern mit next getagged. Damit erscheinen diese Releases nicht im LATEST / BETA Repository sind aber sauber via admin UI installierbar (url iobroker.tibber@next eintippen).

Nur zu Info falls diese Beta / Alpha Achse gewunschen ist. Details gerne hier oder ev. noch besser auf Telegramm.

ACHTUNG: Bitte nicht einfach mit npm deploy raufschieben - dann kommen diese Release (unerwünschter Weise) ev. auch ins Repo. Per default wird nämlich das Tag 'latest' von npm gesetzt.

[Merlin123]

@homoran Ja, das meine ich an der Stelle, hab es undeutlich ausgedrückt. Mein Hinweis bezog sich vor allem auf den Inhalt bei "Attribut".

Ich pass das an. Danke für den Hinweis.

[Merlin123]

@mcm1957 sagte in TibberLink Adapter:

NÖ du hast eben nicht V4.2.0 installiert sondern eine GITHUB Version. Das ist was anderes. Wenn du nicht als Tester unterwegs bist solltest du halt nicht von Github installieren. Und wenn du gemeinsam mit dem Dev testest sind die Versionnummern irrelevant,

Da haben wir einfach verschiedene Ansichten.
Ich kenne das aus der Softwareentwicklung nur so, dass alles, was "irgendwo" abgelegt ist und jemand das von da installieren kann, saubere Versionsnummern hat. Allein wegen der geschilderten Problematik, dass dann zwei Leute verschiedene Stände installiert haben, und das nicht erkennbar ist.

"Wenn du nicht als Tester unterwegs bist solltest du halt nicht von Github installieren. "
Naja... Was mach ich denn hier gerade? Ich teste die neuen Sachen, stelle Fragen und gebe Rückmeldung.... Das die Version nicht stable (oder zumindest beta) ist, ist mir duchaus bewusst. ;)

Also: Wir haben da einfach verschiedene Ansichten, wie das gemacht werden soll/kann. Ich hab jetzt Deine Sicht verstanden, teile sie aber nicht ;)

[Homoran]

@merlin123 sagte in TibberLink Adapter:

Ich kenne das aus der Softwareentwicklung nur so, dass alles, was "irgendwo" abgelegt ist und jemand das von da installieren kann, saubere Versionsnummern hat. Allein wegen der geschilderten Problematik, dass dann zwei Leute verschiedene Stände installiert haben, und das nicht erkennbar ist.

dann darfst du nicht von github installieren

Das ist die Workbench des Entwicklers.
nicht das Auslieferungslager

da holst du einen nicht fertigen Prototyp runter

[SMS]

@homoran @Merlin123 @paul53

Meint ihr so dann:

in "jsonHourly" steht folgendes drin:

... (die letzetn 2 Einträge)

[{"from":"2025-01-03T09:00:00.000+01:00","to":"2025-01-03T10:00:00.000+01:00","cost":0.0719905256,"unitPrice":0.3050446,"unitPriceVAT":0.0487046,"consumption":0.236,"consumptionUnit":"kWh","totalCost":0.06902638435,"unitCost":0.0719905256,"currency":"EUR"},
{"from":"2025-01-03T10:00:00.000+01:00","to":"2025-01-03T11:00:00.000+01:00","cost":0.0027119862,"unitPrice":0.3013318,"unitPriceVAT":0.0481118,"consumption":0.009,"consumptionUnit":"kWh","totalCost":-0.00025215505,"unitCost":0.0027119862,"currency":"EUR"}]

Warum bei Attribut 0. ?

[paul53]

@sms sagte: Warum bei Attribut 0. ?

... weil die bisher gezeigten JSON nur ein Objekt enthielten.
Wenn das letzte Objekt in der Liste relevant ist:

[mcm1957]

@merlin123 said in TibberLink Adapter:

Da haben wir einfach verschiedene Ansichten.
Ich kenne das aus der Softwareentwicklung nur so, dass alles, was "irgendwo" abgelegt ist und jemand das von da installieren kann, saubere Versionsnummern hat. Allein wegen der geschilderten Problematik, dass dann zwei Leute verschiedene Stände installiert haben, und das nicht erkennbar ist.

Du übersiehst noch immer, dass Github NICHT ein Ort ist wo was zum Installieren für Tester im allgemeinen abgelegt ist. Github ist eher als geshartes Fileservice zu sehen. Und in zig Jahren der Softwarentwicklung die ich hinter mir habe wurd nie eine Versionsnumemr erhöht wenn ein Entwickler eine Codeänderung auf den gemeinsamen Bereich (damals cvs) gelegt hat nur damit ein Kolleg die Änderung mal mitnehmen und testen kann. Wenn du von Github installierst, dann installierst du den brandneuesten Softwarestand wie er am PC des Entwicklers liegt bzw. von dort gesichert wurde.

Und ja, die du kannst auch solche INstallationen nachvollziehen - nur nicht über die Versionsnummer. Bei Github Installationen diesnt die GH SHA als eindeutige Refrenz. Damit kannst du den Softwarestand 1:1 auf Guithub nachvollziehen. Du siehst diese iNfos sowohl bei der INstallation als auch später. Also gib ggF diese als Referenz an wenn der genaue Atsn wirklich mal notwendigs ein sollte:

Bei der Installation:
Installing hombach/ioBroker.tibberlink#a1c343893f8996658af5ab86475931f3809626e5...

Auf der Adapter Kachel:

Im Log

tibberlink.0 2025-01-03 13:47:40.669 info starting. Version 4.2.0-beta1 (non-npm: hombach/ioBroker.tibberlink#a1c343893f8996658af5ab86475931f3809626e5) in C:/ioBroker/node_modules/iobroker.tibberlink, node: v20.18.0, js-controller: 7.0.3

Und ja, die Versionsanzeige in Admin ist hier eher verwirrend und sollte entfernt werden.

[Merlin123]

@mcm1957 Auslöser der Diskussion war ja mein Einwand, dass man wegen der gleichen Versionsnummer nicht weiß, was genau bei jemand nicht installiert ist.

Hättest Du da einfach auf die GH SHA verwiesen, wäre alles geklärt gewesen. Ich kannte die GH SHA bisher nicht, da ich noch nie mit Github was entwickelt habe.
Aber Danke für die Erklärung. Wieder was gelernt.

Wo auch der Kachel im Admin sieht man die denn?

Bei mir sieht das so aus, egal wo ich mit der Maus hingehe

[Homoran]

@merlin123 sagte in TibberLink Adapter:

Wo auch der Kachel im Admin sieht man die denn?

eben nicht!
Deswegen

@mcm1957 sagte in TibberLink Adapter:

die Versionsanzeige in Admin ist hier eher verwirrend und sollte entfernt werden.

@mcm1957 sagte in TibberLink Adapter:

Damit kannst du den Softwarestand 1:1 auf Guithub nachvollziehen.