Wieso UTC?
Die UTC (Coordinated Universal Time) wird in myDatanet als grundlegende Zeitzone verwendet. Das gilt sowohl für den Server selbst, als auch für alle mit dem Server kommunizierenden Datenlogger.
Der Grund dahinter ist einfach erklärt: Alle auf der Welt verfügbaren Zeitzonen basieren auf UTC. Alle lokalen Uhrzeiten lassen sich unter Angabe der Zeitzone und der zusätzlichen Angabe von Sommer- und Winterzeit berechnen.
In die umgekehrte Richtung ist dies nicht zu jeder Sekunde des Jahres möglich. Bei der mitteleuropäischen Sommerzeit gibt es an jedem letzten Sonntag im Oktober die Umstellung von UTC+2 (Sommerzeit) auf UTC+1 (Normalzeit, “Winterzeit”). Gemeinhin wird die Zeit von 03:00 Uhr auf 02:00 Uhr “zurück gestellt”, also existiert die Stunde von 02:00 Uhr bis 03:00 Uhr zwei Mal hintereinander. Technisch wäre die Speicherung in lokaler Zeit nicht bzw. nur mit nicht rechtfertigbarer Komplexität machbar.
So läuft das mit der Zeit in myDatanet
Im myDatanet-Ökosystem können Zeitstempel in einem Raster von 1/256 Sekunden gespeichert bzw. erfasst werden. Es ist also nicht möglich, zu jeder einzelnen Millisekunde Datensätze zu erfassen. Die Zeitstempel haben immer einen Abstand von 1/256 Sekunden, das entspricht genau 3,90625 Millisekunden. Dieser Wert wird systemintern immer auf ganze Millisekunden gerundet. Daher ergeben sich hier Abstände von 3 oder 4 Millisekunden, je nachdem welcher exakte Wert gerade verwendet wird.
Woher bekommt der Server die aktuelle Zeit?
Das aktuelle Datum und die Uhrzeit werden vom myDatanet-Server direkt vom unterliegenden Betriebssystem bezogen. Die Aktualisierung der Uhrzeit auf dem Betriebssystem kann einerseits durch das Betriebssystem selbst (falls konfiguriert) oder durch myDatanet (einstellbar, Synchronisierung mit öffentlichen Zeitservern über NTP) übernommen werden.
Synchronisierung mit Datenloggern
Beim Aufbau der Verbindung von einem Gerät zum Server wird der aktuelle Zeitstempel (UTC) vom Server zum Gerät übertragen. Das Gerät übernimmt den übermittelten Zeitstempel als neue Zeit. Falls die Zeit im Gerät um mehr als 5 Sekunden korrigiert wird, wird ein entsprechender Eintrag in das Geräte-Log geschrieben.
Die lokale Zeit im Gerät
Jedes Gerät erhält vom Server auch die Information darüber, in welcher Zeitzone es tatsächlich arbeitet. Welche Zeitzone dabei zum Einsatz kommt, wird in dieser Reihenfolge ermittelt: Site -> Kunde -> Server. Ist keine spezifische Einstellung in der Site getätigt worden, so werden die Einstellungen des Kunden übernommen. Ist auch dort keine spezifische Einstellung vorhanden, werden die Einstellungen des Servers übernommen.
Beispiel: Bei der Verwendung von Tageszählern ist es wichtig, den Zähler zum korrekten Zeitpunkt zurückzusetzen. Dafür muss die eingestellte Uhrzeit zur Rücksetzung am Gerät auch korrekt interpretiert werden können. Die Speicherung der aufgezeichneten Daten erfolgt aber weiterhin in UTC.
Konfigurationen und historische Datensätze
Die Synchronisation der Datenlogger mit dem Server wird primär über Zeitstempel gesteuert. Zu Beginn jeder Verbindung meldet das Gerät dem Server den aktuellen Zeitstempel (bei “Single”-Datensätzen wie z. B. Konfigurationen) bzw. den neuesten Zeitstempel (bei historischen Datenströmen) für jeden einzelnen Datenblock bzw. historischen Datenstrom.
Zusätzlich wird berücksichtigt, in welche Richtung Konfigurationen synchronisiert werden dürfen. Bei IoT-Apps kann dies durch den Entwickler der Applikation definiert werden. Es macht Sinn, Einstellungen ausschließlich in eine Richtung synchronisieren zu lassen, z. B. “config2” nur Upload, “config3” nur Download. Damit kann allfälligen Diskrepanzen schon zum Zeitpunkt der Entwicklung vorgebeugt werden.
Ist der Zeitstempel am Gerät neuer, so fordert der Server die neuen Daten vom Gerät an. Ist der Zeitstempel am Server neuer, so sendet der Server den veränderten Datensatz an das Gerät.
Synchronisation von Dateien (Files)
Die Synchronisation von Dateien erfolgt nach einem ähnlichen Muster wie die Konfigurationen. Wenn eine Datei in beide Richtungen transferiert werden kann, so wird immer die Version mit dem älteren Zeitstempel überschrieben.
Die Synchronisationslogik von Dateien beinhaltet jedoch noch weitere Kriterien, die vor dem Zeitstempel zum Zug kommen. Abhängig vom Design der jeweiligen Applikation findet eine Übertragung von Dateien meist nur unidirektional oder gar nicht statt.
Es wird empfohlen, Dateien zwischen Up- und Download zu trennen und die gleiche Datei nicht in beide Richtungen übertragen zu lassen.
Benutzereinstellungen
Die Darstellung von Uhrzeiten kann am Server auf mehreren Ebenen konfiguriert werden. Die Einstellungen werden in folgender Reihenfolge abgehandelt: Benutzer -> Site -> Kunde -> Server.
Benutzerebene
Wenn die Lokalisierungseinstellungen auf Benutzerebene abgeändert werden, dann werden alle Zeitstempel am Server in dieser Zeitzone angezeigt, unabhängig von den sonstigen Einstellungen bei Site, Kunden oder Server.
Siteebene
Kundenebene
Serverebene
Server-Administratoren können die Standard-Einstellungen für die Darstellung von Zeitstempeln am Server festlegen.
Praxis in der REST API
Die Zeitstempel die von der REST API ausgegeben bzw. als Parameter entgegen genommen werden, werden immer in der Standardzeit UTC gehandelt, außer es ist explizit in der einzelnen Ressource anders beschrieben.
Die Verwendung von lokaler Zeit ist jedoch in der REST API selten anzutreffen und wird nur eingesetzt, wenn ein Bezug zur lokalen Zeit notwendig wird. Ein Beispiel dazu ist die verdichtete Ausgabe von Messwerten, die in Tagesintervallen oder noch größeren Intervallen ausgegeben werden. Die Berechnung von Werten wie Minimum, Maximum, Durchschnitt, etc. macht dabei nur Sinn, wenn man die Daten in der lokalen Uhrzeit betrachtet. Das Gleiche gilt für Tagessummen, die üblicherweise zu Mitternacht der lokalen Zeitzone zurückgesetzt werden.
