93_DbLog - Umstellung Log-Funktion auf non-blocking

[DS_Starter]

Die DropDown-Listen auch ok bei dir ? Falls du die Current Tabelle einsetzt.

[stromer-12]

Felder sind da, musste erstmal wieder Current aktivieren.
Ich bearbeite die gplot-Dateien direkt.
Bei mir ist meistens sowieso ein Text-Feld und keine Dropdownfeld für device:reading da.

[DS_Starter]

ok, super .... dann checke ich oder Tobias heute Abend die neue Version ein.

[Xcoder]

Hallo DS_Starter

Die Fehlermeldung ist mit 2.8.6 nun leicht anders:

Code Auswählen Erweitern

2017.01.10 21:44:45 1: Including fhem.cfg
2017.01.10 21:44:45 0: Using EIB is deprecated. Please migrate to KNX soon. Module 10_EIB is not maintained any longer. If you still want to use the module EIB,
please set the attribute useEIB to 1 within the tul-device. Please keep in mind, that 10_KNX has a changed syntax regarding the definition, arguments and readings. Please refer to the commandref.
As well 10_EIB and 10_KNX are compatible to daemon eibd and knxd.
2017.01.10 21:44:45 2: eventTypes: loaded 1155 events from ./log/eventTypes.txt
2017.01.10 21:44:46 1: Including ./log/fhem.save
2017.01.10 21:44:46 0: Featurelevel: 5.7
2017.01.10 21:44:46 0: Server started with 449 defined entities (fhem.pl:12966/2017-01-05 perl:5.024001 os:linux user:fhem pid:29421)
2017.01.10 21:44:56 1: PERL WARNING: Argument "no" isn't numeric in numeric gt (>) at ./FHEM/23_LUXTRONIK2.pm line 1188.
2017.01.10 21:46:26 2: DbLog logdb_core -> Error: DBD::mysql::st execute_array failed: MySQL server has gone away [err was 2006 now 2000000000]
executing 13 generated 13 errors at ./FHEM/93_DbLog.pm line 946.

2017.01.10 21:46:26 1: PERL WARNING: rollback ineffective with AutoCommit enabled at ./FHEM/93_DbLog.pm line 1014.
2017.01.10 21:48:17 2: DbLog logdb_core -> Error: DBD::mysql::st execute_array failed: MySQL server has gone away [err was 2006 now 2000000000]
executing 2 generated 2 errors at ./FHEM/93_DbLog.pm line 946.

2017.01.10 21:48:31 2: DbLog logdb_core -> Error: DBD::mysql::st execute_array failed: MySQL server has gone away [err was 2006 now 2000000000]
executing 2 generated 2 errors at ./FHEM/93_DbLog.pm line 946.

2017.01.10 21:48:39 2: DbLog logdb_core -> Error: DBD::mysql::st execute_array failed: MySQL server has gone away [err was 2006 now 2000000000]
executing 2 generated 2 errors at ./FHEM/93_DbLog.pm line 946.

2017.01.10 21:48:41 2: DbLog logdb_core -> Error: DBD::mysql::st execute_array failed: MySQL server has gone away [err was 2006 now 2000000000]
executing 2 generated 2 errors at ./FHEM/93_DbLog.pm line 946.

Bis jetzt 21:55 aber keine neuen Meldungen. MySQL war auf jeden Fall verfügbar ich habe laufend in phpMyAdmin die current Tabelle betrachtet, und keine Ausfälle bemerkt. MySQL läuft lokal.

Gruss, Xcoder

[DS_Starter]

Hallo XCoder,

die Warnungen habe ich mit der V2.8.8 hier weiter oben auch eliminiert.
Verwende die bitte mal.
Ich gehe aber davon aus dass deine DB ganz normal logged ?

[Xcoder]

Richtig, alles wird geloggt.

Die AutoCommit-Meldung ist weg. Aber diese kommt immer noch:

Code Auswählen Erweitern

2017.01.10 23:53:30 2: DbLog logdb_core -> Error: DBD::mysql::st execute_array failed: MySQL server has gone away [err was 2006 now 2000000000]
executing 2 generated 2 errors at ./FHEM/93_DbLog.pm line 951.

Ich kann die Meldung fast zuverlässig erzwingen, wenn ich SVG Plots aus dem DbLog anzeigen lasse...

Ist aber nicht so tragisch. Das Problem mit DbLogExclude ist da schon eher störend.


Danke und Gruss, Xcoder

[DS_Starter]

Hallo Xcoder,

schau mal ob für dich diese Hinweise hier gültig sind:

http://piwik.org/faq/troubleshooting/faq_183/
http://stackoverflow.com/questions/7942154/mysql-error-2006-mysql-server-has-gone-away

Vielleicht hilft das.
Gute Nacht .

[JoeALLb]

Hallo Heiko,

vielen Dank nochmals, die Versionen laufen sehr flott und sind eine wirkliche Verbesserung!!!!

Diese Fehlermeldung ist sicherlich eine Spezialität meiner Installation.
Ich bekomme noch immer diese Einträge im state.

Code Auswählen Erweitern

