Tibber & Tibber Pulse

[jnewton957]

Wenn man noch keinen Tibber Account hat und die Test homeID verwendet werden die Preise in Schwedischen Kronen angezeigt
Da ich kein Tibber habe bin ich auf Eure Rückmeldungen angewiesen!

Ich kämpfe zwar immer noch mit dem ON Duplicate Key, da ich eine SQLite habe, die diesen Befehl nicht kennt...
Aber schon mal einige Rückmeldungen. Ich benutze aktuell den tibber DEMO Account.

• DANKE für deine Mühe
• Die Werte fc0_00_total bis fc0_23_total inkl. der dazugehörigen _startsAt sind korrekt.
• Die Werte fc1_00_total bis fc1_23_total inkl. der dazugehörigen _startsAt sind korrekt.
• Die Berechnungen avg, min,max sind auch korrekt

Was mir auffällt, wenn ich in den https://developer.tibber.com/explorer schaue:

• Bei realtime_subscription gibt es noch interessante Werte "abzuholen":
  
  
  Code Auswählen Erweitern
  subscription{
  liveMeasurement(homeId:"96a14971-525a-4420-aae9-e5aedaa129ff"){
    timestamp
    power
    accumulatedConsumption
    accumulatedCost
    currency
    minPower
    averagePower
    maxPower
  }
}
• auch bei den anderen queries gibt es noch Werte bei "energy", die nicht abgeholt werden. Das dürften ja die konsumierten kW zu eben dem Preis in genau der Stunde sein?

• Die 05_consumption_hourly_100 zeigt ja die letzten 4 Tage auf Stundenbasis an. Ein wenig "wie die Zeitung von gestern". Daher könnte man daraus ja Summe wie: Vortag oder eben "vor 1 Tag", "vor 2 Tagen".. machen und das jeweils aufsummieren. Sonst wird ja auch die DB mit vielen Werte voll geschrieben.

Aber auf jeden Fall ist die EVU_Tibber_connect schon mal der Hammer... DANKE

Grüße
Jörg

[/list]

[ch.eick]

Ich kämpfe zwar immer noch mit dem ON Duplicate Key, da ich eine SQLite habe, die diesen Befehl nicht kennt...
Aber schon mal einige Rückmeldungen. Ich benutze aktuell den tibber DEMO Account.

Du könntest anstelle des On Duplicate auch zwei SQL Aufrufe mit DbRep machen. Dabei müsste der erste die bestehenden Datenbankeinträge löschen und der zweite dann die neuen eintragen.

Später können wir gerne noch weitere Abfragen ins Device einbauen.

Die Verbräuche pro Stunde werden mit den consumption Abfragen erstellt.

05_consumption_hourly_100 ist zum auffüllen von versäumten Abfragen, denn ab und zu gibt es bei Tibber auch mal Timeouts

"vor 1 Tag", "vor 2 Tagen" wären Abfragen aus der Datenbank, die man genau wie die Summen Monat oder letzter Monat aus der Datenbank mit SQL abfragen könnte.

Das liveMeasurement geht nach meiner Kenntniss nicht über die normale API, sondern nur über eine WebSession,die ich als Node-Red Verbindung mal getestet habe. Das wäre bei mir dann alternatives EVU_Tibber_connect, dass ich als MQTT2 Device hier mal eingestellt habe. Momentan scheinen aber alle hier im Thread die API zu verwenden.

VG  Christian

[ch.eick]

Und schon gibt es wieder ein kleines Update

In diesem Post habe ich gerade nochmal aktualisiert.
Wenn es für fc0 kein Trigger Fenster mehr gibt, kann man jetzt auch das für fc1 im EVU_Tibber Device sehen.

Und hier mal ein Beispiel, wie ich das im DOIF im Perl Modus einbinde

Code Auswählen Erweitern

## Das wäre ein Block im DOIF, der auf den Trigger reagiert

