Weihnachtsangebot 2025! 🎄

[Domi1893]

Hallo,

ich möchte meine Daten im SQL-Adapter irgendwie im Datetime Format mit ablegen. Für Grafana wäre das geschickter, denke ich. Ich kann zwar in Grafana die Daten abrufen und das funktioniert grundsätzlich alles. Jedoch bekomme ich ein Problem, wenn ich Daten zeitlich gruppiere, dann habe ich einen Versatz um den Betrag der Lokalzeit zu UTC. Wenn ich die Daten ohne Gruppierung auftrage, habe ich diesen Versatz nicht. Da scheint dann irgendwas mit der Erkennung der lokalen Zeit schief zu gehen. Deshalb würde ich zusätzlich gerne den Timestamp als Datetime mit ablegen.
In der Doku steht, dass man das in Date konvertieren kann. Mir ist nur nicht klar wie, und ob das für meine Zwecke mit der Beschreibung funktioniert.

Für eine Hilfe wäre ich super dankbar.

Grüße,

Domi

[fastfoot]

@domi1893 mir ist nicht klar was du vorhast. Hast du eine Abfrage für Grafana und wie lautet die? Die Datenbank kannst du ja nicht verändern(erweitern) und das braucht es wohl auch nicht

[Domi1893]

@fastfoot sagte in SQL-Adapter Datetime generieren:

Die Datenbank kannst du ja nicht verändern(erweitern) und das braucht es wohl auch nicht

Das wäre meine Frage gewesen. Ich habe das Gefühl, dass Grafana Probleme hat, den lokalen Zeitstempel zu identifizieren und zwar dann, wenn ich gruppiere.

Als Beispiel:

Wenn ich folgendes tue:

SELECT
ts/1000 AS "time",
val as "Temperatur"
FROM ts_number
where id = 39 and val >0

