Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)

Begonnen von DS_Starter, 19 Mai 2016, 22:52:13

Vorheriges Thema - Nächstes Thema

Frank_Huber

Denke die Frage ist jetzt eher wie die ungültigen Daten geloggt wurden und was genau falsch ist.

Geloggt wurde ja vom dblog Modul.

Gesendet von meinem Doogee S60 mit Tapatalk


DS_Starter

ZitatDenke die Frage ist jetzt eher wie die ungültigen Daten geloggt wurden und was genau falsch ist.

Geloggt wurde ja vom dblog Modul.
Gute Frage, ich sehe bei "Verzögerung ein paar Sätze zu nicht existierenden Zeiten geschrieben wurden, es geht nur um ein paar Sekunden (02:00:08)" -> 02:00:08 auch keinen unzulässigen Timestamp.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

kadettilac89

Fehler war durch den Timestamp der in die Stunde der Sommerzeitumstellung hineinragte. Da gibt MySql eine Warnung " Warning: #1299 Ungültiger TIMESTAMP-Wert in Feld 'TIMESTAMP', Zeile 1" aus


INSERT INTO `history` (`TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `VALUE`, `UNIT`) VALUES ('2015-03-29 02:00:09', 'Wetter_Nuernberg', 'WEATHER', 'humidity: 86', 'humidity', '86', '%');


Ich habe nun 35 Werte mit ähnlichem Aussehen der Jahre 2014 - 2017 gelöscht. Nun kann ich es vollständig laufen lassen.

2018 und 2019 habe ich keine Fehler gefunden.

Zitat von: DS_Starter am 30 Mai 2019, 08:56:08
Wenn du Verbesserungen siehst, lass es mich gerne wissen.

Meinst du damit ob ich Verbesserungsvorschläge habe? .... ja :)

Vorweg, es ist aktuell nur eine Spielerei und vielleicht den Aufwand gar nicht wert. Ich kann mir das auch selber programmieren.

Folgender Anwendungsfall: Jemand, wie ich, möchte seine Standby Datenbank so aktuell wie möglich halten, der Server auf dem die Standby läuft ist aber nicht immer. Hintergrund, mein NAS läuft nur wenn ich zu Hause bin.

Ich möchte nicht jedesmal einen Fullload machen sondern mit Deltascheiben arbeiten. Jede Stunde, Tag, Woche einmal, sollte erstmal keinen Unterschied machen.

Hier 2 Wünsche.
- Der "von - bis" Zeitraum als Parameter oder irgendwie dynamisch. Aktuell ist es ein Attribut. Dann muss ich immer Speichern wenn ich per Script was ändere. Wenn dynamisch könnte ich aus dem Reading das Datum extrahieren und dann als Start-Datum verwenden.

- Wenn ich einen Lauf erneut starte weil der erste fehlerhaft war, wird ja wieder mit insert gearbeitet. Dazu würde ich ggf. einen unique-index anlegen. Dann gäbe es beim Einfügen aber einen Fehler der das Script auch wieder abbrechen würde. Der Fehler sollte aber die Bearbeitung nicht abbrechen ... ich weiß nicht, ob du irgendwo angeben kannst welche Fehler ignoriert werden sollen. Ich glaube der duplicate ist Fehler #1062 in MySql.
--> Alternative hierzu ... ein Modify Modus, erst lesen ob Sätze schon da sind, wenn ja, UPdate sonst Insert. Mir ist bewusst, dass es die Laufzeit erhöhen würde.


Frank_Huber

Könnte man die standby DB nicht als zweite DB anlegen?
Fhem würde dann das bulk Update machen sobald die Db erreichbar ist und cachen wenn sie offline ist.

Gesendet von meinem Doogee S60 mit Tapatalk


DS_Starter

Zitat- Wenn ich einen Lauf erneut starte weil der erste fehlerhaft war, wird ja wieder mit insert gearbeitet. Dazu würde ich ggf. einen unique-index anlegen. Dann gäbe es beim Einfügen aber einen Fehler der das Script auch wieder abbrechen würde.
Du kannst einen Primary Index anlegen. Dieser wird berücksichtigt und es bricht nichts ab. Doppelte DS werden vermieden.

Zitat- Der "von - bis" Zeitraum als Parameter oder irgendwie dynamisch. Aktuell ist es ein Attribut. Dann muss ich immer Speichern wenn ich per Script was ändere. Wenn dynamisch könnte ich aus dem Reading das Datum extrahieren und dann als Start-Datum verwenden.
Bislang kannst du z.B. mit timeDiffToNow = d:1 arbeiten, also beginne immer mit einem Tag in der Vergangenheit. Das ist dynamisch. Vllt. reicht das schon.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

@Frank,

ZitatKönnte man die standby DB nicht als zweite DB anlegen?
Fhem würde dann das bulk Update machen sobald die Db erreichbar ist und cachen wenn sie offline ist.
Im Prinzip ja. Allerdings war der asynchrone Mode ursprünglich nicht dazu gedacht einen Tag lang oder länger die Events im Cache zu halten (Fehlerfall ausgenommen). Mir ging es damals nur um Minuten und dabei dir DB von FHEM zu entkoppeln.
Nachteil wäre falls FHEM abstürzt der Verlust der ganzen Events.

LG,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

kadettilac89

Zitat von: DS_Starter am 30 Mai 2019, 13:47:16
Du kannst einen Primary Index anlegen. Dieser wird berücksichtigt und es bricht nichts ab. Doppelte DS werden vermieden.
Ich dachte wenn schon eine Warnung wegen Timestamp das Script stoppt dann erst recht ein Doppelter Eintrag. Damit ist Punkt ein erledigt.


Zitat von: DS_Starter am 30 Mai 2019, 13:47:16
Bislang kannst du z.B. mit timeDiffToNow = d:1 arbeiten, also beginne immer mit einem Tag in der Vergangenheit. Das ist dynamisch. Vllt. reicht das schon.
Ich sag mal, damit kann ich  leben. Ich lege mir 2 DbRep-Devices mit unterschiedlichen Werten an. Du könntest die Doku etwas erweitern, du schreibst


Die zur Steuerung der syncStandby Funktion relevanten Attribute sind:

aggregation : Einstellung der Zeitscheiben zur Übertragung (hour,day,week)
device : einschließen oder ausschließen von Datensätzen die <device> enthalten
reading : einschließen oder ausschließen von Datensätzen die <reading> enthalten
time.* : Attribute zur Zeitabgrenzung der zu übertragenden Datensätze.
valueFilter : ein zusätzliches REGEXP um die Datenselektion zu steuern. Der REGEXP wird auf das Datenbankfeld 'VALUE' angewendet.


Ich dachte die anderen Attribute werden hier nicht herangezogen da sie nicht gelistet waren. Das Modul ist sehr mächtig, hat viele Attribute und Funktionen. Vielleicht ist es besser eine 2-dim-Tabelle zu machen mit einem Kreuzchen welche Attribute wo verwendet werden. Wäre sicher auch für dich einfacher zu pflegen wenn du ein Attribut einführst oder eine Änderung machst.

Danke dir.

kadettilac89

Zitat von: DS_Starter am 30 Mai 2019, 14:50:43
Nachteil wäre falls FHEM abstürzt der Verlust der ganzen Events.
bei mir wäre das sogar im Normalbetrieb so. Bin zum Teil die ganze Woche, ggf. sogar länger beruflich weg. Meine Updates Docker und OS mache ich automatisiert. Da wird auch mal Fhem einfach runtergefahren.

DS_Starter

Zitatch dachte die anderen Attribute werden hier nicht herangezogen da sie nicht gelistet waren. Das Modul ist sehr mächtig, hat viele Attribute und Funktionen. Vielleicht ist es besser eine 2-dim-Tabelle zu machen mit einem Kreuzchen welche Attribute wo verwendet werden. Wäre sicher auch für dich einfacher zu pflegen wenn du ein Attribut einführst oder eine Änderung machst.
Oh ja danke dir. Ich checke das. Manchmal vergesse ich auch mal was .  ;)
Die Idee mit der Tabelle ist nicht schlecht. Das probiere ich aus wie das zu pflegen ist.

Zitatbei mir wäre das sogar im Normalbetrieb so. Bin zum Teil die ganze Woche, ggf. sogar länger beruflich weg. Meine Updates Docker und OS mache ich automatisiert. Da wird auch mal Fhem einfach runtergefahren.
Einfach runterfahren tut nichts, da wird alles weggeschrieben. Mir ging es um einen harten Absturz.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Frank_Huber



Zitat von: DS_Starter am 30 Mai 2019, 15:05:49
Einfach runterfahren tut nichts, da wird alles weggeschrieben. Mir ging es um einen harten Absturz.
Könnte dieses wegschreiben dann nicht evtl zyklisch alle 5min gemacht werden?
Damit wäre eine Backup DB recht einfach anzulegen ohne viel Pflege und syncaufwand.
Je nachdem wieviel neues kommt ist das syncen ja nicht unerheblich.
Noch dazu wäre es ein live Backup. [emoji16]

Gesendet von meinem Doogee S60 mit Tapatalk


kadettilac89

Zitat von: DS_Starter am 30 Mai 2019, 15:05:49
Einfach runterfahren tut nichts, da wird alles weggeschrieben. Mir ging es um einen harten Absturz.
Ich meinte die Aussage - Synology ist als Standby DB down da ich nicht zu Hause bin. Gleichzeitig würde Fhem geplant wegen Update restartet. Dann würde ich Sätze verlieren.

Normales runterfahren bei verbundener DB ist kein Problem, das hätte ich schon festgestellt.

Frank_Huber

Ist die Frage wie Heiko dieses "wegschreiben" gemeint hat.
Wegschreiben in die DB,
Oder wegschreiben in ein Temp file.

Im ersten Fall wären die Einträge weg.

Gesendet von meinem Doogee S60 mit Tapatalk


kadettilac89

Zitat von: Frank_Huber am 30 Mai 2019, 15:21:05
Ist die Frage wie Heiko dieses "wegschreiben" gemeint hat.
Wegschreiben in die DB,
Oder wegschreiben in ein Temp file.

Im ersten Fall wären die Einträge weg.

Gesendet von meinem Doogee S60 mit Tapatalk
beides ginge ... :)

wegschreiben in DB läuft in regelmäßigen Abständen ... Sinn und Zweck des Caches
wegschreiben in Temp-File geht mit "set <name> exportCache" bzw. dem entsprechenden import-Statement. Man könnte sich da sicherlich was basteln aber dafür ist es eigentlich nicht gebaut.

DS_Starter

@kadettilac89, habe die commandRef bzgl. Attribute zu syncStandby ergänzt. Sollte ich noch etwas vergessen haben oder du noch weitere Infos dort hilfreich platziert sehen würdest, sag Bitte Bescheid.

LG,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

kadettilac89

Zitat von: DS_Starter am 31 Mai 2019, 11:08:20
@kadettilac89, habe die commandRef bzgl. Attribute zu syncStandby ergänzt. Sollte ich noch etwas vergessen haben oder du noch weitere Infos dort hilfreich platziert sehen würdest, sag Bitte Bescheid.

danke dir. Ich muss zugeben, dass ich jetzt erst die Doku den "relevanten Attributen" verstanden. "time.*" ist kein einzelnes Attribut sondern ein Platzhalter und beinhaltet z. B. timeDiffToNow. Vielleicht setzt du das Wort "mehrere" vorndran. Aber will nicht rumjammern, ich habs jetzt verstanden.


mehrere time*-Attribute: