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