################################################################################################################
## 18 SpeicherStromboerse
##
18_SpeicherStromboerse
{if( !([$SELF:state] eq "off")                                           ## DOIF enabled
     and
      ((
           [$SELF:SpeicherStromboerse] eq "Tibber"                       ## Soll Tibber verwendet werden?
       and [EVU_Tibber_connect:fc0_trigger]                              ## Wurde der Trigger geändert

       )
       or [$SELF:ui_command_1] eq "SpeicherStromboerse"                  ## Hier wird das uiTable select ausgewertet
      )
   ) {

    if ([EVU_Tibber_connect:fc0_trigger] eq "on") {
      set_Reading("SpeicherDcPowerAbs",[$SELF:SpeicherStromboerseDcPowerAbs]);  ## Hier wird das Speicher Laden gestartet
      fhem("setreading $SELF SpeicherTriggerLaden An");
    } else {
      fhem("setreading $SELF SpeicherTriggerLaden Aus");
      fhem("setreading $SELF SpeicherDcPowerAbs 0");                            ## Das beendet das Speicher Laden
    }

   set_Reading("ui_command_1","---");                                    ## Hier wird das uiTable select wieder zurückgesetzt, ansonsten
                                                                         ## kann das Kommando nicht sofort wiederholt werden
   }
}



## Im uiTable sieht eine zusätzliche Zeile dann bei mir wie folgt aus, was natürlich von der Anzahl der Spalten abhängt

|"Strombörse<dd>Auswahl / Ladeleistung / Trigger Status </dd>" | widget([$SELF:SpeicherStromboerse],"uzsuDropDown,Aus,Tibber") |
widget([$SELF:SpeicherStromboerseDcPowerAbs],"selectnumbers,-4500,250,0,0,lin")."W" |
[EVU_Tibber_connect:fc0_trigger] |""
Solch eine Zeile kommt dann bei jedem Device hinzu, um individuell zu aktivieren/deaktivieren, eventuell mit oder ohne Konfigurationsparameter für das Device.
Du darfst diesen Dateianhang nicht ansehen.

Viel Spaß beim Testen
  Christian

[ch.eick]

Hallo Jörg,
ich hatte Dir schon mal einen Vorschlag gemacht, wie Du das ON DUPLICATE beim SQLite umgehen könntest.
Du hast das hier ja nochmals geposted.

Hier wäre es dann mal aufgeteilt in zwei Aufrufe, also zuerst ein DELETE und anschließend nur ein Insert.
Ich habe es nicht getestet und es könnten somit auch noch Syntax Fehler drin sein

Code Auswählen Erweitern