erhalte ich die Werte in der korrekten Zeit dargestellt (Grafana ist in der gleichen Zeitzone eingestellt, wie der Server selbst und dessen Werte, die auch in der lokalen Zeit abgelegt werden, wenn ich das richtig verstanden habe.

Tue ich hingegen folgendes:

SELECT
$__unixEpochGroup(ts/1000,'1d') as "time",
max(ts/1000) as max,
min(ts/1000) as min,
(max(ts/1000)-min(ts/1000))/3600 as testen,
avg(val)*(max(ts/1000)-min(ts/1000))/3600000 as "Hausverbrauch",
sum(val)/360000 as "Int"
from ts_number
where id = 39 and val>0 and $__unixEpochFilter(ts/1000)
group by time

dann kommt in der Anzeige ein Versatz raus und zwar im die Differenz der lokalen Abweichung zur UTC. Das könnte ich in der Vis zwar korrigieren, indem ich einfach auf UTC stelle, das Problem der falschen Gruppierung bleibt allerdings bestehen. Das habe ich getesten, in dem ich mir den kleinsten Wert des TS für den Tag ausgeben lasse, der ist dann aktuell bei 2 Uhr in der Nacht. Im ersten Moment dachte ich an einen Makro-Fehler bei Grafana. Was mich jedoch stutzig macht ist die Tatsache, dass bei allen Probleme in Grafana mit MySQL immer gefragt wird, ob die Daten in Datetime vorliegen. Das ist hier ja nicht der Fall, deshalb mein Weg hierrüber.

Ich würde mir jetzt quasi eine Datetime-Spalte zusätzlich mit füllen wollen, um zu testen, ob das Problem dann immer noch besteht. Nur ist mir nicht ganz klar, wie ich das tun kann, da ich mit dem Datenbankthema nicht so vertraut bin.

Ich hoffe ich konnte mein Problem halbwegs darstellen und ich habe nichts vergessen.
Eine Hilfe zur Lösung wäre wirklich dufte.

[fastfoot]

@domi1893 so ganz verstehe ich das nicht, liegt aber an fehlenden Kenntnissen zu Grafana und dazu was diese beiden Makros bewirken. Sonst könnte man das ja in SQL nachbauen. Eine Datetime kannst du dir aber mit FROM_UNIXTIME(ts/1000) erzeugen. Ob dein Mysql/Mariadb tatsächlich auf lokale Zeit eingestellt ist kannst du mit FROM_UNIXTIME(0) testen, dann müsste er dir 1970-01-01 01:00:00 anzeigen

[Domi1893]

@fastfoot Ja, für mich ist das auch nicht nachvollziehbar. Meine Prüfung zum TS in der DB sah wie folgt aus. Ich habe Werte, die sekündlich abgelegt werden. Ich nehme mir einfach den letzten Wert, rechne ihn in UTC um, wenn dann meine lokale, aktuelle Zeit rauskommt, wäre das für mich der Nachweis, dass die Daten dort im lokalen Zeitstempel abliegen. Die Frage ist: kann ich in einer Abfrage die Daten vorher von lokal in UTC konvertieren?

Vielleicht muss ich das Problem doch eher in Grafana suchen...

[fastfoot]

@domi1893 sagte in SQL-Adapter Datetime generieren:

@fastfoot Ja, für mich ist das auch nicht nachvollziehbar. Meine Prüfung zum TS in der DB sah wie folgt aus. Ich habe Werte, die sekündlich abgelegt werden. Ich nehme mir einfach den letzten Wert, rechne ihn in UTC um, wenn dann meine lokale, aktuelle Zeit rauskommt, wäre das für mich der Nachweis, dass die Daten dort im lokalen Zeitstempel abliegen. Die Frage ist: kann ich in einer Abfrage die Daten vorher von lokal in UTC konvertieren?

Vielleicht muss ich das Problem doch eher in Grafana suchen...

TS ist immer UTC! Die Frage ist ob Grafana das in lokale Zeit wandelt. Du wolltest aber in eine Datetime Spalte wandeln, und da liefert FROM_UNIXTIME() eben auch einen gewandelten Wert, je nach Einstellung in der DB

[onweb]

@domi1893 sagte in SQL-Adapter Datetime generieren:

SELECT
ts/1000 AS "time",
val as "Temperatur"
FROM ts_number
where id = 39 and val >0

Warum machst du "ts/1000" ?

Nach meiner Erfahrung erkennt dies Grafana selbstständig und man muss die Millisekunden nicht rausrechnen.
Vielleicht dies auch die Ursache deines Darstellungsproblems mit Grafana

[fastfoot]

@onweb sagte in SQL-Adapter Datetime generieren:

Warum machst du "ts/1000" ?

Also mein Grafana(latest) will das so oder es gibt keine Daten

[Domi1893]

@fastfoot

@fastfoot sagte in SQL-Adapter Datetime generieren:

@onweb sagte in SQL-Adapter Datetime generieren:

Warum machst du "ts/1000" ?

Also mein Grafana(latest) will das so oder es gibt keine Daten

So ist es bei mir auch. Grundsätzlich funktioniert das ja. Die Daten werden grundsätzlich auch richtig dargestellt auf der Zeitachse, nur, sobald ich das Group-Makro verwende und z.B. nach Tagen gruppiere und mir dazu die Tagesgrenzen ausgeben lasse, sehe ich die Grenze von 2 bis 2 Uhr.

Grüße,

Domi

[fastfoot]

@domi1893 sagte in SQL-Adapter Datetime generieren:

So ist es bei mir auch. Grundsätzlich funktioniert das ja. Die Daten werden grundsätzlich auch richtig dargestellt auf der Zeitachse, nur, sobald ich das Group-Makro verwende und z.B. nach Tagen gruppiere und mir dazu die Tagesgrenzen ausgeben lasse, sehe ich die Grenze von 2 bis 2 Uhr.

Die Tagesgrenzen werden immer in UTC berechnet(ts/1000 DIV 86400 * 86400), weshalb es dann bei der Berechnung in die lokale Zeit zu dieser Differenz kommt. Wenn du Daten aus dem Februar abrufst wird die Differenz nur 1Std betragen, wegen der Winterzeit. Ob das jetzt aber ein Fehler ist oder tatsächlich nicht anders zu berechnen ist, vermag ich nicht zu beurteilen

[Domi1893]

@fastfoot sagte in SQL-Adapter Datetime generieren:

Die Tagesgrenzen werden immer in UTC berechnet(ts/1000 DIV 86400 * 86400), weshalb es dann bei der Berechnung in die lokale Zeit zu dieser Differenz kommt. Wenn du Daten aus dem Februar abrufst wird die Differenz nur 1Std betragen, wegen der Winterzeit. Ob das jetzt aber ein Fehler ist oder tatsächlich nicht anders zu berechnen ist, vermag ich nicht zu beurteilen

Ja genau, die Frage ist, ob ich den Frame in Abhängigkeit der aktuellen Ortszeit anpassen kann? Gerade beim Stromverbrauch etc. ist dieser Versatz ungünstig.