DBD::mysql::st execute_array failed: executing 195 generated 3 errors at ./FHEM/93_DbLog.pm line 1221.
Ich bin mir sicher, dass diese im Zusammenhang mit Primary-Key Fehlern kommen, wenn gewisse Einträge nicht nicht in die DB geschrieben werden können,
weil sie dort bereits vorhanden sind. Da ich einen PK auf "Timestamp, device, reading" gelegt habe und manche Devices leider 2 Einträge zur selben Zeit
produzieren, kommt das manchmal vor.

Ist es dazu ausreichend, wenn ich in Zeile 921 und 1188 für einen Test

Code Auswählen Erweitern

INSERT INTO
durch

Code Auswählen Erweitern

INSERT IGNORE INTO
ersetze? Ich werde das jedenfalls für heute so testen!

schöne Grüße
Joe

[DS_Starter]

Morgen Joe,

Ja genau, das sollte so passen.
Wünsche dir einen schönen Tag. Bei mir ruft die Arbeit ...

Grüße Heiko

[Tedious]

Guten Morgen,

ich will das nicht noch mal alles quoten, daher der Verweis: https://forum.fhem.de/index.php/topic,64537.msg558617.html#msg558617

Jemand eine Idee was da los ist? Tante Google hat mich nicht wirklich weiter gebracht

[DS_Starter]

Die Datenlänge in DbLog für das Feld VALUE ist 64. Die Meldung liest sich so dass dies zu lang wäre für deine DB und spezielle Reading. Ist die Feldlänge für value in der DB auch auf 64 eingestellt ?

[Tedious]

Die Werte habe ich gestern hochgestellt, ja... Weil ich die Meldung so interpretiert hatte.

[JoeALLb]

Jemand eine Idee was da los ist? Tante Google hat mich nicht wirklich weiter gebracht

setz ein

Code Auswählen Erweitern

show COLUMNS  from history;
und wenn du auch die current-tabelle verwendest zusätzlich noch ein

Code Auswählen Erweitern

show COLUMNS  from current;

Als Ergebnis solltest Du etwas in der Form für beide Tabellen erhalten!

Code Auswählen Erweitern


Field Type Null Key Default Extra
TIMESTAMP datetime NO PRI 0000-00-00 00:00:00
DEVICE varchar(64) NO PRI
TYPE varchar(32) YES
EVENT varchar(512) YES
READING varchar(64) NO PRI
VALUE varchar(32) YES
UNIT varchar(32) YES


Was ist das Ergebnis davon?

Code Auswählen Erweitern

show variables  like 'STRICT_%';

[CoolTux]

setz ein

Code Auswählen Erweitern

show COLUMNS  from history;
und wenn du auch die current-tabelle verwendest zusätzlich noch ein

Code Auswählen Erweitern

show COLUMNS  from current;

Als Ergebnis solltest Du etwas in der Form für beide Tabellen erhalten!

Code Auswählen Erweitern


Field Type Null Key Default Extra
TIMESTAMP datetime NO PRI 0000-00-00 00:00:00
DEVICE varchar(64) NO PRI
TYPE varchar(32) YES
EVENT varchar(512) YES
READING varchar(64) NO PRI
VALUE varchar(32) YES
UNIT varchar(32) YES


Was ist das Ergebnis davon?

Code Auswählen Erweitern

show variables  like 'STRICT_%';

Wenn ich mich da mal zwischen drängeln darf. Bei mir sieht das nicht so aus wie bei Dir

Code Auswählen Erweitern


MariaDB [fhem]> show COLUMNS  from history;
+-----------+--------------+------+-----+-------------------+-----------------------------+
| Field     | Type         | Null | Key | Default           | Extra                       |
+-----------+--------------+------+-----+-------------------+-----------------------------+
| TIMESTAMP | timestamp    | NO   |     | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
| DEVICE    | varchar(32)  | YES  | MUL | NULL              |                             |
| TYPE      | varchar(32)  | YES  |     | NULL              |                             |
| EVENT     | varchar(512) | YES  |     | NULL              |                             |
| READING   | varchar(32)  | YES  |     | NULL              |                             |
| VALUE     | varchar(32)  | YES  |     | NULL              |                             |
| UNIT      | varchar(32)  | YES  |     | NULL              |                             |
+-----------+--------------+------+-----+-------------------+-----------------------------+
7 rows in set (0.00 sec)


Ne Idee was nun "besser" oder "schlechter" ist?

[JoeALLb]

32 war die alte Spaltenbreite und wurde nunmehr auf 64 angeboben, daher sind alle Überprüfungen des Moduls ebenfalls auf 64 angehoben!

Also bitte verbreitere die Tabellen!

@Heiko:
Ich würde tatsächlich vorschlagen, beim init des Moduls internals zu generieren mit den Spaltenbreiten aus der Tabelle!
Ich erwarte zukünftig mehrere solcher Fehlermeldungen, und dadurch würden wir diese direkt erkennen.
Wennd as Auslesen in das internal nicht klappt, kann der Wert ja immer noch die Default-Breite annehmen.

Optimaler (für Später) könnten wir im STATE oder einem anderen Reading noch eine Warnung ausgeben: "Achtung, die Spaltenbreite ist kleiner als empfohlen, dies kann zu Fehlern beim Loggen führen"