Skip to content
  • Home
  • Aktuell
  • Tags
  • 0 Ungelesen 0
  • Kategorien
  • Unreplied
  • Beliebt
  • GitHub
  • Docu
  • Hilfe
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Standard: (Kein Skin)
  • Kein Skin
Einklappen
ioBroker Logo

Community Forum

donate donate
  1. ioBroker Community Home
  2. Deutsch
  3. Off Topic
  4. Influx 2 und Grafana Kostenberechnung | gelöst

NEWS

  • Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄
    BluefoxB
    Bluefox
    11
    1
    492

  • Weihnachtsangebot 2025! 🎄
    BluefoxB
    Bluefox
    24
    1
    1.7k

  • UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?
    apollon77A
    apollon77
    48
    3
    9.6k

Influx 2 und Grafana Kostenberechnung | gelöst

Geplant Angeheftet Gesperrt Verschoben Off Topic
15 Beiträge 5 Kommentatoren 2.8k Aufrufe 6 Watching
  • Älteste zuerst
  • Neuste zuerst
  • Meiste Stimmen
Antworten
  • In einem neuen Thema antworten
Anmelden zum Antworten
Dieses Thema wurde gelöscht. Nur Nutzer mit entsprechenden Rechten können es sehen.
  • W 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.:
    Strombezug.PNG

    Grüße Wiesel

    ? Offline
    ? Offline
    Ein ehemaliger Benutzer
    schrieb am zuletzt editiert von
    #5

    @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

    W 1 Antwort Letzte Antwort
    0
    • ? Ein ehemaliger Benutzer

      @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

      W Offline
      W Offline
      Wiesel 1
      schrieb am zuletzt editiert von
      #6

      @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

      1 Antwort Letzte Antwort
      0
      • Marc BergM 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.

        W Offline
        W Offline
        Wiesel 1
        schrieb am zuletzt editiert von Wiesel 1
        #7

        @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

        InfluxxDB2.PNG

        Grüße Wiesel

        W 1 Antwort Letzte Antwort
        0
        • W 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

          InfluxxDB2.PNG

          Grüße Wiesel

          W Offline
          W Offline
          Wiesel 1
          schrieb am zuletzt editiert von Wiesel 1
          #8

          @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

          T 1 Antwort Letzte Antwort
          0
          • ? Offline
            ? Offline
            Ein ehemaliger Benutzer
            schrieb am zuletzt editiert von
            #9

            @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 :)

            W 1 Antwort Letzte Antwort
            0
            • ? 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 :)

              W Offline
              W Offline
              Wiesel 1
              schrieb am zuletzt editiert von Wiesel 1
              #10

              @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

              ? 1 Antwort Letzte Antwort
              0
              • W 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

                ? Offline
                ? Offline
                Ein ehemaliger Benutzer
                schrieb am zuletzt editiert von
                #11

                @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

                W 1 Antwort Letzte Antwort
                0
                • ? 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

                  W Offline
                  W Offline
                  Wiesel 1
                  schrieb am zuletzt editiert von Wiesel 1
                  #12

                  @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

                  1 Antwort Letzte Antwort
                  0
                  • W 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

                    T Offline
                    T Offline
                    T-147
                    schrieb am zuletzt editiert von
                    #13

                    @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

                    W Thomas BraunT 2 Antworten Letzte Antwort
                    0
                    • T 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

                      W Offline
                      W Offline
                      Wiesel 1
                      schrieb am zuletzt editiert von
                      #14

                      @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

                      1 Antwort Letzte Antwort
                      0
                      • T 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

                        Thomas BraunT Online
                        Thomas BraunT Online
                        Thomas Braun
                        Most Active
                        schrieb am zuletzt editiert von
                        #15

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

                        Linux-Werkzeugkasten:
                        https://forum.iobroker.net/topic/42952/der-kleine-iobroker-linux-werkzeugkasten
                        NodeJS Fixer Skript:
                        https://forum.iobroker.net/topic/68035/iob-node-fix-skript
                        iob_diag: curl -sLf -o diag.sh https://iobroker.net/diag.sh && bash diag.sh

                        1 Antwort Letzte Antwort
                        0
                        Antworten
                        • In einem neuen Thema antworten
                        Anmelden zum Antworten
                        • Älteste zuerst
                        • Neuste zuerst
                        • Meiste Stimmen


                        Support us

                        ioBroker
                        Community Adapters
                        Donate

                        472

                        Online

                        32.5k

                        Benutzer

                        81.8k

                        Themen

                        1.3m

                        Beiträge
                        Community
                        Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen | Einwilligungseinstellungen
                        ioBroker Community 2014-2025
                        logo
                        • Anmelden

                        • Du hast noch kein Konto? Registrieren

                        • Anmelden oder registrieren, um zu suchen
                        • Erster Beitrag
                          Letzter Beitrag
                        0
                        • Home
                        • Aktuell
                        • Tags
                        • Ungelesen 0
                        • Kategorien
                        • Unreplied
                        • Beliebt
                        • GitHub
                        • Docu
                        • Hilfe