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

[ReblausGT]

@schimi said in TibberLink Adapter:

habe persönlich keinen benefit von da die "cloud" aktualisierung exact gleich schnell ist (laut objekte)... der einizge vorteile wäre bei verlust der IInet verbindung....
Aber gutes future :-)

Solange die Cloud Variante funktioniert hast du absolut Recht. Leider gibt es immer wieder Probleme - jetzt haben wir eine Reservefunktion....

[ReblausGT]

@oxident said in TibberLink Adapter:

Lediglich die Unit der Phasenverschiebung hat's in die Zeichensatzhölle geworfen (°). Aber das ist ja Kosmetik.

gefixt für 3.4.2

[ReblausGT]

@arnod said in TibberLink Adapter:

@reblausgt
Diese Warnung wir auch bei mir im LOG ständig wiederholt:

2024-07-12 14:41:36.014 - warn: tibberlink.0 (6538) Calling Bridge metrics data
2024-07-12 14:41:36.102 - info: tibberlink.0 (6538) State value to set for "tibberlink.0.LocalPulse.0.PulseInfo.type" has to be type "number" but received type "string"
2024-07-12 14:41:36.148 - info: tibberlink.0 (6538) State value to set for "tibberlink.0.LocalPulse.0.PulseInfo.hub_attachments.node_version" has to be type "number" but received type "string"

warn: tibberlink.0 (6538) Calling Bridge metrics data war ein Debug mode von mir... sorry hatte ich vergessen - ist in 3.4.1 entfernt, eben released

den Rest muss ich mir mal ansehen.... da machen wir einen Issue daraus
https://github.com/hombach/ioBroker.tibberlink/issues/455
Die Werte die in die bemängelten Objekte übergeben werden wären hilfreich.

[ReblausGT]

@flisse said in TibberLink Adapter:

@reblausgt
Bekomme folgende Meldungen:

tibberlink.0
2024-07-12 06:56:27.900	info	State value to set for "tibberlink.0.LocalPulse.0.PulseInfo.hub_attachments.node_version" has to be type "number" but received type "string"

tibberlink.0
2024-07-12 06:56:27.856	info	State value to set for "tibberlink.0.LocalPulse.0.PulseInfo.type" has to be type "number" but received type "string"

tibberlink.0
2024-07-12 06:56:27.777	warn	Calling Bridge metrics data

siehe mein Kommentar von eben..... Aber die Werte kommen trotzdem rein?

[flisse]

@reblausgt
Danke. Meldungen treten jetzt nicht mehr auf.
Die Werte kamen die ganze Zeit rein, ob über Cloud oder Lokal kann man nicht erkennen oder?

[ReblausGT]

@reblausgt said in TibberLink Adapter:

@arnod said in TibberLink Adapter:

@reblausgt
Diese Warnung wir auch bei mir im LOG ständig wiederholt:

2024-07-12 14:41:36.014 - warn: tibberlink.0 (6538) Calling Bridge metrics data
2024-07-12 14:41:36.102 - info: tibberlink.0 (6538) State value to set for "tibberlink.0.LocalPulse.0.PulseInfo.type" has to be type "number" but received type "string"
2024-07-12 14:41:36.148 - info: tibberlink.0 (6538) State value to set for "tibberlink.0.LocalPulse.0.PulseInfo.hub_attachments.node_version" has to be type "number" but received type "string"

Fixed in 3.4.2 - in ein paar Minuten im Beta repo.....
bitte diese beiden status objekte einmalig löschen:

[ReblausGT]

@flisse said in TibberLink Adapter:

@reblausgt
Die Werte kamen die ganze Zeit rein, ob über Cloud oder Lokal kann man nicht erkennen oder?

Die Werte werden akut in unterschiedlichen Objekten bzw. Bereichen abgelegt. Man kann auch beides Nutzen. In sofern, ja, kann man unterscheiden.

[flisse]

@reblausgt
Ich war gestern wohl etwas zu voreilig. Ich bekomme immer noch diese Log-Einträge, lediglich die Warnung vorher tritt nicht mehr auf