::CommandGet(undef, "LogDBRep_".$NAME."_SQL sqlCmdBlocking
                        DELETE FROM history
                          WHERE
                            TIMESTAMP = '".$timestamp."',
                            DEVICE = "','$NAME',
                            READING = 'fc".$loop_fc."_total';" ;

::CommandGet(undef, "LogDBRep_".$NAME."_SQL sqlCmdBlocking
                        INSERT INTO history (TIMESTAMP,DEVICE,TYPE,READING,VALUE)
                          VALUES('".$timestamp."','$NAME','Tibber','fc".$loop_fc."_total','".$value."';") ;

VG   Christian

[ch.eick]

Hallo zusammen,
bisher konnte ich jetzt keine weiteren Probleme im EVU_Tibber und EVU_Tibber_connect feststellen.

Wer übrigens im EVU_Tibber die aktuellen Werte sehen möchte, der müsste das andere EVU_Tibber_connect für die Node-Red Verbindung verwenden, was eine live Web Session zu Tibber verwendet. Dort werden dann die aktuellen Werte des Tibber Pulse gesendet.
Eine weitere Möglichkeit wäre natürlich auch einen eigenen Lesekopf (dazu gibt es einen anderen Thread), oder ein SmartMeter dort im uiTable zu verlinken.
Du darfst diesen Dateianhang nicht ansehen.

Hier mal die beiden Zeilen im uiTable als Beispiel für ein SmartMeter.

Code Auswählen Erweitern

## |"Bezug vom Netz"|sprintf("%04d W",::ReadingsVal(Device(),"Pulse_P_act",0))|Format("day")|Format("month")|Format("year")
|"Bezug vom Netz"|sprintf("%04d W",([WR_0_KSEM:M_AC_Power] >= 0 ? ::round(::ReadingsVal("WR_0_KSEM","M_AC_Power",0),0) : 0) )|Format("day")|Format("month")|Format("year")

## |"Einspeisung ins Netz"|sprintf("%04d W",::ReadingsVal(Device(),"Pulse_P_act_Prod",0))|""|""|""
|"Einspeisung ins Netz"|sprintf("%04d W",([WR_0_KSEM:M_AC_Power] <= 0 ? abs(::round(::ReadingsVal("WR_0_KSEM","M_AC_Power",0),0)) :  0) )|""|""|""


VG  Christian

[ch.eick]

Hallo zusammen,
da ich das Tibber Device ja jetzt auch selber nutze, um meine Verbraucher zu netzdienlichen Zeiten zu betreiben, habe ich noch kleinere Ideen gehabt.

1. Was haltet Ihr davon die Berechnungen von fc0_* auf fc_* um zu benennen?
Das würde folgende readings betreffen

Code Auswählen Erweitern

fc0_avg
fc0_max
fc0_med
fc0_min
fc0_trigger
fc0_trigger_price
Der Hintergrung ist, dass ich die Werte nun, falls vorhanden, über fc= und fc1 berechne, was ein besseres Trigger Fenster über die vorhandenen Tibber Preise ermöglicht.
Das habe ich selber noch nicht umgesetzt und würde mich über Rückmeldungen freuen.

2. fc_avg, fc_max, fc0_min werden dann jetzt ohne Datenbank Aufrufe berechnet, da das nicht so sonderlich schwirig ist

3. Beim Trigger Preis gibt es mehrere Möglichkeiten
3.1 Über die bisherige Formel
3.2 Über die zweite Formel, die den Faktor compensation_grid berücksichtigt, der dann im gleichnamigen reading stehen muss.
    Mit dem EVU_Tibber Device kann man diesen auch mit dem "Trigger fc0 Basis 0.0" in der uiTable einstellen.
    Das könnte die Einspeisevergütunh in Cent oder ein frei justierter Wert sein, den man empirisch ermittelt.
3.3 Man könnte überlegen, wie man den Median Wert verwendet.

Hier wären dann mal die Änderungen für das userReadings (zu 1. ist noch nicht umgesetzt)

Code Auswählen Erweitern

fc0_avg:current_price.* {
## Berechnung des durchschnitt Wertes
  my $fc_avg = 0;
  my $fc = 0;

  if (ReadingsVal("$NAME","fc1_00_startsAt","null") ne "null") {       ## Der nächste Tag ist bereits da
    if (AttrVal("$NAME","verbose",0) >=3) {
      Log 3, "$NAME cmd_1  : Tibber Daten für fc1 sind bereits da";
    }
    $fc = 1;
  } # end if

    for (my $j=0;$j<=$fc;$j++){
      for (my $k=0;$k<=23;$k++) {                                          ## Summe  berechnen
        $fc_avg += ReadingsVal("$NAME",sprintf("fc%d_%02d_total",$j,$k),0);
        } # end $k
    } # end $j

    return round($fc_avg / (24 *(1+$fc)) *100 ,2);                     ## Durchschnitt berechnen
},

fc0_med:current_price.* {
## Berechnung des median Wertes
::CommandGet(undef, "LogDBRep_".$NAME."_SQL sqlCmdBlocking
           SELECT
             cast( (   (SUBSTRING_INDEX(SUBSTRING_INDEX(group_concat(VALUE order by VALUE), ',', floor(1+((count(VALUE)-1) / 2)))  , ',', -1))
                       + (SUBSTRING_INDEX(SUBSTRING_INDEX(group_concat(VALUE order by VALUE), ',', ceiling(1+((count(VALUE)-1) / 2))), ',', -1))
                     )/2 *100
             AS DECIMAL(4,2))
           FROM history
           WHERE DEVICE='".$NAME."'
             AND (   READING='fc0_total' AND TIMESTAMP >= DATE_FORMAT(NOW(), '%Y-%m-%d 00:00:00')
                     OR READING='fc1_total' AND TIMESTAMP >= DATE_FORMAT(NOW() + INTERVAL 1 DAY, '%Y-%m-%d 00:00:00') ) ;") ;
},

fc0_min:current_price.* {
##  Ermittlung des minimal Wertes
  my $fc_min = 0;
  my $fc_tmp = 0;
  my $fc = 0;

  if (ReadingsVal("$NAME","fc1_00_startsAt","null") ne "null") {       ## Der nächste Tag ist bereits da
    $fc = 1;
  } # end if

    for (my $j=0;$j<=$fc;$j++){
      for (my $k=0;$k<=23;$k++) {
        $fc_tmp = ReadingsVal("$NAME",sprintf("fc%d_%02d_total",$j,$k),0);
 
        if (($fc_tmp < $fc_min) or ($j == 0 and $k == 0)) {
          $fc_min = $fc_tmp;
        }
      } # end $k
    } # end $j

    return round($fc_min *100 ,2);                             ## Von Euro auf Cent umrechnen
},

fc0_max:current_price.* {
##  Ermittlung des minimal Wertes
  my $fc_max = 0;
  my $fc_tmp = 0;
  my $fc = 0;

  if (ReadingsVal("$NAME","fc1_00_startsAt","null") ne "null") {       ## Der nächste Tag ist bereits da
    $fc = 1;
  } # end if

    for (my $j=0;$j<=$fc;$j++){
      for (my $k=0;$k<=23;$k++) {
        $fc_tmp = ReadingsVal("$NAME",sprintf("fc%d_%02d_total",$j,$k),0);
 
        if (($fc_tmp > $fc_max) or ($j == 0 and $k == 0)) {
          $fc_max = $fc_tmp;
        }
      } # end $k
    } # end $j

    return round($fc_max *100 ,2);                             ## Von Euro auf Cent umrechnen
},


Viel Spaß und bitte ordentlich testen...
    Christian

[jnewton957]

Zu 1: Ich habe ein fc0_x und fc1_x umgesetzt und nutze das eben auch, um den morgigen Tage das Triggerfenster und die Preise zu sehen.
Habe mal ein screenshot der aktuellen Umsetzung des Dashboard gemacht. Ist noch nicht fertig und Kosten kommen ja erst ab Januar. Die 3 Thermostate wechseln dann auch noch zu den Kosten (Stromkosten, Total_cost etc). Ich kombiniere das mit einem PV Ertrag Forecast, Wetter
Interessant am heutigen Tag ist aber auch, dass es zwei gleich gute Triggerfenster gegeben hätte. Eben 0 -7 und 9-13. Das zweite Fenster geht aktuell in den Trigger-Zeitberechnungen verloren. Der fc0_trigger dürfte den ja mit ON jeweils gemerkt haben (habe ich nicht geprüft)

Zu 2. macht Sinn und reduziert DB-Abrufe.

Zu 3.1/3.2 Ich habe den compensation_grid auf null gelassen. Alleine die Netzentgelte liegen ja bei ca. 16 ct/kWh (steigend) und somit wohl bei den meisten über compensation_grid. Ich möchte ja die Steuerung eigentlich unabhängig vom compensation_grid machen. Also wenn Bedarf ist, um z.B. das Auto zu laden oder Batterie zu laden. Dann möchte ich ja "unabhängig" vom compensation_grid den jeweils günstigsten Zeitpunkt heute oder morgen nutzen.


Zu 3.3: Erkenne den Mehrwert nicht.

[ch.eick]

Zu 3.3 das Trigger Fenster könnte anders ausfallen.

Die zwei Fenster wurden nacheinander im Trigger bedient, was man sehen kann, wenn man den Trigger on/off im Diagramm darstellt.

Compensation_grid wäre für das Sinnvolle Laden des Speichers verwendbar. Bei zu hohen Preisen bei Tibber macht das Speicherladen keinen Sinn. Laden von BEV natürlich schon.

[tomhead]

Erst mal Danke an Christian für das Tibber Device, ich hätte aber noch mal ne Frage dazu: wie kann ich ohne MQTT / Node-Red die täglichen / monatlichen Verbrauchskosten für mich ermitteln? Gibt es da auch über die HTTPMOD Abfrage eine Möglichkeit?
Alternative: Ich lese meinen Stromzähler über Modbus und OBIS aus und erzeuge mir mit dem statistics Modul damit u.a. stündliche Verbrauchswerte. Jetzt kann ich die ja am Ende jeder Stunde mit dem jeweils gültigen Strompreis multiplizieren und habe dann damit die Verbrauchskosten für die jeweils abgelaufene Stunde. Aber wie summiere ich das dann am geschicktesten zu täglichen bzw. monatlichen Werten auf? Das statistics-Modul kann ja glaube ich keine Summenbildung. Werde es mal mit monotonic probieren und das dann in einem eigenen Reading aufsummieren, was dann wieder über statistics ausgewertet wird. Etwas kompliziert, aber vielleicht gibt es ja eine einfachere Möglichkeit.
Danke und Grüße,
Tom

[Torxgewinde]

Hallo,
Bezüglich der Websocket habe ich heute mal angefangen, die Verbindung wird auch wohl aufgebaut - aber praktisch auch sofort wieder geschlossen. Vielleicht sieht jemand ja den Fehler, denn dann könnten wir direkt auf FHEM heraus die "liveMeasurements" auslesen. Die Attribute "homeId" und "token" muss man aus der API-Seite auslesen: https://developer.tibber.com/explorer

Ganz generell funktioniert eine Websocket wohl so aus einem Dummy heraus, das nutze ich seit mehreren Wochen für OwnTone (vormal ForkedDaapd): https://forum.fhem.de/index.php?topic=135838.0

Code Auswählen Erweitern

defmod Tibber.ws dummy
attr Tibber.ws userattr websocketURL homeId token
attr Tibber.ws alias Tibber Websocket
attr Tibber.ws eventMap /wert connect:start/wert disconnect:stop/
attr Tibber.ws group Strom
attr Tibber.ws homeId 1234567-1234-1234-1234-1234567890
attr Tibber.ws icon hue_filled_plug
attr Tibber.ws readingList wert
attr Tibber.ws setList wert
attr Tibber.ws token BLABLABLA
attr Tibber.ws userReadings connect:wert:.connect {\
    my $hash = $defs{$name};;\
    my $devState = DevIo_IsOpen($hash);;\
    return "Device already open" if (defined($devState));;\
    \
    $hash->{DeviceName} = AttrVal($name, "websocketURL", "wss:echo.websocket.org:443");;\
    #is set implicitly by wss: $hash->{SSL} = 1;;\
    $hash->{TIMEOUT} = 10;;\
    \
    # special headers needed for Tibber, see also Developer Tools in Browser\
    $hash->{header}{'Sec-WebSocket-Protocol'} = 'graphql-transport-ws';;\
    $hash->{header}{'Host'} = 'websocket-api.tibber.com';;\
    $hash->{header}{'Origin'} = 'websocket-api.tibber.com';;\
    \
    # callback function when "select" signals data for us\
    # websocket Ping/Pongs are treated in DevIo but still call this function\
    $hash->{directReadFn} = sub () {\
        my $hash = $defs{$name};;\
        readingsBeginUpdate($hash);;\
        \
        # we can read without closing the DevIo, because select signalled data\
        my $buf = DevIo_SimpleRead($hash);;\
        \
        if(!defined($buf)) {\
            #DevIo_CloseDev($hash);;\
            $buf = "not connected";;\
        }\
        \
        # only update our reading if buffer is not empty\
        readingsBulkUpdate($hash, "websocketData", "$buf") if ($buf ne "");;\
        readingsEndUpdate($hash, 1);;\
    };;\
    \
    # open DevIo websocket\
    DevIo_OpenDev($hash, 0, undef, sub(){\
        my ($hash, $error) = @_;;\
        return "$error" if ($error);;\
        \
        #immediately send what we would like to be notified for\
        my $homeId = AttrVal($name, "homeId", "???");;\
        DevIo_SimpleWrite($hash, 'subscription{ liveMeasurement(homeId:"'.$homeId.'"){ timestamp power accumulatedConsumption accumulatedCost currency minPower averagePower maxPower }}', 2);;\
    });;\
        \
    return POSIX::strftime("%H:%M:%S",localtime(time()));;\
},\
disconnect:wert:.disconnect {\
    my $hash = $defs{$name};;\
    RemoveInternalTimer($hash);;\
    DevIo_SimpleRead($hash);;\
    DevIo_CloseDev($hash);;\
    \
    return POSIX::strftime("%H:%M:%S",localtime(time()));;\
},\
onDisconnect {\
    my $myState = ReadingsVal($name, "state", "???");;\
    return if ($myState ne "disconnected");;\
    \
    ## timer callback function, called after a few seconds to initiate a reconnect\
    #my $timerFunction = sub() {\
    #    my ($hash) = @_;;\
    #    my $devState = DevIo_IsOpen($hash);;\
    #    readingsSingleUpdate($hash, "wert", "connect", 1) if (!defined($devState));;\
    #};;\
    #my $hash = $defs{$name};;\
    #RemoveInternalTimer($hash, $timerFunction);;\
    #InternalTimer(gettimeofday() + 60, $timerFunction, $hash);;\
    \
    return POSIX::strftime("%H:%M:%S",localtime(time()));;\
}
attr Tibber.ws websocketURL wss:websocket-api.tibber.com:443/v1-beta/gql/subscriptions

[ch.eick]

Moin,
Die Werte für heute/Monat/Jahr werden doch bereits im Device gebildet und im EVU_Tibber auch angezeigt.

VG Christian

[ch.eick]

Moin,
Die Werte für heute/Monat/Jahr werden doch bereits im Device gebildet und im EVU_Tibber auch angezeigt.

VG Christian

[tomhead]

Moin,
Die Werte für heute/Monat/Jahr werden doch bereits im Device gebildet und im EVU_Tibber auch angezeigt.

VG Christian

OK, Danke. Dann werden die entsprechenden userreadings bei mir vermutlich noch nicht angezeigt, weil mein Vertrag erst am 5.1. startet.

VG, Tom

[ch.eick]

Dann werden die entsprechenden userreadings bei mir vermutlich noch nicht angezeigt, weil mein Vertrag erst am 5.1. startet.

Hallo Tom,
hier mal ein Beispiel, der aus der Datenbank ermittelten Werte, was im userReadings geschieht.

Code Auswählen Erweitern

nodes_consumption_day 9.3770
nodes_consumption_month 22.4870
nodes_consumption_year 22.4870
nodes_cost_avg 11.39
nodes_cost_max 33.63
nodes_cost_min 0.54
total_cost_day 2.19
total_cost_month 4.70
total_cost_year 4.70
VG  Christian

[ch.eick]

Moin,
falls übrigens jemand das EVU_Tibber_connect in der Node-Red Variante verwendet, dann könnte man dort auch die Änderungen im userReading übernehmen.

VG  Christian