Wenn du keine speziellen Zeitserver in der /etc/systemd/timesyncd.conf einstellen möchtest, dann sollten die Standard-Server reichen.
mit
sudo service systemd-timesyncd status
kannst du prüfen, ob und mit welchem Time-Server synchronisiert wird.
Falls das nicht passt, den Service neu starten
sudo service systemd-timesyncd restart
Es sollte keine Abweichung zur „Normalzeit/korrekten lokalen Zeit“ geben.
Falls du eine Firewall (irgendwo) im Weg hast, dann musst du dafür sorgen, dass die Time-Server erreichbar sind oder einen im lokalen Netz haben und den in der timesyncd.conf einragen.
Hier der Auszug aus „sudo service systemd-timesyncd status“
sudo service systemd-timesyncd status
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
└─disable-with-time-daemon.conf
Active: active (running) since Tue 2018-12-11 20:20:36 CET; 22h ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 10062 (systemd-timesyn)
Status: "Synchronized to time server 37.120.191.245:123 (0.de.pool.ntp.org)."
CGroup: /system.slice/systemd-timesyncd.service
└─10062 /lib/systemd/systemd-timesyncd
Dec 11 20:20:36 raspberry systemd[1]: Starting Network Time Synchronization...
Dec 11 20:20:36 raspberry systemd[1]: Started Network Time Synchronization.
Dec 11 20:20:37 raspberry systemd-timesyncd[10062]: Synchronized to time server 37.120.191.245:123 (0.de.pool.ntp.org).
Und von timedatectl
timedatectl
Local time: Wed 2018-12-12 19:09:13 CET
Universal time: Wed 2018-12-12 18:09:13 UTC
RTC time: n/a
Time zone: Europe/Berlin (CET, +0100)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
Wie ihr seht habe ich den dt Server für die Synchronisation eingetragen
Anbei vielleicht nochmal ein Foto zur Verdeutlichung. (Screenshot über 2 Bildschirme, danach nur die relevanten Elemente ausgeschnitten)
Wie man hier erkennt sind die Zeiten alle nicht 100% gleich. Die von der Windows Uhr wird mit dem Internet über time.windows.com synchronsiert, die vom Pi sollte ja durch meine Einstellungen mit dem deutschen ntp server synchronsiert werden. Wo die Uhrzeit im Webfront herkommt weiß ich nicht.
PS.: Auch jetzt während des Schreibens vom Post wieder. Stundenüberschlag und zak direkt beim nächsten Versuch der automatischen aggregation, wieder Meldungen, dass die aggregation hour nicht geklappt hat. Ich vermute die Meldung für day kommt beim Tageswechsel.
der Window-Zeit-Server ist oft nicht so genau. Wie wäre es, statt seiner ‚pool.ntp.org‘ zu verwenden oder einen Internetzeitserver. Dann hättest Du schon mal die gleichen (oder vergleichbare) Server. Dann sollte die Zeit auch stimmen.
Es klingt so, als würde bei Abschluss der Stunde die entsprechende Aggregation zweimal in die Datei geschrieben werden. Das ist offensichtlich nicht so korrekt. Auf die Schnelle konnte ich hier leider nichts problematisches finden, aber ich schaue mir das noch einmal genauer an.
Ich denke nicht, dass das Problem mit der Exaktheit der Uhr zusammenhängt. Ob der zwei Minuten vor oder nach geht sollte hierfür nicht relevant sein. Probleme mit der Uhr könnte ich mir nur vorstellen, wenn diese zurückgeht, du also zweimal den Sprung von 9:59 auf 10:00 machst.
Kann es denn sein, dass die Aggregation auf verschiedene Zeitstempel schaut? Wenn die eine Uhr eben 1 Minuten später als die andere den Überschlag macht?
Habe jetzt mal denselben Server wie auf dem Raspberry eingstellt „0.de.pool.ntp.org“. Sieht erstmal etwas besser aus. Wobei die Windows Zeit schnell „davon läuft“ nach einigen Minuten sind ~8 sec unterschied da. Wenn man in den Internetzeiteinstellungen von Windows (Windows 7) „Jetzt aktualisieren“ betätigt, wird das delta wieder kleiner. Hab mir die Analoguhr als Widget auf den Desktop gepackt, da sieht man auch ganz gut, dass der Sekundenzeiger wieder zurückspringt.
Ich konnte mich nach mehreren Tagen mal wieder damit beschäftigen. Mittlerweile ist die Zeit im Webfront und am Windows System ziemlich gleich (3 sec unterschied). Auch im Pi ist die Differenz nicht mehr so groß. Zwischen dem Webfront und dem Pi liegen noch 20 sec. Differenz. Aggregation Fehler kommen immer noch…
Konntet ihr mittlerweile was herausfinden? Das Zeitproblem ansich habe ich anscheinen in den Griff bekommen. Hab am PC mal die Batterie ausgetauscht und nun ist der Zeitunterschied so gut wie verschwunden. (~ noch 2 sec zwischen Raspberry und dem Windows 7 System).
Das Aggregationsproblem besteht aber weiterhin. Wie wird die Aggregation denn genau durchgeführt? Wenn die Stunde komplett abgelaufen ist also z.B. von 16:00 bis 16:59, wird der Prozess für die „aggregation hour“ gestartet nehme ich an. Was genau bzw. welcher Zeitstempel sollte dann als nächstes in die entsprechende Datei geschrieben werden? Bei mir taucht nach 17 Uhr hier z.B. der Eintrag mit 16 Uhr und entsprechenden Werten auf, woraufhin die Fehlermeldung sagt „erwartet 17 Uhr, gefunden 16 Uhr“. Ist das so gewollt?
Nachdem ich nun knapp 1 Jahr keine Probleme mehr hatte, tauchen seit einigen Wochen immer wieder die Meldungen für mehrere Variablen im Monitor auf:
03.01.2020 17:12:53 | Archive Control | Invalid data for aggregation day for VariableID #50330. Expected: 1578006000, Found: 1577919600
Eine manuelle Aggregation löst das Problem temporär, nach einigen Stunden erscheinen sie aber wieder.
Ich habe vor einigen Wochen angefangen eine handvoll (vielleicht 12 Stk) Bool-Variablen zu loggen, Bewegungsmelder-Signale und Schaltsignale von den Heizkreisverteilern.
Auf den ersten Blick sieht es so aus, als wenn er den Tag doppelt in die Aggregation einträgt. Kannst du mir mal eine *.day.csv vor einer Variablen vor der Reaggregation schicken? Dann prüfe ich das gerne genauer.
Spinnt vielleicht die Uhr auf deinem System irgendwie rum? Kannst du testweise mal ein Ereignis erstellt, dass jeden Tag um 0:00 Uhr eine Variable hochzählt? Wird dieses mehrfach ausgelöst?
Passiert das bei dir eigentlich jeden Tag oder „nur“ gelegentlich?
Also die Zeit auf dem Raspberry stimmt exakt mit der vom PC überein. Ich hab beim letzten mal einige Variablen gelöscht, bzw. das logging ausgeschaltet, die Dateien davon gelöscht und neu angefangen zu loggen, dann war das Problem behoben. Was aber natürlich auch nicht so Sinn der Sache ist.
Ich habe mal Testweise eine Integer Variable erstellt, mit einem Ereignis, welches die Variable täglich um 00:00:00 + 1 zählt. Mal sehen was dabei rauskommt. Nein es passiert wieder täglich.
Noch eine andere, ich hoffe nicht zu dämliche Frage :D… Ich habe im Objektbaum unter Kern Instanzen einmal das Archive vom Typ ArchiveControl und einmal ArchiveControl vom Typ ArchivControl. Ist das normal? Kommt sich da vielleicht was in die quere?
aus. Lösche dann das Archiv mit der zweiten angezeigten ID. Das erste sollte für die Einstellungen verwendet werden und hat gespeichert, welche Variablen geloggt werden etc. . Ganz vielleicht kann es passieren, dass manche Variablen nicht mehr geloggt werden, die Daten gehen dabei aber nicht verloren. Schau also am besten mal durchs WebFront, ob bei deinen Variablen weiterhin der Graph bereitsteht.
In der webbasierten Konsole wird für alle Aktionen das erste Archiv verwendet, ich weiß nicht, wie es in der Legacy-Konsole implementiert ist. Deine Schlussfolgerung klingt allerdings logisch.
Ich würde auf jeden Fall ein Backup machen bevor du das Archiv löschst, damit du dir nicht aus Versehen etwas kaputt machst. Lösche also das mit der 26770 und schaue mal, ob noch alles so läuft wie vorher. Wenn ja ist alles gut, wenn nein, dann Backup wieder einspielen und hier melden
So ich bin mal dazu gekommen das auszuprobieren. Es funktionierte leider nicht :).
Ich hab das Archive mit 26770 gelöscht, bekomme aber nun im WF angezeigt
„Cannot find archive“. Kann ich das noch vorhandene Archive irgendwie als aktiv setzen?
