Erfahrung mit Tibber und Symcon?

Doctor_Snuggles · 24. Februar 2023 um 20:12

Ja prima, dann hast du ja noch Zeit bis auch dein Pulse kommt.
Sollte vom Zeitraum dann passen.
Vielleicht bekommen wir noch ein paar Leute zusammen, die Tibber und IPS nutzen das sich ggf. ein Modul lohnt, um die API auszulesen.
Habe heute auch meinen Pulse in Betrieb genommen und werde am Wochenende mal ausprobieren was man noch an Daten bekommen und gebrauchen kann.
Viele Grüße,
Doc

BoyScout · 25. Februar 2023 um 12:49

Falls sich jemand wundert warum er im Diagramm nichts sieht - die Variablen müssen nach dem Hinzufügen der Archivdaten erst noch reaggregiert werden. Da ihr das sicherlich nicht jedes mal manuell anstoßen möchtet, empfehle ich am Ende des Skriptes folgende Zeilen hinzuzufügen:

# reaggregate variable
AC_ReAggregateVariable ($ID_Archive, $ID_Variable);

@Doctor_Snuggles
Kannst ja nach Prüfung dein Script oben entsprechend anpassen.

Gruß,
Markus

Doctor_Snuggles · 25. Februar 2023 um 14:06

Hallo Markus,

das habe ich schon lange so drin, aber ganz vergessen, die Änderung hier noch zu posten.
Danke für die Erinnerung …

Ich hab’s oben im Script direkt abgeändert, macht es so übersichtlicher.

Danke u. viele Grüße,
Doc

drapple · 25. Februar 2023 um 20:49

Kann es sein das die Legende falsch ist ? bekomme immer nur 1 und 2 Tage in Vergangenheit angezeigt ?

ich tippe mal das 23.02 = heute ist und 24.02 = morgen ist ?

Doctor_Snuggles · 25. Februar 2023 um 21:28

Ja klar, die Legende mußt du am Besten ausschalten und dir die Farbe merken.
2 Tage zurück ist heute , das andere dann die Werte für morgen.
Das eine Diagramm hört ja da auf, wo das andere anfängt.
Das geht halt mit IPS aktuell nicht anders, Werte schreiben in die Zukunft ist nicht möglich.
Viele Grüße,
Doc

BoyScout · 25. Februar 2023 um 21:57

Ja - die fehlende Möglichkeit Zukunftswerte zu schreiben ist schon etwas länger ein Thema: https://community.symcon.de/t/zukuenftiger-ac-addloggedvalues-fehler/128007/5

Ich gebe aber die Hoffnung nicht auf das etwas kommt - weil sind wir mal ehrlich: vor ein paar Jahren war „Smart“ noch ein Begriff für alles was übers Handy / Web / App einfach bedient werden kann. Heut ist das normal. Heute ist Smart alles was vorausschauend regelt, handelt und sich dynamisch an ändernde Situationen anpasst. Symcon hatte dort die Stärke - und wenn sie vorn dabei bleiben wollen, kommen sie (meiner Meinung nach) nicht daran vorbei sich über Zukunftswerte Gedanken zu machen.

Mal sehen

Doctor_Snuggles · 5. März 2023 um 10:57

Ich habe das Script zur aktuellen Preisabfrage noch mal etwas erweitert, da ich jetzt den Pulse mit dran habe und sehen möchte, ob er auch mit dem Tibber-Server verbunden ist, oder ob er sich „heimlich“ abgemeldet hat.
Das scheint aber sehr lange zu dauern, das Tibber den Pulse dann als vermisst kennzeichnet. Auch in der APP kann man diese Benachrichtigung einschalten und ich habe auch nach einigen Stunden ohne Pulse die Meldung noch nicht bekommen.

Anzahl der API Abfragen ist bei Tibber übrigens auf 100 Abfragen pro 5Min. limitiert.

$Token = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx';

$json = '{"query":"{viewer {homes {features {realTimeConsumptionEnabled} currentSubscription {priceInfo {current {total level }}}}}}"}';   // mit Pulse Abfrage

# Create a connection
$ch = curl_init('https://api.tibber.com/v1-beta/gql');

# Setting our options
curl_setopt($ch, CURLOPT_URL, 'https://api.tibber.com/v1-beta/gql');
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Type: application/json','Authorization: Bearer '.$Token));
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, $json);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

# Get the response
$response = curl_exec($ch);
curl_close($ch);

