Influx 2 und Grafana Kostenberechnung | gelöst

[Wiesel 1]

Hallo Leute,

ich werte in meinem Dashboard den Stromverbrauch z.B. in Tagen aus und multipliziere die Datenpunktausgabe mit dem Strompreis (siehe letzte Codezeile). Seit einer ganzen Weile schreibe ich den Strompreis auch im ioBroker als Datenpunkt mit um diesen bei Änderung des Strompreises jederzeit anpassen zu können.

Wie müsste der Code aussehen wenn man statt * 0.3845 >> * Datenpunkt berechnen möchte.
Evtl. hat einer von Euch eine Idee...

Danke und Grüße Wiesel

import "timezone"
option location = timezone.location(name: "Europe/Berlin")

from(bucket: "Datenbank")
|> range(start: -12d)
|> filter(fn: (r) => r["_measurement"] == "Verbrauch Gesamt")
|> filter(fn: (r) => r["_field"] == "value")
|> difference ()
|> aggregateWindow(every: 24h, fn: sum, timeSrc: "_start")
|> map(fn: (r) => ({r with _cost: r._value * 0.3845}))

[A Former User]

@wiesel-1

Moin,

zu Deiner angestrebten Lösung habe ich aktuell noch keinen Vorschlag, aber evtl. geht das auch mit Variablen.

VG
Bernd

[Marc Berg]

@wiesel-1
Du könntest vor deiner jetzigen Query den aktuellen Preis abfragen und in eine Variable speichern:

preis_aktuell=from(bucket: "iobroker")
  |> range(start:-1y)
  |> filter(fn: (r) => r["_measurement"] == "<MEASUREMENTPREIS>")
  |> filter(fn: (r) => r["_field"] == "value")
  |> last()
  |> findColumn(fn: (key) => true, column: "_value")

Und diese Variable nutzen, um die Kosten zu berechnen

...
|> map(fn: (r) => ({r with _cost: r._value * preis_aktuell[0]}))

Das setzt natürlich voraus, dass du den Datenpunkt für den Preis auch in die Influxdb schreibst.

[Wiesel 1]

@dp20eic
Das mit den Variablen ist sicher eine gute Sache wenn man den gleichen Wert für verschiedene Funktionen benötigt. Ich benötige aber einen Wert mit Zeitstempel von einer Datenbank.
Der Hintergrund ist, wenn ich den Zeitraum in der Abfrage ändere über einen Preiswechsel hinaus sind alle alten € Werte falsch. Da dann der neue Preis oder die neue Variable greift. Das wird bei Monats oder Jahresauswertungen interessant.

@Marc-Berg
Ja der Preis wird vom ioBroker in die Influx DB 2 gespeichert. Im ioBroker wollte ich dann immer den Preis anpassen wenn eine Änderung kommt, so das die Preise mit entsprechenden Zeitstempeln vorliegen.
Vom ersten Verständnis deines Vorschlages her... bekomm ich das nach der 12h Schicht gerade nicht zusammen. Aber ich werde das die nächsten Tage mal testen.

Trotzdem kann es kein Hexenwerk sein 2 Datenpunkte zu multiplizieren. Gut für die € fehlt noch die Zuweisung auf den Zeitraum.

Ich danke Euch auf jeden Fall für Eure Vorschläge!

Ich verwende das Design für 12 Tage und daneben für 12 Monate usw.:

Grüße Wiesel

[A Former User]

@wiesel-1

Moin,

ja, wenn Du das jetzt so weiter ausführst, dann passt das mit Variablen nicht, unterstützen kann man nur so gut wie die Informationen sind, die man bekommt

Ich würde das dann auch anders machen und mir die aktuellen Strompreise in einen Datenpunkt schreiben und diesen in ein Bucket -> iobroker sichern, dann würde ich es so machen wie @Marc-Berg, aber das Ergebnis in ein eigenes Bucket strom_kosten schreiben und dann darauf die Abfrage in Grafana machen.

Wie oft ändert sich denn bei Dir der Preis für Strom?
Hast Du Dir schon einmal den Adapter SourceAnalytix angeschaut?

VG
Bernd

[Wiesel 1]