tibberlink.0 2024-07-13 04:31:50.034	info	State value to set for "tibberlink.0.LocalPulse.0.PulseInfo.hub_attachments.node_version" has to be type "number" but received type "string"
tibberlink.0 2024-07-13 04:31:49.989	info	State value to set for "tibberlink.0.LocalPulse.0.PulseInfo.type" has to be type "number" but received type "string"
tibberlink.0 2024-07-13 04:30:49.922	info	State value to set for "tibberlink.0.LocalPulse.0.PulseInfo.hub_attachments.node_version" has to be type "number" but received type "string"
tibberlink.0 2024-07-13 04:30:49.881	info	State value to set for "tibberlink.0.LocalPulse.0.PulseInfo.type" has to be type "number" but received type "string"
tibberlink.0 2024-07-13 04:29:50.023	info	State value to set for "tibberlink.0.LocalPulse.0.PulseInfo.hub_attachments.node_version" has to be type "number" but received type "string"
tibberlink.0 2024-07-13 04:29:49.979	info	State value to set for "tibberlink.0.LocalPulse.0.PulseInfo.type" has to be type "number" but received type "string"
tibberlink.0 2024-07-13 04:28:49.873	info	State value to set for "tibberlink.0.LocalPulse.0.PulseInfo.hub_attachments.node_version" has to be type "number" but received type "string"
tibberlink.0 2024-07-13 04:28:49.832	info	State value to set for "tibberlink.0.LocalPulse.0.PulseInfo.type" has to be type "number" but received type "string"

Und so sieht der Objektbaum der lokalen Datenabfrage bei mir aus:

[ReblausGT]

@flisse said in TibberLink Adapter:

@reblausgt
Ich war gestern wohl etwas zu voreilig. Ich bekomme immer noch diese Log-Einträge, lediglich die Warnung vorher tritt nicht mehr auf

Und so sieht der Objektbaum der lokalen Datenabfrage bei mir aus:

Bitte 3.4.2 installieren - denke bei Dir läuft noch 3.4.1 (wenn schon installiert nocheinmal stoppen und starten)
und dann die beiden "fehlerhaften" states löschen:

sind nach ~1 Minute wieder da.

Dann sollte die Meldungen nicht mehr kommen.

[ReblausGT]

Wie ist eigentlich eure Meinung zu:

• Ausgabe der Zählerwerte in kWh statt Wh wie original vom Pulse gemeldet?
• Runden der Zählerwerte auf ganze kWh oder 1/10 kWh?
• Wegfall von eher unnützen Werten wie z.B. Firmware Version? Welche sind wichtig?
• Umrechnung der Uptime in menschentaugliche Darstellung?
• Ergänzen von Einheiten (V bei Batteriespannung etc.)

[paul53]

@reblausgt sagte: Runden der Zählerwerte auf ganze kWh oder 1/10 kWh?

Besser auf 10 Wh runden (2 Nachkomastellen).

@reblausgt sagte in TibberLink Adapter:

Wegfall von eher unnützen Werten wie z.B. Firmware Version? Welche sind wichtig?

Solche Konstanten würde ich unter "native" des Geräteobjektes bringen.

@reblausgt sagte in TibberLink Adapter:

Ergänzen von Einheiten (V bei Batteriespannung etc.)

Unbedingt!

[ArnoD]

Habe gerade die Version 3.4.2 installiert und läuft ohne Fehlermeldung oder Warnung im LOG. :-)

Zu deinen Fragen:

• Ausgabe der Zählerwerte in kWh statt Wh wie original vom Pulse gemeldet?

Da bei dem Zähler nur ganze kWh entscheidend sind, würde eine Ausgabe in kWh aus meiner Sicht passen.

• Runden der Zählerwerte auf ganze kWh oder 1/10 kWh?>

Hier würde ich auf ganze kWh abrunden. Also 1000954 Wh = 1000 kWh, da so jeder Stromzähler abgelesen wird, die Nachkommastellen werden dabei ignoriert.

• Wegfall von eher unnützen Werten wie z.B. Firmware Version? Welche sind wichtig?

Da für jeden wahrscheinlich andere Informationen wichtig sind, würde ich nichts wegfallen lassen.
Jeder kann dann das verwenden, was er braucht und den Rest ignorieren.

• Umrechnung der Uptime in menschentaugliche Darstellung?

Gute Idee.

• Ergänzen von Einheiten (V bei Batteriespannung etc.)

Gute Idee.

[ArnoD]

Habe mir die Werte gerade etwas genauer angesehen und festgestellt das bei tibberlink.0.LocalPulse.0.PulseInfo.node_status.radio_tx_power nichts übertragen wird.
Funktioniert das bei euch?
Hier sollte eigentlich die Sendeleistung vom Tibber Puls übertragen werden.

[ReblausGT]

@arnod said in TibberLink Adapter:

Habe mir die Werte gerade etwas genauer angesehen und festgestellt das bei tibberlink.0.LocalPulse.0.PulseInfo.node_status.radio_tx_power nichts übertragen wird.
Funktioniert das bei euch?
Hier sollte eigentlich die Sendeleistung vom Tibber Puls übertragen werden.