$pulse = false;                                 // wenn keine Daten, dann Pulse auf false setzen

$data = json_decode($response);
$price = $data->data->viewer->homes[0]->currentSubscription->priceInfo->current->total;
$level = $data->data->viewer->homes[0]->currentSubscription->priceInfo->current->level;
$pulse = $data->data->viewer->homes[0]->features->realTimeConsumptionEnabled;

#Tibber Pulse Status
SetValueBoolean(21393, $pulse);

#Preisabfrage
$Parent = IPS_GetParent($_IPS['SELF']);
if ($price != 0) {                              // wenn mal keine Daten gelesen werden konnten
    SetValueFloat($Parent, $price * 100);       // aktueller Strompreis in Ct.
    SetValueString(23232, $level);              // aktueller PriceLevel von tibber direkt
}

//var_dump($level);      
# ========================================================================

#Preisstufe (-2 bis 2 , sehr günstig bis sehr teuer - zum weiteren rechnen und steuern)
$Preisstufe = 0;
if ($level == 'VERY_CHEAP')     {$Preisstufe = -2;}
if ($level == 'CHEAP')          {$Preisstufe = -1;}
if ($level == 'NORMAL')         {$Preisstufe = 0;}
if ($level == 'EXPENSIVE')      {$Preisstufe = 1;}
if ($level == 'VERY_EXPENSIVE') {$Preisstufe = 2;}

SetValueInteger(33009, $Preisstufe);

Noch ein Hinweis zu dem Satz hier unten bzgl. Gutscheincode, weil die Nachfrage dazu kam:
Der Promocode/Betrag wird euch gutgeschrieben, wenn Tibber die Anmeldung beim Netzbetreiber bestätigt bekommt, also nicht direkt in dem Moment, wenn ihr euch bei Tibber anmeldet.
Das dauert dann ein paar Tage, bis ihr den Gutschein für z.B. den Pulse einlösen könnt.

Falls sich jemand das gefragt hat, auch bei Tibber wird mit der staatlichen 80% Strompreisbremse über den Tagesdurschnittspreis bei 40 Cent der Strompreis gedeckelt, was bis jetzt ja noch nicht ganz klar war, da sich der Preis ja stündlich ändert.
Heißt auch hier ist man von einem hohem Strompreis geschützt. In meinen Tibber Account konnte ich jetzt sehen, welchen Vorjahresverbrauch der Netzbetreiber an Tibber gemeldet hatte.

Falls noch jemand mit dem Gedanken spielt Tibber mal auszuprobieren oder mal den Anbieter wechseln möchte oder muss, kann das gerne über diesen Link tun oder direkt mit dem Einladungscode g5suontq.
Wir bekommen dann beide je €50.- auf den Tibber Store gutgeschrieben und man kann diese Gutschrift nach der Anmeldung auch gleich wieder für den Tibber Pulse verwenden und so direkt die €50.- sparen.

Viele Grüße,
Doc

philipp · 5. März 2023 um 21:46

Hallo,

ich habe nun seit 1.3 auch den stündlichen Tibber Stromtarif.
Bisher funktioniert das Prima, auch wenn wir dank PV und Speicher ab Ende März dann für die kommenden Monate bis Ende September eher keinen Strom aus dem Netz brauchen werden.

Ich habe für mich mal mit einem Modul angefangen, welches die Preisdaten und Verbrauchsdaten je „Zuhause“ ausliest und speichert, sowie den Chart für die 2-Tages Preise anbietet.
Ich hoffe dass ich bis Ende der Woche eine erste BETA Version des Moduls bereitstellen kann

Die Live-Daten des Pulse (also zB. aktuelle Leistung) sind aber nicht über die normale API zu bekommen, dafür gibt es einen getrennten „Stream“ per WebSocket.
Wie man den Einbinden kann, bin ich momentan überfragt.

@Doc: Den realTimeConsumptionEnabled würde ich dann auch gleich mit aufnehmen.

Viele Grüße
Philipp

BoyScout · 6. März 2023 um 09:25

