[Frage] [V1.6.0RC6] Nutzung von Variablen in Grafana Parallelinstanz [v7.2.2]

[blaubaerli]

Leider wirft:

select math(difference(*) *0.2794) from (Select last(*) from "TS00128" WHERE time > now() - 2d GROUP BY time(1d) limit 2)

den Fehler:

"InfluxDB Error: undefined function math()"

Ich glaube allmählich, dass der Ansatz hier mittlerweile fast nur noch akademischen Wert hat. Das ist ja nicht wirklich intuitiv. Zudem muss man die Query dafür ja echt manuell editieren und kann nicht mit dem integrierten Query-Builder arbeiten.

In einem eigenständigen Dashboard mit dem über den Picker ausgewählten Begriff "Yesterday" und dem auf "1d" gesetzten Intervall und der über den Querybuilder ausgewählten Math-Option klappt das dann vergleichsweise einfach. Aber eben mit dem Nachteil, dass ich die dynamischen Vergleichszahlen nur über ein separates Dashboard bekomme.

Beste Grüße
Jens

[gbglace]

Wie sehen denn dann die Klick SQL aus. Die dann per Hand geschrieben hart codiert, lässt dann ggf auch unterschiedliche Zeitbezüge in einem Dashboard zu.

So ist es aber immer, KlickKlack ist einfach und etwas begrenzt, direkter Eingriff in den Code ermöglicht dann viel mehr. SQL ist schon eine mächtige Sprache aber ja nicht jeder Datenbanktyp unterstützt alle Funktionen oder hat eine gewisse Dialektik / Semantik.

[Robosoc]

Ich lag wahrscheinlich mit der Vermutung "math" zu benutzen auch falsch, das wäre notwendig bei KlickKlack, aber bei SQL wohl nicht. Also versteh ich auch nicht, warum Dein Weg nicht ging, aber Du könntest noch ausprobieren - wenn Du noch magst - die Multiplikation im ersten Teil, also bei Select last (*) ... einzubringen...

Nur als eine Idee. Aber mir wäre nicht klar, warum das eine Änderung bringen soll.

[Sensej]

Leider wirft:

select math(difference(*) *0.2794) from (Select last(*) from "TS00128" WHERE time > now() - 2d GROUP BY time(1d) limit 2)

den Fehler:

Hallo Jens,

select test_sum_Val * 0.2794 from (select difference(*) as test from (Select sum(*) from "TS00018" WHERE time > now() - 2d GROUP BY time(1d) limit 2))

MfG Juri

[blaubaerli]

Hi Juri,

super Ansatz! Für meine Lösung nun adaptiert:

select test_last_Val * 0.2794 from (select difference(*) as test from (Select last(*) from "TS00123" WHERE time > now() - 2d GROUP BY time(1d) limit 2))

Dabei ist in der TS00123 dann als Rohdaten der mit jedem Puls steigende neue Zählerstand.

Aber gestern habe ich dann mit Hilfe des Query-Analysers den nächsten Klopfer gefunden

Hier mal die Dateninfo zu der o.g. Query:

29-10-_2020_21-10-13.jpg

Man achte auf die Uhrzeit. Nun habe ich gestern Nacht so lange rumgezaubert, dass ich um kurz nach Mitternacht die Query aufgerufen habe. Der Effekt: In der Zeitspanne zwischen 00:00 und 01:00 schießt die Abfrage allen ernstes daneben.

Nicht das ich jetzt grundsätzlich zischen 00:00 und 01:00 verlässlich die Info bräuchte wieviel es am Vortag geregnet hat, aber damit hat der Ansatz zumindest diese technische Schwäche. Und so richtig intuitiv.....

Wenn ich mir den Standardweg von Grafana anschaue, dann ist die Basis da ja recht einfach zusammenklickbar. Im Timepicker "Yesterday" und in den "Query options" als "Min intervall" "1d" eingetragen. Dann sieht das mit der im Querybuilder zusammengeklickten Abfrage dann so aus:

29-10-_2020_21-23-06.jpg

Über den Query-Analyser sehe ich dann, was Grafana daraus zaubert:

29-10-_2020_21-24-54.jpg

Also da rechnet sich Grafana konkret die richtigen Zeiten zurecht und geht dann damit an die Influx-DB und bekommt auch (heute früh geprüft) gesichert in der Zeit zwischen 00:00 und 01:00 die korrekten Ergebnisse.

Dazu dann mal folgende Screenshots vom "www.epochconverter.com"

29-10-_2020_21-30-12.jpg

und

29-10-_2020_21-31-45.jpg

D.h. Grafana greift da noch korrigierend ein und berücksichtigt Zeitzonen, etc.

Aber wenn ich den Komfort beim Bau der Queries haben will dann kann ich eben die statischen und dynamischen Elemente nicht einfach mischen.

Damit wären wir ja auch wieder beim Basisthema des Threads angekommen... Ich hatte ja ursprünglich die Hoffnung, dass ich mir irgendwie die für die zeitlich Abgrenzung erforderlichen beiden Uhrzeitwerte völlig losgelöst in einer Variablen zusammenbauen kann, also irgendwie in der Art:

Zielvariable1=Today():Formatangabe
Zielvariable2=Today()-1d:Formatangabe

Aber das scheint wohl nicht wirklich zu gehen.

Aber ehrlich, ich bin schon mal sehr zufrieden mit dem erreichten Stand. Ohne eure Hilfe wäre ich ja nie und nimmer soweit gekommen.

Besten Dank dafür.

Beste Grüße
Jens

[Sensej]

Aber gestern habe ich dann mit Hilfe des Query-Analysers den nächsten Klopfer gefunden

29-10-_2020_21-10-13.jpg

Man achte auf die Uhrzeit. Nun habe ich gestern Nacht so lange rumgezaubert, dass ich um kurz nach Mitternacht die Query aufgerufen habe. Der Effekt: In der Zeitspanne zwischen 00:00 und 01:00 schießt die Abfrage allen ernstes daneben.

Nicht das ich jetzt grundsätzlich zischen 00:00 und 01:00 verlässlich die Info bräuchte wieviel es am Vortag geregnet hat, aber damit hat der Ansatz zumindest diese technische Schwäche. Und so richtig intuitiv.....

Hallo Jens,

die beiden SQl-Statements, siehe unten, liefern den gleichen Wert zurück, also sind sie richtig und es liegt nicht an der SQL-Abfrage

hartkodierte Datumsangabe
Select sum(*) from "TS00018" WHERE time >= '2020-10-29T00:00:00Z' AND time < '2020-10-29T23:59:59Z' GROUP BY time(1d)

dynamisch abgeleitete Datumsangabe
select last(*) from (Select sum(*) from "TS00018" WHERE time > now() - 2d GROUP BY time(1d) limit 2)

sondern, das ist nur meine Vermutung, liegt es an der grafanaspezifischen Dashboard-Einstellung "Timezone".
Wahrscheinlich hast du "Default" drin, muss aber "UTC" sein.

Timezone "Default"

Default-Timezone.jpg

Timezone "UTC"

UTC-Timezone.jpg

MfG Juri

[blaubaerli]

Hi Juri,

ich sehe schon, du bist da ja echt fitt. Ich komme allerdings frühestens morgen abend zum vernünftigen Test.

Danke schon mal.

Beste Grüße
Jens