Influxdb LBS19002576 Zeitzonen Problem und InfluxDB2\Model\WritePrecision

[jonofe]

Hab heute mal ein wenig getestet und das funktioniert ganz gut.
dhb2002 Ist mein Verständnis korrekt, dass man die alten Daten eigentlich gar nicht migrieren muss? Nach Einspielen der neuen LBS Version wird doch einfach mit Mikrosekunden Timestamp und ohne Tag "us" ins gleiche Measurement geschrieben, richtig?
Gibt es da ein Problem, wenn Einträge mit unterschiedlicher Timestamp Precision oder unterschiedlicher Anzahl von Tags in einem Measurement sind?

[dhb2002]

Falls du eine lauffähige Version mit Mikrosekunden Timestamp hast, dann bau ich das gerne ein

So, ich hätte eine Version welche die Mikrosekunden Timestamps benutzt und korrekt mit Zeitzonen die nicht 'Europe/Berlin' sind, umgehen kann im Anhang.

Wie so oft, wenn man erstmal weiß was die Influx API will, ist es einfach. Zum Daten einfügen braucht es eine Epoch in Microsekunden (z.B. 1656045907419042), zum Löschen dann eine RFC3339 UTC Zeit mit den Mikrosekunden als Nachkommastellen (z.B. 2022-06-24T04:45:07.419042Z).

Zum Konvertieren der InfluxDB mit den 'alten' Datensätzen wäre mein naiver Ansatz

1. Backup
2. Durch die Daten per _measurement iterieren und die Daten mit Mikrosekundenpräzision nochmal einfügen, d.h. aus _time und us tag errechnen.
3. Alte sind dann all die, die ein us tag haben. Können darüber im Delete Statement gefiltert werden

Wie gesagt, kein Flux Guru. Wenn jemand eine gute Idee hat, dann lasst hören.

[dhb2002]

Habe gerade gesehen, dass das Problem eine andere Ursache hat.

Super, damit wäre die Ursache geklärt. Hätte mir eigentlich auch auffallen sollen. Ist ja ansonsten sehr clever gemacht von dir.

Ich werde also das obige require ersetzen und dann die hart codierte Timezone durch die Timezone aus der config.php.
Dann sollte alles gut sein, oder?

Die Timezone nicht angeben. Die ist ja dann korrekt gesetzt. Bei mir sieht es so aus:

function datetime2utc($datetime)
{
  $tz_to = 'UTC';
  $format = 'Ymd\THis\Z';
  $dt = new DateTime($datetime);
  $dt->setTimeZone(new DateTimeZone($tz_to));
  return $dt->format($format);
}

Beim Loggen das

date_default_timezone_set("Europe/Berlin");

auch ganz rausschmeißen. Du änderst die Zeitzone dann ja nie, außer Object intern beim DateTime Object in der Konvertierung.

Das mit den Zeitzonen ist immer sehr fehlerträchtig. Wenn man mal hier im Forum nach 'Europe/Berlin LBS' sucht schwant mir nichts Gutes ;-). Die Leute mit nur einer Stunde Zeitverschiebung merken es vielleicht gar nicht. Bei 12 Stunden ist mir das halt aufgefallen.

[jonofe]

Habe gerade gesehen, dass das Problem eine andere Ursache hat. Da das EXEC Skript des Influx LBS ja eigentlich kein echtes EXEC Skript ist, da es nicht über den LBS sondern über die mysql Procedure getriggert wird, habe ich nicht auf dem LBS Template aufgesetzt. Und somit fehlt am Anfang des EXEC Skripts das

require(dirname(__FILE__) . "/../../../../main/include/php/incl_lbsexec.php"); 

In dem incl_lbsexec.php wird dann auch die config.php included.

Ich werde also das obige require ersetzen und dann die hart codierte Timezone durch die Timezone aus der config.php.
Dann sollte alles gut sein, oder?

Das Logging ergänze ich dann natürlich auch entsprechend.

[dhb2002]

Hi dhb2002

Vermutlich wäre es geschickter die Zeitzone in der php.ini zu setzen, dann sind alle möglichen EXEC-Skripte glücklich, oder?

date.timezone = Pacific/Auckland

Das würde bei deinem LBS ja nichts bringen, da du die Zeitzone bei der Umrechnung explizit auf Europa/Berlin setzt. Der Fehler tritt immer auf wenn die Zeitzone nicht Europa/Berlin ist.

function datetime2utc($datetime, $tz_from = 'Europe/Berlin')
{
$tz_to = 'UTC';
$format = 'Ymd\THis\Z';
$dt = new DateTime($datetime, new DateTimeZone($tz_from));
$dt->setTimeZone(new DateTimeZone($tz_to));
return $dt->format($format);
}

Warum die Config im EXEC script nicht implizit inkludiert ist, ist mir ein Rätsel. gaert hat sich eigentlich hier mal dahingehend geäußert, daß es so sein sollte. Ist es aber eindeutig nicht. Wenn ich im non EXEC Teil ein date_default_timezone_get() in die Logdatei schreibe steht da bei mir Pacific/Auckland, im EXEC dann UTC. Nach einem

require_once '/usr/local/edomi/www/shared/php/config.php';

im EXEC Teil kommt auch Pacific/Auckland zurück. Wenn die config.php schon implizit inkludiert wäre, würde require_once ja nichts machen.

