Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Wiesel 1]

@dp20eic
Ja das mit dem eigenen Gehirnschmalz erklären ist nicht immer einfach :face_with_cowboy_hat: .
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 :+1:

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 :disappointed_relieved: .

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

[Ein ehemaliger Benutzer]

@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

[Ein ehemaliger Benutzer]

@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 :face_with_cowboy_hat: ...

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 :blush: .

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.