SVG-Plot - irgendeine Beschränkung, die ich nicht kenne?

[wowogiengen]

Hallo,
ich habe meine SVG-Plots umgestellt von FileLog¹⁾ auf DB-Log (zunächst SqLite auf dem raspi²⁾, und dann mySQL auf der Diskstation³⁾).

Problem mit ¹⁾ war, dass das sehr langsam war, zum Teil, weil ich viel zu viel geloggt habe.
Bei ²⁾ habe ich nicht weniger geloggt, aber der Zugriff auf die DB war besser als auf die Dateien.
Bei ³⁾ habe ich jetzt erstmal wieder das gleiche geloggt, die Geschwindigkeit für die SVG-Plots ist hier akzeptabel. Die alten Daten von Anfang des Jahres  habe ich mit einem eigenen C#-Programm aus den Logfiles extrahiert und nur die Devices und Readings in die mySQL-DB eingetragen.

Es fehlen aber definitiv Datenpunkte bei der Anzeige im SVG-Plot.
Z.B. habe ich für Mai bei meiner Wunschtemperatur im Büro nur Punkte vom 01.05 bis ca. 13.05. Danach sehe ich keine Punkte mehr bis 01.06.

Habe dann mal alle DB-Tabellen geleert und nur den Zeitraum vom 13.05. bis 31.05. in die DB eintragen lassen. Da seh ich dann die Punkte.

Jetzt versuche ich aktuell gleiche aufeinanderfolgende Events nicht zu importieren, so dass weniger Zeilen in der DB entstehen.
Das müsste man aber doch auch über das Log-Device hinbekommen?

Viele Grüße
Wolfgang

[DS_Starter]

Hallo Wolfgang,

Jetzt versuche ich aktuell gleiche aufeinanderfolgende Events nicht zu importieren, so dass weniger Zeilen in der DB entstehen.
Das müsste man aber doch auch über das Log-Device hinbekommen?

Wenn du mit "gleiche aufeinanderfolgende Events" Duplikate meinst, also Datensätze mit identischem Timestamp, Device und Reading, kannst du die Arbeit die Datenbank machen lassen indem du der history Tabellle einen primary Key gibst.

Code Auswählen Erweitern


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);


Das erste Statement brauchst du nur falls es schon Duplikate in der Tabelle gibt.

Meinst du aber gleiche aufeinanderfolgende Events mit unterschiedlichem Timestamp, aber ansonsten gleichen Werten, kannst du die Bereinigung mit einem DbRep "set <> delSeqDoublets delete" vornehmen.
Es gibt auch noch Interval-Parameter für die Attribute DbLogInclude und DbLogExclude mit denen du Einfluß auf das Logging nehmen kannst.

Weiterhin gibt es die Variablen  $LASTTIMESTAMP und $LASTVALUE bzw. $IGNORE für die Attributen DbLogValueFn / valueFn mit denen man sich eigene Bedingungen programmieren kann.

-> commandRef.

Grüße,
Heiko

[wowogiengen]

Hallo DS_Starter,
irgendwie vergesse ich immer mich benachrichtigen zu lassen, wenn auf meine Beiträge geantwortet wird.

Aber egal, jetzt bin ich da.