Wird übertragen, sonst würde der State nicht erzeugt werden.... habe ich aber auch ein "0" drin - müsste man mal auf der Web-Seite des Pulse schauen ob dort was geschrieben steht

[flisse]

@reblausgt Hat leider auch nicht geholfen.
Die Objekte habe ich gelöscht, die kamen nach kurzer Zeit auch wieder, die Meldungen kommen dann aber auch wieder.
Werte über die lokale Schnittstelle bekomme ich auch nicht rein, bis auf die aus dem Screenshot, den ich gepostet hatte.

[ArnoD]

@reblausgt sagte in TibberLink Adapter:

@arnod said in TibberLink Adapter:

Habe mir die Werte gerade etwas genauer angesehen und festgestellt das bei tibberlink.0.LocalPulse.0.PulseInfo.node_status.radio_tx_power nichts übertragen wird.
Funktioniert das bei euch?
Hier sollte eigentlich die Sendeleistung vom Tibber Puls übertragen werden.

Wird übertragen, sonst würde der State nicht erzeugt werden.... habe ich aber auch ein "0" drin - müsste man mal auf der Web-Seite des Pulse schauen ob dort was geschrieben steht

Das hat sich erledigt, es wird bereits auf der Webseite nichts eingetragen:

Das kann somit nur Tibber korrigieren. :-)

[ReblausGT]

@flisse said in TibberLink Adapter:

@reblausgt Hat leider auch nicht geholfen.
Die Objekte habe ich gelöscht, die kamen nach kurzer Zeit auch wieder, die Meldungen kommen dann aber auch wieder.
Werte über die lokale Schnittstelle bekomme ich auch nicht rein, bis auf die aus dem Screenshot, den ich gepostet hatte.

Jetzt seh ich es erst.... dein Pulse Node meldet meter_mode=4 .... alles was funktioniert war bisher mode 3.
Die gute Nachricht: du kannst die Spannung deiner Pulse Batterie sehen....
Die schlechte: bei den Verbrauchsdaten müssen wir noch Forschen.
-> Kannst Du bitte mal den Inhalt der SMLHexData posten?

[root_]

Ich bräuchte mal eure Hilfe bzw nen Denkanstoß.
Was ich machen möchte:
Ich möchte 4 Stundenblöcke anlegen, bester 5h, 6h, 7h, 8h Preis. Das ist ja noch easy. Hab ich mit LTF gemacht.
Jetzt möchte ich anzeigen ob der günstige Block heute oder morgen ist, das habe ich noch nicht verstanden wie ich das Filtern kann. Am besten wäre, günstigster Block heute: ...ct und günstigster Block morgen: ...ct.
Dann will ich noch die Differenz zwischen den 5-8h Blöcken berechnen. Das bekomme ich hin.

Hintergrund des Ganzen: ich Steuer Steuer damit meine Wallbox und die soll zur günstigsten Zeit angehen. Wenn es zb wie dieses WE ist, wo der Preis am Samstag schon günstig ist aber am Sonntag noch mal viel günstiger, möchte ich eine Routine programmieren die dann direkt auf den nächsten Tag verweist. sollte dann die Differenz des Durchschnittspreises vom 5h zum 8h Block zb nur 0.03ct betragen, dann soll direkt der 8h Block verwendet werden.

Ich hoffe ihr versteht was sich mein kleines Hirn da ausgedacht hat. ;-)

[ReblausGT]

@root_ said in TibberLink Adapter:

Ich bräuchte mal eure Hilfe bzw nen Denkanstoß.
Was ich machen möchte:
Ich möchte 4 Stundenblöcke anlegen, bester 5h, 6h, 7h, 8h Preis. Das ist ja noch easy. Hab ich mit LTF gemacht.
Jetzt möchte ich anzeigen ob der günstige Block heute oder morgen ist, das habe ich noch nicht verstanden wie ich das Filtern kann.

.... Der LTF mode ist genau dafür gedacht.... du kannst die Zeit in der der beste Block von z.B. 6h gesucht wird über 2 Tage suchen.... bzw. ~35h, da die Daten für "Morgen" ja erst um ca. 13:00 kommen. Warum due Blöcke nimmst verstehe ich allerdings noch nicht - ich würde "best single hours (LTF)" nehmen.... dort kommt die gewünscht ladezeit rein und fertig. Damit holst du dir die günstigsten Stunden an Strom in den Auto-Akku - innerhalb der gegebenen Zeit UND verfügbaren Informationen.

-> Oder ich hatte deinen Ansatz jetzt noch nicht verstanden - :hugging_face:

[Merlin123]

Die lokalen Funktionen sind cool :) Danke dafür!

Gibt es Empfehlungen, ab welcher Batteriespannung man langsam an nen Austausch denken sollte?