Philipp - Hört sich gut an das du an der Modulentwicklung dran bist… Die API scheint ziemlich mächtig zu sein, da wäre ein Modul schon top. Allerdings wäre ich vor allem tatsächlich an den Pulse-(Live)-Daten interessiert (Zumindest der aktuelle Verbrauch in Watt sowie alle ausgelesenen Zählerstände (1.8.0, 1.8.1, 1.8.2 und 2.8.0), da mein Pulse allerdings erst in schätzungsweise 3 Wochen kommen sollte kann ich da eher nicht unterstützen. Wir haben leider einen Doppeltarifzähler (HT/NT) daher sind neben 1.8.0 auch 1.8.1 (NT) und 1.8.2 (HT) von Interesse.

Allerdings würde ich empfehlen mit Doc zusammenzuarbeiten damit ihr nicht die Arbeit doppelt macht. Falls noch Unterstützung notwendig ist (Entwicklung oder Test) sagt gerne bescheid dann klinke ich mich mit ein.

Viele Grüße,
Markus

philipp · 6. März 2023 um 15:19

Hallo Markus,

wie gesagt, der Livestream via Websocket ist aus meiner Sicht (hab da aber bisher nicht viel Erfahrung) nicht so trivial wie die normale Query API, von daher wäre das bei mir erst mal nicht an Prio 1. Würde mich aber informieren ob/wie dass umsetzbar ist…
Allerdings habe ich mal kurz die Stream-Api definition angeschaut, und mit HT/NT wird das so wie ich das auf die Schnelle gehen habe nichts werden, da es nur einen Production und einen Consumption Wert gibt. Ist aus Sicht von Tibber auch logisch, da es da ja kein HT/NT sondern stündliche Tarife sind, wo eine Unterscheidung nach HT/NT keinen wirklichen Sinn macht.

Und mit Doc bin ich in Abstimmung bzgl. der Umsetzung. Falls noch Unterstützung benötigt wird gebe ich gerne bescheid.

Viele Grüße
Philipp

HHuefkenDE · 6. März 2023 um 20:32

Was passiert an den Tagen, wo die Zeitumstellung (Winter-/Sommerzeit und umgekehrt) durchgeführt wird? Jetzt im März werden vermutlich 23 Werte seitens Tibber geliefert und wir brauchen 24 fürs Archiv. Auch im Oktober sollten 25 Werte geliefert werden, wie werden diese aber auf 24h abgebildet?

Gruß

Henning

Doctor_Snuggles · 7. März 2023 um 08:01

Hallo Henning,

das ist eine gute Frage, aber vermutlich wie bei allen anderen Berechnungen über eine Zeitumstellung auch.
Aber zum schreiben ins Archiv wird der Zeitstempel (- 2Tage) genommen, den Tibber selber mitliefert.
Wenn Tibber den mit der Zeitumstellung richtig liefert, sollte es da keine Probleme geben.
Unter Umständen könnte dann mit nur 23 Werten in der Nacht zwischen 1-3h dann ggf. 2 Stunden lang der gleiche Wert stehen, müssen wir mal abwarten, was Tibber da liefert.

Für das Script mit den Stundenwerte sollte das aber ohne Bedeutung sein, es wäre ja nur bei dem Diagramm zu sehen.

Aber wenn ich da jetzt noch länger drüber nachdenke, bekomme ich einen Knoten im Hirn …

Viele Grüße,
Doc

HHuefkenDE · 7. März 2023 um 13:21

Am 25.03.23 ab 13:00Uhr sollten wir die Daten für den 26.03.23 bekommen. Für einen normalen Tagen sehen die Daten so aus:

          array(24) {
            [0]=>
            object(stdClass)#1 (4) {
              ["total"]=>
              float(0,2876)
              ["energy"]=>
              float(0,1143)
              ["tax"]=>
              float(0,1733)
              ["startsAt"]=>
              string(29) "2023-03-08T00:00:00.000+01:00"

Da es am 26.3. nur 23h gibt, sollte das Array auch nur 23 Werte liefern. Die ersten beiden (Startteit 0:00Uhr und 1:00 MEZ mit dem Versatz +01:00 bezogen auf UTC und der Rest mit +02:00 (da jetzt MESZ).

26.3. 0:00Uhr MEZ - 172.800 Sekunden => OK

Unix Timestamp	1679785200
GMT	Sat Mar 25 2023 23:00:00 GMT+0000
Your Time Zone	Sun Mar 26 2023 00:00:00 GMT+0100 (Mitteleuropäische Normalzeit)

GMT	Thu Mar 23 2023 23:00:00 GMT+0000
Your Time Zone	Fri Mar 24 2023 00:00:00 GMT+0100 (Mitteleuropäische Normalzeit)

26.3. 1:00Uhr MEZ - 172.800 Sekunden => OK

Unix Timestamp	1679788800
GMT	Sun Mar 26 2023 00:00:00 GMT+0000
Your Time Zone	Sun Mar 26 2023 01:00:00 GMT+0100 (Mitteleuropäische Normalzeit)

GMT	Fri Mar 24 2023 00:00:00 GMT+0000
Your Time Zone	Fri Mar 24 2023 01:00:00 GMT+0100 (Mitteleuropäische Normalzeit)

26.3. 3:00Uhr MESZ - 172.800 Sekunden => Error

Unix Timestamp	1679792400
GMT	Sun Mar 26 2023 01:00:00 GMT+0000
Your Time Zone	Sun Mar 26 2023 03:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)

GMT	Fri Mar 24 2023 01:00:00 GMT+0000
Your Time Zone	Fri Mar 24 2023 02:00:00 GMT+0100 (Mitteleuropäische Normalzeit)

Im Zeitraum 26.3. 3:00 bis 28.3. 3:00 sind die Werte 1h verschoben, sofern immer mit dem Wert 172.800 Sekunden gerechnet wird.

Gruß

Henning

Doctor_Snuggles · 7. März 2023 um 13:50

Ja das kann sein, die Frage ist, ob es den Aufwand Wert ist hier im Script das noch genau für die Zeitumstellung abzuändern.
Es wird parallel von einem anderen Nutzer schon an einem Modul gearbeitet, ggf. kann man das mit reinfließen lassen.
So genau hatte ich mir das mit der Zeitverschiebung bis jetzt nicht angesehen, aber du hast recht, das wird sich verschieben.
Das ist halt immer blöb mit dem Schreiben von Zukunftswerten in die Vergangenheit ins Archiv.

Viele Grüße,
Doc

bumaas · 7. März 2023 um 14:45

Das ist nicht schwer , denn PHP berücksichtigt das für dich wenn du die strtotime Funktion nutzt.

Statt

 'TimeStamp' => ($timestamp-172800),

also genauer

 'TimeStamp' => strtotime('-2 days', $timestamp),

nehmen.

Doctor_Snuggles · 7. März 2023 um 15:25

Danke dir.
Das man auch mit strtotime arbeiten kann war mir klar, aber das dann automatisch die Sommer/Winterzeitumstellung mit einfließt, war mir neu.
Man lernt halt nie aus …
Obwohl ich den Teil im PHP Manual auf die schnelle nicht gefunden hatte.

Ich habe es oben im Originalscript mal abgeändert, da war auch noch ein kleiner Fehler mit Reaggregation des Archives drin.
Mal schauen, wie es dann in 2 Wochen ausschaut.

Danke u. viele Grüße,
Doc

HHuefkenDE · 7. März 2023 um 17:41

23 Werte auf 24 abzubilden kann noch funktionieren, aber im Oktober haben wir dann 25. Das wird interessant. Sorry, das ich der Spielverderber bin.

Sobald wir diese Umschaltung zwischen Normal- und Sommerzeit abschaffen, würde der Workaround ohne Probleme funktionieren.

Gruß

Henning

HHuefkenDE · 7. März 2023 um 17:42

Das Ergebnis bei 28.3. 3:00Uhr minus 2Tage

string(19) „2023-03-28 02:00:00“
string(19) „2023-03-26 03:00:00“

Gruß

Henning
P.S.: damit getestet

<?php
    $timestamp = 1679961600; //Tue Mar 28 2023 00:00:00 GMT+0000 bzw. Tue Mar 28 2023 02:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)
    var_dump (date("Y-m-d H:i:s", $timestamp));
    var_dump (date("Y-m-d H:i:s", strtotime('-2 days', $timestamp)));
?>

drapple · 9. März 2023 um 15:41

Servus, heute kam mein Pulse IR, der funktioniert soweit.

Ich kann auch die Werte via der Tibber Api über den Tibber Developer so abfragen:

subscription{
liveMeasurement(homeId:„f1d7c039-b2cf-4775-b0a7-2f1792e89xxx“){
timestamp
power
accumulatedConsumption
accumulatedCost
currency
minPower
averagePower
maxPower}
}

Aber wir bekomme ich das per Script hin?

Doctor_Snuggles · 9. März 2023 um 16:04

Nimm doch einfach dieses Script als Vorlage.
Du brauchst doch nur deine Query dort eintragen und unten den entsprechenden Variablen zuordnen.

Grüße,
Doc