Mein Probleme haben sich inzwischen fast erledigt.
- Ich  habe Zeilen, die sich nur im Timestamp unterscheiden, erfolgreich nicht in die DB importiert
- Es wurden jetzt auch alle Zeilen importiert, ohne dass was zu fehlen scheint (lag an meinem C#-Code)

Was mir jetzt noch fehlt:
- Ein/mehrere Readings für Stunden- / Tage-/ Wochen-  und Monatsmittel für die measured-temp der Sensoren.

Habe das mal mit Hilfe phpMyAdmin erzeugt, aber kann das wohl nicht im SVG-Plot auswählen, weil es nicht in der Current-Tabelle enthalten ist...

Aber dbRep müsste das ja hergeben?
Ich schaus mir nachher oder morgen mal an, und schreibe, was ich gefunden habe.

Kann man die SVG-Plots eigentlich auch so tweaken, dass die auf eine andere Tabelle gehen?
Die DB bleibt die selbe, aber die Tabelle ist nicht current und history, sondern vlt. currentTest und historyTest...

Viele Grüße
Wolfgang

[DS_Starter]

Hallo Wolfgang,

mit DbRep kriegst das bestimmt hin. Wenn es keine eingebaute Funktion tut, dann kannst du dir ein individuelles Statement mit sqlCmd ausführen lassen.

Kann man die SVG-Plots eigentlich auch so tweaken, dass die auf eine andere Tabelle gehen?
Die DB bleibt die selbe, aber die Tabelle ist nicht current und history, sondern vlt. currentTest und historyTest...

Zur Zeit nicht, geht alles gegen die history Tabelle. Möglich wäre es natürlich, wobei die Gefahr besteht dass User die sich nicht so intensiv mit der Materie beschäftigen die SVG Definition auf Current belassen (default aus Filelog) und sich dann wundern wenn nichts geht. Deswegen gibt es zur Zeit eine Fehlermeldung wenn man bei SVG nicht HISTORY angibt.

LG,
Heiko

[wowogiengen]

Hallo,
seit ich den primary key eingefügt habe, scheint FHEM keine gescheite Verbindung mehr zur Datenbank zu bekommen...

Code Auswählen Erweitern

DBD::mysql::st execute failed: MySQL server has gone away at ./FHEM/93_DbLog.pm line 2456.
Habe auch einen configcheck laufen lassen.

Code Auswählen Erweitern

Result of version check

Used Perl version: 5.20.2
Used DBI (Database independent interface) version: 1.631
Used DBD (Database driver) version mysql: 4.028
Used DbLog version: 4.10.0.
Your local DbLog module is up to date.
Recommendation: No update of DbLog is needed. Caution: Your DBD version doesn't support UTF8.

Result of configuration read check

Connection parameter store type: configDB (don't forget upload configuration file if changed. Use "configdb filelist" and look for your configuration file.)
Connection parameter: Connection -> mysql:database=fhem;host=ds2;port=3307, User -> fhemdbuser, Password -> read o.k.

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 './mySQLDB.conf' to the right value. Caution: Your DBD version doesn't support UTF8. If you want use UTF8 database option, you must update DBD (Database driver) to at least version 4.032.

Result of logmode check

Logmode of DbLog-device mySQLDB is: asynchronous
Recommendation: settings o.k.

Result of insert mode check

Insert mode of DbLog-device mySQLDB is: Bulk
Recommendation: settings o.k.

Result of plot generation method check

WEB: plotfork=1 / plotEmbed=2
WEB1: plotfork=1 / plotEmbed=2

Recommendation: settings o.k.

Result of table 'history' check

Column width set in DB history: 'DEVICE' = 128, 'TYPE' = 128, 'EVENT' = 512, 'READING' = 128, 'VALUE' = 128, 'UNIT' = 128
Column width used by mySQLDB: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: settings o.k.

Result of table 'current' check

Column width set in DB current: 'DEVICE' = 128, 'TYPE' = 128, 'EVENT' = 512, 'READING' = 128, 'VALUE' = 128, 'UNIT' = 128
Column width used by mySQLDB: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: settings o.k.

Result of check 'Search_Idx' availability

Index 'Search_Idx' exists and contains recommended fields 'DEVICE', 'TIMESTAMP', 'READING'.
Recommendation: settings o.k.

Result of check 'Report_Idx' availability for DbRep-devices

At least one DbRep-device assigned to mySQLDB is used. Index 'Report_Idx' exists and contains recommended fields 'TIMESTAMP', 'READING'.
Recommendation: settings o.k.

Da steht ja Used DBD (Database driver) version mysql: 4.028
und
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 './mySQLDB.conf' to the right value. Caution: Your DBD version doesn't support UTF8. If you want use UTF8 database option, you must update DBD (Database driver) to at least version 4.032.


Ich weiß nicht, wie ich den DBD auf Version 4.032 updaten soll. Und wieso auf einmal LATIN1 vs UTF8 eine Rolle spielt, das war früher nicht so.

Daten, welche von letzter Woche sind, sind offensichtlich in der Datenbank enthalten, da wird auch ein Plot angezeigt.
Der Cache scheint auch immer wieder geschrieben zu werden.
Ein Reopen der Verbindung geht auch ohne Probleme.
Ich dreh mal das logging auf, vielleicht sieht man da was... (kann es aber erst heute abend von zu Hause aus abrufen).

Viele Grüße
Wolfgang

[DS_Starter]

Hallo Wolfgang,

die utf8 Sache betrifft nur Umlaute. Wenn es bei dir nicht geht dann ist es so. Ist nur eine Empfehlung.

Der MySQL Fehler hat mit dem Parameter max_allowed_packet in mysql zu tun. Siehe auch https://praxistipps.chip.de/error-mysql-server-has-gone-away-so-beheben-sie-die-fehlermeldung_105684

Wenn der Cache sich nicht leert, kann das der Grund dafür sein wenn  die eingestellte Paketgröße überschritten wird.
Im Cache hat sich ein DS festgesetzt der nicht in die DB will.

Sichere dir zunächst den Cache mit exportCache nopurge. Evtl. mehrfach ausführen.
Setz dir dann im DbLog das Attribut commitMode auf basic_ta:off.

Hilft das dann schon ?
Wenn nicht, muss man den Cache mit exportCache purgeCache exportieren. Eventuell mehrfach ausführen. Die Daten kann man später importieren damit man sie nicht verliert.

Grüße,
Heiko

[wowogiengen]

Hallo DS_Starter,
aus dem Kopf raus kann ich glaube ich sagen, dass der Wert von max_allowed_packet bei mir in der MariaDB schon extrem hoch eingestellt ist. Das sollte es also nicht sein.

Werde mir heute abend mal den Cache exportieren (wobei der immer nur ein paar Dutzend Einträge hat), und ansehen...

Viele Grüße
Wolfgang

[wowogiengen]

Werde mir heute abend mal den Cache exportieren (wobei der immer nur ein paar Dutzend Einträge hat), und ansehen...
Viele Grüße
Wolfgang

Hallo,
jetzt ist was komisches passiert.
Im fhem hat er angezeigt, dass einige tausend cache einträge vorhanden sein sollen.
Beim exportieren sind aber gerade mal 2 Stück exportiert worden.
Hab dann das Cache-Limit und die sync-Zeit hochgenommen, dass nichts automatisch geschrieben wird.
Jetzt stehen ein paar Einträge mehr in der exportierten Cache-Datei.

Aber in phpMyAdmin kann ich sehen, dass seit Freitag nichts mehr eingetragen wurde.
Habe jetzt mal alle Daten aus der DB-Tabelle history gesichert und die history-Tabelle mit dem Skript neu angelegt.
Kann aber offensichtlich immer noch nichts in die DB schreiben...


Viele Grüße
Wolfgang

[DS_Starter]

Das ist ein Zeitthema, die  Daten sind abwechselnd im Cache oder im Blockingcall beim Versuch in die DB zu schreiben.
Wenn du set ... reopen 3600 ausführst, sollten sich alle Daten im Cache sammeln und du kannst exportieren.

Irgendein DS gefällt der DB nicht... muss man dann später versuchen zu identifizieren beim import. erstmal cach leeren damit alles wieder normal läuft. Der PK ist da jedenfals schuldlos. 

[wowogiengen]

Das ist ein Zeitthema, die  Daten sind abwechselnd im Cache oder im Blockingcall beim Versuch in die DB zu schreiben.
Wenn du set ... reopen 3600 ausführst, sollten sich alle Daten im Cache sammeln und du kannst exportieren.

Irgendein DS gefällt der DB nicht... muss man dann später versuchen zu identifizieren beim import. erstmal cach leeren damit alles wieder normal läuft. Der PK ist da jedenfals schuldlos. 

Ja, soweit scheint es jetzt wieder zu gehen.

Den Cache und die DB habe ich komplett geleert. Jetzt passt das wieder.

Was ist sinnvoller? Aus meinen auch noch vorhandenen Logs die Daten mit Hilfe von C# in die DB zu schreiben, oder eine Cache-Datei zu erstellen, welche die Daten enthält, die wieder in die DB sollen?

Ersteres würde an meinem PC und der diskstation ablaufen, zweiteres auf dem raspberry/fhem und der diskstation...

Viele Grüße
Wolfgang

[DS_Starter]

Ich würde über den Cache gehen. Dauert vllt. länger, aber möglicherweise bekommt man eher heraus welcher DS gestört hat und kann Massnahmen ergreifen um das zukünftig zu vermeiden.

Wäre ein Ansatz 

[wowogiengen]

Hallo,
wenn es jetzt einen Datensatz gibt, der aus welchem Grund auch immer, dazu geführt hat, dass der commit auf die DB länger als die 30 Sekunden dauert, wie bekomme ich den dann heraus?
Eigentlich müsste es ja der DS sein, welcher als erstes nicht mehr in der DB ist, aber noch in den Logs zu finden ist...

Und wie ist das mit dem Perl-Update für das DBD::mySQL-Modul? Wie kriege ich das auf die neueste Version?

Viele Grüße
Wolfgang

[DS_Starter]

Hallo Wolfgang,

setze attr commitMode wie in #5 geschrieben, dann sollte nur der problematische DS im Cache bleiben.
Das DBD hängt mW. beim PI am Betriebssystem bzw. Perl Release.

Gruß,
Heiko