HTTPMOD: Stündlich Strompreis bei Tibber auslesen

Damian · 15 April 2023, 20:51:50

Das Beispiel aus dem ersten Post liest den aktuellen Strompreis der Stunde aus. Kann man über die HTTPMOD-Schnittstelle auch den voraussichtlichen Strompreis der Stunde von morgen auslesen?

Reinhard.M · 16 April 2023, 11:23:56

Ja, gewöhnlich werden um ca. 13:00 Uhr die Stundenpreise des Folgetages veröffentlicht. Wenn man die Werte um 13:300 abruft dürften sie sicher da sein. Werde ich auch noch aufsetzen, bin aber noch nicht dazu gekommen.

Damian · 16 April 2023, 13:37:37

Ich habe etwas rumexperimentiert. Man kann jetzt eine tägliche Prognose in die Zukunft bis zum Ende des Tages darstellen (neue DOIF-Version wurde eingecheckt).

Dazu habe ich diese Definition genommen: https://forum.fhem.de/index.php?topic=130407.msg1264625#msg1264625

Und in einem DOIF um Mitternacht die prognostizierten Werte (total) des Tages ausgelesen und ins Diagramm geschoben:

Code Auswählen

defmod di_collect DOIF { [00:01];;\
my $out;;\
for (my $i=0;;$i<=23;;$i++){\
  $out.=ReadingsVal("EVU_Tibber",sprintf("fc0_%02d_startsAt",$i),"")." ".ReadingsVal("EVU_Tibber",sprintf("fc0_%02d_total",$i),"")."\n";;\
}\
::DOIF_modify_card_data ("di_collect","EVU_Tibber","total","bar1day",0,$out);;\
}
attr di_collect event_Readings total:[EVU_Tibber:total:bar1day]

und mit

Code Auswählen

devStateIcon {ui_Table::card(ReadingsVal("di_collect","total",""),undef,undef,0,2,90,0,"SEK",undef,"3",",fixedscaling,,,,")}

in Device EVU_Tibber visualisiert - siehe Anhang.

xerion · 16 April 2023, 21:01:49

Hallo Damian,

ich bekomme beim ausführen des Blocks folgenden Fehler.
FHEM Update ist aktuelle von heute (16.04.23)

Code Auswählen

block_01
	

condition c01: Can't use string ("") as a HASH ref while "strict refs" in use at ./FHEM/98_DOIF.pm line 1489.

Damian · 16 April 2023, 21:59:56

Zitat von: xerion am 16 April 2023, 21:01:49Hallo Damian,

ich bekomme beim ausführen des Blocks folgenden Fehler.
FHEM Update ist aktuelle von heute (16.04.23)

Code Auswählen Erweitern
block_01 condition c01: Can't use string ("") as a HASH ref while "strict refs" in use at ./FHEM/98_DOIF.pm line 1489.

Vermutlich, weil das Reading total in EVU_Tibber nicht existiert. Setz einfach setreading EVU_Tibber total 0 und schaue, ob im di_collect unter total ein Hash angezeigt wird.

ch.eick · 17 April 2023, 07:57:21

Moin,
ich bekomme auch den HASH Fehler. <<< Updates sind weiter unten im Post

Beide readings sind vorhanden.

Code Auswählen

fc0_00_startsAt 2023-04-17 00:00:00
fc0_00_total 0.2873
fc0_01_startsAt 2023-04-17 01:00:00
fc0_01_total 0.283

Code Auswählen

{ [00:01];
my $out;
for (my $i=0;$i<=23;$i++){
  $out.=ReadingsVal("EVU_Tibber",sprintf("fc0_%02d_startsAt",$i),"")." ".ReadingsVal("EVU_Tibber",sprintf("fc0_%02d_total",$i),"")."\n";
  print($out."\n");    <<< das habe ich mal eingefügt
}
::DOIF_modify_card_data ("EVU_Tibber_ctl","EVU_Tibber","total","bar1day",0,$out);
}

Im Log baut sich dann das $out langsam auf:
2023-04-17 00:00:00 0.2873

2023-04-17 00:00:00 0.2873
2023-04-17 01:00:00 0.283

2023-04-17 00:00:00 0.2873
2023-04-17 01:00:00 0.283
2023-04-17 02:00:00 0.2804

bis dann alle Einträge für das Diagramm da sind.

