Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[axel]

Systemdata	Bitte Ausfüllen
Hardwaresystem:	Virtuelle Maschine auf QNAP
Arbeitsspeicher:	16GB
Festplattenart:	HDD Raid 5
Betriebssystem:	Ubuntu
Node-Version:	10.x.x
Nodejs-Version:	10.x.x
NPM-Version:	6.x.x
Installationsart:	Manuell
Image genutzt:	Nein
Ort/Name der Imagedatei:	Link

Folgendes Problem:

Der Sql-Adapter speichert in meine MariaDB zeitbezogene Datensätze. Wenn ich das richtig verstehe wird dabei für das Feld ts (timestamp) eine Integer-Variable genutzt und es wird die Zeit in UTC gespeichert. Grafana erwartet die Zeit grundsätzlich als Zeit-Format in UTC und konvertiert die Zeit beim auslesen in eine konfigurierbare lokale Zeit, bei uns also CEST. Grafana erkennt das Feld ts von ioBroker aber nicht als Zeit mit der Folge, das eine automatische Rückkonvertierung nicht erfolgt und die Zeitachse um 2 Stunden verschoben ist. Das Problem scheit das Format der Splte ts zu sein. Wenn ich direkt in die DB schaue steht da für ts BIGINT der Länge 20 drin. Größe liegt wohl auch an den 1/1000 in der ioBroker-Zeit.

Kennt jemand das Problem und wie hat er das gelöst?

[Codierknecht]

@axel
Ich kann Dir nicht ganz folgen.
SQL-Adpater => MariaDB.

Grafana hat da gar kein Problem.

[Ein ehemaliger Benutzer]

@axel sagte in SQL-Adapter:

Kennt jemand das Problem und wie hat er das gelöst?

Moin,

hatten wir das nicht schon mal?
Stimmen auf allen beteiligten Rechnern die Zeitzonen?
Wie ist Deine MariaDB eingerichtet?

mysql> SELECT @@global.time_zone, @@session.time_zone;
mysql> SELECT CURRENT_TIMESTAMP();

Was steht in der my.cnf als Default time_zone?

VG
Bernd

P.S.: Es wäre auch schön, wenn Du uns Beispiele zeigen würdest und uns die Rohdaten am besten auch gleich mal zeigst.

[axel]

@dp20eic sagte in SQL-Adapter:

SELECT CURRENT_TIMESTAMP();

Also:

axel@dbserver:~$ date "+%x %H:%M"
07.10.2023 12:05

und:

MariaDB [(none)]> SELECT @@global.time_zone, @@session.time_zone;
+--------------------+---------------------+
| @@global.time_zone | @@session.time_zone |
+--------------------+---------------------+
| SYSTEM | SYSTEM |
+--------------------+---------------------+
1 row in set (0,000 sec)

MariaDB [(none)]> SELECT CURRENT_TIMESTAMP();
+---------------------+
| CURRENT_TIMESTAMP() |
+---------------------+
| 2023-10-07 12:05:57 |
+---------------------+
1 row in set (0,000 sec)

Das ist korrekt.

Die my.cnf ist so ein Problem. In meiner Installation hat /etc/mysql/my.cnf nur 2 Includeverzeichnisse. In sämtlichen inkludierten Files kann ich keine Einstellung zur time_zone finden.

Die Ergebnisse oben zeigen aber an, dass das richtig sein muss. Die Systemzeit des Rechners entspricht der Timestamp in der DB.

In Grafana-Foren kennt man das Problem: liegt daran, dass die ioBroker-TS nicht als Datum-Zeit gespeichert wird. Zumem speicher ioBroker 1/1000 Ticks...

irgendein Beispiel, keine aktuelle Zeit:

SELECT
*
FROM ts_number
WHERE id = 8171
LIMIT 10;

id      ts 	        val 	                ack 	_from 	        q
8171 	1680806220003 	0,33993000000000007 	1 	12 	        0
8171 	1680806220039 	0,33993000000000007 	1 	12 	        0
8171 	1680806340009 	0,34241999999999995 	1 	12 	        0
8171 	1680806340056 	0,34241999999999995 	1 	12 	        0 
8171 	1680806400006 	0,3526099999999999 	1 	12 	        0
8171 	1680806400047 	0,3526099999999999 	1 	12 	        0

generated 2023-10-07 12:13:26 by HeidiSQL 12.3.0.6589

[axel]

@codierknecht Danke. Ich glaube, das war die Lösung.

Ich benutze bisher:
SELECT
from_unixtime (ts/1000),
val as Wetterstation
FROM iobroker.ts_number
WHERE id=1495

mit

SELECT
ts as time,
val as Wetterstation
FROM iobroker.ts_number
WHERE id=1495

scheint das Ergebnis korreckt.

[axel]

@axel

Daten erscheinen nun 2 Stunden früher. Das ist genau die Differenz zwischen UTC und CEST.

Vielen Dank. Problem insgesamt gelöst.