Skip to content
  • Home
  • Recent
  • Tags
  • 0 Unread 0
  • Categories
  • Unreplied
  • Popular
  • 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

  • Default (No Skin)
  • No Skin
Collapse
ioBroker Logo

Community Forum

donate donate
  1. ioBroker Community Home
  2. Deutsch
  3. Off Topic
  4. Grafana - Range mit flexiblem Datum, aber immer 00:00

NEWS

  • Monatsrückblick Januar/Februar 2026 ist online!
    BluefoxB
    Bluefox
    16
    1
    259

  • Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨
    BluefoxB
    Bluefox
    17
    1
    4.6k

  • Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄
    BluefoxB
    Bluefox
    13
    1
    1.3k

Grafana - Range mit flexiblem Datum, aber immer 00:00

Scheduled Pinned Locked Moved Off Topic
9 Posts 3 Posters 2.2k Views 3 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • C Offline
    C Offline
    CoComp
    wrote on last edited by CoComp
    #1

    Moin, ich habe eine Flux-Query in Grafana, in der ich meinen Netzbezug der letzten 7 Tage anzeigen lassen . Aktuell startet/endet die Darstellung immer mit der aktuellen Uhrzeit, was am Starttag zu einem Teilwert in der Darstellung führt.
    ad2b51ff-c795-4e2a-b362-96f21bb63885-image.png

    Wie kann ich die Range in meinem Code entsprechend anpassen? Also Beginn am variablen Starttag um 00:00 und am Ende am Endtag um 23:59 enden.

    from(bucket: "nodered")
      |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
      |> filter(fn: (r) => r["_measurement"] == "KG.hz.SZ_A_Plus15")
      |> filter(fn: (r) => r["_field"] == "value")
      |> difference()
      |> aggregateWindow(every: 1d, offset:-121m, fn: sum, createEmpty: false)
    

    Das ist bestimmt simpel, aber ich könnte da gut einen Tipp brauchen.

    S 1 Reply Last reply
    0
    • C CoComp

      Moin, ich habe eine Flux-Query in Grafana, in der ich meinen Netzbezug der letzten 7 Tage anzeigen lassen . Aktuell startet/endet die Darstellung immer mit der aktuellen Uhrzeit, was am Starttag zu einem Teilwert in der Darstellung führt.
      ad2b51ff-c795-4e2a-b362-96f21bb63885-image.png

      Wie kann ich die Range in meinem Code entsprechend anpassen? Also Beginn am variablen Starttag um 00:00 und am Ende am Endtag um 23:59 enden.

      from(bucket: "nodered")
        |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
        |> filter(fn: (r) => r["_measurement"] == "KG.hz.SZ_A_Plus15")
        |> filter(fn: (r) => r["_field"] == "value")
        |> difference()
        |> aggregateWindow(every: 1d, offset:-121m, fn: sum, createEmpty: false)
      

      Das ist bestimmt simpel, aber ich könnte da gut einen Tipp brauchen.

      S Offline
      S Offline
      SpacerX
      wrote on last edited by SpacerX
      #2

      @cocomp erst mal Zeitzone anpassen.

      Nicht mit so einem komischen offset sondern.:

      import "timezone" // import wegen der Berechnung um 02:00:00
      option location = timezone.location(name: "Europe/Berlin")
      

      dann Offset -1m. So liegst dann zwischen 23:59 und 23:59.

      Das Berechnen vor null Uhr ist ja nur wichtig das die Berechnung nicht dem nächsten Tag zugeordnet wird.

      Außerdem stimmt in dem Query was nicht. Du berechnest difference() und aggregierst dann mit fn: sum.

      Probiere mal so:

      import "timezone" // import wegen der Berechnung um 02:00:00
      option location = timezone.location(name: "Europe/Berlin")
      from(bucket: "nodered")
        |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
        |> filter(fn: (r) => r["_measurement"] == "KG.hz.SZ_A_Plus15")
        |> filter(fn: (r) => r["_field"] == "value")
        |> aggregateWindow(every: 1d, offset: -1m, fn: last, timeSrc: "_start")
        |> difference()
      

      DS720|Nuc8i3BEH|Proxmox|RaspberryMatic|ioBroker|influxDB2|Grafana

      C 2 Replies Last reply
      1
      • S SpacerX

        @cocomp erst mal Zeitzone anpassen.

        Nicht mit so einem komischen offset sondern.:

        import "timezone" // import wegen der Berechnung um 02:00:00
        option location = timezone.location(name: "Europe/Berlin")
        

        dann Offset -1m. So liegst dann zwischen 23:59 und 23:59.

        Das Berechnen vor null Uhr ist ja nur wichtig das die Berechnung nicht dem nächsten Tag zugeordnet wird.

        Außerdem stimmt in dem Query was nicht. Du berechnest difference() und aggregierst dann mit fn: sum.

        Probiere mal so:

        import "timezone" // import wegen der Berechnung um 02:00:00
        option location = timezone.location(name: "Europe/Berlin")
        from(bucket: "nodered")
          |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
          |> filter(fn: (r) => r["_measurement"] == "KG.hz.SZ_A_Plus15")
          |> filter(fn: (r) => r["_field"] == "value")
          |> aggregateWindow(every: 1d, offset: -1m, fn: last, timeSrc: "_start")
          |> difference()
        
        C Offline
        C Offline
        CoComp
        wrote on last edited by CoComp
        #3

        @spacerx said in Grafana - Range mit flexiblem Datum, aber immer 00:00:

        Außerdem stimmt in dem Query was nicht. Du berechnest difference() und aggregierst dann mit fn: sum.

        Die Query passt schon - das Measurement enthält Zählerstände, die alle 5 Minuten in der Influx2DB gespeichert werden. Damit ermittelt difference () die Energiemenge zwischen zwei Zählerständen und fn: sum aggregiert diese Energiemengen dann über den Tag.

        Dein Weg ist aber trotzdem die Lösung ;-) Danke..

        1 Reply Last reply
        0
        • S SpacerX

          @cocomp erst mal Zeitzone anpassen.

          Nicht mit so einem komischen offset sondern.:

          import "timezone" // import wegen der Berechnung um 02:00:00
          option location = timezone.location(name: "Europe/Berlin")
          

          dann Offset -1m. So liegst dann zwischen 23:59 und 23:59.

          Das Berechnen vor null Uhr ist ja nur wichtig das die Berechnung nicht dem nächsten Tag zugeordnet wird.

          Außerdem stimmt in dem Query was nicht. Du berechnest difference() und aggregierst dann mit fn: sum.

          Probiere mal so:

          import "timezone" // import wegen der Berechnung um 02:00:00
          option location = timezone.location(name: "Europe/Berlin")
          from(bucket: "nodered")
            |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
            |> filter(fn: (r) => r["_measurement"] == "KG.hz.SZ_A_Plus15")
            |> filter(fn: (r) => r["_field"] == "value")
            |> aggregateWindow(every: 1d, offset: -1m, fn: last, timeSrc: "_start")
            |> difference()
          
          C Offline
          C Offline
          CoComp
          wrote on last edited by CoComp
          #4

          @spacerx said in Grafana - Range mit flexiblem Datum, aber immer 00:00:

          @cocomp erst mal Zeitzone anpassen.

          Nicht mit so einem komischen offset sondern.:

          import "timezone" // import wegen der Berechnung um 02:00:00
          option location = timezone.location(name: "Europe/Berlin")
          

          dann Offset -1m. So liegst dann zwischen 23:59 und 23:59.

          Das Berechnen vor null Uhr ist ja nur wichtig das die Berechnung nicht dem nächsten Tag zugeordnet wird.

          Außerdem stimmt in dem Query was nicht. Du berechnest difference() und aggregierst dann mit fn: sum.

          Probiere mal so:

          import "timezone" // import wegen der Berechnung um 02:00:00
          option location = timezone.location(name: "Europe/Berlin")
          from(bucket: "nodered")
            |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
            |> filter(fn: (r) => r["_measurement"] == "KG.hz.SZ_A_Plus15")
            |> filter(fn: (r) => r["_field"] == "value")
            |> aggregateWindow(every: 1d, offset: -1m, fn: last, timeSrc: "_start")
            |> difference()
          

          @spacerx An einer Stelle hänge ich noch. Wie definiere ich range, damit der betrachtete Zeitraum immer am aktuellen Tag um 00:00 beginnt und bis zum Abfragezeitpunkt geht?

          mickymM 1 Reply Last reply
          0
          • C CoComp

            @spacerx said in Grafana - Range mit flexiblem Datum, aber immer 00:00:

            @cocomp erst mal Zeitzone anpassen.

            Nicht mit so einem komischen offset sondern.:

            import "timezone" // import wegen der Berechnung um 02:00:00
            option location = timezone.location(name: "Europe/Berlin")
            

            dann Offset -1m. So liegst dann zwischen 23:59 und 23:59.

            Das Berechnen vor null Uhr ist ja nur wichtig das die Berechnung nicht dem nächsten Tag zugeordnet wird.

            Außerdem stimmt in dem Query was nicht. Du berechnest difference() und aggregierst dann mit fn: sum.

            Probiere mal so:

            import "timezone" // import wegen der Berechnung um 02:00:00
            option location = timezone.location(name: "Europe/Berlin")
            from(bucket: "nodered")
              |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
              |> filter(fn: (r) => r["_measurement"] == "KG.hz.SZ_A_Plus15")
              |> filter(fn: (r) => r["_field"] == "value")
              |> aggregateWindow(every: 1d, offset: -1m, fn: last, timeSrc: "_start")
              |> difference()
            

            @spacerx An einer Stelle hänge ich noch. Wie definiere ich range, damit der betrachtete Zeitraum immer am aktuellen Tag um 00:00 beginnt und bis zum Abfragezeitpunkt geht?

            mickymM Online
            mickymM Online
            mickym
            Most Active
            wrote on last edited by mickym
            #5

            @cocomp Probiere:

            |> range(start: today())
            

            https://docs.influxdata.com/flux/v0.x/stdlib/universe/today/

            Bei stop nichts eintragen, dann wird automatisch now() genommen.

            d29201e7-5758-4740-8b54-9d85ccce929b-image.png

            Ansonsten, wenn Du über NodeRed arbeitest, kannst Du die Zeitstempel ja auch dynamisch in Deine Abfrage setzen und über die moments Bibliothek die Startzeitpunkte der jeweiligen Zeitspannen berechnen.

            Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.

            C 1 Reply Last reply
            0
            • mickymM mickym

              @cocomp Probiere:

              |> range(start: today())
              

              https://docs.influxdata.com/flux/v0.x/stdlib/universe/today/

              Bei stop nichts eintragen, dann wird automatisch now() genommen.

              d29201e7-5758-4740-8b54-9d85ccce929b-image.png

              Ansonsten, wenn Du über NodeRed arbeitest, kannst Du die Zeitstempel ja auch dynamisch in Deine Abfrage setzen und über die moments Bibliothek die Startzeitpunkte der jeweiligen Zeitspannen berechnen.

              C Offline
              C Offline
              CoComp
              wrote on last edited by CoComp
              #6

              @mickym said in Grafana - Range mit flexiblem Datum, aber immer 00:00:

              @cocomp Probiere:

              |> range(start: today())
              

              https://docs.influxdata.com/flux/v0.x/stdlib/universe/today/

              Bei stop nichts eintragen, dann wird automatisch now() genommen.

              d29201e7-5758-4740-8b54-9d85ccce929b-image.png

              Da stoße ich jetzt auf einen Punkt, den ich mir nicht erklären kann. Die Zeitzone des Dashbords ist auf CEST, also Deutschland eingestellt. Nur startet der Zeitraum aber nicht um 00:00, sondern um 2:00. Das Ende mit "automatischen" now passt dann wieder auf der aktuellen Deutschen Zeit

              92daebc5-50b5-4174-923a-aefded6e6ccf-image.png

              import "timezone" // import wegen der Berechnung um 02:00:00
              option location = timezone.location(name: "Europe/Berlin")
              from(bucket: "nodered")
                |> range(start: today())
                |> filter(fn: (r) => r["_measurement"] == "KG.hz.SZ_A_Plus15")
                |> filter(fn: (r) => r["_field"] == "value")
              

              Daten vor 02:00 sind natürlich vorhanden. Was übersehe ich?

              mickymM 1 Reply Last reply
              0
              • C CoComp

                @mickym said in Grafana - Range mit flexiblem Datum, aber immer 00:00:

                @cocomp Probiere:

                |> range(start: today())
                

                https://docs.influxdata.com/flux/v0.x/stdlib/universe/today/

                Bei stop nichts eintragen, dann wird automatisch now() genommen.

                d29201e7-5758-4740-8b54-9d85ccce929b-image.png

                Da stoße ich jetzt auf einen Punkt, den ich mir nicht erklären kann. Die Zeitzone des Dashbords ist auf CEST, also Deutschland eingestellt. Nur startet der Zeitraum aber nicht um 00:00, sondern um 2:00. Das Ende mit "automatischen" now passt dann wieder auf der aktuellen Deutschen Zeit

                92daebc5-50b5-4174-923a-aefded6e6ccf-image.png

                import "timezone" // import wegen der Berechnung um 02:00:00
                option location = timezone.location(name: "Europe/Berlin")
                from(bucket: "nodered")
                  |> range(start: today())
                  |> filter(fn: (r) => r["_measurement"] == "KG.hz.SZ_A_Plus15")
                  |> filter(fn: (r) => r["_field"] == "value")
                

                Daten vor 02:00 sind natürlich vorhanden. Was übersehe ich?

                mickymM Online
                mickymM Online
                mickym
                Most Active
                wrote on last edited by
                #7

                @cocomp Ich war immer der Meinung - dass man diese Timezone nicht braucht - da automatisch immer auf local timezone gematched wird. - Allerdings ist es zwingend Datenpunkte immer in UTC zu speichern. Aber da gibts sicher Leute, die das besser wissen als ich.

                Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.

                C 1 Reply Last reply
                0
                • mickymM mickym

                  @cocomp Ich war immer der Meinung - dass man diese Timezone nicht braucht - da automatisch immer auf local timezone gematched wird. - Allerdings ist es zwingend Datenpunkte immer in UTC zu speichern. Aber da gibts sicher Leute, die das besser wissen als ich.

                  C Offline
                  C Offline
                  CoComp
                  wrote on last edited by CoComp
                  #8

                  @mickym Da ich die Daten alle aus ioBroker oder Nodered in einer Influx2db speichere, sollten die ja in UTC vorliegen. Und das habe ich für dieses Measurement geprüft, passt also.
                  Daher meine Verwirrung.

                  mickymM 1 Reply Last reply
                  0
                  • C CoComp

                    @mickym Da ich die Daten alle aus ioBroker oder Nodered in einer Influx2db speichere, sollten die ja in UTC vorliegen. Und das habe ich für dieses Measurement geprüft, passt also.
                    Daher meine Verwirrung.

                    mickymM Online
                    mickymM Online
                    mickym
                    Most Active
                    wrote on last edited by
                    #9

                    @cocomp sagte in Grafana - Range mit flexiblem Datum, aber immer 00:00:

                    @mickym Da ich die Daten alle aus ioBroker oder Nodered in einer Influx2db speichere, sollten die ja in UTC vorliegen. Und das habe ich für dieses Measurement geprüft, passt also.
                    Daher meine Verwirrung.

                    Im NodeRed musst halt - schon das Format konvertieren:

                    be7f9647-c4f5-4df6-a450-3f2553e6d531-image.png

                    Ich hab das extra mal getestet - das Influx wirklich nur dieses Format (also Z und kein Offset) als Eingabe akzeptiert.

                    Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.

                    1 Reply Last reply
                    0
                    Reply
                    • Reply as topic
                    Log in to reply
                    • Oldest to Newest
                    • Newest to Oldest
                    • Most Votes


                    Support us

                    ioBroker
                    Community Adapters
                    Donate

                    617

                    Online

                    32.7k

                    Users

                    82.5k

                    Topics

                    1.3m

                    Posts
                    Community
                    Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen | Einwilligungseinstellungen
                    ioBroker Community 2014-2025
                    logo
                    • Login

                    • Don't have an account? Register

                    • Login or register to search.
                    • First post
                      Last post
                    0
                    • Home
                    • Recent
                    • Tags
                    • Unread 0
                    • Categories
                    • Unreplied
                    • Popular
                    • GitHub
                    • Docu
                    • Hilfe