Diese Seite erklärt, warum eine korrekt eingestellte Systemzeit auf dem Raspberry Pi so wichtig ist, was bei einer falschen oder springenden Uhrzeit in der EmonCMS-Datenbank passiert, und wie sich das beim Aufbau an einem neuen Standort (z. B. Messestand, Kongress, andere Schule) zuverlässig vermeiden lässt. Siehe auch RTC-Nachrüstung und Hauptanleitung.
EmonCMS speichert Messwerte in PHPFina-Feeds an einer festen Position, die direkt aus dem Zeitstempel berechnet wird:
Position im Feed = (Zeitstempel - Feed-Startzeit) / Feed-Intervall
Jeder Messwert landet also nicht „irgendwo“, sondern exakt an der Stelle, die seiner Systemzeit zum Sendezeitpunkt entspricht. Stimmt diese Zeit nicht, stimmt auch die gespeicherte Position nicht – unabhängig davon, ob der eigentliche Messwert (Temperatur, CO2 usw.) korrekt war.
Wichtig: Diese Effekte lassen sich mit den EmonCMS-Standardwerkzeugen NICHT rückwirkend sauber korrigieren. Eine nachträgliche Bereinigung wäre nur mit direktem Zugriff auf die PHPFina-Rohdateien möglich und für den Alltagsbetrieb kaum den Aufwand wert. Für einen Messestand oder eine kurze Präsentation ist das meist unkritisch - ab dem Korrekturzeitpunkt läuft alles wieder sauber weiter.
Das emonSD-Image (siehe Hauptanleitung, Teil 2) kommt aus Großbritannien und ist standardmäßig auf Europe/London (BST, UTC+1) eingestellt – nicht auf Europe/Berlin (CEST, UTC+2). Wird die Uhrzeit gesetzt, ohne vorher die Zeitzone zu korrigieren, ergibt sich ein fester Versatz von 1 Stunde. Details und Lösung siehe RTC-Seite, Stolpersteine.
Eine nachgerüstete RTC (siehe HW-111-Anleitung) sorgt dafür, dass die einmal korrekt gesetzte Uhrzeit auch Neustarts und Stromausfälle übersteht – ohne RTC würde die Zeit sonst bei jedem Neustart auf einen Werksstand zurückfallen.
Wichtig: Die RTC schützt NICHT automatisch vor einer falsch eingestellten Zeitzone oder einer einmalig falsch eingegebenen Uhrzeit - sie speichert zuverlässig genau das, was ihr beim "hwclock -w" mitgegeben wurde. Eine falsche Ersteinrichtung wird also ebenso zuverlässig "eingefroren" wie eine richtige.
Besonders relevant bei einem mobilen Einsatz (Messestand, Kongress, Vorführung an einer anderen Schule), wo das System ggf. neu gestartet oder erstmals in Betrieb genommen wird:
date timedatectl
sudo timedatectl set-timezone Europe/Berlin
sudo date -s "JJJJ-MM-TT HH:MM:SS"
sudo hwclock -w
date sollte „CEST“ (nicht „BST“) und die korrekte Uhrzeit zeigenFalls am jeweiligen Standort Internetzugang verfügbar ist, ist die Zeit alternativ auch automatisch per NTP synchronisierbar, statt sie manuell zu setzen - das isolierte Messnetz-Konzept (siehe Hauptanleitung, Teil 1) sieht im Dauerbetrieb zwar bewusst kein Internet vor, für eine kurzzeitige Erstsynchronisation an einem Standort mit Internet ist das aber ebenfalls eine Option.
Keine Panik – wie oben beschrieben, betrifft das nur den Zeitraum zwischen der fehlerhaften Inbetriebnahme und der Korrektur. Ab dem Moment der Korrektur läuft die Aufzeichnung wieder sauber und durchgehend weiter. Für die Praxis (Vorführung, Messestand, kurzer Testlauf) ist das in aller Regel unproblematisch – für eine langfristige, wissenschaftlich auswertbare Zeitreihe (z. B. den festen Schulaufbau) lohnt sich dagegen, die Checkliste oben schon bei der Ersteinrichtung einmal sorgfältig durchzugehen.