dbLog localized Timestamp

[msonst]

Hi,

in unterschiedlichsten Threads (z.B. https://forum.fhem.de/index.php?topic=91608.0) habe ich nun über ein Problem gelesen, das auch mich gerade beschäftigt. Anscheinend gibt es nur Workarounds diesbezüglich.

Problem:
FHEM loggd via dbLog Einträge mit einem Zeitstempel, der der lokalen Zeit/Zeitzone des Systems entspricht.
In der DB stehen nun Timestamps, die sich nicht mehr einer Zeitzone zuordnen lassen.
Drittsysteme wie Grafana erwarten von der Datenquelle UTC, um basierend auf der Zeitzone des Nutzers die Zeit korrekt darstellen zu können.
Wird nun der Timestamp als UTC interpretiert und lokalisiert, kommt es zu einer Verschiebung der aufgenommenen Datenpunkte.

Ähnliche Probleme sind mir von DCS und SCADA Systemen bekannt.
Hier gilt das ungeschriebene Gesetz, dass Archive immer UTC beinhalten sollen.

Mir stellt sich nun die Frage, was gegen eine Konvertierung nach UTC vor dem Schreiben spricht (einstellbar über ein Attribut).

Speziell folgende Stelle scheint mir interessant, bin aber kein Perl Experte und würde mich zunächst über Input freuen:
93_DbLog.pm

Code Auswählen Erweitern


[1362] DbLog_Log ...
  eval { 
      for (my $i = 0; $i < $max; $i++) {
          my $next = 0;
          my $event = $events->[$i];
          $event = "" if(!defined($event));
          $event = DbLog_charfilter($event) if(AttrVal($name, "useCharfilter",0));
          Log3 $name, 4, "DbLog $name -> check Device: $dev_name , Event: $event" if($vb4show && !$hash->{HELPER}{".RUNNING_PID"}); 
     
          if($dev_name =~ m/^$re$/ || "$dev_name:$event" =~ m/^$re$/ || $DbLogSelectionMode eq 'Include') {
              my $timestamp = $ts_0;
              $timestamp = $dev_hash->{CHANGETIME}[$i] if(defined($dev_hash->{CHANGETIME}[$i]));
>> convert to UTC
              $timestamp = DbLog_ConvertTimeZone($timestamp);
<< convert to UTC
              $event =~ s/\|/_ESC_/g;    # escape Pipe "|"


Daher meine Frage an Entwickler, die schon länger am System arbeiten:

• 
  Was spricht dagegen?
  
• Werden die Daten irgendwo wieder zurück ins System gelesen und könnten Probleme verursachen?

Danke Michael

[betateilchen]

Werden die Daten irgendwo wieder zurück ins System gelesen

z.B. für die grafische Darstellung von Plots in FHEM mit Hilfe des Moduls SVG.

[DS_Starter]

Hallo Michael,

    Was spricht dagegen?
    Werden die Daten irgendwo wieder zurück ins System gelesen und könnten Probleme verursachen?

Im Prinzip spräche meiner Meinung nach nichts dagegen, allerdings nicht als Insellösung in DbLog, sondern als globale Einstellungsmöglichkeit in FHEM.
DbLog ist ja auch nur ein Eventhandler wie FileLog und andere. In meinem Modul 93_Log2SysLog habe ich bereits eine Konvertierung nach UTC eingebaut, weil externe Syslogserver dies (meist einstellbar) so erwarten.

Innerhalb von FHEM sollten m.M. nach aber die Zeitstempel zwischen den diversen Eventhandlern nicht auseinanderdriften.
Stell dir vor ein User loggt mit Filelog und DbLog Daten deren Darstellung in SVG-Grafen plötzlich zueinander verschoben sind und nicht mehr korrelieren.

Ausgewertet werden die Daten natürlich im System ... SVG (betateilchen hat es schon erwähnt), DbRep, Grafana um nur einige zu nennen. Manche User nutzen die Einträge in der DB um diverse Zustände von Devices nach einem Restart wieder auf einen zeitlich definierten Wert zu stellen.

Also ich persönliche hätte nichts gegen deinen Vorschlag der zuschaltbaren !! UTC Konvertierung einzuwenden, aber nicht als DbLog Insellösung sondern als generelle Systemeinstellung.

Das Thema ist sicherlich hier im Anfängerbereich schlecht angesiedelt.
Du könntest es nach Sonstiges verschieben (Taste unten links).

Grüße,
Heiko

[msonst]

Hi,

danke für Eure Antworten.
Der Gedanke war möglichst nicht dutzende Stellen im System anfassen zu müssen, sondern nur Uebergaenge zu anderen Systemen. Zumindest denke ich nicht, dass ich dies in dem Fall erledigen könnte

Es gibt nicht zufällig eine Art Dispatcher, durch den alle Events laufen und man dort zentral das Thema für read (from DB, file.etc) und write (to DB, file.etc) erledigen könnte?

Danke
Michael

[DS_Starter]

Es gibt nicht zufällig eine Art Dispatcher, durch den alle Events laufen...

Der Gedanken _eines_ "Dispatchers" trifft es nicht.
Jedes Modul/Device, welches über Events informiert werden möchte um diese Events in irgendeiner Weise auszuwerten, kann sich in diese Informationskette einklinken.
Der FHEM-Kern (fhem.pl) enthält die dafür nötigen Werkzeuge und Mechanismen.

Wenn du dir z.B. ein Notify Device erstellst, ist dieses Device auch Teil dieser Kette und du kannst auswerten was an Events erstellt wird.
Wer weiß welche der vielen Module diesen Mechanismus nutzen, DbLog, Filelog, notify sind nur die vermutlich prominenten Vertreter solcher Eventhandler.

Der andere Weg, also Lesen der Informationen, ist aber modulspezifisch implementiert. SVG liest z.B. aus Filelog und DbLog. Sonst nichts.

[xenos1984]

z.B. für die grafische Darstellung von Plots in FHEM mit Hilfe des Moduls SVG.

...was dann dazu führt, dass am Tag der Zeitumstellung der Plot um eine Stunde vor oder zurück springt. Da hätte UTC vielleicht auch einen Vorteil, wenn die lokale Zeit nur auf Achse stünde, aber die Daten in UTC wären. Also wenn die Achse nach einem solchen Schema eingeteilt wäre:

0:00 | 1:00 | 2:00 | 3:00 (MESZ) = 2:00 (MEZ) | 3:00 ...

0:00 | 1:00 | 2:00 (MEZ) = 3:00 (MESZ) | 4:00 ...

[Florian_GT]

Ich habe leider auch gerade das gleiche Problem. Und wenn ich Grafana dann bei der Suche die Zeitzone entsprechend einberechnen lasse habe ich so massig Performanceverlust auf der Datenbank dass das ganze einfach unschön ist. Eine Möglichkeit, zumindest die Zeitzone beim Loggen in die Datenbank einzustellen wäre echt super.

[DS_Starter]

Ich habe mich mal hingesetzt und ein kleines Modul im update vom 10.03. bereitgestellt mit dem man die Konvertierung eines Zeitstrings in beliebige Zeitzonen (bzw. UTC) ausführen kann.
Die Funktionen des Moduls können Autoren in Module einbinden bzw. User auch in ihren eigenen Routinen in der 99_myUtils.pm benutzen.
Ich habe es im Wiki beschrieben:

https://wiki.fhem.de/wiki/Modul_ConvertTimeZone_(CTZ)

Momentan habe ich selbst die Funktionen noch nicht in z.B. DbLog eingebunden, will es aber demnächst mal ausprobieren.
Wer mag, kann sich selbst mal daran versuchen.

LG

[DS_Starter]

In meinem contrib liegt jetzt eine dblog Version zum Test des UTC Umwandlung.
Es gibt zum Einschalten der Umwandlung ein Attribut:

convertTimezone

    attr <device> convertTimezone [UTC | none]
    UTC - der lokale Timestamp des Events wird nach UTC konvertiert.
    (default: none)

Wer es mal testen möchte -> zum Download in der FHEMWEB Kommandozeile inklusive der Anführungszeichen angeben und danach FHEM restarten:

Code Auswählen Erweitern


"wget -qO ./FHEM/93_DbLog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbLog.pm"


Denkt daran ein aktuelles FHEM zu haben damit die aktuellste CTZ.pm verfügbar ist.

[DS_Starter]

Hat denn mal jemand das Feature bei seiner Installation ausprobiert ?
Der eine oder andere hatte ja eine solche Möglichkeit vermisst ....

[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