Hallo,
ich versuche mich gerade daran dbLog einzurichten um dann über kurz oder lang vom Filelog weg zu kommen.
MariaDB10 und phpMyAdmin läuft auf meiner SynologyNAS.
FHEM auf einem Raspberry Pi 3B+.
Die Datenbank inkl. Benutzer ist auf der NAS und dem Raspi eingerichtet und lässt sich auch abfragen:
Screenshot 2023-07-30 114232.png
Soweit so gut.
Nach dem
define logdb DbLog ./db.conf .*:.*
Erhalte ich im STATE aber nur Fehlermeldungen die für mich leider zu kryptisch sind.
Als erstes stand etwas von "history" failed o.ä.
Also habe ich daraufhin über phpMyAdmin 2 Tabellen angelegt current und history das sieht nun wie folgt aus:
Screenshot 2023-07-30 114851.png
Jetzt hat sich die Fehlermeldung im STATE geändert und ich erhalte folgendes:
Screenshot 2023-07-30 115029.png
Kann mir bitte jemand hier weiterhelfen?
Welche Informationen benötigt ihr noch für die Fehleranalyse?
Vielen Dank im Voraus.
Grüße
- Falsches Unterforum für Fragen zu DbLog
- wie um alles in der Welt hast Du die Tabellen angelegt? Du kannst doch nicht sämtliche Felder mit dem Type int anlegen.
Hast Du jemals die commandref zu DbLog gelesen? Es gibt in FHEM sogar fertige sql-Skripte zum korrekten Anlegen der benötigten Tabellen.
Hallo,
zu 1: Ich habe das bewusst als in das Anfängerforum, da ich mich als solchen zähle. Sorry!
zu 2: Ich habe die Tabellen nach bestem Wissen händisch in phpMyAdmin angelegt, wenn das Falsch ist, wie muss ich das richtig machen?
Ich habe mich an eine gefundene Anleitung gehalten und hänge nun eben wie oben beschrieben.
Ich habe auch absolut keine Ahnung wie ich die Tabellen mit einem Script anlegen kann.
Kannst du mir dabei behilflich sein?
Das wäre super.
Grüße
Ich bin das jetzt nochmal durchgegangen aber finde keinen Fehler.
Vorgegangen bin ich wie folgt:
Ich habe auf dem RPi mit FHEM den MySQL Client installiert:
sudo apt-get install mariadb-client libdbd-mysql libdbd-mysql-perl
Dann habe ich (hatte das eben als Betateilchen schrieb nicht auf dem Schirm....bin weit weg von einem ITler :-) ) das Skript genutzt aber zuvor kopiert:
sudo cp /opt/fhem/contrib/dblog/db_create_mysql.sql /opt/fhem/contrib/dblog/my_create_mysql.sql
und dann entsprechend
sudo nano /opt/fhem/contrib/dblog/my_create_mysql.sqlmit abgeändertem Passwort konfiguriert.
Danach dann mit:
sudo mysql -h "meineIP" -P 3306 -u root -p < /opt/fhem/contrib/dblog/my_create_mysql.sqldie Datenbank erstellt bzw. erstellen wollen.
Ich glaube hier liegt schon der Fehler.
Ich konnte zwar mit:
sudo mysql -h 10.10.0.245 -P 3306 -p -u fhemuser
show databases;
Die Datenbank anzeigen aber weder die Unterordner current und history noch der User wurde auf meiner Synology angelegt.
Ich bin dann eben zwischenzeitlich hin und habe den "fhemuser" und die Tabellen händisch angelegt.
Ich verstehe nicht, warum ich mit show databases zwar einen Ordner "Fhem" finden konnte, aber der Rest nicht angelegt bzw. auffindbar ist.
Wo kann/muss ich denn hier mit der Fehlersuche beginnen?
Danke im voraus.
Grüße
Das stimmt immer noch
Zitat von: betateilchen am 30 Juli 2023, 12:11:40...
Falsches Unterforum für Fragen zu DbLog
Bin da auch eher Datenbank-Novize, aber als Denkanstoß:
das Wiki kennst du auch ? => https://wiki.fhem.de/wiki/DbLog
Für mich sieht es im ersten Post bis "
Die Datenbank inkl. Benutzer ist auf der NAS und dem Raspi eingerichtet und lässt sich auch abfragen:" (großer Screenshot) eigentlich ganz gut aus. Die danach händisch angelegten Tabellen sind so auf jeden Fall verkehrt. Die angelegte Datenbank mit ihren Tabellen durch das SQL-Script zu überschreiben funktioniert vermutlich nicht.
Ich würde versuchen die händisch angelegeten Tabellen besser die Database "fhem" zu löschen (statt CREATE DATABASE `fhem` vielleicht ein DELETE) bevor ich das SQL-Script erneut ausführe. Die SQL Kommandos kannst du ja ggfs. im Client auch einzeln ausführen (der User existiert vermutlich auch schon):
CREATE DATABASE `fhem` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
CREATE USER 'fhemuser'@'%' IDENTIFIED BY 'fhempassword';
CREATE TABLE `fhem`.`history` (TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
CREATE TABLE `fhem`.`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 `fhem`.* TO 'fhemuser'@'%';
CREATE INDEX Search_Idx ON `fhem`.`history` (DEVICE, READING, TIMESTAMP) USING BTREE;oder eben
sudo mysql -h "meineIP" -P 3306 -u root -p < /opt/fhem/contrib/dblog/my_create_mysql.sql (IP = 10.10.0.245)
Im PHP-Admin kannst du dann schauen (nur gucken) ob die Datenbank und die beiden Tabellen (natürlich noch leer) da sind. Vor allem sind da keine Spalten vom Typ "int" (alles Text vom Typ varchar bzw. Timestamp). Oder wie im genannten Screenshot im Client abgefragt.
Dann geht es weiter mit der Einrichtung des DBLog-Devices.
Hallo,
danke für deine Antwort.
Nein, den Wiki-Eintrag habe ich noch nicht durchgearbeitet.
Hatte mich bisher nur Anhand der Anleitung und aus Teilen der Commandref bis zum jetzigen Stand gehangelt.
Die falschen Einstellung in den Tabellen habe ich zwar korrigiert aber das brachte leider auch keinen Erfolg.
Der Idee mit dem löschen und neu anlegen der Tabellen und User werde ich auf jeden Fall nochmal versuchen.
Aktuell scheint es ja tatsächlich daran zu hängen.
Habe aktuell auch keinen Zugriff auf mein Netzwerk und kann nichts versuchen.
Werde aber dann auch mal noch den Wiki-Eintrag zu DbLog anschauen.....vllt. finde ich dort auch meinen Stolperstein.
Grüße
PS: Ich kann m.W.n. das Unterforum nicht bearbeiten. Evtl. kann ein MOD ja meinen Thread verschieben.
Zitat von: Knallfrosch am 30 Juli 2023, 16:57:54PS: Ich kann m.W.n. das Unterforum nicht bearbeiten. Evtl. kann ein MOD ja meinen Thread verschieben.
Unten links oder rechts ist der Button
Edit
unten rechts unter Moderation / Thema verschieben
Hallo,
ich habe nun die Schritte zum Anlegen der Tabellen und des Users in der Datenbank durchgeführt.
Irgendwo hatte ich da gestern einen Wurm drin.
Jedenfalls hat es nun funktioniert, das der User und die Tabellenstruktur wie in dem Skript vorgesehen angelegt wurden.
Soweit so gut.
Auch das Device in FHEM existiert zum übertragen, aber nun hänge ich dort.
Nachdem ein paar Datensätze in der Datenbank gelandet sind hat Fhem gemeckert:
2023.07.31 08:42:44 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: Data too long for column 'VALUE' at row 1 [err was 1406 now 2000000000]
executing 274 generated 21 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3211.
Ich habe dann einfach versucht die "Zeichenlänge" von VALUE auf 128 zu ändern.
Danach kamen dann ein paar weitere Werte.
Nun feuert FHEM aber noch folgende Meldung raus:
2023.07.31 09:03:06 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 8566 generated 250 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3211.
2023.07.31 09:03:20 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 8747 generated 250 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3211.
2023.07.31 09:03:36 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 8826 generated 250 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3211.
2023.07.31 09:03:58 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 9064 generated 309 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3211.
Und hier bin ich mit meinem Latein am Ende.
Ich habe keine Idee warum diese Meldung kommt, geschweige denn, was ich dagegen machen kann.
Grüße
PS: In welches Unterforum soll ich denn meinen Thread hier verschieben?
Ich habe mal über die Suche geschaut, wo es die meisten Beiträge zu Problemen mit DbLog gibt und die finden sich quasi in allen Unterforen verteilt.
Im configCheck steht nun folgendes:
Available Drivers in your system
DBD::DBM, DBD::ExampleP, DBD::File, DBD::Gofer, DBD::Mem, DBD::Proxy, DBD::SQLite, DBD::Sponge, DBD::mysql
Result of version check
Used Perl version: 5.28.1
Used DBI (Database independent interface) version: 1.642
Used DBD (Database driver) version Undefined
Used DbLog version: 5.9.0
Your local DbLog module is up to date.
Rating:
Recommendation: Update of DbLog is not needed.
Result of configuration read check
Connection parameter store type: file
Connection parameter: Connection -> mysql:database=fhem;host=192.168.178.34;port=3306, User -> fhemuser1, Password -> read o.k.
Rating:
Result of connection check
Connection to database fhem successfully done.
The time required to establish the connection was 0.0102 seconds.
Rating:
Recommendation: settings o.k.
Result of collation check
Collation used by Client (connection): UTF8MB4_BIN
Collation used by DB fhem: UTF8MB4_BIN
Rating:
Recommendation: settings o.k.
Result of insert mode check
Insert mode of DbLog-device logdb is: Array
Rating:
Recommendation: settings o.k.
Result of plot generation method check
WARNING - at least one of your FHEMWEB devices has attribute 'plotfork = 1' not set.
WEB: plotfork=0 / plotEmbed=0 / longpollSVG=0
WEB_Home: plotfork=0 / plotEmbed=0 / longpollSVG=0
WEBhabridge: plotfork=0 / plotEmbed=0 / longpollSVG=0
WEBphone: plotfork=0 / plotEmbed=0 / longpollSVG=0
WEBtablet: plotfork=0 / plotEmbed=0 / longpollSVG=0
Rating:
Recommendation: You should set attribute 'plotfork = 1' in relevant devices. If this attribute is not set, blocking situations may occure when creating plots.
(Note: Your system must have sufficient memory to handle parallel running Perl processes.) See also global attribute blockingCallMax.
Result of table 'history' check
Column width set in table history: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 128, 'UNIT' = 32
Column width used by device logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Rating:
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).
Alternatively the field width used by logdb can be adjusted by setting attributes 'colEvent', 'colReading', 'colValue'. (pls. refer to commandref)
Result of table 'current' check
Column width set in table current: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 32, 'UNIT' = 32
Column width used by device logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Rating:
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).
Alternatively the field width used by logdb can be adjusted by setting attributes 'colEvent', 'colReading', 'colValue'. (pls. refer to commandref)
Result of check 'Search_Idx' availability
Index 'Search_Idx' exists and contains recommended fields 'DEVICE', 'TIMESTAMP', 'READING'.
Rating:
Recommendation: settings o.k.
Result of check 'Report_Idx' availability for DbRep-devices
No DbRep-device assigned to logdb is used. Hence an index for DbRep isn't needed.
Rating:
Recommendation: settings o.k
Meine Einstellung auf utf8 wurde als "Fehler" angezeigt und ich habe wie empfohlen auf utf8mb4 geändert.
Trotzdem erhalte ich nach wie vor die oben genannten Einträge im LOG:
2023.07.31 10:07:04 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 7397 generated 255 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3211.
2023.07.31 10:07:20 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 7466 generated 257 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3211.
2023.07.31 10:07:40 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 7614 generated 257 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3211.
2023.07.31 10:07:55 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 7792 generated 257 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3211.
2023.07.31 10:08:11 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 7831 generated 257 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3211.
Ich komme hier nicht mehr weiter.
Grüße
Zitat von: Knallfrosch am 31 Juli 2023, 09:14:45PS: In welches Unterforum soll ich denn meinen Thread hier verschieben?
Ich habe mal über die Suche geschaut, wo es die meisten Beiträge zu Problemen mit DbLog gibt und die finden sich quasi in allen Unterforen verteilt.
Mach mal in der FHEM-Kommandozeile "help dblog"
Gruß Ralf
Zitat von: Knallfrosch am 31 Juli 2023, 09:14:45Ich habe dann einfach versucht die "Zeichenlänge" von VALUE auf 128 zu ändern.
Danach kamen dann ein paar weitere Werte.
Im ConfigCheck werden u.a. noch zwei andere Spalten als zu kurz ausgewiesen:
Zitat von: Knallfrosch am 31 Juli 2023, 10:09:15Column width set in table history: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 128, 'UNIT' = 32
Column width used by device logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Ist 'DEVICE' = 32, 'TYPE' = 32
Soll 'DEVICE' = 64, 'TYPE' = 64
Edit
Betrifft auch 'READING' = 64
und beide Tabellen curent & history
wie es zu ändern ist steht ja auch dabei "You can change the column width in database by a statement like 'alter table history modify VALUE varchar(128);'
(example for changing field 'VALUE')."
Ich vermute ja immer noch ein Problem bei den verwendeten Datentypen.
Und es hilft der Lösungsfindung überhaupt nicht, die Diskussion jetzt auch noch in mehreren Threads parallel zu führen!
Vermutlich hast du recht.
Wenn die Kommandos
CREATE TABLE `fhem`.`history` (TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
CREATE TABLE `fhem`.`current` (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32))
korrekt gelaufen wären, dürfte der configCheck die Feldlängen nicht anmeckern. Im Create sind sie ja genau wie der Datentyp korrekt.
Danke, die Spaltenlänge habe ich angepasst, hatte mich zu sehr auf den LOG-Eintrag konzentriert und nur VALUE angepasst.
Nun sieht der ConfigCheck so aus:
Available Drivers in your system
DBD::DBM, DBD::ExampleP, DBD::File, DBD::Gofer, DBD::Mem, DBD::Proxy, DBD::SQLite, DBD::Sponge, DBD::mysql
Result of version check
Used Perl version: 5.28.1
Used DBI (Database independent interface) version: 1.642
Used DBD (Database driver) version mysql: 4.050
Used DbLog version: 5.9.0
Your local DbLog module is up to date.
Rating:
Recommendation: Update of DbLog is not needed.
Your DBD version fulfills UTF8 support, no need to update DBD.
Result of configuration read check
Connection parameter store type: file
Connection parameter: Connection -> mysql:database=fhem;host=192.168.178.34;port=3306, User -> fhemuser1, Password -> read o.k.
Rating:
Result of connection check
Connection to database fhem successfully done.
The time required to establish the connection was 0.0065 seconds.
Rating:
Recommendation: settings o.k.
Result of collation check
Collation used by Client (connection): UTF8MB4_BIN
Collation used by DB fhem: UTF8MB4_BIN
Rating:
Recommendation: settings o.k. Your DBD version fulfills UTF8 support, no need to update DBD.
Result of insert mode check
Insert mode of DbLog-device logdb is: Array
Rating:
Recommendation: settings o.k.
Result of plot generation method check
WARNING - at least one of your FHEMWEB devices has attribute 'plotfork = 1' not set.
WEB: plotfork=0 / plotEmbed=0 / longpollSVG=0
WEB_Home: plotfork=0 / plotEmbed=0 / longpollSVG=0
WEBhabridge: plotfork=0 / plotEmbed=0 / longpollSVG=0
WEBphone: plotfork=0 / plotEmbed=0 / longpollSVG=0
WEBtablet: plotfork=0 / plotEmbed=0 / longpollSVG=0
Rating:
Recommendation: You should set attribute 'plotfork = 1' in relevant devices. If this attribute is not set, blocking situations may occure when creating plots.
(Note: Your system must have sufficient memory to handle parallel running Perl processes.) See also global attribute blockingCallMax.
Result of table 'history' check
Column width set in table history: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by device logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Rating:
Recommendation: settings o.k.
Result of table 'current' check
Column width set in table current: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by device logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Rating:
Recommendation: settings o.k.
Result of check 'Search_Idx' availability
Index 'Search_Idx' exists and contains recommended fields 'DEVICE', 'TIMESTAMP', 'READING'.
Rating:
Recommendation: settings o.k.
Result of check 'Report_Idx' availability for DbRep-devices
No DbRep-device assigned to logdb is used. Hence an index for DbRep isn't needed.
Rating:
Recommendation: settings o.k
Die Feldlängen wurden ja autoamtisch mit dem Skript erstellt:
CREATE DATABASE `fhem` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
CREATE USER 'fhemuser'@'%' IDENTIFIED BY 'fhempassword';
CREATE TABLE `fhem`.`history` (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));
CREATE TABLE `fhem`.`current` (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));
GRANT SELECT, INSERT, DELETE, UPDATE ON `fhem`.* TO 'fhemuser'@'%';
CREATE INDEX Search_Idx ON `fhem`.`history` (DEVICE, READING, TIMESTAMP);
Das war die im Ordner abgelegte Datei: /opt/fhem/contrib/dblog/
Irgendwo habe ich zwischendurch gelesen, dass diese Datei nicht aktualisiert ist. Daher haben wohl auch die Spaltenbreiten nicht gepasst.
Aktuell läuft es ohne Fehlermeldungen im LOG.
Jedoch beobachte ich, dass scheinbar der Cache voll läuft.
In der Datenbank kommen kontinuierlich Daten an, aber lt. Datenbank sind es ca. 13.000 Einträge und im listChache ist die fortlaufende Nummer bei über 20.000 Einträgen.
Screenshot 2023-07-31 at 13-17-56 FHEM.png
Welche Angaben oder Screenshots wären noch sinnvoll für die Fehlersuche?
Irgendwie rutsche ich aktuell von Problem zu Problem.....kaum ist das der eine Fehler behoben taucht der nächste auf.
Grüße
So sieht es aktuell in phpMyAdmin aus:
Screenshot 2023-07-31 at 13-26-02 192.168.178.34 _ MariaDB 10 _ fhem _ history phpMyAdmin 5.2.1.png
Zitat von: Knallfrosch am 31 Juli 2023, 13:19:37Die Feldlängen wurden ja autoamtisch mit dem Skript erstellt:
CREATE DATABASE `fhem` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
CREATE USER 'fhemuser'@'%' IDENTIFIED BY 'fhempassword';
CREATE TABLE `fhem`.`history` (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));
CREATE TABLE `fhem`.`current` (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));
GRANT SELECT, INSERT, DELETE, UPDATE ON `fhem`.* TO 'fhemuser'@'%';
CREATE INDEX Search_Idx ON `fhem`.`history` (DEVICE, READING, TIMESTAMP);
Das war die im Ordner abgelegte Datei: /opt/fhem/contrib/dblog/
Irgendwo habe ich zwischendurch gelesen, dass diese Datei nicht aktualisiert ist.
Nur mal so zur Info: die aktuelle Datei
./contrib/dblog/db_create_mysql.sql
sieht so aus:
##################################################################################
# Note:
# =====
# The default installation of the MySQL/MariaDB database provides
# for the use of the utf8mb4_bin collation.
# With this setting characters up to 4 bytes long (e.g. emojis) can be stored.
#
# If the MySQL/MariaDB version used does not offer utf8mb4 for some reason, utf8
# can be used instead.
# In this case the MySQL/MariaDB database would be created with the
# following statement:
#
# CREATE DATABASE `fhem` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
#
# instead of the statement:
#
# CREATE DATABASE `fhem` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
#
# shown in the first line below.
#
##################################################################################
CREATE DATABASE `fhem` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
CREATE USER 'fhemuser'@'%' IDENTIFIED BY 'fhempassword';
CREATE TABLE `fhem`.`history` (TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
CREATE TABLE `fhem`.`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 `fhem`.* TO 'fhemuser'@'%';
CREATE INDEX Search_Idx ON `fhem`.`history` (DEVICE, READING, TIMESTAMP) USING BTREE;
und da sind die Werte korrekt.
Zitat von: Knallfrosch am 30 Juli 2023, 12:18:16Ich habe mich an eine gefundene Anleitung gehalten und hänge nun eben wie oben beschrieben.
Ich habe auch absolut keine Ahnung wie ich die Tabellen mit einem Script anlegen kann.
Keine Ahnung, nach welchem alten Kram Du da vorgegangen bist.
Fang doch einfach nochmal komplett von vorne an, nimm die in FHEM verfügbare Dokumentation (und nicht irgendwas aus dubiosen Dritt-Quellen) und dann wird es auch funktionieren.
Du bist schließlich nicht der erste Anwender, der sein Logging mit DbLog einrichten möchte.
Je nachdem wie gut du die Korrekturen in der Datenbankinstallation umgesetzt hast ist der Vorschlag von betateilchen nicht das Schlechteste
Zitat von: betateilchen am 31 Juli 2023, 15:09:19Fang doch einfach nochmal komplett von vorne an, nimm die in FHEM verfügbare Dokumentation (und nicht irgendwas aus dubiosen Dritt-Quellen) und dann wird es auch funktionieren.
Du bist schließlich nicht der erste Anwender, der sein Logging mit DbLog einrichten möchte.
Zitat von: Knallfrosch am 31 Juli 2023, 13:19:37Das war die im Ordner abgelegte Datei: /opt/fhem/contrib/dblog/
Irgendwo habe ich zwischendurch gelesen, dass diese Datei nicht aktualisiert ist. Daher haben wohl auch die Spaltenbreiten nicht gepasst.
Genau... allerdings stimmen die Feldlängen schon seit mindestens 5 Jahren. Deine lokale contrib ist seeehr alt.
Auch in der CommandRef/Hilfe ist ein Verweis/Link auf die aktuelle Version der SQL-Scripte.
Beispielcode bzw. Scripts zum Erstellen einer MySQL/PostgreSQL/SQLite Datenbank ist im SVN -> https://svn.fhem.de/trac/browser/trunk/fhem/contrib/dblog enthalten.
(Achtung: Die lokale FHEM-Installation enthält im Unterverzeichnis ./contrib/dblog nicht die aktuellsten Scripte!) Scheinbar wird da ziemlich viel in deine DB geloggt. Hast du das so umgesetzt?
Beispiel:
define myDbLog DbLog /etc/fhem/db.conf .*:.*
speichert alles in der Datenbank Besser fängst du etwas kleiner an und loggst erstmal nur ein Device "<Name>:.*" statt ".*:.*"
ZitatWelche Angaben oder Screenshots wären noch sinnvoll für die Fehlersuche?
Irgendwie rutsche ich aktuell von Problem zu Problem.....kaum ist das der eine Fehler behoben taucht der nächste auf.
Da hilft schon ein List des Logging-Devices.
Generell solltest du im Vorfeld mal überlegen was genau alles in die Datenbank soll. So wie es jetzt aussieht platzt die ja schon nach einem Tag.
Hallo,
ja, hätte ich das mit der aktuellen Datei nicht nur gelesen, sondern auch umgesetzt wäre mir einiges an Stress erspart geblieben. :-)
Lernen durch Schmerz oder so ähnlich.
Ja, meine Installation ist schon alt und daher war eben auch die Datei stark veraltet.
Nachdem ich nochmal alles durchgegangen bin, hat es dann gestern Abend auch funktioniert.
Die Daten werden auch komplett in die Datenbank geschrieben.
Es sind allerdings tatsächlich viel zu viele Daten.
Aktuell sind nach ca. 12h schon fast 240.000 Datensätze angefallen.
Hier muss ich nochmal sehr genau drüber schauen und die Datenflut reduzieren.
Danke für eure Hilfe.
Grüße
ZitatEs sind allerdings tatsächlich viel zu viele Daten.
Aktuell sind nach ca. 12h schon fast 240.000 Datensätze angefallen.
Hier muss ich nochmal sehr genau drüber schauen und die Datenflut reduzieren.
Ich habe das so gelöst. Für jedes Device sind 2 Attribute gesetzt.
attr Dev_Brauchwasser DbLogExclude .*
attr Dev_Brauchwasser DbLogInclude DS18B20-1_Temperature
Das erste schält das komlette loggen aus. Das zweite wählt dann aus was doch gelogt werden soll.
Mein Device im Beispiel heisst "Dev_Brauchwasser". Gelogt soll dann nur der Wert des Temperatursensors "DS18B20-1_Temperature" werden.
Damit das ganze funktioniert muss wohl auch das Attribut DbLogType in deinem DBlog-Device auf Current/History gesetzt werden.
attr Dev_DBLog DbLogType Current/HistoryFalls Du viele Devices hast kannst Du zumindest das eintragen von "DbLogExclude .*" in einem Rutsch erledigen (für das "wie" kann Dir hier sicher jemand helfen) Die Wahl der gewünschten Readings mus man wohl eher von Hand machen.
Ausserdem kann es ein Notify geben das die Eintragung für jedes neu angelegte Device automatisch macht.
Da ich mich selbst noch zu den "Anfängern" zähle "keine Gewähr" :)
Gruss Klaus
Hallo Klaus,
vielen Dank für diesen super Tipp!
Das klingt ziemlich vielversprechend.
Damit werde ich mich dann noch ausführlich beschäftigen um die benötigten Werte zu selektieren.
Grüße
Es gibt m.E. bessere und einfachere Wege, sowas festzulegen, als in jedem device entsprechende Attribute zu pflegen. Seit Jahren pflege ich das, was gelogged werden soll, im DEF des DbLog devices, dadurch habe ich nur eine einzige Stelle, an der ich ggf. Änderungen anpassen muss.
Hier ein Beispiel aus meiner Testinstallation, in der ich nur bestimmte devices (diese aber mit allen readings) logge:
defmod dbLog DbLog ./sqldb/dblog.conf (bme688_1|ub4|owo_Jork|yrno_Jork|Jork_Wetter|CUX_Wetter):.*
Das Ganze geht natürlich auch beliebig komplex:
defmod fhemDbLog DbLog ./conf/logDB.cfg (pidActor.*|pid.actuation:..|pid.measured:.*|pid.desired:.*|st_fl_PIR_Motion:.*|mqtt_erdgas:full.*|.*motion:.*|.*Super.*|.*lumi.*|.*measured.*|.*desired.*|.*level.*|.*temperature.*|.*humidity.*|.*pressure.*|out_Regen.*|owo.*)
Hier werden sowohl gelogged:
- bestimmte devices mit allen readings: out_Regen.*
- bestimmte readings aller devices: .*temperature.*
- ein bestimmtes reading aus einem bestimmten device: mqtt_erdgas:full.*
Hallo,
argh....jetzt hatte ich die Datenbank nochmal komplett gelöscht. In 24h waren es schon über 600.000 Einträge.
Ich habe zwar noch einiges an Platz auf der NAS, aber die Datenmenge macht natürlich keinen Sinn.
Ich habe nun mal alle Readings mit DBExclude eingeschlossen und nur ein einzelnes Reading mit DBInclude eingeschlossen.
Und siehe da.....es kommt nichts in der Datenbank an. :-(
Meine Fehlersuche brachte mich auf das Attr: DbLogSelectionMode dieses habe ich nun auf Include gesetzt....damit wird nun auch das definierte Reading in die Datenbank geschrieben.
Wie ich die Selektion der einzelnen Readings machen werde, muss ich mir nochmal überlegen.
Danke für das Zeigen der beiden Möglichkeiten.
Grüße
Hallo,
ich habe noch ein Problem!
Ich habe nun das Reading ENERGY_Power mit DbLogInclude mit der Datenbank verbunden.
Das Reading wird im 30s-Takt durch MQTT beschrieben.
Nun wollte ich das Reading zum reduzieren der Datenmenge nur alle 60sec. in die Datenbank schreiben.
Versucht habe ich
attr Solarertrag_2 DbLogInclude ENERGY_Power:60
trotzdem erfolgt alle 30sec ein Eintrag in der Datenbank.
Wie muss ich hier ansetzen, damit der Eintrag nur in der definierten Zeit übertragen wird?
Vielen Dank.
Grüße
event-min-interval und event-on-change-reading
Zitat von: Christian83 am 02 August 2023, 10:57:59event-min-interval und event-on-change-reading
Ok, Danke!
Ich hatte gehofft, ich könnte das mit einem attr erschlagen.
Grüße
Zitat von: Knallfrosch am 02 August 2023, 11:01:56Ich hatte gehofft, ich könnte das mit einem attr erschlagen.
Lt. CommandRef müsste das gehen:
DbLogInclude Regex[:MinInterval][:force],[Regex[:MinInterval][:force]], ...
Mit dem Attribut DbLogInclude werden die Readings definiert, die in der Datenbank gespeichert werden sollen.
Die Definition der zu speichernden Readings erfolgt über einen regulären Ausdruck und alle Readings, die mit dem regulären Ausdruck matchen, werden in der Datenbank gespeichert.
Der optionale Zusatz <MinInterval> gibt an, dass ein Wert dann gespeichert wird wenn mindestens <MinInterval> Sekunden seit der letzten Speicherung vergangen sind.
Unabhängig vom Ablauf des Intervalls wird das Reading gespeichert wenn sich der Wert des Readings verändert hat.
Mit dem optionalen Modifier "force" kann erzwungen werden das angegebene Intervall <MinInterval> einzuhalten auch wenn sich der Wert des Readings seit der letzten Speicherung verändert hat.
| Modifier | innerhalb Intervall | außerhalb Intervall |
| | Wert gleich | Wert geändert | |
|----------+--------------------+-----------------+---------------------|
| <none> | ignorieren | speichern | speichern |
| force | ignorieren | ignorieren | speichern |Mit dem Parameter force wird erst gespeichert wenn das hinter dem Doppelpunkt angegebene Intervall abgelaufen ist.
Zitat von: RalfRog am 02 August 2023, 11:23:04Zitat von: Knallfrosch am 02 August 2023, 11:01:56Ich hatte gehofft, ich könnte das mit einem attr erschlagen.
Lt. CommandRef müsste das gehen:
DbLogInclude Regex[:MinInterval][:force],[Regex[:MinInterval][:force]], ...
Mit dem Attribut DbLogInclude werden die Readings definiert, die in der Datenbank gespeichert werden sollen.
Die Definition der zu speichernden Readings erfolgt über einen regulären Ausdruck und alle Readings, die mit dem regulären Ausdruck matchen, werden in der Datenbank gespeichert.
Der optionale Zusatz <MinInterval> gibt an, dass ein Wert dann gespeichert wird wenn mindestens <MinInterval> Sekunden seit der letzten Speicherung vergangen sind.
Unabhängig vom Ablauf des Intervalls wird das Reading gespeichert wenn sich der Wert des Readings verändert hat.
Mit dem optionalen Modifier "force" kann erzwungen werden das angegebene Intervall <MinInterval> einzuhalten auch wenn sich der Wert des Readings seit der letzten Speicherung verändert hat.
| Modifier | innerhalb Intervall | außerhalb Intervall |
| | Wert gleich | Wert geändert | |
|----------+--------------------+-----------------+---------------------|
| <none> | ignorieren | speichern | speichern |
| force | ignorieren | ignorieren | speichern |
Mit dem Parameter force wird erst gespeichert wenn das hinter dem Doppelpunkt angegebene Intervall abgelaufen ist.
Oh das kannte ich gar nicht.
Aber dann scheint wichtig zu sein:
Das Attribut DbLogSelectionMode muss entsprechend gesetzt sein um DbLogInclude zu aktivieren.
Zitat von: Knallfrosch am 02 August 2023, 10:51:14...
Versucht habe ich
attr Solarertrag_2 DbLogInclude ENERGY_Power:60
trotzdem erfolgt alle 30sec ein Eintrag in der Datenbank.
Wie muss ich hier ansetzen, damit der Eintrag nur in der definierten Zeit übertragen wird?
...
Aufgrund #21/22 ist der DbLogSelectionMode wohl richtig gesetzt.
So:
attr Solarertrag_2 DbLogInclude ENERGY_Power:60:force
klappt es, wie ich mir das vorgestellt habe.
Danke.
Grüße
Hallo,
ich arbeite nun schon etwas mit dbLog und komme auch halbwegs damit klar.
Jedoch habe ich ein Problem mit der DB selbst.
Ich greife auf die DB mit phpmyadmin auf meiner Synology-NAS zu.
Dabei ist mir aufgefallen, dass seit einiger Zeit die Anzahl der Datensätze nicht mehr ansteigt.
Aktuell werden also neue Datensätze zwar eingetragen, aber damit eben die älteren Überschrieben.
Das wollte und will ich nicht.
Allerdings habe ich nirgends eine Einstellung für eine "Größenbegrenzung" gefunden.
Aktuell hat meine DB -805274- Datensätze
Screenshot 2023-09-10 at 10-40-27 192.168.178.34 _ MariaDB 10 _ fhem _ history phpMyAdmin 5.2.1.png
Wie schaffe ich es auch noch mehr Datensätze speichern zu können?
Ich habe in FHEM auch kein Attr. zum löschen von Daten o.ä. bewusst angelegt.
Es scheint also eine Default-Einstellung zu sein!?
Danke für eure Hilfe.
Grüße
Hallo,
niemand da, der mir helfen und erklären kann, warum meine DB nicht mehr weiter wächst, sondern die alten Einträge gelöscht werden?
Die DB-Größe von ca. 100MB ist doch nicht das maximum.
Aber ich finde nach wie vor keine einstellbare Grenze für die Größe oder Anzahl der Einträge. :-(
Wäre super, wenn mir das jemand erklären kann.
Grüße
Zitatniemand da, der mir helfen und erklären kann, warum meine DB nicht mehr weiter wächst, sondern die alten Einträge gelöscht werden?
Nein. ;)
DbLog löscht keine EInträge in der history Tabelle. Es wird auch nichts überschrieben.
Die current-Tabelle hat eine besondere Aufgabe. Hier werden Einträge durchaus überschrieben wenn Device/Reading identisch sind.
Wenn du von DB sprichst, müsste man genauer spezifizieren ob die history oder current Tabelle gemeint ist.
Möglicherweise hast du das Attr DbLogType=current gesetzt?
Hallo,
danke für deine Rückmeldung.
Nein das Attr habe ich nicht gesetzt.
Hier ein List meiner Log-Device:
Internals:
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION ./db.conf
DEF ./db.conf .*:.*
FD 6
FUUID 64c76571-f33f-a358-bd28-60d53fff9890affa
FVERSION 93_DbLog.pm:v5.9.0-s27617/2023-05-25
MODE asynchronous
MODEL MYSQL
NAME logdb
NR 2
NTFY_ORDER 50-logdb
PID 883
REGEXP .*:.*
SBP_PID 885
SBP_STATE running
STATE connected
TYPE DbLog
UTF8 1
dbconn mysql:database=fhem;host=192.168.178.34;port=3306
dbuser fhemuser1
eventCount 22587
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 512
OLDSTATE connected
PACKAGE main
READINGCOL 64
TC current
TH history
TYPECOL 64
UNITCOL 32
VALUECOL 128
VERSION 5.9.0
OLDREADINGS:
READINGS:
2023-09-14 19:20:55 CacheOverflowLastNum 0
2023-08-01 14:36:22 CacheOverflowLastState normal
2023-09-14 19:20:55 CacheUsage 7
2023-09-14 19:20:55 NextSync 2023-09-14 19:21:25 or when CacheUsage 500 is reached
2023-09-14 19:20:56 state connected
Attributes:
DbLogSelectionMode Include
DbLogType Current/History
asyncMode 1
group Logging
room System
useCharfilter 1
Ich rede von der history-Tabelle.
Aktuell habe ich nochmal in die Tabelle mit phpmyAdming geschaut und auf "optimiere Tabelle" geklickt.
Plötzlich sind aus den 805274 von vor ein paar Tagen, nun 895534 Einträge geworden.
Ok, scheinbar werden also doch Datensätze gespeichert.
Wenn ich mir die Tabelle "history" nach TIMESTAMP sortiert anschaue und aktualisiere, werden zyklisch die Datensätze in die DB geschrieben.
Allerdings erhöht sich der Zähler nicht.
OK, wenn ich dann erneut "Optimiere Tabelle" drücke, erhöht sich auch der Zähler.
Ich kämpfe also nun mit einem Anzeigefehler......gibt es dafür eine Lösung?
Das Optimieren der Tabelle dauert ca. 20sec., prinzipiell kein Problem, aber sollte das nicht auch Optimierung funktionieren?
Grüße
ZitatIch kämpfe also nun mit einem Anzeigefehler......gibt es dafür eine Lösung?
Das Optimieren der Tabelle dauert ca. 20sec., prinzipiell kein Problem, aber sollte das nicht auch Optimierung funktionieren?
Müsstest du die Frage nicht in einem phpmyAdmin-Forum stellen?
Wenn du Einträge in der Tabelle regelmäßig zählen willst, kannst du z.B. DbRep "set ... countEntries" nutzen.
Ja, sorry .... ich hatte FHEM in Verdacht. Hast natürlich Recht, dass es sich nun als anderes NICHT-FHEM-Problem darstellt.
War mir aber zu Beginn nicht offensichtlich, zumindest für mich nicht.
Sollte das Problem doch noch jemand kennen bzw. eine Lösung haben, würde ich mich über weitere Infos freuen.
DBrep, werde ich mir anschauen und einrichten.
Danke dir.
Grüße