Hallo,
ich habe gerade versucht, auf LogDB umzustellen, aber gefühlt ist FHEM seit dem kräftig langsam geworden und was noch merkwürdiger ist, wenn ich den PHPAdmin aufrufe und die Tabellen aufmache, dann sieht das wie im Anhang aus... Was könnte denn da schief laufen ?
Grüße Christian
Hallo Christian,
solche Inhalte wie von dir gezeigt habe ich noch nie gesehen :o
Die mangelnde Performance kann viele Ursachen haben, aber viel wichtiger finde ich herauszubekommen wie diese Inhalte zustande kommen. Vllt. ist die Performance dann auch ok wenn das erledigt ist.
Gib mal ein paar Infos, also eine Ausgabe von "set ... configCheck", ein Logauszug mit verbose 5 des DbLog-Devices und ein paar Infos zu deiner Systemumgebung, d.h. auf welchem System läuft die DB, lokal oder remote, RAM-Größe, etc.
Grüße,
Heiko
Hallo Heiko,
danke für die schnelle Antwort. Ich habe den config Check durchgeführt und glaube ich habe das Performance-Problem schon ein wenig in den Griff bekommen, nachdem ich den Logmode auf Asynchron umgestellt habe.
Hier mal das Ergebnis vom Check:
Result of DbLog version check
Used DbLog version: 4.4.0.
A new DbLog version is available (creation time: 2019-09-03_07:45:03, size: 398080 bytes)
Recommendation: You should update FHEM to get the freshest DbLog version !
Result of configuration read check
Connection parameter store type: file
Connection parameter: Connection -> mysql:database=fhem;host=192.168.2.88;port=3306, User -> fhemuser, 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 './db.conf' to the right value.
Result of logmode check
Logmode of DbLog-device LOGDB is: synchronous
Recommendation: Switch LOGDB to the asynchronous logmode by setting the 'asyncMode' attribute. The advantage of this mode is to log events non-blocking.
There are attributes 'syncInterval' and 'cacheLimit' relevant for this working mode.
Please refer to commandref for further information about these attributes.
Result of plot generation method check
WARNING - at least one of your FHEMWEB devices have attribute "plotfork = 1" not set. This may cause blocking situations when creating plots.
WEB: plotfork=0
WEBphone: plotfork=0
WEBtablet: plotfork=0
Recommendation: You should set attribute "plotfork = 1" in relevant devices
Result of table 'history' check
Column width set in DB history: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 32, '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.
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 DB fhem.current: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 32, '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.
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'.
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.
Recommendation: settings o.k.
Ich habe inzwischen ein Update gemacht, die Feldgrößen angepasst, Forkplot gesetzt... hier der neue Check:
Result of DbLog version check
Used DbLog version: 4.5.0.
Your local DbLog module is up to date.
Recommendation: No update of DbLog is needed.
Result of configuration read check
Connection parameter store type: file
Connection parameter: Connection -> mysql:database=fhem;host=192.168.2.88;port=3306, User -> fhemuser, 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 './db.conf' to the right value.
Result of logmode check
Logmode of DbLog-device LOGDB is: asynchronous
Recommendation: settings o.k.
Result of plot generation method check
WARNING - at least one of your FHEMWEB devices have attribute "plotfork = 1" not set. This may cause blocking situations when creating plots.
WEB: plotfork=1
WEBphone: plotfork=0
WEBtablet: plotfork=0
Recommendation: You should set attribute "plotfork = 1" in relevant devices
Result of table 'history' check
Column width set in DB history: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by LOGDB: '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 fhem.current: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by LOGDB: '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
No DbRep-device assigned to LOGDB is used. Hence an index for DbRep isn't needed.
Recommendation: settings o.k.
Die Anzeige im PHPadmin ist immer noch kryptisch. Wenn ich die DB aber mit HeidiSQL öffne, sieht alles gut aus... Kann das an den Encoder-Einstellungen liegen und wie müsste der entsprechende Eintrag aussehen für die config ?
Der MySQL-Server läuft auf einem NAS326 von Zyxel.
Grüße
Christian
ZitatDie Anzeige im PHPadmin ist immer noch kryptisch. Wenn ich die DB aber mit HeidiSQL öffne, sieht alles gut aus... Kann das an den Encoder-Einstellungen liegen und wie müsste der entsprechende Eintrag aussehen für die config ?
Ja, genauso sehe ich das auch.
Entweder du stellst die DB bzw. Tabellen auf utf8 um oder du setzt utf8 => 0, in der db.config.
Das letztere ist vermutlich das schnellste/einfachste zunächst.
Die Performance können wir uns anschauen wenn du das attr showproctime setzt. Im synchronen Mode können Freezes auftreten wenn die DB zu langsam reagiert. Das sieht man dann auch mit dem gesetzten Attribut.
Grüße,
Heiko
Hallo Heiko,
danke für den schnellen Support, ich probier das heute abend mal aus. Aber seit das auf Asynchron steht, kann ich keine Verzögerung mehr festellen. :-)
Grüße Christian
ZitatAber seit das auf Asynchron steht, kann ich keine Verzögerung mehr festellen. :-)
Ja, das war eins der Ziele die mit dem asynchronen Modus erreicht werden sollten. :)
Grüße,
Heiko
EDIT:
ein Blick ins fhem log und schon ist das Problem zu sehen
2020.02.20 20:36:45.412 2: DbLog LogDB - DBI connect('database=fhem;host=192.168.178.40;port=3306','fhemuser',...) failed: Access denied for user 'fhemuser'@'raspberrypi.fritz.box' (using password: NO) at ./FHEM/93_DbLog.pm line 3042.
Nur warum ist es heute Nacht fuer ein device gelaufen? Sehr strange :-)
root@raspberrypi:/# mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1710
Server version: 5.5.60-0+deb7u1 (Debian)
Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
mysql> select User,Host from mysql.user;
+----------+-------------+
| User | Host |
+----------+-------------+
| fhemuser | % |
| root | 127.0.0.1 |
| root | ::1 |
| root | localhost |
| root | raspberrypi |
+----------+-------------+
5 rows in set (0.00 sec)
Das Passwort ist in der db.conf gesetzt, aber wo kommt dann die Meldung "(using password: NO)" her???
Ich denke mal, da ist das init.sql fuer die mysql DB wohl schief gelaufen, das schau ich mir dann besser morgen mal an.
Hallo zusammen,
ich habe nun auch eine LogDB eingerichtet und schon das erste problem :-)
Internals:
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION ./db.conf
DEF ./db.conf .*:.*
FUUID 5e4d5e9a-f33f-61a8-bb90-3667428c421fdc5d
FVERSION 93_DbLog.pm:v4.9.10-s21087/2020-01-31
MODE synchronous
MODEL MYSQL
NAME LogDB
NR 433
NTFY_ORDER 50-logdb
PID 4796
REGEXP .*:.*
STATE connected
TYPE DbLog
UTF8 1
dbconn mysql:database=fhem;host=192.168.178.40;port=3306
dbuser fhemuser
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 512
OLDSTATE connected
PACKAGE main
READINGCOL 64
TC current
TH history
TYPECOL 64
UNITCOL 32
VALUECOL 128
VERSION 4.9.10
READINGS:
2020-02-20 20:30:46 state connected
Attributes:
DbLogExclude .*
DbLogSelectionMode Exclude/Include
disable 0
room System
Dann habe ich bei allen devices DbLogExclude .* gesetzt, weil ich nur ausgewaehlte eintrage haben moechte.
Heute ist dann das DBLogInclude mit der Komma separierten Liste der readings dazu gekommen, leider passiert jetzt allerdings nichts :-(
Wo koennte ich nun das Zauberwort finden? Irgend etwas habe ich in der Doku wohl falsch gelesen.
Viele Gruesse
Christian
Das erste device waere dann das hier
attr PV_Anlage_1 DbLogExclude .*
attr PV_Anlage_1 DbLogInclude Act_state_of_charge,Actual_battery_charge_-minus_or_discharge_-plus_Power,Actual_battery_charge_usable_Power,Battery_temperature,Home_own_consumption_from_PV,Home_own_consumption_from_battery,Home_own_consumption_from_grid,Inverter_state,Power_DC1,Power_DC2,Power_DC3,Total_DC_Power,Total_DC_Power_Max,Total_PV_Power_reserve,Voltage_DC1,Voltage_DC2
Die readings, die ich loggen moechte habe ich zuvor mit FileLogConvert aus der Logdatei ausgelesen und noch etwas ausgeduennt.
Das filelog wird momentan noch weiter geschrieben.
In der Datenbank hatte ich bereits vor dem setzen von DbLogExclude einige Eintraege, die ich bereits wieder bereinigt habe. Gestern Nacht ist dann noch etwas durch gerutscht, was die Verbindung zur DB als aktiv zeigt.
ysql> connect fhem
Connection id: 1079
Current database: fhem
mysql> select * from current;
Empty set (0.00 sec)
mysql> select * from history;
+---------------------+-------------------+------+-----------------------+---------+-------+----------+
| TIMESTAMP | DEVICE | TYPE | EVENT | READING | VALUE | UNIT |
+---------------------+-------------------+------+-----------------------+---------+-------+----------+
| 2020-02-19 22:30:00 | Zirkulation_timer | AT | state: Next: 22:35:20 | state | Next | 22:35:20 |
| 2020-02-19 23:10:00 | Zirkulation_timer | AT | state: Next: 23:15:20 | state | Next | 23:15:20 |
+---------------------+-------------------+------+-----------------------+---------+-------+----------+
2 rows in set (0.00 sec)
mysql>
Hallo Christian,
zur Fehlersuche sicherstellen dass die zu loggenden Readings einen Event generieren und wenn das so ist mit verbose 4 bzw. 5 prüfen was DbLog mit diesen Events macht. Mit den Logmeldungen kommt man meist dahinter.
Grüße,
Heiko
Zitat von: DS_Starter am 21 Februar 2020, 00:00:33
zur Fehlersuche sicherstellen dass die zu loggenden Readings einen Event generieren und wenn das so ist mit verbose 4 bzw. 5 prüfen was DbLog mit diesen Events macht. Mit den Logmeldungen kommt man meist dahinter.
Moin, das ist gegeben, jedoch scheint etwas mit dem Login nicht zu stimmen. Ich habe nochmal ein init der DB gemacht und das login getestet.
CREATE DATABASE `fhem` DEFAULT CHARACTER SET = `utf8`;
CREATE USER 'fhemuser'@'%' IDENTIFIED BY 'geheim';
REVOKE CREATE ROUTINE, CREATE VIEW, CREATE USER, ALTER, SHOW VIEW, CREATE, ALTER ROUTINE, EVENT, SUPER, INSERT, RELOAD, SELECT, DELETE, FILE, SHOW DATABASES, TRIGGER, SHUTDOWN, REPLICATION CLIENT, GRANT OPTION, PROCESS, REFERENCES, UPDATE, DROP, REPLICATION SLAVE, EXECUTE, LOCK TABLES, CREATE TEMPORARY TABLES, INDEX ON *.* FROM 'fhemuser'@'%';
UPDATE mysql.user SET max_questions = 0, max_updates = 0, max_connections = 0 WHERE User = 'fhemuser' AND Host = '%';
GRANT CREATE ROUTINE, CREATE VIEW, ALTER, SHOW VIEW, CREATE, ALTER ROUTINE, EVENT, INSERT, SELECT, DELETE, TRIGGER, GRANT OPTION, REFERENCES, UPDATE, DROP, EXECUTE, LOCK TABLES, CREATE TEMPORARY TABLES, INDEX ON `fhem`.* TO 'fhemuser'@'%';
USE `fhem`;
CREATE TABLE history (
TIMESTAMP TIMESTAMP,
DEVICE varchar(64),
TYPE varchar(64),
EVENT varchar(512),
READING varchar(64),
VALUE varchar(255),
UNIT varchar(32),
KEY `IDX_HISTORY` (`DEVICE`,`READING`,`TIMESTAMP`,`VALUE`),
KEY `IDX_DEVICE` (`DEVICE`,`READING`),
KEY `IDX_REPORT` (`TIMESTAMP`,`READING`) USING BTREE
);
CREATE TABLE current (
TIMESTAMP TIMESTAMP,
DEVICE varchar(64),
TYPE varchar(64),
EVENT varchar(512),
READING varchar(64),
VALUE varchar(255),
UNIT varchar(32)
);
FLUSH PRIVILEGES;
###########################################################
fhem@raspberrypi:~$ ls -l db.conf
-rw-r----- 1 fhem dialout 2165 Feb 21 10:50 db.conf
fhem@raspberrypi:~$ cat db.conf
## for MySQL
####################################################################################
# # optional enable(1) / disable(0) UTF-8 support (at least V 4.042 is necessary)
%dbconfig= (
connection => "mysql:database=fhem;host=192.168.178.40;port=3306",
user => "fhemuser",
password => "geheim",
utf8 => 1
);
Login Test im docker container
root@raspberrypi:/# mysql -u fhemuser -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1827
Server version: 5.5.60-0+deb7u1 (Debian)
Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
mysql> use fhem
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+----------------+
| Tables_in_fhem |
+----------------+
| current |
| history |
+----------------+
2 rows in set (0.00 sec)
mysql>
Login Test vom fhem server
fhem@raspberrypi:~$ mysql -h 192.168.178.40 -u fhemuser -p
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MySQL connection id is 2914
Server version: 5.5.60-0+deb7u1 (Debian)
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MySQL [(none)]> use fhem
Database changed
MySQL [fhem]> show tables;
+----------------+
| Tables_in_fhem |
+----------------+
| current |
| history |
+----------------+
2 rows in set (0.001 sec)
MySQL [fhem]>
# oder auch mit allen details
fhem@raspberrypi:~$ mysql -h 192.168.178.40 --port 3306 --database fhem -u fhemuser -p
Enter password:
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MySQL connection id is 3012
Server version: 5.5.60-0+deb7u1 (Debian)
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
MySQL [fhem]> show tables;
+----------------+
| Tables_in_fhem |
+----------------+
| current |
| history |
+----------------+
2 rows in set (0.001 sec)
MySQL [fhem]>
Und trotzdem kommt diese Meldung vom logdb modul.
2020.02.21 10:51:50.795 4: DbLog LogDB -> ################################################################
2020.02.21 10:51:50.795 4: DbLog LogDB -> ### start of new Logcycle ###
2020.02.21 10:51:50.795 4: DbLog LogDB -> ################################################################
2020.02.21 10:51:50.795 4: DbLog LogDB -> number of events received: 1 for device: PV_Anlage_1
2020.02.21 10:51:50.795 4: DbLog LogDB -> check Device: PV_Anlage_1 , Event: Battery_state: NaN
2020.02.21 10:51:50.795 5: DbLog LogDB -> parsed Event: PV_Anlage_1 , Event: Battery_state: NaN
2020.02.21 10:51:50.795 5: DbLog LogDB -> DbLogExclude of "PV_Anlage_1": .*
2020.02.21 10:51:50.795 5: DbLog LogDB -> DbLogInclude of "PV_Anlage_1": Act_state_of_charge,Actual_battery_charge_-minus_or_discharge_-plus_Power,Actual_battery_charge_usable_Power,Battery_temperature,Home_own_consumption_from_PV,Home_own_consumption_from_battery,Home_own_consumption_from_grid,Inverter_state,Power_DC1,Power_DC2,Power_DC3,Total_DC_Power,Total_DC_Power_Max,Total_PV_Power_reserve,Voltage_DC1,Voltage_DC2
2020.02.21 10:51:52.339 3: DbLog LogDB - Creating Push-Handle to database mysql:database=fhem;host=192.168.178.40;port=3306 with user fhemuser
2020.02.21 10:51:52.343 2: DbLog LogDB - Error: DBI connect('database=fhem;host=192.168.178.40;port=3306','fhemuser',...) failed: Access denied for user 'fhemuser'@'raspberrypi.fritz.box' (using password: NO) at ./FHEM/93_DbLog.pm line 2975.
2020.02.21 10:51:52.344 4: DbLog LogDB - Trying to connect to database
2020.02.21 10:51:52.363 4: DbLog LogDB -> ################################################################
2020.02.21 10:51:52.364 4: DbLog LogDB -> ### start of new Logcycle ###
2020.02.21 10:51:52.364 4: DbLog LogDB -> ################################################################
2020.02.21 10:51:52.364 4: DbLog LogDB -> number of events received: 1 for device: LogDB
2020.02.21 10:51:52.364 4: DbLog LogDB -> check Device: LogDB , Event: state: DBI connect('database=fhem;host=192.168.178.40;port=3306','fhemuser',...) failed: Access denied for user 'fhemuser'@'raspberrypi.fritz.box' (using password: NO) at ./FHEM/93_DbLog.pm line 2975.
2020.02.21 10:51:52.365 5: DbLog LogDB -> parsed Event: LogDB , Event: state: DBI connect('database=fhem;host=192.168.178.40;port=3306','fhemuser',...) failed: Access denied for user 'fhemuser'@'raspberrypi.fritz.box' (using password: NO) at ./FHEM/93_DbLog.pm line 2975.
2020.02.21 10:51:52.365 5: DbLog LogDB -> DbLogExclude of "LogDB": .*
2020.02.21 10:51:52.371 4: DbLog LogDB - Waiting for database connection
2020.02.21 10:51:57.372 3: DbLog LogDB - Creating Push-Handle to database mysql:database=fhem;host=192.168.178.40;port=3306 with user fhemuser
2020.02.21 10:51:57.375 2: DbLog LogDB - Error: DBI connect('database=fhem;host=192.168.178.40;port=3306','fhemuser',...) failed: Access denied for user 'fhemuser'@'raspberrypi.fritz.box' (using password: NO) at ./FHEM/93_DbLog.pm line 2975.
2020.02.21 10:51:57.376 4: DbLog LogDB - Trying to connect to database
2020.02.21 10:51:57.377 4: DbLog LogDB - Waiting for database connection
2020.02.21 10:52:02.378 3: DbLog LogDB - Creating Push-Handle to database mysql:database=fhem;host=192.168.178.40;port=3306 with user fhemuser
2020.02.21 10:52:02.382 2: DbLog LogDB - Error: DBI connect('database=fhem;host=192.168.178.40;port=3306','fhemuser',...) failed: Access denied for user 'fhemuser'@'raspberrypi.fritz.box' (using password: NO) at ./FHEM/93_DbLog.pm line 2975.
2020.02.21 10:52:02.383 4: DbLog LogDB - Trying to connect to database
2020.02.21 10:52:02.384 4: DbLog LogDB - Waiting for database connection
2020.02.21 10:52:07.384 3: DbLog LogDB - Creating Push-Handle to database mysql:database=fhem;host=192.168.178.40;port=3306 with user fhemuser
2020.02.21 10:52:07.389 2: DbLog LogDB - Error: DBI connect('database=fhem;host=192.168.178.40;port=3306','fhemuser',...) failed: Access denied for user 'fhemuser'@'raspberrypi.fritz.box' (using password: NO) at ./FHEM/93_DbLog.pm line 2975.
Hast du für den User "fhemuser" den Zugang von jedem Host aus (%) mit einem Passwort versehen und gleichermaßen auch für "localhost" ?
Nur zur Sicherheit, weil ja explizit von mysql die Meldung zurück kommt "using password: NO".
Grüße,
Heiko
EDIT:
IT Technik ist schon echt irre :-) Ich habe heute wegen eines massiven WLAN Problems die Fritzbox neu aufgesetzt und aufgeraeumt. Dabei ist dann auch alles neu gestartet worden und jetzt geht's.
Der fhem Server mit den docker Containern ist jedoch nicht mit WLAN angebunden. Warum kann ich nicht erklaeren, aber die Datenbank fuellt sich mit den ersten Eintraegen. Danke fuer Euer
Haendchenhalten und Mitgefuehl.
Eine frage habe ich jetzt noch.
defmod LogDB DbLog ./db.conf .*:.*
attr LogDB DbLogExclude .*
attr LogDB DbLogSelectionMode Exclude/Include <<< ist das so richtig?
Die history Tabelle fuellt sich jetzt, jedoch nicht die current. Muss ich da jetzt noch "DbLogType Current/History" setzen, damit ich mit Diagrammen weiter machen kann?
Mir fehlen da Anwendungsfaelle fuer das Verstaendniss.
Ich denke, dann wird die current Tabelle immer wieder Ueberschrieben und nur der letzte Wert behalten, also ohne Timestamp, oder verstehe ich das falsch?
Zitat von: DS_Starter am 22 Februar 2020, 12:40:15
Hast du für den User "fhemuser" den Zugang von jedem Host aus (%) mit einem Passwort versehen und gleichermaßen auch für "localhost" ?
Nur zur Sicherheit, weil ja explizit von mysql die Meldung zurück kommt "using password: NO".
Im init.sql wird es mit % gesetzt, also fuer alle incl localhost
CREATE USER 'fhemuser'@'%' IDENTIFIED BY 'geheim';
Und der Test aus dem fhem container ueber das Netzwerk in den mysql Container sieht wie folgt aus
root@raspberrypi:/opt/fhem# su - fhem
fhem@raspberrypi:~$ mysql -h 192.168.178.40 --port 3306 --database fhem -u fhemuser -p
Enter password:
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.5.60-0+deb7u1 (Debian)
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
MySQL [fhem]> show tables;
+----------------+
| Tables_in_fhem |
+----------------+
| current |
| history |
+----------------+
2 rows in set (0.002 sec)
MySQL [fhem]>
Somit ist der Zugriff auf der fhem shell Ebene mit Passwort, zwischen den Containern erfolgreich gegeben.
Kann ich testen, ob logdb das Passwort richtig aus der db.conf gelesen hat und mit welchen Parametern die Verbindung aus dem Perl aufgebaut wird?
Was muesste ich dafuer im Modul testweise einfuegen? Mit verbose 5 sehe ich nicht, ob das Passwort verwendet wird. Das waere eventuell noch eine Logging Erweiterung fuer das Modul (z.B. Passwort Ja/Nein)
2020.02.21 10:51:52.339 3: DbLog LogDB - Creating Push-Handle to database mysql:database=fhem;host=192.168.178.40;port=3306 with user fhemuser <<<< ??? mit oder ohne Passwort ????
2020.02.21 10:51:52.343 2: DbLog LogDB - Error: DBI connect('database=fhem;host=192.168.178.40;port=3306','fhemuser',...) failed: Access denied for user 'fhemuser'@'raspberrypi.fritz.box' (using password: NO) at ./FHEM/93_DbLog.pm line 2975. <<<<< die Meldung sagt mir, dass es wohl ohne Passwort versucht wurde
Hallo Christian,
erstmal schön dass es nun funktioniert. :)
Bezüglich User/Passwort unterscheidet MySQL zwischen remote Zugriffen und localhost. D.h. wenn du ein User/Passwort mit "%" für alle remote hosts freigibst umfasst das _nicht_localhost. Das machst du explicit mit "localhost". Meines Wissens läuft dieser Zugriff über UNix Sockets anstatt Network wie bei remote hosts.
Ob das Passwort gelesen (und verwendet) wird, erfolgt mit dem configCheck. Falls es nicht ginge, kommt dort eine Fehlermitteilung.
Zitat<<< ist das so richtig?
Ja, ist es wenn du mit einem kombinierten Exclude/Include arbeiten möchtest, was ich so auch gelesen habe.
ZitatMuss ich da jetzt noch "DbLogType Current/History" setzen, damit ich mit Diagrammen weiter machen kann?
Ja und Nein. Du musst das Attribut so setzen wenn du Werte in der Current-Tabelle haben möchtest. Vorraussetzung für die SVG-Plots ist sie jedoch nicht. Alle Werte zur Darstellung kommen aus der history-Tabelle.
Die current wird nur gebraucht, wenn man im SVG-Editor eine Drop-Down Vorschlagsliste haben möchte.
Advanced User verzichten jedoch meist darauf, weil man mit eingeschalteter current in dem Editor keine eigenen Veränderungen per Regex vornehmen kann. In dem Fall ist nämlich keine frei editierbare Zeile vorhanden.
Das ist ein Unterschied zur Bedienung mit Filelog. Ich wollte es schonmal verbessern, bin bisher jedoch noch nicht dazu gekommen. Andere Dinge waren immer wichtiger. ;)
Grüße,
Heiko
Hallo Heiko,
vielen dank fuer die ausfuehrliche Erlaeuterung, ich werde nun stueckweise meine Altdaten importieren und selektiv die devices loggen.
Dann kommt der Schritt zu Grafana oder eventuell vorher eine Umstellung der SVGs.
Der configCheck ist uebrigens super.
Das koennte fuer mich auch wichtig werden. Danke fuer den rechtzeitigen Tipp :-)
Advanced User verzichten jedoch meist darauf, weil man mit eingeschalteter current in dem Editor keine eigenen Veränderungen per Regex vornehmen kann. In dem Fall ist nämlich keine frei editierbare Zeile vorhanden.
Viele Gruesse
Christian
Gerne :)
Lass die current lieber immer aus wenn du eigene Regex im Editor und damit im gplot-File verwendest. Sonst kannst du dir die zerschießen wenn du mit eingeschalteter current im Editor hantierst und speicherst. Dann sind die Regex weg ... also Obacht ;)
Hi,
ich habe nun die benoetigten Logfiles importiert und es laeuft soweit alles gut.
Mit configCheck habe ich den Hinweis auf den Index bereits befolgt.
Nun habe ich noch kein Gefuehr fuer die select Abfrage, ob es schnell oder langsam ist...
MySQL [fhem]> CREATE INDEX Search_Idx ON `history` (DEVICE, READING, TIMESTAMP) USING BTREE; <<< das war schon vor dem Load aktiv
MySQL [fhem]> OPTIMIZE TABLE history; <<< das lief ca 11 Minuten, nachdem ich alles in die Datenbank geladen hatte
MySQL [fhem]> SELECT table_schema "DB Name", Round(Sum(data_length + index_length) / 1024 / 1024, 1) "DB Size in MB" FROM information_schema.tables GROUP BY table_schema;
+--------------------+---------------+
| DB Name | DB Size in MB |
+--------------------+---------------+
| fhem | 1194.9 |
| information_schema | 0.0 |
+--------------------+---------------+
MySQL [fhem]> select * from history where DEVICE = 'PV_Anlage_1' and TIMESTAMP like "2020-02-25%";
2956 rows in set (1 min 2.408 sec)
3372 rows in set (56.203 sec)
3441 rows in set (55.778 sec)
Das ganze laeuft auf einem RPI4 mit 4GB Ram in Docker Containern.
Tasks: 179 total, 2 running, 177 sleeping, 0 stopped, 0 zombie
%Cpu(s): 30,3 us, 8,9 sy, 0,0 ni, 60,8 id, 0,1 wa, 0,0 hi, 0,0 si, 0,0 st
MiB Mem : 3906,0 total, 246,6 free, 1090,7 used, 2568,7 buff/cache
MiB Swap: 100,0 total, 44,5 free, 55,5 used. 2435,1 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1125 mysql 20 0 328100 163216 4608 S 117,9 4,1 133:47.30 mysqld
6404 fhem 20 0 207360 149184 14084 S 4,3 3,7 355:27.39 perl
1025 root 20 0 799872 7984 3680 S 1,7 0,2 17:47.92 containerd-shim
987 fhem 20 0 96932 52976 4272 S 1,0 1,3 0:14.19 perl
1134 root 20 0 7620 2460 2232 S 1,0 0,1 52:21.33 entry.sh
461 root 20 0 984672 28132 11680 S 0,7 0,7 7:36.76 containerd
15317 fhem 20 0 10324 2928 2532 R 0,7 0,1 0:00.12 top
@ Heiko
Wurdest Du Dich zu einer Bauchgefuehlaussage hinreissen lassen?
Gibt es eine Sammlung der Besten mysql Skripte? z.B.
- Alle Werte eines Devices am Montag um 8:00 Uhr oder den naechsten, der nahe 8:00 Uhr liegt?
- Bildung von Tages, Wochen und Monatswerten
- Liste aller Devices (habe ich schon)
- ...
Viele Gruesse
Christian
Hallo Christian,
sehr schön, dass du alles geschafft hast. :)
Die Geschwindigkeit der SQL-Abfrage ist nicht besonders gut. Das liegt aber nicht an deiner DB, sondern daran, dass ein select mit einer Like-Statement und wildcard deutlich langsamer ist als "=".
Also wenn es geht, besser auf Like mit "%" verzichten und das Statement so wählen, dass die DB den Index nutzen kann.
Manchmal gehts aber auch nicht anders.
Setz dir im DbLog das Attr showproctime=1. Dann siehst du Readings
sql_processing_time. Die geben dir ein Gefühl wie schnell deine Db schreibt. Sollte im 0,x Sekundenbereich liegen.
Damit du die DB von FHEM entkoppelst, kannst du auf asynchron umschalten (asyncMode=1) und das Attr bulkInsert=1 kann dir nochmal einen Schub geben wenn du ohne current-Tabelle arbeitest.
Zitat
Gibt es eine Sammlung der Besten mysql Skripte? z.B.
- Alle Werte eines Devices am Montag um 8:00 Uhr oder den naechsten, der nahe 8:00 Uhr liegt?
- Bildung von Tages, Wochen und Monatswerten
- Liste aller Devices (habe ich schon)
- ...
Eine Sammlung als solche gibt es m.W. nicht, aber vieles davon kannst du mit DbRep erledigen.
Z.B. ist die Bildung von Tages, Wochen und Monatswerten als Funktionalität eingebaut.
Ebenso kannst du Werte eines Device/Readings zu einem bestimmten Zeipunkt oder dem nächstgelegenen zu diesem Zeitpunkt liegenden Datenwert liefern lassen. -> Stichwort
dbReadingsValSobald du ein DbRep-Device definiert hast, gibt es dbReadingsVal. Einfach mal help eingeben oder in die commandref von DbRep reinschauen. Ist gleich zu Beginn beschrieben.
Daneben gibt es im DbRep ein paar vorgefertigte SQL unter
set ... sqlSpecial, z.B.:
50mostFreqLogsLast2days : ermittelt die 50 am häufigsten vorkommenden Loggingeinträge der letzten 2 Tage
allDevCount : alle in der Datenbank vorkommenden Devices und deren Anzahl
allDevReadCount : alle in der Datenbank vorkommenden Device/Reading-Kombinationen und deren Anzahl
Dort stelle ich allgemein interssierende Auswertungen zur Verfügung. Diese Sammlung kann ich gerne erweitern wenn etwas konkretes benötigt wird.
Ansonsten gibt es DbRep im Wiki: https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten
Das wäre auch ein guter Platz um SQL's gesammelt zusammenzutragen.
Grüße,
Heiko
Hallo Heiko,
vielen Dank für die vielen Tipps, ich arbeite mich da natürlich noch durch. Die Wünsche sind schneller als die Umsetzung DbRep stand schon auf der Liste.
Zitat von: DS_Starter am 25 Februar 2020, 22:15:37
Die Geschwindigkeit der SQL-Abfrage ist nicht besonders gut. Das liegt aber nicht an deiner DB, sondern daran, dass ein select mit einer Like-Statement und wildcard deutlich langsamer ist als "=".
Also wenn es geht, besser auf Like mit "%" verzichten und das Statement so wählen, dass die DB den Index nutzen kann.
Manchmal gehts aber auch nicht anders.
Okay, optimiert wäre es dann so, es sieht jedoch etwas unbeholfen aus ;-)
select * from history where DEVICE = 'PV_Anlage_1' and TIMESTAMP like "2020-02-25%";
9590 rows in set (51.956 sec)
MySQL [fhem]> select * from history where DEVICE = 'PV_Anlage_1' and TIMESTAMP > "2020-02-25_00:00:00" and TIMESTAMP < "2020-02-26_00:00:00";
9590 rows in set (0.184 sec)
Aber das Ergebnis spricht für sich :-)
0.184 sec. ... Das sieht freundlich aus :D
Besser unbeholfen und schnell als schick und schneckenlangsam ;)
Zitat von: DS_Starter am 26 Februar 2020, 15:08:29
0.184 sec. ... Das sieht freundlich aus :D
Besser unbeholfen und schnell als schick und schneckenlangsam ;)
Mein O...le Kollege hat es mir nochmal erklärt:
- die Spalte TIMESTAMP ist vom Type timestamp
- bei der Suche mit LIKE und % wird der Type string verwendet und kann intern nicht auf den Type timestamp gewandelt werden.
- somit wird TIMESTAMP auf Type string gewandelt und dann mit dem Wildecard verglichen
- Bei der zweiten Suche wird der Vergleichsstring einmal in den Type timestamp gewandelt
- anschließend kann die Suche dann über den INDEX erfolgen, wo die Werte in der Spalte TIMESTAMP bereits sortiert vorliegen
Viele Grüße
Christian
Jepp, zum Thema Datenbanken , Performance und SQL Gestaltung gibt es endlos viel Material im Netz. Da kann man sich sehr damit beschäftigen. Manchmal streiten sich auch die Experten ;)
Vielleicht hat dein O...le Kollege noch ein paar schöne SQL auf Lager die man in DbRep als sqlSpecial einbauen könnte falls Bedarf besteht.
Zitat von: DS_Starter am 26 Februar 2020, 15:56:49
Vielleicht hat dein O...le Kollege noch ein paar schöne SQL auf Lager die man in DbRep als sqlSpecial einbauen könnte falls Bedarf besteht.
Ich schau mir erst mal an, was drin ist und scheue mich nicht optimieren zu lassen oder zu erweitern :-)
Du hast ja jetzt noch einen Kontakt zum Riesen.
OK ... Thema optimieren ... nicht vergessen alle SQL müssen auch unter SQLite und PostgreSQL laufen ! :)
Riesen ??
Zitat von: DS_Starter am 26 Februar 2020, 16:19:07
Riesen ??
O...le , die mit der Datenbank ;-)
Zitat
OK ... Thema optimieren ... nicht vergessen alle SQL müssen auch unter SQLite und PostgreSQL laufen !
Gut, dass schränkt dann wiederum ein.
ZitatO...le , die mit der Datenbank ;-)
Man muss es nur richtig lesen. :)
Ja, manchmal baue ich die SQL auch DB spezifisch ins Modul ein. Das mache ich aber davon abhängig wie viel Programmieraufwand es für mich bedeutet. Wenn es zu aufwändig wird oder der Aufwand nicht im Verhältnis zum Nutzen steht akzeptiere ich eher einen Kompromiss. Ein paar Millisekunden mehr oder weniger sind in unserem Umfeld dann doch nicht so ausschlaggebend.
Vielleicht jetzt etwas OT ... kennst du den Thread zu DbRep ?
https://forum.fhem.de/index.php/topic,53584.msg452567.html#msg452567
Dort kannst du allgemeine Dinge zum Modul kommunizieren, z.B. bezüglich SQL. Möglicherweise ist dein Kollege auch mit FHEM aktiv ...
Zitat von: DS_Starter am 26 Februar 2020, 17:16:54
Vielleicht jetzt etwas OT ... kennst du den Thread zu DbRep ?
https://forum.fhem.de/index.php/topic,53584.msg452567.html#msg452567
Dort kannst du allgemeine Dinge zum Modul kommunizieren, z.B. bezüglich SQL. Möglicherweise ist dein Kollege auch mit FHEM aktiv ...
Ist er nicht, aber ich werde da sicher auch auftauchen.
DbRep läuft schon und ich arbeite mich durch die wiki Doku....
Vielen, vielen Dank, Du hast mir den Einstieg sehr vereinfacht.
Christian
Ich bin z.Z. dabei eine "etwas" ältere FHEM Instanz umzuziehen. DB_Log hat die ID (15517 2017-11-28 20:22:56Z) und läuft mit DbLogType Current/History. Mein Problem nun : die neue Version hat in Current und History die gleichen Daten, bei der alten stand in Current nur der zuletzt übertragene Wert eines Readings , wie der Name eigentlich schon sagt : Current.
Gibt es eine Chance das die neuere Version auch wieder so arbeitet oder muß ich die alte DBLog Version mit rüber nehmen ?
Hallo Wzut,
das Updateverhalten hat sich schon lange nicht geändert. Auch in der aktuellen Version stehen in der current Tabelle immer die letzten bzw. aktuellsten Werte einer spezifischen Device/Reading Kombination.
Ich habe es gerade bei mir nochmal kontrolliert und ist auch so.
Habe es auf meiner MariaDB gecheckt. Würde mich jetzt wundern wenn es auf einem anderen Typ nicht so wäre.
Gib mal noch ein paar Infos zu deiner.
Hi,
ich hatte zwar nur kurz current/history aktive, aber da waren nur wirklich die letzten readings zu sehen.
Soll ich das nochmal aktivieren, um es zu testen?
Gesendet von meinem SM-G930F mit Tapatalk
:) ... mach mal Christian. Bei mir ist es so wie du es auch bestätigt hast.
schei... DbLog ist unschuldig :) irgend ein Depp hat in der current den Primary Key auf Device,Reading und Timestamp gesetzt .....
Kaum macht man es richtig geht es auch, sorry
Hallo zusammen,
mein postgresql server liegt auf einer anderen Maschine.
Sollte der Datenbankserver gewartet werden, kann logdb natürlich nicht mehr in die DB schreiben und loggt ins Fhemlog eine Unmenge an Verbindungsfehlern.
Kann man iwie verhindern bzw. logdb mundtod machen, falls die Datenbank mal nicht da ist?
Viele Grüße und danke schon mal für die Antwort.
Da gibt es verschiedene Möglichkeiten.
1. du betreibst DbLog mit verbose 1. Kann man machen, würde ich aber nicht, sondern mit verbose 2
2. Im Normalfall wird bekannt sein wann der DB-Server gewartet wird. Für diese Zeit, mit etwas Sicherheitszuschlag vorher und nachher, kann man DbLog von der DB trennen mit:
set <name> reopen <Zeit in Sekunden>
Solltest du dein DbLog im asynchronen Modus betreiben, werden die in dieser Zeit auflaufenden Events im RAM gecached und sobald die DB wieder verfügbar (und die reopen Zeit abgelaufen) ist, in die DB geschrieben.
vielen Dank