Hallo zusammen,
ich habe ein Problem mit dem DBLog. Bisher habe ich DBLog schon in mehreren FHEM-Instanzen genutzt und hatte nie derartige Probleme.
Es scheint mir, als ob das Modul die db.conf nicht ausliest. Ich bekomme allerdings folgenden Fehler:
2018.03.05 17:21:15 3: DbLog logdb - Creating Push-Handle to database with user
2018.03.05 17:21:15 2: DbLog logdb - Error: Can't connect to data source 'dbi:' because I can't work out what driver to use (it doesn't seem to contain a 'dbi:driver:' prefix and the DBI_DRIVER env var is not set) at ./FHEM/93_DbLog.pm line 2310.
Wie man in der Meldung sieht, wird gar kein Datenbankname und User eingetragen.
Ich habe die db.conf in den Ordner /opt/fhem/ abgelegt. Besitzer und Gruppe sind "fhem:dialout". Mit den Berechtigungen habe ich schon bishin zu chmod 777 getestet.
Die Angabe im Modul lautet:
./db.conf .*:.*
Dort habe ich auch schon mit dem absoluten Pfad getestet, leider auch ohne Erfolg.
Hat jemand von euch noch eine Idee, wo der Fehler liegen könnte?
Gruß,
Patrick
und was steht in der db.conf drin?
ich geh mal Popcorn holen...
::)
Da habe ich wohl mal wieder einen wichtigen Teil vergessen :-[
#
# database configuration file
#
#
## for MySQL
################################################################
%dbconfig= (
connection => "mysql:database=srvfhem01_1_logdb;host=10.0.0.3;port=3306",
user => "fhemuser",
password => "***",
);
Die db.conf habe ich aus einer meiner anderen FHEM-instanzen, danach habe ich den servernamen angepasst. Die Struktur in der DB ist auch angelegt.
Wie man sehen kann, habe ich einen MySql Server, der auch von der Instanz erreichbar ist (mysql per shell funktioniert).
Ich vermute aber, dass das Problem schon vorher besteht. Ich kann zum Beispiel als Datei irgendeine nicht existierende Datei angeben, was den gleichen Fehler bringt. :o
Geh mal so vor wie hier beschrieben:
https://forum.fhem.de/index.php/topic,84712.msg770247.html#msg770247
Ergebnisse bitte posten.
Also ich habe die Anweisungen befolgt. Da ich ja erfolgreich die configDB verbunden habe, glaube ich wie gesagt nicht daran, dass es an der DB-Verbindung liegt. Ich hatte auch nochmal die configdb.conf mit der db.conf verglichen.
Wenn ich ein checkConfig ausführe, kommt folgendes (die html-codes werden dabei mit dargestellt)
<html><u><b>Result of DbLog version check</u></b><br><br>Used DbLog version: 3.8.6 <br><b>Recommendation:</b> Your running version may be the current one. Please check for updates of DbLog periodically. <br><br><u><b>Result of configuration read check</u></b><br><br>Connection parameter store type: configDB (don't forget upload configuration file if changed) <br>Connection Error on reading /opt/fhem/db.conf from database! <br><br><u><b>Result of connection check</u></b><br><br>Connection to database was not successful. <br><b>Recommendation:</b> Plese check logfile for further information. <br><br>
Ich habe verbose auf 5 gestellt. Im Logfile steht nun das.
2018.03.05 19:57:43 4: DbLog logdb - Trying to connect to database
2018.03.05 19:57:43 4: DbLog logdb - Waiting for database connection
2018.03.05 19:57:48 3: DbLog logdb - Creating Push-Handle to database with user
2018.03.05 19:57:48 2: DbLog logdb - Error: Can't connect to data source 'dbi:' because I can't work out what driver to use (it doesn't seem to contain a 'dbi:driver:' prefix and the DBI_DRIVER env var is not set) at ./FHEM/93_DbLog.pm line 2310.
Mich wundert eben, dass das DbLog.pm nicht den Datenbank Namen auflösen kann, weil der ja eigentlich bei "Creating Push-Handle to database [db name] with user [dbuser]" stehen sollte. Da er da wohl einen leeren String hat, kann er dann folglich auch nicht die datasource auflösen.
Hast du die Berechtigungen der db.conf mal überprüft?
Edit: Sorry - habe nicht weit genug nach oben gescrollt...
Kurz, weil mobil...
ZitatIch habe die db.conf in den Ordner /opt/fhem/ abgelegt. Besitzer und Gruppe sind "fhem:dialout". Mit den Berechtigungen habe ich schon bishin zu chmod 777 getestet.
Ja, das hatte ich bereits getestet. :)
Zitat von: blade-of-fire am 05 März 2018, 20:12:59
Ja, das hatte ich bereits getestet. :)
Hab's gerade selbst gemerkt- sorry
Kurz, weil mobil...
Die Ergebnisse des Configcheck sind schwer zu lesen (ausnahmsweise mal keine Code-Tags verwenden), aber man sieht schon das wahrscheinliche Problem:
Connection parameter store type: configDB (don't forget upload configuration file if changed)
Connection Error on reading /opt/fhem/db.conf from database!
Du verwendest configDB und hast die conf wahrscheinlich nicht hineingeladen.
Edit: Die Meldung "Connection Error on reading /opt/fhem/db.conf from database! " sieht mir sogar so aus als ob die Verbindung zur configDB garnicht funktioniert.
ja, ich benutze configDB. Und das funktioniert auch. Die Parameter werden in der Datenbank gespeichert.
wenn Du
configdb filelist
ausführst, siehst du dann deine db.conf ?
Die Ausgabe von "configdb filelist" ist:
Files found in database:
------------------------------------------------------------
./FHEM/FhemUtils/uniqueID
./www/gplot/wzpa_hz.gplot
dann solltest du die Datei importieren.
configDB fileimport ./db.conf
Super, danke, das wars :)
Vielen Dank für die schnelle Hilfe. Auf euch ist verlass. :D
Dafür gibts den ConfigCheck im DbLog und dort stand auch schon der Hinweis darauf. Das sollte einem dann auffallen ;)
Zitat von: kumue am 05 März 2018, 20:55:02
dann solltest du die Datei importieren.
configDB fileimport ./db.conf
Besser:
configDB filemove ./db.confDann muss man nämlich später die Datei erst wieder aus der Datenbank exportieren, um sie zu bearbeiten.
Und wenn man sie bewusst exportiert, denkt man eher daran, sie nach der Bearbeitung auch wieder zu importieren 8)
Zitat von: DS_Starter am 05 März 2018, 21:10:18
Dafür gibts den ConfigCheck im DbLog und dort stand auch schon der Hinweis darauf. Das sollte einem dann auffallen ;)
Noch besser wäre es, wenn DbLog nach dem gescheiterten FileRead() die Verarbeitung abbrechen und die zurückgelieferte Fehlermeldung ausgeben würde.
ZitatNoch besser wäre es, wenn DbLog nach dem gescheiterten FileRead() die Verarbeitung abbrechen und die zurückgelieferte Fehlermeldung ausgeben würde.
stimmt. Werde ich demnächst mal mit einbauen.
Edit: Hmm... eben geschaut. Das ist sogar schon so. Auf jeden Fall gibt es einen Eintrag im Logfile. Auch das hätte auffallen müssen. Muss ich nochmal in Ruhe überlegen ...
Grüße,
Heiko
Es macht wenig Sinn, bei einer nicht vorhandenen Konfigurationsdatei einfach weiterzumachen. Und das ist unabhängig davon, ob fhem.cfg oder configDB verwendet wird 8)
Ja ... habe soeben den Fehler gefunden warum das Device nicht ausgestiegen ist obwohl die config nicht gelesen werden konnte. :)
Werde noch etwas testen und dann einchecken ...
Jetzt, wo das Problem bekannt ist, macht für mich die Fehlermeldung auch Sinn. Im Vorfeld war mir aber nicht so ganz klar, wie ich die Meldung zu interpretieren habe.
Könnte man vielleicht im commandref und im Wiki bei dbLog einen kurzen Vermerk machen, dass wenn man die ConfigDB nutzt, die db.conf hochladen muss? Im ConfigDB ist es ja klar beschrieben, im dbLog habe ich dazu allerdings keine Hinweis in der Doku gefunden.
Zitat
Könnte man vielleicht im commandref und im Wiki bei dbLog einen kurzen Vermerk machen, dass wenn man die ConfigDB nutzt, die db.conf hochladen muss? Im ConfigDB ist es ja klar beschrieben, im dbLog habe ich dazu allerdings keine Hinweis in der Doku gefunden.
In ConfigDB ist es ja auch richtig platziert weil es eine Eigenschaft des Moduls ist wenn man es benutzt. In DbLog muss es ja auch nicht hinein weil es keine Eigenschaft dieses Moduls ist.
Aber ich werde trotzdem einen Vermerk in die Commandref schreiben in der Hoffnung dass es tatsächlich mal jemand liest (die Hoffnung sollte man ja bekanntlich nicht verlieren ;) ) und eine Hilfe für den User darstellt.
Klar gehrt die Thematik eigentlich zu configDB, aber ich denke das viele User, die für den Log eine Datenbank benutzen, auch die Config dort ablegen, von daher sind da schon Berührungspunkte.
Da das Thema ja aus meiner Sicht gelöst ist, schließe ich das mal.
Hallo,
ich habe nach einem Umzug meines NAS den selben Fehler.
libs sind installiert (hat ja bisher auch funktioniert)
Maria DB ist von der FHEM Konsole mit dem mysql-client erreichbar.
define myDbLog DbLog /opt/fhem/db.conf .*:(humidity|temperature|messured-temp|pressure|voltage|distance|fuell|Regen).*
attr myDbLog DbLogType Current/History
attr myDbLog asyncMode 1
attr myDbLog verbose 5
attr myDbLog room 90_System
config habe ich mit der hand nochmal neu geschrieben (kein copy&paste)
%dbconfig=(
connection => "mysql:database=fhem;host=10.0.0.10;port=3306",
user => "fhemuser",
password => "xxxx",
utf => 1
);
pi@FHEM:/opt/fhem $ ls -l
insgesamt 576
-rw-r--r-- 1 fhem dialout 249332 Mai 27 22:23 CHANGED
-rw-r--r-- 1 fhem dialout 41123 Apr 28 15:56 configDB.pm
drwxr-xr-x 40 fhem dialout 4096 Jun 6 21:19 contrib
-rwxrwxrwx 1 fhem dialout 148 Jun 6 22:58 db.conf
drwxr-xr-x 3 fhem dialout 4096 Apr 28 15:53 demolog
drwxr-xr-x 4 fhem dialout 4096 Apr 28 15:56 docs
drwxrwxrwx 6 fhem dialout 20480 Mai 13 09:39 FHEM
-rwxrwxrwx 1 fhem dialout 31385 Jun 6 23:07 fhem.cfg
-rw-r--r-- 1 fhem dialout 15848 Apr 28 15:56 fhem.cfg.demo
-rwxr-xr-x 1 fhem dialout 146640 Mai 25 16:40 fhem.pl
drwxr-xr-x 2 fhem dialout 4096 Jun 1 00:00 log
-rw-r--r-- 1 fhem dialout 37253 Mai 25 16:40 MAINTAINER.txt
-rw-r--r-- 1 fhem dialout 935 Feb 19 2017 README_DEMO.txt
drwxr-xr-x 5 fhem dialout 4096 Apr 28 16:13 restoreDir
drwxr-xr-x 2 fhem dialout 4096 Apr 28 15:56 unused
drwxrwxrwx 11 fhem dialout 4096 Mai 12 19:25 www
Verbose 5
2018.06.06 23:08:25 1: DbLog myDbLog - Error while reading /opt/fhem/db.conf: 'could not read connection'
2018.06.06 23:08:25 1: define myDbLog DbLog /opt/fhem/db.conf .*:(humidity|temperature|messured-temp|pressure|voltage|distance|fuell|Regen).*: could not read connection
db habe ich auf schon neu aufgesetzt.
Hat noch irgendwer eine Idee was ich übersehen haben kann?
Liebe Grüsse und Danke schon mal für die Hilfe!
Mach mal bitte ein "set ... configCheck" und poste die Ausgabe.
Das Verrückte daran ist dass FHEM scheinbar das DBLog Device aus der fhem.cfg entfernt hat.
Ich habe es danach wieder rein kopiert und versucht die config zu speichern, was eben immer zu could not read connection connection führt.
Ein Aufruf von
set myDbLog configCheck
liefert:
Please define myDbLog first
es dürfte also eher was mit der initialisierung des Moduls zu tun haben.
(reload des moduls, update all bringt keine abhilfe)
lg
Zitat
Das Verrückte daran ist dass FHEM scheinbar das DBLog Device aus der fhem.cfg entfernt hat.
Ich habe es danach wieder rein kopiert
Ja weil der bestimmte Inhalt der Datei db.conf nicht glesen werden kann und dadurch ein Betrieb des Devices nicht sinnvoll ist. Allerdings passiert die Entfernung des Device nicht wenn nicht "save" gedrückt wird bzw. anderweitig (automatisch) ein "save" durchgeführt wird.
Aber egal, Problem ist dass der Satz " connection => ..." nicht gelesen werden kann. Ich vermute dass Steuerzeichen in der Datei db.conf sind.
Mit welchem Editor hast du die Datei db.conf erstellt ? Nimm einen vi oder ein Notepad++ mit Einstellung UNIX-Format.
das ist richtig, ich habe save gedrückt.
habe mit nano direkt auf der console ein neues file erstellt und händisch rein geschrieben.
werde es heute abend noch mit vi probieren kann mir aber nicht vorstellen dass das irgenwas ändert.
lg
Christoph
Habe die Lösung bzw. das Problem gefunden:
mein Passwort beinhaltete Sonderzeichen welche scheinbar das Config-File korrupt machten.
Vielleicht sollte man das in der Doku aufnehmen.
Danke euch allen für die Hilfe!!
Liebe Grüsse
Christoph
Welche Sonderzeichen waren das ?
Lg,
Heiko
Bestimmt Non utf8.
Gesendet von meinem Doogee S60 mit Tapatalk
Ein % und ein $ war im Passwort.
Ah, ok. Die Zeichen wären zu escapen "$" , also als "\$" zu schreiben bzw. "%" als "\%". Ähnliches trifft für "@" zu -> "\@".
Es betrifft also alle Zeichen die in Perl irgendeine Bedeutung haben.
Werde ich bei einem Update von DbLog mit darauf hinweisen.
Grüße
Heiko
Das config-File ist doch ohnehin nix anderes als reiner perl code. Ein Punkt, der mich sowohl bei DbLog als auch bei configDB schon lange stört.
Vielleicht wäre es sinnvoller, das configFile anstatt mit eval() besser zeilenweise als Text auszuwerten. Dann könnte man u.a. solche Sonderzeichenprobleme vermeiden.
Gute Idee betateilchen. Ich werde das mir für DbLog bei Gelegenheit mal anschauen und ausprobieren.
Grüße
Heiko
ich werde mir das gleiche Thema für die Auswertung der configDB.conf auf die ToDo Liste schreiben, dort ist ja genau das gleiche Verhalten implementiert
Ja war wirklich ein Anfängerfehler,
die Passwortänderung ist leider mit der Serverumstellung zusammengefallen was dann entsprechendes Chaos gestifftet hat.
Aber danke dass du es in die commandref aufnimmst, das erspart in zeiten von "sicheren" Passwörtern vielleicht das eine oder andere Problem.
lg und danke nochmal für eure Hilfe!
Zitat von: betateilchen am 11 Juni 2018, 09:36:23
Vielleicht wäre es sinnvoller, das configFile anstatt mit eval() besser zeilenweise als Text auszuwerten. Dann könnte man u.a. solche Sonderzeichenprobleme vermeiden.
Gar nicht so einfach, das umzubauen, wenn man es abwärtskompatibel zu bestehenden Installationen gestalten will.
Ich schaue mir das wahrscheinlich morgen mal an ... aber glaub ich dir glatt.
Add hoc fällt mir noch die Möglichkeit ein solche Problemzeichen automatisch zu maskieren wenn sie es nicht sind.
Dann könnte alles so bleiben wie es ist. Hmm ... weiß nicht was besser umsetzbar und zielführender wäre ...