Hallo zusammen,
Nachdem ich endlich realisiert habe, dass ich vom web interface, welches ich per https gesichert habe, keinen iframe auf ein http Server machen kann, läuft die Integration ganz gut.
Was aber nun wirklich merkwürdig ist, die Grafana Plots haben einen 2h Zeitversatzt. Die alten svg Plots sind zeitlich richtig.
Der Grafana Server, fhem und MySQL sind zeitlich synchron.
Hat jemand eine Idee?
Christian
Gesendet von meinem ONEPLUS A5010 mit Tapatalk
Zur Info - lag an der Beta Version von Grafana
Hallo zusammen,
kann mir ggf. mal jemand einen Denkanstoss geben.
Ich logge Daten mit DBlog in einer Postgres DB und möchte mir die Daten mit Grafana im Trend visualisieren.
Beim Aufbau des Querys mit Assitent in Grafana werden mir auch die Tabellen "Current" und "History" vorgeschlagen, also sollte die Verbindung mit Berechtigungen wohl stehen. Ich bekomme aber nicht einen Wert in den Graphen gezaubert. Hat vielleicht mal jemand ein Beispiel? Ich vermute es liegt am DateTime Format, kann das sein?
Danke und viele Grüße,
Marcel
Ich logge mit DBLog und habe zum Bsp ein solches Query in Grafana:
SELECT
UNIX_TIMESTAMP(`TIMESTAMP`) as time_sec,
CAST(`VALUE` AS DECIMAL(10, 6)) as value,
'Computer' as text
FROM `history`
WHERE $__timeFilter(`TIMESTAMP`) AND `DEVICE` = 'sonoff_Pow01' AND `READING` = 'sensor-energy-today'
ORDER BY `TIMESTAMP` ASC
Hallo Mkey,
danke für den Tipp, werde ich gleich mal ausprobieren, wobei es mir bekannt vorkommt. Hast du auch Postgres oder evtl. MySQL?
Gruß Marcel
die daten werden per mySQL geloggt, zum Anlegen nutze ich heidisql
analog https://www.youtube.com/watch?v=oLJfw-0ww8I (https://www.youtube.com/watch?v=oLJfw-0ww8I) in Vbdg mit https://www.youtube.com/watch?v=b0Ors2hJJ5s (https://www.youtube.com/watch?v=b0Ors2hJJ5s)
Hi MkeY,
ich habe es geschafft :-) Postgres verhält sich da etwas anders als MySQL. Irgendwie habe ich aber auch komplett auf dem Schlauch gestanden.
Nachdem ich nun den Datentypen der "timestamp" column auf timestamp with time zone geändert habe, funktioniert folgendes beispielhaftes Query.
SELECT
$__time("timestamp"),
CAST("value" AS DECIMAL(10, 6)) as value,
'SMA_TriPower10' as text
FROM "history"
WHERE $__timeFilter("timestamp") AND "device" = 'SMA_TriPower10' AND "reading" = 'SPOT_PACTOT'
ORDER BY "timestamp" ASC
Allerdings sind die Werte jetzt um 2h verschoben, das muss ich noch in den Griff bekommen. Datenbank Timezone ist UTC!
es gibt einen eigenen thread zu grafana und dblog, da kam das thema timezone schon mal auf ...
https://forum.fhem.de/index.php/topic,77724.msg893532/topicseen.html#msg893532
Danke für den Verweis, bei dem Titel MySQL war ich schon fast raus.
Zitat von: ChrisW am 24 Januar 2019, 08:32:08
booooor also nach langennn hin und her aktuell scheint das zu stimmen:
/org dort Browser Time
im Dashboard UTC
Jetzt stimmen die Angaben auch.
Ich nutze Current und History was wohl nun dafür sorgt das die letzten ( Neusten Werte ) nicht angezeigt werden. Welche vorteil soll dieses Current überhaupt haben ? Nur das Aktuelle Werte schneller ausgegeben werde und nicht in der großen Histrory geschaut wird ? Weil dann stelle ich komplett nur auf History um
Das vorgeschlagene Workaround im Grafana WebInterface die Zeitzone auf UTC umzustellen, funktioniert jetzt erstmal.
Allerdings hat man nun immer ein leuchtendes UTC eingeblendet, was ja faktisch falsch ist. Prinzipiell müsste der Zeitwert mit TimeZone gespeichert werden. Ich werde mal schauen ob ich das per Trigger nachbauen kann.
Zitat von: Xguide am 08 April 2019, 15:18:47
Danke für den Verweis, bei dem Titel MySQL war ich schon fast raus.
Das vorgeschlagene Workaround im Grafana WebInterface die Zeitzone auf UTC umzustellen, funktioniert jetzt erstmal.
Allerdings hat man nun immer ein leuchtendes UTC eingeblendet, was ja faktisch falsch ist. Prinzipiell müsste der Zeitwert mit TimeZone gespeichert werden. Ich werde mal schauen ob ich das per Trigger nachbauen kann.
und der hinweis aus dem grafana thread, die timezone beim select mitzugeben, bringt nicht das gewünschte ergebnis? standard sql-funktion, sollte auch postgresql können.
Ich muss mir das noch mal in Ruhe ansehen, ich mache es momentan immer zwischen Tür und Angel und das ist nicht wirklich zielführen.
Nur um das hier auch noch mal kurz zu dokumentieren.
Bezieht sich auf die Verwendung von DBlog in Verbindung mit Postgres und Grafana .
Prinzipiell müsste fhem in die History einen UTC-Timestamp schreiben und die Spalte "timestamp" müsste vom Datentypen "time stamp with timezone sein".
Dafür müsste die Datenbank mit der geltenden Zeitzone initialisiert sein. Debian allein war nicht ausreichend, ich habe die Datenbank entsprechend modifiziert:
ALTER DATABASE fhem SET timezone TO 'Europe/Berlin';
Dann kann bspw. in Grafana auch als Zeiteinstellung "local time of browser" ausgewählt werdenn.
Das wiederum geht dann aber in die Hose (Zeitversatz aktuell 2h), da wie oben geschrieben, die zeitstempel nicht in UTC in die DB geschrieben werden.
Ich kann mit dem jetzigen Setup ganz gut leben.
Falls das umgebaut werden sollte, dann muss DBlog Zeitstempel in UTC zur Verfügung stellen, die Spalte timestamp in der Tabelle history angepasst werden. (timestamp with timezone)
Datenbank Timezone gesetzt werden und sämtlicher vorhandener Datenbestand auf UTC-Zeit geupdet werden. Eingetragenen Zeit - Bias. Dabei wären dann noch die Zeitintervalle von Sommer und Winterzeit zu berücksichtigen.
Hallo Zusammen,
ich hatte ein ähnliches Problem mit dem Zeitversatz in Grafana. Die Dblog Daten werden bei mir mit Zeitstempel UTC+1 und nicht UTC geschrieben. Eine relativ schnelle und schmerzlose Lösung ist die Zeitstempelkonvertierung direkt im SQL-Query. An Stelle von $__timeFilter müssen $__timeFrom, $__timeTo plus die entsprechenden Konvertierungen CONVERT_TZ(`TIMESTAMP`, '+01:00','+00:00') verwendet werden:
SELECT
CONVERT_TZ(`TIMESTAMP`, '+01:00','+00:00') as time_sec,
CAST(`VALUE` AS DECIMAL(10, 6)) as value,
'Temperatur' as metric
FROM `history`
WHERE `DEVICE` = 'XMI_T_Aussen' AND `READING` = 'temperature' AND
CONVERT_TZ(`TIMESTAMP`, '+01:00','+00:00') > $__timeFrom() AND
CONVERT_TZ(`TIMESTAMP`, '+01:00','+00:00') <= $__timeTo()
ORDER BY `TIMESTAMP` ASC
Hallo,
Meine Lösung sieht wie folgt aus:
1) FHEM Server läuft auf TZ Europe/Berlin
Zeitstempel werden dann mit Localtime erzeugt.
2) DBLog schreibt Daten auf einen MariaDB
3) MariaDB Docker Container.
Der Container/Server muss ebenfalls auf TZ Europe/Berlin stehen.
Das geht z.B. mit "docker run -v /etc/localtime:/etc/localtime:ro ....."
Damit werden die Zeitstempel beim schreiben in die Datenbank automatisch in UTC konvertiert.
Somit sind die Daten immer UTC, egal ob Sommer oder Winterzeit.
Beim auslesen werden die Zeitstempel wieder nach Localtime zurück konvertiert.
https://mariadb.com/kb/en/timestamp/#time-zones (https://mariadb.com/kb/en/timestamp/#time-zones)
Somit sollten SVG plots die Daten beim auslesen wieder so bekommen wie benötigt.
(Habe ich nicht getestet.)
Interessant wird der Wechsel zwischen Sommer und Winterzeit, hier sollte kein "Sprung" in den Daten entstehen.
Dies kann je nach Anwendung so gewollt sein, oder auch nicht.
Es kommt (vermutlich) darauf an, wann man die Daten ausliest und wann sie geloggt wurden. (mal bis zum Herbst abwarten.)
4) Grafana
Grafana habe ich ebenfalls in einem Docker Container laufen.
System auf Localtime Zone "TZ Europe/Berlin" eingestellt.
Grafana -> Preferences -> Timezone -> "TZ Europe/Berlin"
Zusätzlich bei der Datenbankabfrage: UNIX_TIMESTAMP(TIMESTAMP) AS "time",
SELECT
UNIX_TIMESTAMP(TIMESTAMP) AS "time",
CAST(`value` AS DECIMAL) AS "Luftfeuchte"
FROM history
WHERE
$__timeFilter(TIMESTAMP) AND
READING = 'humidity' AND
DEVICE = 'WetterOpenWeatherMap'
ORDER BY TIMESTAMP
Hallo,
ich habe eine alternative Lösung für dieses Problem gefunden und hier dokumentiert:
DBLOG / Vorschlag für Änderung an /fhem/contrib/dblog/db_create_postgresql.sql https://forum.fhem.de/index.php/topic,127784.0.html (https://forum.fhem.de/index.php/topic,127784.0.html)
vielleicht hilft es jemanden....
schöne Grüße
Alex