UPDATE 20230417 08:45
Nach dem "setreading EVU_Tibber total 0" kommt dann

Code Auswählen

condition c01: Argument "23:00:00" isn't numeric in addition (+) at ./FHEM/98_DOIF.pm line 1723.
UPDATE 20230417 09:33
Das Problem lag an TIMESTAMP, der wegen MySQL ohne "_" gespeichert wurde.
Es muss für das Diagramm "2023-04-17_09:00:00" geschrieben werden.

Code Auswählen

{ [00:01];
my $out;
my $timestamp;

for (my $i=0;$i<=23;$i++){
  $timestamp = ReadingsVal("EVU_Tibber",sprintf("fc0_%02d_startsAt",$i),"");
  $timestamp =~ s/ /_/g;
  $out.=$timestamp." ".ReadingsVal("EVU_Tibber",sprintf("fc0_%02d_total",$i),"")."\n";
}
::DOIF_modify_card_data("EVU_Tibber_ctl","EVU_Tibber","total","bar1day",0,$out);
}

Für meine Anwendung habe ich das DevstateIcon ins DOIF geschrieben. Dort kommen dann auch noch andere Schedulings und Steuerungen für das EVU_Tibber mit rein. Fortsetzung folgt...

Nun bleiben für mich noch zwei Fragen:

1. Kann ich das DevStateIcon mit meiner uiTable Status Tabelle kombinieren?
2. Bei mir bekomme ich das Diagramm nur bis zur aktuell laufenden Stunde angezeigt, kann ich den ganzen tag im voraus darstellen lassen?

VG Christian

Damian · 17 April 2023, 11:09:05

Da EVU_Tibber sich nicht alleine aktualisiert, könnte man noch im Block nach der Zeitangabe get EVU_Tibber 02_priceAll aufrufen, damit die Preise aktuell sind.

Auch das fehlende Reading könnte man mit setreading EVU_Tibber total 0 im Block erzeugen.

Ich habe ja zwei verschiedene Tibber-Darstellunge hier im Forum dargestellt, die erste bezieht sich auf den aktuellen Strompreis, dort werden die Balken bis zum aktuellen Zeitpunkt dargestellt aufgrund der Events vom Strompreis, der stündlich aktualisiert wurde.

Die Prognose baut dagegen auf deiner ursprünglichen Definition zum Auslesen der Prognosedaten auf, hier gibt es keine Events, deswegen das einmalige Auslesen der Definition um Mitternacht für den ganzen Tag.

Bei mir hat bisher alles funktioniert. Mit bar2day hat man auch den Vergleich zum Vortag.

Was bisher noch nicht geht, ist die Prognose von morgen, dazu müsste ich noch das DOIF anpassen, um weiter in die Zukunft zu schauen.

Im Anhang die Daten von gestern und von heute.

ch.eick · 17 April 2023, 11:59:28

Zitat von: Damian am 17 April 2023, 11:09:05Da EVU_Tibber sich nicht alleine aktualisiert, könnte man noch im Block nach der Zeitangabe get EVU_Tibber 02_priceAll aufrufen, damit die Preise aktuell sind.

Auch das fehlende Reading könnte man mit setreading EVU_Tibber total 0 im Block erzeugen.

Ich habe ja zwei verschiedene Tibber-Darstellunge hier im Forum dargestellt, die erste bezieht sich auf den aktuellen Strompreis, dort werden die Balken bis zum aktuellen Zeitpunkt dargestellt aufgrund der Events vom Strompreis, der stündlich aktualisiert wurde.

Die Prognose baut dagegen auf deiner ursprünglichen Definition zum Auslesen der Prognosedaten auf, hier gibt es keine Events, deswegen das einmalige Auslesen der Definition um Mitternacht für den ganzen Tag.

Bei mir hat bisher alles funktioniert. Mit bar2day hat man auch den Vergleich zum Vortag.

Was bisher noch nicht geht, ist die Prognose von morgen, dazu müsste ich noch das DOIF anpassen, um weiter in die Zukunft zu schauen.

Im Anhang die Daten von gestern und von heute.

Ich werde auch das DOIF für die Visualisierung direkt verwenden und auch das Scheduling dort machen.
Das EVU_Tibber dient dann nur noch dem Datensammeln.

