DbLog Verbindungsproblem nach Update auf Debian Bullseye

[cbl]

Code Auswählen Erweitern

%dbconfig= (
    connection => "mysql:database=fhem;host=dbserver;port=3306",
    user => "fhem_db",
    password => "xxxx",
    utf8 => 1
);

Sieht für die configDB genauso aus - nur mit anderem User.

[DS_Starter]

Sieht erstmal gut aus. Die Fehlermitteilung besagt dass der Eintrag für "connection =>" nicht gelesen werden kann.
Wir hatten schonmal den Fall, dass das File mit einem "ungünstigen" Editor erstellt wurde und nicht sichtbare aber störende Zeichen enthalten waren.
Kannst du dieses File nochmal erstellen. Am besten mit einem vi (Linux) oder auch notepad++ ?
Den Inhalt eintippen , nicht per copy+paste.

[cbl]

Erstellt habe ich das mit dem MC-Editor. Das File hat noch nie einen Windows-PC oder eine grafische Oberfläche gesehen.

Ich habe in der Zwischenzeit das DBLog-Device komplett gelöscht und neu angelegt und dabei dämmerte mir, was das Problem ist:
Beim Einlesen in configDB habe ich ./db.conf verwendet. Im DBLog-Device stand /opt/fhem/db.conf. Das meint zwar dieselbe Datei, ist aber als Schlüssel in der configDB natürlich ein Unterschied.

Was mich wundert ist aber, dass das vor dem Update auf Debian 11 funktioniert hat. Am DBLog Device (und auch sonst) habe ich nichts rumgeschraubt. Ist da irgendeine beteiligte Perl-Bibliothek in einer neueren Version derart verändert, dass das vorher funktioniert hat mit der relativen Pfadangabe und nun strikter gehandhabt wird?

[DS_Starter]

Ist da irgendeine beteiligte Perl-Bibliothek in einer neueren Version derart verändert, dass das vorher funktioniert hat mit der relativen Pfadangabe und nun strikter gehandhabt wird?

Kann ich mir nicht vorstellen.

Hab noch nicht ganz verstanden was der Status jetzt ist. Geht es nun mit einem neu angelegten DbLog Device mit meiner Testzeile und/oder auch mit configDB ?

[cbl]

Es läuft jetzt mit einem neu angelegten DbLog Device. Das alte habe ich gelöscht. Ich vermute, dass es auch mit dem alten Device nun funktioniert hätte.
Ich verwende weiterhin configDB und habe (mit dem gewünschten User und neuem Passwort) die db.conf neu eingelesen.

Die echte Änderung ist, dass ich beim configdb fileimport die db.conf exakt so angegeben habe wie im DbLog Device. Das war vorher unterschiedlich.

Vielen Dank für die Tipps, die am Ende dazu geführt haben, dass ich beim wiederholten Draufschauen den Unterschied gesehen habe.

[DS_Starter]

Na dann weiterhin viel Spaß beim Loggen 

Allerdings erschließt sich mir noch nicht wieso aus dem File nicht korrekt gelesen werden konnte.
Nun ja ...

LG,
Heiko

[betateilchen]

Was mich wundert ist aber, dass das vor dem Update auf Debian 11 funktioniert hat. Am DBLog Device (und auch sonst) habe ich nichts rumgeschraubt. Ist da irgendeine beteiligte Perl-Bibliothek in einer neueren Version derart verändert, dass das vorher funktioniert hat mit der relativen Pfadangabe und nun strikter gehandhabt wird?

Das hat vorher nicht funktioniert. Du hast vorher im DbLog device /opt/fhem/db.conf verwendet.

Den Fehler hast Du beim Editieren Deiner Verbindungskonfiguration verbrochen...

mit einem neu gesetzten Passwort. Dieses Passwort habe ich nach dem Anlegen in MySQL auch in die db.conf geschrieben.


Nachtrag da ich mit configDB arbeite:
Ich habe die db.conf auch wieder mit

Code Auswählen Erweitern

configDB fileimport ./db.conf

importiert.

und damit hast Du zwei verschiedene Konfigurationsdateien in Deiner configDB.
Dass dann weiterhin die alte Konfigurationsdatei verwendet wird, ist absolut logisch, solange Du das im DEF Deines DbLog nicht änderst.

Hättest Du einfach mal meinen Tipp befolgt und verbose 5 gesetzt, hättest Du das im FHEM-Log bemerkt.

[cbl]

Hallo,

ich hatte verbose 5 schon vorher und habe dieses Detail übersehen.

Aber ich stimme dir zu, dass vermutlich alles korrekt funktioniert und - wie so oft - das Problem 60 cm vor dem Rechner saß und die neue Konfigurationsdatei nun nur mit relativem Pfad importiert hat. Das muss ich vor langer Zeit schon mal gemacht haben, da mir die Autovervollständigung im Browser den relativen Pfad vorschlug, den ich dann auch so verwendet habe. 

Was die ursprüngliche Ursache war, dass nach dem Update die Verbindung nicht mehr geklappt hat, kann ich jetzt nicht mehr nachvollziehen. Den hier nun diskutierten Fehler habe ich im Rahmen der "Analyse" reingebracht.

Danke für eure Hinweise.

Gruß
Christian