@dp20eic
Ja das mit dem eigenen Gehirnschmalz erklären ist nicht immer einfach .
Trotzdem Danke für den Austausch. Das mit den Variablen habe ich schon oft gelesen aber bisher noch nicht genutzt. Den empfohlenen Adapter schau ich mir mal an. Ich möchte aber auch nicht mit allen Tools arbeiten.
Dann verliert man den Überblick. Momentan ist gerade Grafana im Fokus...

Momentan ändert sich der Preis nur wenn der Energieversorger mit einer Änderung droht oder ich den Tarif wechsele. Das wird demnächst wieder passieren. Weiterhin steht das Thema variable Stromtarife im Raum. Dann wollte ich den Datenpunkte für die Influxx ggf. mit einem Tagesmittelwert berechnet über ein Blockly Script füllen und dann Auswerten.

Ich werde jetzt mal die Empfehlungen testen und Euch dann eine Rückmeldung geben

Grüße Wiesel

[Wiesel 1]

@marc-berg

import "timezone"
option location = timezone.location(name: "Europe/Berlin")

from(bucket: "wiesel")
|> range(start: -12d)
|> filter(fn: (r) => r._measurement == "Verbrauch Gesamt" or  r._measurement == "Strompreis")
|> filter(fn: (r) => r._field == "value")
|> aggregateWindow(every: 1d, fn: last, timeSrc: "_start")
|> pivot(rowKey: ["_time"], columnKey: ["_measurement"], valueColumn: "_value")
|> difference(columns: ["Verbrauch Gesamt"])
|> map(fn: (r) => ({r with _value: r.value * r.value}))

Ich habe das soweit zusammen, das die Werte Addiert werden können in eine neue Spalte.
Weißt du wie man die "|> map(fn: (r) => ({r with _value:........*........}))" ausdrücken muss, das Verbrauch Gesamt und Strompreis multipliziert werden?

1. Measurement = Verbrauch Gesamt >> Value
2. Measurement = Strompreis >> Value

Grüße Wiesel

[Wiesel 1]

@dp20eic
@Marc-Berg

Es gibt eine sehr gute Beschreibung dazu hier:
https://docs.influxdata.com/influxdb/cloud/query-data/common-queries/multiple-fields-in-calculations/

Und meinen Fehler, an dem man verzweifeln kann habe ich auch gefunden.
Der Datenpunkt der in die Influx geschrieben wird, darf keine Leerzeichen enthalten.
Damit kommt wohl die "map()" Berechnung nicht zurecht.
Ich habe viele Datenpunkte mit Leerzeichen .

Verbrauch Gesamt >> wird rot unterstrichen in der Operation
Verbrauch_Gesamt >> i.O.!

Anbei nochmal der Flux Code, falls das jemand benötigt:

import "timezone"
option location = timezone.location(name: "Europe/Berlin")

  from(bucket: "wiesel")
  |> range(start: -12d)
  |> filter(fn: (r) => r._measurement == "Verbrauch_Gesamt" or  r._measurement == "Strompreis")
  |> filter(fn: (r) => r._field == "value")
  |> aggregateWindow(every: 1d, fn: last, timeSrc: "_start")
  |> pivot(rowKey: ["_time"], columnKey: ["_measurement"], valueColumn: "_value")
  |> difference(columns: ["Verbrauch_Gesamt"])
  |> map(fn: (r) => ({ r with Kosten: r.Verbrauch_Gesamt * r.Strompreis }))

Danke und Grüße Wiesel

[A Former User]

@wiesel-1 sagte in Influx 2 und Grafana Kostenberechnung | gelöst:

Ich habe viele Datenpunkte mit Leerzeichen .

Moin,

freut mich, dass Du Deine Herausforderung gelöst bekommen hast.

Zu Deinem Problem mit den Leerzeichen, sollte man niemals nicht machen, genauso wie ä,ö,ü,ß nutzen, irgendwann hauen Dir diese Sachen vor den Latz.

Aber es gibt, glaube ich, Lösungen für dieses Problem, Du musst mal die Datensätze als CSV exportieren, dann korrigieren und wieder zurückspielen, oder Du quotest die Leerzeichen.
Schau mal InfluxDb line protokol im Abschnitt Special Characters vielleicht hilft das ja schon.

VG
Bernd

P.S.: Und ein Sternchen, dafür, dass Du bei influxDB in der Dokumentation gelesen hast

