Gelöst: Dblog und Grafana 2h versatz

Begonnen von ChristianH, 30 September 2018, 16:01:07

Vorheriges Thema - Nächstes Thema

ChristianH

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


ChristianH

Zur Info - lag an der Beta Version von Grafana

Xguide

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
FHEM 5.9 - Intel NUC i3 mit Proxmox im Stretch Container
HomeMatic - VCCU mit 2 x HM-LAN-CFG
Module: SMA Peripheries - Sonos - IPCam(s) - Philips Hue - Sprinkler - TabletUI - DBlog -

MKeY

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
Wer Fehler findet, darf sie behalten!
RPi's, D1Mini
Homematic, Hue, Sonoff, Alexa, Xiaomi, ConBee
Prusa MK2.5, Prusa MK3S (MMU2S vorhanden, aber nervtötend)
Lowrider 2CNC

Xguide

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
FHEM 5.9 - Intel NUC i3 mit Proxmox im Stretch Container
HomeMatic - VCCU mit 2 x HM-LAN-CFG
Module: SMA Peripheries - Sonos - IPCam(s) - Philips Hue - Sprinkler - TabletUI - DBlog -

MKeY

Wer Fehler findet, darf sie behalten!
RPi's, D1Mini
Homematic, Hue, Sonoff, Alexa, Xiaomi, ConBee
Prusa MK2.5, Prusa MK3S (MMU2S vorhanden, aber nervtötend)
Lowrider 2CNC

Xguide

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!
FHEM 5.9 - Intel NUC i3 mit Proxmox im Stretch Container
HomeMatic - VCCU mit 2 x HM-LAN-CFG
Module: SMA Peripheries - Sonos - IPCam(s) - Philips Hue - Sprinkler - TabletUI - DBlog -

kadettilac89

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

Xguide

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.

FHEM 5.9 - Intel NUC i3 mit Proxmox im Stretch Container
HomeMatic - VCCU mit 2 x HM-LAN-CFG
Module: SMA Peripheries - Sonos - IPCam(s) - Philips Hue - Sprinkler - TabletUI - DBlog -

kadettilac89

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.

Xguide

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.
FHEM 5.9 - Intel NUC i3 mit Proxmox im Stretch Container
HomeMatic - VCCU mit 2 x HM-LAN-CFG
Module: SMA Peripheries - Sonos - IPCam(s) - Philips Hue - Sprinkler - TabletUI - DBlog -

Xguide

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.
FHEM 5.9 - Intel NUC i3 mit Proxmox im Stretch Container
HomeMatic - VCCU mit 2 x HM-LAN-CFG
Module: SMA Peripheries - Sonos - IPCam(s) - Philips Hue - Sprinkler - TabletUI - DBlog -

smart.builder

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

markus1407

#13
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

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








PichlAlex

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

vielleicht hilft es jemanden....

schöne Grüße
Alex