Hi dhb2002
Grundsätzlich hast du Recht. Ich hatte auch genauso begonnen es zu implementieren. Aber irgendwas hat da nicht funktioniert, kann mich leider nicht dran erinnern was es genau war. Deshalb hab ich den Mikrosekunden als Tag in die DB geschrieben, damit sich mehrere Datenpunkte, die in derselben Sekunden generiert werden, nicht überschreiben. Falls du eine lauffähige Version mit Mikrosekunden Timestamp hast, dann bau ich das gerne ein. Dann bräuchte es aber auch ein Skript, welches bestehende Archive migrieren kann. Wichtig ist, dass beim Schreiben der EDOMI Datenarchive Timestamp verwendet wird und nicht der des Schreibvorgangs in die Influx DB.

Ja, muß ich mir noch mal anschauen. Sollte schon gehen. Was das Konvertieren angeht, da gibt es sicher Influx Gurus die mal schnell eine Query herzaubern können. Bin bei Flux nicht der Experte.

[jonofe]

Hi dhb2002

Vermutlich wäre es geschickter die Zeitzone in der php.ini zu setzen, dann sind alle möglichen EXEC-Skripte glücklich, oder?

date.timezone = Pacific/Auckland

Noch eine Frage zu den Timestamps: Du setzt die Präzision auf Sekunden (InfluxDB2\Model\WritePrecision::S) und schreibst dann den Mikrosekundenteil aus der MySQL DB als 'us' tag in die Influx DB. Macht es nicht mehr Sinn, einen UTC Mikrosekunden Timestamp zu errechnen und die Präzision auf Mikrosekunden mit InfluxDB2\Model\WritePrecision::U zu setzen?

Grundsätzlich hast du Recht. Ich hatte auch genauso begonnen es zu implementieren. Aber irgendwas hat da nicht funktioniert, kann mich leider nicht dran erinnern was es genau war. Deshalb hab ich den Mikrosekunden als Tag in die DB geschrieben, damit sich mehrere Datenpunkte, die in derselben Sekunden generiert werden, nicht überschreiben. Falls du eine lauffähige Version mit Mikrosekunden Timestamp hast, dann bau ich das gerne ein. Dann bräuchte es aber auch ein Skript, welches bestehende Archive migrieren kann. Wichtig ist, dass beim Schreiben der EDOMI Datenarchive Timestamp verwendet wird und nicht der des Schreibvorgangs in die Influx DB.

[dhb2002]

Hallo jonofe,

Erst mal vielen Dank für den tollen LBS. Das hat auf Anhieb soweit funktioniert. Allerdings ist mir beim Ansehen der Plots dann aufgefallen, daß es immer nachts bei mir am wärmsten ist 😂
Sah ganz nach einem Zeitzonen Problem aus. Ich habe das bei mir mal korrigiert. Hier ist der Diff:

[root@edomi lbs]# diff -w 19002576_lbs.php 19002576_lbs.php_bak
285d284
<
290d288
< require_once '/usr/local/edomi/www/shared/php/config.php';
319a318
>
336d334
< logging("Local Time (" . date_default_timezone_get() . "): $datetime");
337a336
> logging("UTC Timestamp: $datetimeutc");
341d339
< logging("UTC Timestamp: $timestamp_utc");
453c451
< function datetime2utc($datetime)
---
> function datetime2utc($datetime, $tz_from = 'Europe/Berlin')
457c455
< $dt = new DateTime($datetime);
---
> $dt = new DateTime($datetime, new DateTimeZone($tz_from));
510a509
> date_default_timezone_set("Europe/Berlin");
512c511
< file_put_contents('/usr/local/edomi/www/data/log/CUSTOMLOG_Influx_Data_Archives-EXEC.log', date("Y-m-d H:i:s T") . "\t" . $message . "\n", FILE_APPEND);
---
> file_put_contents('/usr/local/edomi/www/data/log/CUSTOMLOG_Influx_Data_Archives-EXEC.log', date("Y-m-d H:i:s") . "\t" . $message . "\n", FILE_APPEND);

Das Problem betrifft jeden, der nicht in der "Europe/Berlin" Zeitzone ist.

Kommt daher das die Edomi Konfiguration, in der die Zeitzone ja gesetzt wird (
date_default_timezone_set() ), nicht im EXEC Teil des LBS geladen wird. Im normalen LBS geht das wie gewohnt. Ich wusste das bisher auch nicht. Daher denkt PHP es ist in der UTC Zeitzone.

Nach dem Laden von '/usr/local/edomi/www/shared/php/config.php' braucht es keine Klimmzüge mehr zum Zeitzonen hinbiegen. Habe nur noch die Logmessages etwas eindeutiger gemacht und damit stimmt es für mich.

2022-06-22 13:30:08 NZST Local Time (Pacific/Auckland): 2022-06-22 13:30:08
2022-06-22 13:30:08 NZST UTC Time: 20220622T013008Z
2022-06-22 13:30:08 NZST UTC Timestamp: 1655861408
2022-06-22 13:30:08 NZST Writing data to InfluxDB ...
2022-06-22 13:30:08 NZST INSERT : archiveName: Flair 325 Actual Control Value 0-10V, archiveId: 21, us: 571692, value: 0, timestamp_utc: 1655861408
2022-06-22 13:30:08 NZST Writing as FLOAT

Noch eine Frage zu den Timestamps: Du setzt die Präzision auf Sekunden (InfluxDB2\Model\WritePrecision::S) und schreibst dann den Mikrosekundenteil aus der MySQL DB als 'us' tag in die Influx DB. Macht es nicht mehr Sinn, einen UTC Mikrosekunden Timestamp zu errechnen und die Präzision auf Mikrosekunden mit InfluxDB2\Model\WritePrecision::U zu setzen? Der Platz wird in der DB mit dem Tag eh verbraucht. Es wird so aber nie benutzt. Ich denke wenn das Tag wegfällt, kann man sich auch das sperrige 'Group By' in den Queries sparen.