Momentan verzweifle ich leider an dem Diagramm und verstehe auch nicht das reading total 0. Wofür wird das verwendet oder ist das der HASH mit der Liste?

Die Prognose von morgen würde ich einfach als zweites Diagramm haben wollen. Da würde ich dann in einer zweiten For Schleife durch fc[0|1] laufen. Da ich aber noch nicht verstanden habe, wie die daten ins card kommen und was dort das reading mit den Daten ist, klappt das noch nicht.

Über/unter den Diagrammen möchte ich dann mein stateFormat als uiTable haben.
Da sollen dann die Diagramme auch größer sein, was ich auch noch nicht im Wiki bei den Beispielen gefunden habe.

Es ist noch viel zu lernen

ch.eick · 17 April 2023, 12:17:40

Hier mal ein erster Entwurf für mein EVU_Tibber_Status Device mit DOIF

Die stateFormat Tabelle transferiere ich noch ins uiTable.
Dort möchte ich dann das Diagramm einbinden.

Das EVU_Tibber Scheduling ist bereits ein eigener Block.

Damian · 17 April 2023, 13:35:03

Du kannst statt dem Attribut uiTable das DOIF-Attribut uiState nehmen, wenn du die Tabelle im Status statt darunter im DOIF-Device haben willst. Die Syntax ist identisch.

Zum Thema Reading total:

Der Card-Aufruf erfolgt normalerweise innerhalb der uiTable mit der Triggerangabe des Readings [<device>:<reading>:<collect-Angaben>]. Damit weiß das DOIF-Device welches Reading in welchem Diagramm dargestellt werden soll und sammelt bei jedem Event des Reading intern die darzustellenden Daten und visualisiert diese.

Bei zukünftigen Daten zu einem Reading gibt es keine Events zum Sammeln. Daher habe ich die card_data-Funktion "missbraucht" (mit einer DOIF-Anpassung) Daten der Zukunft ins Diagramm zu laden.

Das DOIF braucht aber immer ein Reading, weil es eigentlich selbstständig Daten des Readings für die Darstellung sammeln will.

Man könnte auch das Reading Strompreis statt total nehmen, dann würde man um Mitternacht die Daten zum Strompreis laden statt zu total. Im Laufe des Tages würden sie falls es Events zum Reading Strompreis gibt (HTTMPOD mit Intervall, wie im Beispiel von Reinhard im ersten Post) überschrieben werden. Wenn die Prognose des Tages und die tatsächlichen Daten übereinstimmen, dann merkt man keinen Unterschied - nur das Reading "Strompreis" wäre auf jeden Fall da.

ch.eick · 17 April 2023, 15:33:16

Momentan sieht es dann jetzt schon mal so aus...

In dem Pull Down kann man auf den FHEMWEB einzelne Blöcke direkt manuell ausführen.

Damian · 17 April 2023, 17:24:59

So sieht bei mir eine reine DOIF-Definition mit uiTable aus, angesetzt auf das Device EVU_Tibber:

Code Auswählen

defmod di_tibber DOIF { [00:01];;\
my $out;;\
fhem("get EVU_Tibber 02_priceAll");;\
for (my $i=0;;$i<=23;;$i++){\
  $out.=ReadingsVal("EVU_Tibber",sprintf("fc0_%02d_startsAt",$i),"")." ".(ReadingsVal("EVU_Tibber",sprintf("fc0_%02d_total",$i),"")*100*0.088)."\n";;\
}\
::DOIF_modify_card_data ("$SELF","EVU_Tibber","Strompreis","bar2day",0,$out);;\
}\
{[:01];\
fhem("get EVU_Tibber 01_priceInfo");\
}
attr di_tibber uiTable {package ui_Table;;}\
card([EVU_Tibber:Strompreis:bar2day],undef,"",0,40,90,0,"Cent",undef,"1",",fixedscaling,,,,halfring")

Ich habe den total-Preis auf Cent umgerechnet. Allerdings fand ich eine stündliche Aktualisierung des Strompreises per Intervall im HTTPMOD, wie bei Reinhard, besser. In deiner Definition von EVU_Tipper muss man es wohl, wie ich es sehe, extern per get anstoßen.

Damian · 04 Mai 2023, 20:10:24

Kostenberechnung + Visualisierung mit Echtdaten siehe: https://forum.fhem.de/index.php?topic=130407.msg1274835#msg1274835