-
@codierknecht
Die daten kommen über eine Adapter in iobroker direkt herein, keine Blocklyabfrage. Die Daten bei Tageswerten sind vor 24 Uhr geschrieben.
@andi_grafa sagte in Grafana, Anzeige um einen Tag verschoben:
@codierknecht
Die Daten bei Tageswerten sind von 24 Uhr geschrieben.24 Uhr gibt’s auf meiner Uhr nicht. Nach 23:59:59:999 kommt da 00:00 Uhr. Und das ist dann der nächste Tag.
Da wäre dann die Darstellung in Grafana völlig korrekt. -
@andi_grafa sagte in Grafana, Anzeige um einen Tag verschoben:
@codierknecht
Die Daten bei Tageswerten sind von 24 Uhr geschrieben.24 Uhr gibt’s auf meiner Uhr nicht. Nach 23:59:59:999 kommt da 00:00 Uhr. Und das ist dann der nächste Tag.
Da wäre dann die Darstellung in Grafana völlig korrekt.die Zeiten sind VOR 24 Uhr geschrieben. Damit man es auch nachvollziehen kann, habe ich extra den Datenverlauf von Influxdb mit angehangen. Es ist dort am Beispiel des violetten Grafen "Solarregler Ertrag Heute" eigentlich zu erkennen. Beim anderen Grafen wird eh die Differenz des letzten Tagenwertes gebildet.
-
die Zeiten sind VOR 24 Uhr geschrieben. Damit man es auch nachvollziehen kann, habe ich extra den Datenverlauf von Influxdb mit angehangen. Es ist dort am Beispiel des violetten Grafen "Solarregler Ertrag Heute" eigentlich zu erkennen. Beim anderen Grafen wird eh die Differenz des letzten Tagenwertes gebildet.
@andi_grafa
Was ein „n“ statt ’nem „r“ so ausmacht.
Wirklich erkennen kann man das im Graphen nicht, weil ungünstige Zeitskala.Da müssen dann die Flux-Experten draufschauen.
Ich weiß schon, warum ich um diese Sprache einen großen Bogen mache ;-)"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." (Martin Fowler, "Refactoring")
Proxmox 9.1.1 LXC|8 GB|Core i7-6700
HmIP|ZigBee|Tasmota|Unifi
Zabbix Certified Specialist
Konnte ich Dir helfen? Dann benutze bitte das Voting unten rechts im Beitrag -
@andi_grafa
Was ein „n“ statt ’nem „r“ so ausmacht.
Wirklich erkennen kann man das im Graphen nicht, weil ungünstige Zeitskala.Da müssen dann die Flux-Experten draufschauen.
Ich weiß schon, warum ich um diese Sprache einen großen Bogen mache ;-)@codierknecht sagte in Grafana, Anzeige um einen Tag verschoben:
Ich weiß schon, warum ich um diese Sprache einen großen Bogen mache
Und wahrscheinlich wird es sie zumindest bei InfluxDb vorerst nicht mehr geben.
Qwer weiß das schon?
-
Hallo,
ich nutze Grafana 10.3.1 mit Influx 2.0 und iobroker zur Visualisierung.
In der Balkengrafik werden die Daten um einen Tag verschoben angezeigt, d.h. die Daten vom 08.02. gehören eigentlich zum 07.02.
Die Abfrage lautet:mport "timezone" import "date" option location = timezone.location(name: "Europe/Berlin") from(bucket: "iobroker") |> range(start: date.add(d: -14d, to: today()), stop: date.truncate(t: today(), unit: 1d)) |> filter(fn: (r) => r["_measurement"] == "Regen heute") |> filter(fn: (r) => r["_field"] == "value") |>aggregateWindow(every: 1d, fn: last, createEmpty: false) |> sort(columns: ["_time"]) |> yield(name: "last")die Abfrageoptionen sind wie folgt definiert:
Was muss ich ändern, damit die Daten dem richtigen Tag zugeordnet werden?
Danke
Andreas
@andi_grafa sagte in Grafana, Anzeige um einen Tag verschoben:
d.h. die Daten vom 08.02. gehören eigentlich zum 07.02.
Die Statements sehen ja erstmal richtig aus. In Grafana hast Du auch deine richtige Zeitzone hinterlegt? Könnte sein dass das Frontend die Daten als UTC formatiert. Dann wäre es ja ein Tag vorher (-1h). Dann wäre es nur ein Darstellungsproblem von Grafana und Du suchst am falschen Ende.
-
Hallo,
ich nutze Grafana 10.3.1 mit Influx 2.0 und iobroker zur Visualisierung.
In der Balkengrafik werden die Daten um einen Tag verschoben angezeigt, d.h. die Daten vom 08.02. gehören eigentlich zum 07.02.
Die Abfrage lautet:mport "timezone" import "date" option location = timezone.location(name: "Europe/Berlin") from(bucket: "iobroker") |> range(start: date.add(d: -14d, to: today()), stop: date.truncate(t: today(), unit: 1d)) |> filter(fn: (r) => r["_measurement"] == "Regen heute") |> filter(fn: (r) => r["_field"] == "value") |>aggregateWindow(every: 1d, fn: last, createEmpty: false) |> sort(columns: ["_time"]) |> yield(name: "last")die Abfrageoptionen sind wie folgt definiert:
Was muss ich ändern, damit die Daten dem richtigen Tag zugeordnet werden?
Danke
Andreas
@andi_grafa sagte in Grafana, Anzeige um einen Tag verschoben:
Was muss ich ändern, damit die Daten dem richtigen Tag zugeordnet werden?
Ich bin etwas verwirrt, weil in der ersten Abfrage etwas von "Regen heute" steht. Ansonsten würde ich aus
|>aggregateWindow(every: 1d, fn: max, createEmpty: false)|>aggregateWindow(every: 1d, fn: max, createEmpty: false, timeSrc: "_start")machen, damit die Zuordnung passt.
-
@codierknecht sagte in Grafana, Anzeige um einen Tag verschoben:
Ich weiß schon, warum ich um diese Sprache einen großen Bogen mache
Und wahrscheinlich wird es sie zumindest bei InfluxDb vorerst nicht mehr geben.
Qwer weiß das schon?
Und wahrscheinlich wird es sie zumindest bei InfluxDb vorerst nicht mehr geben.
Hat wohl seine Gründe..
Eine Structured Query Language liest sich halt irgendwie besser … und auch logischer."Any fool can write code that a computer can understand. Good programmers write code that humans can understand." (Martin Fowler, "Refactoring")
Proxmox 9.1.1 LXC|8 GB|Core i7-6700
HmIP|ZigBee|Tasmota|Unifi
Zabbix Certified Specialist
Konnte ich Dir helfen? Dann benutze bitte das Voting unten rechts im Beitrag -
Und wahrscheinlich wird es sie zumindest bei InfluxDb vorerst nicht mehr geben.
Hat wohl seine Gründe..
Eine Structured Query Language liest sich halt irgendwie besser … und auch logischer.@codierknecht sagte in Grafana, Anzeige um einen Tag verschoben:
Eine Structured Query Language liest sich halt irgendwie besser … und auch logischer.
... kommt aber aus der Welt der relationalen Datenbanken. Darum finde ich FLUX für die Art der Daten (Time Series) ziemlich cool. Aber du hast natürlich Recht, sich da jetzt noch reinzudenken ist es wohl nicht Wert.
-
Und wahrscheinlich wird es sie zumindest bei InfluxDb vorerst nicht mehr geben.
Hat wohl seine Gründe..
Eine Structured Query Language liest sich halt irgendwie besser … und auch logischer.@codierknecht Ganz ehrlich? Nach 20+ Jahren SQL fand ich Flux wirklich erfrischend und an vielen Stellen sogar intuitiver
-
-
@andi_grafa sagte in Grafana, Anzeige um einen Tag verschoben:
Was muss ich ändern, damit die Daten dem richtigen Tag zugeordnet werden?
Ich bin etwas verwirrt, weil in der ersten Abfrage etwas von "Regen heute" steht. Ansonsten würde ich aus
|>aggregateWindow(every: 1d, fn: max, createEmpty: false)|>aggregateWindow(every: 1d, fn: max, createEmpty: false, timeSrc: "_start")machen, damit die Zuordnung passt.
@marc-berg
Es stimmt, ich habe 2 Visualisierungen, wo die Werte um einen Tag verschoben sind.- Regenmelder
- Solarertrag
beide Abfragen sind identisch aufgebaut.
ober habe ich nochmals die zusammengehörenden Grafiken vom:
- Influxdb
- Grafana Abfragen
- Grafana Visualisierung
gepostet.
-
@marc-berg
Es stimmt, ich habe 2 Visualisierungen, wo die Werte um einen Tag verschoben sind.- Regenmelder
- Solarertrag
beide Abfragen sind identisch aufgebaut.
ober habe ich nochmals die zusammengehörenden Grafiken vom:
- Influxdb
- Grafana Abfragen
- Grafana Visualisierung
gepostet.
@andi_grafa sagte in Grafana, Anzeige um einen Tag verschoben:
, ich habe 2 Visualisierungen, wo die Werte um einen Tag verschoben sind.
und hat
timeSrc: "_start")jetzt was gebracht? Ist halt schwer zu beurteilen, wenn man die Quelldaten nicht hat.
-
@andi_grafa sagte in Grafana, Anzeige um einen Tag verschoben:
, ich habe 2 Visualisierungen, wo die Werte um einen Tag verschoben sind.
und hat
timeSrc: "_start")jetzt was gebracht? Ist halt schwer zu beurteilen, wenn man die Quelldaten nicht hat.
@marc-berg
sieht super aus, danke!Ich verstehe zwar nicht, was manche Befehle bedeuten, aber offensichtlich scheint es zu funktionieren. Ich werde Versuchen, in den Hilfen von Grafana etwas zu finden.
Support us
748
Online32.7k
Users82.5k
Topics1.3m
Posts