Wird frei gehalten für die gesammelten Optimierungsideen.
Um den eigentlichen Entwicklungsthread der aktuellen Version weder übersichtlicher zu bekommen, wurde sich auf diesen neuen Thread zur Zusammenfassung
von Optimierungsideen geeinigt.
Die meisten dieser Ideen bisher stammen aus dem Entwicklungsthread, weitere bitte einfach wie gewohnt im Thread anhängen oder besprechen.
Hinweis: Die Liste ist (bisher) unbewertet. (Fett markierte sind in neueren Versionen des Moduls gelöst.).
#01 Lokales Zwischenspeichern von Einträgen bei nicht-erreichbarkeit der DB (@Heiko)
#02 Ausgeben auch der Memcache-Datensätze bei Plotanfragen
#03 "insert into history" ersetzen durch "insert ignore into history" zur Unterstützung eines PK-Indexes erledigt in #50, #119 für alle DB's
#04 "insert into current" ersetzen durch "insert ignore into current" um die zwei (insert und update)-Befehle zu einem zusammenzufassen erledigt in #50
#05 den Index der Datenbank zu einem PK ändern, und doppelte Einträge verhindern wird am #50 unterstützt
#06 den Index von DbLog und DbRep zusammelgen
#07 "set .... deleteOldDays <n> EXCLUDE=..." ergänzen
#08 Direktes "addLog" in die Datenbank statt über Trigger fixed
#09 ist ASCI ausreichend oder wird Unicode benötigt? -> RPI Optimierung Zwischen ASCI und UTF8 kann der Anwender wechseln, ohne Änderung in DbLog. Die Performance bei ASCI ist ca. doppelt so schnell unter MySQL.
#10 noTransaction-Modus: Verzicht auf Transaktionen zur Reduzierung von Overhead; sollte bei LOGS keinen Vorteil ergeben, ein Rollback macht keinen Sinn.
#11 NonBlocking der DB für Bereinigungen (nonBlocking (Version im Kommentar 119)
#12 Prüfung der wichtigsten DB-Parameter
#13 Blockieren von Plots während die DB gelockt ist (zB durch Backup, ...)
#14 verhindern von commitCache während die DB gelockt ist
#15 Updateoption für die DB für alle, die noch nach "altem Schema" angelegt wurden.
#16 einene SplitRoutinen analog zu userReadings für Devices, deren Module die Splitfunktion von DbLog noch nicht unterstützen. über attr valueFn gelöst.
#17 "markieren" von zu löschenden Datensätzen als "Dry run" vor dem tatsächlichen löschen.
#18 Integrieren einer Importfunktion für die Übernahme von FileLog-Logs, um den Umstieg auf DbLog zu vereinfachen (@DeeSPe, ...) wird in externem Modul realisiert
#19 Integrieren eines non-blocking Backups für die DB (@friesenjung, ...), ggf. per Parameter eingebunden in das Systembackup. wird in DbRep integriert.
#20 Anpassen der benutzten Spalten in der DB(verzicht auf events, ggf. auch auf units). (@Garry Hayne)
#21 Funktion zum korrigieren von Werten vor dem Einfügen in die Datenbank (duplikat von #26)
#22 clearReadings -> V2.12.3.pm
#23 ReduceLog: Möglichkeit zum Löschen des Inhalts der Spalte "Event" ergänzen.
#24 Möglichkeit schaffen zum Verhindern des Loggings von "state". (über valueFn möglich) NEU: ab 2.22 zusätzlich über "addStateEvent = 0"
#25 Unterstützung MongoDB (betateilchen)
#26 valueFn ähnlich wie bei readingsProxy oder valueFormat bei readingsGroup, indem Werte vor der Aufnahme in die DB verändert werden können (korrigiere Units, verhindere bestimmte Werte (bsp kleiner 0), map true/false auf 0/1; ...) (erledigt in c2.15.0 aus Kommentar #225)
#27 Eine Funktion ähnlich der average funktion, aber für nicht-numerische werte, also löschen aller records, ausser VALUE ändert sich, behalten von min 1 Wert/Stunde bzw. Tag... (werner)
#28 exportCache / importCache (erledigt in v2.14 in #205)
#29 excludeDevs auch als <devspec> plus Newline als Trenner für excludeDevs (erledigt in v2.14.4 )
#30 verhindern eines Logeintrags, der bestimmte kriterien (nicht) erfüllt (erledigt in v2.15.0_test1 über valueFn mit ignore=1; )
#31 timestamp soll beim Update nicht auf die aktuelle Uhrzeit geändert werden (entfernen von default timestamp für das Feld timestamp)
#32 "$UPDATE=1" für valueFN um bestimmte Werte in der Datenbank aktualisieren zu können!
#33 <Reading> von addLog sollte als Regex angegeben werden können in 2.16.3 enthalten.
#34 set <name> deleteOldDaysFilter<n> <Device> <Reading> (Muschelpuster)
#35 UTF8-Modus für Datenbankverbindungen
#36 "set sql checkConfig", prüfung auf alte Konfigurationen, zusammenpassende unicode-DB-verbindung mit unicode-Tabellenstruktur, DB-Typen (bei MySQL),... in 2.18 erledigt
#37 Möglichkeit, die current-tabelle manuell füllen zu können, um dessen Vorteile ohne permanenten Ressourcenverbrauch nutzen zu können. (zusammen mit DbRep gelöst)
#0 ... wird fortgesetzt
Offene Fragen (bitte bringt euren Input direkt im Thread ein!)
# Soll das Datenbankschema angepasst werden oder genügt es, nicht benutzte Spalten wie "Events" und "Units" auf Wunsch einfach nicht zu schreiben?
# Gibt es Empfehlungen für die Optimalen DB_Servereinstellungen? Wie kann man zB den Speicherverbrauch auf dem RPI für MySQL möglichst gering halten?
# ...
Aktuelle Workarounds:
#20 durch setzen von "attr dbLog colEvent = 0" wird diese Spalte nict mehr gefüllt (DS_Starter in Kommentar #26)
# Korrektur von Fehlerhaften Loggings über attr valueFn am Beispiel von Whatsapp (yowsup): https://forum.fhem.de/index.php/topic,65860.msg618486.html#msg618486
Aktuelle Testversion:
=> Enthalten in Message #50. Mit dieser ist der Betrieb auf einem RPI1 schon sehr performant möglich.
Workaround für Tests:
Wie können große Änderungen an der Datenbank durchgeführt werden, ohne dass
FHEM dadurch blockiert wird?
Schritte:
1. Erzeuge eine leere History-Tabelle mit neuem Namen
2. Benenne die aktuelle history-tabelle um und platziere eine neue, leere Tabelle dort. Dies funktioniert ohne Unterbrechung.
3. Korrigiere/Bereinige die Einträge in der Umbenannten Tabelle: FHEM kann somit völlig ungestört weiterarbeiten.
4. Benenne die Tabellen zurück um:
5. Kopiere die neuen Werte aus der "Temporären leeren History-Tabelle" wieder zurück in die Haupttabelle
6. Lösche die Einträge der temporären History-Tabelle.
zu 1:
Nutzt ihr DbRep? Diese Tabellen haben auch den Index für DbRep, der ggf. entfernt werden kann... gebenchmarked habe ich diesen noch nie.
CREATE TABLE `historyNEW` like history;
zu 2: Achtung! Beide Befehle in einer Zeile gemeinsam ausführen, damit es zu keiner Unterbrechung kommt.
rename table history to historyOLD; rename table historyNEW to history;
Jetzt hast Du eine neue leere History-Tabelle in die alles neue geloggt wird. Jetzt kannst Du die alte Tabelle so verändern, bereinigen, etc. bis sie ok ist und Du sie wieder
an Original-stelle zurück spielst.
zu 3: Jetzt kannst Du mit der Datenbank "historyOLD" arbeiten, ohne FHEM zu blockieren.
Hier kannst Du neue Indexe anlegen, große Datenmengen bereinigen, etc...
zu 4:
rename table history to historyTMP; rename table historyOLD to history;
zu 5: Dies sollte ohne großen Lock gehen, da in der zwischenzeit nur eine geringe Anzahl an Datensätzen angelaufen ist:
insert ignore into history select * from historyTMP;
zu 6:
drop table historyTMP;
kleiner Auszug aus gemachten Benchmarks:(wird noch weiter durchgeführt)
Test#1: Import von 22.794.730 Datensätzen in die jeweilige Datenbank. Einheit in Sekunden
Test#2: Größe der unterschiedlichen DBs.
Test#3: Plot-ähnliche Suche aller Daten der 200 häufsten Devices aus meiner Tsest-DB für jeweils einen Monatszeitraum:
Test#9: Gruppierung über sämtliche Devices und Count um zu häufig loggende und zu selten loggende Devices erkennen zu können (optionaler Zusatztest. kommt direkt in FHEM nicht vor)
Datenbanken:
#1: Original MySQL InnoDB-Datenbank mit original Index.
#1a: Original ohne Unicode
#2: Original mit Engine MyISAM
#2a: Original mit Engine Aria
#3a: Aria mit zweitem Index aus DbRep
#6a: Aria zweitem Hash-Index
#6b: Aria mit "vertauschtem" index
#7: Aria als "CrashSafe".
#7a: Aria als "CrashSafe" mit einfachem index
#8: Aria mit unicode sonst wie 7a.
Test1: MySQL
Datenbank Test#1 GrößeMB Test#2 test #3 Test#9
--------------------------------------------------
#1 96,56s 3500 861s 91s 48,56s
#1a 36s
#2
#2a
#3a 39s
#6a 814s
#6b 68,58s 2200 112s 36s 2,32s
#7 38s
#7a 548s
#8
Tabellen:
original: ist die Original MySQL-innoDB -Tabelle, wie sie im create-Script von DbLog erzeugt wird.
MyISAM:
Aria: Ist ähnlich wie MyISAM, funktioniert jedoch nur in MariaDB. Dieser Datenbanktyp ist "crashsave".
Ok .. bin dabei ...
Zitat von: DS_Starter am 27 Januar 2017, 22:29:53
Ok .. bin dabei ...
Sehr schön :D
Bitte Ideen und Vorschläge einfachhier einbringen, im ersten Thread möchte ich diese halbwegs "zusammenhalten" soweit möglich!
Für heute bin ich raus... CU
Zitat von: JoeALLb am 27 Januar 2017, 22:21:02
Hallo Daniel,
Die Fehlermeldung wäre schön ;-)
...
Hallo Joe,
leider habe ich keine Fehlermeldung (wo würde sowas geloggt?). :o
Ich nutze ja PHPmyAdmin i.V.m. MariaDB auf einer Synology.
Ich merke es an versch. Dingen an der historyNEW-Tabelle:
-nach dem "insert ignore..." klicke ich auf Anzeigen der neuen Tabelle, aber er bleibt hängen
-den Prozess (unter PHPmyAdmin) sieht man zwar unter Status, nur bleibt der immer bei 0
-auch der Prozess von MariaDB auf der Synology ist ungewöhnlich konstant bei 50%
-unter "Tabellenkommentar > Speicherplatzverbrauch steht immer nur "Daten 0 B"
-einzig der Index wächst minimal (so 0,1MB pro Minute)
-die Spalten Timestamp, Device, Reading haben auf einmal einen Primärschlüssel (im Gegensatz zu auch neuen history-Tabelle)
Oder bin ich zu ungeduldig und die Datensätze kommen erst nach 10h? Glaub ich aber irgendwie nicht.
Kann ich den Prozess abbrechen?
Das mit dem
limit 0,10000;
bzw.
limit 10000,20000
hab ich noch nicht ganz gerafft. Muß ich das jedesmal nach 10000Stück wieder machen? Bei 5Mio. Datensätzen keine schöne Vorstellung :-[
VG
Daniel
Zitat von: friesenjung am 27 Januar 2017, 22:55:20
Hallo Joe,
leider habe ich keine Fehlermeldung (wo würde sowas geloggt?). :o
Ich nutze ja PHPmyAdmin i.V.m. MariaDB auf einer Synology.
vermutlich ist das dann ein anderes Problem ...
Ich tippe auf Timeouts.
Kannst Du ein anderes Tool laden, zB Heidisql? das ist ein Sql-Browser.
Alternativ geht natürlich aich die Console.
5Mio datensätze sollte eigentlich funktionieren , die primary keys hatte ich in meiner Vorlage, wollte diese aber eigentlich entfernen, bis diese ordentlich von DbLog supported werden. das schau ich mir noch an.
Hallo Joe,
der Groschen viel bei "...die primary keys hatte ich in meiner Vorlage, wollte diese aber eigentlich entfernen,"!!!
Das war das Problem. Hab die DB nochmal ohne die Primarykeys übernommen und siehe da, es lief :)
Alle Datensätze wurden in recht kurzer Zeit (ein paar Minute) kopiert.
Folgende Verbesserungen:
-Größe: Datenbank von 1300 auf 700 MB geschrumpft :D
-Index von 500MB auf 50MB gesunken :D :o
-Abfrage mit Count über alles: von 120 Sekunden auf 36 Sekunden gesunken :D
-die Plot-Abfrage sank von 0.04 auf 0.03 Sekunden. ok...
Wie soll ich nun vorgehen, um wieder nur eine history zu haben? hab ja neue Daten in der jetzigen history. So würde ichs machen:
1. history in historyTEMP und gleichzeitig historyWORK in history umbenennen
rename table history to historyTEMP; rename table historyWORK to history;
2. aus historyTEMP die während der "Bauarbeiten an den anderen DBs" zuletzt geloggten Daten in die history kopieren
insert ignore into history select * from historyTEMP;
OK so?
und nochmal ich,
da sich meine SQL-Kenntnisse recht oberflächlich sind (für meine Anwendungsfälle wurschtel ich mich halt so durch), hier noch ein paar Verständnisfragen, die mir heute Abend noch so in den Sinn kamen:
- was genau bewirken die Partitionen, ist das so ne art extra-Index? was bringen Sie in unserer FHEM-LOG-Anwendung?
- die DB "Current" ist ja noch vom Typ InnoDB, ist das ein Problem? also die Kombi current=InnoDB und history=Aria?
- warum benutzt Du gerade den schwedischen Zeichensatz "latin1_swedish_si" (Kollation)? und macht es Sinn diesen auch in der current-Tabelle einzustellen?
- ich habe bei bestimmten Sensoren unter Unit "°C". Das war aber auch schon mit dem Zeichensatz UTF8 so. hast Du ne Idee, wie man das wegbekommt?
So, genug der Fragen.
VG...
Zitat von: friesenjung am 27 Januar 2017, 23:54:05
Wie soll ich nun vorgehen, um wieder nur eine history zu haben? hab ja neue Daten in der jetzigen history. So würde ichs machen:
1. history in historyTEMP und gleichzeitig historyWORK in history umbenennen
rename table history to historyTEMP; rename table historyWORK to history;
2. aus historyTEMP die während der "Bauarbeiten an den anderen DBs" zuletzt geloggten Daten in die history kopieren
insert ignore into history select * from historyTEMP;
genau so, und da die aktelle history recht klein ist, geht das auch sehr schnell! Ich mach grad Mittagpause und antworte danach auf die anderen fragen.
Zitat von: friesenjung am 28 Januar 2017, 00:17:57
- was genau bewirken die Partitionen, ist das so ne art extra-Index? was bringen Sie in unserer FHEM-LOG-Anwendung?
Diese erzeugen praktisch eine völlig eigene tabelle.
Du hast jetzt eine Tabelle in der alle Logeinträge von Sonntagen, eine andere wo alle Montage drinnen sind, etc.
Auf dem RPI habe ich damit sehr gute Erfahrungen gemacht, ob man das tatsächlich braucht ist sicherlich disskussionswürdig.
Eventuell sollten wir noch eine zusätzliche Patrtition für "zu löschende" Datensätze ergänzen. Ein löschen von solch einer Partition geht in 0,2 sekunden mit allen
datensätzen, die darin enthalten sind, also ein Vorteil beim aufräumen.
Zitat von: friesenjung am 28 Januar 2017, 00:17:57
- die DB "Current" ist ja noch vom Typ InnoDB, ist das ein Problem? also die Kombi current=InnoDB und history=Aria?
kein Problem, aber für den Arbeitsspeicher nicht optimal. das gehen wir aber später an, wir können dann innodb in der my.cfg deaktivieren.[/list]
Zitat von: friesenjung am 28 Januar 2017, 00:17:57
- warum benutzt Du gerade den schwedischen Zeichensatz "latin1_swedish_si" (Kollation)? und macht es Sinn diesen auch in der current-Tabelle einzustellen?
Weil es immer der standard bei MysSQL für Single-Byte Zeichensätze war. Ist weit verbreitet und kein hindernis... Hast Du bessere Vorschläge?
Zitat von: friesenjung am 28 Januar 2017, 00:17:57
- ich habe bei bestimmten Sensoren unter Unit "°C". Das war aber auch schon mit dem Zeichensatz UTF8 so. hast Du ne Idee, wie man das wegbekommt?
Ich auch! Das Modul des Sensors übderstützt die splitFn von DbLog nicht, daher wird dies falsch eingetragen.
Ob man Units in der aktuellen Fassung überhaupt benöptigt, stelle ich mal zur Frage.
Ich habe dazu auch einen Workaround geschrieben als MySQL-Strored procedure geschrieben, wenn du willst kannst du ihn aktivieren:
Bitte passe ihn an deine Gegebenheiten an!!
CREATE DEFINER=`root`@`localhost` TRIGGER `history_before_insert` BEFORE INSERT ON `history_dup` FOR EACH ROW if
(New.TYPE='CUL_EM' and New.READING='total') then Set New.value = CAST(New.value AS DECIMAL(8,4));
ELSEIF
(New.value ='°C') then Set New.value = ' °C';
ELSEIF
(New.TYPE='CUL_EM' and New.READING='power') then Set New.value = CAST(New.value AS DECIMAL(8,4));
ELSEIF
(New.TYPE='OWTHERM' and New.READING='data') then Set New.value =digits(New.value);
ELSEIF
(New.event ='desiredTemperature auto') then Set New.value = 22.0;
ELSEIF
(New.event ='desiredTemperature eco') then Set New.value = 18.0;
ELSEIF
(New.event ='desiredTemperature comfort') then Set New.value = 22.0;
ELSEIF
(New.event ='desiredTemperature off') then Set New.value = 5.0;
ELSEIF
(New.event ='desiredTemperature boost') then Set New.value = 30.0;
ELSEIF
(New.event ='desiredTemperature on') then Set New.value = 30.0;
END IF
Ich habe mal bei mir auf dem Cubietruck MyISAM mit Aria verglichen.
Beide hatten ca. die gleichen Geschwindigkeitswerte.
Auch beim Speicherplatz ist die Aria nur um 2,2% kleiner als die MyISAM Tabelle.
Zitat von: stromer-12 am 28 Januar 2017, 20:28:08
Ich habe mal bei mir auf dem Cubietruck MyISAM mit Aria verglichen.
Beide hatten ca. die gleichen Geschwindigkeitswerte.
Auch beim Speicherplatz ist die Aria nur um 2,2% kleiner als die MyISAM Tabelle.
Aria hat den Vorteil, dass sie crash-safe konfiguriert werden kann. Wenn also möglich, ist Aria die bessere Option.
Hallo Daniel,
Zitat von: friesenjung am 27 Januar 2017, 22:55:20
-nach dem "insert ignore..." klicke ich auf Anzeigen der neuen Tabelle, aber er bleibt hängen
-den Prozess (unter PHPmyAdmin) sieht man zwar unter Status, nur bleibt der immer bei 0
-auch der Prozess von MariaDB auf der Synology ist ungewöhnlich konstant bei 50%
-unter "Tabellenkommentar > Speicherplatzverbrauch steht immer nur "Daten 0 B"
-einzig der Index wächst minimal (so 0,1MB pro Minute)
-die Spalten Timestamp, Device, Reading haben auf einmal einen Primärschlüssel (im Gegensatz zu auch neuen history-Tabelle)
dem wäre es aber schon noch interessant, nachzugehen, denn im ALlgemeinen wäre es für diesen Einsatzzweck SEHR gut, einen Primary Key zu verwenden!
Ich sehe auch keinen Grund für schwierigkeiten, ich selbst hatte bei der ersten Konvertierung jedoch auch jede Menge doppelter Datensätze, die ich jedoch durch das "insert ignore"
einfach aussortieren konnte (ich habe auch andere Methoden versucht und die Daten auf deren Herkunft geprüft...).
zB erzeugen oft zu weit konfigurierte Userreadings doppelte Speichereinträge..
Hallo Joe,
Zitat von: JoeALLb am 28 Januar 2017, 08:44:45
kein Problem, aber für den Arbeitsspeicher nicht optimal. das gehen wir aber später an, wir können dann innodb in der my.cfg deaktivieren.[/q]
Weil es immer der standard bei MysSQL für Single-Byte Zeichensätze war. Ist weit verbreitet und kein hindernis... Hast Du bessere Vorschläge?
> war nur Neugier. einen besseren Vorschlag hätte ich auch nicht...
Zitat von: JoeALLb am 28 Januar 2017, 08:44:45
kein Problem, aber für den Arbeitsspeicher nicht optimal. das gehen wir aber später an, wir können dann innodb in der my.cfg deaktivieren.[/q]
> rein theoretisch der gleiche Ablauf wie bei der history-Tabelle denk ich!?
Zitat von: JoeALLb am 28 Januar 2017, 08:44:45
Ich auch! Das Modul des Sensors übderstützt die splitFn von DbLog nicht, daher wird dies falsch eingetragen.
Ob man Units in der aktuellen Fassung überhaupt benöptigt, stelle ich mal zur Frage.
Ich habe dazu auch einen Workaround geschrieben als MySQL-Strored procedure geschrieben, wenn du willst kannst du ihn aktivieren:
Bitte passe ihn an deine Gegebenheiten an!!
...
> mh, ok. dann könnte man den Modul-Author danach fragen. Aber eigentlich hast Du Recht, das ist mein kleinstes Problem ;) . Ich nutze die Units auch nicht wirklich!
Deinen Workaround werde ich deshalb erstmal nicht aktivieren, aber gut zu wissen, dass es Ihn gibt!
Eine Verständnisfrage dazu: Der Code erfasst nur neue Einträge und wirkt nicht "rückwärts" oder?
Zitat von: JoeALLb am 28 Januar 2017, 21:55:31
dem wäre es aber schon noch interessant, nachzugehen, denn im ALlgemeinen wäre es für diesen Einsatzzweck SEHR gut, einen Primary Key zu verwenden!
Ich sehe auch keinen Grund für schwierigkeiten, ich selbst hatte bei der ersten Konvertierung jedoch auch jede Menge doppelter Datensätze, die ich jedoch durch das "insert ignore"
einfach aussortieren konnte (ich habe auch andere Methoden versucht und die Daten auf deren Herkunft geprüft...).
zB erzeugen oft zu weit konfigurierte Userreadings doppelte Speichereinträge..
> vermutlich lag es daran, dass die beiden Tabellen nicht beide einen PK hatten. Meine alte history (InnoDB) hatte keinen PK, jedoch die neue history (Aria). Nachdem ich dann beide ohne PK hatte funktionierte es. Werd das mal ausprobieren. Kann ich eine Tabelle kopieren, also ohne die Prozedur, die wir zum Ändern des Tabellentyps nutzten?
So und nun noch eine neue Frage:Also ich habe nun alles wieder so wie es vorher war und alle Datensätze sind in der "history", nur ist die history-Tabelle "Aria" statt "InnoDB"! So weit so gut.
Nun lasse ich mir die (neue) history (ca. 5Mio. Datensätze) anzeigen, so dauert das ca. 15 Sekunden!!!??? Das komische ist, dass die gleiche Tabelle, als sie noch historyWORK hieß das gleiche in 0.003 Sekunden erledigt hatte. Irgendwas ist doch da noch faul!?
Selbst die alte historyOLD (InnoDB) liegt da bei 0.004Sek!
Was könnte das sein?
VG
Daniel
Zitat von: friesenjung am 29 Januar 2017, 15:02:44
> rein theoretisch der gleiche Ablauf wie bei der history-Tabelle denk ich!?
Ja! Oder direkt ohne Zwischenkopie, da diese Tabelle so klein ist sollte das auch gehen (alter table...)
Zitat von: friesenjung am 29 Januar 2017, 15:02:44
Eine Verständnisfrage dazu: Der Code erfasst nur neue Einträge und wirkt nicht "rückwärts" oder?
korrekt, diese müsste man einmal manuell korrigieren.
Zitat von: friesenjung am 29 Januar 2017, 15:02:44
So und nun noch eine neue Frage:
Also ich habe nun alles wieder so wie es vorher war und alle Datensätze sind in der "history", nur ist die history-Tabelle "Aria" statt "InnoDB"! So weit so gut.
Nun lasse ich mir die (neue) history (ca. 5Mio. Datensätze) anzeigen, so dauert das ca. 15 Sekunden!!!??? Das komische ist, dass die gleiche Tabelle, als sie noch historyWORK hieß das gleiche in 0.003 Sekunden erledigt hatte. Irgendwas ist doch da noch faul!?
Selbst die alte historyOLD (InnoDB) liegt da bei 0.004Sek!
Wie sieht es aus, wenn du die Abfrage mehrmals ausführst? Klingt nach einem simplen Cache-Problem,wo die Abfrage bereits im Zwischenspeicher war zur schnelleren Beantwortung.
Ich vermute dass noch viel des vorhandenen Speichers für die anderen Tabellen genutzt wird.
sG und gute Nacht,
Joe
Zitat von: JoeALLb am 29 Januar 2017, 21:50:37
Wie sieht es aus, wenn du die Abfrage mehrmals ausführst? Klingt nach einem simplen Cache-Problem,wo die Abfrage bereits im Zwischenspeicher war zur schnelleren Beantwortung.
Ich vermute dass noch viel des vorhandenen Speichers für die anderen Tabellen genutzt wird.
Auch wenn ich es kurz nacheinander wiederhole ist keine Änderung zu sehen. Ganz selten, ich glaube 2 mal war das, wurde die Ansicht in 0.04sek geladen. Bei den übrigen 20 Versuchen geht es immer nur langsam (also die 16Sekunden). :(
Interessanterweise ist die Count-Abfrage genauso schnell wie vorher, also 36 Sekunden. :o
Bzgl. der Idee mit dem Cache. Wo soll ich da ansetzen. Unter PHPmyAdmin gibts z.B. "Leeren des Tabellenzwischenspeichers (FLUSH)", "Optimiere Tabelle" oder "Repariere Tabelle".
Ich habe mal die Cache-Variablen ausgelesen. Das Ergebnis ist im Anhang. Auffällig ist, dass die Cache_size 0 ist.
VG
Wie sieht denn dein SQL-Selectbefehl aus, den Du für diese Aktion nutzt?
Zitat von: friesenjung am 29 Januar 2017, 15:02:44
Nun lasse ich mir die (neue) history (ca. 5Mio. Datensätze) anzeigen, so dauert das ca. 15 Sekunden!!!??? Das komische ist, dass die gleiche Tabelle, als sie noch historyWORK hieß das gleiche in 0.003 Sekunden erledigt hatte. Irgendwas ist doch da noch faul!?
Zitat von: JoeALLb am 30 Januar 2017, 09:51:38
Wie sieht denn dein SQL-Selectbefehl aus, den Du für diese Aktion nutzt?
SELECT * FROM `history` ORDER BY `TIMESTAMP` DESCUpdate: ohne die Sortierung gehts schnell
Und welchen Index hast Du aktuell auf der Tabelle?
Einfach den Standard-Key von DbLog (der auch in meinem Testscript unverändert, bis auf das PK-Argument enthalten war)?
Deine Abfrage kann den Index nicht nutzen, da Du im WHERE-Abschnitt (den es nicht gibt) keine Devices und keine Reading angegeben hast.
Er macht somit immer einen "Full Table scan" und dieser ist zu groß für den Speicher. Daher dauert dies auch immer gleich lang.
Ich bezweifle jedoch, dass genau diese Abfrage bei der historyWORK ein anderes Verhalten gezeigt hat.
Ich würde gerne einen anderen Index testen, bin bisher jedoch noch nicht dazugekommen.
Ich denke, einer dieser Index könnte für alles ein besseres Ergebnis liefern, zumal in fast allen
Mysql-Abfragem an die DB (zB aus Plots) das Timestamp mit abgefragt wird.
Die aktuell schnellste Indexkombination ist:
ALTER IGNORE TABLE `history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);
CREATE INDEX Search_Idx ON `history` (DEVICE, READING, TIMESTAMP);
# Hinweis: Am "optimalen" Index wird aktuell noch auf Testsystemen experimentiert. Dieser kann sich je nach Erkenntnis nochmal verändern.
Um die Indexfrage optimal entscheiden zu können, benötigen wir auch eine Liste an "Häufig benötigte SELECT-Abfragen AN DIE db".
Würdest Du sagen, dass deine Abfrage schon dazugehört, denn automatisch (also vom Modul) wird diese, so denke ich, so niemals an die Datenbank abgesetzt.
@DS_Starter: Heiko, warum ist der INdex von DbLog ohne Devices? Werden hier hauptsächlich Readings ohne Devices abgefragt? Ich würde die zwei separaten Indexe gerne in einem zusammenfassen...
Edit: Habe den Index durch den zweiten Index ergänzt, da dies im Moment die performanteste Kombination ist. GGF. kann sich diese rnochmal ändern.
Nachtrag:
Im übrigen würde dieser SQL ja sämtliche (ALLE!) Daensätze zurückgeben,
ich vermute also, dass dein Querybrowser da noch ein "limit 100" oder ähnlich ergänzt.
Nachtrag2:
Wenn Du die Abfrage mit device und reading ergänzt, so in etwa wie hier, kann der Index wieder genutzt werden und es sollte wieder schneller sein.
Zitat von: friesenjung am 30 Januar 2017, 10:02:53
SELECT * FROM `history` where device='Wohnzimmer' and reading='measured-temp' ORDER BY `TIMESTAMP` DESC limit 10;
ich hätte da auch noch eine Idee :-)
bei my/Maria SQL
erzeugung der Current Tabelle/View via stored procedure (asynchron via Trigger auf den Insert?)
Zitat von: Wuppi68 am 30 Januar 2017, 12:22:41
erzeugung der Current Tabelle/View via stored procedure (asynchron via Trigger auf den Insert?)
Hallo Wuppi,
Vielen Dank für deinen Input! Ideen sind immer sehr willkommen ;-).
Die Idee mit stored procedures sollte jedoch ein recht großer overhead für viele Inserts sein und auf sqlite sind diese nicht wirklich eine gute Lösung.
insert delayed ignore into current ...würde eigentlich das selbe erreichen, jedoch mit weniger overhead. Der Nachteil ist, dass "delayed" die Storageengine "Aria" nicht unterstützt.
Ob hier MyISAM, das dies noch unterstützt eine Alternative wäre, könnte man sich noch genauer ansehen.
Eventuell wäre es eine Option, diese ausschließlich im Speicher zu halten. bei einem Neustart könnte sie aus der Datenbank einmalig befüllt werden...
Ich hätte (wenn ich sie nutzen würde) aktuell 4500 Einträge in der Current_DB. Man müsste mal erheben, wie viel Speicher das benötigen würde...
Als Idee habe ich auch versucht, die current-Tabelle als "View" dynamisch einzubinden. dies dauert leider ca. eine Minute.
Eine weitere Idee wäre, die Daten einfach nur zum Anlegen eines Plots aus der Datenbank abzurufen.
Danzu habe ich folgende Tests als Idee gemacht:
Variante1: stand heute: Ergebnis: 01:45 Minuten
select TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT, READING from history where TIMESTAMP > (now() - interval 24 hour) group by DEVICE,READING;Variant2: unter Verwendung der Partition von Heute (also nur Einträge von heute berücksichtigt) = 68s:
select TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT, READING from history partition(mon) where TIMESTAMP > (now() - interval 24 hour) group by DEVICE,READING;Variant3: wie 2 jedoch mit Nutzung des neu vorgeschlagenen Indexes (timestamp zuerst) bei kalter Datenbank = 4s: (Achtung, funktioniert nur wennd er Index verändert wurde!)
die zweite Abfrage davon eine Stunde später war in 0,95s fertig.
select TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT, READING from history partition(mon) where TIMESTAMP > (now() - interval 24 hour) group by DEVICE,READING;jeweils bei meiner Datenbank mit 34Mio Datensätzen.
Eventuell wäre es im Plot beim editieren durchaus möglich, diese 4 Sekunden (einmalig) zu warten? Zumindest für die Betriebsart "History", also ohne Current könnte man dies überlegen.
Ich stell dies hier einfach mal zur Diskussion.
Heiko,
mir werde es reichen die Felder einfach nicht zu fuellen im Moment.
Regards, Garry
Hi Garry,
Zitatmir werde es reichen die Felder einfach nicht zu fuellen im Moment.
sehe ich mal mit vor.
Regards,
Heiko
Hallo zusammen, hallo Dan & Joe,
ich habe uns für die Implementierung der Altdatenmigration eine Arbeitsversion 93_DbLog_V2.12_Migration gebaut und hier angehängt.
Ich habe bereits als Grundlage den non-blocking Fileimport aus DbRep in das Modul integriert. Man kann es nutzen um die Funktion zu testen und sich mit der Arbeitsweise vertraut zu machen.
Vorgehensweise:
* Attribut "impfile" auf das zu importierende File setzen z.B. /sds1/backup/test.txt
* bei großen Files Attr timeout hochsetzen -> wird aber auf 3600s gesetzt falls Attr nicht vorhanden
* "set <dbLog> migrateFile" startet den non-blocking import -> state und Logfile werden bedient
Datensatzformat: "TIMESTAMP","DEVICE","TYPE","EVENT","READING","VALUE","UNIT"
# Die Felder "TIMESTAMP","DEVICE","TYPE","EVENT","READING" und "VALUE" müssen gesetzt sein. Das Feld "UNIT" ist optional. Der Fileinhalt wird als Transaktion importiert, d.h. es wird der Inhalt des gesamten Files oder, im Fehlerfall, kein Datensatz des Files importiert.
Ein Beispielfile für einen Testimport habe ich mit angehängt.
Dan, um jetzt meine Funktion mit deiner Migrationsfunktion zu ersetzen mütest du dir die sub "DbLog_impfilePush" genauer anschauen. Ich habe gekennzeichnet wo etwa dein Code statt meinem implementiert werden müßte.
"DbLog_impfilePushDone" ist die reguläre Beendigungsfunktion des BlockingCall, "DbLog_impfilePushAborted" die Abbruchfunktion bei timeout.
Dan, schau mal ob du damit für die ersten Schritte klarkommst. Wir schauen dann gemeinsam weiter wie wir das implementiert bekommen.
Grüße
Heiko
Good morning Garry,
ZitatHeiko,
mir werde es reichen die Felder einfach nicht zu fuellen im Moment.
Mir ist eingefallen, dass du doch schon mit der aktuellen Version zumindest für das Feld EVENT das machen kannst.
Es gibt die Attribute colEvent, colReading, colValue. Sie sind zur flexiblen Anpassung der Feldbreiten in der DB gedacht.
Wenn du z.B. colEvent = 0 setzt, werden de facto keine Events in die DB geschrieben.
Probiers mal aus.
Have a good day, best regards
Heiko
Zitat von: DS_Starter am 31 Januar 2017, 07:57:30
Es gibt die Attribute colEvent, colReading, colValue. Sie sind zur flexiblen Anpassung der Feldbreiten in der DB gedacht.
Wenn du z.B. colEvent = 0 setzt, werden de facto keine Events in die DB geschrieben.
Toller Hinweis, vielen Dank! bei mir verkleinert sich die history-Tabelle dadurch immerhin um 25%!
Anbei mein bescheidener Versuch, einen Patch für einen
"PimaryKey-Mode" herzustellen.
Dieser führt ein neues Attribut "usePK=0" ein,
und nutzt die neuen Funktionen nur, wenn dieser auf 1 gesetzt wird.
Der Patch funktioniert aktuell nur mit MySQL und MariaDB.
Zuvor muss dieser Index (unten) in der Tabelle "Current" angelegt werden.
Dieser Patch fasst die beiden Vorgänge
# Versuche den Datensatz upzudaten
# bei nichtgelingen versuche ein insert
zu einem einzigen
insert into...
zusammen. Auf meinem RPI, der damit massive Performanceprobleme hatte (auch weil die SD-Karte nicht sonderlich schnell ist), ist die CPU-Auslastung
von 0.71 auf 0.19 gesunken.
ALTER TABLE `current`
ALTER `DEVICE` DROP DEFAULT,
ALTER `READING` DROP DEFAULT;
ALTER TABLE `current`
ALTER `DEVICE` DROP DEFAULT,
ALTER `READING` DROP DEFAULT,
CHANGE COLUMN `DEVICE` `DEVICE` VARCHAR(64) NOT NULL AFTER `TIMESTAMP`,
CHANGE COLUMN `READING` `READING` VARCHAR(64) NOT NULL AFTER `EVENT`,
ADD PRIMARY KEY (`DEVICE`, `READING`);
Generell stellt sich die Frage, wie wir zukünftig mit der current-Tabelle umgehen.
Ich könnte mir auch vorstellen, dass diese ausschließlich in einem Memcache gehalten werden kann.
Wie denkt ihr darüber?
Zitat von: JoeALLb am 31 Januar 2017, 09:12:28
Toller Hinweis, vielen Dank! bei mir verkleinert sich die history-Tabelle dadurch immerhin um 25%!
Hi,
hast du das am laufendem DbLog gemacht? Bei mir funkioniert es nicht.
Garry
Hi,
Zitat von: Garry Hayne am 31 Januar 2017, 13:09:21
hast du das am laufendem DbLog gemacht? Bei mir funkioniert es nicht.
Was genau funktioniert nicht? Das
attr DbLog colEvent 0?
oder das Löschen der bisherigen alten Einträge in der Tabelle zum herausfinden, wieviel Speicherplatz dadurch frei wird?
attr DbLog colEvent 0? klappt bei mir problemlos!
Die (Test-)Datenbank habe ich mit dem Trick bereinigt, den ich schon angegeben habe zum Konvertieren der
Datenbank nach Aria.
Edit: Habe die Anleitung in diesem Thread unter #1 nochmal vereinfacht angehängt.
(siehe https://forum.fhem.de/index.php/topic,65860.msg571050.html#msg571050)
Zitat von: JoeALLb am 31 Januar 2017, 13:22:31
Hi,Was genau funktioniert nicht? Das
attr DbLog colEvent 0?
oder das Löschen der bisherigen alten Einträge in der Tabelle zum herausfinden, wieviel Speicherplatz dadurch frei wird?
attr DbLog colEvent 0? klappt bei mir problemlos!
Die (Test-)Datenbank habe ich mit dem Trick bereinigt, den ich schon angegeben habe zum Konvertieren der
Datenbank nach Aria. Siehe die ersten Punkte unter https://forum.fhem.de/index.php/topic,62998.msg568302.html#msg568302 (also anlegen einer neuen DB, umbenennen, bearbeiten, zurück umbenennen und zInhalte wieder zusammenführen)...
Hi,
dann muss ich history doch nachbearbeiten, ich dachte die EVENT werte werden einfach nicht geschrieben nachdem ich colEvent auf 0 gesetzt habe!
Regards, Garry
Hinweis: Habe die Anleitung in diesem Thread unter #1 nochmal vereinfacht angehängt.
(siehe https://forum.fhem.de/index.php/topic,65860.msg571050.html#msg571050)
Wenn Du
attr DbLog colEvent 0
setzt, werden ab jetzt die neuen Logs ohne diese Spalte geschrieben.
Die bisherigen Datensätze, die schon in der Datenbank sind, werden dadurch natürlich nicht gelöscht!
Dazu müsstest Du etwas wie
update history set event='';
ausführen! Aber Achtung, die Daten sind dadurch gelöscht, und dieser Vorgang wird eine weile benötigen!
Zitat von: JoeALLb am 31 Januar 2017, 13:36:42
Hinweis: Habe die Anleitung in diesem Thread unter #1 nochmal vereinfacht angehängt.
(siehe https://forum.fhem.de/index.php/topic,65860.msg571050.html#msg571050)
Wenn Du
attr DbLog colEvent 0
setzt, werden ab jetzt die neuen Logs ohne diese Spalte geschrieben.
Die bisherigen Datensätze, die schon in der Datenbank sind, werden dadurch natürlich nicht gelöscht!
Dazu müsstest Du etwas wie
update history set event='';
ausführen! Aber Achtung, die Daten sind dadurch gelöscht, und dieser Vorgang wird eine weile benötigen!
Leider wird EVENT immer noch geschrieben, selbst nach dem ich history geleert habe!
Garry
Hallo Garry, versuch mal bitte ein
set <DEVICE> reopen oder sogar
einen Neustart von FHEM.
Hast Du die aktuelle Version von heute im Einsatz, ich habe nur diese getestet (2.11.1) aus dem
normalen FHEM-Update (oder von hier https://svn.fhem.de/trac/export/13289/trunk/fhem/FHEM/93_DbLog.pm)?
Ich habe diese getestet und bei mir hats wunderbar funktioniert.
Hi Garry, Joe,
Sorry, habe nicht daran gedacht dass Harry ja SQLite hat. Die Beschneidung der Feldlänge haben wir bisher ja nur für Nicht-Sqlite implementiert weil SQLite DB das ja nicht benötigt für die ursprünglich gedachte Verwendung.
Könnte man natürlich leicht für alle DB's machen.
Was meint ihr ?
Grüße,
Heiko
Zitat von: DS_Starter am 31 Januar 2017, 14:37:31
Hi Garry, Joe,
Sorry, habe nicht daran gedacht dass Harry ja SQLite hat. Die Beschneidung der Feldlänge haben wir bisher ja nur für Nicht-Sqlite implementiert weil SQLite DB das ja nicht benötigt für die ursprünglich gedachte Verwendung.
Könnte man natürlich leicht für alle DB's machen.
Was meint ihr ?
Grüße,
Heiko
Ich werde mich freuen :)
Garry
Hallo Heiko,
Zitat von: DS_Starter am 31 Januar 2017, 14:37:31
Sorry, habe nicht daran gedacht dass Harry ja SQLite hat. Die Beschneidung der Feldlänge haben wir bisher ja nur für Nicht-Sqlite implementiert weil SQLite DB das ja nicht benötigt für die ursprünglich gedachte Verwendung.
Könnte man natürlich leicht für alle DB's machen.
das hatte ich auch nicht mehr am Schirm!!
Natürlich ist es schöner, wenn die Funktionalität für alle Datenbanken gilt.
Dies liese sich hier ja relativ einfach umsetzen und bräuchte lediglich für das Setzen der Standardwerte ein anderes Vorgehen.
Wunsch:
Was noch schön wäre ist eine Attribut, ähnlich wie bei Readingsgroups, mit dem ich Werte vor dem Einfügen in die Datenbank abändern kann.
Bei den Readingsgroups heißt eines dieser Attribute zB "valueFormat", welches ich nutzen kann um die Anzeigewerte komplett abändern.
Andere Module haben solche Funktionen auch, zB splitFn, pidActorCallBeforeSetting in PID20, ...
Abtuell nutze ich eine stored Procedure in MySQL, um gewisse Werte, die DbLog nicht korrekt einträgt,
umzuschreiben:
Beispiel:
if
(New.TYPE='CUL_EM' and New.READING='total') then Set New.value = CAST(New.value AS DECIMAL(8,4));
ELSEIF
(New.TYPE='CUL_EM' and New.READING='power') then Set New.value = CAST(New.value AS DECIMAL(8,4));
ELSEIF
(New.TYPE='OWTHERM' and New.READING='data') then Set New.value =digits(New.value);
ELSEIF
(New.event ='yowsup:who') then Set New.value = digits(New.value);
END IF
Da für FHEM eine Stored procedure zu komplex sein dürfte und diese nicht datenbankübergreifend kompatibel ist,
wäre es schön, dafür einfach Perl nutzen zu können!
Auch wenn DbLog irgendwann keine Schwierigkeiten mehr mit Units hat, sehe ich dann immernoch ein Anwendungsgebiet
für diese Funktion. Man könnte damit beispielsweise bestimmte Readings runden, werte wie "set Heizung Eco"
umwandeln in "set Heizung 17°", etc.
Beispiel für Möglichkeiten mi valueFormat:
{
if( $READING eq "humidity" && $VALUE =~ /^hu/ ) { $VALUE = "%"; }
elsif( $VALUE == 1 ) { $VALUE = " "}
elsif( $VALUE eq "state" ) { $VALUE = " "}
elsif( $VALUE eq "positionCombi" ) { $VALUE = " "}
}
Diese könnte zB "insertFormat" heißen.
Hallo Garry, @all,
mit der angehängten Version 2.11.2 gelten die Feldlängenbegrenzungen mit den Attributen colEvent, colReading und colValue auch für SQLite Datenbanken. Es wird nun auch bei SQLite mit colEvent=0 das Feld EVENT nicht gefüllt.
HINWEIS:
Um die Kompatibilität mit dem bisherigen Verhalten keine Feldlängenbegrenzung bei SQLite vorzunehmen zu erhalten, gelten die Feldlängenbegrenzungen bei SQLite erst dann wenn eines der oben genannten Attribute gesetzt wird. Dann gelten aber ALLE im Internal COLUMNS angezeigten Feldlängen.
Unter Umständen sind sie dann anzupassen.
Garry, probiers mal bei dir aus. Denke es passt so... :)
Grüße
Heiko
Hab mir mal die Importfunktion angesehen.
Irgendwie ist die nicht so ganz wie ich mir das vorstellen würde (IMHO). ???
Das FileLogConvert Modul (https://forum.fhem.de/index.php/topic,65982.msg572349.html#msg572349) habe ich nun komplett non-blocking gemacht. Meint Ihr wir könnten den Import so ähnlich (etwas benutzerfreundlicher) integrieren?
Möchte jetzt nicht behaupten dass mein Modul "Das Gelbe vom Ei" ist, aber ich denke zumindest etwas benutzerfreundlicher.
Oder man lässt das Modul wirklich separat zu DbLog. Schadet erstens der Übersicht nicht und man kann die Konvertierungsfunktionen mit dem FileLogConvert Device nach der Migration entsorgen, die braucht man dann wohl eh nie wieder... ;)
Gruß
Dan
Morgen Dan,
ZitatHab mir mal die Importfunktion angesehen.
Irgendwie ist die nicht so ganz wie ich mir das vorstellen würde
Das war auch nur ein Beispiel um in die Funktionsweise reinzukommen. Klar dass die Convert-Funktion andere Anforderungen hat.
Aber prima dass du dein Modul hast umstellen können :)
Ich muß es auch mal ausprobieren um ein Gefühl für das Handling zu bekommen. Schön wäre wohl schon eine Integration in DbLog. Aber das können wir jederzeit noch machen und muß ja nicht gleich sein. Wie du schon sagst kann man es ja auch separat super nutzen.
Grüße
Heiko
Zitat von: DS_Starter am 31 Januar 2017, 19:44:29
Hallo Garry, @all,
mit der angehängten Version 2.11.2 gelten die Feldlängenbegrenzungen mit den Attributen colEvent, colReading und colValue auch für SQLite Datenbanken. Es wird nun auch bei SQLite mit colEvent=0 das Feld EVENT nicht gefüllt.
HINWEIS:
Um die Kompatibilität mit dem bisherigen Verhalten keine Feldlängenbegrenzung bei SQLite vorzunehmen zu erhalten, gelten die Feldlängenbegrenzungen bei SQLite erst dann wenn eines der oben genannten Attribute gesetzt wird. Dann gelten aber ALLE im Internal COLUMNS angezeigten Feldlängen.
Unter Umständen sind sie dann anzupassen.
Garry, probiers mal bei dir aus. Denke es passt so... :)
Grüße
Heiko
Heiko,
werde ich Heute probieren.
Ich habe am Stromkasten von eine Rasperry Pi 1 zum Zero gewechselt und habe Probleme mit timing irgendwie (Ich habe dazu ein neue thread geoeffnet).
Regards, Garry
Hi Dan,
ZitatMeint Ihr wir könnten den Import so ähnlich (etwas benutzerfreundlicher) integrieren?
Hab mal einen Blick drauf geworfen. Also ich denke das kriegen wir bestimmt so nutzerfeundlich integriert. Ich habe erst am WE wieder mehr Zeit.
Dann schau eich es mir mal genauer an wie das zu machen wäre .
Ich bin ein echter Fan von Rudis Blocking.pm und mache viel damit. Ist einen feine Sache...
Schönen Abend und bis später mal ...
Heiko
Zitat von: DS_Starter am 01 Februar 2017, 18:54:05
Hi Dan,
Hab mal einen Blick drauf geworfen. Also ich denke das kriegen wir bestimmt so nutzerfeundlich integriert. Ich habe erst am WE wieder mehr Zeit.
Dann schau eich es mir mal genauer an wie das zu machen wäre .
Ich bin ein echter Fan von Rudis Blocking.pm und mache viel damit. Ist einen feine Sache...
Schönen Abend und bis später mal ...
Heiko
Wie so ziemlich alles in FHEM ist auch BlockingCall toll, wenn man erst mal begriffen hat wie es funktioniert und wie man es einsetzt.
Jetzt wo ich weiß wie es geht, werden sich sicherlich zukünftig weitere Anwendungsbereiche ergeben...
Gruß
Dan
@Heiko, @All,
Vorschlag für neuen Standardindex.
Nach einigen Tests ist für mich dieser Index der geeignetste.
Er unterstützt sämtliche Anfragen, die in meinem Alltag und auch bei Serviceabfragen benutzt werden,
da in sämtlichen Abfragen eigentlich immer eine Zeiteinschränkung enthalten ist.
Getestet habe ich:
# Plots (=> immer mit Zeitangabe)
# DbRep (=> mit Zeitangabe)
# reduceLog (=> immer mit Zeitangabe)
# deleteOldDays (=> immer mit Zeitangabe)
# @Friesenjung: Auch deine letzte Abfrage, die ich in ähnlicher Form durchaus häufiger nutze, ist mit diesem viel schneller.
Durch diesen Index wird auch kein zweiter eigener Index für DbRep mehr benötigt.
Vorschlag:
PRIMARY KEY (`TIMESTAMP`, `DEVICE`, `READING`)
Daher die allgemeine Frage an die Runde: Sieht jemand andere Anwendungsfälle, in welchen dieser Index einen
größeren Nachteil zum bisherigen Index hat?
@Heiko: Da es jedoch ein Primary Key-Index meine Frage: Denkst Du, wir können meinen Patch von oben in die aktuellen Testversionen integrieren?
Dieser sollte ohne dem Attribut usePK keinerlei Änderungen für die Anwendung bedeuten, mit dem gesetzten Attribut jedoch den primary-Key
problemlos unterstützen? Zusätzlich könne ich dadurch Testversionen deutlich einfacher bei mir einspielen...
Fazit: Sämtliche von mir getesteten und gefundenen SQLs aus den Modulen werden dadurch beschleunigt oder bleiben zumindest gleich schnell.
Die einzige gefundene Ausnahme für FLOORPLAN ist unten dokumentiert. Wenn diese Abfrage wichtig ist, kann für diese und für Verwender von Floorplan ein
zusätzlicher Index eingefügt werden. Alternativ kann dieser jedoch durch eine Unterstützung aus dem Cache sogar noch beschleunigt werden.
===========================================================
folgende Abfragen werden dadurch langsamer:
aus DbLog:
weiß jemand, wann "getreadings" für diesen Select genau benötigt wird? Ich denke, dies fürd nur für Benutzer
von "FLOORPLAN" benötigt. Diese könnten sich dann zusätzlich einen weiteren Index mit anlegen.
SELECT distinct(reading) FROM history WHERE device = '".$device.
Anhang: zusätzlich zu DbLog geprüfte SQL_Statements aus anderen FHEM-Modulen, die durch diese Änderung profitieren:
aus DbRep:
SELECT AVG(VALUE) FROM `history` where DEVICE LIKE '$device' AND READING LIKE '$reading' AND TIMESTAMP >= '$runtime_string_first' AND TIMESTAMP < '$runtime_string_next' ;
SELECT COUNT(*) FROM `history` where ...
SELECT VALUE,TIMESTAMP FROM `history` where ... TIMESTAMP >= '$runtime_string_first' AND TIMESTAMP < '$runtime_string_next' ORDER BY TIMESTAMP;
Hallo Joe,
ZitatDenkst Du, wir können meinen Patch von oben in die aktuellen Testversionen integrieren?
Ja, ich denke das kriegen wir gut integriert mit diesem Attribut. Habe aber erst am WE wieder Zeit etwas am Modul zu tun.
Kann der neue neue "PRIMARY KEY (`TIMESTAMP`, `DEVICE`, `READING`) " kann (zunächst) neben dem bisherigen Index existieren oder muß man den alten Index dafür zwingend löschen ? Das wäre sicherlich für die Kompatibilität wichtig, falls Nutzer erst nach und nach auf Primary Key umstellen wollen.
Das Ganze funktioniert in dieser Form sicherlich nur für Nicht-SQLite DBs, d.h. für Postgre sollte es eigentlich auch passen oder ?
Wenn der Primary Key de facto Standard werden soll, wären natürlich diverse Anleitungen, Hinweise und die Beispiel-SQL's im contrib Verzeichnis anzupassen usw. Mal schauen was Tobias dazu sagt.
Grüße und schönen Abend zusammen
Heiko
Hallo Heiko,
aus verschiedenen Gründen (Performance, doppelte Einträge zur selben Zeit machen keinen Sinn, können auch nicht geplottet werden, etc..., zuverlässigeres Löschen von Einträgen (damit auch in SQL-Browsern möglich, ...)
Würde ich dazu plädieren, den PK als standard zumindest für neue Datenbanken zu empfehlen.
Bei bereits bestehenden kann dieser Index natürlich einfach als normaler Index verwendet werden.
INDEX `DbLog2.13` (`TIMESTAMP`, `DEVICE`, `READING`) USING BTREE;
Achtung: Diese Indexe sind aktuell vorschläge und werden im Moment noch sehr ausgiebig in unterschiedlichsten Konstellationen getestet!
Denn im Updatefall müssten zuvor bereits bestehende doppelte Einträge bereinigt werden.
Mit der Umkopier-Methode, die hier schon mehrmals beschrieben war, ist dies im Prinzip auch leicht möglich.
Eventuell ergänzen wir sogar eine Funktion: "verifyDB" und "upgradeDB", die diese Schritte für den User übernimmt.
Warum denkst Du, sollte das bei SQLite nicht funktionieren?
CREATE TABLE [history](
[TIMESTAMP] TIMESTAMP,
[DEVICE] varchar(64),
[TYPE] varchar(64),
[EVENT] varchar(512),
[READING] varchar(64),
[VALUE] varchar(128),
[UNIT] varchar(32),
PRIMARY KEY([TIMESTAMP], [DEVICE], [TYPE]) ON CONFLICT IGNORE) WITHOUT ROWID;
Sollte genauso funktionieren, jedoch habe ich das noch nicht getestet.
Das Updatescript für SqLite würde in etwa so aussehen:
SAVEPOINT [dblog_db_upgrade_transaction];
CREATE TABLE [historyTMP](
[TIMESTAMP] TIMESTAMP,
[DEVICE] varchar(64),
[TYPE] varchar(64),
[EVENT] varchar(512),
[READING] varchar(64),
[VALUE] varchar(128),
[UNIT] varchar(32),
PRIMARY KEY([TIMESTAMP], [DEVICE], [TYPE]) ON CONFLICT IGNORE) WITHOUT ROWID;
ALTER TABLE [history] RENAME TO [historyWORK]; ALTER TABLE [historyTMP] RENAME TO [history];
RELEASE [dblog_db_upgrade_transaction];
SAVEPOINT [dblog_db_upgrade_transaction];
CREATE TABLE [historyNEW](
[TIMESTAMP] TIMESTAMP,
[DEVICE] varchar(64),
[TYPE] varchar(64),
[EVENT] varchar(512),
[READING] varchar(64),
[VALUE] varchar(128),
[UNIT] varchar(32),
PRIMARY KEY([TIMESTAMP], [DEVICE], [TYPE]) ON CONFLICT IGNORE) WITHOUT ROWID;
INSERT INTO [historyNEW]([TIMESTAMP], [DEVICE], [TYPE], [EVENT], [READING], [VALUE], [UNIT])
SELECT [TIMESTAMP], [DEVICE], [TYPE], [EVENT], [READING], [VALUE], [UNIT]
FROM [historyWORK];
ALTER TABLE [history] RENAME TO [historyTMP2]; ALTER TABLE [historyNEW] RENAME TO [history];
RELEASE [dblog_db_upgrade_transaction];
INSERT INTO [history]([TIMESTAMP], [DEVICE], [TYPE], [EVENT], [READING], [VALUE], [UNIT])
SELECT [TIMESTAMP], [DEVICE], [TYPE], [EVENT], [READING], [VALUE], [UNIT]
FROM [historyTMP2];
Am Update der Anleitungen würde ich mich natürlich beteiligen!
schönen Abend,
Joe
Hi Joe,
ZitatWarum denkst Du, sollte das bei SQLite nicht funktionieren?
Könnte sagen ... gebranntes Kind ;) Nein, ich dachte eher an deinen Patch. Die Syntax für den Insert passt, glaube ich, nicht für SQLite.
Müssen wir nochmal checken.
Muß jetzt aber echt los . Bis später mal ...
Grüße
Heiko
Zitat von: DS_Starter am 31 Januar 2017, 19:44:29
Hallo Garry, @all,
mit der angehängten Version 2.11.2 gelten die Feldlängenbegrenzungen mit den Attributen colEvent, colReading und colValue auch für SQLite Datenbanken. Es wird nun auch bei SQLite mit colEvent=0 das Feld EVENT nicht gefüllt.
HINWEIS:
Um die Kompatibilität mit dem bisherigen Verhalten keine Feldlängenbegrenzung bei SQLite vorzunehmen zu erhalten, gelten die Feldlängenbegrenzungen bei SQLite erst dann wenn eines der oben genannten Attribute gesetzt wird. Dann gelten aber ALLE im Internal COLUMNS angezeigten Feldlängen.
Unter Umständen sind sie dann anzupassen.
Garry, probiers mal bei dir aus. Denke es passt so... :)
Grüße
Heiko
Hallo Heiko,
funktioniert bei mir (AsyncMode=1)
Regards, Garry
Edit
Habe aber jetzt teilweise extrem hohe messungen wieder (400kW)
Nicht optimal!
Garry
Hallo Joe, @all,
anbei die Version 2.12.1_Test.
In dieser Version ist der Support für die Verwendung von Tabellen mit Primary Key für Nicht-SQLite DB's implementiert.
DbLog erkennt automatisch ob die Tabelle history und/oder current einen primary key gesetzt haben und verwendet dementsprechende Statements.
Das ist sowohl im synchronen als auch asynchronen Mode der Fall. Wird der PK wieder gelöscht und durch normale Indexe ersetzt, verwendet
DbLog wieder automatisch die bisherigen Statements.
Ich habe bei meinen MySQLs die bisherig verwendeten Indexe (mehrere weil DbRep verwendet) gelöscht und durch einen primary key auf der Tabelle
history ersetzt. Auf der current-Tabelle habe ich auch einen PK gesetzt (über die Sinnfälligkeit kann man sich sicherlich streiten, aber
ich wollte es probieren ).
Für die history-Tabelle habe ich diese Syntax verwendet:
ALTER IGNORE TABLE `history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);
Das "IGNORE" war bei mir nötig um auf der bereits gefüllten Tabelle den PK anlegen zu können da bereits duplicate rows vorhanden
waren. Sonst klappt es nicht und die Key Erstellung läuft auf Fehler.
Für die Current-Tabelle habe ich verwendet:
ALTER TABLE `current` ADD PRIMARY KEY (DEVICE, READING);
Vorher habe ich den Inhalt der Einfachneit halber mit "delete from current" gelöscht, da sie ja sofort wieder aufgebaut wird.
Die Erstellung der PK auf der history (ca. 950 MB) dauerte nur ein paar Minuten.
Die Ergebnisse sind bisher sehr positiv. Umfangreiche Kalkulationen (Jahresauswertungen) mit DbRep die ohne PK ca. 12s im Hintergrund
liefen, benötigen jetzt nur noch ca. 1,5s.
@Joe, schau dir mal den Code an ob du diesbzgl. noch etwas verändern würdest.
viele Grüße und einen schönen Sonntag
Heiko
Hi Garry,
ZitatEdit
Habe aber jetzt teilweise extrem hohe messungen wieder (400kW)
Nicht optimal!
Deine message kann ich nicht einordnen. Ich vermute es handelt sich um deine Messungen am Energiezähler an sich, d.h. die gemessenen Werte sind zu hoch.
best regards,
Heiko
Hallo Heiko,
Das klingt schon mal sehr vielversprechend,
vielen Dank für die Version! Ich bin am testen!! kurze Rückfrage: Du nutzt aktuell immer noch mehrere Indexe, oder?
Bezüglich Index zur current: Lt. meinen Tests ist das zumindest effizienter als die
separatem update und insert-Befehle, bei mySQL.
Generell könnte ich mir aber vorstellen, dass wir diese Tabelle gar nicht mehr benötigen, und vielleicht einen neuen Modus:
"History/Mem" statt (oder zusätzlich zu) "Hostpry/Current" anbieten.
Kann man testen, wieviel Speicher 4000 Datensätze in einer Memcache-Tabelle benötigt?
Ich denke, das sollten die meisten Systeme leisten können...
sG
Joe
Hi Joe,
ZitatDu nutzt aktuell immer noch mehrere Indexe, oder?
Nein, habe alles gelöscht und nur noch die oben beschriebenen PK im Einsatz.
ZitatGenerell könnte ich mir aber vorstellen, dass wir diese Tabelle gar nicht mehr benötigen, und vielleicht einen neuen Modus:
"History/Mem" statt (oder zusätzlich zu) "Hostpry/Current" anbieten.
Keine schlechte Idee. Die current braucht man ja nur wenn man die Vorschläge bei der Plot-erstellung haben möchte. Nachteil des Lesens aus dem Mem
ist für diesen Einsatzfall dass selten generierte Device/Reading-Kombinationen im Mem nicht enthalten sein können. Aber wenn man als User die Zusammenhänge kennt sollte eine zusätzliche "History/Mem"-Auswahl für DbLogType eine hilfreiche Möglichkeit sein.
ZitatKann man testen, wieviel Speicher 4000 Datensätze in einer Memcache-Tabelle benötigt?
Wüßte ad hoc nichts brauchbares. Aber wenn wir pro zu loggenden Event durchschnittlich 500 Byte annehmen (wahrscheinlich eher weniger), wären das ca. 2MB. Sollte m.M. nach kein Prob sein.
Grüße
Heiko
Hallo Heiko,
Danke für die Info!
Hast Du vor, die schon vorhandenen "doppelten" Einträge in der History zu finden und sie ggf. zu bereinigen?
Zitat von: DS_Starter am 05 Februar 2017, 16:32:38
... Nachteil des Lesens aus dem Mem
ist für diesen Einsatzfall dass selten generierte Device/Reading-Kombinationen im Mem nicht enthalten sein können. Aber wenn man als User die Zusammenhänge kennt sollte eine zusätzliche "History/Mem"-Auswahl für DbLogType eine hilfreiche Möglichkeit sein.
Nun, ein SQL der sämtliche Device/Reading_Kombinationen generiert, dauert bei mir aktuell 9 Sekunden.
Diesen könnte man ja nach dem Start von FHEM auslesen und damit die Memcache-Tabelle füllen, somit würde es diesen Nachteil erst gar nicht geben.
Gerade im ASync-Modus wäre es auch egal, wenn nach dem Systemstart diese Daten einmalig aus der DB gelesen werden würden.... nicht?
Eventuell sollten wir ein Reading erzeugen "dbLocked", auf das andere Module prüfen können. Wenn die DB durch ein Modul gelocked (also benutzt)
wird, können andere Module ihre Abfragen an die DB verschieben (vorallem wenn sie nicht zeitkritisch sind).... aber ich merke schon... ideen gibt es viele :D
schöne Grüße
Joe
Hi Joe,
ZitatHast Du vor, die schon vorhandenen "doppelten" Einträge in der History zu finden und sie ggf. zu bereinigen?
Wenn ich die Doku unter https://dev.mysql.com/doc/refman/5.7/en/alter-table.html richtig verstanden habe, werden allein schon durch den Einsatz dieser Option die duplicate rows deleted und (ich glaube) die erste vorhandene wird behalten.
Auszug aus der Doku:
Zitat.... If IGNORE is specified, only one row is used of rows with duplicates on a unique key. The other conflicting rows are deleted. Incorrect values are truncated to the closest matching acceptable value......
Ich sehe schon ... du hast viele Ideen :D Vielleicht hilft noch mal jemand mit das umzusetzen sonst wird das einen never ending story für mich (wollte ja eigentlich nur das Logging non-blocking gestalten) ;)
EDIT: Joe, nur beim Start sämtliche Device/Reading_Kombinationen auszulesen und im Mem bereitzustellen reicht nicht. Neue Device/Readings müssen
auch während des Betriebes bereitgestellt werden wenn sie erzeugt wurden. Ist also noch etwas mehr. Aber machbar sollte es sein.
Grüße,
Heiko
Mit dem Index Time,Device,Reading werden meine Plots langsamer erstellt als mit Device,Reading,Time.
Hallo zusammen,
erst einmal danke für Eure Überlegungen und Optimierungen an DBLog. Die Idee mit dem PK und dem Löschen der Duplikate finde ich sehr gut. Werde das auch bei mir machen, da immer mal wieder mehrfache, gleiche Einträge entstehen.
Spannend ist nur, wie der PK aufgebaut sein muss bzw. ob es weitere Indexe geben muss. Ein interessanter Artikel ist hier zu finden http://use-the-index-luke.com/de/sql/where/gleichheit/zusammengesetzte-schluessel (http://use-the-index-luke.com/de/sql/where/gleichheit/zusammengesetzte-schluessel). Hängt also ganz stark davon ab, wie auf die Daten bzw. auf welche Spalten zugegriffen wird.
Beste Grüße
Torsten
Zitat von: stromer-12 am 05 Februar 2017, 20:43:43
Mit dem Index Time,Device,Reading werden meine Plots langsamer erstellt als mit Device,Reading,Time.
Das sind leider sehr wenige Informationen, hast Du mehr für uns?!
Ist das gefühlt oder gemessen?
Hast Du den Index als normalen, oder mit PK angelegt? Hast Du auch das Modul aus #50 installiert? Nur dieses unterstützt PKs und würde eine Verlangsamerung erklären.
Waren das ältere readings oder gar Auswertungen über besonders lange Zeiträume? (Jahre, etc?)
War im Device eventuell sogar eine Wildcard enthalten?
Ich würde das dann in meine Testumgebung mit aufnehmen um ggf. weitere Änderungen aufzunehmen!
Oder Bitte um nähere Details!
sG
Joe
Zitat von: ToKa am 05 Februar 2017, 20:58:31
erst einmal danke für Eure Überlegungen und Optimierungen an DBLog. Die Idee mit dem PK und dem Löschen der Duplikate finde ich sehr gut. Werde das auch bei mir machen, da immer mal wieder mehrfache, gleiche Einträge entstehen.
Hallo Torsten,
Danke fürs einbringen und die Rückmeldung!
FHEM selbst nutzt eigentlich sehr wenige Abfragen an die DB, ausgenommen Plots.
Hier sind mehrere Indexe sicherlich nicht zu empfehlen.
Aktuell betreibe ich eine recht große Testinstallation, um mehr oder weniger automatisiert tausende Tests durchzuführen.
Hauptziel ist es, ein performantes System auch für kleinere Rechner (zB RPI) zu erhalten, was ohne jeglicher Änderung leider mit
Datenbanksystemen nicht so direkt tauglich ist. Verschiedene Datenbankkonfigurationen spielen hier ebenfalls eine Rolle.
Ob alle Spezialmodule mit dem Standardindex auskommen können oder für diese Zwecke ein zusätzlicher Index (wie es ja im Moment auch schon der Fall ist)
empfohlen werden, hängt von den einzelnen Tests ab.
Hast Du einen konkreten Anwendungsfall, dessen Performance zu wünschen übrig lässt?
sG
Joe
Zitat von: JoeALLb am 05 Februar 2017, 21:06:50
Oder Bitte um nähere Details!
Ich hatte die komplette Datenbank auf den Primärindex umgestellt mittels umkopieren.
Getestet mit der normalen DbLog Version mit eingefügten IGNORE.
Plots ganz normal für die letzten 24Stunden.
Selbst ganz einfache Plots mit der Syntax: #myDbLog <Device>:<Reading>
wurden langsamer dargestellt.
Ich hatte sogar plotfork abgeschaltet, damit sich die Plots nicht gegenseitig beinflussen.
Hallo Joe,
ich nutze die DB-Daten vorwiegend für Plots. Insofern habe ich keine anderen, speziellen Anforderungen. Meine mysql DB läuft zudem nicht auf dem FHEM RPi, sondern auf einem anderen Server unter Ubuntu. Das Schreiben und Lesen der Daten über's Netz funktioniert prima und durch das Puffern der Daten spielt es auch keine Rollen, wenn ich den DB-Server mal neustarte.
Gruß
Torsten
Zitat von: JoeALLb am 30 Januar 2017, 12:09:02
Und welchen Index hast Du aktuell auf der Tabelle?
...
Würdest Du sagen, dass deine Abfrage schon dazugehört, denn automatisch (also vom Modul) wird diese, so denke ich, so niemals an die Datenbank abgesetzt.
...
Hallo Joe, komme erst jetzt zum antworten. sorry...
Genau, ich verwende den Standard-Index (ohne PK), wie in Deinem Testscript:
INDEX `DbLogDefault` (`DEVICE`, `READING`, `TIMESTAMP`)Die Abfrage ohne "where" ist die Standardeinstellung in phpmyAdmin, wenn ich auf die Tabelle klicke. Leider hab ich noch keinen Weg gefunden, wie ich das anpassen kann. Ich klick einfach nicht mehr drauf!
Diese Abfrage gehört aber keinesfalls zu den Standardabfragen von Fhem würde ich sagen! Wir können Sie, m.M.n. außen vor lassen!
Hauptsächlich erstelle ich Plots, das ist bei mir der Hauptanwendungsfall. Direkt in der DB über phpmyAdmin bewege ich mich nur im Problem- bzw. Fehlerfall. Dafür habe ich aber eher auch solche select-Abfragen, wie Du Sie einen Beitrag weiter unten beschreibst:
SELECT * FROM `history` where device='Wohnzimmer' and reading='measured-temp' ORDER BY `TIMESTAMP` DESC limit 10;Mit dieser "verfeinerten" Abfrage läufts auch sehr performant!
Ich würde mal probieren den Index auf
INDEX `DbLogDefault` (`TIMESTAMP`, `READING`, `DEVICE`) umzustellen. Klingt logisch, dass dieser für Plots besser ist!
Meinst Du ich soll dafür eine neue Tabelle machen und die Werte umkopieren? Oder gibt es eine Möglichkeit einen alten Index zu löschen und einen neuen aufzubauen? Mehrere Index in der DB zu haben finde ich nicht so gut, deshalb lieber einen neuen erzeugen und den alten entfernen.
Ich möchte noch 2 weiter Punkte in den Raum werfen:
1. Wiki: so ein Thread ist ja schön, aber am Anfang ist es gerade für "Neulinge" zu denen ich mich auch noch zähle, wichtig einen Platz zu haben an dem die aktuellen Erkenntnisse bzw. Vorgehensweisen in Verbindung mit dem aktuellen Versionsumfang des DbLog-Moduls dokumentiert sind. Vielleicht könnte man da am Ende, wenn klar ist welche Index, in welcher Kombi mit oder ohne PK usw. für den "Standard"-User bzw. den "Advanced"-User die Richtige ist. Auch eine kurze Erklärung bzgl. DB-Typen (z.B. Aria vs. innoDB) oder wozu ist ein Index oder PK gut, wäre da gut aufgehoben meine ich. Ich weiß, alles viel Arbeit, aber ich wollts mal ansprechen, denn ich habe so langsam auch meine Mühe den tlws. sehr fachlichen Diskussionen und Ideen gänzlich zu folgen...
2. Event-Logging: coole Idee, über colEvent=0 die Events nicht mitzuloggen! Ich bin kurz davor auch auf die Events zu verzichten und meine DB dementsprechend auch rückwirkend zu leeren. Aber bevor ich das tue, wollte ich fragen, ob Ihr einen Anwendungsfall habt, wo Ihr das Event in der DB braucht?
so, wieder viel zu viel Text ::)
VG...
Zitat von: DS_Starter am 05 Februar 2017, 15:49:33
Hi Garry,
Deine message kann ich nicht einordnen. Ich vermute es handelt sich um deine Messungen am Energiezähler an sich, d.h. die gemessenen Werte sind zu hoch.
best regards,
Heiko
Ich habe Gestern alles auf ein pi3 mit Dietpi(minimal Jessie installation) und Mysql umgebaut. Ich vermute das die 400kw readings waren einfach timing Problemen mit der alte Pi1.
Es sieht viel besser aus obwohl ich weiss das eigentlich fhem kein Echtzeit system ist.
Regards, Garry
hallo!
Zitat von: friesenjung am 06 Februar 2017, 11:32:07
Ich würde mal probieren den Index auf INDEX `DbLogDefault` (`TIMESTAMP`, `READING`, `DEVICE`) umzustellen. Klingt logisch, dass dieser für Plots besser ist!
Wenn Du es nicht eilig hast, warte noch etwas ab. Jemand meinte, dass ein anderer besser funktionieren könnte und ich bau mir gerade eine recht große
testumgebung auf, um das noch etwas detailierter testet zu können! Ansonsten kannst Du das gerne machen!
Zitat von: friesenjung am 06 Februar 2017, 11:32:07
Meinst Du ich soll dafür eine neue Tabelle machen und die Werte umkopieren?
Oder gibt es eine Möglichkeit einen alten Index zu löschen und einen neuen aufzubauen?
Umkopieren, oder du nutzt async=1 und stellst den wert
syncInterval entsprechend hoch ...
Solch eine Möglichkeit kenne ich bei Mysql etc. nicht.
Zitat von: friesenjung am 06 Februar 2017, 11:32:07
Mehrere Index in der DB zu haben finde ich nicht so gut, deshalb lieber einen neuen erzeugen und den alten entfernen.
Wäre aber für Tabellen prinzipiell nichts ungewöhnliches...
Zu Wiki: Wir suchen Helfer, die uns 1.) beim code schreiben und 2.) auch bei der Doku im Wiki helfen. Ich kann das leide rnicht übernehmen, könnte lediglich "korrekturlesen" ...
Zu: Event-Logging: Ich nutze es nur im Debug-Fall, ansonsten kenne ich keinen Nutzen davon. Webradios schreiben dort beispielsweise den gespielte Lieder rein, das benötige ich aber nicht!
schöne Grüße
Joe
Zitat von: JoeALLb am 06 Februar 2017, 17:11:51
hallo!
Wenn Du es nicht eilig hast, warte noch etwas ab.
...
ok, dann warte ich erstmal ab.
Zitat von: JoeALLb am 06 Februar 2017, 17:11:51
Wäre aber für Tabellen prinzipiell nichts ungewöhnliches...
wie wird denn der richtige Index in der Abfrage berücksichtigt, wenn es mehrere gibt?
Zitat von: JoeALLb am 06 Februar 2017, 17:11:51
Zu Wiki: Wir suchen Helfer, die uns 1.) beim code schreiben und 2.) auch bei der Doku im Wiki helfen. Ich kann das leide rnicht übernehmen, könnte lediglich "korrekturlesen" ...
...
ich helfe gern. dazu muss ich es aber erst einmal richtig kapieren (siehe meine Frage weiter oben). wir können ja Themen (Überschriften) festlegen. Ich schreib was dazu und die "Spezialisten" lesen gegen.
Nur grundsätzlich müsste man vorher abklären wer beim Wiki die Hand drauf hat und die Arbeit verteilt...
Zitat von: JoeALLb am 06 Februar 2017, 17:11:51
Zu: Event-Logging: Ich nutze es nur im Debug-Fall, ansonsten kenne ich keinen Nutzen davon. Webradios schreiben dort beispielsweise den gespielte Lieder rein, das benötige ich aber nicht!
...
ok, ich glaub dann entferne ich die Events bei Gelegenheit...
VG
Hallo friesenjung, hi Joe,
ZitatOder gibt es eine Möglichkeit einen alten Index zu löschen und einen neuen aufzubauen?
Mit phpMyAdmin kannst du Indexe bequem löschen und neue aufbauen, selbsverständlich auch mehrere.
Zitatwie wird denn der richtige Index in der Abfrage berücksichtigt, wenn es mehrere gibt?
Diese Entscheidung übernimmt der Optimizer. Er ist Bestandteil des Datenbankmanagement-Systems. Im Detail habe ich mich auch noch nicht beschäftigt, aber hier ist ein Einstieg in das Thema zu finden: http://use-the-index-luke.com/de/sql/anatomie/langsame-indizes
Ein kleines Beispiel macht das deutlcih. Habe nun zusätzlich zum PK auch noch den Search-Index wieder angelegt. Die Tabelle hat also diese zwei Indizes:
ALTER IGNORE TABLE `history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);
CREATE INDEX Search_Idx ON `history` (DEVICE, READING, TIMESTAMP);
Dann kann habe ich in phpMyAdmin dieses Statement ausgeführt.
SELECT * FROM `history` WHERE TIMESTAMP='2017-02-06 20:53:19' AND DEVICE='SMA_Energymeter' AND READING='state'
Welcher Index benutzt wird, sieht man wenn man den Link "SQL erklären" anklickt. In diesem Fall ist es der PK (SQL1 im Anhang).
Nach der Ausführung von:
SELECT * FROM `history` WHERE DEVICE='SMA_Energymeter' AND READING='state' AND TIMESTAMP BETWEEN '2016-02-06 20:53:19' AND 2017-02-06 20:53:19'
zeigt "SQL erklären" jedoch dass diesmal der Search_Index verwendet wurde.
@Joe, es wird sinnvoll sein den Search_Index zusätzlich zum PK zu behalten da gerade Plots diese Time-range selects verwenden werden.
Grüße,
Heiko
Hallo Heiko,
ich seh mir das gerade genau an. Prinzipiell kann der PK auch Timeranges, er filtert aber bei großen gemischten Datenmengen im ersten Step weniger heraus...
SG
Joe
Hallo miteinander,
in der angehängten 93_DbLog_V2.12.2_Test ist nun auch der PK-Support für SQLIte implemnetiert.
Leider kann man (soviel ich weiß) auf SQLite nicht so einfach einen PK hinzufügen wie auf MySQL. Ich habe eine neue DB erstellt und den PK gleich beim Tabellencreate mit angegeben.
Auch hier ist eine deutliche Beschleunigung von DbRep-Abfragen/Auswertungen feststellbar.
Jetzt fehlt noch der Support für PostGreSQL. Dabei brauche ich eure Unterstützung. Die entsprechenden Befehle kann ich mir vllt. noch ausdenken, nur habe ich dafür keine Testumgebung.
@Joe, hast du in deinem Labor auch eine Postgre mit aufgebaut ?
Wer könnte mich diesbzgl. noch unterstützen .... Freiwillige bitte vortreten :D
EDIT: Joe, ich habe die Update-Statements nochmal gändert. Die waren nicht optimal weil ungenügende Unterstützung für update/insert in einem Schreitt. Jetzt ist es besser.
schönen Tag und VG
Heiko
Hallo Heiko,
Zitat von: DS_Starter am 07 Februar 2017, 08:34:07
@Joe, hast du in deinem Labor auch eine Postgre mit aufgebaut ?
Im Moment leider nein, aus Festplattenplatz-Gründen. Meine Testumgebung ist aktuell 120GB groß, mehr SSD-Platz habe ich auf dem Testserver nicht.
Sobald ich ein paar "exotische" Testvarianten aussondieren und somit löschen kann, werde ich PostGreSQL mit dazu aufnehmen.
Zitat von: DS_Starter am 05 Februar 2017, 17:05:19
Ich sehe schon ... du hast viele Ideen :D Vielleicht hilft noch mal jemand mit das umzusetzen sonst wird das einen never ending story für mich (wollte ja eigentlich nur das Logging non-blocking gestalten) ;)
Vielleicht haben ja Benni und Dan lust, an der weiteren Optimierung mitzuwirken?
Zitat von: DeeSPe
Gruß
Dan
Zitat von: Benni
Gruß Benni.
Zitat von: JoeALLb am 07 Februar 2017, 20:27:01
Vielleicht haben ja Benni und Dan lust, an der weiteren Optimierung mitzuwirken?
Generell habe ich nichts gegen "Mitwirken"! 8)
Hab noch 2-3 andere Baustellen, für die gerade wenig Zeit ist.
Bin auch bisher, bis auf die Funktion DbLog_ExecSQL und eigene Nutzung von DbLog, noch NULL mit dem Modul vertraut! ;)
Wenn sich die Programmierarbeit in kleinere Tasks zerlegen lässt bin ich gerne bereit (Teil)Funktionen beizusteuern.
Gruß
Dan
Nabend miteinander,
es ist bestimmt nicht einfach im gegenwärtigen Fluß Einzelaufgaben zu verteilen. Momentan habe ich selbst noch verschiedene Releasestände zu verwalten die hier im Test sind und erst nach und nach eingecheckt werden. Ist mühsam und muß aufpassen nicht durcheinder zu kommen.
Hilfe ist natürlich immer gern willkommen :). Manchmal reicht es schon wenn ein anderer mal über ein Problem schaut weil man selbst feststeckt und den Wald vor lauter Bäumen nicht sieht.
In DbLog schreibe ich auf jeden Fall immer die Commandref weiter. Aber, wie schon festgestellt wurde, wäre es auch wichtig die Features im Wiki zu beschreiben damit die Nutzer nachlesen können was man mit dem asynchronen Mode anstellen kann, welche Vor- und Nachteile er hat und wie es geht.
Wenn sich jemand darum kümmern könnte, wäre das schon eine ungemeine Bereicherung und Unterstützung !
So wie Dan geht es mir auch ... habe noch zwei eigene Module die ich zu Gunsten von DbLog sträflich vernachlässige ... ich hoffe die User von DbRep und SSCam bzw. SMAInverter (kommissarisch) sehen es mir nach .. ;)
Die nächsten direkten Ziele sind:
* reduceLog non-blocking gestalten. Finde ich sehr wichtig weil es FHEM stark beeinträchtigt wenn es genutzt wird
* PK Support für Postgre (schon erwähnt)
Dan, könnte mir vorstellen dass du, wenn du magst, dir die reducelog-Funktion vornehmen könntest um sie auf Blockingcall umzustellen oder mich dabei zu unterstützen.
Grüße
Heiko
Zitat von: DS_Starter am 07 Februar 2017, 20:58:47
Dan, könnte mir vorstellen dass du, wenn du magst, dir die reducelog-Funktion vornehmen könntest um sie auf Blockingcall umzustellen oder mich dabei zu unterstützen.
Daran habe ich auch als Erstes gedacht! Wo ich doch gerade warm geworden bin mit BlockingCall! :D :D :D
Ich schaue mir das mal in den kommenden Tagen an! Evtl. kann ich ja dabei meine SQL Query Kenntnisse mal wieder etwas auffrischen. Versprechen will ich aber so schnell nicht die Top-Lösung. 8)
Kann ich diesbezüglich auf der aktuellen in SVN verfügbaren Modul Version aufbauen? Gab's da überhaupt irgendwelche Änderungen dran von Euch?
Gruß
Dan
ZitatWo ich doch gerade warm geworden bin mit BlockingCall! :D :D :D
Genau :D Kein Stress, mache erstmal und ich gucke dann auch noch drüber. Ideal wäre vllt. die non-blocking reducelog parallel zum bisherigen reducelog einzubauen um Vergleichsläufe machen zu können.
Als Grundlage nimm am Besten das hier angehängte Modul V2.12.3.
Hier habe ich heute Abend noch ein "set ... clearReadings" eingebaut damit man auch mal Readings wieder los wird die von verschiedenen Funktionen geschrieben werden. In das SVN will ich die Tage die V 2.11.4 einchecken, die schon gut ausgetestet ist.
@all, ihr könnt gern die clearReadings Funktion mit dem angehängten Modul bei euch probieren.
Grüße
Heiko
@DS_Starter
andere Idee zum Umgang mit der Current-Tabelle:
Wenn wir den Inhalt der Current-Tabelle im Speicher behalten, und diesen nur beim Neustart von FHEM in die Current-Tabelle schreiben? (analog zum aktuellen stat-file).
Zusätzlich könnten wir noch einen setter "rereadCurrent" (oder ähnlich) erzeugen. Das wäre von der Performance her das absolut beste und
würde auch einen kleinen RPI kaum belasten.
Hi Joe,
ich bin mir gerade nicht sicher ob es sinnvoll ist soviel Kraft in die current-Tabelle zu investieren. Ein select auf diese Tabelle passiert ja nur wenn man mal eine neue SVG-Definition mit der Unterstützung durch Vorschlagswerte anlegen will. Der advanced User wird die vermutlich nicht immer mitlaufen/ beschreiben lassen und abschalten bzw. bei Bedarf mal zuschalten. Obendrein enthält sie typischerweise nur wenige Datensätze auch wenn es ein paar hundert sein sollten.
Ich würde die Energie eher auf die Umsetzung solcher Dinge wie "Direktes addLog in die Datenbank statt über Trigger" aus deiner Liste am Anfang verwenden wollen. Das wäre ein schönes Feature finde ich.
Aber was ich wirklich bräuchte wäre ein engagierter Tester für die Unterstützung von PK bei PostgreSQL. Ich glaube passende Statements gefunden zu haben und baue die nächste Version auch zügig. Nur mit dem Test hapert es nun.
Grüße
Heiko
Hallo alle,
Eine Idee:
Mysql hat Untersstutzung fur Sekundenbruchteile https://dev.mysql.com/doc/refman/5.7/en/fractional-seconds.html (https://dev.mysql.com/doc/refman/5.7/en/fractional-seconds.html).
Damit waere ein PK fuer TIMESTAMP allein eindeutig.
Korrektur:
Erst ab Mysql version 5.6, aber mit MariaDB muss es moeglich sein auf der Pi.
Regards, Garry
Zitat von: DS_Starter am 08 Februar 2017, 18:30:32Aber was ich wirklich bräuchte wäre ein engagierter Tester für die Unterstützung von PK bei PostgreSQL. Ich glaube passende Statements gefunden zu haben und baue die nächste Version auch zügig. Nur mit dem Test hapert es nun.
Ich setze PostgreSQL ein und würde mich als Tester zur Verfügung stellen.
Reicht eine Kopie der History Tabelle und Konsole die Befehle ausführen oder wird eine vollständige FHEM Inst benötigt? (Beides wäre möglich)
Hallo Pyro,
prima... danke ! :)
Anbei die V2.12.4.
Hier ist der PK Support erstmal nur für die history-Tabelle integriert. Wir schauen zunächst ob das klappt.
Welche Konstellation du wählst ist eigentlich egal solange du dir eine zweite DB, zb. fhemtest, mit einer kopierten (oder neuen leeren) history-Tabelle zur Verfügung hast mit der du spielen kannst.
Dann definierst du dir ein zweites DbLog-Device und ein DEF mit dem auch Events geloggt werden. Ohne weitere Massnahmen soll bis hierher alles wie gewohnt laufen und die events in die history geschrieben werden.
Dann legst du dir in der DB den PK an:
ALTER TABLE `history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);
Möglicherweise einfach über dein DB Management-Tool. Wenn alles richtig läuft, geht alles wie gewohnt weiter. Erst mit verbose 5 sieht man Unterschiede. Hier mal ein Beispiel mit MySQL:
2017.02.09 18:28:23.534 4: DbLog LogDB -> ################################################################
2017.02.09 18:28:23.534 4: DbLog LogDB -> ### start of new Logcycle ###
2017.02.09 18:28:23.534 4: DbLog LogDB -> ################################################################
2017.02.09 18:28:23.534 4: DbLog LogDB -> amount of events received: 5 for device: sysmon
2017.02.09 18:28:23.534 4: DbLog LogDB -> check Device: sysmon , Event: stat_cpu_percent: 1.73 0.00 0.49 97.43 0.17 0.00 0.18
2017.02.09 18:28:23.535 4: DbLog LogDB -> added event - Timestamp: 2017-02-09 18:28:23, Device: sysmon, Type: SYSMON, Event: stat_cpu_percent: 1.73 0.00 0.49 97.43 0.17 0.00 0.18, Reading: stat_cpu_percent, Value: 1.73 0.00 0.49 97.43 0.17 0.00 0.18, Unit:
2017.02.09 18:28:23.535 4: DbLog LogDB -> check Device: sysmon , Event: eth0_diff: RX: 0.24 MB, TX: 0.33 MB, Total: 0.57 MB
2017.02.09 18:28:23.536 4: DbLog LogDB -> added event - Timestamp: 2017-02-09 18:28:23, Device: sysmon, Type: SYSMON, Event: eth0_diff: RX: 0.24 MB, TX: 0.33 MB, Total: 0.57 MB, Reading: eth0_diff, Value: RX: 0.24 MB, TX: 0.33 MB, Total: 0.57 MB, Unit:
2017.02.09 18:28:23.536 4: DbLog LogDB -> check Device: sysmon , Event: loadavg: 0.02 0.07 0.09
2017.02.09 18:28:23.536 4: DbLog LogDB -> added event - Timestamp: 2017-02-09 18:28:23, Device: sysmon, Type: SYSMON, Event: loadavg: 0.02 0.07 0.09, Reading: loadavg, Value: 0.02 0.07 0.09, Unit:
2017.02.09 18:28:23.536 4: DbLog LogDB -> check Device: sysmon , Event: swap: Total: 1293.00 MB, Used: 3.53 MB, 0.27 %, Free: 1289.46 MB
2017.02.09 18:28:23.536 4: DbLog LogDB -> added event - Timestamp: 2017-02-09 18:28:23, Device: sysmon, Type: SYSMON, Event: swap: Total: 1293.00 MB, Used: 3.53 MB, 0.27 %, Free: 1289.46 MB, Reading: swap, Value: Total: 1293.00 MB, Used: 3.53 MB, 0.27 %, Free: 1289.46 MB, Unit:
2017.02.09 18:28:23.536 4: DbLog LogDB -> check Device: sysmon , Event: ram: Total: 876.27 MB, Used: 229.55 MB, 26.20 %, Free: 646.71 MB
2017.02.09 18:28:23.537 4: DbLog LogDB -> added event - Timestamp: 2017-02-09 18:28:23, Device: sysmon, Type: SYSMON, Event: ram: Total: 876.27 MB, Used: 229.55 MB, 26.20 %, Free: 646.71 MB, Reading: ram, Value: Total: 876.27 MB, Used: 229.55 MB, 26.20 %, Free: 646.71 MB, Unit:
2017.02.09 18:28:23.547 5: DbLog LogDB -> Primary Key used in fhemtest.history: TIMESTAMP DEVICE READING
2017.02.09 18:28:23.547 5: DbLog LogDB -> Primary Key used in fhemtest.current: none
2017.02.09 18:28:23.547 4: DbLog LogDB -> processing event Timestamp: 2017-02-09 18:28:23, Device: sysmon, Type: SYSMON, Event: stat_cpu_percent: 1.73 0.00 0.49 97.43 0.17 0.00 0.18, Reading: stat_cpu_percent, Value: 1.73 0.00 0.49 97.43 0.17 0.00 0.18, Unit:
2017.02.09 18:28:23.547 4: DbLog LogDB -> processing event Timestamp: 2017-02-09 18:28:23, Device: sysmon, Type: SYSMON, Event: eth0_diff: RX: 0.24 MB, TX: 0.33 MB, Total: 0.57 MB, Reading: eth0_diff, Value: RX: 0.24 MB, TX: 0.33 MB, Total: 0.57 MB, Unit:
2017.02.09 18:28:23.547 4: DbLog LogDB -> processing event Timestamp: 2017-02-09 18:28:23, Device: sysmon, Type: SYSMON, Event: loadavg: 0.02 0.07 0.09, Reading: loadavg, Value: 0.02 0.07 0.09, Unit:
2017.02.09 18:28:23.547 4: DbLog LogDB -> processing event Timestamp: 2017-02-09 18:28:23, Device: sysmon, Type: SYSMON, Event: swap: Total: 1293.00 MB, Used: 3.53 MB, 0.27 %, Free: 1289.46 MB, Reading: swap, Value: Total: 1293.00 MB, Used: 3.53 MB, 0.27 %, Free: 1289.46 MB, Unit:
2017.02.09 18:28:23.547 4: DbLog LogDB -> processing event Timestamp: 2017-02-09 18:28:23, Device: sysmon, Type: SYSMON, Event: ram: Total: 876.27 MB, Used: 229.55 MB, 26.20 %, Free: 646.71 MB, Reading: ram, Value: Total: 876.27 MB, Used: 229.55 MB, 26.20 %, Free: 646.71 MB, Unit:
2017.02.09 18:28:23.553 4: DbLog LogDB -> 5 of 5 events successfully inserted into table history
2017.02.09 18:28:23.558 5: DbLog LogDB -> 5 events successfully inserted or replaced in table current using primary key
2017.02.09 18:28:23.639 5: DbLog LogDB -> DbLog_Push Returncode: 0
Die farbigen Stellen sollten erkennen lassen dass DbLog den gesetzten PK erkennt. Die Werte sollten in die DB geschrieben werden, aber jetzt können auch Fehler auftreten wenn z.B. ein Satz wegen eines vorhandenen Duplicates nicht geschrieben wird. Dieser Fehler wäre dann i.O., das muß man wissen !
EDIT: So sieht der Fehler auf, wenn er durch die duplicate row verursacht wird (sorry hatte falsche Meldung von meinem Testsystem kopiert):
2017.02.10 07:18:20.129 3: DbLog LogDB -> Failed to insert into history - Device: Rep.Show.DbSize, Event: done
2017.02.10 07:28:50.686 3: DbLog LogDB -> Failed to insert into history - Device: Rep.Show.DbSize, Event: done
2017.02.10 07:48:41.507 3: DbLog LogDB -> Failed to insert into history - Device: Rep.Show.DbSize, Event: done
2017.02.10 08:08:32.183 3: DbLog LogDB -> Failed to insert into history - Device: Rep.Show.DbSize, Event: done
[/code]
Der PK-Support wird aber erst ab Postgre Version 9.5 funktionieren. Ich hoffe du hast mindestens dieses Release.
Wenn du getestet hast mache bitte ein paar verbose 5 Auszüge so wie oben jeweils im synch bzw. asynch mode.
Grüße
Heiko
Hallo Garry
Zitat von: Garry Hayne am 08 Februar 2017, 20:10:02
Eine Idee:
Mysql hat Untersstutzung fur Sekundenbruchteile https://dev.mysql.com/doc/refman/5.7/en/fractional-seconds.html (https://dev.mysql.com/doc/refman/5.7/en/fractional-seconds.html).
Damit waere ein PK fuer TIMESTAMP allein eindeutig.
Was genau versprichst Du dir davon?
DB-Einträge unter einer Sekunde machen für mich aus mehreren Gründen keinen SInn, aber ich würde gerne Deine Beweggründe erfahren!
SG Joe
Zitat von: JoeALLb am 09 Februar 2017, 19:40:42
Hallo GarryWas genau versprichst Du dir davon?
DB-Einträge unter einer Sekunde machen für mich aus mehreren Gründen keinen SInn, aber ich würde gerne Deine Beweggründe erfahren!
SG Joe
Hallo Joe, ich dachte es waere einfacher ein PK zu erstellen auf nur ein Feld. Ist meistens schneller. Ich habe es selbst aufgegeben schnelle events in eine DB zu schreiben, Fhem ist nicht dafuer geeignet.
Garry
Zitat von: Garry Hayne am 09 Februar 2017, 22:20:26
Hallo Joe, ich dachte es waere einfacher ein PK zu erstellen auf nur ein Feld. Ist meistens schneller. Ich habe es selbst aufgegeben schnelle events in eine DB zu schreiben, Fhem ist nicht dafuer geeignet.
FHEM ist eigentlich nicht langsam.....
und mit async=1 sind die events auch schnell gespeichert. Aber ja, ein Echtzeit-System wird es nie werden.
Dein Problem habe ich dennoch noch nicht ganz verstanden...
Bezüglich PK: Man könne als PK auch eine fortlaufende Nummer oder einen Zufallswert generieren,
das hat alles vor und Nachteile.
Hier geht es aber darum, zu verhindern, dass ein Device/reading zus selben Zeit loggt. Das macht für FHEM keinen Sinn und kann in Plots auch nicht geloggt werden.
Zusätzlich sind Löschungen ohne PK nicht eindeutig.
Sorry, falls ich hier nicht richtig bin, aber ich hab in letzter Zeit ziemlich viele Logeinträge dieser Art (vermutlich seit der Umstellung auf non-blocking?):
2017.02.10 09:27:37.454 3: DbLog benDbLog: Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user fhem
2017.02.10 09:27:37.455 3: DbLog benDbLog: Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2017.02.10 09:27:43.798 3: DbLog benDbLog: Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user fhem
2017.02.10 09:27:43.799 3: DbLog benDbLog: Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2017.02.10 09:28:03.964 3: DbLog benDbLog: Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user fhem
2017.02.10 09:28:03.965 3: DbLog benDbLog: Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2017.02.10 09:34:25.363 3: DbLog benDbLog: Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user fhem
2017.02.10 09:34:25.364 3: DbLog benDbLog: Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2017.02.10 09:36:54.618 3: DbLog benDbLog: Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user fhem
2017.02.10 09:36:54.619 3: DbLog benDbLog: Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2017.02.10 09:37:18.145 3: DbLog benDbLog: Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user fhem
2017.02.10 09:37:18.146 3: DbLog benDbLog: Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
Hallo VBS,
Passt schon. Solche Verbindungsmeldungen habe schon vorher, sahen nur anders aus und kamen evtl. Seltener. Es ist nur eine Info, kannst du mit verbose 2 im DbLog unterdrücken.
Grüße,
Heiko
Ok danke, kann ich machen. Aber besteht da nicht die Gefahr, dass ich damit auch andere, relevantere Logs wegfiltere?
Eher weniger. Richtige Fehler werden im Modul mit verbose 1 oder 2 generiert und würden dann natürlich auch ins Log gelangen. Dies Verbindungsinfos oben werden generiert wenn im synchronen Mode die gespeicherte Session zur DB aus irgendwelchen Gründen neu erstellt wurde/werden musste. Das nur zur Erläuterung dieser Meldung. Im asychronen Mode wird es diese Meldung in dieser Form sicherlich nicht geben.
Zitat von: DS_Starter am 09 Februar 2017, 18:35:16
Hallo Pyro,
prima... danke ! :)
Guten Abend Heiko,
ich habe zu danken für deinen Einsatz :)
Wir können alles gefahrlos probieren und keine Rücksicht nehmen.
Zitat von: DS_Starter am 09 Februar 2017, 18:35:16Hier ist der PK Support erstmal nur für die history-Tabelle integriert. Wir schauen zunächst ob das klappt.
Dann legst du dir in der DB den PK an:
ALTER TABLE `history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);
Der PK-Support wird aber erst ab Postgre Version 9.5 funktionieren. Ich hoffe du hast mindestens dieses Release.
Wenn du getestet hast mache bitte ein paar verbose 5 Auszüge so wie oben jeweils im synch bzw. asynch mode.
Ich setze 9.5 ein und erhalte beim Ausführen von
ALTER TABLE fhem.history ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);folgende Fehlermeldung
ERROR: could not create unique index "history_pkey"
DETAIL: Key ("timestamp", device, reading)=(2017-01-10 10:35:35, ESPEasy_ESP2_System, ram) is duplicated.
Nabend Pyro,
ja, du hast in deiner history schon duplcate rows. War bei mir genauso.
Versuche es mal mit
ZitatALTER IGNORE TABLE `history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);
Weiß allerdings nicht ob dieser Befehl MySQL-spezifisch ist. Möglicherweise heißt er bei Postgre anders um den PK trotz vorhandener Duplikate anlgen zu können. Probier mal, ich frage inzwischen Tante Google ...
EDIT: Also ich finde zu Postgre eigentlich nur, dass man in dieser Situation mit entsprechenden SQLs versucht die doppelten Sätze herausbekommen und dann löschen muß.
Hmmm ... wenn es geht dann würde ich vorschlagen die Test-history zu leeren "delete from history". Dann den PK wie beim ersten Versuch anlegen und DbLog dann loggen lassen um mit dem Test voranzukommen.
Wenn der Inhalt wichtig für dich ist, dann mache dir bitte vorher ein Backup damit du es später wieder einpielen kannst wenn nötig.
Leider nein.
Hier wird beschrieben wie man doppelte Einträge löscht, wobei ich noch überlege wie man dass an die history Tabelle anpassen kann.
http://www.it-iss.com/mysql/sql-removing-duplicate-records/ (http://www.it-iss.com/mysql/sql-removing-duplicate-records/)
Ja, so etwas ähnliches habe ich zur Problemlösung bei Postgre auch gefunden. -> aufwändig. Deswegen würde ich für das Testscenario erstmal mit einer leeren history arbeiten wie in meinem EDIT oben geschrieben ... wenn es geht .
Einfachere Lösung scheint (weiter unten) gefunden.
Hallo Pyro,
nachdem ich deinen Link etwas genauer gelesen habe könnte das folgende Statement eventuell funktionieren um die rows zu löschen:
DELETE FROM history WHERE ctid IN (SELECT MAX(ctid) FROM history GROUP BY TIMESTAMP, DEVICE, READING HAVING COUNT(*) > 1);
Zitat von: DS_Starter am 10 Februar 2017, 21:56:01
Ja, so etwas ähnliches habe ich zur Problemlösung bei Postgre auch gefunden. -> aufwändig.
Ich habe es jetzt mal versucht und es schaut ganz gut aus:
DELETE FROM fhem.history WHERE TIMESTAMP IN (SELECT MAX(TIMESTAMP) FROM fhem.history GROUP BY TIMESTAMP, DEVICE, READING HAVING COUNT(*) > 1);
DELETE 421030
Query returned successfully in 25 secs.ALTER TABLE fhem.history ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);
ALTER TABLE
Query returned successfully in 14 secs.
Prima :) ...
Jetzt bin ich gespannt ob die Insert-Statements im Modul klappen ...
Auszug ausm Log:
2017.02.10 23:09:27 5: DbLog myDbLog -> Primary Key used in fhemdaten.history: "timestamp" device reading
2017.02.10 23:09:27 5: DbLog myDbLog -> Primary Key used in fhemdaten.current: none
....
2017.02.10 23:09:27 5: DbLog myDbLog -> 3 of 3 events successfully inserted into table history
2017.02.10 23:09:27 5: DbLog myDbLog -> 3 of 3 events successfully updated in table current
Na das ist doch Klasse ! .. sehr schön :D
Darauf kann ich aufbauen und sehe mal zu auch noch den PK-Support für die current einzubauen. Das Verhalten liegt hier etwas anders weil wir versuchen wollen ein update oder insert in einem Step in die Tabelle zu bringen.
Aber heute nicht mehr.
Danke Pyro und gute Nacht. Melde mich wieder.
Heiko
Zitat von: DS_Starter am 10 Februar 2017, 23:19:40
Danke Pyro und gute Nacht. Melde mich wieder.
Danke, dir auch eine gute Nacht :)
Hallo Pyro,
habe jetzt nach langem hin und her wahrscheinlich eine Lösung für die current-Tabelle gefunden.
Probiers mal nach bewärtem Muster, der PK ist allerdings nur:
ALTER TABLE current ADD PRIMARY KEY (DEVICE, READING);
Die V2.12.5, hier angehängt, habe ich auch noch bzgl. der Log-Ausgaben für verbose 5 für die PK Unterstützung verbessert.
Sollte das so nicht funktionieren, kannst du im asynch mode die Zeile 1431 für diverse Versuche abändern. Im synch mode wäre das Zeile 1078.
Grüße
Heiko
spannend, was sich hier tut!!
Da ich PostgresQL nicht nutze, bin ich da im Moment weniger involviert, ich werde es aber noch in meinen Benchmark
mit aufnehmen, um die unterschiedlichen Geschwindigkeiten darstellen zu können.
Weiß jemand, warum DbLog die Datenabfrage mit
select * where 1=1...
beginnt?Ist das Programmtechnisch, um die anderen Statements mit "and" anhängen zu können?
Joe
Hallo Heiko,
auch in der current Tabelle waren Einträge doppelt vorhanden, aber nach einem "truncate" war das Problem beseitigt.
2017.02.11 13:53:10 5: DbLog myDbLog -> Start DbLog_PushAsync
2017.02.11 13:53:10 5: DbLog myDbLog -> Primary Key used in fhemdaten.history: timestamp,device,reading
2017.02.11 13:53:10 5: DbLog myDbLog -> Primary Key used in fhemdaten.current: device,reading
2017.02.11 13:53:10 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 13:53:07, Device: mySysMon, Type: SYSMON, Event: loadavg: 0.00 0.08 0.07, Reading: loadavg, Value: 0.00 0.08 0.07, Unit:
2017.02.11 13:53:10 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 13:53:07, Device: mySysMon, Type: SYSMON, Event: ram: Total: 3008.29 MB, Used: -2975.06 MB, -98.90 %, Free: 5552.51 MB, Reading: ram, Value: Total: 3008.29 MB, Used: -2975.06 MB, -98.90 %, Free: 5552.51 MB, Unit:
2017.02.11 13:53:10 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 13:53:07, Device: mySysMon, Type: SYSMON, Event: ens3_diff: RX: 0.04 MB, TX: 0.02 MB, Total: 0.06 MB, Reading: ens3_diff, Value: RX: 0.04 MB, TX: 0.02 MB, Total: 0.06 MB, Unit:
2017.02.11 13:53:10 5: DbLog myDbLog -> 3 of 3 events successfully inserted into table history using PK on columns timestamp,device,reading
2017.02.11 13:53:10 2: DbLog myDbLog -> Error: DBD::Pg::st execute_array failed: ERROR: syntax error at or near "EVENT"
LINE 2: ...STAMP, DEVICE=EXCLUDED.DEVICE, TYPE=EXCLUDED.TYPE EVENT=EXCL...
^ [err was 7 now 2000000000]
executing 3 generated 3 errors at ./FHEM/93_DbLog.pm line 1481.
2017.02.11 13:53:10 5: DbLog myDbLog -> DbLog_PushAsync finished
2017.02.11 13:53:10 5: DbLog myDbLog -> Start DbLog_PushAsyncDone
2017.02.11 13:53:10 5: DbLog myDbLog -> DbLog_PushAsyncDone finished
Ach ja, habe Kommata vergessen ...
Hier nochmal V2.12.5. Die andere Version nehme ich raus.
Hi Joe,
ZitatIst das Programmtechnisch, um die anderen Statements mit "and" anhängen zu können?
don't know. Aber deine Vermutung klingt plausibel.
Scheit zu funktionieren :)
2017.02.11 14:15:28 5: DbLog myDbLog -> Start DbLog_PushAsync
2017.02.11 14:15:28 5: DbLog myDbLog -> Primary Key used in fhemdaten.history: timestamp,device,reading
2017.02.11 14:15:28 5: DbLog myDbLog -> Primary Key used in fhemdaten.current: device,reading
2017.02.11 14:15:28 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 14:15:04, Device: ESPEasy_ESP2_Raum, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 14:15:28 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 14:15:04, Device: ESPEasy_ESP1_WW_WW, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 14:15:28 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 14:15:05, Device: ESPEasy_ESP1_KW_KW, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 14:15:28 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 14:15:06, Device: ESPEasy_ESP1_RA_UM, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 14:15:28 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 14:15:06, Device: ESPEasy_ESP1_FB_RL, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 14:15:28 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 14:15:07, Device: ESPEasy_ESP1_FW_UM, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 14:15:28 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 14:15:07, Device: ESPEasy_ESP1_FW_RL, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 14:15:28 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 14:15:07, Device: ESPEasy_ESP1_FW_VL, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 14:15:28 5: DbLog myDbLog -> 8 of 8 events successfully inserted into table history using PK on columns timestamp,device,reading
2017.02.11 14:15:28 5: DbLog myDbLog -> 8 of 8 events successfully updated in table current using PK on columns device,reading
2017.02.11 14:15:28 5: DbLog myDbLog -> DbLog_PushAsync finished
2017.02.11 14:15:28 5: DbLog myDbLog -> Start DbLog_PushAsyncDone
2017.02.11 14:15:28 5: DbLog myDbLog -> DbLog_PushAsyncDone finished
Welche Szenarien soll ich durchtesten?
Great :)
ZitatWelche Szenarien soll ich durchtesten?
Erstmal freuen :D
Dann würde ich vorschlagen folgendes zu testen:
1. asynch mode -> sowohl für history, current PK definiert
2. asynch mode -> nur PK für history
3. asynch mode -> nur PK für current
4. synch mode -> sowohl für history, current PK definiert
5. synch mode -> nur PK für history
6. synch mode -> nur PK für current
Dann kannst du bitte auch mal probieren wie das Modul sich verhält wenn der Nutzer z.B. für die current ein Feld noch hinzunimmt, also den PK so aufbaut wie für die history. Interessant wären auch die Ausgaben wenn man versucht tatsächlich einen Datensatz doppelt einzufügen. Möglicherweise kannst du das provozieren.
Zum Schluß leere mal deine current Tabelle und lasse sie neu aufbauen. Die entsprechenden Insert-Meldungen sollten dann auch im Log eingetragen werden und die Current-Tabelle gefüllt werden.
EDIT: ich vergaß, baue dir auch mal einen neuen Plot mit Hilfe der Vorschläge aus der current auf. Und schau ob die Inserts/Updates auch tatsächlich in den Tabellen ankommen, aber das hast du sicher schon kontrolliert ... ;)
EDIT2: auch mal in beiden Modi ganz ohne PK testen ob das nach wie vor gut klappt (also der Standard beim User)
LG
Heiko
Zitat von: DS_Starter am 11 Februar 2017, 14:41:37
Great :)
Erstmal freuen :D
Leider etwas zu früh gefreut, der Log aus meinem vorigen Beitrag war der letzte der erfolgreich in die history Tabelle geschrieben werden konnte, seitdem erhöht sich der CacheUsage ständig und der Log füllt sich damit:
....
2017.02.11 15:19:38 5: DbLog myDbLog -> 231 of 231 events successfully inserted into table history using PK on columns timestamp,device,reading
2017.02.11 15:19:38 2: DbLog myDbLog -> Error: DBD::Pg::st execute_array failed: ERROR: current transaction is aborted, commands ignored until end of transaction block [err was 7 now 2000000000]
executing 231 generated 228 errors at ./FHEM/93_DbLog.pm line 1481.
Das sollte uns noch nicht entmutigen. Die Statements funktionieren erstmal.
Habe hier gefunden: http://laurenthinoul.com/how-to-fix-postgres-error-current-transaction-is-aborted-commands-ignored-until-end-of-transaction-block/
Gib mal in deinem SQL-Editor:
rollback;
Zitat von: DS_Starter am 11 Februar 2017, 16:53:04Gib mal in deinem SQL-Editor:
rollback;
WARNING: there is no transaction in progress
ROLLBACK
Query returned successfully in 191 msec.Tante EDIT sagt:
current enthält lediglich einen Eintrag und dieser ist ebenfalls von 14:15, eindeutig zu wenig.
Stellt sich die Frage, ob wir überhaupt mit Transaktionen Daten eintragen müssen...
denn diese machen für eine einzelne Tabelle die nochdazu nur Logs schreibt eibentlich überpowert.
Es müssen ja keine "zusammenhänge" in mehreren Tabellen sicher komplett eingetragen werden.
Eventuell wäre auch
SET AUTOCOMMIT { = | TO } { ON | OFF }
(kurzfristig) eine Hilfe?
Schalte mal nur auf history um mit DbLogType = History. Danach nur auf current.
Wie sieht es dann aus ?
@Joe, ja, die Frage ist natürlich berechtigt.
@Joe, auf Transactionen zu verzichten ist IMHO nur im synchronen mode sinnvoll. Im asynch mode brauche ich den rollback um die misslungenen Insert wieder an den Cache zurückzugeben für den nächsten Versuch.
Wir sollten also ergründen warum die Postgre so reagiert hat.
Zitat von: DS_Starter am 11 Februar 2017, 17:03:12
Schalte mal nur auf history um mit DbLogType = History. Danach nur auf current.
Wie sieht es dann aus?
Als ich auf history umgestellt habe wurde der gesamte Cache erfolgreich in die DB geschrieben. (geprüft per Admin Tool)
Bei current erhalte ich folgende Fehlermeldung:
2017.02.11 17:14:51 5: DbLog myDbLog -> ################################################################
2017.02.11 17:14:51 5: DbLog myDbLog -> ### New database processing cycle ###
2017.02.11 17:14:51 5: DbLog myDbLog -> ################################################################
2017.02.11 17:14:51 5: DbLog myDbLog -> MemCache contains 5 entries to process
2017.02.11 17:14:51 5: DbLog myDbLog -> MemCache contains: 2017-02-11 17:14:48|mySysMon|SYSMON|ens3_diff: RX: 0.20 MB, TX: 4.60 MB, Total: 4.80 MB|ens3_diff|RX: 0.20 MB, TX: 4.60 MB, Total: 4.80 MB|
2017.02.11 17:14:51 5: DbLog myDbLog -> MemCache contains: 2017-02-11 17:14:48|mySysMon|SYSMON|fs_boot: Total: 472 MB, Used: 105 MB, 24 %, Available: 343 MB at /boot|fs_boot|Total: 472 MB, Used: 105 MB, 24 %, Available: 343 MB at /boot|
2017.02.11 17:14:51 5: DbLog myDbLog -> MemCache contains: 2017-02-11 17:14:48|mySysMon|SYSMON|ram: Total: 3008.29 MB, Used: -3847.19 MB, -127.89 %, Free: 5509.80 MB|ram|Total: 3008.29 MB, Used: -3847.19 MB, -127.89 %, Free: 5509.80 MB|
2017.02.11 17:14:51 5: DbLog myDbLog -> MemCache contains: 2017-02-11 17:14:48|mySysMon|SYSMON|fs_root: Total: 23551 MB, Used: 3131 MB, 15 %, Available: 19201 MB at /|fs_root|Total: 23551 MB, Used: 3131 MB, 15 %, Available: 19201 MB at /|
2017.02.11 17:14:51 5: DbLog myDbLog -> MemCache contains: 2017-02-11 17:14:48|mySysMon|SYSMON|loadavg: 0.00 0.01 0.00|loadavg|0.00 0.01 0.00|
2017.02.11 17:14:51 5: DbLog myDbLog -> DbLog_PushAsync called with timeout: 120
2017.02.11 17:14:51 5: DbLog myDbLog -> Start DbLog_PushAsync
2017.02.11 17:14:51 5: DbLog myDbLog -> Primary Key used in fhemdaten.history: timestamp,device,reading
2017.02.11 17:14:51 5: DbLog myDbLog -> Primary Key used in fhemdaten.current: device,reading
2017.02.11 17:14:51 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 17:14:48, Device: mySysMon, Type: SYSMON, Event: ens3_diff: RX: 0.20 MB, TX: 4.60 MB, Total: 4.80 MB, Reading: ens3_diff, Value: RX: 0.20 MB, TX: 4.60 MB, Total: 4.80 MB, Unit:
2017.02.11 17:14:51 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 17:14:48, Device: mySysMon, Type: SYSMON, Event: fs_boot: Total: 472 MB, Used: 105 MB, 24 %, Available: 343 MB at /boot, Reading: fs_boot, Value: Total: 472 MB, Used: 105 MB, 24 %, Available: 343 MB at /boot, Unit:
2017.02.11 17:14:51 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 17:14:48, Device: mySysMon, Type: SYSMON, Event: ram: Total: 3008.29 MB, Used: -3847.19 MB, -127.89 %, Free: 5509.80 MB, Reading: ram, Value: Total: 3008.29 MB, Used: -3847.19 MB, -127.89 %, Free: 5509.80 MB, Unit:
2017.02.11 17:14:51 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 17:14:48, Device: mySysMon, Type: SYSMON, Event: fs_root: Total: 23551 MB, Used: 3131 MB, 15 %, Available: 19201 MB at /, Reading: fs_root, Value: Total: 23551 MB, Used: 3131 MB, 15 %, Available: 19201 MB at /, Unit:
2017.02.11 17:14:51 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 17:14:48, Device: mySysMon, Type: SYSMON, Event: loadavg: 0.00 0.01 0.00, Reading: loadavg, Value: 0.00 0.01 0.00, Unit:
2017.02.11 17:14:51 2: DbLog myDbLog -> Error: DBD::Pg::st execute_array failed: ERROR: current transaction is aborted, commands ignored until end of transaction block [err was 7 now 2000000000]
executing 5 generated 4 errors at ./FHEM/93_DbLog.pm line 1481.
2017.02.11 17:14:51 5: DbLog myDbLog -> DbLog_PushAsync finished
2017.02.11 17:14:51 5: DbLog myDbLog -> Start DbLog_PushAsyncDone
2017.02.11 17:14:51 5: DbLog myDbLog -> DbLog_PushAsyncDone finished
Hmm... hat also tatsächlich nur etwas mit der current Tabelle zu tun. Da müssen wir doch nochmal an dem Statement schrauben. Ich weiß bloß noch nicht wo genau es haken könnte.
Um die Sperre zu lösen wird wahrscheinlich ein Restart der Postgre ausreichen. Schau mal ob der Fehler dann auf der current wiederkommt.
Muß erstmal nachdenken was an dem Statement nicht so ganz passt.
Ich habe auf current umgestellt, diese per truncate geleert und den ganzen Server neugestartet, danach zeigt das Log folgendes:
2017.02.11 17:48:23 5: DbLog myDbLog -> ################################################################
2017.02.11 17:48:23 5: DbLog myDbLog -> ### New database processing cycle ###
2017.02.11 17:48:23 5: DbLog myDbLog -> ################################################################
2017.02.11 17:48:23 5: DbLog myDbLog -> MemCache contains 8 entries to process
2017.02.11 17:48:23 5: DbLog myDbLog -> MemCache contains: 2017-02-11 17:47:51|ESPEasy_ESP1_FW_RL|ESPEASY|absent|state|absent|
2017.02.11 17:48:23 5: DbLog myDbLog -> MemCache contains: 2017-02-11 17:47:51|ESPEasy_ESP1_FW_VL|ESPEASY|absent|state|absent|
2017.02.11 17:48:23 5: DbLog myDbLog -> MemCache contains: 2017-02-11 17:47:51|ESPEasy_ESP2_Raum|ESPEASY|absent|state|absent|
2017.02.11 17:48:23 5: DbLog myDbLog -> MemCache contains: 2017-02-11 17:47:52|ESPEasy_ESP1_FB_RL|ESPEASY|absent|state|absent|
2017.02.11 17:48:23 5: DbLog myDbLog -> MemCache contains: 2017-02-11 17:47:52|ESPEasy_ESP1_WW_WW|ESPEASY|absent|state|absent|
2017.02.11 17:48:23 5: DbLog myDbLog -> MemCache contains: 2017-02-11 17:47:54|ESPEasy_ESP1_RA_UM|ESPEASY|absent|state|absent|
2017.02.11 17:48:23 5: DbLog myDbLog -> MemCache contains: 2017-02-11 17:47:54|ESPEasy_ESP1_KW_KW|ESPEASY|absent|state|absent|
2017.02.11 17:48:23 5: DbLog myDbLog -> MemCache contains: 2017-02-11 17:47:55|ESPEasy_ESP1_FW_UM|ESPEASY|absent|state|absent|
2017.02.11 17:48:23 5: DbLog myDbLog -> DbLog_PushAsync called with timeout: 120
2017.02.11 17:48:23 5: DbLog myDbLog -> Start DbLog_PushAsync
2017.02.11 17:48:23 5: DbLog myDbLog -> Primary Key used in fhemdaten.history: timestamp,device,reading
2017.02.11 17:48:23 5: DbLog myDbLog -> Primary Key used in fhemdaten.current: device,reading
2017.02.11 17:48:23 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 17:47:51, Device: ESPEasy_ESP1_FW_RL, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 17:48:23 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 17:47:51, Device: ESPEasy_ESP1_FW_VL, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 17:48:23 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 17:47:51, Device: ESPEasy_ESP2_Raum, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 17:48:23 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 17:47:52, Device: ESPEasy_ESP1_FB_RL, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 17:48:23 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 17:47:52, Device: ESPEasy_ESP1_WW_WW, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 17:48:23 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 17:47:54, Device: ESPEasy_ESP1_RA_UM, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 17:48:23 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 17:47:54, Device: ESPEasy_ESP1_KW_KW, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 17:48:23 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 17:47:55, Device: ESPEasy_ESP1_FW_UM, Type: ESPEASY, Event: absent, Reading: state, Value: absent, Unit:
2017.02.11 17:48:23 5: DbLog myDbLog -> 8 of 8 events successfully updated in table current using PK on columns device,reading
2017.02.11 17:48:23 5: DbLog myDbLog -> DbLog_PushAsync finished
2017.02.11 17:48:23 5: DbLog myDbLog -> Start DbLog_PushAsyncDone
2017.02.11 17:48:23 5: DbLog myDbLog -> DbLog_PushAsyncDone finished
...
...
...
2017.02.11 17:48:53 5: DbLog myDbLog -> ################################################################
2017.02.11 17:48:53 5: DbLog myDbLog -> ### New database processing cycle ###
2017.02.11 17:48:53 5: DbLog myDbLog -> ################################################################
2017.02.11 17:48:53 5: DbLog myDbLog -> MemCache contains 5 entries to process
2017.02.11 17:48:53 5: DbLog myDbLog -> MemCache contains: 2017-02-11 17:48:42|mySysMon|SYSMON|loadavg: 0.20 0.09 0.03|loadavg|0.20 0.09 0.03|
2017.02.11 17:48:53 5: DbLog myDbLog -> MemCache contains: 2017-02-11 17:48:42|mySysMon|SYSMON|ens3_diff: RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB|ens3_diff|RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB|
2017.02.11 17:48:53 5: DbLog myDbLog -> MemCache contains: 2017-02-11 17:48:42|mySysMon|SYSMON|fs_boot: Total: 472 MB, Used: 105 MB, 24 %, Available: 343 MB at /boot|fs_boot|Total: 472 MB, Used: 105 MB, 24 %, Available: 343 MB at /boot|
2017.02.11 17:48:53 5: DbLog myDbLog -> MemCache contains: 2017-02-11 17:48:42|mySysMon|SYSMON|fs_root: Total: 23551 MB, Used: 3132 MB, 15 %, Available: 19201 MB at /|fs_root|Total: 23551 MB, Used: 3132 MB, 15 %, Available: 19201 MB at /|
2017.02.11 17:48:53 5: DbLog myDbLog -> MemCache contains: 2017-02-11 17:48:42|mySysMon|SYSMON|ram: Total: 3008.29 MB, Used: -2813.61 MB, -93.53 %, Free: 5572.53 MB|ram|Total: 3008.29 MB, Used: -2813.61 MB, -93.53 %, Free: 5572.53 MB|
2017.02.11 17:48:53 5: DbLog myDbLog -> DbLog_PushAsync called with timeout: 120
2017.02.11 17:48:53 5: DbLog myDbLog -> Start DbLog_PushAsync
2017.02.11 17:48:53 5: DbLog myDbLog -> Primary Key used in fhemdaten.history: timestamp,device,reading
2017.02.11 17:48:53 5: DbLog myDbLog -> Primary Key used in fhemdaten.current: device,reading
2017.02.11 17:48:53 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 17:48:42, Device: mySysMon, Type: SYSMON, Event: loadavg: 0.20 0.09 0.03, Reading: loadavg, Value: 0.20 0.09 0.03, Unit:
2017.02.11 17:48:53 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 17:48:42, Device: mySysMon, Type: SYSMON, Event: ens3_diff: RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB, Reading: ens3_diff, Value: RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB, Unit:
2017.02.11 17:48:53 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 17:48:42, Device: mySysMon, Type: SYSMON, Event: fs_boot: Total: 472 MB, Used: 105 MB, 24 %, Available: 343 MB at /boot, Reading: fs_boot, Value: Total: 472 MB, Used: 105 MB, 24 %, Available: 343 MB at /boot, Unit:
2017.02.11 17:48:53 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 17:48:42, Device: mySysMon, Type: SYSMON, Event: fs_root: Total: 23551 MB, Used: 3132 MB, 15 %, Available: 19201 MB at /, Reading: fs_root, Value: Total: 23551 MB, Used: 3132 MB, 15 %, Available: 19201 MB at /, Unit:
2017.02.11 17:48:53 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 17:48:42, Device: mySysMon, Type: SYSMON, Event: ram: Total: 3008.29 MB, Used: -2813.61 MB, -93.53 %, Free: 5572.53 MB, Reading: ram, Value: Total: 3008.29 MB, Used: -2813.61 MB, -93.53 %, Free: 5572.53 MB, Unit:
2017.02.11 17:48:53 2: DbLog myDbLog -> Error: DBD::Pg::st execute_array failed: ERROR: current transaction is aborted, commands ignored until end of transaction block [err was 7 now 2000000000]
executing 5 generated 3 errors at ./FHEM/93_DbLog.pm line 1481.
2017.02.11 17:48:53 5: DbLog myDbLog -> DbLog_PushAsync finished
2017.02.11 17:48:53 5: DbLog myDbLog -> Start DbLog_PushAsyncDone
2017.02.11 17:48:53 5: DbLog myDbLog -> DbLog_PushAsyncDone finished
Sehr eigenartig finde ich folgendes
2017.02.11 17:48:23 5: DbLog myDbLog -> 8 of 8 events successfully updated in table current using PK on columns device,reading
Obwohl die Tabelle leer ist?
Tante EDIT sagt:
ich finde jetzt folgenden Eintrag in der current Tabelle:
"timestamp","device","type","event","reading","value","unit"
"2017-02-11 18:02:38","ESPEASY","absent","absent","","ESPEasy_ESP1_FB_RL","state"
Scheint als wäre nur die letzte Zeile übertragen worden.
ZitatObwohl die Tabelle leer ist?
Ja, der Update war für den DB-Treiber erstmal ok, aber der Commit der die Daten in der DB manifestiert klappt offensichtlich nicht. Deswegen sind die Daten letztlich nicht drin und der nachfolgende update geht auf die Bretter weil der davor immer noch auf den commit wartet der nicht funktioniert. Das ist was ich mir bis jetzt erkläre ...
Teste mal die angehängte V2.12.5, die andere nehme ich wieder raus. Habe einen Fehler in der Zuweisung der bind-parameter gefunden. Vllt. ist es das schon gewesen.
Die Postgre mußt du wieder restarten nachdem du das Modul eingespielt hast. sonst löst sich die Sperre nicht.
Jetzt hat sich mein EDIT und deine Antwort überschnitten, daher hier zur Sicherheit mein EDIT nochmal
ZitatTante EDIT sagt:
ich finde jetzt folgenden Eintrag in der current Tabelle:
"timestamp","device","type","event","reading","value","unit"
"2017-02-11 18:02:38","ESPEASY","absent","absent","","ESPEasy_ESP1_FB_RL","state"
Scheint als wäre nur die letzte Zeile übertragen worden.
Zitat von: DS_Starter am 11 Februar 2017, 18:11:32Teste mal die angehängte V2.12.5
Eingespielt, current Tabelle geleert und Server neugestartet
DbLogType Current
Current Tabelle erhält Einträge und bestehende werden auch aktualisiert.
DbLogType Current/History
Funktioniert nun ebenfalls, sprich current wird upgedatet und die history erhält Einträge dazu.
Dürfen wir uns jetzt wirklich freuen ? ;)
Mach mal bitte noch ein verbose 5 Log.
Zitat von: DS_Starter am 11 Februar 2017, 18:46:23
Dürfen wir uns jetzt wirklich freuen ? ;)
current erhält immer noch laufend Updates
History wird laufend um neue Einträge erweitert
Japp, jetzt scheint der richtige Zeitpunkt gekommen zu sein um sich zu freuen :) :) 8)
Und vor allem auch um ein Danke an dich zu richten ;)
Zitat von: DS_Starter am 11 Februar 2017, 18:46:23Mach mal bitte noch ein verbose 5 Log.
2017.02.11 18:47:45 5: DbLog myDbLog -> ################################################################
2017.02.11 18:47:45 5: DbLog myDbLog -> ### New database processing cycle ###
2017.02.11 18:47:45 5: DbLog myDbLog -> ################################################################
2017.02.11 18:47:45 5: DbLog myDbLog -> MemCache contains 3 entries to process
2017.02.11 18:47:45 5: DbLog myDbLog -> MemCache contains: 2017-02-11 18:47:40|mySysMon|SYSMON|loadavg: 0.00 0.01 0.00|loadavg|0.00 0.01 0.00|
2017.02.11 18:47:45 5: DbLog myDbLog -> MemCache contains: 2017-02-11 18:47:40|mySysMon|SYSMON|ram: Total: 3008.29 MB, Used: -3085.54 MB, -102.57 %, Free: 5547.84 MB|ram|Total: 3008.29 MB, Used: -3085.54 MB, -102.57 %, Free: 5547.84 MB|
2017.02.11 18:47:45 5: DbLog myDbLog -> MemCache contains: 2017-02-11 18:47:40|mySysMon|SYSMON|ens3_diff: RX: 0.03 MB, TX: 0.02 MB, Total: 0.05 MB|ens3_diff|RX: 0.03 MB, TX: 0.02 MB, Total: 0.05 MB|
2017.02.11 18:47:45 5: DbLog myDbLog -> DbLog_PushAsync called with timeout: 120
2017.02.11 18:47:45 5: DbLog myDbLog -> Start DbLog_PushAsync
2017.02.11 18:47:45 5: DbLog myDbLog -> Primary Key used in fhemdaten.history: timestamp,device,reading
2017.02.11 18:47:45 5: DbLog myDbLog -> Primary Key used in fhemdaten.current: device,reading
2017.02.11 18:47:45 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 18:47:40, Device: mySysMon, Type: SYSMON, Event: loadavg: 0.00 0.01 0.00, Reading: loadavg, Value: 0.00 0.01 0.00, Unit:
2017.02.11 18:47:45 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 18:47:40, Device: mySysMon, Type: SYSMON, Event: ram: Total: 3008.29 MB, Used: -3085.54 MB, -102.57 %, Free: 5547.84 MB, Reading: ram, Value: Total: 3008.29 MB, Used: -3085.54 MB, -102.57 %, Free: 5547.84 MB, Unit:
2017.02.11 18:47:45 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 18:47:40, Device: mySysMon, Type: SYSMON, Event: ens3_diff: RX: 0.03 MB, TX: 0.02 MB, Total: 0.05 MB, Reading: ens3_diff, Value: RX: 0.03 MB, TX: 0.02 MB, Total: 0.05 MB, Unit:
2017.02.11 18:47:45 5: DbLog myDbLog -> 3 of 3 events inserted into table history using PK on columns timestamp,device,reading
2017.02.11 18:47:45 5: DbLog myDbLog -> 3 of 3 events updated in table current using PK on columns device,reading
2017.02.11 18:47:45 5: DbLog myDbLog -> DbLog_PushAsync finished
2017.02.11 18:47:45 5: DbLog myDbLog -> Start DbLog_PushAsyncDone
2017.02.11 18:47:45 5: DbLog myDbLog -> DbLog_PushAsyncDone finished
...
...
...
2017.02.11 18:48:45 5: DbLog myDbLog -> ################################################################
2017.02.11 18:48:45 5: DbLog myDbLog -> ### New database processing cycle ###
2017.02.11 18:48:45 5: DbLog myDbLog -> ################################################################
2017.02.11 18:48:45 5: DbLog myDbLog -> MemCache contains 3 entries to process
2017.02.11 18:48:45 5: DbLog myDbLog -> MemCache contains: 2017-02-11 18:48:40|mySysMon|SYSMON|loadavg: 0.00 0.00 0.00|loadavg|0.00 0.00 0.00|
2017.02.11 18:48:45 5: DbLog myDbLog -> MemCache contains: 2017-02-11 18:48:40|mySysMon|SYSMON|ens3_diff: RX: 0.03 MB, TX: 0.01 MB, Total: 0.04 MB|ens3_diff|RX: 0.03 MB, TX: 0.01 MB, Total: 0.04 MB|
2017.02.11 18:48:45 5: DbLog myDbLog -> MemCache contains: 2017-02-11 18:48:40|mySysMon|SYSMON|ram: Total: 3008.29 MB, Used: -3085.08 MB, -102.55 %, Free: 5547.36 MB|ram|Total: 3008.29 MB, Used: -3085.08 MB, -102.55 %, Free: 5547.36 MB|
2017.02.11 18:48:45 5: DbLog myDbLog -> DbLog_PushAsync called with timeout: 120
2017.02.11 18:48:45 5: DbLog myDbLog -> Start DbLog_PushAsync
2017.02.11 18:48:45 5: DbLog myDbLog -> Primary Key used in fhemdaten.history: timestamp,device,reading
2017.02.11 18:48:45 5: DbLog myDbLog -> Primary Key used in fhemdaten.current: device,reading
2017.02.11 18:48:45 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 18:48:40, Device: mySysMon, Type: SYSMON, Event: loadavg: 0.00 0.00 0.00, Reading: loadavg, Value: 0.00 0.00 0.00, Unit:
2017.02.11 18:48:45 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 18:48:40, Device: mySysMon, Type: SYSMON, Event: ens3_diff: RX: 0.03 MB, TX: 0.01 MB, Total: 0.04 MB, Reading: ens3_diff, Value: RX: 0.03 MB, TX: 0.01 MB, Total: 0.04 MB, Unit:
2017.02.11 18:48:45 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 18:48:40, Device: mySysMon, Type: SYSMON, Event: ram: Total: 3008.29 MB, Used: -3085.08 MB, -102.55 %, Free: 5547.36 MB, Reading: ram, Value: Total: 3008.29 MB, Used: -3085.08 MB, -102.55 %, Free: 5547.36 MB, Unit:
2017.02.11 18:48:45 5: DbLog myDbLog -> 3 of 3 events inserted into table history using PK on columns timestamp,device,reading
2017.02.11 18:48:45 5: DbLog myDbLog -> 3 of 3 events updated in table current using PK on columns device,reading
2017.02.11 18:48:45 5: DbLog myDbLog -> DbLog_PushAsync finished
...
...
...
2017.02.11 18:54:46 5: DbLog myDbLog -> ################################################################
2017.02.11 18:54:46 5: DbLog myDbLog -> ### New database processing cycle ###
2017.02.11 18:54:46 5: DbLog myDbLog -> ################################################################
2017.02.11 18:54:46 5: DbLog myDbLog -> MemCache contains 5 entries to process
2017.02.11 18:54:46 5: DbLog myDbLog -> MemCache contains: 2017-02-11 18:54:26|myDbLog|DBLOG|countHistory: 2567557|countHistory|2567557|
2017.02.11 18:54:46 5: DbLog myDbLog -> MemCache contains: 2017-02-11 18:54:26|myDbLog|DBLOG|countCurrent: 19|countCurrent|19|
2017.02.11 18:54:46 5: DbLog myDbLog -> MemCache contains: 2017-02-11 18:54:40|mySysMon|SYSMON|loadavg: 0.00 0.00 0.00|loadavg|0.00 0.00 0.00|
2017.02.11 18:54:46 5: DbLog myDbLog -> MemCache contains: 2017-02-11 18:54:40|mySysMon|SYSMON|ram: Total: 3008.29 MB, Used: -3085.74 MB, -102.57 %, Free: 5547.39 MB|ram|Total: 3008.29 MB, Used: -3085.74 MB, -102.57 %, Free: 5547.39 MB|
2017.02.11 18:54:46 5: DbLog myDbLog -> MemCache contains: 2017-02-11 18:54:40|mySysMon|SYSMON|ens3_diff: RX: 0.05 MB, TX: 0.07 MB, Total: 0.12 MB|ens3_diff|RX: 0.05 MB, TX: 0.07 MB, Total: 0.12 MB|
2017.02.11 18:54:46 5: DbLog myDbLog -> DbLog_PushAsync called with timeout: 120
2017.02.11 18:54:46 5: DbLog myDbLog -> Start DbLog_PushAsync
2017.02.11 18:54:46 5: DbLog myDbLog -> Primary Key used in fhemdaten.history: timestamp,device,reading
2017.02.11 18:54:46 5: DbLog myDbLog -> Primary Key used in fhemdaten.current: device,reading
2017.02.11 18:54:46 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 18:54:26, Device: myDbLog, Type: DBLOG, Event: countHistory: 2567557, Reading: countHistory, Value: 2567557, Unit:
2017.02.11 18:54:46 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 18:54:26, Device: myDbLog, Type: DBLOG, Event: countCurrent: 19, Reading: countCurrent, Value: 19, Unit:
2017.02.11 18:54:46 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 18:54:40, Device: mySysMon, Type: SYSMON, Event: loadavg: 0.00 0.00 0.00, Reading: loadavg, Value: 0.00 0.00 0.00, Unit:
2017.02.11 18:54:46 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 18:54:40, Device: mySysMon, Type: SYSMON, Event: ram: Total: 3008.29 MB, Used: -3085.74 MB, -102.57 %, Free: 5547.39 MB, Reading: ram, Value: Total: 3008.29 MB, Used: -3085.74 MB, -102.57 %, Free: 5547.39 MB, Unit:
2017.02.11 18:54:46 5: DbLog myDbLog -> processing event Timestamp: 2017-02-11 18:54:40, Device: mySysMon, Type: SYSMON, Event: ens3_diff: RX: 0.05 MB, TX: 0.07 MB, Total: 0.12 MB, Reading: ens3_diff, Value: RX: 0.05 MB, TX: 0.07 MB, Total: 0.12 MB, Unit:
2017.02.11 18:54:46 5: DbLog myDbLog -> 5 of 5 events inserted into table history using PK on columns timestamp,device,reading
2017.02.11 18:54:46 5: DbLog myDbLog -> 5 of 5 events updated in table current using PK on columns device,reading
2017.02.11 18:54:46 5: DbLog myDbLog -> DbLog_PushAsync finished
2017.02.11 18:54:46 5: DbLog myDbLog -> Start DbLog_PushAsyncDone
2017.02.11 18:54:46 5: DbLog myDbLog -> DbLog_PushAsyncDone finished
Ich danke dir ! 8) Tests kosten (Frei-)Zeit und Mühe ...
Im Team kommt man eben wirklich weiter und Spaß macht es so auch mehr als nur im eigenen Saft zu schmoren :D
Schau mal noch ein bisschen rum ... synch mode usw. wie weiter vorn beschrieben ....
Ich teste auch noch etwas mit MySQL und SQLite ...
schönen Abend !
LG
Heiko
Servus Heiko!
Ich denke ich habe reduceLog non-blocking hinbekommen.
Zumindest arbeitet die Funktion und es kommt auch etwas zurück!
die Zeitangabe sieht noch etwas utopisch aus, vielleicht guckst Du Dir das nochmal an.
Per PN habe ich Dir einen Link auf meine Dropbox von der Dev Version geschickt.
Bitte schaue es Dir an und teste!
Danke.
Gruß
Dan
Hallo Dan, @all,
ich habe die Arbeit von Dan bzgl. der non-blocking reduceLog-Funktion in DbLog eingearbeitet und auch auf MySQL getestet.
Läuft bei mir auf MySQL erwartungsgemäß super gut, d.h. FHEM und Logging laufen ohne Beeinträchtigung weiter wenn reducelog gestartet wurde.
Bitte testet es auf euren Systemen, inbesondere wieder SQLite bzw. Postrgre.
Jetzt haben wir in Summe folgende Weiterentwicklungen gegenüber der eingecheckten 2.11.4:
* Support für primary Key auf allen DB's (PostgreSQL ab 9.5) für history und current
* Command clearReadings
* reduceLog non-blocking
Nochmal herzlichen Dank an Dan !!
Nur als Info, das Kommando clearReadings habe ich extra nicht z.B. delReadings genannt um nicht zu suggerieren es würden Readings in der DB gelöscht.
Die neue V2.13.0 ist anbei.
viele Grüße
Heiko
Moin Heiko,
schön dass Du es geschafft hast meinen Code zu integrieren.
Aber wie ich Dir schon per PN geschrieben habe finde ich "clearReadings" nicht so gut. Es müsste wirklich die Readings leeren. Ich finde es nicht so schön wenn mir meine Readings weggelöscht werden, denn gerade bei den non-blocking Funktionen, die irgendwann zurückkehren und ihr Ergebnis in ein Reading schreiben, muss man immer mal wieder die Seite neu laden um das neu erstellte Reading (Ergebnis) zu sehen.
Wenn schon "clearReadings" dann könnte ich mir vorstellen alle Readings zu löschen, damit wieder Ordnung ist (und alle "alten", nicht wiederkehrenden Readings weg sind) und dann die wirklich wiederkehrenden Readings leer wieder erstellen.
Da ich im FileLogConvert Modul ein ähnliches Problem hatte, erstelle ich direkt beim Define alle Reading leer und fülle sie nach und nach. Das finde ich für den User angenehmer... 8)
Gruß
Dan
P.S. Werd nachher mal mit der neuen Version testen...
Hallo!
Leider bin ich kein Nutzer von reduceLog und bin daher für tests nicht sonderlich gut geeignet.
Ich werde mir heute mal die Doku dazu durchlesen und dann entscheiden, ob ich es mal testen kann/will.
Zu dem clearReadings habe ich nicht wirklich eine Meinung: Ich benötige es nicht, da ich mit
deletereading <DbLogDevice> .*
oder eben
deletereading <DbLogDevice> NextSync
das selbe Ergebnis bekomme und ich mir dort sicher bin, was genau passiert.
Anbei ein Überblick über den aktuellen Performancetest.
Um den Überblick nicht zu verlieren, zähle ich im Moment nur die wichtigsten Tests/Ergebnisse auf.
Wenn jemand an weiteren Ergebnissen interessiert ist oder auch einen Test hinzufügen möchte, bitte immer gerne melden.
Die Tests wurden automatisiert und somit auch mehrmals gemacht. Die Ergebnisse sind immer relativ konstant
und schwanken meist nur um 1-3 Sekunden. Ich denke somit dass das Ergebnis durchaus verwendet werden kann.
Besonders interessiert hat mich auch der Vergleich der unterschiedlichen Datenbanksysteme.
Original-Tabellen, gefüllt mit den jeweils exakt gleichen Daten (>24Mio) Datensätzen.
Test 1 2 3 4
MySQL 5973,6 77 3014 3585MB
SqLite 2216 19 2441 3484MB
PostGres 8640 64 1756 4903MB
Beschreibung der Tests:
*1 Insert, also das Einfügen der Datensätze in die DB, Zeit in s
*2 Plot-Abfragen auf die 150 häufigsten Devices mit Zeitraum 1 Woche, Zeit in s
*3 Select-Abfrage mit Group und Order über alle Datensätze (zum Ermitteln, welches Device wie oft in der DB ist), Zeit in s
*4 Die Größe der Datenbank auf dem System, Gröe in MB
Mit verändertem Index:
1 2 3 4
SqLite - 22 983 3555MB
PostGres - 59 1595 4401MB
MySQL#1c 6751 24 183 4203MB
MySQL#2 4050 668 149 2737MB
Maria#7b 7132 30 144 3018MB
Details zu den Veränderten Tabellen für den Versuch:
SqLite Es wurde ein zweiter Key (`TIMESTAMP`, `DEVICE`) hinzugefügt
Postgr (`TIMESTAMP`, `DEVICE`, `READING`)
#1c= Wie Original-Tabelle jedoch ohne Unicode + zewiten Index;
PRIMARY KEY (`DEVICE`, `READING`, `TIMESTAMP`), INDEX `key2` (`TIMESTAMP`, `DEVICE`)) COLLATE='latin1_bin' ENGINE=InnoDB
#2 = MyISAM (Test als Alternative zu Aria, da Aria auf manchen Rechnern ohne MariaDB nicht verfügbar ist)
COLLATE='latin1_swedish_ci' ENGINE=MyISAM;
#7b= Engine Aria, ohne Unicode, jedoch Crashsafe(daher langsamer, jedoch sicherer bei möglichen Abstürzen/Stromausfall)
PRIMARY KEY (`DEVICE`, `READING`, `TIMESTAMP`), UNIQUE INDEX `Schlüssel 2` (`TIMESTAMP`, `DEVICE`, `READING`) ) COLLATE='latin1_swedish_ci' TRANSACTIONAL= 1 ENGINE=Aria
Aktuelles Fazit:
Für mich(persönlich) scheint im Moment MariaDB mit der Konfiguration "7b" die interessanteste Variante zu sein.
Sie ist CrashSafe, im Schnitt sehr schnell, relativ klein, erlaubt mehrere Zugriffe gleichzeitig und benötigt wenig Arbeitsspeicher.
Bei Postgres werde ich noch weitere Tests mit anderen Indexkombinationen durchführen. Dort denke ich ist das Ende der
Geschwindigkeit noch nicht erreicht. SqLite ist bereits extrem schnell für Plotabfragen, bei komplexeren
Abfragen jedoch träge.
Findings bei den Tests:
# Die sqLite-DB wurde 2x corrupt, ohne Systemabsturz. Die Reperatur hat >30h gedauert.
# InnoDB konnte in manchen Konfigurationen keine 20Mio Datensätze auf einmal importieren.
Fehlermeldung: "The total number of locks exceeds the lock table size insert into select from"
Schöne Grüße
Joe
Edit: Kommentar bezügl. clearReadings ergänzt
Anbei ein kleines diff welches "set <name> count" als non-blocking implementiert.
EDIT: Hab's natürlich kurz mit meiner MySQL DB getestet.
Gruß
Dan
P.S. Hab jetzt nicht weiter gesucht! Ist dann alles non-blocking?
EDIT: Dateianhang entfernt.
So richtig gefällt mir count nicht per set!!!
Nach dem Abschicken kehrt die Seite nicht schnell genug zurück um schon von lonpoll aktualisiert zu werden, aber nicht langsam genug dass der neue Wert aus dem Reading gelesen wird!
Also muss man manuell nochmal aktualisieren um das Ergebnis zu sehen!
Das finde ich suboptimal. ???
Wollen wir nicht ein get daraus machen?
Gruß
Dan
Ich habe keine Lust, jetzt durch 10 Seiten zu lesen, aber hat schon jemand darüber nachgedacht, DbLog irgendwann in einer MongoDB laufen zu lassen, die ja von haus schon nonblocking ist und auch noch ein paar andere Vorteile - beispielsweise kein Datenbankschema mehr und damit keine Diskussion über Feldlängen - bietet?
Zitat von: DeeSPe am 15 Februar 2017, 12:58:32
So richtig gefällt mir count nicht per set!!!
Wollen wir nicht ein get daraus machen?
Lass bitte den alten set count Befehl wie er ist und baue Deine nonblocking-Variante als get ein.
Zitat von: betateilchen am 15 Februar 2017, 12:59:18
Ich habe keine Lust, jetzt durch 10 Seiten zu lesen, aber hat schon jemand darüber nachgedacht, DbLog irgendwann in einer MongoDB laufen zu lassen, die ja von haus schon nonblocking ist und auch noch ein paar andere Vorteile - beispielsweise kein Datenbankschema mehr und damit keine Diskussion über Feldlängen - bietet?
Ich habe MongoDb hier testhalber am Laufen, jedoc nicht im im Livebetrieb, ich spiegle lediglich die Daten aus MariaDB mach MongoDB.
Hast Du eine bestimmte Erwartung ausser dem NonBlocking an diese Erweiterung?
Meine Hoffnungen wurden bisher nicht erfüllt (geringere Ressourcen beim Speichern der Daten, geringerer Speicherbedarf auf der SSD, etc...).
Wie weit ist dein Test mit SAP-Hana?
In meine Geschwindigkeits-Tests von oben konnte ich es noch nicht integrieren, da ich beim Auslesen der Daten für Plots noch Fehler erhalte, das möchte ich aber in nächster Zeit ergänzen.
Zitat von: betateilchen am 15 Februar 2017, 13:00:29
Lass bitte den alten set count Befehl wie er ist und baue Deine nonblocking-Variante als get ein.
Warum soll der als set und blocking drin bleiben wenn man ein get in non-blocking daraus macht?
Gruß
Dan
Zitat von: JoeALLb am 15 Februar 2017, 13:18:50
Wie weit ist dein Test mit SAP-Hana?
Meine configDB zuhause läuft problemlos mit SAP HANA :)
DbLog auf HANA zu nutzen, dürfte auch nicht weiter schwierig sein, HANA ist aus perl prinzipiell über einen ODBC Treiber anzusprechen. Die meiste Arbeit ist ausserhalb von FHEM notwendig, die HANA DB erstmal so weit zu haben, dass man irgendwas reinschreiben kann 8)
Für FHEM wird HANA m.E. kein Thema werden, diese Datenbank läuft schließlich nicht auf der FritzKotz.
Zitat von: DeeSPe am 15 Februar 2017, 13:25:58
Warum soll der als set und blocking drin bleiben wenn man ein get in non-blocking daraus macht?
Aus Kompatibilitätsgründen in bestehenden Anwendungen.
Und bei mir hat ein count noch nie irgendwas blockiert.
Zitat von: betateilchen am 15 Februar 2017, 13:26:52
Aus Kompatibilitätsgründen in bestehenden Anwendungen.
Okay, verstanden!
Aber das set könnte man dann auf die selbe non-blocking Funktion schicken, oder?
Oder gibt es einen Grund die blocking Variante zu behalten?
Gruß
Dan
Zitat von: DeeSPe am 15 Februar 2017, 13:28:37
Oder gibt es einen Grund die blocking Variante zu behalten?
siehe oben:
Zitat von: betateilchen am 15 Februar 2017, 13:26:52
bei mir hat ein count noch nie irgendwas blockiert.
Man nimmt auch keine Kopfschmerztablette, wenn man keine Kopfschmerzen hat. Es sei denn, man ist drogensüchtig.
Ich möchte nicht noch mehr perl Prozesse haben.
Zitat von: betateilchen am 15 Februar 2017, 13:31:27
siehe oben:
Man nimmt auch keine Kopfschmerztablette, wenn man keine Kopfschmerzen hat. Es sei denn, man ist drogensüchtig.
Ich möchte nicht noch mehr perl Prozesse haben.
Okay!
Die Funktion ist wohl bei Dir zu schnell als dass das Blockieren auffallen würde. :D
Wir hatten hier schon mal kurz über non-blocking count geschrieben.
Das ist auch nur ein Vorschlag von mir, ob und wie es in das Modul übernommen wird steht auf einem anderen Blatt.
Gruß
Dan
Zitat von: DeeSPe am 15 Februar 2017, 13:43:04
Die Funktion ist wohl bei Dir zu schnell als dass das Blockieren auffallen würde.
ich sag mal so: ich hatte noch nie irgendein blocking-Problem mit DbLog 8)
Zitat von: DeeSPe am 15 Februar 2017, 13:43:04
Das ist auch nur ein Vorschlag von mir, ob und wie es in das Modul übernommen wird steht auf einem anderen Blatt.
Der Vorschlag ist ja ok, und ich hatte lediglich einen Gegenvorschlag gemacht, der unser beider Anliegen lösen könnte ;)
Zitat von: betateilchen am 15 Februar 2017, 13:55:43
ich sag mal so: ich hatte noch nie irgendein blocking-Problem mit DbLog 8)
Mein (Test)RPi1 hat am WE fast 6 Stunden blockiert während reduceLog lief...
Zitat von: betateilchen am 15 Februar 2017, 13:55:43
Der Vorschlag ist ja ok, und ich hatte lediglich einen Gegenvorschlag gemacht, der unser beider Anliegen lösen könnte ;)
Verstanden!
Gruß
Dan
Hallo zusammen,
habe die letzten Tage auch von FileLog auf DBLog migriert und musste leider feststellen das die MariaDB auf dem Raspberry vielleicht in meinem Falle nicht so eine gute Idee ist, die Plots dauern ca 10-20 Sekunden und der arme Raspberry läuft auf 100% CPU (MySQL Process 1-2 Cores).
In der Datenbank sind ca 13 Mio Datensätze, der letzten 6 Monate, bei ca 30 Devices. Im Monat kommen im Schnitt 1-2 MIO Datensätze hinzu. Die Datenbank habe ich schon mal auf eine SSD Platte (die aber leider über USB angeschlossen ist) geschoben.
In einer alten Firma hatten wir ein ähnliches Problem (wenn ungleich die Hardware viel größer war, doch 2 TB im Monat Daten war auch da eine Hausnummer). Dort hatten wir es dann so gelöst das wir einen insert und select trigger in der Postgres gebaut haben. Diese hatte die Daten in die unterschiedlichen Tabellen geschrieben.
Der insert ging z.B auf history, der trigger hatte dieses dann aber in die Tabelle history_201702 geschrieben. Somit hatten wir "schlankere Tabellen" und auch kleinere Indexe. But not Least war das Löschen der alten Daten einfach ein "drop table_201610". Der Select konnte normal auf "history" gehen und der trigger wusste ja wo der Timestamp zu finden ist.
Beispiel:
Datum 12.12.2016
-> history = Trigger auf history_201612
Datum 01.01.2017
-> history = Trigger auf history_201701
Es gibt natürlich auch einen Nachteil, zwar müssen die Tabellen davor natürlich existieren. Dafür hatten wir einen Cronjob gebaut der einmal im Monat gelaufen ist, der hatte überprüft ob die nächsten 3 Monate schon Tabellen existieren und wenn nicht existierten dann gleich die nächsten 3 Monate angelegt hat.
Was haltet ihr von dem Gedanken?
Ich denke nicht, dass Du zwei Tabellen benötigst.
Trigger brauchen auch CPU-Zeit und eigentlich gibt es (zumindes auf meinen RPIs) keinen Engpass.
Aber das ist genau der Grund, warum es diesen Thread hier gibt.
1. Frage: Verwendest Du current/history? Wenn ja, stell doch mal auf nur "history" um. Die Persormance sollte gleich spürbar besser werden.
2. Dann würde ich das Tabellenformat und die Indexe umstellen, und auf die neue Testversion von DbLog umstellen,
die in diesem Thread anhegängt wurde und bereits die PK-Indexe unterstützt. Wenn Du dann noch auf async=1 umstellst, sollte
deine Plots besser funktionieren als zuvor mit Filelog.
Hi @JoeALLb,
danke für deine Tips, habe schon mal folgendes gesetzt:
attr DbLog_FHEM DbLogType History
attr DbLog_FHEM asyncMode 1
Zeiten haben sich aber beim GPLOT nicht geändert, dauerte davor ca 11 Sekunden und dauert auch jetzt noch 11 Sekunden.
Ein Fulltablescan (Select coun(*) from historys) dauert allerdings 1 Minute 20 Sekunden. Dabei liefert die Platte 10 MB/s und 1500 IOs :D
Wo finde ich denn das neue Tabellenformat? Dann würde ich das heute abend gerne mal testen. Werde die Datenbank noch neu importieren, denn die innodb ist schon bei 6.5 GB, Datenbank selber hat aber "nur" 1.2 GB.
Danke schon mal für die unterstützung.
Hier in diesem Thread
https://forum.fhem.de/index.php/topic,62998.msg568302.html#msg568302
Folgende Anmerkung:
#1 Mach Index 1 als Primary Key, da DbLog aus diesem Thread mittlerweile einen PK-Support hat!
#2 verwende das Modul DbLog aus diesem Thread (Kommentar #119 denk ich)
#3 Du kannst die Partitionen weglassen, die sind hauptsächlich für RPIS gedacht, die die DB auf einer SD-Karte gespeichert haben (so wie ich auf einem RPI)
#3: Die Datenbankgröße wird immer größer sein wie die Filelog-Größe.
Neuimport sollte nicht nötig sein, mit dem insert into select from kopierst du die Daten relativ schnell innerhalb von MySQL.
Achtung: InnoDB gibt manchmal einen Fehler beim lesen von mehr als 1Mio Datensätzen aus, wenn dem so ist, meld dich nochmal.
Edit: Ergänzt
Zitat von: Kaufe am 16 Februar 2017, 07:31:09
Was haltet ihr von dem Gedanken?
Nachtrag:
Hier in meinem Benchmark(https://forum.fhem.de/index.php/topic,65860.msg585475.html#msg585475) sieht man aber, dass jede Client/Server Datenbank längsamer ist als SqLite (19s vs. 30s),
jedoch für 150 Devices für eine ganze Woche. Ich denke also dass es auch mit MySQL/MariaDB schnell genug sein sollte
bei jedem Plot. Die Vorteile dieser DBs halte ich jedoch für größer wie diesen Nachteil!
Hi JoeALLb,
super, ich danke dir vielmals.
Testergebniss davor:
#################
-> ein spezieller PLOT(mit 4 verschiedenen Devices) dauerte ca 11 Sekunden
-> 173 rows in set (4 min 7.63 sec) von dem SQL"select timestamp, device, reading, value, count(*) as Nr from history group by device, reading order by Nr DESC, device; "
* Habe mal das neue V2.13 vom 93_DbLog installiert.
* die Datenbanken neu aufgebaut wie du beschrieben hast
* Die Datenbank importiert
Query OK, 12995574 rows affected (41 min 12.63 sec)
Records: 13135326 Duplicates: 139752 Warnings: 0* Datenbank wieder umbenannt
Wieder Tests gemacht:
##################
-> ein spezieller PLOT(mit 4 verschiedenen Devices) dauerte nun zwischen 5 und 7 Sekunden
-> 173 rows in set (1 min 38.98 sec) von dem SQL"select timestamp, device, reading, value, count(*) as Nr from history group by device, reading order by Nr DESC, device; "
Abschließend habe ich mein GPLOT noch überprüft und auch hier die Übeltäter gefunden:
Zitat#DbLog_FHEM GA_Garage1
#DbLog_FHEM AU_Garage1
#DbLog_FHEM AU_Garage2
#DbLog_FHEM AU_Haustuere
ist natürlich falsch, habe das nun abgeändert, das auch dei Readings ins SQL bzw in den Index fallen.
Zitat#DbLog_FHEM GA_Garage1:temperature
#DbLog_FHEM AU_Garage1:temperature
#DbLog_FHEM AU_Garage2:temperature
#DbLog_FHEM AU_Haustuere:temperature
Nun braucht auch das 6 Sekunden Plot, nur noch ein gefühltes Augenzwinkern.
Geniale Arbeit. DANKE schon mal vielmals
Hallo miteinander,
ich habe die Hinweise von Dan aufgegriffen und "clearReadings" dahingehend geändert dass die Readings nur noch geleert werden (außer
state und periodisch wiederkehrende Readings mit asynch=1).
Um alle Readings (außer "state") zu löschen, gibt es jetzt den Befehl "eraseReadings". Somit hat sicherlich jeder zur Verfügung was er an dieser Stelle wünscht.
Desweiteren habe ich eine non-blocking Variante von deleteOldDays eingebaut. Sie heißt deleteOldDaysNbl.
Insgesamt habe ich, dem Wunsch von betateilchen folgend, die bisherigen Funktionen von count, aber auch von deleteOldDays, reduceLog im Modul gelassen und
die nicht-blockierenden Varianten mit dem Zusatz "Nbl" versehen hinzugefügt.
Es gibt also nun "set <name> ... ":
* count (alt) bzw. countNbl (non-blocking)
* reduceLog (alt) bzw. reduceLogNbl (non-blocking)
* deleteOldDays (alt) bzw. deleteOldDaysNbl (non-blocking)
Ich denke damit gibt es für jeden Geschmack bzw. Bedarf eine entsprechende Funktion.
Die Commandref ist ebenfalls angepasst.
Bitte testet diese neue Version 2.13.2 wieder auf euren Systemen und gebt bitte Rückmeldung ob alles soweit ok ist.
viele Grüße
Heiko
Zitat von: DS_Starter am 17 Februar 2017, 17:17:58
Hallo miteinander,
ich habe die Hinweise von Dan aufgegriffen und "clearReadings" dahingehend geändert dass die Readings nur noch geleert werden (außer
state und periodisch wiederkehrende Readings mit asynch=1).
Um alle Readings (außer "state") zu löschen, gibt es jetzt den Befehl "eraseReadings". Somit hat sicherlich jeder zur Verfügung was er an dieser Stelle wünscht.
Desweiteren habe ich eine non-blocking Variante von deleteOldDays eingebaut. Sie heißt deleteOldDaysNbl.
Insgesamt habe ich, dem Wunsch von betateilchen folgend, die bisherigen Funktionen von count, aber auch von deleteOldDays, reduceLog im Modul gelassen und
die nicht-blockierenden Varianten mit dem Zusatz "Nbl" versehen hinzugefügt.
Es gibt also nun "set <name> ... ":
* count (alt) bzw. countNbl (non-blocking)
* reduceLog (alt) bzw. reduceLogNbl (non-blocking)
* deleteOldDays (alt) bzw. deleteOldDaysNbl (non-blocking)
Ich denke damit gibt es für jeden Geschmack bzw. Bedarf eine entsprechende Funktion.
Die Commandref ist ebenfalls angepasst.
Bitte testet diese neue Version 2.13.2 wieder auf euren Systemen und gebt bitte Rückmeldung ob alles soweit ok ist.
viele Grüße
Heiko
Ui ui ui, da hast Du Dir aber wieder viel Arbeit gemacht Heiko!
Bisher sieht es bei mir auf MySQL gut aus.
Gruß
Dan
Hallo,
als erstes mal vielen Dank für die viele Arbeit die ihr hier reinsteckt.
Ich bräuchte bitte mal etwas Hilfe. Seit gestern abend erhalte ich den Fehler: Commit already running - resync at NextSync
Ich nutze fhem auf einem Ubuntu Server (mit ESX virtualisiert). MySQL läuft auf dem gleichen Server. list myDbLog liefert:
Internals:
CFGFN
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION ./FHEM/FhemUtils/db.conf
DBMODEL MYSQL
DEF ./FHEM/FhemUtils/db.conf ^HK.*|^Kollektor.*|^Solar.*|^Speicher.*|^Steuerung.*|^Therme.*|^WW.*|.*:.*
MODE asynchronous
NAME myDbLog
NR 6
NTFY_ORDER 50-myDbLog
PID 28818
REGEXP ^HK.*|^Kollektor.*|^Solar.*|^Speicher.*|^Steuerung.*|^Therme.*|^WW.*|.*:.*
STATE Commit already running - resync at NextSync
TYPE DbLog
VERSION 2.11.1
dbconn mysql:database=fhem;host=localhost;port=3306
dbuser fhem
Helper:
COLSET 1
DEVICECOL 64
EVENTCOL 512
READINGCOL 64
TYPECOL 64
UNITCOL 32
VALUECOL 128
Running_pid:
abortFn DbLog_PushAsyncAborted
arg myDbLog|MjAxNy0wMi0xNyAyMjoxMTozNXxIS1ZvcmxhdWZWYWx1ZXxEVU1NWXwzNC45fHN0YXRlfDM0Ljl8wqcyMDE3LTAyLTE3IDIyOjExOjM1fFNvbGFyV1RWb3JsYXVmfERVTU1ZfDIxLjZ8c3RhdGV8MjEuNnzCpzIwMTctMDItMTcgMjI6MTE6MzZ8T0dfRVpfVGhlcm1vc3RhdHxDVUxfSE18aHVtaWRpdHk6IDY2fGh1bWlkaXR5fDY2fCXCpzIwMTctMDItMTcgMjI6MTE6MzZ8T0dfRVpfVGhlcm1vc3RhdHxDVUxfSE18bWVhc3VyZWQtdGVtcDogMTMuMnxtZWFzdXJlZC10ZW1wfDEzLjJ8wqcyMDE3LTAyLTE3IDIyOjExOjM2fE9HX0VaX1RoZXJtb3N0YXR8Q1VMX0hNfFQ6IDEzLjIgSDogNjZ8VHwxMy4yIEh8NjbCpzIwMTctMDItMTcgMjI6MTE6MzZ8T0dfRVpfVGhlcm1vc3RhdF9XZWF0aGVyfENVTF9ITXxodW1pZGl0eTogNjZ8aHVtaWRpdHl8NjZ8JcKnMjAxNy0wMi0xNyAyMjoxMTozNnxPR19FWl9UaGVybW9zdGF0X1dlYXRoZXJ8Q1VMX0hNfG1lYXN1cmVkLXRlbXA6IDEzLjJ8bWVhc3VyZWQtdGVtcHwxMy4yfMKnMjAxNy0wMi0xNyAyMjoxMTozNnxPR19FWl9UaGVybW9zdGF0X1dlYXRoZXJ8Q1VMX0hNfFQ6IDEzLjIgSDogNjZ8VHwxMy4yIEh8NjbCpzIwMTctMDItMTcgMjI6MTE6MzZ8SEtSdWVja2xhdWZUZW1wMnxEVU1NWXwzOC4yfHN0YXRlfDM4LjJ8wqcyMDE3LTAyLTE3IDIyOjExOjM2fFNvbGFyTGVpc3R1bmd8RFVNTVl8MHxzdGF0ZXwwfMKnMjAxNy0wMi0xNyAyMjoxMTozNnxTb2xhclZvcmxhdWZ8RFVNTVl8MzcuMHxzdGF0ZXwzNy4wfMKnMjAxNy0wMi0xNyAyMjoxMTozNnxTcGVpY2hlckE1fERVTU1ZfDMxLjd8c3RhdGV8MzEuN3zCpzIwMTctMDItMTcgMjI6MTE6MzZ8VGhlcm1lUnVlY2tsYXVmVGVtcElzdHxEVU1NWXwzMS42fHN0YXRlfDMxLjZ8wqcyMDE3LTAyLTE3IDIyOjExOjM2fFRoZXJtZVZvcmxhdWZUZW1wSXN0fERVTU1ZfDQ3LjZ8c3RhdGV8NDcuNnzCpzIwMTctMDItMTcgMjI6MTE6MzZ8U3BlaWNoZXJBMnxEVU1NWXw1My40fHN0YXRlfDUzLjR8wqcyMDE3LTAyLTE3IDIyOjExOjM4fFRoZXJtZVNwZWljaGVyVGVtcHxEVU1NWXw3NC44fHN0YXRlfDc0Ljh8wqcyMDE3LTAyLTE3IDIyOjExOjQ0fEhLVm9ybGF1ZlZhbHVlfERVTU1ZfDM0LjV8c3RhdGV8MzQuNXzCpzIwMTctMDItMTcgMjI6MTE6NDV8SE1MQU4xfEhNTEFOfGxvYWRMdmw6IGxvd3xsb2FkTHZsfGxvd3zCpzIwMTctMDItMTcgMjI6MTE6NDZ8S29sbGVrdG9yVmFsdWVEYWNoMXxEVU1NWXwxNTF8c3RhdGV8MTUxfMKnMjAxNy0wMi0xNyAyMjoxMTo0NnxLb2xsZWt0b3JEYWNoMXxEVU1NWXw2LjR8c3RhdGV8Ni40fMKnMjAxNy0wMi0xNyAyMjoxMTo1MHxUaGVybWVTcGVpY2hlclRlbXB8RFVNTVl8NzQuOXxzdGF0ZXw3NC45fMKnMjAxNy0wMi0xNyAyMjoxMTo1MHxUaGVybWVWb3JsYXVmVGVtcElzdHxEVU1NWXw0OC4yfHN0YXRlfDQ4LjJ8wqcyMDE3LTAyLTE3IDIyOjExOjUwfFNvbGFyTGVpc3R1bmd8RFVNTVl8MHxzdGF0ZXwwfMKnMjAxNy0wMi0xNyAyMjoxMTo1MHxTb2xhclZvcmxhdWZ8RFVNTVl8MzcuMXxzdGF0ZXwzNy4xfMKnMjAxNy0wMi0xNyAyMjoxMTo1MHxTcGVpY2hlckEyfERVTU1ZfDUzLjN8c3RhdGV8NTMuM3zCpzIwMTctMDItMTcgMjI6MTE6NTB8U3BlaWNoZXJBM3xEVU1NWXw0NC40fHN0YXRlfDQ0LjR8wqcyMDE3LTAyLTE3IDIyOjExOjUwfFNwZWljaGVyQTR8RFVNTVl8MzMuMHxzdGF0ZXwzMy4wfMKnMjAxNy0wMi0xNyAyMjoxMTo1MHxUaGVybWVSdWVja2xhdWZUZW1wSXN0fERVTU1ZfDMxLjV8c3RhdGV8MzEuNXzCpzIwMTctMDItMTcgMjI6MTE6NTF8T0dfRVpfVGhlcm1vc3RhdF9FWnxDVUxfSE18YWN0dWF0b3I6IDB8YWN0dWF0b3J8MHzCpzIwMTctMDItMTcgMjI6MTE6NTF8T0dfRVpfVGhlcm1vc3RhdF9FWnxDVUxfSE18YmF0dGVyeTogb2t8YmF0dGVyeXxva3zCpzIwMTctMDItMTcgMjI6MTE6NTF8T0dfRVpfVGhlcm1vc3RhdF9FWnxDVUxfSE18YmF0dGVyeUxldmVsOiAyLjl8YmF0dGVyeUxldmVsfDIuOXzCpzIwMTctMDItMTcgMjI6MTE6NTF8T0dfRVpfVGhlcm1vc3RhdF9FWnxDVUxfSE18ZGVzaXJlZC10ZW1wOiAxOS4wfGRlc2lyZWQtdGVtcHwxOS4wfMKnMjAxNy0wMi0xNyAyMjoxMTo1MXxPR19FWl9UaGVybW9zdGF0X0VafENVTF9ITXxtZWFzdXJlZC10ZW1wOiAyMy4wfG1lYXN1cmVkLXRlbXB8MjMuMHzCpzIwMTctMDItMTcgMjI6MTE6NTF8T0dfRVpfVGhlcm1vc3RhdF9FWnxDVUxfSE18bW90b3JFcnI6IG9rfG1vdG9yRXJyfG9rfMKnMjAxNy0wMi0xNyAyMjoxMTo1MXxPR19FWl9UaGVybW9zdGF0X0VaX0NsaW1hfENVTF9ITXxWYWx2ZVBvc2l0aW9uOiAwfFZhbHZlUG9zaXRpb258MHzCpzIwMTctMDItMTcgMjI6MTE6NTF8T0dfRVpfVGhlcm1vc3RhdF9FWl9XZWF0aGVyfENVTF9ITXxtZWFzdXJlZC10ZW1wOiAyMy4wfG1lYXN1cmVkLXRlbXB8MjMuMHzCpzIwMTctMDItMTcgMjI6MTE6NTF8T0dfRVpfVGhlcm1vc3RhdF9FWl9XZWF0aGVyfENVTF9ITXwyMy4wfHN0YXRlfDIzLjB8wqcyMDE3LTAyLTE3IDIyOjExOjU0fEhLVm9ybGF1ZlZhbHVlfERVTU1ZfDM0LjN8c3RhdGV8MzQuM3zCpzIwMTctMDItMTcgMjI6MTE6NTh8VGhlcm1lU3BlaWNoZXJUZW1wfERVTU1ZfDc0Ljh8c3RhdGV8NzQuOHzCpzIwMTctMDItMTcgMjI6MTE6NTh8VGhlcm1lVm9ybGF1ZlZhbHVlfERVTU1ZfC01LjB8c3RhdGV8LTUuMHzCpzIwMTctMDItMTcgMjI6MTI6MDF8VGhlcm1lUnVlY2tsYXVmVGVtcElzdHxEVU1NWXwzMS40fHN0YXRlfDMxLjR8wqcyMDE3LTAyLTE3IDIyOjEyOjAxfFRoZXJtZVZvcmxhdWZUZW1wSXN0fERVTU1ZfDQ4Ljh8c3RhdGV8NDguOHzCpzIwMTctMDItMTcgMjI6MTI6MDJ8V1dTcGVpY2hlclRlbXAyfERVTU1ZfDQ2LjR8c3RhdGV8NDYuNHzCpzIwMTctMDItMTcgMjI6MTI6MDJ8U3BlaWNoZXJBM3xEVU1NWXw0My41fHN0YXRlfDQzLjV8wqcyMDE3LTAyLTE3IDIyOjEyOjA0fEhLVm9ybGF1ZlZhbHVlfERVTU1ZfDM0LjF8c3RhdGV8MzQuMXw=
bc_pid 24327
finishFn DbLog_PushAsyncDone
fn DbLog_PushAsync
pid WAITING:
timeout 120
Abortarg:
Helper:
Dblog:
Cacheusage:
Mydblog:
TIME 1486638532.49027
VALUE 31
Dbi connect('database=fhem;host=localhost;port=3306','fhem',...) failed:
Mydblog:
TIME 1487405892.98586
VALUE Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at ./FHEM/93_DbLog.pm line 1151.
Background_processing_time:
Mydblog:
TIME 1486638160.74013
VALUE 0.4276
Countcurrent:
Mydblog:
TIME 1486632305.14062
VALUE 1248
Counthistory:
Mydblog:
TIME 1486632305.01294
VALUE 98182987
Notify_processing_time:
Mydblog:
TIME 1486638157.98433
VALUE 0.0027
Sql_processing_time:
Mydblog:
TIME 1486638160.74013
VALUE 0.4174
State:
Mydblog:
TIME 1487406193.56428
VALUE Commit already running - resync at NextSync
Readings:
2017-02-18 09:23:13 CacheUsage 96629
2017-02-18 09:23:13 NextSync 2017-02-18 09:23:43 or if CacheUsage 1000 reached
2017-02-09 10:25:05 countCurrent 1248
2017-02-09 10:25:05 countHistory 98182987
2017-02-18 09:23:13 state Commit already running - resync at NextSync
Cache:
index 980599
Memcache:
883971 2017-02-17 22:12:18|ThermeKesselTempIst|DUMMY|34.0|state|34.0|
.
.
.
980598 2017-02-18 09:23:13|ThermeSpeicherTemp|DUMMY|74.9|state|74.9|
980599 2017-02-18 09:23:13|myDbLog|DBLOG|Commit already running - resync at NextSync|state|Commit already running - resync at NextSync|
Attributes:
DbLogExclude CacheUsage
DbLogType Current/History
asyncMode 1
cacheEvents 1
cacheLimit 1000
shutdownWait 120
syncInterval 30
Kann ich die Datensätze noch retten?
Und wo liegt das eigentliche Problem?
Mit HeidiSQL kann ich mich Problemlos auf den Server verbinden.
Vielen Dank und liebe Grüße
Eddy
Kannst du im MySQL-Log herausfinden, warum das commit nicht funktioniert?
Ansonsten musst du wohl ein rollback in kauf nehmen, dadurch verlierst du wohl die 1000 Datensätze dieses commits.
Die Memcache-Daten solltest du retten können, indem Du set <device> reopen 10; eingibst.
Dadurch wird die Verbindung für 10 Sekunden geschlossen und neu aufgebaut.
Die Daten werden dann versucht nochmal zu schreiben... aber ob das funktioniert hängt wieder von der Fehlermeldung aus MySQL ab. (Es könnte ja die Platte voll sein, etc...)
sG
Joe
Edit: Dies bestärkt mich in meinem Wunsch nach einem Speichermodus ohne Transaktion. Diese ist hier in dieser Konstellation nicht hilfreich und kostet Systemressourcen; Ein Rollback bei einer Logdatei macht keinen Sinn.
Edit2: Sorry, die Connect-Fehlermeldung habe ich glatt überlesen. Heikos Antwort unten ist natürlich die bessere!
@est,
Zitat
Dbi connect('database=fhem;host=localhost;port=3306','fhem',...) failed:
Mydblog:
TIME 1487405892.98586
VALUE Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at ./FHEM/93_DbLog.pm line 1151.
Möglicherweise hilft auch ein Restart der MySQL mit
/etc/init.d/mysqld restartDer Cache bleibt solange erhalten und wird dann weggeschrieben wenn die Verbindung wieder hergestellt werden kann.
SHOW FULL PROCESSLIST zeigt mir nur die Session vom Laptop von dem ich es aufrufe.
Ich hatte den MySQL schon neu gestartet. Hat sich aber nichts geändert.
Protokoll aus /var/log/mysql/error.log:
170218 9:18:06 [Note] /usr/sbin/mysqld: Normal shutdown
170218 9:18:06 [Note] Event Scheduler: Purging the queue. 0 events
170218 9:18:08 [Warning] /usr/sbin/mysqld: Forcing close of thread 171415 user: 'steier'
170218 9:18:08 InnoDB: Starting shutdown...
170218 9:18:10 InnoDB: Shutdown completed; log sequence number 1762443238810
170218 9:18:10 [Note] /usr/sbin/mysqld: Shutdown complete
170218 9:18:11 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
170218 9:18:11 [Note] Plugin 'FEDERATED' is disabled.
170218 9:18:11 InnoDB: The InnoDB memory heap is disabled
170218 9:18:11 InnoDB: Mutexes and rw_locks use GCC atomic builtins
170218 9:18:11 InnoDB: Compressed tables use zlib 1.2.8
170218 9:18:11 InnoDB: Using Linux native AIO
170218 9:18:11 InnoDB: Initializing buffer pool, size = 128.0M
170218 9:18:11 InnoDB: Completed initialization of buffer pool
170218 9:18:11 InnoDB: highest supported file format is Barracuda.
170218 9:18:13 InnoDB: Waiting for the background threads to start
170218 9:18:14 InnoDB: 5.5.54 started; log sequence number 1762443238810
170218 9:18:14 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
170218 9:18:14 [Note] - '0.0.0.0' resolves to '0.0.0.0';
170218 9:18:14 [Note] Server socket created on IP: '0.0.0.0'.
170218 9:18:14 [Note] Event Scheduler: Loaded 0 events
170218 9:18:14 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.54-0ubuntu0.14.04.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
Ich kann mich auch von HeidiSQL und von der Konsol über mysql -ufhem -p Problemlos verbinden.
Nächster Schritt wäre dann set <device> reopen 10?
Ja, probiers mal.
Sonst habe ich evtl. noch eine weitere Idee ...
Anbei noch ein Grund, warum ich mir eine valueFormat -Funktion, ähnlich wie bei readingsGroup wünsche.
So wird bei mir aktuell eine Whatsapp-Nachricht geloggt. Mit ist bewußt, dass hier eine Implementierung von SplitFN im Modul
die korrekte lösung wäre, der Modulautor ist daran aber im Moment nicht interessiert.
+---------------------+-------------+--------+----------------------------------------+-----------+---------------+--------------+----------+
| TIMESTAMP | DEVICE | TYPE | EVENT | READING | VALUE | UNIT | count(*) |
+---------------------+-------------+--------+----------------------------------------+-----------+---------------+--------------+----------+
| 2016-12-19 14:30:02 | whats | YOWSUP | chatstate: composing | chatstate | composing | | 256 |
| 2016-12-19 14:31:34 | whats | YOWSUP | chatstate: paused | chatstate | paused | | 56 |
| 2016-12-19 14:28:40 | whats | YOWSUP | chatstate: received from: 491XXXXX | chatstate | received from | 491XXXXX | 131 |
+---------------------+-------------+--------+----------------------------------------+-----------+---------------+--------------+----------+
in userReadings könnte ich es in etwa mit diesem Code korrigieren:
attr <device> valueFormat
{
if( $DEVICE eq "whats" && $VALUE =~ /^received from/ ) { $READING=$VALUE; $VALUE = $UNIT; }
elsif( $DEVICE eq "whats" && $VALUE =~ /^composing/ ) { $VALUE = undef; # don't save it to database!}
}
Morgen Joe,
ich werde mal schauen wie wir so etwas implementieren können.
Allerdings wird es bei mir etwas dauern. Ich möchte erst einmal den gegenwärtigen Stand eingecheckt haben wenn es nach einer entsprechenden Testzeit keine Einwände gibt.
Und dann muss ich mich mal um DbRep kümmern damit die dortigen Insertroutinen ebenfalls PK supporten können. Das klappt ja momentan noch nicht.
Vielleicht hat Dan etwas Zeit um sich darum Gedanken machen zu können. Schön wäre eine solche Funktion schon.
Grüße
Heiko
Hallo est,
wenn du mit den Maßnahmen nicht weiterkommst, dann gib mal im FHEMWEB in der KOmmandozeile ein:
{ delete $defs{myDbLog}{HELPER}{RUNNING_PID}}
Wird dann der Zustand wieder normalisiert ?
Grüße
Heiko
set myDbLog reopen 10 hat leider keine Veränderung gebracht.
Nach { delete $defs{myDbLog}{HELPER}{RUNNING_PID}} war der state 'Database access timeout' und CacheUsage hat neu zu zählen begonnen. Seit dem scheint das Loggen wieder zu funktionieren. Der MemCache ist aber offenbar auch verloren gegangen. Im Diagramm fehlt jedenfalls der Zeitraum von gestern Abend bis heute früh.
In dem List von vorhin, stehen ja die ganzen Daten (Bei mir in einer Datei - im Forum habe ich diesen Teil ja gekürzt). Das kann man aber auch nur mit großem Aufwand importieren - oder?
ZitatNach { delete $defs{myDbLog}{HELPER}{RUNNING_PID}} war der state 'Database access timeout' und CacheUsage hat neu zu zählen begonnen. Seit dem scheint das Loggen wieder zu funktionieren.
Dann werde ich die reopen-Funktion etwas erweitern damit solche Zustände (wahrscheinlich sehr selten , bei mir noch nie) bereinigt werden könnnen.
ZitatDer MemCache ist aber offenbar auch verloren gegangen. Im Diagramm fehlt jedenfalls der Zeitraum von gestern Abend bis heute früh.
Das ist allerdings unverständlich da nach der "Lösung des Knotens" alle vorhandenen Cache-Daten in die DB geschrieben werden, danach wird CacheUsage 0 (nach Browserrefresh) sein.
Schau mal deinem SQL-Editor in die DB zu den fraglichen Zeiten bzw. auch im fhem/MySQL-Log nach weiteren Hinweisen.EDIT: Sind mir gerade Schuppen von den Augen gefallen. Die Schreibfunktion ist in einen Timeout gelaufen weil seehr viele Daten in die DB zu schreiben waren. Die dafür benötigte Zeit lag über dem Timeout. -> Werde die Timeout-Zeit generall erhöhen um dem vorzubeugen.
Grüße
Heiko
Ich habe attr myDbLog Verbose 5 gesetzt und gespeichert. Das ging obwohl es in mit configDb in die gleiche Datenbank läuft.
Dann habe ich den Eventmonitor mit Häckchen für FHEM log geöffnet und { delete $defs{myDbLog}{HELPER}{RUNNING_PID}} ausgeführt:
10:44:12 4 : DbLog myDbLog -> ################################################################
2017.02.18 10:44:12 4 : DbLog myDbLog -> ### start of new Logcycle ###
2017.02.18 10:44:12 4 : DbLog myDbLog -> ################################################################
2017.02.18 10:44:12 4 : DbLog myDbLog -> amount of events received: 1 for device: ThermeSpeicherTemp
2017.02.18 10:44:12 4 : DbLog myDbLog -> check Device: ThermeSpeicherTemp , Event: 74.9
2017.02.18 10:44:12 4 : DbLog myDbL
og -> added event - Timestamp: 2017-02-18 10:44:12, Device: ThermeSpeicherTemp, Type: DUMMY, Event: 74.9, Reading: state, Value: 74.9, Unit: 2017.02.18 10:44:12 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:12 4 : DbLog myDbLog -> ### start of new Logcycle ###2017.02.18 10:44:12 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:12 4 : DbLog myDbLog -> amount of events received: 1 for device: myDbLog2017.02.18 10:44:12 4 : DbLog myDbLog -> check Device: myDbLog , Event: CacheUsage: 1082942017-02-18 10:44:12 DbLog myDbLog CacheUsage: 108294
2017.02.18 10:44:12 5 : DbLog myDbLog -> Number of cache entries reached cachelimit 1000 - start database sync.2017.02.18 10:44:12 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:12 4 : DbLog myDbLog -> ### start of new Logcycle ###2017.02.18 10:44:12 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:12 4 : DbLog myDbLog -> amount of events received: 1 for device: myDbLog2017.02.18 10:44:12 4 : DbLog myDbLog -> check Device: myDbLog , Event: Commit already running - resync at NextSync2017.02.18 10:44:12 4 : DbLog myDbLog -> added event - Timestamp: 2017-02-18 10:44:12, Device: myDbLog, Type: DBLOG, Event: Commit already running - resync at NextSync, Reading: state, Value: Commit already running - resync at NextSync, Unit: 2017.02.18 10:44:12 5 : DbLog myDbLog -> Number of cache entries reached cachelimit 1000 - start database sync.2017-02-18 10:44:12 DbLog myDbLog Commit already running - resync at NextSync
2017-02-18 10:44:12 DbLog myDbLog CacheUsage: 108295
2017-02-18 10:44:12 DbLog myDbLog CacheUsage: 108295
2017-02-18 10:44:12 DbLog myDbLog NextSync: 2017-02-18 10:44:42 or if CacheUsage 1000 reached
2017-02-18 10:44:12 DbLog myDbLog Commit already running - resync at NextSync
2017-02-18 10:44:12 dummy ThermeSpeicherTemp 74.9
2017.02.18 10:44:13 4 : DbLog myDbLog -> ################################################################
2017.02.18 10:44:13 4 : DbLog myDbLog -> ### start of new Logcycle ###
2017.02.18 10:44:13 4 : DbLog myDbLog -> ################################################################
2017.02.18 10:44:13 4 : DbLog myDbLog -> amount of events received: 1 for device: global
2017.02.18 10:44:13 4 : DbLog myDbLog -> check Device: global , Event: SAVE
2017.02.18 10:44:13 4 : DbLog myDbLog -> added event - Timestamp: 2017-02-18 10:44:13, Device: global, Type: GLOBAL, Event: SAVE, Reading: state, Value: SAVE, Unit:
2017.02.18 10:44:13 4 : DbLog myDbLog -> ################################################################
2017.02.18 10:44:13 4 : DbLog myDbLog -> ### start of new Logcycle ###
2017.02.18 10:44:13 4 : DbLog myDbLog -> ################################################################
2017.02.18 10:44:13 4 : DbLog myDbLog -> amount of events received: 1 for device: myDbLog
2017.02.18 10:44:13 4 : DbLog myDbLog -> check Device: myDbLog , Event: CacheUsage: 108296
2017-02-18 10:44:13 DbLog myDbLog CacheUsage: 108296
2017.02.18 10:44:13 5 : DbLog myDbLog -> Number of cache entries reached cachelimit 1000 - start database sync.
2017.02.18 10:44:13 4 : DbLog myDbLog -> ################################################################
2017.02.18 10:44:13 4 : DbLog myDbLog -> ### start of new Logcycle ###
2017.02.18 10:44:13 4 : DbLog myDbLog -> ################################################################
2017.02.18 10:44:13 4 : DbLog myDbLog -> amount of events received: 1 for device: myDbLog
2017.02.18 10:44:13 4 : DbLog myDbLog -> check Device: myDbLog , Event: Commit already running - resync at NextSync
2017.02.18 10:44:13 4 : DbLog myDbLog -> added event - Timestamp: 2017-02-18 10:44:13, Device: myDbLog, Type: DBLOG, Event: Commit already running - resync at NextSync, Reading: state, Value: Commit already running - resync at NextSync, Unit:
2017.02.18 10:44:13 5 : DbLog myDbLog -> Number of cache entries reached cachelimit 1000 - start database sync.
2017-02-18 10:44:13 DbLog myDbLog Commit already running - resync at NextSync
2017-02-18 10:44:13 DbLog myDbLog CacheUsage: 108297
2017-02-18 10:44:13 DbLog myDbLog CacheUsage: 108297
2017-02-18 10:44:13 DbLog myDbLog NextSync: 2017-02-18 10:44:43 or if CacheUsage 1000 reached
2017-02-18 10:44:13 DbLog myDbLog Commit already running - resync at NextSync
2017-02-18 10:44:13 Global global SAVE
2017.02.18 10:44:14 5 : DbLog myDbLog -> Start DbLog_PushAsyncDone
2017.02.18 10:44:14 5 : DbLog myDbLog -> DbLog_PushAsyncDone finished
2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################
2017.02.18 10:44:21 4 : DbLog myDbLog -> ### start of new Logcycle ###
2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################
2017.02.18 10:44:21 4 : DbLog myDbLog -> amount of events received: 1 for device: LetztesEventDerSteuerung
2017.02.18 10:44:21 4 : DbLog myDbLog -> check Device: LetztesEventDerSteuerung , Event: HKRuecklaufTemp2
2017-02-18 10:44:21 dummy LetztesEventDerSteuerung HKRuecklaufTemp2
2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################
2017.02.18 10:44:21 4 : DbLog myDbLog -> ### start of new Logcycle ###
2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################
2017.02.18 10:44:21 4 : DbLog myDbLog -> amount of events received: 1 for device: HKRuecklaufTemp2
2017.02.18 10:44:21 4 : DbLog myDbLog -> check Device: HKRuecklaufTemp2 , Event: 37.0
2017.02.18 10:44:21 4 : DbLog myDbLog -> added event - Timestamp: 2017-02-18 10:44:21, Device: HKRuecklaufTemp2, Type: DUMMY, Event: 37.0, Reading: state, Value: 37.0, Unit:
2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################
2017.02.18 10:44:21 4 : DbLog myDbLog -> ### start of new Logcycle ###
2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################
2017.02.18 10:44:21 4 : DbLog myDbLog -> amount of events received: 1 for device: myDbLog
2017.02.18 10:44:21 4 : DbLog myDbLog -> check Device: myDbLog , Event: CacheUsage: 3
2017-02-18 10:44:21 DbLog myDbLog CacheUsage: 3
2017-02-18 10:44:21 dummy HKRuecklaufTemp2 37.0
2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################
2017.02.18 10:44:21 4 : DbLog myDbLog -> ### start of new Logcycle ###
2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################
2017.02.18 10:44:21 4 : DbLog myDbLog -> amount of events received: 1 for device: LetztesEventDerSteuerung
2017.02.18 10:4
4:21 4 : DbLog myDbLog -> check Device: LetztesEventDerSteuerung , Event: HKVorlaufTemp12017-02-18 10:44:21 dummy LetztesEventDerSteuerung HKVorlaufTemp1
2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> ### start of new Logcycle ###2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> amount of events received: 1 for device: HKVorlaufTemp12017.02.18 10:44:21 4 : DbLog myDbLog -> check Device: HKVorlaufTemp1 , Event: 56.02017.02.18 10:44:21 4 : DbLog myDbLog -> added event - Timestamp: 2017-02-18 10:44:21, Device: HKVorlaufTemp1, Type: DUMMY, Event: 56.0, Reading: state, Value: 56.0, Unit: 2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> ### start of new Logcycle ###2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> amount of events received: 1 for device: myDbLog2017.02.18 10:44:21 4 : DbLog myDbLog -> check Device: myDbLog , Event: CacheUsage: 42017-02-18 10:44:21 DbLog myDbLog CacheUsage: 4
2017-02-18 10:44:21 dummy HKVorlaufTemp1 56.0
2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> ### start of new Logcycle ###2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> amount of events received: 1 for device: LetztesEventDerSteuerung2017.02.18 10:44:21 4 : DbLog myDbLog -> check Device: LetztesEventDerSteuerung , Event: SolarVorlauf2017-02-18 10:44:21 dummy LetztesEventDerSteuerung SolarVorlauf
2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> ### start of new Logcycle ###2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> amount of events received: 1 for device: LetztesEventDerSteuerung2017.02.18 10:44:21 4 : DbLog myDbLog -> check Device: LetztesEventDerSteuerung , Event: SolarLeistung2017-02-18 10:44:21 dummy LetztesEventDerSteuerung SolarLeistung
2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> ### start of new Logcycle ###2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> amount of events received: 1 for device: SolarLeistung2017.02.18 10:44:21 4 : DbLog myDbLog -> check Device: SolarLeistung , Event: 02017.02.18 10:44:21 4 : DbLog myDbLog -> added event - Timestamp: 2017-02-18 10:44:21, Device: SolarLeistung, Type: DUMMY, Event: 0, Reading: state, Value: 0, Unit: 2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> ### start of new Logcycle ###2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> amount of events received: 1 for device: myDbLog2017.02.18 10:44:21 4 : DbLog myDbLog -> check Device: myDbLog , Event: CacheUsage: 52017-02-18 10:44:21 DbLog myDbLog CacheUsage: 5
2017-02-18 10:44:21 dummy SolarLeistung 0
2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> ### start of new Logcycle ###2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> amount of events received: 1 for device: SolarVorlauf2017.02.18 10:44:21 4 : DbLog myDbLog -> check Device: SolarVorlauf , Event: 42.02017.02.18 10:44:21 4 : DbLog myDbLog -> added event - Timestamp: 2017-02-18 10:44:21, Device: SolarVorlauf, Type: DUMMY, Event: 42.0, Reading: state, Value: 42.0, Unit: 2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> ### start of new Logcycle ###2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> amount of events received: 1 for device: myDbLog2017.02.18 10:44:21 4 : DbLog myDbLog -> check Device: myDbLog , Event: CacheUsage: 62017-02-18 10:44:21 DbLog myDbLog CacheUsage: 6
2017-02-18 10:44:21 dummy SolarVorlauf 42.0
2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> ### start of new Logcycle ###2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> amount of events received: 1 for device: LetztesEventDerSteuerung2017.02.18 10:44:21 4 : DbLog myDbLog -> check Device: LetztesEventDerSteuerung , Event: SpeicherA32017-02-18 10:44:21 dummy LetztesEventDerSteuerung SpeicherA3
2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> ### start of new Logcycle ###2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> amount of events received: 1 for device: SpeicherA32017.02.18 10:44:21 4 : DbLog myDbLog -> check Device: SpeicherA3 , Event: 55.02017.02.18 10:44:21 4 : DbLog myDbLog -> added event - Timestamp: 2017-02-18 10:44:21, Device: SpeicherA3, Type: DUMMY, Event: 55.0, Reading: state, Value: 55.0, Unit: 2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> ### start of new Logcycle ###2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> amount of events received: 1 for device: myDbLog2017.02.18 10:44:21 4 : DbLog myDbLog -> check Device: myDbLog , Event: CacheUsage: 72017-02-18 10:44:21 DbLog myDbLog CacheUsage: 7
2017-02-18 10:44:21 dummy SpeicherA3 55.0
2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> ### start of new Logcycle ###2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> amount of events received: 1 for device: LetztesEventDerSteuerung2017.02.18 10:44:21 4 : DbLog myDbLog -> check Device: LetztesEventDerSteuerung , Event: SpeicherA42017-02-18 10:44:21 dummy LetztesEventDerSteuerung SpeicherA4
2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> ### start of new Logcycle ###2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> amount of events received: 1 for device: SpeicherA42017.02.18 10:44:21 4 : DbLog myDbLog -> check Device: SpeicherA4 , Event: 33.82017.02.18 10:44:21 4 : DbLog myDbLog -> added event - Timestamp: 2017-02-18 10:44:21, Device: SpeicherA4, Type: DUMMY, Event: 33.8, Reading: state, Value: 33.8, Unit: 2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> ### start of new Logcycle ###2017.02.18 10:44:21 4 : DbLog myDbLog -> ################################################################2017.02.18 10:44:21 4 : DbLog myDbLog -> amount of events received: 1 for device: myDbLog2017.02.18 10:44:21 4 : DbLog myDbLog -> check Device: myDbLog , Event: CacheUsage: 82017-02-18 10:44:21 DbLog myDbLog CacheUsage: 8
2017-02-18 10:44:21 dummy SpeicherA4 33.8
2017.02.18 10:44:25 4 : DbLog myDbLog -> ################################################################
2017.02.18 10:44:25 4 : DbLog myDbLog -> ### start of new Logcycle ###
2017.02.18 10:44:25 4 : DbLog myDbLog -> ################################################################
2017.02.18 10:44:25 4 : DbLog myDbLog -> amount of events received: 1 for device: LetztesEventDerSteuerung
2017.02.18 10:44:25 4 : DbLog myDbLog -> check Device: LetztesEventDerSteuerung , Event: HKVorlaufValue
2017-02-18 10:44:25 dummy LetztesEventDerSteuerung HKVorlaufValue
2017.02.18 10:44:25 4 : DbLog myDbLog -> ################################################################
2017.02.18 10:44:25 4 : DbLog myDbLog -> ### start of new Logcycle ###
2017.02.18 10:44:25 4 : DbLog myDbLog -> ################################################################
2017.02.18 10:44:25 4 : DbLog myDbLog -> amount of events received: 1 for device: HKVorlaufValue
2017.02.18 10:44:25 4 : DbLog myDbLog -> check Device: HKVorlaufValue , Event: 64.3
2017.02.18 10:44:25 4 : DbLog myDbLog -> added event - Timestamp: 2017-02-18 10:44:25, Device: HKVorlaufValue, Type: DUMMY, Event: 64.3, Reading: state, Value: 64.3, Unit:
2017.02.18 10:44:25 4 : DbLog myDbLog -> ################################################################
2017.02.18 10:44:25 4 : DbLog myDbLog -> ### start of new Logcycle ###
2017.02.18 10:44:25 4 : DbLog myDbLog -> ################################################################
2017.02.18 10:44:25 4 : DbLog myDbLog -> amount of events received: 1 for device: myDbLog
2017.02.18 10:44:25 4 : DbLog myDbLog -> check Device: myDbLog , Event: CacheUsage: 9
2017-02-18 10:44:25 DbLog myDbLog CacheUsage: 9
In der Datenbank sind für den fraglichen Zeitraum wirklich keine Daten.
Zitat von: est am 18 Februar 2017, 10:58:02
In dem List von vorhin, stehen ja die ganzen Daten (Bei mir in einer Datei - im Forum habe ich diesen Teil ja gekürzt). Das kann man aber auch nur mit großem Aufwand importieren - oder?
Wieviele sind das ca.?
Es gibt 2 Methoden, die mir spontan einfallen... da kann ich dir schon helfen!
Hallo est,
ja, siehe oben mein Edit.
Ich werde in Kürze eine Version hier einstellen die mit dieser etwas unglücklichen Situation besser umgehen kann.
Grüße
Heiko
Äh - 96628 Zeilen.
Solche:
myDbLog|DBLOG|Commit already running - resync at NextSync|state|Commit already running - resync at NextSync|
könnte man aber auch gleich wegschmeißen.
Danke für Dein Angebot. Ich denke ich verbessere dann selber mal meine sed-Kenntnisse und schmeiß das direkt in die Datenbank.
So ein Problem ist bei mir jetzt auch zum ersten mal aufgetreten. Scheint also nicht so häufig zu sein.
Jetzt wo es für neue Daten wieder funktioniert nehme ich mir mal meine eigentliche ToDo-Liste vor.
Vielen Dank für eure Hilfe.
Eddy
ZitatEs gibt 2 Methoden, die mir spontan einfallen... da kann ich dir schon helfen!
Falls du diese Methode noch nicht auf dem Schirm hast -> in eine CSV-Datei überführen und mit DbRep imporieren.
Sollte relativ gut machbar sein.
Zitat von: JoeALLb am 18 Februar 2017, 10:33:18
So wird bei mir aktuell eine Whatsapp-Nachricht geloggt. Mit ist bewußt, dass hier eine Implementierung von SplitFN im Modul
die korrekte lösung wäre, der Modulautor ist daran aber im Moment nicht interessiert.
+---------------------+-------------+--------+----------------------------------------+-----------+---------------+--------------+----------+
| TIMESTAMP | DEVICE | TYPE | EVENT | READING | VALUE | UNIT | count(*) |
+---------------------+-------------+--------+----------------------------------------+-----------+---------------+--------------+----------+
| 2016-12-19 14:30:02 | whats | YOWSUP | chatstate: composing | chatstate | composing | | 256 |
| 2016-12-19 14:31:34 | whats | YOWSUP | chatstate: paused | chatstate | paused | | 56 |
| 2016-12-19 14:28:40 | whats | YOWSUP | chatstate: received from: 491XXXXX | chatstate | received from | 491XXXXX | 131 |
+---------------------+-------------+--------+----------------------------------------+-----------+---------------+--------------+----------+
in userReadings könnte ich es in etwa mit diesem Code korrigieren:
attr <device> valueFormat
{
if( $DEVICE eq "whats" && $VALUE =~ /^received from/ ) { $READING=$VALUE; $VALUE = $UNIT; }
elsif( $DEVICE eq "whats" && $VALUE =~ /^composing/ ) { $VALUE = undef; # don't save it to database!}
}
Zitat von: DS_Starter am 18 Februar 2017, 10:42:33
ich werde mal schauen wie wir so etwas implementieren können.
Allerdings wird es bei mir etwas dauern. Ich möchte erst einmal den gegenwärtigen Stand eingecheckt haben wenn es nach einer entsprechenden Testzeit keine Einwände gibt.
Und dann muss ich mich mal um DbRep kümmern damit die dortigen Insertroutinen ebenfalls PK supporten können. Das klappt ja momentan noch nicht.
Vielleicht hat Dan etwas Zeit um sich darum Gedanken machen zu können. Schön wäre eine solche Funktion schon.
Ich hol das Thema noch mal hoch: Heiko, danke fürd drüberschauen und mitdenken.
Ich habe mit den Code dazu von readingsGroup schon angesehen, scheitere hier aber an den Grundlagen, also kann ich hierzu leider nichts beitragen.
(obwohl ich denke/hoffe, dass man viel von dort direkt übernehmen kann)
Zitat von: DeeSPe am 07 Februar 2017, 20:37:50
[...]
Wenn sich die Programmierarbeit in kleinere Tasks zerlegen lässt bin ich gerne bereit (Teil)Funktionen beizusteuern.
Gruß
Dan
@Dan, wäre das was für Dich?
Es gibt noch einen Anwendungsfall hierfür: Manche Module vertauschen "," und "." bei Zahlen, was Berechnungen verhindert. Auch das könnte hiermit korrigiert werden.
schöne Grüße
Joe
Öhem... ich habe ein ähnliches Problem wie @est...
MySQL läuft auf Synology DS1515+, FHEM als Docker Image ebenfalls auf der Synology.
DbLog ist die Version 2.11.4
Seit heute morgen tauchen in FHEM Log Fehlermeldungen von DbLog auf:
2017.02.18 07:39:34.915 2: DbLog logdb -> Error: DBD::mysql::st execute_array failed: executing 195 generated 1 errors at ./FHEM/93_DbLog.pm line 1357.
2017.02.18 07:44:27.070 2: DbLog logdb -> Error: DBD::mysql::st execute_array failed: executing 500 generated 1 errors at ./FHEM/93_DbLog.pm line 1357.
2017.02.18 07:51:08.428 2: DbLog logdb -> Error: DBD::mysql::st execute_array failed: executing 986 generated 1 errors at ./FHEM/93_DbLog.pm line 1357.
2017.02.18 07:55:06.955 2: DbLog logdb -> Error: DBD::mysql::st execute_array failed: executing 1348 generated 1 errors at ./FHEM/93_DbLog.pm line 1357.
2017.02.18 08:01:01.155 2: DbLog logdb -> Error: DBD::mysql::st execute_array failed: executing 2051 generated 1 errors at ./FHEM/93_DbLog.pm line 1357.
2017.02.18 08:09:16.073 2: DbLog logdb -> Error: DBD::mysql::st execute_array failed: executing 2812 generated 2 errors at ./FHEM/93_DbLog.pm line 1357.
2017.02.18 08:21:31.707 2: DbLog logdb -> Error: DBD::mysql::st execute_array failed: executing 4162 generated 4 errors at ./FHEM/93_DbLog.pm line 1357.
2017.02.18 08:38:22.634 2: DbLog logdb -> Error: DBD::mysql::st execute_array failed: executing 5754 generated 6 errors at ./FHEM/93_DbLog.pm line 1357.
2017.02.18 11:49:31.524 4: DbLog logdb -> ################################################################
2017.02.18 11:49:31.524 4: DbLog logdb -> ### start of new Logcycle ###
2017.02.18 11:49:31.524 4: DbLog logdb -> ################################################################
2017.02.18 11:49:31.525 4: DbLog logdb -> amount of events received: 1 for device: global
2017.02.18 11:49:31.525 4: DbLog logdb -> check Device: global , Event: ATTR logdb verbose 4
2017.02.18 11:49:31.525 4: DbLog logdb -> added event - Timestamp: 2017-02-18 11:49:31, Device: global, Type: GLOBAL, Event: ATTR lo
gdb verbose 4, Reading: state, Value: ATTR logdb verbose 4, Unit:
2017.02.18 11:49:31.670 4: DbLog logdb -> ################################################################
2017.02.18 11:49:31.670 4: DbLog logdb -> ### start of new Logcycle ###
2017.02.18 11:49:31.670 4: DbLog logdb -> ################################################################
2017.02.18 11:49:31.670 4: DbLog logdb -> amount of events received: 1 for device: ESPEasy.DS18B20_001D
2017.02.18 11:49:31.670 4: DbLog logdb -> check Device: ESPEasy.DS18B20_001D , Event: tem: 85.00
2017.02.18 11:49:31.671 4: DbLog logdb -> added event - Timestamp: 2017-02-18 11:49:31, Device: ESPEasy.DS18B20_001D, Type: ESPEASY,
Event: tem: 85.00, Reading: tem, Value: 85.00, Unit:
2017.02.18 11:49:31.806 4: DbLog logdb -> ################################################################
2017.02.18 11:49:31.806 4: DbLog logdb -> ### start of new Logcycle ###
2017.02.18 11:49:31.806 4: DbLog logdb -> ################################################################
2017.02.18 11:49:31.806 4: DbLog logdb -> amount of events received: 5 for device: ESPEasy_NodeMCUv3_01_Wasser
2017.02.18 11:49:31.807 4: DbLog logdb -> check Device: ESPEasy_NodeMCUv3_01_Wasser , Event: Ruecklauf: 11.1
2017.02.18 11:49:31.807 4: DbLog logdb -> added event - Timestamp: 2017-02-18 11:49:31, Device: ESPEasy_NodeMCUv3_01_Wasser, Type: E
SPEASY, Event: Ruecklauf: 11.1, Reading: Ruecklauf, Value: 11.1, Unit:
2017.02.18 11:49:31.810 4: DbLog logdb -> check Device: ESPEasy_NodeMCUv3_01_Wasser , Event: Delta: 0.0
2017.02.18 11:49:31.810 4: DbLog logdb -> added event - Timestamp: 2017-02-18 11:49:31, Device: ESPEasy_NodeMCUv3_01_Wasser, Type: E
SPEASY, Event: Delta: 0.0, Reading: Delta, Value: 0.0, Unit:
2017.02.18 11:49:31.813 4: DbLog logdb -> check Device: ESPEasy_NodeMCUv3_01_Wasser , Event: Vorlauf: 19.1
2017.02.18 11:49:31.813 4: DbLog logdb -> added event - Timestamp: 2017-02-18 11:49:31, Device: ESPEasy_NodeMCUv3_01_Wasser, Type: E
SPEASY, Event: Vorlauf: 19.1, Reading: Vorlauf, Value: 19.1, Unit:
2017.02.18 11:49:31.815 4: DbLog logdb -> check Device: ESPEasy_NodeMCUv3_01_Wasser , Event: Pumpe: 0.0
2017.02.18 11:49:31.816 4: DbLog logdb -> added event - Timestamp: 2017-02-18 11:49:31, Device: ESPEasy_NodeMCUv3_01_Wasser, Type: E
SPEASY, Event: Pumpe: 0.0, Reading: Pumpe, Value: 0.0, Unit:
2017.02.18 11:49:31.818 4: DbLog logdb -> check Device: ESPEasy_NodeMCUv3_01_Wasser , Event: Del: 0.0 Pum: 0.0 Rue: 11.1 Vor: 19.1
2017.02.18 11:49:31.818 4: DbLog logdb -> added event - Timestamp: 2017-02-18 11:49:31, Device: ESPEasy_NodeMCUv3_01_Wasser, Type: E
SPEASY, Event: Del: 0.0 Pum: 0.0 Rue: 11.1 Vor: 19.1, Reading: Del, Value: 0.0 Pum: 0.0 Rue: 11.1 Vor: 19.1, Unit:
Andere Auffälligkeiten habe ich nicht gesehen.
Von den meisten meiner Sensoren stehen keine Werte mehr in der Datenbank.
Bspw. enden die Eintragungen meines Stromzählers um 7:42:54.
select * from history where DEVICE='ESPEasy_NodeMCUv3_02_FIFO' AND TIMESTAMP > '2017-02-18 07:00:00' order by timestamp;
TIMESTAMP DEVICE TYPE EVENT READING VALUE UNIT
2017-02-18 07:00:02 ESPEasy_NodeMCUv3_02_FIFO ESPEASY Total: 6696.00 Total 6696.00
2017-02-18 07:00:02 ESPEasy_NodeMCUv3_02_FIFO ESPEASY t1: 451.97 t1 451.97
2017-02-18 07:00:02 ESPEasy_NodeMCUv3_02_FIFO ESPEASY t3: 453.88 t3 453.88
2017-02-18 07:00:02 ESPEasy_NodeMCUv3_02_FIFO ESPEASY t2: 452.72 t2 452.72
2017-02-18 07:00:02 ESPEasy_NodeMCUv3_02_FIFO ESPEASY Tot: 6696.00 t1: 451.97 t2: 452.72 t3: 453.88 Tot 6696.00 t1: 451.97 t2: 452.72 t3
2017-02-18 07:01:02 ESPEasy_NodeMCUv3_02_FIFO ESPEASY t3: 452.72 t3 452.72
2017-02-18 07:01:02 ESPEasy_NodeMCUv3_02_FIFO ESPEASY t2: 451.97 t2 451.97
2017-02-18 07:01:02 ESPEasy_NodeMCUv3_02_FIFO ESPEASY t1: 761.10 t1 761.10
2017-02-18 07:01:02 ESPEasy_NodeMCUv3_02_FIFO ESPEASY Total: 6697.00 Total 6697.00
2017-02-18 07:01:02 ESPEasy_NodeMCUv3_02_FIFO ESPEASY Tot: 6697.00 t1: 761.10 t2: 451.97 t3: 452.72 Tot 6697.00 t1: 761.10 t2: 451.97 t3
....
2017-02-18 07:42:04 ESPEasy_NodeMCUv3_02_FIFO ESPEASY Total: 6843.00 Total 6843.00
2017-02-18 07:42:04 ESPEasy_NodeMCUv3_02_FIFO ESPEASY t1: 2989.16 t1 2989.16
2017-02-18 07:42:04 ESPEasy_NodeMCUv3_02_FIFO ESPEASY t2: 2997.56 t2 2997.56
2017-02-18 07:42:04 ESPEasy_NodeMCUv3_02_FIFO ESPEASY t3: 2986.37 t3 2986.37
2017-02-18 07:42:04 ESPEasy_NodeMCUv3_02_FIFO ESPEASY Tot: 6843.00 t1: 2989.16 t2: 2997.56 t3: 2986.37 Tot 6843.00 t1: 2989.16 t2: 2997.56
2017-02-18 07:42:24 ESPEasy_NodeMCUv3_02_FIFO ESPEASY t1: 3017.92 t1 3017.92
2017-02-18 07:42:24 ESPEasy_NodeMCUv3_02_FIFO ESPEASY Total: 6844.00 Total 6844.00
2017-02-18 07:42:24 ESPEasy_NodeMCUv3_02_FIFO ESPEASY t3: 2997.56 t3 2997.56
2017-02-18 07:42:24 ESPEasy_NodeMCUv3_02_FIFO ESPEASY t2: 2989.16 t2 2989.16
2017-02-18 07:42:24 ESPEasy_NodeMCUv3_02_FIFO ESPEASY Tot: 6844.00 t1: 3017.92 t2: 2989.16 t3: 2997.56 Tot 6844.00 t1: 3017.92 t2: 2989.16
2017-02-18 07:42:54 ESPEasy_NodeMCUv3_02_FIFO ESPEASY t1: 1790.64 t1 1790.64
2017-02-18 07:42:54 ESPEasy_NodeMCUv3_02_FIFO ESPEASY Total: 6845.00 Total 6845.00
2017-02-18 07:42:54 ESPEasy_NodeMCUv3_02_FIFO ESPEASY t3: 2989.16 t3 2989.16
2017-02-18 07:42:54 ESPEasy_NodeMCUv3_02_FIFO ESPEASY t2: 3017.92 t2 3017.92
2017-02-18 07:42:54 ESPEasy_NodeMCUv3_02_FIFO ESPEASY Tot: 6845.00 t1: 1790.64 t2: 3017.92 t3: 2989.16 Tot 6845.00 t1: 1790.64 t2: 3017.92
Ein "set reopen" hat nichts gebracht, ein "set listcache" zeigt keine Daten aus dem fraglichen Zeitraum an.
Any hints?
Setz das verbose des DbLog-Device mal auf 5. Interessant ist dann der komplette Abschnitt mit "New database processing cycle".
EDIT: eine primary key hast du aber nicht gesetzt !?
EDIT2: Habe gerade gesehen dass es wohl ein Prob mit der current-Tabelle ist -> setzte die das Attr DbLogType mal nur auf "history" zum Vergleich des Verhaltens
ZitatEDIT: eine primary key hast du aber nicht gesetzt !?
Nein, habe die Datenbank noch nicht überarbeitet.
@All hier wurde ein Fehler im Modul gemeldet:
https://forum.fhem.de/index.php/topic,67326.0.html
Vielleicht können wir den Absturz von fhem abfangen..
Habe beim Versuch des reproduzierens auch meine memcache-Logs verloren... ;-)
Morgen Joe, hallo zusammen,
anbei die neue Version 2.13.4
Wegen der gemeldeten Situationen habe ich in dieser Version folgende Erweiterungen/Änderungen eingebaut:
1. Erweiterung der reopen-Funktion um einen abgestürzten asynchronen Prozess mit zu bereinigen.
2. default timeout der asynchronen Log-Funktion auf 1800s erhöht.
3. sowohl im synchronen als auch asynchronen Mode werden die Tabellen history und current in jeweils voneinander getrennt
ausgeführten/ausgewerteten Transaktionen behandelt um zu verhindern dass kein Commit für
die history-Daten erfolgt, falls es ein Problem mit der current-Tabelle geben sollte (falls man beide Tabellen verwendet).
(z.B. die current wurde nicht angelegt siehe 4., whatever ...)
Somit sind die Vorgänge zwischen history und current voneinander entkoppelt um eventuell auftretenden Problemen
vorzubeugen deren Ursache in der gemeinsamen Transaktion beider Tabellen liegt.
4. dem in https://forum.fhem.de/index.php/topic,67326.0.html gemeldeten Problem dass fhem crashed wenn das Attr DbLogType
nicht gesetzt ist UND die current Tabelle obendrein nicht angelegt ist, wurde durch eine geänderte Abfrage in
DbLog_sampleDataFn vorgebeugt.
Idealerweise müßte eine SQL-Abfrage auf die definitive Existenz der current-Tabelle erfolgen um dieses Problem
gänzlich auszuschließen,
@Joe, hast du ein passendes Statement welches für alle DB-Typen valide ist, bei der Hand ? Dann würde ich das demnächst mit
implementieren.
Bitte testet wieder auf euren Systemen und meldet bitte falls etwas auffällt.
EDIT: Habe noch einen kleinen Fehler beim restart ausgemerzt
"PERL WARNING: Found = in conditional, should be == at ./FHEM/93_DbLog.pm line 474,"
Grüße
Heiko
Zitat von: DS_Starter am 19 Februar 2017, 08:31:22
@Joe, hast du ein passendes Statement welches für alle DB-Typen valide ist, bei der Hand ? Dann würde ich das demnächst mit
implementieren.
Aus dem Stehgreif kenne ich diese Befehle...
Statt (count) kann man natürlich auch andere Werte wie Name, Größe etc.. abfragen.
#mysql
SELECT count(*) FROM INFORMATION_SCHEMA.TABLES where table_schema='fhem' and table_name='current';
#Postgres
SELECT count(*) FROM pg_catalog.pg_tables where schemaname='fhem' and tablename='current';
#sqlite
SELECT count(*) FROM sqlite_master r WHERE name='current';
Hi Joe,
danke dir !
Vielleicht wäre auch eine ganz einfache und für alle DBs passende Methode über ein eval auf die Tabelle currrent zuzugreifen:
select count(*) from current;
und auszuwerten ob es fehlerfrei möglich ist oder ein Fehlercode zurückkommt. Wenn die Tab nicht da ist, irgendwie nicht zugreifbar ist, was auch
immer .... kommt auf jedenfall ein Code zurück und dann greift der else-Zweig von DbLog_sampleDataFn. Damit sollte man sicher sein denke ich.
Ist mir gerade an der frischen Luft eingefallen.....
Grüße
Heiko
Zitat von: DS_Starter am 19 Februar 2017, 17:57:25
Ist mir gerade an der frischen Luft eingefallen.....
Frische Luft tut manchmal einfach gut :D Sehr gute Idee!
Diese Vorgehensweise bringt auch gleich einen Vorteil bezüglich Zugriffsrechte in den DBs mit:
Für den anderen Vorschlag bräuchten wir zugriff auf die die System-Tabellen (was zu mehr Supportaufwand bei manchen kommen könnte).
Edit: Formulierung
Hallo miteinander,
wie oben angekündigt habe ich in der angehängten Version 2.13.5 nun zusätzlich zu den Anpassungen in der 2.13.4 (#163) noch einen check auf die Zugreifbarkeit der current-Tabelle bei der Erstellung von neuen Plots eingebaut.
Falls man das Attribut DbLogType auf "Current" oder "History/Current" gesetzt haben sollte und die current-Tabelle nicht vorhanden, nicht zugreifbar sein oder sie keine Datensätze enthalten sollte, wird das Eingabefeld "device:reading::" zur manuellen Angabe bei der Ploterstellung angezeigt.
Das Verhalten ist somit das gleiche als ob man das Attribut DbLogType nicht oder nur auf "History" gesetzt hat.
Das heißt im Umkehrschluß .... nur wenn das Attribut DbLogType auf "Current" oder "History/Current" gesetzt ist UND die Tabelle current vorhanden ist UND diese Tabelle auch Einträge enthält, wird eine Drop-Down-Liste bei der Ploterstellung angezeigt.
Wenn man das Attribut DbLogType auf "Current" oder "History/Current" gesetzt hat und current nicht beschreibbar ist, kommt allerdings schon beim Logging eine Meldung im state. Es sollte also hinreichend auffallen. FHEM stürzt auf jeden Fall in dieser speziellen Konstellation nicht mehr ab.
Bitte übernehmt die Version für entsprechende Tests bei euch ...
Grüße
Heiko
Hallo zusammen,
die Version 2.13.5 läuft bei mir (und offfensichtlich auch bei euch wie an den Downloadzahlen zu sehen ist) schon seit einigen Tagen problemlos und ohne Auffälligkeiten.
Ich werde die Version nun demnächst einchecken bzw. Tobias bitten es zu tun.
viele Grüße und einen guten Wochenanfang.
Heiko
Hallo Heiko,
bei mir läuft's absolut Unauffällig, also alles bestens.
Besondere Tests konnte ich jedoch nicht machen.
SG Joe
2.13.5 bei mir auch ok
Grüsse
Michael
Hallo Michael,
danke für die Rückinfo.
@all ... habe die Version 2.13.5 soeben eingecheckt.
viele Grüße
Heiko
Zitat von: DS_Starter am 27 Februar 2017, 22:30:19
Hallo Michael,
danke für die Rückinfo.
@all ... habe die Version 2.13.5 soeben eingecheckt.
viele Grüße
Heiko
Danke Heiko!
Da Du ja mit alten Funktionen kompatibel geblieben bist, sollte es ja keine Probleme geben mit den neuen Funktionen.
Gruß
Dan
Hi Dan,
ja denke ich auch ....
Ich hatte mich erstmal mit der Umstellung meiner IT beschäftigt (unten Profil). Jetzt will ich auch mal an das Upgrade meiner Synology ran. Die ist noch auf 5.2 ...
Wenn wir noch weiter am DbLog entwickeln wollen dauert es zumindest bei mir nun etwas länger ;)
Grüße
Heiko
Mach mal ganz in Ruhe Heiko!
In den letzten Wochen hat sich hier echt viel getan. Würde sagen sogar mehr als ursprünglich angenommen. ;)
Hab gerade mal über das eingecheckte diff geschaut, meine Herren das ist ordentlich. :o
Gruß
Dan
Hab auf einem meiner Systeme mit MySQL ständig Folgendes im Log:
2017-03-02 20:05:51 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:06:21 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:07:21 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:07:51 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:08:21 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:08:51 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:09:21 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:09:51 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:10:21 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:10:51 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:11:21 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:11:51 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:12:21 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:12:51 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:13:21 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:14:21 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:14:51 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:15:21 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-02 20:15:51 DbLog DbLog state: Commit already running - resync at NextSync
???
Gruß
Dan
Hi Dan,
Da ist dir ein Hintergrund Prozess abgeschmiert.
Gib Mal ein Set reopen. Dann sollte sich das wieder fangen.
Grüße
Heiko
Hi Developers!
Erstmal herzlichen Dank für die Weiterentwicklung des Moduls- tolle Arbeit!
Ich bin gerade am Testen der reduceLogNbl funktion und möchte euch Feedback geben:
Folgende Werte hab ich erzielt:
cmd: reduceLogNbl 426 average INCLUDE=HMS100TF%:temperature
result: Rows processed: 2931030, deleted: 2882204, updated: 48486, time: 12388.00sec
der nächste:
cmd: reduceLogNbl 426 average INCLUDE=RPI1_TempSensor:temperature
result: processed: 823290, deleted: 804200, updated: 19053, time: 3621.00sec
Interessant dabei die werte aus top vom fhem host:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3174 fhem 20 0 331m 300m 3628 S 33.3 62.2 24:41.53 perl
2120 fhem 20 0 58724 32m 5464 S 12.0 6.7 95:21.68 perl
wobei pid 3174 der forked DbLog Task ist. grenzwertig ist die virt und res Zahl.
ich hab dann versucht das include etwas "weiter" zu fassen, dabei sind dann etliche 'cannot fork - out of memory' (von diversen tasks) gekommen.
Die letzte Zahl die ich gesehen habe war bei res: 400m, da sind dann freemem und swap schon sehr gegen null gegangen.
Environment: Fhem auf RPI-1, SQL Server auf QNAP419P
der sqldaemon (auf der QNAP) nimmt sich zw. 30 und 60% cpu während dem delete/update.
sql index hab ich den standart aus dblog. Gibts da noch Potential? ich hab da jetzt den Überblick im thread verloren....
l.g. erwin
Hi Erwin,
herzlichen Dank für dein Feedback.
Ist wirklich interressant mal ein paar Zahlen "aus dem Leben" zu sehen.
Was mich mal interressiert .... wie war denn während der Laufzeit des reduceLogNbl im Hintergrund (lief ja immerhin beim ersten Mal über 3 Stunden) das Reaktionsverhalten des FHEM auf dem RPi. Also lief alles andere noch gut ?
Wahrscheinlich ist es auf jeden Fall von Vorteil die DB auf einem anderen Server getrennt zu fahren. Denn der hat ja ordentlich CPU genommen während des Prozesses. Eine solche Umgebung habe ich ja ebenfalls, nur mit MariaDB auf Synology.
FHEM läuft jetzt mittlerweile auf einem NUC, das macht jetzt wirkich Freude :D
Aber ich baue noch an meiner Synology rum, habe viele Updates nachzuholen und das läuft nicht so reibungslos.
Was die Indizes betrifft bin ich mir selbst noch nicht so eins mit mir. Zur Zeit habe ich neben dem DbLog-Standardindex noch einen primary Key in der history und current (den nur zu Entwiclungszwecken) gesetzt und bilde mir ein dadurch Performancegewinn erzieht zu haben.
Den PK habe ich so angelegt:
DELETE FROM fhem.history WHERE TIMESTAMP IN (SELECT MAX(TIMESTAMP) FROM fhem.history GROUP BY TIMESTAMP, DEVICE, READING HAVING COUNT(*) > 1);
ALTER TABLE fhem.history ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);
Aber JoeAllb hat sich eine recht umfangreiche Testumgebung aufgebaut um verschiedene Index-Varianten zu testen.
Ich denke er kann dann noch Hinweise geben in welcher Konstellation er die besten Ergebnisse bei den verschiedenen DB's erziehlt hat.
Warten wir es mal ab.
LG
Heiko
Zitat von: DS_Starter am 02 März 2017, 20:49:04
Hi Dan,
Da ist dir ein Hintergrund Prozess abgeschmiert.
Gib Mal ein Set reopen. Dann sollte sich das wieder fangen.
Grüße
Heiko
Moin Heiko,
konnte erst soeben Deinen Ratschlag testen.
Leider keine Änderung:
2017-03-05 11:25:14 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:25:44 DbLog DbLog state: Commit already running - resync at NextSync
2017.03.05 11:25:55 3 : DbLog DbLog: Reopen requested.
2017.03.05 11:25:55 3 : DbLog DbLog: Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user root
2017.03.05 11:25:55 3 : DbLog DbLog: Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2017-03-05 11:25:55 DbLog DbLog state: connected
2017-03-05 11:25:55 DbLog DbLog CacheUsage: 5
2017-03-05 11:26:14 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:26:44 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:27:14 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:27:44 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:28:14 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:28:44 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:29:14 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:29:44 DbLog DbLog state: Commit already running - resync at NextSync
2017.03.05 11:30:07 3 : DbLog DbLog: Connection closed. Reopen requested in 10 seconds.
2017-03-05 11:30:07 DbLog DbLog state: closed for 10 seconds
2017-03-05 11:30:07 DbLog DbLog CacheUsage: 17
2017.03.05 11:30:17 3 : DbLog DbLog: Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user root
2017.03.05 11:30:17 3 : DbLog DbLog: Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2017-03-05 11:30:17 DbLog DbLog state: connected
2017-03-05 11:30:17 DbLog DbLog CacheUsage: 18
2017.03.05 11:30:17 3 : DbLog DbLog: Database connection reopen request finished.
2017-03-05 11:30:17 DbLog DbLog state: reopened
2017-03-05 11:30:17 DbLog DbLog CacheUsage: 19
2017-03-05 11:30:47 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:31:17 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:31:47 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:32:17 DbLog DbLog state: Commit already running - resync at NextSync
2017-03-05 11:32:47 DbLog DbLog state: Commit already running - resync at NextSyncHast Du noch eine Idee?
Gruß
Dan
Hi Heiko,
ich hätte noch schreiben sollen:
ca 25 Mio records in der DB , beginnend mit 1.1.2012, mySQL.
Zu den Antwortzeiten: soweit ok, ich hab auch ohne reduceLogNbl ab und zu einige freezes, speziell wenns um historische SVG-Plots, (Monat/Jahr) geht.
Ein Problem war ein kompletter Hänger für etliche Minuten , als ich einen Plot aus der DB holen wollte. - ist aber klar, kann nicht gehen wenn DB locked...
ich denke die sql-performance ist bei mir dzt. durch den RPI-1 limitiert, da liegt die CPU bei 40% für den SQL-fork und bei 25% für den main task.
Bin allerdings schon dabei einen RPI-3 aufzusetzten, schaun wir mal...
Das out-of-memory problem: ich hab mom. keine idee, wie man das abfangen könnte, es muss ja nicht notwendigerweise der sql-task betroffen sein, es kann jedes andere modul, welches forked ein problem bekommen...
Wenn ich mir noch eine Funktion wünschen dürfte, wäre dass folgende:
Ähnlich der average funktion, aber für nicht-numerische werte, also löschen aller records, ausser VALUE ändert sich, behalten von min 1 Wert/Stunde bzw. Tag...
l.g. & danke erwin
Hi Dan,
grundsätzlich kommt diese Meldung wenn noch "{HELPER}{RUNNING_PID}" gesetzt ist.
Mit einem "set ... reopen" wird dieser Eintrag ebenfalls gelöscht, zumindest in der neuesten Version.
Unter set ... findest du:
delete $hash->{HELPER}{RUNNING_PID};
Du kannst es auch mal versuchen über die Eingabezeile zu löschen:
{ delete $defs{myDbLog}{HELPER}{RUNNING_PID}}
Mit set reopen sollte es aber greifen. Kannst ja mit list auch schauen ob es diesen Helper-Eintrag noch gibt.
Probier mal.
Grüße
Heiko
Hallo Erwin,
ZitatWenn ich mir noch eine Funktion wünschen dürfte, wäre dass folgende:
Ähnlich der average funktion, aber für nicht-numerische werte, also löschen aller records, ausser VALUE ändert sich, behalten von min 1 Wert/Stunde bzw. Tag...
Ja, ich schau mal wenn ich wieder etwas mehr Zeit habe.
Sind bei mir gerade noch ein paar andere Baustellen um die ich mich kümmern muß.
DbLog hatte mich ziemlich in Anspruch genommen ;)
Grüße
Heiko
Hallo Joe,
kannst du bitte den Wunsch von erwin
ZitatWenn ich mir noch eine Funktion wünschen dürfte, wäre dass folgende:
Ähnlich der average funktion, aber für nicht-numerische werte, also löschen aller records, ausser VALUE ändert sich, behalten von min 1 Wert/Stunde bzw. Tag...
mit in deine Liste am Anfang einfügen ? Ich kann das ja nicht.
Und der Verweis auf die aktuelle Testversion ist auch veraltet.
LG
Heiko
Zitat von: DS_Starter am 05 März 2017, 11:55:34
Hi Dan,
grundsätzlich kommt diese Meldung wenn noch "{HELPER}{RUNNING_PID}" gesetzt ist.
Mit einem "set ... reopen" wird dieser Eintrag ebenfalls gelöscht, zumindest in der neuesten Version.
Unter set ... findest du:
delete $hash->{HELPER}{RUNNING_PID};
Du kannst es auch mal versuchen über die Eingabezeile zu löschen:
{ delete $defs{myDbLog}{HELPER}{RUNNING_PID}}
Mit set reopen sollte es aber greifen. Kannst ja mit list auch schauen ob es diesen Helper-Eintrag noch gibt.
Probier mal.
Grüße
Heiko
Hallo Heiko,
mein Problem sitzt irgendwie tiefer. >:(
Auf besagtem System werden alle BlockingCall(s) mit "Connection refused" im Log angezeigt.
Bin gerade etwas ratlos woher das resultiert, scheint nach bisherigen Erkenntnissen aber nichts mit DbLog zu tun zu haben.
Gruß
Dan
Hi Dan,
schau mal im Umfeld von telnet und allowed.
Möglicherweise darf keine Telnet-Session eröffnet werden.
Telnet-Paswort gesetzt ? usw...
Grüße
Heiko
Zitat von: DS_Starter am 05 März 2017, 13:11:47
Hi Dan,
schau mal im Umfeld von telnet und allowed.
Möglicherweise darf keine Telnet-Session eröffnet werden.
Telnet-Paswort gesetzt ? usw...
Grüße
Heiko
Danke, das habe ich schon getan.
Kann mich auch problemlos auf den Host per telnet verbinden mit globalpassword.
Alles was ich bisher geprüft habe ist identisch zu meinen anderen Hosts, trotzdem bleibt es beim refused.
Gruß
Dan
Update aus den Benchmarks:
Die bei mir aktuell schnellste Konfiguration ist diese:
Die Tabelle zeigt für alle berüksichtigten SQLs (wenn ihr weitere habt, die wichtig sind, bitte zusenden)
das beste Ergebnis.
Die Tabelle ist hier partitioniert, das bringt auf meinem kleinen System ca. 10% bessere Ergebnisse wie ohne Partition.
CREATE TABLE `history` (
`TIMESTAMP` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
`DEVICE` VARCHAR(64) NOT NULL DEFAULT '' COLLATE 'latin1_bin',
`TYPE` VARCHAR(32) NULL DEFAULT NULL COLLATE 'latin1_bin',
`EVENT` VARCHAR(64) NULL DEFAULT NULL COLLATE 'latin1_bin',
`READING` VARCHAR(64) NOT NULL DEFAULT '' COLLATE 'latin1_bin',
`VALUE` VARCHAR(32) NULL DEFAULT NULL COLLATE 'latin1_bin',
`UNIT` VARCHAR(32) NULL DEFAULT NULL COLLATE 'latin1_bin',
PRIMARY KEY (`DEVICE`, `READING`, `TIMESTAMP`),
INDEX `DbLog_Group` (`TIMESTAMP`, `DEVICE`, `READING`)
)
COLLATE='latin1_bin'
PARTITION BY RANGE COLUMNS(device)
(PARTITION Arest VALUES LESS THAN ('#') ENGINE = Aria,
PARTITION Btrash VALUES LESS THAN ('$') ENGINE = Aria,
PARTITION Eg VALUES LESS THAN ('E') ENGINE = Aria,
PARTITION Ig VALUES LESS THAN ('I') ENGINE = Aria,
PARTITION Og VALUES LESS THAN ('O') ENGINE = Aria,
PARTITION Ug VALUES LESS THAN ('U') ENGINE = Aria,
PARTITION ak VALUES LESS THAN ('a') ENGINE = Aria,
PARTITION ek VALUES LESS THAN ('e') ENGINE = Aria,
PARTITION ik VALUES LESS THAN ('i') ENGINE = Aria,
PARTITION ok VALUES LESS THAN ('o') ENGINE = Aria,
PARTITION uk VALUES LESS THAN ('u') ENGINE = Aria,
PARTITION zk VALUES LESS THAN ('z') ENGINE = Aria,
PARTITION zz VALUES LESS THAN (MAXVALUE) ENGINE = Aria);
Zusätzlich kann ich hier sehr ressourcensparend Datensätze löschen.
Ich habe dies bei mir so konfiguriert, dass ich alle Datensätze, die ich nicht lange aufbewahren möchte umbenenne.
Device="HeizungBad" wird dann zu "Device=#HeizungBad".
Durch die vorangestellte "#" werden solche Datensätze in die Partition "Btrash" verschoben.
Die andere Aufteilung der Partitionen ist so gewählt, um eine durchschnittliche VErteilung der Devices zu erziehlen. Wenn ihr alle Devices mit einem bestimmtem Prefix
angelegt habt, müsst ihr die Partitionsaufteilung ggf. abändern.
Für Berechnungen kann ich mit diesem Layout auch noch die Trash-Datensätze nutzen.
Mit
ALTER TABLE history TRUNCATE PARTITION Btrash;
lösche ich diese Daten des Papierkorbs dann "verzögerungsfrei".
Vermutlich ist das alles nicht wirklich einfach genug für den Endanwender, funktioniert jedoch für mich wunderbar!
Welche Bereinigungen kosten denn im Moment am meisten Performance? Vielleicht kann ich da noch etwas finden?
sG
Joe
Hallo miteinander,
ich habe eine neue Version 2.13.6 hier angehängt. Es sind keine neuen Funktionen hinzugekommen, nur Ergänzungen die aus
Hinweisen aus dem Forum resultieren.
* es ist für die reduceLog(Nbl) Funktion ein erweiterter Plausibilitätscheck hinzugekommen der z.B. Schreibfehler
wie "verage" statt "average" abfängt und die Funktion dann nicht loslaufen lässt.
(https://forum.fhem.de/index.php/topic,68713.msg601965.html#msg601965 (https://forum.fhem.de/index.php/topic,68713.msg601965.html#msg601965))
* Ausstattung der Get-Funktion (Ploterstellung) mit einem separaten DB-Handle zur proaktiven Optimierung
Würde mich freuen wenn ihr diese Version wieder bei euch integriert und Feedback gebt ob es bei euch ebenso läuft.
Bitte FHEM nach Einspielung restarten !
viele Grüße
Heiko
Bisher höchst unauffällig ;-) Danke für die Version!!
Hallo Heiko,
im Log finde ich immer wieder mal solche Einträge,
leider ohne Information, warum diese nicht gespeichert werden können.
Ich vermute mal, dass hier nicht alle Daten ausreichend vorhanden sind, im Falle cin
HeizunDI wurde nur in ein Status verändert das Event der Readinggroup wird hier (denk ich) nicht korrekt erkannt?!?
Dies ist aber unabhängig von der aktuellen Version, diese Meldungen hatte ich zuvor auch.
2017.03.16 19:11:53 3: DbLog myDbLogSQL -> Failed to insert into history - TS: 2017-03-16 19:11:39, Device: HeizDI, Event: Auto
2017.03.16 19:11:53 3: DbLog myDbLogSQL -> Failed to insert into history - TS: 2017-03-16 19:11:39, Device: rg_HeizunP, Event: HeizunDI.state: <html>Auto</html>
2017.03.17 02:14:37 3: DbLog myDbLogSQL -> Failed to insert into history - TS: 2017-03-17 02:14:01, Device: telegram, Event: PollingErrCount: 2
2017.03.17 03:26:44 3: DbLog myDbLogSQL -> Failed to insert into history - TS: 2017-03-17 03:26:05, Device: KNX_020001, Event: getG1: 0.000
2017.03.17 03:26:44 3: DbLog myDbLogSQL -> Failed to insert into history - TS: 2017-03-17 03:26:05, Device: KNX_020001, Event: last-sender: 1/1/20
2017.03.17 03:26:44 3: DbLog myDbLogSQL -> Failed to insert into history - TS: 2017-03-17 03:26:05, Device: KNX_020001, Event: 0.000
Hast Du eine Idee dazu?
Davor und danach stehen leider keine näheren Hinweise im Log.
Hallo Joe,
Das Array insert bringt nur zurück ob ein Element erfolgreich gespeichert wurde oder nicht. Deswegen sind die Infos etwas mager.
Aber der Grund für diese Meldungen ist (übrigens auch bei mir) wenn der Primary Key das Speichern verhinderte.
Siehst du auch dass der Timestamp gleich ist, das Device auch. Schau mal in deine DB. Du wirst mit ziemlicher Sicherheit bereits einen Eintrag zu fraglicher Zeit mit dem Device und dem angemeckerten Reading (als Teil des Events) finden.
Wenn du den PK löscht wird es diese Fehler nicht mehr geben. Bin auch schon längere Zeit am Überlegen ob man PK noch etwas anders bauen könnte/sollte.
Grüße
Heiko
Hallo Heiko,
Sorry, da hätte ich auch selber drauf kommen können. Danke für Deine Antwort! Ich habe das sogar geprüft, jedoch wegen einem Tippfehler im SQL keine Werte erhalten.
Den PK sehe ich eigentlich so schon als genau richtig, denn was bedeuten Werte zur exakt gleichen zeit mit gleichem Reading? Das ist nichts wirklich brauchbares.
Eher würde ich das nutzen, um die Module zu korrigieren, die so etwas produzieren. Bisher habe ich dadurch 2 fehlerhafte Module entdeckt (wurden bereits korrigiert).
Diese Fälle habe ich im Moment entdeckt, die doppelte Logeinträge generieren:
# Das KNX-Modul schreibt denke ich tatsächlich manchmal doppelte Events
# DOIFs, die sich selbst aufrufen, verursachen ebenfalls doppelte Logs (welche ich nicht benötige)
# Die Readingsgroup duplizierte Events von dargestellten Devices... habe das abgestellt indem ich die RG mit DbLogExclude versehen habe. Da dies nur zur Anzeige benutzt wird will ich dort nichts loggen.
# userReadings ohne Filter für Events. Wenn das zugrundeliegende Device mehrere Readings gleichzeitig aktualisiert, wird dieses userReading mehrmals zur selben Zeit neu berechnet. In den meisten Fällen ist dies auch aus Performancegründen nicht optimal.
Idee:
Wie wäre es, wenn wir die Fehlermeldung
DbLog sql -> Failed to insert into history -
durch
DbLog sql -> Failed to insert into history (check for possible PK violation)-
ersetzen? Dadurch könnten vielleicht zukünftige Fragen diesbezüglich hier reduziert werden?!
Aus aktuellem Anlass hätte ich auch noch einen Wunsch (auch wenn ich es manuell halbwegs lösen konnte)
Die Festplatte meiner DB eines Systems hatte sich verabschiedet, im Cache waren 117000 Einträge.
Eine andere Festplatte im System funktionierte noch.
Mein Wunsch wäre also:
set sql exportCache /mnt/usb/export.data purgeCache
und
set sql importCache /mnt/usb/export.data
Der optionale Parameter "purgeCache" sollte den Speicher des Caches löschen, nachdem dieser erfolgreich in die Datei geschrieben wurde.
Wenn ich das ohne diesen Parameter manuell über "set sql purgeCache" mache, vergeht zuviel Zeit zwischen dem schreiben der Datei und dem Löschen des Caches, ich verliere
dadurch also zu viele Einträge...
Grüße
Joe
Hi Joe,
ja, die Fehlermeldung "Failed to insert into history ..." kann ich noch etwas pimpen. Ich wollt esie nur nicht so lang werden lassen. Es kommt nach dem ganzen blabla ja noch der Inhalt des nicht gespeicherten Events an sich. Aber du hast recht, dann kommt man evtl. schneller drauf.
Die andrere Sache
set sql exportCache /mnt/usb/export.data purgeCache
kann ich gerne mit mit vorsehen.
Wenn ich dich richtig verstanden habe, soll der Befehl exportCache nur den Inhalt des Caches in eine beliebige Textdatei an beliebiger Stelle schreiben können (optional mit löschen des Caches danach) damit man die Daten im Disasterfall (wie bei dir) nicht verliert sondern hinterher, wenn man seine DB verfügbar hat, wieder importieren kann. Habe ich das so richtig zusammengefasst ?
Grüße
Heiko
Zitat von: DS_Starter am 17 März 2017, 12:57:44
Wenn ich dich richtig verstanden habe, soll der Befehl exportCache nur den Inhalt des Caches in eine beliebige Textdatei an beliebiger Stelle schreiben können (optional mit löschen des Caches danach) damit man die Daten im Disasterfall (wie bei dir) nicht verliert sondern hinterher, wenn man seine DB verfügbar hat, wieder importieren kann. Habe ich das so richtig zusammengefasst ?
Perfekt, genau so sind meine Überlegungen... Ich wußte einfach nicht wie groß der Cache werden kann/darf, weshalb ich ihn bei dieser Größe leeren wollte.
Natürlich habe ich auch überlegt, kurzfristig auf sqlite zu wechseln, da dies aber nicht ohne ein redefine des moduls geht, hab ich davon die finger gelassen....
Wenn der Config-String als Attribut möglich wäre, wäre das vermutlich auch eine Option gewesen... aber durch ein redefine des DbLog-Devices hätte ich (vermutlich) den Cache komplett verloren...
sG
Joe
ZitatNatürlich habe ich auch überlegt, kurzfristig auf sqlite zu wechseln, da dies aber nicht ohne ein redefine des moduls geht, hab ich davon die finger gelassen....
Hättest du IMHO mal probieren können. Modul so lassen, nur die Config-Datei entsprechend ändern und ein "rereadcfg" machen. Sollte klappen und den Cache auch nicht in Mitleidenschaft ziehen.
Deinen Wunsch will ich mal versuchen umzusetzen. WE wird verregnet ;)
Mal schauen wie ich Zeit habe.
Grüße
Heiko
Hallo,
ich bin mir nicht ganz sicher ob ich hier im Thread richtig bin, aber ich habe nach einigen Tagen wieder mal in meine Testinstallation (sqlite) reingeschaut und ein update angestoßen:
Internals:
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION /opt/fhem/db.conf
DBMODEL SQLITE
DEF /opt/fhem/db.conf .*:.*
MODE asynchronous
NAME myDbLog
NR 19
NTFY_ORDER 50-myDbLog
PID 1508
REGEXP .*:.*
STATE DBD::SQLite::st execute_array failed: executing 47 generated 1 errors at ./FHEM/93_DbLog.pm line 1581.
, 0
TYPE DbLog
VERSION 2.13.5
dbconn SQLite:dbname=/opt/fhem/fhem.db
dbuser
Helper:
COLSET 1
DEVICECOL 64
EVENTCOL 512
READINGCOL 64
TYPECOL 64
UNITCOL 32
VALUECOL 128
Helper:
Dblog:
Countcurrent:
Mydblog:
TIME 1489759165.21155
VALUE 47
Readings:
2017-03-17 15:00:37 CacheUsage 47
2017-03-17 15:00:37 NextSync 2017-03-17 15:01:07 or if CacheUsage 500 reached
2017-03-17 14:59:25 countCurrent 47
2017-03-16 03:19:24 countHistory 702538
2016-12-31 00:05:28 lastRowsDeleted 22663
2017-03-17 15:00:37 state DBD::SQLite::st execute_array failed: executing 47 generated 1 errors at ./FHEM/93_DbLog.pm line 1581.
, 0
2017-02-26 12:23:04 userCommand DELETE FROM history WHERE device = 'ESPEasy_ESPTest_System' AND TIMESTAMP < datetime(1487848063, 'unixepoch');
2016-08-07 18:58:03 userCommandResult 2016-08-07
Cache:
index 152
Memcache:
106 2017-03-17 14:59:59|mySysMon|SYSMON|ram: Total: 181.38 MB, Used: 80.70 MB, 44.49 %, Free: 100.68 MB|ram|Total: 181.38 MB, Used: 80.70 MB, 44.49 %, Free: 100.68 MB|
107 2017-03-17 15:00:04|MyBroker|MQTT|connection: active|connection|active|
108 2017-03-17 15:00:11|ESPEasy_ESPTest_System|ESPEASY|rssi: -91|rssi|-91|
109 2017-03-17 15:00:11|ESPEasy_ESPTest_System|ESPEASY|ram: 25328 rss: -91 upt: 188622|ram|25328 rss: -91 upt: 188622|
110 2017-03-17 15:00:28|ESPEasy_ESPTest_System|ESPEASY|upt: 188623|upt|188623|
111 2017-03-17 15:00:28|ESPEasy_ESPTest_System|ESPEASY|ram: 25328 rss: -91 upt: 188623|ram|25328 rss: -91 upt: 188623|
112 2017-03-17 14:59:07|MyBroker|MQTT|connection: connected|connection|connected|
113 2017-03-17 14:59:28|ESPEasy_ESPTest_System|ESPEASY|upt: 188622|upt|188622|
114 2017-03-17 14:59:28|ESPEasy_ESPTest_System|ESPEASY|ram: 25144 rss: -90 upt: 188622|ram|25144 rss: -90 upt: 188622|
115 2017-03-17 14:59:34|ESPEasy_ESPTest_System|ESPEASY|ram: 25328|ram|25328|
116 2017-03-17 14:59:34|ESPEasy_ESPTest_System|ESPEASY|ram: 25328 rss: -90 upt: 188622|ram|25328 rss: -90 upt: 188622|
117 2017-03-17 14:59:35|Blume2|XIAOMIFLOWERSENS|active|state|active|
118 2017-03-17 14:59:35|Blume2|XIAOMIFLOWERSENS|call data|state|call data|
119 2017-03-17 14:59:07|MyBroker|MQTT|connection: active|connection|active|
120 2017-03-17 14:59:09|ESPEasy_ESPTest_System|ESPEASY|ram: 25144|ram|25144|
121 2017-03-17 14:59:09|ESPEasy_ESPTest_System|ESPEASY|ram: 25144|ram|25144|
122 2017-03-17 14:59:11|ESPEasy_ESPTest_System|ESPEASY|rssi: -90|rssi|-90|
123 2017-03-17 14:59:11|ESPEasy_ESPTest_System|ESPEASY|ram: 25144 rss: -90|ram|25144 rss|-90
124 2017-03-17 14:59:20|Sys2|MQTT_DEVICE|Uptime: 191479.00|Uptime|191479.00|
125 2017-03-17 14:59:24|global|GLOBAL|DEFINED telnetForBlockingFn_1489759164|state|DEFINED telnetForBlockingFn_1489759164|
126 2017-03-17 14:59:25|myDbLog|DBLOG|countCurrent: 47|countCurrent|47|
127 2017-03-17 14:59:38|Blume2|XIAOMIFLOWERSENS|battery: ok|battery|ok|
128 2017-03-17 14:59:38|Blume2|XIAOMIFLOWERSENS|temperature: 25.1|temperature|25.1|°C
129 2017-03-17 14:59:38|Blume2|XIAOMIFLOWERSENS|lux: 2157|lux|2157|
130 2017-03-17 14:59:38|Blume2|XIAOMIFLOWERSENS|moisture: 81|moisture|81|
131 2017-03-17 14:59:38|Blume2|XIAOMIFLOWERSENS|fertility: 1565|fertility|1565|
132 2017-03-17 14:59:38|Blume2|XIAOMIFLOWERSENS|firmware: 2.7.0|firmware|2.7.0|
133 2017-03-17 14:59:38|Blume2|XIAOMIFLOWERSENS|active|state|active|
134 2017-03-17 14:59:41|ESPEasy_ESPTest_System|ESPEASY|rssi: -92|rssi|-92|
135 2017-03-17 14:59:41|ESPEasy_ESPTest_System|ESPEASY|ram: 25328 rss: -92 upt: 188622|ram|25328 rss: -92 upt: 188622|
136 2017-03-17 14:59:48|Blume1|XIAOMIFLOWERSENS|active|state|active|
137 2017-03-17 14:59:48|Blume1|XIAOMIFLOWERSENS|call data|state|call data|
138 2017-03-17 14:59:50|Sys2|MQTT_DEVICE|Uptime: 191480.00|Uptime|191480.00|
139 2017-03-17 14:59:55|Blume1|XIAOMIFLOWERSENS|battery: ok|battery|ok|
140 2017-03-17 14:59:55|Blume1|XIAOMIFLOWERSENS|temperature: 25.2|temperature|25.2|°C
141 2017-03-17 14:59:55|Blume1|XIAOMIFLOWERSENS|lux: 6408|lux|6408|
142 2017-03-17 14:59:55|Blume1|XIAOMIFLOWERSENS|moisture: 19|moisture|19|
143 2017-03-17 14:59:55|Blume1|XIAOMIFLOWERSENS|fertility: 1709|fertility|1709|
144 2017-03-17 14:59:55|Blume1|XIAOMIFLOWERSENS|firmware: 2.6.2|firmware|2.6.2|
145 2017-03-17 14:59:55|Blume1|XIAOMIFLOWERSENS|active|state|active|
146 2017-03-17 14:59:58|mySysMon|SYSMON|cpu_freq: 700|cpu_freq|700|
147 2017-03-17 14:59:59|mySysMon|SYSMON|cpu_temp_avg: 51.8|cpu_temp_avg|51.8|
148 2017-03-17 14:59:59|mySysMon|SYSMON|loadavg: 0.38 0.18 0.16|loadavg|0.38 0.18 0.16|
149 2017-03-17 14:59:59|mySysMon|SYSMON|cpu_temp: 51.92|cpu_temp|51.92|
150 2017-03-17 14:59:59|mySysMon|SYSMON|eth0_diff: RX: 0.06 MB, TX: 0.06 MB, Total: 0.12 MB|eth0_diff|RX: 0.06 MB, TX: 0.06 MB, Total: 0.12 MB|
151 2017-03-17 14:59:59|mySysMon|SYSMON|fs_boot: Total: 60 MB, Used: 20 MB, 34 %, Available: 41 MB at /boot|fs_boot|Total: 60 MB, Used: 20 MB, 34 %, Available: 41 MB at /boot|
152 2017-03-17 14:59:59|mySysMon|SYSMON|fs_root: Total: 7351 MB, Used: 4631 MB, 67 %, Available: 2367 MB at /|fs_root|Total: 7351 MB, Used: 4631 MB, 67 %, Available: 2367 MB at /|
Attributes:
DbLogType History
asyncMode 1
verbose 5
2017.03.17 15:02:38 2: DbLog myDbLog -> Error table history - DBD::SQLite::st execute_array failed: executing 77 generated 1 errors at ./FHEM/93_DbLog.pm line 1581.
2017.03.17 15:02:38 5: DbLog myDbLog -> DbLog_PushAsync finished
2017.03.17 15:02:38 5: DbLog myDbLog -> Start DbLog_PushAsyncDone
2017.03.17 15:02:38 4: DbLog myDbLog -> ################################################################
2017.03.17 15:02:38 4: DbLog myDbLog -> ### start of new Logcycle ###
2017.03.17 15:02:38 4: DbLog myDbLog -> ################################################################
2017.03.17 15:02:38 4: DbLog myDbLog -> amount of events received: 1 for device: myDbLog
2017.03.17 15:02:38 4: DbLog myDbLog -> check Device: myDbLog , Event: DBD::SQLite::st execute_array failed: executing 77 generated 1 errors at ./FHEM/93_DbLog.pm line 1581.
, 0
2017.03.17 15:02:38 5: DbLog myDbLog -> DbLog_PushAsyncDone finished
Grüße
Pyro
Hallo Pyro,
der Prozess kann auf deine DB (bzw. Tabelle) nicht zugreifen. Bei mir kommt das (nur bei SQLite) immer mal wieder vor wenn ich die DB mal mit einem externen SQL-Editor geöffnet hatte.
Üblicherweise hilft ein "reopen" um den Zustand dann wieder zu beseitigen. Möglicherweise hängt noch ein anderer Prozess auf deiner DB.
Nebenbei ... da du mit ".*:.* " arbeitest und alles logst was so an events kommt, würde ich mit excludeDevs zumindest das eigene Logdevice myDbLog davon ausschließen.
Grüße
Heiko
Nabend Heiko,
danke für den Hinweis bezüglich meines großzügigen Loggings, aber beim Testsystem ist es gewollt.
Das Problem konnte ich inzwischen auch beheben, die Datenbank war beschädigt und konnte durch ein umkopieren wiederhergestellt werden. Falls jemand mal in einer ähnlichen Situation ist, hier die notwendigen Befehle:
sudo sqlite3 /opt/fhem/fhem.db ".dump" | sudo sqlite3 /opt/fhem/fhem2.db
sudo chown -c fhem /opt/fhem/fhem2.db
Danach entweder die db.conf anpassen oder die beschädigte Datenbankdatei löschen und fhem2.db in fhem.db umbenennen.
Hallo,
in Bezug auf Optimierung habe ich da eine Frage.
Ich habe dblog eingerichtet gem. Wiki.
Also in "/opt/fhem/fhem.db"
Nun möchte die die Belastung meiner SD Karte reduzieren. (gebranntes Kind:-) )
Ich möchte daher die Datenbank auf den USB Stick auslagern.
Ich hätte kein Problem damit die Datenbank neu anzulegen: sudo sqlite3 /media/usbstick/DB/fhem.db
Ist es sinnvoll, die Datenbank auf den USB Stick umzuziehen ?
Soll ich die DB auf dem USB Stick NEU anlegen und dann in der db.conf den Eintrag "/media/usbstick/DB/fhem.db" machen oder mit einem symbolischen link arbeiten ?
Was ist der sinnvollste Weg ?
Danke für die Infos
Jörg
Hallo Jörg,
mit SqLite weiß ich es leide rnicht genau, meine DB war damals manchmal corrupt, weshalb ich auf MySQL/MariaDB umgestiegen bin.
Seit 4 Jahren läuft das auf ein paar RPIS eigentlich problemlos, ich nutze gute! SD-Karten und nutze bei den Datenbanken Partitionen, dass die Daten auf mehrere Dateien aufgeteilt werden.
wie gesagt, bisher ohne korrupion und bei guter Geschwindigkeit.
Und der neue ASYNC-Modus trägt ebenfalls dazu bei, dass die Daten seltener geschrieben werden....
Auf einen USB-Stick mache ich tägliche Backups. Habe jedoch festgestellt, dass der USB.Stick mein Booten für mySQL regelmäßig zu spät gemouted wird, musste dafür eine Pause im Startscript einbauen.
Ich hoffe, dass meine Erfahrung Dir ein bisschen helfen konnte ;-)
Grüße
Joe
Frage zum asyncMode:
In der Commandref steht unter attr asyncMode: "Attribut "timeout" (Default 120s)".
Bei attr timeout steht: " im asynchronen Modus (default 1800s)".
Beobachte ich das Reading NextSync, wechselt das alle 30 Sekunden.
Zeitweise hatte ich attr timeout auf 600 stehen, das hat aber anscheinend (lt. Reading NextSync) nicht gezogen.
Habe ich etwas nicht verstanden oder gibt es da noch einen kleinen Fehler?
LG
Holger
Hallo Holger,
den timeout hatte ich früher auf 120s stehen und wegen diverser Hinweise auf default 1800 gesetzt. Ich schau nochmal durch das Modul durch ob ich eine Stelle vergessen habe umzuschreiben.
Aber das ist nur der timeout für den geforkten Hintergrundprozesse im Asynchmode. Das Intervall zum Wegschreiben der Daten in die DB stellst du mit dem Attribut syncInterval ein.
schönes WE
Heiko
Hallo Heiko,
danke für die Info - ist schon etwas verwirrend, wenn man nicht im Thema drinsteckt. Aber das mit dem Attribut syncInterval hätte ich auch schon selber lesen können :-[
LG
Holger
Hallo miteienader,
anbei die weiterentwickelte Version 2.14.0.
Was ist neu bzw. verändert ? Hier die Liste:
* neue set-Befehle exportCache und importCachefile sowie neues Attr expimpdir
Die Befehle dienen zum Export bzw. Import von Cacheinhalten so wie Joe es vergeschlagen hat.
Der Filename wird fest generiert. Er beginnt mit "cache_" gefolgt von dem DbLog-Namen (z.B. LogDB) und dem
aktuellen Zeitstamp des Exports. Ich habe es extra fest definiert damit ich für den Import eine schöne Drop-Downliste
über das Menü anbieten kann (habe bei Dan's Modul gespickelt ;) ).
Weiterhin werden im Drop-Down Menü nur die zu dem DbLog-Device gehörigen Exportfiles absteigend sortiert angezeigt falls man mehrere DbLog-Devices hat.
Ist das Attr expimpdir nicht gesetzt, wird automatisch {global}{modpath}/log/ benutzt, d.h. die Exportfiles landen im
Logverzeichnis.
Mit dem Attr expimpdir kann man einen (kompletten) Pfad angeben in welchen die Files geschrieben werden sollen.
* exportCache kann mit den Optionen nopurge bzw. purgeCache aufgerufen werden. Im letzteren Fall wird der Cache nach dem
Export geleert ohne in die DB zu schreiben.
* die Log-Fehlerausgaben sind erweitert sofern man PK benutzt (nur zur Userinfo warum z.B. Fehler beim Insert auftreten)
* alle cache relevanten set-Befehle (listcache usw.) werden nur noch im Menü angezeigt wenn asynch-Mode benutzt wird
da sie ja sonst obsolet sind
* kleinere Fixes (z.B. timeout 1800s in Doku)
Mit dem exportCache könnten sich interessante Einsatzmöglichkeiten ergeben. So könnte man beipielsweise mit einem AT den
Füllstand von CacheUsage abfragen und wenn dieser Wert über dem eingestellten cacheLimit (attr) ist, stimmt irgendwas nicht
man könnte dann den Cache wegschreiben. Durch den Timestamp im Dateinamen kann der Cache regelmäßig weggeschrieben werden. da jeder Schreibvorgang ein neues eindeutiges File generiert.
Die Commandref ergänze ich erst später wenn ihr bei euch auch getestet habt.
Viel Spaß dabei und einen schönen Sonntag.
@Holger, don't worry , dafür gibt's ja den Thread :)
VG
Heiko
@Heiko: Vielen Dank, dass Du das schlechte Wetter für das Modul genutzt hast...
Habe die neuen Funktionen getestet und bisher keine unerwarteten Dinge festgestellt!!
In der Tat gibt uns das viele neue Möglichkeiten, ich frage mich gerade ob man dadurch das Fallback nach SqLite, das mal angedacht war, noch benötigt....
Ich denke, dass damit eigentlich der Sinn davon jetzt schon erledigt ist...
Dblog : die Spaltenlängen zwischen SQLite und MySQL sind unterschiedlich bzw. werden unterschiedlich verwendet.
Ich habe unter SQLite eine DB angelegt mit folgenden Parametern:
CREATE TABLE 'history' (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(64), UNIT varchar(32));
CREATE TABLE 'current' (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(64), UNIT varchar(32));
Definiere ich die Tabelle dann in FHEM, erhalte ich in den Internals
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
d.h. wundersamer Weise haben sich die Spaltenlängen bei Device, Type, Reading und Value verdoppelt.
Aufgefallen ist mir das, da ich parallel auch mit MySQL teste. Dort habe ich die Datenbank mit den gleichen Längenangaben angelegt. Und dann festgestellt, dass Readings nach 32 Zeichen abgeschnitten werden, obwohl auch hier lt. den Internals die Werte verdoppelt sind.
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
Unter SQLite sind Readings > 32 Zeichen vorhanden und auch auswertbar, bei MySQL sind sie abgeschnitten (und damit nicht nutzbar).
Schaue ich auf die DB mit ,,.schema", sehe ich sie so, wie ich sie oben definiert habe.
Unter SQLite funktioniert folgender select:
select * from history where DEVICE='myElectricityCalculator' AND READING='strombezug_electricityConsumed_kWh_EnergyDay';
Unter MySQL nicht. Der Readingname ist zu lang. Erst wenn ich ihn auf 32 Zeichen kürze ('strombezug_electricityConsumed_k), erhalte ich eine Ausgabe (nur nicht die gewünschte).
Verwirrend.
Wie geht ihr mit dem Problem um? Einfach die MySQL-DB mit größeren Werten anlegen?
LG
Holger
Zitat von: DS_Starter am 19 März 2017, 10:39:39
Mit dem exportCache könnten sich interessante Einsatzmöglichkeiten ergeben. So könnte man beipielsweise mit einem AT den
Füllstand von CacheUsage abfragen und wenn dieser Wert über dem eingestellten cacheLimit (attr) ist, stimmt irgendwas nicht
man könnte dann den Cache wegschreiben. Durch den Timestamp im Dateinamen kann der Cache regelmäßig weggeschrieben werden. da jeder Schreibvorgang ein neues eindeutiges File generiert.
Ich habe dies mal getestet und mit diesem Beispiel scheint das bisher sehr gut zu funktionieren.
define di_sqlWatchdog DOIF ([sql:NextSync] && [?sql:CacheUsage]>1000 && [?sql:sql_processing_time:sec]>3000 && [?sql:state] !~/closed for/)\
((msg Achtung, SQL-Fehler $SELF))\
(set sql exportCache purgecache)
Gleichzeitig lasse ich mir über "msg" eine Nachricht auf das Handy schicken um mich zu informieren, dass die SQL-Datenbank im Moment nicht funktioniert.
Edit1: @Heiko: Schön wäre es noch, wenn ich für das Erstellen eines Exportfiles ein Reading nutzen könnte. Dann wüßte ich mit Sicherheit, wann das letzte Exportfile entstanden ist und ob Handlungsbedarf für mich besteht.
Hallo Holger,
Zitat
Definiere ich die Tabelle dann in FHEM, erhalte ich in den Internals
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
d.h. wundersamer Weise haben sich die Spaltenlängen bei Device, Type, Reading und Value verdoppelt.
nein, die Werte haben sich nicht verdoppelt. Der Zusammenhang ist etwas anders.
Seit einiger Zeit (letztes Jahr) ist die Standardlänge der Felder "Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32".
Das ist auch so in dem contrib-Verzeichnis hinterlegt.
DbLog zeigt in den Internals an, mit welchen Feldlängen DbLog zur Zeit arbeitet. Sind Events etc. länger, werden sie auf die angegebenen Längen gekürzt. Du solltest also beim create die Tabellen mindestens mit den Feldlängen wie im Standard angegeben anlegen.
Im DbLog hast du mit Attributen auch die Möglichkeit die Feldlängen mit denen das Modul operiert, zu ändern. Du kannst z.B. event auf "0" setzen, dann wird de facto diese Spalte nicht mehr in die DB geschrieben.
Die andere Sache ...
Zitat
Unter SQLite sind Readings > 32 Zeichen vorhanden und auch auswertbar, bei MySQL sind sie abgeschnitten (und damit nicht nutzbar).
Schaue ich auf die DB mit ,,.schema", sehe ich sie so, wie ich sie oben definiert habe.
hat etwas mit den Eigenheiten der DB-Typen zu tun. SQLite speichert trotz der Create-Spaltenbreiten Werte auch dann wenn sie länger sind (sofern sie nicht vom Modul beschnitten werden). MySQL tut das nicht. Ist ein Wert länger als die Feldlänge wid er abgeschnitten und ggf. führt das auch zu entsprechenden Fehlermeldungen. Ich glaube auch dass das diesbezügliche Verhalten durch Parametrisierung in MySQL verändert werden kann.
Ich würde es so machen .... die Feldlängen in MySQL mindestens so wie Standard (siehe oben) oder größer wie du sie brauchst. In dem Fall dann auch die Attribute in DbLog setzen damit das Modul nicht von sich aus beim Standard abschneidet.
Grüße
Heiko
Hallo Joe,
Zitat
Edit1: @Heiko: Schön wäre es noch, wenn ich für das Erstellen eines Exportfiles ein Reading nutzen könnte. Dann wüßte ich mit Sicherheit, wann das letzte Exportfile entstanden ist und ob Handlungsbedarf für mich besteht.
Woran hast du dabei gedacht ?
D.h. wie sollte das Reading deiner Meinung nach gestaltet sein ?
Grüße
Heiko
Hallo Heiko,
Zitat von: DS_Starter am 23 März 2017, 00:59:55
Woran hast du dabei gedacht ?
D.h. wie sollte das Reading deiner Meinung nach gestaltet sein ?
In der Art:
lastLog = cache_sql_2017-03-19_14-01-50Damit wäre alles, was ich in diesem Zusammenhang bräuchte, erschlagen. Weitere Informationen wie den Modus (nopurge, purgecache) benötige ich nicht.
Ob dies für andere Einsatzzwecke wichtig ist, kann ich im Moment nicht beurteilen...
Den Zeitstempel des Readings kann ich für die Benachrichtigungen nutzen, somit wäre meine Benachrichtigungsfunktion damit möglich.
GGf. sollte dort auch ein Fehler angezeigt werden, wenn das schreiben nicht funktioniert hat.
sG
Joe
Hallo Heiko,
danke für deine ausführlichen Erläuterungen.
Wenn ich das richtig interpretiere, wird contrib beim Update nicht aktualisiert. Meine db_create_mysql.sql ist vom 09.11.2014 – und noch mit den geringeren Feldlängen. Ebenso im Wiki, an dass ich mich auch gehalten hatte. Für viele Anfänger sehe ich da eine potenzielle Fehlerquelle. Kein Vorwurf!
Mittlerweile habe ich die DB mit den größeren Feldlängen neu angelegt. Wenn ich das richtig verstehe, brauche ich mich dann um die Attribute col.* nicht zu kümmern.
Danke noch mal
Holger
Hallo zusammen,
anbei wieder eine weiterentwickelte Version 2.14.2 mit folgenden Ergänzungen:
* neues Reading "lastCachefile".
Es wird das letzte exportierte bzw. importierte Cachefile mit einem Status angedruckt.
* Wurde ein Cachefile erfolgreich in die DB importiert, wird es mit einem Präfix "impdone_" versehen und erscheint dann nicht mehr in der Drop-Down-Liste der möglichen Importfiles
Gerne wieder Feedback nach euren Tests ...
@Holger, im Wiki habe ich die Feldlängen aktualisiert. Müssen wir sowieso noch einiges ergänzen was die neuen Funktionen von DbLog betrifft. Vllt mag da einer mitwirken ?!
viele Grüße
Heiko
Hallo miteinander,
anbei die Version 2.14.3.
Es ist die commandref um die neuen Funktionen ergänzt aber auch die Get-Funktion bezüglich DB-Handle Verwendung etwas umgebaut.
Ich habe die berechtigte Hoffnung damit nun ein Problem behoben zu haben, dass mit plotfork=1 unter der Voraussetzung dass
mehrere Plots in einem Raum vorhanden sind und man SQLite einsetzt, Plots u.U. alternierend nicht vollständig bzw. abgeschnitten dargestellt werden.
Ich hatte viele Versuche gemacht und ausschließlich bei SQLite dieses Verhalten registriert und auch nicht generell, sondern nur dann wenn eine größere
(unbestimmte) Anzahl SQLite-Plots im Raum vorhanden ist.
Bitte testet diese Version bei euch, insbesondere wenn ihr dieses beschriebene Problem mit SQLite/plotfork=1 habt.
Achtet natürlich darauf dass alles andere nach wie vor funktioniert wie gewohnt.
Diese Version habe ich für den Check-In vorgesehen.
FHEM-Restart ist erforderlich !
Grüße
Heiko
Bei einer Umstellung aktuell ist noch ein Wunsch aufgekommen:
Schön wäre es, wenn man bei excludeDevs auch <devspec> angeben könnte, dessen Device dann mittels devspec ermittelt wird. (Siehe auch commandfref unter "Device specification (devspec)").
Grund: Ich würde gerne sämtliche roommates von einem Logging ausschließen, leider werden diese bei mir dynamisch erzeugt und haben manchmal unterschiedliche Namensformate.
Mit einem
list TYPE=ROOMMATE
kann ich diese alle ermitteln, per
set TYPE=ROOMMATE disable 1
kann ich beispielsweise alle disablen oder analog dazu auch löschen.
Da devspec eine fhem-typische Funktion ist, denke ich, wäre es gut dies hier auch zu unterstützen.
Zusätzlich wäre es noch schön, wenn Multiline ebenfalls als Trenner für excludeDevs genutzt werden kann.
So hat es Rudi beim Dummy eingebaut
https://svn.fhem.de/trac/changeset?reponame=&new=12700%40trunk%2Ffhem%2FFHEM%2F98_dummy.pm&old=12688%40trunk%2Ffhem%2FFHEM%2F98_dummy.pm
und so wurde es auch beim DOIF übernommen:
https://svn.fhem.de/trac/changeset?reponame=&new=12703%40trunk%2Ffhem%2FFHEM%2F98_DOIF.pm&old=12691%40trunk%2Ffhem%2FFHEM%2F98_DOIF.pm
Hallo miteinander, hallo Joe,
habe die angehängte Version 2.14.4 gebaut.
Änderungen:
* Im Asynch-Mode habe ich den Pre-Connection check in der Funktion DbLog_execmemcache entfernt.
Das geht auf zurück auf https://forum.fhem.de/index.php/topic,69702.0.html und hat nach meinen Tests nach auch keine negativen Seiteneffekte
* das Attribut excludeDevs kann nun als Geräte-Spezifikation (devspec) angegeben werden. Z.B. so: global,Log.*,Cam.*,TYPE=DbLog
Gibt es denn schon Testergebnisse zur 2.14.3, alles ok ?
Grüße
Heiko
Hallo Heiko,
ich habe derzeit 2.14.0 in Betrieb, ohne Auffälligkeiten.
Gruß
Michael
EDIT: Habe nun 2.1.4.4 aktiviert. Sieht erstmal gut aus.
Zitat von: DS_Starter am 29 März 2017, 00:16:29
* Im Asynch-Mode habe ich den Pre-Connection check in der Funktion DbLog_execmemcache entfernt.
* das Attribut excludeDevs kann nun als Geräte-Spezifikation (devspec) angegeben werden. Z.B. so: global,Log.*,Cam.*,TYPE=DbLog
Hallo Heiko,
danke für das Update.
Da ich am Test-FHEM zum Connect SOCKS verwende, gehe ich davon aus, dass es mich nicht betrifft. Habe die Version jedenfalls aktiviert und funktioniert bisher
problemlos!
Danke für die devspec-Ergänzung... das werde ich exzessiv nutzen!
schöne Grüße Joe.
Hallo Heiko,
mit der Version 2.14.3 sind die sporadischen Plot-Fehler in Verbindung mit SQLite bei mir nicht mehr aufgetreten.
Danke und Daumen hoch.
vg Jens
Hallo @all,
danke für die Rückmeldungen !
Auch bei mir sind diese Plot-Fehler in Verbindung mit SQLite nicht mehr aufgetreten. Habe viel kreuz und quer getestet.
Dann werde ich die Version 2.14.4 dann mal einchecken....
viele Grüße
Heiko
Ich habe auch excludeDevs weiter getestet, auch die Mehrzeilen-Variante: Funktioniert ohne Auffälligkeiten!
Danke für die neue Version und fürs einchecken!
Ich habe bei Readings festgestellt, dass sie, sofern wie im Sommer mit 0 gefüllt, meine Datenbank spammen.
Bei einer Recherche habe ich diesen Thread gefunden, der leider auch keine Lösung enthält.
https://forum.fhem.de/index.php/topic,63731.0.html
In readingsProxy wurde dieser Fehler gerade mit diesem Changeset korrigiert:
https://svn.fhem.de/trac/changeset?old_path=%2F&old=13861&new_path=%2F&new=13861
Nun suche ich nach einer Lösung für dbLog: Wäre es nicht einfach die Lösung,
Zeile 1090 zu entfernen? Dadurch wird der Wert nicht gesetzt und die nächste Vergleichsprüfung
$lv = "" if(!$lv);
in Zeile 1092 sollte erfolgreich sein... oder übersehe ich hier etwas?
Edit1: In fhem.pl finde ich diese Prüfung für "event-min-interval" auch nicht....
Anbei ein Patch um ein Attribut valueFn hinzuzufügen.
Beispiel für valueFn
{
if ($DEVICE eq "dummy3"){
$UNIT="°C ";;
$VALUE= $VALUE/10 ;;
}
}
Hier wird beim dummy3 das Unit korrekt gesetzt.
Patch
*** C:/Users/Privat/93_DbLog.pm Sat Apr 01 15:35:58 2017
--- C:/Users/Privat/93_DbLogMINE.pm Sat Apr 01 17:30:24 2017
***************
*** 153,158 ****
--- 153,159 ----
"showNotifyTime:1,0 ".
"timeout " .
"DbLogSelectionMode:Exclude,Include,Exclude/Include ".
+ "valueFn:textField-long ".
$readingFnAttributes;
# Das Attribut DbLogSelectionMode legt fest, wie die Device-Spezifischen Atrribute
***************
*** 1026,1031 ****
--- 1027,1040 ----
#one Transaction
eval {
+ my $value_fn = AttrVal( $name, "valueFn", "" );
+ if( $value_fn =~ m/^\s*(\{.*\})\s*$/s ) {
+ $value_fn=$1;
+ }
+ else{
+ $value_fn='';
+ }
+
for (my $i = 0; $i < $max; $i++) {
my $event = $dev_hash->{CHANGED}[$i];
Log3 $name, 4, "DbLog $name -> check Device: $dev_name , Event: $event" if($vb4show);
***************
*** 1106,1111 ****
--- 1115,1144 ----
my $colevent = AttrVal($name, 'colEvent', undef);
my $colreading = AttrVal($name, 'colReading', undef);
my $colvalue = AttrVal($name, 'colValue', undef);
+
+ ##ValueFB
+ if( $value_fn ne '' ) {
+ my $TIMESTAMP = $timestamp;
+ my $DEVICE = $dev_name;
+ my $DEVICETYPE = $dev_type;
+ my $EVENT = $event;
+ my $READING = $reading;
+ my $VALUE = $value;
+ my $UNIT = $unit;
+ ##Todo: EVAL-Fehlermeldung in Reading (oder state) schreiben
+ my $value_fn = eval $value_fn;
+ Log3 $name, 3, $name .": valueFn: ". $@ if($@);
+
+ $timestamp= $TIMESTAMP if( $TIMESTAMP ne '' );
+ $dev_name = $DEVICE if( $DEVICE ne '' );
+ $dev_type = $DEVICETYPE if( $DEVICETYPE ne '' );
+ $event = $EVENT if( $EVENT ne '' );
+ $reading = $READING if( $READING ne '' );
+ $value = $VALUE if( $VALUE ne '' );
+ $unit = $UNIT if( $UNIT ne '' );
+
+ }
+
if ($hash->{DBMODEL} ne 'SQLITE' || defined($colevent) || defined($colreading) || defined($colvalue) ) {
# Daten auf maximale Länge beschneiden
$dev_name = substr($dev_name,0, $hash->{HELPER}{DEVICECOL});
***************
*** 1115,1121 ****
$value = substr($value,0, $hash->{HELPER}{VALUECOL});
$unit = substr($unit,0, $hash->{HELPER}{UNITCOL});
}
!
my $row = ($timestamp."|".$dev_name."|".$dev_type."|".$event."|".$reading."|".$value."|".$unit);
Log3 $hash->{NAME}, 4, "DbLog $name -> added event - Timestamp: $timestamp, Device: $dev_name, Type: $dev_type, Event: $event, Reading: $reading, Value: $value, Unit: $unit"
if($vb4show);
--- 1148,1154 ----
$value = substr($value,0, $hash->{HELPER}{VALUECOL});
$unit = substr($unit,0, $hash->{HELPER}{UNITCOL});
}
!
my $row = ($timestamp."|".$dev_name."|".$dev_type."|".$event."|".$reading."|".$value."|".$unit);
Log3 $hash->{NAME}, 4, "DbLog $name -> added event - Timestamp: $timestamp, Device: $dev_name, Type: $dev_type, Event: $event, Reading: $reading, Value: $value, Unit: $unit"
if($vb4show);
@Heiko: Als Vorlage habe ich dazu readingProxy und readingsGroup genutzt. Die Doku denke ich kann man auch von dort leicht angepasst übernehmen. Eventuell könnte man noch ein Beispiel für aktuell bekannte und nicht funktionierende Devices angeben. Beispiel yowsupp. Kann man das so in der Art übernehmen?
Zitat von: JoeALLb am 01 April 2017, 15:09:57
Nun suche ich nach einer Lösung für dbLog: Wäre es nicht einfach die Lösung,
Zeile 1090 zu entfernen? Dadurch wird der Wert nicht gesetzt und die nächste Vergleichsprüfung
$lv = "" if(!$lv);
in Zeile 1092 sollte erfolgreich sein... oder übersehe ich hier etwas?
Sollte das nicht nach
$lv = "" if(!defined($lv));geändert werden.
Edith: Eventuell auch bei include.
Hallo Joe & stromer-12,
danke für euren Input. Ich werde mal eine Testversion bauen.
Bezüglich der Zeile
$lv = "" if(!$lv);
bin ich der Meinung dass auch
$lv = "" if(!defined($lv));
nicht zu dem gewünschten Ziel führt. Aber wir können es probieren ... ich baue es mal ein und wir sehen und das Ergebnis an.
Im Normalfall arbeitet DbLog mit DbLogSelectionMode=Exclude, d.h. es wird alles geloggt was mit dem Regex von DEF matcht wenn man in dem Quelldevice nicht explizit DbLogExclude gesetzt hat.
Das bedeutet auch, dass im Normalfall nicht in den If-Zweig (Zeile 1052) gegangen wird in dem die Zuweisung "$lv = "" if(!$lv);" stattfindet.
Habt ihr denn DbLogExclude gesetzt ? Und wenn ja ... verwendet ihr dabei ebenfalls die MinInterval-Angabe ?
Ich muß das auch mal ausprobieren. Brauche ich normal nicht.
Grüße
Heiko
Hallo Heiko,
ich nutze das immer öfter.
Bisher nutzte ich oft "event-on uptate" und ggf. "event-min-interval"um zu häufige events nicht zu loggen.
Jetzt werden aber immer häufiger Devices miteinander verknüpft (telegramBot mit postMe, telegramBot mit TALKTOME, etc...).
Diese reagieren oft allergisch auf fehlende Events... daher muss ich dies öfter auf DbLogExclude mit angegebenem miInterval anpassen.
Ich verhindere damit, zu seltenes und auch zu häufiges Loggen von gleichen Werten, im Sommer ist das die 0 für off bei der Heizung.
2 Einträge pro Tag hätte ich jedoch trotztdem gerne, damit Plots dargestellt werden können...
wenn es die addLog-Routine für DbLog gibt, und ich damit um Mitternacht nötige Zusatzlogeinträge generiere, möchte ich diese minInterval-Zeiteinheiten rücksetzen können... aber das ist wohl de rnächste Schritt.
Ich habe meinen Patch oben jetzt seit ein paar Stunden im Einsatz, und hoffe nichts vergessen zu haben. Probleme kann ich jedoch aktuell nicht feststellen...
Ich stelle mir nur die Frage, ob man der Konsistenz halber auch hier die Verarbeitungszeit mitloggen sollte? Jedoch vergeht diese bei mir immer noch recht schnell!
Ich denke schon, dass uns
$lv = "" if(!defined($lv));
helfen wird... nächste Woche werde ich mich intensiv am Testen beteiligen können!
Noch etwas, was mit beim Zusammensuchen des Codes hier aufgefallen ist:
Sollten diese beiden Zeilen (gemeint sind die die SQL-Befehle)
# insert current mit/ohne primary key, insert-values für current werden generiert
if ($usepkc && $hash->{DBMODEL} eq 'MYSQL') {
eval { $sth_ic = $dbh->prepare("INSERT IGNORE INTO current (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"); };
und
if ($usepkc && $hash->{DBMODEL} eq 'MYSQL') {
# update current (mit PK), insert-values für current wird generiert
$sth_uc = $dbh->prepare("REPLACE INTO current (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)");
nicht duch einen einzigen in der Form von
INSERT INTO current (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)")
ON DUPLICATE KEY UPDATE VALUE=VALUES(VALUE), timestamp=VALUES(timestamp);
Durch "ON DUPLICATE KEY UPDATE" wird das Update gleich im selben Durchgang gemacht und eine zweite Kontaktaufnahme mit dem Server wird nicht notwendig...
Ich habe es aber nicht konkret getestet, wollte vorher eure Meinung hören.
schöne Grüße
Joe
Hallo zusammen,
so ... habe eine Testversion erstellt mit den folgenden Ergänzungen
* in dem Exclude / Include-Zweig auf "$lv = "" if(!defined($lv));" umgestellt wie von stromer-12 vorgeschlagen
* neues Attribut "valueFn"
Für das Attribut valueFn habe ich noch den perlSyntaxCheck eingebaut. Dadurch wird gleich bei der Erstellung der Funktion die Validität geprüft.
Innerhalb der valueFn hat man Zugriff auf alle Log-Werte über die Variablen $TIMESTAMP, $DEVICE, $DEVICETYPE, $EVENT, $READING, $VALUE, $UNIT.
Verändern kann man auch alle außer $TIMESTAMP und $EVENT.
Ich halte es für gut wenn der Nutzer den gelieferten $TIMESTAMP nicht verändern kann um möglichen Fehlern durch die Veränderung vorzubeugen. Und $EVENT bleibt zum Vergleich somit immer unverändert.
@Joe ... die Verarbeitungszeit der DbLog-Schleife kann man bisher bereits mit dem Attribut showNotifyTime einschalten.
Die Zusammenfassung der DB-Befehle kann ich nochmal testen wenn ich wieder Zeit habe. Aber wenn mich nicht alles täuscht hatte ich das schon mal so versucht. Kann aber auch etwas anderes gewesen sein ... vermag mich bei den ganzen Änderungen nicht mehr so recht erinnern.
Dann testet es mal und ich bin gespannt auf eure Ergebnisse. (Commandref kommt später)
EDIT: Habe noch den Wunsch von Andreas https://forum.fhem.de/index.php/topic,69781.msg614746.html#new eingebaut
viele Grüße
Heiko
Hallo zusammen, Hallo Heiko,
danke für die neue Version...
bezüglich den unveränderbaren Timestamps: genau diese Funktion nutze ich aktuell um um Mitternacht Logeinträge zu schreiben...
Da um Mitternacht viel zu tun ist, wird das Notify manchmal erst um 00:00:01 tatsächlich gespeichert, was dann zu Plot-Abbrüchen kommt.
In diesem Fall habe ich das Timestamp auf 00:00:00 umgeschrieben.
Da dies aber nur eine Übergangslösung für mich war, werde ich mir wohl bald auch das addLog ansehen, vielleicht komme ich da einen Schritt weiter...
Anbei ein Vorschlag für Commandref, kann gerne ergänzt oder verändert werden.
Ich arbeite auch noch an anderen Beispielen, vielleicht habe ich morgen noch mehr.
valueFn
perl expresion that can use and change values for $DEVICE $DEVICETYPE, $READING, $VALUE and $UNIT.
It also has readonly-access to $TIMESTAMP and $EVENT.
Example: (change off to 0, round e-power to 1f)
attr sqlLogDevice valueFn {if ($DEVICE eq "living_Clima" && $VALUE eq "off" ){$VALUE=0;} elsif ($DEVICE eq "e-power"){$VALUE= sprintf "%.1f", $VALUE;;}}
Zitatbezüglich den unveränderbaren Timestamps: genau diese Funktion nutze ich aktuell um um Mitternacht Logeinträge zu schreiben...
uups ... sorry ;) ... kannst dir die Zeile 1154 einfach entkommentieren.
my $res = eval $value_fn;
Log3 $name, 2, "DbLog $name -> error valueFn: ".$@ if($@);
---> # $timestamp= $TIMESTAMP if($TIMESTAMP ne '');
$dev_name = $DEVICE if($DEVICE ne '');
$dev_type = $DEVICETYPE if($DEVICETYPE ne '');
# $event = $EVENT if($EVENT ne '');
Danke für den Commandref-Vorschlag. Morgen habe ich sicherlich wieder etwas mehr Zeit und kann mir auch mal die Sache mit dem addlog anschauen und evtl. einbauen.
Grüße
Heiko
Hallo Heiko,
Zitat von: DS_Starter am 02 April 2017, 14:33:22
uups ... sorry ;) ... kannst dir die Zeile 1154 einfach entkommentieren.
Danke, das hatte ich gefunden :D.
Noch etwas ist mir brim Einsatz eingefallen: Ich möchte gewisse Werte(state) NICHT loggen. fileLog loggt diese nicht, DbLog manchmal schon.Manchmal nimmt DbLog bei unbekannten Devices auch einfach an, es könnte sich um STATE handeln. Schön wäre also noch (als Wunsch), wenn ich $VALUE auf undef setze, dass dann dieser Logeintrag komplett ignoriert wird.
Hast Du dazu eine Idee? Eigentlich müsste man nur die FOR-Schleife aus 1060 verlassen, oder?
schöne Grüße
Joe
ZitatHast Du dazu eine Idee? Eigentlich müsste man nur die FOR-Schleife aus 1060 verlassen, oder?
So einfach nicht. Es wird immer ein ganzer Block von Events die ein Device liefert (bzw. die Funktion deviceEvents) abgearbeitet und mittels array-insert in die DB geschrieben. Da müssen wir uns ein bisschen was ausdenken .... aber heute nicht mehr, muß los ...
Bis später,
Heiko
Mein Skiurlaub ist – leider – vorbei.
Dafür komme ich jetzt aber auch wieder zum Testen. Auch ich hatte ja Fehler bei plotfork=1 gemeldet und kann nun – wie ja andere auch schon – bestätigen, dass diese Fehler mit der Version 2.14.4 weg sind. Super!
Und danke
Holger
Hi Joe, @all,
es ist mir über Nacht eine Idee gekommen wie man einen Logeinrag ignorieren kann.
Für die valueFn habe ich noch eine setzbare Variable $IGNORE eingeführt. Wenn man in der Funktion diese Variable setzt wird der Datensatz, auf den diese Logik zutrifft, nicht geloggt.
Also zum Beispiel um Reading state von Device SMA_Energymeter nicht zu loggen:
{
if ($DEVICE eq "SMA_Energymeter" && $READING eq "state"){
$IGNORE=1;
}
}
Hier die neue Testversion ....
Grüße
Heiko
Hallo Heiko,
Zitat von: DS_Starter am 03 April 2017, 08:34:40
$IGNORE=1;
Hier die neue Testversion ....
sehr cool, danke! Ich habe einen Stromzähler, der bei Funkproblemen "-1" sendet.., was mir jegliche Plots "versaut", denn die Summe beim nächsten
funktionierenden Funkkontakt stimmt trotzdem. Dafür kann ich das auch gleich nutzen! :D
Hallo Heiko,
vielen Dank für deine Änderung für ZWAVE-Module. Jetzt wird Value und Unit richtig gespeichert.
Den anderen Thread schließe ich.
Gruß
Andreas
Hallo miteinander,
in der angehängten Version 2.16.0 gibt es einen neuen set-Befehl "set addLog".
Über dieses Kommando kann man z.B. per At zu einem bestimmten Zeitpunkt ein Reading eines Quelldevices in die
DB loggen lassen. Die valueFn wirkt dabei ebenfalls. Unterschied zum addlog im Wiki ist, dass nicht mit trigger gearbeitet wird
und damit keine zusätzlichen Events erzeugt werden.
Aufrufsyntax ist:
set <DbLog-Device> addLog <Devspec>,<Reading>,<[Unit]>
Also zum Beispiel:
set LogDB addLog SMA_Energymeter,Bezug_Wirkleistung,W
Die Angabe der Einheit als letzter Parameter ist optional. Das Device kann wieder als Devspec angegeben werden.
D.h. mit:
set LogDB addLog TYPE=IT,state
bekäme man für alle IT-Devices den state geloggt. Dabei wird TYPE und EVENT fix auf "addlog" gesetzt. Damit erkennt man in der DB auch leicht den Ursprung.
Ein AT könnte so aussehen:
defmod at.addlog.1 at *23:59:59 set LogDB addLog SMA_Energymeter,Bezug_Wirkleistung,W
attr at.addlog.1 room DbLog
Die Commandref für die valueFn hab ich hier bereits eingearbeitet.
Frage .... gibt es schon Erkenntnisse ob die Änderung "$lv = "" if(!defined($lv));" in DbLogExclude / DbLogInclude irgendetwas gebracht hat ?
Viel Spaß beim Testen und natürlich gerne wieder Feedback.
Danke für eure bisherigen Rückmeldungen !
Grüße
Heiko
Hallo Heiko,
vielen Dank! Ich habe versucht es ausgiebig zu testen, was mir aufgefallen ist ist:
1: Wenn ich addLog oder commitCache absetze, bekomme ich im FHEM häufig die Meldung "Connection lost retrying after 5 sek". Ich habe auf diesem Gerät longpoll auf websocket gestellt. Negativen Effekt bis auf den Optischen hat es jedoch vermutlich keinen.
2: excludeDevs
attr sql widgetOverride excludeDevs:textField-long
attr sql excludeDevs global\
TYPE=SONOSPLAYER\
TYPE=SONOS\
TYPE=DOIF
funktioniert bei mir nicht. (Achtung, die \ encoden nur den Zeilenwechsel in der fhem.cfg, in der Oberfläche werden diese nicht angezeigt.) "DOIFS" werden weiterhin geloggt. Ohne Zeilenwechsel mit , als Trenner funktioniert es. Zeile 1030 dürfte hier nicht greifen...
3: kleiner Hinweis zur Beschreibung: TYPE und EVENT werden auf "addLog", nicht "addlog" gesetzt. Ist auch stimmiger so!
4: Thema Timestamp: Leider schaffe ich es nicht, den Timestamp veränderbar zu machen. Ich habe dazu
$timestamp = $TIMESTAMP if($TIMESTAMP ne '');
in Zeile 1162 eingefügt, ohne Erfolg. @Heiko, hast Du dazu eine Idee? Glaubst du wirklich, dass dies auf readonly gesetzt werden sollte? Eigentlich sehe ich da kein Risiko....
5: listCache ist nicht nummerisch sortiet. Die Daten werden als
1
10
100
angezeigt.
6: Ich hätte einen Einsatzbereich, wo addLog auch mit einem konkreten Wert, in meinem Fall der 0 geschrieben werden sollte. Dies Ist für mich persönlich aber nicht überaus wichtig, und muss jetzt nicht direkt mit entwickelt werden.
In dem Fall wird der aktuelle Stromverbrauch regelmäßig geloggt. Wenn ich also um 23:58 100W Strom verbrauche, sollte ich das um 00:00 nicht nochmals auf 100W setzen, sondern auf 0. um 00:02 wird dann wieder der aktelle und korrekte Verbrauch geloggt. Ohne die 0 um Mitternacht würde ich den Stromverbrauch fälschlicherweise um 100W erhöhen, er wäre also höher als das Reading "Tagesverbrauch".
Ich denke,
set <DbLog-Device> addLog <Devspec>,<Reading>,<[Unit]>,<[Value]>
wäre auch möglich, mit ",," könnte man die Units ja auch leer lassen.
Vielen Dank für die neue Version!!!
schöne Grüße
Joe
Hi Joe,
Zu 1:
Den Effekt habe ich auch bei mir, aber unabhängig von DbLog, generell. Deswegen benutze ich noch das longpoll=1.
Habe allerdings im Forum nicht nach Lösungsansätzen gesucht ... immer was anderes was vorgeht.
Zu2:
Hast du es mal so versucht:
attr sql widgetOverride excludeDevs:textField-long
attr sql excludeDevs global\
TYPE=SONOSPLAYER,\
TYPE=SONOS,\
TYPE=DOIF
Zu 4: muss ich mir im Code anschauen wenn ich wieder zu Hause bin.
Zu5:
Das ist doch numerisch sortiert 😉
Aber ich weiss was du sagen willst. Geht IMHO mit führenden Nullen zu verbessern, aber den Aufwand will ich nicht treiben.
Zu 6:
Muss die addLog Funktion wahrscheinlich nochmal ändern. Das mit unit ist unschön gelöst weil eine evtl vorhandene DbLog_splitFn nicht berücksichtigt wird. Das mach ich anders und kann die Sache von dir dann mit vorsehen.
Grüße
Heiko
Zitat von: DS_Starter am 04 April 2017, 12:45:04
Zu2:
Hast du es mal so versucht:
Ja, selbes Ergebnis.
Mit folgendem Patch funktioniert es bei mir. (habe sicherheitshalber vor und nach dem \n noch Leerzeichen erlaubt, kann aber weggelassen werden)
--- C:/Users///93_DbLog_V2.16.0.pm Tue Apr 04 10:43:22 2017
+++ C:/Users///93_DbLog_V2.16.1.pm Tue Apr 04 13:25:38 2017
@@ -1026,8 +1026,9 @@
# Devices ausschließen durch Attribut "excludeDevs" (nur wenn kein $hash->{NOTIFYDEV} oder $hash->{NOTIFYDEV} = .*)
if(!$hash->{NOTIFYDEV} || $hash->{NOTIFYDEV} eq ".*") {
- my @exdvs = devspec2array(AttrVal($name, "excludeDevs", ""));
- for(@exdvs){s/\n/,/g}
+ my $attrExc = AttrVal($name, "excludeDevs", "");
+ $attrExc =~ s/\s*\n\s*/,/g;
+ my @exdvs = devspec2array($attrExc);
if(@exdvs) {
# Log3 $name, 4, "DbLog $name -> excludeDevs: @exdvs";
foreach (@exdvs) {
Zitat von: DS_Starter am 04 April 2017, 12:45:04
Zu5:
Das ist doch numerisch sortiert
Aber ich weiss was du sagen willst. Geht IMHO mit führenden Nullen zu verbessern, aber den Aufwand will ich nicht treiben.
Sicher? Ich hatte es so im Kopf ...
Nummerisch wäre 8,9,10,11; Alphabetisch wäre 1,10,2,20,3,4,A,B,a,b; , Alphanumerisch wäre 1,2,3,4,10,20,A,a,B,b; Wie auch immer... ich dachte dass der memCache direkt eine Sortierung (nach Einfügereihenfolge) hat, dies lediglich aus irgendeinem Grund vor der Ausgabe nochmal umsortiert wird. So wichtig ist das tatsächlich nicht, hatte mich nur beim Debuggen verwirrt, da ich dachte, mir fehlen Einträge.
Nee, nicht sicher. Der memCache hat auch eine direkt aufsteigende Reihenfolge. Das ist eine Anzeigesache. Damit habe ich schonmal gekämpft. Normal kann man mit
sort {$a <=>$b} keys (%hash)
numerisch sortieren. Hatte aber für die Anzeige nicht geklappt. Aber kann es heute Abend nochmal versuchen.
Danke für den Patch ... prima :) baue ich so ein.
Grüße
Heiko
Nachtrag:
Folgende Fehlermeldung erhalte ich noch in rauhen Mengen;
Die Ursache verstehe ich jedoch nicht, denn $UNIT wird in Zeile 2702 initialisiert...
Use of uninitialized value $UNIT in string ne at ./FHEM/93_DbLog.pm line 2713.
Use of uninitialized value $unit in concatenation (.) or string at ./FHEM/93_DbLog.pm line 2716.
Use of uninitialized value $unit in concatenation (.) or string at ./FHEM/93_DbLog.pm line 2717.
sG
Joe
Hallo Heiko,
ich habe meinen Patch nochmal verkürzt....
1029,1030c1029
< my @exdvs = devspec2array(AttrVal($name, "excludeDevs", ""));
< for(@exdvs){s/\n/,/g}
---
> my @exdvs = devspec2array( AttrVal($name, "excludeDevs", "") =~ s/\s*\n\s*/,/gr );
sG Joe
Nabend Joe, @all,
Zitatich habe meinen Patch nochmal verkürzt....
Ich auch :). Habe allerdings den Modifikator /r nicht verwendet weil er erst ab perl 5.14.0 eingeführt wurde. Nicht dass es dann an dieser Stelle Probleme gibt.
Desweiteren ist die addLog-Funktion umgebaut. Jetzt wird auch die Standard-Splittingfunktion für das Event verwendet in der dann auch DbLog_splitFn durchlaufen wird sofern sie vorhanden ist.
Der Aufruf hat sich dadurch geändert in:
set <device> addLog <devspec>,<Reading>,[Value]
Value ist optional, kann aber gesetzt werden um einen spezifischen Wert zu setzen wenn gewünscht.
In der DB wird nur noch der Feldwert von "Event" auf "addLog" gesetzt. TYPE wird devspec-spezifisch geloggt.
Die Sortierung habe ich sogar auch so wie ich es in #240 schon geschrieben habe verbessern können. Weiß nicht wieso es mir bisher nicht gelungen war.
Bitte wieder die neue Version 2.16.1 testen ...
Grüße
Heiko
Hallo,
ich hänge mich mal mit ran :)
Bevor ich den thread fand, hatte ich schon einen Beitrag gepostet.
Ich habe bei mir den Index erweitert um die Spalte "value".
Sinn des ganzen ist, das zumindest mal die Plot den Timestamp, device, reading und value brauchen.
Die ersten 3 sind im Index. ABer um den Value rauszufinden ist ein Tablejoin nötig. Das kostet Resourcen.
Indem Value im Index ist entfällt dieser Tablejoin und die Plots (gerade mit historischen zb. Jahresdaten) werden wesentlich schneller aufgebaut.
(siehe auch Explain befehl mit und ohne value im Index)
Ein Insert dauert natürlich ein klein bisle länger, da aber nicht 100te Datensätze pro Sekunde in die DB geschrieben werden dürfte das zu vernachlässigen sein.
Und noch ne anmerkung: Es gibt bei Mariadb/Mysql auch ein Replace Into. Ist unter manchen Umständen besser geeignet als ein insert into... on duplikate key
Grüße aus Dinslaken
Icebear
Hallo icebear,
danke für dein Feedback und das Einbringen von Ideen, das ist immer sehr hilfreich!
Hast Du zu diesen Ideen auch nähere Informationen, bzw. hast Du auch Messungen durchgeführt??
Zitat von: Icebear am 05 April 2017, 00:22:33
Ich habe bei mir den Index erweitert um die Spalte "value".
Ich habe Benchmarks mit verschiedenen Datenbank/Indexkonfigurationen durchgeführt, dabei war auch ein "covering index", also indexe in denen der value auch enthalten war.
In Benchmarks hatte dies (nach den anderen Verbesserungen wie DB-Engine wechseln, ...) keinen messbaren Vorteil (mehr), selbst bei komplexen Abfragen die mehrere Minuten rechneten oder bei tausenden Abfragen auf eine kalte bzw. warme Datenbank.
Der Unterschied beim Lesen war nicht messbar, der negative Unterschied beim insert jedoch merkbar. (Die Inserts waren ca. 7% langsamer).
Lt. bisherigen Messungen fallen hier Einflussfaktorie wie Unicode, Tabellentyp (Aria vs. MyISAM vs. innoDB, ...).
Meine aktuell gemessen beste Konfiguration unter MariaDB habe ich in diesem Post:
https://forum.fhem.de/index.php/topic,65860.msg599526.html#msg599526
dokumentiert.
Zitat von: Icebear am 05 April 2017, 00:22:33
Und noch ne anmerkung: Es gibt bei Mariadb/Mysql auch ein Replace Into. Ist unter manchen Umständen besser geeignet als ein insert into... on duplikate key
Aktuell ist Replace into in Verwendung! Dies wird jedoch nur bei der current-Tabelle benötigt und hier ist aktuell zuvor immer eine insert-Prüfung notwendig, um fetszustellen, ob der Datensatz erstmalig eingefügt werden muss.
"into... on duplikate key" fügt diese zwei Schritte zu einem zusammen, und ist somit lt. Messung etwas performanter für diejenigen, die die current-Tabelle noch verwenden.
Solltest Du zu deinen Tests noch weitere Erkenntnisse haben, zögere bitte nicht, diese mit uns hier zu teilen! DbLog wird gerade
stark mordernisiert und aktualisiert und die Möglichkeiten hier begeistern mich sehr!
sG
Joe
Hallo Heiko,
Zitat von: DS_Starter am 04 April 2017, 22:33:47
Ich auch :). Habe allerdings den Modifikator /r nicht verwendet weil er erst ab perl 5.14.0 eingeführt wurde. Nicht dass es dann an dieser Stelle Probleme gibt.
Verstehe und ist gut... aber ich mag /r im Zusammenhang mit regexp und mit diesen kenn ich mich wenigstens ein bisschen mehr aus als mit perl ;-)
Zitat von: DS_Starter am 04 April 2017, 22:33:47
Desweiteren ist die addLog-Funktion umgebaut. Jetzt wird auch die Standard-Splittingfunktion für das Event verwendet in der dann auch DbLog_splitFn durchlaufen wird sofern sie vorhanden ist.
Funktioniert! Hatte dies um Mitternacht schon erfolgreich getestet!
Zitat von: DS_Starter am 04 April 2017, 22:33:47
Die Sortierung habe ich sogar auch so wie ich es in #240 schon geschrieben habe verbessern können. Weiß nicht wieso es mir bisher nicht gelungen war.
Zum debuggen ein netter Zusatz, danke fürs umsetzen! Am Handy im kleinen SSH-Client ist die Sortierung für den Überblick recht wichtig!!
Zitat von: DS_Starter am 04 April 2017, 22:33:47
$lv = "" if(!defined($lv));
Das nutze ich auf einem anderen Gerät das ich im Moment nicht updaten kann (bin nicht vor ort, kein Zugang).
Ich habs jedoch auf meiner Liste für den nächsten Besuch!
Noch eine Frage: Wie sollen wir mit splitFn und Devices zukünftig umgehen?
Sollen wir für Devices, die bisher nicht passend mit DbLog zusammenarbeiten, wie letztens beim ZWAVE-Modul, in den Code mit aufnehmen
oder sollen wir dafür einfach den valueFn-Code posten?
Aktuell teste ich den Code für das yowsup-Whatsapp-Modul...
Hier wird bei
received from <number> die Nummer in die Unit-Spalte geloggt.
Schöne Grüße
Joe
Hallo,
gibt es ein Testscript was die Performance misst in den "üblichen" fhem konstellationen ?
Ich habe meine erkenntnisse vom sehen (aktualisieren von Plots) und durch die Erkenntnisse auf der Firma (Ziemliche grosse Buchhaltungsdatenbank die ich betreue und auch die Software für die Datenbank die ich entwickel).
Den Umschwung auf Ariadb find ich schonmal gut. Ich weiss im moment noch nicht warum Innodb die Defaultdatenbank geworden ist. Ariadb ist bei mir auf der Firma auch wesentlich performanter ...
Zum Replace Into: Warum ist vorab ein Insert Into nötig ? Replace Into macht genau das. Wenn der Pri Schlüssel trifft werden die Felder geupdatet ansonsten ein neuer Datensatz eingefügt ?!
@Heiko:
Anbei etwas spezielleres, was mir heute aufgefallen ist. Ob das so nutzbar/übernehmbar ist, kann ich nicht entscheiden.
Anbei ein Patch, der die Routine DbLog_explode_datetime von der Benutzung mehrerer Splits zu einem Regex abändert.
Zusätzlich habe ich die Berechnung des Detaultwertes nur dann vorgenommen, wenn dieser auch tatsächlich benötigt wird.
Dabei erziehle ich folgendes Ergebnis:
Ergebnis der bisherigen Routine: 2017-04-04_11:58:59 00:00:00
Ergebnis der neuen Routine: 2017-04-04 11:58:59
Ergebnis der neuen Routine: 2017-04-04 11:58:59
Rate bisher_1 Test2_2 Test3_2
bisher_1 2271/s -- -62% -64%
Test2_2 6028/s 165% -- -4%
Test3_2 6287/s 177% 4% --
Die neue Variante ist lt. meinen Tests (Zeile1 vs. Zeile3) also um ca. 177% also fast 3x so schnell. Statt 2271/s Durchläufe schafft die neue Variante 6287.
Sie ist zudem auch flexibler, da sie mit dem Datum '2017-04-04 11:58:59' als auch '2017-04-04_11:58:59' umgehen kann.
Aktuell wird dazu per regex das "_" in " " ersetzt.
Um sicher zu gehen habe ich dafür auch eine Testroutine geschrieben, die auch die Laufzeiten misst.
Diese Datei befindet sich im Anhang und kann über
./bench-regex2.pl '2017-04-04_11:58:59' gestartet werden
sG
Joe
Hi Joe,
ZitatNoch eine Frage: Wie sollen wir mit splitFn und Devices zukünftig umgehen?
Meiner Meinung nach sollte zukünftig die Implementierung der Device- bzw. modulspezifischen Funktion "DbLog_splitFn" in allererster Linie für das Splitting und die Bereitstellung der Units zuständig sein.
Tobias hatte sich auch schonmal so geäußert und wenn ich mich recht erinnere soll das Splitting im DbLog-Modul mehr und mehr entfernt werden.
Aber ich würde, wie letztens bei ZWAVE, das Splitting hier mit aufnehmen bis der entsprechende Modul-Maintainer die DbLog_splitFn implementiert hat.
Allerdings bin ich nicht der DbLog-Maintainer, auch wenn es sich momentan so anfühlt weil ich/wir in den letzten Monaten viel dafür getan habe/n.
Vielleicht äußert sich Tobias nochmal dazu.
Danke für den Patch Joe ... klingt interessant weil sich die Plot Erstellungszeiten wahrscheinlich verringern könnten. Aber wir würden direkt in den Plotprozess eingreifen.
Deswegen schlage ich vor den jetzigen Entwicklungsstand erstmal zu dokumentieren, finalisieren und euch zum finalen Test bereitstellen um ihn dann einzuchecken.
Deswegen hätte ich noch gern die Bestätigung ob die Änderung von
$lv = "" if(!defined($lv));
sich wirklich positiv ausgewirkt hat. Sonst würde ich diese Änderung wieder auf Original zurücknehmen.
Danach können wir deinen Patch mal mit angehen um es wirklich intensiv zu testen ob / wie sich diese Änderung auswirkt, ok ?
Grüße
Heiko
Zitat von: DS_Starter am 05 April 2017, 22:08:56
$lv = "" if(!defined($lv));
Mir ist eingefallen, wie ich es testen kann, ob es zumindest dem bisherigen Ergebnis entspricht... aber heute nicht mehr, ist zu spät.
Gute Nacht, bis morgen!
Gute Nacht Joe. Habe es auch gerade bei mir getestet.
Funktioniert nicht gut ... es gint dann Probleme mit dem MinIntervall.
Ich habe es wieder zurück auf Originalzustand gebracht.
Bis morgen..
Grüße
Heiko
Zitat von: DS_Starter am 05 April 2017, 22:08:56
Danke für den Patch Joe ... klingt interessant weil sich die Plot Erstellungszeiten wahrscheinlich verringern könnten. Aber wir würden direkt in den Plotprozess eingreifen.
Deswegen schlage ich vor den jetzigen Entwicklungsstand erstmal zu dokumentieren, finalisieren und euch zum finalen Test bereitstellen um ihn dann einzuchecken.
Gerne! Um eben keine negativen Auswirkungen zu haben (hoffentlich), habe ich extra den kleinen Benchmark geschrieben, der auch unterschiedliche Eingaben und Versionen
prüfen und vergleichen kann. Es ist kein eiliges Thema, aber bei einem so zentralen Modul, das auf die meisten Event reagiert, ist es sicherlich lohnenswert.
Hast Du noch eine Idee zum Ändern des Timestamps in valueFN, oder sollen wir diesbezüglich auch noch etwas warten?
schöne Grüße
joe
hallo,
seh ich das richtig, das die Splitfunktion für die einzelnen Felder in die einzelnen Module verlegt werden soll?
Damit würde eventuell (endlich) das Chaos mit den verschiedenen Fehlerhaften Logging aufhören ..(Values die keine SInd usw ...)
Wie würde das mit Modulen aussehen, die von keinem mehr gewartet werden ?
(aktuell habe ich kleinigkeiten am Modul 19_Revolt gepacht, die aber nicht offiziell. Meine Frage ob das Modul noch jemand wartet liefen ins leere ..)
Ich würde das dann da übernehmen wollen (nachdem das ganze auf neuem Stand ist, weils wohl nicht mehr den Richtlinien entspricht) aber bräuchte da dann wohl Hilfe weils das erste Modul wäre was ich "offiziell" betreue ..
Aber das währe der falsche Thread hier :)
Grüße aus Dinslaken
Icebear ak Holger
Zitat von: Icebear am 06 April 2017, 13:02:32
seh ich das richtig, das die Splitfunktion für die einzelnen Felder in die einzelnen Module verlegt werden soll?
Hallo Holger,
korrekt!
Näheres dazu findest Du unter:
https://wiki.fhem.de/wiki/DbLog#Bereitstellung_der_UNITS und
https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_DbLog_split
Module, die nicht mehr gewartet werden können mit dem neuen Attribut "valueFn" aus V2.16.1
von jedem selbst "korrigiert" werden, jedoch ist der ideale Weg sicherlich die Einbindung von SplitFn.
@Heiko:
Vielleicht wäre diese Ergänzung im Log hilfreich um weitere Maintainer dazu zu bekommen, ihre Module um splitFn zu ergänzen?
718a719,721
> else{
> Log3($name, 3, "DbLog: The FHEM-Module for $device,$type does not support DbLog_splitFn. Please ask the Maintainer to fix it.");
> }
Hi joe,
und wie finde ich nun raus ob's noch gewartet wird ?
Habe mir die Split Funktion gerade mal angesehen. Scheint relativ einfach (auch wenn ich kein PERL mensch bin) aber es müssten noch andere Änderungen zum Einchecken gemacht werden (hilfe usw).
Gibts ne entsprechende Hilfe was ich tun muss um Maintainer des Moduls zu werden, falls es keinen mehr gibt / der nicht mehr aktiv ist ?!
Puh, das ist jetzt nicht mein Spezialgebiet...
Generell schau mal in diese Liste:
https://svn.fhem.de/trac/browser/trunk/fhem/MAINTAINER.txt
Wenn bei deinem Modul niemand steht, schreib Rudi an uns sag ihm, dass du gerne Maintainer sein möchtest.
Wenn du es vom dort eingetragenen Maintainer "übernehmen" möchtest, schreib den bisherigen an. Wenn er sich nicht meldet,
sag wieder Rudi bescheid.
hi joe,
Habe ich gemacht, der eine Maintainer ist nicht auffindbar. Den anderen habe ich angeschrieben ...
Allerdings war der seit 23. März nicht Online ...
Ich wart mal 2-3 Tage ...
und nu schluss mit OT ..
Grüße aus Dinslaken
Holger ak Icebear.
Hallo miteinander,
hier nun die finalisierte Version 2.16.3.
Diese Version ist für den check-in vorgesehen.
Hier nochmal zusammengefasst die Neuerungen seit der eingecheckten V 2.14.4:
* neues Attribut valueFn um eine anwenderspezifische Funktion auf die Werte anwenden zu können
@Joe, $TIMESTAMP funktioniert nun auch veränderlich ... nur zum Beispiel:
{ if ($DEVICE eq "MyWetter" && $READING eq "wind"){ $TIMESTAMP="2017-04-06 19:00:00"; } } Es wird beim Timestamp die Form "yyyy-mm-dd hh:mm:ss" geprüft. Ist Timestamp nicht valide, wird er nicht übernommen und der alte verwendet
* neues set addLog Kommando. Es hat die Form:
set <device> addLog <devspec>,<Reading>,[Value] Value ist optional, kann aber gesetzt werden um einen spezifischen Wert in die DB einzufügen.
In der DB wird nur noch der Feldwert von "Event" auf "addLog" gesetzt. TYPE wird devspec-spezifisch geloggt.
Reading wird als regulärer Ausdruck ausgewertet.
* Verbesserte Sortierung von listCache
* ein paar kleinere Verbesserungen (ZWAVE split, Logging mit verbose 4/5)
* Commandref ist ergänzt
Bitte testet die Version, speziell die neuen Features und gebt bitte Feedback.
@Joe ...
ZitatVielleicht wäre diese Ergänzung im Log hilfreich um weitere Maintainer dazu zu bekommen, ihre Module um splitFn zu ergänzen?
Die Idee ist Klasse, nur die Stelle nicht. Dort würden wir jedes Logfile zuspammen weil jeder Event dieses Schleife durchläuft.
Wenn wir eine nicht so "brachiale" Stelle finden würden wäre das eine feine Sache um da mal weiter zu kommen.
Grüße
Heiko
Hallo Heiko,
bin gerade am Testen und jetzt weiß ich, warum meine Tests für die Ersetzung von TIMESTAMP nicht funktioniert haben:
in set sql cacheList habe ich die Einträge mit addLog gesehen, weshalb ich davon ausging, diese auch ändern zu können.
Dieser Code matched jedoch nie. Im Nachhinein auch verständlich, doch gestern hat mich das einiges an Testzeit gekostet.
Ich frage mich, ob wir hier das Event schon rechtzeitig ersetzen sollten oder ob wir das als Hinweis vermerken sollen?
{
if($EVENT eq "addLog"){
$TIMESTAMP = "2017-04-04 00:00:01" ;;
}
Hallo Joe,
du hast recht. Es macht Sinn, $EVENT in der addlog-Funktion vor dem Durchlaufen von valueFn auf "addlog" zu setzen.
Dann hat man die Möglichkeit innerhalb von valueFn $EVENT auf "addlog" zu prüfen und davon abhängig den $TIMESTAMP zu korrigieren.
Das wäre IMHO auch so ziemlich der einzige Fall wo man die Anpassung von $TIMESTAMP sinnvoll anwenden könnte.
Die anderen Felder hat man ja bereits gesplittet zur Auswertung zur Verfügung.
Ich habe die angehängte Version in #258 nochmal geringfügig dafür angepasst und in der Commandref deutlich gemacht.
Grüße
Heiko
Hallo Heiko
Vorerst mal vielen, vielen Dank für den Aufwand den Ihr treibt um das Db Modul besser und funktioneller zu machen.
Ich erlaube mir dennoch einen Kommentar zu diesem Satz:
ZitatDas wäre IMHO auch so ziemlich der einzige Fall wo man die Anpassung von $TIMESTAMP sinnvoll anwenden könnte.
Die anderen Felder hat man ja bereits gesplittet zur Auswertung zur Verfügung.
Mir fallen da etliche Anwendungen ein, wo ein Timestamp NICHT die aktuelle Zeit sein muss/soll:
z.B. hab ich einen Stromzähler, der neben der aktuellen Last/Einspeisung auch werte wie: Monat-Zählerstand, Monats-Maximum-Verbrauch/Einspeisung, usw. ausgibt - und das für die letzten 12 Monate.
Das funktioniert dzt. (aus einem Modul heraus) nur durch massive Eingriffe in die internen Stukturen von fhem. (manipulieren von readingsUpdate)
Verallgemeinert könnte das eine Lösung für alle möglichen (offline-) Daten-Logger sein.
l.g & danke Erwin
Hi erwin,
an sowas hab ich natürlich wieder nicht gedacht. ;)
Also danke und bringt eure Ideen gerne hier ein ... das hilft uns allen bei Verbesserungen und Lösungsmöglichkeiten.
LG
Heiko
Hm, für diesen Fall bräuchte man aber auch die Funktion "UPDATE" im SQL, da sich die Monatssumme ja im Monatsverlauf ändern kann....
Das ist im Moment nicht vorgesehen, wäre aber eine wunderbare Ergänzung, die ich auch sofort nutzen würde!
Damit könnte man sich zB auch einen Plot konfigurieren, der den Monatsverbrauch in einer Jahresdarstellung anzeigt,..... :D
wie $IGNORE=1; könnte man dies über $UPDATE=1; steuern... Ich nehm das mal als Wunsch in der ersten Seite mit auf!
EDIT1: Da fallen mir auf Anhieb zahlreiche weitere Möglichkeiten ein. zB wenn ich nur an einem Stundenschnitt des Verbrauchs interessiert bin, kann ich einen Logeintrag für jede Stunde in der Datenbank erhöhen(updaten)... und spare mich gleich zahlreiche andere Logeinträge, die ich später wieder löschen muss.... Die Idee gefällt mir, würde jedoch vorab vorschlagen, die aktuuelle Version in eine Veröffentlichung zu bringen!
ZitatDie Idee gefällt mir, würde jedoch vorab vorschlagen, die aktuuelle Version in eine Veröffentlichung zu bringen!
Unbedingt ... und es kommen auch bald Feiertage ;-)
@Heiko:
Noch eine Idee, im Moment würde mich jedoch nur eine grobe Einschätzung von Dir interessieren:
Ich habe meine DB ja in Partitionen eingeteilt, und eine Partition dabei heißt "Papierkorb".
Ich logge dort Werte, die ich nicht lange aufbewahren möchte. Die Partition kann ich verzögerungsfrei komplett löschen, egal ob 1000 oder 1 Mio Datensätze enthalten sind.
Nun die Frage: Wäre der Aufwand, in valueFN eine Möglichkeit zu integrieren, die den Wert einer Spalte nach der Units-Tabelle füllt/ändert, hoch?
Die Spalte wird im Moment per Tabellenlayout und Default auf 0 gesetzt. Manuell und per MySQL-Trigger ändere ich dies für gewisse Datensätze auf 1, also Papierkorb.
Mein Wunsch wäre nun praktisch in etwa so:
valueFn
{if ($DEVICE eq "Bewegungssensor" && $READING eq "moving" ){ $PAPIERKORB = 1; #oder $SPALTE8=1;}}
Die Grundüberlegung geht dahin, dass man so auch bei anderen Funktionen statt DELETE ein "update history set papierkorb=1 where XXX;" machen könnte, und die
zu löschenden Datensätze dann mit einem einzigen Befehl verzögerungsfrei löschen kann... So könnte man die Datensätze, die gelöscht werden auch nochmal vorab überprüfen..
schöne Grüße
Joe
Edit: Wunsch#2 Schön wäre, wenn <Reading> von addLog auch mit Regex angegeben werden könnte....
Hallo Joe,
ZitatNun die Frage: Wäre der Aufwand, in valueFN eine Möglichkeit zu integrieren, die den Wert einer Spalte nach der Units-Tabelle füllt/ändert, hoch?
Naja nur in valueFn noch eine Variable setzen zu lassen ist kein Akt. Aber dahinter muß ja noch etwas kommen. Die SQL-Statements müssen ein Insert/Update in eine normalerweise nicht existierende Spalte durchführen, oder sehe ich da etwas falsch ?
ZitatEdit: Wunsch#2 Schön wäre, wenn <Reading> von addLog auch mit Regex angegeben werden könnte
Das verstehe ich nicht. Es ist aber so dass geprüft wird ob das angegebene Reading tatsächlich im Device existiert, da ja der Readingswert abgefragt werden muß um hinterher die Splittingfunktionen zu durchlaufen. Vielleicht kannst du es nochmal genauer erläutern.
Zitat von: DS_Starter am 07 April 2017, 17:00:10
Die SQL-Statements müssen ein Insert/Update in eine normalerweise nicht existierende Spalte durchführen, oder sehe ich da etwas falsch ?
Nein, das ist korrekt! Darum vermute ich den Aufwand eher hoch?!?
Zitat von: DS_Starter am 07 April 2017, 17:00:10
Das verstehe ich nicht.
Ich habe ein Device, von welchem ich mehrere Readings per Addlog gleichzeitig schreiben möchte.
Statt
set <name> addLog Clima,measured-temp
set <name> addLog Clima,desired-temp
set <name> addLog Clima,humiditywäre es elegant, es so zusammenfassen zu können...
set <name> addLog Clima,(.*?-temp|humidity)Besonders bei dynamischen Readings wäre das hilfreich... , und würde vom System her zum <device> Parameter passen, den man per devspec auch als regex angeben kann ;-)
sG
Joe
Hallo Joe, @all,
ZitatEdit: Wunsch#2 Schön wäre, wenn <Reading> von addLog auch mit Regex angegeben werden könnte
Habe das nun auch noch umgesetzt und die Version 2.16.3 im Beitrag #258 hinterlegt.
ZitatNun die Frage: Wäre der Aufwand, in valueFN eine Möglichkeit zu integrieren, die den Wert einer Spalte nach der Units-Tabelle füllt/ändert, hoch?
Dazu habe ich auch inzwischen eine Idee. Muss die noch etwas weiter denken und ausprobieren wenn ich dazu komme....
Aber das mache ich erst wenn die Version 2.16.3 getestet und eingecheckt ist ;)
Grüße
Heiko
Zitat von: DS_Starter am 07 April 2017, 22:27:43
Habe das nun auch noch umgesetzt und die Version 2.16.3 im Beitrag #258 hinterlegt.
Wow, welch tolles neues Feature!!
Anbei ein Beispiel, mit welchem man die in FHEM recht häufig benutzten Heizungsaktore "HM-CC-RT-DN"
um Mitternacht direkt loggen kann.
Vielleicht wäre das was für die COmmandref?
set sql addLog TYPE=CUL_HM:FILTER=model=HM-CC-RT-DN:FILTER=subType!=(virtual|),(measured-temp|desired-temp|actuator)Danke vielmals, schöne Grüße
Joe
ZitatVielleicht wäre das was für die COmmandref?
Danke für das schöne Beispiel. Habe ich natürlich gleich in die Beschreibung integriert.
VG
Heiko
Meine Tests sind erfolgreich, würde diese Version für einen Checkin vorschlagen!! Ist ein schönes Ostergeschenk :D
Zuf Info, fall interesse besteht: Anbei ein Beispiel für valueFn, um das Logging des Whatsapp-Moduls(yowsup) zu korrigieren.
if($DEVICETYPE eq "YOWSUP" && $EVENT =~ m/chatstate: received from: (.*)/){
$READING = "from";
$VALUE = $1;
$UNIT = "Nr.";
}
if($DEVICETYPE eq "YOWSUP" && $VALUE =~ m/(composing|paused)/){
$IGNORE = 1
}
Hallo miteinander,
die V2.16.3 ist eingecheckt und steht morgen früh im Update zur Verfügung.
VG
Heiko
Noch eine Frage zu addLog: Sollte hier nicht der Timer, der hinter dbLogExclude:<Zeit> angegeben wird, mit zurückgesetzt werden?
Morgen Joe,
Da wird es sicherlich unterschiedliche Sichtweisen geben. Eine ist, dass es sich um einen ZUSÄTZLICHEN Logeintrag handelt der außer der Reihe eingefügt wird. In diesem Kontext wäre der Timer nicht zu ändern.
Wie gesagt, das wäre eine Sichtweise ...
Grüße
Heiko
Guten morgen Heiko,
da hast Du bestimmt recht, darum war es als Frage formuliert...
Meine Verständnis wäre: Ich regle damit, dass ich zumindest alle X Sekunden einen Logeintrag bekomme. Üblicherweise mache ich das um Plots ordentlich darzustellen.
Die Zeit gibt nur vor, wie lange ich darauf verzichten kann, den selben Wert immer wieder zu loggen.
Da ich jetzt mit addLog einen neuen zusätzlichen Wert habe, möchte ich eigentlich nicht, dass es vielleicht schon kurze Zeit später diesen Wert nochmals loggt. Bei einer Datenbankbereinigung ist es für mich recht aufwändig, diesen einen Logeintrag zu finden und wieder zu löschen.
Da ich keinen Vorteil des zusätzlichen Loggings sehe, jedoch den oben genannten Nachteil, plädiere ich für "zurücksetzen". :D
(kann aber mit der aktuellen Variante auch leben!)
Hallo miteinander,
wegen dem von Eldrik hier https://forum.fhem.de/index.php/topic,70537.msg621403.html?PHPSESSID=kk377u53al2tt4mfat4uff9su1#msg621403 gemeldeteten Problem mit der PK-Ermittlung auf seiner PostgreSQL habe ich die neue Version 2.16.5 ersttellt.
Bei dieser Version gibt es auch ein Attribut "noSupportPK", welches die Unterstützung von PK im Modul explizit ausschaltet. Das kann evtl. für eine Fehlersuche oder einen schnellen Workaround nützlich sein.
Die Version checke ich dann auch ein.
Grüße
Heiko
Hallo Joe, @all,
ich habe die Version 2.16.5 eingecheckt. Sie ist dann morgen früh im Update verfügbar.
@Joe, ich habe hier noch die V 2.16.6 angehängt in der ich so wie du vorgeschlagen hast im AddLog die Zeit und auch den Value im Quelldevice setze damit es entsprechende Auswirkungen auf MinIntervall von DbLogInclude / DbLogExclude hat.
Probiert es mal bitte intensiv aus ob so funktioniert wie gewünscht und keine negativen Effekte hat.
Ich komme selbst die nächste Zeit nicht zu Tests und weiteren Entwicklungen ...
viele Grüße
Heiko
Hallo Heiko,
ich bin am testen! Da meine Thesholds recht hoch sind benötige ich dafür eine etwas längere zeit, vorallem auch, da mein Standardwert > ein Tag ist!
Ich werde das für diesen Test heruntersetzen.
sG Joe
@Heiko: 2.16.6 bekomme ich leider folgende Fehlermeldung. Eine schnelle Korrektur habe ich nicht gefunden.
2017.04.20 10:16:18 1: reload: Error:Modul 93_DbLog deactivated:
Global symbol "$now" requires explicit package name at ./FHEM/93_DbLog.pm line 2736, <$fh> line 4392.
2017.04.20 10:16:18 0: Global symbol "$now" requires explicit package name at ./FHEM/93_DbLog.pm line 2736, <$fh> line 4392.
2017.04.20 10:16:19 1: configfile: Cannot load module DbLog
Meine Devices habe ich umkonfiguriert, einem Test steht ansonsten nichts mehr im Weg.
Noch etwas ist mir gerade aufgefallen:
Ich bin gerade über die verschiedene Schreibweisen von devspec bei
readingsgroup und dbLog:addLog gestoßen, den ich automatisch aus Gewohnheit so definiert habe.
Bei readingsgroup werden die Readings direkt mit : angehängt, bei dbLog mit ,
IODev=HMLAN(1|2|3):batteryLevel,HMLAN1_RSSI
schöne Grüße
Joe
Hi Joe,
Den $now Fehler fixe ich heute Abend noch schnell damit du/ihr testen könnt.
Die andere Sache sollten wir auch vereinheitlichen, stimmt. Aber das nehmen wir uns Mal für nach meinem Urlaub für eine nächste Version vor.
Bis später ....
Heiko
Hallo Joe,
anbi nun die Version 2.16.7 mit dem Fix
Grüße
Heiko
Danke Heiko,
Tests laufen!
Wünsch Dir eine schöne Urlaubszeit!!
Joe
Die Neuerungen des Moduls funktionieren toll, hie rkann ich im Moment nur positives finden!
Danke für die erneute Verbesserung des Moduls!
Generell habe ich mit DbLogExclude experimentiert, und komme mit der Einschränkung des Regex dort nicht ganz klar.
Dies hängt aber nicht mit den Neuerungen zusammen und ist wohl ein älteres Problem:
Folgendes sollte alle Readings matchen, außer precense. (als negativer look-around).
Separate Tests mit diesem Regex funktionieren.
Demnach sollte mit diesem Regex NUR precensegeloggt werden.
attr rr_ DbLogExclude ^((?!precense).)*$
Dies funktioniert aber nicht, geloggt wird dann gar nicht mehr.
Nun weiß ich, dass bei zB userReadings REGEXE automatisch mit ^ und $ umschlossen werden (scheint hier in Zeile 1101 ausch so zu sein).
Jedoch bin ich mit anderen genannte Kombinationen auch nicht erfolgreich gewesen.
attr rr_ DbLogExclude ((?!precense).)*
Edit: Entwarnung, ich bin wohl diesem Problem aufgesessen, denn der Wert des Attributs hat sich unsichtbar verändert. Nach Update scheint es jetzt wie gewünscht zu funktionieren.
https://svn.fhem.de/trac/changeset?old_path=%2F&old=14046&new_path=%2F&new=14046
Nachtrag:
dbLogExclude funktioniert bei mir mit eingetragenem Interval NICHT.
Anbei ein Patch, mit dem ich es für meine Tests erfolgreicht nutzen konnte, dieser Patch
ist jedoch sicherlich noch nicht komplett.
Ich habe hierin einige Prüfungen etwas umgestalten müssen mit dem Vorteil, dass manche Tests nicht mehrfach durchgeführt werden müssen.
@Heiko: Wenn Du nähere Angaben über meine Tests und meine Testumgebung benötigst, kann ich Dir diese gerne per PN zukommen lassen.
1101a1102
>
1104,1111d1104
< $DoIt = 0 if(!$v2[1] && $reading =~ m/^$v2[0]$/); #Reading matcht auf Regexp, kein MinIntervall angegeben
<
< if(($v2[1] && $reading =~ m/^$v2[0]$/) && ($v2[1] =~ m/^(\d+)$/)) {
< #Regexp matcht und MinIntervall ist angegeben
< my $lt = $defs{$dev_hash->{NAME}}{Helper}{DBLOG}{$reading}{$hash->{NAME}}{TIME};
< my $lv = $defs{$dev_hash->{NAME}}{Helper}{DBLOG}{$reading}{$hash->{NAME}}{VALUE};
< $lt = 0 if(!$lt);
< $lv = "" if(!$lv);
1113,1116c1106,1108
< if(($now-$lt < $v2[1]) && ($lv eq $value)) {
< # innerhalb MinIntervall und LastValue=Value
< $DoIt = 0;
< }
---
> if( $reading =~ m/^$v2[0]$/) {
> $DoIt = 0;
> Log3 $name, 1, "found $dev_name:$reading in DbLogExclude, prevent logging to database. Matching regex: ^".$v2[0].'$ ' if($vb4show);
1117a1110,1143
> else
> {
> Log3 $name, 1, "RR: $dev_name:$reading matched" if($vb4show);
> #Reading matched
> if ($v2[1] eq ''){ #kein MinIntervall angegeben
> Log3 $name, 1, "RR: $dev_name:$reading EINGESCHLOSSEN (nicht excluded), ohne MinInterval" if($vb4show);
> }
> else{
> Log3 $name, 1, "RR: $dev_name:$reading mit MinInterval" if($vb4show);
>
> ##Log3 $name, 4, "RR: $dev_name: #1#1 -".$v2[1]."-" if($vb4show);
> if($v2[1] =~ m/^(\d+)$/) {
> Log3 $name, 1, "RR: $dev_name:$reading MinIntervall ist eine Zahl " if($vb4show);
> my $lv = $defs{$dev_hash->{NAME}}{Helper}{DBLOG}{$reading}{$hash->{NAME}}{VALUE};
> $lv = "" if(!$lv);
> if ($lv ne $value){
> Log3 $name, 1, "$dev_name:$reading logging value $value to database, because it is different to old value $lv" if($vb4show);
> }else{
> #Regexp matcht und MinIntervall ist angegeben
> my $lt = $defs{$dev_hash->{NAME}}{Helper}{DBLOG}{$reading}{$hash->{NAME}}{TIME};
> $lt = 0 if(!$lt);
>
> if($now-$lt < $v2[1]) {
> Log3 $name, 1, "RR: $dev_name:$reading: innerhalb MinIntervall und LastValue=Value" if($vb4show);
>
> # innerhalb MinIntervall und LastValue=Value
> $DoIt = 0;
> }
> else{
> Log3 $name, 1, "$dev_name:$reading: Time since last log shorter than threshold. Time:".($now-$lt)." < Treshold: $v2[1] " if($vb4show);
> }
> }
> }
> }
1119a1146
> }
Edit1: Die verbose4Devs - Logs sollten natürlich noch entfernt/reduziert und fertig übersetzt werden. Das mache ich bei Bedarf gerne.
Hi Joe,
trag erstmal alles zusammen was dir evtl. auffällt. Ich bewerte es und arbeite das dann endgültig ins Modul zu abschließenden Tests ein wenn ich wieder dafür Zeit habe.
So wie ich das sehe hast du die Details in der DbLog_Log Routine geändert. Da müssen wir aufpassen dass sich keine unerwünschten Nebeneffekte einschleichen. Die Routine stammt noch aus dem Modul aus dem vorigen Jahr (dem alten Modul).
ZitatDie verbose4Devs - Logs sollten natürlich noch entfernt/reduziert und fertig übersetzt werden. Das mache ich bei Bedarf gerne.
Brauchst du nicht .... erledige ich dann mit.
So, jetzt mache ich mich erstmal vom Acker, lese aber sicherlich mit und schreibe evtl. Nur ist jetzt erstmal FHEM-freie Zeit angesagt ;)
Bis dann,
Heiko
Hallo Heiko,
alles klar, so wars auch gedacht. Daher hab ich einen Patch und keine neue Version angehängt.
Den Patch brauchte ich nur, damit es für mich erstmal wieder funktioniert.
Ich werde in diesem Punkt sammeln, was ich herausgefunden habe und diesen dann auch aktualisieren.
Findings:
#1 Unterschiedliches Verhalten mit dem min-Interval und ohne. Eigentlich nicht vom Regex gematchten Devices wurden nur durch die Angabe :1000 plötzlich doch geloggt.
Das gewollte Verhalten (lt. COmmandref) ist aber, dass sich der gematchte Device nur dann loggt, wenn entweder der Wert verändert wurde, oder die Min-Zeit überschritten wurde.
Um das zu Testen bei einem Residence-Device folgendes Attribut angeben.
attr rr_ DbLogExclude ((?!precense).)*
Wenn stattdessen dieses Attribut genutzt wird, werden (mit dem bisherigen Code) plötzlich auch Readings wie durTimerAbsence geloggt.
attr rr_ DbLogExclude ((?!precense).)*:1000
--> dieses Verhalten korrigiert der oben genannte Patch.
#2 Lösung für
$lv = "" if(!$lv);
in #288 ergänzt.
sG Joe
Edit: #2 ergänzt
Aktualisierter Patch, der auch Werte mit 0
UND minInterval korrekt loggt.
1101a1102
>
1104d1104
< $DoIt = 0 if(!$v2[1] && $reading =~ m/^$v2[0]$/); #Reading matcht auf Regexp, kein MinIntervall angegeben
1106,1111c1106,1109
< if(($v2[1] && $reading =~ m/^$v2[0]$/) && ($v2[1] =~ m/^(\d+)$/)) {
< #Regexp matcht und MinIntervall ist angegeben
< my $lt = $defs{$dev_hash->{NAME}}{Helper}{DBLOG}{$reading}{$hash->{NAME}}{TIME};
< my $lv = $defs{$dev_hash->{NAME}}{Helper}{DBLOG}{$reading}{$hash->{NAME}}{VALUE};
< $lt = 0 if(!$lt);
< $lv = "" if(!$lv);
---
> ##Debuggcode
> if ($dev_name =~ m/^rr_P/){
> $value=0 if($vb4show); # Debuggcode
> }
1113,1116c1111,1113
< if(($now-$lt < $v2[1]) && ($lv eq $value)) {
< # innerhalb MinIntervall und LastValue=Value
< $DoIt = 0;
< }
---
> if( $reading =~ m/^$v2[0]$/) { #Reading matched, so prevent Logging
> $DoIt = 0;
> Log3 $name, 1, "found $dev_name:$reading in DbLogExclude, prevent logging to database. Matching regex: ^".$v2[0].'$ ' if($vb4show);
1117a1115,1144
> else {
> #Reading matched
> Log3 $name, 1, "RR: $dev_name:$reading matched" if($vb4show);
> if (!defined($v2[1]) || $v2[1] eq ''){ #kein MinIntervall angegeben
> Log3 $name, 1, "RR: $dev_name:$reading Add to Log, no MinInterval" if($vb4show);
> }
> else {
> #Reading NOT matched, so doing further checks
> if($v2[1] =~ m/^(\d+)$/) {
> Log3 $name, 1, "$dev_name:$reading minInterval found, set to ".$v2[1]."s " if($vb4show);
> my $lv = $defs{$dev_hash->{NAME}}{Helper}{DBLOG}{$reading}{$hash->{NAME}}{VALUE};
> #Neu
> # $lv = "" if(!$lv); ## falsch bei VALUE=0;
> $lv = "" if(!defined($lv)); #versuch der Korrektur #2 in 2.16.7b
>
> if ($lv ne $value){
> Log3 $name, 1, "$dev_name:$reading logging value $value to database, because it is different to old value $lv" if($vb4show);
> }else{ #Regexp matcht und MinIntervall ist angegeben, prüfen, ob minINterval überschritten ist.
> my $lt = $defs{$dev_hash->{NAME}}{Helper}{DBLOG}{$reading}{$hash->{NAME}}{TIME};
> $lt = 0 if(!$lt);
> if($now-$lt < $v2[1]) {
> Log3 $name, 1, "$dev_name:$reading: prevent logging. Time since last Log too short. ".($now-$lt)." < Treshold: $v2[1] " if($vb4show);
> $DoIt = 0;
> }
> else{
> Log3 $name, 1, "$dev_name:$reading: Add to Log. Old Value = New value, but Time since last log > than minInterval. Time: ".($now-$lt)." > Treshold: $v2[1] " if($vb4show);
> }
> }
> }
> }
1119a1147
> }
Moin zusammen,
Nachdem Heiko mich auf diesen Fred geschubst hat, gibt es auch noch einen Wunsch von mir ;Dset <name> deleteOldDaysFilter<n> <Device> <Reading>
Es ist ja oft so, dass man wichtige und nicht so wichtige Daten loggt. Dementsprechend möchte man sie auch länger oder nicht so lange aufheben. So wäre es doch toll, wenn man nicht den großen Holzhammer nimmt, sondern gezielt unwichtige Daten früh aussortieren kann. Es würde die DB auch deutlich entlasten, wenn man nicht mit Rücksicht auf die wichtigen Daten jeden Schrott entsprechend lange aufbewahrt. Wenn man nun noch den Readingname mit Wildcards versorgen kann (optimal, weil FHEM-durchgängig natürlich Perl-Regex-Style, für die Programmierung sicher einfacher SQL-Style) dann könnte man mit wenigen Handgriffen (oder eben at's) viele Daten rechtzeitig entsorgen.
Bei reducelog gibt es das ja schon in etwa (eben umgekehrt):
set <name> reduceLogNbl <n> [average[=day]] [exclude=deviceRegExp1:ReadingRegExp1,deviceRegExp2:ReadingRegExp2,...]
selektive Grüße
Niels
Hallo Niels,
melde mich nochmal hier, dann mache ich wieder Urlaub ;)
Sowas in der Art hatte JoeAllb auch schon mal angedacht. Umgesetzt haben wir es bisher nicht.
Momentan kannst du aber mit DbRep-Devices arbeiten um selektiv Device/Reading-Kombinationen aus der DB zu löschen. Dabei kannst du auch SQL-Wildcards (% bzw. _) angeben. So mache ich das z.Zt.
Einfach die benötigte Menge DbRep's anlegen, entsprechende Attribute für die zu löschenden Device/Readings setzen, ggf. auch noch die Zeiten begrenzen (um z.B. die Dev/readings zu löschen die älter als x sind) und dann mit At regelmäßig laufen lassen.
Arbeitet non-blocking und bei mit mit MySQL/MariaDB völlig merklos im Hintergrund.
VG
Heiko
Hallo Joe,
ich komme mit deinem Patch auch #288 nicht klar. Es lässt sich mit Tortoisemerge nicht verarbeiten und zu Fuß ist mir das zu anstrengend ;)
Kannst du den relevanten Ausschntt aus DbLog (mit ein paar Zeilen davor und danach) einfach hier als Code reinkopieren ? Damit komme ich dann sicher besser klar.
Grüße
Heiko
Hallo Heiko,
schön von Dir zu hören ;-)
Jetzt bin nur leider ich unterwegs....
Interessant, denn den Patch habe ich mit Tortoise erstellt.
Ich mus snur zugeben, ich habe in der zwischenzeit herausgefunden, dass der Patch so tatsächlich die Funktion etwas ändert (mehr in die Richtung, wie ich es bräuchte ;-) ).
Ich müsste da also nochmal ran und einen oder zwei vergleiche negieren. GGf. fällt mir dann auch ein, wie ich die von mir gewünschte Funktion noch unterbringen kann...
Meine Funktion entspricht praktisch der Anwendung event-on-change kombiniert mit event-min-interval, da ich die Ereignisse aber benötige (für chat, etc..) möchte ich gerne auf die event.* Funktionen verzichten, und dies direkt im Logdevice filtern...
Aber wie gesagt, diese Woche bin ich noch unterwegs, vielleicht kann ich ihn mal eines Abends fertigstellen, wenn ich eine VPN-Verbindung zu meinem Server aufbauen kann (das ist im Ausland leider nicht immer möglich... :( )
sG
Joe
Ja wie das so ist ;)
Ok, dann mach erstmal noch deine Checks. Ich habe die Addlog-Funktion schon umgebaut (von wegen <Device>:<Reding> ) und auch noch valueFN geändert damit VALUE bzw. UNIT auch 0 bzw. Leerstring gesetzt werden können.
Niels (Muschelpuster) hat etwas weiter oben auch noch einen Wunsch eingebracht. Vllt.kannst du das ma mit ganz vorn in deiner Liste mit vermerken.
Die neue Version stelle ich dann noch zum Test zur Verfügung.
Bis denne ...
Heiko
Hallo zusammen,
hatte am WE die neue Version 2.16.9 angefertigt, hier nun zum Test.
ChangeLog:
* geändert ist die Syntax für die Addlog-Funktion.
Damit es eine Vereinheitlichung mit dem Feel zu anderen Modulen gibt, sieht die Syntax nun so aus:
... addLog devspec:Reading [Value]
Beachtet auch dass es zwischen Reading und dem optionalen Value nun ein Leerzeichen statt Komma gibt. Die generelle Änderung war
nötig geworden um auch komplexe Angaben wie:
addLog TYPE=CUL_HM:FILTER=model=HM-CC-RT-DN:FILTER=subType!=(virtual|):(measured-temp|desired-temp|actuator) bzw.
addLog Dev1,Dev2,Dev3:(measured-temp|desired-temp|actuator)
abbilden zu können und damit die Devspec-Definition vollumfänglich zu unterstützen.
* innerhalb der valueFN-Funktion kann man nun die Werte für $VALUE und $UNIT auf Leerstring '' bzw. 0 setzen um sie so in
die DB zu übernehmen. Solche Werte, durch Perl als "false" gewertet, wurden bisher ignoriert.
Bitte testet die Funktionen wie gehabt, insbesondere das AddLog mit komplexeren Strukturen.
Die Version möchte ich demnächst einchecken wenn nichts negatives auffallen sollte.
Grüße
Heiko
Hallo,
kleiner Querverweis für all diejenigen die sich mit Datenauswertungen befassen.
DbRep wurde aktuell um eine sqlResult sqlCmd-Funktion erweitert (Danke an viegener für den Input !) mit der Benutzer beliebige SQL-Statements absetzen können. https://forum.fhem.de/index.php/topic,53584.msg633861.html#msg633861 (https://forum.fhem.de/index.php/topic,53584.msg633861.html#msg633861) (ist noch nicht eingecheckt).
Das gibt es zwar in DbLog ebenfalls, allerdings können die Ergebnisse vielzeilig sein und werden wie bei DbRep üblich, non-blocking ausgeführt.
Darüber hinaus kann man über ein Attribut die Darstellung des Ergebnisses verändern.
viele Grüße
Hallo,
nochmal ein kleiner Querverweis zu DbRep.
DbRep erzeugt ja je nach ausgeführten Statement u.U. viele Readings, die eine entsprechende Eventlast erzeugen wenn man die Events erzeugen lässt um sie mit Notify weiter zu verarbeiten.
Mit der Version 4.14.0 gibt es nun eine User-Schnittstelle über die man eigenen Code zur Ausführung bringen kann OHNE dafür Events erzeugen zu müssen.
Die Erläuterung und ein praktisches Beispiel zur Anwendung findet man hier: https://forum.fhem.de/index.php/topic,53584.msg635077.html#msg635077
schönen Sonntag,
Heiko
Zitat von: DS_Starter am 17 Februar 2017, 17:17:58
Es gibt also nun "set <name> ... ":
* count (alt) bzw. countNbl (non-blocking)
* reduceLog (alt) bzw. reduceLogNbl (non-blocking)
* deleteOldDays (alt) bzw. deleteOldDaysNbl (non-blocking)
Da ich mit deleteOldDays das Problem habe, dass FHEM so lange blockiert ist, dass mir einige Dinge aus dem Tritt geraten (die LaCrosseGateway werden neu connected, da zu lange nichts von ihnen gehört wurde, ...) und ich gerade deleteOldDaysNbl entdeckt habe, dachte ich, dass das meine Rettung ist.
Es scheint aber mit SQLite nicht ganz zu funktionieren.
deleteOldDaysNbl 27:
2017.06.01 08:06:47 3: DbLog commonLog -> Deletion of records older than 27 days in database /opt/fhem/dbLog/commonLog.db requested
2017.06.01 08:07:48 2: DbLog commonLog -> Error table history - DBD::SQLite::st execute_array failed: database is locked [err was 5 now 2000000000]
executing 2 generated 2 errors at ./FHEM/93_DbLog.pm line 1409.
2017.06.01 08:07:54 3: DbLog commonLog -> deleteOldDays finished. 100178 entries of database /opt/fhem/dbLog/commonLog.db deleted.Von 08:06:47 bis 08:07:54 war FHEM dann trotzdem blockiert.
Ansonsten läuft DbLog bei mir seit je her völlig problemlos ohne irgend welche Auffälligkeiten.
Hallo HCS,
bin Grad unterwegs und kann nicht viel schreiben, aber vermutlich lässt du deine DB noch synchron laufen.
Wenn du den asynchmode einschaltest sollte dieses Verhalten nicht mehr mit SQLite auftreten.
VG
Heiko
Zitat von: DS_Starter am 01 Juni 2017, 10:49:24
bin Grad unterwegs und kann nicht viel schreiben
Kein Problem, so eilig ist es nun wirklich nicht
Zitat von: DS_Starter am 01 Juni 2017, 10:49:24
Wenn du den asynchmode einschaltest sollte dieses Verhalten nicht mehr mit SQLite auftreten.
OK, habe ich jetzt eingeschaltet. Klappt schon besser, aber es ist trotzdem noch ein Fehler dabei:
2017.06.01 11:07:19 3: DbLog commonLog -> Deletion of records older than 26 days in database /opt/fhem/dbLog/commonLog.db requested
2017.06.01 11:08:24 2: DbLog commonLog -> Error table history - DBD::SQLite::st execute_array failed: executing 40 generated 1 errors at ./FHEM/93_DbLog.pm line 1787.
2017.06.01 11:08:24 3: DbLog commonLog -> deleteOldDays finished. 114681 entries of database /opt/fhem/dbLog/commonLog.db deleted.Ich lasse es mal so weiterlaufen, wird jede Nacht einmal erledigt.
Kannst ja mal schauen, wenn Du Zeit hast, ohne Stress und so ...
ZitatOK, habe ich jetzt eingeschaltet. Klappt schon besser, aber es ist trotzdem noch ein Fehler dabei...
Ja, das ist in dem Fall in Ordnung. SQLite sperrt die history-Tabelle gegen weiter Schreibzugriffe wenn das delete läuft.
FHEM wirft dann diesen Fehler sobald vom DB-Interface ein Problem gemeldet wird, in diesem Fall kein Schreiben in die DB (execute_array) .
Wenn du die DB im Synchronmode betreibst, ist zwar der deleteOldDaysNbl durch den BlockingCall nicht blockierend, aber die FHEM Hauptschleife bleibt beim history-Zugriff hängen.
Im asynchronen Modus wird dieser Zustand durch die Applikation abgefangen. Der Fehler wird durch die DB weiterhin gemeldet,aber FHEM speichert die Log-Daten solange im Cache (listCache) bis die DB wieder verfügbar ist. Das ist auch in anderen Situationen wie DB-Crash oder Backup der Fall. Die Daten werden wieder in die DB geschrieben wenn der Zugriff wieder funktioniwert.
Dadurch blockiert FHEM nicht und auch die Daten gehen nicht verloren.
Mit dem Attr syncInterval kannst du festlegen alle wieviel Sekunden der Cache in die DB geschrieben werden soll. Wenn du diesen Wert vor dem deleteOldDaysNbl auf einen deutlich höheren Wert setzt als normalerweise deleteOldDaysNbl dauert, wirst du diese Meldung nicht mehr bekommen weil kein Schreibzugriff stattfindet.
MySQL, die ich benutze, reagiert bei parallelen Zugriffen deutlich entspannter. Da gibt es solche Meldungen (im Normalbetrieb) nicht.
viele Grüße
Heiko
Vielen Dank für die Erläuterung.
Das klappt trotzdem nicht ohne Fehlermedung.
asyncMode ist 1
syncInterval ist 180
*01:30:00 {
fhem ("set commonLog commitCache");
fhem ("set commonLog deleteOldDaysNbl 30");
}
2017.06.01 20:07:15 3: DbLog commonLog -> Deletion of records older than 30 days in database /opt/fhem/dbLog/commonLog.db requested
2017.06.01 20:08:13 3: DbLog commonLog -> deleteOldDays finished. 0 entries of database /opt/fhem/dbLog/commonLog.db deleted.
2017.06.01 20:08:13 2: DbLog commonLog -> Error table history - DBD::SQLite::st execute_array failed: executing 323 generated 1 errors at ./FHEM/93_DbLog.pm line 1787.
Nach knapp einer Minute ist der deleteOldDaysNbl durch.
Direkt drauf kommt der Fehler
Aber es dürfte doch eigentlich erst 20:10:15 wieder in die DB schreiben?
ZitatAber es dürfte doch eigentlich erst 20:10:15 wieder in die DB schreiben?
Da hast du recht. Es sei denn dass inzwischen der Wert des Attr "cacheLimit" erreicht ist. Wenn also hinreichend viel Daten in der Zwischenzeit aufgelaufen sind. Wenn cacheLimit erreicht ist wird versucht zu schreiben egal ob syncInterval erreicht ist.
Ansonsten kann ich mir gerade nicht vorstellen weswegen die Schreibroutine angesprungen werden sollte.
Jetzt habe ich mal auf meiner SQLite 3 Test-DB alle Datensaätze älter als 50 Tage löschen lassen.
2017.06.01 23:00:13.806 3: DbLog LogSQLITE -> Deletion of records older than 50 days in database /opt/fhem/fhem.db requested
2017.06.01 23:01:30.032 3: DbLog LogSQLITE -> deleteOldDays finished. 2908707 entries of database /opt/fhem/fhem.db deleted.
Das System hat innerhalb von rund 2:20 die Daten gelöscht. syncInterval habe ich auf 45 s stehen.
Ich habe weder während es Laufs noch hinterher eine Fehlermitteilung wie du erhalten.
Spannende Sache.
deleteOldDaysNbl benötigt in meinem Fall recht genau eine Minute
cacheLimit ist 500, das wird in einer Minute definitiv nicht erreicht.
syncInterval ist aktuell 120
SQLite Version 3.7.13
Das kann ich beides sicher reproduzieren:
1. Wenn ich den Start von deleteOldDaysNbl so lege, dass es vor "NextSync" fertig ist, dann gibt es keinen Fehler.
2. Wenn ich deleteOldDaysNbl so starte, dass während der Ausführung "NextSync" erreicht wird, passiert folgendes:
- Wenn "NextSync" erreicht ist, geht CacheUsage auf 0
- Zu diesem Zeitpunkt wird kein Fehler geloggt
- CacheUsage steigt dann wieder an
- Wenn deleteOldDaysNbl fertig ist, endet es mit dem Fehler:
2017.06.02 09:41:58 3: DbLog commonLog -> deleteOldDays finished. 0 entries of database /opt/fhem/dbLog/commonLog.db deleted.
2017.06.02 09:41:58 2: DbLog commonLog -> Error table history - DBD::SQLite::st execute_array failed: executing 152 generated 1 errors at ./FHEM/93_DbLog.pm line 1787.
Der Fehler kommt immmer nur am Ende, auch dann, wenn ich syncInterval sehr kurz mache, z.B. 10 Sekunden.
In dem Fall passiert folgendes:
- deleteOldDaysNbl gestartet
- Wenn "NextSync" das erste mal erreicht ist, geht CacheUsage auf 0 und state bleibt "connected"
- Wenn "NextSync" das zweite mal erreicht ist, zählt CacheUsage weiter hoch und state wird "Commit already running - resync at NextSync"
- Das geht so weiter, bis deleteOldDaysNbl fertig ist
- Dann kommt am Ende der Fehler
Hier die Konfiguration vom device:
Internals:
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION ./dbLog/commonLog.conf
DBMODEL SQLITE
DEF ./dbLog/commonLog.conf .*:.*
MODE asynchronous
NAME commonLog
NR 246
NTFY_ORDER 50-commonLog
PID 32203
REGEXP .*:.*
STATE connected
TYPE DbLog
VERSION 2.16.10
dbconn SQLite:dbname=/opt/fhem/dbLog/commonLog.db
dbuser
Helper:
COLSET 1
DELDAYS 30
DEVICECOL 64
EVENTCOL 512
READINGCOL 64
TYPECOL 64
UNITCOL 32
VALUECOL 128
Readings:
2017-06-02 09:52:08 CacheUsage 54
2017-06-02 09:51:24 NextSync 2017-06-02 09:53:24 or if CacheUsage 500 reached
2017-05-20 11:51:35 countCurrent 22
2017-05-20 11:51:35 countHistory 3126176
2017-06-02 09:41:58 lastRowsDeleted 0
2017-06-02 09:51:25 state connected
Cache:
index 6670
Memcache:
6617 2017-06-02 09:51:25|EC3000_7AE4|EC3000|power: 0.2|power|0.2|
6618 2017-06-02 09:51:26|EC3000_7CA8|EC3000|consumption: 11.948|consumption|11.948|
6619 2017-06-02 09:51:26|EC3000_7CA8|EC3000|power: 0.2|power|0.2|
6620 2017-06-02 09:51:27|EC3000_HCS|EC3000|power: 4.7|power|4.7|
6621 2017-06-02 09:51:28|EC3000_Cubie|EC3000|power: 14.1|power|14.1|
6622 2017-06-02 09:51:28|EC3000_7E43|EC3000|power: 0.3|power|0.3|
6623 2017-06-02 09:51:30|EC3000_7AE4|EC3000|power: 0.2|power|0.2|
6624 2017-06-02 09:51:31|EC3000_7CA8|EC3000|consumption: 11.948|consumption|11.948|
6625 2017-06-02 09:51:31|EC3000_7CA8|EC3000|power: 0.2|power|0.2|
6626 2017-06-02 09:51:32|EC3000_HCS|EC3000|power: 4.5|power|4.5|
6627 2017-06-02 09:51:33|EC3000_Cubie|EC3000|power: 13.6|power|13.6|
6628 2017-06-02 09:51:33|EC3000_7E43|EC3000|power: 0.2|power|0.2|
6629 2017-06-02 09:51:35|EC3000_7AE4|EC3000|power: 0.2|power|0.2|
6630 2017-06-02 09:51:36|EC3000_7CA8|EC3000|consumption: 11.948|consumption|11.948|
6631 2017-06-02 09:51:36|EC3000_7CA8|EC3000|power: 0.2|power|0.2|
6632 2017-06-02 09:51:37|EC3000_HCS|EC3000|power: 4.5|power|4.5|
6633 2017-06-02 09:51:38|EC3000_Cubie|EC3000|power: 13.7|power|13.7|
6634 2017-06-02 09:51:38|EC3000_7E43|EC3000|power: 0.3|power|0.3|
6635 2017-06-02 09:51:40|EC3000_7AE4|EC3000|power: 0.2|power|0.2|
6636 2017-06-02 09:51:41|EC3000_7CA8|EC3000|consumption: 11.948|consumption|11.948|
6637 2017-06-02 09:51:41|EC3000_7CA8|EC3000|power: 0.3|power|0.3|
6638 2017-06-02 09:51:42|EC3000_HCS|EC3000|power: 4.5|power|4.5|
6639 2017-06-02 09:51:43|EC3000_Cubie|EC3000|power: 13.5|power|13.5|
6640 2017-06-02 09:51:43|EC3000_7E43|EC3000|power: 0.2|power|0.2|
6641 2017-06-02 09:51:45|EC3000_7AE4|EC3000|power: 0.2|power|0.2|
6642 2017-06-02 09:51:46|EC3000_7CA8|EC3000|consumption: 11.948|consumption|11.948|
6643 2017-06-02 09:51:46|EC3000_7CA8|EC3000|power: 0.4|power|0.4|
6644 2017-06-02 09:51:47|EC3000_HCS|EC3000|power: 4.5|power|4.5|
6645 2017-06-02 09:51:48|EC3000_Cubie|EC3000|power: 13.6|power|13.6|
6646 2017-06-02 09:51:48|EC3000_7E43|EC3000|power: 0.3|power|0.3|
6647 2017-06-02 09:51:50|EC3000_7AE4|EC3000|power: 0.2|power|0.2|
6648 2017-06-02 09:51:51|EC3000_7CA8|EC3000|consumption: 11.948|consumption|11.948|
6649 2017-06-02 09:51:51|EC3000_7CA8|EC3000|power: 0|power|0|
6650 2017-06-02 09:51:52|EC3000_HCS|EC3000|power: 4.6|power|4.6|
6651 2017-06-02 09:51:53|EC3000_Cubie|EC3000|power: 13.5|power|13.5|
6652 2017-06-02 09:51:53|EC3000_7E43|EC3000|power: 0.3|power|0.3|
6653 2017-06-02 09:51:55|EC3000_7AE4|EC3000|power: 0.2|power|0.2|
6654 2017-06-02 09:51:56|EC3000_7CA8|EC3000|consumption: 11.948|consumption|11.948|
6655 2017-06-02 09:51:56|EC3000_7CA8|EC3000|power: 0.2|power|0.2|
6656 2017-06-02 09:51:57|EC3000_HCS|EC3000|power: 4.5|power|4.5|
6657 2017-06-02 09:51:58|EC3000_Cubie|EC3000|power: 13.6|power|13.6|
6658 2017-06-02 09:51:58|EC3000_7E43|EC3000|power: 0.3|power|0.3|
6659 2017-06-02 09:52:00|EC3000_7AE4|EC3000|power: 0.2|power|0.2|
6660 2017-06-02 09:52:01|EC3000_7CA8|EC3000|consumption: 11.948|consumption|11.948|
6661 2017-06-02 09:52:01|EC3000_7CA8|EC3000|power: 0.5|power|0.5|
6662 2017-06-02 09:52:02|EC3000_HCS|EC3000|power: 4.5|power|4.5|
6663 2017-06-02 09:52:03|EC3000_Cubie|EC3000|power: 13.5|power|13.5|
6664 2017-06-02 09:52:03|EC3000_7E43|EC3000|power: 0.2|power|0.2|
6665 2017-06-02 09:52:05|EC3000_7AE4|EC3000|power: 0.2|power|0.2|
6666 2017-06-02 09:52:06|EC3000_7CA8|EC3000|consumption: 11.948|consumption|11.948|
6667 2017-06-02 09:52:06|EC3000_7CA8|EC3000|power: 0.2|power|0.2|
6668 2017-06-02 09:52:07|EC3000_HCS|EC3000|power: 4.5|power|4.5|
6669 2017-06-02 09:52:08|EC3000_Cubie|EC3000|power: 13.7|power|13.7|
6670 2017-06-02 09:52:08|EC3000_7E43|EC3000|power: 0.2|power|0.2|
Attributes:
DbLogSelectionMode Include
DbLogType Current/History
asyncMode 1
cacheLimit 500
disable 0
group CommonLog
room System
syncInterval 120
verbose 3
In der Variante "blocking" gibt es keinerlei Fehler, außer den an anderen Stellen durch das Blockieren erzeugten halt.
@HCS , das ist wirklich spannend. Dank deiner ausführlichen Beschreibung ist mir jetzt noch eine Idee gekommen die ich mal checken muss. So ganz passt das Verhalten nicht zu meiner Theorie. Ich melde mich wieder zu dem Thema.
@Joe, das Thema Backup kannst du von der ToDo Liste nehmen. Für MySql habe es jetzt im DbRep umgesetzt. Läuft nicht blockierend, online im laufenden Betrieb. Ich muss noch ein bisschen feilen und testen . Wenn ich fertig bin Stelle ich die Version im DbRep Forum zur Verfügung. Für die anderen DB Typen würde die Anwendung auch im DbRep angesiedelt.
Grüße
Heiko
Zitat von: DS_Starter am 02 Juni 2017, 11:37:07
@Joe, das Thema Backup kannst du von der ToDo Liste nehmen.
Erledigt!
Hallo HCS, @all,
denke den Grund für das auf den ersten Blick seltsame Verhalten gefunden zu haben. Der erste Synclauf geht in den Hintergrund und bleibt dort, für FHEM natürlich nicht merkbar, dort "hängen". Deswegen kommt erst beim zweiten Synclauf "Commit already running - resync at NextSync", dann solange bis der deleteOldDays durch ist.
Sobald die Tabellensperre durch deleteOldDays nicht mehr existiert, versucht der in dem Hintergrund auf die Freigabe wartende Prozess die Daten zu schreiben. Wenn es in diesem Schreibprozess zu einem Fehler kommt, wird ein Fehler im Log generiert und die Daten an den Cache zurückgegeben (Works as designed). Daten gehen dadurch nicht verloren die übergebenen Daten in einer Transaktion geschrieben werden.
Nun habe ich DbLog für SQLite so abgeändert, dass bereits innerhalb der Applikation eine Sperre für das Logging gesetzt wird, wenn eine andere schreibende Aktivität (deleteOldDaysNbl, reduceLogNbl) aktiv ist. Auch die Ausgabe in state habe ich etwas angeändert.
Bitte testet bei euch (SQLite), insbesondere HCS, die angehängte Version 2.16.11.
Bei mir habe ich keine Fehlermeldungen provozieren können.
schöne Pfingsgrüße
Heiko
Zitat von: DS_Starter am 03 Juni 2017, 20:16:31
Bitte testet bei euch (SQLite), insbesondere HCS, die angehängte Version 2.16.11.
Habe es mehrfach getestet und es funktioniert mit der 2.16.11 ohne Fehler am Ende und ohne die "erstaunlichen" Verhaltensweisen (CacheUsage geht auf 0) usw.
Vielen Dank für den Bugfix.
Ich beobachte DbLog mal noch etwas genauer im sonstigen Betrieb aber ich denke, dass ich aus SQLite-Sicht eine Freigabe für's Repository empfehlen könnte.
ZitatIch beobachte DbLog mal noch etwas genauer im sonstigen Betrieb aber ich denke, dass ich aus SQLite-Sicht eine Freigabe für's Repository empfehlen könnte.
Danke für die Rückmeldung. Ich werde es auch noch etwas laufen lassen und beobachten und wenn nichts mehr auffällt einchecken.
Grüße
Heiko
Hallo zusammen,
für die Interessenten ....
die DbRep -Version mit dem integrierten Dump/Backup für MySQL-DB ist nun hier https://forum.fhem.de/index.php/topic,53584.msg643931.html#msg643931 beschrieben und zum Test verfügbar.
Grüße
Heiko
Habe soeben Version 2.16.11 eingecheckt.
VG
Heiko
Hallo zusammen,
wegen der hier https://forum.fhem.de/index.php/topic,73114.0.html gestellten Frage zu Abspeicherung von "°C" als "°C" habe ich mich mal mit dem Thema beschäftigt und eine Version 2.17.0 erstellt, die UTF8 von MySQL unterstützt. Im DBD-Treiber von MySQL ist UTF8 per default nicht eingeschaltet.
Um die UTF8-Unterstützung einzuschalten, ist ein utf8- Eintrag in der db.conf hinzuzufügen:
%dbconfig= (
connection => "mysql:database=fhemtest;host=<Host>;port=3306",
user => "<DB-User>",
password => "<PW>",
utf8 => 1, # enable(1) / disable(0) UTF-8 support of MySQL
);
Danach "set ... rereadcfg". Beim fhem-Start zieht es natürlich gleich.
Ich habe es erst über ein Attribut probiert. Das hat sich allerdings als ungünstig erwiesen weil zum Zeitpunkt der DB-Handle-Erstellung die Attribute noch nicht eingelesen sind und so einfach besser handhabbar ist.
Das Ganze ist rückwärtskompatibel, d.h. wenn der utf-Eintrag ncht gesetzt ist, ist es gleichbedeutend mit "utf8 => 0" (so wie bisher).
Wenn der utf-Eintrag auf "1" gesetzt ist, wird "°C" auch als "°C" abgeseichert, sofern mit dem verwendeten Characterset der DB übereinstimmend.
Probierts mal aus und gebt mir bitte Rückinfo wie ihr die Vorgehensweise findet.
Grüße
Heiko
Hallo zusammen,
habe mit der Version 2.17.1 zwei kleine Unschönheiten gefixt die mir aufgefallen sind. Außerdem ist die Commandref um den Aufbau des Konfigurationsfiles für DbLog ergänzt. Damit hat man das gleich zur Verfügung.
* wenn SVG's in einem room abgearbeitet wurden, gab es es Einträge "UTF8 support enabled" im Log mit verbose 3. Die sollen nur einmal beim Start
bzw. rereadcfg kommen.
* UTF8 Untersützung ist noch für die get-Funktion eingebaut, also wenn man im FHEMWEB eine manuelle Abfrage der Art
"get LogDB - all 2017-06-18 2017-06-19 MyWetter:temperature" aufruft, werden die Ausgaben bzgl. UNIT ebenfalls korrigiert.
Grüße
Heiko
Ich habe die erste Seite aktualisiert. Testen kann ich das nicht, da ich meine Tabellen aus Performancegründen nicht in UTF8 erstellt habe.
"°C" korrigiere ich im Moment über valueFn.
Hi Joe,
ZitatTesten kann ich das nicht, da ich meine Tabellen aus Performancegründen nicht in UTF8 erstellt habe.
Stimmt nicht ganz. Wenn du das neue Modul bei dir einspielst und alles bleibt beim Alten ist es auch ok. ;)
lg
Heiko
Bei mir wird das °C jetzt richtig in der DB gespeichert!
Habe soeben die V2.17.1 eingecheckt.
Im contrib/dblog-Verzeichnis ist die Beispiel-db.conf ebenfalls um diesen optionalen Parameter ergänzt.
Grüße
Heiko
Noch ein Gedanke: Würde es nicht sinn machen, die Frage der Verbindung ob "UTF8" oder nicht abhängig davon zu machen, wie die Datenbank angelegt ist?
Ich frage mich gerade, was bei unterschiedlichen kombinationen als Ergebnis herauskommt. Wenn ich jetzt die Verbindung auf UTF8 umstelle, aber eine ASCI-Datenbank habe, wird
vermutlich nichts schönes dabei heraus kommen. umgekehrt hatten fast alle bisher eine UTF8-Datenbank befüllt jedoch mit einer ASCI-Datenbankverbindung.
Auch diese Unicodezeichen sind bis jetzt nicht sauber in die Datenbank abgelegt worden.
Durch die neue Option haben wir zwei verschiedene Stellen, die "zusammenpassen" müssen.
Hi Joe,
ja, schön wäre es die Steuerung so zu machen. Allerdings habe ich dafür noch keine Lösung gefunden, weil diese Entscheidung bereits sehr frühzeitig bei der Anlage des DB-Handle erfolgen muß (beim FHEM-Start). Dieser Paramater muß an dieser Stelle mitgegeben werden.
Deswegen war ich auch mit dem ersten Attribut-Ansatz gescheitert.
Für den asynchronen Modus, der ja immer wieder einen einen neuen DBH erhält, wäre es wahrscheinlich mit entsprechenden Aufwand möglich. Beim synchronen Modus ist das komplizierter wenn nicht unmöglich.
Also ich denke dass der User, der sich Gedanken um so etwas macht, auch in der Lage ist die von dir beschriebenen Abhängigkeiten zu berücksichtigen.
Wenn der User kein "Problem" damit hat, kann er ja wie bisher in den allermeisten Fällen mit dem Standardsetup weiter machen.
lg
Heiko
Ich verstehe... ;-)
Dann ändere ich meine Gedanken ab in folgenden nachrangigen Wunsch für später:
Eine Funktion wie "set sql checkConfig", die dann auf gewisse Ungereimtheiten prüft und diese ausgibt.
Dort könnten wir zB auf Unicode, aber auch auf die alten Spaltenbreiten, auf fehlende Indexe, etc. hinweisen. Das wäre denk vom Aufwand her eher überschaubar,
hätte kein Fehlerpotential (da es den Livebetrieb nicht beeinflusst) und diese Information könnte bei einem Supportfall direkt angefragt werden.
Gute Idee Joe, du hast aber auch immer wieder etwas im Ärmel dass mir nicht langweilig werden kann. ;)
Schreib's Mal auf deine Liste ...
LG
Heiko
Hallo zusammen,
es hat mich natürlich gereizt den von Joe angeregten configCheck einzubauen. Hier der erste Wurf mit V2.18.0.
Implementiert ist "set ... configCheck" für MySQL und PostgreSQL.
Viel ist dazu nicht anzumerken.
Probierts mal aus und gerne wieder Verbesserungsvorschläge und Ergänzungen.
Grüße
Heiko
Hallo Heiko,
Bin gespannt, herzlichen Dank :D
Leider bin ich im Ausland und komm erst Sonntag Abend heim zum testen....
schöne Grüße
Joe
Hi Joe,
ja kein Stress. Es gibt ja auch noch andere Mitstreiter. Und vllt. habe ich bis dahin noch etwas mehr gemacht, mal schauen wie das WE wird.
Bis dann ...
Zitat von: DS_Starter am 23 Juni 2017, 16:25:24
Hallo zusammen,
es hat mich natürlich gereizt den von Joe angeregten configCheck einzubauen. Hier der erste Wurf mit V2.18.0.
Implementiert ist "set ... configCheck" für MySQL und PostgreSQL.
Viel ist dazu nicht anzumerken.
Probierts mal aus und gerne wieder Verbesserungsvorschläge und Ergänzungen.
Grüße
Heiko
Morgen Heiko,
zur Info, habe die 2.18.0 bei mir in einer STD-Konfiguration am laufen.
Result of connection check
Connection to database fhem successfully done.
Recommendation: settings o.k.
Result of encoding check
Encoding used by Client (connection): LATIN1
Encodung used by fhem: UTF8
Recommendation: Both parameters should be identical. You can adjust the usage of UTF8 connection by setting the UTF8 parameter in file './db.conf' to the right value.
Result of table 'history' check
Column width set in fhem: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 64, 'UNIT' = 32
Column width used by logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: The relation between column width in table history and the field width used in device logdb don't meet the requirements. Please make sure that the width of database field definition is equal or larger than the field width used by the module. Compare the given results.
You can change the column width in database by a statement like 'alter table history modify VALUE varchar(128);' (example for changing field 'VALUE'). The field width used by the module can be done by setting attributes 'colEvent', 'colReading', 'colValue',
Result of table 'current' check
Column width set in fhem: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 64, 'UNIT' = 32
Column width used by logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: The relation between column width in table current and the field width used in device logdb don't meet the requirements. Please make sure that the width of database field definition is equal or larger than the field width used by the module. Compare the given results.
You can change the column width in database by a statement like 'alter table current modify VALUE varchar(128);' (example for changing field 'VALUE'). The field width used by the module can be done by setting attributes 'colEvent', 'colReading', 'colValue',
Result of check 'Search_Idx' availability
'Search_Idx' exists and contains fields 'DEVICE', 'READING', 'TIMESTAMP'.
Recommendation: settings o.k.
Hi Michael,
das sind doch schonmal hilfreiche Ergebnisse, sieht alles richtig gelaufen aus. (was ist STD ??)
Zitat
Result of encoding check
Encoding used by Client (connection): LATIN1
Encodung used by fhem: UTF8
Recommendation: Both parameters should be identical. You can adjust the usage of UTF8 connection by setting the UTF8 parameter in file './db.conf' to the right value.
Das bedeutet dass in deiner DB "°C" als "°C" zu sehen sein wird wenn du zB. mit phpMyAdmin oder DbRep dir die Einträge anschaust.
Die UTF8 Unterstützung kannst du mit dem UTF8-Paramater in der Konfigdatei einschalten.
Zitat
Column width set in fhem: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 64, 'UNIT' = 32
Column width used by logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Die Spaltenbreite für 'DEVICE', 'READING', 'VALUE' ist in der DB zu klein. Füher (bis letztes Jahr irgendwann) waren das richtige Werte. Dann wurden die Defaultwerte erhöht. Es würde zu Fehlern kommen wenn Werte in den Spalten gespeichert werden sollen die diese Größen überschreiten. Entweder in der Tabelle history bzw. current die Spaltenbreite auf den jetzt akzuellen Wert setzen (best way) oder im Modul über die Attribute begrenzen.
Das wären so die Handlungsempfehlungen die aus dem Check rauspurzeln.
Prima !
Grüße
Heiko
Hallo Heiko,
STD=Standard, heisst "nichts besonders" ;)
Ja, mit der Länge hatte ich damals nichts angepasst. Utf8 latin1 habe bisher nicht bemerkt.
Werde ich jatzt wohl mal anpassen.
Schönes Wochende. Danke für deine Weiterentwicklung.
Hallo zusammen,
In der angehängten V 2.18.1 habe ich die Checks noch etwas erweitert, verfeinert und auch die Commandref bereits angepasst.
VG
Heiko
Hallo Heiko,
habe gerade V2.18.1.pm getestet und zeigt bei mir ebenfalls korrekte und brauchbare Ergebnisse an.
Kleiner gedanken noch: Sollte man beim Index ggf. auch auf den DbRep-Index prüfen, wenn das Modul DbRep genutzt wird?
Ansonsten lasse ich es jetzt mal bbei mir laufen! Herzlichen Dank,
Joe
ZitatKleiner gedanken noch: Sollte man beim Index ggf. auch auf den DbRep-Index prüfen, wenn das Modul DbRep genutzt wird?
Ja, ich schau mal ob/wie ich das hinbekomme.
LG
Heiko
Hallo zusammen,
anbei die V 2.18.2 mit der ebenfalls der DbRep-Index geprüft wird wenn dieses Modul genutzt wird.
(checkConfig ist z.Zt. verfügbar für MySQL, PostgreSQL)
Grüße
Heiko
Gaaaaanz großes Lob für configCheck!
Sehr übersichtlich und informativ!
Hat ein paar Minuten bei mir gedauert das VALUE auf 128 zu altern. 8)
Nun ist aber alles chic...
Danke Heiko für die Umsetzung dieses sehr nützlichen Features!
Gruß
Dan
Prima! Sehr schön.
Ich hätte da eine Idee (Wunsch): Maintenance Modus für DbLog
Bei größeren Datenbanken (hmm - genauer - bei den 11GB auf meiner Synology) können DB-Operationen doch schon mal mehrere Stunden dauern.
(Das letzte Anlegen eines Index hat ca 10Std. gedauert :-\ - Ursache habe ich noch nicht gefunden :-[ )
Ablauf:
CURRENT wird in einer eigenen Datenbank gehalten (bspw. SQLite).
Sobald DbLog in den Maintenance-Modus gesetzt wird, wird nur noch CURRENT zum Schreiben / Lesen verwendet.
Nach dem Deaktivieren werden die Daten aus CURRENT nach HISTORY kopiert und CURRENT wieder "normal" verwendet.
@SusisStrolch: Hast Du dir den async-Modus angesehen?
Der speichert die Daten im RAM. Das geht auch über 10 Stunden.
Um die Daten auch bei einem Stromausfall abzusichern kannst Du ja alle 10 Minuten per doif ein exportCache machen und die Daten in einer Datei zwischenspeichern.
Nun, genau das mit den 10Std ging ja leider nicht, sonst wäre ich nicht auf diese Idee gekommen.
defmod logdb DbLog ./contrib/dblog/db.conf .*:.*
attr logdb DbLogExclude .*
attr logdb DbLogType Current/History
attr logdb asyncMode 1
attr logdb cacheEvents 2
attr logdb colEvent 512
attr logdb colReading 64
attr logdb colValue 64
attr logdb event-on-change-reading CacheUsage,background_processing_time
attr logdb icon security
attr logdb room DbLog
attr logdb showNotifyTime 1
attr logdb showproctime 1
attr logdb timeout 1800
attr logdb verbose 3
Ich hatte zwei Operationen auf die Datenbank gestartet (via mysql):
CREATE INDEX Search_Idx ON `history` (DEVICE, READING, TIMESTAMP);
alter table history modify DEVICE varchar(64);
Die Erste war nach ca. 10Std fertig. Während dieser Phase wurde so ca. alle 30min (== timeout?) ein einzelner Wert weggeschrieben.
Nach dem "CREATE INDEX" wurden die gecachten Daten weitgehendst geschrieben - allerding nicht mit dem Timestamp als der Event auftrat.
Beim "alter table" wurde wieder nur alle 30s ein Wert weggeschrieben.
Daher eben die Idee mit "CURRENT", damit die Timestamps des Event beibehalten werden.
Ich verstehe das Problem nicht, in meinem Test geht es problemlos. Kannst Du details schicken?
Jo - hier ein Export aus dem fraglichen Zeitraum:
| 2017-07-13 13:11:37 | Waermepumpe_Umwaelzung | ESPEASY | Del: 0.0 Pum: 0.0 Rue: 18.6 Vor: 23.1 | Del | 0.0 Pum: 0.0 Rue: 18.6 Vor: 23.1 | |
| 2017-07-13 13:11:37 | Waermepumpe_Umwaelzung | ESPEASY | Delta: 0.0 | Delta | 0.0 | |
| 2017-07-13 13:11:37 | Waermepumpe_Umwaelzung | ESPEASY | Pumpe: 0.0 | Pumpe | 0.0 | |
| 2017-07-13 13:11:37 | Waermepumpe_Umwaelzung | ESPEASY | Ruecklauf: 18.6 | Ruecklauf | 18.6 | |
| 2017-07-13 13:11:37 | Waermepumpe_Umwaelzung | ESPEASY | Vorlauf: 23.1 | Vorlauf | 23.1 | |
| 2017-07-13 13:11:38 | ESPEasy.BME280 | ESPEASY | temperature.bme280: 22.34 | temperature.bme280 | 22.34 | °C |
| 2017-07-13 13:12:08 | LCG.Outdoor | LACROSSEGATEWAY | humidity: 65 | humidity | 65 | % |
| 2017-07-13 13:42:09 | ESPEasy.DHT22 | ESPEASY | temperature.dht22: 21.6 | temperature.dht22 | 21.6 | °C |
| 2017-07-13 14:12:09 | Verbrauch.Homeoffice | EC3000 | power: 111.8 | power | 111.8 | |
| 2017-07-13 14:42:13 | Verbrauch.Lab | EC3000 | power: 9.2 | power | 9.2 | |
| 2017-07-13 15:12:13 | LCG.Lab.BME280 | LACROSSE | dewpoint: 7.6 | dewpoint | 7.6 | |
| 2017-07-13 15:42:13 | FritzBox | FRITZBOX | user18_thisMonthTime: 12d 0:54 | user18_thisMonthTime | 12d 0:54 | |
| 2017-07-13 16:12:16 | Verbrauch.Lab | EC3000 | power: 9.3 | power | 9.3 | |
| 2017-07-13 16:42:18 | Umwaelzung_sysinfo | ESPEASY | RSSI: -88.00 | RSSI | -88.00 | |
| 2017-07-13 17:12:16 | Verbrauch.Lab | EC3000 | power: 9.3 | power | 9.3 | |
| 2017-07-13 18:11:01 | Umwaelzung_sysinfo | ESPEASY | RSSI: -86.00 | RSSI | -86.00 | |
| 2017-07-13 18:12:17 | Verbrauch.Multimedia | EC3000 | power: 22.1 | power | 22.1 | |
| 2017-07-13 18:42:18 | ESPEasy.DHT22 | ESPEASY | deltaT: 0.29 | deltaT | 0.29 | |
| 2017-07-13 19:12:19 | ESPEasy.BME280 | ESPEASY | humidity.bme280: 37.1356121977295 | humidity.bme280 | 37.1356121977295 | % |
| 2017-07-13 19:42:20 | Verbrauch.Lab | EC3000 | power: 9.4 | power | 9.4 | |
| 2017-07-13 20:12:23 | LCG.Lab.BME280 | LACROSSE | temperature: 22.7 | temperature | 22.7 | °C |
| 2017-07-13 20:42:24 | Thermostat.Esszimmer | FBDECT | temperature: 21.5 C (measured) | temperature | 21.5 | C (measured) |
| 2017-07-13 21:12:26 | Verbrauch.Lab | EC3000 | power: 9.4 | power | 9.4 | |
| 2017-07-13 21:42:26 | LCG.Garten.BME280 | LACROSSE | humidity: 60 | humidity | 60 | % |
| 2017-07-13 22:12:27 | ESPEasy.DHT22 | ESPEASY | temperature.dht22: 21.9 | temperature.dht22 | 21.9 | °C |
| 2017-07-13 22:42:26 | ESPEasy.DHT22 | ESPEASY | deltaT: 0.01 | deltaT | 0.01 | |
| 2017-07-13 23:12:28 | ESPEasy.DHT22 | ESPEASY | deltaT: -0.04 | deltaT | -0.04 | |
| 2017-07-13 23:12:28 | ESPEasy.DHT22 | ESPEASY | hum: 43.8 tem: 21.7 | hum | 43.8 tem | 21.7 |
| 2017-07-13 23:12:28 | ESPEasy.DHT22 | ESPEASY | temperature.dht22: 21.7 | temperature.dht22 | 21.7 | °C |
| 2017-07-13 23:12:28 | ESPEasy.ESP_Proto_4MB | ESPEASY | temperature.dht22: 21.7 | temperature.dht22 | 21.7 | °C |
| 2017-07-13 23:12:28 | Verbrauch.Homeoffice | EC3000 | power: 77.1 | power | 77.1 | |
| 2017-07-13 23:12:29 | ESPEasy.DS18B20_001D | ESPEASY | presence: present | presence | present | |
| 2017-07-13 23:12:29 | ESPEasy.DS18B20_001D | ESPEASY | tem: 21.87 | tem | 21.87 | |
| 2017-07-13 23:12:29 | ESPEasy_ESP_Proto_4MB_sysinfo | ESPEASY | RSS: -62.00 upt: 2232.00 | RSS | -62.00 upt | 2232.00 |
| 2017-07-13 23:12:29 | ESPEasy_ESP_Proto_4MB_sysinfo | ESPEASY | RSSI: -62.00 | RSSI | -62.00 | |
| 2017-07-13 23:12:30 | ESPEasy_ESP_Proto_4MB_sysinfo | ESPEASY | RSS: -62.00 upt: 2232.00 | RSS | -62.00 upt | 2232.00 |
| 2017-07-13 23:12:30 | ESPEasy_ESP_Proto_4MB_sysinfo | ESPEASY | presence: present | presence | present | |
| 2017-07-13 23:12:30 | ESPEasy_ESP_Proto_4MB_sysinfo | ESPEASY | uptime: 2233.00 | uptime | 2233.00 | |
| 2017-07-13 23:12:30 | LCG.Lab.BME280 | LACROSSE | T: 22.5 H: 43 D: 9.3 | T | 22.5 H: 43 D: 9.3 | |
| 2017-07-13 23:12:30 | LCG.Lab.BME280 | LACROSSE | deltaT: 0.76 | deltaT | 0.76 | |
| 2017-07-13 23:12:30 | LCG.Lab.BME280 | LACROSSE | dewpoint: 9.3 | dewpoint | 9.3 | |
| 2017-07-13 23:12:30 | LCG.Lab.BME280 | LACROSSE | temperature: 22.5 | temperature | 22.5 | °C |
| 2017-07-13 23:12:30 | Verbrauch.Lab | EC3000 | power: 9.2 | power | 9.2 | |
| 2017-07-13 23:12:30 | Verbrauch.Multimedia | EC3000 | power: 115.8 | power | 115.8 | |
| 2017-07-13 23:12:37 | Thermostat.Arbeitszimmer | FBDECT | temperature: 22.0 C (measured) | temperature | 22.0 | C (measured) |
| 2017-07-13 23:12:37 | Thermostat.Esszimmer | FBDECT | temperature: 21.5 C (measured) | temperature | 21.5 | C (measured) |
| 2017-07-13 23:12:37 | Thermostat.Wohnzimmer | FBDECT | temperature: 21.5 C (measured) | temperature | 21.5 | C (measured) |
| 2017-07-13 23:12:41 | LCG.Garten.BME280 | LACROSSE | T: 17 H: 64 D: 10.1 | T | 17 H: 64 D: 10.1 | |
| 2017-07-13 23:12:41 | LCG.Garten.BME280 | LACROSSE | dewpoint: 10.1 | dewpoint | 10.1 | |
| 2017-07-13 23:12:41 | LCG.Garten.BME280 | LACROSSE | humidity: 64 | humidity | 64 | % |
| 2017-07-13 23:12:41 | LCG.Garten.BME280 | LACROSSE | pressure: 1020 | pressure | 1020 | |
| 2017-07-13 23:12:41 | LCG.Garten.BME280 | LACROSSE | temperature: 17 | temperature | 17 | °C |
| 2017-07-13 23:12:41 | LCG.Lab.BME280 | LACROSSE | T: 22.5 H: 44 D: 9.6 | T | 22.5 H: 44 D: 9.6 | |
| 2017-07-13 23:12:41 | LCG.Lab.BME280 | LACROSSE | deltaT: 0.76 | deltaT | 0.76 | |
| 2017-07-13 23:12:41 | LCG.Lab.BME280 | LACROSSE | dewpoint: 9.6 | dewpoint | 9.6 | |
| 2017-07-13 23:12:41 | LCG.Lab.BME280 | LACROSSE | temperature: 22.5 | temperature | 22.5 | °C |
| 2017-07-13 23:12:41 | Verbrauch.Homeoffice | EC3000 | power: 76.6 | power | 76.6 | |
| 2017-07-13 23:12:41 | Verbrauch.Lab | EC3000 | power: 9.3 | power | 9.3 | |
| 2017-07-13 23:12:41 | Verbrauch.Multimedia | EC3000 | power: 115.8 | power | 115.8 | |
| 2017-07-13 23:12:44 | ESPEasy.BME280 | ESPEASY | deltaT: 0.49 | deltaT | 0.49 | |
| 2017-07-13 23:12:44 | ESPEasy.BME280 | ESPEASY | hum: 43.17 pre: 1013.37 tem: 22.23 | hum | 43.17 pre: 1013.37 tem: 22.23 | |
| 2017-07-13 23:12:44 | ESPEasy.BME280 | ESPEASY | temperature.bme280: 22.23 | temperature.bme280 | 22.23 | °C |
| 2017-07-13 23:12:44 | ESPEasy.DHT22 | ESPEASY | deltaT: -0.04 | deltaT | -0.04 | |
| 2017-07-13 23:12:44 | ESPEasy.DHT22 | ESPEASY | hum: 43.7937460661376 tem: 21.7 | hum | 43.7937460661376 tem | 21.7 |
| 2017-07-13 23:12:44 | ESPEasy.DHT22 | ESPEASY | humidity.dht22: 43.7937460661376 | humidity.dht22 | 43.7937460661376 | % |
| 2017-07-13 23:12:44 | ESPEasy.DHT22 | ESPEASY | presence: present | presence | present | |
| 2017-07-13 23:12:44 | ESPEasy.DHT22 | ESPEASY | temperature.dht22: 21.7 | temperature.dht22 | 21.7 | °C |
| 2017-07-13 23:12:44 | ESPEasy.DS18B20_001D | ESPEASY | tem: 21.87 | tem | 21.87 | |
| 2017-07-13 23:12:44 | ESPEasy.ESP_Proto_4MB | ESPEASY | temperature.bme280: 22.23 | temperature.bme280 | 22.23 | °C |
| 2017-07-13 23:12:44 | ESPEasy.ESP_Proto_4MB | ESPEASY | temperature.dht22: 21.7 | temperature.dht22 | 21.7 | °C |
| 2017-07-13 23:12:44 | ESPEasy_sonoff_01_Switch | ESPEASY | presence: absent | presence | absent | |
| 2017-07-13 23:12:44 | Hauptzaehler | ESPEASY | Gli: 194173 Pow: 2744.27 Tim: 17491 Tot: 9493 | Gli | 194173 Pow: 2744.27 Tim: 17491 T | |
| 2017-07-13 23:12:44 | Hauptzaehler | ESPEASY | Glitches: 194173 | Glitches | 194173 | |
| 2017-07-13 23:12:44 | Hauptzaehler | ESPEASY | PowerWh: 2744.27 | PowerWh | 2744.27 | |
| 2017-07-13 23:12:44 | Hauptzaehler | ESPEASY | Time: 17491 | Time | 17491 | |
| 2017-07-13 23:12:44 | Hauptzaehler | ESPEASY | Total: 9493 | Total | 9493 | |
Ab 23:12 trommeln die Werte herein, allerdings ohne den echten Event-Zeitpunkt zu reflektieren.
Das sollte eigentlich korrekt gehen, mein letzter Test dies bezüglich war erfolgreich! Ich kann es nur gerade nicht testen...
Welche dbLog-Version nutzt du? Welche Datenbank?
Hast Du jemals ein Update auf die Datenbank gemacht? (bei MySQL wird aktuell ein default für Timestamp in der
Tabelle angelegt, was hie rnicht hilfreich wäre...)
DbLog: Version 2.19.0
MariaDB5: Version 5.5.54-0079 (die aktuellste von Synology).
Update auf MariaDB10 steht an...
Ach ja - hab nochmal etwas selektiver in den Logs nachgeschaut. Mir sind tatsächlich alle Daten zwischen 13:11 und 23:xx abhanden gekommen, d.h. der Cache wurde nicht sauber weggeschrieben (sysinfo liefert alle 60s die Uptime...).
2017-07-13 13:07:56 Hauptzaehler_sysinfo ESPEASY uptime: 11710.00 uptime 11710.00
2017-07-13 13:08:56 Hauptzaehler_sysinfo ESPEASY uptime: 11711.00 uptime 11711.00
2017-07-13 13:09:57 Hauptzaehler_sysinfo ESPEASY uptime: 11712.00 uptime 11712.00
2017-07-13 13:10:57 Hauptzaehler_sysinfo ESPEASY uptime: 11713.00 uptime 11713.00
2017-07-13 23:12:44 Hauptzaehler_sysinfo ESPEASY uptime: 12315.00 uptime 12315.00
2017-07-13 23:13:47 Hauptzaehler_sysinfo ESPEASY uptime: 12316.00 uptime 12316.00
2017-07-13 23:14:46 Hauptzaehler_sysinfo ESPEASY uptime: 12317.00 uptime 12317.00
2017-07-13 23:15:45 Hauptzaehler_sysinfo ESPEASY uptime: 12318.00 uptime 12318.00
2017-07-13 23:16:45 Hauptzaehler_sysinfo ESPEASY uptime: 12319.00 uptime 12319.00
2017-07-13 23:17:46 Hauptzaehler_sysinfo ESPEASY uptime: 12320.00 uptime 12320.00
2
Öhem - und noch was...
Ich bekomme ab und an einen seltsamen State (DbLog 2.19.0) angezeigt:
STATE ��y�h�{ �ׯz{l�{h�+-���y�h���
ZitatMir sind tatsächlich alle Daten zwischen 13:11 und 23:xx abhanden gekommen, d.h. der Cache wurde nicht sauber weggeschrieben (sysinfo liefert alle 60s die Uptime...).
Das liegt an den Timeouts. Setze das Attribut timeout auf einen sehr hohen Wert (z.B. 3 Tage) wenn du derart lang laufende Aktivitäten vorhast.
Der timeout soll lediglich verhindern dass ein geforkter Prozess "ewig" im System rumhängt.
Meine MariaDB 5.5.54-0079 liegt auch auf Syno. MariaDB 10 habe ich für testdevice laufen, ohne Probs.
Übrigens .... das Anlegen eines Index dauert bei meinen 1,5 GB wenige Minuten (< 5 Min) . Bei 11GB und 10 Stunden ist das schon sehr merkwürdig. Ich habe allerdings die Parametrisierug der DB dahingehend geändert, dass sie mehr RAM verwendet.
Grüße
Heiko
ZitatMeine MariaDB 5.5.54-0079 liegt auch auf Syno. MariaDB 10 habe ich für testdevice laufen, ohne Probs.
Hast Du auch Performance-Probleme mit dem Teil?
Wie schon gesagt braucht meine FHEM-Table (11GB) >10Std. um einen Index zu generieren.
(Ich geb' zu dass ich da mal aufräumen müsste...)
Hatte ich gerade oben noch ergänzt ... Index geht bei mir recht schnell....
Nun, meine 1515+ hat 16GB Memory, und ich habe die Buffers auf 1GB gesetzt.
aria_pagecache_buffer_size = 1G
innodb_buffer_pool_size = 1G
Kannst Du mal Deine my.conf hier reinlegen, damit ich bei mir nachtrimmen kann?
Ich tue mir ein wenig schwer die korrekten Tuning-Parameter zu finden...
1 GB ist eventuell etwas viel weil das DBM dann diesen Speicher verwalten muß. Ich suche mal meine cfg noch raus. Die 415+ hatte ich auf 8 GB RAM erweitert (Standard 2 GB).
Aber hilfreicher ist wahrscheinlich wenn du das Perlscript MysqlTuner verwendest (http://mysqltuner.com/).
Das benutze ich um die DB-Einstellungen zu optimieren.
Lade es dir runter und lege es auf der Syno in ein Verzeichnis. Du kannst es dann so starten wie in dem angegebenen Beispiel. "forcemem" würden deinen 16GB Speicher entsprechen. Als "forceswap" hatte ich bei mir einen Daumenwert angegeben, müßte ich jetzt überlegen wo das herkommt ....
cd /volume1/ApplicationBackup/Backup_FHEM
perl mysqltuner.pl --forcemem 16000 --forceswap 6700 --user root --pass <Passwort>
Probier mal, ich denke damit kommst du sicherlich gut klar.
EDIT: Es kommt dann so etwas heraus:
-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.51a-24+lenny2+spu1
[OK] Operating on 32-bit architecture with less than 2GB RAM
-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 1M (Tables: 26)
[--] Data in InnoDB tables: 22M (Tables: 39)
[--] Data in MEMORY tables: 0B (Tables: 1)
[!!] Total fragmented tables: 10
-------- Performance Metrics -------------------------------------------------
[--] Up for: 11d 16h 28m 56s (8M q [8.714 qps], 597K conn, TX: 2B, RX: 1B)
[--] Reads / Writes: 93% / 7%
[--] Total buffers: 58.0M global + 2.6M per thread (100 max threads)
[OK] Maximum possible memory usage: 320.5M (15% of installed RAM)
[OK] Slow queries: 0% (0/8M)
[OK] Highest usage of available connections: 19% (19/100)
[OK] Key buffer size / total MyISAM indexes: 16.0M/1.9M
[OK] Key buffer hit rate: 99.4% (266K cached / 1K reads)
[OK] Query cache efficiency: 70.2% (4M cached / 6M selects)
[!!] Query cache prunes per day: 2132
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 586K sorts)
[!!] Temporary tables created on disk: 30% (24K on disk / 81K total)
[OK] Thread cache hit rate: 99% (1K created / 597K connections)
[!!] Table cache hit rate: 14% (64 open / 433 opened)
[OK] Open file limit used: 0% (6/1K)
[OK] Table locks acquired immediately: 100% (2M immediate / 2M locks)
[!!] InnoDB data size / buffer pool: 22.1M/8.0M
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Enable the slow query log to troubleshoot bad queries
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
query_cache_size (> 16M)
tmp_table_size (> 32M)
max_heap_table_size (> 16M)
table_cache (> 64)
innodb_buffer_pool_size (>= 22M)
-> Nicht wundern, das ist ein altes Beispiel aus meinen Aufzeichnungen..
Grüße
Heiko
Hi Joe,
kennst du noch ein besseres Hilfsmittel als das mysqltuner- Script für die Optimierung , oder wie machst du das ?
LG
Heiko
Und hier noch meine DB-Parametrisierung:
root@SDS1:~# more /var/packages/MariaDB/etc/my.cnf
[mysqld]
# 19.12.2016
innodb_buffer_pool_size = 300M
innodb_log_file_size=75M
# innodb_buffer_pool_size = 128M
innodb_additional_mem_pool_size = 24M
# innodb_additional_mem_pool_size = 64M
key_buffer_size = 10M
# key_buffer_size = 256M
sort_buffer_size = 512K
read_buffer_size = 512K
read_rnd_buffer_size = 512K
query_cache_limit = 4M
query_cache_size = 64M
max_allowed_packet = 2M
table_open_cache = 1024
key_buffer = 256M
thread_cache_size = 4
join_buffer_size = 256K
Hmm, da kommt dann folgender Vorschlag:
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
OPTIMIZE TABLE fhem.historyOLD; -- can free 4079 MB
Total freed space after theses OPTIMIZE TABLE : 4079 Mb
Variables to adjust:
query_cache_type (=0)
innodb_buffer_pool_size (>= 24G) if possible.
Hmm... naja, irgendwie nicht so toll (außer optimize table) ;)
Vielleicht nimmst du tatsächlich erst einmal meine Konfig als Ausgangspunkt und lässt das Script nach längerer DB-Laufzeit nochmal drüber laufen.
Gleich nach dem DB-Start macht das keinen Sinn. Es sollte etwas Zeit vergangen sein, damit sich die DB/der Memory eingeschwungen hat.
ACHTUNG: innodb_log_file_size nicht einfach ändern ! lass diesen Parameter bei dir erstmal wie er ist.
ZitatACHTUNG: innodb_log_file_size nicht einfach ändern ! lass diesen Parameter bei dir erstmal wie er ist.
Jo - da hatte ich mal ne leidvolle Erfahrung, weil mir beim Update meine optimierte my.cnf verloren ging...
Wenn Du experimentierfreudig bist, versuche mal die Engine umzustellen auf Aria.
Gerade auf solchen Kisten sollte das deutlich besser funktionieren....
Läuft seit längerem schon auf Aria - die Innodb ist disabled...
Hier noch einige Details von mysqltuner:
-------- Storage Engine Statistics -----------------------------------------------------------------
[--] Status: +ARCHIVE +Aria +BLACKHOLE +CSV +FEDERATED -InnoDB +MEMORY +MRG_MYISAM +MyISAM +PERFORMANCE_SCHEMA
[--] Data in MyISAM tables: 4K (Tables: 4)
[--] Data in Aria tables: 36G (Tables: 81)
[OK] Total fragmented tables: 0
-------- Performance Metrics -----------------------------------------------------------------------
[--] Up for: 1h 59m 20s (10K q [1.491 qps], 485 conn, TX: 87M, RX: 998K)
[--] Reads / Writes: 69% / 31%
[--] Binary logging is disabled
[--] Physical Memory : 15.7G
[--] Max MySQL memory : 11.3G
[--] Other process memory: 922.6M
[--] Total buffers: 10.6G global + 3.2M per thread (100 max threads)
[--] P_S Max memory usage: 376M
[--] Galera GCache Max memory usage: 0B
[OK] Maximum reached memory usage: 11.0G (70.05% of installed RAM)
[OK] Maximum possible memory usage: 11.3G (71.99% of installed RAM)
[OK] Overall possible memory usage with other process is compatible with memory available
[OK] Slow queries: 0% (64/10K)
[OK] Highest usage of available connections: 4% (4/100)
[OK] Aborted connections: 0.82% (4/485)
[OK] Query cache is disabled by default due to mutex contention on multiprocessor machines.
[OK] Sorts requiring temporary tables: 10% (17 temp sorts / 159 sorts)
[OK] No joins without indexes
[OK] Temporary tables created on disk: 5% (101 on disk / 1K total)
[OK] Table cache hit rate: 122% (134 open / 109 opened)
[OK] Open file limit used: 3% (308/8K)
[OK] Table locks acquired immediately: 100% (15K immediate / 15K locks)
-------- Performance schema ------------------------------------------------------------------------
[--] Performance schema is enabled.
[--] Memory used by P_S: 376.2M
[--] Sys schema isn't installed.
-------- ThreadPool Metrics ------------------------------------------------------------------------
[--] ThreadPool stat is enabled.
[--] Thread Pool Size: 4 thread(s).
[--] Using default value is good enough for your version (5.5.54-MariaDB)
-------- MyISAM Metrics ----------------------------------------------------------------------------
[!!] Key buffer used: 18.2% (97M used / 536M cache)
[OK] Key buffer size / total MyISAM indexes: 512.0M/103.0K
[!!] Read Key buffer hit rate: 80.0% (5 cached / 1 reads)
-------- AriaDB Metrics ----------------------------------------------------------------------------
[--] AriaDB is enabled.
[OK] Aria pagecache size / total Aria indexes: 10.0G/9.3G
[OK] Aria pagecache hit rate: 99.8% (100M cached / 225K reads)
-------- InnoDB Metrics ----------------------------------------------------------------------------
[--] InnoDB is disabled.
[!!] InnoDB Storage engine is disabled. InnoDB is the default storage engine
-------- TokuDB Metrics ----------------------------------------------------------------------------
[--] TokuDB is disabled.
-------- Galera Metrics ----------------------------------------------------------------------------
[--] Galera is disabled.
-------- Replication Metrics -----------------------------------------------------------------------
[--] Galera Synchronous replication: NO
[--] No replication slave(s) for this server.
[--] This is a standalone server.
Ein "CREATE INDEX Reading_Time_Idx" läuft jetzt schon seit 2h...
Jetzt habe ich den Search_Idx gelöscht und mit
CREATE INDEX Search_Idx ON `history` (DEVICE, READING, TIMESTAMP) USING BTREE
anlegen lassen.
Laufzeit war rund 3 Min. bei 6.738.467 Datensätzen , rund 1,5 GB.
MySQL lieferte ein leeres Resultat zurück (d.h. null Datensätze). (Die Abfrage dauerte 180.5843 Sekunden.)
Die CPU der Syno war dabei ca. 20% durch MariaDB 5 ausgelastet, aber das Volume während dieser Zeit fast 100%. Das könnte bei dir ein Flaschenhals sein. Die CPU (4 Cores) ist bei meiner und deiner Syno identisch glaube ich.
Ich habe auch noch InnoDB. Auf MariaDB 10, auf die ich nach und nach umstelle, setze ich dann auch Aria ein.
EDIT: Also Daten sind rund 1GB, der Rest ist dann die Datenmenge für den Index !
Grüße
Heiko
root@DiskStation:/var/packages/MariaDB/target/mysql# time dd if=ibdata1 of=/dev/null bs=16M
1076+1 records in
1076+1 records out
18062770176 bytes (18 GB) copied, 166.295 s, 109 MB/s
Viel schneller bekomm' ichs nicht hin...
Meine ist ca. 1/3 schneller:
root@SDS1:/var/packages/MariaDB/target/mysql# time dd if=ibdata1 of=/dev/null bs=16M
245+1 records in
245+1 records out
4112515072 bytes (4.1 GB) copied, 30.8802 s, 133 MB/s
Das kann m.M. nach doch nicht der Grund für derart drastische Unterschiede bei der Indexerstellungsgeschwindigkeit sein ....
Was sagt denn deine CPU ?
Die eine CPU mit dem mysqld pendelt um die 99%. Gesamtsystem pendelt zwischen 40% und 60%.
ZitatDie eine CPU mit dem mysqld pendelt um die 99%
Jetzt habe ich lange darüber nachgedacht wieso deine CPU-Auslastung gegenüber meiner Beobachtung so hoch ist und wahrscheinlich den Bottleneck darstellt.
Könnte es sein, dass du Filesystemverschlüsselung auf der Syno benutzt ?
Nope, ich verwende auch keine verschlüsselten Partitionen.
Volume1 (ext4) und Volume2 (btrfs) sind beide RAID5, (4x 6TB), Volume3 ist ein Single Volume (3TB, ext4).
Die Datenbank-Durchsätze sind auf allen Volumes gleich schlecht (in der Vergangenheit schon getestet).
So - hatte nochmal die Sache mit dem Cache ausprobiert.
Gestern nachmittag (mit den lt. mysqltuner "optimierten" Werten):
CREATE INDEX Reading_Time_Idx ON `history` (READING, TIMESTAMP) USING BTREE;
Query OK, 102681848 rows affected, 1 warning (12 hours 16 min 31.49 sec)
Records: 102681848 Duplicates: 0 Warnings: 1
Ergebnis in der Datenbank:
('2017-07-14 14:40:54', 'Hauptzaehler_sysinfo', 'ESPEASY', 'uptime: 13242.00', 'uptime', '13242.00', ''),
('2017-07-14 14:41:54', 'Hauptzaehler_sysinfo', 'ESPEASY', 'uptime: 13243.00', 'uptime', '13243.00', ''),
('2017-07-14 14:42:55', 'Hauptzaehler_sysinfo', 'ESPEASY', 'uptime: 13244.00', 'uptime', '13244.00', ''),
('2017-07-15 01:02:10', 'Hauptzaehler_sysinfo', 'ESPEASY', 'uptime: 13863.00', 'uptime', '13863.00', ''),
('2017-07-15 01:03:10', 'Hauptzaehler_sysinfo', 'ESPEASY', 'uptime: 13864.00', 'uptime', '13864.00', ''),
('2017-07-15 01:04:11', 'Hauptzaehler_sysinfo', 'ESPEASY', 'uptime: 13865.00', 'uptime', '13865.00', '');
Es fehlen also genau die 12 Stunden...
ZitatEs fehlen also genau die 12 Stunden...
Ich gebe zu dass es mich sehr irritiert und ich es auch nicht nachvollziehen kann.
Gibt es denn irgendwelche Fehlermeldungen im Log ?
Nur nochmal zur Funktionsweise ........
Im asynchronen Betrieb werden die Events im Cache (RAM) gesammelt und alle X Sekunden bzw. bei Überschreiten der Anzahl "cacheLimit" wird versucht diese Daten in die DB zu schreiben. Kann nicht auf die DB/Tabelle zugegriffen werden bleiben die Daten im Cache und bauen sich immer weiter auf. Man sieht das schön mit "set ... listCache".
Gleichzeitig wird im state entweder eine Fehlermeldung (wenn z.B. die DB nicht verfügbar ist) angezeigt oder, und das ist wichtig, die Meldung "Commit already running - resync at NextSync" angezeigt wenn z.B. die Tabelle history gesperrt ist.
Mit jedem weiteren Event baut sich der Cache dann weiter auf ...
Hast du während der Indexerstellung das mal verfolgt und kannst es bestätigen ?
Sobald die DB wieder da ist bzw. die Tabellensperre weg ist wird beim nächsten Synclauf der gesammte Cache in die DB weggeschrieben. Das funktioniert bei mir z.B. während der Backupphasen mit Synology Hyper Backup ausgezeichnet (dabei wird die DB gestoppt).
Momentan simuliere ich gerade einen Fehlerzustand indem ich das PW des Benutzers in der DB falsch gesetzt habe. Dadurch kommt im state des Moduls:
DBI connect('database=fhemtest;host=192.168.2.10;port=3307','fhemtest',...) failed: Access denied for user 'fhemtest'@'fhemtest.myds.me' (using password: YES) at ./FHEM/93_DbLog.pm line 1683.
Auch im Log tauchen entsprechende Meldungen auf:
2017.07.15 20:10:18.071 2: DbLog LogDB - Error: DBI connect('database=fhemtest;host=192.168.2.10;port=3307','fhemtest',...) failed: Access denied for user 'fhemtest'@'fhemtest.myds.me' (using password: YES) at ./FHEM/93_DbLog.pm line 1683.
So ist es auch richtig in diesem Fall.
Wichtig ist, das sich der Cache aufbaut. Das macht er und enthält inzwischen 650 Einträge (cachUsage) seit 19:50.
Ich lasse das noch ein bisschen so laufen und setze dann das PW wieder richtig damit die Verbindung funktioniert. Dann wird der Cache in der Gesamtheit in die DB geschrieben. Das kontrolliere ich nachher.
Vielleicht kannst du es in dieser Form auch nochmal nachvollziehen.
Zu deiner mangelhaften Performance auf der Syno fällt mir momentan nichts mehr ein. Nicht das es mit dem von dir beschriebenen Problem einen Zusammenhang gibt den wir noch nicht sehen.
Grüße
Heiko
So, nun ist DbLog über eine Stunde in diesem fehlerhaften Zustand gelaufen (19:50-21:08) und es haben sich rund 1800 Einträge im Cache gesammelt.
Hier ein Ausschnitt:
245566 => 2017-07-15 20:10:18|SMA_Energymeter|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0045|Bezug_WirkP_Zaehler_Diff|0.0045|
245567 => 2017-07-15 20:10:18|MySTP_5000|SMAINVERTER|etotal: 16151.796|etotal|16151.796|
245568 => 2017-07-15 20:10:33|sysmon|SYSMON|stat_cpu_percent: 0.19 0.00 0.14 99.64 0.03 0.00 0.00|stat_cpu_percent|0.19 0.00 0.14 99.64 0.03 0.00 0.00|
245569 => 2017-07-15 20:11:18|SMA_Energymeter|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0046|Bezug_WirkP_Zaehler_Diff|0.0046|
245570 => 2017-07-15 20:11:18|MySTP_5000|SMAINVERTER|etotal: 16151.798|etotal|16151.798|
245571 => 2017-07-15 20:11:33|sysmon|SYSMON|swap: Total: 1293.00 MB, Used: 26.13 MB, 2.02 %, Free: 1266.86 MB|swap|Total: 1293.00 MB, Used: 26.13 MB, 2.02 %, Free: 1266.86 MB|
245572 => 2017-07-15 20:12:19|SMA_Energymeter|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0049|Bezug_WirkP_Zaehler_Diff|0.0049|
245573 => 2017-07-15 20:12:19|MySTP_5000|SMAINVERTER|etotal: 16151.8|etotal|16151.8|
245574 => 2017-07-15 20:12:33|sysmon|SYSMON|ram: Total: 2010.07 MB, Used: 339.73 MB, 16.90 %, Free: 1670.35 MB|ram|Total: 2010.07 MB, Used: 339.73 MB, 16.90 %, Free: 1670.35 MB|
245575 => 2017-07-15 20:13:05|Rep.Show.DbSize|DBREP|state: running|state|running|
245576 => 2017-07-15 20:13:05|Sonnenstrom|SHM|state: disabled|state|disabled|
245577 => 2017-07-15 20:13:19|SMA_Energymeter|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0047|Bezug_WirkP_Zaehler_Diff|0.0047|
245578 => 2017-07-15 20:13:20|MySTP_5000|SMAINVERTER|etotal: 16151.803|etotal|16151.803|
245579 => 2017-07-15 20:13:33|sysmon|SYSMON|eth0_diff: RX: 1.19 MB, TX: 0.16 MB, Total: 1.35 MB|eth0_diff|RX: 1.19 MB, TX: 0.16 MB, Total: 1.35 MB|
245580 => 2017-07-15 20:14:05|Sonnenstrom_Relative|SHMFORECASTRELATIVE|state: disabled|state|disabled|
245581 => 2017-07-15 20:14:19|SMA_Energymeter|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0046|Bezug_WirkP_Zaehler_Diff|0.0046|
245582 => 2017-07-15 20:14:20|MySTP_5000|SMAINVERTER|etotal: 16151.805|etotal|16151.805|
245583 => 2017-07-15 20:14:33|sysmon|SYSMON|eth0_diff: RX: 2.35 MB, TX: 0.27 MB, Total: 2.62 MB|eth0_diff|RX: 2.35 MB, TX: 0.27 MB, Total: 2.62 MB|
245584 => 2017-07-15 20:15:12|MyWetter|WEATHER|wind: 7|wind|7|km/h
245585 => 2017-07-15 20:15:20|SMA_Energymeter|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0046|Bezug_WirkP_Zaehler_Diff|0.0046|
245586 => 2017-07-15 20:15:20|MySTP_5000|SMAINVERTER|etotal: 16151.807|etotal|16151.807|
245587 => 2017-07-15 20:15:33|sysmon|SYSMON|loadavg: 0.03 0.04 0.00|loadavg|0.03 0.04 0.00|
245588 => 2017-07-15 20:16:19|SMA_Energymeter|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0042|Bezug_WirkP_Zaehler_Diff|0.0042|
245589 => 2017-07-15 20:16:20|MySTP_5000|SMAINVERTER|etotal: 16151.81|etotal|16151.81|
245590 => 2017-07-15 20:16:33|sysmon|SYSMON|loadavg: 0.01 0.03 0.00|loadavg|0.01 0.03 0.00|
245591 => 2017-07-15 20:17:19|SMA_Energymeter|SMAEM|Bezug_WirkP_Zaehler_Diff: 0.0038|Bezug_WirkP_Zaehler_Diff|0.0038|
245592 => 2017-07-15 20:17:20|MySTP_5000|SMAINVERTER|etotal: 16151.812|etotal|16151.812|
245593 => 2017-07-15 20:17:33|sysmon|SYSMON|stat_cpu_percent: 0.28 0.00 0.15 99.54 0.03 0.00 0.00|stat_cpu_percent|0.28 0.00 0.15 99.54 0.03 0.00 0.00|
Nun habe ich das PW in der DB wieder korrekt gesetzt und die DB-Verbindung konnte sich wieder aufbauen.
Die im Cache gespeicherten Datensätze wurden in die DB geschrieben.
Z.B. den Satz rausgepickt "245584 => 2017-07-15 20:15:12|MyWetter|WEATHER|wind: 7|wind|7|km/h " und als Screenshot aus phpMyAdmin angehängt.
Hallo zusammen,
wegen dem von SusisStrolch hier https://forum.fhem.de/index.php/topic,74234.0.html#msg659694 beschriebenen Sachverhalt habe ich im Modul kleine Änderungen vorgenommen um bei einem state-Event auch das Reading "state" mit im Event zu erhlalten.
Anbei die V2.20.0 die ich euch bitte, insbesondere SusisStrolch, zu testen ob bei euch ebenfalls alles wie gewohnt sauber funktioniert.
VG
Heiko
Die Möglichkeit zum configCheck finde ich super!!
Zu folgender Ausgabe habe ich allerdings Fragen:
Result of encoding check
Encoding used by Client (connection): LATIN1
Encoding used by fhem: UTF8
Recommendation: Both encodings should be identical. You can adjust the usage of UTF8 connection by setting the UTF8 parameter in file '/opt/fhem/dblog/sqldb.conf' to the right value.
Unter Linux verwende ich de_DE.UTF-8.
Die DB habe ich angelegt mit
CREATE DATABASE `fhem` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
Allerdings ohne Parameter ,,utf8 => 1".
In /etc/mysql/my.cnf habe ich nichts definiert bzgl. character-set.
Frage 1:
Vielleicht weißt du ja aus dem Stegreif (ohne einen Blick in die Glaskugel zu werfen ;)), woher LATIN1 kommt, obwohl ich zumindest an 2 Stellen explizit UTF8 definiert habe?
Frage 2:
Nur den Parameter ,,utf8 => 1" in der Config-Datei zu definieren, recht vermutlich nicht. Muss die DB neu angelegt werden? Reicht ein Export/Import? Gibt es noch etwas, was ich beim Wechseln der Codierung berücksichtigen sollte?
LG
Holger
Bin heute zeitlich eingeschränkt. Schaue, ob ich heut Abend testen kann.
Noch ne Frage zu Deiner my.cnf:
Ist das die Einzige oder die, die von der mitgelieferten inkludiert wird?
Hi Holger,
ja, deine Fragen kann ich beantworten denke ich.
Die Angabe zu Encoding aus dem configCheck bezieht sich tatsächlich auf die Connection zwischen dem Client (FHEM) und der Datenbank. Ich will nicht lügen, aber es gibt glaube ich bis zu 10 Stellen im MySQL die sich auf Zeichensätze beziehen. Die meisten davon werden aus der Servereinstellung übernommen. Wenn du DbRep einsetzt, kannst du dir mit "get ... dbvars" einen Überblick über die Parameter mit uft8-Einstellungen verschaffen (siehe Screenshot).
Also konkret ist es so dass das Perl-DBI-Interface im Standard beim Verbindungsaufbau KEIN UTF8 verwendet (warum man das auch immer so gemacht hat). Deswegen muß ich bei Verbindungsaufbau einen Parameter mitgeben sofern UTF8 gewünscht ist.
Das passiert über die Angabe ,,utf8 => 1" in der Config-Datei und ist insofern auch ausreichend wenn man ansonsten auch so wie von dir beschrieben für die DB bzw. Tabelle UTF8 benutzt (ist sicherlich der Standard).
JoeAllb verzichtet z.B. bewußt auf UTF8 wegen Platzbedarf bzw. Performance, glaube ich. Vllt. kann er noch etwas dazu sagen.
LG
Heiko
ZitatIst das die Einzige oder die, die von der mitgelieferten inkludiert wird?
Das ist die inkludierte. In letzter Zeit hat Syno etliche Updates (inkl. MariaDB 10) ausgeliefert. Ich muß mich mal wieder damit beschäftigen ob sich bezüglich der DB-Konfiguration dadurch Änderungen ergeben haben. Habe auch einfach zu wenig Zeit ;)
Hallo SusisStrolch,
jetzt habe ich mal den Aufwand betrieben und eine meiner Testdatenbanken über Backup/ Restore (mit DbRep dumpMySQL serverSide, restoreMySQL) auf ca. 6GB Größe (nur Daten ! ) aufgepumpt.
Vor dieser Maßnahme habe ich alle Indizes gelöscht damit die Importe schnell laufen.
Ausgangspunkt war nun eine 6 GB history Tabelle mit 56 Mio Datensätzen.
Im phpMyadmin habe ich dann die Indexerstellung:
CREATE INDEX Search_Idx ON `history` (DEVICE, READING, TIMESTAMP) USING BTREE;
gestartet. Das war 12:52.
Nach ca. 20 Minuten ! war der Prozess 13:11 fertig.
Während dieser Zeit hat sich der Cache aufgebaut (ca. 800 Einträge) sowie im state kam die erwartete Mitteilung "Commit is already running ..." (siehe Screenshot).
Nachdem der Index erstellt war (Indexgröße 2,4 GB), wurden genau wie bei meinem anderen Test die Cacheeinträge in die DB geschrieben.
Die Test-DB ist nun insgesamt 8,3GB groß und kommt deinem Aufbau schon recht nahe.
Die Performance ist nach wie vor vollkommen positiv zu bewerten entgegen deinen beschriebenen 12H .
LG
Heiko
Hallo Heiko,
danke für deine Ausführungen. Sie haben mich auf den richtigen Weg gebracht.
Kleiner Hinweis jetzt: die Ausgabe der Variablen in DBREP zeigt nur die globalen Einstellungen. Da ich die DB aber bereits mit UTF8 definiert hatte, war die Ausgabe von DBREP mMn nicht ganz korrekt.
Ich habe mir die Variablen dann mit DBREP, direkt von der MySQL-Console und mittels Windows Programm HeidiSQL angeschaut. Die Unterschiede habe ich mal als HC angehängt.
Etwa verwirrt mich noch die Angabe von utf8mb4 in HeidiSQL, obwohl die Console etwas anderes ausgibt.
Ich habe jetzt in my.cnf (nach Hinweisen aus dem Netz) folgendes eingefügt:
skip-character-set-client-handshake
collation-server=utf8_general_ci
character-set-server=utf8
Jetzt habe ich definitiv UTF8. Da das jetzt der Standard ist, müsste ich doch eigentlich auf den Parameter utf8 => 1, verzichten können (oder habe ich mir mit ,,skip-character-set-client-handshake" ein Eigentor geleistet)?
LG
Holger
Hi Holger,
ZitatKleiner Hinweis jetzt: die Ausgabe der Variablen in DBREP zeigt nur die globalen Einstellungen.....
Guter Hinweis, danke. Vllt. kann ich die Abfrage etwas verbessern. Schaue ich mal.
ZitatJetzt habe ich definitiv UTF8. Da das jetzt der Standard ist, müsste ich doch eigentlich auf den Parameter utf8 => 1, verzichten können (oder habe ich mir mit ,,skip-character-set-client-handshake" ein Eigentor geleistet)?
Also meiner Meinung nach solltest du "utf8 => 1" weiterhin setzen und ,,skip-character-set-client-handshake" verzichten obwohl es eventuell auf das Gleiche rauskommt (müsste man testen). Wenn ich das richtig im Netz lese, wird dieser Parameter vor allem eingesetzt wenn man das alte Verhalten von MySQL 4.0 bei einem Upgrade behalten will. Wollen wir ja nicht ;)
Außerdem werte ich den Parameter "utf8 => 1" über den DbLog-Hash auch in den DbRep-Devices für bestimmte Operation wie Import/Export aus und setze dementsprechend die Verbindungsvariablen.
LG
Heiko
Du hast mich überzeugt - Danke
LG
Holger
Und noch ein besonderes Dankeschön für deine gute und ausführliche Dokumentation!
Gern geschehen :)
Danke dir auch für den Tipp bzgl. DbRep -> habe ich schon geändert und eingecheckt. Ist dann mogen früh im Update.
LG
Heiko
@SUSISTROLCH,
kann es sein, dass Du viele doppelten Einträge hast, also zur selben Uhrzeit einträge mit den selben Device-Readings-Kombinationen?
Ich denke mich erinnern zu können, dass in dieser Konstellation MariaDB5 beim Index erstellen selbst bei mir auch langsam war....
Ich hatte das dann bereinigt in dem ich einen primary Key statt dem normalen Index nutze. Seither und seit dem Update auf MariaDB 10
läuft meine Indexerstellung ähnlich performant wie die von Heiko. Ob diese Maßnahmen jedoch ausreichen kann ich nicht sagen, da ich es(den langsamen Index) nicht mehr reproduzieren kann.
@JoeALLb, kann ich ausschließen:
--
-- Indizes für die Tabelle `history`
--
ALTER TABLE `history`
ADD PRIMARY KEY (`DEVICE`,`READING`,`TIMESTAMP`),
ADD KEY `DbLog_Group` (`TIMESTAMP`,`DEVICE`,`READING`),
ADD KEY `Search_Idx` (`DEVICE`,`READING`,`TIMESTAMP`),
Ich zieh' mir heut mal die Daten in eine MariaDB10, um auszuschließen dass ich mir in der Vergangenheit ein Problem mit meiner alten Datenbank eingefangen habe.
aber dein PK und "Search_Idx" sind ja redundant, hast Du das nur für einen Test so angelegt?
Den PK hatte ich schon, den SearchKey habe ich nach "Anraten" von "check Config" angelegt.
Der PK ersetzt "Search_Idx", du solltest "Search_Idx" löschen!
Ja, guter Hinweis !
Ich prüfe in configCheck das Vorhandensein des Standardindex. Wenn der Nutzer einen anderen Index erstellt hat der diesen ersetzt, braucht es den Standardindex natürlich nicht.
Werde den Erläuterungstext dahingehend ändern dass der Nutzer darauf hingewiesen wird.
LG
Heiko
ZitatAnbei die V2.20.0 die ich euch bitte, insbesondere SusisStrolch, zu testen ob bei euch ebenfalls alles wie gewohnt sauber funktioniert.
Die Einträge tauchen nun sauber mit dem Reading "state" auf.
Vielen Dank für die schnelle Korrektur.
Wg. der Performance-Sache bin ich noch immer dran - weiß einfach nicht wo es da noch klemmen kann.
Den doppelten Index schließe ich mal als Ursache für diese extremen Unterschiede aus.
Momentan importiere ich in die MariaDB10, um zu sehen ob sich das System da genau so verhält.
Danke für die Rückmeldung !
Ist sicherlich ein guter Weg nach dem Ausschlußverfahren. Eventuell lohnt es sich ein Ticket bei Syno aufzumachen. Es sind doch erhebliche Unterschiede in Performance feststellbar.
LG
Heiko
Hallo zusammen,
die hier angehängte DbLog-Version 2.21.0 enthält neben den Anpassungen der 2.20.0 noch erweiterte Erläuterungen im configCheck sowie eine Heraufsetzung des Standard-Timeouts im asynchronen Betrieb auf 86400s.
Damit sollen potentielle Fehlermöglichkeiten bei lang laufenden Prozessen großer Datenbanken (z.B. Indexerstellung) vermieden werden.
Wer bereits das Attribut "timeout" auf einen eigenen Wert gesetzt hat und damit zufrieden ist kann es natürlich so lassen.
VG
Heiko
Kann das sein, dass ihr eure AriaDB mit
ENGINE=Aria ... ROW_FORMAT=PAGE TRANSACTIONAL=0
angelegt habt?
Ich importiere momentan mit "LOAD DATA INFILE..." in eine Test-DB mit TRANSACTIONAL=0.
Die CPU-Last geht auf ~300% hoch (statt bisher ca. 100%), die Fortschrittsanzeige scheint mir auch deutlich flotter zu sein...
Also bei mir zumindest ist das nicht der Fall. Die beschriebenen Tests habe ich alle noch mit der Engine InnoDb auf MariaDb5 durchgeführt. Das ist meine bisherige "alte" Datenbank. Umzug auf MariaDB 10 mit Aria-Engine kommt erst noch.
Ok... dann werde ich mal mit InnoDB ausprobieren...
So - hier mal mein "Abschlussbericht"...
Das Performance-Problem kommt tatsächlich daher, dass ich "Aria" als Engine verwende.
Die Operationen mit InnoDB sind min. Faktor 10 schneller, d.h. der Index war mit meinen Daten innerhalb eine Stunde aufgebaut.
Anlegen der InnoDB (READ INTO...), ohne Keys / Index, dauerte knappe 2 Std.
Wenn ich die beiden so vergleiche, finde ich das Verhältnis Daten zu Index bei der InnoDB etwas heftig:
| Datensätze | Daten | Index |
Aria | 103.856.256 | 8,6 GiB | 5,7 GiB |
InnoDB | 99.833.927 | 9,7 GiB | 11,8 GiB |
Die InnoDB wurde mit
PRIMARY KEY (`DEVICE`,`READING`,`TIMESTAMP`),
KEY `Report_Idx` (`TIMESTAMP`,`READING`) USING BTREE,
KEY `Reading_Time_Idx` (`READING`,`TIMESTAMP`) USING BTREE,
KEY `Search_Idx` (`DEVICE`,`READING`,`TIMESTAMP`) USING BTREE
Aria (durch meine Spielereinen) mit
PRIMARY KEY (`DEVICE`,`READING`,`TIMESTAMP`),
KEY `DbLog_Group` (`TIMESTAMP`,`DEVICE`,`READING`),
KEY `Search_Idx` (`DEVICE`,`READING`,`TIMESTAMP`),
KEY `Reading_Time_Idx` (`READING`,`TIMESTAMP`) USING BTREE,
KEY `Test_Idx` (`DEVICE`,`READING`,`TIMESTAMP`)
erstellt.
So - hier noch ein Code-Snippet, mit dem man "auf die Schnelle" alle Einträge aus der Datenbank werfen kann, die in der Kombination "DEVICE,READING" nicht häufiger als 10x auftauchen...
CREATE TEMPORARY TABLE tmptable
SELECT `TIMESTAMP`, COUNT(*) as Nr, `DEVICE`, `READING`
FROM `fhem`.`historyNew`
GROUP BY `DEVICE`,`READING`;
DELETE `h` FROM `fhem`.`historyNew` AS h
INNER JOIN `tmptable` AS t
ON `t`.Nr < '10' AND `h`.`TIMESTAMP` = `t`.`TIMESTAMP` AND `h`.`DEVICE` = `t`.`DEVICE` AND `h`.`READING` = `t`.`READING`;
Query OK, 1822 rows affected (7.68 sec)
und - als Vergleich - auf der Aria:
Query OK, 2231 rows affected (45.53 sec)
Hi,
Danke für die Info !
Dieser Unterschied ist tatsächlich unglaublich !
Dann muss ich auch noch einmal meinen Ansatz überdenken beim Switch zu Maria 10 ebenfalls zu Aria zu wechseln.
Interessant wäre noch die Erfahrung von Joe, denn er hat Aria im Einsatz und kommt auf ähnliche Performance wie ich mit InnoDb.
Schönes Snippet :)
VG
Heiko
Zitat von: DS_Starter am 20 Juli 2017, 12:44:28
Interessant wäre noch die Erfahrung von Joe, denn er hat Aria im Einsatz und kommt auf ähnliche Performance wie ich mit InnoDb.
Da wären natürlich Konfiguration und Plattform des SQL-Servers interessant...
Hab' jetzt noch mal ein wenig auf die Read-Performance geschaut.
Test: MariaDB10, query: count(TYPE) from history
Aria: 3 min 35.80 sec
InnoDB: 6 min 28.39 sec
Aus Sicht der Datenmenge und der Lese-Performance ist die Aria nicht schlecht. Und so häufig werden wohl auch keine Idx neu aufgebaut.
Evtl. sollte man die Notwendigkeit der TRANSACTIONAL-Option noch einmal überdenken (die ist per default aktiviert).
Dasselbe Testscenario habe ich jetzt bei meiner MariaDB10 ausgeführt und bekomme eine genau gegensätzliche Read-Performance.
In meinem Test ist InnoDB etwas schneller als Aria.
Zitat
Maria10 (Größe Daten ca. 600MB)
Aria-Engine:
select count(TYPE) from history -> 6199328 insgesamt, Die Abfrage dauerte 16.1305 Sekunden.
InnoDB-Engine:
select count(TYPE) from test -> 5780060 insgesamt, Die Abfrage dauerte 14.2124 Sekunden.
Wenn ich etwas mehr Zeit habe, versuche ich das Ganze nochmal mit größeren Datenmengen.
EDIT:
Bei größeren Tabellen drehen sich die Verhältnisse offensichtlich zu Gunsten von Aria:
Zitat
Zitat
MariaDB 5 (Größe ca. 5,5 GB)
Aria-Engine:
select count(TYPE) from test -> 55649759 insgesamt, Die Abfrage dauerte 87.3970 Sekunden.
InnoDB-Engine:
select count(TYPE) from history -> 52078133 insgesamt, Die Abfrage dauerte 154.3552 Sekunden.
ZitatBei größeren Tabellen drehen sich die Verhältnisse offensichtlich zu Gunsten von Aria:
Das wäre jetzt meine Frage gewesen - 500MB vs. >> nGB
Kannst Du mal deine 5GB Datenbank in ne Aria importieren?
Mich würde da der Durchsatz beim Import interessieren...
Ich komme bei den ~8GB auf ca 1GB/Stunde.
Die Platten der Syno schlafen hierbei - da geht max. 1MB/s rüber - ziemlich konstant.
Wenn ich die InnoDB in der Größe anlege, kommen häufiger Peaks von >20MB/s.
Kann ich machen. Mit SQL-Export / Import ? Sonst nehme ich nämlich Export to / Import from File.
Ich hatte es mit
SELECT * INTO OUTFILE 'history.dat'
-> FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
-> LINES TERMINATED BY '\n'
-> FROM `fhem`.`history`;
LOAD DATA INFILE './history.dat'
INTO TABLE `fhem`.`historyNew`
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY '\n';
durchgeführt, weil laut der MySQL-Doku die wenigsten Reibungsverluste beim Inport auftreten sollten.
Bei der InnoDB sieht man, dass er erst im /tmp (tmpfs) die Zwischendateien anlegt.
Das knallt nämlich, wenn df(/tmp) < sizeof(db)...
Mit Partitionen kommt man dann darum herum...
So, hier ist das Ergebnis.
Export (into file) aus InnoDB:
Query OK, 55651919 rows affected (8 min 2.57 sec)
Der Import in die Aria-Tabelle:
Query OK, 55651919 rows affected (13 min 38.07 sec)
Größe der DB rund 5,5 GB. Wenn ich mich nicht verrechnet habe entspricht das einem Durchsatz von ca. 22 GB/h.
Die CPU war dabei ca. 20% vom mysqld belegt, aber das Volume zeigte eine Auslastung zw. 77-99% (hatte ich schon bei einem meiner anderen Tests).
Ich fass es nicht.
Was für eine DS hast du?
Ich habe eine 415+. Die dürfte eigentlich die gleiche Maschine wie deine sein, außer das meine nur 4 Slots hat.
EDIT: Platten sind 3 x WD Red 3GB im Synology SHR (Raid 5) Verbund
Ach so .... ich habe meine DS auf 8 GB RAM hochgerüstet. Normal hat dieser Typ nur 2GB.
Gestern hatte ich den Import-Test auf MariaDB 5 gemacht und ihn nun auf meiner MariaDB 10-Installation in eine Aria-Tabelle wiederholt.
Das Ergebnis ist das gleiche:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 1306
Server version: 10.0.30-MariaDB Source distribution
Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> LOAD DATA CONCURRENT INFILE 'history.dat' IGNORE INTO TABLE fhemtest.test FIELDS TERMINATED BY ',' ENCLOSED BY '\"' LINES TERMINATED BY '\n';
Query OK, 55687497 rows affected, 65535 warnings (13 min 28.11 sec)
Records: 55687497 Deleted: 0 Skipped: 0 Warnings: 1180618
Es werden wiederum ca. 13 Min für die ~5 GB benötigt. Das besondere ist, dass ich Maria 10 in keinster Weise angepasst habe. Es ist noch "jungfräulich" so wie Syno das Package installiert. Die Standardkonfiguration befindet sich in /usr/local/mariadb10/etc/mysql/my.cnf
Ein
SELECT count(TYPE) from test
dauert (55687497 insgesamt, Die Abfrage dauerte 46.4177 Sekunden.)
Hier ist die Standardkonfiguration für MariaDB 10 wie sie ausgeliefert wurde:
[client]
port = 3307
socket = /run/mysqld/mysqld10.sock
[mysqld]
bind-address = 0.0.0.0
port = 3307
socket = /run/mysqld/mysqld10.sock
pid-file = /run/mysqld/mysqld10.pid
skip-external-locking
key_buffer_size = 16K
max_allowed_packet = 1M
table_open_cache = 4
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
thread_stack = 240K
innodb_data_home_dir = /var/packages/MariaDB10/target/mysql
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /var/packages/MariaDB10/target/mysql
innodb_buffer_pool_size = 16M
innodb_additional_mem_pool_size = 2M
#innodb_log_file_size = 5M
#innodb_log_buffer_size = 8M
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 50
innodb_file_per_table = 1
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
[myisamchk]
key_buffer_size = 8M
sort_buffer_size = 8M
[mysqlhotcopy]
interactive-timeout
# Please add your custom configuration to here:
!include /var/packages/MariaDB10/etc/my.cnf
Vielleicht hilft dir das noch etwas.
LG
Heiko
Mir bleibt nur noch ein Support-Ticket aufzumachen.
Hatte MariaDB10 bereits komplett reinstalliert, alle CNF's auf die Seite geschoben so dass MariaDB10 mit der Factory-Config läuft.
Versuch 1:
DB-Ordner auf eine (nahezu leeren) 3TB WD-Red gelegt:
Import der 2016er Daten:
Query OK, 33891066 rows affected (3 hours 18 min 55.40 sec)
Records: 33891066 Deleted: 0 Skipped: 0 Warnings: 0
Versuch 2:
/tmp auf 2GB reduziert, tmpfs mit 8GB angelegt und das Datenbank-Verzeichnis in die Ram-Disk gelegt.
Dann einen DB-Import der 2016er Daten gestartet.
Zwischenstatus: 8% nach 800sec...
Das wären - grob kalkuliert - >2Std bei einer Datenbank, die komplett im RAM liegt....
Ach ja - vorher natürlich ein
sysctl -w vm.swappiness=0
ZitatMir bleibt nur noch ein Support-Ticket aufzumachen.
Würde ich auch machen. Das kommt mir schon arg komisch vor.
Hast du denn auch sonst Performanceprobleme ?
Wenn ich irgendeinen Vergleich beisteuern kann gib einfach Bescheid....
ZitatHast du denn auch sonst Performanceprobleme ?
Nö - das ist ja das Seltsame. Schreiben/Lesen via nfs oder die Syslog-Auswertungen sind eigentlich ohne Befund.
strolch@Strolchi /var/media/misc $ dd if=/dev/zero of=zero bs=16M count=1024
1024+0 records in
1024+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 254,19 s, 67,6 MB/s
strolch@Strolchi /var/media/misc $ dd if=/var/media/misc of=/dev/null bs=16M
1024+0 records in
1024+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 252,829 s, 68,0 MB/s
/var/media/misc ist ein NFS-Mount auf /volume1/misc...
Hatte auch bereits die üblichen Verdächtigen (Intrusion Detection, Firewall, Virenchecker) schlafen gelegt.
Hmm... schau mal zum Vergleich:
Heiko@SDS1:~$ dd if=/dev/zero of=zero bs=16M count=1024
1024+0 records in
1024+0 records out
17179869184 bytes (17 GB) copied, 104.823 s, 164 MB/s
Jo - Faktor 2,5 - suboptimal, aber noch immer nicht im gelben Bereich.
Im Gegensatz zur MariaDB auf RAMDisk - die importiert noch immer...
Mir ist nur immer wieder aufgefallen dass bei mir das Plattensubsytem die Leistung begrenzte, so auch bei diesem Test. Die CPU lief jetzt mit gesamt ~30% wobei das Volume zu 100% ausgelastet war. (Screenshot)
Bei dir war es eher die CPU wenn ich mich nicht irre.
Da wir die gleichen CPUs haben, kann ich mir da keinen Reim drauf machen.
Na mal schauen was Syno sagt ....
Die CPU-Load kann man vernachlässigen - es waren nie mehr als 2 Cores aktiv.
Sobald ich was habe gebe ich Bescheid.
Hallo @all,
wie hier https://forum.fhem.de/index.php/topic,74234.msg664064.html#msg664064 gemeldet und diskutiert, gibt es in manchen Fällen (Modul dewpoint) die Notwendigkeit die Event-API im kompatiblen Modus (Events ohne state-String) aufzurufen.
In der angehängten Version 2.22.0 kann man dieses Verhalten mit dem Attribut "addStateEvent = 0" einschalten.
Per default verwendet DbLog "addStateEvent = 1", d.h. bei Events mit dem state-Reading wird der state-String mit abgerufen.
Bitte testet diese Version bei euch.
viele Grüße
Heiko
Zitat von: DS_Starter am 25 Juli 2017, 21:47:33
wie hier https://forum.fhem.de/index.php/topic,74234.msg664064.html#msg664064 gemeldet und diskutiert, gibt es in manchen Fällen (Modul dewpoint) die Notwendigkeit die Event-API im kompatiblen Modus (Events ohne state-String) aufzurufen.
Hallo, das ist ein schönes Feature. Ausführlich testen konnte ich es leider noch nicht.
Da "state" ja eigentlich nicht zum loggen gedacht ist, musste ich bisher immer kleinere Handstände machen, um diese aus meiner DB zu verbannen,
dieses Feature reduziert somit meine Systemlast, da ich mir das Loggen und spätere aussortieren löschen spare! Herzlichen Dank!
Ich werde das auf Seite 1 bei unfer #24 ergänzen!
Joe
Ich bin's nochmal...
Um es vorwegzunehmen - mein Problem liegt darin, dass das MariaDB tmpdir auf /tmp liegt - und /tmp ein tmpfs device ist.
Ab einer bestimmten Datenbankgröße gehen die Zugriffszeiten explosionsartig nach oben.
Ich nehme an, dass dies im Wesentlichen dem 32bit-Kernel geschuldet ist.
Legt man tmpdir auf die Harddisk, so sieht man bei 'kleinen' Datenbanken nur unwesentliche Unterschiede. Hingegen kommt der eklatante Leistungseinbruch bei der großen Datenbank nicht zum Tragen. Die nachfolgenden Werte wurden mit der Synology Default-Konfiguration durchgeführt, die Custom mysql.cnf enthält lediglich ein "tmpdir=/volumeSATA1/satashare1-1/@tmp" Statement.
Testablauf:
TRUNCATE TABLE `fhem`.`historyAria`;
ALTER TABLE `fhem`.`historyAria` DROP PRIMARY KEY, DROP INDEX Report_Idx,DROP INDEX Reading_Time_Idx,DROP INDEX Search_Idx;
LOAD DATA INFILE './history.dat' INTO TABLE `fhem`.`historyAria` FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n';
ALTER TABLE `fhem`.`historyAria` ADD PRIMARY KEY(`DEVICE`,`READING`,`TIMESTAMP`);
CREATE INDEX Report_Idx ON `fhem`.`historyAria` (TIMESTAMP, READING);
CREATE INDEX Reading_Time_Idx ON `fhem`.`historyAria` (READING,TIMESTAMP);
CREATE INDEX Search_Idx ON `fhem`.`historyAria` (DEVICE,READING,TIMESTAMP);
ALTER TABLE `fhem`.`historyAria` DROP PRIMARY KEY, DROP INDEX Report_Idx,DROP INDEX Reading_Time_Idx,DROP INDEX Search_Idx;
ALTER TABLE `fhem`.`historyAria` ADD PRIMARY KEY(`DEVICE`,`READING`,`TIMESTAMP`), ADD INDEX Report_Idx(TIMESTAMP, READING), ADD INDEX Reading_Time_Idx(READING,TIMESTAMP), ADD INDEX Search_Idx(DEVICE,READING,TIMESTAMP);
Vergleich 'tmpfs' vs. Harddisk bei kleinen sowie größeren DBs:
| tmpfs | /dev/sd | tmpfs | /dev/sd |
DB rows | 33.891.066 | 33.891.066 | 70.674.191 | 104.555.703 |
IMPORT | 6:15.58 | 6:17.33 | 13:02.20 | 19:14.06 |
PRIMARY KEY | 9:20.36 | 9:32.38 | 20:10.58 | 29:44.66 |
Report_Idx | 11:15.87 | 11:15.74 | 25:57.34 | 38:56.62 |
Reading_Time_Idx | 14:13.99 | 14:13.53 | 34:13.53 | 50:48.60 |
Search_Idx | 19:14.34 | 19:07.35 | 45:11.09 | 67:21.90 |
DROP all PKey,Idx | 4:22.41 | 4:26.33 | --- | --- |
ADD all PKey, Idx | 19:08.72 | 19:08.70 | --- | --- |
Fazit:
Werden die Idx sequentiell generiert, so ist bereits beim Hinzufügen des 1. Index tmdir auf der Platte nicht langsamer als im tmpfs.
DROP all Idx,PKey; ADD all Idx,PKey ist deutlich schneller als KEY und INDEX successive hinzuzufügen.
[Edit: Zeiten für DROP all, ADD all mit tmpfs hinzugefügt]
Hallo zusammen,
ich hab eine Bitte.
Würden sich noch ein paar Tester finden, die diese https://forum.fhem.de/index.php/topic,74690.msg664364.html#msg664364 Version ebenfalls testen ?
In dieser Version wurde Warnungen "unitialized ..." in zwei Codezeilen gefixt die offensichtlich in seltenen Fällen beim Aufruf von SVGs auftreten können.
Bin mir nur noch unsicher ob es unerwünschte Nebeneffekte gibt.
Würde mich freuen wenn es dazu noch ein paar Rückmeldungen geben würde.
Danke und VG
Heiko
Hallo Heiko,
sorry dass ich nicht zum testen gekommen bin, ich bin gerade recht viel unterwegs.
Danke dennoch fürs erstellen und einchecken der neuen Version.
Die Warnungen konnte ich in meinen Logs auch finden, mit dem Update sind sie auch bei mir (bisher) verschwunden!
sG
Joe
Hallo Heiko,
habe die 2.22.1 eingespielt. Läuft unauffällig.
Keine Meldungen im Log.
Alles gut bei mir.
Danke und Grüße
Michael
Guten Morgen ihr zwei,
ihr habt sicherlich mitbekommen dass ich die Version wegen https://forum.fhem.de/index.php/topic,75039.0.html wieder zurückgedreht habe.
@Joe, wir können zu einem späteren Zeitpunkt auch nochmal gemeinsam schauen woran diese Meldung ""unitialized ..." liegen könnte. Sie kommt offensichtlich selten vor. Bei mir gibt es sie nicht.
LG
Heiko
Hallo Heiko,
ich dreh meine Version vor dem Wochenende nicht mehr zurück, aber danach gerne!
Wobei mir gerade bei genauerem hinsehen aufgefallen ist, dass ich da völlig andere Codestellen habe. (sorry!)
PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_DbLog.pm line 2817.
PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_DbLog.pm line 2838.
PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_DbLog.pm line 2838.
Vielleicht habenmeine Meldungen also gar nichts mit der Meldung zu tun?!?
Hinweis: Die Zeilen angaben oben sind bei mir natürlich etwas verschoben, da ich einen Patch von mir zum reduzieren der Datenmenge gerade teste...
schöne Grüße, Joe
Ja, kein Stress. Ich komme auch erstmal nicht dazu nochmal genauer zu schauen wie man die Warnung ohne Nebenwirkung bseitigen kann.
LG,
Heiko
Hey,
hab gerade im SVN gesehen, dass die Version zurückgedreht wurde...
Und ja, im Ploteditor fehlt tatsächlich was :-\
Gibts bei Perl ist nicht auch sowas wie: if(!isset($var))$var="";
Ja, gibt verschiedene Möglichkeiten. Ich muß mir die Stelle bei Gelegenheit nochmal ansehen und durchdenken in welchen Fällen es überhaupt dazu kommt dass die (oder eine ) Variable nicht gesetzt sind. Wie gesagt, der Code an dieser Stelle ist schon alt und da muß ich mich hineindenken was der Autor sich damals gedacht hat.
LG,
Heiko
Hallo Heiko,
ich habe jetzt mal die "addlog" - Funktion ausprobiert mit <devspec>. Funktioniert sehr gut. Unschön finde ich allerdings, dass mir zuviel in das Log geschrieben wird (für jedes gefundene Device ein Eintrag, der so lang ist, dass er über 2 Zeilen geht. Dadurch übersehe ich eventuell wichtigere Meldungen im Log. Verbose möchte ich ungerne von 3 auf 2 setzen. Gerade DbLog ist zu wichtig, um Meldungen zu unterdrücken. Ich bräuchte diese Zeilen überhaupt nicht im Log. Der Hinweis innerhalb der DB, dass der Wert aus der addlog-Funktion kommt, reicht meiner Meinung nach.
Hast du eine Idee dazu (und evtl. auch eine Lösung ;D)
LG
Holger
Hi Holger,
wie wäre es bei verbose 3 nur eine kurze Meldung aus Device, Reading, Value auszugeben. Die ausführliche Variante kann man auf verbose 4 setzen.
So mach einer hätte sicherlich gern einen Hinweis im Log dass sein Addlog durchgeführt wurde.
Was hältst du/ihr davon ?
LG
Heiko
Hallo Heiko,
das "Problem" ist vor allem, dass diese Meldung für jedes einzelne Device ausgegeben wird. Ich habe unterschiedliche Devices/devspec, für die ich jeweils ein addLog setzen möchte (stündlich). Dafür bräuchte ich vermutlich mehrere set ... .
Wäre evtl. folgendes möglich: ausführlich mit verbose 5 und Kurzmeldung mit 4?
Oder ein zusätzliches Attribut (entweder zum Unterdrücken ja/nein oder zum Einstellen des verbose-Grades für diese Meldungen). Ist aber bestimmt ein ziemlicher Aufwand für ein nice to have ;)
Habe gerade noch mal nachgeschaut: die FHEM-addlog Implementierung schreibt auch nichts in's Log. Nur im Filelog findet sich ein Hinweis dazu, ähnlich wie bei dir in der DB. Also die Meldung vielleicht doch ganz weglassen?
LG
Holger
Ja, ich sehe ein dass es störend sein kann wenn viele addlogs gesetzt werden.
Ich denke ich werde ein Attribut ähnlich "suppressAddlogMsg" einführen. Dann kann man diese Meldungen im Log unterdrücken. Manch einer der vielelicht nur Mitternacht ein Addlog setzt, möchte eine Info im Log haben.
Dann ist allen geholfen ;)
LG
Heiko
Hallo zusammen,
hier ist die V2.22.1 mit dem Attribut "suppressAddLogV3".
Wenn gesetzt werden die addLog-Meldung mit verbose 3 unterdrückt.
Bitte testen ob das Ziel damit erreicht ist. Wenn alles wie gewünscht funktioniert checke ich die Version ein.
viele Grüße
Heiko
Hallo Heiko,
habe gerade gesehen, dass du noch fleißig warst :) - danke dafür!!!
Der Test selber ist bei mir nicht erfolgreich. Die neue Version ist aktiv, extra "shutdown restart" durchgeführt, suppressAddLogV3 steht auf "1".
Dann set addLog ausgelöst.... ---> leider immer noch alle Meldungen im Log. Oder ich habe irgend etwas übersehen - aber genug für heute.
LG
Holger
Ja, hab ein Zeichen vergessen .... bitte nochmal die V aus #417.
LG
Heiko
:) :) :)
Danke!!! Funktioniert wie gewünscht
LG
Holger
Habe grade gesehen, dass bei meinem CUL-Devices einiges zu viel geloggt wird (Version 2.22.0):
defmod logdb DbLog ./contrib/dblog/MariaDB10.conf .*:.*
attr logdb DbLogExclude .*
attr logdb DbLogType Current/History
attr logdb asyncMode 1
attr logdb cacheEvents 2
attr logdb colEvent 512
attr logdb colReading 64
attr logdb colValue 128
attr logdb disable 0
attr logdb event-on-change-reading CacheUsage,background_processing_time
attr logdb icon security
attr logdb room DbLog
attr logdb showNotifyTime 1
attr logdb showproctime 1
attr logdb timeout 86400
attr logdb verbose 3
Der CUL:
defmod miniCUL433 CUL 192.168.254.88:85 0000
attr miniCUL433 DbLogInclude state,uptime
attr miniCUL433 addvaltrigger 1
attr miniCUL433 comment freq: 433.940MHz, bWidth: 325kHz\
(bei 433.92: T1: -35,7kHz, T2: +42,3kHz, T3: +60,8kHz)\
Der Thermometer:
defmod NC_WS_81 CUL_TCM97001 CUL_TCM97001_81
attr NC_WS_81 event-min-interval .*:300
attr NC_WS_81 event-on-change-reading .*
attr NC_WS_81 model NC_WS
attr NC_WS_81 room CUL_TCM97001
setstate NC_WS_81 T: 23.3 H: 24
setstate NC_WS_81 2017-08-03 15:36:15 battery low
setstate NC_WS_81 2017-08-03 15:36:15 channel 1
setstate NC_WS_81 2017-08-08 14:26:29 humidity 24
setstate NC_WS_81 2017-08-03 15:36:15 mode normal
setstate NC_WS_81 2017-08-08 14:26:29 state T: 23.3 H: 24
setstate NC_WS_81 2017-08-08 14:26:29 temperature 23.3
Und das dblog für dieses Device:
TIMESTAMP DEVICE TYPE EVENT READING VALUE UNIT
2017-08-08 14:17:44 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801B RAWMSG s51C90E91801B
2017-08-08 14:17:09 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801F RAWMSG s51C90E91801F
2017-08-08 14:16:34 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801F RAWMSG s51C90E91801F
2017-08-08 14:15:59 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801F RAWMSG s51C90E91801F
2017-08-08 14:15:24 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801F RAWMSG s51C90E91801F
2017-08-08 14:14:49 NC_WS_81 CUL_TCM97001 humidity: 24 humidity 24 %
2017-08-08 14:14:49 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E918020 RAWMSG s51C90E918020
2017-08-08 14:14:14 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801F RAWMSG s51C90E91801F
2017-08-08 14:13:39 NC_WS_81 CUL_TCM97001 temperature: 23.3 temperature 23.3 °C
2017-08-08 14:13:39 NC_WS_81 CUL_TCM97001 state: T: 23.3 H: 24 state T: 23.3 H: 24
2017-08-08 14:13:39 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801E RAWMSG s51C90E91801E
2017-08-08 14:13:06 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801F RAWMSG s51C90E91801F
2017-08-08 14:12:29 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801D RAWMSG s51C90E91801D
2017-08-08 14:11:54 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801F RAWMSG s51C90E91801F
2017-08-08 14:11:19 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801D RAWMSG s51C90E91801D
2017-08-08 14:10:44 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E918022 RAWMSG s51C90E918022
2017-08-08 14:10:09 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801E RAWMSG s51C90E91801E
2017-08-08 14:09:34 NC_WS_81 CUL_TCM97001 humidity: 24 humidity 24 %
2017-08-08 14:09:34 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E918020 RAWMSG s51C90E918020
2017-08-08 14:08:59 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E918020 RAWMSG s51C90E918020
2017-08-08 14:08:24 NC_WS_81 CUL_TCM97001 temperature: 23.3 temperature 23.3 °C
2017-08-08 14:08:24 NC_WS_81 CUL_TCM97001 state: T: 23.3 H: 24 state T: 23.3 H: 24
2017-08-08 14:08:24 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E918020 RAWMSG s51C90E918020
2017-08-08 14:07:51 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E918020 RAWMSG s51C90E918020
2017-08-08 14:07:14 NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E918020 RAWMSG s51C90E918020
ZitatHabe grade gesehen, dass bei meinem CUL-Devices einiges zu viel geloggt wird (Version 2.22.0)
Gehe ich richtig in der Annahme dass mit "einiges zu viel geloggt" die Einträge
NC_WS_81 CUL_TCM97001 RAWMSG: s51C90E91801F RAWMSG s51C90E91801F
bzw. deren Häufigkeit, gemeint sind ?
Das diese Readings des Thermometers überhaupt in der DB sind ist soweit i.O. weil nicht über den Regex ausgeschlossen.
Anders verhält es sich mit der Häufigkeit. Anders als "state" und "humidity" die sich an die Frequenz vo 300 Sekunden halten,
scheinen sich die Readings "RAWMSG" nicht darum zu scheren.
Ob geloggt wird oder nicht (bzgl. Intervall), wird durch einen Vergleich des letzten Logzeitpunkt des Readings und dessen Wert ermittelt.
Dazu gibt es in dem betreffenden Device einen Helpereintrag (list NC_WS_81) für das DbLog-Device:
Helper:
DBLOG:
Bezug_WirkP_Kosten_Diff:
LogDB1:
TIME 1502210951.26597
VALUE 0.0000
Bei dir müßte es also etwas Vergleichbares für das Reading "RAWMSG" geben, wobei ich etwas unschlüssig bin ob es dieses Reading überhaupt gibt weil ich keinen setstate-Eintrag im Thermometer dafür erkennen kann.
Schau mal bitte mit list in dein Thermometer und suche nach "RAWMSG" und was dort drin steht (sollte ja z.B. "s51C90E91801F" sein).
Grüße
Heiko
Die 93_DbLog: V2.22.1, new attribute "suppressAddLogV3" ist eingecheckt und morgen früh im Update.
Grüße
Heiko
RAWMSG ist ein internal.
Und DbLogExclude steht auf .*
Für die Thermometer gibt's kein explizites Include.
ZitatRAWMSG ist ein internal.
Dann verstehe ich momentan nicht wieso dafür Events erzeugt werden denn nur die können ja geloggt werden. Üblicherweise erzeugt der Autor Events für Readings mit den dafür vorgesehenen fhem-Befehlen. Da könntest du mal in dem entsprechenden Unterforum nachfragen wie sich das verhält.
ZitatUnd DbLogExclude steht auf .*
Das hast du aber im DbLog-Device selbst gesetzt. Das bedeutet, es würden alle Events missachtet die das DbLog-Device SELBST erzeugt (wenn es das tun würde). "DbLogExclude" bzw. "DbLogInclude" setzt du immer in der Quellen, d.h. den zu loggenden Devices.
ZitatFür die Thermometer gibt's kein explizites Include.
Das ist auch nicht nötig. Wie die einzelnen Attribute "DbLogExclude" bzw. "DbLogInclude" ausgewertet werden, sofern sie in den Quellen gesetzt sind, hängt von dem im DbLog-Device gesetzten Attribut "DbLogSelectionMode" ab. Ist es nicht gesetzt, wie in deinem Fall, gilt immer "Exclude" als Default .
Das heißt, solltest du irgendwo ein "DbLogInclude" gesetzt haben, würde es durch DbLog ignoriert.
Zitat aus der Commandref ->
Zitat
DbLogSelectionMode
Dieses, fuer DbLog-Devices spezifische Attribut beeinflußt, wie die Device-spezifischen Attributes DbLogExclude und DbLogInclude (s.u.) ausgewertet werden. Fehlt dieses Attribut, wird dafuer "Exclude" als Default angenommen.
Exclude: DbLog verhaelt sich wie bisher auch, alles was ueber die RegExp im DEF angegeben ist, wird geloggt, bis auf das, was ueber die RegExp in DbLogExclude ausgeschlossen wird
Das Attribut DbLogInclude wird in diesem Fall nicht beruecksichtigt
Ich muß zugeben dass ich auch jedesmal dreimal über diesen Zusammenhang nachdenken muss und löse bisher alles über die Regex im DEF bzw. "event-on-change-reading" in den Quellen.
Also soweit ist mir alles klar was passiert, aber bzgl. des RAWMSG ist mir das momentan nicht transparent denn ein INTERNAL wirft allgemein keinen Event.
@Virsacer, @all,
hier nochmal der Versuch die "Uninitialized" Meldungen in Zeile 737 zu beseitigen.
Bitte die V2.22.2 testen ob es diesmal ohne Nebeneffekte funktioniert. D.h. bitte die SVG Erstellung explizit testen.
Bei mir sieht es bis jetzt gut aus.
Grüße
Heiko
Hallo Heiko,
ich schon wieder ;)
Ich bin gerade etwas am Optimieren. In der Definition meiner DB steht u.a., dass das Reading ,,state" geloggt werden soll. Dabei ist mir jetzt aufgefallen, dass ich auch viele state-Readings von diversen DOIFs und ATs habe, die ich aber nicht benötige. Ich habe daher in der DB (DbLogSelectionMode Exclude) ein
attr <db> excludeDevs speedtest,my_unifi_controller,TYPE=DOIF,TYPE=AT
Für DOIF funktioniert es, für AT nicht. Getestet habe ich auch die Schreibweise: TYPE=(DOIF|AT). Hat auch nur für DOIF funktioniert. Auch ausschließlich TYPE=AT funktioniert nicht.
Habe ich etwas übersehen?
LG
Holger
AT klein schreiben ?
LG
Heiko
at mus sklein geschrieben werden.
fhem> list TYPE=AT
fhem> list TYPE=at
DbLog.DeleteOldData
PCA301_01.calcD
...
Zitat von: DS_Starter am 08 August 2017, 23:08:43
Dann verstehe ich momentan nicht wieso dafür Events erzeugt werden denn nur die können ja geloggt werden. Üblicherweise erzeugt der Autor Events für Readings mit den dafür vorgesehenen fhem-Befehlen.
Fehler bei mir...
Hatte versehentlich "addValTrigger" auf dem CUL-Device aktiviert - der ist dafür verantwortlich.
Ihr habt recht: at muss klein geschrieben werden. Danke.
Was ich nicht so ganz verstehe, warum es dann in der DB groß abgespeichert wird. Ist das so gewollt?
LG
Holger
ZitatWas ich nicht so ganz verstehe, warum es dann in der DB groß abgespeichert wird. Ist das so gewollt?
Ja, der Type wird auf Uppercase gesetzt. Allerdings kann ich dir die Entwicklungsgeschichte nicht verraten. Das war bereits in dem "alten" DbLog-Modul (2016) der Fall und wurde bei der Weiterentwicklung nicht verändert.
Wahrscheinlich wollte man eine gewisse Vereinheitlichung erreichen.
Zitat von: DS_Starter am 08 August 2017, 23:51:31hier nochmal der Versuch die "Uninitialized" Meldungen in Zeile 737 zu beseitigen.
Bitte die V2.22.2 testen ob es diesmal ohne Nebeneffekte funktioniert. D.h. bitte die SVG Erstellung explizit testen.
Bei mir sieht es bis jetzt gut aus.
Danke, aber eine Meldung hab ich bisher:
2017.08.09 23:05:51 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_DbLog.pm line 4322.
Zitat2017.08.09 23:05:51 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/93_DbLog.pm line 4322.
Ich wollte schrittweise vorgehen und habe mit der angehängten V2.22.3 auch noch diese Zeile behandelt.
Schau mal bitte ob auch diese Änderung keine negativen Auswirkungen auf die SVG-Erstellung bzw. SVG-Änderung hat.
LG
Heiko
Danke, hatte jetzt keine Warnungen mehr, aber im Plot Editor stet z.B. "VarTemperatureMin: : : " und wenn ich das so mit den Leerzeichen zwischen den Doppelpunkten speichere, funktioniert der Graph nicht mehr...
"2017.08.11 08:38:28 3: SVG_Thermometer: space is not allowed in DbLog definition: VarTemperatureMin: : : "
Sollte da auch nicht nur maximal ein Doppelpunkt drin sein?
Manchmal sieht man die einfachste Lösung nicht .... habe die Version in #434 nochmal überarbeitet und ich denke dass wir das Problem nun völlig ohne unbeabsichtigte Nebenwirkungen erledigen konnten.
Test mal bitte ...
LG
Heiko
Im Plot Editor hängt er zwar immernoch "::" bzw. ":::" an, was zwar unnötig ist, aber wenigstens nicht zu Fehlern führt...
Sonst scheint es ok zu sein 8)
ZitatIm Plot Editor hängt er zwar immernoch "::" bzw. ":::" an, was zwar unnötig ist,....
Das kenne ich nicht anders.
Schön dass es nun klappt !
Ich möchte noch weitere Mitstreiter ermutigen die Version 2.22.3 aus dem Beitrag #434 zu testen damit ich diese V guten Gewissens mal einchecken kann.
VG
Heiko
Hallo Heiko,
eine Rückmeldung zu v2.22.3.
Ich bin endlich dazu gekommen, meine ganzen Filelog-Plots auf DbLog umzustellen (knapp 50). Dabei hatte ich schon die v2.22.3 im Einsatz.
Das einzige, was mir jetzt aufgefallen ist, dass bei einem Zwave-Device der Luminance-Wert "2 %" in der DB nicht auf Wert "2" und Unit "%" aufteilt wird und daher PERL WARNINGs ausgegeben werden. Auch bei einigen Batteriewerten mit %-Angaben erfolgt keine Trennung in Value und Unit.
LG
Holger
Hallo Holger,
danke für die Info.
Bezüglich der Trennung Value/Unit gibt es in DbLog eine, sagen wir nicht umfassende, Behandlung der Devices. Unser Ziel ist es eigentlich, dass diese Splittingfunktion in dem Quelldevice (Modul) vorgenommen wird und nicht in DbLog selbst. Ich kann schauen dass ich das Splitting noch aufbohre, aber
zielführender und exakter wäre es wenn der Modulmaintainer die Funktion "DbLog_splitFn" einbauen würde. Vielleicht ihn mal darauf schubsen.
Infos dazu hier -> https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_DbLog_split.
LG
Heiko
Hallo Heiko,
ich habe das Problem im ZWave-Bereich gemeldet. Mal sehen, die dort die Sicht der Dinge ist.
LG
Holger
Nachtrag:
Bzgl. DbLog_splitFn habe ich eine Absage bekommen.
Für mein aktuelles Problem habe ich jetzt für diese Situation eine Lösung für mich gefunden: im SVG nach den ::: noch chop($val) anfügen. Das entfernt das letzte Zeichen und es gibt keine Warnings mehr im Log.
Was ich nicht hinbekommen habe: ein RegEx zu definieren, dass im Prinzip das gleiche macht. Könnte man vielleicht gebrauchen, wenn die (nicht aufgetrennte) Unit mal länger als ein Zeichen ist.
ZitatBzgl. DbLog_splitFn habe ich eine Absage bekommen.
Ja, habe gelesen was Rudi geantwortet hat.
ZitatWas ich nicht hinbekommen habe: ein RegEx zu definieren, dass im Prinzip das gleiche macht. Könnte man vielleicht gebrauchen, wenn die (nicht aufgetrennte) Unit mal länger als ein Zeichen ist.
Wenn nochmal ein konkreter Anwendungsfall für ein notwendiges Splitting vorliegt, könnte ich es noch im DbLog erweitern. Das sollte/ kann nur eine Notlösung sein.
Die V2.22.3 habe ich vorhin eingecheckt.
LG
Heiko
Mit Perl stehe ich noch auf dem Kriegsfuß und bitte daher um Unterstützung.
Ich habe einige ZWave-Sensoren, bei denen DbLog im $VALUE auch die Unit (hier: %) speichert.
Die Idee ist jetzt, mit valueFn die Daten anzupassen.
attr myFHEMdb_LT valueFn {if ($DEVICE eq "ZW_.*" && $VALUE <hier verlassen sie mich>){chop($VALUE);$UNIT="%";}}
Meine Idee: prüfen, ob letztes Zeiches des $VALUE ein ,,%"-Zeichen enthält. Falls ja: $VALUE um das %-Zeichen kürzen und das $UNIT-Feld mit % befüllen.
LG
Holger
Nachtrag:
Ich habe es jetzt so
{if ($DEVICE eq "ZW_.*" && $READING eq ("battery"|"luminance") && $VALUE =~ m/%$/){chop($VALUE);$UNIT="%";}}
versucht. Funktioniert aber leider nicht. Wo ist mein Denkfehler?
Versuche es mal so (ungetestet):
attr myFHEMdb_LT valueFn {if ($DEVICE =~ m/ZW_.*/ && $VALUE =~ m/.*%$/) {$VALUE =~ tr/%//d; $UNIT="%";}}
LG
Heiko
Ja, funktioniert so. Danke!
Verstehe allerdings nicht, warum meine Variante nicht funktioniert hat.
LG
Holger
z.B.
$DEVICE eq "ZW_.*"
wird nicht klappen denn "ZW_.*" soll ja eigentlich ein regulärer Ausdruck sein. So vergleichst du tatsächlich auf ein Device welches genau "ZW_.*" heißt.
Zitat von: DS_Starter am 18 August 2017, 20:19:25
Versuche es mal so (ungetestet):
attr myFHEMdb_LT valueFn {if ($DEVICE =~ m/ZW_.*/ && $VALUE =~ m/.*%$/) {$VALUE =~ tr/%//d; $UNIT="%";}}
LG
Heiko
Evtl. hilft es so weiter:
attr myFHEMdb_LT valueFn {if($VALUE=~/\s%$/){$VALUE=~s/\s%$//;$UNIT="%";}}Gruß
Dan
Hi Dan, hast du mich jetzt gefragt, weil du mich zitiert hast ? ;)
Zitat von: DS_Starter am 18 August 2017, 22:15:15
Hi Dan, hast du mich jetzt gefragt, weil du mich zitiert hast ? ;)
Nö, hab nur versucht eine mögliche bessere Lösung aufzuzeigen.
Probiere diese nämlich auch gerade, da ich selbiges Verhalten meiner ZWave Sensoren in der DB festgestellt habe.
Gruß
Dan
Jo, viele Wege ... 8)
LG
Heiko
Zitat von: DeeSPe am 18 August 2017, 21:45:27
attr myFHEMdb_LT valueFn {if($VALUE=~/\s%$/){$VALUE=~s/\s%$//;$UNIT="%";}}
Diese valueFn hat in der letzten Nacht meine Batteriewerte der ZWave Sensoren richtig geloggt!
Gruß
Dan
Hallo miteinander,
habe soeben die Version 2.22.6 eingecheckt.
In der V hat sich nichts geändert außer dass ich die commandref überarbeitet habe und insbesondere die ersten Schritte vor dem Define besser verständlich strukturiert habe (hoffe ich jedenfalls).
Grüße
Heiko
Guten Abend,
ich setze DbLog(2.22.6) zusammen mit PostgreSQL ein, bei einem set <name> configCheck erhalte ich folgende (gekürzte) Ausgabe
........
Result of table 'history' check
Column width set in DB fhemdaten: 'DEVICE' = no esult, 'TYPE' = no esult, 'EVENT' = no esult, 'READING' = no esult, 'VALUE' = no esult, 'UNIT' = no esult
Column width used by myDbLog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: The relation between column width in table history and the field width used in device myDbLog don't meet the requirements. Please make sure that the width of database field definition is equal or larger than the field width used by the module. Compare the given results.
Currently the default values for field width are:
DEVICE: 64
TYPE: 64
EVENT: 512
READING: 64
VALUE: 128
UNIT: 32
You can change the column width in database by a statement like 'alter table history modify VALUE varchar(128);' (example for changing field 'VALUE'). You can do it for example by executing 'sqlCMD' in DbRep or in a SQL-Editor of your choice. (switch myDbLog to asynchron mode for non-blocking).
The field width used by the module can be done by setting attributes 'colEvent', 'colReading', 'colValue',
........
Ich denke mal bei "no esult" hat sich das R heimlich aus dem Staub gemacht.
Aus meiner Sicht wäre es besser wie folgt zu schreiben: Column width set in table 'history'
Gleiches gilt auch für den "current" Abschnitt
Grüße
Pyro
Hi Pyro,
teste mal die angehängte 2.22.7 ob du das "r" nun hast.
Was ich aber prinzipiell nicht verstehe ist wieso du überhaupt "no esult" bekommst. Bei mir klappt es einwandfrei (screenshot).
Kannst du mal in deinem SQL-Editor eingeben:
select column_name,character_maximum_length from information_schema.columns where table_schema='$dbname' and table_name='history' and column_name='device'Dabei ist $dbname deine DbLog-Datenbank.
ZitatAus meiner Sicht wäre es besser wie folgt zu schreiben: Column width set in table 'history'
Ich hatte bewußt "Column width set in DB fhemdaten" geschrieben um eindeutig gegenüber den Settings im Device (Column width used by myDbLog) abzugrenzen. Das es sich dabei um die Tabelle history bzw. current handelt steht ja im jeweiligen Abschnitt eindeutig in der Überschrift ;)
Ich habe es jetzt so ergänzt -> "Column width set in DB fhemdaten.history" bzw. "Column width set in DB fhemdaten.current".
Teste mal bitte.
Grüße
Heiko
Zitat von: DS_Starter am 24 September 2017, 20:18:47Kannst du mal in deinem SQL-Editor eingeben:
select column_name,character_maximum_length from information_schema.columns where table_schema='$dbname' and table_name='history' and column_name='device'
Dabei ist $dbname deine DbLog-Datenbank.
Hallo Heiko,
mein Aufbau ist wie folgt:
Datenbankname: fhemdaten
Schema: fhem
Wenn ich jetzt
select column_name,character_maximum_length from information_schema.columns where table_schema='fhemdaten' and table_name='history' and column_name='device'ausführe erhalte ich:
Total query runtime: 20 msec0 rows retrieved.Wenn ich allerdings das Schema abfrage:
select column_name,character_maximum_length from information_schema.columns where table_schema='fhem' and table_name='history' and column_name='device'erhalte ich korrekt die Antwort
"device";64Kann es sein das in deiner Testumgebung beides gleich benannt ist?
2.22.7 werde ich morgen testen.
Ja, kann sein. Versuche den Abruf mal so:
select column_name,character_maximum_length from information_schema.columns where table_name='history' and column_name='device'
Zitat von: DS_Starter am 24 September 2017, 22:00:08
Ja, kann sein. Versuche den Abruf mal so:
select column_name,character_maximum_length from information_schema.columns where table_name='history' and column_name='device'
Ja, funktioniert:
"device";64
Ok, prima ... hatte ich vermutet :)
Ich habe hier noch eine 2.22.7a angehängt. Wenn du du die 2.22.7 testest sollte "no result" kommen und mit der 2.22.7a dann auch (hoffentlich) es richtig funktionieren.
Danke und bis morgen .. gute Nacht !
LG
Heiko
Testsystem erstellen ist schneller gegangen als gedacht:
2.22.7
Result of table 'history' check
Column width set in DB fhemdaten.history: 'DEVICE' = no result, 'TYPE' = no result, 'EVENT' = no result, 'READING' = no result, 'VALUE' = no result, 'UNIT' = no result
Column width used by myDbLog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: The relation between column width in table history and the field width used in device myDbLog don't meet the requirements. Please make sure that the width of database field definition is equal or larger than the field width used by the module. Compare the given results.
Currently the default values for field width are:
DEVICE: 64
TYPE: 64
EVENT: 512
READING: 64
VALUE: 128
UNIT: 32
You can change the column width in database by a statement like 'alter table history modify VALUE varchar(128);' (example for changing field 'VALUE'). You can do it for example by executing 'sqlCMD' in DbRep or in a SQL-Editor of your choice. (switch myDbLog to asynchron mode for non-blocking).
The field width used by the module can be done by setting attributes 'colEvent', 'colReading', 'colValue',
2.22.7a
Result of table 'history' check
Column width set in DB fhemdaten.history: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by myDbLog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: settings o.k.
Aus meiner Sicht sollte somit alles passen.
Herzlichen Dank für die schnellen Anpassungen!
Gruß und gute Nacht
Pyro
Guten Morgen Pyro,
danke für dein Engagement extra noch ein zusätzliches Testsystem aufzubauen.
Sieht gut aus :)
Werde die 2.22.7a als Version 2.22.7 heute Abend einchecken.
Guten Start in die Woche !
LG
Heiko
Hallo zusammen,
habe eine neue Version gebaut 2.22.8 gebaut. Bei dieser Version werden in der Dropdown-Liste zur SVG-Erstellung doppelte Einträge in der current (sofern dort vorhanden) bei der Ausgabe eliminiert.
Würde mich freuen wenn ihr einen Test dieser Version machen würdet.
Grüße,
Heiko
Edit: V2.22.8 ist eingecheckt
Hallo Heiko,
ich hätte eine kleine Verständnissfrage:
Aus der "current" Tabelle werden ja nur die Spalten device und reading genutzt um die SVG Erstellung zu vereinfachen.
Demnach müsste es ja möglich sein die beiden Spalten mit einer "SELECT DISTINCT" Abfrage aus der "history" Tabelle zu befüllen?
Danke!
Gruß und gute Nacht,
Pyro
Hallo Pyro,
ja, das ist möglich und dafür gab es auch Tests, bei größeren Datenbanken mit mehreren 10 Mio Datensätzen dauerte diese Abfrage 17s oder teils je nach Indexe deutlich länger.
Ob man so lange zum Öffnen dieser Seite warten möchte?
beste Grüße
Joe
Mahlzeit,
ich dachte eher an einen "set" Befehl(nonblocking) den man entweder ausführt wenn man neue Devices/Readings angelegt hat oder wenn man die current Tabelle regelmäßig erstellt haben möchte kann man ja ein AT definieren.
Gruß
Pyro
Hi Pyro,
du hast also eine Art Zusatzfunktion im Kopf die ein Nutzer explizit ausführen kann weil er zum Beispiel die gewünschte Device:Reading-Kombi in der current-Tabelle nicht findet ?
Oder ist die Idee das bisherige Schreiben in die current-Tabelle generell umzubauen und durch den "select distinct" zu ersetzen ?
LG
Heiko
Hallo Heiko,
Zitat von: DS_Starter am 02 Oktober 2017, 12:52:44du hast also eine Art Zusatzfunktion im Kopf die ein Nutzer explizit ausführen kann weil er zum Beispiel die gewünschte Device:Reading-Kombi in der current-Tabelle nicht findet ?
ja, das entspricht meiner Vorstellung.
Gruß
Pyro
Das wäre mal zu überlegen und zu testen wie gut oder schlecht das funktioniert. Da die besherige Arbeitsweise erhalten bleibt und quasi nur ein "Auffüllen" der current aus den vorhandenen Werten in der history durchgeführt wird, könnte ich mir das recht gut vorstellen.
Ein Manko welches ich sehe ist, dass eventuell die Leseperformance der current und somit die Performance bei der SVG-Erstellung leidet da ja bisher keine Empfehlung für einen Index auf die current vorliegt. Das ist ja bei wenigen Datensätzen auch nicht nötig. Möglicherweise bläht sich die current dadurch aber gewaltig auf. Es kann ja sein, dass in der history-Tabelle sehr viele Device:Reading-Kombis vorhanden sind von Devices, die es im System evtl. garnicht mehr gibt (Altlasten) weil der User im Laufe der Zeit viel im System geändert hat ohne Datenbereinigung in der DB zu betreiben usw.
Aber ein interessanter Ansatz, mal schauen.
Mich würde interessieren was andere User dazu sagen ?
LG
Heiko
Nur um andere Möglichkeiten aufzuzeigen:
- Man könnte die current komplett durch einen View auf die history-Tabelle ersetzen, der genau diese Informationen generiert.
- Man könnte die Current im async-Modus immer beim Schreiben in die DB aus dem memcache heraus aktualisieren bzw. mit befüllen. Ein "set dblogDevice recreateCurrentCache" könnte diesen aus der DB neu erzeugen, falls der cache mal corrupt geworden ist.
- Da die Current-Tabelle nie besonders groß wird, könnte man diese auch komplett im Speicher behalten. -> Diese müsste beim Start von fhem oder besser noch erst beim Öffnen des Ploteditors befüllt befüllt werden.
Eventuell würde ich durch eine Änderung/Verbesserung hier auch dieses Feature nutzen ;-), was mir aber im Ploteditor eigentlich fehlt ist eine Suche über die Devices,
denn eine übervolle Combobox halte ich eher für unpraktisch.
Just my 5 ct, ...
Grüße
Joe
Für mich wäre eine Funktion wie "RemoveCharacterValues" noch interessant. Vielleicht auch für jemand anders?
Aktuell führe ich dies mittels einem AT aus. Vorteil ist, dass falls mal nicht-numerische Werte in die Loggingspalte VALUE kommen, diese damit gelöscht werden. Somit geben die SVG Funktionen auch keine Fehler bzw. Warnings mehr aus. Meistens passiert mir das bei der Neuanlage von Devices.
define AT_DBLogging_FixCharValuesCurrent at *00:50:00 set DBLogging userCommand "DELETE FROM current WHERE VALUE NOT REGEXP '^[+\-]?[0-9]+\\.?[0-9]*$'";;
define AT_DBLogging_FixCharValuesHistory at *00:45:00 set DBLogging userCommand "DELETE FROM history WHERE VALUE NOT REGEXP '^[+\-]?[0-9]+\\.?[0-9]*$'";;
Zitat von: fhemxperte am 03 Oktober 2017, 22:44:41
Für mich wäre eine Funktion wie "RemoveCharacterValues" noch interessant. Vielleicht auch für jemand anders?
das geht jetzt schon über valueFN. hier kannst du einfach alle Zahlen ausschneiden (also Werte abschneiden) und den Rest verwerfen,
oder eben das Loggen ganz unterbinden.
ValueFN kannte ich noch nicht, funktioniert prima! Danke für den Tipp. Bei mir sollen halt nur auswertbare Decimalwerte im Logging landen. Falls einer möchte, hiermit habe ich das gelöst und es wird direkt angezeigt von welchem Device eine falsche Meldung kommt:
{
if ($VALUE =~ m/^[-+]?\d+(\.\d+)?$/) {
#Log 3, "DBLogging: Value ".$VALUE." from device ".$DEVICE." was logged.";
} else {
Log 3, "DBLogging: Value ".$VALUE." from device ".$DEVICE." was not logged.";
$IGNORE=1;
}
}
Danke fürs teilen!
Zitat von: fhemxperte am 04 Oktober 2017, 19:29:08
...Bei mir sollen halt nur auswertbare Decimalwerte im Logging landen.
Ich habe devices, die leider manchmal irgendwelche Zusätze oder eben auch , statt . nutzen,
diese kann man hier auch noch schön abbilden/korrigieren.... aber das siehst Du dann ja schön in deinem Log.
Hallo zusammen,
Rudi hat ja mit neuesten Blocking.pm ein neues Abbruchargument ausgeliefert.
Ich habe die V2.22.10 so erweitert dass bei einem evtl. Abbruch dieses Argument genutzt wird.
Es ist zwar nur eine kleine Änderung, aber möchte sie dennoch hier zum Test zur Verfügung stellen bevor ich einchecke.
Bitte checked es auch bei euch.
VG
Heiko
Hallo Heiko,
Test läuft.
Melde mich später mit dem Ergebnis.
Gruß
Pyro
Hallo Heiko,
Zitat von: DS_Starter am 07 Oktober 2017, 09:22:16
Bitte checked es auch bei euch.
danke, aber hast Du eine Idee, wie ich diesen Fall konstruieren kann?
Wenn ich korrekt verstehe müsste ich während dem schreiben in die MySQL-Datenbank diese abschalten... dafür hätte ich in meinen Beispielen keine 0.1s zeit...
sG
Joe
Hi Joe,
den konkreten Fehlerfall zu provozieren ist mE nach schwierig. Ich will nur sicher gehen dass die Version bei euch, unter Umständen mit älteren Blocking.pm, problemlos läuft.
Man könnte theoretisch die fehlerhafte Blocking.pm Version 15172 vom 2017-10-02 benutzen die diesen Abbruch fälschlicherweise häufig wirft.
Aber das will ich eigentlich niemanden zumuten sich so zu verrenken. Ich habe sie aber noch parat wer möchte ...
LG
Heiko
Ich weiß gerade nicht, ob ich mich dazu an dich, oder an Rudi wegen FHEMWEB wenden muss. Ich hätte gerne, dass bei den DBLog Device auch der Link für "Create SVG instance" angezeigt wird. Würde das erstellen von Plots ein wenig vereinfachen :)
EDIT:
OK, vergiss es. Es steht oben links bei DBLog und nicht unten dabei, wie ich es von FileLog gewohnt war :D
Hallo zusammen,
ich habe mich mit dem Vorschlag von Pyro zum "Fillup" der current-Tabelle beschäftigt und auch eine Lösung implementiert.
Allerdings habe ich mich dafür entschieden diese Funktion in DbRep zu implementieren. Das hat unter anderem den Vorteil dass man die Fillup-Funktion durch die Attribute device, reading, timestamp_begin, timestamp_end begrenzen kann.
So werden z.B. die Device/Reading-Kombinationen aus der history ausgewertet/extrahiert die letzten Monat eingetragen wurden wenn "timestamp_begin=previous_month_begin" und "timestamp_end=previous_month_end" gesetzt wurde. Das so eingestellte DbRep-Device kann man dann regelmäßig laufen lassen um die Funktion auszuführen.
Darüber hinaus gibt des im DbRep nun die Funktion "tableCurrentPurge" um die current Tabelle zu leeren. Das kann sinnvoll sein wenn sie zu groß geworden ist oder vllt. unerwünschte EInträge enthalten sind. Evtl. vorhandene Indizes bleiben erhalten.
D.h. es gibt nun in der DbRep V5.7.0 die Funktionen:
* set <dbrep-device> tableCurrentPurge - löscht den Inhalt der current-Tabelle
* set <dbrep-device> tableCurrentFillup - ergänzt den Inhalt der current Tabelle aus einem select der histrory-Tabelle unter Beachtung der Select-Eingrenzung durch device,reading und timestamps
Die DbRep-Version könnt ihr euch zum Test hier: https://forum.fhem.de/index.php/topic,53584.msg452567.html#msg452567 herunterladen.
Das DbLog-Device sollte auf jeden Fall im asynchronen Modus betrieben werden.
(konsequenterweise müsste ich im DbLog das Attr DbLogType noch um eine Auswahlmöglichkeit "samplefill/history" ergänzen. Bei dieser Auswahl wird die current nicht aktiv geloggt, aber bei der SVG-Erstellung ausgewertet. Damit könnte man sie ausschließlich regelmäßig über DbRep füllen).
Die DbLog-Version V2.22.10 checke ich nachher noch ein.
Grüsse,
Heiko
Hallo Heiko,
Zitat von: DS_Starter am 09 Oktober 2017, 21:48:54Die DbLog-Version V2.22.10 checke ich nachher noch ein.
hat sich bei mir absolut unauffällig verhalten.
Zitat von: DS_Starter am 09 Oktober 2017, 21:48:54Allerdings habe ich mich dafür entschieden diese Funktion in DbRep zu implementieren.
Das wäre dann wohl ein guter Grund mich mit DbRep zu beschäftigen.
Nur liegt derzeit mein Testsystem im Sterben(Festplatte oder SATA Controller) und mir fehlt gerade ein wenig die Zeit um mich darum zu kümmern.
Gruß und gute Nacht
Pyro
Hallo Heiko,
das ist mal wieder eine tolle Weiterentwicklung, herzlichen Dank!
Ich habe es auf meinem älteren rpi1 getestet und dort läuft es wunderbar, lediglich
Zitat von: DS_Starter am 09 Oktober 2017, 21:48:54
(konsequenterweise müsste ich im DbLog das Attr DbLogType noch um eine Auswahlmöglichkeit "samplefill/history" ergänzen. Bei dieser Auswahl wird die current nicht aktiv geloggt, aber bei der SVG-Erstellung ausgewertet. Damit könnte man sie ausschließlich regelmäßig über DbRep füllen).
diese Erweiterung bräuchte ich noch da die current-Tabelle den doch recht langsamen rpi1 mit seiner riesigen Datenbank (>20GB) doch recht stark belastet.
Um dies dennoch testen zu können habe ich für den Test einfach die SQL-Statements auskommentiert!
beste Grüße,
Joe
Hallo Pyro und Joe,
danke für eure Rückmeldungen.
Das Attr in DbLog werde ich noch erweitern.
Habe heute festgestellt dass meine verwendete Syntax für mysql und sqlite prima klappt, aber für postgre schiefgeht.
Es braucht ofensichtlich eine etwas abgewandelte Syntax.
Ihr seht das Statement mit verbose 4 im DbRep.
Vllt könnt ihr mir helfen und den richtigen Aufruf für Postgre eruieren.
Habe grad wenig Zeit ...
LG
Heiko
Hallo zusammen,
für PostgreSQL habe ich nun auch ein passendes Statement gefunden. Getestet habe ich es auf Postgre ohne primary key. Leider ist mein Postgre-Release zu klein um mit PK testen zu können.
In DbLog habe ich Attr DbLogType um die Auswahl "SampleFill/History" ergänzt. Damit ist die Zusammenarbeit zwischen beiden Modulen an dieser Stelle so wie ich es mir vorstelle. Ist diese Auswahl eingestellt, wird nur in die History geloggt, die current Tabelle wird aber bei der SVG-Erstellung ausgewertet sofern mit "DbRep set tableCurrentFillup" aufgefüllt wurde und damit Werte enthält.
Der Einfachheit halber sind beide Module zum Test hier angehängt.
Freue mich auf eure Ergebnisse dazu.
Grüße
Heiko
Hallo Heiko,
ich habe die neue Version gerade au einem größeren System getestet.
Funktioniert toll, DANKE!
Gerade das Einschränken der current-Tabelle über die Devices ist ein mächtiges Feature, kann aber auch zu Missverständnissen führen.
GGf. sollte man darauf in der Statusnachricht des Readings hinweisen. (da sogar der Purge-Befehl nur die dort genannten Devices löscht)
Verwirrend finde ich (vielleicht denke ich gerade falsch) einen Teil der Logausgabe.
Aggregation wird (denke ich) nicht verwendet, sollte dort demnach auch nicht ausgegeben werden.
Auch Meldungen wie (die zweite Zeile)
2017.10.11 09:03:09 4: DbRep CurrentTable - Command: tableCurrentPurge
2017.10.11 09:03:09 5: DbRep CurrentTable - Daylight savings changed: 0 (on Sat Mar 4 00:00:00 2017)
machen bei" tableCurrentPurge" denke ich keinen Sinn, oder?
beste Grüße
Joe
Hi Joe,
ja ich kann statecnoch etwas aufbessern. Bis verbose 5 hatte ich noch garnicht getestet ;)
Aber purge löscht jeden Inhalt der current. Siehst du auch am Statement. Schau da bitte nochmal.
Ist ein einfaches "delete from current".
LG
Heiko
Zitat von: DS_Starter am 11 Oktober 2017, 10:26:15
Ist ein einfaches "delete from current".
Nein... ;-)
Auszug aus dem Log
2017.10.11 10:03:10 4: DbRep CurrentTable - SQL execute: Delete FROM current where DEVICE = 'Manuell' AND READING = 'Strom' AND 1;
2017.10.11 10:03:10 5: DbRep CurrentTable - Number of deleted rows: 0Und die Tabelle wurde nicht leer! Nach dem Löschen des Attributs Device und Reading hat es funktioniert.
sG
Joe
Uuups .... ändere ich .... danke ! :)
Bei der Befüllung der Current wird dies auch verwendet, da sehe ich es aber eher als Vorteil, da ich zB über "excludes" Dinge ausnehmen kann, die ich da eigentlich nicht haben möchte
(wie zB Wetterdaten).
sG
Joe
Ja da wollte ich es auch so haben, beim Löschen nicht
Hi Joe,
habe die DbRep 5.7.1 in #482 nachgebessert und neu hochgeladen.
Bitte teste erneut.
VG
Heiko
Hallo zusammen,
inzwischen habe ich die neuen DbRep/DbLog-Versionen noch etwas getestet und auch die commandref ergänzt.
Spricht aus eurer Sicht etwas dagegen diese Versionen einzuchecken ?
( Vllt. sollten wir noch auf die Ergebnisse von Pyro warten, aber ich weiß nicht wie lange er noch "out of order" sein wird.)
VG
Heiko
Guten Abend die Runde,
mangels Testsystem hab ich vorhin die Module in meinem Livesystem eingespielt und werde sie über Nacht testen.
Morgen folgt ein kurzer Bericht.
Wünsche einen angenehmen Start ins Wochenende
Pyro
Hallo Heiko,
an erster Stelle muss ich ein herzliches DANKE aussprechen, die Funktion verhält sich wie gewünscht und ich konnte keine Seiteneffekte entdecken :)
Mein Langzeitarchiv enthält derzeit ca. 40 Mio Einträge, das füllen der "current" Tabelle dauert gerade mal 40 Sekunden und umfasst dann ca. 960 Einträge. SVG Diagramme erstellen oder editieren funktioniert absolut problemlos und deutlich komfortabler als bisher.
Einzig die Device und readings sind durcheinander, da würde ich vorschlagen an die Abfrage hinten noch ein ORDER BY 2 ASC, 3 ASC(PostgreSQL) dranzuhängen, dann sind die devices sowie die readings alle sortiert.
Danke und gute Nacht
Pyro
Hallo, also bei mir läuft die neue Version ebenfalls sehr unauffällig!
Beste Grüße, Joe
Guten Morgen allerseits,
sieht ja schon gut aus.
@Pyro, ich habe die DbRep in #482 so wie von dir vorgeschlagen modifiziert. Kannst du bitte nochmal checken ob es jetzt wie gewünscht funktioniert ?
VG
Heiko
Mahlzeit Heiko,
die Daten stehen jetzt sauber sortiert in der current Tabelle drinnen, aber bei den SVG Diagrammen sind die Einträge dennoch durcheinander. Ich mach mich da mal auf die Suche weshalb dort eine andere Sortierung vorgenommen wird.
Aus meiner Sicht spricht nichts gegen einchecken der Version.
Grüße
Pyro
Hi Pyro,
habe in #482 die DbLog-Version an der Select-Stelle für die Current noch um eine Sortierfunktion ergänzt.
Schau mal ob das bei dir nun klappt.
Bei meiner Postgre-Testinstallation war allerdings schon bisher die Sortierung ok. Ist aber noch eine ältere Version auf der Synology (
09.03.1400).
Vielleicht gibt es ja bei Postgres so etwas wie eine Default Einstellung für die Sortierung. Aber ist nur eine Vermutung. Ich habe an der Parametrisierung meiner Postrgres nie etwas geändert. Es ist ist ja auch die DB die Synology für ihre internen Applikationen verwendet. Da will ich nicht soviel herumschrauben.
Grüße,
Heiko
Hallo Heiko,
leider ohne Erfolg, siehe Screen.
Wie lautet den die Abfrage? Dann probiere ich die mal direkt auf der DB aus.
Gruß
Pyro
Hi Pyro,
ich glaube schon dass es funktioniert, nur werden wahrscheinlich zuerst die Devices mit Großbuchstaben zuerst angezeigt. Bei dir dummerweise mit "Z" beginnend. Schau mal ob die nachfolgenden, klein geschriebenen devices:readings, dann richtig sortiert sind. Wenn meine Theorie stimmt, passt das alles.
Du kannst aber gerne experimentieren. Schau in DbLog Zeile 4306:
my $query = "select device,reading from current where device <> '' group by device,reading ORDER BY device ASC, reading ASC";
Das Order by kann ich demnach wieder rausnehmen.
LG
Heiko
Ich denke ich habs.
Verwende das Statement:
my $query = "select device,reading from current where device <> '' group by device,reading ORDER BY LOWER(device) ASC, LOWER(reading) ASC";
Oder benutze gleich die hier angehängte DbLog zum Test.
Leider unverändert, die neue DbLog Version liefert das gleiche Ergebnis.
Beide Abfragen liefern das richtig sortierte Ergebnis.
Zitat von: DS_Starter am 14 Oktober 2017, 17:38:12
my $query = "select device,reading from current where device <> '' group by device,reading ORDER BY device ASC, reading ASC";
Zitat von: DS_Starter am 14 Oktober 2017, 17:50:48my $query = "select device,reading from current where device <> '' group by device,reading ORDER BY LOWER(device) ASC, LOWER(reading) ASC";
Hmm, dann liegts aber nicht am Statement. Ich schau mal ...
So, alle guten Dinge sind drei. ;)
Es lag wohl eher an der Sortierung der Vorschlagliste die im Return zurück gegeben wird.
Habe die Version in #499 nochmal angepasst ... probier mal bitte.
Grüße
Heiko
Ich darf mit Freude vermelden: es funktioniert und die Sortierung stimmt :)
Danke für deinen Einsatz!
Gruß
Pyro
:)
Dann ckecke ich das Pärchen DbRep/DbLog ins SVN ein.
Ist dann morgen früh im Update.
Bis zum nächsten mal ...
LG
Heiko
Hallo zusammen,
ich habe auf meine RPI3 heute auf stretch upgedatet. RPI und fhem laufen problemlos, aber die Verbindung zu meine mySQL Server (anderer Rechner) klappt nicht mehr, weil an den Rechnername ein local angehängt wird:
log/fhem-2017-10.log:2017.10.16 22:37:59.443 2: DbLog logdb - Error: DBI connect('database=fhem;host=starstore.cgnf.net;port=3306','fhemuser',...) failed: Host 'StarHome.local' is not allowed to connect to this MySQL server at ./FHEM/93_DbLog.pm line 1712.
Ich kann aber nirgends eine Einstellung in fhem oder im RPI finden, in dem der hostname mit .local erscheint. Ich möchte ungern die Änderung im Datenbankserver vornehmen.
Hat jemand eine Idee, wie ich das local wieder los werden und DBLog nur den Rechnernamen oder den FQDN zur Anmeldung verwendet?
Beste Grüße
Torsten
Hallo Torsten,
also in DbLog wird nichts angehängt und du kannst auch im Modul diesbezüglich nichts einstellen. Dei Raspi heißt offensichtlich nun 'StarHome.local' und dieser Host ist nicht berechtigt sich remote zu connecten.
Was steht denn in /etc/hostname bzw. /etc/hosts ?
Grüße
Heiko
Hallo Heiko,
beides habe ich schon kontrolliert und weder in der hostname noch in hosts ist hinter dem Rechnernamen ein local zu finden. In der hostname steht nur der Name und in der hosts gibt es zwei einträge nur name und fqdn.
Kann es sein, dass sich DHCP unter stretch anders verhält, als unter jessie?
Gruß
Torsten
Hi Torsten,
Das kann ich dir leider nicht beantworten. Ich habe nur Jessie im Einsatz.
Das einfachste wäre IMHO in MySQL mit deiner Admin-Oberfläche den Host (oder vllt. alle Hosts -> "%") zum Connect zu berechtigen.
Kommt natürlich darauf an ob du das möchtest. Ansonsten würde ich mal Google bemühen ...
Grüße
Heiko
Hallo Heiko,
die Fehlermeldung führt total in die Irre... es lag daran, dass nach dem update auf stretch mysql-client und die perl-lib für mysql wieder installiert werden musste.
Gruß
Torsten
krass ... gut zu wissen :)
Grüsse,
Heiko
Guten Abend zusammen,
ich habe DbRep erweitert um das device-Attribut nun mit Devspec-Syntax angeben zu können.
Damit steht bei der Auffüllung der Current-Tabelle eine komfortablere Abgrenzung der zu berücksichtigenden Device-Datensätze zur Verfügung.
Weitere Infos dazu sind hier: https://forum.fhem.de/index.php/topic,53584.msg700877.html#msg700877
Würde mich über Testergebnisse freuen.
VG
Heiko
Hallo,
habe herausgefunden wieso der "state" im DbLog manchmal unleserliche Zeichen enthielt und ist nun in der hier angehängten Version 2.22.12 gefixt.
Ich checke die Version dann auch ins SVN ein.
Grüße
Heiko
Hallo Heiko,
22.12 zeigt keinerlei Auffälligkeiten :-)
DbRep werde ich mir am Wochenende genauer anschauen.
Gute Nacht zusammen
Pyro
Danke fürs einchecken, funktioniert bei mir wunderbar.
Hallo zusammen,
Es gab noch eine Funktion die wir im ersten Beitrag notiert hatten:
#27 Eine Funktion ähnlich der average funktion, aber für nicht-numerische werte, also löschen aller records, ausser VALUE ändert sich, behalten von min 1 Wert/Stunde bzw. Tag... (werner)
So etwas habe ich jetzt in DbRep realisiert. Es wird auch mindestens der erste und letzte Datensatz eines Tages in der DB behalten.
https://forum.fhem.de/index.php/topic,53584.msg723924.html#msg723924
EDIT: inzwischen kann man über aggregation wählen ob mindestens der erste und letzte Datensatz eines Tages, einer Stunde, Woche usw. behalten werden soll.
Grüße
Heiko
Hi,
auch von mir erstmal Respekt für die Arbeit, die ihr hier geleistet habt. Hab mich im Laufe der letzten drei Tage mal durch alle 35 Seite gearbeitet :-)
Dann hab ich mein Contrib auf vordermann gebracht (dafür gibts auch keine richtige Anleitung, oder?)
und jetzt das neue DbLog getestet. Dabei ist mir aufgefallen, dass im state unleserliche Zeichen enthalten waren. Allerdings wollte ich nicht von Seite 20 direkt eine Antwort posten - und jetzt ist der State wieder prima.
Ich benutze Mysql mit etwa 90 Mio. Einträgen in der history-Datenbank.
meine 93_DbLog.pm ist die Version:
Zitat$Id: 93_DbLog.pm 15517 2017-11-28 20:22:56Z DS_Starter $
Wenn ihr noch Infos braucht - ich hab keinerlei Ansatzpunkt - dann meldet euch.
Danke nochmal an alle,
Stephan
Hallo Stephan,
dieses Verhalten war bekannt, ist aber mit der Version 2.22.12 vom 19.10.2017 behoben.
Mit der von dir zitierten Version sollte es nicht mehr auftreten (ist es bei mir und auch den Testern nicht mehr aufgetreten).
Grüße
Heiko
Da ich grad angemeldet bin möchte ich euch auch gleich die aktuellste DbLog zum Download anbieten und euch bitten die Version bei euch zu testen und zu schauen ob alles wie gewohnt läuft:
* die Ausgaben sind erweitert (verbose 4), man sieht z.B. mit welchem AutoCommit mode die Session läuft (On/Off), bzw. wieviele Datensätze eines Sync-Laufs commited wurden und welche rejected wurden -> Beispiel:
2017.12.03 20:36:48.701 4: DbLog LogDB1 -> ################################################################
2017.12.03 20:36:48.702 4: DbLog LogDB1 -> ### New database processing cycle - asynchronous ###
2017.12.03 20:36:48.703 4: DbLog LogDB1 -> ################################################################
2017.12.03 20:36:48.703 4: DbLog LogDB1 -> MemCache contains 54 entries to process
2017.12.03 20:36:48.704 4: DbLog LogDB1 -> DbLogType is: SampleFill/History
2017.12.03 20:36:48.718 4: DbLog LogDB1 -> AutoCommit mode: ON
2017.12.03 20:36:48.856 3: DbLog LogDB1 -> Insert into history rejected (possible PK violation) - TS: 2017-12-03 20:36:02, Device: Rep.Show.DbSize, Event: state: done
2017.12.03 20:36:48.857 3: DbLog LogDB1 -> Insert into history rejected (possible PK violation) - TS: 2017-12-03 20:36:02, Device: SDS1_SVS, Event: Errorcode: none
2017.12.03 20:36:48.858 3: DbLog LogDB1 -> Insert into history rejected (possible PK violation) - TS: 2017-12-03 20:36:02, Device: SDS1_SVS, Event: Error: none
2017.12.03 20:36:48.858 3: DbLog LogDB1 -> Insert into history rejected (possible PK violation) - TS: 2017-12-03 20:36:02, Device: SDS1_SVS, Event: Errorcode: none
2017.12.03 20:36:48.859 3: DbLog LogDB1 -> Insert into history rejected (possible PK violation) - TS: 2017-12-03 20:36:02, Device: SDS1_SVS, Event: Error: none
2017.12.03 20:36:48.860 4: DbLog LogDB1 -> 49 of 54 events inserted into table history using PK on columns TIMESTAMP,DEVICE,READING
2017.12.03 20:36:48.861 4: DbLog LogDB1 -> insert history committed
2017.12.03 20:36:48.863 4: DbLog LogDB1 -> insert or update current committed
* für die reduceLog/Nbl habe ich Fortschrittsmitteilungen eingebaut, damit man sieht wo der Prozess ungefähr steht. Das gilt auch für das blockierende reduceLog. Hier muß man sich das Logfile außerhalb von fhem anschauen, z.B. mit tail -f <file>, um es zu verfolgen. Das ist sicherlich insbesondere bei lang laufenden Prozessen von Interesse. Beispiel:
2017.12.03 20:42:02.260 3: DbLog LogDB1: reduceLogNbl requested with DAYS=197, AVERAGE=DAY
2017.12.03 20:42:04.039 3: DbLog LogDB1: reduceLogNbl deleting 1448 records of day: 2017-05-18
2017.12.03 20:42:04.249 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-18 is: 100
2017.12.03 20:42:04.441 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-18 is: 200
2017.12.03 20:42:04.635 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-18 is: 300
......
2017.12.03 20:42:07.227 3: DbLog LogDB1: reduceLogNbl (hourly-average) updating 23 records of day: 2017-05-18
2017.12.03 20:42:07.316 3: DbLog LogDB1: reduceLogNbl (daily-average) updating 33, deleting 629 records of day: 2017-05-18
2017.12.03 20:42:07.501 3: DbLog LogDB1: reduceLogNbl (daily-average) deleting progress of day: 2017-05-18 is: 100
2017.12.03 20:42:07.677 3: DbLog LogDB1: reduceLogNbl (daily-average) deleting progress of day: 2017-05-18 is: 200
2017.12.03 20:42:07.879 3: DbLog LogDB1: reduceLogNbl (daily-average) deleting progress of day: 2017-05-18 is: 300
.....
2017.12.03 20:42:09.317 3: DbLog LogDB1: reduceLogNbl deleting 39029 records of day: 2017-05-19
2017.12.03 20:42:29.305 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-19 is: 10000
2017.12.03 20:42:51.521 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-19 is: 20000
2017.12.03 20:43:12.680 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-19 is: 30000
....
* ein neues Attribut "autocommit". Man kann explizit den Autocommit-Modus der DB schalten. Gedacht ist es z.Zt. für Sonderfälle oder Supportfälle.
Standard ist "basic", d.h. wie bis jetzt auch wird die Servereinstellung verwendet, was meist Autocommit "ON" sein dürfte. Man kann den Modus mit dem Attr explizit on oder off schalten. Im Code habe ich nochmal besonders danach geschaut dass beide Varianten auch unterstützt werden.
* einige kleinere / kosmetische Anpassungen
Bitte gebt wieder Rückmeldung.
viele Grüße
Heiko
Hallo Heiko,
deswegen melde ich mich ja.
Wenn ich es nochmal sehe, versuche ich es festzuhalten - war blöd, dass ich es erst festgestellt und dann erst die Beiträge dazu gelesen hatte.
Zum Thema current/history:
Ich häng da ein bisschen fest. Ist es richtig, dass wenn ich eine current-tabelle nutze, im SVG dropdowns für Device und Reading habe (haben sollte)?
Ich habe:
eine Datenbank (DEVEL_fhem) angelegt
Tabellen (current und history) nach der db_create_mysql angelegt
ein DbLog-Device angelegt
ein DbRep-Device angelegt
bei DbLog
- attr DbLogDevice DbLogType SampleFill/History ausgewählt
bei DbRep
- set <DbRep-name> tableCurrentFillup ausgeführt
dann bei DbLog auf den "Create SVG"-Link geklickt
Aber im SVG hab ich für Reading und Device keine Dropdowns.
Mach ich was falsch, bzw, Was mache ich falsch?
btw: Ich muss jetzt für diese eine Funktion ein DbRep-Device besitzen. Wäre es eine Idee, ein Attribut "reloadCurrentTable" einzuführen, in dem man dann eine Uhrzeit ([12:00]),eine Zeitspanne eingeben kann (86400) oder ein Event, zu der/dem die current-Tabelle aktualisiert wird?
Grüße,
Stephan
ZitatIst es richtig, dass wenn ich eine current-tabelle nutze, im SVG dropdowns für Device und Reading habe (haben sollte)?
Ja, richtig.
Was du gemacht hast um das fllup auszuführen sieht erstmal richtig aus. Allerdings kommt es nun darauf an dass DbRep so eingestellt ist dass auch die Selektionen erfolgen können, also keine (bzw. die richtigen ! Zeit-, Device-, Reading EIngrenzungen).
Nach einem fillup kannst du im debrep mit set ... fetchrows current prüfen was dort drinsteht.
Steht denn etwas drin ?
Wenn nicht, wäre zu prüfen weshalb. Ich würde erstmal mit der ganz normalen Einstellung current/history starten um damit warm zu werden.
Zitatbtw: Ich muss jetzt für diese eine Funktion ein DbRep-Device besitzen. Wäre es eine Idee, ein Attribut "reloadCurrentTable" einzuführen, in dem man dann eine Uhrzeit ([12:00]),eine Zeitspanne eingeben kann (86400) oder ein Event, zu der/dem die current-Tabelle aktualisiert wird?
Genau dazu gibt es ja die Möglichkeit mit DbRep. Du kannst du über umfangreiche Einstellungsmöglichkeiten bestimmen womit die current Tabelle aufgefüllt werden soll, z.B. nur über die Selektionen des letzten Monats o.ä. Und wann das geschehen soll macht man über ein AT (so mache in es) , ja und wenn es ein Event sein soll tut es ein Notify ;)
Grüße
Heiko
Hi,
ZitatSteht denn etwas drin ?
Nein. Dafür hab ich folgenden Fehler:
Zitat
DBD::mysql::st execute failed: Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'DEVELfhem.history.TIMESTAMP' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3453.
Da ich nicht genau weiss, was ich jetzt wie gemacht hatte, mach ich grade alles nochmal.
Also "DROP DATABASE;" und jetzt neu anlegen.
Dabei fällt mir folgendes auf:
In diesem Thread gings oft um einen Primary Key. In der "db_create_mysql" wird aber *nur* der normale Index erzeugt. Gibt es bereits eine Anleitung, um den PK umzusetzen?
Also nicht, dass ich nicht einen PK erzeugen könnte.. aber Ich hatte den Eindruck, ihr habt viel getestet. Habt ihr einen optimalen herausgefunden?
So, ich habe meine Datenbank mit
ZitatCREATE DATABASE `DEVELfhem` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
CREATE USER 'DEVELfhemuser'@'%' IDENTIFIED BY 'stephan';
CREATE TABLE `DEVELfhem`.`history` (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
CREATE TABLE `DEVELfhem`.`current` (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
GRANT SELECT, INSERT, DELETE, UPDATE ON `DEVELfhem`.* TO 'DEVELfhemuser'@'%';
CREATE INDEX Search_Idx ON `DEVELfhem`.`history` (DEVICE, READING, TIMESTAMP);
erzeugt. in die Tabelle History werden auch Daten geschrieben.
Das füllen der Tabelle current mit dem SampleFill hingegen schlägt weiterhin fehl.
Danach hatte ich Probleme mit meinem live-logdb - es konnte nicht mehr connecten und vertröstete mich auf den nächsten Sync. Ein Shutdown restart" hat geholfen.
Umstellen auf Current/History funktioniert einwandfrei. Die current-Tabelle wird einwandfrei gefüllt. Jetzt hab ich auch Dropdowns.
Hab das ganze nochmal mit dbrep verbose 5 ausgeführt, kommen aber leider nicht mehr Meldungen als das
Zitat2017-12-04 10:00:14.508 DbRep DEVEL_repdb running
2017-12-04 10:00:14.711 DbRep DEVEL_repdb errortext: DBD::mysql::st execute failed: Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'DEVELfhem.history.TIMESTAMP' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3453.
2017-12-04 10:00:14.728 DbRep DEVEL_repdb error
Grüße,
Stephan
ZitatDBD::mysql::st execute failed: Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'DEVELfhem.history.TIMESTAMP' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3453.
Das ist natürlich ein Fehler der da nichts zu suchen hat. Mach mal bitte ein list deines DbRep-Devices.
Ich benutze ebenfalls MySQL (konkret MariaDB).
Bzgl. PK würde ich an die Beiträge von JoeAllb verweisen. Er hat viele Tests gemacht.
Meines Erachtens nach war dieser der günstigste (verwende ich ) für die history:
ALTER TABLE fhem.history ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);und die current:
ALTER TABLE `current` ADD PRIMARY KEY (DEVICE, READING);Grüße
Heiko
Hier ist das list:
ZitatInternals:
DATABASE DEVELfhem
DEF DEVEL_logdb
LASTCMD tableCurrentFillup
NAME DEVEL_repdb
NOTIFYDEV global,DEVEL_repdb
NR 737
NTFY_ORDER 50-DEVEL_repdb
ROLE Client
STATE error
TYPE DbRep
UTF8 0
VERSION 6.0.0
HELPER:
DBLOGDEVICE DEVEL_logdb
CV:
aggregation no
aggsec 1
destr 2017-12-04
dsstr 1970-01-01
epoch_seconds_end 1512378014
mestr 12
msstr 01
testr 10:00:14
tsstr 01:00:00
wdadd 345600
yestr 2017
ysstr 1970
READINGS:
2017-12-04 10:00:14 errortext DBD::mysql::st execute failed: Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'DEVELfhem.history.TIMESTAMP' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3453.
2017-12-04 10:00:14 state error
dbloghash:
COLUMNS field length used for Device: 64, Type: 64, Event: 0, Reading: 64, Value: 128, Unit: 32
CONFIGURATION ./db_DEVELfhem.conf
DEF ./db_DEVELfhem.conf .*:.*
MODE asynchronous
MODEL MYSQL
NAME DEVEL_logdb
NR 736
NTFY_ORDER 50-DEVEL_logdb
PID 11980
REGEXP .*:.*
STATE disabled
TYPE DbLog
UTF8 0
VERSION 2.22.15
dbconn mysql:database=DEVELfhem;host=localhost;port=3306
dbuser DEVELfhemuser
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 0
OLDSTATE disabled
READINGCOL 64
TYPECOL 64
UNITCOL 32
VALUECOL 128
Helper:
DBLOG:
state:
DEVEL_logdb:
TIME 1512377850.21721
VALUE disabled
READINGS:
2017-12-04 09:57:37 CacheUsage 1
2017-12-04 09:57:30 NextSync 2017-12-04 09:58:00 or if CacheUsage 500 reached
2017-12-04 09:57:37 state disabled
cache:
index 925
memcache:
925 2017-12-04 09:57:30|DEVEL_logdb|DBLOG||state|disabled|
Attributes:
room Logging,x_devel
Wegen dem PK:
Wenn der besser ist, würde ich vorschlagen, den (ggf mit kommentar) in die db_create.* zu übernehmen... Zum testen lass ichs jetzt erstmal original lt. Anleitung.
Bin eh dran, um meine DB zu optimieren, dafür brauch ich die Test-, bzw. Backup-DB.
Grüße,
Stephan
Hallo Stephan,
das Problem kommt durch eine Servereinstellung, die offensichtlich bei dir (oder MySQL) und MariaDB nicht identisch ist.
Habe im Modul eine Gegenmassnahem eingebaut.
Probiere mal ob es mit der angehängten V6.3.1 auch bei dir funktioniert.
Grüße
Heiko
Hi,
klappt. Vielen Dank.
Welche Option hat denn das Problem verursacht?
Ich habe ein bisschen das Gefühl, ich hab meine DB kaputtoptimiert, deshalb beschäftige ich mich grade etwas damit. Evtl kommt dann demnächst auch mal ein kompletter reinstall ...
Grüße,
Stephan
Hi Stephan,
der in der Fehlermeldung drin steht:
Zitat...GROUP BY clause; this is incompatible with sql_mode=only_full_group_by
Habe dann ein bisschen gegoogelt.
Aber schön dass es jetzt klappt. Wer weiß wie oft das sonst noch hochkommen würde.
Grüße
Heiko
Hi,
seit gestern abend sind keine Daten mehr in die Datenbank geschrieben worden.
Mein Log ist voll von solchen Meldungen:
Zitat2017.12.06 18:32:49.344 5: DbLog logdb -> processing event Timestamp: 2017-12-06 03:28:21, Device: RE_TEMP_Ruecklauf_Solar, Type: DUMMY, Event
: , Reading: temperature, Value: 21.56, Unit:
2017.12.06 18:32:49.344 5: DbLog logdb -> processing event Timestamp: 2017-12-06 03:28:22, Device: Stromzaehler, Type: VZ, Event: , Reading: t
otal_power_L1, Value: 154, Unit:
2017.12.06 18:32:49.344 5: DbLog logdb -> processing event Timestamp: 2017-12-06 03:28:22, Device: RE_TEMP_Vorlauf_EG_Boden, Type: DUMMY, Even
t: , Reading: temperature, Value: 25.25, Unit:
2017.12.06 18:32:49.345 5: DbLog logdb -> processing event Timestamp: 2017-12-06 03:28:23, Device: RE_TEMP_Ruecklauf_EG_Boden, Type: DUMMY, Ev
ent: , Reading: temperature, Value: 23.81, Unit:
2017.12.06 18:32:49.345 5: DbLog logdb -> processing event Timestamp: 2017-12-06 03:28:24, Device: RE_TEMP_Ruecklauf_WT_EG, Type: DUMMY, Event
: , Reading: temperature, Value: 24.56, Unit:
Zitat
2017.12.06 00:00:43.228 2: DbLog logdb -> Error table history - DBD::mysql::st execute_array failed: executing 540 generated 2 errors at ./FHEM/93_DbLog.pm line 1866.
2017.12.06 00:00:46.636 2: DbLog logdb -> Error table history - DBD::mysql::st execute_array failed: executing 598 generated 2 errors at ./FHEM/93_DbLog.pm line 1866.
2017.12.06 00:00:48.887 2: DbLog logdb -> Error table history - DBD::mysql::st execute_array failed: executing 608 generated 2 errors at ./FHEM/93_DbLog.pm line 1866.
2017.12.06 00:00:50.746 2: DbLog logdb -> Error table history - DBD::mysql::st execute_array failed: executing 618 generated 2 errors at ./FHEM/93_DbLog.pm line 1866.
2017.12.06 00:00:52.917 2: DbLog logdb -> Error table history - DBD::mysql::st execute_array failed: executing 626 generated 2 errors at ./FHEM/93_DbLog.pm line 1866.
2017.12.06 18:39:27.109 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:27.213 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:27.761 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:28.282 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:28.285 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:28.288 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:28.395 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:28.940 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:29.484 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:30.150 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:30.153 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:30.156 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:30.580 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:31.124 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:31.683 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:32.018 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:32.021 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:32.160 5: CUL/RAW: /TED84CE02F1
2017.12.06 18:39:32.161 4: CUL_Parse: CUL_0 TED84CE02F1 -81.5
2017.12.06 18:39:32.162 5: CUL_0: dispatch TED84CE02
2017.12.06 18:39:32.241 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:32.655 5: CUL/RAW: /TED84CE82F1
2017.12.06 18:39:32.655 4: CUL_Parse: CUL_0 TED84CE82F1 -81.5
2017.12.06 18:39:32.656 5: CUL_0: dispatch TED84CE82
2017.12.06 18:39:32.718 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:32.721 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:32.724 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:32.802 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:32.805 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:32.867 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
2017.12.06 18:39:33.521 5: DbLog logdb -> Number of cache entries reached cachelimit 500 - start database sync.
Auch ein attr logdb verbose 5 scheint nicht mehr output zu generieren.
Kann jemand helfen?
Was kann ich tun?
Grüße,
Stephan
PS: beim "list logdb" hängt sich fhem auf.
deshalb gibts hier nen Screenshot.
Hi Stephan,
du hast 2 Datensätze die nicht in die DB wollen und Fehler versursachen. Letztlich hatte jemand genau den gleichen Fall weil seine Feldgrößen in der DB von den im DbLOg-Device verwendeten Größen unterschiedlich waren.
Zur Lösung schlage ich rstmal vor vor:
* setze dir cacheLimit hoch (5000) damit etwas Ruhe herrscht. Gleiches gilt für Syncinterval
* mache eine cacheexport "set ... exportcache nopurge" damit keine Daten verloren gehen
* dann führe mal "set ... configCheck" aus und poste was du siehst.
Hi,
ich hab unten mal nen configCheck gesetzt, aber:
Da FHEM bereits aufgegeben hat (nicht mehr bedienbar, deshalb habe ich neu gestartet) sind die Daten nicht mehr im Cache.
Habe aber die TEST-Instanz noch laufen, da wurden die Daten geloggt.
Weiss auch nicht, ob dir das configCheck jetzt noch hilft:
Result of connection check
Connection to database fhem successfully done.
Recommendation: settings o.k.
Result of encoding check
Encoding used by Client (connection): LATIN1
Encoding used by DB fhem: UTF8
Recommendation: Both encodings should be identical. You can adjust the usage of UTF8 connection by setting the UTF8 parameter in file './db_fhem.conf' to the right value.
Result of logmode check
Logmode of DbLog-device logdb is: asynchronous
Recommendation: settings o.k.
Result of table 'history' check
Column width set in DB fhem.history: 'DEVICE' = 64, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 64, 'UNIT' = 32
Column width used by logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 0, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: The relation between column width in table history and the field width used in device logdb don't meet the requirements. Please make sure that the width of database field definition is equal or larger than the field width used by the module. Compare the given results.
Currently the default values for field width are:
DEVICE: 64
TYPE: 64
EVENT: 512
READING: 64
VALUE: 128
UNIT: 32
You can change the column width in database by a statement like 'alter table history modify VALUE varchar(128);' (example for changing field 'VALUE'). You can do it for example by executing 'sqlCMD' in DbRep or in a SQL-Editor of your choice. (switch logdb to asynchron mode for non-blocking).
The field width used by the module can be adjusted by attributes 'colEvent', 'colReading', 'colValue',
Result of table 'current' check
Column width set in DB fhem.current: 'DEVICE' = 64, 'TYPE' = no result, 'EVENT' = no result, 'READING' = 24, 'VALUE' = 24, 'UNIT' = no result
Column width used by logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 0, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: The relation between column width in table current and the field width used in device logdb don't meet the requirements. Please make sure that the width of database field definition is equal or larger than the field width used by the module. Compare the given results.
Currently the default values for field width are:
DEVICE: 64
TYPE: 64
EVENT: 512
READING: 64
VALUE: 128
UNIT: 32
You can change the column width in database by a statement like 'alter table current modify VALUE varchar(128);' (example for changing field 'VALUE'). You can do it for example by executing 'sqlCMD' in DbRep or in a SQL-Editor of your choice. (switch logdb to asynchron mode for non-blocking).
The field width used by the module can be adjusted by attributes 'colEvent', 'colReading', 'colValue',
Result of check 'Search_Idx' availability
Index 'Search_Idx' exists and contains the recommended fields 'DEVICE', 'READING', 'TIMESTAMP'.
Recommendation: settings o.k.
Result of check 'Report_Idx' availability for DbRep-devices
You use at least one DbRep-device assigned to logdb, but the recommended index 'Report_Idx' is missing.
Recommendation: You can create the index by executing statement 'CREATE INDEX Report_Idx ON `history` (TIMESTAMP, READING) USING BTREE;'
Depending on your database size this command may running a long time.
Please make sure the device 'logdb' is operating in asynchronous mode to avoid FHEM from blocking when creating the index.
Note: If you have just created another index which covers the same fields and order as suggested (e.g. a primary key) you don't need to create the 'Report_Idx' as well !
Okay, erstmal als Antwort. Ich hab schon gesehn, da sind ein paar Sachen im argen, ich arbeite das erstmal durch.
Was ich aber loswerden wollte:
Kannst du für den Fall eine Fehlermeldung schreiben/generieren, die mir sagt, was das Problem ist?
Oder war das die Stelle, wo du meintest, dass dir die Datenbank nur einen allgemeinen Fehler liefert, aus dem du keine weiteren Infos holen kannst?
Und mich würde interessieren, warum (dadurch? ) FHEM abstürzt...
Wenn ich noch Infos liefern kann, lass es mich wissen!
Grüße,
Stephan
Hi Stephan,
ja, der Check war hilfreich un aufschlussreich. Das Problem ist dadurch verursacht:
Zitat
Column width set in DB fhem.history: 'DEVICE' = 64, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 64, 'UNIT' = 32
Column width used by logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 0, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
MySQL ist da etwas empfindlich bei solchen Misskonfigurationen, dafür gibts diesen Check.
Du kannst das Feld Reading vergrößern (empfohlen) oder per Attribut colReading im Modul beschränken.
Bei der current-Tabelle sieht es noch schlimmer aus. Da musst du mal ran.
ZitatKannst du für den Fall eine Fehlermeldung schreiben/generieren, die mir sagt, was das Problem ist?
Naja, stand ja da. ;) Man muß es nur interpretieren können.
ZitatUnd mich würde interessieren, warum (dadurch? ) FHEM abstürzt...
Nun, ich denke nicht dass FHEM "abgetürzt" ist. Du hast ein "list device" gemacht. Leider waren unmengen an Daten im Cache der im Browser angezeigt werden sollte. Dadurch war deine Browsersession überlastet. Wahrscheinlich hätte sich sich mit viel Geduld wieder eingekriegt.
Aber ich hatte dieses generelle Problem erkannt und mit etlichen weiteren Änderungen und einem Bugfix wegen dieses Problems:
https://forum.fhem.de/index.php/topic,80519.0.html
eine überarbeitet Version erstelt. Damit sollte es auch Geschichte sein dass wegen einem oder 2 Datensätzen der ganze Cache nicht in der Datenbank persistiert werden kann.
Das Problem mit dem "list Device" nehme ich mal mit auf die Agenda damit sowas nicht mehr vorkommt.
Die neue Version hänge ich gleich mit Begleittext hier an.
Bitte lade sie dir runter setze sie ein.
Eigentlich wäre es jetzt erstmal gut wenn du an der DB noch nichts richten würdest damit wir im Fehlerfall sehen wie das Modul reagiert.
Hat ein bisschen was von Versuchskaninchen....sorry :D
Grüße
Heiko
Eigentlich wäre es jetzt erstmal gut wenn du an der DB noch nichts richten würdest damit wir im Fehlerfall sehen wie das Modul reagiert.
Hat ein bisschen was von Versuchskaninchen....sorry :D
Kein Problem, dafür bin ich ja hier unterwegs. :-)
Hab nur jetzt leider schon die ersten spalten verbreitert... Würde die TEST-Datenbank mal so hinbauen, wie die live-DB war/ist, dann müsste man den Fehler ja auch sehen... oder?
Was mir grade nicht so klar war: warum hatte auch das zweite logDB-Device, welches auf eine getrennte Datenbank (auf dem gleichen Server) loggt, Probleme? Sollten die nicht unabhängig voneinander laufen?
EDIT: die Spalte TYPE ließ sich schnell anpassen, die Spalte READING scheint deutlich aufwendiger zu sein ...
Grüße,
Stephan
ZitatWas mir grade nicht so klar war: warum hatte auch das zweite logDB-Device, welches auf eine getrennte Datenbank (auf dem gleichen Server) loggt, Probleme? Sollten die nicht unabhängig voneinander laufen?
Davon hatte ich bisher nichts gelesen. Du hattest nur geschrieben :
ZitatHabe aber die TEST-Instanz noch laufen, da wurden die Daten geloggt.
Was gabs da für Probleme ?
ZitatWürde die TEST-Datenbank mal so hinbauen, wie die live-DB war/ist, dann müsste man den Fehler ja auch sehen... oder?
DAs wäre gut ... und ja, früher oder später.
ZitatWas gabs da für Probleme ?
Ja, die Daten wurden geloggt.
Sorry, für das durcheinander, ich hab leider noch nicht so richtig den Durchblick, was hier was macht.
Die TEST-Instanz hatte insofern Probleme, dass die Fehlermeldung kam, dass die Daten nicht geschrieben werden konnten und es erneut versucht wird.
Die genaue Fehlermeldung hab ich leider grad nicht da, weil ich die Datenbank jetzt nicht noch zusätzlich stressen will...
Ab und zu muss es aber funktioniert haben, dann wurde der Cache von 3000-4000 wieder auf 0 gesetzt.
Vielleicht hat der Fehler im live-logdb die Datenbank so belastet, dass das Test-logdb nicht mehr richtig durchgekommen ist?
Nur mal als Idee, wie wäre es, wenn bei Problemen mindestens xxx Sekunden gewartet wird (zb. 1x SyncInterval), zusätzlich wird eine Datei angelegt und die vorhandenen/auflaufenden Nachrichten dort hineingeschrieben. Sobald der commit funktioniert hat, wird die Datei wieder gelöscht. Evtl. Optional ein Threshold, der einstellt, wie oft der commit fehlschlagen muss, bis so eine Datei erzeugt wird...
Grüße,
Stephan
Zitat
Die TEST-Instanz hatte insofern Probleme, dass die Fehlermeldung kam, dass die Daten nicht geschrieben werden konnten und es erneut versucht wird.
Die genaue Fehlermeldung hab ich leider grad nicht da, weil ich die Datenbank jetzt nicht noch zusätzlich stressen will...
Ab und zu muss es aber funktioniert haben, dann wurde der Cache von 3000-4000 wieder auf 0 gesetzt.
Vielleicht hat der Fehler im live-logdb die Datenbank so belastet, dass das Test-logdb nicht mehr richtig durchgekommen ist?
Auszuschließen wäre so etwas nicht wenn die Ressourcen aufgebraucht sind und die DB nicht mehr richtig arbeiten kann. Im Nachhinein kann man da nur mutmassen.
ZitatNur mal als Idee, wie wäre es, wenn bei Problemen mindestens xxx Sekunden gewartet wird (zb. 1x SyncInterval), zusätzlich wird eine Datei angelegt und die vorhandenen/auflaufenden Nachrichten dort hineingeschrieben. Sobald der commit funktioniert hat, wird die Datei wieder gelöscht. Evtl. Optional ein Threshold, der einstellt, wie oft der commit fehlschlagen muss, bis so eine Datei erzeugt wird...
Die Sache mit der Datei kannst du dir bereits jetzt bauen.
Es gibt das Attr "cacheEvents" (siehe commandref). Setze dir das auf 2 und werte die Events mit einem Notify aus. Überschreitet der Wert einen Schwellenwert (natürlich höher) als cacheLimit, schreibe dir den Cache raus "set ... exportCache" . Wahlweise mit den Optionen purge/nopurge.
Und lasse dich informieren -> Mail/Telegram , what ever damit du reagieren kannst.
Das mit der Wartezeit bei Überschreiten des cacheLimits bei Fehler überlege ich mir mal.
Manchmal ist ein Fehler auch kein Fehler, zum Beispiel weil der User ein Offline Backup angeworfen hat oder die DB zur Wartung gestoppt hat usw. In dem Fall weiß er wieso die Fehler geworfen werden ...
Aber grundsätzlich braucht man solche Verrenkungen garnicht machen. Wichtig ist die Ursache zu erkennen und zu beheben, in deinem Fall eine schlecht eingestellte Datenbank die früher oder später Probleme bereiten _muss_.
Gerade MySQL/MariaDB ist eine super dankbare DB die, richtig erstellt, einfach nur läuft, läuft, läuft .... 8)
So, jetzt teste ich die neue V noch etwas und stelle sie dann hier ein.
Grüße
Heiko
Hallo zusammen,
in den letzten paar Tagen sind noch ein/zwei Issues aufgetreten, die mich veranlasst haben die hier angehängte Version 3.2.0 zu erstellen. Hier die Änderungen/Ergänzungen zur eingecheckten V2.22.15. zusammengefasst:
* neues Attribut "useCharfilter"
Erlaubt nur die ASCII Zeichen von 32 bis 126 im Datensatz. Umlaute und "€" werden umgesetzt.
* ein neues Attribut "commitMode"
Ändert das Autocommit- bzw. Transaktionsverhalten der DB. Dadurch ist es möglich mit den Tabellen ohne Transaktionen zu arbeiten.
Im Code habe ich nochmal besonders danach geschaut dass alle Varianten unterstützt werden.
(Advanced Feature)
* die Ausgaben sind erweitert (verbose 4), man sieht z.B. mit welchem AutoCommit/Transaktionsmode die Session läuft, bzw. wieviele Datensätze eines Sync-Laufs committed/rejected wurden -> Beispiel:
2017.12.06 18:46:00.104 4: DbLog LogDB -> ################################################################
2017.12.06 18:46:00.105 4: DbLog LogDB -> ### New database processing cycle - asynchronous ###
2017.12.06 18:46:00.106 4: DbLog LogDB -> ################################################################
2017.12.06 18:46:00.107 4: DbLog LogDB -> MemCache contains 50 entries to process
2017.12.06 18:46:00.107 4: DbLog LogDB -> DbLogType is: Current/History
2017.12.06 18:46:00.133 4: DbLog LogDB -> AutoCommit mode: ON, Transaction mode: ON
2017.12.06 18:46:00.276 4: DbLog LogDB -> 50 of 50 events inserted into table history using PK on columns TIMESTAMP,DEVICE,READING
2017.12.06 18:46:00.278 4: DbLog LogDB -> insert history committed
2017.12.06 18:46:00.343 4: DbLog LogDB -> 50 of 50 events updated in table current using PK on columns DEVICE,READING
2017.12.06 18:46:00.345 4: DbLog LogDB -> insert / update table current committed
* für die reduceLog/Nbl sind Fortschrittsmitteilungen eingebaut, damit man sieht wo der Prozess ungefähr steht. Das gilt auch für das blockierende reduceLog.
Hier muß man sich das Logfile außerhalb von fhem anschauen, z.B. mit tail -f <file>, um es zu verfolgen. Das ist sicherlich insbesondere bei lang laufenden Prozessen von Interesse. Beispiel:
2017.12.03 20:42:02.260 3: DbLog LogDB1: reduceLogNbl requested with DAYS=197, AVERAGE=DAY
2017.12.03 20:42:04.039 3: DbLog LogDB1: reduceLogNbl deleting 1448 records of day: 2017-05-18
2017.12.03 20:42:04.249 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-18 is: 100
2017.12.03 20:42:04.441 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-18 is: 200
2017.12.03 20:42:04.635 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-18 is: 300
......
2017.12.03 20:42:07.227 3: DbLog LogDB1: reduceLogNbl (hourly-average) updating 23 records of day: 2017-05-18
2017.12.03 20:42:07.316 3: DbLog LogDB1: reduceLogNbl (daily-average) updating 33, deleting 629 records of day: 2017-05-18
2017.12.03 20:42:07.501 3: DbLog LogDB1: reduceLogNbl (daily-average) deleting progress of day: 2017-05-18 is: 100
2017.12.03 20:42:07.677 3: DbLog LogDB1: reduceLogNbl (daily-average) deleting progress of day: 2017-05-18 is: 200
2017.12.03 20:42:07.879 3: DbLog LogDB1: reduceLogNbl (daily-average) deleting progress of day: 2017-05-18 is: 300
.....
2017.12.03 20:42:09.317 3: DbLog LogDB1: reduceLogNbl deleting 39029 records of day: 2017-05-19
2017.12.03 20:42:29.305 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-19 is: 10000
2017.12.03 20:42:51.521 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-19 is: 20000
2017.12.03 20:43:12.680 3: DbLog LogDB1: reduceLogNbl deletion progress of day: 2017-05-19 is: 30000
....
* neues Kommanndo "addCacheLine"
Es erlaubt das Einfügen eines Datensatzes direkt in den Cache. Die Weiterverabeitung erfolgt beim nächsten Datenbank-Synclauf
* redesign der Push/PushAsync-Funktionen wegen dem Issue Forum: https://forum.fhem.de/index.php/topic,80519.0.html (hoffentlich)
Dadurch sollte ebenfalls das eventuelle Problem beseitigt sein, dass ein fehlerhafter Datensatz im Cache verhindert, dass der restliche Cache
in die DB eingefügt wird.
* einige kleinere / kosmetische Anpassungen
* Ergänzung: mit angehängter V3.3.0 wird bei "list device" der Inhalt des cache nicht mehr mit gelistet. Das verhindert im Fehlerfall (wenn der cache sehr groß ist), dass ein list die Browsersession überlastet.
Ich würde mich sehr über Rückmeldungen freuen.
Grüße
Heiko
ZitatÜberschreitet der Wert einen Schwellenwert (natürlich höher) als cacheLimit,
Erledigt.
Allerdings war der Cache-Wert nicht so hoch, als dass dort alle Events seit gestern Nacht drin gewesen wären. Es waren vllt 4000 Einträge drin...
Grüße,
Stephan
Noch ne Frage, auf die ich irgendwie keine befriedigende Antwort finde:
Benötigt eine Datenbank (Tabelle, Datensatz) mit einem 128er Feld, von dem nur 1 Zeichen genutzt ist, mehr Speicher, als eine Datenbank mit einem 5er Feld, von dem 1 Zeichen genutzt ist?
Benötigt eine Datenbank (Tabelle, Datensatz) mit einer überflüssigen/leeren Spalte mehr Speicher als ohne diese Spalte?
Beeinflussen zu lange/unnötige Felder die Performance (negativ)?
Irgendwie werd ich aus der Doku nicht schlau...
Falls ja: warum ein 128er Feld für Value?
Warum Value und Event in der current-Table?
Grüße,
Stephan
Grade hatte ich wieder ein Problem, mehr als 2000 Queries anstehen, es half nur noch ein kill.
Könnten unschöne Einträge wie der von HTTPMOD dafür verantwortlich sein?:
ZitatX-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Frame-Options: DENY
Vary: Accept-Encoding
Server: cloudflare-nginx
CF-RAY: 3c9278282abc9706-FRA
2017.12.06 22:51:56.949 4: BTC_HTTPMOD: Read callback: request type was update retry 0,
Header: HTTP/1.1 200 OK
Date: Wed, 06 Dec 2017 21:51:56 GMT
Content-Type: text/html; charset=utf-8
Connection: close
Set-Cookie: __cfduid=ded74d2625a963ba7635e244bd13b493d1512597116; expires=Thu, 06-Dec-18 21:51:56 GMT; path=/; domain=.bitcoin.de; HttpOnly
Cache-Control: private
Set-Cookie: bitcoin_de_supercoin=04ec978fdccdf1c045c3f779bbefa5a7:ad748936490684509aebb82496e71c74de079faa; path=/; secure; httponly
Set-Cookie: bitcoin_de_language_keks=de_DE; expires=Fri, 05-Jan-2018 21:51:56 GMT; path=/; secure; httponly
Strict-Transport-Security: max-age=15552000; includeSubDomains; preload
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Frame-Options: DENY
Vary: Accept-Encoding
Server: cloudflare-nginx
CF-RAY: 3c9278282abc9706-FRA,
Body: <!DOCTYPE html>
<html lang="de">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<link rel="alternate" href="https://www.bitcoin.de" hreflang="x-default"/>
<link rel="alternate" href="https://www.bitcoin.de/de" hreflang="de"/>
<link rel="alternate" href="https://www.bitcoin.de/en" hreflang="en"/>
<link rel="alternate" href="https://www.bitcoin.de/es" hreflang="es"/>
<link rel="alternate" href="https://www.bitcoin.de/fr" hreflang="fr"/>
.....
Grüße,
Stephan
ZitatKönnten unschöne Einträge wie der von HTTPMOD dafür verantwortlich sein?:
Immer wenn ein Feld im Modul länger ist als die DB zulässt ist es ein Problem.
Das ist natürlich ein außerordentliches Exemplar. In welches Felf sollte das denn rein ?
ZitatBenötigt eine Datenbank (Tabelle, Datensatz) mit einer überflüssigen/leeren Spalte mehr Speicher als ohne diese Spalte?
Meines Wissens nur 2 Byte
ZitatBeeinflussen zu lange/unnötige Felder die Performance (negativ)?
Nein bis vernachlässigbar. Viel wichtiger sind passende Indexe.
Zitat
warum ein 128er Feld für Value?
Damit Werte bis 128 Byte hineinpassen ;) Es gibt ja auch Textwerte.
Zitat
Warum Value und Event in der current-Table?
Die ganze Tabellenstruktur ist historisch gewachsen. Man braucht sie eigentlich nicht.
Es gibt einen Satz von Attribute, die mit "col..." anfangen. Damit kann man die Zeichenbreite im Modul der tatsächlichen Feldbeite in der DB anpassen.
Man kann sie aber auch benutzen um z.B. das Schreiben des Feldes Event zu verhindert indem man das Attribut colEvent = 0 setzt.
Grüße
Heiko
ZitatEs gibt einen Satz von Attribute, die mit "col..." anfangen. Damit kann man die Zeichenbreite im Modul der tatsächlichen Feldbeite in der DB anpassen.
Man kann sie aber auch benutzen um z.B. das Schreiben des Feldes Event zu verhindert indem man das Attribut colEvent = 0 setzt.
Das war mir bereits bewusst. Und nachdem ich jetzt weiss, dass leere Felder keine performance-killer sind, hab ich die current-Tabelle wieder richtig angelegt, und colEvent hab ich ja schon länger auf 0 (siehe checkConfig).
Hab heute Nacht die Live-Tabelle auf Vordermann gebracht, die Test-Tabelle ist jetzt so, wie Live vorher war.
Mal sehen, ob es jetzt stabiler läuft, damit ich weiter optimieren kann.
Danke für die Hilfe!
Grüße,
Stephan
Ich habe in #535 noch die 3.3.0 hinterlegt. Damit ist ein "list device" nicht mehr hinderlich wenn der cache im Fehlerfall sehr groß ist.
Grüße
Heiko
Rudi hat hier
https://forum.fhem.de/index.php/topic,73490.0.html
den Befehl "blockinginfo" erwähnt.
Wenn ich diesen Ausführe, bekomme ich logdb mit kompletter Ausgabe, gleiche Symptome wie beim list Device mit vollem Cache.
Kennst du diesen Befehl?
Hast du eine Idee, ob der aus gleichem Grund blockiert?
Hoffe, es ist klar geworden, was ich meine ..
Grüße,
Stephan
ZitatKennst du diesen Befehl?
Ja, der wird quasi nachimplementiert wenn du ein Device/Modul nutzt welches Blocking.pm nutzt.
Dann siehst du den Befehl auch mit "help" in der Kommandozeile.
Der Befehl zeigt nur etwas an wenn ein BlockingCall aktuell läuft. Normalerweise wird dir nur:
No BlockingCall processes running currently zeigen weil der Moment der Ausführung (zumindest bzgl. DbLog) verhältnismäßig kurz ist.
Anders verhält es sich wenn der gestartete BlockingCall im Hintergrund auf irgendetwas wartet.
Erstens wirst du im Device state sehen:
Commit already running - resync at NextSyncUnd zweitens, wenn du den Befehl blockinginfo ausführst, wird er dir alle Info zu dem laufenden Prozess mit allen seinen Argumenten ausgeben.
Und das können eben im Fehlerfall (oder deinem Fall) sehr sehr viele Daten sein , mit deren Anzeige dein Browsersession überlastet wird.
Der Cache wird mit "list Device" ab der V3.3.0 nicht mehr ausgegeben, das habe ich abgeändert.
Grüße
Heiko
Hmm, bei mir schlägt der SqlDump nahezu komplett fehl.
Lediglich current wird gesichert.
2017.12.07 22:16:37.104 3: DbRep DbBackUp - ################################################################
2017.12.07 22:16:37.105 3: DbRep DbBackUp - ### New database clientSide dump ###
2017.12.07 22:16:37.106 3: DbRep DbBackUp - ################################################################
2017.12.07 22:16:37.107 4: DbRep DbBackUp - execute command before dump: 'set logdb commitCache'
2017.12.07 22:16:37.136 4: DbRep DbBackUp -> Start BlockingCall mysql_DoDumpClientSide
2017.12.07 22:16:37.138 3: DbRep DbBackUp - Starting dump of database 'fhem'
2017.12.07 22:16:37.143 3: DbRep DbBackUp - Characterset of collection and backup file set to utf8.
2017.12.07 22:16:37.144 3: DbRep DbBackUp - Searching for tables inside database fhem....
2017.12.07 22:16:37.150 3: DbRep DbBackUp - Found 3 tables with 273561697 records.
2017.12.07 22:16:37.151 3: DbRep DbBackUp - Dumping table current (Type Aria):
2017.12.07 22:16:37.197 3: DbRep DbBackUp - 1025 records inserted (size of backupfile: 199.83 KB)
2017.12.07 22:16:37.198 3: DbRep DbBackUp - Dumping table history (Type Aria):
2017.12.07 22:16:59.065 3: ESPEasy: set Teich.ModusTag raw event,setTemp=7.1
2017.12.07 22:17:01.633 2: ESPEasy ESPbridge: httpReq failed: 192.168.254.80 pondctrl_Environ 'raw event,setTemp=7.1'
2017.12.07 22:17:01.664 2: ESPEasy Teich.ModusTag: WARNING: http://192.168.254.80:80/control?cmd=event,setTemp=7.1: empty answer received
2017.12.07 22:17:07.256 1: DbRep DbBackUp - BlockingCall mysql_DoDumpClientSide Process died prematurely
2017.12.07 22:17:07.338 2: DbRep DbBackUp - Database dump aborted by "Process died prematurely"
2017.12.07 22:17:28.047 2: ESPEasy Teich.ModusTag: RESOLVED: http://192.168.254.80:80/control?cmd=event,setTemp=7.1: empty answer received
2017.12.07 22:17:46.321 1: miniCUL433: answer: miniCUL433 uptime => 0 00:33:41
2017.12.07 22:17:48.977 3: ESPEasy: set Teich.ModusTag raw event,setTemp=7.1
Wie kann ich dem "Process died prematurely" auf die Schliche kommen?
Nachtrag:
defmod DbBackUp DbRep logdb
attr DbBackUp DbLogExclude .*
attr DbBackUp DbLogInclude DumpRowsHistory
attr DbBackUp dumpFilesKeep 6
attr DbBackUp dumpMemlimit 500000000
attr DbBackUp dumpSpeed 50000000
attr DbBackUp event-on-update-reading state,DumpRowsHistory
attr DbBackUp executeBeforeDump set logdb commitCache
attr DbBackUp room DbLog
attr DbBackUp timeout 7200
attr DbBackUp verbose 4
setstate DbBackUp Process died prematurely
setstate DbBackUp 2017-12-07 22:17:07 state Process died prematurely
Das ist der falsche Thread ;)
Aber ich hatte das auch vor Kurzem. Ich glaube ich hatte zuviel Ressourcen zugewiesen, Attribute
dumpMemlimit
dumpSpeed
reduzieren.
Grüße
Heiko
ZitatDer Cache wird mit "list Device" ab der V3.3.0 nicht mehr ausgegeben, das habe ich abgeändert.
Ich hab ja das TEST-Device noch mit der verhunzten Datenbank laufen - als test.
2100 Rows in Cache
und beim list DEVEL_logdb kommt der Browser immer noch genauso ins Schwitzen... oder hab ich deinen Satz falsch verstanden?
Grüße,
Stephan
Nein, hast du nicht falsch verstanden.
Das ist ja blöd ... der Cache wird zwar nicht mehr ausgegeben, aber die Argumente der RUNNING_PID. Das siehst du ja sehr gut auf deinem Screenshot.
Das ist auch nur der Fall wenn ein BlockingCall gerade läuft. Und das ist, normalerweise, nur kurz der Fall.
Muss ich mal schauen ob ich das auch noch unterdrücken kann, aber heute nicht mehr ...
Grüße
Heiko
ZitatUnd das ist, normalerweise, nur kurz der Fall.
Und in dem Fall interessierts ja auch meist nicht ;)
Zitatheute nicht mehr ...
Bin am Wochenende sowieso nicht da :)
also, kein Stress.
Danke,
Stephan
Hallo Stephan,
die V3.3.0 ist eingecheckt.
Hier habe ich die V3.4.0 zum Test angehängt. Nun sollten aber tatsächlich keine cache-Bestandteile mehr beim "list" mit angezeigt werden, d.h. auch die BLOCKING_PID nebst ihren Argumenten (cache) wird beim list unterdrückt.
Grüße
Heiko
Hi Heiko,
nachdem ich gestern abend die 3.4.0 aktiviert habe, ist heute morgen FHEM wieder abgestürzt. Leider sind keine Meldungen im Log, weshalb ich lediglich neu gestartet und attr logdb verbose 5 gesetzt habe.
Was ich mir wünschen würde, wäre eine Option, mit der man den Namen des Logfiles definieren kann.
Extrem geil wäre eine Option wie bei FileLog, die direkt erkennt, wann rotiert werden muss (%y-%m-%d täglich; %w wöchentlich usw), aber allein Tagesfiles wäre schon hilfreich.
Wenn ich ein Doif mache, welches auf (bsp) CacheUsage > 2000 reagiert, löst das ja quasi bei *jedem* Datensatz aus
(ja, ich weiss, kann ich zeitlich oder Threshold-mäßig einschränken);
aber alles in einer Datei wäre schon praktischer ..
Grüße,
Stephan
Hallo Stephan,
Zitatnachdem ich gestern abend die 3.4.0 aktiviert habe, ist heute morgen FHEM wieder abgestürzt. Leider sind keine Meldungen im Log, weshalb ich lediglich neu gestartet und attr logdb verbose 5 gesetzt habe.
Die Version unterdrückt lediglich die Ausgabe der BLOCKING_PID beim "list". Hast du mal gecheckt ob das so ist ?
Wie läuft denn inzwischen deine Prod-DB. Die hast du doch inzwischen ordentlich hergerichtet ?
ZitatWas ich mir wünschen würde, wäre eine Option, mit der man den Namen des Logfiles definieren kann.
Logfiles ? Du meinst sicherlich die Namen der Files vom exportCache.
Die Namensgebung der Files ist absichtlich restriktiv. Dadurch habe ich die Chance, diese Files mit vertretbarem Aufwand für den Befehl "importCacheFile" im System zu identifizieren und dem Nutzer per Drop-Down bereitzustellen.
Das einzigste, worüber ich nachdenken könnte, wäre eine Option ein bestehendes File weiterzuschreiben anstatt bei jedem exportCache ein neues zu beginnen. Macht aber nur Sinn in Verbindung mit "purge" weil man ansonsten alle Daten mehrfach in einem File hat.
Grüße,
Heiko
Zitat von: abc2006 am 11 Dezember 2017, 05:15:19
Wenn ich ein Doif mache, welches auf (bsp) CacheUsage > 2000 reagiert, löst das ja quasi bei *jedem* Datensatz aus
(ja, ich weiss, kann ich zeitlich oder Threshold-mäßig einschränken);
Meinst Du damit, dass das Doif jedesmal die Werte auswerten muss? Gehts Dir dabei um eine mögliche Ressourcenverschwendung?
Das lässt sich doch mit normalen DOIF-Boardmitteln lösen, ohne dass es gleich neue "Features" benötigt.
Prüfe doch einfach auf "NextSync" (das ändert sich nur alle "syncInterval") und nimm die CacheUsage nur als nicht triggernde Abfrage (durch das ?) mit dazu.
([SQL:NextSync] && [?SQL:CacheUsage] > 2000 )
sG
Joe
Achtung, Code nicht getestet aus dem Kopf, bin unterwegs und kanns nicht prüfen.
Hi,
ZitatHast du mal gecheckt ob das so ist ?
Nein. Habe gestern beim einspielen nicht daran gedacht, und heute morgen um 4:30 nur kurz FHEM restartet, bevor ich dann eilig auf Arbeit musste. Check ich später, wenn ich daheim bin.
ZitatDie hast du doch inzwischen ordentlich hergerichtet ?
Ja, hab ich. Die TEST-DB ist grade auch disabled. D.h. der Fehler heute morgen ist mit der prod-DB aufgetreten.
ZitatDu meinst sicherlich die Namen der Files vom exportCache.
Ja, die meine ich.
Okay, war heute morgen vllt etwas früh.
Angenommen, ich habe ein doif, welches auf Events von logdb:cacheUsage triggert.
Weiterhin angenommen, ich führe bei jedem Event ein exportCache (nopurge) durch. Dann habe ich pro Logeintrag eine neue Datei, die entweder alle im Cache befindlichen Daten enthält (also einen Datensatz mehr als die vorherige Datei)
Alternativ führe ich einen exportCache purgeCache durch, dann enthält jede neue Datei lediglich einen Datensatz. Hab ich das so richtig verstanden?
Dadurch entstehen ziemlich schnell ziemlich viele Dateien ( 3600 pro Stunde, wahrscheinlich mehr).
-> Manchmal komm ich erst auf die Ideen, wenn ich mal drüber gesprochen hab. Ich würde ggf. ein expimpdir anlegen, dann wärs mir ja fast egal, wieviele Dateien da drin sind. In Zusammenhang mit purgeCache wärs dann ja sogar konsistent. Solange die Import-Funktion mit so vielen Dateien klar kommt.
Trotzdem könnte ich mir vorstellen, dass es einfacher handhabbar ist, nur eine (wenige) Dateien zu haben ...
Zitat([SQL:NextSync] && [?SQL:CacheUsage] > 2000 )
Klasse Idee, werd ich direkt so umsetzen, wenn ich daheim bin. Habs im Moment mit ([+60] && [?SQL:CacheUsage] > 2000 ) etwas eingeschränkt. Dazu kann ich dann direkt noch einen purgeCache machen, dann könnte das schon fast so sein, wie ich mir das gedacht hatte...
(eingebildeter) Nachteil: wenn fhem zwischendurch dann ganz abstürzt (ich weiss ja noch nicht warum, und ich sähe das (also das eintreten unvorhergesehener Ereignisse, die dazu führen, dass FHEM/DbLog nicht mehr richtig arbeitet) als Hauptanwendungsgrund von exportCache) wären die Daten seit dem letzten SyncInterval weg.
Hoffe das war jetzt verständlicher,
Grüße,
Stephan
Zitat([SQL:NextSync] && [?SQL:CacheUsage] > 2000 )
[logdb:NextSync] erzeugt gar keine Events (wird nicht rot)
Grüße,
Stephan
Zitat[logdb:NextSync] erzeugt gar keine Events (wird nicht rot)
Das mussst du einschalten -> Attr syncEvents (commandref)
Schande über mich, da hab ich wohl zu schnell gelesen...
hatte nur das Cache-Events im Kopf...
wobei, mit
ZitatcacheEvents=2: creates events of reading CacheUsage at point of time when in aychronous mode a new write cycle to the database starts. In that moment CacheUsage contains the amount of datasets which will be written to the database.
müsste es ja tatsächlich reichen, auf "CacheEvents > 2000" zu triggern...
Grüße,
Stephan
wahrscheinlich ... probiers mal aus.
.. und sag mir mal bitte ob das "list" jetzt so funktioniert wie ich das möchte ;)
Grüße
Heiko
Hey,
ja, im *nicht-Fehler-Fall* funktioniert das list, ohne Cache-Inhalt auszugeben.
Wenn und falls der Fehler nochmal auftritt, melde ich mich. (Hoffentlich nicht xD)
Grüße,
Stephan
Hallo Stephan,
wahrscheinlich hast du noch keine Neuigkeiten, da du noch nicht geschrieben hast.
Alledings habe ich inzwischen über ein DbRep deviceRename einen längeren Tabellen-Lock provoziert und so auch schön sehen können, dass auch bei einem laufenden BlockingCall nun ebenfalls die Daten des RUNNING_PID beim list-Kommando nicht mehr mit ausgegeben werden.
Man sieht dann nur noch "STATE Commit already running - resync at NextSync" was vollkommen ausreicht.
So soll es sein.
Dann checke ich die V3.4.0 auch mal ein.
LG und einen schönen dritten Advent
Heiko
Hi,
tatsächlich ist der list-Fehler behoben.
Allerdings hatte ich über Wochenende ein Problem mit logdb, als ich das letzte mal schaute, waren es ca 200k Einträge im Cache.
Bevor ich mich darum kümmern konnte, ist FHEM leider abgestürzt - also hab ich versucht, das Cache-File einzulesen.
Dies endete mit dem Reading:
2017-12-17 22:29:08 lastCachefile ./log/cache_logdb_2017-12-17_22-01-47 - Error - Operation not supported
und folgenden Log-Einträgen:
Zitat
2017.12.17 22:16:45.846 4: DbLog logdb -> processing event Timestamp: 2017-12-17 03:31:55, Device: RE_TEMP_PS3000_05, Type: DUMMY, Event: , Reading: temperature, Valu
e: 61.00, Unit:
2017.12.17 22:25:54.143 2: DbLog logdb -> Error table history - DBD::mysql::st execute_array failed: executing 598386 generated 22 errors at ./FHEM/93_DbLog.pm line 1
515.
2017.12.17 22:29:06.627 4: DbLog logdb -> insert history rolled back
2017.12.17 22:29:08.857 4: DbLog logdb -> ################################################################
2017.12.17 22:29:08.857 4: DbLog logdb -> ### start of new Logcycle ###
2017.12.17 22:29:08.858 4: DbLog logdb -> ################################################################
2017.12.17 22:29:08.858 4: DbLog logdb -> amount of events received: 1 for device: logdb
2017.12.17 22:29:08.858 4: DbLog logdb -> check Device: logdb , Event: lastCachefile: ./log/cache_logdb_2017-12-17_22-01-47 - Error - Operation not supported
2017.12.17 22:29:09.827 4: DbLog logdb -> ################################################################
2017.12.17 22:29:09.827 4: DbLog logdb -> ### start of new Logcycle ###
2017.12.17 22:29:09.827 4: DbLog logdb -> ################################################################
2017.12.17 22:29:09.827 4: DbLog logdb -> amount of events received: 1 for device: logdb
2017.12.17 22:29:09.827 4: DbLog logdb -> check Device: logdb , Event: state: DBD::mysql::st execute_array failed: executing 598386 generated 22 errors at ./FHEM/93_DbLog.pm line 1515.
2017.12.17 22:29:09.848 5: DbLog logdb -> DbLog_Push Returncode: DBD::mysql::st execute_array failed: executing 598386 generated 22 errors at ./FHEM/93_DbLog.pm line 1515.
ZitatInternals:
COLUMNS field length used for Device: 64, Type: 64, Event: 0, Reading: 64, Value: 128, Unit: 32
CONFIGURATION ./db_fhem.conf
DEF ./db_fhem.conf .*:.*
MODE asynchronous
MODEL MYSQL
NAME logdb
NR 311
NTFY_ORDER 50-logdb
PID 13172
REGEXP .*:.*
STATE connected
TYPE DbLog
UTF8 1
VERSION 3.4.0
dbconn mysql:database=fhem;host=localhost;port=3306
dbuser fhemuser
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 0
OLDSTATE connected
READINGCOL 64
TYPECOL 64
UNITCOL 32
VALUECOL 128
READINGS:
2017-12-17 23:05:00 CacheUsage 94
2017-12-17 23:04:33 NextSync 2017-12-17 23:05:33 or if CacheUsage 500 reached
2017-12-17 22:29:08 lastCachefile ./log/cache_logdb_2017-12-17_22-01-47 - Error - Operation not supported
2017-12-17 23:04:34 state connected
cache:
index 8519
Attributes:
DbLogSelectionMode Include
DbLogType History
asyncMode 1
cacheEvents 2
cacheLimit 500
colEvent 0
room Logging
syncInterval 60
userReadings DbFileSize:lastReduceLogResult.* { (split(' ',`du -m fhem.db`))[0] }
verbose 5
Leider bin ich nicht in der Lage, diese Fehlermeldungen zu deuten. Das Cache-File ist mittlerweile ca. 40MB groß.
Kannst du mir einen Tipp geben?
Danke und Grüße,
Stephan
EDIT: Ah, und beim Einlesen war die WEB-Oberfläche von FHEM nicht mehr erreichbar. Nachdem der Prozess dann beendet/abgebrochen war, konnte ich wieder an FHEM ran. Läuft das einlesen als fork?
Die funktion war gefühlt wenig beeinträchtigt (Licht ging an).
Nochma EDIT:
Was passiert, wenn ich das gleiche CacheFile zweimal einlese? Doppelte einträge? Oder wird das vorher geprüft?
Arbeite gerade daran, ein mysql master-slave aufzusetzen.
Dabei ist mir folgendes aufgefallen:
Cache-Usage zeigt 3000 meldungen
nach dem Aktualisieren der Seite zeigt CacheUsage nur noch 30 Meldungen.
beim nächsten Event springt CacheUsage wieder auf 3000+ meldungen.
im List steht:
Internals:
COLUMNS field length used for Device: 64, Type: 64, Event: 0, Reading: 64, Value: 128, Unit: 32
CONFIGURATION ./db_fhem.conf
DEF ./db_fhem.conf .*:.*
MODE asynchronous
MODEL MYSQL
NAME logdb
NR 311
NTFY_ORDER 50-logdb
PID 13172
REGEXP .*:.*
STATE DBI connect('database=fhem;host=localhost;port=3306','fhemuser',...) failed: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at ./FHEM/93_DbLog.pm line 1783.
TYPE DbLog
UTF8 1
VERSION 3.4.0
dbconn mysql:database=fhem;host=localhost;port=3306
dbuser fhemuser
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 0
OLDSTATE DBI connect('database=fhem;host=localhost;port=3306','fhemuser',...) failed: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at ./FHEM/93_DbLog.pm line 1783.
READINGCOL 64
TYPECOL 64
UNITCOL 32
VALUECOL 128
READINGS:
2017-12-18 03:20:53 CacheUsage 8
2017-12-18 03:20:53 NextSync 2017-12-18 03:22:53 or if CacheUsage 1500 reached
2017-12-18 03:19:12 lastCachefile ./log/cache_logdb_2017-12-18_03-19-12 export successful
2017-12-18 03:20:53 state DBI connect('database=fhem;host=localhost;port=3306','fhemuser',...) failed: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at ./FHEM/93_DbLog.pm line 1783.
cache:
index 197285
Attributes:
DbLogSelectionMode Include
DbLogType History
asyncMode 1
cacheEvents 2
cacheLimit 1500
colEvent 0
room Logging
syncInterval 120
userReadings DbFileSize:lastReduceLogResult.* { (split(' ',`du -m fhem.db`))[0] }
verbose 5
Vielleicht ist das nicht so gewollt.
Die DB ist gerade gestoppt, weil ich die Daten kopiere.
Grüße,
Stephan
Hallo Stephan,
Zitat
Vielleicht ist das nicht so gewollt.
Die DB ist gerade gestoppt, weil ich die Daten kopiere.
Doch, dass ok so. Wenn du aber die Datenbank bewusst stoppst, kannst das Modul "entlasten" indem du ein "reopen xxx" absetzt. Damit wäre die Verbindung für die nächsten xxx Sekunden geschlossen und es würden keine sinnlosen forks mehr eröffnet (und damit der cache nicht mehr so reagieren).
Nebenbei würde DbRep ab V7.0.0 diesen Zustand ebenfalls erkennen.
Wegen deinem anderen Beitrag...
Zitat
Dies endete mit dem Reading:
2017-12-17 22:29:08 lastCachefile ./log/cache_logdb_2017-12-17_22-01-47 - Error - Operation not supported
Das ist die Rückmeldung des DB-Interfaces.
Da im Standard die Operation als Transaktion ausgeführt wird, wird im Fehlerfall ein :
DbLog logdb -> insert history rolled backausgeführt.
Es scheint mit deiner DB noch ein grundsätzliches Problem zu geben. Das Problem mit dem Import des Cachefiles ist, dass 22 der 598386 zu importierenden Datensätzen nicht in die DB wollen. Das ist augenscheinlich auch der Grund warum diese Datensätze das Wegschreiben des Cache im laufenden Betrieb verhindern und sich deswegen der Cache aufbaut.
Mach bitte ein "configCheck" und poste das Ergebnis.
Um das File importiert zu bekommen kannst du verschiedene Wege probieren.
1. du teilst das File mit Tools in kleinere Häppchen und importierst diese. Den Filenamen hinten einfach um eine Ziffer 1... ergänzen. Dadurch besteht die Chance die fehlerhaften Datensätze zu identifizieren.
2. du verwendest keine Transaktion. Dazu setzt du das (neue) Attribut "commitMode = ac:on_ta:off". Dadurch werden diese 22 fehlerhaften Datensätze auch nicht importiert, aber die restlichen 500xxx sollten in der DB landen. (Checke es mit einem Admintool / DbRep)
Zitat
EDIT: Ah, und beim Einlesen war die WEB-Oberfläche von FHEM nicht mehr erreichbar. Nachdem der Prozess dann beendet/abgebrochen war, konnte ich wieder an FHEM ran. Läuft das einlesen als fork?
Die funktion war gefühlt wenig beeinträchtigt (Licht ging an).
Nein, der Import wird nicht als fork ausgeführt. Ich war nicht der Meinung, dass man damit Massenverarbeitung duchführen wird :).
Zitat
Nochma EDIT:
Was passiert, wenn ich das gleiche CacheFile zweimal einlese? Doppelte einträge? Oder wird das vorher geprüft?
Wie oben bereits erwähnt, es wird als Transaktion ausgeführt. D.h. entweder das ganze File landet in der DB oder garnichts. Das soll genau das vermeiden was deine Frage beinhaltete. Anders ist es wenn du das Attribut commitMode wie beschrieben setzt !
EDIT: du kannst die Einstellung Attribut "commitMode = ac:on_ta:off" auch im Betrieb so lassen. Dadurch ergibt sich evtl. die Chance die fehlerhaften Datensätze zu identifizieren.
LG
Heiko
Zitat von: DS_Starter am 18 Dezember 2017, 07:58:23
Hallo Stephan,
Doch, dass ok so. Wenn du aber die Datenbank bewusst stoppst, kannst das Modul "entlasten" indem du ein "reopen xxx" absetzt. Damit wäre die Verbindung für die nächsten xxx Sekunden geschlossen und es würden keine sinnlosen forks mehr eröffnet (und damit der cache nicht mehr so reagieren).
Nebenbei würde DbRep ab V7.0.0 diesen Zustand ebenfalls erkennen.
Kurze Verständnisfrage: was hat DbRep in diesem Fall mit DbLog zu tun? Beeinflusst DbRep das DbLog-Device?
Der Cache reagiert so, weil der Fork gestartet wird, den Cache mitnimmt, feststellt, dass er nicht schreiben kann und die Daten wieder zurückspielt?
Dann würde der Cache in den Sprüngen weiter wachsen?
Zitat
Wegen deinem anderen Beitrag...
Das ist die Rückmeldung des DB-Interfaces.
Da im Standard die Operation als Transaktion ausgeführt wird, wird im Fehlerfall ein :
DbLog logdb -> insert history rolled back
ausgeführt.
Na, das nimmt mir doch schonmal Sorgen :)
Zitat
Es scheint mit deiner DB noch ein grundsätzliches Problem zu geben. Das Problem mit dem Import des Cachefiles ist, dass 22 der 598386 zu importierenden Datensätzen nicht in die DB wollen. Das ist augenscheinlich auch der Grund warum diese Datensätze das Wegschreiben des Cache im laufenden Betrieb verhindern und sich deswegen der Cache aufbaut.
Mach bitte ein "configCheck" und poste das Ergebnis.
Result of connection check
Connection to database fhem successfully done.
Recommendation: settings o.k.
Result of encoding check
Encoding used by Client (connection): UTF8
Encoding used by DB fhem: UTF8
Recommendation: settings o.k.
Result of logmode check
Logmode of DbLog-device logdb is: asynchronous
Recommendation: settings o.k.
Result of table 'history' check
Column width set in DB fhem.history: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 0, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: settings o.k.
Result of table 'current' check
Column width set in DB fhem.current: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 0, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: settings o.k.
Result of check 'Search_Idx' availability
Index 'Search_Idx' exists and contains the recommended fields 'DEVICE', 'READING', 'TIMESTAMP'.
Recommendation: settings o.k.
Result of check 'Report_Idx' availability for DbRep-devices
You use at least one DbRep-device assigned to logdb, but the recommended index 'Report_Idx' is missing.
Recommendation: You can create the index by executing statement 'CREATE INDEX Report_Idx ON `history` (TIMESTAMP, READING) USING BTREE;'
Depending on your database size this command may running a long time.
Please make sure the device 'logdb' is operating in asynchronous mode to avoid FHEM from blocking when creating the index.
Note: If you have just created another index which covers the same fields and order as suggested (e.g. a primary key) you don't need to create the 'Report_Idx' as well ! Zitat
Um das File importiert zu bekommen kannst du verschiedene Wege probieren.
1. du teilst das File mit Tools in kleinere Häppchen und importierst diese. Den Filenamen hinten einfach um eine Ziffer 1... ergänzen. Dadurch besteht die Chance die fehlerhaften Datensätze zu identifizieren.
2. du verwendest keine Transaktion. Dazu setzt du das (neue) Attribut "commitMode = ac:on_ta:off". Dadurch werden diese 22 fehlerhaften Datensätze auch nicht importiert, aber die restlichen 500xxx sollten in der DB landen. (Checke es mit einem Admintool / DbRep)
Nein, der Import wird nicht als fork ausgeführt. Ich war nicht der Meinung, dass man damit Massenverarbeitung duchführen wird :).
Wie oben bereits erwähnt, es wird als Transaktion ausgeführt. D.h. entweder das ganze File landet in der DB oder garnichts. Das soll genau das vermeiden was deine Frage beinhaltete. Anders ist es wenn du das Attribut commitMode wie beschrieben setzt !
werd ich testen. Mit Massenverarbeitung hat das nix zu tun, sammelt sich halt an, wenn man nicht *sofort* reagieren kann. Hatte ja *extra* die save-Option gewählt, und da ich der Hoffnung war, dass dann keine Inserts verloren gehen, hatte ich mir nicht sofort zeit genommen, das Problem zu lösen..
Danke dir,
Stephan
ZitatKurze Verständnisfrage: was hat DbRep in diesem Fall mit DbLog zu tun?
nichts, wollte es nur erwähnen
Zitat
Der Cache reagiert so, weil der Fork gestartet wird, den Cache mitnimmt, feststellt, dass er nicht schreiben kann und die Daten wieder zurückspielt?
Ja
ZitatMit Massenverarbeitung hat das nix zu tun, sammelt sich halt an, wenn man nicht *sofort* reagieren kann. Hatte ja *extra* die save-Option gewählt, und da ich der Hoffnung war, dass dann keine Inserts verloren gehen, hatte ich mir nicht sofort zeit genommen, das Problem zu lösen..
Alles gut, dafür ist die Funktion da.
Dein check sieht auch gut aus. Kann mir momentan nicht vorstellen welche daten weshalb rumzicken. Das wäre herauszubekommen.
Bin auf das Ergebnis des Imports gespannt.
Grüsse
Heiko
ZitatDu verwendest keine Transaktion. Dazu setzt du das (neue) Attribut "commitMode = ac:on_ta:off". Dadurch werden diese 22 fehlerhaften Datensätze auch nicht importiert, aber die restlichen 500xxx sollten in der DB landen. (Checke es mit einem Admintool / DbRep)
Dazu hätt ich nochmal ne Rückfrage.
a)
Angenommen, ich setze dieses Attribut. Dann muss ich höllisch aufpassen, dass ich das File nur ein einziges mal importiere, weil wenn was schief geht, würden alle bereits importierten Datensätze nochmal importiert.
Da ich (mit meinem Kenntnisstand) nicht herausfinden kann, welche das sind, kann ich die Datei zu dem Zeitpunkt auch nicht mehr anpassen.
b) ich habe ja ein paar mehr Cache-Save-Files. eigentlich brauche ich nur das allerletzte, die anderen 10 GB logfiles kann ich wieder löschen, oder?
c) wenn ich die Dateien jetzt aufteile, kann ich dann eine Art "batch-verarbeitung" durchführen? oder muss ich jede Datei einzeln importieren?
d) wie kann ich die fehlerhaften Zeilen dann erkennen?
e) was hältst du davon, wenn ein Fehler auftritt, die fehlerhafte Zeile 1:1 ins Log zu schreiben?
Grüße,
Stephan
(der sich dann mal ans aufteilen der Dateien macht) ;.)
oh, viele Fragen ...
a) ja, das wäre so. es sei denn du setzt vorher in der history einen primary key. der schützt vor doppelten datensätzen.
b) ja, sofern der cache nicht gepurgt wurde.
c) sowas ist nicht eingebaut. musst du einzeln importieren.
d) es bleiben dann überschaubare files übrig. da müsen wir uns den inhalt anschauen
e) denke das passiert schon mit verbose 5
grüsse
heiko
Danke, dass du dir so viel Zeit nimmst :-)
Ich habe jetzt mal die Dateien durchgesehen.
Dabei ist mir was aufgefallen, mal sehen, ob ich das ordentlich beschrieben krieg:
So sahen meine Dateien aus:
-rw-r--r-- 1 fhem dialout 276K Dez 15 16:24 cache_logdb_2017-12-15_16-24-05
-rw-r--r-- 1 fhem dialout 389K Dez 15 16:29 cache_logdb_2017-12-15_16-29-05
-rw-r--r-- 1 fhem dialout 210K Dez 15 16:44 cache_logdb_2017-12-15_16-44-05
-rw-r--r-- 1 fhem dialout 142K Dez 15 16:59 cache_logdb_2017-12-15_16-59-05
-rw-r--r-- 1 fhem dialout 203K Dez 15 17:14 cache_logdb_2017-12-15_17-14-05
-rw-r--r-- 1 fhem dialout 313K Dez 15 17:19 cache_logdb_2017-12-15_17-19-05
-rw-r--r-- 1 fhem dialout 422K Dez 15 17:24 cache_logdb_2017-12-15_17-24-05
-rw-r--r-- 1 fhem dialout 540K Dez 15 17:29 cache_logdb_2017-12-15_17-29-05
-rw-r--r-- 1 fhem dialout 640K Dez 15 17:34 cache_logdb_2017-12-15_17-34-05
-rw-r--r-- 1 fhem dialout 743K Dez 15 17:39 cache_logdb_2017-12-15_17-39-05
-rw-r--r-- 1 fhem dialout 845K Dez 15 17:44 cache_logdb_2017-12-15_17-44-05
-rw-r--r-- 1 fhem dialout 954K Dez 15 17:49 cache_logdb_2017-12-15_17-49-05
-rw-r--r-- 1 fhem dialout 1,1M Dez 15 17:54 cache_logdb_2017-12-15_17-54-05
-rw-r--r-- 1 fhem dialout 1,2M Dez 15 17:59 cache_logdb_2017-12-15_17-59-05
-rw-r--r-- 1 fhem dialout 0 Dez 18 11:34 cache_logdb_2017-12-16_00-44-05
-rw-r--r-- 1 fhem dialout 0 Dez 18 11:34 cache_logdb_2017-12-16_00-49-05
-rw-r--r-- 1 fhem dialout 259K Dez 16 00:54 cache_logdb_2017-12-16_00-54-05
-rw-r--r-- 1 fhem dialout 308K Dez 16 00:59 cache_logdb_2017-12-16_00-59-05
-rw-r--r-- 1 fhem dialout 356K Dez 16 01:04 cache_logdb_2017-12-16_01-04-05
-rw-r--r-- 1 fhem dialout 409K Dez 16 01:09 cache_logdb_2017-12-16_01-09-05
-rw-r--r-- 1 fhem dialout 463K Dez 16 01:14 cache_logdb_2017-12-16_01-14-05
-rw-r--r-- 1 fhem dialout 519K Dez 16 01:19 cache_logdb_2017-12-16_01-19-05
-rw-r--r-- 1 fhem dialout 576K Dez 16 01:24 cache_logdb_2017-12-16_01-24-05
-rw-r--r-- 1 fhem dialout 630K Dez 16 01:29 cache_logdb_2017-12-16_01-29-05
-rw-r--r-- 1 fhem dialout 684K Dez 16 01:34 cache_logdb_2017-12-16_01-34-05
-rw-r--r-- 1 fhem dialout 738K Dez 16 01:39 cache_logdb_2017-12-16_01-39-05
-rw-r--r-- 1 fhem dialout 792K Dez 16 01:44 cache_logdb_2017-12-16_01-44-05
-rw-r--r-- 1 fhem dialout 846K Dez 16 01:49 cache_logdb_2017-12-16_01-49-05
-rw-r--r-- 1 fhem dialout 899K Dez 16 01:54 cache_logdb_2017-12-16_01-54-05
-rw-r--r-- 1 fhem dialout 952K Dez 16 01:59 cache_logdb_2017-12-16_01-59-05
-rw-r--r-- 1 fhem dialout 1004K Dez 16 02:04 cache_logdb_2017-12-16_02-04-05
-rw-r--r-- 1 fhem dialout 1,1M Dez 16 02:09 cache_logdb_2017-12-16_02-09-05
-rw-r--r-- 1 fhem dialout 1,1M Dez 16 02:14 cache_logdb_2017-12-16_02-14-05
-rw-r--r-- 1 fhem dialout 1,2M Dez 16 02:19 cache_logdb_2017-12-16_02-19-05
-rw-r--r-- 1 fhem dialout 1,2M Dez 16 02:24 cache_logdb_2017-12-16_02-24-05
-rw-r--r-- 1 fhem dialout 1,3M Dez 16 02:29 cache_logdb_2017-12-16_02-29-05
-rw-r--r-- 1 fhem dialout 1,3M Dez 16 02:34 cache_logdb_2017-12-16_02-34-05
-rw-r--r-- 1 fhem dialout 1,4M Dez 16 02:39 cache_logdb_2017-12-16_02-39-05
-rw-r--r-- 1 fhem dialout 1,4M Dez 16 02:44 cache_logdb_2017-12-16_02-44-05
-rw-r--r-- 1 fhem dialout 1,5M Dez 16 02:49 cache_logdb_2017-12-16_02-49-05
-rw-r--r-- 1 fhem dialout 1,5M Dez 16 02:54 cache_logdb_2017-12-16_02-54-05
-rw-r--r-- 1 fhem dialout 1,6M Dez 16 02:59 cache_logdb_2017-12-16_02-59-05
-rw-r--r-- 1 fhem dialout 1,6M Dez 16 03:04 cache_logdb_2017-12-16_03-04-05
-rw-r--r-- 1 fhem dialout 1,7M Dez 16 03:09 cache_logdb_2017-12-16_03-09-05
-rw-r--r-- 1 fhem dialout 1,7M Dez 16 03:14 cache_logdb_2017-12-16_03-14-05
-rw-r--r-- 1 fhem dialout 1,8M Dez 16 03:19 cache_logdb_2017-12-16_03-19-05
-rw-r--r-- 1 fhem dialout 1,8M Dez 16 03:24 cache_logdb_2017-12-16_03-24-05
-rw-r--r-- 1 fhem dialout 1,9M Dez 16 03:29 cache_logdb_2017-12-16_03-29-05
-rw-r--r-- 1 fhem dialout 1,9M Dez 16 03:34 cache_logdb_2017-12-16_03-34-05
-rw-r--r-- 1 fhem dialout 2,0M Dez 16 03:39 cache_logdb_2017-12-16_03-39-05
-rw-r--r-- 1 fhem dialout 2,0M Dez 16 03:44 cache_logdb_2017-12-16_03-44-05
-rw-r--r-- 1 fhem dialout 2,1M Dez 16 03:49 cache_logdb_2017-12-16_03-49-05
-rw-r--r-- 1 fhem dialout 2,1M Dez 16 03:54 cache_logdb_2017-12-16_03-54-05
-rw-r--r-- 1 fhem dialout 2,2M Dez 16 03:59 cache_logdb_2017-12-16_03-59-05
-rw-r--r-- 1 fhem dialout 2,2M Dez 16 04:04 cache_logdb_2017-12-16_04-04-05
-rw-r--r-- 1 fhem dialout 2,3M Dez 16 04:09 cache_logdb_2017-12-16_04-09-05
-rw-r--r-- 1 fhem dialout 2,3M Dez 16 04:14 cache_logdb_2017-12-16_04-14-05
-rw-r--r-- 1 fhem dialout 2,4M Dez 16 04:19 cache_logdb_2017-12-16_04-19-05
-rw-r--r-- 1 fhem dialout 2,4M Dez 16 04:24 cache_logdb_2017-12-16_04-24-05
-rw-r--r-- 1 fhem dialout 2,5M Dez 16 04:29 cache_logdb_2017-12-16_04-29-05
-rw-r--r-- 1 fhem dialout 2,5M Dez 16 04:34 cache_logdb_2017-12-16_04-34-05
-rw-r--r-- 1 fhem dialout 2,6M Dez 16 04:39 cache_logdb_2017-12-16_04-39-05
-rw-r--r-- 1 fhem dialout 2,6M Dez 16 04:44 cache_logdb_2017-12-16_04-44-05
-rw-r--r-- 1 fhem dialout 2,7M Dez 16 04:49 cache_logdb_2017-12-16_04-49-05
-rw-r--r-- 1 fhem dialout 2,7M Dez 16 04:54 cache_logdb_2017-12-16_04-54-05
-rw-r--r-- 1 fhem dialout 2,8M Dez 16 04:59 cache_logdb_2017-12-16_04-59-05
-rw-r--r-- 1 fhem dialout 2,8M Dez 16 05:04 cache_logdb_2017-12-16_05-04-05
-rw-r--r-- 1 fhem dialout 2,9M Dez 16 05:09 cache_logdb_2017-12-16_05-09-05
-rw-r--r-- 1 fhem dialout 2,9M Dez 16 05:14 cache_logdb_2017-12-16_05-14-05
-rw-r--r-- 1 fhem dialout 3,0M Dez 16 05:19 cache_logdb_2017-12-16_05-19-05
-rw-r--r-- 1 fhem dialout 3,0M Dez 16 05:24 cache_logdb_2017-12-16_05-24-05
-rw-r--r-- 1 fhem dialout 3,1M Dez 16 05:29 cache_logdb_2017-12-16_05-29-05
-rw-r--r-- 1 fhem dialout 3,1M Dez 16 05:34 cache_logdb_2017-12-16_05-34-05
-rw-r--r-- 1 fhem dialout 3,2M Dez 16 05:39 cache_logdb_2017-12-16_05-39-05
-rw-r--r-- 1 fhem dialout 3,2M Dez 16 05:44 cache_logdb_2017-12-16_05-44-05
-rw-r--r-- 1 fhem dialout 3,3M Dez 16 05:49 cache_logdb_2017-12-16_05-49-05
-rw-r--r-- 1 fhem dialout 3,4M Dez 16 05:54 cache_logdb_2017-12-16_05-54-05
-rw-r--r-- 1 fhem dialout 3,5M Dez 16 05:59 cache_logdb_2017-12-16_05-59-05
-rw-r--r-- 1 fhem dialout 3,5M Dez 16 06:04 cache_logdb_2017-12-16_06-04-05
-rw-r--r-- 1 fhem dialout 3,6M Dez 16 06:09 cache_logdb_2017-12-16_06-09-05
-rw-r--r-- 1 fhem dialout 3,7M Dez 16 06:14 cache_logdb_2017-12-16_06-14-05
-rw-r--r-- 1 fhem dialout 3,7M Dez 16 06:19 cache_logdb_2017-12-16_06-19-05
-rw-r--r-- 1 fhem dialout 3,8M Dez 16 06:24 cache_logdb_2017-12-16_06-24-05
-rw-r--r-- 1 fhem dialout 3,9M Dez 16 06:29 cache_logdb_2017-12-16_06-29-05
-rw-r--r-- 1 fhem dialout 3,9M Dez 16 06:34 cache_logdb_2017-12-16_06-34-05
-rw-r--r-- 1 fhem dialout 4,0M Dez 16 06:39 cache_logdb_2017-12-16_06-39-05
-rw-r--r-- 1 fhem dialout 4,1M Dez 16 06:44 cache_logdb_2017-12-16_06-44-05
-rw-r--r-- 1 fhem dialout 4,2M Dez 16 06:49 cache_logdb_2017-12-16_06-49-05
-rw-r--r-- 1 fhem dialout 4,2M Dez 16 06:54 cache_logdb_2017-12-16_06-54-05
-rw-r--r-- 1 fhem dialout 4,3M Dez 16 06:59 cache_logdb_2017-12-16_06-59-05
-rw-r--r-- 1 fhem dialout 4,4M Dez 16 07:04 cache_logdb_2017-12-16_07-04-05
-rw-r--r-- 1 fhem dialout 4,4M Dez 16 07:09 cache_logdb_2017-12-16_07-09-05
-rw-r--r-- 1 fhem dialout 4,5M Dez 16 07:14 cache_logdb_2017-12-16_07-14-05
-rw-r--r-- 1 fhem dialout 4,6M Dez 16 07:19 cache_logdb_2017-12-16_07-19-05
-rw-r--r-- 1 fhem dialout 4,6M Dez 16 07:24 cache_logdb_2017-12-16_07-24-05
-rw-r--r-- 1 fhem dialout 4,7M Dez 16 07:29 cache_logdb_2017-12-16_07-29-05
-rw-r--r-- 1 fhem dialout 4,7M Dez 16 07:34 cache_logdb_2017-12-16_07-34-05
-rw-r--r-- 1 fhem dialout 4,8M Dez 16 07:39 cache_logdb_2017-12-16_07-39-05
-rw-r--r-- 1 fhem dialout 4,9M Dez 16 07:44 cache_logdb_2017-12-16_07-44-05
-rw-r--r-- 1 fhem dialout 4,9M Dez 16 07:49 cache_logdb_2017-12-16_07-49-05
-rw-r--r-- 1 fhem dialout 5,0M Dez 16 07:54 cache_logdb_2017-12-16_07-54-05
-rw-r--r-- 1 fhem dialout 5,1M Dez 16 07:59 cache_logdb_2017-12-16_07-59-05
-rw-r--r-- 1 fhem dialout 5,1M Dez 16 08:04 cache_logdb_2017-12-16_08-04-05
-rw-r--r-- 1 fhem dialout 5,2M Dez 16 08:09 cache_logdb_2017-12-16_08-09-05
-rw-r--r-- 1 fhem dialout 5,3M Dez 16 08:14 cache_logdb_2017-12-16_08-14-05
-rw-r--r-- 1 fhem dialout 5,4M Dez 16 08:19 cache_logdb_2017-12-16_08-19-05
-rw-r--r-- 1 fhem dialout 5,4M Dez 16 08:24 cache_logdb_2017-12-16_08-24-05
-rw-r--r-- 1 fhem dialout 5,5M Dez 16 08:29 cache_logdb_2017-12-16_08-29-05
-rw-r--r-- 1 fhem dialout 5,6M Dez 16 08:34 cache_logdb_2017-12-16_08-34-05
-rw-r--r-- 1 fhem dialout 5,6M Dez 16 08:39 cache_logdb_2017-12-16_08-39-05
-rw-r--r-- 1 fhem dialout 5,7M Dez 16 08:44 cache_logdb_2017-12-16_08-44-05
-rw-r--r-- 1 fhem dialout 5,8M Dez 16 08:49 cache_logdb_2017-12-16_08-49-05
-rw-r--r-- 1 fhem dialout 5,9M Dez 16 08:54 cache_logdb_2017-12-16_08-54-05
-rw-r--r-- 1 fhem dialout 5,9M Dez 16 08:59 cache_logdb_2017-12-16_08-59-05
-rw-r--r-- 1 fhem dialout 6,0M Dez 16 09:04 cache_logdb_2017-12-16_09-04-05
-rw-r--r-- 1 fhem dialout 6,1M Dez 16 09:09 cache_logdb_2017-12-16_09-09-05
-rw-r--r-- 1 fhem dialout 6,1M Dez 16 09:14 cache_logdb_2017-12-16_09-14-05
-rw-r--r-- 1 fhem dialout 6,2M Dez 16 09:19 cache_logdb_2017-12-16_09-19-06
-rw-r--r-- 1 fhem dialout 6,3M Dez 16 09:24 cache_logdb_2017-12-16_09-24-07
-rw-r--r-- 1 fhem dialout 6,4M Dez 16 09:29 cache_logdb_2017-12-16_09-29-08
-rw-r--r-- 1 fhem dialout 6,4M Dez 16 09:34 cache_logdb_2017-12-16_09-34-09
-rw-r--r-- 1 fhem dialout 6,5M Dez 16 09:39 cache_logdb_2017-12-16_09-39-10
-rw-r--r-- 1 fhem dialout 6,6M Dez 16 09:44 cache_logdb_2017-12-16_09-44-11
-rw-r--r-- 1 fhem dialout 6,6M Dez 16 09:49 cache_logdb_2017-12-16_09-49-12
-rw-r--r-- 1 fhem dialout 6,7M Dez 16 09:54 cache_logdb_2017-12-16_09-54-13
-rw-r--r-- 1 fhem dialout 6,8M Dez 16 09:59 cache_logdb_2017-12-16_09-59-14
-rw-r--r-- 1 fhem dialout 6,8M Dez 16 10:04 cache_logdb_2017-12-16_10-04-15
-rw-r--r-- 1 fhem dialout 6,9M Dez 16 10:09 cache_logdb_2017-12-16_10-09-16
-rw-r--r-- 1 fhem dialout 7,0M Dez 16 10:14 cache_logdb_2017-12-16_10-14-17
-rw-r--r-- 1 fhem dialout 7,1M Dez 16 10:19 cache_logdb_2017-12-16_10-19-18
-rw-r--r-- 1 fhem dialout 7,1M Dez 16 10:24 cache_logdb_2017-12-16_10-24-19
-rw-r--r-- 1 fhem dialout 7,2M Dez 16 10:29 cache_logdb_2017-12-16_10-29-20
-rw-r--r-- 1 fhem dialout 7,3M Dez 16 10:34 cache_logdb_2017-12-16_10-34-21
-rw-r--r-- 1 fhem dialout 7,4M Dez 16 10:39 cache_logdb_2017-12-16_10-39-22
-rw-r--r-- 1 fhem dialout 7,4M Dez 16 10:44 cache_logdb_2017-12-16_10-44-23
-rw-r--r-- 1 fhem dialout 7,5M Dez 16 10:49 cache_logdb_2017-12-16_10-49-24
-rw-r--r-- 1 fhem dialout 7,6M Dez 16 10:54 cache_logdb_2017-12-16_10-54-25
-rw-r--r-- 1 fhem dialout 7,7M Dez 16 10:59 cache_logdb_2017-12-16_10-59-26
-rw-r--r-- 1 fhem dialout 7,8M Dez 16 11:04 cache_logdb_2017-12-16_11-04-27
-rw-r--r-- 1 fhem dialout 7,8M Dez 16 11:09 cache_logdb_2017-12-16_11-09-28
-rw-r--r-- 1 fhem dialout 7,9M Dez 16 11:14 cache_logdb_2017-12-16_11-14-29
-rw-r--r-- 1 fhem dialout 8,0M Dez 16 11:19 cache_logdb_2017-12-16_11-19-30
-rw-r--r-- 1 fhem dialout 8,0M Dez 16 11:24 cache_logdb_2017-12-16_11-24-31
-rw-r--r-- 1 fhem dialout 8,1M Dez 16 11:29 cache_logdb_2017-12-16_11-29-32
-rw-r--r-- 1 fhem dialout 8,2M Dez 16 11:34 cache_logdb_2017-12-16_11-34-33
-rw-r--r-- 1 fhem dialout 8,3M Dez 16 11:39 cache_logdb_2017-12-16_11-39-34
-rw-r--r-- 1 fhem dialout 8,3M Dez 16 11:44 cache_logdb_2017-12-16_11-44-35
-rw-r--r-- 1 fhem dialout 8,4M Dez 16 11:49 cache_logdb_2017-12-16_11-49-36
-rw-r--r-- 1 fhem dialout 8,5M Dez 16 11:54 cache_logdb_2017-12-16_11-54-37
-rw-r--r-- 1 fhem dialout 8,6M Dez 16 11:59 cache_logdb_2017-12-16_11-59-38
-rw-r--r-- 1 fhem dialout 8,6M Dez 16 12:04 cache_logdb_2017-12-16_12-04-39
-rw-r--r-- 1 fhem dialout 8,7M Dez 16 12:09 cache_logdb_2017-12-16_12-09-40
-rw-r--r-- 1 fhem dialout 8,8M Dez 16 12:14 cache_logdb_2017-12-16_12-14-41
-rw-r--r-- 1 fhem dialout 8,9M Dez 16 12:19 cache_logdb_2017-12-16_12-19-42
-rw-r--r-- 1 fhem dialout 9,0M Dez 16 12:24 cache_logdb_2017-12-16_12-24-43
-rw-r--r-- 1 fhem dialout 9,1M Dez 16 12:29 cache_logdb_2017-12-16_12-29-44
-rw-r--r-- 1 fhem dialout 9,1M Dez 16 12:34 cache_logdb_2017-12-16_12-34-45
-rw-r--r-- 1 fhem dialout 9,3M Dez 16 12:39 cache_logdb_2017-12-16_12-39-46
-rw-r--r-- 1 fhem dialout 9,4M Dez 16 12:44 cache_logdb_2017-12-16_12-44-47
-rw-r--r-- 1 fhem dialout 9,6M Dez 16 12:49 cache_logdb_2017-12-16_12-49-48
-rw-r--r-- 1 fhem dialout 9,7M Dez 16 12:54 cache_logdb_2017-12-16_12-54-49
-rw-r--r-- 1 fhem dialout 9,9M Dez 16 12:59 cache_logdb_2017-12-16_12-59-50
-rw-r--r-- 1 fhem dialout 0 Dez 18 11:31 cache_logdb_2017-12-16_13-04-51
-rw-r--r-- 1 fhem dialout 11M Dez 16 13:09 cache_logdb_2017-12-16_13-09-52
-rw-r--r-- 1 fhem dialout 11M Dez 16 13:14 cache_logdb_2017-12-16_13-14-53
-rw-r--r-- 1 fhem dialout 11M Dez 16 13:19 cache_logdb_2017-12-16_13-19-54
-rw-r--r-- 1 fhem dialout 11M Dez 16 13:24 cache_logdb_2017-12-16_13-24-55
-rw-r--r-- 1 fhem dialout 11M Dez 16 13:29 cache_logdb_2017-12-16_13-29-56
-rw-r--r-- 1 fhem dialout 11M Dez 16 13:34 cache_logdb_2017-12-16_13-34-57
-rw-r--r-- 1 fhem dialout 11M Dez 16 13:39 cache_logdb_2017-12-16_13-39-58
-rw-r--r-- 1 fhem dialout 12M Dez 16 13:45 cache_logdb_2017-12-16_13-44-59
-rw-r--r-- 1 fhem dialout 12M Dez 16 13:50 cache_logdb_2017-12-16_13-50-00
-rw-r--r-- 1 fhem dialout 12M Dez 16 13:55 cache_logdb_2017-12-16_13-55-01
-rw-r--r-- 1 fhem dialout 12M Dez 16 14:00 cache_logdb_2017-12-16_14-00-02
-rw-r--r-- 1 fhem dialout 12M Dez 16 14:05 cache_logdb_2017-12-16_14-05-03
-rw-r--r-- 1 fhem dialout 12M Dez 16 14:10 cache_logdb_2017-12-16_14-10-04
-rw-r--r-- 1 fhem dialout 12M Dez 16 14:15 cache_logdb_2017-12-16_14-15-05
-rw-r--r-- 1 fhem dialout 13M Dez 16 14:20 cache_logdb_2017-12-16_14-20-07
-rw-r--r-- 1 fhem dialout 13M Dez 16 14:25 cache_logdb_2017-12-16_14-25-09
-rw-r--r-- 1 fhem dialout 13M Dez 16 14:30 cache_logdb_2017-12-16_14-30-11
-rw-r--r-- 1 fhem dialout 13M Dez 16 14:35 cache_logdb_2017-12-16_14-35-13
-rw-r--r-- 1 fhem dialout 13M Dez 16 14:40 cache_logdb_2017-12-16_14-40-15
-rw-r--r-- 1 fhem dialout 13M Dez 16 14:45 cache_logdb_2017-12-16_14-45-17
-rw-r--r-- 1 fhem dialout 13M Dez 16 14:50 cache_logdb_2017-12-16_14-50-19
-rw-r--r-- 1 fhem dialout 14M Dez 16 14:55 cache_logdb_2017-12-16_14-55-21
-rw-r--r-- 1 fhem dialout 14M Dez 16 15:00 cache_logdb_2017-12-16_15-00-23
-rw-r--r-- 1 fhem dialout 14M Dez 16 15:05 cache_logdb_2017-12-16_15-05-25
-rw-r--r-- 1 fhem dialout 14M Dez 16 15:10 cache_logdb_2017-12-16_15-10-27
-rw-r--r-- 1 fhem dialout 14M Dez 16 15:15 cache_logdb_2017-12-16_15-15-29
-rw-r--r-- 1 fhem dialout 14M Dez 16 15:20 cache_logdb_2017-12-16_15-20-31
-rw-r--r-- 1 fhem dialout 14M Dez 16 15:25 cache_logdb_2017-12-16_15-25-33
-rw-r--r-- 1 fhem dialout 14M Dez 16 15:30 cache_logdb_2017-12-16_15-30-35
-rw-r--r-- 1 fhem dialout 15M Dez 16 15:35 cache_logdb_2017-12-16_15-35-37
-rw-r--r-- 1 fhem dialout 15M Dez 16 15:40 cache_logdb_2017-12-16_15-40-39
-rw-r--r-- 1 fhem dialout 15M Dez 16 15:45 cache_logdb_2017-12-16_15-45-41
-rw-r--r-- 1 fhem dialout 15M Dez 16 15:50 cache_logdb_2017-12-16_15-50-43
-rw-r--r-- 1 fhem dialout 15M Dez 16 15:55 cache_logdb_2017-12-16_15-55-45
-rw-r--r-- 1 fhem dialout 15M Dez 16 16:00 cache_logdb_2017-12-16_16-00-47
-rw-r--r-- 1 fhem dialout 15M Dez 16 16:05 cache_logdb_2017-12-16_16-05-49
-rw-r--r-- 1 fhem dialout 15M Dez 16 16:10 cache_logdb_2017-12-16_16-10-51
-rw-r--r-- 1 fhem dialout 15M Dez 16 16:15 cache_logdb_2017-12-16_16-15-53
-rw-r--r-- 1 fhem dialout 16M Dez 16 16:20 cache_logdb_2017-12-16_16-20-55
-rw-r--r-- 1 fhem dialout 16M Dez 16 16:25 cache_logdb_2017-12-16_16-25-57
-rw-r--r-- 1 fhem dialout 16M Dez 16 16:31 cache_logdb_2017-12-16_16-30-59
-rw-r--r-- 1 fhem dialout 16M Dez 16 16:36 cache_logdb_2017-12-16_16-36-01
-rw-r--r-- 1 fhem dialout 16M Dez 16 16:41 cache_logdb_2017-12-16_16-41-03
-rw-r--r-- 1 fhem dialout 16M Dez 16 16:46 cache_logdb_2017-12-16_16-46-05
-rw-r--r-- 1 fhem dialout 16M Dez 16 16:51 cache_logdb_2017-12-16_16-51-07
-rw-r--r-- 1 fhem dialout 16M Dez 16 16:56 cache_logdb_2017-12-16_16-56-09
-rw-r--r-- 1 fhem dialout 16M Dez 16 17:01 cache_logdb_2017-12-16_17-01-11
-rw-r--r-- 1 fhem dialout 17M Dez 16 17:06 cache_logdb_2017-12-16_17-06-13
-rw-r--r-- 1 fhem dialout 17M Dez 16 17:11 cache_logdb_2017-12-16_17-11-15
-rw-r--r-- 1 fhem dialout 17M Dez 16 17:16 cache_logdb_2017-12-16_17-16-17
-rw-r--r-- 1 fhem dialout 17M Dez 16 17:21 cache_logdb_2017-12-16_17-21-19
-rw-r--r-- 1 fhem dialout 17M Dez 16 17:26 cache_logdb_2017-12-16_17-26-21
-rw-r--r-- 1 fhem dialout 17M Dez 16 17:31 cache_logdb_2017-12-16_17-31-23
-rw-r--r-- 1 fhem dialout 17M Dez 16 17:36 cache_logdb_2017-12-16_17-36-25
-rw-r--r-- 1 fhem dialout 17M Dez 16 17:41 cache_logdb_2017-12-16_17-41-27
-rw-r--r-- 1 fhem dialout 0 Dez 18 11:31 cache_logdb_2017-12-16_17-46-29
-rw-r--r-- 1 fhem dialout 17M Dez 16 17:51 cache_logdb_2017-12-16_17-51-31
-rw-r--r-- 1 fhem dialout 17M Dez 16 17:56 cache_logdb_2017-12-16_17-56-34
-rw-r--r-- 1 fhem dialout 18M Dez 16 18:01 cache_logdb_2017-12-16_18-01-37
-rw-r--r-- 1 fhem dialout 18M Dez 16 18:06 cache_logdb_2017-12-16_18-06-40
-rw-r--r-- 1 fhem dialout 18M Dez 16 18:11 cache_logdb_2017-12-16_18-11-43
-rw-r--r-- 1 fhem dialout 18M Dez 16 18:16 cache_logdb_2017-12-16_18-16-46
-rw-r--r-- 1 fhem dialout 18M Dez 16 18:21 cache_logdb_2017-12-16_18-21-49
-rw-r--r-- 1 fhem dialout 18M Dez 16 18:26 cache_logdb_2017-12-16_18-26-52
-rw-r--r-- 1 fhem dialout 18M Dez 16 18:31 cache_logdb_2017-12-16_18-31-55
-rw-r--r-- 1 fhem dialout 18M Dez 16 18:37 cache_logdb_2017-12-16_18-36-58
-rw-r--r-- 1 fhem dialout 18M Dez 16 18:42 cache_logdb_2017-12-16_18-42-01
-rw-r--r-- 1 fhem dialout 18M Dez 16 18:47 cache_logdb_2017-12-16_18-47-04
-rw-r--r-- 1 fhem dialout 18M Dez 16 18:52 cache_logdb_2017-12-16_18-52-07
-rw-r--r-- 1 fhem dialout 18M Dez 16 18:57 cache_logdb_2017-12-16_18-57-10
-rw-r--r-- 1 fhem dialout 18M Dez 16 19:02 cache_logdb_2017-12-16_19-02-13
-rw-r--r-- 1 fhem dialout 19M Dez 16 19:07 cache_logdb_2017-12-16_19-07-16
-rw-r--r-- 1 fhem dialout 19M Dez 16 19:12 cache_logdb_2017-12-16_19-12-19
-rw-r--r-- 1 fhem dialout 19M Dez 16 19:17 cache_logdb_2017-12-16_19-17-22
-rw-r--r-- 1 fhem dialout 19M Dez 16 19:22 cache_logdb_2017-12-16_19-22-25
-rw-r--r-- 1 fhem dialout 19M Dez 16 19:27 cache_logdb_2017-12-16_19-27-28
-rw-r--r-- 1 fhem dialout 19M Dez 16 19:32 cache_logdb_2017-12-16_19-32-31
-rw-r--r-- 1 fhem dialout 19M Dez 16 19:37 cache_logdb_2017-12-16_19-37-34
-rw-r--r-- 1 fhem dialout 19M Dez 16 19:42 cache_logdb_2017-12-16_19-42-37
-rw-r--r-- 1 fhem dialout 19M Dez 16 19:47 cache_logdb_2017-12-16_19-47-40
-rw-r--r-- 1 fhem dialout 19M Dez 16 19:52 cache_logdb_2017-12-16_19-52-43
-rw-r--r-- 1 fhem dialout 19M Dez 16 19:57 cache_logdb_2017-12-16_19-57-46
-rw-r--r-- 1 fhem dialout 19M Dez 16 20:02 cache_logdb_2017-12-16_20-02-49
-rw-r--r-- 1 fhem dialout 19M Dez 16 20:07 cache_logdb_2017-12-16_20-07-52
-rw-r--r-- 1 fhem dialout 19M Dez 16 20:12 cache_logdb_2017-12-16_20-12-55
-rw-r--r-- 1 fhem dialout 19M Dez 16 20:18 cache_logdb_2017-12-16_20-17-58
-rw-r--r-- 1 fhem dialout 19M Dez 16 20:23 cache_logdb_2017-12-16_20-23-01
-rw-r--r-- 1 fhem dialout 20M Dez 16 20:28 cache_logdb_2017-12-16_20-28-04
-rw-r--r-- 1 fhem dialout 20M Dez 16 20:33 cache_logdb_2017-12-16_20-33-07
-rw-r--r-- 1 fhem dialout 20M Dez 16 20:38 cache_logdb_2017-12-16_20-38-10
-rw-r--r-- 1 fhem dialout 20M Dez 16 20:43 cache_logdb_2017-12-16_20-43-13
-rw-r--r-- 1 fhem dialout 20M Dez 16 20:48 cache_logdb_2017-12-16_20-48-16
-rw-r--r-- 1 fhem dialout 20M Dez 16 20:53 cache_logdb_2017-12-16_20-53-19
-rw-r--r-- 1 fhem dialout 20M Dez 16 20:58 cache_logdb_2017-12-16_20-58-22
-rw-r--r-- 1 fhem dialout 20M Dez 16 21:03 cache_logdb_2017-12-16_21-03-25
-rw-r--r-- 1 fhem dialout 20M Dez 16 21:08 cache_logdb_2017-12-16_21-08-28
-rw-r--r-- 1 fhem dialout 20M Dez 16 21:13 cache_logdb_2017-12-16_21-13-31
-rw-r--r-- 1 fhem dialout 20M Dez 16 21:18 cache_logdb_2017-12-16_21-18-34
-rw-r--r-- 1 fhem dialout 20M Dez 16 21:23 cache_logdb_2017-12-16_21-23-37
-rw-r--r-- 1 fhem dialout 20M Dez 16 21:28 cache_logdb_2017-12-16_21-28-40
-rw-r--r-- 1 fhem dialout 20M Dez 16 21:33 cache_logdb_2017-12-16_21-33-43
-rw-r--r-- 1 fhem dialout 20M Dez 16 21:38 cache_logdb_2017-12-16_21-38-46
-rw-r--r-- 1 fhem dialout 0 Dez 18 11:29 cache_logdb_2017-12-16_21-43-49
-rw-r--r-- 1 fhem dialout 21M Dez 16 21:48 cache_logdb_2017-12-16_21-48-52
-rw-r--r-- 1 fhem dialout 21M Dez 16 21:53 cache_logdb_2017-12-16_21-53-55
-rw-r--r-- 1 fhem dialout 21M Dez 16 21:59 cache_logdb_2017-12-16_21-58-58
-rw-r--r-- 1 fhem dialout 21M Dez 16 22:04 cache_logdb_2017-12-16_22-04-01
-rw-r--r-- 1 fhem dialout 21M Dez 16 22:09 cache_logdb_2017-12-16_22-09-04
-rw-r--r-- 1 fhem dialout 21M Dez 16 22:14 cache_logdb_2017-12-16_22-14-07
-rw-r--r-- 1 fhem dialout 21M Dez 16 22:19 cache_logdb_2017-12-16_22-19-10
-rw-r--r-- 1 fhem dialout 21M Dez 16 22:24 cache_logdb_2017-12-16_22-24-13
-rw-r--r-- 1 fhem dialout 21M Dez 16 22:29 cache_logdb_2017-12-16_22-29-16
-rw-r--r-- 1 fhem dialout 21M Dez 16 22:34 cache_logdb_2017-12-16_22-34-19
-rw-r--r-- 1 fhem dialout 21M Dez 16 22:39 cache_logdb_2017-12-16_22-39-22
-rw-r--r-- 1 fhem dialout 21M Dez 16 22:44 cache_logdb_2017-12-16_22-44-25
-rw-r--r-- 1 fhem dialout 21M Dez 16 22:49 cache_logdb_2017-12-16_22-49-28
-rw-r--r-- 1 fhem dialout 21M Dez 16 22:54 cache_logdb_2017-12-16_22-54-31
-rw-r--r-- 1 fhem dialout 21M Dez 16 22:59 cache_logdb_2017-12-16_22-59-34
-rw-r--r-- 1 fhem dialout 21M Dez 16 23:04 cache_logdb_2017-12-16_23-04-37
-rw-r--r-- 1 fhem dialout 21M Dez 16 23:09 cache_logdb_2017-12-16_23-09-40
-rw-r--r-- 1 fhem dialout 22M Dez 16 23:14 cache_logdb_2017-12-16_23-14-43
-rw-r--r-- 1 fhem dialout 22M Dez 16 23:19 cache_logdb_2017-12-16_23-19-46
-rw-r--r-- 1 fhem dialout 22M Dez 16 23:24 cache_logdb_2017-12-16_23-24-50
-rw-r--r-- 1 fhem dialout 22M Dez 16 23:29 cache_logdb_2017-12-16_23-29-53
-rw-r--r-- 1 fhem dialout 22M Dez 16 23:35 cache_logdb_2017-12-16_23-34-57
-rw-r--r-- 1 fhem dialout 22M Dez 16 23:40 cache_logdb_2017-12-16_23-40-01
-rw-r--r-- 1 fhem dialout 22M Dez 16 23:45 cache_logdb_2017-12-16_23-45-05
-rw-r--r-- 1 fhem dialout 22M Dez 16 23:50 cache_logdb_2017-12-16_23-50-09
-rw-r--r-- 1 fhem dialout 22M Dez 16 23:55 cache_logdb_2017-12-16_23-55-12
-rw-r--r-- 1 fhem dialout 22M Dez 17 00:00 cache_logdb_2017-12-17_00-00-16
-rw-r--r-- 1 fhem dialout 22M Dez 17 00:05 cache_logdb_2017-12-17_00-05-20
-rw-r--r-- 1 fhem dialout 22M Dez 17 00:10 cache_logdb_2017-12-17_00-10-24
-rw-r--r-- 1 fhem dialout 22M Dez 17 00:15 cache_logdb_2017-12-17_00-15-28
-rw-r--r-- 1 fhem dialout 22M Dez 17 00:20 cache_logdb_2017-12-17_00-20-34
-rw-r--r-- 1 fhem dialout 22M Dez 17 00:25 cache_logdb_2017-12-17_00-25-42
-rw-r--r-- 1 fhem dialout 22M Dez 17 00:30 cache_logdb_2017-12-17_00-30-47
-rw-r--r-- 1 fhem dialout 22M Dez 17 00:36 cache_logdb_2017-12-17_00-35-59
-rw-r--r-- 1 fhem dialout 23M Dez 17 00:41 cache_logdb_2017-12-17_00-41-11
-rw-r--r-- 1 fhem dialout 23M Dez 17 00:46 cache_logdb_2017-12-17_00-46-15
-rw-r--r-- 1 fhem dialout 23M Dez 17 00:51 cache_logdb_2017-12-17_00-51-19
-rw-r--r-- 1 fhem dialout 23M Dez 17 00:56 cache_logdb_2017-12-17_00-56-23
-rw-r--r-- 1 fhem dialout 23M Dez 17 01:01 cache_logdb_2017-12-17_01-01-27
-rw-r--r-- 1 fhem dialout 23M Dez 17 01:06 cache_logdb_2017-12-17_01-06-31
-rw-r--r-- 1 fhem dialout 23M Dez 17 01:11 cache_logdb_2017-12-17_01-11-35
-rw-r--r-- 1 fhem dialout 23M Dez 17 01:16 cache_logdb_2017-12-17_01-16-39
-rw-r--r-- 1 fhem dialout 23M Dez 17 01:21 cache_logdb_2017-12-17_01-21-43
-rw-r--r-- 1 fhem dialout 23M Dez 17 01:26 cache_logdb_2017-12-17_01-26-47
-rw-r--r-- 1 fhem dialout 23M Dez 17 01:31 cache_logdb_2017-12-17_01-31-51
-rw-r--r-- 1 fhem dialout 23M Dez 17 01:37 cache_logdb_2017-12-17_01-36-56
-rw-r--r-- 1 fhem dialout 23M Dez 17 01:42 cache_logdb_2017-12-17_01-42-00
-rw-r--r-- 1 fhem dialout 23M Dez 17 01:47 cache_logdb_2017-12-17_01-47-04
-rw-r--r-- 1 fhem dialout 23M Dez 17 01:52 cache_logdb_2017-12-17_01-52-08
-rw-r--r-- 1 fhem dialout 23M Dez 17 01:57 cache_logdb_2017-12-17_01-57-12
-rw-r--r-- 1 fhem dialout 23M Dez 17 02:02 cache_logdb_2017-12-17_02-02-16
-rw-r--r-- 1 fhem dialout 23M Dez 17 02:07 cache_logdb_2017-12-17_02-07-20
-rw-r--r-- 1 fhem dialout 24M Dez 17 02:12 cache_logdb_2017-12-17_02-12-24
-rw-r--r-- 1 fhem dialout 24M Dez 17 02:17 cache_logdb_2017-12-17_02-17-30
-rw-r--r-- 1 fhem dialout 24M Dez 17 02:22 cache_logdb_2017-12-17_02-22-34
-rw-r--r-- 1 fhem dialout 24M Dez 17 02:27 cache_logdb_2017-12-17_02-27-38
-rw-r--r-- 1 fhem dialout 24M Dez 17 02:32 cache_logdb_2017-12-17_02-32-42
-rw-r--r-- 1 fhem dialout 24M Dez 17 02:37 cache_logdb_2017-12-17_02-37-47
-rw-r--r-- 1 fhem dialout 24M Dez 17 02:42 cache_logdb_2017-12-17_02-42-52
-rw-r--r-- 1 fhem dialout 24M Dez 17 02:48 cache_logdb_2017-12-17_02-47-57
-rw-r--r-- 1 fhem dialout 24M Dez 17 02:53 cache_logdb_2017-12-17_02-53-01
-rw-r--r-- 1 fhem dialout 24M Dez 17 02:58 cache_logdb_2017-12-17_02-58-05
-rw-r--r-- 1 fhem dialout 0 Dez 18 11:27 cache_logdb_2017-12-17_03-03-09
-rw-r--r-- 1 fhem dialout 24M Dez 17 03:08 cache_logdb_2017-12-17_03-08-13
-rw-r--r-- 1 root root 224K Dez 18 11:13 .cache_logdb_2017-12-17_03-08-13.swp
-rw-r--r-- 1 fhem dialout 24M Dez 17 03:13 cache_logdb_2017-12-17_03-13-18
-rw-r--r-- 1 fhem dialout 24M Dez 17 03:18 cache_logdb_2017-12-17_03-18-24
-rw-r--r-- 1 fhem dialout 24M Dez 17 03:23 cache_logdb_2017-12-17_03-23-29
-rw-r--r-- 1 fhem dialout 24M Dez 17 03:28 cache_logdb_2017-12-17_03-28-33
-rw-r--r-- 1 fhem dialout 24M Dez 17 03:33 cache_logdb_2017-12-17_03-33-38
-rw-r--r-- 1 fhem dialout 24M Dez 17 03:38 cache_logdb_2017-12-17_03-38-43
-rw-r--r-- 1 fhem dialout 24M Dez 17 03:43 cache_logdb_2017-12-17_03-43-48
-rw-r--r-- 1 fhem dialout 24M Dez 17 03:48 cache_logdb_2017-12-17_03-48-53
-rw-r--r-- 1 fhem dialout 24M Dez 17 03:54 cache_logdb_2017-12-17_03-53-58
-rw-r--r-- 1 fhem dialout 24M Dez 17 03:59 cache_logdb_2017-12-17_03-59-04
-rw-r--r-- 1 fhem dialout 25M Dez 17 04:04 cache_logdb_2017-12-17_04-04-09
-rw-r--r-- 1 fhem dialout 25M Dez 17 04:09 cache_logdb_2017-12-17_04-09-15
-rw-r--r-- 1 fhem dialout 25M Dez 17 04:14 cache_logdb_2017-12-17_04-14-21
-rw-r--r-- 1 fhem dialout 25M Dez 17 04:19 cache_logdb_2017-12-17_04-19-26
-rw-r--r-- 1 fhem dialout 25M Dez 17 04:24 cache_logdb_2017-12-17_04-24-32
-rw-r--r-- 1 fhem dialout 25M Dez 17 04:29 cache_logdb_2017-12-17_04-29-38
-rw-r--r-- 1 fhem dialout 25M Dez 17 04:34 cache_logdb_2017-12-17_04-34-43
-rw-r--r-- 1 fhem dialout 25M Dez 17 04:39 cache_logdb_2017-12-17_04-39-49
-rw-r--r-- 1 fhem dialout 25M Dez 17 04:45 cache_logdb_2017-12-17_04-44-55
-rw-r--r-- 1 fhem dialout 25M Dez 17 04:50 cache_logdb_2017-12-17_04-50-00
-rw-r--r-- 1 fhem dialout 25M Dez 17 04:55 cache_logdb_2017-12-17_04-55-05
-rw-r--r-- 1 fhem dialout 25M Dez 17 05:00 cache_logdb_2017-12-17_05-00-12
-rw-r--r-- 1 fhem dialout 25M Dez 17 05:05 cache_logdb_2017-12-17_05-05-18
-rw-r--r-- 1 fhem dialout 25M Dez 17 05:10 cache_logdb_2017-12-17_05-10-24
-rw-r--r-- 1 fhem dialout 25M Dez 17 05:15 cache_logdb_2017-12-17_05-15-30
-rw-r--r-- 1 fhem dialout 25M Dez 17 05:20 cache_logdb_2017-12-17_05-20-36
-rw-r--r-- 1 fhem dialout 25M Dez 17 05:25 cache_logdb_2017-12-17_05-25-44
-rw-r--r-- 1 fhem dialout 25M Dez 17 05:30 cache_logdb_2017-12-17_05-30-51
-rw-r--r-- 1 fhem dialout 25M Dez 17 05:36 cache_logdb_2017-12-17_05-35-57
-rw-r--r-- 1 fhem dialout 25M Dez 17 05:41 cache_logdb_2017-12-17_05-41-06
-rw-r--r-- 1 fhem dialout 25M Dez 17 05:46 cache_logdb_2017-12-17_05-46-13
-rw-r--r-- 1 fhem dialout 26M Dez 17 05:51 cache_logdb_2017-12-17_05-51-20
-rw-r--r-- 1 fhem dialout 26M Dez 17 05:56 cache_logdb_2017-12-17_05-56-27
-rw-r--r-- 1 fhem dialout 26M Dez 17 06:01 cache_logdb_2017-12-17_06-01-34
-rw-r--r-- 1 fhem dialout 26M Dez 17 06:06 cache_logdb_2017-12-17_06-06-41
-rw-r--r-- 1 fhem dialout 26M Dez 17 06:11 cache_logdb_2017-12-17_06-11-49
-rw-r--r-- 1 fhem dialout 26M Dez 17 06:17 cache_logdb_2017-12-17_06-16-56
-rw-r--r-- 1 fhem dialout 26M Dez 17 06:22 cache_logdb_2017-12-17_06-22-04
-rw-r--r-- 1 fhem dialout 26M Dez 17 06:27 cache_logdb_2017-12-17_06-27-11
-rw-r--r-- 1 fhem dialout 26M Dez 17 06:32 cache_logdb_2017-12-17_06-32-18
-rw-r--r-- 1 fhem dialout 26M Dez 17 06:37 cache_logdb_2017-12-17_06-37-26
-rw-r--r-- 1 fhem dialout 26M Dez 17 06:42 cache_logdb_2017-12-17_06-42-34
-rw-r--r-- 1 fhem dialout 26M Dez 17 06:47 cache_logdb_2017-12-17_06-47-41
-rw-r--r-- 1 fhem dialout 26M Dez 17 06:52 cache_logdb_2017-12-17_06-52-49
-rw-r--r-- 1 fhem dialout 26M Dez 17 06:58 cache_logdb_2017-12-17_06-57-55
-rw-r--r-- 1 fhem dialout 26M Dez 17 07:03 cache_logdb_2017-12-17_07-03-05
-rw-r--r-- 1 fhem dialout 26M Dez 17 07:08 cache_logdb_2017-12-17_07-08-13
-rw-r--r-- 1 fhem dialout 26M Dez 17 07:13 cache_logdb_2017-12-17_07-13-22
-rw-r--r-- 1 fhem dialout 26M Dez 17 07:18 cache_logdb_2017-12-17_07-18-32
-rw-r--r-- 1 fhem dialout 26M Dez 17 07:23 cache_logdb_2017-12-17_07-23-40
-rw-r--r-- 1 fhem dialout 26M Dez 17 07:28 cache_logdb_2017-12-17_07-28-47
-rw-r--r-- 1 fhem dialout 27M Dez 17 07:34 cache_logdb_2017-12-17_07-33-56
-rw-r--r-- 1 fhem dialout 27M Dez 17 07:39 cache_logdb_2017-12-17_07-39-05
-rw-r--r-- 1 fhem dialout 27M Dez 17 07:44 cache_logdb_2017-12-17_07-44-15
-rw-r--r-- 1 fhem dialout 27M Dez 17 07:49 cache_logdb_2017-12-17_07-49-22
-rw-r--r-- 1 fhem dialout 27M Dez 17 07:54 cache_logdb_2017-12-17_07-54-30
-rw-r--r-- 1 fhem dialout 27M Dez 17 07:59 cache_logdb_2017-12-17_07-59-38
-rw-r--r-- 1 fhem dialout 27M Dez 17 08:04 cache_logdb_2017-12-17_08-04-45
-rw-r--r-- 1 fhem dialout 27M Dez 17 08:10 cache_logdb_2017-12-17_08-09-53
-rw-r--r-- 1 fhem dialout 27M Dez 17 08:15 cache_logdb_2017-12-17_08-15-04
-rw-r--r-- 1 fhem dialout 27M Dez 17 08:20 cache_logdb_2017-12-17_08-20-12
-rw-r--r-- 1 fhem dialout 27M Dez 17 08:25 cache_logdb_2017-12-17_08-25-21
-rw-r--r-- 1 fhem dialout 27M Dez 17 08:30 cache_logdb_2017-12-17_08-30-30
-rw-r--r-- 1 fhem dialout 27M Dez 17 08:35 cache_logdb_2017-12-17_08-35-40
-rw-r--r-- 1 fhem dialout 27M Dez 17 08:40 cache_logdb_2017-12-17_08-40-49
-rw-r--r-- 1 fhem dialout 27M Dez 17 08:46 cache_logdb_2017-12-17_08-45-58
-rw-r--r-- 1 fhem dialout 27M Dez 17 08:51 cache_logdb_2017-12-17_08-51-08
-rw-r--r-- 1 fhem dialout 27M Dez 17 08:56 cache_logdb_2017-12-17_08-56-18
-rw-r--r-- 1 fhem dialout 27M Dez 17 09:01 cache_logdb_2017-12-17_09-01-28
-rw-r--r-- 1 fhem dialout 28M Dez 17 09:06 cache_logdb_2017-12-17_09-06-38
-rw-r--r-- 1 fhem dialout 28M Dez 17 09:11 cache_logdb_2017-12-17_09-11-49
-rw-r--r-- 1 fhem dialout 28M Dez 17 09:17 cache_logdb_2017-12-17_09-16-59
-rw-r--r-- 1 fhem dialout 28M Dez 17 09:22 cache_logdb_2017-12-17_09-22-10
-rw-r--r-- 1 fhem dialout 28M Dez 17 09:27 cache_logdb_2017-12-17_09-27-21
-rw-r--r-- 1 fhem dialout 28M Dez 17 09:32 cache_logdb_2017-12-17_09-32-32
-rw-r--r-- 1 fhem dialout 28M Dez 17 09:37 cache_logdb_2017-12-17_09-37-43
-rw-r--r-- 1 fhem dialout 28M Dez 17 09:43 cache_logdb_2017-12-17_09-42-54
-rw-r--r-- 1 fhem dialout 28M Dez 17 09:48 cache_logdb_2017-12-17_09-48-09
-rw-r--r-- 1 fhem dialout 28M Dez 17 09:53 cache_logdb_2017-12-17_09-53-19
-rw-r--r-- 1 fhem dialout 28M Dez 17 09:58 cache_logdb_2017-12-17_09-58-31
-rw-r--r-- 1 fhem dialout 28M Dez 17 10:03 cache_logdb_2017-12-17_10-03-41
-rw-r--r-- 1 fhem dialout 28M Dez 17 10:09 cache_logdb_2017-12-17_10-08-52
-rw-r--r-- 1 fhem dialout 28M Dez 17 10:14 cache_logdb_2017-12-17_10-14-05
-rw-r--r-- 1 fhem dialout 28M Dez 17 10:19 cache_logdb_2017-12-17_10-19-15
-rw-r--r-- 1 fhem dialout 28M Dez 17 10:24 cache_logdb_2017-12-17_10-24-26
-rw-r--r-- 1 fhem dialout 29M Dez 17 10:29 cache_logdb_2017-12-17_10-29-38
-rw-r--r-- 1 fhem dialout 29M Dez 17 10:35 cache_logdb_2017-12-17_10-34-49
-rw-r--r-- 1 fhem dialout 29M Dez 17 10:40 cache_logdb_2017-12-17_10-40-01
-rw-r--r-- 1 fhem dialout 29M Dez 17 10:45 cache_logdb_2017-12-17_10-45-13
-rw-r--r-- 1 fhem dialout 29M Dez 17 10:50 cache_logdb_2017-12-17_10-50-24
-rw-r--r-- 1 fhem dialout 29M Dez 17 10:55 cache_logdb_2017-12-17_10-55-35
-rw-r--r-- 1 fhem dialout 29M Dez 17 11:00 cache_logdb_2017-12-17_11-00-47
-rw-r--r-- 1 fhem dialout 29M Dez 17 11:06 cache_logdb_2017-12-17_11-06-00
-rw-r--r-- 1 fhem dialout 29M Dez 17 11:11 cache_logdb_2017-12-17_11-11-12
-rw-r--r-- 1 fhem dialout 29M Dez 17 11:16 cache_logdb_2017-12-17_11-16-24
-rw-r--r-- 1 fhem dialout 29M Dez 17 11:21 cache_logdb_2017-12-17_11-21-37
-rw-r--r-- 1 fhem dialout 29M Dez 17 11:27 cache_logdb_2017-12-17_11-26-49
-rw-r--r-- 1 fhem dialout 29M Dez 17 11:32 cache_logdb_2017-12-17_11-32-02
-rw-r--r-- 1 fhem dialout 30M Dez 17 11:37 cache_logdb_2017-12-17_11-37-15
-rw-r--r-- 1 fhem dialout 30M Dez 17 11:42 cache_logdb_2017-12-17_11-42-27
-rw-r--r-- 1 fhem dialout 30M Dez 17 11:47 cache_logdb_2017-12-17_11-47-40
-rw-r--r-- 1 fhem dialout 30M Dez 17 11:53 cache_logdb_2017-12-17_11-52-52
-rw-r--r-- 1 fhem dialout 30M Dez 17 11:58 cache_logdb_2017-12-17_11-58-08
-rw-r--r-- 1 fhem dialout 30M Dez 17 12:03 cache_logdb_2017-12-17_12-03-20
-rw-r--r-- 1 fhem dialout 30M Dez 17 12:08 cache_logdb_2017-12-17_12-08-34
-rw-r--r-- 1 fhem dialout 30M Dez 17 12:13 cache_logdb_2017-12-17_12-13-47
-rw-r--r-- 1 fhem dialout 30M Dez 17 12:19 cache_logdb_2017-12-17_12-18-59
-rw-r--r-- 1 fhem dialout 30M Dez 17 12:24 cache_logdb_2017-12-17_12-24-13
-rw-r--r-- 1 fhem dialout 30M Dez 17 12:29 cache_logdb_2017-12-17_12-29-26
-rw-r--r-- 1 fhem dialout 30M Dez 17 12:34 cache_logdb_2017-12-17_12-34-39
-rw-r--r-- 1 fhem dialout 30M Dez 17 12:40 cache_logdb_2017-12-17_12-39-52
-rw-r--r-- 1 fhem dialout 30M Dez 17 12:45 cache_logdb_2017-12-17_12-45-09
-rw-r--r-- 1 fhem dialout 30M Dez 17 12:50 cache_logdb_2017-12-17_12-50-22
-rw-r--r-- 1 fhem dialout 31M Dez 17 12:55 cache_logdb_2017-12-17_12-55-35
-rw-r--r-- 1 fhem dialout 31M Dez 17 13:01 cache_logdb_2017-12-17_13-00-48
-rw-r--r-- 1 fhem dialout 31M Dez 17 13:06 cache_logdb_2017-12-17_13-06-03
-rw-r--r-- 1 fhem dialout 31M Dez 17 13:11 cache_logdb_2017-12-17_13-11-17
-rw-r--r-- 1 fhem dialout 31M Dez 17 13:16 cache_logdb_2017-12-17_13-16-31
-rw-r--r-- 1 fhem dialout 31M Dez 17 13:22 cache_logdb_2017-12-17_13-21-45
-rw-r--r-- 1 fhem dialout 31M Dez 17 13:27 cache_logdb_2017-12-17_13-27-10
-rw-r--r-- 1 fhem dialout 31M Dez 17 13:32 cache_logdb_2017-12-17_13-32-33
-rw-r--r-- 1 fhem dialout 31M Dez 17 13:38 cache_logdb_2017-12-17_13-37-56
-rw-r--r-- 1 fhem dialout 31M Dez 17 13:43 cache_logdb_2017-12-17_13-43-19
-rw-r--r-- 1 fhem dialout 31M Dez 17 13:49 cache_logdb_2017-12-17_13-48-43
-rw-r--r-- 1 fhem dialout 31M Dez 17 13:54 cache_logdb_2017-12-17_13-54-08
-rw-r--r-- 1 fhem dialout 31M Dez 17 13:59 cache_logdb_2017-12-17_13-59-31
-rw-r--r-- 1 fhem dialout 32M Dez 17 14:05 cache_logdb_2017-12-17_14-04-55
-rw-r--r-- 1 fhem dialout 32M Dez 17 14:10 cache_logdb_2017-12-17_14-10-21
-rw-r--r-- 1 fhem dialout 32M Dez 17 14:16 cache_logdb_2017-12-17_14-15-44
-rw-r--r-- 1 fhem dialout 32M Dez 17 14:21 cache_logdb_2017-12-17_14-21-10
-rw-r--r-- 1 fhem dialout 32M Dez 17 14:26 cache_logdb_2017-12-17_14-26-32
-rw-r--r-- 1 fhem dialout 32M Dez 17 14:32 cache_logdb_2017-12-17_14-31-55
-rw-r--r-- 1 fhem dialout 32M Dez 17 14:37 cache_logdb_2017-12-17_14-37-23
-rw-r--r-- 1 fhem dialout 32M Dez 17 14:43 cache_logdb_2017-12-17_14-42-47
-rw-r--r-- 1 fhem dialout 32M Dez 17 14:48 cache_logdb_2017-12-17_14-48-14
-rw-r--r-- 1 fhem dialout 32M Dez 17 14:54 cache_logdb_2017-12-17_14-53-38
-rw-r--r-- 1 fhem dialout 32M Dez 17 14:59 cache_logdb_2017-12-17_14-59-03
-rw-r--r-- 1 fhem dialout 32M Dez 17 15:04 cache_logdb_2017-12-17_15-04-28
-rw-r--r-- 1 fhem dialout 32M Dez 17 15:10 cache_logdb_2017-12-17_15-09-52
-rw-r--r-- 1 fhem dialout 33M Dez 17 15:15 cache_logdb_2017-12-17_15-15-18
-rw-r--r-- 1 fhem dialout 33M Dez 17 15:21 cache_logdb_2017-12-17_15-20-41
-rw-r--r-- 1 fhem dialout 33M Dez 17 15:26 cache_logdb_2017-12-17_15-26-08
-rw-r--r-- 1 fhem dialout 33M Dez 17 15:31 cache_logdb_2017-12-17_15-31-32
-rw-r--r-- 1 fhem dialout 33M Dez 17 15:37 cache_logdb_2017-12-17_15-36-56
-rw-r--r-- 1 fhem dialout 33M Dez 17 15:42 cache_logdb_2017-12-17_15-42-21
-rw-r--r-- 1 fhem dialout 33M Dez 17 15:48 cache_logdb_2017-12-17_15-47-45
-rw-r--r-- 1 fhem dialout 33M Dez 17 15:53 cache_logdb_2017-12-17_15-53-10
-rw-r--r-- 1 fhem dialout 33M Dez 17 15:58 cache_logdb_2017-12-17_15-58-35
-rw-r--r-- 1 fhem dialout 33M Dez 17 16:04 cache_logdb_2017-12-17_16-03-59
-rw-r--r-- 1 fhem dialout 33M Dez 17 16:09 cache_logdb_2017-12-17_16-09-23
-rw-r--r-- 1 fhem dialout 33M Dez 17 16:15 cache_logdb_2017-12-17_16-14-47
-rw-r--r-- 1 fhem dialout 33M Dez 17 16:20 cache_logdb_2017-12-17_16-20-13
-rw-r--r-- 1 fhem dialout 34M Dez 17 16:26 cache_logdb_2017-12-17_16-25-37
-rw-r--r-- 1 fhem dialout 34M Dez 17 16:31 cache_logdb_2017-12-17_16-31-03
-rw-r--r-- 1 fhem dialout 34M Dez 17 16:36 cache_logdb_2017-12-17_16-36-28
-rw-r--r-- 1 fhem dialout 34M Dez 17 16:42 cache_logdb_2017-12-17_16-41-53
-rw-r--r-- 1 fhem dialout 34M Dez 17 16:47 cache_logdb_2017-12-17_16-47-23
-rw-r--r-- 1 fhem dialout 34M Dez 17 16:53 cache_logdb_2017-12-17_16-52-49
-rw-r--r-- 1 fhem dialout 34M Dez 17 16:58 cache_logdb_2017-12-17_16-58-17
-rw-r--r-- 1 fhem dialout 34M Dez 17 17:04 cache_logdb_2017-12-17_17-03-43
-rw-r--r-- 1 fhem dialout 34M Dez 17 17:09 cache_logdb_2017-12-17_17-09-11
-rw-r--r-- 1 fhem dialout 34M Dez 17 17:15 cache_logdb_2017-12-17_17-14-40
-rw-r--r-- 1 fhem dialout 34M Dez 17 17:20 cache_logdb_2017-12-17_17-20-08
-rw-r--r-- 1 fhem dialout 34M Dez 17 17:25 cache_logdb_2017-12-17_17-25-34
-rw-r--r-- 1 fhem dialout 34M Dez 17 17:31 cache_logdb_2017-12-17_17-31-00
-rw-r--r-- 1 fhem dialout 34M Dez 17 17:36 cache_logdb_2017-12-17_17-36-26
-rw-r--r-- 1 fhem dialout 35M Dez 17 17:42 cache_logdb_2017-12-17_17-41-52
-rw-r--r-- 1 fhem dialout 35M Dez 17 17:47 cache_logdb_2017-12-17_17-47-21
-rw-r--r-- 1 fhem dialout 35M Dez 17 17:53 cache_logdb_2017-12-17_17-52-48
-rw-r--r-- 1 fhem dialout 35M Dez 17 17:58 cache_logdb_2017-12-17_17-58-20
-rw-r--r-- 1 fhem dialout 35M Dez 17 18:04 cache_logdb_2017-12-17_18-03-46
-rw-r--r-- 1 fhem dialout 35M Dez 17 18:09 cache_logdb_2017-12-17_18-09-16
-rw-r--r-- 1 fhem dialout 35M Dez 17 18:15 cache_logdb_2017-12-17_18-14-43
-rw-r--r-- 1 fhem dialout 35M Dez 17 18:20 cache_logdb_2017-12-17_18-20-14
-rw-r--r-- 1 fhem dialout 35M Dez 17 18:26 cache_logdb_2017-12-17_18-25-40
-rw-r--r-- 1 fhem dialout 35M Dez 17 18:31 cache_logdb_2017-12-17_18-31-12
-rw-r--r-- 1 fhem dialout 35M Dez 17 18:37 cache_logdb_2017-12-17_18-36-39
-rw-r--r-- 1 fhem dialout 35M Dez 17 18:42 cache_logdb_2017-12-17_18-42-08
-rw-r--r-- 1 fhem dialout 35M Dez 17 18:48 cache_logdb_2017-12-17_18-47-34
-rw-r--r-- 1 fhem dialout 36M Dez 17 18:53 cache_logdb_2017-12-17_18-53-02
-rw-r--r-- 1 fhem dialout 36M Dez 17 18:58 cache_logdb_2017-12-17_18-58-30
-rw-r--r-- 1 fhem dialout 36M Dez 17 19:04 cache_logdb_2017-12-17_19-03-58
-rw-r--r-- 1 fhem dialout 36M Dez 17 19:09 cache_logdb_2017-12-17_19-09-27
-rw-r--r-- 1 fhem dialout 36M Dez 17 19:15 cache_logdb_2017-12-17_19-14-54
-rw-r--r-- 1 fhem dialout 36M Dez 17 19:20 cache_logdb_2017-12-17_19-20-29
-rw-r--r-- 1 fhem dialout 36M Dez 17 19:26 cache_logdb_2017-12-17_19-25-57
-rw-r--r-- 1 fhem dialout 36M Dez 17 19:31 cache_logdb_2017-12-17_19-31-25
-rw-r--r-- 1 fhem dialout 36M Dez 17 19:37 cache_logdb_2017-12-17_19-36-53
-rw-r--r-- 1 fhem dialout 36M Dez 17 19:42 cache_logdb_2017-12-17_19-42-26
-rw-r--r-- 1 fhem dialout 36M Dez 17 19:48 cache_logdb_2017-12-17_19-47-54
-rw-r--r-- 1 fhem dialout 37M Dez 17 19:53 cache_logdb_2017-12-17_19-53-27
-rw-r--r-- 1 fhem dialout 37M Dez 17 19:59 cache_logdb_2017-12-17_19-58-57
-rw-r--r-- 1 fhem dialout 37M Dez 17 20:04 cache_logdb_2017-12-17_20-04-27
-rw-r--r-- 1 fhem dialout 37M Dez 17 20:10 cache_logdb_2017-12-17_20-09-56
-rw-r--r-- 1 fhem dialout 37M Dez 17 20:15 cache_logdb_2017-12-17_20-15-25
-rw-r--r-- 1 fhem dialout 37M Dez 17 20:21 cache_logdb_2017-12-17_20-20-54
-rw-r--r-- 1 fhem dialout 37M Dez 17 20:26 cache_logdb_2017-12-17_20-26-25
-rw-r--r-- 1 fhem dialout 37M Dez 17 20:32 cache_logdb_2017-12-17_20-31-56
-rw-r--r-- 1 fhem dialout 37M Dez 17 20:37 cache_logdb_2017-12-17_20-37-27
-rw-r--r-- 1 fhem dialout 37M Dez 17 20:43 cache_logdb_2017-12-17_20-42-56
-rw-r--r-- 1 fhem dialout 37M Dez 17 20:48 cache_logdb_2017-12-17_20-48-25
-rw-r--r-- 1 fhem dialout 37M Dez 17 20:54 cache_logdb_2017-12-17_20-53-55
-rw-r--r-- 1 fhem dialout 37M Dez 17 21:00 cache_logdb_2017-12-17_20-59-29
-rw-r--r-- 1 fhem dialout 37M Dez 17 21:05 cache_logdb_2017-12-17_21-05-06
-rw-r--r-- 1 fhem dialout 37M Dez 17 21:11 cache_logdb_2017-12-17_21-10-40
-rw-r--r-- 1 fhem dialout 37M Dez 17 21:16 cache_logdb_2017-12-17_21-16-18
-rw-r--r-- 1 fhem dialout 37M Dez 17 21:22 cache_logdb_2017-12-17_21-21-51
-rw-r--r-- 1 fhem dialout 38M Dez 17 21:28 cache_logdb_2017-12-17_21-27-27
-rw-r--r-- 1 fhem dialout 38M Dez 17 21:33 cache_logdb_2017-12-17_21-33-01
-rw-r--r-- 1 fhem dialout 38M Dez 17 21:39 cache_logdb_2017-12-17_21-38-38
-rw-r--r-- 1 fhem dialout 38M Dez 17 21:44 cache_logdb_2017-12-17_21-44-21
-rw-r--r-- 1 fhem dialout 38M Dez 17 21:50 cache_logdb_2017-12-17_21-49-57
-rw-r--r-- 1 fhem dialout 38M Dez 17 21:56 cache_logdb_2017-12-17_21-55-52
-rw-r--r-- 1 fhem dialout 38M Dez 17 22:02 cache_logdb_2017-12-17_22-01-47
wie man sieht, steigt die Dateigröße an.
Die erste Auffälligkeit waren die ersten Dateien. Dort ist der Cache gesichert worden, aber (vermutlich, so weit bin ich noch nicht) danach *doch* in die Datenbank geschrieben worden. Zumindest wurde der Cache geleert. Deshalb fängt die nächste Datei an einer anderen Stelle an.
Sehr schwierig zu überblicken, angenommen vor allem, dass *nur* sporadische DB-Probleme bestehen.
Gibt es eine Möglichkeit, Dateien, deren Inhalt *doch* committed werden konnte, wieder zu entfernen? Oder ein Datenbank-Handle, welches sich mit jedem erfolgreichen Zugriff ändert, so dass man es zur Serienidentifikation von fehlgeschlagenen commits verwenden kann? Muss ja nicht mal ein menschenverständlicher Wert sein, sondern sich nur nach jedem commit ändern.
Dann kommen konsistente Daten, begonnen bei cache_logdb_2017-12-16_00-44-05 bis hin zu cache_logdb_2017-12-17_03-28-33.
Überprüft hab ich das folgendermaßen:
root@fhem:/opt/fhem/log# head -n1 cache_logdb_2017-12-16_00-44-05
2017-12-16 00:30:41|RE_TEMP_HV_RLA2|DUMMY||temperature|64.062|
root@fhem:/opt/fhem/log# head -n1 cache_logdb_2017-12-17_03-28-33
2017-12-16 00:30:41|RE_TEMP_HV_RLA2|DUMMY||temperature|64.062|
Leider wird das bei cache_logdb_2017-12-17_03-33-38 inkonsistent:
root@fhem:/opt/fhem/log# ls -alh cache_logdb_2017-12-17_03*
-rw-r--r-- 1 fhem dialout 24M Dez 17 03:28 cache_logdb_2017-12-17_03-28-33
-rw-r--r-- 1 fhem dialout 24M Dez 17 03:33 cache_logdb_2017-12-17_03-33-38
-rw-r--r-- 1 fhem dialout 24M Dez 17 03:38 cache_logdb_2017-12-17_03-38-43
-rw-r--r-- 1 fhem dialout 24M Dez 17 03:43 cache_logdb_2017-12-17_03-43-48
-rw-r--r-- 1 fhem dialout 24M Dez 17 03:48 cache_logdb_2017-12-17_03-48-53
-rw-r--r-- 1 fhem dialout 24M Dez 17 03:54 cache_logdb_2017-12-17_03-53-58
-rw-r--r-- 1 fhem dialout 24M Dez 17 03:59 cache_logdb_2017-12-17_03-59-04
root@fhem:/opt/fhem/log#
root@fhem:/opt/fhem/log# head -n1 cache_logdb_2017-12-17_03-33-38
2017-12-17 03:31:55|RE_TEMP_HV_RLA2|DUMMY||temperature|63.812|
wenn ich in cache_logdb_2017-12-17_03-33-38 reinschaue, sehe ich, dass die Reihenfolge der Zeilen vertauscht ist:
1 2017-12-17 03:31:55|RE_TEMP_HV_RLA2|DUMMY||temperature|63.812|
2 2017-12-17 03:31:55|RE_TEMP_PS3000_06|DUMMY||temperature|77.25|
3 2017-12-17 03:31:56|RE_TEMP_PS3000_11|DUMMY||temperature|80.56|
4 2017-12-17 03:31:56|RE_TEMP_PS3000_04|DUMMY||temperature|49.38|
[...]
227 2017-12-17 03:33:36|RE_TEMP_Ruecklauf_EG_Boden|DUMMY||temperature|25.94|
228 2017-12-17 03:33:37|RE_TEMP_Ruecklauf_WT_EG|DUMMY||temperature|28.12|
229 2017-12-17 03:33:37|RE_TEMP_Vorlauf_Solar|DUMMY||temperature|24.19|
--> 230 2017-12-16 00:30:41|RE_TEMP_HV_RLA2|DUMMY||temperature|64.062|<--!!!das war bisher die erste Zeile...
231 2017-12-16 00:30:41|KNX01.O03_Aktor_Leuchte_HZGRaum|KNX||state|on|
232 2017-12-16 00:30:41|KNX01.O01_Aktor_Leuchte_Flur_EG_OG|KNX||state|on|
[...]
377649 2017-12-17 03:31:53|RE_TEMP_PS3000_03|DUMMY||temperature|42.00|
377650 2017-12-17 03:31:53|RE_TEMP_PS3000_07|DUMMY||temperature|81.62|
377651 2017-12-17 03:31:54|KNX02.O07_Stromwert|KNX||power|4.6|
377652 2017-12-17 03:31:54|KNX02.O07_Stromwert|KNX||current|0.02|
377653 2017-12-17 03:31:54|RE_TEMP_PS3000_02|DUMMY||temperature|39.19|
377654 2017-12-17 03:31:54|RE_TEMP_PS3000_10|DUMMY||temperature|82.19|
377655 2017-12-17 03:31:55|RE_TEMP_PS3000_05|DUMMY||temperature|61.00|
Anscheinend wird jetzt in der Mitte der Logdateien weiter geschrieben:
-rw-r--r-- 1 fhem dialout 38M Dez 17 21:44 cache_logdb_2017-12-17_21-44-21
-rw-r--r-- 1 fhem dialout 38M Dez 17 21:50 cache_logdb_2017-12-17_21-49-57
-rw-r--r-- 1 fhem dialout 38M Dez 17 21:56 cache_logdb_2017-12-17_21-55-52
-rw-r--r-- 1 fhem dialout 38M Dez 17 22:02 cache_logdb_2017-12-17_22-01-47
cache_logdb_2017-12-17_22-01-47:
220958 2017-12-17 22:01:46|PID.FUBO|PID20||p_i|-51.6500000000299|
220959 2017-12-17 22:01:46|PID.FUBO|PID20||actuation|196|
220960 2017-12-17 22:01:46|PID.FUBO|PID20||actuationCalc|195.879976790655|
220961 2017-12-16 00:30:41|RE_TEMP_HV_RLA2|DUMMY||temperature|64.062|
220962 2017-12-16 00:30:41|KNX01.O03_Aktor_Leuchte_HZGRaum|KNX||state|on|
220963 2017-12-16 00:30:41|KNX01.O01_Aktor_Leuchte_Flur_EG_OG|KNX||state|on|
Vielleicht ist das jetzt ein Problem beim Import?
Grüße,
Stephan
zum Thema fehlerhafte Abfrage im Log:
ich habe bei mir - trotz Loglevel 5 - lediglich folgende Einträge gefunden.
Zitat1477219 2017.12.17 22:16:45.845 4: DbLog logdb -> processing event Timestamp: 2017-12-17 03:31:53, Device: RE_TEMP_PS3000_07, Type: DUMMY, Event: , Reading: temperature, Value: 81.62, Unit:
1477220
1477221 2017.12.17 22:16:45.845 4: DbLog logdb -> processing event Timestamp: 2017-12-17 03:31:54, Device: KNX02.O07_Stromwert, Type: KNX, Event: , Reading: power, Value: 4.6, Unit:
1477222
1477223 2017.12.17 22:16:45.845 4: DbLog logdb -> processing event Timestamp: 2017-12-17 03:31:54, Device: KNX02.O07_Stromwert, Type: KNX, Event: , Reading: current, Value: 0.02, Unit:
1477224
1477225 2017.12.17 22:16:45.845 4: DbLog logdb -> processing event Timestamp: 2017-12-17 03:31:54, Device: RE_TEMP_PS3000_02, Type: DUMMY, Event: , Reading: temperature, Value: 39.19, Unit:
1477226
1477227 2017.12.17 22:16:45.846 4: DbLog logdb -> processing event Timestamp: 2017-12-17 03:31:54, Device: RE_TEMP_PS3000_10, Type: DUMMY, Event: , Reading: temperature, Value: 82.19, Unit:
1477228
1477229 2017.12.17 22:16:45.846 4: DbLog logdb -> processing event Timestamp: 2017-12-17 03:31:55, Device: RE_TEMP_PS3000_05, Type: DUMMY, Event: , Reading: temperature, Value: 61.00, Unit:
1477230
1477231 2017.12.17 22:25:54.143 2: DbLog logdb -> Error table history - DBD::mysql::st execute_array failed: executing 598386 generated 22 errors at ./FHEM/93_DbLog.pm line 1515.
1477232
1477233 2017.12.17 22:29:06.627 4: DbLog logdb -> insert history rolled back
1477234 2017.12.17 22:29:08.857 4: DbLog logdb -> ################################################################
1477235 2017.12.17 22:29:08.857 4: DbLog logdb -> ### start of new Logcycle ###
1477236 2017.12.17 22:29:08.858 4: DbLog logdb -> ################################################################
1477237 2017.12.17 22:29:08.858 4: DbLog logdb -> amount of events received: 1 for device: logdb
1477238 2017.12.17 22:29:08.858 4: DbLog logdb -> check Device: logdb , Event: lastCachefile: ./log/cache_logdb_2017-12-17_22-01-47 - Error - Operation not supported
1477239 2017.12.17 22:29:09.827 4: DbLog logdb -> ################################################################
1477240 2017.12.17 22:29:09.827 4: DbLog logdb -> ### start of new Logcycle ###
1477241 2017.12.17 22:29:09.827 4: DbLog logdb -> ################################################################
1477242 2017.12.17 22:29:09.827 4: DbLog logdb -> amount of events received: 1 for device: logdb
1477243 2017.12.17 22:29:09.827 4: DbLog logdb -> check Device: logdb , Event: state: DBD::mysql::st execute_array failed: executing 598386 generated 22 errors at ./FHEM/93_DbLog.pm line 1515.
1477244
1477245 2017.12.17 22:29:09.848 5: DbLog logdb -> DbLog_Push Returncode: DBD::mysql::st execute_array failed: executing 598386 generated 22 errors at ./FHEM/93_DbLog.pm line 1515.
1477246
1477247 2017.12.17 22:29:10.078 4: DbLog logdb -> ################################################################
1477248 2017.12.17 22:29:10.079 4: DbLog logdb -> ### start of new Logcycle ###
1477249 2017.12.17 22:29:10.079 4: DbLog logdb -> ################################################################
1477250 2017.12.17 22:29:10.079 4: DbLog logdb -> amount of events received: 1 for device: RE_TEMP_Vorlauf_WW
1477251 2017.12.17 22:29:10.079 4: DbLog logdb -> check Device: RE_TEMP_Vorlauf_WW , Event: temperature: 43.25
1477252 2017.12.17 22:29:10.080 4: DbLog logdb -> added event - Timestamp: 2017-12-17 22:29:10, Device: RE_TEMP_Vorlauf_WW, Type: DUMMY, Event: , Reading: temperature, Value: 43.25, Unit:
1477253 2017.12.17 22:29:10.081 4: DbLog logdb -> ################################################################
1477254 2017.12.17 22:29:10.082 4: DbLog logdb -> ### start of new Logcycle ###
1477255 2017.12.17 22:29:10.082 4: DbLog logdb -> ################################################################
1477256 2017.12.17 22:29:10.082 4: DbLog logdb -> amount of events received: 1 for device: tempOWarduino
1477257 2017.12.17 22:29:10.082 4: DbLog logdb -> check Device: tempOWarduino , Event: 28AE7720070000: 43.25
Grüße,
Stephan
Okay, hab den Fehler gefunden .. hoffentlich blick ich bei den Dateien jetzt noch durch xD
2017-12-17 04:00:02|alarmbot|TELEGRAMBOT||state|message calcVL:
Aussentemperatursensor überprüfen!!|
2017-12-17 04:00:02|PID.FUBO|PID20||desired|31.5|
der Zeilenumbruch erzeugt den Fehler.
Hat sich für mich erledigt, weil ich (vorhin schon ) alle bots vom Log ausgeschlossen habe.
Kannst du das aber trotzdem irgendwie abfangen? so dass es zb umgewandelt wird in ein lesbares \n, wenn/falls die Datenbank damit nicht umgehen kann?
ich.. versuch mal, die restlichen Dateien jetzt zu importieren :-)
Grüße,
Stephan
So, ich habe mich jetzt durchgewühlt.. fürchte, ich hab ein paar duplikate und ein paar Lücken erzeugt.
Werde jetzt umstellen auf exportFile mit purgeCache, dafür das limit etwas höher.
und im Zweifel, das hatte ich nämlich nicht bedacht, können die Dateien mit
cat zusammengefügt werden ...
Grüße,
stephan
Hallo Stephan,
da hast du dich ja klasse durchgearbeitet :)
Zitatfürchte, ich hab ein paar duplikate und ein paar Lücken erzeugt.
Die Duplikate kannst du vllt. mit der neuen DbRep-Funktion delSeqDoublets wieder loswerden.
ZitatKannst du das aber trotzdem irgendwie abfangen? so dass es zb umgewandelt wird in ein lesbares \n, wenn/falls die Datenbank damit nicht umgehen kann?
Das gibt es bereits ! Dazu aktivierst du dir das Attribut useCharfilter=1. Damit werden Steuerzeichen entfernt und Umlaute umgesetzt.
Es wirkt momentan nur beim loggen, ich werde die Filtermöglichkeit noch in die importCachfile Funktion einbauen. Setze dir dieses Attribut am Besten. Dann sollte so etwas wie du erlebt hast nicht mehr vorkommen.
ZitatGibt es eine Möglichkeit, Dateien, deren Inhalt *doch* committed werden konnte, wieder zu entfernen? Oder ein Datenbank-Handle, welches sich mit jedem erfolgreichen Zugriff ändert, so dass man es zur Serienidentifikation von fehlgeschlagenen commits verwenden kann?
So etwas kann ich nicht realisieren. Um doppelte DB-Einträge zu verhindern, ist ein primary key das probate Mittel. Dann kann man auch wiederholt ein File importieren ohne dass mehrfach identische Einträge angelegt werden.
Zitate) was hältst du davon, wenn ein Fehler auftritt, die fehlerhafte Zeile 1:1 ins Log zu schreiben?
Habe nochmal nachgeschaut .... es wird jetzt schon mit verbose level 3 im Logfile wenn ein Datensatz nicht weggeschrieben werden konnte.
Allerdings muss das DB-Interface diese Info liefern, sonst kann nichts protokolliert werden.
LG,
Heiko
Hallo zusammen,
anbei die Version 3.5.0.
Der Zeichenfilter (einschalten mit dem Attribut useCharfilter ) wirkt nun auch bei importCacheFile und addCacheLine.
Der Filter wird nun direkt auf den zu verarbeitenden Event angewendet. Es werden unerwünschte Steuerzeichen im Event ausgesondert.
Die commandref ist diesbezüglich etwas erweitert.
Grüße
Heiko
Zitat von: DS_Starter am 18 Dezember 2017, 20:04:28
Habe nochmal nachgeschaut .... es wird jetzt schon mit verbose level 3 im Logfile wenn ein Datensatz nicht weggeschrieben werden konnte.
Allerdings muss das DB-Interface diese Info liefern, sonst kann nichts protokolliert werden.
Hi,
vielleicht haben wir uns da missverstanden: es ging nicht darum, *dass* ein Datensatz nicht weggeschrieben werden konnte (das stand ja drin), sondern *welcher* Datensatz nicht geschrieben werden konnte... das hätte mir vermutlich etwa 6h arbeit gespart heute :-)
Zumal ich diese blöden Meldungen *eigentlich* eh nicht speichern wollte ::)
EDIT:
PK-> würdest du den auf TIMESTAMP anwenden?
Es müsste vielleicht mal ne Wiki-Seite mit den ganzen Datenbankoptimierungen geben... vielleicht fang ich sowas mal an, mir fehlt da aber noch enorm Verständnis.
Ist die Wahrscheinlichkeit, dass zwei Events zum gleichen Zeitpunkt kommen, hinreichend gering?
Grüße,
Stephan
Zitatvielleicht haben wir uns da missverstanden: es ging nicht darum, *dass* ein Datensatz nicht weggeschrieben werden konnte (das stand ja drin), sondern *welcher*
Nein, schon richtig verstanden. Es wird auch im Logfile ausgegeben welche Daten Probleme bereiten. Das geht aber nur sofern das DB-.Interface die Information rausbringt. Regelmäßig passiert das wenn ein Datensatz wegen eines gesetzten PK nicht geschrieben werden kann.
Zitat
PK-> würdest du den auf TIMESTAMP anwenden?
Es müsste vielleicht mal ne Wiki-Seite mit den ganzen Datenbankoptimierungen geben... vielleicht fang ich sowas mal an, mir fehlt da aber noch enorm Verständnis.
Ist die Wahrscheinlichkeit, dass zwei Events zum gleichen Zeitpunkt kommen, hinreichend gering?
ja, habe ich gemacht. Timestamp, device, reading ist mit dabei. Bei mir ist diese Kombination genau richtig.
Ich glaube so eine Wikiseite wurde schon begonnen, habe aber keine Zeit dafür ...
Grüße
Heiko
Hi,
seit ein paar Minuten habe ich wieder ein Problem:
State vom logdb-Device sagt:
state
Commit already running - resync at NextSync
2017-12-20 14:44:01
Mein Device sieht wie folgt aus:
Zitat
Internals:
COLUMNS field length used for Device: 64, Type: 64, Event: 0, Reading: 64, Value: 128, Unit: 32
CONFIGURATION ./db_fhem.conf
DEF ./db_fhem.conf .*:.*
MODE asynchronous
MODEL MYSQL
NAME logdb
NR 311
NTFY_ORDER 50-logdb
PID 8425
REGEXP .*:.*
STATE Commit already running - resync at NextSync
TYPE DbLog
UTF8 1
VERSION 3.4.0
dbconn mysql:database=fhem;host=localhost;port=3306
dbuser fhemuser
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 0
OLDSTATE Commit already running - resync at NextSync
READINGCOL 64
TYPECOL 64
UNITCOL 32
VALUECOL 128
READINGS:
2017-12-20 14:46:23 CacheUsage 1060
2017-12-20 14:46:23 NextSync 2017-12-20 14:47:23 or if CacheUsage 1000 reached
2017-12-20 14:43:02 lastCachefile ./log/cache_logdb_2017-12-20_14-43-02 export successful
2017-12-20 14:46:23 state Commit already running - resync at NextSync
cache:
index 1060
Attributes:
DbLogSelectionMode Include
DbLogType History
asyncMode 1
cacheEvents 2
cacheLimit 1000
colEvent 0
room Logging
syncInterval 60
useCharfilter 1
userReadings DbFileSize:lastReduceLogResult.* { (split(' ',`du -m fhem.db`))[0] }
verbose 5
configCheck:
Zitat
Result of connection check
Connection to database fhem successfully done.
Recommendation: settings o.k.
Result of encoding check
Encoding used by Client (connection): UTF8
Encoding used by DB fhem: UTF8
Recommendation: settings o.k.
Result of logmode check
Logmode of DbLog-device logdb is: asynchronous
Recommendation: settings o.k.
Result of table 'history' check
Column width set in DB fhem.history: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 0, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: settings o.k.
Result of table 'current' check
Column width set in DB fhem.current: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 0, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: settings o.k.
Result of check 'Search_Idx' availability
Index 'Search_Idx' exists and contains the recommended fields 'DEVICE', 'READING', 'TIMESTAMP'.
Recommendation: settings o.k.
Result of check 'Report_Idx' availability for DbRep-devices
You use at least one DbRep-device assigned to logdb, but the recommended index 'Report_Idx' is missing.
Recommendation: You can create the index by executing statement 'CREATE INDEX Report_Idx ON `history` (TIMESTAMP, READING) USING BTREE;'
Depending on your database size this command may running a long time.
Please make sure the device 'logdb' is operating in asynchronous mode to avoid FHEM from blocking when creating the index.
Note: If you have just created another index which covers the same fields and order as suggested (e.g. a primary key) you don't need to create the 'Report_Idx' as well !
in der Log-Datei steht kein Hinweis auf einen Fehler, nur quasi die "Antwort" auf mein DOIF/notify, welches die anzahl der Datensätze überwacht und den exportCache sowie den purgeCache anstößt und mir per Telegram eine Info zukommen lässt.
2034101 2017.12.20 14:43:00.652 5: DbLog logdb -> Number of cache entries reached cachelimit 1000 - start database sync.
2034102 2017.12.20 14:43:01.021 5: DbLog logdb -> Number of cache entries reached cachelimit 1000 - start database sync.
2034103 2017.12.20 14:43:01.196 5: DbLog logdb -> Number of cache entries reached cachelimit 1000 - start database sync.
2034104 2017.12.20 14:43:01.255 1: PERL WARNING: Argument "-62317 W" isn't numeric in subtraction (-) at FHEM/TimeSeries.pm line 247.
2034105 2017.12.20 14:43:01.255 1: PERL WARNING: Argument "-62317 W" isn't numeric in sort at FHEM/TimeSeries.pm line 316.
2034106 2017.12.20 14:43:01.256 1: PERL WARNING: Argument "-62317 W" isn't numeric in numeric lt (<) at FHEM/TimeSeries.pm line 354.
2034107 2017.12.20 14:43:01.282 5: DbLog logdb -> Number of cache entries reached cachelimit 1000 - start database sync.
2034108 2017.12.20 14:43:01.302 5: DbLog logdb -> Number of cache entries reached cachelimit 1000 - start database sync.
2034109 2017.12.20 14:43:01.321 5: DbLog logdb -> Number of cache entries reached cachelimit 1000 - start database sync.
2034110 2017.12.20 14:43:01.339 5: DbLog logdb -> Number of cache entries reached cachelimit 1000 - start database sync.
2034111 2017.12.20 14:43:01.740 5: DbLog logdb -> Number of cache entries reached cachelimit 1000 - start database sync.
2034112 2017.12.20 14:43:02.080 3: DbLog logdb: 3217 cache rows exported to ./log/cache_logdb_2017-12-20_14-43-02.
2034113 2017.12.20 14:43:04.892 1: PERL WARNING: Subroutine myUtilsHZG_Initialize redefined at ./FHEM/99_myUtilsHZG.pm line 14.
2034114 2017.12.20 14:43:04.893 1: PERL WARNING: Subroutine getStoredEnergy redefined at ./FHEM/99_myUtilsHZG.pm line 18.
2034115 2017.12.20 14:43:04.897 1: PERL WARNING: Subroutine controlVL redefined at ./FHEM/99_myUtilsHZG.pm line 77.
2034116 2017.12.20 14:43:04.900 1: PERL WARNING: Subroutine UWP_Garage redefined at ./FHEM/99_myUtilsHZG.pm line 338.
2034117 2017.12.20 14:43:04.907 1: PERL WARNING: Subroutine Heizschleifenbetrieb redefined at ./FHEM/99_myUtilsHZG.pm line 379.
2034118 2017.12.20 14:43:04.910 1: PERL WARNING: Subroutine calcVL redefined at ./FHEM/99_myUtilsHZG.pm line 629.
2034119 2017.12.20 14:43:04.914 1: PERL WARNING: Subroutine Heizkesselbetrieb redefined at ./FHEM/99_myUtilsHZG.pm line 723.
2034120 2017.12.20 14:43:04.917 1: PERL WARNING: Subroutine kessel redefined at ./FHEM/99_myUtilsHZG.pm line 826.
2034121 2017.12.20 14:43:04.919 1: PERL WARNING: Subroutine set_temp_values redefined at ./FHEM/99_myUtilsHZG.pm line 874.
2034122 2017.12.20 14:43:04.921 1: PERL WARNING: Subroutine getHashTemps redefined at ./FHEM/99_myUtilsHZG.pm line 906.
2034123 2017.12.20 14:43:04.923 1: PERL WARNING: Subroutine getResTemps redefined at ./FHEM/99_myUtilsHZG.pm line 965.
2034124 2017.12.20 14:43:04.932 1: PERL WARNING: Subroutine OWtemp redefined at ./FHEM/99_myUtilsHZG.pm line 989.
2034125 2017.12.20 14:43:04.936 1: PERL WARNING: Subroutine move_heat redefined at ./FHEM/99_myUtilsHZG.pm line 1075.
2034126 2017.12.20 14:43:04.993 3: N_backupMyUtils return value: -1
2034127 2017.12.20 14:43:05.026 1: Perfmon: possible freeze starting at 14:43:04, delay is 1.026
mysql tut *nichts*:
mysql> show full processlist;
+------+----------+-----------+------+---------+------+----------+-----------------------+
| Id | User | Host | db | Command | Time | State | Info |
+------+----------+-----------+------+---------+------+----------+-----------------------+
| 2497 | fhemuser | localhost | fhem | Sleep | 821 | | NULL |
| 2520 | root | localhost | NULL | Query | 0 | starting | show full processlist |
+------+----------+-----------+------+---------+------+----------+-----------------------+
2 rows in set (0.00 sec)
mysql>
Was kann ich tun?
Grüße,
Stephan
- aktuelles fhem update (heute morgen ) machen
- du machst ein export mit purgecache, dann ist nach dem export der cache leer, richtig ?
- schau in das erzeugte file ob dir etwas auffällt was noch störend sein könnte.oder schicke dax file mal als pm wenn das geht, du das willst
Grüße
Heiko
Hi,
- update ist gemacht,
- der Cache ist nach dem export und purge leer, ja
- der Fehler tritt jetzt natürlich nicht mehr auf (nach dem shutdown restart).
- in den Logfiles steht nix aussergewöhnliches drin, und sie lassen sich auch einwandfrei mit importCacheFile einlesen.
- ein neustart von mysql hat nicht geholfen
- der neustart von FHEM hats dann gelöst.
Ich melde mich, wenns was neues gibt.
Wenn du *immer noch/trotzdem* ein Logfile haben willst, sag bescheid..
Grüße,
Stephan
da sich die cachefiles einwandfrei einlesen lassen macht es wenig sinn darin noch zu suchen. Wobei nun der charfilter auch beim importcachefile wirkt. Möglicherweise dann doch einen Blick wert ....
In der eingecheckten version habe ich den charfilter an eine andere stelle gesetzt die sich direkt auf den übermittelten event auswirkt, deswegen war es wichtig das update zu machen. ich habe es bei mir mit künstlich erzeugten daten die einen zeilenumbruch enthielten ausgetestet .... hat einwandfrei funktioniert.
wenn es nochmal auftreten sollte und du dbrep v7.0.0 im einsatz hast dann mch mal ein get blockinginfo. die ausgabe erfolgt gekürzt und blockiert nicht den browser. schau dir auch mal das globale attribut blockingcallmax an. Hast du das gesetzt ?
Edit: was du auch in dieser Situation machen kannst .... ein set reopen
Grüsse,
Heiko
blockingcallmax -> war gesetzt. auf 2. Warum auch immer, habs jetzt mal auf 5 geändert. Kann natürlich dann direkt der Grund gewesen sein.
Möglicherweise dann doch einen Blick wert .... -> hab die Dateien mal durchgeschaut.. ein Zeilenumbruch isses jedenfalls nicht...
get blockinginfo -> werd ich machen, hab ich diesmal natürlich wieder vergessen. hmpf.
set reopen -> ob ich jetzt ein set reopen mache oder ein shutdown restart... meistens installier ich dann auch noch system-updates und reboote den ganzen Rechner. Versuch ich nächtes mal aber dran zu denken.
Grüße,
Stephan
ja die begrenzung durch blockingcallmax kann sich ungünstig auswirken. ich müsste mal in rudis code reinschauen wie sich der parameter genau auswirkt, begrenzend oder nur verzögernd, bin mir unsicher.
weshalb hast den überhaupt gesetzt ? Hast du probleme mit den forks ?
LG
Heiko
das bringt mich auf die idee das setting von global blockingcallmax im configcheck mit zu überprüfen und den user darauf hinzuweisen falls sehr eng gesetzt..
Grüsse
Heiko
Zitat von: DS_Starter am 20 Dezember 2017, 17:16:47ich müsste mal in rudis code reinschauen wie sich der parameter genau auswirkt, begrenzend oder nur verzögernd, bin mir unsicher.
Laut Wiki:
ZitatSofern die maximale parallele Anzahl an BlockingCalls erreicht ist, werden weitere Calls in eine Warteschlange eingereiht und ausgeführt, sobald laufende Calls beendet werden.
https://wiki.fhem.de/wiki/Blocking_Call#Einschr.C3.A4nkungen (https://wiki.fhem.de/wiki/Blocking_Call#Einschr.C3.A4nkungen)
Danke für den Hinweis, dessen war ich mir bisher nicht bewusst.
Hallo Pyro,
das erspart mir das nachgrasen im Code. :)
Damit ist auch klar dass in dem Fall eine nicht näher festgelegte Verzögerung eintritt.
@alll, anbei ist die erweiterte Version 3.6.0.
Ich habe die blockingCallMax-Prüfung im configCheck mit eingebaut und dabei gleichzeitig auch den configCheck für SQLITE-Datenbanken verfügbar gemacht.
Grüße
Heiko
Hi,
Zitatweshalb hast den überhaupt gesetzt ? Hast du probleme mit den forks ?
Ich.. habe an einem eigenen BlockingCall rumprobiert, und durch zu viele forks (das Endgerät hat nicht geantwortet) FHEM abgeschossen.
Da dieses Projekt aber in den Akten liegt, könnte ich die Begrenzung eigtl auch wieder ganz raus machen.
Grüße,
Stephan
So, bin wieder soweit, dass es hängt.
blockingInfo zeigt: Presence ist böse ::)
ZitatPid:WAITING: Fn:PRESENCE_DoLocalPingScan Arg:SGS5_Stephan|SGS5-Stephan|0|4 Timeout:60 ConnectedVia:N/A
Pid:WAITING: Fn:PROPLANTA_Run Arg:wetter_prop Timeout:120 ConnectedVia:N/A
Pid:WAITING: Fn:PRESENCE_DoLocalPingScan Arg:p_Raumfeld_Bad|192.168.0.121|0|4 Timeout:60 ConnectedVia:N/A
Pid:WAITING: Fn:PRESENCE_DoLocalPingScan Arg:p_SNSG|192.168.0.3|0|4 Timeout:60 ConnectedVia:N/A
Pid:WAITING: Fn:PRESENCE_DoLocalPingScan Arg:SGS5_Nadine|192.168.0.115|0|4 Timeout:60 ConnectedVia:N/A
Pid:WAITING: Fn:PRESENCE_DoLocalPingScan Arg:PCStephan|stephan-SSD|0|4 Timeout:60 ConnectedVia:N/A
Pid:WAITING: Fn:PRESENCE_DoLocalPingScan Arg:SGS4_Stephan|192.168.0.101|0|4 Timeout:60 ConnectedVia:N/A
Pid:WAITING: Fn:DbLog_PushAsync Arg:logdb|MjAxNy0xMi0yOCAwMTowMzozNXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzNy42MnxsL21pbsKnMjAxNy0xMi0yOCAwMTowMzozNXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE5LjIxfFdowqcyMDE3LTEyLTI4IDAxOjAzOjM1fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDQzMzYwfFfCpzIwMTctMTItMjggMDE6MDM6Mzd8UkVfVEVNUF9QUzMwMDBfMDN8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjY5fMKnMjAxNy0xMi0yOCAwMTowMzozN3xLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHx0b3RhbHw3NTguNDkyfG3CpzIwMTctMTItMjggMDE6MDM6Mzd8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzcuNjJ8bC9taW7CpzIwMTctMTItMjggMDE6MDM6Mzd8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxOS4yMXxXaMKnMjAxNy0xMi0yOCAwMTowMzozN3xLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnw0MzM2MHxXwqcyMDE3LTEyLTI4IDAxOjAzOjM3fFJFX1RFTVBfUFMzMDAwXzA3fERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi43NXzCpzIwMTctMTItMjggMDE6MDM6Mzh8UkVfVEVNUF9QUzMwMDBfMDJ8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjgxfMKnMjAxNy0xMi0yOCAwMTowMzozOHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsaXRlcnByb21pbnwxOS4zM3xsL21pbsKnMjAxNy0xMi0yOCAwMTowMzozOHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsYXN0bGl0ZXJ3b3JrfDMuMjZ8V2jCpzIwMTctMTItMjggMDE6MDM6Mzh8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8cG93ZXJ8Mzc4MHxXwqcyMDE3LTEyLTI4IDAxOjAzOjM4fFJFX1RFTVBfUFMzMDAwXzEwfERVTU1ZfHx0ZW1wZXJhdHVyZXwzOC44OHzCpzIwMTctMTItMjggMDE6MDM6Mzl8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzcuNjJ8bC9taW7CpzIwMTctMTItMjggMDE6MDM6Mzl8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxOS4yMXxXaMKnMjAxNy0xMi0yOCAwMTowMzozOXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnw0MzM2MHxXwqcyMDE3LTEyLTI4IDAxOjAzOjM5fFJFX1RFTVBfUFMzMDAwXzA1fERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi41MHzCpzIwMTctMTItMjggMDE6MDM6Mzl8UkVfVEVNUF9QUzMwMDBfMDZ8RFVNTVl8fHRlbXBlcmF0dXJlfDI2Ljc1fMKnMjAxNy0xMi0yOCAwMTowMzo0MHxSRV9URU1QX1BTMzAwMF8xMXxEVU1NWXx8dGVtcGVyYXR1cmV8ODIuNTZ8wqcyMDE3LTEyLTI4IDAxOjAzOjQwfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM3LjYyfGwvbWluwqcyMDE3LTEyLTI4IDAxOjAzOjQwfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTkuMjF8V2jCpzIwMTctMTItMjggMDE6MDM6NDB8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8NDMzNjB8V8KnMjAxNy0xMi0yOCAwMTowMzo0MHxSRV9URU1QX0hWX1JMQTJ8RFVNTVl8fHRlbXBlcmF0dXJlfDY2LjgxMnzCpzIwMTctMTItMjggMDE6MDM6NDB8UkVfVEVNUF9QUzMwMDBfMDR8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjY5fMKnMjAxNy0xMi0yOCAwMTowMzo0MXxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsaXRlcnByb21pbnwxOS4zMHxsL21pbsKnMjAxNy0xMi0yOCAwMTowMzo0MXxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsYXN0bGl0ZXJ3b3JrfDMuMjZ8V2jCpzIwMTctMTItMjggMDE6MDM6NDF8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8cG93ZXJ8Mzc3NXxXwqcyMDE3LTEyLTI4IDAxOjAzOjQxfFJFX1RFTVBfUFMzMDAwXzAxfERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi42OXzCpzIwMTctMTItMjggMDE6MDM6NDJ8UkVfVEVNUF9QUzMwMDBfMDl8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjYyfMKnMjAxNy0xMi0yOCAwMTowMzo0MnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHx0b3RhbHw3NTguNDk1fG3CpzIwMTctMTItMjggMDE6MDM6NDJ8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzcuNzV8bC9taW7CpzIwMTctMTItMjggMDE6MDM6NDJ8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxOS4yMXxXaMKnMjAxNy0xMi0yOCAwMTowMzo0MnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnw0MzUxMHxXwqcyMDE3LTEyLTI4IDAxOjAzOjQyfFJFX1RFTVBfUFMzMDAwXzA4fERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi42MnzCpzIwMTctMTItMjggMDE6MDM6NDN8UkVfVEVNUF9TcGVpY2hlcl8wMnxEVU1NWXx8dGVtcGVyYXR1cmV8MjcuMDB8wqcyMDE3LTEyLTI4IDAxOjAzOjQzfFJFX1RFTVBfU3BlaWNoZXJfMDh8RFVNTVl8fHRlbXBlcmF0dXJlfDc5LjEyfMKnMjAxNy0xMi0yOCAwMTowMzo0M3xLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzNy43NXxsL21pbsKnMjAxNy0xMi0yOCAwMTowMzo0M3xLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE5LjIxfFdowqcyMDE3LTEyLTI4IDAxOjAzOjQzfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDQzNTEwfFfCpzIwMTctMTItMjggMDE6MDM6NDR8UkVfVEVNUF9TcGVpY2hlcl8xMHxEVU1NWXx8dGVtcGVyYXR1cmV8NzcuMTJ8wqcyMDE3LTEyLTI4IDAxOjAzOjQ0fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxpdGVycHJvbWlufDE5LjM1fGwvbWluwqcyMDE3LTEyLTI4IDAxOjAzOjQ0fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxhc3RsaXRlcndvcmt8My4yNnxXaMKnMjAxNy0xMi0yOCAwMTowMzo0NHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxwb3dlcnwzNzg0fFfCpzIwMTctMTItMjggMDE6MDM6NDR8UkVfVEVNUF9TcGVpY2hlcl8wNHxEVU1NWXx8dGVtcGVyYXR1cmV8MjguMDZ8wqcyMDE3LTEyLTI4IDAxOjAzOjQ1fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM3Ljc1fGwvbWluwqcyMDE3LTEyLTI4IDAxOjAzOjQ1fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTkuMjF8V2jCpzIwMTctMTItMjggMDE6MDM6NDV8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8NDM1MTB8V8KnMjAxNy0xMi0yOCAwMTowMzo0NXxSRV9URU1QX1NwZWljaGVyXzAzfERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi45NHzCpzIwMTctMTItMjggMDE6MDM6NDV8UkVfVEVNUF9TcGVpY2hlcl8wMXxEVU1NWXx8dGVtcGVyYXR1cmV8MjYuNzV8wqcyMDE3LTEyLTI4IDAxOjAzOjQ2fFJFX1RFTVBfU3BlaWNoZXJfMDd8RFVNTVl8fHRlbXBlcmF0dXJlfDcyLjEyfMKnMjAxNy0xMi0yOCAwMTowMzo0NnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHx0b3RhbHw3NTguNDk4fG3CpzIwMTctMTItMjggMDE6MDM6NDZ8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzcuOTB8bC9taW7CpzIwMTctMTItMjggMDE6MDM6NDZ8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxOS4yMXxXaMKnMjAxNy0xMi0yOCAwMTowMzo0NnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnw0MzY4M3xXwqcyMDE3LTEyLTI4IDAxOjAzOjQ3fFJFX1RFTVBfU3BlaWNoZXJfMDl8RFVNTVl8fHRlbXBlcmF0dXJlfDgwLjE5fMKnMjAxNy0xMi0yOCAwMTowMzo0N3xTdHJvbXphZWhsZXJ8Vlp8fHRvdGFsX3Bvd2VyfDgzN3zCpzIwMTctMTItMjggMDE6MDM6NDd8U3Ryb216YWVobGVyfFZafHx0b3RhbF9wb3dlcl9MMXw0MjJ8wqcyMDE3LTEyLTI4IDAxOjAzOjQ3fFJFX1RFTVBfU3BlaWNoZXJfMDZ8RFVNTVl8fHRlbXBlcmF0dXJlfDY0LjAwfMKnMjAxNy0xMi0yOCAwMTowMzo0N3xLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsaXRlcnByb21pbnwxOS4zN3xsL21pbsKnMjAxNy0xMi0yOCAwMTowMzo0N3xLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsYXN0bGl0ZXJ3b3JrfDMuMjZ8V2jCpzIwMTctMTItMjggMDE6MDM6NDd8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8cG93ZXJ8Mzc4OHxXwqcyMDE3LTEyLTI4IDAxOjAzOjQ4fFJFX1RFTVBfU3BlaWNoZXJfMDV8RFVNTVl8fHRlbXBlcmF0dXJlfDQ5LjE5fMKnMjAxNy0xMi0yOCAwMTowMzo0OHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzNy45MHxsL21pbsKnMjAxNy0xMi0yOCAwMTowMzo0OHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE5LjIxfFdowqcyMDE3LTEyLTI4IDAxOjAzOjQ4fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDQzNjgzfFfCpzIwMTctMTItMjggMDE6MDM6NDh8UkVfVEVNUF9Wb3JsYXVmX1NjaHdpbW1iYWR8RFVNTVl8fHRlbXBlcmF0dXJlfDIyLjYyfMKnMjAxNy0xMi0yOCAwMTowMzo0OHxTdHJvbXphZWhsZXJ8Vlp8fHRvdGFsX3Bvd2VyfDgwOHzCpzIwMTctMTItMjggMDE6MDM6NDh8U3Ryb216YWVobGVyfFZafHx0b3RhbF9wb3dlcl9MMXwzOTR8wqcyMDE3LTEyLTI4IDAxOjAzOjQ5fFJFX1RFTVBfUnVlY2tsYXVmX1NvbGFyfERVTU1ZfHx0ZW1wZXJhdHVyZXwyMi4xOXzCpzIwMTctMTItMjggMDE6MDM6NDl8UkVfVEVNUF9Wb3JsYXVmX0VHX0JvZGVufERVTU1ZfHx0ZW1wZXJhdHVyZXwyOS4wNnzCpzIwMTctMTItMjggMDE6MDM6NTB8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzcuOTB8bC9taW7CpzIwMTctMTItMjggMDE6MDM6NTB8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxOS4yMXxXaMKnMjAxNy0xMi0yOCAwMTowMzo1MHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnw0MzY4M3xXwqcyMDE3LTEyLTI4IDAxOjAzOjUwfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxpdGVycHJvbWlufDE5LjM3fGwvbWluwqcyMDE3LTEyLTI4IDAxOjAzOjUwfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxhc3RsaXRlcndvcmt8My4yNnxXaMKnMjAxNy0xMi0yOCAwMTowMzo1MHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxwb3dlcnwzNzg4fFfCpzIwMTctMTItMjggMDE6MDM6NTB8UkVfVEVNUF9SdWVja2xhdWZfRUdfQm9kZW58RFVNTVl8fHRlbXBlcmF0dXJlfDI1LjQ0fMKnMjAxNy0xMi0yOCAwMTowMzo1MXxSRV9URU1QX1J1ZWNrbGF1Zl9XVF9FR3xEVU1NWXx8dGVtcGVyYXR1cmV8MjYuNjl8wqcyMDE3LTEyLTI4IDAxOjAzOjUxfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHRvdGFsfDc1OC41MDF8bcKnMjAxNy0xMi0yOCAwMTowMzo1MXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzNy45NHxsL21pbsKnMjAxNy0xMi0yOCAwMTowMzo1MXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE5LjIxfFdowqcyMDE3LTEyLTI4IDAxOjAzOjUxfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDQzNzI5fFfCpzIwMTctMTItMjggMDE6MDM6NTF8UkVfVEVNUF9IVl9STEEyfERVTU1ZfHx0ZW1wZXJhdHVyZXw2Ni44MTJ8wqcyMDE3LTEyLTI4IDAxOjAzOjUxfFJFX1RFTVBfVm9ybGF1Zl9Tb2xhcnxEVU1NWXx8dGVtcGVyYXR1cmV8MjIuMTl8wqcyMDE3LTEyLTI4IDAxOjAzOjUyfFJFX1RFTVBfUnVlY2tsYXVmSEt8RFVNTVl8fHRlbXBlcmF0dXJlfDI3LjMxfMKnMjAxNy0xMi0yOCAwMTowMzo1M3xSRV9URU1QX1ZvcmxhdWZIS3xEVU1NWXx8dGVtcGVyYXR1cmV8MzAuMzF8wqcyMDE3LTEyLTI4IDAxOjAzOjUzfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM3Ljk0fGwvbWluwqcyMDE3LTEyLTI4IDAxOjAzOjUzfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTkuMjF8V2jCpzIwMTctMTItMjggMDE6MDM6NTN8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8NDM3Mjl8V8KnMjAxNy0xMi0yOCAwMTowMzo1M3xSRV9URU1QX1NjaGxhZnppbW1lcnxEVU1NWXx8dGVtcGVyYXR1cmV8MjIuNjl8wqcyMDE3LTEyLTI4IDAxOjAzOjUzfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxpdGVycHJvbWlufDE5LjM2fGwvbWluwqcyMDE3LTEyLTI4IDAxOjAzOjUzfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxhc3RsaXRlcndvcmt8My40OHxXaMKnMjAxNy0xMi0yOCAwMTowMzo1M3xLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxwb3dlcnw0MDQyfFfCpzIwMTctMTItMjggMDE6MDM6NTR8UkVfVEVNUF9BbmtsZWlkZXxEVU1NWXx8dGVtcGVyYXR1cmV8MjMuNzV8wqcyMDE3LTEyLTI4IDAxOjAzOjU0fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM3Ljk0fGwvbWluwqcyMDE3LTEyLTI4IDAxOjAzOjU0fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTkuMjF8V2jCpzIwMTctMTItMjggMDE6MDM6NTR8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8NDM3Mjl8V8KnMjAxNy0xMi0yOCAwMTowMzo1NHxSRV9URU1QX0ZsdXJPR3xEVU1NWXx8dGVtcGVyYXR1cmV8MjQuMjV8wqcyMDE3LTEyLTI4IDAxOjAzOjU1fFJFX1RFTVBfVm9ybGF1Zl9LZXNzZWx8RFVNTVl8fHRlbXBlcmF0dXJlfDIyLjAwfMKnMjAxNy0xMi0yOCAwMTowMzo1NXxSRV9URU1QX0FVU1NFTnxEVU1NWXx8dGVtcGVyYXR1cmV8Ni4yNXzCpzIwMTctMTItMjggMDE6MDM6NTZ8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8dG90YWx8NzU4LjUwNHxtwqcyMDE3LTEyLTI4IDAxOjAzOjU2fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM3LjkzfGwvbWluwqcyMDE3LTEyLTI4IDAxOjAzOjU2fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTkuMjF8V2jCpzIwMTctMTItMjggMDE6MDM6NTZ8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8NDM3MTd8V8KnMjAxNy0xMi0yOCAwMTowMzo1NnxSRV9URU1QX1ZvcmxhdWZfV1d8RFVNTVl8fHRlbXBlcmF0dXJlfDQ4Ljk0fMKnMjAxNy0xMi0yOCAwMTowMzo1NnxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsaXRlcnByb21pbnwxOS4zNXxsL21pbsKnMjAxNy0xMi0yOCAwMTowMzo1NnxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsYXN0bGl0ZXJ3b3JrfDMuNDh8V2jCpzIwMTctMTItMjggMDE6MDM6NTZ8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8cG93ZXJ8NDA0MHxXwqcyMDE3LTEyLTI4IDAxOjAzOjU3fFJFX1RFTVBfV1dfQXVzZ2FuZ19TcGVpY2hlcnxEVU1NWXx8dGVtcGVyYXR1cmV8NjUuNDR8wqcyMDE3LTEyLTI4IDAxOjAzOjU3fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM3LjkzfGwvbWluwqcyMDE3LTEyLTI4IDAxOjAzOjU3fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTkuMjF8V2jCpzIwMTctMTItMjggMDE6MDM6NTd8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8NDM3MTd8V8KnMjAxNy0xMi0yOCAwMTowMzo1OHxSRV9URU1QX1J1ZWNrbGF1Zl9LZXNzZWx8RFVNTVl8fHRlbXBlcmF0dXJlfDIyLjA2fMKnMjAxNy0xMi0yOCAwMTowMzo1OHxSRV9URU1QX1J1ZWNrbGF1Zl9aaXJrdWxhdGlvbnxEVU1NWXx8dGVtcGVyYXR1cmV8MjQuMDB8wqcyMDE3LTEyLTI4IDAxOjAzOjU5fFJFX1RFTVBfSFZfUkxBfERVTU1ZfHx0ZW1wZXJhdHVyZXw2Ni44MXzCpzIwMTctMTItMjggMDE6MDM6NTl8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzcuOTN8bC9taW7CpzIwMTctMTItMjggMDE6MDM6NTl8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxOS4yMXxXaMKnMjAxNy0xMi0yOCAwMTowMzo1OXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnw0MzcxN3xXwqcyMDE3LTEyLTI4IDAxOjAzOjU5fFJFX1RFTVBfSFZfUkx8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjA2fMKnMjAxNy0xMi0yOCAwMTowNDowMHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsaXRlcnByb21pbnwxOS4zNXxsL21pbsKnMjAxNy0xMi0yOCAwMTowNDowMHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsYXN0bGl0ZXJ3b3JrfDMuNDh8V2jCpzIwMTctMTItMjggMDE6MDQ6MDB8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8cG93ZXJ8NDA0MHxXwqcyMDE3LTEyLTI4IDAxOjA0OjAwfFJFX1RFTVBfSFZfVkx8RFVNTVl8fHRlbXBlcmF0dXJlfDgzLjMxfMKnMjAxNy0xMi0yOCAwMTowNDowMXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHx0b3RhbHw3NTguNTA3fG3CpzIwMTctMTItMjggMDE6MDQ6MDF8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzcuOTB8bC9taW7CpzIwMTctMTItMjggMDE6MDQ6MDF8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxOS4xNHxXaMKnMjAxNy0xMi0yOCAwMTowNDowMXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnw0MzUyNHxXwqcyMDE3LTEyLTI4IDAxOjA0OjAyfFJFX1RFTVBfSFZfUkxBMnxEVU1NWXx8dGVtcGVyYXR1cmV8NjYuODEyfMKnMjAxNy0xMi0yOCAwMTowNDowMnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzNy45MHxsL21pbsKnMjAxNy0xMi0yOCAwMTowNDowMnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE5LjE0fFdowqcyMDE3LTEyLTI4IDAxOjA0OjAyfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDQzNTI0fFfCpzIwMTctMTItMjggMDE6MDQ6MDN8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGl0ZXJwcm9taW58MTkuMzV8bC9taW7CpzIwMTctMTItMjggMDE6MDQ6MDN8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGFzdGxpdGVyd29ya3wzLjQ4fFdowqcyMDE3LTEyLTI4IDAxOjA0OjAzfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fHBvd2VyfDQwNDB8V8KnMjAxNy0xMi0yOCAwMTowNDowNHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzNy45MHxsL21pbsKnMjAxNy0xMi0yOCAwMTowNDowNHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE5LjE0fFdowqcyMDE3LTEyLTI4IDAxOjA0OjA0fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDQzNTI0fFfCpzIwMTctMTItMjggMDE6MDQ6MDV8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8dG90YWx8NzU4LjUxMHxtwqcyMDE3LTEyLTI4IDAxOjA0OjA1fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM3LjgwfGwvbWluwqcyMDE3LTEyLTI4IDAxOjA0OjA1fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTkuMTR8V2jCpzIwMTctMTItMjggMDE6MDQ6MDV8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8NDM0MTB8V8KnMjAxNy0xMi0yOCAwMTowNDowNnxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsaXRlcnByb21pbnwxOS40MHxsL21pbsKnMjAxNy0xMi0yOCAwMTowNDowNnxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsYXN0bGl0ZXJ3b3JrfDMuNDh8V2jCpzIwMTctMTItMjggMDE6MDQ6MDZ8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8cG93ZXJ8NDA1MXxXwqcyMDE3LTEyLTI4IDAxOjA0OjA3fFJFX1RFTVBfUFMzMDAwXzAzfERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi42OXzCpzIwMTctMTItMjggMDE6MDQ6MDd8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzcuODB8bC9taW7CpzIwMTctMTItMjggMDE6MDQ6MDd8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxOS4xNHxXaMKnMjAxNy0xMi0yOCAwMTowNDowN3xLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnw0MzQxMHxXwqcyMDE3LTEyLTI4IDAxOjA0OjA3fFJFX1RFTVBfUFMzMDAwXzA3fERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi43NXzCpzIwMTctMTItMjggMDE6MDQ6MDh8UkVfVEVNUF9QUzMwMDBfMDJ8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjgxfMKnMjAxNy0xMi0yOCAwMTowNDowOHxSRV9URU1QX1BTMzAwMF8xMHxEVU1NWXx8dGVtcGVyYXR1cmV8MzkuMDZ8wqcyMDE3LTEyLTI4IDAxOjA0OjA4fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM3LjgwfGwvbWluwqcyMDE3LTEyLTI4IDAxOjA0OjA4fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTkuMTR8V2jCpzIwMTctMTItMjggMDE6MDQ6MDh8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8NDM0MTB8V8KnMjAxNy0xMi0yOCAwMTowNDowOXxSRV9URU1QX1BTMzAwMF8wNXxEVU1NWXx8dGVtcGVyYXR1cmV8MjYuNTB8wqcyMDE3LTEyLTI4IDAxOjA0OjA5fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxpdGVycHJvbWlufDE5LjQwfGwvbWluwqcyMDE3LTEyLTI4IDAxOjA0OjA5fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxhc3RsaXRlcndvcmt8My40OHxXaMKnMjAxNy0xMi0yOCAwMTowNDowOXxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxwb3dlcnw0MDUxfFfCpzIwMTctMTItMjggMDE6MDQ6MDl8UkVfVEVNUF9QUzMwMDBfMDZ8RFVNTVl8fHRlbXBlcmF0dXJlfDI2Ljc1fMKnMjAxNy0xMi0yOCAwMTowNDoxMHxSRV9URU1QX1BTMzAwMF8xMXxEVU1NWXx8dGVtcGVyYXR1cmV8ODIuNjJ8wqcyMDE3LTEyLTI4IDAxOjA0OjEwfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHRvdGFsfDc1OC41MTN8bcKnMjAxNy0xMi0yOCAwMTowNDoxMHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzNy44NHxsL21pbsKnMjAxNy0xMi0yOCAwMTowNDoxMHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE5LjE0fFdowqcyMDE3LTEyLTI4IDAxOjA0OjEwfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDQzNDU1fFfCpzIwMTctMTItMjggMDE6MDQ6MTB8UkVfVEVNUF9QUzMwMDBfMDR8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjY5fMKnMjAxNy0xMi0yOCAwMTowNDoxMXxSRV9URU1QX1BTMzAwMF8wMXxEVU1NWXx8dGVtcGVyYXR1cmV8MjYuNzV8wqcyMDE3LTEyLTI4IDAxOjA0OjEyfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM3Ljg0fGwvbWluwqcyMDE3LTEyLTI4IDAxOjA0OjEyfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTkuMTR8V2jCpzIwMTctMTItMjggMDE6MDQ6MTJ8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8NDM0NTV8V8KnMjAxNy0xMi0yOCAwMTowNDoxMnxSRV9URU1QX1BTMzAwMF8wOXxEVU1NWXx8dGVtcGVyYXR1cmV8MjYuNjJ8wqcyMDE3LTEyLTI4IDAxOjA0OjEyfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxpdGVycHJvbWlufDE5LjM1fGwvbWluwqcyMDE3LTEyLTI4IDAxOjA0OjEyfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxhc3RsaXRlcndvcmt8My40OHxXaMKnMjAxNy0xMi0yOCAwMTowNDoxMnxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxwb3dlcnw0MDQwfFfCpzIwMTctMTItMjggMDE6MDQ6MTJ8UkVfVEVNUF9QUzMwMDBfMDh8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjYyfMKnMjAxNy0xMi0yOCAwMTowNDoxM3xSRV9URU1QX0hWX1JMQTJ8RFVNTVl8fHRlbXBlcmF0dXJlfDY2LjgxMnzCpzIwMTctMTItMjggMDE6MDQ6MTN8UkVfVEVNUF9TcGVpY2hlcl8wMnxEVU1NWXx8dGVtcGVyYXR1cmV8MjcuMDB8wqcyMDE3LTEyLTI4IDAxOjA0OjEzfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM3Ljg0fGwvbWluwqcyMDE3LTEyLTI4IDAxOjA0OjEzfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTkuMTR8V2jCpzIwMTctMTItMjggMDE6MDQ6MTN8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8NDM0NTV8V8KnMjAxNy0xMi0yOCAwMTowNDoxNHxSRV9URU1QX1NwZWljaGVyXzA4fERVTU1ZfHx0ZW1wZXJhdHVyZXw3OS4xOXzCpzIwMTctMTItMjggMDE6MDQ6MTR8UkVfVEVNUF9TcGVpY2hlcl8xMHxEVU1NWXx8dGVtcGVyYXR1cmV8NzcuMTl8wqcyMDE3LTEyLTI4IDAxOjA0OjE1fFJFX1RFTVBfU3BlaWNoZXJfMDR8RFVNTVl8fHRlbXBlcmF0dXJlfDI4LjQ0fMKnMjAxNy0xMi0yOCAwMTowNDoxNXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHx0b3RhbHw3NTguNTE2fG3CpzIwMTctMTItMjggMDE6MDQ6MTV8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzcuODF8bC9taW7CpzIwMTctMTItMjggMDE6MDQ6MTV8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxOS4xNHxXaMKnMjAxNy0xMi0yOCAwMTowNDoxNXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnw0MzQyMXxXwqcyMDE3LTEyLTI4IDAxOjA0OjE1fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxpdGVycHJvbWlufDE5LjM0fGwvbWluwqcyMDE3LTEyLTI4IDAxOjA0OjE1fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxhc3RsaXRlcndvcmt8My40OHxXaMKnMjAxNy0xMi0yOCAwMTowNDoxNXxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxwb3dlcnw0MDM4fFfCpzIwMTctMTItMjggMDE6MDQ6MTV8UkVfVEVNUF9TcGVpY2hlcl8wM3xEVU1NWXx8dGVtcGVyYXR1cmV8MjcuMDB8wqcyMDE3LTEyLTI4IDAxOjA0OjE2fFJFX1RFTVBfU3BlaWNoZXJfMDF8RFVNTVl8fHRlbXBlcmF0dXJlfDI2Ljc1fMKnMjAxNy0xMi0yOCAwMTowNDoxNnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzNy44MXxsL21pbsKnMjAxNy0xMi0yOCAwMTowNDoxNnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE5LjE0fFdowqcyMDE3LTEyLTI4IDAxOjA0OjE2fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDQzNDIxfFfCpzIwMTctMTItMjggMDE6MDQ6MTZ8UkVfVEVNUF9TcGVpY2hlcl8wN3xEVU1NWXx8dGVtcGVyYXR1cmV8NzIuMjV8wqcyMDE3LTEyLTI4IDAxOjA0OjE2fFN0cm9temFlaGxlcnxWWnx8dG90YWxfZW5lcmd5fDExNDQ0LjQ5Nzl8wqcyMDE3LTEyLTI4IDAxOjA0OjE3fFJFX1RFTVBfU3BlaWNoZXJfMDl8RFVNTVl8fHRlbXBlcmF0dXJlfDgwLjI1fMKnMjAxNy0xMi0yOCAwMTowNDoxN3xSRV9URU1QX1NwZWljaGVyXzA2fERVTU1ZfHx0ZW1wZXJhdHVyZXw2NC4yNXzCpzIwMTctMTItMjggMDE6MDQ6MTh8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzcuODF8bC9taW7CpzIwMTctMTItMjggMDE6MDQ6MTh8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxOS4xNHxXaMKnMjAxNy0xMi0yOCAwMTowNDoxOHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnw0MzQyMXxXwqcyMDE3LTEyLTI4IDAxOjA0OjE4fFJFX1RFTVBfU3BlaWNoZXJfMDV8RFVNTVl8fHRlbXBlcmF0dXJlfDQ5LjgxfMKnMjAxNy0xMi0yOCAwMTowNDoxOHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsaXRlcnByb21pbnwxOS4zNHxsL21pbsKnMjAxNy0xMi0yOCAwMTowNDoxOHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsYXN0bGl0ZXJ3b3JrfDMuNDh8V2jCpzIwMTctMTItMjggMDE6MDQ6MTh8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8cG93ZXJ8NDAzOHxXwqcyMDE3LTEyLTI4IDAxOjA0OjE4fFJFX1RFTVBfVm9ybGF1Zl9TY2h3aW1tYmFkfERVTU1ZfHx0ZW1wZXJhdHVyZXwyMi42MnzCpzIwMTctMTItMjggMDE6MDQ6MTl8U3Ryb216YWVobGVyfFZafHx0b3RhbF9wb3dlcl9MM3wzNzR8wqcyMDE3LTEyLTI4IDAxOjA0OjE5fFJFX1RFTVBfUnVlY2tsYXVmX1NvbGFyfERVTU1ZfHx0ZW1wZXJhdHVyZXwyMi4xMnzCpzIwMTctMTItMjggMDE6MDQ6MjB8UkVfVEVNUF9Wb3JsYXVmX0VHX0JvZGVufERVTU1ZfHx0ZW1wZXJhdHVyZXwyOS4yNXzCpzIwMTctMTItMjggMDE6MDQ6MjB8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8dG90YWx8NzU4LjUxOXxtwqcyMDE3LTEyLTI4IDAxOjA0OjIwfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM3LjczfGwvbWluwqcyMDE3LTEyLTI4IDAxOjA0OjIwfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTkuMTR8V2jCpzIwMTctMTItMjggMDE6MDQ6MjB8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8NDMzMjl8V8KnMjAxNy0xMi0yOCAwMTowNDoyMHxTdHJvbXphZWhsZXJ8Vlp8fHRvdGFsX3Bvd2VyfDgzMHzCpzIwMTctMTItMjggMDE6MDQ6MjB8U3Ryb216YWVobGVyfFZafHx0b3RhbF9wb3dlcl9MM3w0MDF8wqcyMDE3LTEyLTI4IDAxOjA0OjIxfFJFX1RFTVBfUnVlY2tsYXVmX0VHX0JvZGVufERVTU1ZfHx0ZW1wZXJhdHVyZXwyNS40NHzCpzIwMTctMTItMjggMDE6MDQ6MjF8UkVfVEVNUF9SdWVja2xhdWZfV1RfRUd8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjY5fMKnMjAxNy0xMi0yOCAwMTowNDoyMXxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsaXRlcnByb21pbnwxOS4zNXxsL21pbsKnMjAxNy0xMi0yOCAwMTowNDoyMXxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsYXN0bGl0ZXJ3b3JrfDMuNDh8V2jCpzIwMTctMTItMjggMDE6MDQ6MjF8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8cG93ZXJ8NDA0MHxXwqcyMDE3LTEyLTI4IDAxOjA0OjIxfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM3LjczfGwvbWluwqcyMDE3LTEyLTI4IDAxOjA0OjIxfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTkuMTR8V2jCpzIwMTctMTItMjggMDE6MDQ6MjF8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8NDMzMjl8V8KnMjAxNy0xMi0yOCAwMTowNDoyMnxSRV9URU1QX1ZvcmxhdWZfU29sYXJ8RFVNTVl8fHRlbXBlcmF0dXJlfDIyLjE5fMKnMjAxNy0xMi0yOCAwMTowNDoyMnxSRV9URU1QX1J1ZWNrbGF1ZkhLfERVTU1ZfHx0ZW1wZXJhdHVyZXwyNy4zMXzCpzIwMTctMTItMjggMDE6MDQ6MjN8UkVfVEVNUF9Wb3JsYXVmSEt8RFVNTVl8fHRlbXBlcmF0dXJlfDMwLjM3fMKnMjAxNy0xMi0yOCAwMTowNDoyM3xLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHx0b3RhbHw3NTguNTIxfG3CpzIwMTctMTItMjggMDE6MDQ6MjN8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzcuODJ8bC9taW7CpzIwMTctMTItMjggMDE6MDQ6MjN8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxOS4xNHxXaMKnMjAxNy0xMi0yOCAwMTowNDoyM3xLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnw0MzQzMnxXwqcyMDE3LTEyLTI4IDAxOjA0OjIzfFJFX1RFTVBfU2NobGFmemltbWVyfERVTU1ZfHx0ZW1wZXJhdHVyZXwyMi42OXzCpzIwMTctMTItMjggMDE6MDQ6MjR8UkVfVEVNUF9IVl9STEEyfERVTU1ZfHx0ZW1wZXJhdHVyZXw2Ni44MTJ8wqcyMDE3LTEyLTI4IDAxOjA0OjI0fFJFX1RFTVBfQW5rbGVpZGV8RFVNTVl8fHRlbXBlcmF0dXJlfDIzLjc1fMKnMjAxNy0xMi0yOCAwMTowNDoyNHxTdHJvbXphZWhsZXJ8Vlp8fHRvdGFsX3Bvd2VyfDgwOHzCpzIwMTctMTItMjggMDE6MDQ6MjR8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGl0ZXJwcm9taW58MTkuMzV8bC9taW7CpzIwMTctMTItMjggMDE6MDQ6MjR8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGFzdGxpdGVyd29ya3wzLjU1fFdowqcyMDE3LTEyLTI4IDAxOjA0OjI0fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fHBvd2VyfDQxMjF8V8KnMjAxNy0xMi0yOCAwMTowNDoyNXxSRV9URU1QX0ZsdXJPR3xEVU1NWXx8dGVtcGVyYXR1cmV8MjQuNTB8wqcyMDE3LTEyLTI4IDAxOjA0OjI1fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM3LjgyfGwvbWluwqcyMDE3LTEyLTI4IDAxOjA0OjI1fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTkuMTR8V2jCpzIwMTctMTItMjggMDE6MDQ6MjV8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8NDM0MzJ8V8KnMjAxNy0xMi0yOCAwMTowNDoyNXxSRV9URU1QX1ZvcmxhdWZfS2Vzc2VsfERVTU1ZfHx0ZW1wZXJhdHVyZXwyMi4wNnzCpzIwMTctMTItMjggMDE6MDQ6MjZ8UkVfVEVNUF9BVVNTRU58RFVNTVl8fHRlbXBlcmF0dXJlfDYuMjV8wqcyMDE3LTEyLTI4IDAxOjA0OjI2fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM3LjgyfGwvbWluwqcyMDE3LTEyLTI4IDAxOjA0OjI2fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTkuMTR8V2jCpzIwMTctMTItMjggMDE6MDQ6MjZ8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8NDM0MzJ8V8KnMjAxNy0xMi0yOCAwMTowNDoyNnxSRV9URU1QX1ZvcmxhdWZfV1d8RFVNTVl8fHRlbXBlcmF0dXJlfDQ4Ljk0fMKnMjAxNy0xMi0yOCAwMTowNDoyN3xSRV9URU1QX1dXX0F1c2dhbmdfU3BlaWNoZXJ8RFVNTVl8fHRlbXBlcmF0dXJlfDY1LjM3fMKnMjAxNy0xMi0yOCAwMTowNDoyN3xSRV9URU1QX1J1ZWNrbGF1Zl9LZXNzZWx8RFVNTVl8fHRlbXBlcmF0dXJlfDIyLjA2fMKnMjAxNy0xMi0yOCAwMTowNDoyN3xLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsaXRlcnByb21pbnwxOS4zNnxsL21pbsKnMjAxNy0xMi0yOCAwMTowNDoyN3xLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsYXN0bGl0ZXJ3b3JrfDMuNTV8V2jCpzIwMTctMTItMjggMDE6MDQ6Mjd8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8cG93ZXJ8NDEyM3xXwqcyMDE3LTEyLTI4IDAxOjA0OjI4fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHRvdGFsfDc1OC41MjR8bcKnMjAxNy0xMi0yOCAwMTowNDoyOHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzNy43NHxsL21pbsKnMjAxNy0xMi0yOCAwMTowNDoyOHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE5LjE0fFdowqcyMDE3LTEyLTI4IDAxOjA0OjI4fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDQzMzQxfFfCpzIwMTctMTItMjggMDE6MDQ6Mjh8UkVfVEVNUF9SdWVja2xhdWZfWmlya3VsYXRpb258RFVNTVl8fHRlbXBlcmF0dXJlfDI0LjAwfMKnMjAxNy0xMi0yOCAwMTowNDoyOHxSRV9URU1QX0hWX1JMQXxEVU1NWXx8dGVtcGVyYXR1cmV8NjYuODF8wqcyMDE3LTEyLTI4IDAxOjA0OjI5fFJFX1RFTVBfSFZfUkx8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjA2fMKnMjAxNy0xMi0yOCAwMTowNDoyOXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzNy43NHxsL21pbsKnMjAxNy0xMi0yOCAwMTowNDoyOXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE5LjE0fFdowqcyMDE3LTEyLTI4IDAxOjA0OjI5fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDQzMzQxfFfCpzIwMTctMTItMjggMDE6MDQ6Mjl8UkVfVEVNUF9IVl9WTHxEVU1NWXx8dGVtcGVyYXR1cmV8ODMuMjV8wqcyMDE3LTEyLTI4IDAxOjA0OjMwfFJFX1RFTVBfUFMzMDAwXzAzfERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi42OXzCpzIwMTctMTItMjggMDE6MDQ6MzF8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGl0ZXJwcm9taW58MTkuMzZ8bC9taW7CpzIwMTctMTItMjggMDE6MDQ6MzF8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGFzdGxpdGVyd29ya3wzLjU1fFdowqcyMDE3LTEyLTI4IDAxOjA0OjMxfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fHBvd2VyfDQxMjN8V8KnMjAxNy0xMi0yOCAwMTowNDozMXxSRV9URU1QX1BTMzAwMF8wN3xEVU1NWXx8dGVtcGVyYXR1cmV8MjYuNzV8wqcyMDE3LTEyLTI4IDAxOjA0OjMxfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM3Ljc0fGwvbWluwqcyMDE3LTEyLTI4IDAxOjA0OjMxfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTkuMDd8V2jCpzIwMTctMTItMjggMDE6MDQ6MzF8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8NDMxODN8V8KnMjAxNy0xMi0yOCAwMTowNDozMXxSRV9URU1QX1BTMzAwMF8wMnxEVU1NWXx8dGVtcGVyYXR1cmV8MjYuODF8wqcyMDE3LTEyLTI4IDAxOjA0OjMyfFJFX1RFTVBfUFMzMDAwXzEwfERVTU1ZfHx0ZW1wZXJhdHVyZXwzOS4xM3zCpzIwMTctMTItMjggMDE6MDQ6MzJ8UkVfVEVNUF9QUzMwMDBfMDV8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjUwfMKnMjAxNy0xMi0yOCAwMTowNDozMnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHx0b3RhbHw3NTguNTI3fG3CpzIwMTctMTItMjggMDE6MDQ6MzJ8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzcuOTl8bC9taW7CpzIwMTctMTItMjggMDE6MDQ6MzJ8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxOS4wN3xXaMKnMjAxNy0xMi0yOCAwMTowNDozMnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnw0MzQ2OXxXwqcyMDE3LTEyLTI4IDAxOjA0OjMzfFJFX1RFTVBfUFMzMDAwXzA2fERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi43NXzCpzIwMTctMTItMjggMDE6MDQ6MzN8UkVfVEVNUF9QUzMwMDBfMTF8RFVNTVl8fHRlbXBlcmF0dXJlfDgyLjYyfMKnMjAxNy0xMi0yOCAwMTowNDozNHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsaXRlcnByb21pbnwxOS4zNnxsL21pbsKnMjAxNy0xMi0yOCAwMTowNDozNHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsYXN0bGl0ZXJ3b3JrfDMuNTV8V2jCpzIwMTctMTItMjggMDE6MDQ6MzR8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8cG93ZXJ8NDEyM3xXwqcyMDE3LTEyLTI4IDAxOjA0OjM0fFJFX1RFTVBfUFMzMDAwXzA0fERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi43NXzCpzIwMTctMTItMjggMDE6MDQ6MzR8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzcuOTl8bC9taW7CpzIwMTctMTItMjggMDE6MDQ6MzR8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxOS4wN3xXaMKnMjAxNy0xMi0yOCAwMTowNDozNHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnw0MzQ2OXxXwqcyMDE3LTEyLTI4IDAxOjA0OjM0fFJFX1RFTVBfUFMzMDAwXzAxfERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi42OXzCpzIwMTctMTItMjggMDE6MDQ6MzV8UkVfVEVNUF9IVl9STEEyfERVTU1ZfHx0ZW1wZXJhdHVyZXw2Ni43NXzCpzIwMTctMTItMjggMDE6MDQ6MzV8UElELkZVQk98UElEMjB8fGRlc2lyZWR8MjkuNHzCpzIwMTctMTItMjggMDE6MDQ6MzV8UElELkZVQk98UElEMjB8fG1lYXN1cmVkfDMwLjM3fMKnMjAxNy0xMi0yOCAwMTowNDozNXxQSUQuRlVCT3xQSUQyMHx8cF9wfC00MzYuNTAwMDAwMDAwMDAxfMKnMjAxNy0xMi0yOCAwMTowNDozNXxQSUQuRlVCT3xQSUQyMHx8cF9kfC0xMTguODU3NjQzNzYyNzQ1fMKnMjAxNy0xMi0yOCAwMTowNDozNXxQSUQuRlVCT3xQSUQyMHx8cF9pfC0xMTAuMTQ5OTk5OTk5OTc3fMKnMjAxNy0xMi0yOCAwMTowNDozNXxQSUQuRlVCT3xQSUQyMHx8YWN0dWF0aW9ufC02NjZ8wqcyMDE3LTEyLTI4IDAxOjA0OjM1fFBJRC5GVUJPfFBJRDIwfHxhY3R1YXRpb25DYWxjfC02NjUuNTA3NjQzNzYyNzIzfMKnMjAxNy0xMi0yOCAwMTowNDozNXxSRV9URU1QX1BTMzAwMF8wOXxEVU1NWXx8dGVtcGVyYXR1cmV8MjYuNjJ8 Timeout:86400 ConnectedVia:N/A
Pid:WAITING: Fn:PRESENCE_DoLocalPingScan Arg:Z5_Stephan|192.168.0.100|0|4 Timeout:60 ConnectedVia:N/A
Ich mach mich dann mal auf die Suche, warum die Presence alle hängen. Scheint also nichts mit DbLog zu tun zu haben, sondern das ist nur die Stelle, an der es auffällt...
Grüße und Danke für den super Support!
Stephan
Hi,
ich hab mal wieder tausend Dateien zum importieren ;D
Wär es möglich, einen Dateinamen anzugeben, und die Zeilen anstatt bei jedem exportCache purge in eine neue Datei zu schreiben, sie an die vorhandene anzuhängen?
z.B.
attr exportFileName cache_logdb_%Y-%m-%d
Grüße,
Stephan
Hi Stephan,
na ich schau mal ob ich da etwas anbieten kann was sich nahtlos integrieren lässt.
Melde mich wieder wenn ich was zum Test anbieten kann.
Grüße,
Heiko
Guten Abend,
es ist hier eine neue Version 3.6.2 angehängt. Was ist neu ?
1.
Wie von Stephan gewünscht/angeregt habe ich es nun ermöglicht, dass bei exportCache der Inhalt an ein bestehendes File angehängt werden kann.
Dafür gibt es ein neues Attribut.
exportCacheAppend
attr <device> exportCacheAppend [1|0]
Wenn gesetzt, wird beim Export des Cache ("set <device> exportCache") der Cacheinhalt an das neueste bereits vorhandene Exportfile angehängt.
Ist noch kein Exportfile vorhanden, wird es neu angelegt.
Ist das Attribut nicht gesetzt, wird bei jedem Exportvorgang ein neues Exportfile angelegt. (default)
2.
Die zweite Änderung betrifft nur Nutzer von SQLite. Ich habe mir Gedanken gemacht, ob es über die Applikation möglich wäre, mehr Vorsorge gegen eine Filekorruption zu betreiben. Es wird hier (https://www.sqlite.org/howtocorrupt.html) empfohlen für ein Maximum an Zuverlässigkeit und Robustheit gegenüber Datenbankkorruption die DB mit synchronous = FULL zu betreiben, was auch der Default-Zustand ist.
Allerdings wird DbLog seit jeher im Modus synchronous = NORMAL betrieben (zumindest solange ich das Modul kenne).
Laut Doku soll der Normal Modus beim Schreiben schneller gegenüber dem Full-Modus sein (was wegen der Funktionalität auch nachvollziehbar ist), allerdings habe ich bei meinen Test keinerlei negative Performanceeinflüsse feststellen können. Selbst wenn es sein sollte, halte ich einen Zugewinn an Robustheit für wichtiger zumal mit dem asynchronen Modus dies eliminiert werden kann.
Aus diesen Überlegungen heraus habe ich jetzt in dieser Version synchronous = FULL eingestellt. Im normalen Betrieb merkt man davon nichts, aber ich hoffe dass dadurch SQLite etwas stabiler gegenüber Korruption wird, obwohl es sicher nicht 100%ig vermieden werden kann und deswegen immer ein aktuelles Backup zu haben wichtig ist !
Deswegen bitte ich insbesondere SQLite-Anwender bzw. SQLite-Spezies um ihre Tests/Meinung und um Rückmeldung wie die Erfahrung mit dieser Version sind.
schönen Abend und LG,
Heiko
Hey Heiko, danke für die Klasse arbeit!
Läuft erstmal unauffällig!
Zwei Fragen sind grade noch übrig:
1. Bei einem Shutdown werden die noch gecachten Daten in die Datenbank geschrieben, richtig?
2. Ich muss meine Datenbank mal überarbeiten. Readings vereinheitlichen, Devices vereinheitlichen, Daten ausdünnen usw.
Dafür könnte ich doch den Zugriff einfach abschalten (z.B. Passwort ändern), dann alle Änderungen vornehmen, und dann ggf. die exportFiles importieren. Oder?
Grüße,
Stephan
Nabend Stephan,
Zitat1. Bei einem Shutdown werden die noch gecachten Daten in die Datenbank geschrieben, richtig?
Ja, du solltest dir aber das Attribut "shutdownWait" auf z.B. 2 (Sekunden) setzen damit der DB Zeit für den Sync bleibt.
ZitatDafür könnte ich doch den Zugriff einfach abschalten (z.B. Passwort ändern), dann alle Änderungen vornehmen, und dann ggf. die exportFiles importieren. Oder?
Im Prinzip kannst du das so machen, musst dir nur verbose auf 1 oder 0 setzen sonst hast du jede Menge Fehlermeldungen im Log.
Ein "set reopen <hohe Sekundenzahl>" täte es auch, allerdings wäre diese Einstellung nach einem Restart dahin.
Grüße
Heiko
Hi,
probleme hab ich immer noch mit der Datenbank:
Zitat
Commit already running - resync at NextSync
Was ich getan habe:
set logdb reopen
set logdb rereadcfg
attr logdb verbose 5
attr global stacktrace 1
blockinginfo
ZitatPid:WAITING: Fn:DbLog_PushAsync Arg:logdb|MjAxOC0wMS0xOCAxMDo1ODoxM3xLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzOC41OXxsL21pbsKnMjAxOC0wMS0xOCAxMDo1ODoxM3xLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE2LjkwfFdowqcyMDE4LTAxLTE4IDEwOjU4OjEzfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDM5MTMzfFfCpzIwMTgtMDEtMTggMTA6NTg6MTN8UkVfVEVNUF9IVl9WTHxEVU1NWXx8dGVtcGVyYXR1cmV8LTEuNTB8wqcyMDE4LTAxLTE4IDEwOjU4OjEzfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxpdGVycHJvbWlufDE5LjMzfGwvbWluwqcyMDE4LTAxLTE4IDEwOjU4OjEzfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxhc3RsaXRlcndvcmt8Ni40NXxXaMKnMjAxOC0wMS0xOCAxMDo1ODoxM3xLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxwb3dlcnw3NDgwfFfCpzIwMTgtMDEtMTggMTA6NTg6MTR8UkVfVEVNUF9QUzMwMDBfMDN8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjAwfMKnMjAxOC0wMS0xOCAxMDo1ODoxNHxSRV9URU1QX1BTMzAwMF8wN3xEVU1NWXx8dGVtcGVyYXR1cmV8MjYuNzV8wqcyMDE4LTAxLTE4IDEwOjU4OjE1fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM4LjU5fGwvbWluwqcyMDE4LTAxLTE4IDEwOjU4OjE1fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTYuOTB8V2jCpzIwMTgtMDEtMTggMTA6NTg6MTV8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8MzkxMzN8V8KnMjAxOC0wMS0xOCAxMDo1ODoxNXxSRV9URU1QX1BTMzAwMF8wMnxEVU1NWXx8dGVtcGVyYXR1cmV8MjYuMTl8wqcyMDE4LTAxLTE4IDEwOjU4OjE1fFJFX1RFTVBfUFMzMDAwXzEwfERVTU1ZfHx0ZW1wZXJhdHVyZXwzNy40NHzCpzIwMTgtMDEtMTggMTA6NTg6MTZ8UkVfVEVNUF9QUzMwMDBfMDV8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjA2fMKnMjAxOC0wMS0xOCAxMDo1ODoxNnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHx0b3RhbHw5OTYuMjY0fG3CpzIwMTgtMDEtMTggMTA6NTg6MTZ8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzguNTh8bC9taW7CpzIwMTgtMDEtMTggMTA6NTg6MTZ8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxNi45MHxXaMKnMjAxOC0wMS0xOCAxMDo1ODoxNnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnwzOTEyM3xXwqcyMDE4LTAxLTE4IDEwOjU4OjE2fFJFX1RFTVBfUFMzMDAwXzA2fERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi41NnzCpzIwMTgtMDEtMTggMTA6NTg6MTZ8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGl0ZXJwcm9taW58MTkuMzJ8bC9taW7CpzIwMTgtMDEtMTggMTA6NTg6MTZ8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGFzdGxpdGVyd29ya3w2LjQ1fFdowqcyMDE4LTAxLTE4IDEwOjU4OjE2fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fHBvd2VyfDc0NzZ8V8KnMjAxOC0wMS0xOCAxMDo1ODoxN3xSRV9URU1QX0hWX1JMQTJ8RFVNTVl8fHRlbXBlcmF0dXJlfDYyLjI1fMKnMjAxOC0wMS0xOCAxMDo1ODoxN3xSRV9URU1QX1BTMzAwMF8xMXxEVU1NWXx8dGVtcGVyYXR1cmV8NjcuMTl8wqcyMDE4LTAxLTE4IDEwOjU4OjE3fFJFX1RFTVBfUFMzMDAwXzA0fERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi4xMnzCpzIwMTgtMDEtMTggMTA6NTg6MTh8UkVfVEVNUF9IVl9WTDJ8RFVNTVl8fHRlbXBlcmF0dXJlfDc2LjYyNXzCpzIwMTgtMDEtMTggMTA6NTg6MTh8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzguNTh8bC9taW7CpzIwMTgtMDEtMTggMTA6NTg6MTh8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxNi42N3xXaMKnMjAxOC0wMS0xOCAxMDo1ODoxOHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnwzODU4NnxXwqcyMDE4LTAxLTE4IDEwOjU4OjE4fERfV01aX0hlaXp1bmdfbWFpbnxEVU1NWXx8cG93ZXJ8NzQ3MiBXfMKnMjAxOC0wMS0xOCAxMDo1ODoxOHxEX1dNWl9IZWl6dW5nX21haW58RFVNTVl8fHdvcmt8MTYxOC44NSBXaHzCpzIwMTgtMDEtMTggMTA6NTg6MTh8UkVfVEVNUF9CUlR8RFVNTVl8fHRlbXBlcmF0dXJlfDg2NS41fMKnMjAxOC0wMS0xOCAxMDo1ODoxOHxSRV9URU1QX1BTMzAwMF8wMXxEVU1NWXx8dGVtcGVyYXR1cmV8MjYuMTl8wqcyMDE4LTAxLTE4IDEwOjU4OjE5fFJFX1RFTVBfUFMzMDAwXzA5fERVTU1ZfHx0ZW1wZXJhdHVyZXwyOC44N3zCpzIwMTgtMDEtMTggMTA6NTg6MTl8UkVfVEVNUF9QUzMwMDBfMDh8RFVNTVl8fHRlbXBlcmF0dXJlfDI2Ljg3fMKnMjAxOC0wMS0xOCAxMDo1ODoxOXxLTlgxMDEuSTAxX0JXTV9HYXJhZ2VfV0hHX0hlbGxpZ2tlaXR8S05YfHxzdGF0ZXw4OC40MHxsdXjCpzIwMTgtMDEtMTggMTA6NTg6MTl8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzguNTh8bC9taW7CpzIwMTgtMDEtMTggMTA6NTg6MTl8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxNi42N3xXaMKnMjAxOC0wMS0xOCAxMDo1ODoxOXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnwzODU4NnxXwqcyMDE4LTAxLTE4IDEwOjU4OjIwfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxpdGVycHJvbWlufDE5LjQwfGwvbWluwqcyMDE4LTAxLTE4IDEwOjU4OjIwfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxhc3RsaXRlcndvcmt8Ni40NXxXaMKnMjAxOC0wMS0xOCAxMDo1ODoyMHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxwb3dlcnw3NTA3fFfCpzIwMTgtMDEtMTggMTA6NTg6MjB8UkVfVEVNUF9TcGVpY2hlcl8wMnxEVU1NWXx8dGVtcGVyYXR1cmV8MjYuMjV8wqcyMDE4LTAxLTE4IDEwOjU4OjIwfFJFX1RFTVBfU3BlaWNoZXJfMDh8RFVNTVl8fHRlbXBlcmF0dXJlfDYzLjk0fMKnMjAxOC0wMS0xOCAxMDo1ODoyMXxSRV9URU1QX1NwZWljaGVyXzEwfERVTU1ZfHx0ZW1wZXJhdHVyZXw2NC4xOXzCpzIwMTgtMDEtMTggMTA6NTg6MjF8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8dG90YWx8OTk2LjI2N3xtwqcyMDE4LTAxLTE4IDEwOjU4OjIxfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM4LjYwfGwvbWluwqcyMDE4LTAxLTE4IDEwOjU4OjIxfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTYuNjd8V2jCpzIwMTgtMDEtMTggMTA6NTg6MjF8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8Mzg2MDZ8V8KnMjAxOC0wMS0xOCAxMDo1ODoyMXxSRV9URU1QX1NwZWljaGVyXzA0fERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi4yNXzCpzIwMTgtMDEtMTggMTA6NTg6MjJ8UkVfVEVNUF9TcGVpY2hlcl8wM3xEVU1NWXx8dGVtcGVyYXR1cmV8MjYuMzF8wqcyMDE4LTAxLTE4IDEwOjU4OjIyfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM4LjYwfGwvbWluwqcyMDE4LTAxLTE4IDEwOjU4OjIyfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTYuNjd8V2jCpzIwMTgtMDEtMTggMTA6NTg6MjJ8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8Mzg2MDZ8V8KnMjAxOC0wMS0xOCAxMDo1ODoyMnxSRV9URU1QX1NwZWljaGVyXzAxfERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi4wMHzCpzIwMTgtMDEtMTggMTA6NTg6MjN8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGl0ZXJwcm9taW58MTkuMzh8bC9taW7CpzIwMTgtMDEtMTggMTA6NTg6MjN8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGFzdGxpdGVyd29ya3w2LjQ1fFdowqcyMDE4LTAxLTE4IDEwOjU4OjIzfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fHBvd2VyfDc1MDB8V8KnMjAxOC0wMS0xOCAxMDo1ODoyM3xSRV9URU1QX1NwZWljaGVyXzA3fERVTU1ZfHx0ZW1wZXJhdHVyZXw0OC45NHzCpzIwMTgtMDEtMTggMTA6NTg6MjN8S05YMTAxLkkwMV9CV01fR2FyYWdlX1dIR19IZWxsaWdrZWl0fEtOWHx8c3RhdGV8OTkuMDR8bHV4wqcyMDE4LTAxLTE4IDEwOjU4OjIzfFJFX1RFTVBfU3BlaWNoZXJfMDl8RFVNTVl8fHRlbXBlcmF0dXJlfDY2LjMxfMKnMjAxOC0wMS0xOCAxMDo1ODoyNHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzOC42MHxsL21pbsKnMjAxOC0wMS0xOCAxMDo1ODoyNHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE2LjY3fFdowqcyMDE4LTAxLTE4IDEwOjU4OjI0fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDM4NjA2fFfCpzIwMTgtMDEtMTggMTA6NTg6MjR8S05YMTAxLkkwMV9CV01fR2FyYWdlX1dIR19IZWxsaWdrZWl0fEtOWHx8c3RhdGV8ODYuNDB8bHV4wqcyMDE4LTAxLTE4IDEwOjU4OjI0fFJFX1RFTVBfU3BlaWNoZXJfMDZ8RFVNTVl8fHRlbXBlcmF0dXJlfDMyLjM4fMKnMjAxOC0wMS0xOCAxMDo1ODoyNXxSRV9URU1QX1NwZWljaGVyXzA1fERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi4xMnzCpzIwMTgtMDEtMTggMTA6NTg6MjV8S05YMTAxLkkwMV9CV01fR2FyYWdlX1dIR19IZWxsaWdrZWl0fEtOWHx8c3RhdGV8MTAzLjc2fGx1eMKnMjAxOC0wMS0xOCAxMDo1ODoyNXxSRV9URU1QX1ZvcmxhdWZfU2Nod2ltbWJhZHxEVU1NWXx8dGVtcGVyYXR1cmV8MjAuNTZ8wqcyMDE4LTAxLTE4IDEwOjU4OjI1fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHRvdGFsfDk5Ni4yNzB8bcKnMjAxOC0wMS0xOCAxMDo1ODoyNXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzOC42MnxsL21pbsKnMjAxOC0wMS0xOCAxMDo1ODoyNXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE2LjY3fFdowqcyMDE4LTAxLTE4IDEwOjU4OjI1fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDM4NjI2fFfCpzIwMTgtMDEtMTggMTA6NTg6MjZ8UkVfVEVNUF9SdWVja2xhdWZfU29sYXJ8RFVNTVl8fHRlbXBlcmF0dXJlfDI0LjE5fMKnMjAxOC0wMS0xOCAxMDo1ODoyNnxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsaXRlcnByb21pbnwxOS4yOHxsL21pbsKnMjAxOC0wMS0xOCAxMDo1ODoyNnxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsYXN0bGl0ZXJ3b3JrfDYuNDV8V2jCpzIwMTgtMDEtMTggMTA6NTg6MjZ8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8cG93ZXJ8NzQ2MXxXwqcyMDE4LTAxLTE4IDEwOjU4OjI2fFJFX1RFTVBfVm9ybGF1Zl9FR19Cb2RlbnxEVU1NWXx8dGVtcGVyYXR1cmV8MzAuMjV8wqcyMDE4LTAxLTE4IDEwOjU4OjI3fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM4LjYyfGwvbWluwqcyMDE4LTAxLTE4IDEwOjU4OjI3fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTYuNjd8V2jCpzIwMTgtMDEtMTggMTA6NTg6Mjd8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8Mzg2MjZ8V8KnMjAxOC0wMS0xOCAxMDo1ODoyN3xSRV9URU1QX1J1ZWNrbGF1Zl9FR19Cb2RlbnxEVU1NWXx8dGVtcGVyYXR1cmV8MjQuNTB8wqcyMDE4LTAxLTE4IDEwOjU4OjI3fEtOWDAxLk8wOF9Ba3Rvcl9MZXVjaHRlX0ZsdXJfRUdfcHJvdmlzb3Jpc2NofEtOWHx8c3RhdGV8b2ZmfMKnMjAxOC0wMS0xOCAxMDo1ODoyOHxSRV9URU1QX0hWX1JMQTJ8RFVNTVl8fHRlbXBlcmF0dXJlfDYyLjMxMnzCpzIwMTgtMDEtMTggMTA6NTg6Mjh8UkVfVEVNUF9SdWVja2xhdWZfV1RfRUd8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjYyfMKnMjAxOC0wMS0xOCAxMDo1ODoyOHxTdHJvbXphZWhsZXJ8Vlp8fHRvdGFsX3Bvd2VyX0wxfDYzMnzCpzIwMTgtMDEtMTggMTA6NTg6Mjh8UkVfVEVNUF9Wb3JsYXVmX1NvbGFyfERVTU1ZfHx0ZW1wZXJhdHVyZXwyMC41MHzCpzIwMTgtMDEtMTggMTA6NTg6Mjl8UkVfVEVNUF9IVl9WTDJ8RFVNTVl8fHRlbXBlcmF0dXJlfDc2LjYyNXzCpzIwMTgtMDEtMTggMTA6NTg6Mjl8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzguNjJ8bC9taW7CpzIwMTgtMDEtMTggMTA6NTg6Mjl8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxNi42MHxXaMKnMjAxOC0wMS0xOCAxMDo1ODoyOXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnwzODQ2NXxXwqcyMDE4LTAxLTE4IDEwOjU4OjI5fEtOWDEwMS5JMDFfQldNX0dhcmFnZV9XSEdfSGVsbGlna2VpdHxLTlh8fHN0YXRlfDkxLjkyfGx1eMKnMjAxOC0wMS0xOCAxMDo1ODoyOXxSRV9URU1QX1J1ZWNrbGF1ZkhLfERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi41MHzCpzIwMTgtMDEtMTggMTA6NTg6Mjl8U3Ryb216YWVobGVyfFZafHx0b3RhbF9wb3dlcl9MMXw2MTB8wqcyMDE4LTAxLTE4IDEwOjU4OjI5fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxpdGVycHJvbWlufDE5LjI5fGwvbWluwqcyMDE4LTAxLTE4IDEwOjU4OjI5fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxhc3RsaXRlcndvcmt8Ni40NXxXaMKnMjAxOC0wMS0xOCAxMDo1ODoyOXxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxwb3dlcnw3NDY1fFfCpzIwMTgtMDEtMTggMTA6NTg6Mjl8S05YMTAwLkkwMV9CV01fRmx1cl9FR19IZWxsaWdrZWl0fEtOWHx8c3RhdGV8MjYxLjc2fGx1eMKnMjAxOC0wMS0xOCAxMDo1ODoyOXxSRV9URU1QX1ZvcmxhdWZIS3xEVU1NWXx8dGVtcGVyYXR1cmV8MzIuMTl8wqcyMDE4LTAxLTE4IDEwOjU4OjMwfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHRvdGFsfDk5Ni4yNzN8bcKnMjAxOC0wMS0xOCAxMDo1ODozMHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzOC42MHxsL21pbsKnMjAxOC0wMS0xOCAxMDo1ODozMHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE2LjYwfFdowqcyMDE4LTAxLTE4IDEwOjU4OjMwfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDM4NDQ1fFfCpzIwMTgtMDEtMTggMTA6NTg6MzB8UkVfVEVNUF9TY2hsYWZ6aW1tZXJ8RFVNTVl8fHRlbXBlcmF0dXJlfDIxLjQ0fMKnMjAxOC0wMS0xOCAxMDo1ODozMXxSRV9URU1QX0Fua2xlaWRlfERVTU1ZfHx0ZW1wZXJhdHVyZXwyMi42OXzCpzIwMTgtMDEtMTggMTA6NTg6MzF8UkVfVEVNUF9GbHVyT0d8RFVNTVl8fHRlbXBlcmF0dXJlfDIzLjI1fMKnMjAxOC0wMS0xOCAxMDo1ODozMnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzOC42MHxsL21pbsKnMjAxOC0wMS0xOCAxMDo1ODozMnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE2LjYwfFdowqcyMDE4LTAxLTE4IDEwOjU4OjMyfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDM4NDQ1fFfCpzIwMTgtMDEtMTggMTA6NTg6MzJ8UkVfVEVNUF9Wb3JsYXVmX0tlc3NlbHxEVU1NWXx8dGVtcGVyYXR1cmV8MjAuMDZ8wqcyMDE4LTAxLTE4IDEwOjU4OjMyfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxpdGVycHJvbWlufDE5LjI3fGwvbWluwqcyMDE4LTAxLTE4IDEwOjU4OjMyfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxhc3RsaXRlcndvcmt8Ni42MHxXaMKnMjAxOC0wMS0xOCAxMDo1ODozMnxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxwb3dlcnw3NjMxfFfCpzIwMTgtMDEtMTggMTA6NTg6MzJ8S05YMTAxLkkwMV9CV01fR2FyYWdlX1dIR19IZWxsaWdrZWl0fEtOWHx8c3RhdGV8MTAzLjM2fGx1eMKnMjAxOC0wMS0xOCAxMDo1ODozMnxSRV9URU1QX0FVU1NFTnxEVU1NWXx8dGVtcGVyYXR1cmV8OC40NHzCpzIwMTgtMDEtMTggMTA6NTg6MzN8RF9XTVpfSGVpenVuZ19tYWlufERVTU1ZfHxwb3dlcnw3NzY4IFd8wqcyMDE4LTAxLTE4IDEwOjU4OjMzfERfV01aX0hlaXp1bmdfbWFpbnxEVU1NWXx8d29ya3wxNjgzLjEwIFdofMKnMjAxOC0wMS0xOCAxMDo1ODozM3xSRV9URU1QX1ZvcmxhdWZfV1d8RFVNTVl8fHRlbXBlcmF0dXJlfDU0LjY5fMKnMjAxOC0wMS0xOCAxMDo1ODozM3xLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzOC42MHxsL21pbsKnMjAxOC0wMS0xOCAxMDo1ODozM3xLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE2LjYwfFdowqcyMDE4LTAxLTE4IDEwOjU4OjMzfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDM4NDQ1fFfCpzIwMTgtMDEtMTggMTA6NTg6MzN8UkVfVEVNUF9XV19BdXNnYW5nX1NwZWljaGVyfERVTU1ZfHx0ZW1wZXJhdHVyZXw1NC4zOHzCpzIwMTgtMDEtMTggMTA6NTg6MzN8S05YMTAxLkkwMV9CV01fR2FyYWdlX1dIR19IZWxsaWdrZWl0fEtOWHx8c3RhdGV8OTAuNDh8bHV4wqcyMDE4LTAxLTE4IDEwOjU4OjM0fFJFX1RFTVBfUnVlY2tsYXVmX0tlc3NlbHxEVU1NWXx8dGVtcGVyYXR1cmV8MTkuOTR8wqcyMDE4LTAxLTE4IDEwOjU4OjM0fFJFX1RFTVBfUnVlY2tsYXVmX1ppcmt1bGF0aW9ufERVTU1ZfHx0ZW1wZXJhdHVyZXwyMi44N3zCpzIwMTgtMDEtMTggMTA6NTg6MzV8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8dG90YWx8OTk2LjI3NnxtwqcyMDE4LTAxLTE4IDEwOjU4OjM1fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM4LjU5fGwvbWluwqcyMDE4LTAxLTE4IDEwOjU4OjM1fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTYuNjB8V2jCpzIwMTgtMDEtMTggMTA6NTg6MzV8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8Mzg0MzV8V8KnMjAxOC0wMS0xOCAxMDo1ODozNXxLTlgxMDEuSTAxX0JXTV9HYXJhZ2VfV0hHX0hlbGxpZ2tlaXR8S05YfHxzdGF0ZXwxMDIuOTZ8bHV4wqcyMDE4LTAxLTE4IDEwOjU4OjM1fFJFX1RFTVBfSFZfUkxBfERVTU1ZfHx0ZW1wZXJhdHVyZXwtMC4wNnzCpzIwMTgtMDEtMTggMTA6NTg6MzV8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGl0ZXJwcm9taW58MTkuMjd8bC9taW7CpzIwMTgtMDEtMTggMTA6NTg6MzV8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGFzdGxpdGVyd29ya3w2LjYwfFdowqcyMDE4LTAxLTE4IDEwOjU4OjM1fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fHBvd2VyfDc2MzF8V8KnMjAxOC0wMS0xOCAxMDo1ODozNXxTdHJvbXphZWhsZXJ8Vlp8fHRvdGFsX3Bvd2VyX0wxfDYzM3zCpzIwMTgtMDEtMTggMTA6NTg6MzZ8UkVfVEVNUF9IVl9STHxEVU1NWXx8dGVtcGVyYXR1cmV8MzMuODh8wqcyMDE4LTAxLTE4IDEwOjU4OjM2fFJFX1RFTVBfSFZfVkx8RFVNTVl8fHRlbXBlcmF0dXJlfC0xLjUwfMKnMjAxOC0wMS0xOCAxMDo1ODozNnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzOC41OXxsL21pbsKnMjAxOC0wMS0xOCAxMDo1ODozNnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE2LjYwfFdowqcyMDE4LTAxLTE4IDEwOjU4OjM2fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDM4NDM1fFfCpzIwMTgtMDEtMTggMTA6NTg6Mzd8UkVfVEVNUF9QUzMwMDBfMDN8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjAwfMKnMjAxOC0wMS0xOCAxMDo1ODozN3xSRV9URU1QX1BTMzAwMF8wN3xEVU1NWXx8dGVtcGVyYXR1cmV8MjYuNzV8wqcyMDE4LTAxLTE4IDEwOjU4OjM3fFN0cm9temFlaGxlcnxWWnx8dG90YWxfcG93ZXJfTDF8NjEyfMKnMjAxOC0wMS0xOCAxMDo1ODozOHxSRV9URU1QX1BTMzAwMF8wMnxEVU1NWXx8dGVtcGVyYXR1cmV8MjYuMTl8wqcyMDE4LTAxLTE4IDEwOjU4OjM4fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM4LjU5fGwvbWluwqcyMDE4LTAxLTE4IDEwOjU4OjM4fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTYuNjB8V2jCpzIwMTgtMDEtMTggMTA6NTg6Mzh8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8Mzg0MzV8V8KnMjAxOC0wMS0xOCAxMDo1ODozOHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsaXRlcnByb21pbnwxOS4yOXxsL21pbsKnMjAxOC0wMS0xOCAxMDo1ODozOHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsYXN0bGl0ZXJ3b3JrfDYuNjB8V2jCpzIwMTgtMDEtMTggMTA6NTg6Mzh8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8cG93ZXJ8NzYzOXxXwqcyMDE4LTAxLTE4IDEwOjU4OjM4fFJFX1RFTVBfUFMzMDAwXzEwfERVTU1ZfHx0ZW1wZXJhdHVyZXwzNy4zOHzCpzIwMTgtMDEtMTggMTA6NTg6Mzh8U3Ryb216YWVobGVyfFZafHx0b3RhbF9wb3dlcl9MMXw2NDl8wqcyMDE4LTAxLTE4IDEwOjU4OjM4fFN0cm9temFlaGxlcnxWWnx8dG90YWxfcG93ZXJ8MTA1MHzCpzIwMTgtMDEtMTggMTA6NTg6Mzl8UkVfVEVNUF9IVl9STEEyfERVTU1ZfHx0ZW1wZXJhdHVyZXw2Mi4zNzV8wqcyMDE4LTAxLTE4IDEwOjU4OjM5fFJFX1RFTVBfUFMzMDAwXzA1fERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi4wNnzCpzIwMTgtMDEtMTggMTA6NTg6Mzl8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8dG90YWx8OTk2LjI3OXxtwqcyMDE4LTAxLTE4IDEwOjU4OjM5fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM4LjYwfGwvbWluwqcyMDE4LTAxLTE4IDEwOjU4OjM5fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTYuNTJ8V2jCpzIwMTgtMDEtMTggMTA6NTg6Mzl8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8MzgyNTd8V8KnMjAxOC0wMS0xOCAxMDo1ODozOXxSRV9URU1QX0hWX1ZMMnxEVU1NWXx8dGVtcGVyYXR1cmV8NzYuNjI1fMKnMjAxOC0wMS0xOCAxMDo1ODo0MHxTdHJvbXphZWhsZXJ8Vlp8fHRvdGFsX3Bvd2VyX0wxfDYyMXzCpzIwMTgtMDEtMTggMTA6NTg6NDB8U3Ryb216YWVobGVyfFZafHx0b3RhbF9wb3dlcnwxMDIyfMKnMjAxOC0wMS0xOCAxMDo1ODo0MHxSRV9URU1QX1BTMzAwMF8wNnxEVU1NWXx8dGVtcGVyYXR1cmV8MjYuNTZ8wqcyMDE4LTAxLTE4IDEwOjU4OjQwfFJFX1RFTVBfUFMzMDAwXzExfERVTU1ZfHx0ZW1wZXJhdHVyZXw2Ny4xOXzCpzIwMTgtMDEtMTggMTA6NTg6NDF8U3Ryb216YWVobGVyfFZafHx0b3RhbF9wb3dlcl9MMXw2MDF8wqcyMDE4LTAxLTE4IDEwOjU4OjQxfFJFX1RFTVBfUFMzMDAwXzA0fERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi4xMnzCpzIwMTgtMDEtMTggMTA6NTg6NDF8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzguNjB8bC9taW7CpzIwMTgtMDEtMTggMTA6NTg6NDF8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxNi41MnxXaMKnMjAxOC0wMS0xOCAxMDo1ODo0MXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnwzODI1N3xXwqcyMDE4LTAxLTE4IDEwOjU4OjQxfFJFX1RFTVBfUFMzMDAwXzAxfERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi4xOXzCpzIwMTgtMDEtMTggMTA6NTg6NDF8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGl0ZXJwcm9taW58MTkuMjl8bC9taW7CpzIwMTgtMDEtMTggMTA6NTg6NDF8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGFzdGxpdGVyd29ya3w2LjYwfFdowqcyMDE4LTAxLTE4IDEwOjU4OjQxfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fHBvd2VyfDc2Mzl8V8KnMjAxOC0wMS0xOCAxMDo1ODo0MnxLTlgxMDAuSTAxX0JXTV9GbHVyX0VHX0hlbGxpZ2tlaXR8S05YfHxzdGF0ZXwyNTAuNTZ8bHV4wqcyMDE4LTAxLTE4IDEwOjU4OjQyfFN0cm9temFlaGxlcnxWWnx8dG90YWxfcG93ZXJ8MTAwMHzCpzIwMTgtMDEtMTggMTA6NTg6NDJ8UkVfVEVNUF9QUzMwMDBfMDl8RFVNTVl8fHRlbXBlcmF0dXJlfDI4LjgxfMKnMjAxOC0wMS0xOCAxMDo1ODo0MnxQSUQuRlVCT3xQSUQyMHx8ZGVzaXJlZHwyOS4yfMKnMjAxOC0wMS0xOCAxMDo1ODo0MnxQSUQuRlVCT3xQSUQyMHx8bWVhc3VyZWR8MzIuMTl8wqcyMDE4LTAxLTE4IDEwOjU4OjQyfFBJRC5GVUJPfFBJRDIwfHxwX3B8LTEzNDUuNXzCpzIwMTgtMDEtMTggMTA6NTg6NDJ8UElELkZVQk98UElEMjB8fHBfZHwtMTU2NC42NjQzMzE0MzY1fMKnMjAxOC0wMS0xOCAxMDo1ODo0MnxQSUQuRlVCT3xQSUQyMHx8cF9pfC0xMzQuODUwMDAwMDAwMDA4fMKnMjAxOC0wMS0xOCAxMDo1ODo0MnxQSUQuRlVCT3xQSUQyMHx8YWN0dWF0aW9ufC0yNTAwfMKnMjAxOC0wMS0xOCAxMDo1ODo0MnxQSUQuRlVCT3xQSUQyMHx8YWN0dWF0aW9uQ2FsY3wtMzA0NS4wMTQzMzE0MzY1MXzCpzIwMTgtMDEtMTggMTA6NTg6NDJ8UkVfVEVNUF9QUzMwMDBfMDh8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjgxfMKnMjAxOC0wMS0xOCAxMDo1ODo0MnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzOC42MHxsL21pbsKnMjAxOC0wMS0xOCAxMDo1ODo0MnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE2LjUyfFdowqcyMDE4LTAxLTE4IDEwOjU4OjQyfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDM4MjU3fFfCpzIwMTgtMDEtMTggMTA6NTg6NDN8U3Ryb216YWVobGVyfFZafHx0b3RhbF9wb3dlcnwxMDIyfMKnMjAxOC0wMS0xOCAxMDo1ODo0M3xSRV9URU1QX1NwZWljaGVyXzAyfERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi4xOXzCpzIwMTgtMDEtMTggMTA6NTg6NDN8S05YMTAxLkkwMV9CV01fR2FyYWdlX1dIR19IZWxsaWdrZWl0fEtOWHx8c3RhdGV8OTEuOTJ8bHV4wqcyMDE4LTAxLTE4IDEwOjU4OjQzfFJFX1RFTVBfU3BlaWNoZXJfMDh8RFVNTVl8fHRlbXBlcmF0dXJlfDY0LjAwfMKnMjAxOC0wMS0xOCAxMDo1ODo0NHxSRV9URU1QX1NwZWljaGVyXzEwfERVTU1ZfHx0ZW1wZXJhdHVyZXw2NC4yNXzCpzIwMTgtMDEtMTggMTA6NTg6NDR8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8dG90YWx8OTk2LjI4MnxtwqcyMDE4LTAxLTE4IDEwOjU4OjQ0fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM4LjYzfGwvbWluwqcyMDE4LTAxLTE4IDEwOjU4OjQ0fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTYuNTJ8V2jCpzIwMTgtMDEtMTggMTA6NTg6NDR8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8MzgyODZ8V8KnMjAxOC0wMS0xOCAxMDo1ODo0NHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsaXRlcnByb21pbnwxOS4yOXxsL21pbsKnMjAxOC0wMS0xOCAxMDo1ODo0NHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsYXN0bGl0ZXJ3b3JrfDYuNjB8V2jCpzIwMTgtMDEtMTggMTA6NTg6NDR8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8cG93ZXJ8NzYzOXxXwqcyMDE4LTAxLTE4IDEwOjU4OjQ1fFJFX1RFTVBfU3BlaWNoZXJfMDR8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjE5fMKnMjAxOC0wMS0xOCAxMDo1ODo0NXxSRV9URU1QX1NwZWljaGVyXzAzfERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi4zMXzCpzIwMTgtMDEtMTggMTA6NTg6NDZ8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzguNjN8bC9taW7CpzIwMTgtMDEtMTggMTA6NTg6NDZ8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxNi41MnxXaMKnMjAxOC0wMS0xOCAxMDo1ODo0NnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnwzODI4NnxXwqcyMDE4LTAxLTE4IDEwOjU4OjQ2fFJFX1RFTVBfU3BlaWNoZXJfMDF8RFVNTVl8fHRlbXBlcmF0dXJlfDI1Ljk0fMKnMjAxOC0wMS0xOCAxMDo1ODo0NnxSRV9URU1QX1NwZWljaGVyXzA3fERVTU1ZfHx0ZW1wZXJhdHVyZXw0OS4zMXzCpzIwMTgtMDEtMTggMTA6NTg6NDd8UkVfVEVNUF9TcGVpY2hlcl8wOXxEVU1NWXx8dGVtcGVyYXR1cmV8NjYuMzF8wqcyMDE4LTAxLTE4IDEwOjU4OjQ3fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM4LjYzfGwvbWluwqcyMDE4LTAxLTE4IDEwOjU4OjQ3fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTYuNTJ8V2jCpzIwMTgtMDEtMTggMTA6NTg6NDd8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8MzgyODZ8V8KnMjAxOC0wMS0xOCAxMDo1ODo0N3xSRV9URU1QX1NwZWljaGVyXzA2fERVTU1ZfHx0ZW1wZXJhdHVyZXwzMi42OXzCpzIwMTgtMDEtMTggMTA6NTg6NDh8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGl0ZXJwcm9taW58MTkuMjl8bC9taW7CpzIwMTgtMDEtMTggMTA6NTg6NDh8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGFzdGxpdGVyd29ya3w2LjYwfFdowqcyMDE4LTAxLTE4IDEwOjU4OjQ4fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fHBvd2VyfDc2Mzl8V8KnMjAxOC0wMS0xOCAxMDo1ODo0OHxEX1dNWl9IZWl6dW5nX21haW58RFVNTVl8fHBvd2VyfDc2MTYgV3zCpzIwMTgtMDEtMTggMTA6NTg6NDh8RF9XTVpfSGVpenVuZ19tYWlufERVTU1ZfHx3b3JrfDE2NTAuMTAgV2h8wqcyMDE4LTAxLTE4IDEwOjU4OjQ4fFJFX1RFTVBfU3BlaWNoZXJfMDV8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjE5fMKnMjAxOC0wMS0xOCAxMDo1ODo0OXxSRV9URU1QX1ZvcmxhdWZfU2Nod2ltbWJhZHxEVU1NWXx8dGVtcGVyYXR1cmV8MjAuNjJ8wqcyMDE4LTAxLTE4IDEwOjU4OjQ5fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHRvdGFsfDk5Ni4yODV8bcKnMjAxOC0wMS0xOCAxMDo1ODo0OXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzOC42M3xsL21pbsKnMjAxOC0wMS0xOCAxMDo1ODo0OXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE2LjUyfFdowqcyMDE4LTAxLTE4IDEwOjU4OjQ5fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDM4Mjg2fFfCpzIwMTgtMDEtMTggMTA6NTg6NDl8U3Ryb216YWVobGVyfFZafHx0b3RhbF9wb3dlcnwxMDAyfMKnMjAxOC0wMS0xOCAxMDo1ODo0OXxSRV9URU1QX1J1ZWNrbGF1Zl9Tb2xhcnxEVU1NWXx8dGVtcGVyYXR1cmV8MjQuMTl8wqcyMDE4LTAxLTE4IDEwOjU4OjQ5fFJFX1RFTVBfSFZfUkxBMnxEVU1NWXx8dGVtcGVyYXR1cmV8NjIuNDM3fMKnMjAxOC0wMS0xOCAxMDo1ODo1MHxSRV9URU1QX1ZvcmxhdWZfRUdfQm9kZW58RFVNTVl8fHRlbXBlcmF0dXJlfDMwLjMxfMKnMjAxOC0wMS0xOCAxMDo1ODo1MHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzOC42M3xsL21pbsKnMjAxOC0wMS0xOCAxMDo1ODo1MHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE2LjQ1fFdowqcyMDE4LTAxLTE4IDEwOjU4OjUwfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDM4MTI1fFfCpzIwMTgtMDEtMTggMTA6NTg6NTB8UkVfVEVNUF9IVl9WTDJ8RFVNTVl8fHRlbXBlcmF0dXJlfDc2LjU2MnzCpzIwMTgtMDEtMTggMTA6NTg6NTB8UkVfVEVNUF9CUlR8RFVNTVl8fHRlbXBlcmF0dXJlfDg3MS4wfMKnMjAxOC0wMS0xOCAxMDo1ODo1MXxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsaXRlcnByb21pbnwxOS4yOXxsL21pbsKnMjAxOC0wMS0xOCAxMDo1ODo1MXxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsYXN0bGl0ZXJ3b3JrfDYuNjB8V2jCpzIwMTgtMDEtMTggMTA6NTg6NTF8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8cG93ZXJ8NzYzOXxXwqcyMDE4LTAxLTE4IDEwOjU4OjUxfFJFX1RFTVBfUnVlY2tsYXVmX0VHX0JvZGVufERVTU1ZfHx0ZW1wZXJhdHVyZXwyNC41NnzCpzIwMTgtMDEtMTggMTA6NTg6NTF8U3Ryb216YWVobGVyfFZafHx0b3RhbF9wb3dlcl9MMXw2NjF8wqcyMDE4LTAxLTE4IDEwOjU4OjUxfFN0cm9temFlaGxlcnxWWnx8dG90YWxfcG93ZXJ8MTA2OHzCpzIwMTgtMDEtMTggMTA6NTg6NTF8UkVfVEVNUF9SdWVja2xhdWZfV1RfRUd8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjYyfMKnMjAxOC0wMS0xOCAxMDo1ODo1MnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzOC42M3xsL21pbsKnMjAxOC0wMS0xOCAxMDo1ODo1MnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE2LjM4fFdowqcyMDE4LTAxLTE4IDEwOjU4OjUyfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDM3OTY0fFfCpzIwMTgtMDEtMTggMTA6NTg6NTJ8UkVfVEVNUF9Wb3JsYXVmX1NvbGFyfERVTU1ZfHx0ZW1wZXJhdHVyZXwyMC41MHzCpzIwMTgtMDEtMTggMTA6NTg6NTJ8U3Ryb216YWVobGVyfFZafHx0b3RhbF9wb3dlcnwxMDMxfMKnMjAxOC0wMS0xOCAxMDo1ODo1MnxTdHJvbXphZWhsZXJ8Vlp8fHRvdGFsX3Bvd2VyX0wxfDYzMXzCpzIwMTgtMDEtMTggMTA6NTg6NTJ8UkVfVEVNUF9SdWVja2xhdWZIS3xEVU1NWXx8dGVtcGVyYXR1cmV8MjYuNTB8wqcyMDE4LTAxLTE4IDEwOjU4OjUzfFJFX1RFTVBfVm9ybGF1ZkhLfERVTU1ZfHx0ZW1wZXJhdHVyZXwzMi4yNXzCpzIwMTgtMDEtMTggMTA6NTg6NTN8U3Ryb216YWVobGVyfFZafHx0b3RhbF9wb3dlcl9MMXw2NTR8wqcyMDE4LTAxLTE4IDEwOjU4OjUzfFN0cm9temFlaGxlcnxWWnx8dG90YWxfcG93ZXJ8MTA1OHzCpzIwMTgtMDEtMTggMTA6NTg6NTN8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8dG90YWx8OTk2LjI4OHxtwqcyMDE4LTAxLTE4IDEwOjU4OjUzfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM4Ljc5fGwvbWluwqcyMDE4LTAxLTE4IDEwOjU4OjUzfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTYuMzh8V2jCpzIwMTgtMDEtMTggMTA6NTg6NTN8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8MzgxMjF8V8KnMjAxOC0wMS0xOCAxMDo1ODo1NHxSRV9URU1QX1NjaGxhZnppbW1lcnxEVU1NWXx8dGVtcGVyYXR1cmV8MjEuNDR8wqcyMDE4LTAxLTE4IDEwOjU4OjU0fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxpdGVycHJvbWlufDE5LjI3fGwvbWluwqcyMDE4LTAxLTE4IDEwOjU4OjU0fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxhc3RsaXRlcndvcmt8Ni42N3xXaMKnMjAxOC0wMS0xOCAxMDo1ODo1NHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxwb3dlcnw3NzEyfFfCpzIwMTgtMDEtMTggMTA6NTg6NTR8UkVfVEVNUF9BbmtsZWlkZXxEVU1NWXx8dGVtcGVyYXR1cmV8MjIuNjl8wqcyMDE4LTAxLTE4IDEwOjU4OjU0fFN0cm9temFlaGxlcnxWWnx8dG90YWxfcG93ZXJfTDF8NjEwfMKnMjAxOC0wMS0xOCAxMDo1ODo1NHxTdHJvbXphZWhsZXJ8Vlp8fHRvdGFsX3Bvd2VyfDEwMTJ8wqcyMDE4LTAxLTE4IDEwOjU4OjU1fFJFX1RFTVBfRmx1ck9HfERVTU1ZfHx0ZW1wZXJhdHVyZXwyMy41MHzCpzIwMTgtMDEtMTggMTA6NTg6NTV8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzguNzl8bC9taW7CpzIwMTgtMDEtMTggMTA6NTg6NTV8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxNi4zOHxXaMKnMjAxOC0wMS0xOCAxMDo1ODo1NXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnwzODEyMXxXwqcyMDE4LTAxLTE4IDEwOjU4OjU1fFJFX1RFTVBfVm9ybGF1Zl9LZXNzZWx8RFVNTVl8fHRlbXBlcmF0dXJlfDIwLjA2fMKnMjAxOC0wMS0xOCAxMDo1ODo1NnxSRV9URU1QX0FVU1NFTnxEVU1NWXx8dGVtcGVyYXR1cmV8OC40NHzCpzIwMTgtMDEtMTggMTA6NTg6NTZ8S05YMTAxLkkwMV9CV01fR2FyYWdlX1dIR19IZWxsaWdrZWl0fEtOWHx8c3RhdGV8MTAyLjMyfGx1eMKnMjAxOC0wMS0xOCAxMDo1ODo1NnxSRV9URU1QX1ZvcmxhdWZfV1d8RFVNTVl8fHRlbXBlcmF0dXJlfDU0LjQ0fMKnMjAxOC0wMS0xOCAxMDo1ODo1NnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzOC43OXxsL21pbsKnMjAxOC0wMS0xOCAxMDo1ODo1NnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE2LjM4fFdowqcyMDE4LTAxLTE4IDEwOjU4OjU2fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDM4MTIxfFfCpzIwMTgtMDEtMTggMTA6NTg6NTd8UkVfVEVNUF9XV19BdXNnYW5nX1NwZWljaGVyfERVTU1ZfHx0ZW1wZXJhdHVyZXw1NC4yNXzCpzIwMTgtMDEtMTggMTA6NTg6NTd8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGl0ZXJwcm9taW58MTkuMjV8bC9taW7CpzIwMTgtMDEtMTggMTA6NTg6NTd8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGFzdGxpdGVyd29ya3w2LjY3fFdowqcyMDE4LTAxLTE4IDEwOjU4OjU3fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fHBvd2VyfDc3MDR8V8KnMjAxOC0wMS0xOCAxMDo1ODo1OHxSRV9URU1QX1J1ZWNrbGF1Zl9LZXNzZWx8RFVNTVl8fHRlbXBlcmF0dXJlfDE5Ljk0fMKnMjAxOC0wMS0xOCAxMDo1ODo1OHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHx0b3RhbHw5OTYuMjkxfG3CpzIwMTgtMDEtMTggMTA6NTg6NTh8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzguODJ8bC9taW7CpzIwMTgtMDEtMTggMTA6NTg6NTh8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxNi4zOHxXaMKnMjAxOC0wMS0xOCAxMDo1ODo1OHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnwzODE1MHxXwqcyMDE4LTAxLTE4IDEwOjU4OjU4fFJFX1RFTVBfUnVlY2tsYXVmX1ppcmt1bGF0aW9ufERVTU1ZfHx0ZW1wZXJhdHVyZXwyMi44MXzCpzIwMTgtMDEtMTggMTA6NTg6NTl8UkVfVEVNUF9IVl9STEF8RFVNTVl8fHRlbXBlcmF0dXJlfC0wLjA2fMKnMjAxOC0wMS0xOCAxMDo1ODo1OXxSRV9URU1QX0hWX1JMfERVTU1ZfHx0ZW1wZXJhdHVyZXwzMy44OHzCpzIwMTgtMDEtMTggMTA6NTk6MDB8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzguODJ8bC9taW7CpzIwMTgtMDEtMTggMTA6NTk6MDB8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxNi4zOHxXaMKnMjAxOC0wMS0xOCAxMDo1OTowMHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnwzODE1MHxXwqcyMDE4LTAxLTE4IDEwOjU5OjAwfFN0cm9temFlaGxlcnxWWnx8dG90YWxfZW5lcmd5fDExNzU3LjY5Njl8wqcyMDE4LTAxLTE4IDEwOjU5OjAwfFJFX1RFTVBfSFZfVkx8RFVNTVl8fHRlbXBlcmF0dXJlfC0xLjUwfMKnMjAxOC0wMS0xOCAxMDo1OTowMHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsaXRlcnByb21pbnwxOS4yNHxsL21pbsKnMjAxOC0wMS0xOCAxMDo1OTowMHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsYXN0bGl0ZXJ3b3JrfDYuNjd8V2jCpzIwMTgtMDEtMTggMTA6NTk6MDB8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8cG93ZXJ8NzcwMHxXwqcyMDE4LTAxLTE4IDEwOjU5OjAwfFJFX1RFTVBfSFZfUkxBMnxEVU1NWXx8dGVtcGVyYXR1cmV8NjIuNXzCpzIwMTgtMDEtMTggMTA6NTk6MDB8UkVfVEVNUF9QUzMwMDBfMDN8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjAwfMKnMjAxOC0wMS0xOCAxMDo1OTowMXxSRV9URU1QX1BTMzAwMF8wN3xEVU1NWXx8dGVtcGVyYXR1cmV8MjYuNzV8wqcyMDE4LTAxLTE4IDEwOjU5OjAxfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM4LjgyfGwvbWluwqcyMDE4LTAxLTE4IDEwOjU5OjAxfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTYuMzF8V2jCpzIwMTgtMDEtMTggMTA6NTk6MDF8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8Mzc5ODh8V8KnMjAxOC0wMS0xOCAxMDo1OTowMXxSRV9URU1QX0hWX1ZMMnxEVU1NWXx8dGVtcGVyYXR1cmV8NzYuNTYyfMKnMjAxOC0wMS0xOCAxMDo1OTowMXxSRV9URU1QX1BTMzAwMF8wMnxEVU1NWXx8dGVtcGVyYXR1cmV8MjYuMjV8wqcyMDE4LTAxLTE4IDEwOjU5OjAyfFJFX1RFTVBfUFMzMDAwXzEwfERVTU1ZfHx0ZW1wZXJhdHVyZXwzNy4zMXzCpzIwMTgtMDEtMTggMTA6NTk6MDJ8UkVfVEVNUF9QUzMwMDBfMDV8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjA2fMKnMjAxOC0wMS0xOCAxMDo1OTowM3xLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHx0b3RhbHw5OTYuMjk0fG3CpzIwMTgtMDEtMTggMTA6NTk6MDN8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzguNjJ8bC9taW7CpzIwMTgtMDEtMTggMTA6NTk6MDN8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxNi4zMXxXaMKnMjAxOC0wMS0xOCAxMDo1OTowM3xLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnwzNzc5M3xXwqcyMDE4LTAxLTE4IDEwOjU5OjAzfERfV01aX0hlaXp1bmdfbWFpbnxEVU1NWXx8cG93ZXJ8Nzc1OCBXfMKnMjAxOC0wMS0xOCAxMDo1OTowM3xEX1dNWl9IZWl6dW5nX21haW58RFVNTVl8fHdvcmt8MTY4MC44NCBXaHzCpzIwMTgtMDEtMTggMTA6NTk6MDN8UkVfVEVNUF9QUzMwMDBfMDZ8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjU2fMKnMjAxOC0wMS0xOCAxMDo1OTowM3xLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsaXRlcnByb21pbnwxOS4yM3xsL21pbsKnMjAxOC0wMS0xOCAxMDo1OTowM3xLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsYXN0bGl0ZXJ3b3JrfDYuNjd8V2jCpzIwMTgtMDEtMTggMTA6NTk6MDN8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8cG93ZXJ8NzY5NnxXwqcyMDE4LTAxLTE4IDEwOjU5OjA0fFJFX1RFTVBfUFMzMDAwXzExfERVTU1ZfHx0ZW1wZXJhdHVyZXw2Ny4yNXzCpzIwMTgtMDEtMTggMTA6NTk6MDR8S05YMTAxLkkwMV9CV01fR2FyYWdlX1dIR19IZWxsaWdrZWl0fEtOWHx8c3RhdGV8ODkuODR8bHV4wqcyMDE4LTAxLTE4IDEwOjU5OjA0fFJFX1RFTVBfUFMzMDAwXzA0fERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi4xMnzCpzIwMTgtMDEtMTggMTA6NTk6MDR8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzguNjJ8bC9taW7CpzIwMTgtMDEtMTggMTA6NTk6MDR8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxNi4zMXxXaMKnMjAxOC0wMS0xOCAxMDo1OTowNHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnwzNzc5M3xXwqcyMDE4LTAxLTE4IDEwOjU5OjA1fFJFX1RFTVBfUFMzMDAwXzAxfERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi4xOXzCpzIwMTgtMDEtMTggMTA6NTk6MDV8UkVfVEVNUF9QUzMwMDBfMDl8RFVNTVl8fHRlbXBlcmF0dXJlfDI4LjgxfMKnMjAxOC0wMS0xOCAxMDo1OTowNXxLTlgxMDEuSTAxX0JXTV9HYXJhZ2VfV0hHX0hlbGxpZ2tlaXR8S05YfHxzdGF0ZXwxMDIuOTZ8bHV4wqcyMDE4LTAxLTE4IDEwOjU5OjA2fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM4LjYyfGwvbWluwqcyMDE4LTAxLTE4IDEwOjU5OjA2fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MTYuMzF8V2jCpzIwMTgtMDEtMTggMTA6NTk6MDZ8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8Mzc3OTN8V8KnMjAxOC0wMS0xOCAxMDo1OTowNnxSRV9URU1QX1BTMzAwMF8wOHxEVU1NWXx8dGVtcGVyYXR1cmV8MjYuODd8wqcyMDE4LTAxLTE4IDEwOjU5OjA2fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxpdGVycHJvbWlufDE5LjIzfGwvbWluwqcyMDE4LTAxLTE4IDEwOjU5OjA2fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxhc3RsaXRlcndvcmt8Ni42N3xXaMKnMjAxOC0wMS0xOCAxMDo1OTowNnxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxwb3dlcnw3Njk2fFfCpzIwMTgtMDEtMTggMTA6NTk6MDZ8UkVfVEVNUF9TcGVpY2hlcl8wMnxEVU1NWXx8dGVtcGVyYXR1cmV8MjYuMTl8wqcyMDE4LTAxLTE4IDEwOjU5OjA3fFJFX1RFTVBfU3BlaWNoZXJfMDh8RFVNTVl8fHRlbXBlcmF0dXJlfDY0LjEyfMKnMjAxOC0wMS0xOCAxMDo1OTowN3xTdHJvbXphZWhsZXJ8Vlp8fHRvdGFsX3Bvd2VyfDEwNTh8wqcyMDE4LTAxLTE4IDEwOjU5OjA3fFN0cm9temFlaGxlcnxWWnx8dG90YWxfcG93ZXJfTDF8NjU2fMKnMjAxOC0wMS0xOCAxMDo1OTowN3xLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHx0b3RhbHw5OTYuMjk3fG3CpzIwMTgtMDEtMTggMTA6NTk6MDd8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzguNjJ8bC9taW7CpzIwMTgtMDEtMTggMTA6NTk6MDd8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wxNi4zMXxXaMKnMjAxOC0wMS0xOCAxMDo1OTowN3xLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnwzNzc5M3xXwqcyMDE4LTAxLTE4IDEwOjU5OjA3fEtOWDEwMC5JMDFfQldNX0ZsdXJfRUdfSGVsbGlna2VpdHxLTlh8fHN0YXRlfDIzOS41MnxsdXjCpzIwMTgtMDEtMTggMTA6NTk6MDh8UkVfVEVNUF9TcGVpY2hlcl8xMHxEVU1NWXx8dGVtcGVyYXR1cmV8NjQuMzF8wqcyMDE4LTAxLTE4IDEwOjU5OjA4fFJFX1RFTVBfU3BlaWNoZXJfMDR8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjE5fMKnMjAxOC0wMS0xOCAxMDo1OTowOHxTdHJvbXphZWhsZXJ8Vlp8fHRvdGFsX3Bvd2VyX0wxfDU5NnzCpzIwMTgtMDEtMTggMTA6NTk6MDh8U3Ryb216YWVobGVyfFZafHx0b3RhbF9wb3dlcnw5OTl8wqcyMDE4LTAxLTE4IDEwOjU5OjA5fFJFX1RFTVBfU3BlaWNoZXJfMDN8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjMxfMKnMjAxOC0wMS0xOCAxMDo1OTowOXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzOC42MnxsL21pbsKnMjAxOC0wMS0xOCAxMDo1OTowOXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE2LjMxfFdowqcyMDE4LTAxLTE4IDEwOjU5OjA5fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDM3NzkzfFfCpzIwMTgtMDEtMTggMTA6NTk6MDl8UkVfVEVNUF9TcGVpY2hlcl8wMXxEVU1NWXx8dGVtcGVyYXR1cmV8MjYuMDB8wqcyMDE4LTAxLTE4IDEwOjU5OjA5fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxpdGVycHJvbWlufDE5LjIyfGwvbWluwqcyMDE4LTAxLTE4IDEwOjU5OjA5fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxhc3RsaXRlcndvcmt8Ni42N3xXaMKnMjAxOC0wMS0xOCAxMDo1OTowOXxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxwb3dlcnw3NjkyfFfCpzIwMTgtMDEtMTggMTA6NTk6MTB8UkVfVEVNUF9TcGVpY2hlcl8wN3xEVU1NWXx8dGVtcGVyYXR1cmV8NDkuNjl8wqcyMDE4LTAxLTE4IDEwOjU5OjEwfFJFX1RFTVBfU3BlaWNoZXJfMDl8RFVNTVl8fHRlbXBlcmF0dXJlfDY2LjQ0fMKnMjAxOC0wMS0xOCAxMDo1OToxMHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzOC42MnxsL21pbsKnMjAxOC0wMS0xOCAxMDo1OToxMHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDE2LjMxfFdowqcyMDE4LTAxLTE4IDEwOjU5OjEwfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDM3NzkzfFfCpzIwMTgtMDEtMTggMTA6NTk6MTF8UkVfVEVNUF9TcGVpY2hlcl8wNnxEVU1NWXx8dGVtcGVyYXR1cmV8MzMuMDZ8wqcyMDE4LTAxLTE4IDEwOjU5OjExfFJFX1RFTVBfSFZfUkxBMnxEVU1NWXx8dGVtcGVyYXR1cmV8NjIuNXzCpzIwMTgtMDEtMTggMTA6NTk6MTF8UkVfVEVNUF9TcGVpY2hlcl8wNXxEVU1NWXx8dGVtcGVyYXR1cmV8MjYuMTJ8wqcyMDE4LTAxLTE4IDEwOjU5OjEyfFJFX1RFTVBfVm9ybGF1Zl9TY2h3aW1tYmFkfERVTU1ZfHx0ZW1wZXJhdHVyZXwyMC41Nnw= Timeout:86400 ConnectedVia:N/A
Pid:WAITING: Fn:PROPLANTA_Run Arg:wetter_prop Timeout:120 ConnectedVia:N/A
Daraufhin habe ich folgende Meldung im Log gefunden:
2018.01.18 12:00:01.365 1: PROPLANTA wetter_prop: Start.608 Could not start forked process, old process still running
2018.01.18 12:03:23.947 5: DbLog logdb -> Number of cache entries reached cachelimit 1000 - start database sync.
2018.01.18 12:03:24.254 5: DbLog logdb -> Number of cache entries reached cachelimit 1000 - start database sync.
2018.01.18 12:03:24.285 5: DbLog logdb -> Number of cache entries reached cachelimit 1000 - start database sync.
2018.01.18 12:03:24.315 5: DbLog logdb -> Number of cache entries reached cachelimit 1000 - start database sync.
2018.01.18 12:03:24.487 5: DbLog logdb -> Number of cache entries reached cachelimit 1000 - start database sync.
2018.01.18 12:03:25.041 5: DbLog logdb -> Number of cache entries reached cachelimit 1000 - start database sync.
jetzt bleibt mir wohl nur noch der restart bzw. reboot.
Was ich auch schon hatte, war die Meldung "could not fork, out of memory" oder so. Allerdings gerade im Moment nicht.
Ich hab wirklich keine Ahnung, nach was ich jetzt noch suchen soll. PRESENCE hab ich deaktiviert, jetzt tritt das Problem halt mit PROPLANTA auf.
Aber ich kann doch jetzt nicht *alle* Module deaktivieren ...
Grüße Stephan
Zitat von: abc2006 am 07 Januar 2018, 19:03:34
1. Bei einem Shutdown werden die noch gecachten Daten in die Datenbank geschrieben, richtig?
Zitat von: DS_Starter am 07 Januar 2018, 19:17:29
Nabend Stephan,
Ja, du solltest dir aber das Attribut "shutdownWait" auf z.B. 2 (Sekunden) setzen damit der DB Zeit für den Sync bleibt.
Was passiert denn, wenn ich jetzt ein shutdown restart mache? Werden die Daten exportiert, weil die Datenbank nicht verfügbar ist, oder gehen die verloren?
so schnell kann ich ja gar nicht exportcache und shutdown machen, ohne dass da wieder was aufläuft. Okay, ich kanns in einem Befehl schicken, das minimiert die Zeit...
Grüße,
Stephan
Hallo Stephan,
so wie es aussieht hast du aber kein Problem mit der Datenbank, sondern mit den Hintergrundprozessen.
Wie steht denn blockingCallMax in global jetzt ?
ZitatWas passiert denn, wenn ich jetzt ein shutdown restart mache? Werden die Daten exportiert, weil die Datenbank nicht verfügbar ist, oder gehen die verloren?
Wahrscheinlich gehen die verloren wenn deine Prozesssituation so ist wie sie sich darstellt.
Solange du so ein generelles Problem hast und es nicht in den Griff bekommst, würde ich DbLog im synchronen Modus betreiben.
Das bringt nichts sich dermaßen damit abzuquälen, wenn es nicht machbar ist.
Grüße
Heiko
Hi,
blockingCalls sollten nicht das Problem sein.
attr global blockingCallMax 10ZitatDas bringt nichts sich dermaßen damit abzuquälen, wenn es nicht machbar ist.
Hm. einen Versuch ist es Wert. Aber ich will nicht verstehen, dass es *nur* bei mir nicht läuft...
Grüße,
Stephan
ZitatblockingCalls sollten nicht das Problem sein.
Ja, aber die PID's stehen alle auf "Waiting". Worauf ?
Zum Beispiel steht PROPLANTA mit einem Timeout von 120s drin. Wird denn der nach 120s auch beendet ?
Im DbLog könntest du den timeout Wert im Attribut "timeout" auch auf 60 Sekunden setzen. Dann wird der Prozess nach 60s abgebrochen wenn er noch laufen sollte.
Kannst du mal probieren, aber normal ist das nicht was bei dir passiert wie ich finde.
Zitat von: abc2006 am 18 Januar 2018, 12:41:33
blockingCalls sollten nicht das Problem sein.
Okay, ungenau ausgedrückt. Die Anzahl der laufenden blockingCalls sollte nicht das Problem sein.
ZitatJa, aber die PID's stehen alle auf "Waiting". Worauf ?
das habe ich mich allerdings auch gefragt. Leider bin ich nicht in der Lage, den Grund dafür herauszufinden - ich weiss nicht, wie.
Da keine PID vorhanden ist, weiss ich auch nicht, ob(wie) man die laufenden BlockingCalls beenden kann.
ZitatZum Beispiel steht PROPLANTA mit einem Timeout von 120s drin. Wird denn der nach 120s auch beendet ?
Weiss ich nicht. Aufgrund der Tatsache, dass er keine PID hat, kann ich nicht nachvollziehen, ob er abgebrochen und wieder gestartet wurde, oder ob er *immer noch* läuft...
ZitatIm DbLog könntest du den timeout Wert im Attribut "timeout" auch auf 60 Sekunden setzen. Dann wird der Prozess nach 60s abgebrochen wenn er noch laufen sollte.
Hilft das gegen mein Problem? Würde ein neuer fork die Verbindung zur Datenbank wieder aufnehmen? (ich werds versuchen, wenns das nächste mal auftritt... )
Danke,
Stephan
ZitatWeiss ich nicht. Aufgrund der Tatsache, dass er keine PID hat, kann ich nicht nachvollziehen, ob er abgebrochen und wieder gestartet wurde, oder ob er *immer noch* läuft...
Damit meinte ich ob Proplanta einen Logeintrag schmeißt wenn der Prozess in einen Timeout läuft.
In DbLog habe ich es so programmiert. Du bekommst auf jeden Fall einen Log-Eintrag wenn der Prozess abbricht/tot ist.
ZitatHilft das gegen mein Problem?
Jein. Es hilft dabei herauszufinden ob es überhaupt einen Abbruch nach Ablauf des timeout gibt oder ob die PID bis zum Nimmerleinstag auf "Waiting" stehen bleiben.
ZitatWürde ein neuer fork die Verbindung zur Datenbank wieder aufnehmen?
Ja, allerdings wären die Daten, die dem mit timeout abgebrochenen Prozess übergeben wurden, weg.
Ich habe jetzt mal in Blocking.pm reingeschaut.
Alle PID, die über BlockingCall eröffnet werden, erhalten zunächst "Waiting" als PID und werden dann der Abarbeitung über BlockingStart zugeführt. Es werden aber nur soviele gleichzeitig abgearbeitet wie blockingCallMax es zulässt.
Dann wird zeitgesteuert alle 5 s die Schleife neu durchlaufen. Das heißt für mich, dass bei dir diese Abarbeitungsschleife wahrscheinlich irgendwie zum Erliegen kommt. Wie/warum kann ich momentan auch nicht einschätzen.
Als ersten Schritt würde ich blockingCallMax generell löschen und schauen wie es damit dann aussieht.
ZitatAls ersten Schritt würde ich blockingCallMax generell löschen und schauen wie es damit dann aussieht.
Wird gemacht.
Grüße,
Stephan
So.
Problem tritt wieder auf.
list logdb:
Internals:
COLUMNS field length used for Device: 64, Type: 64, Event: 0, Reading: 64, Value: 128, Unit: 32
CONFIGURATION ./db_fhem.conf
DEF ./db_fhem.conf .*:.*
MODE asynchronous
MODEL MYSQL
NAME logdb
NR 311
NTFY_ORDER 50-logdb
PID 2243
REGEXP .*:.*
STATE Commit already running - resync at NextSync
TYPE DbLog
UTF8 1
VERSION 3.6.2
dbconn mysql:database=fhem;host=localhost;port=3306
dbuser fhemuser
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 0
OLDSTATE Commit already running - resync at NextSync
READINGCOL 64
TYPECOL 64
UNITCOL 32
VALUECOL 128
READINGS:
2018-01-20 18:08:47 CacheUsage 475
2018-01-20 18:08:47 NextSync 2018-01-20 18:09:17 or if CacheUsage 100 reached
2018-01-20 18:07:33 lastCachefile ./log/cache_logdb_2018-01-20_16-42-33 (2010 cache rows exported)
2018-01-20 18:08:47 state Commit already running - resync at NextSync
cache:
index 475
Attributes:
DbLogSelectionMode Include
DbLogType History
asyncMode 1
cacheEvents 2
cacheLimit 100
colEvent 0
exportCacheAppend 1
room Logging
syncInterval 30
timeout 300
useCharfilter 1
userReadings DbFileSize:lastReduceLogResult.* { (split(' ',`du -m fhem.db`))[0] }
verbose 5
blockinginfo:
Pid:WAITING: Fn:PROPLANTA_Run Arg:wetter_prop Timeout:120 ConnectedVia:N/A
Pid:WAITING: Fn:DbLog_PushAsync Arg:logdb|MjAxOC0wMS0yMCAxNjozMjo1OHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsaXRlcnByb21pbnwxOS4xM3xsL21pbsKnMjAxOC0wMS0yMCAxNjozMjo1OHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsYXN0bGl0ZXJ3b3JrfDUuNjV8V2jCpzIwMTgtMDEtMjAgMTY6MzI6NTh8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8cG93ZXJ8NjQ4NHxXwqcyMDE4LTAxLTIwIDE2OjMyOjU4fEtOWDEwMS5JMDFfQldNX0dhcmFnZV9XSEdfSGVsbGlna2VpdHxLTlh8fHN0YXRlfDg1Ljc2fGx1eMKnMjAxOC0wMS0yMCAxNjozMjo1OHxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHx0b3RhbHwxMDMwLjUyNXxtwqcyMDE4LTAxLTIwIDE2OjMyOjU4fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM4LjM4fGwvbWluwqcyMDE4LTAxLTIwIDE2OjMyOjU4fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MjAuMDF8V2jCpzIwMTgtMDEtMjAgMTY6MzI6NTh8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8NDYwNzl8V8KnMjAxOC0wMS0yMCAxNjozMjo1OHxSRV9URU1QX0hWX1JMQTJ8RFVNTVl8fHRlbXBlcmF0dXJlfDYzLjA2MnzCpzIwMTgtMDEtMjAgMTY6MzI6NTh8UkVfVEVNUF9QUzMwMDBfMDV8RFVNTVl8fHRlbXBlcmF0dXJlfDI1LjI1fMKnMjAxOC0wMS0yMCAxNjozMjo1OHxSRV9URU1QX0JSVHxEVU1NWXx8dGVtcGVyYXR1cmV8ODMxLjc1fMKnMjAxOC0wMS0yMCAxNjozMjo1OXxLTlgxMDEuSTAxX0JXTV9HYXJhZ2VfV0hHX0hlbGxpZ2tlaXR8S05YfHxzdGF0ZXw5OC44OHxsdXjCpzIwMTgtMDEtMjAgMTY6MzI6NTl8UkVfVEVNUF9QUzMwMDBfMDZ8RFVNTVl8fHRlbXBlcmF0dXJlfDI1LjU2fMKnMjAxOC0wMS0yMCAxNjozMjo1OXxSRV9URU1QX1BTMzAwMF8xMXxEVU1NWXx8dGVtcGVyYXR1cmV8NjkuODF8wqcyMDE4LTAxLTIwIDE2OjMzOjAwfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM4LjM4fGwvbWluwqcyMDE4LTAxLTIwIDE2OjMzOjAwfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MjAuMDF8V2jCpzIwMTgtMDEtMjAgMTY6MzM6MDB8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8NDYwNzl8V8KnMjAxOC0wMS0yMCAxNjozMzowMHxSRV9URU1QX0hWX1ZMMnxEVU1NWXx8dGVtcGVyYXR1cmV8ODAuMzEyfMKnMjAxOC0wMS0yMCAxNjozMzowMHxSRV9URU1QX0JSVHxEVU1NWXx8dGVtcGVyYXR1cmV8ODI4LjI1fMKnMjAxOC0wMS0yMCAxNjozMzowMHxSRV9URU1QX1BTMzAwMF8wNHxEVU1NWXx8dGVtcGVyYXR1cmV8MjUuNTZ8wqcyMDE4LTAxLTIwIDE2OjMzOjAwfFJFX1RFTVBfQlJUfERVTU1ZfHx0ZW1wZXJhdHVyZXw4MjkuMHzCpzIwMTgtMDEtMjAgMTY6MzM6MDB8UkVfVEVNUF9QUzMwMDBfMDF8RFVNTVl8fHRlbXBlcmF0dXJlfDI1LjU2fMKnMjAxOC0wMS0yMCAxNjozMzowMXxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsaXRlcnByb21pbnwxOS4wNHxsL21pbsKnMjAxOC0wMS0yMCAxNjozMzowMXxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsYXN0bGl0ZXJ3b3JrfDUuNjV8V2jCpzIwMTgtMDEtMjAgMTY6MzM6MDF8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8cG93ZXJ8NjQ1NHxXwqcyMDE4LTAxLTIwIDE2OjMzOjAxfFJFX1RFTVBfQlJUfERVTU1ZfHx0ZW1wZXJhdHVyZXw4MzAuNzV8wqcyMDE4LTAxLTIwIDE2OjMzOjAxfFJFX1RFTVBfUFMzMDAwXzA5fERVTU1ZfHx0ZW1wZXJhdHVyZXwyNS42OXzCpzIwMTgtMDEtMjAgMTY6MzM6MDF8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGl0ZXJwcm9taW58MzguMzh8bC9taW7CpzIwMTgtMDEtMjAgMTY6MzM6MDF8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8bGFzdGxpdGVyd29ya3wyMC4wMXxXaMKnMjAxOC0wMS0yMCAxNjozMzowMXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxwb3dlcnw0NjA3OXxXwqcyMDE4LTAxLTIwIDE2OjMzOjAyfFJFX1RFTVBfUFMzMDAwXzA4fERVTU1ZfHx0ZW1wZXJhdHVyZXwyNS42OXzCpzIwMTgtMDEtMjAgMTY6MzM6MDJ8UkVfVEVNUF9CUlR8RFVNTVl8fHRlbXBlcmF0dXJlfDgzMC4wfMKnMjAxOC0wMS0yMCAxNjozMzowMnxSRV9URU1QX1NwZWljaGVyXzAyfERVTU1ZfHx0ZW1wZXJhdHVyZXwyNC41NnzCpzIwMTgtMDEtMjAgMTY6MzM6MDN8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8dG90YWx8MTAzMC41Mjh8bcKnMjAxOC0wMS0yMCAxNjozMzowM3xLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzOC4zOHxsL21pbsKnMjAxOC0wMS0yMCAxNjozMzowM3xLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDIwLjAxfFdowqcyMDE4LTAxLTIwIDE2OjMzOjAzfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDQ2MDc5fFfCpzIwMTgtMDEtMjAgMTY6MzM6MDN8UkVfVEVNUF9TcGVpY2hlcl8wOHxEVU1NWXx8dGVtcGVyYXR1cmV8NjUuMTJ8wqcyMDE4LTAxLTIwIDE2OjMzOjAzfFJFX1RFTVBfQlJUfERVTU1ZfHx0ZW1wZXJhdHVyZXw4MzAuMjV8wqcyMDE4LTAxLTIwIDE2OjMzOjAzfFBJRC5GVUJPfFBJRDIwfHxkZXNpcmVkfDI5Ljh8wqcyMDE4LTAxLTIwIDE2OjMzOjAzfFBJRC5GVUJPfFBJRDIwfHxtZWFzdXJlZHwzMS41NnzCpzIwMTgtMDEtMjAgMTY6MzM6MDN8UElELkZVQk98UElEMjB8fHBfcHwtNzkxLjk5OTk5OTk5OTk5OXzCpzIwMTgtMDEtMjAgMTY6MzM6MDN8UElELkZVQk98UElEMjB8fHBfZHwxNjM2LjU3NTk4MTY0NzA5fMKnMjAxOC0wMS0yMCAxNjozMzowM3xQSUQuRlVCT3xQSUQyMHx8cF9pfC0zNzIuN3zCpzIwMTgtMDEtMjAgMTY6MzM6MDN8UElELkZVQk98UElEMjB8fGFjdHVhdGlvbnw0NzJ8wqcyMDE4LTAxLTIwIDE2OjMzOjAzfFBJRC5GVUJPfFBJRDIwfHxhY3R1YXRpb25DYWxjfDQ3MS44NzU5ODE2NDcwOXzCpzIwMTgtMDEtMjAgMTY6MzM6MDN8UkVfVEVNUF9TcGVpY2hlcl8xMHxEVU1NWXx8dGVtcGVyYXR1cmV8NjUuNjJ8wqcyMDE4LTAxLTIwIDE2OjMzOjA0fFJFX1RFTVBfU3BlaWNoZXJfMDR8RFVNTVl8fHRlbXBlcmF0dXJlfDI0LjUwfMKnMjAxOC0wMS0yMCAxNjozMzowNHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsaXRlcnByb21pbnwxOS4wNXxsL21pbsKnMjAxOC0wMS0yMCAxNjozMzowNHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsYXN0bGl0ZXJ3b3JrfDUuNjV8V2jCpzIwMTgtMDEtMjAgMTY6MzM6MDR8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8cG93ZXJ8NjQ1N3xXwqcyMDE4LTAxLTIwIDE2OjMzOjA0fFJFX1RFTVBfQlJUfERVTU1ZfHx0ZW1wZXJhdHVyZXw4MjkuNzV8wqcyMDE4LTAxLTIwIDE2OjMzOjA0fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM4LjM4fGwvbWluwqcyMDE4LTAxLTIwIDE2OjMzOjA0fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MjAuMDF8V2jCpzIwMTgtMDEtMjAgMTY6MzM6MDR8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8NDYwNzl8V8KnMjAxOC0wMS0yMCAxNjozMzowNHxSRV9URU1QX1NwZWljaGVyXzAzfERVTU1ZfHx0ZW1wZXJhdHVyZXwyNC41MHzCpzIwMTgtMDEtMjAgMTY6MzM6MDV8UkVfVEVNUF9TcGVpY2hlcl8wMXxEVU1NWXx8dGVtcGVyYXR1cmV8MjQuMzd8wqcyMDE4LTAxLTIwIDE2OjMzOjA1fFJFX1RFTVBfQlJUfERVTU1ZfHx0ZW1wZXJhdHVyZXw4MzAuMHzCpzIwMTgtMDEtMjAgMTY6MzM6MDV8S05YMTAxLkkwMV9CV01fR2FyYWdlX1dIR19IZWxsaWdrZWl0fEtOWHx8c3RhdGV8ODYuODB8bHV4wqcyMDE4LTAxLTIwIDE2OjMzOjA1fFJFX1RFTVBfU3BlaWNoZXJfMDd8RFVNTVl8fHRlbXBlcmF0dXJlfDU0LjgxfMKnMjAxOC0wMS0yMCAxNjozMzowNnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzOC4zOHxsL21pbsKnMjAxOC0wMS0yMCAxNjozMzowNnxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDIwLjAxfFdowqcyMDE4LTAxLTIwIDE2OjMzOjA2fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDQ2MDc5fFfCpzIwMTgtMDEtMjAgMTY6MzM6MDZ8UkVfVEVNUF9CUlR8RFVNTVl8fHRlbXBlcmF0dXJlfDgyOS43NXzCpzIwMTgtMDEtMjAgMTY6MzM6MDZ8UkVfVEVNUF9TcGVpY2hlcl8wOXxEVU1NWXx8dGVtcGVyYXR1cmV8NjguMDZ8wqcyMDE4LTAxLTIwIDE2OjMzOjA3fFJFX1RFTVBfU3BlaWNoZXJfMDZ8RFVNTVl8fHRlbXBlcmF0dXJlfDQ0LjU2fMKnMjAxOC0wMS0yMCAxNjozMzowN3xLTlgxMDEuSTAxX0JXTV9HYXJhZ2VfV0hHX0hlbGxpZ2tlaXR8S05YfHxzdGF0ZXw5OC4wMHxsdXjCpzIwMTgtMDEtMjAgMTY6MzM6MDd8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGl0ZXJwcm9taW58MTkuMTJ8bC9taW7CpzIwMTgtMDEtMjAgMTY6MzM6MDd8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGFzdGxpdGVyd29ya3w1LjY1fFdowqcyMDE4LTAxLTIwIDE2OjMzOjA3fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fHBvd2VyfDY0ODF8V8KnMjAxOC0wMS0yMCAxNjozMzowN3xSRV9URU1QX0JSVHxEVU1NWXx8dGVtcGVyYXR1cmV8ODI5LjI1fMKnMjAxOC0wMS0yMCAxNjozMzowN3xSRV9URU1QX1NwZWljaGVyXzA1fERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi4zMXzCpzIwMTgtMDEtMjAgMTY6MzM6MDd8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8dG90YWx8MTAzMC41MzF8bcKnMjAxOC0wMS0yMCAxNjozMzowN3xLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzOC4zN3xsL21pbsKnMjAxOC0wMS0yMCAxNjozMzowN3xLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDIwLjAxfFdowqcyMDE4LTAxLTIwIDE2OjMzOjA3fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDQ2MDY3fFfCpzIwMTgtMDEtMjAgMTY6MzM6MDh8UkVfVEVNUF9Wb3JsYXVmX1NjaHdpbW1iYWR8RFVNTVl8fHRlbXBlcmF0dXJlfDIxLjA2fMKnMjAxOC0wMS0yMCAxNjozMzowOHxSRV9URU1QX0JSVHxEVU1NWXx8dGVtcGVyYXR1cmV8ODI5LjI1fMKnMjAxOC0wMS0yMCAxNjozMzowOHxSRV9URU1QX1J1ZWNrbGF1Zl9Tb2xhcnxEVU1NWXx8dGVtcGVyYXR1cmV8MjIuMTJ8wqcyMDE4LTAxLTIwIDE2OjMzOjA5fFJFX1RFTVBfVm9ybGF1Zl9FR19Cb2RlbnxEVU1NWXx8dGVtcGVyYXR1cmV8MjkuNDR8wqcyMDE4LTAxLTIwIDE2OjMzOjA5fFJFX1RFTVBfSFZfUkxBMnxEVU1NWXx8dGVtcGVyYXR1cmV8NjN8wqcyMDE4LTAxLTIwIDE2OjMzOjA5fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxpdGVycHJvbWlufDM4LjM3fGwvbWluwqcyMDE4LTAxLTIwIDE2OjMzOjA5fEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fGxhc3RsaXRlcndvcmt8MjAuMDh8V2jCpzIwMTgtMDEtMjAgMTY6MzM6MDl8S05YMTAuSTA1X1phZWhsZXJfSG9senZlcmdhc2VyfEtOWHx8cG93ZXJ8NDYyMjd8V8KnMjAxOC0wMS0yMCAxNjozMzowOXxSRV9URU1QX0JSVHxEVU1NWXx8dGVtcGVyYXR1cmV8ODI4Ljc1fMKnMjAxOC0wMS0yMCAxNjozMzoxMHxSRV9URU1QX1J1ZWNrbGF1Zl9FR19Cb2RlbnxEVU1NWXx8dGVtcGVyYXR1cmV8MjQuNjl8wqcyMDE4LTAxLTIwIDE2OjMzOjEwfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxpdGVycHJvbWlufDE5LjExfGwvbWluwqcyMDE4LTAxLTIwIDE2OjMzOjEwfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxhc3RsaXRlcndvcmt8NS42NXxXaMKnMjAxOC0wMS0yMCAxNjozMzoxMHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxwb3dlcnw2NDc3fFfCpzIwMTgtMDEtMjAgMTY6MzM6MTB8UkVfVEVNUF9SdWVja2xhdWZfV1RfRUd8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjMxfMKnMjAxOC0wMS0yMCAxNjozMzoxMXxSRV9URU1QX0hWX1ZMMnxEVU1NWXx8dGVtcGVyYXR1cmV8ODAuMzEyfMKnMjAxOC0wMS0yMCAxNjozMzoxMXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsaXRlcnByb21pbnwzOC4zN3xsL21pbsKnMjAxOC0wMS0yMCAxNjozMzoxMXxLTlgxMC5JMDVfWmFlaGxlcl9Ib2x6dmVyZ2FzZXJ8S05YfHxsYXN0bGl0ZXJ3b3JrfDIwLjA4fFdowqcyMDE4LTAxLTIwIDE2OjMzOjExfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHBvd2VyfDQ2MjI3fFfCpzIwMTgtMDEtMjAgMTY6MzM6MTF8UkVfVEVNUF9CUlR8RFVNTVl8fHRlbXBlcmF0dXJlfDgyNi4wfMKnMjAxOC0wMS0yMCAxNjozMzoxMXxSRV9URU1QX1ZvcmxhdWZfU29sYXJ8RFVNTVl8fHRlbXBlcmF0dXJlfDIwLjk0fMKnMjAxOC0wMS0yMCAxNjozMzoxMXxSRV9URU1QX0JSVHxEVU1NWXx8dGVtcGVyYXR1cmV8ODI3LjV8wqcyMDE4LTAxLTIwIDE2OjMzOjEyfFJFX1RFTVBfUnVlY2tsYXVmSEt8RFVNTVl8fHRlbXBlcmF0dXJlfDI2LjY5fMKnMjAxOC0wMS0yMCAxNjozMzoxMnxSRV9URU1QX1ZvcmxhdWZIS3xEVU1NWXx8dGVtcGVyYXR1cmV8MzEuNTB8wqcyMDE4LTAxLTIwIDE2OjMzOjEyfEtOWDEwLkkwNV9aYWVobGVyX0hvbHp2ZXJnYXNlcnxLTlh8fHRvdGFsfDEwMzAuNTM0fG0= Timeout:300 ConnectedVia:N/A
auch 300 sekunden später, keine Änderung:
[code] main::DBPlan_Parse_Timetable called by FHEM/HttpUtils.pm (576)
2018.01.20 18:06:33.000 1: main::__ANON__ called by fhem.pl (684)
2018.01.20 18:07:24.715 3: DBPlan_Set (NadineSbahnFFM_S2_freitagmittag) - interval timer set to inactive
2018.01.20 18:07:31.957 3: PID20 PID.FUBO: Calc.729 <set D_MischerPID -498>
2018.01.20 18:07:33.105 3: DbLog logdb: 2010 cache rows exported to ./log/cache_logdb_2018-01-20_16-42-33.
2018.01.20 18:07:33.133 3: DbLog logdb: Cache purged after exporting rows to ./log/cache_logdb_2018-01-20_16-42-33.
2018.01.20 18:07:39.744 1: RMDIR: ./restoreDir/2018-01-17
2018.01.20 18:07:39.796 3: N_backupCFG return value: -1
2018.01.20 18:08:32.247 3: PID20 PID.FUBO: Calc.729 <set D_MischerPID -562>
2018.01.20 18:09:13.177 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:13.205 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:13.232 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:13.354 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:13.437 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:13.846 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:14.021 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:14.468 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:14.587 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:14.737 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:14.765 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:14.792 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:14.842 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:15.128 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:15.579 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:15.707 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:15.878 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:15.905 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:15.932 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:16.237 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:16.304 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:16.331 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:16.359 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:16.387 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:16.499 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:16.848 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:17.392 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:17.575 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:17.852 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:17.879 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:17.907 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:18.023 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:18.567 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:18.647 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:19.050 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:19.078 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:19.105 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:19.216 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:19.399 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:19.427 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:19.454 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:19.535 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:19.759 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:20.303 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:20.532 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:20.847 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:20.969 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:20.996 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:21.024 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:21.052 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:21.391 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:21.485 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:21.945 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:22.018 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:22.209 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:22.236 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:22.262 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:22.478 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:22.541 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:22.570 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:22.597 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:22.678 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:23.022 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:23.566 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:24.081 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:24.109 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:24.136 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:24.211 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:24.294 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:24.375 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:24.653 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:24.740 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:25.198 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:25.385 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:25.414 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:25.441 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:25.519 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:25.642 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:25.670 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:25.698 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:25.725 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:25.839 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:26.384 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:26.509 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:26.926 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:27.193 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:27.222 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:27.250 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:27.525 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:28.015 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:28.500 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:28.582 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:28.609 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:28.636 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:28.709 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:28.773 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:28.801 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:28.829 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:29.159 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:29.509 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:29.704 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:30.248 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:30.314 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:30.342 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:30.370 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:30.397 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:30.489 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:30.928 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:31.461 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:31.535 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:31.712 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:31.739 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:31.767 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:31.871 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:31.899 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:31.927 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:32.040 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:32.450 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:32.535 3: PID20 PID.FUBO: Calc.729 <set D_MischerPID 211>
2018.01.20 18:09:32.617 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:32.644 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:32.672 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:32.699 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:32.726 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:32.754 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:32.781 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:32.922 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:32.991 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:33.061 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:33.139 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:33.218 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:33.292 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:33.374 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:33.402 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:33.473 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:33.540 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:33.619 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:33.685 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:33.713 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:33.740 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:33.855 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:34.399 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:34.868 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:34.895 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:34.922 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:34.989 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:35.017 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:35.045 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:35.073 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:35.147 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:35.231 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:35.311 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:35.576 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:35.655 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:36.134 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:36.507 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:36.572 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:36.600 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:36.628 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:36.749 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:37.299 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:37.508 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:37.903 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:38.029 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:38.056 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:38.084 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:38.147 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:38.175 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:38.202 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:38.446 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:38.527 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:38.990 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:39.534 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:39.616 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:39.682 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:39.709 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:39.737 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:39.764 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:40.076 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:40.549 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:40.665 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:41.208 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:41.236 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:41.266 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:41.327 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:41.355 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:41.382 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:41.453 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:41.584 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:41.758 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:42.296 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:42.781 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:42.810 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:42.837 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:42.951 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:43.343 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:43.424 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:43.540 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:43.807 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:43.859 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:43.886 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:44.084 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:44.196 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:44.223 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:44.335 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:44.363 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:44.391 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:44.418 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:44.499 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:44.526 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:44.553 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:44.631 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:44.745 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:45.289 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:45.832 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:45.895 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:45.922 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:45.949 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:46.057 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:46.142 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:46.378 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:46.456 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:46.483 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:46.561 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:46.967 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:47.412 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:47.442 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:47.521 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:47.584 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:47.611 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:47.638 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:47.719 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:47.749 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:47.777 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:47.844 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:47.895 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:47.921 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:48.033 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:48.507 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:48.623 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:49.016 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:49.044 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:49.072 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:49.099 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:49.213 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:49.517 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:49.758 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:50.301 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:50.507 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:50.577 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:50.606 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:50.635 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:50.719 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:50.747 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:50.775 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:50.885 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:51.578 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:51.862 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:51.972 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:52.127 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:52.155 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:52.182 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:52.496 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:52.567 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:53.060 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:53.604 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:53.691 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:53.718 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:53.746 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:53.773 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:53.875 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:53.902 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:53.930 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:54.015 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:54.151 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:54.238 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:54.319 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:54.674 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:54.830 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:55.274 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:55.300 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:55.325 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:55.435 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:55.513 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:55.980 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:56.523 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:56.803 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:56.830 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:56.856 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:56.948 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:57.044 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:57.070 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:57.097 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:57.164 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:57.416 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:57.495 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:57.611 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:58.157 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:58.359 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:58.385 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:58.411 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:58.436 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:58.514 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:58.698 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:59.244 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:59.394 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:59.419 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:59.508 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:59.797 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:59.910 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:59.936 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:09:59.961 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:00.041 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:00.205 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:00.231 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:00.258 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:00.376 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:00.461 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:00.539 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:00.924 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:01.470 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:01.504 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:01.549 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:01.602 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:01.679 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:01.748 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:02.071 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:02.535 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:02.648 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:03.023 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:03.048 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:03.074 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:03.099 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:03.213 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:03.375 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:03.402 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:03.428 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:03.538 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:03.755 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:04.299 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:04.584 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:04.612 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:04.638 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:04.842 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:05.091 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:05.169 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:05.385 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:05.535 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:05.929 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:06.141 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:06.167 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:06.192 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:06.467 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:06.545 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:06.570 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:06.597 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:06.666 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:07.020 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:07.560 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:07.705 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:07.732 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:07.758 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:07.785 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:07.871 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:08.139 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:08.283 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:08.486 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:08.647 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:09.193 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:09.257 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:09.283 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:09.308 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:09.514 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:09.702 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:09.727 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:09.752 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:09.861 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:10.403 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:10.516 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:10.809 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:10.835 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:10.860 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:10.974 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:11.299 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:11.519 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:11.588 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:12.060 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:12.373 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:12.399 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:12.425 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:12.450 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:12.531 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:12.643 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:12.852 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:12.876 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:12.901 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:13.190 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:13.570 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:13.731 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:13.930 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:13.956 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:13.981 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:14.277 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:14.577 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:14.626 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:14.651 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:15.306 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:15.375 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:15.494 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:15.521 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:15.547 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:15.626 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:15.651 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:15.906 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:15.989 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:16.067 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:16.092 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:16.117 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:16.192 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:16.452 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:16.534 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:16.993 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:17.057 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:17.083 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:17.109 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:17.134 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:17.542 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:17.624 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:18.219 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:18.609 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:18.636 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:18.663 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:18.747 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:18.860 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:19.168 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:19.245 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:19.270 5: DbLog logdb -> Number of cache entries reached cachelimit 100 - start database sync.
2018.01.20 18:10:19.295 5: DbLog logdb -> Number of cache entries reached cachelimit 100 -
Hallo Stephan,
ja, deine Blocking-Prozesse stehen wieder auf "Waiting". Da kann weder Proplanta, noch DbLog einen weiteren Call auslösen. In DbLog siehst du es ja am "Resync ....". Weiß nicht ob Proplanta ähnliche MItteilungen generiert.
Falls die Situation noch vorliegt, würde mich interessieren was passiert wenn du einen weiteren BlockingCall auslöst.
Am einfachsten geht das wenn du irgendeine Funktion in DbRep ausführst, welche ist egal.
EDIT: Kannst du mal schauen ob du Einträge im Log findest wie "BlockingCall ..... No telnet port found and cannot create one: ....." findest ?
Grüße,
Heiko
Hi,
Problem ist wieder da.
Ich hab eine Funktion in dbRep aufgerufen, die steht jetzt auch auf waiting:
Pid:WAITING: Fn:DbLog_PushAsync Arg:logdb|MjAxOC0wMS0yMiAyMDowMDowN3xSRV9URU1QX0JSVHxEVU1NWXx8dGVtcGVyYXR1cmV8ODEuNzV8wqcyMDE4LTAxLTIyIDIwOjAwOjA3fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxpdGVycHJvbWlufDE4LjkyfGwvbWluwqcyMDE4LTAxLTIyIDIwOjAwOjA3fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxhc3RsaXRlcndvcmt8My44NHxXaMKnMjAxOC0wMS0yMiAyMDowMDowN3xLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxwb3dlcnw0MzU5fFfCpzIwMTgtMDEtMjIgMjA6MDA6MDd8UkVfVEVNUF9CUlR8RFVNTVl8fHRlbXBlcmF0dXJlfDgxLjc1fMKnMjAxOC0wMS0yMiAyMDowMDowOHxSRV9URU1QX0FVU1NFTnxEVU1NWXx8dGVtcGVyYXR1cmV8NS42OXzCpzIwMTgtMDEtMjIgMjA6MDA6MDh8UkVfVEVNUF9CUlR8RFVNTVl8fHRlbXBlcmF0dXJlfDgxLjc1fMKnMjAxOC0wMS0yMiAyMDowMDowOHxSRV9URU1QX1ZvcmxhdWZfV1d8RFVNTVl8fHRlbXBlcmF0dXJlfDI0Ljc1fMKnMjAxOC0wMS0yMiAyMDowMDowOXxSRV9URU1QX1dXX0F1c2dhbmdfU3BlaWNoZXJ8RFVNTVl8fHRlbXBlcmF0dXJlfDQzLjM4fMKnMjAxOC0wMS0yMiAyMDowMDowOXxSRV9URU1QX0JSVHxEVU1NWXx8dGVtcGVyYXR1cmV8ODEuNXzCpzIwMTgtMDEtMjIgMjA6MDA6MDl8UkVfVEVNUF9SdWVja2xhdWZfS2Vzc2VsfERVTU1ZfHx0ZW1wZXJhdHVyZXwyMS41NnzCpzIwMTgtMDEtMjIgMjA6MDA6MTB8UkVfVEVNUF9SdWVja2xhdWZfWmlya3VsYXRpb258RFVNTVl8fHRlbXBlcmF0dXJlfDI0LjAwfMKnMjAxOC0wMS0yMiAyMDowMDoxMHxSRV9URU1QX0JSVHxEVU1NWXx8dGVtcGVyYXR1cmV8ODIuMHzCpzIwMTgtMDEtMjIgMjA6MDA6MTB8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGl0ZXJwcm9taW58MTguOTJ8bC9taW7CpzIwMTgtMDEtMjIgMjA6MDA6MTB8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGFzdGxpdGVyd29ya3wzLjg0fFdowqcyMDE4LTAxLTIyIDIwOjAwOjEwfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fHBvd2VyfDQzNTl8V8KnMjAxOC0wMS0yMiAyMDowMDoxMXxSRV9URU1QX0hWX1JMQXxEVU1NWXx8dGVtcGVyYXR1cmV8NjkuNjl8wqcyMDE4LTAxLTIyIDIwOjAwOjExfFJFX1RFTVBfQlJUfERVTU1ZfHx0ZW1wZXJhdHVyZXw4MS4wfMKnMjAxOC0wMS0yMiAyMDowMDoxMXxLTlgwMi5PMDVfU3Ryb213ZXJ0fEtOWHx8cG93ZXJ8MjEuODV8wqcyMDE4LTAxLTIyIDIwOjAwOjExfEtOWDAyLk8wNV9TdHJvbXdlcnR8S05YfHxjdXJyZW50fDAuMDk1fMKnMjAxOC0wMS0yMiAyMDowMDoxMXxSRV9URU1QX0hWX1JMfERVTU1ZfHx0ZW1wZXJhdHVyZXw1NS45NHzCpzIwMTgtMDEtMjIgMjA6MDA6MTJ8UkVfVEVNUF9IVl9WTHxEVU1NWXx8dGVtcGVyYXR1cmV8NzEuODF8wqcyMDE4LTAxLTIyIDIwOjAwOjEyfFN0cm9temFlaGxlcnxWWnx8dG90YWxfcG93ZXJ8NDE2fMKnMjAxOC0wMS0yMiAyMDowMDoxMnxSRV9URU1QX0JSVHxEVU1NWXx8dGVtcGVyYXR1cmV8ODIuMHzCpzIwMTgtMDEtMjIgMjA6MDA6MTN8UkVfVEVNUF9CUlR8RFVNTVl8fHRlbXBlcmF0dXJlfDgyLjB8wqcyMDE4LTAxLTIyIDIwOjAwOjEzfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxpdGVycHJvbWlufDE4Ljg1fGwvbWluwqcyMDE4LTAxLTIyIDIwOjAwOjEzfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxhc3RsaXRlcndvcmt8My44NHxXaMKnMjAxOC0wMS0yMiAyMDowMDoxM3xLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxwb3dlcnw0MzQzfFfCpzIwMTgtMDEtMjIgMjA6MDA6MTV8UkVfVEVNUF9IVl9STEEyfERVTU1ZfHx0ZW1wZXJhdHVyZXw3MC45Mzd8wqcyMDE4LTAxLTIyIDIwOjAwOjE1fFJFX1RFTVBfQlJUfERVTU1ZfHx0ZW1wZXJhdHVyZXw4MS43NXzCpzIwMTgtMDEtMjIgMjA6MDA6MTZ8UElELkZVQk98UElEMjB8fGRlc2lyZWR8MjkuN3zCpzIwMTgtMDEtMjIgMjA6MDA6MTZ8UElELkZVQk98UElEMjB8fG1lYXN1cmVkfDMwLjAwfMKnMjAxOC0wMS0yMiAyMDowMDoxNnxQSUQuRlVCT3xQSUQyMHx8cF9wfC0xMzV8wqcyMDE4LTAxLTIyIDIwOjAwOjE2fFBJRC5GVUJPfFBJRDIwfHxwX2R8MHzCpzIwMTgtMDEtMjIgMjA6MDA6MTZ8UElELkZVQk98UElEMjB8fHBfaXwtMjEuNDAwMDAwMDAwMDA2OHzCpzIwMTgtMDEtMjIgMjA6MDA6MTZ8UElELkZVQk98UElEMjB8fGFjdHVhdGlvbnwtMTU2fMKnMjAxOC0wMS0yMiAyMDowMDoxNnxQSUQuRlVCT3xQSUQyMHx8YWN0dWF0aW9uQ2FsY3wtMTU2LjQwMDAwMDAwMDAwN3zCpzIwMTgtMDEtMjIgMjA6MDA6MTZ8UkVfVEVNUF9IVl9WTDJ8RFVNTVl8fHRlbXBlcmF0dXJlfDczLjU2MnzCpzIwMTgtMDEtMjIgMjA6MDA6MTZ8UkVfVEVNUF9CUlR8RFVNTVl8fHRlbXBlcmF0dXJlfDgxLjI1fMKnMjAxOC0wMS0yMiAyMDowMDoxNnxSRV9URU1QX1BTMzAwMF8wM3xEVU1NWXx8dGVtcGVyYXR1cmV8MjcuNzV8wqcyMDE4LTAxLTIyIDIwOjAwOjE2fFJFX1RFTVBfQlJUfERVTU1ZfHx0ZW1wZXJhdHVyZXw4Mi4wfMKnMjAxOC0wMS0yMiAyMDowMDoxNnxSRV9URU1QX1BTMzAwMF8wN3xEVU1NWXx8dGVtcGVyYXR1cmV8NTUuNDR8wqcyMDE4LTAxLTIyIDIwOjAwOjE2fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxpdGVycHJvbWlufDE4Ljg2fGwvbWluwqcyMDE4LTAxLTIyIDIwOjAwOjE2fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxhc3RsaXRlcndvcmt8My44NHxXaMKnMjAxOC0wMS0yMiAyMDowMDoxNnxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxwb3dlcnw0MzQ1fFfCpzIwMTgtMDEtMjIgMjA6MDA6MTd8UkVfVEVNUF9CUlR8RFVNTVl8fHRlbXBlcmF0dXJlfDgyLjI1fMKnMjAxOC0wMS0yMiAyMDowMDoxN3xSRV9URU1QX1BTMzAwMF8wMnxEVU1NWXx8dGVtcGVyYXR1cmV8MjYuNzV8wqcyMDE4LTAxLTIyIDIwOjAwOjE3fFJFX1RFTVBfUFMzMDAwXzEwfERVTU1ZfHx0ZW1wZXJhdHVyZXw3NS4xOXzCpzIwMTgtMDEtMjIgMjA6MDA6MTh8UkVfVEVNUF9CUlR8RFVNTVl8fHRlbXBlcmF0dXJlfDgxLjV8wqcyMDE4LTAxLTIyIDIwOjAwOjE4fFJFX1RFTVBfUFMzMDAwXzA1fERVTU1ZfHx0ZW1wZXJhdHVyZXwzMi4zMXzCpzIwMTgtMDEtMjIgMjA6MDA6MTl8d2V0dGVyX3Byb3B8UFJPUExBTlRBfHxmYzBfcmFkfDAuNnzCpzIwMTgtMDEtMjIgMjA6MDA6MTl8d2V0dGVyX3Byb3B8UFJPUExBTlRBfHxmYzBfcHJnX2dlc3w2fMKnMjAxOC0wMS0yMiAyMDowMDoxOXxSRV9URU1QX1BTMzAwMF8wNnxEVU1NWXx8dGVtcGVyYXR1cmV8NDEuNTZ8wqcyMDE4LTAxLTIyIDIwOjAwOjE5fFN0cm9temFlaGxlcnxWWnx8dG90YWxfcG93ZXJ8Mzk1fMKnMjAxOC0wMS0yMiAyMDowMDoxOXxSRV9URU1QX0JSVHxEVU1NWXx8dGVtcGVyYXR1cmV8ODEuNXzCpzIwMTgtMDEtMjIgMjA6MDA6MTl8UkVfVEVNUF9QUzMwMDBfMTF8RFVNTVl8fHRlbXBlcmF0dXJlfDc0LjgxfMKnMjAxOC0wMS0yMiAyMDowMDoyMHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsaXRlcnByb21pbnwxOC45NnxsL21pbsKnMjAxOC0wMS0yMiAyMDowMDoyMHxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsYXN0bGl0ZXJ3b3JrfDMuODR8V2jCpzIwMTgtMDEtMjIgMjA6MDA6MjB8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8cG93ZXJ8NDM2OHxXwqcyMDE4LTAxLTIyIDIwOjAwOjIwfFJFX1RFTVBfUFMzMDAwXzA0fERVTU1ZfHx0ZW1wZXJhdHVyZXwyOS4wMHzCpzIwMTgtMDEtMjIgMjA6MDA6MjB8UkVfVEVNUF9CUlR8RFVNTVl8fHRlbXBlcmF0dXJlfDgxLjc1fMKnMjAxOC0wMS0yMiAyMDowMDoyMHxSRV9URU1QX1BTMzAwMF8wMXxEVU1NWXx8dGVtcGVyYXR1cmV8MjYuMDB8wqcyMDE4LTAxLTIyIDIwOjAwOjIxfFJFX1RFTVBfUFMzMDAwXzA5fERVTU1ZfHx0ZW1wZXJhdHVyZXw3NC44MXzCpzIwMTgtMDEtMjIgMjA6MDA6MjF8UkVfVEVNUF9CUlR8RFVNTVl8fHRlbXBlcmF0dXJlfDgyLjB8wqcyMDE4LTAxLTIyIDIwOjAwOjIyfFJFX1RFTVBfUFMzMDAwXzA4fERVTU1ZfHx0ZW1wZXJhdHVyZXw3MS4wNnzCpzIwMTgtMDEtMjIgMjA6MDA6MjJ8UkVfVEVNUF9CUlR8RFVNTVl8fHRlbXBlcmF0dXJlfDgxLjc1fMKnMjAxOC0wMS0yMiAyMDowMDoyMnxSRV9URU1QX1NwZWljaGVyXzAyfERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi45NHzCpzIwMTgtMDEtMjIgMjA6MDA6MjN8UkVfVEVNUF9TcGVpY2hlcl8wOHxEVU1NWXx8dGVtcGVyYXR1cmV8NzUuMTl8wqcyMDE4LTAxLTIyIDIwOjAwOjIzfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxpdGVycHJvbWlufDE4Ljk2fGwvbWluwqcyMDE4LTAxLTIyIDIwOjAwOjIzfEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fGxhc3RsaXRlcndvcmt8My44NHxXaMKnMjAxOC0wMS0yMiAyMDowMDoyM3xLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxwb3dlcnw0MzY4fFfCpzIwMTgtMDEtMjIgMjA6MDA6MjN8UkVfVEVNUF9CUlR8RFVNTVl8fHRlbXBlcmF0dXJlfDgyLjB8wqcyMDE4LTAxLTIyIDIwOjAwOjIzfFJFX1RFTVBfU3BlaWNoZXJfMTB8RFVNTVl8fHRlbXBlcmF0dXJlfDcyLjA2fMKnMjAxOC0wMS0yMiAyMDowMDoyNHxSRV9URU1QX1NwZWljaGVyXzA0fERVTU1ZfHx0ZW1wZXJhdHVyZXwyNy40NHzCpzIwMTgtMDEtMjIgMjA6MDA6MjR8UkVfVEVNUF9CUlR8RFVNTVl8fHRlbXBlcmF0dXJlfDgxLjc1fMKnMjAxOC0wMS0yMiAyMDowMDoyNHxSRV9URU1QX1NwZWljaGVyXzAzfERVTU1ZfHx0ZW1wZXJhdHVyZXwyNi45NHzCpzIwMTgtMDEtMjIgMjA6MDA6MjV8UkVfVEVNUF9TcGVpY2hlcl8wMXxEVU1NWXx8dGVtcGVyYXR1cmV8MjYuNjl8wqcyMDE4LTAxLTIyIDIwOjAwOjI1fFJFX1RFTVBfU3BlaWNoZXJfMDd8RFVNTVl8fHRlbXBlcmF0dXJlfDczLjEyfMKnMjAxOC0wMS0yMiAyMDowMDoyNnxSRV9URU1QX0hWX1JMQTJ8RFVNTVl8fHRlbXBlcmF0dXJlfDcxfMKnMjAxOC0wMS0yMiAyMDowMDoyNnxSRV9URU1QX1NwZWljaGVyXzA5fERVTU1ZfHx0ZW1wZXJhdHVyZXw3NC45NHzCpzIwMTgtMDEtMjIgMjA6MDA6MjZ8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGl0ZXJwcm9taW58MTguOTZ8bC9taW7CpzIwMTgtMDEtMjIgMjA6MDA6MjZ8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8bGFzdGxpdGVyd29ya3wzLjg0fFdowqcyMDE4LTAxLTIyIDIwOjAwOjI2fEtOWDEwLkkwNl9IZWl6dW5nc3phZWhsZXJfbWFpbnxLTlh8fHBvd2VyfDQzNjh8V8KnMjAxOC0wMS0yMiAyMDowMDoyNnxSRV9URU1QX1NwZWljaGVyXzA2fERVTU1ZfHx0ZW1wZXJhdHVyZXw2OS42OXzCpzIwMTgtMDEtMjIgMjA6MDA6Mjd8UkVfVEVNUF9IVl9WTDJ8RFVNTVl8fHRlbXBlcmF0dXJlfDczLjU2MnzCpzIwMTgtMDEtMjIgMjA6MDA6Mjd8UkVfVEVNUF9CUlR8RFVNTVl8fHRlbXBlcmF0dXJlfDgyLjB8wqcyMDE4LTAxLTIyIDIwOjAwOjI3fFJFX1RFTVBfQlJUfERVTU1ZfHx0ZW1wZXJhdHVyZXw4Mi4wfMKnMjAxOC0wMS0yMiAyMDowMDoyN3xSRV9URU1QX0JSVHxEVU1NWXx8dGVtcGVyYXR1cmV8ODIuMHzCpzIwMTgtMDEtMjIgMjA6MDA6Mjd8UkVfVEVNUF9TcGVpY2hlcl8wNXxEVU1NWXx8dGVtcGVyYXR1cmV8NDAuMTN8wqcyMDE4LTAxLTIyIDIwOjAwOjI4fFJFX1RFTVBfVm9ybGF1Zl9TY2h3aW1tYmFkfERVTU1ZfHx0ZW1wZXJhdHVyZXwyMi4zMXzCpzIwMTgtMDEtMjIgMjA6MDA6Mjh8UkVfVEVNUF9CUlR8RFVNTVl8fHRlbXBlcmF0dXJlfDgwLjc1fMKnMjAxOC0wMS0yMiAyMDowMDoyOHxSRV9URU1QX1J1ZWNrbGF1Zl9Tb2xhcnxEVU1NWXx8dGVtcGVyYXR1cmV8MjMuMDB8wqcyMDE4LTAxLTIyIDIwOjAwOjI5fFJFX1RFTVBfVm9ybGF1Zl9FR19Cb2RlbnxEVU1NWXx8dGVtcGVyYXR1cmV8MjguNTZ8wqcyMDE4LTAxLTIyIDIwOjAwOjI5fFJFX1RFTVBfQlJUfERVTU1ZfHx0ZW1wZXJhdHVyZXw4MS41fMKnMjAxOC0wMS0yMiAyMDowMDoyOXxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsaXRlcnByb21pbnwxOC45NnxsL21pbsKnMjAxOC0wMS0yMiAyMDowMDoyOXxLTlgxMC5JMDZfSGVpenVuZ3N6YWVobGVyX21haW58S05YfHxsYXN0bGl0ZXJ3b3JrfDMuODR8V2jCpzIwMTgtMDEtMjIgMjA6MDA6Mjl8S05YMTAuSTA2X0hlaXp1bmdzemFlaGxlcl9tYWlufEtOWHx8cG93ZXJ8NDM2OHxXwqcyMDE4LTAxLTIyIDIwOjAwOjMwfFN0cm9temFlaGxlcnxWWnx8dG90YWxfZW5lcmd5fDExODI1LjkxNDN8wqcyMDE4LTAxLTIyIDIwOjAwOjMwfFJFX1RFTVBfUnVlY2tsYXVmX0VHX0JvZGVufERVTU1ZfHx0ZW1wZXJhdHVyZXwyNS4wNnzCpzIwMTgtMDEtMjIgMjA6MDA6MzB8UkVfVEVNUF9CUlR8RFVNTVl8fHRlbXBlcmF0dXJlfDgxLjc1fA== Timeout:300 ConnectedVia:N/A
Pid:WAITING: Fn:fetchrows_DoParse Arg:repdb|history|Stromzaehler|%|2017-01-22 21:00:00|2017-01-22 21:10:00 Timeout:86400 ConnectedVia:N/A
Pid:WAITING: Fn:PROPLANTA_Run Arg:wetter_prop Timeout:120 ConnectedVia:N/A
"no telnet port found" hab ich leider nicht im Angebot, dafür aber heute (zum ersten mal ersichtlich) ein memory-Problem:
2018.01.22 21:00:01.715 1: Cannot fork: Cannot allocate memory
2018.01.22 21:00:01.715 1: stacktrace:
2018.01.22 21:00:01.715 1: main::fhemFork called by FHEM/Blocking.pm (172)
2018.01.22 21:00:01.716 1: main::BlockingStart called by FHEM/Blocking.pm (107)
2018.01.22 21:00:01.716 1: main::BlockingCall called by ./FHEM/59_PROPLANTA.pm (597)
2018.01.22 21:00:01.716 1: main::PROPLANTA_Start called by fhem.pl (3068)
2018.01.22 21:00:01.716 1: main::HandleTimeout called by fhem.pl (616)
2018.01.22 21:00:01.716 1: Cannot fork: Cannot allocate memory
free sagt allerdings, dass noch Platz frei ist:
root@fhem:/opt/fhem/log# free -m
total used free shared buff/cache available
Mem: 3257 2252 841 16 163 838
Swap: 1628 578 1050
Ich kann auch noch ganz normal Prozesse starten und auf meinem Server arbeiten... mysql, vim, less, cp, rsync usw. funktionieren alle *einwandfrei*.
Kann das an der Hardware liegen?
Ich glaube, wenns am RAM liegt, frieren wir das Thema besser als *unsolved* ein und warten, bis ich neue Hardware hab...
Grüße,
Stephan
Hi Stephan,
Zitat"no telnet port found" hab ich leider nicht im Angebot, dafür aber heute (zum ersten mal ersichtlich) ein memory-Problem:
Ja, das ist es. Cannot fork: Cannot allocate memory -> wenn dieser Fehler kommt, wird BlockingStart auch verlassen.
Ob es an der Hardware liegt kann ich leider nicht beantworten, vermutlich eher nicht.
Bekommst du raus was bei dir soviel RAM verbraucht ? -> bisschen googlen, hier im Forum habe ich auch schon threads gelesen die sich mit dem Thema Memory Verbrauch beschäftigt haben.
Mein System verbraucht so ca. 500MB incl. SWAP. Vielleicht reicht es schon wenn du den SWAP reichlich vergrößerst.
Du könntest außerdem die verdächtigen DbLog bzw. Proplanta ausschließen indem zu DbLog in den synchronen Mode schaltest bzw. Proplanta deaktivierst.
In der Zwischenzeit habe ich mal so ca. 800 Events im cache auflaufen lassen, der RAM-Verbrauch liegt damit bei ca. 370MB incl. SWAP .. mal so zum Vergleich.
Grüße
Heiko
Moin,
ich gestehe, nicht alle 41 Seiten gelesen zu haben, aber im "set" ist ein Fehler:
Falsch: "set ... exportCache purgecache"
Richtig:" set ... exportCache purgeCache"
zumindest geht es bei mir nur mit einem großen C.
Wäre auch schön, wenn exportCache den ganzen Cache schreiben würde, nicht nur den Cache seit letztem sync oder purge. Aufgrund eines fehlerhaften Readings, das ich jetzt erst bemerkt habe, ist mein Cache mittlerweile auf 22tsd Einträge gewachsen. Löse ich einen Export aus, schreibt er nur wenige Dutzend Einträge weg, eben die, die nach dem letzten Sync angefallen sind.
Ich muss ganz genau den Augenblick erwischen, wo DbLog versucht, den Cache in die Datenbank zu schreiben, nur dann kann ich die 22tsd Einträge exportieren und so die Daten vor dem Totalverlust retten....
Hallo Florian,
Zitat
Richtig:" set ... exportCache purgeCache"
zumindest geht es bei mir nur mit einem großen C.
Das wundert mich, weil purgecache tatsächlich klein geschrieben ist (zumindest in der aktuellsten Version 3.7.0).
ZitatIch muss ganz genau den Augenblick erwischen, wo DbLog versucht, den Cache in die Datenbank zu schreiben, nur dann kann ich die 22tsd Einträge exportieren und so die Daten vor dem Totalverlust retten....
Das kannst du dir vereinfachen. Setze cacheLimit auf z.B. "1000000". Dann geht DbLog solange nicht in Sync bis "syncInterval" erreicht ist und du kannst die Daten bequem exportieren.
Ich denke aber noch darüber nach das Verhalten beim Erreichen von "cacheLimit" zu verbessern.
EDIT: Was ist denn das für ein fehlerhaftes Reading, bzw. wie sieht es aus ?
LG,
Heiko
Zitat
Das wundert mich, weil purgecache tatsächlich klein geschrieben ist (zumindest in der aktuellsten Version 3.7.0).
Ja, im zweiten Dropdown ist es kleingeschrieben, aber wenn ich das so nutze, sagt er innerhalb von 10 Sekunden "160 Zeilen exportiert" und dann "170 Zeilen exportiert". Vergleicht man die Exporte, sind bei den 170 Zeilen nur 10 neue dabei und 160 Dubletten. Aus der Kommandozeile mit purge
Cache sagt er "160 Zeilen exportiert" und dann "10 Zeilen exportiert".
Zeile 464 aus 93_DbLog.pm:
$usage .= "listCache:noArg addCacheLine purgeCache:noArg commitCache:noArg exportCache:nopurge,purgecache " if (AttrVal($name, "asyncMode", undef));
Da wird es einmal groß und einmal klein geschrieben... Andererseits wird es tatsächlich auch getrennt ausgewertet, aber scheinbar löst Zeile 669 bei mir nie aus, denn auch den dort beschriebenen Logeintrag habe ich noch nie gelesen.
Drauf gekommen bin ich durch die Commandref: set <name> exportCache [nopurge | purge
Cache]
Zitat
Das kannst du dir vereinfachen. Setze cacheLimit auf z.B. "1000000". Dann geht geht DbLog solange nicht in Sync bis "syncInterval" erreicht ist und du kannst die Daten bequem exportieren.
Manchmal ist man echt zu blöd, die einfachste Lösung zu finden... Er fängt nach einem Sync ja an mit 8, 10, 17, *zack* 22tsd. Und dann versucht er zu schreiben, weil 500 überschritten wurde... Klar, kurzfristig Cache erhöhen und warten, bis er die 22tsd anzeigt, dann Export. War zu einfach um selbst drauf zu kommen *pfeif*
Edit: Ich weiß es (noch) nicht. Es gibt da ein Device (welches mir gerade nicht einfällt), das im State immer mal wieder (nicht immer!) blöderweise den Trenner "|" von DbLog nutzt. Damit generiert sich eine zu große Anzahl an Spalten. Fällt dann auf, wenn man sich den Export in Excel anschaut, dass da plötzlich zu viele Spalten auftauchen. Zeile in Notepad++ löschen, wieder hochladen und einspielen: Läuft dann wieder. --- Bis zum nächsten Reading...
Hab mal geschaut, commandref muss ich korrigieren -> purgecache muss klein geschrieben werden.
Das kleine purgecache ist eine Option zu exportFile, wohingegen purgeCache eine eigene Funktion ist -> leeren des Cache ohne irgendwas weiter.
Wenn man es falsch schreibt, wird automatisch "nopurge" verwendet, d.h. der Cache wird nicht geleert und beim nächsten Export wieder mit rausgeschrieben. Deswegen dann auch die Doubletten.
Und gestestet habe ich es auch, man weiß ja nie ;)
set LogDB exportCache purgecache
Log (verbose 3):
2018.01.25 16:45:21.786 3: DbLog LogDB: 38 cache rows exported to ./log/cache_LogDB_2018-01-25_16-04-44.
2018.01.25 16:45:21.797 3: DbLog LogDB: Cache purged after exporting rows to ./log/cache_LogDB_2018-01-25_16-04-44.
Zur Lösung des Problems gibt momentan mehrere Möglichkeiten, je nachdem in welchem Feld das Pipe genutzt wird. Einmal könnetst du mit valueFn das Zeichen substituieren oder löschen.
Oder aber ich ändere den charFilter im DbLog so um, dass Pipe rausgefiltert wird. Gefällt mir sogar besser.
Ich ändere das mal und lade die Version gleich hoch.
Dann brauchst die exportierten Files auch nicht editieren, sondern einfach wieder reinladen wenn es klappt wie ich es mir denke.
Grüße
Heiko
Zitat
Wenn man es falsch schreibt, wird automatisch "nopurge" verwendet, d.h. der Cache wird nicht geleert und beim nächsten Export wieder mit rausgeschrieben. Deswegen dann auch die Doubletten.
Glaub ich Dir, keine Frage, aber ich könnte schwören, das es sich bei mir anders verhält... als "set dblog exportCache purgecache" löscht er mir den Cache nicht, so meine Erinnerung. Und gerade habe ich x Mal "set dblog exportCache purgeCache" per Telnet eingetackert um den Zeitpunkt zu finden, wo die async.Daten wieder in den Cache zurückkommen. Jedesmal nur 4-10 neue Einträge. Ich probiere es nachher hoch mal mit kleinem purgecache. Die Dubletten sind bei kleinem purgecache aufgetaucht.
Wo Du gerade am Basteln bist: Gibt es einen Filter (oder was zum reinbasteln) um "nicht druckbare Sonderzeichen" rauszufiltern? Die mag MySQL auch nicht... Als mein nanoCUL noch am USB hing kam gerne mal ein UNKNOWNCODE <Steuerzeichen>, was mir dann die Datenbankanbindung gestört hat... (Obwohl ich den CUL ignoriert habe!) -> Wobei das nicht ganz so wichtig ist, jetzt schlägt sich die CCU mit dem CUL rum und FHEM steuert nur noch.
Ich werde die Version mit dem gefixten Typo erstmal einchecken.
Die andere Sache mit dem "|" ist aufwendiger. Ich werde diesbezüglich mit Escapes arbeiten. Aber da muss ich mir etwas Zeit nehmen und vor allem viel Testen.
ZitatWo Du gerade am Basteln bist: Gibt es einen Filter (oder was zum reinbasteln) um "nicht druckbare Sonderzeichen" rauszufiltern?
Das gibt es schon -> useCharfilter = 1
Edit: die
Option "purgecache" ist jetzt nicht mehr case sensitive. Also geht auch purgeCAChe. Neue Version anbei, checke ich aber noch ein.
LG,
Heiko
Hallo Florian, @all,
anbei befindet sich die Version 3.8.0.
Mit dieser Version können nun Events, die das Zeichen "|" enthalten, geloggt werden.
Bitte teste(t) dieses Version.
Florian, diese Version sollte dein Problem mit dem problematischen Readings bzw. Events lösen. Setze dir auch das Attribut "useCharfilter = 1".
Grüße
Heiko
Gerade runtergeladen, gleich gibt's in diesem Post ein Edit ;-)
Edit1: Da ist der Fehler: attr TempFeuchte event-on-update-reading (1.HUMIDITY|1.TEMPERATURE)Wenn das ein geloggtes Device ist, taucht ein Trenner auf, wo in der Datenbank kein Trenner sein darf. Wobei: Selbst schuld, warum logge ich auch .*:.*?
Ich hatte eigentlich mehr einen Event aus dem Eventmonitor erwartet.
Das ist ja erstmal nur die Einstellung vom event-on-update-reading.
Na mal schauen was noch kommt ...
EDIT: schau doch mal mit listCache in den Cache rein ...
Hm, es hat *mööp* gemacht...
lastCachefile ./log/cache_logdb_2018-01-25_16-04-32 - Error - 2018-01-25 22:53:47
Die Datei enthält die vorhin genannte ATTR-Zeile. Müsste ich noch was in der 3.8.0 einstellen, damit er den Trenner entfernt? Charfilter habe ich gesetzt.
Edit: Hier die raw-Zeile:2018-01-25 12:38:22|global|GLOBAL|ATTR TempFeuchte event-on-update-reading (1.HUMIDITY|1.TEMPERATURE)|state|ATTR TempFeuchte event-on-update-reading (1.HUMIDITY|1.TEMPERATURE)|
Musst nichts einstellen. Hast du auch reload oder Restart gemacht ?
Ansonsten schauen wir morgen nochmal ...
GN
Beides. Nachdem reload 93_DbLog.pm keinen Erfolg hatte, hatte ich fhem neu gestartet. Internals zeigt auch Version 3.8.0 an.
Import des Cache schlägt weiter fehl. Habe die Datei noch nicht geändert, kann ich also morgen wieder als Test nehmen.
Gesendet von meinem VTR-L09 mit Tapatalk
Moin Florian,
ich war wohl gestern schon zu müde und verbraucht. Die Umstellung im Modul betrifft das Logging. Das hat direkte Auswirkung auf den Cacheinhalt, der dann wiederum gleich im richtigen Format mit exportCache exportiert wird.
Für den Import deines Files müssen wir dem Modul einmalig noch unter die Arme greifen. Editiere bitte den Datensatz wie folgt:
2018-01-25 12:38:22|global|GLOBAL|ATTR TempFeuchte event-on-update-reading (1.HUMIDITY_ESC_1.TEMPERATURE)|state|ATTR TempFeuchte event-on-update-reading (1.HUMIDITY|1.TEMPERATURE)|
Wenn der Datensatz in der DB gespeichert wird, wirst du wieder den originalen Inhalt vorfinden.
Zukünftig werden beim Logging solche "Problemdaten" von vornherein so behandelt. Der charFilter betrifft die Behandlung von Steuerzeichen, Umlauten (Umsetzung in ue, ae, usw.)
Grüße,
Heiko
Moin,
hat funktioniert!
26048 cache rows processed from ./log/cache_logdb_2018-01-25_16-04-32
An den Plots ist schön zu sehen, dass die Daten auch angekommen sind.
Klasse Arbeit, vielen Dank!
Gruß
Florian
PS. Eigentlich wollte ich jetzt global ausschließen, aber ich lasse es heute noch mal drin und werde ein paar Attribute setzen. Dann kann ich testen, ob der neue Code auch lüppt.
Super :D
Ja, mach das mal bitte. Ich teste heute auch noch etwas.
Wenn bei dir auch alles rund läuft würde ich die Version ins SVN übernehmen.
LG,
Heiko
So, ich habe jetzt mehrere Attribute mit | gesetzt, Dummys angelegt und denen dann Umlaute in den Status geschrieben - ohne Probleme. Ich habe jetzt aber nicht die Datenbank kontrolliert, ob da alles richtig ankommt. Da aber die Status und für die Graphen die History vorhanden sind, unterstelle ich, dass da alles lüppt.
Nur meinen CUL konnte ich nicht überreden, Grütze zu senden...
Hallo Florian,
danke für die Rückinfo. Das sieht gut aus. Bei mir habe ich meine Tests auch erfolgreich absolviert.
Denke das passt und ich werde die Version morgen ins SVN übernehmen. Ist dann MOntag früh im Update.
Danke und Grüße
Heiko
Hallo zusammen,
Ich habe soeben eine neue Version 3.8.3 eingecheckt. Neben einigen weiteren Verbesserungen/Fixes habe ich das CacheUsage-Handling umgestellt.
Wenn cacheLimit erreicht ist, wird nach einem fehlerhaften Schreibvorgang ein erneuter Versuch frühestens nach syncInterval/2 gestartet.
Das entlastet fhem in diesem speziellen Fehlerfall.
Bitte updaten !
Grüße,
Heiko
Hi,
ich wollte mal ein Feedback zu Performance geben:
Ich hab eine SQLite3-Datenbank mit ca. 400 MB nach optimierungen, vorher waren es knapp 2 GB.
Auf meinem Rechner hat der import einer Logdatei mit ca. 8 MB mit importFileLog etwa 1,5h gedauert.
Nun habe ich einen Primary Key hinzugefügt:
sqlite> .schema
CREATE TABLE IF NOT EXISTS 'current' (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
CREATE TABLE IF NOT EXISTS 'history' (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32), PRIMARY KEY(TIMESTAMP, DEVICE, READING));
Der import der aktuellen Logdatei, Größe etwa 7,5 MB, wurde um 16:42 begonnen und ist noch nicht fertig.
Vielleicht geht was schief, aber das dauert mir echt (zu) lange...
Sooo.
Ein Blick ins Log (nach restart, verbose 5 und neuem import) zeigt:
2018.02.05 21:57:08.372 4: BlockingCall (FileLogConvert_FileRead): created child (15418), uses telnetPort to connect back
2018.02.05 21:57:08.373 4: Executing INSERT INTO history (TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT) VALUES ('2018-01-23 00:00:00','DF_setHTNT','','tarif: NT','tarif','NT','');
DBD::SQLite::db do failed: UNIQUE constraint failed: history.TIMESTAMP, history.DEVICE, history.READING at ./FHEM/93_DbLog.pm line 2388, <FH> line 1.
Mein Fehler? Ich kanns nicht deuten....
Ah, ich hab irgendwo was von INSERT IGNORE gelesen, was man benutzen (muss?), wenn man möglicherweise doppelte Datensätze in eine PK-Tabelle einfügt ...
Das habe ich auch gebraucht, um den PK anzulegen...
Grüße,
Stephan
Hallo Stephan,
so wie ich das lese bist du gerade dabei logfiles mit dem Tool von DeeSpe zu importieren, richtig ?
Ich denke das hat nicht geklappt. Die verschiedenen Statements abhängig vom vorhandenen PK oder nicht wird von DbLog automatisch gewählt wenn es um das
Loggen von Events geht.
DeeSpe verwendet mit seinem Importtool die Funktion "DbLog_ExecSQL". Das ist ein Seiteneinstieg für Modulentwickler um Werte in die DB zu pumpen.
Frag ihn mal in dem richtigen Thread (siehe commandref von DbLog am Anfang) ob er mit seiner insert-Syntax Rücksicht nimmt auf einen vorhandenen PK.
Das sieht mir nämlich nicht so aus.
ZitatDBD::SQLite::db do failed: UNIQUE constraint failed: ....
Dann fliegt der Prozess weg, weil die DB das nicht handeln kann (falsches Statement).
Was macht dein Memory-Problem ?
Grüße,
Heiko
Das sieht mir nämlich nicht so aus.
Dann sind wir der gleichen Meinung.
Was macht dein Memory-Problem ?
Danke der Nachfrage:
Rudi hat aufgegeben... Ich werde wohl mal in neue Hardware investieren, oder ein zweites FHEM auf einem neuen Rechner aufsetzen oder ... tja.. sobald, wenn, falls ich mal Zeit hab...
Wenn ich noch was durchschlagendes finde, meld ich mich. Aber es sieht nicht danach aus;(
Grüße, Stephan
Was müsste ich denn mit dem Aufruf von DbLog_ExecSQL tun um Rücksicht auf den PK zu nehmen?
Bin doch nicht so der SQL Junkie sondern hab mich ja mit FileLogConvert nur an Deine Funktion gehängt. ;)
Gruß
Dan
Huhu ;) Kann ich mir dann den zweiten Post sparen?
Edit:
http://www.sqlitetutorial.net/sqlite-replace-statement/
REPLACE INTO history
Grüße,
Stephan
Hi Dan,
ZitatWas müsste ich denn mit dem Aufruf von DbLog_ExecSQL tun um Rücksicht auf den PK zu nehmen?
Das ist ein bisschen Aufwand.
Zunächst musst du ermitteln ob PK benutzt wird. Dazu kannst du eine DbLog Funktion nutzen:
($usepkh,$usepkc,$pkh,$pkc) = DbLog_checkUsePK($hash,$dbh);Dann musst du abhängig davon die SQL's zusammenbauen. Dummerweise haben die verschiedenen DB-Typen auch noch unterschiedliche Syntax dafür.
Hier mal die Syntax wie ich sie für den Insert der Events benutze:
# insert history mit/ohne primary key
if ($usepkh && $hash->{MODEL} eq 'MYSQL') {
eval { $sth_ih = $dbh->prepare("INSERT IGNORE INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"); };
} elsif ($usepkh && $hash->{MODEL} eq 'SQLITE') {
eval { $sth_ih = $dbh->prepare("INSERT OR IGNORE INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"); };
} elsif ($usepkh && $hash->{MODEL} eq 'POSTGRESQL') {
eval { $sth_ih = $dbh->prepare("INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?) ON CONFLICT DO NOTHING"); };
} else {
# old behavior
eval { $sth_ih = $dbh->prepare("INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"); };
}
if ($@) {
# Eventliste zurückgeben wenn z.B. disk I/O error bei SQLITE
$error = encode_base64($@,"");
Log3 ($name, 2, "DbLog $name - Error: $@");
Log3 ($name, 5, "DbLog $name -> DbLog_PushAsync finished");
$dbh->disconnect();
return "$name|$error|0|$rowlist";
}
Das müßtest du entsprechend adaptieren und das richtige Statement dann an DbLog_ExecSQL übergeben. So zumindst die Theorie ;)
Grüße
Heiko
Hmm, dann denke ich ist für diesen Fall die Funktion DbLog_ExecSQL einfach falsch.
Im Prinzip brauche ich ja kein volles ExecSQL. Eine InsertSQL Funktion würde mir ja reichen wenn das restliche DB-Handling eh schon in DbLog vorhanden ist.
Gibt es so eine Funktion in DbLog?
Gruß
Dan
Naja, gibt es schon. Am einfachsten wäre die DbLog_addCacheLine. Da wird einfach eine Zeile dem Cache hinzugefügt und mit den normalen Events in die DB eingefügt. Geht aber nur im asynchronen Modus.
Ansonsten gibt es ja noch die normale Routine DbLog_Push die auch für Events im synchronen Mode verwendet wird.
Der wird einfach ein Array der Werte übergeben:
my $row = ($timestamp."|".$dev_name."|".$dev_type."|".$event."|".$reading."|".$value."|".$unit);
push(@row_array, $row);
...
if(@row_array) {
# return wenn "reopen" mit Ablaufzeit gestartet ist
return if($hash->{HELPER}{REOPEN_RUNS});
my $error = DbLog_Push($hash, @row_array);
}
Hallo zusammen,
ich nutze DBLog erst seit einigen Wochen. Im Grunde läuft alles reibungslos. Nur bei meinem ZWAVE Geräten wird das übergebene Reading nicht korrekt aufgelöst, sodass die Einheit trotzdem im Attribut "Value" gespeichert und Minus-Werte ohne Minus - also positiv - gespeichert werden.
Hier ein Auszug aus der DBLog DB:
1. Zeile... man betrachte das % Zeichen
2. Zeile... man betrachte die positive Temperatur
"2018-02-06 20:18:22" "AU.Multisensor" "ZWAVE" "humidity: 62 %" "humidity" "62 %" "%"
"2018-02-06 20:18:21" "AU.Multisensor" "ZWAVE" "temperature: -1.5 C" "temperature" "1.5" "C"
Ich steige bei den regulären Ausdrücken nicht durch. Die Syntax macht mir zu schaffen. Habt ihr eine Idee, wie man das lösen könnte?
In der 93_DBLog.pm sollte die Besonderheit für ZWAVE Geräte ja eigentlich abgebildet sein:
# FBDECT or ZWAVE
elsif (($type eq "FBDECT") || ($type eq "ZWAVE")) {
if ( $value=~/([\.\d]+)\s([a-z].*)/i ) {
$value = $1;
$unit = $2;
}
}
Hallo,
ja ZWAVE Parsing hat schon in der Vergangenheit immer mal wieder für Schwierigkeiten in DbLog gesorgt.
Grundsätzlich ist zu sagen dass die Subroutine "DbLog_ParseEvent", die du zitiert hast , von mir nicht aktiv weiterentwickelt wird. Das hat den Grund dass die Modulmaintainer möglichst die Funktion "DbLog_splitFn" (siehe Wiki dazu) in ihren Modulen implementieren um das Wertesplitting direkt in den Modulen durchzuführen. Das ist am elegantesten, denn die Developer wissen am besten welche Readings die Module erzeugen usw.
Im Fall von ZWAVE ist das aber bisher nicht passiert. Deswegen ist hier der Nutzer etwas gefordert.
Man kann als User über das Attribut valueFn Perl-Ausdrücke einbauen um selbst die Aufbereitung / das Splitting vorzunehmen. Lies dir dazu mal die commandref im DbLog durch.
Wenn du damit nicht klarkommst, kannst du dich gern nochmal melden. Ich selbst habe momentan wenig Zeit für Support, aber es helfen bestimmt noch mehr Mitstreiter.
Grüße
Heiko
Hallo Heiko,
vielen Dank für deine schnelle Reaktion. Deinen Lösungsansatz finde ich auch nachhaltiger, als dass die Besonderheiten für jedes Modul in die DBLog Config ausgelagert werden. Ich schaue mal, ob ich deinen Workaround umsetzen kann.
Viele Grüße
René
Zitat von: DS_Starter am 05 Februar 2018, 23:25:42
Naja, gibt es schon. Am einfachsten wäre die DbLog_addCacheLine. Da wird einfach eine Zeile dem Cache hinzugefügt und mit den normalen Events in die DB eingefügt. Geht aber nur im asynchronen Modus.
Ansonsten gibt es ja noch die normale Routine DbLog_Push die auch für Events im synchronen Mode verwendet wird.
Der wird einfach ein Array der Werte übergeben:
my $row = ($timestamp."|".$dev_name."|".$dev_type."|".$event."|".$reading."|".$value."|".$unit);
push(@row_array, $row);
...
if(@row_array) {
# return wenn "reopen" mit Ablaufzeit gestartet ist
return if($hash->{HELPER}{REOPEN_RUNS});
my $error = DbLog_Push($hash, @row_array);
}
Danke für den Hinweis Heiko.
Ich werde mal ein bisschen was probieren. Habe leider die nächsten Tage wenig Zeit.
Gruß
Dan
Hi,
ich habe weitere Dateien mit FileLogImport importiert.
Dabei stelle ich fest, dass der Import hängt. Fehlermeldung :
2018.02.06 22:55:12.744 4: Executing INSERT INTO history (TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT) VALUES ('2018-02-01 00:43:16','OWX_1D_22DC84000003','','memory: ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@','memory','^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@','');
DBD::SQLite::db do failed: unrecognized token: "'memory: " at ./FHEM/93_DbLog.pm line 2388, <FH> line 181991.
useCharfilter ist bei DbLog gesetzt (der laut commandref in diesem fall eh nichts machen würde).
Ich würde diese Zeilen jetzt aus den Filelogs löschen.
ich weiss nicht, ob das ein "insert"-Fehler ist oder das Problem woanders liegt. Falls insert-Fehler,
könnte man die Zeile nicht in ein "nicht importiert"-Reading stecken und mit dem Rest weitermachen?
Grüße,
Stephan
Hallo Stephan,
habe in DbLog die Funktion die Dan hier benutzt jetzt gekapselt (auch wegen einer anderen Meldung bzgl. usercommand).
Ggenüber solchen fehlerhaften Sätzen ist die Funktion jetzt resistent. Fehlermitteilung kommt im Log, aber der Import von FilelogConvert bricht nicht mehr ab (wenn ich alles richtig gemacht habe).
V3.8.4 hier angehängt.
Grüße
Heiko
Hallo Heiko,
mir ist heute früh FHEM "abgeraucht":
DBD::mysql::db selectrow_array failed: fetch() without execute() at ./FHEM/93_DbLog.pm line 817.
Das passierte beim Ausführen von:
set logdb userCommand delete from history where READING="state"
Hast Du eine Ahnung was dort passiert sein könnte?
FHEM ist aktuell.
Gruß
Dan
Hi Dan,
ja, das Statement war nicht korrekt, hat ein ";" gefehlt.
Die userCommand-Funktion war noch nicht mit eval gekapselt.
Habe ich jetzt mit der obigen V3.8.4 noch nachgeholt.
Setz die mal ein und wiederhole das SQL. Der Fehler erscheint dann im Reading, aber FHEM bleibt unberührt.
Grüße
Heiko
Hab jetzt die Version von oben mal eingespielt und das "falsche" Kommando nochmal abgesetzt.
Jetzt ist nichts abgeschmiert. ;)
Aber dann nochmal mit dem "richtigen" Kommando und es wird wieder ein Fehler geworfen:
ZitatuserCommand delete from history where READING="state"; 2018-02-07 21:07:56
userCommandResult DBD::mysql::db selectrow_array failed: fetch() without execute() at ./FHEM/93_DbLog.pm line 820. 2018-02-07 21:08:53
Ich hatte gehofft damit alle "state" Einträge in der DB zu löschen.
Gruß
Dan
was ist denn das für ein Date String ?
Zitatdelete from history where READING="state"; 2018-02-07 21:07:56
delete from history where READING="state"; wäre doch richtig
EDIT: selectrow_array wird verwendet... nimm DbRep für selektives löschen.
Grüße
Heiko
Hi,
ich habe einen Dummy, der mir die Leistung berechnet:
Internals:
NAME D_WMZ_Heizung_main
NR 756
STATE 4582 W
TYPE dummy
Helper:
DBLOG:
power:
logdb:
TIME 1518707885.22366
VALUE 4582 W
work:
logdb:
TIME 1518707885.22366
VALUE 12.73 Wh
READINGS:
2018-02-15 16:18:05 RL 25.75 °C
2018-02-15 16:18:05 VL 29.25 °C
2018-02-15 16:08:15 literproh 0.32 liter/h
2018-02-15 16:18:05 literprosec 0.31 liter/s
2018-02-15 16:18:05 power 4582 W
2018-02-15 16:18:05 rate 16.3
2018-02-15 16:18:05 work 12.73 Wh
Attributes:
DbLogInclude power,work
room FHEM2FHEM,Heizung,_dummy
stateFormat power
userReadings VL {sprintf("%.2f °C",ReadingsNum("RE_TEMP_VorlaufHK","temperature",0))},
RL {sprintf("%.2f °C",ReadingsNum("RE_TEMP_RuecklaufHK","temperature",0))},
power:rate.* {sprintf("%.0f W",ReadingsNum($name,"rate",0)/52*3600*1.16*(ReadingsNum($name,"VL",0)-ReadingsNum($name,"RL",0)))},
work:rate.* {sprintf("%.2f Wh",ReadingsNum($name,"rate",0)/52*1.16*ReadingsAge($name,"work",0)*(ReadingsNum($name,"VL",0)-ReadingsNum($name,"RL",0)))},
literprosec:rate.* {sprintf("%.2f liter/s",ReadingsNum($name,"rate",0)/52)}
wie man sieht, wird die Arbeit (work) mit Value in das Reading geschrieben, so dass da "10.45 Wh" rauskommt. Ohne ists ziemlich kryptisch.
Leider erzeugt mir das Datenbankeinträge, bei denen Wh mit im Feld "Value" steht.
Wie kann ich das ändern?
so werden nämlich die Abfragen schwierig... ganz zu schweigen davon, dass ich nicht weiss, wie ichs reparieren soll... aber das werd ich schon noch schaffen ..
Grüße,
Stephan
Hallo Stephan,
reparieren kannst du es ganz einfach mit dem neuen DbRep Kommando changeValue.
Damit es erst garnicht so in der DB landet kannst du das Attribut valueFn in dblog verwenden.
Mach dir ein kleines Split wenn du dieses Device/Reading loggst.
LG
Heiko
Zitat von: DS_Starter am 15 Februar 2018, 16:32:08
Mach dir ein kleines Split wenn du dieses Device/Reading loggst.
Muss ich für jedes Device prüfen, ob die Werte richtig geloggt werden, und ggf ein "kleines Split" bauen?
Grüße,
Stephan
Ich verstehe die Frage nicht wirklich. Du prüfst ob VALUE eine Zahl und irgendwas ist, ob DEVICE dein Dummy ist und READING dein reading. Wenn es so ist splittest du VALUE auf und gibst die Zahl als VALUE und den Rest als UNIT zurück. Schau mal in die commandref dazu.
ich hab dich missverstanden ...
Danke und Grüße,
Stephan
Hi,
die valueFn hab ich hinbekommen, gute Idee die du da eingebaut hast. Bin noch am überlegen wie bzw. ob ich das generisch lösen kann, ohne den Inhalt zu kennen ... aber vermutlich hast du das auch schon versucht. ::)
Zum changeValue hab ich aber noch ne Frage:
hier steht :
Zitatset <name> changeValue "<alter String>","<neuer String>"
# der alte String wird in den neuen String geändert.
# Beide Strings können Leerzeichen enthalten. Die Werte sind in Quotes zu setzen und durch Komma zu trennen.
Also kann ich bei einem Value
"a b"
das b weg machen mit
set repdb changeValue "a b","a"Was aber nicht in der commandref zu stehen scheint, ob ich hier auch z.B. $Reading und $value sowie perl verwenden kann...
Ich habe in der Datenbank
Value:Unit-Paare:
"11.14 Wh":""
"22.35 Wh".""
mit "strings" bekomm ich die nicht auseinander ...
das " Wh" löschen könnte gehen, aber nur wenn <alter String> auch <alter Teilstring> bedeutet ...
Grüße,
Stephan
editiert: Formulierungen überarbeitet
Hi Stephan,
Zitatset repdb changeValue "a b","a"
Ja, so ist es.
ZitatWas aber nicht in der commandref zu stehen scheint, ob ich hier auch z.B. $Reading und $value sowie perl verwenden kann...
Steht da so nicht drin weil es momentan nicht geht. Du hast natürlich Recht ... diese Möglichkeit wäre eine tolle Sache um die Erstetzung generischer zu gestalten.
Ich nehme mir das mal mit vor die Funktion aufzupeppen. In deinem speziellen Fall hilft dir das nichts....
Grüße
Heiko
ZitatIn deinem speziellen Fall hilft dir das nichts....
Alles klar. Ist nicht so schlimm. Die neuen Daten sind ja einwandfrei.
Danke!
Grüße,
Stephan
Hallo zusammen,
für eine neue Installation nutze ich zur Zeit
DbLogType SampleFill/History
Das klappt soweit auch ganz gut, jedoch wenn ich einen Plot bearbeite, wird EINE Zeile, nämlich
HeizungKeller.1.1.1_A:ventil-get
in der Combobox immer ersetzt durch
hz.Heizkreis.Keller.RuecklaufGesamt:measured-temp:::
also den Wert der ersten Zeile.
Wenn ich ihn manuell wieder auf "HeizungKeller.1.1.1_A:ventil-get" stelle und write plot klicke, funktioniert der Plot auch wie gewünscht,
jedoch ist es mir schon mal passiert, dass ich versehentlich einen Wert geändert habe und somit der plot nicht mehr funktionierte.
Schön wäre es also, wenn die Combobox in allen Zeilen korrekt ausgefüllt wäre, nicht nur in den ersten 8.
Im HTML-Quellcode steht schon der falsche Wert als "selected" drinnen, nämlich
<option selected="selected" value="hz.Heizkreis.Keller.RuecklaufGesamt:measured-temp">hz.Heizkreis.Keller.RuecklaufGesamt:measured-temp</option>
Ich vermute fast, dass es kein Fehler im DbLog-Modul ist, aber im SVG-Modul scheint er auch nicht angesiedelt zu sein?!?
Hat jemand eine Idee?
Anbei ein Screenshot der zeigt, dass in der gplot-Datei etwas anderes angezeigt wird als in FHEMWEB. Die gplot-Datei stimmt!
sG
joe
Hallo Joe,
ich habe mir jetzt nicht SVG.pm genauer angesehen, aber bei Aufruf der entspechenden DbLog-Funktion übergibt SVG einen Parameter $max.
$max wird in der DbLog-Funktion auf "8" begrenzt, wenn $max gößer sein sollte.
Warum das so ist kann ich leider nicht sagen .... die Funktion gibt es schon länger als ich mich mit dem Modul beschäftige.
Möglicherweise hängt aber deine Beobachtung damit zusammmen.
Um das zu testen/verifizieren kannst du im eingecheckten DbLog die Zeile 4694 mal abändern:
original: $max = 8 if($max > 8);
ändern z.B.: $max = 11 if($max > 11);
Ich bin nur darauf gekommen weil du von 8 Zeilen geschrieben hast.
Eine andere Möglichkeit DbLog betreffend kann ich mir nciht vorstellen.
LG,
Heiko
Hallo Heiko,
JA, das ists!!!! Danke!
Stellt sich nur die Frage, warum der Code enthalten ist....
Hat mich immer mal wider geärgert wenn ich mir damit einen Plot kaputt gemacht habe...
sG
Joe
ZitatStellt sich nur die Frage, warum der Code enthalten ist....
Ja, das wüßte ich auch gern. Möglicherweise hat man ein (willkürliches) Limit eingebaut.
Vielleicht kann Rudi Aufklärung geben, irgendeinen Sinn wird es wohl haben ... oder gehabt haben.
Wäre etwas um im SVG Forum mal nachzufragen ...
LG,
Heiko
Es gibt 8 Farben für Linien, vermutlich hängt es damit zusammen...
ZitatEs gibt 8 Farben für Linien, vermutlich hängt es damit zusammen...
Klingt schlüssig ...
Hallo Heiko,
habe von Rudi keine Antwort bekommen, bin mir amber ziemlich sicher, dass wir das Limit anheben könnten.
Vermutlich könnten wir es sogar ohne Attribut machen, wobei wir mit Attribut die Möglichkeit hätten, den Standardwert bei 8 zu belassen...
Ob das dann noch jemand versteht, bezweifle ich jedoch....
Noch etwas ist mir aufgefallen:
Sollte ich damit nicht Datensätze loggen können, da es sich um einen validen Devspec handelt?
set sql addLog Gaszaehler:FILTER=verbrauch_.*=.*
geht jedoch nicht.
Dies funktioniert, jedoch kann ich hier nicht auf bestimmte Werte filtern.
set sql addLog Gaszaehler:verbrauch_.*
ein "list Gaszaehler:FILTER=verbrauch_.*=.*" funktioniert jedenfalls!
sG
joe
Hallo Joe,
ich habe in der angehängten Version 3.8.7 das Limit mal auskommentiert. Es wird also so verwendet wie es von SVG übergeben wird.
Vermutlich hat es keine negativen Auswirkungen. Habe es auch bei mir getestet.
Dennoch würde ich mich freuen wenn es ein paar mehr Tester geben würde bevor ich die Änderung einchecke !!!
Zum Addlog ...
Das devspec ist valide, ja. Aber die Syntax vom Addlog ist:
set <name> addLog <devspec>:<Reading>
D.h. nach devspec muß nochmal ein ":" gefolgt von dem relevanten Reading kommen welches für Addlog verwendet werden soll. Wenn man das/die Readings innerhalb des devspec filtert, wäre die Ergänzung nur ein ":.*".
Es müsste also so funktionieren:
set sql addLog Gaszaehler:FILTER=verbrauch_.*=.*:.*
Ich habe für addlog das verbose 4 etwas erweitert. Man sieht dann genau welche Devices die devspec Spezifikation als valide erachtet und zur Verwendung an addlog zurück gibt.
Also wie gesagt, über ein paar mehr Tester bzgl. SVG würde ich mich freuen.
LG,
Heiko
Hallo Heiko,
ich habe deine Änderung bei mir mal eingebaut. Bis jetzt ohne Problem.
Ich hatte zu dem Thema schon mal gefragt, damals aber keine zufriedenstellende Lösung bekommen. Freut mich wenn es jetzt klappt.
https://forum.fhem.de/index.php/topic,76008.msg773789.html#msg773789
Gruss
Enno
Hallo Heiko,.
Danke, werds morgen einbauen.
Ist das auch der Grund, warum obiges devspec auch bei
excludeDevs nicht greift?
(Hintergrund: ich möchte für alle KNX devices das Loggen von "last-sender" verhindern.... Das wird nämlich sehr oft gesendet.)
SG Joe
Ist das auch der Grund, warum obiges devspec auch bei excludeDevs nicht greift?
das Attribut "excludeDevs " füttert ganz trivial die devspec2array-Funktion. Die bringt dann das Ergebnis zurück.
Das sollte ganz normal funktionieren.
Grüße,
Heiko
Hallo enno,
prima, habe den Thread jetzt kurz überflogen. Scheinen ja noch mehr betroffene vorhanden zu sein und testen vllt. dann auch.
LG,
Heiko
Zitat von: DS_Starter am 27 Februar 2018, 22:12:19
das Attribut "excludeDevs " füttert ganz trivial die devspec2array-Funktion. Die bringt dann das Ergebnis zurück.
Das sollte ganz normal funktionieren.
Danke für die Erklärung.
Es loggt aber KEIN Device, das das angegebene Filterreading nur "enthält". Ich bin davon ausgegangen, dass es dann lediglich
das angegebene Reading nicht loggt, nicht alle Readings.
sg
joe
Hi Joe,
ZitatEs loggt aber KEIN Device, das das angegebene Filterreading nur "enthält". Ich bin davon ausgegangen, dass es dann lediglich
das angegebene Reading nicht loggt, nicht alle Readings.
Das Attribut heißt "excludeDevs" (exclude Devices) und ist wörtlich zu nehmen. Alle Devices, die in dem Attribut angegeben sind, werden vom Logging ausgeschlossen. devspec gibt auch ein oder meherere Devices zurück, die gemäß der devspec Angabe matchen. Diese Devices werden dann ausgeschlossen.
LG,
Heiko
Hallo Heiko,
Verstehe... Dann schlage ich ein DbLogExkludeGlobal direkt im DbLog Device vor, um, analog zum normalen DbLogExklude beim Device gewisse Readings allgemein vom Logging auszuschließen.
Zur Hintergrunderklärung: ich bekomme viele KNX devices automatisch angelegt und möchte gewisse sinnlose Informationen einfach generell vom Logging ausschließen, bevor ich dazu komme das von Hand immer nachzuziehen.....
SG Joe
Reicht es nicht bestimmte Readings im DEF generell auszuschließen ?
Zum Beispiel so um "done" nicht zu loggen:
.*:(?!done).*
Das müsste m.M. nach ausreichen.
Hi DS_Starter,
darf ich dich um ein kleines Update in der Commandref bitten? Ich habe es schon mehrfach gelesen, dass Anwender auf DBLog umstellen, jedoch noch die kurzen Felder in der Datenbank nutzen, und dadurch verschiedene Probleme hochkommen ... Readings abgeschnitten, Plots leer, ...
Hintergrund ist, dass der contrib-Ordner in der Fhem-Installation beim Update nicht beachtet wird. Somit wird manchmal ein veraltetes Script genutzt obwohl im Github eine korrekte Version liegt. Mein contrib-Ordner ist z. B. von Anfang 2015 obwohl die Installtion aktuell ist. Das Verhalten ist für User selten bekannt.
Den Wiki-Eintrag hast du mit erstellt, zumindest stehts du als Author mit dabei. Ähnlich im Commandref wäre gut.
Mein Vorschlag: in der Commandref ausschließlich auf die Scripts im Github verweisen, im Wiki ist der Link schon enthalten. Oder alternativ den Link auf github einfügen mit dem Hinweis, dass dieses Script dort immer das aktuelle ist, und im Fhem-Ordner ggf. nicht.
Beispiel eines solchen Posts ...
https://forum.fhem.de/index.php/topic,17201.msg777876.html#msg777876
Danke dir!
Zitat von: DS_Starter am 28 Februar 2018, 17:51:58
Reicht es nicht bestimmte Readings im DEF generell auszuschließen ?
Zum Beispiel so um "done" nicht zu loggen:
.*:(?!done).*
Das müsste m.M. nach ausreichen.
Hallo Heiko,
Funktioniert bei mir nicht, danach zB alle Alarme von 1wire Sensoren nicht speichern möchte, da ich diese nicht nutze, und die Standard Alarmtemperatur ständig überschritten wird. Andere Alarme interessieren mich jedoch sehr. Aber auch dazu würde das globalExclude nicht ausreichen, dazu müsste es DEVSPEC:Reading verstehen können....
SG Joe
Guten Morgen,
@kadettilac89 ... Ich habe die commandref dahingehend überarbeitet wie du vorgeschlagen hast. Es wird auf das Verzeichnis mit den aktuellen Scripten im SVG verlinkt. Die kann man sich dann anschauen oder runterladen.
Außerdem habe ich noch einen Abschnitt "Troubleshooting" am Anfang mit eingefügt, der Hilfestellung zur Vorgehensweise bei Problemen zu Beginn mit DbLog bieten soll. Die neue Version ist eingecheckt und morgen früh im Update, schau mal ob es nun so für den User hilfreich ist.
@Joe, bin mir noch unsicher wie ich dir helfen kann.
ZitatDann schlage ich ein DbLogExkludeGlobal direkt im DbLog Device vor, um, analog zum normalen DbLogExklude beim Device gewisse Readings allgemein vom Logging auszuschließen.
Wenn ich es richtig interpreriere, dann würde ein Attribut im DbLog, welches eine Liste der global auszuschließenden Readings enthält (ähnlich excludeDevs wobei natürlich keine devspec verwendet werden können), ausreichen um das Ziel zu erreichen. Richtig ?
LG,
Heiko
@Heiko: korrekt! Kein globales Attribut für alle Devices, sondern nur für das DbLog-Device.
SG Joe
Hallo Joe,
anbei die V3.9.0. Das Attribut excludeDevs ist erweitert um Readings auch ausschließen zu können.
excludeDevs
attr <device> excludeDevs <devspec1>[#Reading],<devspec2>[#Reading],<devspec...>
Die Device/Reading-Kombinationen "devspec1#Reading", "devspec2#Reading" bis "devspec..." werden vom Logging in die Datenbank global
ausgeschlossen.
Die Angabe eines auszuschließenden Readings ist optional.
Somit können Device/Readings explizit bzw. konsequent vom Logging ausgeschlossen werden ohne Berücksichtigung anderer Excludes oder Includes
(z.B. im DEF). Die auszuschließenden Devices können als Geräte-Spezifikation angegeben werden. Für weitere Details bezüglich devspec siehe Geräte-
Spezifikation.
Beispiel
attr <device> excludeDevs global,Log.*,Cam.*,TYPE=DbLog
# Es werden die Devices global bzw. Devices beginnend mit "Log" oder "Cam" bzw. Devices vom Typ "DbLog" vom Logging ausgeschlossen.
attr <device> excludeDevs .*#.*Wirkleistung.*
# Es werden alle Device/Reading-Kombinationen mit "Wirkleistung" im Reading vom Logging ausgeschlossen.
attr <device> excludeDevs SMA_Energymeter#Bezug_WirkP_Zaehler_Diff
# Es wird der Event mit Device "SMA_Energymeter" und Reading "Bezug_WirkP_Zaehler_Diff" vom Logging ausgeschlossen.
Bitte mal testen ob alles so funktioniert wie beabsichtigt.
Grüße,
Heiko
Zitat von: DS_Starter am 10 März 2018, 09:29:29
@kadettilac89 ... Ich habe die commandref dahingehend überarbeitet wie du vorgeschlagen hast. Es wird auf das Verzeichnis mit den aktuellen Scripten im SVG verlinkt. Die kann man sich dann anschauen oder runterladen.
Außerdem habe ich noch einen Abschnitt "Troubleshooting" am Anfang mit eingefügt, der Hilfestellung zur Vorgehensweise bei Problemen zu Beginn mit DbLog bieten soll. Die neue Version ist eingecheckt und morgen früh im Update, schau mal ob es nun so für den User hilfreich ist.
Danke dir!
Hallo,
Bin gerade erst heimgekommen, Werd's mir morgen gleich Mal testen!
Danke, SG Joe
Hallo Heiko,
diese Lösung entspricht aber im Prinzip der Lösung, die Du weiter oben vogeschlagen hast, oder?
.*:(?!done).*.
Sämtliche Devices vom Typ OWSERVER mit dem reading "alarm" kann ich damit jedoch nicht ausschließen: Ich bräuchte also eher die Screibweise:
attr <device> excludeReads [<devspec>:]<Reading1>,[<devspec>:]<Reading2>,[<devspec>:]<Reading..>
um
attr <device> excludeReads TYPE=OWSERVER:alarm
nutzen zu können.
Ein weiterer Wunsch:
Können wir aus
$exr =~ s/\s/,/g;
durch
$exr =~ s/(?:\s|\n)/,/g;
ersetzten, damit ich auch die mehrzeilige Konfiguration nutzen kann?Die ist für meine Anzahl an Devices viel übersichtlicher!
sG
Joe
Hallo Joe,
jetzt habe ich es erst richtig verstanden was du willst bzw. brauchst.
In dem Fall könnte ich mir etwas überlegen das vorhandene Attribut excludeDevs zu erweitern und die dahinter
iegende Funktion auszubauen.
Ich melde mich wieder mit einer veränderten Version.
Grüsse,
Heiko
Hallo Joe,
habe das Modul überarbeitet und in #669 neu hochgeladen.
Weil die devspec bereits den Trenner ":" kennt, habe ich für die Trennung des Readings "#" eingeführt.
Mit verbose 4 wird im Logfile ausgegeben wenn etwas ausgeschlossen wurde.
Teste mal bitte erneut.
Grüße
Heiko
Hallo Heiko,
danke, funktioniert in einem ersten Test gut, habe jedoch gerade mein Testsystem "verloren"....
Was mir noch aufgefallen ist ist, wenn ich DbLog mit "reopen 2000" schließe und eine Seite mit Plots
aufrufe, hängt FHEM.
Kann man da in dbLog etwas machen, oder betrifft das vielmehr das SVG-Modul?
sG
Joe
Hi Joe,
na du machst Sachen ... :D
Bezüglich dem Fhem hängen ... achte darauf dass du in deinem fhemweb plotfork=1 gesetzt hast.
Sonst wird auf das Ergebnis aus der Db gewartet die natürlich geschlossen ist.
Grüsse,
Heiko
Hallo Heiko,
Danke! plotfork=1 hatte ich disabled, weil Rudi darüber in einem Forum mal ganz schön abgelästert hatte....
Vielleicht hast Du dazu auch eine Idee: Ich habe Devices mit über hundert Readings.
Dafür nutze ich mitternächtlich addLog, was wunderbar funktioniert.
Nun bräuchte ich aber eine Variante von addLog, die auch DbLogExclude mit berücksichtigt.
Der umgekehrte Weg, die 99 benötigten Readings anzugeben erscheint mir als etwas mühevoll ;-)
sG Joe
Eine Idee wäre beim addlog Befehl das Vorhandensein eines Signalwortes, was man optional mit angeben kann, zu prüfen. Wenn es vorhanden ist, würde das DbExclude-Attribut in den Devices mit brücksichtigt.
Denke sowas könnte recht einfach umgesetzt werden.
LG
Klingt für mich gut, wollte nur eigentlich nicht schon wieder eine Erweiterung "wünschen"!!:D
Danke, jedenfalls....!!
sG Joe
Hallo Joe,
anbei die V3.10.0., ... hat wegen anderer Baustellen etwas länger gedauert ;)
Bei addLog wird ein eventuell gesetztes Attribut "DbLogExclude" in den Quelldevices generell berücksichtigt.
Ich bin mir noch unsicher, ob ich die Berücksichtigung des Attributs generell unberücksichtigt lasse und sie mit einem Keyword einschalte, oder es generell berücksichtige und mit einem Keyword ausschalte.
Welche Meinung hast du/habt ihr dazu ?
LG,
Heiko
Generell Berücksichtigen und nur mit Keyword ausschalten.
Würde ich auch dazu tendieren, auch wenn es meine bisherige Verwendung beeinflusst. Ich nehme zB das state eigentlich immer aus...
SG Joe
Hallo zusammen,
danke für eure Rückmeldungen.
Habe nun das addLog in der angehängten 3.10.0 so erweitert dass ein Keywort verwendet werden kann.
Neue Beschreibung:
set <name> addLog <devspec>:<Reading> [Value] [!useExcludes]
Fügt einen zusatzlichen Logeintrag einer Device/Reading-Kombination in die Datenbank ein. Optional kann "Value" für den Readingwert angegeben
werden. Ist Value nicht angegeben, wird der aktuelle Wert des Readings in die DB eingefügt. Das Feld "$EVENT" wird automatisch mit "addLog"
belegt.
Das Device kann als Geräte-Spezifikation angegeben werden. "Reading" wird als regulärer Ausdruck ausgewertet.
Ein eventuell im Quell-Device gesetztes Attribut "DbLogExclude" wird von der Funktion berücksichtigt. Soll dieses Attribut nicht berücksichtigt werden,
kann das Schüsselwort "!useExcludes" verwendet werden.
Es wird KEIN zusätzlicher Event im System erzeugt !
Beispiele:
set <name> addLog SMA_Energymeter:Bezug_Wirkleistung
set <name> addLog TYPE=SSCam:state
set <name> addLog MyWetter:(fc10.*|fc8.*)
set <name> addLog MyWetter:(wind|wind_ch.*) 20 !useExcludes
set <name> addLog TYPE=CUL_HM:FILTER=model=HM-CC-RT-DN:FILTER=subType!=(virtual|):(measured-temp|desired-temp|actuator)
Hoffe das funktioniert so in eurem Sinne und würde mich über eure Testergebnisse/Meinungen freuen.
Grüße,
Heiko
Hallo Heiko,
mir ist gerade aufgefallen, dass DbLogExclude keine Readingnamen mit "/" im Namen direkt unterstützt.
Nun, meine Heizung generiert automatisch NUR solche readings.
Vermutlich klappt Escapen, habe das richtige noch nicht gefunden, wollte aber fragen, ob es nicht möglich wäre / sinnvoll ist, dass
DBLog das Attribut automatisch korrekt escaped?
sG
Joe
Hallo Joe,
habe die Version in #683 angepasst und neu hochgeladen.
Schau mal ob auch das nun klappt.
Update: Das betrifft sowohl addLog als auch das normale Logging. DbLogInclude mit/ohne Minintervall habe ich auch angepasst. Bitte die Varianten komplett testen !
Grüße,
Heiko
Hi,
ist bei dir/euch auch alles ok mit der v3.10.0 ?
Ich würde die V in Kürze einchecken wenn nichts negatives aufgefallen ist.
LG,
Heiko
Sie läuft, unauffällig;-)
Hab die Features im Einsatz, aber noch nicht im Detail kontrollieren können.
Die Plots jedenfalls sehen sehr gut aus!!
SG und frohe Ostern!
Joe
Danke Joe und ebenfalls schöne Ostern !
Heiko
Hi Heiko,
Noch eine Frage: kann man bei addLog im Event auch das aufrufende Device, also das at oder doif Device mit aufnehmen? Ich bräuchte das zur Differenzierung in valueFn, da ich je nach aufrufer was anderes machen müsste.
Oder hast du eine andere Idee dazu?
SG Joe
Morgen Joe,
eine Idee wäre einen Qualifier CN=<aufrufer> einzuführen.
Den Aufrufer müsste man im at oder doif in eine Variable stecken und den CN mitgeben.
In der addlog Funktion würde ich dem aus devspec resultierenden device das CN davorsetzen, also in der Art <CN>#device sofern CN angegeben.
In valueFn müsste man dann $DEVICE checken und ggf. splitten um CN zu extrahieren und damit dann die Steuerung vorzunehmen.
Das ist zwar ein bisschen Aufwand, aber sicherlich machbar und mir fällt momentan auch keine bessere Variante ein.
Vielleicht hat jemand noch eine bessere Idee.
Was denkst du / ihr ?
LG,
Heiko
Hallo Heiko,
Würden dann nicht bestehende Scripte nicht mehr funktionieren?
Spricht etwas dagegen eine eigene, neue Variable einzuführen?
Das splitten sehe ich als unproblematisch.
Schöne Grüße Joe
was meinst du für Scripte genau ?
Man könnte auch $CN=<aufrufer> implementieren und die Variable $CN in valueFn auswertbar anbieten. Das wäre noch besser und vermindert den Aufwand splitten usw.
Naja, ich müsste das alles auch erstmal entwickeln und testen ... aber so im Prinzip als Idee .....
Hallo Heiko,
Zitat von: DS_Starter am 06 April 2018, 11:30:08
was meinst du für Scripte genau ?
wenn $DEVICETYPE (wann wurde $DEVICE zu $DEVICETYPE umbenannt?) nicht mehr "heizkoerper" ist, sondern eben "cronjob#heizkoerper",
würden plötzlich schon vorhandene Scripte nicht mehr funktionieren.... (oder habe ich deineen Vorschlag falsch verstanden?
Von daher fände ich die Idee mit
$CN=<aufrufer>
besser, wenn nicht optimal.
Hintergrund:
Ich muss genau um 00:00:00 einige Werte loggen! Nun braucht FHEM manchmal etwas länger, sodass die letzten Werte dann erst um 00:00:01 geloggt werden!
Das macht probleme in Plots und anderen Scripten, weshalb ich per valueFn in diesem Fall die Uhrzeit eben wieder zurück ändere auf 00:00:00
(über)
if($DEVICETYPE eq "addLog" and $TIMESTAMP =~ m/\s00:00:[\d:]+/){
$TIMESTAMP =~ s/([^\s]+)\s/\1 00:00:00/
}Nun, trifft das eben manchmal auch auf andere addLogs zu was auch zu deren Zeitverschiebung führt. Das wäre falsch!
Daher würde ich eben gerne noch die Quelle, also "and $CN =~ m/cronjob.midnight/"
zu meiner Prüfung ergänzen...
sG
Joe
Ok, verstanden.
Aber
wann wurde $DEVICE zu $DEVICETYPE umbenannt?
garnicht. $DEVICE heisst noch und $DEVICETYPE gibt es extra.
Ich entwerfe dann mal was und dann schauen wir ... :)
LG,
Heiko
Hallo Joe,
addLog habe ich erweitert. Es wäre jetzt so anzuwenden:
set <name> addLog <devspec>:<Reading> [Value] [CN=<caller name>] [!useExcludes]
<caller name> ist das aufrufende Device (at etc.) oder ein beliebiger Erkennungsstring. Also zum Beispiel:
set <dblog> addLog USV:state CN=Test
In valueFn kann nun $CN ausgewertet werden, z.B.:
if ($CN eq "Test") {$READING = "statetest"}
Viel Spass beim Test ...
LG,
Heiko
Hallo Joe,
wie sieht es aus ? Passt die Erweiterung ?
LG,
Heiko
Hallo Heiko, bin noch am Heimflug und erst morgen wieder im Land. Werds dann gleich ansehen!
Sorry.
SG Joe
Hallo Heiko,
konnte mir das Update nun genauer ansehen... habe dazu aber noch eine Rückfrage:
Wäre es möglich, dass CN automatisch gefüllt wird, oder ist das im momentanen Kontext her kaum möglich?
define di.cronjob ([00:00])\
(set <dblog> addLog USV:state)
Könnte nicht in diesem Fall das CN automatisch "di.cronjob" lauten, um dann über
if ($CN eq "di.cronjob") {$READING = "statetest"}
mein ziel zu erreichen?
Für mich funktioniert die aktuelle Lösung gut, jedoch denke ich wäre die automatische Befüllung weniger "Erklärungsbedürftig".
Für meinen Zweck wäre die aktuelle Umsetzung jedoch top!!
sG
Joe
Hi Joe,
nun ja ich wüßte nicht wie CN lauten soll wenn es dem addLog Aufruf nicht mitgegeben wird.
Ich "sehe" ja aus Perspektive DbLog nur
addLog USV:state
und entnehme daraus was passieren soll. Dem set wird nicht automatisch der aufrufenden Device name übergeben, zumindest nicht das ich wüßte.
Deswegen brauche ich diesen kleinen Zusatz um entsprechende Zuweisungen vornehmen zu können.
Dann ergänze ich mal die commandref hoffentlich einigermaßen verständlich :) und checke den Stand ein.
LG,
Heiko
Top! Mein Beispiel aus #693 könnte für die commandref als Beispiel dienen?
Danke! SG Joe
Ja, ich bastele was für die commandref zusammen damit es möglichst transparent wird.
LG,
Heiko
Hallo Heiko,
habe leider übersehen dass ich im Beispiel für "\1" eine Perlwarnung bekomme.
PERL WARNING: \1 better written as $1
kannst Du bitte bei Gelegenheit das in der commandref tauschen?
Hier die korrigierte Zeile ohne \1
{$TIMESTAMP=~ s/\s([^\s]+)/ 00:00:00/; }
Zusätzlich ist mir heute Nacht aufgefallen, dass ein Device mit addLog nicht geloggt wird
mit der Begründung:
Device: "Gaszaehler", reading: "verbrauch_EnergyDay" excluded by attribute DbLogExclude from addLog !
Der Aufruf enthielt aber "!useExcludes".
set <Device> addLog Gaszaehler:verbrauch_EnergyDay.* 0 !useExcludes CN=midnight
Kann es sein, dass der default Wert 0 hier irgendwie das !useExcludes "schluckt"?
sG
Joe
Morgen Joe,
ZitatKann es sein, dass der default Wert 0 hier irgendwie das !useExcludes "schluckt"?
Kann eigentlich nicht sein.
Ich werde heute Abend das auch mal simulieren.
Danke für die Korrektur. Baue ich mal mit ein.
LG,
Heiko
Habs gerade probiert. Klappt einwandfrei was !useExcludes betrifft. Allerdings habe ich einen Fehler festgestellt dass "0" wieder nicht zieht und habe es gleich korrigiert.
Hier angehängt.
Grüße,
Heiko
Hallo Heiko,
habe oben mein Beispiel wegen \1 nochmal völlig geändert, da es so noch nicht funktionierte.
habe soeben festgestellt, dass $TIMESTAMP in valueFn zwischen 2 addLog-Readingeinträgen nicht zurückgesetzt wird.
Um das zu verdeutlichen, habe ich den Timestamp in die Unit-Spalte kopiert:
Beispiel valueFn
if($CN eq "test"){
$UNIT= "OrgTS: ".$TIMESTAMP;
$TIMESTAMP=~ s/\s([^\s]+)/ 23:59:59/;
}
der Aufruf lautet:
set sql addLog Gaszaehler:verbrauch_EnergyDay.* !useExcludes CN=test
Ale Ergebnis bekomme ich
84042 => 2018-04-10 23:59:59|Gaszaehler|KNX|addLog|verbrauch_EnergyDay|0.000|OrgTS: 2018-04-10 08:43:53
84043 => 2018-04-10 23:59:59|Gaszaehler|KNX|addLog|verbrauch_EnergyDayLast|0.000|OrgTS: 2018-04-10 23:59:59
wobei mich in der 2. zeile das 23:59:59 in der unit-Spalte wundert.
sG
Joe
Hallo Joe,
Zitathabe soeben festgestellt, dass $TIMESTAMP in valueFn zwischen 2 addLog-Readingeinträgen nicht zurückgesetzt wird.
Das ar wieder ein ganz gemeiner Fehler der sich gut versteckt hatte.
Habe es korrigiert und auch die commandref angepasst.
Anbei die finale V3.10.3 die ich heute auch noch einchecken will.
LG,
Heiko
Hallo heiko,
herzlichen Dank !!!
Hm, wieder so eine Idee:
Da kürzlich funktionen wie "OldReadingsVal" und "OldReadingsNum"
hinzugefügt wurden (siehe https://svn.fhem.de/trac/changeset/16349)
wünsche ich mir so etwas auch mit Daten aus der Datenbank!
Über "OldReadingsVal" kann ich mir ältere Werte im Speicher halten.
Nun würde ich aber gerne im Status meines Wettermoduls gerne die Temperatur von gestern zur selben Tageszeit wie jetzt gerade als Vergleichswert anzeigen lassen,
welche natürlich nicht mehr im Speicher sind.
Dazu stelle ich mir eine analoge Funktion "DbLogReadingsVal(<device>,<reading>,<default>,<timestamp>[,<mode>])" vor.
(Name nur ein Vorschlag!)
Diese könnte einfach den Wert des readings zum Zeitpunkt "timestamp" zurückgeben.
Timestamp würde ich im stateFormat beispielsweise mit
$TIMESTAMP = strftime("%Y-%m-%d", ( localtime(time-60*60*24)) )
angeben, um das gestrige Datum zur selben Uhrzeit zu erhalten.
Da fast nie zum genauen Zeitpunkt (auf die Sekunde genau) ein Wert abgespeichert wird,
suche ich mir mit folgendem SQL-Statement den Wert heraus, der meinem Timestamp am nächsten ist.
((Ich benutze hier bewußt 2 separate Selects mit Union, um den index nutzen zu können!))
select value from
(
( select *, TIMESTAMPDIFF(SECOND, '2018-04-10 09:45:00', timestamp) as diff
from history where device='kitchen.hygro' and reading='temperature' and timestamp >= '2018-04-10 09:45:00'
order by timestamp asc limit 1
)
union
( select *, TIMESTAMPDIFF(SECOND, timestamp, '2018-04-10 09:45:00') as diff
from history where device='kitchen.hygro' and reading='temperature' and timestamp < '2018-04-10 09:45:00'
order by timestamp desc limit 1
)
) x
order by diff
limit 1;
Über den optionalen Parameter "mode" könnte man andere Modi für den vergleich schalten, wie "<=", "<", oder eben die Suche in beide Richtungen, wie in meinem Beispiel.
per
set <dblog> userCommand select [...]funktioniert das schon, da ich das aber oft benötige und das anschließende Auslesen des Readings bei gleichzeitigen Befehlen nicht immer sauber klappt, würde ich die oben genannte Funktion vorschlagen.
Ich denke/hoffe, dass dies doch eine eher einfache Funktion wird, leider kann ich jedoch die SQL-Befehle für Postgres nicht beisteuern.
Mein gewünschtes stateFormat -Attribut würden dann in etwa so aussehen:
{ "Aktuelle Temperatur ist ".ReadingsNum($name,"temperature","").
"Gestern war diese ".DbLogReadingsVal($name,"temperature","",
strftime("%Y-%m-%d", ( localtime(time-60*60*24))))
}
sG
Joe
Hallo Heiko,
dieser Aufruf aus DOIF heraus um 23:59:59 hat folgenden Eintrag in der Datenbank
mit der gestrigen Version von DbLog verursacht:
set sql addLog Gaszaehler:verbrauch_EnergyDay.* !useExcludes CN=z59
2018-04-10 23:59:59;Gaszaehler;KNX;addLog;state;verbrauch_EnergyDay: ;""
Als Reading wurde also "state" eingetragen und als value der readingname "verbrauch_EnergyDay" gefolgt von einem Doppelpunkt.
Der Regex ".*" scheint nicht ausgewertet worden zu sein.
Der nächste Aufruf eine sekunde später mit
set sql addLog Gaszaehler:verbrauch_EnergyDay.* 0 !useExcludes CN=z60
scheint funktioniert zu haben:
TIMESTAMP;DEVICE;TYPE;EVENT;READING;VALUE;UNIT;datatype
2018-04-11 00:00:00;Gaszaehler;KNX;addLog;verbrauch_EnergyDay;0;""
2018-04-11 00:00:00;Gaszaehler;KNX;addLog;verbrauch_EnergyDayLast;0;""
Hast Du dafür eine Erklärung?
Ich würde es aber heute auch nochmal mit der aktuellen Version von letzter nacht testen, habe das Update gerade gemacht.
sG
Joe
Hallo Joe,
wird irgendwie nicht langweilig ;D
Finde ich eine interessante Sache, würde sowas aber ins DbRep integriereren -> Auswertung, nonblocking etc.
Wenn du deine Versuche mit dbrep sqlCmd durchführen würdest wäre das super.
Allerdings habe ich versprochen mich erstmal um das https://forum.fhem.de/index.php/topic,86781.0.html zu kümmern. Dauert also ein bisschen.
Dein gerade geschildertes Problem kann ich mir momentan auch nicht erklären.
LG,
Heiko
Hallo Heiko,
Zitat von: DS_Starter am 11 April 2018, 10:12:45
wird irgendwie nicht langweilig ;D
Ich weiß, sorry :-[
Zitat von: DS_Starter am 11 April 2018, 10:12:45
Finde ich eine interessante Sache, würde sowas aber ins DbRep integriereren -> Auswertung, nonblocking etc.
Prinzipiell habe ich dazu keine Präferenz, jedoch stelle ich mir "DbLogReadingsVal" eher als global verfügbar vor,
analog eben zu den bekannten und weit verbreiteten Funktionen ReadingsVal, ReadingsNum, sowie den neueren Erweiterungen dazu
(OldReadingsVal, OldReadingsNum, ...).
Ich denke, dass die Benutzung eben einfach und wenig erklärungsbedürftig ist, wenn es sich gleich bedienen lässt.
Ein DbRep-Device müsste ich im Vorfeld dazu immer definieren.... aber generell ist das dann für mich schon eher eine Nebensache!
Zitat von: DS_Starter am 11 April 2018, 10:12:45
Wenn du deine Versuche mit dbrep sqlCmd durchführen würdest wäre das super.
habe ich gemacht, wenn ich dort aber
attr <dev> widgetOverride sqlCmd:textField-longsetze, und meinen SQL-Code absetze, kommt es aus dem Status "running" nicht mehr zurück.
Auf der Datenbank selber läuft dann jedoch keine Abfrage.
wenn ich meinen SQL-Code als Einzeiler umformatiere, geht es.
sqlCmd scheit Zeilenwechsel nicht zu mögen. Das sollte aber vermutlich eher dort weiterdiskutiert werden ;-)
Das Verbose5 Log zeigt nur dies
2018.04.11 10:57:35 4: DbRep rep.DbLogReadingsVal - SQL execute: select value from
2018.04.11 10:57:36 4: DbRep rep.DbLogReadingsVal - SQL result: 16.10anbei das list auf das Device, das den Status noch immer als "running" zeigt:
Internals:
CFGFN
DATABASE fhem
DEF sql
LASTCMD sqlCmd select value from
(
( select *, TIMESTAMPDIFF(SECOND, '2018-04-10 09:45:00', timestamp) as diff
from history where device='kitchen.hygro' and reading='temperature' and timestamp >= '2018-04-10 09:45:00'
order by timestamp asc limit 1
)
union
( select *, TIMESTAMPDIFF(SECOND, timestamp, '2018-04-10 09:45:00') as diff
from history where device='kitchen.hygro' and reading='temperature' and timestamp < '2018-04-10 09:45:00'
order by timestamp desc limit 1
)
) x
order by diff
limit 1;
NAME rep.DbLogReadingsVal
NOTIFYDEV global,rep.DbLogReadingsVal
NR 495
NTFY_ORDER 50-rep.DbLogReadingsVal
ROLE Client
STATE running
TYPE DbRep
UTF8 0
VERSION 7.15.0
HELPER:
DBLOGDEVICE sql
MINTS 2017-12-07 09:19:12
SQLHIST
CV:
aggregation day
aggsec 86400
destr 2018-04-11
dsstr 2017-12-07
epoch_seconds_end 1523437055
mestr 04
msstr 12
testr 10:57:35
tsstr 09:19:12
wdadd 345600
yestr 2018
ysstr 2017
RUNNING_PID:
abortFn DbRep_ParseAborted
arg rep.DbLogReadingsVal|sqlCmd|2018-04-11|2018-04-11 10:57:35|select value from
(
( select *, TIMESTAMPDIFF(SECOND, '2018-04-10 09:45:00', timestamp) as diff
from history where device='kitchen.hygro' and reading='temperature' and timestamp >= '2018-04-10 09:45:00'
order by timestamp asc limit 1
)
union
( select *, TIMESTAMPDIFF(SECOND, timestamp, '2018-04-10 09:45:00') as diff
from history where device='kitchen.hygro' and reading='temperature' and timestamp < '2018-04-10 09:45:00'
order by timestamp desc limit 1
)
) x
order by diff
limit 1;
bc_pid 168
finishFn sqlCmd_ParseDone
fn sqlCmd_DoParse
loglevel 5
pid DEAD:26999
telnet telnetPort_127.0.0.1_59226
terminated 1
timeout 86400
abortArg:
Helper:
DBLOG:
state:
sql:
TIME 1523435242.76449
VALUE initialized
READINGS:
2018-04-11 10:57:35 state running
dbloghash:
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION /opt/fhem/db-mysql.conf
DEF /opt/fhem/db-mysql.conf .*:.*
MODE asynchronous
MODEL MYSQL
NAME sql
NR 22
NTFY_ORDER 50-sql
PID 14820
REGEXP .*:.*
STATE connected (9)
TYPE DbLog
UTF8 0
VERSION 3.10.3
dbconn mysql:database=fhem;mysql_socket=/var/run/mysqld/mysqld.sock
dbuser fhemuser
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 512
OLDSTATE connected
READINGCOL 64
TYPECOL 64
UNITCOL 32
VALUECOL 128
Helper:
DBLOG:
CacheUsage:
sql:
TIME 1523437212.85604
VALUE 124
background_processing_time:
sql:
TIME 1523437213.07536
VALUE 0.1381
sql_processing_time:
sql:
TIME 1523437213.07536
VALUE 0.1101
userCommand:
sql:
TIME 1523435608.49739
VALUE select value from ( ( select *, TIMESTAMPDIFF(SECOND, '2018-04-10 09:45:00', timestamp) as diff from history where device='kitchen.hygro' and reading='temperature' and timestamp >= '2018-04-10 09:45:00' order by timestamp asc limit 1 ) union ( select *, TIMESTAMPDIFF(SECOND, timestamp, '2018-04-10 09:45:00') as diff from history where device='kitchen.hygro' and reading='temperature' and timestamp < '2018-04-10 09:45:00' order by timestamp desc limit 1 ) ) x order by diff limit 1
userCommandResult:
sql:
TIME 1523435608.5275
VALUE 16.10
READINGS:
2018-04-11 11:00:15 CacheUsage 9
2018-04-11 11:00:12 NextSync 2018-04-11 11:01:12 or if CacheUsage 500 reached
2018-04-11 11:00:13 background_processing_time 0.1381
2018-04-09 14:43:58 lastCachefile ./log/cache_sql_2018-03-22_10-39-17 import successful
2018-04-11 11:00:13 sql_processing_time 0.1101
2018-04-11 11:00:13 state connected
2018-04-11 10:33:28 userCommand select value from ( ( select *, TIMESTAMPDIFF(SECOND, '2018-04-10 09:45:00', timestamp) as diff from history where device='kitchen.hygro' and reading='temperature' and timestamp >= '2018-04-10 09:45:00' order by timestamp asc limit 1 ) union ( select *, TIMESTAMPDIFF(SECOND, timestamp, '2018-04-10 09:45:00') as diff from history where device='kitchen.hygro' and reading='temperature' and timestamp < '2018-04-10 09:45:00' order by timestamp desc limit 1 ) ) x order by diff limit 1
2018-04-11 10:33:28 userCommandResult 16.10
cache:
index 14144
Attributes:
DbLogExclude .*
aggregation day
allowDeletion 1
devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
device Gaszaehler
event-on-change-reading state
event-on-update-reading state,--DELETED_ROWS_CURRENT--
reading verbrauch_EnergyDay
room Manuell,System
verbose 5
widgetOverride sqlCmd:textField-longsG
Joe
Hallo Joe,
Zitat
Als Reading wurde also "state" eingetragen und als value der readingname "verbrauch_EnergyDay" gefolgt von einem Doppelpunkt.
Der Regex ".*" scheint nicht ausgewertet worden zu sein.
den Fehler habe ich im Rahmen der Fehlerbereinigung (https://forum.fhem.de/index.php/topic,86863.0.html) gefunden und erledigt/eingecheckt. Der war reingekommen als ich das Problem mit value "0" bereinigt hatte ... echt schlimm manchmal :(
ZitatPrinzipiell habe ich dazu keine Präferenz, jedoch stelle ich mir "DbLogReadingsVal" eher als global verfügbar vor,
Ja, so hatte ich es auch verstanden. Als global verfügbares Kommando.
Ich möchte es deswegen im DbRep haben weil es eine Auswertung der DB darstellt und ich versuche die Funktionstrennung DbLog=Loggen und DbRep=Auswertung so strikt wie möglich umzusetzen. Es sind aus historischen Gründen ja bereits Funktionen im DbLog, die eigentlich ins DbRep gehören. Weil sie schon immer dort sind, will ich das auch nicht ändern.
Aber bei neuen Funktionalitäten versuche ich die Trennung so gut es geht einzuhalten.
Zitat
habe ich gemacht, wenn ich dort aber
Code: [Auswählen]
attr <dev> widgetOverride sqlCmd:textField-long
setze, und meinen SQL-Code absetze, kommt es aus dem Status "running" nicht mehr zurück.
Auf der Datenbank selber läuft dann jedoch keine Abfrage.
wenn ich meinen SQL-Code als Einzeiler umformatiere, geht es.
Muss ich checken/abändern. Ja, passt eher zu dem anderen Thread ;)
Grüße,
Heiko
Hallo Joe,
habe soeben DbRep V7.15.1 eingecheckt.
Die Version akzeptiert nun das textlong-Widget für sqlCmd.
Kannst du morgen dann weiter deine SQL testen.
Grüße,
Heiko
Hallo Heiko,
danke!!
Zitat von: DS_Starter am 11 April 2018, 10:12:45
Wenn du deine Versuche mit dbrep sqlCmd durchführen würdest wäre das super.
Nur zur info, aber mit dbrep funktioniert es nicht!
Wenn ich folgendes als
stateFormat eintrage, funktioniert es mit nur mit dem dblog-device
{
fhem("set sql userCommand select value from ( ( select *, TIMESTAMPDIFF(SECOND, '". strftime("%Y-%m-%d %H:%M", ( localtime(time-60*60*24)))."', timestamp) as diff from history where device='kitchen.hygro' and reading='temperature' and timestamp >= '". strftime("%Y-%m-%d %H:%M", ( localtime(time-60*60*24)))."' order by timestamp asc limit 1 ) union ( select *, TIMESTAMPDIFF(SECOND, timestamp, '". strftime("%Y-%m-%d %H:%M", ( localtime(time-60*60*24)))."') as diff from history where device='kitchen.hygro' and reading='temperature' and timestamp < '". strftime("%Y-%m-%d %H:%M", ( localtime(time-60*60*24)))."' order by timestamp desc limit 1 ) ) x order by diff limit 1");
sprintf "T: %4.1f° ".
"(%4.1f°) ".
"H: %d%% ".
"A: %3.1fg ".
"D: %3.0f°",
ReadingsNum($name,"temperature-get",undef),
ReadingsVal("sql","userCommandResult",undef),
ReadingsNum($name,"hygrorel-get",undef),
ReadingsNum($name,"hygroAbs-get",undef),
ReadingsNum($name,"taupunkt-get",undef)
}aber mit dbrep (vermutlich wegen nonblocking) nicht!
Diese Abfrage
ReadingsNum("rep","SqlResultRow_1",undef)ist direkt nach dem Absetzen des Befehls immer "undef", und wird erst später gefüllt.
Bei DbLog funktioniert das oben genannte Beispiel.
sG Joe
Ja genau, Dbrep arbeitet non-blocking.
Speziell für so ein Userinterface oder eine API wie du oben geschrieben hattest müsste ich die Voraussetzungen schaffen und habe auch eine Idee dazu. Dauert halt etwas ...
LG,
Heiko
Aber schaudir im dbrep mal das Attr usercExitFn an !
Das ist für meine Anwendung nicht so passend, da ich danach dann den State nochmal anpassen/aktualisieren müsste.
Wenn ich alles in stateFormat zusammenbaue, wird dieser nur einmal aktualisiert.
Aber danke für den Hinweis!
Hallo Heiko,
sehe aktuell dies hier öfter im Log?
PERL WARNING: Use of uninitialized value $out_value in concatenation (.) or string at ./FHEM/93_DbLog.pm line 2888.
sG
Joe
Hallo Joe,
diese Warnung hat irgendetwas mit der SVG-Generierung zu tun.
Ich bin momentan nicht dahinter gekommen in welcher Situation genau das $out_value nicht vorhanden ist.
Dieser Wert ist in ziemlichen Untiefen der DbLog_Get-Funktion versteckt. Allerdings ist diese Warnung bei mir noch nie augetreten. Möglicherweise tritt sie nur in einer bestimmten Konstellation auf.
Vielleicht bekommst du etwas genauer heraus bei welchem SVG-Aufruf die Warung kommt damit man daraus evtl. etwas ableiten kann.
Grüße
Heiko
Hallo Heiko,
ja, es war wenn im Plot "undef" als Wert genutzt wurde im eine Linie unterbrechen zu lassen...
sG
Joe
Stelle mir die Frage, ob man diese "Erweiterung", die von Rudi sogar als Fehler bezeichnet wurde,
von Filelog in DbLog nachziehen sollte:
https://forum.fhem.de/index.php/topic,88084
sG Joe
Moin @all,
da ich auch so meine Probleme mit meinem RPi3 und MySQL auf dem NAS habe:
https://forum.fhem.de/index.php/topic,88361.0.html
Hatte ich mir überlegt, ob man bei der Durchführung eines reduceLog(Nbl) o.ä. auf schwacher HW wie dem RPi aber der DB auf dem NAS, den RPi nicht komplett aussen vor lassen kann, indem man die Bereinigung/Berechnung direkt server-seitig (also auf dem NAS selbst) durchführen kann.
MySQL kennt ab ca. 5.1.irgendwas den EventScheduler mit dem man ggf. eine stored Procedure anwerfen kann.
Da (zumindest mein NAS) deutlich kräftiger als der RPi ist, würde es aus meiner Sicht Sinn machen, da man dann auch nicht die Daten hin und her zu schicken muss.
Allerdings fehlt mir das Wissen, ob und wenn ja, wie das geht.
Was sagt ihr?
blofield
Zitat von: blofield am 03 Juni 2018, 12:20:07
Moin @all,
da ich auch so meine Probleme mit meinem RPi3 und MySQL auf dem NAS habe:
https://forum.fhem.de/index.php/topic,88361.0.html
Ich habe mir nur die Einleitung eines Posts durchgelesen. Ich hatte ähnliche Probleme aber seit ich auf Devices einschränke läuft es ... kannst ma testen
set myDbLog reduceLogNbl 30 INCLUDE=%TempSensor%:humidity ; sleep 180 ;
set myDbLog reduceLogNbl 30 INCLUDE=%TempSensor%:pressu% ; sleep 180 ;
set myDbLog reduceLogNbl 30 INCLUDE=Heizung_%:measured-temp ; sleep 180 ;
Einziger Nachteil ... die in den Readings gespeicherten Statistiken sind vom letzen Teil. Für mich kein Showstopper
Zitat von: blofield am 03 Juni 2018, 12:20:07
Allerdings fehlt mir das Wissen, ob und wenn ja, wie das geht.
Was sagt ihr?
Gehen tut das sicher. Frage des Aufwands. Ggf. kannst du auch Perl auf dem NAS installieren wenn das möglich ist, dann kannst die Logik aus fhem-Modul sicher übernehmen und muss nur Teile anpassen. Du liest zwar immer noch DAten aus, aber die bleiben lokal auf dem NAS und nutzt die Resourcen die du dort hast ohne Fhem lahmzulegen.
Zitat von: kadettilac89 am 03 Juni 2018, 17:40:28
Ich habe mir nur die Einleitung eines Posts durchgelesen. Ich hatte ähnliche Probleme aber seit ich auf Devices einschränke läuft es ... kannst ma testen
set myDbLog reduceLogNbl 30 INCLUDE=%TempSensor%:humidity ; sleep 180 ;
set myDbLog reduceLogNbl 30 INCLUDE=%TempSensor%:pressu% ; sleep 180 ;
set myDbLog reduceLogNbl 30 INCLUDE=Heizung_%:measured-temp ; sleep 180 ;
Einziger Nachteil ... die in den Readings gespeicherten Statistiken sind vom letzen Teil. Für mich kein Showstopper
Danke! Werde ich mal testen.
Alternativ hatte ich mir auch überlegt auf dem NAS fhem selbst zu installieren, nur mit DbLog und dann dort das reduceLog anzuschmeißen.
Schöner wäre aber direkt in SQL ;)
blofield
Sind das immer die selben Arten von Daten, die ihr löschen wollt? Es gibt noch die sehr schnelle Löschmethode über Datenbankpartitionen, jedoch muss man dafür vorabgenauer planen....
SG Joe
Hallo Joe,
wäre es denn möglich die Einrichtung von Datenbankpartitionen als Template z.B. im DbRep dem User anzubieten ?
Damit meine ich die Möglichkeit dem User eine Scriptgestützte Einrichtung/Verwaltung zu ermöglichen.
Wollte jetzt nicht vom eigentlichen Thema ablenken, fiel mir gerade so ein. Wenn ja, können wir uns vllt. im DbRep-Thread dazu austauschen.
LG,
Heiko
Hallo Joe,
es geht halt um das normale reduceLogNbl, um die Datenbank auszudünnen.
Ich bin auch schon über die Partitionen gestolpert hatte aber verstanden, dass die leider nicht so einfach auf den Timestamp zu machen sind - was man in diesem Falle aber ja genau möchte.
Mein RPi steigt halt aus, wenn es zuviele Daten pro Tag sind.
Ich versuche jetzt mal mit Include/Exclude ... aber es wäre ja eleganter (zumindest in Konstellation mit DB auf dem NAS) das alles nicht vom RPi machen zu lassen. Ich kenne das aus der Firma von Hadoop, da bringst Du den Rechenprozess zu den Daten und nicht anders herum ;) Daher der Ansatz, das irgendwie in (My)SQL mit dem EventScheduler zu koppeln.
blofield
Noch eine Idee. Je nachdem wie die Daten aussehen und wie das Ziel ist, kannst du evtl. auch die delSeqDoublets Funktion im DbRep verwenden.
Hallo Heiko,
hallo blofield:
Zitat von: DS_Starter am 03 Juni 2018, 19:26:00
wäre es denn möglich die Einrichtung von Datenbankpartitionen als Template z.B. im DbRep dem User anzubieten ?
Ja, das wäre in MySQL einfach möglich, auch ein zurückswitchen ist problemlos.
Dies funktioniert alles über ein "alter table".
Zitat von: blofield am 03 Juni 2018, 19:35:28
Ich bin auch schon über die Partitionen gestolpert hatte aber verstanden, dass die leider nicht so einfach auf den Timestamp zu machen sind - was man in diesem Falle aber ja genau möchte.
Das ist prinzipiell korrekt, wenn man aber zB die Daten vorab schon sortiert und die Partitionierung in Wochentage unterteilt,
kann man zB alle nur zur Berechnung von Stundenwerten benötigten Daten von gestern ohne jegliche Wartezeit und fast ohne Systembelastung
innerhalb von 0.1s löschen.
Zitat von: blofield am 03 Juni 2018, 19:35:28
Ich versuche jetzt mal mit Include/Exclude ... aber es wäre ja eleganter (zumindest in Konstellation mit DB auf dem NAS) das alles nicht vom RPi machen zu lassen. Ich kenne das aus der Firma von Hadoop, da bringst Du den Rechenprozess zu den Daten und nicht anders herum ;) Daher der Ansatz, das irgendwie in (My)SQL mit dem EventScheduler zu koppeln.
Davon würde ich mir nicht zuviel Verbesserung versprechen, denn das aufwändige ist nicht, den "delete" prozess vom rpi an den mysql zu senden, sondern
die Daten am mySQL tatsächlich zu löschen. Da wir hier eine flache DB strucktur haben gehe ich davon aus, dass dies eher sogar länger dauert als zeitersparnis bringt.
sG
Joe
Morgen Joe,
danke für deinen Hinweis. Dann schaue ich mir das mal bei Gelegenheit an. Dauert aber etwas weil ich mich momentan um ein paar Themen meines SSCam bzw. DbRep kümmere.
Aber die Technik wäre sicherlich etwas für den einen oder anderen MySQL-User.
Die technische Löung im Modul (wahrscheinlich DbRep) können wir uns dann im entsprechenden Thread anschauen/diskutieren.
LG,
Heiko
Moin Joe,
Hast Recht. Hat statt ~700s diesmal 4200s gedauert. Und reboot gab es dann auch noch. :-/
Das mit den Partitionen hört sich gut an.
Ich habe gestern noch ein bisschen mit dem Event Scheduler experiment. Für DeleteOld wäre das z.B. sehr einfach umsetzbar.
Ich werde das die Woche Mal ausgiebig testen und dann Feedback geben.
blofield
Gesendet von meinem ONEPLUS A5000 mit Tapatalk
Hallo Heiko, @All.
EDIT: diskussion hierrüber wird im Thread DbRep weitergeführt. (Siehe https://forum.fhem.de/index.php/topic,53584.msg808229.html#msg808229)
Anbei ein Tabellenlayout, das die Daten nach Wochentage und anschließend noch nach der neuen Spalte "Longterm" partitioniert. (Als Diskussionsgrundlage).
CREATE TABLE `history` (
`TIMESTAMP` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
`DEVICE` VARCHAR(64) NOT NULL DEFAULT '',
`TYPE` VARCHAR(32) NULL DEFAULT NULL,
`EVENT` VARCHAR(512) NULL DEFAULT NULL,
`READING` VARCHAR(64) NOT NULL DEFAULT '',
`VALUE` VARCHAR(32) NULL DEFAULT NULL,
`UNIT` VARCHAR(32) NULL DEFAULT NULL,
`Longterm` TINYINT(4) NOT NULL DEFAULT '0',
PRIMARY KEY (`DEVICE`, `READING`, `TIMESTAMP`, `Longterm`),
INDEX `Reading_Time_Idx` (`READING`, `TIMESTAMP`) USING BTREE
)
COLLATE='latin1_swedish_ci'
PARTITION BY RANGE (WEEKDAY(timestamp))
SUBPARTITION BY HASH (Longterm)
(PARTITION mon VALUES LESS THAN (1)
(SUBPARTITION monNolong ENGINE = Aria,
SUBPARTITION monLong ENGINE = Aria),
PARTITION tue VALUES LESS THAN (2)
(SUBPARTITION tueNolong ENGINE = Aria,
SUBPARTITION tueLong ENGINE = Aria),
PARTITION wed VALUES LESS THAN (3)
(SUBPARTITION wedNolong ENGINE = Aria,
SUBPARTITION wedLong ENGINE = Aria),
PARTITION thu VALUES LESS THAN (4)
(SUBPARTITION thuNolong ENGINE = Aria,
SUBPARTITION thuLong ENGINE = Aria),
PARTITION fri VALUES LESS THAN (5)
(SUBPARTITION friNolong ENGINE = Aria,
SUBPARTITION friLong ENGINE = Aria),
PARTITION sat VALUES LESS THAN (6)
(SUBPARTITION satNolong ENGINE = Aria,
SUBPARTITION satLong ENGINE = Aria),
PARTITION sun VALUES LESS THAN (7)
(SUBPARTITION sunNolong ENGINE = Aria,
SUBPARTITION sunLong ENGINE = Aria)) ;
Diese Tabelle kann so jetzt schon in FHEM verwendet werden, ohne Codeänderung.
(Jedoch können die möglichen Vorteile noch nicht direkt genutzt werden.)
Somit könnte die Codeunterstützung jedoch schritt für schritt einfach ergänzt werden!
Eventuell sollte der default bei Longterm statt 0 auf 1 gesetzt werden.
(Man kann Longterm natürlich auch um die Werte 2,3,4,5, etc. ergänzen, wenn es sinn macht. Zb. analog zum Verbose level.
Beispielszenario:
Ein Insert eines Datenwertes HEUTE würde mit dieser Tabelle in der Partitionstabelle "monNoLong" landen.
Wenn ich Longterm auf 1 setzem landet er in der Partitionstabelle "monLong".
Ich packe also alle Werte, die ich nicht dauerhaft speichern möchte, in die Tabelle "*NoLong" und die anderen in "*Long".
Am Ende des Tages nehme ich die Werte aus der NoLong-Tabelle und berechne daraus meine Stundenmittel, etc.
Anschließend lösche ich sämtliche Daten (fast) verzögerungsfrei über
ALTER TABLE history TRUNCATE PARTITION monNoLong;
Hilfreiche Codeunterstützung wäre dafür meines Erachtens nach (durchaus in dieser Reihenfolge als einzelne Punkte realisierbar):
1# Erlauben des direkten Setzens von Longterm auf definierte Werte über ein DbLogexclude/Include Attribut.
((im Moment mache ich das in MySQL direkt über einen inserttrigger)))
2# Unterstützung der Tabellenkonfiguration (zB über set DbRep updateHistoryTable [no]partition)
3# Unterstutzung der neuen Löschmöglichkeiten in DbRep
4# Erlauben der Umkategorisierung von Daten von NoLong auf Long über das Modul nach gewissen Parametern.
@Heiko: Ich wollte die Antwort schon in DbRep posten, der Bezug zu DbLog ist aber fast stärker (durch die benötigte Unterstützung im DbLogInclude)....
Wo sollen wir die Diskussion aufteilen?
Edit: Fragen, die wir noch festlegen sopllten:
#1 Werden mehr als 2 Aufbewahrungszeiten (Longterm NoLongterm) benötigt? Ich bin mir hier nicht so sicher, denn die Komplexität steigt dadurch enorm.
sG
Joe
Hi Joe,
alles was einen direkten Bezug zum Logging hat, also die Unterstützung durch "Logging nahe" Attribute wie DbLogExclude gehören ins DbLog.
Aber eigentlich ist das alles ein Datenbank Mangement Thema und gehört deswegen ins DbRep.
Auch ist das auch nur eine Thema was für die MySQL-Familie umgesetzt wird. Möglicherweise kann die Attributunterstützung auch im DbRep erfolgen und DbLog greift darauf zu sofern man die Technologie einsetzt.
Das überblicke ich momentan noch nicht, muss die Entwicklung bringen.
LG,
Heiko
Passt, danke!
Habe den Post dorthin kopiert und hier einen Hinweis dazu hinterlassen.
Zur Ermittlung der aktuellen Datenbankgröße habe ich folgende Helfer-Devices definiert:
defmod at_DBLogging_Size at +*01:00:00 set DBLogging userCommand SELECT ROUND(SUM(data_length + index_length) / 1024 / 1024, 1) FROM information_schema.tables;;
attr at_DBLogging_Size alias Database-Log Size
attr at_DBLogging_Size group Logging
attr at_DBLogging_Size icon edit_save
attr at_DBLogging_Size room System
defmod notify_DBLogging_Size notify DBLogging:userCommand:.SELECT.ROUND.* setreading DBLogging size [DBLogging:userCommandResult]
attr notify_DBLogging_Size alias Database-Log Size Notify
attr notify_DBLogging_Size group Logging
attr notify_DBLogging_Size icon edit_save
attr notify_DBLogging_Size room System
Man könnte das SELECT-Kommando sicherlich auch direkt ins Modul als Get-Befehl integrieren, um das Size Reading zu aktualisieren. Das würde zumindest das Notify Device ersparen :-)
Gruß
Julian
Hallo Julian,
ZitatZur Ermittlung der aktuellen Datenbankgröße habe ich folgende Helfer-Devices definiert
Das gibt es bereits im DbRep. Und auch für alle unterstützen Datenbanken mit entsprechender Abfrage die je nach Typ unterschiedlich sind. Alles nonblocking, falls es länger dauert ;)
MySQL: get ... tableinfo
SQLite: get ... svrinfo
Postgre: get ... svrinfo
Grüße
Heiko
Ah merci, habe ich übersehen, da sie nicht als Getter in der UI angezeigt werden :)
Sent from my iPhone using Tapatalk
Wurde im Modul etwas für die Selektierung der Datensätze zum Anzeigen von Plots geändert?
Mir ist heute aufgefallen, dass meine Plots nicht mehr um Mitternacht enden, und das, obwohl um 00:00 des Folgetags
ein Eintrag in der Datenbank steht! Dies wurde bisher geplottet!
Nun ist mir aufgefallen, dass auch Einträge um 23:59:59 nicht mehr geplottet werden, lediglich um 23:59:58.
Ein Blick in das SQL-Log verrät den Grund:
FROM history WHERE 1=1 AND DEVICE = 'DEVICE' AND READING = 'position' AND TIMESTAMP >= STR_TO_DATE('2018-06-27 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP < STR_TO_DATE('2018-06-27 23:59:59', '%Y-%m-%d %H:%i:%s') ORDER BY TIMESTAMP
< STR_TO_DATE('2018-06-27 23:59:59') führt natürlich zu diesem Ergebnis.
Mir ist im Changelog jedoch diesbezüglich nichts aufgefallen,.... habe ich etwas verpasst?
sG
Joe
Hallo Joe,
Im modul ist schon sehr lange nichts mehr geändert. Der letzt Change von vor ein paar tagen betraf nur ergänzungen in der hilfe.
SG
Heiko
Danke Heiko,
vermutlich hängt es mit diesen Changeset im Modul SVG zusammen.
Zeitstempel:
25.02.2018 20:55:59 (vor 4 Monaten)
Autor:
rudolfkoenig
Nachricht:
98_SVG.pm: correct from/to limits (Forum: #84691)
https://svn.fhem.de/trac/changeset/16275
Jetzt ist nur die Frage, wer recht hat, da es dort ja hauptsächlich um Jahresansichten ging.
Ob man DbLog daraufhin nachziehen muss oder dort noch etwas ändern muss, ist mir im Moment nicht klar.
Jedenfalls sollte ein Tag nicht um 23:59:58 enden, denke ich ;-)
sG Joe
Wie sieht es mit der Änderung in SVG vom 4.6. aus:
https://forum.fhem.de/index.php/topic,88395.0.html (https://forum.fhem.de/index.php/topic,88395.0.html)
Frage doch in dem thread mal nach. Wenn klar ist das wegen diesem change noch etwas im dblog nachgezogen werdem musd mache ich das gerne, muss nur wissen was.
Rudi hat uns gebeten, das auf Seite von DbLog zu korrigieren,
da es in SVG einen großen Rattenschwanz nachziehen würde.
Was ich jedoch noch nicht herausgefunden habe ist, mit welchem Aufruf genau SVG die Daten eines Tages bei DbLog "anfordert".
Wenn ich es recht verstehe, müsste DbLog diese Anforderung dann anders umsetzen, um eben nicht die Einschränkung auf "23:59:58"
zu legen... ?!
Stellen wie
$stm2 .= "AND TIMESTAMP < $sqlspec{to_timestamp} ";
scheinen erstmal "fast" korrekt ( "AND TIMESTAMP <= "x.x.x 00:00:00" wäre korrekt und würde das alte Verhalten wieder herstellen), wenn $sqlspec{to_timestamp} mit "...... 00:00:00" vorbelegt wird, aber irgendwo im Code wird das 00:00:00 nochmal abgeändert?!?.
leider komme ich hier mit meinen bescheidenen Perl-Kenntnissen gerade nicht weiter!
sG
Joe
Hallo Joe,
muss ich mir anschauen. Mit meinem SSCam-Modul bin ich erstmal durch und nehme mir dann wieder DbLog/DbRep vor.
Wird aber wahrscheinlich erst nach meinem Urlaub wieder weitergehen.
Es sei denn jemand stellt einen Patch bereit den ich nach Test einfach übernehmen kann.
Grüße
Heiko
Hallo Heiko,
ich verfolge deine Entwicklungen hier recht genau, auch das SSCam und das Dashboard-Modul ;-) Spannende sachen, vielleicht steig ich auch wieder um auf die Surveillance-Station!
Aber genug OT.
Ich denke, wir warten hier einfach, denn ich kann keinen sauberen Patch liefern. Vielleicht schaff ich einen Workaround, aber so
dringend ist mir das Thema gerade auch nicht, da ich andere Baustellen habe die den WAF mehr beeinflussen.
Bezüglich Partitionierung bin ich übrigens noch am Testen, ob es sich lohnt, eine zusätzliche "decimal"-Spalte einzufügen, um Dezimalwerte direkt dort stall in "value" abzulegen, denn Berechnungen sind damit auch deutlich schneller... Aber... mal sehen!
sG
Joe
Hallo Joe, @all,
ich habe die Selectionsanforderung durch das SVG-Modul im DbLog SQL korrigiert.
Dadurch wird der Select nun so ausgeführt:
SELECT DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s'), DEVICE, READING, VALUE
FROM history WHERE 1=1 AND DEVICE = 'sysmon' AND READING = 'stat_cpu_percent' AND TIMESTAMP >= STR_TO_DATE('2018-09-02 00:00:00', '%Y-%m-%d %H:%i:%s')
AND TIMESTAMP <= STR_TO_DATE('2018-09-02 23:59:59', '%Y-%m-%d %H:%i:%s') ORDER BY TIMESTAMP
Sollte m.M. nach jetzt wieder passen.
Die Version könnt ihr aus contrib herunterladen:
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter
Bitte mal testen und Feedback geben.
LG
Heiko
Hallo Heiko,
danke, dass Du das noch am Schirm hattest.
Die Zeile vergisst aber die letzte Sekunde, denn der Tag geht bis 00:00!
Alles von 23:59:59: bis 00:00:00 gehört noch zum alten tagm und der genaue Zeitpunkt 00:00:00 ist der Anfangs UND auch der Endpunkt für den nächsten Tag.
Daher müsste es
AND TIMESTAMP <= STR_TO_DATE('2018-09-03 00:00:00', '%Y-%m-%d %H:%i:%s') heißen.
(wie es vorher auch war. damals noch in dieser Schreibweise)
AND TIMESTAMP < STR_TO_DATE('2018-09-03 00:00:01', '%Y-%m-%d %H:%i:%s') ,
was jedoch nicht ganz korrekt ist, wenn man Millisekunden aktiviert hat!
sG
Joe
Jetzt ist die letzte Sekunde mit drin.
Der Select dürftr jetzt zufriedenstellend sein:
2018.09.04 17:36:11.040 1: Processing Statement: SELECT
TIMESTAMP,
DEVICE,
READING,
VALUE
FROM history WHERE 1=1 AND DEVICE = 'SMA_Energymeter' AND READING = 'Bezug_Wirkleistung'
AND TIMESTAMP >= '2018-09-03 00:00:00' AND TIMESTAMP <= '2018-09-04 00:00:00' ORDER BY TIMESTAMP
Die Version könnt ihr aus contrib herunterladen:
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter
Bitte wieder testen und Feedback geben.
LG,
Heiko
Hat denn mal jemand außer mir diese Änderung bzgl. Datenselektion für SVG ebenfalls getestet ??
Ich habs installiert und kurz angetestet. Bisher nichts negatives aufgefallen, jedoch ist der Test krankheitsbedingt bisher nur oberflächlich ausgefallen...
Sorry.
SG Joe
Hi Joe,
na dann gute Besserung !!
Vielleicht findet sich ja noch ein weiterer Mitstreiter ...
LG,
Heiko
Hallo Heiko,
läuft seit gestern auf meinem Testfhem problemlos.
Grüße
Pyro
Danke Pyro und noch einen schönen Abend.
LG,
Heiko
Habe die Version 3.12.0 eingecheckt und aus contrib wieder entfernt.
Ist morgen früh im regulären Update.
Danke nochmal fürs mittesten Pyro !
LG,
Heiko
Danke fürs einchecken! Blieb bei mir bisher unauffällig, was j aein gutes Zeichen ist ;-)
sG Joe
Guten Morgen zusammen,
für das Winterhalbjahr habe ich geplant eine neue DbLog-Version speziell für MariaDB aufzubauen.
Arbeitsname wäre z.B. MDbLog für (Maria DbLog).
Das bisherige DbLog bleibt so erhalten wie es jetzt ist. Bis auf Bugfixes würde ich aber nichts mehr implementieren.
Das neue MDbLog würde dann ausschließlich MariaDB unterstützen und dafür wäre es aber möglich die speziellen Features von MariaDB einzusetzen.
Für MDbLog hätte ich bis jetzt folgende Merkmale im Sinn:
* Count, reducelog und Co. fällt weg. Reducelog überführe ich in DbRep damit die Funktion weiterhin zur Verfügung steht.
* Anlegen der DB, Tabellen, Indizes erfolgt automatisiert
* Das Db-Konfigfile wird automatisch erstellt und ggf. geändert. Der User muss selbst keine Datei vorher erstellen
* Unterstützung von Partitionen
* Strukturänderungen (Feldbreiten) sollen einfach über set für den User änderbar sein
* Unterstützung eigener Felder, die z.B. für Löschmerkmale etc. verwendet werden könnten
* ....
Was haltet ihr davon ? (Ich will mir keine Arbeit machen die anschließend niemand braucht ;) )
Ihr seid gern eingeladen Ideen einzubringen und an der Umsetzung mitzuwirken.
LG,
Heiko
Hallo Heiko,
das klingt sehr spannend! Finde es auch gut, das Modul "sauber" zu halten.
Eventuell könnten wir in diesem Zusammenhang auch mit DbLogExclude und DbLogINclude aufräumen?
Das wäre denke ich auch mein einziger Vorschlag einer größeren Änderung...
Die Verwendung davon vorallem auch mit der Treshold-Angabe ist etwas verwirrend und wird daher meiner Meinung nach nicht wirklich genutzt.Ich denke, man benötigt das alles etwas anders.
zB. sollte man nicht auf "event-on-change" Einträge angewiesen sein, wenn man gewisse Werte nicht doppelt in der DB haben möchte. Ich habe da mehrtere Fälle als Beispiel, wo ich das so gar nicht nutzen kann.
(zB benötigt mein Heizaktor vom Termostat mind. alle 20 Minuten einen Temperaturwert, sonst geht eh auf Störung. Somit kann ich "event-on-change" nicht wirklich nutzen, da ich ja die events benötige. In der Datenbank selbst benötige ich jedoch keine doppelten Temperaturwerte. Daher denke ich, sollte das getrennt werden.
Den Code dafür hätte ich sogar schon mal geschrieben, und wäre auch bereit, den für das neue Modul nochmal umzuschreiben, soweit es meine Fähigkeiten entspricht.
Mein Vorschlag wäre also ein Attribut in etwa in der Form:
attr MDbLogconfig
[+-][reading]:[all (default)|onchange]:[range]
Beschreibung:
Add or Exclude from Log # readingname # mode # range: optional, benötigeich nicht unbedingt: angabe eines ranges, außerhalb dessen ein Wert nochmals geloggt wird.
zB. um Temperatursprünge von 0.1° auszuschließen
also zB
attr MDbLogconfig
+temperatur:onchange
+state
+humidity:all:5
-last-sender
Ich denke, so wäre eine Steuerung des Loggings sehr einfach und klar verständlich möglich und er wäre deutlich logischer aufgebaut als die DBLog-Bariante.
Eine Überführung des Attributes wäre theoretisch sogar automatisch möglich von DbLogExclude/include nach MDbLogconfig.
sG Joe
Bin gerne dabei und wünsche mir eine anfängerfreundliche Anleitung zur Inbetriebnahme.
Danke und LG
Hallo zusammen,
danke für eure Wortmeldungen.
Ich denke zu gegebener Zeit mache ich einen separaten Thread dafür auf.
@Joe, wäre es so zu verstehen, dass "+" das bisherige DbLogInclude und "-" das bisherige "DbLogExclude" ersetzen soll ?
Irgenwie müsste es auch noch eine Verknüpfung mit dem Device-Namen geben, der in deiner bisherigen Darstellung fehlt. Hattest du dir darüber auch schon Gedanken gemacht ? Da es dann kein gesetztes Attribut mehr in den Quelldevices gibt, müsste alles in dem DbLog-Device gehalten werden ... Übersichtlichkeit ??
LG,
Heiko
Hallo Heiko,
es war auch nur eine Idee. Aber gerade die Übersichtlichkeit denke ich sollte damit deutlich steigen! UNd wir hätten auch Platz für weitere Parameter.
Den Devicenamen habe ich nur vergessen!
Ich würde pro Device es so handhaben:
attr <Device> MDbLogconfig
+temperatur:onchange:partition9
+state:partition8
+humidity:all:5
-last-sender
und im Logdevice selbst ein
attr <Device> MDbLogconfigGlobal
nutzen, was weitestgehend dem jetzigen
excludeDevs
entspricht und ja genau dafür genutzt werden kann, Global gewisse Devices, Typen oder Readings zu sperren, auszuschließen, verhindern....
Im Beispiel oben für die Devices könne man so locker gewisse Attribute ergänzen, wie zB eben auch in welcher Partition es gespeichert werden soll. (Eben direkt in die "Kurzzeitpartition", weil man schon weiß, dass man diesen Wert nur zur Berechnung des Stundenmittels benötigt und ihn danach wegwerfen kann).
Im Extremfall könnte man dort sogar eine Wertänderung erlauben, ähnlich wie valueFn nur eben Devicespezifisch:
+temperatur:onchange:partition9:$value=($value=~'^true'?1:0)
Aber das alles wäre sicherlich nur zukunftsmusik und nicht direkt notwendig. Ich möchte damit nur aufzeigen, wie flexibel dies wäre.
Im Zusammenhang mit dem neuen direkten Einblenden der Hilfe in FHEM (siehe Screenshot), ist sicherlich auch die Notation keine große Hürde mehr!
Auch der Name ist natürlich nur eine schnelle Idee.... vielleicht gibts da was prägnanteres?!?
sG
Joe
Ah, ok. Jetzt ist es mir klarer geworden. Finde ich gut !
Würde ich mit vorsehen und wir schauen dann wie es sich in der Praxis gestaltet.
Die neuen Attributhilfen habe ich auch schon gesehen, aber weiß noch nicht wie man die im eigenen Modul einblendet.
"Einfach so" passiert es jedenfalls nicht.
Zitat von: DS_Starter am 02 Oktober 2018, 14:09:23
Die neuen Attributhilfen habe ich auch schon gesehen, aber weiß noch nicht wie man die im eigenen Modul einblendet.
So hat es DOIF gemacht... vielleicht hilfts?
https://svn.fhem.de/trac/changeset?old=17290&old_path=trunk%2Ffhem%2FFHEM%2F98_DOIF.pm&new=17291&new_path=trunk%2Ffhem%2FFHEM%2F98_DOIF.pm
sG
joe
Ja, das kenne ich. Hat bei meinen Experimenten aber bis jetzt nicht funktioniert.
So habe ich es mal probiert in der Commandref:
<a name="addStateEvent"></a>
Irgendwas stimmt da noch nicht.
Ha, jetzt habe ich es mal komplett für ein ganzes Modul durchgezogen (Log2Syslog) und nun funktioniert es. ;)
Zitat von: DS_Starter am 02 Oktober 2018, 14:09:23
Ah, ok. Jetzt ist es mir klarer geworden. Finde ich gut !
Würde ich mit vorsehen und wir schauen dann wie es sich in der Praxis gestaltet.
Die neuen Attributhilfen habe ich auch schon gesehen, aber weiß noch nicht wie man die im eigenen Modul einblendet.
"Einfach so" passiert es jedenfalls nicht.
Habe ein bisschen überlegt, und denke, man könnte eventuell auch über dieses Konstrukt einfach mehrere unterschiedliche Tabellen anstatt Partitionen nutzen Punkt eine Tabelle Kurzzeitspeicher wäre genauso schnell gelöscht. Die Berechnungen davon die History zu übertragen wäre ebenfalls schnell Punkt lediglich Abfragen für Plots müsste man wohl über alle Tabellen einzeln laufen lassen oder Union nutzen...
Nur mal so als Überlegung ;-)
SG Joe
Hi Joe,
die Aufteilung in mehrere Tabellen hatte ich auch schon mal kurz auf dem Schirm.
Aber ich habe das ganz schnell wieder verworfen als ich an die Arbeit gedacht habe, die mir das im DbRep bescheren würde wenn ich sowohl die Tabellenstruktur des bisherigen DbLog UND die Struktur über mehrere Tabellen in einem neuen Modul unterstützen müsste, und das noch für verschiedene Datenbanksysteme.
Das wäre mir momentan echt zuviel ;)
LG,
Heiko
Hallo zusammen,
ich würde in meiner bestehenden Datenbank (Synology mit mariadb10) gerne einen Primary Key hinzufügen.
Leider werden dabei die ein oder anderen doppelten Einträge gefunden, was das Vorhaben verhindert.
Im anderen Thread ist es schon kurz angesprochen. https://forum.fhem.de/index.php/topic,68646.30.html
Mit dem Hinweis von DS_Starter hab ichs auch probiert, ohne Erfolg:
ALTER IGNORE TABLE `history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);
delSeqDoublets hab ich in einem kurzen Zeitraum ausprobiert, mit dem Ergebnis das nahezu alle Daten aus dem Zeitraum gelöscht wurden, vermutlich weil delSeqDoublets nur auf Device,Reading and Value prüft, nicht aber auf den Timestamp. Und gerade bei Value-States eines Thermostats gibt es ja über längere Zeiträume auch gleiche Zustände. Solange pro Zeitstempler ein Wert ist, ist das ja auch OK.
Meine gelöschten Daten muss ich jetzt aus einem Backup wiederherstellen. Aber anderes Thema.
Wäre es ein Lösungsweg, die Datenbank zu sichern, dann komplett zu löschen, mit Primary Key neu anzulegen und dann die alten Daten wieder rückwärts zu importieren?
Wie könnte ich in der Zwischenzeit dafür sorgen, dass die anfallenden Daten irgendwo zwischengespeichert werden um währen des Prozederes keine Daten zu verlieren?
Besten Dank,
Bond
Hallo Bond,
Zitat
delSeqDoublets hab ich in einem kurzen Zeitraum ausprobiert, mit dem Ergebnis das nahezu alle Daten aus dem Zeitraum gelöscht wurden, vermutlich weil delSeqDoublets nur auf Device,Reading and Value prüft, nicht aber auf den Timestamp. Und gerade bei Value-States eines Thermostats gibt es ja über längere Zeiträume auch gleiche Zustände. Solange pro Zeitstempler ein Wert ist, ist das ja auch OK.
Die Funktion delSeqDoublets macht etwas mehr als "nur" doppelte Datensätze löschen. Wie genau es wirkt, ist in der commandref detailliert beschrieben. Es gibt auch einen Testlauf vorher mit "delSeqDoublets adviceDelete". Ich hätte dich vermutlich explizit nochmal darauf hinweisen sollen vorher die commandref zu lesen und das dort beschriebene Beipiel anzuschauen. Sorry ... mein Fehler.
Werde wohl noch eine Funktion ins DbRep einbauen, die ausschließlich doppelte (mehrfache) Datensätze bereinigt.
Zu deinem eigentlichen Thema.
Ich würde mit einer Standby-Datenbank arbeiten.
1. Neue DB (z.B. fhempk) anlegen und dort den PK wie beschrieben mit anlegen für die history.
2. ein DbLog-Device Log.fhempk für diese DB anlegen was einsatzbereit ist, aber so einstellen das nichts geloggt wird (Regex im DEF z.B. aaaaaa:bbbbbbb).
3. ein Dbrep-Device anlegen was mit produktiven Datenbank verbunden ist.
4. mit dem Befehl "syncStandby Log.fhempk" alle Datensätze in die Standby-DB übertragen. Doppelte Datensätze werden durch den PK
automatisch ignoriert. Der produktive Betrieb wird nicht behindert und kann weiter laufen.
Je nach Größe der DB kann das einige Zeit in Anspruch nehmen. Vorher Commandref lesen !
5. vermutlich wird es dann noch einen Datengap geben, der zwischen Start und Ende des syncStandby-Befehls liegt. Dann einfach diesen Zeitraum nochmal mit syncStandby und gesetzten Zeitattributen nachfahren
6. Sind alle Daten übertragen, das Device Log.fhempk disabled setzen und das bisherige produktive DbLog mit der neuen DB fhempk verbinden (db.cfg editieren).
Dann hättest du deine Daten relativ stressfrei umgezogen und fortan einen PK der doppelte Einträge in der DB verhindert.
Edit: Das Verfahren hat auch den Vorteil, dass man üben kann. Die Standby-DB aufbauen, schauen wie alles gelaufen ist, die Tabellen droppen und nochmal beginnen. Das kann man so oft wiederholen wie man es wünscht. Die produktive DB läuft in der Zeit munter weiter.
Grüße,
Heiko
So wie hier beschrieben würde es natürlich auch gehen, mit eventuell etwas weniger aufwand....
https://forum.fhem.de/index.php/topic,65860.msg571050/topicseen.html#msg571050
In Punkt 1 kannst Du dann die Tabelle vorab ja noch anpassen und den PK setzen.
sG Joe
Zitat von: JoeALLb am 12 Oktober 2018, 11:36:10
So wie hier beschrieben würde es natürlich auch gehen, mit eventuell etwas weniger aufwand....
https://forum.fhem.de/index.php/topic,65860.msg571050/topicseen.html#msg571050
In Punkt 1 kannst Du dann die Tabelle vorab ja noch anpassen und den PK setzen.
sG Joe
Danke, so hab ich es jetzt gemacht.
Zuerst eine neue historyNEW angelegt, dann die aktuelle in historyOLD umgebannt und dann hab ich alle Daten von OLD zur neuen umgezogen mit dem aktiven privateKey.
Besten Dank.
Hallo zusammen,
zur Beseitigung von doppelten Datensätzen gibt es nun eine einfache Möglichkeit mit DbRep.
Im contrib Verzeichnis
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter
gibt es eine neue DbRep-Version die den Befehl
set <name> delDoublets [adviceDelete | delete]
enthält. Mit der "delete" Option werden die doppelt oder mehrfach vorhandenen Datensätze gelöscht.
Wenn man noch keinen PK gesetzt hat und sich doppelte Records in der DB befinden, kann man folgendermaßen vorgehen um einen PK setzen zu können.
Erstmal die DB für das Logging (genügend lange) schließen:
set <DbLog> reopen 86000
Wie bekannt, gehen die Daten während dieser Zeit nicht verloren und werden nachgebucht, wenn DbLog im asynchronen Modus betrieben wird.
Dann die doppelten Datensätze entfernen:
set <DbRep> delDoublets
Das dauert nun je nach Größe und Performance eine gewissse Zeit.
Dann den PK setzen, für MySQL/MariaDB:
set <DbRep> sqlCmd ALTER TABLE 'history' ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);
DbLog wieder zum Logging öffnen:
set <DbLog> reopen
Jetzt wird die DB von doppelten Datensätzen verschont.
Die delDoublets-Funktion kann man natürlich auch zum regelmäßigen Pflegen des Datenbestandes nutzen.
Wenn ich genügend getestet habe, checke ich die Version auch ein.
Siehe auch hier: https://forum.fhem.de/index.php/topic,53584.msg856008.html#msg856008
Grüße
Heiko
Guten Morgen,
Im contrib-Verzeichnis:
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter
liegt eine DbLog-Version die DbLogInclude mit berücksichtigt. Die Anforderung geht zurück auf diesen Thread:
https://forum.fhem.de/index.php/topic,92854.msg854173.html#new
set <name> addLog <devspec>:<Reading> [Value] [CN=<caller name>] [!useExcludes]
Fügt einen zusätzlichen Logeintrag einer Device/Reading-Kombination in die Datenbank ein. Die eventuell in den Attributen "DbLogExclude" spezifizierten Readings (im Quelldevice) werden nicht nicht geloggt, es sei denn sie sind im Attribut "DbLogInclude" enthalten bzw. der addLog-Aufruf erfolgte mit der Option "!useExcludes".
....
Bitte testet die Erweiterung auch mal bei euch.
Grüße
Heiko
Hallo DbLog Team :),
nach längerer Zeit beginne ich nun wieder DbLog auf aktuelle Entwicklungen in FHEM anzupassen und verschiedene Dinge einzupflegen. Auf meiner ToDo haben sich ein paar Sachen angesammelt.
In der Version 3.14.0 habe ich erst einmal folgendes umgesetzt:
* Support für Meta.pm und Installer ist eingebaut (Meta.pm muss aber nicht zwingend vorhanden sein -> Rücksicht auf
nicht Top aktuelle Installationen)
* die neue DelayedShutdownFn-Funktion ist eingebaut. Dadurch ist ein besseres Shutdown-Management möglich geworden.
Der configCheck ist entsprechend angepasst.
* das Attribut "shutdownWait" wurde durch den voherigen Punkt obsolet.
Achtung: ist das Attribut gesetzt, wird es beim nächsten Restart entfernt und im Log gibt eine entsprechende
Meldung. Das ist gewollt und nach speichern der Konfig ok.
* die direkte Attribut-Hilfe innerhalb des FHEMWEB ist eingebaut
Zunächst bitte aus meinem contrib laden:
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter (Downloadbutton benutzen)
Danach ist ein Restart notwendig !
Ich hoffe es finden sich ein paar Tester :D
viele Grüße,
Heiko
Mahlzeit Heiko,
nachdem ich gerade ein wenig Zeit habe vermelde ich: Testsystem auf den aktuellen Stand gebracht und DbLog vom Contri Link eingespielt. Ich werde Mo/Di kurze Rückmeldung geben.
Grüße
Pyro
Danke Pyro :)
Gibt es evtl. schon erste Testergebnisse ?
Keine Fehlermitteilungen sind ja auch ein gutes Zeichen ;)
VG
Mahlzeit Heiko,
da war ja was... Schande über mein Haupt :(
Aber wie du bereits richtig erkannt hast, gab es keine Auffälligkeiten.
Grüße
Pyro
Hi Pyro,
na schäm dich :D
Dann sieht das doch gut aus. Werde diese Version dann einchecken.
Ich habe noch ein bisschen was auf meiner ToDo ...
LG,
Heiko
Hallo Pyro, @all,
nachdem die aktuellste Version eingecheckt ist, habe ich mich dem gemeldeten Problem: https://forum.fhem.de/index.php/topic,99280.0.html mit MySQL und der SVG-Darstellung von Differenzwerten beschäftigt. Das Problem tritt nur in dem speziellen Fall auf, wenn VALUE kein Zahlenwert ist, sondern durch ein im SVG mitgegebenen Regex aus VALUE extrahiert wird. Und nur bei MySQL.
Ich konnte das Problem hoffentlich ohne Nebeneffekte lösen.
Kurioserweise existiert diese für MySQL spezielle Selektion bereits seit der ganz alten Version vom Juli 2016 (sicherlich noch früher) und erst jetzt wurde solch ein (mir bekannter) Fall geschildert. :o
Also meine Bitte wieder diese Version zu testen. Diesmal sind vor allem MySQL User gefragt.
Bitte aus meinem contrib laden:
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter (Downloadbutton benutzen)
Reload danach wäre ausreichend.
Danke und Grüße,
Heiko
Ist das attr shutdownWait nicht mehr aktiv?
Fhem meldete dies beim Neustart.
Hatte ich vergessen zu erwähnen ;-)
Gruß Bernd
Zitat von: DS_Starter am 12 April 2019, 22:49:53
Bitte aus meinem contrib laden:
Könntest ja auch die DEV Version in META.json verlinken ;)
@Bernd,
ZitatIst das attr shutdownWait nicht mehr aktiv?
Ja, das ist obsolet. Siehe den Beitrag #772
@Loredo,
ZitatKönntest ja auch die DEV Version in META.json verlinken
ah cool, das probiere ich mal aus wie das geht.
Hallo zusammen,
die Version 3.14 läuft problemlos, bin nur über das fehlende shutdown Attribut gestolpert.
FHEMInstaller weist bei mir auf eine fehlende Perl Bibliothek hin:
Recommended
Item Type Used by
DBD::Pg Perl DbLog
These dependencies are strongly encouraged and should be installed for full functionality of the listed FHEM modules, except in resource constrained environments.
Diese lässt sich aber nicht installieren, da ich kein postgress sondern mysql verwende. Sicherlich nur ein Schönheitsfehler...
Beste Grüße
Torsten
Moin Torsten,
Zitatdie Version 3.14 läuft problemlos, bin nur über das fehlende shutdown Attribut gestolpert. Attribut gestolpert.
Ich vermute du meinst die 3.14.1 (?).
Ja, das Attribut shutdownWait ist obsolet geworden ... siehe oben.
ZitatFHEMInstaller weist bei mir auf eine fehlende Perl Bibliothek hin ...
Ja, das ist noch ein Unschönheit weil ich momentan in der Meta.json alle Bibliothejen angegeben habe die man für DbLog brauchen könnte, wobei ich eigentlich nur die angeben müsste die der User entsprechend seines Setup benötigt. Das weiß ich aber vorher nicht.
Vielleicht hat Loredo eine passende Idee dazu ...
Danke für deinen Test und Meldung !
Heiko
Zitat von: DS_Starter am 14 April 2019, 12:12:17
Vielleicht hat Loredo eine passende Idee dazu ...
Darauf bin ich ja hier (https://forum.fhem.de/index.php/topic,97589.msg926826.html#msg926826) schonmal eingegangen. ;)
Grundsätzlich gibt es keine "wenn dann, oder sonst" Abhängigkeiten. Es gibt nur "zwingend notwendig", "empfohlen" und "optional". Derzeit sind wohl alle Datenbank Typen als "zwingend notwendig" hinterlegt.
Der Installer würde auch alle installieren und gut ist. Das gleiche würde ich also auch dir, Torsten, empfehlen. Man muss ja nun wirklich nicht päpstlicher sein als der Papst, man redet ja hier nicht von Gigabytes mehr Daten. Ansonsten kann Heiko natürlich auch die Datenbank Typen alle oder teilweise als "empfohlen" hinterlegen. Das impliziert, dass man sie installieren _sollte_, aber nicht muss. Dass man irgendeinen davon mindestens braucht, sagt einem das Modul ja ohnehin dann schon, wenn man es benutzen will. Eine Hellsehen-Fähigkeit, wie jemand FHEM zu benutzen plant, gibts im Installer wohl nie... ;D
ZitatAnsonsten kann Heiko natürlich auch die Datenbank Typen alle oder teilweise als "empfohlen" hinterlegen.
Das wird wohl tendenziell das Beste sein.
Im nächsten Release ändere ich die Abhängigkeiten entsprechend ab.
Hallo zusammen,
die getestete Version 3.14.1 habe ich soeben eingecheckt und ist morgen früh im Regelupdate enthalten.
In der Zwischenzeit habe ich ein weiteres ToDo umgesetzt.
Ein User hatte angeregt die Schreibgeschwindigkeit bei Masseninserts zu beschleunigen.
Dazu habe ich die Schreibroutinen überarbeitet und einen bulkInsert-Mode implementiert. Die stark gesteigerte Schreibperformance ist besonders spürbar, wenn man die Datenbank im asynchronen Modus längere Zeit mit "reopen" geschlossen hält, d.h. wenn sich eine größere Menge Events angesammelt hat, die nach DB-Öffnung weggeschrieben werden sollen.
Um diesen Mode einzuschalten gibt es ein Attribut:
* bulkInsert
attr <device> bulkInsert [1|0]
Schaltet den Insert-Modus zwischen "Array" (default) und "Bulk" um. Der Bulk Modus führt beim Insert von sehr vielen Datensätzen in die history-Tabelle zu einer erheblichen Performancesteigerung vor allem im asynchronen Mode. Um die volle Performancesteigerung zu erhalten, sollte in diesem Fall das Attribut "DbLogType" nicht die current-Tabelle enthalten.
Weiterhin habe ich noch einen Bugfix integriert der ein aufgetretenes Problem mit plotfork und MySQL behoben hat.
Siehe -> https://forum.fhem.de/index.php/topic,99719.0.html
Da sich doch recht viel geändert hat, werde ich diese Version zunächst längere Zeit zum Test aus meinem contrib zur Verfügung stellen:
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter (Downloadbutton benutzen)
Grüße,
Heiko
Nabend Heiko,
mein Testsystem mit der Testversion versehen.
DbLogType von SampleFill/History auf History umgestellt
bulkInsert 1 gesetzt
Grüße
Pyro
Nabend Pyro,
ZitatDbLogType von SampleFill/History auf History umgestellt
Das hättest du so lassen können, nur die Current sollte nicht beschrieben werden, also nicht "Current/History".
Ansonsten ok ... schauen wir mal. :)
Gute Nacht ...
Heiko
Hallo Heiko,
das Testsystem hat sich absolut unauffällig verhalten.
Performacegewinn konnte ich keinen feststellen, das dürfte aber an meinem Testsystem liegen (zu wenig Datensätze die geschrieben werden nach einem Reopen).
Grüße
Pyro
Moin Pyro,
danke für deine Rückmeldung.
Ja, die Performancesteigerung macht sich dann bemerkbar wenn sehr viele Daten auf einmal eingefügt werden sollen.
Also wenn sehr viele Events im Speicher gehalten wurden, z.B. weil die Verbindung zur DB geschlossen war, oder ähnliche Fälle.
LG,
Heiko
Habe die getestete Version 4.1.0 soeben eingecheckt und ist morgen früh im Regelupdate entahlten.
Grüße,
Heiko
Grüß Euch,
kann berichten, dass am RaspberryPI 3 das speichern von 300 Logs
mit langsamer SD-Karte und MariaDB (Debian) von durchschnittlich 1,2s auf die Hälfte gesenkt hat,
durch die Nutzung von blkinsert!
Sehr schönes Ergebnis, herzlichen Dank für das tolle Feature!!
Vor diesem Hintergrund halte ich das Feature durch aus auch für weniger als "sehr viele Daten" für Sinnvoll :D
Joe
Danke für die RückInfo Joe !
Die Ergebnisse sind offensichtlich recht unterschiedlich abhängig von der DB und der jeweiligen Umgebung.
Hauptsache es hilft und man kann Vorteile für sein FHEM generieren :D
Grüße,
Heiko
Hallo Heiko,
Anbei ein Screenshot zur Veranschaulichung.
Blau die Speicherzeiten, pink Anzahl der Datensätze.
Dazwischen die Zeit des Updates... (in der die Datensätze von 300 auf 15000 anstieg ;-)
man sieht schön, dass die blaue Linie deutlich weiter unten bleibt!!!
sG Joe
... Weil es mich so freut, hier nochmal ein Screenshot über die ganze Woche.
Man sieht schön, wo ich BulkInsert aktiviert habe! Die normale Speicherzeit von 1.3-6s liegt jetzt zwischen 0.6 und max. 1.8s ...
und belastet sicherlich auch die SD-Karte weniger!
sg Joe
Hallo miteinander,
seit längerer Zeit habe ich mich wieder mit DbLog beschäftigt.
Angeregt von unserem Stammtisch (https://forum.fhem.de/index.php/topic,52727.msg953319.html#msg953319) habe ich
ein Attribut "DbLogValueFn" eingeführt, welches in den Devices (so wie DbLogExclude) propagiert wird sofern DbLog genutzt wird.
Dadurch ist es möglich, gewünschte Manipulationen der zu loggenden Daten im Device vorzunehmen und nicht alles in der zentralen "valueFn" hinterlegen zu müssen. Dadurch wird "valueFn" nicht zu umfangreich falls man diese Möglichkeit umfangreich einsetzt.
Auszug:
* DbLogValueFn
attr <device> DbLogValueFn {}
Wird DbLog genutzt, wird in allen Devices das Attribut DbLogValueFn propagiert. Es kann über einen Perl-Ausdruck auf die
Variablen $TIMESTAMP, $READING, $VALUE (Wert des Readings) und $UNIT (Einheit des Readingswert) zugegriffen
werden und diese verändern, d.h. die veränderten Werte werden geloggt. Außerdem hat man lesenden Zugriff auf $EVENT
für eine Auswertung im Perl-Ausdruck. $EVENT kann nicht verändert werden.
Soll $TIMESTAMP verändert werden, muss die Form "yyyy-mm-dd hh:mm:ss" eingehalten werden, ansonsten wird der
geänderte $timestamp nicht übernommen. Zusätzlich kann durch Setzen der Variable "$IGNORE=1" der Datensatz vom
Logging ausgeschlossen werden.
Die devicespezifische Funktion in "DbLogValueFn" wird vor der eventuell im DbLog-Device vorhandenen Funktion im
Attribut "valueFn" auf den Datensatz angewendet.
Beispiel
attr SMA_Energymeter DbLogValueFn
{
if ($READING eq "Bezug_WirkP_Kosten_Diff"){
$UNIT="Diff-W";
}
if ($READING =~ /Einspeisung_Wirkleistung_Zaehler/){
$IGNORE=1;
}
Die Änderung ist zunächst per Download aus meinem contrib (Footer) verfügbar. Bitte benutzt den Downloadbutton in der Zeile des Moduls.
Grüße,
Heiko
Hallo zusammen,
in meinem contrib (siehe Footer) habe ich einen neue Version 4.3.0 bereitgestellt.
Diese Version erlaubt es das Datenbankschema mit dem Attribut "dbSchema" zu setzen (nicht bei SQLITE).
Hintergrund ist die Anfrage von volschin hier -> https://forum.fhem.de/index.php/topic,102679.0.html
Auch wenn die Änderung klein ist, habe ich jedes Statement anfassen müssen und bitte euch die Version herunterzuladen und zu testen !!
Es ist ein Restart erforderlich !
Grüße,
Heiko
Hallo Heiko,
Funktioniert bisher ohne Auffälligkeiten sowohl für die Logs, als auch die Plot-Darstellung.
Danke für die Rückmeldung volschin, Freut mich :)
Heiko
Moin,
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/dblog/db_create_postgresql.sql Zeile 72 fehlt ein ";" am Ende der Zeile.
Das gesamte Script funktioniert bei mir nicht wirklich - am Ende half es bei mir nur, die Kommandos mit Copy & Paste ins Terminal einzugeben.
Danke, -MN
Da hatte jetzt auch keiner was gefixt.
Gesendet von iPhone mit Tapatalk
Zitat
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/dblog/db_create_postgresql.sql Zeile 72 fehlt ein ";" am Ende der Zeile.
Danke für den Hinweis, ist ergänzt und eingecheckt.
Hallo miteinander,
in meinen contrib (siehe footer) befindet sich die Version 4.6.0.
In diesem Thread -> https://forum.fhem.de/index.php/topic,97148.0.html wurde angeregt bei der Verwendung von MinInterval die Events auch dann nicht zu loggen wenn sie sich gegenüber dem Vorwert unterscheiden.
Um das zu realisieren wurde ein optionaler Parameter "force" bei der Verwendung von MinInterval eingeführt.
Auszug aus ComRef:
Ist MinIntervall angegeben, wird der Logeintrag nicht geloggt, wenn das Intervall noch nicht erreicht und der Wert des Readings sich nicht verändert hat. Ist der optionale Parameter "force" hinzugefügt, wird der Logeintrag auch dann nicht geloggt, wenn sich der Wert des Readings verändert hat,z.B.
attr MyDevice2 DbLogExclude state,(floorplantext|MyUserReading):300:force,battery:3600:force
Würde mich über Meinungen und den einen oder anderen Tester freuen.
Grüße,
Heiko
Hallo zusammen,
ich hätte eine Feature-Wunsch:
Die Funktionalität von "MinIntervall" noch zusätzlich als allgemeines Attribut im DbLog Device hinzufügen. Dies gilt dann generell für alle Readings/Log-Einträge. So kann ich mir ersparen dies in allen meinen Geräten anzupassen. Eventuell auch als Regex um auf bestimmte Geräte/Readings einzugrenzen. Ich möchte generell keine Doppelten Einträge/gleiche Werte innerhalb eines Intervall erhalten.
Wäre schön wenn es umgesetzt wird :)
ZitatDie Funktionalität von "MinIntervall" noch zusätzlich als allgemeines Attribut im DbLog Device hinzufügen. Dies gilt dann generell für alle Readings/Log-Einträge.
Ich habe die Idee auf meine ToDo-Liste gesetzt um es zu prüfen.
Möchte aber zunächst einmal den aktuellen Entwicklungsstand einchecken und schauen ob es eventuell noch irgendwo Nachbesserungsbedarf geben sollte.
Grüße,
Heiko
Hallo Heiko,
zum dem hier https://forum.fhem.de/index.php/topic,99280.msg979679.html#msg979679 (https://forum.fhem.de/index.php/topic,99280.msg979679.html#msg979679) gelösten Problem ist mir noch eine Kleinigkeit aufgefallen.
Die Beschreibung incl. Anhänge habe ich im dem alten Thread eingefügt, da es ja daraus resultiert.
Gruß
Bernd
Hallo miteinander,
ich habe eine neue DbLog-Version in meinem contrib zur Verfügung gestellt.
Es ist das SQL zur Ermittlung von Differenzen delta-h, delta-d neu aufgebaut. Die Grundlage für diesen Change ist die Diskussion in diesem Thread mit Bernd: https://forum.fhem.de/index.php/topic,99280.msg980406.html#msg980406
Die neue Version ist in meinem contrib. Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben:
"wget -qO ./FHEM/93_DbLog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbLog.pm"
Ich habe grundlegende Tests durchgeführt, aber kann natürlich nicht jede Variation abbilden.
Deswegen wäre es mir wichtig, dass ihr mich mit Tests der Version auf euren Systemen unterstützt. Es betrifft SVG-Generierungen die delta-h bzw. delta-d Berechnungen mit logproxy durchführen in der Art:
#myProxy1 DbLog:LogSQLITE:KS300:data::delta-h:$val=~s/.*\sR..([\d.]+)\s.*/$1/eg
#myProxy1 DbLog:LogPostgre:KS300:data::delta-h:$val=~s/.*\sR..([\d.]+)\s.*/$1/eg
Grüße,
Heiko
Hallo Heiko,
da passt was nicht :o
Zitat2019-10-09_00:30:00 -9.22337e+18
2019-10-09_01:30:00 0
2019-10-09_02:30:00 0
2019-10-09_03:30:00 0
2019-10-09_04:30:00 0
2019-10-09_05:30:00 0
2019-10-09_06:30:00 0
2019-10-09_07:30:00 0
2019-10-09_08:30:00 0
2019-10-09_09:30:00 0
2019-10-09_10:30:00 0
2019-10-09_11:30:00 0
2019-10-09_12:30:00 0
2019-10-09_13:30:00 0
2019-10-09_14:30:00 0
2019-10-09_15:30:00 0.3
2019-10-09_16:30:00 0.3
2019-10-09_17:30:00 0
2019-10-09_18:30:00 0
2019-10-09_19:30:00 0
2019-10-09_20:30:00 3.8
#KS300:data::delta-h:$val=~s/.*\sR..([\d.]*).*/$1/eg
2019-10-09_12:00:00 -9.22337e+18
#KS300:data::delta-d:$val=~s/.*\sR..([\d.]*).*/$1/eg
Gruß Bernd
???
Hast du die gleichen Daten ausgewertet wie bei unserem Test ?
Bitte mal verbose 5 setzen, das SVG aufrufen und die Ausgabe posten. Möglicher Grund ... gibt es vielleicht keinerlei Daten in der Vorperiode ?
Grüße.
Heiko
Nein, die Daten sind von heute. War auf die schnelle mit dem Tablet.
Hier vom 25.09.
Zitat2019-09-25_00:30:00 -9.22337e+18
2019-09-25_01:30:00 0
2019-09-25_02:30:00 0
2019-09-25_03:30:00 0
2019-09-25_04:30:00 0.3
2019-09-25_05:30:00 0
2019-09-25_06:30:00 0
2019-09-25_07:30:00 0
2019-09-25_08:30:00 0
2019-09-25_09:30:00 0
2019-09-25_10:30:00 0
2019-09-25_11:30:00 0.2
2019-09-25_12:30:00 0
2019-09-25_13:30:00 0
2019-09-25_14:30:00 0
2019-09-25_15:30:00 1.3
2019-09-25_16:30:00 0
2019-09-25_17:30:00 0
2019-09-25_18:30:00 0
2019-09-25_19:30:00 2.1
2019-09-25_20:30:00 0.5
2019-09-25_21:30:00 0
2019-09-25_22:30:00 0
2019-09-25_23:30:00 0
#KS300:data::delta-h:$val=~s/.*\sR..([\d.]*).*/$1/eg
2019-09-25_12:00:00 -9.22337e+18
Verbose 5 habe ich als Datei angehängt, sind zu viele Daten.
Und ein paar Bilder.
Hier noch der 06.10. Bild im Anhang
Zitat2019-10-06_00:30:00 -1.84467e+19
2019-10-06_01:30:00 0
2019-10-06_02:30:00 0
2019-10-06_03:30:00 0
2019-10-06_04:30:00 0
2019-10-06_05:30:00 0
2019-10-06_06:30:00 0
2019-10-06_07:30:00 0
2019-10-06_08:30:00 9.22337e+18
2019-10-06_09:30:00 0.5
2019-10-06_10:30:00 2.3
2019-10-06_11:30:00 1
2019-10-06_12:30:00 1.8
2019-10-06_13:30:00 1.5
2019-10-06_14:30:00 2
2019-10-06_15:30:00 0.5
2019-10-06_16:30:00 0.3
2019-10-06_17:30:00 2
2019-10-06_18:30:00 0.8
2019-10-06_19:30:00 1.3
2019-10-06_20:30:00 3.3
2019-10-06_21:30:00 0.8
2019-10-06_22:30:00 0
2019-10-06_23:30:00 0
#KS300:data::delta-h:$val=~s/.*\sR..([\d.]*).*/$1/eg
2019-10-06_12:00:00 -9.22337e+18
Ich habe einige Tage mit und ohne Regen durchgeschaut, die -9.22337e+18 o.ä. ist jedes Mal vorhanden.
Gruß Bernd
Hier noch Verbose 5 vom 06.10.
Das ist was :
Zitat
2019.10.09 22:04:31 4: DbLog logdb -> ################################################################
2019.10.09 22:04:31 4: DbLog logdb -> ### new get data for SVG ###
2019.10.09 22:04:31 4: DbLog logdb -> ################################################################
2019.10.09 22:04:31 4: DbLog logdb -> main PID: 5757, secondary PID: 5757
2019.10.09 22:04:31 4: logdb - Processing Statement:
SELECT Z.TIMESTAMP, Z.DEVICE, Z.READING, Z.VALUE from (SELECT DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s') AS TIMESTAMP,
DEVICE AS DEVICE,
READING AS READING,
VALUE AS VALUE FROM history WHERE 1=1 AND DEVICE = 'KS300' AND READING = 'data' AND TIMESTAMP < STR_TO_DATE('2019-10-06 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP > DATE_SUB(STR_TO_DATE('2019-10-06 00:00:00', '%Y-%m-%d %H:%i:%s'),INTERVAL 1 DAY) ORDER BY TIMESTAMP DESC LIMIT 1 ) AS Z
UNION ALL SELECT
MAX(DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s')) AS TIMESTAMP,
MAX(DEVICE) AS DEVICE,
MAX(READING) AS READING,
MAX(VALUE)
FROM history WHERE 1=1 AND DEVICE = 'KS300' AND READING = 'data' AND TIMESTAMP >= STR_TO_DATE('2019-10-06 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP <= STR_TO_DATE('2019-10-07 00:00:00', '%Y-%m-%d %H:%i:%s') GROUP BY DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H') ORDER BY TIMESTAMP
2019.10.09 22:04:31 5: logdb - SQL-result -> TS: 2019-10-06 08:59:45, DEV: KS300, RD: data, VAL: T: 8.5 H: 90 W: 0.0 R: 1698.6 IR: no Wi: 0
2019.10.09 22:04:31 5: logdb - Output delta-h -> TS: 08, LASTTS: 00, OUTTS: 2019-10-06 00:30:00, OUTVAL: -1.84467e+19
2019.10.09 22:04:31 5: logdb - SQL-result -> TS: 2019-10-06 09:50:36, DEV: KS300, RD: data, VAL: T: 8.6 H: 91 W: 0.0 R: 1699.1
Ich muss mir das in Ruhe anschauen. Kannst du mir noch aktuelle Daten exportieren die ich in meine DB importieren kann ?
Bei mir kommt das übrigens nicht (preprocessed input):
get myProxy1 CURRENT INT 2019-09-24_00:00:00 2019-09-24_23:59:59 DbLog:LogDB:KS300:data::delta-h:$val=~s/.*\sR..([\d.]+)\s.*/$1/eg DbLog:LogDB:KS300:data::delta-d:$val=~s/.*\sR..([\d.]+)\s.*/$1/eg
2019-09-24_00:30:00 0
2019-09-24_01:30:00 0
2019-09-24_02:30:00 0
2019-09-24_03:30:00 0
2019-09-24_04:30:00 0
2019-09-24_05:30:00 0
2019-09-24_06:30:00 0
2019-09-24_07:30:00 0
2019-09-24_08:30:00 0
2019-09-24_09:30:00 0
2019-09-24_10:30:00 0
2019-09-24_11:30:00 0
2019-09-24_12:30:00 0
2019-09-24_13:30:00 0
2019-09-24_14:30:00 0
2019-09-24_15:30:00 0
2019-09-24_16:30:00 0
2019-09-24_17:30:00 0
2019-09-24_18:30:00 0.5
2019-09-24_19:30:00 0.8
2019-09-24_20:30:00 0.5
2019-09-24_21:30:00 0.2
2019-09-24_22:30:00 0.5
2019-09-24_23:30:00 0
#KS300:data::delta-h:$val=~s/.*\sR..([\d.]+)\s.*/$1/eg
2019-09-24_12:00:00 2.5
#KS300:data::delta-d:$val=~s/.*\sR..([\d.]+)\s.*/$1/eg
ZitatIch muss mir das in Ruhe anschauen. Kannst du mir noch aktuelle Daten exportieren die ich in meine DB importieren kann ?
Heute Abend....
Da es fast täglich regnet, werde ich dir einen längeren Zeitraum exportieren.
Gruß Bernd
P.S. werde die Daten beim ex-, importieren, eventuell verändert String/numerisch etc.?
Oder gibt es bezgl. SQL Installation/Konfiguration Unterschiede?
Ich werde mal SQLite auf den Testsystem benutzen...
So, mal wieder der selbe Mist. :(
Bei SQlite auf dem Testsystem ist alles TOP:
Zitat2019-10-10_00:30:00 0
2019-10-10_01:30:00 0
2019-10-10_02:30:00 0.7
2019-10-10_03:30:00 0.3
2019-10-10_04:30:00 0
2019-10-10_05:30:00 0
2019-10-10_06:30:00 1.3
2019-10-10_07:30:00 0.5
2019-10-10_08:30:00 0.2
2019-10-10_09:30:00 0.3
2019-10-10_10:30:00 0
2019-10-10_11:30:00 0
2019-10-10_12:30:00 0
2019-10-10_13:30:00 0
2019-10-10_14:30:00 0.2
2019-10-10_15:30:00 0
2019-10-10_16:30:00 0
2019-10-10_17:30:00 1.8
2019-10-10_18:30:00 0
#KS300:data::delta-h:$val=~s/.*\sR..([\d.]*).*/$1/eg
2019-10-10_12:00:00 5.3
#KS300:data::delta-d:$val=~s/.*\sR..([\d.]*).*/$1/eg
Die ex. Daten sind im Anhang.
Die Konfig. bis auf die Datenbank ist auf beiden Systemen gleich.
Welche Datenbank nutzt du eigentlich?
Grüße Bernd
Da fällt mir noch ein, logproxy hatte ich vor der aktuellen Änderung komplett aus dem gplot-File entfernt.
Das hatte keine Auswirkung.
Hi Bernd,
ZitatWelche Datenbank nutzt du eigentlich?
Produktiv nutze ich MySQL/MariaDB. Aber zum Testen habe ich alles zur Verfügung, auch SQLite und Postgre.
Den Test bei mir habe ich mit MariaDB gemacht.
Naja, werden wir schon hinkriegen ...
Habe deine Daten importiert und läuft auf meiner MariaDB astrein.
Einerseits gut, hilft mir bloß nicht. :-\
Hmm, mal weiterschauen ...
Ich habe etwas justiert und bei mir getestet. Es hat zunächst keinerlei negativen Einfluß.
Jetzt kommt es nur noch darauf an, dass es bei dir funktioniert.
Bei dieser Testversion wirst du im Log so etwas sehen wenn ein SVG aufgerufen wird:
2019.10.10 22:05:43.029 1: LogDB1 - Init Maxval: -9223372036854775807 , Init Minval: 9223372036854775807
2019.10.10 22:05:43.275 1: LogDB1 - Maxval result: 1727.4 , Minval result: 1727.4
2019.10.10 22:05:43.276 1: LogDB1 - Maxval result: 1727.4 , Minval result: 1727.4
2019.10.10 22:05:43.277 1: LogDB1 - Maxval result: 1728.1 , Minval result: 1727.4
2019.10.10 22:05:43.278 1: LogDB1 - Maxval result: 1728.4 , Minval result: 1728.1
2019.10.10 22:05:43.279 1: LogDB1 - Maxval result: 1728.4 , Minval result: 1728.4
2019.10.10 22:05:43.280 1: LogDB1 - Maxval result: 1728.4 , Minval result: 1728.4
2019.10.10 22:05:43.280 1: LogDB1 - Maxval result: 1729.7 , Minval result: 1728.4
2019.10.10 22:05:43.281 1: LogDB1 - Maxval result: 1730.2 , Minval result: 1729.7
2019.10.10 22:05:43.282 1: LogDB1 - Maxval result: 1730.4 , Minval result: 1730.2
2019.10.10 22:05:43.282 1: LogDB1 - Maxval result: 1730.7 , Minval result: 1730.4
2019.10.10 22:05:43.283 1: LogDB1 - Maxval result: 1730.7 , Minval result: 1730.7
2019.10.10 22:05:43.283 1: LogDB1 - Maxval result: 1730.7 , Minval result: 1730.7
2019.10.10 22:05:43.284 1: LogDB1 - Maxval result: 1730.7 , Minval result: 1730.7
2019.10.10 22:05:43.284 1: LogDB1 - Maxval result: 1730.7 , Minval result: 1730.7
2019.10.10 22:05:43.285 1: LogDB1 - Maxval result: 1730.9 , Minval result: 1730.7
2019.10.10 22:05:43.285 1: LogDB1 - Maxval result: 1730.9 , Minval result: 1730.9
2019.10.10 22:05:43.286 1: LogDB1 - Maxval result: 1732.7 , Minval result: 1730.9
2019.10.10 22:05:43.288 1: LogDB1 - Init Maxval: -9223372036854775807 , Init Minval: 9223372036854775807
Das kommt dann wieder raus, will nur wissen was bei dir ausgedruckt wird.
Liegt im contrib.
Grüße,
Heiko
Hallo Heiko,
hier das Log für den 10.10.
Zitat2019.10.11 18:26:49 1: logdb - Init Maxval: -9223372036854775807 , Init Minval: 9223372036854775807
2019.10.11 18:26:49 1: logdb - Init Maxval: -9223372036854775807 , Init Minval: 9223372036854775807
2019.10.11 18:26:49 1: logdb - Maxval result: 1727.4 , Minval result: 9223372036854775807
2019.10.11 18:26:49 1: logdb - Maxval result: 1727.4 , Minval result: 1727.4
2019.10.11 18:26:49 1: logdb - Maxval result: 1728.1 , Minval result: 1727.4
2019.10.11 18:26:49 1: logdb - Maxval result: 1728.4 , Minval result: 1728.1
2019.10.11 18:26:49 1: logdb - Maxval result: 1728.4 , Minval result: 1728.4
2019.10.11 18:26:49 1: logdb - Maxval result: 1728.4 , Minval result: 1728.4
2019.10.11 18:26:49 1: logdb - Maxval result: 1729.7 , Minval result: 1728.4
2019.10.11 18:26:49 1: logdb - Maxval result: 1730.2 , Minval result: 1729.7
2019.10.11 18:26:49 1: logdb - Maxval result: 1730.4 , Minval result: 1730.2
2019.10.11 18:26:49 1: logdb - Maxval result: 1730.7 , Minval result: 1730.4
2019.10.11 18:26:49 1: logdb - Maxval result: 1730.7 , Minval result: 1730.7
2019.10.11 18:26:49 1: logdb - Maxval result: 1730.7 , Minval result: 1730.7
2019.10.11 18:26:49 1: logdb - Maxval result: 1730.7 , Minval result: 1730.7
2019.10.11 18:26:49 1: logdb - Maxval result: 1730.7 , Minval result: 1730.7
2019.10.11 18:26:49 1: logdb - Maxval result: 1730.9 , Minval result: 1730.7
2019.10.11 18:26:49 1: logdb - Maxval result: 1730.9 , Minval result: 1730.9
2019.10.11 18:26:49 1: logdb - Maxval result: 1732.7 , Minval result: 1730.9
2019.10.11 18:26:49 1: logdb - Maxval result: 1732.7 , Minval result: 1732.7
2019.10.11 18:26:49 1: logdb - Maxval result: 1732.7 , Minval result: 1732.7
2019.10.11 18:26:49 1: logdb - Maxval result: 1732.7 , Minval result: 1732.7
2019.10.11 18:26:49 1: logdb - Maxval result: 1732.7 , Minval result: 1732.7
2019.10.11 18:26:49 1: logdb - Maxval result: 1732.7 , Minval result: 1732.7
2019.10.11 18:26:49 1: logdb - Init Maxval: -9223372036854775807 , Init Minval: 9223372036854775807
2019.10.11 18:26:49 1: logdb - Init Maxval: -9223372036854775807 , Init Minval: 9223372036854775807
Bei delta-h sind um 00:30 keine Daten ???
Zitat2019-10-10_00:30:00
2019-10-10_01:30:00 0
2019-10-10_02:30:00 0.7
2019-10-10_03:30:00 0.3
2019-10-10_04:30:00 0
2019-10-10_05:30:00 0
2019-10-10_06:30:00 1.3
2019-10-10_07:30:00 0.5
2019-10-10_08:30:00 0.2
2019-10-10_09:30:00 0.3
2019-10-10_10:30:00 0
2019-10-10_11:30:00 0
2019-10-10_12:30:00 0
2019-10-10_13:30:00 0
2019-10-10_14:30:00 0.2
2019-10-10_15:30:00 0
2019-10-10_16:30:00 0
2019-10-10_17:30:00 1.8
2019-10-10_18:30:00 0
2019-10-10_19:30:00 0
2019-10-10_20:30:00 0
2019-10-10_21:30:00 0
2019-10-10_22:30:00 0
2019-10-10_23:30:00 0
#KS300:data::delta-h:$val=~s/.*\sR..([\d.]*).*/$1/eg
2019-10-10_12:00:00 -9.22337e+18
#KS300:data::delta-d:$val=~s/.*\sR..([\d.]*).*/$1/eg
für den 06.10.
Zitat2019-10-06_00:30:00 0
2019-10-06_01:30:00 0
2019-10-06_02:30:00 0
2019-10-06_03:30:00 0
2019-10-06_04:30:00 0
2019-10-06_05:30:00 0
2019-10-06_06:30:00 0
2019-10-06_07:30:00 0
2019-10-06_08:30:00 9.22337e+18
2019-10-06_09:30:00 0.5
2019-10-06_10:30:00 2.3
2019-10-06_11:30:00 1
2019-10-06_12:30:00 1.8
2019-10-06_13:30:00 1.5
2019-10-06_14:30:00 2
2019-10-06_15:30:00 0.5
2019-10-06_16:30:00 0.3
2019-10-06_17:30:00 2
2019-10-06_18:30:00 0.8
2019-10-06_19:30:00 1.3
2019-10-06_20:30:00 3.3
2019-10-06_21:30:00 0.8
2019-10-06_22:30:00 0
2019-10-06_23:30:00 0
#KS300:data::delta-h:$val=~s/.*\sR..([\d.]*).*/$1/eg
2019-10-06_12:00:00 -9.22337e+18
#KS300:data::delta-d:$val=~s/.*\sR..([\d.]*).*/$1/eg
Zitat2019.10.11 18:36:19 1: logdb - Init Maxval: -9223372036854775807 , Init Minval: 9223372036854775807
2019.10.11 18:36:19 1: logdb - Maxval result: -9223372036854775807 , Minval result: 9223372036854775807
2019.10.11 18:36:19 1: logdb - Maxval result: 1698.6 , Minval result: -9223372036854775807
2019.10.11 18:36:19 1: logdb - Maxval result: 1699.1 , Minval result: 1698.6
2019.10.11 18:36:19 1: logdb - Maxval result: 1701.4 , Minval result: 1699.1
2019.10.11 18:36:19 1: logdb - Maxval result: 1702.4 , Minval result: 1701.4
2019.10.11 18:36:19 1: logdb - Maxval result: 1704.2 , Minval result: 1702.4
2019.10.11 18:36:19 1: logdb - Maxval result: 1705.7 , Minval result: 1704.2
2019.10.11 18:36:19 1: logdb - Maxval result: 1707.7 , Minval result: 1705.7
2019.10.11 18:36:19 1: logdb - Maxval result: 1708.2 , Minval result: 1707.7
2019.10.11 18:36:19 1: logdb - Maxval result: 1708.5 , Minval result: 1708.2
2019.10.11 18:36:19 1: logdb - Maxval result: 1710.5 , Minval result: 1708.5
2019.10.11 18:36:19 1: logdb - Maxval result: 1711.3 , Minval result: 1710.5
2019.10.11 18:36:19 1: logdb - Maxval result: 1712.6 , Minval result: 1711.3
2019.10.11 18:36:19 1: logdb - Maxval result: 1715.9 , Minval result: 1712.6
2019.10.11 18:36:19 1: logdb - Maxval result: 1716.7 , Minval result: 1715.9
2019.10.11 18:36:19 1: logdb - Maxval result: 1716.7 , Minval result: 1716.7
2019.10.11 18:36:19 1: logdb - Init Maxval: -9223372036854775807 , Init Minval: 9223372036854775807
2019.10.11 18:36:19 1: logdb - Init Maxval: -9223372036854775807 , Init Minval: 9223372036854775807
Sieht schon etwas besser aus.. :)
Die erste und letzte Zeile vom Log ist doppelt, variiert jedoch zu Teil.
Gruß Bernd
Hallo Bernd,
bitte teste nochmal mit der neuen Version aus dem contrib.
Ich verstehe ehrlich nicht wieso bei dir minval nicht gleichermaßen wie maxval ersetzt wird zu Beginn.
2019.10.11 18:26:49 1: logdb - Maxval result: 1727.4 , Minval result: 9223372036854775807
Vielleicht wird es jetzt deutlicher.
Grüße,
Heiko
Hallo Heiko,
die Logs habe ich angehängt.
Gruß Bernd
Hallo Bernd,
danke für die Logs.
Zitat
2019.10.12 10:57:53 4: DbLog logdb -> ################################################################
2019.10.12 10:57:53 4: DbLog logdb -> ### new get data for SVG ###
2019.10.12 10:57:53 4: DbLog logdb -> ################################################################
2019.10.12 10:57:53 4: DbLog logdb -> main PID: 23866, secondary PID: 23866
2019.10.12 10:57:53 1: logdb - Init Maxval: -9223372036854775807 , Init Minval: 9223372036854775807
2019.10.12 10:57:53 4: logdb - Processing Statement:
SELECT Z.TIMESTAMP, Z.DEVICE, Z.READING, Z.VALUE from (SELECT DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s') AS TIMESTAMP,
DEVICE AS DEVICE,
READING AS READING,
VALUE AS VALUE FROM history WHERE 1=1 AND DEVICE = 'KS300' AND READING = 'data' AND TIMESTAMP < STR_TO_DATE('2019-10-10 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP > DATE_SUB(STR_TO_DATE('2019-10-10 00:00:00', '%Y-%m-%d %H:%i:%s'),INTERVAL 1 DAY) ORDER BY TIMESTAMP DESC LIMIT 1 ) AS Z
UNION ALL SELECT
MAX(DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s')) AS TIMESTAMP,
MAX(DEVICE) AS DEVICE,
MAX(READING) AS READING,
MAX(VALUE)
FROM history WHERE 1=1 AND DEVICE = 'KS300' AND READING = 'data' AND TIMESTAMP >= STR_TO_DATE('2019-10-10 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP <= STR_TO_DATE('2019-10-11 00:00:00', '%Y-%m-%d %H:%i:%s') GROUP BY DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H') ORDER BY TIMESTAMP
2019.10.12 10:57:53 5: logdb - SQL-result -> TS: 2019-10-10 00:51:27, DEV: KS300, RD: data, VAL: T: 9.0 H: 92 W: 0.0 R: 1727.4 IR: no Wi: 0
2019.10.12 10:57:53 1: logdb - SQL-result -> TS: 2019-10-10 00:51:27, DEV: KS300, RD: data, VAL: T: 9.0 H: 92 W: 0.0 R: 1727.4 IR: no Wi: 0
2019.10.12 10:57:53 5: logdb - SQL-result -> TS: 2019-10-10 01:54:59, DEV: KS300, RD: data, VAL: T: 8.9 H: 92 W: 0.0 R: 1727.4 IR: no Wi: 0
2019.10.12 10:57:53 1: logdb - SQL-result -> TS: 2019-10-10 01:54:59, DEV: KS300, RD: data, VAL: T: 8.9 H: 92 W: 0.0 R: 1727.4 IR: no Wi: 0
2019.10.12 10:57:53 1: logdb - delta-h - TS result: 2019-10-10 00:30:00 , Maxval result: 1727.4 , Minval result: 1727.4 , WRITEOUT: 1
2019.10.12 10:57:53 5: logdb - Output delta-h -> TS: 01, LASTTS: 00, OUTTS: 2019-10-10 00:30:00, OUTVAL: -9.22337e+18
Ich hoffe, ich komme damit weiter. Schaue ich mir heute Abend an. Will jetzt erst einmal diesen wunderschönen Tag in der Natur verbringen.
Nebenbei ... deine Graphen müssten jetzt meiner Meinung nach aber ok aussehen ?
LG,
Heiko
Leider sind die Grafiken noch nicht ok, um 00:30 sind die Balken noch da.
Hallo Bernd,
ich glaube noch etwas bereinigt zu haben. Bitte nochmal aus dem contrib laden.
Die verbose5 logs helfen mir. Es reicht wenn du die dann wieder mit anhängst und eine Ausgabe von "preprocessed input"
Grüße,
Heiko
Hallo Heiko,
kannst Du mir sagen welchen Zeitraum delta-d zur Berechnung verwendet?
Scheinbar ist es in meinem Fall nicht 00:00 bis 23:59:59, kann man es ändern und wenn ja wie.
Danke und Gruß
Alex
Hallo Alex,
welche Zeiträume abgefragt werden siehst du mit einem verbose 4 oder 5:
Zitat
2019.10.14 17:53:59.333 4: DbLog LogDB1 -> ################################################################
2019.10.14 17:53:59.334 4: DbLog LogDB1 -> ### new get data for SVG ###
2019.10.14 17:53:59.335 4: DbLog LogDB1 -> ################################################################
2019.10.14 17:53:59.335 4: DbLog LogDB1 -> main PID: 17712, secondary PID: 29766
2019.10.14 17:53:59.337 1: LogDB1 - Init Maxval: -9223372036854775807 , Init Minval: 9223372036854775807
2019.10.14 17:53:59.337 4: DbLog LogDB1 -> deltacalc: day
2019.10.14 17:53:59.338 4: LogDB1 - Processing Statement:
SELECT Z.TIMESTAMP, Z.DEVICE, Z.READING, Z.VALUE from (SELECT DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s') AS TIMESTAMP,
DEVICE AS DEVICE,
READING AS READING,
VALUE AS VALUE FROM fhemtest1.history WHERE 1=1 AND DEVICE = 'KS300' AND READING = 'data' AND TIMESTAMP < STR_TO_DATE('2019-10-10 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP > DATE_SUB(STR_TO_DATE('2019-10-10 00:00:00', '%Y-%m-%d %H:%i:%s'),INTERVAL 1 DAY) ORDER BY TIMESTAMP) AS Z
UNION ALL SELECT
MAX(DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s')) AS TIMESTAMP,
MAX(DEVICE) AS DEVICE,
MAX(READING) AS READING,
MAX(VALUE)
FROM fhemtest1.history WHERE 1=1 AND DEVICE = 'KS300' AND READING = 'data' AND TIMESTAMP >= STR_TO_DATE('2019-10-10 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP <= STR_TO_DATE('2019-10-11 00:00:00', '%Y-%m-%d %H:%i:%s') GROUP BY DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H') ORDER BY TIMESTAMP
Wobei der Zusatz "INTERVAL 1 DAY" wichtig ist der die DB veranlasst einen Tag vorher auszuwerten, in dem Beispiel dann real > 2019-10-09 00:00:00 und < 2019-10-10 00:00:00.
Beeinflussen kannst du es selbst eigentlich nur indirekt über Parameter des SVG (Zeitgrenzen), wobei ich auch erst nachschauen müsste was SVG an der Stelle alles bietet. Aber als ich jetzt über deinen Einwand nachdachte, bin ich noch darauf gekommen dass das neue SQL delta-h und delta-d unterschiedlich bezüglich "Limit" behandeln müsste.
Ich habe die Testversion abgeändert und wieder ins contrib zum Download bereitgestellt.
Eine erweiterte Logausgabe ist auch dabei (DbLog LogDB1 -> deltacalc: day), damit man gleich sieht für welche delta-Ermittlung das folgende Statement und dessen Ergebnisse gilt.
Grüße,
Heiko
Hallo Heiko,
jetzt sieht es gut aus :)
Zitat2019-10-10_01:30:00 0
2019-10-10_02:30:00 0.7
2019-10-10_03:30:00 0.3
2019-10-10_04:30:00 0
2019-10-10_05:30:00 0
2019-10-10_06:30:00 1.3
2019-10-10_07:30:00 0.5
2019-10-10_08:30:00 0.2
2019-10-10_09:30:00 0.3
2019-10-10_10:30:00 0
2019-10-10_11:30:00 0
2019-10-10_12:30:00 0
2019-10-10_13:30:00 0
2019-10-10_14:30:00 0.2
2019-10-10_15:30:00 0
2019-10-10_16:30:00 0
2019-10-10_17:30:00 1.8
2019-10-10_18:30:00 0
2019-10-10_19:30:00 0
2019-10-10_20:30:00 0
2019-10-10_21:30:00 0
2019-10-10_22:30:00 0
2019-10-10_23:30:00 0
#KS300:data::delta-h:$val=~s/.*\sR..([\d.]*).*/$1/eg
2019-10-10_12:00:00 5.3
#KS300:data::delta-d:$val=~s/.*\sR..([\d.]*).*/$1/eg
heute habe ich eine kleine Abweichung, würde mich jedoch nicht stören (Daten sind gekürzt):
Zitat2019-10-14_05:30:00 0
2019-10-14_06:30:00 0
2019-10-14_07:30:00 0
2019-10-14_08:30:00 0.3
2019-10-14_09:30:00 0
2019-10-14_10:30:00 0
#KS300:data::delta-h:$val=~s/.*\sR..([\d.]*).*/$1/eg
2019-10-14_12:00:00 0.3
#KS300:data::delta-d:$val=~s/.*\sR..([\d.]*).*/$1/eg
2019-10-14_06:36:50 -2
2019-10-14_06:49:33 -2
2019-10-14_06:52:05 -2
2019-10-14_07:09:53 -2
2019-10-14_07:12:25 1
2019-10-14_07:14:58 -2
2019-10-14_07:40:23 -2
2019-10-14_08:05:48 -2
2019-10-14_08:13:25 -2
2019-10-14_08:59:10 -2
#KS300:data:::$val=~s/.*IR..(yes|no)(\d*).*/$1eq"yes"?1:-2/eg
Logs und Bilder im Anhang.
Gruß Bernd
Hi Bernd,
:) ... hast du die Version benutzt, die ich gerade hochgeladen hatte ? EDIT: ja, habs gesehen, die logs sind ja dabei ::)
Wegen deinen kleinen (roten) Abweichungen können wir auch nochmal schauen. Da müssen wir die verbose 5 SQL Ergebnisse genauer ansehen. Aber ich vermute dass hier tatsächlich Werte aus der DB kommen die das verursachen. Damit wäre ich dann auch zufrieden ;)
zwichen 7:30 und 8:30 hast du tatsächlich ein Diff in der DB:
Zitat
2019.10.14 18:41:06 5: logdb - SQL-result -> TS: 2019-10-14 08:59:10, DEV: KS300, RD: data, VAL: T: 11.5 H: 92 W: 0.0 R: 1733.5 IR: no Wi: 0
2019.10.14 18:41:06 1: logdb - SQL-result -> TS: 2019-10-14 08:59:10, DEV: KS300, RD: data, VAL: T: 11.5 H: 92 W: 0.0 R: 1733.5 IR: no Wi: 0
2019.10.14 18:41:06 1: logdb - delta-h - TS result: 2019-10-14 07:30:00 , Maxval result: 1733.2 , Minval result: 1733.2 , WRITEOUT: 1
2019.10.14 18:41:06 5: logdb - Output delta-h -> TS: 08, LASTTS: 07, OUTTS: 2019-10-14 07:30:00, OUTVAL: 0
2019.10.14 18:41:06 5: logdb - SQL-result -> TS: 2019-10-14 09:50:01, DEV: KS300, RD: data, VAL: T: 13.0 H: 92 W: 0.0 R: 1733.5 IR: no Wi: 0
2019.10.14 18:41:06 1: logdb - SQL-result -> TS: 2019-10-14 09:50:01, DEV: KS300, RD: data, VAL: T: 13.0 H: 92 W: 0.0 R: 1733.5 IR: no Wi: 0
2019.10.14 18:41:06 1: logdb - delta-h - TS result: 2019-10-14 08:30:00 , Maxval result: 1733.5 , Minval result: 1733.5 , WRITEOUT: 1
2019.10.14 18:41:06 5: logdb - Output delta-h -> TS: 09, LASTTS: 08, OUTTS: 2019-10-14 08:30:00, OUTVAL: 0.3
Das ist beruhigend :)
Ok Heiko,
nochmals danke.
Die KS300 ist beim Senden nicht so zuverlässig, kann sein das es daher kommt.
Ich bin auch zufrieden.
Schönen Abend noch.
Bernd
Dir auch Bernd.
Ich werde die Routine jetzt bereinigen und wieder "schön" machen. Wenn ich damit fertig bin, stelle ich die Version wieder ins contrib mit der Bitte um Test. Alex wird sich sicher auch noch melden und hoffentlich ebenfalls ein positives Ergebnis verkünden.
LG,
Heiko
Die bereinigte Version liegt im contrib.
Bitte teste(t) diese bitte.
Mit verbose 5 sollte nun ebenfalls recht gut nachvollziehbar werden, was aus der DB selektiert wurde und was an SVG zurück geliefert wird.
LG,
Heiko
Passt, super. :)
Produktiv, wie auch Test mit SQLite....Daumen hoch.
Grüsse, Bernd
Habe die Version jetzt noch auf meiner Postgre mit deinen Daten getestet ... läuft auch.
Hallo Heiko,
leider besteht mein Problem weiterhin.
Zum Hintergrund des Problems:
Ich habe am 01.10 einen neuen Stromzähler bekommen, dieser startete natürlich wieder bei 1KW/h und natürlich wurde der Wechsel mitten am Tag durchgeführt.
Nun dachte ich "bist du mal ein Fuchs und bearbeitest die Daten in der DB".
Die neuen Daten habe ich für den 01.10 gelöscht und den Betrag auf den alten Wert aufaddiert, das Ergebniss habe ich dann um 23:50:59 und 23:59:59 in die DB eingetragen.
Ab dem 02.10 lief dann der neue Wert weiter.
Leider bekomme ich in den SVGs mit delta-d aber für den 2.10 einen Wert von -26643.7 (das ist das Ergebniss vom Wert von 01.10 23:59:59 "26657.9631736" minus 02.10 23:59:56 "14.2591381").
Bei einer Betrachtung von 00:00:00 bis 23:59:59 sollte dies so nicht vorkommen, oder übersehe ich da etwas?
Logfile und Auszug der DB hänge ich an.
Gruß
Alex
Zitat von: Nighthawk am 15 Oktober 2019, 08:49:29
Bei einer Betrachtung von 00:00:00 bis 23:59:59 sollte dies so nicht vorkommen, oder übersehe ich da etwas?
Logfile und Auszug der DB hänge ich an.
Gruß
Alex
Der Tag geht von 00:00:00 bis 00:00:00... ansonsten würde ja die letzte Sekunde gar nicht gewertet werden.
die kleinste einheit von "00:00:00:00.......unendlich" gehört beiden Tagen und ist atomar, also zuerst tag 1, dann tag2.
Du kannst natürlich am nächsten Tag direkt um 00:00:01 direkt den neuen Zählerwert mit setzen, wenn er wirklich mit 0 begonnen hat.
Die "Datenbanktechnisch" optimale Lösung wäre hier (vermutlich), den Wert über ein "monotonic user reading) permanent ansteigend zu machen.
Dann hast Du auch kein Problem mit dem Wechsel "mitte am Tag". Du muss dann eigentlich gar nichts machen!
sG
Joe
Moin Alex und Joe,
abgesehen von dem Hinweis von Joe sehe ich in dem Ergebnis keinen Widerspruch. Es doch tatsächlich die Differenz des Vortageswertes (26657.9631736) zum Wert am 02.10. (14.2591381) in Höhe von rund -26643.7 vorhanden.
Welchen Wert hättest du denn jetzt erwartet ?
BTW ... würde man ein diffValue im DbRep über diese Werte laufen lassen, würde dieser "Zählerwechsel" ignoriert werden. D.h. die negative Flanke würde ausgeblendet. Vgl. auch das Attr "diffAccept" im DbRep. Für eine SVG Erstellung könnte man mit DbRep die Differenzen unter einem neuen Reading-Namen in die DB zurückschreiben lassen und per SVG anzeigen. Weiß aber nicht ob sich der Aufwnd lohnt.
LG,
Heiko
Zitat von: DS_Starter am 15 Oktober 2019, 09:58:59
Weiß aber nicht ob sich der Aufwnd lohnt.
Darum würde ich in diesem Fall eben eher zum Userreading mit Monotonic raten.
Auszug aus der Hilfe:
monotonic: wenn die Differenz zw. dem aktuellen und dem vorherigen Wert positiv ist wird diese Differenz zum Reading addiert.
Damit lässt sich von einem Zähler der bei Stromverlust zurückgesetzt wird ein monoton wachsender Zähler ableiten.
Beispiel:
attr myPowerMeter userReadings power differential { ReadingsVal("myPowerMeter","counters.A",0)/1250.0}
Ja für die Zukunft würde ich es auch so machen. Ich dachte jetzt mit meiner Anmerkung eher an den bestehenden Sachverhalt. ;)
Hallo zusammen,
danke für die Rückmeldung.
Erwartet hätte ich eigentlich die Differenz des Tages, in etwa so:
2019-10-02 00:00:29 Stromzaehler OBIS total_consumption: 6.39221171 total_consumption 6.39221171
und
2019-10-02 23:59:56 Stromzaehler OBIS total_consumption: 14.2591381 total_consumption 14.2591381
also 14.2591381 - 6.39221171
Warum wird hier der Vortag mit herangezogen und kann ich da nicht über einfache Wertemanipulation in der DB das Ganze bereinigen (das wäre mir am liebsten)?
Gruß
Alex
PS
ich habe hier noch mal den SQL Export mit angehängt
Hallo Alex,
ZitatWarum wird hier der Vortag mit herangezogen ...
Zunächst mal sind es historische Gründe, d.h. man hatte sich irgenwann einmal entschlossen die Selektion so zu gestalten und ich möchte sie aus Kompatibilitätsgründen auch nicht komplett umstoßen.
Es erscheint mir auch logisch, da man z.B. auch keine realistischen Werte bekommt, wenn der Vortag mit einem niedrigen Wert endet, der neue Tag mit einem vergleichsweise hohen Wert beginnt und dieser vlt. sogar kaum eine Steigerung erfährt. Dann wäre die ausgegebene Diff sehr klein, was nicht stimmt wenn man vom Vortageswert ausgeht.
(Joe wird sich vllt. noch erinnern wie wir am diffValue im DbRep gefeilt haben um die Logik auszuprägen 8) )
Es war bisher ebenfalls so implementiert, dass bei den Diff-Berechnungen die vorherige Periode, also Tag oder Stunde bei delta-h, mit berücksichtigt wurde. Kannst gerne mal einen Vergleich mit der aktuell offiziell eingecheckten Version 4.7.5 durchführen.
Die Werte nachträglich zu manipulieren wäre m.M. nach wie schon angedeutet mit einem diffValue (mit der aggregation day) im DbRep problemloas möglich. Das Ganze mit der Option "writeToDB". Dann hast du für jeden Tag die Differenz als fertigen Wert in der DB stehen und brauchst nur noch im SVG anzeigen. Die Definition kannst du z.B. jede Nacht (4:00) für den Vortag laufen lassen. Man müsste das natürlich vorher auf einer TestDB laufen lassen ob das Ergebnis den Wünschen entspricht. Aber es wäre ein möglicher Weg denke ich.
LG,
Heiko
Hallo Heiko,
danke, ich versuche es mit DiffValue.
Gruß
Alex
Hallo zusammen,
ich möchte nochmal die Bitte erneuern, die DbLog-Version aus meinem contrib zu testen. Ist jetzt vllt. nach den letzten Beiträgen etwas untergegangen.
Es ist die SVG Erstellung bzgl. delta-h und delta-d geändert.
Einfacher Download mit diesem Befehl in der FHEM Kommandozeile. Bitte so komplett mit den Ausführungszeichen am Anfang und Ende eingeben!!!
Zitat
"wget -qO ./FHEM/93_DbLog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbLog.pm"
Grüße,
Heiko
Hallo Heiko,
läuft bei mir seit einigen Tagen ohne Auffälligkeiten.
Gruß
Alex
Hallo Alex,
danke für die Rückmeldung !
LG,
Heiko
Hallo Heiko,
auch bei mir sieht alles super aus, danke nochmal.
Gruß Bernd
Danke Bernd !
Mal schauen ob sich noch Vertreter der SQLite und Postgre "Fraktion" melden.
Ansonsten checke ich die Version bald ein. Überlege nur noch den richtigen Zeitpunkt. Da ich in Kürze ein paar Tage Urlaub mache, wird es wahrscheinlich erst danach. Bei einer so zentralen Änderung möchte ich gerne verfügbar sein nach dem check-In . :)
Grüße,
Heiko
Von mit aus, mach dir keinen Stress.
Genieße lieber den Urlaub.
Hallo Heiko,
Zitat von: DS_Starter am 19 Oktober 2019, 13:40:23Einfacher Download mit diesem Befehl in der FHEM Kommandozeile. Bitte so komplett mit den Ausführungszeichen am Anfang und Ende eingeben!!!
danke für den Tipp, der macht Tests soooooooooo viel einfacher!
ZitatMal schauen ob sich noch Vertreter der SQLite und Postgre "Fraktion" melden.
Ich habs bei meinem Testsystem eingespielt, sollte ich keinen Aufschrei tätigen hat wie gewohnt alles funktioniert :)
Wünsch einen schönen Urlaub.
Grüße
Pyro
Guten Abend zusammen,
nach nun gut zweiwöchiger Testzeit habe ich soeben die DbLog-Version 4.8.0 eingecheckt und ist morgen früh im Regelupdate enthalten.
Danke an alle die mitgeholfen und getestet haben !!
Hoffen wir, dass es bei allen anderen Nutzern ebenfalls so gut läuft wie im Testerkreis.
Grüße und einen guten Wochenstart,
Heiko
Hallo zusammen,
ich habe meine ToDo weiter abgearbeitet und Feature Request von obi aus #804 umgesetzt.
In der V 4.9.0 gibt es nun ein Attribut defaultMinInterval mit dem man global für alle Devices ein MinIntervall einstellen kann.
Auszug aus ComRef:
defaultMinInterval
attr <device> defaultMinInterval <devspec>::<MinInterval>[::force],[<devspec>::<MinInterval>[::force]] ...
Mit diesem Attribut wird ein Standard Minimum Intervall für devspec festgelegt. Ist defaultMinInterval angegeben, wird der Logeintrag nicht geloggt, wenn das Intervall noch nicht erreicht und der Wert des Readings sich nicht verändert hat. Ist der optionale Parameter "force" hinzugefügt, wird der Logeintrag auch dann nicht nicht geloggt, wenn sich der Wert des Readings verändert hat.
Eventuell im Quelldevice angegebene Spezifikationen DbLogExclude / DbLogInclude haben Vorrag und werden durch defaultMinInterval nicht überschrieben.
Die Eingabe kann mehrzeilig erfolgen.
Beispiele
attr dblog defaultMinInterval .*::120::force
# Events aller Devices werden nur geloggt, wenn 120 Sekunden zum letzten Logeintrag vergangen sind ist (Reading spezifisch)
attr dblog defaultMinInterval (Weather|SMA)::300
# Events der Devices "Weather" und "SMA" werden nur geloggt wenn 300 Sekunden zum letzten Logeintrag vergangen sind (Reading spezifisch) und sich der Wert nicht geändert hat.
attr dblog defaultMinInterval TYPE=CUL_HM::600::force
# Events aller Devices des Typs "CUL_HM" werden nur geloggt, wenn 600 Sekunden zum letzten Logeintrag vergangen sind ist (Reading spezifisch)
Einfacher Download mit diesem Befehl in der FHEM Kommandozeile. Bitte so komplett mit den Ausführungszeichen am Anfang und Ende eingeben!!!
"wget -qO ./FHEM/93_DbLog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbLog.pm"
Wer mag bitte mal testen.
LG und schönen Sonntag ...
Heiko
Die neue Version mit den oben genannten Features sowie kleineren Korrekturen ist soeben in das Repository gewandert und ist morgen früh im Update enthalten.
Grüße,
Heiko
Ich glaub das Problem ist noch nicht ganz beseitigt.
Die Darstellung des Plot´s geht hervorragend.
Ich hab jedoch das Label son configuriert das ich dort die Maximal,-Minimal und Durchschnittswerte angezeigt bekomme.
Leider taucht hier wieder der Wert "-9.22337e+18" auf.
Ich hab hier mal zwei Bilder vom Plot mit Label und die Configuration vom Label.
Ein "Show preprocessed input" gibt folgendes aus:
Zitatget logdb HISTORY INT 2019-11-01_00:00:00 2019-11-30_23:59:59 HM_6CF841_IEC_01:kWh::delta-d
2019-11-02_12:00:00 11.9
2019-11-03_12:00:00 19.5
2019-11-04_12:00:00 12.9
2019-11-05_12:00:00 10.8
2019-11-06_12:00:00 10.2
2019-11-07_12:00:00 12.6
2019-11-08_12:00:00 18.2
2019-11-09_12:00:00 19.3
2019-11-10_12:00:00 18.6
2019-11-11_12:00:00 13.4
2019-11-12_12:00:00 9
2019-11-13_12:00:00 9.6
2019-11-14_12:00:00 9.4
2019-11-15_12:00:00 13.9
2019-11-16_12:00:00 21.5
2019-11-17_12:00:00 15.8
2019-11-18_12:00:00 12.8
2019-11-19_12:00:00 12.2
2019-11-20_12:00:00 4.5
#HM_6CF841_IEC_01:kWh::delta-d:
Hier ist mir aufgefallen das der Wert vom 01.11.2019 fehlt. Das ist jetzt nicht das Problem aber vieleicht ein entscheidender Hinweis.
Hallo Marco,
ich gehe stark davon aus, dass es in deiner DB keinen Wert für den 31.10.2019 des besagten Devices/Readings gibt.
Dadurch gibt es für den Werteparser keinen Anfangswert zur Berechnung der Tagesdifferenz und die Resultierende ist quasi "unendlich" -> wird nicht ausgegeben ab V 4.8.0.
Zur Lösung schlage ich dir vor, einfach einen definierten Anfangswert in der DB zu speichern, z.B. 0 oder du weißt welchen kWh-Wert du dort besser platzieren solltest. Am 01.12. sollte sich dieses Problem von allein erledigen.
Läuft dein DbLog im asynchronen Mode, kannst du einfach diesen Befehl nutzen:
set <name> addCacheLine 2019-10-31 23:00:00|HM_6CF841_IEC_01|CUL_HM|manual|kWh|0|
Ansonsten gehen Einfügungen auch einfach über ein DbRep-Device.
Grüße,
Heiko
Vielen Dank.
Hab einen wert für den 31.10.2019 eingetragen -> funktioniert!
Gruß
Marco
Hallo miteinander,
in diesem Thread https://forum.fhem.de/index.php/topic,106769.0.html wurde berichtet, dass das Eventsplitting dann nicht richtig funktioniert, wenn der Value eines Events leer ist.
In dem vorliegenden Fall ist es tatsächlich so, dass das Fehlen eines Wertes "vermuten" lässt, es handele sich um das state-Reading obwohl "state" als Reading mitgeliefert wird. Es ist der default wenn das Attribut addStateEvent nicht explizit 0 gesetzt wird.
Ich habe die Defaultzerlegung so angepasst, dass ein solcher Fall berücksichtigt wird. Der Test war bei mir und im obigen Thread erfolgreich, würde mich aber freuen wenn der eine oder andere auch noch testen würde.
Die Testversion 4.9.4 liegt in meinem contrib.
Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben:
"wget -qO ./FHEM/93_DbLog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbLog.pm"
Danach FHEM restarten.
LG,
Heiko
Hallo,
ich suche nach einer Optimierung des Löschens von Einzelwerten nach dem Motto: Was interessiert mich das reading von gestern.
Ich messe alle 30 Sekunden den Aktuellen Stromverbrauch im Haus und lasse schreibe das als dummy in ein Device "Aktueller Verbrauch".
Früher habe ich das brav über ein FileLog geloggt und hatte eben jeden Tag Werte. Ab und zu habe ich dann die Logdatei gelöscht. Durch die vielen Schreibvorgänge auf der SD Karte hatte ich dann auch schon mal saubere crashes.
Nun habe ich auf dbLog umgestellt. Klar kann ich den AktuellerVerbrauch dort entweder mit dblogInclude oder eben der dblog.conf als |AktuellerVerbrauch.:.*| in die Datenbank schreiben.
Aber auch hier sind es mir zuviele Werte und letztlich brauche ich die von gestern nicht in der Detaillierung.
Im TabletUI möchte ich aber einen Tageschart haben. Also muss ich loggen.
Wie bekomme ich nun automatisch z.B. alle Werte AktuellerVerbrauch vom Vortag (oder älter 24 Stunden) aus der Datenbank (ohne die dabei zu korrumpieren,zerstören ect??
Danke für die Hilfe
Jörg
Hallo Jörg,
für Pflegemassnahmen von Datenbankdaten gibt es das Modul DbRep. Es stellt umfangreiche Möglichkeiten bereit Daten auszudünnen, zu verändern und zu löschen.
Es können relevante Zeiträume, devices und readings festgelegt werden.
Der einfachste Fall ist im Wiki hier beschrieben (delEntries): https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#.28regelm.C3.A4.C3.9Figes.29_l.C3.B6schen_von_Datenbanks.C3.A4tzen
Ansonsten schau dir im DbRep auch mal die set-Befehle delDoublets, delSeqDoublets und reduceLog an.
Weiterhin gibt es eingebaute Möglichkeiten für Backup und Restore. Ein valides Datenbankbackup sollte immer ! verfügbar sein.
Grüße,
Heiko
Zitat von: jnewton957 am 18 Januar 2020, 10:49:38
Wie bekomme ich nun automatisch z.B. alle Werte AktuellerVerbrauch vom Vortag (oder älter 24 Stunden) aus der Datenbank (ohne die dabei zu korrumpieren,zerstören ect??
Hier ist ein .gplot für Heute und Gestern, Werte pro Stunde am Beispiel eines Regenmessers aus DBLOG (so heißt das DbLog-Device):
# Created by FHEM/98_SVG.pm, 2019-11-10 17:46:51
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Regenmenge'
set ytics
set y2tics
set grid
set ylabel ""
set y2label "Niederschlag mm/qm"
set yrange [0:]
set y2range [0:]
#LP_LogProxy DbLog:DBLOG,offset=24*60*60:DI_RainGaugeStats:RainNewValue::delta-h
#DBLOG DI_RainGaugeStats:RainNewValue::delta-h
plot "<IN>" using 1:2 axes x1y2 title 'mm/qm Gestern' ls l2 lw 1 with steps,\
"<IN>" using 1:2 axes x1y2 title 'mm/qm Heute' ls l7fill lw 1 with steps
Ciao, -MN
Result of encoding check
Encoding used by Client (connection): LATIN1
Encoding used by DB fhem: UTF8
Recommendation: Both encodings should be identical. You can adjust the usage of UTF8 connection by setting the UTF8 parameter in file './configDB.conf' to the right value. Your DBD version fulfills UTF8 support, no need to update DB
ich möchte einheitlich UFT8 haben
welche Einträge muss ich genau in welchen configs ergänzen ?
besten Dank
Thomas
Hallo Thomas,
das machst du in dem Config-File für die DB Verbindung, so wie es ja ausgeschrieben wird. Bei dir heißt sie ja configDB.conf. Per default wäre es die db.conf.
Es ist der letzte Parameter:
%dbconfig= (
connection => "mysql:database=fhemtest;host=192.168.2.10;port=3307",
user => "......",
password => "........",
utf8 => 1,
);
Grüße,
Heiko
danke schön !
Hallo,
ich nutze FHEM bereits viele Jahre. Der Grund warum ich bisher noch nicht auf dblog umgestellt habe ist der Speicherverbrauch. Klar ist die SD Karte groß genug. Viele kleine Dateien lassen sich besser handhaben als eine riesige Datei, die auch noch größer ist als alle kleinen Dateien zusammen durch den Index und Overhead. Gerade in Bezug auf Backup.
Aktuell scheint dblog noch immer nur eine Tabelle zu nutzen und die Daten stumpf so abzuspeichern wie in den log files.?
Warum werden nicht die immer wieder gleichen Daten wie DEVICE TYPE READING usw. in jeweils separaten Tabellen gespeichert? Also der Aufbau einer relationalen Datenbank und und nicht einer Tabelle. Verbraucht das zu viel CPU-Performance?
Eine normale Logzeile sieht so aus:
2020-01-01_00:00:04 Hzg_Wozi_Weather measured-temp_avg_day: 18.8
dann würde nur noch dies geloggt werden müssen:
time IndexDevices indexREADING
2020-01-01_00:00:04 1234 9876 18.8
VG
Hallo,
Es gab auch schon vor dir ähnliche Anfragen von Usern mit einem vergleichbaren Anliegen.
Das aktuelle Modul ist schon fast so alt wie fhem selbst und ich hatte es vor ca. vier Jahren in Pflege genommen und stabilisiert dass es den Ansprüchen genügte. Auch das Datenmodell stammt noch aus der Anfangszeit. Warum es damals so und nicht anders erfolgte vermag ich nicht zu beurteilen. Vermutlich aus Vereinfachungsgründen.
Aber grundsätzlich gebe ich dir recht dass einiges verbessert werden sollte und auch das Datenmodell verbesserungeswürdig ist. Auch so manches Handling in FHEM bezüglich Definition und manuellen Tätigkeiten sind suboptimal.
Ebenfalls ist die Indexierung bei dem jetzigen Model ungünstig weil es eben nur eine flachen Tabellenstruktur nutzt.
Um auf deine Frage zu antworten ... An dem jetzigen DbLog Modul werde ich im Hinblick auf die erreichte Stabilität und dem breiten Usereinsatz keine grundlegenden Veränderungen mehr vornehmen. Die damit einhergehende Unruhe, Supportnotwendigkeit und der Aufwand für nötige Migrationsroutinen wäre einfach zu hoch und würde meinen Zeitfonds überstrapazieren. Ich spreche da aus Erfahrung :)
Aber ich habe eigentlich vor ein Nachfolgemodul zu entwickeln welches ein besseres Datenmodell und dementsprechend angepasste SQL verwendet sowie auch sonstige Nachteile des jetzigen Moduls zumindest teilweise behebt.
Bei diesem Vorhaben möchte ich mir auch die Unterstützung von DB / SQL Experten mit ins Boot holen um gleich zu Beginn einen tragfähigen Ansatz zu bauen den ich dann implementiere.
Es wäre zunächst also etwas Konzeption und Diskussionen nötig bevor es losgeht.
Die Frage ist natürlich wann das alles passiert. Ich kann es dir heute noch nicht sagen da ich auch noch ein paar eigene Projekte habe die immer wieder im Interresse der Community bei mir verschoben wurden.
Beobachte das Forum Automatisierung weiterhin und ich würde mich über deine Unterstützung freuen wenn es dann mal los gehen sollte.
viele Grüße,
Heiko
Hallöchen,
ich habe mich die letzten Tage dem erstellen einer neuen DB ein wenig angenommen und mal ein kleines Grundgerüst erstellt, welches auf Basis von MariaDB eine DB anlegt, Tabellen erstellt und Daten in die Tabellen speichern kann.
Hier in den einzelnen Tabellen soll es nix doppeltes geben. Im Idealfall werden pro Logeintrag nur noch 5 Zahlen abgespeichert:
MariaDB [fhemlog]> select * from Log01;
+----------+--------------+-----------+------------+--------------+
| Log01_ID | Timestamp_ID | Device_ID | Reading_ID | ReadValue_ID |
+----------+--------------+-----------+------------+--------------+
| 1 | 1 | 1 | 1 | 1 |
| 2 | 1 | 1 | 1 | 1 |
| 3 | 4 | 1 | 4 | 4 |
| 4 | 5 | 5 | 5 | 5 |
| 5 | 6 | 5 | 5 | 6 |
| 6 | 7 | 5 | 5 | 7 |
| 7 | 8 | 5 | 5 | 8 |
| 8 | 9 | 5 | 5 | 9 |
+----------+--------------+-----------+------------+--------------+
Ich habe die Scripte angehängt.
Eine Abfrage der Daten, also das wieder einlesen habe ich noch nicht angefangen.
Auch wünschenswert ein Import aus alten log files und der alten db habe ich noch nix gemacht.
Guten Rutsch!
Zitat von: DS_Starter am 16 Januar 2021, 18:31:11
Bei diesem Vorhaben möchte ich mir auch die Unterstützung von DB / SQL Experten mit ins Boot holen um gleich zu Beginn einen tragfähigen Ansatz zu bauen den ich dann implementiere.
Es wäre zunächst also etwas Konzeption und Diskussionen nötig bevor es losgeht.
Wie ist der Stand hier. Willst du das aktiv angehen, oder bleibt es wie es ist? Läuft ja auch stabil.
Wenn hier größer umgebaut wird meine Bitte ... schon mal woanders kurz angesprochen ... Integration von InfluxDB wenn möglich.
Zitat von: davidgross am 31 Dezember 2021, 16:14:09
Hier in den einzelnen Tabellen soll es nix doppeltes geben. Im Idealfall werden pro Logeintrag nur noch 5 Zahlen abgespeichert:
Da ist das Normalisieren etwas zu eifrig erfolgt.
Beispiel ReadValue_ID ... es ist schneller einen Wert 100 einzufügen statt in einer eigenen Tabelle nachzusehen ob der Wert 100 schon eine value_ID hat. Außerdem werden beim Normalisieren nur Werte ausgelagert wenn mehrere Spalten von einem Feld abhängig sind. Das ist bei "Value" nicht der Fall.
Die einzigen Informationen die in eine eigene Tabelle ausgelagert werden können, sollten
ReadingID mit Feldern als Schlüssel
- Device
- Reading
- Unit
Feld Event ist (eigentlich) redundant.
Bevor hier Module gebaut werden sollten erstmal die Anforderungen gesammelt und die bekannten Probleme dokumentiert werden.
Hallo allerseits,
danke davidgross für die Startsequenz.
Allerdings gebe ich kadettilac89 recht was die Normalisierung betrifft und würde auch nur
- Device
- Reading
- Unit
in separate Tabellen auslagern und per Fremdschlüssel in die Haupttabelle integrieren. Beim Value bin ich mir unsicher. Könnte
tatsächlich der Fall sein, dass sich im laufe der Zeit ein gewisser Wertevorrat aufbaut aus dem man per Fremdschlüssel partizipieren könnte.
Wir müssen auch die contraints beim Löschen von Datensätzen berücksichtigen etc.
Zitat
Wie ist der Stand hier. Willst du das aktiv angehen, oder bleibt es wie es ist? Läuft ja auch stabil.
Wenn hier größer umgebaut wird meine Bitte ... schon mal woanders kurz angesprochen ... Integration von InfluxDB wenn möglich.
Bis jetzt habe ich für mich noch keinen Projektstart gesetzt. Das Modul werde ich mit dem Projektnamen DbLogNG (NG= new Generation) starten.
Das bisherige 93_DbLog wird im Grunde so bleiben wie es ist, nur Bug Fixes, Code Restrukturierung wo nötig usw habe vor umzusetzen. Insbesondere an der DB-Struktur wird sich aber nichts ändern. Ich will an dieser Stelle Ruhe haben, sonst frisst der Support meine Zeit auf und ich habe keine Ressourcen für etwas Neues.
Momentan arbeite ich an einer DbRep Code Restrukturierung um auch in diesem Modul die Vorraussetzung für eine spätere Verwendung zur Datenpflege zu haben.
Für DbLogNG starte ich am Besten einen neuen Projektthread hier in Automation und lade alle zur Mitarbeit ein.
Ein erfolgreiches Jahr 2022 wünsche ich uns allen !
Heiko
Zitat von: DS_Starter am 01 Januar 2022, 14:25:22
Für DbLogNG starte ich am Besten einen neuen Projektthread hier in Automation und lade alle zur Mitarbeit ein.
Ein erfolgreiches Jahr 2022 wünsche ich uns allen !
Heiko
Ob es nötig ist kannst nur du entscheiden. Du machst ja den ganzen Support :) Sooo schräg finde ich das aktuelle Tabellendesign auch nicht. Es ist auf Performance ausgelegt.
Wenn jemand (z. B. Anforderung davidgross) die DB auf mehrere Tabellen aufteilen will geht das ggf. sogar mit insertable views in MySql und kleinen Änderungen. Müsste man sich ansehen sofern Bedarf besteht.
Solltest du es machen wollen wäre das sicher interessant und lehrreich. Vor allem wenn man InfluxDb mit aufnehmen könnte da diese DB so performant ist. Aber das würde SVG und andere Änderungen nach sich ziehen sonst ist der Mehrwert in keinem Verhältnis zum Aufwand.
@davidgross, was ist dein genaues Problem, von welcher DB-Größe sprichst du? Welche Probleme bereitet dir das Backup?
Hallöchen und ein frohes Neues Jahr!
Was mich damals vor ein paar Jahren gestört hatte das die DB-logs ein vielfaches (2fach, 3-fach, ich weiß es nicht mehr) der logfiles waren. Ich fand das alles ziemlich unhandlich. Im Moment habe ich 2 Raspi's mit jeweils 1GB log files.
Ich werde da die nächsten Tage nochmal etwas mit rumspielen.
Zitat von: DS_Starter am 01 Januar 2022, 14:25:22
Allerdings gebe ich kadettilac89 recht was die Normalisierung betrifft und würde auch nur
- Device
- Reading
- Unit
in separate Tabellen auslagern
Alles auslagern war in diesem Fall erstmal einfacher,.... weil alles das Gleiche
Klar das man sich die Speicherreduzierung mit CPU-Last erkauft.
Zitat von: DS_Starter am 01 Januar 2022, 14:25:22
Bis jetzt habe ich für mich noch keinen Projektstart gesetzt. Das Modul werde ich mit dem Projektnamen DbLogNG (NG= new Generation) starten.
Das bisherige 93_DbLog wird im Grunde so bleiben wie es ist, nur Bug Fixes, Code Restrukturierung wo nötig usw habe vor umzusetzen.
Ja, so hätte ich es auch gedacht. Warum das anfassen was gut läuft...
Ich denke das man das meiste aus den originalen DBLog Codes weiterverwenden kann, und nur die direkten SQL-Routinen anfassen muss. Auch wenn ich mir den Code noch nicht angeschaut habe. Ich als Hobby-Programmierer tue mich immer etwas schwer in Code von anderen rumzuwühlen.
Ich experimentiere mal noch etwas weiter. Tabellen erstellen, Daten schreiben, Exportieren, Sichern, alte logfiles importieren funktioniert auf meinem alten RPI 1 testweise schon mal recht gut. Mal schauen ob ich auch Trends anzeigen kann.
Ich hätte auch nicht gedacht das ich innerhallb weniger Tagen nebenbei soweit komme.
VG
Zitat
Ich denke das man das meiste aus den originalen DBLog Codes weiterverwenden kann, und nur die direkten SQL-Routinen anfassen muss.
Leider nein. Es hat sich viel Ballast angesammelt über viele Jahre der in einem Log-Device eigentlich nichts zu suchen hat und ausgebaut werden soll. Der Code ist auf Packages umzustellen und zu testen,testen,testen ... (für alle unterstützen Datenbanken und nicht nur MariaDB, also auch SQLite und PostgreSQL ! )
Dann ist die Verbindungsinformation über das cfg-File ungünstig (fehleranfällig und Paßwort zu lesen) und soll geändert werden.
Nicht zuletzt sind Pflegeroutinen zu erstellen um Daten auszudünnen bzw. allgemein zu pflegen, d.h. entsprechend in DbRep zu integrieren. Außerdem war der Wunsch noch InfluxDb zu integrieren.
Da kommt bestimmt noch mehr zusammen.
LG
@DS_Starter:
Mir ist folgender Eintrag im Log aufgefallen:
ZitatDbLog logdb - WARNING - "deleteOldDaysNbl" is outdated. Please consider use of DbRep "set <Name> delEntries" instead.
Ich beschränke die vorgehaltenen Daten auf 14 Tage und benutze die Funktion "deleteOldDaysNbl" von DBLog. DBRep benötige ich nicht.
Wenn diese Funktion in DBLog entfällt, dann müsste ich das mit 1 MB grösste in FHEM vorhandene Modul installieren, nur um die Datenbank zu reduzieren. Das ist aus meiner Sicht keine Optimierung.
Daher meine dringliche Bitte, lass deleteOldDaysNbl in DBLog, bitte!
Moin Ellert,
ZitatWenn diese Funktion in DBLog entfällt, dann müsste ich das mit 1 MB grösste in FHEM vorhandene Modul installieren, nur um die Datenbank zu reduzieren. Das ist aus meiner Sicht keine Optimierung.
Daher meine dringliche Bitte, lass deleteOldDaysNbl in DBLog, bitte!
Keine Sorge, es ist nicht geplant die Funktion zu entfernen. Aber bestimmte Funktionen, die im DbLog nicht zum eigentlichen Logging gehören werden von mir nicht weiterentwickelt, sondern stehen mit erweiterten Möglichkeiten im DbRep zur Verfügung. Deswegen der Hinweis für die User, dass die Funktion
veraltet ist.
Grüße,
Heiko
Zitat von: davidgross am 31 Dezember 2021, 16:14:09
Hallöchen,
ich habe mich die letzten Tage dem erstellen einer neuen DB ein wenig angenommen und mal ein kleines Grundgerüst erstellt, welches auf Basis von MariaDB eine DB anlegt, Tabellen erstellt und Daten in die Tabellen speichern kann.
Hier in den einzelnen Tabellen soll es nix doppeltes geben. Im Idealfall werden pro Logeintrag nur noch 5 Zahlen abgespeichert:
MariaDB [fhemlog]> select * from Log01;
+----------+--------------+-----------+------------+--------------+
| Log01_ID | Timestamp_ID | Device_ID | Reading_ID | ReadValue_ID |
+----------+--------------+-----------+------------+--------------+
| 1 | 1 | 1 | 1 | 1 |
| 2 | 1 | 1 | 1 | 1 |
| 3 | 4 | 1 | 4 | 4 |
| 4 | 5 | 5 | 5 | 5 |
| 5 | 6 | 5 | 5 | 6 |
| 6 | 7 | 5 | 5 | 7 |
| 7 | 8 | 5 | 5 | 8 |
| 8 | 9 | 5 | 5 | 9 |
+----------+--------------+-----------+------------+--------------+
Ich habe die Scripte angehängt.
Eine Abfrage der Daten, also das wieder einlesen habe ich noch nicht angefangen.
Auch wünschenswert ein Import aus alten log files und der alten db habe ich noch nix gemacht.
Guten Rutsch!
Es ist immer eine Abwegung zwischen Speicher HDD, Speicher RAM und CPU Usage. Je mehr joins erforderlich sind um Datensätze auszulesen, umso mehr I/O sind nötig. Insbesondere werden die Indexe (HDD Speicher) dadurch um ein vielfaches größer, da du dann indizierte Werte redundant vorhalten musst. Alles in separate Tabellen auszulagern halte ich nicht für glücklich, da die meisten FHEM eher auf Einplatinen PCs wie raspberry pi laufen haben. Ich nutze z.b. einen mit einer SSD. Logging auf einer SD Karte zu machen ist nicht so schlau - egal ob man logfiles oder logdb nutzt. Daraus folgt dann aber auch, dass HDD Speicher nicht das entscheidende sein kann, sondern nur Ram + CPU Auslastung.
Die Datenstruktur der history table ist sicherlich optimierbar. Die Felder Device, Type, Reading und Unit auszulagern wäre ggf. zu überlegen. In der history Tabelle bräuchte man dann nur noch ids als smallint (default) speichern, was dann jeder individuell auch noch auf tinyints reduzieren könnte, was insbesondere bei type/reading möglich sein dürfte. Die Kardinalität ist hier eher sehr gering. Jedenfalls bezweifle ich, dass es eine Notwendigkeit gibt, dass man dort tausende verschiedene Werte benötigt. Ob man diese Werte dann in jeweils eigene Tabellen auslagert oder eine einzelne Attribut Tabelle macht hängt davon ab, wie man die Daten verarbeiten/selektieren will. Auch hier muss man dann Aufwand/Nutzen abwiegen.
Ob die Spalte Event wirklich gebraucht wird, weiß ich nicht. Ich meine DS_Starter meinte mal, dass die nur aus historischen Gründen drin ist, weil das an einzelnen Stellen noch im Code wäre. Am wichtigsten sind jedenfalls timestamp, device, value. value nur noch als id zu speichern und dann über einen left join auszulesen halte ich aber für unperformant. Hinzu kommt, dass man hier 3x soviel datenvolumen hat wegen der dann notwendigen valueid (2x felder + index). Der einzige Vorteil wäre, dass die Tabelle dann statisch und nicht mehr flexible wäre, was die Datenselektion etwas beschleunigen könnte. Das kommt aber nur dann zum tragen, wenn der Index der History Tabelle nicht Hot Cached ist, also nicht mehr in den RAM passt. Durch die Änderung von Device und Reading von varchar zu int hin würde das aber bei den meisten 10+ jahre dauern, bis das der Fall ist und bis dahin dürfte wieder viel bessere Hardware zur Verfügung stehen?
Am Ende stellt sich die Frage, was man möchte. Einfach nur einen Ersatz für DBLog zu schreiben halte ich für vertane Zeit. Sicherlich könnte man dblog anders strukturieren, wenn man es heute nochmal von neuem entwickeln müsste. Aber es funktioniert und für mutmaßlich 95% der Nutzer reicht es doch vollkommen aus und der verbleibende Teil mit größeren Installationen hat im Zweifel auch genug Geld sich einfach bessere Hardware hinzustellen ::). Alternative DBs zu unterstützen halte ich auch für verschwendete Zeit. Die meisten nutzen ohnehin nur mysql und nur weil einzelne Nerds (nicht böse gemeint) meinen, eine andere DB wäre toller... Nunja, mysql ist nicht umsonst im Bereich der relationalen Datenbanken der Standard. Aus meiner Sicht gibt es jedenfalls keinen sachlichen Grund nicht mysql/mariadb zu nutzen. Bleibt also die Frage wer ein neu entwickeltes dblog wirklich braucht.
Ich fänds jedenfalls auch schöner, wenn man den speicherbedarf reduzieren könnte. Meiner Meinung nach würde es aber erstmal genügen spalten wie Event zu entfernen. Als weiteren Schritt wäre zu überlegen, ob man dblog fürs debugging (auch) nutzen will oder es "nur" für Plots verwenden möchte. Im letzteren Fall könnten Type, Reading und Unit auch entfernt werden.
Das bringt mich zumindest zum überlegen, ob es nicht vielleicht sinnvoller wäre neben der history table einfach noch eine weitere tabelle nur mit den spalten timestamp, device und value zu pflegen und hier über ein attribut je device zu bestimmen, ob ein Event nur in dieser, in beiden oder nur in history gespeichert werden soll. Soweit ich den Code überblicke, wäre sowas jedenfalls relativ einfach umzusetzen und würde für die meisten Fälle eine erhebliche Optimierung mit sich bringen. In der history table könnte man dann z.b. viel einfacher alte Werte löschen, weil man diese dann ja eigentlich nur noch fürs debugging bräuchte. So bliebe alles bisherige kompatibel und man könnte gezielt für plots eine optimierung vornehmen ohne viel Aufwand betreiben zu müssen. Der Aufwand für einen DBLog Nachfolger mit den hier angedachten Ideen ist ja sicher der Grund dafür, warum es immer noch nicht in Angriff genommen wurde - was absolut nachvollziehbar ist ;D