Moin,
gerade habe ich eine ganze Weile gebraucht, um hinter das Geheimnis dieser Fehlermeldung zu kommen:
Error - Wrong time limits. The <nn> (days newer than) option must be greater than the <no> (older than) one !
Der Fehler tritt auf bei "set dbRep1 delEntries" mit folgender Konfiguration:
defmod dbRep1 DbRep fhemLog
attr dbRep1 allowDeletion 1
attr dbRep1 timeOlderThan d:3
Ändere ich das Attribut timeOlderThan in "d:3 FullDay" funktioniert alles fehlerfrei.
Wenn man es weiß, ist es nicht schlimm, aber richtig scheint es mir trotzdem nicht zu sein :)
Da hast du Recht. :)
Schaue ich mir an. Danke für die Info.
LG
Hinweis: d:3 h:1 endet mit der gleichen Fehlermeldung.
Keine Ahnung, ob es einen Zusammenhang gibt: countEntries history liefert bei mir aktuell auch kein Ergebnis (zumindest aber keine Fehlermeldung).
ein set ... count direkt im DbLog device liefert knapp 1500 Einträge, was mit der manuellen Abfrage in sqlite3 übereinstimmt.
Edit: wenn ich das Attribut timeOlderThan lösche, werden auch wieder Einträge gezählt. Vermutlich hatte ich nur nicht verinnerlicht, dass das Attribut sich auch auf das Zählen auswirken könnte.
Guten Morgen,
ich habe eine Wiele versucht den Fehler nachzustellen und es ist mir bisher nicht gelungen.
Aber ich habe eine Vermutung.
Hier eine verbose 4 Ausgabe meines Testes:
2023.09.17 09:17:29.604 4: DbRep Rep.LogDB.All - -------- New selection ---------
2023.09.17 09:17:29.605 4: DbRep Rep.LogDB.All - Command: delEntries
2023.09.17 09:17:29.606 4: DbRep Rep.LogDB.All - timeOlderThan - year: , day: 3, hour: , min: , sec:
2023.09.17 09:17:29.607 4: DbRep Rep.LogDB.All - startMonth: 4 endMonth: 8 lastleapyear: baseYear: 2023 diffdaylight:1 isdaylight:1
2023.09.17 09:17:29.608 4: DbRep Rep.LogDB.All - FullDay option: 0
2023.09.17 09:17:29.608 4: DbRep Rep.LogDB.All - Timestamp begin human readable: 2023-05-25 21:50:57
2023.09.17 09:17:29.609 4: DbRep Rep.LogDB.All - Time difference to current time for calculating Timestamp end: 259201 sec
2023.09.17 09:17:29.610 4: DbRep Rep.LogDB.All - Timestamp end human readable: 2023-09-14 09:17:28
2023.09.17 09:17:29.630 4: DbRep Rep.LogDB.All - Database connect - user: fhemtest, UTF-8 option set: yes
2023.09.17 09:17:29.637 4: DbRep Rep.LogDB.All - SQL execute: SHOW VARIABLES LIKE 'collation_database'
2023.09.17 09:17:29.639 4: DbRep Rep.LogDB.All - Database Character set is >utf8mb4_bin<
2023.09.17 09:17:29.640 4: DbRep Rep.LogDB.All - simple do statement: set names "utf8mb4" collate "utf8mb4_bin"
2023.09.17 09:17:29.670 4: DbRep Rep.LogDB.All - SQL execute: delete FROM history where TIMESTAMP >= '2023-05-25 21:50:57' AND TIMESTAMP <= '2023-09-14 09:17:28' ;
2023.09.17 09:42:09.427 3: DbRep Rep.LogDB.All - Entries of fhemtest.history deleted: /--/--19051460
Dabei ist "Timestamp begin human readable: 2023-05-25 21:50:57" der älteste Datensatz in der DB.
Er wird automatisch ermittelt.
Wenn schon Daten gelöscht wurden und somit der älteste noch in der DB befindliche Datensatz neuer ist als der Timestamp der sich aus der Angabe von "timeOlderThan d:3" ergibt, kann diese Ausschrift kommen.
Die Fehlermitteilung ist dann irreführend und für den User nicht hilfreich. Das kann ich abändern.
Vorher möchte ich meine These nochmal überprüfen.
Kannst du bitte auch ein verbose 4 Log zum Vergleich anfertigen?
Den Timestamp des ältesten in der DB befindlichen Datensatz kann man explizit mit
get ... minTimestamp
ermitteln und anzeigen.
timestamp_oldest_dataset 2023-09-15 00:04:59
023.09.17 10:32:58 3: DbRep dbRep1 - get initial structure information of database "/opt/sqldb/fhemLog.db", remaining attempts: 3
2023.09.17 10:32:58 3: DbRep dbRep1 - Connectiontest to database SQLite:dbname=/opt/sqldb/fhemLog.db with user
2023.09.17 10:32:58 4: DbRep dbRep1 - Database connect - user: no, UTF-8 option set: no
2023.09.17 10:32:58 4: DbRep dbRep1 - Oldest timestamp determined: 2023-09-15 00:04:59
2023.09.17 10:32:58 4: DbRep dbRep1 - Encoding of database determined: UTF-8
2023.09.17 10:32:58 3: DbRep dbRep1 - Index Report_Idx exists. Check ok
2023.09.17 10:32:58 3: DbRep dbRep1 - Initial data information retrieved - total time used: 0.0865 seconds
2023.09.17 10:32:58 3: DbRep dbRep1 - Connectiontest to db SQLite:dbname=/opt/sqldb/fhemLog.db successful
2023.09.17 10:32:58 4: DbRep dbRep1 - -------- New selection ---------
2023.09.17 10:32:58 4: DbRep dbRep1 - Command: delEntries
2023.09.17 10:32:58 4: DbRep dbRep1 - timeOlderThan - year: , day: 3, hour: , min: , sec:
2023.09.17 10:32:58 4: DbRep dbRep1 - startMonth: 8 endMonth: 8 lastleapyear: baseYear: 2023 diffdaylight:1 isdaylight:1
2023.09.17 10:32:58 4: DbRep dbRep1 - FullDay option: 0
2023.09.17 10:32:58 4: DbRep dbRep1 - Timestamp begin human readable: 2023-09-15 00:04:59
2023.09.17 10:32:58 4: DbRep dbRep1 - Time difference to current time for calculating Timestamp end: 259201 sec
2023.09.17 10:32:58 4: DbRep dbRep1 - Timestamp end human readable: 2023-09-14 10:32:57
Danke dir. Das bestätigt meine Vermutung.
Inzwischen konnte ich diesen Zustand auch bei mir durch bewusstes Setzen der Zeitgrenzen gegenüber minTimestamp provozieren.
Ich passe im Modul die Meldung an damit in diesem speziellen Fall eine für den User hilfreiche Statusmeldung generiert wird.
das heißt also, diese (inhaltlich unpassende) Meldung ist lediglich der Hinweis darauf, dass es innerhalb des angegebenen Zeitrahmens nichts zu Löschen gab?
Im Prinzip ja. Es ist allerdings meiner ungenügenden Prüfungssteuerung geschuldet.
Man kann ja bei bestimmten Funktionen direkt die Aufrufoption "<no>[:<nn>]" mitgeben.
Deswegen prüfe ich bei diesen Funktionen sinnvoll gesetzte Grenzen, die sich auch aus den time.*-Attributen ableiten können.
In dem vorliegenden Fall wird das (nicht explizit) gesetzte 'nn'-Limit durch "minTimestamp" substituiert was bei der speziellen Situation des zu neuen minTimestamp die Prüfung anschalgen lässt.
Jetzt wird in diesem Fall kommen:
"The oldest record in the database is newer than the specified time limit (time.*-attribute or 'no'-option). It makes no sense to execute the function"
Das sollte dem User Hinweis genug sein denke ich.
Ok.
Manchmal finde ich Deine Meldungen einfach zu lang.
Ein einfaches "No data found in specified time range." sollte m.E. völlig reichen. Niemand möchte einen halben Roman lesen müssen 😀
:D ... meine Schwäche. ;)
So machen wir das.
Werde das Modul im Laufe des Tages einchecken und dann morgen früh für alle im Update.