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

[paul53]

@paul53 sagte: SA kann am besten mit einem kumulativen Gesamtkostenwert umgehen.

Da SA keine dynamischen Preise unterstützt, muss man die kumulativen Gesamtkosten per Skript ermitteln und an SA übergeben, wobei man eine zusätzliche Preisdefinition verwenden sollte:

Ich habe die Unit "l" gewählt, da man "Euro" nicht auswählen kann.

[Peter666666]

@paul53 d.h. ich nehme dann den DP "Kosten gesamt" für SA und sehe dann einen Tag später was ich an Energiekosten gebraucht habe oder verstehe ich das wieder falsch?
Verstehe nur nicht warum es bei einem anderen DP wo ich den Netzbezug mit SA aufzeichne perfekt funktioniert...

[paul53]

@peter666666 sagte: DP wo ich den Netzbezug mit SA aufzeichne perfekt funktioniert...

Die Ermittlung der Periodenwerte für den Verbrauch in kWh ist kein Problem.
Das Problem sind die dynamischen Preise. In SA kann man nur einen konstanten Preis/Einheit zur Berechnung der Kosten angeben.

[Peter666666]

@paul53 dieses Skript auch jede Stunde laufen lassen oder?

[paul53]

@peter666666 sagte: dieses Skript auch jede Stunde laufen lassen oder?

Dieses Skript läuft ständig und triggert bei jeder Zählerstanderhöhung.

[Peter666666]

@paul53 achso das ist dann statt dem alten welches ich bis jetzt verwendet habe

[paul53]

@peter666666 sagte: das ist dann statt dem alten welches ich bis jetzt verwendet habe

Ja, es ermittelt fortlaufend den Gesamtkostenstand (in Euro). Die Periodenwerte berechnet daraus SA mit der Unit l. Da der Faktor für die Kosten 1 €/l ist, zeigt SA die Periodenkosten auch in € an.

[Peter666666]

@paul53 Super viele Dank! Werde ich gleich testen!

[Peter666666]

@paul53 funktioniert soweit. Ich muss bei mir nur 0.1 je Einheit einstellen weil sonst stimmt der Preis dann nicht. Denke das ist weil ich den Stundenpreis anders bekomme als du. Muss ich mir nochmal anschauen.

[paul53]

@peter666666 sagte: weil ich den Stundenpreis anders bekomme

Ich würde immer Euro/kWh verwenden. Wenn es der Original-DP nicht liefert, dann rechne es in einem Alias mit Lesekonvertierung um und verwenden den Alias im Skript. Der Zählerstand liegt schließlich auch in kWh vor?

EDIT: Wenn der Preis in ct/kWh vorliegt, dann berechne die Gesamtkosten in Euro so:

[Peter666666]

@paul53 habe die Preise von dem apg-info Adapter. Werde das Skript umschreiben da ich den Preis in ct/KWh bekomme. Der zähler gibt kWh aus.

[Peter666666]

@paul53 jetzt laufen die Kosten im Sekundentakt in die höhe. Irgendwo habe ich einen Fehler drinnen...

[paul53]

@peter666666 sagte: jetzt laufen die Kosten im Sekundentakt in die höhe.

... nur, wenn sich auch der Zählerstand im Sekundentakt erhöht.
Du hast beim Schreiben die Gesamtkosten gerundet (auf ganze Zahl) und anschließend durch 100 dividiert?

[Peter666666]

@paul53 ja aber 11 eur in einer Stunde kann nicht sein...

StormPreisStundeOhneRunden ist in Ct/kWh

EDIT:

DP Stromzähler (180):

[Peter666666]

@paul53 ja hab ich.

[paul53]

@peter666666 sagte: ja hab ich.

So muss richtig gerechnet werden, wenn der DP "180" den Zählerstand in kWh liefert und der Preis in Ct/kWh ist. Wie hoch ist der Preis aktuell?

[Peter666666]

@paul53 Preis inkl. 20% Mwst und inkl. 1.44ct Gebühr je kWh

Beim Zähler steht als Einheit kWh

EDIT: Anzeige in der VIS:

[paul53]

@peter666666 sagte: Beim Zähler steht als Einheit kWh

... was nicht bedeuten muss, dass er auch tatsächlich kWh zählt. Stimmt der Wert mit der Anzeige auf dem Zähler überein?
Logge mal den Wert und setze "Kosten_gesamt" auf 0 zurück. Der Wert ist zu hoch, da das Skript erst kurze Zeit läuft, allerdings zu Beginn ohne die Division durch 100.

[Peter666666]

@paul53 Wert am Zähler ist ein anderer da der Zähler mal getauscht wurde. Logge jetzt den Wert mit und deaktiviere die Division durch 100 im Skript. Kosten setze ich auf 0

[paul53]

@peter666666 sagte: deaktiviere die Division durch 100 im Skript.

Auf keinen Fall! Bei Preis in Ct/kWh wird die Division durch 100 benötigt.
Das Weglassen zu Anfang war falsch und erzeugte zu hohe Kosten.