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.
Wo könnte das Problem liegen?
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.
Hallo Niels,
hab dir eine Mail mit einer .csv geschickt. Die Werte werden tatsächlich doppelt geloggt, warum auch immer 
Danke für deine Hilfe
VG
Marcel
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?
Vielleicht synchronisiert sich der PC mit einem Zeitserver zu dem Zeitpunkt und springt dann wieder leicht zurück.
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?
Die zwei Archive werden wohl das Problem sein. Führe mal das Skript
var_dump(IPS_GetInstanceListByModuleID('{43192F0B-135B-4CE7-A0A7-1475603F3060}'));
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.
Ok ich hab es befürchtet.
Jetzt nochmal zum Verständnis. Diese Ausgabe bekomme ich:
array(2)
[0]=>
int(26770)
[1]=>
int(50306)
}
Das Archive mit der ID 50306 zeigt allerdings die Daten im Objektbaum an
{
Wenn ich jetzt das Archive mit der ID 26770 lösche, lösche ich das, welches keine Daten loggt oder ?
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?
So etwas gibt es eigentlich nicht. Hast du das Archiv vielleicht in irgendwelchen Skripten hart reingecodet? Suche die ID mal in allen Skripten. Gibt es alternativ vielleicht Module, in denen die das Archiv ausgewählt hast? Suche sonst auch mal in deiner settings.json nach der ID.
Grande katastrophe :eek:
Also erstmal zu den Fragen. Ja ich habe die Archiv-ID in den Skripten Hardcodiert. Sollte ich vielleicht mal anpassen 
Was mir aber mehr sorgen bereitet ist die settings.json. Wie auf den Anhängen zu sehen ist, gibt es da natürlich beide IDs. Hinter einer ID sind ein Teil der Variablen-IDs aufgeführt die ich logge, hinter dem anderen andere IDs aber teilweise auch dieselben
In der letzten Grafik habe ich mal ein paar der geloggden IDs gesucht und es zeigte sich das diese teilweise im Archive 50306 (Zeile 216) und teilweise im Archiv 26770 auftauchen. Einige auch in beiden.
Was würde passieren, wenn ich mir den Ordner var/lib/symcon/db zur Sicherung vom Raspberry ziehe, beide Archive lösche und eins neu anlege? Kann ich die gesicherten Daten wieder einfach einfügen?
Du musst die db gar nicht rausziehen. In den Einstellungen des Archivs wird „nur“ definiert welche Variable wie geloggt wird, nicht die Archivdaten selbst.Wenn du also diese Einstellungen durch das eine Archiv verlierst, kannst du das Logging bei diesen Variablen wieder aktivieren. Deine Archivdaten sind also auf jeden Fall sicher beim Rumspielen mit den Archiven, solange du sie nicht explizit löschst. Wenn du in der settings.json lesen kannst, kannst du ja die aufgelisteten Variablen nach dem Löschen des Archivs manuell oder via Skript durchgehen.
Ich glaube ich habs hinbekommen:o
Ich habe zuerst das 2. Archiv gelöscht. Danach waren in der Konsole im 1. Archiv alle Variablen grau hinterlegt. Nachdem ich dann für jede wieder das logging eingeschaltet hatte, wurden nach einer kompletten Reaggregation wieder alle Daten angezeigt. Und im WF sieht es bisher auch aus, als wenn alles sichtbar ist.
Danke euch :o 