[Wiesel 1]

@dp20eic

Servus,

mit dem InfluxDb line protokol bin ich nicht weiter gekommen um das Leerzeichen zu überbrücken.

Aber die Rohdaten von der Influx DB2 exportieren hat gut geklappt.
Dann aufbereitet im Excel und gleich noch die Zählerwerte 1 Jahr zurück mit eingegeben, jeweils 1 Datenpunkt am Anfang und Ende des Monats. Dann den Datensatz wieder importiert in ein neues Measurement.

Die Datenkurve in der Influx DB2 sieht gut aus. Im Grafana passen die Werte auch, außer der März 2023.
Hier wird der Februar mit dem März zusammengerechnet. Auch in der Tabellenansicht, wie als wenn am Ende vom Februar / Anfang März kein Datenpunkt vorhanden wäre.

Gab es da nicht ein Problem mit diesem Monatsübergang, wegen Schaltjahr? Aber das war dieses Jahr nicht.

Grüße Wiesel

[A Former User]

@wiesel-1 sagte in Influx 2 und Grafana Kostenberechnung | gelöst:

Gab es da nicht ein Problem mit diesem Monatsübergang, wegen Schaltjahr? Aber das war dieses Jahr nicht.

Moin,

2023 war kein Schaltjahr, hast Du mal geschaut, vielleicht findest Du im Export etwas, ein , vergessen oder, oder.

Ohne Daten kann man da nicht helfen.

VG
Bernd

[Wiesel 1]

@dp20eic

Hallo,

ich habe mal am Monatswechsel Jan. / Feb. und Feb. / Mrz. im h Takt weitere Daten vorgegeben.
Jeweils von 20:00 - 04:00...
Weil die Daten in der Influx mit Zeitzone Zuluzeit "Z" abgelegt sind.
Das hat aber nicht wirklich geholfen. In Grafana setze ich ja dann unsere Zeitzone fest mit:

import "timezone"
option location = timezone.location(name: "Europe/Berlin")

Diese Zeitzonenanpassung habe ich jetzt in Grafana rausgenommen.
Und schon passen die Monatswerte wie in meiner Excelaufzeichnung.
Ich dachte diese Zeitzonenanpassung benötigt man, damit die Zeitumstellung richtig auswertet.
Bei einer kompletten Monatsabfrage mit Difference() wird das aber nicht gebraucht.
Denke ich zumindest ...

Jetzt passt es. Auf jeden Fall habe ich wieder viel gelernt.

Danke und Grüße Wiesel

[T-147]

@wiesel-1
Kann es sein, dass nicht nur Leerzeichen, sondern auch "." in den Datenpunkten Probleme bereiten?
Habe deine Lösung auf mein System übertragen, aber die letze Zeile versursacht immer einen Fehler, dass der "String" nicht teilbar sei.
Nehm ich die letzte Zeile raus, funktioniert die Tabelle soweit.
Ich hab in vielen Datenpunkten "." und "_" mit drin zur besseren Unterteilung. Wenn das nu das Problem ist, kann ich einiges an Datenpunkten nicht verwenden, bzw habe viel Arbeit vor mir.
Bei normalen Queries scheinen diese Sonderzeichen nicht zu stören.

Gruß
Marian

[Wiesel 1]

@t-147

Hallo Marian,

war eine Weile nicht online.
Das musste ich leider auch erst schmerzhaft lernen.
Zumindest bei der "map" Berechnung machen diese Zeichen Probleme.
Du kannst dann nur die Datenbank exportieren und wieder unter einem zulässigen Namen korrigiert importieren.
Dabei habe ich gleich noch ein paar ältere Daten mit eingepflegt.

Das steht alles weiter oben. Meine Leerzeichenvorgabe hatte iobroker sogar abgelehnt, aber ich hatte die stur wieder eingepflegt .

Mehr kann ich dir dazu nicht beantworten mit meinem Halbwissen.

Grüße Wiesel

[Thomas Braun]

@t-147 sagte in Influx 2 und Grafana Kostenberechnung | gelöst:

Ich hab in vielen Datenpunkten "." und "_" mit drin zur besseren Unterteilung.

Zumindest die Punkte sind eine Fehlerquelle. Die werden halt anderweitig bereits verwendet und sind im Namen tabu.